From xen-devel-bounces@lists.xen.org Tue May 01 06:41:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 06: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 ) id 1SP6kt-0002ab-6s; Tue, 01 May 2012 06:40:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SP6kr-0002aT-Hc for xen-devel@lists.xensource.com; Tue, 01 May 2012 06:40:09 +0000 Received: from [193.109.254.147:5751] by server-3.bemta-14.messagelabs.com id 40/63-23274-7458F9F4; Tue, 01 May 2012 06:40:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1335854406!7060702!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26030 invoked from network); 1 May 2012 06:40:06 -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 May 2012 06:40:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="12216430" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 06:40: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, 1 May 2012 07:40:06 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SP6kn-0006OX-Q1; Tue, 01 May 2012 06:40:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SP6kn-0005wR-MA; Tue, 01 May 2012 07:40:05 +0100 To: Message-ID: From: xen.org Date: Tue, 1 May 2012 07:40:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12767: tolerable trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12767 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12767/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken pass in 12765 test-amd64-amd64-pair 16 guest-start fail pass in 12765 test-i386-i386-xl-win 7 windows-install fail pass in 12765 test-i386-i386-pv 3 host-install(3) broken in 12765 pass in 12767 test-amd64-amd64-pv 3 host-install(3) broken in 12765 pass in 12767 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12765 pass in 12767 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 3 host-install(3) broken like 12765 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken like 12765 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-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-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 12765 never pass version targeted for testing: xen 9dda0efd8ce1 baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair fail test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 06:41:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 06: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 ) id 1SP6kt-0002ab-6s; Tue, 01 May 2012 06:40:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SP6kr-0002aT-Hc for xen-devel@lists.xensource.com; Tue, 01 May 2012 06:40:09 +0000 Received: from [193.109.254.147:5751] by server-3.bemta-14.messagelabs.com id 40/63-23274-7458F9F4; Tue, 01 May 2012 06:40:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1335854406!7060702!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26030 invoked from network); 1 May 2012 06:40:06 -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 May 2012 06:40:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="12216430" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 06:40: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, 1 May 2012 07:40:06 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SP6kn-0006OX-Q1; Tue, 01 May 2012 06:40:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SP6kn-0005wR-MA; Tue, 01 May 2012 07:40:05 +0100 To: Message-ID: From: xen.org Date: Tue, 1 May 2012 07:40:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12767: tolerable trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12767 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12767/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken pass in 12765 test-amd64-amd64-pair 16 guest-start fail pass in 12765 test-i386-i386-xl-win 7 windows-install fail pass in 12765 test-i386-i386-pv 3 host-install(3) broken in 12765 pass in 12767 test-amd64-amd64-pv 3 host-install(3) broken in 12765 pass in 12767 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12765 pass in 12767 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 3 host-install(3) broken like 12765 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken like 12765 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-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-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 12765 never pass version targeted for testing: xen 9dda0efd8ce1 baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair fail test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 10:29:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 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 ) id 1SPAKS-0005JN-M9; Tue, 01 May 2012 10:29:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAKR-0005JI-HA for xen-devel@lists.xensource.com; Tue, 01 May 2012 10:29:07 +0000 Received: from [193.109.254.147:9562] by server-9.bemta-14.messagelabs.com id D0/34-05787-2FABF9F4; Tue, 01 May 2012 10:29:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1335868145!1425006!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10263 invoked from network); 1 May 2012 10:29:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 10:29:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,509,1330905600"; d="scan'208";a="12219493" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 10:29: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, 1 May 2012 11:29:05 +0100 Message-ID: <1335868144.6038.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 1 May 2012 11:29:04 +0100 In-Reply-To: <20120430093811.GC5414@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > The following makes 'x86info -r' dump kvm cpu ids > > > (signature+features) when running in a vm. > > > > > > On the guest we see the signature and the features: > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > On the host it just adds a couple of zero lines: > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > This is too KVM specific. > > That's what I have. I scratch my own itch. > > > Other hypervisors may use more cpuid leafs. > > But not less so no harm's done. > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > leaf available. Haven't checked Xen or VMWare. Xen does the same, documentation in the Xen public interfaces header: http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. If compat mode for another h/v is enabled then those leaves will appear at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of drivers (or detection routine, etc) should check at 0x100 intervals until 0x40010000 for the appropriate signatures (I realise that the docs are somewhat lacking in this regard, I should cook up a patch). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 10:29:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 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 ) id 1SPAKS-0005JN-M9; Tue, 01 May 2012 10:29:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAKR-0005JI-HA for xen-devel@lists.xensource.com; Tue, 01 May 2012 10:29:07 +0000 Received: from [193.109.254.147:9562] by server-9.bemta-14.messagelabs.com id D0/34-05787-2FABF9F4; Tue, 01 May 2012 10:29:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1335868145!1425006!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10263 invoked from network); 1 May 2012 10:29:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 10:29:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,509,1330905600"; d="scan'208";a="12219493" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 10:29: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, 1 May 2012 11:29:05 +0100 Message-ID: <1335868144.6038.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 1 May 2012 11:29:04 +0100 In-Reply-To: <20120430093811.GC5414@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > The following makes 'x86info -r' dump kvm cpu ids > > > (signature+features) when running in a vm. > > > > > > On the guest we see the signature and the features: > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > On the host it just adds a couple of zero lines: > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > This is too KVM specific. > > That's what I have. I scratch my own itch. > > > Other hypervisors may use more cpuid leafs. > > But not less so no harm's done. > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > leaf available. Haven't checked Xen or VMWare. Xen does the same, documentation in the Xen public interfaces header: http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. If compat mode for another h/v is enabled then those leaves will appear at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of drivers (or detection routine, etc) should check at 0x100 intervals until 0x40010000 for the appropriate signatures (I realise that the docs are somewhat lacking in this regard, I should cook up a patch). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 10:51:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 10:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAfI-0005WV-On; Tue, 01 May 2012 10:50:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAfH-0005WQ-Lf for xen-devel@lists.xensource.com; Tue, 01 May 2012 10:50:39 +0000 Received: from [85.158.143.99:46976] by server-2.bemta-4.messagelabs.com id E1/AF-17550-EFFBF9F4; Tue, 01 May 2012 10:50:38 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1335869437!25653433!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24048 invoked from network); 1 May 2012 10:50:38 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-5.tower-216.messagelabs.com with SMTP; 1 May 2012 10:50: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 q41AoQrC028218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 06:50:26 -0400 Received: from redhat.com (dhcp-4-60.tlv.redhat.com [10.35.4.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id q41AoNPm026991; Tue, 1 May 2012 06:50:23 -0400 Date: Tue, 1 May 2012 13:50:32 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120501105032.GA6654@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> <1335868144.6038.89.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335868144.6038.89.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 11:29:04AM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > > The following makes 'x86info -r' dump kvm cpu ids > > > > (signature+features) when running in a vm. > > > > > > > > On the guest we see the signature and the features: > > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > On the host it just adds a couple of zero lines: > > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > This is too KVM specific. > > > > That's what I have. I scratch my own itch. > > > > > Other hypervisors may use more cpuid leafs. > > > > But not less so no harm's done. > > > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > > leaf available. Haven't checked Xen or VMWare. > > Xen does the same, documentation in the Xen public interfaces header: > http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. So ack to my patch? > If compat mode for another h/v is enabled then those leaves will appear > at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > drivers (or detection routine, etc) should check at 0x100 intervals > until 0x40010000 for the appropriate signatures (I realise that the docs > are somewhat lacking in this regard, I should cook up a patch). > > Ian. How does guest know that the data at 0x40000100 makes sense? -- MST _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 10:51:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 10:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAfI-0005WV-On; Tue, 01 May 2012 10:50:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPAfH-0005WQ-Lf for xen-devel@lists.xensource.com; Tue, 01 May 2012 10:50:39 +0000 Received: from [85.158.143.99:46976] by server-2.bemta-4.messagelabs.com id E1/AF-17550-EFFBF9F4; Tue, 01 May 2012 10:50:38 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1335869437!25653433!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24048 invoked from network); 1 May 2012 10:50:38 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-5.tower-216.messagelabs.com with SMTP; 1 May 2012 10:50: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 q41AoQrC028218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 06:50:26 -0400 Received: from redhat.com (dhcp-4-60.tlv.redhat.com [10.35.4.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id q41AoNPm026991; Tue, 1 May 2012 06:50:23 -0400 Date: Tue, 1 May 2012 13:50:32 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120501105032.GA6654@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> <1335868144.6038.89.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335868144.6038.89.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 11:29:04AM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > > The following makes 'x86info -r' dump kvm cpu ids > > > > (signature+features) when running in a vm. > > > > > > > > On the guest we see the signature and the features: > > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > On the host it just adds a couple of zero lines: > > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > This is too KVM specific. > > > > That's what I have. I scratch my own itch. > > > > > Other hypervisors may use more cpuid leafs. > > > > But not less so no harm's done. > > > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > > leaf available. Haven't checked Xen or VMWare. > > Xen does the same, documentation in the Xen public interfaces header: > http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. So ack to my patch? > If compat mode for another h/v is enabled then those leaves will appear > at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > drivers (or detection routine, etc) should check at 0x100 intervals > until 0x40010000 for the appropriate signatures (I realise that the docs > are somewhat lacking in this regard, I should cook up a patch). > > Ian. How does guest know that the data at 0x40000100 makes sense? -- MST _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:18:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12:18:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPC1T-0006Ao-4j; Tue, 01 May 2012 12:17:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPC1S-0006Aj-HE for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:17:38 +0000 Received: from [85.158.143.35:53879] by server-1.bemta-4.messagelabs.com id F3/F0-20925-164DF9F4; Tue, 01 May 2012 12:17:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335874657!13735389!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7682 invoked from network); 1 May 2012 12:17:37 -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; 1 May 2012 12:17:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12221118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 12:17:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 13:17:16 +0100 Message-ID: <1335874635.6038.95.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 1 May 2012 13:17:15 +0100 In-Reply-To: <20120501105032.GA6654@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> <1335868144.6038.89.camel@zakaz.uk.xensource.com> <20120501105032.GA6654@redhat.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-01 at 11:50 +0100, Michael S. Tsirkin wrote: > On Tue, May 01, 2012 at 11:29:04AM +0100, Ian Campbell wrote: > > On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > > > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > > > The following makes 'x86info -r' dump kvm cpu ids > > > > > (signature+features) when running in a vm. > > > > > > > > > > On the guest we see the signature and the features: > > > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > > > On the host it just adds a couple of zero lines: > > > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > > This is too KVM specific. > > > > > > That's what I have. I scratch my own itch. > > > > > > > Other hypervisors may use more cpuid leafs. > > > > > > But not less so no harm's done. > > > > > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > > > leaf available. Haven't checked Xen or VMWare. > > > > Xen does the same, documentation in the Xen public interfaces header: > > http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. > > So ack to my patch? I didn't see the patch, where should I be looking? > > If compat mode for another h/v is enabled then those leaves will appear > > at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > > drivers (or detection routine, etc) should check at 0x100 intervals > > until 0x40010000 for the appropriate signatures (I realise that the docs > > are somewhat lacking in this regard, I should cook up a patch). > > > > Ian. > > How does guest know that the data at 0x40000100 makes sense? http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html EBX, ECX and EDX contain a signature "XenVMMXenVMM". I'm fairly certain that hyperv has it's own magic number here. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:18:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12:18:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPC1T-0006Ao-4j; Tue, 01 May 2012 12:17:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPC1S-0006Aj-HE for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:17:38 +0000 Received: from [85.158.143.35:53879] by server-1.bemta-4.messagelabs.com id F3/F0-20925-164DF9F4; Tue, 01 May 2012 12:17:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335874657!13735389!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7682 invoked from network); 1 May 2012 12:17:37 -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; 1 May 2012 12:17:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12221118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 12:17:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 13:17:16 +0100 Message-ID: <1335874635.6038.95.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 1 May 2012 13:17:15 +0100 In-Reply-To: <20120501105032.GA6654@redhat.com> References: <20120429101019.GA21165@redhat.com> <20120430084319.GE15413@redhat.com> <20120430093811.GC5414@redhat.com> <1335868144.6038.89.camel@zakaz.uk.xensource.com> <20120501105032.GA6654@redhat.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-01 at 11:50 +0100, Michael S. Tsirkin wrote: > On Tue, May 01, 2012 at 11:29:04AM +0100, Ian Campbell wrote: > > On Mon, 2012-04-30 at 10:38 +0100, Michael S. Tsirkin wrote: > > > On Mon, Apr 30, 2012 at 11:43:19AM +0300, Gleb Natapov wrote: > > > > On Sun, Apr 29, 2012 at 01:10:21PM +0300, Michael S. Tsirkin wrote: > > > > > The following makes 'x86info -r' dump kvm cpu ids > > > > > (signature+features) when running in a vm. > > > > > > > > > > On the guest we see the signature and the features: > > > > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > > > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > > > On the host it just adds a couple of zero lines: > > > > > eax in: 0x40000000, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > eax in: 0x40000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > > > > This is too KVM specific. > > > > > > That's what I have. I scratch my own itch. > > > > > > > Other hypervisors may use more cpuid leafs. > > > > > > But not less so no harm's done. > > > > > > > As far as I see Hyper-V uses 5 and use cpuid.0x40000000.eax as max cpuid > > > > leaf available. Haven't checked Xen or VMWare. > > > > Xen does the same, documentation in the Xen public interfaces header: > > http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html. > > So ack to my patch? I didn't see the patch, where should I be looking? > > If compat mode for another h/v is enabled then those leaves will appear > > at 0x40000000 and Xen's will be bumped up, so a fully Xen aware set of > > drivers (or detection routine, etc) should check at 0x100 intervals > > until 0x40010000 for the appropriate signatures (I realise that the docs > > are somewhat lacking in this regard, I should cook up a patch). > > > > Ian. > > How does guest know that the data at 0x40000100 makes sense? http://xenbits.xen.org/docs/unstable/hypercall/include,public,arch-x86,cpuid.h.html EBX, ECX and EDX contain a signature "XenVMMXenVMM". I'm fairly certain that hyperv has it's own magic number here. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:28:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12:28:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCAt-0006Kv-Au; Tue, 01 May 2012 12:27:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCAr-0006Kq-Nm for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:27:21 +0000 Received: from [85.158.143.99:50933] by server-3.bemta-4.messagelabs.com id 2D/CF-05853-9A6DF9F4; Tue, 01 May 2012 12:27:21 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-12.tower-216.messagelabs.com!1335875240!20749180!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6452 invoked from network); 1 May 2012 12:27:20 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-12.tower-216.messagelabs.com with SMTP; 1 May 2012 12:27:20 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 39216148710; Tue, 1 May 2012 12:27:16 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc4JUjM5MwMs; Tue, 1 May 2012 13:27:14 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id D041A1407F8; Tue, 1 May 2012 13:27:14 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPCAh-0006Af-I8; Tue, 01 May 2012 13:27:14 +0100 Message-ID: <1335875225.6038.98.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 01 May 2012 13:27:05 +0100 In-Reply-To: <20120430143835.GA10190@redhat.com> References: <20120430143835.GA10190@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > The following makes 'x86info -r' dump hypervisor leaf cpu ids > (for kvm this is signature+features) when running in a vm. > > On the guest we see the signature and the features: > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > Hypervisor flag is checked to avoid output changes when not > running on a VM. > > Signed-off-by: Michael S. Tsirkin > > Changes from v1: > Make work on non KVM hypervisors (only KVM was tested). > Avi Kivity said kvm will in the future report > max HV leaf in eax. For now it reports eax = 0 > so add a work around for that. > > --- > > diff --git a/identify.c b/identify.c > index 33f35de..a4a3763 100644 > --- a/identify.c > +++ b/identify.c > @@ -9,8 +9,8 @@ > > void get_cpu_info_basics(struct cpudata *cpu) > { > - unsigned int maxi, maxei, vendor, address_bits; > - unsigned int eax; > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > + unsigned int eax, ebx, ecx; > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > return; > > /* Everything that supports cpuid supports these. */ > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); You probably want to check ebx, ecx, edx for the signatures of the hypervisor's you are willing to support and which you know do something sane with eax? Also it would be something worth reporting in its own right? BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has a signature too 'KVMKVMKVM'. > cpu->stepping = eax & 0xf; > cpu->model = (eax >> 4) & 0xf; > cpu->family = (eax >> 8) & 0xf; > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > cpu->maxei2 = maxei; > + if (ecx & 0x80000000) { > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > + /* > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > + * where it really means 0x40000001. This is something where I definitely think you want to check the signature first. Ian. > + * Most (all?) hypervisors have at least one CPUID besides > + * the vendor ID so assume that. > + */ > + cpu->maxhv = maxhv ? maxhv : 0x40000001; > + } else { > + /* Suppress hypervisor cpuid unless running on a hypervisor */ > + cpu->maxhv = 0; > + } > > cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL); > cpu->phyaddr_bits = address_bits & 0xFF; > diff --git a/x86info.c b/x86info.c > index 22c4734..80cae36 100644 > --- a/x86info.c > +++ b/x86info.c > @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu) > > if (cpu->maxei2 >=0xC0000000) > dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2); > + > + if (cpu->maxhv >= 0x40000000) > + dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv); > + > } > > if (show_cacheinfo) { > diff --git a/x86info.h b/x86info.h > index 7d2a455..c4f5d81 100644 > --- a/x86info.h > +++ b/x86info.h > @@ -84,7 +84,7 @@ struct cpudata { > unsigned int cachesize_trace; > unsigned int phyaddr_bits; > unsigned int viraddr_bits; > - unsigned int cpuid_level, maxei, maxei2; > + unsigned int cpuid_level, maxei, maxei2, maxhv; > char name[CPU_NAME_LEN]; > enum connector connector; > unsigned int flags_ecx; > _______________________________________________ > Virtualization mailing list > Virtualization@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > -- Ian Campbell Your own qualities will help prevent your advancement in the world. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:28:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12:28:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCAt-0006Kv-Au; Tue, 01 May 2012 12:27:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCAr-0006Kq-Nm for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:27:21 +0000 Received: from [85.158.143.99:50933] by server-3.bemta-4.messagelabs.com id 2D/CF-05853-9A6DF9F4; Tue, 01 May 2012 12:27:21 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-12.tower-216.messagelabs.com!1335875240!20749180!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6452 invoked from network); 1 May 2012 12:27:20 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-12.tower-216.messagelabs.com with SMTP; 1 May 2012 12:27:20 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 39216148710; Tue, 1 May 2012 12:27:16 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc4JUjM5MwMs; Tue, 1 May 2012 13:27:14 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id D041A1407F8; Tue, 1 May 2012 13:27:14 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPCAh-0006Af-I8; Tue, 01 May 2012 13:27:14 +0100 Message-ID: <1335875225.6038.98.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Tue, 01 May 2012 13:27:05 +0100 In-Reply-To: <20120430143835.GA10190@redhat.com> References: <20120430143835.GA10190@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > The following makes 'x86info -r' dump hypervisor leaf cpu ids > (for kvm this is signature+features) when running in a vm. > > On the guest we see the signature and the features: > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > Hypervisor flag is checked to avoid output changes when not > running on a VM. > > Signed-off-by: Michael S. Tsirkin > > Changes from v1: > Make work on non KVM hypervisors (only KVM was tested). > Avi Kivity said kvm will in the future report > max HV leaf in eax. For now it reports eax = 0 > so add a work around for that. > > --- > > diff --git a/identify.c b/identify.c > index 33f35de..a4a3763 100644 > --- a/identify.c > +++ b/identify.c > @@ -9,8 +9,8 @@ > > void get_cpu_info_basics(struct cpudata *cpu) > { > - unsigned int maxi, maxei, vendor, address_bits; > - unsigned int eax; > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > + unsigned int eax, ebx, ecx; > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > return; > > /* Everything that supports cpuid supports these. */ > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); You probably want to check ebx, ecx, edx for the signatures of the hypervisor's you are willing to support and which you know do something sane with eax? Also it would be something worth reporting in its own right? BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has a signature too 'KVMKVMKVM'. > cpu->stepping = eax & 0xf; > cpu->model = (eax >> 4) & 0xf; > cpu->family = (eax >> 8) & 0xf; > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > cpu->maxei2 = maxei; > + if (ecx & 0x80000000) { > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > + /* > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > + * where it really means 0x40000001. This is something where I definitely think you want to check the signature first. Ian. > + * Most (all?) hypervisors have at least one CPUID besides > + * the vendor ID so assume that. > + */ > + cpu->maxhv = maxhv ? maxhv : 0x40000001; > + } else { > + /* Suppress hypervisor cpuid unless running on a hypervisor */ > + cpu->maxhv = 0; > + } > > cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL); > cpu->phyaddr_bits = address_bits & 0xFF; > diff --git a/x86info.c b/x86info.c > index 22c4734..80cae36 100644 > --- a/x86info.c > +++ b/x86info.c > @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu) > > if (cpu->maxei2 >=0xC0000000) > dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2); > + > + if (cpu->maxhv >= 0x40000000) > + dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv); > + > } > > if (show_cacheinfo) { > diff --git a/x86info.h b/x86info.h > index 7d2a455..c4f5d81 100644 > --- a/x86info.h > +++ b/x86info.h > @@ -84,7 +84,7 @@ struct cpudata { > unsigned int cachesize_trace; > unsigned int phyaddr_bits; > unsigned int viraddr_bits; > - unsigned int cpuid_level, maxei, maxei2; > + unsigned int cpuid_level, maxei, maxei2, maxhv; > char name[CPU_NAME_LEN]; > enum connector connector; > unsigned int flags_ecx; > _______________________________________________ > Virtualization mailing list > Virtualization@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > -- Ian Campbell Your own qualities will help prevent your advancement in the world. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:36:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12: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 ) id 1SPCIb-0006W6-9H; Tue, 01 May 2012 12:35:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCIZ-0006W1-Sb for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:35:20 +0000 Received: from [85.158.138.51:60115] by server-11.bemta-3.messagelabs.com id C0/C3-18894-788DF9F4; Tue, 01 May 2012 12:35:19 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335875717!13634601!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 741 invoked from network); 1 May 2012 12:35:18 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-174.messagelabs.com with SMTP; 1 May 2012 12:35:18 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q41CZAHx020386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 08:35:10 -0400 Received: from redhat.com (dhcp-4-60.tlv.redhat.com [10.35.4.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id q41CZ4xD021636; Tue, 1 May 2012 08:35:06 -0400 Date: Tue, 1 May 2012 15:35:13 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120501123513.GA8019@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335875225.6038.98.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 01:27:05PM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump hypervisor leaf cpu ids > > (for kvm this is signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > Hypervisor flag is checked to avoid output changes when not > > running on a VM. > > > > Signed-off-by: Michael S. Tsirkin > > > > Changes from v1: > > Make work on non KVM hypervisors (only KVM was tested). > > Avi Kivity said kvm will in the future report > > max HV leaf in eax. For now it reports eax = 0 > > so add a work around for that. > > > > --- > > > > diff --git a/identify.c b/identify.c > > index 33f35de..a4a3763 100644 > > --- a/identify.c > > +++ b/identify.c > > @@ -9,8 +9,8 @@ > > > > void get_cpu_info_basics(struct cpudata *cpu) > > { > > - unsigned int maxi, maxei, vendor, address_bits; > > - unsigned int eax; > > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > > + unsigned int eax, ebx, ecx; > > > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > > return; > > > > /* Everything that supports cpuid supports these. */ > > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); > > You probably want to check ebx, ecx, edx for the signatures of the > hypervisor's you are willing to support and which you know do something > sane with eax? Everyone puts the max leaf in eax - this is what hardware CPUs do. So I think we can just interpret eax as such. If someone wants to put broken info in cpuid, send a patch to blacklist it. > Also it would be something worth reporting in its own > right? > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > a signature too 'KVMKVMKVM'. > > > cpu->stepping = eax & 0xf; > > cpu->model = (eax >> 4) & 0xf; > > cpu->family = (eax >> 8) & 0xf; > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > cpu->maxei2 = maxei; > > + if (ecx & 0x80000000) { > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > + /* > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > + * where it really means 0x40000001. > > This is something where I definitely think you want to check the > signature first. > > Ian. kvm lets users change the signature. But worst case we print one useless line. Better than not printing something potentially useful. -- MST _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 12:36:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 12: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 ) id 1SPCIb-0006W6-9H; Tue, 01 May 2012 12:35:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCIZ-0006W1-Sb for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:35:20 +0000 Received: from [85.158.138.51:60115] by server-11.bemta-3.messagelabs.com id C0/C3-18894-788DF9F4; Tue, 01 May 2012 12:35:19 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335875717!13634601!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 741 invoked from network); 1 May 2012 12:35:18 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-174.messagelabs.com with SMTP; 1 May 2012 12:35:18 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q41CZAHx020386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 08:35:10 -0400 Received: from redhat.com (dhcp-4-60.tlv.redhat.com [10.35.4.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id q41CZ4xD021636; Tue, 1 May 2012 08:35:06 -0400 Date: Tue, 1 May 2012 15:35:13 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120501123513.GA8019@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335875225.6038.98.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 01:27:05PM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump hypervisor leaf cpu ids > > (for kvm this is signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > Hypervisor flag is checked to avoid output changes when not > > running on a VM. > > > > Signed-off-by: Michael S. Tsirkin > > > > Changes from v1: > > Make work on non KVM hypervisors (only KVM was tested). > > Avi Kivity said kvm will in the future report > > max HV leaf in eax. For now it reports eax = 0 > > so add a work around for that. > > > > --- > > > > diff --git a/identify.c b/identify.c > > index 33f35de..a4a3763 100644 > > --- a/identify.c > > +++ b/identify.c > > @@ -9,8 +9,8 @@ > > > > void get_cpu_info_basics(struct cpudata *cpu) > > { > > - unsigned int maxi, maxei, vendor, address_bits; > > - unsigned int eax; > > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > > + unsigned int eax, ebx, ecx; > > > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > > return; > > > > /* Everything that supports cpuid supports these. */ > > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); > > You probably want to check ebx, ecx, edx for the signatures of the > hypervisor's you are willing to support and which you know do something > sane with eax? Everyone puts the max leaf in eax - this is what hardware CPUs do. So I think we can just interpret eax as such. If someone wants to put broken info in cpuid, send a patch to blacklist it. > Also it would be something worth reporting in its own > right? > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > a signature too 'KVMKVMKVM'. > > > cpu->stepping = eax & 0xf; > > cpu->model = (eax >> 4) & 0xf; > > cpu->family = (eax >> 8) & 0xf; > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > cpu->maxei2 = maxei; > > + if (ecx & 0x80000000) { > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > + /* > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > + * where it really means 0x40000001. > > This is something where I definitely think you want to check the > signature first. > > Ian. kvm lets users change the signature. But worst case we print one useless line. Better than not printing something potentially useful. -- MST _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:05:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:05:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClE-0006uh-Iy; Tue, 01 May 2012 13:04:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClD-0006uc-6T for xen-devel@lists.xensource.com; Tue, 01 May 2012 13:04:55 +0000 Received: from [85.158.143.99:47268] by server-3.bemta-4.messagelabs.com id CE/F4-05853-67FDF9F4; Tue, 01 May 2012 13:04:54 +0000 X-Env-Sender: gleb@redhat.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1335877475!16370936!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25918 invoked from network); 1 May 2012 13:04:36 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-216.messagelabs.com with SMTP; 1 May 2012 13:04:36 -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 q41D4LIf008180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 09:04:21 -0400 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 q41D4K22016265; Tue, 1 May 2012 09:04:20 -0400 Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519) id 03C8B18D495; Tue, 1 May 2012 16:04:19 +0300 (IDT) Date: Tue, 1 May 2012 16:04:19 +0300 From: Gleb Natapov To: Ian Campbell Message-ID: <20120501130419.GJ22191@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335875225.6038.98.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 01:27:05PM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump hypervisor leaf cpu ids > > (for kvm this is signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > Hypervisor flag is checked to avoid output changes when not > > running on a VM. > > > > Signed-off-by: Michael S. Tsirkin > > > > Changes from v1: > > Make work on non KVM hypervisors (only KVM was tested). > > Avi Kivity said kvm will in the future report > > max HV leaf in eax. For now it reports eax = 0 > > so add a work around for that. > > > > --- > > > > diff --git a/identify.c b/identify.c > > index 33f35de..a4a3763 100644 > > --- a/identify.c > > +++ b/identify.c > > @@ -9,8 +9,8 @@ > > > > void get_cpu_info_basics(struct cpudata *cpu) > > { > > - unsigned int maxi, maxei, vendor, address_bits; > > - unsigned int eax; > > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > > + unsigned int eax, ebx, ecx; > > > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > > return; > > > > /* Everything that supports cpuid supports these. */ > > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); > > You probably want to check ebx, ecx, edx for the signatures of the > hypervisor's you are willing to support and which you know do something > sane with eax? Also it would be something worth reporting in its own > right? > Yes, but this is for -r option which only dumps raw cpuid info. Decoding hypervisor specific info is useful thing, but should not be pre-request for that patch. > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > a signature too 'KVMKVMKVM'. > > > cpu->stepping = eax & 0xf; > > cpu->model = (eax >> 4) & 0xf; > > cpu->family = (eax >> 8) & 0xf; > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > cpu->maxei2 = maxei; > > + if (ecx & 0x80000000) { > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > + /* > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > + * where it really means 0x40000001. > > This is something where I definitely think you want to check the > signature first. In theory yes, but in practice what will this break? > > Ian. > > > + * Most (all?) hypervisors have at least one CPUID besides > > + * the vendor ID so assume that. > > + */ > > + cpu->maxhv = maxhv ? maxhv : 0x40000001; > > + } else { > > + /* Suppress hypervisor cpuid unless running on a hypervisor */ > > + cpu->maxhv = 0; > > + } > > > > cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL); > > cpu->phyaddr_bits = address_bits & 0xFF; > > diff --git a/x86info.c b/x86info.c > > index 22c4734..80cae36 100644 > > --- a/x86info.c > > +++ b/x86info.c > > @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu) > > > > if (cpu->maxei2 >=0xC0000000) > > dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2); > > + > > + if (cpu->maxhv >= 0x40000000) > > + dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv); > > + > > } > > > > if (show_cacheinfo) { > > diff --git a/x86info.h b/x86info.h > > index 7d2a455..c4f5d81 100644 > > --- a/x86info.h > > +++ b/x86info.h > > @@ -84,7 +84,7 @@ struct cpudata { > > unsigned int cachesize_trace; > > unsigned int phyaddr_bits; > > unsigned int viraddr_bits; > > - unsigned int cpuid_level, maxei, maxei2; > > + unsigned int cpuid_level, maxei, maxei2, maxhv; > > char name[CPU_NAME_LEN]; > > enum connector connector; > > unsigned int flags_ecx; > > _______________________________________________ > > Virtualization mailing list > > Virtualization@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > > > > -- > Ian Campbell > > Your own qualities will help prevent your advancement in the world. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:05:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:05:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClE-0006uh-Iy; Tue, 01 May 2012 13:04:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClD-0006uc-6T for xen-devel@lists.xensource.com; Tue, 01 May 2012 13:04:55 +0000 Received: from [85.158.143.99:47268] by server-3.bemta-4.messagelabs.com id CE/F4-05853-67FDF9F4; Tue, 01 May 2012 13:04:54 +0000 X-Env-Sender: gleb@redhat.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1335877475!16370936!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MDk=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25918 invoked from network); 1 May 2012 13:04:36 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-216.messagelabs.com with SMTP; 1 May 2012 13:04:36 -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 q41D4LIf008180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 09:04:21 -0400 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 q41D4K22016265; Tue, 1 May 2012 09:04:20 -0400 Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519) id 03C8B18D495; Tue, 1 May 2012 16:04:19 +0300 (IDT) Date: Tue, 1 May 2012 16:04:19 +0300 From: Gleb Natapov To: Ian Campbell Message-ID: <20120501130419.GJ22191@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335875225.6038.98.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 01:27:05PM +0100, Ian Campbell wrote: > On Mon, 2012-04-30 at 17:38 +0300, Michael S. Tsirkin wrote: > > The following makes 'x86info -r' dump hypervisor leaf cpu ids > > (for kvm this is signature+features) when running in a vm. > > > > On the guest we see the signature and the features: > > eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d > > eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > Hypervisor flag is checked to avoid output changes when not > > running on a VM. > > > > Signed-off-by: Michael S. Tsirkin > > > > Changes from v1: > > Make work on non KVM hypervisors (only KVM was tested). > > Avi Kivity said kvm will in the future report > > max HV leaf in eax. For now it reports eax = 0 > > so add a work around for that. > > > > --- > > > > diff --git a/identify.c b/identify.c > > index 33f35de..a4a3763 100644 > > --- a/identify.c > > +++ b/identify.c > > @@ -9,8 +9,8 @@ > > > > void get_cpu_info_basics(struct cpudata *cpu) > > { > > - unsigned int maxi, maxei, vendor, address_bits; > > - unsigned int eax; > > + unsigned int maxi, maxei, maxhv, vendor, address_bits; > > + unsigned int eax, ebx, ecx; > > > > cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL); > > maxi &= 0xffff; /* The high-order word is non-zero on some Cyrix CPUs */ > > @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu) > > return; > > > > /* Everything that supports cpuid supports these. */ > > - cpuid(cpu->number, 1, &eax, NULL, NULL, NULL); > > + cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL); > > You probably want to check ebx, ecx, edx for the signatures of the > hypervisor's you are willing to support and which you know do something > sane with eax? Also it would be something worth reporting in its own > right? > Yes, but this is for -r option which only dumps raw cpuid info. Decoding hypervisor specific info is useful thing, but should not be pre-request for that patch. > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > a signature too 'KVMKVMKVM'. > > > cpu->stepping = eax & 0xf; > > cpu->model = (eax >> 4) & 0xf; > > cpu->family = (eax >> 8) & 0xf; > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > cpu->maxei2 = maxei; > > + if (ecx & 0x80000000) { > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > + /* > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > + * where it really means 0x40000001. > > This is something where I definitely think you want to check the > signature first. In theory yes, but in practice what will this break? > > Ian. > > > + * Most (all?) hypervisors have at least one CPUID besides > > + * the vendor ID so assume that. > > + */ > > + cpu->maxhv = maxhv ? maxhv : 0x40000001; > > + } else { > > + /* Suppress hypervisor cpuid unless running on a hypervisor */ > > + cpu->maxhv = 0; > > + } > > > > cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL); > > cpu->phyaddr_bits = address_bits & 0xFF; > > diff --git a/x86info.c b/x86info.c > > index 22c4734..80cae36 100644 > > --- a/x86info.c > > +++ b/x86info.c > > @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu) > > > > if (cpu->maxei2 >=0xC0000000) > > dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2); > > + > > + if (cpu->maxhv >= 0x40000000) > > + dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv); > > + > > } > > > > if (show_cacheinfo) { > > diff --git a/x86info.h b/x86info.h > > index 7d2a455..c4f5d81 100644 > > --- a/x86info.h > > +++ b/x86info.h > > @@ -84,7 +84,7 @@ struct cpudata { > > unsigned int cachesize_trace; > > unsigned int phyaddr_bits; > > unsigned int viraddr_bits; > > - unsigned int cpuid_level, maxei, maxei2; > > + unsigned int cpuid_level, maxei, maxei2, maxhv; > > char name[CPU_NAME_LEN]; > > enum connector connector; > > unsigned int flags_ecx; > > _______________________________________________ > > Virtualization mailing list > > Virtualization@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/virtualization > > > > -- > Ian Campbell > > Your own qualities will help prevent your advancement in the world. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:19:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:19:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCzA-00076O-2k; Tue, 01 May 2012 13:19:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCz8-00076J-I6 for xen-devel@lists.xen.org; Tue, 01 May 2012 13:19:18 +0000 Received: from [193.109.254.147:30348] by server-4.bemta-14.messagelabs.com id 55/7A-11570-5D2EF9F4; Tue, 01 May 2012 13:19:17 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335878356!282416!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22080 invoked from network); 1 May 2012 13:19:16 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:19:16 -0000 Received: by eeit10 with SMTP id t10so937709eei.32 for ; Tue, 01 May 2012 06:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=Q9KLQR+hEAI7Mx/pMcTXg8eNP89fbU889cPFdVLhSnI=; b=SunlOy6HtpNlO8n1duAVT3ZDYFPdaDMqaarIsi43aZfFhXWWPUnfU31qQD8+1WgvWW VxhdeC0zfNFLS7H/HKXbYR5mzD45pbjmb2G2Zp+6OunRswUSNM6s45FqU0H00mVv5UuO 4U97nrMVQwZOFt1m9XRyFJsIDVTSkmJOMXCJ/kir/0Dh5kdiYHmVE/BHuJXKceEUQ0zG nqde9/P/Ub+Y3ipXY7SaViROQN5cAU2j3L4uGaY0CkRlKR9ZOkO6FaWlD6e+98GmR5FL GITHQmUGp88uWOVggJAuwVm2HCxSdrpy0ZBYL6fE7HgztEHOKogvVQmz0SV+ocyGdonI +3jw== Received: by 10.14.130.202 with SMTP id k50mr3278845eei.113.1335878355585; Tue, 01 May 2012 06:19:15 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id n56sm90797561eeb.4.2012.05.01.06.19.14 (version=SSLv3 cipher=OTHER); Tue, 01 May 2012 06:19:15 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 01 May 2012 14:19:12 +0100 From: Keir Fraser To: Malcolm Crossley , Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases Thread-Index: Ac0nnP+VDYFinh8bFEa3dtC/G+tPOg== In-Reply-To: <4F99617F.8000002@citrix.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 26/04/2012 15:53, "Malcolm Crossley" wrote: > On 12/04/12 17:30, Ian Campbell wrote: >> The time has come for another round of stable releases. >> >> Please send (or resend) any outstanding backport requests for 4.0.4 and >> 4.1.3 before Friday 20 April. >> >> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >> >> Ian. > Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be > backported to 4.0 and 4.1? Done. -- Keir > Thanks, > > Malcolm > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:19:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:19:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCzA-00076O-2k; Tue, 01 May 2012 13:19:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCz8-00076J-I6 for xen-devel@lists.xen.org; Tue, 01 May 2012 13:19:18 +0000 Received: from [193.109.254.147:30348] by server-4.bemta-14.messagelabs.com id 55/7A-11570-5D2EF9F4; Tue, 01 May 2012 13:19:17 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335878356!282416!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22080 invoked from network); 1 May 2012 13:19:16 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:19:16 -0000 Received: by eeit10 with SMTP id t10so937709eei.32 for ; Tue, 01 May 2012 06:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=Q9KLQR+hEAI7Mx/pMcTXg8eNP89fbU889cPFdVLhSnI=; b=SunlOy6HtpNlO8n1duAVT3ZDYFPdaDMqaarIsi43aZfFhXWWPUnfU31qQD8+1WgvWW VxhdeC0zfNFLS7H/HKXbYR5mzD45pbjmb2G2Zp+6OunRswUSNM6s45FqU0H00mVv5UuO 4U97nrMVQwZOFt1m9XRyFJsIDVTSkmJOMXCJ/kir/0Dh5kdiYHmVE/BHuJXKceEUQ0zG nqde9/P/Ub+Y3ipXY7SaViROQN5cAU2j3L4uGaY0CkRlKR9ZOkO6FaWlD6e+98GmR5FL GITHQmUGp88uWOVggJAuwVm2HCxSdrpy0ZBYL6fE7HgztEHOKogvVQmz0SV+ocyGdonI +3jw== Received: by 10.14.130.202 with SMTP id k50mr3278845eei.113.1335878355585; Tue, 01 May 2012 06:19:15 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id n56sm90797561eeb.4.2012.05.01.06.19.14 (version=SSLv3 cipher=OTHER); Tue, 01 May 2012 06:19:15 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 01 May 2012 14:19:12 +0100 From: Keir Fraser To: Malcolm Crossley , Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases Thread-Index: Ac0nnP+VDYFinh8bFEa3dtC/G+tPOg== In-Reply-To: <4F99617F.8000002@citrix.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 26/04/2012 15:53, "Malcolm Crossley" wrote: > On 12/04/12 17:30, Ian Campbell wrote: >> The time has come for another round of stable releases. >> >> Please send (or resend) any outstanding backport requests for 4.0.4 and >> 4.1.3 before Friday 20 April. >> >> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >> >> Ian. > Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be > backported to 4.0 and 4.1? Done. -- Keir > Thanks, > > Malcolm > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007Qj-Dr; Tue, 01 May 2012 13:53:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007Px-2K for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:02 +0000 Received: from [85.158.138.51:28429] by server-5.bemta-3.messagelabs.com id 3F/07-17113-DBAEF9F4; Tue, 01 May 2012 13:53:01 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!5 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2365 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825480" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Hr; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:41 +0100 Message-ID: <1335880366-9873-3-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 2/7] vgabios: Does not define cur_mode if not required X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3fc786d..3d42216 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -761,7 +761,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; Bit16u status; Bit16u result; Bit16u vbe2_info; +#ifdef DEBUG Bit16u cur_mode=0; +#endif Bit16u cur_ptr=34; ModeInfoListItem *cur_info=&mode_info_list; @@ -849,9 +851,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); + cur_mode++; #endif write_word(ES, DI + cur_ptr, cur_info->mode); - cur_mode++; cur_ptr+=2; } else { #ifdef DEBUG -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007Qj-Dr; Tue, 01 May 2012 13:53:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007Px-2K for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:02 +0000 Received: from [85.158.138.51:28429] by server-5.bemta-3.messagelabs.com id 3F/07-17113-DBAEF9F4; Tue, 01 May 2012 13:53:01 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!5 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2365 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825480" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Hr; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:41 +0100 Message-ID: <1335880366-9873-3-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 2/7] vgabios: Does not define cur_mode if not required X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3fc786d..3d42216 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -761,7 +761,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; Bit16u status; Bit16u result; Bit16u vbe2_info; +#ifdef DEBUG Bit16u cur_mode=0; +#endif Bit16u cur_ptr=34; ModeInfoListItem *cur_info=&mode_info_list; @@ -849,9 +851,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); + cur_mode++; #endif write_word(ES, DI + cur_ptr, cur_info->mode); - cur_mode++; cur_ptr+=2; } else { #ifdef DEBUG -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007QX-22; Tue, 01 May 2012 13:53:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVl-0007Pn-H7 for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:01 +0000 Received: from [85.158.143.35:60252] by server-1.bemta-4.messagelabs.com id 18/81-20925-CBAEF9F4; Tue, 01 May 2012 13:53:00 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880378!13643321!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11558 invoked from network); 1 May 2012 13:52:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825478" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-JI; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:44 +0100 Message-ID: <1335880366-9873-6-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 5/7] vgabios: Reduce stack usage getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index fff314e..0b8b736 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -914,9 +914,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; // error by default is 0x014f which means supported but error Bit16u result=0x014f; Bit16u ss=get_SS(); - ModeInfoBlock info; ModeInfoListItem *cur_info; Boolean using_lfb; + ModeInfoBlockCompact info; #ifdef DEBUG printf("VBE vbe_biosfn_return_mode_information ES%x DI%x CX%x\n",ES,DI,CX); @@ -933,7 +933,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif - memsetb(ss, &info, 0, sizeof(ModeInfoBlock)); memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); if (using_lfb) { info.NumberOfBanks = 1; @@ -950,6 +949,10 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; info.PhysBasePtr |= inw(VBE_DISPI_IOPORT_DATA); #endif result = 0x4f; + + // copy updates in mode_info_block back + memsetb(ES, DI, 0, sizeof(ModeInfoBlock)); + memcpyb(ES, DI, ss, &info, sizeof(info)); } else { @@ -957,12 +960,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; printf("VBE *NOT* found mode %x\n",CX); #endif } - - if (result == 0x4f) - { - // copy updates in mode_info_block back - memcpyb(ES, DI, ss, &info, sizeof(info)); - } write_word(ss, AX, result); } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007QN-Ka; Tue, 01 May 2012 13:53:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVl-0007PN-1m for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:01 +0000 Received: from [85.158.138.51:28349] by server-11.bemta-3.messagelabs.com id 1D/B2-18894-BBAEF9F4; Tue, 01 May 2012 13:52:59 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2284 invoked from network); 1 May 2012 13:52:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825477" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-IL; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:42 +0100 Message-ID: <1335880366-9873-4-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- 1 files changed, 28 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3d42216..35d9866 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -742,6 +742,29 @@ no_vbe_flag: jmp _display_string ASM_END +ASM_START +_size64: + push bp + mov bp, sp + push dx + +; multiply bbp by yres first as results fit in 16bits +; then multiply by xres + mov ax, 8[bp] + mul word 6[bp] + mul word 4[bp] +; divide by 2^19 ceiling result + add ax, #0xffff + adc dx, #7 + mov ax, dx + shr ax, #3 + + pop dx + pop bp + ret +ASM_END + + /** Function 00h - Return VBE Controller Information * * Input: @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; do { + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); + Bit16u max_bpp = dispi_get_max_bpp(); + if ((cur_info->info.XResolution <= dispi_get_max_xres()) && - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { + (cur_info->info.BitsPerPixel <= max_bpp) && + (size_64k <= vbe_info_block.TotalMemory)) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); cur_mode++; -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007QX-22; Tue, 01 May 2012 13:53:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVl-0007Pn-H7 for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:01 +0000 Received: from [85.158.143.35:60252] by server-1.bemta-4.messagelabs.com id 18/81-20925-CBAEF9F4; Tue, 01 May 2012 13:53:00 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880378!13643321!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11558 invoked from network); 1 May 2012 13:52:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825478" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-JI; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:44 +0100 Message-ID: <1335880366-9873-6-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 5/7] vgabios: Reduce stack usage getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index fff314e..0b8b736 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -914,9 +914,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; // error by default is 0x014f which means supported but error Bit16u result=0x014f; Bit16u ss=get_SS(); - ModeInfoBlock info; ModeInfoListItem *cur_info; Boolean using_lfb; + ModeInfoBlockCompact info; #ifdef DEBUG printf("VBE vbe_biosfn_return_mode_information ES%x DI%x CX%x\n",ES,DI,CX); @@ -933,7 +933,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif - memsetb(ss, &info, 0, sizeof(ModeInfoBlock)); memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); if (using_lfb) { info.NumberOfBanks = 1; @@ -950,6 +949,10 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; info.PhysBasePtr |= inw(VBE_DISPI_IOPORT_DATA); #endif result = 0x4f; + + // copy updates in mode_info_block back + memsetb(ES, DI, 0, sizeof(ModeInfoBlock)); + memcpyb(ES, DI, ss, &info, sizeof(info)); } else { @@ -957,12 +960,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; printf("VBE *NOT* found mode %x\n",CX); #endif } - - if (result == 0x4f) - { - // copy updates in mode_info_block back - memcpyb(ES, DI, ss, &info, sizeof(info)); - } write_word(ss, AX, result); } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVo-0007RC-Qk; Tue, 01 May 2012 13:53:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007QJ-1Z for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:03 +0000 Received: from [85.158.143.35:63248] by server-3.bemta-4.messagelabs.com id FB/6A-05853-EBAEF9F4; Tue, 01 May 2012 13:53:02 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880379!13643323!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11642 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825482" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Kz; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:46 +0100 Message-ID: <1335880366-9873-8-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index a7b06b9..9131721 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; (size_64k > totalMemory)) info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; - if (using_lfb) { - info.NumberOfBanks = 1; - } + /* Windows 8 require this to be 1! */ + info.NumberOfBanks = 1; + if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { info.WinFuncPtr = 0xC0000000UL; *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007QN-Ka; Tue, 01 May 2012 13:53:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVl-0007PN-1m for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:01 +0000 Received: from [85.158.138.51:28349] by server-11.bemta-3.messagelabs.com id 1D/B2-18894-BBAEF9F4; Tue, 01 May 2012 13:52:59 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2284 invoked from network); 1 May 2012 13:52:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825477" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-IL; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:42 +0100 Message-ID: <1335880366-9873-4-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- 1 files changed, 28 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3d42216..35d9866 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -742,6 +742,29 @@ no_vbe_flag: jmp _display_string ASM_END +ASM_START +_size64: + push bp + mov bp, sp + push dx + +; multiply bbp by yres first as results fit in 16bits +; then multiply by xres + mov ax, 8[bp] + mul word 6[bp] + mul word 4[bp] +; divide by 2^19 ceiling result + add ax, #0xffff + adc dx, #7 + mov ax, dx + shr ax, #3 + + pop dx + pop bp + ret +ASM_END + + /** Function 00h - Return VBE Controller Information * * Input: @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; do { + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); + Bit16u max_bpp = dispi_get_max_bpp(); + if ((cur_info->info.XResolution <= dispi_get_max_xres()) && - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { + (cur_info->info.BitsPerPixel <= max_bpp) && + (size_64k <= vbe_info_block.TotalMemory)) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); cur_mode++; -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVo-0007RC-Qk; Tue, 01 May 2012 13:53:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007QJ-1Z for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:03 +0000 Received: from [85.158.143.35:63248] by server-3.bemta-4.messagelabs.com id FB/6A-05853-EBAEF9F4; Tue, 01 May 2012 13:53:02 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880379!13643323!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11642 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825482" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Kz; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:46 +0100 Message-ID: <1335880366-9873-8-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index a7b06b9..9131721 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; (size_64k > totalMemory)) info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; - if (using_lfb) { - info.NumberOfBanks = 1; - } + /* Windows 8 require this to be 1! */ + info.NumberOfBanks = 1; + if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { info.WinFuncPtr = 0xC0000000UL; *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007PO-B3; Tue, 01 May 2012 13:53:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVi-0007PD-PC for xen-devel@lists.xen.org; Tue, 01 May 2012 13:52:58 +0000 Received: from [85.158.138.51:28142] by server-3.bemta-3.messagelabs.com id 4D/9A-04048-9BAEF9F4; Tue, 01 May 2012 13:52:57 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2209 invoked from network); 1 May 2012 13:52:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825475" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Ff; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:39 +0100 Message-ID: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 MIME-Version: 1.0 Subject: [Xen-devel] VGABIOS patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Couple of patches to fix an overflow, optimize a bit and support bigger resolutions using Windows 8. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007PO-B3; Tue, 01 May 2012 13:53:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVi-0007PD-PC for xen-devel@lists.xen.org; Tue, 01 May 2012 13:52:58 +0000 Received: from [85.158.138.51:28142] by server-3.bemta-3.messagelabs.com id 4D/9A-04048-9BAEF9F4; Tue, 01 May 2012 13:52:57 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2209 invoked from network); 1 May 2012 13:52:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825475" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Ff; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:39 +0100 Message-ID: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 MIME-Version: 1.0 Subject: [Xen-devel] VGABIOS patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Couple of patches to fix an overflow, optimize a bit and support bigger resolutions using Windows 8. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007Q9-8O; Tue, 01 May 2012 13:53:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007PE-GO for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:00 +0000 Received: from [85.158.138.51:28360] by server-1.bemta-3.messagelabs.com id 5B/BC-11491-CBAEF9F4; Tue, 01 May 2012 13:53:00 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2344 invoked from network); 1 May 2012 13:52:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825479" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Io; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:43 +0100 Message-ID: <1335880366-9873-5-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 35d9866..fff314e 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; void vbe_biosfn_return_mode_information(AX, CX, ES, DI) Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; { - Bit16u result=0x0100; + // error by default is 0x014f which means supported but error + Bit16u result=0x014f; Bit16u ss=get_SS(); ModeInfoBlock info; ModeInfoListItem *cur_info; @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE *NOT* found mode %x\n",CX); #endif - result = 0x100; } if (result == 0x4f) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVm-0007Q9-8O; Tue, 01 May 2012 13:53:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007PE-GO for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:00 +0000 Received: from [85.158.138.51:28360] by server-1.bemta-3.messagelabs.com id 5B/BC-11491-CBAEF9F4; Tue, 01 May 2012 13:53:00 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2344 invoked from network); 1 May 2012 13:52:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825479" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Io; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:43 +0100 Message-ID: <1335880366-9873-5-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 35d9866..fff314e 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; void vbe_biosfn_return_mode_information(AX, CX, ES, DI) Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; { - Bit16u result=0x0100; + // error by default is 0x014f which means supported but error + Bit16u result=0x014f; Bit16u ss=get_SS(); ModeInfoBlock info; ModeInfoListItem *cur_info; @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE *NOT* found mode %x\n",CX); #endif - result = 0x100; } if (result == 0x4f) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVp-0007RO-6t; Tue, 01 May 2012 13:53:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007Qg-Pq for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:03 +0000 Received: from [85.158.143.35:60330] by server-2.bemta-4.messagelabs.com id 1A/28-17550-FBAEF9F4; Tue, 01 May 2012 13:53:03 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880378!13643321!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11593 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825481" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Jk; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:45 +0100 Message-ID: <1335880366-9873-7-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 6/7] vgabios: Check if mode is currently supported as vesa specifications X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 0b8b736..a7b06b9 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -930,10 +930,22 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; if (cur_info != 0) { + Bit16u max_bpp = dispi_get_max_bpp(); + Bit16u size_64k; + Bit16u totalMemory; + + outw(VBE_DISPI_IOPORT_INDEX, VBE_DISPI_INDEX_VIDEO_MEMORY_64K); + totalMemory = inw(VBE_DISPI_IOPORT_DATA); #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); + size_64k = size64(info.XResolution, info.YResolution, info.BitsPerPixel); + if ((info.XResolution > dispi_get_max_xres()) || + (info.BitsPerPixel > max_bpp) || + (size_64k > totalMemory)) + info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; + if (using_lfb) { info.NumberOfBanks = 1; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVp-0007RO-6t; Tue, 01 May 2012 13:53:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVn-0007Qg-Pq for xen-devel@lists.xen.org; Tue, 01 May 2012 13:53:03 +0000 Received: from [85.158.143.35:60330] by server-2.bemta-4.messagelabs.com id 1A/28-17550-FBAEF9F4; Tue, 01 May 2012 13:53:03 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335880378!13643321!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11593 invoked from network); 1 May 2012 13:53:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:53:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825481" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:53 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-Jk; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:45 +0100 Message-ID: <1335880366-9873-7-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 6/7] vgabios: Check if mode is currently supported as vesa specifications X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 0b8b736..a7b06b9 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -930,10 +930,22 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; if (cur_info != 0) { + Bit16u max_bpp = dispi_get_max_bpp(); + Bit16u size_64k; + Bit16u totalMemory; + + outw(VBE_DISPI_IOPORT_INDEX, VBE_DISPI_INDEX_VIDEO_MEMORY_64K); + totalMemory = inw(VBE_DISPI_IOPORT_DATA); #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); + size_64k = size64(info.XResolution, info.YResolution, info.BitsPerPixel); + if ((info.XResolution > dispi_get_max_xres()) || + (info.BitsPerPixel > max_bpp) || + (size_64k > totalMemory)) + info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; + if (using_lfb) { info.NumberOfBanks = 1; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007Ph-SB; Tue, 01 May 2012 13:53:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVj-0007PE-Jz for xen-devel@lists.xen.org; Tue, 01 May 2012 13:52:59 +0000 Received: from [85.158.138.51:28230] by server-1.bemta-3.messagelabs.com id 29/AC-11491-ABAEF9F4; Tue, 01 May 2012 13:52:58 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2252 invoked from network); 1 May 2012 13:52:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825476" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-HP; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:40 +0100 Message-ID: <1335880366-9873-2-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vgabios.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c index a9dbe00..e0b1ed9 100644 --- a/tools/firmware/vgabios/vgabios.c +++ b/tools/firmware/vgabios/vgabios.c @@ -3811,9 +3811,9 @@ void printf(s) for (i=0; i> (4 * digit)) & 0x000f; if (nibble <= 9) - outb(0xe9, nibble + '0'); + outb(0x12, nibble + '0'); else - outb(0xe9, (nibble - 10) + 'A'); + outb(0x12, (nibble - 10) + 'A'); digit--; } in_format = 0; @@ -3823,7 +3823,7 @@ void printf(s) // } } else { - outb(0xe9, c); + outb(0x12, c); } s ++; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 13:53:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 13:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVk-0007Ph-SB; Tue, 01 May 2012 13:53:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDVj-0007PE-Jz for xen-devel@lists.xen.org; Tue, 01 May 2012 13:52:59 +0000 Received: from [85.158.138.51:28230] by server-1.bemta-3.messagelabs.com id 29/AC-11491-ABAEF9F4; Tue, 01 May 2012 13:52:58 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335880374!13647345!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg0ODc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2252 invoked from network); 1 May 2012 13:52:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 13:52:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="192825476" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 09:52:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 09:52:52 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPDVc-0003ot-HP; Tue, 01 May 2012 14:52:52 +0100 From: Frediano Ziglio To: Frediano Ziglio , xen-devel@lists.xen.org Date: Tue, 1 May 2012 14:52:40 +0100 Message-ID: <1335880366-9873-2-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vgabios.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c index a9dbe00..e0b1ed9 100644 --- a/tools/firmware/vgabios/vgabios.c +++ b/tools/firmware/vgabios/vgabios.c @@ -3811,9 +3811,9 @@ void printf(s) for (i=0; i> (4 * digit)) & 0x000f; if (nibble <= 9) - outb(0xe9, nibble + '0'); + outb(0x12, nibble + '0'); else - outb(0xe9, (nibble - 10) + 'A'); + outb(0x12, (nibble - 10) + 'A'); digit--; } in_format = 0; @@ -3823,7 +3823,7 @@ void printf(s) // } } else { - outb(0xe9, c); + outb(0x12, c); } s ++; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 14:04:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 14:04:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDgR-0000A8-DB; Tue, 01 May 2012 14:04:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDgP-00009Z-JI for xen-devel@lists.xen.org; Tue, 01 May 2012 14:04:01 +0000 Received: from [85.158.143.99:33928] by server-1.bemta-4.messagelabs.com id 3F/7D-20925-05DEF9F4; Tue, 01 May 2012 14:04:00 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335881040!22638988!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7809 invoked from network); 1 May 2012 14:04:00 -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; 1 May 2012 14:04:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12224199" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 14:04:00 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 1 May 2012 15:04:00 +0100 From: Paul Durrant To: Frediano Ziglio , Frediano Ziglio , "xen-devel@lists.xen.org" Date: Tue, 1 May 2012 15:03:58 +0100 Thread-Topic: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one Thread-Index: Ac0noevW2A+vxiocRLyiHWXThF3fFwAARQdQ Message-ID: <291EDFCB1E9E224A99088639C4762022C82E7FA337@LONPMAILBOX01.citrite.net> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> <1335880366-9873-2-git-send-email-frediano.ziglio@citrix.com> In-Reply-To: <1335880366-9873-2-git-send-email-frediano.ziglio@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 Subject: Re: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I'm confused. Last time I looked 0xE9 was the xen debug port. Paul > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Frediano Ziglio > Sent: 01 May 2012 14:53 > To: Frediano Ziglio; xen-devel@lists.xen.org > Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead > of using Bochs one > > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vgabios.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vgabios.c > b/tools/firmware/vgabios/vgabios.c > index a9dbe00..e0b1ed9 100644 > --- a/tools/firmware/vgabios/vgabios.c > +++ b/tools/firmware/vgabios/vgabios.c > @@ -3811,9 +3811,9 @@ void printf(s) > for (i=0; i nibble = (arg >> (4 * digit)) & 0x000f; > if (nibble <= 9) > - outb(0xe9, nibble + '0'); > + outb(0x12, nibble + '0'); > else > - outb(0xe9, (nibble - 10) + 'A'); > + outb(0x12, (nibble - 10) + 'A'); > digit--; > } > in_format = 0; > @@ -3823,7 +3823,7 @@ void printf(s) > // } > } > else { > - outb(0xe9, c); > + outb(0x12, c); > } > s ++; > } > -- > 1.7.5.4 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 14:04:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 14:04:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDgR-0000A8-DB; Tue, 01 May 2012 14:04:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPDgP-00009Z-JI for xen-devel@lists.xen.org; Tue, 01 May 2012 14:04:01 +0000 Received: from [85.158.143.99:33928] by server-1.bemta-4.messagelabs.com id 3F/7D-20925-05DEF9F4; Tue, 01 May 2012 14:04:00 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335881040!22638988!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7809 invoked from network); 1 May 2012 14:04:00 -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; 1 May 2012 14:04:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12224199" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 14:04:00 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 1 May 2012 15:04:00 +0100 From: Paul Durrant To: Frediano Ziglio , Frediano Ziglio , "xen-devel@lists.xen.org" Date: Tue, 1 May 2012 15:03:58 +0100 Thread-Topic: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one Thread-Index: Ac0noevW2A+vxiocRLyiHWXThF3fFwAARQdQ Message-ID: <291EDFCB1E9E224A99088639C4762022C82E7FA337@LONPMAILBOX01.citrite.net> References: <1335880366-9873-1-git-send-email-frediano.ziglio@citrix.com> <1335880366-9873-2-git-send-email-frediano.ziglio@citrix.com> In-Reply-To: <1335880366-9873-2-git-send-email-frediano.ziglio@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 Subject: Re: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I'm confused. Last time I looked 0xE9 was the xen debug port. Paul > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Frediano Ziglio > Sent: 01 May 2012 14:53 > To: Frediano Ziglio; xen-devel@lists.xen.org > Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Xen debug port instead > of using Bochs one > > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vgabios.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vgabios.c > b/tools/firmware/vgabios/vgabios.c > index a9dbe00..e0b1ed9 100644 > --- a/tools/firmware/vgabios/vgabios.c > +++ b/tools/firmware/vgabios/vgabios.c > @@ -3811,9 +3811,9 @@ void printf(s) > for (i=0; i nibble = (arg >> (4 * digit)) & 0x000f; > if (nibble <= 9) > - outb(0xe9, nibble + '0'); > + outb(0x12, nibble + '0'); > else > - outb(0xe9, (nibble - 10) + 'A'); > + outb(0x12, (nibble - 10) + 'A'); > digit--; > } > in_format = 0; > @@ -3823,7 +3823,7 @@ void printf(s) > // } > } > else { > - outb(0xe9, c); > + outb(0x12, c); > } > s ++; > } > -- > 1.7.5.4 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 15:47:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 15:47:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPFHt-0000iC-Ip; Tue, 01 May 2012 15:46:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPFHr-0000i6-Be for xen-devel@lists.xen.org; Tue, 01 May 2012 15:46:47 +0000 Received: from [85.158.139.83:65193] by server-8.bemta-5.messagelabs.com id 5A/FB-26964-66500AF4; Tue, 01 May 2012 15:46:46 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1335887204!26196711!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDExMjc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25516 invoked from network); 1 May 2012 15:46:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 15:46:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="24723395" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 11:46:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 11:46:42 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPFHl-0005fp-W1; Tue, 01 May 2012 16:46:41 +0100 Message-ID: <4FA0051F.6020909@eu.citrix.com> Date: Tue, 1 May 2012 16:45:35 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> In-Reply-To: <31163f014d8a2da9375f.1334150275@Solace> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey Dario, Thanks for the work on this -- this is obviously a very complicated area to try to make sense of. Of course, that makes it even more complicated to review -- sorry this has taken so long. (comments inline) On 11/04/12 14:17, Dario Faggioli wrote: > + > +=item B > + > +use a not better specified (xl-implementation dependant) algorithm > +to try automatically fitting the guest on the host's NUMA nodes Uum, you mean, "Use the default placement algorithm"? :-) We should specify which one this will be here. > + > +/* Automatic placement policies symbols, with the following meaning: > + * NONE : no automatic placement at all; > + * STATIC : explicit nodes specification. > + * FFIT : use the First Fit algorithm for automatic placement; > + * AUTO : an not better specified automatic placement, likely > + * to be implemented as a short circuit to (one of) > + * the above(s); > + */ > +#define NODES_POLICY_NONE 0 > +#define NODES_POLICY_STATIC 1 > +#define NODES_POLICY_FFIT 2 > +#define NODES_POLICY_AUTO 3 This is minor, but it seems like "auto" should be 1, so if we add another policy, the policies are all together, without having to move AUTO around every time. > + > +/* Store the policy for the domain while parsing */ > +static int nodes_policy = NODES_POLICY_DEFAULT; > + > +/* Store the number of nodes to be used while parsing */ > +static int num_nodes_policy = 0; Why are "nodes_policy" and "num_nodes_policy" not passed in along with b_info? > +static int nodes_policy_parse(const char *pol, long int *policy) > +{ > + int i; > + const char *n; > + > + for (i = 0; i< sizeof(nodes_policy_names) / sizeof(nodes_policy_names[0]); i++) { I personally prefer an explicit NODES_POLICY_MAX, but I'll let the libxl maintainers decide on that. > + > + /* Determine how much free memory we want on each of the nodes > + * that will end up in suitable_nodes. Either adding or ignoring > + * the modulus of the integer division should be fine (the total > + * number of nodes should be in the order of tens of them), so > + * let's add it as it should be more safe. > + */ > + memb_node = (memb / (*nodes)) + (memb % (*nodes)); Wouldn't it just be easier to do a "round-up" function here, like this: memb_node = ( (memb + *nodes -1) / (*nodes) ) Also, is it really necessary for a VM to have an equal amount of memory on every node? It seems like it would be better to have 75% on one node and 25% on a second node than to have 25% on four nodes, for example. Furthermore, insisting on an even amount fragments the node memory further -- i.e., if we chose to have 25% on four nodes instead of 75% on one and 25% on another, that will make it harder for another VM to fit on a single node as well. The need for NODES_POLICY_RETRY_DEC is an artifact of the above; if nodes were allowed to be assymetric, you wouldn't need to *decrease* the number of nodes to find *more* memory. > + /* Apply the asked retry policy for the next round. Notice > + * that it would be pointless to increase nodes without also > + * adding some nodes to the map! */ > + *nodes += retry; > + if (retry == NODES_POLICY_RETRY_INC) > + __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry); Hmm -- if I'm reading this right, the only time the nodemap won't be all nodes is if (1) the user specified nodes, or (2) there's a cpumask in effect. If we're going to override that setting, wouldn't it make sense to just expand to all numa nodes? Hmm -- though I suppose what you'd really want to try is adding each node in turn, rather than one at a time (i.e., if the cpus are pinned to nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before trying [1,2,3,4]. But that's starting to get really complicated -- I wonder if it's better to just fail and let the user change the pinnings / configuration node mapping. > + > + /* If a nodemap has been specified, just comply with that. > + * OTOH, if there's no nodemap, rely on cpumap (if any), and > + * fallback to all node if even that is empty. Also consider > + * all the nodes to be valid if only the number (i.e., _how_ > + * _many_ of them instead of _which_ of them) of nodes the > + * domain wants is provided. I feel like this comment could be made more clear... > + * > + * Concering retries, if a specific set of nodes is specified, > + * just try that and give up if we fail. If, instead, a set of > + * CPUs onto which to pin the domain is specified, try first > + * the exact nodes those CPUs belongs to, then also try both > + * a smaller and a bigger number of nodes. The same happens if > + * we just have the number of nodes to be used. Finally, if > + * there is no node-affinity, no cpu-pinning, no number of nodes, > + * start trying with one node and increase at the configured > + * rate (considering all the nodes to be suitable). This should be above the "do {} while()" loop below. (Also, see comment on increasing node map above.) > + > + if (use_cpus>= b_info->max_vcpus) { > + rc = 0; > + break; > + } Hmm -- there's got to be a better way to find out the minimum number of nodes to house a given number of vcpus than just starting at 1 and re-trying until we have enough. > + /* Add one more node and retry fitting the domain */ > + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); Same comment as above. > > + ret = place_domain(&d_config.b_info); > + if (ret == ESRCH || ret == ENOSPC) { > + fprintf(stderr, "failed to place the domain, fallback to all nodes\n"); > + libxl_nodemap_set_any(&d_config.b_info.nodemap); Hmm -- is this the right fallback? I think in general, if the user asks for X to be done, and X cannot be done for whatever reason, the right thing is to tell the user that X cannot be done and let them sort it out, rather than resorting to Y (unless that's been set). Is it the case that if any node placement fails, then they'll all fail? Or to put it the other way, is it the case that if there is *some* placement, that any placement algorithm will eventually find it? If so, then I think this fallback may make sense, as there's nothing for the user to really do. > diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c > --- a/xen/arch/x86/numa.c > +++ b/xen/arch/x86/numa.c > @@ -365,10 +365,11 @@ static void dump_numa(unsigned char key) > > for_each_online_node(i) { > paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT; > - printk("idx%d -> NODE%d start->%lu size->%lu\n", > + printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n", > i, NODE_DATA(i)->node_id, > NODE_DATA(i)->node_start_pfn, > - NODE_DATA(i)->node_spanned_pages); > + NODE_DATA(i)->node_spanned_pages, > + avail_node_heap_pages(i)); > /* sanity check phys_to_nid() */ > printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa, phys_to_nid(pa), > NODE_DATA(i)->node_id); This should be in its own patch. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 15:47:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 15:47:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPFHt-0000iC-Ip; Tue, 01 May 2012 15:46:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPFHr-0000i6-Be for xen-devel@lists.xen.org; Tue, 01 May 2012 15:46:47 +0000 Received: from [85.158.139.83:65193] by server-8.bemta-5.messagelabs.com id 5A/FB-26964-66500AF4; Tue, 01 May 2012 15:46:46 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1335887204!26196711!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDExMjc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25516 invoked from network); 1 May 2012 15:46:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 15:46:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330923600"; d="scan'208";a="24723395" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 11:46:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 11:46:42 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPFHl-0005fp-W1; Tue, 01 May 2012 16:46:41 +0100 Message-ID: <4FA0051F.6020909@eu.citrix.com> Date: Tue, 1 May 2012 16:45:35 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> In-Reply-To: <31163f014d8a2da9375f.1334150275@Solace> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey Dario, Thanks for the work on this -- this is obviously a very complicated area to try to make sense of. Of course, that makes it even more complicated to review -- sorry this has taken so long. (comments inline) On 11/04/12 14:17, Dario Faggioli wrote: > + > +=item B > + > +use a not better specified (xl-implementation dependant) algorithm > +to try automatically fitting the guest on the host's NUMA nodes Uum, you mean, "Use the default placement algorithm"? :-) We should specify which one this will be here. > + > +/* Automatic placement policies symbols, with the following meaning: > + * NONE : no automatic placement at all; > + * STATIC : explicit nodes specification. > + * FFIT : use the First Fit algorithm for automatic placement; > + * AUTO : an not better specified automatic placement, likely > + * to be implemented as a short circuit to (one of) > + * the above(s); > + */ > +#define NODES_POLICY_NONE 0 > +#define NODES_POLICY_STATIC 1 > +#define NODES_POLICY_FFIT 2 > +#define NODES_POLICY_AUTO 3 This is minor, but it seems like "auto" should be 1, so if we add another policy, the policies are all together, without having to move AUTO around every time. > + > +/* Store the policy for the domain while parsing */ > +static int nodes_policy = NODES_POLICY_DEFAULT; > + > +/* Store the number of nodes to be used while parsing */ > +static int num_nodes_policy = 0; Why are "nodes_policy" and "num_nodes_policy" not passed in along with b_info? > +static int nodes_policy_parse(const char *pol, long int *policy) > +{ > + int i; > + const char *n; > + > + for (i = 0; i< sizeof(nodes_policy_names) / sizeof(nodes_policy_names[0]); i++) { I personally prefer an explicit NODES_POLICY_MAX, but I'll let the libxl maintainers decide on that. > + > + /* Determine how much free memory we want on each of the nodes > + * that will end up in suitable_nodes. Either adding or ignoring > + * the modulus of the integer division should be fine (the total > + * number of nodes should be in the order of tens of them), so > + * let's add it as it should be more safe. > + */ > + memb_node = (memb / (*nodes)) + (memb % (*nodes)); Wouldn't it just be easier to do a "round-up" function here, like this: memb_node = ( (memb + *nodes -1) / (*nodes) ) Also, is it really necessary for a VM to have an equal amount of memory on every node? It seems like it would be better to have 75% on one node and 25% on a second node than to have 25% on four nodes, for example. Furthermore, insisting on an even amount fragments the node memory further -- i.e., if we chose to have 25% on four nodes instead of 75% on one and 25% on another, that will make it harder for another VM to fit on a single node as well. The need for NODES_POLICY_RETRY_DEC is an artifact of the above; if nodes were allowed to be assymetric, you wouldn't need to *decrease* the number of nodes to find *more* memory. > + /* Apply the asked retry policy for the next round. Notice > + * that it would be pointless to increase nodes without also > + * adding some nodes to the map! */ > + *nodes += retry; > + if (retry == NODES_POLICY_RETRY_INC) > + __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry); Hmm -- if I'm reading this right, the only time the nodemap won't be all nodes is if (1) the user specified nodes, or (2) there's a cpumask in effect. If we're going to override that setting, wouldn't it make sense to just expand to all numa nodes? Hmm -- though I suppose what you'd really want to try is adding each node in turn, rather than one at a time (i.e., if the cpus are pinned to nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before trying [1,2,3,4]. But that's starting to get really complicated -- I wonder if it's better to just fail and let the user change the pinnings / configuration node mapping. > + > + /* If a nodemap has been specified, just comply with that. > + * OTOH, if there's no nodemap, rely on cpumap (if any), and > + * fallback to all node if even that is empty. Also consider > + * all the nodes to be valid if only the number (i.e., _how_ > + * _many_ of them instead of _which_ of them) of nodes the > + * domain wants is provided. I feel like this comment could be made more clear... > + * > + * Concering retries, if a specific set of nodes is specified, > + * just try that and give up if we fail. If, instead, a set of > + * CPUs onto which to pin the domain is specified, try first > + * the exact nodes those CPUs belongs to, then also try both > + * a smaller and a bigger number of nodes. The same happens if > + * we just have the number of nodes to be used. Finally, if > + * there is no node-affinity, no cpu-pinning, no number of nodes, > + * start trying with one node and increase at the configured > + * rate (considering all the nodes to be suitable). This should be above the "do {} while()" loop below. (Also, see comment on increasing node map above.) > + > + if (use_cpus>= b_info->max_vcpus) { > + rc = 0; > + break; > + } Hmm -- there's got to be a better way to find out the minimum number of nodes to house a given number of vcpus than just starting at 1 and re-trying until we have enough. > + /* Add one more node and retry fitting the domain */ > + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); Same comment as above. > > + ret = place_domain(&d_config.b_info); > + if (ret == ESRCH || ret == ENOSPC) { > + fprintf(stderr, "failed to place the domain, fallback to all nodes\n"); > + libxl_nodemap_set_any(&d_config.b_info.nodemap); Hmm -- is this the right fallback? I think in general, if the user asks for X to be done, and X cannot be done for whatever reason, the right thing is to tell the user that X cannot be done and let them sort it out, rather than resorting to Y (unless that's been set). Is it the case that if any node placement fails, then they'll all fail? Or to put it the other way, is it the case that if there is *some* placement, that any placement algorithm will eventually find it? If so, then I think this fallback may make sense, as there's nothing for the user to really do. > diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c > --- a/xen/arch/x86/numa.c > +++ b/xen/arch/x86/numa.c > @@ -365,10 +365,11 @@ static void dump_numa(unsigned char key) > > for_each_online_node(i) { > paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT; > - printk("idx%d -> NODE%d start->%lu size->%lu\n", > + printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n", > i, NODE_DATA(i)->node_id, > NODE_DATA(i)->node_start_pfn, > - NODE_DATA(i)->node_spanned_pages); > + NODE_DATA(i)->node_spanned_pages, > + avail_node_heap_pages(i)); > /* sanity check phys_to_nid() */ > printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa, phys_to_nid(pa), > NODE_DATA(i)->node_id); This should be in its own patch. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 16:43:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 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 ) id 1SPGAD-0001P6-VE; Tue, 01 May 2012 16:42:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGAC-0001P1-RD for xen-devel@lists.xensource.com; Tue, 01 May 2012 16:42:57 +0000 Received: from [85.158.138.51:8122] by server-5.bemta-3.messagelabs.com id 4E/16-17113-09210AF4; Tue, 01 May 2012 16:42:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335890573!24648901!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13265 invoked from network); 1 May 2012 16:42:55 -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; 1 May 2012 16:42:55 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41Ggoqq021917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 16:42:51 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 q41Ggnrw023621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 16:42:50 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 q41GgntM018261; Tue, 1 May 2012 11:42:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 09:42:48 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A3B7A40357; Tue, 1 May 2012 12:37:07 -0400 (EDT) Date: Tue, 1 May 2012 12:37:07 -0400 From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com Message-ID: <20120501163707.GA8741@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: > Changelog v5 [since v4]: > - used populate_physmap, fixed bugs. > [v2-v4: not posted] > - reworked the code in setup.c to work properly. > [v1: https://lkml.org/lkml/2012/3/30/492] > - initial patchset One bug I found was that with 'dom0_mem=max:1G' (with and without these patches) I would get a bunch of (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine I ran on it. I figured it out that the difference was in the ACPI tables that are allocated - and that those regions - even though are returned back to the hypervisor, cannot be repopulated. I can't find the actual exact piece of code in the hypervisor to pin-point and say "Aha". What I did was use the same metrix that the hypervisor uses to figure out whether to deny the guest ballooning up - checking the d->tot_pages against t->max_pages. For that the XENMEM_current_reservation is used. >From e4568b678455f68d374277319fb5cc41f11b6c4f Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Thu, 26 Apr 2012 22:11:08 -0400 Subject: [PATCH] xen/setup: Cap amount to populate based on current tot_pages count. Previous to this patch we would try to populate exactly up to xen_released_pages number (so the ones that we released), but that is incorrect as there are some pages that we thought were released but in actuality were shared. Depending on the platform it could be small amounts - 2 pages, but some had much higher - 17. As such, lets use the XENMEM_current_reservation to get the exact count of pages we are using, subtract it from nr_pages and use the lesser of this and xen_released_pages to populate back. This fixes errors such as: (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/setup.c | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 506a3e6..8e7dcfd 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -287,7 +287,15 @@ static unsigned long __init xen_get_max_pages(void) return min(max_pages, MAX_DOMAIN_PAGES); } - +static unsigned long xen_get_current_pages(void) +{ + domid_t domid = DOMID_SELF; + int ret; + ret = HYPERVISOR_memory_op(XENMEM_current_reservation, &domid); + if (ret > 0) + return ret; + return 0; +} static void xen_align_and_add_e820_region(u64 start, u64 size, int type) { u64 end = start + size; @@ -358,7 +366,11 @@ char * __init xen_memory_setup(void) /* * Populate back the non-RAM pages and E820 gaps that had been - * released. */ + * released. But cap it as certain regions cannot be repopulated. + */ + if (xen_get_current_pages()) + xen_released_pages = min(max_pfn - xen_get_current_pages(), + xen_released_pages); populated = xen_populate_chunk(map, memmap.nr_entries, max_pfn, &last_pfn, xen_released_pages); -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 16:43:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 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 ) id 1SPGAD-0001P6-VE; Tue, 01 May 2012 16:42:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGAC-0001P1-RD for xen-devel@lists.xensource.com; Tue, 01 May 2012 16:42:57 +0000 Received: from [85.158.138.51:8122] by server-5.bemta-3.messagelabs.com id 4E/16-17113-09210AF4; Tue, 01 May 2012 16:42:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335890573!24648901!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13265 invoked from network); 1 May 2012 16:42:55 -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; 1 May 2012 16:42:55 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41Ggoqq021917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 16:42:51 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 q41Ggnrw023621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 16:42:50 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 q41GgntM018261; Tue, 1 May 2012 11:42:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 09:42:48 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A3B7A40357; Tue, 1 May 2012 12:37:07 -0400 (EDT) Date: Tue, 1 May 2012 12:37:07 -0400 From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, JBeulich@suse.com Message-ID: <20120501163707.GA8741@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: > Changelog v5 [since v4]: > - used populate_physmap, fixed bugs. > [v2-v4: not posted] > - reworked the code in setup.c to work properly. > [v1: https://lkml.org/lkml/2012/3/30/492] > - initial patchset One bug I found was that with 'dom0_mem=max:1G' (with and without these patches) I would get a bunch of (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine I ran on it. I figured it out that the difference was in the ACPI tables that are allocated - and that those regions - even though are returned back to the hypervisor, cannot be repopulated. I can't find the actual exact piece of code in the hypervisor to pin-point and say "Aha". What I did was use the same metrix that the hypervisor uses to figure out whether to deny the guest ballooning up - checking the d->tot_pages against t->max_pages. For that the XENMEM_current_reservation is used. >From e4568b678455f68d374277319fb5cc41f11b6c4f Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Thu, 26 Apr 2012 22:11:08 -0400 Subject: [PATCH] xen/setup: Cap amount to populate based on current tot_pages count. Previous to this patch we would try to populate exactly up to xen_released_pages number (so the ones that we released), but that is incorrect as there are some pages that we thought were released but in actuality were shared. Depending on the platform it could be small amounts - 2 pages, but some had much higher - 17. As such, lets use the XENMEM_current_reservation to get the exact count of pages we are using, subtract it from nr_pages and use the lesser of this and xen_released_pages to populate back. This fixes errors such as: (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/setup.c | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 506a3e6..8e7dcfd 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -287,7 +287,15 @@ static unsigned long __init xen_get_max_pages(void) return min(max_pages, MAX_DOMAIN_PAGES); } - +static unsigned long xen_get_current_pages(void) +{ + domid_t domid = DOMID_SELF; + int ret; + ret = HYPERVISOR_memory_op(XENMEM_current_reservation, &domid); + if (ret > 0) + return ret; + return 0; +} static void xen_align_and_add_e820_region(u64 start, u64 size, int type) { u64 end = start + size; @@ -358,7 +366,11 @@ char * __init xen_memory_setup(void) /* * Populate back the non-RAM pages and E820 gaps that had been - * released. */ + * released. But cap it as certain regions cannot be repopulated. + */ + if (xen_get_current_pages()) + xen_released_pages = min(max_pfn - xen_get_current_pages(), + xen_released_pages); populated = xen_populate_chunk(map, memmap.nr_entries, max_pfn, &last_pfn, xen_released_pages); -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 16:53:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 16: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 ) id 1SPGJv-0001cl-Ej; Tue, 01 May 2012 16:52:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGJu-0001cg-2k for xen-devel@lists.xensource.com; Tue, 01 May 2012 16:52:58 +0000 Received: from [193.109.254.147:22711] by server-6.bemta-14.messagelabs.com id E9/AF-04960-9E410AF4; Tue, 01 May 2012 16:52:57 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1335891175!323939!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7703 invoked from network); 1 May 2012 16:52:56 -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; 1 May 2012 16:52:56 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41GqruA031126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 16:52:54 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 q41Gqqw6020140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 16:52:52 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 q41Gqq00024483; Tue, 1 May 2012 11:52:52 -0500 MIME-Version: 1.0 Message-ID: Date: Tue, 1 May 2012 09:52:40 -0700 (PDT) From: Dan Magenheimer To: Jana Saout , xen-devel@lists.xensource.com References: <1335728058.4574.18.camel@localhost> In-Reply-To: <1335728058.4574.18.camel@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Jana Saout [mailto:jana@saout.de] > Subject: [Xen-devel] Self-ballooning question / cache issue > > Hello, > > I have been testing autoballooning on a production Xen system today > (with cleancache + frontswap on Xen-provided tmem). For most of the > idle or CPU-centric VMs it seems to work just fine. > > However, on one of the web-serving VMs, there is also a cron job running > every few minutes which runs over a rather large directory (plus, this > directory is on OCFS2 so this is a rather time-consuming process). Now, > if the dcache/inode cache is large enough (which it was before, since > the VM got allocated 4 GB and is only using 1-2 most of the time), this > was not a problem. > > Now, with self-ballooning, the memory gets reduced to somewhat between 1 > and 2 GB and after a few minutes the load is going through the ceiling. > Jobs reading through said directories are piling up (stuck in D state, > waiting for the FS). And most of the time kswapd is spinning at 100%. > If I deactivate self-ballooning and assign the VM 3 GB, everything goes > back to normal after a few minutes. (and, "ls -l" on said directory is > served from the cache again). > > Now, I am aware that said problem is a self-made one. The directory was > not actually supposed to contain that many files and the next job not > waiting for the previous job to terminate is cause for trouble - but > still, I would consider this a possible regression since it seems > self-ballooning is constantly thrashing the VM's caches. Not all caches > can be saved in cleancache. > > What about an additional tunable: a user-specified amount of pages that > is added on top of the computed target number of pages? This way, one > could manually reserve a bit more room for other types of caches. (in > fact, I might try this myself, since it shouldn't be too hard to do so) > > Any opinions on this? Hi Jana -- Thanks for doing this analysis. While your workload is a bit unusual, I agree that you have exposed a problem that will need to be resolved. It was observed three years ago that the next "frontend" for tmem could handle a cleancache-like mechanism for the dcache. Until now, I had thought that this was purely optional and would yield only a small performance improvement. But with your workload, I think the combination of the facts that selfballooning is forcing out dcache entries and they aren't being saved in tmem is resulting in the problem you are seeing. I think the best solution for this will be a "cleandcache" patch in the Linux guest... but given how long it has taken to get cleancache and frontswap into the kernel (and the fact that a working cleandcache patch doesn't even exist yet), I wouldn't hold my breath ;-) I will put it on the "to do" list though. Your idea of the tunable is interesting (and patches are always welcome!) but I am skeptical that it will solve the problem since I would guess the Linux kernel is shrinking dcache proportional to the size of the page cache. So adding more RAM with your "user-specified amount of pages that is added on top of the computed target number of pages", the RAM will still be shared across all caches and only some small portion of the added RAM will likely be used for dcache. However, if you have a chance to try it, I would be interested in your findings. Note that you already can set a permanent floor for selfballooning ("min_usable_mb") or, of course, just turn off selfballooning altogether. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 16:53:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 16: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 ) id 1SPGJv-0001cl-Ej; Tue, 01 May 2012 16:52:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGJu-0001cg-2k for xen-devel@lists.xensource.com; Tue, 01 May 2012 16:52:58 +0000 Received: from [193.109.254.147:22711] by server-6.bemta-14.messagelabs.com id E9/AF-04960-9E410AF4; Tue, 01 May 2012 16:52:57 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1335891175!323939!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7703 invoked from network); 1 May 2012 16:52:56 -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; 1 May 2012 16:52:56 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41GqruA031126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 16:52:54 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 q41Gqqw6020140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 16:52:52 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 q41Gqq00024483; Tue, 1 May 2012 11:52:52 -0500 MIME-Version: 1.0 Message-ID: Date: Tue, 1 May 2012 09:52:40 -0700 (PDT) From: Dan Magenheimer To: Jana Saout , xen-devel@lists.xensource.com References: <1335728058.4574.18.camel@localhost> In-Reply-To: <1335728058.4574.18.camel@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Jana Saout [mailto:jana@saout.de] > Subject: [Xen-devel] Self-ballooning question / cache issue > > Hello, > > I have been testing autoballooning on a production Xen system today > (with cleancache + frontswap on Xen-provided tmem). For most of the > idle or CPU-centric VMs it seems to work just fine. > > However, on one of the web-serving VMs, there is also a cron job running > every few minutes which runs over a rather large directory (plus, this > directory is on OCFS2 so this is a rather time-consuming process). Now, > if the dcache/inode cache is large enough (which it was before, since > the VM got allocated 4 GB and is only using 1-2 most of the time), this > was not a problem. > > Now, with self-ballooning, the memory gets reduced to somewhat between 1 > and 2 GB and after a few minutes the load is going through the ceiling. > Jobs reading through said directories are piling up (stuck in D state, > waiting for the FS). And most of the time kswapd is spinning at 100%. > If I deactivate self-ballooning and assign the VM 3 GB, everything goes > back to normal after a few minutes. (and, "ls -l" on said directory is > served from the cache again). > > Now, I am aware that said problem is a self-made one. The directory was > not actually supposed to contain that many files and the next job not > waiting for the previous job to terminate is cause for trouble - but > still, I would consider this a possible regression since it seems > self-ballooning is constantly thrashing the VM's caches. Not all caches > can be saved in cleancache. > > What about an additional tunable: a user-specified amount of pages that > is added on top of the computed target number of pages? This way, one > could manually reserve a bit more room for other types of caches. (in > fact, I might try this myself, since it shouldn't be too hard to do so) > > Any opinions on this? Hi Jana -- Thanks for doing this analysis. While your workload is a bit unusual, I agree that you have exposed a problem that will need to be resolved. It was observed three years ago that the next "frontend" for tmem could handle a cleancache-like mechanism for the dcache. Until now, I had thought that this was purely optional and would yield only a small performance improvement. But with your workload, I think the combination of the facts that selfballooning is forcing out dcache entries and they aren't being saved in tmem is resulting in the problem you are seeing. I think the best solution for this will be a "cleandcache" patch in the Linux guest... but given how long it has taken to get cleancache and frontswap into the kernel (and the fact that a working cleandcache patch doesn't even exist yet), I wouldn't hold my breath ;-) I will put it on the "to do" list though. Your idea of the tunable is interesting (and patches are always welcome!) but I am skeptical that it will solve the problem since I would guess the Linux kernel is shrinking dcache proportional to the size of the page cache. So adding more RAM with your "user-specified amount of pages that is added on top of the computed target number of pages", the RAM will still be shared across all caches and only some small portion of the added RAM will likely be used for dcache. However, if you have a chance to try it, I would be interested in your findings. Note that you already can set a permanent floor for selfballooning ("min_usable_mb") or, of course, just turn off selfballooning altogether. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:10:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:10:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGaD-0001qi-6b; Tue, 01 May 2012 17:09:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGaB-0001qd-OC for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:09:48 +0000 Received: from [85.158.143.35:64782] by server-3.bemta-4.messagelabs.com id A4/02-05853-BD810AF4; Tue, 01 May 2012 17:09:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335892184!9405690!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8961 invoked from network); 1 May 2012 17:09:45 -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; 1 May 2012 17:09:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12228609" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 17:09:42 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 18:09:42 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPGa6-0001X9-IN; Tue, 01 May 2012 17:09:42 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPGa6-0007Uj-Bo; Tue, 01 May 2012 18:09:42 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 18:09:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12768: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12768 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12768/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-xl 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-pv 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-rhel6hvm-amd 5 xen-boot fail in 12764 REGR. vs. 12694 test-i386-i386-pv 5 xen-boot fail in 12762 REGR. vs. 12694 Tests which are failing intermittently (not blocking): test-i386-i386-xl 3 host-install(3) broken pass in 12764 test-i386-i386-pv 3 host-install(3) broken pass in 12762 test-amd64-i386-xl 3 host-install(3) broken pass in 12764 test-amd64-i386-pv 3 host-install(3) broken pass in 12764 test-amd64-i386-xl-multivcpu 3 host-install(3) broken pass in 12764 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken pass in 12764 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 12764 pass in 12768 test-amd64-amd64-xl-sedf 12 guest-saverestore.2 fail in 12762 pass in 12768 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop 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-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl broken test-i386-i386-xl broken test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu broken test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:10:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:10:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGaD-0001qi-6b; Tue, 01 May 2012 17:09:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGaB-0001qd-OC for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:09:48 +0000 Received: from [85.158.143.35:64782] by server-3.bemta-4.messagelabs.com id A4/02-05853-BD810AF4; Tue, 01 May 2012 17:09:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335892184!9405690!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8961 invoked from network); 1 May 2012 17:09:45 -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; 1 May 2012 17:09:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12228609" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 17:09:42 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 18:09:42 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPGa6-0001X9-IN; Tue, 01 May 2012 17:09:42 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPGa6-0007Uj-Bo; Tue, 01 May 2012 18:09:42 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 18:09:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12768: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12768 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12768/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-xl 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-pv 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 12764 REGR. vs. 12694 test-amd64-i386-rhel6hvm-amd 5 xen-boot fail in 12764 REGR. vs. 12694 test-i386-i386-pv 5 xen-boot fail in 12762 REGR. vs. 12694 Tests which are failing intermittently (not blocking): test-i386-i386-xl 3 host-install(3) broken pass in 12764 test-i386-i386-pv 3 host-install(3) broken pass in 12762 test-amd64-i386-xl 3 host-install(3) broken pass in 12764 test-amd64-i386-pv 3 host-install(3) broken pass in 12764 test-amd64-i386-xl-multivcpu 3 host-install(3) broken pass in 12764 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken pass in 12764 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 12764 pass in 12768 test-amd64-amd64-xl-sedf 12 guest-saverestore.2 fail in 12762 pass in 12768 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop 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-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl broken test-i386-i386-xl broken test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu broken test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuY-00026g-RN; Tue, 01 May 2012 17:30:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuX-00026T-AG for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:30:49 +0000 Received: from [85.158.143.35:14480] by server-3.bemta-4.messagelabs.com id A9/FB-05853-8CD10AF4; Tue, 01 May 2012 17:30:48 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1335893446!14364519!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27343 invoked from network); 1 May 2012 17:30:48 -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; 1 May 2012 17:30:48 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41HUgIN009509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 17:30:43 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 q41HUgTb015994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 17:30:42 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 q41HUfZl001493; Tue, 1 May 2012 12:30:42 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 10:30:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5BCD040357; Tue, 1 May 2012 13:25:00 -0400 (EDT) From: Konrad Rzeszutek Wilk To: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 1 May 2012 13:24:53 -0400 Message-Id: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/2] Export acpi_processor_set_pdc to modules. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The Xen ACPI module calls acpi_processor_set_pdc for ACPI IDs for CPUs that are not visible to an instance of a running Linux kernel. Meaning it calls them on the ones that the generic code has no control over. But without this being exported the module will fail to compile. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/acpi/processor_core.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index c850de4..7c7c2d9 100644 --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -352,6 +352,7 @@ void __cpuinit acpi_processor_set_pdc(acpi_handle handle) kfree(obj_list->pointer); kfree(obj_list); } +EXPORT_SYMBOL_GPL(acpi_processor_set_pdc); static acpi_status __init early_init_pdc(acpi_handle handle, u32 lvl, void *context, void **rv) -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuY-00026g-RN; Tue, 01 May 2012 17:30:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuX-00026T-AG for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:30:49 +0000 Received: from [85.158.143.35:14480] by server-3.bemta-4.messagelabs.com id A9/FB-05853-8CD10AF4; Tue, 01 May 2012 17:30:48 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1335893446!14364519!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27343 invoked from network); 1 May 2012 17:30:48 -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; 1 May 2012 17:30:48 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41HUgIN009509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 17:30:43 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 q41HUgTb015994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 17:30:42 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 q41HUfZl001493; Tue, 1 May 2012 12:30:42 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 10:30:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5BCD040357; Tue, 1 May 2012 13:25:00 -0400 (EDT) From: Konrad Rzeszutek Wilk To: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 1 May 2012 13:24:53 -0400 Message-Id: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/2] Export acpi_processor_set_pdc to modules. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The Xen ACPI module calls acpi_processor_set_pdc for ACPI IDs for CPUs that are not visible to an instance of a running Linux kernel. Meaning it calls them on the ones that the generic code has no control over. But without this being exported the module will fail to compile. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/acpi/processor_core.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index c850de4..7c7c2d9 100644 --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -352,6 +352,7 @@ void __cpuinit acpi_processor_set_pdc(acpi_handle handle) kfree(obj_list->pointer); kfree(obj_list); } +EXPORT_SYMBOL_GPL(acpi_processor_set_pdc); static acpi_status __init early_init_pdc(acpi_handle handle, u32 lvl, void *context, void **rv) -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuY-00026Y-Ew; Tue, 01 May 2012 17:30:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuW-00026O-GJ for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:30:48 +0000 Received: from [85.158.143.99:9237] by server-1.bemta-4.messagelabs.com id 02/ED-20925-7CD10AF4; Tue, 01 May 2012 17:30:47 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335893445!25126566!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26538 invoked from network); 1 May 2012 17:30:47 -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; 1 May 2012 17:30:47 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41HUgtU003012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 17:30:43 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 q41HUg8W013180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 17:30:42 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41HUfSJ016959; Tue, 1 May 2012 12:30:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 10:30:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6454C4032C; Tue, 1 May 2012 13:25:00 -0400 (EDT) From: Konrad Rzeszutek Wilk To: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 1 May 2012 13:24:54 -0400 Message-Id: <1335893094-6904-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> References: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/2] xen/acpi: Execute _PDC on CPUs past the ones seen to the guest. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org acpi_early_processor_set_pdc does this (executes _PDC), but it cannot do it for vCPUS that are past the currently available vCPUS (so dom0_max_vcpus=X is used). We can easily find if that is the case by seeing if we get the same failure as the generic code and if so run _PDC ourselves. We also (by doing some other hypercalls) know how many physical CPUs there are - which the acpi_get_cpuid can't - as it bands the amount of CPUs up to 'cpu_possible()' which has been influenced by 'dom0_max_vcpus=X' flag. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/xen/xen-acpi-processor.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 0b48579..bb9f711 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -323,7 +323,7 @@ static unsigned int __init get_max_acpi_id(void) /* * The read_acpi_id and check_acpi_ids are there to support the Xen * oddity of virtual CPUs != physical CPUs in the initial domain. - * The user can supply 'xen_max_vcpus=X' on the Xen hypervisor line + * The user can supply 'dom0_max_vcps=X' on the Xen hypervisor line * which will band the amount of CPUs the initial domain can see. * In general that is OK, except it plays havoc with any of the * for_each_[present|online]_cpu macros which are banded to the virtual @@ -374,6 +374,14 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) pr_debug(DRV_NAME "ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk); + /* acpi_early_processor_set_pdc does this, but it cannot do it for vCPUS + * that are past the currently available vCPUS (so dom0_max_vcpus=X is + * used). We can easily find if that is the case by seeing if we get the + * same failure as the generic code and if so run _PDC ourselves. + */ + if (acpi_get_cpuid(handle, (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0, acpi_id) == -1) + acpi_processor_set_pdc(handle); + status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); if (ACPI_FAILURE(status)) { if (!pblk) -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 17:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 17:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuY-00026Y-Ew; Tue, 01 May 2012 17:30:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPGuW-00026O-GJ for xen-devel@lists.xensource.com; Tue, 01 May 2012 17:30:48 +0000 Received: from [85.158.143.99:9237] by server-1.bemta-4.messagelabs.com id 02/ED-20925-7CD10AF4; Tue, 01 May 2012 17:30:47 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335893445!25126566!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26538 invoked from network); 1 May 2012 17:30:47 -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; 1 May 2012 17:30:47 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41HUgtU003012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 17:30:43 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 q41HUg8W013180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 17:30:42 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41HUfSJ016959; Tue, 1 May 2012 12:30:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 10:30:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6454C4032C; Tue, 1 May 2012 13:25:00 -0400 (EDT) From: Konrad Rzeszutek Wilk To: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 1 May 2012 13:24:54 -0400 Message-Id: <1335893094-6904-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> References: <1335893094-6904-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/2] xen/acpi: Execute _PDC on CPUs past the ones seen to the guest. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org acpi_early_processor_set_pdc does this (executes _PDC), but it cannot do it for vCPUS that are past the currently available vCPUS (so dom0_max_vcpus=X is used). We can easily find if that is the case by seeing if we get the same failure as the generic code and if so run _PDC ourselves. We also (by doing some other hypercalls) know how many physical CPUs there are - which the acpi_get_cpuid can't - as it bands the amount of CPUs up to 'cpu_possible()' which has been influenced by 'dom0_max_vcpus=X' flag. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/xen/xen-acpi-processor.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 0b48579..bb9f711 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -323,7 +323,7 @@ static unsigned int __init get_max_acpi_id(void) /* * The read_acpi_id and check_acpi_ids are there to support the Xen * oddity of virtual CPUs != physical CPUs in the initial domain. - * The user can supply 'xen_max_vcpus=X' on the Xen hypervisor line + * The user can supply 'dom0_max_vcps=X' on the Xen hypervisor line * which will band the amount of CPUs the initial domain can see. * In general that is OK, except it plays havoc with any of the * for_each_[present|online]_cpu macros which are banded to the virtual @@ -374,6 +374,14 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) pr_debug(DRV_NAME "ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk); + /* acpi_early_processor_set_pdc does this, but it cannot do it for vCPUS + * that are past the currently available vCPUS (so dom0_max_vcpus=X is + * used). We can easily find if that is the case by seeing if we get the + * same failure as the generic code and if so run _PDC ourselves. + */ + if (acpi_get_cpuid(handle, (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0, acpi_id) == -1) + acpi_processor_set_pdc(handle); + status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); if (ACPI_FAILURE(status)) { if (!pblk) -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:04:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19: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 ) id 1SPIMa-0002iz-9q; Tue, 01 May 2012 19:03:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPIMY-0002iu-Cg for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:03:50 +0000 Received: from [85.158.143.35:14375] by server-3.bemta-4.messagelabs.com id D8/E2-05853-59330AF4; Tue, 01 May 2012 19:03:49 +0000 X-Env-Sender: julian.pidancet@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1335899028!13327530!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.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30570 invoked from network); 1 May 2012 19:03:48 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 19:03:48 -0000 Received: by eekc13 with SMTP id c13so1514669eek.30 for ; Tue, 01 May 2012 12:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NRjGXFIBRzr//FKnK+wWXqLXrfosykHomrujGASfT4Q=; b=dqEglME1WDRbA7QZ0y6aFbsFl514fcRPwVRrbWXnAu56QKEBqjqFLcUTKJgm3iINeh uf3FpsGUyVO2SIDfrnUh4qU7Gy0+r372PWaQANiYWWQRzVrMf7v/cB0dGIsT6634KvHv +WLD3VVYJUjV3KgfNNOVBJgzBOttzQwfsq7NVF6t7OE5ub4zMh2eu8cPhSGoCL6w5WX9 6+IlGA5yKbOhFll+sv3oRK3Ldb6WY+4PM56oZMM9vdDUTkR8OMGFq4aNOEhB2dBz6ef2 5P+k486ppw9d67SdwE7ZYCIElIfmqtIdyrDxmWSlrAB7MJh2EIM/XX+ocykEQsxc9fWk sgXA== Received: by 10.213.29.2 with SMTP id o2mr593730ebc.53.1335899028028; Tue, 01 May 2012 12:03:48 -0700 (PDT) Received: from [192.168.1.110] (188-223-88-44.zone14.bethere.co.uk. [188.223.88.44]) by mx.google.com with ESMTPS id r44sm94748423eef.2.2012.05.01.12.03.45 (version=SSLv3 cipher=OTHER); Tue, 01 May 2012 12:03:47 -0700 (PDT) Message-ID: <4FA03DC8.6040204@gmail.com> Date: Tue, 01 May 2012 20:47:20 +0100 From: Julian Pidancet User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120402 Thunderbird/10.0.3 MIME-Version: 1.0 To: Tim Deegan References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> In-Reply-To: <20120322112612.GG37468@ocelot.phlegethon.org> Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/22/12 11:26, Tim Deegan wrote: > Hi, > > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote: >> My impression from the earlier discussions is that we're pasing largish >> blobs of binary BIOS goop around, which aren't suitable to go into >> xenstore. Dropping them in memory where HVMloader can pick them up >> seems reasonable. >> >> All the control-path stuff - what the blobs are, where they are &c, >> should go through Xenstore, though. > > So having looked at the code, I think the module system is really > overkill - AIUI all the things you're talking about passing through are > ACPI tables, which have their own length fields internally. So all > you'd need to do is have a type code and an address in xenstore > somewhere, the same way we pass a type code and a string for the other > BIOS customizations. > > Cheers, > > Tim. Hi, I don't think ACPI and SMBIOS firmware passthrough are the only use cases here. The module architecture could also be used to pass the BIOS and Option ROMs to hvmloader. The toolstack could load them from dom0's filesystem dynamically and pass them to hvmloader, instead of having them compiled-in statically in hvmloader. Would we still be able to do that with the simplifications you're suggesting here ? -- Julian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:04:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19: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 ) id 1SPIMa-0002iz-9q; Tue, 01 May 2012 19:03:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPIMY-0002iu-Cg for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:03:50 +0000 Received: from [85.158.143.35:14375] by server-3.bemta-4.messagelabs.com id D8/E2-05853-59330AF4; Tue, 01 May 2012 19:03:49 +0000 X-Env-Sender: julian.pidancet@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1335899028!13327530!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.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30570 invoked from network); 1 May 2012 19:03:48 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 19:03:48 -0000 Received: by eekc13 with SMTP id c13so1514669eek.30 for ; Tue, 01 May 2012 12:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NRjGXFIBRzr//FKnK+wWXqLXrfosykHomrujGASfT4Q=; b=dqEglME1WDRbA7QZ0y6aFbsFl514fcRPwVRrbWXnAu56QKEBqjqFLcUTKJgm3iINeh uf3FpsGUyVO2SIDfrnUh4qU7Gy0+r372PWaQANiYWWQRzVrMf7v/cB0dGIsT6634KvHv +WLD3VVYJUjV3KgfNNOVBJgzBOttzQwfsq7NVF6t7OE5ub4zMh2eu8cPhSGoCL6w5WX9 6+IlGA5yKbOhFll+sv3oRK3Ldb6WY+4PM56oZMM9vdDUTkR8OMGFq4aNOEhB2dBz6ef2 5P+k486ppw9d67SdwE7ZYCIElIfmqtIdyrDxmWSlrAB7MJh2EIM/XX+ocykEQsxc9fWk sgXA== Received: by 10.213.29.2 with SMTP id o2mr593730ebc.53.1335899028028; Tue, 01 May 2012 12:03:48 -0700 (PDT) Received: from [192.168.1.110] (188-223-88-44.zone14.bethere.co.uk. [188.223.88.44]) by mx.google.com with ESMTPS id r44sm94748423eef.2.2012.05.01.12.03.45 (version=SSLv3 cipher=OTHER); Tue, 01 May 2012 12:03:47 -0700 (PDT) Message-ID: <4FA03DC8.6040204@gmail.com> Date: Tue, 01 May 2012 20:47:20 +0100 From: Julian Pidancet User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120402 Thunderbird/10.0.3 MIME-Version: 1.0 To: Tim Deegan References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> In-Reply-To: <20120322112612.GG37468@ocelot.phlegethon.org> Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/22/12 11:26, Tim Deegan wrote: > Hi, > > At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote: >> My impression from the earlier discussions is that we're pasing largish >> blobs of binary BIOS goop around, which aren't suitable to go into >> xenstore. Dropping them in memory where HVMloader can pick them up >> seems reasonable. >> >> All the control-path stuff - what the blobs are, where they are &c, >> should go through Xenstore, though. > > So having looked at the code, I think the module system is really > overkill - AIUI all the things you're talking about passing through are > ACPI tables, which have their own length fields internally. So all > you'd need to do is have a type code and an address in xenstore > somewhere, the same way we pass a type code and a string for the other > BIOS customizations. > > Cheers, > > Tim. Hi, I don't think ACPI and SMBIOS firmware passthrough are the only use cases here. The module architecture could also be used to pass the BIOS and Option ROMs to hvmloader. The toolstack could load them from dom0's filesystem dynamically and pass them to hvmloader, instead of having them compiled-in statically in hvmloader. Would we still be able to do that with the simplifications you're suggesting here ? -- Julian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:48:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19:48:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3A-0002xI-RY; Tue, 01 May 2012 19:47:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3A-0002xD-2S for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:47:52 +0000 Received: from [193.109.254.147:25818] by server-8.bemta-14.messagelabs.com id 88/41-23244-7ED30AF4; Tue, 01 May 2012 19:47:51 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1335901669!338155!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30493 invoked from network); 1 May 2012 19:47:50 -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; 1 May 2012 19:47:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41JlkRE004884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 19:47:47 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 q41JlgOr014514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 19:47:43 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 q41JleWi025508; Tue, 1 May 2012 14:47:40 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 12:47:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1019740357; Tue, 1 May 2012 15:41:58 -0400 (EDT) Date: Tue, 1 May 2012 15:41:58 -0400 From: Konrad Rzeszutek Wilk To: Lin Ming Message-ID: <20120501194158.GA15164@phenom.dumpdata.com> References: <1335802587.4746.2.camel@chief-river-32> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335802587.4746.2.camel@chief-river-32> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH v2] xen/apic: implement io apic read with hypercall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 12:16:27AM +0800, Lin Ming wrote: > Implements xen_io_apic_read with hypercall, so it returns proper > IO-APIC information instead of fabricated one. Looks good. I queued it up and sending the git pull to Ingo shortly. > > Fallback to return an emulated IO_APIC values if hypercall fails. > > Signed-off-by: Lin Ming > --- > > v2: fallback to return an emulated IO_APIC values if hypercall fails > > arch/x86/xen/apic.c | 15 ++++++++++++++- > 1 files changed, 14 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c > index aee16ab..1913bf2 100644 > --- a/arch/x86/xen/apic.c > +++ b/arch/x86/xen/apic.c > @@ -1,14 +1,27 @@ > #include > #include > +#include > +#include > +#include > > unsigned int xen_io_apic_read(unsigned apic, unsigned reg) > { > + struct physdev_apic apic_op; > + int ret; > + > + apic_op.apic_physbase = mpc_ioapic_addr(apic); > + apic_op.reg = reg; > + ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); > + if (!ret) > + return apic_op.value; > + > + /* fallback to return an emulated IO_APIC values */ > if (reg == 0x1) > return 0x00170020; > else if (reg == 0x0) > return apic << 24; > > - return 0xff; > + return 0xfd; > } > > void __init xen_init_apic(void) > -- > 1.7.9 > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:48:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19:48:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3A-0002xI-RY; Tue, 01 May 2012 19:47:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3A-0002xD-2S for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:47:52 +0000 Received: from [193.109.254.147:25818] by server-8.bemta-14.messagelabs.com id 88/41-23244-7ED30AF4; Tue, 01 May 2012 19:47:51 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1335901669!338155!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30493 invoked from network); 1 May 2012 19:47:50 -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; 1 May 2012 19:47:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41JlkRE004884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 19:47:47 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 q41JlgOr014514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 19:47:43 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 q41JleWi025508; Tue, 1 May 2012 14:47:40 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 12:47:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1019740357; Tue, 1 May 2012 15:41:58 -0400 (EDT) Date: Tue, 1 May 2012 15:41:58 -0400 From: Konrad Rzeszutek Wilk To: Lin Ming Message-ID: <20120501194158.GA15164@phenom.dumpdata.com> References: <1335802587.4746.2.camel@chief-river-32> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335802587.4746.2.camel@chief-river-32> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH v2] xen/apic: implement io apic read with hypercall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 12:16:27AM +0800, Lin Ming wrote: > Implements xen_io_apic_read with hypercall, so it returns proper > IO-APIC information instead of fabricated one. Looks good. I queued it up and sending the git pull to Ingo shortly. > > Fallback to return an emulated IO_APIC values if hypercall fails. > > Signed-off-by: Lin Ming > --- > > v2: fallback to return an emulated IO_APIC values if hypercall fails > > arch/x86/xen/apic.c | 15 ++++++++++++++- > 1 files changed, 14 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c > index aee16ab..1913bf2 100644 > --- a/arch/x86/xen/apic.c > +++ b/arch/x86/xen/apic.c > @@ -1,14 +1,27 @@ > #include > #include > +#include > +#include > +#include > > unsigned int xen_io_apic_read(unsigned apic, unsigned reg) > { > + struct physdev_apic apic_op; > + int ret; > + > + apic_op.apic_physbase = mpc_ioapic_addr(apic); > + apic_op.reg = reg; > + ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); > + if (!ret) > + return apic_op.value; > + > + /* fallback to return an emulated IO_APIC values */ > if (reg == 0x1) > return 0x00170020; > else if (reg == 0x0) > return apic << 24; > > - return 0xff; > + return 0xfd; > } > > void __init xen_init_apic(void) > -- > 1.7.9 > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:49:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3p-0002yu-9x; Tue, 01 May 2012 19:48:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3n-0002yl-PA for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:48:32 +0000 Received: from [85.158.138.51:48709] by server-1.bemta-3.messagelabs.com id 6F/A3-11491-F0E30AF4; Tue, 01 May 2012 19:48:31 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1335901707!24695455!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18868 invoked from network); 1 May 2012 19:48:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 19:48:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41JmNFO005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 19:48: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 q41JmM9I015590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 19:48:22 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41JmMIU024478; Tue, 1 May 2012 14:48:22 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 12:48:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C5BFB40357; Tue, 1 May 2012 15:42:40 -0400 (EDT) Date: Tue, 1 May 2012 15:42:40 -0400 From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, mingo@kernel.org Message-ID: <20120501194240.GA15237@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] Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn Subject: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey Ingo, Please git pull the following branch for v3.5: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5 It has the proper fix for the IO-APIC having 0xfdfdfd... contents when booting under Xen. It also abstracts the IO-APIC in a different layer allowing for re-using of the generic code. Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6 x86/ioapic: Add io_apic_ops driver layer to allow interception) it does four things: 1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table instead of keeping it in the io_apic. This makes the code fit within the rest of x86_ops functions. 2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one. 3) Removes the work-around. 4) Implements a read hypercall to get the contents of the IOAPIC. Note: There is no (*write) as it is not needed. With these patches, this is what we end up seeing (for Xen): ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) -IOAPIC[0]: apic_id 0, version 253, address 0xfec00000, GSI 0-253 +IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[24]) -IOAPIC[1]: apic_id 1, version 253, address 0xfec3f000, GSI 24-277 +IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 24-47 ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[48]) -IOAPIC[2]: apic_id 2, version 253, address 0xfec7f000, GSI 48-301 +IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 48-71 for baremetal - there is no change in the output or functionality. Please pull! arch/x86/include/asm/io_apic.h | 35 +++++++++++++++++++---------- arch/x86/include/asm/x86_init.h | 9 ++++++- arch/x86/kernel/apic/io_apic.c | 46 +++----------------------------------- arch/x86/kernel/setup.c | 2 +- arch/x86/kernel/x86_init.c | 8 ++++++ arch/x86/xen/Makefile | 2 +- arch/x86/xen/apic.c | 30 +++++++++++++++++++++++++ arch/x86/xen/enlighten.c | 2 + arch/x86/xen/mmu.c | 4 +-- arch/x86/xen/xen-ops.h | 4 +++ 10 files changed, 82 insertions(+), 60 deletions(-) Konrad Rzeszutek Wilk (3): x86/apic: Replace io_apic_ops with x86_io_apic_ops. xen/x86: Implement x86_apic_ops Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'" Lin Ming (1): xen/apic: implement io apic read with hypercall And the full diff. diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 2c4943d..73d8c53 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -5,7 +5,7 @@ #include #include #include - +#include /* * Intel IO-APIC support for SMP and UP systems. * @@ -21,15 +21,6 @@ #define IO_APIC_REDIR_LEVEL_TRIGGER (1 << 15) #define IO_APIC_REDIR_MASKED (1 << 16) -struct io_apic_ops { - void (*init) (void); - unsigned int (*read) (unsigned int apic, unsigned int reg); - void (*write) (unsigned int apic, unsigned int reg, unsigned int value); - void (*modify)(unsigned int apic, unsigned int reg, unsigned int value); -}; - -void __init set_io_apic_ops(const struct io_apic_ops *); - /* * The structure of the IO-APIC: */ @@ -156,7 +147,6 @@ struct io_apic_irq_attr; extern int io_apic_set_pci_routing(struct device *dev, int irq, struct io_apic_irq_attr *irq_attr); void setup_IO_APIC_irq_extra(u32 gsi); -extern void ioapic_and_gsi_init(void); extern void ioapic_insert_resources(void); int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr); @@ -185,12 +175,29 @@ extern void mp_save_irq(struct mpc_intsrc *m); extern void disable_ioapic_support(void); +extern void __init native_io_apic_init_mappings(void); +extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg); +extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int val); +extern void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val); + +static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg) +{ + return x86_io_apic_ops.read(apic, reg); +} + +static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) +{ + x86_io_apic_ops.write(apic, reg, value); +} +static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) +{ + x86_io_apic_ops.modify(apic, reg, value); +} #else /* !CONFIG_X86_IO_APIC */ #define io_apic_assign_pci_irqs 0 #define setup_ioapic_ids_from_mpc x86_init_noop static const int timer_through_8259 = 0; -static inline void ioapic_and_gsi_init(void) { } static inline void ioapic_insert_resources(void) { } #define gsi_top (NR_IRQS_LEGACY) static inline int mp_find_ioapic(u32 gsi) { return 0; } @@ -212,6 +219,10 @@ static inline int restore_ioapic_entries(void) static inline void mp_save_irq(struct mpc_intsrc *m) { }; static inline void disable_ioapic_support(void) { } +#define native_io_apic_init_mappings NULL +#define native_io_apic_read NULL +#define native_io_apic_write NULL +#define native_io_apic_modify NULL #endif #endif /* _ASM_X86_IO_APIC_H */ diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index 764b66a..c090af1 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -188,11 +188,18 @@ struct x86_msi_ops { void (*restore_msi_irqs)(struct pci_dev *dev, int irq); }; +struct x86_io_apic_ops { + void (*init) (void); + unsigned int (*read) (unsigned int apic, unsigned int reg); + void (*write) (unsigned int apic, unsigned int reg, unsigned int value); + void (*modify)(unsigned int apic, unsigned int reg, unsigned int value); +}; + extern struct x86_init_ops x86_init; extern struct x86_cpuinit_ops x86_cpuinit; extern struct x86_platform_ops x86_platform; extern struct x86_msi_ops x86_msi; - +extern struct x86_io_apic_ops x86_io_apic_ops; extern void x86_init_noop(void); extern void x86_init_uint_noop(unsigned int unused); diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index e88300d..973539c 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -68,24 +68,6 @@ #define for_each_irq_pin(entry, head) \ for (entry = head; entry; entry = entry->next) -static void __init __ioapic_init_mappings(void); - -static unsigned int __io_apic_read (unsigned int apic, unsigned int reg); -static void __io_apic_write (unsigned int apic, unsigned int reg, unsigned int val); -static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val); - -static struct io_apic_ops io_apic_ops = { - .init = __ioapic_init_mappings, - .read = __io_apic_read, - .write = __io_apic_write, - .modify = __io_apic_modify, -}; - -void __init set_io_apic_ops(const struct io_apic_ops *ops) -{ - io_apic_ops = *ops; -} - /* * Is the SiS APIC rmw bug present ? * -1 = don't know, 0 = no, 1 = yes @@ -313,21 +295,6 @@ static void free_irq_at(unsigned int at, struct irq_cfg *cfg) irq_free_desc(at); } -static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg) -{ - return io_apic_ops.read(apic, reg); -} - -static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) -{ - io_apic_ops.write(apic, reg, value); -} - -static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) -{ - io_apic_ops.modify(apic, reg, value); -} - struct io_apic { unsigned int index; @@ -349,14 +316,14 @@ static inline void io_apic_eoi(unsigned int apic, unsigned int vector) writel(vector, &io_apic->eoi); } -static unsigned int __io_apic_read(unsigned int apic, unsigned int reg) +unsigned int native_io_apic_read(unsigned int apic, unsigned int reg) { struct io_apic __iomem *io_apic = io_apic_base(apic); writel(reg, &io_apic->index); return readl(&io_apic->data); } -static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) +void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) { struct io_apic __iomem *io_apic = io_apic_base(apic); @@ -370,7 +337,7 @@ static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int va * * Older SiS APIC requires we rewrite the index register */ -static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) +void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) { struct io_apic __iomem *io_apic = io_apic_base(apic); @@ -3931,12 +3898,7 @@ static struct resource * __init ioapic_setup_resources(int nr_ioapics) return res; } -void __init ioapic_and_gsi_init(void) -{ - io_apic_ops.init(); -} - -static void __init __ioapic_init_mappings(void) +void __init native_io_apic_init_mappings(void) { unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0; struct resource *ioapic_res; diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1a29015..8526317 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) init_cpu_to_node(); init_apic_mappings(); - ioapic_and_gsi_init(); + x86_io_apic_ops.init(); kvm_guest_init(); diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index 9cf71d0..35c5e54 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi = { .teardown_msi_irqs = default_teardown_msi_irqs, .restore_msi_irqs = default_restore_msi_irqs, }; + +struct x86_io_apic_ops x86_io_apic_ops = { + .init = native_io_apic_init_mappings, + .read = native_io_apic_read, + .write = native_io_apic_write, + .modify = native_io_apic_modify, +}; diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile index add2c2d..96ab2c0 100644 --- a/arch/x86/xen/Makefile +++ b/arch/x86/xen/Makefile @@ -20,5 +20,5 @@ 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_XEN_DOM0) += apic.o vga.o obj-$(CONFIG_SWIOTLB_XEN) += pci-swiotlb-xen.o diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c new file mode 100644 index 0000000..1913bf2 --- /dev/null +++ b/arch/x86/xen/apic.c @@ -0,0 +1,30 @@ +#include +#include +#include +#include +#include + +unsigned int xen_io_apic_read(unsigned apic, unsigned reg) +{ + struct physdev_apic apic_op; + int ret; + + apic_op.apic_physbase = mpc_ioapic_addr(apic); + apic_op.reg = reg; + ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); + if (!ret) + return apic_op.value; + + /* fallback to return an emulated IO_APIC values */ + if (reg == 0x1) + return 0x00170020; + else if (reg == 0x0) + return apic << 24; + + return 0xfd; +} + +void __init xen_init_apic(void) +{ + x86_io_apic_ops.read = xen_io_apic_read; +} diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..c2ea9e9 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1362,6 +1362,8 @@ asmlinkage void __init xen_start_kernel(void) xen_start_info->console.domU.mfn = 0; xen_start_info->console.domU.evtchn = 0; + xen_init_apic(); + /* Make sure ACS will be enabled */ pci_request_acs(); } diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..988828b 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1859,7 +1859,6 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, #endif /* CONFIG_X86_64 */ static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss; -static unsigned char fake_ioapic_mapping[PAGE_SIZE] __page_aligned_bss; static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) { @@ -1900,7 +1899,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) * We just don't map the IO APIC - all access is via * hypercalls. Keep the address in the pte for reference. */ - pte = pfn_pte(PFN_DOWN(__pa(fake_ioapic_mapping)), PAGE_KERNEL); + pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL); break; #endif @@ -2065,7 +2064,6 @@ void __init xen_init_mmu_ops(void) pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); - memset(fake_ioapic_mapping, 0xfd, PAGE_SIZE); } /* Protected by xen_reservation_lock. */ diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index b095739..45c0c06 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -92,11 +92,15 @@ struct dom0_vga_console_info; #ifdef CONFIG_XEN_DOM0 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size); +void __init xen_init_apic(void); #else static inline void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size) { } +static inline void __init xen_init_apic(void) +{ +} #endif /* Declare an asm function, along with symbols needed to make it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:49:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3p-0002yu-9x; Tue, 01 May 2012 19:48:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ3n-0002yl-PA for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:48:32 +0000 Received: from [85.158.138.51:48709] by server-1.bemta-3.messagelabs.com id 6F/A3-11491-F0E30AF4; Tue, 01 May 2012 19:48:31 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1335901707!24695455!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18868 invoked from network); 1 May 2012 19:48:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 19:48:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41JmNFO005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 19:48: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 q41JmM9I015590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 19:48:22 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41JmMIU024478; Tue, 1 May 2012 14:48:22 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 12:48:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C5BFB40357; Tue, 1 May 2012 15:42:40 -0400 (EDT) Date: Tue, 1 May 2012 15:42:40 -0400 From: Konrad Rzeszutek Wilk To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, mingo@kernel.org Message-ID: <20120501194240.GA15237@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] Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn Subject: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey Ingo, Please git pull the following branch for v3.5: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-ingo-v3.5 It has the proper fix for the IO-APIC having 0xfdfdfd... contents when booting under Xen. It also abstracts the IO-APIC in a different layer allowing for re-using of the generic code. Compared to the patch you have already in the tree (136d249ef7dbf0fefa292082cc40be1ea864cbd6 x86/ioapic: Add io_apic_ops driver layer to allow interception) it does four things: 1) Exposes the io_apic baremetal functions and uses the x86_io_apic_ops function table instead of keeping it in the io_apic. This makes the code fit within the rest of x86_ops functions. 2) Use the x86_io_apic_ops to re-direct the (*read) to the Xen emulated one. 3) Removes the work-around. 4) Implements a read hypercall to get the contents of the IOAPIC. Note: There is no (*write) as it is not needed. With these patches, this is what we end up seeing (for Xen): ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) -IOAPIC[0]: apic_id 0, version 253, address 0xfec00000, GSI 0-253 +IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[24]) -IOAPIC[1]: apic_id 1, version 253, address 0xfec3f000, GSI 24-277 +IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 24-47 ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[48]) -IOAPIC[2]: apic_id 2, version 253, address 0xfec7f000, GSI 48-301 +IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 48-71 for baremetal - there is no change in the output or functionality. Please pull! arch/x86/include/asm/io_apic.h | 35 +++++++++++++++++++---------- arch/x86/include/asm/x86_init.h | 9 ++++++- arch/x86/kernel/apic/io_apic.c | 46 +++----------------------------------- arch/x86/kernel/setup.c | 2 +- arch/x86/kernel/x86_init.c | 8 ++++++ arch/x86/xen/Makefile | 2 +- arch/x86/xen/apic.c | 30 +++++++++++++++++++++++++ arch/x86/xen/enlighten.c | 2 + arch/x86/xen/mmu.c | 4 +-- arch/x86/xen/xen-ops.h | 4 +++ 10 files changed, 82 insertions(+), 60 deletions(-) Konrad Rzeszutek Wilk (3): x86/apic: Replace io_apic_ops with x86_io_apic_ops. xen/x86: Implement x86_apic_ops Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'" Lin Ming (1): xen/apic: implement io apic read with hypercall And the full diff. diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 2c4943d..73d8c53 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -5,7 +5,7 @@ #include #include #include - +#include /* * Intel IO-APIC support for SMP and UP systems. * @@ -21,15 +21,6 @@ #define IO_APIC_REDIR_LEVEL_TRIGGER (1 << 15) #define IO_APIC_REDIR_MASKED (1 << 16) -struct io_apic_ops { - void (*init) (void); - unsigned int (*read) (unsigned int apic, unsigned int reg); - void (*write) (unsigned int apic, unsigned int reg, unsigned int value); - void (*modify)(unsigned int apic, unsigned int reg, unsigned int value); -}; - -void __init set_io_apic_ops(const struct io_apic_ops *); - /* * The structure of the IO-APIC: */ @@ -156,7 +147,6 @@ struct io_apic_irq_attr; extern int io_apic_set_pci_routing(struct device *dev, int irq, struct io_apic_irq_attr *irq_attr); void setup_IO_APIC_irq_extra(u32 gsi); -extern void ioapic_and_gsi_init(void); extern void ioapic_insert_resources(void); int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct io_apic_irq_attr *attr); @@ -185,12 +175,29 @@ extern void mp_save_irq(struct mpc_intsrc *m); extern void disable_ioapic_support(void); +extern void __init native_io_apic_init_mappings(void); +extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg); +extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int val); +extern void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val); + +static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg) +{ + return x86_io_apic_ops.read(apic, reg); +} + +static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) +{ + x86_io_apic_ops.write(apic, reg, value); +} +static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) +{ + x86_io_apic_ops.modify(apic, reg, value); +} #else /* !CONFIG_X86_IO_APIC */ #define io_apic_assign_pci_irqs 0 #define setup_ioapic_ids_from_mpc x86_init_noop static const int timer_through_8259 = 0; -static inline void ioapic_and_gsi_init(void) { } static inline void ioapic_insert_resources(void) { } #define gsi_top (NR_IRQS_LEGACY) static inline int mp_find_ioapic(u32 gsi) { return 0; } @@ -212,6 +219,10 @@ static inline int restore_ioapic_entries(void) static inline void mp_save_irq(struct mpc_intsrc *m) { }; static inline void disable_ioapic_support(void) { } +#define native_io_apic_init_mappings NULL +#define native_io_apic_read NULL +#define native_io_apic_write NULL +#define native_io_apic_modify NULL #endif #endif /* _ASM_X86_IO_APIC_H */ diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index 764b66a..c090af1 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -188,11 +188,18 @@ struct x86_msi_ops { void (*restore_msi_irqs)(struct pci_dev *dev, int irq); }; +struct x86_io_apic_ops { + void (*init) (void); + unsigned int (*read) (unsigned int apic, unsigned int reg); + void (*write) (unsigned int apic, unsigned int reg, unsigned int value); + void (*modify)(unsigned int apic, unsigned int reg, unsigned int value); +}; + extern struct x86_init_ops x86_init; extern struct x86_cpuinit_ops x86_cpuinit; extern struct x86_platform_ops x86_platform; extern struct x86_msi_ops x86_msi; - +extern struct x86_io_apic_ops x86_io_apic_ops; extern void x86_init_noop(void); extern void x86_init_uint_noop(unsigned int unused); diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index e88300d..973539c 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -68,24 +68,6 @@ #define for_each_irq_pin(entry, head) \ for (entry = head; entry; entry = entry->next) -static void __init __ioapic_init_mappings(void); - -static unsigned int __io_apic_read (unsigned int apic, unsigned int reg); -static void __io_apic_write (unsigned int apic, unsigned int reg, unsigned int val); -static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int val); - -static struct io_apic_ops io_apic_ops = { - .init = __ioapic_init_mappings, - .read = __io_apic_read, - .write = __io_apic_write, - .modify = __io_apic_modify, -}; - -void __init set_io_apic_ops(const struct io_apic_ops *ops) -{ - io_apic_ops = *ops; -} - /* * Is the SiS APIC rmw bug present ? * -1 = don't know, 0 = no, 1 = yes @@ -313,21 +295,6 @@ static void free_irq_at(unsigned int at, struct irq_cfg *cfg) irq_free_desc(at); } -static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg) -{ - return io_apic_ops.read(apic, reg); -} - -static inline void io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) -{ - io_apic_ops.write(apic, reg, value); -} - -static inline void io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) -{ - io_apic_ops.modify(apic, reg, value); -} - struct io_apic { unsigned int index; @@ -349,14 +316,14 @@ static inline void io_apic_eoi(unsigned int apic, unsigned int vector) writel(vector, &io_apic->eoi); } -static unsigned int __io_apic_read(unsigned int apic, unsigned int reg) +unsigned int native_io_apic_read(unsigned int apic, unsigned int reg) { struct io_apic __iomem *io_apic = io_apic_base(apic); writel(reg, &io_apic->index); return readl(&io_apic->data); } -static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) +void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned int value) { struct io_apic __iomem *io_apic = io_apic_base(apic); @@ -370,7 +337,7 @@ static void __io_apic_write(unsigned int apic, unsigned int reg, unsigned int va * * Older SiS APIC requires we rewrite the index register */ -static void __io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) +void native_io_apic_modify(unsigned int apic, unsigned int reg, unsigned int value) { struct io_apic __iomem *io_apic = io_apic_base(apic); @@ -3931,12 +3898,7 @@ static struct resource * __init ioapic_setup_resources(int nr_ioapics) return res; } -void __init ioapic_and_gsi_init(void) -{ - io_apic_ops.init(); -} - -static void __init __ioapic_init_mappings(void) +void __init native_io_apic_init_mappings(void) { unsigned long ioapic_phys, idx = FIX_IO_APIC_BASE_0; struct resource *ioapic_res; diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1a29015..8526317 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) init_cpu_to_node(); init_apic_mappings(); - ioapic_and_gsi_init(); + x86_io_apic_ops.init(); kvm_guest_init(); diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index 9cf71d0..35c5e54 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi = { .teardown_msi_irqs = default_teardown_msi_irqs, .restore_msi_irqs = default_restore_msi_irqs, }; + +struct x86_io_apic_ops x86_io_apic_ops = { + .init = native_io_apic_init_mappings, + .read = native_io_apic_read, + .write = native_io_apic_write, + .modify = native_io_apic_modify, +}; diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile index add2c2d..96ab2c0 100644 --- a/arch/x86/xen/Makefile +++ b/arch/x86/xen/Makefile @@ -20,5 +20,5 @@ 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_XEN_DOM0) += apic.o vga.o obj-$(CONFIG_SWIOTLB_XEN) += pci-swiotlb-xen.o diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c new file mode 100644 index 0000000..1913bf2 --- /dev/null +++ b/arch/x86/xen/apic.c @@ -0,0 +1,30 @@ +#include +#include +#include +#include +#include + +unsigned int xen_io_apic_read(unsigned apic, unsigned reg) +{ + struct physdev_apic apic_op; + int ret; + + apic_op.apic_physbase = mpc_ioapic_addr(apic); + apic_op.reg = reg; + ret = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); + if (!ret) + return apic_op.value; + + /* fallback to return an emulated IO_APIC values */ + if (reg == 0x1) + return 0x00170020; + else if (reg == 0x0) + return apic << 24; + + return 0xfd; +} + +void __init xen_init_apic(void) +{ + x86_io_apic_ops.read = xen_io_apic_read; +} diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..c2ea9e9 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1362,6 +1362,8 @@ asmlinkage void __init xen_start_kernel(void) xen_start_info->console.domU.mfn = 0; xen_start_info->console.domU.evtchn = 0; + xen_init_apic(); + /* Make sure ACS will be enabled */ pci_request_acs(); } diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..988828b 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1859,7 +1859,6 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, #endif /* CONFIG_X86_64 */ static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss; -static unsigned char fake_ioapic_mapping[PAGE_SIZE] __page_aligned_bss; static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) { @@ -1900,7 +1899,7 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) * We just don't map the IO APIC - all access is via * hypercalls. Keep the address in the pte for reference. */ - pte = pfn_pte(PFN_DOWN(__pa(fake_ioapic_mapping)), PAGE_KERNEL); + pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL); break; #endif @@ -2065,7 +2064,6 @@ void __init xen_init_mmu_ops(void) pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); - memset(fake_ioapic_mapping, 0xfd, PAGE_SIZE); } /* Protected by xen_reservation_lock. */ diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index b095739..45c0c06 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -92,11 +92,15 @@ struct dom0_vga_console_info; #ifdef CONFIG_XEN_DOM0 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size); +void __init xen_init_apic(void); #else static inline void __init xen_init_vga(const struct dom0_vga_console_info *info, size_t size) { } +static inline void __init xen_init_apic(void) +{ +} #endif /* Declare an asm function, along with symbols needed to make it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:49:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19: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 ) id 1SPJ4O-00033K-Sb; Tue, 01 May 2012 19:49:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ4N-00032z-49 for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:49:07 +0000 Received: from [193.109.254.147:26405] by server-11.bemta-14.messagelabs.com id 98/A3-05858-23E30AF4; Tue, 01 May 2012 19:49:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1335901745!7156902!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1733 invoked from network); 1 May 2012 19:49:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 19:49:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12231845" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 19:49: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, 1 May 2012 20:49:05 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPJ4L-0002WY-7F; Tue, 01 May 2012 19:49:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPJ4L-0000Hd-3W; Tue, 01 May 2012 20:49:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 20:49:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12769: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12769 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12769/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-amd64-pv 3 host-install(3) broken REGR. vs. 12707 test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 3 host-install(3) broken REGR. vs. 12707 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 15 guest-stop 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-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 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-i386-i386-xl-qemuu-winxpsp3 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 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 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 broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv broken test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 19:49:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 19: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 ) id 1SPJ4O-00033K-Sb; Tue, 01 May 2012 19:49:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJ4N-00032z-49 for xen-devel@lists.xensource.com; Tue, 01 May 2012 19:49:07 +0000 Received: from [193.109.254.147:26405] by server-11.bemta-14.messagelabs.com id 98/A3-05858-23E30AF4; Tue, 01 May 2012 19:49:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1335901745!7156902!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1733 invoked from network); 1 May 2012 19:49:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 19:49:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12231845" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 19:49: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, 1 May 2012 20:49:05 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPJ4L-0002WY-7F; Tue, 01 May 2012 19:49:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPJ4L-0000Hd-3W; Tue, 01 May 2012 20:49:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 20:49:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12769: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12769 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12769/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-amd64-pv 3 host-install(3) broken REGR. vs. 12707 test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 3 host-install(3) broken REGR. vs. 12707 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 15 guest-stop 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-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 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-i386-i386-xl-qemuu-winxpsp3 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 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 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 broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv broken test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:08:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20:08:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJMd-0003VT-MV; Tue, 01 May 2012 20:07:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJMb-0003VO-Pk for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:07:58 +0000 Received: from [193.109.254.147:23379] by server-6.bemta-14.messagelabs.com id C3/7A-04960-C9240AF4; Tue, 01 May 2012 20:07:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335902874!7127794!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4201 invoked from network); 1 May 2012 20:07:56 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:07:56 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41K7ovb023154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 20:07: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 q41K7nW9011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 20:07:50 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 q41K7neu021358; Tue, 1 May 2012 15:07:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 13:07:49 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1213640357; Tue, 1 May 2012 16:02:08 -0400 (EDT) Date: Tue, 1 May 2012 16:02:07 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120501200207.GA15313@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F9976F8.8040502@canonical.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > > On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >> Since there have been requests about that driver to get backported into 3.2, I > >> was interested to find out what or how much would be gained by that. > >> > >> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > >> was not very successful as the drivers bail out of the init function because the > >> first call to acpi_processor_register_performance() returns -ENODEV. There is > >> some frequency scaling when running without Xen, so I need to do some more > >> debugging there. > > > > Did you back-port the other components - the ones that turn off the native > > frequency scalling? > > > > provide disable_cpufreq() function to disable the API. > > xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > > xen/cpufreq: Disable the cpu frequency scaling drivers from loading > >> > > Yes, here is the full set for reference: > > * xen/cpufreq: Disable the cpu frequency scaling drivers from loading. > * xen/acpi: Remove the WARN's as they just create noise. > * xen/acpi: Fix Kconfig dependency on CPU_FREQ > * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > * xen/acpi-processor: C and P-state driver that uploads said data to hyper > * provide disable_cpufreq() function to disable the API. And (Linus just pulled it), you also need this one: df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > > >> The second system was an Intel one (4 core i7 920@2.67GHz) which was > >> successfully loading the driver. Via xenpm I can see the various frequencies and > >> also see them being changed. However the cpuidle data out of xenpm looks a bit odd: > >> > >> #> xenpm get-cpuidle-states 0 > >> Max C-state: C7 > >> > >> cpu id : 0 > >> total C-states : 2 > >> idle time(ms) : 10819311 > >> C0 : transition [00000000000000000001] > >> residency [00000000000000005398 ms] > >> C1 : transition [00000000000000000001] > >> residency [00000000000010819311 ms] > >> pc3 : [00000000000000000000 ms] > >> pc6 : [00000000000000000000 ms] > >> pc7 : [00000000000000000000 ms] > >> cc3 : [00000000000000000000 ms] > >> cc6 : [00000000000000000000 ms] > >> > >> Also gathering samples over 30s does look like only C0 and C1 are used. This > > > > Yes. > >> might be because C1E support is enabled in BIOS but when looking at the > >> intel_idle data in sysfs when running without a hypervisor will show C3 and C6 > >> for the cores. That could have been just a wrong output, so I plugged in a power > >> meter and compared a kernel running natively and running as dom0 (with and > >> without the acpi-processor driver). > >> > >> Native: 175W > >> dom0: 183W (with only marginal difference between with or without the > >> processor driver) > >> [yes, the system has a somewhat high base consumption which I attribute to a > >> ridiculously dimensioned graphics subsystem to be running a text console] > >> > >> This I would take as C3 and C6 really not being used and the frequency scaling So the other thing I forgot to note is that C3->C6 have a detrimental effect on some Intel boxes with Xen. We haven't figured out exactly which ones and the bug is definitly in the hypervisor. The bug is that when the CPU goes in those states the NIC ends up being unresponsive. Its like the interrupts stopped being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > > > > To go in deeper modes there is also a need to backport a Xen unstable > > hypercall which will allow the kernel to detect the other states besides > > C0-C2. > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > "ACPI: add _PDC input override mechanism". > > > > I see. There is a kernel patch about enabling MWAIT that refers to that... Were there any special things you ran when checking the output? Just plugging and looking at the results? > > > > >> having no impact on the idle system is not that much surprising. But if that was > >> true it would also limit the usefulness of the turbo mode which I understand > >> would also be limited by the c-state of the other cores. > > > > Hm, I should double-check that - but somehow I thought that Xen independetly > > checks for TurboMode and if the P-states are in, then they are activated. I did a bit of checking around and it does seem that is the case. From what I have gathered the TurboMode kicks in when the CPU is C0 mode (which should be obvious), and when the other cores are in anything but C0 mode. And sure enough that seems to be the case. But I can't get the concrete details whether the "but C0 mode" means that TurboMode will work better if the C mode is legacy C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from Len Brown more details.. > > > Turbo mode should be enabled. I had been only looking at a generic overview > about it on Intel site which sounded like it would make more of a difference on > how much one core could get overclocked related to how many cores are active > (and I translated active or not into deeper c-states or not). > Looking at the verbose output of turbostat it seems not to make that much > difference whether 2-4 cores are running. A single core alone could get one more > increment in clock stepping. That does not immediately sound a lot. And of > course how much or long the higher clock is used depends on other factors as > well and is not under OS control. > > In the end it is probably quite dynamic and hard to come up with hard facts to > prove its value. Though if I can lower the idle power usage by reaching a bit > further, that would greatly help to justify the effort and potential risk of > backporting... I understand. I wish I could give you the exact percentage points by which the power usage will drop. But I think the more substantial reason benefit of these patches is performance gains. The ones that Ian Campbell ran and were posted on Phorenix site paint that they are beneficial. > > >> > >> Do I misread the data I see? Or maybe its a known limitation? In case it is > >> worth doing more research I'll gladly try things and gather more data. > > > > Just missing some patches. > > > > Oh, and this one: > > xen/acpi: Fix Kconfig dependency on CPU_FREQ > > > > Hmm.. I think a patch disappeared somewhere. That was the one I referenced at the beginning of this email. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:08:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20:08:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJMd-0003VT-MV; Tue, 01 May 2012 20:07:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJMb-0003VO-Pk for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:07:58 +0000 Received: from [193.109.254.147:23379] by server-6.bemta-14.messagelabs.com id C3/7A-04960-C9240AF4; Tue, 01 May 2012 20:07:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335902874!7127794!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4201 invoked from network); 1 May 2012 20:07:56 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:07:56 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41K7ovb023154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 20:07: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 q41K7nW9011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 20:07:50 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 q41K7neu021358; Tue, 1 May 2012 15:07:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 13:07:49 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1213640357; Tue, 1 May 2012 16:02:08 -0400 (EDT) Date: Tue, 1 May 2012 16:02:07 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120501200207.GA15313@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F9976F8.8040502@canonical.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > > On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >> Since there have been requests about that driver to get backported into 3.2, I > >> was interested to find out what or how much would be gained by that. > >> > >> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > >> was not very successful as the drivers bail out of the init function because the > >> first call to acpi_processor_register_performance() returns -ENODEV. There is > >> some frequency scaling when running without Xen, so I need to do some more > >> debugging there. > > > > Did you back-port the other components - the ones that turn off the native > > frequency scalling? > > > > provide disable_cpufreq() function to disable the API. > > xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > > xen/cpufreq: Disable the cpu frequency scaling drivers from loading > >> > > Yes, here is the full set for reference: > > * xen/cpufreq: Disable the cpu frequency scaling drivers from loading. > * xen/acpi: Remove the WARN's as they just create noise. > * xen/acpi: Fix Kconfig dependency on CPU_FREQ > * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > * xen/acpi-processor: C and P-state driver that uploads said data to hyper > * provide disable_cpufreq() function to disable the API. And (Linus just pulled it), you also need this one: df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > > >> The second system was an Intel one (4 core i7 920@2.67GHz) which was > >> successfully loading the driver. Via xenpm I can see the various frequencies and > >> also see them being changed. However the cpuidle data out of xenpm looks a bit odd: > >> > >> #> xenpm get-cpuidle-states 0 > >> Max C-state: C7 > >> > >> cpu id : 0 > >> total C-states : 2 > >> idle time(ms) : 10819311 > >> C0 : transition [00000000000000000001] > >> residency [00000000000000005398 ms] > >> C1 : transition [00000000000000000001] > >> residency [00000000000010819311 ms] > >> pc3 : [00000000000000000000 ms] > >> pc6 : [00000000000000000000 ms] > >> pc7 : [00000000000000000000 ms] > >> cc3 : [00000000000000000000 ms] > >> cc6 : [00000000000000000000 ms] > >> > >> Also gathering samples over 30s does look like only C0 and C1 are used. This > > > > Yes. > >> might be because C1E support is enabled in BIOS but when looking at the > >> intel_idle data in sysfs when running without a hypervisor will show C3 and C6 > >> for the cores. That could have been just a wrong output, so I plugged in a power > >> meter and compared a kernel running natively and running as dom0 (with and > >> without the acpi-processor driver). > >> > >> Native: 175W > >> dom0: 183W (with only marginal difference between with or without the > >> processor driver) > >> [yes, the system has a somewhat high base consumption which I attribute to a > >> ridiculously dimensioned graphics subsystem to be running a text console] > >> > >> This I would take as C3 and C6 really not being used and the frequency scaling So the other thing I forgot to note is that C3->C6 have a detrimental effect on some Intel boxes with Xen. We haven't figured out exactly which ones and the bug is definitly in the hypervisor. The bug is that when the CPU goes in those states the NIC ends up being unresponsive. Its like the interrupts stopped being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > > > > To go in deeper modes there is also a need to backport a Xen unstable > > hypercall which will allow the kernel to detect the other states besides > > C0-C2. > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > "ACPI: add _PDC input override mechanism". > > > > I see. There is a kernel patch about enabling MWAIT that refers to that... Were there any special things you ran when checking the output? Just plugging and looking at the results? > > > > >> having no impact on the idle system is not that much surprising. But if that was > >> true it would also limit the usefulness of the turbo mode which I understand > >> would also be limited by the c-state of the other cores. > > > > Hm, I should double-check that - but somehow I thought that Xen independetly > > checks for TurboMode and if the P-states are in, then they are activated. I did a bit of checking around and it does seem that is the case. From what I have gathered the TurboMode kicks in when the CPU is C0 mode (which should be obvious), and when the other cores are in anything but C0 mode. And sure enough that seems to be the case. But I can't get the concrete details whether the "but C0 mode" means that TurboMode will work better if the C mode is legacy C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from Len Brown more details.. > > > Turbo mode should be enabled. I had been only looking at a generic overview > about it on Intel site which sounded like it would make more of a difference on > how much one core could get overclocked related to how many cores are active > (and I translated active or not into deeper c-states or not). > Looking at the verbose output of turbostat it seems not to make that much > difference whether 2-4 cores are running. A single core alone could get one more > increment in clock stepping. That does not immediately sound a lot. And of > course how much or long the higher clock is used depends on other factors as > well and is not under OS control. > > In the end it is probably quite dynamic and hard to come up with hard facts to > prove its value. Though if I can lower the idle power usage by reaching a bit > further, that would greatly help to justify the effort and potential risk of > backporting... I understand. I wish I could give you the exact percentage points by which the power usage will drop. But I think the more substantial reason benefit of these patches is performance gains. The ones that Ian Campbell ran and were posted on Phorenix site paint that they are beneficial. > > >> > >> Do I misread the data I see? Or maybe its a known limitation? In case it is > >> worth doing more research I'll gladly try things and gather more data. > > > > Just missing some patches. > > > > Oh, and this one: > > xen/acpi: Fix Kconfig dependency on CPU_FREQ > > > > Hmm.. I think a patch disappeared somewhere. That was the one I referenced at the beginning of this email. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:13:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJRR-0003dS-Ff; Tue, 01 May 2012 20:12:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJRQ-0003dN-60 for xen-devel@lists.xen.org; Tue, 01 May 2012 20:12:56 +0000 Received: from [193.109.254.147:52152] by server-2.bemta-14.messagelabs.com id 76/EF-19409-7C340AF4; Tue, 01 May 2012 20:12:55 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1335903173!1496371!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5823 invoked from network); 1 May 2012 20:12:54 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:12:54 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q41KCq2E029974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 May 2012 16:12:52 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q41KCqsQ029972; Tue, 1 May 2012 16:12:52 -0400 Date: Tue, 1 May 2012 16:12:52 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk Message-ID: <20120501201252.GA29872@andromeda.dapyr.net> References: <20120427023439.GB26931@phenom.dumpdata.com> <4F9AA4C602000078000806F2@nat28.tlf.novell.com> <20120427143122.GD9186@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120427143122.GD9186@phenom.dumpdata.com> User-Agent: Mutt/1.5.9i Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 27, 2012 at 10:31:22AM -0400, Konrad Rzeszutek Wilk wrote: > > How would that be? 2711MiB = 2776064kiB, which 446k off the value > > above. And apart from that, the value above isn't even divisible by 4 > > I messed up on that. Redid the numbers and I was off. > > > (i.e. not an even number of pages). > > To make this a bit easier I used 'dom0_max=max:3G', which means > (with this swiss-cheese type E820 on this Intel box): > > [ 0.000000] Released 75745 pages of unused memory > > so I should have 75745 pages left to play with. But what I found is that > I can only go up to 786415 which is 17 pages short of the 786432 goal. > > Here are the steps: > > $cat `find /sys -name current_kb` > 2842816 > $echo $((3*1024*1024)) > 3145728 > $echo "3145728" > `find /sys -name target_kb` > $cat `find /sys -name current_kb` > 3145660 > $xl dmesg | tail > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 786433 (786432) > 786432 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) > > > > Any ideas of what that might be? Could it be the shared_info, hypercall page, > > > start_info, xenconsole and some other ones are the magic 6 pages which > > > inhibit how much we can balloon up to? > > > > Not likely: The hypercall page is in kernel (image) memory, and there's > > no console page at all fro Dom0. > > 17 pages.. Hmm I am still not exactly sure what the problem is, but by running this on various machines I found that I can be off by 1,2,3, 4 or 17 pages. It looked to vary based on the amount of ACPI tables that showed up in MADT. So I think what is happening is that the initial domain gets the ACPI regions (which are shared) accounted in its d->tot_pages. I can't pinpoint the exact piece of code in the hypervisor for this. But what I did do on the Linux side was using the current_reservation hypercall (so d->tot_pages) and based on that would populate exactly up to start_info->nr_pages - d->tot_pages pages and did not get any of those errors. > > > > Jan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:13:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJRR-0003dS-Ff; Tue, 01 May 2012 20:12:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJRQ-0003dN-60 for xen-devel@lists.xen.org; Tue, 01 May 2012 20:12:56 +0000 Received: from [193.109.254.147:52152] by server-2.bemta-14.messagelabs.com id 76/EF-19409-7C340AF4; Tue, 01 May 2012 20:12:55 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1335903173!1496371!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5823 invoked from network); 1 May 2012 20:12:54 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:12:54 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q41KCq2E029974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 May 2012 16:12:52 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q41KCqsQ029972; Tue, 1 May 2012 16:12:52 -0400 Date: Tue, 1 May 2012 16:12:52 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk Message-ID: <20120501201252.GA29872@andromeda.dapyr.net> References: <20120427023439.GB26931@phenom.dumpdata.com> <4F9AA4C602000078000806F2@nat28.tlf.novell.com> <20120427143122.GD9186@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120427143122.GD9186@phenom.dumpdata.com> User-Agent: Mutt/1.5.9i Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 694017 > 694016 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 27, 2012 at 10:31:22AM -0400, Konrad Rzeszutek Wilk wrote: > > How would that be? 2711MiB = 2776064kiB, which 446k off the value > > above. And apart from that, the value above isn't even divisible by 4 > > I messed up on that. Redid the numbers and I was off. > > > (i.e. not an even number of pages). > > To make this a bit easier I used 'dom0_max=max:3G', which means > (with this swiss-cheese type E820 on this Intel box): > > [ 0.000000] Released 75745 pages of unused memory > > so I should have 75745 pages left to play with. But what I found is that > I can only go up to 786415 which is 17 pages short of the 786432 goal. > > Here are the steps: > > $cat `find /sys -name current_kb` > 2842816 > $echo $((3*1024*1024)) > 3145728 > $echo "3145728" > `find /sys -name target_kb` > $cat `find /sys -name current_kb` > 3145660 > $xl dmesg | tail > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 786433 (786432) > 786432 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) > > > > Any ideas of what that might be? Could it be the shared_info, hypercall page, > > > start_info, xenconsole and some other ones are the magic 6 pages which > > > inhibit how much we can balloon up to? > > > > Not likely: The hypercall page is in kernel (image) memory, and there's > > no console page at all fro Dom0. > > 17 pages.. Hmm I am still not exactly sure what the problem is, but by running this on various machines I found that I can be off by 1,2,3, 4 or 17 pages. It looked to vary based on the amount of ACPI tables that showed up in MADT. So I think what is happening is that the initial domain gets the ACPI regions (which are shared) accounted in its d->tot_pages. I can't pinpoint the exact piece of code in the hypervisor for this. But what I did do on the Linux side was using the current_reservation hypercall (so d->tot_pages) and based on that would populate exactly up to start_info->nr_pages - d->tot_pages pages and did not get any of those errors. > > > > Jan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:21:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJYs-0003oe-FR; Tue, 01 May 2012 20:20:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJYr-0003oZ-G3 for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:20:37 +0000 Received: from [85.158.143.99:44922] by server-3.bemta-4.messagelabs.com id C3/90-05853-49540AF4; Tue, 01 May 2012 20:20:36 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335903632!22674242!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzkzNzY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21588 invoked from network); 1 May 2012 20:20:35 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:20:35 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2012 20:15:16 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2012 20:15:12 +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 q41KDXIH1544248 for ; Wed, 2 May 2012 06:13:35 +1000 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 q41KKMAV019561 for ; Wed, 2 May 2012 06:20:23 +1000 Received: from [9.79.246.105] ([9.79.246.105]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q41KKFNH019511; Wed, 2 May 2012 06:20:16 +1000 Message-ID: <4FA04576.6030405@linux.vnet.ibm.com> Date: Wed, 02 May 2012 01:50:06 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Avi Kivity References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com> <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com> <4F9D415B.7010103@redhat.com> <4F9E42F6.8050108@linux.vnet.ibm.com> In-Reply-To: <4F9E42F6.8050108@linux.vnet.ibm.com> x-cbid: 12050110-7014-0000-0000-000001031971 Cc: Jeremy Fitzhardinge , X86 , KVM , Konrad Rzeszutek Wilk , linux-doc@vger.kernel.org, LKML , Greg Kroah-Hartman , Alexander Graf , Gleb Natapov , Virtualization , Marcelo Tosatti , Randy Dunlap , Ingo Molnar , Srivatsa Vaddagiri , Sasha Levin , "H. Peter Anvin" , Xen , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/30/2012 01:14 PM, Raghavendra K T wrote: >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 4044ce0..7fc9be6 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext) >>> case KVM_CAP_ASYNC_PF: >>> case KVM_CAP_GET_TSC_KHZ: >>> case KVM_CAP_PCI_2_3: >>> + case KVM_CAP_PV_UNHALT: >>> r = 1; >>> break; >>> case KVM_CAP_COALESCED_MMIO: >> >> Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID. But >> please indicate this in the documentation. >> > > Ok. will mention that in documentation added for KVM_CAP_PV_UNHALT. > I think it is better to remove KVM_CAP_PV_UNHALT itself and avoid spamming CAP.. will do that in coming version. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:21:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJYs-0003oe-FR; Tue, 01 May 2012 20:20:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJYr-0003oZ-G3 for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:20:37 +0000 Received: from [85.158.143.99:44922] by server-3.bemta-4.messagelabs.com id C3/90-05853-49540AF4; Tue, 01 May 2012 20:20:36 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335903632!22674242!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzkzNzY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21588 invoked from network); 1 May 2012 20:20:35 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:20:35 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2012 20:15:16 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2012 20:15:12 +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 q41KDXIH1544248 for ; Wed, 2 May 2012 06:13:35 +1000 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 q41KKMAV019561 for ; Wed, 2 May 2012 06:20:23 +1000 Received: from [9.79.246.105] ([9.79.246.105]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q41KKFNH019511; Wed, 2 May 2012 06:20:16 +1000 Message-ID: <4FA04576.6030405@linux.vnet.ibm.com> Date: Wed, 02 May 2012 01:50:06 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Avi Kivity References: <20120423095937.30893.14776.sendpatchset@codeblue.in.ibm.com> <20120423095947.30893.84029.sendpatchset@codeblue.in.ibm.com> <4F9D415B.7010103@redhat.com> <4F9E42F6.8050108@linux.vnet.ibm.com> In-Reply-To: <4F9E42F6.8050108@linux.vnet.ibm.com> x-cbid: 12050110-7014-0000-0000-000001031971 Cc: Jeremy Fitzhardinge , X86 , KVM , Konrad Rzeszutek Wilk , linux-doc@vger.kernel.org, LKML , Greg Kroah-Hartman , Alexander Graf , Gleb Natapov , Virtualization , Marcelo Tosatti , Randy Dunlap , Ingo Molnar , Srivatsa Vaddagiri , Sasha Levin , "H. Peter Anvin" , Xen , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/30/2012 01:14 PM, Raghavendra K T wrote: >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 4044ce0..7fc9be6 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -2147,6 +2147,7 @@ int kvm_dev_ioctl_check_extension(long ext) >>> case KVM_CAP_ASYNC_PF: >>> case KVM_CAP_GET_TSC_KHZ: >>> case KVM_CAP_PCI_2_3: >>> + case KVM_CAP_PV_UNHALT: >>> r = 1; >>> break; >>> case KVM_CAP_COALESCED_MMIO: >> >> Redundant, since we can infer this from KVM_GET_SUPPORTED_CPUID. But >> please indicate this in the documentation. >> > > Ok. will mention that in documentation added for KVM_CAP_PV_UNHALT. > I think it is better to remove KVM_CAP_PV_UNHALT itself and avoid spamming CAP.. will do that in coming version. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:33:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJkQ-0003yB-Oj; Tue, 01 May 2012 20:32:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJkP-0003y6-C1 for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:32:33 +0000 Received: from [85.158.139.83:13495] by server-10.bemta-5.messagelabs.com id A5/A3-08260-06840AF4; Tue, 01 May 2012 20:32:32 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1335904349!23586558!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20552 invoked from network); 1 May 2012 20:32:30 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:32:30 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41KWNNK015434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 20:32:24 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 q41KWM6l015414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 20:32:23 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41KWLBl021170; Tue, 1 May 2012 15:32:21 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 13:32:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id ABE3040357; Tue, 1 May 2012 16:26:40 -0400 (EDT) Date: Tue, 1 May 2012 16:26:40 -0400 From: Konrad Rzeszutek Wilk To: Josh Boyer Message-ID: <20120501202640.GB16209@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 04:08:19PM -0400, Josh Boyer wrote: > On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk > wrote: > > -static void __init __ioapic_init_mappings(void) > > +void __init native_io_apic_init_mappings(void) > > =A0{ > > =A0 =A0 =A0 =A0unsigned long ioapic_phys, idx =3D FIX_IO_APIC_BASE_0; > > =A0 =A0 =A0 =A0struct resource *ioapic_res; > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 1a29015..8526317 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) > > =A0 =A0 =A0 =A0init_cpu_to_node(); > > > > =A0 =A0 =A0 =A0init_apic_mappings(); > > - =A0 =A0 =A0 ioapic_and_gsi_init(); > > + =A0 =A0 =A0 x86_io_apic_ops.init(); > > > > =A0 =A0 =A0 =A0kvm_guest_init(); > > > > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > > index 9cf71d0..35c5e54 100644 > > --- a/arch/x86/kernel/x86_init.c > > +++ b/arch/x86/kernel/x86_init.c > > @@ -18,6 +18,7 @@ > > =A0#include > > =A0#include > > =A0#include > > +#include > > =A0#include > > =A0#include > > =A0#include > > @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi =3D { > > =A0 =A0 =A0 =A0.teardown_msi_irqs =3D default_teardown_msi_irqs, > > =A0 =A0 =A0 =A0.restore_msi_irqs =3D default_restore_msi_irqs, > > =A0}; > > + > > +struct x86_io_apic_ops x86_io_apic_ops =3D { > > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, > > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, > > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, > > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, > > +}; > = > You'll get a section mismatch warning on this struct. It's not a huge > deal, but native_io_apic_init_mappings is annotated as __init whereas > this struct isn't. In practice it doesn't seem to matter as > x86_io_apic_ops.init is only called in setup_arch, but it's still a > valid warning. I think that the mismatch disappears if the structure has the word _ops in it. At least that is what I saw (when I ran with the MODULE_SECTION= =3Dy with the initial implementation of this and then fixed it up). However, let me double check - I might have seen that with something else and misremebered it. > = > (First noticed in https://bugzilla.redhat.com/show_bug.cgi?id=3D817645 ) > = > josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 20:33:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 20: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 ) id 1SPJkQ-0003yB-Oj; Tue, 01 May 2012 20:32:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJkP-0003y6-C1 for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:32:33 +0000 Received: from [85.158.139.83:13495] by server-10.bemta-5.messagelabs.com id A5/A3-08260-06840AF4; Tue, 01 May 2012 20:32:32 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1335904349!23586558!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAzMTQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20552 invoked from network); 1 May 2012 20:32:30 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 20:32:30 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41KWNNK015434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 20:32:24 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 q41KWM6l015414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 20:32:23 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q41KWLBl021170; Tue, 1 May 2012 15:32:21 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 13:32:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id ABE3040357; Tue, 1 May 2012 16:26:40 -0400 (EDT) Date: Tue, 1 May 2012 16:26:40 -0400 From: Konrad Rzeszutek Wilk To: Josh Boyer Message-ID: <20120501202640.GB16209@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 04:08:19PM -0400, Josh Boyer wrote: > On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk > wrote: > > -static void __init __ioapic_init_mappings(void) > > +void __init native_io_apic_init_mappings(void) > > =A0{ > > =A0 =A0 =A0 =A0unsigned long ioapic_phys, idx =3D FIX_IO_APIC_BASE_0; > > =A0 =A0 =A0 =A0struct resource *ioapic_res; > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 1a29015..8526317 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) > > =A0 =A0 =A0 =A0init_cpu_to_node(); > > > > =A0 =A0 =A0 =A0init_apic_mappings(); > > - =A0 =A0 =A0 ioapic_and_gsi_init(); > > + =A0 =A0 =A0 x86_io_apic_ops.init(); > > > > =A0 =A0 =A0 =A0kvm_guest_init(); > > > > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > > index 9cf71d0..35c5e54 100644 > > --- a/arch/x86/kernel/x86_init.c > > +++ b/arch/x86/kernel/x86_init.c > > @@ -18,6 +18,7 @@ > > =A0#include > > =A0#include > > =A0#include > > +#include > > =A0#include > > =A0#include > > =A0#include > > @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi =3D { > > =A0 =A0 =A0 =A0.teardown_msi_irqs =3D default_teardown_msi_irqs, > > =A0 =A0 =A0 =A0.restore_msi_irqs =3D default_restore_msi_irqs, > > =A0}; > > + > > +struct x86_io_apic_ops x86_io_apic_ops =3D { > > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, > > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, > > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, > > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, > > +}; > = > You'll get a section mismatch warning on this struct. It's not a huge > deal, but native_io_apic_init_mappings is annotated as __init whereas > this struct isn't. In practice it doesn't seem to matter as > x86_io_apic_ops.init is only called in setup_arch, but it's still a > valid warning. I think that the mismatch disappears if the structure has the word _ops in it. At least that is what I saw (when I ran with the MODULE_SECTION= =3Dy with the initial implementation of this and then fixed it up). However, let me double check - I might have seen that with something else and misremebered it. > = > (First noticed in https://bugzilla.redhat.com/show_bug.cgi?id=3D817645 ) > = > josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:18:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22:18:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLOU-0004Xg-7W; Tue, 01 May 2012 22:18:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLOS-0004Xb-7x for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:18:00 +0000 Received: from [193.109.254.147:55830] by server-9.bemta-14.messagelabs.com id 87/CF-05787-71160AF4; Tue, 01 May 2012 22:17:59 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1335910678!7167329!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5986 invoked from network); 1 May 2012 22:17:58 -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; 1 May 2012 22:17:58 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPLOO-000I4a-Uf; Tue, 01 May 2012 22:17:56 +0000 Date: Tue, 1 May 2012 23:17:56 +0100 From: Tim Deegan To: Julian Pidancet Message-ID: <20120501221756.GA69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA03DC8.6040204@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 20:47 +0100 on 01 May (1335905240), Julian Pidancet wrote: > I don't think ACPI and SMBIOS firmware passthrough are the only use > cases here. > > The module architecture could also be used to pass the BIOS and Option > ROMs to hvmloader. The toolstack could load them from dom0's filesystem > dynamically and pass them to hvmloader, instead of having them > compiled-in statically in hvmloader. AFAIK the BIOS can already load option ROMs from real or emulated hardware, the way a real BIOS does, and I think that's a good interface. Is loading a custom BIOS (as opposed to option ROM) something you actually want to do, BTW? > Would we still be able to do that with the simplifications you're > suggesting here ? Yes, you could definitely do it without all this module stuff. Passing an address and length in Xenstore would work. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:18:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22:18:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLOU-0004Xg-7W; Tue, 01 May 2012 22:18:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLOS-0004Xb-7x for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:18:00 +0000 Received: from [193.109.254.147:55830] by server-9.bemta-14.messagelabs.com id 87/CF-05787-71160AF4; Tue, 01 May 2012 22:17:59 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1335910678!7167329!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5986 invoked from network); 1 May 2012 22:17:58 -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; 1 May 2012 22:17:58 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPLOO-000I4a-Uf; Tue, 01 May 2012 22:17:56 +0000 Date: Tue, 1 May 2012 23:17:56 +0100 From: Tim Deegan To: Julian Pidancet Message-ID: <20120501221756.GA69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA03DC8.6040204@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 20:47 +0100 on 01 May (1335905240), Julian Pidancet wrote: > I don't think ACPI and SMBIOS firmware passthrough are the only use > cases here. > > The module architecture could also be used to pass the BIOS and Option > ROMs to hvmloader. The toolstack could load them from dom0's filesystem > dynamically and pass them to hvmloader, instead of having them > compiled-in statically in hvmloader. AFAIK the BIOS can already load option ROMs from real or emulated hardware, the way a real BIOS does, and I think that's a good interface. Is loading a custom BIOS (as opposed to option ROM) something you actually want to do, BTW? > Would we still be able to do that with the simplifications you're > suggesting here ? Yes, you could definitely do it without all this module stuff. Passing an address and length in Xenstore would work. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:36:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22: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 ) id 1SPLfq-0004jK-TE; Tue, 01 May 2012 22:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLfp-0004jF-5u for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:35:57 +0000 Received: from [85.158.138.51:6406] by server-9.bemta-3.messagelabs.com id 79/4F-26691-C4560AF4; Tue, 01 May 2012 22:35:56 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1335911753!24701702!1 X-Originating-IP: [65.55.88.11] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27306 invoked from network); 1 May 2012 22:35:54 -0000 Received: from tx2ehsobe001.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.11) by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 May 2012 22:35:54 -0000 Received: from mail129-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 May 2012 22:35:45 +0000 Received: from mail129-tx2 (localhost [127.0.0.1]) by mail129-tx2-R.bigfish.com (Postfix) with ESMTP id 7F509440191; Tue, 1 May 2012 22:35:45 +0000 (UTC) X-SpamScore: -17 X-BigFish: VPS-17(zzbb2dI9371I1432N98dK179dNzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2 (MessageSwitch) id 133591174360014_24320; Tue, 1 May 2012 22:35:43 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.246]) by mail129-tx2.bigfish.com (Postfix) with ESMTP id 0883DC0059; Tue, 1 May 2012 22:35:43 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 May 2012 22:35:42 +0000 X-WSS-ID: 0M3D83L-02-DOY-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 282B3C80F8; Tue, 1 May 2012 17:35:44 -0500 (CDT) 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, 1 May 2012 17:35:55 -0500 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, 1 May 2012 17:35:46 -0500 Message-ID: <4FA06541.7050607@amd.com> Date: Tue, 1 May 2012 18:35:45 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk , Stefan Bader References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> In-Reply-To: <20120501200207.GA15313@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>> Since there have been requests about that driver to get backported into 3.2, I >>>> was interested to find out what or how much would be gained by that. >>>> >>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which >>>> was not very successful as the drivers bail out of the init function because the >>>> first call to acpi_processor_register_performance() returns -ENODEV. There is >>>> some frequency scaling when running without Xen, so I need to do some more >>>> debugging there. I believe this is caused by the somewhat under-enlightened xen_apic_read(): static u32 xen_apic_read(u32 reg) { return 0; } This results in some data, most importantly boot_cpu_physical_apicid, not being set correctly and, in turn, causes x86_cpu_to_apicid to be broken. On larger AMD systems boot processor is typically APICID=0x20 (I don't have Intel system handy to see how it looks there). As a quick and dirty test you can try: diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index edc2448..1f78998 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long address) } if (boot_cpu_physical_apicid == -1U) { boot_cpu_physical_apicid = read_apic_id(); + boot_cpu_physical_apicid = 32; apic_version[boot_cpu_physical_apicid] = GET_APIC_VERSION(apic_read(APIC_LVR)); } (Set it to whatever APICID on core0 is, I suspect it won't be zero). -boris >>> >>> Did you back-port the other components - the ones that turn off the native >>> frequency scalling? >>> >>> provide disable_cpufreq() function to disable the API. >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loading >>>> >> >> Yes, here is the full set for reference: >> >> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading. >> * xen/acpi: Remove the WARN's as they just create noise. >> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >> * xen/acpi-processor: C and P-state driver that uploads said data to hyper >> * provide disable_cpufreq() function to disable the API. > > And (Linus just pulled it), you also need this one: > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > >> >>>> The second system was an Intel one (4 core i7 920@2.67GHz) which was >>>> successfully loading the driver. Via xenpm I can see the various frequencies and >>>> also see them being changed. However the cpuidle data out of xenpm looks a bit odd: >>>> >>>> #> xenpm get-cpuidle-states 0 >>>> Max C-state: C7 >>>> >>>> cpu id : 0 >>>> total C-states : 2 >>>> idle time(ms) : 10819311 >>>> C0 : transition [00000000000000000001] >>>> residency [00000000000000005398 ms] >>>> C1 : transition [00000000000000000001] >>>> residency [00000000000010819311 ms] >>>> pc3 : [00000000000000000000 ms] >>>> pc6 : [00000000000000000000 ms] >>>> pc7 : [00000000000000000000 ms] >>>> cc3 : [00000000000000000000 ms] >>>> cc6 : [00000000000000000000 ms] >>>> >>>> Also gathering samples over 30s does look like only C0 and C1 are used. This >>> >>> Yes. >>>> might be because C1E support is enabled in BIOS but when looking at the >>>> intel_idle data in sysfs when running without a hypervisor will show C3 and C6 >>>> for the cores. That could have been just a wrong output, so I plugged in a power >>>> meter and compared a kernel running natively and running as dom0 (with and >>>> without the acpi-processor driver). >>>> >>>> Native: 175W >>>> dom0: 183W (with only marginal difference between with or without the >>>> processor driver) >>>> [yes, the system has a somewhat high base consumption which I attribute to a >>>> ridiculously dimensioned graphics subsystem to be running a text console] >>>> >>>> This I would take as C3 and C6 really not being used and the frequency scaling > > So the other thing I forgot to note is that C3->C6 have a detrimental > effect on some Intel boxes with Xen. We haven't figured out exactly which ones > and the bug is definitly in the hypervisor. The bug is that when the CPU goes in > those states the NIC ends up being unresponsive. Its like the interrupts stopped > being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > >>> >>> To go in deeper modes there is also a need to backport a Xen unstable >>> hypercall which will allow the kernel to detect the other states besides >>> C0-C2. >>> >>> "XEN_SET_PDC query was implemented in c/s 23783: >>> "ACPI: add _PDC input override mechanism". >>> >> >> I see. There is a kernel patch about enabling MWAIT that refers to that... > > Were there any special things you ran when checking the output? Just plugging > and looking at the results? >> >>> >>>> having no impact on the idle system is not that much surprising. But if that was >>>> true it would also limit the usefulness of the turbo mode which I understand >>>> would also be limited by the c-state of the other cores. >>> >>> Hm, I should double-check that - but somehow I thought that Xen independetly >>> checks for TurboMode and if the P-states are in, then they are activated. > > I did a bit of checking around and it does seem that is the case. From what > I have gathered the TurboMode kicks in when the CPU is C0 mode (which should > be obvious), and when the other cores are in anything but C0 mode. And sure > enough that seems to be the case. But I can't get the concrete details whether > the "but C0 mode" means that TurboMode will work better if the C mode is legacy > C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from > Len Brown more details.. >>> >> Turbo mode should be enabled. I had been only looking at a generic overview >> about it on Intel site which sounded like it would make more of a difference on >> how much one core could get overclocked related to how many cores are active >> (and I translated active or not into deeper c-states or not). >> Looking at the verbose output of turbostat it seems not to make that much >> difference whether 2-4 cores are running. A single core alone could get one more >> increment in clock stepping. That does not immediately sound a lot. And of >> course how much or long the higher clock is used depends on other factors as >> well and is not under OS control. >> >> In the end it is probably quite dynamic and hard to come up with hard facts to >> prove its value. Though if I can lower the idle power usage by reaching a bit >> further, that would greatly help to justify the effort and potential risk of >> backporting... > > I understand. I wish I could give you the exact percentage points by which > the power usage will drop. But I think the more substantial reason benefit of > these patches is performance gains. The ones that Ian Campbell ran and were > posted on Phorenix site paint that they are beneficial. > >> >>>> >>>> Do I misread the data I see? Or maybe its a known limitation? In case it is >>>> worth doing more research I'll gladly try things and gather more data. >>> >>> Just missing some patches. >>> >>> Oh, and this one: >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> >>> Hmm.. I think a patch disappeared somewhere. > > That was the one I referenced at the beginning of this email. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:36:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22: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 ) id 1SPLfq-0004jK-TE; Tue, 01 May 2012 22:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLfp-0004jF-5u for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:35:57 +0000 Received: from [85.158.138.51:6406] by server-9.bemta-3.messagelabs.com id 79/4F-26691-C4560AF4; Tue, 01 May 2012 22:35:56 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1335911753!24701702!1 X-Originating-IP: [65.55.88.11] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27306 invoked from network); 1 May 2012 22:35:54 -0000 Received: from tx2ehsobe001.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.11) by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 May 2012 22:35:54 -0000 Received: from mail129-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 May 2012 22:35:45 +0000 Received: from mail129-tx2 (localhost [127.0.0.1]) by mail129-tx2-R.bigfish.com (Postfix) with ESMTP id 7F509440191; Tue, 1 May 2012 22:35:45 +0000 (UTC) X-SpamScore: -17 X-BigFish: VPS-17(zzbb2dI9371I1432N98dK179dNzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2 (MessageSwitch) id 133591174360014_24320; Tue, 1 May 2012 22:35:43 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.246]) by mail129-tx2.bigfish.com (Postfix) with ESMTP id 0883DC0059; Tue, 1 May 2012 22:35:43 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server id 14.1.225.23; Tue, 1 May 2012 22:35:42 +0000 X-WSS-ID: 0M3D83L-02-DOY-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 282B3C80F8; Tue, 1 May 2012 17:35:44 -0500 (CDT) 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, 1 May 2012 17:35:55 -0500 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, 1 May 2012 17:35:46 -0500 Message-ID: <4FA06541.7050607@amd.com> Date: Tue, 1 May 2012 18:35:45 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk , Stefan Bader References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> In-Reply-To: <20120501200207.GA15313@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>> Since there have been requests about that driver to get backported into 3.2, I >>>> was interested to find out what or how much would be gained by that. >>>> >>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which >>>> was not very successful as the drivers bail out of the init function because the >>>> first call to acpi_processor_register_performance() returns -ENODEV. There is >>>> some frequency scaling when running without Xen, so I need to do some more >>>> debugging there. I believe this is caused by the somewhat under-enlightened xen_apic_read(): static u32 xen_apic_read(u32 reg) { return 0; } This results in some data, most importantly boot_cpu_physical_apicid, not being set correctly and, in turn, causes x86_cpu_to_apicid to be broken. On larger AMD systems boot processor is typically APICID=0x20 (I don't have Intel system handy to see how it looks there). As a quick and dirty test you can try: diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index edc2448..1f78998 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long address) } if (boot_cpu_physical_apicid == -1U) { boot_cpu_physical_apicid = read_apic_id(); + boot_cpu_physical_apicid = 32; apic_version[boot_cpu_physical_apicid] = GET_APIC_VERSION(apic_read(APIC_LVR)); } (Set it to whatever APICID on core0 is, I suspect it won't be zero). -boris >>> >>> Did you back-port the other components - the ones that turn off the native >>> frequency scalling? >>> >>> provide disable_cpufreq() function to disable the API. >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loading >>>> >> >> Yes, here is the full set for reference: >> >> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading. >> * xen/acpi: Remove the WARN's as they just create noise. >> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >> * xen/acpi-processor: C and P-state driver that uploads said data to hyper >> * provide disable_cpufreq() function to disable the API. > > And (Linus just pulled it), you also need this one: > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > >> >>>> The second system was an Intel one (4 core i7 920@2.67GHz) which was >>>> successfully loading the driver. Via xenpm I can see the various frequencies and >>>> also see them being changed. However the cpuidle data out of xenpm looks a bit odd: >>>> >>>> #> xenpm get-cpuidle-states 0 >>>> Max C-state: C7 >>>> >>>> cpu id : 0 >>>> total C-states : 2 >>>> idle time(ms) : 10819311 >>>> C0 : transition [00000000000000000001] >>>> residency [00000000000000005398 ms] >>>> C1 : transition [00000000000000000001] >>>> residency [00000000000010819311 ms] >>>> pc3 : [00000000000000000000 ms] >>>> pc6 : [00000000000000000000 ms] >>>> pc7 : [00000000000000000000 ms] >>>> cc3 : [00000000000000000000 ms] >>>> cc6 : [00000000000000000000 ms] >>>> >>>> Also gathering samples over 30s does look like only C0 and C1 are used. This >>> >>> Yes. >>>> might be because C1E support is enabled in BIOS but when looking at the >>>> intel_idle data in sysfs when running without a hypervisor will show C3 and C6 >>>> for the cores. That could have been just a wrong output, so I plugged in a power >>>> meter and compared a kernel running natively and running as dom0 (with and >>>> without the acpi-processor driver). >>>> >>>> Native: 175W >>>> dom0: 183W (with only marginal difference between with or without the >>>> processor driver) >>>> [yes, the system has a somewhat high base consumption which I attribute to a >>>> ridiculously dimensioned graphics subsystem to be running a text console] >>>> >>>> This I would take as C3 and C6 really not being used and the frequency scaling > > So the other thing I forgot to note is that C3->C6 have a detrimental > effect on some Intel boxes with Xen. We haven't figured out exactly which ones > and the bug is definitly in the hypervisor. The bug is that when the CPU goes in > those states the NIC ends up being unresponsive. Its like the interrupts stopped > being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > >>> >>> To go in deeper modes there is also a need to backport a Xen unstable >>> hypercall which will allow the kernel to detect the other states besides >>> C0-C2. >>> >>> "XEN_SET_PDC query was implemented in c/s 23783: >>> "ACPI: add _PDC input override mechanism". >>> >> >> I see. There is a kernel patch about enabling MWAIT that refers to that... > > Were there any special things you ran when checking the output? Just plugging > and looking at the results? >> >>> >>>> having no impact on the idle system is not that much surprising. But if that was >>>> true it would also limit the usefulness of the turbo mode which I understand >>>> would also be limited by the c-state of the other cores. >>> >>> Hm, I should double-check that - but somehow I thought that Xen independetly >>> checks for TurboMode and if the P-states are in, then they are activated. > > I did a bit of checking around and it does seem that is the case. From what > I have gathered the TurboMode kicks in when the CPU is C0 mode (which should > be obvious), and when the other cores are in anything but C0 mode. And sure > enough that seems to be the case. But I can't get the concrete details whether > the "but C0 mode" means that TurboMode will work better if the C mode is legacy > C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from > Len Brown more details.. >>> >> Turbo mode should be enabled. I had been only looking at a generic overview >> about it on Intel site which sounded like it would make more of a difference on >> how much one core could get overclocked related to how many cores are active >> (and I translated active or not into deeper c-states or not). >> Looking at the verbose output of turbostat it seems not to make that much >> difference whether 2-4 cores are running. A single core alone could get one more >> increment in clock stepping. That does not immediately sound a lot. And of >> course how much or long the higher clock is used depends on other factors as >> well and is not under OS control. >> >> In the end it is probably quite dynamic and hard to come up with hard facts to >> prove its value. Though if I can lower the idle power usage by reaching a bit >> further, that would greatly help to justify the effort and potential risk of >> backporting... > > I understand. I wish I could give you the exact percentage points by which > the power usage will drop. But I think the more substantial reason benefit of > these patches is performance gains. The ones that Ian Campbell ran and were > posted on Phorenix site paint that they are beneficial. > >> >>>> >>>> Do I misread the data I see? Or maybe its a known limitation? In case it is >>>> worth doing more research I'll gladly try things and gather more data. >>> >>> Just missing some patches. >>> >>> Oh, and this one: >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> >>> Hmm.. I think a patch disappeared somewhere. > > That was the one I referenced at the beginning of this email. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:53:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22:53:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLwS-000575-7X; Tue, 01 May 2012 22:53:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLwQ-000570-Gm for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:53:06 +0000 Received: from [85.158.143.99:11451] by server-3.bemta-4.messagelabs.com id 52/5F-05853-15960AF4; Tue, 01 May 2012 22:53:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1335912785!26073361!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28668 invoked from network); 1 May 2012 22:53:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 22:53:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12233556" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 22:53:04 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 23:53:04 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPLwO-0003Tm-Ij; Tue, 01 May 2012 22:53:04 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPLwL-0003Qc-AF; Tue, 01 May 2012 23:53:04 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 23:53:01 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12770: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12770 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12770/ 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. 12746 test-amd64-i386-xl-credit2 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 22:53:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 22:53:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLwS-000575-7X; Tue, 01 May 2012 22:53:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPLwQ-000570-Gm for xen-devel@lists.xensource.com; Tue, 01 May 2012 22:53:06 +0000 Received: from [85.158.143.99:11451] by server-3.bemta-4.messagelabs.com id 52/5F-05853-15960AF4; Tue, 01 May 2012 22:53:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1335912785!26073361!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28668 invoked from network); 1 May 2012 22:53:05 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 22:53:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="12233556" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 22:53:04 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 1 May 2012 23:53:04 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPLwO-0003Tm-Ij; Tue, 01 May 2012 22:53:04 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPLwL-0003Qc-AF; Tue, 01 May 2012 23:53:04 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 1 May 2012 23:53:01 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12770: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12770 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12770/ 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. 12746 test-amd64-i386-xl-credit2 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:00:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPM39-0005L4-4D; Tue, 01 May 2012 23:00:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPM37-0005J5-K5 for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:00:01 +0000 Received: from [85.158.143.99:24348] by server-1.bemta-4.messagelabs.com id 30/61-20925-0FA60AF4; Tue, 01 May 2012 23:00:00 +0000 X-Env-Sender: swaplinker@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335913198!25148236!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12209 invoked from network); 1 May 2012 23:00:00 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 23:00:00 -0000 Received: by obfk16 with SMTP id k16so76391obf.30 for ; Tue, 01 May 2012 15:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=tYX+utWqZbNLAC4RQ6FZLXpiZ3ZKPlcP71oHmbaK+aA=; b=UHXjafgKJ6eGQ4OXd4zFh2AngBIG9MzGcyjnuVCu3P+WsVL/ut5oxdHp4d/t2vUnyF 5NhKLZtIbR4Hf9Y+9MRMV9BwfRD58NbGgtRNRcsqL2R9sauFU8ynigmtnPWW/YBfTPxa +1VgxvGjf0LAE5s9uGgk1GlNqGwylHfVkWhKQV272zejZ+EBqGMCq2euOKzZs27W77yb 7iEyteFmSnmqXaxCXHkQds5hVaXDK1eU4hOSBKjzvzlJEkGLdR8FwlTXSHvXUNhHGUJc DuZe6h+muEQZNwoQBtGJl0AqAyliNyd3dCUQJSPnd/KtDModInxLCPlucDEznsHRnobm s7pg== Received: by 10.60.20.38 with SMTP id k6mr36624246oee.26.1335913198578; Tue, 01 May 2012 15:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.168.172 with HTTP; Tue, 1 May 2012 15:59:38 -0700 (PDT) In-Reply-To: <20120501221756.GA69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> From: Julian Pidancet Date: Tue, 1 May 2012 23:59:38 +0100 X-Google-Sender-Auth: MTKZeNgPf4CxcxNBXY5o0ktc4zA Message-ID: To: Tim Deegan Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCBNYXkgMSwgMjAxMiBhdCAxMToxNyBQTSwgVGltIERlZWdhbiA8dGltQHhlbi5vcmc+ IHdyb3RlOgo+IEF0IDIwOjQ3ICswMTAwIG9uIDAxIE1heSAoMTMzNTkwNTI0MCksIEp1bGlhbiBQ aWRhbmNldCB3cm90ZToKPj4gSSBkb24ndCB0aGluayBBQ1BJIGFuZCBTTUJJT1MgZmlybXdhcmUg cGFzc3Rocm91Z2ggYXJlIHRoZSBvbmx5IHVzZQo+PiBjYXNlcyBoZXJlLgo+Pgo+PiBUaGUgbW9k dWxlIGFyY2hpdGVjdHVyZSBjb3VsZCBhbHNvIGJlIHVzZWQgdG8gcGFzcyB0aGUgQklPUyBhbmQg T3B0aW9uCj4+IFJPTXMgdG8gaHZtbG9hZGVyLiBUaGUgdG9vbHN0YWNrIGNvdWxkIGxvYWQgdGhl bSBmcm9tIGRvbTAncyBmaWxlc3lzdGVtCj4+IGR5bmFtaWNhbGx5IGFuZCBwYXNzIHRoZW0gdG8g aHZtbG9hZGVyLCBpbnN0ZWFkIG9mIGhhdmluZyB0aGVtCj4+IGNvbXBpbGVkLWluIHN0YXRpY2Fs bHkgaW4gaHZtbG9hZGVyLgo+Cj4gQUZBSUsgdGhlIEJJT1MgY2FuIGFscmVhZHkgbG9hZCBvcHRp b24gUk9NcyBmcm9tIHJlYWwgb3IgZW11bGF0ZWQKPiBoYXJkd2FyZSwgdGhlIHdheSBhIHJlYWwg QklPUyBkb2VzLCBhbmQgSSB0aGluayB0aGF0J3MgYSBnb29kIGludGVyZmFjZS4KPgoKVGhhdCdz IHRydWUgZm9yIFNlYUJJT1MsIGJ1dCB3aGVuIHVzaW5nIHJvbWJpb3MsIGh2bWxvYWRlciBsb2Fk cyB0aGUKVkdBIG9wdGlvbiBST00gYW5kIGV0aGVyYm9vdCBpbnRvIHRoZSBWTSdzIGFkZHJlc3Mg c3BhY2UgYmVmb3JlCmV4ZWN1dGluZyB0aGUgQklPUy4KCj4gSXMgbG9hZGluZyBhIGN1c3RvbSBC SU9TIChhcyBvcHBvc2VkIHRvIG9wdGlvbiBST00pIHNvbWV0aGluZyB5b3UKPiBhY3R1YWxseSB3 YW50IHRvIGRvLCBCVFc/Cj4KClllcy4KCj4+IFdvdWxkIHdlIHN0aWxsIGJlIGFibGUgdG8gZG8g dGhhdCB3aXRoIHRoZSBzaW1wbGlmaWNhdGlvbnMgeW91J3JlCj4+IHN1Z2dlc3RpbmcgaGVyZSA/ Cj4KPiBZZXMsIHlvdSBjb3VsZCBkZWZpbml0ZWx5IGRvIGl0IHdpdGhvdXQgYWxsIHRoaXMgbW9k dWxlIHN0dWZmLiDCoFBhc3NpbmcKPiBhbiBhZGRyZXNzIGFuZCBsZW5ndGggaW4gWGVuc3RvcmUg d291bGQgd29yay4KPgoKSXNuJ3QgaXQga2luZCBvZiB0aGUgc2FtZSB0aGluZyA/IEkgbWVhbiwg dGhlIEJJT1Mgb3IgYW4gT3B0aW9uIFJPTSB0bwpwcmUtbG9hZCBjb3VsZCBiZSBzZWVuIGJ5IGh2 bWxvYWRlciBhcyAibW9kdWxlcyIgYmVjYXVzZSB0aGV5IHdvdWxkCmhhdmUgdG8gYmUgcGFzc2Vk IGJ5IHRoZSB0b29sc3RhY2sgdGhlIHNhbWUgd2F5IGFzIEFDUEkgb3IgU01CSU9TCnRhYmxlcy4K Ci0tIApKdWxpYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue May 01 23:00:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPM39-0005L4-4D; Tue, 01 May 2012 23:00:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPM37-0005J5-K5 for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:00:01 +0000 Received: from [85.158.143.99:24348] by server-1.bemta-4.messagelabs.com id 30/61-20925-0FA60AF4; Tue, 01 May 2012 23:00:00 +0000 X-Env-Sender: swaplinker@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335913198!25148236!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12209 invoked from network); 1 May 2012 23:00:00 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 23:00:00 -0000 Received: by obfk16 with SMTP id k16so76391obf.30 for ; Tue, 01 May 2012 15:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=tYX+utWqZbNLAC4RQ6FZLXpiZ3ZKPlcP71oHmbaK+aA=; b=UHXjafgKJ6eGQ4OXd4zFh2AngBIG9MzGcyjnuVCu3P+WsVL/ut5oxdHp4d/t2vUnyF 5NhKLZtIbR4Hf9Y+9MRMV9BwfRD58NbGgtRNRcsqL2R9sauFU8ynigmtnPWW/YBfTPxa +1VgxvGjf0LAE5s9uGgk1GlNqGwylHfVkWhKQV272zejZ+EBqGMCq2euOKzZs27W77yb 7iEyteFmSnmqXaxCXHkQds5hVaXDK1eU4hOSBKjzvzlJEkGLdR8FwlTXSHvXUNhHGUJc DuZe6h+muEQZNwoQBtGJl0AqAyliNyd3dCUQJSPnd/KtDModInxLCPlucDEznsHRnobm s7pg== Received: by 10.60.20.38 with SMTP id k6mr36624246oee.26.1335913198578; Tue, 01 May 2012 15:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.168.172 with HTTP; Tue, 1 May 2012 15:59:38 -0700 (PDT) In-Reply-To: <20120501221756.GA69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> From: Julian Pidancet Date: Tue, 1 May 2012 23:59:38 +0100 X-Google-Sender-Auth: MTKZeNgPf4CxcxNBXY5o0ktc4zA Message-ID: To: Tim Deegan Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCBNYXkgMSwgMjAxMiBhdCAxMToxNyBQTSwgVGltIERlZWdhbiA8dGltQHhlbi5vcmc+ IHdyb3RlOgo+IEF0IDIwOjQ3ICswMTAwIG9uIDAxIE1heSAoMTMzNTkwNTI0MCksIEp1bGlhbiBQ aWRhbmNldCB3cm90ZToKPj4gSSBkb24ndCB0aGluayBBQ1BJIGFuZCBTTUJJT1MgZmlybXdhcmUg cGFzc3Rocm91Z2ggYXJlIHRoZSBvbmx5IHVzZQo+PiBjYXNlcyBoZXJlLgo+Pgo+PiBUaGUgbW9k dWxlIGFyY2hpdGVjdHVyZSBjb3VsZCBhbHNvIGJlIHVzZWQgdG8gcGFzcyB0aGUgQklPUyBhbmQg T3B0aW9uCj4+IFJPTXMgdG8gaHZtbG9hZGVyLiBUaGUgdG9vbHN0YWNrIGNvdWxkIGxvYWQgdGhl bSBmcm9tIGRvbTAncyBmaWxlc3lzdGVtCj4+IGR5bmFtaWNhbGx5IGFuZCBwYXNzIHRoZW0gdG8g aHZtbG9hZGVyLCBpbnN0ZWFkIG9mIGhhdmluZyB0aGVtCj4+IGNvbXBpbGVkLWluIHN0YXRpY2Fs bHkgaW4gaHZtbG9hZGVyLgo+Cj4gQUZBSUsgdGhlIEJJT1MgY2FuIGFscmVhZHkgbG9hZCBvcHRp b24gUk9NcyBmcm9tIHJlYWwgb3IgZW11bGF0ZWQKPiBoYXJkd2FyZSwgdGhlIHdheSBhIHJlYWwg QklPUyBkb2VzLCBhbmQgSSB0aGluayB0aGF0J3MgYSBnb29kIGludGVyZmFjZS4KPgoKVGhhdCdz IHRydWUgZm9yIFNlYUJJT1MsIGJ1dCB3aGVuIHVzaW5nIHJvbWJpb3MsIGh2bWxvYWRlciBsb2Fk cyB0aGUKVkdBIG9wdGlvbiBST00gYW5kIGV0aGVyYm9vdCBpbnRvIHRoZSBWTSdzIGFkZHJlc3Mg c3BhY2UgYmVmb3JlCmV4ZWN1dGluZyB0aGUgQklPUy4KCj4gSXMgbG9hZGluZyBhIGN1c3RvbSBC SU9TIChhcyBvcHBvc2VkIHRvIG9wdGlvbiBST00pIHNvbWV0aGluZyB5b3UKPiBhY3R1YWxseSB3 YW50IHRvIGRvLCBCVFc/Cj4KClllcy4KCj4+IFdvdWxkIHdlIHN0aWxsIGJlIGFibGUgdG8gZG8g dGhhdCB3aXRoIHRoZSBzaW1wbGlmaWNhdGlvbnMgeW91J3JlCj4+IHN1Z2dlc3RpbmcgaGVyZSA/ Cj4KPiBZZXMsIHlvdSBjb3VsZCBkZWZpbml0ZWx5IGRvIGl0IHdpdGhvdXQgYWxsIHRoaXMgbW9k dWxlIHN0dWZmLiDCoFBhc3NpbmcKPiBhbiBhZGRyZXNzIGFuZCBsZW5ndGggaW4gWGVuc3RvcmUg d291bGQgd29yay4KPgoKSXNuJ3QgaXQga2luZCBvZiB0aGUgc2FtZSB0aGluZyA/IEkgbWVhbiwg dGhlIEJJT1Mgb3IgYW4gT3B0aW9uIFJPTSB0bwpwcmUtbG9hZCBjb3VsZCBiZSBzZWVuIGJ5IGh2 bWxvYWRlciBhcyAibW9kdWxlcyIgYmVjYXVzZSB0aGV5IHdvdWxkCmhhdmUgdG8gYmUgcGFzc2Vk IGJ5IHRoZSB0b29sc3RhY2sgdGhlIHNhbWUgd2F5IGFzIEFDUEkgb3IgU01CSU9TCnRhYmxlcy4K Ci0tIApKdWxpYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue May 01 23:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPM3t-0005Ni-I4; Tue, 01 May 2012 23:00:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPM3r-0005NT-NQ for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:00:48 +0000 Received: from [85.158.138.51:17896] by server-6.bemta-3.messagelabs.com id 60/D8-05145-E1B60AF4; Tue, 01 May 2012 23:00:46 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1335913244!24622322!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17254 invoked from network); 1 May 2012 23:00:45 -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; 1 May 2012 23:00:45 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41N0dsY030559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 23:00: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 q41N0coG000320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 23:00:38 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 q41N0bxp023387; Tue, 1 May 2012 18:00:37 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 16:00:37 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5352C40357; Tue, 1 May 2012 18:54:56 -0400 (EDT) Date: Tue, 1 May 2012 18:54:56 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120501225456.GA13757@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA06541.7050607@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > >>On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > >>>On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >>>>Since there have been requests about that driver to get backported into 3.2, I > >>>>was interested to find out what or how much would be gained by that. > >>>> > >>>>The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > >>>>was not very successful as the drivers bail out of the init function because the > >>>>first call to acpi_processor_register_performance() returns -ENODEV. There is > >>>>some frequency scaling when running without Xen, so I need to do some more > >>>>debugging there. > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > static u32 xen_apic_read(u32 reg) > { > return 0; > } > > This results in some data, most importantly > boot_cpu_physical_apicid, not being set correctly and, in turn, > causes x86_cpu_to_apicid to be broken. What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? Or is this more of a stab in the dark? Stefan, one way to debug this is to make the driver be a module and then configure the /sys/../acpi/debug_level and debug_layer to be 0xffffffff and try loading the module. It should print out tons of data (And the reason it returned -Exxx). > > On larger AMD systems boot processor is typically APICID=0x20 (I > don't have Intel system handy to see how it looks there). > > As a quick and dirty test you can try: > > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned > long address) > } > if (boot_cpu_physical_apicid == -1U) { > boot_cpu_physical_apicid = read_apic_id(); > + boot_cpu_physical_apicid = 32; > apic_version[boot_cpu_physical_apicid] = > GET_APIC_VERSION(apic_read(APIC_LVR)); > } > > > (Set it to whatever APICID on core0 is, I suspect it won't be zero). > > -boris > > > >>> > >>>Did you back-port the other components - the ones that turn off the native > >>>frequency scalling? > >>> > >>> provide disable_cpufreq() function to disable the API. > >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loading > >>>> > >> > >>Yes, here is the full set for reference: > >> > >>* xen/cpufreq: Disable the cpu frequency scaling drivers from loading. > >>* xen/acpi: Remove the WARN's as they just create noise. > >>* xen/acpi: Fix Kconfig dependency on CPU_FREQ > >>* xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > >>* xen/acpi-processor: C and P-state driver that uploads said data to hyper > >>* provide disable_cpufreq() function to disable the API. > > > >And (Linus just pulled it), you also need this one: > > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > > > >> > >>>>The second system was an Intel one (4 core i7 920@2.67GHz) which was > >>>>successfully loading the driver. Via xenpm I can see the various frequencies and > >>>>also see them being changed. However the cpuidle data out of xenpm looks a bit odd: > >>>> > >>>>#> xenpm get-cpuidle-states 0 > >>>>Max C-state: C7 > >>>> > >>>>cpu id : 0 > >>>>total C-states : 2 > >>>>idle time(ms) : 10819311 > >>>>C0 : transition [00000000000000000001] > >>>> residency [00000000000000005398 ms] > >>>>C1 : transition [00000000000000000001] > >>>> residency [00000000000010819311 ms] > >>>>pc3 : [00000000000000000000 ms] > >>>>pc6 : [00000000000000000000 ms] > >>>>pc7 : [00000000000000000000 ms] > >>>>cc3 : [00000000000000000000 ms] > >>>>cc6 : [00000000000000000000 ms] > >>>> > >>>>Also gathering samples over 30s does look like only C0 and C1 are used. This > >>> > >>>Yes. > >>>>might be because C1E support is enabled in BIOS but when looking at the > >>>>intel_idle data in sysfs when running without a hypervisor will show C3 and C6 > >>>>for the cores. That could have been just a wrong output, so I plugged in a power > >>>>meter and compared a kernel running natively and running as dom0 (with and > >>>>without the acpi-processor driver). > >>>> > >>>>Native: 175W > >>>>dom0: 183W (with only marginal difference between with or without the > >>>> processor driver) > >>>>[yes, the system has a somewhat high base consumption which I attribute to a > >>>>ridiculously dimensioned graphics subsystem to be running a text console] > >>>> > >>>>This I would take as C3 and C6 really not being used and the frequency scaling > > > >So the other thing I forgot to note is that C3->C6 have a detrimental > >effect on some Intel boxes with Xen. We haven't figured out exactly which ones > >and the bug is definitly in the hypervisor. The bug is that when the CPU goes in > >those states the NIC ends up being unresponsive. Its like the interrupts stopped > >being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > > > >>> > >>>To go in deeper modes there is also a need to backport a Xen unstable > >>>hypercall which will allow the kernel to detect the other states besides > >>>C0-C2. > >>> > >>>"XEN_SET_PDC query was implemented in c/s 23783: > >>> "ACPI: add _PDC input override mechanism". > >>> > >> > >>I see. There is a kernel patch about enabling MWAIT that refers to that... > > > >Were there any special things you ran when checking the output? Just plugging > >and looking at the results? > >> > >>> > >>>>having no impact on the idle system is not that much surprising. But if that was > >>>>true it would also limit the usefulness of the turbo mode which I understand > >>>>would also be limited by the c-state of the other cores. > >>> > >>>Hm, I should double-check that - but somehow I thought that Xen independetly > >>>checks for TurboMode and if the P-states are in, then they are activated. > > > >I did a bit of checking around and it does seem that is the case. From what > >I have gathered the TurboMode kicks in when the CPU is C0 mode (which should > >be obvious), and when the other cores are in anything but C0 mode. And sure > >enough that seems to be the case. But I can't get the concrete details whether > >the "but C0 mode" means that TurboMode will work better if the C mode is legacy > >C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from > >Len Brown more details.. > >>> > >>Turbo mode should be enabled. I had been only looking at a generic overview > >>about it on Intel site which sounded like it would make more of a difference on > >>how much one core could get overclocked related to how many cores are active > >>(and I translated active or not into deeper c-states or not). > >>Looking at the verbose output of turbostat it seems not to make that much > >>difference whether 2-4 cores are running. A single core alone could get one more > >>increment in clock stepping. That does not immediately sound a lot. And of > >>course how much or long the higher clock is used depends on other factors as > >>well and is not under OS control. > >> > >>In the end it is probably quite dynamic and hard to come up with hard facts to > >>prove its value. Though if I can lower the idle power usage by reaching a bit > >>further, that would greatly help to justify the effort and potential risk of > >>backporting... > > > >I understand. I wish I could give you the exact percentage points by which > >the power usage will drop. But I think the more substantial reason benefit of > >these patches is performance gains. The ones that Ian Campbell ran and were > >posted on Phorenix site paint that they are beneficial. > > > >> > >>>> > >>>>Do I misread the data I see? Or maybe its a known limitation? In case it is > >>>>worth doing more research I'll gladly try things and gather more data. > >>> > >>>Just missing some patches. > >>> > >>>Oh, and this one: > >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ > >>> > >>>Hmm.. I think a patch disappeared somewhere. > > > >That was the one I referenced at the beginning of this email. > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xen.org > >http://lists.xen.org/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPM3t-0005Ni-I4; Tue, 01 May 2012 23:00:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPM3r-0005NT-NQ for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:00:48 +0000 Received: from [85.158.138.51:17896] by server-6.bemta-3.messagelabs.com id 60/D8-05145-E1B60AF4; Tue, 01 May 2012 23:00:46 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1335913244!24622322!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17254 invoked from network); 1 May 2012 23:00:45 -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; 1 May 2012 23:00:45 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q41N0dsY030559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 23:00: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 q41N0coG000320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 23:00:38 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 q41N0bxp023387; Tue, 1 May 2012 18:00:37 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 16:00:37 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5352C40357; Tue, 1 May 2012 18:54:56 -0400 (EDT) Date: Tue, 1 May 2012 18:54:56 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120501225456.GA13757@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA06541.7050607@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > >>On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > >>>On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >>>>Since there have been requests about that driver to get backported into 3.2, I > >>>>was interested to find out what or how much would be gained by that. > >>>> > >>>>The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > >>>>was not very successful as the drivers bail out of the init function because the > >>>>first call to acpi_processor_register_performance() returns -ENODEV. There is > >>>>some frequency scaling when running without Xen, so I need to do some more > >>>>debugging there. > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > static u32 xen_apic_read(u32 reg) > { > return 0; > } > > This results in some data, most importantly > boot_cpu_physical_apicid, not being set correctly and, in turn, > causes x86_cpu_to_apicid to be broken. What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? Or is this more of a stab in the dark? Stefan, one way to debug this is to make the driver be a module and then configure the /sys/../acpi/debug_level and debug_layer to be 0xffffffff and try loading the module. It should print out tons of data (And the reason it returned -Exxx). > > On larger AMD systems boot processor is typically APICID=0x20 (I > don't have Intel system handy to see how it looks there). > > As a quick and dirty test you can try: > > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned > long address) > } > if (boot_cpu_physical_apicid == -1U) { > boot_cpu_physical_apicid = read_apic_id(); > + boot_cpu_physical_apicid = 32; > apic_version[boot_cpu_physical_apicid] = > GET_APIC_VERSION(apic_read(APIC_LVR)); > } > > > (Set it to whatever APICID on core0 is, I suspect it won't be zero). > > -boris > > > >>> > >>>Did you back-port the other components - the ones that turn off the native > >>>frequency scalling? > >>> > >>> provide disable_cpufreq() function to disable the API. > >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loading > >>>> > >> > >>Yes, here is the full set for reference: > >> > >>* xen/cpufreq: Disable the cpu frequency scaling drivers from loading. > >>* xen/acpi: Remove the WARN's as they just create noise. > >>* xen/acpi: Fix Kconfig dependency on CPU_FREQ > >>* xen/acpi-processor: Do not depend on CPU frequency scaling drivers. > >>* xen/acpi-processor: C and P-state driver that uploads said data to hyper > >>* provide disable_cpufreq() function to disable the API. > > > >And (Linus just pulled it), you also need this one: > > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.) > > > >> > >>>>The second system was an Intel one (4 core i7 920@2.67GHz) which was > >>>>successfully loading the driver. Via xenpm I can see the various frequencies and > >>>>also see them being changed. However the cpuidle data out of xenpm looks a bit odd: > >>>> > >>>>#> xenpm get-cpuidle-states 0 > >>>>Max C-state: C7 > >>>> > >>>>cpu id : 0 > >>>>total C-states : 2 > >>>>idle time(ms) : 10819311 > >>>>C0 : transition [00000000000000000001] > >>>> residency [00000000000000005398 ms] > >>>>C1 : transition [00000000000000000001] > >>>> residency [00000000000010819311 ms] > >>>>pc3 : [00000000000000000000 ms] > >>>>pc6 : [00000000000000000000 ms] > >>>>pc7 : [00000000000000000000 ms] > >>>>cc3 : [00000000000000000000 ms] > >>>>cc6 : [00000000000000000000 ms] > >>>> > >>>>Also gathering samples over 30s does look like only C0 and C1 are used. This > >>> > >>>Yes. > >>>>might be because C1E support is enabled in BIOS but when looking at the > >>>>intel_idle data in sysfs when running without a hypervisor will show C3 and C6 > >>>>for the cores. That could have been just a wrong output, so I plugged in a power > >>>>meter and compared a kernel running natively and running as dom0 (with and > >>>>without the acpi-processor driver). > >>>> > >>>>Native: 175W > >>>>dom0: 183W (with only marginal difference between with or without the > >>>> processor driver) > >>>>[yes, the system has a somewhat high base consumption which I attribute to a > >>>>ridiculously dimensioned graphics subsystem to be running a text console] > >>>> > >>>>This I would take as C3 and C6 really not being used and the frequency scaling > > > >So the other thing I forgot to note is that C3->C6 have a detrimental > >effect on some Intel boxes with Xen. We haven't figured out exactly which ones > >and the bug is definitly in the hypervisor. The bug is that when the CPU goes in > >those states the NIC ends up being unresponsive. Its like the interrupts stopped > >being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. > > > >>> > >>>To go in deeper modes there is also a need to backport a Xen unstable > >>>hypercall which will allow the kernel to detect the other states besides > >>>C0-C2. > >>> > >>>"XEN_SET_PDC query was implemented in c/s 23783: > >>> "ACPI: add _PDC input override mechanism". > >>> > >> > >>I see. There is a kernel patch about enabling MWAIT that refers to that... > > > >Were there any special things you ran when checking the output? Just plugging > >and looking at the results? > >> > >>> > >>>>having no impact on the idle system is not that much surprising. But if that was > >>>>true it would also limit the usefulness of the turbo mode which I understand > >>>>would also be limited by the c-state of the other cores. > >>> > >>>Hm, I should double-check that - but somehow I thought that Xen independetly > >>>checks for TurboMode and if the P-states are in, then they are activated. > > > >I did a bit of checking around and it does seem that is the case. From what > >I have gathered the TurboMode kicks in when the CPU is C0 mode (which should > >be obvious), and when the other cores are in anything but C0 mode. And sure > >enough that seems to be the case. But I can't get the concrete details whether > >the "but C0 mode" means that TurboMode will work better if the C mode is legacy > >C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out from > >Len Brown more details.. > >>> > >>Turbo mode should be enabled. I had been only looking at a generic overview > >>about it on Intel site which sounded like it would make more of a difference on > >>how much one core could get overclocked related to how many cores are active > >>(and I translated active or not into deeper c-states or not). > >>Looking at the verbose output of turbostat it seems not to make that much > >>difference whether 2-4 cores are running. A single core alone could get one more > >>increment in clock stepping. That does not immediately sound a lot. And of > >>course how much or long the higher clock is used depends on other factors as > >>well and is not under OS control. > >> > >>In the end it is probably quite dynamic and hard to come up with hard facts to > >>prove its value. Though if I can lower the idle power usage by reaching a bit > >>further, that would greatly help to justify the effort and potential risk of > >>backporting... > > > >I understand. I wish I could give you the exact percentage points by which > >the power usage will drop. But I think the more substantial reason benefit of > >these patches is performance gains. The ones that Ian Campbell ran and were > >posted on Phorenix site paint that they are beneficial. > > > >> > >>>> > >>>>Do I misread the data I see? Or maybe its a known limitation? In case it is > >>>>worth doing more research I'll gladly try things and gather more data. > >>> > >>>Just missing some patches. > >>> > >>>Oh, and this one: > >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ > >>> > >>>Hmm.. I think a patch disappeared somewhere. > > > >That was the one I referenced at the beginning of this email. > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xen.org > >http://lists.xen.org/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:22:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPMOM-00064N-9C; Tue, 01 May 2012 23:21:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMOK-00064I-Hp for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:21:56 +0000 Received: from [85.158.139.83:21173] by server-4.bemta-5.messagelabs.com id F9/6C-10788-31070AF4; Tue, 01 May 2012 23:21:55 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1335914514!23597314!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8096 invoked from network); 1 May 2012 23:21:55 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 23:21:55 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPMOG-000IDs-A2; Tue, 01 May 2012 23:21:52 +0000 Date: Wed, 2 May 2012 00:21:52 +0100 From: Tim Deegan To: Julian Pidancet Message-ID: <20120501232152.GB69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 23:59 +0100 on 01 May (1335916778), Julian Pidancet wrote: > >> Would we still be able to do that with the simplifications you're > >> suggesting here ? > > > > Yes, you could definitely do it without all this module stuff. =A0Passi= ng > > an address and length in Xenstore would work. > = > Isn't it kind of the same thing ? I mean, the BIOS or an Option ROM to > pre-load could be seen by hvmloader as "modules" because they would > have to be passed by the toolstack the same way as ACPI or SMBIOS > tables. Yes, it's similar. But the new module marshalling/unmarshalling code isn't necessary for any of them. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:22:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23: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 ) id 1SPMOM-00064N-9C; Tue, 01 May 2012 23:21:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMOK-00064I-Hp for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:21:56 +0000 Received: from [85.158.139.83:21173] by server-4.bemta-5.messagelabs.com id F9/6C-10788-31070AF4; Tue, 01 May 2012 23:21:55 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1335914514!23597314!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8096 invoked from network); 1 May 2012 23:21:55 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 23:21:55 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPMOG-000IDs-A2; Tue, 01 May 2012 23:21:52 +0000 Date: Wed, 2 May 2012 00:21:52 +0100 From: Tim Deegan To: Julian Pidancet Message-ID: <20120501232152.GB69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 23:59 +0100 on 01 May (1335916778), Julian Pidancet wrote: > >> Would we still be able to do that with the simplifications you're > >> suggesting here ? > > > > Yes, you could definitely do it without all this module stuff. =A0Passi= ng > > an address and length in Xenstore would work. > = > Isn't it kind of the same thing ? I mean, the BIOS or an Option ROM to > pre-load could be seen by hvmloader as "modules" because they would > have to be passed by the toolstack the same way as ACPI or SMBIOS > tables. Yes, it's similar. But the new module marshalling/unmarshalling code isn't necessary for any of them. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:57:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23:57:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMvk-0006vd-F5; Tue, 01 May 2012 23:56:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMvi-0006vY-NN for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:56:27 +0000 Received: from [193.109.254.147:47266] by server-6.bemta-14.messagelabs.com id 30/92-04960-92870AF4; Tue, 01 May 2012 23:56:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1335916585!7180220!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7914 invoked from network); 1 May 2012 23:56:25 -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 May 2012 23:56:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,513,1330905600"; d="scan'208";a="12233934" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 23:56: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, 2 May 2012 00:56:24 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPMvg-0003nu-7F; Tue, 01 May 2012 23:56:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPMvf-0006r8-VE; Wed, 02 May 2012 00:56:24 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 00:56:23 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12771: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12771 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12771/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12767 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 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops broken test-amd64-amd64-xl pass test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 01 23:57:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 May 2012 23:57:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMvk-0006vd-F5; Tue, 01 May 2012 23:56:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPMvi-0006vY-NN for xen-devel@lists.xensource.com; Tue, 01 May 2012 23:56:27 +0000 Received: from [193.109.254.147:47266] by server-6.bemta-14.messagelabs.com id 30/92-04960-92870AF4; Tue, 01 May 2012 23:56:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1335916585!7180220!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7914 invoked from network); 1 May 2012 23:56:25 -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 May 2012 23:56:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,513,1330905600"; d="scan'208";a="12233934" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 23:56: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, 2 May 2012 00:56:24 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPMvg-0003nu-7F; Tue, 01 May 2012 23:56:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPMvf-0006r8-VE; Wed, 02 May 2012 00:56:24 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 00:56:23 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12771: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12771 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12771/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12767 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 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops broken test-amd64-amd64-xl pass test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 00:53:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 00:53:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPNoZ-0007fL-5k; Wed, 02 May 2012 00:53:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPNoX-0007fG-CG for xen-devel@lists.xensource.com; Wed, 02 May 2012 00:53:05 +0000 Received: from [85.158.143.99:22290] by server-3.bemta-4.messagelabs.com id 37/CF-05853-07580AF4; Wed, 02 May 2012 00:53:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1335919982!26080313!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20748 invoked from network); 2 May 2012 00:53:03 -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; 2 May 2012 00:53:03 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q420quhb031600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 00:52:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q420qsjE009177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 00:52:55 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 q420qsRl025627; Tue, 1 May 2012 19:52:54 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 17:52:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B0B1040357; Tue, 1 May 2012 20:47:12 -0400 (EDT) Date: Tue, 1 May 2012 20:47:12 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120502004712.GA15950@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120501225456.GA13757@phenom.dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 06:54:56PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: > > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > > >On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > > >>On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > > >>>On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > > >>>>Since there have been requests about that driver to get backported into 3.2, I > > >>>>was interested to find out what or how much would be gained by that. > > >>>> > > >>>>The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > > >>>>was not very successful as the drivers bail out of the init function because the > > >>>>first call to acpi_processor_register_performance() returns -ENODEV. There is > > >>>>some frequency scaling when running without Xen, so I need to do some more > > >>>>debugging there. > > > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > > > static u32 xen_apic_read(u32 reg) > > { > > return 0; > > } > > > > This results in some data, most importantly > > boot_cpu_physical_apicid, not being set correctly and, in turn, > > causes x86_cpu_to_apicid to be broken. > > What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? > Or is this more of a stab in the dark? Ah, it is the acpi_get_cpuid that gets called by acpi_processor_add->acpi_processor_get_info. And this one: 201 #ifdef CONFIG_SMP 202 for_each_possible_cpu(i) { 203 if (cpu_physical_id(i) == apic_id) 204 return i; 205 } 206 #else where the cpu_physical_id(i) is per_cpu(x86_cpu_to_apicid, i). But it is curious that it has been working for me on AMD and Intel machines. Granted the only server boxes I've are Intel - don't have AMD server boxes at all. Stefan, can you send the full dmesg output too please? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 00:53:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 00:53:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPNoZ-0007fL-5k; Wed, 02 May 2012 00:53:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPNoX-0007fG-CG for xen-devel@lists.xensource.com; Wed, 02 May 2012 00:53:05 +0000 Received: from [85.158.143.99:22290] by server-3.bemta-4.messagelabs.com id 37/CF-05853-07580AF4; Wed, 02 May 2012 00:53:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1335919982!26080313!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNTQ5OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20748 invoked from network); 2 May 2012 00:53:03 -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; 2 May 2012 00:53:03 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q420quhb031600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 00:52:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q420qsjE009177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 00:52:55 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 q420qsRl025627; Tue, 1 May 2012 19:52:54 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 May 2012 17:52:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B0B1040357; Tue, 1 May 2012 20:47:12 -0400 (EDT) Date: Tue, 1 May 2012 20:47:12 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120502004712.GA15950@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120501225456.GA13757@phenom.dumpdata.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 01, 2012 at 06:54:56PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: > > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > > >On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > > >>On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > > >>>On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > > >>>>Since there have been requests about that driver to get backported into 3.2, I > > >>>>was interested to find out what or how much would be gained by that. > > >>>> > > >>>>The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which > > >>>>was not very successful as the drivers bail out of the init function because the > > >>>>first call to acpi_processor_register_performance() returns -ENODEV. There is > > >>>>some frequency scaling when running without Xen, so I need to do some more > > >>>>debugging there. > > > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > > > static u32 xen_apic_read(u32 reg) > > { > > return 0; > > } > > > > This results in some data, most importantly > > boot_cpu_physical_apicid, not being set correctly and, in turn, > > causes x86_cpu_to_apicid to be broken. > > What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? > Or is this more of a stab in the dark? Ah, it is the acpi_get_cpuid that gets called by acpi_processor_add->acpi_processor_get_info. And this one: 201 #ifdef CONFIG_SMP 202 for_each_possible_cpu(i) { 203 if (cpu_physical_id(i) == apic_id) 204 return i; 205 } 206 #else where the cpu_physical_id(i) is per_cpu(x86_cpu_to_apicid, i). But it is curious that it has been working for me on AMD and Intel machines. Granted the only server boxes I've are Intel - don't have AMD server boxes at all. Stefan, can you send the full dmesg output too please? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 01:12:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 01:12:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPO6m-0005MF-3X; Wed, 02 May 2012 01:11:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPO6j-0005MA-T1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 01:11:54 +0000 Received: from [85.158.138.51:37015] by server-2.bemta-3.messagelabs.com id 92/55-09269-8D980AF4; Wed, 02 May 2012 01:11:52 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1335921111!24760776!1 X-Originating-IP: [216.32.180.14] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8875 invoked from network); 2 May 2012 01:11:52 -0000 Received: from va3ehsobe004.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.14) by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 01:11:52 -0000 Received: from mail195-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 May 2012 01:11:43 +0000 Received: from mail195-va3 (localhost [127.0.0.1]) by mail195-va3-R.bigfish.com (Postfix) with ESMTP id 01A5E2404EB; Wed, 2 May 2012 01:11:43 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3 (MessageSwitch) id 133592108598449_9490; Wed, 2 May 2012 01:11:25 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.237]) by mail195-va3.bigfish.com (Postfix) with ESMTP id 0168C2206D8; Wed, 2 May 2012 01:11:25 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 01:11:23 +0000 X-WSS-ID: 0M3DFB4-01-8QO-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 2429E10280D5; Tue, 1 May 2012 20:11:28 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 1 May 2012 20:11:38 -0500 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; Tue, 1 May 2012 20:11:28 -0500 Message-ID: <4FA089C0.9050203@amd.com> Date: Tue, 1 May 2012 21:11:28 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> <20120502004712 In-Reply-To: <20120502004712.GA15950@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 08:47 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 06:54:56PM -0400, Konrad Rzeszutek Wilk wrote: >> On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: >>> On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >>>> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>>>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>>>> Since there have been requests about that driver to get backported into 3.2, I >>>>>>> was interested to find out what or how much would be gained by that. >>>>>>> >>>>>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which >>>>>>> was not very successful as the drivers bail out of the init function because the >>>>>>> first call to acpi_processor_register_performance() returns -ENODEV. There is >>>>>>> some frequency scaling when running without Xen, so I need to do some more >>>>>>> debugging there. >>> >>> I believe this is caused by the somewhat under-enlightened xen_apic_read(): >>> >>> static u32 xen_apic_read(u32 reg) >>> { >>> return 0; >>> } >>> >>> This results in some data, most importantly >>> boot_cpu_physical_apicid, not being set correctly and, in turn, >>> causes x86_cpu_to_apicid to be broken. >> >> What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? >> Or is this more of a stab in the dark? > > Ah, it is the acpi_get_cpuid that gets called by acpi_processor_add->acpi_processor_get_info. > > And this one: > 201 #ifdef CONFIG_SMP > 202 for_each_possible_cpu(i) { > 203 if (cpu_physical_id(i) == apic_id) > 204 return i; > 205 } > 206 #else > > where the cpu_physical_id(i) is per_cpu(x86_cpu_to_apicid, i). Right. This and the fact that 'if (apicid == boot_cpu_physical_apicid)' in generic_processor_info() is never true. In the end, 'processors' per-cpu variable is not initialized for cpu 0 and that's what causes acpi_processor_register_performance() to fail. > > But it is curious that it has been working for me on AMD and Intel machines. > Granted the only server boxes I've are Intel - don't have AMD server boxes at all. I am also surprised that aside from some power inefficiencies and "BIOS bug" warnings the system appeared reasonably OK. I'd think that with APIC IDs messed up it would not run. If Intel processors number cores starting with APICID=0 then you wouldn't see any issues. -boris > > Stefan, can you send the full dmesg output too please? > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 01:12:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 01:12:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPO6m-0005MF-3X; Wed, 02 May 2012 01:11:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPO6j-0005MA-T1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 01:11:54 +0000 Received: from [85.158.138.51:37015] by server-2.bemta-3.messagelabs.com id 92/55-09269-8D980AF4; Wed, 02 May 2012 01:11:52 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1335921111!24760776!1 X-Originating-IP: [216.32.180.14] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8875 invoked from network); 2 May 2012 01:11:52 -0000 Received: from va3ehsobe004.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.14) by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 01:11:52 -0000 Received: from mail195-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 May 2012 01:11:43 +0000 Received: from mail195-va3 (localhost [127.0.0.1]) by mail195-va3-R.bigfish.com (Postfix) with ESMTP id 01A5E2404EB; Wed, 2 May 2012 01:11:43 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3 (MessageSwitch) id 133592108598449_9490; Wed, 2 May 2012 01:11:25 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.237]) by mail195-va3.bigfish.com (Postfix) with ESMTP id 0168C2206D8; Wed, 2 May 2012 01:11:25 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 01:11:23 +0000 X-WSS-ID: 0M3DFB4-01-8QO-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 2429E10280D5; Tue, 1 May 2012 20:11:28 -0500 (CDT) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 1 May 2012 20:11:38 -0500 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; Tue, 1 May 2012 20:11:28 -0500 Message-ID: <4FA089C0.9050203@amd.com> Date: Tue, 1 May 2012 21:11:28 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> <20120502004712 In-Reply-To: <20120502004712.GA15950@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 08:47 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 06:54:56PM -0400, Konrad Rzeszutek Wilk wrote: >> On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote: >>> On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >>>> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>>>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>>>> Since there have been requests about that driver to get backported into 3.2, I >>>>>>> was interested to find out what or how much would be gained by that. >>>>>>> >>>>>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which >>>>>>> was not very successful as the drivers bail out of the init function because the >>>>>>> first call to acpi_processor_register_performance() returns -ENODEV. There is >>>>>>> some frequency scaling when running without Xen, so I need to do some more >>>>>>> debugging there. >>> >>> I believe this is caused by the somewhat under-enlightened xen_apic_read(): >>> >>> static u32 xen_apic_read(u32 reg) >>> { >>> return 0; >>> } >>> >>> This results in some data, most importantly >>> boot_cpu_physical_apicid, not being set correctly and, in turn, >>> causes x86_cpu_to_apicid to be broken. >> >> What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance? >> Or is this more of a stab in the dark? > > Ah, it is the acpi_get_cpuid that gets called by acpi_processor_add->acpi_processor_get_info. > > And this one: > 201 #ifdef CONFIG_SMP > 202 for_each_possible_cpu(i) { > 203 if (cpu_physical_id(i) == apic_id) > 204 return i; > 205 } > 206 #else > > where the cpu_physical_id(i) is per_cpu(x86_cpu_to_apicid, i). Right. This and the fact that 'if (apicid == boot_cpu_physical_apicid)' in generic_processor_info() is never true. In the end, 'processors' per-cpu variable is not initialized for cpu 0 and that's what causes acpi_processor_register_performance() to fail. > > But it is curious that it has been working for me on AMD and Intel machines. > Granted the only server boxes I've are Intel - don't have AMD server boxes at all. I am also surprised that aside from some power inefficiencies and "BIOS bug" warnings the system appeared reasonably OK. I'd think that with APIC IDs messed up it would not run. If Intel processors number cores starting with APICID=0 then you wouldn't see any issues. -boris > > Stefan, can you send the full dmesg output too please? > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 03:20:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 03:20:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQ6H-0006q8-35; Wed, 02 May 2012 03:19:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQ6F-0006q3-LU for xen-devel@lists.xensource.com; Wed, 02 May 2012 03:19:31 +0000 Received: from [85.158.143.35:7475] by server-2.bemta-4.messagelabs.com id 78/E3-17550-2C7A0AF4; Wed, 02 May 2012 03:19:30 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1335928766!14759689!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28839 invoked from network); 2 May 2012 03:19:27 -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; 2 May 2012 03:19:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12234490" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 03:19:24 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 04:19:24 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPQ68-00059q-5X; Wed, 02 May 2012 03:19:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPQ68-0004Wl-1e; Wed, 02 May 2012 04:19:24 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 04:19:24 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12772: regressions - trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12772 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12772/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 build-amd64-pvops 2 host-install(2) broken REGR. vs. 12707 build-amd64-oldkern 2 host-install(2) broken REGR. vs. 12707 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail in 12769 REGR. vs. 12707 test-amd64-amd64-pv 3 host-install(3) broken in 12769 REGR. vs. 12707 Tests which are failing intermittently (not blocking): test-i386-i386-xl 9 guest-start fail pass in 12769 test-amd64-i386-xl-credit2 3 host-install(3) broken in 12769 pass in 12772 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken in 12769 pass in 12772 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-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 15 guest-stop fail never pass test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 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 7 windows-install fail never pass test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail in 12769 never pass test-i386-i386-xl 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-sedf 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 12769 never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail in 12769 never pass test-amd64-amd64-win 16 leak-check/check fail in 12769 never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail in 12769 never pass test-amd64-amd64-xl-win 7 windows-install fail in 12769 never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern broken build-i386-oldkern pass build-amd64-pvops broken build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair blocked test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win blocked test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win blocked test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 03:20:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 03:20:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQ6H-0006q8-35; Wed, 02 May 2012 03:19:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQ6F-0006q3-LU for xen-devel@lists.xensource.com; Wed, 02 May 2012 03:19:31 +0000 Received: from [85.158.143.35:7475] by server-2.bemta-4.messagelabs.com id 78/E3-17550-2C7A0AF4; Wed, 02 May 2012 03:19:30 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1335928766!14759689!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28839 invoked from network); 2 May 2012 03:19:27 -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; 2 May 2012 03:19:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12234490" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 03:19:24 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 04:19:24 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPQ68-00059q-5X; Wed, 02 May 2012 03:19:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPQ68-0004Wl-1e; Wed, 02 May 2012 04:19:24 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 04:19:24 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12772: regressions - trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12772 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12772/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 build-amd64-pvops 2 host-install(2) broken REGR. vs. 12707 build-amd64-oldkern 2 host-install(2) broken REGR. vs. 12707 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail in 12769 REGR. vs. 12707 test-amd64-amd64-pv 3 host-install(3) broken in 12769 REGR. vs. 12707 Tests which are failing intermittently (not blocking): test-i386-i386-xl 9 guest-start fail pass in 12769 test-amd64-i386-xl-credit2 3 host-install(3) broken in 12769 pass in 12772 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken in 12769 pass in 12772 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-pcipt-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 15 guest-stop fail never pass test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 15 guest-stop fail never pass test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 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 7 windows-install fail never pass test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail in 12769 never pass test-i386-i386-xl 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-sedf 15 guest-stop fail in 12769 never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 12769 never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail in 12769 never pass test-amd64-amd64-win 16 leak-check/check fail in 12769 never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail in 12769 never pass test-amd64-amd64-xl-win 7 windows-install fail in 12769 never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern broken build-i386-oldkern pass build-amd64-pvops broken build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair blocked test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win blocked test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win blocked test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 04:05:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 04: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 ) id 1SPQo3-0007Bu-1t; Wed, 02 May 2012 04:04:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQo1-0007Bp-NV for xen-devel@lists.xensource.com; Wed, 02 May 2012 04:04:46 +0000 Received: from [85.158.139.83:49073] by server-10.bemta-5.messagelabs.com id 65/8C-08260-C52B0AF4; Wed, 02 May 2012 04:04:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335931484!26324518!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23953 invoked from network); 2 May 2012 04:04:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 04:04:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12234634" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 04:04: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; Wed, 2 May 2012 05:04:43 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPQnz-0005RH-BW; Wed, 02 May 2012 04:04:43 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPQnz-0002Uh-9g; Wed, 02 May 2012 05:04:43 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 05:04:43 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12774: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12774 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12774/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12746 build-i386-oldkern 2 host-install(2) broken REGR. vs. 12746 build-i386 2 host-install(2) broken REGR. vs. 12746 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-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-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-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-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 broken build-amd64-oldkern pass build-i386-oldkern broken build-amd64-pvops pass build-i386-pvops broken test-amd64-amd64-xl pass test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 04:05:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 04: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 ) id 1SPQo3-0007Bu-1t; Wed, 02 May 2012 04:04:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPQo1-0007Bp-NV for xen-devel@lists.xensource.com; Wed, 02 May 2012 04:04:46 +0000 Received: from [85.158.139.83:49073] by server-10.bemta-5.messagelabs.com id 65/8C-08260-C52B0AF4; Wed, 02 May 2012 04:04:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335931484!26324518!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23953 invoked from network); 2 May 2012 04:04:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 04:04:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12234634" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 04:04: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; Wed, 2 May 2012 05:04:43 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPQnz-0005RH-BW; Wed, 02 May 2012 04:04:43 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPQnz-0002Uh-9g; Wed, 02 May 2012 05:04:43 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 05:04:43 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12774: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12774 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12774/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12746 build-i386-oldkern 2 host-install(2) broken REGR. vs. 12746 build-i386 2 host-install(2) broken REGR. vs. 12746 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-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-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-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-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 broken build-amd64-oldkern pass build-i386-oldkern broken build-amd64-pvops pass build-i386-pvops broken test-amd64-amd64-xl pass test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 05:38:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 05: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 ) id 1SPSGT-0008Rw-BB; Wed, 02 May 2012 05:38:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPSGS-0008Rr-51 for xen-devel@lists.xensource.com; Wed, 02 May 2012 05:38:12 +0000 Received: from [85.158.143.35:14087] by server-3.bemta-4.messagelabs.com id 74/8D-05853-348C0AF4; Wed, 02 May 2012 05:38:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335937089!13810641!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10996 invoked from network); 2 May 2012 05:38:10 -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; 2 May 2012 05:38:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12235377" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 05:38: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, 2 May 2012 06:38:09 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPSGO-0006I3-S7; Wed, 02 May 2012 05:38:08 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPSGO-0007hK-RR; Wed, 02 May 2012 06:38:08 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 06:38:08 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12775: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12775 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12775/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 2 host-install(2) broken REGR. vs. 12767 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-pv 3 host-install(3) broken like 12765 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 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 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-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 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 blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv broken test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 05:38:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 05: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 ) id 1SPSGT-0008Rw-BB; Wed, 02 May 2012 05:38:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPSGS-0008Rr-51 for xen-devel@lists.xensource.com; Wed, 02 May 2012 05:38:12 +0000 Received: from [85.158.143.35:14087] by server-3.bemta-4.messagelabs.com id 74/8D-05853-348C0AF4; Wed, 02 May 2012 05:38:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335937089!13810641!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10996 invoked from network); 2 May 2012 05:38:10 -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; 2 May 2012 05:38:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="12235377" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 05:38: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, 2 May 2012 06:38:09 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPSGO-0006I3-S7; Wed, 02 May 2012 05:38:08 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPSGO-0007hK-RR; Wed, 02 May 2012 06:38:08 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 06:38:08 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12775: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12775 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12775/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 2 host-install(2) broken REGR. vs. 12767 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-pv 3 host-install(3) broken like 12765 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 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 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-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 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 blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv broken test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:19:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPUmL-0001L6-1r; Wed, 02 May 2012 08:19:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUmJ-0001L1-6e for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:19:15 +0000 Received: from [85.158.143.99:27574] by server-1.bemta-4.messagelabs.com id 23/43-20925-20EE0AF4; Wed, 02 May 2012 08:19:14 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335946727!25195340!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1329 invoked from network); 2 May 2012 08:18:48 -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; 2 May 2012 08:18:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12237947" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 08:18:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 09:18:47 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPUlr-0007np-1o; Wed, 02 May 2012 08:18:47 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPUlq-00039Y-OX; Wed, 02 May 2012 09:18:46 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 09:18:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12776: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12776 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12776/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 3 host-install(3) broken REGR. vs. 12707 build-i386 2 host-install(2) broken REGR. vs. 12707 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-xl 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-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de 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 fail test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv broken test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:19:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPUmL-0001L6-1r; Wed, 02 May 2012 08:19:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUmJ-0001L1-6e for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:19:15 +0000 Received: from [85.158.143.99:27574] by server-1.bemta-4.messagelabs.com id 23/43-20925-20EE0AF4; Wed, 02 May 2012 08:19:14 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335946727!25195340!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzIzMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1329 invoked from network); 2 May 2012 08:18:48 -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; 2 May 2012 08:18:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12237947" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 08:18:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 09:18:47 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPUlr-0007np-1o; Wed, 02 May 2012 08:18:47 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPUlq-00039Y-OX; Wed, 02 May 2012 09:18:46 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 09:18:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12776: trouble: blocked/broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12776 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12776/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 3 host-install(3) broken REGR. vs. 12707 build-i386 2 host-install(2) broken REGR. vs. 12707 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 15 guest-stop fail never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-xl 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-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 16 leak-check/check fail never pass test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de 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 fail test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv broken test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win fail test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:21:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPUo9-0001OQ-IJ; Wed, 02 May 2012 08:21:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUo7-0001OJ-Mw for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:21:07 +0000 Received: from [85.158.139.83:21200] by server-12.bemta-5.messagelabs.com id A6/46-01344-27EE0AF4; Wed, 02 May 2012 08:21:06 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-182.messagelabs.com!1335946864!19009684!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5840 invoked from network); 2 May 2012 08:21:05 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 2 May 2012 08:21:05 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPUo3-0008SK-KA for xen-devel@lists.xensource.com; Wed, 02 May 2012 01:21:03 -0700 Date: Wed, 2 May 2012 01:21:03 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1335946863612-5679908.post@n5.nabble.com> In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhou Peng wrote > > Hi Fantu, > > Thanks for your response. > > xl doesn't support qxl-related option at the moment. > I will test upstream-qemu-xen these days, and if it works well > with qxl device, I will be glad to add qxl support to xl. > Hello, any news about this? Thanks in advance -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5679908.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:21:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPUo9-0001OQ-IJ; Wed, 02 May 2012 08:21:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUo7-0001OJ-Mw for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:21:07 +0000 Received: from [85.158.139.83:21200] by server-12.bemta-5.messagelabs.com id A6/46-01344-27EE0AF4; Wed, 02 May 2012 08:21:06 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-182.messagelabs.com!1335946864!19009684!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5840 invoked from network); 2 May 2012 08:21:05 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 2 May 2012 08:21:05 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPUo3-0008SK-KA for xen-devel@lists.xensource.com; Wed, 02 May 2012 01:21:03 -0700 Date: Wed, 2 May 2012 01:21:03 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1335946863612-5679908.post@n5.nabble.com> In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhou Peng wrote > > Hi Fantu, > > Thanks for your response. > > xl doesn't support qxl-related option at the moment. > I will test upstream-qemu-xen these days, and if it works well > with qxl device, I will be glad to add qxl support to xl. > Hello, any news about this? Thanks in advance -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5679908.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:23:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUpx-0001U8-2O; Wed, 02 May 2012 08:23:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUpv-0001Tz-QQ for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:23:00 +0000 Received: from [85.158.143.35:12722] by server-2.bemta-4.messagelabs.com id EE/1F-17550-2EEE0AF4; Wed, 02 May 2012 08:22:58 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1335946977!14787921!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12004 invoked from network); 2 May 2012 08:22:57 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP; 2 May 2012 08:22:57 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPUps-0001Lm-FI; Wed, 02 May 2012 08:22:56 +0000 Message-ID: <4FA0EED5.8040009@canonical.com> Date: Wed, 02 May 2012 10:22:45 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> In-Reply-To: <20120501200207.GA15313@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6383696628749017196==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6383696628749017196== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8FC035EE44599C0D30620CF6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FC035EE44599C0D30620CF6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for not responding sooner, there was a good opportunity for a long = week end here I could not miss. Also I had been moving the power meter over to= the other machine. On 01.05.2012 22:02, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>> Since there have been requests about that driver to get backported i= nto 3.2, I >>>> was interested to find out what or how much would be gained by that.= >>>> >>>> The first system I tried was an AMD based one (8 core Opteron 6128@2= GHz). Which >>>> was not very successful as the drivers bail out of the init function= because the >>>> first call to acpi_processor_register_performance() returns -ENODEV.= There is >>>> some frequency scaling when running without Xen, so I need to do som= e more >>>> debugging there. >>> >>> Did you back-port the other components - the ones that turn off the n= ative >>> frequency scalling? >>> >>> provide disable_cpufreq() function to disable the API. >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loa= ding >>>> >> >> Yes, here is the full set for reference: >> >> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading.= >> * xen/acpi: Remove the WARN's as they just create noise. >> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >> * xen/acpi-processor: C and P-state driver that uploads said data to h= yper >> * provide disable_cpufreq() function to disable the API. >=20 > And (Linus just pulled it), you also need this one: > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT= _LEAF so that acpi-pad won't be loaded.) I suspect that one only if I would have commit 73c154c60be106b47f15d1111fc2d75cc7a436f2 xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it. and the change in the hypervisor to implement XEN_SET_PDC. >=20 >> >>>> The second system was an Intel one (4 core i7 920@2.67GHz) which was= >>>> successfully loading the driver. Via xenpm I can see the various fre= quencies and >>>> also see them being changed. However the cpuidle data out of xenpm l= ooks a bit odd: >>>> >>>> #> xenpm get-cpuidle-states 0 >>>> Max C-state: C7 >>>> >>>> cpu id : 0 >>>> total C-states : 2 >>>> idle time(ms) : 10819311 >>>> C0 : transition [00000000000000000001] >>>> residency [00000000000000005398 ms] >>>> C1 : transition [00000000000000000001] >>>> residency [00000000000010819311 ms] >>>> pc3 : [00000000000000000000 ms] >>>> pc6 : [00000000000000000000 ms] >>>> pc7 : [00000000000000000000 ms] >>>> cc3 : [00000000000000000000 ms] >>>> cc6 : [00000000000000000000 ms] >>>> >>>> Also gathering samples over 30s does look like only C0 and C1 are us= ed. This >>> >>> Yes.=20 >>>> might be because C1E support is enabled in BIOS but when looking at = the >>>> intel_idle data in sysfs when running without a hypervisor will show= C3 and C6 >>>> for the cores. That could have been just a wrong output, so I plugge= d in a power >>>> meter and compared a kernel running natively and running as dom0 (wi= th and >>>> without the acpi-processor driver). >>>> >>>> Native: 175W >>>> dom0: 183W (with only marginal difference between with or without = the >>>> processor driver) >>>> [yes, the system has a somewhat high base consumption which I attrib= ute to a >>>> ridiculously dimensioned graphics subsystem to be running a text con= sole] >>>> >>>> This I would take as C3 and C6 really not being used and the frequen= cy scaling >=20 > So the other thing I forgot to note is that C3->C6 have a detrimental > effect on some Intel boxes with Xen. We haven't figured out exactly whi= ch ones > and the bug is definitly in the hypervisor. The bug is that when the CP= U goes in > those states the NIC ends up being unresponsive. Its like the interrupt= s stopped > being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. >=20 I think I saw weird behavior not only under Xen with that. One netbook I = got has the nasty tendency to go into undetermined sleeps and you had to hit some= keys to keep it running. In that case I found out that the intel gfx card was = one which does not cause interrupts on vsync and other sources seemed not abl= e to wake up from deeper c-states when being msi. So the wonder cure there is = to force interrupts not being msi. That aside, I was also comparing power usage in idle on the AMD box. And = that shows an even bigger difference between running natively and running dom0= under the hypervisor (103W against 127W). As that is AMD there never are other c-states than c1(e) which xenpm shows as being used (got the feeling that= with AMD CPUs it is quite hard to find out the c1 residency nowadays (only int= el_idle keeps statistics). I think I got some data now but still need to parse it= (if I am not wrong one needs to use power trace now). But regardless it would hint that having the deeper c-states may not be t= he real solution. >>> >>> To go in deeper modes there is also a need to backport a Xen unstable= >>> hypercall which will allow the kernel to detect the other states besi= des >>> C0-C2. >>> >>> "XEN_SET_PDC query was implemented in c/s 23783: >>> "ACPI: add _PDC input override mechanism". >>> =20 >> >> I see. There is a kernel patch about enabling MWAIT that refers to tha= t... >=20 > Were there any special things you ran when checking the output? Just pl= ugging > and looking at the results? In the first step it only was the idle power usage. But as you say the re= al target for the patches were a better overall performance under use. So I = need to think of something to quantify the difference. >> >>> >>>> having no impact on the idle system is not that much surprising. But= if that was >>>> true it would also limit the usefulness of the turbo mode which I un= derstand >>>> would also be limited by the c-state of the other cores. >>> >>> Hm, I should double-check that - but somehow I thought that Xen indep= endetly >>> checks for TurboMode and if the P-states are in, then they are activa= ted. >=20 > I did a bit of checking around and it does seem that is the case. From = what > I have gathered the TurboMode kicks in when the CPU is C0 mode (which s= hould > be obvious), and when the other cores are in anything but C0 mode. And = sure > enough that seems to be the case. But I can't get the concrete details = whether > the "but C0 mode" means that TurboMode will work better if the C mode i= s legacy > C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out f= rom > Len Brown more details.. >>> Right, that is how I understood things, too. Depending on how many cores = are "active" (which does not really say what active means) the frequency can = go up in steps of 133Mhz (or was that 200) up to a certain upper limit. The upp= er limit depends on how many cores are active but for my CPU seems just one = more step between 2-4 cores active and 1 core active. The rest is not under OS control beside the CPU to go up in frequency nee= d to be in P0 mode. From the looks other cores can be in P0 as well and can go up= a bit as well. >> Turbo mode should be enabled. I had been only looking at a generic ove= rview >> about it on Intel site which sounded like it would make more of a dif= ference on >> how much one core could get overclocked related to how many cores are = active >> (and I translated active or not into deeper c-states or not). >> Looking at the verbose output of turbostat it seems not to make that m= uch >> difference whether 2-4 cores are running. A single core alone could ge= t one more >> increment in clock stepping. That does not immediately sound a lot. An= d of >> course how much or long the higher clock is used depends on other fact= ors as >> well and is not under OS control. >> >> In the end it is probably quite dynamic and hard to come up with hard = facts to >> prove its value. Though if I can lower the idle power usage by reachin= g a bit >> further, that would greatly help to justify the effort and potential r= isk of >> backporting... >=20 > I understand. I wish I could give you the exact percentage points by wh= ich > the power usage will drop. But I think the more substantial reason bene= fit of > these patches is performance gains. The ones that Ian Campbell ran and = were > posted on Phorenix site paint that they are beneficial. I probably should ask Ian (or check on that post) what tests he was using= to measure the difference. >=20 >> >>>> >>>> Do I misread the data I see? Or maybe its a known limitation? In cas= e it is >>>> worth doing more research I'll gladly try things and gather more dat= a. >>> >>> Just missing some patches.=20 >>> >>> Oh, and this one: >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> >>> Hmm.. I think a patch disappeared somewhere. >=20 > That was the one I referenced at the beginning of this email. >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enig8FC035EE44599C0D30620CF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoO7eAAoJEOhnXe7L7s6jZr0P/jEA3z3rnrIRzMAb9k58kV1i DiowtaYpKKNtlYG6RSVLtC5Hwcedw06C3EJmYg5jVGyJ5BlrQW4p/2fX+ozIPs8q phaqCmSMagPnIrUAauj0jGZzo16VnMnawSOrNmOIqLdVPkC5vwGIx+y+f8otGseo j2weShe2Fws6W/IrtyRdLgrAjZ4ROfTKaaHddv/H+Z4ua6t15P6VAuYd1FFRmw1G 82YmikwpaDO+W2l2Xo6eOylDrkFD1J2puKrVcx0/yon3ec6jQquWVhf+mbZi9kzx EK31sHCtCtpWnLmg2FSirkOCMeC8UxFx+Md37yw8wv0q0cCEgNpTjwvBQPAI4GeI u3P/Hi1GcfUDX8OecQwLcd3Wlsa5q0HP7ga/NfL0HAXrBEg3ilcJ+Zfi/m06cVZJ oAor+RknjZQXo+fHKMTfrnHQ0Kr7nO8Am9LzURyO0N+92rmNE62HYArQk60fQ1TR k6EZNa4UvK2MooWin6cx/BFvjA+Ahpbp0tpC07G7X/9XVKqEmlyBKl02LsZcixYz YOy19EoOdm3ewkKTVVxyd/G4RqR7oRgUBKG+3wHU6VjrA9uLr4qUMiKHZf5iLsDH zstEEcaDKLCTvPxYidCfgACmio2/5zlwPlDEiRbbXA3zGnVn/X3m0HZEXXOUkpSf wo4fA1jPQ5Ql3nAmSpYa =eQpr -----END PGP SIGNATURE----- --------------enig8FC035EE44599C0D30620CF6-- --===============6383696628749017196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6383696628749017196==-- From xen-devel-bounces@lists.xen.org Wed May 02 08:23:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUpx-0001U8-2O; Wed, 02 May 2012 08:23:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPUpv-0001Tz-QQ for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:23:00 +0000 Received: from [85.158.143.35:12722] by server-2.bemta-4.messagelabs.com id EE/1F-17550-2EEE0AF4; Wed, 02 May 2012 08:22:58 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1335946977!14787921!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12004 invoked from network); 2 May 2012 08:22:57 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP; 2 May 2012 08:22:57 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPUps-0001Lm-FI; Wed, 02 May 2012 08:22:56 +0000 Message-ID: <4FA0EED5.8040009@canonical.com> Date: Wed, 02 May 2012 10:22:45 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> In-Reply-To: <20120501200207.GA15313@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6383696628749017196==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6383696628749017196== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8FC035EE44599C0D30620CF6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FC035EE44599C0D30620CF6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for not responding sooner, there was a good opportunity for a long = week end here I could not miss. Also I had been moving the power meter over to= the other machine. On 01.05.2012 22:02, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>> Since there have been requests about that driver to get backported i= nto 3.2, I >>>> was interested to find out what or how much would be gained by that.= >>>> >>>> The first system I tried was an AMD based one (8 core Opteron 6128@2= GHz). Which >>>> was not very successful as the drivers bail out of the init function= because the >>>> first call to acpi_processor_register_performance() returns -ENODEV.= There is >>>> some frequency scaling when running without Xen, so I need to do som= e more >>>> debugging there. >>> >>> Did you back-port the other components - the ones that turn off the n= ative >>> frequency scalling? >>> >>> provide disable_cpufreq() function to disable the API. >>> xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >>> xen/cpufreq: Disable the cpu frequency scaling drivers from loa= ding >>>> >> >> Yes, here is the full set for reference: >> >> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading.= >> * xen/acpi: Remove the WARN's as they just create noise. >> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers. >> * xen/acpi-processor: C and P-state driver that uploads said data to h= yper >> * provide disable_cpufreq() function to disable the API. >=20 > And (Linus just pulled it), you also need this one: > df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWAIT= _LEAF so that acpi-pad won't be loaded.) I suspect that one only if I would have commit 73c154c60be106b47f15d1111fc2d75cc7a436f2 xen/enlighten: Expose MWAIT and MWAIT_LEAF if hypervisor OKs it. and the change in the hypervisor to implement XEN_SET_PDC. >=20 >> >>>> The second system was an Intel one (4 core i7 920@2.67GHz) which was= >>>> successfully loading the driver. Via xenpm I can see the various fre= quencies and >>>> also see them being changed. However the cpuidle data out of xenpm l= ooks a bit odd: >>>> >>>> #> xenpm get-cpuidle-states 0 >>>> Max C-state: C7 >>>> >>>> cpu id : 0 >>>> total C-states : 2 >>>> idle time(ms) : 10819311 >>>> C0 : transition [00000000000000000001] >>>> residency [00000000000000005398 ms] >>>> C1 : transition [00000000000000000001] >>>> residency [00000000000010819311 ms] >>>> pc3 : [00000000000000000000 ms] >>>> pc6 : [00000000000000000000 ms] >>>> pc7 : [00000000000000000000 ms] >>>> cc3 : [00000000000000000000 ms] >>>> cc6 : [00000000000000000000 ms] >>>> >>>> Also gathering samples over 30s does look like only C0 and C1 are us= ed. This >>> >>> Yes.=20 >>>> might be because C1E support is enabled in BIOS but when looking at = the >>>> intel_idle data in sysfs when running without a hypervisor will show= C3 and C6 >>>> for the cores. That could have been just a wrong output, so I plugge= d in a power >>>> meter and compared a kernel running natively and running as dom0 (wi= th and >>>> without the acpi-processor driver). >>>> >>>> Native: 175W >>>> dom0: 183W (with only marginal difference between with or without = the >>>> processor driver) >>>> [yes, the system has a somewhat high base consumption which I attrib= ute to a >>>> ridiculously dimensioned graphics subsystem to be running a text con= sole] >>>> >>>> This I would take as C3 and C6 really not being used and the frequen= cy scaling >=20 > So the other thing I forgot to note is that C3->C6 have a detrimental > effect on some Intel boxes with Xen. We haven't figured out exactly whi= ch ones > and the bug is definitly in the hypervisor. The bug is that when the CP= U goes in > those states the NIC ends up being unresponsive. Its like the interrupt= s stopped > being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. >=20 I think I saw weird behavior not only under Xen with that. One netbook I = got has the nasty tendency to go into undetermined sleeps and you had to hit some= keys to keep it running. In that case I found out that the intel gfx card was = one which does not cause interrupts on vsync and other sources seemed not abl= e to wake up from deeper c-states when being msi. So the wonder cure there is = to force interrupts not being msi. That aside, I was also comparing power usage in idle on the AMD box. And = that shows an even bigger difference between running natively and running dom0= under the hypervisor (103W against 127W). As that is AMD there never are other c-states than c1(e) which xenpm shows as being used (got the feeling that= with AMD CPUs it is quite hard to find out the c1 residency nowadays (only int= el_idle keeps statistics). I think I got some data now but still need to parse it= (if I am not wrong one needs to use power trace now). But regardless it would hint that having the deeper c-states may not be t= he real solution. >>> >>> To go in deeper modes there is also a need to backport a Xen unstable= >>> hypercall which will allow the kernel to detect the other states besi= des >>> C0-C2. >>> >>> "XEN_SET_PDC query was implemented in c/s 23783: >>> "ACPI: add _PDC input override mechanism". >>> =20 >> >> I see. There is a kernel patch about enabling MWAIT that refers to tha= t... >=20 > Were there any special things you ran when checking the output? Just pl= ugging > and looking at the results? In the first step it only was the idle power usage. But as you say the re= al target for the patches were a better overall performance under use. So I = need to think of something to quantify the difference. >> >>> >>>> having no impact on the idle system is not that much surprising. But= if that was >>>> true it would also limit the usefulness of the turbo mode which I un= derstand >>>> would also be limited by the c-state of the other cores. >>> >>> Hm, I should double-check that - but somehow I thought that Xen indep= endetly >>> checks for TurboMode and if the P-states are in, then they are activa= ted. >=20 > I did a bit of checking around and it does seem that is the case. From = what > I have gathered the TurboMode kicks in when the CPU is C0 mode (which s= hould > be obvious), and when the other cores are in anything but C0 mode. And = sure > enough that seems to be the case. But I can't get the concrete details = whether > the "but C0 mode" means that TurboMode will work better if the C mode i= s legacy > C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out f= rom > Len Brown more details.. >>> Right, that is how I understood things, too. Depending on how many cores = are "active" (which does not really say what active means) the frequency can = go up in steps of 133Mhz (or was that 200) up to a certain upper limit. The upp= er limit depends on how many cores are active but for my CPU seems just one = more step between 2-4 cores active and 1 core active. The rest is not under OS control beside the CPU to go up in frequency nee= d to be in P0 mode. From the looks other cores can be in P0 as well and can go up= a bit as well. >> Turbo mode should be enabled. I had been only looking at a generic ove= rview >> about it on Intel site which sounded like it would make more of a dif= ference on >> how much one core could get overclocked related to how many cores are = active >> (and I translated active or not into deeper c-states or not). >> Looking at the verbose output of turbostat it seems not to make that m= uch >> difference whether 2-4 cores are running. A single core alone could ge= t one more >> increment in clock stepping. That does not immediately sound a lot. An= d of >> course how much or long the higher clock is used depends on other fact= ors as >> well and is not under OS control. >> >> In the end it is probably quite dynamic and hard to come up with hard = facts to >> prove its value. Though if I can lower the idle power usage by reachin= g a bit >> further, that would greatly help to justify the effort and potential r= isk of >> backporting... >=20 > I understand. I wish I could give you the exact percentage points by wh= ich > the power usage will drop. But I think the more substantial reason bene= fit of > these patches is performance gains. The ones that Ian Campbell ran and = were > posted on Phorenix site paint that they are beneficial. I probably should ask Ian (or check on that post) what tests he was using= to measure the difference. >=20 >> >>>> >>>> Do I misread the data I see? Or maybe its a known limitation? In cas= e it is >>>> worth doing more research I'll gladly try things and gather more dat= a. >>> >>> Just missing some patches.=20 >>> >>> Oh, and this one: >>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> >>> Hmm.. I think a patch disappeared somewhere. >=20 > That was the one I referenced at the beginning of this email. >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enig8FC035EE44599C0D30620CF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoO7eAAoJEOhnXe7L7s6jZr0P/jEA3z3rnrIRzMAb9k58kV1i DiowtaYpKKNtlYG6RSVLtC5Hwcedw06C3EJmYg5jVGyJ5BlrQW4p/2fX+ozIPs8q phaqCmSMagPnIrUAauj0jGZzo16VnMnawSOrNmOIqLdVPkC5vwGIx+y+f8otGseo j2weShe2Fws6W/IrtyRdLgrAjZ4ROfTKaaHddv/H+Z4ua6t15P6VAuYd1FFRmw1G 82YmikwpaDO+W2l2Xo6eOylDrkFD1J2puKrVcx0/yon3ec6jQquWVhf+mbZi9kzx EK31sHCtCtpWnLmg2FSirkOCMeC8UxFx+Md37yw8wv0q0cCEgNpTjwvBQPAI4GeI u3P/Hi1GcfUDX8OecQwLcd3Wlsa5q0HP7ga/NfL0HAXrBEg3ilcJ+Zfi/m06cVZJ oAor+RknjZQXo+fHKMTfrnHQ0Kr7nO8Am9LzURyO0N+92rmNE62HYArQk60fQ1TR k6EZNa4UvK2MooWin6cx/BFvjA+Ahpbp0tpC07G7X/9XVKqEmlyBKl02LsZcixYz YOy19EoOdm3ewkKTVVxyd/G4RqR7oRgUBKG+3wHU6VjrA9uLr4qUMiKHZf5iLsDH zstEEcaDKLCTvPxYidCfgACmio2/5zlwPlDEiRbbXA3zGnVn/X3m0HZEXXOUkpSf wo4fA1jPQ5Ql3nAmSpYa =eQpr -----END PGP SIGNATURE----- --------------enig8FC035EE44599C0D30620CF6-- --===============6383696628749017196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6383696628749017196==-- From xen-devel-bounces@lists.xen.org Wed May 02 08:37:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:37:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPV3c-0001pg-NT; Wed, 02 May 2012 08:37:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPV3a-0001pb-LV for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:37:06 +0000 Received: from [193.109.254.147:13652] by server-9.bemta-14.messagelabs.com id 14/2B-05787-132F0AF4; Wed, 02 May 2012 08:37:05 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1335947822!7248237!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32127 invoked from network); 2 May 2012 08:37:02 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-8.tower-27.messagelabs.com with SMTP; 2 May 2012 08:37:02 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPV3U-0001t7-Nm; Wed, 02 May 2012 08:37:00 +0000 Message-ID: <4FA0F22B.1030505@canonical.com> Date: Wed, 02 May 2012 10:36:59 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> In-Reply-To: <4FA06541.7050607@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8138260408291714200==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8138260408291714200== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2D59051F8CC116A8C0E01A61" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D59051F8CC116A8C0E01A61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:35, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>> Since there have been requests about that driver to get backported = into 3.2, I >>>>> was interested to find out what or how much would be gained by that= =2E >>>>> >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@= 2GHz). >>>>> Which >>>>> was not very successful as the drivers bail out of the init functio= n >>>>> because the >>>>> first call to acpi_processor_register_performance() returns -ENODEV= =2E There is >>>>> some frequency scaling when running without Xen, so I need to do so= me more >>>>> debugging there. >=20 > I believe this is caused by the somewhat under-enlightened xen_apic_rea= d(): >=20 > static u32 xen_apic_read(u32 reg) > { > return 0; > } >=20 > This results in some data, most importantly boot_cpu_physical_apicid, n= ot being > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. Ah ok. I check what my box say and try the change below and gathering mor= e data as suggested in the follow-ups (including to turn on the acpi debugging a= nd debugging in the xen acpi processor driver). The latter I had done but th= at only would print "max acpi id: 16" (or so) before the failure. No wonder missi= ng the acpi debugging. >=20 > On larger AMD systems boot processor is typically APICID=3D0x20 (I don'= t have > Intel system handy to see how it looks there). >=20 > As a quick and dirty test you can try: >=20 > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long = address) > } > if (boot_cpu_physical_apicid =3D=3D -1U) { > boot_cpu_physical_apicid =3D read_apic_id(); > + boot_cpu_physical_apicid =3D 32; > apic_version[boot_cpu_physical_apicid] =3D > GET_APIC_VERSION(apic_read(APIC_LVR)); > } >=20 >=20 > (Set it to whatever APICID on core0 is, I suspect it won't be zero). >=20 > -boris >=20 >=20 >>>> >>>> Did you back-port the other components - the ones that turn off the = native >>>> frequency scalling? >>>> >>>> provide disable_cpufreq() function to disable the API. >>>> xen/acpi-processor: Do not depend on CPU frequency scaling drive= rs. >>>> xen/cpufreq: Disable the cpu frequency scaling drivers from l= oading >>>>> >>> >>> Yes, here is the full set for reference: >>> >>> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading= =2E >>> * xen/acpi: Remove the WARN's as they just create noise. >>> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers.= >>> * xen/acpi-processor: C and P-state driver that uploads said data to = hyper >>> * provide disable_cpufreq() function to disable the API. >> >> And (Linus just pulled it), you also need this one: >> df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWA= IT_LEAF >> so that acpi-pad won't be loaded.) >> >>> >>>>> The second system was an Intel one (4 core i7 920@2.67GHz) which wa= s >>>>> successfully loading the driver. Via xenpm I can see the various >>>>> frequencies and >>>>> also see them being changed. However the cpuidle data out of xenpm = looks a >>>>> bit odd: >>>>> >>>>> #> xenpm get-cpuidle-states 0 >>>>> Max C-state: C7 >>>>> >>>>> cpu id : 0 >>>>> total C-states : 2 >>>>> idle time(ms) : 10819311 >>>>> C0 : transition [00000000000000000001] >>>>> residency [00000000000000005398 ms] >>>>> C1 : transition [00000000000000000001] >>>>> residency [00000000000010819311 ms] >>>>> pc3 : [00000000000000000000 ms] >>>>> pc6 : [00000000000000000000 ms] >>>>> pc7 : [00000000000000000000 ms] >>>>> cc3 : [00000000000000000000 ms] >>>>> cc6 : [00000000000000000000 ms] >>>>> >>>>> Also gathering samples over 30s does look like only C0 and C1 are u= sed. This >>>> >>>> Yes. >>>>> might be because C1E support is enabled in BIOS but when looking at= the >>>>> intel_idle data in sysfs when running without a hypervisor will sho= w C3 and C6 >>>>> for the cores. That could have been just a wrong output, so I plugg= ed in a >>>>> power >>>>> meter and compared a kernel running natively and running as dom0 (w= ith and >>>>> without the acpi-processor driver). >>>>> >>>>> Native: 175W >>>>> dom0: 183W (with only marginal difference between with or without= the >>>>> processor driver) >>>>> [yes, the system has a somewhat high base consumption which I attri= bute to a >>>>> ridiculously dimensioned graphics subsystem to be running a text co= nsole] >>>>> >>>>> This I would take as C3 and C6 really not being used and the freque= ncy scaling >> >> So the other thing I forgot to note is that C3->C6 have a detrimental >> effect on some Intel boxes with Xen. We haven't figured out exactly wh= ich ones >> and the bug is definitly in the hypervisor. The bug is that when the C= PU goes in >> those states the NIC ends up being unresponsive. Its like the interrup= ts stopped >> being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. >> >>>> >>>> To go in deeper modes there is also a need to backport a Xen unstabl= e >>>> hypercall which will allow the kernel to detect the other states bes= ides >>>> C0-C2. >>>> >>>> "XEN_SET_PDC query was implemented in c/s 23783: >>>> "ACPI: add _PDC input override mechanism". >>>> >>> >>> I see. There is a kernel patch about enabling MWAIT that refers to th= at... >> >> Were there any special things you ran when checking the output? Just p= lugging >> and looking at the results? >>> >>>> >>>>> having no impact on the idle system is not that much surprising. Bu= t if >>>>> that was >>>>> true it would also limit the usefulness of the turbo mode which I u= nderstand >>>>> would also be limited by the c-state of the other cores. >>>> >>>> Hm, I should double-check that - but somehow I thought that Xen inde= pendetly >>>> checks for TurboMode and if the P-states are in, then they are activ= ated. >> >> I did a bit of checking around and it does seem that is the case. From= what >> I have gathered the TurboMode kicks in when the CPU is C0 mode (which = should >> be obvious), and when the other cores are in anything but C0 mode. And= sure >> enough that seems to be the case. But I can't get the concrete details= whether >> the "but C0 mode" means that TurboMode will work better if the C mode = is legacy >> C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out = from >> Len Brown more details.. >>>> >>> Turbo mode should be enabled. I had been only looking at a generic ov= erview >>> about it on Intel site which sounded like it would make more of a di= fference on >>> how much one core could get overclocked related to how many cores are= active >>> (and I translated active or not into deeper c-states or not). >>> Looking at the verbose output of turbostat it seems not to make that = much >>> difference whether 2-4 cores are running. A single core alone could g= et one more >>> increment in clock stepping. That does not immediately sound a lot. A= nd of >>> course how much or long the higher clock is used depends on other fac= tors as >>> well and is not under OS control. >>> >>> In the end it is probably quite dynamic and hard to come up with hard= facts to >>> prove its value. Though if I can lower the idle power usage by reachi= ng a bit >>> further, that would greatly help to justify the effort and potential = risk of >>> backporting... >> >> I understand. I wish I could give you the exact percentage points by w= hich >> the power usage will drop. But I think the more substantial reason ben= efit of >> these patches is performance gains. The ones that Ian Campbell ran and= were >> posted on Phorenix site paint that they are beneficial. >> >>> >>>>> >>>>> Do I misread the data I see? Or maybe its a known limitation? In ca= se it is >>>>> worth doing more research I'll gladly try things and gather more da= ta. >>>> >>>> Just missing some patches. >>>> >>>> Oh, and this one: >>>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>>> >>>> Hmm.. I think a patch disappeared somewhere. >> >> That was the one I referenced at the beginning of this email. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enig2D59051F8CC116A8C0E01A61 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoPIrAAoJEOhnXe7L7s6jTaEQAIOVbD8Jg5dFXXuVemYHgRkf +gGbuI+u0kWWaYjmAzyjhstqP1ut28ePcLU1t7VJVZjyVWLgi7IgakeHPddjIFMa UkBHueFtcdqIT5HWvXhTGKuxYkxDfsnIt6Cr1TGCqEEdtYo2W5NoqvUsw31S8yeQ z974yjim2pEkUuYQXhFi5ddmTF9JH5497gOdEw0TIOeY/AuHWPHGL5RWS7zVt6y5 mChWb2aiG3C9SLgih92fcA34iQ/Tj+F+5o82LeMG6tXOkJMNRH0NGDsw36On6m+x ouXsgkfARbMSRtB3y7xdDWJIhKOSN8yQZNWfqSNnhGqfRzTHD99NjmT233OVi832 dMSricUWEHqcrxrD9xkHn0MJZSmDRiUGygw8MktOTrxI+wIvb/GzghXyPWI+zuUV au0wFKKr/9hEz+7pSQRU1Mc9Csx3copskQmnwoJOY69LBAY9fW2zNA/SStBDnRfp 8ol3AlEkle+hu8M91SJl32TmABh5HNN+wMMGzkkPsy5z06Eac1YJ045ynhxaigR8 OBga8/0CI9LNa8fVCMKCNpqgIXImiz9BBKSdPF3MXjhq1sk4BjSj6v+KMfGV3RzQ Tdqx7Wt+fE5FomKy8UwJDXa1FW0tRmN5esbE+F6Y+YlJZxlZOm5ZDaiU/RyUB33Y vGHYvJSOmyA62lNRQXzH =7eSy -----END PGP SIGNATURE----- --------------enig2D59051F8CC116A8C0E01A61-- --===============8138260408291714200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8138260408291714200==-- From xen-devel-bounces@lists.xen.org Wed May 02 08:37:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:37:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPV3c-0001pg-NT; Wed, 02 May 2012 08:37:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPV3a-0001pb-LV for xen-devel@lists.xensource.com; Wed, 02 May 2012 08:37:06 +0000 Received: from [193.109.254.147:13652] by server-9.bemta-14.messagelabs.com id 14/2B-05787-132F0AF4; Wed, 02 May 2012 08:37:05 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1335947822!7248237!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32127 invoked from network); 2 May 2012 08:37:02 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-8.tower-27.messagelabs.com with SMTP; 2 May 2012 08:37:02 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPV3U-0001t7-Nm; Wed, 02 May 2012 08:37:00 +0000 Message-ID: <4FA0F22B.1030505@canonical.com> Date: Wed, 02 May 2012 10:36:59 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> In-Reply-To: <4FA06541.7050607@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8138260408291714200==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8138260408291714200== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2D59051F8CC116A8C0E01A61" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D59051F8CC116A8C0E01A61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:35, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>> Since there have been requests about that driver to get backported = into 3.2, I >>>>> was interested to find out what or how much would be gained by that= =2E >>>>> >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@= 2GHz). >>>>> Which >>>>> was not very successful as the drivers bail out of the init functio= n >>>>> because the >>>>> first call to acpi_processor_register_performance() returns -ENODEV= =2E There is >>>>> some frequency scaling when running without Xen, so I need to do so= me more >>>>> debugging there. >=20 > I believe this is caused by the somewhat under-enlightened xen_apic_rea= d(): >=20 > static u32 xen_apic_read(u32 reg) > { > return 0; > } >=20 > This results in some data, most importantly boot_cpu_physical_apicid, n= ot being > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. Ah ok. I check what my box say and try the change below and gathering mor= e data as suggested in the follow-ups (including to turn on the acpi debugging a= nd debugging in the xen acpi processor driver). The latter I had done but th= at only would print "max acpi id: 16" (or so) before the failure. No wonder missi= ng the acpi debugging. >=20 > On larger AMD systems boot processor is typically APICID=3D0x20 (I don'= t have > Intel system handy to see how it looks there). >=20 > As a quick and dirty test you can try: >=20 > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long = address) > } > if (boot_cpu_physical_apicid =3D=3D -1U) { > boot_cpu_physical_apicid =3D read_apic_id(); > + boot_cpu_physical_apicid =3D 32; > apic_version[boot_cpu_physical_apicid] =3D > GET_APIC_VERSION(apic_read(APIC_LVR)); > } >=20 >=20 > (Set it to whatever APICID on core0 is, I suspect it won't be zero). >=20 > -boris >=20 >=20 >>>> >>>> Did you back-port the other components - the ones that turn off the = native >>>> frequency scalling? >>>> >>>> provide disable_cpufreq() function to disable the API. >>>> xen/acpi-processor: Do not depend on CPU frequency scaling drive= rs. >>>> xen/cpufreq: Disable the cpu frequency scaling drivers from l= oading >>>>> >>> >>> Yes, here is the full set for reference: >>> >>> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading= =2E >>> * xen/acpi: Remove the WARN's as they just create noise. >>> * xen/acpi: Fix Kconfig dependency on CPU_FREQ >>> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers.= >>> * xen/acpi-processor: C and P-state driver that uploads said data to = hyper >>> * provide disable_cpufreq() function to disable the API. >> >> And (Linus just pulled it), you also need this one: >> df88b2d96e36d9a9e325bfcd12eb45671cbbc937 (xen/enlighten: Disable MWA= IT_LEAF >> so that acpi-pad won't be loaded.) >> >>> >>>>> The second system was an Intel one (4 core i7 920@2.67GHz) which wa= s >>>>> successfully loading the driver. Via xenpm I can see the various >>>>> frequencies and >>>>> also see them being changed. However the cpuidle data out of xenpm = looks a >>>>> bit odd: >>>>> >>>>> #> xenpm get-cpuidle-states 0 >>>>> Max C-state: C7 >>>>> >>>>> cpu id : 0 >>>>> total C-states : 2 >>>>> idle time(ms) : 10819311 >>>>> C0 : transition [00000000000000000001] >>>>> residency [00000000000000005398 ms] >>>>> C1 : transition [00000000000000000001] >>>>> residency [00000000000010819311 ms] >>>>> pc3 : [00000000000000000000 ms] >>>>> pc6 : [00000000000000000000 ms] >>>>> pc7 : [00000000000000000000 ms] >>>>> cc3 : [00000000000000000000 ms] >>>>> cc6 : [00000000000000000000 ms] >>>>> >>>>> Also gathering samples over 30s does look like only C0 and C1 are u= sed. This >>>> >>>> Yes. >>>>> might be because C1E support is enabled in BIOS but when looking at= the >>>>> intel_idle data in sysfs when running without a hypervisor will sho= w C3 and C6 >>>>> for the cores. That could have been just a wrong output, so I plugg= ed in a >>>>> power >>>>> meter and compared a kernel running natively and running as dom0 (w= ith and >>>>> without the acpi-processor driver). >>>>> >>>>> Native: 175W >>>>> dom0: 183W (with only marginal difference between with or without= the >>>>> processor driver) >>>>> [yes, the system has a somewhat high base consumption which I attri= bute to a >>>>> ridiculously dimensioned graphics subsystem to be running a text co= nsole] >>>>> >>>>> This I would take as C3 and C6 really not being used and the freque= ncy scaling >> >> So the other thing I forgot to note is that C3->C6 have a detrimental >> effect on some Intel boxes with Xen. We haven't figured out exactly wh= ich ones >> and the bug is definitly in the hypervisor. The bug is that when the C= PU goes in >> those states the NIC ends up being unresponsive. Its like the interrup= ts stopped >> being ACKed. If I run 'xenpm set-max-cstate 2' the issue disappears. >> >>>> >>>> To go in deeper modes there is also a need to backport a Xen unstabl= e >>>> hypercall which will allow the kernel to detect the other states bes= ides >>>> C0-C2. >>>> >>>> "XEN_SET_PDC query was implemented in c/s 23783: >>>> "ACPI: add _PDC input override mechanism". >>>> >>> >>> I see. There is a kernel patch about enabling MWAIT that refers to th= at... >> >> Were there any special things you ran when checking the output? Just p= lugging >> and looking at the results? >>> >>>> >>>>> having no impact on the idle system is not that much surprising. Bu= t if >>>>> that was >>>>> true it would also limit the usefulness of the turbo mode which I u= nderstand >>>>> would also be limited by the c-state of the other cores. >>>> >>>> Hm, I should double-check that - but somehow I thought that Xen inde= pendetly >>>> checks for TurboMode and if the P-states are in, then they are activ= ated. >> >> I did a bit of checking around and it does seem that is the case. From= what >> I have gathered the TurboMode kicks in when the CPU is C0 mode (which = should >> be obvious), and when the other cores are in anything but C0 mode. And= sure >> enough that seems to be the case. But I can't get the concrete details= whether >> the "but C0 mode" means that TurboMode will work better if the C mode = is legacy >> C1, C2, C3 or the CPU C-states (so MWAIT enabled). Trying to find out = from >> Len Brown more details.. >>>> >>> Turbo mode should be enabled. I had been only looking at a generic ov= erview >>> about it on Intel site which sounded like it would make more of a di= fference on >>> how much one core could get overclocked related to how many cores are= active >>> (and I translated active or not into deeper c-states or not). >>> Looking at the verbose output of turbostat it seems not to make that = much >>> difference whether 2-4 cores are running. A single core alone could g= et one more >>> increment in clock stepping. That does not immediately sound a lot. A= nd of >>> course how much or long the higher clock is used depends on other fac= tors as >>> well and is not under OS control. >>> >>> In the end it is probably quite dynamic and hard to come up with hard= facts to >>> prove its value. Though if I can lower the idle power usage by reachi= ng a bit >>> further, that would greatly help to justify the effort and potential = risk of >>> backporting... >> >> I understand. I wish I could give you the exact percentage points by w= hich >> the power usage will drop. But I think the more substantial reason ben= efit of >> these patches is performance gains. The ones that Ian Campbell ran and= were >> posted on Phorenix site paint that they are beneficial. >> >>> >>>>> >>>>> Do I misread the data I see? Or maybe its a known limitation? In ca= se it is >>>>> worth doing more research I'll gladly try things and gather more da= ta. >>>> >>>> Just missing some patches. >>>> >>>> Oh, and this one: >>>> xen/acpi: Fix Kconfig dependency on CPU_FREQ >>>> >>>> Hmm.. I think a patch disappeared somewhere. >> >> That was the one I referenced at the beginning of this email. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enig2D59051F8CC116A8C0E01A61 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoPIrAAoJEOhnXe7L7s6jTaEQAIOVbD8Jg5dFXXuVemYHgRkf +gGbuI+u0kWWaYjmAzyjhstqP1ut28ePcLU1t7VJVZjyVWLgi7IgakeHPddjIFMa UkBHueFtcdqIT5HWvXhTGKuxYkxDfsnIt6Cr1TGCqEEdtYo2W5NoqvUsw31S8yeQ z974yjim2pEkUuYQXhFi5ddmTF9JH5497gOdEw0TIOeY/AuHWPHGL5RWS7zVt6y5 mChWb2aiG3C9SLgih92fcA34iQ/Tj+F+5o82LeMG6tXOkJMNRH0NGDsw36On6m+x ouXsgkfARbMSRtB3y7xdDWJIhKOSN8yQZNWfqSNnhGqfRzTHD99NjmT233OVi832 dMSricUWEHqcrxrD9xkHn0MJZSmDRiUGygw8MktOTrxI+wIvb/GzghXyPWI+zuUV au0wFKKr/9hEz+7pSQRU1Mc9Csx3copskQmnwoJOY69LBAY9fW2zNA/SStBDnRfp 8ol3AlEkle+hu8M91SJl32TmABh5HNN+wMMGzkkPsy5z06Eac1YJ045ynhxaigR8 OBga8/0CI9LNa8fVCMKCNpqgIXImiz9BBKSdPF3MXjhq1sk4BjSj6v+KMfGV3RzQ Tdqx7Wt+fE5FomKy8UwJDXa1FW0tRmN5esbE+F6Y+YlJZxlZOm5ZDaiU/RyUB33Y vGHYvJSOmyA62lNRQXzH =7eSy -----END PGP SIGNATURE----- --------------enig2D59051F8CC116A8C0E01A61-- --===============8138260408291714200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8138260408291714200==-- From xen-devel-bounces@lists.xen.org Wed May 02 08:53:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPVJM-00020Q-9l; Wed, 02 May 2012 08:53:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVJL-00020L-8Q for xen-devel@lists.xen.org; Wed, 02 May 2012 08:53:23 +0000 Received: from [85.158.143.35:61654] by server-3.bemta-4.messagelabs.com id 62/C0-05853-206F0AF4; Wed, 02 May 2012 08:53:22 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1335948800!11233892!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI2NDIw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25027 invoked from network); 2 May 2012 08:53:21 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-16.tower-21.messagelabs.com with SMTP; 2 May 2012 08:53:21 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 02 May 2012 01:53:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="137850565" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 02 May 2012 01:53:19 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 01:53:19 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Wed, 2 May 2012 16:53:17 +0800 From: "Dong, Eddie" To: Jan Beulich , Aravindh Puthiyaparambil Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA Date: Wed, 2 May 2012 08:53:16 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> In-Reply-To: <4F914060020000780007EC9D@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: "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > Jun, Eddie - I further wonder why #OF is not being handled according > to the documentation here either (should also result in > X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from > TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it > should be annotated with a comment saying why fall-through is > intended here). Nor does the documentation state that TRAP_debug > should ever result in X86_EVENTTYPE_SW_EXCEPTION. Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & #BP, It seems we are slightly different here. Let me check w/ internal person. > > Finally, the whole injection logic (including the patch here) doesn't > appear to cope with INT nn being used by a guest with nn < 32, nor The original code path works for the privilege violation introduced exceptions, It seems we probbaly need a new code for INT n emulation for both interrupt & exceptions. > with any (pointless) prefixes used on INT3 or INT nn. > What specific prefix do u mean here? Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:53:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08: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 ) id 1SPVJM-00020Q-9l; Wed, 02 May 2012 08:53:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVJL-00020L-8Q for xen-devel@lists.xen.org; Wed, 02 May 2012 08:53:23 +0000 Received: from [85.158.143.35:61654] by server-3.bemta-4.messagelabs.com id 62/C0-05853-206F0AF4; Wed, 02 May 2012 08:53:22 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1335948800!11233892!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI2NDIw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25027 invoked from network); 2 May 2012 08:53:21 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-16.tower-21.messagelabs.com with SMTP; 2 May 2012 08:53:21 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 02 May 2012 01:53:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="137850565" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 02 May 2012 01:53:19 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 01:53:19 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Wed, 2 May 2012 16:53:17 +0800 From: "Dong, Eddie" To: Jan Beulich , Aravindh Puthiyaparambil Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA Date: Wed, 2 May 2012 08:53:16 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> In-Reply-To: <4F914060020000780007EC9D@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: "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > Jun, Eddie - I further wonder why #OF is not being handled according > to the documentation here either (should also result in > X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from > TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it > should be annotated with a comment saying why fall-through is > intended here). Nor does the documentation state that TRAP_debug > should ever result in X86_EVENTTYPE_SW_EXCEPTION. Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & #BP, It seems we are slightly different here. Let me check w/ internal person. > > Finally, the whole injection logic (including the patch here) doesn't > appear to cope with INT nn being used by a guest with nn < 32, nor The original code path works for the privilege violation introduced exceptions, It seems we probbaly need a new code for INT n emulation for both interrupt & exceptions. > with any (pointless) prefixes used on INT3 or INT nn. > What specific prefix do u mean here? Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:55:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:55:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVLF-00024v-Qe; Wed, 02 May 2012 08:55:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVLF-00024o-2s for xen-devel@lists.xen.org; Wed, 02 May 2012 08:55:21 +0000 Received: from [85.158.139.83:34339] by server-12.bemta-5.messagelabs.com id 0A/A8-01344-876F0AF4; Wed, 02 May 2012 08:55:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1335948919!22411814!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19924 invoked from network); 2 May 2012 08:55:19 -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; 2 May 2012 08:55:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 09:55:18 +0100 Message-Id: <4FA1129502000078000810B9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 09:55:17 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4F99617F.8000002@citrix.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.05.12 at 15:19, Keir Fraser wrote: > On 26/04/2012 15:53, "Malcolm Crossley" wrote: > >> On 12/04/12 17:30, Ian Campbell wrote: >>> The time has come for another round of stable releases. >>> >>> Please send (or resend) any outstanding backport requests for 4.0.4 and >>> 4.1.3 before Friday 20 April. >>> >>> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >>> >>> Ian. >> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be >> backported to 4.0 and 4.1? > > Done. Any plan then to tag RC1-s on both trees? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 08:55:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 08:55:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVLF-00024v-Qe; Wed, 02 May 2012 08:55:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVLF-00024o-2s for xen-devel@lists.xen.org; Wed, 02 May 2012 08:55:21 +0000 Received: from [85.158.139.83:34339] by server-12.bemta-5.messagelabs.com id 0A/A8-01344-876F0AF4; Wed, 02 May 2012 08:55:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1335948919!22411814!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19924 invoked from network); 2 May 2012 08:55:19 -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; 2 May 2012 08:55:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 09:55:18 +0100 Message-Id: <4FA1129502000078000810B9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 09:55:17 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4F99617F.8000002@citrix.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.05.12 at 15:19, Keir Fraser wrote: > On 26/04/2012 15:53, "Malcolm Crossley" wrote: > >> On 12/04/12 17:30, Ian Campbell wrote: >>> The time has come for another round of stable releases. >>> >>> Please send (or resend) any outstanding backport requests for 4.0.4 and >>> 4.1.3 before Friday 20 April. >>> >>> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >>> >>> Ian. >> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be >> backported to 4.0 and 4.1? > > Done. Any plan then to tag RC1-s on both trees? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:00:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVQ5-0002J7-JY; Wed, 02 May 2012 09:00:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVQ4-0002J2-3t for xen-devel@lists.xen.org; Wed, 02 May 2012 09:00:20 +0000 Received: from [85.158.143.35:62586] by server-3.bemta-4.messagelabs.com id 4D/AD-05853-3A7F0AF4; Wed, 02 May 2012 09:00:19 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1335949217!15643714!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19834 invoked from network); 2 May 2012 09:00:18 -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; 2 May 2012 09:00:18 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:00:16 +0100 Message-Id: <4FA113B902000078000810C3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:00:09 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <20120430193713.GA12817@phenom.dumpdata.com> In-Reply-To: <20120430193713.GA12817@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: > I somehow thought that this has been fixed but I've been > getting reports that people are running into this. "this" being what? I too thought that all xsave related issues were sorted out by now. Jan > What kind of fix do I need the in the kernel? I see this: > 255 xen_cpuid(&ax, &bx, &cx, &dx); > 256 > 257 xsave_mask = > 258 (1 << (X86_FEATURE_XSAVE % 32)) | > 259 (1 << (X86_FEATURE_OSXSAVE % 32)); > 260 > 261 /* Xen will set CR4.OSXSAVE if supported and not disabled by > force */ > 262 if ((cx & xsave_mask) != xsave_mask) > 263 cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & > OSXSAVE */ > 264 } > > But do I need some other one? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:00:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVQ5-0002J7-JY; Wed, 02 May 2012 09:00:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVQ4-0002J2-3t for xen-devel@lists.xen.org; Wed, 02 May 2012 09:00:20 +0000 Received: from [85.158.143.35:62586] by server-3.bemta-4.messagelabs.com id 4D/AD-05853-3A7F0AF4; Wed, 02 May 2012 09:00:19 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1335949217!15643714!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19834 invoked from network); 2 May 2012 09:00:18 -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; 2 May 2012 09:00:18 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:00:16 +0100 Message-Id: <4FA113B902000078000810C3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:00:09 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <20120430193713.GA12817@phenom.dumpdata.com> In-Reply-To: <20120430193713.GA12817@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: > I somehow thought that this has been fixed but I've been > getting reports that people are running into this. "this" being what? I too thought that all xsave related issues were sorted out by now. Jan > What kind of fix do I need the in the kernel? I see this: > 255 xen_cpuid(&ax, &bx, &cx, &dx); > 256 > 257 xsave_mask = > 258 (1 << (X86_FEATURE_XSAVE % 32)) | > 259 (1 << (X86_FEATURE_OSXSAVE % 32)); > 260 > 261 /* Xen will set CR4.OSXSAVE if supported and not disabled by > force */ > 262 if ((cx & xsave_mask) != xsave_mask) > 263 cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & > OSXSAVE */ > 264 } > > But do I need some other one? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:05:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:05:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVV4-0002RL-BA; Wed, 02 May 2012 09:05:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVV2-0002RG-Tr for xen-devel@lists.xen.org; Wed, 02 May 2012 09:05:29 +0000 Received: from [85.158.143.35:16366] by server-2.bemta-4.messagelabs.com id BA/08-17550-8D8F0AF4; Wed, 02 May 2012 09:05:28 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1335949526!13392119!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15874 invoked from network); 2 May 2012 09:05:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 09:05:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:05:25 +0100 Message-Id: <4FA114F402000078000810D4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:05:24 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> In-Reply-To: <20120501163707.GA8741@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, xen-devel Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.05.12 at 18:37, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >> Changelog v5 [since v4]: >> - used populate_physmap, fixed bugs. >> [v2-v4: not posted] >> - reworked the code in setup.c to work properly. >> [v1: https://lkml.org/lkml/2012/3/30/492] >> - initial patchset > > One bug I found was that with 'dom0_mem=max:1G' (with and without these > patches) I would get a bunch of > > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 > of 17) > > where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine > I ran on it. I figured it out that the difference was in the ACPI tables > that are allocated - and that those regions - even though are returned > back to the hypervisor, cannot be repopulated. I can't find the actual > exact piece of code in the hypervisor to pin-point and say "Aha". Are you sure about this? For one, given that you wrote that you saw this with as little as a single page off, I doubt there's any half way modern system where ACPI tables all fit into a single page (2 would even seem to be a theoretical minimum, as there ought to be one NVS region along with the "normal" tables). Second, the ability to repopulate shouldn't really depend on the nature of the corresponding machine pages. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:05:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:05:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVV4-0002RL-BA; Wed, 02 May 2012 09:05:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVV2-0002RG-Tr for xen-devel@lists.xen.org; Wed, 02 May 2012 09:05:29 +0000 Received: from [85.158.143.35:16366] by server-2.bemta-4.messagelabs.com id BA/08-17550-8D8F0AF4; Wed, 02 May 2012 09:05:28 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1335949526!13392119!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15874 invoked from network); 2 May 2012 09:05:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 09:05:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:05:25 +0100 Message-Id: <4FA114F402000078000810D4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:05:24 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> In-Reply-To: <20120501163707.GA8741@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: linux-kernel@vger.kernel.org, david.vrabel@citrix.com, xen-devel Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.05.12 at 18:37, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >> Changelog v5 [since v4]: >> - used populate_physmap, fixed bugs. >> [v2-v4: not posted] >> - reworked the code in setup.c to work properly. >> [v1: https://lkml.org/lkml/2012/3/30/492] >> - initial patchset > > One bug I found was that with 'dom0_mem=max:1G' (with and without these > patches) I would get a bunch of > > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 > of 17) > > where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine > I ran on it. I figured it out that the difference was in the ACPI tables > that are allocated - and that those regions - even though are returned > back to the hypervisor, cannot be repopulated. I can't find the actual > exact piece of code in the hypervisor to pin-point and say "Aha". Are you sure about this? For one, given that you wrote that you saw this with as little as a single page off, I doubt there's any half way modern system where ACPI tables all fit into a single page (2 would even seem to be a theoretical minimum, as there ought to be one NVS region along with the "normal" tables). Second, the ability to repopulate shouldn't really depend on the nature of the corresponding machine pages. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:19:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVij-00030Z-Kj; Wed, 02 May 2012 09:19:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVih-00030S-JO for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:19:35 +0000 Received: from [193.109.254.147:44800] by server-2.bemta-14.messagelabs.com id BF/36-19409-62CF0AF4; Wed, 02 May 2012 09:19:34 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1335950374!7233706!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16389 invoked from network); 2 May 2012 09:19:34 -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; 2 May 2012 09:19:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:19:33 +0100 Message-Id: <4FA1184002000078000810E3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:19:28 +0100 From: "Jan Beulich" To: "Boris Ostrovsky" , "Konrad Rzeszutek Wilk" References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> <20120502004712<20120502004712.GA15950@phenom.dumpdata.com> <4FA089C0.9050203@amd.com> In-Reply-To: <4FA089C0.9050203@amd.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 03:11, Boris Ostrovsky wrote: > On 05/01/2012 08:47 PM, Konrad Rzeszutek Wilk wrote: >> But it is curious that it has been working for me on AMD and Intel machines. >> Granted the only server boxes I've are Intel - don't have AMD server boxes at > all. > > I am also surprised that aside from some power inefficiencies and "BIOS > bug" warnings the system appeared reasonably OK. I'd think that with > APIC IDs messed up it would not run. That's not suprising at all to me, given that the entire LAPIC and interrupt management happens in Xen and not in Dom0. Hence P- and C-state management code is likely the only consumer of this (always going to be bogus under Xen) data. (In our kernels, I specifically removed all traces of these, as any use of them can only have bad effects. In pv-ops this not being an option, the only alternative appears to be to find and adjust each one individually, now and forever.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:19:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVij-00030Z-Kj; Wed, 02 May 2012 09:19:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVih-00030S-JO for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:19:35 +0000 Received: from [193.109.254.147:44800] by server-2.bemta-14.messagelabs.com id BF/36-19409-62CF0AF4; Wed, 02 May 2012 09:19:34 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1335950374!7233706!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16389 invoked from network); 2 May 2012 09:19:34 -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; 2 May 2012 09:19:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:19:33 +0100 Message-Id: <4FA1184002000078000810E3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:19:28 +0100 From: "Jan Beulich" To: "Boris Ostrovsky" , "Konrad Rzeszutek Wilk" References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> <20120502004712<20120502004712.GA15950@phenom.dumpdata.com> <4FA089C0.9050203@amd.com> In-Reply-To: <4FA089C0.9050203@amd.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 03:11, Boris Ostrovsky wrote: > On 05/01/2012 08:47 PM, Konrad Rzeszutek Wilk wrote: >> But it is curious that it has been working for me on AMD and Intel machines. >> Granted the only server boxes I've are Intel - don't have AMD server boxes at > all. > > I am also surprised that aside from some power inefficiencies and "BIOS > bug" warnings the system appeared reasonably OK. I'd think that with > APIC IDs messed up it would not run. That's not suprising at all to me, given that the entire LAPIC and interrupt management happens in Xen and not in Dom0. Hence P- and C-state management code is likely the only consumer of this (always going to be bogus under Xen) data. (In our kernels, I specifically removed all traces of these, as any use of them can only have bad effects. In pv-ops this not being an option, the only alternative appears to be to find and adjust each one individually, now and forever.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:24:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVmn-00039L-D1; Wed, 02 May 2012 09:23:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVml-000399-7p for xen-devel@lists.xen.org; Wed, 02 May 2012 09:23:47 +0000 Received: from [85.158.143.99:29108] by server-1.bemta-4.messagelabs.com id 6C/71-20925-22DF0AF4; Wed, 02 May 2012 09:23:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1335950624!25784433!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30642 invoked from network); 2 May 2012 09:23: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; 2 May 2012 09:23:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:23:43 +0100 Message-Id: <4FA1193D02000078000810EC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:23:41 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 10:53, "Dong, Eddie" wrote: >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> to the documentation here either (should also result in >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> should be annotated with a comment saying why fall-through is >> intended here). Nor does the documentation state that TRAP_debug >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. > > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & #BP, > It seems we are slightly different here. Let me check w/ internal person. Thanks. >> Finally, the whole injection logic (including the patch here) doesn't >> appear to cope with INT nn being used by a guest with nn < 32, nor > > The original code path works for the privilege violation introduced > exceptions, > It seems we probbaly need a new code for INT n emulation for both interrupt & > exceptions. Indeed. >> with any (pointless) prefixes used on INT3 or INT nn. >> > What specific prefix do u mean here? Anyone except perhaps LOCK - none of them should have any effect other than making the instruction longer. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:24:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPVmn-00039L-D1; Wed, 02 May 2012 09:23:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPVml-000399-7p for xen-devel@lists.xen.org; Wed, 02 May 2012 09:23:47 +0000 Received: from [85.158.143.99:29108] by server-1.bemta-4.messagelabs.com id 6C/71-20925-22DF0AF4; Wed, 02 May 2012 09:23:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1335950624!25784433!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30642 invoked from network); 2 May 2012 09:23: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; 2 May 2012 09:23:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 02 May 2012 10:23:43 +0100 Message-Id: <4FA1193D02000078000810EC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 02 May 2012 10:23:41 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 10:53, "Dong, Eddie" wrote: >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> to the documentation here either (should also result in >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> should be annotated with a comment saying why fall-through is >> intended here). Nor does the documentation state that TRAP_debug >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. > > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & #BP, > It seems we are slightly different here. Let me check w/ internal person. Thanks. >> Finally, the whole injection logic (including the patch here) doesn't >> appear to cope with INT nn being used by a guest with nn < 32, nor > > The original code path works for the privilege violation introduced > exceptions, > It seems we probbaly need a new code for INT n emulation for both interrupt & > exceptions. Indeed. >> with any (pointless) prefixes used on INT3 or INT nn. >> > What specific prefix do u mean here? Anyone except perhaps LOCK - none of them should have any effect other than making the instruction longer. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:45:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:45:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW75-0003Rz-GN; Wed, 02 May 2012 09:44:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW74-0003Rt-6U for xen-devel@lists.xen.org; Wed, 02 May 2012 09:44:46 +0000 Received: from [193.109.254.147:10825] by server-12.bemta-14.messagelabs.com id 9B/CE-05898-D0201AF4; Wed, 02 May 2012 09:44:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335951883!7209081!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE0NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32126 invoked from network); 2 May 2012 09:44:44 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 09:44:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330923600"; d="scan'208";a="24759726" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 05:44:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 05:44:41 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPW6z-0004lD-D0; Wed, 02 May 2012 10:44:41 +0100 Message-ID: <4FA10208.6060908@citrix.com> Date: Wed, 2 May 2012 10:44:40 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Ian Jackson References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-3-git-send-email-roger.pau@citrix.com> <20373.35017.147406.379559@mariner.uk.xensource.com> In-Reply-To: <20373.35017.147406.379559@mariner.uk.xensource.com> Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson escribi=F3: > Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_= path_cleanup"): >> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c >> index c7e057d..36d58cd 100644 >> --- a/tools/libxl/libxl_device.c >> +++ b/tools/libxl/libxl_device.c >> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpa= th, int *pdisk, >> return -1; >> } >> >> - > > Unrelated whitespace change. > >> +/* >> + * Perfrom recursive cleanup of xenstore path, from top to bottom >> + * just like xenstore-rm -t >> + */ >> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path); > > I think, following my confusion, that this needs some better > documentation comment. > >> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c >> index 3ea8d08..0b1b844 100644 >> --- a/tools/libxl/libxl_xshelp.c >> +++ b/tools/libxl/libxl_xshelp.c >> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t = domid) >> return s; >> } >> >> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path) >> +{ >> + libxl_ctx *ctx =3D libxl__gc_owner(gc); >> + unsigned int nb =3D 0; >> + char *last; >> + >> + if (!path) >> + return 0; >> + >> + xs_rm(ctx->xsh, XBT_NULL, path); >> + >> + for (last =3D strrchr(path, '/'); last !=3D NULL; last =3D strrchr(= path, '/')) { > > If the path is relative, this won't work correctly. > > Also this whole thing needs to take place in a transaction, or it is > racy. Probably a transaction supplied by the caller, in which case > you should assert it. This cannot be done inside of a transaction, because we cannot check = that the directory is empty if the remove has not actually taken place, = and checking that there are zero or one elements (the one we 'had' = removed) can lead to unexpected results, as someone might be deleting = elements on our back and we might actually delete a directory that still = has valid entries. > >> + *last =3D '\0'; >> + if (!libxl__xs_directory(gc, XBT_NULL, path,&nb)) >> + continue; > > If this fails, it should be a fatal error; we should not just blunder > on. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:45:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:45:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW75-0003Rz-GN; Wed, 02 May 2012 09:44:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW74-0003Rt-6U for xen-devel@lists.xen.org; Wed, 02 May 2012 09:44:46 +0000 Received: from [193.109.254.147:10825] by server-12.bemta-14.messagelabs.com id 9B/CE-05898-D0201AF4; Wed, 02 May 2012 09:44:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335951883!7209081!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE0NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32126 invoked from network); 2 May 2012 09:44:44 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 09:44:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330923600"; d="scan'208";a="24759726" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 05:44:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 05:44:41 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPW6z-0004lD-D0; Wed, 02 May 2012 10:44:41 +0100 Message-ID: <4FA10208.6060908@citrix.com> Date: Wed, 2 May 2012 10:44:40 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Ian Jackson References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-3-git-send-email-roger.pau@citrix.com> <20373.35017.147406.379559@mariner.uk.xensource.com> In-Reply-To: <20373.35017.147406.379559@mariner.uk.xensource.com> Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson escribi=F3: > Roger Pau Monne writes ("[Xen-devel] [PATCH v3 2/5] libxl: add libxl__xs_= path_cleanup"): >> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c >> index c7e057d..36d58cd 100644 >> --- a/tools/libxl/libxl_device.c >> +++ b/tools/libxl/libxl_device.c >> @@ -356,7 +356,6 @@ int libxl__device_disk_dev_number(const char *virtpa= th, int *pdisk, >> return -1; >> } >> >> - > > Unrelated whitespace change. > >> +/* >> + * Perfrom recursive cleanup of xenstore path, from top to bottom >> + * just like xenstore-rm -t >> + */ >> +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *path); > > I think, following my confusion, that this needs some better > documentation comment. > >> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c >> index 3ea8d08..0b1b844 100644 >> --- a/tools/libxl/libxl_xshelp.c >> +++ b/tools/libxl/libxl_xshelp.c >> @@ -135,6 +135,28 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t = domid) >> return s; >> } >> >> +int libxl__xs_path_cleanup(libxl__gc *gc, char *path) >> +{ >> + libxl_ctx *ctx =3D libxl__gc_owner(gc); >> + unsigned int nb =3D 0; >> + char *last; >> + >> + if (!path) >> + return 0; >> + >> + xs_rm(ctx->xsh, XBT_NULL, path); >> + >> + for (last =3D strrchr(path, '/'); last !=3D NULL; last =3D strrchr(= path, '/')) { > > If the path is relative, this won't work correctly. > > Also this whole thing needs to take place in a transaction, or it is > racy. Probably a transaction supplied by the caller, in which case > you should assert it. This cannot be done inside of a transaction, because we cannot check = that the directory is empty if the remove has not actually taken place, = and checking that there are zero or one elements (the one we 'had' = removed) can lead to unexpected results, as someone might be deleting = elements on our back and we might actually delete a directory that still = has valid entries. > >> + *last =3D '\0'; >> + if (!libxl__xs_directory(gc, XBT_NULL, path,&nb)) >> + continue; > > If this fails, it should be a fatal error; we should not just blunder > on. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:46:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPW84-0003Ud-Ub; Wed, 02 May 2012 09:45:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW83-0003UR-62 for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:45:47 +0000 Received: from [85.158.138.51:51799] by server-11.bemta-3.messagelabs.com id 61/04-18894-A4201AF4; Wed, 02 May 2012 09:45:46 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-10.tower-174.messagelabs.com!1335951945!20712493!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29381 invoked from network); 2 May 2012 09:45:45 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-10.tower-174.messagelabs.com with SMTP; 2 May 2012 09:45:45 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 29D77148849; Wed, 2 May 2012 09:45:44 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwYoL5UN9naB; Wed, 2 May 2012 10:45:39 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 70852131684; Wed, 2 May 2012 10:45:39 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPW7p-0006RG-Hw; Wed, 02 May 2012 10:45:39 +0100 Message-ID: <1335951927.26758.24.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Gleb Natapov Date: Wed, 02 May 2012 10:45:27 +0100 In-Reply-To: <20120501130419.GJ22191@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > a signature too 'KVMKVMKVM'. > > > > > cpu->stepping = eax & 0xf; > > > cpu->model = (eax >> 4) & 0xf; > > > cpu->family = (eax >> 8) & 0xf; > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > cpu->maxei2 = maxei; > > > + if (ecx & 0x80000000) { > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > + /* > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > + * where it really means 0x40000001. > > > > This is something where I definitely think you want to check the > > signature first. > In theory yes, but in practice what will this break? I've got no idea -- but what's the harm in checking? Ian. -- Ian Campbell Current Noise: Hypocrisy - Roswell 47 Angels we have heard on High Tell us to go out and Buy. -- Tom Lehrer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:46:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPW84-0003Ud-Ub; Wed, 02 May 2012 09:45:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPW83-0003UR-62 for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:45:47 +0000 Received: from [85.158.138.51:51799] by server-11.bemta-3.messagelabs.com id 61/04-18894-A4201AF4; Wed, 02 May 2012 09:45:46 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-10.tower-174.messagelabs.com!1335951945!20712493!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29381 invoked from network); 2 May 2012 09:45:45 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-10.tower-174.messagelabs.com with SMTP; 2 May 2012 09:45:45 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 29D77148849; Wed, 2 May 2012 09:45:44 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwYoL5UN9naB; Wed, 2 May 2012 10:45:39 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 70852131684; Wed, 2 May 2012 10:45:39 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPW7p-0006RG-Hw; Wed, 02 May 2012 10:45:39 +0100 Message-ID: <1335951927.26758.24.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Gleb Natapov Date: Wed, 02 May 2012 10:45:27 +0100 In-Reply-To: <20120501130419.GJ22191@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > a signature too 'KVMKVMKVM'. > > > > > cpu->stepping = eax & 0xf; > > > cpu->model = (eax >> 4) & 0xf; > > > cpu->family = (eax >> 8) & 0xf; > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > cpu->maxei2 = maxei; > > > + if (ecx & 0x80000000) { > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > + /* > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > + * where it really means 0x40000001. > > > > This is something where I definitely think you want to check the > > signature first. > In theory yes, but in practice what will this break? I've got no idea -- but what's the harm in checking? Ian. -- Ian Campbell Current Noise: Hypocrisy - Roswell 47 Angels we have heard on High Tell us to go out and Buy. -- Tom Lehrer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:51:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPWDD-0003kp-Q4; Wed, 02 May 2012 09:51:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWDD-0003ki-A0 for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:51:07 +0000 Received: from [85.158.138.51:38550] by server-4.bemta-3.messagelabs.com id 24/A6-15341-A8301AF4; Wed, 02 May 2012 09:51:06 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1335952264!24789145!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE1NjA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4435 invoked from network); 2 May 2012 09:51:05 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-2.tower-174.messagelabs.com with SMTP; 2 May 2012 09:51:05 -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 q429on39016216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 05:50:49 -0400 Received: from redhat.com (vpn-202-148.tlv.redhat.com [10.35.202.148]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id q429ojhl008052; Wed, 2 May 2012 05:50:46 -0400 Date: Wed, 2 May 2012 12:50:55 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120502095053.GA31543@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> <1335951927.26758.24.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335951927.26758.24.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: xen-devel@lists.xensource.com, Gleb Natapov , kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 10:45:27AM +0100, Ian Campbell wrote: > On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > > a signature too 'KVMKVMKVM'. > > > > > > > cpu->stepping = eax & 0xf; > > > > cpu->model = (eax >> 4) & 0xf; > > > > cpu->family = (eax >> 8) & 0xf; > > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > > cpu->maxei2 = maxei; > > > > + if (ecx & 0x80000000) { > > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > > + /* > > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > > + * where it really means 0x40000001. > > > > > > This is something where I definitely think you want to check the > > > signature first. > > In theory yes, but in practice what will this break? > > I've got no idea -- but what's the harm in checking? > > Ian. Users can set kvm signature to anything, if they do debugging will be a bit harder for them. > -- > Ian Campbell > Current Noise: Hypocrisy - Roswell 47 > > Angels we have heard on High > Tell us to go out and Buy. > -- Tom Lehrer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:51:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09: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 ) id 1SPWDD-0003kp-Q4; Wed, 02 May 2012 09:51:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWDD-0003ki-A0 for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:51:07 +0000 Received: from [85.158.138.51:38550] by server-4.bemta-3.messagelabs.com id 24/A6-15341-A8301AF4; Wed, 02 May 2012 09:51:06 +0000 X-Env-Sender: mst@redhat.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1335952264!24789145!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE1NjA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4435 invoked from network); 2 May 2012 09:51:05 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-2.tower-174.messagelabs.com with SMTP; 2 May 2012 09:51:05 -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 q429on39016216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 05:50:49 -0400 Received: from redhat.com (vpn-202-148.tlv.redhat.com [10.35.202.148]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP id q429ojhl008052; Wed, 2 May 2012 05:50:46 -0400 Date: Wed, 2 May 2012 12:50:55 +0300 From: "Michael S. Tsirkin" To: Ian Campbell Message-ID: <20120502095053.GA31543@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> <1335951927.26758.24.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1335951927.26758.24.camel@zakaz.uk.xensource.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: xen-devel@lists.xensource.com, Gleb Natapov , kvm@vger.kernel.org, pv-drivers@vmware.com, virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org, davej@redhat.com Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 10:45:27AM +0100, Ian Campbell wrote: > On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > > a signature too 'KVMKVMKVM'. > > > > > > > cpu->stepping = eax & 0xf; > > > > cpu->model = (eax >> 4) & 0xf; > > > > cpu->family = (eax >> 8) & 0xf; > > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > > cpu->maxei2 = maxei; > > > > + if (ecx & 0x80000000) { > > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > > + /* > > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > > + * where it really means 0x40000001. > > > > > > This is something where I definitely think you want to check the > > > signature first. > > In theory yes, but in practice what will this break? > > I've got no idea -- but what's the harm in checking? > > Ian. Users can set kvm signature to anything, if they do debugging will be a bit harder for them. > -- > Ian Campbell > Current Noise: Hypocrisy - Roswell 47 > > Angels we have heard on High > Tell us to go out and Buy. > -- Tom Lehrer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:52:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:52:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWEO-0003rE-8g; Wed, 02 May 2012 09:52:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWEM-0003r2-ML for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:52:18 +0000 Received: from [85.158.138.51:55356] by server-10.bemta-3.messagelabs.com id C9/DE-29478-1D301AF4; Wed, 02 May 2012 09:52:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1335952337!20714042!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29662 invoked from network); 2 May 2012 09:52:17 -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; 2 May 2012 09:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12240610" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 09:51: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, 2 May 2012 10:51:56 +0100 Message-ID: <1335952315.26758.30.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Wed, 2 May 2012 10:51:55 +0100 In-Reply-To: <20120501232152.GB69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> <20120501232152.GB69356@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Julian Pidancet Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 00:21 +0100, Tim Deegan wrote: > At 23:59 +0100 on 01 May (1335916778), Julian Pidancet wrote: > > >> Would we still be able to do that with the simplifications you're > > >> suggesting here ? > > > > > > Yes, you could definitely do it without all this module stuff. Passing > > > an address and length in Xenstore would work. > > > > Isn't it kind of the same thing ? I mean, the BIOS or an Option ROM to > > pre-load could be seen by hvmloader as "modules" because they would > > have to be passed by the toolstack the same way as ACPI or SMBIOS > > tables. > > Yes, it's similar. But the new module marshalling/unmarshalling code > isn't necessary for any of them. Agreed, if necessary then there should be specific fields in xc_hvm_build_args to provide these overrides. I'm not totally convinced about adding new features (specifically Option ROM deployment support) for ROMBIOS+qemu-xen-traditional. By the time this stuff hits the tree (i.e. 4.3 at this point) we should have switched to SEABIOS+qemu-xen-upstream as our default BIOS+ioemu pair. It is already the case that we have been refusing new features to qemu-xen-traditional but we haven't yet extended this to ROMBIOS (I don't think). I suppose the flip side is that the code ought to be small and relatively self contained under if(rombios) conditionals in hvmloader, so long as we make it clear in the xc interface that those ROMs only apply if you are using ROMBIOS. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:52:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:52:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWEO-0003rE-8g; Wed, 02 May 2012 09:52:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWEM-0003r2-ML for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:52:18 +0000 Received: from [85.158.138.51:55356] by server-10.bemta-3.messagelabs.com id C9/DE-29478-1D301AF4; Wed, 02 May 2012 09:52:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1335952337!20714042!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29662 invoked from network); 2 May 2012 09:52:17 -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; 2 May 2012 09:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12240610" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 09:51: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, 2 May 2012 10:51:56 +0100 Message-ID: <1335952315.26758.30.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Wed, 2 May 2012 10:51:55 +0100 In-Reply-To: <20120501232152.GB69356@ocelot.phlegethon.org> References: <831D55AF5A11D64C9B4B43F59EEBF720724FB1BAA8@FTLPMAILBOX02.citrite.net> <20120320092412.GA3544@ocelot.phlegethon.org> <20120322112612.GG37468@ocelot.phlegethon.org> <4FA03DC8.6040204@gmail.com> <20120501221756.GA69356@ocelot.phlegethon.org> <20120501232152.GB69356@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Ross Philipson , Julian Pidancet Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 00:21 +0100, Tim Deegan wrote: > At 23:59 +0100 on 01 May (1335916778), Julian Pidancet wrote: > > >> Would we still be able to do that with the simplifications you're > > >> suggesting here ? > > > > > > Yes, you could definitely do it without all this module stuff. Passing > > > an address and length in Xenstore would work. > > > > Isn't it kind of the same thing ? I mean, the BIOS or an Option ROM to > > pre-load could be seen by hvmloader as "modules" because they would > > have to be passed by the toolstack the same way as ACPI or SMBIOS > > tables. > > Yes, it's similar. But the new module marshalling/unmarshalling code > isn't necessary for any of them. Agreed, if necessary then there should be specific fields in xc_hvm_build_args to provide these overrides. I'm not totally convinced about adding new features (specifically Option ROM deployment support) for ROMBIOS+qemu-xen-traditional. By the time this stuff hits the tree (i.e. 4.3 at this point) we should have switched to SEABIOS+qemu-xen-upstream as our default BIOS+ioemu pair. It is already the case that we have been refusing new features to qemu-xen-traditional but we haven't yet extended this to ROMBIOS (I don't think). I suppose the flip side is that the code ought to be small and relatively self contained under if(rombios) conditionals in hvmloader, so long as we make it clear in the xc interface that those ROMs only apply if you are using ROMBIOS. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:59:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:59:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWKx-00046V-4l; Wed, 02 May 2012 09:59:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWKv-00046Q-9I for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:59:05 +0000 Received: from [85.158.143.99:14370] by server-2.bemta-4.messagelabs.com id C0/11-17550-86501AF4; Wed, 02 May 2012 09:59:04 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-11.tower-216.messagelabs.com!1335952742!18592971!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27197 invoked from network); 2 May 2012 09:59:02 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-11.tower-216.messagelabs.com with SMTP; 2 May 2012 09:59:02 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 2645E148849; Wed, 2 May 2012 09:59:00 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFSRfM+jwsfi; Wed, 2 May 2012 10:58:55 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 884BD13FE39; Wed, 2 May 2012 10:58:55 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPWKi-0006UQ-Ms; Wed, 02 May 2012 10:58:54 +0100 Message-ID: <1335952726.26758.34.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Wed, 02 May 2012 10:58:46 +0100 In-Reply-To: <20120502095053.GA31543@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> <1335951927.26758.24.camel@zakaz.uk.xensource.com> <20120502095053.GA31543@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 10:50 +0100, Michael S. Tsirkin wrote: > On Wed, May 02, 2012 at 10:45:27AM +0100, Ian Campbell wrote: > > On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > > > a signature too 'KVMKVMKVM'. > > > > > > > > > cpu->stepping = eax & 0xf; > > > > > cpu->model = (eax >> 4) & 0xf; > > > > > cpu->family = (eax >> 8) & 0xf; > > > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > > > cpu->maxei2 = maxei; > > > > > + if (ecx & 0x80000000) { > > > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > > > + /* > > > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > > > + * where it really means 0x40000001. > > > > > > > > This is something where I definitely think you want to check the > > > > signature first. > > > In theory yes, but in practice what will this break? > > > > I've got no idea -- but what's the harm in checking? > > > > Ian. > > Users can set kvm signature to anything, if they do > debugging will be a bit harder for them. Ah, right, someone already mentioned that and I forgot, sorry. And, just to complete my train of thought, cpuid just returns reserved values for requests for non-existent leaves (rather than #GP for example) so it's safe enough even if you do end up trying to read an eax=0x40000001 when it doesn't exist. Seems fine to me then. Ian. -- Ian Campbell Current Noise: Hypocrisy - Buried He's like a function -- he returns a value, in the form of his opinion. It's up to you to cast it into a void or not. -- Phil Lapsley _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 09:59:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 09:59:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWKx-00046V-4l; Wed, 02 May 2012 09:59:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWKv-00046Q-9I for xen-devel@lists.xensource.com; Wed, 02 May 2012 09:59:05 +0000 Received: from [85.158.143.99:14370] by server-2.bemta-4.messagelabs.com id C0/11-17550-86501AF4; Wed, 02 May 2012 09:59:04 +0000 X-Env-Sender: ijc@hellion.org.uk X-Msg-Ref: server-11.tower-216.messagelabs.com!1335952742!18592971!1 X-Originating-IP: [80.68.92.230] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27197 invoked from network); 2 May 2012 09:59:02 -0000 Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk) (80.68.92.230) by server-11.tower-216.messagelabs.com with SMTP; 2 May 2012 09:59:02 -0000 Received: from localhost (unknown [127.0.0.1]) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 2645E148849; Wed, 2 May 2012 09:59:00 +0000 (UTC) Received: from aaar.vm.bytemark.co.uk ([127.0.0.1]) by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFSRfM+jwsfi; Wed, 2 May 2012 10:58:55 +0100 (BST) Received: from hopkins.hellion.org.uk (cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 884BD13FE39; Wed, 2 May 2012 10:58:55 +0100 (BST) Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42]) by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SPWKi-0006UQ-Ms; Wed, 02 May 2012 10:58:54 +0100 Message-ID: <1335952726.26758.34.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "Michael S. Tsirkin" Date: Wed, 02 May 2012 10:58:46 +0100 In-Reply-To: <20120502095053.GA31543@redhat.com> References: <20120430143835.GA10190@redhat.com> <1335875225.6038.98.camel@zakaz.uk.xensource.com> <20120501130419.GJ22191@redhat.com> <1335951927.26758.24.camel@zakaz.uk.xensource.com> <20120502095053.GA31543@redhat.com> X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 62.200.22.2 X-SA-Exim-Mail-From: ijc@hellion.org.uk X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk) Cc: "xen-devel@lists.xensource.com" , Gleb Natapov , "kvm@vger.kernel.org" , "pv-drivers@vmware.com" , "virtualization@lists.linux-foundation.org" , "davej@redhat.com" , "devel@linuxdriverproject.org" Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 10:50 +0100, Michael S. Tsirkin wrote: > On Wed, May 02, 2012 at 10:45:27AM +0100, Ian Campbell wrote: > > On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote: > > > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has > > > > a signature too 'KVMKVMKVM'. > > > > > > > > > cpu->stepping = eax & 0xf; > > > > > cpu->model = (eax >> 4) & 0xf; > > > > > cpu->family = (eax >> 8) & 0xf; > > > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu) > > > > > > > > > > cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL); > > > > > cpu->maxei2 = maxei; > > > > > + if (ecx & 0x80000000) { > > > > > + cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL); > > > > > + /* > > > > > + * KVM up to linux 3.4 reports 0 as the max hypervisor leaf, > > > > > + * where it really means 0x40000001. > > > > > > > > This is something where I definitely think you want to check the > > > > signature first. > > > In theory yes, but in practice what will this break? > > > > I've got no idea -- but what's the harm in checking? > > > > Ian. > > Users can set kvm signature to anything, if they do > debugging will be a bit harder for them. Ah, right, someone already mentioned that and I forgot, sorry. And, just to complete my train of thought, cpuid just returns reserved values for requests for non-existent leaves (rather than #GP for example) so it's safe enough even if you do end up trying to read an eax=0x40000001 when it doesn't exist. Seems fine to me then. Ian. -- Ian Campbell Current Noise: Hypocrisy - Buried He's like a function -- he returns a value, in the form of his opinion. It's up to you to cast it into a void or not. -- Phil Lapsley _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 10:03:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 10: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 ) id 1SPWPI-0004I6-RM; Wed, 02 May 2012 10:03:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWPH-0004Hy-43 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:03:35 +0000 Received: from [85.158.143.99:49071] by server-3.bemta-4.messagelabs.com id F5/AE-05853-67601AF4; Wed, 02 May 2012 10:03:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335953013!22753142!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2911 invoked from network); 2 May 2012 10:03:33 -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; 2 May 2012 10:03:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12241278" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 10:03: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; Wed, 2 May 2012 11:03:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPWPE-000080-Fe; Wed, 02 May 2012 10:03:32 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPWPE-0002Yo-Aw; Wed, 02 May 2012 11:03:32 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 11:03:32 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12777: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12777 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12777/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Tests which are failing intermittently (not blocking): test-i386-i386-xl 3 host-install(3) broken pass in 12770 test-amd64-i386-xl 9 guest-start fail in 12770 pass in 12777 test-amd64-i386-xl-credit2 3 host-install(3) broken in 12770 pass in 12777 test-amd64-i386-pv 3 host-install(3) broken in 12770 pass in 12777 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-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 version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl broken test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 10:03:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 10: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 ) id 1SPWPI-0004I6-RM; Wed, 02 May 2012 10:03:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWPH-0004Hy-43 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:03:35 +0000 Received: from [85.158.143.99:49071] by server-3.bemta-4.messagelabs.com id F5/AE-05853-67601AF4; Wed, 02 May 2012 10:03:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1335953013!22753142!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2911 invoked from network); 2 May 2012 10:03:33 -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; 2 May 2012 10:03:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208";a="12241278" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 10:03: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; Wed, 2 May 2012 11:03:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPWPE-000080-Fe; Wed, 02 May 2012 10:03:32 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPWPE-0002Yo-Aw; Wed, 02 May 2012 11:03:32 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 11:03:32 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12777: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12777 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12777/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Tests which are failing intermittently (not blocking): test-i386-i386-xl 3 host-install(3) broken pass in 12770 test-amd64-i386-xl 9 guest-start fail in 12770 pass in 12777 test-amd64-i386-xl-credit2 3 host-install(3) broken in 12770 pass in 12777 test-amd64-i386-pv 3 host-install(3) broken in 12770 pass in 12777 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-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 version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl broken test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 10:59:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 10: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 ) id 1SPXGi-0004uP-Ff; Wed, 02 May 2012 10:58:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPXGg-0004uJ-Vj for xen-devel@lists.xen.org; Wed, 02 May 2012 10:58:47 +0000 Received: from [193.109.254.147:14072] by server-9.bemta-14.messagelabs.com id 0D/BA-05787-66311AF4; Wed, 02 May 2012 10:58:46 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335956325!424171!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32260 invoked from network); 2 May 2012 10:58:45 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 10:58:45 -0000 Received: by eaaf11 with SMTP id f11so136143eaa.32 for ; Wed, 02 May 2012 03:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=iEM2Sghzvtarvt6+mj6ET22m+w6lrLvQQn4wuFMnFuE=; b=efFBPHzU+jBIJm8EpDR0BOvJVVA/oC51ovbSkvkB+5KVBI5k1GI1tQbG+RY5zNi+r6 709TDnUmPrn/fiFA/M1gn/SwL7XLQnJ6DzEJX1o6MBltZkn0cYR7f2OAkjMJHUkVOMzI VjtEmW7bmsLb99YPumxZXHVOY+E5CcbWm/u/5hywhXgYn9Mq28lhC4Wu7gzPT7m4HSmm mCbndWdsNbjEy17k2PEEiAYSUnVjaXUhTsTp0KxUH+XXLtvOeoaBkNzZLwfclzdeTZhP 2fCwIq0qz0jwq+Zm7yBwokoMthL54G71Hj5gqS/NfSGwBEQo19rt0fOah4lVNIH0RSBS b7yA== Received: by 10.14.28.65 with SMTP id f41mr5382363eea.23.1335956324901; Wed, 02 May 2012 03:58:44 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id z47sm7346332een.5.2012.05.02.03.58.43 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 03:58:44 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 02 May 2012 11:58:35 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases Thread-Index: Ac0oUoUnHQPh90UXlkyKt5XxPiX+Fg== In-Reply-To: <4FA1129502000078000810B9@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/2012 09:55, "Jan Beulich" wrote: >>>> On 01.05.12 at 15:19, Keir Fraser wrote: >> On 26/04/2012 15:53, "Malcolm Crossley" wrote: >> >>> On 12/04/12 17:30, Ian Campbell wrote: >>>> The time has come for another round of stable releases. >>>> >>>> Please send (or resend) any outstanding backport requests for 4.0.4 and >>>> 4.1.3 before Friday 20 April. >>>> >>>> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >>>> >>>> Ian. >>> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be >>> backported to 4.0 and 4.1? >> >> Done. > > Any plan then to tag RC1-s on both trees? Yes, we could do that this week I think. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 10:59:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 10: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 ) id 1SPXGi-0004uP-Ff; Wed, 02 May 2012 10:58:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPXGg-0004uJ-Vj for xen-devel@lists.xen.org; Wed, 02 May 2012 10:58:47 +0000 Received: from [193.109.254.147:14072] by server-9.bemta-14.messagelabs.com id 0D/BA-05787-66311AF4; Wed, 02 May 2012 10:58:46 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335956325!424171!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32260 invoked from network); 2 May 2012 10:58:45 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 10:58:45 -0000 Received: by eaaf11 with SMTP id f11so136143eaa.32 for ; Wed, 02 May 2012 03:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=iEM2Sghzvtarvt6+mj6ET22m+w6lrLvQQn4wuFMnFuE=; b=efFBPHzU+jBIJm8EpDR0BOvJVVA/oC51ovbSkvkB+5KVBI5k1GI1tQbG+RY5zNi+r6 709TDnUmPrn/fiFA/M1gn/SwL7XLQnJ6DzEJX1o6MBltZkn0cYR7f2OAkjMJHUkVOMzI VjtEmW7bmsLb99YPumxZXHVOY+E5CcbWm/u/5hywhXgYn9Mq28lhC4Wu7gzPT7m4HSmm mCbndWdsNbjEy17k2PEEiAYSUnVjaXUhTsTp0KxUH+XXLtvOeoaBkNzZLwfclzdeTZhP 2fCwIq0qz0jwq+Zm7yBwokoMthL54G71Hj5gqS/NfSGwBEQo19rt0fOah4lVNIH0RSBS b7yA== Received: by 10.14.28.65 with SMTP id f41mr5382363eea.23.1335956324901; Wed, 02 May 2012 03:58:44 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id z47sm7346332een.5.2012.05.02.03.58.43 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 03:58:44 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 02 May 2012 11:58:35 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases Thread-Index: Ac0oUoUnHQPh90UXlkyKt5XxPiX+Fg== In-Reply-To: <4FA1129502000078000810B9@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/2012 09:55, "Jan Beulich" wrote: >>>> On 01.05.12 at 15:19, Keir Fraser wrote: >> On 26/04/2012 15:53, "Malcolm Crossley" wrote: >> >>> On 12/04/12 17:30, Ian Campbell wrote: >>>> The time has come for another round of stable releases. >>>> >>>> Please send (or resend) any outstanding backport requests for 4.0.4 and >>>> 4.1.3 before Friday 20 April. >>>> >>>> Note that 4.0.4 will likely be the last release in the 4.0.x branch. >>>> >>>> Ian. >>> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be >>> backported to 4.0 and 4.1? >> >> Done. > > Any plan then to tag RC1-s on both trees? Yes, we could do that this week I think. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 12:40:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 12: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 ) id 1SPYqm-0005fQ-2z; Wed, 02 May 2012 12:40:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPYqk-0005fL-9h for xen-devel@lists.xensource.com; Wed, 02 May 2012 12:40:06 +0000 Received: from [85.158.143.35:30606] by server-2.bemta-4.messagelabs.com id E6/76-17550-52B21AF4; Wed, 02 May 2012 12:40:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1335962404!15307913!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3923 invoked from network); 2 May 2012 12:40:04 -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; 2 May 2012 12:40:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12245724" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 12:40:03 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 13:40:03 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPYqg-0001Y1-Tr; Wed, 02 May 2012 12:40:02 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPYqg-0003OA-Oc; Wed, 02 May 2012 13:40:02 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 13:40:02 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12781: trouble: blocked/broken/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12781 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12781/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12694 build-amd64-pvops 2 host-install(2) broken REGR. vs. 12694 build-i386 2 host-install(2) broken REGR. vs. 12694 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-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-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-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-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-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 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-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-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-win 1 xen-build-check(1) blocked n/a version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 jobs: build-amd64 pass build-i386 broken build-amd64-pvops broken build-i386-pvops broken test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 12:40:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 12: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 ) id 1SPYqm-0005fQ-2z; Wed, 02 May 2012 12:40:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPYqk-0005fL-9h for xen-devel@lists.xensource.com; Wed, 02 May 2012 12:40:06 +0000 Received: from [85.158.143.35:30606] by server-2.bemta-4.messagelabs.com id E6/76-17550-52B21AF4; Wed, 02 May 2012 12:40:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1335962404!15307913!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3923 invoked from network); 2 May 2012 12:40:04 -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; 2 May 2012 12:40:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12245724" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 12:40:03 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 13:40:03 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPYqg-0001Y1-Tr; Wed, 02 May 2012 12:40:02 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPYqg-0003OA-Oc; Wed, 02 May 2012 13:40:02 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 13:40:02 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12781: trouble: blocked/broken/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12781 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12781/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 2 host-install(2) broken REGR. vs. 12694 build-amd64-pvops 2 host-install(2) broken REGR. vs. 12694 build-i386 2 host-install(2) broken REGR. vs. 12694 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-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-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-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-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-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 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-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-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-win 1 xen-build-check(1) blocked n/a version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 jobs: build-amd64 pass build-i386 broken build-amd64-pvops broken build-i386-pvops broken test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:12:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:12:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZLJ-00068j-GN; Wed, 02 May 2012 13:11:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZLI-00068Y-DG for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:11:40 +0000 Received: from [85.158.138.51:45830] by server-3.bemta-3.messagelabs.com id C1/95-04048-B8231AF4; Wed, 02 May 2012 13:11:39 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-8.tower-174.messagelabs.com!1335964298!24751403!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12984 invoked from network); 2 May 2012 13:11:39 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-8.tower-174.messagelabs.com with SMTP; 2 May 2012 13:11:39 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id D7CB91AC1DB; Wed, 2 May 2012 15:11:37 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id er5bIiq7sDsN; Wed, 2 May 2012 15:11:37 +0200 (CEST) Received: from [10.0.0.1] (p5794633D.dip.t-dialin.net [87.148.99.61]) by rootsrv.hfp.de (Postfix) with ESMTPA; Wed, 2 May 2012 15:11:37 +0200 (CEST) Message-ID: <4FA1328B.6070602@hfp.de> Date: Wed, 02 May 2012 15:11:39 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: xen-devel@lists.xensource.com, Jeremy Fitzhardinge , Konrad Rzeszutek Wilk Subject: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Jeremy + Konrad + all kernel devs, while it is great to see that vanilla dom0 seems to work, the performance breakdown compared to xenified 2.6.34 (from opensuse) is huge. Here are my benchmarks: Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs time emerge apache: 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 real 1m0.560s 0m59.971s 0m47.689s user 0m40.939s 0m40.619s 0m41.355s sys 0m18.865s 0m18.305s 0m11.441s time make -j4 (3.2.12 linux compile): 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 real 5m8.793s 5m4.888s 4m20.576s user 8m1.746s 7m59.726s 7m10.375s sys 1m39.010s 1m32.994s 0m56.304s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:12:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:12:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZLJ-00068j-GN; Wed, 02 May 2012 13:11:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZLI-00068Y-DG for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:11:40 +0000 Received: from [85.158.138.51:45830] by server-3.bemta-3.messagelabs.com id C1/95-04048-B8231AF4; Wed, 02 May 2012 13:11:39 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-8.tower-174.messagelabs.com!1335964298!24751403!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12984 invoked from network); 2 May 2012 13:11:39 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-8.tower-174.messagelabs.com with SMTP; 2 May 2012 13:11:39 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id D7CB91AC1DB; Wed, 2 May 2012 15:11:37 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id er5bIiq7sDsN; Wed, 2 May 2012 15:11:37 +0200 (CEST) Received: from [10.0.0.1] (p5794633D.dip.t-dialin.net [87.148.99.61]) by rootsrv.hfp.de (Postfix) with ESMTPA; Wed, 2 May 2012 15:11:37 +0200 (CEST) Message-ID: <4FA1328B.6070602@hfp.de> Date: Wed, 02 May 2012 15:11:39 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: xen-devel@lists.xensource.com, Jeremy Fitzhardinge , Konrad Rzeszutek Wilk Subject: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Jeremy + Konrad + all kernel devs, while it is great to see that vanilla dom0 seems to work, the performance breakdown compared to xenified 2.6.34 (from opensuse) is huge. Here are my benchmarks: Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs time emerge apache: 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 real 1m0.560s 0m59.971s 0m47.689s user 0m40.939s 0m40.619s 0m41.355s sys 0m18.865s 0m18.305s 0m11.441s time make -j4 (3.2.12 linux compile): 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 real 5m8.793s 5m4.888s 4m20.576s user 8m1.746s 7m59.726s 7m10.375s sys 1m39.010s 1m32.994s 0m56.304s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:26:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13: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 ) id 1SPZYn-0006RP-Ta; Wed, 02 May 2012 13:25:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZYl-0006RK-SZ for xen-devel@lists.xen.org; Wed, 02 May 2012 13:25:36 +0000 Received: from [85.158.143.35:19967] by server-2.bemta-4.messagelabs.com id 9F/D2-17550-FC531AF4; Wed, 02 May 2012 13:25:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1335965133!7276025!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12730 invoked from network); 2 May 2012 13:25:34 -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; 2 May 2012 13:25:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247262" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:25: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; Wed, 2 May 2012 14:25:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPZYj-0001t6-3Y; Wed, 02 May 2012 13:25:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SPZYi-0007hL-Ur; Wed, 02 May 2012 14:25:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20385.13772.941848.617576@mariner.uk.xensource.com> Date: Wed, 2 May 2012 14:25:32 +0100 To: Ian Campbell In-Reply-To: <1335550569.4881.74.camel@dagon.hellion.org.uk> References: <1335529430.28015.194.camel@zakaz.uk.xensource.com> <1335543062.28015.234.camel@zakaz.uk.xensource.com> <1335550569.4881.74.camel@dagon.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: misiu godfrey , xen-devel Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Xen-4.1-testing fails to "make tools""): > I've just thought to actually check the staging vs. regular trees: > http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary > http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary > and it turns out that the regular tree is lagging behind the staging > one, including the very commits in question, sorry for not looking at > this sooner. This is a snafu of some kind on my part. The qemu-xen-* trees aren't supposed to have separate push gates and the staging trees for them are a leftover wart. However I seem to have accidentally pushed some changesets to staging instead of main. I have now fixed this by pushing the missing changesets. In the future I think I will try to retire the staging trees entirely. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:26:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13: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 ) id 1SPZYn-0006RP-Ta; Wed, 02 May 2012 13:25:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZYl-0006RK-SZ for xen-devel@lists.xen.org; Wed, 02 May 2012 13:25:36 +0000 Received: from [85.158.143.35:19967] by server-2.bemta-4.messagelabs.com id 9F/D2-17550-FC531AF4; Wed, 02 May 2012 13:25:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1335965133!7276025!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12730 invoked from network); 2 May 2012 13:25:34 -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; 2 May 2012 13:25:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247262" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:25: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; Wed, 2 May 2012 14:25:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPZYj-0001t6-3Y; Wed, 02 May 2012 13:25:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SPZYi-0007hL-Ur; Wed, 02 May 2012 14:25:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20385.13772.941848.617576@mariner.uk.xensource.com> Date: Wed, 2 May 2012 14:25:32 +0100 To: Ian Campbell In-Reply-To: <1335550569.4881.74.camel@dagon.hellion.org.uk> References: <1335529430.28015.194.camel@zakaz.uk.xensource.com> <1335543062.28015.234.camel@zakaz.uk.xensource.com> <1335550569.4881.74.camel@dagon.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: misiu godfrey , xen-devel Subject: Re: [Xen-devel] Xen-4.1-testing fails to "make tools" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Xen-4.1-testing fails to "make tools""): > I've just thought to actually check the staging vs. regular trees: > http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git;a=summary > http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git;a=summary > and it turns out that the regular tree is lagging behind the staging > one, including the very commits in question, sorry for not looking at > this sooner. This is a snafu of some kind on my part. The qemu-xen-* trees aren't supposed to have separate push gates and the staging trees for them are a leftover wart. However I seem to have accidentally pushed some changesets to staging instead of main. I have now fixed this by pushing the missing changesets. In the future I think I will try to retire the staging trees entirely. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:31:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13: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 ) id 1SPZdx-0006ZB-LZ; Wed, 02 May 2012 13:30:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZdw-0006Z5-M0 for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:30:56 +0000 Received: from [85.158.138.51:35661] by server-10.bemta-3.messagelabs.com id FE/69-29478-F0731AF4; Wed, 02 May 2012 13:30:55 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335965453!24810724!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7408 invoked from network); 2 May 2012 13:30:55 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 13:30:55 -0000 Received: by yenl11 with SMTP id l11so900287yen.30 for ; Wed, 02 May 2012 06:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4kvOTNT3ZVTTDmqZexiGXD8VyBwaafldufNy2PtLA88=; b=NNhonxDAMsNblvxn72b1Pj9V/K/mGZQzAtWfqweUma6dG0dfGybabaUT1U6i6ZU7TB 4G+kkQ5/rwjrd0DHOEU7QRP2tOs5Nyj3WCsu0vcnj5oiIm4A+wi+yedNOSejGFwrraR5 iKl63dO+/C9jqp+aVL0iRHdGhl0rNnKyWw/C+5TIimBLXKL5xOehzpKZXPzLwcsXjGWH ITstrCzlZksZLnLVv5vi+bjhRO9sQv3JQkrKgSqRqNZ791ef7lzk5qs+p79SLG38wBT2 i4i7g58UqySQ2rtP1vqiaBr7pfDxmVR3mtZ50PptXNyAoJok2zh7fJQJnmoZyKGt+xnm uWTA== Received: by 10.236.79.195 with SMTP id i43mr31067264yhe.53.1335965453601; Wed, 02 May 2012 06:30:53 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id p3sm2679135and.4.2012.05.02.06.30.49 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 06:30:51 -0700 (PDT) Message-ID: <4FA13708.4050202@cantab.net> Date: Wed, 02 May 2012 14:30:48 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Andreas Kinzler References: <4FA1328B.6070602@hfp.de> In-Reply-To: <4FA1328B.6070602@hfp.de> Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/12 14:11, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: > > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly check for pending events when restoring irq flags"[1] and see how much it helps? This patch is in 3.4-rc5 and is queued for 3.3.5. David [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7eb7ce4d2e8991aff4ecb71a81949a907ca755ac _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:31:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13: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 ) id 1SPZdx-0006ZB-LZ; Wed, 02 May 2012 13:30:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZdw-0006Z5-M0 for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:30:56 +0000 Received: from [85.158.138.51:35661] by server-10.bemta-3.messagelabs.com id FE/69-29478-F0731AF4; Wed, 02 May 2012 13:30:55 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335965453!24810724!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7408 invoked from network); 2 May 2012 13:30:55 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 13:30:55 -0000 Received: by yenl11 with SMTP id l11so900287yen.30 for ; Wed, 02 May 2012 06:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4kvOTNT3ZVTTDmqZexiGXD8VyBwaafldufNy2PtLA88=; b=NNhonxDAMsNblvxn72b1Pj9V/K/mGZQzAtWfqweUma6dG0dfGybabaUT1U6i6ZU7TB 4G+kkQ5/rwjrd0DHOEU7QRP2tOs5Nyj3WCsu0vcnj5oiIm4A+wi+yedNOSejGFwrraR5 iKl63dO+/C9jqp+aVL0iRHdGhl0rNnKyWw/C+5TIimBLXKL5xOehzpKZXPzLwcsXjGWH ITstrCzlZksZLnLVv5vi+bjhRO9sQv3JQkrKgSqRqNZ791ef7lzk5qs+p79SLG38wBT2 i4i7g58UqySQ2rtP1vqiaBr7pfDxmVR3mtZ50PptXNyAoJok2zh7fJQJnmoZyKGt+xnm uWTA== Received: by 10.236.79.195 with SMTP id i43mr31067264yhe.53.1335965453601; Wed, 02 May 2012 06:30:53 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id p3sm2679135and.4.2012.05.02.06.30.49 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 06:30:51 -0700 (PDT) Message-ID: <4FA13708.4050202@cantab.net> Date: Wed, 02 May 2012 14:30:48 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Andreas Kinzler References: <4FA1328B.6070602@hfp.de> In-Reply-To: <4FA1328B.6070602@hfp.de> Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/12 14:11, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: > > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly check for pending events when restoring irq flags"[1] and see how much it helps? This patch is in 3.4-rc5 and is queued for 3.3.5. David [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7eb7ce4d2e8991aff4ecb71a81949a907ca755ac _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:31:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:31:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZeF-0006a8-1U; Wed, 02 May 2012 13:31:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZeD-0006a0-FR for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:31:13 +0000 Received: from [85.158.138.51:14783] by server-11.bemta-3.messagelabs.com id 1B/CC-18894-02731AF4; Wed, 02 May 2012 13:31:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335965471!24810808!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9195 invoked from network); 2 May 2012 13:31:12 -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; 2 May 2012 13:31:12 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:31: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, 2 May 2012 14:31:11 +0100 Message-ID: <1335965470.26758.58.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andreas Kinzler Date: Wed, 2 May 2012 14:31:10 +0100 In-Reply-To: <4FA1328B.6070602@hfp.de> References: <4FA1328B.6070602@hfp.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 14:11 +0100, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: There were a couple of performance fixes posted recently, one of them was "xen: correctly check for pending events when restoring irq flags" from David Vrabel, which is now in mainline as 7eb7ce4d2e89 and marked for stable backport. The other was something to do with blk i/o performance from Stefano Stabellini which I don't have a handy reference too or status on (hopefully Konrad does though). I think those will undoubtedly help although I think performance tuning of the upstream dom0 kernel is still something we need to do more of in the short term. > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s > > time make -j4 (3.2.12 linux compile): > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 5m8.793s 5m4.888s 4m20.576s > user 8m1.746s 7m59.726s 7m10.375s > sys 1m39.010s 1m32.994s 0m56.304s Did you happen to also compare 3.2.12 and 2.6.34.10 running these workloads natively? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:31:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:31:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZeF-0006a8-1U; Wed, 02 May 2012 13:31:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZeD-0006a0-FR for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:31:13 +0000 Received: from [85.158.138.51:14783] by server-11.bemta-3.messagelabs.com id 1B/CC-18894-02731AF4; Wed, 02 May 2012 13:31:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1335965471!24810808!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9195 invoked from network); 2 May 2012 13:31:12 -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; 2 May 2012 13:31:12 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:31: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, 2 May 2012 14:31:11 +0100 Message-ID: <1335965470.26758.58.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andreas Kinzler Date: Wed, 2 May 2012 14:31:10 +0100 In-Reply-To: <4FA1328B.6070602@hfp.de> References: <4FA1328B.6070602@hfp.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 14:11 +0100, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: There were a couple of performance fixes posted recently, one of them was "xen: correctly check for pending events when restoring irq flags" from David Vrabel, which is now in mainline as 7eb7ce4d2e89 and marked for stable backport. The other was something to do with blk i/o performance from Stefano Stabellini which I don't have a handy reference too or status on (hopefully Konrad does though). I think those will undoubtedly help although I think performance tuning of the upstream dom0 kernel is still something we need to do more of in the short term. > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s > > time make -j4 (3.2.12 linux compile): > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 5m8.793s 5m4.888s 4m20.576s > user 8m1.746s 7m59.726s 7m10.375s > sys 1m39.010s 1m32.994s 0m56.304s Did you happen to also compare 3.2.12 and 2.6.34.10 running these workloads natively? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:37:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:37:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZjm-0006sS-Qe; Wed, 02 May 2012 13:36:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZjk-0006sM-W1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:36:57 +0000 Received: from [85.158.143.35:47013] by server-3.bemta-4.messagelabs.com id 5E/D7-05853-87831AF4; Wed, 02 May 2012 13:36:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1335965814!14478084!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30173 invoked from network); 2 May 2012 13:36: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; 2 May 2012 13:36:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247793" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:36:54 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 14:36:54 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPZji-0001wx-9Z; Wed, 02 May 2012 13:36:54 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPZji-0000ES-4n; Wed, 02 May 2012 14:36:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 14:36:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12778: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12778 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12778/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12767 build-i386 2 host-install(2) broken in 12775 REGR. vs. 12767 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 3 host-install(3) broken pass in 12775 test-amd64-amd64-xl-sedf 3 host-install(3) broken pass in 12775 Regressions which are regarded as allowable (not blocking): test-i386-i386-pv 3 host-install(3) broken like 12765 test-amd64-i386-xl-credit2 3 host-install(3) broken like 12767 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken like 12767 test-amd64-amd64-pv 3 host-install(3) broken in 12775 like 12765 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-pv 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-pv 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-pair 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-win 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-pair 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-win 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked in 12775 n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf broken test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 13:37:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 13:37:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZjm-0006sS-Qe; Wed, 02 May 2012 13:36:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPZjk-0006sM-W1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 13:36:57 +0000 Received: from [85.158.143.35:47013] by server-3.bemta-4.messagelabs.com id 5E/D7-05853-87831AF4; Wed, 02 May 2012 13:36:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1335965814!14478084!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30173 invoked from network); 2 May 2012 13:36: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; 2 May 2012 13:36:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12247793" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 13:36:54 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 14:36:54 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPZji-0001wx-9Z; Wed, 02 May 2012 13:36:54 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPZji-0000ES-4n; Wed, 02 May 2012 14:36:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 14:36:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12778: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12778 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12778/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12767 build-i386 2 host-install(2) broken in 12775 REGR. vs. 12767 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 3 host-install(3) broken pass in 12775 test-amd64-amd64-xl-sedf 3 host-install(3) broken pass in 12775 Regressions which are regarded as allowable (not blocking): test-i386-i386-pv 3 host-install(3) broken like 12765 test-amd64-i386-xl-credit2 3 host-install(3) broken like 12767 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken like 12767 test-amd64-amd64-pv 3 host-install(3) broken in 12775 like 12765 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-pv 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-pv 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-pair 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 12775 n/a test-amd64-i386-win 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-pair 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-win 1 xen-build-check(1) blocked in 12775 n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked in 12775 n/a version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 broken test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf broken test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 14:57:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 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 ) id 1SPazU-0007cj-Uy; Wed, 02 May 2012 14:57:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPazS-0007cb-IN for xen-devel@lists.xensource.com; Wed, 02 May 2012 14:57:15 +0000 Received: from [85.158.143.35:58217] by server-1.bemta-4.messagelabs.com id CD/80-20925-94B41AF4; Wed, 02 May 2012 14:57:13 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335970623!9531231!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3159 invoked from network); 2 May 2012 14:57:03 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-4.tower-21.messagelabs.com with SMTP; 2 May 2012 14:57:03 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPazC-0003oe-Ny; Wed, 02 May 2012 14:57:00 +0000 Message-ID: <4FA14B38.8080804@canonical.com> Date: Wed, 02 May 2012 16:56:56 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> In-Reply-To: <20120501225456.GA13757@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8154349337432514550==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8154349337432514550== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8743CEE041A746E466A979FC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8743CEE041A746E466A979FC Content-Type: multipart/mixed; boundary="------------060902080104000706080807" This is a multi-part message in MIME format. --------------060902080104000706080807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:54, Konrad Rzeszutek Wilk wrote: > What is the involvment of x86_cpu_to_apicid to acpi_processor_register_= performance? > Or is this more of a stab in the dark? >=20 > Stefan, one way to debug this is to make the driver be a module and the= n > configure the /sys/../acpi/debug_level and debug_layer to be 0xffffffff= > and try loading the module. It should print out tons of data (And the r= eason > it returned -Exxx). For completeness here the run without the modification Boris had suggeste= d. --------------060902080104000706080807 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.2" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.2" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg1 SMP Wed May 2 10:10:23= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg1-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 2/0x11, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 2: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 3/0x12, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 3: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 4/0x13, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 4: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 5/0x14, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 5: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 6/0x15, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 6: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 7/0x16, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 7: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 8/0x17, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 8: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.196 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.39 BogoMIPS (lpj=3D8000784) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.007701] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016613] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019176] Mount-cache hash table entries: 256 [ 0.019421] Initializing cgroup subsys cpuacct [ 0.019432] Initializing cgroup subsys memory [ 0.019452] Initializing cgroup subsys devices [ 0.019458] Initializing cgroup subsys freezer [ 0.019463] Initializing cgroup subsys blkio [ 0.019479] Initializing cgroup subsys perf_event [ 0.019582] tseg: 00dff00000 [ 0.019590] CPU: Physical Processor ID: 0 [ 0.019594] CPU: Processor Core ID: 0 [ 0.022490] ACPI: Core revision 20110623 [ 0.038531] ftrace: allocating 27102 entries in 107 pages [ 0.040132] cpu 0 spinlock event irq 273 [ 0.040233] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040497] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040627] installing Xen timer for CPU 1 [ 0.040645] cpu 1 spinlock event irq 279 [ 0.040850] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040972] installing Xen timer for CPU 2 [ 0.040990] cpu 2 spinlock event irq 285 [ 0.041148] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041262] installing Xen timer for CPU 3 [ 0.041277] cpu 3 spinlock event irq 291 [ 0.041438] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041555] installing Xen timer for CPU 4 [ 0.041570] cpu 4 spinlock event irq 297 [ 0.041752] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041877] installing Xen timer for CPU 5 [ 0.041893] cpu 5 spinlock event irq 303 [ 0.042051] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042166] installing Xen timer for CPU 6 [ 0.042182] cpu 6 spinlock event irq 309 [ 0.042337] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042452] installing Xen timer for CPU 7 [ 0.042468] cpu 7 spinlock event irq 315 [ 0.042628] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042660] Brought up 8 CPUs [ 0.042889] devtmpfs: initialized [ 0.045526] EVM: security.selinux [ 0.045531] EVM: security.SMACK64 [ 0.045535] EVM: security.capability [ 0.045610] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045610] Grant table initialized [ 0.045610] print_constraints: dummy:=20 [ 0.045610] RTC time: 13:16:01, date: 05/02/12 [ 0.045610] NET: Registered protocol family 16 [ 0.045610] Trying to unpack rootfs image as initramfs... [ 0.060275] node 0 link 0: io port [1000, ffffff] [ 0.060290] TOM: 00000000e0000000 aka 3584M [ 0.060296] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060307] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060315] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060324] node 0 link 0: mmio [a0000, bffff] [ 0.060332] TOM2: 0000000820000000 aka 33280M [ 0.060337] bus: [00, 1f] on node 0 link 0 [ 0.060341] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060346] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060351] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060356] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060376] Extended Config Space enabled on 2 nodes [ 0.060550] ACPI: bus type pci registered [ 0.060654] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060663] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.175090] Freeing initrd memory: 40072k freed [ 0.219594] PCI: Using configuration type 1 for base access [ 0.221163] bio: create slab at 0 [ 0.221163] ACPI: Added _OSI(Module Device) [ 0.221163] ACPI: Added _OSI(Processor Device) [ 0.221163] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221163] ACPI: Added _OSI(Processor Aggregator Device) [ 0.224162] ACPI: EC: Look up EC in DSDT [ 0.228609] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253661] ACPI: Interpreter enabled [ 0.253670] ACPI: (supports S0 S1 S4 S5) [ 0.253715] ACPI: Using IOAPIC for interrupt routing [ 0.267198] ACPI: No dock devices found. [ 0.267261] HEST: Table parsing has been initialized. [ 0.267268] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267573] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268134] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268141] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268147] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268153] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268160] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268201] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268398] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268634] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268757] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268766] pci 0000:00:09.0: PME# disabled [ 0.268808] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268924] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.268932] pci 0000:00:0a.0: PME# disabled [ 0.268995] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269033] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269053] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269073] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269093] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269113] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269133] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269241] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269268] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269392] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269419] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269553] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269591] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269749] pci 0000:00:12.2: supports D1 D2 [ 0.269754] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269763] pci 0000:00:12.2: PME# disabled [ 0.269803] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269862] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.269986] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270013] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270149] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270187] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270345] pci 0000:00:13.2: supports D1 D2 [ 0.270350] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270360] pci 0000:00:13.2: PME# disabled [ 0.270406] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270596] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270741] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270822] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270849] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.270992] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271121] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271182] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271282] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271372] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271485] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271602] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271665] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271732] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271825] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272045] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272090] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272115] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272294] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272305] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280070] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280079] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280204] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280239] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280284] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280308] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280489] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280501] pci 0000:02:00.0: PME# disabled [ 0.288055] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288144] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288183] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288206] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288228] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288437] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288451] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288461] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288467] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288473] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288480] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288487] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288493] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288529] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288940] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289045] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289157] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289332] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289340] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289346] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307515] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307653] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307787] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307917] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308023] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308156] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308321] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308456] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308527] xen/balloon: Initialising balloon driver. [ 0.351974] xen-balloon: Initialising balloon driver. [ 0.352005] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352140] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352140] vgaarb: loaded [ 0.352140] vgaarb: bridge control possible 0000:01:04.0 [ 0.352232] i2c-core: driver [aat2870] using legacy suspend method [ 0.352237] i2c-core: driver [aat2870] using legacy resume method [ 0.352330] SCSI subsystem initialized [ 0.352403] libata version 3.00 loaded. [ 0.352403] usbcore: registered new interface driver usbfs [ 0.352403] usbcore: registered new interface driver hub [ 0.352403] usbcore: registered new device driver usb [ 0.352403] PCI: Using ACPI for IRQ routing [ 0.360021] PCI: pci_cache_line_size set to 64 bytes [ 0.360021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.360021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.360021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.360114] NetLabel: Initializing [ 0.360119] NetLabel: domain hash size =3D 128 [ 0.360123] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.360140] NetLabel: unlabeled traffic allowed by default [ 0.360216] Switching to clocksource xen [ 0.369450] AppArmor: AppArmor Filesystem Enabled [ 0.369488] pnp: PnP ACPI init [ 0.369509] ACPI: bus type pnp registered [ 0.369871] pnp 00:00: [bus 00-ff] [ 0.369876] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.369882] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.369887] pnp 00:00: [io 0x0d00-0xffff window] [ 0.369892] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.369897] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.369902] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.369941] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.370062] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.370336] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.370343] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.370426] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370605] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.370667] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.370674] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.371348] pnp 00:03: [dma 4] [ 0.371353] pnp 00:03: [io 0x0000-0x000f] [ 0.371358] pnp 00:03: [io 0x0081-0x0083] [ 0.371362] pnp 00:03: [io 0x0087] [ 0.371366] pnp 00:03: [io 0x0089-0x008b] [ 0.371371] pnp 00:03: [io 0x008f] [ 0.371375] pnp 00:03: [io 0x00c0-0x00df] [ 0.371432] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.371459] pnp 00:04: [io 0x0070-0x0071] [ 0.371466] xen: registering gsi 8 triggering 1 polarity 0 [ 0.371475] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.371480] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.371502] pnp 00:04: [irq 8] [ 0.371559] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.371629] pnp 00:05: [io 0x0060] [ 0.371634] pnp 00:05: [io 0x0064] [ 0.371638] xen: registering gsi 1 triggering 1 polarity 0 [ 0.371643] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.371648] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.371661] pnp 00:05: [irq 1] [ 0.371717] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.371831] xen: registering gsi 12 triggering 1 polarity 0 [ 0.371837] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.371842] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.371855] pnp 00:06: [irq 12] [ 0.371915] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.371936] pnp 00:07: [io 0x0061] [ 0.371995] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.372016] pnp 00:08: [io 0x00f0-0x00ff] [ 0.372021] xen: registering gsi 13 triggering 1 polarity 0 [ 0.372026] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.372031] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.372044] pnp 00:08: [irq 13] [ 0.372112] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.372312] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.372318] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.372324] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.372407] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.372414] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372501] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.372563] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.372889] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.372894] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.372977] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.372984] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.372991] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.373482] pnp 00:0c: [io 0x0010-0x001f] [ 0.373487] pnp 00:0c: [io 0x0022-0x003f] [ 0.373491] pnp 00:0c: [io 0x0062-0x0063] [ 0.373496] pnp 00:0c: [io 0x0065-0x006f] [ 0.373500] pnp 00:0c: [io 0x0072-0x007f] [ 0.373505] pnp 00:0c: [io 0x0080] [ 0.373509] pnp 00:0c: [io 0x0084-0x0086] [ 0.373513] pnp 00:0c: [io 0x0088] [ 0.373517] pnp 00:0c: [io 0x008c-0x008e] [ 0.373522] pnp 00:0c: [io 0x0090-0x009f] [ 0.373526] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.373531] pnp 00:0c: [io 0x00b1] [ 0.373535] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.373539] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.373544] pnp 00:0c: [io 0x0550-0x0551] [ 0.373548] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.373553] pnp 00:0c: [io 0x040b] [ 0.373557] pnp 00:0c: [io 0x04d6] [ 0.373561] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.373565] pnp 00:0c: [io 0x0c14] [ 0.373570] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.373574] pnp 00:0c: [io 0x0c52] [ 0.373578] pnp 00:0c: [io 0x0c6c] [ 0.373582] pnp 00:0c: [io 0x0c6f] [ 0.373586] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.373591] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.373595] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.373600] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.373604] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.373608] pnp 00:0c: [io 0x0800-0x089f] [ 0.373613] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.373619] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.373623] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.373627] pnp 00:0c: [io 0x0900-0x090f] [ 0.373632] pnp 00:0c: [io 0x0910-0x091f] [ 0.373636] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.373641] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.373646] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.373651] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.373659] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.373770] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.373777] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.373783] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.373788] system 00:0c: [io 0x040b] has been reserved [ 0.373794] system 00:0c: [io 0x04d6] has been reserved [ 0.373799] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.373805] system 00:0c: [io 0x0c14] has been reserved [ 0.373811] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.373817] system 00:0c: [io 0x0c52] has been reserved [ 0.373822] system 00:0c: [io 0x0c6c] has been reserved [ 0.373827] system 00:0c: [io 0x0c6f] has been reserved [ 0.373833] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.373839] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.373845] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.373850] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.373856] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.373865] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.373871] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.373877] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.373883] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.373889] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.373895] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.373902] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.373908] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.373915] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.374487] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.374493] xen: registering gsi 4 triggering 1 polarity 0 [ 0.374498] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.374503] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.374519] pnp 00:0d: [irq 4] [ 0.374524] pnp 00:0d: [dma 0 disabled] [ 0.374648] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.375186] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.375191] xen: registering gsi 3 triggering 1 polarity 0 [ 0.375197] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.375201] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.375206] Already setup the GSI :3 [ 0.375211] pnp 00:0e: [irq 3] [ 0.375215] pnp 00:0e: [dma 0 disabled] [ 0.375334] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.375508] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.375590] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.375598] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.376526] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.376532] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.376537] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.376542] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.376551] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.376650] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.376656] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.376663] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.376669] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.376676] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.376683] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.377012] pnp: PnP ACPI: found 17 devices [ 0.377017] ACPI: ACPI bus type pnp unregistered [ 0.384322] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.384348] PCI: max bus depth: 1 pci_try_num: 2 [ 0.384387] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.384394] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.384404] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.384419] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.384425] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.384435] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.384449] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.384464] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.384474] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.384497] xen: registering gsi 17 triggering 0 polarity 1 [ 0.384517] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.384532] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.384542] pci 0000:00:09.0: setting latency timer to 64 [ 0.384553] xen: registering gsi 18 triggering 0 polarity 1 [ 0.384563] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.384576] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.384584] pci 0000:00:0a.0: setting latency timer to 64 [ 0.384600] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.384606] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.384611] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.384617] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.384622] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.384628] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.384634] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.384640] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.384646] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.384652] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.384658] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.384664] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.384670] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.384676] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.384681] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.384687] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.384745] NET: Registered protocol family 2 [ 0.386858] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.392197] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.395428] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.395775] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.395782] TCP reno registered [ 0.395912] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.396171] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.396454] NET: Registered protocol family 1 [ 0.396513] xen: registering gsi 16 triggering 0 polarity 1 [ 0.396535] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.396556] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.124169] pci 0000:00:12.0: PCI INT A disabled [ 1.124201] xen: registering gsi 16 triggering 0 polarity 1 [ 1.124216] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.124221] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.124226] Already setup the GSI :16 [ 1.124233] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.208174] pci 0000:00:12.1: PCI INT A disabled [ 1.208207] xen: registering gsi 17 triggering 0 polarity 1 [ 1.208220] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.208225] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.208231] Already setup the GSI :17 [ 1.208237] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.208370] pci 0000:00:12.2: PCI INT B disabled [ 1.208386] xen: registering gsi 18 triggering 0 polarity 1 [ 1.208392] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.208397] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.208401] Already setup the GSI :18 [ 1.208406] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.292207] pci 0000:00:13.0: PCI INT A disabled [ 1.292238] xen: registering gsi 18 triggering 0 polarity 1 [ 1.292251] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.292256] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.292262] Already setup the GSI :18 [ 1.292267] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.376173] pci 0000:00:13.1: PCI INT A disabled [ 1.376207] xen: registering gsi 19 triggering 0 polarity 1 [ 1.376234] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.376252] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.376388] pci 0000:00:13.2: PCI INT B disabled [ 1.376414] xen: registering gsi 18 triggering 0 polarity 1 [ 1.376419] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.376424] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.376429] Already setup the GSI :18 [ 1.376433] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.460176] pci 0000:00:14.5: PCI INT C disabled [ 1.460263] pci 0000:01:04.0: Boot video device [ 1.460271] PCI: CLS 64 bytes, default 64 [ 1.461342] audit: initializing netlink socket (disabled) [ 1.461361] type=3D2000 audit(1335964562.601:1): initialized [ 1.489601] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.491852] VFS: Disk quotas dquot_6.5.2 [ 1.491932] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.492683] fuse init (API version 7.17) [ 1.492825] msgmni has been set to 1479 [ 1.493529] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.493586] io scheduler noop registered [ 1.493591] io scheduler deadline registered [ 1.493633] io scheduler cfq registered (default) [ 1.494114] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.494148] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.494341] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.494351] ACPI: Power Button [PWRB] [ 1.494412] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.494420] ACPI: Power Button [PWRF] [ 1.676958] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.677083] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.677259] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.677679] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.681442] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.800115] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.820418] hpet_acpi_add: no address or irqs in _CRS [ 1.820439] Linux agpgart interface v0.103 [ 1.824231] brd: module loaded [ 1.825115] loop: module loaded [ 1.825527] ahci 0000:00:11.0: version 3.0 [ 1.825555] xen: registering gsi 22 triggering 0 polarity 1 [ 1.825578] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.825596] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.825826] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.825836] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.826774] scsi0 : ahci [ 1.826926] scsi1 : ahci [ 1.827024] scsi2 : ahci [ 1.827120] scsi3 : ahci [ 1.827224] scsi4 : ahci [ 1.827320] scsi5 : ahci [ 1.828266] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.828274] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.828281] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.828288] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.828295] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.828303] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.828836] Fixed MDIO Bus: probed [ 1.828864] tun: Universal TUN/TAP device driver, 1.6 [ 1.828870] tun: (C) 1999-2004 Max Krasnyansky [ 1.828931] PPP generic driver version 2.4.2 [ 1.829048] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.829138] xen: registering gsi 17 triggering 0 polarity 1 [ 1.829148] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.829153] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.829158] Already setup the GSI :17 [ 1.829164] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.829198] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.829284] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.829301] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.829398] ehci_hcd 0000:00:12.2: debug port 1 [ 1.829447] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.840124] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.840320] hub 1-0:1.0: USB hub found [ 1.840328] hub 1-0:1.0: 6 ports detected [ 1.840513] xen: registering gsi 19 triggering 0 polarity 1 [ 1.840521] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.840526] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.840531] Already setup the GSI :19 [ 1.840536] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.840570] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.840647] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.840663] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.840755] ehci_hcd 0000:00:13.2: debug port 1 [ 1.840808] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.852099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.852310] hub 2-0:1.0: USB hub found [ 1.852317] hub 2-0:1.0: 6 ports detected [ 1.852441] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.852530] xen: registering gsi 16 triggering 0 polarity 1 [ 1.852538] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.852543] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.852548] Already setup the GSI :16 [ 1.852553] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.852587] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.852654] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.852724] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.912279] hub 3-0:1.0: USB hub found [ 1.912294] hub 3-0:1.0: 3 ports detected [ 1.912446] xen: registering gsi 16 triggering 0 polarity 1 [ 1.912454] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.912459] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.912463] Already setup the GSI :16 [ 1.912469] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.912504] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.912572] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.912614] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.972294] hub 4-0:1.0: USB hub found [ 1.972308] hub 4-0:1.0: 3 ports detected [ 1.972473] xen: registering gsi 18 triggering 0 polarity 1 [ 1.972481] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.972486] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.972490] Already setup the GSI :18 [ 1.972496] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.972524] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.972593] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.972660] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.032273] hub 5-0:1.0: USB hub found [ 2.032287] hub 5-0:1.0: 3 ports detected [ 2.032436] xen: registering gsi 18 triggering 0 polarity 1 [ 2.032443] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.032448] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.032453] Already setup the GSI :18 [ 2.032458] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.032493] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.032565] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.032604] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.092304] hub 6-0:1.0: USB hub found [ 2.092318] hub 6-0:1.0: 3 ports detected [ 2.092475] xen: registering gsi 18 triggering 0 polarity 1 [ 2.092483] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.092487] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.092492] Already setup the GSI :18 [ 2.092497] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.092532] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.092605] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.092656] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.148125] ata5: SATA link down (SStatus 0 SControl 300) [ 2.152407] hub 7-0:1.0: USB hub found [ 2.152421] hub 7-0:1.0: 2 ports detected [ 2.152520] uhci_hcd: USB Universal Host Controller Interface driver [ 2.152616] usbcore: registered new interface driver libusual [ 2.152672] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.155612] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.155624] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.155785] mousedev: PS/2 mouse device common for all mice [ 2.155992] rtc_cmos 00:04: RTC can wake from S4 [ 2.156199] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.156254] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.156356] device-mapper: uevent: version 1.0.3 [ 2.156451] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.156463] EFI Variables Facility v0.08 2004-May-17 [ 2.156791] TCP cubic registered [ 2.156956] NET: Registered protocol family 10 [ 2.157654] NET: Registered protocol family 17 [ 2.157678] Registering the dns_resolver key type [ 2.157881] PM: Hibernation image not present or could not be loaded. [ 2.157899] registered taskstats version 1 [ 2.164100] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.175372] Magic number: 12:240:280 [ 2.175417] tty tty17: hash matches [ 2.175565] rtc_cmos 00:04: setting system clock to 2012-05-02 13:16:0= 3 UTC (1335964563) [ 2.175696] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.175793] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.175798] EDD information not available. [ 2.188032] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.302043] Initializing USB Mass Storage driver... [ 2.302431] scsi6 : usb-storage 2-2:1.0 [ 2.302547] usbcore: registered new interface driver usb-storage [ 2.302553] USB Mass Storage support registered. [ 2.320117] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320155] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320193] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320223] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.320254] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320786] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.321220] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321227] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321248] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321256] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321275] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321282] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321435] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321443] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321598] ata6.00: configured for UDMA/100 [ 2.322467] ata4.00: configured for UDMA/133 [ 2.322500] ata1.00: configured for UDMA/133 [ 2.322651] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.322825] ata2.00: configured for UDMA/133 [ 2.322871] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.322885] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.322945] ata3.00: configured for UDMA/133 [ 2.322997] sd 0:0:0:0: [sda] Write Protect is off [ 2.323004] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.323071] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.323104] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.323340] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.323393] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.323539] sd 1:0:0:0: [sdb] Write Protect is off [ 2.323545] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.323586] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.323648] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.323877] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.323920] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.324039] sd 2:0:0:0: [sdc] Write Protect is off [ 2.324046] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.324102] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.324171] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.324392] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.324411] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.324510] sd 3:0:0:0: [sdd] Write Protect is off [ 2.324517] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.324557] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.325174] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.328738] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.328747] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.328923] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.329015] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.337560] sdb: sdb1 sdb2 [ 2.337987] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.338935] sdd: unknown partition table [ 2.339234] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.341070] sdc: unknown partition table [ 2.341349] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.444044] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.445275] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.445944] Freeing unused kernel memory: 920k freed [ 2.446270] Write protecting the kernel read-only data: 12288k [ 2.453350] Freeing unused kernel memory: 1520k freed [ 2.454493] Freeing unused kernel memory: 1140k freed [ 2.520146] udevd[165]: starting version 175 [ 2.603325] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.603337] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.603495] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.603528] xen: registering gsi 17 triggering 0 polarity 1 [ 2.603541] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.603549] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.603591] Already setup the GSI :17 [ 2.603598] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.603631] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.676127] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.714484] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.714493] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.714578] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.714808] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.714834] xen: registering gsi 18 triggering 0 polarity 1 [ 2.714846] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.714852] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.714857] Already setup the GSI :18 [ 2.714863] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.714895] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.829330] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.829339] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.829437] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.854463] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.854692] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.858390] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.858585] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.858611] usbcore: registered new interface driver usbhid [ 2.858616] usbhid: USB HID core driver [ 3.301039] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.301664] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.302434] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.303153] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.304656] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.304975] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.305358] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.305921] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.310865] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.311491] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 3.312213] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.314371] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 8.935827] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.783346] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.783361] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.812254] udevd[719]: starting version 175 [ 15.924609] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.940804] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.941886] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.942029] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.944124] MCE: In-kernel MCE decoding enabled. [ 15.945779] EDAC MC: Ver: 2.1.0 [ 15.947575] lp: driver loaded but no devices found [ 15.951215] AMD64 EDAC driver v3.4.0 [ 15.952459] Bridge firewalling registered [ 15.953066] type=3D1400 audit(1335964577.273:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D825 comm=3D"appar= mor_parser" [ 15.953754] type=3D1400 audit(1335964577.273:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D825 comm=3D"apparmor_parser" [ 15.953834] EDAC amd64: DRAM ECC enabled. [ 15.953905] EDAC amd64: F10h detected (node 0). [ 15.953981] EDAC MC: DCT0 chip selects: [ 15.953986] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.953989] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.953992] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.953995] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.953997] EDAC MC: DCT1 chip selects: [ 15.954000] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.954003] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.954006] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.954009] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.954012] EDAC amd64: using x8 syndromes. [ 15.954014] EDAC amd64: MCT channel count: 2 [ 15.954064] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.954068] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.954073] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.954077] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.954164] type=3D1400 audit(1335964577.273:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D825 comm=3D"apparmor_parser" [ 15.954191] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.957544] ipmi message handler version 39.2 [ 15.958325] ipmi device interface [ 15.961741] EDAC amd64: DRAM ECC enabled. [ 15.961751] EDAC amd64: F10h detected (node 1). [ 15.961831] EDAC MC: DCT0 chip selects: [ 15.961835] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.961838] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.961841] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.961844] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.961847] EDAC MC: DCT1 chip selects: [ 15.961850] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.961853] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.961856] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.961859] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.961862] EDAC amd64: using x8 syndromes. [ 15.961865] EDAC amd64: MCT channel count: 2 [ 15.961904] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.961908] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.961911] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.961914] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.961988] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.962103] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.963866] IPMI System Interface driver. [ 15.963946] ipmi_si: probing via SMBIOS [ 15.963950] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.963954] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.963965] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.964506] device-mapper: multipath: version 1.3.0 loaded [ 15.981254] device eth0 entered promiscuous mode [ 16.036101] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 16.043255] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 16.043367] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.085117] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 16.177926] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.179422] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.187558] ADDRCONF(NETDEV_UP): br0: link is not ready [ 17.107889] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.362235] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.157089] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.159695] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.159833] br0: port 1(eth0) entering forwarding state [ 19.159851] br0: port 1(eth0) entering forwarding state [ 19.162058] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 19.505855] init: udev-fallback-graphics main process (1834) terminate= d with status 1 [ 19.658903] init: failsafe main process (1723) killed by TERM signal [ 19.770924] type=3D1400 audit(1335964581.089:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1932 comm=3D"apparmor_parser" [ 19.771034] type=3D1400 audit(1335964581.089:6): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1933 comm=3D"= apparmor_parser" [ 19.771113] type=3D1400 audit(1335964581.089:7): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1930 comm=3D"a= pparmor_parser" [ 19.771751] type=3D1400 audit(1335964581.089:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1930 comm=3D"apparmor_parser" [ 19.772152] type=3D1400 audit(1335964581.093:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1930 comm=3D"apparmor_parser" [ 19.772188] type=3D1400 audit(1335964581.093:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1934 c= omm=3D"apparmor_parser" [ 19.772544] type=3D1400 audit(1335964581.093:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1934 comm=3D"apparmor_parser" [ 20.049999] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 20.271564] ip_tables: (C) 2000-2006 Netfilter Core Team [ 20.373030] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 20.424289] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 20.654948] Event-channel device installed. [ 20.718822] XENBUS: Unable to read cpu state [ 20.719070] XENBUS: Unable to read cpu state [ 20.719271] XENBUS: Unable to read cpu state [ 20.719477] XENBUS: Unable to read cpu state [ 20.719666] XENBUS: Unable to read cpu state [ 20.719810] XENBUS: Unable to read cpu state [ 20.719955] XENBUS: Unable to read cpu state [ 20.720132] XENBUS: Unable to read cpu state [ 21.183395] Ebtables v2.0 registered [ 21.213618] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.236526] br0: no IPv6 routers present [ 245.817700]=20 [ 245.817701] **** Context Switch from TID 0 to TID 49125104 **** [ 245.817703]=20 [ 245.817707] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.817718] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.817727] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.817737] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.817746] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.817754] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.817763] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.817772] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.817781] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.817791] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.817801] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.817819] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.817827] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.817836] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.817845] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P001] (ffff880027d50e88) [ 245.817855] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.817863] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.817878] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.817887] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.817895] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50e88 [ 245.817904] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.817913] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P001 (ffff880027d50e88) For [_PSD] (Untyped) [ 245.817923] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.817931] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.817940] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d438 found in scope [P001] ffff880027d50e88= [ 245.817950] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.817958] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.817967] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.817975] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.817984] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.817993] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.818002] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.818010] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.818019] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d438 [ 245.818028] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d709d8 [ 245.818037] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d438] Value ffff880027d709d8 [ 245.818046] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.818054] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.818063] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.818072] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.818081] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.818090] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.818108] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.818116] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.818124] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d438 [ 245.818132] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d709d8 [ 245.818141] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.818149] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.818157] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d438 SourceDesc=3Dffff880027d709d8 [Package] [ 245.818167] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d709d8 [ 245.818175] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.818184] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d709d8 [ 245.818193] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d709d8 Current Refs=3D1 [To Be Incremented] [ 245.818202] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d709d8 [ 245.818211] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250c7f30 [ 245.818224] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.818233] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818241] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818249] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d709d8 Refs=3D2, [Incremented] [ 245.818258] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818266] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818274] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818282] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818290] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250c7f78 [ 245.818298] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.818307] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818315] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818322] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff880027d716c0 [ 245.818331] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.818339] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818347] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818354] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff880027d71a68 [ 245.818363] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.818371] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818379] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818386] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d0000 [ 245.818395] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.818403] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818411] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818419] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d0048 [ 245.818427] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.818435] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818443] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818451] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250c7f30 Refs=3D2, [Incremented] [ 245.818459] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818467] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.818475] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818483] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818491] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d0048 Refs=3D2, [Incremented] [ 245.818499] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818507] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.818515] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818523] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818531] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d0000 Refs=3D2, [Incremented] [ 245.818539] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818547] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.818555] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818563] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818571] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d71a68 Refs=3D2, [Incremented] [ 245.818580] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818587] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.818596] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818603] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818611] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d716c0 Refs=3D2, [Incremented] [ 245.818620] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818628] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818636] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818644] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818651] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250c7f78 Refs=3D2, [Incremented] [ 245.818660] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.818668] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.818676] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.818684] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.818692] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.818701] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.818710] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.818718] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d709d8 [Package] [ 245.818728] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d438 [ 245.818736] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.818746] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P001._PSD Validating return Package of Type 5, Count 1 [ 245.818757] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.818766] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.818775] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d709d8 [ 245.818783] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.818791] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 245.818799] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.818808] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.818816] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.818823] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250c7f30 [ 245.818832] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.818840] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250c7f78 [ 245.818848] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818856] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff880027d716c0 [ 245.818864] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818872] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff880027d71a68 [ 245.818881] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818889] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d0000 [ 245.818897] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818905] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d0048 [ 245.818913] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818921] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.818929] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.818936] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.818944] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818952] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.818960] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.818968] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.818976] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.818984] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.818992] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.819001] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.819009] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.819017] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.819025] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 245.819033] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.819042] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.819050] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.819057] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250c7f30 [ 245.819066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.819074] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819082] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819090] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819098] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819106] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819113] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819122] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819129] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819137] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819145] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819153] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.819161] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.819169] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.819176] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819185] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.819192] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.819200] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.819208] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.819216] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.819224] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.819232] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.819241] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.819249] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.819258] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.819267] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.819284] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.819292] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d709d8 [ 245.819300] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d709d8 Current Refs=3D2 [To Be Decremented] [ 245.819310] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d709d8 [ 245.819318] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250c7f30 [ 245.819326] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.819334] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819342] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819350] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d709d8 Refs=3D1, [Decremented] [ 245.819359] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819367] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819375] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819383] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819390] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250c7f78 [ 245.819399] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.819407] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819415] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819423] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff880027d716c0 [ 245.819431] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.819439] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819447] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819455] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff880027d71a68 [ 245.819463] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.819471] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819479] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819487] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d0000 [ 245.819495] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.819503] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819511] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819519] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d0048 [ 245.819527] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.819535] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819543] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819551] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250c7f30 Refs=3D1, [Decremented] [ 245.819559] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819567] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.819575] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819583] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819591] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d0048 Refs=3D1, [Decremented] [ 245.819599] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819607] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.819615] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819623] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819631] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d0000 Refs=3D1, [Decremented] [ 245.819640] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819647] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.819656] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819663] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819671] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d71a68 Refs=3D1, [Decremented] [ 245.819680] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819687] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.819696] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819703] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819711] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d716c0 Refs=3D1, [Decremented] [ 245.819720] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819728] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819736] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819744] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819751] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250c7f78 Refs=3D1, [Decremented] [ 245.819760] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.819768] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.819776] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.819784] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.819793] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.819802] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.819810] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.819820] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.819828] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.819836] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.819844] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.819852] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.819860] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.819868] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.819876] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.819884] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.819894] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.819903] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.819920] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.819927] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.819935] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.819944] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P002] (ffff880027d50eb0) [ 245.819953] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.819961] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.819975] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.819983] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.819991] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50eb0 [ 245.819999] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.820007] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P002 (ffff880027d50eb0) For [_PSD] (Untyped) [ 245.820017] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.820025] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.820033] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d500 found in scope [P002] ffff880027d50eb0= [ 245.820043] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.820072] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.820081] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.820089] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.820098] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.820111] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.820129] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.820148] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.820167] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d500 [ 245.820189] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70b40 [ 245.820211] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d500] Value ffff880027d70b40 [ 245.820232] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.820249] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.820265] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.820283] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.820306] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.820326] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.820361] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.820381] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.820400] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d500 [ 245.820419] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70b40 [ 245.820436] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.820455] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.820472] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d500 SourceDesc=3Dffff880027d70b40 [Package] [ 245.820492] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70b40 [ 245.820508] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.820525] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70b40 [ 245.820543] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70b40 Current Refs=3D1 [To Be Incremented] [ 245.820562] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70b40 [ 245.820582] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1d38 [ 245.820598] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.820619] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820637] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820651] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70b40 Refs=3D2, [Incremented] [ 245.820671] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.820693] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.820710] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.820730] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.820751] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1d80 [ 245.820769] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.820785] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820807] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820824] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1dc8 [ 245.820841] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.820861] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820878] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820896] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1e10 [ 245.820911] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.820928] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820943] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820960] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1e58 [ 245.820981] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.820997] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.821019] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.821036] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1ea0 [ 245.821056] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.821075] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.821094] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.821112] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1d38 Refs=3D2, [Incremented] [ 245.821125] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821133] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.821141] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821149] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821161] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1ea0 Refs=3D2, [Incremented] [ 245.821169] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821177] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.821186] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821194] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821202] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1e58 Refs=3D2, [Incremented] [ 245.821211] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821219] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.821227] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821236] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821243] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1e10 Refs=3D2, [Incremented] [ 245.821252] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821260] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.821269] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821277] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821285] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1dc8 Refs=3D2, [Incremented] [ 245.821294] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821302] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.821310] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821318] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821326] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1d80 Refs=3D2, [Incremented] [ 245.821335] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.821344] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.821352] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.821363] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.821379] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.821399] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.821417] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.821436] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70b40 [Package] [ 245.821456] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d500 [ 245.821476] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.821498] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P002._PSD Validating return Package of Type 5, Count 1 [ 245.821519] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.821539] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.821556] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70b40 [ 245.821575] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.821593] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 245.821611] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.821630] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.821647] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.821667] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d1d38 [ 245.821686] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.821705] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1d80 [ 245.821725] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821745] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1dc8 [ 245.821763] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821780] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1e10 [ 245.821798] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821815] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1e58 [ 245.821832] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821851] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1ea0 [ 245.821867] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821883] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.821898] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.821916] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.821938] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.821957] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.821974] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.821991] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.822011] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.822030] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.822047] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.822067] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.822085] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.822104] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.822120] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 245.822138] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.822153] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.822173] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.822190] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d1d38 [ 245.822209] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.822228] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822247] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822264] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822282] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822297] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822312] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822331] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822349] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822368] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822382] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822391] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.822399] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.822407] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.822415] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.822423] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.822432] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.822440] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.822448] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.822456] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.822465] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.822473] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.822482] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.822490] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.822499] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.822509] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.822526] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.822539] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70b40 [ 245.822560] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70b40 Current Refs=3D2 [To Be Decremented] [ 245.822579] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70b40 [ 245.822598] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1d38 [ 245.822615] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.822633] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822647] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822666] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70b40 Refs=3D1, [Decremented] [ 245.822686] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.822704] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.822725] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.822743] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.822762] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1d80 [ 245.822782] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.822799] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822820] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822840] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1dc8 [ 245.822856] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.822874] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822892] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822911] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1e10 [ 245.822927] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.822943] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822960] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822978] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1e58 [ 245.822996] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.823014] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.823029] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.823046] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1ea0 [ 245.823065] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.823085] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.823106] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.823124] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1d38 Refs=3D1, [Decremented] [ 245.823144] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823161] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.823178] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823195] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823215] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1ea0 Refs=3D1, [Decremented] [ 245.823233] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823253] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.823270] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823285] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823302] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1e58 Refs=3D1, [Decremented] [ 245.823321] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823341] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.823359] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823379] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823397] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1e10 Refs=3D1, [Decremented] [ 245.823418] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823437] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.823455] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823470] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823487] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1dc8 Refs=3D1, [Decremented] [ 245.823509] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823531] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.823549] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823567] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823575] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1d80 Refs=3D1, [Decremented] [ 245.823585] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.823593] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.823601] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.823609] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.823619] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.823628] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.823636] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.823645] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.823653] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.823662] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.823672] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.823680] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.823688] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.823697] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.823705] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.823713] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.823723] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.823732] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.823764] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.823786] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.823806] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.823825] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P003] (ffff880027d50ed8) [ 245.823846] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.823866] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.823904] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.823918] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.823935] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50ed8 [ 245.823953] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.823973] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P003 (ffff880027d50ed8) For [_PSD] (Untyped) [ 245.823992] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824011] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824027] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d5c8 found in scope [P003] ffff880027d50ed8= [ 245.824047] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d5c8 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70ca8 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d5c8] Value ffff880027d70ca8 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d5c8 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70ca8 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d5c8 SourceDesc=3Dffff880027d70ca8 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70ca8 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70ca8 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70ca8 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70ca8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70ca8 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d5c8 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P003._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70ca8 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70ca8 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70ca8 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70ca8 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70ca8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P004] (ffff880027d50f00) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f00 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P004 (ffff880027d50f00) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d690 found in scope [P004] ffff880027d50f00= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d690 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70e10 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d690] Value ffff880027d70e10 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d690 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70e10 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d690 SourceDesc=3Dffff880027d70e10 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70e10 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70e10 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70e10 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70e10 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70e10 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d690 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P004._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70e10 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70e10 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70e10 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70e10 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P005] (ffff880027d50f28) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f28 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P005 (ffff880027d50f28) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d758 found in scope [P005] ffff880027d50f28= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d758 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70f78 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d758] Value ffff880027d70f78 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d758 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70f78 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d758 SourceDesc=3Dffff880027d70f78 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70f78 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70f78 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70f78 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70f78 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70f78 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70f78 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d758 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P005._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70f78 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70f78 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70f78 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70f78 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70f78 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P006] (ffff880027d50f50) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f50 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P006 (ffff880027d50f50) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d820 found in scope [P006] ffff880027d50f50= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d820 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d710d8 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d820] Value ffff880027d710d8 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d820 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d710d8 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d820 SourceDesc=3Dffff880027d710d8 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d710d8 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d710d8 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d710d8 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d710d8 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d710d8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d710d8 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d820 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P006._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d710d8 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d710d8 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d710d8 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d710d8 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d710d8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P007] (ffff880027d50f78) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f78 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P007 (ffff880027d50f78) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d8e8 found in scope [P007] ffff880027d50f78= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d8e8 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d71288 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d8e8] Value ffff880027d71288 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d8e8 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d71288 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d8e8 SourceDesc=3Dffff880027d71288 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d71288 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d71288 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d71288 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d71288 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d71288 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbd80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbdc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbe10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbe58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbd38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbe58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbe10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbdc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbd80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d71288 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d8e8 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P007._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d71288 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbd80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbdc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbe10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbe58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d71288 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d71288 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d71288 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d71288 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbd80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbdc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbe10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbe58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbd38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbe58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbe10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbdc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbd80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK --------------060902080104000706080807-- --------------enig8743CEE041A746E466A979FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoUs4AAoJEOhnXe7L7s6jmCEP/3UXK4/2N1k6JhAQydGpfVUk vIoOZEWxahe9ovF5WVQcp1wpz+syaqt6i7SVh/+BjzspHcjBEka3iOith1A0sd9E N7BJFyyyVTa7VJiGsKc1eIDzEcpnbujEpapSPRDjnkU1v9ggn9z5JV+KjalXDx4j felEcDb5nHnNXJqt0uToYOlGwQ301nMOtTCMSEz2oPkiCH3KnWo2McRAdt6ppdRX 52jElzJgDMOOFYg/ZWJHfI0EyLhNJZOf1u9/VYuyd8ZEk70QUNj1a6LkxFpxw3hc NxYPG2ElCxWSqT0P1pFFU2msgdvyoYTMTDMImFF61JCT/vY/ZXxtvyfNpd1c8pUZ JAn0vbVn7bO2IsOahwUnsxFXPiYdwG9vbjnYtHw5hGYwZpxLHfLNTZolPlhyNeV+ 8duSBLlcA/RDSEWTv1XxGQ4e5ZQKWF8c7sBkRacTfjgF+QhE9WA2lMfOkPkNzwO5 oaEPjuKfyyelNzi+I3vSC5+UGfQ3jeAVWPRuATysIsg2m4m7/gYseXg0ahcoifV2 E75IHAD5lWp9gAnxDB+2aClqrnhNLRj0jMt/BHO4mzcRbQJnIgYMZJwO2Siph5Mv 6z1b5sxioRUu8G/Nf2O8xTy/Fo4FHnzxBRz9go2nSOhgFZ2LQwUxT6LrJt4JnDtz 58hs1bzZaDKj63NLFdOn =fxD4 -----END PGP SIGNATURE----- --------------enig8743CEE041A746E466A979FC-- --===============8154349337432514550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8154349337432514550==-- From xen-devel-bounces@lists.xen.org Wed May 02 14:57:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 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 ) id 1SPazU-0007cj-Uy; Wed, 02 May 2012 14:57:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPazS-0007cb-IN for xen-devel@lists.xensource.com; Wed, 02 May 2012 14:57:15 +0000 Received: from [85.158.143.35:58217] by server-1.bemta-4.messagelabs.com id CD/80-20925-94B41AF4; Wed, 02 May 2012 14:57:13 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335970623!9531231!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3159 invoked from network); 2 May 2012 14:57:03 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-4.tower-21.messagelabs.com with SMTP; 2 May 2012 14:57:03 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPazC-0003oe-Ny; Wed, 02 May 2012 14:57:00 +0000 Message-ID: <4FA14B38.8080804@canonical.com> Date: Wed, 02 May 2012 16:56:56 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <20120501225456.GA13757@phenom.dumpdata.com> In-Reply-To: <20120501225456.GA13757@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8154349337432514550==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8154349337432514550== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8743CEE041A746E466A979FC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8743CEE041A746E466A979FC Content-Type: multipart/mixed; boundary="------------060902080104000706080807" This is a multi-part message in MIME format. --------------060902080104000706080807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:54, Konrad Rzeszutek Wilk wrote: > What is the involvment of x86_cpu_to_apicid to acpi_processor_register_= performance? > Or is this more of a stab in the dark? >=20 > Stefan, one way to debug this is to make the driver be a module and the= n > configure the /sys/../acpi/debug_level and debug_layer to be 0xffffffff= > and try loading the module. It should print out tons of data (And the r= eason > it returned -Exxx). For completeness here the run without the modification Boris had suggeste= d. --------------060902080104000706080807 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.2" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.2" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg1 SMP Wed May 2 10:10:23= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg1-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 2/0x11, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 2: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 3/0x12, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 3: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 4/0x13, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 4: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 5/0x14, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 5: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 6/0x15, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 6: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 7/0x16, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 7: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 8/0x17, fixing up to 0= x10 [ 0.000000] BIOS bug: APIC version mismatch, boot CPU: 0, CPU 8: versi= on 10 [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.196 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.39 BogoMIPS (lpj=3D8000784) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.007701] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016613] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019176] Mount-cache hash table entries: 256 [ 0.019421] Initializing cgroup subsys cpuacct [ 0.019432] Initializing cgroup subsys memory [ 0.019452] Initializing cgroup subsys devices [ 0.019458] Initializing cgroup subsys freezer [ 0.019463] Initializing cgroup subsys blkio [ 0.019479] Initializing cgroup subsys perf_event [ 0.019582] tseg: 00dff00000 [ 0.019590] CPU: Physical Processor ID: 0 [ 0.019594] CPU: Processor Core ID: 0 [ 0.022490] ACPI: Core revision 20110623 [ 0.038531] ftrace: allocating 27102 entries in 107 pages [ 0.040132] cpu 0 spinlock event irq 273 [ 0.040233] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040497] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040627] installing Xen timer for CPU 1 [ 0.040645] cpu 1 spinlock event irq 279 [ 0.040850] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040972] installing Xen timer for CPU 2 [ 0.040990] cpu 2 spinlock event irq 285 [ 0.041148] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041262] installing Xen timer for CPU 3 [ 0.041277] cpu 3 spinlock event irq 291 [ 0.041438] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041555] installing Xen timer for CPU 4 [ 0.041570] cpu 4 spinlock event irq 297 [ 0.041752] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041877] installing Xen timer for CPU 5 [ 0.041893] cpu 5 spinlock event irq 303 [ 0.042051] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042166] installing Xen timer for CPU 6 [ 0.042182] cpu 6 spinlock event irq 309 [ 0.042337] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042452] installing Xen timer for CPU 7 [ 0.042468] cpu 7 spinlock event irq 315 [ 0.042628] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042660] Brought up 8 CPUs [ 0.042889] devtmpfs: initialized [ 0.045526] EVM: security.selinux [ 0.045531] EVM: security.SMACK64 [ 0.045535] EVM: security.capability [ 0.045610] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045610] Grant table initialized [ 0.045610] print_constraints: dummy:=20 [ 0.045610] RTC time: 13:16:01, date: 05/02/12 [ 0.045610] NET: Registered protocol family 16 [ 0.045610] Trying to unpack rootfs image as initramfs... [ 0.060275] node 0 link 0: io port [1000, ffffff] [ 0.060290] TOM: 00000000e0000000 aka 3584M [ 0.060296] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060307] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060315] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060324] node 0 link 0: mmio [a0000, bffff] [ 0.060332] TOM2: 0000000820000000 aka 33280M [ 0.060337] bus: [00, 1f] on node 0 link 0 [ 0.060341] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060346] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060351] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060356] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060376] Extended Config Space enabled on 2 nodes [ 0.060550] ACPI: bus type pci registered [ 0.060654] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060663] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.175090] Freeing initrd memory: 40072k freed [ 0.219594] PCI: Using configuration type 1 for base access [ 0.221163] bio: create slab at 0 [ 0.221163] ACPI: Added _OSI(Module Device) [ 0.221163] ACPI: Added _OSI(Processor Device) [ 0.221163] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221163] ACPI: Added _OSI(Processor Aggregator Device) [ 0.224162] ACPI: EC: Look up EC in DSDT [ 0.228609] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253661] ACPI: Interpreter enabled [ 0.253670] ACPI: (supports S0 S1 S4 S5) [ 0.253715] ACPI: Using IOAPIC for interrupt routing [ 0.267198] ACPI: No dock devices found. [ 0.267261] HEST: Table parsing has been initialized. [ 0.267268] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267573] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268134] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268141] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268147] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268153] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268160] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268201] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268398] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268634] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268757] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268766] pci 0000:00:09.0: PME# disabled [ 0.268808] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268924] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.268932] pci 0000:00:0a.0: PME# disabled [ 0.268995] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269033] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269053] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269073] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269093] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269113] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269133] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269241] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269268] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269392] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269419] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269553] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269591] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269749] pci 0000:00:12.2: supports D1 D2 [ 0.269754] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269763] pci 0000:00:12.2: PME# disabled [ 0.269803] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269862] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.269986] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270013] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270149] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270187] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270345] pci 0000:00:13.2: supports D1 D2 [ 0.270350] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270360] pci 0000:00:13.2: PME# disabled [ 0.270406] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270596] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270741] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270822] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270849] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.270992] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271121] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271182] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271282] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271372] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271485] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271602] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271665] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271732] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271825] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272045] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272090] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272115] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272294] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272305] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280070] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280079] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280204] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280239] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280284] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280308] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280489] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280501] pci 0000:02:00.0: PME# disabled [ 0.288055] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288144] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288183] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288206] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288228] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288437] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288451] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288461] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288467] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288473] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288480] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288487] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288493] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288529] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288940] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289045] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289157] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289332] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289340] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289346] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307515] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307653] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307787] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307917] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308023] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308156] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308321] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308456] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308527] xen/balloon: Initialising balloon driver. [ 0.351974] xen-balloon: Initialising balloon driver. [ 0.352005] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352140] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352140] vgaarb: loaded [ 0.352140] vgaarb: bridge control possible 0000:01:04.0 [ 0.352232] i2c-core: driver [aat2870] using legacy suspend method [ 0.352237] i2c-core: driver [aat2870] using legacy resume method [ 0.352330] SCSI subsystem initialized [ 0.352403] libata version 3.00 loaded. [ 0.352403] usbcore: registered new interface driver usbfs [ 0.352403] usbcore: registered new interface driver hub [ 0.352403] usbcore: registered new device driver usb [ 0.352403] PCI: Using ACPI for IRQ routing [ 0.360021] PCI: pci_cache_line_size set to 64 bytes [ 0.360021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.360021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.360021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.360114] NetLabel: Initializing [ 0.360119] NetLabel: domain hash size =3D 128 [ 0.360123] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.360140] NetLabel: unlabeled traffic allowed by default [ 0.360216] Switching to clocksource xen [ 0.369450] AppArmor: AppArmor Filesystem Enabled [ 0.369488] pnp: PnP ACPI init [ 0.369509] ACPI: bus type pnp registered [ 0.369871] pnp 00:00: [bus 00-ff] [ 0.369876] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.369882] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.369887] pnp 00:00: [io 0x0d00-0xffff window] [ 0.369892] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.369897] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.369902] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.369941] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.370062] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.370336] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.370343] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.370426] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370605] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.370667] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.370674] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.371348] pnp 00:03: [dma 4] [ 0.371353] pnp 00:03: [io 0x0000-0x000f] [ 0.371358] pnp 00:03: [io 0x0081-0x0083] [ 0.371362] pnp 00:03: [io 0x0087] [ 0.371366] pnp 00:03: [io 0x0089-0x008b] [ 0.371371] pnp 00:03: [io 0x008f] [ 0.371375] pnp 00:03: [io 0x00c0-0x00df] [ 0.371432] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.371459] pnp 00:04: [io 0x0070-0x0071] [ 0.371466] xen: registering gsi 8 triggering 1 polarity 0 [ 0.371475] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.371480] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.371502] pnp 00:04: [irq 8] [ 0.371559] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.371629] pnp 00:05: [io 0x0060] [ 0.371634] pnp 00:05: [io 0x0064] [ 0.371638] xen: registering gsi 1 triggering 1 polarity 0 [ 0.371643] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.371648] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.371661] pnp 00:05: [irq 1] [ 0.371717] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.371831] xen: registering gsi 12 triggering 1 polarity 0 [ 0.371837] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.371842] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.371855] pnp 00:06: [irq 12] [ 0.371915] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.371936] pnp 00:07: [io 0x0061] [ 0.371995] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.372016] pnp 00:08: [io 0x00f0-0x00ff] [ 0.372021] xen: registering gsi 13 triggering 1 polarity 0 [ 0.372026] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.372031] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.372044] pnp 00:08: [irq 13] [ 0.372112] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.372312] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.372318] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.372324] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.372407] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.372414] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372501] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.372563] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.372889] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.372894] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.372977] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.372984] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.372991] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.373482] pnp 00:0c: [io 0x0010-0x001f] [ 0.373487] pnp 00:0c: [io 0x0022-0x003f] [ 0.373491] pnp 00:0c: [io 0x0062-0x0063] [ 0.373496] pnp 00:0c: [io 0x0065-0x006f] [ 0.373500] pnp 00:0c: [io 0x0072-0x007f] [ 0.373505] pnp 00:0c: [io 0x0080] [ 0.373509] pnp 00:0c: [io 0x0084-0x0086] [ 0.373513] pnp 00:0c: [io 0x0088] [ 0.373517] pnp 00:0c: [io 0x008c-0x008e] [ 0.373522] pnp 00:0c: [io 0x0090-0x009f] [ 0.373526] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.373531] pnp 00:0c: [io 0x00b1] [ 0.373535] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.373539] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.373544] pnp 00:0c: [io 0x0550-0x0551] [ 0.373548] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.373553] pnp 00:0c: [io 0x040b] [ 0.373557] pnp 00:0c: [io 0x04d6] [ 0.373561] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.373565] pnp 00:0c: [io 0x0c14] [ 0.373570] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.373574] pnp 00:0c: [io 0x0c52] [ 0.373578] pnp 00:0c: [io 0x0c6c] [ 0.373582] pnp 00:0c: [io 0x0c6f] [ 0.373586] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.373591] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.373595] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.373600] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.373604] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.373608] pnp 00:0c: [io 0x0800-0x089f] [ 0.373613] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.373619] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.373623] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.373627] pnp 00:0c: [io 0x0900-0x090f] [ 0.373632] pnp 00:0c: [io 0x0910-0x091f] [ 0.373636] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.373641] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.373646] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.373651] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.373659] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.373770] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.373777] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.373783] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.373788] system 00:0c: [io 0x040b] has been reserved [ 0.373794] system 00:0c: [io 0x04d6] has been reserved [ 0.373799] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.373805] system 00:0c: [io 0x0c14] has been reserved [ 0.373811] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.373817] system 00:0c: [io 0x0c52] has been reserved [ 0.373822] system 00:0c: [io 0x0c6c] has been reserved [ 0.373827] system 00:0c: [io 0x0c6f] has been reserved [ 0.373833] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.373839] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.373845] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.373850] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.373856] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.373865] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.373871] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.373877] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.373883] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.373889] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.373895] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.373902] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.373908] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.373915] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.374487] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.374493] xen: registering gsi 4 triggering 1 polarity 0 [ 0.374498] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.374503] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.374519] pnp 00:0d: [irq 4] [ 0.374524] pnp 00:0d: [dma 0 disabled] [ 0.374648] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.375186] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.375191] xen: registering gsi 3 triggering 1 polarity 0 [ 0.375197] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.375201] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.375206] Already setup the GSI :3 [ 0.375211] pnp 00:0e: [irq 3] [ 0.375215] pnp 00:0e: [dma 0 disabled] [ 0.375334] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.375508] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.375590] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.375598] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.376526] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.376532] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.376537] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.376542] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.376551] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.376650] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.376656] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.376663] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.376669] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.376676] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.376683] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.377012] pnp: PnP ACPI: found 17 devices [ 0.377017] ACPI: ACPI bus type pnp unregistered [ 0.384322] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.384348] PCI: max bus depth: 1 pci_try_num: 2 [ 0.384387] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.384394] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.384404] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.384419] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.384425] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.384435] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.384449] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.384464] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.384474] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.384497] xen: registering gsi 17 triggering 0 polarity 1 [ 0.384517] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.384532] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.384542] pci 0000:00:09.0: setting latency timer to 64 [ 0.384553] xen: registering gsi 18 triggering 0 polarity 1 [ 0.384563] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.384576] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.384584] pci 0000:00:0a.0: setting latency timer to 64 [ 0.384600] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.384606] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.384611] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.384617] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.384622] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.384628] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.384634] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.384640] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.384646] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.384652] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.384658] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.384664] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.384670] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.384676] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.384681] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.384687] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.384745] NET: Registered protocol family 2 [ 0.386858] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.392197] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.395428] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.395775] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.395782] TCP reno registered [ 0.395912] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.396171] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.396454] NET: Registered protocol family 1 [ 0.396513] xen: registering gsi 16 triggering 0 polarity 1 [ 0.396535] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.396556] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.124169] pci 0000:00:12.0: PCI INT A disabled [ 1.124201] xen: registering gsi 16 triggering 0 polarity 1 [ 1.124216] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.124221] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.124226] Already setup the GSI :16 [ 1.124233] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.208174] pci 0000:00:12.1: PCI INT A disabled [ 1.208207] xen: registering gsi 17 triggering 0 polarity 1 [ 1.208220] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.208225] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.208231] Already setup the GSI :17 [ 1.208237] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.208370] pci 0000:00:12.2: PCI INT B disabled [ 1.208386] xen: registering gsi 18 triggering 0 polarity 1 [ 1.208392] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.208397] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.208401] Already setup the GSI :18 [ 1.208406] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.292207] pci 0000:00:13.0: PCI INT A disabled [ 1.292238] xen: registering gsi 18 triggering 0 polarity 1 [ 1.292251] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.292256] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.292262] Already setup the GSI :18 [ 1.292267] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.376173] pci 0000:00:13.1: PCI INT A disabled [ 1.376207] xen: registering gsi 19 triggering 0 polarity 1 [ 1.376234] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.376252] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.376388] pci 0000:00:13.2: PCI INT B disabled [ 1.376414] xen: registering gsi 18 triggering 0 polarity 1 [ 1.376419] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.376424] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.376429] Already setup the GSI :18 [ 1.376433] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.460176] pci 0000:00:14.5: PCI INT C disabled [ 1.460263] pci 0000:01:04.0: Boot video device [ 1.460271] PCI: CLS 64 bytes, default 64 [ 1.461342] audit: initializing netlink socket (disabled) [ 1.461361] type=3D2000 audit(1335964562.601:1): initialized [ 1.489601] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.491852] VFS: Disk quotas dquot_6.5.2 [ 1.491932] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.492683] fuse init (API version 7.17) [ 1.492825] msgmni has been set to 1479 [ 1.493529] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.493586] io scheduler noop registered [ 1.493591] io scheduler deadline registered [ 1.493633] io scheduler cfq registered (default) [ 1.494114] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.494148] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.494341] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.494351] ACPI: Power Button [PWRB] [ 1.494412] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.494420] ACPI: Power Button [PWRF] [ 1.676958] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.677083] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.677259] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.677679] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.681442] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.800115] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.820418] hpet_acpi_add: no address or irqs in _CRS [ 1.820439] Linux agpgart interface v0.103 [ 1.824231] brd: module loaded [ 1.825115] loop: module loaded [ 1.825527] ahci 0000:00:11.0: version 3.0 [ 1.825555] xen: registering gsi 22 triggering 0 polarity 1 [ 1.825578] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.825596] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.825826] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.825836] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.826774] scsi0 : ahci [ 1.826926] scsi1 : ahci [ 1.827024] scsi2 : ahci [ 1.827120] scsi3 : ahci [ 1.827224] scsi4 : ahci [ 1.827320] scsi5 : ahci [ 1.828266] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.828274] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.828281] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.828288] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.828295] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.828303] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.828836] Fixed MDIO Bus: probed [ 1.828864] tun: Universal TUN/TAP device driver, 1.6 [ 1.828870] tun: (C) 1999-2004 Max Krasnyansky [ 1.828931] PPP generic driver version 2.4.2 [ 1.829048] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.829138] xen: registering gsi 17 triggering 0 polarity 1 [ 1.829148] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.829153] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.829158] Already setup the GSI :17 [ 1.829164] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.829198] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.829284] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.829301] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.829398] ehci_hcd 0000:00:12.2: debug port 1 [ 1.829447] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.840124] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.840320] hub 1-0:1.0: USB hub found [ 1.840328] hub 1-0:1.0: 6 ports detected [ 1.840513] xen: registering gsi 19 triggering 0 polarity 1 [ 1.840521] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.840526] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.840531] Already setup the GSI :19 [ 1.840536] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.840570] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.840647] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.840663] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.840755] ehci_hcd 0000:00:13.2: debug port 1 [ 1.840808] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.852099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.852310] hub 2-0:1.0: USB hub found [ 1.852317] hub 2-0:1.0: 6 ports detected [ 1.852441] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.852530] xen: registering gsi 16 triggering 0 polarity 1 [ 1.852538] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.852543] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.852548] Already setup the GSI :16 [ 1.852553] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.852587] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.852654] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.852724] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.912279] hub 3-0:1.0: USB hub found [ 1.912294] hub 3-0:1.0: 3 ports detected [ 1.912446] xen: registering gsi 16 triggering 0 polarity 1 [ 1.912454] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.912459] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.912463] Already setup the GSI :16 [ 1.912469] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.912504] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.912572] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.912614] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.972294] hub 4-0:1.0: USB hub found [ 1.972308] hub 4-0:1.0: 3 ports detected [ 1.972473] xen: registering gsi 18 triggering 0 polarity 1 [ 1.972481] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.972486] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.972490] Already setup the GSI :18 [ 1.972496] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.972524] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.972593] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.972660] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.032273] hub 5-0:1.0: USB hub found [ 2.032287] hub 5-0:1.0: 3 ports detected [ 2.032436] xen: registering gsi 18 triggering 0 polarity 1 [ 2.032443] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.032448] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.032453] Already setup the GSI :18 [ 2.032458] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.032493] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.032565] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.032604] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.092304] hub 6-0:1.0: USB hub found [ 2.092318] hub 6-0:1.0: 3 ports detected [ 2.092475] xen: registering gsi 18 triggering 0 polarity 1 [ 2.092483] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.092487] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.092492] Already setup the GSI :18 [ 2.092497] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.092532] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.092605] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.092656] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.148125] ata5: SATA link down (SStatus 0 SControl 300) [ 2.152407] hub 7-0:1.0: USB hub found [ 2.152421] hub 7-0:1.0: 2 ports detected [ 2.152520] uhci_hcd: USB Universal Host Controller Interface driver [ 2.152616] usbcore: registered new interface driver libusual [ 2.152672] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.155612] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.155624] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.155785] mousedev: PS/2 mouse device common for all mice [ 2.155992] rtc_cmos 00:04: RTC can wake from S4 [ 2.156199] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.156254] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.156356] device-mapper: uevent: version 1.0.3 [ 2.156451] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.156463] EFI Variables Facility v0.08 2004-May-17 [ 2.156791] TCP cubic registered [ 2.156956] NET: Registered protocol family 10 [ 2.157654] NET: Registered protocol family 17 [ 2.157678] Registering the dns_resolver key type [ 2.157881] PM: Hibernation image not present or could not be loaded. [ 2.157899] registered taskstats version 1 [ 2.164100] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.175372] Magic number: 12:240:280 [ 2.175417] tty tty17: hash matches [ 2.175565] rtc_cmos 00:04: setting system clock to 2012-05-02 13:16:0= 3 UTC (1335964563) [ 2.175696] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.175793] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.175798] EDD information not available. [ 2.188032] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.302043] Initializing USB Mass Storage driver... [ 2.302431] scsi6 : usb-storage 2-2:1.0 [ 2.302547] usbcore: registered new interface driver usb-storage [ 2.302553] USB Mass Storage support registered. [ 2.320117] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320155] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320193] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320223] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.320254] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.320786] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.321220] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321227] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321248] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321256] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321275] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321282] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321435] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.321443] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.321598] ata6.00: configured for UDMA/100 [ 2.322467] ata4.00: configured for UDMA/133 [ 2.322500] ata1.00: configured for UDMA/133 [ 2.322651] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.322825] ata2.00: configured for UDMA/133 [ 2.322871] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.322885] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.322945] ata3.00: configured for UDMA/133 [ 2.322997] sd 0:0:0:0: [sda] Write Protect is off [ 2.323004] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.323071] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.323104] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.323340] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.323393] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.323539] sd 1:0:0:0: [sdb] Write Protect is off [ 2.323545] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.323586] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.323648] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.323877] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.323920] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.324039] sd 2:0:0:0: [sdc] Write Protect is off [ 2.324046] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.324102] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.324171] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.324392] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.324411] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.324510] sd 3:0:0:0: [sdd] Write Protect is off [ 2.324517] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.324557] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.325174] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.328738] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.328747] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.328923] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.329015] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.337560] sdb: sdb1 sdb2 [ 2.337987] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.338935] sdd: unknown partition table [ 2.339234] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.341070] sdc: unknown partition table [ 2.341349] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.444044] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.445275] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.445944] Freeing unused kernel memory: 920k freed [ 2.446270] Write protecting the kernel read-only data: 12288k [ 2.453350] Freeing unused kernel memory: 1520k freed [ 2.454493] Freeing unused kernel memory: 1140k freed [ 2.520146] udevd[165]: starting version 175 [ 2.603325] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.603337] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.603495] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.603528] xen: registering gsi 17 triggering 0 polarity 1 [ 2.603541] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.603549] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.603591] Already setup the GSI :17 [ 2.603598] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.603631] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.676127] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.714484] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.714493] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.714578] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.714808] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.714834] xen: registering gsi 18 triggering 0 polarity 1 [ 2.714846] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.714852] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.714857] Already setup the GSI :18 [ 2.714863] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.714895] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.829330] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.829339] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.829437] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.854463] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.854692] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.858390] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.858585] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.858611] usbcore: registered new interface driver usbhid [ 2.858616] usbhid: USB HID core driver [ 3.301039] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.301664] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.302434] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.303153] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.304656] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.304975] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.305358] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.305921] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.310865] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.311491] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 3.312213] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.314371] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 8.935827] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.783346] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.783361] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.812254] udevd[719]: starting version 175 [ 15.924609] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.940804] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.941886] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.942029] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.944124] MCE: In-kernel MCE decoding enabled. [ 15.945779] EDAC MC: Ver: 2.1.0 [ 15.947575] lp: driver loaded but no devices found [ 15.951215] AMD64 EDAC driver v3.4.0 [ 15.952459] Bridge firewalling registered [ 15.953066] type=3D1400 audit(1335964577.273:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D825 comm=3D"appar= mor_parser" [ 15.953754] type=3D1400 audit(1335964577.273:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D825 comm=3D"apparmor_parser" [ 15.953834] EDAC amd64: DRAM ECC enabled. [ 15.953905] EDAC amd64: F10h detected (node 0). [ 15.953981] EDAC MC: DCT0 chip selects: [ 15.953986] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.953989] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.953992] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.953995] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.953997] EDAC MC: DCT1 chip selects: [ 15.954000] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.954003] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.954006] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.954009] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.954012] EDAC amd64: using x8 syndromes. [ 15.954014] EDAC amd64: MCT channel count: 2 [ 15.954064] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.954068] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.954073] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.954077] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.954164] type=3D1400 audit(1335964577.273:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D825 comm=3D"apparmor_parser" [ 15.954191] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.957544] ipmi message handler version 39.2 [ 15.958325] ipmi device interface [ 15.961741] EDAC amd64: DRAM ECC enabled. [ 15.961751] EDAC amd64: F10h detected (node 1). [ 15.961831] EDAC MC: DCT0 chip selects: [ 15.961835] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.961838] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.961841] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.961844] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.961847] EDAC MC: DCT1 chip selects: [ 15.961850] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.961853] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.961856] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.961859] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.961862] EDAC amd64: using x8 syndromes. [ 15.961865] EDAC amd64: MCT channel count: 2 [ 15.961904] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.961908] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.961911] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.961914] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.961988] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.962103] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.963866] IPMI System Interface driver. [ 15.963946] ipmi_si: probing via SMBIOS [ 15.963950] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.963954] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.963965] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.964506] device-mapper: multipath: version 1.3.0 loaded [ 15.981254] device eth0 entered promiscuous mode [ 16.036101] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 16.043255] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 16.043367] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.085117] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 16.177926] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.179422] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.187558] ADDRCONF(NETDEV_UP): br0: link is not ready [ 17.107889] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.362235] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.157089] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.159695] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.159833] br0: port 1(eth0) entering forwarding state [ 19.159851] br0: port 1(eth0) entering forwarding state [ 19.162058] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 19.505855] init: udev-fallback-graphics main process (1834) terminate= d with status 1 [ 19.658903] init: failsafe main process (1723) killed by TERM signal [ 19.770924] type=3D1400 audit(1335964581.089:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1932 comm=3D"apparmor_parser" [ 19.771034] type=3D1400 audit(1335964581.089:6): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1933 comm=3D"= apparmor_parser" [ 19.771113] type=3D1400 audit(1335964581.089:7): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1930 comm=3D"a= pparmor_parser" [ 19.771751] type=3D1400 audit(1335964581.089:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1930 comm=3D"apparmor_parser" [ 19.772152] type=3D1400 audit(1335964581.093:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1930 comm=3D"apparmor_parser" [ 19.772188] type=3D1400 audit(1335964581.093:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1934 c= omm=3D"apparmor_parser" [ 19.772544] type=3D1400 audit(1335964581.093:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1934 comm=3D"apparmor_parser" [ 20.049999] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 20.271564] ip_tables: (C) 2000-2006 Netfilter Core Team [ 20.373030] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 20.424289] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 20.654948] Event-channel device installed. [ 20.718822] XENBUS: Unable to read cpu state [ 20.719070] XENBUS: Unable to read cpu state [ 20.719271] XENBUS: Unable to read cpu state [ 20.719477] XENBUS: Unable to read cpu state [ 20.719666] XENBUS: Unable to read cpu state [ 20.719810] XENBUS: Unable to read cpu state [ 20.719955] XENBUS: Unable to read cpu state [ 20.720132] XENBUS: Unable to read cpu state [ 21.183395] Ebtables v2.0 registered [ 21.213618] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.236526] br0: no IPv6 routers present [ 245.817700]=20 [ 245.817701] **** Context Switch from TID 0 to TID 49125104 **** [ 245.817703]=20 [ 245.817707] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.817718] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.817727] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.817737] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.817746] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.817754] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.817763] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.817772] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.817781] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.817791] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.817801] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.817819] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.817827] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.817836] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.817845] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P001] (ffff880027d50e88) [ 245.817855] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.817863] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.817878] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.817887] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.817895] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50e88 [ 245.817904] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.817913] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P001 (ffff880027d50e88) For [_PSD] (Untyped) [ 245.817923] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.817931] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.817940] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d438 found in scope [P001] ffff880027d50e88= [ 245.817950] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.817958] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.817967] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.817975] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.817984] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.817993] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.818002] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.818010] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.818019] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d438 [ 245.818028] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d709d8 [ 245.818037] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d438] Value ffff880027d709d8 [ 245.818046] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.818054] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.818063] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.818072] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.818081] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.818090] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.818108] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.818116] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.818124] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d438 [ 245.818132] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d709d8 [ 245.818141] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.818149] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.818157] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d438 SourceDesc=3Dffff880027d709d8 [Package] [ 245.818167] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d709d8 [ 245.818175] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.818184] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d709d8 [ 245.818193] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d709d8 Current Refs=3D1 [To Be Incremented] [ 245.818202] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d709d8 [ 245.818211] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250c7f30 [ 245.818224] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.818233] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818241] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818249] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d709d8 Refs=3D2, [Incremented] [ 245.818258] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818266] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818274] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818282] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818290] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250c7f78 [ 245.818298] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.818307] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818315] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818322] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff880027d716c0 [ 245.818331] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.818339] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818347] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818354] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff880027d71a68 [ 245.818363] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.818371] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818379] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818386] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d0000 [ 245.818395] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.818403] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818411] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818419] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d0048 [ 245.818427] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.818435] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.818443] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.818451] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250c7f30 Refs=3D2, [Incremented] [ 245.818459] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818467] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.818475] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818483] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818491] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d0048 Refs=3D2, [Incremented] [ 245.818499] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818507] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.818515] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818523] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818531] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d0000 Refs=3D2, [Incremented] [ 245.818539] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818547] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.818555] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818563] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818571] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d71a68 Refs=3D2, [Incremented] [ 245.818580] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818587] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.818596] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818603] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818611] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d716c0 Refs=3D2, [Incremented] [ 245.818620] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.818628] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818636] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.818644] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.818651] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250c7f78 Refs=3D2, [Incremented] [ 245.818660] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.818668] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.818676] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.818684] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.818692] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.818701] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.818710] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.818718] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d709d8 [Package] [ 245.818728] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d438 [ 245.818736] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.818746] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P001._PSD Validating return Package of Type 5, Count 1 [ 245.818757] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.818766] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.818775] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d709d8 [ 245.818783] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.818791] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 245.818799] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.818808] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.818816] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.818823] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250c7f30 [ 245.818832] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.818840] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250c7f78 [ 245.818848] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818856] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff880027d716c0 [ 245.818864] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818872] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff880027d71a68 [ 245.818881] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818889] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d0000 [ 245.818897] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818905] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d0048 [ 245.818913] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.818921] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.818929] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.818936] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.818944] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.818952] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.818960] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.818968] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.818976] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.818984] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.818992] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.819001] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.819009] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.819017] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.819025] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 245.819033] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.819042] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.819050] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.819057] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250c7f30 [ 245.819066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.819074] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819082] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819090] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819098] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819106] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819113] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819122] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819129] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819137] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.819145] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.819153] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.819161] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.819169] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.819176] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819185] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.819192] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.819200] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.819208] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.819216] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.819224] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.819232] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.819241] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.819249] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.819258] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.819267] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.819284] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.819292] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d709d8 [ 245.819300] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d709d8 Current Refs=3D2 [To Be Decremented] [ 245.819310] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d709d8 [ 245.819318] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250c7f30 [ 245.819326] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.819334] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819342] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819350] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d709d8 Refs=3D1, [Decremented] [ 245.819359] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819367] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819375] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819383] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819390] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250c7f78 [ 245.819399] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.819407] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819415] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819423] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff880027d716c0 [ 245.819431] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.819439] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819447] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819455] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff880027d71a68 [ 245.819463] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.819471] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819479] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819487] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d0000 [ 245.819495] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.819503] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819511] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819519] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d0048 [ 245.819527] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.819535] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.819543] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.819551] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250c7f30 Refs=3D1, [Decremented] [ 245.819559] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819567] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.819575] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819583] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819591] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d0048 Refs=3D1, [Decremented] [ 245.819599] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819607] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.819615] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819623] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819631] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d0000 Refs=3D1, [Decremented] [ 245.819640] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819647] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.819656] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819663] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819671] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d71a68 Refs=3D1, [Decremented] [ 245.819680] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819687] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.819696] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819703] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819711] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d716c0 Refs=3D1, [Decremented] [ 245.819720] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.819728] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.819736] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.819744] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.819751] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250c7f78 Refs=3D1, [Decremented] [ 245.819760] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.819768] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.819776] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.819784] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.819793] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.819802] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.819810] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.819820] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.819828] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.819836] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.819844] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.819852] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.819860] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.819868] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.819876] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.819884] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.819894] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.819903] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.819920] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.819927] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.819935] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.819944] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P002] (ffff880027d50eb0) [ 245.819953] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.819961] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.819975] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.819983] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.819991] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50eb0 [ 245.819999] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.820007] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P002 (ffff880027d50eb0) For [_PSD] (Untyped) [ 245.820017] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.820025] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.820033] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d500 found in scope [P002] ffff880027d50eb0= [ 245.820043] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.820072] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.820081] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.820089] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.820098] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.820111] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.820129] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.820148] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.820167] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d500 [ 245.820189] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70b40 [ 245.820211] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d500] Value ffff880027d70b40 [ 245.820232] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.820249] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.820265] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.820283] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.820306] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.820326] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.820361] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.820381] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.820400] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d500 [ 245.820419] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70b40 [ 245.820436] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.820455] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.820472] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d500 SourceDesc=3Dffff880027d70b40 [Package] [ 245.820492] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70b40 [ 245.820508] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.820525] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70b40 [ 245.820543] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70b40 Current Refs=3D1 [To Be Incremented] [ 245.820562] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70b40 [ 245.820582] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1d38 [ 245.820598] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.820619] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820637] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820651] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70b40 Refs=3D2, [Incremented] [ 245.820671] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.820693] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.820710] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.820730] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.820751] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1d80 [ 245.820769] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.820785] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820807] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820824] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1dc8 [ 245.820841] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.820861] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820878] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820896] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1e10 [ 245.820911] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.820928] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.820943] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.820960] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1e58 [ 245.820981] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.820997] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.821019] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.821036] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d1ea0 [ 245.821056] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.821075] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.821094] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.821112] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1d38 Refs=3D2, [Incremented] [ 245.821125] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821133] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.821141] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821149] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821161] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1ea0 Refs=3D2, [Incremented] [ 245.821169] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821177] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.821186] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821194] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821202] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1e58 Refs=3D2, [Incremented] [ 245.821211] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821219] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.821227] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821236] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821243] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1e10 Refs=3D2, [Incremented] [ 245.821252] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821260] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.821269] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821277] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821285] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1dc8 Refs=3D2, [Incremented] [ 245.821294] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.821302] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.821310] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.821318] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.821326] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d1d80 Refs=3D2, [Incremented] [ 245.821335] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.821344] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.821352] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.821363] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.821379] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.821399] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.821417] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.821436] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70b40 [Package] [ 245.821456] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d500 [ 245.821476] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.821498] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P002._PSD Validating return Package of Type 5, Count 1 [ 245.821519] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.821539] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.821556] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70b40 [ 245.821575] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.821593] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 245.821611] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.821630] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.821647] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.821667] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d1d38 [ 245.821686] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.821705] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1d80 [ 245.821725] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821745] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1dc8 [ 245.821763] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821780] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1e10 [ 245.821798] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821815] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1e58 [ 245.821832] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821851] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d1ea0 [ 245.821867] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.821883] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.821898] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.821916] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.821938] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.821957] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.821974] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.821991] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.822011] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.822030] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.822047] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.822067] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.822085] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.822104] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.822120] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 245.822138] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.822153] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.822173] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.822190] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d1d38 [ 245.822209] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.822228] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822247] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822264] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822282] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822297] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822312] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822331] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822349] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822368] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.822382] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.822391] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.822399] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.822407] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.822415] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.822423] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.822432] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.822440] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.822448] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.822456] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.822465] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.822473] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.822482] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.822490] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.822499] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.822509] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.822526] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.822539] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70b40 [ 245.822560] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70b40 Current Refs=3D2 [To Be Decremented] [ 245.822579] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70b40 [ 245.822598] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1d38 [ 245.822615] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.822633] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822647] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822666] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70b40 Refs=3D1, [Decremented] [ 245.822686] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.822704] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.822725] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.822743] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.822762] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1d80 [ 245.822782] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.822799] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822820] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822840] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1dc8 [ 245.822856] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.822874] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822892] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822911] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1e10 [ 245.822927] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.822943] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.822960] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.822978] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1e58 [ 245.822996] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.823014] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.823029] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.823046] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d1ea0 [ 245.823065] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.823085] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.823106] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.823124] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1d38 Refs=3D1, [Decremented] [ 245.823144] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823161] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.823178] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823195] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823215] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1ea0 Refs=3D1, [Decremented] [ 245.823233] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823253] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.823270] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823285] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823302] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1e58 Refs=3D1, [Decremented] [ 245.823321] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823341] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.823359] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823379] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823397] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1e10 Refs=3D1, [Decremented] [ 245.823418] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823437] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.823455] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823470] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823487] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1dc8 Refs=3D1, [Decremented] [ 245.823509] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.823531] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.823549] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.823567] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.823575] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d1d80 Refs=3D1, [Decremented] [ 245.823585] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.823593] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.823601] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.823609] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.823619] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.823628] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.823636] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.823645] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.823653] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.823662] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.823672] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.823680] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.823688] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.823697] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.823705] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.823713] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.823723] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.823732] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.823764] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.823786] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.823806] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.823825] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P003] (ffff880027d50ed8) [ 245.823846] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.823866] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.823904] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.823918] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.823935] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50ed8 [ 245.823953] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.823973] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P003 (ffff880027d50ed8) For [_PSD] (Untyped) [ 245.823992] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824011] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824027] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d5c8 found in scope [P003] ffff880027d50ed8= [ 245.824047] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d5c8 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70ca8 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d5c8] Value ffff880027d70ca8 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d5c8 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70ca8 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d5c8 SourceDesc=3Dffff880027d70ca8 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70ca8 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70ca8 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70ca8 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70ca8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d4d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70ca8 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d5c8 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P003._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70ca8 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70ca8 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70ca8 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70ca8 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70ca8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P004] (ffff880027d50f00) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f00 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P004 (ffff880027d50f00) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d690 found in scope [P004] ffff880027d50f00= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d690 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70e10 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d690] Value ffff880027d70e10 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d690 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70e10 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d690 SourceDesc=3Dffff880027d70e10 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70e10 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70e10 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70e10 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70e10 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d6d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70e10 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d690 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P004._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70e10 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70e10 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70e10 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70e10 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P005] (ffff880027d50f28) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f28 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P005 (ffff880027d50f28) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d758 found in scope [P005] ffff880027d50f28= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d758 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70f78 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d758] Value ffff880027d70f78 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d758 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d70f78 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d758 SourceDesc=3Dffff880027d70f78 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d70f78 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d70f78 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d70f78 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d70f78 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d70f78 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d8ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d8d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d70f78 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d758 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P005._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70f78 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d8ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d70f78 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d70f78 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70f78 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d70f78 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d8ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d8d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P006] (ffff880027d50f50) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f50 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P006 (ffff880027d50f50) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d820 found in scope [P006] ffff880027d50f50= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d820 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d710d8 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d820] Value ffff880027d710d8 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d820 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d710d8 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d820 SourceDesc=3Dffff880027d710d8 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d710d8 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d710d8 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d710d8 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d710d8 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d710d8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9d38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9ea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9e58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9e10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9dc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250d9d80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d710d8 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d820 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P006._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d710d8 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9d80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9dc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9ea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d710d8 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d710d8 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d710d8 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d710d8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9ea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9dc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK [ 245.824066] nsxfeval-0181 [49125104] [4294967293] evaluate_object = : ----Entry [ 245.824066] nseval-0090 [49125104] [4294967294] ns_evaluate = : ----Entry [ 245.824066] nsutils-0707 [49125104] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 245.824066] nsutils-0391 [49125104] [00] ns_internalize_name : ----= Entry [ 245.824066] nsutils-0280 [49125104] [01] ns_build_internal_name: ----= Entry [ 245.824066] nsutils-0363 [49125104] [01] ns_build_internal_name: Retu= rning [ffff880002e0dfc0] (rel) "_PSD" [ 245.824066] nsutils-0366 [49125104] [01] ns_build_internal_name: ----= Exit- AE_OK [ 245.824066] nsutils-0419 [49125104] [00] ns_internalize_name : ----= Exit- AE_OK [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Namespace] [ 245.824066] nsaccess-0301 [49125104] [00] ns_lookup : ----= Entry [ 245.824066] nsutils-0663 [49125104] [01] ns_opens_scope : ----= Entry Processor [ 245.824066] nsutils-0673 [49125104] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 245.824066] nsaccess-0398 [49125104] [00] ns_lookup : Sear= ching relative to prefix scope [P007] (ffff880027d50f78) [ 245.824066] nsaccess-0510 [49125104] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 245.824066] nsdump-0087 [49125104] [00] ns_print_pathname : [_PS= D] [ 245.824066] nssearch-0297 [49125104] [01] ns_search_and_enter : ----= Entry [ 245.824066] nssearch-0102 [49125104] [02] ns_search_one_scope : ----= Entry [ 245.824066] nsnames-0139 [49125104] [03] ns_get_external_pathna: ----= Entry ffff880027d50f78 [ 245.824066] nsnames-0164 [49125104] [03] ns_get_external_pathna: ----= Exit- ffff880002e4eae0 [ 245.824066] nssearch-0114 [49125104] [02] ns_search_one_scope : Sear= ching \_PR_.P007 (ffff880027d50f78) For [_PSD] (Untyped) [ 245.824066] nsutils-0150 [49125104] [03] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [03] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] nssearch-0149 [49125104] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d8e8 found in scope [P007] ffff880027d50f78= [ 245.824066] nssearch-0152 [49125104] [02] ns_search_one_scope : ----= Exit- AE_OK [ 245.824066] nssearch-0349 [49125104] [01] ns_search_and_enter : ----= Exit- AE_OK [ 245.824066] nsaccess-0670 [49125104] [00] ns_lookup : ----= Exit- AE_OK [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Namespace] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 245.824066] nsutils-0750 [49125104] [4294967295] ns_get_node = : ----Exit- AE_OK [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] nsobject-0266 [49125104] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d8e8 [ 245.824066] nsobject-0281 [49125104] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d71288 [ 245.824066] nseval-0127 [49125104] [4294967294] ns_evaluate = : _PSD [ffff880027d6d8e8] Value ffff880027d71288 [ 245.824066] nsutils-0150 [49125104] [4294967295] ns_get_type = : ----Entry [ 245.824066] nsutils-0157 [49125104] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 245.824066] exutils-0091 [49125104] [4294967295] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967295] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967295] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967295] ex_enter_interpreter= : ----Exit- [ 245.824066] exresnte-0089 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 245.824066] nsobject-0266 [49125104] [00] ns_get_attached_object: ----= Entry ffff880027d6d8e8 [ 245.824066] nsobject-0281 [49125104] [00] ns_get_attached_object: ----= Exit- ffff880027d71288 [ 245.824066] nsutils-0150 [49125104] [00] ns_get_type : ----= Entry [ 245.824066] nsutils-0157 [49125104] [00] ns_get_type : ----= Exit- 0000000000000004 [ 245.824066] exresnte-0101 [49125104] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d8e8 SourceDesc=3Dffff880027d71288 [Package] [ 245.824066] dsargs-0318 [49125104] [00] ds_get_package_argumen: ----= Entry ffff880027d71288 [ 245.824066] dsargs-0321 [49125104] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 245.824066] utdelete-0642 [49125104] [00] ut_add_reference : ----= Entry ffff880027d71288 [ 245.824066] utdelete-0652 [49125104] [00] ut_add_reference : Obj = ffff880027d71288 Current Refs=3D1 [To Be Incremented] [ 245.824066] utdelete-0483 [49125104] [01] ut_update_object_refer: ----= Entry ffff880027d71288 [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff880027d71288 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbd80 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbdc8 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbe10 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbe58 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [02] ut_create_update_state: ----= Entry ffff8800250dbea0 [ 245.824066] utstate-0248 [49125104] [02] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [02] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [02] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbd38 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbea0 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbe58 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbe10 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbdc8 Refs=3D2, [Incremented] [ 245.824066] utstate-0127 [49125104] [02] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [02] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [02] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [02] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0393 [49125104] [01] ut_update_ref_count : Obj = ffff8800250dbd80 Refs=3D2, [Incremented] [ 245.824066] utdelete-0609 [49125104] [01] ut_update_object_refer: ----= Exit- AE_OK [ 245.824066] utdelete-0657 [49125104] [00] ut_add_reference : ----= Exit- [ 245.824066] exresnte-0277 [49125104] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 245.824066] exutils-0151 [49125104] [4294967295] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967295] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967295] ex_exit_interpreter = : ----Exit- [ 245.824066] nseval-0247 [49125104] [4294967294] ns_evaluate = : Returning object ffff880027d71288 [Package] [ 245.824066] nsnames-0139 [49125104] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d8e8 [ 245.824066] nsnames-0164 [49125104] [4294967295] ns_get_external_path= na: ----Exit- ffff880002e4eae0 [ 245.824066] nspredef-0445 [49125104] [4294967294] ns_check_package = : \_PR_.P007._PSD Validating return Package of Type 5, Count 1 [ 245.824066] nseval-0277 [49125104] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 245.824066] nseval-0283 [49125104] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 245.824066] utobject-0645 [49125104] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d71288 [ 245.824066] utmisc-0941 [49125104] [4294967295] ut_walk_package_tree= : ----Entry [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [00] ut_create_pkg_state : ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0287 [49125104] [00] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbd80 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbdc8 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbe10 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbe58 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utobject-0460 [49125104] [00] ut_get_simple_object_s: ----= Entry ffff8800250dbea0 [ 245.824066] utobject-0562 [49125104] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 245.824066] utobject-0668 [49125104] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 245.824066] utcopy-0400 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 245.824066] utcopy-0342 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 245.824066] utmisc-0941 [49125104] [00] ut_walk_package_tree : ----= Entry [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [01] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [01] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0270 [49125104] [01] ut_create_pkg_state : ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0287 [49125104] [01] ut_create_pkg_state : ----= Exit- ffff880002906050 [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utcopy-0118 [49125104] [01] ut_copy_isimple_to_esi: ----= Entry [ 245.824066] utcopy-0231 [49125104] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [01] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [01] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0127 [49125104] [01] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [01] ut_pop_generic_state : ----= Exit- (null) [ 245.824066] utmisc-0996 [49125104] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 245.824066] utcopy-0377 [49125104] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 245.824066] utcopy-0434 [49125104] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 245.824066] exutils-0091 [49125104] [4294967294] ex_enter_interpreter= : ----Entry [ 245.824066] utmutex-0261 [49125104] [4294967294] ut_acquire_mutex = : Thread 49125104 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-0981 [49125104] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 245.824066] osl-1000 [49125104] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [49125104] = [4294967294] ut_acquire_mutex : Thread 49125104 acquired Mutex [ACPI= _MTX_Interpreter] [ 245.824066] exutils-0099 [49125104] [4294967294] ex_enter_interpreter= : ----Exit- [ 245.824066] utdelete-0675 [49125104] [4294967294] ut_remove_reference = : ----Entry ffff880027d71288 [ 245.824066] utdelete-0695 [49125104] [4294967294] ut_remove_reference = : Obj ffff880027d71288 Current Refs=3D2 [To Be Decremented] [ 245.824066] utdelete-0483 [49125104] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d71288 [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbd38 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff880027d71288 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbd80 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906000 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbdc8 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906050 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbe10 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbe58 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utstate-0233 [49125104] [00] ut_create_update_state: ----= Entry ffff8800250dbea0 [ 245.824066] utstate-0248 [49125104] [00] ut_create_update_state: ----= Exit- ffff880002906140 [ 245.824066] utstate-0100 [49125104] [00] ut_push_generic_state : ----= Entry [ 245.824066] utstate-0107 [49125104] [00] ut_push_generic_state : ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbd38 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906140 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbea0 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060f0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbe58 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff8800029060a0 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbe10 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906050 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbdc8 Refs=3D1, [Decremented] [ 245.824066] utstate-0127 [49125104] [00] ut_pop_generic_state : ----= Entry [ 245.824066] utstate-0139 [49125104] [00] ut_pop_generic_state : ----= Exit- ffff880002906000 [ 245.824066] utstate-0339 [49125104] [00] ut_delete_generic_stat: ----= Entry [ 245.824066] utstate-0346 [49125104] [00] ut_delete_generic_stat: ----= Exit- [ 245.824066] utdelete-0409 [49125104] [4294967295] ut_update_ref_count = : Obj ffff8800250dbd80 Refs=3D1, [Decremented] [ 245.824066] utdelete-0609 [49125104] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 245.824066] utdelete-0703 [49125104] [4294967294] ut_remove_reference = : ----Exit- [ 245.824066] exutils-0151 [49125104] [4294967294] ex_exit_interpreter = : ----Entry [ 245.824066] utmutex-0304 [49125104] [4294967294] ut_release_mutex = : Thread 49125104 releasing Mutex [ACPI_MTX_Interpreter] [ 245.824066] osl-1020 [49125104] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 245.824066] exutils-0159 [49125104] [4294967294] ex_exit_interpreter = : ----Exit- [ 245.824066] nsxfeval-0358 [49125104] [4294967293] evaluate_object = : ----Exit- AE_OK --------------060902080104000706080807-- --------------enig8743CEE041A746E466A979FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoUs4AAoJEOhnXe7L7s6jmCEP/3UXK4/2N1k6JhAQydGpfVUk vIoOZEWxahe9ovF5WVQcp1wpz+syaqt6i7SVh/+BjzspHcjBEka3iOith1A0sd9E N7BJFyyyVTa7VJiGsKc1eIDzEcpnbujEpapSPRDjnkU1v9ggn9z5JV+KjalXDx4j felEcDb5nHnNXJqt0uToYOlGwQ301nMOtTCMSEz2oPkiCH3KnWo2McRAdt6ppdRX 52jElzJgDMOOFYg/ZWJHfI0EyLhNJZOf1u9/VYuyd8ZEk70QUNj1a6LkxFpxw3hc NxYPG2ElCxWSqT0P1pFFU2msgdvyoYTMTDMImFF61JCT/vY/ZXxtvyfNpd1c8pUZ JAn0vbVn7bO2IsOahwUnsxFXPiYdwG9vbjnYtHw5hGYwZpxLHfLNTZolPlhyNeV+ 8duSBLlcA/RDSEWTv1XxGQ4e5ZQKWF8c7sBkRacTfjgF+QhE9WA2lMfOkPkNzwO5 oaEPjuKfyyelNzi+I3vSC5+UGfQ3jeAVWPRuATysIsg2m4m7/gYseXg0ahcoifV2 E75IHAD5lWp9gAnxDB+2aClqrnhNLRj0jMt/BHO4mzcRbQJnIgYMZJwO2Siph5Mv 6z1b5sxioRUu8G/Nf2O8xTy/Fo4FHnzxBRz9go2nSOhgFZ2LQwUxT6LrJt4JnDtz 58hs1bzZaDKj63NLFdOn =fxD4 -----END PGP SIGNATURE----- --------------enig8743CEE041A746E466A979FC-- --===============8154349337432514550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8154349337432514550==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb3Y-0007lD-5z; Wed, 02 May 2012 15:01:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb3V-0007l3-NW for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:01:26 +0000 Received: from [193.109.254.147:32130] by server-8.bemta-14.messagelabs.com id A5/C2-23244-54C41AF4; Wed, 02 May 2012 15:01:25 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335970864!7276618!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14845 invoked from network); 2 May 2012 15:01:05 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-2.tower-27.messagelabs.com with SMTP; 2 May 2012 15:01:05 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPb38-0003xy-Qh; Wed, 02 May 2012 15:01:03 +0000 Message-ID: <4FA14C2C.5030104@canonical.com> Date: Wed, 02 May 2012 17:01:00 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> In-Reply-To: <4FA06541.7050607@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6456103616454136699==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6456103616454136699== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig72814478D7B52B9E326357CB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72814478D7B52B9E326357CB Content-Type: multipart/mixed; boundary="------------020809070207090105090201" This is a multi-part message in MIME format. --------------020809070207090105090201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:35, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>> Since there have been requests about that driver to get backported = into 3.2, I >>>>> was interested to find out what or how much would be gained by that= =2E >>>>> >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@= 2GHz). >>>>> Which >>>>> was not very successful as the drivers bail out of the init functio= n >>>>> because the >>>>> first call to acpi_processor_register_performance() returns -ENODEV= =2E There is >>>>> some frequency scaling when running without Xen, so I need to do so= me more >>>>> debugging there. >=20 > I believe this is caused by the somewhat under-enlightened xen_apic_rea= d(): >=20 > static u32 xen_apic_read(u32 reg) > { > return 0; > } >=20 > This results in some data, most importantly boot_cpu_physical_apicid, n= ot being > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. >=20 > On larger AMD systems boot processor is typically APICID=3D0x20 (I don'= t have > Intel system handy to see how it looks there). >=20 > As a quick and dirty test you can try: >=20 > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long = address) > } > if (boot_cpu_physical_apicid =3D=3D -1U) { > boot_cpu_physical_apicid =3D read_apic_id(); > + boot_cpu_physical_apicid =3D 32; > apic_version[boot_cpu_physical_apicid] =3D > GET_APIC_VERSION(apic_read(APIC_LVR)); > } >=20 >=20 > (Set it to whatever APICID on core0 is, I suspect it won't be zero). >=20 Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most of t= he BIOS bug messages are gone and the xen-acpi-processor driver successfully load= s and seems to be switching frequencies ok (just a quick tight loop which made = one cpu go from P4 to P0). -Stefan --------------020809070207090105090201 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.3" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.3" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg2 SMP Wed May 2 13:46:26= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg2-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x10, fixing up to 0= x10 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.194 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.38 BogoMIPS (lpj=3D8000776) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008042] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.017234] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019934] Mount-cache hash table entries: 256 [ 0.020139] Initializing cgroup subsys cpuacct [ 0.020151] Initializing cgroup subsys memory [ 0.020169] Initializing cgroup subsys devices [ 0.020175] Initializing cgroup subsys freezer [ 0.020181] Initializing cgroup subsys blkio [ 0.020197] Initializing cgroup subsys perf_event [ 0.020269] tseg: 00dff00000 [ 0.020276] CPU: Physical Processor ID: 0 [ 0.020281] CPU: Processor Core ID: 0 [ 0.023239] ACPI: Core revision 20110623 [ 0.039296] ftrace: allocating 27102 entries in 107 pages [ 0.040130] cpu 0 spinlock event irq 273 [ 0.040230] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040496] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040627] installing Xen timer for CPU 1 [ 0.040646] cpu 1 spinlock event irq 279 [ 0.040849] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040971] installing Xen timer for CPU 2 [ 0.040989] cpu 2 spinlock event irq 285 [ 0.041147] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041260] installing Xen timer for CPU 3 [ 0.041275] cpu 3 spinlock event irq 291 [ 0.041438] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041555] installing Xen timer for CPU 4 [ 0.041570] cpu 4 spinlock event irq 297 [ 0.041750] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041875] installing Xen timer for CPU 5 [ 0.041891] cpu 5 spinlock event irq 303 [ 0.042052] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042166] installing Xen timer for CPU 6 [ 0.042183] cpu 6 spinlock event irq 309 [ 0.042338] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042455] installing Xen timer for CPU 7 [ 0.042470] cpu 7 spinlock event irq 315 [ 0.042631] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042664] Brought up 8 CPUs [ 0.042893] devtmpfs: initialized [ 0.045288] EVM: security.selinux [ 0.045292] EVM: security.SMACK64 [ 0.045296] EVM: security.capability [ 0.045372] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045372] Grant table initialized [ 0.045372] print_constraints: dummy:=20 [ 0.045372] RTC time: 14:45:52, date: 05/02/12 [ 0.045372] NET: Registered protocol family 16 [ 0.045372] Trying to unpack rootfs image as initramfs... [ 0.060269] node 0 link 0: io port [1000, ffffff] [ 0.060283] TOM: 00000000e0000000 aka 3584M [ 0.060290] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060301] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060309] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060317] node 0 link 0: mmio [a0000, bffff] [ 0.060325] TOM2: 0000000820000000 aka 33280M [ 0.060330] bus: [00, 1f] on node 0 link 0 [ 0.060335] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060340] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060345] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060350] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060374] Extended Config Space enabled on 2 nodes [ 0.060542] ACPI: bus type pci registered [ 0.060651] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060660] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.180907] Freeing initrd memory: 40072k freed [ 0.219808] PCI: Using configuration type 1 for base access [ 0.221344] bio: create slab at 0 [ 0.221344] ACPI: Added _OSI(Module Device) [ 0.221344] ACPI: Added _OSI(Processor Device) [ 0.221344] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221344] ACPI: Added _OSI(Processor Aggregator Device) [ 0.225715] ACPI: EC: Look up EC in DSDT [ 0.230192] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253658] ACPI: Interpreter enabled [ 0.253667] ACPI: (supports S0 S1 S4 S5) [ 0.253712] ACPI: Using IOAPIC for interrupt routing [ 0.267237] ACPI: No dock devices found. [ 0.267301] HEST: Table parsing has been initialized. [ 0.267309] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267617] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268211] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268218] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268224] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268230] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268237] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268279] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268473] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268677] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268795] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268804] pci 0000:00:09.0: PME# disabled [ 0.268845] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268962] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.268970] pci 0000:00:0a.0: PME# disabled [ 0.269065] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269102] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269125] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269145] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269165] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269185] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269205] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269314] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269341] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269465] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269492] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269625] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269663] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269821] pci 0000:00:12.2: supports D1 D2 [ 0.269826] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269836] pci 0000:00:12.2: PME# disabled [ 0.269875] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269902] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270026] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270053] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270190] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270228] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270418] pci 0000:00:13.2: supports D1 D2 [ 0.270423] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270432] pci 0000:00:13.2: PME# disabled [ 0.270477] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270668] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270812] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270893] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270921] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271063] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271193] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271254] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271322] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271412] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271526] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271644] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271707] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271806] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271900] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280069] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280079] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280203] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280237] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280282] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280307] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280487] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280499] pci 0000:02:00.0: PME# disabled [ 0.288054] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288143] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288182] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288205] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288228] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288436] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288451] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288461] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288467] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288473] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288480] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288487] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288493] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288541] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288954] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289027] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289138] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289344] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289352] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289358] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307234] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307382] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307517] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307650] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.307782] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.307924] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308030] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308163] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308239] xen/balloon: Initialising balloon driver. [ 0.351878] xen-balloon: Initialising balloon driver. [ 0.351910] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352081] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352089] vgaarb: loaded [ 0.352092] vgaarb: bridge control possible 0000:01:04.0 [ 0.352233] i2c-core: driver [aat2870] using legacy suspend method [ 0.352239] i2c-core: driver [aat2870] using legacy resume method [ 0.352360] SCSI subsystem initialized [ 0.352432] libata version 3.00 loaded. [ 0.352432] usbcore: registered new interface driver usbfs [ 0.352432] usbcore: registered new interface driver hub [ 0.352432] usbcore: registered new device driver usb [ 0.352432] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356114] NetLabel: Initializing [ 0.356119] NetLabel: domain hash size =3D 128 [ 0.356123] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356140] NetLabel: unlabeled traffic allowed by default [ 0.356221] Switching to clocksource xen [ 0.365468] AppArmor: AppArmor Filesystem Enabled [ 0.365506] pnp: PnP ACPI init [ 0.365528] ACPI: bus type pnp registered [ 0.365887] pnp 00:00: [bus 00-ff] [ 0.365893] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365898] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365903] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365908] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365913] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365919] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365924] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366046] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366320] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366327] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366410] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366622] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366683] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366690] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367338] pnp 00:03: [dma 4] [ 0.367343] pnp 00:03: [io 0x0000-0x000f] [ 0.367347] pnp 00:03: [io 0x0081-0x0083] [ 0.367352] pnp 00:03: [io 0x0087] [ 0.367356] pnp 00:03: [io 0x0089-0x008b] [ 0.367361] pnp 00:03: [io 0x008f] [ 0.367365] pnp 00:03: [io 0x00c0-0x00df] [ 0.367422] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367449] pnp 00:04: [io 0x0070-0x0071] [ 0.367457] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367466] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367471] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367490] pnp 00:04: [irq 8] [ 0.367547] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367616] pnp 00:05: [io 0x0060] [ 0.367621] pnp 00:05: [io 0x0064] [ 0.367625] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367631] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367636] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367652] pnp 00:05: [irq 1] [ 0.367708] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367822] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367829] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367833] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367847] pnp 00:06: [irq 12] [ 0.367907] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367928] pnp 00:07: [io 0x0061] [ 0.368018] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368039] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368044] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368051] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368056] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368081] pnp 00:08: [irq 13] [ 0.368137] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368338] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368344] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368350] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368433] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368440] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368533] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368595] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368897] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368902] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.368985] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.368992] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.368999] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369529] pnp 00:0c: [io 0x0010-0x001f] [ 0.369534] pnp 00:0c: [io 0x0022-0x003f] [ 0.369539] pnp 00:0c: [io 0x0062-0x0063] [ 0.369543] pnp 00:0c: [io 0x0065-0x006f] [ 0.369548] pnp 00:0c: [io 0x0072-0x007f] [ 0.369552] pnp 00:0c: [io 0x0080] [ 0.369556] pnp 00:0c: [io 0x0084-0x0086] [ 0.369561] pnp 00:0c: [io 0x0088] [ 0.369565] pnp 00:0c: [io 0x008c-0x008e] [ 0.369569] pnp 00:0c: [io 0x0090-0x009f] [ 0.369574] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369578] pnp 00:0c: [io 0x00b1] [ 0.369582] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369587] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369591] pnp 00:0c: [io 0x0550-0x0551] [ 0.369596] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369600] pnp 00:0c: [io 0x040b] [ 0.369604] pnp 00:0c: [io 0x04d6] [ 0.369608] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369613] pnp 00:0c: [io 0x0c14] [ 0.369617] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369621] pnp 00:0c: [io 0x0c52] [ 0.369626] pnp 00:0c: [io 0x0c6c] [ 0.369630] pnp 00:0c: [io 0x0c6f] [ 0.369634] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369638] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369643] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369647] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369652] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369656] pnp 00:0c: [io 0x0800-0x089f] [ 0.369661] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369666] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369670] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369675] pnp 00:0c: [io 0x0900-0x090f] [ 0.369679] pnp 00:0c: [io 0x0910-0x091f] [ 0.369684] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369688] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369693] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369698] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369706] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369818] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369824] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369830] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369836] system 00:0c: [io 0x040b] has been reserved [ 0.369842] system 00:0c: [io 0x04d6] has been reserved [ 0.369847] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369853] system 00:0c: [io 0x0c14] has been reserved [ 0.369858] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369864] system 00:0c: [io 0x0c52] has been reserved [ 0.369870] system 00:0c: [io 0x0c6c] has been reserved [ 0.369875] system 00:0c: [io 0x0c6f] has been reserved [ 0.369881] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369887] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369893] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369898] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369904] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369913] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369919] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369925] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369931] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369937] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369943] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369950] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369956] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369963] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370520] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370526] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370531] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370536] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370552] pnp 00:0d: [irq 4] [ 0.370557] pnp 00:0d: [dma 0 disabled] [ 0.370681] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371255] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371260] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371266] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371270] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371275] Already setup the GSI :3 [ 0.371279] pnp 00:0e: [irq 3] [ 0.371284] pnp 00:0e: [dma 0 disabled] [ 0.371404] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371547] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371630] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371637] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372610] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372615] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372620] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372625] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372635] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372734] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372741] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372747] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372753] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372760] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372767] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373080] pnp: PnP ACPI: found 17 devices [ 0.373085] ACPI: ACPI bus type pnp unregistered [ 0.380388] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380414] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380485] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380492] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380502] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380516] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380523] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380533] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380547] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380558] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380568] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380592] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380611] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380626] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380636] pci 0000:00:09.0: setting latency timer to 64 [ 0.380648] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380658] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380670] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380679] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380695] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380700] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380706] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380711] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380717] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380723] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380728] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380734] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380740] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380746] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380752] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380759] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380764] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380770] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380776] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380782] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380840] NET: Registered protocol family 2 [ 0.382874] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388164] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391394] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391772] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391779] TCP reno registered [ 0.391903] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392172] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392420] NET: Registered protocol family 1 [ 0.392475] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392498] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392519] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120175] pci 0000:00:12.0: PCI INT A disabled [ 1.120207] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120221] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120227] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120232] Already setup the GSI :16 [ 1.120238] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204177] pci 0000:00:12.1: PCI INT A disabled [ 1.204211] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204224] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204230] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204235] Already setup the GSI :17 [ 1.204241] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204378] pci 0000:00:12.2: PCI INT B disabled [ 1.204393] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204399] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204404] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204408] Already setup the GSI :18 [ 1.204413] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288202] pci 0000:00:13.0: PCI INT A disabled [ 1.288233] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288246] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288251] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288256] Already setup the GSI :18 [ 1.288262] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372182] pci 0000:00:13.1: PCI INT A disabled [ 1.372216] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372243] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372262] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372397] pci 0000:00:13.2: PCI INT B disabled [ 1.372424] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372430] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372434] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372439] Already setup the GSI :18 [ 1.372444] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456175] pci 0000:00:14.5: PCI INT C disabled [ 1.456261] pci 0000:01:04.0: Boot video device [ 1.456269] PCI: CLS 64 bytes, default 64 [ 1.457352] audit: initializing netlink socket (disabled) [ 1.457372] type=3D2000 audit(1335969953.923:1): initialized [ 1.485603] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487841] VFS: Disk quotas dquot_6.5.2 [ 1.487923] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488634] fuse init (API version 7.17) [ 1.488808] msgmni has been set to 1479 [ 1.489519] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489578] io scheduler noop registered [ 1.489583] io scheduler deadline registered [ 1.489627] io scheduler cfq registered (default) [ 1.490108] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490142] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490330] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490341] ACPI: Power Button [PWRB] [ 1.490401] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490409] ACPI: Power Button [PWRF] [ 1.716979] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.717094] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.717274] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.717857] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.721834] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.746263] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.852428] hpet_acpi_add: no address or irqs in _CRS [ 1.852449] Linux agpgart interface v0.103 [ 1.856352] brd: module loaded [ 1.857407] loop: module loaded [ 1.857802] ahci 0000:00:11.0: version 3.0 [ 1.857824] xen: registering gsi 22 triggering 0 polarity 1 [ 1.857845] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.857864] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.858086] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.858095] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.859054] scsi0 : ahci [ 1.859169] scsi1 : ahci [ 1.859262] scsi2 : ahci [ 1.859362] scsi3 : ahci [ 1.859468] scsi4 : ahci [ 1.859560] scsi5 : ahci [ 1.860509] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.860517] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.860525] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.860532] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.860539] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.860546] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.861047] Fixed MDIO Bus: probed [ 1.861071] tun: Universal TUN/TAP device driver, 1.6 [ 1.861076] tun: (C) 1999-2004 Max Krasnyansky [ 1.861162] PPP generic driver version 2.4.2 [ 1.861314] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.861402] xen: registering gsi 17 triggering 0 polarity 1 [ 1.861411] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.861416] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.861420] Already setup the GSI :17 [ 1.861426] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.861460] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.861523] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.861540] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.861636] ehci_hcd 0000:00:12.2: debug port 1 [ 1.861720] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.872106] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.872298] hub 1-0:1.0: USB hub found [ 1.872307] hub 1-0:1.0: 6 ports detected [ 1.872556] xen: registering gsi 19 triggering 0 polarity 1 [ 1.872564] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.872569] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.872574] Already setup the GSI :19 [ 1.872579] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.872614] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.872700] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.872716] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.872808] ehci_hcd 0000:00:13.2: debug port 1 [ 1.872857] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.884099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.884311] hub 2-0:1.0: USB hub found [ 1.884319] hub 2-0:1.0: 6 ports detected [ 1.884438] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.884590] xen: registering gsi 16 triggering 0 polarity 1 [ 1.884598] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.884603] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.884608] Already setup the GSI :16 [ 1.884613] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.884648] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.884743] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.884809] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.944281] hub 3-0:1.0: USB hub found [ 1.944296] hub 3-0:1.0: 3 ports detected [ 1.944511] xen: registering gsi 16 triggering 0 polarity 1 [ 1.944519] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.944524] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.944528] Already setup the GSI :16 [ 1.944534] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.944569] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.944667] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.944707] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 2.004294] hub 4-0:1.0: USB hub found [ 2.004308] hub 4-0:1.0: 3 ports detected [ 2.004528] xen: registering gsi 18 triggering 0 polarity 1 [ 2.004535] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.004540] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.004545] Already setup the GSI :18 [ 2.004550] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.004585] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 2.004671] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 2.004738] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.064268] hub 5-0:1.0: USB hub found [ 2.064282] hub 5-0:1.0: 3 ports detected [ 2.064494] xen: registering gsi 18 triggering 0 polarity 1 [ 2.064502] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.064506] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.064511] Already setup the GSI :18 [ 2.064516] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.064551] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.064620] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.064659] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.124279] hub 6-0:1.0: USB hub found [ 2.124293] hub 6-0:1.0: 3 ports detected [ 2.124502] xen: registering gsi 18 triggering 0 polarity 1 [ 2.124509] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.124514] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.124519] Already setup the GSI :18 [ 2.124524] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.124559] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.124626] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.124666] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.184191] ata5: SATA link down (SStatus 0 SControl 300) [ 2.184261] hub 7-0:1.0: USB hub found [ 2.184272] hub 7-0:1.0: 2 ports detected [ 2.184358] uhci_hcd: USB Universal Host Controller Interface driver [ 2.184440] usbcore: registered new interface driver libusual [ 2.184498] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.187405] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.187418] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.187601] mousedev: PS/2 mouse device common for all mice [ 2.187775] rtc_cmos 00:04: RTC can wake from S4 [ 2.187934] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.187989] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.188106] device-mapper: uevent: version 1.0.3 [ 2.188194] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.188207] EFI Variables Facility v0.08 2004-May-17 [ 2.188532] TCP cubic registered [ 2.188663] NET: Registered protocol family 10 [ 2.189387] NET: Registered protocol family 17 [ 2.189411] Registering the dns_resolver key type [ 2.189546] PM: Hibernation image not present or could not be loaded. [ 2.189563] registered taskstats version 1 [ 2.196092] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.207113] Magic number: 12:861:787 [ 2.207307] rtc_cmos 00:04: setting system clock to 2012-05-02 14:45:5= 4 UTC (1335969954) [ 2.207436] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.207544] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.207549] EDD information not available. [ 2.220637] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.334785] Initializing USB Mass Storage driver... [ 2.335007] scsi6 : usb-storage 2-2:1.0 [ 2.335086] usbcore: registered new interface driver usb-storage [ 2.335092] USB Mass Storage support registered. [ 2.360141] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360175] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360201] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360225] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360250] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.360796] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.361200] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361208] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361277] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361285] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361334] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361340] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361354] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361360] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361505] ata6.00: configured for UDMA/100 [ 2.362391] ata4.00: configured for UDMA/133 [ 2.362421] ata2.00: configured for UDMA/133 [ 2.362599] ata1.00: configured for UDMA/133 [ 2.362749] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.362951] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363055] sd 0:0:0:0: [sda] Write Protect is off [ 2.363061] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.363118] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.363162] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363312] ata3.00: configured for UDMA/133 [ 2.363439] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.363609] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363669] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.363762] sd 1:0:0:0: [sdb] Write Protect is off [ 2.363769] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.363808] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363950] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.364143] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.364168] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.364238] sd 2:0:0:0: [sdc] Write Protect is off [ 2.364245] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.364291] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.364333] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.364513] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.364564] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.364735] sd 3:0:0:0: [sdd] Write Protect is off [ 2.364741] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.364780] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.365239] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.368276] sdb: sdb1 sdb2 [ 2.368691] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.368760] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.368768] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.368876] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.368945] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.376384] sdd: unknown partition table [ 2.376666] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.379373] sdc: unknown partition table [ 2.379649] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.483103] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.484090] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.484841] Freeing unused kernel memory: 920k freed [ 2.485162] Write protecting the kernel read-only data: 12288k [ 2.492276] Freeing unused kernel memory: 1520k freed [ 2.493426] Freeing unused kernel memory: 1140k freed [ 2.559332] udevd[165]: starting version 175 [ 2.620594] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.620604] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.623802] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.623832] xen: registering gsi 17 triggering 0 polarity 1 [ 2.623845] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.623850] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.623856] Already setup the GSI :17 [ 2.623862] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.623894] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.704179] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.737702] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.737713] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.737798] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.738025] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.738052] xen: registering gsi 18 triggering 0 polarity 1 [ 2.738096] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.738102] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.738107] Already setup the GSI :18 [ 2.738113] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.738145] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.853363] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.853372] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.853456] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.882463] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.882615] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.886373] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.886517] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.886542] usbcore: registered new interface driver usbhid [ 2.886547] usbhid: USB HID core driver [ 3.333153] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.333827] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.334481] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.335199] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.336131] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.336366] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.336599] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.336822] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.342133] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.346546] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.347264] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.348092] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 8.966388] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.562527] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.562539] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.593024] udevd[718]: starting version 175 [ 15.695773] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.717924] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.718899] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.719044] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.723681] lp: driver loaded but no devices found [ 15.734573] ipmi message handler version 39.2 [ 15.735953] ipmi device interface [ 15.739772] Bridge firewalling registered [ 15.741834] IPMI System Interface driver. [ 15.741948] ipmi_si: probing via SMBIOS [ 15.741953] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.741960] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.741973] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.751212] device-mapper: multipath: version 1.3.0 loaded [ 15.756221] device eth0 entered promiscuous mode [ 15.784153] type=3D1400 audit(1335969968.074:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D842 comm=3D"appar= mor_parser" [ 15.784732] type=3D1400 audit(1335969968.074:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D842 comm=3D"apparmor_parser" [ 15.785117] type=3D1400 audit(1335969968.074:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D842 comm=3D"apparmor_parser" [ 15.802699] MCE: In-kernel MCE decoding enabled. [ 15.804165] EDAC MC: Ver: 2.1.0 [ 15.807771] AMD64 EDAC driver v3.4.0 [ 15.808823] EDAC amd64: DRAM ECC enabled. [ 15.808852] EDAC amd64: F10h detected (node 0). [ 15.808916] EDAC MC: DCT0 chip selects: [ 15.808920] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.808924] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.808927] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.808930] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.808933] EDAC MC: DCT1 chip selects: [ 15.808939] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.808942] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.808948] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.808951] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.808954] EDAC amd64: using x8 syndromes. [ 15.808960] EDAC amd64: MCT channel count: 2 [ 15.809009] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.809012] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.809015] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.809018] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.809112] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.809275] EDAC amd64: DRAM ECC enabled. [ 15.809280] EDAC amd64: F10h detected (node 1). [ 15.809345] EDAC MC: DCT0 chip selects: [ 15.809349] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.809352] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.809355] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.809358] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.809360] EDAC MC: DCT1 chip selects: [ 15.809363] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.809366] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.809369] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.809372] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.809375] EDAC amd64: using x8 syndromes. [ 15.809377] EDAC amd64: MCT channel count: 2 [ 15.809404] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.809407] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.809413] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.809416] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.809583] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.809909] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.842927] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.855258] ADDRCONF(NETDEV_UP): br0: link is not ready [ 15.856181] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.898626] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.899311] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.032526] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.123208] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.868146] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.205624] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.069087] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.071434] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.071572] br0: port 1(eth0) entering forwarding state [ 19.071587] br0: port 1(eth0) entering forwarding state [ 19.073722] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 19.861816] init: udev-fallback-graphics main process (1853) terminate= d with status 1 [ 19.990334] init: failsafe main process (1730) killed by TERM signal [ 20.102020] type=3D1400 audit(1335969972.390:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1942 comm=3D"apparmor_parser" [ 20.102328] type=3D1400 audit(1335969972.390:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1940 comm=3D"a= pparmor_parser" [ 20.102359] type=3D1400 audit(1335969972.390:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1943 comm=3D"= apparmor_parser" [ 20.102975] type=3D1400 audit(1335969972.390:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1940 comm=3D"apparmor_parser" [ 20.103332] type=3D1400 audit(1335969972.390:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1940 comm=3D"apparmor_parser" [ 20.103432] type=3D1400 audit(1335969972.390:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1944 c= omm=3D"apparmor_parser" [ 20.103792] type=3D1400 audit(1335969972.390:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1944 comm=3D"apparmor_parser" [ 20.392238] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 20.626333] ip_tables: (C) 2000-2006 Netfilter Core Team [ 20.728136] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 20.779431] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 21.005464] Event-channel device installed. [ 21.069011] XENBUS: Unable to read cpu state [ 21.069219] XENBUS: Unable to read cpu state [ 21.069422] XENBUS: Unable to read cpu state [ 21.069607] XENBUS: Unable to read cpu state [ 21.069825] XENBUS: Unable to read cpu state [ 21.069962] XENBUS: Unable to read cpu state [ 21.070115] XENBUS: Unable to read cpu state [ 21.070284] XENBUS: Unable to read cpu state [ 21.940360] Ebtables v2.0 registered [ 21.974059] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.888084] br0: no IPv6 routers present [ 230.463540] xen-acpi-processor: Max ACPI ID: 16 [ 230.465802] ACPI CPU1 - P-states uploaded. [ 230.465812] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465816] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465819] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465822] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465825] P4: 800 MHz, 4777 mW, 4 uS [ 230.465839] ACPI CPU2 - P-states uploaded. [ 230.465843] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465846] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465850] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465853] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465856] P4: 800 MHz, 4777 mW, 4 uS [ 230.465871] ACPI CPU3 - P-states uploaded. [ 230.465876] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465881] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465886] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465892] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465897] P4: 800 MHz, 4777 mW, 4 uS [ 230.465911] ACPI CPU4 - P-states uploaded. [ 230.465921] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465927] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465932] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465937] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465942] P4: 800 MHz, 4777 mW, 4 uS [ 230.465963] ACPI CPU5 - P-states uploaded. [ 230.465968] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465978] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465983] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465988] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465993] P4: 800 MHz, 4777 mW, 4 uS [ 230.466006] ACPI CPU6 - P-states uploaded. [ 230.466013] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466018] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466023] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466028] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466032] P4: 800 MHz, 4777 mW, 4 uS [ 230.466045] ACPI CPU7 - P-states uploaded. [ 230.466051] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466056] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466060] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466065] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466073] P4: 800 MHz, 4777 mW, 4 uS [ 230.466083] ACPI CPU8 - P-states uploaded. [ 230.466088] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466093] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466098] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466103] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466108] P4: 800 MHz, 4777 mW, 4 uS [ 230.466134] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x810 [ 230.466150] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x0 [ 230.466161] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x0 [ 230.466172] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x0 [ 230.466182] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x0 [ 230.466193] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x0 [ 230.466203] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x0 [ 230.466213] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x0 [ 230.466227] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x0 [ 230.466237] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x0 [ 230.466247] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x0 [ 230.466258] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x0 --------------020809070207090105090201-- --------------enig72814478D7B52B9E326357CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoUwtAAoJEOhnXe7L7s6jIlgP/j8edSHPl/UjIYzv+MYr8AMq +sC0ud3CvBbxQdBN5guBTV8BhSNQCLPPiAHj251D+MZa8BT3J6qbAJ5w5KMMyXn+ AyPJvdiUm5g4n4Nqj1VjXjrlsLHeIGSHYsrmiGJalyWQDXtUOnEVfKqS6d+CGZWz qc/yPUfozlj+r3NY5IcSaWSZGIWqWa+U9Kb7eUmwz1Vuc4lKdaQyzEIApLskjpHc pGlC/c5L0g7opAh+aJTe6Xq5avZRydKgJbK2fTHe5tRFUEFNDh7Yfx0lhl1FQ6jl kiSXz7ddn59aNCr440HlKeXwGl9XfMX+RjIHPAmbDIM2CluSKIemNgPEYEZZMlsQ 2YDwYbztudrBZBHoBDI/E/Ii890IgVf7/W8Bb1DRVHTfbGn0DxR0A4uiRh/lKKec k7T5akVIobaKQJhIC22HsOxeD8MpvOlfCNXjGPL36xBcNLSKTPzSuYVHHq/S/wsw Jh+apvrVbsUpj4KnW8kB5j4TkI0awm+64ixoM/rJdrfTxolO1Pua+nvfxR598Fqa Mz/RQsZV7WycrwGv5gYHZTcNOBEbHBgrLvdjQzaomwEiRJ009ypOSfRJ6VYiY0dw GSTCdGAMEloUOfnqDMELJuOyDjwAgAcQIXevoZPG33s33cH5f6xMYhD6fJsP7gSZ qjFRCv/fEyTYtLcTDFoc =wuT/ -----END PGP SIGNATURE----- --------------enig72814478D7B52B9E326357CB-- --===============6456103616454136699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6456103616454136699==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb3Y-0007lD-5z; Wed, 02 May 2012 15:01:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb3V-0007l3-NW for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:01:26 +0000 Received: from [193.109.254.147:32130] by server-8.bemta-14.messagelabs.com id A5/C2-23244-54C41AF4; Wed, 02 May 2012 15:01:25 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1335970864!7276618!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14845 invoked from network); 2 May 2012 15:01:05 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-2.tower-27.messagelabs.com with SMTP; 2 May 2012 15:01:05 -0000 Received: from p5b2e3387.dip.t-dialin.net ([91.46.51.135] 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 ) id 1SPb38-0003xy-Qh; Wed, 02 May 2012 15:01:03 +0000 Message-ID: <4FA14C2C.5030104@canonical.com> Date: Wed, 02 May 2012 17:01:00 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> In-Reply-To: <4FA06541.7050607@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6456103616454136699==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6456103616454136699== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig72814478D7B52B9E326357CB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig72814478D7B52B9E326357CB Content-Type: multipart/mixed; boundary="------------020809070207090105090201" This is a multi-part message in MIME format. --------------020809070207090105090201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 00:35, Boris Ostrovsky wrote: > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>> Since there have been requests about that driver to get backported = into 3.2, I >>>>> was interested to find out what or how much would be gained by that= =2E >>>>> >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@= 2GHz). >>>>> Which >>>>> was not very successful as the drivers bail out of the init functio= n >>>>> because the >>>>> first call to acpi_processor_register_performance() returns -ENODEV= =2E There is >>>>> some frequency scaling when running without Xen, so I need to do so= me more >>>>> debugging there. >=20 > I believe this is caused by the somewhat under-enlightened xen_apic_rea= d(): >=20 > static u32 xen_apic_read(u32 reg) > { > return 0; > } >=20 > This results in some data, most importantly boot_cpu_physical_apicid, n= ot being > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. >=20 > On larger AMD systems boot processor is typically APICID=3D0x20 (I don'= t have > Intel system handy to see how it looks there). >=20 > As a quick and dirty test you can try: >=20 > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index edc2448..1f78998 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long = address) > } > if (boot_cpu_physical_apicid =3D=3D -1U) { > boot_cpu_physical_apicid =3D read_apic_id(); > + boot_cpu_physical_apicid =3D 32; > apic_version[boot_cpu_physical_apicid] =3D > GET_APIC_VERSION(apic_read(APIC_LVR)); > } >=20 >=20 > (Set it to whatever APICID on core0 is, I suspect it won't be zero). >=20 Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most of t= he BIOS bug messages are gone and the xen-acpi-processor driver successfully load= s and seems to be switching frequencies ok (just a quick tight loop which made = one cpu go from P4 to P0). -Stefan --------------020809070207090105090201 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.3" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.3" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg2 SMP Wed May 2 13:46:26= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg2-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] BIOS bug: APIC version is 0 for CPU 0/0x10, fixing up to 0= x10 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.194 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.38 BogoMIPS (lpj=3D8000776) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008042] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.017234] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019934] Mount-cache hash table entries: 256 [ 0.020139] Initializing cgroup subsys cpuacct [ 0.020151] Initializing cgroup subsys memory [ 0.020169] Initializing cgroup subsys devices [ 0.020175] Initializing cgroup subsys freezer [ 0.020181] Initializing cgroup subsys blkio [ 0.020197] Initializing cgroup subsys perf_event [ 0.020269] tseg: 00dff00000 [ 0.020276] CPU: Physical Processor ID: 0 [ 0.020281] CPU: Processor Core ID: 0 [ 0.023239] ACPI: Core revision 20110623 [ 0.039296] ftrace: allocating 27102 entries in 107 pages [ 0.040130] cpu 0 spinlock event irq 273 [ 0.040230] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040496] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040627] installing Xen timer for CPU 1 [ 0.040646] cpu 1 spinlock event irq 279 [ 0.040849] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040971] installing Xen timer for CPU 2 [ 0.040989] cpu 2 spinlock event irq 285 [ 0.041147] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041260] installing Xen timer for CPU 3 [ 0.041275] cpu 3 spinlock event irq 291 [ 0.041438] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041555] installing Xen timer for CPU 4 [ 0.041570] cpu 4 spinlock event irq 297 [ 0.041750] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041875] installing Xen timer for CPU 5 [ 0.041891] cpu 5 spinlock event irq 303 [ 0.042052] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042166] installing Xen timer for CPU 6 [ 0.042183] cpu 6 spinlock event irq 309 [ 0.042338] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042455] installing Xen timer for CPU 7 [ 0.042470] cpu 7 spinlock event irq 315 [ 0.042631] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042664] Brought up 8 CPUs [ 0.042893] devtmpfs: initialized [ 0.045288] EVM: security.selinux [ 0.045292] EVM: security.SMACK64 [ 0.045296] EVM: security.capability [ 0.045372] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045372] Grant table initialized [ 0.045372] print_constraints: dummy:=20 [ 0.045372] RTC time: 14:45:52, date: 05/02/12 [ 0.045372] NET: Registered protocol family 16 [ 0.045372] Trying to unpack rootfs image as initramfs... [ 0.060269] node 0 link 0: io port [1000, ffffff] [ 0.060283] TOM: 00000000e0000000 aka 3584M [ 0.060290] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060301] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060309] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060317] node 0 link 0: mmio [a0000, bffff] [ 0.060325] TOM2: 0000000820000000 aka 33280M [ 0.060330] bus: [00, 1f] on node 0 link 0 [ 0.060335] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060340] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060345] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060350] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060374] Extended Config Space enabled on 2 nodes [ 0.060542] ACPI: bus type pci registered [ 0.060651] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060660] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.180907] Freeing initrd memory: 40072k freed [ 0.219808] PCI: Using configuration type 1 for base access [ 0.221344] bio: create slab at 0 [ 0.221344] ACPI: Added _OSI(Module Device) [ 0.221344] ACPI: Added _OSI(Processor Device) [ 0.221344] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221344] ACPI: Added _OSI(Processor Aggregator Device) [ 0.225715] ACPI: EC: Look up EC in DSDT [ 0.230192] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253658] ACPI: Interpreter enabled [ 0.253667] ACPI: (supports S0 S1 S4 S5) [ 0.253712] ACPI: Using IOAPIC for interrupt routing [ 0.267237] ACPI: No dock devices found. [ 0.267301] HEST: Table parsing has been initialized. [ 0.267309] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267617] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268211] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268218] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268224] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268230] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268237] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268279] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268473] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268677] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268795] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268804] pci 0000:00:09.0: PME# disabled [ 0.268845] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268962] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.268970] pci 0000:00:0a.0: PME# disabled [ 0.269065] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269102] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269125] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269145] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269165] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269185] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269205] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269314] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269341] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269465] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269492] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269625] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269663] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269821] pci 0000:00:12.2: supports D1 D2 [ 0.269826] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269836] pci 0000:00:12.2: PME# disabled [ 0.269875] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269902] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270026] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270053] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270190] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270228] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270418] pci 0000:00:13.2: supports D1 D2 [ 0.270423] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270432] pci 0000:00:13.2: PME# disabled [ 0.270477] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270668] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270812] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270893] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270921] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271063] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271193] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271254] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271322] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271412] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271526] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271644] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271707] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271806] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271900] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280069] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280079] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280203] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280237] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280282] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280307] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280487] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280499] pci 0000:02:00.0: PME# disabled [ 0.288054] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288143] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288182] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288205] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288228] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288436] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288451] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288461] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288467] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288473] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288480] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288487] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288493] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288541] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288954] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289027] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289138] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289344] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289352] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289358] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307234] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307382] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307517] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307650] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.307782] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.307924] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308030] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308163] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308239] xen/balloon: Initialising balloon driver. [ 0.351878] xen-balloon: Initialising balloon driver. [ 0.351910] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352081] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352089] vgaarb: loaded [ 0.352092] vgaarb: bridge control possible 0000:01:04.0 [ 0.352233] i2c-core: driver [aat2870] using legacy suspend method [ 0.352239] i2c-core: driver [aat2870] using legacy resume method [ 0.352360] SCSI subsystem initialized [ 0.352432] libata version 3.00 loaded. [ 0.352432] usbcore: registered new interface driver usbfs [ 0.352432] usbcore: registered new interface driver hub [ 0.352432] usbcore: registered new device driver usb [ 0.352432] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356114] NetLabel: Initializing [ 0.356119] NetLabel: domain hash size =3D 128 [ 0.356123] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356140] NetLabel: unlabeled traffic allowed by default [ 0.356221] Switching to clocksource xen [ 0.365468] AppArmor: AppArmor Filesystem Enabled [ 0.365506] pnp: PnP ACPI init [ 0.365528] ACPI: bus type pnp registered [ 0.365887] pnp 00:00: [bus 00-ff] [ 0.365893] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365898] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365903] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365908] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365913] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365919] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365924] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366046] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366320] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366327] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366410] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366622] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366683] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366690] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367338] pnp 00:03: [dma 4] [ 0.367343] pnp 00:03: [io 0x0000-0x000f] [ 0.367347] pnp 00:03: [io 0x0081-0x0083] [ 0.367352] pnp 00:03: [io 0x0087] [ 0.367356] pnp 00:03: [io 0x0089-0x008b] [ 0.367361] pnp 00:03: [io 0x008f] [ 0.367365] pnp 00:03: [io 0x00c0-0x00df] [ 0.367422] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367449] pnp 00:04: [io 0x0070-0x0071] [ 0.367457] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367466] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367471] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367490] pnp 00:04: [irq 8] [ 0.367547] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367616] pnp 00:05: [io 0x0060] [ 0.367621] pnp 00:05: [io 0x0064] [ 0.367625] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367631] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367636] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367652] pnp 00:05: [irq 1] [ 0.367708] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367822] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367829] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367833] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367847] pnp 00:06: [irq 12] [ 0.367907] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367928] pnp 00:07: [io 0x0061] [ 0.368018] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368039] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368044] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368051] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368056] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368081] pnp 00:08: [irq 13] [ 0.368137] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368338] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368344] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368350] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368433] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368440] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368533] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368595] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368897] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368902] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.368985] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.368992] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.368999] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369529] pnp 00:0c: [io 0x0010-0x001f] [ 0.369534] pnp 00:0c: [io 0x0022-0x003f] [ 0.369539] pnp 00:0c: [io 0x0062-0x0063] [ 0.369543] pnp 00:0c: [io 0x0065-0x006f] [ 0.369548] pnp 00:0c: [io 0x0072-0x007f] [ 0.369552] pnp 00:0c: [io 0x0080] [ 0.369556] pnp 00:0c: [io 0x0084-0x0086] [ 0.369561] pnp 00:0c: [io 0x0088] [ 0.369565] pnp 00:0c: [io 0x008c-0x008e] [ 0.369569] pnp 00:0c: [io 0x0090-0x009f] [ 0.369574] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369578] pnp 00:0c: [io 0x00b1] [ 0.369582] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369587] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369591] pnp 00:0c: [io 0x0550-0x0551] [ 0.369596] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369600] pnp 00:0c: [io 0x040b] [ 0.369604] pnp 00:0c: [io 0x04d6] [ 0.369608] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369613] pnp 00:0c: [io 0x0c14] [ 0.369617] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369621] pnp 00:0c: [io 0x0c52] [ 0.369626] pnp 00:0c: [io 0x0c6c] [ 0.369630] pnp 00:0c: [io 0x0c6f] [ 0.369634] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369638] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369643] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369647] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369652] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369656] pnp 00:0c: [io 0x0800-0x089f] [ 0.369661] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369666] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369670] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369675] pnp 00:0c: [io 0x0900-0x090f] [ 0.369679] pnp 00:0c: [io 0x0910-0x091f] [ 0.369684] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369688] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369693] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369698] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369706] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369818] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369824] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369830] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369836] system 00:0c: [io 0x040b] has been reserved [ 0.369842] system 00:0c: [io 0x04d6] has been reserved [ 0.369847] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369853] system 00:0c: [io 0x0c14] has been reserved [ 0.369858] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369864] system 00:0c: [io 0x0c52] has been reserved [ 0.369870] system 00:0c: [io 0x0c6c] has been reserved [ 0.369875] system 00:0c: [io 0x0c6f] has been reserved [ 0.369881] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369887] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369893] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369898] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369904] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369913] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369919] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369925] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369931] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369937] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369943] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369950] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369956] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369963] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370520] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370526] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370531] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370536] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370552] pnp 00:0d: [irq 4] [ 0.370557] pnp 00:0d: [dma 0 disabled] [ 0.370681] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371255] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371260] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371266] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371270] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371275] Already setup the GSI :3 [ 0.371279] pnp 00:0e: [irq 3] [ 0.371284] pnp 00:0e: [dma 0 disabled] [ 0.371404] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371547] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371630] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371637] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372610] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372615] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372620] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372625] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372635] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372734] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372741] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372747] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372753] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372760] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372767] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373080] pnp: PnP ACPI: found 17 devices [ 0.373085] ACPI: ACPI bus type pnp unregistered [ 0.380388] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380414] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380485] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380492] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380502] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380516] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380523] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380533] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380547] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380558] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380568] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380592] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380611] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380626] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380636] pci 0000:00:09.0: setting latency timer to 64 [ 0.380648] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380658] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380670] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380679] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380695] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380700] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380706] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380711] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380717] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380723] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380728] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380734] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380740] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380746] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380752] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380759] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380764] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380770] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380776] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380782] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380840] NET: Registered protocol family 2 [ 0.382874] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388164] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391394] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391772] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391779] TCP reno registered [ 0.391903] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392172] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392420] NET: Registered protocol family 1 [ 0.392475] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392498] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392519] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120175] pci 0000:00:12.0: PCI INT A disabled [ 1.120207] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120221] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120227] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120232] Already setup the GSI :16 [ 1.120238] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204177] pci 0000:00:12.1: PCI INT A disabled [ 1.204211] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204224] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204230] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204235] Already setup the GSI :17 [ 1.204241] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204378] pci 0000:00:12.2: PCI INT B disabled [ 1.204393] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204399] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204404] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204408] Already setup the GSI :18 [ 1.204413] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288202] pci 0000:00:13.0: PCI INT A disabled [ 1.288233] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288246] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288251] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288256] Already setup the GSI :18 [ 1.288262] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372182] pci 0000:00:13.1: PCI INT A disabled [ 1.372216] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372243] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372262] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372397] pci 0000:00:13.2: PCI INT B disabled [ 1.372424] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372430] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372434] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372439] Already setup the GSI :18 [ 1.372444] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456175] pci 0000:00:14.5: PCI INT C disabled [ 1.456261] pci 0000:01:04.0: Boot video device [ 1.456269] PCI: CLS 64 bytes, default 64 [ 1.457352] audit: initializing netlink socket (disabled) [ 1.457372] type=3D2000 audit(1335969953.923:1): initialized [ 1.485603] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487841] VFS: Disk quotas dquot_6.5.2 [ 1.487923] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488634] fuse init (API version 7.17) [ 1.488808] msgmni has been set to 1479 [ 1.489519] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489578] io scheduler noop registered [ 1.489583] io scheduler deadline registered [ 1.489627] io scheduler cfq registered (default) [ 1.490108] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490142] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490330] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490341] ACPI: Power Button [PWRB] [ 1.490401] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490409] ACPI: Power Button [PWRF] [ 1.716979] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.717094] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.717274] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.717857] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.721834] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.746263] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.852428] hpet_acpi_add: no address or irqs in _CRS [ 1.852449] Linux agpgart interface v0.103 [ 1.856352] brd: module loaded [ 1.857407] loop: module loaded [ 1.857802] ahci 0000:00:11.0: version 3.0 [ 1.857824] xen: registering gsi 22 triggering 0 polarity 1 [ 1.857845] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.857864] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.858086] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.858095] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.859054] scsi0 : ahci [ 1.859169] scsi1 : ahci [ 1.859262] scsi2 : ahci [ 1.859362] scsi3 : ahci [ 1.859468] scsi4 : ahci [ 1.859560] scsi5 : ahci [ 1.860509] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.860517] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.860525] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.860532] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.860539] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.860546] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.861047] Fixed MDIO Bus: probed [ 1.861071] tun: Universal TUN/TAP device driver, 1.6 [ 1.861076] tun: (C) 1999-2004 Max Krasnyansky [ 1.861162] PPP generic driver version 2.4.2 [ 1.861314] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.861402] xen: registering gsi 17 triggering 0 polarity 1 [ 1.861411] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.861416] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.861420] Already setup the GSI :17 [ 1.861426] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.861460] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.861523] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.861540] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.861636] ehci_hcd 0000:00:12.2: debug port 1 [ 1.861720] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.872106] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.872298] hub 1-0:1.0: USB hub found [ 1.872307] hub 1-0:1.0: 6 ports detected [ 1.872556] xen: registering gsi 19 triggering 0 polarity 1 [ 1.872564] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.872569] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.872574] Already setup the GSI :19 [ 1.872579] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.872614] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.872700] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.872716] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.872808] ehci_hcd 0000:00:13.2: debug port 1 [ 1.872857] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.884099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.884311] hub 2-0:1.0: USB hub found [ 1.884319] hub 2-0:1.0: 6 ports detected [ 1.884438] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.884590] xen: registering gsi 16 triggering 0 polarity 1 [ 1.884598] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.884603] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.884608] Already setup the GSI :16 [ 1.884613] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.884648] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.884743] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.884809] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.944281] hub 3-0:1.0: USB hub found [ 1.944296] hub 3-0:1.0: 3 ports detected [ 1.944511] xen: registering gsi 16 triggering 0 polarity 1 [ 1.944519] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.944524] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.944528] Already setup the GSI :16 [ 1.944534] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.944569] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.944667] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.944707] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 2.004294] hub 4-0:1.0: USB hub found [ 2.004308] hub 4-0:1.0: 3 ports detected [ 2.004528] xen: registering gsi 18 triggering 0 polarity 1 [ 2.004535] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.004540] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.004545] Already setup the GSI :18 [ 2.004550] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.004585] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 2.004671] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 2.004738] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.064268] hub 5-0:1.0: USB hub found [ 2.064282] hub 5-0:1.0: 3 ports detected [ 2.064494] xen: registering gsi 18 triggering 0 polarity 1 [ 2.064502] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.064506] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.064511] Already setup the GSI :18 [ 2.064516] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.064551] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.064620] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.064659] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.124279] hub 6-0:1.0: USB hub found [ 2.124293] hub 6-0:1.0: 3 ports detected [ 2.124502] xen: registering gsi 18 triggering 0 polarity 1 [ 2.124509] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.124514] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.124519] Already setup the GSI :18 [ 2.124524] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.124559] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.124626] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.124666] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.184191] ata5: SATA link down (SStatus 0 SControl 300) [ 2.184261] hub 7-0:1.0: USB hub found [ 2.184272] hub 7-0:1.0: 2 ports detected [ 2.184358] uhci_hcd: USB Universal Host Controller Interface driver [ 2.184440] usbcore: registered new interface driver libusual [ 2.184498] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.187405] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.187418] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.187601] mousedev: PS/2 mouse device common for all mice [ 2.187775] rtc_cmos 00:04: RTC can wake from S4 [ 2.187934] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.187989] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.188106] device-mapper: uevent: version 1.0.3 [ 2.188194] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.188207] EFI Variables Facility v0.08 2004-May-17 [ 2.188532] TCP cubic registered [ 2.188663] NET: Registered protocol family 10 [ 2.189387] NET: Registered protocol family 17 [ 2.189411] Registering the dns_resolver key type [ 2.189546] PM: Hibernation image not present or could not be loaded. [ 2.189563] registered taskstats version 1 [ 2.196092] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.207113] Magic number: 12:861:787 [ 2.207307] rtc_cmos 00:04: setting system clock to 2012-05-02 14:45:5= 4 UTC (1335969954) [ 2.207436] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.207544] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.207549] EDD information not available. [ 2.220637] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.334785] Initializing USB Mass Storage driver... [ 2.335007] scsi6 : usb-storage 2-2:1.0 [ 2.335086] usbcore: registered new interface driver usb-storage [ 2.335092] USB Mass Storage support registered. [ 2.360141] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360175] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360201] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360225] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.360250] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.360796] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.361200] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361208] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361277] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361285] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361334] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361340] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361354] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361360] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.361505] ata6.00: configured for UDMA/100 [ 2.362391] ata4.00: configured for UDMA/133 [ 2.362421] ata2.00: configured for UDMA/133 [ 2.362599] ata1.00: configured for UDMA/133 [ 2.362749] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.362951] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363055] sd 0:0:0:0: [sda] Write Protect is off [ 2.363061] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.363118] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.363162] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363312] ata3.00: configured for UDMA/133 [ 2.363439] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.363609] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363669] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.363762] sd 1:0:0:0: [sdb] Write Protect is off [ 2.363769] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.363808] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363950] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.364143] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.364168] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.364238] sd 2:0:0:0: [sdc] Write Protect is off [ 2.364245] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.364291] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.364333] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.364513] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.364564] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.364735] sd 3:0:0:0: [sdd] Write Protect is off [ 2.364741] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.364780] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.365239] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.368276] sdb: sdb1 sdb2 [ 2.368691] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.368760] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.368768] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.368876] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.368945] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.376384] sdd: unknown partition table [ 2.376666] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.379373] sdc: unknown partition table [ 2.379649] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.483103] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.484090] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.484841] Freeing unused kernel memory: 920k freed [ 2.485162] Write protecting the kernel read-only data: 12288k [ 2.492276] Freeing unused kernel memory: 1520k freed [ 2.493426] Freeing unused kernel memory: 1140k freed [ 2.559332] udevd[165]: starting version 175 [ 2.620594] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.620604] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.623802] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.623832] xen: registering gsi 17 triggering 0 polarity 1 [ 2.623845] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.623850] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.623856] Already setup the GSI :17 [ 2.623862] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.623894] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.704179] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.737702] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.737713] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.737798] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.738025] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.738052] xen: registering gsi 18 triggering 0 polarity 1 [ 2.738096] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.738102] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.738107] Already setup the GSI :18 [ 2.738113] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.738145] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.853363] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.853372] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.853456] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.882463] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.882615] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.886373] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.886517] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.886542] usbcore: registered new interface driver usbhid [ 2.886547] usbhid: USB HID core driver [ 3.333153] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.333827] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.334481] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.335199] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.336131] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.336366] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.336599] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.336822] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.342133] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.346546] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.347264] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.348092] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 8.966388] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.562527] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.562539] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.593024] udevd[718]: starting version 175 [ 15.695773] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.717924] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.718899] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.719044] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.723681] lp: driver loaded but no devices found [ 15.734573] ipmi message handler version 39.2 [ 15.735953] ipmi device interface [ 15.739772] Bridge firewalling registered [ 15.741834] IPMI System Interface driver. [ 15.741948] ipmi_si: probing via SMBIOS [ 15.741953] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.741960] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.741973] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.751212] device-mapper: multipath: version 1.3.0 loaded [ 15.756221] device eth0 entered promiscuous mode [ 15.784153] type=3D1400 audit(1335969968.074:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D842 comm=3D"appar= mor_parser" [ 15.784732] type=3D1400 audit(1335969968.074:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D842 comm=3D"apparmor_parser" [ 15.785117] type=3D1400 audit(1335969968.074:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D842 comm=3D"apparmor_parser" [ 15.802699] MCE: In-kernel MCE decoding enabled. [ 15.804165] EDAC MC: Ver: 2.1.0 [ 15.807771] AMD64 EDAC driver v3.4.0 [ 15.808823] EDAC amd64: DRAM ECC enabled. [ 15.808852] EDAC amd64: F10h detected (node 0). [ 15.808916] EDAC MC: DCT0 chip selects: [ 15.808920] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.808924] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.808927] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.808930] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.808933] EDAC MC: DCT1 chip selects: [ 15.808939] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.808942] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.808948] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.808951] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.808954] EDAC amd64: using x8 syndromes. [ 15.808960] EDAC amd64: MCT channel count: 2 [ 15.809009] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.809012] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.809015] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.809018] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.809112] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.809275] EDAC amd64: DRAM ECC enabled. [ 15.809280] EDAC amd64: F10h detected (node 1). [ 15.809345] EDAC MC: DCT0 chip selects: [ 15.809349] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.809352] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.809355] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.809358] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.809360] EDAC MC: DCT1 chip selects: [ 15.809363] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.809366] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.809369] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.809372] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.809375] EDAC amd64: using x8 syndromes. [ 15.809377] EDAC amd64: MCT channel count: 2 [ 15.809404] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.809407] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.809413] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.809416] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.809583] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.809909] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.842927] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.855258] ADDRCONF(NETDEV_UP): br0: link is not ready [ 15.856181] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.898626] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.899311] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.032526] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.123208] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.868146] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.205624] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.069087] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.071434] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.071572] br0: port 1(eth0) entering forwarding state [ 19.071587] br0: port 1(eth0) entering forwarding state [ 19.073722] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 19.861816] init: udev-fallback-graphics main process (1853) terminate= d with status 1 [ 19.990334] init: failsafe main process (1730) killed by TERM signal [ 20.102020] type=3D1400 audit(1335969972.390:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1942 comm=3D"apparmor_parser" [ 20.102328] type=3D1400 audit(1335969972.390:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1940 comm=3D"a= pparmor_parser" [ 20.102359] type=3D1400 audit(1335969972.390:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1943 comm=3D"= apparmor_parser" [ 20.102975] type=3D1400 audit(1335969972.390:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1940 comm=3D"apparmor_parser" [ 20.103332] type=3D1400 audit(1335969972.390:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1940 comm=3D"apparmor_parser" [ 20.103432] type=3D1400 audit(1335969972.390:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1944 c= omm=3D"apparmor_parser" [ 20.103792] type=3D1400 audit(1335969972.390:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1944 comm=3D"apparmor_parser" [ 20.392238] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 20.626333] ip_tables: (C) 2000-2006 Netfilter Core Team [ 20.728136] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 20.779431] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 21.005464] Event-channel device installed. [ 21.069011] XENBUS: Unable to read cpu state [ 21.069219] XENBUS: Unable to read cpu state [ 21.069422] XENBUS: Unable to read cpu state [ 21.069607] XENBUS: Unable to read cpu state [ 21.069825] XENBUS: Unable to read cpu state [ 21.069962] XENBUS: Unable to read cpu state [ 21.070115] XENBUS: Unable to read cpu state [ 21.070284] XENBUS: Unable to read cpu state [ 21.940360] Ebtables v2.0 registered [ 21.974059] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.888084] br0: no IPv6 routers present [ 230.463540] xen-acpi-processor: Max ACPI ID: 16 [ 230.465802] ACPI CPU1 - P-states uploaded. [ 230.465812] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465816] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465819] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465822] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465825] P4: 800 MHz, 4777 mW, 4 uS [ 230.465839] ACPI CPU2 - P-states uploaded. [ 230.465843] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465846] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465850] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465853] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465856] P4: 800 MHz, 4777 mW, 4 uS [ 230.465871] ACPI CPU3 - P-states uploaded. [ 230.465876] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465881] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465886] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465892] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465897] P4: 800 MHz, 4777 mW, 4 uS [ 230.465911] ACPI CPU4 - P-states uploaded. [ 230.465921] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465927] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465932] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465937] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465942] P4: 800 MHz, 4777 mW, 4 uS [ 230.465963] ACPI CPU5 - P-states uploaded. [ 230.465968] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.465978] P1: 1500 MHz, 8265 mW, 4 uS [ 230.465983] P2: 1200 MHz, 6825 mW, 4 uS [ 230.465988] P3: 1000 MHz, 5600 mW, 4 uS [ 230.465993] P4: 800 MHz, 4777 mW, 4 uS [ 230.466006] ACPI CPU6 - P-states uploaded. [ 230.466013] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466018] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466023] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466028] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466032] P4: 800 MHz, 4777 mW, 4 uS [ 230.466045] ACPI CPU7 - P-states uploaded. [ 230.466051] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466056] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466060] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466065] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466073] P4: 800 MHz, 4777 mW, 4 uS [ 230.466083] ACPI CPU8 - P-states uploaded. [ 230.466088] *P0: 2000 MHz, 10580 mW, 4 uS [ 230.466093] P1: 1500 MHz, 8265 mW, 4 uS [ 230.466098] P2: 1200 MHz, 6825 mW, 4 uS [ 230.466103] P3: 1000 MHz, 5600 mW, 4 uS [ 230.466108] P4: 800 MHz, 4777 mW, 4 uS [ 230.466134] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x810 [ 230.466150] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x0 [ 230.466161] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x0 [ 230.466172] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x0 [ 230.466182] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x0 [ 230.466193] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x0 [ 230.466203] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x0 [ 230.466213] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x0 [ 230.466227] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x0 [ 230.466237] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x0 [ 230.466247] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x0 [ 230.466258] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x0 --------------020809070207090105090201-- --------------enig72814478D7B52B9E326357CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoUwtAAoJEOhnXe7L7s6jIlgP/j8edSHPl/UjIYzv+MYr8AMq +sC0ud3CvBbxQdBN5guBTV8BhSNQCLPPiAHj251D+MZa8BT3J6qbAJ5w5KMMyXn+ AyPJvdiUm5g4n4Nqj1VjXjrlsLHeIGSHYsrmiGJalyWQDXtUOnEVfKqS6d+CGZWz qc/yPUfozlj+r3NY5IcSaWSZGIWqWa+U9Kb7eUmwz1Vuc4lKdaQyzEIApLskjpHc pGlC/c5L0g7opAh+aJTe6Xq5avZRydKgJbK2fTHe5tRFUEFNDh7Yfx0lhl1FQ6jl kiSXz7ddn59aNCr440HlKeXwGl9XfMX+RjIHPAmbDIM2CluSKIemNgPEYEZZMlsQ 2YDwYbztudrBZBHoBDI/E/Ii890IgVf7/W8Bb1DRVHTfbGn0DxR0A4uiRh/lKKec k7T5akVIobaKQJhIC22HsOxeD8MpvOlfCNXjGPL36xBcNLSKTPzSuYVHHq/S/wsw Jh+apvrVbsUpj4KnW8kB5j4TkI0awm+64ixoM/rJdrfTxolO1Pua+nvfxR598Fqa Mz/RQsZV7WycrwGv5gYHZTcNOBEbHBgrLvdjQzaomwEiRJ009ypOSfRJ6VYiY0dw GSTCdGAMEloUOfnqDMELJuOyDjwAgAcQIXevoZPG33s33cH5f6xMYhD6fJsP7gSZ qjFRCv/fEyTYtLcTDFoc =wuT/ -----END PGP SIGNATURE----- --------------enig72814478D7B52B9E326357CB-- --===============6456103616454136699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6456103616454136699==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:03:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:03:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb4s-0007rV-1T; Wed, 02 May 2012 15:02:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb4r-0007rG-19 for xen-devel@lists.xen.org; Wed, 02 May 2012 15:02:49 +0000 Received: from [193.109.254.147:61079] by server-5.bemta-14.messagelabs.com id A0/06-30733-89C41AF4; Wed, 02 May 2012 15:02:48 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-27.messagelabs.com!1335970967!476347!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4810 invoked from network); 2 May 2012 15:02:47 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-27.messagelabs.com with SMTP; 2 May 2012 15:02:47 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77551064; Wed, 02 May 2012 17:02:46 +0200 Message-ID: <1335970965.2961.51.camel@Abyss> From: Dario Faggioli To: Ian Campbell Date: Wed, 02 May 2012 17:02:45 +0200 In-Reply-To: <1335272011.4347.108.camel@zakaz.uk.xensource.com> References: <1335272011.4347.108.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.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 Release Plan / TODO X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2882401088892209699==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2882401088892209699== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-20KBDmv7Ssxa/nnVbDr6" --=-20KBDmv7Ssxa/nnVbDr6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-24 at 13:53 +0100, Ian Campbell wrote:=20 > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html >=20 > The time line is as follows: >=20 > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > I'm guessing we're still here and hence I'm proposing the following. > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. >=20 As it is probably known and has been repeatedly stated in various threads, xm/xend has some kind of NUMA placement policy when a new guest is being created. On the opposite hand, xl/libxl does absolutely nothing, and that looks like an issue for the xl-xend feature parity we're aiming at. What xend basically does is trying to figure out where to put a guest (according to some heuristics) and it then pins its vcpus there. The NUMA series I posted also introduces some placement heuristics into xl, and I can easily take the scheduling/affinity modification apart and do pin vcpus basing on the outcome of the heuristics, just like xend. Yes, I noticed this for the first time way earlier than now, but it's only now that it came to my mind that this could be quite a serious feature parity issue, and that I can (try to!) fix with a reasonably small effort. Therefore, I'm officially proposing to add "automatic NUMA placement and vcpu pinning in xl" here below: > tools, blockers: > ...=20 > * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it> > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter has posted a patch. * does not automatically try to select a (set of)=20 node(s) on which to create a VM and pin its vcpus there. The strong case I'm making is that not having this is a regression wrt default xend behaviour, and it could upset and break stuff for people expecting the toolstack tacking care about NUMA, at least in some rough way (which btw is what xend is doing). I'm not far from having the patches so, if the proposal is accepted, I can post them next week, I'm quite sure. Thoughts? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-20KBDmv7Ssxa/nnVbDr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hTJUACgkQk4XaBE3IOsS/xwCeOVHWpKdbOkCcCPSZds0mzsZq fVwAoKF9dak6B9s2iK/JgEFGG8kRCZYf =FN6c -----END PGP SIGNATURE----- --=-20KBDmv7Ssxa/nnVbDr6-- --===============2882401088892209699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2882401088892209699==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:03:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:03:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb4s-0007rV-1T; Wed, 02 May 2012 15:02:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPb4r-0007rG-19 for xen-devel@lists.xen.org; Wed, 02 May 2012 15:02:49 +0000 Received: from [193.109.254.147:61079] by server-5.bemta-14.messagelabs.com id A0/06-30733-89C41AF4; Wed, 02 May 2012 15:02:48 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-27.messagelabs.com!1335970967!476347!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4810 invoked from network); 2 May 2012 15:02:47 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-27.messagelabs.com with SMTP; 2 May 2012 15:02:47 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77551064; Wed, 02 May 2012 17:02:46 +0200 Message-ID: <1335970965.2961.51.camel@Abyss> From: Dario Faggioli To: Ian Campbell Date: Wed, 02 May 2012 17:02:45 +0200 In-Reply-To: <1335272011.4347.108.camel@zakaz.uk.xensource.com> References: <1335272011.4347.108.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.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 Release Plan / TODO X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2882401088892209699==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2882401088892209699== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-20KBDmv7Ssxa/nnVbDr6" --=-20KBDmv7Ssxa/nnVbDr6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-24 at 13:53 +0100, Ian Campbell wrote:=20 > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html >=20 > The time line is as follows: >=20 > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > I'm guessing we're still here and hence I'm proposing the following. > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. >=20 As it is probably known and has been repeatedly stated in various threads, xm/xend has some kind of NUMA placement policy when a new guest is being created. On the opposite hand, xl/libxl does absolutely nothing, and that looks like an issue for the xl-xend feature parity we're aiming at. What xend basically does is trying to figure out where to put a guest (according to some heuristics) and it then pins its vcpus there. The NUMA series I posted also introduces some placement heuristics into xl, and I can easily take the scheduling/affinity modification apart and do pin vcpus basing on the outcome of the heuristics, just like xend. Yes, I noticed this for the first time way earlier than now, but it's only now that it came to my mind that this could be quite a serious feature parity issue, and that I can (try to!) fix with a reasonably small effort. Therefore, I'm officially proposing to add "automatic NUMA placement and vcpu pinning in xl" here below: > tools, blockers: > ...=20 > * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it> > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter has posted a patch. * does not automatically try to select a (set of)=20 node(s) on which to create a VM and pin its vcpus there. The strong case I'm making is that not having this is a regression wrt default xend behaviour, and it could upset and break stuff for people expecting the toolstack tacking care about NUMA, at least in some rough way (which btw is what xend is doing). I'm not far from having the patches so, if the proposal is accepted, I can post them next week, I'm quite sure. Thoughts? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-20KBDmv7Ssxa/nnVbDr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hTJUACgkQk4XaBE3IOsS/xwCeOVHWpKdbOkCcCPSZds0mzsZq fVwAoKF9dak6B9s2iK/JgEFGG8kRCZYf =FN6c -----END PGP SIGNATURE----- --=-20KBDmv7Ssxa/nnVbDr6-- --===============2882401088892209699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2882401088892209699==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:13:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 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 ) id 1SPbEf-0008A0-9F; Wed, 02 May 2012 15:12:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbEd-00089v-91 for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:12:55 +0000 Received: from [85.158.139.83:22061] by server-9.bemta-5.messagelabs.com id D3/AF-09826-6FE41AF4; Wed, 02 May 2012 15:12:54 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335971571!26436367!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE0NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10146 invoked from network); 2 May 2012 15:12:52 -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; 2 May 2012 15:12:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="24773803" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:49 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-BR; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:22 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 2] libxlu: Rename filename to config_source X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User George Dunlap # Date 1335971126 -3600 # Node ID c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 # Parent c9f97681552fd9aaf3157f30e1f502d9db17f395 libxlu: Rename filename to config_source The "filename" is a bit of a misnomer, as it's only used during error messages, and in most instances cases is actually set to "command line". Rename it to "config_source" to make it clear that it's not used to actually open any files. No functional changes. Signed-off-by: George Dunlap diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_cfg.c --- a/tools/libxl/libxlu_cfg.c Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_cfg.c Wed May 02 16:05:26 2012 +0100 @@ -25,15 +25,15 @@ #include "libxlu_cfg_l.h" #include "libxlu_cfg_i.h" -XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename) { +XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) { XLU_Config *cfg; cfg= malloc(sizeof(*cfg)); if (!cfg) return 0; cfg->report= report; - cfg->filename= strdup(report_filename); - if (!cfg->filename) { free(cfg); return 0; } + cfg->config_source= strdup(report_source); + if (!cfg->config_source) { free(cfg); return 0; } cfg->settings= 0; return cfg; @@ -51,7 +51,7 @@ static int ctx_prep(CfgParseContext *ctx e= xlu__cfg_yylex_init_extra(ctx, &ctx->scanner); if (e) { fprintf(cfg->report,"%s: unable to create scanner: %s\n", - cfg->filename, strerror(e)); + cfg->config_source, strerror(e)); return e; } return 0; @@ -117,7 +117,7 @@ int xlu_cfg_readdata(XLU_Config *cfg, co buf = xlu__cfg_yy_scan_bytes(data, length, ctx.scanner); if (!buf) { fprintf(cfg->report,"%s: unable to allocate scanner buffer\n", - cfg->filename); + cfg->config_source); ctx.err= ENOMEM; goto xe; } @@ -151,7 +151,7 @@ void xlu_cfg_destroy(XLU_Config *cfg) { set_next= set->next; xlu__cfg_set_free(set); } - free(cfg->filename); + free(cfg->config_source); free(cfg); } @@ -178,7 +178,7 @@ static int find_atom(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' is" " a list but should be a single value\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); return EINVAL; } *set_r= set; @@ -223,14 +223,14 @@ int xlu_cfg_get_long(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' could not be parsed" " as a number: %s\n", - cfg->filename, set->lineno, n, strerror(e)); + cfg->config_source, set->lineno, n, strerror(e)); return e; } if (*ep || ep==set->values[0]) { if (!dont_warn) fprintf(cfg->report, "%s:%d: warning: parameter `%s' is not a valid number\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); return EINVAL; } *value_r= l; @@ -258,7 +258,7 @@ int xlu_cfg_get_list(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' is a single value" " but should be a list\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); } return EINVAL; } @@ -467,7 +467,7 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgP fprintf(ctx->cfg->report, "%s:%d: config parsing error near %s%.*s%s%s: %s\n", - ctx->cfg->filename, lineno, + ctx->cfg->config_source, lineno, len?"`":"", len, text, len?"'":"", newline, msg); if (!ctx->err) ctx->err= EINVAL; diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_disk.c --- a/tools/libxl/libxlu_disk.c Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_disk.c Wed May 02 16:05:26 2012 +0100 @@ -10,7 +10,7 @@ void xlu__disk_err(DiskParseContext *dpc "%s: config parsing error in disk specification: %s" "%s%s%s" " in `%s'\n", - dpc->cfg->filename, message, + dpc->cfg->config_source, message, erroneous?": near `":"", erroneous?erroneous:"", erroneous?"'":"", dpc->spec); if (!dpc->err) dpc->err= EINVAL; diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_internal.h --- a/tools/libxl/libxlu_internal.h Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_internal.h Wed May 02 16:05:26 2012 +0100 @@ -38,7 +38,7 @@ struct XLU_ConfigSetting { /* transparen struct XLU_Config { XLU_ConfigSetting *settings; FILE *report; - char *filename; + char *config_source; }; typedef struct { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:13:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 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 ) id 1SPbEf-0008A0-9F; Wed, 02 May 2012 15:12:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbEd-00089v-91 for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:12:55 +0000 Received: from [85.158.139.83:22061] by server-9.bemta-5.messagelabs.com id D3/AF-09826-6FE41AF4; Wed, 02 May 2012 15:12:54 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335971571!26436367!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE0NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10146 invoked from network); 2 May 2012 15:12:52 -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; 2 May 2012 15:12:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="24773803" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:49 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-BR; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:22 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 2] libxlu: Rename filename to config_source X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User George Dunlap # Date 1335971126 -3600 # Node ID c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 # Parent c9f97681552fd9aaf3157f30e1f502d9db17f395 libxlu: Rename filename to config_source The "filename" is a bit of a misnomer, as it's only used during error messages, and in most instances cases is actually set to "command line". Rename it to "config_source" to make it clear that it's not used to actually open any files. No functional changes. Signed-off-by: George Dunlap diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_cfg.c --- a/tools/libxl/libxlu_cfg.c Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_cfg.c Wed May 02 16:05:26 2012 +0100 @@ -25,15 +25,15 @@ #include "libxlu_cfg_l.h" #include "libxlu_cfg_i.h" -XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename) { +XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) { XLU_Config *cfg; cfg= malloc(sizeof(*cfg)); if (!cfg) return 0; cfg->report= report; - cfg->filename= strdup(report_filename); - if (!cfg->filename) { free(cfg); return 0; } + cfg->config_source= strdup(report_source); + if (!cfg->config_source) { free(cfg); return 0; } cfg->settings= 0; return cfg; @@ -51,7 +51,7 @@ static int ctx_prep(CfgParseContext *ctx e= xlu__cfg_yylex_init_extra(ctx, &ctx->scanner); if (e) { fprintf(cfg->report,"%s: unable to create scanner: %s\n", - cfg->filename, strerror(e)); + cfg->config_source, strerror(e)); return e; } return 0; @@ -117,7 +117,7 @@ int xlu_cfg_readdata(XLU_Config *cfg, co buf = xlu__cfg_yy_scan_bytes(data, length, ctx.scanner); if (!buf) { fprintf(cfg->report,"%s: unable to allocate scanner buffer\n", - cfg->filename); + cfg->config_source); ctx.err= ENOMEM; goto xe; } @@ -151,7 +151,7 @@ void xlu_cfg_destroy(XLU_Config *cfg) { set_next= set->next; xlu__cfg_set_free(set); } - free(cfg->filename); + free(cfg->config_source); free(cfg); } @@ -178,7 +178,7 @@ static int find_atom(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' is" " a list but should be a single value\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); return EINVAL; } *set_r= set; @@ -223,14 +223,14 @@ int xlu_cfg_get_long(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' could not be parsed" " as a number: %s\n", - cfg->filename, set->lineno, n, strerror(e)); + cfg->config_source, set->lineno, n, strerror(e)); return e; } if (*ep || ep==set->values[0]) { if (!dont_warn) fprintf(cfg->report, "%s:%d: warning: parameter `%s' is not a valid number\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); return EINVAL; } *value_r= l; @@ -258,7 +258,7 @@ int xlu_cfg_get_list(const XLU_Config *c fprintf(cfg->report, "%s:%d: warning: parameter `%s' is a single value" " but should be a list\n", - cfg->filename, set->lineno, n); + cfg->config_source, set->lineno, n); } return EINVAL; } @@ -467,7 +467,7 @@ void xlu__cfg_yyerror(YYLTYPE *loc, CfgP fprintf(ctx->cfg->report, "%s:%d: config parsing error near %s%.*s%s%s: %s\n", - ctx->cfg->filename, lineno, + ctx->cfg->config_source, lineno, len?"`":"", len, text, len?"'":"", newline, msg); if (!ctx->err) ctx->err= EINVAL; diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_disk.c --- a/tools/libxl/libxlu_disk.c Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_disk.c Wed May 02 16:05:26 2012 +0100 @@ -10,7 +10,7 @@ void xlu__disk_err(DiskParseContext *dpc "%s: config parsing error in disk specification: %s" "%s%s%s" " in `%s'\n", - dpc->cfg->filename, message, + dpc->cfg->config_source, message, erroneous?": near `":"", erroneous?erroneous:"", erroneous?"'":"", dpc->spec); if (!dpc->err) dpc->err= EINVAL; diff -r c9f97681552f -r c3eda4333f15 tools/libxl/libxlu_internal.h --- a/tools/libxl/libxlu_internal.h Wed May 02 14:52:55 2012 +0100 +++ b/tools/libxl/libxlu_internal.h Wed May 02 16:05:26 2012 +0100 @@ -38,7 +38,7 @@ struct XLU_ConfigSetting { /* transparen struct XLU_Config { XLU_ConfigSetting *settings; FILE *report; - char *filename; + char *config_source; }; typedef struct { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:13:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15: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 ) id 1SPbEt-0008Ah-Lu; Wed, 02 May 2012 15:13:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbEr-0008AV-Sh for xen-devel@lists.xen.org; Wed, 02 May 2012 15:13:10 +0000 Received: from [85.158.143.99:43053] by server-1.bemta-4.messagelabs.com id 18/98-20925-50F41AF4; Wed, 02 May 2012 15:13:09 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-216.messagelabs.com!1335971587!22812349!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21272 invoked from network); 2 May 2012 15:13:07 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-216.messagelabs.com with SMTP; 2 May 2012 15:13:07 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77551965; Wed, 02 May 2012 17:13:07 +0200 Message-ID: <1335971586.2961.60.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Wed, 02 May 2012 17:13:06 +0200 In-Reply-To: <4F9AB0F8.10102@eu.citrix.com> References: <1f4b55806de9e7109ff6.1334150274@Solace> <4F9AB0F8.10102@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6757133835761434034==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6757133835761434034== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3n48E9qaqULvGKFci6NW" --=-3n48E9qaqULvGKFci6NW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-04-27 at 15:45 +0100, George Dunlap wrote:=20 > Hey Dario, >=20 Hi! > Sorry for the long delay in reviewing this. >=20 No problem, thanks to you for taking the time to look at the patches so thoroughly! > Overall I think the approach is good. =20 > That's nice to hear. :-) > > /* > > + * Node Balancing > > + */ > > +#define CSCHED_BALANCE_NODE_AFFINITY 1 > > +#define CSCHED_BALANCE_CPU_AFFINITY 0 > > +#define CSCHED_BALANCE_START_STEP CSCHED_BALANCE_NODE_AFFINITY > > +#define CSCHED_BALANCE_END_STEP CSCHED_BALANCE_CPU_AFFINITY > > + > > + > This thing of defining "START_STEP" and "END_STEP" seems a bit fragile. = =20 > I think it would be better to always start at 0, and go until=20 > CSCHED_BALANCE_MAX. > Ok, I agree that this is fragile and probably also a bit overkill. I'll make it simpler as you're suggesting. > > + /* > > + * Let's cache domain's dom->node_affinity here as an > > + * optimization for a couple of hot paths. In fact, > > + * knowing whether or not dom->node_affinity has changed > > + * would allow us to avoid rebuilding node_affinity_cpumask > > + * (below) duing node balancing and/or scheduling. > > + */ > > + nodemask_t node_affinity_cache; > > + /* Basing on what dom->node_affinity says, > > + * on what CPUs would we like to run most? */ > > + cpumask_t node_affinity_cpumask; > I think the comments here need to be more clear. The main points are: > * node_affinity_cpumask is the dom->node_affinity translated from a=20 > nodemask into a cpumask > * Because doing the nodemask -> cpumask translation may be expensive,=20 > node_affinity_cache stores the last translated value, so we can avoid=20 > doing the translation if nothing has changed. >=20 Ok, will do. > > +/* > > + * Sort-of conversion between node-affinity and vcpu-affinity for the = domain, > > + * i.e., a cpumask containing all the cpus from all the set nodes in t= he > > + * node-affinity mask of the domain. > This needs to be clearer -- vcpu-affinity doesn't have anything to do=20 > with this function, and there's nothing "sort-of" about the conversion. := -) >=20 > I think you mean to say, "Create a cpumask from the node affinity mask." > Exactly, I'll try to clarify. > > static inline void > > +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask) > > +{ > > + CSCHED_STAT_CRANK(tickle_idlers_some); > > + if ( opt_tickle_one_idle ) > > + { > > + this_cpu(last_tickle_cpu) =3D > > + cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask); > > + cpumask_set_cpu(this_cpu(last_tickle_cpu), mask); > > + } > > + else > > + cpumask_or(mask, mask, idle_mask); > > +} > I don't see any reason to make this into a function -- it's only called= =20 > once, and it's not that long. Unless you're concerned about too many=20 > indentations making the lines too short? > That was part of it, but I'll put it back and see if I can have it looking good enough. :-) > > sdom->dom =3D dom; > > + /* > > + *XXX This would be 'The Right Thing', but as it is still too > > + * early and d->node_affinity has not settled yet, maybe we > > + * can just init the two masks with something like all-nodes > > + * and all-cpus and rely on the first balancing call for > > + * having them updated? > > + */ > > + csched_build_balance_cpumask(sdom); > We might as well do what you've got here, unless it's likely to produce= =20 > garbage. This isn't exactly a hot path. :-) >=20 Well, I won't call it garbage, so that's probably fine. I was concerned about be thing be clear and meaningful enough. Having this here could make us (and or future coders :-D) think that they can rely on the balance mask somehow, while that is not entirely true. I'll re-check the code and see how I can make it something better for next posting... > Other than that, looks good -- Thanks! >=20 Good to know, thanks to you! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-3n48E9qaqULvGKFci6NW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hTwIACgkQk4XaBE3IOsRNNQCfUIlnas4XtpqnUqw2WEOvRW/I Rf8An3EXgE+Pbp3A8g6SYbb887q5kviV =1Ao3 -----END PGP SIGNATURE----- --=-3n48E9qaqULvGKFci6NW-- --===============6757133835761434034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6757133835761434034==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:13:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15: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 ) id 1SPbEt-0008Ah-Lu; Wed, 02 May 2012 15:13:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbEr-0008AV-Sh for xen-devel@lists.xen.org; Wed, 02 May 2012 15:13:10 +0000 Received: from [85.158.143.99:43053] by server-1.bemta-4.messagelabs.com id 18/98-20925-50F41AF4; Wed, 02 May 2012 15:13:09 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-216.messagelabs.com!1335971587!22812349!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21272 invoked from network); 2 May 2012 15:13:07 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-216.messagelabs.com with SMTP; 2 May 2012 15:13:07 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77551965; Wed, 02 May 2012 17:13:07 +0200 Message-ID: <1335971586.2961.60.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Wed, 02 May 2012 17:13:06 +0200 In-Reply-To: <4F9AB0F8.10102@eu.citrix.com> References: <1f4b55806de9e7109ff6.1334150274@Solace> <4F9AB0F8.10102@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 07 of 10 [RFC]] sched_credit: Let the scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6757133835761434034==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6757133835761434034== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3n48E9qaqULvGKFci6NW" --=-3n48E9qaqULvGKFci6NW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-04-27 at 15:45 +0100, George Dunlap wrote:=20 > Hey Dario, >=20 Hi! > Sorry for the long delay in reviewing this. >=20 No problem, thanks to you for taking the time to look at the patches so thoroughly! > Overall I think the approach is good. =20 > That's nice to hear. :-) > > /* > > + * Node Balancing > > + */ > > +#define CSCHED_BALANCE_NODE_AFFINITY 1 > > +#define CSCHED_BALANCE_CPU_AFFINITY 0 > > +#define CSCHED_BALANCE_START_STEP CSCHED_BALANCE_NODE_AFFINITY > > +#define CSCHED_BALANCE_END_STEP CSCHED_BALANCE_CPU_AFFINITY > > + > > + > This thing of defining "START_STEP" and "END_STEP" seems a bit fragile. = =20 > I think it would be better to always start at 0, and go until=20 > CSCHED_BALANCE_MAX. > Ok, I agree that this is fragile and probably also a bit overkill. I'll make it simpler as you're suggesting. > > + /* > > + * Let's cache domain's dom->node_affinity here as an > > + * optimization for a couple of hot paths. In fact, > > + * knowing whether or not dom->node_affinity has changed > > + * would allow us to avoid rebuilding node_affinity_cpumask > > + * (below) duing node balancing and/or scheduling. > > + */ > > + nodemask_t node_affinity_cache; > > + /* Basing on what dom->node_affinity says, > > + * on what CPUs would we like to run most? */ > > + cpumask_t node_affinity_cpumask; > I think the comments here need to be more clear. The main points are: > * node_affinity_cpumask is the dom->node_affinity translated from a=20 > nodemask into a cpumask > * Because doing the nodemask -> cpumask translation may be expensive,=20 > node_affinity_cache stores the last translated value, so we can avoid=20 > doing the translation if nothing has changed. >=20 Ok, will do. > > +/* > > + * Sort-of conversion between node-affinity and vcpu-affinity for the = domain, > > + * i.e., a cpumask containing all the cpus from all the set nodes in t= he > > + * node-affinity mask of the domain. > This needs to be clearer -- vcpu-affinity doesn't have anything to do=20 > with this function, and there's nothing "sort-of" about the conversion. := -) >=20 > I think you mean to say, "Create a cpumask from the node affinity mask." > Exactly, I'll try to clarify. > > static inline void > > +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask) > > +{ > > + CSCHED_STAT_CRANK(tickle_idlers_some); > > + if ( opt_tickle_one_idle ) > > + { > > + this_cpu(last_tickle_cpu) =3D > > + cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask); > > + cpumask_set_cpu(this_cpu(last_tickle_cpu), mask); > > + } > > + else > > + cpumask_or(mask, mask, idle_mask); > > +} > I don't see any reason to make this into a function -- it's only called= =20 > once, and it's not that long. Unless you're concerned about too many=20 > indentations making the lines too short? > That was part of it, but I'll put it back and see if I can have it looking good enough. :-) > > sdom->dom =3D dom; > > + /* > > + *XXX This would be 'The Right Thing', but as it is still too > > + * early and d->node_affinity has not settled yet, maybe we > > + * can just init the two masks with something like all-nodes > > + * and all-cpus and rely on the first balancing call for > > + * having them updated? > > + */ > > + csched_build_balance_cpumask(sdom); > We might as well do what you've got here, unless it's likely to produce= =20 > garbage. This isn't exactly a hot path. :-) >=20 Well, I won't call it garbage, so that's probably fine. I was concerned about be thing be clear and meaningful enough. Having this here could make us (and or future coders :-D) think that they can rely on the balance mask somehow, while that is not entirely true. I'll re-check the code and see how I can make it something better for next posting... > Other than that, looks good -- Thanks! >=20 Good to know, thanks to you! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-3n48E9qaqULvGKFci6NW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hTwIACgkQk4XaBE3IOsRNNQCfUIlnas4XtpqnUqw2WEOvRW/I Rf8An3EXgE+Pbp3A8g6SYbb887q5kviV =1Ao3 -----END PGP SIGNATURE----- --=-3n48E9qaqULvGKFci6NW-- --===============6757133835761434034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6757133835761434034==-- From xen-devel-bounces@lists.xen.org Wed May 02 15:25:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15: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 ) id 1SPbQu-0008Tl-54; Wed, 02 May 2012 15:25:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQs-0008Tb-Dv for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:25:34 +0000 Received: from [85.158.138.51:31008] by server-6.bemta-3.messagelabs.com id 1B/E6-05145-DE151AF4; Wed, 02 May 2012 15:25:33 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1335972331!24894587!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg4MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27098 invoked from network); 2 May 2012 15:25:32 -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; 2 May 2012 15:25:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="193045681" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:49 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-Au; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:21 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 2] libxl cleanup: distinguish filenames from sources X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:25:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15: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 ) id 1SPbQu-0008Tl-54; Wed, 02 May 2012 15:25:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQs-0008Tb-Dv for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:25:34 +0000 Received: from [85.158.138.51:31008] by server-6.bemta-3.messagelabs.com id 1B/E6-05145-DE151AF4; Wed, 02 May 2012 15:25:33 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1335972331!24894587!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg4MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27098 invoked from network); 2 May 2012 15:25:32 -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; 2 May 2012 15:25:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="193045681" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:49 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-Au; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:21 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 2] libxl cleanup: distinguish filenames from sources X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:25:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:25:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQv-0008Tu-HN; Wed, 02 May 2012 15:25:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQt-0008Tg-IZ for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:25:35 +0000 Received: from [85.158.138.51:31149] by server-9.bemta-3.messagelabs.com id D1/21-26691-EE151AF4; Wed, 02 May 2012 15:25:34 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1335972331!24894587!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg4MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27156 invoked from network); 2 May 2012 15:25:33 -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; 2 May 2012 15:25:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="193045682" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:50 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-Bt; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: 60013c9b8d62e39988db3c5b22c0510f5557756b Message-ID: <60013c9b8d62e39988db.1335971423@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:23 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User George Dunlap # Date 1335971129 -3600 # Node ID 60013c9b8d62e39988db3c5b22c0510f5557756b # Parent c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 xl: Make clear distinction between "filename" and "data source" Many places in xl there's a variable or element named "filename" which does not contain a filename, but the source of the data for reporting purposes. Worse, there are variables which are sometimes actually used or interpreted as a filename depending on what other variables are set. This makes it difficult to tell when a string is purely cosmetic, and when another bit of code may actually attempt to call "open" with the string. This patch makes a consistent distinction between "filename" (which always refers to the name of an actual file, and may be interpreted as such at some point) and "source" (which may be a filename, or may be another data source such as a migration stream or saved data). This does add some variables and reshuffle where assignments happen; most notably, the "restore_filename" element of struct domain_create is now only set when restoring from a file. But at a high level, there should be no funcitonal changes. Signed-off-by: George Dunlap diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Wed May 02 16:05:26 2012 +0100 +++ b/tools/libxl/libxl_utils.c Wed May 02 16:05:29 2012 +0100 @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx * \ int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \ constdata void *data, ssize_t sz, \ - const char *filename, const char *what) { \ + const char *source, const char *what) { \ ssize_t got; \ \ while (sz > 0) { \ @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx * if (errno == EINTR) continue; \ if (!ctx) return errno; \ LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \ - what?what:"", what?" from ":"", filename); \ + what?what:"", what?" from ":"", source); \ return errno; \ } \ if (got == 0) { \ @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx * zero_is_eof \ ? "file/stream truncated reading %s%s%s" \ : "file/stream write returned 0! writing %s%s%s", \ - what?what:"", what?" from ":"", filename); \ + what?what:"", what?" from ":"", source); \ return EPROTO; \ } \ sz -= got; \ diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed May 02 16:05:26 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 02 16:05:29 2012 +0100 @@ -520,9 +520,9 @@ vcpp_out: return rc; } -static void parse_config_data(const char *configfile_filename_report, - const char *configfile_data, - int configfile_len, +static void parse_config_data(const char *config_source, + const char *config_data, + int config_len, libxl_domain_config *d_config) { const char *buf; @@ -537,15 +537,15 @@ static void parse_config_data(const char libxl_domain_create_info *c_info = &d_config->c_info; libxl_domain_build_info *b_info = &d_config->b_info; - config= xlu_cfg_init(stderr, configfile_filename_report); + config= xlu_cfg_init(stderr, config_source); if (!config) { fprintf(stderr, "Failed to allocate for configuration\n"); exit(1); } - e= xlu_cfg_readdata(config, configfile_data, configfile_len); + e= xlu_cfg_readdata(config, config_data, config_len); if (e) { - fprintf(stderr, "Failed to parse config file: %s\n", strerror(e)); + fprintf(stderr, "Failed to parse config: %s\n", strerror(e)); exit(1); } @@ -1522,6 +1522,8 @@ static int create_domain(struct domain_c const char *config_file = dom_info->config_file; const char *extra_config = dom_info->extra_config; const char *restore_file = dom_info->restore_file; + const char *config_source = NULL; + const char *restore_source = NULL; int migrate_fd = dom_info->migrate_fd; int i; @@ -1537,24 +1539,28 @@ static int create_domain(struct domain_c pid_t child_console_pid = -1; struct save_file_header hdr; + int restoring = (restore_file || (migrate_fd >= 0)); + libxl_domain_config_init(&d_config); - if (restore_file) { + if (restoring) { uint8_t *optdata_begin = 0; const uint8_t *optdata_here = 0; union { uint32_t u32; char b[4]; } u32buf; uint32_t badflags; if (migrate_fd >= 0) { + restore_source = "" restore_fd = migrate_fd; } else { + restore_source = restore_file; restore_fd = open(restore_file, O_RDONLY); rc = libxl_fd_set_cloexec(ctx, restore_fd, 1); if (rc) return rc; } CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr, - sizeof(hdr), restore_file, "header") ); + sizeof(hdr), restore_source, "header") ); if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) { fprintf(stderr, "File has wrong magic number -" " corrupt or for a different tool?\n"); @@ -1567,7 +1573,7 @@ static int create_domain(struct domain_c fprintf(stderr, "Loading new save file %s" " (new xl fmt info" " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", - restore_file, hdr.mandatory_flags, hdr.optional_flags, + restore_source, hdr.mandatory_flags, hdr.optional_flags, hdr.optional_data_len); badflags = hdr.mandatory_flags & ~( 0 /* none understood yet */ ); @@ -1580,7 +1586,7 @@ static int create_domain(struct domain_c if (hdr.optional_data_len) { optdata_begin = xmalloc(hdr.optional_data_len); CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin, - hdr.optional_data_len, restore_file, "optdata") ); + hdr.optional_data_len, restore_source, "optdata") ); } #define OPTDATA_LEFT (hdr.optional_data_len - (optdata_here - optdata_begin)) @@ -1615,7 +1621,7 @@ static int create_domain(struct domain_c &config_data, &config_len); if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n", config_file, strerror(errno)); return ERROR_FAIL; } - if (!restore_file && extra_config && strlen(extra_config)) { + if (!restoring && extra_config && strlen(extra_config)) { if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) { fprintf(stderr, "Failed to attach extra configration\n"); return ERROR_FAIL; @@ -1630,19 +1636,20 @@ static int create_domain(struct domain_c config_len += sprintf(config_data + config_len, "\n%s\n", extra_config); } + config_source=config_file; } else { if (!config_data) { fprintf(stderr, "Config file not specified and" " none in save file\n"); return ERROR_INVAL; } - config_file = ""; + config_source = ""; } if (!dom_info->quiet) - printf("Parsing config file %s\n", config_file); - - parse_config_data(config_file, config_data, config_len, &d_config); + printf("Parsing config from %s\n", config_source); + + parse_config_data(config_source, config_data, config_len, &d_config); if (migrate_fd >= 0) { if (d_config.c_info.name) { @@ -1693,7 +1700,7 @@ start: cb = NULL; } - if ( restore_file ) { + if ( restoring ) { ret = libxl_domain_create_restore(ctx, &d_config, cb, &child_console_pid, &domid, restore_fd); @@ -2469,7 +2476,7 @@ static void list_domains_details(const l { libxl_domain_config d_config; - char *config_file; + char *config_source; uint8_t *data; int i, len, rc; @@ -2480,13 +2487,13 @@ static void list_domains_details(const l rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len); if (rc) continue; - CHK_ERRNO(asprintf(&config_file, "", info[i].domid)); + CHK_ERRNO(asprintf(&config_source, "", info[i].domid)); libxl_domain_config_init(&d_config); - parse_config_data(config_file, (char *)data, len, &d_config); + parse_config_data(config_source, (char *)data, len, &d_config); printf_info(default_output_format, info[i].domid, &d_config); libxl_domain_config_dispose(&d_config); free(data); - free(config_file); + free(config_source); } } @@ -2589,7 +2596,7 @@ static void save_domain_core_begin(const } } -static void save_domain_core_writeconfig(int fd, const char *filename, +static void save_domain_core_writeconfig(int fd, const char *source, const uint8_t *config_data, int config_len) { struct save_file_header hdr; @@ -2618,13 +2625,13 @@ static void save_domain_core_writeconfig /* that's the optional data */ CHK_ERRNO( libxl_write_exactly(ctx, fd, - &hdr, sizeof(hdr), filename, "header") ); + &hdr, sizeof(hdr), source, "header") ); CHK_ERRNO( libxl_write_exactly(ctx, fd, - optdata_begin, hdr.optional_data_len, filename, "header") ); + optdata_begin, hdr.optional_data_len, source, "header") ); fprintf(stderr, "Saving to %s new xl format (info" " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", - filename, hdr.mandatory_flags, hdr.optional_flags, + source, hdr.mandatory_flags, hdr.optional_flags, hdr.optional_data_len); } @@ -2950,7 +2957,6 @@ static void migrate_receive(int debug, i dom_info.daemonize = daemonize; dom_info.monitor = monitor; dom_info.paused = 1; - dom_info.restore_file = "incoming migration stream"; dom_info.migrate_fd = 0; /* stdin */ dom_info.migration_domname_r = &migration_domname; dom_info.incr_generationid = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:25:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:25:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQv-0008Tu-HN; Wed, 02 May 2012 15:25:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbQt-0008Tg-IZ for xen-devel@lists.xensource.com; Wed, 02 May 2012 15:25:35 +0000 Received: from [85.158.138.51:31149] by server-9.bemta-3.messagelabs.com id D1/21-26691-EE151AF4; Wed, 02 May 2012 15:25:34 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1335972331!24894587!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDg4MTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27156 invoked from network); 2 May 2012 15:25:33 -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; 2 May 2012 15:25:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330923600"; d="scan'208";a="193045682" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 11:12:50 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 11:12:49 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPbEX-0001gf-Bt; Wed, 02 May 2012 16:12:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: 60013c9b8d62e39988db3c5b22c0510f5557756b Message-ID: <60013c9b8d62e39988db.1335971423@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 2 May 2012 16:10:23 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User George Dunlap # Date 1335971129 -3600 # Node ID 60013c9b8d62e39988db3c5b22c0510f5557756b # Parent c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 xl: Make clear distinction between "filename" and "data source" Many places in xl there's a variable or element named "filename" which does not contain a filename, but the source of the data for reporting purposes. Worse, there are variables which are sometimes actually used or interpreted as a filename depending on what other variables are set. This makes it difficult to tell when a string is purely cosmetic, and when another bit of code may actually attempt to call "open" with the string. This patch makes a consistent distinction between "filename" (which always refers to the name of an actual file, and may be interpreted as such at some point) and "source" (which may be a filename, or may be another data source such as a migration stream or saved data). This does add some variables and reshuffle where assignments happen; most notably, the "restore_filename" element of struct domain_create is now only set when restoring from a file. But at a high level, there should be no funcitonal changes. Signed-off-by: George Dunlap diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Wed May 02 16:05:26 2012 +0100 +++ b/tools/libxl/libxl_utils.c Wed May 02 16:05:29 2012 +0100 @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx * \ int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \ constdata void *data, ssize_t sz, \ - const char *filename, const char *what) { \ + const char *source, const char *what) { \ ssize_t got; \ \ while (sz > 0) { \ @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx * if (errno == EINTR) continue; \ if (!ctx) return errno; \ LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to " #rw " %s%s%s", \ - what?what:"", what?" from ":"", filename); \ + what?what:"", what?" from ":"", source); \ return errno; \ } \ if (got == 0) { \ @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx * zero_is_eof \ ? "file/stream truncated reading %s%s%s" \ : "file/stream write returned 0! writing %s%s%s", \ - what?what:"", what?" from ":"", filename); \ + what?what:"", what?" from ":"", source); \ return EPROTO; \ } \ sz -= got; \ diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed May 02 16:05:26 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 02 16:05:29 2012 +0100 @@ -520,9 +520,9 @@ vcpp_out: return rc; } -static void parse_config_data(const char *configfile_filename_report, - const char *configfile_data, - int configfile_len, +static void parse_config_data(const char *config_source, + const char *config_data, + int config_len, libxl_domain_config *d_config) { const char *buf; @@ -537,15 +537,15 @@ static void parse_config_data(const char libxl_domain_create_info *c_info = &d_config->c_info; libxl_domain_build_info *b_info = &d_config->b_info; - config= xlu_cfg_init(stderr, configfile_filename_report); + config= xlu_cfg_init(stderr, config_source); if (!config) { fprintf(stderr, "Failed to allocate for configuration\n"); exit(1); } - e= xlu_cfg_readdata(config, configfile_data, configfile_len); + e= xlu_cfg_readdata(config, config_data, config_len); if (e) { - fprintf(stderr, "Failed to parse config file: %s\n", strerror(e)); + fprintf(stderr, "Failed to parse config: %s\n", strerror(e)); exit(1); } @@ -1522,6 +1522,8 @@ static int create_domain(struct domain_c const char *config_file = dom_info->config_file; const char *extra_config = dom_info->extra_config; const char *restore_file = dom_info->restore_file; + const char *config_source = NULL; + const char *restore_source = NULL; int migrate_fd = dom_info->migrate_fd; int i; @@ -1537,24 +1539,28 @@ static int create_domain(struct domain_c pid_t child_console_pid = -1; struct save_file_header hdr; + int restoring = (restore_file || (migrate_fd >= 0)); + libxl_domain_config_init(&d_config); - if (restore_file) { + if (restoring) { uint8_t *optdata_begin = 0; const uint8_t *optdata_here = 0; union { uint32_t u32; char b[4]; } u32buf; uint32_t badflags; if (migrate_fd >= 0) { + restore_source = "" restore_fd = migrate_fd; } else { + restore_source = restore_file; restore_fd = open(restore_file, O_RDONLY); rc = libxl_fd_set_cloexec(ctx, restore_fd, 1); if (rc) return rc; } CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr, - sizeof(hdr), restore_file, "header") ); + sizeof(hdr), restore_source, "header") ); if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.magic))) { fprintf(stderr, "File has wrong magic number -" " corrupt or for a different tool?\n"); @@ -1567,7 +1573,7 @@ static int create_domain(struct domain_c fprintf(stderr, "Loading new save file %s" " (new xl fmt info" " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", - restore_file, hdr.mandatory_flags, hdr.optional_flags, + restore_source, hdr.mandatory_flags, hdr.optional_flags, hdr.optional_data_len); badflags = hdr.mandatory_flags & ~( 0 /* none understood yet */ ); @@ -1580,7 +1586,7 @@ static int create_domain(struct domain_c if (hdr.optional_data_len) { optdata_begin = xmalloc(hdr.optional_data_len); CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, optdata_begin, - hdr.optional_data_len, restore_file, "optdata") ); + hdr.optional_data_len, restore_source, "optdata") ); } #define OPTDATA_LEFT (hdr.optional_data_len - (optdata_here - optdata_begin)) @@ -1615,7 +1621,7 @@ static int create_domain(struct domain_c &config_data, &config_len); if (ret) { fprintf(stderr, "Failed to read config file: %s: %s\n", config_file, strerror(errno)); return ERROR_FAIL; } - if (!restore_file && extra_config && strlen(extra_config)) { + if (!restoring && extra_config && strlen(extra_config)) { if (config_len > INT_MAX - (strlen(extra_config) + 2 + 1)) { fprintf(stderr, "Failed to attach extra configration\n"); return ERROR_FAIL; @@ -1630,19 +1636,20 @@ static int create_domain(struct domain_c config_len += sprintf(config_data + config_len, "\n%s\n", extra_config); } + config_source=config_file; } else { if (!config_data) { fprintf(stderr, "Config file not specified and" " none in save file\n"); return ERROR_INVAL; } - config_file = ""; + config_source = ""; } if (!dom_info->quiet) - printf("Parsing config file %s\n", config_file); - - parse_config_data(config_file, config_data, config_len, &d_config); + printf("Parsing config from %s\n", config_source); + + parse_config_data(config_source, config_data, config_len, &d_config); if (migrate_fd >= 0) { if (d_config.c_info.name) { @@ -1693,7 +1700,7 @@ start: cb = NULL; } - if ( restore_file ) { + if ( restoring ) { ret = libxl_domain_create_restore(ctx, &d_config, cb, &child_console_pid, &domid, restore_fd); @@ -2469,7 +2476,7 @@ static void list_domains_details(const l { libxl_domain_config d_config; - char *config_file; + char *config_source; uint8_t *data; int i, len, rc; @@ -2480,13 +2487,13 @@ static void list_domains_details(const l rc = libxl_userdata_retrieve(ctx, info[i].domid, "xl", &data, &len); if (rc) continue; - CHK_ERRNO(asprintf(&config_file, "", info[i].domid)); + CHK_ERRNO(asprintf(&config_source, "", info[i].domid)); libxl_domain_config_init(&d_config); - parse_config_data(config_file, (char *)data, len, &d_config); + parse_config_data(config_source, (char *)data, len, &d_config); printf_info(default_output_format, info[i].domid, &d_config); libxl_domain_config_dispose(&d_config); free(data); - free(config_file); + free(config_source); } } @@ -2589,7 +2596,7 @@ static void save_domain_core_begin(const } } -static void save_domain_core_writeconfig(int fd, const char *filename, +static void save_domain_core_writeconfig(int fd, const char *source, const uint8_t *config_data, int config_len) { struct save_file_header hdr; @@ -2618,13 +2625,13 @@ static void save_domain_core_writeconfig /* that's the optional data */ CHK_ERRNO( libxl_write_exactly(ctx, fd, - &hdr, sizeof(hdr), filename, "header") ); + &hdr, sizeof(hdr), source, "header") ); CHK_ERRNO( libxl_write_exactly(ctx, fd, - optdata_begin, hdr.optional_data_len, filename, "header") ); + optdata_begin, hdr.optional_data_len, source, "header") ); fprintf(stderr, "Saving to %s new xl format (info" " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", - filename, hdr.mandatory_flags, hdr.optional_flags, + source, hdr.mandatory_flags, hdr.optional_flags, hdr.optional_data_len); } @@ -2950,7 +2957,6 @@ static void migrate_receive(int debug, i dom_info.daemonize = daemonize; dom_info.monitor = monitor; dom_info.paused = 1; - dom_info.restore_file = "incoming migration stream"; dom_info.migrate_fd = 0; /* stdin */ dom_info.migration_domname_r = &migration_domname; dom_info.incr_generationid = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:30:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:30:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbVZ-0000Eg-9T; Wed, 02 May 2012 15:30:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbVX-0000EX-LK for xen-devel@lists.xen.org; Wed, 02 May 2012 15:30:23 +0000 Received: from [85.158.138.51:16420] by server-6.bemta-3.messagelabs.com id B1/F0-05145-E0351AF4; Wed, 02 May 2012 15:30:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1335972621!18482943!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22941 invoked from network); 2 May 2012 15:30:21 -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; 2 May 2012 15:30:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12252901" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 15:30:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 16:30:20 +0100 Message-ID: <1335972619.26758.67.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Wed, 2 May 2012 16:30:19 +0100 In-Reply-To: <1335970965.2961.51.camel@Abyss> References: <1335272011.4347.108.camel@zakaz.uk.xensource.com> <1335970965.2961.51.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 Release Plan / TODO X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 16:02 +0100, Dario Faggioli wrote: > [...] > Therefore, I'm officially proposing to add "automatic NUMA placement and > vcpu pinning in xl" here below: > > > tools, blockers: > > ... > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > > reported by Fabio Fantoni in > > <4F9672DD.2080902@tiscali.it> > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter has posted a patch. > * does not automatically try to select a (set of) > node(s) on which to create a VM and pin its vcpus > there. > > The strong case I'm making is that not having this is a regression wrt > default xend behaviour, and it could upset and break stuff for people > expecting the toolstack tacking care about NUMA, at least in some rough > way (which btw is what xend is doing). > > I'm not far from having the patches so, if the proposal is accepted, I > can post them next week, I'm quite sure. > > Thoughts? I think this is a reasonable thing to accept for 4.2. BTW, I missed my regular TODO list update this week. Since it is now Wednesday I'm not going to bother this week and will pick up again on Tuesday (Monday is a UK public holiday). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 15:30:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 15:30:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbVZ-0000Eg-9T; Wed, 02 May 2012 15:30:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPbVX-0000EX-LK for xen-devel@lists.xen.org; Wed, 02 May 2012 15:30:23 +0000 Received: from [85.158.138.51:16420] by server-6.bemta-3.messagelabs.com id B1/F0-05145-E0351AF4; Wed, 02 May 2012 15:30:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1335972621!18482943!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22941 invoked from network); 2 May 2012 15:30:21 -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; 2 May 2012 15:30:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="12252901" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 15:30:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 16:30:20 +0100 Message-ID: <1335972619.26758.67.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Wed, 2 May 2012 16:30:19 +0100 In-Reply-To: <1335970965.2961.51.camel@Abyss> References: <1335272011.4347.108.camel@zakaz.uk.xensource.com> <1335970965.2961.51.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 Release Plan / TODO X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 16:02 +0100, Dario Faggioli wrote: > [...] > Therefore, I'm officially proposing to add "automatic NUMA placement and > vcpu pinning in xl" here below: > > > tools, blockers: > > ... > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > > reported by Fabio Fantoni in > > <4F9672DD.2080902@tiscali.it> > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter has posted a patch. > * does not automatically try to select a (set of) > node(s) on which to create a VM and pin its vcpus > there. > > The strong case I'm making is that not having this is a regression wrt > default xend behaviour, and it could upset and break stuff for people > expecting the toolstack tacking care about NUMA, at least in some rough > way (which btw is what xend is doing). > > I'm not far from having the patches so, if the proposal is accepted, I > can post them next week, I'm quite sure. > > Thoughts? I think this is a reasonable thing to accept for 4.2. BTW, I missed my regular TODO list update this week. Since it is now Wednesday I'm not going to bother this week and will pick up again on Tuesday (Monday is a UK public holiday). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 16:14:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 16:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcBp-000108-V5; Wed, 02 May 2012 16:14:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcBp-000103-0a for xen-devel@lists.xensource.com; Wed, 02 May 2012 16:14:05 +0000 Received: from [85.158.143.35:8442] by server-1.bemta-4.messagelabs.com id 05/34-20925-C4D51AF4; Wed, 02 May 2012 16:14:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335975241!13898608!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3975 invoked from network); 2 May 2012 16:14:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 16:14:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42GDsEA016427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 16:13:55 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 q42GDswa007445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 16:13:54 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 q42GDrNO013447; Wed, 2 May 2012 11:13:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 09:13:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 84D3240357; Wed, 2 May 2012 12:08:12 -0400 (EDT) Date: Wed, 2 May 2012 12:08:12 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120502160812.GA6611@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA14C2C.5030104@canonical.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 05:01:00PM +0200, Stefan Bader wrote: > On 02.05.2012 00:35, Boris Ostrovsky wrote: > > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >>>>> Since there have been requests about that driver to get backported into 3.2, I > >>>>> was interested to find out what or how much would be gained by that. > >>>>> > >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). > >>>>> Which > >>>>> was not very successful as the drivers bail out of the init function > >>>>> because the > >>>>> first call to acpi_processor_register_performance() returns -ENODEV. There is > >>>>> some frequency scaling when running without Xen, so I need to do some more > >>>>> debugging there. > > > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > > > static u32 xen_apic_read(u32 reg) > > { > > return 0; > > } > > > > This results in some data, most importantly boot_cpu_physical_apicid, not being > > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. > > > > On larger AMD systems boot processor is typically APICID=0x20 (I don't have > > Intel system handy to see how it looks there). > > > > As a quick and dirty test you can try: > > > > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > > index edc2448..1f78998 100644 > > --- a/arch/x86/kernel/apic/apic.c > > +++ b/arch/x86/kernel/apic/apic.c > > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long address) > > } > > if (boot_cpu_physical_apicid == -1U) { > > boot_cpu_physical_apicid = read_apic_id(); > > + boot_cpu_physical_apicid = 32; > > apic_version[boot_cpu_physical_apicid] = > > GET_APIC_VERSION(apic_read(APIC_LVR)); > > } > > > > > > (Set it to whatever APICID on core0 is, I suspect it won't be zero). > > > > Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most of the BIOS > bug messages are gone and the xen-acpi-processor driver successfully loads and > seems to be switching frequencies ok (just a quick tight loop which made one cpu > go from P4 to P0). OK. Can you try the attached patch pls? It should do the same thing as what the debug patch does - get the _real_ APIC ID from the hypervisor. (And as bonus it also removes the annoying: BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..d816448 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -811,7 +811,29 @@ static void xen_io_delay(void) #ifdef CONFIG_X86_LOCAL_APIC static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id; } static void xen_apic_write(u32 reg, u32 val) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 16:14:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 16:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcBp-000108-V5; Wed, 02 May 2012 16:14:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcBp-000103-0a for xen-devel@lists.xensource.com; Wed, 02 May 2012 16:14:05 +0000 Received: from [85.158.143.35:8442] by server-1.bemta-4.messagelabs.com id 05/34-20925-C4D51AF4; Wed, 02 May 2012 16:14:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335975241!13898608!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3975 invoked from network); 2 May 2012 16:14:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 16:14:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42GDsEA016427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 16:13:55 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 q42GDswa007445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 16:13:54 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 q42GDrNO013447; Wed, 2 May 2012 11:13:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 09:13:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 84D3240357; Wed, 2 May 2012 12:08:12 -0400 (EDT) Date: Wed, 2 May 2012 12:08:12 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120502160812.GA6611@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA14C2C.5030104@canonical.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 05:01:00PM +0200, Stefan Bader wrote: > On 02.05.2012 00:35, Boris Ostrovsky wrote: > > On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: > >> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: > >>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: > >>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: > >>>>> Since there have been requests about that driver to get backported into 3.2, I > >>>>> was interested to find out what or how much would be gained by that. > >>>>> > >>>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). > >>>>> Which > >>>>> was not very successful as the drivers bail out of the init function > >>>>> because the > >>>>> first call to acpi_processor_register_performance() returns -ENODEV. There is > >>>>> some frequency scaling when running without Xen, so I need to do some more > >>>>> debugging there. > > > > I believe this is caused by the somewhat under-enlightened xen_apic_read(): > > > > static u32 xen_apic_read(u32 reg) > > { > > return 0; > > } > > > > This results in some data, most importantly boot_cpu_physical_apicid, not being > > set correctly and, in turn, causes x86_cpu_to_apicid to be broken. > > > > On larger AMD systems boot processor is typically APICID=0x20 (I don't have > > Intel system handy to see how it looks there). > > > > As a quick and dirty test you can try: > > > > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > > index edc2448..1f78998 100644 > > --- a/arch/x86/kernel/apic/apic.c > > +++ b/arch/x86/kernel/apic/apic.c > > @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned long address) > > } > > if (boot_cpu_physical_apicid == -1U) { > > boot_cpu_physical_apicid = read_apic_id(); > > + boot_cpu_physical_apicid = 32; > > apic_version[boot_cpu_physical_apicid] = > > GET_APIC_VERSION(apic_read(APIC_LVR)); > > } > > > > > > (Set it to whatever APICID on core0 is, I suspect it won't be zero). > > > > Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most of the BIOS > bug messages are gone and the xen-acpi-processor driver successfully loads and > seems to be switching frequencies ok (just a quick tight loop which made one cpu > go from P4 to P0). OK. Can you try the attached patch pls? It should do the same thing as what the debug patch does - get the _real_ APIC ID from the hypervisor. (And as bonus it also removes the annoying: BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..d816448 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -811,7 +811,29 @@ static void xen_io_delay(void) #ifdef CONFIG_X86_LOCAL_APIC static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id; } static void xen_apic_write(u32 reg, u32 val) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 16:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 16:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcSP-0001Bf-Ge; Wed, 02 May 2012 16:31:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcSM-0001BX-73 for xen-devel@lists.xen.org; Wed, 02 May 2012 16:31:11 +0000 Received: from [193.109.254.147:30100] by server-9.bemta-14.messagelabs.com id C9/DE-05787-D4161AF4; Wed, 02 May 2012 16:31:09 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-5.tower-27.messagelabs.com!1335976258!4882192!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16893 invoked from network); 2 May 2012 16:30:59 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-5.tower-27.messagelabs.com with SMTP; 2 May 2012 16:30:59 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77554134; Wed, 02 May 2012 18:30:57 +0200 Message-ID: <1335976251.2961.123.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Wed, 02 May 2012 18:30:51 +0200 In-Reply-To: <4FA0051F.6020909@eu.citrix.com> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6837791055166636165==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6837791055166636165== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VITkHo9S8QdJpmzIjUfZ" --=-VITkHo9S8QdJpmzIjUfZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-05-01 at 16:45 +0100, George Dunlap wrote:=20 > Hey Dario, >=20 Hi again, > Thanks for the work on this -- this is obviously a very complicated area= =20 > to try to make sense of. Of course, that makes it even more complicated= =20 > to review -- sorry this has taken so long. (comments inline) > Again, no problem at all! > > + > > +=3Ditem B > > + > > +use a not better specified (xl-implementation dependant) algorithm > > +to try automatically fitting the guest on the host's NUMA nodes > Uum, you mean, "Use the default placement algorithm"? :-) We should=20 > specify which one this will be here. > > + > > +/* Automatic placement policies symbols, with the following meaning: > > + * NONE : no automatic placement at all; > > + * STATIC : explicit nodes specification. > > + * FFIT : use the First Fit algorithm for automatic placement; > > + * AUTO : an not better specified automatic placement, likely > > + * to be implemented as a short circuit to (one of) > > + * the above(s); > > + */ > > +#define NODES_POLICY_NONE 0 > > +#define NODES_POLICY_STATIC 1 > > +#define NODES_POLICY_FFIT 2 > > +#define NODES_POLICY_AUTO 3 > This is minor, but it seems like "auto" should be 1, so if we add=20 > another policy, the policies are all together, without having to move=20 > AUTO around every time. > Ok, I'll reorganize this bit to be more sensible, which also includes changing the names of the policies and some others cleanups. > > + > > +/* Store the policy for the domain while parsing */ > > +static int nodes_policy =3D NODES_POLICY_DEFAULT; > > + > > +/* Store the number of nodes to be used while parsing */ > > +static int num_nodes_policy =3D 0; > Why are "nodes_policy" and "num_nodes_policy" not passed in along with= =20 > b_info? > That was my first implementation. Then I figured out that I want to do the placement in _xl_, not in _libxl_, so I really don't need to muck up build info with placement related stuff. Should I use b_info anyway, even if I don't need these fields while in libxl? > > +static int nodes_policy_parse(const char *pol, long int *policy) > > +{ > > + int i; > > + const char *n; > > + > > + for (i =3D 0; i< sizeof(nodes_policy_names) / sizeof(nodes_policy= _names[0]); i++) { > I personally prefer an explicit NODES_POLICY_MAX, but I'll let the libxl= =20 > maintainers decide on that. > Sounds definitely nicer. I just did it like that because I found a very similar example in xl itself, but I'm open about changing this to whatever you and libxl maintainers reach a consensus on. :-) > > + > > + /* Determine how much free memory we want on each of the nodes > > + * that will end up in suitable_nodes. Either adding or ignori= ng > > + * the modulus of the integer division should be fine (the tot= al > > + * number of nodes should be in the order of tens of them), so > > + * let's add it as it should be more safe. > > + */ > > + memb_node =3D (memb / (*nodes)) + (memb % (*nodes)); > Wouldn't it just be easier to do a "round-up" function here, like this: > memb_node =3D ( (memb + *nodes -1) / (*nodes) ) >=20 Yep, it probably is, thanks. :-) > Also, is it really necessary for a VM to have an equal amount of memory= =20 > on every node? It seems like it would be better to have 75% on one node= =20 > and 25% on a second node than to have 25% on four nodes, for example. = =20 > Furthermore, insisting on an even amount fragments the node memory=20 > further -- i.e., if we chose to have 25% on four nodes instead of 75% on= =20 > one and 25% on another, that will make it harder for another VM to fit= =20 > on a single node as well. >=20 Ok, that is something quite important to discuss. What you propose makes a lot of sense, although some issues comes to my mind: - which percent should I try, and in what order? I mean, 75%/25% sounds reasonable, but maybe also 80%/20% or even 60%/40% helps your=20 point. So, should I just decide an asymmetrical layout and try it=20 (instead of 50%/50%) or do you have some sort of "trial and error" approach, with different layouts being attempted one after the other, in mind? The problem is very complex and finding a (good) solution will easily start depending on which layout we try first, in which order we try the other ones (if at all) and on the free memory we have on the various nodes... We can probably state it as an integer optimization problem, but I'm not sure we want to put a GLPK (GNU Linear Programming Kit) solver within xl! :-O - suppose I go for 75%/25%, what about the scheduling oof the VM?=20 Right now, with 50%/50% I can set node affinity to both the nodes and rest ensured things won't be that bad. I'll be getting something in the middle between best and worst performances, as the benchmarks show. Doing the same with 75%/25% means I can be instructing the scheduler to run the VM on a node where it has far fewer probability of accessing local memory than the other one. OTOH, if setting node affinity to just the node with 75% of the mem, I'm risking always generating 25% of remote accesses, which will keep us apart from the best case performance, isn't it? - what about the asymmetrical layout of choice (let's stick to 75%/25%) does not fit anywhere and I really need one more (or one less) node... I mean, how do I partition memory in that case? Please, don't get me wrong, I see your point and really think it makes sense. I've actually thought along the same line for a while, but then I couldn't find an answers to the questions above. That's why, kind of falling back with Xen's default "striped" approach (although on as less nodes as possible, which is _much_ better than the actual Xen's default!). It looked simple enough to write, read and understand, while still providing statistically consistent performances. If we, together, manage in sorting out the issues, I'm all for asymmetrical placement myself! :-D > The need for NODES_POLICY_RETRY_DEC is an artifact of the above; if=20 > nodes were allowed to be assymetric, you wouldn't need to *decrease* the= =20 > number of nodes to find *more* memory. > I agree, let's try figure out how we think the heuristics should look like, ok? That being done, I'll be happy to kill RETRY_DEC if it turns out to be useless! :-P > > + /* Apply the asked retry policy for the next round. Notice > > + * that it would be pointless to increase nodes without also > > + * adding some nodes to the map! */ > > + *nodes +=3D retry; > > + if (retry =3D=3D NODES_POLICY_RETRY_INC) > > + __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry); > Hmm -- if I'm reading this right, the only time the nodemap won't be all= =20 > nodes is if (1) the user specified nodes, or (2) there's a cpumask in=20 > effect. If we're going to override that setting, wouldn't it make sense= =20 > to just expand to all numa nodes? >=20 As you wish, the whole "what to do if what I've been provided with doesn't work" is in the *wild guess* status, meaning I tried to figure out what would be best to do, but I might well be far from the actual correct solution, provided there is one. Trying to enlarge the nodemap step by step is potentially yielding better performances, but is probably not so near to the "least surprise" principle one should use when designing UIs. :-( > Hmm -- though I suppose what you'd really want to try is adding each=20 > node in turn, rather than one at a time (i.e., if the cpus are pinned to= =20 > nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before=20 > trying [1,2,3,4]. =20 > Yep, that makes a real lot of sense, thanks! I can definitely try doing that, although it will complicate the code a bit... > But that's starting to get really complicated -- I=20 > wonder if it's better to just fail and let the user change the pinnings= =20 > / configuration node mapping. > Well, that will probably be the least surprising behaviour. Again, just let me know what you think it's best among the various alternatives and I'll go for it. > > + > > + if (use_cpus>=3D b_info->max_vcpus) { > > + rc =3D 0; > > + break; > > + } > Hmm -- there's got to be a better way to find out the minimum number of= =20 > nodes to house a given number of vcpus than just starting at 1 and=20 > re-trying until we have enough. > > + /* Add one more node and retry fitting the domain */ > > + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); > Same comment as above. > I'm not sure I'm getting this. The whole point here is let's consider free memory on the various nodes first, and then adjust the result if some other constraints are being violated. However, if what you mean is I could check beforehand whether or not the user provided configuration will give us enough CPUs and avoid testing scenarios that are guaranteed to fail, then I agree and I'll reshape the code to look like that. This triggers the heuristics re-designing stuff from above again, as one have to decide what to do if user asks for "nodes=3D[1,3]" and I discover (earlier) that I need one more node for having enough CPUs (I mean, what node should I try first?). > > > > + ret =3D place_domain(&d_config.b_info); > > + if (ret =3D=3D ESRCH || ret =3D=3D ENOSPC) { > > + fprintf(stderr, "failed to place the domain, fallback to all n= odes\n"); > > + libxl_nodemap_set_any(&d_config.b_info.nodemap); > Hmm -- is this the right fallback? I think in general, if the user asks= =20 > for X to be done, and X cannot be done for whatever reason, the right=20 > thing is to tell the user that X cannot be done and let them sort it=20 > out, rather than resorting to Y (unless that's been set). >=20 I agree and I will go for this. > Is it the case that if any node placement fails, then they'll all fail? = =20 > Or to put it the other way, is it the case that if there is *some*=20 > placement, that any placement algorithm will eventually find it? If so,= =20 > then I think this fallback may make sense, as there's nothing for the=20 > user to really do. > Well, that's tricky. I mean, if we were only talking about fitting all the VM's memory on one single node, then yes, no matter how you order the list of nodes, if there is at least one with enough space for the VM, you'll find it. However, we might be dealing with "fit the VM in multiple nodes" scenarios, which is a completely different thing, and changing the number of nodes onto which you're trying to fit the VM will change pretty much everything. So, I'm not entirely sure I answered your question but the point is your idea above is the best one: if you ask something and we don't manage in getting it done, just stop and let you figure things out. I've only one question about this approach, what if the automatic placement is/becomes the default? I mean, avoiding any kind of fallback (which again, makes sense to me in case the user is explicitly asking something specific) would mean a completely NUMA-unaware VM creation can be aborted even if the user did not say anything... How do we deal with this? > > diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c > > --- a/xen/arch/x86/numa.c > > +++ b/xen/arch/x86/numa.c > > ... > >=20 > This should be in its own patch. >=20 Ok. Thanks lot again for taking a look! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-VITkHo9S8QdJpmzIjUfZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hYTsACgkQk4XaBE3IOsQcaQCeOwhFzvuKoNeM2IXEgAhh9TNC 7CoAn3AnzYx4y7K/bzJf1GskruO6Ygaq =etUB -----END PGP SIGNATURE----- --=-VITkHo9S8QdJpmzIjUfZ-- --===============6837791055166636165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6837791055166636165==-- From xen-devel-bounces@lists.xen.org Wed May 02 16:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 16:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcSP-0001Bf-Ge; Wed, 02 May 2012 16:31:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcSM-0001BX-73 for xen-devel@lists.xen.org; Wed, 02 May 2012 16:31:11 +0000 Received: from [193.109.254.147:30100] by server-9.bemta-14.messagelabs.com id C9/DE-05787-D4161AF4; Wed, 02 May 2012 16:31:09 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-5.tower-27.messagelabs.com!1335976258!4882192!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16893 invoked from network); 2 May 2012 16:30:59 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-5.tower-27.messagelabs.com with SMTP; 2 May 2012 16:30:59 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77554134; Wed, 02 May 2012 18:30:57 +0200 Message-ID: <1335976251.2961.123.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Wed, 02 May 2012 18:30:51 +0200 In-Reply-To: <4FA0051F.6020909@eu.citrix.com> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6837791055166636165==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6837791055166636165== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VITkHo9S8QdJpmzIjUfZ" --=-VITkHo9S8QdJpmzIjUfZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-05-01 at 16:45 +0100, George Dunlap wrote:=20 > Hey Dario, >=20 Hi again, > Thanks for the work on this -- this is obviously a very complicated area= =20 > to try to make sense of. Of course, that makes it even more complicated= =20 > to review -- sorry this has taken so long. (comments inline) > Again, no problem at all! > > + > > +=3Ditem B > > + > > +use a not better specified (xl-implementation dependant) algorithm > > +to try automatically fitting the guest on the host's NUMA nodes > Uum, you mean, "Use the default placement algorithm"? :-) We should=20 > specify which one this will be here. > > + > > +/* Automatic placement policies symbols, with the following meaning: > > + * NONE : no automatic placement at all; > > + * STATIC : explicit nodes specification. > > + * FFIT : use the First Fit algorithm for automatic placement; > > + * AUTO : an not better specified automatic placement, likely > > + * to be implemented as a short circuit to (one of) > > + * the above(s); > > + */ > > +#define NODES_POLICY_NONE 0 > > +#define NODES_POLICY_STATIC 1 > > +#define NODES_POLICY_FFIT 2 > > +#define NODES_POLICY_AUTO 3 > This is minor, but it seems like "auto" should be 1, so if we add=20 > another policy, the policies are all together, without having to move=20 > AUTO around every time. > Ok, I'll reorganize this bit to be more sensible, which also includes changing the names of the policies and some others cleanups. > > + > > +/* Store the policy for the domain while parsing */ > > +static int nodes_policy =3D NODES_POLICY_DEFAULT; > > + > > +/* Store the number of nodes to be used while parsing */ > > +static int num_nodes_policy =3D 0; > Why are "nodes_policy" and "num_nodes_policy" not passed in along with= =20 > b_info? > That was my first implementation. Then I figured out that I want to do the placement in _xl_, not in _libxl_, so I really don't need to muck up build info with placement related stuff. Should I use b_info anyway, even if I don't need these fields while in libxl? > > +static int nodes_policy_parse(const char *pol, long int *policy) > > +{ > > + int i; > > + const char *n; > > + > > + for (i =3D 0; i< sizeof(nodes_policy_names) / sizeof(nodes_policy= _names[0]); i++) { > I personally prefer an explicit NODES_POLICY_MAX, but I'll let the libxl= =20 > maintainers decide on that. > Sounds definitely nicer. I just did it like that because I found a very similar example in xl itself, but I'm open about changing this to whatever you and libxl maintainers reach a consensus on. :-) > > + > > + /* Determine how much free memory we want on each of the nodes > > + * that will end up in suitable_nodes. Either adding or ignori= ng > > + * the modulus of the integer division should be fine (the tot= al > > + * number of nodes should be in the order of tens of them), so > > + * let's add it as it should be more safe. > > + */ > > + memb_node =3D (memb / (*nodes)) + (memb % (*nodes)); > Wouldn't it just be easier to do a "round-up" function here, like this: > memb_node =3D ( (memb + *nodes -1) / (*nodes) ) >=20 Yep, it probably is, thanks. :-) > Also, is it really necessary for a VM to have an equal amount of memory= =20 > on every node? It seems like it would be better to have 75% on one node= =20 > and 25% on a second node than to have 25% on four nodes, for example. = =20 > Furthermore, insisting on an even amount fragments the node memory=20 > further -- i.e., if we chose to have 25% on four nodes instead of 75% on= =20 > one and 25% on another, that will make it harder for another VM to fit= =20 > on a single node as well. >=20 Ok, that is something quite important to discuss. What you propose makes a lot of sense, although some issues comes to my mind: - which percent should I try, and in what order? I mean, 75%/25% sounds reasonable, but maybe also 80%/20% or even 60%/40% helps your=20 point. So, should I just decide an asymmetrical layout and try it=20 (instead of 50%/50%) or do you have some sort of "trial and error" approach, with different layouts being attempted one after the other, in mind? The problem is very complex and finding a (good) solution will easily start depending on which layout we try first, in which order we try the other ones (if at all) and on the free memory we have on the various nodes... We can probably state it as an integer optimization problem, but I'm not sure we want to put a GLPK (GNU Linear Programming Kit) solver within xl! :-O - suppose I go for 75%/25%, what about the scheduling oof the VM?=20 Right now, with 50%/50% I can set node affinity to both the nodes and rest ensured things won't be that bad. I'll be getting something in the middle between best and worst performances, as the benchmarks show. Doing the same with 75%/25% means I can be instructing the scheduler to run the VM on a node where it has far fewer probability of accessing local memory than the other one. OTOH, if setting node affinity to just the node with 75% of the mem, I'm risking always generating 25% of remote accesses, which will keep us apart from the best case performance, isn't it? - what about the asymmetrical layout of choice (let's stick to 75%/25%) does not fit anywhere and I really need one more (or one less) node... I mean, how do I partition memory in that case? Please, don't get me wrong, I see your point and really think it makes sense. I've actually thought along the same line for a while, but then I couldn't find an answers to the questions above. That's why, kind of falling back with Xen's default "striped" approach (although on as less nodes as possible, which is _much_ better than the actual Xen's default!). It looked simple enough to write, read and understand, while still providing statistically consistent performances. If we, together, manage in sorting out the issues, I'm all for asymmetrical placement myself! :-D > The need for NODES_POLICY_RETRY_DEC is an artifact of the above; if=20 > nodes were allowed to be assymetric, you wouldn't need to *decrease* the= =20 > number of nodes to find *more* memory. > I agree, let's try figure out how we think the heuristics should look like, ok? That being done, I'll be happy to kill RETRY_DEC if it turns out to be useless! :-P > > + /* Apply the asked retry policy for the next round. Notice > > + * that it would be pointless to increase nodes without also > > + * adding some nodes to the map! */ > > + *nodes +=3D retry; > > + if (retry =3D=3D NODES_POLICY_RETRY_INC) > > + __add_nodes_to_nodemap(nodemap, numa, nr_nodes, retry); > Hmm -- if I'm reading this right, the only time the nodemap won't be all= =20 > nodes is if (1) the user specified nodes, or (2) there's a cpumask in=20 > effect. If we're going to override that setting, wouldn't it make sense= =20 > to just expand to all numa nodes? >=20 As you wish, the whole "what to do if what I've been provided with doesn't work" is in the *wild guess* status, meaning I tried to figure out what would be best to do, but I might well be far from the actual correct solution, provided there is one. Trying to enlarge the nodemap step by step is potentially yielding better performances, but is probably not so near to the "least surprise" principle one should use when designing UIs. :-( > Hmm -- though I suppose what you'd really want to try is adding each=20 > node in turn, rather than one at a time (i.e., if the cpus are pinned to= =20 > nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before=20 > trying [1,2,3,4]. =20 > Yep, that makes a real lot of sense, thanks! I can definitely try doing that, although it will complicate the code a bit... > But that's starting to get really complicated -- I=20 > wonder if it's better to just fail and let the user change the pinnings= =20 > / configuration node mapping. > Well, that will probably be the least surprising behaviour. Again, just let me know what you think it's best among the various alternatives and I'll go for it. > > + > > + if (use_cpus>=3D b_info->max_vcpus) { > > + rc =3D 0; > > + break; > > + } > Hmm -- there's got to be a better way to find out the minimum number of= =20 > nodes to house a given number of vcpus than just starting at 1 and=20 > re-trying until we have enough. > > + /* Add one more node and retry fitting the domain */ > > + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); > Same comment as above. > I'm not sure I'm getting this. The whole point here is let's consider free memory on the various nodes first, and then adjust the result if some other constraints are being violated. However, if what you mean is I could check beforehand whether or not the user provided configuration will give us enough CPUs and avoid testing scenarios that are guaranteed to fail, then I agree and I'll reshape the code to look like that. This triggers the heuristics re-designing stuff from above again, as one have to decide what to do if user asks for "nodes=3D[1,3]" and I discover (earlier) that I need one more node for having enough CPUs (I mean, what node should I try first?). > > > > + ret =3D place_domain(&d_config.b_info); > > + if (ret =3D=3D ESRCH || ret =3D=3D ENOSPC) { > > + fprintf(stderr, "failed to place the domain, fallback to all n= odes\n"); > > + libxl_nodemap_set_any(&d_config.b_info.nodemap); > Hmm -- is this the right fallback? I think in general, if the user asks= =20 > for X to be done, and X cannot be done for whatever reason, the right=20 > thing is to tell the user that X cannot be done and let them sort it=20 > out, rather than resorting to Y (unless that's been set). >=20 I agree and I will go for this. > Is it the case that if any node placement fails, then they'll all fail? = =20 > Or to put it the other way, is it the case that if there is *some*=20 > placement, that any placement algorithm will eventually find it? If so,= =20 > then I think this fallback may make sense, as there's nothing for the=20 > user to really do. > Well, that's tricky. I mean, if we were only talking about fitting all the VM's memory on one single node, then yes, no matter how you order the list of nodes, if there is at least one with enough space for the VM, you'll find it. However, we might be dealing with "fit the VM in multiple nodes" scenarios, which is a completely different thing, and changing the number of nodes onto which you're trying to fit the VM will change pretty much everything. So, I'm not entirely sure I answered your question but the point is your idea above is the best one: if you ask something and we don't manage in getting it done, just stop and let you figure things out. I've only one question about this approach, what if the automatic placement is/becomes the default? I mean, avoiding any kind of fallback (which again, makes sense to me in case the user is explicitly asking something specific) would mean a completely NUMA-unaware VM creation can be aborted even if the user did not say anything... How do we deal with this? > > diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c > > --- a/xen/arch/x86/numa.c > > +++ b/xen/arch/x86/numa.c > > ... > >=20 > This should be in its own patch. >=20 Ok. Thanks lot again for taking a look! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-VITkHo9S8QdJpmzIjUfZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+hYTsACgkQk4XaBE3IOsQcaQCeOwhFzvuKoNeM2IXEgAhh9TNC 7CoAn3AnzYx4y7K/bzJf1GskruO6Ygaq =etUB -----END PGP SIGNATURE----- --=-VITkHo9S8QdJpmzIjUfZ-- --===============6837791055166636165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6837791055166636165==-- From xen-devel-bounces@lists.xen.org Wed May 02 17:02:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPcvv-0001TD-Cc; Wed, 02 May 2012 17:01:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcvt-0001T8-Ew for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:01:41 +0000 Received: from [85.158.143.35:40931] by server-3.bemta-4.messagelabs.com id A6/A2-05853-47861AF4; Wed, 02 May 2012 17:01:40 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-8.tower-21.messagelabs.com!1335978100!15715991!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8508 invoked from network); 2 May 2012 17:01:40 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-8.tower-21.messagelabs.com with SMTP; 2 May 2012 17:01:40 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id DA2DB1AC1A2; Wed, 2 May 2012 19:01:38 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wq9A1_GwdMQj; Wed, 2 May 2012 19:01:38 +0200 (CEST) Received: from [10.0.0.1] (p5794633D.dip.t-dialin.net [87.148.99.61]) by rootsrv.hfp.de (Postfix) with ESMTPA; Wed, 2 May 2012 19:01:38 +0200 (CEST) Message-ID: <4FA16875.5020801@hfp.de> Date: Wed, 02 May 2012 19:01:41 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Vrabel References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> In-Reply-To: <4FA13708.4050202@cantab.net> Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02.05.2012 15:30, David Vrabel wrote: > Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly > check for pending events when restoring irq flags"[1] and see how much > it helps? There is some minor improvement - but it is still far away from xenified 2.6.34.10. time emerge apache: 3.2.12-dom0 3.3.4-dom0 (w. patch) 2.6.34.10-dom0 real 1m0.560s 0m59.971s (0m58.029s) 0m47.689s user 0m40.939s 0m40.619s (0m40.291s) 0m41.355s sys 0m18.865s 0m18.305s (0m16.837s) 0m11.441s time make -j4 (3.2.12 linux compile): 3.2.12-dom0 3.3.4-dom0 (w. patch) 2.6.34.10-dom0 real 5m8.793s 5m4.888s (5m1.408s) 4m20.576s user 8m1.746s 7m59.726s (7m57.534s) 7m10.375s sys 1m39.010s 1m32.994s (1m29.518s) 0m56.304s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:02:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPcvv-0001TD-Cc; Wed, 02 May 2012 17:01:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPcvt-0001T8-Ew for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:01:41 +0000 Received: from [85.158.143.35:40931] by server-3.bemta-4.messagelabs.com id A6/A2-05853-47861AF4; Wed, 02 May 2012 17:01:40 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-8.tower-21.messagelabs.com!1335978100!15715991!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8508 invoked from network); 2 May 2012 17:01:40 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-8.tower-21.messagelabs.com with SMTP; 2 May 2012 17:01:40 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id DA2DB1AC1A2; Wed, 2 May 2012 19:01:38 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wq9A1_GwdMQj; Wed, 2 May 2012 19:01:38 +0200 (CEST) Received: from [10.0.0.1] (p5794633D.dip.t-dialin.net [87.148.99.61]) by rootsrv.hfp.de (Postfix) with ESMTPA; Wed, 2 May 2012 19:01:38 +0200 (CEST) Message-ID: <4FA16875.5020801@hfp.de> Date: Wed, 02 May 2012 19:01:41 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Vrabel References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> In-Reply-To: <4FA13708.4050202@cantab.net> Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02.05.2012 15:30, David Vrabel wrote: > Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly > check for pending events when restoring irq flags"[1] and see how much > it helps? There is some minor improvement - but it is still far away from xenified 2.6.34.10. time emerge apache: 3.2.12-dom0 3.3.4-dom0 (w. patch) 2.6.34.10-dom0 real 1m0.560s 0m59.971s (0m58.029s) 0m47.689s user 0m40.939s 0m40.619s (0m40.291s) 0m41.355s sys 0m18.865s 0m18.305s (0m16.837s) 0m11.441s time make -j4 (3.2.12 linux compile): 3.2.12-dom0 3.3.4-dom0 (w. patch) 2.6.34.10-dom0 real 5m8.793s 5m4.888s (5m1.408s) 4m20.576s user 8m1.746s 7m59.726s (7m57.534s) 7m10.375s sys 1m39.010s 1m32.994s (1m29.518s) 0m56.304s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:07:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17:07:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPd0s-0001aW-3m; Wed, 02 May 2012 17:06:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPd0q-0001aQ-Ur for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:06:49 +0000 Received: from [85.158.143.35:58615] by server-3.bemta-4.messagelabs.com id F9/27-05853-8A961AF4; Wed, 02 May 2012 17:06:48 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335978405!13804607!1 X-Originating-IP: [216.32.180.12] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29689 invoked from network); 2 May 2012 17:06:46 -0000 Received: from va3ehsobe002.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.12) by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 17:06:46 -0000 Received: from mail144-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 17:06:36 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id 68E0D120319; Wed, 2 May 2012 17:06:36 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) 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 mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1335978394589923_5152; Wed, 2 May 2012 17:06:34 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240]) by mail144-va3.bigfish.com (Postfix) with ESMTP id 80B8820083; Wed, 2 May 2012 17:06:34 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 17:06:32 +0000 X-WSS-ID: 0M3ENJ0-02-8QT-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 22F97C8102; Wed, 2 May 2012 12:06:36 -0500 (CDT) 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, 2 May 2012 12:06:48 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 12:06:36 -0500 Message-ID: <4FA1699A.9070405@amd.com> Date: Wed, 2 May 2012 13:06:34 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> In-Reply-To: <20120502160812.GA6611@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..d816448 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -811,7 +811,29 @@ static void xen_io_delay(void) > #ifdef CONFIG_X86_LOCAL_APIC > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op = { > + .cmd = XENPF_get_cpuinfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid = 0, Is this always zero? This will probably solve the current problem but I am wondering whether in the future we might hit another bug because this routine will return the same APICID for all VCPUs. -boris > + }; > + int ret = 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg == APIC_LVR) > + return 0x10; > + > + if (reg != APIC_ID) > + return 0; > + > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id; > } > > static void xen_apic_write(u32 reg, u32 val) > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:07:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17:07:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPd0s-0001aW-3m; Wed, 02 May 2012 17:06:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPd0q-0001aQ-Ur for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:06:49 +0000 Received: from [85.158.143.35:58615] by server-3.bemta-4.messagelabs.com id F9/27-05853-8A961AF4; Wed, 02 May 2012 17:06:48 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1335978405!13804607!1 X-Originating-IP: [216.32.180.12] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29689 invoked from network); 2 May 2012 17:06:46 -0000 Received: from va3ehsobe002.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.12) by server-6.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 17:06:46 -0000 Received: from mail144-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 17:06:36 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id 68E0D120319; Wed, 2 May 2012 17:06:36 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) 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 mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1335978394589923_5152; Wed, 2 May 2012 17:06:34 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240]) by mail144-va3.bigfish.com (Postfix) with ESMTP id 80B8820083; Wed, 2 May 2012 17:06:34 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 17:06:32 +0000 X-WSS-ID: 0M3ENJ0-02-8QT-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 22F97C8102; Wed, 2 May 2012 12:06:36 -0500 (CDT) 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, 2 May 2012 12:06:48 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 12:06:36 -0500 Message-ID: <4FA1699A.9070405@amd.com> Date: Wed, 2 May 2012 13:06:34 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> In-Reply-To: <20120502160812.GA6611@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..d816448 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -811,7 +811,29 @@ static void xen_io_delay(void) > #ifdef CONFIG_X86_LOCAL_APIC > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op = { > + .cmd = XENPF_get_cpuinfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid = 0, Is this always zero? This will probably solve the current problem but I am wondering whether in the future we might hit another bug because this routine will return the same APICID for all VCPUs. -boris > + }; > + int ret = 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg == APIC_LVR) > + return 0x10; > + > + if (reg != APIC_ID) > + return 0; > + > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id; > } > > static void xen_apic_write(u32 reg, u32 val) > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:21:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPdEk-0001mI-Ht; Wed, 02 May 2012 17:21:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPdEj-0001mA-0Z for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:21:09 +0000 Received: from [85.158.138.51:12115] by server-8.bemta-3.messagelabs.com id 7B/54-24428-40D61AF4; Wed, 02 May 2012 17:21:08 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1335979266!24845324!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNzY0OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 835 invoked from network); 2 May 2012 17:21:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 17:21:07 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42HL1in010033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:21:01 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 q42HL0OZ015786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 17:21:00 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42HL0FR000510; Wed, 2 May 2012 12:21:00 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 10:19:56 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5380940357; Wed, 2 May 2012 13:14:15 -0400 (EDT) USER-AGENT: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 Message-ID: <20120502171415.GA17477@phenom.dumpdata.com> Date: Wed, 2 May 2012 10:14:15 -0700 (PDT) From: Konrad Rzeszutek Wilk To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> In-Reply-To: <4FA1699A.9070405@amd.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >index a8f8844..d816448 100644 > >--- a/arch/x86/xen/enlighten.c > >+++ b/arch/x86/xen/enlighten.c > >@@ -811,7 +811,29 @@ static void xen_io_delay(void) > > #ifdef CONFIG_X86_LOCAL_APIC > > static u32 xen_apic_read(u32 reg) > > { > >- return 0; > >+ struct xen_platform_op op = { > >+ .cmd = XENPF_get_cpuinfo, > >+ .interface_version = XENPF_INTERFACE_VERSION, > >+ .u.pcpu_info.xen_cpuid = 0, > > > Is this always zero? This will probably solve the current problem Its a CPU number (not tied in to APIC or ACPI IDs). > but I am wondering whether in the future we might hit another bug > because this routine will return the same APICID for all VCPUs. Later on it does a check for 'smp_processor_id()' - and if that is anything but zero it will bail out. So this shoudl solve the problem for the bootup processor. > > -boris > > > >+ }; > >+ int ret = 0; > >+ > >+ /* Shouldn't need this as APIC is turned off for PV, and we only > >+ * get called on the bootup processor. But just in case. */ > >+ if (!xen_initial_domain() || smp_processor_id()) > >+ return 0; > >+ > >+ if (reg == APIC_LVR) > >+ return 0x10; > >+ > >+ if (reg != APIC_ID) > >+ return 0; > >+ > >+ ret = HYPERVISOR_dom0_op(&op); > >+ if (ret) > >+ return 0; > >+ > >+ return op.u.pcpu_info.apic_id; > > } > > > > static void xen_apic_write(u32 reg, u32 val) > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:21:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPdEk-0001mI-Ht; Wed, 02 May 2012 17:21:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPdEj-0001mA-0Z for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:21:09 +0000 Received: from [85.158.138.51:12115] by server-8.bemta-3.messagelabs.com id 7B/54-24428-40D61AF4; Wed, 02 May 2012 17:21:08 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1335979266!24845324!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNzY0OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 835 invoked from network); 2 May 2012 17:21:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 17:21:07 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42HL1in010033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:21:01 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 q42HL0OZ015786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 17:21:00 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42HL0FR000510; Wed, 2 May 2012 12:21:00 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 10:19:56 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5380940357; Wed, 2 May 2012 13:14:15 -0400 (EDT) USER-AGENT: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 Message-ID: <20120502171415.GA17477@phenom.dumpdata.com> Date: Wed, 2 May 2012 10:14:15 -0700 (PDT) From: Konrad Rzeszutek Wilk To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> In-Reply-To: <4FA1699A.9070405@amd.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >index a8f8844..d816448 100644 > >--- a/arch/x86/xen/enlighten.c > >+++ b/arch/x86/xen/enlighten.c > >@@ -811,7 +811,29 @@ static void xen_io_delay(void) > > #ifdef CONFIG_X86_LOCAL_APIC > > static u32 xen_apic_read(u32 reg) > > { > >- return 0; > >+ struct xen_platform_op op = { > >+ .cmd = XENPF_get_cpuinfo, > >+ .interface_version = XENPF_INTERFACE_VERSION, > >+ .u.pcpu_info.xen_cpuid = 0, > > > Is this always zero? This will probably solve the current problem Its a CPU number (not tied in to APIC or ACPI IDs). > but I am wondering whether in the future we might hit another bug > because this routine will return the same APICID for all VCPUs. Later on it does a check for 'smp_processor_id()' - and if that is anything but zero it will bail out. So this shoudl solve the problem for the bootup processor. > > -boris > > > >+ }; > >+ int ret = 0; > >+ > >+ /* Shouldn't need this as APIC is turned off for PV, and we only > >+ * get called on the bootup processor. But just in case. */ > >+ if (!xen_initial_domain() || smp_processor_id()) > >+ return 0; > >+ > >+ if (reg == APIC_LVR) > >+ return 0x10; > >+ > >+ if (reg != APIC_ID) > >+ return 0; > >+ > >+ ret = HYPERVISOR_dom0_op(&op); > >+ if (ret) > >+ return 0; > >+ > >+ return op.u.pcpu_info.apic_id; > > } > > > > static void xen_apic_write(u32 reg, u32 val) > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:52:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPdi9-00020P-34; Wed, 02 May 2012 17:51:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPdi6-00020K-Um for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:51:31 +0000 Received: from [193.109.254.147:46082] by server-9.bemta-14.messagelabs.com id B0/6C-05787-22471AF4; Wed, 02 May 2012 17:51:30 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335981088!7317755!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3453 invoked from network); 2 May 2012 17:51:29 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 17:51:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42HpQYD014390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:51:27 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 q42HpPid007934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 17:51:26 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 q42HpPDv023440; Wed, 2 May 2012 12:51:25 -0500 MIME-Version: 1.0 Message-ID: <3a2da977-299d-4200-8f31-542b8a4fcb34@default> Date: Wed, 2 May 2012 10:51:12 -0700 (PDT) From: Dan Magenheimer To: Jana Saout References: <1335728058.4574.18.camel@localhost> <1335953632.3599.16.camel@localhost> In-Reply-To: <1335953632.3599.16.camel@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Jana Saout [mailto:jana@saout.de] > Subject: Re: [Xen-devel] Self-ballooning question / cache issue > Hi Jana -- Since you have tested this patch and have found it useful, and since its use is entirely optional, it is OK with me for it to be upstreamed at the next window. Konrad cc'ed. You will need to add a Signed-off-by line to the patch but other than that you can consider it Acked-by: Dan Magenheimer > > Your idea of the tunable is interesting (and patches are always > > welcome!) but I am skeptical that it will solve the problem > > since I would guess the Linux kernel is shrinking dcache > > proportional to the size of the page cache. So adding more > > RAM with your "user-specified amount of pages that is > > added on top of the computed target number of pages", > > the RAM will still be shared across all caches and only > > some small portion of the added RAM will likely be used > > for dcache. > > That's true. In fact, I have to add about 1 GB of memory in order to > keep the relevant dcache / inode cache entries to stay in the cache. > When I do that the largest portion of memory is still eaten up by the > regular page cache. So this is more of a workaround than a solution, > but for now it works. > > I've attached the simple patch I've whipped up below. > > > However, if you have a chance to try it, I would be interested > > in your findings. Note that you already can set a > > permanent floor for selfballooning ("min_usable_mb") or, > > of course, just turn off selfballooning altogether. > > Sure, that's always a possibility. However, the VM already had an > overly large amount of memory before to avoid the problem. Now it runs > with less memory (still a bit more than required), and when a load spike > comes, it can quickly balloon up, which is exactly what I was looking > for. > > Jana > > ---- > Author: Jana Saout > Date: Sun Apr 29 22:09:29 2012 +0200 > > Add selfballoning memory reservation tunable. > > diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c > index 146c948..7d041cb 100644 > --- a/drivers/xen/xen-selfballoon.c > +++ b/drivers/xen/xen-selfballoon.c > @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; > */ > static unsigned int selfballoon_min_usable_mb; > > +/* > + * Amount of RAM in MB to add to the target number of pages. > + * Can be used to reserve some more room for caches and the like. > + */ > +static unsigned int selfballoon_reserved_mb; > + > static void selfballoon_process(struct work_struct *work); > static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); > > @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) > cur_pages = totalram_pages; > tgt_pages = cur_pages; /* default is no change */ > goal_pages = percpu_counter_read_positive(&vm_committed_as) + > - totalreserve_pages; > + totalreserve_pages + > + MB2PAGES(selfballoon_reserved_mb); > #ifdef CONFIG_FRONTSWAP > /* allow space for frontswap pages to be repatriated */ > if (frontswap_selfshrinking && frontswap_enabled) > @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, > show_selfballoon_min_usable_mb, > store_selfballoon_min_usable_mb); > > +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", > + selfballoon_reserved_mb); > + > +static ssize_t store_selfballoon_reserved_mb(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t count) > +{ > + unsigned long val; > + int err; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + err = strict_strtoul(buf, 10, &val); > + if (err) > + return -EINVAL; > + selfballoon_reserved_mb = val; > + return count; > +} > + > +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, > + show_selfballoon_reserved_mb, > + store_selfballoon_reserved_mb); > + > > #ifdef CONFIG_FRONTSWAP > SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); > @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { > &dev_attr_selfballoon_downhysteresis.attr, > &dev_attr_selfballoon_uphysteresis.attr, > &dev_attr_selfballoon_min_usable_mb.attr, > + &dev_attr_selfballoon_reserved_mb.attr, > #ifdef CONFIG_FRONTSWAP > &dev_attr_frontswap_selfshrinking.attr, > &dev_attr_frontswap_hysteresis.attr, > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 17:52:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 17: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 ) id 1SPdi9-00020P-34; Wed, 02 May 2012 17:51:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPdi6-00020K-Um for xen-devel@lists.xensource.com; Wed, 02 May 2012 17:51:31 +0000 Received: from [193.109.254.147:46082] by server-9.bemta-14.messagelabs.com id B0/6C-05787-22471AF4; Wed, 02 May 2012 17:51:30 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335981088!7317755!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3453 invoked from network); 2 May 2012 17:51:29 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 17:51:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42HpQYD014390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:51:27 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 q42HpPid007934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 17:51:26 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 q42HpPDv023440; Wed, 2 May 2012 12:51:25 -0500 MIME-Version: 1.0 Message-ID: <3a2da977-299d-4200-8f31-542b8a4fcb34@default> Date: Wed, 2 May 2012 10:51:12 -0700 (PDT) From: Dan Magenheimer To: Jana Saout References: <1335728058.4574.18.camel@localhost> <1335953632.3599.16.camel@localhost> In-Reply-To: <1335953632.3599.16.camel@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Jana Saout [mailto:jana@saout.de] > Subject: Re: [Xen-devel] Self-ballooning question / cache issue > Hi Jana -- Since you have tested this patch and have found it useful, and since its use is entirely optional, it is OK with me for it to be upstreamed at the next window. Konrad cc'ed. You will need to add a Signed-off-by line to the patch but other than that you can consider it Acked-by: Dan Magenheimer > > Your idea of the tunable is interesting (and patches are always > > welcome!) but I am skeptical that it will solve the problem > > since I would guess the Linux kernel is shrinking dcache > > proportional to the size of the page cache. So adding more > > RAM with your "user-specified amount of pages that is > > added on top of the computed target number of pages", > > the RAM will still be shared across all caches and only > > some small portion of the added RAM will likely be used > > for dcache. > > That's true. In fact, I have to add about 1 GB of memory in order to > keep the relevant dcache / inode cache entries to stay in the cache. > When I do that the largest portion of memory is still eaten up by the > regular page cache. So this is more of a workaround than a solution, > but for now it works. > > I've attached the simple patch I've whipped up below. > > > However, if you have a chance to try it, I would be interested > > in your findings. Note that you already can set a > > permanent floor for selfballooning ("min_usable_mb") or, > > of course, just turn off selfballooning altogether. > > Sure, that's always a possibility. However, the VM already had an > overly large amount of memory before to avoid the problem. Now it runs > with less memory (still a bit more than required), and when a load spike > comes, it can quickly balloon up, which is exactly what I was looking > for. > > Jana > > ---- > Author: Jana Saout > Date: Sun Apr 29 22:09:29 2012 +0200 > > Add selfballoning memory reservation tunable. > > diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c > index 146c948..7d041cb 100644 > --- a/drivers/xen/xen-selfballoon.c > +++ b/drivers/xen/xen-selfballoon.c > @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; > */ > static unsigned int selfballoon_min_usable_mb; > > +/* > + * Amount of RAM in MB to add to the target number of pages. > + * Can be used to reserve some more room for caches and the like. > + */ > +static unsigned int selfballoon_reserved_mb; > + > static void selfballoon_process(struct work_struct *work); > static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); > > @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) > cur_pages = totalram_pages; > tgt_pages = cur_pages; /* default is no change */ > goal_pages = percpu_counter_read_positive(&vm_committed_as) + > - totalreserve_pages; > + totalreserve_pages + > + MB2PAGES(selfballoon_reserved_mb); > #ifdef CONFIG_FRONTSWAP > /* allow space for frontswap pages to be repatriated */ > if (frontswap_selfshrinking && frontswap_enabled) > @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, > show_selfballoon_min_usable_mb, > store_selfballoon_min_usable_mb); > > +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", > + selfballoon_reserved_mb); > + > +static ssize_t store_selfballoon_reserved_mb(struct device *dev, > + struct device_attribute *attr, > + const char *buf, > + size_t count) > +{ > + unsigned long val; > + int err; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + err = strict_strtoul(buf, 10, &val); > + if (err) > + return -EINVAL; > + selfballoon_reserved_mb = val; > + return count; > +} > + > +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, > + show_selfballoon_reserved_mb, > + store_selfballoon_reserved_mb); > + > > #ifdef CONFIG_FRONTSWAP > SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); > @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { > &dev_attr_selfballoon_downhysteresis.attr, > &dev_attr_selfballoon_uphysteresis.attr, > &dev_attr_selfballoon_min_usable_mb.attr, > + &dev_attr_selfballoon_reserved_mb.attr, > #ifdef CONFIG_FRONTSWAP > &dev_attr_frontswap_selfshrinking.attr, > &dev_attr_frontswap_hysteresis.attr, > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 18:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 18: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 ) id 1SPeVL-0002PC-M9; Wed, 02 May 2012 18:42:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPeVK-0002P7-1G for xen-devel@lists.xen.org; Wed, 02 May 2012 18:42:22 +0000 Received: from [85.158.139.83:11251] by server-8.bemta-5.messagelabs.com id 9A/81-26964-D0081AF4; Wed, 02 May 2012 18:42:21 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1335984137!26463529!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3888 invoked from network); 2 May 2012 18:42:19 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 18:42:19 -0000 Received: by qafl39 with SMTP id l39so927004qaf.16 for ; Wed, 02 May 2012 11:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ezmfeRlos+NC8jw2DmcgqdI9f44gl0Fd981ysoQ4OGA=; b=SA9O6QYHLCvo7FCrjTIQn367CoRTvaTBg+GmNHWEfwuXD6WEPlp25HcMkZCfOaY1+b Ph+TUzRz3fPOJP3fgfBEUHy2Zj53IGW3TnLsPmwQ+OR8GIFf8lFPEUCw/NT9zpLYCSox rMr4E07PlMV8ZxTus1dvXTzcaLi74Q+wRc2h8YfDMusXdDjJWDwKbHlI5Lsk4AtAbQHp XSqYq+ye8c0dnXuimWyTibgrHesXzphbnb+kqFccefqdJdK0fd+G4cczV8wylXlX91a+ WgzUiFotYkDTaJKiPhpjxg69T1e8zIO/5tcBQN2Rmf63O7u8IZJBtvZWR6kJ30roBwsH PoiA== MIME-Version: 1.0 Received: by 10.224.100.71 with SMTP id x7mr25973331qan.92.1335984136470; Wed, 02 May 2012 11:42:16 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Wed, 2 May 2012 11:42:16 -0700 (PDT) In-Reply-To: <4FA113B902000078000810C3@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> Date: Wed, 2 May 2012 11:42:16 -0700 Message-ID: From: AP To: Jan Beulich Cc: xen-devel , weidong.han@intel.com, Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk w= rote: >> I somehow thought that this has been fixed but I've been >> getting reports that people are running into this. > > "this" being what? I too thought that all xsave related issues were > sorted out by now. I see the following crash if I run without xsave=3D0 with Ubuntu 11.10 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. [ 7.509303] invalid opcode: 0000 [#1] SMP [ 7.509319] CPU 0 [ 7.509325] Modules linked in: [ 7.509337] [ 7.509347] Pid: 0, comm: swapper Not tainted 3.0.0-17-generic #30-Ubuntu LENOVO 4286CTO/4286CTO [ 7.509371] RIP: e030:[] [] xstate_enable+0x3c/0x50 [ 7.509399] RSP: e02b:ffffffff81c01e58 EFLAGS: 00010046 [ 7.509409] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 00000000000= 00000 [ 7.509419] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00000000000= 02660 [ 7.509430] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ffffffff81c= 01e94 [ 7.509440] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81c= 01e90 [ 7.509501] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ffff8801e97= ecd00 [ 7.509519] FS: 0000000000000000(0000) GS:ffff8801e97e0000(0000) knlGS:0000000000000000 [ 7.509530] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 7.509539] CR2: 0000000000000000 CR3: 0000000001c03000 CR4: 00000000000= 02660 [ 7.509550] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 7.509561] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 [ 7.509573] Process swapper (pid: 0, threadinfo ffffffff81c00000, task ffffffff81c0b020) [ 7.509582] Stack: [ 7.509589] ffffffff81c01ec8 ffffffff81cd97ac 0000000000000040 0000000000000000 [ 7.509613] ffffffff81007b4f ffffffff81004057 0000024000000007 0000000000000340 [ 7.509637] ffff8801e97eb100 0000000000000008 0000000000000004 0000000000000000 [ 7.509660] Call Trace: [ 7.509679] [] xstate_enable_boot_cpu+0xa9/0x174 [ 7.509698] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 7.509712] [] ? xen_write_cr0+0x77/0x90 [ 7.509730] [] xsave_init+0x26/0x28 [ 7.509744] [] cpu_init+0x2bb/0x2d8 [ 7.509759] [] trap_init+0x169/0x171 [ 7.509774] [] start_kernel+0x1d0/0x3df [ 7.509789] [] x86_64_start_reservations+0x132/0x136 [ 7.509805] [] xen_start_kernel+0x5ac/0x5b3 [ 7.509814] Code: 00 04 00 ff 14 25 10 33 c1 81 48 89 c7 48 81 cf 00 00 04 00 ff 14 25 18 33 c1 81 48 8b 05 0d 15 db 00 31 c9 48 89 c2 48 c1 ea 20 <0f> 01 d1 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 [ 7.510045] RIP [] xstate_enable+0x3c/0x50 [ 7.510062] RSP [ 7.510086] ---[ end trace a7919e7f17c0a725 ]--- [ 7.510097] Kernel panic - not syncing: Attempted to kill the idle task! [ 7.510109] Pid: 0, comm: swapper Tainted: G D 3.0.0-17-generic #30-Ubuntu [ 7.510119] Call Trace: [ 7.510134] [] panic+0x91/0x194 [ 7.510151] [] do_exit+0x40b/0x440 [ 7.510168] [] oops_end+0xb0/0xf0 [ 7.510181] [] die+0x58/0x90 [ 7.510195] [] do_trap+0xc4/0x170 [ 7.510211] [] do_invalid_op+0x95/0xb0 [ 7.510226] [] ? xstate_enable+0x3c/0x50 [ 7.510240] [] ? check_events+0x12/0x20 [ 7.510255] [] ? get_phys_to_machine+0x9/0x70 [ 7.510269] [] ? pte_mfn_to_pfn+0x89/0xf0 [ 7.510283] [] ? xen_force_evtchn_callback+0xd/0x10 [ 7.510299] [] invalid_op+0x1b/0x20 [ 7.510315] [] ? xstate_enable+0x3c/0x50 [ 7.510329] [] ? xstate_enable+0x2c/0x50 [ 7.510343] [] xstate_enable_boot_cpu+0xa9/0x174 [ 7.510358] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 7.510371] [] ? xen_write_cr0+0x77/0x90 [ 7.510385] [] xsave_init+0x26/0x28 [ 7.510399] [] cpu_init+0x2bb/0x2d8 [ 7.510413] [] trap_init+0x169/0x171 [ 7.510427] [] start_kernel+0x1d0/0x3df [ 7.510441] [] x86_64_start_reservations+0x132/0x136 [ 7.510457] [] xen_start_kernel+0x5ac/0x5b3 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >> What kind of fix do I need the in the kernel? I see this: >> =A0255 =A0 =A0 =A0 =A0 xen_cpuid(&ax, &bx, &cx, &dx); >> =A0256 >> =A0257 =A0 =A0 =A0 =A0 xsave_mask =3D >> =A0258 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 << (X86_FEATURE_XSAVE % 32)) | >> =A0259 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 << (X86_FEATURE_OSXSAVE % 32)); >> =A0260 >> =A0261 =A0 =A0 =A0 =A0 /* Xen will set CR4.OSXSAVE if supported and not = disabled by >> force */ >> =A0262 =A0 =A0 =A0 =A0 if ((cx & xsave_mask) !=3D xsave_mask) >> =A0263 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpuid_leaf1_ecx_mask &=3D ~xsave_= mask; /* disable XSAVE & >> OSXSAVE */ >> =A0264 } >> >> But do I need some other one? > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 18:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 18: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 ) id 1SPeVL-0002PC-M9; Wed, 02 May 2012 18:42:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPeVK-0002P7-1G for xen-devel@lists.xen.org; Wed, 02 May 2012 18:42:22 +0000 Received: from [85.158.139.83:11251] by server-8.bemta-5.messagelabs.com id 9A/81-26964-D0081AF4; Wed, 02 May 2012 18:42:21 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1335984137!26463529!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3888 invoked from network); 2 May 2012 18:42:19 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 18:42:19 -0000 Received: by qafl39 with SMTP id l39so927004qaf.16 for ; Wed, 02 May 2012 11:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ezmfeRlos+NC8jw2DmcgqdI9f44gl0Fd981ysoQ4OGA=; b=SA9O6QYHLCvo7FCrjTIQn367CoRTvaTBg+GmNHWEfwuXD6WEPlp25HcMkZCfOaY1+b Ph+TUzRz3fPOJP3fgfBEUHy2Zj53IGW3TnLsPmwQ+OR8GIFf8lFPEUCw/NT9zpLYCSox rMr4E07PlMV8ZxTus1dvXTzcaLi74Q+wRc2h8YfDMusXdDjJWDwKbHlI5Lsk4AtAbQHp XSqYq+ye8c0dnXuimWyTibgrHesXzphbnb+kqFccefqdJdK0fd+G4cczV8wylXlX91a+ WgzUiFotYkDTaJKiPhpjxg69T1e8zIO/5tcBQN2Rmf63O7u8IZJBtvZWR6kJ30roBwsH PoiA== MIME-Version: 1.0 Received: by 10.224.100.71 with SMTP id x7mr25973331qan.92.1335984136470; Wed, 02 May 2012 11:42:16 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Wed, 2 May 2012 11:42:16 -0700 (PDT) In-Reply-To: <4FA113B902000078000810C3@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> Date: Wed, 2 May 2012 11:42:16 -0700 Message-ID: From: AP To: Jan Beulich Cc: xen-devel , weidong.han@intel.com, Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk w= rote: >> I somehow thought that this has been fixed but I've been >> getting reports that people are running into this. > > "this" being what? I too thought that all xsave related issues were > sorted out by now. I see the following crash if I run without xsave=3D0 with Ubuntu 11.10 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. [ 7.509303] invalid opcode: 0000 [#1] SMP [ 7.509319] CPU 0 [ 7.509325] Modules linked in: [ 7.509337] [ 7.509347] Pid: 0, comm: swapper Not tainted 3.0.0-17-generic #30-Ubuntu LENOVO 4286CTO/4286CTO [ 7.509371] RIP: e030:[] [] xstate_enable+0x3c/0x50 [ 7.509399] RSP: e02b:ffffffff81c01e58 EFLAGS: 00010046 [ 7.509409] RAX: 0000000000000007 RBX: ffffffff81c01e94 RCX: 00000000000= 00000 [ 7.509419] RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00000000000= 02660 [ 7.509430] RBP: ffffffff81c01e58 R08: ffffffff81c01e90 R09: ffffffff81c= 01e94 [ 7.509440] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81c= 01e90 [ 7.509501] R13: ffffffff81c01e8c R14: ffffffff81c01e88 R15: ffff8801e97= ecd00 [ 7.509519] FS: 0000000000000000(0000) GS:ffff8801e97e0000(0000) knlGS:0000000000000000 [ 7.509530] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 7.509539] CR2: 0000000000000000 CR3: 0000000001c03000 CR4: 00000000000= 02660 [ 7.509550] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 7.509561] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 [ 7.509573] Process swapper (pid: 0, threadinfo ffffffff81c00000, task ffffffff81c0b020) [ 7.509582] Stack: [ 7.509589] ffffffff81c01ec8 ffffffff81cd97ac 0000000000000040 0000000000000000 [ 7.509613] ffffffff81007b4f ffffffff81004057 0000024000000007 0000000000000340 [ 7.509637] ffff8801e97eb100 0000000000000008 0000000000000004 0000000000000000 [ 7.509660] Call Trace: [ 7.509679] [] xstate_enable_boot_cpu+0xa9/0x174 [ 7.509698] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 7.509712] [] ? xen_write_cr0+0x77/0x90 [ 7.509730] [] xsave_init+0x26/0x28 [ 7.509744] [] cpu_init+0x2bb/0x2d8 [ 7.509759] [] trap_init+0x169/0x171 [ 7.509774] [] start_kernel+0x1d0/0x3df [ 7.509789] [] x86_64_start_reservations+0x132/0x136 [ 7.509805] [] xen_start_kernel+0x5ac/0x5b3 [ 7.509814] Code: 00 04 00 ff 14 25 10 33 c1 81 48 89 c7 48 81 cf 00 00 04 00 ff 14 25 18 33 c1 81 48 8b 05 0d 15 db 00 31 c9 48 89 c2 48 c1 ea 20 <0f> 01 d1 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 [ 7.510045] RIP [] xstate_enable+0x3c/0x50 [ 7.510062] RSP [ 7.510086] ---[ end trace a7919e7f17c0a725 ]--- [ 7.510097] Kernel panic - not syncing: Attempted to kill the idle task! [ 7.510109] Pid: 0, comm: swapper Tainted: G D 3.0.0-17-generic #30-Ubuntu [ 7.510119] Call Trace: [ 7.510134] [] panic+0x91/0x194 [ 7.510151] [] do_exit+0x40b/0x440 [ 7.510168] [] oops_end+0xb0/0xf0 [ 7.510181] [] die+0x58/0x90 [ 7.510195] [] do_trap+0xc4/0x170 [ 7.510211] [] do_invalid_op+0x95/0xb0 [ 7.510226] [] ? xstate_enable+0x3c/0x50 [ 7.510240] [] ? check_events+0x12/0x20 [ 7.510255] [] ? get_phys_to_machine+0x9/0x70 [ 7.510269] [] ? pte_mfn_to_pfn+0x89/0xf0 [ 7.510283] [] ? xen_force_evtchn_callback+0xd/0x10 [ 7.510299] [] invalid_op+0x1b/0x20 [ 7.510315] [] ? xstate_enable+0x3c/0x50 [ 7.510329] [] ? xstate_enable+0x2c/0x50 [ 7.510343] [] xstate_enable_boot_cpu+0xa9/0x174 [ 7.510358] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 7.510371] [] ? xen_write_cr0+0x77/0x90 [ 7.510385] [] xsave_init+0x26/0x28 [ 7.510399] [] cpu_init+0x2bb/0x2d8 [ 7.510413] [] trap_init+0x169/0x171 [ 7.510427] [] start_kernel+0x1d0/0x3df [ 7.510441] [] x86_64_start_reservations+0x132/0x136 [ 7.510457] [] xen_start_kernel+0x5ac/0x5b3 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >> What kind of fix do I need the in the kernel? I see this: >> =A0255 =A0 =A0 =A0 =A0 xen_cpuid(&ax, &bx, &cx, &dx); >> =A0256 >> =A0257 =A0 =A0 =A0 =A0 xsave_mask =3D >> =A0258 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 << (X86_FEATURE_XSAVE % 32)) | >> =A0259 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 << (X86_FEATURE_OSXSAVE % 32)); >> =A0260 >> =A0261 =A0 =A0 =A0 =A0 /* Xen will set CR4.OSXSAVE if supported and not = disabled by >> force */ >> =A0262 =A0 =A0 =A0 =A0 if ((cx & xsave_mask) !=3D xsave_mask) >> =A0263 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpuid_leaf1_ecx_mask &=3D ~xsave_= mask; /* disable XSAVE & >> OSXSAVE */ >> =A0264 } >> >> But do I need some other one? > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 19:09:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 19: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 ) id 1SPeuY-0002ea-1F; Wed, 02 May 2012 19:08:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPeuX-0002eV-1n for xen-devel@lists.xensource.com; Wed, 02 May 2012 19:08:25 +0000 Received: from [85.158.138.51:65211] by server-4.bemta-3.messagelabs.com id B3/9E-15341-72681AF4; Wed, 02 May 2012 19:08:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1335985703!16964106!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15509 invoked from network); 2 May 2012 19:08:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 19:08:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,518,1330905600"; d="scan'208";a="12257829" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 19:08:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 20:08:22 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPeuU-0003v5-6m; Wed, 02 May 2012 19:08:22 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPeuT-0005sT-VM; Wed, 02 May 2012 20:08:22 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 20:08:21 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12779: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12779 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12779/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 build-i386 2 host-install(2) broken in 12776 REGR. vs. 12707 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail pass in 12776 test-amd64-amd64-pv 3 host-install(3) broken in 12776 pass in 12779 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 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-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-pv 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-pv 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-pair 1 xen-build-check(1) blocked in 12776 n/a test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 12776 never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-pair 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-win 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-win 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked in 12776 n/a version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 19:09:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 19: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 ) id 1SPeuY-0002ea-1F; Wed, 02 May 2012 19:08:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPeuX-0002eV-1n for xen-devel@lists.xensource.com; Wed, 02 May 2012 19:08:25 +0000 Received: from [85.158.138.51:65211] by server-4.bemta-3.messagelabs.com id B3/9E-15341-72681AF4; Wed, 02 May 2012 19:08:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1335985703!16964106!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15509 invoked from network); 2 May 2012 19:08:23 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 May 2012 19:08:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,518,1330905600"; d="scan'208";a="12257829" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 19:08:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 20:08:22 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPeuU-0003v5-6m; Wed, 02 May 2012 19:08:22 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPeuT-0005sT-VM; Wed, 02 May 2012 20:08:22 +0100 To: Message-ID: From: xen.org Date: Wed, 2 May 2012 20:08:21 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12779: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12779 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12779/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12707 test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 12707 build-i386 2 host-install(2) broken in 12776 REGR. vs. 12707 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail pass in 12776 test-amd64-amd64-pv 3 host-install(3) broken in 12776 pass in 12779 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 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-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-pv 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-pv 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-pair 1 xen-build-check(1) blocked in 12776 n/a test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 12776 never pass test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-pair 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-win 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-win 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 12776 n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked in 12776 n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked in 12776 n/a version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv broken test-i386-i386-pv broken test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 19:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 19: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 ) id 1SPffl-0003Eo-Sy; Wed, 02 May 2012 19:57:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPffk-0003Ef-6I for xen-devel@lists.xensource.com; Wed, 02 May 2012 19:57:12 +0000 Received: from [85.158.143.35:9958] by server-2.bemta-4.messagelabs.com id D6/02-17550-79191AF4; Wed, 02 May 2012 19:57:11 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1335988629!15173219!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27680 invoked from network); 2 May 2012 19:57:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 19:57:10 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42JuLDh012039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 19:56: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 q42JuIif027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 19:56:19 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42JuHat032166; Wed, 2 May 2012 14:56:18 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 12:56:17 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B68BB40357; Wed, 2 May 2012 15:50:36 -0400 (EDT) Date: Wed, 2 May 2012 15:50:36 -0400 From: Konrad Rzeszutek Wilk To: Goncalo Gomes Message-ID: <20120502195035.GA31755@phenom.dumpdata.com> References: <20120313173239.GA27920@eire.uk.xensource.com> <20120313173504.GB13033@phenom.dumpdata.com> <20120313180422.GA28716@eire.uk.xensource.com> <20120313190917.GA31144@eire.uk.xensource.com> <20120313192541.GA4969@phenom.dumpdata.com> <20120313223437.GA5180@eire.uk.xensource.com> <20120313234503.GA18924@phenom.dumpdata.com> <20120316191127.GA6668@eire.uk.xensource.com> <20120316195907.GA6228@phenom.dumpdata.com> <20120318155034.GA24315@eire.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120318155034.GA24315@eire.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "dave.mccracken@oracle.com" Subject: Re: [Xen-devel] crash in is_xen_swiotlb_buffer X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Mar 18, 2012 at 03:50:35PM +0000, Goncalo Gomes wrote: > On Fri, 16 Mar 2012, Konrad Rzeszutek Wilk wrote: > > > On Fri, Mar 16, 2012 at 07:11:27PM +0000, Goncalo Gomes wrote: > > > Any luck with this one? :) > > > > Can you try with a 64-bit hypervisor please? > > I tried and I can still trigger the bug. > > I've attached the log. > > Goncalo .. snip.. > [ 0.000000] No NUMA configuration found > [ 0.000000] Faking a node at 0000000000000000-0000000240000000 > (XEN) mm.c:943:d0 Attempt to map superpage without allowsuperpage flag in hypervisor > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: at arch/x86/xen/multicalls.c:129 xen_mc_issue+0x34/0x62() > [ 0.000000] Hardware name: PowerEdge R310 > [ 0.000000] Modules linked in: > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.2.9 #9 > [ 0.000000] Call Trace: > [ 0.000000] [] ? warn_slowpath_common+0x6a/0x7b > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > [ 0.000000] [] ? warn_slowpath_null+0xd/0x10 > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > [ 0.000000] [] ? xen_set_pmd_hyper+0x3c/0x42 > [ 0.000000] [] ? set_pmd_pfn+0xde/0xf9 > [ 0.000000] [] ? init_alloc_remap+0x1b3/0x216 > [ 0.000000] [] ? setup_node_data+0x4c/0x22f > [ 0.000000] [] ? T.744+0x290/0x2c2 > [ 0.000000] [] ? T.743+0x77/0x1a1 > [ 0.000000] [] ? default_get_apic_id+0x14/0x33 > [ 0.000000] [] ? initmem_init+0x5/0xb7 > [ 0.000000] [] ? setup_arch+0x5bf/0x694 > [ 0.000000] [] ? __spin_time_accum+0x26/0x36 > [ 0.000000] [] ? start_kernel+0x81/0x34d > [ 0.000000] [] ? xen_start_kernel+0x554/0x55b > [ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]--- So I've been able to reproduce this and it is due to CONFIG_NUMA=y set on 32-bit builds. >From a brief look, it looks as this is happening: /* perform actual remap */ for (pfn = 0; pfn < size >> PAGE_SHIFT; pfn += PTRS_PER_PTE) set_pmd_pfn((unsigned long)remap_va + (pfn << PAGE_SHIFT), (node_pa >> PAGE_SHIFT) + pfn, PAGE_KERNEL_LARGE); The PAGE_KERNEL_LARGE means that the PSE bit (so the 2MB) is set which is a no-no. What is weird is that acpi_numa is disabled when booting under Xen, but somehow this (which in my case was the 'fake_numa' code) still gets turned on. Even doing 'numa=off' on the command line causes this to appear. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 19:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 19: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 ) id 1SPffl-0003Eo-Sy; Wed, 02 May 2012 19:57:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPffk-0003Ef-6I for xen-devel@lists.xensource.com; Wed, 02 May 2012 19:57:12 +0000 Received: from [85.158.143.35:9958] by server-2.bemta-4.messagelabs.com id D6/02-17550-79191AF4; Wed, 02 May 2012 19:57:11 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1335988629!15173219!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA1MjU1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27680 invoked from network); 2 May 2012 19:57:10 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 19:57:10 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42JuLDh012039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 19:56: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 q42JuIif027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 19:56:19 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42JuHat032166; Wed, 2 May 2012 14:56:18 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 12:56:17 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B68BB40357; Wed, 2 May 2012 15:50:36 -0400 (EDT) Date: Wed, 2 May 2012 15:50:36 -0400 From: Konrad Rzeszutek Wilk To: Goncalo Gomes Message-ID: <20120502195035.GA31755@phenom.dumpdata.com> References: <20120313173239.GA27920@eire.uk.xensource.com> <20120313173504.GB13033@phenom.dumpdata.com> <20120313180422.GA28716@eire.uk.xensource.com> <20120313190917.GA31144@eire.uk.xensource.com> <20120313192541.GA4969@phenom.dumpdata.com> <20120313223437.GA5180@eire.uk.xensource.com> <20120313234503.GA18924@phenom.dumpdata.com> <20120316191127.GA6668@eire.uk.xensource.com> <20120316195907.GA6228@phenom.dumpdata.com> <20120318155034.GA24315@eire.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120318155034.GA24315@eire.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "dave.mccracken@oracle.com" Subject: Re: [Xen-devel] crash in is_xen_swiotlb_buffer X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Mar 18, 2012 at 03:50:35PM +0000, Goncalo Gomes wrote: > On Fri, 16 Mar 2012, Konrad Rzeszutek Wilk wrote: > > > On Fri, Mar 16, 2012 at 07:11:27PM +0000, Goncalo Gomes wrote: > > > Any luck with this one? :) > > > > Can you try with a 64-bit hypervisor please? > > I tried and I can still trigger the bug. > > I've attached the log. > > Goncalo .. snip.. > [ 0.000000] No NUMA configuration found > [ 0.000000] Faking a node at 0000000000000000-0000000240000000 > (XEN) mm.c:943:d0 Attempt to map superpage without allowsuperpage flag in hypervisor > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: at arch/x86/xen/multicalls.c:129 xen_mc_issue+0x34/0x62() > [ 0.000000] Hardware name: PowerEdge R310 > [ 0.000000] Modules linked in: > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.2.9 #9 > [ 0.000000] Call Trace: > [ 0.000000] [] ? warn_slowpath_common+0x6a/0x7b > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > [ 0.000000] [] ? warn_slowpath_null+0xd/0x10 > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > [ 0.000000] [] ? xen_set_pmd_hyper+0x3c/0x42 > [ 0.000000] [] ? set_pmd_pfn+0xde/0xf9 > [ 0.000000] [] ? init_alloc_remap+0x1b3/0x216 > [ 0.000000] [] ? setup_node_data+0x4c/0x22f > [ 0.000000] [] ? T.744+0x290/0x2c2 > [ 0.000000] [] ? T.743+0x77/0x1a1 > [ 0.000000] [] ? default_get_apic_id+0x14/0x33 > [ 0.000000] [] ? initmem_init+0x5/0xb7 > [ 0.000000] [] ? setup_arch+0x5bf/0x694 > [ 0.000000] [] ? __spin_time_accum+0x26/0x36 > [ 0.000000] [] ? start_kernel+0x81/0x34d > [ 0.000000] [] ? xen_start_kernel+0x554/0x55b > [ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]--- So I've been able to reproduce this and it is due to CONFIG_NUMA=y set on 32-bit builds. >From a brief look, it looks as this is happening: /* perform actual remap */ for (pfn = 0; pfn < size >> PAGE_SHIFT; pfn += PTRS_PER_PTE) set_pmd_pfn((unsigned long)remap_va + (pfn << PAGE_SHIFT), (node_pa >> PAGE_SHIFT) + pfn, PAGE_KERNEL_LARGE); The PAGE_KERNEL_LARGE means that the PSE bit (so the 2MB) is set which is a no-no. What is weird is that acpi_numa is disabled when booting under Xen, but somehow this (which in my case was the 'fake_numa' code) still gets turned on. Even doing 'numa=off' on the command line causes this to appear. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 20:16:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 20:16:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPfxe-0003og-8w; Wed, 02 May 2012 20:15:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPfxc-0003ob-Uz for xen-devel@lists.xensource.com; Wed, 02 May 2012 20:15:41 +0000 Received: from [85.158.139.83:13037] by server-6.bemta-5.messagelabs.com id DB/7B-13222-CE591AF4; Wed, 02 May 2012 20:15:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1335989737!22201486!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26851 invoked from network); 2 May 2012 20:15:38 -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; 2 May 2012 20:15:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,518,1330905600"; d="scan'208";a="12259267" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 20:15:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 21:15:35 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPfxX-0004GM-SB; Wed, 02 May 2012 20:15:35 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPfxX-0000wY-Mg; Wed, 02 May 2012 21:15:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 21:15:35 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12780: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12780 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12780/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 3 host-install(3) broken pass in 12777 test-i386-i386-xl 3 host-install(3) broken in 12777 pass in 12780 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 20:16:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 20:16:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPfxe-0003og-8w; Wed, 02 May 2012 20:15:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPfxc-0003ob-Uz for xen-devel@lists.xensource.com; Wed, 02 May 2012 20:15:41 +0000 Received: from [85.158.139.83:13037] by server-6.bemta-5.messagelabs.com id DB/7B-13222-CE591AF4; Wed, 02 May 2012 20:15:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1335989737!22201486!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26851 invoked from network); 2 May 2012 20:15:38 -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; 2 May 2012 20:15:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,518,1330905600"; d="scan'208";a="12259267" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 May 2012 20:15:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 21:15:35 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPfxX-0004GM-SB; Wed, 02 May 2012 20:15:35 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPfxX-0000wY-Mg; Wed, 02 May 2012 21:15:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 2 May 2012 21:15:35 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12780: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12780 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12780/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 12746 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 3 host-install(3) broken pass in 12777 test-i386-i386-xl 3 host-install(3) broken in 12777 pass in 12780 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 12746 test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 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-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 21:30:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21:30:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh7T-0004pD-C4; Wed, 02 May 2012 21:29:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh7R-0004p8-6p for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:29:53 +0000 Received: from [193.109.254.147:38218] by server-6.bemta-14.messagelabs.com id BA/2C-04960-057A1AF4; Wed, 02 May 2012 21:29:52 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1335994188!4912202!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6707 invoked from network); 2 May 2012 21:29:48 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-5.tower-27.messagelabs.com with SMTP; 2 May 2012 21:29:48 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPh7K-0004iD-KC; Wed, 02 May 2012 21:29:47 +0000 Message-ID: <4FA1A747.5080909@canonical.com> Date: Wed, 02 May 2012 23:29:43 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> In-Reply-To: <20120502160812.GA6611@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8639842970269748413==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8639842970269748413== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2E4FEB681D5F888C5BCE183E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E4FEB681D5F888C5BCE183E Content-Type: multipart/mixed; boundary="------------040008000906090802060103" This is a multi-part message in MIME format. --------------040008000906090802060103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 18:08, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 05:01:00PM +0200, Stefan Bader wrote: >> On 02.05.2012 00:35, Boris Ostrovsky wrote: >>> On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >>>> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>>>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>>>> Since there have been requests about that driver to get backporte= d into 3.2, I >>>>>>> was interested to find out what or how much would be gained by th= at. >>>>>>> >>>>>>> The first system I tried was an AMD based one (8 core Opteron 612= 8@2GHz). >>>>>>> Which >>>>>>> was not very successful as the drivers bail out of the init funct= ion >>>>>>> because the >>>>>>> first call to acpi_processor_register_performance() returns -ENOD= EV. There is >>>>>>> some frequency scaling when running without Xen, so I need to do = some more >>>>>>> debugging there. >>> >>> I believe this is caused by the somewhat under-enlightened xen_apic_r= ead(): >>> >>> static u32 xen_apic_read(u32 reg) >>> { >>> return 0; >>> } >>> >>> This results in some data, most importantly boot_cpu_physical_apicid,= not being >>> set correctly and, in turn, causes x86_cpu_to_apicid to be broken. >>> >>> On larger AMD systems boot processor is typically APICID=3D0x20 (I do= n't have >>> Intel system handy to see how it looks there). >>> >>> As a quick and dirty test you can try: >>> >>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.= c >>> index edc2448..1f78998 100644 >>> --- a/arch/x86/kernel/apic/apic.c >>> +++ b/arch/x86/kernel/apic/apic.c >>> @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned lon= g address) >>> } >>> if (boot_cpu_physical_apicid =3D=3D -1U) { >>> boot_cpu_physical_apicid =3D read_apic_id(); >>> + boot_cpu_physical_apicid =3D 32; >>> apic_version[boot_cpu_physical_apicid] =3D >>> GET_APIC_VERSION(apic_read(APIC_LVR)); >>> } >>> >>> >>> (Set it to whatever APICID on core0 is, I suspect it won't be zero). >>> >> >> Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most o= f the BIOS >> bug messages are gone and the xen-acpi-processor driver successfully l= oads and >> seems to be switching frequencies ok (just a quick tight loop which ma= de one cpu >> go from P4 to P0). >=20 > OK. Can you try the attached patch pls? It should do the same thing > as what the debug patch does - get the _real_ APIC ID from the hypervis= or. > (And as bonus it also removes the annoying: >=20 > BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 All the BIOS bug messages are gone from the Intel and the AMD box. Just t= he AMD box again fails to load the xen-acpi-processor driver. Though it must be = a different exit. I had enabled acpi debugging for the modprobe call but th= is time there is no trace of any acpi messages. >=20 >=20 > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..d816448 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -811,7 +811,29 @@ static void xen_io_delay(void) > #ifdef CONFIG_X86_LOCAL_APIC > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op =3D { > + .cmd =3D XENPF_get_cpuinfo, > + .interface_version =3D XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid =3D 0, > + }; > + int ret =3D 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg =3D=3D APIC_LVR) > + return 0x10; > + > + if (reg !=3D APIC_ID) > + return 0; > + > + ret =3D HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id; > } > =20 > static void xen_apic_write(u32 reg, u32 val) >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------040008000906090802060103 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.4" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.4" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg3 SMP Wed May 2 20:48:57= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg3-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.172 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.34 BogoMIPS (lpj=3D8000688) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008000] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016990] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019592] Mount-cache hash table entries: 256 [ 0.019840] Initializing cgroup subsys cpuacct [ 0.019852] Initializing cgroup subsys memory [ 0.019871] Initializing cgroup subsys devices [ 0.019877] Initializing cgroup subsys freezer [ 0.019882] Initializing cgroup subsys blkio [ 0.019898] Initializing cgroup subsys perf_event [ 0.019972] tseg: 00dff00000 [ 0.019980] CPU: Physical Processor ID: 0 [ 0.019984] CPU: Processor Core ID: 0 [ 0.022918] ACPI: Core revision 20110623 [ 0.038976] ftrace: allocating 27102 entries in 107 pages [ 0.040132] cpu 0 spinlock event irq 273 [ 0.040233] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040500] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040631] installing Xen timer for CPU 1 [ 0.040649] cpu 1 spinlock event irq 279 [ 0.040855] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040978] installing Xen timer for CPU 2 [ 0.040996] cpu 2 spinlock event irq 285 [ 0.041153] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041269] installing Xen timer for CPU 3 [ 0.041284] cpu 3 spinlock event irq 291 [ 0.041445] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041562] installing Xen timer for CPU 4 [ 0.041577] cpu 4 spinlock event irq 297 [ 0.041759] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041885] installing Xen timer for CPU 5 [ 0.041901] cpu 5 spinlock event irq 303 [ 0.042060] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042175] installing Xen timer for CPU 6 [ 0.042191] cpu 6 spinlock event irq 309 [ 0.042346] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042463] installing Xen timer for CPU 7 [ 0.042479] cpu 7 spinlock event irq 315 [ 0.042636] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042669] Brought up 8 CPUs [ 0.042898] devtmpfs: initialized [ 0.045573] EVM: security.selinux [ 0.045578] EVM: security.SMACK64 [ 0.045582] EVM: security.capability [ 0.045658] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045658] Grant table initialized [ 0.045658] print_constraints: dummy:=20 [ 0.045658] RTC time: 21:13:53, date: 05/02/12 [ 0.045658] NET: Registered protocol family 16 [ 0.045658] Trying to unpack rootfs image as initramfs... [ 0.060236] node 0 link 0: io port [1000, ffffff] [ 0.060252] TOM: 00000000e0000000 aka 3584M [ 0.060258] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060269] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060278] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060285] node 0 link 0: mmio [a0000, bffff] [ 0.060293] TOM2: 0000000820000000 aka 33280M [ 0.060298] bus: [00, 1f] on node 0 link 0 [ 0.060303] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060307] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060312] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060317] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060338] Extended Config Space enabled on 2 nodes [ 0.060506] ACPI: bus type pci registered [ 0.060613] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060622] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.116338] Freeing initrd memory: 40072k freed [ 0.147622] PCI: Using configuration type 1 for base access [ 0.149637] bio: create slab at 0 [ 0.149637] ACPI: Added _OSI(Module Device) [ 0.149637] ACPI: Added _OSI(Processor Device) [ 0.149637] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.149637] ACPI: Added _OSI(Processor Aggregator Device) [ 0.152152] ACPI: EC: Look up EC in DSDT [ 0.156136] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.177614] ACPI: Interpreter enabled [ 0.177623] ACPI: (supports S0 S1 S4 S5) [ 0.177668] ACPI: Using IOAPIC for interrupt routing [ 0.190794] ACPI: No dock devices found. [ 0.190868] HEST: Table parsing has been initialized. [ 0.190875] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.191175] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.191767] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.191774] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.191780] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.191786] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.191793] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.191834] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.192011] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.192087] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.192205] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.192214] pci 0000:00:09.0: PME# disabled [ 0.192256] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.192372] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.192380] pci 0000:00:0a.0: PME# disabled [ 0.192440] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.192477] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.192498] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.192517] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.192537] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.192557] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.192577] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.192685] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.192712] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.192839] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.192866] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.193000] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.193037] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.193195] pci 0000:00:12.2: supports D1 D2 [ 0.193200] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.193210] pci 0000:00:12.2: PME# disabled [ 0.193249] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.193276] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.193400] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.193429] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.193571] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.193609] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.193767] pci 0000:00:13.2: supports D1 D2 [ 0.193772] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.193781] pci 0000:00:13.2: PME# disabled [ 0.193826] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.194017] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.194160] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.194245] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.194273] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.194416] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.194545] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.194606] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.194671] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.194761] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.194873] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.194990] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.195056] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.195123] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.195215] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.195431] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.195464] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.195509] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.195534] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.195712] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.195723] pci 0000:03:00.0: PME# disabled [ 0.204050] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.204064] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.204074] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.204196] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.204231] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.204275] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.204300] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.204486] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.204498] pci 0000:02:00.0: PME# disabled [ 0.212049] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.212063] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.212071] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.212139] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.212178] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.212201] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.212224] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.212432] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.212446] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.212457] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.212463] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.212469] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.212475] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.212482] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.212488] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.212546] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.212959] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.213031] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.213142] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.213317] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.213325] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.213331] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.231035] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.231173] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.231307] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.231444] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.231577] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.231709] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.231843] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.231976] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.232013] xen/balloon: Initialising balloon driver. [ 0.272380] xen-balloon: Initialising balloon driver. [ 0.272411] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.272584] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.272591] vgaarb: loaded [ 0.272594] vgaarb: bridge control possible 0000:01:04.0 [ 0.272737] i2c-core: driver [aat2870] using legacy suspend method [ 0.272742] i2c-core: driver [aat2870] using legacy resume method [ 0.272839] SCSI subsystem initialized [ 0.275640] libata version 3.00 loaded. [ 0.275640] usbcore: registered new interface driver usbfs [ 0.275640] usbcore: registered new interface driver hub [ 0.275640] usbcore: registered new device driver usb [ 0.275640] PCI: Using ACPI for IRQ routing [ 0.276016] PCI: pci_cache_line_size set to 64 bytes [ 0.276016] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.276016] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.276016] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.288133] NetLabel: Initializing [ 0.288138] NetLabel: domain hash size =3D 128 [ 0.288142] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.288162] NetLabel: unlabeled traffic allowed by default [ 0.288279] Switching to clocksource xen [ 0.297286] AppArmor: AppArmor Filesystem Enabled [ 0.297330] pnp: PnP ACPI init [ 0.297351] ACPI: bus type pnp registered [ 0.297714] pnp 00:00: [bus 00-ff] [ 0.297720] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.297729] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.297734] pnp 00:00: [io 0x0d00-0xffff window] [ 0.297740] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.297745] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.297750] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.297756] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.297874] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.298146] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.298152] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.298227] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.298413] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.298478] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.298485] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.299138] pnp 00:03: [dma 4] [ 0.299143] pnp 00:03: [io 0x0000-0x000f] [ 0.299148] pnp 00:03: [io 0x0081-0x0083] [ 0.299152] pnp 00:03: [io 0x0087] [ 0.299157] pnp 00:03: [io 0x0089-0x008b] [ 0.299161] pnp 00:03: [io 0x008f] [ 0.299165] pnp 00:03: [io 0x00c0-0x00df] [ 0.299223] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.299250] pnp 00:04: [io 0x0070-0x0071] [ 0.299257] xen: registering gsi 8 triggering 1 polarity 0 [ 0.299267] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.299272] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.299290] pnp 00:04: [irq 8] [ 0.299344] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.299415] pnp 00:05: [io 0x0060] [ 0.299419] pnp 00:05: [io 0x0064] [ 0.299424] xen: registering gsi 1 triggering 1 polarity 0 [ 0.299429] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.299434] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.299450] pnp 00:05: [irq 1] [ 0.299509] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.299623] xen: registering gsi 12 triggering 1 polarity 0 [ 0.299630] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.299634] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.299648] pnp 00:06: [irq 12] [ 0.299707] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.299729] pnp 00:07: [io 0x0061] [ 0.299783] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.299804] pnp 00:08: [io 0x00f0-0x00ff] [ 0.299809] xen: registering gsi 13 triggering 1 polarity 0 [ 0.299815] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.299819] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.299836] pnp 00:08: [irq 13] [ 0.299895] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.300116] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.300123] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.300129] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.300213] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.300220] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.300302] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.300364] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.300662] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.300667] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.300747] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.300754] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.300761] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.301257] pnp 00:0c: [io 0x0010-0x001f] [ 0.301262] pnp 00:0c: [io 0x0022-0x003f] [ 0.301267] pnp 00:0c: [io 0x0062-0x0063] [ 0.301298] pnp 00:0c: [io 0x0065-0x006f] [ 0.301302] pnp 00:0c: [io 0x0072-0x007f] [ 0.301307] pnp 00:0c: [io 0x0080] [ 0.301311] pnp 00:0c: [io 0x0084-0x0086] [ 0.301315] pnp 00:0c: [io 0x0088] [ 0.301320] pnp 00:0c: [io 0x008c-0x008e] [ 0.301324] pnp 00:0c: [io 0x0090-0x009f] [ 0.301329] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.301336] pnp 00:0c: [io 0x00b1] [ 0.301341] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.301345] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.301350] pnp 00:0c: [io 0x0550-0x0551] [ 0.301354] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.301359] pnp 00:0c: [io 0x040b] [ 0.301363] pnp 00:0c: [io 0x04d6] [ 0.301367] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.301372] pnp 00:0c: [io 0x0c14] [ 0.301376] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.301380] pnp 00:0c: [io 0x0c52] [ 0.301384] pnp 00:0c: [io 0x0c6c] [ 0.301389] pnp 00:0c: [io 0x0c6f] [ 0.301393] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.301397] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.301402] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.301406] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.301411] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.301415] pnp 00:0c: [io 0x0800-0x089f] [ 0.301420] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.301425] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.301430] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.301434] pnp 00:0c: [io 0x0900-0x090f] [ 0.301439] pnp 00:0c: [io 0x0910-0x091f] [ 0.301443] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.301448] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.301453] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.301458] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.301463] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.301575] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.301582] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.301588] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.301594] system 00:0c: [io 0x040b] has been reserved [ 0.301599] system 00:0c: [io 0x04d6] has been reserved [ 0.301605] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.301610] system 00:0c: [io 0x0c14] has been reserved [ 0.301616] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.301622] system 00:0c: [io 0x0c52] has been reserved [ 0.301627] system 00:0c: [io 0x0c6c] has been reserved [ 0.301633] system 00:0c: [io 0x0c6f] has been reserved [ 0.301638] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.301644] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.301650] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.301659] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.301665] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.301671] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.301677] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.301683] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.301689] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.301695] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.301701] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.301708] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.301714] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.301721] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.302275] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.302280] xen: registering gsi 4 triggering 1 polarity 0 [ 0.302286] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.302291] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.302304] pnp 00:0d: [irq 4] [ 0.302308] pnp 00:0d: [dma 0 disabled] [ 0.302436] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.302979] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.302984] xen: registering gsi 3 triggering 1 polarity 0 [ 0.302990] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.302995] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.302999] Already setup the GSI :3 [ 0.303004] pnp 00:0e: [irq 3] [ 0.303008] pnp 00:0e: [dma 0 disabled] [ 0.303124] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.303267] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.303358] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.303365] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.304306] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.304311] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.304316] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.304322] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.304327] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.304426] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.304433] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.304439] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.304445] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.304452] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.304459] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.304761] pnp: PnP ACPI: found 17 devices [ 0.304766] ACPI: ACPI bus type pnp unregistered [ 0.310401] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.310428] PCI: max bus depth: 1 pci_try_num: 2 [ 0.310470] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.310478] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.310487] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.310502] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.310508] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.310518] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.310532] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.310543] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.310553] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.310576] xen: registering gsi 17 triggering 0 polarity 1 [ 0.310598] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.310614] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.310624] pci 0000:00:09.0: setting latency timer to 64 [ 0.310636] xen: registering gsi 18 triggering 0 polarity 1 [ 0.310646] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.310659] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.310667] pci 0000:00:0a.0: setting latency timer to 64 [ 0.310683] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.310689] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.310694] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.310700] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.310705] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.310711] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.310717] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.310723] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.310728] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.310735] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.310741] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.310747] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.310752] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.310758] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.310764] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.310770] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.310826] NET: Registered protocol family 2 [ 0.312885] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.318088] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.321255] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.321597] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.321604] TCP reno registered [ 0.321733] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.321994] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.322246] NET: Registered protocol family 1 [ 0.322302] xen: registering gsi 16 triggering 0 polarity 1 [ 0.322326] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.322347] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.052170] pci 0000:00:12.0: PCI INT A disabled [ 1.052202] xen: registering gsi 16 triggering 0 polarity 1 [ 1.052216] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.052221] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.052227] Already setup the GSI :16 [ 1.052233] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.136169] pci 0000:00:12.1: PCI INT A disabled [ 1.136202] xen: registering gsi 17 triggering 0 polarity 1 [ 1.136216] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.136221] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.136227] Already setup the GSI :17 [ 1.136233] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.136369] pci 0000:00:12.2: PCI INT B disabled [ 1.136385] xen: registering gsi 18 triggering 0 polarity 1 [ 1.136391] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.136396] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.136400] Already setup the GSI :18 [ 1.136405] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.220155] pci 0000:00:13.0: PCI INT A disabled [ 1.220185] xen: registering gsi 18 triggering 0 polarity 1 [ 1.220199] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.220204] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.220209] Already setup the GSI :18 [ 1.220215] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.304177] pci 0000:00:13.1: PCI INT A disabled [ 1.304210] xen: registering gsi 19 triggering 0 polarity 1 [ 1.304236] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.304255] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.304390] pci 0000:00:13.2: PCI INT B disabled [ 1.304416] xen: registering gsi 18 triggering 0 polarity 1 [ 1.304422] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.304426] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.304431] Already setup the GSI :18 [ 1.304436] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.388174] pci 0000:00:14.5: PCI INT C disabled [ 1.388260] pci 0000:01:04.0: Boot video device [ 1.388268] PCI: CLS 64 bytes, default 64 [ 1.389229] audit: initializing netlink socket (disabled) [ 1.389247] type=3D2000 audit(1335993234.672:1): initialized [ 1.416904] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.419035] VFS: Disk quotas dquot_6.5.2 [ 1.419116] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.419802] fuse init (API version 7.17) [ 1.419911] msgmni has been set to 1479 [ 1.420488] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.420542] io scheduler noop registered [ 1.420547] io scheduler deadline registered [ 1.420586] io scheduler cfq registered (default) [ 1.421042] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.421075] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.421261] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.421272] ACPI: Power Button [PWRB] [ 1.421332] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.421340] ACPI: Power Button [PWRF] [ 1.613187] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.613304] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.613478] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.613901] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.617658] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.736114] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.756421] hpet_acpi_add: no address or irqs in _CRS [ 1.756442] Linux agpgart interface v0.103 [ 1.760267] brd: module loaded [ 1.761149] loop: module loaded [ 1.761542] ahci 0000:00:11.0: version 3.0 [ 1.761570] xen: registering gsi 22 triggering 0 polarity 1 [ 1.761594] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.761614] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.761875] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.761884] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.762820] scsi0 : ahci [ 1.762940] scsi1 : ahci [ 1.763038] scsi2 : ahci [ 1.763137] scsi3 : ahci [ 1.763272] scsi4 : ahci [ 1.763366] scsi5 : ahci [ 1.764294] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.764303] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.764310] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.764318] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.764325] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.764332] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.764857] Fixed MDIO Bus: probed [ 1.764883] tun: Universal TUN/TAP device driver, 1.6 [ 1.764888] tun: (C) 1999-2004 Max Krasnyansky [ 1.764952] PPP generic driver version 2.4.2 [ 1.765084] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.765170] xen: registering gsi 17 triggering 0 polarity 1 [ 1.765179] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.765184] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.765189] Already setup the GSI :17 [ 1.765195] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.765229] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.765321] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.765339] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.765438] ehci_hcd 0000:00:12.2: debug port 1 [ 1.765487] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.776123] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.776313] hub 1-0:1.0: USB hub found [ 1.776322] hub 1-0:1.0: 6 ports detected [ 1.776504] xen: registering gsi 19 triggering 0 polarity 1 [ 1.776512] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.776517] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.776522] Already setup the GSI :19 [ 1.776527] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.776562] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.776635] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.776650] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.776725] ehci_hcd 0000:00:13.2: debug port 1 [ 1.776777] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.788099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.788340] hub 2-0:1.0: USB hub found [ 1.788347] hub 2-0:1.0: 6 ports detected [ 1.788477] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.788566] xen: registering gsi 16 triggering 0 polarity 1 [ 1.788575] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.788580] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.788584] Already setup the GSI :16 [ 1.788590] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.788624] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.788695] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.788763] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.848304] hub 3-0:1.0: USB hub found [ 1.848319] hub 3-0:1.0: 3 ports detected [ 1.848475] xen: registering gsi 16 triggering 0 polarity 1 [ 1.848483] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.848487] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.848492] Already setup the GSI :16 [ 1.848497] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.848532] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.848614] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.848653] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.908303] hub 4-0:1.0: USB hub found [ 1.908318] hub 4-0:1.0: 3 ports detected [ 1.908470] xen: registering gsi 18 triggering 0 polarity 1 [ 1.908477] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.908482] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.908487] Already setup the GSI :18 [ 1.908492] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.908527] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.908596] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.908665] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 1.968287] hub 5-0:1.0: USB hub found [ 1.968308] hub 5-0:1.0: 3 ports detected [ 1.968501] xen: registering gsi 18 triggering 0 polarity 1 [ 1.968508] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.968513] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.968518] Already setup the GSI :18 [ 1.968523] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.968558] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 1.968631] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 1.968670] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.028317] hub 6-0:1.0: USB hub found [ 2.028331] hub 6-0:1.0: 3 ports detected [ 2.028487] xen: registering gsi 18 triggering 0 polarity 1 [ 2.028494] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.028499] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.028504] Already setup the GSI :18 [ 2.028509] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.028544] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.028615] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.028669] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.084219] ata5: SATA link down (SStatus 0 SControl 300) [ 2.088443] hub 7-0:1.0: USB hub found [ 2.088456] hub 7-0:1.0: 2 ports detected [ 2.088560] uhci_hcd: USB Universal Host Controller Interface driver [ 2.088655] usbcore: registered new interface driver libusual [ 2.088719] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.091633] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.091646] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.091822] mousedev: PS/2 mouse device common for all mice [ 2.092082] rtc_cmos 00:04: RTC can wake from S4 [ 2.092261] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.092312] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.092417] device-mapper: uevent: version 1.0.3 [ 2.092508] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.092521] EFI Variables Facility v0.08 2004-May-17 [ 2.092838] TCP cubic registered [ 2.092964] NET: Registered protocol family 10 [ 2.093679] NET: Registered protocol family 17 [ 2.093706] Registering the dns_resolver key type [ 2.093911] PM: Hibernation image not present or could not be loaded. [ 2.093929] registered taskstats version 1 [ 2.100091] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.111457] Magic number: 12:538:246 [ 2.111644] rtc_cmos 00:04: setting system clock to 2012-05-02 21:13:5= 5 UTC (1335993235) [ 2.111775] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.111880] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.111885] EDD information not available. [ 2.124184] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.238732] Initializing USB Mass Storage driver... [ 2.239162] scsi6 : usb-storage 2-2:1.0 [ 2.239275] usbcore: registered new interface driver usb-storage [ 2.239280] USB Mass Storage support registered. [ 2.256136] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256171] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256200] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256224] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256247] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.256783] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.257232] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257240] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257267] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257275] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257295] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257302] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257315] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257323] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257541] ata6.00: configured for UDMA/100 [ 2.258423] ata4.00: configured for UDMA/133 [ 2.258588] ata1.00: configured for UDMA/133 [ 2.258739] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.258905] ata2.00: configured for UDMA/133 [ 2.258926] ata3.00: configured for UDMA/133 [ 2.258971] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.259009] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259202] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.259382] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259406] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.259438] sd 0:0:0:0: [sda] Write Protect is off [ 2.259444] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.259477] sd 1:0:0:0: [sdb] Write Protect is off [ 2.259484] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.259539] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.259546] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.259685] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.259907] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259999] sd 2:0:0:0: [sdc] Write Protect is off [ 2.260006] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.260045] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.260158] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.260424] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.260574] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.260604] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.260664] sd 3:0:0:0: [sdd] Write Protect is off [ 2.260671] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.260767] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.261308] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.264878] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.264887] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.265053] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.265146] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.272079] sdd: unknown partition table [ 2.272315] sdc: unknown partition table [ 2.272574] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.272677] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.273624] sdb: sdb1 sdb2 [ 2.274072] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.379876] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.381137] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.381861] Freeing unused kernel memory: 920k freed [ 2.382200] Write protecting the kernel read-only data: 12288k [ 2.389556] Freeing unused kernel memory: 1520k freed [ 2.390733] Freeing unused kernel memory: 1140k freed [ 2.455991] udevd[165]: starting version 175 [ 2.507331] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.507341] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.510219] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.510250] xen: registering gsi 17 triggering 0 polarity 1 [ 2.510266] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.510276] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.510282] Already setup the GSI :17 [ 2.510288] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.510322] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.608120] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.618454] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.618464] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.618549] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.618727] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.618753] xen: registering gsi 18 triggering 0 polarity 1 [ 2.618765] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.618771] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.618808] Already setup the GSI :18 [ 2.618815] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.618846] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.732995] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.733004] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.733089] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.786470] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.786696] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.790396] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.790549] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.790575] usbcore: registered new interface driver usbhid [ 2.790581] usbhid: USB HID core driver [ 3.237118] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.237728] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.238358] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.238989] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.240411] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.240716] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.241062] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.241431] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.247202] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.248706] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.249442] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.256349] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 8.779984] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.660572] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.660584] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.681388] udevd[720]: starting version 175 [ 15.783292] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.805250] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.806887] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.807066] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.811003] lp: driver loaded but no devices found [ 15.816683] device-mapper: multipath: version 1.3.0 loaded [ 15.822147] Bridge firewalling registered [ 15.824789] ipmi message handler version 39.2 [ 15.826134] ipmi device interface [ 15.831918] IPMI System Interface driver. [ 15.832013] ipmi_si: probing via SMBIOS [ 15.832018] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.832022] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.832029] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.840762] device eth0 entered promiscuous mode [ 15.847580] type=3D1400 audit(1335993249.231:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D864 comm=3D"appar= mor_parser" [ 15.848208] type=3D1400 audit(1335993249.235:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D864 comm=3D"apparmor_parser" [ 15.848556] type=3D1400 audit(1335993249.235:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D864 comm=3D"apparmor_parser" [ 15.884399] MCE: In-kernel MCE decoding enabled. [ 15.885625] EDAC MC: Ver: 2.1.0 [ 15.892212] AMD64 EDAC driver v3.4.0 [ 15.893098] EDAC amd64: DRAM ECC enabled. [ 15.893140] EDAC amd64: F10h detected (node 0). [ 15.893209] EDAC MC: DCT0 chip selects: [ 15.893213] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.893216] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.893220] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.893223] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.893228] EDAC MC: DCT1 chip selects: [ 15.893231] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.893234] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.893237] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.893240] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.893243] EDAC amd64: using x8 syndromes. [ 15.893246] EDAC amd64: MCT channel count: 2 [ 15.893295] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.893302] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.893305] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.893308] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.893378] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.894468] EDAC amd64: DRAM ECC enabled. [ 15.894474] EDAC amd64: F10h detected (node 1). [ 15.894543] EDAC MC: DCT0 chip selects: [ 15.894547] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.894550] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.894553] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.894556] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.894559] EDAC MC: DCT1 chip selects: [ 15.894562] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.894565] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.894569] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.894572] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.894575] EDAC amd64: using x8 syndromes. [ 15.894578] EDAC amd64: MCT channel count: 2 [ 15.894604] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.894607] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.894610] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.894613] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.894673] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.894979] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.935526] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.936109] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.984439] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.984585] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.013572] ADDRCONF(NETDEV_UP): br0: link is not ready [ 16.061669] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.123574] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.967731] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.073284] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 18.985096] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 18.987513] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.987651] br0: port 1(eth0) entering forwarding state [ 18.987668] br0: port 1(eth0) entering forwarding state [ 18.990136] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 21.841738] init: udev-fallback-graphics main process (1843) terminate= d with status 1 [ 21.982235] init: failsafe main process (1722) killed by TERM signal [ 22.095449] type=3D1400 audit(1335993255.479:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1935 comm=3D"apparmor_parser" [ 22.095590] type=3D1400 audit(1335993255.479:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1933 comm=3D"a= pparmor_parser" [ 22.095641] type=3D1400 audit(1335993255.479:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1936 comm=3D"= apparmor_parser" [ 22.096279] type=3D1400 audit(1335993255.483:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1933 comm=3D"apparmor_parser" [ 22.096619] type=3D1400 audit(1335993255.483:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1933 comm=3D"apparmor_parser" [ 22.096934] type=3D1400 audit(1335993255.483:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1937 c= omm=3D"apparmor_parser" [ 22.097294] type=3D1400 audit(1335993255.483:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1937 comm=3D"apparmor_parser" [ 22.097727] type=3D1400 audit(1335993255.483:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1939 comm=3D"= apparmor_parser" [ 22.375521] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 22.603449] ip_tables: (C) 2000-2006 Netfilter Core Team [ 22.705577] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 22.759236] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 23.067948] Event-channel device installed. [ 23.131264] XENBUS: Unable to read cpu state [ 23.131474] XENBUS: Unable to read cpu state [ 23.131666] XENBUS: Unable to read cpu state [ 23.131850] XENBUS: Unable to read cpu state [ 23.132087] XENBUS: Unable to read cpu state [ 23.132254] XENBUS: Unable to read cpu state [ 23.132396] XENBUS: Unable to read cpu state [ 23.132515] XENBUS: Unable to read cpu state [ 24.071993] Ebtables v2.0 registered [ 24.102932] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.788091] br0: no IPv6 routers present [ 46.145335] xen-acpi-processor: Max ACPI ID: 16 [ 126.303979] xen-acpi-processor: Max ACPI ID: 16 --------------040008000906090802060103-- --------------enig2E4FEB681D5F888C5BCE183E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoadIAAoJEOhnXe7L7s6jE5EP/jOjpEj2FTAmJYez3SVK5mMo nPq51jkZx4e/aC7DtSvwBgt1CuOQsxqlh8F7Pm9k9GTd4oOwCt9QX/0RnysB5xY3 f/GRF7oyxkfpmuU3+uso5DLuUGma7VXPrGG1CCz2Bm87OIueo7lnycyZmL2fqCX7 3YfDytjcvA9woiAxkGpASq+4gBlwnog7SM5iGifjfaxS2T/7YfPP5bJzFHAxg/bd jWJ0Iwf4kRKySjhNp0Q7QYUHeOHeZzp3fYQ74UHpnLxjCpSbKlLMIszV7NL3Tdnv 8R40fJJgtclVh8WtzDVJFf6HBfuMh5xKigngPuwqToCvBHwrHf8H9E6W9nn9alt2 cBuWwCNfcb8ktdOuYjpRj3RE5/8lbTTBMLmTY/VhLlATq6UwoTF61UzzGoNFnILR Fba9zdmwpwa0YcolYiLgKSAcSroEwOIrv8tMeehOSrcsJMvXxxsuOFzQXo3sxrFv MCalqAs22nTeCHnE/W96e+1zRux3B/mb1+znaSOsnP4rfB/nC5lAuZU6KZmXNCdA NvhwZ45g4bxf6LyjgaiDroYmoGVXPGp4PznXayz8nHvhfAl6dHi0FXK+fQtHKGiE yJGTDh7yFbtv7wheyAcgZDBsozLo0t9XlnJYrePp+vlfylze4EKlqMnsx4oT8eUQ 6rQ6/tNXxVVsxJcdVH8l =cu2N -----END PGP SIGNATURE----- --------------enig2E4FEB681D5F888C5BCE183E-- --===============8639842970269748413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8639842970269748413==-- From xen-devel-bounces@lists.xen.org Wed May 02 21:30:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21:30:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh7T-0004pD-C4; Wed, 02 May 2012 21:29:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh7R-0004p8-6p for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:29:53 +0000 Received: from [193.109.254.147:38218] by server-6.bemta-14.messagelabs.com id BA/2C-04960-057A1AF4; Wed, 02 May 2012 21:29:52 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1335994188!4912202!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6707 invoked from network); 2 May 2012 21:29:48 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-5.tower-27.messagelabs.com with SMTP; 2 May 2012 21:29:48 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPh7K-0004iD-KC; Wed, 02 May 2012 21:29:47 +0000 Message-ID: <4FA1A747.5080909@canonical.com> Date: Wed, 02 May 2012 23:29:43 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> In-Reply-To: <20120502160812.GA6611@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8639842970269748413==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8639842970269748413== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2E4FEB681D5F888C5BCE183E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E4FEB681D5F888C5BCE183E Content-Type: multipart/mixed; boundary="------------040008000906090802060103" This is a multi-part message in MIME format. --------------040008000906090802060103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.05.2012 18:08, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 05:01:00PM +0200, Stefan Bader wrote: >> On 02.05.2012 00:35, Boris Ostrovsky wrote: >>> On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote: >>>> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote: >>>>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote: >>>>>>> Since there have been requests about that driver to get backporte= d into 3.2, I >>>>>>> was interested to find out what or how much would be gained by th= at. >>>>>>> >>>>>>> The first system I tried was an AMD based one (8 core Opteron 612= 8@2GHz). >>>>>>> Which >>>>>>> was not very successful as the drivers bail out of the init funct= ion >>>>>>> because the >>>>>>> first call to acpi_processor_register_performance() returns -ENOD= EV. There is >>>>>>> some frequency scaling when running without Xen, so I need to do = some more >>>>>>> debugging there. >>> >>> I believe this is caused by the somewhat under-enlightened xen_apic_r= ead(): >>> >>> static u32 xen_apic_read(u32 reg) >>> { >>> return 0; >>> } >>> >>> This results in some data, most importantly boot_cpu_physical_apicid,= not being >>> set correctly and, in turn, causes x86_cpu_to_apicid to be broken. >>> >>> On larger AMD systems boot processor is typically APICID=3D0x20 (I do= n't have >>> Intel system handy to see how it looks there). >>> >>> As a quick and dirty test you can try: >>> >>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.= c >>> index edc2448..1f78998 100644 >>> --- a/arch/x86/kernel/apic/apic.c >>> +++ b/arch/x86/kernel/apic/apic.c >>> @@ -1781,6 +1781,7 @@ void __init register_lapic_address(unsigned lon= g address) >>> } >>> if (boot_cpu_physical_apicid =3D=3D -1U) { >>> boot_cpu_physical_apicid =3D read_apic_id(); >>> + boot_cpu_physical_apicid =3D 32; >>> apic_version[boot_cpu_physical_apicid] =3D >>> GET_APIC_VERSION(apic_read(APIC_LVR)); >>> } >>> >>> >>> (Set it to whatever APICID on core0 is, I suspect it won't be zero). >>> >> >> Indeed, when I hack the above id to be 0x10 (as my dmesg tells) most o= f the BIOS >> bug messages are gone and the xen-acpi-processor driver successfully l= oads and >> seems to be switching frequencies ok (just a quick tight loop which ma= de one cpu >> go from P4 to P0). >=20 > OK. Can you try the attached patch pls? It should do the same thing > as what the debug patch does - get the _real_ APIC ID from the hypervis= or. > (And as bonus it also removes the annoying: >=20 > BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 All the BIOS bug messages are gone from the Intel and the AMD box. Just t= he AMD box again fails to load the xen-acpi-processor driver. Though it must be = a different exit. I had enabled acpi debugging for the modprobe call but th= is time there is no trace of any acpi messages. >=20 >=20 > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..d816448 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -811,7 +811,29 @@ static void xen_io_delay(void) > #ifdef CONFIG_X86_LOCAL_APIC > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op =3D { > + .cmd =3D XENPF_get_cpuinfo, > + .interface_version =3D XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid =3D 0, > + }; > + int ret =3D 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg =3D=3D APIC_LVR) > + return 0x10; > + > + if (reg !=3D APIC_ID) > + return 0; > + > + ret =3D HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id; > } > =20 > static void xen_apic_write(u32 reg, u32 val) >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------040008000906090802060103 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.4" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.4" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (smb@gomeisa) (gcc version = 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg3 SMP Wed May 2 20:48:57= UTC 2012 (Ubuntu 3.2.0-24.38+xendbg3-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.172 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.34 BogoMIPS (lpj=3D8000688) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008000] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016990] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019592] Mount-cache hash table entries: 256 [ 0.019840] Initializing cgroup subsys cpuacct [ 0.019852] Initializing cgroup subsys memory [ 0.019871] Initializing cgroup subsys devices [ 0.019877] Initializing cgroup subsys freezer [ 0.019882] Initializing cgroup subsys blkio [ 0.019898] Initializing cgroup subsys perf_event [ 0.019972] tseg: 00dff00000 [ 0.019980] CPU: Physical Processor ID: 0 [ 0.019984] CPU: Processor Core ID: 0 [ 0.022918] ACPI: Core revision 20110623 [ 0.038976] ftrace: allocating 27102 entries in 107 pages [ 0.040132] cpu 0 spinlock event irq 273 [ 0.040233] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040500] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040631] installing Xen timer for CPU 1 [ 0.040649] cpu 1 spinlock event irq 279 [ 0.040855] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040978] installing Xen timer for CPU 2 [ 0.040996] cpu 2 spinlock event irq 285 [ 0.041153] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041269] installing Xen timer for CPU 3 [ 0.041284] cpu 3 spinlock event irq 291 [ 0.041445] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041562] installing Xen timer for CPU 4 [ 0.041577] cpu 4 spinlock event irq 297 [ 0.041759] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041885] installing Xen timer for CPU 5 [ 0.041901] cpu 5 spinlock event irq 303 [ 0.042060] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042175] installing Xen timer for CPU 6 [ 0.042191] cpu 6 spinlock event irq 309 [ 0.042346] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042463] installing Xen timer for CPU 7 [ 0.042479] cpu 7 spinlock event irq 315 [ 0.042636] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042669] Brought up 8 CPUs [ 0.042898] devtmpfs: initialized [ 0.045573] EVM: security.selinux [ 0.045578] EVM: security.SMACK64 [ 0.045582] EVM: security.capability [ 0.045658] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045658] Grant table initialized [ 0.045658] print_constraints: dummy:=20 [ 0.045658] RTC time: 21:13:53, date: 05/02/12 [ 0.045658] NET: Registered protocol family 16 [ 0.045658] Trying to unpack rootfs image as initramfs... [ 0.060236] node 0 link 0: io port [1000, ffffff] [ 0.060252] TOM: 00000000e0000000 aka 3584M [ 0.060258] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060269] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060278] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060285] node 0 link 0: mmio [a0000, bffff] [ 0.060293] TOM2: 0000000820000000 aka 33280M [ 0.060298] bus: [00, 1f] on node 0 link 0 [ 0.060303] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060307] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060312] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060317] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060338] Extended Config Space enabled on 2 nodes [ 0.060506] ACPI: bus type pci registered [ 0.060613] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060622] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.116338] Freeing initrd memory: 40072k freed [ 0.147622] PCI: Using configuration type 1 for base access [ 0.149637] bio: create slab at 0 [ 0.149637] ACPI: Added _OSI(Module Device) [ 0.149637] ACPI: Added _OSI(Processor Device) [ 0.149637] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.149637] ACPI: Added _OSI(Processor Aggregator Device) [ 0.152152] ACPI: EC: Look up EC in DSDT [ 0.156136] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.177614] ACPI: Interpreter enabled [ 0.177623] ACPI: (supports S0 S1 S4 S5) [ 0.177668] ACPI: Using IOAPIC for interrupt routing [ 0.190794] ACPI: No dock devices found. [ 0.190868] HEST: Table parsing has been initialized. [ 0.190875] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.191175] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.191767] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.191774] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.191780] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.191786] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.191793] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.191834] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.192011] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.192087] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.192205] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.192214] pci 0000:00:09.0: PME# disabled [ 0.192256] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.192372] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.192380] pci 0000:00:0a.0: PME# disabled [ 0.192440] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.192477] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.192498] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.192517] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.192537] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.192557] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.192577] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.192685] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.192712] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.192839] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.192866] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.193000] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.193037] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.193195] pci 0000:00:12.2: supports D1 D2 [ 0.193200] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.193210] pci 0000:00:12.2: PME# disabled [ 0.193249] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.193276] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.193400] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.193429] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.193571] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.193609] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.193767] pci 0000:00:13.2: supports D1 D2 [ 0.193772] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.193781] pci 0000:00:13.2: PME# disabled [ 0.193826] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.194017] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.194160] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.194245] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.194273] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.194416] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.194545] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.194606] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.194671] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.194761] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.194873] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.194990] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.195056] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.195123] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.195215] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.195431] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.195464] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.195509] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.195534] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.195712] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.195723] pci 0000:03:00.0: PME# disabled [ 0.204050] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.204064] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.204074] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.204196] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.204231] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.204275] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.204300] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.204486] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.204498] pci 0000:02:00.0: PME# disabled [ 0.212049] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.212063] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.212071] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.212139] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.212178] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.212201] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.212224] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.212432] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.212446] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.212457] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.212463] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.212469] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.212475] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.212482] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.212488] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.212546] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.212959] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.213031] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.213142] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.213317] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.213325] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.213331] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.231035] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.231173] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.231307] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.231444] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.231577] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.231709] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.231843] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.231976] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.232013] xen/balloon: Initialising balloon driver. [ 0.272380] xen-balloon: Initialising balloon driver. [ 0.272411] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.272584] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.272591] vgaarb: loaded [ 0.272594] vgaarb: bridge control possible 0000:01:04.0 [ 0.272737] i2c-core: driver [aat2870] using legacy suspend method [ 0.272742] i2c-core: driver [aat2870] using legacy resume method [ 0.272839] SCSI subsystem initialized [ 0.275640] libata version 3.00 loaded. [ 0.275640] usbcore: registered new interface driver usbfs [ 0.275640] usbcore: registered new interface driver hub [ 0.275640] usbcore: registered new device driver usb [ 0.275640] PCI: Using ACPI for IRQ routing [ 0.276016] PCI: pci_cache_line_size set to 64 bytes [ 0.276016] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.276016] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.276016] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.288133] NetLabel: Initializing [ 0.288138] NetLabel: domain hash size =3D 128 [ 0.288142] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.288162] NetLabel: unlabeled traffic allowed by default [ 0.288279] Switching to clocksource xen [ 0.297286] AppArmor: AppArmor Filesystem Enabled [ 0.297330] pnp: PnP ACPI init [ 0.297351] ACPI: bus type pnp registered [ 0.297714] pnp 00:00: [bus 00-ff] [ 0.297720] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.297729] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.297734] pnp 00:00: [io 0x0d00-0xffff window] [ 0.297740] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.297745] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.297750] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.297756] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.297874] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.298146] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.298152] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.298227] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.298413] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.298478] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.298485] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.299138] pnp 00:03: [dma 4] [ 0.299143] pnp 00:03: [io 0x0000-0x000f] [ 0.299148] pnp 00:03: [io 0x0081-0x0083] [ 0.299152] pnp 00:03: [io 0x0087] [ 0.299157] pnp 00:03: [io 0x0089-0x008b] [ 0.299161] pnp 00:03: [io 0x008f] [ 0.299165] pnp 00:03: [io 0x00c0-0x00df] [ 0.299223] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.299250] pnp 00:04: [io 0x0070-0x0071] [ 0.299257] xen: registering gsi 8 triggering 1 polarity 0 [ 0.299267] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.299272] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.299290] pnp 00:04: [irq 8] [ 0.299344] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.299415] pnp 00:05: [io 0x0060] [ 0.299419] pnp 00:05: [io 0x0064] [ 0.299424] xen: registering gsi 1 triggering 1 polarity 0 [ 0.299429] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.299434] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.299450] pnp 00:05: [irq 1] [ 0.299509] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.299623] xen: registering gsi 12 triggering 1 polarity 0 [ 0.299630] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.299634] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.299648] pnp 00:06: [irq 12] [ 0.299707] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.299729] pnp 00:07: [io 0x0061] [ 0.299783] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.299804] pnp 00:08: [io 0x00f0-0x00ff] [ 0.299809] xen: registering gsi 13 triggering 1 polarity 0 [ 0.299815] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.299819] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.299836] pnp 00:08: [irq 13] [ 0.299895] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.300116] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.300123] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.300129] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.300213] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.300220] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.300302] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.300364] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.300662] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.300667] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.300747] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.300754] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.300761] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.301257] pnp 00:0c: [io 0x0010-0x001f] [ 0.301262] pnp 00:0c: [io 0x0022-0x003f] [ 0.301267] pnp 00:0c: [io 0x0062-0x0063] [ 0.301298] pnp 00:0c: [io 0x0065-0x006f] [ 0.301302] pnp 00:0c: [io 0x0072-0x007f] [ 0.301307] pnp 00:0c: [io 0x0080] [ 0.301311] pnp 00:0c: [io 0x0084-0x0086] [ 0.301315] pnp 00:0c: [io 0x0088] [ 0.301320] pnp 00:0c: [io 0x008c-0x008e] [ 0.301324] pnp 00:0c: [io 0x0090-0x009f] [ 0.301329] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.301336] pnp 00:0c: [io 0x00b1] [ 0.301341] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.301345] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.301350] pnp 00:0c: [io 0x0550-0x0551] [ 0.301354] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.301359] pnp 00:0c: [io 0x040b] [ 0.301363] pnp 00:0c: [io 0x04d6] [ 0.301367] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.301372] pnp 00:0c: [io 0x0c14] [ 0.301376] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.301380] pnp 00:0c: [io 0x0c52] [ 0.301384] pnp 00:0c: [io 0x0c6c] [ 0.301389] pnp 00:0c: [io 0x0c6f] [ 0.301393] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.301397] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.301402] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.301406] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.301411] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.301415] pnp 00:0c: [io 0x0800-0x089f] [ 0.301420] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.301425] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.301430] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.301434] pnp 00:0c: [io 0x0900-0x090f] [ 0.301439] pnp 00:0c: [io 0x0910-0x091f] [ 0.301443] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.301448] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.301453] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.301458] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.301463] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.301575] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.301582] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.301588] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.301594] system 00:0c: [io 0x040b] has been reserved [ 0.301599] system 00:0c: [io 0x04d6] has been reserved [ 0.301605] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.301610] system 00:0c: [io 0x0c14] has been reserved [ 0.301616] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.301622] system 00:0c: [io 0x0c52] has been reserved [ 0.301627] system 00:0c: [io 0x0c6c] has been reserved [ 0.301633] system 00:0c: [io 0x0c6f] has been reserved [ 0.301638] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.301644] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.301650] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.301659] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.301665] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.301671] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.301677] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.301683] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.301689] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.301695] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.301701] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.301708] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.301714] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.301721] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.302275] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.302280] xen: registering gsi 4 triggering 1 polarity 0 [ 0.302286] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.302291] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.302304] pnp 00:0d: [irq 4] [ 0.302308] pnp 00:0d: [dma 0 disabled] [ 0.302436] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.302979] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.302984] xen: registering gsi 3 triggering 1 polarity 0 [ 0.302990] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.302995] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.302999] Already setup the GSI :3 [ 0.303004] pnp 00:0e: [irq 3] [ 0.303008] pnp 00:0e: [dma 0 disabled] [ 0.303124] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.303267] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.303358] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.303365] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.304306] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.304311] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.304316] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.304322] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.304327] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.304426] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.304433] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.304439] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.304445] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.304452] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.304459] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.304761] pnp: PnP ACPI: found 17 devices [ 0.304766] ACPI: ACPI bus type pnp unregistered [ 0.310401] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.310428] PCI: max bus depth: 1 pci_try_num: 2 [ 0.310470] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.310478] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.310487] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.310502] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.310508] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.310518] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.310532] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.310543] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.310553] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.310576] xen: registering gsi 17 triggering 0 polarity 1 [ 0.310598] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.310614] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.310624] pci 0000:00:09.0: setting latency timer to 64 [ 0.310636] xen: registering gsi 18 triggering 0 polarity 1 [ 0.310646] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.310659] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.310667] pci 0000:00:0a.0: setting latency timer to 64 [ 0.310683] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.310689] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.310694] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.310700] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.310705] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.310711] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.310717] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.310723] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.310728] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.310735] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.310741] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.310747] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.310752] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.310758] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.310764] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.310770] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.310826] NET: Registered protocol family 2 [ 0.312885] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.318088] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.321255] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.321597] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.321604] TCP reno registered [ 0.321733] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.321994] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.322246] NET: Registered protocol family 1 [ 0.322302] xen: registering gsi 16 triggering 0 polarity 1 [ 0.322326] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.322347] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.052170] pci 0000:00:12.0: PCI INT A disabled [ 1.052202] xen: registering gsi 16 triggering 0 polarity 1 [ 1.052216] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.052221] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.052227] Already setup the GSI :16 [ 1.052233] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.136169] pci 0000:00:12.1: PCI INT A disabled [ 1.136202] xen: registering gsi 17 triggering 0 polarity 1 [ 1.136216] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.136221] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.136227] Already setup the GSI :17 [ 1.136233] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.136369] pci 0000:00:12.2: PCI INT B disabled [ 1.136385] xen: registering gsi 18 triggering 0 polarity 1 [ 1.136391] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.136396] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.136400] Already setup the GSI :18 [ 1.136405] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.220155] pci 0000:00:13.0: PCI INT A disabled [ 1.220185] xen: registering gsi 18 triggering 0 polarity 1 [ 1.220199] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.220204] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.220209] Already setup the GSI :18 [ 1.220215] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.304177] pci 0000:00:13.1: PCI INT A disabled [ 1.304210] xen: registering gsi 19 triggering 0 polarity 1 [ 1.304236] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.304255] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.304390] pci 0000:00:13.2: PCI INT B disabled [ 1.304416] xen: registering gsi 18 triggering 0 polarity 1 [ 1.304422] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.304426] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.304431] Already setup the GSI :18 [ 1.304436] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.388174] pci 0000:00:14.5: PCI INT C disabled [ 1.388260] pci 0000:01:04.0: Boot video device [ 1.388268] PCI: CLS 64 bytes, default 64 [ 1.389229] audit: initializing netlink socket (disabled) [ 1.389247] type=3D2000 audit(1335993234.672:1): initialized [ 1.416904] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.419035] VFS: Disk quotas dquot_6.5.2 [ 1.419116] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.419802] fuse init (API version 7.17) [ 1.419911] msgmni has been set to 1479 [ 1.420488] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.420542] io scheduler noop registered [ 1.420547] io scheduler deadline registered [ 1.420586] io scheduler cfq registered (default) [ 1.421042] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.421075] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.421261] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.421272] ACPI: Power Button [PWRB] [ 1.421332] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.421340] ACPI: Power Button [PWRF] [ 1.613187] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.613304] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.613478] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.613901] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.617658] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.736114] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.756421] hpet_acpi_add: no address or irqs in _CRS [ 1.756442] Linux agpgart interface v0.103 [ 1.760267] brd: module loaded [ 1.761149] loop: module loaded [ 1.761542] ahci 0000:00:11.0: version 3.0 [ 1.761570] xen: registering gsi 22 triggering 0 polarity 1 [ 1.761594] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.761614] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.761875] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.761884] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.762820] scsi0 : ahci [ 1.762940] scsi1 : ahci [ 1.763038] scsi2 : ahci [ 1.763137] scsi3 : ahci [ 1.763272] scsi4 : ahci [ 1.763366] scsi5 : ahci [ 1.764294] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.764303] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.764310] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.764318] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.764325] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.764332] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.764857] Fixed MDIO Bus: probed [ 1.764883] tun: Universal TUN/TAP device driver, 1.6 [ 1.764888] tun: (C) 1999-2004 Max Krasnyansky [ 1.764952] PPP generic driver version 2.4.2 [ 1.765084] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.765170] xen: registering gsi 17 triggering 0 polarity 1 [ 1.765179] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.765184] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.765189] Already setup the GSI :17 [ 1.765195] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.765229] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.765321] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.765339] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.765438] ehci_hcd 0000:00:12.2: debug port 1 [ 1.765487] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.776123] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.776313] hub 1-0:1.0: USB hub found [ 1.776322] hub 1-0:1.0: 6 ports detected [ 1.776504] xen: registering gsi 19 triggering 0 polarity 1 [ 1.776512] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.776517] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.776522] Already setup the GSI :19 [ 1.776527] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.776562] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.776635] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.776650] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.776725] ehci_hcd 0000:00:13.2: debug port 1 [ 1.776777] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.788099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.788340] hub 2-0:1.0: USB hub found [ 1.788347] hub 2-0:1.0: 6 ports detected [ 1.788477] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.788566] xen: registering gsi 16 triggering 0 polarity 1 [ 1.788575] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.788580] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.788584] Already setup the GSI :16 [ 1.788590] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.788624] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.788695] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.788763] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.848304] hub 3-0:1.0: USB hub found [ 1.848319] hub 3-0:1.0: 3 ports detected [ 1.848475] xen: registering gsi 16 triggering 0 polarity 1 [ 1.848483] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.848487] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.848492] Already setup the GSI :16 [ 1.848497] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.848532] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.848614] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.848653] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.908303] hub 4-0:1.0: USB hub found [ 1.908318] hub 4-0:1.0: 3 ports detected [ 1.908470] xen: registering gsi 18 triggering 0 polarity 1 [ 1.908477] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.908482] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.908487] Already setup the GSI :18 [ 1.908492] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.908527] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.908596] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.908665] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 1.968287] hub 5-0:1.0: USB hub found [ 1.968308] hub 5-0:1.0: 3 ports detected [ 1.968501] xen: registering gsi 18 triggering 0 polarity 1 [ 1.968508] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.968513] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.968518] Already setup the GSI :18 [ 1.968523] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.968558] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 1.968631] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 1.968670] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.028317] hub 6-0:1.0: USB hub found [ 2.028331] hub 6-0:1.0: 3 ports detected [ 2.028487] xen: registering gsi 18 triggering 0 polarity 1 [ 2.028494] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.028499] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.028504] Already setup the GSI :18 [ 2.028509] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.028544] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.028615] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.028669] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.084219] ata5: SATA link down (SStatus 0 SControl 300) [ 2.088443] hub 7-0:1.0: USB hub found [ 2.088456] hub 7-0:1.0: 2 ports detected [ 2.088560] uhci_hcd: USB Universal Host Controller Interface driver [ 2.088655] usbcore: registered new interface driver libusual [ 2.088719] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.091633] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.091646] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.091822] mousedev: PS/2 mouse device common for all mice [ 2.092082] rtc_cmos 00:04: RTC can wake from S4 [ 2.092261] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.092312] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.092417] device-mapper: uevent: version 1.0.3 [ 2.092508] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.092521] EFI Variables Facility v0.08 2004-May-17 [ 2.092838] TCP cubic registered [ 2.092964] NET: Registered protocol family 10 [ 2.093679] NET: Registered protocol family 17 [ 2.093706] Registering the dns_resolver key type [ 2.093911] PM: Hibernation image not present or could not be loaded. [ 2.093929] registered taskstats version 1 [ 2.100091] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.111457] Magic number: 12:538:246 [ 2.111644] rtc_cmos 00:04: setting system clock to 2012-05-02 21:13:5= 5 UTC (1335993235) [ 2.111775] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.111880] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.111885] EDD information not available. [ 2.124184] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.238732] Initializing USB Mass Storage driver... [ 2.239162] scsi6 : usb-storage 2-2:1.0 [ 2.239275] usbcore: registered new interface driver usb-storage [ 2.239280] USB Mass Storage support registered. [ 2.256136] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256171] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256200] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256224] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.256247] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.256783] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.257232] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257240] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257267] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257275] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257295] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257302] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257315] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.257323] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.257541] ata6.00: configured for UDMA/100 [ 2.258423] ata4.00: configured for UDMA/133 [ 2.258588] ata1.00: configured for UDMA/133 [ 2.258739] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.258905] ata2.00: configured for UDMA/133 [ 2.258926] ata3.00: configured for UDMA/133 [ 2.258971] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.259009] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259202] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.259382] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259406] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.259438] sd 0:0:0:0: [sda] Write Protect is off [ 2.259444] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.259477] sd 1:0:0:0: [sdb] Write Protect is off [ 2.259484] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.259539] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.259546] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.259685] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.259907] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.259999] sd 2:0:0:0: [sdc] Write Protect is off [ 2.260006] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.260045] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.260158] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.260424] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.260574] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.260604] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.260664] sd 3:0:0:0: [sdd] Write Protect is off [ 2.260671] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.260767] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.261308] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.264878] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.264887] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.265053] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.265146] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.272079] sdd: unknown partition table [ 2.272315] sdc: unknown partition table [ 2.272574] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.272677] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.273624] sdb: sdb1 sdb2 [ 2.274072] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.379876] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.381137] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.381861] Freeing unused kernel memory: 920k freed [ 2.382200] Write protecting the kernel read-only data: 12288k [ 2.389556] Freeing unused kernel memory: 1520k freed [ 2.390733] Freeing unused kernel memory: 1140k freed [ 2.455991] udevd[165]: starting version 175 [ 2.507331] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.507341] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.510219] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.510250] xen: registering gsi 17 triggering 0 polarity 1 [ 2.510266] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.510276] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.510282] Already setup the GSI :17 [ 2.510288] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.510322] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.608120] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.618454] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.618464] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.618549] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.618727] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.618753] xen: registering gsi 18 triggering 0 polarity 1 [ 2.618765] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.618771] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.618808] Already setup the GSI :18 [ 2.618815] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.618846] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.732995] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.733004] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.733089] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.786470] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.786696] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.790396] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.790549] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.790575] usbcore: registered new interface driver usbhid [ 2.790581] usbhid: USB HID core driver [ 3.237118] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.237728] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.238358] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.238989] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.240411] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.240716] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.241062] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.241431] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.247202] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.248706] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.249442] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.256349] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 8.779984] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.660572] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.660584] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.681388] udevd[720]: starting version 175 [ 15.783292] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.805250] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.806887] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.807066] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.811003] lp: driver loaded but no devices found [ 15.816683] device-mapper: multipath: version 1.3.0 loaded [ 15.822147] Bridge firewalling registered [ 15.824789] ipmi message handler version 39.2 [ 15.826134] ipmi device interface [ 15.831918] IPMI System Interface driver. [ 15.832013] ipmi_si: probing via SMBIOS [ 15.832018] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.832022] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.832029] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.840762] device eth0 entered promiscuous mode [ 15.847580] type=3D1400 audit(1335993249.231:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D864 comm=3D"appar= mor_parser" [ 15.848208] type=3D1400 audit(1335993249.235:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D864 comm=3D"apparmor_parser" [ 15.848556] type=3D1400 audit(1335993249.235:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D864 comm=3D"apparmor_parser" [ 15.884399] MCE: In-kernel MCE decoding enabled. [ 15.885625] EDAC MC: Ver: 2.1.0 [ 15.892212] AMD64 EDAC driver v3.4.0 [ 15.893098] EDAC amd64: DRAM ECC enabled. [ 15.893140] EDAC amd64: F10h detected (node 0). [ 15.893209] EDAC MC: DCT0 chip selects: [ 15.893213] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.893216] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.893220] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.893223] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.893228] EDAC MC: DCT1 chip selects: [ 15.893231] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.893234] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.893237] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.893240] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.893243] EDAC amd64: using x8 syndromes. [ 15.893246] EDAC amd64: MCT channel count: 2 [ 15.893295] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.893302] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.893305] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.893308] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.893378] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.894468] EDAC amd64: DRAM ECC enabled. [ 15.894474] EDAC amd64: F10h detected (node 1). [ 15.894543] EDAC MC: DCT0 chip selects: [ 15.894547] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.894550] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.894553] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.894556] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.894559] EDAC MC: DCT1 chip selects: [ 15.894562] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.894565] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.894569] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.894572] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.894575] EDAC amd64: using x8 syndromes. [ 15.894578] EDAC amd64: MCT channel count: 2 [ 15.894604] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.894607] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.894610] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.894613] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.894673] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.894979] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.935526] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.936109] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.984439] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.984585] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.013572] ADDRCONF(NETDEV_UP): br0: link is not ready [ 16.061669] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 16.123574] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.967731] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.073284] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 18.985096] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 18.987513] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.987651] br0: port 1(eth0) entering forwarding state [ 18.987668] br0: port 1(eth0) entering forwarding state [ 18.990136] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 21.841738] init: udev-fallback-graphics main process (1843) terminate= d with status 1 [ 21.982235] init: failsafe main process (1722) killed by TERM signal [ 22.095449] type=3D1400 audit(1335993255.479:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1935 comm=3D"apparmor_parser" [ 22.095590] type=3D1400 audit(1335993255.479:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1933 comm=3D"a= pparmor_parser" [ 22.095641] type=3D1400 audit(1335993255.479:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1936 comm=3D"= apparmor_parser" [ 22.096279] type=3D1400 audit(1335993255.483:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1933 comm=3D"apparmor_parser" [ 22.096619] type=3D1400 audit(1335993255.483:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1933 comm=3D"apparmor_parser" [ 22.096934] type=3D1400 audit(1335993255.483:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1937 c= omm=3D"apparmor_parser" [ 22.097294] type=3D1400 audit(1335993255.483:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1937 comm=3D"apparmor_parser" [ 22.097727] type=3D1400 audit(1335993255.483:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1939 comm=3D"= apparmor_parser" [ 22.375521] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 22.603449] ip_tables: (C) 2000-2006 Netfilter Core Team [ 22.705577] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 22.759236] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 23.067948] Event-channel device installed. [ 23.131264] XENBUS: Unable to read cpu state [ 23.131474] XENBUS: Unable to read cpu state [ 23.131666] XENBUS: Unable to read cpu state [ 23.131850] XENBUS: Unable to read cpu state [ 23.132087] XENBUS: Unable to read cpu state [ 23.132254] XENBUS: Unable to read cpu state [ 23.132396] XENBUS: Unable to read cpu state [ 23.132515] XENBUS: Unable to read cpu state [ 24.071993] Ebtables v2.0 registered [ 24.102932] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.788091] br0: no IPv6 routers present [ 46.145335] xen-acpi-processor: Max ACPI ID: 16 [ 126.303979] xen-acpi-processor: Max ACPI ID: 16 --------------040008000906090802060103-- --------------enig2E4FEB681D5F888C5BCE183E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoadIAAoJEOhnXe7L7s6jE5EP/jOjpEj2FTAmJYez3SVK5mMo nPq51jkZx4e/aC7DtSvwBgt1CuOQsxqlh8F7Pm9k9GTd4oOwCt9QX/0RnysB5xY3 f/GRF7oyxkfpmuU3+uso5DLuUGma7VXPrGG1CCz2Bm87OIueo7lnycyZmL2fqCX7 3YfDytjcvA9woiAxkGpASq+4gBlwnog7SM5iGifjfaxS2T/7YfPP5bJzFHAxg/bd jWJ0Iwf4kRKySjhNp0Q7QYUHeOHeZzp3fYQ74UHpnLxjCpSbKlLMIszV7NL3Tdnv 8R40fJJgtclVh8WtzDVJFf6HBfuMh5xKigngPuwqToCvBHwrHf8H9E6W9nn9alt2 cBuWwCNfcb8ktdOuYjpRj3RE5/8lbTTBMLmTY/VhLlATq6UwoTF61UzzGoNFnILR Fba9zdmwpwa0YcolYiLgKSAcSroEwOIrv8tMeehOSrcsJMvXxxsuOFzQXo3sxrFv MCalqAs22nTeCHnE/W96e+1zRux3B/mb1+znaSOsnP4rfB/nC5lAuZU6KZmXNCdA NvhwZ45g4bxf6LyjgaiDroYmoGVXPGp4PznXayz8nHvhfAl6dHi0FXK+fQtHKGiE yJGTDh7yFbtv7wheyAcgZDBsozLo0t9XlnJYrePp+vlfylze4EKlqMnsx4oT8eUQ 6rQ6/tNXxVVsxJcdVH8l =cu2N -----END PGP SIGNATURE----- --------------enig2E4FEB681D5F888C5BCE183E-- --===============8639842970269748413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8639842970269748413==-- From xen-devel-bounces@lists.xen.org Wed May 02 21:31:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21: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 ) id 1SPh8p-0004tS-5f; Wed, 02 May 2012 21:31:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh8m-0004tI-Pm for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:31:17 +0000 Received: from [85.158.139.83:35941] by server-7.bemta-5.messagelabs.com id 44/94-16195-4A7A1AF4; Wed, 02 May 2012 21:31:16 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1335994273!19249391!1 X-Originating-IP: [65.55.88.11] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32243 invoked from network); 2 May 2012 21:31:15 -0000 Received: from tx2ehsobe001.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.11) by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 21:31:15 -0000 Received: from mail146-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 21:31:04 +0000 Received: from mail146-tx2 (localhost [127.0.0.1]) by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 79D9E4E03C9; Wed, 2 May 2012 21:31:04 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) 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 mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1335994262590893_6156; Wed, 2 May 2012 21:31:02 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.238]) by mail146-tx2.bigfish.com (Postfix) with ESMTP id 7FB1F2202AF; Wed, 2 May 2012 21:31:02 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 21:31:02 +0000 X-WSS-ID: 0M3EZRV-01-CGM-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 26F8410281A2; Wed, 2 May 2012 16:31:07 -0500 (CDT) 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, 2 May 2012 16:31:20 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 16:31:07 -0500 Message-ID: <4FA1A79B.5040701@amd.com> Date: Wed, 2 May 2012 17:31:07 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> In-Reply-To: <20120502171415.GA17477@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>> index a8f8844..d816448 100644 >>> --- a/arch/x86/xen/enlighten.c >>> +++ b/arch/x86/xen/enlighten.c >>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>> #ifdef CONFIG_X86_LOCAL_APIC >>> static u32 xen_apic_read(u32 reg) >>> { >>> - return 0; >>> + struct xen_platform_op op = { >>> + .cmd = XENPF_get_cpuinfo, >>> + .interface_version = XENPF_INTERFACE_VERSION, >>> + .u.pcpu_info.xen_cpuid = 0, >> >> >> Is this always zero? This will probably solve the current problem > > Its a CPU number (not tied in to APIC or ACPI IDs). Why not use CPU number instead of zero here? > >> but I am wondering whether in the future we might hit another bug >> because this routine will return the same APICID for all VCPUs. > > Later on it does a check for 'smp_processor_id()' - and if > that is anything but zero it will bail out. Can you point me to the check you are referring to? -boris > > So this shoudl solve the problem for the bootup processor. >> >> -boris >> >> >>> + }; >>> + int ret = 0; >>> + >>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>> + * get called on the bootup processor. But just in case. */ >>> + if (!xen_initial_domain() || smp_processor_id()) >>> + return 0; >>> + >>> + if (reg == APIC_LVR) >>> + return 0x10; >>> + >>> + if (reg != APIC_ID) >>> + return 0; >>> + >>> + ret = HYPERVISOR_dom0_op(&op); >>> + if (ret) >>> + return 0; >>> + >>> + return op.u.pcpu_info.apic_id; >>> } >>> >>> static void xen_apic_write(u32 reg, u32 val) >>> >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 21:31:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21: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 ) id 1SPh8p-0004tS-5f; Wed, 02 May 2012 21:31:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPh8m-0004tI-Pm for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:31:17 +0000 Received: from [85.158.139.83:35941] by server-7.bemta-5.messagelabs.com id 44/94-16195-4A7A1AF4; Wed, 02 May 2012 21:31:16 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1335994273!19249391!1 X-Originating-IP: [65.55.88.11] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32243 invoked from network); 2 May 2012 21:31:15 -0000 Received: from tx2ehsobe001.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.11) by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 21:31:15 -0000 Received: from mail146-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 21:31:04 +0000 Received: from mail146-tx2 (localhost [127.0.0.1]) by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 79D9E4E03C9; Wed, 2 May 2012 21:31:04 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzzz2dh668h839hd25he5bh) 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 mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1335994262590893_6156; Wed, 2 May 2012 21:31:02 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.238]) by mail146-tx2.bigfish.com (Postfix) with ESMTP id 7FB1F2202AF; Wed, 2 May 2012 21:31:02 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 21:31:02 +0000 X-WSS-ID: 0M3EZRV-01-CGM-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 26F8410281A2; Wed, 2 May 2012 16:31:07 -0500 (CDT) 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, 2 May 2012 16:31:20 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 16:31:07 -0500 Message-ID: <4FA1A79B.5040701@amd.com> Date: Wed, 2 May 2012 17:31:07 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> In-Reply-To: <20120502171415.GA17477@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>> index a8f8844..d816448 100644 >>> --- a/arch/x86/xen/enlighten.c >>> +++ b/arch/x86/xen/enlighten.c >>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>> #ifdef CONFIG_X86_LOCAL_APIC >>> static u32 xen_apic_read(u32 reg) >>> { >>> - return 0; >>> + struct xen_platform_op op = { >>> + .cmd = XENPF_get_cpuinfo, >>> + .interface_version = XENPF_INTERFACE_VERSION, >>> + .u.pcpu_info.xen_cpuid = 0, >> >> >> Is this always zero? This will probably solve the current problem > > Its a CPU number (not tied in to APIC or ACPI IDs). Why not use CPU number instead of zero here? > >> but I am wondering whether in the future we might hit another bug >> because this routine will return the same APICID for all VCPUs. > > Later on it does a check for 'smp_processor_id()' - and if > that is anything but zero it will bail out. Can you point me to the check you are referring to? -boris > > So this shoudl solve the problem for the bootup processor. >> >> -boris >> >> >>> + }; >>> + int ret = 0; >>> + >>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>> + * get called on the bootup processor. But just in case. */ >>> + if (!xen_initial_domain() || smp_processor_id()) >>> + return 0; >>> + >>> + if (reg == APIC_LVR) >>> + return 0x10; >>> + >>> + if (reg != APIC_ID) >>> + return 0; >>> + >>> + ret = HYPERVISOR_dom0_op(&op); >>> + if (ret) >>> + return 0; >>> + >>> + return op.u.pcpu_info.apic_id; >>> } >>> >>> static void xen_apic_write(u32 reg, u32 val) >>> >> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 21:48:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21: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 ) id 1SPhOc-0005G1-6i; Wed, 02 May 2012 21:47:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPhOb-0005Fw-4P for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:47:37 +0000 Received: from [85.158.143.35:39914] by server-1.bemta-4.messagelabs.com id A1/AE-20925-87BA1AF4; Wed, 02 May 2012 21:47:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1335995254!15365222!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA2NjYw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27667 invoked from network); 2 May 2012 21:47:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 21:47:35 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42LlT5S031186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 21:47:30 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 q42LlSa2009964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 21:47:29 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42LlSiY028665; Wed, 2 May 2012 16:47:28 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 14:47:28 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9C41D40357; Wed, 2 May 2012 17:41:47 -0400 (EDT) Date: Wed, 2 May 2012 17:41:47 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120502214147.GA7670@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA1A79B.5040701@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: > On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > >On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > >>On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >>>index a8f8844..d816448 100644 > >>>--- a/arch/x86/xen/enlighten.c > >>>+++ b/arch/x86/xen/enlighten.c > >>>@@ -811,7 +811,29 @@ static void xen_io_delay(void) > >>> #ifdef CONFIG_X86_LOCAL_APIC > >>> static u32 xen_apic_read(u32 reg) > >>> { > >>>- return 0; > >>>+ struct xen_platform_op op = { > >>>+ .cmd = XENPF_get_cpuinfo, > >>>+ .interface_version = XENPF_INTERFACE_VERSION, > >>>+ .u.pcpu_info.xen_cpuid = 0, > >> > >> > >>Is this always zero? This will probably solve the current problem > > > >Its a CPU number (not tied in to APIC or ACPI IDs). > > Why not use CPU number instead of zero here? The issue was only with the bootup CPU - so was using the Xen's bootup CPU number - which is zero (as is Linux's). > > > > >>but I am wondering whether in the future we might hit another bug > >>because this routine will return the same APICID for all VCPUs. > > > > Later on it does a check for 'smp_processor_id()' - and if > >that is anything but zero it will bail out. > > Can you point me to the check you are referring to? if (!xen_initial_domain() || smp_processor_id()) > > -boris > > > > > >So this shoudl solve the problem for the bootup processor. > >> > >>-boris > >> > >> > >>>+ }; > >>>+ int ret = 0; > >>>+ > >>>+ /* Shouldn't need this as APIC is turned off for PV, and we only > >>>+ * get called on the bootup processor. But just in case. */ > >>>+ if (!xen_initial_domain() || smp_processor_id()) > >>>+ return 0; > >>>+ > >>>+ if (reg == APIC_LVR) > >>>+ return 0x10; > >>>+ > >>>+ if (reg != APIC_ID) > >>>+ return 0; > >>>+ > >>>+ ret = HYPERVISOR_dom0_op(&op); > >>>+ if (ret) > >>>+ return 0; > >>>+ > >>>+ return op.u.pcpu_info.apic_id; > >>> } > >>> > >>> static void xen_apic_write(u32 reg, u32 val) > >>> > >> > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 21:48:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 21: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 ) id 1SPhOc-0005G1-6i; Wed, 02 May 2012 21:47:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPhOb-0005Fw-4P for xen-devel@lists.xensource.com; Wed, 02 May 2012 21:47:37 +0000 Received: from [85.158.143.35:39914] by server-1.bemta-4.messagelabs.com id A1/AE-20925-87BA1AF4; Wed, 02 May 2012 21:47:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1335995254!15365222!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA2NjYw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27667 invoked from network); 2 May 2012 21:47:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 21:47:35 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42LlT5S031186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 21:47:30 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 q42LlSa2009964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 21:47:29 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42LlSiY028665; Wed, 2 May 2012 16:47:28 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 14:47:28 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9C41D40357; Wed, 2 May 2012 17:41:47 -0400 (EDT) Date: Wed, 2 May 2012 17:41:47 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120502214147.GA7670@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA1A79B.5040701@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: > On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > >On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > >>On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >>>index a8f8844..d816448 100644 > >>>--- a/arch/x86/xen/enlighten.c > >>>+++ b/arch/x86/xen/enlighten.c > >>>@@ -811,7 +811,29 @@ static void xen_io_delay(void) > >>> #ifdef CONFIG_X86_LOCAL_APIC > >>> static u32 xen_apic_read(u32 reg) > >>> { > >>>- return 0; > >>>+ struct xen_platform_op op = { > >>>+ .cmd = XENPF_get_cpuinfo, > >>>+ .interface_version = XENPF_INTERFACE_VERSION, > >>>+ .u.pcpu_info.xen_cpuid = 0, > >> > >> > >>Is this always zero? This will probably solve the current problem > > > >Its a CPU number (not tied in to APIC or ACPI IDs). > > Why not use CPU number instead of zero here? The issue was only with the bootup CPU - so was using the Xen's bootup CPU number - which is zero (as is Linux's). > > > > >>but I am wondering whether in the future we might hit another bug > >>because this routine will return the same APICID for all VCPUs. > > > > Later on it does a check for 'smp_processor_id()' - and if > >that is anything but zero it will bail out. > > Can you point me to the check you are referring to? if (!xen_initial_domain() || smp_processor_id()) > > -boris > > > > > >So this shoudl solve the problem for the bootup processor. > >> > >>-boris > >> > >> > >>>+ }; > >>>+ int ret = 0; > >>>+ > >>>+ /* Shouldn't need this as APIC is turned off for PV, and we only > >>>+ * get called on the bootup processor. But just in case. */ > >>>+ if (!xen_initial_domain() || smp_processor_id()) > >>>+ return 0; > >>>+ > >>>+ if (reg == APIC_LVR) > >>>+ return 0x10; > >>>+ > >>>+ if (reg != APIC_ID) > >>>+ return 0; > >>>+ > >>>+ ret = HYPERVISOR_dom0_op(&op); > >>>+ if (ret) > >>>+ return 0; > >>>+ > >>>+ return op.u.pcpu_info.apic_id; > >>> } > >>> > >>> static void xen_apic_write(u32 reg, u32 val) > >>> > >> > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 22:10:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 22: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 ) id 1SPhkh-0005qH-G3; Wed, 02 May 2012 22:10:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPhkg-0005qB-AA for xen-devel@lists.xensource.com; Wed, 02 May 2012 22:10:26 +0000 Received: from [85.158.143.35:30052] by server-1.bemta-4.messagelabs.com id C9/C7-20925-1D0B1AF4; Wed, 02 May 2012 22:10:25 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335996621!9568974!1 X-Originating-IP: [65.55.88.13] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23762 invoked from network); 2 May 2012 22:10:23 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.13) by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 22:10:23 -0000 Received: from mail35-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 22:10:12 +0000 Received: from mail35-tx2 (localhost [127.0.0.1]) by mail35-tx2-R.bigfish.com (Postfix) with ESMTP id 8D53F1C0364; Wed, 2 May 2012 22:10:12 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2 (MessageSwitch) id 1335996609468322_5465; Wed, 2 May 2012 22:10:09 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.242]) by mail35-tx2.bigfish.com (Postfix) with ESMTP id 603AD4E007F; Wed, 2 May 2012 22:10:09 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 22:10:07 +0000 X-WSS-ID: 0M3F1L1-02-30P-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 26853C8105; Wed, 2 May 2012 17:10:12 -0500 (CDT) 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, 2 May 2012 17:10:27 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 17:09:27 -0500 Message-ID: <4FA1B096.5010009@amd.com> Date: Wed, 2 May 2012 18:09:26 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> In-Reply-To: <20120502214147.GA7670@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>> index a8f8844..d816448 100644 >>>>> --- a/arch/x86/xen/enlighten.c >>>>> +++ b/arch/x86/xen/enlighten.c >>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>> static u32 xen_apic_read(u32 reg) >>>>> { >>>>> - return 0; >>>>> + struct xen_platform_op op = { >>>>> + .cmd = XENPF_get_cpuinfo, >>>>> + .interface_version = XENPF_INTERFACE_VERSION, >>>>> + .u.pcpu_info.xen_cpuid = 0, >>>> >>>> >>>> Is this always zero? This will probably solve the current problem >>> >>> Its a CPU number (not tied in to APIC or ACPI IDs). >> >> Why not use CPU number instead of zero here? > > The issue was only with the bootup CPU - so was using the Xen's > bootup CPU number - which is zero (as is Linux's). I agree that for this particular problem this may be sufficient. My concern is that in the future someone may decide to use apic_read(APIC_ID) or read_apic_id() for some other purpose and they won't get expected result (i.e. on all CPUs they will get the same answer). > >> >>> >>>> but I am wondering whether in the future we might hit another bug >>>> because this routine will return the same APICID for all VCPUs. >>> >>> Later on it does a check for 'smp_processor_id()' - and if >>> that is anything but zero it will bail out. >> >> Can you point me to the check you are referring to? > > if (!xen_initial_domain() || smp_processor_id()) I don't see this line --- neither in the mainline nor in your kernel. Which kernel and which routine is this in? BTW, this patch doesn't quite work, xen-acpi-processor driver fails to load with the same error as before. I'll look at this tomorrow more carefully. -boris > > >> >> -boris >> >> >>> >>> So this shoudl solve the problem for the bootup processor. >>>> >>>> -boris >>>> >>>> >>>>> + }; >>>>> + int ret = 0; >>>>> + >>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>>>> + * get called on the bootup processor. But just in case. */ >>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>> + return 0; >>>>> + >>>>> + if (reg == APIC_LVR) >>>>> + return 0x10; >>>>> + >>>>> + if (reg != APIC_ID) >>>>> + return 0; >>>>> + >>>>> + ret = HYPERVISOR_dom0_op(&op); >>>>> + if (ret) >>>>> + return 0; >>>>> + >>>>> + return op.u.pcpu_info.apic_id; >>>>> } >>>>> >>>>> static void xen_apic_write(u32 reg, u32 val) >>>>> >>>> >>> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 02 22:10:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 May 2012 22: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 ) id 1SPhkh-0005qH-G3; Wed, 02 May 2012 22:10:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPhkg-0005qB-AA for xen-devel@lists.xensource.com; Wed, 02 May 2012 22:10:26 +0000 Received: from [85.158.143.35:30052] by server-1.bemta-4.messagelabs.com id C9/C7-20925-1D0B1AF4; Wed, 02 May 2012 22:10:25 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1335996621!9568974!1 X-Originating-IP: [65.55.88.13] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23762 invoked from network); 2 May 2012 22:10:23 -0000 Received: from tx2ehsobe003.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.13) by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 2 May 2012 22:10:23 -0000 Received: from mail35-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 22:10:12 +0000 Received: from mail35-tx2 (localhost [127.0.0.1]) by mail35-tx2-R.bigfish.com (Postfix) with ESMTP id 8D53F1C0364; Wed, 2 May 2012 22:10:12 +0000 (UTC) X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2 (MessageSwitch) id 1335996609468322_5465; Wed, 2 May 2012 22:10:09 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.242]) by mail35-tx2.bigfish.com (Postfix) with ESMTP id 603AD4E007F; Wed, 2 May 2012 22:10:09 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 22:10:07 +0000 X-WSS-ID: 0M3F1L1-02-30P-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 26853C8105; Wed, 2 May 2012 17:10:12 -0500 (CDT) 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, 2 May 2012 17:10:27 -0500 Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 17:09:27 -0500 Message-ID: <4FA1B096.5010009@amd.com> Date: Wed, 2 May 2012 18:09:26 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> In-Reply-To: <20120502214147.GA7670@phenom.dumpdata.com> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>> index a8f8844..d816448 100644 >>>>> --- a/arch/x86/xen/enlighten.c >>>>> +++ b/arch/x86/xen/enlighten.c >>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>> static u32 xen_apic_read(u32 reg) >>>>> { >>>>> - return 0; >>>>> + struct xen_platform_op op = { >>>>> + .cmd = XENPF_get_cpuinfo, >>>>> + .interface_version = XENPF_INTERFACE_VERSION, >>>>> + .u.pcpu_info.xen_cpuid = 0, >>>> >>>> >>>> Is this always zero? This will probably solve the current problem >>> >>> Its a CPU number (not tied in to APIC or ACPI IDs). >> >> Why not use CPU number instead of zero here? > > The issue was only with the bootup CPU - so was using the Xen's > bootup CPU number - which is zero (as is Linux's). I agree that for this particular problem this may be sufficient. My concern is that in the future someone may decide to use apic_read(APIC_ID) or read_apic_id() for some other purpose and they won't get expected result (i.e. on all CPUs they will get the same answer). > >> >>> >>>> but I am wondering whether in the future we might hit another bug >>>> because this routine will return the same APICID for all VCPUs. >>> >>> Later on it does a check for 'smp_processor_id()' - and if >>> that is anything but zero it will bail out. >> >> Can you point me to the check you are referring to? > > if (!xen_initial_domain() || smp_processor_id()) I don't see this line --- neither in the mainline nor in your kernel. Which kernel and which routine is this in? BTW, this patch doesn't quite work, xen-acpi-processor driver fails to load with the same error as before. I'll look at this tomorrow more carefully. -boris > > >> >> -boris >> >> >>> >>> So this shoudl solve the problem for the bootup processor. >>>> >>>> -boris >>>> >>>> >>>>> + }; >>>>> + int ret = 0; >>>>> + >>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>>>> + * get called on the bootup processor. But just in case. */ >>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>> + return 0; >>>>> + >>>>> + if (reg == APIC_LVR) >>>>> + return 0x10; >>>>> + >>>>> + if (reg != APIC_ID) >>>>> + return 0; >>>>> + >>>>> + ret = HYPERVISOR_dom0_op(&op); >>>>> + if (ret) >>>>> + return 0; >>>>> + >>>>> + return op.u.pcpu_info.apic_id; >>>>> } >>>>> >>>>> static void xen_apic_write(u32 reg, u32 val) >>>>> >>>> >>> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 00:26:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 00: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 ) id 1SPjrv-0007YY-O0; Thu, 03 May 2012 00:26:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPjru-0007YT-6A for xen-devel@lists.xen.org; Thu, 03 May 2012 00:26:02 +0000 Received: from [85.158.139.83:31903] by server-10.bemta-5.messagelabs.com id 77/9F-08260-990D1AF4; Thu, 03 May 2012 00:26:01 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336004757!25811814!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyODk2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4704 invoked from network); 3 May 2012 00:26:00 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-9.tower-182.messagelabs.com with SMTP; 3 May 2012 00:26:00 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 02 May 2012 17:25:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138206145" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 02 May 2012 17:25:53 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 17:25:53 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Thu, 3 May 2012 08:25:51 +0800 From: "Dong, Eddie" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsA== Date: Thu, 3 May 2012 00:25:51 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: <4FA1193D02000078000810EC@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > >> > >> Jun, Eddie - I further wonder why #OF is not being handled according > >> to the documentation here either (should also result in > >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from > >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it > >> should be annotated with a comment saying why fall-through is > >> intended here). Nor does the documentation state that TRAP_debug > >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. > > > > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & > #BP, > > It seems we are slightly different here. Let me check w/ internal person. > > Thanks. The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION Per SDM and confirmation from our HW guys. We will send fixes soon. > > >> Finally, the whole injection logic (including the patch here) doesn't > >> appear to cope with INT nn being used by a guest with nn < 32, nor > > > > The original code path works for the privilege violation introduced > > exceptions, > > It seems we probbaly need a new code for INT n emulation for both > interrupt & > > exceptions. > > Indeed. This API vmx_inject_hw_exception is never intended to be used for INT nn emulation, Rather it is designed for the exceptions generated by processor-detected program-error exceptions and machine check exceptions. If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is incorrect. We need a new API for that purpose, and use software interrupt. Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM mentioned. > > >> with any (pointless) prefixes used on INT3 or INT nn. > >> > > What specific prefix do u mean here? > > Anyone except perhaps LOCK - none of them should have any effect > other than making the instruction longer. > LOCK can never be used as prefix of INT nn instruction, nor can REPx prefix. Can you provide more details as for this concern? Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 00:26:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 00: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 ) id 1SPjrv-0007YY-O0; Thu, 03 May 2012 00:26:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPjru-0007YT-6A for xen-devel@lists.xen.org; Thu, 03 May 2012 00:26:02 +0000 Received: from [85.158.139.83:31903] by server-10.bemta-5.messagelabs.com id 77/9F-08260-990D1AF4; Thu, 03 May 2012 00:26:01 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336004757!25811814!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjcyODk2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4704 invoked from network); 3 May 2012 00:26:00 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-9.tower-182.messagelabs.com with SMTP; 3 May 2012 00:26:00 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 02 May 2012 17:25:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138206145" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 02 May 2012 17:25:53 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 17:25:53 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Thu, 3 May 2012 08:25:51 +0800 From: "Dong, Eddie" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsA== Date: Thu, 3 May 2012 00:25:51 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: <4FA1193D02000078000810EC@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > >> > >> Jun, Eddie - I further wonder why #OF is not being handled according > >> to the documentation here either (should also result in > >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from > >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it > >> should be annotated with a comment saying why fall-through is > >> intended here). Nor does the documentation state that TRAP_debug > >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. > > > > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & > #BP, > > It seems we are slightly different here. Let me check w/ internal person. > > Thanks. The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION Per SDM and confirmation from our HW guys. We will send fixes soon. > > >> Finally, the whole injection logic (including the patch here) doesn't > >> appear to cope with INT nn being used by a guest with nn < 32, nor > > > > The original code path works for the privilege violation introduced > > exceptions, > > It seems we probbaly need a new code for INT n emulation for both > interrupt & > > exceptions. > > Indeed. This API vmx_inject_hw_exception is never intended to be used for INT nn emulation, Rather it is designed for the exceptions generated by processor-detected program-error exceptions and machine check exceptions. If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is incorrect. We need a new API for that purpose, and use software interrupt. Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM mentioned. > > >> with any (pointless) prefixes used on INT3 or INT nn. > >> > > What specific prefix do u mean here? > > Anyone except perhaps LOCK - none of them should have any effect > other than making the instruction longer. > LOCK can never be used as prefix of INT nn instruction, nor can REPx prefix. Can you provide more details as for this concern? Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 00:47:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 00:47:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkBo-0007nj-S9; Thu, 03 May 2012 00:46:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkBn-0007ne-8S for xen-devel@lists.xensource.com; Thu, 03 May 2012 00:46:35 +0000 Received: from [85.158.138.51:40589] by server-4.bemta-3.messagelabs.com id 3B/05-15341-A65D1AF4; Thu, 03 May 2012 00:46:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336005993!13924649!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10364 invoked from network); 3 May 2012 00:46:33 -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; 3 May 2012 00:46:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,519,1330905600"; d="scan'208";a="12261218" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 00:46: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, 3 May 2012 01:46:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPkBk-0005iQ-5R; Thu, 03 May 2012 00:46:32 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPkBk-0003D0-4G; Thu, 03 May 2012 01:46:32 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 01:46:32 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12782: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12782 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12782/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl 9 guest-start fail like 12763 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12763 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 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-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=98fe3b2a572d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 98fe3b2a572d + branch=xen-unstable + revision=98fe3b2a572d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 98fe3b2a572d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 00:47:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 00:47:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkBo-0007nj-S9; Thu, 03 May 2012 00:46:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkBn-0007ne-8S for xen-devel@lists.xensource.com; Thu, 03 May 2012 00:46:35 +0000 Received: from [85.158.138.51:40589] by server-4.bemta-3.messagelabs.com id 3B/05-15341-A65D1AF4; Thu, 03 May 2012 00:46:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336005993!13924649!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10364 invoked from network); 3 May 2012 00:46:33 -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; 3 May 2012 00:46:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,519,1330905600"; d="scan'208";a="12261218" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 00:46: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, 3 May 2012 01:46:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPkBk-0005iQ-5R; Thu, 03 May 2012 00:46:32 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPkBk-0003D0-4G; Thu, 03 May 2012 01:46:32 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 01:46:32 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12782: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12782 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12782/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl 9 guest-start fail like 12763 test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12763 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 98fe3b2a572d baseline version: xen 9dda0efd8ce1 jobs: build-amd64 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-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=98fe3b2a572d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 98fe3b2a572d + branch=xen-unstable + revision=98fe3b2a572d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 98fe3b2a572d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 01:04:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 01:04:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkT2-0003PL-UZ; Thu, 03 May 2012 01:04:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkT1-0003PG-Pm for xen-devel@lists.xen.org; Thu, 03 May 2012 01:04:24 +0000 Received: from [85.158.139.83:40051] by server-9.bemta-5.messagelabs.com id 64/57-09826-799D1AF4; Thu, 03 May 2012 01:04:23 +0000 X-Env-Sender: dario.faggioli@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336007061!26486648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11846 invoked from network); 3 May 2012 01:04:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 01:04:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,519,1330905600"; d="scan'";a="12261349" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 01:04:20 +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; Thu, 3 May 2012 02:04:20 +0100 Message-ID: <1336007032.874.12.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Thu, 3 May 2012 03:03:52 +0200 In-Reply-To: <1335976251.2961.123.camel@Abyss> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.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.3 (3.2.3-3.fc16) MIME-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4423668689322008657==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4423668689322008657== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uB28wXrkYJTtVrwE9IKW" --=-uB28wXrkYJTtVrwE9IKW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-02 at 18:30 +0200, Dario Faggioli wrote: > > > + > > > + if (use_cpus>=3D b_info->max_vcpus) { > > > + rc =3D 0; > > > + break; > > > + } > > Hmm -- there's got to be a better way to find out the minimum number > > of nodes to house a given number of vcpus than just starting at 1 > > and re-trying until we have enough. > > ... > > However, if what you mean is I could check beforehand whether or not > the > user provided configuration will give us enough CPUs and avoid testing > scenarios that are guaranteed to fail, then I agree and I'll reshape > the > code to look like that.=20 > Actually, thinking more about this, I'm not even sure I can do what I stated above. In fact, I don't think I can assume the number of CPUs each node is made up of to be known, without actually checking it for the specific node(s) I want to try using. What if some CPUs are off-line and stuff like that? I might have to recheck, but reading topology information takes on/offline-ness into account, which is something I lose if I assume some static x number of CPUs in each node. Also, are we sure archs with different number of CPUs in different nodes won't ever exist? :-P Finally, consider this is likely going to change when we will have some mechanism for taking the actual load on the CPUs into account, so maybe it's not worth spending much time on it right now. So, given what we currently export wrt topology, and all the above, I'm not sure I can see any cleverer way of figuring our how many CPUs/nodes I need than explicitly counting them (for what it counts, xend is also doing the same AFAIUI :-) ). Thoughts? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-uB28wXrkYJTtVrwE9IKW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+h2XgACgkQk4XaBE3IOsSn5QCgnUx6OC+vLD7DOqKAHOrZL3OD UIMAn2Ai6wzfWz8j6IlpKs3bSOKKHhOA =ce2H -----END PGP SIGNATURE----- --=-uB28wXrkYJTtVrwE9IKW-- --===============4423668689322008657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4423668689322008657==-- From xen-devel-bounces@lists.xen.org Thu May 03 01:04:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 01:04:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkT2-0003PL-UZ; Thu, 03 May 2012 01:04:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPkT1-0003PG-Pm for xen-devel@lists.xen.org; Thu, 03 May 2012 01:04:24 +0000 Received: from [85.158.139.83:40051] by server-9.bemta-5.messagelabs.com id 64/57-09826-799D1AF4; Thu, 03 May 2012 01:04:23 +0000 X-Env-Sender: dario.faggioli@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336007061!26486648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjQxMg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11846 invoked from network); 3 May 2012 01:04:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 01:04:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,519,1330905600"; d="scan'";a="12261349" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 01:04:20 +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; Thu, 3 May 2012 02:04:20 +0100 Message-ID: <1336007032.874.12.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Thu, 3 May 2012 03:03:52 +0200 In-Reply-To: <1335976251.2961.123.camel@Abyss> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.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.3 (3.2.3-3.fc16) MIME-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4423668689322008657==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4423668689322008657== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uB28wXrkYJTtVrwE9IKW" --=-uB28wXrkYJTtVrwE9IKW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-02 at 18:30 +0200, Dario Faggioli wrote: > > > + > > > + if (use_cpus>=3D b_info->max_vcpus) { > > > + rc =3D 0; > > > + break; > > > + } > > Hmm -- there's got to be a better way to find out the minimum number > > of nodes to house a given number of vcpus than just starting at 1 > > and re-trying until we have enough. > > ... > > However, if what you mean is I could check beforehand whether or not > the > user provided configuration will give us enough CPUs and avoid testing > scenarios that are guaranteed to fail, then I agree and I'll reshape > the > code to look like that.=20 > Actually, thinking more about this, I'm not even sure I can do what I stated above. In fact, I don't think I can assume the number of CPUs each node is made up of to be known, without actually checking it for the specific node(s) I want to try using. What if some CPUs are off-line and stuff like that? I might have to recheck, but reading topology information takes on/offline-ness into account, which is something I lose if I assume some static x number of CPUs in each node. Also, are we sure archs with different number of CPUs in different nodes won't ever exist? :-P Finally, consider this is likely going to change when we will have some mechanism for taking the actual load on the CPUs into account, so maybe it's not worth spending much time on it right now. So, given what we currently export wrt topology, and all the above, I'm not sure I can see any cleverer way of figuring our how many CPUs/nodes I need than explicitly counting them (for what it counts, xend is also doing the same AFAIUI :-) ). Thoughts? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-uB28wXrkYJTtVrwE9IKW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+h2XgACgkQk4XaBE3IOsSn5QCgnUx6OC+vLD7DOqKAHOrZL3OD UIMAn2Ai6wzfWz8j6IlpKs3bSOKKHhOA =ce2H -----END PGP SIGNATURE----- --=-uB28wXrkYJTtVrwE9IKW-- --===============4423668689322008657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4423668689322008657==-- From xen-devel-bounces@lists.xen.org Thu May 03 01:56:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 01:56:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPlGQ-0004Il-D4; Thu, 03 May 2012 01:55:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPlGO-0004Ig-Pm for xen-devel@lists.xen.org; Thu, 03 May 2012 01:55:25 +0000 Received: from [85.158.143.99:26677] by server-3.bemta-4.messagelabs.com id C7/DA-05853-C85E1AF4; Thu, 03 May 2012 01:55:24 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336010122!16611588!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17588 invoked from network); 3 May 2012 01:55:23 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 01:55:23 -0000 Received: by lbok6 with SMTP id k6so1155155lbo.32 for ; Wed, 02 May 2012 18:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0ZHu6zYM1WOLSQezIiKW1v0SKdE2xyGssa2WirOd/Z8=; b=l/710XNv3sKZ24T2bts31UBwVwZzQKaUelqBWkDpPuXg50B3KQ/MGfZUCr7I55M8J8 4lHL6SaqFqQog289SFSjKiS3HjjuV5LcJ0lnl1tPMwrxe1pIRnLcc17GkY7Kt5MvrYV6 yZZ1EcSGUnJqKxMbwdBUVUz0KhFvQlj3XY5kg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0ZHu6zYM1WOLSQezIiKW1v0SKdE2xyGssa2WirOd/Z8=; b=Wi7wYcOAlytmBz2AOkB/MDwriWiVSaGr2ZsqvnBGgaYy6rJ6Co3Kx8ie7uYC7SJK0w 0ljSk7FwCMN5BkldO9HQgIBhzWP+NxewzjJXRUmYTSW1NWC3odOI1sx6r9YiXAM70vmK 4gC4EEQ8OM+lIjyri1IOPY9l0q2ySWRQid9dNAuyHzHOfMYoeZ5aZDfFiFSGc6e26jbB n1N/3edBmdjW3SCtuzS++4EDT/NniA86dWsJZ9ruoPTNYVYswKM9IT8ZZnp3RgtmVzaq cmtUa4lDSe6kyOJnz9Ms0PVCvwZArDlZFg4k2T3lYy0JeaVaWeASMnIn4UjRLcils0+Z cSBw== MIME-Version: 1.0 Received: by 10.112.36.133 with SMTP id q5mr156323lbj.37.1336010121743; Wed, 02 May 2012 18:55:21 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Wed, 2 May 2012 18:55:21 -0700 (PDT) X-Originating-IP: [108.92.21.169] In-Reply-To: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> Date: Wed, 2 May 2012 18:55:21 -0700 Message-ID: From: Aravindh Puthiyaparambil To: "Dong, Eddie" X-Gm-Message-State: ALoCoQm6THpst73N+1NkmVxDEb0159quQ6vdatGn+oTfTQFSxOptj/R9O6r/KQSCELY8tIL4Pe+O Cc: "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 5:25 PM, Dong, Eddie wrote: >> >> >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> >> to the documentation here either (should also result in >> >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> >> should be annotated with a comment saying why fall-through is >> >> intended here). Nor does the documentation state that TRAP_debug >> >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. >> > >> > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & >> #BP, >> > It seems we are slightly different here. Let me check w/ internal person. >> >> Thanks. > > The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION > Per SDM and confirmation from our HW guys. We will send fixes soon. > > >> >> >> Finally, the whole injection logic (including the patch here) doesn't >> >> appear to cope with INT nn being used by a guest with nn < 32, nor >> > >> > The original code path works for the privilege violation introduced >> > exceptions, >> > It seems we probbaly need a new code for INT n emulation for both >> interrupt & >> > exceptions. >> >> Indeed. > > This API vmx_inject_hw_exception is never intended to be used for INT nn emulation, > Rather it is designed for the exceptions generated by processor-detected program-error exceptions and machine check exceptions. > > If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is incorrect. We need a new API for that purpose, and use software interrupt. > Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM mentioned. > The reason I submitted the patch was, calling xc_hvm_inject_trap() on a software interrupt caused the guest to crash with a vmentry failure because the interrupt was injected as a hardware interrupt. The patch allowed me to inject a software interrupt successfully. However I do agree that it is better if we have a separate API that does not overload vmx_inject_hw_exception(). Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 01:56:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 01:56:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPlGQ-0004Il-D4; Thu, 03 May 2012 01:55:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPlGO-0004Ig-Pm for xen-devel@lists.xen.org; Thu, 03 May 2012 01:55:25 +0000 Received: from [85.158.143.99:26677] by server-3.bemta-4.messagelabs.com id C7/DA-05853-C85E1AF4; Thu, 03 May 2012 01:55:24 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336010122!16611588!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17588 invoked from network); 3 May 2012 01:55:23 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 01:55:23 -0000 Received: by lbok6 with SMTP id k6so1155155lbo.32 for ; Wed, 02 May 2012 18:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0ZHu6zYM1WOLSQezIiKW1v0SKdE2xyGssa2WirOd/Z8=; b=l/710XNv3sKZ24T2bts31UBwVwZzQKaUelqBWkDpPuXg50B3KQ/MGfZUCr7I55M8J8 4lHL6SaqFqQog289SFSjKiS3HjjuV5LcJ0lnl1tPMwrxe1pIRnLcc17GkY7Kt5MvrYV6 yZZ1EcSGUnJqKxMbwdBUVUz0KhFvQlj3XY5kg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0ZHu6zYM1WOLSQezIiKW1v0SKdE2xyGssa2WirOd/Z8=; b=Wi7wYcOAlytmBz2AOkB/MDwriWiVSaGr2ZsqvnBGgaYy6rJ6Co3Kx8ie7uYC7SJK0w 0ljSk7FwCMN5BkldO9HQgIBhzWP+NxewzjJXRUmYTSW1NWC3odOI1sx6r9YiXAM70vmK 4gC4EEQ8OM+lIjyri1IOPY9l0q2ySWRQid9dNAuyHzHOfMYoeZ5aZDfFiFSGc6e26jbB n1N/3edBmdjW3SCtuzS++4EDT/NniA86dWsJZ9ruoPTNYVYswKM9IT8ZZnp3RgtmVzaq cmtUa4lDSe6kyOJnz9Ms0PVCvwZArDlZFg4k2T3lYy0JeaVaWeASMnIn4UjRLcils0+Z cSBw== MIME-Version: 1.0 Received: by 10.112.36.133 with SMTP id q5mr156323lbj.37.1336010121743; Wed, 02 May 2012 18:55:21 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Wed, 2 May 2012 18:55:21 -0700 (PDT) X-Originating-IP: [108.92.21.169] In-Reply-To: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> Date: Wed, 2 May 2012 18:55:21 -0700 Message-ID: From: Aravindh Puthiyaparambil To: "Dong, Eddie" X-Gm-Message-State: ALoCoQm6THpst73N+1NkmVxDEb0159quQ6vdatGn+oTfTQFSxOptj/R9O6r/KQSCELY8tIL4Pe+O Cc: "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 5:25 PM, Dong, Eddie wrote: >> >> >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> >> to the documentation here either (should also result in >> >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> >> should be annotated with a comment saying why fall-through is >> >> intended here). Nor does the documentation state that TRAP_debug >> >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. >> > >> > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & >> #BP, >> > It seems we are slightly different here. Let me check w/ internal person. >> >> Thanks. > > The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION > Per SDM and confirmation from our HW guys. We will send fixes soon. > > >> >> >> Finally, the whole injection logic (including the patch here) doesn't >> >> appear to cope with INT nn being used by a guest with nn < 32, nor >> > >> > The original code path works for the privilege violation introduced >> > exceptions, >> > It seems we probbaly need a new code for INT n emulation for both >> interrupt & >> > exceptions. >> >> Indeed. > > This API vmx_inject_hw_exception is never intended to be used for INT nn emulation, > Rather it is designed for the exceptions generated by processor-detected program-error exceptions and machine check exceptions. > > If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is incorrect. We need a new API for that purpose, and use software interrupt. > Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM mentioned. > The reason I submitted the patch was, calling xc_hvm_inject_trap() on a software interrupt caused the guest to crash with a vmentry failure because the interrupt was injected as a hardware interrupt. The patch allowed me to inject a software interrupt successfully. However I do agree that it is better if we have a separate API that does not overload vmx_inject_hw_exception(). Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 03:29:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 03:29:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPmiM-000554-IX; Thu, 03 May 2012 03:28:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPmiK-00054z-70 for xen-devel@lists.xen.org; Thu, 03 May 2012 03:28:20 +0000 Received: from [85.158.139.83:26902] by server-6.bemta-5.messagelabs.com id FE/2D-13222-35BF1AF4; Thu, 03 May 2012 03:28:19 +0000 X-Env-Sender: christian.limpach@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336015696!19274545!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1272 invoked from network); 3 May 2012 03:28:17 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 03:28:17 -0000 Received: by qcsc20 with SMTP id c20so1107077qcs.32 for ; Wed, 02 May 2012 20:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=s8+kNWluStyoSwTbJ/RKa3f65DyTiwfS2DQ6i9Z3GdQ=; b=XDWO0iewBSEoGQX6tcVUPuyhmlGWcApkobAan8vggo5NjJM5lybCHsrAMa8c/Xkruv dEv0spOMPrQLTBnb+HJNcmXUxhJOoQcvIr3QrFnmmdVzx+NGtslsOFsBD3ZpSOl2kUit jVxzyzpn8bzfP6V+dFMKmXsVF8gF3L6eaA8POuT9A3PBxXVL2fWBQLR+aNjHhzVkMe9N dG5aNy9Otojt4J+27s6W350u/cJeLtqHKA1GTn2DOk0nGC4tFsYflxXRHjTntN2TC8tb rUIH3uMb0hD+yjCXgs3ctP7guILQwTUKsY1lHu7YkGVWJ7R28ZQC+GuA8KrxsukUhclh 2d0g== MIME-Version: 1.0 Received: by 10.224.34.9 with SMTP id j9mr1609255qad.14.1336015695456; Wed, 02 May 2012 20:28:15 -0700 (PDT) Received: by 10.229.184.11 with HTTP; Wed, 2 May 2012 20:28:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 20:28:15 -0700 Message-ID: From: Christian Limpach To: Aravindh Puthiyaparambil Cc: tim@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Christian.Limpach@gmail.com List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil wrote: >>> Let me re-iterate: >>> - if it's a leaf entry, then there's no need to call ept_free_entry >>> - if you don't need to call ept_free_entry, then you can defer >>> ept_sync_domain (subject to the iommu case) >>> - you could pass in a pointer to a bool to indicate to the caller that >>> ept_sync_domain was deferred and that the caller needs to do it, with >>> a NULL pointer indicating that the caller doesn't support defer > > How does this look? It's missing the "leaf entry" part of my description of how I think things should work. Without that, you're effectively ignoring the following comment at the end of ept_set_entry: /* Release the old intermediate tables, if any. This has to be the last thing we do, after the ept_sync_domain() and removal from the iommu tables, so as to avoid a potential use-after-free. */ See inline comments in your patch below for how I'd change this, untested... christian > @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0 =A0 int needs_sync =3D 1; > =A0 =A0 struct domain *d =3D p2m->domain; > =A0 =A0 ept_entry_t old_entry =3D { .epte =3D 0 }; > + =A0 =A0bool_t _sync_deferred =3D 0; don't need that > =A0 =A0 /* > =A0 =A0 =A0* the caller must make sure: > @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 1 && hvm_hap_has_2mb(d)) || > =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 0)); > > + =A0 =A0if (sync_deferred) > + =A0 =A0 =A0 =A0*sync_deferred =3D 1; > + > =A0 =A0 table =3D map_domain_page(ept_get_asr(d)); > > =A0 =A0 for ( i =3D ept_get_wl(d); i > target; i-- ) > @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un > > =A0 =A0 =A0 =A0 /* No need to flush if the old entry wasn't valid */ > =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) ) > needs_sync =3D 0; This should be: if ( !is_epte_present(ept_entry) || (!target && sync_deferred) ) { needs_sync =3D 0; if (sync_deferred) *sync_deferred =3D 0; } This expresses the notion that we're going to skip the call to ept_free_entry since it's a leaf entry (target =3D=3D 0) and that the caller will make the ept_sync_domain call (sync_deferred !=3D NULL). > > =A0 =A0 =A0 =A0 /* If we're replacing a non-leaf entry with a leaf entry > (1GiB or 2MiB), > =A0 =A0 =A0 =A0 =A0* the intermediate tables will be freed below after th= e ept flush > @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un > > =A0 =A0 =A0 =A0 ASSERT(is_epte_superpage(ept_entry)); > > + =A0 =A0 =A0 =A0if ( sync_deferred ) > + =A0 =A0 =A0 =A0 =A0 =A0_sync_deferred =3D 1; > + don't need that > =A0 =A0 =A0 =A0 split_ept_entry =3D atomic_read_ept_entry(ept_entry); > > =A0 =A0 =A0 =A0 if ( !ept_split_super_page(p2m, &split_ept_entry, i, targ= et) ) > @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0out: > =A0 =A0 unmap_domain_page(table); > > - =A0 =A0if ( needs_sync ) > + =A0 =A0if ( needs_sync && !_sync_deferred ) > =A0 =A0 =A0 =A0 ept_sync_domain(p2m->domain); don't need that change, test on needs_sync is sufficient > > =A0 =A0 if ( rv && iommu_enabled && need_iommu(p2m->domain) && > need_modify_vtd_table ) Then at the end of ept_set_pte add the test for non-leaf, which is more like an optimization/clarification since ept_free_entry has the same test already. if ( target && is_epte_present(&old_entry) ) ept_free_entry(p2m, &old_entry, target); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 03:29:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 03:29:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPmiM-000554-IX; Thu, 03 May 2012 03:28:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPmiK-00054z-70 for xen-devel@lists.xen.org; Thu, 03 May 2012 03:28:20 +0000 Received: from [85.158.139.83:26902] by server-6.bemta-5.messagelabs.com id FE/2D-13222-35BF1AF4; Thu, 03 May 2012 03:28:19 +0000 X-Env-Sender: christian.limpach@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336015696!19274545!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1272 invoked from network); 3 May 2012 03:28:17 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 03:28:17 -0000 Received: by qcsc20 with SMTP id c20so1107077qcs.32 for ; Wed, 02 May 2012 20:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=s8+kNWluStyoSwTbJ/RKa3f65DyTiwfS2DQ6i9Z3GdQ=; b=XDWO0iewBSEoGQX6tcVUPuyhmlGWcApkobAan8vggo5NjJM5lybCHsrAMa8c/Xkruv dEv0spOMPrQLTBnb+HJNcmXUxhJOoQcvIr3QrFnmmdVzx+NGtslsOFsBD3ZpSOl2kUit jVxzyzpn8bzfP6V+dFMKmXsVF8gF3L6eaA8POuT9A3PBxXVL2fWBQLR+aNjHhzVkMe9N dG5aNy9Otojt4J+27s6W350u/cJeLtqHKA1GTn2DOk0nGC4tFsYflxXRHjTntN2TC8tb rUIH3uMb0hD+yjCXgs3ctP7guILQwTUKsY1lHu7YkGVWJ7R28ZQC+GuA8KrxsukUhclh 2d0g== MIME-Version: 1.0 Received: by 10.224.34.9 with SMTP id j9mr1609255qad.14.1336015695456; Wed, 02 May 2012 20:28:15 -0700 (PDT) Received: by 10.229.184.11 with HTTP; Wed, 2 May 2012 20:28:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 20:28:15 -0700 Message-ID: From: Christian Limpach To: Aravindh Puthiyaparambil Cc: tim@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Christian.Limpach@gmail.com List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil wrote: >>> Let me re-iterate: >>> - if it's a leaf entry, then there's no need to call ept_free_entry >>> - if you don't need to call ept_free_entry, then you can defer >>> ept_sync_domain (subject to the iommu case) >>> - you could pass in a pointer to a bool to indicate to the caller that >>> ept_sync_domain was deferred and that the caller needs to do it, with >>> a NULL pointer indicating that the caller doesn't support defer > > How does this look? It's missing the "leaf entry" part of my description of how I think things should work. Without that, you're effectively ignoring the following comment at the end of ept_set_entry: /* Release the old intermediate tables, if any. This has to be the last thing we do, after the ept_sync_domain() and removal from the iommu tables, so as to avoid a potential use-after-free. */ See inline comments in your patch below for how I'd change this, untested... christian > @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0 =A0 int needs_sync =3D 1; > =A0 =A0 struct domain *d =3D p2m->domain; > =A0 =A0 ept_entry_t old_entry =3D { .epte =3D 0 }; > + =A0 =A0bool_t _sync_deferred =3D 0; don't need that > =A0 =A0 /* > =A0 =A0 =A0* the caller must make sure: > @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 1 && hvm_hap_has_2mb(d)) || > =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 0)); > > + =A0 =A0if (sync_deferred) > + =A0 =A0 =A0 =A0*sync_deferred =3D 1; > + > =A0 =A0 table =3D map_domain_page(ept_get_asr(d)); > > =A0 =A0 for ( i =3D ept_get_wl(d); i > target; i-- ) > @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un > > =A0 =A0 =A0 =A0 /* No need to flush if the old entry wasn't valid */ > =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) ) > needs_sync =3D 0; This should be: if ( !is_epte_present(ept_entry) || (!target && sync_deferred) ) { needs_sync =3D 0; if (sync_deferred) *sync_deferred =3D 0; } This expresses the notion that we're going to skip the call to ept_free_entry since it's a leaf entry (target =3D=3D 0) and that the caller will make the ept_sync_domain call (sync_deferred !=3D NULL). > > =A0 =A0 =A0 =A0 /* If we're replacing a non-leaf entry with a leaf entry > (1GiB or 2MiB), > =A0 =A0 =A0 =A0 =A0* the intermediate tables will be freed below after th= e ept flush > @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un > > =A0 =A0 =A0 =A0 ASSERT(is_epte_superpage(ept_entry)); > > + =A0 =A0 =A0 =A0if ( sync_deferred ) > + =A0 =A0 =A0 =A0 =A0 =A0_sync_deferred =3D 1; > + don't need that > =A0 =A0 =A0 =A0 split_ept_entry =3D atomic_read_ept_entry(ept_entry); > > =A0 =A0 =A0 =A0 if ( !ept_split_super_page(p2m, &split_ept_entry, i, targ= et) ) > @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un > =A0out: > =A0 =A0 unmap_domain_page(table); > > - =A0 =A0if ( needs_sync ) > + =A0 =A0if ( needs_sync && !_sync_deferred ) > =A0 =A0 =A0 =A0 ept_sync_domain(p2m->domain); don't need that change, test on needs_sync is sufficient > > =A0 =A0 if ( rv && iommu_enabled && need_iommu(p2m->domain) && > need_modify_vtd_table ) Then at the end of ept_set_pte add the test for non-leaf, which is more like an optimization/clarification since ept_free_entry has the same test already. if ( target && is_epte_present(&old_entry) ) ept_free_entry(p2m, &old_entry, target); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 05:03:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 05: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 ) id 1SPoBk-0005jE-SK; Thu, 03 May 2012 05:02:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPoBj-0005j7-4s for xen-devel@lists.xen.org; Thu, 03 May 2012 05:02:47 +0000 Received: from [85.158.143.99:33688] by server-3.bemta-4.messagelabs.com id 57/A5-05853-67112AF4; Thu, 03 May 2012 05:02:46 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336021365!20938815!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI3NTUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20892 invoked from network); 3 May 2012 05:02:45 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-216.messagelabs.com with SMTP; 3 May 2012 05:02:45 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 02 May 2012 22:02:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="95817198" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 02 May 2012 22:02:42 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 22:02:42 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Thu, 3 May 2012 13:02:39 +0800 From: "Dong, Eddie" To: Aravindh Puthiyaparambil Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsP//l2GAgAC6JAA= Date: Thu, 3 May 2012 05:02:39 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Dong, Eddie" , "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > The reason I submitted the patch was, calling xc_hvm_inject_trap() on > a software interrupt caused the guest to crash with a vmentry failure That should use SW_INTERRUPT, not SW_EXCEPTION. > because the interrupt was injected as a hardware interrupt. The patch > allowed me to inject a software interrupt successfully. > > However I do agree that it is better if we have a separate API that > does not overload vmx_inject_hw_exception(). > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 05:03:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 05: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 ) id 1SPoBk-0005jE-SK; Thu, 03 May 2012 05:02:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPoBj-0005j7-4s for xen-devel@lists.xen.org; Thu, 03 May 2012 05:02:47 +0000 Received: from [85.158.143.99:33688] by server-3.bemta-4.messagelabs.com id 57/A5-05853-67112AF4; Thu, 03 May 2012 05:02:46 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336021365!20938815!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI3NTUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20892 invoked from network); 3 May 2012 05:02:45 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-216.messagelabs.com with SMTP; 3 May 2012 05:02:45 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 02 May 2012 22:02:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="95817198" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 02 May 2012 22:02:42 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 May 2012 22:02:42 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Thu, 3 May 2012 13:02:39 +0800 From: "Dong, Eddie" To: Aravindh Puthiyaparambil Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsP//l2GAgAC6JAA= Date: Thu, 3 May 2012 05:02:39 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Dong, Eddie" , "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > The reason I submitted the patch was, calling xc_hvm_inject_trap() on > a software interrupt caused the guest to crash with a vmentry failure That should use SW_INTERRUPT, not SW_EXCEPTION. > because the interrupt was injected as a hardware interrupt. The patch > allowed me to inject a software interrupt successfully. > > However I do agree that it is better if we have a separate API that > does not overload vmx_inject_hw_exception(). > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 06:15:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 06: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 ) id 1SPpIm-00068M-F1; Thu, 03 May 2012 06:14:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpIk-00068H-Rm for xen-devel@lists.xensource.com; Thu, 03 May 2012 06:14:07 +0000 Received: from [85.158.138.51:16099] by server-9.bemta-3.messagelabs.com id 81/C6-26691-E2222AF4; Thu, 03 May 2012 06:14:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336025645!24831248!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6207 invoked from network); 3 May 2012 06:14:05 -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; 3 May 2012 06:14:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,520,1330905600"; d="scan'208";a="12263851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 06:14: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, 3 May 2012 07:14:04 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPpIi-0007dF-48; Thu, 03 May 2012 06:14:04 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPpIh-0007tp-R4; Thu, 03 May 2012 07:14:03 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 07:14:03 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12784: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12784 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12784/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 12779 test-i386-i386-pv 3 host-install(3) broken in 12779 pass in 12784 test-amd64-i386-pv 3 host-install(3) broken in 12779 pass in 12784 test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail in 12779 pass in 12784 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 12779 pass in 12784 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 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-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 12779 never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=d8fd425b60d3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 d8fd425b60d3 + branch=xen-4.0-testing + revision=d8fd425b60d3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.0-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.0-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git ++ : daily-cron.xen-4.0-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git + info_linux_tree xen-4.0-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r d8fd425b60d3 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 06:15:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 06: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 ) id 1SPpIm-00068M-F1; Thu, 03 May 2012 06:14:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpIk-00068H-Rm for xen-devel@lists.xensource.com; Thu, 03 May 2012 06:14:07 +0000 Received: from [85.158.138.51:16099] by server-9.bemta-3.messagelabs.com id 81/C6-26691-E2222AF4; Thu, 03 May 2012 06:14:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336025645!24831248!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6207 invoked from network); 3 May 2012 06:14:05 -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; 3 May 2012 06:14:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,520,1330905600"; d="scan'208";a="12263851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 06:14: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, 3 May 2012 07:14:04 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPpIi-0007dF-48; Thu, 03 May 2012 06:14:04 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPpIh-0007tp-R4; Thu, 03 May 2012 07:14:03 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 07:14:03 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12784: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12784 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12784/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 12779 test-i386-i386-pv 3 host-install(3) broken in 12779 pass in 12784 test-amd64-i386-pv 3 host-install(3) broken in 12779 pass in 12784 test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail in 12779 pass in 12784 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 12779 pass in 12784 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail blocked in 12707 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-i386-i386-xl 15 guest-stop fail never pass test-amd64-i386-xl-credit2 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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 12779 never pass version targeted for testing: xen d8fd425b60d3 baseline version: xen 4e446ac2c6de jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=d8fd425b60d3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 d8fd425b60d3 + branch=xen-4.0-testing + revision=d8fd425b60d3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.0-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.0-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git ++ : daily-cron.xen-4.0-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git + info_linux_tree xen-4.0-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r d8fd425b60d3 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 06:56:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 06:56:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpxO-0006Ol-3k; Thu, 03 May 2012 06:56:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpxM-0006Og-RS for xen-devel@lists.xensource.com; Thu, 03 May 2012 06:56:05 +0000 Received: from [85.158.139.83:64813] by server-9.bemta-5.messagelabs.com id 23/CB-09826-40C22AF4; Thu, 03 May 2012 06:56:04 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336028163!25987757!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8134 invoked from network); 3 May 2012 06:56:03 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP; 3 May 2012 06:56:03 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPpxJ-0007fj-Dg; Thu, 03 May 2012 06:56:01 +0000 Message-ID: <4FA22BF8.2050409@canonical.com> Date: Thu, 03 May 2012 08:55:52 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> In-Reply-To: <4FA1B096.5010009@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4098233777693533906==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4098233777693533906== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE4D7DB7D964CF58A0ADBFBFA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4D7DB7D964CF58A0ADBFBFA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 00:09, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>> index a8f8844..d816448 100644 >>>>>> --- a/arch/x86/xen/enlighten.c >>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>> static u32 xen_apic_read(u32 reg) >>>>>> { >>>>>> - return 0; >>>>>> + struct xen_platform_op op =3D { >>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>> >>>>> >>>>> Is this always zero? This will probably solve the current problem >>>> >>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>> >>> Why not use CPU number instead of zero here? >> >> The issue was only with the bootup CPU - so was using the Xen's >> bootup CPU number - which is zero (as is Linux's). >=20 > I agree that for this particular problem this may be sufficient. >=20 > My concern is that in the future someone may decide to use apic_read(AP= IC_ID) or > read_apic_id() for some other purpose and they won't get expected resul= t (i.e. > on all CPUs they will get the same answer). >=20 >> >>> >>>> >>>>> but I am wondering whether in the future we might hit another bug >>>>> because this routine will return the same APICID for all VCPUs. >>>> >>>> Later on it does a check for 'smp_processor_id()' - and if >>>> that is anything but zero it will bail out. >>> >>> Can you point me to the check you are referring to? >> >> if (!xen_initial_domain() || smp_processor_id()) >=20 > I don't see this line --- neither in the mainline nor in your kernel. W= hich > kernel and which routine is this in? This is in the inline patch Konrad asked me to check. >=20 > BTW, this patch doesn't quite work, xen-acpi-processor driver fails to = load with > the same error as before. I'll look at this tomorrow more carefully. It does fail but at least for me it seems slightly different. I do the mo= dprobe after turning on all acpi debugging levels and layers. And without any ch= ange there are queries visible. With that patch the driver just fails but ther= e are no queries. I plan to have another go with messages sprinkled to all exit= paths today, too (was just a bit too late and two pints later yesterday). -Stefan >=20 >=20 > -boris >=20 >> >> >>> >>> -boris >>> >>> >>>> >>>> So this shoudl solve the problem for the bootup processor. >>>>> >>>>> -boris >>>>> >>>>> >>>>>> + }; >>>>>> + int ret =3D 0; >>>>>> + >>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we o= nly >>>>>> + * get called on the bootup processor. But just in case. */ >>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>> + return 0; >>>>>> + >>>>>> + if (reg =3D=3D APIC_LVR) >>>>>> + return 0x10; >>>>>> + >>>>>> + if (reg !=3D APIC_ID) >>>>>> + return 0; >>>>>> + >>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>> + if (ret) >>>>>> + return 0; >>>>>> + >>>>>> + return op.u.pcpu_info.apic_id; >>>>>> } >>>>>> >>>>>> static void xen_apic_write(u32 reg, u32 val) >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 --------------enigE4D7DB7D964CF58A0ADBFBFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoiv/AAoJEOhnXe7L7s6j6Z0P/1gvbeEvQMj5VA+TgaDC8yH6 jQ6Z/walWWrge3LCQR8coUo66JSq7yQFy9FQTCEDSPYG4gHJJTicabVtni6aeXkv bjfOWIQcFiUmzzR6/mzDM1CSeZ0ICoRQ8QJOPq7RnEtP2BZOUCD/M3JUOEn8A1rg 06aU6Yw2v2wJNfb3PIgovGnPpu8GMcBbRPS9r9THqVDSis8fK0JRtD6NqtWz5koc uTLapvKP+Fys4qTZeseeAtptnzaR/M8qviJJ+1Upm0XU3Sl6yBF0K/Spczf9HgLT g5neXdz/CfhHqkYtGpphBzZaCS02olrevGRZlAgbo3EtfNiQhqqfFIgbB9cVz3Yb x5zD3tXoqA23w0kVp/zuRnHz7CEm61OSBDgLEsP9TcK0zXZZf24mcxGSyPY6J6py PRdW9ubQeuQQy1ei19we3rRy9A69jHQC6Cw26ZAd/CRhH4taBpWfIYKQlZUJQp+T ZVWN5RJjt7tefGRVFgQEuVdWyl0QlPvqcbEuEkEe2ff5cUBi7OkiJtbyxEzhOBk0 t4sU+OOR6a+t5EkVYGZeq70yViNZEYaMvRxUO6sv/FRj8i6bFZT414nmR0bxmzov 9KzsGKsIGoCcEzEU9za3Vem3LM/0CnijdSqeMsBmdvUwiX8SwQZEua68UtDGPIbx xQuBf7PU9xg2Jzw+gT5V =3DmT -----END PGP SIGNATURE----- --------------enigE4D7DB7D964CF58A0ADBFBFA-- --===============4098233777693533906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4098233777693533906==-- From xen-devel-bounces@lists.xen.org Thu May 03 06:56:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 06:56:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpxO-0006Ol-3k; Thu, 03 May 2012 06:56:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPpxM-0006Og-RS for xen-devel@lists.xensource.com; Thu, 03 May 2012 06:56:05 +0000 Received: from [85.158.139.83:64813] by server-9.bemta-5.messagelabs.com id 23/CB-09826-40C22AF4; Thu, 03 May 2012 06:56:04 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336028163!25987757!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8134 invoked from network); 3 May 2012 06:56:03 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-182.messagelabs.com with SMTP; 3 May 2012 06:56:03 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPpxJ-0007fj-Dg; Thu, 03 May 2012 06:56:01 +0000 Message-ID: <4FA22BF8.2050409@canonical.com> Date: Thu, 03 May 2012 08:55:52 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> In-Reply-To: <4FA1B096.5010009@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4098233777693533906==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4098233777693533906== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE4D7DB7D964CF58A0ADBFBFA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4D7DB7D964CF58A0ADBFBFA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 00:09, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>> index a8f8844..d816448 100644 >>>>>> --- a/arch/x86/xen/enlighten.c >>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>> static u32 xen_apic_read(u32 reg) >>>>>> { >>>>>> - return 0; >>>>>> + struct xen_platform_op op =3D { >>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>> >>>>> >>>>> Is this always zero? This will probably solve the current problem >>>> >>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>> >>> Why not use CPU number instead of zero here? >> >> The issue was only with the bootup CPU - so was using the Xen's >> bootup CPU number - which is zero (as is Linux's). >=20 > I agree that for this particular problem this may be sufficient. >=20 > My concern is that in the future someone may decide to use apic_read(AP= IC_ID) or > read_apic_id() for some other purpose and they won't get expected resul= t (i.e. > on all CPUs they will get the same answer). >=20 >> >>> >>>> >>>>> but I am wondering whether in the future we might hit another bug >>>>> because this routine will return the same APICID for all VCPUs. >>>> >>>> Later on it does a check for 'smp_processor_id()' - and if >>>> that is anything but zero it will bail out. >>> >>> Can you point me to the check you are referring to? >> >> if (!xen_initial_domain() || smp_processor_id()) >=20 > I don't see this line --- neither in the mainline nor in your kernel. W= hich > kernel and which routine is this in? This is in the inline patch Konrad asked me to check. >=20 > BTW, this patch doesn't quite work, xen-acpi-processor driver fails to = load with > the same error as before. I'll look at this tomorrow more carefully. It does fail but at least for me it seems slightly different. I do the mo= dprobe after turning on all acpi debugging levels and layers. And without any ch= ange there are queries visible. With that patch the driver just fails but ther= e are no queries. I plan to have another go with messages sprinkled to all exit= paths today, too (was just a bit too late and two pints later yesterday). -Stefan >=20 >=20 > -boris >=20 >> >> >>> >>> -boris >>> >>> >>>> >>>> So this shoudl solve the problem for the bootup processor. >>>>> >>>>> -boris >>>>> >>>>> >>>>>> + }; >>>>>> + int ret =3D 0; >>>>>> + >>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we o= nly >>>>>> + * get called on the bootup processor. But just in case. */ >>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>> + return 0; >>>>>> + >>>>>> + if (reg =3D=3D APIC_LVR) >>>>>> + return 0x10; >>>>>> + >>>>>> + if (reg !=3D APIC_ID) >>>>>> + return 0; >>>>>> + >>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>> + if (ret) >>>>>> + return 0; >>>>>> + >>>>>> + return op.u.pcpu_info.apic_id; >>>>>> } >>>>>> >>>>>> static void xen_apic_write(u32 reg, u32 val) >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 --------------enigE4D7DB7D964CF58A0ADBFBFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoiv/AAoJEOhnXe7L7s6j6Z0P/1gvbeEvQMj5VA+TgaDC8yH6 jQ6Z/walWWrge3LCQR8coUo66JSq7yQFy9FQTCEDSPYG4gHJJTicabVtni6aeXkv bjfOWIQcFiUmzzR6/mzDM1CSeZ0ICoRQ8QJOPq7RnEtP2BZOUCD/M3JUOEn8A1rg 06aU6Yw2v2wJNfb3PIgovGnPpu8GMcBbRPS9r9THqVDSis8fK0JRtD6NqtWz5koc uTLapvKP+Fys4qTZeseeAtptnzaR/M8qviJJ+1Upm0XU3Sl6yBF0K/Spczf9HgLT g5neXdz/CfhHqkYtGpphBzZaCS02olrevGRZlAgbo3EtfNiQhqqfFIgbB9cVz3Yb x5zD3tXoqA23w0kVp/zuRnHz7CEm61OSBDgLEsP9TcK0zXZZf24mcxGSyPY6J6py PRdW9ubQeuQQy1ei19we3rRy9A69jHQC6Cw26ZAd/CRhH4taBpWfIYKQlZUJQp+T ZVWN5RJjt7tefGRVFgQEuVdWyl0QlPvqcbEuEkEe2ff5cUBi7OkiJtbyxEzhOBk0 t4sU+OOR6a+t5EkVYGZeq70yViNZEYaMvRxUO6sv/FRj8i6bFZT414nmR0bxmzov 9KzsGKsIGoCcEzEU9za3Vem3LM/0CnijdSqeMsBmdvUwiX8SwQZEua68UtDGPIbx xQuBf7PU9xg2Jzw+gT5V =3DmT -----END PGP SIGNATURE----- --------------enigE4D7DB7D964CF58A0ADBFBFA-- --===============4098233777693533906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4098233777693533906==-- From xen-devel-bounces@lists.xen.org Thu May 03 07:22:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 07: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 ) id 1SPqMR-0006rS-8Y; Thu, 03 May 2012 07:21:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPqMP-0006rN-Lv for xen-devel@lists.xensource.com; Thu, 03 May 2012 07:21:57 +0000 Received: from [193.109.254.147:2081] by server-11.bemta-14.messagelabs.com id F0/0D-05858-41232AF4; Thu, 03 May 2012 07:21:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336029690!7390286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18510 invoked from network); 3 May 2012 07:21:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 07:21:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,521,1330905600"; d="scan'208";a="12264767" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07: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, 3 May 2012 08:21:30 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPqLy-0008Ek-1B; Thu, 03 May 2012 07:21:30 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPqLx-0000AO-VD; Thu, 03 May 2012 08:21:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 08:21:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12785: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12785 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12785/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=a21938b58fc4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 a21938b58fc4 + branch=xen-4.1-testing + revision=a21938b58fc4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r a21938b58fc4 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 07:22:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 07: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 ) id 1SPqMR-0006rS-8Y; Thu, 03 May 2012 07:21:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPqMP-0006rN-Lv for xen-devel@lists.xensource.com; Thu, 03 May 2012 07:21:57 +0000 Received: from [193.109.254.147:2081] by server-11.bemta-14.messagelabs.com id F0/0D-05858-41232AF4; Thu, 03 May 2012 07:21:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336029690!7390286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18510 invoked from network); 3 May 2012 07:21:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 07:21:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,521,1330905600"; d="scan'208";a="12264767" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07: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, 3 May 2012 08:21:30 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPqLy-0008Ek-1B; Thu, 03 May 2012 07:21:30 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPqLx-0000AO-VD; Thu, 03 May 2012 08:21:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 3 May 2012 08:21:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12785: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12785 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12785/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12746 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen a21938b58fc4 baseline version: xen 99517f769cc8 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=a21938b58fc4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 a21938b58fc4 + branch=xen-4.1-testing + revision=a21938b58fc4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r a21938b58fc4 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:11:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:11:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPr7u-0007oT-DO; Thu, 03 May 2012 08:11:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPr7t-0007oK-C7 for xen-devel@lists.xen.org; Thu, 03 May 2012 08:11:01 +0000 Received: from [85.158.138.51:63362] by server-8.bemta-3.messagelabs.com id 01/AF-24428-49D32AF4; Thu, 03 May 2012 08:11:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336032659!24944201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23488 invoked from network); 3 May 2012 08:11:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:11:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,521,1330905600"; d="scan'208";a="12265812" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 08:10:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 09:10:59 +0100 Message-ID: <1336032658.6367.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Thu, 3 May 2012 09:10:58 +0100 In-Reply-To: <1336007032.874.12.camel@Abyss> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <1336007032.874.12.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andre Przywara , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 02:03 +0100, Dario Faggioli wrote: > On Wed, 2012-05-02 at 18:30 +0200, Dario Faggioli wrote: > > > > + > > > > + if (use_cpus>= b_info->max_vcpus) { > > > > + rc = 0; > > > > + break; > > > > + } > > > Hmm -- there's got to be a better way to find out the minimum number > > > of nodes to house a given number of vcpus than just starting at 1 > > > and re-trying until we have enough. > > > > ... > > > > However, if what you mean is I could check beforehand whether or not > > the > > user provided configuration will give us enough CPUs and avoid testing > > scenarios that are guaranteed to fail, then I agree and I'll reshape > > the > > code to look like that. > > > Actually, thinking more about this, I'm not even sure I can do what I > stated above. In fact, I don't think I can assume the number of CPUs > each node is made up of to be known, without actually checking it for > the specific node(s) I want to try using. What if some CPUs are off-line > and stuff like that? > > I might have to recheck, but reading topology information takes > on/offline-ness into account, which is something I lose if I assume some > static x number of CPUs in each node. Also, are we sure archs with > different number of CPUs in different nodes won't ever exist? :-P > Finally, consider this is likely going to change when we will have some > mechanism for taking the actual load on the CPUs into account, so maybe > it's not worth spending much time on it right now. > > So, given what we currently export wrt topology, and all the above, I'm > not sure I can see any cleverer way of figuring our how many CPUs/nodes > I need than explicitly counting them (for what it counts, xend is also > doing the same AFAIUI :-) ). If xend does it this way then this is IMHO also appropriate for (lib)xl in 4.2 at this stage in the release. For 4.3 we can figure out the right way to do it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:11:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:11:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPr7u-0007oT-DO; Thu, 03 May 2012 08:11:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPr7t-0007oK-C7 for xen-devel@lists.xen.org; Thu, 03 May 2012 08:11:01 +0000 Received: from [85.158.138.51:63362] by server-8.bemta-3.messagelabs.com id 01/AF-24428-49D32AF4; Thu, 03 May 2012 08:11:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336032659!24944201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NjY0MA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23488 invoked from network); 3 May 2012 08:11:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:11:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,521,1330905600"; d="scan'208";a="12265812" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 08:10:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 09:10:59 +0100 Message-ID: <1336032658.6367.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Thu, 3 May 2012 09:10:58 +0100 In-Reply-To: <1336007032.874.12.camel@Abyss> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <1336007032.874.12.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andre Przywara , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 02:03 +0100, Dario Faggioli wrote: > On Wed, 2012-05-02 at 18:30 +0200, Dario Faggioli wrote: > > > > + > > > > + if (use_cpus>= b_info->max_vcpus) { > > > > + rc = 0; > > > > + break; > > > > + } > > > Hmm -- there's got to be a better way to find out the minimum number > > > of nodes to house a given number of vcpus than just starting at 1 > > > and re-trying until we have enough. > > > > ... > > > > However, if what you mean is I could check beforehand whether or not > > the > > user provided configuration will give us enough CPUs and avoid testing > > scenarios that are guaranteed to fail, then I agree and I'll reshape > > the > > code to look like that. > > > Actually, thinking more about this, I'm not even sure I can do what I > stated above. In fact, I don't think I can assume the number of CPUs > each node is made up of to be known, without actually checking it for > the specific node(s) I want to try using. What if some CPUs are off-line > and stuff like that? > > I might have to recheck, but reading topology information takes > on/offline-ness into account, which is something I lose if I assume some > static x number of CPUs in each node. Also, are we sure archs with > different number of CPUs in different nodes won't ever exist? :-P > Finally, consider this is likely going to change when we will have some > mechanism for taking the actual load on the CPUs into account, so maybe > it's not worth spending much time on it right now. > > So, given what we currently export wrt topology, and all the above, I'm > not sure I can see any cleverer way of figuring our how many CPUs/nodes > I need than explicitly counting them (for what it counts, xend is also > doing the same AFAIUI :-) ). If xend does it this way then this is IMHO also appropriate for (lib)xl in 4.2 at this stage in the release. For 4.3 we can figure out the right way to do it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:33:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:33:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPrSy-00007Z-0S; Thu, 03 May 2012 08:32:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPrSw-00007I-7C for xen-devel@lists.xensource.com; Thu, 03 May 2012 08:32:46 +0000 Received: from [85.158.143.99:31326] by server-2.bemta-4.messagelabs.com id 51/76-17550-DA242AF4; Thu, 03 May 2012 08:32:45 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336033962!25952904!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19634 invoked from network); 3 May 2012 08:32:43 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:32:43 -0000 Received: by qady23 with SMTP id y23so88222qad.7 for ; Thu, 03 May 2012 01:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FQULWGCoJHd2IzhRNcF8z0Zq5f7ByYcbC9UIwLCxNAs=; b=vVqX1g2eDXPkQF54fcDfJLn6T0gm/FTtoAFlPmzKWyFCpmp2BQ6q/CbJlidGm+LMfC dsMG3Z13qsh4kKO7AygEvGl01lgOk2OA8C9tBPI78DVfDAjMLN6JfBLEAqyUd9cj56SV s9w/YaIUlUF1/TpIEJkRSCvgwPyzC6WE70glDRg2BSSRJKMK5IFUxlR+dDFaHgjijack tgP36e19NY1aCKwQrft6ugRB7Fi4iiDp/bjsbZJfl4oiZlA4CP6eg+vMNmGMOKsyVrLj x2HcWG+J4LqkR4rTvLKm6pUe65IwvkkkjOSFW5marO06Ct5H7vddNQilaGb9Tt5wPlnT CH5g== MIME-Version: 1.0 Received: by 10.224.193.8 with SMTP id ds8mr2647094qab.1.1336033962085; Thu, 03 May 2012 01:32:42 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Thu, 3 May 2012 01:32:41 -0700 (PDT) In-Reply-To: <4FA16875.5020801@hfp.de> References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> <4FA16875.5020801@hfp.de> Date: Thu, 3 May 2012 09:32:41 +0100 X-Google-Sender-Auth: hvN19bY-67Q9Bt4Hlw-1VvA3zlY Message-ID: From: George Dunlap To: Andreas Kinzler Cc: David Vrabel , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 6:01 PM, Andreas Kinzler wrote: > On 02.05.2012 15:30, David Vrabel wrote: >> >> Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly >> check for pending events when restoring irq flags"[1] and see how much >> it helps? > > > There is some minor improvement - but it is still far away from xenified > 2.6.34.10. Just FYI, the reason Ian suggested making the same comparison for native is that the performance of linux overall on bare-metal has also suffered since 2.6.34. It's likely that a non-trivial amount of the performance regression is due to moving from 2.6.34 to 3.{2,3}, over and above whatever regressions may have happened when moving from xenified to pvops. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:33:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:33:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPrSy-00007Z-0S; Thu, 03 May 2012 08:32:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPrSw-00007I-7C for xen-devel@lists.xensource.com; Thu, 03 May 2012 08:32:46 +0000 Received: from [85.158.143.99:31326] by server-2.bemta-4.messagelabs.com id 51/76-17550-DA242AF4; Thu, 03 May 2012 08:32:45 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336033962!25952904!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19634 invoked from network); 3 May 2012 08:32:43 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:32:43 -0000 Received: by qady23 with SMTP id y23so88222qad.7 for ; Thu, 03 May 2012 01:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FQULWGCoJHd2IzhRNcF8z0Zq5f7ByYcbC9UIwLCxNAs=; b=vVqX1g2eDXPkQF54fcDfJLn6T0gm/FTtoAFlPmzKWyFCpmp2BQ6q/CbJlidGm+LMfC dsMG3Z13qsh4kKO7AygEvGl01lgOk2OA8C9tBPI78DVfDAjMLN6JfBLEAqyUd9cj56SV s9w/YaIUlUF1/TpIEJkRSCvgwPyzC6WE70glDRg2BSSRJKMK5IFUxlR+dDFaHgjijack tgP36e19NY1aCKwQrft6ugRB7Fi4iiDp/bjsbZJfl4oiZlA4CP6eg+vMNmGMOKsyVrLj x2HcWG+J4LqkR4rTvLKm6pUe65IwvkkkjOSFW5marO06Ct5H7vddNQilaGb9Tt5wPlnT CH5g== MIME-Version: 1.0 Received: by 10.224.193.8 with SMTP id ds8mr2647094qab.1.1336033962085; Thu, 03 May 2012 01:32:42 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Thu, 3 May 2012 01:32:41 -0700 (PDT) In-Reply-To: <4FA16875.5020801@hfp.de> References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> <4FA16875.5020801@hfp.de> Date: Thu, 3 May 2012 09:32:41 +0100 X-Google-Sender-Auth: hvN19bY-67Q9Bt4Hlw-1VvA3zlY Message-ID: From: George Dunlap To: Andreas Kinzler Cc: David Vrabel , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 6:01 PM, Andreas Kinzler wrote: > On 02.05.2012 15:30, David Vrabel wrote: >> >> Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly >> check for pending events when restoring irq flags"[1] and see how much >> it helps? > > > There is some minor improvement - but it is still far away from xenified > 2.6.34.10. Just FYI, the reason Ian suggested making the same comparison for native is that the performance of linux overall on bare-metal has also suffered since 2.6.34. It's likely that a non-trivial amount of the performance regression is due to moving from 2.6.34 to 3.{2,3}, over and above whatever regressions may have happened when moving from xenified to pvops. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:49:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:49:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPriN-0000Qf-Gx; Thu, 03 May 2012 08:48:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPriM-0000Qa-KN for xen-devel@lists.xensource.com; Thu, 03 May 2012 08:48:43 +0000 Received: from [85.158.139.83:41586] by server-9.bemta-5.messagelabs.com id EB/8C-09826-96642AF4; Thu, 03 May 2012 08:48:41 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336034920!22274343!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16211 invoked from network); 3 May 2012 08:48:41 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:48:41 -0000 Received: by lbom4 with SMTP id m4so1253718lbo.30 for ; Thu, 03 May 2012 01:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6MU+KoSbg6NjK9Top2TCxcQOKcjtwPRkAlFuArLIR5c=; b=IDOGX/9QSWQl4mwYnM/2Lb+kuHYP6FP0oT9zt88c5K6JkRS103EoOkVP9bxlFXQgn4 iNDVd2Ykwf9h2CqziFkhL3IboJXiXzLzG/5zrLB4Ub6PYKMeXxeNB7oJ3/8JA+OPiFHq tHtDdiCpwtguhq4371iAVM1Xrq/Xnd6WBlqEkYDj0craqSSyebvWcN4C0I5vi7+w+tZS u1XELX33PBbtBTOkOI9pHIMlKgrCGx1V24y7l7h85YLjLN0zfswTMN6xohwqCSTg70zz XjioGGX6Aosy3/t451RB7Y1FCQgz2EkVxOuOWe4iVh5DhGbnnstz2dXZSgRdkMPMHPk1 51WA== Received: by 10.112.85.39 with SMTP id e7mr614831lbz.56.1336034920079; Thu, 03 May 2012 01:48:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.45.194 with HTTP; Thu, 3 May 2012 01:48:19 -0700 (PDT) In-Reply-To: <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> <20120117162414.GA25281@spongy.cam.xci-test.com> <20120131145142.GB23556@spongy.cam.xci-test.com> From: Jean Guyader Date: Thu, 3 May 2012 09:48:19 +0100 Message-ID: To: Jean Guyader Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , "allen.m.kay@intel.com" , Ian Jackson , Jean Guyader , "konrad@darnok.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 31 January 2012 14:51, Jean Guyader wrote: > > 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 > > > > > 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 > > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 > > > > > >> Author: Jean Guyader > > > > > >> 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? > Hi Ian, I was going through my email and it seems that this patch didn't make it into qemu-xen-unstable. Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 08:49:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 08:49:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPriN-0000Qf-Gx; Thu, 03 May 2012 08:48:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPriM-0000Qa-KN for xen-devel@lists.xensource.com; Thu, 03 May 2012 08:48:43 +0000 Received: from [85.158.139.83:41586] by server-9.bemta-5.messagelabs.com id EB/8C-09826-96642AF4; Thu, 03 May 2012 08:48:41 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336034920!22274343!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16211 invoked from network); 3 May 2012 08:48:41 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 08:48:41 -0000 Received: by lbom4 with SMTP id m4so1253718lbo.30 for ; Thu, 03 May 2012 01:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6MU+KoSbg6NjK9Top2TCxcQOKcjtwPRkAlFuArLIR5c=; b=IDOGX/9QSWQl4mwYnM/2Lb+kuHYP6FP0oT9zt88c5K6JkRS103EoOkVP9bxlFXQgn4 iNDVd2Ykwf9h2CqziFkhL3IboJXiXzLzG/5zrLB4Ub6PYKMeXxeNB7oJ3/8JA+OPiFHq tHtDdiCpwtguhq4371iAVM1Xrq/Xnd6WBlqEkYDj0craqSSyebvWcN4C0I5vi7+w+tZS u1XELX33PBbtBTOkOI9pHIMlKgrCGx1V24y7l7h85YLjLN0zfswTMN6xohwqCSTg70zz XjioGGX6Aosy3/t451RB7Y1FCQgz2EkVxOuOWe4iVh5DhGbnnstz2dXZSgRdkMPMHPk1 51WA== Received: by 10.112.85.39 with SMTP id e7mr614831lbz.56.1336034920079; Thu, 03 May 2012 01:48:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.45.194 with HTTP; Thu, 3 May 2012 01:48:19 -0700 (PDT) In-Reply-To: <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> <20120117162414.GA25281@spongy.cam.xci-test.com> <20120131145142.GB23556@spongy.cam.xci-test.com> From: Jean Guyader Date: Thu, 3 May 2012 09:48:19 +0100 Message-ID: To: Jean Guyader Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , "allen.m.kay@intel.com" , Ian Jackson , Jean Guyader , "konrad@darnok.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 31 January 2012 14:51, Jean Guyader wrote: > > 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 > > > > > 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 > > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 > > > > > >> Author: Jean Guyader > > > > > >> 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? > Hi Ian, I was going through my email and it seems that this patch didn't make it into qemu-xen-unstable. Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 09:16:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 09: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 ) id 1SPs8M-00013N-Nt; Thu, 03 May 2012 09:15:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPs8K-00013I-KT for xen-devel@lists.xen.org; Thu, 03 May 2012 09:15:32 +0000 Received: from [85.158.143.35:61919] by server-3.bemta-4.messagelabs.com id D5/AF-05853-3BC42AF4; Thu, 03 May 2012 09:15:31 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336036529!15238303!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29146 invoked from network); 3 May 2012 09:15:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 09:15:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 10:15:28 +0100 Message-Id: <4FA268CD02000078000814E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 10:15:25 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 20:42, AP wrote: > On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>> I somehow thought that this has been fixed but I've been >>> getting reports that people are running into this. >> >> "this" being what? I too thought that all xsave related issues were >> sorted out by now. > > I see the following crash if I run without xsave=0 with Ubuntu 11.10 > 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with > Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. And in the thread starting at http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html I gave debugging instructions that apparently no-one followed so far. Without someone seeing the problem doing so I don't think we will ever get anywhere with this (unless, as also indicated there, someone can spot something wrong with the code that non-obvious to everyone else). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 09:16:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 09: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 ) id 1SPs8M-00013N-Nt; Thu, 03 May 2012 09:15:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPs8K-00013I-KT for xen-devel@lists.xen.org; Thu, 03 May 2012 09:15:32 +0000 Received: from [85.158.143.35:61919] by server-3.bemta-4.messagelabs.com id D5/AF-05853-3BC42AF4; Thu, 03 May 2012 09:15:31 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336036529!15238303!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29146 invoked from network); 3 May 2012 09:15:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 09:15:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 10:15:28 +0100 Message-Id: <4FA268CD02000078000814E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 10:15:25 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 20:42, AP wrote: > On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>> I somehow thought that this has been fixed but I've been >>> getting reports that people are running into this. >> >> "this" being what? I too thought that all xsave related issues were >> sorted out by now. > > I see the following crash if I run without xsave=0 with Ubuntu 11.10 > 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with > Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. And in the thread starting at http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html I gave debugging instructions that apparently no-one followed so far. Without someone seeing the problem doing so I don't think we will ever get anywhere with this (unless, as also indicated there, someone can spot something wrong with the code that non-obvious to everyone else). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 09:27:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 09:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsJN-0001D2-0n; Thu, 03 May 2012 09:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsJL-0001Cx-Rg for xen-devel@lists.xen.org; Thu, 03 May 2012 09:26:56 +0000 Received: from [85.158.139.83:51408] by server-11.bemta-5.messagelabs.com id FB/A1-12959-F5F42AF4; Thu, 03 May 2012 09:26:55 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336037213!22685336!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_DONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24421 invoked from network); 3 May 2012 09:26:54 -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; 3 May 2012 09:26:54 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 10:26:52 +0100 Message-Id: <4FA26B7C0200007800081502@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 10:26:52 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 02:25, "Dong, Eddie" wrote: >> >> >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> >> to the documentation here either (should also result in >> >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> >> should be annotated with a comment saying why fall-through is >> >> intended here). Nor does the documentation state that TRAP_debug >> >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. >> > >> > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & >> #BP, >> > It seems we are slightly different here. Let me check w/ internal person. >> >> Thanks. > > The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION > Per SDM and confirmation from our HW guys. We will send fixes soon. Please also have the opcode 0xF1 generated #DB addressed in whatever is the appropriate way. >> >> Finally, the whole injection logic (including the patch here) doesn't >> >> appear to cope with INT nn being used by a guest with nn < 32, nor >> > >> > The original code path works for the privilege violation introduced >> > exceptions, >> > It seems we probbaly need a new code for INT n emulation for both >> interrupt & >> > exceptions. >> >> Indeed. > > This API vmx_inject_hw_exception is never intended to be used for INT nn > emulation, > Rather it is designed for the exceptions generated by processor-detected > program-error exceptions and machine check exceptions. > > If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is > incorrect. We need a new API for that purpose, and use software interrupt. > Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM > mentioned. I'm sure he took it to be the correct one because it previously handled #BP too. >> >> with any (pointless) prefixes used on INT3 or INT nn. >> >> >> > What specific prefix do u mean here? >> >> Anyone except perhaps LOCK - none of them should have any effect >> other than making the instruction longer. >> > LOCK can never be used as prefix of INT nn instruction, nor can REPx prefix. > Can you provide more details as for this concern? The only prefix that is documented to cause #UD here is LOCK. All other prefixes should consequently be considered ignored, and so should the emulation do (and properly handle resulting instruction lengths). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 09:27:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 09:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsJN-0001D2-0n; Thu, 03 May 2012 09:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsJL-0001Cx-Rg for xen-devel@lists.xen.org; Thu, 03 May 2012 09:26:56 +0000 Received: from [85.158.139.83:51408] by server-11.bemta-5.messagelabs.com id FB/A1-12959-F5F42AF4; Thu, 03 May 2012 09:26:55 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336037213!22685336!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_DONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24421 invoked from network); 3 May 2012 09:26:54 -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; 3 May 2012 09:26:54 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 10:26:52 +0100 Message-Id: <4FA26B7C0200007800081502@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 10:26:52 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 02:25, "Dong, Eddie" wrote: >> >> >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> >> to the documentation here either (should also result in >> >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> >> should be annotated with a comment saying why fall-through is >> >> intended here). Nor does the documentation state that TRAP_debug >> >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. >> > >> > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & >> #BP, >> > It seems we are slightly different here. Let me check w/ internal person. >> >> Thanks. > > The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION > Per SDM and confirmation from our HW guys. We will send fixes soon. Please also have the opcode 0xF1 generated #DB addressed in whatever is the appropriate way. >> >> Finally, the whole injection logic (including the patch here) doesn't >> >> appear to cope with INT nn being used by a guest with nn < 32, nor >> > >> > The original code path works for the privilege violation introduced >> > exceptions, >> > It seems we probbaly need a new code for INT n emulation for both >> interrupt & >> > exceptions. >> >> Indeed. > > This API vmx_inject_hw_exception is never intended to be used for INT nn > emulation, > Rather it is designed for the exceptions generated by processor-detected > program-error exceptions and machine check exceptions. > > If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is > incorrect. We need a new API for that purpose, and use software interrupt. > Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM > mentioned. I'm sure he took it to be the correct one because it previously handled #BP too. >> >> with any (pointless) prefixes used on INT3 or INT nn. >> >> >> > What specific prefix do u mean here? >> >> Anyone except perhaps LOCK - none of them should have any effect >> other than making the instruction longer. >> > LOCK can never be used as prefix of INT nn instruction, nor can REPx prefix. > Can you provide more details as for this concern? The only prefix that is documented to cause #UD here is LOCK. All other prefixes should consequently be considered ignored, and so should the emulation do (and properly handle resulting instruction lengths). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:01:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:01:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsqc-0001VJ-3h; Thu, 03 May 2012 10:01:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsqY-0001VE-Uk for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:01:15 +0000 Received: from [85.158.143.35:9429] by server-1.bemta-4.messagelabs.com id 42/1E-20925-A6752AF4; Thu, 03 May 2012 10:01:14 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336039263!14560293!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4994 invoked from network); 3 May 2012 10:01:04 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-21.messagelabs.com with SMTP; 3 May 2012 10:01:04 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPsqK-0005l8-Ec; Thu, 03 May 2012 10:01:02 +0000 Message-ID: <4FA25752.8010807@canonical.com> Date: Thu, 03 May 2012 12:00:50 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA22BF8.2050409@canonical.com> In-Reply-To: <4FA22BF8.2050409@canonical.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4024771420858992763==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4024771420858992763== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig44CE6C0905155E36B06E265B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44CE6C0905155E36B06E265B Content-Type: multipart/mixed; boundary="------------060305080106050804080206" This is a multi-part message in MIME format. --------------060305080106050804080206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 08:55, Stefan Bader wrote: > On 03.05.2012 00:09, Boris Ostrovsky wrote: >> On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>>> index a8f8844..d816448 100644 >>>>>>> --- a/arch/x86/xen/enlighten.c >>>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>>> static u32 xen_apic_read(u32 reg) >>>>>>> { >>>>>>> - return 0; >>>>>>> + struct xen_platform_op op =3D { >>>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>>> >>>>>> >>>>>> Is this always zero? This will probably solve the current problem >>>>> >>>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>>> >>>> Why not use CPU number instead of zero here? >>> >>> The issue was only with the bootup CPU - so was using the Xen's >>> bootup CPU number - which is zero (as is Linux's). >> >> I agree that for this particular problem this may be sufficient. >> >> My concern is that in the future someone may decide to use apic_read(A= PIC_ID) or >> read_apic_id() for some other purpose and they won't get expected resu= lt (i.e. >> on all CPUs they will get the same answer). >> >>> >>>> >>>>> >>>>>> but I am wondering whether in the future we might hit another bug >>>>>> because this routine will return the same APICID for all VCPUs. >>>>> >>>>> Later on it does a check for 'smp_processor_id()' - and if >>>>> that is anything but zero it will bail out. >>>> >>>> Can you point me to the check you are referring to? >>> >>> if (!xen_initial_domain() || smp_processor_id()) >> >> I don't see this line --- neither in the mainline nor in your kernel. = Which >> kernel and which routine is this in? >=20 > This is in the inline patch Konrad asked me to check. >> >> BTW, this patch doesn't quite work, xen-acpi-processor driver fails to= load with >> the same error as before. I'll look at this tomorrow more carefully. >=20 > It does fail but at least for me it seems slightly different. I do the = modprobe > after turning on all acpi debugging levels and layers. And without any = change > there are queries visible. With that patch the driver just fails but th= ere are > no queries. I plan to have another go with messages sprinkled to all ex= it paths > today, too (was just a bit too late and two pints later yesterday). Gah! Once you do it right... It *does* fail the exactly same way and ther= e are some acpi debug messages... >=20 >=20 > -Stefan >> >> >> -boris >> >>> >>> >>>> >>>> -boris >>>> >>>> >>>>> >>>>> So this shoudl solve the problem for the bootup processor. >>>>>> >>>>>> -boris >>>>>> >>>>>> >>>>>>> + }; >>>>>>> + int ret =3D 0; >>>>>>> + >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we = only >>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>> + return 0; >>>>>>> + >>>>>>> + if (reg =3D=3D APIC_LVR) >>>>>>> + return 0x10; >>>>>>> + >>>>>>> + if (reg !=3D APIC_ID) >>>>>>> + return 0; >>>>>>> + >>>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>>> + if (ret) >>>>>>> + return 0; >>>>>>> + >>>>>>> + return op.u.pcpu_info.apic_id; >>>>>>> } >>>>>>> >>>>>>> static void xen_apic_write(u32 reg, u32 val) >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >>> >> >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------060305080106050804080206 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.4" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.4" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg4 SMP Thu May 3 09:28:4= 7 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg4-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.196 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.39 BogoMIPS (lpj=3D8000784) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.007694] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016580] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019111] Mount-cache hash table entries: 256 [ 0.019360] Initializing cgroup subsys cpuacct [ 0.019372] Initializing cgroup subsys memory [ 0.019391] Initializing cgroup subsys devices [ 0.019397] Initializing cgroup subsys freezer [ 0.019402] Initializing cgroup subsys blkio [ 0.019419] Initializing cgroup subsys perf_event [ 0.019493] tseg: 00dff00000 [ 0.019500] CPU: Physical Processor ID: 0 [ 0.019504] CPU: Processor Core ID: 0 [ 0.022409] ACPI: Core revision 20110623 [ 0.038591] ftrace: allocating 27102 entries in 107 pages [ 0.040131] cpu 0 spinlock event irq 273 [ 0.040232] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040494] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040624] installing Xen timer for CPU 1 [ 0.040642] cpu 1 spinlock event irq 279 [ 0.040844] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040967] installing Xen timer for CPU 2 [ 0.040986] cpu 2 spinlock event irq 285 [ 0.041142] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041258] installing Xen timer for CPU 3 [ 0.041273] cpu 3 spinlock event irq 291 [ 0.041435] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041552] installing Xen timer for CPU 4 [ 0.041568] cpu 4 spinlock event irq 297 [ 0.041752] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041878] installing Xen timer for CPU 5 [ 0.041894] cpu 5 spinlock event irq 303 [ 0.042056] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042171] installing Xen timer for CPU 6 [ 0.042188] cpu 6 spinlock event irq 309 [ 0.042343] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042459] installing Xen timer for CPU 7 [ 0.042474] cpu 7 spinlock event irq 315 [ 0.042633] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042665] Brought up 8 CPUs [ 0.042894] devtmpfs: initialized [ 0.045534] EVM: security.selinux [ 0.045539] EVM: security.SMACK64 [ 0.045543] EVM: security.capability [ 0.045619] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045619] Grant table initialized [ 0.045619] print_constraints: dummy:=20 [ 0.045619] RTC time: 9:53:40, date: 05/03/12 [ 0.045619] NET: Registered protocol family 16 [ 0.045619] Trying to unpack rootfs image as initramfs... [ 0.060271] node 0 link 0: io port [1000, ffffff] [ 0.060287] TOM: 00000000e0000000 aka 3584M [ 0.060294] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060304] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060313] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060321] node 0 link 0: mmio [a0000, bffff] [ 0.060329] TOM2: 0000000820000000 aka 33280M [ 0.060334] bus: [00, 1f] on node 0 link 0 [ 0.060339] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060344] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060348] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060353] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060380] Extended Config Space enabled on 2 nodes [ 0.060554] ACPI: bus type pci registered [ 0.060657] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060666] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.175327] Freeing initrd memory: 40072k freed [ 0.220228] PCI: Using configuration type 1 for base access [ 0.221784] bio: create slab at 0 [ 0.221784] ACPI: Added _OSI(Module Device) [ 0.221784] ACPI: Added _OSI(Processor Device) [ 0.221784] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221784] ACPI: Added _OSI(Processor Aggregator Device) [ 0.226175] ACPI: EC: Look up EC in DSDT [ 0.230647] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253676] ACPI: Interpreter enabled [ 0.253686] ACPI: (supports S0 S1 S4 S5) [ 0.253731] ACPI: Using IOAPIC for interrupt routing [ 0.267252] ACPI: No dock devices found. [ 0.267315] HEST: Table parsing has been initialized. [ 0.267323] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267657] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268216] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268223] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268230] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268236] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268242] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268283] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268477] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268684] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268800] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268809] pci 0000:00:09.0: PME# disabled [ 0.268851] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268998] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.269006] pci 0000:00:0a.0: PME# disabled [ 0.269066] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269103] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269123] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269143] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269163] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269183] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269203] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269312] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269339] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269463] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269490] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269625] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269662] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269820] pci 0000:00:12.2: supports D1 D2 [ 0.269825] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269835] pci 0000:00:12.2: PME# disabled [ 0.269874] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269901] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270024] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270052] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270188] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270225] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270416] pci 0000:00:13.2: supports D1 D2 [ 0.270421] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270431] pci 0000:00:13.2: PME# disabled [ 0.270476] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270666] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270810] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270891] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270918] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271060] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271188] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271250] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271317] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271407] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271520] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271637] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271700] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271798] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271891] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280057] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280071] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280080] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280205] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280240] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280285] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280309] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280490] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280501] pci 0000:02:00.0: PME# disabled [ 0.288056] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288069] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288078] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288145] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288184] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288207] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288229] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288438] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288452] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288463] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288469] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288475] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288482] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288489] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288495] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288542] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288960] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289033] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289146] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289355] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289363] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289369] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307491] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307629] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307762] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307900] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308018] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308121] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308256] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308427] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308499] xen/balloon: Initialising balloon driver. [ 0.351637] xen-balloon: Initialising balloon driver. [ 0.351668] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.351833] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.351833] vgaarb: loaded [ 0.351833] vgaarb: bridge control possible 0000:01:04.0 [ 0.351833] i2c-core: driver [aat2870] using legacy suspend method [ 0.351833] i2c-core: driver [aat2870] using legacy resume method [ 0.352090] SCSI subsystem initialized [ 0.352162] libata version 3.00 loaded. [ 0.352162] usbcore: registered new interface driver usbfs [ 0.352166] usbcore: registered new interface driver hub [ 0.352203] usbcore: registered new device driver usb [ 0.352203] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356116] NetLabel: Initializing [ 0.356120] NetLabel: domain hash size =3D 128 [ 0.356125] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356142] NetLabel: unlabeled traffic allowed by default [ 0.356221] Switching to clocksource xen [ 0.365440] AppArmor: AppArmor Filesystem Enabled [ 0.365478] pnp: PnP ACPI init [ 0.365499] ACPI: bus type pnp registered [ 0.365890] pnp 00:00: [bus 00-ff] [ 0.365895] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365901] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365906] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365911] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365916] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365922] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365927] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366052] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366323] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366330] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366407] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366585] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366646] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366654] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367333] pnp 00:03: [dma 4] [ 0.367337] pnp 00:03: [io 0x0000-0x000f] [ 0.367342] pnp 00:03: [io 0x0081-0x0083] [ 0.367347] pnp 00:03: [io 0x0087] [ 0.367351] pnp 00:03: [io 0x0089-0x008b] [ 0.367356] pnp 00:03: [io 0x008f] [ 0.367360] pnp 00:03: [io 0x00c0-0x00df] [ 0.367418] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367445] pnp 00:04: [io 0x0070-0x0071] [ 0.367452] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367462] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367467] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367485] pnp 00:04: [irq 8] [ 0.367541] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367612] pnp 00:05: [io 0x0060] [ 0.367617] pnp 00:05: [io 0x0064] [ 0.367621] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367627] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367632] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367645] pnp 00:05: [irq 1] [ 0.367700] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367814] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367820] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367825] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367842] pnp 00:06: [irq 12] [ 0.367901] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367922] pnp 00:07: [io 0x0061] [ 0.367979] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368001] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368006] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368011] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368016] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368029] pnp 00:08: [irq 13] [ 0.368059] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368059] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368059] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368059] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368394] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368402] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368494] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368555] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368856] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368862] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.368944] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.368951] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.368958] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369454] pnp 00:0c: [io 0x0010-0x001f] [ 0.369460] pnp 00:0c: [io 0x0022-0x003f] [ 0.369464] pnp 00:0c: [io 0x0062-0x0063] [ 0.369469] pnp 00:0c: [io 0x0065-0x006f] [ 0.369473] pnp 00:0c: [io 0x0072-0x007f] [ 0.369477] pnp 00:0c: [io 0x0080] [ 0.369482] pnp 00:0c: [io 0x0084-0x0086] [ 0.369486] pnp 00:0c: [io 0x0088] [ 0.369490] pnp 00:0c: [io 0x008c-0x008e] [ 0.369495] pnp 00:0c: [io 0x0090-0x009f] [ 0.369499] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369503] pnp 00:0c: [io 0x00b1] [ 0.369508] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369512] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369517] pnp 00:0c: [io 0x0550-0x0551] [ 0.369521] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369526] pnp 00:0c: [io 0x040b] [ 0.369530] pnp 00:0c: [io 0x04d6] [ 0.369534] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369538] pnp 00:0c: [io 0x0c14] [ 0.369542] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369547] pnp 00:0c: [io 0x0c52] [ 0.369551] pnp 00:0c: [io 0x0c6c] [ 0.369555] pnp 00:0c: [io 0x0c6f] [ 0.369559] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369564] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369568] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369573] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369577] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369581] pnp 00:0c: [io 0x0800-0x089f] [ 0.369586] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369591] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369596] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369600] pnp 00:0c: [io 0x0900-0x090f] [ 0.369605] pnp 00:0c: [io 0x0910-0x091f] [ 0.369609] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369614] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369619] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369624] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369631] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369775] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369781] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369787] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369793] system 00:0c: [io 0x040b] has been reserved [ 0.369798] system 00:0c: [io 0x04d6] has been reserved [ 0.369804] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369810] system 00:0c: [io 0x0c14] has been reserved [ 0.369815] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369821] system 00:0c: [io 0x0c52] has been reserved [ 0.369826] system 00:0c: [io 0x0c6c] has been reserved [ 0.369832] system 00:0c: [io 0x0c6f] has been reserved [ 0.369837] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369843] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369849] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369855] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369861] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369870] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369876] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369882] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369888] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369893] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369900] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369906] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369913] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369920] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370470] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370475] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370481] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370486] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370499] pnp 00:0d: [irq 4] [ 0.370503] pnp 00:0d: [dma 0 disabled] [ 0.370627] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371202] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371207] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371212] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371217] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371221] Already setup the GSI :3 [ 0.371226] pnp 00:0e: [irq 3] [ 0.371230] pnp 00:0e: [dma 0 disabled] [ 0.371350] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371492] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371574] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371582] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372549] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372555] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372560] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372565] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372573] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372673] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372679] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372686] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372692] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372698] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372706] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373005] pnp: PnP ACPI: found 17 devices [ 0.373009] ACPI: ACPI bus type pnp unregistered [ 0.380350] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380377] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380428] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380436] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380446] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380460] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380467] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380477] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380491] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380502] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380512] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380536] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380554] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380569] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380579] pci 0000:00:09.0: setting latency timer to 64 [ 0.380590] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380600] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380613] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380622] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380638] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380643] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380648] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380654] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380660] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380665] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380671] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380677] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380683] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380689] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380696] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380702] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380707] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380713] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380719] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380725] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380782] NET: Registered protocol family 2 [ 0.382871] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388135] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391365] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391707] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391714] TCP reno registered [ 0.391839] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392140] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392395] NET: Registered protocol family 1 [ 0.392455] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392478] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392499] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120169] pci 0000:00:12.0: PCI INT A disabled [ 1.120201] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120215] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120220] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120225] Already setup the GSI :16 [ 1.120232] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204174] pci 0000:00:12.1: PCI INT A disabled [ 1.204207] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204221] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204226] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204231] Already setup the GSI :17 [ 1.204237] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204371] pci 0000:00:12.2: PCI INT B disabled [ 1.204387] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204392] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204397] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204401] Already setup the GSI :18 [ 1.204406] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288185] pci 0000:00:13.0: PCI INT A disabled [ 1.288216] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288229] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288234] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288239] Already setup the GSI :18 [ 1.288245] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372178] pci 0000:00:13.1: PCI INT A disabled [ 1.372211] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372237] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372256] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372390] pci 0000:00:13.2: PCI INT B disabled [ 1.372416] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372422] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372426] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372431] Already setup the GSI :18 [ 1.372435] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456173] pci 0000:00:14.5: PCI INT C disabled [ 1.456259] pci 0000:01:04.0: Boot video device [ 1.456267] PCI: CLS 64 bytes, default 64 [ 1.457343] audit: initializing netlink socket (disabled) [ 1.457362] type=3D2000 audit(1336038821.847:1): initialized [ 1.485577] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487788] VFS: Disk quotas dquot_6.5.2 [ 1.487868] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488563] fuse init (API version 7.17) [ 1.488737] msgmni has been set to 1479 [ 1.489458] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489514] io scheduler noop registered [ 1.489519] io scheduler deadline registered [ 1.489561] io scheduler cfq registered (default) [ 1.490010] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490046] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490266] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490277] ACPI: Power Button [PWRB] [ 1.490337] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490345] ACPI: Power Button [PWRF] [ 1.688912] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.689037] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.689211] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.689634] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.693393] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.812124] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.832536] hpet_acpi_add: no address or irqs in _CRS [ 1.832555] Linux agpgart interface v0.103 [ 1.836328] brd: module loaded [ 1.837212] loop: module loaded [ 1.837590] ahci 0000:00:11.0: version 3.0 [ 1.837625] xen: registering gsi 22 triggering 0 polarity 1 [ 1.837648] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.837666] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.837891] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.837900] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.838864] scsi0 : ahci [ 1.838982] scsi1 : ahci [ 1.839077] scsi2 : ahci [ 1.839173] scsi3 : ahci [ 1.839275] scsi4 : ahci [ 1.839371] scsi5 : ahci [ 1.840311] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.840319] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.840327] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.840334] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.840341] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.840348] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.840881] Fixed MDIO Bus: probed [ 1.840909] tun: Universal TUN/TAP device driver, 1.6 [ 1.840918] tun: (C) 1999-2004 Max Krasnyansky [ 1.840983] PPP generic driver version 2.4.2 [ 1.841100] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.841193] xen: registering gsi 17 triggering 0 polarity 1 [ 1.841202] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.841207] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.841212] Already setup the GSI :17 [ 1.841218] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.841252] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.841336] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.841353] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.841452] ehci_hcd 0000:00:12.2: debug port 1 [ 1.841502] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.852094] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.852291] hub 1-0:1.0: USB hub found [ 1.852299] hub 1-0:1.0: 6 ports detected [ 1.852485] xen: registering gsi 19 triggering 0 polarity 1 [ 1.852493] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.852498] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.852503] Already setup the GSI :19 [ 1.852508] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.852542] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.852618] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.852633] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.852708] ehci_hcd 0000:00:13.2: debug port 1 [ 1.852763] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.864098] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.864308] hub 2-0:1.0: USB hub found [ 1.864316] hub 2-0:1.0: 6 ports detected [ 1.864439] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.864560] xen: registering gsi 16 triggering 0 polarity 1 [ 1.864569] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.864574] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.864578] Already setup the GSI :16 [ 1.864584] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.864618] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.864685] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.864754] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.924286] hub 3-0:1.0: USB hub found [ 1.924301] hub 3-0:1.0: 3 ports detected [ 1.924456] xen: registering gsi 16 triggering 0 polarity 1 [ 1.924464] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.924468] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.924473] Already setup the GSI :16 [ 1.924478] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.924513] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.924582] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.924626] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.984287] hub 4-0:1.0: USB hub found [ 1.984301] hub 4-0:1.0: 3 ports detected [ 1.984451] xen: registering gsi 18 triggering 0 polarity 1 [ 1.984458] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.984463] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.984468] Already setup the GSI :18 [ 1.984473] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.984508] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.984579] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.984646] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.044274] hub 5-0:1.0: USB hub found [ 2.044288] hub 5-0:1.0: 3 ports detected [ 2.044439] xen: registering gsi 18 triggering 0 polarity 1 [ 2.044447] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.044452] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.044456] Already setup the GSI :18 [ 2.044462] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.044496] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.044569] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.044609] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.104298] hub 6-0:1.0: USB hub found [ 2.104314] hub 6-0:1.0: 3 ports detected [ 2.104504] xen: registering gsi 18 triggering 0 polarity 1 [ 2.104512] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.104517] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.104522] Already setup the GSI :18 [ 2.104527] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.104561] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.104633] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.104684] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.160242] ata5: SATA link down (SStatus 0 SControl 300) [ 2.164415] hub 7-0:1.0: USB hub found [ 2.164430] hub 7-0:1.0: 2 ports detected [ 2.164530] uhci_hcd: USB Universal Host Controller Interface driver [ 2.164625] usbcore: registered new interface driver libusual [ 2.164682] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.167602] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.167614] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.167777] mousedev: PS/2 mouse device common for all mice [ 2.167985] rtc_cmos 00:04: RTC can wake from S4 [ 2.168223] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.168275] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.168379] device-mapper: uevent: version 1.0.3 [ 2.168474] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.168487] EFI Variables Facility v0.08 2004-May-17 [ 2.168807] TCP cubic registered [ 2.168939] NET: Registered protocol family 10 [ 2.169670] NET: Registered protocol family 17 [ 2.169694] Registering the dns_resolver key type [ 2.169917] PM: Hibernation image not present or could not be loaded. [ 2.169934] registered taskstats version 1 [ 2.176089] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.187946] Magic number: 12:509:878 [ 2.188144] rtc_cmos 00:04: setting system clock to 2012-05-03 09:53:4= 2 UTC (1336038822) [ 2.188276] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.188374] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.188379] EDD information not available. [ 2.200605] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.314893] Initializing USB Mass Storage driver... [ 2.315113] scsi6 : usb-storage 2-2:1.0 [ 2.315224] usbcore: registered new interface driver usb-storage [ 2.315230] USB Mass Storage support registered. [ 2.332119] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.332156] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332191] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332222] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332246] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332694] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.333246] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333255] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333273] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333281] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333299] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333309] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333413] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333420] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333543] ata6.00: configured for UDMA/100 [ 2.334451] ata1.00: configured for UDMA/133 [ 2.334636] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.334792] ata4.00: configured for UDMA/133 [ 2.334824] ata3.00: configured for UDMA/133 [ 2.334866] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.334915] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.334938] ata2.00: configured for UDMA/133 [ 2.335015] sd 0:0:0:0: [sda] Write Protect is off [ 2.335024] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.335061] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.335194] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.335396] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.335416] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.335501] sd 1:0:0:0: [sdb] Write Protect is off [ 2.335509] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.335557] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.335702] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.335883] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.335917] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.335981] sd 2:0:0:0: [sdc] Write Protect is off [ 2.335987] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.336106] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.336258] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.336265] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.336355] sd 3:0:0:0: [sdd] Write Protect is off [ 2.336362] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.336367] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.336408] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.337308] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.340918] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.340927] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.341087] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.341196] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.341647] sdb: sdb1 sdb2 [ 2.342067] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.347291] sdd: unknown partition table [ 2.347568] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.350641] sdc: unknown partition table [ 2.350926] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.455361] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.457499] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.458052] Freeing unused kernel memory: 920k freed [ 2.458379] Write protecting the kernel read-only data: 12288k [ 2.465974] Freeing unused kernel memory: 1520k freed [ 2.467147] Freeing unused kernel memory: 1140k freed [ 2.532778] udevd[166]: starting version 175 [ 2.586556] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.586566] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.586899] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.586929] xen: registering gsi 17 triggering 0 polarity 1 [ 2.586979] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.586985] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.586991] Already setup the GSI :17 [ 2.586997] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.587033] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.684119] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.711875] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.711884] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.711969] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.712119] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.712148] xen: registering gsi 18 triggering 0 polarity 1 [ 2.712159] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.712164] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.712170] Already setup the GSI :18 [ 2.712176] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.712208] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.826232] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.826241] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.826326] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.862464] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.862705] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.866427] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.866568] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.866595] usbcore: registered new interface driver usbhid [ 2.866601] usbhid: USB HID core driver [ 3.313116] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.313858] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.314481] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.315095] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.315995] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.316209] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.316399] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.316566] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.321554] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.325956] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.327301] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 3.328099] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 8.680452] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.378393] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.378413] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.406855] udevd[718]: starting version 175 [ 15.516929] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.541315] lp: driver loaded but no devices found [ 15.543010] Bridge firewalling registered [ 15.543528] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.545436] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.545583] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.548417] device-mapper: multipath: version 1.3.0 loaded [ 15.554115] ipmi message handler version 39.2 [ 15.554771] device eth0 entered promiscuous mode [ 15.554947] ipmi device interface [ 15.561242] IPMI System Interface driver. [ 15.561305] ipmi_si: probing via SMBIOS [ 15.561309] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.561313] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.561321] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.565782] MCE: In-kernel MCE decoding enabled. [ 15.567534] EDAC MC: Ver: 2.1.0 [ 15.568886] AMD64 EDAC driver v3.4.0 [ 15.569069] EDAC amd64: DRAM ECC enabled. [ 15.569102] EDAC amd64: F10h detected (node 0). [ 15.569180] EDAC MC: DCT0 chip selects: [ 15.569187] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.569190] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.569197] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.569203] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.569206] EDAC MC: DCT1 chip selects: [ 15.569209] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.569212] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.569215] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.569218] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.569221] EDAC amd64: using x8 syndromes. [ 15.569224] EDAC amd64: MCT channel count: 2 [ 15.569278] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.569285] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.569288] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.569291] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.569422] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.571018] EDAC amd64: DRAM ECC enabled. [ 15.571030] EDAC amd64: F10h detected (node 1). [ 15.571107] EDAC MC: DCT0 chip selects: [ 15.571111] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.571114] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.571117] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.571120] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.571123] EDAC MC: DCT1 chip selects: [ 15.571126] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.571129] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.571132] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.571135] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.571138] EDAC amd64: using x8 syndromes. [ 15.571141] EDAC amd64: MCT channel count: 2 [ 15.571176] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.571179] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.571183] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.571186] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.571257] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.571424] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.606210] type=3D1400 audit(1336038835.913:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D818 comm=3D"appar= mor_parser" [ 15.606825] type=3D1400 audit(1336038835.913:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D818 comm=3D"apparmor_parser" [ 15.607175] type=3D1400 audit(1336038835.913:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D818 comm=3D"apparmor_parser" [ 15.643062] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.655321] ADDRCONF(NETDEV_UP): br0: link is not ready [ 15.672109] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.712684] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.713196] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 15.852353] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 15.919391] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.672650] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.200817] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 18.745090] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 18.747436] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.747574] br0: port 1(eth0) entering forwarding state [ 18.747591] br0: port 1(eth0) entering forwarding state [ 18.749725] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 21.937790] init: udev-fallback-graphics main process (1840) terminate= d with status 1 [ 22.085550] init: failsafe main process (1723) killed by TERM signal [ 22.198011] type=3D1400 audit(1336038842.505:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1936 comm=3D"apparmor_parser" [ 22.198271] type=3D1400 audit(1336038842.505:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1934 comm=3D"a= pparmor_parser" [ 22.198526] type=3D1400 audit(1336038842.505:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1937 comm=3D"= apparmor_parser" [ 22.198897] type=3D1400 audit(1336038842.505:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1934 comm=3D"apparmor_parser" [ 22.199271] type=3D1400 audit(1336038842.505:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1934 comm=3D"apparmor_parser" [ 22.199376] type=3D1400 audit(1336038842.505:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1938 c= omm=3D"apparmor_parser" [ 22.199727] type=3D1400 audit(1336038842.505:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1938 comm=3D"apparmor_parser" [ 22.200161] type=3D1400 audit(1336038842.509:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1940 comm=3D"= apparmor_parser" [ 22.477708] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 22.722258] ip_tables: (C) 2000-2006 Netfilter Core Team [ 22.823823] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 22.877126] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 23.122997] Event-channel device installed. [ 23.185712] XENBUS: Unable to read cpu state [ 23.185922] XENBUS: Unable to read cpu state [ 23.186113] XENBUS: Unable to read cpu state [ 23.186295] XENBUS: Unable to read cpu state [ 23.186508] XENBUS: Unable to read cpu state [ 23.186669] XENBUS: Unable to read cpu state [ 23.186807] XENBUS: Unable to read cpu state [ 23.186979] XENBUS: Unable to read cpu state [ 23.944659] Ebtables v2.0 registered [ 23.976417] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.644090] br0: no IPv6 routers present [ 205.760461] xen-acpi-processor: Max ACPI ID: 16 [ 205.760479]=20 [ 205.760480] **** Context Switch from TID 0 to TID 42768112 **** [ 205.760481]=20 [ 205.760485] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.760495] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.760504] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.760514] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.760522] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.760530] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.760540] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.760548] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.760557] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.760567] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.760577] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.760595] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.760604] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.760613] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.760622] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P001] (ffff880027d50e88) [ 205.760631] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.760640] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.760656] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.760664] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.760672] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50e88 [ 205.760682] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.760690] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P001 (ffff880027d50e88) For [_PSD] (Untyped) [ 205.760701] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.760708] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.760717] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d438 found in scope [P001] ffff880027d50e88= [ 205.760727] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.760736] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.760744] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.760752] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.760762] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.760772] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.760780] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.760788] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.760797] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d438 [ 205.760806] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d709d8 [ 205.760814] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d438] Value ffff880027d709d8 [ 205.760824] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.760832] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.760841] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.760849] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.760859] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.760868] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.760885] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.760894] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.760902] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d438 [ 205.760912] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d709d8 [ 205.760920] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.760928] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.760937] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d438 SourceDesc=3Dffff880027d709d8 [Package] [ 205.760947] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d709d8 [ 205.760955] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.760964] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d709d8 [ 205.760973] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d709d8 Current Refs=3D1 [To Be Incremented] [ 205.760982] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d709d8 [ 205.760991] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cdf30 [ 205.761001] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.761009] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761017] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761025] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d709d8 Refs=3D2, [Incremented] [ 205.761034] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761042] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761050] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761058] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761067] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cdf78 [ 205.761075] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.761083] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761091] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761099] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff880027d716c0 [ 205.761107] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.761115] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761123] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761131] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff880027d71a68 [ 205.761139] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.761148] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761155] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761163] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250ce000 [ 205.761171] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.761180] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761187] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761195] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250ce048 [ 205.761204] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.761212] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761220] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761228] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cdf30 Refs=3D2, [Incremented] [ 205.761236] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761244] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.761252] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761260] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761268] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250ce048 Refs=3D2, [Incremented] [ 205.761276] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761284] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.761293] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761300] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761308] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250ce000 Refs=3D2, [Incremented] [ 205.761317] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761324] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.761333] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761341] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761349] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d71a68 Refs=3D2, [Incremented] [ 205.761358] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761365] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.761373] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761381] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761389] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d716c0 Refs=3D2, [Incremented] [ 205.761398] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761405] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761414] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761421] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761429] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cdf78 Refs=3D2, [Incremented] [ 205.761438] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.761446] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.761454] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.761462] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.761470] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.761479] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.761488] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.761495] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d709d8 [Package] [ 205.761506] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d438 [ 205.761514] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.761524] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P001._PSD Validating return Package of Type 5, Count 1 [ 205.761535] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.761544] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.761552] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d709d8 [ 205.761561] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.761569] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 205.761577] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.761586] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.761593] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.761601] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250cdf30 [ 205.761609] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.761618] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cdf78 [ 205.761626] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761634] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff880027d716c0 [ 205.761642] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761650] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff880027d71a68 [ 205.761658] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761666] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250ce000 [ 205.761674] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761682] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250ce048 [ 205.761691] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761699] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.761706] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.761714] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.761722] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761730] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.761738] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.761745] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.761753] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.761762] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.761770] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.761779] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.761787] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.761795] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.761803] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 205.761811] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.761819] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.761827] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.761835] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250cdf30 [ 205.761843] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.761851] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761859] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761867] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761875] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761883] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761891] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761899] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761907] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761914] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761922] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761930] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.761938] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.761946] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.761953] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761962] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.761969] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.761977] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.761985] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.761993] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.762001] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.762010] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.762018] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.762026] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.762035] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.762044] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.762061] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.762069] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d709d8 [ 205.762077] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d709d8 Current Refs=3D2 [To Be Decremented] [ 205.762087] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d709d8 [ 205.762095] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cdf30 [ 205.762103] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.762112] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762119] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762127] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d709d8 Refs=3D1, [Decremented] [ 205.762136] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762144] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.762152] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762159] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762167] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cdf78 [ 205.762175] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.762184] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762192] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762199] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff880027d716c0 [ 205.762208] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.762216] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762223] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762231] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff880027d71a68 [ 205.762239] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.762248] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762255] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762263] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250ce000 [ 205.762271] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.762279] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762287] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762295] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250ce048 [ 205.762303] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.762311] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762319] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762327] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cdf30 Refs=3D1, [Decremented] [ 205.762336] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762343] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.762352] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762359] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762367] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250ce048 Refs=3D1, [Decremented] [ 205.762376] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762383] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.762391] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762399] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762407] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250ce000 Refs=3D1, [Decremented] [ 205.762416] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762423] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.762431] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762439] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762447] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d71a68 Refs=3D1, [Decremented] [ 205.762455] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762463] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.762471] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762479] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762487] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d716c0 Refs=3D1, [Decremented] [ 205.762495] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762503] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.762511] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762519] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762527] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cdf78 Refs=3D1, [Decremented] [ 205.762535] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.762554] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.762562] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.762570] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.762579] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.762588] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.762596] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.762605] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.762613] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.762621] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.762630] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.762637] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.762645] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.762654] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.762662] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.762670] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.762679] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.762688] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.762705] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.762713] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.762721] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.762729] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P002] (ffff880027d50eb0) [ 205.762738] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.762746] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.762760] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.762768] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.762776] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50eb0 [ 205.762784] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.762792] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P002 (ffff880027d50eb0) For [_PSD] (Untyped) [ 205.762802] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.762810] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.762818] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d500 found in scope [P002] ffff880027d50eb0= [ 205.762828] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.762836] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.762844] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.762852] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.762861] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.762870] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.762878] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.762886] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.762894] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d500 [ 205.762903] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70b40 [ 205.762911] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d500] Value ffff880027d70b40 [ 205.762920] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.762928] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.762936] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.762944] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.762953] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.762962] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.762979] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.762987] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.762995] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d500 [ 205.763003] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70b40 [ 205.763012] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.763019] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.763028] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d500 SourceDesc=3Dffff880027d70b40 [Package] [ 205.763037] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70b40 [ 205.763045] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.763053] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70b40 [ 205.763061] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70b40 Current Refs=3D1 [To Be Incremented] [ 205.763070] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70b40 [ 205.763078] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfd38 [ 205.763086] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.763095] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763102] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763110] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70b40 Refs=3D2, [Incremented] [ 205.763119] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763126] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763134] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763142] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763150] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfd80 [ 205.763158] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.763167] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763174] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763182] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfdc8 [ 205.763190] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.763199] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763206] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763214] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfe10 [ 205.763222] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.763230] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763238] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763246] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfe58 [ 205.763254] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.763262] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763270] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763278] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfea0 [ 205.763286] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.763294] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763302] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763310] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfd38 Refs=3D2, [Incremented] [ 205.763318] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763326] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.763334] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763342] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763350] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfea0 Refs=3D2, [Incremented] [ 205.763358] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763366] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.763375] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763382] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763390] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfe58 Refs=3D2, [Incremented] [ 205.763399] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763406] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.763415] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763422] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763430] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfe10 Refs=3D2, [Incremented] [ 205.763439] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763446] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.763455] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763462] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763470] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfdc8 Refs=3D2, [Incremented] [ 205.763479] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763487] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763495] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763503] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763510] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfd80 Refs=3D2, [Incremented] [ 205.763519] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.763527] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.763535] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.763543] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.763551] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.763560] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.763568] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.763576] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70b40 [Package] [ 205.763586] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d500 [ 205.763594] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.763603] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P002._PSD Validating return Package of Type 5, Count 1 [ 205.763612] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.763620] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.763629] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70b40 [ 205.763637] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.763645] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 205.763653] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.763661] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.763669] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.763677] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250cfd38 [ 205.763685] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.763693] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfd80 [ 205.763701] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763709] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfdc8 [ 205.763718] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763726] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfe10 [ 205.763734] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763742] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfe58 [ 205.763750] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763758] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfea0 [ 205.763766] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763774] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.763782] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.763789] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.763797] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763805] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.763813] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.763821] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.763828] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.763837] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.763845] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.763853] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.763861] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.763869] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.763877] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 205.763885] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.763893] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.763901] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.763909] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250cfd38 [ 205.763917] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.763925] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763933] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763941] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763949] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763957] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763964] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763972] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763980] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763988] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763996] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764004] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764012] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764019] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764027] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764035] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764043] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764056] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70b40 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70b40 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70b40 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfd38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70b40 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfd80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfdc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfe10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfe58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfd38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfe58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfe10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfdc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfd80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P003] (ffff880027d50ed8) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50ed8 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P003 (ffff880027d50ed8) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d5c8 found in scope [P003] ffff880027d50ed8= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d5c8 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70ca8 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d5c8] Value ffff880027d70ca8 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d5c8 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70ca8 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d5c8 SourceDesc=3Dffff880027d70ca8 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70ca8 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70ca8 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70ca8 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70ca8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70ca8 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d5c8 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P003._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70ca8 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70ca8 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70ca8 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70ca8 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70ca8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P004] (ffff880027d50f00) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f00 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P004 (ffff880027d50f00) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d690 found in scope [P004] ffff880027d50f00= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d690 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70e10 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d690] Value ffff880027d70e10 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d690 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70e10 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d690 SourceDesc=3Dffff880027d70e10 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70e10 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70e10 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70e10 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70e10 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70e10 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d690 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P004._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70e10 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70e10 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70e10 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70e10 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P005] (ffff880027d50f28) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f28 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P005 (ffff880027d50f28) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d758 found in scope [P005] ffff880027d50f28= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d758 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70f78 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d758] Value ffff880027d70f78 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d758 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70f78 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d758 SourceDesc=3Dffff880027d70f78 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70f78 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70f78 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70f78 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70f78 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70f78 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70f78 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d758 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P005._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70f78 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70f78 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70f78 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70f78 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70f78 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P006] (ffff880027d50f50) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f50 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P006 (ffff880027d50f50) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d820 found in scope [P006] ffff880027d50f50= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d820 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d710d8 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d820] Value ffff880027d710d8 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d820 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d710d8 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d820 SourceDesc=3Dffff880027d710d8 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d710d8 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d710d8 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d710d8 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d710d8 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d710d8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d710d8 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d820 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P006._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d710d8 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d710d8 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d710d8 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d710d8 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d710d8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P007] (ffff880027d50f78) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f78 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P007 (ffff880027d50f78) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d8e8 found in scope [P007] ffff880027d50f78= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d8e8 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d71288 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d8e8] Value ffff880027d71288 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d8e8 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d71288 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.772639] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.772647] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d8e8 SourceDesc=3Dffff880027d71288 [Package] [ 205.772657] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d71288 [ 205.772665] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.772673] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d71288 [ 205.772682] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d71288 Current Refs=3D1 [To Be Incremented] [ 205.772692] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d71288 [ 205.772712] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 205.772731] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.772752] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.772770] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.772790] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d71288 Refs=3D2, [Incremented] [ 205.772811] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.772828] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.772846] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.772863] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.772881] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 205.772901] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.772919] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.772937] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.772956] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 205.772973] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.772990] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773007] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773027] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 205.773044] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.773064] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773083] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773103] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 205.773122] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.773144] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773160] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773176] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 205.773195] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.773212] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773230] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773245] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9d38 Refs=3D2, [Incremented] [ 205.773269] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773287] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.773305] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773321] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773339] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9ea0 Refs=3D2, [Incremented] [ 205.773359] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773378] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.773394] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773413] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773430] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9e58 Refs=3D2, [Incremented] [ 205.773448] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773465] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.773486] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773503] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773517] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9e10 Refs=3D2, [Incremented] [ 205.773539] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773558] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.773575] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773592] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773610] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9dc8 Refs=3D2, [Incremented] [ 205.773629] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773647] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.773665] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773681] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773697] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9d80 Refs=3D2, [Incremented] [ 205.773705] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.773713] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.773721] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.773730] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.773738] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.773747] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.773757] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.773765] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d71288 [Package] [ 205.773775] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d8e8 [ 205.773783] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.773792] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P007._PSD Validating return Package of Type 5, Count 1 [ 205.773802] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.773811] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.773819] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d71288 [ 205.773828] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.773836] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 205.773845] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.773853] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.773861] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.773869] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 205.773878] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.773886] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9d80 [ 205.773895] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773904] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9dc8 [ 205.773912] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773921] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e10 [ 205.773935] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773958] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e58 [ 205.773982] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.774004] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9ea0 [ 205.774028] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.774051] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.774076] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.774093] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774113] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.774130] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.774148] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.774164] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774183] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.774201] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.774215] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.774236] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.774253] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.774272] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.774289] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 205.774310] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.774327] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.774342] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.774363] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 205.774382] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.774399] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774418] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774435] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774453] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774470] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774486] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774505] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774524] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774538] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774559] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774579] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.774598] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.774614] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.774629] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.774647] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.774665] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.774683] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.774703] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.774720] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.774740] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.774757] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.774776] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.774792] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.774812] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.774831] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.774870] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.774889] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d71288 [ 205.774907] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d71288 Current Refs=3D2 [To Be Decremented] [ 205.774928] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d71288 [ 205.774944] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 205.774953] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.774961] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.774969] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.774977] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d71288 Refs=3D1, [Decremented] [ 205.774987] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774994] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.775003] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775011] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775019] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 205.775028] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.775036] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775044] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775052] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 205.775061] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.775069] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775077] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775085] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 205.775094] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.775110] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775127] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775145] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 205.775165] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.775186] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775205] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775221] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 205.775236] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.775253] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775269] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775284] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d38 Refs=3D1, [Decremented] [ 205.775309] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775328] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.775345] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775365] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775381] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9ea0 Refs=3D1, [Decremented] [ 205.775400] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775416] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.775434] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775455] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775475] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e58 Refs=3D1, [Decremented] [ 205.775494] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775512] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.775528] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775548] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775566] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e10 Refs=3D1, [Decremented] [ 205.775587] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775603] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.775620] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775638] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775655] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9dc8 Refs=3D1, [Decremented] [ 205.775674] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775691] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.775709] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775728] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775744] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d80 Refs=3D1, [Decremented] [ 205.775764] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.775784] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.775805] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.775824] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.775841] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.775861] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.775881] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.775900] xen-acpi-processor: register_performance(0) =3D -19 --------------060305080106050804080206-- --------------enig44CE6C0905155E36B06E265B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoldaAAoJEOhnXe7L7s6jjBAQAKFCK1qzxw0UjU51NEfoD5g1 f5bXe9KdgtRUqDIUs/dEVv0jBH4595SOn8ghksziBeKiIV2lh4ocZVtfP3U6pJdt +fq7Wxtp2yhcmSFXHHXmLIHkcI+WwMcZMSYKliruybBM+oYRGiq7/BxanaGwBK7A j2n/+7M28b3pjjI2X/Yi97ArSPN15HseasuglUZL03bbUV0KG/MdZsxZHRNp1tor sHeIS9PfscZfTobxLnPrY54x7HQSUvpIoU9eiZVRwQv318jQWNhyzf0kZcQiFwoG 3HHoJ/KASTIplmiR9bkCDJon0p/8dry/8XPZQdRB4MrwVfEeOFQ6qPiYWROgbonj 6vZPfDpa62mhdYIfcRf4ebcJuYpAIblzVdRuRpkBotYVcJ+lTAOWem7bEcKBuXcl e2d2/uA/pQveBuMQAapECG7e8LUaLrffJfx5jrpow++RtoSgiFKKpEUSqU7Hc6fk rBoVzaCII3M9Psn1cZLiLMUHRRubgjf54HpSLP2i8NUxPJ0lraemUnk6lrhYQLmI etH2rtedVDws5hSmT9AoEag8zStceyzpxB8+P4gAP5+cdIIXzA1bZA51QakLaz6Y Uc1F6Q0yEcEUxEdnR2BLZk2rJE+CBCTSEaDcceNIF9ruDVPXoluy04We5gmiNRVY N2q8M50EaMTVgEONU+YH =UqC/ -----END PGP SIGNATURE----- --------------enig44CE6C0905155E36B06E265B-- --===============4024771420858992763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4024771420858992763==-- From xen-devel-bounces@lists.xen.org Thu May 03 10:01:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:01:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsqc-0001VJ-3h; Thu, 03 May 2012 10:01:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPsqY-0001VE-Uk for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:01:15 +0000 Received: from [85.158.143.35:9429] by server-1.bemta-4.messagelabs.com id 42/1E-20925-A6752AF4; Thu, 03 May 2012 10:01:14 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336039263!14560293!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4994 invoked from network); 3 May 2012 10:01:04 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-13.tower-21.messagelabs.com with SMTP; 3 May 2012 10:01:04 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPsqK-0005l8-Ec; Thu, 03 May 2012 10:01:02 +0000 Message-ID: <4FA25752.8010807@canonical.com> Date: Thu, 03 May 2012 12:00:50 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA22BF8.2050409@canonical.com> In-Reply-To: <4FA22BF8.2050409@canonical.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4024771420858992763==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4024771420858992763== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig44CE6C0905155E36B06E265B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44CE6C0905155E36B06E265B Content-Type: multipart/mixed; boundary="------------060305080106050804080206" This is a multi-part message in MIME format. --------------060305080106050804080206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 08:55, Stefan Bader wrote: > On 03.05.2012 00:09, Boris Ostrovsky wrote: >> On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>>> index a8f8844..d816448 100644 >>>>>>> --- a/arch/x86/xen/enlighten.c >>>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>>> static u32 xen_apic_read(u32 reg) >>>>>>> { >>>>>>> - return 0; >>>>>>> + struct xen_platform_op op =3D { >>>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>>> >>>>>> >>>>>> Is this always zero? This will probably solve the current problem >>>>> >>>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>>> >>>> Why not use CPU number instead of zero here? >>> >>> The issue was only with the bootup CPU - so was using the Xen's >>> bootup CPU number - which is zero (as is Linux's). >> >> I agree that for this particular problem this may be sufficient. >> >> My concern is that in the future someone may decide to use apic_read(A= PIC_ID) or >> read_apic_id() for some other purpose and they won't get expected resu= lt (i.e. >> on all CPUs they will get the same answer). >> >>> >>>> >>>>> >>>>>> but I am wondering whether in the future we might hit another bug >>>>>> because this routine will return the same APICID for all VCPUs. >>>>> >>>>> Later on it does a check for 'smp_processor_id()' - and if >>>>> that is anything but zero it will bail out. >>>> >>>> Can you point me to the check you are referring to? >>> >>> if (!xen_initial_domain() || smp_processor_id()) >> >> I don't see this line --- neither in the mainline nor in your kernel. = Which >> kernel and which routine is this in? >=20 > This is in the inline patch Konrad asked me to check. >> >> BTW, this patch doesn't quite work, xen-acpi-processor driver fails to= load with >> the same error as before. I'll look at this tomorrow more carefully. >=20 > It does fail but at least for me it seems slightly different. I do the = modprobe > after turning on all acpi debugging levels and layers. And without any = change > there are queries visible. With that patch the driver just fails but th= ere are > no queries. I plan to have another go with messages sprinkled to all ex= it paths > today, too (was just a bit too late and two pints later yesterday). Gah! Once you do it right... It *does* fail the exactly same way and ther= e are some acpi debug messages... >=20 >=20 > -Stefan >> >> >> -boris >> >>> >>> >>>> >>>> -boris >>>> >>>> >>>>> >>>>> So this shoudl solve the problem for the bootup processor. >>>>>> >>>>>> -boris >>>>>> >>>>>> >>>>>>> + }; >>>>>>> + int ret =3D 0; >>>>>>> + >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we = only >>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>> + return 0; >>>>>>> + >>>>>>> + if (reg =3D=3D APIC_LVR) >>>>>>> + return 0x10; >>>>>>> + >>>>>>> + if (reg !=3D APIC_ID) >>>>>>> + return 0; >>>>>>> + >>>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>>> + if (ret) >>>>>>> + return 0; >>>>>>> + >>>>>>> + return op.u.pcpu_info.apic_id; >>>>>>> } >>>>>>> >>>>>>> static void xen_apic_write(u32 reg, u32 val) >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >>> >> >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------060305080106050804080206 Content-Type: text/plain; charset=UTF-8; name="dmesg.xen.4" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.xen.4" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg4 SMP Thu May 3 09:28:4= 7 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg4-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10 earlyp= rintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug console=3Dhvc0 loglevel=3D10= earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.196 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.39 BogoMIPS (lpj=3D8000784) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.007694] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.016580] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019111] Mount-cache hash table entries: 256 [ 0.019360] Initializing cgroup subsys cpuacct [ 0.019372] Initializing cgroup subsys memory [ 0.019391] Initializing cgroup subsys devices [ 0.019397] Initializing cgroup subsys freezer [ 0.019402] Initializing cgroup subsys blkio [ 0.019419] Initializing cgroup subsys perf_event [ 0.019493] tseg: 00dff00000 [ 0.019500] CPU: Physical Processor ID: 0 [ 0.019504] CPU: Processor Core ID: 0 [ 0.022409] ACPI: Core revision 20110623 [ 0.038591] ftrace: allocating 27102 entries in 107 pages [ 0.040131] cpu 0 spinlock event irq 273 [ 0.040232] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040494] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040624] installing Xen timer for CPU 1 [ 0.040642] cpu 1 spinlock event irq 279 [ 0.040844] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040967] installing Xen timer for CPU 2 [ 0.040986] cpu 2 spinlock event irq 285 [ 0.041142] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041258] installing Xen timer for CPU 3 [ 0.041273] cpu 3 spinlock event irq 291 [ 0.041435] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041552] installing Xen timer for CPU 4 [ 0.041568] cpu 4 spinlock event irq 297 [ 0.041752] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041878] installing Xen timer for CPU 5 [ 0.041894] cpu 5 spinlock event irq 303 [ 0.042056] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042171] installing Xen timer for CPU 6 [ 0.042188] cpu 6 spinlock event irq 309 [ 0.042343] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042459] installing Xen timer for CPU 7 [ 0.042474] cpu 7 spinlock event irq 315 [ 0.042633] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042665] Brought up 8 CPUs [ 0.042894] devtmpfs: initialized [ 0.045534] EVM: security.selinux [ 0.045539] EVM: security.SMACK64 [ 0.045543] EVM: security.capability [ 0.045619] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045619] Grant table initialized [ 0.045619] print_constraints: dummy:=20 [ 0.045619] RTC time: 9:53:40, date: 05/03/12 [ 0.045619] NET: Registered protocol family 16 [ 0.045619] Trying to unpack rootfs image as initramfs... [ 0.060271] node 0 link 0: io port [1000, ffffff] [ 0.060287] TOM: 00000000e0000000 aka 3584M [ 0.060294] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060304] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060313] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060321] node 0 link 0: mmio [a0000, bffff] [ 0.060329] TOM2: 0000000820000000 aka 33280M [ 0.060334] bus: [00, 1f] on node 0 link 0 [ 0.060339] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060344] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060348] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060353] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060380] Extended Config Space enabled on 2 nodes [ 0.060554] ACPI: bus type pci registered [ 0.060657] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060666] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.175327] Freeing initrd memory: 40072k freed [ 0.220228] PCI: Using configuration type 1 for base access [ 0.221784] bio: create slab at 0 [ 0.221784] ACPI: Added _OSI(Module Device) [ 0.221784] ACPI: Added _OSI(Processor Device) [ 0.221784] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221784] ACPI: Added _OSI(Processor Aggregator Device) [ 0.226175] ACPI: EC: Look up EC in DSDT [ 0.230647] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253676] ACPI: Interpreter enabled [ 0.253686] ACPI: (supports S0 S1 S4 S5) [ 0.253731] ACPI: Using IOAPIC for interrupt routing [ 0.267252] ACPI: No dock devices found. [ 0.267315] HEST: Table parsing has been initialized. [ 0.267323] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267657] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268216] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268223] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268230] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268236] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268242] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268283] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268477] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268684] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268800] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268809] pci 0000:00:09.0: PME# disabled [ 0.268851] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.268998] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.269006] pci 0000:00:0a.0: PME# disabled [ 0.269066] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269103] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269123] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269143] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269163] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269183] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269203] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269312] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269339] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269463] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269490] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269625] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269662] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269820] pci 0000:00:12.2: supports D1 D2 [ 0.269825] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269835] pci 0000:00:12.2: PME# disabled [ 0.269874] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269901] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270024] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270052] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270188] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270225] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270416] pci 0000:00:13.2: supports D1 D2 [ 0.270421] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270431] pci 0000:00:13.2: PME# disabled [ 0.270476] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270666] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270810] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270891] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270918] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271060] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271188] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271250] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271317] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271407] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271520] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271637] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271700] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271798] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271891] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280057] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280071] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280080] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280205] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280240] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280285] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280309] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280490] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280501] pci 0000:02:00.0: PME# disabled [ 0.288056] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288069] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288078] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288145] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288184] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288207] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288229] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288438] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288452] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288463] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288469] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288475] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288482] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288489] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288495] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288542] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288960] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289033] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289146] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289355] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289363] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289369] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307491] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307629] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307762] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.307900] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308018] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308121] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308256] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308427] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308499] xen/balloon: Initialising balloon driver. [ 0.351637] xen-balloon: Initialising balloon driver. [ 0.351668] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.351833] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.351833] vgaarb: loaded [ 0.351833] vgaarb: bridge control possible 0000:01:04.0 [ 0.351833] i2c-core: driver [aat2870] using legacy suspend method [ 0.351833] i2c-core: driver [aat2870] using legacy resume method [ 0.352090] SCSI subsystem initialized [ 0.352162] libata version 3.00 loaded. [ 0.352162] usbcore: registered new interface driver usbfs [ 0.352166] usbcore: registered new interface driver hub [ 0.352203] usbcore: registered new device driver usb [ 0.352203] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356116] NetLabel: Initializing [ 0.356120] NetLabel: domain hash size =3D 128 [ 0.356125] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356142] NetLabel: unlabeled traffic allowed by default [ 0.356221] Switching to clocksource xen [ 0.365440] AppArmor: AppArmor Filesystem Enabled [ 0.365478] pnp: PnP ACPI init [ 0.365499] ACPI: bus type pnp registered [ 0.365890] pnp 00:00: [bus 00-ff] [ 0.365895] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365901] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365906] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365911] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365916] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365922] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365927] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366052] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366323] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366330] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366407] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366585] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366646] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366654] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367333] pnp 00:03: [dma 4] [ 0.367337] pnp 00:03: [io 0x0000-0x000f] [ 0.367342] pnp 00:03: [io 0x0081-0x0083] [ 0.367347] pnp 00:03: [io 0x0087] [ 0.367351] pnp 00:03: [io 0x0089-0x008b] [ 0.367356] pnp 00:03: [io 0x008f] [ 0.367360] pnp 00:03: [io 0x00c0-0x00df] [ 0.367418] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367445] pnp 00:04: [io 0x0070-0x0071] [ 0.367452] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367462] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367467] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367485] pnp 00:04: [irq 8] [ 0.367541] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367612] pnp 00:05: [io 0x0060] [ 0.367617] pnp 00:05: [io 0x0064] [ 0.367621] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367627] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367632] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367645] pnp 00:05: [irq 1] [ 0.367700] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367814] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367820] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367825] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367842] pnp 00:06: [irq 12] [ 0.367901] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367922] pnp 00:07: [io 0x0061] [ 0.367979] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368001] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368006] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368011] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368016] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368029] pnp 00:08: [irq 13] [ 0.368059] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368059] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368059] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368059] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368394] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368402] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368494] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368555] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368856] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368862] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.368944] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.368951] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.368958] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369454] pnp 00:0c: [io 0x0010-0x001f] [ 0.369460] pnp 00:0c: [io 0x0022-0x003f] [ 0.369464] pnp 00:0c: [io 0x0062-0x0063] [ 0.369469] pnp 00:0c: [io 0x0065-0x006f] [ 0.369473] pnp 00:0c: [io 0x0072-0x007f] [ 0.369477] pnp 00:0c: [io 0x0080] [ 0.369482] pnp 00:0c: [io 0x0084-0x0086] [ 0.369486] pnp 00:0c: [io 0x0088] [ 0.369490] pnp 00:0c: [io 0x008c-0x008e] [ 0.369495] pnp 00:0c: [io 0x0090-0x009f] [ 0.369499] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369503] pnp 00:0c: [io 0x00b1] [ 0.369508] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369512] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369517] pnp 00:0c: [io 0x0550-0x0551] [ 0.369521] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369526] pnp 00:0c: [io 0x040b] [ 0.369530] pnp 00:0c: [io 0x04d6] [ 0.369534] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369538] pnp 00:0c: [io 0x0c14] [ 0.369542] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369547] pnp 00:0c: [io 0x0c52] [ 0.369551] pnp 00:0c: [io 0x0c6c] [ 0.369555] pnp 00:0c: [io 0x0c6f] [ 0.369559] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369564] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369568] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369573] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369577] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369581] pnp 00:0c: [io 0x0800-0x089f] [ 0.369586] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369591] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369596] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369600] pnp 00:0c: [io 0x0900-0x090f] [ 0.369605] pnp 00:0c: [io 0x0910-0x091f] [ 0.369609] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369614] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369619] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369624] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369631] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369775] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369781] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369787] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369793] system 00:0c: [io 0x040b] has been reserved [ 0.369798] system 00:0c: [io 0x04d6] has been reserved [ 0.369804] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369810] system 00:0c: [io 0x0c14] has been reserved [ 0.369815] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369821] system 00:0c: [io 0x0c52] has been reserved [ 0.369826] system 00:0c: [io 0x0c6c] has been reserved [ 0.369832] system 00:0c: [io 0x0c6f] has been reserved [ 0.369837] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369843] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369849] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369855] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369861] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369870] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369876] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369882] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369888] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369893] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369900] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369906] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369913] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369920] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370470] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370475] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370481] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370486] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370499] pnp 00:0d: [irq 4] [ 0.370503] pnp 00:0d: [dma 0 disabled] [ 0.370627] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371202] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371207] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371212] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371217] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371221] Already setup the GSI :3 [ 0.371226] pnp 00:0e: [irq 3] [ 0.371230] pnp 00:0e: [dma 0 disabled] [ 0.371350] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371492] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371574] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371582] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372549] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372555] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372560] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372565] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372573] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372673] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372679] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372686] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372692] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372698] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372706] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373005] pnp: PnP ACPI: found 17 devices [ 0.373009] ACPI: ACPI bus type pnp unregistered [ 0.380350] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380377] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380428] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380436] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380446] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380460] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380467] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380477] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380491] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380502] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380512] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380536] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380554] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380569] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380579] pci 0000:00:09.0: setting latency timer to 64 [ 0.380590] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380600] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380613] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380622] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380638] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380643] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380648] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380654] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380660] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380665] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380671] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380677] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380683] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380689] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380696] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380702] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380707] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380713] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380719] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380725] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380782] NET: Registered protocol family 2 [ 0.382871] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388135] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391365] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391707] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391714] TCP reno registered [ 0.391839] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392140] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392395] NET: Registered protocol family 1 [ 0.392455] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392478] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392499] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120169] pci 0000:00:12.0: PCI INT A disabled [ 1.120201] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120215] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120220] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120225] Already setup the GSI :16 [ 1.120232] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204174] pci 0000:00:12.1: PCI INT A disabled [ 1.204207] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204221] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204226] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204231] Already setup the GSI :17 [ 1.204237] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204371] pci 0000:00:12.2: PCI INT B disabled [ 1.204387] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204392] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204397] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204401] Already setup the GSI :18 [ 1.204406] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288185] pci 0000:00:13.0: PCI INT A disabled [ 1.288216] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288229] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288234] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288239] Already setup the GSI :18 [ 1.288245] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372178] pci 0000:00:13.1: PCI INT A disabled [ 1.372211] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372237] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372256] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372390] pci 0000:00:13.2: PCI INT B disabled [ 1.372416] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372422] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372426] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372431] Already setup the GSI :18 [ 1.372435] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456173] pci 0000:00:14.5: PCI INT C disabled [ 1.456259] pci 0000:01:04.0: Boot video device [ 1.456267] PCI: CLS 64 bytes, default 64 [ 1.457343] audit: initializing netlink socket (disabled) [ 1.457362] type=3D2000 audit(1336038821.847:1): initialized [ 1.485577] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487788] VFS: Disk quotas dquot_6.5.2 [ 1.487868] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488563] fuse init (API version 7.17) [ 1.488737] msgmni has been set to 1479 [ 1.489458] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489514] io scheduler noop registered [ 1.489519] io scheduler deadline registered [ 1.489561] io scheduler cfq registered (default) [ 1.490010] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490046] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490266] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490277] ACPI: Power Button [PWRB] [ 1.490337] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490345] ACPI: Power Button [PWRF] [ 1.688912] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.689037] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.689211] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.689634] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.693393] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.812124] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.832536] hpet_acpi_add: no address or irqs in _CRS [ 1.832555] Linux agpgart interface v0.103 [ 1.836328] brd: module loaded [ 1.837212] loop: module loaded [ 1.837590] ahci 0000:00:11.0: version 3.0 [ 1.837625] xen: registering gsi 22 triggering 0 polarity 1 [ 1.837648] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.837666] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.837891] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.837900] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.838864] scsi0 : ahci [ 1.838982] scsi1 : ahci [ 1.839077] scsi2 : ahci [ 1.839173] scsi3 : ahci [ 1.839275] scsi4 : ahci [ 1.839371] scsi5 : ahci [ 1.840311] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.840319] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.840327] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.840334] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.840341] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.840348] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.840881] Fixed MDIO Bus: probed [ 1.840909] tun: Universal TUN/TAP device driver, 1.6 [ 1.840918] tun: (C) 1999-2004 Max Krasnyansky [ 1.840983] PPP generic driver version 2.4.2 [ 1.841100] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.841193] xen: registering gsi 17 triggering 0 polarity 1 [ 1.841202] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.841207] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.841212] Already setup the GSI :17 [ 1.841218] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.841252] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.841336] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.841353] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.841452] ehci_hcd 0000:00:12.2: debug port 1 [ 1.841502] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.852094] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.852291] hub 1-0:1.0: USB hub found [ 1.852299] hub 1-0:1.0: 6 ports detected [ 1.852485] xen: registering gsi 19 triggering 0 polarity 1 [ 1.852493] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.852498] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.852503] Already setup the GSI :19 [ 1.852508] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.852542] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.852618] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.852633] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.852708] ehci_hcd 0000:00:13.2: debug port 1 [ 1.852763] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.864098] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.864308] hub 2-0:1.0: USB hub found [ 1.864316] hub 2-0:1.0: 6 ports detected [ 1.864439] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.864560] xen: registering gsi 16 triggering 0 polarity 1 [ 1.864569] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.864574] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.864578] Already setup the GSI :16 [ 1.864584] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.864618] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.864685] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.864754] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.924286] hub 3-0:1.0: USB hub found [ 1.924301] hub 3-0:1.0: 3 ports detected [ 1.924456] xen: registering gsi 16 triggering 0 polarity 1 [ 1.924464] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.924468] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.924473] Already setup the GSI :16 [ 1.924478] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.924513] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.924582] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.924626] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 1.984287] hub 4-0:1.0: USB hub found [ 1.984301] hub 4-0:1.0: 3 ports detected [ 1.984451] xen: registering gsi 18 triggering 0 polarity 1 [ 1.984458] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.984463] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.984468] Already setup the GSI :18 [ 1.984473] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 1.984508] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 1.984579] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 1.984646] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.044274] hub 5-0:1.0: USB hub found [ 2.044288] hub 5-0:1.0: 3 ports detected [ 2.044439] xen: registering gsi 18 triggering 0 polarity 1 [ 2.044447] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.044452] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.044456] Already setup the GSI :18 [ 2.044462] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.044496] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.044569] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.044609] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.104298] hub 6-0:1.0: USB hub found [ 2.104314] hub 6-0:1.0: 3 ports detected [ 2.104504] xen: registering gsi 18 triggering 0 polarity 1 [ 2.104512] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.104517] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.104522] Already setup the GSI :18 [ 2.104527] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.104561] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.104633] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.104684] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.160242] ata5: SATA link down (SStatus 0 SControl 300) [ 2.164415] hub 7-0:1.0: USB hub found [ 2.164430] hub 7-0:1.0: 2 ports detected [ 2.164530] uhci_hcd: USB Universal Host Controller Interface driver [ 2.164625] usbcore: registered new interface driver libusual [ 2.164682] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.167602] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.167614] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.167777] mousedev: PS/2 mouse device common for all mice [ 2.167985] rtc_cmos 00:04: RTC can wake from S4 [ 2.168223] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.168275] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.168379] device-mapper: uevent: version 1.0.3 [ 2.168474] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.168487] EFI Variables Facility v0.08 2004-May-17 [ 2.168807] TCP cubic registered [ 2.168939] NET: Registered protocol family 10 [ 2.169670] NET: Registered protocol family 17 [ 2.169694] Registering the dns_resolver key type [ 2.169917] PM: Hibernation image not present or could not be loaded. [ 2.169934] registered taskstats version 1 [ 2.176089] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.187946] Magic number: 12:509:878 [ 2.188144] rtc_cmos 00:04: setting system clock to 2012-05-03 09:53:4= 2 UTC (1336038822) [ 2.188276] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.188374] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.188379] EDD information not available. [ 2.200605] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.314893] Initializing USB Mass Storage driver... [ 2.315113] scsi6 : usb-storage 2-2:1.0 [ 2.315224] usbcore: registered new interface driver usb-storage [ 2.315230] USB Mass Storage support registered. [ 2.332119] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.332156] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332191] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332222] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332246] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.332694] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.333246] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333255] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333273] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333281] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333299] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333309] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333413] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.333420] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.333543] ata6.00: configured for UDMA/100 [ 2.334451] ata1.00: configured for UDMA/133 [ 2.334636] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.334792] ata4.00: configured for UDMA/133 [ 2.334824] ata3.00: configured for UDMA/133 [ 2.334866] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.334915] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.334938] ata2.00: configured for UDMA/133 [ 2.335015] sd 0:0:0:0: [sda] Write Protect is off [ 2.335024] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.335061] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.335194] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.335396] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.335416] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.335501] sd 1:0:0:0: [sdb] Write Protect is off [ 2.335509] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.335557] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.335702] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.335883] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.335917] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.335981] sd 2:0:0:0: [sdc] Write Protect is off [ 2.335987] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.336106] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.336258] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.336265] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.336355] sd 3:0:0:0: [sdd] Write Protect is off [ 2.336362] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.336367] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.336408] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.337308] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.340918] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.340927] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.341087] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.341196] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.341647] sdb: sdb1 sdb2 [ 2.342067] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.347291] sdd: unknown partition table [ 2.347568] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.350641] sdc: unknown partition table [ 2.350926] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.455361] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.457499] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.458052] Freeing unused kernel memory: 920k freed [ 2.458379] Write protecting the kernel read-only data: 12288k [ 2.465974] Freeing unused kernel memory: 1520k freed [ 2.467147] Freeing unused kernel memory: 1140k freed [ 2.532778] udevd[166]: starting version 175 [ 2.586556] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.586566] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.586899] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.586929] xen: registering gsi 17 triggering 0 polarity 1 [ 2.586979] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.586985] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.586991] Already setup the GSI :17 [ 2.586997] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.587033] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.684119] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.711875] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.711884] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.711969] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.712119] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.712148] xen: registering gsi 18 triggering 0 polarity 1 [ 2.712159] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.712164] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.712170] Already setup the GSI :18 [ 2.712176] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.712208] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.826232] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.826241] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.826326] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.862464] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.862705] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.866427] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.866568] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.866595] usbcore: registered new interface driver usbhid [ 2.866601] usbhid: USB HID core driver [ 3.313116] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.313858] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.314481] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.315095] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.315995] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.316209] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.316399] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.316566] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.321554] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.325956] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.327301] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 3.328099] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 8.680452] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.378393] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.378413] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.406855] udevd[718]: starting version 175 [ 15.516929] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.541315] lp: driver loaded but no devices found [ 15.543010] Bridge firewalling registered [ 15.543528] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.545436] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.545583] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.548417] device-mapper: multipath: version 1.3.0 loaded [ 15.554115] ipmi message handler version 39.2 [ 15.554771] device eth0 entered promiscuous mode [ 15.554947] ipmi device interface [ 15.561242] IPMI System Interface driver. [ 15.561305] ipmi_si: probing via SMBIOS [ 15.561309] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 15.561313] ipmi_si: Adding SMBIOS-specified kcs state machine [ 15.561321] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 15.565782] MCE: In-kernel MCE decoding enabled. [ 15.567534] EDAC MC: Ver: 2.1.0 [ 15.568886] AMD64 EDAC driver v3.4.0 [ 15.569069] EDAC amd64: DRAM ECC enabled. [ 15.569102] EDAC amd64: F10h detected (node 0). [ 15.569180] EDAC MC: DCT0 chip selects: [ 15.569187] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.569190] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.569197] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.569203] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.569206] EDAC MC: DCT1 chip selects: [ 15.569209] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.569212] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.569215] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.569218] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.569221] EDAC amd64: using x8 syndromes. [ 15.569224] EDAC amd64: MCT channel count: 2 [ 15.569278] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.569285] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.569288] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.569291] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.569422] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 15.571018] EDAC amd64: DRAM ECC enabled. [ 15.571030] EDAC amd64: F10h detected (node 1). [ 15.571107] EDAC MC: DCT0 chip selects: [ 15.571111] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.571114] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.571117] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.571120] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.571123] EDAC MC: DCT1 chip selects: [ 15.571126] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 15.571129] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 15.571132] EDAC amd64: MC: 4: 0MB 5: 0MB [ 15.571135] EDAC amd64: MC: 6: 0MB 7: 0MB [ 15.571138] EDAC amd64: using x8 syndromes. [ 15.571141] EDAC amd64: MCT channel count: 2 [ 15.571176] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 15.571179] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 15.571183] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 15.571186] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 15.571257] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 15.571424] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 15.606210] type=3D1400 audit(1336038835.913:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D818 comm=3D"appar= mor_parser" [ 15.606825] type=3D1400 audit(1336038835.913:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D818 comm=3D"apparmor_parser" [ 15.607175] type=3D1400 audit(1336038835.913:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D818 comm=3D"apparmor_parser" [ 15.643062] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.655321] ADDRCONF(NETDEV_UP): br0: link is not ready [ 15.672109] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 15.712684] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 15.713196] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 15.852353] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 15.919391] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.672650] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.200817] EXT4-fs (dm-33): mounted filesystem with ordered data mode= =2E Opts: (null) [ 18.745090] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 18.747436] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.747574] br0: port 1(eth0) entering forwarding state [ 18.747591] br0: port 1(eth0) entering forwarding state [ 18.749725] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 21.937790] init: udev-fallback-graphics main process (1840) terminate= d with status 1 [ 22.085550] init: failsafe main process (1723) killed by TERM signal [ 22.198011] type=3D1400 audit(1336038842.505:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1936 comm=3D"apparmor_parser" [ 22.198271] type=3D1400 audit(1336038842.505:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1934 comm=3D"a= pparmor_parser" [ 22.198526] type=3D1400 audit(1336038842.505:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1937 comm=3D"= apparmor_parser" [ 22.198897] type=3D1400 audit(1336038842.505:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1934 comm=3D"apparmor_parser" [ 22.199271] type=3D1400 audit(1336038842.505:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1934 comm=3D"apparmor_parser" [ 22.199376] type=3D1400 audit(1336038842.505:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1938 c= omm=3D"apparmor_parser" [ 22.199727] type=3D1400 audit(1336038842.505:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1938 comm=3D"apparmor_parser" [ 22.200161] type=3D1400 audit(1336038842.509:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1940 comm=3D"= apparmor_parser" [ 22.477708] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 22.722258] ip_tables: (C) 2000-2006 Netfilter Core Team [ 22.823823] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 22.877126] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 23.122997] Event-channel device installed. [ 23.185712] XENBUS: Unable to read cpu state [ 23.185922] XENBUS: Unable to read cpu state [ 23.186113] XENBUS: Unable to read cpu state [ 23.186295] XENBUS: Unable to read cpu state [ 23.186508] XENBUS: Unable to read cpu state [ 23.186669] XENBUS: Unable to read cpu state [ 23.186807] XENBUS: Unable to read cpu state [ 23.186979] XENBUS: Unable to read cpu state [ 23.944659] Ebtables v2.0 registered [ 23.976417] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.644090] br0: no IPv6 routers present [ 205.760461] xen-acpi-processor: Max ACPI ID: 16 [ 205.760479]=20 [ 205.760480] **** Context Switch from TID 0 to TID 42768112 **** [ 205.760481]=20 [ 205.760485] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.760495] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.760504] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.760514] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.760522] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.760530] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.760540] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.760548] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.760557] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.760567] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.760577] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.760595] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.760604] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.760613] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.760622] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P001] (ffff880027d50e88) [ 205.760631] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.760640] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.760656] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.760664] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.760672] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50e88 [ 205.760682] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.760690] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P001 (ffff880027d50e88) For [_PSD] (Untyped) [ 205.760701] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.760708] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.760717] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d438 found in scope [P001] ffff880027d50e88= [ 205.760727] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.760736] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.760744] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.760752] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.760762] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.760772] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.760780] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.760788] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.760797] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d438 [ 205.760806] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d709d8 [ 205.760814] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d438] Value ffff880027d709d8 [ 205.760824] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.760832] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.760841] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.760849] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.760859] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.760868] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.760885] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.760894] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.760902] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d438 [ 205.760912] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d709d8 [ 205.760920] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.760928] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.760937] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d438 SourceDesc=3Dffff880027d709d8 [Package] [ 205.760947] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d709d8 [ 205.760955] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.760964] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d709d8 [ 205.760973] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d709d8 Current Refs=3D1 [To Be Incremented] [ 205.760982] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d709d8 [ 205.760991] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cdf30 [ 205.761001] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.761009] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761017] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761025] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d709d8 Refs=3D2, [Incremented] [ 205.761034] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761042] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761050] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761058] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761067] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cdf78 [ 205.761075] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.761083] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761091] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761099] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff880027d716c0 [ 205.761107] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.761115] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761123] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761131] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff880027d71a68 [ 205.761139] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.761148] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761155] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761163] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250ce000 [ 205.761171] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.761180] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761187] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761195] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250ce048 [ 205.761204] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.761212] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.761220] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.761228] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cdf30 Refs=3D2, [Incremented] [ 205.761236] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761244] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.761252] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761260] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761268] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250ce048 Refs=3D2, [Incremented] [ 205.761276] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761284] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.761293] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761300] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761308] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250ce000 Refs=3D2, [Incremented] [ 205.761317] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761324] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.761333] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761341] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761349] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d71a68 Refs=3D2, [Incremented] [ 205.761358] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761365] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.761373] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761381] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761389] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d716c0 Refs=3D2, [Incremented] [ 205.761398] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.761405] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761414] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.761421] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.761429] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cdf78 Refs=3D2, [Incremented] [ 205.761438] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.761446] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.761454] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.761462] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.761470] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.761479] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.761488] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.761495] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d709d8 [Package] [ 205.761506] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d438 [ 205.761514] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.761524] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P001._PSD Validating return Package of Type 5, Count 1 [ 205.761535] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.761544] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.761552] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d709d8 [ 205.761561] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.761569] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 205.761577] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.761586] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.761593] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.761601] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250cdf30 [ 205.761609] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.761618] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cdf78 [ 205.761626] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761634] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff880027d716c0 [ 205.761642] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761650] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff880027d71a68 [ 205.761658] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761666] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250ce000 [ 205.761674] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761682] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250ce048 [ 205.761691] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.761699] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.761706] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.761714] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.761722] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761730] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.761738] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.761745] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.761753] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.761762] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.761770] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.761779] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.761787] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.761795] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.761803] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d709d8 [ 205.761811] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.761819] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.761827] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.761835] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250cdf30 [ 205.761843] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.761851] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761859] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761867] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761875] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761883] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761891] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761899] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761907] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761914] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.761922] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.761930] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.761938] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.761946] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.761953] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.761962] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.761969] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.761977] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.761985] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.761993] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.762001] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.762010] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.762018] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.762026] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.762035] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.762044] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.762061] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.762069] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d709d8 [ 205.762077] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d709d8 Current Refs=3D2 [To Be Decremented] [ 205.762087] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d709d8 [ 205.762095] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cdf30 [ 205.762103] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.762112] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762119] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762127] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d709d8 Refs=3D1, [Decremented] [ 205.762136] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762144] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.762152] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762159] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762167] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cdf78 [ 205.762175] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.762184] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762192] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762199] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff880027d716c0 [ 205.762208] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.762216] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762223] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762231] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff880027d71a68 [ 205.762239] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.762248] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762255] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762263] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250ce000 [ 205.762271] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.762279] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762287] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762295] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250ce048 [ 205.762303] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.762311] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.762319] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.762327] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cdf30 Refs=3D1, [Decremented] [ 205.762336] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762343] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.762352] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762359] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762367] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250ce048 Refs=3D1, [Decremented] [ 205.762376] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762383] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.762391] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762399] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762407] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250ce000 Refs=3D1, [Decremented] [ 205.762416] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762423] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.762431] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762439] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762447] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d71a68 Refs=3D1, [Decremented] [ 205.762455] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762463] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.762471] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762479] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762487] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d716c0 Refs=3D1, [Decremented] [ 205.762495] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.762503] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.762511] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.762519] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.762527] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cdf78 Refs=3D1, [Decremented] [ 205.762535] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.762554] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.762562] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.762570] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.762579] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.762588] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.762596] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.762605] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.762613] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.762621] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.762630] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.762637] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.762645] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.762654] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.762662] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.762670] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.762679] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.762688] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.762705] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.762713] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.762721] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.762729] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P002] (ffff880027d50eb0) [ 205.762738] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.762746] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.762760] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.762768] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.762776] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50eb0 [ 205.762784] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.762792] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P002 (ffff880027d50eb0) For [_PSD] (Untyped) [ 205.762802] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.762810] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.762818] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d500 found in scope [P002] ffff880027d50eb0= [ 205.762828] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.762836] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.762844] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.762852] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.762861] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.762870] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.762878] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.762886] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.762894] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d500 [ 205.762903] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70b40 [ 205.762911] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d500] Value ffff880027d70b40 [ 205.762920] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.762928] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.762936] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.762944] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.762953] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.762962] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.762979] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.762987] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.762995] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d500 [ 205.763003] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70b40 [ 205.763012] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.763019] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.763028] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d500 SourceDesc=3Dffff880027d70b40 [Package] [ 205.763037] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70b40 [ 205.763045] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.763053] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70b40 [ 205.763061] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70b40 Current Refs=3D1 [To Be Incremented] [ 205.763070] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70b40 [ 205.763078] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfd38 [ 205.763086] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.763095] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763102] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763110] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70b40 Refs=3D2, [Incremented] [ 205.763119] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763126] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763134] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763142] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763150] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfd80 [ 205.763158] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.763167] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763174] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763182] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfdc8 [ 205.763190] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.763199] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763206] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763214] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfe10 [ 205.763222] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.763230] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763238] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763246] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfe58 [ 205.763254] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.763262] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763270] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763278] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250cfea0 [ 205.763286] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.763294] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.763302] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.763310] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfd38 Refs=3D2, [Incremented] [ 205.763318] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763326] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.763334] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763342] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763350] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfea0 Refs=3D2, [Incremented] [ 205.763358] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763366] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.763375] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763382] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763390] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfe58 Refs=3D2, [Incremented] [ 205.763399] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763406] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.763415] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763422] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763430] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfe10 Refs=3D2, [Incremented] [ 205.763439] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763446] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.763455] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763462] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763470] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfdc8 Refs=3D2, [Incremented] [ 205.763479] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.763487] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763495] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.763503] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.763510] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250cfd80 Refs=3D2, [Incremented] [ 205.763519] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.763527] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.763535] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.763543] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.763551] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.763560] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.763568] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.763576] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70b40 [Package] [ 205.763586] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d500 [ 205.763594] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.763603] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P002._PSD Validating return Package of Type 5, Count 1 [ 205.763612] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.763620] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.763629] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70b40 [ 205.763637] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.763645] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 205.763653] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.763661] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.763669] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.763677] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250cfd38 [ 205.763685] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.763693] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfd80 [ 205.763701] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763709] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfdc8 [ 205.763718] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763726] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfe10 [ 205.763734] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763742] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfe58 [ 205.763750] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763758] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250cfea0 [ 205.763766] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.763774] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.763782] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.763789] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.763797] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.763805] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.763813] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.763821] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.763828] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.763837] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.763845] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.763853] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.763861] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.763869] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.763877] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70b40 [ 205.763885] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.763893] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.763901] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.763909] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250cfd38 [ 205.763917] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.763925] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763933] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763941] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763949] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763957] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763964] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763972] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763980] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.763988] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.763996] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764004] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764012] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764019] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764027] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764035] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764043] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764056] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70b40 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70b40 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70b40 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfd38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70b40 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfd80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfdc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfe10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfe58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250cfea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfd38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfe58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfe10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfdc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250cfd80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P003] (ffff880027d50ed8) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50ed8 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P003 (ffff880027d50ed8) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d5c8 found in scope [P003] ffff880027d50ed8= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d5c8 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70ca8 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d5c8] Value ffff880027d70ca8 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d5c8 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70ca8 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d5c8 SourceDesc=3Dffff880027d70ca8 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70ca8 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70ca8 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70ca8 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70ca8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d2ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d2d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70ca8 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d5c8 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P003._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70ca8 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d2ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70ca8 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70ca8 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70ca8 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70ca8 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70ca8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d2ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d2d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P004] (ffff880027d50f00) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f00 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P004 (ffff880027d50f00) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d690 found in scope [P004] ffff880027d50f00= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d690 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70e10 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d690] Value ffff880027d70e10 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d690 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70e10 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d690 SourceDesc=3Dffff880027d70e10 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70e10 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70e10 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70e10 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70e10 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d4d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70e10 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d690 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P004._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70e10 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d4ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70e10 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70e10 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70e10 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70e10 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d4ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d4d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P005] (ffff880027d50f28) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f28 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P005 (ffff880027d50f28) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d758 found in scope [P005] ffff880027d50f28= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d758 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d70f78 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d758] Value ffff880027d70f78 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d758 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d70f78 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d758 SourceDesc=3Dffff880027d70f78 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d70f78 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d70f78 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d70f78 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d70f78 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d70f78 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d6d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d70f78 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d758 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P005._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d70f78 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d6ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d70f78 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d70f78 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d70f78 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d70f78 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d70f78 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d6ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d6d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P006] (ffff880027d50f50) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f50 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P006 (ffff880027d50f50) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d820 found in scope [P006] ffff880027d50f50= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d820 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d710d8 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d820] Value ffff880027d710d8 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d820 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d710d8 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d820 SourceDesc=3Dffff880027d710d8 [Package] [ 205.764063] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d710d8 [ 205.764063] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.764063] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d710d8 [ 205.764063] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d710d8 Current Refs=3D1 [To Be Incremented] [ 205.764063] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d710d8 [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d710d8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7d80 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7dc8 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7e10 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7e58 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d7ea0 [ 205.764063] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7d38 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7ea0 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7e58 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7e10 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7dc8 Refs=3D2, [Incremented] [ 205.764063] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d7d80 Refs=3D2, [Incremented] [ 205.764063] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.764063] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.764063] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.764063] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.764063] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d710d8 [Package] [ 205.764063] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d820 [ 205.764063] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.764063] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P006._PSD Validating return Package of Type 5, Count 1 [ 205.764063] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.764063] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.764063] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d710d8 [ 205.764063] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7d80 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7dc8 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7e10 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7e58 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d7ea0 [ 205.764063] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.764063] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.764063] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.764063] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.764063] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d710d8 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.764063] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.764063] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.764063] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.764063] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.764063] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.764063] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d710d8 [ 205.764063] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d710d8 Current Refs=3D2 [To Be Decremented] [ 205.764063] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d710d8 [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7d38 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d710d8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7d80 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7dc8 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7e10 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7e58 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d7ea0 [ 205.764063] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.764063] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.764063] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7d38 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7ea0 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7e58 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7e10 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7dc8 Refs=3D1, [Decremented] [ 205.764063] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.764063] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.764063] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.764063] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.764063] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d7d80 Refs=3D1, [Decremented] [ 205.764063] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.764063] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.764063] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.764063] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.764063] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.764063] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.764063] nsxfeval-0181 [42768112] [4294967293] evaluate_object = : ----Entry [ 205.764063] nseval-0090 [42768112] [4294967294] ns_evaluate = : ----Entry [ 205.764063] nsutils-0707 [42768112] [4294967295] ns_get_node = : ----Entry ffffffff81a4c82f [ 205.764063] nsutils-0391 [42768112] [00] ns_internalize_name : ----= Entry [ 205.764063] nsutils-0280 [42768112] [01] ns_build_internal_name: ----= Entry [ 205.764063] nsutils-0363 [42768112] [01] ns_build_internal_name: Retu= rning [ffff88001b1a1870] (rel) "_PSD" [ 205.764063] nsutils-0366 [42768112] [01] ns_build_internal_name: ----= Exit- AE_OK [ 205.764063] nsutils-0419 [42768112] [00] ns_internalize_name : ----= Exit- AE_OK [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404360|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404360|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Namespace] [ 205.764063] nsaccess-0301 [42768112] [00] ns_lookup : ----= Entry [ 205.764063] nsutils-0663 [42768112] [01] ns_opens_scope : ----= Entry Processor [ 205.764063] nsutils-0673 [42768112] [01] ns_opens_scope : ----= Exit- 0000000000000001 [ 205.764063] nsaccess-0398 [42768112] [00] ns_lookup : Sear= ching relative to prefix scope [P007] (ffff880027d50f78) [ 205.764063] nsaccess-0510 [42768112] [00] ns_lookup : Simp= le Pathname (1 segment, Flags=3D2) [ 205.764063] nsdump-0087 [42768112] [00] ns_print_pathname : [_PS= D] [ 205.764063] nssearch-0297 [42768112] [01] ns_search_and_enter : ----= Entry [ 205.764063] nssearch-0102 [42768112] [02] ns_search_one_scope : ----= Entry [ 205.764063] nsnames-0139 [42768112] [03] ns_get_external_pathna: ----= Entry ffff880027d50f78 [ 205.764063] nsnames-0164 [42768112] [03] ns_get_external_pathna: ----= Exit- ffff88001cfbd2d0 [ 205.764063] nssearch-0114 [42768112] [02] ns_search_one_scope : Sear= ching \_PR_.P007 (ffff880027d50f78) For [_PSD] (Untyped) [ 205.764063] nsutils-0150 [42768112] [03] ns_get_type : ----= Entry [ 205.764063] nsutils-0157 [42768112] [03] ns_get_type : ----= Exit- 0000000000000004 [ 205.764063] nssearch-0149 [42768112] [02] ns_search_one_scope : Name= [_PSD] (Package) ffff880027d6d8e8 found in scope [P007] ffff880027d50f78= [ 205.764063] nssearch-0152 [42768112] [02] ns_search_one_scope : ----= Exit- AE_OK [ 205.764063] nssearch-0349 [42768112] [01] ns_search_and_enter : ----= Exit- AE_OK [ 205.764063] nsaccess-0670 [42768112] [00] ns_lookup : ----= Exit- AE_OK [ 205.764063] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Namespace] [ 205.764063] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404360|1] [ 205.764063] nsutils-0750 [42768112] [4294967295] ns_get_node = : ----Exit- AE_OK [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] nsobject-0266 [42768112] [4294967295] ns_get_attached_obje= ct: ----Entry ffff880027d6d8e8 [ 205.764063] nsobject-0281 [42768112] [4294967295] ns_get_attached_obje= ct: ----Exit- ffff880027d71288 [ 205.764063] nseval-0127 [42768112] [4294967294] ns_evaluate = : _PSD [ffff880027d6d8e8] Value ffff880027d71288 [ 205.764063] nsutils-0150 [42768112] [4294967295] ns_get_type = : ----Entry [ 205.764063] nsutils-0157 [42768112] [4294967295] ns_get_type = : ----Exit- 0000000000000004 [ 205.764063] exutils-0091 [42768112] [4294967295] ex_enter_interpreter= : ----Entry [ 205.764063] utmutex-0261 [42768112] [4294967295] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.764063] osl-0981 [42768112] [4294967295] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.764063] osl-1000 [42768112] [4294967295] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967295] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.764063] exutils-0099 [42768112] [4294967295] ex_enter_interpreter= : ----Exit- [ 205.764063] exresnte-0089 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Entry [ 205.764063] nsobject-0266 [42768112] [00] ns_get_attached_object: ----= Entry ffff880027d6d8e8 [ 205.764063] nsobject-0281 [42768112] [00] ns_get_attached_object: ----= Exit- ffff880027d71288 [ 205.764063] nsutils-0150 [42768112] [00] ns_get_type : ----= Entry [ 205.772639] nsutils-0157 [42768112] [00] ns_get_type : ----= Exit- 0000000000000004 [ 205.772647] exresnte-0101 [42768112] [4294967295] ex_resolve_node_to_v= al: Entry=3Dffff880027d6d8e8 SourceDesc=3Dffff880027d71288 [Package] [ 205.772657] dsargs-0318 [42768112] [00] ds_get_package_argumen: ----= Entry ffff880027d71288 [ 205.772665] dsargs-0321 [42768112] [00] ds_get_package_argumen: ----= Exit- AE_OK [ 205.772673] utdelete-0642 [42768112] [00] ut_add_reference : ----= Entry ffff880027d71288 [ 205.772682] utdelete-0652 [42768112] [00] ut_add_reference : Obj = ffff880027d71288 Current Refs=3D1 [To Be Incremented] [ 205.772692] utdelete-0483 [42768112] [01] ut_update_object_refer: ----= Entry ffff880027d71288 [ 205.772712] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 205.772731] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.772752] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.772770] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.772790] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff880027d71288 Refs=3D2, [Incremented] [ 205.772811] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.772828] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.772846] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.772863] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.772881] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 205.772901] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.772919] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.772937] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.772956] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 205.772973] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.772990] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773007] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773027] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 205.773044] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.773064] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773083] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773103] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 205.773122] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.773144] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773160] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773176] utstate-0233 [42768112] [02] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 205.773195] utstate-0248 [42768112] [02] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.773212] utstate-0100 [42768112] [02] ut_push_generic_state : ----= Entry [ 205.773230] utstate-0107 [42768112] [02] ut_push_generic_state : ----= Exit- [ 205.773245] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9d38 Refs=3D2, [Incremented] [ 205.773269] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773287] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.773305] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773321] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773339] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9ea0 Refs=3D2, [Incremented] [ 205.773359] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773378] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.773394] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773413] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773430] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9e58 Refs=3D2, [Incremented] [ 205.773448] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773465] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.773486] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773503] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773517] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9e10 Refs=3D2, [Incremented] [ 205.773539] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773558] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.773575] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773592] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773610] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9dc8 Refs=3D2, [Incremented] [ 205.773629] utstate-0127 [42768112] [02] ut_pop_generic_state : ----= Entry [ 205.773647] utstate-0139 [42768112] [02] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.773665] utstate-0339 [42768112] [02] ut_delete_generic_stat: ----= Entry [ 205.773681] utstate-0346 [42768112] [02] ut_delete_generic_stat: ----= Exit- [ 205.773697] utdelete-0393 [42768112] [01] ut_update_ref_count : Obj = ffff8800250d9d80 Refs=3D2, [Incremented] [ 205.773705] utdelete-0609 [42768112] [01] ut_update_object_refer: ----= Exit- AE_OK [ 205.773713] utdelete-0657 [42768112] [00] ut_add_reference : ----= Exit- [ 205.773721] exresnte-0277 [42768112] [4294967295] ex_resolve_node_to_v= al: ----Exit- AE_OK [ 205.773730] exutils-0151 [42768112] [4294967295] ex_exit_interpreter = : ----Entry [ 205.773738] utmutex-0304 [42768112] [4294967295] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.773747] osl-1020 [42768112] [4294967295] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.773757] exutils-0159 [42768112] [4294967295] ex_exit_interpreter = : ----Exit- [ 205.773765] nseval-0247 [42768112] [4294967294] ns_evaluate = : Returning object ffff880027d71288 [Package] [ 205.773775] nsnames-0139 [42768112] [4294967295] ns_get_external_path= na: ----Entry ffff880027d6d8e8 [ 205.773783] nsnames-0164 [42768112] [4294967295] ns_get_external_path= na: ----Exit- ffff88001cfbd2d0 [ 205.773792] nspredef-0445 [42768112] [4294967294] ns_check_package = : \_PR_.P007._PSD Validating return Package of Type 5, Count 1 [ 205.773802] nseval-0277 [42768112] [4294967294] ns_evaluate = : *** Completed evaluation of object _PSD *** [ 205.773811] nseval-0283 [42768112] [4294967294] ns_evaluate = : ----Exit- AE_OK [ 205.773819] utobject-0645 [42768112] [4294967294] ut_get_package_objec= t_: ----Entry ffff880027d71288 [ 205.773828] utmisc-0941 [42768112] [4294967295] ut_walk_package_tree= : ----Entry [ 205.773836] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 205.773845] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.773853] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.773861] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.773869] utstate-0270 [42768112] [00] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 205.773878] utstate-0287 [42768112] [00] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.773886] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9d80 [ 205.773895] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773904] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9dc8 [ 205.773912] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773921] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e10 [ 205.773935] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.773958] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9e58 [ 205.773982] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.774004] utobject-0460 [42768112] [00] ut_get_simple_object_s: ----= Entry ffff8800250d9ea0 [ 205.774028] utobject-0562 [42768112] [00] ut_get_simple_object_s: ----= Exit- AE_OK [ 205.774051] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.774076] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.774093] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774113] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.774130] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.774148] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.774164] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774183] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- (null) [ 205.774201] utmisc-0996 [42768112] [4294967295] ut_walk_package_tree= : ----Exit- AE_OK [ 205.774215] utobject-0668 [42768112] [4294967294] ut_get_package_objec= t_: ----Exit- AE_OK [ 205.774236] utcopy-0400 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Entry [ 205.774253] utcopy-0342 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Entry [ 205.774272] utmisc-0941 [42768112] [00] ut_walk_package_tree : ----= Entry [ 205.774289] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff880027d71288 [ 205.774310] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f000 [ 205.774327] utstate-0100 [42768112] [01] ut_push_generic_state : ----= Entry [ 205.774342] utstate-0107 [42768112] [01] ut_push_generic_state : ----= Exit- [ 205.774363] utstate-0270 [42768112] [01] ut_create_pkg_state : ----= Entry ffff8800250d9d38 [ 205.774382] utstate-0287 [42768112] [01] ut_create_pkg_state : ----= Exit- ffff88000282f050 [ 205.774399] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774418] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774435] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774453] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774470] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774486] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774505] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774524] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774538] utcopy-0118 [42768112] [01] ut_copy_isimple_to_esi: ----= Entry [ 205.774559] utcopy-0231 [42768112] [01] ut_copy_isimple_to_esi: ----= Exit- AE_OK [ 205.774579] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.774598] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.774614] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.774629] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.774647] utstate-0339 [42768112] [01] ut_delete_generic_stat: ----= Entry [ 205.774665] utstate-0346 [42768112] [01] ut_delete_generic_stat: ----= Exit- [ 205.774683] utstate-0127 [42768112] [01] ut_pop_generic_state : ----= Entry [ 205.774703] utstate-0139 [42768112] [01] ut_pop_generic_state : ----= Exit- (null) [ 205.774720] utmisc-0996 [42768112] [00] ut_walk_package_tree : ----= Exit- AE_OK [ 205.774740] utcopy-0377 [42768112] [4294967295] ut_copy_ipackage_to_= ep: ----Exit- AE_OK [ 205.774757] utcopy-0434 [42768112] [4294967294] ut_copy_iobject_to_e= ob: ----Exit- AE_OK [ 205.774776] exutils-0091 [42768112] [4294967294] ex_enter_interpreter= : ----Entry [ 205.774792] utmutex-0261 [42768112] [4294967294] ut_acquire_mutex = : Thread 42768112 attempting to acquire Mutex [ACPI_MTX_Interpreter] [ 205.774812] osl-0981 [42768112] [4294967294] os_wait_semaphore = : Waiting for semaphore[ffff88003e404340|1|65535] [ 205.774831] osl-1000 [42768112] [4294967294] os_wait_semaphore = : Acquired semaphore[ffff88003e404340|1|65535] utmutex-0269 [42768112] = [4294967294] ut_acquire_mutex : Thread 42768112 acquired Mutex [ACPI= _MTX_Interpreter] [ 205.774870] exutils-0099 [42768112] [4294967294] ex_enter_interpreter= : ----Exit- [ 205.774889] utdelete-0675 [42768112] [4294967294] ut_remove_reference = : ----Entry ffff880027d71288 [ 205.774907] utdelete-0695 [42768112] [4294967294] ut_remove_reference = : Obj ffff880027d71288 Current Refs=3D2 [To Be Decremented] [ 205.774928] utdelete-0483 [42768112] [4294967295] ut_update_object_ref= er: ----Entry ffff880027d71288 [ 205.774944] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9d38 [ 205.774953] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.774961] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.774969] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.774977] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff880027d71288 Refs=3D1, [Decremented] [ 205.774987] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.774994] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.775003] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775011] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775019] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9d80 [ 205.775028] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f000 [ 205.775036] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775044] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775052] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9dc8 [ 205.775061] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f050 [ 205.775069] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775077] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775085] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9e10 [ 205.775094] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0a0 [ 205.775110] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775127] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775145] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9e58 [ 205.775165] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f0f0 [ 205.775186] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775205] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775221] utstate-0233 [42768112] [00] ut_create_update_state: ----= Entry ffff8800250d9ea0 [ 205.775236] utstate-0248 [42768112] [00] ut_create_update_state: ----= Exit- ffff88000282f140 [ 205.775253] utstate-0100 [42768112] [00] ut_push_generic_state : ----= Entry [ 205.775269] utstate-0107 [42768112] [00] ut_push_generic_state : ----= Exit- [ 205.775284] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d38 Refs=3D1, [Decremented] [ 205.775309] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775328] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f140 [ 205.775345] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775365] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775381] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9ea0 Refs=3D1, [Decremented] [ 205.775400] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775416] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0f0 [ 205.775434] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775455] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775475] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e58 Refs=3D1, [Decremented] [ 205.775494] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775512] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f0a0 [ 205.775528] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775548] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775566] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9e10 Refs=3D1, [Decremented] [ 205.775587] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775603] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f050 [ 205.775620] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775638] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775655] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9dc8 Refs=3D1, [Decremented] [ 205.775674] utstate-0127 [42768112] [00] ut_pop_generic_state : ----= Entry [ 205.775691] utstate-0139 [42768112] [00] ut_pop_generic_state : ----= Exit- ffff88000282f000 [ 205.775709] utstate-0339 [42768112] [00] ut_delete_generic_stat: ----= Entry [ 205.775728] utstate-0346 [42768112] [00] ut_delete_generic_stat: ----= Exit- [ 205.775744] utdelete-0409 [42768112] [4294967295] ut_update_ref_count = : Obj ffff8800250d9d80 Refs=3D1, [Decremented] [ 205.775764] utdelete-0609 [42768112] [4294967295] ut_update_object_ref= er: ----Exit- AE_OK [ 205.775784] utdelete-0703 [42768112] [4294967294] ut_remove_reference = : ----Exit- [ 205.775805] exutils-0151 [42768112] [4294967294] ex_exit_interpreter = : ----Entry [ 205.775824] utmutex-0304 [42768112] [4294967294] ut_release_mutex = : Thread 42768112 releasing Mutex [ACPI_MTX_Interpreter] [ 205.775841] osl-1020 [42768112] [4294967294] os_signal_semaphore = : Signaling semaphore[ffff88003e404340|1] [ 205.775861] exutils-0159 [42768112] [4294967294] ex_exit_interpreter = : ----Exit- [ 205.775881] nsxfeval-0358 [42768112] [4294967293] evaluate_object = : ----Exit- AE_OK [ 205.775900] xen-acpi-processor: register_performance(0) =3D -19 --------------060305080106050804080206-- --------------enig44CE6C0905155E36B06E265B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPoldaAAoJEOhnXe7L7s6jjBAQAKFCK1qzxw0UjU51NEfoD5g1 f5bXe9KdgtRUqDIUs/dEVv0jBH4595SOn8ghksziBeKiIV2lh4ocZVtfP3U6pJdt +fq7Wxtp2yhcmSFXHHXmLIHkcI+WwMcZMSYKliruybBM+oYRGiq7/BxanaGwBK7A j2n/+7M28b3pjjI2X/Yi97ArSPN15HseasuglUZL03bbUV0KG/MdZsxZHRNp1tor sHeIS9PfscZfTobxLnPrY54x7HQSUvpIoU9eiZVRwQv318jQWNhyzf0kZcQiFwoG 3HHoJ/KASTIplmiR9bkCDJon0p/8dry/8XPZQdRB4MrwVfEeOFQ6qPiYWROgbonj 6vZPfDpa62mhdYIfcRf4ebcJuYpAIblzVdRuRpkBotYVcJ+lTAOWem7bEcKBuXcl e2d2/uA/pQveBuMQAapECG7e8LUaLrffJfx5jrpow++RtoSgiFKKpEUSqU7Hc6fk rBoVzaCII3M9Psn1cZLiLMUHRRubgjf54HpSLP2i8NUxPJ0lraemUnk6lrhYQLmI etH2rtedVDws5hSmT9AoEag8zStceyzpxB8+P4gAP5+cdIIXzA1bZA51QakLaz6Y Uc1F6Q0yEcEUxEdnR2BLZk2rJE+CBCTSEaDcceNIF9ruDVPXoluy04We5gmiNRVY N2q8M50EaMTVgEONU+YH =UqC/ -----END PGP SIGNATURE----- --------------enig44CE6C0905155E36B06E265B-- --===============4024771420858992763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4024771420858992763==-- From xen-devel-bounces@lists.xen.org Thu May 03 10:15:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPt3r-0001hp-W2; Thu, 03 May 2012 10:14:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt3q-0001hk-5X for xen-devel@lists.xen.org; Thu, 03 May 2012 10:14:58 +0000 Received: from [85.158.143.99:8012] by server-2.bemta-4.messagelabs.com id EF/DF-17550-1AA52AF4; Thu, 03 May 2012 10:14:57 +0000 X-Env-Sender: codinggeek16@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336040095!16536617!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11609 invoked from network); 3 May 2012 10:14:56 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:14:56 -0000 Received: by vbbfs19 with SMTP id fs19so1425886vbb.32 for ; Thu, 03 May 2012 03:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xHVNdccwE87pt2ZhX7NuLYL1lZkhzrGM4EPs3WVBahw=; b=ijcD074lkMpRnfBpTOZLBt9l22UeDogaiQIi/B5m0Jiju/dVOArrX63l1PO6TTT3qE 3QaT3Jylb3IcDVHxYEMYgj6lYIec18IkH2C6rl5e0DiHJrNFRnPDqwsHee/28Dp1EFlC 0Pw1fT2CiRteNJPbFpQR/U9YeL9KdndBqWFQmJwTO/AXCimHHBFM8/LfwD0LOtuAb/vT zG/BCX8u3h3uER8kBTnLBXWt+4y92x9QiLa8+Q0u10XzLq23K7o2XNpSxuqqcWCsql1i yAR2/WViqpt2NgvFg8gDYF9vEJjiCarJ7YW9Br+Q/ieNcMB4uoTBlYfacyr3J+8/HfBC m9XA== MIME-Version: 1.0 Received: by 10.52.175.138 with SMTP id ca10mr676067vdc.114.1336040095540; Thu, 03 May 2012 03:14:55 -0700 (PDT) Received: by 10.52.94.41 with HTTP; Thu, 3 May 2012 03:14:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 15:44:55 +0530 Message-ID: From: Coding Geek To: xen-devel@lists.xen.org Subject: [Xen-devel] Fwd: Does xen implement VIR_MIGRATE_PERSIST_DEST flag while migrating live using xen+ssh X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4185954824579471014==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4185954824579471014== Content-Type: multipart/alternative; boundary=bcaec50fe05b4ce4f104bf1f13d1 --bcaec50fe05b4ce4f104bf1f13d1 Content-Type: text/plain; charset=ISO-8859-1 Hello I am working with 3 host machines each running xen with shared NFS storage. I am working on automatic load balancing if one host is over utilized and another is under utilized by measuring the utilization from xentop. I am facing a problem after migration of VM. I am setting the flags ( 1| 8| 16) in order to do live migration, persist VM on destination, undefine host from source. After migration if I shut off the migrated VM on destination host it does not persist. I am using the migrateToURI() API for migration. Please help how to make VM persist on destination. Thank you, Tasvinder Singh --bcaec50fe05b4ce4f104bf1f13d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
I am w= orking with 3 host machines each running xen with shared NFS storage. I am = working on automatic load balancing if one host is over utilized and anothe= r is under utilized by measuring the utilization from xentop. I am facing a= problem after migration of VM. I am setting the flags ( 1| 8| 16) in order= to do live migration, persist VM on destination, undefine host from source= . After migration if I shut off the migrated VM on destination host it does= not persist. I am using the migrateToURI() API for migration.

Please help how to make VM persist on destination.

Thank you,Tasvinder Singh



--bcaec50fe05b4ce4f104bf1f13d1-- --===============4185954824579471014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4185954824579471014==-- From xen-devel-bounces@lists.xen.org Thu May 03 10:15:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPt3r-0001hp-W2; Thu, 03 May 2012 10:14:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt3q-0001hk-5X for xen-devel@lists.xen.org; Thu, 03 May 2012 10:14:58 +0000 Received: from [85.158.143.99:8012] by server-2.bemta-4.messagelabs.com id EF/DF-17550-1AA52AF4; Thu, 03 May 2012 10:14:57 +0000 X-Env-Sender: codinggeek16@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336040095!16536617!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11609 invoked from network); 3 May 2012 10:14:56 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:14:56 -0000 Received: by vbbfs19 with SMTP id fs19so1425886vbb.32 for ; Thu, 03 May 2012 03:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xHVNdccwE87pt2ZhX7NuLYL1lZkhzrGM4EPs3WVBahw=; b=ijcD074lkMpRnfBpTOZLBt9l22UeDogaiQIi/B5m0Jiju/dVOArrX63l1PO6TTT3qE 3QaT3Jylb3IcDVHxYEMYgj6lYIec18IkH2C6rl5e0DiHJrNFRnPDqwsHee/28Dp1EFlC 0Pw1fT2CiRteNJPbFpQR/U9YeL9KdndBqWFQmJwTO/AXCimHHBFM8/LfwD0LOtuAb/vT zG/BCX8u3h3uER8kBTnLBXWt+4y92x9QiLa8+Q0u10XzLq23K7o2XNpSxuqqcWCsql1i yAR2/WViqpt2NgvFg8gDYF9vEJjiCarJ7YW9Br+Q/ieNcMB4uoTBlYfacyr3J+8/HfBC m9XA== MIME-Version: 1.0 Received: by 10.52.175.138 with SMTP id ca10mr676067vdc.114.1336040095540; Thu, 03 May 2012 03:14:55 -0700 (PDT) Received: by 10.52.94.41 with HTTP; Thu, 3 May 2012 03:14:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 15:44:55 +0530 Message-ID: From: Coding Geek To: xen-devel@lists.xen.org Subject: [Xen-devel] Fwd: Does xen implement VIR_MIGRATE_PERSIST_DEST flag while migrating live using xen+ssh X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4185954824579471014==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4185954824579471014== Content-Type: multipart/alternative; boundary=bcaec50fe05b4ce4f104bf1f13d1 --bcaec50fe05b4ce4f104bf1f13d1 Content-Type: text/plain; charset=ISO-8859-1 Hello I am working with 3 host machines each running xen with shared NFS storage. I am working on automatic load balancing if one host is over utilized and another is under utilized by measuring the utilization from xentop. I am facing a problem after migration of VM. I am setting the flags ( 1| 8| 16) in order to do live migration, persist VM on destination, undefine host from source. After migration if I shut off the migrated VM on destination host it does not persist. I am using the migrateToURI() API for migration. Please help how to make VM persist on destination. Thank you, Tasvinder Singh --bcaec50fe05b4ce4f104bf1f13d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
I am w= orking with 3 host machines each running xen with shared NFS storage. I am = working on automatic load balancing if one host is over utilized and anothe= r is under utilized by measuring the utilization from xentop. I am facing a= problem after migration of VM. I am setting the flags ( 1| 8| 16) in order= to do live migration, persist VM on destination, undefine host from source= . After migration if I shut off the migrated VM on destination host it does= not persist. I am using the migrateToURI() API for migration.

Please help how to make VM persist on destination.

Thank you,Tasvinder Singh



--bcaec50fe05b4ce4f104bf1f13d1-- --===============4185954824579471014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4185954824579471014==-- From xen-devel-bounces@lists.xen.org Thu May 03 10:17:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt6G-0001nG-K9; Thu, 03 May 2012 10:17:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt6F-0001n7-2e for xen-devel@lists.xen.org; Thu, 03 May 2012 10:17:27 +0000 Received: from [193.109.254.147:51017] by server-2.bemta-14.messagelabs.com id 95/58-19409-63B52AF4; Thu, 03 May 2012 10:17:26 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336040244!2274508!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16832 invoked from network); 3 May 2012 10:17:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:17:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193200670" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 06:17:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 06:17:23 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPt6B-0007Am-JR; Thu, 03 May 2012 11:17:23 +0100 Message-ID: <4FA25AEF.8010403@eu.citrix.com> Date: Thu, 3 May 2012 11:16:15 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <1336007032.874.12.camel@Abyss> In-Reply-To: <1336007032.874.12.camel@Abyss> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 02:03, Dario Faggioli wrote: > Actually, thinking more about this, I'm not even sure I can do what I > stated above. In fact, I don't think I can assume the number of CPUs > each node is made up of to be known, without actually checking it for > the specific node(s) I want to try using. What if some CPUs are off-line > and stuff like that? Hmm, yeah, off-line cpus are certainly going to be an issue. If each node has an equal number of cores, we should at least be able to find a *minimum* number of nodes, and then increase it from there; then in the common case (where there are no offline cpus), we'll only have a single pass. But I think the priority right now is getting something useable for the 4.2 release; so I think getting to a reasonable functionality quickly (i.e., with a minimum amount of effort from you) makes sense. If that means leaving it as is for the moment, that's fine. This won't be a hot path, so a little bit of inefficiency should be acceptable. We can always come back and revisit it later. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:17:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt6G-0001nG-K9; Thu, 03 May 2012 10:17:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPt6F-0001n7-2e for xen-devel@lists.xen.org; Thu, 03 May 2012 10:17:27 +0000 Received: from [193.109.254.147:51017] by server-2.bemta-14.messagelabs.com id 95/58-19409-63B52AF4; Thu, 03 May 2012 10:17:26 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336040244!2274508!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16832 invoked from network); 3 May 2012 10:17:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:17:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193200670" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 06:17:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 06:17:23 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPt6B-0007Am-JR; Thu, 03 May 2012 11:17:23 +0100 Message-ID: <4FA25AEF.8010403@eu.citrix.com> Date: Thu, 3 May 2012 11:16:15 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <1336007032.874.12.camel@Abyss> In-Reply-To: <1336007032.874.12.camel@Abyss> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 02:03, Dario Faggioli wrote: > Actually, thinking more about this, I'm not even sure I can do what I > stated above. In fact, I don't think I can assume the number of CPUs > each node is made up of to be known, without actually checking it for > the specific node(s) I want to try using. What if some CPUs are off-line > and stuff like that? Hmm, yeah, off-line cpus are certainly going to be an issue. If each node has an equal number of cores, we should at least be able to find a *minimum* number of nodes, and then increase it from there; then in the common case (where there are no offline cpus), we'll only have a single pass. But I think the priority right now is getting something useable for the 4.2 release; so I think getting to a reasonable functionality quickly (i.e., with a minimum amount of effort from you) makes sense. If that means leaving it as is for the moment, that's fine. This won't be a hot path, so a little bit of inefficiency should be acceptable. We can always come back and revisit it later. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:24:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtCF-00024k-LT; Thu, 03 May 2012 10:23:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtCD-00024e-QJ for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:23:38 +0000 Received: from [85.158.138.51:20473] by server-8.bemta-3.messagelabs.com id 81/BC-24428-9AC52AF4; Thu, 03 May 2012 10:23:37 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336040615!24994846!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26345 invoked from network); 3 May 2012 10:23:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:23:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12269564" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10:23:34 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 11:23:34 +0100 Date: Thu, 3 May 2012 11:20:34 +0100 From: Goncalo Gomes To: Konrad Rzeszutek Wilk Message-ID: <20120503102034.GA11043@eire.uk.xensource.com> References: <20120313173504.GB13033@phenom.dumpdata.com> <20120313180422.GA28716@eire.uk.xensource.com> <20120313190917.GA31144@eire.uk.xensource.com> <20120313192541.GA4969@phenom.dumpdata.com> <20120313223437.GA5180@eire.uk.xensource.com> <20120313234503.GA18924@phenom.dumpdata.com> <20120316191127.GA6668@eire.uk.xensource.com> <20120316195907.GA6228@phenom.dumpdata.com> <20120318155034.GA24315@eire.uk.xensource.com> <20120502195035.GA31755@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120502195035.GA31755@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "dave.mccracken@oracle.com" Subject: Re: [Xen-devel] crash in is_xen_swiotlb_buffer X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 02 May 2012, Konrad Rzeszutek Wilk wrote: ...snip... > > [ 0.000000] Hardware name: PowerEdge R310 > > [ 0.000000] Modules linked in: > > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.2.9 #9 > > [ 0.000000] Call Trace: > > [ 0.000000] [] ? warn_slowpath_common+0x6a/0x7b > > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > > [ 0.000000] [] ? warn_slowpath_null+0xd/0x10 > > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > > [ 0.000000] [] ? xen_set_pmd_hyper+0x3c/0x42 > > [ 0.000000] [] ? set_pmd_pfn+0xde/0xf9 > > [ 0.000000] [] ? init_alloc_remap+0x1b3/0x216 > > [ 0.000000] [] ? setup_node_data+0x4c/0x22f > > [ 0.000000] [] ? T.744+0x290/0x2c2 > > [ 0.000000] [] ? T.743+0x77/0x1a1 > > [ 0.000000] [] ? default_get_apic_id+0x14/0x33 > > [ 0.000000] [] ? initmem_init+0x5/0xb7 > > [ 0.000000] [] ? setup_arch+0x5bf/0x694 > > [ 0.000000] [] ? __spin_time_accum+0x26/0x36 > > [ 0.000000] [] ? start_kernel+0x81/0x34d > > [ 0.000000] [] ? xen_start_kernel+0x554/0x55b > > [ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]--- > > So I've been able to reproduce this and it is due to CONFIG_NUMA=y > set on 32-bit builds. > > From a brief look, it looks as this is happening: > > /* perform actual remap */ > for (pfn = 0; pfn < size >> PAGE_SHIFT; pfn += PTRS_PER_PTE) > set_pmd_pfn((unsigned long)remap_va + (pfn << PAGE_SHIFT), > (node_pa >> PAGE_SHIFT) + pfn, > PAGE_KERNEL_LARGE); > > The PAGE_KERNEL_LARGE means that the PSE bit (so the 2MB) is set > which is a no-no. What is weird is that acpi_numa is disabled when booting > under Xen, but somehow this (which in my case was the 'fake_numa' code) > still gets turned on. Even doing 'numa=off' on the command line causes > this to appear. Thanks for the investigation, I'll turn off NUMA in my config. Goncalo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:24:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtCF-00024k-LT; Thu, 03 May 2012 10:23:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtCD-00024e-QJ for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:23:38 +0000 Received: from [85.158.138.51:20473] by server-8.bemta-3.messagelabs.com id 81/BC-24428-9AC52AF4; Thu, 03 May 2012 10:23:37 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336040615!24994846!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26345 invoked from network); 3 May 2012 10:23:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 10:23:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12269564" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10:23:34 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 11:23:34 +0100 Date: Thu, 3 May 2012 11:20:34 +0100 From: Goncalo Gomes To: Konrad Rzeszutek Wilk Message-ID: <20120503102034.GA11043@eire.uk.xensource.com> References: <20120313173504.GB13033@phenom.dumpdata.com> <20120313180422.GA28716@eire.uk.xensource.com> <20120313190917.GA31144@eire.uk.xensource.com> <20120313192541.GA4969@phenom.dumpdata.com> <20120313223437.GA5180@eire.uk.xensource.com> <20120313234503.GA18924@phenom.dumpdata.com> <20120316191127.GA6668@eire.uk.xensource.com> <20120316195907.GA6228@phenom.dumpdata.com> <20120318155034.GA24315@eire.uk.xensource.com> <20120502195035.GA31755@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120502195035.GA31755@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "dave.mccracken@oracle.com" Subject: Re: [Xen-devel] crash in is_xen_swiotlb_buffer X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 02 May 2012, Konrad Rzeszutek Wilk wrote: ...snip... > > [ 0.000000] Hardware name: PowerEdge R310 > > [ 0.000000] Modules linked in: > > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.2.9 #9 > > [ 0.000000] Call Trace: > > [ 0.000000] [] ? warn_slowpath_common+0x6a/0x7b > > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > > [ 0.000000] [] ? warn_slowpath_null+0xd/0x10 > > [ 0.000000] [] ? xen_mc_issue+0x34/0x62 > > [ 0.000000] [] ? xen_set_pmd_hyper+0x3c/0x42 > > [ 0.000000] [] ? set_pmd_pfn+0xde/0xf9 > > [ 0.000000] [] ? init_alloc_remap+0x1b3/0x216 > > [ 0.000000] [] ? setup_node_data+0x4c/0x22f > > [ 0.000000] [] ? T.744+0x290/0x2c2 > > [ 0.000000] [] ? T.743+0x77/0x1a1 > > [ 0.000000] [] ? default_get_apic_id+0x14/0x33 > > [ 0.000000] [] ? initmem_init+0x5/0xb7 > > [ 0.000000] [] ? setup_arch+0x5bf/0x694 > > [ 0.000000] [] ? __spin_time_accum+0x26/0x36 > > [ 0.000000] [] ? start_kernel+0x81/0x34d > > [ 0.000000] [] ? xen_start_kernel+0x554/0x55b > > [ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]--- > > So I've been able to reproduce this and it is due to CONFIG_NUMA=y > set on 32-bit builds. > > From a brief look, it looks as this is happening: > > /* perform actual remap */ > for (pfn = 0; pfn < size >> PAGE_SHIFT; pfn += PTRS_PER_PTE) > set_pmd_pfn((unsigned long)remap_va + (pfn << PAGE_SHIFT), > (node_pa >> PAGE_SHIFT) + pfn, > PAGE_KERNEL_LARGE); > > The PAGE_KERNEL_LARGE means that the PSE bit (so the 2MB) is set > which is a no-no. What is weird is that acpi_numa is disabled when booting > under Xen, but somehow this (which in my case was the 'fake_numa' code) > still gets turned on. Even doing 'numa=off' on the command line causes > this to appear. Thanks for the investigation, I'll turn off NUMA in my config. Goncalo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:44:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtVf-0002HZ-G4; Thu, 03 May 2012 10:43:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtVe-0002HU-EP for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:43:42 +0000 Received: from [85.158.143.99:56752] by server-2.bemta-4.messagelabs.com id 69/CC-17550-D5162AF4; Thu, 03 May 2012 10:43:41 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-15.tower-216.messagelabs.com!1336041820!26292210!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11288 invoked from network); 3 May 2012 10:43:41 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-15.tower-216.messagelabs.com with SMTP; 3 May 2012 10:43:41 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id A9E7B1AC290; Thu, 3 May 2012 12:43:38 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VMlrWUOAcFYB; Thu, 3 May 2012 12:43:38 +0200 (CEST) Received: from [10.0.0.1] (p579469B6.dip.t-dialin.net [87.148.105.182]) by rootsrv.hfp.de (Postfix) with ESMTPA; Thu, 3 May 2012 12:43:38 +0200 (CEST) Message-ID: <4FA2615C.1000301@hfp.de> Date: Thu, 03 May 2012 12:43:40 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> In-Reply-To: <1335965470.26758.58.camel@zakaz.uk.xensource.com> Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02.05.2012 15:31, Ian Campbell wrote: > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > workloads natively? Yes, I tested against 2.6.32.x. Differences exist, but are minor. time emerge apache: 2.6.32.36 3.2.12 3.3.4 real 0m31.419s 0m34.770s 0m35.210s user 0m45.479s 0m38.994s 0m39.750s sys 0m6.488s 0m4.584s 0m4.928s make -j4: 2.6.32.36 3.2.12 3.3.4 real 2m3.531s 2m4.423s 2m2.348s user 7m45.817s 7m21.456s 7m18.291s sys 0m35.194s 0m28.758s 0m28.974s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:44:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtVf-0002HZ-G4; Thu, 03 May 2012 10:43:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtVe-0002HU-EP for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:43:42 +0000 Received: from [85.158.143.99:56752] by server-2.bemta-4.messagelabs.com id 69/CC-17550-D5162AF4; Thu, 03 May 2012 10:43:41 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-15.tower-216.messagelabs.com!1336041820!26292210!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11288 invoked from network); 3 May 2012 10:43:41 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-15.tower-216.messagelabs.com with SMTP; 3 May 2012 10:43:41 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id A9E7B1AC290; Thu, 3 May 2012 12:43:38 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VMlrWUOAcFYB; Thu, 3 May 2012 12:43:38 +0200 (CEST) Received: from [10.0.0.1] (p579469B6.dip.t-dialin.net [87.148.105.182]) by rootsrv.hfp.de (Postfix) with ESMTPA; Thu, 3 May 2012 12:43:38 +0200 (CEST) Message-ID: <4FA2615C.1000301@hfp.de> Date: Thu, 03 May 2012 12:43:40 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> In-Reply-To: <1335965470.26758.58.camel@zakaz.uk.xensource.com> Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02.05.2012 15:31, Ian Campbell wrote: > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > workloads natively? Yes, I tested against 2.6.32.x. Differences exist, but are minor. time emerge apache: 2.6.32.36 3.2.12 3.3.4 real 0m31.419s 0m34.770s 0m35.210s user 0m45.479s 0m38.994s 0m39.750s sys 0m6.488s 0m4.584s 0m4.928s make -j4: 2.6.32.36 3.2.12 3.3.4 real 2m3.531s 2m4.423s 2m2.348s user 7m45.817s 7m21.456s 7m18.291s sys 0m35.194s 0m28.758s 0m28.974s Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:47:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtYo-0002QH-Ge; Thu, 03 May 2012 10:46:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtYn-0002Q6-6j for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:46:57 +0000 Received: from [85.158.138.51:34307] by server-12.bemta-3.messagelabs.com id 32/FF-29760-02262AF4; Thu, 03 May 2012 10:46:56 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1336042015!25000696!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26889 invoked from network); 3 May 2012 10:46:55 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-3.tower-174.messagelabs.com with SMTP; 3 May 2012 10:46:55 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id D78B41AC290; Thu, 3 May 2012 12:46:54 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ac5UyBH5UB9k; Thu, 3 May 2012 12:46:54 +0200 (CEST) Received: from [10.0.0.1] (p579469B6.dip.t-dialin.net [87.148.105.182]) by rootsrv.hfp.de (Postfix) with ESMTPA; Thu, 3 May 2012 12:46:54 +0200 (CEST) Message-ID: <4FA26220.40205@hfp.de> Date: Thu, 03 May 2012 12:46:56 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: George Dunlap References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> <4FA16875.5020801@hfp.de> In-Reply-To: Cc: David Vrabel , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03.05.2012 10:32, George Dunlap wrote: >>> Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly >>> check for pending events when restoring irq flags"[1] and see how much >>> it helps? >> There is some minor improvement - but it is still far away from xenified >> 2.6.34.10. > Just FYI, the reason Ian suggested making the same comparison for > native is that the performance of linux overall on bare-metal has also > suffered since 2.6.34. It's likely that a non-trivial amount of the > performance regression is due to moving from 2.6.34 to 3.{2,3}, over > and above whatever regressions may have happened when moving from > xenified to pvops. I took his suggestion serious - and actually I had performed these tests (see my other post). Unfortunately, the minor loss on bare-metal and the huge loss on xenified 2.6.34 vs pvops 3.x show that the problem is clearly with the Xen changes and not the bare-metal changes. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:47:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10: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 ) id 1SPtYo-0002QH-Ge; Thu, 03 May 2012 10:46:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtYn-0002Q6-6j for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:46:57 +0000 Received: from [85.158.138.51:34307] by server-12.bemta-3.messagelabs.com id 32/FF-29760-02262AF4; Thu, 03 May 2012 10:46:56 +0000 X-Env-Sender: ml-xen-devel@hfp.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1336042015!25000696!1 X-Originating-IP: [88.205.101.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26889 invoked from network); 3 May 2012 10:46:55 -0000 Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6) by server-3.tower-174.messagelabs.com with SMTP; 3 May 2012 10:46:55 -0000 Received: from localhost (localhost [127.0.0.1]) by rootsrv.hfp.de (Postfix) with ESMTP id D78B41AC290; Thu, 3 May 2012 12:46:54 +0200 (CEST) X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de Received: from rootsrv.hfp.de ([127.0.0.1]) by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ac5UyBH5UB9k; Thu, 3 May 2012 12:46:54 +0200 (CEST) Received: from [10.0.0.1] (p579469B6.dip.t-dialin.net [87.148.105.182]) by rootsrv.hfp.de (Postfix) with ESMTPA; Thu, 3 May 2012 12:46:54 +0200 (CEST) Message-ID: <4FA26220.40205@hfp.de> Date: Thu, 03 May 2012 12:46:56 +0200 From: Andreas Kinzler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: George Dunlap References: <4FA1328B.6070602@hfp.de> <4FA13708.4050202@cantab.net> <4FA16875.5020801@hfp.de> In-Reply-To: Cc: David Vrabel , Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03.05.2012 10:32, George Dunlap wrote: >>> Can you apply 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac "xen: correctly >>> check for pending events when restoring irq flags"[1] and see how much >>> it helps? >> There is some minor improvement - but it is still far away from xenified >> 2.6.34.10. > Just FYI, the reason Ian suggested making the same comparison for > native is that the performance of linux overall on bare-metal has also > suffered since 2.6.34. It's likely that a non-trivial amount of the > performance regression is due to moving from 2.6.34 to 3.{2,3}, over > and above whatever regressions may have happened when moving from > xenified to pvops. I took his suggestion serious - and actually I had performed these tests (see my other post). Unfortunately, the minor loss on bare-metal and the huge loss on xenified 2.6.34 vs pvops 3.x show that the problem is clearly with the Xen changes and not the bare-metal changes. Regards Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:52:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:52:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtdi-0002gv-8H; Thu, 03 May 2012 10:52:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtdg-0002go-Ni for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:52:00 +0000 Received: from [85.158.139.83:53236] by server-1.bemta-5.messagelabs.com id 45/FB-28458-F4362AF4; Thu, 03 May 2012 10:51:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336042319!19344778!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28325 invoked from network); 3 May 2012 10:51:59 -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 May 2012 10:51:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12270344" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10: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; Thu, 3 May 2012 11:51:59 +0100 Message-ID: <1336042317.20716.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andreas Kinzler Date: Thu, 3 May 2012 11:51:57 +0100 In-Reply-To: <4FA2615C.1000301@hfp.de> References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> <4FA2615C.1000301@hfp.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 11:43 +0100, Andreas Kinzler wrote: > On 02.05.2012 15:31, Ian Campbell wrote: > > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > > workloads natively? > > Yes, I tested against 2.6.32.x. Differences exist, but are minor. Good to know, thanks for testing The other potential Xen perf thing which just occurred to to me is the ACPI power management stuff which the xen-acpi-processor patches in 3.4-rcN are fixing. These are necessary to enable things like turbo mode so have a pretty large perf impact. Are you able to try the latest 3.4-rc kernel? I'm not sure if backports to the kernels you are running exist or not, Konrad? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 10:52:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 10:52:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtdi-0002gv-8H; Thu, 03 May 2012 10:52:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPtdg-0002go-Ni for xen-devel@lists.xensource.com; Thu, 03 May 2012 10:52:00 +0000 Received: from [85.158.139.83:53236] by server-1.bemta-5.messagelabs.com id 45/FB-28458-F4362AF4; Thu, 03 May 2012 10:51:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336042319!19344778!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28325 invoked from network); 3 May 2012 10:51:59 -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 May 2012 10:51:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12270344" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10: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; Thu, 3 May 2012 11:51:59 +0100 Message-ID: <1336042317.20716.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andreas Kinzler Date: Thu, 3 May 2012 11:51:57 +0100 In-Reply-To: <4FA2615C.1000301@hfp.de> References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> <4FA2615C.1000301@hfp.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 11:43 +0100, Andreas Kinzler wrote: > On 02.05.2012 15:31, Ian Campbell wrote: > > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > > workloads natively? > > Yes, I tested against 2.6.32.x. Differences exist, but are minor. Good to know, thanks for testing The other potential Xen perf thing which just occurred to to me is the ACPI power management stuff which the xen-acpi-processor patches in 3.4-rcN are fixing. These are necessary to enable things like turbo mode so have a pretty large perf impact. Are you able to try the latest 3.4-rc kernel? I'm not sure if backports to the kernels you are running exist or not, Konrad? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:24:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:24:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPu8Y-00035N-CJ; Thu, 03 May 2012 11:23:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPu8X-00035I-5Z for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:23:53 +0000 Received: from [85.158.143.99:55092] by server-3.bemta-4.messagelabs.com id 14/7E-05853-8CA62AF4; Thu, 03 May 2012 11:23:52 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336044231!16690530!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30133 invoked from network); 3 May 2012 11:23:51 -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; 3 May 2012 11:23:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271079" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:23: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; Thu, 3 May 2012 12:23:46 +0100 Date: Thu, 3 May 2012 12:31:14 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Andreas Kinzler In-Reply-To: <4FA1328B.6070602@hfp.de> Message-ID: References: <4FA1328B.6070602@hfp.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2 May 2012, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: > Thanks for running benchmarks! > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s > > time make -j4 (3.2.12 linux compile): > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 5m8.793s 5m4.888s 4m20.576s > user 8m1.746s 7m59.726s 7m10.375s > sys 1m39.010s 1m32.994s 0m56.304s Just for clarity, are you running this in dom0 (not in a VM), correct? If you are running the test in a VM, is it a PV or an HVM guest? What is the guest kernel version? What is the vcpu and memory configuration? And finally, what are you using as the disk image (file or LVM)? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:24:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:24:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPu8Y-00035N-CJ; Thu, 03 May 2012 11:23:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPu8X-00035I-5Z for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:23:53 +0000 Received: from [85.158.143.99:55092] by server-3.bemta-4.messagelabs.com id 14/7E-05853-8CA62AF4; Thu, 03 May 2012 11:23:52 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336044231!16690530!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30133 invoked from network); 3 May 2012 11:23:51 -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; 3 May 2012 11:23:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271079" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:23: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; Thu, 3 May 2012 12:23:46 +0100 Date: Thu, 3 May 2012 12:31:14 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Andreas Kinzler In-Reply-To: <4FA1328B.6070602@hfp.de> Message-ID: References: <4FA1328B.6070602@hfp.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2 May 2012, Andreas Kinzler wrote: > Hello Jeremy + Konrad + all kernel devs, > > while it is great to see that vanilla dom0 seems to work, the > performance breakdown compared to xenified 2.6.34 (from opensuse) is > huge. Here are my benchmarks: > Thanks for running benchmarks! > Xen 4.1.1, Xeon E5620, Supermicro X8DTi-F, 12 GB RAM, dom0 2 VCPUs > > time emerge apache: > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 1m0.560s 0m59.971s 0m47.689s > user 0m40.939s 0m40.619s 0m41.355s > sys 0m18.865s 0m18.305s 0m11.441s > > time make -j4 (3.2.12 linux compile): > > 3.2.12-dom0 3.3.4-dom0 2.6.34.10-dom0 > real 5m8.793s 5m4.888s 4m20.576s > user 8m1.746s 7m59.726s 7m10.375s > sys 1m39.010s 1m32.994s 0m56.304s Just for clarity, are you running this in dom0 (not in a VM), correct? If you are running the test in a VM, is it a PV or an HVM guest? What is the guest kernel version? What is the vcpu and memory configuration? And finally, what are you using as the disk image (file or LVM)? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:26:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11: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 ) id 1SPuAf-00039y-TD; Thu, 03 May 2012 11:26:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuAe-00039m-JB for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:26:04 +0000 Received: from [85.158.139.83:64291] by server-5.bemta-5.messagelabs.com id A5/9A-13566-B4B62AF4; Thu, 03 May 2012 11:26:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336044363!22710715!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31190 invoked from network); 3 May 2012 11:26:03 -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 May 2012 11:26:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271139" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:26: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; Thu, 3 May 2012 12:26:03 +0100 Date: Thu, 3 May 2012 12:33:31 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1335965470.26758.58.camel@zakaz.uk.xensource.com> Message-ID: References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Andreas Kinzler , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2 May 2012, Ian Campbell wrote: > On Wed, 2012-05-02 at 14:11 +0100, Andreas Kinzler wrote: > > Hello Jeremy + Konrad + all kernel devs, > > > > while it is great to see that vanilla dom0 seems to work, the > > performance breakdown compared to xenified 2.6.34 (from opensuse) is > > huge. Here are my benchmarks: > > There were a couple of performance fixes posted recently, one of them > was "xen: correctly check for pending events when restoring irq flags" > from David Vrabel, which is now in mainline as 7eb7ce4d2e89 and marked > for stable backport. The other was something to do with blk i/o > performance from Stefano Stabellini which I don't have a handy reference > too or status on (hopefully Konrad does though). It is this one: http://marc.info/?l=xen-devel&m=133526478318742&w=2 but it is only relevant if you are running the benchmark in a VM, with the disk image stored in a file. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:26:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11: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 ) id 1SPuAf-00039y-TD; Thu, 03 May 2012 11:26:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuAe-00039m-JB for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:26:04 +0000 Received: from [85.158.139.83:64291] by server-5.bemta-5.messagelabs.com id A5/9A-13566-B4B62AF4; Thu, 03 May 2012 11:26:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336044363!22710715!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31190 invoked from network); 3 May 2012 11:26:03 -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 May 2012 11:26:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271139" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:26: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; Thu, 3 May 2012 12:26:03 +0100 Date: Thu, 3 May 2012 12:33:31 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1335965470.26758.58.camel@zakaz.uk.xensource.com> Message-ID: References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Andreas Kinzler , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2 May 2012, Ian Campbell wrote: > On Wed, 2012-05-02 at 14:11 +0100, Andreas Kinzler wrote: > > Hello Jeremy + Konrad + all kernel devs, > > > > while it is great to see that vanilla dom0 seems to work, the > > performance breakdown compared to xenified 2.6.34 (from opensuse) is > > huge. Here are my benchmarks: > > There were a couple of performance fixes posted recently, one of them > was "xen: correctly check for pending events when restoring irq flags" > from David Vrabel, which is now in mainline as 7eb7ce4d2e89 and marked > for stable backport. The other was something to do with blk i/o > performance from Stefano Stabellini which I don't have a handy reference > too or status on (hopefully Konrad does though). It is this one: http://marc.info/?l=xen-devel&m=133526478318742&w=2 but it is only relevant if you are running the benchmark in a VM, with the disk image stored in a file. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:32:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:32:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuGT-0003Oe-B3; Thu, 03 May 2012 11:32:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuGR-0003OY-V9 for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:32:04 +0000 Received: from [193.109.254.147:56918] by server-3.bemta-14.messagelabs.com id D9/09-23274-3BC62AF4; Thu, 03 May 2012 11:32:03 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336044712!7467015!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17685 invoked from network); 3 May 2012 11:31:53 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:31:53 -0000 Received: by obfk16 with SMTP id k16so3279951obf.30 for ; Thu, 03 May 2012 04:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5/AcnEhiYv2fLKjx6zlUFhCjpiX/QRy2Oc0muvZvVFA=; b=Wde4MxrrFhEqs2rmGzca5gPTbxqtpxN6HCj9YT1GhvHgHw9XVwb93EAzellgcVVbDq Y5ah2CPqgWbMAfygTMsZZCur8YSY1fS4LuzrTY8NyPCgBaF88pKc6XtQ5wa6diRnNYla PzwnFm87D5Y56CIxXzE9cXqDhYl+m+u6O2jztk29+jUgy1zDB32zYh9m5D3K92gM0Tr+ BBsAZdBTv95a7JezECxifNHOdacq3F3hYXoY0KlozaNEQYsyVybEBE3g00ZIeRL9ECp+ JbQKib2ssNSEPlaM1T7IHNVDIT8boRMlj4EXFieBlinXLC1LJ6kD1l12zag4LZLfIpZG 4ePQ== MIME-Version: 1.0 Received: by 10.182.51.9 with SMTP id g9mr2293580obo.56.1336044711809; Thu, 03 May 2012 04:31:51 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 04:31:51 -0700 (PDT) In-Reply-To: <1335946863612-5679908.post@n5.nabble.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 19:31:51 +0800 Message-ID: From: ZhouPeng To: Fantu , Ian Campbell , Stefano Stabellini Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > > Zhou Peng wrote >> >> Hi Fantu, >> >> Thanks for your response. >> >> xl doesn't support qxl-related option at the moment. >> I will test upstream-qemu-xen these days, and if it works well >> with qxl device, I will be glad to add qxl support to xl. >> > Hello, any news about this? > Thanks in advance It seems you are using the upstream-qemu. There are some special patches for upstream-qemu-xen(I don't track if all the patches have been accepted by qemu) The git repos for upstream-qemu-xen: Stefano Stabellini's tree: git://xenbits.xen.org/people/sstabellini/qemu-dm.git Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git I am watching upstream-qemu-xen's progress too, but I have not tracked it for months. I was plan to test the latest upstream-qemu-xen and response to you, but I encounter a problem when preparing the environment using the upstream xen: # xl list libxl: error: libxl.c:506:libxl_list_domain: geting domain info list: Operation not permitted libxl_domain_infolist failed. So I suggest you to have a try of upstream-qemu-xen if not yet. In my test many months ago, it didn't support graphic, and spice was tested with linux-hvm disabling graphic. How to configure upstream-qemu-xen: ./configure --target-list=i386-softmmu --enable-spice --enable-xen --extra-cflags=-I${path-to-xen}/dist/install/usr/include --extra-ldflags=-L${path-to-xen}/dist/install/usr/lib CCing to Stefano, who may help you on upstream-qemu-xen. > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5679908.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:32:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:32:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuGT-0003Oe-B3; Thu, 03 May 2012 11:32:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuGR-0003OY-V9 for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:32:04 +0000 Received: from [193.109.254.147:56918] by server-3.bemta-14.messagelabs.com id D9/09-23274-3BC62AF4; Thu, 03 May 2012 11:32:03 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336044712!7467015!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17685 invoked from network); 3 May 2012 11:31:53 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:31:53 -0000 Received: by obfk16 with SMTP id k16so3279951obf.30 for ; Thu, 03 May 2012 04:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5/AcnEhiYv2fLKjx6zlUFhCjpiX/QRy2Oc0muvZvVFA=; b=Wde4MxrrFhEqs2rmGzca5gPTbxqtpxN6HCj9YT1GhvHgHw9XVwb93EAzellgcVVbDq Y5ah2CPqgWbMAfygTMsZZCur8YSY1fS4LuzrTY8NyPCgBaF88pKc6XtQ5wa6diRnNYla PzwnFm87D5Y56CIxXzE9cXqDhYl+m+u6O2jztk29+jUgy1zDB32zYh9m5D3K92gM0Tr+ BBsAZdBTv95a7JezECxifNHOdacq3F3hYXoY0KlozaNEQYsyVybEBE3g00ZIeRL9ECp+ JbQKib2ssNSEPlaM1T7IHNVDIT8boRMlj4EXFieBlinXLC1LJ6kD1l12zag4LZLfIpZG 4ePQ== MIME-Version: 1.0 Received: by 10.182.51.9 with SMTP id g9mr2293580obo.56.1336044711809; Thu, 03 May 2012 04:31:51 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 04:31:51 -0700 (PDT) In-Reply-To: <1335946863612-5679908.post@n5.nabble.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 19:31:51 +0800 Message-ID: From: ZhouPeng To: Fantu , Ian Campbell , Stefano Stabellini Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > > Zhou Peng wrote >> >> Hi Fantu, >> >> Thanks for your response. >> >> xl doesn't support qxl-related option at the moment. >> I will test upstream-qemu-xen these days, and if it works well >> with qxl device, I will be glad to add qxl support to xl. >> > Hello, any news about this? > Thanks in advance It seems you are using the upstream-qemu. There are some special patches for upstream-qemu-xen(I don't track if all the patches have been accepted by qemu) The git repos for upstream-qemu-xen: Stefano Stabellini's tree: git://xenbits.xen.org/people/sstabellini/qemu-dm.git Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git I am watching upstream-qemu-xen's progress too, but I have not tracked it for months. I was plan to test the latest upstream-qemu-xen and response to you, but I encounter a problem when preparing the environment using the upstream xen: # xl list libxl: error: libxl.c:506:libxl_list_domain: geting domain info list: Operation not permitted libxl_domain_infolist failed. So I suggest you to have a try of upstream-qemu-xen if not yet. In my test many months ago, it didn't support graphic, and spice was tested with linux-hvm disabling graphic. How to configure upstream-qemu-xen: ./configure --target-list=i386-softmmu --enable-spice --enable-xen --extra-cflags=-I${path-to-xen}/dist/install/usr/include --extra-ldflags=-L${path-to-xen}/dist/install/usr/lib CCing to Stefano, who may help you on upstream-qemu-xen. > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5679908.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:48:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:48:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuWK-0003cV-Uu; Thu, 03 May 2012 11:48:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuWJ-0003cQ-In for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:48:27 +0000 Received: from [85.158.143.99:39257] by server-2.bemta-4.messagelabs.com id C5/81-17550-A8072AF4; Thu, 03 May 2012 11:48:26 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336045703!16694993!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3843 invoked from network); 3 May 2012 11:48:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:48:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193210476" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07:48:22 -0400 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, 3 May 2012 07:48:22 -0400 Message-ID: <4FA27084.4030005@citrix.com> Date: Thu, 3 May 2012 12:48:20 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> In-Reply-To: <20120501163707.GA8741@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/05/12 17:37, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >> Changelog v5 [since v4]: >> - used populate_physmap, fixed bugs. >> [v2-v4: not posted] >> - reworked the code in setup.c to work properly. >> [v1: https://lkml.org/lkml/2012/3/30/492] >> - initial patchset > > One bug I found was that with 'dom0_mem=max:1G' (with and without these > patches) I would get a bunch of > > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) > > where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine > I ran on it. I figured it out that the difference was in the ACPI tables > that are allocated - and that those regions - even though are returned > back to the hypervisor, cannot be repopulated. I can't find the actual > exact piece of code in the hypervisor to pin-point and say "Aha". It was tricky to track down what is going here but I think I see what's happening. The problem pages (on the system I looked at) were located just before the ISA memory region (so PFN < a0) and so they are mapped in the bootstrap page tables and have an additional ref so are not immediately freed when the page is released. They do get freed later on, presumably when the page tables are swapped over. I think the mapping needs to be removed with HYPERVISOR_update_va_mapping() before releasing the page. This is already done for the ISA region in xen_ident_map_ISA(). I may be easier to avoid doing anything with the PFNs < 0x100 and take the minimal lose of memory. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:48:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:48:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuWK-0003cV-Uu; Thu, 03 May 2012 11:48:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuWJ-0003cQ-In for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:48:27 +0000 Received: from [85.158.143.99:39257] by server-2.bemta-4.messagelabs.com id C5/81-17550-A8072AF4; Thu, 03 May 2012 11:48:26 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336045703!16694993!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3843 invoked from network); 3 May 2012 11:48:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:48:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193210476" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07:48:22 -0400 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, 3 May 2012 07:48:22 -0400 Message-ID: <4FA27084.4030005@citrix.com> Date: Thu, 3 May 2012 12:48:20 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> In-Reply-To: <20120501163707.GA8741@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/05/12 17:37, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >> Changelog v5 [since v4]: >> - used populate_physmap, fixed bugs. >> [v2-v4: not posted] >> - reworked the code in setup.c to work properly. >> [v1: https://lkml.org/lkml/2012/3/30/492] >> - initial patchset > > One bug I found was that with 'dom0_mem=max:1G' (with and without these > patches) I would get a bunch of > > (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 > (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) > > where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine > I ran on it. I figured it out that the difference was in the ACPI tables > that are allocated - and that those regions - even though are returned > back to the hypervisor, cannot be repopulated. I can't find the actual > exact piece of code in the hypervisor to pin-point and say "Aha". It was tricky to track down what is going here but I think I see what's happening. The problem pages (on the system I looked at) were located just before the ISA memory region (so PFN < a0) and so they are mapped in the bootstrap page tables and have an additional ref so are not immediately freed when the page is released. They do get freed later on, presumably when the page tables are swapped over. I think the mapping needs to be removed with HYPERVISOR_update_va_mapping() before releasing the page. This is already done for the ISA region in xen_ident_map_ISA(). I may be easier to avoid doing anything with the PFNs < 0x100 and take the minimal lose of memory. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:55:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:55:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPucn-0003m3-P7; Thu, 03 May 2012 11:55:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPucl-0003lw-T2 for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:55:08 +0000 Received: from [85.158.139.83:49663] by server-10.bemta-5.messagelabs.com id 2B/75-08260-B1272AF4; Thu, 03 May 2012 11:55:07 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336046105!22633573!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1107 invoked from network); 3 May 2012 11:55:06 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:55:06 -0000 Received: by yhkk6 with SMTP id k6so877047yhk.30 for ; Thu, 03 May 2012 04:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pWb3IU55y99pZeoazkofEnS85kSaxUVkg+qsIoDtlds=; b=CedNjf+HrICoMqL2ukqEK+++a7zDYOh/RY30ht3yMzVIuY01PmDQfPaZeKfWMlCLGT mifs33nfR69m/XFGPe+8kFhZUzY9nlaAQLJ4F4tdrteJg+k1d6DWYAlHpJkrv/z2gzlL bIc7Ni602V98XAu499Si7gg2I5/N2OyAo0llmumjh60cfsDTSkWDqh3qSPET9S5GTyfx vDBs8U2IcdavALpHaZ3PrQPbcHxAa7jbcLKQ+leWjhNOVISn3dSYPjh/OJuyCeFzUB5x ztJZ2rBTk1msZHuaZMvEBbib5n32i4TaE8+qKmqD6yDpF847Q1bAFjGgfYTCeJrqhvQA bf9Q== Received: by 10.236.109.66 with SMTP id r42mr2557248yhg.39.1336046104852; Thu, 03 May 2012 04:55:04 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id a35sm22643150yhh.13.2012.05.03.04.55.00 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:55:03 -0700 (PDT) Message-ID: <4FA27212.9060403@cantab.net> Date: Thu, 03 May 2012 12:54:58 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X' or with not dom0_mem. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > We ignored the X value and ended up populating up to > max(MAX_DOMAIN_PAGES, last E820_RAM entry). > > This fixes it by figuring out how many RAM nr_pages the > hypervisor wanted to provide to us and cap the populate > hypercalls up to that. I don't think we should change the behavior again, particularly as the dom0_mem documentation doesn't describe this proposed behaviour. I would drop this patch. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:55:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:55:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPucn-0003m3-P7; Thu, 03 May 2012 11:55:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPucl-0003lw-T2 for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:55:08 +0000 Received: from [85.158.139.83:49663] by server-10.bemta-5.messagelabs.com id 2B/75-08260-B1272AF4; Thu, 03 May 2012 11:55:07 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336046105!22633573!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1107 invoked from network); 3 May 2012 11:55:06 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:55:06 -0000 Received: by yhkk6 with SMTP id k6so877047yhk.30 for ; Thu, 03 May 2012 04:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pWb3IU55y99pZeoazkofEnS85kSaxUVkg+qsIoDtlds=; b=CedNjf+HrICoMqL2ukqEK+++a7zDYOh/RY30ht3yMzVIuY01PmDQfPaZeKfWMlCLGT mifs33nfR69m/XFGPe+8kFhZUzY9nlaAQLJ4F4tdrteJg+k1d6DWYAlHpJkrv/z2gzlL bIc7Ni602V98XAu499Si7gg2I5/N2OyAo0llmumjh60cfsDTSkWDqh3qSPET9S5GTyfx vDBs8U2IcdavALpHaZ3PrQPbcHxAa7jbcLKQ+leWjhNOVISn3dSYPjh/OJuyCeFzUB5x ztJZ2rBTk1msZHuaZMvEBbib5n32i4TaE8+qKmqD6yDpF847Q1bAFjGgfYTCeJrqhvQA bf9Q== Received: by 10.236.109.66 with SMTP id r42mr2557248yhg.39.1336046104852; Thu, 03 May 2012 04:55:04 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id a35sm22643150yhh.13.2012.05.03.04.55.00 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:55:03 -0700 (PDT) Message-ID: <4FA27212.9060403@cantab.net> Date: Thu, 03 May 2012 12:54:58 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-7-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 6/8] xen/setup: Work properly with 'dom0_mem=X' or with not dom0_mem. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > We ignored the X value and ended up populating up to > max(MAX_DOMAIN_PAGES, last E820_RAM entry). > > This fixes it by figuring out how many RAM nr_pages the > hypervisor wanted to provide to us and cap the populate > hypercalls up to that. I don't think we should change the behavior again, particularly as the dom0_mem documentation doesn't describe this proposed behaviour. I would drop this patch. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:56:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:56:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPue5-0003pm-7Q; Thu, 03 May 2012 11:56:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPue4-0003pe-5J for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:56:28 +0000 Received: from [193.109.254.147:65106] by server-3.bemta-14.messagelabs.com id 2C/CA-23274-B6272AF4; Thu, 03 May 2012 11:56:27 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336046185!7489955!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14489 invoked from network); 3 May 2012 11:56: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; 3 May 2012 11:56:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271888" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:56: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, 3 May 2012 12:56:25 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPue0-0001SZ-Qz; Thu, 03 May 2012 11:56:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPue0-0001hz-Qc; Thu, 03 May 2012 12:56:24 +0100 To: Message-ID: From: xen.org Date: Thu, 3 May 2012 12:56:24 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12786: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12786 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12786/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12782 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 98fe3b2a572d baseline version: xen 98fe3b2a572d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:56:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11:56:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPue5-0003pm-7Q; Thu, 03 May 2012 11:56:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPue4-0003pe-5J for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:56:28 +0000 Received: from [193.109.254.147:65106] by server-3.bemta-14.messagelabs.com id 2C/CA-23274-B6272AF4; Thu, 03 May 2012 11:56:27 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336046185!7489955!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14489 invoked from network); 3 May 2012 11:56: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; 3 May 2012 11:56:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="12271888" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:56: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, 3 May 2012 12:56:25 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPue0-0001SZ-Qz; Thu, 03 May 2012 11:56:24 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPue0-0001hz-Qc; Thu, 03 May 2012 12:56:24 +0100 To: Message-ID: From: xen.org Date: Thu, 3 May 2012 12:56:24 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12786: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12786 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12786/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12782 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 98fe3b2a572d baseline version: xen 98fe3b2a572d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:56:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPueF-0003qV-JZ; Thu, 03 May 2012 11:56:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPueE-0003qO-Go for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:56:38 +0000 Received: from [85.158.143.99:23725] by server-2.bemta-4.messagelabs.com id AC/1E-17550-57272AF4; Thu, 03 May 2012 11:56:37 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336046195!26306386!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2029 invoked from network); 3 May 2012 11:56:36 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:56:36 -0000 Received: by yenq11 with SMTP id q11so683136yen.30 for ; Thu, 03 May 2012 04:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Prp7vUaG6BGyTpIpue6Iemae/4Bo54A03x1oyhjFGMM=; b=LD+CTQMy19d9Ms0iAeqsTx/AgEW8jBWM7IXd/aQQ5hS7rGvuItdoG/Gl/Jh0BEsWp7 PoAvPWEq8f7UdEDCpt35GEF+vCA0zraycYfK9D5/gdfnD7O2qIlgSvvchQ0Rb+5YCWDT EJ6jDMfXpoSTuBj+J5BWc7RYI5/ksDeuap28yCzkpc8OZYjPCKSfAr8tGO3WpfoF4SjY Ghw27HgNm3TM+YEAHSf0ISK40Yf/vOAbZ31mp+Q6Q56Mo0d5TYEHU2Bh3mIFVzPZnvIh s77uqLPd1TVY0nu37FdKwUivUn/muVO584L4W+15WxAgZNEz+UkK5K2OGuOThaqqiIyv UsyA== Received: by 10.236.181.133 with SMTP id l5mr2545572yhm.71.1336046195047; Thu, 03 May 2012 04:56:35 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id p6sm7633837ani.8.2012.05.03.04.56.33 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:56:34 -0700 (PDT) Message-ID: <4FA27270.5070905@cantab.net> Date: Thu, 03 May 2012 12:56:32 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > > > This patch, implements the populate hypercall (XENMEM_populate_physmap) > which increases the the domain with the same amount of pages that > were released. Provided the problem with the unreclaimable pages are resolved: Acked-by: David Vrabel David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:56:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPueF-0003qV-JZ; Thu, 03 May 2012 11:56:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPueE-0003qO-Go for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:56:38 +0000 Received: from [85.158.143.99:23725] by server-2.bemta-4.messagelabs.com id AC/1E-17550-57272AF4; Thu, 03 May 2012 11:56:37 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336046195!26306386!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2029 invoked from network); 3 May 2012 11:56:36 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:56:36 -0000 Received: by yenq11 with SMTP id q11so683136yen.30 for ; Thu, 03 May 2012 04:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Prp7vUaG6BGyTpIpue6Iemae/4Bo54A03x1oyhjFGMM=; b=LD+CTQMy19d9Ms0iAeqsTx/AgEW8jBWM7IXd/aQQ5hS7rGvuItdoG/Gl/Jh0BEsWp7 PoAvPWEq8f7UdEDCpt35GEF+vCA0zraycYfK9D5/gdfnD7O2qIlgSvvchQ0Rb+5YCWDT EJ6jDMfXpoSTuBj+J5BWc7RYI5/ksDeuap28yCzkpc8OZYjPCKSfAr8tGO3WpfoF4SjY Ghw27HgNm3TM+YEAHSf0ISK40Yf/vOAbZ31mp+Q6Q56Mo0d5TYEHU2Bh3mIFVzPZnvIh s77uqLPd1TVY0nu37FdKwUivUn/muVO584L4W+15WxAgZNEz+UkK5K2OGuOThaqqiIyv UsyA== Received: by 10.236.181.133 with SMTP id l5mr2545572yhm.71.1336046195047; Thu, 03 May 2012 04:56:35 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id p6sm7633837ani.8.2012.05.03.04.56.33 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:56:34 -0700 (PDT) Message-ID: <4FA27270.5070905@cantab.net> Date: Thu, 03 May 2012 12:56:32 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-8-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 7/8] xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > > > This patch, implements the populate hypercall (XENMEM_populate_physmap) > which increases the the domain with the same amount of pages that > were released. Provided the problem with the unreclaimable pages are resolved: Acked-by: David Vrabel David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:58:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11: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 ) id 1SPufk-0003zh-4M; Thu, 03 May 2012 11:58:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPufi-0003zX-Cd for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:58:10 +0000 Received: from [85.158.143.35:16772] by server-3.bemta-4.messagelabs.com id 44/C4-05853-1D272AF4; Thu, 03 May 2012 11:58:09 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336046287!13908693!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6256 invoked from network); 3 May 2012 11:58:08 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:58:08 -0000 Received: by yenq11 with SMTP id q11so684994yen.30 for ; Thu, 03 May 2012 04:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QP8Z0oKVuuq8i3lKVn9eSDM2bT4JaJ3T5XN7PadzCuo=; b=XWhNfkPSGa0hVx9nFX0PXq4SKymeOAkhoDC5WL5hloWFWmC0TEEF1ZNha8ls38F12j /qiQZnefrDJuCq/oZWF25PVuUHI/rYhuKC0iunRvDIQkOYcnYWD5sZQTu0JmwZmGy6iF wwLGtsMrFM++DbpHMkvmRqNfjszB89xJVyEky0Le7fVXUfAxC+ZVMdT126WK5ORWn1WL Qd95yt40W5XxPC+btnNJp/Z73bPakaYSeGRj2M/CPb+PgOAu7Xz4FkhNCf5TQYTdINn3 mBkX2jcyNuseKEj+SKZucU8nZuWQz9Esv/Xtl5DjSxIrYi4bqNCkycs7LBdSOF4TLM8Y J4pA== Received: by 10.236.109.66 with SMTP id r42mr2568838yhg.39.1336046287545; Thu, 03 May 2012 04:58:07 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id d25sm22741812yhe.4.2012.05.03.04.58.05 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:58:06 -0700 (PDT) Message-ID: <4FA272CD.90808@cantab.net> Date: Thu, 03 May 2012 12:58:05 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall functions - since they are quite similar. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > They use the same set of arguments, so it is just the matter > of using the proper hypercall. > > Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David Vrabel But would it be better to fold this into the previous patch? David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 11:58:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 11: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 ) id 1SPufk-0003zh-4M; Thu, 03 May 2012 11:58:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPufi-0003zX-Cd for xen-devel@lists.xensource.com; Thu, 03 May 2012 11:58:10 +0000 Received: from [85.158.143.35:16772] by server-3.bemta-4.messagelabs.com id 44/C4-05853-1D272AF4; Thu, 03 May 2012 11:58:09 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336046287!13908693!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6256 invoked from network); 3 May 2012 11:58:08 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 11:58:08 -0000 Received: by yenq11 with SMTP id q11so684994yen.30 for ; Thu, 03 May 2012 04:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QP8Z0oKVuuq8i3lKVn9eSDM2bT4JaJ3T5XN7PadzCuo=; b=XWhNfkPSGa0hVx9nFX0PXq4SKymeOAkhoDC5WL5hloWFWmC0TEEF1ZNha8ls38F12j /qiQZnefrDJuCq/oZWF25PVuUHI/rYhuKC0iunRvDIQkOYcnYWD5sZQTu0JmwZmGy6iF wwLGtsMrFM++DbpHMkvmRqNfjszB89xJVyEky0Le7fVXUfAxC+ZVMdT126WK5ORWn1WL Qd95yt40W5XxPC+btnNJp/Z73bPakaYSeGRj2M/CPb+PgOAu7Xz4FkhNCf5TQYTdINn3 mBkX2jcyNuseKEj+SKZucU8nZuWQz9Esv/Xtl5DjSxIrYi4bqNCkycs7LBdSOF4TLM8Y J4pA== Received: by 10.236.109.66 with SMTP id r42mr2568838yhg.39.1336046287545; Thu, 03 May 2012 04:58:07 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id d25sm22741812yhe.4.2012.05.03.04.58.05 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 04:58:06 -0700 (PDT) Message-ID: <4FA272CD.90808@cantab.net> Date: Thu, 03 May 2012 12:58:05 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, david.vrabel@citrix.com Subject: Re: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall functions - since they are quite similar. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > They use the same set of arguments, so it is just the matter > of using the proper hypercall. > > Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David Vrabel But would it be better to fold this into the previous patch? David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:00:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPuha-0004Cy-93; Thu, 03 May 2012 12:00:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuhX-0004CK-Q7 for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:00:04 +0000 Received: from [85.158.143.99:43185] by server-2.bemta-4.messagelabs.com id 4A/13-17550-34372AF4; Thu, 03 May 2012 12:00:03 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336046397!15124185!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8046 invoked from network); 3 May 2012 12:00:00 -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; 3 May 2012 12:00:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193211676" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07:59:26 -0400 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, 3 May 2012 07:59:26 -0400 Message-ID: <4FA2731C.2050204@citrix.com> Date: Thu, 3 May 2012 12:59:24 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH 5/8] xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > Otherwise we can get these meaningless: > Freeing bad80-badf4 pfn range: 0 pages freed > > We also can do this for the summary ones - no point of printing > "Set 0 page(s) to 1-1 mapping" > > [v1: Extended to the summary printks] > Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David Vrabel David > --- > arch/x86/xen/setup.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 1ba8dff..7b0ab77 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -114,8 +114,9 @@ static unsigned long __init xen_release_chunk(unsigned long start, > len++; > } > } > - printk(KERN_INFO "Freeing %lx-%lx pfn range: %lu pages freed\n", > - start, end, len); > + if (len) > + printk(KERN_INFO "Freeing %lx-%lx pfn range: %lu pages freed\n", > + start, end, len); > > return len; > } > @@ -162,8 +163,10 @@ static unsigned long __init xen_set_identity_and_release( > } > } > > - printk(KERN_INFO "Released %lu pages of unused memory\n", released); > - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); > + if (released) > + printk(KERN_INFO "Released %lu pages of unused memory\n", released); > + if (identity) > + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); > > return released; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:00:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPuha-0004Cy-93; Thu, 03 May 2012 12:00:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPuhX-0004CK-Q7 for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:00:04 +0000 Received: from [85.158.143.99:43185] by server-2.bemta-4.messagelabs.com id 4A/13-17550-34372AF4; Thu, 03 May 2012 12:00:03 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336046397!15124185!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8046 invoked from network); 3 May 2012 12:00:00 -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; 3 May 2012 12:00:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,522,1330923600"; d="scan'208";a="193211676" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 07:59:26 -0400 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, 3 May 2012 07:59:26 -0400 Message-ID: <4FA2731C.2050204@citrix.com> Date: Thu, 3 May 2012 12:59:24 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com> In-Reply-To: <1334596539-18172-6-git-send-email-konrad.wilk@oracle.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH 5/8] xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > Otherwise we can get these meaningless: > Freeing bad80-badf4 pfn range: 0 pages freed > > We also can do this for the summary ones - no point of printing > "Set 0 page(s) to 1-1 mapping" > > [v1: Extended to the summary printks] > Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David Vrabel David > --- > arch/x86/xen/setup.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 1ba8dff..7b0ab77 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -114,8 +114,9 @@ static unsigned long __init xen_release_chunk(unsigned long start, > len++; > } > } > - printk(KERN_INFO "Freeing %lx-%lx pfn range: %lu pages freed\n", > - start, end, len); > + if (len) > + printk(KERN_INFO "Freeing %lx-%lx pfn range: %lu pages freed\n", > + start, end, len); > > return len; > } > @@ -162,8 +163,10 @@ static unsigned long __init xen_set_identity_and_release( > } > } > > - printk(KERN_INFO "Released %lu pages of unused memory\n", released); > - printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); > + if (released) > + printk(KERN_INFO "Released %lu pages of unused memory\n", released); > + if (identity) > + printk(KERN_INFO "Set %ld page(s) to 1-1 mapping\n", identity); > > return released; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:29:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPv9N-0004hy-TC; Thu, 03 May 2012 12:28:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPv9M-0004hq-9s for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:28:48 +0000 Received: from [193.109.254.147:28432] by server-2.bemta-14.messagelabs.com id 3F/C1-19409-FF972AF4; Thu, 03 May 2012 12:28:47 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-4.tower-27.messagelabs.com!1336048125!7465237!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16645 invoked from network); 3 May 2012 12:28:46 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 12:28:46 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPv9I-0001F1-Jy for xen-devel@lists.xensource.com; Thu, 03 May 2012 05:28:44 -0700 Date: Thu, 3 May 2012 05:28:44 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336048124596-5683034.post@n5.nabble.com> In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org upstream-qemu-xen extra patches are included in upstream-qemu unstable (now at 1.1-rc0) I can run hvm domU correctly, on xen-unstable with xl, also with spice. Some info about my last test system: Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25249:a4e7fce6ee2b) vi Makefile # removed dist-kernel to not compile kernel ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb One domU xl configuration file: --------------------------------- XP.cfg ------------- name='XP' builder="hvm" memory=1024 vcpus=2 hap=1 pae=1 acpi=1 apic=1 nx=1 vif=['bridge=xenbr0'] #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw'] boot='cd' xen_platform_pci=1 viridian=1 device_model_version="qemu-xen" #vnc=1 #vncunused=1 #vnclisten="0.0.0.0" #keymap="it" spice=1 spicehost="0.0.0.0" spiceport=6000 spicedisable_ticketing=1 on_poweroff="destroy" on_reboot="restart" on_crash="destroy" stdvga=1 --------------------------------- About QXL I tried to add: stdvga=0 videoram=128 device_model_args=["-device","qxl-vga"] About qxl there are problems about videoram not allocated or not used over 4 mb (same as default cirrus vga). At the moment I haven't found solution for this problem, probably some bugfix and/or change are needed on xen. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5683034.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:29:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPv9N-0004hy-TC; Thu, 03 May 2012 12:28:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPv9M-0004hq-9s for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:28:48 +0000 Received: from [193.109.254.147:28432] by server-2.bemta-14.messagelabs.com id 3F/C1-19409-FF972AF4; Thu, 03 May 2012 12:28:47 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-4.tower-27.messagelabs.com!1336048125!7465237!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16645 invoked from network); 3 May 2012 12:28:46 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 12:28:46 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPv9I-0001F1-Jy for xen-devel@lists.xensource.com; Thu, 03 May 2012 05:28:44 -0700 Date: Thu, 3 May 2012 05:28:44 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336048124596-5683034.post@n5.nabble.com> In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org upstream-qemu-xen extra patches are included in upstream-qemu unstable (now at 1.1-rc0) I can run hvm domU correctly, on xen-unstable with xl, also with spice. Some info about my last test system: Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25249:a4e7fce6ee2b) vi Makefile # removed dist-kernel to not compile kernel ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb One domU xl configuration file: --------------------------------- XP.cfg ------------- name='XP' builder="hvm" memory=1024 vcpus=2 hap=1 pae=1 acpi=1 apic=1 nx=1 vif=['bridge=xenbr0'] #vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] disk=['/mnt/vm/disks/XP.disk1.xm,raw,hda,rw'] boot='cd' xen_platform_pci=1 viridian=1 device_model_version="qemu-xen" #vnc=1 #vncunused=1 #vnclisten="0.0.0.0" #keymap="it" spice=1 spicehost="0.0.0.0" spiceport=6000 spicedisable_ticketing=1 on_poweroff="destroy" on_reboot="restart" on_crash="destroy" stdvga=1 --------------------------------- About QXL I tried to add: stdvga=0 videoram=128 device_model_args=["-device","qxl-vga"] About qxl there are problems about videoram not allocated or not used over 4 mb (same as default cirrus vga). At the moment I haven't found solution for this problem, probably some bugfix and/or change are needed on xen. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5683034.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvBt-0004nc-Jb; Thu, 03 May 2012 12:31:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvBs-0004nU-Jn for xen-devel@lists.xen.org; Thu, 03 May 2012 12:31:24 +0000 Received: from [85.158.138.51:61720] by server-10.bemta-3.messagelabs.com id B9/59-29478-B9A72AF4; Thu, 03 May 2012 12:31:23 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336048281!25047547!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE5MTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11625 invoked from network); 3 May 2012 12:31:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="24813808" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 08:31:21 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 08:31:20 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPvBo-0000nA-CE; Thu, 03 May 2012 13:31:20 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 3 May 2012 13:31:17 +0100 Message-ID: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix qemu dm model destruction if the pid in xenstore is 0 (or is not present). Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 11de03f..b2bae68 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1081,6 +1081,11 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); if (!pid) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); + ret = ERROR_INVAL; + goto out; + } + if (!atoi(pid)) { int stubdomid = libxl_get_stubdom_id(ctx, domid); const char *savefile; @@ -1122,10 +1127,10 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) goto out; } } - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); out: + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); return ret; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvBt-0004nc-Jb; Thu, 03 May 2012 12:31:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvBs-0004nU-Jn for xen-devel@lists.xen.org; Thu, 03 May 2012 12:31:24 +0000 Received: from [85.158.138.51:61720] by server-10.bemta-3.messagelabs.com id B9/59-29478-B9A72AF4; Thu, 03 May 2012 12:31:23 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336048281!25047547!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE5MTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11625 invoked from network); 3 May 2012 12:31:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="24813808" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 08:31:21 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 08:31:20 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPvBo-0000nA-CE; Thu, 03 May 2012 13:31:20 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 3 May 2012 13:31:17 +0100 Message-ID: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix qemu dm model destruction if the pid in xenstore is 0 (or is not present). Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 11de03f..b2bae68 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1081,6 +1081,11 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); if (!pid) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); + ret = ERROR_INVAL; + goto out; + } + if (!atoi(pid)) { int stubdomid = libxl_get_stubdom_id(ctx, domid); const char *savefile; @@ -1122,10 +1127,10 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) goto out; } } - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); out: + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); return ret; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:39:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvJH-00051I-HJ; Thu, 03 May 2012 12:39:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvJG-00051D-8k for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:39:02 +0000 Received: from [85.158.143.35:52356] by server-1.bemta-4.messagelabs.com id D7/48-20925-56C72AF4; Thu, 03 May 2012 12:39:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336048740!14013155!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12379 invoked from network); 3 May 2012 12:39:00 -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; 3 May 2012 12:39:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12272980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:38: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; Thu, 3 May 2012 13:38:48 +0100 Date: Thu, 3 May 2012 13:46:16 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, ZhouPeng wrote: > On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > > > > Zhou Peng wrote > >> > >> Hi Fantu, > >> > >> Thanks for your response. > >> > >> xl doesn't support qxl-related option at the moment. > >> I will test upstream-qemu-xen these days, and if it works well > >> with qxl device, I will be glad to add qxl support to xl. > >> > > Hello, any news about this? > > Thanks in advance > > It seems you are using the upstream-qemu. > There are some special patches for upstream-qemu-xen(I don't track if all the > patches have been accepted by qemu) > > The git repos for upstream-qemu-xen: > Stefano Stabellini's tree: > git://xenbits.xen.org/people/sstabellini/qemu-dm.git > Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git > > I am watching upstream-qemu-xen's progress too, but I have not tracked > it for months. That is my personal tree. Now upstream QEMU is integrated in xen-unstable, so the tree that should be used is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > I was plan to test the latest upstream-qemu-xen and response to you, > but I encounter a problem when preparing the environment using the upstream xen: > # xl list > libxl: error: libxl.c:506:libxl_list_domain: geting domain info > list: Operation not permitted > libxl_domain_infolist failed. This looks like a basic setup issue. > So I suggest you to have a try of upstream-qemu-xen if not yet. > In my test many months ago, it didn't support graphic, and spice was tested > with linux-hvm disabling graphic. What do you mean by "disabling graphic"? Do you mean disabling the vga card? > How to configure upstream-qemu-xen: > ./configure --target-list=i386-softmmu --enable-spice > --enable-xen --extra-cflags=-I${path-to-xen}/dist/install/usr/include > --extra-ldflags=-L${path-to-xen}/dist/install/usr/lib > > CCing to Stefano, who may help you on upstream-qemu-xen. Yes, it is true that you need to add --enable-spice to the configure command line options. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:39:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvJH-00051I-HJ; Thu, 03 May 2012 12:39:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvJG-00051D-8k for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:39:02 +0000 Received: from [85.158.143.35:52356] by server-1.bemta-4.messagelabs.com id D7/48-20925-56C72AF4; Thu, 03 May 2012 12:39:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336048740!14013155!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12379 invoked from network); 3 May 2012 12:39:00 -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; 3 May 2012 12:39:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12272980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:38: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; Thu, 3 May 2012 13:38:48 +0100 Date: Thu, 3 May 2012 13:46:16 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, ZhouPeng wrote: > On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > > > > Zhou Peng wrote > >> > >> Hi Fantu, > >> > >> Thanks for your response. > >> > >> xl doesn't support qxl-related option at the moment. > >> I will test upstream-qemu-xen these days, and if it works well > >> with qxl device, I will be glad to add qxl support to xl. > >> > > Hello, any news about this? > > Thanks in advance > > It seems you are using the upstream-qemu. > There are some special patches for upstream-qemu-xen(I don't track if all the > patches have been accepted by qemu) > > The git repos for upstream-qemu-xen: > Stefano Stabellini's tree: > git://xenbits.xen.org/people/sstabellini/qemu-dm.git > Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git > > I am watching upstream-qemu-xen's progress too, but I have not tracked > it for months. That is my personal tree. Now upstream QEMU is integrated in xen-unstable, so the tree that should be used is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > I was plan to test the latest upstream-qemu-xen and response to you, > but I encounter a problem when preparing the environment using the upstream xen: > # xl list > libxl: error: libxl.c:506:libxl_list_domain: geting domain info > list: Operation not permitted > libxl_domain_infolist failed. This looks like a basic setup issue. > So I suggest you to have a try of upstream-qemu-xen if not yet. > In my test many months ago, it didn't support graphic, and spice was tested > with linux-hvm disabling graphic. What do you mean by "disabling graphic"? Do you mean disabling the vga card? > How to configure upstream-qemu-xen: > ./configure --target-list=i386-softmmu --enable-spice > --enable-xen --extra-cflags=-I${path-to-xen}/dist/install/usr/include > --extra-ldflags=-L${path-to-xen}/dist/install/usr/lib > > CCing to Stefano, who may help you on upstream-qemu-xen. Yes, it is true that you need to add --enable-spice to the configure command line options. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:50:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:50:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvU0-0005Bw-MC; Thu, 03 May 2012 12:50:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvTz-0005Br-RL for xen-devel@lists.xen.org; Thu, 03 May 2012 12:50:08 +0000 Received: from [193.109.254.147:11273] by server-2.bemta-14.messagelabs.com id 99/1B-19409-FFE72AF4; Thu, 03 May 2012 12:50:07 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336049405!599226!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7087 invoked from network); 3 May 2012 12:50:05 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:50:05 -0000 Received: by wgbed3 with SMTP id ed3so1273423wgb.32 for ; Thu, 03 May 2012 05:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n0V3UFk4+6PCToG+h8keJvO6Be+f2RgxBskCwFL/knM=; b=p37ROYNsULP1TakyCG/aOBZSUTltuA/WtJE/BZb4NGmbb9NG5acJ2GlDaATHFchx/O wEoYxrzeHpZI7IEN+3V8UpgdsCV6BqHVQDkP88LzwD98eKveqE55qQEu+ZK/gnoXDGUR nALdyn/kqRgClqCv9GiRtmDYKF0jJBb/RBMMLs7tv9jQKQBZVlfht2+wXLjDuKBOFCmi sZba8x0faViKS8RAjlzW39vYzYb9tLGiv1D2d5K/sB9vyDnG6m039QkPhOSSKf59uAKT ufXOlPiL0cKB06+8ba5/1JJusXoFMl3tZH4hzxD/UiEtrDS5k2Ts3us1/aLW5+nQkBb1 EKPA== MIME-Version: 1.0 Received: by 10.180.84.4 with SMTP id u4mr3161798wiy.2.1336049405092; Thu, 03 May 2012 05:50:05 -0700 (PDT) Received: by 10.223.157.129 with HTTP; Thu, 3 May 2012 05:50:04 -0700 (PDT) Date: Thu, 3 May 2012 20:50:04 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1196300607551140119==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1196300607551140119== Content-Type: multipart/alternative; boundary=f46d044303f431625704bf213e2b --f46d044303f431625704bf213e2b Content-Type: text/plain; charset=ISO-8859-1 Hi, When I make install-tools in Xen unstable source code directory, there is an error. The output is as the following. Please help me figure out this problem. Thank you very much. root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools make -C tools install make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C include install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' make -C xen-foreign make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' ./checker > tmp.size diff -u reference.size tmp.size rm tmp.size make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-ia64 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-ia64/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-x86 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-x86/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/foreign /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/io /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/sys /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/xsm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/COPYING //usr/include/xen /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/*.h //usr/include/xen /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia64/*.h //usr/include/xen/arch-ia64 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/*.h //usr/include/xen/arch-x86 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/foreign/*.h //usr/include/xen/foreign /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/hvm/*.h //usr/include/xen/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/io/*.h //usr/include/xen/io /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/sys/*.h //usr/include/xen/sys /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/xsm/*.h //usr/include/xen/xsm make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C libxc install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' make libs make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' make[4]: Nothing to be done for `libs'. make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/include /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxenctrl.so.4.2.0 //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p libxenctrl.a //usr/lib64 ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p xenctrl.h xenctrlosdep.h xentoollog.h //usr/include /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxenguest.so.4.2.0 //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p libxenguest.a //usr/lib64 ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p xenguest.h //usr/include make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C flask install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' make -C utils install make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/utils' gcc loadpolicy.o /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so -o flask-loadpolicy /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_key_create' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_once' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_getspecific' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_setspecific' collect2: ld returned 1 exit status make[5]: *** [flask-loadpolicy] Error 1 make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils' make[4]: *** [subdir-install-utils] Error 2 make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' make[2]: *** [subdir-install-flask] Error 2 make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make: *** [install-tools] Error 2 -- Best Regards, Bei Guan --f46d044303f431625704bf213e2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

When I make install-tools in Xen unstable= source code directory, there is an error. The output is as the following. = Please help me figure out this problem. Thank you very much.

root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools
make -C tools install
make[1]: Entering directory `/root/Xe= n/xen-unstable.hg/tools'
make[2]: Entering directory `/root/X= en/xen-unstable.hg/tools'
make -C include install
make[3]: Entering directory `/root/X= en/xen-unstable.hg/tools/include'
make -C xen-foreign
make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/include/xen= -foreign'
./checker > tmp.size
diff -u reference.size tmp.size
rm tmp.size
make[4]: Leaving directory `/root/Xen/xen-unsta= ble.hg/tools/include/xen-foreign'
/root/Xen/xen-unstable.hg/t= ools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-= ia64
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/arch-ia64/hvm
/root/Xen/xen-unstable.h= g/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/ar= ch-x86
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/arch-x86/hvm
/root/Xen/xen-unstable.hg= /tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/for= eign
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/hvm
/root/Xen/xen-unstable.hg/tools/in= clude/../../tools/cross-install -d -m0755 -p //usr/include/xen/io
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/sys
/root/Xen/xen-unstable.hg/tools/in= clude/../../tools/cross-install -d -m0755 -p //usr/include/xen/xsm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/COPYING //usr/include/xen
/root/Xen/xen-unstable.hg/too= ls/include/../../tools/cross-install -m0644 -p xen/*.h //usr/include/xen
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/arch-ia64/*.h //usr/include/xen/arch-ia64
/root/Xen/xen= -unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia6= 4/hvm/*.h //usr/include/xen/arch-ia64/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/arch-x86/*.h //usr/include/xen/arch-x86
/root/Xen/xen-u= nstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/h= vm/*.h //usr/include/xen/arch-x86/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/foreign/*.h //usr/include/xen/foreign
/root/Xen/xen-uns= table.hg/tools/include/../../tools/cross-install -m0644 -p xen/hvm/*.h //us= r/include/xen/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/io/*.h //usr/include/xen/io
/root/Xen/xen-unstable.hg/t= ools/include/../../tools/cross-install -m0644 -p xen/sys/*.h //usr/include/= xen/sys
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/xsm/*.h //usr/include/xen/xsm
make[3]: Leaving director= y `/root/Xen/xen-unstable.hg/tools/include'
make[2]: Leaving = directory `/root/Xen/xen-unstable.hg/tools'
make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
make -C libxc install
make[3]: Entering directory `/root/Xe= n/xen-unstable.hg/tools/libxc'
make libs
make[4]: E= ntering directory `/root/Xen/xen-unstable.hg/tools/libxc'
make[4]: Nothing to be done for `libs'.
make[4]: Leaving= directory `/root/Xen/xen-unstable.hg/tools/libxc'
/root/Xen/= xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/li= b64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p //usr/include
/root/Xen/xen-unstable.hg/tools/libxc/../../= tools/cross-install -m0755 -p libxenctrl.so.4.2.0 //usr/lib64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p l= ibxenctrl.a //usr/lib64
ln -sf libxenctrl.so.4.2.0 //usr/lib64/li= bxenctrl.so.4.2
ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.s= o
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p xenctrl.h xenctrlosdep.h xentoollog.h //usr/include
/root/Xen= /xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxengues= t.so.4.2.0 //usr/lib64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p libxenguest.a //usr/lib64
ln -sf libxenguest.so.4.2.0 //usr/l= ib64/libxenguest.so.4.2
ln -sf libxenguest.so.4.2 //usr/lib64/lib= xenguest.so
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p xenguest.h //usr/include
make[3]: Leaving directory `/root/Xe= n/xen-unstable.hg/tools/libxc'
make[2]: Leaving directory `/r= oot/Xen/xen-unstable.hg/tools'
make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
make -C flask install
make[3]: Entering directory `/root/Xe= n/xen-unstable.hg/tools/flask'
make[4]: Entering directory `/= root/Xen/xen-unstable.hg/tools/flask'
make -C utils install
make[5]: Entering directory `/root/Xen= /xen-unstable.hg/tools/flask/utils'
gcc =A0 =A0 loadpolicy.o = =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenc= trl.so -o flask-loadpolicy
/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so: undefined reference to `pthread_key_create'
/root/X= en/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: un= defined reference to `pthread_once'
/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so: undefined reference to `pthread_getspecific'
/root/= Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: u= ndefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
make[5]: *** [flask-load= policy] Error 1
make[5]: Leaving directory `/root/Xen/xen-unstabl= e.hg/tools/flask/utils'
make[4]: *** [subdir-install-utils] E= rror 2
make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
make[3]: *** [subdirs-install] Error 2
make[3]: Leavin= g directory `/root/Xen/xen-unstable.hg/tools/flask'
make[2]: = *** [subdir-install-flask] Error 2
make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
=
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving dire= ctory `/root/Xen/xen-unstable.hg/tools'
make: *** [install-to= ols] Error 2

=A0



--
Best Regards,
Bei Guan

--f46d044303f431625704bf213e2b-- --===============1196300607551140119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1196300607551140119==-- From xen-devel-bounces@lists.xen.org Thu May 03 12:50:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:50:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvU0-0005Bw-MC; Thu, 03 May 2012 12:50:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvTz-0005Br-RL for xen-devel@lists.xen.org; Thu, 03 May 2012 12:50:08 +0000 Received: from [193.109.254.147:11273] by server-2.bemta-14.messagelabs.com id 99/1B-19409-FFE72AF4; Thu, 03 May 2012 12:50:07 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336049405!599226!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7087 invoked from network); 3 May 2012 12:50:05 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:50:05 -0000 Received: by wgbed3 with SMTP id ed3so1273423wgb.32 for ; Thu, 03 May 2012 05:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n0V3UFk4+6PCToG+h8keJvO6Be+f2RgxBskCwFL/knM=; b=p37ROYNsULP1TakyCG/aOBZSUTltuA/WtJE/BZb4NGmbb9NG5acJ2GlDaATHFchx/O wEoYxrzeHpZI7IEN+3V8UpgdsCV6BqHVQDkP88LzwD98eKveqE55qQEu+ZK/gnoXDGUR nALdyn/kqRgClqCv9GiRtmDYKF0jJBb/RBMMLs7tv9jQKQBZVlfht2+wXLjDuKBOFCmi sZba8x0faViKS8RAjlzW39vYzYb9tLGiv1D2d5K/sB9vyDnG6m039QkPhOSSKf59uAKT ufXOlPiL0cKB06+8ba5/1JJusXoFMl3tZH4hzxD/UiEtrDS5k2Ts3us1/aLW5+nQkBb1 EKPA== MIME-Version: 1.0 Received: by 10.180.84.4 with SMTP id u4mr3161798wiy.2.1336049405092; Thu, 03 May 2012 05:50:05 -0700 (PDT) Received: by 10.223.157.129 with HTTP; Thu, 3 May 2012 05:50:04 -0700 (PDT) Date: Thu, 3 May 2012 20:50:04 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1196300607551140119==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1196300607551140119== Content-Type: multipart/alternative; boundary=f46d044303f431625704bf213e2b --f46d044303f431625704bf213e2b Content-Type: text/plain; charset=ISO-8859-1 Hi, When I make install-tools in Xen unstable source code directory, there is an error. The output is as the following. Please help me figure out this problem. Thank you very much. root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools make -C tools install make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C include install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' make -C xen-foreign make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' ./checker > tmp.size diff -u reference.size tmp.size rm tmp.size make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-ia64 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-ia64/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-x86 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-x86/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/foreign /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/io /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/sys /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/xsm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/COPYING //usr/include/xen /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/*.h //usr/include/xen /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia64/*.h //usr/include/xen/arch-ia64 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/*.h //usr/include/xen/arch-x86 /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/foreign/*.h //usr/include/xen/foreign /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/hvm/*.h //usr/include/xen/hvm /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/io/*.h //usr/include/xen/io /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/sys/*.h //usr/include/xen/sys /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/xsm/*.h //usr/include/xen/xsm make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C libxc install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' make libs make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' make[4]: Nothing to be done for `libs'. make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/include /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxenctrl.so.4.2.0 //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p libxenctrl.a //usr/lib64 ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p xenctrl.h xenctrlosdep.h xentoollog.h //usr/include /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxenguest.so.4.2.0 //usr/lib64 /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p libxenguest.a //usr/lib64 ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p xenguest.h //usr/include make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' make -C flask install make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' make -C utils install make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/utils' gcc loadpolicy.o /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so -o flask-loadpolicy /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_key_create' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_once' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_getspecific' /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: undefined reference to `pthread_setspecific' collect2: ld returned 1 exit status make[5]: *** [flask-loadpolicy] Error 1 make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils' make[4]: *** [subdir-install-utils] Error 2 make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' make[2]: *** [subdir-install-flask] Error 2 make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' make: *** [install-tools] Error 2 -- Best Regards, Bei Guan --f46d044303f431625704bf213e2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

When I make install-tools in Xen unstable= source code directory, there is an error. The output is as the following. = Please help me figure out this problem. Thank you very much.

root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools
make -C tools install
make[1]: Entering directory `/root/Xe= n/xen-unstable.hg/tools'
make[2]: Entering directory `/root/X= en/xen-unstable.hg/tools'
make -C include install
make[3]: Entering directory `/root/X= en/xen-unstable.hg/tools/include'
make -C xen-foreign
make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/include/xen= -foreign'
./checker > tmp.size
diff -u reference.size tmp.size
rm tmp.size
make[4]: Leaving directory `/root/Xen/xen-unsta= ble.hg/tools/include/xen-foreign'
/root/Xen/xen-unstable.hg/t= ools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/arch-= ia64
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/arch-ia64/hvm
/root/Xen/xen-unstable.h= g/tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/ar= ch-x86
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/arch-x86/hvm
/root/Xen/xen-unstable.hg= /tools/include/../../tools/cross-install -d -m0755 -p //usr/include/xen/for= eign
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/hvm
/root/Xen/xen-unstable.hg/tools/in= clude/../../tools/cross-install -d -m0755 -p //usr/include/xen/io
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755 -p //usr/include/xen/sys
/root/Xen/xen-unstable.hg/tools/in= clude/../../tools/cross-install -d -m0755 -p //usr/include/xen/xsm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/COPYING //usr/include/xen
/root/Xen/xen-unstable.hg/too= ls/include/../../tools/cross-install -m0644 -p xen/*.h //usr/include/xen
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/arch-ia64/*.h //usr/include/xen/arch-ia64
/root/Xen/xen= -unstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-ia6= 4/hvm/*.h //usr/include/xen/arch-ia64/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/arch-x86/*.h //usr/include/xen/arch-x86
/root/Xen/xen-u= nstable.hg/tools/include/../../tools/cross-install -m0644 -p xen/arch-x86/h= vm/*.h //usr/include/xen/arch-x86/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/foreign/*.h //usr/include/xen/foreign
/root/Xen/xen-uns= table.hg/tools/include/../../tools/cross-install -m0644 -p xen/hvm/*.h //us= r/include/xen/hvm
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/io/*.h //usr/include/xen/io
/root/Xen/xen-unstable.hg/t= ools/include/../../tools/cross-install -m0644 -p xen/sys/*.h //usr/include/= xen/sys
/root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p xen/xsm/*.h //usr/include/xen/xsm
make[3]: Leaving director= y `/root/Xen/xen-unstable.hg/tools/include'
make[2]: Leaving = directory `/root/Xen/xen-unstable.hg/tools'
make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
make -C libxc install
make[3]: Entering directory `/root/Xe= n/xen-unstable.hg/tools/libxc'
make libs
make[4]: E= ntering directory `/root/Xen/xen-unstable.hg/tools/libxc'
make[4]: Nothing to be done for `libs'.
make[4]: Leaving= directory `/root/Xen/xen-unstable.hg/tools/libxc'
/root/Xen/= xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755 -p //usr/li= b64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p //usr/include
/root/Xen/xen-unstable.hg/tools/libxc/../../= tools/cross-install -m0755 -p libxenctrl.so.4.2.0 //usr/lib64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p l= ibxenctrl.a //usr/lib64
ln -sf libxenctrl.so.4.2.0 //usr/lib64/li= bxenctrl.so.4.2
ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.s= o
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p xenctrl.h xenctrlosdep.h xentoollog.h //usr/include
/root/Xen= /xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p libxengues= t.so.4.2.0 //usr/lib64
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p libxenguest.a //usr/lib64
ln -sf libxenguest.so.4.2.0 //usr/l= ib64/libxenguest.so.4.2
ln -sf libxenguest.so.4.2 //usr/lib64/lib= xenguest.so
/root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p xenguest.h //usr/include
make[3]: Leaving directory `/root/Xe= n/xen-unstable.hg/tools/libxc'
make[2]: Leaving directory `/r= oot/Xen/xen-unstable.hg/tools'
make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
make -C flask install
make[3]: Entering directory `/root/Xe= n/xen-unstable.hg/tools/flask'
make[4]: Entering directory `/= root/Xen/xen-unstable.hg/tools/flask'
make -C utils install
make[5]: Entering directory `/root/Xen= /xen-unstable.hg/tools/flask/utils'
gcc =A0 =A0 loadpolicy.o = =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenc= trl.so -o flask-loadpolicy
/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so: undefined reference to `pthread_key_create'
/root/X= en/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: un= defined reference to `pthread_once'
/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so: undefined reference to `pthread_getspecific'
/root/= Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenctrl.so: u= ndefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
make[5]: *** [flask-load= policy] Error 1
make[5]: Leaving directory `/root/Xen/xen-unstabl= e.hg/tools/flask/utils'
make[4]: *** [subdir-install-utils] E= rror 2
make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
make[3]: *** [subdirs-install] Error 2
make[3]: Leavin= g directory `/root/Xen/xen-unstable.hg/tools/flask'
make[2]: = *** [subdir-install-flask] Error 2
make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
=
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving dire= ctory `/root/Xen/xen-unstable.hg/tools'
make: *** [install-to= ols] Error 2

=A0



--
Best Regards,
Bei Guan

--f46d044303f431625704bf213e2b-- --===============1196300607551140119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1196300607551140119==-- From xen-devel-bounces@lists.xen.org Thu May 03 12:57:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:57:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvaR-0005M4-PG; Thu, 03 May 2012 12:56:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvaQ-0005Lx-4u for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:56:46 +0000 Received: from [85.158.143.99:48170] by server-1.bemta-4.messagelabs.com id 85/C3-20925-D8082AF4; Thu, 03 May 2012 12:56:45 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336049802!26355222!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3427 invoked from network); 3 May 2012 12:56:43 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:56:43 -0000 Received: by obfk16 with SMTP id k16so3404216obf.30 for ; Thu, 03 May 2012 05:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sXvIBMtWaWAEXmh3KTx27Fhi/54s/j4S//fAjmbYxKI=; b=ZAd0evSHsYSV9HuGJ+RYmh13EqoSdTDNGGR4EdLZeOX/M3OgHpLvOtT5rUmxgzls3g w8UR38v5R/Iqomz/RpPJ3oJ3Nfs8izqYEgAjs1c+OcgbkMeAmbKMQSsOuDo3skpaKVNn 1Bhoek/FNPctPyjDKUJ5lXvS3qFykerCtWoU2FnbTXUaOaNVabh0IWpOgWpKWXz9jwHB r0cXr2+hHHOs8rOBcWWPZujlD04modQcTs3zA6rZeIYqbto1V1JLoT5Xd7i1g1Yv4XQV FmSo4iLStFXEj86r4ugMAG8yTXMIZsmmfiAmTi3S28jc2DXlx1X2rsUesI1QW2VI4Plu 737A== MIME-Version: 1.0 Received: by 10.182.38.1 with SMTP id c1mr2782927obk.18.1336049801199; Thu, 03 May 2012 05:56:41 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 05:56:41 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 20:56:41 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: >> > >> > Zhou Peng wrote >> >> >> >> Hi Fantu, >> >> >> >> Thanks for your response. >> >> >> >> xl doesn't support qxl-related option at the moment. >> >> I will test upstream-qemu-xen these days, and if it works well >> >> with qxl device, I will be glad to add qxl support to xl. >> >> >> > Hello, any news about this? >> > Thanks in advance >> >> It seems you are using the upstream-qemu. >> There are some special patches for upstream-qemu-xen(I don't track if al= l the >> patches have been accepted by qemu) >> >> The git repos for upstream-qemu-xen: >> =A0 Stefano Stabellini's tree: >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git >> =A0 Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git >> >> I am watching upstream-qemu-xen's progress too, but I have not tracked >> it for months. > > That is my personal tree. Now upstream QEMU is integrated in > xen-unstable, so the tree that should be used > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > > >> I was plan to test the latest upstream-qemu-xen and response to you, >> but I encounter a problem when preparing the environment using the upstr= eam xen: >> =A0 # xl list >> =A0 libxl: error: libxl.c:506:libxl_list_domain: geting domain info >> list: Operation not permitted >> =A0 libxl_domain_infolist failed. > > This looks like a basic setup issue. > > >> So I suggest you =A0to have a try of upstream-qemu-xen if not yet. >> In my test many months ago, it didn't support graphic, and spice was tes= ted >> with linux-hvm disabling graphic. > > What do you mean by "disabling graphic"? Do you mean disabling the vga > card? No, not disable the vga card. But booting in Text mode. > >> How to configure upstream-qemu-xen: >> ./configure --target-list=3Di386-softmmu --enable-spice >> =A0 =A0--enable-xen --extra-cflags=3D-I${path-to-xen}/dist/install/usr/i= nclude >> =A0 =A0--extra-ldflags=3D-L${path-to-xen}/dist/install/usr/lib >> >> CCing to Stefano, who may help you on upstream-qemu-xen. > > Yes, it is true that you need to add --enable-spice to the configure > command line options. -- = Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:57:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:57:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvaR-0005M4-PG; Thu, 03 May 2012 12:56:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvaQ-0005Lx-4u for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:56:46 +0000 Received: from [85.158.143.99:48170] by server-1.bemta-4.messagelabs.com id 85/C3-20925-D8082AF4; Thu, 03 May 2012 12:56:45 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336049802!26355222!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3427 invoked from network); 3 May 2012 12:56:43 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 12:56:43 -0000 Received: by obfk16 with SMTP id k16so3404216obf.30 for ; Thu, 03 May 2012 05:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sXvIBMtWaWAEXmh3KTx27Fhi/54s/j4S//fAjmbYxKI=; b=ZAd0evSHsYSV9HuGJ+RYmh13EqoSdTDNGGR4EdLZeOX/M3OgHpLvOtT5rUmxgzls3g w8UR38v5R/Iqomz/RpPJ3oJ3Nfs8izqYEgAjs1c+OcgbkMeAmbKMQSsOuDo3skpaKVNn 1Bhoek/FNPctPyjDKUJ5lXvS3qFykerCtWoU2FnbTXUaOaNVabh0IWpOgWpKWXz9jwHB r0cXr2+hHHOs8rOBcWWPZujlD04modQcTs3zA6rZeIYqbto1V1JLoT5Xd7i1g1Yv4XQV FmSo4iLStFXEj86r4ugMAG8yTXMIZsmmfiAmTi3S28jc2DXlx1X2rsUesI1QW2VI4Plu 737A== MIME-Version: 1.0 Received: by 10.182.38.1 with SMTP id c1mr2782927obk.18.1336049801199; Thu, 03 May 2012 05:56:41 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 05:56:41 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 20:56:41 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: >> > >> > Zhou Peng wrote >> >> >> >> Hi Fantu, >> >> >> >> Thanks for your response. >> >> >> >> xl doesn't support qxl-related option at the moment. >> >> I will test upstream-qemu-xen these days, and if it works well >> >> with qxl device, I will be glad to add qxl support to xl. >> >> >> > Hello, any news about this? >> > Thanks in advance >> >> It seems you are using the upstream-qemu. >> There are some special patches for upstream-qemu-xen(I don't track if al= l the >> patches have been accepted by qemu) >> >> The git repos for upstream-qemu-xen: >> =A0 Stefano Stabellini's tree: >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git >> =A0 Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git >> >> I am watching upstream-qemu-xen's progress too, but I have not tracked >> it for months. > > That is my personal tree. Now upstream QEMU is integrated in > xen-unstable, so the tree that should be used > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > > >> I was plan to test the latest upstream-qemu-xen and response to you, >> but I encounter a problem when preparing the environment using the upstr= eam xen: >> =A0 # xl list >> =A0 libxl: error: libxl.c:506:libxl_list_domain: geting domain info >> list: Operation not permitted >> =A0 libxl_domain_infolist failed. > > This looks like a basic setup issue. > > >> So I suggest you =A0to have a try of upstream-qemu-xen if not yet. >> In my test many months ago, it didn't support graphic, and spice was tes= ted >> with linux-hvm disabling graphic. > > What do you mean by "disabling graphic"? Do you mean disabling the vga > card? No, not disable the vga card. But booting in Text mode. > >> How to configure upstream-qemu-xen: >> ./configure --target-list=3Di386-softmmu --enable-spice >> =A0 =A0--enable-xen --extra-cflags=3D-I${path-to-xen}/dist/install/usr/i= nclude >> =A0 =A0--extra-ldflags=3D-L${path-to-xen}/dist/install/usr/lib >> >> CCing to Stefano, who may help you on upstream-qemu-xen. > > Yes, it is true that you need to add --enable-spice to the configure > command line options. -- = Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 12:58:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPvbe-0005Pu-8H; Thu, 03 May 2012 12:58:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvbc-0005Pj-2O for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:58:00 +0000 Received: from [85.158.138.51:21067] by server-8.bemta-3.messagelabs.com id FD/33-24428-7D082AF4; Thu, 03 May 2012 12:57:59 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336049878!25060096!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2913 invoked from network); 3 May 2012 12:57:58 -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 May 2012 12:57:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12273540" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:57: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, 3 May 2012 13:57:58 +0100 Date: Thu, 3 May 2012 14:05:26 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-963175513-1336050342=:26786" Cc: "xen-devel@lists.xensource.com" , Fantu , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --8323329-963175513-1336050342=:26786 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Thu, 3 May 2012, ZhouPeng wrote: > On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini > wrote: > > On Thu, 3 May 2012, ZhouPeng wrote: > >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > >> > > >> > Zhou Peng wrote > >> >> > >> >> Hi Fantu, > >> >> > >> >> Thanks for your response. > >> >> > >> >> xl doesn't support qxl-related option at the moment. > >> >> I will test upstream-qemu-xen these days, and if it works well > >> >> with qxl device, I will be glad to add qxl support to xl. > >> >> > >> > Hello, any news about this? > >> > Thanks in advance > >> > >> It seems you are using the upstream-qemu. > >> There are some special patches for upstream-qemu-xen(I don't track if all the > >> patches have been accepted by qemu) > >> > >> The git repos for upstream-qemu-xen: > >>   Stefano Stabellini's tree: > >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git > >>   Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git > >> > >> I am watching upstream-qemu-xen's progress too, but I have not tracked > >> it for months. > > > > That is my personal tree. Now upstream QEMU is integrated in > > xen-unstable, so the tree that should be used > > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > > > > > >> I was plan to test the latest upstream-qemu-xen and response to you, > >> but I encounter a problem when preparing the environment using the upstream xen: > >>   # xl list > >>   libxl: error: libxl.c:506:libxl_list_domain: geting domain info > >> list: Operation not permitted > >>   libxl_domain_infolist failed. > > > > This looks like a basic setup issue. > > > > > >> So I suggest you  to have a try of upstream-qemu-xen if not yet. > >> In my test many months ago, it didn't support graphic, and spice was tested > >> with linux-hvm disabling graphic. > > > > What do you mean by "disabling graphic"? Do you mean disabling the vga > > card? > No, not disable the vga card. > But booting in Text mode. Then you are manually starting X11 with the spice driver? --8323329-963175513-1336050342=:26786 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --8323329-963175513-1336050342=:26786-- From xen-devel-bounces@lists.xen.org Thu May 03 12:58:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12: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 ) id 1SPvbe-0005Pu-8H; Thu, 03 May 2012 12:58:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvbc-0005Pj-2O for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:58:00 +0000 Received: from [85.158.138.51:21067] by server-8.bemta-3.messagelabs.com id FD/33-24428-7D082AF4; Thu, 03 May 2012 12:57:59 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336049878!25060096!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2913 invoked from network); 3 May 2012 12:57:58 -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 May 2012 12:57:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12273540" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:57: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, 3 May 2012 13:57:58 +0100 Date: Thu, 3 May 2012 14:05:26 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-963175513-1336050342=:26786" Cc: "xen-devel@lists.xensource.com" , Fantu , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --8323329-963175513-1336050342=:26786 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Thu, 3 May 2012, ZhouPeng wrote: > On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini > wrote: > > On Thu, 3 May 2012, ZhouPeng wrote: > >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: > >> > > >> > Zhou Peng wrote > >> >> > >> >> Hi Fantu, > >> >> > >> >> Thanks for your response. > >> >> > >> >> xl doesn't support qxl-related option at the moment. > >> >> I will test upstream-qemu-xen these days, and if it works well > >> >> with qxl device, I will be glad to add qxl support to xl. > >> >> > >> > Hello, any news about this? > >> > Thanks in advance > >> > >> It seems you are using the upstream-qemu. > >> There are some special patches for upstream-qemu-xen(I don't track if all the > >> patches have been accepted by qemu) > >> > >> The git repos for upstream-qemu-xen: > >>   Stefano Stabellini's tree: > >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git > >>   Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git > >> > >> I am watching upstream-qemu-xen's progress too, but I have not tracked > >> it for months. > > > > That is my personal tree. Now upstream QEMU is integrated in > > xen-unstable, so the tree that should be used > > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git > > > > > >> I was plan to test the latest upstream-qemu-xen and response to you, > >> but I encounter a problem when preparing the environment using the upstream xen: > >>   # xl list > >>   libxl: error: libxl.c:506:libxl_list_domain: geting domain info > >> list: Operation not permitted > >>   libxl_domain_infolist failed. > > > > This looks like a basic setup issue. > > > > > >> So I suggest you  to have a try of upstream-qemu-xen if not yet. > >> In my test many months ago, it didn't support graphic, and spice was tested > >> with linux-hvm disabling graphic. > > > > What do you mean by "disabling graphic"? Do you mean disabling the vga > > card? > No, not disable the vga card. > But booting in Text mode. Then you are manually starting X11 with the spice driver? --8323329-963175513-1336050342=:26786 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --8323329-963175513-1336050342=:26786-- From xen-devel-bounces@lists.xen.org Thu May 03 12:58:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvc2-0005Rz-Pd; Thu, 03 May 2012 12:58:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvc1-0005Rn-Lo for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:58:25 +0000 Received: from [193.109.254.147:42633] by server-10.bemta-14.messagelabs.com id AB/44-05847-0F082AF4; Thu, 03 May 2012 12:58:24 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336049886!643055!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32233 invoked from network); 3 May 2012 12:58:06 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-15.tower-27.messagelabs.com with SMTP; 3 May 2012 12:58:06 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPvbg-0000U7-O8; Thu, 03 May 2012 12:58:04 +0000 Message-ID: <4FA280DA.9080505@canonical.com> Date: Thu, 03 May 2012 14:58:02 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> In-Reply-To: <4FA1B096.5010009@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7483904360065399984==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7483904360065399984== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC439D14FE923CC3E0AE06D48" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC439D14FE923CC3E0AE06D48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 00:09, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>> index a8f8844..d816448 100644 >>>>>> --- a/arch/x86/xen/enlighten.c >>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>> static u32 xen_apic_read(u32 reg) >>>>>> { >>>>>> - return 0; >>>>>> + struct xen_platform_op op =3D { >>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>> >>>>> >>>>> Is this always zero? This will probably solve the current problem >>>> >>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>> >>> Why not use CPU number instead of zero here? >> >> The issue was only with the bootup CPU - so was using the Xen's >> bootup CPU number - which is zero (as is Linux's). >=20 > I agree that for this particular problem this may be sufficient. >=20 > My concern is that in the future someone may decide to use apic_read(AP= IC_ID) or > read_apic_id() for some other purpose and they won't get expected resul= t (i.e. > on all CPUs they will get the same answer). >=20 >> >>> >>>> >>>>> but I am wondering whether in the future we might hit another bug >>>>> because this routine will return the same APICID for all VCPUs. >>>> >>>> Later on it does a check for 'smp_processor_id()' - and if >>>> that is anything but zero it will bail out. >>> >>> Can you point me to the check you are referring to? >> >> if (!xen_initial_domain() || smp_processor_id()) >=20 > I don't see this line --- neither in the mainline nor in your kernel. W= hich > kernel and which routine is this in? >=20 > BTW, this patch doesn't quite work, xen-acpi-processor driver fails to = load with > the same error as before. I'll look at this tomorrow more carefully. >=20 >=20 > -boris >=20 >> >> >>> >>> -boris >>> >>> >>>> >>>> So this shoudl solve the problem for the bootup processor. >>>>> >>>>> -boris >>>>> >>>>> >>>>>> + }; >>>>>> + int ret =3D 0; >>>>>> + >>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we o= nly >>>>>> + * get called on the bootup processor. But just in case. */ >>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>> + return 0; >>>>>> + >>>>>> + if (reg =3D=3D APIC_LVR) >>>>>> + return 0x10; >>>>>> + >>>>>> + if (reg !=3D APIC_ID) >>>>>> + return 0; >>>>>> + >>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>> + if (ret) >>>>>> + return 0; >>>>>> + >>>>>> + return op.u.pcpu_info.apic_id; >>>>>> } >>>>>> >>>>>> static void xen_apic_write(u32 reg, u32 val) I added debugging to all exit paths that could return 0 (which is what th= e boot_cpu_physical_apicid is set to with that patch. Which would only leav= e the case of the HV call returning the wrong value somehow... >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enigC439D14FE923CC3E0AE06D48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPooDaAAoJEOhnXe7L7s6jqgYQAINa5QM4Mko8dQqD0gUMSxwf +GZdh31C3o/yY1z9lIIFSSOqUlgwCHy9+dYv+yrIY1LvcE7tw4XhtAdxCWDDU1fg leB0beMdPK9fbAKx0VWCfiwuZCrwHo+5VT62z/PQ3M2/LQVaoTXWBEQDRtntEzXY i0LqTjPFcBN0EVGhnCXFkqO0+P5XWseTwnh2/6o+iKlaTAzI2/M+ntx27h7w3Pgl nox25mxXCrHGkE+7s5LsbD/C5rMmZuhk8CNst7aG9Xm3fMcPn2KtnGjt/uK4tNSU BA8hcStTJoD42dF3kqYIDMvnpc3OSdptcMgbsS3Wo2zCC83kf8OgKR3RiY9F1hiE CpjEHfMLJQyGV10qe9uAC5oZnonpMAtUSlgKZsXmyCtqlbT/HOy/lkXAuLnsnaf1 q8S7c5mtCHlkN6r+zVzjNZoTCVxRWvHkol5Nbix2IRNENeUvPgF3x1xfya9ymQhT hNjwkZakjt9CFjoLsfD7QFZ0nN5HQQy0Txp5k3tSKc6croSWS2/CLM/hRMec563/ xcFVlxgv8MIRNJtMsWfTnJY9FZBzCVbRuKPOy72b9yuzrueJBwpq9Bcfw04FpAiB /NNUZnhIVicMizUUdC+/62d+9627FRvz7fF8paOwSVqY31GHf1535C5NZsfcF47x foNqJfqdOMpoUh/9sea6 =FQCk -----END PGP SIGNATURE----- --------------enigC439D14FE923CC3E0AE06D48-- --===============7483904360065399984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7483904360065399984==-- From xen-devel-bounces@lists.xen.org Thu May 03 12:58:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 12:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvc2-0005Rz-Pd; Thu, 03 May 2012 12:58:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvc1-0005Rn-Lo for xen-devel@lists.xensource.com; Thu, 03 May 2012 12:58:25 +0000 Received: from [193.109.254.147:42633] by server-10.bemta-14.messagelabs.com id AB/44-05847-0F082AF4; Thu, 03 May 2012 12:58:24 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336049886!643055!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32233 invoked from network); 3 May 2012 12:58:06 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-15.tower-27.messagelabs.com with SMTP; 3 May 2012 12:58:06 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPvbg-0000U7-O8; Thu, 03 May 2012 12:58:04 +0000 Message-ID: <4FA280DA.9080505@canonical.com> Date: Thu, 03 May 2012 14:58:02 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> In-Reply-To: <4FA1B096.5010009@amd.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7483904360065399984==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7483904360065399984== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC439D14FE923CC3E0AE06D48" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC439D14FE923CC3E0AE06D48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 00:09, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>> index a8f8844..d816448 100644 >>>>>> --- a/arch/x86/xen/enlighten.c >>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>> static u32 xen_apic_read(u32 reg) >>>>>> { >>>>>> - return 0; >>>>>> + struct xen_platform_op op =3D { >>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>> >>>>> >>>>> Is this always zero? This will probably solve the current problem >>>> >>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>> >>> Why not use CPU number instead of zero here? >> >> The issue was only with the bootup CPU - so was using the Xen's >> bootup CPU number - which is zero (as is Linux's). >=20 > I agree that for this particular problem this may be sufficient. >=20 > My concern is that in the future someone may decide to use apic_read(AP= IC_ID) or > read_apic_id() for some other purpose and they won't get expected resul= t (i.e. > on all CPUs they will get the same answer). >=20 >> >>> >>>> >>>>> but I am wondering whether in the future we might hit another bug >>>>> because this routine will return the same APICID for all VCPUs. >>>> >>>> Later on it does a check for 'smp_processor_id()' - and if >>>> that is anything but zero it will bail out. >>> >>> Can you point me to the check you are referring to? >> >> if (!xen_initial_domain() || smp_processor_id()) >=20 > I don't see this line --- neither in the mainline nor in your kernel. W= hich > kernel and which routine is this in? >=20 > BTW, this patch doesn't quite work, xen-acpi-processor driver fails to = load with > the same error as before. I'll look at this tomorrow more carefully. >=20 >=20 > -boris >=20 >> >> >>> >>> -boris >>> >>> >>>> >>>> So this shoudl solve the problem for the bootup processor. >>>>> >>>>> -boris >>>>> >>>>> >>>>>> + }; >>>>>> + int ret =3D 0; >>>>>> + >>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we o= nly >>>>>> + * get called on the bootup processor. But just in case. */ >>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>> + return 0; >>>>>> + >>>>>> + if (reg =3D=3D APIC_LVR) >>>>>> + return 0x10; >>>>>> + >>>>>> + if (reg !=3D APIC_ID) >>>>>> + return 0; >>>>>> + >>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>> + if (ret) >>>>>> + return 0; >>>>>> + >>>>>> + return op.u.pcpu_info.apic_id; >>>>>> } >>>>>> >>>>>> static void xen_apic_write(u32 reg, u32 val) I added debugging to all exit paths that could return 0 (which is what th= e boot_cpu_physical_apicid is set to with that patch. Which would only leav= e the case of the HV call returning the wrong value somehow... >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enigC439D14FE923CC3E0AE06D48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPooDaAAoJEOhnXe7L7s6jqgYQAINa5QM4Mko8dQqD0gUMSxwf +GZdh31C3o/yY1z9lIIFSSOqUlgwCHy9+dYv+yrIY1LvcE7tw4XhtAdxCWDDU1fg leB0beMdPK9fbAKx0VWCfiwuZCrwHo+5VT62z/PQ3M2/LQVaoTXWBEQDRtntEzXY i0LqTjPFcBN0EVGhnCXFkqO0+P5XWseTwnh2/6o+iKlaTAzI2/M+ntx27h7w3Pgl nox25mxXCrHGkE+7s5LsbD/C5rMmZuhk8CNst7aG9Xm3fMcPn2KtnGjt/uK4tNSU BA8hcStTJoD42dF3kqYIDMvnpc3OSdptcMgbsS3Wo2zCC83kf8OgKR3RiY9F1hiE CpjEHfMLJQyGV10qe9uAC5oZnonpMAtUSlgKZsXmyCtqlbT/HOy/lkXAuLnsnaf1 q8S7c5mtCHlkN6r+zVzjNZoTCVxRWvHkol5Nbix2IRNENeUvPgF3x1xfya9ymQhT hNjwkZakjt9CFjoLsfD7QFZ0nN5HQQy0Txp5k3tSKc6croSWS2/CLM/hRMec563/ xcFVlxgv8MIRNJtMsWfTnJY9FZBzCVbRuKPOy72b9yuzrueJBwpq9Bcfw04FpAiB /NNUZnhIVicMizUUdC+/62d+9627FRvz7fF8paOwSVqY31GHf1535C5NZsfcF47x foNqJfqdOMpoUh/9sea6 =FQCk -----END PGP SIGNATURE----- --------------enigC439D14FE923CC3E0AE06D48-- --===============7483904360065399984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7483904360065399984==-- From xen-devel-bounces@lists.xen.org Thu May 03 13:05:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:05:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPviB-0005u1-Av; Thu, 03 May 2012 13:04:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvi9-0005to-P9 for xen-devel@lists.xen.org; Thu, 03 May 2012 13:04:46 +0000 Received: from [85.158.138.51:26136] by server-11.bemta-3.messagelabs.com id 69/B1-18894-D6282AF4; Thu, 03 May 2012 13:04:45 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336050282!25019216!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5758 invoked from network); 3 May 2012 13:04:44 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:04:44 -0000 Received: by qcsc20 with SMTP id c20so1385340qcs.32 for ; Thu, 03 May 2012 06:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uhsZDRGWEP6Cjr4/sUiZMoz3YGlsj5G92KwqClLbhIw=; b=Tv2HwPAvi+NGzMSk9dJiNAbnu2QarD3Cz+oUEDdC7wpRThqKrwpdEvl5oDhpPuzW7j qnCnXSG0iw+ZZugOBhierg46Lgwa0GSATX18rWd5YjtKVjZuq9OhD+wBkdN7I9+riWfX 6VmFrUmHvi5LeMIHMEI/kPXtbI3k0obZMlldzsTVYWoFLEylsO1YZ3lK0aGbX9P7an3u 2JtDwA4WxOju5C8dPaoSyN+WQTXW/DjjLCXGluFbnVr0ryHvahKxlzofaM0pwgLKa9lY um4BftlUUQwsNCcoVQ6CRDcPh2bxOnSvO8kjq71TkCF5eLBMtEBbTfurVBmUIc7ap5Yr ieCA== MIME-Version: 1.0 Received: by 10.224.212.1 with SMTP id gq1mr3666917qab.79.1336050282602; Thu, 03 May 2012 06:04:42 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Thu, 3 May 2012 06:04:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 14:04:42 +0100 X-Google-Sender-Auth: kb7lWEB7xnoTeq_8godi53KdLB0 Message-ID: From: George Dunlap To: Bei Guan Cc: xen-devel Subject: Re: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 1:50 PM, Bei Guan wrote: > Hi, > > When I make install-tools in Xen unstable source code directory, there is= an > error. The output is as the following. Please help me figure out this > problem. Thank you very much. Did you try doing "make clean ; ./configure ; make tools"? That's the first thing to do when you encounter a random error like this after pulling from trunk. This looks like it was made by a change to the way libraries were included a week or two ago. Try the above steps and let us know if that doesn't fix it. -George > > root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools > make -C tools install > make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C include install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' > make -C xen-foreign > make[4]: Entering directory > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > ./checker > tmp.size > diff -u reference.size tmp.size > rm tmp.size > make[4]: Leaving directory > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-ia64 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-ia64/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-x86 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-x86/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/foreign > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/io > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/sys > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/xsm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/COPYING //usr/include/xen > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/*.h //usr/include/xen > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-ia64/*.h //usr/include/xen/arch-ia64 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-x86/*.h //usr/include/xen/arch-x86 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/foreign/*.h //usr/include/xen/foreign > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/hvm/*.h //usr/include/xen/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/io/*.h //usr/include/xen/io > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/sys/*.h //usr/include/xen/sys > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/xsm/*.h //usr/include/xen/xsm > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C libxc install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > make libs > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > make[4]: Nothing to be done for `libs'. > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755= -p > //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755= -p > //usr/include > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p > libxenctrl.so.4.2.0 //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > libxenctrl.a //usr/lib64 > ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 > ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > xenctrl.h xenctrlosdep.h xentoollog.h //usr/include > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p > libxenguest.so.4.2.0 //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > libxenguest.a //usr/lib64 > ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 > ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > xenguest.h //usr/include > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C flask install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > make -C utils install > make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/utils' > gcc =A0 =A0 loadpolicy.o > =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so > -o flask-loadpolicy > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_key_create' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_once' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_getspecific' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_setspecific' > collect2: ld returned 1 exit status > make[5]: *** [flask-loadpolicy] Error 1 > make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils' > make[4]: *** [subdir-install-utils] Error 2 > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > make[3]: *** [subdirs-install] Error 2 > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > make[2]: *** [subdir-install-flask] Error 2 > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make: *** [install-tools] Error 2 > > > > > > -- > Best Regards, > Bei Guan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:05:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:05:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPviB-0005u1-Av; Thu, 03 May 2012 13:04:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvi9-0005to-P9 for xen-devel@lists.xen.org; Thu, 03 May 2012 13:04:46 +0000 Received: from [85.158.138.51:26136] by server-11.bemta-3.messagelabs.com id 69/B1-18894-D6282AF4; Thu, 03 May 2012 13:04:45 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336050282!25019216!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5758 invoked from network); 3 May 2012 13:04:44 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:04:44 -0000 Received: by qcsc20 with SMTP id c20so1385340qcs.32 for ; Thu, 03 May 2012 06:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uhsZDRGWEP6Cjr4/sUiZMoz3YGlsj5G92KwqClLbhIw=; b=Tv2HwPAvi+NGzMSk9dJiNAbnu2QarD3Cz+oUEDdC7wpRThqKrwpdEvl5oDhpPuzW7j qnCnXSG0iw+ZZugOBhierg46Lgwa0GSATX18rWd5YjtKVjZuq9OhD+wBkdN7I9+riWfX 6VmFrUmHvi5LeMIHMEI/kPXtbI3k0obZMlldzsTVYWoFLEylsO1YZ3lK0aGbX9P7an3u 2JtDwA4WxOju5C8dPaoSyN+WQTXW/DjjLCXGluFbnVr0ryHvahKxlzofaM0pwgLKa9lY um4BftlUUQwsNCcoVQ6CRDcPh2bxOnSvO8kjq71TkCF5eLBMtEBbTfurVBmUIc7ap5Yr ieCA== MIME-Version: 1.0 Received: by 10.224.212.1 with SMTP id gq1mr3666917qab.79.1336050282602; Thu, 03 May 2012 06:04:42 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Thu, 3 May 2012 06:04:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 14:04:42 +0100 X-Google-Sender-Auth: kb7lWEB7xnoTeq_8godi53KdLB0 Message-ID: From: George Dunlap To: Bei Guan Cc: xen-devel Subject: Re: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 1:50 PM, Bei Guan wrote: > Hi, > > When I make install-tools in Xen unstable source code directory, there is= an > error. The output is as the following. Please help me figure out this > problem. Thank you very much. Did you try doing "make clean ; ./configure ; make tools"? That's the first thing to do when you encounter a random error like this after pulling from trunk. This looks like it was made by a change to the way libraries were included a week or two ago. Try the above steps and let us know if that doesn't fix it. -George > > root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools > make -C tools install > make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C include install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' > make -C xen-foreign > make[4]: Entering directory > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > ./checker > tmp.size > diff -u reference.size tmp.size > rm tmp.size > make[4]: Leaving directory > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-ia64 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-ia64/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-x86 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/arch-x86/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/foreign > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/io > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/sys > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -m07= 55 > -p //usr/include/xen/xsm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/COPYING //usr/include/xen > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/*.h //usr/include/xen > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-ia64/*.h //usr/include/xen/arch-ia64 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-x86/*.h //usr/include/xen/arch-x86 > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/foreign/*.h //usr/include/xen/foreign > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/hvm/*.h //usr/include/xen/hvm > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/io/*.h //usr/include/xen/io > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/sys/*.h //usr/include/xen/sys > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m0644 = -p > xen/xsm/*.h //usr/include/xen/xsm > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C libxc install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > make libs > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > make[4]: Nothing to be done for `libs'. > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755= -p > //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0755= -p > //usr/include > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p > libxenctrl.so.4.2.0 //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > libxenctrl.a //usr/lib64 > ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 > ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > xenctrl.h xenctrlosdep.h xentoollog.h //usr/include > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 -p > libxenguest.so.4.2.0 //usr/lib64 > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > libxenguest.a //usr/lib64 > ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 > ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 -p > xenguest.h //usr/include > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > make -C flask install > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > make -C utils install > make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/utils' > gcc =A0 =A0 loadpolicy.o > =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so > -o flask-loadpolicy > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_key_create' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_once' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_getspecific' > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > undefined reference to `pthread_setspecific' > collect2: ld returned 1 exit status > make[5]: *** [flask-loadpolicy] Error 1 > make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils' > make[4]: *** [subdir-install-utils] Error 2 > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > make[3]: *** [subdirs-install] Error 2 > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > make[2]: *** [subdir-install-flask] Error 2 > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > make: *** [install-tools] Error 2 > > > > > > -- > Best Regards, > Bei Guan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:06:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:06:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvjS-00060d-Rh; Thu, 03 May 2012 13:06:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvjR-00060P-CV for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:06:05 +0000 Received: from [193.109.254.147:6523] by server-4.bemta-14.messagelabs.com id 9E/97-11570-CB282AF4; Thu, 03 May 2012 13:06:04 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336050360!2309344!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22009 invoked from network); 3 May 2012 13:06:02 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:06:02 -0000 Received: by obfk16 with SMTP id k16so3417102obf.30 for ; Thu, 03 May 2012 06:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iIcNtAQwlYQv4NO9ZKT7NIdBvs/S7f+qplzaThTKgWU=; b=WNkusemOLarPQZ0ZtGpWpee1tUgsWzkOm1gmypI+z6FHnSIRLjSxhicYXicEp5h/ag c4EDBBVvb2BPCtmHU3QqhW/fQIr2g704k44rjBq+O+r6LkkXmJKjIm/II9/F47zC+o0v OKs17frnNiLC/qDOZUFVxCIx+vPIIzHSXTj8KbS9WYPwmD+H1SvfaiGc9xkVoukvR3mH /r1sJFnEfNHBkFADZjNK3ZgXVyNQKC2wADu7/vCcLcSZVkcai6ORsouI5yE8QwwFyPc0 Abb7wReBeXyAJPVxLJS5/EstbinYP17THFh4eDAhWlf0VwoUt94bEjRxwF3pBGxWRaUj WpTg== MIME-Version: 1.0 Received: by 10.60.26.231 with SMTP id o7mr2730253oeg.31.1336050359895; Thu, 03 May 2012 06:05:59 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 06:05:59 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 21:05:59 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:05 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini >> wrote: >> > On Thu, 3 May 2012, ZhouPeng wrote: >> >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: >> >> > >> >> > Zhou Peng wrote >> >> >> >> >> >> Hi Fantu, >> >> >> >> >> >> Thanks for your response. >> >> >> >> >> >> xl doesn't support qxl-related option at the moment. >> >> >> I will test upstream-qemu-xen these days, and if it works well >> >> >> with qxl device, I will be glad to add qxl support to xl. >> >> >> >> >> > Hello, any news about this? >> >> > Thanks in advance >> >> >> >> It seems you are using the upstream-qemu. >> >> There are some special patches for upstream-qemu-xen(I don't track if= all the >> >> patches have been accepted by qemu) >> >> >> >> The git repos for upstream-qemu-xen: >> >> =A0 Stefano Stabellini's tree: >> >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git >> >> =A0 Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git >> >> >> >> I am watching upstream-qemu-xen's progress too, but I have not tracked >> >> it for months. >> > >> > That is my personal tree. Now upstream QEMU is integrated in >> > xen-unstable, so the tree that should be used >> > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git >> > >> > >> >> I was plan to test the latest upstream-qemu-xen and response to you, >> >> but I encounter a problem when preparing the environment using the up= stream xen: >> >> =A0 # xl list >> >> =A0 libxl: error: libxl.c:506:libxl_list_domain: geting domain info >> >> list: Operation not permitted >> >> =A0 libxl_domain_infolist failed. >> > >> > This looks like a basic setup issue. >> > >> > >> >> So I suggest you =A0to have a try of upstream-qemu-xen if not yet. >> >> In my test many months ago, it didn't support graphic, and spice was = tested >> >> with linux-hvm disabling graphic. >> > >> > What do you mean by "disabling graphic"? Do you mean disabling the vga >> > card? >> No, not disable the vga card. >> But booting in Text mode. > > Then you are manually starting X11 with the spice driver? Always in text mode. Never start X11. Using stdard vga but not qxl-vga. -- = Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:06:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:06:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvjS-00060d-Rh; Thu, 03 May 2012 13:06:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvjR-00060P-CV for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:06:05 +0000 Received: from [193.109.254.147:6523] by server-4.bemta-14.messagelabs.com id 9E/97-11570-CB282AF4; Thu, 03 May 2012 13:06:04 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336050360!2309344!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22009 invoked from network); 3 May 2012 13:06:02 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:06:02 -0000 Received: by obfk16 with SMTP id k16so3417102obf.30 for ; Thu, 03 May 2012 06:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iIcNtAQwlYQv4NO9ZKT7NIdBvs/S7f+qplzaThTKgWU=; b=WNkusemOLarPQZ0ZtGpWpee1tUgsWzkOm1gmypI+z6FHnSIRLjSxhicYXicEp5h/ag c4EDBBVvb2BPCtmHU3QqhW/fQIr2g704k44rjBq+O+r6LkkXmJKjIm/II9/F47zC+o0v OKs17frnNiLC/qDOZUFVxCIx+vPIIzHSXTj8KbS9WYPwmD+H1SvfaiGc9xkVoukvR3mH /r1sJFnEfNHBkFADZjNK3ZgXVyNQKC2wADu7/vCcLcSZVkcai6ORsouI5yE8QwwFyPc0 Abb7wReBeXyAJPVxLJS5/EstbinYP17THFh4eDAhWlf0VwoUt94bEjRxwF3pBGxWRaUj WpTg== MIME-Version: 1.0 Received: by 10.60.26.231 with SMTP id o7mr2730253oeg.31.1336050359895; Thu, 03 May 2012 06:05:59 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 06:05:59 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Thu, 3 May 2012 21:05:59 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:05 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> On Thu, May 3, 2012 at 8:46 PM, Stefano Stabellini >> wrote: >> > On Thu, 3 May 2012, ZhouPeng wrote: >> >> On Wed, May 2, 2012 at 4:21 PM, Fantu wrote: >> >> > >> >> > Zhou Peng wrote >> >> >> >> >> >> Hi Fantu, >> >> >> >> >> >> Thanks for your response. >> >> >> >> >> >> xl doesn't support qxl-related option at the moment. >> >> >> I will test upstream-qemu-xen these days, and if it works well >> >> >> with qxl device, I will be glad to add qxl support to xl. >> >> >> >> >> > Hello, any news about this? >> >> > Thanks in advance >> >> >> >> It seems you are using the upstream-qemu. >> >> There are some special patches for upstream-qemu-xen(I don't track if= all the >> >> patches have been accepted by qemu) >> >> >> >> The git repos for upstream-qemu-xen: >> >> =A0 Stefano Stabellini's tree: >> >> git://xenbits.xen.org/people/sstabellini/qemu-dm.git >> >> =A0 Anthony's tree: git://xenbits.xen.org/people/aperard/qemu-dm.git >> >> >> >> I am watching upstream-qemu-xen's progress too, but I have not tracked >> >> it for months. >> > >> > That is my personal tree. Now upstream QEMU is integrated in >> > xen-unstable, so the tree that should be used >> > is: http://xenbits.xen.org/git-http/qemu-upstream-unstable.git >> > >> > >> >> I was plan to test the latest upstream-qemu-xen and response to you, >> >> but I encounter a problem when preparing the environment using the up= stream xen: >> >> =A0 # xl list >> >> =A0 libxl: error: libxl.c:506:libxl_list_domain: geting domain info >> >> list: Operation not permitted >> >> =A0 libxl_domain_infolist failed. >> > >> > This looks like a basic setup issue. >> > >> > >> >> So I suggest you =A0to have a try of upstream-qemu-xen if not yet. >> >> In my test many months ago, it didn't support graphic, and spice was = tested >> >> with linux-hvm disabling graphic. >> > >> > What do you mean by "disabling graphic"? Do you mean disabling the vga >> > card? >> No, not disable the vga card. >> But booting in Text mode. > > Then you are manually starting X11 with the spice driver? Always in text mode. Never start X11. Using stdard vga but not qxl-vga. -- = Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:13:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:13:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvqM-0006PH-VC; Thu, 03 May 2012 13:13:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvqK-0006PB-Rb for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:13:12 +0000 Received: from [193.109.254.147:34581] by server-8.bemta-14.messagelabs.com id 00/8E-23244-86482AF4; Thu, 03 May 2012 13:13:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336050790!604137!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23045 invoked from network); 3 May 2012 13:13:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:13:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12274023" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 13:13: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, 3 May 2012 14:13:10 +0100 Message-ID: <1336050788.20716.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: ZhouPeng Date: Thu, 3 May 2012 14:13:08 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 14:05 +0100, ZhouPeng wrote: > > Then you are manually starting X11 with the spice driver? > Always in text mode. > Never start X11. > Using stdard vga but not qxl-vga. How is spice being used when you do this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:13:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:13:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvqM-0006PH-VC; Thu, 03 May 2012 13:13:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPvqK-0006PB-Rb for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:13:12 +0000 Received: from [193.109.254.147:34581] by server-8.bemta-14.messagelabs.com id 00/8E-23244-86482AF4; Thu, 03 May 2012 13:13:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336050790!604137!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23045 invoked from network); 3 May 2012 13:13:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:13:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12274023" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 13:13: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, 3 May 2012 14:13:10 +0100 Message-ID: <1336050788.20716.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: ZhouPeng Date: Thu, 3 May 2012 14:13:08 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 14:05 +0100, ZhouPeng wrote: > > Then you are manually starting X11 with the spice driver? > Always in text mode. > Never start X11. > Using stdard vga but not qxl-vga. How is spice being used when you do this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:27:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPw47-0006gg-IB; Thu, 03 May 2012 13:27:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPw45-0006gb-VO for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:27:26 +0000 Received: from [85.158.139.83:4117] by server-5.bemta-5.messagelabs.com id 09/E8-13566-DB782AF4; Thu, 03 May 2012 13:27:25 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336051642!15341742!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2848 invoked from network); 3 May 2012 13:27:24 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:27:24 -0000 Received: by ghbz17 with SMTP id z17so2330831ghb.30 for ; Thu, 03 May 2012 06:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XWEixCUZhGuREEPP6jQJt0KqTiItKGPXvy586vOu7WQ=; b=JYC6mj+hPuEAMIs56HNhJqIHlgQ8M5CZom8QnCWDIDsUbmZVicGTs6QVkYKJnfzHh2 DyXPPn8EHSCR9Zb7AikIS+ir49t6kThBRpbc/MERQ+Bui3lZO2w2ltcbem1P7e3/tY5m jApqOm1Z+XcjlGyGxel22sGBknloJZ5etxEIoNg9C5amNCbzfBL5r7YbV/UiuSDCNOli MnbnXKXCDKGp5Sl3RJJIXCDujfyU/vOj7usAYpgf4lnhc4yW6HVjaPj65Jf0c+i4tbYi gRvn5kpaVAoCwirxUTNLMGktlFTD8pSHi9xzwdkxf8SdGhC54VEWRVWVpZjzUcc7r3D+ 9MZg== MIME-Version: 1.0 Received: by 10.60.4.1 with SMTP id g1mr2756599oeg.55.1336051641940; Thu, 03 May 2012 06:27:21 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 06:27:21 -0700 (PDT) In-Reply-To: <1336050788.20716.76.camel@zakaz.uk.xensource.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336050788.20716.76.camel@zakaz.uk.xensource.com> Date: Thu, 3 May 2012 21:27:21 +0800 Message-ID: From: ZhouPeng To: Ian Campbell Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:13 PM, Ian Campbell wrote: > On Thu, 2012-05-03 at 14:05 +0100, ZhouPeng wrote: >> > Then you are manually starting X11 with the spice driver? >> Always in text mode. >> Never start X11. >> Using stdard vga but not qxl-vga. > > How is spice being used when you do this? > > Ian. > building upstream-qemu-xen (enable spice and xen) Add this options in hvm-cfg to enable spice protocal spice=1 spiceport=6000 spicehost='192.168.1.187' spicedisable_ticketing = 1 There is some info in http://code.google.com/p/spice4xen/wiki/Using_Upstream_Qemu ps: Two ways to disable graphic boot. * install a new linux-hvm without graphic in install period * set runlevel in text mode If boot in graphic, the hvm-windows and hvm-linux will crash down before booting completely. -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:27:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPw47-0006gg-IB; Thu, 03 May 2012 13:27:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPw45-0006gb-VO for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:27:26 +0000 Received: from [85.158.139.83:4117] by server-5.bemta-5.messagelabs.com id 09/E8-13566-DB782AF4; Thu, 03 May 2012 13:27:25 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336051642!15341742!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2848 invoked from network); 3 May 2012 13:27:24 -0000 Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com) (209.85.160.171) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:27:24 -0000 Received: by ghbz17 with SMTP id z17so2330831ghb.30 for ; Thu, 03 May 2012 06:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XWEixCUZhGuREEPP6jQJt0KqTiItKGPXvy586vOu7WQ=; b=JYC6mj+hPuEAMIs56HNhJqIHlgQ8M5CZom8QnCWDIDsUbmZVicGTs6QVkYKJnfzHh2 DyXPPn8EHSCR9Zb7AikIS+ir49t6kThBRpbc/MERQ+Bui3lZO2w2ltcbem1P7e3/tY5m jApqOm1Z+XcjlGyGxel22sGBknloJZ5etxEIoNg9C5amNCbzfBL5r7YbV/UiuSDCNOli MnbnXKXCDKGp5Sl3RJJIXCDujfyU/vOj7usAYpgf4lnhc4yW6HVjaPj65Jf0c+i4tbYi gRvn5kpaVAoCwirxUTNLMGktlFTD8pSHi9xzwdkxf8SdGhC54VEWRVWVpZjzUcc7r3D+ 9MZg== MIME-Version: 1.0 Received: by 10.60.4.1 with SMTP id g1mr2756599oeg.55.1336051641940; Thu, 03 May 2012 06:27:21 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 06:27:21 -0700 (PDT) In-Reply-To: <1336050788.20716.76.camel@zakaz.uk.xensource.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336050788.20716.76.camel@zakaz.uk.xensource.com> Date: Thu, 3 May 2012 21:27:21 +0800 Message-ID: From: ZhouPeng To: Ian Campbell Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:13 PM, Ian Campbell wrote: > On Thu, 2012-05-03 at 14:05 +0100, ZhouPeng wrote: >> > Then you are manually starting X11 with the spice driver? >> Always in text mode. >> Never start X11. >> Using stdard vga but not qxl-vga. > > How is spice being used when you do this? > > Ian. > building upstream-qemu-xen (enable spice and xen) Add this options in hvm-cfg to enable spice protocal spice=1 spiceport=6000 spicehost='192.168.1.187' spicedisable_ticketing = 1 There is some info in http://code.google.com/p/spice4xen/wiki/Using_Upstream_Qemu ps: Two ways to disable graphic boot. * install a new linux-hvm without graphic in install period * set runlevel in text mode If boot in graphic, the hvm-windows and hvm-linux will crash down before booting completely. -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:34:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwAM-0006qP-FY; Thu, 03 May 2012 13:33:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwAK-0006qK-Ft for xen-devel@lists.xen.org; Thu, 03 May 2012 13:33:52 +0000 Received: from [85.158.138.51:54748] by server-1.bemta-3.messagelabs.com id 83/D8-11491-F3982AF4; Thu, 03 May 2012 13:33:51 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336052029!25109775!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 491 invoked from network); 3 May 2012 13:33:50 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:33:50 -0000 Received: by wgbed3 with SMTP id ed3so1304145wgb.32 for ; Thu, 03 May 2012 06:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvAGdjODQXAO/fiINLIP6s+e+cs4PWZU4V5nlgxqfYM=; b=la13Pos2kEJjewnyOM2VSCRvJs/G6t8CQ1JN/q6GMcxijJk53yuFSdWRkG7qjtPBI5 0DUcKV2H+stC812HVLOf03AHO1FfOLwK4dmlBobaCPo19lwIx36nYM4aEmxuQkHxo2ag +Dsi8CSeYDBlxJfPmSlt2A6rLokoXQ4zRW5CN+s9NHY/I7PpQmzASAqsnDvk3RDa+u8b UcWjv+hQpNTKDS+DzED/dJFGIpwNhxJv3csnuf1eCFq0vRl/Ry8f89qLYhq9pM3/aHOO 8gKen7pxaQDSBORDclW+TPIAjiQ/eHQylv01ud2QIdtB3ISqG/kyf7r4HLFKSgLV79fL yzGg== MIME-Version: 1.0 Received: by 10.180.88.169 with SMTP id bh9mr3512047wib.5.1336052029762; Thu, 03 May 2012 06:33:49 -0700 (PDT) Received: by 10.223.157.129 with HTTP; Thu, 3 May 2012 06:33:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 21:33:49 +0800 Message-ID: From: Bei Guan To: George Dunlap Cc: xen-devel Subject: Re: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5690367443359018707==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5690367443359018707== Content-Type: multipart/alternative; boundary=f46d04182570a2ad6504bf21da58 --f46d04182570a2ad6504bf21da58 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi George, I didn't do the =93./configure=94 before. But when I do the steps as you said, I can compile the Xen tools successfully. Thanks a lot. 2012/5/3 George Dunlap > On Thu, May 3, 2012 at 1:50 PM, Bei Guan wrote: > > Hi, > > > > When I make install-tools in Xen unstable source code directory, there > is an > > error. The output is as the following. Please help me figure out this > > problem. Thank you very much. > > Did you try doing "make clean ; ./configure ; make tools"? That's the > first thing to do when you encounter a random error like this after > pulling from trunk. > > This looks like it was made by a change to the way libraries were > included a week or two ago. Try the above steps and let us know if > that doesn't fix it. > > -George > > > > > root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools > > make -C tools install > > make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C include install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' > > make -C xen-foreign > > make[4]: Entering directory > > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > > ./checker > tmp.size > > diff -u reference.size tmp.size > > rm tmp.size > > make[4]: Leaving directory > > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-ia64 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-ia64/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-x86 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-x86/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/foreign > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/io > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/sys > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/xsm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/COPYING //usr/include/xen > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/*.h //usr/include/xen > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-ia64/*.h //usr/include/xen/arch-ia64 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-x86/*.h //usr/include/xen/arch-x86 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/foreign/*.h //usr/include/xen/foreign > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/hvm/*.h //usr/include/xen/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/io/*.h //usr/include/xen/io > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/sys/*.h //usr/include/xen/sys > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/xsm/*.h //usr/include/xen/xsm > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C libxc install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make libs > > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make[4]: Nothing to be done for `libs'. > > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d > -m0755 -p > > //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d > -m0755 -p > > //usr/include > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 = -p > > libxenctrl.so.4.2.0 //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > libxenctrl.a //usr/lib64 > > ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 > > ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > xenctrl.h xenctrlosdep.h xentoollog.h //usr/include > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 = -p > > libxenguest.so.4.2.0 //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > libxenguest.a //usr/lib64 > > ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 > > ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > xenguest.h //usr/include > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C flask install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > > make -C utils install > > make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/util= s' > > gcc loadpolicy.o > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenc= trl.so > > -o flask-loadpolicy > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_key_create' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_once' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_getspecific' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_setspecific' > > collect2: ld returned 1 exit status > > make[5]: *** [flask-loadpolicy] Error 1 > > make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils= ' > > make[4]: *** [subdir-install-utils] Error 2 > > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[3]: *** [subdirs-install] Error 2 > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[2]: *** [subdir-install-flask] Error 2 > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make: *** [install-tools] Error 2 > > > > > > > > > > > > -- > > Best Regards, > > Bei Guan > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > --=20 Best Regards, Bei Guan --f46d04182570a2ad6504bf21da58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi George,

I didn't do the =93./configure=94 before.= =A0
But when I do the steps as you said, I can compile the Xen to= ols successfully.=A0Thanks a lot.



2012/5/3 George Dunlap <George.Dunlap@eu.citrix.com>
On Thu, May 3, 2012 at 1:50 PM, Bei Guan <gbtju85@gmail.com> wrote:
> Hi,
>
> When I make install-tools in Xen unstable source code directory, there= is an
> error. The output is as the following. Please help me figure out this<= br> > problem. Thank you very much.

Did you try doing "make clean ; ./configure ; make tools"? = =A0That's the
first thing to do when you encounter a random error like this after
pulling from trunk.

This looks like it was made by a change to the way libraries were
included a week or two ago. =A0Try the above steps and let us know if
that doesn't fix it.

=A0-George

>
> root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools
> make -C tools install
> make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C include install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include&#= 39;
> make -C xen-foreign
> make[4]: Entering directory
> `/root/Xen/xen-unstable.hg/tools/include/xen-foreign'
> ./checker > tmp.size
> diff -u reference.size tmp.size
> rm tmp.size
> make[4]: Leaving directory
> `/root/Xen/xen-unstable.hg/tools/include/xen-foreign'
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-ia64
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-ia64/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-x86
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-x86/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/foreign
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/io
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/sys
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/xsm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/COPYING //usr/include/xen
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/*.h //usr/include/xen
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-ia64/*.h //usr/include/xen/arch-ia64
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-x86/*.h //usr/include/xen/arch-x86
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/foreign/*.h //usr/include/xen/foreign
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/hvm/*.h //usr/include/xen/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/io/*.h //usr/include/xen/io
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/sys/*.h //usr/include/xen/sys
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/xsm/*.h //usr/include/xen/xsm
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include= 9;
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C libxc install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc'= ;
> make libs
> make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc'= ;
> make[4]: Nothing to be done for `libs'.
> make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc'=
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p
> //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p
> //usr/include
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755= -p
> libxenctrl.so.4.2.0 //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> libxenctrl.a //usr/lib64
> ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2
> ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> xenctrl.h xenctrlosdep.h xentoollog.h //usr/include
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755= -p
> libxenguest.so.4.2.0 //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> libxenguest.a //usr/lib64
> ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2
> ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> xenguest.h //usr/include
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc'=
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C flask install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask'= ;
> make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask'= ;
> make -C utils install
> make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/uti= ls'
> gcc =A0 =A0 loadpolicy.o
> =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/li= bxenctrl.so
> -o flask-loadpolicy
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_key_create'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_once'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_getspecific'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_setspecific'
> collect2: ld returned 1 exit status
> make[5]: *** [flask-loadpolicy] Error 1
> make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/util= s'
> make[4]: *** [subdir-install-utils] Error 2
> make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
> make[2]: *** [subdir-install-flask] Error 2
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make: *** [install-tools] Error 2
>
>
>
>
>
> --
> Best Regards,
> Bei Guan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org=
> http://li= sts.xen.org/xen-devel
>



--
Best Regards= ,
Bei Guan

--f46d04182570a2ad6504bf21da58-- --===============5690367443359018707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5690367443359018707==-- From xen-devel-bounces@lists.xen.org Thu May 03 13:34:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwAM-0006qP-FY; Thu, 03 May 2012 13:33:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwAK-0006qK-Ft for xen-devel@lists.xen.org; Thu, 03 May 2012 13:33:52 +0000 Received: from [85.158.138.51:54748] by server-1.bemta-3.messagelabs.com id 83/D8-11491-F3982AF4; Thu, 03 May 2012 13:33:51 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336052029!25109775!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 491 invoked from network); 3 May 2012 13:33:50 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 13:33:50 -0000 Received: by wgbed3 with SMTP id ed3so1304145wgb.32 for ; Thu, 03 May 2012 06:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvAGdjODQXAO/fiINLIP6s+e+cs4PWZU4V5nlgxqfYM=; b=la13Pos2kEJjewnyOM2VSCRvJs/G6t8CQ1JN/q6GMcxijJk53yuFSdWRkG7qjtPBI5 0DUcKV2H+stC812HVLOf03AHO1FfOLwK4dmlBobaCPo19lwIx36nYM4aEmxuQkHxo2ag +Dsi8CSeYDBlxJfPmSlt2A6rLokoXQ4zRW5CN+s9NHY/I7PpQmzASAqsnDvk3RDa+u8b UcWjv+hQpNTKDS+DzED/dJFGIpwNhxJv3csnuf1eCFq0vRl/Ry8f89qLYhq9pM3/aHOO 8gKen7pxaQDSBORDclW+TPIAjiQ/eHQylv01ud2QIdtB3ISqG/kyf7r4HLFKSgLV79fL yzGg== MIME-Version: 1.0 Received: by 10.180.88.169 with SMTP id bh9mr3512047wib.5.1336052029762; Thu, 03 May 2012 06:33:49 -0700 (PDT) Received: by 10.223.157.129 with HTTP; Thu, 3 May 2012 06:33:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 May 2012 21:33:49 +0800 Message-ID: From: Bei Guan To: George Dunlap Cc: xen-devel Subject: Re: [Xen-devel] Xen unstable make install-tools error X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5690367443359018707==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5690367443359018707== Content-Type: multipart/alternative; boundary=f46d04182570a2ad6504bf21da58 --f46d04182570a2ad6504bf21da58 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi George, I didn't do the =93./configure=94 before. But when I do the steps as you said, I can compile the Xen tools successfully. Thanks a lot. 2012/5/3 George Dunlap > On Thu, May 3, 2012 at 1:50 PM, Bei Guan wrote: > > Hi, > > > > When I make install-tools in Xen unstable source code directory, there > is an > > error. The output is as the following. Please help me figure out this > > problem. Thank you very much. > > Did you try doing "make clean ; ./configure ; make tools"? That's the > first thing to do when you encounter a random error like this after > pulling from trunk. > > This looks like it was made by a change to the way libraries were > included a week or two ago. Try the above steps and let us know if > that doesn't fix it. > > -George > > > > > root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools > > make -C tools install > > make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C include install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include' > > make -C xen-foreign > > make[4]: Entering directory > > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > > ./checker > tmp.size > > diff -u reference.size tmp.size > > rm tmp.size > > make[4]: Leaving directory > > `/root/Xen/xen-unstable.hg/tools/include/xen-foreign' > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-ia64 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-ia64/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-x86 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/arch-x86/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/foreign > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/io > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/sys > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d > -m0755 > > -p //usr/include/xen/xsm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/COPYING //usr/include/xen > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/*.h //usr/include/xen > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-ia64/*.h //usr/include/xen/arch-ia64 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-x86/*.h //usr/include/xen/arch-x86 > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/foreign/*.h //usr/include/xen/foreign > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/hvm/*.h //usr/include/xen/hvm > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/io/*.h //usr/include/xen/io > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/sys/*.h //usr/include/xen/sys > > /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m064= 4 > -p > > xen/xsm/*.h //usr/include/xen/xsm > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include' > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C libxc install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make libs > > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make[4]: Nothing to be done for `libs'. > > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d > -m0755 -p > > //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d > -m0755 -p > > //usr/include > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 = -p > > libxenctrl.so.4.2.0 //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > libxenctrl.a //usr/lib64 > > ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2 > > ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > xenctrl.h xenctrlosdep.h xentoollog.h //usr/include > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755 = -p > > libxenguest.so.4.2.0 //usr/lib64 > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > libxenguest.a //usr/lib64 > > ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2 > > ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so > > /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644 = -p > > xenguest.h //usr/include > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc' > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools' > > make -C flask install > > make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask' > > make -C utils install > > make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/util= s' > > gcc loadpolicy.o > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenc= trl.so > > -o flask-loadpolicy > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_key_create' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_once' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_getspecific' > > > /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxenct= rl.so: > > undefined reference to `pthread_setspecific' > > collect2: ld returned 1 exit status > > make[5]: *** [flask-loadpolicy] Error 1 > > make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/utils= ' > > make[4]: *** [subdir-install-utils] Error 2 > > make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[3]: *** [subdirs-install] Error 2 > > make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask' > > make[2]: *** [subdir-install-flask] Error 2 > > make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools' > > make: *** [install-tools] Error 2 > > > > > > > > > > > > -- > > Best Regards, > > Bei Guan > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > --=20 Best Regards, Bei Guan --f46d04182570a2ad6504bf21da58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi George,

I didn't do the =93./configure=94 before.= =A0
But when I do the steps as you said, I can compile the Xen to= ols successfully.=A0Thanks a lot.



2012/5/3 George Dunlap <George.Dunlap@eu.citrix.com>
On Thu, May 3, 2012 at 1:50 PM, Bei Guan <gbtju85@gmail.com> wrote:
> Hi,
>
> When I make install-tools in Xen unstable source code directory, there= is an
> error. The output is as the following. Please help me figure out this<= br> > problem. Thank you very much.

Did you try doing "make clean ; ./configure ; make tools"? = =A0That's the
first thing to do when you encounter a random error like this after
pulling from trunk.

This looks like it was made by a change to the way libraries were
included a week or two ago. =A0Try the above steps and let us know if
that doesn't fix it.

=A0-George

>
> root@gavin-laptop:~/Xen/xen-unstable.hg# make install-tools
> make -C tools install
> make[1]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C include install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/include&#= 39;
> make -C xen-foreign
> make[4]: Entering directory
> `/root/Xen/xen-unstable.hg/tools/include/xen-foreign'
> ./checker > tmp.size
> diff -u reference.size tmp.size
> rm tmp.size
> make[4]: Leaving directory
> `/root/Xen/xen-unstable.hg/tools/include/xen-foreign'
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-ia64
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-ia64/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-x86
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/arch-x86/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/foreign
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/io
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/sys
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -d -= m0755
> -p //usr/include/xen/xsm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/COPYING //usr/include/xen
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/*.h //usr/include/xen
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-ia64/*.h //usr/include/xen/arch-ia64
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-ia64/hvm/*.h //usr/include/xen/arch-ia64/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-x86/*.h //usr/include/xen/arch-x86
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/arch-x86/hvm/*.h //usr/include/xen/arch-x86/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/foreign/*.h //usr/include/xen/foreign
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/hvm/*.h //usr/include/xen/hvm
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/io/*.h //usr/include/xen/io
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/sys/*.h //usr/include/xen/sys
> /root/Xen/xen-unstable.hg/tools/include/../../tools/cross-install -m06= 44 -p
> xen/xsm/*.h //usr/include/xen/xsm
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/include= 9;
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C libxc install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc'= ;
> make libs
> make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/libxc'= ;
> make[4]: Nothing to be done for `libs'.
> make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc'=
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p
> //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -d -m0= 755 -p
> //usr/include
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755= -p
> libxenctrl.so.4.2.0 //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> libxenctrl.a //usr/lib64
> ln -sf libxenctrl.so.4.2.0 //usr/lib64/libxenctrl.so.4.2
> ln -sf libxenctrl.so.4.2 //usr/lib64/libxenctrl.so
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> xenctrl.h xenctrlosdep.h xentoollog.h //usr/include
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0755= -p
> libxenguest.so.4.2.0 //usr/lib64
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> libxenguest.a //usr/lib64
> ln -sf libxenguest.so.4.2.0 //usr/lib64/libxenguest.so.4.2
> ln -sf libxenguest.so.4.2 //usr/lib64/libxenguest.so
> /root/Xen/xen-unstable.hg/tools/libxc/../../tools/cross-install -m0644= -p
> xenguest.h //usr/include
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/libxc'=
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[2]: Entering directory `/root/Xen/xen-unstable.hg/tools'
> make -C flask install
> make[3]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask'= ;
> make[4]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask'= ;
> make -C utils install
> make[5]: Entering directory `/root/Xen/xen-unstable.hg/tools/flask/uti= ls'
> gcc =A0 =A0 loadpolicy.o
> =A0/root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/li= bxenctrl.so
> -o flask-loadpolicy
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_key_create'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_once'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_getspecific'
> /root/Xen/xen-unstable.hg/tools/flask/utils/../../../tools/libxc/libxe= nctrl.so:
> undefined reference to `pthread_setspecific'
> collect2: ld returned 1 exit status
> make[5]: *** [flask-loadpolicy] Error 1
> make[5]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask/util= s'
> make[4]: *** [subdir-install-utils] Error 2
> make[4]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/root/Xen/xen-unstable.hg/tools/flask'=
> make[2]: *** [subdir-install-flask] Error 2
> make[2]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/Xen/xen-unstable.hg/tools'
> make: *** [install-tools] Error 2
>
>
>
>
>
> --
> Best Regards,
> Bei Guan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org=
> http://li= sts.xen.org/xen-devel
>



--
Best Regards= ,
Bei Guan

--f46d04182570a2ad6504bf21da58-- --===============5690367443359018707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5690367443359018707==-- From xen-devel-bounces@lists.xen.org Thu May 03 13:42:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwIN-00071x-Eo; Thu, 03 May 2012 13:42:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwIM-00071s-0M for xen-devel@lists.xen.org; Thu, 03 May 2012 13:42:10 +0000 Received: from [85.158.138.51:31077] by server-5.bemta-3.messagelabs.com id 42/5E-17113-13B82AF4; Thu, 03 May 2012 13:42:09 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336052527!14059966!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI4MTEx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1176 invoked from network); 3 May 2012 13:42:08 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-13.tower-174.messagelabs.com with SMTP; 3 May 2012 13:42:08 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 03 May 2012 06:42:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138445595" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 03 May 2012 06:42:07 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 May 2012 06:42:06 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Thu, 3 May 2012 21:42:04 +0800 From: "Dong, Eddie" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsIAAFYgAgADJ91A= Date: Thu, 3 May 2012 13:42:03 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> In-Reply-To: <4FA26B7C0200007800081502@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > The TRAP_debug should not use SW_EXCEPTION, it should use > HW_EXCEPTION > > Per SDM and confirmation from our HW guys. We will send fixes soon. > > Please also have the opcode 0xF1 generated #DB addressed in > whatever is the appropriate way. Opcode 0xf1 should use " privileged software exception". What we can do probably include: 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state the usage of the API. 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real usage case to test so far. We will provide #1 quickly, but for #2, can Aravindh provide test if we get the patch ready? > > >> > >> Anyone except perhaps LOCK - none of them should have any effect > >> other than making the instruction longer. > >> > > LOCK can never be used as prefix of INT nn instruction, nor can REPx > prefix. > > Can you provide more details as for this concern? > > The only prefix that is documented to cause #UD here is LOCK. All In #UD case (fault), the guest RIP is not advanced per SDM, and therefore guest will either spin in the previous LOCK instruction, or advance the IP to next instruction by guest #UD handler. I didn't see emulator could advance IP to the next instruction (INT nn) for LOCK prefix. Do I miss something? > other prefixes should consequently be considered ignored, and so > should the emulation do (and properly handle resulting instruction > lengths). > The behavior is un-defined per SDM in this case, so either solution should be fine :) Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:42:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwIN-00071x-Eo; Thu, 03 May 2012 13:42:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwIM-00071s-0M for xen-devel@lists.xen.org; Thu, 03 May 2012 13:42:10 +0000 Received: from [85.158.138.51:31077] by server-5.bemta-3.messagelabs.com id 42/5E-17113-13B82AF4; Thu, 03 May 2012 13:42:09 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336052527!14059966!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI4MTEx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1176 invoked from network); 3 May 2012 13:42:08 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-13.tower-174.messagelabs.com with SMTP; 3 May 2012 13:42:08 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 03 May 2012 06:42:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138445595" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 03 May 2012 06:42:07 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 May 2012 06:42:06 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Thu, 3 May 2012 21:42:04 +0800 From: "Dong, Eddie" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsIAAFYgAgADJ91A= Date: Thu, 3 May 2012 13:42:03 +0000 Message-ID: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> In-Reply-To: <4FA26B7C0200007800081502@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > The TRAP_debug should not use SW_EXCEPTION, it should use > HW_EXCEPTION > > Per SDM and confirmation from our HW guys. We will send fixes soon. > > Please also have the opcode 0xF1 generated #DB addressed in > whatever is the appropriate way. Opcode 0xf1 should use " privileged software exception". What we can do probably include: 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state the usage of the API. 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real usage case to test so far. We will provide #1 quickly, but for #2, can Aravindh provide test if we get the patch ready? > > >> > >> Anyone except perhaps LOCK - none of them should have any effect > >> other than making the instruction longer. > >> > > LOCK can never be used as prefix of INT nn instruction, nor can REPx > prefix. > > Can you provide more details as for this concern? > > The only prefix that is documented to cause #UD here is LOCK. All In #UD case (fault), the guest RIP is not advanced per SDM, and therefore guest will either spin in the previous LOCK instruction, or advance the IP to next instruction by guest #UD handler. I didn't see emulator could advance IP to the next instruction (INT nn) for LOCK prefix. Do I miss something? > other prefixes should consequently be considered ignored, and so > should the emulation do (and properly handle resulting instruction > lengths). > The behavior is un-defined per SDM in this case, so either solution should be fine :) Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwJU-00076K-2V; Thu, 03 May 2012 13:43:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwJS-000768-OL for xen-devel@lists.xen.org; Thu, 03 May 2012 13:43:19 +0000 Received: from [85.158.138.51:46760] by server-11.bemta-3.messagelabs.com id 47/22-18894-57B82AF4; Thu, 03 May 2012 13:43:17 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336052595!25028931!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2084 invoked from network); 3 May 2012 13:43:16 -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; 3 May 2012 13:43:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="193230372" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 09:42:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 09:42:56 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPwJ6-0001mm-41; Thu, 03 May 2012 14:42:56 +0100 Message-ID: <4FA28B1B.8040205@eu.citrix.com> Date: Thu, 3 May 2012 14:41:47 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> In-Reply-To: <1335976251.2961.123.camel@Abyss> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/12 17:30, Dario Faggioli wrote: >>> + >>> +/* Store the policy for the domain while parsing */ >>> +static int nodes_policy = NODES_POLICY_DEFAULT; >>> + >>> +/* Store the number of nodes to be used while parsing */ >>> +static int num_nodes_policy = 0; >> Why are "nodes_policy" and "num_nodes_policy" not passed in along with >> b_info? >> > That was my first implementation. Then I figured out that I want to do > the placement in _xl_, not in _libxl_, so I really don't need to muck up > build info with placement related stuff. Should I use b_info anyway, > even if I don't need these fields while in libxl? Ah right -- yeah, probably since b_info is a libxl structure, you shouldn't add it in there. But in that case you should probably add another xl-specific structure and pass it through, rather than having global variables, I think. It's only used in the handful of placement functions, right? > Sounds definitely nicer. I just did it like that because I found a very > similar example in xl itself, but I'm open about changing this to > whatever you and libxl maintainers reach a consensus on. :-) Right. This is always a bit tricky, balancing your own taste for how to do things, and following the style of the code that you're modifying. >> Also, is it really necessary for a VM to have an equal amount of memory >> on every node? It seems like it would be better to have 75% on one node >> and 25% on a second node than to have 25% on four nodes, for example. >> Furthermore, insisting on an even amount fragments the node memory >> further -- i.e., if we chose to have 25% on four nodes instead of 75% on >> one and 25% on another, that will make it harder for another VM to fit >> on a single node as well. >> > Ok, that is something quite important to discuss. What you propose makes > a lot of sense, although some issues comes to my mind: > > - which percent should I try, and in what order? I mean, 75%/25% > sounds reasonable, but maybe also 80%/20% or even 60%/40% helps your > point. I had in mind no constraints at all on the ratios -- basically, if you can find N nodes such that the sum of free memory is enough to create the VM, even 99%/1%, then go for that rather than looking for N+1. Obviously finding a more balanced option would be better. One option would be to scan through finding all sets of N nodes that will satisfy the criteria, and then choose the most "balanced" one. That might be more than we need for 4.2, so another option would be to look for evenly balanced nodes first, then if we don't find a set, look for any set. (That certainly fits with the "first fit" description!) > - suppose I go for 75%/25%, what about the scheduling oof the VM? Haha -- yeah, for a research paper, you'd probably implement some kind of lottery scheduling algorithm that would schedule it on one node 75% of the time and another node 25% of the time. :-) But I think that just making the node affinity equal to both of them will be good enough for now. There will be some variability in performance, but there will be some of that anyway depending on what node's memory the guest happens to use more. This actually kind of a different issue, but I'll bring it up now because it's related. (Something to toss in for thinking about in 4.3 really.) Suppose there are 4 cores and 16GiB per node, and a VM has 8 vcpus and 8GiB of RAM. The algorithm you have here will attempt to put 4GiB on each of two nodes (since it will take 2 nodes to get 8 cores). However, it's pretty common for larger VMs to have way more vcpus than they actually use at any one time. So it might actually have better performance to put all 8GiB on one node, and set the node affinity accordingly. In the rare event that more than 4 vcpus are active, a handful of vcpus will have all remote accesses, but the majority of the time, all of the cpus will have local accesses. (OTOH, maybe that should be only a policy thing that we should recommend in the documentation...) > Please, don't get me wrong, I see your point and really think it makes > sense. I've actually thought along the same line for a while, but then I > couldn't find an answers to the questions above. > > That's why, kind of falling back with Xen's default "striped" approach > (although on as less nodes as possible, which is _much_ better than the > actual Xen's default!). It looked simple enough to write, read and > understand, while still providing statistically consistent performances. Dude, this is open source. Be opinionated. ;-) What do you think of my suggestions above? >> Hmm -- if I'm reading this right, the only time the nodemap won't be >> all nodes is if (1) the user specified nodes, or (2) there's a >> cpumask in effect. If we're going to override that setting, wouldn't >> it make sense to just expand to all numa nodes? > As you wish, the whole "what to do if what I've been provided with > doesn't work" is in the *wild guess* status, meaning I tried to figure > out what would be best to do, but I might well be far from the actual > correct solution, provided there is one. > > Trying to enlarge the nodemap step by step is potentially yielding > better performances, but is probably not so near to the "least surprise" > principle one should use when designing UIs. :-( > >> Hmm -- though I suppose what you'd really want to try is adding each >> node in turn, rather than one at a time (i.e., if the cpus are pinned to >> nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before >> trying [1,2,3,4]. >> > Yep, that makes a real lot of sense, thanks! I can definitely try doing > that, although it will complicate the code a bit... > >> But that's starting to get really complicated -- I >> wonder if it's better to just fail and let the user change the pinnings >> / configuration node mapping. >> > Well, that will probably be the least surprising behaviour. > > Again, just let me know what you think it's best among the various > alternatives and I'll go for it. I think if the user specifies a nodemap, and that nodemap doesn't have enough memory, we should throw an error. If there's a node_affinity set, no memory on that node, but memory on a *different* node, what will Xen do? It will allocate memory on some other node, right? So ATM even if you specify a cpumask, you'll get memory on the masked nodes first, and then memory elsewhere (probably in a fairly random manner); but as much of the memory as possible will be on the masked nodes. I wonder then if we shouldnt' just keep that behavior -- i.e., if there's a cpumask specified, just return the nodemask from that mask, and let Xen put as much as possible on that node and let the rest fall where it may. What do you think? >>> + >>> + if (use_cpus>= b_info->max_vcpus) { >>> + rc = 0; >>> + break; >>> + } >> Hmm -- there's got to be a better way to find out the minimum number of >> nodes to house a given number of vcpus than just starting at 1 and >> re-trying until we have enough. >>> + /* Add one more node and retry fitting the domain */ >>> + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); >> Same comment as above. >> > I'm not sure I'm getting this. The whole point here is let's consider > free memory on the various nodes first, and then adjust the result if > some other constraints are being violated. Sorry, wrong above -- I meant the other comment about __add_nodes_to_nodemap(). :-) > However, if what you mean is I could check beforehand whether or not the > user provided configuration will give us enough CPUs and avoid testing > scenarios that are guaranteed to fail, then I agree and I'll reshape the > code to look like that. This triggers the heuristics re-designing stuff > from above again, as one have to decide what to do if user asks for > "nodes=[1,3]" and I discover (earlier) that I need one more node for > having enough CPUs (I mean, what node should I try first?). No, that's not exactly what I meant. Suppose there are 4 cores per node, and a VM has 16 vcpus, and NUMA is just set to auto, with no other parameters. If I'm reading your code right, what it will do is first try to find a set of 1 node that will satisfy the constraints, then 2 nodes, then 3, nodes, then 4, &c. Since there are at most 4 cores per node, we know that 1, 2, and 3 nodes are going to fail, regardless of how much memory there is or how many cpus are offline. So why not just start with 4, if the user hasn't specified anything? Then if 4 doesn't work (either because there's not enough memory, or some of the cpus are offline), then we can start bumping it up to 5, 6, &c. That's what I was getting at -- but again, if it makes it too complicated, trading a bit of extra passes for a significant chunk of your debugging time is OK. :-) > So, I'm not entirely sure I answered your question but the point is your > idea above is the best one: if you ask something and we don't manage in > getting it done, just stop and let you figure things out. > I've only one question about this approach, what if the automatic > placement is/becomes the default? I mean, avoiding any kind of fallback > (which again, makes sense to me in case the user is explicitly asking > something specific) would mean a completely NUMA-unaware VM creation can > be aborted even if the user did not say anything... How do we deal with > this? Well, if the user didn't specify anything, then we can't contradict anything he specified, right? :-) If the user doesn't specify anything, and the default is "numa=auto", then I think we're free to do whatever we think is best regarding NUMA placement; in fact, I think we should try to avoid failing VM creation if it's at all possible. I just meant what I think we should do if the user asked for specific NUMA nodes or a specific number of nodes. (I think that cpu masks should probably behave as it does now -- set the numa_affinity, but not fail domain creation if there's not enough memory on those nodes.) It seems like we have a number of issues here that would be good for more people to come in on -- what if I attempt to summarize the high-level decisions we're talking about so that it's easier for more people to comment on them? -George > >>> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c >>> --- a/xen/arch/x86/numa.c >>> +++ b/xen/arch/x86/numa.c >>> ... >>> >> This should be in its own patch. >> > Ok. > > Thanks lot again for taking a look! > > Regards, > Dario > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwJU-00076K-2V; Thu, 03 May 2012 13:43:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwJS-000768-OL for xen-devel@lists.xen.org; Thu, 03 May 2012 13:43:19 +0000 Received: from [85.158.138.51:46760] by server-11.bemta-3.messagelabs.com id 47/22-18894-57B82AF4; Thu, 03 May 2012 13:43:17 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336052595!25028931!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2084 invoked from network); 3 May 2012 13:43:16 -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; 3 May 2012 13:43:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="193230372" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 09:42:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 3 May 2012 09:42:56 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SPwJ6-0001mm-41; Thu, 03 May 2012 14:42:56 +0100 Message-ID: <4FA28B1B.8040205@eu.citrix.com> Date: Thu, 3 May 2012 14:41:47 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dario Faggioli References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> In-Reply-To: <1335976251.2961.123.camel@Abyss> Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/05/12 17:30, Dario Faggioli wrote: >>> + >>> +/* Store the policy for the domain while parsing */ >>> +static int nodes_policy = NODES_POLICY_DEFAULT; >>> + >>> +/* Store the number of nodes to be used while parsing */ >>> +static int num_nodes_policy = 0; >> Why are "nodes_policy" and "num_nodes_policy" not passed in along with >> b_info? >> > That was my first implementation. Then I figured out that I want to do > the placement in _xl_, not in _libxl_, so I really don't need to muck up > build info with placement related stuff. Should I use b_info anyway, > even if I don't need these fields while in libxl? Ah right -- yeah, probably since b_info is a libxl structure, you shouldn't add it in there. But in that case you should probably add another xl-specific structure and pass it through, rather than having global variables, I think. It's only used in the handful of placement functions, right? > Sounds definitely nicer. I just did it like that because I found a very > similar example in xl itself, but I'm open about changing this to > whatever you and libxl maintainers reach a consensus on. :-) Right. This is always a bit tricky, balancing your own taste for how to do things, and following the style of the code that you're modifying. >> Also, is it really necessary for a VM to have an equal amount of memory >> on every node? It seems like it would be better to have 75% on one node >> and 25% on a second node than to have 25% on four nodes, for example. >> Furthermore, insisting on an even amount fragments the node memory >> further -- i.e., if we chose to have 25% on four nodes instead of 75% on >> one and 25% on another, that will make it harder for another VM to fit >> on a single node as well. >> > Ok, that is something quite important to discuss. What you propose makes > a lot of sense, although some issues comes to my mind: > > - which percent should I try, and in what order? I mean, 75%/25% > sounds reasonable, but maybe also 80%/20% or even 60%/40% helps your > point. I had in mind no constraints at all on the ratios -- basically, if you can find N nodes such that the sum of free memory is enough to create the VM, even 99%/1%, then go for that rather than looking for N+1. Obviously finding a more balanced option would be better. One option would be to scan through finding all sets of N nodes that will satisfy the criteria, and then choose the most "balanced" one. That might be more than we need for 4.2, so another option would be to look for evenly balanced nodes first, then if we don't find a set, look for any set. (That certainly fits with the "first fit" description!) > - suppose I go for 75%/25%, what about the scheduling oof the VM? Haha -- yeah, for a research paper, you'd probably implement some kind of lottery scheduling algorithm that would schedule it on one node 75% of the time and another node 25% of the time. :-) But I think that just making the node affinity equal to both of them will be good enough for now. There will be some variability in performance, but there will be some of that anyway depending on what node's memory the guest happens to use more. This actually kind of a different issue, but I'll bring it up now because it's related. (Something to toss in for thinking about in 4.3 really.) Suppose there are 4 cores and 16GiB per node, and a VM has 8 vcpus and 8GiB of RAM. The algorithm you have here will attempt to put 4GiB on each of two nodes (since it will take 2 nodes to get 8 cores). However, it's pretty common for larger VMs to have way more vcpus than they actually use at any one time. So it might actually have better performance to put all 8GiB on one node, and set the node affinity accordingly. In the rare event that more than 4 vcpus are active, a handful of vcpus will have all remote accesses, but the majority of the time, all of the cpus will have local accesses. (OTOH, maybe that should be only a policy thing that we should recommend in the documentation...) > Please, don't get me wrong, I see your point and really think it makes > sense. I've actually thought along the same line for a while, but then I > couldn't find an answers to the questions above. > > That's why, kind of falling back with Xen's default "striped" approach > (although on as less nodes as possible, which is _much_ better than the > actual Xen's default!). It looked simple enough to write, read and > understand, while still providing statistically consistent performances. Dude, this is open source. Be opinionated. ;-) What do you think of my suggestions above? >> Hmm -- if I'm reading this right, the only time the nodemap won't be >> all nodes is if (1) the user specified nodes, or (2) there's a >> cpumask in effect. If we're going to override that setting, wouldn't >> it make sense to just expand to all numa nodes? > As you wish, the whole "what to do if what I've been provided with > doesn't work" is in the *wild guess* status, meaning I tried to figure > out what would be best to do, but I might well be far from the actual > correct solution, provided there is one. > > Trying to enlarge the nodemap step by step is potentially yielding > better performances, but is probably not so near to the "least surprise" > principle one should use when designing UIs. :-( > >> Hmm -- though I suppose what you'd really want to try is adding each >> node in turn, rather than one at a time (i.e., if the cpus are pinned to >> nodes 2 and 3, and [2,3] doesn't work, try [1,2,3] and [2,3,4] before >> trying [1,2,3,4]. >> > Yep, that makes a real lot of sense, thanks! I can definitely try doing > that, although it will complicate the code a bit... > >> But that's starting to get really complicated -- I >> wonder if it's better to just fail and let the user change the pinnings >> / configuration node mapping. >> > Well, that will probably be the least surprising behaviour. > > Again, just let me know what you think it's best among the various > alternatives and I'll go for it. I think if the user specifies a nodemap, and that nodemap doesn't have enough memory, we should throw an error. If there's a node_affinity set, no memory on that node, but memory on a *different* node, what will Xen do? It will allocate memory on some other node, right? So ATM even if you specify a cpumask, you'll get memory on the masked nodes first, and then memory elsewhere (probably in a fairly random manner); but as much of the memory as possible will be on the masked nodes. I wonder then if we shouldnt' just keep that behavior -- i.e., if there's a cpumask specified, just return the nodemask from that mask, and let Xen put as much as possible on that node and let the rest fall where it may. What do you think? >>> + >>> + if (use_cpus>= b_info->max_vcpus) { >>> + rc = 0; >>> + break; >>> + } >> Hmm -- there's got to be a better way to find out the minimum number of >> nodes to house a given number of vcpus than just starting at 1 and >> re-trying until we have enough. >>> + /* Add one more node and retry fitting the domain */ >>> + __add_nodes_to_nodemap(&new_nodemap, numa, nr_nodes, 1); >> Same comment as above. >> > I'm not sure I'm getting this. The whole point here is let's consider > free memory on the various nodes first, and then adjust the result if > some other constraints are being violated. Sorry, wrong above -- I meant the other comment about __add_nodes_to_nodemap(). :-) > However, if what you mean is I could check beforehand whether or not the > user provided configuration will give us enough CPUs and avoid testing > scenarios that are guaranteed to fail, then I agree and I'll reshape the > code to look like that. This triggers the heuristics re-designing stuff > from above again, as one have to decide what to do if user asks for > "nodes=[1,3]" and I discover (earlier) that I need one more node for > having enough CPUs (I mean, what node should I try first?). No, that's not exactly what I meant. Suppose there are 4 cores per node, and a VM has 16 vcpus, and NUMA is just set to auto, with no other parameters. If I'm reading your code right, what it will do is first try to find a set of 1 node that will satisfy the constraints, then 2 nodes, then 3, nodes, then 4, &c. Since there are at most 4 cores per node, we know that 1, 2, and 3 nodes are going to fail, regardless of how much memory there is or how many cpus are offline. So why not just start with 4, if the user hasn't specified anything? Then if 4 doesn't work (either because there's not enough memory, or some of the cpus are offline), then we can start bumping it up to 5, 6, &c. That's what I was getting at -- but again, if it makes it too complicated, trading a bit of extra passes for a significant chunk of your debugging time is OK. :-) > So, I'm not entirely sure I answered your question but the point is your > idea above is the best one: if you ask something and we don't manage in > getting it done, just stop and let you figure things out. > I've only one question about this approach, what if the automatic > placement is/becomes the default? I mean, avoiding any kind of fallback > (which again, makes sense to me in case the user is explicitly asking > something specific) would mean a completely NUMA-unaware VM creation can > be aborted even if the user did not say anything... How do we deal with > this? Well, if the user didn't specify anything, then we can't contradict anything he specified, right? :-) If the user doesn't specify anything, and the default is "numa=auto", then I think we're free to do whatever we think is best regarding NUMA placement; in fact, I think we should try to avoid failing VM creation if it's at all possible. I just meant what I think we should do if the user asked for specific NUMA nodes or a specific number of nodes. (I think that cpu masks should probably behave as it does now -- set the numa_affinity, but not fail domain creation if there's not enough memory on those nodes.) It seems like we have a number of issues here that would be good for more people to come in on -- what if I attempt to summarize the high-level decisions we're talking about so that it's easier for more people to comment on them? -George > >>> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c >>> --- a/xen/arch/x86/numa.c >>> +++ b/xen/arch/x86/numa.c >>> ... >>> >> This should be in its own patch. >> > Ok. > > Thanks lot again for taking a look! > > Regards, > Dario > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:49:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwPG-0007KQ-SG; Thu, 03 May 2012 13:49:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwPF-0007KK-11 for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:49:17 +0000 Received: from [85.158.143.35:13662] by server-2.bemta-4.messagelabs.com id 4B/95-17550-CDC82AF4; Thu, 03 May 2012 13:49:16 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336052955!13925213!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4553 invoked from network); 3 May 2012 13:49:15 -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 May 2012 13:49:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12274937" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 13:49: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, 3 May 2012 14:49:15 +0100 Date: Thu, 3 May 2012 14:56:44 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Fantu , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, ZhouPeng wrote: > >> > What do you mean by "disabling graphic"? Do you mean disabling the vga > >> > card? > >> No, not disable the vga card. > >> But booting in Text mode. > > > > Then you are manually starting X11 with the spice driver? > Always in text mode. > Never start X11. > Using stdard vga but not qxl-vga. so you didn't actually test qxl at all, did you? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 13:49:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 13: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 ) id 1SPwPG-0007KQ-SG; Thu, 03 May 2012 13:49:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwPF-0007KK-11 for xen-devel@lists.xensource.com; Thu, 03 May 2012 13:49:17 +0000 Received: from [85.158.143.35:13662] by server-2.bemta-4.messagelabs.com id 4B/95-17550-CDC82AF4; Thu, 03 May 2012 13:49:16 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336052955!13925213!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4553 invoked from network); 3 May 2012 13:49:15 -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 May 2012 13:49:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12274937" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 13:49: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, 3 May 2012 14:49:15 +0100 Date: Thu, 3 May 2012 14:56:44 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: ZhouPeng In-Reply-To: Message-ID: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Fantu , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, ZhouPeng wrote: > >> > What do you mean by "disabling graphic"? Do you mean disabling the vga > >> > card? > >> No, not disable the vga card. > >> But booting in Text mode. > > > > Then you are manually starting X11 with the spice driver? > Always in text mode. > Never start X11. > Using stdard vga but not qxl-vga. so you didn't actually test qxl at all, did you? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:01:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwaR-0007Ye-5K; Thu, 03 May 2012 14:00:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwaP-0007YZ-Vo for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:00:50 +0000 Received: from [85.158.143.99:25944] by server-1.bemta-4.messagelabs.com id 0D/CE-20925-09F82AF4; Thu, 03 May 2012 14:00:48 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-216.messagelabs.com!1336053647!22978438!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzMzNTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8892 invoked from network); 3 May 2012 14:00:47 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 14:00:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id A96861FCE; Thu, 3 May 2012 17:00:46 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B82BA2005D; Thu, 3 May 2012 17:00:45 +0300 (EEST) Date: Thu, 3 May 2012 17:00:45 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Fantu Message-ID: <20120503140045.GP2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336048124596-5683034.post@n5.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:28:44AM -0700, Fantu wrote: > > About qxl there are problems about videoram not allocated or not used over 4 > mb (same as default cirrus vga). > At the moment I haven't found solution for this problem, probably some > bugfix and/or change are needed on xen. > Is this a regression in xen-unstable compared to xen 4.1 ? afaik you can get at least 16 MB of video memory for HVM guest with Xen 4.1. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:01:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwaR-0007Ye-5K; Thu, 03 May 2012 14:00:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwaP-0007YZ-Vo for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:00:50 +0000 Received: from [85.158.143.99:25944] by server-1.bemta-4.messagelabs.com id 0D/CE-20925-09F82AF4; Thu, 03 May 2012 14:00:48 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-216.messagelabs.com!1336053647!22978438!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzMzNTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8892 invoked from network); 3 May 2012 14:00:47 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 14:00:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id A96861FCE; Thu, 3 May 2012 17:00:46 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B82BA2005D; Thu, 3 May 2012 17:00:45 +0300 (EEST) Date: Thu, 3 May 2012 17:00:45 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Fantu Message-ID: <20120503140045.GP2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336048124596-5683034.post@n5.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:28:44AM -0700, Fantu wrote: > > About qxl there are problems about videoram not allocated or not used over 4 > mb (same as default cirrus vga). > At the moment I haven't found solution for this problem, probably some > bugfix and/or change are needed on xen. > Is this a regression in xen-unstable compared to xen 4.1 ? afaik you can get at least 16 MB of video memory for HVM guest with Xen 4.1. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:17:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14: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 ) id 1SPwq9-00084O-D7; Thu, 03 May 2012 14:17:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwq8-00084J-4D for xen-devel@lists.xen.org; Thu, 03 May 2012 14:17:04 +0000 Received: from [85.158.138.51:25574] by server-1.bemta-3.messagelabs.com id B4/33-11491-F5392AF4; Thu, 03 May 2012 14:17:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336054622!23271568!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_DONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3231 invoked from network); 3 May 2012 14:17:02 -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; 3 May 2012 14:17:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 15:17:01 +0100 Message-Id: <4FA2AF7C0200007800081649@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 15:17:00 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 15:42, "Dong, Eddie" wrote: >> > The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >> > Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state > the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have > real usage case to test so far. > > We will provide #1 quickly, but for #2, can Aravindh provide test if we get > the patch ready? > >> >> >> >> >> Anyone except perhaps LOCK - none of them should have any effect >> >> other than making the instruction longer. >> >> >> > LOCK can never be used as prefix of INT nn instruction, nor can REPx >> prefix. >> > Can you provide more details as for this concern? >> >> The only prefix that is documented to cause #UD here is LOCK. All > > In #UD case (fault), the guest RIP is not advanced per SDM, and therefore > guest will either > spin in the previous LOCK instruction, or advance the IP to next instruction > by guest #UD handler. > I didn't see emulator could advance IP to the next instruction (INT nn) for > LOCK prefix. > Do I miss something? I'm sure you misunderstand me. I was saying that LOCK is the only prefix we can validly assume was not present on the original instruction. Any other prefix could be present, and should count towards the instruction length. Note the __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ and (after the recent change for INT nn) __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ which both use hard coded values. Furthermore, for Aravindh's use case where there might not even be an "original instruction" (i.e. injecting an interrupt/exception for reasons other than emulating a respective instruction), advancing IP seems bogus to me altogether. >> other prefixes should consequently be considered ignored, and so >> should the emulation do (and properly handle resulting instruction >> lengths). >> > The behavior is un-defined per SDM in this case, so either solution should be > fine :) Can you please point me to where this is being stated? I particularly doubt that for operand and address size prefixes as well as on 64-bit - since they are documented to be ignored there - CS, DS, ES, and SS segment prefixes... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:17:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14: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 ) id 1SPwq9-00084O-D7; Thu, 03 May 2012 14:17:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwq8-00084J-4D for xen-devel@lists.xen.org; Thu, 03 May 2012 14:17:04 +0000 Received: from [85.158.138.51:25574] by server-1.bemta-3.messagelabs.com id B4/33-11491-F5392AF4; Thu, 03 May 2012 14:17:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336054622!23271568!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_DONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3231 invoked from network); 3 May 2012 14:17:02 -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; 3 May 2012 14:17:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 15:17:01 +0100 Message-Id: <4FA2AF7C0200007800081649@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 15:17:00 +0100 From: "Jan Beulich" To: "Eddie Dong" References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Jun Nakajima , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 15:42, "Dong, Eddie" wrote: >> > The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >> > Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state > the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have > real usage case to test so far. > > We will provide #1 quickly, but for #2, can Aravindh provide test if we get > the patch ready? > >> >> >> >> >> Anyone except perhaps LOCK - none of them should have any effect >> >> other than making the instruction longer. >> >> >> > LOCK can never be used as prefix of INT nn instruction, nor can REPx >> prefix. >> > Can you provide more details as for this concern? >> >> The only prefix that is documented to cause #UD here is LOCK. All > > In #UD case (fault), the guest RIP is not advanced per SDM, and therefore > guest will either > spin in the previous LOCK instruction, or advance the IP to next instruction > by guest #UD handler. > I didn't see emulator could advance IP to the next instruction (INT nn) for > LOCK prefix. > Do I miss something? I'm sure you misunderstand me. I was saying that LOCK is the only prefix we can validly assume was not present on the original instruction. Any other prefix could be present, and should count towards the instruction length. Note the __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ and (after the recent change for INT nn) __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ which both use hard coded values. Furthermore, for Aravindh's use case where there might not even be an "original instruction" (i.e. injecting an interrupt/exception for reasons other than emulating a respective instruction), advancing IP seems bogus to me altogether. >> other prefixes should consequently be considered ignored, and so >> should the emulation do (and properly handle resulting instruction >> lengths). >> > The behavior is un-defined per SDM in this case, so either solution should be > fine :) Can you please point me to where this is being stated? I particularly doubt that for operand and address size prefixes as well as on 64-bit - since they are documented to be ignored there - CS, DS, ES, and SS segment prefixes... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:27:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwzy-0008FO-HW; Thu, 03 May 2012 14:27:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwzy-0008FJ-40 for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:27:14 +0000 Received: from [85.158.143.35:41645] by server-1.bemta-4.messagelabs.com id 4D/9A-20925-1C592AF4; Thu, 03 May 2012 14:27:13 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-14.tower-21.messagelabs.com!1336055231!14031336!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8716 invoked from network); 3 May 2012 14:27:12 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 14:27:12 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPwzv-0005pg-75 for xen-devel@lists.xensource.com; Thu, 03 May 2012 07:27:11 -0700 Date: Thu, 3 May 2012 07:27:11 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336055231213-5683345.post@n5.nabble.com> In-Reply-To: <20120503140045.GP2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ClBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlCj4gCj4gT24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMDU6 Mjg6NDRBTSAtMDcwMCwgRmFudHUgd3JvdGU6Cj4+IAo+PiBBYm91dCBxeGwgdGhlcmUgYXJlIHBy b2JsZW1zIGFib3V0IHZpZGVvcmFtIG5vdCBhbGxvY2F0ZWQgb3Igbm90IHVzZWQKPj4gb3ZlciA0 Cj4+IG1iIChzYW1lIGFzIGRlZmF1bHQgY2lycnVzIHZnYSkuCj4+IEF0IHRoZSBtb21lbnQgSSBo YXZlbid0IGZvdW5kIHNvbHV0aW9uIGZvciB0aGlzIHByb2JsZW0sIHByb2JhYmx5IHNvbWUKPj4g YnVnZml4IGFuZC9vciBjaGFuZ2UgYXJlIG5lZWRlZCBvbiB4ZW4uCj4+IAo+IAo+IElzIHRoaXMg YSByZWdyZXNzaW9uIGluIHhlbi11bnN0YWJsZSBjb21wYXJlZCB0byB4ZW4gNC4xID8gCj4gCj4g YWZhaWsgeW91IGNhbiBnZXQgYXQgbGVhc3QgMTYgTUIgb2YgdmlkZW8gbWVtb3J5IGZvciBIVk0g Z3Vlc3Qgd2l0aCBYZW4KPiA0LjEuCj4gCj4gLS0gUGFzaQo+IAo+IAo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlz dAo+IFhlbi1kZXZlbEAueGVuCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4gClRo YW5rcyBmb3IgcmVwbHkKUHJvYmFibHkgeGVuLXVuc3RhYmxlIHdpdGggcWVtdSB1cHN0cmVhbSBk b2Vzbid0IHN1cHBvcnQgdmlkZW9yYW0gc2V0dGluZy4KcXhsIGRlZmF1bHQgdmlkZW9yYW0gaXMg NjQgbWIgYnV0IEkgYWxzbyB0cmllZCB0byBzZXQgMTYgbWIgd2l0aG91dCByZXN1bHQsCml0IGFs d2F5cyBzZWUgb25seSA0IG1iLCBub3QgZW5vdWdoIGZvciBjb3JyZWN0IHdvcmtpbmcgcXhsLgoK LS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5h YmJsZS5jb20vVW5hYmxlLXRvLWdldC1RWEwtdmdhLXdvcmtpbmctdHA1NjY3OTE5cDU2ODMzNDUu aHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJi bGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz dHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 03 14:27:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwzy-0008FO-HW; Thu, 03 May 2012 14:27:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPwzy-0008FJ-40 for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:27:14 +0000 Received: from [85.158.143.35:41645] by server-1.bemta-4.messagelabs.com id 4D/9A-20925-1C592AF4; Thu, 03 May 2012 14:27:13 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-14.tower-21.messagelabs.com!1336055231!14031336!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8716 invoked from network); 3 May 2012 14:27:12 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 14:27:12 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPwzv-0005pg-75 for xen-devel@lists.xensource.com; Thu, 03 May 2012 07:27:11 -0700 Date: Thu, 3 May 2012 07:27:11 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336055231213-5683345.post@n5.nabble.com> In-Reply-To: <20120503140045.GP2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ClBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlCj4gCj4gT24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMDU6 Mjg6NDRBTSAtMDcwMCwgRmFudHUgd3JvdGU6Cj4+IAo+PiBBYm91dCBxeGwgdGhlcmUgYXJlIHBy b2JsZW1zIGFib3V0IHZpZGVvcmFtIG5vdCBhbGxvY2F0ZWQgb3Igbm90IHVzZWQKPj4gb3ZlciA0 Cj4+IG1iIChzYW1lIGFzIGRlZmF1bHQgY2lycnVzIHZnYSkuCj4+IEF0IHRoZSBtb21lbnQgSSBo YXZlbid0IGZvdW5kIHNvbHV0aW9uIGZvciB0aGlzIHByb2JsZW0sIHByb2JhYmx5IHNvbWUKPj4g YnVnZml4IGFuZC9vciBjaGFuZ2UgYXJlIG5lZWRlZCBvbiB4ZW4uCj4+IAo+IAo+IElzIHRoaXMg YSByZWdyZXNzaW9uIGluIHhlbi11bnN0YWJsZSBjb21wYXJlZCB0byB4ZW4gNC4xID8gCj4gCj4g YWZhaWsgeW91IGNhbiBnZXQgYXQgbGVhc3QgMTYgTUIgb2YgdmlkZW8gbWVtb3J5IGZvciBIVk0g Z3Vlc3Qgd2l0aCBYZW4KPiA0LjEuCj4gCj4gLS0gUGFzaQo+IAo+IAo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlz dAo+IFhlbi1kZXZlbEAueGVuCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCj4gClRo YW5rcyBmb3IgcmVwbHkKUHJvYmFibHkgeGVuLXVuc3RhYmxlIHdpdGggcWVtdSB1cHN0cmVhbSBk b2Vzbid0IHN1cHBvcnQgdmlkZW9yYW0gc2V0dGluZy4KcXhsIGRlZmF1bHQgdmlkZW9yYW0gaXMg NjQgbWIgYnV0IEkgYWxzbyB0cmllZCB0byBzZXQgMTYgbWIgd2l0aG91dCByZXN1bHQsCml0IGFs d2F5cyBzZWUgb25seSA0IG1iLCBub3QgZW5vdWdoIGZvciBjb3JyZWN0IHdvcmtpbmcgcXhsLgoK LS0KVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5h YmJsZS5jb20vVW5hYmxlLXRvLWdldC1RWEwtdmdhLXdvcmtpbmctdHA1NjY3OTE5cDU2ODMzNDUu aHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJi bGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz dHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 03 14:30:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:30:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx2s-0008Kf-4f; Thu, 03 May 2012 14:30:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx2q-0008Ka-KL for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:30:12 +0000 Received: from [85.158.139.83:9238] by server-1.bemta-5.messagelabs.com id 4D/7A-28458-37692AF4; Thu, 03 May 2012 14:30:11 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-12.tower-182.messagelabs.com!1336055410!26618675!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32479 invoked from network); 3 May 2012 14:30:11 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 14:30:11 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SPx2i-0003GK-Fj for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:30:06 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 16:30:04 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 16:30:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Thu, 3 May 2012 14:23:20 +0000 (UTC) Lines: 24 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Stefano, I'm also using ubuntu 11.04 HVM domain with xen 4.1.0. If I enable xen_platform_pci then I get busybox error. If I say xen_platform_pci=0 then it boots fine. I make passthrough devices available by using pci-stub module as pci_back is ntworking for me. [CONFIG_XEN_PCIDEV_BACKEND=y instead of m] When I provide these pci devices either by config file or by pci-attach my system turns blank. I read your post and tried with ubuntu 10.04 as guest. But I run into same problem. Should I have to create a kernel image inside d guest wid al configurations enabled in domu as mentioned in http://wiki.xensource.com/xenwiki/XenParavirtOps Let me know where I'm going wrong or else let me know the solution to get it working on 11.04. FYI: PCI devices are nvidia graphics card _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:30:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:30:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx2s-0008Kf-4f; Thu, 03 May 2012 14:30:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx2q-0008Ka-KL for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:30:12 +0000 Received: from [85.158.139.83:9238] by server-1.bemta-5.messagelabs.com id 4D/7A-28458-37692AF4; Thu, 03 May 2012 14:30:11 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-12.tower-182.messagelabs.com!1336055410!26618675!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32479 invoked from network); 3 May 2012 14:30:11 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 3 May 2012 14:30:11 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SPx2i-0003GK-Fj for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:30:06 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 16:30:04 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 16:30:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Thu, 3 May 2012 14:23:20 +0000 (UTC) Lines: 24 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Stefano, I'm also using ubuntu 11.04 HVM domain with xen 4.1.0. If I enable xen_platform_pci then I get busybox error. If I say xen_platform_pci=0 then it boots fine. I make passthrough devices available by using pci-stub module as pci_back is ntworking for me. [CONFIG_XEN_PCIDEV_BACKEND=y instead of m] When I provide these pci devices either by config file or by pci-attach my system turns blank. I read your post and tried with ubuntu 10.04 as guest. But I run into same problem. Should I have to create a kernel image inside d guest wid al configurations enabled in domu as mentioned in http://wiki.xensource.com/xenwiki/XenParavirtOps Let me know where I'm going wrong or else let me know the solution to get it working on 11.04. FYI: PCI devices are nvidia graphics card _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:36:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:36:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx8D-0000Aq-Mq; Thu, 03 May 2012 14:35:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx8C-0000Ah-S2 for xen-devel@lists.xen.org; Thu, 03 May 2012 14:35:45 +0000 Received: from [85.158.143.99:58258] by server-1.bemta-4.messagelabs.com id 30/38-20925-0C792AF4; Thu, 03 May 2012 14:35:44 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336055742!26375563!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30837 invoked from network); 3 May 2012 14:35:43 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:35:43 -0000 Received: by eaaf11 with SMTP id f11so598648eaa.32 for ; Thu, 03 May 2012 07:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=yoHj7sNbE0cpQxrP38J6WjNDXfUya56GlanqxJGAk5k=; b=E/XoUStrhByfQEpcsC4CCc6eLebSu35Dx/4gqVtLMO59BEZyu2MWwwwSMpZF1JUZI5 KDYvDVE9a76IP0hqbvk1GSxcROsZCVl+oEIEbXtd32eIjcfzHdV6Z2vdhESeCP/0uAZN sVddlqAEhJf/sFZhJPacDHBiMNcBm8jx51izQTfNlh4Z6Cp1Wq09BP8nEU6ixleRHK6e nlf+rd1yqVJMMPYwIZJ3W5Y6AgdOZxCjQeWtRsP03r3MUjH838ua0AexLUqOXMknbYJ0 yD1Kr2lGf5btg0I6KYo83xrB/o5JFxzBsIs3/kvNMyMUZFSb6BndjwThedwPYfACYPy3 G3BA== Received: by 10.213.25.220 with SMTP id a28mr336268ebc.88.1336055742197; Thu, 03 May 2012 07:35:42 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id p57sm26279129eei.8.2012.05.03.07.35.39 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 07:35:41 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 15:35:36 +0100 From: Keir Fraser To: "Dong, Eddie" , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsIAAFYgAgADJ91CAABJnmw== In-Reply-To: Mime-version: 1.0 Cc: Aravindh Puthiyaparambil , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/2012 14:42, "Dong, Eddie" wrote: >>> The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >>> Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state > the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real > usage case to test so far. Yes, this sounds great. -- Keir > We will provide #1 quickly, but for #2, can Aravindh provide test if we get > the patch ready? > >> >>>> >>>> Anyone except perhaps LOCK - none of them should have any effect >>>> other than making the instruction longer. >>>> >>> LOCK can never be used as prefix of INT nn instruction, nor can REPx >> prefix. >>> Can you provide more details as for this concern? >> >> The only prefix that is documented to cause #UD here is LOCK. All > > In #UD case (fault), the guest RIP is not advanced per SDM, and therefore > guest will either > spin in the previous LOCK instruction, or advance the IP to next instruction > by guest #UD handler. > I didn't see emulator could advance IP to the next instruction (INT nn) for > LOCK prefix. > Do I miss something? > >> other prefixes should consequently be considered ignored, and so >> should the emulation do (and properly handle resulting instruction >> lengths). >> > The behavior is un-defined per SDM in this case, so either solution should be > fine :) > > Thx, Eddie > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:36:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:36:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx8D-0000Aq-Mq; Thu, 03 May 2012 14:35:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPx8C-0000Ah-S2 for xen-devel@lists.xen.org; Thu, 03 May 2012 14:35:45 +0000 Received: from [85.158.143.99:58258] by server-1.bemta-4.messagelabs.com id 30/38-20925-0C792AF4; Thu, 03 May 2012 14:35:44 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336055742!26375563!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30837 invoked from network); 3 May 2012 14:35:43 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:35:43 -0000 Received: by eaaf11 with SMTP id f11so598648eaa.32 for ; Thu, 03 May 2012 07:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=yoHj7sNbE0cpQxrP38J6WjNDXfUya56GlanqxJGAk5k=; b=E/XoUStrhByfQEpcsC4CCc6eLebSu35Dx/4gqVtLMO59BEZyu2MWwwwSMpZF1JUZI5 KDYvDVE9a76IP0hqbvk1GSxcROsZCVl+oEIEbXtd32eIjcfzHdV6Z2vdhESeCP/0uAZN sVddlqAEhJf/sFZhJPacDHBiMNcBm8jx51izQTfNlh4Z6Cp1Wq09BP8nEU6ixleRHK6e nlf+rd1yqVJMMPYwIZJ3W5Y6AgdOZxCjQeWtRsP03r3MUjH838ua0AexLUqOXMknbYJ0 yD1Kr2lGf5btg0I6KYo83xrB/o5JFxzBsIs3/kvNMyMUZFSb6BndjwThedwPYfACYPy3 G3BA== Received: by 10.213.25.220 with SMTP id a28mr336268ebc.88.1336055742197; Thu, 03 May 2012 07:35:42 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id p57sm26279129eei.8.2012.05.03.07.35.39 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 07:35:41 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 03 May 2012 15:35:36 +0100 From: Keir Fraser To: "Dong, Eddie" , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Thread-Index: AQHNHtM0VD+ni7wmHU+wvDQuwY5bFZa2QflA//+EyoCAAX2xsIAAFYgAgADJ91CAABJnmw== In-Reply-To: Mime-version: 1.0 Cc: Aravindh Puthiyaparambil , "Nakajima, Jun" , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/2012 14:42, "Dong, Eddie" wrote: >>> The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >>> Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state > the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real > usage case to test so far. Yes, this sounds great. -- Keir > We will provide #1 quickly, but for #2, can Aravindh provide test if we get > the patch ready? > >> >>>> >>>> Anyone except perhaps LOCK - none of them should have any effect >>>> other than making the instruction longer. >>>> >>> LOCK can never be used as prefix of INT nn instruction, nor can REPx >> prefix. >>> Can you provide more details as for this concern? >> >> The only prefix that is documented to cause #UD here is LOCK. All > > In #UD case (fault), the guest RIP is not advanced per SDM, and therefore > guest will either > spin in the previous LOCK instruction, or advance the IP to next instruction > by guest #UD handler. > I didn't see emulator could advance IP to the next instruction (INT nn) for > LOCK prefix. > Do I miss something? > >> other prefixes should consequently be considered ignored, and so >> should the emulation do (and properly handle resulting instruction >> lengths). >> > The behavior is un-defined per SDM in this case, so either solution should be > fine :) > > Thx, Eddie > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:48:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:48:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxJw-0000hU-7F; Thu, 03 May 2012 14:47:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxJu-0000hP-QT for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:47:51 +0000 Received: from [85.158.143.35:51243] by server-1.bemta-4.messagelabs.com id 7A/2B-20925-69A92AF4; Thu, 03 May 2012 14:47:50 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336056468!14999466!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1867 invoked from network); 3 May 2012 14:47:48 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP; 3 May 2012 14:47:48 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPxJs-0004Xh-0M; Thu, 03 May 2012 14:47:48 +0000 Message-ID: <4FA29A92.2040601@canonical.com> Date: Thu, 03 May 2012 16:47:46 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> In-Reply-To: <4FA280DA.9080505@canonical.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6660960853952199437==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6660960853952199437== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2866F1A5A83D44748554318C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2866F1A5A83D44748554318C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 14:58, Stefan Bader wrote: >>>>> So this shoudl solve the problem for the bootup processor. >>>>>> >>>>>> -boris >>>>>> >>>>>> >>>>>>> + }; >>>>>>> + int ret =3D 0; >>>>>>> + >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we = only >>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>> + return 0; >>>>>>> + >>>>>>> + if (reg =3D=3D APIC_LVR) >>>>>>> + return 0x10; >>>>>>> + >>>>>>> + if (reg !=3D APIC_ID) >>>>>>> + return 0; >>>>>>> + >>>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>>> + if (ret) >>>>>>> + return 0; >>>>>>> + >>>>>>> + return op.u.pcpu_info.apic_id; >>>>>>> } >>>>>>> >>>>>>> static void xen_apic_write(u32 reg, u32 val) >=20 > I added debugging to all exit paths that could return 0 (which is what = the > boot_cpu_physical_apicid is set to with that patch. Which would only le= ave the > case of the HV call returning the wrong value somehow... >=20 Hmmm, so xen_apic_read is still correct... [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(20) [ 0.000000] xxx xen_apic_read -> 10 [ 0.000000] boot_cpu_physical_apicid =3D 0 [ 0.000000] xxx xen_apic_read(30) [ 0.000000] +- apic version =3D 10 there seems to be a slightly strange tweak (at least for me) in read_apic= _id... static inline unsigned int read_apic_id(void) { unsigned int reg; reg =3D apic_read(APIC_ID); // calls apic->read(reg) return apic->get_apic_id(reg); } --------------enig2866F1A5A83D44748554318C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPopqSAAoJEOhnXe7L7s6jg2YQANpYYYt5zNi03Av89bRO6fNJ VDnDV03oTDNUR9cbra7OgjsQ3GkQSVwLTySa3LtSj7OEgwLQN0R8aeKgW5ONMsA/ DPYfUfDtlZAom4iuXv+GsDtFoaB9kv6CIewhgJGE2ySFLg1Dm2INsjPRXrigAPNH aj5IEO3CDDi2x8BMDCXQ7RMUwuu1dIKd4ZOAGdq7k4U3QDwbYZW5mCGVHQOXj3Rc h7YdQwzyrJekTD/0aiGE8YgpOt2BUtq7mUtUVTJHtI2OzPYDhsdtHhzq/g6yBnBc 5Tgg2t18l1jV14PuM8goKVYwuu+XWhrrCVvht4zRJpZuvH8eTElr6CeJlYC5oAbd +B8hwP1/+liUxhFwq1WK6QGF5kU+uGT6F5stIsFr6dUJxWY8CRQ6NtG9arqxaCD+ +83zOukaUNBKtNoFjsKt6tR/aBK+6tdAtXkanKXu6samTwD0E1id8vlM4hIZBZTe qa5kg8GbiGyovOrPEtTpyZ5RrxGURQ3UgydOdCOK9K3qwVWW3d0z8fMEGLVUomYv 4fFQNk864QkrMpG8+HawwvhXt705v90r9FPDJlamVfbWzgDgaF6NIJlxUloHPsTQ 91pCnWgeWYfZufu8BcBDcF3kSH6q6/tYzZOr0sM6XnuBJFzThcHqc+h8WrOArhd/ yXD++4Ml8e3f6iO1tF5o =oDlt -----END PGP SIGNATURE----- --------------enig2866F1A5A83D44748554318C-- --===============6660960853952199437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6660960853952199437==-- From xen-devel-bounces@lists.xen.org Thu May 03 14:48:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 14:48:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxJw-0000hU-7F; Thu, 03 May 2012 14:47:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxJu-0000hP-QT for xen-devel@lists.xensource.com; Thu, 03 May 2012 14:47:51 +0000 Received: from [85.158.143.35:51243] by server-1.bemta-4.messagelabs.com id 7A/2B-20925-69A92AF4; Thu, 03 May 2012 14:47:50 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336056468!14999466!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1867 invoked from network); 3 May 2012 14:47:48 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-11.tower-21.messagelabs.com with SMTP; 3 May 2012 14:47:48 -0000 Received: from p5b2e479b.dip.t-dialin.net ([91.46.71.155] 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 ) id 1SPxJs-0004Xh-0M; Thu, 03 May 2012 14:47:48 +0000 Message-ID: <4FA29A92.2040601@canonical.com> Date: Thu, 03 May 2012 16:47:46 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Boris Ostrovsky References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> In-Reply-To: <4FA280DA.9080505@canonical.com> X-Enigmail-Version: 1.4 Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6660960853952199437==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6660960853952199437== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2866F1A5A83D44748554318C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2866F1A5A83D44748554318C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 14:58, Stefan Bader wrote: >>>>> So this shoudl solve the problem for the bootup processor. >>>>>> >>>>>> -boris >>>>>> >>>>>> >>>>>>> + }; >>>>>>> + int ret =3D 0; >>>>>>> + >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we = only >>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>> + return 0; >>>>>>> + >>>>>>> + if (reg =3D=3D APIC_LVR) >>>>>>> + return 0x10; >>>>>>> + >>>>>>> + if (reg !=3D APIC_ID) >>>>>>> + return 0; >>>>>>> + >>>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>>> + if (ret) >>>>>>> + return 0; >>>>>>> + >>>>>>> + return op.u.pcpu_info.apic_id; >>>>>>> } >>>>>>> >>>>>>> static void xen_apic_write(u32 reg, u32 val) >=20 > I added debugging to all exit paths that could return 0 (which is what = the > boot_cpu_physical_apicid is set to with that patch. Which would only le= ave the > case of the HV call returning the wrong value somehow... >=20 Hmmm, so xen_apic_read is still correct... [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(20) [ 0.000000] xxx xen_apic_read -> 10 [ 0.000000] boot_cpu_physical_apicid =3D 0 [ 0.000000] xxx xen_apic_read(30) [ 0.000000] +- apic version =3D 10 there seems to be a slightly strange tweak (at least for me) in read_apic= _id... static inline unsigned int read_apic_id(void) { unsigned int reg; reg =3D apic_read(APIC_ID); // calls apic->read(reg) return apic->get_apic_id(reg); } --------------enig2866F1A5A83D44748554318C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPopqSAAoJEOhnXe7L7s6jg2YQANpYYYt5zNi03Av89bRO6fNJ VDnDV03oTDNUR9cbra7OgjsQ3GkQSVwLTySa3LtSj7OEgwLQN0R8aeKgW5ONMsA/ DPYfUfDtlZAom4iuXv+GsDtFoaB9kv6CIewhgJGE2ySFLg1Dm2INsjPRXrigAPNH aj5IEO3CDDi2x8BMDCXQ7RMUwuu1dIKd4ZOAGdq7k4U3QDwbYZW5mCGVHQOXj3Rc h7YdQwzyrJekTD/0aiGE8YgpOt2BUtq7mUtUVTJHtI2OzPYDhsdtHhzq/g6yBnBc 5Tgg2t18l1jV14PuM8goKVYwuu+XWhrrCVvht4zRJpZuvH8eTElr6CeJlYC5oAbd +B8hwP1/+liUxhFwq1WK6QGF5kU+uGT6F5stIsFr6dUJxWY8CRQ6NtG9arqxaCD+ +83zOukaUNBKtNoFjsKt6tR/aBK+6tdAtXkanKXu6samTwD0E1id8vlM4hIZBZTe qa5kg8GbiGyovOrPEtTpyZ5RrxGURQ3UgydOdCOK9K3qwVWW3d0z8fMEGLVUomYv 4fFQNk864QkrMpG8+HawwvhXt705v90r9FPDJlamVfbWzgDgaF6NIJlxUloHPsTQ 91pCnWgeWYfZufu8BcBDcF3kSH6q6/tYzZOr0sM6XnuBJFzThcHqc+h8WrOArhd/ yXD++4Ml8e3f6iO1tF5o =oDlt -----END PGP SIGNATURE----- --------------enig2866F1A5A83D44748554318C-- --===============6660960853952199437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6660960853952199437==-- From xen-devel-bounces@lists.xen.org Thu May 03 14:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPxRD-0000tL-55; Thu, 03 May 2012 14:55:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxRC-0000tG-Jy for xen-devel@lists.xen.org; Thu, 03 May 2012 14:55:22 +0000 Received: from [85.158.143.35:63945] by server-1.bemta-4.messagelabs.com id 5C/A6-20925-95C92AF4; Thu, 03 May 2012 14:55:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336056917!13597098!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31444 invoked from network); 3 May 2012 14:55:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:55:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12277354" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 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; Thu, 3 May 2012 15:55:16 +0100 Message-ID: <1336056915.20716.96.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "netdev@vger.kernel.org" Date: Thu, 3 May 2012 15:55:15 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Alexander Duyck , Bart Van Assche , Eric Dumazet , "Michael S. Tsirkin" , David VomLehn , xen-devel , David Miller , Ian Campbell Subject: [Xen-devel] [PATCH v5 0/9] skb paged fragment destructors X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following series makes use of the skb fragment API (which is in 3.2 +) to add a per-paged-fragment destructor callback. This can be used by creators of skbs who are interested in the lifecycle of the pages included in that skb after they have handed it off to the network stack. The mail at [0] contains some more background and rationale but basically the completed series will allow entities which inject pages into the networking stack to receive a notification when the stack has really finished with those pages (i.e. including retransmissions, clones, pull-ups etc) and not just when the original skb is finished with, which is beneficial to many subsystems which wish to inject pages into the network stack without giving up full ownership of those page's lifecycle. It implements something broadly along the lines of what was described in [1]. I have also included a patch to the RPC subsystem which uses this API to fix the bug which I describe at [2]. I've also had some interest from David VemLehn and Bart Van Assche regarding using this functionality in the context of vmsplice and iSCSI targets respectively (I think). Changes since last time: * The big change is that the patches now explicitly align the "nr_frags" member of the shinfo, as suggested by Alexander Duyck. This ensures that the placement is optimal irrespective of page size (in particular the variation of MAX_SKB_FRAGS). It is still the case that for 4k pages a maximum MTU frame + SKB_PAD + shinfo, still fit within 2048k. * As part of the preceeding I squashed the patches manipulating the shinfo layout and alignment into a single patch (which is far more coherent than the piecemeal approach used previously) * I crushed "net: only allow paged fragments with the same destructor to be coalesced." into the baseline patch (Ben Hutchings) * Added and used skb_shinfo_init to centralise several copies of that code. * Reduced CC list on "net: add paged frag destructor support to kernel_sendpage", it was rather long and seemed a bit overly spammy on the non-netdev recipients. Changes since time before: * Added skb_orphan_frags API for the use of recipients of SKBs who may hold onto the SKB for a long time (this is analogous to skb_orphan). This was pointed out by Michael. The TUN driver is currently the only user. * I can't for the life of me get anything to actually hit this code path. I've been trying with an NFS server running in a Xen HVM domain with emulated (e.g. tap) networking and a client in domain 0, using the NFS fix in this series which generates SKBs with destructors set, so far -- nothing. I suspect that lack of TSO/GSO etc on the TAP interface is causing the frags to be copied to normal pages during skb_segment(). * Various fixups related to the change of alignment/padding in shinfo, in particular to build_skb as pointed out by Eric. * Tweaked ordering of shinfo members to ensure that all hotpath variables up to and including the first frag fit within (and are aligned to) a single 64 byte cache line. (Eric again) I ran a monothread UDP benchmark (similar to that described by Eric in e52fcb2462ac) and don't see any difference in pps throughput, it was ~810,000 pps both before and after. Cheers, Ian. [0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2 [1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2 [2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 14:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPxRD-0000tL-55; Thu, 03 May 2012 14:55:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxRC-0000tG-Jy for xen-devel@lists.xen.org; Thu, 03 May 2012 14:55:22 +0000 Received: from [85.158.143.35:63945] by server-1.bemta-4.messagelabs.com id 5C/A6-20925-95C92AF4; Thu, 03 May 2012 14:55:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336056917!13597098!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31444 invoked from network); 3 May 2012 14:55:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:55:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12277354" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 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; Thu, 3 May 2012 15:55:16 +0100 Message-ID: <1336056915.20716.96.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "netdev@vger.kernel.org" Date: Thu, 3 May 2012 15:55:15 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Alexander Duyck , Bart Van Assche , Eric Dumazet , "Michael S. Tsirkin" , David VomLehn , xen-devel , David Miller , Ian Campbell Subject: [Xen-devel] [PATCH v5 0/9] skb paged fragment destructors X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following series makes use of the skb fragment API (which is in 3.2 +) to add a per-paged-fragment destructor callback. This can be used by creators of skbs who are interested in the lifecycle of the pages included in that skb after they have handed it off to the network stack. The mail at [0] contains some more background and rationale but basically the completed series will allow entities which inject pages into the networking stack to receive a notification when the stack has really finished with those pages (i.e. including retransmissions, clones, pull-ups etc) and not just when the original skb is finished with, which is beneficial to many subsystems which wish to inject pages into the network stack without giving up full ownership of those page's lifecycle. It implements something broadly along the lines of what was described in [1]. I have also included a patch to the RPC subsystem which uses this API to fix the bug which I describe at [2]. I've also had some interest from David VemLehn and Bart Van Assche regarding using this functionality in the context of vmsplice and iSCSI targets respectively (I think). Changes since last time: * The big change is that the patches now explicitly align the "nr_frags" member of the shinfo, as suggested by Alexander Duyck. This ensures that the placement is optimal irrespective of page size (in particular the variation of MAX_SKB_FRAGS). It is still the case that for 4k pages a maximum MTU frame + SKB_PAD + shinfo, still fit within 2048k. * As part of the preceeding I squashed the patches manipulating the shinfo layout and alignment into a single patch (which is far more coherent than the piecemeal approach used previously) * I crushed "net: only allow paged fragments with the same destructor to be coalesced." into the baseline patch (Ben Hutchings) * Added and used skb_shinfo_init to centralise several copies of that code. * Reduced CC list on "net: add paged frag destructor support to kernel_sendpage", it was rather long and seemed a bit overly spammy on the non-netdev recipients. Changes since time before: * Added skb_orphan_frags API for the use of recipients of SKBs who may hold onto the SKB for a long time (this is analogous to skb_orphan). This was pointed out by Michael. The TUN driver is currently the only user. * I can't for the life of me get anything to actually hit this code path. I've been trying with an NFS server running in a Xen HVM domain with emulated (e.g. tap) networking and a client in domain 0, using the NFS fix in this series which generates SKBs with destructors set, so far -- nothing. I suspect that lack of TSO/GSO etc on the TAP interface is causing the frags to be copied to normal pages during skb_segment(). * Various fixups related to the change of alignment/padding in shinfo, in particular to build_skb as pointed out by Eric. * Tweaked ordering of shinfo members to ensure that all hotpath variables up to and including the first frag fit within (and are aligned to) a single 64 byte cache line. (Eric again) I ran a monothread UDP benchmark (similar to that described by Eric in e52fcb2462ac) and don't see any difference in pps throughput, it was ~810,000 pps both before and after. Cheers, Ian. [0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2 [1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2 [2] http://marc.info/?l=linux-nfs&m=122424132729720&w=2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:00:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:00:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxVh-00013S-So; Thu, 03 May 2012 15:00:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxVg-00011U-DD for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:00:00 +0000 Received: from [85.158.143.35:28626] by server-2.bemta-4.messagelabs.com id 67/78-17550-F6D92AF4; Thu, 03 May 2012 14:59:59 +0000 X-Env-Sender: Ross.Philipson@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336057197!14638339!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22630 invoked from network); 3 May 2012 14:59:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:59:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="193248991" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10:57:08 -0400 Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 3 May 2012 10:57:08 -0400 From: Ross Philipson To: "xen-devel@lists.xensource.com" Date: Thu, 3 May 2012 10:57:11 -0400 Thread-Topic: vTPM patch does not apply Thread-Index: Ac0pPJox2vZ9uU+/T6OBjCEOOX+bkA== Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I was trying to build the vtpm bits in unstable and the patch for the vtpm was failing to apply. It worked fine before this commit. http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c5b7d49ca3ee Since it is a patch file, maybe the change should read something more like: +-LDFLAGS += -lgmp ++LDLIBS += -lgmp Thanks Ross Philipson Senior Software Engineer Citrix Systems, Inc 14 Crosby Drive Bedford, MA 01730 781-301-7949 ross.philipson@citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:00:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:00:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxVh-00013S-So; Thu, 03 May 2012 15:00:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxVg-00011U-DD for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:00:00 +0000 Received: from [85.158.143.35:28626] by server-2.bemta-4.messagelabs.com id 67/78-17550-F6D92AF4; Thu, 03 May 2012 14:59:59 +0000 X-Env-Sender: Ross.Philipson@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336057197!14638339!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22630 invoked from network); 3 May 2012 14:59:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 14:59:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330923600"; d="scan'208";a="193248991" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 10:57:08 -0400 Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 3 May 2012 10:57:08 -0400 From: Ross Philipson To: "xen-devel@lists.xensource.com" Date: Thu, 3 May 2012 10:57:11 -0400 Thread-Topic: vTPM patch does not apply Thread-Index: Ac0pPJox2vZ9uU+/T6OBjCEOOX+bkA== Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I was trying to build the vtpm bits in unstable and the patch for the vtpm was failing to apply. It worked fine before this commit. http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c5b7d49ca3ee Since it is a patch file, maybe the change should read something more like: +-LDFLAGS += -lgmp ++LDLIBS += -lgmp Thanks Ross Philipson Senior Software Engineer Citrix Systems, Inc 14 Crosby Drive Bedford, MA 01730 781-301-7949 ross.philipson@citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:16:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:16:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxl4-0001Jb-E4; Thu, 03 May 2012 15:15:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxl2-0001JW-JC for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:15:52 +0000 Received: from [85.158.143.35:46016] by server-3.bemta-4.messagelabs.com id E1/9C-05853-721A2AF4; Thu, 03 May 2012 15:15:51 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336058147!15003606!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23521 invoked from network); 3 May 2012 15:15:49 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:15:49 -0000 Received: by yhkk6 with SMTP id k6so1166601yhk.30 for ; Thu, 03 May 2012 08:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Iiv+AHyHWzuEm02mR6L4U4Cu86X753LOvTdFUFVxoOA=; b=D2r0d0Wbt5D/qAnx/zV6C7F4RHFUuhh7BliR11AOiy4cO00o1rF7djizWs7ItDKH3o 6qVzQ9xe8VIJhp3dNmoTcUOfHJF7yvxJgrwu/Dj9+LcLCnUgIMvL07hH7HUaKK2ZswUE uU8o9HT6WS+nXNT+E+5r2LgVscRL37cytTVrRBvQjphdUT9xTedYHUTbyQZ+gcLeLxdQ wxEvRbiq8gJAMTXZIscRoC+adWTi36zMbU4rQJYn30HMooJO8oQWBZw87Jpx37g05/Hu xBagwz2sGt34pQT9yL6G4RCQsLl1VB1tGzBJgpp/ZzronjGkHcrkqmqriSxJjg+xPe4i 9GPg== Received: by 10.236.76.226 with SMTP id b62mr3509795yhe.13.1336058146967; Thu, 03 May 2012 08:15:46 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id d63sm24671089yhh.17.2012.05.03.08.15.43 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 08:15:46 -0700 (PDT) Message-ID: <4FA2A11E.1060907@cantab.net> Date: Thu, 03 May 2012 16:15:42 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> In-Reply-To: <4FA27084.4030005@citrix.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 12:48, David Vrabel wrote: > On 01/05/12 17:37, Konrad Rzeszutek Wilk wrote: >> On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >>> Changelog v5 [since v4]: >>> - used populate_physmap, fixed bugs. >>> [v2-v4: not posted] >>> - reworked the code in setup.c to work properly. >>> [v1: https://lkml.org/lkml/2012/3/30/492] >>> - initial patchset >> >> One bug I found was that with 'dom0_mem=max:1G' (with and without these >> patches) I would get a bunch of >> >> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 >> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) >> >> where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine >> I ran on it. I figured it out that the difference was in the ACPI tables >> that are allocated - and that those regions - even though are returned >> back to the hypervisor, cannot be repopulated. I can't find the actual >> exact piece of code in the hypervisor to pin-point and say "Aha". > > It was tricky to track down what is going here but I think I see what's > happening. > > The problem pages (on the system I looked at) were located just before > the ISA memory region (so PFN < a0) and so they are mapped in the > bootstrap page tables and have an additional ref so are not immediately > freed when the page is released. They do get freed later on, presumably > when the page tables are swapped over. It's not the bootstrap page tables but those constructed in xen_setup_kernel_pagetable() but this has the same effect. > I think the mapping needs to be removed with > HYPERVISOR_update_va_mapping() before releasing the page. This is > already done for the ISA region in xen_ident_map_ISA(). And here's a patch that does this. I've not given it a lot of testing. This is on top of your 8/8 patch and your "xen/setup: Cap amount to populate based on current tot_pages count." patch is no longer needed. David 8<--------------------- >From 17900ce942ed34ccc85b8e6fbce392118d95d9d3 Mon Sep 17 00:00:00 2001 From: David Vrabel Date: Thu, 3 May 2012 15:57:00 +0100 Subject: [PATCH] xen: update VA mapping when releasing memory during setup In xen_memory_setup(), if a page that is being released has a VA mapping this must also be updated. Otherwise, the page will be not released completely -- it will still be referenced in Xen and won't be freed util the mapping is removed and this prevents it from being reallocated at a different PFN. This was already being done for the ISA memory region in xen_ident_map_ISA() but on many systems this was omitting a few pages as many systems marked a few pages below the ISA memory region as reserved in the e820 map. Signed-off-by: David Vrabel --- arch/x86/xen/enlighten.c | 1 - arch/x86/xen/mmu.c | 23 ----------------------- arch/x86/xen/setup.c | 41 ++++++++++++++++++++++++++++++++++------- arch/x86/xen/xen-ops.h | 1 - 4 files changed, 34 insertions(+), 32 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..ff9a20a 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1306,7 +1306,6 @@ asmlinkage void __init xen_start_kernel(void) xen_raw_console_write("mapping kernel into physical memory\n"); pgd = xen_setup_kernel_pagetable(pgd, xen_start_info->nr_pages); - xen_ident_map_ISA(); /* Allocate and initialize top and mid mfn levels for p2m structure */ xen_build_mfn_list_list(); diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..b756d8c 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) #endif } -void __init xen_ident_map_ISA(void) -{ - unsigned long pa; - - /* - * If we're dom0, then linear map the ISA machine addresses into - * the kernel's address space. - */ - if (!xen_initial_domain()) - return; - - xen_raw_printk("Xen: setup ISA identity maps\n"); - - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); - - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) - BUG(); - } - - xen_flush_tlb(); -} - static void __init xen_post_allocator_init(void) { pv_mmu_ops.set_pte = xen_set_pte; diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 506a3e6..d5f8714 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, return len; } + +static unsigned long __init xen_release_chunk(unsigned long start, + unsigned long end) +{ + return xen_do_chunk(start, end, true); +} + static unsigned long __init xen_populate_chunk( const struct e820entry *list, size_t map_size, unsigned long max_pfn, unsigned long *last_pfn, @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( } return done; } + +static void __init xen_set_identity_and_release_chunk( + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, + unsigned long *released, unsigned long *identity) +{ + unsigned long pfn; + + /* + * If the PFNs are currently mapped, the VA mapping also needs + * to be updated to be 1:1. + */ + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) + (void)HYPERVISOR_update_va_mapping( + (unsigned long)__va(pfn << PAGE_SHIFT), + mfn_pte(pfn, PAGE_KERNEL_IO), 0); + + if (start_pfn < nr_pages) + *released += xen_release_chunk( + start_pfn, min(end_pfn, nr_pages)); + + *identity += set_phys_range_identity(start_pfn, end_pfn); +} + static unsigned long __init xen_set_identity_and_release( const struct e820entry *list, size_t map_size, unsigned long nr_pages) { @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( if (entry->type == E820_RAM) end_pfn = PFN_UP(entry->addr); - if (start_pfn < end_pfn) { - if (start_pfn < nr_pages) - released += xen_do_chunk( - start_pfn, min(end_pfn, nr_pages), true); + if (start_pfn < end_pfn) + xen_set_identity_and_release_chunk( + start_pfn, end_pfn, nr_pages, + &released, &identity); - identity += set_phys_range_identity( - start_pfn, end_pfn); - } start = end; } } diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index b095739..506fa08 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); void xen_build_mfn_list_list(void); void xen_setup_machphys_mapping(void); pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); -void xen_ident_map_ISA(void); void xen_reserve_top(void); extern unsigned long xen_max_p2m_pfn; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:16:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:16:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxl4-0001Jb-E4; Thu, 03 May 2012 15:15:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxl2-0001JW-JC for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:15:52 +0000 Received: from [85.158.143.35:46016] by server-3.bemta-4.messagelabs.com id E1/9C-05853-721A2AF4; Thu, 03 May 2012 15:15:51 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336058147!15003606!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23521 invoked from network); 3 May 2012 15:15:49 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:15:49 -0000 Received: by yhkk6 with SMTP id k6so1166601yhk.30 for ; Thu, 03 May 2012 08:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Iiv+AHyHWzuEm02mR6L4U4Cu86X753LOvTdFUFVxoOA=; b=D2r0d0Wbt5D/qAnx/zV6C7F4RHFUuhh7BliR11AOiy4cO00o1rF7djizWs7ItDKH3o 6qVzQ9xe8VIJhp3dNmoTcUOfHJF7yvxJgrwu/Dj9+LcLCnUgIMvL07hH7HUaKK2ZswUE uU8o9HT6WS+nXNT+E+5r2LgVscRL37cytTVrRBvQjphdUT9xTedYHUTbyQZ+gcLeLxdQ wxEvRbiq8gJAMTXZIscRoC+adWTi36zMbU4rQJYn30HMooJO8oQWBZw87Jpx37g05/Hu xBagwz2sGt34pQT9yL6G4RCQsLl1VB1tGzBJgpp/ZzronjGkHcrkqmqriSxJjg+xPe4i 9GPg== Received: by 10.236.76.226 with SMTP id b62mr3509795yhe.13.1336058146967; Thu, 03 May 2012 08:15:46 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id d63sm24671089yhh.17.2012.05.03.08.15.43 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 08:15:46 -0700 (PDT) Message-ID: <4FA2A11E.1060907@cantab.net> Date: Thu, 03 May 2012 16:15:42 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> In-Reply-To: <4FA27084.4030005@citrix.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 12:48, David Vrabel wrote: > On 01/05/12 17:37, Konrad Rzeszutek Wilk wrote: >> On Mon, Apr 16, 2012 at 01:15:31PM -0400, Konrad Rzeszutek Wilk wrote: >>> Changelog v5 [since v4]: >>> - used populate_physmap, fixed bugs. >>> [v2-v4: not posted] >>> - reworked the code in setup.c to work properly. >>> [v1: https://lkml.org/lkml/2012/3/30/492] >>> - initial patchset >> >> One bug I found was that with 'dom0_mem=max:1G' (with and without these >> patches) I would get a bunch of >> >> (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152 >> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17) >> >> where the (0 of X), sometimes was 1, 2,3,4 or 17 -depending on the machine >> I ran on it. I figured it out that the difference was in the ACPI tables >> that are allocated - and that those regions - even though are returned >> back to the hypervisor, cannot be repopulated. I can't find the actual >> exact piece of code in the hypervisor to pin-point and say "Aha". > > It was tricky to track down what is going here but I think I see what's > happening. > > The problem pages (on the system I looked at) were located just before > the ISA memory region (so PFN < a0) and so they are mapped in the > bootstrap page tables and have an additional ref so are not immediately > freed when the page is released. They do get freed later on, presumably > when the page tables are swapped over. It's not the bootstrap page tables but those constructed in xen_setup_kernel_pagetable() but this has the same effect. > I think the mapping needs to be removed with > HYPERVISOR_update_va_mapping() before releasing the page. This is > already done for the ISA region in xen_ident_map_ISA(). And here's a patch that does this. I've not given it a lot of testing. This is on top of your 8/8 patch and your "xen/setup: Cap amount to populate based on current tot_pages count." patch is no longer needed. David 8<--------------------- >From 17900ce942ed34ccc85b8e6fbce392118d95d9d3 Mon Sep 17 00:00:00 2001 From: David Vrabel Date: Thu, 3 May 2012 15:57:00 +0100 Subject: [PATCH] xen: update VA mapping when releasing memory during setup In xen_memory_setup(), if a page that is being released has a VA mapping this must also be updated. Otherwise, the page will be not released completely -- it will still be referenced in Xen and won't be freed util the mapping is removed and this prevents it from being reallocated at a different PFN. This was already being done for the ISA memory region in xen_ident_map_ISA() but on many systems this was omitting a few pages as many systems marked a few pages below the ISA memory region as reserved in the e820 map. Signed-off-by: David Vrabel --- arch/x86/xen/enlighten.c | 1 - arch/x86/xen/mmu.c | 23 ----------------------- arch/x86/xen/setup.c | 41 ++++++++++++++++++++++++++++++++++------- arch/x86/xen/xen-ops.h | 1 - 4 files changed, 34 insertions(+), 32 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..ff9a20a 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1306,7 +1306,6 @@ asmlinkage void __init xen_start_kernel(void) xen_raw_console_write("mapping kernel into physical memory\n"); pgd = xen_setup_kernel_pagetable(pgd, xen_start_info->nr_pages); - xen_ident_map_ISA(); /* Allocate and initialize top and mid mfn levels for p2m structure */ xen_build_mfn_list_list(); diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..b756d8c 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) #endif } -void __init xen_ident_map_ISA(void) -{ - unsigned long pa; - - /* - * If we're dom0, then linear map the ISA machine addresses into - * the kernel's address space. - */ - if (!xen_initial_domain()) - return; - - xen_raw_printk("Xen: setup ISA identity maps\n"); - - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); - - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) - BUG(); - } - - xen_flush_tlb(); -} - static void __init xen_post_allocator_init(void) { pv_mmu_ops.set_pte = xen_set_pte; diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 506a3e6..d5f8714 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, return len; } + +static unsigned long __init xen_release_chunk(unsigned long start, + unsigned long end) +{ + return xen_do_chunk(start, end, true); +} + static unsigned long __init xen_populate_chunk( const struct e820entry *list, size_t map_size, unsigned long max_pfn, unsigned long *last_pfn, @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( } return done; } + +static void __init xen_set_identity_and_release_chunk( + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, + unsigned long *released, unsigned long *identity) +{ + unsigned long pfn; + + /* + * If the PFNs are currently mapped, the VA mapping also needs + * to be updated to be 1:1. + */ + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) + (void)HYPERVISOR_update_va_mapping( + (unsigned long)__va(pfn << PAGE_SHIFT), + mfn_pte(pfn, PAGE_KERNEL_IO), 0); + + if (start_pfn < nr_pages) + *released += xen_release_chunk( + start_pfn, min(end_pfn, nr_pages)); + + *identity += set_phys_range_identity(start_pfn, end_pfn); +} + static unsigned long __init xen_set_identity_and_release( const struct e820entry *list, size_t map_size, unsigned long nr_pages) { @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( if (entry->type == E820_RAM) end_pfn = PFN_UP(entry->addr); - if (start_pfn < end_pfn) { - if (start_pfn < nr_pages) - released += xen_do_chunk( - start_pfn, min(end_pfn, nr_pages), true); + if (start_pfn < end_pfn) + xen_set_identity_and_release_chunk( + start_pfn, end_pfn, nr_pages, + &released, &identity); - identity += set_phys_range_identity( - start_pfn, end_pfn); - } start = end; } } diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index b095739..506fa08 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); void xen_build_mfn_list_list(void); void xen_setup_machphys_mapping(void); pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); -void xen_ident_map_ISA(void); void xen_reserve_top(void); extern unsigned long xen_max_p2m_pfn; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:18:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPxnX-0001Pb-5R; Thu, 03 May 2012 15:18:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxnV-0001PV-Mt for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:18:25 +0000 Received: from [193.109.254.147:22460] by server-1.bemta-14.messagelabs.com id BF/B9-29372-0C1A2AF4; Thu, 03 May 2012 15:18:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336058304!1844450!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27599 invoked from network); 3 May 2012 15:18:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:18:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12278192" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 15:18: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, 3 May 2012 16:18:23 +0100 Message-ID: <1336058302.20716.100.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ross Philipson Date: Thu, 3 May 2012 16:18:22 +0100 In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 15:57 +0100, Ross Philipson wrote: > I was trying to build the vtpm bits in unstable and the patch for the vtpm was failing to apply. It worked fine before this commit. > > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c5b7d49ca3ee CCing the author. > Since it is a patch file, maybe the change should read something more like: > > +-LDFLAGS += -lgmp > ++LDLIBS += -lgmp Quite possibly. Certainly patching the context of the patch seems like a very odd thing to do given the patch description and unless the patch invocation is allowing loads of fuzz I don't see how it could ever work. Olaf did you actually test this change with vtpm enabled in the build? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:18:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPxnX-0001Pb-5R; Thu, 03 May 2012 15:18:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxnV-0001PV-Mt for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:18:25 +0000 Received: from [193.109.254.147:22460] by server-1.bemta-14.messagelabs.com id BF/B9-29372-0C1A2AF4; Thu, 03 May 2012 15:18:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336058304!1844450!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27599 invoked from network); 3 May 2012 15:18:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:18:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,523,1330905600"; d="scan'208";a="12278192" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 15:18: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, 3 May 2012 16:18:23 +0100 Message-ID: <1336058302.20716.100.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ross Philipson Date: Thu, 3 May 2012 16:18:22 +0100 In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 15:57 +0100, Ross Philipson wrote: > I was trying to build the vtpm bits in unstable and the patch for the vtpm was failing to apply. It worked fine before this commit. > > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c5b7d49ca3ee CCing the author. > Since it is a patch file, maybe the change should read something more like: > > +-LDFLAGS += -lgmp > ++LDLIBS += -lgmp Quite possibly. Certainly patching the context of the patch seems like a very odd thing to do given the patch description and unless the patch invocation is allowing loads of fuzz I don't see how it could ever work. Olaf did you actually test this change with vtpm enabled in the build? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:29:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxxj-0001dR-D7; Thu, 03 May 2012 15:28:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxxh-0001dM-A2 for xen-devel@lists.xen.org; Thu, 03 May 2012 15:28:57 +0000 Received: from [85.158.138.51:24532] by server-6.bemta-3.messagelabs.com id 93/01-05145-834A2AF4; Thu, 03 May 2012 15:28:56 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-14.tower-174.messagelabs.com!1336058934!18709631!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31160 invoked from network); 3 May 2012 15:28:54 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-14.tower-174.messagelabs.com with SMTP; 3 May 2012 15:28:54 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77585255; Thu, 03 May 2012 16:58:53 +0200 Message-ID: <1336057131.2313.82.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Thu, 03 May 2012 16:58:51 +0200 In-Reply-To: <4FA28B1B.8040205@eu.citrix.com> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <4FA28B1B.8040205@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3055614114624587010==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3055614114624587010== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6C60f7a+kgUahT5xki3b" --=-6C60f7a+kgUahT5xki3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-05-03 at 14:41 +0100, George Dunlap wrote:=20 > >> Why are "nodes_policy" and "num_nodes_policy" not passed in along with > >> b_info? > > That was my first implementation. Then I figured out that I want to do > > the placement in _xl_, not in _libxl_, so I really don't need to muck u= p > > build info with placement related stuff. Should I use b_info anyway, > > even if I don't need these fields while in libxl? > Ah right -- yeah, probably since b_info is a libxl structure, you=20 > shouldn't add it in there. But in that case you should probably add=20 > another xl-specific structure and pass it through, rather than having=20 > global variables, I think. It's only used in the handful of placement= =20 > functions, right? > It is and yes, I can and will try to "pack" it better. Thanks. > > - which percent should I try, and in what order? I mean, 75%/25% > > sounds reasonable, but maybe also 80%/20% or even 60%/40% helps you= r > > point. > I had in mind no constraints at all on the ratios -- basically, if you= =20 > can find N nodes such that the sum of free memory is enough to create=20 > the VM, even 99%/1%, then go for that rather than looking for N+1. =20 > Obviously finding a more balanced option would be better.=20 > I see, and this looks both reasonable and doable with reasonable effort. :-) > One option=20 > would be to scan through finding all sets of N nodes that will satisfy= =20 > the criteria, and then choose the most "balanced" one. That might be=20 > more than we need for 4.2, so another option would be to look for evenly= =20 > balanced nodes first, then if we don't find a set, look for any set. =20 > (That certainly fits with the "first fit" description!) > Yep, that would need some extra effort that we might want to postpone. I like what you proposed above and I'll look into putting it together without turning xl too much into a set-theory processing machine. ;-D > > - suppose I go for 75%/25%, what about the scheduling oof the VM? > Haha -- yeah, for a research paper, you'd probably implement some kind= =20 > of lottery scheduling algorithm that would schedule it on one node 75%= =20 > of the time and another node 25% of the time. :-) =20 > That would be awesome. I know a bunch of people that would manage in getting at leat 3 or 4 publications out of this idea (one about the idea, one about the implementation, one about the statistical guarantees, etc.). :-P :-P > But I think that just=20 > making the node affinity equal to both of them will be good enough for= =20 > now. There will be some variability in performance, but there will be= =20 > some of that anyway depending on what node's memory the guest happens to= =20 > use more. > Agreed. I'm really thinking about taking your suggestion about keeping thee layout "fluid" and then set the affinity to all of the involved nodes. Thanks again. > This actually kind of a different issue, but I'll bring it up now=20 > because it's related. (Something to toss in for thinking about in 4.3= =20 > really.) Suppose there are 4 cores and 16GiB per node, and a VM has 8= =20 > vcpus and 8GiB of RAM. The algorithm you have here will attempt to put= =20 > 4GiB on each of two nodes (since it will take 2 nodes to get 8 cores). = =20 > However, it's pretty common for larger VMs to have way more vcpus than= =20 > they actually use at any one time. So it might actually have better=20 > performance to put all 8GiB on one node, and set the node affinity=20 > accordingly. In the rare event that more than 4 vcpus are active, a=20 > handful of vcpus will have all remote accesses, but the majority of the= =20 > time, all of the cpus will have local accesses. (OTOH, maybe that=20 > should be only a policy thing that we should recommend in the=20 > documentation...) >=20 That makes a lot of sense, and I was also thinking along the very same line. Once we'll have a proper mechanism to account for CPU load we could put another policing re this thing, i.e., once we've got all the information about the memory, what should we do with respect to (v)cpus? Should we spread the load or prefer some more "packed" placement? Again, I think we can both add more tunables and also make things dynamic (e.g., have all the 8 vcpus on the 4 cpus of a node and, if they're generating too much remote accesses, expand the node affinity and move some of the memory) when we'll have more of the mechanism in place. > Dude, this is open source. Be opinionated. ;-) >=20 Thanks for the advice... From now on, I'll do my best! :-) > What do you think of my suggestions above? > As I said, I actually like it. > I think if the user specifies a nodemap, and that nodemap doesn't have= =20 > enough memory, we should throw an error. >=20 Agreed. > If there's a node_affinity set, no memory on that node, but memory on a= =20 > *different* node, what will Xen do? It will allocate memory on some=20 > other node, right? >=20 Yep. > So ATM even if you specify a cpumask, you'll get memory on the masked=20 > nodes first, and then memory elsewhere (probably in a fairly random=20 > manner); but as much of the memory as possible will be on the masked=20 > nodes. I wonder then if we shouldnt' just keep that behavior -- i.e.,= =20 > if there's a cpumask specified, just return the nodemask from that mask,= =20 > and let Xen put as much as possible on that node and let the rest fall= =20 > where it may. >=20 Well, sounds reasonable after all, and I'm pretty sure it would simplify the code a bit, which is something not bad at all. So yes, I'm inclined to agree on this. > > However, if what you mean is I could check beforehand whether or not th= e > > user provided configuration will give us enough CPUs and avoid testing > > scenarios that are guaranteed to fail, then I agree and I'll reshape th= e > > code to look like that. This triggers the heuristics re-designing stuff > > from above again, as one have to decide what to do if user asks for > > "nodes=3D[1,3]" and I discover (earlier) that I need one more node for > > having enough CPUs (I mean, what node should I try first?). > No, that's not exactly what I meant. Suppose there are 4 cores per=20 > node, and a VM has 16 vcpus, and NUMA is just set to auto, with no other= =20 > parameters. If I'm reading your code right, what it will do is first=20 > try to find a set of 1 node that will satisfy the constraints, then 2=20 > nodes, then 3, nodes, then 4, &c. Since there are at most 4 cores per= =20 > node, we know that 1, 2, and 3 nodes are going to fail, regardless of=20 > how much memory there is or how many cpus are offline. So why not just= =20 > start with 4, if the user hasn't specified anything? Then if 4 doesn't= =20 > work (either because there's not enough memory, or some of the cpus are= =20 > offline), then we can start bumping it up to 5, 6, &c. >=20 Fine, I got it now, thanks for clarifying (both here and in the other e-mail). I'll look into that and, if it doesn't cost too much thinking/coding/debugging time, I'll go for it. > That's what I was getting at -- but again, if it makes it too=20 > complicated, trading a bit of extra passes for a significant chunk of=20 > your debugging time is OK. :-) >=20 I'll sure act like this. I really want this thing out ASAP. > Well, if the user didn't specify anything, then we can't contradict=20 > anything he specified, right? :-) If the user doesn't specify anything,= =20 > and the default is "numa=3Dauto", then I think we're free to do whatever= =20 > we think is best regarding NUMA placement; in fact, I think we should=20 > try to avoid failing VM creation if it's at all possible. I just meant= =20 > what I think we should do if the user asked for specific NUMA nodes or a= =20 > specific number of nodes. > I agree, and it should be easy enough to discern in which of these two situations we are and act accordingly. > It seems like we have a number of issues here that would be good for=20 > more people to come in on --=20 > This is something I really would enjoy a lot! > what if I attempt to summarize the=20 > high-level decisions we're talking about so that it's easier for more=20 > people to comment on them? >=20 That would be very helpful, indeed. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-6C60f7a+kgUahT5xki3b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+inSsACgkQk4XaBE3IOsSuFgCfaAf0x++ZGvjHfMIDIRJto3J5 AyIAn0La1PbL7QsWSLOZSGK+8xBc8hXI =DeiO -----END PGP SIGNATURE----- --=-6C60f7a+kgUahT5xki3b-- --===============3055614114624587010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3055614114624587010==-- From xen-devel-bounces@lists.xen.org Thu May 03 15:29:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxxj-0001dR-D7; Thu, 03 May 2012 15:28:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPxxh-0001dM-A2 for xen-devel@lists.xen.org; Thu, 03 May 2012 15:28:57 +0000 Received: from [85.158.138.51:24532] by server-6.bemta-3.messagelabs.com id 93/01-05145-834A2AF4; Thu, 03 May 2012 15:28:56 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-14.tower-174.messagelabs.com!1336058934!18709631!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31160 invoked from network); 3 May 2012 15:28:54 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-14.tower-174.messagelabs.com with SMTP; 3 May 2012 15:28:54 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77585255; Thu, 03 May 2012 16:58:53 +0200 Message-ID: <1336057131.2313.82.camel@Abyss> From: Dario Faggioli To: George Dunlap Date: Thu, 03 May 2012 16:58:51 +0200 In-Reply-To: <4FA28B1B.8040205@eu.citrix.com> References: <31163f014d8a2da9375f.1334150275@Solace> <4FA0051F.6020909@eu.citrix.com> <1335976251.2961.123.camel@Abyss> <4FA28B1B.8040205@eu.citrix.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi 64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg== X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 08 of 10 [RFC]] xl: Introduce First Fit memory-wise placement of guests on nodes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3055614114624587010==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3055614114624587010== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6C60f7a+kgUahT5xki3b" --=-6C60f7a+kgUahT5xki3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-05-03 at 14:41 +0100, George Dunlap wrote:=20 > >> Why are "nodes_policy" and "num_nodes_policy" not passed in along with > >> b_info? > > That was my first implementation. Then I figured out that I want to do > > the placement in _xl_, not in _libxl_, so I really don't need to muck u= p > > build info with placement related stuff. Should I use b_info anyway, > > even if I don't need these fields while in libxl? > Ah right -- yeah, probably since b_info is a libxl structure, you=20 > shouldn't add it in there. But in that case you should probably add=20 > another xl-specific structure and pass it through, rather than having=20 > global variables, I think. It's only used in the handful of placement= =20 > functions, right? > It is and yes, I can and will try to "pack" it better. Thanks. > > - which percent should I try, and in what order? I mean, 75%/25% > > sounds reasonable, but maybe also 80%/20% or even 60%/40% helps you= r > > point. > I had in mind no constraints at all on the ratios -- basically, if you= =20 > can find N nodes such that the sum of free memory is enough to create=20 > the VM, even 99%/1%, then go for that rather than looking for N+1. =20 > Obviously finding a more balanced option would be better.=20 > I see, and this looks both reasonable and doable with reasonable effort. :-) > One option=20 > would be to scan through finding all sets of N nodes that will satisfy= =20 > the criteria, and then choose the most "balanced" one. That might be=20 > more than we need for 4.2, so another option would be to look for evenly= =20 > balanced nodes first, then if we don't find a set, look for any set. =20 > (That certainly fits with the "first fit" description!) > Yep, that would need some extra effort that we might want to postpone. I like what you proposed above and I'll look into putting it together without turning xl too much into a set-theory processing machine. ;-D > > - suppose I go for 75%/25%, what about the scheduling oof the VM? > Haha -- yeah, for a research paper, you'd probably implement some kind= =20 > of lottery scheduling algorithm that would schedule it on one node 75%= =20 > of the time and another node 25% of the time. :-) =20 > That would be awesome. I know a bunch of people that would manage in getting at leat 3 or 4 publications out of this idea (one about the idea, one about the implementation, one about the statistical guarantees, etc.). :-P :-P > But I think that just=20 > making the node affinity equal to both of them will be good enough for= =20 > now. There will be some variability in performance, but there will be= =20 > some of that anyway depending on what node's memory the guest happens to= =20 > use more. > Agreed. I'm really thinking about taking your suggestion about keeping thee layout "fluid" and then set the affinity to all of the involved nodes. Thanks again. > This actually kind of a different issue, but I'll bring it up now=20 > because it's related. (Something to toss in for thinking about in 4.3= =20 > really.) Suppose there are 4 cores and 16GiB per node, and a VM has 8= =20 > vcpus and 8GiB of RAM. The algorithm you have here will attempt to put= =20 > 4GiB on each of two nodes (since it will take 2 nodes to get 8 cores). = =20 > However, it's pretty common for larger VMs to have way more vcpus than= =20 > they actually use at any one time. So it might actually have better=20 > performance to put all 8GiB on one node, and set the node affinity=20 > accordingly. In the rare event that more than 4 vcpus are active, a=20 > handful of vcpus will have all remote accesses, but the majority of the= =20 > time, all of the cpus will have local accesses. (OTOH, maybe that=20 > should be only a policy thing that we should recommend in the=20 > documentation...) >=20 That makes a lot of sense, and I was also thinking along the very same line. Once we'll have a proper mechanism to account for CPU load we could put another policing re this thing, i.e., once we've got all the information about the memory, what should we do with respect to (v)cpus? Should we spread the load or prefer some more "packed" placement? Again, I think we can both add more tunables and also make things dynamic (e.g., have all the 8 vcpus on the 4 cpus of a node and, if they're generating too much remote accesses, expand the node affinity and move some of the memory) when we'll have more of the mechanism in place. > Dude, this is open source. Be opinionated. ;-) >=20 Thanks for the advice... From now on, I'll do my best! :-) > What do you think of my suggestions above? > As I said, I actually like it. > I think if the user specifies a nodemap, and that nodemap doesn't have= =20 > enough memory, we should throw an error. >=20 Agreed. > If there's a node_affinity set, no memory on that node, but memory on a= =20 > *different* node, what will Xen do? It will allocate memory on some=20 > other node, right? >=20 Yep. > So ATM even if you specify a cpumask, you'll get memory on the masked=20 > nodes first, and then memory elsewhere (probably in a fairly random=20 > manner); but as much of the memory as possible will be on the masked=20 > nodes. I wonder then if we shouldnt' just keep that behavior -- i.e.,= =20 > if there's a cpumask specified, just return the nodemask from that mask,= =20 > and let Xen put as much as possible on that node and let the rest fall= =20 > where it may. >=20 Well, sounds reasonable after all, and I'm pretty sure it would simplify the code a bit, which is something not bad at all. So yes, I'm inclined to agree on this. > > However, if what you mean is I could check beforehand whether or not th= e > > user provided configuration will give us enough CPUs and avoid testing > > scenarios that are guaranteed to fail, then I agree and I'll reshape th= e > > code to look like that. This triggers the heuristics re-designing stuff > > from above again, as one have to decide what to do if user asks for > > "nodes=3D[1,3]" and I discover (earlier) that I need one more node for > > having enough CPUs (I mean, what node should I try first?). > No, that's not exactly what I meant. Suppose there are 4 cores per=20 > node, and a VM has 16 vcpus, and NUMA is just set to auto, with no other= =20 > parameters. If I'm reading your code right, what it will do is first=20 > try to find a set of 1 node that will satisfy the constraints, then 2=20 > nodes, then 3, nodes, then 4, &c. Since there are at most 4 cores per= =20 > node, we know that 1, 2, and 3 nodes are going to fail, regardless of=20 > how much memory there is or how many cpus are offline. So why not just= =20 > start with 4, if the user hasn't specified anything? Then if 4 doesn't= =20 > work (either because there's not enough memory, or some of the cpus are= =20 > offline), then we can start bumping it up to 5, 6, &c. >=20 Fine, I got it now, thanks for clarifying (both here and in the other e-mail). I'll look into that and, if it doesn't cost too much thinking/coding/debugging time, I'll go for it. > That's what I was getting at -- but again, if it makes it too=20 > complicated, trading a bit of extra passes for a significant chunk of=20 > your debugging time is OK. :-) >=20 I'll sure act like this. I really want this thing out ASAP. > Well, if the user didn't specify anything, then we can't contradict=20 > anything he specified, right? :-) If the user doesn't specify anything,= =20 > and the default is "numa=3Dauto", then I think we're free to do whatever= =20 > we think is best regarding NUMA placement; in fact, I think we should=20 > try to avoid failing VM creation if it's at all possible. I just meant= =20 > what I think we should do if the user asked for specific NUMA nodes or a= =20 > specific number of nodes. > I agree, and it should be easy enough to discern in which of these two situations we are and act accordingly. > It seems like we have a number of issues here that would be good for=20 > more people to come in on --=20 > This is something I really would enjoy a lot! > what if I attempt to summarize the=20 > high-level decisions we're talking about so that it's easier for more=20 > people to comment on them? >=20 That would be very helpful, indeed. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-6C60f7a+kgUahT5xki3b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+inSsACgkQk4XaBE3IOsSuFgCfaAf0x++ZGvjHfMIDIRJto3J5 AyIAn0La1PbL7QsWSLOZSGK+8xBc8hXI =DeiO -----END PGP SIGNATURE----- --=-6C60f7a+kgUahT5xki3b-- --===============3055614114624587010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3055614114624587010==-- From xen-devel-bounces@lists.xen.org Thu May 03 15:37:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:37:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5K-0001pI-Q3; Thu, 03 May 2012 15:36:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5K-0001pD-3U for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:36:50 +0000 Received: from [85.158.143.35:19028] by server-2.bemta-4.messagelabs.com id 83/2F-17550-116A2AF4; Thu, 03 May 2012 15:36:49 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-21.messagelabs.com!1336059377!11409831!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTY5MjQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTY5MjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6591 invoked from network); 3 May 2012 15:36:18 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:36:18 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0GEL8= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-081-083.pools.arcor-ip.net [88.65.81.83]) by smtp.strato.de (joses mo60) (RZmta 28.16 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x02e32o43CqZZS ; Thu, 3 May 2012 17:36:17 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id C190918637; Thu, 3 May 2012 17:36:16 +0200 (CEST) Date: Thu, 3 May 2012 17:36:16 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120503153616.GA10918@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336058302.20716.100.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, Ian Campbell wrote: > Olaf did you actually test this change with vtpm enabled in the build? Yes, I did. However, after leaving for vacation I wondered myself if this change is the right approach given that it changes the context of a patch. Perhaps I made a mistake somewhere in my queue of changes, or vtpm got disabled for some reason. I will double check. In any case, the Makefiles in the vtpm directory need some more changes. Ross, do you actually run the vtpm code? I did just compile tests. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:37:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:37:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5K-0001pI-Q3; Thu, 03 May 2012 15:36:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5K-0001pD-3U for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:36:50 +0000 Received: from [85.158.143.35:19028] by server-2.bemta-4.messagelabs.com id 83/2F-17550-116A2AF4; Thu, 03 May 2012 15:36:49 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-21.messagelabs.com!1336059377!11409831!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTY5MjQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTY5MjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6591 invoked from network); 3 May 2012 15:36:18 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:36:18 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0GEL8= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-081-083.pools.arcor-ip.net [88.65.81.83]) by smtp.strato.de (joses mo60) (RZmta 28.16 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x02e32o43CqZZS ; Thu, 3 May 2012 17:36:17 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id C190918637; Thu, 3 May 2012 17:36:16 +0200 (CEST) Date: Thu, 3 May 2012 17:36:16 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120503153616.GA10918@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336058302.20716.100.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, Ian Campbell wrote: > Olaf did you actually test this change with vtpm enabled in the build? Yes, I did. However, after leaving for vacation I wondered myself if this change is the right approach given that it changes the context of a patch. Perhaps I made a mistake somewhere in my queue of changes, or vtpm got disabled for some reason. I will double check. In any case, the Makefiles in the vtpm directory need some more changes. Ross, do you actually run the vtpm code? I did just compile tests. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:37:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:37:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5x-0001rq-7X; Thu, 03 May 2012 15:37:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5v-0001rd-FQ for xen-devel@lists.xen.org; Thu, 03 May 2012 15:37:27 +0000 Received: from [85.158.143.35:23068] by server-2.bemta-4.messagelabs.com id F5/00-17550-636A2AF4; Thu, 03 May 2012 15:37:26 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336059441!13603031!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15315 invoked from network); 3 May 2012 15:37:23 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:37:23 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id 800B410211D74; Thu, 3 May 2012 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyGZSFFXa-XP; Thu, 3 May 2012 08:37:17 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id D0FA310211D6F; Thu, 3 May 2012 08:37:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: Date: Thu, 3 May 2012 08:37:16 -0700 Message-Id: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com> <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> To: xen-devel@lists.xen.org X-Mailer: Apple Mail (2.1084) Cc: great.potato@gmail.com Subject: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey folks... This is with the same packages and such that I've been work on with Arch, and I encountered an odd crash. If I need to move this thread to Xen-users or whatnot, apologies and please let me know. The packages that I've been working with functioned great in the desktop VM, and worked wonderfully in PV and HVM on my test hardware (an HP server with Intel Xeons), but crashes right out of the gate on my production server (Tyan motherboard with Opteron 8356s). When I move the kernel back to a 2.6.32.18 pvops kernel I had been using, I can boot and run VMs without trouble. Incidentally, I can now boot as many VMs as I like as long as the memory holds out, so the initial trouble that got all of this started looks like it's been fixed. Everything looks normal until Xen hands off to the kernel, then I get this: [ 0.000000] Cannot find 20480 bytes in node 1 [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null) [ 0.000000] IP: [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] PGD 0 [ 0.000000] Oops: 0000 [#1] PREEMPT SMP [ 0.000000] CPU 0 [ 0.000000] Modules linked in: [ 0.000000] [ 0.000000] Pid: 0, comm: swapper Not tainted 3.3.4-1-ARCH #1 empty empty/S3992 [ 0.000000] RIP: e030:[] [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] RSP: e02b:ffffffff81801de8 EFLAGS: 00010046 [ 0.000000] RAX: 0000000000000000 RBX: 0000000000000378 RCX: 0000000000000000 [ 0.000000] RDX: 0000000000000040 RSI: 0000000000000378 RDI: 0000000000000000 [ 0.000000] RBP: ffffffff81801e08 R08: 0000000000000000 R09: ffffffff81801d98 [ 0.000000] R10: ffffffff81801d88 R11: ffffffff81801d90 R12: 0000000000000040 [ 0.000000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff8189f000(0000) knlGS:0000000000000000 [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: 0000000000000000 CR3: 0000000001805000 CR4: 0000000000000660 [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 [ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81800000, task ffffffff8180d020) [ 0.000000] Stack: [ 0.000000] 0000000000080000 0000000000000378 000000000000003c ffff88003fbfa000 [ 0.000000] ffffffff81801e68 ffffffff818d63f0 ffffffff81801e48 00000001818d53bc [ 0.000000] ffff88003fbf9fe0 0000000000000000 000000000282c000 ffff88003fbfa000 [ 0.000000] Call Trace: [ 0.000000] [] sparse_early_usemaps_alloc_node+0x63/0x1c4 [ 0.000000] [] sparse_init+0xf8/0x2c8 [ 0.000000] [] paging_init+0x13/0x22 [ 0.000000] [] setup_arch+0x9f2/0xac0 [ 0.000000] [] ? printk+0x41/0x43 [ 0.000000] [] start_kernel+0xd4/0x3d1 [ 0.000000] [] x86_64_start_reservations+0x131/0x135 [ 0.000000] [] xen_start_kernel+0x598/0x59f [ 0.000000] Code: 4c 89 e9 4c 89 e2 48 89 de bf 40 00 00 00 e8 0f fc ff ff eb 34 41 8b 96 a0 40 00 00 be 00 80 00 00 48 89 d [ 0.000000] RIP [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] RSP [ 0.000000] CR2: 0000000000000000 [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! (XEN) Domain 0 crashed: rebooting machine in 5 seconds. ---- This is the same kernel I've been using in the two testing machines. The server is, incidentally, the same server that houses the mail server I'm on, so I'm cc'ing a gmail address, if you could include it in your replies, I'd appreciate it. Thanks! -- Sam Mulvey Tacoma Telematics sam@tacomatelematics.com (253) 883-3030 x110 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:37:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:37:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5x-0001rq-7X; Thu, 03 May 2012 15:37:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy5v-0001rd-FQ for xen-devel@lists.xen.org; Thu, 03 May 2012 15:37:27 +0000 Received: from [85.158.143.35:23068] by server-2.bemta-4.messagelabs.com id F5/00-17550-636A2AF4; Thu, 03 May 2012 15:37:26 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336059441!13603031!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15315 invoked from network); 3 May 2012 15:37:23 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:37:23 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id 800B410211D74; Thu, 3 May 2012 08:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyGZSFFXa-XP; Thu, 3 May 2012 08:37:17 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id D0FA310211D6F; Thu, 3 May 2012 08:37:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: Date: Thu, 3 May 2012 08:37:16 -0700 Message-Id: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> References: <0DC43CA6-6F9A-4C8D-BB7C-785D646C5474@tacomatelematics.com> <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> To: xen-devel@lists.xen.org X-Mailer: Apple Mail (2.1084) Cc: great.potato@gmail.com Subject: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hey folks... This is with the same packages and such that I've been work on with Arch, and I encountered an odd crash. If I need to move this thread to Xen-users or whatnot, apologies and please let me know. The packages that I've been working with functioned great in the desktop VM, and worked wonderfully in PV and HVM on my test hardware (an HP server with Intel Xeons), but crashes right out of the gate on my production server (Tyan motherboard with Opteron 8356s). When I move the kernel back to a 2.6.32.18 pvops kernel I had been using, I can boot and run VMs without trouble. Incidentally, I can now boot as many VMs as I like as long as the memory holds out, so the initial trouble that got all of this started looks like it's been fixed. Everything looks normal until Xen hands off to the kernel, then I get this: [ 0.000000] Cannot find 20480 bytes in node 1 [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null) [ 0.000000] IP: [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] PGD 0 [ 0.000000] Oops: 0000 [#1] PREEMPT SMP [ 0.000000] CPU 0 [ 0.000000] Modules linked in: [ 0.000000] [ 0.000000] Pid: 0, comm: swapper Not tainted 3.3.4-1-ARCH #1 empty empty/S3992 [ 0.000000] RIP: e030:[] [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] RSP: e02b:ffffffff81801de8 EFLAGS: 00010046 [ 0.000000] RAX: 0000000000000000 RBX: 0000000000000378 RCX: 0000000000000000 [ 0.000000] RDX: 0000000000000040 RSI: 0000000000000378 RDI: 0000000000000000 [ 0.000000] RBP: ffffffff81801e08 R08: 0000000000000000 R09: ffffffff81801d98 [ 0.000000] R10: ffffffff81801d88 R11: ffffffff81801d90 R12: 0000000000000040 [ 0.000000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff8189f000(0000) knlGS:0000000000000000 [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: 0000000000000000 CR3: 0000000001805000 CR4: 0000000000000660 [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 [ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81800000, task ffffffff8180d020) [ 0.000000] Stack: [ 0.000000] 0000000000080000 0000000000000378 000000000000003c ffff88003fbfa000 [ 0.000000] ffffffff81801e68 ffffffff818d63f0 ffffffff81801e48 00000001818d53bc [ 0.000000] ffff88003fbf9fe0 0000000000000000 000000000282c000 ffff88003fbfa000 [ 0.000000] Call Trace: [ 0.000000] [] sparse_early_usemaps_alloc_node+0x63/0x1c4 [ 0.000000] [] sparse_init+0xf8/0x2c8 [ 0.000000] [] paging_init+0x13/0x22 [ 0.000000] [] setup_arch+0x9f2/0xac0 [ 0.000000] [] ? printk+0x41/0x43 [ 0.000000] [] start_kernel+0xd4/0x3d1 [ 0.000000] [] x86_64_start_reservations+0x131/0x135 [ 0.000000] [] xen_start_kernel+0x598/0x59f [ 0.000000] Code: 4c 89 e9 4c 89 e2 48 89 de bf 40 00 00 00 e8 0f fc ff ff eb 34 41 8b 96 a0 40 00 00 be 00 80 00 00 48 89 d [ 0.000000] RIP [] __alloc_bootmem_node+0x72/0x99 [ 0.000000] RSP [ 0.000000] CR2: 0000000000000000 [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! (XEN) Domain 0 crashed: rebooting machine in 5 seconds. ---- This is the same kernel I've been using in the two testing machines. The server is, incidentally, the same server that houses the mail server I'm on, so I'm cc'ing a gmail address, if you could include it in your replies, I'd appreciate it. Thanks! -- Sam Mulvey Tacoma Telematics sam@tacomatelematics.com (253) 883-3030 x110 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:38:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy6V-0001vF-Pk; Thu, 03 May 2012 15:38:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy6T-0001v0-Jm for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:38:01 +0000 Received: from [85.158.143.35:24813] by server-1.bemta-4.messagelabs.com id EC/35-20925-856A2AF4; Thu, 03 May 2012 15:38:00 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-16.tower-21.messagelabs.com!1336059476!11431520!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2380 invoked from network); 3 May 2012 15:37:58 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:37: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 q43Fbhq9003870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 11:37:43 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q43Fbhco003868; Thu, 3 May 2012 11:37:43 -0400 Date: Thu, 3 May 2012 11:37:43 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120503153743.GA3464@andromeda.dapyr.net> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> <4FA272CD.90808@cantab.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA272CD.90808@cantab.net> User-Agent: Mutt/1.5.9i Cc: david.vrabel@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall functions - since they are quite similar. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 12:58:05PM +0100, David Vrabel wrote: > On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > > They use the same set of arguments, so it is just the matter > > of using the proper hypercall. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > Acked-by: David Vrabel > > But would it be better to fold this into the previous patch? Nah, one logical change per patch. > > David > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:38:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy6V-0001vF-Pk; Thu, 03 May 2012 15:38:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPy6T-0001v0-Jm for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:38:01 +0000 Received: from [85.158.143.35:24813] by server-1.bemta-4.messagelabs.com id EC/35-20925-856A2AF4; Thu, 03 May 2012 15:38:00 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-16.tower-21.messagelabs.com!1336059476!11431520!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2380 invoked from network); 3 May 2012 15:37:58 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:37: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 q43Fbhq9003870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 11:37:43 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q43Fbhco003868; Thu, 3 May 2012 11:37:43 -0400 Date: Thu, 3 May 2012 11:37:43 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120503153743.GA3464@andromeda.dapyr.net> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <1334596539-18172-9-git-send-email-konrad.wilk@oracle.com> <4FA272CD.90808@cantab.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA272CD.90808@cantab.net> User-Agent: Mutt/1.5.9i Cc: david.vrabel@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 8/8] xen/setup: Combine the two hypercall functions - since they are quite similar. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 12:58:05PM +0100, David Vrabel wrote: > On 16/04/12 18:15, Konrad Rzeszutek Wilk wrote: > > They use the same set of arguments, so it is just the matter > > of using the proper hypercall. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > Acked-by: David Vrabel > > But would it be better to fold this into the previous patch? Nah, one logical change per patch. > > David > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:46:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:46:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyEh-0002JB-Sf; Thu, 03 May 2012 15:46:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyEg-0002J1-RS for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:46:31 +0000 Received: from [85.158.138.51:6403] by server-10.bemta-3.messagelabs.com id FE/3B-29478-658A2AF4; Thu, 03 May 2012 15:46:30 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-13.tower-174.messagelabs.com!1336059987!14091335!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18524 invoked from network); 3 May 2012 15:46:28 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:46: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 q43FkLel004214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 11:46:21 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q43FkKG8004212; Thu, 3 May 2012 11:46:20 -0400 Date: Thu, 3 May 2012 11:46:20 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120503154620.GB3464@andromeda.dapyr.net> References: <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA29A92.2040601@canonical.com> User-Agent: Mutt/1.5.9i Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 04:47:46PM +0200, Stefan Bader wrote: > On 03.05.2012 14:58, Stefan Bader wrote: > > >>>>> So this shoudl solve the problem for the bootup processor. > >>>>>> > >>>>>> -boris > >>>>>> > >>>>>> > >>>>>>> + }; > >>>>>>> + int ret = 0; > >>>>>>> + > >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only > >>>>>>> + * get called on the bootup processor. But just in case. */ > >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + if (reg == APIC_LVR) > >>>>>>> + return 0x10; > >>>>>>> + > >>>>>>> + if (reg != APIC_ID) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + ret = HYPERVISOR_dom0_op(&op); > >>>>>>> + if (ret) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + return op.u.pcpu_info.apic_id; > >>>>>>> } > >>>>>>> > >>>>>>> static void xen_apic_write(u32 reg, u32 val) > > > > I added debugging to all exit paths that could return 0 (which is what the > > boot_cpu_physical_apicid is set to with that patch. Which would only leave the > > case of the HV call returning the wrong value somehow... > > > Hmmm, so xen_apic_read is still correct... > > [ 0.000000] ACPI: Local APIC address 0xfee00000 > [ 0.000000] xxx xen_apic_read(20) > [ 0.000000] xxx xen_apic_read -> 10 > [ 0.000000] boot_cpu_physical_apicid = 0 > [ 0.000000] xxx xen_apic_read(30) > [ 0.000000] +- apic version = 10 > > there seems to be a slightly strange tweak (at least for me) in read_apic_id... > > static inline unsigned int read_apic_id(void) > { > unsigned int reg; > > reg = apic_read(APIC_ID); // calls apic->read(reg) > > return apic->get_apic_id(reg); Duh!! Let me spin out a new patch that will do this. > } > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:46:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15:46:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyEh-0002JB-Sf; Thu, 03 May 2012 15:46:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyEg-0002J1-RS for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:46:31 +0000 Received: from [85.158.138.51:6403] by server-10.bemta-3.messagelabs.com id FE/3B-29478-658A2AF4; Thu, 03 May 2012 15:46:30 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-13.tower-174.messagelabs.com!1336059987!14091335!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18524 invoked from network); 3 May 2012 15:46:28 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:46: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 q43FkLel004214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 11:46:21 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q43FkKG8004212; Thu, 3 May 2012 11:46:20 -0400 Date: Thu, 3 May 2012 11:46:20 -0400 From: Konrad Rzeszutek Wilk To: Stefan Bader Message-ID: <20120503154620.GB3464@andromeda.dapyr.net> References: <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA29A92.2040601@canonical.com> User-Agent: Mutt/1.5.9i Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 04:47:46PM +0200, Stefan Bader wrote: > On 03.05.2012 14:58, Stefan Bader wrote: > > >>>>> So this shoudl solve the problem for the bootup processor. > >>>>>> > >>>>>> -boris > >>>>>> > >>>>>> > >>>>>>> + }; > >>>>>>> + int ret = 0; > >>>>>>> + > >>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only > >>>>>>> + * get called on the bootup processor. But just in case. */ > >>>>>>> + if (!xen_initial_domain() || smp_processor_id()) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + if (reg == APIC_LVR) > >>>>>>> + return 0x10; > >>>>>>> + > >>>>>>> + if (reg != APIC_ID) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + ret = HYPERVISOR_dom0_op(&op); > >>>>>>> + if (ret) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + return op.u.pcpu_info.apic_id; > >>>>>>> } > >>>>>>> > >>>>>>> static void xen_apic_write(u32 reg, u32 val) > > > > I added debugging to all exit paths that could return 0 (which is what the > > boot_cpu_physical_apicid is set to with that patch. Which would only leave the > > case of the HV call returning the wrong value somehow... > > > Hmmm, so xen_apic_read is still correct... > > [ 0.000000] ACPI: Local APIC address 0xfee00000 > [ 0.000000] xxx xen_apic_read(20) > [ 0.000000] xxx xen_apic_read -> 10 > [ 0.000000] boot_cpu_physical_apicid = 0 > [ 0.000000] xxx xen_apic_read(30) > [ 0.000000] +- apic version = 10 > > there seems to be a slightly strange tweak (at least for me) in read_apic_id... > > static inline unsigned int read_apic_id(void) > { > unsigned int reg; > > reg = apic_read(APIC_ID); // calls apic->read(reg) > > return apic->get_apic_id(reg); Duh!! Let me spin out a new patch that will do this. > } > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:48:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPyGp-0002Nx-Do; Thu, 03 May 2012 15:48:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyGn-0002Nn-F1 for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:48:41 +0000 Received: from [85.158.143.99:5557] by server-3.bemta-4.messagelabs.com id FF/3B-05853-8D8A2AF4; Thu, 03 May 2012 15:48:40 +0000 X-Env-Sender: Ross.Philipson@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336060116!25459355!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE5MTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22236 invoked from network); 3 May 2012 15:48:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:48:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="24824778" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:48:34 -0400 Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 3 May 2012 11:48:34 -0400 From: Ross Philipson To: Olaf Hering , Ian Campbell Date: Thu, 3 May 2012 11:48:37 -0400 Thread-Topic: [Xen-devel] vTPM patch does not apply Thread-Index: Ac0pQtWkz1aloVS/TIe8xzqSV1FbUQAAQoGg Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DE6@FTLPMAILBOX02.citrite.net> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> In-Reply-To: <20120503153616.GA10918@aepfle.de> 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" , Ian Jackson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Olaf Hering [mailto:olaf@aepfle.de] > Sent: Thursday, May 03, 2012 11:36 AM > To: Ian Campbell > Cc: Ross Philipson; xen-devel@lists.xensource.com; Ian Jackson > Subject: Re: [Xen-devel] vTPM patch does not apply > > On Thu, May 03, Ian Campbell wrote: > > > Olaf did you actually test this change with vtpm enabled in the build? > > Yes, I did. > However, after leaving for vacation I wondered myself if this change is > the right approach given that it changes the context of a patch. > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > disabled for some reason. I will double check. > > In any case, the Makefiles in the vtpm directory need some more changes. > Ross, do you actually run the vtpm code? I did just compile tests. > > Olaf Olaf, We are about to do some work with the vtpm code in our project. That is when I noticed it failed to build. When I reverted to a previous version of the vtpm patch it applied without issues. So no, we have not gotten it running but we are working on it. I can post the results on xen-devel once we know more if folks would like. Thanks Ross _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:48:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPyGp-0002Nx-Do; Thu, 03 May 2012 15:48:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyGn-0002Nn-F1 for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:48:41 +0000 Received: from [85.158.143.99:5557] by server-3.bemta-4.messagelabs.com id FF/3B-05853-8D8A2AF4; Thu, 03 May 2012 15:48:40 +0000 X-Env-Sender: Ross.Philipson@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336060116!25459355!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDE5MTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22236 invoked from network); 3 May 2012 15:48:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 15:48:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="24824778" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 11:48:34 -0400 Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 3 May 2012 11:48:34 -0400 From: Ross Philipson To: Olaf Hering , Ian Campbell Date: Thu, 3 May 2012 11:48:37 -0400 Thread-Topic: [Xen-devel] vTPM patch does not apply Thread-Index: Ac0pQtWkz1aloVS/TIe8xzqSV1FbUQAAQoGg Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DE6@FTLPMAILBOX02.citrite.net> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> In-Reply-To: <20120503153616.GA10918@aepfle.de> 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" , Ian Jackson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Olaf Hering [mailto:olaf@aepfle.de] > Sent: Thursday, May 03, 2012 11:36 AM > To: Ian Campbell > Cc: Ross Philipson; xen-devel@lists.xensource.com; Ian Jackson > Subject: Re: [Xen-devel] vTPM patch does not apply > > On Thu, May 03, Ian Campbell wrote: > > > Olaf did you actually test this change with vtpm enabled in the build? > > Yes, I did. > However, after leaving for vacation I wondered myself if this change is > the right approach given that it changes the context of a patch. > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > disabled for some reason. I will double check. > > In any case, the Makefiles in the vtpm directory need some more changes. > Ross, do you actually run the vtpm code? I did just compile tests. > > Olaf Olaf, We are about to do some work with the vtpm code in our project. That is when I noticed it failed to build. When I reverted to a previous version of the vtpm patch it applied without issues. So no, we have not gotten it running but we are working on it. I can post the results on xen-devel once we know more if folks would like. Thanks Ross _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:57:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPyPB-0002aw-G1; Thu, 03 May 2012 15:57:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyP9-0002ar-Mi for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:57:19 +0000 Received: from [85.158.143.35:46468] by server-2.bemta-4.messagelabs.com id D7/F8-17550-EDAA2AF4; Thu, 03 May 2012 15:57:18 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-21.messagelabs.com!1336060637!7441636!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODIzNjE=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODIzNjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16204 invoked from network); 3 May 2012 15:57:18 -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 DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:57:18 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0GEL8= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-081-083.pools.arcor-ip.net [88.65.81.83]) by smtp.strato.de (jored mo81) (RZmta 29.1 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K036a0o43FhF1Q ; Thu, 3 May 2012 17:57:17 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id DECF518637; Thu, 3 May 2012 17:57:16 +0200 (CEST) Date: Thu, 3 May 2012 17:57:16 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120503155716.GA14354@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120503153616.GA10918@aepfle.de> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, Olaf Hering wrote: > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > disabled for some reason. I will double check. While preparing the patch I accidently disabled vtpm in my rpm spec file, so the code was not exectued anymore. Sorry for that. I see some nice patch handing in tools/firmware/etherboot/Makefile, which could be copied to tools/vtpm/Makefile. However, this would make the make targets updatepatches and orig in tools/vtpm/Makefile obsolete. Would that be an acceptable approach to maintain a stack of patches for vtpm? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 15:57:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 15: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 ) id 1SPyPB-0002aw-G1; Thu, 03 May 2012 15:57:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyP9-0002ar-Mi for xen-devel@lists.xensource.com; Thu, 03 May 2012 15:57:19 +0000 Received: from [85.158.143.35:46468] by server-2.bemta-4.messagelabs.com id D7/F8-17550-EDAA2AF4; Thu, 03 May 2012 15:57:18 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-21.messagelabs.com!1336060637!7441636!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODIzNjE=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODIzNjE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16204 invoked from network); 3 May 2012 15:57:18 -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 DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 15:57:18 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0GEL8= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-081-083.pools.arcor-ip.net [88.65.81.83]) by smtp.strato.de (jored mo81) (RZmta 29.1 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K036a0o43FhF1Q ; Thu, 3 May 2012 17:57:17 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id DECF518637; Thu, 3 May 2012 17:57:16 +0200 (CEST) Date: Thu, 3 May 2012 17:57:16 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120503155716.GA14354@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120503153616.GA10918@aepfle.de> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, Olaf Hering wrote: > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > disabled for some reason. I will double check. While preparing the patch I accidently disabled vtpm in my rpm spec file, so the code was not exectued anymore. Sorry for that. I see some nice patch handing in tools/firmware/etherboot/Makefile, which could be copied to tools/vtpm/Makefile. However, this would make the make targets updatepatches and orig in tools/vtpm/Makefile obsolete. Would that be an acceptable approach to maintain a stack of patches for vtpm? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:03:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyUU-00038p-7s; Thu, 03 May 2012 16:02:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyUT-00038h-8O for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:02:49 +0000 Received: from [85.158.143.99:30758] by server-1.bemta-4.messagelabs.com id 76/55-20925-82CA2AF4; Thu, 03 May 2012 16:02:48 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-11.tower-216.messagelabs.com!1336060966!18843505!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzMzNTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9851 invoked from network); 3 May 2012 16:02:47 -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; 3 May 2012 16:02:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 1C56E165E; Thu, 3 May 2012 19:02:44 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 5E91A2005D; Thu, 3 May 2012 19:02:44 +0300 (EEST) Date: Thu, 3 May 2012 19:02:44 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Fantu Message-ID: <20120503160244.GQ2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336055231213-5683345.post@n5.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 07:27:11AM -0700, Fantu wrote: > = > Pasi K=E4rkk=E4inen wrote > > = > > On Thu, May 03, 2012 at 05:28:44AM -0700, Fantu wrote: > >> = > >> About qxl there are problems about videoram not allocated or not used > >> over 4 > >> mb (same as default cirrus vga). > >> At the moment I haven't found solution for this problem, probably some > >> bugfix and/or change are needed on xen. > >> = > > = > > Is this a regression in xen-unstable compared to xen 4.1 ? = > > = > > afaik you can get at least 16 MB of video memory for HVM guest with Xen > > 4.1. > > = > > -- Pasi > > = > > = > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > = > Thanks for reply > Probably xen-unstable with qemu upstream doesn't support videoram setting. > qxl default videoram is 64 mb but I also tried to set 16 mb without resul= t, > it always see only 4 mb, not enough for correct working qxl. > = Ok. If you use qemu-upstream and cirrus/stdvga (without qxl), does videomem= >4MB work then ? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:03:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyUU-00038p-7s; Thu, 03 May 2012 16:02:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyUT-00038h-8O for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:02:49 +0000 Received: from [85.158.143.99:30758] by server-1.bemta-4.messagelabs.com id 76/55-20925-82CA2AF4; Thu, 03 May 2012 16:02:48 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-11.tower-216.messagelabs.com!1336060966!18843505!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzMzNTU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9851 invoked from network); 3 May 2012 16:02:47 -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; 3 May 2012 16:02:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 1C56E165E; Thu, 3 May 2012 19:02:44 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 5E91A2005D; Thu, 3 May 2012 19:02:44 +0300 (EEST) Date: Thu, 3 May 2012 19:02:44 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Fantu Message-ID: <20120503160244.GQ2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336055231213-5683345.post@n5.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 07:27:11AM -0700, Fantu wrote: > = > Pasi K=E4rkk=E4inen wrote > > = > > On Thu, May 03, 2012 at 05:28:44AM -0700, Fantu wrote: > >> = > >> About qxl there are problems about videoram not allocated or not used > >> over 4 > >> mb (same as default cirrus vga). > >> At the moment I haven't found solution for this problem, probably some > >> bugfix and/or change are needed on xen. > >> = > > = > > Is this a regression in xen-unstable compared to xen 4.1 ? = > > = > > afaik you can get at least 16 MB of video memory for HVM guest with Xen > > 4.1. > > = > > -- Pasi > > = > > = > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > = > Thanks for reply > Probably xen-unstable with qemu upstream doesn't support videoram setting. > qxl default videoram is 64 mb but I also tried to set 16 mb without resul= t, > it always see only 4 mb, not enough for correct working qxl. > = Ok. If you use qemu-upstream and cirrus/stdvga (without qxl), does videomem= >4MB work then ? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:07:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyYf-0003Jp-21; Thu, 03 May 2012 16:07:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyYd-0003Jh-Sy for xen-devel@lists.xen.org; Thu, 03 May 2012 16:07:07 +0000 Received: from [85.158.143.99:55026] by server-2.bemta-4.messagelabs.com id 1A/85-17550-B2DA2AF4; Thu, 03 May 2012 16:07:07 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336061224!26039551!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32491 invoked from network); 3 May 2012 16:07:05 -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; 3 May 2012 16:07:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 17:07:03 +0100 Message-Id: <4FA2C94802000078000816E3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 17:07:04 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Both Linux and Xen offer only ways to set the IOPL. While on native Linux this is not a problem since user mode code can read the IOPL by inspecting EFLAGS, on Xen this would always yield zero. Now X folks appear to be using save-modify-restore cycles in some newer code, and this obviously breaks under Xen, as they would restore IOPL 0 even when IOPL 3 was in effect before. Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add e.g. a "get" counterpart to PHYSDEVOP_set_iopl. Or am I overlooking some other access mechanism? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:07:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyYf-0003Jp-21; Thu, 03 May 2012 16:07:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyYd-0003Jh-Sy for xen-devel@lists.xen.org; Thu, 03 May 2012 16:07:07 +0000 Received: from [85.158.143.99:55026] by server-2.bemta-4.messagelabs.com id 1A/85-17550-B2DA2AF4; Thu, 03 May 2012 16:07:07 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336061224!26039551!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32491 invoked from network); 3 May 2012 16:07:05 -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; 3 May 2012 16:07:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 03 May 2012 17:07:03 +0100 Message-Id: <4FA2C94802000078000816E3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 03 May 2012 17:07:04 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Both Linux and Xen offer only ways to set the IOPL. While on native Linux this is not a problem since user mode code can read the IOPL by inspecting EFLAGS, on Xen this would always yield zero. Now X folks appear to be using save-modify-restore cycles in some newer code, and this obviously breaks under Xen, as they would restore IOPL 0 even when IOPL 3 was in effect before. Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add e.g. a "get" counterpart to PHYSDEVOP_set_iopl. Or am I overlooking some other access mechanism? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:19:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPykU-0003Xe-9t; Thu, 03 May 2012 16:19:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPykS-0003XZ-B5 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:19:20 +0000 Received: from [85.158.143.99:55336] by server-3.bemta-4.messagelabs.com id 8B/81-05853-700B2AF4; Thu, 03 May 2012 16:19:19 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-216.messagelabs.com!1336061958!15172409!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20387 invoked from network); 3 May 2012 16:19:18 -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; 3 May 2012 16:19:18 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPykM-000Oma-4V; Thu, 03 May 2012 16:19:14 +0000 Date: Thu, 3 May 2012 17:19:14 +0100 From: Tim Deegan To: Andres Lagar-Cavilla Message-ID: <20120503161914.GD90833@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "Zhang, Yang Z" , andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC top up to experimental p2m rwlock patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 17:16 -0400 on 27 Apr (1335546977), Andres Lagar-Cavilla wrote: > Extending the core idea form Tim's patch, and bug fixing galore. > > Our testing works quite smoothly with this in place. > > Signed-off-by: Andres Lagar-Cavilla Thanks very much for that. I had intended to merge this into a cleaned-up series based on the previous patch today, but other things came up, so I'm afraid it will have to wait until next week. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:19:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPykU-0003Xe-9t; Thu, 03 May 2012 16:19:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPykS-0003XZ-B5 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:19:20 +0000 Received: from [85.158.143.99:55336] by server-3.bemta-4.messagelabs.com id 8B/81-05853-700B2AF4; Thu, 03 May 2012 16:19:19 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-216.messagelabs.com!1336061958!15172409!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20387 invoked from network); 3 May 2012 16:19:18 -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; 3 May 2012 16:19:18 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPykM-000Oma-4V; Thu, 03 May 2012 16:19:14 +0000 Date: Thu, 3 May 2012 17:19:14 +0100 From: Tim Deegan To: Andres Lagar-Cavilla Message-ID: <20120503161914.GD90833@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "Zhang, Yang Z" , andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 4] RFC top up to experimental p2m rwlock patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 17:16 -0400 on 27 Apr (1335546977), Andres Lagar-Cavilla wrote: > Extending the core idea form Tim's patch, and bug fixing galore. > > Our testing works quite smoothly with this in place. > > Signed-off-by: Andres Lagar-Cavilla Thanks very much for that. I had intended to merge this into a cleaned-up series based on the previous patch today, but other things came up, so I'm afraid it will have to wait until next week. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:20:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPyl6-0003ai-NU; Thu, 03 May 2012 16:20:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyl5-0003aL-Ve for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:20:00 +0000 Received: from [193.109.254.147:33921] by server-5.bemta-14.messagelabs.com id BC/A2-30733-F20B2AF4; Thu, 03 May 2012 16:19:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336061997!7526726!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA4MjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28248 invoked from network); 3 May 2012 16:19:58 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 16:19:58 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43GJrJ5032516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 16:19:53 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43GJq5b022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 16:19:52 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 q43GJpi6016671; Thu, 3 May 2012 11:19:51 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 09:19:51 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B6BFE40357; Thu, 3 May 2012 12:14:09 -0400 (EDT) Date: Thu, 3 May 2012 12:14:09 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120503161409.GB9992@phenom.dumpdata.com> References: <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA1B096.5010009@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 06:09:26PM -0400, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: > >On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: > >>On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > >>>On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > >>>>On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >>>>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >>>>>index a8f8844..d816448 100644 > >>>>>--- a/arch/x86/xen/enlighten.c > >>>>>+++ b/arch/x86/xen/enlighten.c > >>>>>@@ -811,7 +811,29 @@ static void xen_io_delay(void) > >>>>> #ifdef CONFIG_X86_LOCAL_APIC > >>>>> static u32 xen_apic_read(u32 reg) > >>>>> { > >>>>>- return 0; > >>>>>+ struct xen_platform_op op = { > >>>>>+ .cmd = XENPF_get_cpuinfo, > >>>>>+ .interface_version = XENPF_INTERFACE_VERSION, > >>>>>+ .u.pcpu_info.xen_cpuid = 0, > >>>> > >>>> > >>>>Is this always zero? This will probably solve the current problem > >>> > >>>Its a CPU number (not tied in to APIC or ACPI IDs). > >> > >>Why not use CPU number instead of zero here? > > > >The issue was only with the bootup CPU - so was using the Xen's > >bootup CPU number - which is zero (as is Linux's). > > I agree that for this particular problem this may be sufficient. > > My concern is that in the future someone may decide to use > apic_read(APIC_ID) or read_apic_id() for some other purpose and they > won't get expected result (i.e. on all CPUs they will get the same > answer). Good point. Let's get this particular bug fixed for v3.5, and then will do a more comprehensive fix for v3.6. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:20:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPyl6-0003ai-NU; Thu, 03 May 2012 16:20:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyl5-0003aL-Ve for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:20:00 +0000 Received: from [193.109.254.147:33921] by server-5.bemta-14.messagelabs.com id BC/A2-30733-F20B2AF4; Thu, 03 May 2012 16:19:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336061997!7526726!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA4MjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28248 invoked from network); 3 May 2012 16:19:58 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 16:19:58 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43GJrJ5032516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 16:19:53 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43GJq5b022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 16:19:52 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 q43GJpi6016671; Thu, 3 May 2012 11:19:51 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 09:19:51 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B6BFE40357; Thu, 3 May 2012 12:14:09 -0400 (EDT) Date: Thu, 3 May 2012 12:14:09 -0400 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky Message-ID: <20120503161409.GB9992@phenom.dumpdata.com> References: <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA1B096.5010009@amd.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 06:09:26PM -0400, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: > >On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: > >>On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: > >>>On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: > >>>>On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: > >>>>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >>>>>index a8f8844..d816448 100644 > >>>>>--- a/arch/x86/xen/enlighten.c > >>>>>+++ b/arch/x86/xen/enlighten.c > >>>>>@@ -811,7 +811,29 @@ static void xen_io_delay(void) > >>>>> #ifdef CONFIG_X86_LOCAL_APIC > >>>>> static u32 xen_apic_read(u32 reg) > >>>>> { > >>>>>- return 0; > >>>>>+ struct xen_platform_op op = { > >>>>>+ .cmd = XENPF_get_cpuinfo, > >>>>>+ .interface_version = XENPF_INTERFACE_VERSION, > >>>>>+ .u.pcpu_info.xen_cpuid = 0, > >>>> > >>>> > >>>>Is this always zero? This will probably solve the current problem > >>> > >>>Its a CPU number (not tied in to APIC or ACPI IDs). > >> > >>Why not use CPU number instead of zero here? > > > >The issue was only with the bootup CPU - so was using the Xen's > >bootup CPU number - which is zero (as is Linux's). > > I agree that for this particular problem this may be sufficient. > > My concern is that in the future someone may decide to use > apic_read(APIC_ID) or read_apic_id() for some other purpose and they > won't get expected result (i.e. on all CPUs they will get the same > answer). Good point. Let's get this particular bug fixed for v3.5, and then will do a more comprehensive fix for v3.6. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:24:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPypB-0003oY-Ei; Thu, 03 May 2012 16:24:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyp9-0003oN-P9 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:24:11 +0000 Received: from [85.158.143.35:57558] by server-2.bemta-4.messagelabs.com id B5/68-17550-A21B2AF4; Thu, 03 May 2012 16:24:10 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1336062249!11415149!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18432 invoked from network); 3 May 2012 16:24:10 -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; 3 May 2012 16:24:10 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPyp7-000Ons-HG; Thu, 03 May 2012 16:24:09 +0000 Date: Thu, 3 May 2012 17:24:09 +0100 From: Tim Deegan To: Andres Lagar-Cavilla Message-ID: <20120503162409.GE90833@ocelot.phlegethon.org> References: <00034349414ec903179d.1335561378@xdev.gridcentric.ca> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <00034349414ec903179d.1335561378@xdev.gridcentric.ca> User-Agent: Mutt/1.4.2.1i Cc: "Zhang, Yang Z" , andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1 of 4] x86/mm: Eliminate _shadow_mode_refcounts X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 17:16 -0400 on 27 Apr (1335546978), Andres Lagar-Cavilla wrote: > xen/arch/x86/mm.c | 2 +- > xen/arch/x86/mm/shadow/common.c | 5 ----- > xen/include/asm-x86/mm.h | 1 - > 3 files changed, 1 insertions(+), 7 deletions(-) > > > Replace it with the proper paging_mode_refcounts. This was causing spurious > and abundant verbiage from Xen for the > > !get_page(page, d) && !get_page(page, dom_cow) > > sequence in get_page_from_gfn > > Signed-off-by: Andres Lagar-Cavilla Applied, thanks. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:24:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPypB-0003oY-Ei; Thu, 03 May 2012 16:24:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyp9-0003oN-P9 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:24:11 +0000 Received: from [85.158.143.35:57558] by server-2.bemta-4.messagelabs.com id B5/68-17550-A21B2AF4; Thu, 03 May 2012 16:24:10 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1336062249!11415149!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18432 invoked from network); 3 May 2012 16:24:10 -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; 3 May 2012 16:24:10 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SPyp7-000Ons-HG; Thu, 03 May 2012 16:24:09 +0000 Date: Thu, 3 May 2012 17:24:09 +0100 From: Tim Deegan To: Andres Lagar-Cavilla Message-ID: <20120503162409.GE90833@ocelot.phlegethon.org> References: <00034349414ec903179d.1335561378@xdev.gridcentric.ca> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <00034349414ec903179d.1335561378@xdev.gridcentric.ca> User-Agent: Mutt/1.4.2.1i Cc: "Zhang, Yang Z" , andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1 of 4] x86/mm: Eliminate _shadow_mode_refcounts X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 17:16 -0400 on 27 Apr (1335546978), Andres Lagar-Cavilla wrote: > xen/arch/x86/mm.c | 2 +- > xen/arch/x86/mm/shadow/common.c | 5 ----- > xen/include/asm-x86/mm.h | 1 - > 3 files changed, 1 insertions(+), 7 deletions(-) > > > Replace it with the proper paging_mode_refcounts. This was causing spurious > and abundant verbiage from Xen for the > > !get_page(page, d) && !get_page(page, dom_cow) > > sequence in get_page_from_gfn > > Signed-off-by: Andres Lagar-Cavilla Applied, thanks. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:27:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPysQ-0003zu-8Y; Thu, 03 May 2012 16:27:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPysP-0003zm-DQ for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:27:33 +0000 Received: from [85.158.143.35:48494] by server-3.bemta-4.messagelabs.com id 9B/E9-05853-4F1B2AF4; Thu, 03 May 2012 16:27:32 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336062450!14649829!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27747 invoked from network); 3 May 2012 16:27:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:27:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="193271122" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:27:29 -0400 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, 3 May 2012 12:27:28 -0400 Message-ID: <4FA2B1EF.8080900@citrix.com> Date: Thu, 3 May 2012 17:27:27 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> In-Reply-To: <4FA2A11E.1060907@cantab.net> Cc: "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 16:15, David Vrabel wrote: > > xen: update VA mapping when releasing memory during setup > > In xen_memory_setup(), if a page that is being released has a VA > mapping this must also be updated. Otherwise, the page will be not > released completely -- it will still be referenced in Xen and won't be > freed util the mapping is removed and this prevents it from being > reallocated at a different PFN. > > This was already being done for the ISA memory region in > xen_ident_map_ISA() but on many systems this was omitting a few pages > as many systems marked a few pages below the ISA memory region as > reserved in the e820 map. > > Signed-off-by: David Vrabel > --- [...] > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > #endif > } > > -void __init xen_ident_map_ISA(void) > -{ > - unsigned long pa; > - > - /* > - * If we're dom0, then linear map the ISA machine addresses into > - * the kernel's address space. > - */ > - if (!xen_initial_domain()) > - return; It might look like this test has gone, however the new code which updates the VA mapping uses the e820 map and for a domU its map will not have a ISA region so there's no mapping to be updated. David > - > - xen_raw_printk("Xen: setup ISA identity maps\n"); > - > - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { > - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); > - > - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) > - BUG(); > - } > - > - xen_flush_tlb(); > -} > - > static void __init xen_post_allocator_init(void) > { > pv_mmu_ops.set_pte = xen_set_pte; > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 506a3e6..d5f8714 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, > > return len; > } > + > +static unsigned long __init xen_release_chunk(unsigned long start, > + unsigned long end) > +{ > + return xen_do_chunk(start, end, true); > +} > + > static unsigned long __init xen_populate_chunk( > const struct e820entry *list, size_t map_size, > unsigned long max_pfn, unsigned long *last_pfn, > @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( > } > return done; > } > + > +static void __init xen_set_identity_and_release_chunk( > + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, > + unsigned long *released, unsigned long *identity) > +{ > + unsigned long pfn; > + > + /* > + * If the PFNs are currently mapped, the VA mapping also needs > + * to be updated to be 1:1. > + */ > + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) > + (void)HYPERVISOR_update_va_mapping( > + (unsigned long)__va(pfn << PAGE_SHIFT), > + mfn_pte(pfn, PAGE_KERNEL_IO), 0); > + > + if (start_pfn < nr_pages) > + *released += xen_release_chunk( > + start_pfn, min(end_pfn, nr_pages)); > + > + *identity += set_phys_range_identity(start_pfn, end_pfn); > +} > + > static unsigned long __init xen_set_identity_and_release( > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > { > @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( > if (entry->type == E820_RAM) > end_pfn = PFN_UP(entry->addr); > > - if (start_pfn < end_pfn) { > - if (start_pfn < nr_pages) > - released += xen_do_chunk( > - start_pfn, min(end_pfn, nr_pages), true); > + if (start_pfn < end_pfn) > + xen_set_identity_and_release_chunk( > + start_pfn, end_pfn, nr_pages, > + &released, &identity); > > - identity += set_phys_range_identity( > - start_pfn, end_pfn); > - } > start = end; > } > } > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > index b095739..506fa08 100644 > --- a/arch/x86/xen/xen-ops.h > +++ b/arch/x86/xen/xen-ops.h > @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); > void xen_build_mfn_list_list(void); > void xen_setup_machphys_mapping(void); > pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); > -void xen_ident_map_ISA(void); > void xen_reserve_top(void); > extern unsigned long xen_max_p2m_pfn; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:27:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPysQ-0003zu-8Y; Thu, 03 May 2012 16:27:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPysP-0003zm-DQ for xen-devel@lists.xensource.com; Thu, 03 May 2012 16:27:33 +0000 Received: from [85.158.143.35:48494] by server-3.bemta-4.messagelabs.com id 9B/E9-05853-4F1B2AF4; Thu, 03 May 2012 16:27:32 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336062450!14649829!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDkzMTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27747 invoked from network); 3 May 2012 16:27:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:27:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="193271122" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 12:27:29 -0400 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, 3 May 2012 12:27:28 -0400 Message-ID: <4FA2B1EF.8080900@citrix.com> Date: Thu, 3 May 2012 17:27:27 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> In-Reply-To: <4FA2A11E.1060907@cantab.net> Cc: "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/05/12 16:15, David Vrabel wrote: > > xen: update VA mapping when releasing memory during setup > > In xen_memory_setup(), if a page that is being released has a VA > mapping this must also be updated. Otherwise, the page will be not > released completely -- it will still be referenced in Xen and won't be > freed util the mapping is removed and this prevents it from being > reallocated at a different PFN. > > This was already being done for the ISA memory region in > xen_ident_map_ISA() but on many systems this was omitting a few pages > as many systems marked a few pages below the ISA memory region as > reserved in the e820 map. > > Signed-off-by: David Vrabel > --- [...] > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > #endif > } > > -void __init xen_ident_map_ISA(void) > -{ > - unsigned long pa; > - > - /* > - * If we're dom0, then linear map the ISA machine addresses into > - * the kernel's address space. > - */ > - if (!xen_initial_domain()) > - return; It might look like this test has gone, however the new code which updates the VA mapping uses the e820 map and for a domU its map will not have a ISA region so there's no mapping to be updated. David > - > - xen_raw_printk("Xen: setup ISA identity maps\n"); > - > - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { > - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); > - > - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) > - BUG(); > - } > - > - xen_flush_tlb(); > -} > - > static void __init xen_post_allocator_init(void) > { > pv_mmu_ops.set_pte = xen_set_pte; > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 506a3e6..d5f8714 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, > > return len; > } > + > +static unsigned long __init xen_release_chunk(unsigned long start, > + unsigned long end) > +{ > + return xen_do_chunk(start, end, true); > +} > + > static unsigned long __init xen_populate_chunk( > const struct e820entry *list, size_t map_size, > unsigned long max_pfn, unsigned long *last_pfn, > @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( > } > return done; > } > + > +static void __init xen_set_identity_and_release_chunk( > + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, > + unsigned long *released, unsigned long *identity) > +{ > + unsigned long pfn; > + > + /* > + * If the PFNs are currently mapped, the VA mapping also needs > + * to be updated to be 1:1. > + */ > + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) > + (void)HYPERVISOR_update_va_mapping( > + (unsigned long)__va(pfn << PAGE_SHIFT), > + mfn_pte(pfn, PAGE_KERNEL_IO), 0); > + > + if (start_pfn < nr_pages) > + *released += xen_release_chunk( > + start_pfn, min(end_pfn, nr_pages)); > + > + *identity += set_phys_range_identity(start_pfn, end_pfn); > +} > + > static unsigned long __init xen_set_identity_and_release( > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > { > @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( > if (entry->type == E820_RAM) > end_pfn = PFN_UP(entry->addr); > > - if (start_pfn < end_pfn) { > - if (start_pfn < nr_pages) > - released += xen_do_chunk( > - start_pfn, min(end_pfn, nr_pages), true); > + if (start_pfn < end_pfn) > + xen_set_identity_and_release_chunk( > + start_pfn, end_pfn, nr_pages, > + &released, &identity); > > - identity += set_phys_range_identity( > - start_pfn, end_pfn); > - } > start = end; > } > } > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > index b095739..506fa08 100644 > --- a/arch/x86/xen/xen-ops.h > +++ b/arch/x86/xen/xen-ops.h > @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); > void xen_build_mfn_list_list(void); > void xen_setup_machphys_mapping(void); > pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); > -void xen_ident_map_ISA(void); > void xen_reserve_top(void); > extern unsigned long xen_max_p2m_pfn; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:31:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyvZ-00047s-48; Thu, 03 May 2012 16:30:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyvX-00047L-R4 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:30:47 +0000 Received: from [85.158.143.35:33433] by server-2.bemta-4.messagelabs.com id C5/FE-17550-6B2B2AF4; Thu, 03 May 2012 16:30:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336062645!14921320!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30537 invoked from network); 3 May 2012 16:30:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:30:45 -0000 Received: by eekc4 with SMTP id c4so95309eek.32 for ; Thu, 03 May 2012 09:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ue9NJDg+1BM0CPGjQm3nShJ1RX89uNTmlIklzjpBq8k=; b=V28QjH2OW/4e1jV4Rr6Dj/JWxfaUK1ysRbFNjCccDpL8IQzEZjvJXZOXJDHsVdXUXP vbk6dcVd4pTHa/73B7QU/kVrxwsP2nnYDTnTRo+TfVfq6hEAEQETt1cCAXG3Hjbdgp83 acz+BZoRQkPu87I+ocyBPWyURMEVWMisUd5e8clR80l6QQ75blmzP0AkKorqrlTTPBPC cZUw3FjrEh3u7CJWT6p5Dgy8faZi2l63AOcufLCW3mAZbD7OIg6y36OkohWNYIYCC4Sh RxutUrBWByvc8uAFG/Eeg0MpOCGBH5pO2wm/SdunlyUTER7LMgrFr8dvtC51myv3+FiB +Whg== Received: by 10.14.99.137 with SMTP id x9mr606262eef.15.1336062645127; Thu, 03 May 2012 09:30:45 -0700 (PDT) Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55]) by mx.google.com with ESMTPS id n52sm20834382eef.6.2012.05.03.09.30.42 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:30:43 -0700 (PDT) Message-ID: <4FA2B2B1.3040901@xen.org> Date: Thu, 03 May 2012 17:30:41 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-api@lists.xen.org, xen-arm@lists.xen.org Subject: [Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dear Developers, we have had the original Xen project governance document (see http://xen.org/projects/governance.html ) in effect now since July last year. The last minor review was in October 2011. Since then I had feedback on two items: a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past. b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer). Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead". Timetable: 1) Open review with feedback until 11th May (a bit more than a week from today) 2) Lars to incorporate any feedback and publish a revision. 3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP). Best Regards Lars _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 16:31:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 16: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 ) id 1SPyvZ-00047s-48; Thu, 03 May 2012 16:30:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPyvX-00047L-R4 for xen-devel@lists.xen.org; Thu, 03 May 2012 16:30:47 +0000 Received: from [85.158.143.35:33433] by server-2.bemta-4.messagelabs.com id C5/FE-17550-6B2B2AF4; Thu, 03 May 2012 16:30:46 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336062645!14921320!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30537 invoked from network); 3 May 2012 16:30:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 16:30:45 -0000 Received: by eekc4 with SMTP id c4so95309eek.32 for ; Thu, 03 May 2012 09:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ue9NJDg+1BM0CPGjQm3nShJ1RX89uNTmlIklzjpBq8k=; b=V28QjH2OW/4e1jV4Rr6Dj/JWxfaUK1ysRbFNjCccDpL8IQzEZjvJXZOXJDHsVdXUXP vbk6dcVd4pTHa/73B7QU/kVrxwsP2nnYDTnTRo+TfVfq6hEAEQETt1cCAXG3Hjbdgp83 acz+BZoRQkPu87I+ocyBPWyURMEVWMisUd5e8clR80l6QQ75blmzP0AkKorqrlTTPBPC cZUw3FjrEh3u7CJWT6p5Dgy8faZi2l63AOcufLCW3mAZbD7OIg6y36OkohWNYIYCC4Sh RxutUrBWByvc8uAFG/Eeg0MpOCGBH5pO2wm/SdunlyUTER7LMgrFr8dvtC51myv3+FiB +Whg== Received: by 10.14.99.137 with SMTP id x9mr606262eef.15.1336062645127; Thu, 03 May 2012 09:30:45 -0700 (PDT) Received: from [172.16.25.10] (b0fb6237.bb.sky.com. [176.251.98.55]) by mx.google.com with ESMTPS id n52sm20834382eef.6.2012.05.03.09.30.42 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:30:43 -0700 (PDT) Message-ID: <4FA2B2B1.3040901@xen.org> Date: Thu, 03 May 2012 17:30:41 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen-devel@lists.xen.org, xen-api@lists.xen.org, xen-arm@lists.xen.org Subject: [Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dear Developers, we have had the original Xen project governance document (see http://xen.org/projects/governance.html ) in effect now since July last year. The last minor review was in October 2011. Since then I had feedback on two items: a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past. b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer). Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead". Timetable: 1) Open review with feedback until 11th May (a bit more than a week from today) 2) Lars to incorporate any feedback and publish a revision. 3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP). Best Regards Lars _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:03:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPzQk-00059w-7Z; Thu, 03 May 2012 17:03:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzQi-00059o-Lm for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:03:00 +0000 Received: from [85.158.143.35:49219] by server-1.bemta-4.messagelabs.com id CC/93-20925-44AB2AF4; Thu, 03 May 2012 17:03:00 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336064577!11418843!1 X-Originating-IP: [216.32.180.16] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12521 invoked from network); 3 May 2012 17:02:58 -0000 Received: from va3ehsobe006.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.16) by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 3 May 2012 17:02:58 -0000 Received: from mail197-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 17:02:47 +0000 Received: from mail197-va3 (localhost [127.0.0.1]) by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 818DC3A06D3; Thu, 3 May 2012 17:02:47 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dI9371I1432N98dK179dN853kzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1336064565227670_23297; Thu, 3 May 2012 17:02:45 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.252]) by mail197-va3.bigfish.com (Postfix) with ESMTP id 24C79C02A6; Thu, 3 May 2012 17:02:45 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 17:02:43 +0000 X-WSS-ID: 0M3GI0R-01-GB5-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 25253D10019; Thu, 3 May 2012 12:02:51 -0500 (CDT) 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, 3 May 2012 12:03:06 -0500 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, 3 May 2012 12:02:50 -0500 Message-ID: <4FA2BA3A.7070100@amd.com> Date: Thu, 3 May 2012 13:02:50 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> In-Reply-To: <20120503154620.GB3464@andromeda.dapyr.net> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/03/2012 11:46 AM, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 04:47:46PM +0200, Stefan Bader wrote: >> On 03.05.2012 14:58, Stefan Bader wrote: >> >>>>>>> So this shoudl solve the problem for the bootup processor. >>>>>>>> >>>>>>>> -boris >>>>>>>> >>>>>>>> >>>>>>>>> + }; >>>>>>>>> + int ret = 0; >>>>>>>>> + >>>>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>>>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + if (reg == APIC_LVR) >>>>>>>>> + return 0x10; >>>>>>>>> + >>>>>>>>> + if (reg != APIC_ID) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + ret = HYPERVISOR_dom0_op(&op); >>>>>>>>> + if (ret) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + return op.u.pcpu_info.apic_id; return (op.u.pcpu_info.apic_id << 24); indeed fixes the problem. -boris >>>>>>>>> } >>>>>>>>> >>>>>>>>> static void xen_apic_write(u32 reg, u32 val) >>> >>> I added debugging to all exit paths that could return 0 (which is what the >>> boot_cpu_physical_apicid is set to with that patch. Which would only leave the >>> case of the HV call returning the wrong value somehow... >>> >> Hmmm, so xen_apic_read is still correct... >> >> [ 0.000000] ACPI: Local APIC address 0xfee00000 >> [ 0.000000] xxx xen_apic_read(20) >> [ 0.000000] xxx xen_apic_read -> 10 >> [ 0.000000] boot_cpu_physical_apicid = 0 >> [ 0.000000] xxx xen_apic_read(30) >> [ 0.000000] +- apic version = 10 >> >> there seems to be a slightly strange tweak (at least for me) in read_apic_id... >> >> static inline unsigned int read_apic_id(void) >> { >> unsigned int reg; >> >> reg = apic_read(APIC_ID); // calls apic->read(reg) >> >> return apic->get_apic_id(reg); > > Duh!! Let me spin out a new patch that will do this. >> } >> >> > > > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:03:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 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 ) id 1SPzQk-00059w-7Z; Thu, 03 May 2012 17:03:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzQi-00059o-Lm for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:03:00 +0000 Received: from [85.158.143.35:49219] by server-1.bemta-4.messagelabs.com id CC/93-20925-44AB2AF4; Thu, 03 May 2012 17:03:00 +0000 X-Env-Sender: Boris.Ostrovsky@amd.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336064577!11418843!1 X-Originating-IP: [216.32.180.16] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12521 invoked from network); 3 May 2012 17:02:58 -0000 Received: from va3ehsobe006.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.16) by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 3 May 2012 17:02:58 -0000 Received: from mail197-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 17:02:47 +0000 Received: from mail197-va3 (localhost [127.0.0.1]) by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 818DC3A06D3; Thu, 3 May 2012 17:02:47 +0000 (UTC) X-SpamScore: -14 X-BigFish: VPS-14(zzbb2dI9371I1432N98dK179dN853kzz1202hzz8275dhz2dh668h839hd25he5bh) 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 mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1336064565227670_23297; Thu, 3 May 2012 17:02:45 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.252]) by mail197-va3.bigfish.com (Postfix) with ESMTP id 24C79C02A6; Thu, 3 May 2012 17:02:45 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 17:02:43 +0000 X-WSS-ID: 0M3GI0R-01-GB5-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 25253D10019; Thu, 3 May 2012 12:02:51 -0500 (CDT) 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, 3 May 2012 12:03:06 -0500 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, 3 May 2012 12:02:50 -0500 Message-ID: <4FA2BA3A.7070100@amd.com> Date: Thu, 3 May 2012 13:02:50 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> In-Reply-To: <20120503154620.GB3464@andromeda.dapyr.net> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/03/2012 11:46 AM, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 04:47:46PM +0200, Stefan Bader wrote: >> On 03.05.2012 14:58, Stefan Bader wrote: >> >>>>>>> So this shoudl solve the problem for the bootup processor. >>>>>>>> >>>>>>>> -boris >>>>>>>> >>>>>>>> >>>>>>>>> + }; >>>>>>>>> + int ret = 0; >>>>>>>>> + >>>>>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we only >>>>>>>>> + * get called on the bootup processor. But just in case. */ >>>>>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + if (reg == APIC_LVR) >>>>>>>>> + return 0x10; >>>>>>>>> + >>>>>>>>> + if (reg != APIC_ID) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + ret = HYPERVISOR_dom0_op(&op); >>>>>>>>> + if (ret) >>>>>>>>> + return 0; >>>>>>>>> + >>>>>>>>> + return op.u.pcpu_info.apic_id; return (op.u.pcpu_info.apic_id << 24); indeed fixes the problem. -boris >>>>>>>>> } >>>>>>>>> >>>>>>>>> static void xen_apic_write(u32 reg, u32 val) >>> >>> I added debugging to all exit paths that could return 0 (which is what the >>> boot_cpu_physical_apicid is set to with that patch. Which would only leave the >>> case of the HV call returning the wrong value somehow... >>> >> Hmmm, so xen_apic_read is still correct... >> >> [ 0.000000] ACPI: Local APIC address 0xfee00000 >> [ 0.000000] xxx xen_apic_read(20) >> [ 0.000000] xxx xen_apic_read -> 10 >> [ 0.000000] boot_cpu_physical_apicid = 0 >> [ 0.000000] xxx xen_apic_read(30) >> [ 0.000000] +- apic version = 10 >> >> there seems to be a slightly strange tweak (at least for me) in read_apic_id... >> >> static inline unsigned int read_apic_id(void) >> { >> unsigned int reg; >> >> reg = apic_read(APIC_ID); // calls apic->read(reg) >> >> return apic->get_apic_id(reg); > > Duh!! Let me spin out a new patch that will do this. >> } >> >> > > > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:12:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzZy-0005UP-Cl; Thu, 03 May 2012 17:12:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzZw-0005UK-Lo for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:12:33 +0000 Received: from [193.109.254.147:56342] by server-8.bemta-14.messagelabs.com id FB/25-23244-08CB2AF4; Thu, 03 May 2012 17:12:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336065151!702356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7655 invoked from network); 3 May 2012 17:12:31 -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; 3 May 2012 17:12:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330905600"; d="scan'208";a="12281168" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 17:12: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, 3 May 2012 18:12:30 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPzZu-0003Mb-LT; Thu, 03 May 2012 17:12:30 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPzZu-00044Q-Iq; Thu, 03 May 2012 18:12:30 +0100 To: Message-ID: From: xen.org Date: Thu, 3 May 2012 18:12:30 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12787: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12787 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12787/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-win 12 guest-localmigrate/x10 fail pass in 12768 test-i386-i386-xl 3 host-install(3) broken in 12768 pass in 12787 test-i386-i386-pv 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-xl 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-pv 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-xl-multivcpu 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken in 12768 pass in 12787 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop 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-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail in 12768 never pass version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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-3.0 f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + branch=linux-3.0 + revision=f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git f1c84a5cb52ee2915457b481c756fcc1dfe6a471:tested/linux-3.0 Counting objects: 1 Counting objects: 932, done. Compressing objects: 0% (1/153) Compressing objects: 1% (2/153) Compressing objects: 2% (4/153) Compressing objects: 3% (5/153) Compressing objects: 4% (7/153) Compressing objects: 5% (8/153) Compressing objects: 6% (10/153) Compressing objects: 7% (11/153) Compressing objects: 8% (13/153) Compressing objects: 9% (14/153) Compressing objects: 10% (16/153) Compressing objects: 11% (17/153) Compressing objects: 12% (19/153) Compressing objects: 13% (20/153) Compressing objects: 14% (22/153) Compressing objects: 15% (23/153) Compressing objects: 16% (25/153) Compressing objects: 17% (27/153) Compressing objects: 18% (28/153) Compressing objects: 19% (30/153) Compressing objects: 20% (31/153) Compressing objects: 21% (33/153) Compressing objects: 22% (34/153) Compressing objects: 23% (36/153) Compressing objects: 24% (37/153) Compressing objects: 25% (39/153) Compressing objects: 26% (40/153) Compressing objects: 27% (42/153) Compressing objects: 28% (43/153) Compressing objects: 29% (45/153) Compressing objects: 30% (46/153) Compressing objects: 31% (48/153) Compressing objects: 32% (49/153) Compressing objects: 33% (51/153) Compressing objects: 34% (53/153) Compressing objects: 35% (54/153) Compressing objects: 36% (56/153) Compressing objects: 37% (57/153) Compressing objects: 38% (59/153) Compressing objects: 39% (60/153) Compressing objects: 40% (62/153) Compressing objects: 41% (63/153) Compressing objects: 42% (65/153) Compressing objects: 43% (66/153) Compressing objects: 44% (68/153) Compressing objects: 45% (69/153) Compressing objects: 46% (71/153) Compressing objects: 47% (72/153) Compressing objects: 48% (74/153) Compressing objects: 49% (75/153) Compressing objects: 50% (77/153) Compressing objects: 51% (79/153) Compressing objects: 52% (80/153) Compressing objects: 53% (82/153) Compressing objects: 54% (83/153) Compressing objects: 55% (85/153) Compressing objects: 56% (86/153) Compressing objects: 57% (88/153) Compressing objects: 58% (89/153) Compressing objects: 59% (91/153) Compressing objects: 60% (92/153) Compressing objects: 61% (94/153) Compressing objects: 62% (95/153) Compressing objects: 63% (97/153) Compressing objects: 64% (98/153) Compressing objects: 65% (100/153) Compressing objects: 66% (101/153) Compressing objects: 67% (103/153) Compressing objects: 68% (105/153) Compressing objects: 69% (106/153) Compressing objects: 70% (108/153) Compressing objects: 71% (109/153) Compressing objects: 72% (111/153) Compressing objects: 73% (112/153) Compressing objects: 74% (114/153) Compressing objects: 75% (115/153) Compressing objects: 76% (117/153) Compressing objects: 77% (118/153) Compressing objects: 78% (120/153) Compressing objects: 79% (121/153) Compressing objects: 80% (123/153) Compressing objects: 81% (124/153) Compressing objects: 82% (126/153) Compressing objects: 83% (127/153) Compressing objects: 84% (129/153) Compressing objects: 85% (131/153) Compressing objects: 86% (132/153) Compressing objects: 87% (134/153) Compressing objects: 88% (135/153) Compressing objects: 89% (137/153) Compressing objects: 90% (138/153) Compressing objects: 91% (140/153) Compressing objects: 92% (141/153) Compressing objects: 93% (143/153) Compressing objects: 94% (144/153) Compressing objects: 95% (146/153) Compressing objects: 96% (147/153) Compressing objects: 97% (149/153) Compressing objects: 98% (150/153) Compressing objects: 99% (152/153) Compressing objects: 100% (153/153) Compressing objects: 100% (153/153), done. Writing objects: 0% (1/727) Writing objects: 1% (8/727) Writing objects: 2% (15/727) Writing objects: 3% (22/727) Writing objects: 4% (30/727) Writing objects: 5% (37/727) Writing objects: 6% (44/727) Writing objects: 7% (51/727) Writing objects: 8% (59/727) Writing objects: 9% (66/727) Writing objects: 10% (73/727) Writing objects: 11% (80/727) Writing objects: 12% (88/727) Writing objects: 13% (95/727) Writing objects: 14% (102/727) Writing objects: 15% (110/727) Writing objects: 16% (117/727) Writing objects: 17% (124/727) Writing objects: 18% (131/727) Writing objects: 19% (139/727) Writing objects: 20% (146/727) Writing objects: 21% (154/727) Writing objects: 22% (160/727) Writing objects: 23% (168/727) Writing objects: 24% (175/727) Writing objects: 25% (182/727) Writing objects: 26% (190/727) Writing objects: 27% (197/727) Writing objects: 28% (204/727) Writing objects: 29% (211/727) Writing objects: 30% (219/727) Writing objects: 31% (226/727) Writing objects: 32% (233/727) Writing objects: 33% (240/727) Writing objects: 34% (248/727) Writing objects: 35% (255/727) Writing objects: 36% (263/727) Writing objects: 37% (269/727) Writing objects: 38% (277/727) Writing objects: 39% (284/727) Writing objects: 40% (291/727) Writing objects: 41% (299/727) Writing objects: 42% (306/727) Writing objects: 43% (314/727) Writing objects: 44% (320/727) Writing objects: 45% (328/727) Writing objects: 46% (335/727) Writing objects: 47% (342/727) Writing objects: 48% (349/727) Writing objects: 49% (357/727) Writing objects: 50% (364/727) Writing objects: 51% (371/727) Writing objects: 52% (379/727) Writing objects: 53% (386/727) Writing objects: 54% (393/727) Writing objects: 55% (400/727) Writing objects: 56% (408/727) Writing objects: 57% (415/727) Writing objects: 58% (422/727) Writing objects: 59% (429/727) Writing objects: 60% (437/727) Writing objects: 61% (444/727) Writing objects: 62% (451/727) Writing objects: 63% (459/727) Writing objects: 64% (466/727) Writing objects: 65% (473/727) Writing objects: 66% (480/727) Writing objects: 67% (488/727) Writing objects: 68% (495/727) Writing objects: 69% (502/727) Writing objects: 70% (509/727) Writing objects: 71% (517/727) Writing objects: 72% (524/727) Writing objects: 73% (531/727) Writing objects: 74% (538/727) Writing objects: 75% (546/727) Writing objects: 76% (553/727) Writing objects: 77% (560/727) Writing objects: 78% (568/727) Writing objects: 79% (575/727) Writing objects: 80% (582/727) Writing objects: 81% (589/727) Writing objects: 82% (597/727) Writing objects: 83% (604/727) Writing objects: 84% (611/727) Writing objects: 85% (618/727) Writing objects: 86% (626/727) Writing objects: 87% (633/727) Writing objects: 88% (640/727) Writing objects: 89% (648/727) Writing objects: 90% (655/727) Writing objects: 91% (662/727) Writing objects: 92% (669/727) Writing objects: 93% (677/727) Writing objects: 94% (684/727) Writing objects: 95% (691/727) Writing objects: 96% (698/727) Writing objects: 97% (706/727) Writing objects: 98% (713/727) Writing objects: 99% (720/727) Writing objects: 100% (727/727) Writing objects: 100% (727/727), 126.51 KiB, done. Total 727 (delta 597), reused 702 (delta 572) To xen@xenbits.xensource.com:git/linux-pvops.git 0527fde..f1c84a5 f1c84a5cb52ee2915457b481c756fcc1dfe6a471 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:12:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzZy-0005UP-Cl; Thu, 03 May 2012 17:12:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzZw-0005UK-Lo for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:12:33 +0000 Received: from [193.109.254.147:56342] by server-8.bemta-14.messagelabs.com id FB/25-23244-08CB2AF4; Thu, 03 May 2012 17:12:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336065151!702356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7655 invoked from network); 3 May 2012 17:12:31 -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; 3 May 2012 17:12:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,524,1330905600"; d="scan'208";a="12281168" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 17:12: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, 3 May 2012 18:12:30 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SPzZu-0003Mb-LT; Thu, 03 May 2012 17:12:30 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SPzZu-00044Q-Iq; Thu, 03 May 2012 18:12:30 +0100 To: Message-ID: From: xen.org Date: Thu, 3 May 2012 18:12:30 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12787: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12787 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12787/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-win 12 guest-localmigrate/x10 fail pass in 12768 test-i386-i386-xl 3 host-install(3) broken in 12768 pass in 12787 test-i386-i386-pv 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-xl 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-pv 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-xl-multivcpu 3 host-install(3) broken in 12768 pass in 12787 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken in 12768 pass in 12787 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop 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-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail in 12768 never pass version targeted for testing: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 baseline version: linux 0527fde0639955203ad48a9fd83bd6fc35e82e07 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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-3.0 f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + branch=linux-3.0 + revision=f1c84a5cb52ee2915457b481c756fcc1dfe6a471 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git f1c84a5cb52ee2915457b481c756fcc1dfe6a471:tested/linux-3.0 Counting objects: 1 Counting objects: 932, done. Compressing objects: 0% (1/153) Compressing objects: 1% (2/153) Compressing objects: 2% (4/153) Compressing objects: 3% (5/153) Compressing objects: 4% (7/153) Compressing objects: 5% (8/153) Compressing objects: 6% (10/153) Compressing objects: 7% (11/153) Compressing objects: 8% (13/153) Compressing objects: 9% (14/153) Compressing objects: 10% (16/153) Compressing objects: 11% (17/153) Compressing objects: 12% (19/153) Compressing objects: 13% (20/153) Compressing objects: 14% (22/153) Compressing objects: 15% (23/153) Compressing objects: 16% (25/153) Compressing objects: 17% (27/153) Compressing objects: 18% (28/153) Compressing objects: 19% (30/153) Compressing objects: 20% (31/153) Compressing objects: 21% (33/153) Compressing objects: 22% (34/153) Compressing objects: 23% (36/153) Compressing objects: 24% (37/153) Compressing objects: 25% (39/153) Compressing objects: 26% (40/153) Compressing objects: 27% (42/153) Compressing objects: 28% (43/153) Compressing objects: 29% (45/153) Compressing objects: 30% (46/153) Compressing objects: 31% (48/153) Compressing objects: 32% (49/153) Compressing objects: 33% (51/153) Compressing objects: 34% (53/153) Compressing objects: 35% (54/153) Compressing objects: 36% (56/153) Compressing objects: 37% (57/153) Compressing objects: 38% (59/153) Compressing objects: 39% (60/153) Compressing objects: 40% (62/153) Compressing objects: 41% (63/153) Compressing objects: 42% (65/153) Compressing objects: 43% (66/153) Compressing objects: 44% (68/153) Compressing objects: 45% (69/153) Compressing objects: 46% (71/153) Compressing objects: 47% (72/153) Compressing objects: 48% (74/153) Compressing objects: 49% (75/153) Compressing objects: 50% (77/153) Compressing objects: 51% (79/153) Compressing objects: 52% (80/153) Compressing objects: 53% (82/153) Compressing objects: 54% (83/153) Compressing objects: 55% (85/153) Compressing objects: 56% (86/153) Compressing objects: 57% (88/153) Compressing objects: 58% (89/153) Compressing objects: 59% (91/153) Compressing objects: 60% (92/153) Compressing objects: 61% (94/153) Compressing objects: 62% (95/153) Compressing objects: 63% (97/153) Compressing objects: 64% (98/153) Compressing objects: 65% (100/153) Compressing objects: 66% (101/153) Compressing objects: 67% (103/153) Compressing objects: 68% (105/153) Compressing objects: 69% (106/153) Compressing objects: 70% (108/153) Compressing objects: 71% (109/153) Compressing objects: 72% (111/153) Compressing objects: 73% (112/153) Compressing objects: 74% (114/153) Compressing objects: 75% (115/153) Compressing objects: 76% (117/153) Compressing objects: 77% (118/153) Compressing objects: 78% (120/153) Compressing objects: 79% (121/153) Compressing objects: 80% (123/153) Compressing objects: 81% (124/153) Compressing objects: 82% (126/153) Compressing objects: 83% (127/153) Compressing objects: 84% (129/153) Compressing objects: 85% (131/153) Compressing objects: 86% (132/153) Compressing objects: 87% (134/153) Compressing objects: 88% (135/153) Compressing objects: 89% (137/153) Compressing objects: 90% (138/153) Compressing objects: 91% (140/153) Compressing objects: 92% (141/153) Compressing objects: 93% (143/153) Compressing objects: 94% (144/153) Compressing objects: 95% (146/153) Compressing objects: 96% (147/153) Compressing objects: 97% (149/153) Compressing objects: 98% (150/153) Compressing objects: 99% (152/153) Compressing objects: 100% (153/153) Compressing objects: 100% (153/153), done. Writing objects: 0% (1/727) Writing objects: 1% (8/727) Writing objects: 2% (15/727) Writing objects: 3% (22/727) Writing objects: 4% (30/727) Writing objects: 5% (37/727) Writing objects: 6% (44/727) Writing objects: 7% (51/727) Writing objects: 8% (59/727) Writing objects: 9% (66/727) Writing objects: 10% (73/727) Writing objects: 11% (80/727) Writing objects: 12% (88/727) Writing objects: 13% (95/727) Writing objects: 14% (102/727) Writing objects: 15% (110/727) Writing objects: 16% (117/727) Writing objects: 17% (124/727) Writing objects: 18% (131/727) Writing objects: 19% (139/727) Writing objects: 20% (146/727) Writing objects: 21% (154/727) Writing objects: 22% (160/727) Writing objects: 23% (168/727) Writing objects: 24% (175/727) Writing objects: 25% (182/727) Writing objects: 26% (190/727) Writing objects: 27% (197/727) Writing objects: 28% (204/727) Writing objects: 29% (211/727) Writing objects: 30% (219/727) Writing objects: 31% (226/727) Writing objects: 32% (233/727) Writing objects: 33% (240/727) Writing objects: 34% (248/727) Writing objects: 35% (255/727) Writing objects: 36% (263/727) Writing objects: 37% (269/727) Writing objects: 38% (277/727) Writing objects: 39% (284/727) Writing objects: 40% (291/727) Writing objects: 41% (299/727) Writing objects: 42% (306/727) Writing objects: 43% (314/727) Writing objects: 44% (320/727) Writing objects: 45% (328/727) Writing objects: 46% (335/727) Writing objects: 47% (342/727) Writing objects: 48% (349/727) Writing objects: 49% (357/727) Writing objects: 50% (364/727) Writing objects: 51% (371/727) Writing objects: 52% (379/727) Writing objects: 53% (386/727) Writing objects: 54% (393/727) Writing objects: 55% (400/727) Writing objects: 56% (408/727) Writing objects: 57% (415/727) Writing objects: 58% (422/727) Writing objects: 59% (429/727) Writing objects: 60% (437/727) Writing objects: 61% (444/727) Writing objects: 62% (451/727) Writing objects: 63% (459/727) Writing objects: 64% (466/727) Writing objects: 65% (473/727) Writing objects: 66% (480/727) Writing objects: 67% (488/727) Writing objects: 68% (495/727) Writing objects: 69% (502/727) Writing objects: 70% (509/727) Writing objects: 71% (517/727) Writing objects: 72% (524/727) Writing objects: 73% (531/727) Writing objects: 74% (538/727) Writing objects: 75% (546/727) Writing objects: 76% (553/727) Writing objects: 77% (560/727) Writing objects: 78% (568/727) Writing objects: 79% (575/727) Writing objects: 80% (582/727) Writing objects: 81% (589/727) Writing objects: 82% (597/727) Writing objects: 83% (604/727) Writing objects: 84% (611/727) Writing objects: 85% (618/727) Writing objects: 86% (626/727) Writing objects: 87% (633/727) Writing objects: 88% (640/727) Writing objects: 89% (648/727) Writing objects: 90% (655/727) Writing objects: 91% (662/727) Writing objects: 92% (669/727) Writing objects: 93% (677/727) Writing objects: 94% (684/727) Writing objects: 95% (691/727) Writing objects: 96% (698/727) Writing objects: 97% (706/727) Writing objects: 98% (713/727) Writing objects: 99% (720/727) Writing objects: 100% (727/727) Writing objects: 100% (727/727), 126.51 KiB, done. Total 727 (delta 597), reused 702 (delta 572) To xen@xenbits.xensource.com:git/linux-pvops.git 0527fde..f1c84a5 f1c84a5cb52ee2915457b481c756fcc1dfe6a471 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:15:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17: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 ) id 1SPzcu-0005bj-4R; Thu, 03 May 2012 17:15:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzcs-0005bc-TF for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:15:35 +0000 Received: from [85.158.139.83:61562] by server-5.bemta-5.messagelabs.com id 4B/C5-13566-63DB2AF4; Thu, 03 May 2012 17:15:34 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336065332!19298903!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA4MjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5672 invoked from network); 3 May 2012 17:15:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:15:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HEiI3031816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:14:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43HEhnq000249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:14:44 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 q43HEf9f029307; Thu, 3 May 2012 12:14:42 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:14:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 180A94031D; Thu, 3 May 2012 13:08:59 -0400 (EDT) Date: Thu, 3 May 2012 13:08:58 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk Message-ID: <20120503170858.GC9992@phenom.dumpdata.com> References: <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120503154620.GB3464@andromeda.dapyr.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > Hmmm, so xen_apic_read is still correct... > > > > [ 0.000000] ACPI: Local APIC address 0xfee00000 > > [ 0.000000] xxx xen_apic_read(20) > > [ 0.000000] xxx xen_apic_read -> 10 > > [ 0.000000] boot_cpu_physical_apicid = 0 > > [ 0.000000] xxx xen_apic_read(30) > > [ 0.000000] +- apic version = 10 > > > > there seems to be a slightly strange tweak (at least for me) in read_apic_id... > > > > static inline unsigned int read_apic_id(void) > > { > > unsigned int reg; > > > > reg = apic_read(APIC_ID); // calls apic->read(reg) > > > > return apic->get_apic_id(reg); > > Duh!! Let me spin out a new patch that will do this. Meaning bit-shift it. We ended up doing 10 >> 24 (get_apic_id does that) which results in zero. So lets be a bit more cautious and over-write the get_apic_id and set_apic_id and as well do the proper bit-shifting. commit 4bb450ea9dca1b8d845f1b53ab6476615a32badf Author: Konrad Rzeszutek Wilk Date: Wed May 2 15:04:51 2012 -0400 xen/apic: Return the APIC ID (and version) for CPU 0. On x86_64 on AMD machines where the first APIC_ID is not zero, we get: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 which means that when the ACPI processor driver loads and tries to parse the _Pxx states it fails to do as, as it ends up calling acpi_get_cpuid which does this: for_each_possible_cpu(i) { if (cpu_physical_id(i) == apic_id) return i; } And the bootup CPU, has not been found so it fails and returns -1 for the first CPU - which then subsequently in the loop that "acpi_processor_get_info" does results in returning an error, which means that "acpi_processor_add" failing and per_cpu(processor) is never set (and is NULL). That means that when xen-acpi-processor tries to load (much much later on) and parse the P-states it gets -ENODEV from acpi_processor_register_performance() (which tries to read the per_cpu(processor)) and fails to parse the data. Reported-by: Stefan Bader Suggested-by: Boris Ostrovsky [v2: Bit-shift APIC ID by 24 bits] Signed-off-by: Konrad Rzeszutek Wilk diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..63d6c22 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -53,6 +53,9 @@ #include #include #include +#ifdef CONFIG_NUMA +#include +#endif #include #include #include @@ -809,9 +812,40 @@ static void xen_io_delay(void) } #ifdef CONFIG_X86_LOCAL_APIC +static unsigned long xen_set_apic_id(unsigned int x) +{ + WARN_ON(1); + return x; +} +static unsigned int xen_get_apic_id(unsigned long x) +{ + return (((x)>>24) & 0xFFu); +} static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id << 24; } static void xen_apic_write(u32 reg, u32 val) @@ -849,6 +883,8 @@ static void set_xen_basic_apic_ops(void) apic->icr_write = xen_apic_icr_write; apic->wait_icr_idle = xen_apic_wait_icr_idle; apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; + apic->set_apic_id = xen_set_apic_id; + apic->get_apic_id = xen_get_apic_id; } #endif @@ -1294,6 +1330,9 @@ asmlinkage void __init xen_start_kernel(void) */ acpi_numa = -1; #endif +#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32) + numa_off = 1; +#endif pgd = (pgd_t *)xen_start_info->pt_base; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:15:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17: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 ) id 1SPzcu-0005bj-4R; Thu, 03 May 2012 17:15:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzcs-0005bc-TF for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:15:35 +0000 Received: from [85.158.139.83:61562] by server-5.bemta-5.messagelabs.com id 4B/C5-13566-63DB2AF4; Thu, 03 May 2012 17:15:34 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336065332!19298903!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA4MjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5672 invoked from network); 3 May 2012 17:15:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:15:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HEiI3031816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:14:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43HEhnq000249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:14:44 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 q43HEf9f029307; Thu, 3 May 2012 12:14:42 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:14:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 180A94031D; Thu, 3 May 2012 13:08:59 -0400 (EDT) Date: Thu, 3 May 2012 13:08:58 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk Message-ID: <20120503170858.GC9992@phenom.dumpdata.com> References: <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120503154620.GB3464@andromeda.dapyr.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > Hmmm, so xen_apic_read is still correct... > > > > [ 0.000000] ACPI: Local APIC address 0xfee00000 > > [ 0.000000] xxx xen_apic_read(20) > > [ 0.000000] xxx xen_apic_read -> 10 > > [ 0.000000] boot_cpu_physical_apicid = 0 > > [ 0.000000] xxx xen_apic_read(30) > > [ 0.000000] +- apic version = 10 > > > > there seems to be a slightly strange tweak (at least for me) in read_apic_id... > > > > static inline unsigned int read_apic_id(void) > > { > > unsigned int reg; > > > > reg = apic_read(APIC_ID); // calls apic->read(reg) > > > > return apic->get_apic_id(reg); > > Duh!! Let me spin out a new patch that will do this. Meaning bit-shift it. We ended up doing 10 >> 24 (get_apic_id does that) which results in zero. So lets be a bit more cautious and over-write the get_apic_id and set_apic_id and as well do the proper bit-shifting. commit 4bb450ea9dca1b8d845f1b53ab6476615a32badf Author: Konrad Rzeszutek Wilk Date: Wed May 2 15:04:51 2012 -0400 xen/apic: Return the APIC ID (and version) for CPU 0. On x86_64 on AMD machines where the first APIC_ID is not zero, we get: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 which means that when the ACPI processor driver loads and tries to parse the _Pxx states it fails to do as, as it ends up calling acpi_get_cpuid which does this: for_each_possible_cpu(i) { if (cpu_physical_id(i) == apic_id) return i; } And the bootup CPU, has not been found so it fails and returns -1 for the first CPU - which then subsequently in the loop that "acpi_processor_get_info" does results in returning an error, which means that "acpi_processor_add" failing and per_cpu(processor) is never set (and is NULL). That means that when xen-acpi-processor tries to load (much much later on) and parse the P-states it gets -ENODEV from acpi_processor_register_performance() (which tries to read the per_cpu(processor)) and fails to parse the data. Reported-by: Stefan Bader Suggested-by: Boris Ostrovsky [v2: Bit-shift APIC ID by 24 bits] Signed-off-by: Konrad Rzeszutek Wilk diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..63d6c22 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -53,6 +53,9 @@ #include #include #include +#ifdef CONFIG_NUMA +#include +#endif #include #include #include @@ -809,9 +812,40 @@ static void xen_io_delay(void) } #ifdef CONFIG_X86_LOCAL_APIC +static unsigned long xen_set_apic_id(unsigned int x) +{ + WARN_ON(1); + return x; +} +static unsigned int xen_get_apic_id(unsigned long x) +{ + return (((x)>>24) & 0xFFu); +} static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id << 24; } static void xen_apic_write(u32 reg, u32 val) @@ -849,6 +883,8 @@ static void set_xen_basic_apic_ops(void) apic->icr_write = xen_apic_icr_write; apic->wait_icr_idle = xen_apic_wait_icr_idle; apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; + apic->set_apic_id = xen_set_apic_id; + apic->get_apic_id = xen_get_apic_id; } #endif @@ -1294,6 +1330,9 @@ asmlinkage void __init xen_start_kernel(void) */ acpi_numa = -1; #endif +#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32) + numa_off = 1; +#endif pgd = (pgd_t *)xen_start_info->pt_base; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:28:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17: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 ) id 1SPzow-0005oL-Dx; Thu, 03 May 2012 17:28:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzou-0005oG-Kg for xen-devel@lists.xen.org; Thu, 03 May 2012 17:28:00 +0000 Received: from [85.158.143.99:53034] by server-1.bemta-4.messagelabs.com id A3/67-20925-020C2AF4; Thu, 03 May 2012 17:28:00 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336066077!16754083!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15409 invoked from network); 3 May 2012 17:27:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:27:59 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HRtLK028709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:27:55 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 q43HRri1023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:27:54 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 q43HRrRp017890; Thu, 3 May 2012 12:27:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:27:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D71854031D; Thu, 3 May 2012 13:22:11 -0400 (EDT) Date: Thu, 3 May 2012 13:22:11 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120503172211.GE9992@phenom.dumpdata.com> References: <4FA2C94802000078000816E3@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA2C94802000078000816E3@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel Subject: Re: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:07:04PM +0100, Jan Beulich wrote: > Both Linux and Xen offer only ways to set the IOPL. While on native Linux > this is not a problem since user mode code can read the IOPL by inspecting > EFLAGS, on Xen this would always yield zero. > > Now X folks appear to be using save-modify-restore cycles in some newer > code, and this obviously breaks under Xen, as they would restore IOPL 0 This is in the KMS drivers or in the user-land Xorg? > even when IOPL 3 was in effect before. > > Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. > XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add > e.g. a "get" counterpart to PHYSDEVOP_set_iopl. > > Or am I overlooking some other access mechanism? > > Jan > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:28:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17: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 ) id 1SPzow-0005oL-Dx; Thu, 03 May 2012 17:28:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzou-0005oG-Kg for xen-devel@lists.xen.org; Thu, 03 May 2012 17:28:00 +0000 Received: from [85.158.143.99:53034] by server-1.bemta-4.messagelabs.com id A3/67-20925-020C2AF4; Thu, 03 May 2012 17:28:00 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336066077!16754083!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15409 invoked from network); 3 May 2012 17:27:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:27:59 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HRtLK028709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:27:55 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 q43HRri1023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:27:54 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 q43HRrRp017890; Thu, 3 May 2012 12:27:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:27:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D71854031D; Thu, 3 May 2012 13:22:11 -0400 (EDT) Date: Thu, 3 May 2012 13:22:11 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120503172211.GE9992@phenom.dumpdata.com> References: <4FA2C94802000078000816E3@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA2C94802000078000816E3@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel Subject: Re: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:07:04PM +0100, Jan Beulich wrote: > Both Linux and Xen offer only ways to set the IOPL. While on native Linux > this is not a problem since user mode code can read the IOPL by inspecting > EFLAGS, on Xen this would always yield zero. > > Now X folks appear to be using save-modify-restore cycles in some newer > code, and this obviously breaks under Xen, as they would restore IOPL 0 This is in the KMS drivers or in the user-land Xorg? > even when IOPL 3 was in effect before. > > Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. > XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add > e.g. a "get" counterpart to PHYSDEVOP_set_iopl. > > Or am I overlooking some other access mechanism? > > Jan > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:30:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17:30:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzr5-0005tE-VY; Thu, 03 May 2012 17:30:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzr4-0005t6-Hi for xen-devel@lists.xen.org; Thu, 03 May 2012 17:30:14 +0000 Received: from [85.158.139.83:10278] by server-4.bemta-5.messagelabs.com id 7F/FD-10788-5A0C2AF4; Thu, 03 May 2012 17:30:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336066211!26571604!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28893 invoked from network); 3 May 2012 17:30:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:30:12 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HU85V031096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:30:09 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 q43HU8E5026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:30:08 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 q43HU8ot008536; Thu, 3 May 2012 12:30:08 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:30:08 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7422E4031D; Thu, 3 May 2012 13:24:26 -0400 (EDT) Date: Thu, 3 May 2012 13:24:26 -0400 From: Konrad Rzeszutek Wilk To: Sam Mulvey Message-ID: <20120503172426.GF9992@phenom.dumpdata.com> References: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: great.potato@gmail.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 08:37:16AM -0700, Sam Mulvey wrote: > > Hey folks... > > This is with the same packages and such that I've been work on with Arch, and I encountered an odd crash. If I need to move this thread to Xen-users or whatnot, apologies and please let me know. > > The packages that I've been working with functioned great in the desktop VM, and worked wonderfully in PV and HVM on my test hardware (an HP server with Intel Xeons), but crashes right out of the gate on my production server (Tyan motherboard with Opteron 8356s). When I move the kernel back to a 2.6.32.18 pvops kernel I had been using, I can boot and run VMs without trouble. > > Incidentally, I can now boot as many VMs as I like as long as the memory holds out, so the initial trouble that got all of this started looks like it's been fixed. > > > Everything looks normal until Xen hands off to the kernel, then I get this: This looks like an E820 alignment issue. Can you provide the full serial output please. > > [ 0.000000] Cannot find 20480 bytes in node 1 > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 0.000000] IP: [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] PGD 0 > [ 0.000000] Oops: 0000 [#1] PREEMPT SMP > [ 0.000000] CPU 0 > [ 0.000000] Modules linked in: > [ 0.000000] > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.3.4-1-ARCH #1 empty empty/S3992 > [ 0.000000] RIP: e030:[] [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] RSP: e02b:ffffffff81801de8 EFLAGS: 00010046 > [ 0.000000] RAX: 0000000000000000 RBX: 0000000000000378 RCX: 0000000000000000 > [ 0.000000] RDX: 0000000000000040 RSI: 0000000000000378 RDI: 0000000000000000 > [ 0.000000] RBP: ffffffff81801e08 R08: 0000000000000000 R09: ffffffff81801d98 > [ 0.000000] R10: ffffffff81801d88 R11: ffffffff81801d90 R12: 0000000000000040 > [ 0.000000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 > [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff8189f000(0000) knlGS:0000000000000000 > [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.000000] CR2: 0000000000000000 CR3: 0000000001805000 CR4: 0000000000000660 > [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 > [ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81800000, task ffffffff8180d020) > [ 0.000000] Stack: > [ 0.000000] 0000000000080000 0000000000000378 000000000000003c ffff88003fbfa000 > [ 0.000000] ffffffff81801e68 ffffffff818d63f0 ffffffff81801e48 00000001818d53bc > [ 0.000000] ffff88003fbf9fe0 0000000000000000 000000000282c000 ffff88003fbfa000 > [ 0.000000] Call Trace: > [ 0.000000] [] sparse_early_usemaps_alloc_node+0x63/0x1c4 > [ 0.000000] [] sparse_init+0xf8/0x2c8 > [ 0.000000] [] paging_init+0x13/0x22 > [ 0.000000] [] setup_arch+0x9f2/0xac0 > [ 0.000000] [] ? printk+0x41/0x43 > [ 0.000000] [] start_kernel+0xd4/0x3d1 > [ 0.000000] [] x86_64_start_reservations+0x131/0x135 > [ 0.000000] [] xen_start_kernel+0x598/0x59f > [ 0.000000] Code: 4c 89 e9 4c 89 e2 48 89 de bf 40 00 00 00 e8 0f fc ff ff eb 34 41 8b 96 a0 40 00 00 be 00 80 00 00 48 89 d > [ 0.000000] RIP [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] RSP > [ 0.000000] CR2: 0000000000000000 > [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > (XEN) Domain 0 crashed: rebooting machine in 5 seconds. > > ---- > > This is the same kernel I've been using in the two testing machines. The server is, incidentally, the same server that houses the mail server I'm on, so I'm cc'ing a gmail address, if you could include it in your replies, I'd appreciate it. > > Thanks! > > -- > Sam Mulvey > Tacoma Telematics > sam@tacomatelematics.com > (253) 883-3030 x110 > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 17:30:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 17:30:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzr5-0005tE-VY; Thu, 03 May 2012 17:30:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPzr4-0005t6-Hi for xen-devel@lists.xen.org; Thu, 03 May 2012 17:30:14 +0000 Received: from [85.158.139.83:10278] by server-4.bemta-5.messagelabs.com id 7F/FD-10788-5A0C2AF4; Thu, 03 May 2012 17:30:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336066211!26571604!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28893 invoked from network); 3 May 2012 17:30:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 17:30:12 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43HU85V031096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 17:30:09 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 q43HU8E5026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 17:30:08 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 q43HU8ot008536; Thu, 3 May 2012 12:30:08 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 10:30:08 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7422E4031D; Thu, 3 May 2012 13:24:26 -0400 (EDT) Date: Thu, 3 May 2012 13:24:26 -0400 From: Konrad Rzeszutek Wilk To: Sam Mulvey Message-ID: <20120503172426.GF9992@phenom.dumpdata.com> References: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: great.potato@gmail.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 08:37:16AM -0700, Sam Mulvey wrote: > > Hey folks... > > This is with the same packages and such that I've been work on with Arch, and I encountered an odd crash. If I need to move this thread to Xen-users or whatnot, apologies and please let me know. > > The packages that I've been working with functioned great in the desktop VM, and worked wonderfully in PV and HVM on my test hardware (an HP server with Intel Xeons), but crashes right out of the gate on my production server (Tyan motherboard with Opteron 8356s). When I move the kernel back to a 2.6.32.18 pvops kernel I had been using, I can boot and run VMs without trouble. > > Incidentally, I can now boot as many VMs as I like as long as the memory holds out, so the initial trouble that got all of this started looks like it's been fixed. > > > Everything looks normal until Xen hands off to the kernel, then I get this: This looks like an E820 alignment issue. Can you provide the full serial output please. > > [ 0.000000] Cannot find 20480 bytes in node 1 > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 0.000000] IP: [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] PGD 0 > [ 0.000000] Oops: 0000 [#1] PREEMPT SMP > [ 0.000000] CPU 0 > [ 0.000000] Modules linked in: > [ 0.000000] > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.3.4-1-ARCH #1 empty empty/S3992 > [ 0.000000] RIP: e030:[] [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] RSP: e02b:ffffffff81801de8 EFLAGS: 00010046 > [ 0.000000] RAX: 0000000000000000 RBX: 0000000000000378 RCX: 0000000000000000 > [ 0.000000] RDX: 0000000000000040 RSI: 0000000000000378 RDI: 0000000000000000 > [ 0.000000] RBP: ffffffff81801e08 R08: 0000000000000000 R09: ffffffff81801d98 > [ 0.000000] R10: ffffffff81801d88 R11: ffffffff81801d90 R12: 0000000000000040 > [ 0.000000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 > [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff8189f000(0000) knlGS:0000000000000000 > [ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.000000] CR2: 0000000000000000 CR3: 0000000001805000 CR4: 0000000000000660 > [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 > [ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81800000, task ffffffff8180d020) > [ 0.000000] Stack: > [ 0.000000] 0000000000080000 0000000000000378 000000000000003c ffff88003fbfa000 > [ 0.000000] ffffffff81801e68 ffffffff818d63f0 ffffffff81801e48 00000001818d53bc > [ 0.000000] ffff88003fbf9fe0 0000000000000000 000000000282c000 ffff88003fbfa000 > [ 0.000000] Call Trace: > [ 0.000000] [] sparse_early_usemaps_alloc_node+0x63/0x1c4 > [ 0.000000] [] sparse_init+0xf8/0x2c8 > [ 0.000000] [] paging_init+0x13/0x22 > [ 0.000000] [] setup_arch+0x9f2/0xac0 > [ 0.000000] [] ? printk+0x41/0x43 > [ 0.000000] [] start_kernel+0xd4/0x3d1 > [ 0.000000] [] x86_64_start_reservations+0x131/0x135 > [ 0.000000] [] xen_start_kernel+0x598/0x59f > [ 0.000000] Code: 4c 89 e9 4c 89 e2 48 89 de bf 40 00 00 00 e8 0f fc ff ff eb 34 41 8b 96 a0 40 00 00 be 00 80 00 00 48 89 d > [ 0.000000] RIP [] __alloc_bootmem_node+0x72/0x99 > [ 0.000000] RSP > [ 0.000000] CR2: 0000000000000000 > [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > (XEN) Domain 0 crashed: rebooting machine in 5 seconds. > > ---- > > This is the same kernel I've been using in the two testing machines. The server is, incidentally, the same server that houses the mail server I'm on, so I'm cc'ing a gmail address, if you could include it in your replies, I'd appreciate it. > > Thanks! > > -- > Sam Mulvey > Tacoma Telematics > sam@tacomatelematics.com > (253) 883-3030 x110 > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:02:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18:02:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0M1-0006IO-Or; Thu, 03 May 2012 18:02:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0M0-0006IG-8H for xen-devel@lists.xen.org; Thu, 03 May 2012 18:02:12 +0000 Received: from [85.158.143.35:5141] by server-3.bemta-4.messagelabs.com id DA/C9-05853-328C2AF4; Thu, 03 May 2012 18:02:11 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336068128!7454152!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9329 invoked from network); 3 May 2012 18:02:09 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 18:02:09 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id EE19A10211FC6; Thu, 3 May 2012 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t03I563Yfjwt; Thu, 3 May 2012 10:49:57 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id 8DDAF10211FC2; Thu, 3 May 2012 10:49:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: <20120503172426.GF9992@phenom.dumpdata.com> Date: Thu, 3 May 2012 11:02:02 -0700 Message-Id: <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> References: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen-devel@lists.xen.org, great.potato@gmail.com Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ck9uIE1heSAzLCAyMDEyLCBhdCAxMDoyNCBBTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3Rl Ogo+IAo+IFRoaXMgbG9va3MgbGlrZSBhbiBFODIwIGFsaWdubWVudCBpc3N1ZS4gQ2FuIHlvdSBw cm92aWRlIHRoZSBmdWxsIHNlcmlhbCBvdXRwdXQgcGxlYXNlLgoKQ29taW5nIHJpZ2h0IHVwIQoK X18gIF9fICAgICAgICAgICAgXyAgXyAgICBfICAgX19fXyAgCiBcIFwvIC9fX18gXyBfXyAgIHwg fHwgfCAgLyB8IHxfX18gXCAKICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8XyB8IHwgICBfXykgfAog IC8gIFwgIF9fLyB8IHwgfCB8X18gICBffHwgfF8gLyBfXy8gCiAvXy9cX1xfX198X3wgfF98ICAg IHxffChfKV8oXylfX19fX3wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoo WEVOKSBYZW4gdmVyc2lvbiA0LjEuMiAoc2FtQGxvY2FsZG9tYWluKSAoZ2NjIHZlcnNpb24gNC43 LjAgMjAxMjA0MTQgKHByZXJlbGVhc2UpIChHQ0MpICkgV2VkIE1heSAgMiAxOTo1MToyMSBQRFQg MjAxMgooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiB1bmF2YWlsYWJsZQooWEVOKSBCb290bG9hZGVy OiBHTlUgR1JVQiAwLjk3CihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MUcgbG9nbHZsPWFs bCBndWVzdF9sb2dsdmw9YWxsIGNvbTE9MTE1MjAwLDhuMSBjb25zb2xlPWNvbTEKKFhFTikgVmlk ZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYK KFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMiBzZWNvbmRz CihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAzIE1CUiBzaWduYXR1cmVzCihY RU4pICBGb3VuZCAzIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJB TSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZDAwMCAodXNhYmxl KQooWEVOKSAgMDAwMDAwMDAwMDA5ZDAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQoo WEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVO KSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwYmZmZjAwMDAgKHVzYWJsZSkKKFhFTikgIDAw MDAwMDAwYmZmZjAwMDAgLSAwMDAwMDAwMGJmZmZlMDAwIChBQ1BJIGRhdGEpCihYRU4pICAwMDAw MDAwMGJmZmZlMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAw MGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMzAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZl ZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMTAwMDAw MDAwIC0gMDAwMDAwMDM4MDAwMDAwMCAodXNhYmxlKQooWEVOKSBBQ1BJOiBSU0RQIDAwMEY4M0Mw LCAwMDI0IChyMiBBQ1BJQU0pCihYRU4pIEFDUEk6IFhTRFQgQkZGRjAxMDAsIDAwNEMgKHIxIDA3 MTAwOCBYU0RUMDk0OCAyMDA4MDcxMCBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBGQUNQIEJG RkYwMjkwLCAwMEY0IChyMyAwNzEwMDggRkFDUDA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykK KFhFTikgQUNQSTogRFNEVCBCRkZGMDRBMCwgM0I2OCAocjEgIDBBQUFBIDBBQUFBMDAwICAgICAg ICAwIElOVEwgIDIwMDIwMjYpCihYRU4pIEFDUEk6IEZBQ1MgQkZGRkUwMDAsIDAwNDAKKFhFTikg QUNQSTogQVBJQyBCRkZGMDM5MCwgMDBDQSAocjEgMDcxMDA4IEFQSUMwOTQ4IDIwMDgwNzEwIE1T RlQgICAgICAgOTcpCihYRU4pIEFDUEk6IE1DRkcgQkZGRjA0NjAsIDAwM0MgKHIxIDA3MTAwOCBP RU1NQ0ZHICAyMDA4MDcxMCBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBPRU1CIEJGRkZFMDQw LCAwMDU2IChyMSAwNzEwMDggT0VNQjA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykKKFhFTikg QUNQSTogU1JBVCBCRkZGNDAxMCwgMDE1MCAocjEgQU1EICAgIEhBTU1FUiAgICAgICAgICAxIEFN RCAgICAgICAgIDEpCihYRU4pIFN5c3RlbSBSQU06IDEzMzExTUIgKDEzNjMxMDI4a0IpCihYRU4p IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJ QyAxIC0+IE5vZGUgMAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwCihYRU4p IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJ QyA0IC0+IE5vZGUgMQooWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElDIDUgLT4gTm9kZSAxCihYRU4p IFNSQVQ6IFBYTSAxIC0+IEFQSUMgNiAtPiBOb2RlIDEKKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJ QyA3IC0+IE5vZGUgMQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1hMDAwMAooWEVOKSBTUkFU OiBOb2RlIDAgUFhNIDAgMTAwMDAwLWMwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAx MDAwMDAwMDAtMWUwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMSBQWE0gMSAxZTAwMDAwMDAtMzgw MDAwMDAwCihYRU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMzdlNWY1MDAwIC0g MzdlNWY5MDAwCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0LgooWEVOKSBE b21haW4gaGVhcCBpbml0aWFsaXNlZCBETUEgd2lkdGggMzAgYml0cwooWEVOKSBmb3VuZCBTTVAg TVAtdGFibGUgYXQgMDAwZmY3ODAKKFhFTikgRE1JIDIuMyBwcmVzZW50LgooWEVOKSBVc2luZyBB UElDIGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4NTA4CihY RU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0xeF9jbnRbNTQ0LDUwNF0sIHBtMXhfZXZ0WzU0 MCw1MDBdCihYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tiZmZmZTAwY10s IHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAoo WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQoo WEVOKSBQcm9jZXNzb3IgIzAgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEg MDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp Y19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgMDoyIEFQSUMgdmVyc2lvbiAx NgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVk KQooWEVOKSBQcm9jZXNzb3IgIzMgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3Ig IzQgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBs YXBpY19pZFsweDA1XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgMDoyIEFQSUMgdmVyc2lv biAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDA2XSBlbmFi bGVkKQooWEVOKSBQcm9jZXNzb3IgIzYgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBM QVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDA3XSBlbmFibGVkKQooWEVOKSBQcm9jZXNz b3IgIzcgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRb MHgwMV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk WzB4MDJdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlf aWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3Bp X2lkWzB4MDVdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNw aV9pZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFj cGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDhdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb MHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBh cGljX2lkIDgsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMTUKKFhFTikg QUNQSTogSU9BUElDIChpZFsweDA5XSBhZGRyZXNzWzB4ZmVjMDEwMDBdIGdzaV9iYXNlWzE2XSkK KFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMTAw MCwgR1NJIDE2LTMxCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwYV0gYWRkcmVzc1sweGZlYzAy MDAwXSBnc2lfYmFzZVszMl0pCihYRU4pIElPQVBJQ1syXTogYXBpY19pZCAxMCwgdmVyc2lvbiAx NywgYWRkcmVzcyAweGZlYzAyMDAwLCBHU0kgMzItNDcKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIg KGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSVJRMCB1 c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4p IEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAzIEkvTyBBUElDcwooWEVOKSBQQ0k6 IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21lbnQgMCBidXNlcyAwIC0g MjU1CihYRU4pIFBDSTogTm90IHVzaW5nIE1NQ09ORklHLgooWEVOKSBUYWJsZSBpcyBub3QgZm91 bmQhCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbgooWEVOKSBJUlEgbGltaXRzOiA0OCBHU0ksIDE1MDQgTVNJL01TSS1YCihYRU4pIFVzaW5n IHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQg MjI5NC4zMDggTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhF TikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIEFNRC1W aTogSU9NTVUgbm90IGZvdW5kIQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZGlzYWJsZWQKKFhF TikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZAoo WEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x CihYRU4pIFBsYXRmb3JtIHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBl ZCAxMCBvciBtb3JlIHRpbWVzLgooWEVOKSBQbGF0Zm9ybSB0aW1lciBpcyAzLjU3OU1IeiBBQ1BJ IFBNIFRpbWVyCsuHKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4p IEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVy ZXM6CihYRU4pICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSAgLSBMYXN0IEJyYW5j aCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KKFhFTikgSFZNOiBTVk0gZW5hYmxlZAooWEVO KSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyBkZXRlY3RlZC4KKFhFTikgQnJvdWdodCB1 cCA4IENQVXMKKFhFTikgQ1BVSURMRTogZGlzYWJsZWQgZHVlIHRvIG5vIEhQRVQuIEZvcmNlIGVu YWJsZSB3aXRoICdjcHVpZGxlJy4KKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgTUNB OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBt Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCihYRU4pICoq KiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBj b21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAw MDAwMCAtPiAweDFlYjgwMDAKKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVO KSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDM3MDAwMDAwMC0+MDAwMDAwMDM3NDAwMDAwMCAoMjQz MzQwIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAz N2Y2OGMwMDAtPjAwMDAwMDAzN2ZmZmZlMDAKKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1F TlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgxZWI4 MDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgxZWI4MDAwLT5mZmZmZmZmZjgyODJi ZTAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyODJjMDAwLT5mZmZmZmZmZjgyYTJj MDAwCihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgyYTJjMDAwLT5mZmZmZmZmZjgyYTJj NGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgyYTJkMDAwLT5mZmZmZmZmZjgyYTQ2 MDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyYTQ2MDAwLT5mZmZmZmZmZjgyYTQ3 MDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgyYzAw MDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxOGI0MjAwCihYRU4pIERvbTAgaGFz IG1heGltdW0gOCBWQ1BVcwooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4K KFhFTikgWGVuIHRyYWNlIGJ1ZmZlcnM6IGRpc2FibGVkCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs bAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVO KSBGcmVlZCAyMjhrQiBpbml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBt ZW1vcnkKWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQgc3RhcnRlZC4u LgpbICAgIDAuMDAwMDAwXSBDYW5ub3QgZmluZCAyMDQ4MCBieXRlcyBpbiBub2RlIDEKWyAgICAw LjAwMDAwMF0gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZl cmVuY2UgYXQgICAgICAgICAgIChudWxsKQpbICAgIDAuMDAwMDAwXSBJUDogWzxmZmZmZmZmZjgx OGQ1NzA0Pl0gX19hbGxvY19ib290bWVtX25vZGUrMHg3Mi8weDk5ClsgICAgMC4wMDAwMDBdIFBH RCAwIApbICAgIDAuMDAwMDAwXSBPb3BzOiAwMDAwIFsjMV0gUFJFRU1QVCBTTVAgClsgICAgMC4w MDAwMDBdIENQVSAwIApbICAgIDAuMDAwMDAwXSBNb2R1bGVzIGxpbmtlZCBpbjoKWyAgICAwLjAw MDAwMF0gClsgICAgMC4wMDAwMDBdIFBpZDogMCwgY29tbTogc3dhcHBlciBOb3QgdGFpbnRlZCAz LjMuNC0yLUFSQ0ggIzEgZW1wdHkgZW1wdHkvUzM5OTIKWyAgICAwLjAwMDAwMF0gUklQOiBlMDMw Ols8ZmZmZmZmZmY4MThkNTcwND5dICBbPGZmZmZmZmZmODE4ZDU3MDQ+XSBfX2FsbG9jX2Jvb3Rt ZW1fbm9kZSsweDcyLzB4OTkKWyAgICAwLjAwMDAwMF0gUlNQOiBlMDJiOmZmZmZmZmZmODE4MDFk ZTggIEVGTEFHUzogMDAwMTAwNDYKWyAgICAwLjAwMDAwMF0gUkFYOiAwMDAwMDAwMDAwMDAwMDAw IFJCWDogMDAwMDAwMDAwMDAwMDM3OCBSQ1g6IDAwMDAwMDAwMDAwMDAwMDAKWyAgICAwLjAwMDAw MF0gUkRYOiAwMDAwMDAwMDAwMDAwMDQwIFJTSTogMDAwMDAwMDAwMDAwMDM3OCBSREk6IDAwMDAw MDAwMDAwMDAwMDAKWyAgICAwLjAwMDAwMF0gUkJQOiBmZmZmZmZmZjgxODAxZTA4IFIwODogMDAw MDAwMDAwMDAwMDAwMCBSMDk6IGZmZmZmZmZmODE4MDFkOTgKWyAgICAwLjAwMDAwMF0gUjEwOiBm ZmZmZmZmZjgxODAxZDg4IFIxMTogZmZmZmZmZmY4MTgwMWQ5MCBSMTI6IDAwMDAwMDAwMDAwMDAw NDAKWyAgICAwLjAwMDAwMF0gUjEzOiAwMDAwMDAwMDAwMDAwMDAwIFIxNDogMDAwMDAwMDAwMDAw MDAwMCBSMTU6IDAwMDAwMDAwMDAwMDAwMDEKWyAgICAwLjAwMDAwMF0gRlM6ICAwMDAwMDAwMDAw MDAwMDAwKDAwMDApIEdTOmZmZmZmZmZmODE4OWYwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAw MDAwMApbICAgIDAuMDAwMDAwXSBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAw MDAwMDgwMDUwMDMzClsgICAgMC4wMDAwMDBdIENSMjogMDAwMDAwMDAwMDAwMDAwMCBDUjM6IDAw MDAwMDAwMDE4MDUwMDAgQ1I0OiAwMDAwMDAwMDAwMDAwNjYwClsgICAgMC4wMDAwMDBdIERSMDog MDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAw MDAwClsgICAgMC4wMDAwMDBdIERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6IDAwMDAwMDAwMDAw MDAwMDAgRFI3OiAwMDAwMDAwMDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIFByb2Nlc3Mgc3dhcHBl ciAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE4MDAwMDAsIHRhc2sgZmZmZmZmZmY4MTgw ZDAyMCkKWyAgICAwLjAwMDAwMF0gU3RhY2s6ClsgICAgMC4wMDAwMDBdICAwMDAwMDAwMDAwMDgw MDAwIDAwMDAwMDAwMDAwMDAzNzggMDAwMDAwMDAwMDAwMDAzYyBmZmZmODgwMDNmYmZhMDAwClsg ICAgMC4wMDAwMDBdICBmZmZmZmZmZjgxODAxZTY4IGZmZmZmZmZmODE4ZDYzZjAgZmZmZmZmZmY4 MTgwMWU0OCAwMDAwMDAwMTgxOGQ1M2JjClsgICAgMC4wMDAwMDBdICBmZmZmODgwMDNmYmY5ZmUw IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMjgyYzAwMCBmZmZmODgwMDNmYmZhMDAwClsgICAg MC4wMDAwMDBdIENhbGwgVHJhY2U6ClsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE4ZDYzZjA+ XSBzcGFyc2VfZWFybHlfdXNlbWFwc19hbGxvY19ub2RlKzB4NjMvMHgxYzQKWyAgICAwLjAwMDAw MF0gIFs8ZmZmZmZmZmY4MThkNjc3Yj5dIHNwYXJzZV9pbml0KzB4ZjgvMHgyYzgKWyAgICAwLjAw MDAwMF0gIFs8ZmZmZmZmZmY4MThjYTRkMj5dIHBhZ2luZ19pbml0KzB4MTMvMHgyMgpbICAgIDAu MDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI5ZGNhPl0gc2V0dXBfYXJjaCsweDlmMi8weGFjMApbICAg IDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxNDU2MmQyPl0gPyBwcmludGsrMHg0MS8weDQzClsgICAg MC4wMDAwMDBdICBbPGZmZmZmZmZmODE4YjQ5MWI+XSBzdGFydF9rZXJuZWwrMHhkNC8weDNkMQpb ICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0MzQ2Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0 aW9ucysweDEzMS8weDEzNQpbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI2OWM5Pl0geGVu X3N0YXJ0X2tlcm5lbCsweDU5OC8weDU5ZgpbICAgIDAuMDAwMDAwXSBDb2RlOiA0YyA4OSBlOSA0 YyA4OSBlMiA0OCA4OSBkZSBiZiA0MCAwMCAwMCAwMCBlOCAwZiBmYyBmZiBmZiBlYiAzNCA0MSA4 YiA5NiBhMCA0MCAwMCAwMCBiZSAwMCA4MCAwMCAwMCA0OCA4OSBkZiBlOCAxZSAxMSA4OCBmZiBl YiAxZSA8NDE+IDhiIGJlIGEwIDQwIDAwIDAwIDQ5IDgzIGM4IGZmIDRjIDg5IGU5IDRjIDg5IGUy IDQ4IDg5IGRlIGU4IApbICAgIDAuMDAwMDAwXSBSSVAgIFs8ZmZmZmZmZmY4MThkNTcwND5dIF9f YWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5OQpbICAgIDAuMDAwMDAwXSAgUlNQIDxmZmZmZmZm ZjgxODAxZGU4PgpbICAgIDAuMDAwMDAwXSBDUjI6IDAwMDAwMDAwMDAwMDAwMDAKWyAgICAwLjAw MDAwMF0gLS0tWyBlbmQgdHJhY2UgYTc5MTllN2YxN2MwYTcyNSBdLS0tClsgICAgMC4wMDAwMDBd IEtlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBBdHRlbXB0ZWQgdG8ga2lsbCB0aGUgaWRsZSB0 YXNrIQooWEVOKSBEb21haW4gMCBjcmFzaGVkOiByZWJvb3RpbmcgbWFjaGluZSBpbiA1IHNlY29u ZHMuCgoKVGhhbmtzIQoKCi0tIApTYW0gTXVsdmV5ClRhY29tYSBUZWxlbWF0aWNzCnNhbUB0YWNv bWF0ZWxlbWF0aWNzLmNvbQooMjUzKSA4ODMtMzAzMCB4MTEwCgoKCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 03 18:02:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18:02:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0M1-0006IO-Or; Thu, 03 May 2012 18:02:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0M0-0006IG-8H for xen-devel@lists.xen.org; Thu, 03 May 2012 18:02:12 +0000 Received: from [85.158.143.35:5141] by server-3.bemta-4.messagelabs.com id DA/C9-05853-328C2AF4; Thu, 03 May 2012 18:02:11 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336068128!7454152!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9329 invoked from network); 3 May 2012 18:02:09 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 18:02:09 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id EE19A10211FC6; Thu, 3 May 2012 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t03I563Yfjwt; Thu, 3 May 2012 10:49:57 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id 8DDAF10211FC2; Thu, 3 May 2012 10:49:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: <20120503172426.GF9992@phenom.dumpdata.com> Date: Thu, 3 May 2012 11:02:02 -0700 Message-Id: <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> References: <9AE360C4-B0F2-4672-9C5D-CF9CD1E1C4AA@tacomatelematics.com> <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen-devel@lists.xen.org, great.potato@gmail.com Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ck9uIE1heSAzLCAyMDEyLCBhdCAxMDoyNCBBTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3Rl Ogo+IAo+IFRoaXMgbG9va3MgbGlrZSBhbiBFODIwIGFsaWdubWVudCBpc3N1ZS4gQ2FuIHlvdSBw cm92aWRlIHRoZSBmdWxsIHNlcmlhbCBvdXRwdXQgcGxlYXNlLgoKQ29taW5nIHJpZ2h0IHVwIQoK X18gIF9fICAgICAgICAgICAgXyAgXyAgICBfICAgX19fXyAgCiBcIFwvIC9fX18gXyBfXyAgIHwg fHwgfCAgLyB8IHxfX18gXCAKICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8XyB8IHwgICBfXykgfAog IC8gIFwgIF9fLyB8IHwgfCB8X18gICBffHwgfF8gLyBfXy8gCiAvXy9cX1xfX198X3wgfF98ICAg IHxffChfKV8oXylfX19fX3wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoo WEVOKSBYZW4gdmVyc2lvbiA0LjEuMiAoc2FtQGxvY2FsZG9tYWluKSAoZ2NjIHZlcnNpb24gNC43 LjAgMjAxMjA0MTQgKHByZXJlbGVhc2UpIChHQ0MpICkgV2VkIE1heSAgMiAxOTo1MToyMSBQRFQg MjAxMgooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiB1bmF2YWlsYWJsZQooWEVOKSBCb290bG9hZGVy OiBHTlUgR1JVQiAwLjk3CihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MUcgbG9nbHZsPWFs bCBndWVzdF9sb2dsdmw9YWxsIGNvbTE9MTE1MjAwLDhuMSBjb25zb2xlPWNvbTEKKFhFTikgVmlk ZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250IDh4MTYK KFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMiBzZWNvbmRz CihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAzIE1CUiBzaWduYXR1cmVzCihY RU4pICBGb3VuZCAzIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1lODIwIFJB TSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZDAwMCAodXNhYmxl KQooWEVOKSAgMDAwMDAwMDAwMDA5ZDAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQoo WEVOKSAgMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQooWEVO KSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwYmZmZjAwMDAgKHVzYWJsZSkKKFhFTikgIDAw MDAwMDAwYmZmZjAwMDAgLSAwMDAwMDAwMGJmZmZlMDAwIChBQ1BJIGRhdGEpCihYRU4pICAwMDAw MDAwMGJmZmZlMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAoQUNQSSBOVlMpCihYRU4pICAwMDAwMDAw MGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMzAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZl ZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMTAwMDAw MDAwIC0gMDAwMDAwMDM4MDAwMDAwMCAodXNhYmxlKQooWEVOKSBBQ1BJOiBSU0RQIDAwMEY4M0Mw LCAwMDI0IChyMiBBQ1BJQU0pCihYRU4pIEFDUEk6IFhTRFQgQkZGRjAxMDAsIDAwNEMgKHIxIDA3 MTAwOCBYU0RUMDk0OCAyMDA4MDcxMCBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBGQUNQIEJG RkYwMjkwLCAwMEY0IChyMyAwNzEwMDggRkFDUDA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykK KFhFTikgQUNQSTogRFNEVCBCRkZGMDRBMCwgM0I2OCAocjEgIDBBQUFBIDBBQUFBMDAwICAgICAg ICAwIElOVEwgIDIwMDIwMjYpCihYRU4pIEFDUEk6IEZBQ1MgQkZGRkUwMDAsIDAwNDAKKFhFTikg QUNQSTogQVBJQyBCRkZGMDM5MCwgMDBDQSAocjEgMDcxMDA4IEFQSUMwOTQ4IDIwMDgwNzEwIE1T RlQgICAgICAgOTcpCihYRU4pIEFDUEk6IE1DRkcgQkZGRjA0NjAsIDAwM0MgKHIxIDA3MTAwOCBP RU1NQ0ZHICAyMDA4MDcxMCBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBPRU1CIEJGRkZFMDQw LCAwMDU2IChyMSAwNzEwMDggT0VNQjA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykKKFhFTikg QUNQSTogU1JBVCBCRkZGNDAxMCwgMDE1MCAocjEgQU1EICAgIEhBTU1FUiAgICAgICAgICAxIEFN RCAgICAgICAgIDEpCihYRU4pIFN5c3RlbSBSQU06IDEzMzExTUIgKDEzNjMxMDI4a0IpCihYRU4p IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJ QyAxIC0+IE5vZGUgMAooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwCihYRU4p IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJ QyA0IC0+IE5vZGUgMQooWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElDIDUgLT4gTm9kZSAxCihYRU4p IFNSQVQ6IFBYTSAxIC0+IEFQSUMgNiAtPiBOb2RlIDEKKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJ QyA3IC0+IE5vZGUgMQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1hMDAwMAooWEVOKSBTUkFU OiBOb2RlIDAgUFhNIDAgMTAwMDAwLWMwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAx MDAwMDAwMDAtMWUwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMSBQWE0gMSAxZTAwMDAwMDAtMzgw MDAwMDAwCihYRU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMzdlNWY1MDAwIC0g MzdlNWY5MDAwCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0LgooWEVOKSBE b21haW4gaGVhcCBpbml0aWFsaXNlZCBETUEgd2lkdGggMzAgYml0cwooWEVOKSBmb3VuZCBTTVAg TVAtdGFibGUgYXQgMDAwZmY3ODAKKFhFTikgRE1JIDIuMyBwcmVzZW50LgooWEVOKSBVc2luZyBB UElDIGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4NTA4CihY RU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0xeF9jbnRbNTQ0LDUwNF0sIHBtMXhfZXZ0WzU0 MCw1MDBdCihYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tiZmZmZTAwY10s IHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAoo WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQoo WEVOKSBQcm9jZXNzb3IgIzAgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEg MDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp Y19pZFsweDAyXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzIgMDoyIEFQSUMgdmVyc2lvbiAx NgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVk KQooWEVOKSBQcm9jZXNzb3IgIzMgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3Ig IzQgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBs YXBpY19pZFsweDA1XSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzUgMDoyIEFQSUMgdmVyc2lv biAxNgooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDA2XSBlbmFi bGVkKQooWEVOKSBQcm9jZXNzb3IgIzYgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBM QVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDA3XSBlbmFibGVkKQooWEVOKSBQcm9jZXNz b3IgIzcgMDoyIEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRb MHgwMV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk WzB4MDJdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlf aWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3Bp X2lkWzB4MDVdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNw aV9pZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFj cGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDhdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb MHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBh cGljX2lkIDgsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMTUKKFhFTikg QUNQSTogSU9BUElDIChpZFsweDA5XSBhZGRyZXNzWzB4ZmVjMDEwMDBdIGdzaV9iYXNlWzE2XSkK KFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMTAw MCwgR1NJIDE2LTMxCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwYV0gYWRkcmVzc1sweGZlYzAy MDAwXSBnc2lfYmFzZVszMl0pCihYRU4pIElPQVBJQ1syXTogYXBpY19pZCAxMCwgdmVyc2lvbiAx NywgYWRkcmVzcyAweGZlYzAyMDAwLCBHU0kgMzItNDcKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIg KGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSVJRMCB1 c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4p IEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAzIEkvTyBBUElDcwooWEVOKSBQQ0k6 IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21lbnQgMCBidXNlcyAwIC0g MjU1CihYRU4pIFBDSTogTm90IHVzaW5nIE1NQ09ORklHLgooWEVOKSBUYWJsZSBpcyBub3QgZm91 bmQhCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbgooWEVOKSBJUlEgbGltaXRzOiA0OCBHU0ksIDE1MDQgTVNJL01TSS1YCihYRU4pIFVzaW5n IHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQg MjI5NC4zMDggTUh6IHByb2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhF TikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIEFNRC1W aTogSU9NTVUgbm90IGZvdW5kIQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZGlzYWJsZWQKKFhF TikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZAoo WEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x CihYRU4pIFBsYXRmb3JtIHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBl ZCAxMCBvciBtb3JlIHRpbWVzLgooWEVOKSBQbGF0Zm9ybSB0aW1lciBpcyAzLjU3OU1IeiBBQ1BJ IFBNIFRpbWVyCsuHKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4p IEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVy ZXM6CihYRU4pICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSAgLSBMYXN0IEJyYW5j aCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KKFhFTikgSFZNOiBTVk0gZW5hYmxlZAooWEVO KSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyBkZXRlY3RlZC4KKFhFTikgQnJvdWdodCB1 cCA4IENQVXMKKFhFTikgQ1BVSURMRTogZGlzYWJsZWQgZHVlIHRvIG5vIEhQRVQuIEZvcmNlIGVu YWJsZSB3aXRoICdjcHVpZGxlJy4KKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgTUNB OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQooWEVOKSBt Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCihYRU4pICoq KiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBj b21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAw MDAwMCAtPiAweDFlYjgwMDAKKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVO KSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDM3MDAwMDAwMC0+MDAwMDAwMDM3NDAwMDAwMCAoMjQz MzQwIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAz N2Y2OGMwMDAtPjAwMDAwMDAzN2ZmZmZlMDAKKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1F TlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgxZWI4 MDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgxZWI4MDAwLT5mZmZmZmZmZjgyODJi ZTAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyODJjMDAwLT5mZmZmZmZmZjgyYTJj MDAwCihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgyYTJjMDAwLT5mZmZmZmZmZjgyYTJj NGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgyYTJkMDAwLT5mZmZmZmZmZjgyYTQ2 MDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyYTQ2MDAwLT5mZmZmZmZmZjgyYTQ3 MDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgyYzAw MDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxOGI0MjAwCihYRU4pIERvbTAgaGFz IG1heGltdW0gOCBWQ1BVcwooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4K KFhFTikgWGVuIHRyYWNlIGJ1ZmZlcnM6IGRpc2FibGVkCihYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs bAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQooWEVO KSBGcmVlZCAyMjhrQiBpbml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBt ZW1vcnkKWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQgc3RhcnRlZC4u LgpbICAgIDAuMDAwMDAwXSBDYW5ub3QgZmluZCAyMDQ4MCBieXRlcyBpbiBub2RlIDEKWyAgICAw LjAwMDAwMF0gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZl cmVuY2UgYXQgICAgICAgICAgIChudWxsKQpbICAgIDAuMDAwMDAwXSBJUDogWzxmZmZmZmZmZjgx OGQ1NzA0Pl0gX19hbGxvY19ib290bWVtX25vZGUrMHg3Mi8weDk5ClsgICAgMC4wMDAwMDBdIFBH RCAwIApbICAgIDAuMDAwMDAwXSBPb3BzOiAwMDAwIFsjMV0gUFJFRU1QVCBTTVAgClsgICAgMC4w MDAwMDBdIENQVSAwIApbICAgIDAuMDAwMDAwXSBNb2R1bGVzIGxpbmtlZCBpbjoKWyAgICAwLjAw MDAwMF0gClsgICAgMC4wMDAwMDBdIFBpZDogMCwgY29tbTogc3dhcHBlciBOb3QgdGFpbnRlZCAz LjMuNC0yLUFSQ0ggIzEgZW1wdHkgZW1wdHkvUzM5OTIKWyAgICAwLjAwMDAwMF0gUklQOiBlMDMw Ols8ZmZmZmZmZmY4MThkNTcwND5dICBbPGZmZmZmZmZmODE4ZDU3MDQ+XSBfX2FsbG9jX2Jvb3Rt ZW1fbm9kZSsweDcyLzB4OTkKWyAgICAwLjAwMDAwMF0gUlNQOiBlMDJiOmZmZmZmZmZmODE4MDFk ZTggIEVGTEFHUzogMDAwMTAwNDYKWyAgICAwLjAwMDAwMF0gUkFYOiAwMDAwMDAwMDAwMDAwMDAw IFJCWDogMDAwMDAwMDAwMDAwMDM3OCBSQ1g6IDAwMDAwMDAwMDAwMDAwMDAKWyAgICAwLjAwMDAw MF0gUkRYOiAwMDAwMDAwMDAwMDAwMDQwIFJTSTogMDAwMDAwMDAwMDAwMDM3OCBSREk6IDAwMDAw MDAwMDAwMDAwMDAKWyAgICAwLjAwMDAwMF0gUkJQOiBmZmZmZmZmZjgxODAxZTA4IFIwODogMDAw MDAwMDAwMDAwMDAwMCBSMDk6IGZmZmZmZmZmODE4MDFkOTgKWyAgICAwLjAwMDAwMF0gUjEwOiBm ZmZmZmZmZjgxODAxZDg4IFIxMTogZmZmZmZmZmY4MTgwMWQ5MCBSMTI6IDAwMDAwMDAwMDAwMDAw NDAKWyAgICAwLjAwMDAwMF0gUjEzOiAwMDAwMDAwMDAwMDAwMDAwIFIxNDogMDAwMDAwMDAwMDAw MDAwMCBSMTU6IDAwMDAwMDAwMDAwMDAwMDEKWyAgICAwLjAwMDAwMF0gRlM6ICAwMDAwMDAwMDAw MDAwMDAwKDAwMDApIEdTOmZmZmZmZmZmODE4OWYwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAw MDAwMApbICAgIDAuMDAwMDAwXSBDUzogIGUwMzMgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAw MDAwMDgwMDUwMDMzClsgICAgMC4wMDAwMDBdIENSMjogMDAwMDAwMDAwMDAwMDAwMCBDUjM6IDAw MDAwMDAwMDE4MDUwMDAgQ1I0OiAwMDAwMDAwMDAwMDAwNjYwClsgICAgMC4wMDAwMDBdIERSMDog MDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAw MDAwClsgICAgMC4wMDAwMDBdIERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6IDAwMDAwMDAwMDAw MDAwMDAgRFI3OiAwMDAwMDAwMDAwMDAwMDAwClsgICAgMC4wMDAwMDBdIFByb2Nlc3Mgc3dhcHBl ciAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE4MDAwMDAsIHRhc2sgZmZmZmZmZmY4MTgw ZDAyMCkKWyAgICAwLjAwMDAwMF0gU3RhY2s6ClsgICAgMC4wMDAwMDBdICAwMDAwMDAwMDAwMDgw MDAwIDAwMDAwMDAwMDAwMDAzNzggMDAwMDAwMDAwMDAwMDAzYyBmZmZmODgwMDNmYmZhMDAwClsg ICAgMC4wMDAwMDBdICBmZmZmZmZmZjgxODAxZTY4IGZmZmZmZmZmODE4ZDYzZjAgZmZmZmZmZmY4 MTgwMWU0OCAwMDAwMDAwMTgxOGQ1M2JjClsgICAgMC4wMDAwMDBdICBmZmZmODgwMDNmYmY5ZmUw IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMjgyYzAwMCBmZmZmODgwMDNmYmZhMDAwClsgICAg MC4wMDAwMDBdIENhbGwgVHJhY2U6ClsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE4ZDYzZjA+ XSBzcGFyc2VfZWFybHlfdXNlbWFwc19hbGxvY19ub2RlKzB4NjMvMHgxYzQKWyAgICAwLjAwMDAw MF0gIFs8ZmZmZmZmZmY4MThkNjc3Yj5dIHNwYXJzZV9pbml0KzB4ZjgvMHgyYzgKWyAgICAwLjAw MDAwMF0gIFs8ZmZmZmZmZmY4MThjYTRkMj5dIHBhZ2luZ19pbml0KzB4MTMvMHgyMgpbICAgIDAu MDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI5ZGNhPl0gc2V0dXBfYXJjaCsweDlmMi8weGFjMApbICAg IDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxNDU2MmQyPl0gPyBwcmludGsrMHg0MS8weDQzClsgICAg MC4wMDAwMDBdICBbPGZmZmZmZmZmODE4YjQ5MWI+XSBzdGFydF9rZXJuZWwrMHhkNC8weDNkMQpb ICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0MzQ2Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0 aW9ucysweDEzMS8weDEzNQpbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI2OWM5Pl0geGVu X3N0YXJ0X2tlcm5lbCsweDU5OC8weDU5ZgpbICAgIDAuMDAwMDAwXSBDb2RlOiA0YyA4OSBlOSA0 YyA4OSBlMiA0OCA4OSBkZSBiZiA0MCAwMCAwMCAwMCBlOCAwZiBmYyBmZiBmZiBlYiAzNCA0MSA4 YiA5NiBhMCA0MCAwMCAwMCBiZSAwMCA4MCAwMCAwMCA0OCA4OSBkZiBlOCAxZSAxMSA4OCBmZiBl YiAxZSA8NDE+IDhiIGJlIGEwIDQwIDAwIDAwIDQ5IDgzIGM4IGZmIDRjIDg5IGU5IDRjIDg5IGUy IDQ4IDg5IGRlIGU4IApbICAgIDAuMDAwMDAwXSBSSVAgIFs8ZmZmZmZmZmY4MThkNTcwND5dIF9f YWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5OQpbICAgIDAuMDAwMDAwXSAgUlNQIDxmZmZmZmZm ZjgxODAxZGU4PgpbICAgIDAuMDAwMDAwXSBDUjI6IDAwMDAwMDAwMDAwMDAwMDAKWyAgICAwLjAw MDAwMF0gLS0tWyBlbmQgdHJhY2UgYTc5MTllN2YxN2MwYTcyNSBdLS0tClsgICAgMC4wMDAwMDBd IEtlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBBdHRlbXB0ZWQgdG8ga2lsbCB0aGUgaWRsZSB0 YXNrIQooWEVOKSBEb21haW4gMCBjcmFzaGVkOiByZWJvb3RpbmcgbWFjaGluZSBpbiA1IHNlY29u ZHMuCgoKVGhhbmtzIQoKCi0tIApTYW0gTXVsdmV5ClRhY29tYSBUZWxlbWF0aWNzCnNhbUB0YWNv bWF0ZWxlbWF0aWNzLmNvbQooMjUzKSA4ODMtMzAzMCB4MTEwCgoKCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 03 18:09:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18:09:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0T1-0006Uz-Qs; Thu, 03 May 2012 18:09:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0Sz-0006Ut-OB for xen-devel@lists.xen.org; Thu, 03 May 2012 18:09:25 +0000 Received: from [85.158.139.83:9781] by server-6.bemta-5.messagelabs.com id E1/75-13222-5D9C2AF4; Thu, 03 May 2012 18:09:25 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336068562!26112844!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4340 invoked from network); 3 May 2012 18:09:23 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 18:09:23 -0000 Received: by qafl39 with SMTP id l39so630226qaf.16 for ; Thu, 03 May 2012 11:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kwoAqjhvsHueNzWrUjn1nwo/dLJC18GLC4uohsVdpjQ=; b=l/bslEkAhcDCGvV9OKNOk5heqGnTfSAuzZPPcrOCuk7yWqTtzPFjRsu6LHYl8nP+m9 CzsZMGtOwTDnRu0Lj/c2ZfdSkLbVwIfwj33p4nl7h72BnUhpTdUVIBquhXNFM04CsHDX /qsdZiPApLV/HDutotVPSKo1taZtb2ElaDr7nSGqwfCIqDa2uereKf7gMX9ZsaxJN/Gc ds6aBhDvaMjcuj6qevI/C3kIyZ2G8lFulYB3D6TWI/S+r1m+pglcJVEeycA32zLoXQTW J5PMW2mc9bm8Zriy8IXRrRlqELcMNfkNuhAPo2qY2pbzywKwxXKJyqFwy1O6GGFbEfAP LKtQ== MIME-Version: 1.0 Received: by 10.229.137.130 with SMTP id w2mr1414413qct.154.1336068561411; Thu, 03 May 2012 11:09:21 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Thu, 3 May 2012 11:09:21 -0700 (PDT) In-Reply-To: <4FA268CD02000078000814E4@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> Date: Thu, 3 May 2012 11:09:21 -0700 Message-ID: From: AP To: Jan Beulich Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 2:15 AM, Jan Beulich wrote: >>>> On 02.05.12 at 20:42, AP wrote: >> On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>>> I somehow thought that this has been fixed but I've been >>>> getting reports that people are running into this. >>> >>> "this" being what? I too thought that all xsave related issues were >>> sorted out by now. >> >> I see the following crash if I run without xsave=0 with Ubuntu 11.10 >> 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with >> Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. > > And in the thread starting at > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html > I gave debugging instructions that apparently no-one followed so > far. Without someone seeing the problem doing so I don't think we > will ever get anywhere with this (unless, as also indicated there, > someone can spot something wrong with the code that non-obvious > to everyone else). I missed that thread. I will add some debugging to pv_guest_cr4_fixup() and the XSETBV handling in emulate_privileged_op() and post the output. Thanks, AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:09:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18:09:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0T1-0006Uz-Qs; Thu, 03 May 2012 18:09:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0Sz-0006Ut-OB for xen-devel@lists.xen.org; Thu, 03 May 2012 18:09:25 +0000 Received: from [85.158.139.83:9781] by server-6.bemta-5.messagelabs.com id E1/75-13222-5D9C2AF4; Thu, 03 May 2012 18:09:25 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336068562!26112844!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4340 invoked from network); 3 May 2012 18:09:23 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 18:09:23 -0000 Received: by qafl39 with SMTP id l39so630226qaf.16 for ; Thu, 03 May 2012 11:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kwoAqjhvsHueNzWrUjn1nwo/dLJC18GLC4uohsVdpjQ=; b=l/bslEkAhcDCGvV9OKNOk5heqGnTfSAuzZPPcrOCuk7yWqTtzPFjRsu6LHYl8nP+m9 CzsZMGtOwTDnRu0Lj/c2ZfdSkLbVwIfwj33p4nl7h72BnUhpTdUVIBquhXNFM04CsHDX /qsdZiPApLV/HDutotVPSKo1taZtb2ElaDr7nSGqwfCIqDa2uereKf7gMX9ZsaxJN/Gc ds6aBhDvaMjcuj6qevI/C3kIyZ2G8lFulYB3D6TWI/S+r1m+pglcJVEeycA32zLoXQTW J5PMW2mc9bm8Zriy8IXRrRlqELcMNfkNuhAPo2qY2pbzywKwxXKJyqFwy1O6GGFbEfAP LKtQ== MIME-Version: 1.0 Received: by 10.229.137.130 with SMTP id w2mr1414413qct.154.1336068561411; Thu, 03 May 2012 11:09:21 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Thu, 3 May 2012 11:09:21 -0700 (PDT) In-Reply-To: <4FA268CD02000078000814E4@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> Date: Thu, 3 May 2012 11:09:21 -0700 Message-ID: From: AP To: Jan Beulich Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 2:15 AM, Jan Beulich wrote: >>>> On 02.05.12 at 20:42, AP wrote: >> On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>>> I somehow thought that this has been fixed but I've been >>>> getting reports that people are running into this. >>> >>> "this" being what? I too thought that all xsave related issues were >>> sorted out by now. >> >> I see the following crash if I run without xsave=0 with Ubuntu 11.10 >> 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with >> Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. > > And in the thread starting at > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html > I gave debugging instructions that apparently no-one followed so > far. Without someone seeing the problem doing so I don't think we > will ever get anywhere with this (unless, as also indicated there, > someone can spot something wrong with the code that non-obvious > to everyone else). I missed that thread. I will add some debugging to pv_guest_cr4_fixup() and the XSETBV handling in emulate_privileged_op() and post the output. Thanks, AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:15:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ0Ym-0006fT-Lb; Thu, 03 May 2012 18:15:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0Yl-0006fO-3z for xen-devel@lists.xen.org; Thu, 03 May 2012 18:15:23 +0000 Received: from [85.158.143.35:5433] by server-2.bemta-4.messagelabs.com id 33/43-17550-A3BC2AF4; Thu, 03 May 2012 18:15:22 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336068916!14630639!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17653 invoked from network); 3 May 2012 18:15:21 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 18:15:21 -0000 Received: by lahe6 with SMTP id e6so1844898lah.32 for ; Thu, 03 May 2012 11:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M3FfYz8EnhmsmFPzWoXuuITDIlgvHmMAcDUaKXxJhcg=; b=CxIVPy0FnOq8CJWFPcIFHqpwD9KX64kfNyfm+jkYmvQO2578s5tAv2aoCDmgVA3uw8 cqpHyL6ZeOdpUSZxk6Q3tTBA8x8P4bN5d8d5UrZ9lxZaCi/YiW1rTlxReqKH/m+cuJCk VV/g1M4QUB1Xb9aRWCiOKBSfJ+jMDGjmUuU1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=M3FfYz8EnhmsmFPzWoXuuITDIlgvHmMAcDUaKXxJhcg=; b=W59fikx9MnU/Dqj12ZxDmbkjFe2xlgUCsYi71u4Q+3GHjTvtMZThbpzSzcuanRxb0a uSZ+T46eEP5N971OFUZ0RxdHvECW9SizKNuE/zbyCz5w3gW6bB7yTB0/QJCcjnfgz2yt PV9P1LctiF/6OKX6gjSSC1u6b7Uw02dLrMEdtRLJve1oQf78r8ROFcp2JK4OaCLlKmdT 1RuF+X+fPROd8NNkR4UrJ7QZBD3scokt8ec8JOfP+onqGVbmRsAzWVI7cvea7shNfLlw S8numiemVJ0tBclY3mh/dzyPZtJYnAw5YV6BJHZH+NAmjxNxY3E+ShCo9Yr65gppzlLK /0ew== MIME-Version: 1.0 Received: by 10.112.26.233 with SMTP id o9mr1542291lbg.23.1336068916202; Thu, 03 May 2012 11:15:16 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Thu, 3 May 2012 11:15:16 -0700 (PDT) X-Originating-IP: [108.92.21.169] In-Reply-To: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> Date: Thu, 3 May 2012 11:15:16 -0700 Message-ID: From: Aravindh Puthiyaparambil To: "Dong, Eddie" X-Gm-Message-State: ALoCoQktAaoNEY5qZUDTiVmC+ew0a7iKW2FdbsAg2BQrrkg0q9d6Q3uy8k8Loruh2lo3j44Rl6OZ Cc: "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 6:42 AM, Dong, Eddie wrote: >> > The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >> > Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real usage case to test so far. > > We will provide #1 quickly, but for #2, can Aravindh provide test if we get the patch ready? I will gladly debug and test #2 for you. Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:15:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ0Ym-0006fT-Lb; Thu, 03 May 2012 18:15:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0Yl-0006fO-3z for xen-devel@lists.xen.org; Thu, 03 May 2012 18:15:23 +0000 Received: from [85.158.143.35:5433] by server-2.bemta-4.messagelabs.com id 33/43-17550-A3BC2AF4; Thu, 03 May 2012 18:15:22 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336068916!14630639!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17653 invoked from network); 3 May 2012 18:15:21 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 May 2012 18:15:21 -0000 Received: by lahe6 with SMTP id e6so1844898lah.32 for ; Thu, 03 May 2012 11:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M3FfYz8EnhmsmFPzWoXuuITDIlgvHmMAcDUaKXxJhcg=; b=CxIVPy0FnOq8CJWFPcIFHqpwD9KX64kfNyfm+jkYmvQO2578s5tAv2aoCDmgVA3uw8 cqpHyL6ZeOdpUSZxk6Q3tTBA8x8P4bN5d8d5UrZ9lxZaCi/YiW1rTlxReqKH/m+cuJCk VV/g1M4QUB1Xb9aRWCiOKBSfJ+jMDGjmUuU1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=M3FfYz8EnhmsmFPzWoXuuITDIlgvHmMAcDUaKXxJhcg=; b=W59fikx9MnU/Dqj12ZxDmbkjFe2xlgUCsYi71u4Q+3GHjTvtMZThbpzSzcuanRxb0a uSZ+T46eEP5N971OFUZ0RxdHvECW9SizKNuE/zbyCz5w3gW6bB7yTB0/QJCcjnfgz2yt PV9P1LctiF/6OKX6gjSSC1u6b7Uw02dLrMEdtRLJve1oQf78r8ROFcp2JK4OaCLlKmdT 1RuF+X+fPROd8NNkR4UrJ7QZBD3scokt8ec8JOfP+onqGVbmRsAzWVI7cvea7shNfLlw S8numiemVJ0tBclY3mh/dzyPZtJYnAw5YV6BJHZH+NAmjxNxY3E+ShCo9Yr65gppzlLK /0ew== MIME-Version: 1.0 Received: by 10.112.26.233 with SMTP id o9mr1542291lbg.23.1336068916202; Thu, 03 May 2012 11:15:16 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Thu, 3 May 2012 11:15:16 -0700 (PDT) X-Originating-IP: [108.92.21.169] In-Reply-To: References: <4F914060020000780007EC9D@nat28.tlf.novell.com> <4FA1193D02000078000810EC@nat28.tlf.novell.com> <4FA26B7C0200007800081502@nat28.tlf.novell.com> Date: Thu, 3 May 2012 11:15:16 -0700 Message-ID: From: Aravindh Puthiyaparambil To: "Dong, Eddie" X-Gm-Message-State: ALoCoQktAaoNEY5qZUDTiVmC+ew0a7iKW2FdbsAg2BQrrkg0q9d6Q3uy8k8Loruh2lo3j44Rl6OZ Cc: "Nakajima, Jun" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 6:42 AM, Dong, Eddie wrote: >> > The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >> > Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real usage case to test so far. > > We will provide #1 quickly, but for #2, can Aravindh provide test if we get the patch ready? I will gladly debug and test #2 for you. Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:36:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ0sU-0006t2-Kz; Thu, 03 May 2012 18:35:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0sT-0006sx-3r for xen-devel@lists.xensource.com; Thu, 03 May 2012 18:35:45 +0000 Received: from [85.158.139.83:5090] by server-12.bemta-5.messagelabs.com id C0/CF-01344-000D2AF4; Thu, 03 May 2012 18:35:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336070143!26644968!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13684 invoked from network); 3 May 2012 18:35:43 -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; 3 May 2012 18:35:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="12282528" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 18:35: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, 3 May 2012 19:35:26 +0100 Date: Thu, 3 May 2012 19:42:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Vinaya M S In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, Vinaya M S wrote: > Hi Stefano, > > I'm also using ubuntu 11.04 HVM domain with xen 4.1.0. > If I enable xen_platform_pci then I get busybox error. > If I say xen_platform_pci=0 then it boots fine. Can you post the boot logs please? > I make passthrough devices available by using pci-stub > module as pci_back is ntworking for me. > [CONFIG_XEN_PCIDEV_BACKEND=y instead of m] Are you using xm or xl? Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? > When I provide these pci devices either by > config file or by pci-attach my system turns blank. > I read your post and tried with ubuntu 10.04 as guest. > But I run into same problem. Try assigning something that is not a graphic card, do you see the device if you execute lspci? > Should I have to create a kernel image inside d guest > wid al configurations enabled in domu as > mentioned in http://wiki.xensource.com/xenwiki/XenParavirtOps it should not be necessary > Let me know where I'm going wrong or else > let me know the solution to get it working on 11.04. > FYI: PCI devices are nvidia graphics card Is it your primary graphic card? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:36:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ0sU-0006t2-Kz; Thu, 03 May 2012 18:35:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ0sT-0006sx-3r for xen-devel@lists.xensource.com; Thu, 03 May 2012 18:35:45 +0000 Received: from [85.158.139.83:5090] by server-12.bemta-5.messagelabs.com id C0/CF-01344-000D2AF4; Thu, 03 May 2012 18:35:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336070143!26644968!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13684 invoked from network); 3 May 2012 18:35:43 -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; 3 May 2012 18:35:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="12282528" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 18:35: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, 3 May 2012 19:35:26 +0100 Date: Thu, 3 May 2012 19:42:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Vinaya M S In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 3 May 2012, Vinaya M S wrote: > Hi Stefano, > > I'm also using ubuntu 11.04 HVM domain with xen 4.1.0. > If I enable xen_platform_pci then I get busybox error. > If I say xen_platform_pci=0 then it boots fine. Can you post the boot logs please? > I make passthrough devices available by using pci-stub > module as pci_back is ntworking for me. > [CONFIG_XEN_PCIDEV_BACKEND=y instead of m] Are you using xm or xl? Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? > When I provide these pci devices either by > config file or by pci-attach my system turns blank. > I read your post and tried with ubuntu 10.04 as guest. > But I run into same problem. Try assigning something that is not a graphic card, do you see the device if you execute lspci? > Should I have to create a kernel image inside d guest > wid al configurations enabled in domu as > mentioned in http://wiki.xensource.com/xenwiki/XenParavirtOps it should not be necessary > Let me know where I'm going wrong or else > let me know the solution to get it working on 11.04. > FYI: PCI devices are nvidia graphics card Is it your primary graphic card? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:46:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ12V-00075x-PZ; Thu, 03 May 2012 18:46:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ12U-00075s-EO for xen-devel@lists.xen.org; Thu, 03 May 2012 18:46:06 +0000 Received: from [85.158.138.51:46415] by server-1.bemta-3.messagelabs.com id FD/B1-11491-D62D2AF4; Thu, 03 May 2012 18:46:05 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336070764!25046052!1 X-Originating-IP: [98.138.229.162] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23761 invoked from network); 3 May 2012 18:46:04 -0000 Received: from nm39-vm2.bullet.mail.ne1.yahoo.com (HELO nm39-vm2.bullet.mail.ne1.yahoo.com) (98.138.229.162) by server-8.tower-174.messagelabs.com with SMTP; 3 May 2012 18:46:04 -0000 Received: from [98.138.90.51] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 Received: from [98.138.88.237] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 462847.86100.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 10926 invoked by uid 60001); 3 May 2012 18:46:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1336070763; bh=xNMuWruphXmThpP1YxLRRbC25WfYeMV8me5ej4WbjwA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sFxG53oyH5UNDtDNh5zdlTQ0A81gysiXVCo7g7MWeXtAuscf9LMn+NUpwCd9obicF83HB6l6GEmHF9YNbJ87PZ0ZbAlYfch1VA5fJeP30gS2Yi7cex3y9jWSwVwwof+eP47ixjO/p1Sx6oehuw3PM0oEG3XO3X+eZymYJfIEGyM= 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:Reply-To:Subject:To:MIME-Version:Content-Type; b=HRQlNSlR3mYmTtwtL7WrY7NW7BoVBIztHaIui1BqHyH4OyckdQxaqFhEBcNW9Ver+WSt4TYPVIgEUwEBNQm3ceQoycTdOeVj8nngVnIp6wbkM8J8Bqniia5RzvdoPKlOov8tUPSKfjr4gHUa2ba/SEW6HdvoOY03du5c2ErVtbs=; X-YMail-OSG: 10BbO1QVM1l0pEGzOqAaknnwl5izOxssQqWeZVCw_AVqDcu KWcmwXIK6 Received: from [128.173.237.43] by web124502.mail.ne1.yahoo.com via HTTP; Thu, 03 May 2012 11:46:02 PDT X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> Date: Thu, 3 May 2012 11:46:02 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" MIME-Version: 1.0 Subject: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi I want to set up an inter-domain event channel, and I want to receive interrupts in both directions (i.e. Dom1 can independently send an interrupt to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and the other one on Dom 2, and on each domain I simply bind it to the corresponding interrupt handler? Or do I need to have 4 ports: one pair is used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? I would greatly appreciate if someone can explain it! Ruslan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 18:46:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 18: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 ) id 1SQ12V-00075x-PZ; Thu, 03 May 2012 18:46:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ12U-00075s-EO for xen-devel@lists.xen.org; Thu, 03 May 2012 18:46:06 +0000 Received: from [85.158.138.51:46415] by server-1.bemta-3.messagelabs.com id FD/B1-11491-D62D2AF4; Thu, 03 May 2012 18:46:05 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336070764!25046052!1 X-Originating-IP: [98.138.229.162] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23761 invoked from network); 3 May 2012 18:46:04 -0000 Received: from nm39-vm2.bullet.mail.ne1.yahoo.com (HELO nm39-vm2.bullet.mail.ne1.yahoo.com) (98.138.229.162) by server-8.tower-174.messagelabs.com with SMTP; 3 May 2012 18:46:04 -0000 Received: from [98.138.90.51] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 Received: from [98.138.88.237] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 03 May 2012 18:46:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 462847.86100.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 10926 invoked by uid 60001); 3 May 2012 18:46:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1336070763; bh=xNMuWruphXmThpP1YxLRRbC25WfYeMV8me5ej4WbjwA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sFxG53oyH5UNDtDNh5zdlTQ0A81gysiXVCo7g7MWeXtAuscf9LMn+NUpwCd9obicF83HB6l6GEmHF9YNbJ87PZ0ZbAlYfch1VA5fJeP30gS2Yi7cex3y9jWSwVwwof+eP47ixjO/p1Sx6oehuw3PM0oEG3XO3X+eZymYJfIEGyM= 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:Reply-To:Subject:To:MIME-Version:Content-Type; b=HRQlNSlR3mYmTtwtL7WrY7NW7BoVBIztHaIui1BqHyH4OyckdQxaqFhEBcNW9Ver+WSt4TYPVIgEUwEBNQm3ceQoycTdOeVj8nngVnIp6wbkM8J8Bqniia5RzvdoPKlOov8tUPSKfjr4gHUa2ba/SEW6HdvoOY03du5c2ErVtbs=; X-YMail-OSG: 10BbO1QVM1l0pEGzOqAaknnwl5izOxssQqWeZVCw_AVqDcu KWcmwXIK6 Received: from [128.173.237.43] by web124502.mail.ne1.yahoo.com via HTTP; Thu, 03 May 2012 11:46:02 PDT X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> Date: Thu, 3 May 2012 11:46:02 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" MIME-Version: 1.0 Subject: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi I want to set up an inter-domain event channel, and I want to receive interrupts in both directions (i.e. Dom1 can independently send an interrupt to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and the other one on Dom 2, and on each domain I simply bind it to the corresponding interrupt handler? Or do I need to have 4 ports: one pair is used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? I would greatly appreciate if someone can explain it! Ruslan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 19:02:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 19: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 ) id 1SQ1IC-0007Hi-9n; Thu, 03 May 2012 19:02:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ1IB-0007Hd-E0 for xen-devel@lists.xen.org; Thu, 03 May 2012 19:02:19 +0000 Received: from [85.158.139.83:62288] by server-11.bemta-5.messagelabs.com id A6/A8-12959-A36D2AF4; Thu, 03 May 2012 19:02:18 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336071736!22704782!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24505 invoked from network); 3 May 2012 19:02:17 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 19:02:17 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43J2CFX031002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 19:02:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43J2B7I021567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 19:02:12 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 q43J2Bvk011415; Thu, 3 May 2012 14:02:11 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 12:02:11 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A52834031D; Thu, 3 May 2012 14:56:29 -0400 (EDT) Date: Thu, 3 May 2012 14:56:29 -0400 From: Konrad Rzeszutek Wilk To: Sam Mulvey Message-ID: <20120503185629.GA4895@phenom.dumpdata.com> References: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: great.potato@gmail.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMTE6MDI6MDJBTSAtMDcwMCwgU2FtIE11bHZleSB3cm90 ZToKPiAKPiBPbiBNYXkgMywgMjAxMiwgYXQgMTA6MjQgQU0sIEtvbnJhZCBSemVzenV0ZWsgV2ls ayB3cm90ZToKPiA+IAo+ID4gVGhpcyBsb29rcyBsaWtlIGFuIEU4MjAgYWxpZ25tZW50IGlzc3Vl LiBDYW4geW91IHByb3ZpZGUgdGhlIGZ1bGwgc2VyaWFsIG91dHB1dCBwbGVhc2UuCj4gCj4gQ29t aW5nIHJpZ2h0IHVwIQoKSG0sIHRoZXJlIGlzIG5vdGhpbmcgaGVyZSB0aGF0IGxvb2tzIHdyb25n LCBwZXIgc2F5LiBJIHdvdWxkIHN1Z2dlc3QKeW91IGRvOiBkb20wX21lbT1tYXg6MUcgaW5zdGVh ZCBvZiBkb20wX21lbT0xRyAob3RoZXJ3aXNlIHlvdSBlbmQgdXAKaGF2aW5nIGRvbTAgY29udGFp biBwYWdlcyBmb3IgdGhlIGZ1bGwgMTNHQikuCgpCZXNpZGVzIHRoYXQsIGNhbiB5b3UgZG8gcmVk byB0aGlzIHdpdGggb24gTGludXggY29tbWFuZCBsaW5lIGJlOgoKJ2Vhcmx5cHJpbnRrPXhlbiBj b25zb2xlPWh2YzAgZGVidWcgbWVtYmxvY2s9ZGVidWcgbG9nbGV2ZWw9OCBpbml0Y2FsbF9kZWJ1 ZyIKCkFuZCBhZGQgb24gdGhlIFhlbiBsaW5lOiAic3luY19jb25zb2xlIi4KCkhvcGVmdWxseSB0 aGF0IHdpbGwgcHJvdmlkZSBzb21lIGlkZWEgb2Ygd2h5IHRoaXMgaXMgbm90IHdvcmtpbmcgcmln aHQuCgo+IAo+IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF9fX18gIAo+ICBcIFwvIC9f X18gXyBfXyAgIHwgfHwgfCAgLyB8IHxfX18gXCAKPiAgIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxf IHwgfCAgIF9fKSB8Cj4gICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3x8IHxfIC8gX18vIAo+ICAv Xy9cX1xfX198X3wgfF98ICAgIHxffChfKV8oXylfX19fX3wKPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCj4gKFhFTikgWGVuIHZlcnNpb24gNC4xLjIgKHNhbUBsb2NhbGRv bWFpbikgKGdjYyB2ZXJzaW9uIDQuNy4wIDIwMTIwNDE0IChwcmVyZWxlYXNlKSAoR0NDKSApIFdl ZCBNYXkgIDIgMTk6NTE6MjEgUERUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiB1bmF2 YWlsYWJsZQo+IChYRU4pIEJvb3Rsb2FkZXI6IEdOVSBHUlVCIDAuOTcKPiAoWEVOKSBDb21tYW5k IGxpbmU6IGRvbTBfbWVtPTFHIGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBjb20xPTExNTIw MCw4bjEgY29uc29sZT1jb20xCj4gKFhFTikgVmlkZW8gaW5mb3JtYXRpb246Cj4gKFhFTikgIFZH QSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgo+IChYRU4pICBWQkUvRERDIG1ldGhvZHM6 IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDIgc2Vjb25kcwo+IChYRU4pIERpc2MgaW5mb3JtYXRp b246Cj4gKFhFTikgIEZvdW5kIDMgTUJSIHNpZ25hdHVyZXMKPiAoWEVOKSAgRm91bmQgMyBFREQg aW5mb3JtYXRpb24gc3RydWN0dXJlcwo+IChYRU4pIFhlbi1lODIwIFJBTSBtYXA6Cj4gKFhFTikg IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlkMDAwICh1c2FibGUpCj4gKFhFTikgIDAw MDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAw MDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAw MDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBiZmZmMDAwMCAodXNhYmxlKQo+IChYRU4pICAwMDAwMDAw MGJmZmYwMDAwIC0gMDAwMDAwMDBiZmZmZTAwMCAoQUNQSSBkYXRhKQo+IChYRU4pICAwMDAwMDAw MGJmZmZlMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAoQUNQSSBOVlMpCj4gKFhFTikgIDAwMDAwMDAw ZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAzMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAwMDAwMDBm ZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMTAw MDAwMDAwIC0gMDAwMDAwMDM4MDAwMDAwMCAodXNhYmxlKQo+IChYRU4pIEFDUEk6IFJTRFAgMDAw RjgzQzAsIDAwMjQgKHIyIEFDUElBTSkKPiAoWEVOKSBBQ1BJOiBYU0RUIEJGRkYwMTAwLCAwMDRD IChyMSAwNzEwMDggWFNEVDA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBGQUNQIEJGRkYwMjkwLCAwMEY0IChyMyAwNzEwMDggRkFDUDA5NDggMjAwODA3MTAgTVNGVCAg ICAgICA5NykKPiAoWEVOKSBBQ1BJOiBEU0RUIEJGRkYwNEEwLCAzQjY4IChyMSAgMEFBQUEgMEFB QUEwMDAgICAgICAgIDAgSU5UTCAgMjAwMjAyNikKPiAoWEVOKSBBQ1BJOiBGQUNTIEJGRkZFMDAw LCAwMDQwCj4gKFhFTikgQUNQSTogQVBJQyBCRkZGMDM5MCwgMDBDQSAocjEgMDcxMDA4IEFQSUMw OTQ4IDIwMDgwNzEwIE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogTUNGRyBCRkZGMDQ2MCwg MDAzQyAocjEgMDcxMDA4IE9FTU1DRkcgIDIwMDgwNzEwIE1TRlQgICAgICAgOTcpCj4gKFhFTikg QUNQSTogT0VNQiBCRkZGRTA0MCwgMDA1NiAocjEgMDcxMDA4IE9FTUIwOTQ4IDIwMDgwNzEwIE1T RlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogU1JBVCBCRkZGNDAxMCwgMDE1MCAocjEgQU1EICAg IEhBTU1FUiAgICAgICAgICAxIEFNRCAgICAgICAgIDEpCj4gKFhFTikgU3lzdGVtIFJBTTogMTMz MTFNQiAoMTM2MzEwMjhrQikKPiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9kZSAw Cj4gKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMAo+IChYRU4pIFNSQVQ6IFBY TSAwIC0+IEFQSUMgMiAtPiBOb2RlIDAKPiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDMgLT4g Tm9kZSAwCj4gKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA0IC0+IE5vZGUgMQo+IChYRU4pIFNS QVQ6IFBYTSAxIC0+IEFQSUMgNSAtPiBOb2RlIDEKPiAoWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElD IDYgLT4gTm9kZSAxCj4gKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA3IC0+IE5vZGUgMQo+IChY RU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAwLWEwMDAwCj4gKFhFTikgU1JBVDogTm9kZSAwIFBYTSAw IDEwMDAwMC1jMDAwMDAwMAo+IChYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMWUw MDAwMDAwCj4gKFhFTikgU1JBVDogTm9kZSAxIFBYTSAxIDFlMDAwMDAwMC0zODAwMDAwMDAKPiAo WEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDM3ZTVmNTAwMCAtIDM3ZTVmOTAw MAo+IChYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lgo+IChYRU4pIERvbWFp biBoZWFwIGluaXRpYWxpc2VkIERNQSB3aWR0aCAzMCBiaXRzCj4gKFhFTikgZm91bmQgU01QIE1Q LXRhYmxlIGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIDIuMyBwcmVzZW50Lgo+IChYRU4pIFVzaW5n IEFQSUMgZHJpdmVyIGRlZmF1bHQKPiAoWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDUw OAo+IChYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0xeF9jbnRbNTQ0LDUwNF0sIHBtMXhf ZXZ0WzU0MCw1MDBdCj4gKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3YWtldXBfdmVjW2Jm ZmZlMDBjXSwgdmVjX3NpemVbMjBdCj4gKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4 ZmVlMDAwMDAKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAw XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMCAwOjIgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKPiAo WEVOKSBQcm9jZXNzb3IgIzEgMDoyIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICMyIDA6MiBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0 XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMyAwOjIgQVBJQyB2 ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw NF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzQgMDoyIEFQSUMgdmVyc2lvbiAxNgo+IChY RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4g KFhFTikgUHJvY2Vzc29yICM1IDA6MiBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3Nv ciAjNiAwOjIgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw OF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzcgMDoyIEFQSUMg dmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAxXSBoaWdoIGVk Z2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdo IGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAzXSBo aWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA0 XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsw eDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNw aV9pZFsweDA3XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAo YWNwaV9pZFsweDA4XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IElPQVBJQyAo aWRbMHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKPiAoWEVOKSBJT0FQSUNb MF06IGFwaWNfaWQgOCwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0xNQo+ IChYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwOV0gYWRkcmVzc1sweGZlYzAxMDAwXSBnc2lfYmFz ZVsxNl0pCj4gKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMTcsIGFkZHJlc3Mg MHhmZWMwMTAwMCwgR1NJIDE2LTMxCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDBhXSBhZGRy ZXNzWzB4ZmVjMDIwMDBdIGdzaV9iYXNlWzMyXSkKPiAoWEVOKSBJT0FQSUNbMl06IGFwaWNfaWQg MTAsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMjAwMCwgR1NJIDMyLTQ3Cj4gKFhFTikgQUNQ STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKPiAo WEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2Vk IGJ5IG92ZXJyaWRlLgo+IChYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAz IEkvTyBBUElDcwo+IChYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAw MDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKPiAoWEVOKSBQQ0k6IE5vdCB1c2luZyBNTUNPTkZJ Ry4KPiAoWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCj4gKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkg Zm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uCj4gKFhFTikgSVJRIGxpbWl0czogNDgg R1NJLCAxNTA0IE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBT Y2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAyMjk0LjMwOCBNSHogcHJvY2Vzc29y Lgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZhbTEwaCBtYWNo aW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgQU1ELVZpOiBJT01NVSBub3QgZm91 bmQhCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCj4gKFhFTikgRU5BQkxJTkcg SU8tQVBJQyBJUlFzCj4gKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kCj4gKFhFTikgLi5U SU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQo+IChYRU4p IFBsYXRmb3JtIHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBlZCAxMCBv ciBtb3JlIHRpbWVzLgo+IChYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDMuNTc5TUh6IEFDUEkgUE0g VGltZXIKPiDLhyhYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgNjQgS2lCLgo+IChYRU4p IEhWTTogQVNJRHMgZW5hYmxlZC4KPiAoWEVOKSBTVk06IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0 dXJlczoKPiAoWEVOKSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkKPiAoWEVOKSAgLSBMYXN0 IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KPiAoWEVOKSBIVk06IFNWTSBlbmFi bGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgZGV0ZWN0ZWQuCj4gKFhF TikgQnJvdWdodCB1cCA4IENQVXMKPiAoWEVOKSBDUFVJRExFOiBkaXNhYmxlZCBkdWUgdG8gbm8g SFBFVC4gRm9yY2UgZW5hYmxlIHdpdGggJ2NwdWlkbGUnLgo+IChYRU4pIEFDUEkgc2xlZXAgbW9k ZXM6IFMzCj4gKFhFTikgTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5n IGZyZXF1ZW5jeQo+IChYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt ZXIgc3RhcnRlZC4KPiAoWEVOKSAqKiogTE9BRElORyBET01BSU4gMCAqKioKPiAoWEVOKSAgWGVu ICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgo+IChYRU4pICBEb20wIGtlcm5lbDogNjQt Yml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MWViODAwMAo+IChYRU4pIFBIWVNJ Q0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKPiAoWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDM3 MDAwMDAwMC0+MDAwMDAwMDM3NDAwMDAwMCAoMjQzMzQwIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkK PiAoWEVOKSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDM3ZjY4YzAwMC0+MDAwMDAwMDM3ZmZmZmUw MAo+IChYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBMb2FkZWQga2Vy bmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgxZWI4MDAwCj4gKFhFTikgIEluaXQuIHJh bWRpc2s6IGZmZmZmZmZmODFlYjgwMDAtPmZmZmZmZmZmODI4MmJlMDAKPiAoWEVOKSAgUGh5cy1N YWNoIG1hcDogZmZmZmZmZmY4MjgyYzAwMC0+ZmZmZmZmZmY4MmEyYzAwMAo+IChYRU4pICBTdGFy dCBpbmZvOiAgICBmZmZmZmZmZjgyYTJjMDAwLT5mZmZmZmZmZjgyYTJjNGI0Cj4gKFhFTikgIFBh Z2UgdGFibGVzOiAgIGZmZmZmZmZmODJhMmQwMDAtPmZmZmZmZmZmODJhNDYwMDAKPiAoWEVOKSAg Qm9vdCBzdGFjazogICAgZmZmZmZmZmY4MmE0NjAwMC0+ZmZmZmZmZmY4MmE0NzAwMAo+IChYRU4p ICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgyYzAwMDAwCj4gKFhF TikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODE4YjQyMDAKPiAoWEVOKSBEb20wIGhhcyBtYXhp bXVtIDggVkNQVXMKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4KPiAo WEVOKSBYZW4gdHJhY2UgYnVmZmVyczogZGlzYWJsZWQKPiAoWEVOKSBTdGQuIExvZ2xldmVsOiBB bGwKPiAoWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCj4gKFhFTikgKioqIFNlcmlhbCBpbnB1dCAt PiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4p Cj4gKFhFTikgRnJlZWQgMjI4a0IgaW5pdCBtZW1vcnkuCj4gbWFwcGluZyBrZXJuZWwgaW50byBw aHlzaWNhbCBtZW1vcnkKPiBYZW46IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCj4gYWJvdXQgdG8g Z2V0IHN0YXJ0ZWQuLi4KPiBbICAgIDAuMDAwMDAwXSBDYW5ub3QgZmluZCAyMDQ4MCBieXRlcyBp biBub2RlIDEKPiBbICAgIDAuMDAwMDAwXSBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIE5V TEwgcG9pbnRlciBkZXJlZmVyZW5jZSBhdCAgICAgICAgICAgKG51bGwpCj4gWyAgICAwLjAwMDAw MF0gSVA6IFs8ZmZmZmZmZmY4MThkNTcwND5dIF9fYWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5 OQo+IFsgICAgMC4wMDAwMDBdIFBHRCAwIAo+IFsgICAgMC4wMDAwMDBdIE9vcHM6IDAwMDAgWyMx XSBQUkVFTVBUIFNNUCAKPiBbICAgIDAuMDAwMDAwXSBDUFUgMCAKPiBbICAgIDAuMDAwMDAwXSBN b2R1bGVzIGxpbmtlZCBpbjoKPiBbICAgIDAuMDAwMDAwXSAKPiBbICAgIDAuMDAwMDAwXSBQaWQ6 IDAsIGNvbW06IHN3YXBwZXIgTm90IHRhaW50ZWQgMy4zLjQtMi1BUkNIICMxIGVtcHR5IGVtcHR5 L1MzOTkyCj4gWyAgICAwLjAwMDAwMF0gUklQOiBlMDMwOls8ZmZmZmZmZmY4MThkNTcwND5dICBb PGZmZmZmZmZmODE4ZDU3MDQ+XSBfX2FsbG9jX2Jvb3RtZW1fbm9kZSsweDcyLzB4OTkKPiBbICAg IDAuMDAwMDAwXSBSU1A6IGUwMmI6ZmZmZmZmZmY4MTgwMWRlOCAgRUZMQUdTOiAwMDAxMDA0Ngo+ IFsgICAgMC4wMDAwMDBdIFJBWDogMDAwMDAwMDAwMDAwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAz NzggUkNYOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgICAwLjAwMDAwMF0gUkRYOiAwMDAwMDAwMDAw MDAwMDQwIFJTSTogMDAwMDAwMDAwMDAwMDM3OCBSREk6IDAwMDAwMDAwMDAwMDAwMDAKPiBbICAg IDAuMDAwMDAwXSBSQlA6IGZmZmZmZmZmODE4MDFlMDggUjA4OiAwMDAwMDAwMDAwMDAwMDAwIFIw OTogZmZmZmZmZmY4MTgwMWQ5OAo+IFsgICAgMC4wMDAwMDBdIFIxMDogZmZmZmZmZmY4MTgwMWQ4 OCBSMTE6IGZmZmZmZmZmODE4MDFkOTAgUjEyOiAwMDAwMDAwMDAwMDAwMDQwCj4gWyAgICAwLjAw MDAwMF0gUjEzOiAwMDAwMDAwMDAwMDAwMDAwIFIxNDogMDAwMDAwMDAwMDAwMDAwMCBSMTU6IDAw MDAwMDAwMDAwMDAwMDEKPiBbICAgIDAuMDAwMDAwXSBGUzogIDAwMDAwMDAwMDAwMDAwMDAoMDAw MCkgR1M6ZmZmZmZmZmY4MTg5ZjAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAwMDAwCj4gWyAg ICAwLjAwMDAwMF0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1 MDAzMwo+IFsgICAgMC4wMDAwMDBdIENSMjogMDAwMDAwMDAwMDAwMDAwMCBDUjM6IDAwMDAwMDAw MDE4MDUwMDAgQ1I0OiAwMDAwMDAwMDAwMDAwNjYwCj4gWyAgICAwLjAwMDAwMF0gRFIwOiAwMDAw MDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAwMDAwMDAwMDAwMDAwMDAK PiBbICAgIDAuMDAwMDAwXSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMDAwMDAw MDAwIERSNzogMDAwMDAwMDAwMDAwMDAwMAo+IFsgICAgMC4wMDAwMDBdIFByb2Nlc3Mgc3dhcHBl ciAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE4MDAwMDAsIHRhc2sgZmZmZmZmZmY4MTgw ZDAyMCkKPiBbICAgIDAuMDAwMDAwXSBTdGFjazoKPiBbICAgIDAuMDAwMDAwXSAgMDAwMDAwMDAw MDA4MDAwMCAwMDAwMDAwMDAwMDAwMzc4IDAwMDAwMDAwMDAwMDAwM2MgZmZmZjg4MDAzZmJmYTAw MAo+IFsgICAgMC4wMDAwMDBdICBmZmZmZmZmZjgxODAxZTY4IGZmZmZmZmZmODE4ZDYzZjAgZmZm ZmZmZmY4MTgwMWU0OCAwMDAwMDAwMTgxOGQ1M2JjCj4gWyAgICAwLjAwMDAwMF0gIGZmZmY4ODAw M2ZiZjlmZTAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAyODJjMDAwIGZmZmY4ODAwM2ZiZmEw MDAKPiBbICAgIDAuMDAwMDAwXSBDYWxsIFRyYWNlOgo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZm ZmZmODE4ZDYzZjA+XSBzcGFyc2VfZWFybHlfdXNlbWFwc19hbGxvY19ub2RlKzB4NjMvMHgxYzQK PiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGQ2NzdiPl0gc3BhcnNlX2luaXQrMHhmOC8w eDJjOAo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE4Y2E0ZDI+XSBwYWdpbmdfaW5pdCsw eDEzLzB4MjIKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI5ZGNhPl0gc2V0dXBfYXJj aCsweDlmMi8weGFjMAo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE0NTYyZDI+XSA/IHBy aW50aysweDQxLzB4NDMKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0OTFiPl0gc3Rh cnRfa2VybmVsKzB4ZDQvMHgzZDEKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0MzQ2 Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNQo+IFsgICAgMC4wMDAwMDBd ICBbPGZmZmZmZmZmODE4YjY5Yzk+XSB4ZW5fc3RhcnRfa2VybmVsKzB4NTk4LzB4NTlmCj4gWyAg ICAwLjAwMDAwMF0gQ29kZTogNGMgODkgZTkgNGMgODkgZTIgNDggODkgZGUgYmYgNDAgMDAgMDAg MDAgZTggMGYgZmMgZmYgZmYgZWIgMzQgNDEgOGIgOTYgYTAgNDAgMDAgMDAgYmUgMDAgODAgMDAg MDAgNDggODkgZGYgZTggMWUgMTEgODggZmYgZWIgMWUgPDQxPiA4YiBiZSBhMCA0MCAwMCAwMCA0 OSA4MyBjOCBmZiA0YyA4OSBlOSA0YyA4OSBlMiA0OCA4OSBkZSBlOCAKPiBbICAgIDAuMDAwMDAw XSBSSVAgIFs8ZmZmZmZmZmY4MThkNTcwND5dIF9fYWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5 OQo+IFsgICAgMC4wMDAwMDBdICBSU1AgPGZmZmZmZmZmODE4MDFkZTg+Cj4gWyAgICAwLjAwMDAw MF0gQ1IyOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgICAwLjAwMDAwMF0gLS0tWyBlbmQgdHJhY2Ug YTc5MTllN2YxN2MwYTcyNSBdLS0tCj4gWyAgICAwLjAwMDAwMF0gS2VybmVsIHBhbmljIC0gbm90 IHN5bmNpbmc6IEF0dGVtcHRlZCB0byBraWxsIHRoZSBpZGxlIHRhc2shCj4gKFhFTikgRG9tYWlu IDAgY3Jhc2hlZDogcmVib290aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgo+IAo+IAo+IFRoYW5r cyEKPiAKPiAKPiAtLSAKPiBTYW0gTXVsdmV5Cj4gVGFjb21hIFRlbGVtYXRpY3MKPiBzYW1AdGFj b21hdGVsZW1hdGljcy5jb20KPiAoMjUzKSA4ODMtMzAzMCB4MTEwCj4gCj4gCj4gCj4gCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2 ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMu eGVuLm9yZy94ZW4tZGV2ZWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Thu May 03 19:02:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 19: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 ) id 1SQ1IC-0007Hi-9n; Thu, 03 May 2012 19:02:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ1IB-0007Hd-E0 for xen-devel@lists.xen.org; Thu, 03 May 2012 19:02:19 +0000 Received: from [85.158.139.83:62288] by server-11.bemta-5.messagelabs.com id A6/A8-12959-A36D2AF4; Thu, 03 May 2012 19:02:18 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336071736!22704782!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMDYxNQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24505 invoked from network); 3 May 2012 19:02:17 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 19:02:17 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q43J2CFX031002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 19:02:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q43J2B7I021567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 19:02:12 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 q43J2Bvk011415; Thu, 3 May 2012 14:02:11 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 12:02:11 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A52834031D; Thu, 3 May 2012 14:56:29 -0400 (EDT) Date: Thu, 3 May 2012 14:56:29 -0400 From: Konrad Rzeszutek Wilk To: Sam Mulvey Message-ID: <20120503185629.GA4895@phenom.dumpdata.com> References: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: great.potato@gmail.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMTE6MDI6MDJBTSAtMDcwMCwgU2FtIE11bHZleSB3cm90 ZToKPiAKPiBPbiBNYXkgMywgMjAxMiwgYXQgMTA6MjQgQU0sIEtvbnJhZCBSemVzenV0ZWsgV2ls ayB3cm90ZToKPiA+IAo+ID4gVGhpcyBsb29rcyBsaWtlIGFuIEU4MjAgYWxpZ25tZW50IGlzc3Vl LiBDYW4geW91IHByb3ZpZGUgdGhlIGZ1bGwgc2VyaWFsIG91dHB1dCBwbGVhc2UuCj4gCj4gQ29t aW5nIHJpZ2h0IHVwIQoKSG0sIHRoZXJlIGlzIG5vdGhpbmcgaGVyZSB0aGF0IGxvb2tzIHdyb25n LCBwZXIgc2F5LiBJIHdvdWxkIHN1Z2dlc3QKeW91IGRvOiBkb20wX21lbT1tYXg6MUcgaW5zdGVh ZCBvZiBkb20wX21lbT0xRyAob3RoZXJ3aXNlIHlvdSBlbmQgdXAKaGF2aW5nIGRvbTAgY29udGFp biBwYWdlcyBmb3IgdGhlIGZ1bGwgMTNHQikuCgpCZXNpZGVzIHRoYXQsIGNhbiB5b3UgZG8gcmVk byB0aGlzIHdpdGggb24gTGludXggY29tbWFuZCBsaW5lIGJlOgoKJ2Vhcmx5cHJpbnRrPXhlbiBj b25zb2xlPWh2YzAgZGVidWcgbWVtYmxvY2s9ZGVidWcgbG9nbGV2ZWw9OCBpbml0Y2FsbF9kZWJ1 ZyIKCkFuZCBhZGQgb24gdGhlIFhlbiBsaW5lOiAic3luY19jb25zb2xlIi4KCkhvcGVmdWxseSB0 aGF0IHdpbGwgcHJvdmlkZSBzb21lIGlkZWEgb2Ygd2h5IHRoaXMgaXMgbm90IHdvcmtpbmcgcmln aHQuCgo+IAo+IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgXyAgIF9fX18gIAo+ICBcIFwvIC9f X18gXyBfXyAgIHwgfHwgfCAgLyB8IHxfX18gXCAKPiAgIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxf IHwgfCAgIF9fKSB8Cj4gICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3x8IHxfIC8gX18vIAo+ICAv Xy9cX1xfX198X3wgfF98ICAgIHxffChfKV8oXylfX19fX3wKPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCj4gKFhFTikgWGVuIHZlcnNpb24gNC4xLjIgKHNhbUBsb2NhbGRv bWFpbikgKGdjYyB2ZXJzaW9uIDQuNy4wIDIwMTIwNDE0IChwcmVyZWxlYXNlKSAoR0NDKSApIFdl ZCBNYXkgIDIgMTk6NTE6MjEgUERUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiB1bmF2 YWlsYWJsZQo+IChYRU4pIEJvb3Rsb2FkZXI6IEdOVSBHUlVCIDAuOTcKPiAoWEVOKSBDb21tYW5k IGxpbmU6IGRvbTBfbWVtPTFHIGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBjb20xPTExNTIw MCw4bjEgY29uc29sZT1jb20xCj4gKFhFTikgVmlkZW8gaW5mb3JtYXRpb246Cj4gKFhFTikgIFZH QSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgo+IChYRU4pICBWQkUvRERDIG1ldGhvZHM6 IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDIgc2Vjb25kcwo+IChYRU4pIERpc2MgaW5mb3JtYXRp b246Cj4gKFhFTikgIEZvdW5kIDMgTUJSIHNpZ25hdHVyZXMKPiAoWEVOKSAgRm91bmQgMyBFREQg aW5mb3JtYXRpb24gc3RydWN0dXJlcwo+IChYRU4pIFhlbi1lODIwIFJBTSBtYXA6Cj4gKFhFTikg IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlkMDAwICh1c2FibGUpCj4gKFhFTikgIDAw MDAwMDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAw MDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAw MDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBiZmZmMDAwMCAodXNhYmxlKQo+IChYRU4pICAwMDAwMDAw MGJmZmYwMDAwIC0gMDAwMDAwMDBiZmZmZTAwMCAoQUNQSSBkYXRhKQo+IChYRU4pICAwMDAwMDAw MGJmZmZlMDAwIC0gMDAwMDAwMDBjMDAwMDAwMCAoQUNQSSBOVlMpCj4gKFhFTikgIDAwMDAwMDAw ZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAzMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAwMDAwMDBm ZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMTAw MDAwMDAwIC0gMDAwMDAwMDM4MDAwMDAwMCAodXNhYmxlKQo+IChYRU4pIEFDUEk6IFJTRFAgMDAw RjgzQzAsIDAwMjQgKHIyIEFDUElBTSkKPiAoWEVOKSBBQ1BJOiBYU0RUIEJGRkYwMTAwLCAwMDRD IChyMSAwNzEwMDggWFNEVDA5NDggMjAwODA3MTAgTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBGQUNQIEJGRkYwMjkwLCAwMEY0IChyMyAwNzEwMDggRkFDUDA5NDggMjAwODA3MTAgTVNGVCAg ICAgICA5NykKPiAoWEVOKSBBQ1BJOiBEU0RUIEJGRkYwNEEwLCAzQjY4IChyMSAgMEFBQUEgMEFB QUEwMDAgICAgICAgIDAgSU5UTCAgMjAwMjAyNikKPiAoWEVOKSBBQ1BJOiBGQUNTIEJGRkZFMDAw LCAwMDQwCj4gKFhFTikgQUNQSTogQVBJQyBCRkZGMDM5MCwgMDBDQSAocjEgMDcxMDA4IEFQSUMw OTQ4IDIwMDgwNzEwIE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogTUNGRyBCRkZGMDQ2MCwg MDAzQyAocjEgMDcxMDA4IE9FTU1DRkcgIDIwMDgwNzEwIE1TRlQgICAgICAgOTcpCj4gKFhFTikg QUNQSTogT0VNQiBCRkZGRTA0MCwgMDA1NiAocjEgMDcxMDA4IE9FTUIwOTQ4IDIwMDgwNzEwIE1T RlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogU1JBVCBCRkZGNDAxMCwgMDE1MCAocjEgQU1EICAg IEhBTU1FUiAgICAgICAgICAxIEFNRCAgICAgICAgIDEpCj4gKFhFTikgU3lzdGVtIFJBTTogMTMz MTFNQiAoMTM2MzEwMjhrQikKPiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9kZSAw Cj4gKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMAo+IChYRU4pIFNSQVQ6IFBY TSAwIC0+IEFQSUMgMiAtPiBOb2RlIDAKPiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDMgLT4g Tm9kZSAwCj4gKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA0IC0+IE5vZGUgMQo+IChYRU4pIFNS QVQ6IFBYTSAxIC0+IEFQSUMgNSAtPiBOb2RlIDEKPiAoWEVOKSBTUkFUOiBQWE0gMSAtPiBBUElD IDYgLT4gTm9kZSAxCj4gKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA3IC0+IE5vZGUgMQo+IChY RU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAwLWEwMDAwCj4gKFhFTikgU1JBVDogTm9kZSAwIFBYTSAw IDEwMDAwMC1jMDAwMDAwMAo+IChYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMWUw MDAwMDAwCj4gKFhFTikgU1JBVDogTm9kZSAxIFBYTSAxIDFlMDAwMDAwMC0zODAwMDAwMDAKPiAo WEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDM3ZTVmNTAwMCAtIDM3ZTVmOTAw MAo+IChYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lgo+IChYRU4pIERvbWFp biBoZWFwIGluaXRpYWxpc2VkIERNQSB3aWR0aCAzMCBiaXRzCj4gKFhFTikgZm91bmQgU01QIE1Q LXRhYmxlIGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIDIuMyBwcmVzZW50Lgo+IChYRU4pIFVzaW5n IEFQSUMgZHJpdmVyIGRlZmF1bHQKPiAoWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDUw OAo+IChYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0xeF9jbnRbNTQ0LDUwNF0sIHBtMXhf ZXZ0WzU0MCw1MDBdCj4gKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3YWtldXBfdmVjW2Jm ZmZlMDBjXSwgdmVjX3NpemVbMjBdCj4gKFhFTikgQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4 ZmVlMDAwMDAKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAw XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMCAwOjIgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKPiAo WEVOKSBQcm9jZXNzb3IgIzEgMDoyIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICMyIDA6MiBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0 XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMyAwOjIgQVBJQyB2 ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw NF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzQgMDoyIEFQSUMgdmVyc2lvbiAxNgo+IChY RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4g KFhFTikgUHJvY2Vzc29yICM1IDA6MiBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDA2XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3Nv ciAjNiAwOjIgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw OF0gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzcgMDoyIEFQSUMg dmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAxXSBoaWdoIGVk Z2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBoaWdo IGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAzXSBo aWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA0 XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsw eDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDA2XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAoYWNw aV9pZFsweDA3XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IExBUElDX05NSSAo YWNwaV9pZFsweDA4XSBoaWdoIGVkZ2UgbGludFsweDFdKQo+IChYRU4pIEFDUEk6IElPQVBJQyAo aWRbMHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKPiAoWEVOKSBJT0FQSUNb MF06IGFwaWNfaWQgOCwgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0xNQo+ IChYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwOV0gYWRkcmVzc1sweGZlYzAxMDAwXSBnc2lfYmFz ZVsxNl0pCj4gKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDksIHZlcnNpb24gMTcsIGFkZHJlc3Mg MHhmZWMwMTAwMCwgR1NJIDE2LTMxCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDBhXSBhZGRy ZXNzWzB4ZmVjMDIwMDBdIGdzaV9iYXNlWzMyXSkKPiAoWEVOKSBJT0FQSUNbMl06IGFwaWNfaWQg MTAsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMjAwMCwgR1NJIDMyLTQ3Cj4gKFhFTikgQUNQ STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkKPiAo WEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2Vk IGJ5IG92ZXJyaWRlLgo+IChYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAz IEkvTyBBUElDcwo+IChYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAw MDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKPiAoWEVOKSBQQ0k6IE5vdCB1c2luZyBNTUNPTkZJ Ry4KPiAoWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCj4gKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkg Zm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uCj4gKFhFTikgSVJRIGxpbWl0czogNDgg R1NJLCAxNTA0IE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBT Y2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAyMjk0LjMwOCBNSHogcHJvY2Vzc29y Lgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZhbTEwaCBtYWNo aW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgQU1ELVZpOiBJT01NVSBub3QgZm91 bmQhCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCj4gKFhFTikgRU5BQkxJTkcg SU8tQVBJQyBJUlFzCj4gKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kCj4gKFhFTikgLi5U SU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQo+IChYRU4p IFBsYXRmb3JtIHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBlZCAxMCBv ciBtb3JlIHRpbWVzLgo+IChYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDMuNTc5TUh6IEFDUEkgUE0g VGltZXIKPiDLhyhYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgNjQgS2lCLgo+IChYRU4p IEhWTTogQVNJRHMgZW5hYmxlZC4KPiAoWEVOKSBTVk06IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0 dXJlczoKPiAoWEVOKSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkKPiAoWEVOKSAgLSBMYXN0 IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KPiAoWEVOKSBIVk06IFNWTSBlbmFi bGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgZGV0ZWN0ZWQuCj4gKFhF TikgQnJvdWdodCB1cCA4IENQVXMKPiAoWEVOKSBDUFVJRExFOiBkaXNhYmxlZCBkdWUgdG8gbm8g SFBFVC4gRm9yY2UgZW5hYmxlIHdpdGggJ2NwdWlkbGUnLgo+IChYRU4pIEFDUEkgc2xlZXAgbW9k ZXM6IFMzCj4gKFhFTikgTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5n IGZyZXF1ZW5jeQo+IChYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt ZXIgc3RhcnRlZC4KPiAoWEVOKSAqKiogTE9BRElORyBET01BSU4gMCAqKioKPiAoWEVOKSAgWGVu ICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgo+IChYRU4pICBEb20wIGtlcm5lbDogNjQt Yml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MWViODAwMAo+IChYRU4pIFBIWVNJ Q0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKPiAoWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDM3 MDAwMDAwMC0+MDAwMDAwMDM3NDAwMDAwMCAoMjQzMzQwIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkK PiAoWEVOKSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDM3ZjY4YzAwMC0+MDAwMDAwMDM3ZmZmZmUw MAo+IChYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBMb2FkZWQga2Vy bmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgxZWI4MDAwCj4gKFhFTikgIEluaXQuIHJh bWRpc2s6IGZmZmZmZmZmODFlYjgwMDAtPmZmZmZmZmZmODI4MmJlMDAKPiAoWEVOKSAgUGh5cy1N YWNoIG1hcDogZmZmZmZmZmY4MjgyYzAwMC0+ZmZmZmZmZmY4MmEyYzAwMAo+IChYRU4pICBTdGFy dCBpbmZvOiAgICBmZmZmZmZmZjgyYTJjMDAwLT5mZmZmZmZmZjgyYTJjNGI0Cj4gKFhFTikgIFBh Z2UgdGFibGVzOiAgIGZmZmZmZmZmODJhMmQwMDAtPmZmZmZmZmZmODJhNDYwMDAKPiAoWEVOKSAg Qm9vdCBzdGFjazogICAgZmZmZmZmZmY4MmE0NjAwMC0+ZmZmZmZmZmY4MmE0NzAwMAo+IChYRU4p ICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgyYzAwMDAwCj4gKFhF TikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODE4YjQyMDAKPiAoWEVOKSBEb20wIGhhcyBtYXhp bXVtIDggVkNQVXMKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4KPiAo WEVOKSBYZW4gdHJhY2UgYnVmZmVyczogZGlzYWJsZWQKPiAoWEVOKSBTdGQuIExvZ2xldmVsOiBB bGwKPiAoWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCj4gKFhFTikgKioqIFNlcmlhbCBpbnB1dCAt PiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4p Cj4gKFhFTikgRnJlZWQgMjI4a0IgaW5pdCBtZW1vcnkuCj4gbWFwcGluZyBrZXJuZWwgaW50byBw aHlzaWNhbCBtZW1vcnkKPiBYZW46IHNldHVwIElTQSBpZGVudGl0eSBtYXBzCj4gYWJvdXQgdG8g Z2V0IHN0YXJ0ZWQuLi4KPiBbICAgIDAuMDAwMDAwXSBDYW5ub3QgZmluZCAyMDQ4MCBieXRlcyBp biBub2RlIDEKPiBbICAgIDAuMDAwMDAwXSBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIE5V TEwgcG9pbnRlciBkZXJlZmVyZW5jZSBhdCAgICAgICAgICAgKG51bGwpCj4gWyAgICAwLjAwMDAw MF0gSVA6IFs8ZmZmZmZmZmY4MThkNTcwND5dIF9fYWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5 OQo+IFsgICAgMC4wMDAwMDBdIFBHRCAwIAo+IFsgICAgMC4wMDAwMDBdIE9vcHM6IDAwMDAgWyMx XSBQUkVFTVBUIFNNUCAKPiBbICAgIDAuMDAwMDAwXSBDUFUgMCAKPiBbICAgIDAuMDAwMDAwXSBN b2R1bGVzIGxpbmtlZCBpbjoKPiBbICAgIDAuMDAwMDAwXSAKPiBbICAgIDAuMDAwMDAwXSBQaWQ6 IDAsIGNvbW06IHN3YXBwZXIgTm90IHRhaW50ZWQgMy4zLjQtMi1BUkNIICMxIGVtcHR5IGVtcHR5 L1MzOTkyCj4gWyAgICAwLjAwMDAwMF0gUklQOiBlMDMwOls8ZmZmZmZmZmY4MThkNTcwND5dICBb PGZmZmZmZmZmODE4ZDU3MDQ+XSBfX2FsbG9jX2Jvb3RtZW1fbm9kZSsweDcyLzB4OTkKPiBbICAg IDAuMDAwMDAwXSBSU1A6IGUwMmI6ZmZmZmZmZmY4MTgwMWRlOCAgRUZMQUdTOiAwMDAxMDA0Ngo+ IFsgICAgMC4wMDAwMDBdIFJBWDogMDAwMDAwMDAwMDAwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDAz NzggUkNYOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgICAwLjAwMDAwMF0gUkRYOiAwMDAwMDAwMDAw MDAwMDQwIFJTSTogMDAwMDAwMDAwMDAwMDM3OCBSREk6IDAwMDAwMDAwMDAwMDAwMDAKPiBbICAg IDAuMDAwMDAwXSBSQlA6IGZmZmZmZmZmODE4MDFlMDggUjA4OiAwMDAwMDAwMDAwMDAwMDAwIFIw OTogZmZmZmZmZmY4MTgwMWQ5OAo+IFsgICAgMC4wMDAwMDBdIFIxMDogZmZmZmZmZmY4MTgwMWQ4 OCBSMTE6IGZmZmZmZmZmODE4MDFkOTAgUjEyOiAwMDAwMDAwMDAwMDAwMDQwCj4gWyAgICAwLjAw MDAwMF0gUjEzOiAwMDAwMDAwMDAwMDAwMDAwIFIxNDogMDAwMDAwMDAwMDAwMDAwMCBSMTU6IDAw MDAwMDAwMDAwMDAwMDEKPiBbICAgIDAuMDAwMDAwXSBGUzogIDAwMDAwMDAwMDAwMDAwMDAoMDAw MCkgR1M6ZmZmZmZmZmY4MTg5ZjAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAwMDAwCj4gWyAg ICAwLjAwMDAwMF0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1 MDAzMwo+IFsgICAgMC4wMDAwMDBdIENSMjogMDAwMDAwMDAwMDAwMDAwMCBDUjM6IDAwMDAwMDAw MDE4MDUwMDAgQ1I0OiAwMDAwMDAwMDAwMDAwNjYwCj4gWyAgICAwLjAwMDAwMF0gRFIwOiAwMDAw MDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAwMDAwMDAwMDAwMDAwMDAK PiBbICAgIDAuMDAwMDAwXSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMDAwMDAw MDAwIERSNzogMDAwMDAwMDAwMDAwMDAwMAo+IFsgICAgMC4wMDAwMDBdIFByb2Nlc3Mgc3dhcHBl ciAocGlkOiAwLCB0aHJlYWRpbmZvIGZmZmZmZmZmODE4MDAwMDAsIHRhc2sgZmZmZmZmZmY4MTgw ZDAyMCkKPiBbICAgIDAuMDAwMDAwXSBTdGFjazoKPiBbICAgIDAuMDAwMDAwXSAgMDAwMDAwMDAw MDA4MDAwMCAwMDAwMDAwMDAwMDAwMzc4IDAwMDAwMDAwMDAwMDAwM2MgZmZmZjg4MDAzZmJmYTAw MAo+IFsgICAgMC4wMDAwMDBdICBmZmZmZmZmZjgxODAxZTY4IGZmZmZmZmZmODE4ZDYzZjAgZmZm ZmZmZmY4MTgwMWU0OCAwMDAwMDAwMTgxOGQ1M2JjCj4gWyAgICAwLjAwMDAwMF0gIGZmZmY4ODAw M2ZiZjlmZTAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAyODJjMDAwIGZmZmY4ODAwM2ZiZmEw MDAKPiBbICAgIDAuMDAwMDAwXSBDYWxsIFRyYWNlOgo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZm ZmZmODE4ZDYzZjA+XSBzcGFyc2VfZWFybHlfdXNlbWFwc19hbGxvY19ub2RlKzB4NjMvMHgxYzQK PiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGQ2NzdiPl0gc3BhcnNlX2luaXQrMHhmOC8w eDJjOAo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE4Y2E0ZDI+XSBwYWdpbmdfaW5pdCsw eDEzLzB4MjIKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI5ZGNhPl0gc2V0dXBfYXJj aCsweDlmMi8weGFjMAo+IFsgICAgMC4wMDAwMDBdICBbPGZmZmZmZmZmODE0NTYyZDI+XSA/IHBy aW50aysweDQxLzB4NDMKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0OTFiPl0gc3Rh cnRfa2VybmVsKzB4ZDQvMHgzZDEKPiBbICAgIDAuMDAwMDAwXSAgWzxmZmZmZmZmZjgxOGI0MzQ2 Pl0geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNQo+IFsgICAgMC4wMDAwMDBd ICBbPGZmZmZmZmZmODE4YjY5Yzk+XSB4ZW5fc3RhcnRfa2VybmVsKzB4NTk4LzB4NTlmCj4gWyAg ICAwLjAwMDAwMF0gQ29kZTogNGMgODkgZTkgNGMgODkgZTIgNDggODkgZGUgYmYgNDAgMDAgMDAg MDAgZTggMGYgZmMgZmYgZmYgZWIgMzQgNDEgOGIgOTYgYTAgNDAgMDAgMDAgYmUgMDAgODAgMDAg MDAgNDggODkgZGYgZTggMWUgMTEgODggZmYgZWIgMWUgPDQxPiA4YiBiZSBhMCA0MCAwMCAwMCA0 OSA4MyBjOCBmZiA0YyA4OSBlOSA0YyA4OSBlMiA0OCA4OSBkZSBlOCAKPiBbICAgIDAuMDAwMDAw XSBSSVAgIFs8ZmZmZmZmZmY4MThkNTcwND5dIF9fYWxsb2NfYm9vdG1lbV9ub2RlKzB4NzIvMHg5 OQo+IFsgICAgMC4wMDAwMDBdICBSU1AgPGZmZmZmZmZmODE4MDFkZTg+Cj4gWyAgICAwLjAwMDAw MF0gQ1IyOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgICAwLjAwMDAwMF0gLS0tWyBlbmQgdHJhY2Ug YTc5MTllN2YxN2MwYTcyNSBdLS0tCj4gWyAgICAwLjAwMDAwMF0gS2VybmVsIHBhbmljIC0gbm90 IHN5bmNpbmc6IEF0dGVtcHRlZCB0byBraWxsIHRoZSBpZGxlIHRhc2shCj4gKFhFTikgRG9tYWlu IDAgY3Jhc2hlZDogcmVib290aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgo+IAo+IAo+IFRoYW5r cyEKPiAKPiAKPiAtLSAKPiBTYW0gTXVsdmV5Cj4gVGFjb21hIFRlbGVtYXRpY3MKPiBzYW1AdGFj b21hdGVsZW1hdGljcy5jb20KPiAoMjUzKSA4ODMtMzAzMCB4MTEwCj4gCj4gCj4gCj4gCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2 ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMu eGVuLm9yZy94ZW4tZGV2ZWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Thu May 03 19:35:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 19: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 ) id 1SQ1nl-0007bq-Bn; Thu, 03 May 2012 19:34:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ1nj-0007bl-TE for xen-devel@lists.xen.org; Thu, 03 May 2012 19:34:56 +0000 Received: from [85.158.138.51:48038] by server-2.bemta-3.messagelabs.com id 47/D1-09269-EDDD2AF4; Thu, 03 May 2012 19:34:54 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336073692!17197056!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21940 invoked from network); 3 May 2012 19:34:53 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 19:34:53 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id 2463210211FC9; Thu, 3 May 2012 12:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hDf4XGo1U2v; Thu, 3 May 2012 12:22:43 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id 5FE3C10211FC8; Thu, 3 May 2012 12:22:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: <20120503185629.GA4895@phenom.dumpdata.com> Date: Thu, 3 May 2012 12:34:49 -0700 Message-Id: <0C708620-3906-4AFF-BA31-E4F102731B84@tacomatelematics.com> References: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> <20120503185629.GA4895@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen-devel@lists.xen.org, great.potato@gmail.com Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5720188451857223844==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5720188451857223844== Content-Type: multipart/alternative; boundary=Apple-Mail-7--863279643 --Apple-Mail-7--863279643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2012, at 11:56 AM, Konrad Rzeszutek Wilk wrote: >=20 > Hm, there is nothing here that looks wrong, per say. I would suggest > you do: dom0_mem=3Dmax:1G instead of dom0_mem=3D1G (otherwise you end = up > having dom0 contain pages for the full 13GB). >=20 > Besides that, can you do redo this with on Linux command line be: >=20 > 'earlyprintk=3Dxen console=3Dhvc0 debug memblock=3Ddebug loglevel=3D8 = initcall_debug" >=20 > And add on the Xen line: "sync_console". >=20 > Hopefully that will provide some idea of why this is not working = right. It absolutely did. It wasn't working right because my brain is wrong. = Your boot flags reminded me that I was specifying my console output = incorrectly, trying to use the serial console directly rather than going = through hvc0. =20 Pardon me while I go soak my head. =20 Anyway, thanks for the help, and for the information about dom0 memory = allocation. I'm going to nap now. --=20 Sam Mulvey Tacoma Telematics sam@tacomatelematics.com (253) 883-3030 x110 --Apple-Mail-7--863279643 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hm, there is = nothing here that looks wrong, per say. I would suggest
you do: = dom0_mem=3Dmax:1G instead of dom0_mem=3D1G (otherwise you end = up
having dom0 contain pages for the full 13GB).

Besides that, = can you do redo this with on Linux command line = be:

'earlyprintk=3Dxen console=3Dhvc0 debug memblock=3Ddebug = loglevel=3D8 initcall_debug"

And add on the Xen line: = "sync_console".

Hopefully that will provide some idea of why this = is not working right.

It = absolutely did.  It wasn't working right because my brain is wrong. =   Your boot flags reminded me that I was specifying my console = output incorrectly, trying to use the serial console directly rather = than going through hvc0.   

Pardon me = while I go soak my head.  

Anyway, thanks = for the help, and for the information about dom0 memory allocation. =  I'm going to nap now.


-- 
Sam = Mulvey
Tacoma Telematics
sam@tacomatelematics.com
(= 253) 883-3030 = x110




= --Apple-Mail-7--863279643-- --===============5720188451857223844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5720188451857223844==-- From xen-devel-bounces@lists.xen.org Thu May 03 19:35:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 19: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 ) id 1SQ1nl-0007bq-Bn; Thu, 03 May 2012 19:34:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ1nj-0007bl-TE for xen-devel@lists.xen.org; Thu, 03 May 2012 19:34:56 +0000 Received: from [85.158.138.51:48038] by server-2.bemta-3.messagelabs.com id 47/D1-09269-EDDD2AF4; Thu, 03 May 2012 19:34:54 +0000 X-Env-Sender: sam@tacomatelematics.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336073692!17197056!1 X-Originating-IP: [173.160.255.210] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21940 invoked from network); 3 May 2012 19:34:53 -0000 Received: from tacomatelematics.com (HELO mail.tacomatelematics.com) (173.160.255.210) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2012 19:34:53 -0000 Received: from localhost (vac [127.0.0.1]) by mail.tacomatelematics.com (Postfix) with ESMTP id 2463210211FC9; Thu, 3 May 2012 12:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at tacomatelematics.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-500 required=2 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.tacomatelematics.com ([127.0.0.1]) by localhost (mail.tacomatelematics.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hDf4XGo1U2v; Thu, 3 May 2012 12:22:43 -0700 (PDT) Received: from smokescreen.nat.tact (173-160-255-209-Washington.hfc.comcastbusiness.net [173.160.255.209]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sam@tacomatelematics.com) by mail.tacomatelematics.com (Postfix) with ESMTPSA id 5FE3C10211FC8; Thu, 3 May 2012 12:22:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Sam Mulvey In-Reply-To: <20120503185629.GA4895@phenom.dumpdata.com> Date: Thu, 3 May 2012 12:34:49 -0700 Message-Id: <0C708620-3906-4AFF-BA31-E4F102731B84@tacomatelematics.com> References: <7A0AFCD2-6D24-4101-A82D-72CB76D7D287@tacomatelematics.com> <20120503172426.GF9992@phenom.dumpdata.com> <8C499CDB-0D01-4AAC-84C9-A3158449BE25@tacomatelematics.com> <20120503185629.GA4895@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen-devel@lists.xen.org, great.potato@gmail.com Subject: Re: [Xen-devel] Xen 4.2.1, Linux 3.3.4 kernel crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5720188451857223844==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5720188451857223844== Content-Type: multipart/alternative; boundary=Apple-Mail-7--863279643 --Apple-Mail-7--863279643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 3, 2012, at 11:56 AM, Konrad Rzeszutek Wilk wrote: >=20 > Hm, there is nothing here that looks wrong, per say. I would suggest > you do: dom0_mem=3Dmax:1G instead of dom0_mem=3D1G (otherwise you end = up > having dom0 contain pages for the full 13GB). >=20 > Besides that, can you do redo this with on Linux command line be: >=20 > 'earlyprintk=3Dxen console=3Dhvc0 debug memblock=3Ddebug loglevel=3D8 = initcall_debug" >=20 > And add on the Xen line: "sync_console". >=20 > Hopefully that will provide some idea of why this is not working = right. It absolutely did. It wasn't working right because my brain is wrong. = Your boot flags reminded me that I was specifying my console output = incorrectly, trying to use the serial console directly rather than going = through hvc0. =20 Pardon me while I go soak my head. =20 Anyway, thanks for the help, and for the information about dom0 memory = allocation. I'm going to nap now. --=20 Sam Mulvey Tacoma Telematics sam@tacomatelematics.com (253) 883-3030 x110 --Apple-Mail-7--863279643 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hm, there is = nothing here that looks wrong, per say. I would suggest
you do: = dom0_mem=3Dmax:1G instead of dom0_mem=3D1G (otherwise you end = up
having dom0 contain pages for the full 13GB).

Besides that, = can you do redo this with on Linux command line = be:

'earlyprintk=3Dxen console=3Dhvc0 debug memblock=3Ddebug = loglevel=3D8 initcall_debug"

And add on the Xen line: = "sync_console".

Hopefully that will provide some idea of why this = is not working right.

It = absolutely did.  It wasn't working right because my brain is wrong. =   Your boot flags reminded me that I was specifying my console = output incorrectly, trying to use the serial console directly rather = than going through hvc0.   

Pardon me = while I go soak my head.  

Anyway, thanks = for the help, and for the information about dom0 memory allocation. =  I'm going to nap now.


-- 
Sam = Mulvey
Tacoma Telematics
sam@tacomatelematics.com
(= 253) 883-3030 = x110




= --Apple-Mail-7--863279643-- --===============5720188451857223844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5720188451857223844==-- From xen-devel-bounces@lists.xen.org Thu May 03 23:52:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 23: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 ) id 1SQ5o9-0001Au-V2; Thu, 03 May 2012 23:51:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ5o8-0001Ap-Kk for xen-devel@lists.xensource.com; Thu, 03 May 2012 23:51:36 +0000 Received: from [85.158.143.99:10255] by server-2.bemta-4.messagelabs.com id 3E/83-17550-70A13AF4; Thu, 03 May 2012 23:51:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336089093!26395340!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19351 invoked from network); 3 May 2012 23:51:33 -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; 3 May 2012 23:51:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,528,1330905600"; d="scan'208";a="12286563" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 23:51: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, 4 May 2012 00:51:00 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQ5nY-0005VG-Q3; Thu, 03 May 2012 23:51:00 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQ5nY-0002RB-L6; Fri, 04 May 2012 00:51:00 +0100 To: Message-ID: From: xen.org Date: Fri, 4 May 2012 00:51:00 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12788: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12788 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12788/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12786 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail REGR. vs. 12786 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 8f556a70ae0b baseline version: xen 98fe3b2a572d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8f556a70ae0b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8f556a70ae0b + branch=xen-unstable + revision=8f556a70ae0b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8f556a70ae0b 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 03 23:52:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 May 2012 23: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 ) id 1SQ5o9-0001Au-V2; Thu, 03 May 2012 23:51:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ5o8-0001Ap-Kk for xen-devel@lists.xensource.com; Thu, 03 May 2012 23:51:36 +0000 Received: from [85.158.143.99:10255] by server-2.bemta-4.messagelabs.com id 3E/83-17550-70A13AF4; Thu, 03 May 2012 23:51:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336089093!26395340!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Njc3MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19351 invoked from network); 3 May 2012 23:51:33 -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; 3 May 2012 23:51:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,528,1330905600"; d="scan'208";a="12286563" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 May 2012 23:51: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, 4 May 2012 00:51:00 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQ5nY-0005VG-Q3; Thu, 03 May 2012 23:51:00 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQ5nY-0002RB-L6; Fri, 04 May 2012 00:51:00 +0100 To: Message-ID: From: xen.org Date: Fri, 4 May 2012 00:51:00 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12788: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12788 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12788/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12786 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail REGR. vs. 12786 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 8f556a70ae0b baseline version: xen 98fe3b2a572d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8f556a70ae0b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8f556a70ae0b + branch=xen-unstable + revision=8f556a70ae0b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8f556a70ae0b 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 00:32:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 00: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 ) id 1SQ6RX-0001sr-CT; Fri, 04 May 2012 00:32:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ6RV-0001sl-Tn for xen-devel@lists.xensource.com; Fri, 04 May 2012 00:32:18 +0000 Received: from [85.158.139.83:59369] by server-1.bemta-5.messagelabs.com id 53/0D-28458-19323AF4; Fri, 04 May 2012 00:32:17 +0000 X-Env-Sender: shandivo@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336091534!26000096!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22764 invoked from network); 4 May 2012 00:32:15 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 00:32:15 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQ6RR-0006kH-Qn for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:32:13 -0700 Date: Thu, 3 May 2012 17:32:13 -0700 (PDT) From: n4rC0t1C To: xen-devel@lists.xensource.com Message-ID: <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <4F7B66A3.3080802@amd.com> References: <4F7B66A3.3080802@amd.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Huang2, Wei wrote > > I just re-spin the patch, but haven't tested it yet. You want to try it > (attached)? Make sure you are using AMD GPU as the primary. > > -Wei > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > Works perfectly here. Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. Gfx passthrough=0, just install ati drivers with vnc, then reboot and monitors turn on with full 3D acceleration. I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, not a single bsod. Thanks everyone, Ivo -- View this message in context: http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611297p5684634.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 00:32:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 00: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 ) id 1SQ6RX-0001sr-CT; Fri, 04 May 2012 00:32:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ6RV-0001sl-Tn for xen-devel@lists.xensource.com; Fri, 04 May 2012 00:32:18 +0000 Received: from [85.158.139.83:59369] by server-1.bemta-5.messagelabs.com id 53/0D-28458-19323AF4; Fri, 04 May 2012 00:32:17 +0000 X-Env-Sender: shandivo@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336091534!26000096!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22764 invoked from network); 4 May 2012 00:32:15 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 00:32:15 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQ6RR-0006kH-Qn for xen-devel@lists.xensource.com; Thu, 03 May 2012 17:32:13 -0700 Date: Thu, 3 May 2012 17:32:13 -0700 (PDT) From: n4rC0t1C To: xen-devel@lists.xensource.com Message-ID: <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <4F7B66A3.3080802@amd.com> References: <4F7B66A3.3080802@amd.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Huang2, Wei wrote > > I just re-spin the patch, but haven't tested it yet. You want to try it > (attached)? Make sure you are using AMD GPU as the primary. > > -Wei > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > Works perfectly here. Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. Gfx passthrough=0, just install ati drivers with vnc, then reboot and monitors turn on with full 3D acceleration. I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, not a single bsod. Thanks everyone, Ivo -- View this message in context: http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611297p5684634.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 01:16:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 01: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 ) id 1SQ77C-00062f-Sl; Fri, 04 May 2012 01:15:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ77A-00062a-N3 for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:15:20 +0000 Received: from [85.158.138.51:47565] by server-3.bemta-3.messagelabs.com id 95/92-04048-6AD23AF4; Fri, 04 May 2012 01:15:18 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336094116!25032846!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4416 invoked from network); 4 May 2012 01:15:17 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 01:15:17 -0000 Received: by obfk16 with SMTP id k16so4428977obf.30 for ; Thu, 03 May 2012 18:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y2Z+XnCfeNrhEFPhsNehdyrYzoKzCPIqCmlZobSrD9w=; b=bX89NiwX11SV8Jeoc5lBQ2h7ysYnHkwAzwlURvwOgUr0hnic4VWDvDufrU8JLPIhGE WOIGQAs1SQ4qNaYUcJzis6rOJ2yWAMxjn0gXrPEaxdCyHFu3URYMtHIK/U8iIK82u0Vq l4AfDO329l+usSUTNAWxGnXBJYzqmtPPTS2e8HZEb9krm94JUTkV4asZkxDMSk4oe7VQ ZLs62UMVvognkhHIKFIupPZnVBwo2uE2VN1wnoxxiSbAY4uNiI9E+OIKrrywei1HEd5q Pdfq2gfdicwxYXU9MS1JLosskSBsR8OqEfCcn2wW8LiAmApZltK010LBAPeQsHiSwJTp +Zcw== MIME-Version: 1.0 Received: by 10.60.169.174 with SMTP id af14mr5864559oec.13.1336094115566; Thu, 03 May 2012 18:15:15 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 18:15:15 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Fri, 4 May 2012 09:15:15 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:56 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> >> > What do you mean by "disabling graphic"? Do you mean disabling the vga >> >> > card? >> >> No, not disable the vga card. >> >> But booting in Text mode. >> > >> > Then you are manually starting X11 with the spice driver? >> Always in text mode. >> Never start X11. >> Using stdard vga but not qxl-vga. > > so you didn't actually test qxl at all, did you? Didn't test qxl but only spice. -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 01:16:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 01: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 ) id 1SQ77C-00062f-Sl; Fri, 04 May 2012 01:15:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ77A-00062a-N3 for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:15:20 +0000 Received: from [85.158.138.51:47565] by server-3.bemta-3.messagelabs.com id 95/92-04048-6AD23AF4; Fri, 04 May 2012 01:15:18 +0000 X-Env-Sender: zpengxen@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336094116!25032846!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4416 invoked from network); 4 May 2012 01:15:17 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 01:15:17 -0000 Received: by obfk16 with SMTP id k16so4428977obf.30 for ; Thu, 03 May 2012 18:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y2Z+XnCfeNrhEFPhsNehdyrYzoKzCPIqCmlZobSrD9w=; b=bX89NiwX11SV8Jeoc5lBQ2h7ysYnHkwAzwlURvwOgUr0hnic4VWDvDufrU8JLPIhGE WOIGQAs1SQ4qNaYUcJzis6rOJ2yWAMxjn0gXrPEaxdCyHFu3URYMtHIK/U8iIK82u0Vq l4AfDO329l+usSUTNAWxGnXBJYzqmtPPTS2e8HZEb9krm94JUTkV4asZkxDMSk4oe7VQ ZLs62UMVvognkhHIKFIupPZnVBwo2uE2VN1wnoxxiSbAY4uNiI9E+OIKrrywei1HEd5q Pdfq2gfdicwxYXU9MS1JLosskSBsR8OqEfCcn2wW8LiAmApZltK010LBAPeQsHiSwJTp +Zcw== MIME-Version: 1.0 Received: by 10.60.169.174 with SMTP id af14mr5864559oec.13.1336094115566; Thu, 03 May 2012 18:15:15 -0700 (PDT) Received: by 10.182.77.134 with HTTP; Thu, 3 May 2012 18:15:15 -0700 (PDT) In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Date: Fri, 4 May 2012 09:15:15 +0800 Message-ID: From: ZhouPeng To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 3, 2012 at 9:56 PM, Stefano Stabellini wrote: > On Thu, 3 May 2012, ZhouPeng wrote: >> >> > What do you mean by "disabling graphic"? Do you mean disabling the vga >> >> > card? >> >> No, not disable the vga card. >> >> But booting in Text mode. >> > >> > Then you are manually starting X11 with the spice driver? >> Always in text mode. >> Never start X11. >> Using stdard vga but not qxl-vga. > > so you didn't actually test qxl at all, did you? Didn't test qxl but only spice. -- Zhou Peng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 02:11:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 02: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 ) id 1SQ7yn-0006jb-E6; Fri, 04 May 2012 02:10:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ7ym-0006jW-0C for Xen-devel@lists.xensource.com; Fri, 04 May 2012 02:10:44 +0000 Received: from [85.158.143.35:13603] by server-3.bemta-4.messagelabs.com id C3/05-05853-3AA33AF4; Fri, 04 May 2012 02:10:43 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336097440!7485045!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTQ4\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9107 invoked from network); 4 May 2012 02:10:41 -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; 4 May 2012 02:10:41 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q442AdQV031951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 May 2012 02:10:39 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q442AcG6027022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 May 2012 02:10:38 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 q442Ac4H031716 for ; Thu, 3 May 2012 21:10:38 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 19:10:37 -0700 Date: Thu, 3 May 2012 19:10:25 -0700 From: Mukesh Rathor To: "Xen-devel@lists.xensource.com" Message-ID: <20120503191025.7c2cec2e@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: ucsinet22.oracle.com [156.151.31.94] Subject: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi guys, At a loss trying to figure why if (has_eflag(X86_EFLAGS_ID)) returns false in my HVM domU. Standard function has_eflag() in cpucheck.c running in real mode. Works fine on PV dom0, but fails when guest is booting on my hybrid dom0. LMK if any ideas. I'll keep digging in the manuals, but nothing so far. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 02:11:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 02: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 ) id 1SQ7yn-0006jb-E6; Fri, 04 May 2012 02:10:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ7ym-0006jW-0C for Xen-devel@lists.xensource.com; Fri, 04 May 2012 02:10:44 +0000 Received: from [85.158.143.35:13603] by server-3.bemta-4.messagelabs.com id C3/05-05853-3AA33AF4; Fri, 04 May 2012 02:10:43 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336097440!7485045!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTQ4\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9107 invoked from network); 4 May 2012 02:10:41 -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; 4 May 2012 02:10:41 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q442AdQV031951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 May 2012 02:10:39 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q442AcG6027022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 May 2012 02:10:38 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 q442Ac4H031716 for ; Thu, 3 May 2012 21:10:38 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 May 2012 19:10:37 -0700 Date: Thu, 3 May 2012 19:10:25 -0700 From: Mukesh Rathor To: "Xen-devel@lists.xensource.com" Message-ID: <20120503191025.7c2cec2e@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: ucsinet22.oracle.com [156.151.31.94] Subject: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi guys, At a loss trying to figure why if (has_eflag(X86_EFLAGS_ID)) returns false in my HVM domU. Standard function has_eflag() in cpucheck.c running in real mode. Works fine on PV dom0, but fails when guest is booting on my hybrid dom0. LMK if any ideas. I'll keep digging in the manuals, but nothing so far. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 02:57:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 02:57:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ8hI-000714-6O; Fri, 04 May 2012 02:56:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ8hG-00070z-0M for xen-devel@lists.xensource.com; Fri, 04 May 2012 02:56:42 +0000 Received: from [193.109.254.147:63334] by server-6.bemta-14.messagelabs.com id DF/10-04960-96543AF4; Fri, 04 May 2012 02:56:41 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336100199!7543647!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI4NjYx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27331 invoked from network); 4 May 2012 02:56:40 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-27.messagelabs.com with SMTP; 4 May 2012 02:56:40 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 03 May 2012 19:56:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138722609" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 03 May 2012 19:56:38 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 May 2012 19:56:38 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Fri, 4 May 2012 10:56:36 +0800 From: "Zhang, Yang Z" To: "xen-devel@lists.xensource.com" Thread-Topic: [PATCH]libxl: allow to set more than 31 vcpus Thread-Index: Ac0poYSvmJALVq5wRuSA2SJW/RtHzw== Date: Fri, 4 May 2012 02:56:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User yang zhang # Date 1336099620 -28800 # Node ID b1229c22098499e677270d7b95ed0878347ac953 # Parent c6bde42c8845439183336602a78bc07869f3651b libxl: allow to set more than 31 vcpus In current implementation, it uses integer for record current avail cpus and this only allows user to specify 31 vcpus. In following patch, it uses cpumap instead interger which make more sense than before. Also there is no limit to the max vcpus. Signed-off-by: Yang Zhang diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_create.c Fri May 04 10:47:00 2012 +0800 @@ -112,8 +112,11 @@ int libxl__domain_build_info_setdefault( if (!b_info->max_vcpus) b_info->max_vcpus = 1; - if (!b_info->cur_vcpus) - b_info->cur_vcpus = 1; + if (!b_info->avail_vcpus.size) { + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) + return ERROR_NOMEM; + libxl_cpumap_set(&b_info->avail_vcpus, 0); + } if (!b_info->cpumap.size) { if (libxl_cpumap_alloc(CTX, &b_info->cpumap)) diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_dm.c Fri May 04 10:47:00 2012 +0800 @@ -200,10 +200,35 @@ static char ** libxl__build_device_model libxl__sprintf(gc, "%d", b_info->max_vcpus), NULL); } - if (b_info->cur_vcpus) { + if (b_info->avail_vcpus.size) { + int i, nr_set_cpus = 0; + char *s; + + libxl_for_each_set_cpu(i, + ((libxl_domain_build_info *)b_info)->avail_vcpus) + nr_set_cpus++; + + s = (char *)malloc((nr_set_cpus + 3) / 4 + 1); + + memset(s + ((nr_set_cpus % 4) ? 1 : 0), 'f', nr_set_cpus / 4); + switch (nr_set_cpus % 4) { + case 1: + s[0] = '1'; + break; + case 2: + s[0] = '3'; + break; + case 3: + s[0] = '7'; + break; + } + + s[(nr_set_cpus + 3) / 4] = '\0'; + flexarray_vappend(dm_args, "-vcpu_avail", - libxl__sprintf(gc, "0x%x", b_info->cur_vcpus), + libxl__sprintf(gc, "0x%s", s), NULL); + free(s); } for (i = 0; i < num_vifs; i++) { if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) { @@ -437,11 +462,16 @@ static char ** libxl__build_device_model } if (b_info->max_vcpus > 1) { flexarray_append(dm_args, "-smp"); - if (b_info->cur_vcpus) + if (b_info->avail_vcpus.size) { + int i, nr_set_cpus = 0; + libxl_for_each_set_cpu(i, + ((libxl_domain_build_info *)b_info)->avail_vcpus) + nr_set_cpus++; + flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", b_info->max_vcpus, - b_info->cur_vcpus)); - else + nr_set_cpus)); + } else flexarray_append(dm_args, libxl__sprintf(gc, "%d", b_info->max_vcpus)); } diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); for (i = 0; i < info->max_vcpus; i++) { ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i))) + ents[12+(i*2)+1] = (i && info->avail_vcpus.size + && !libxl_cpumap_test(&info->avail_vcpus, i)) ? "offline" : "online"; } @@ -297,7 +298,7 @@ static int hvm_build_set_params(xc_inter va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET); 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)); + memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size); for (i = 0, sum = 0; i < va_hvm->length; i++) sum += ((uint8_t *) va_hvm)[i]; va_hvm->checksum -= sum; diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_types.idl Fri May 04 10:47:00 2012 +0800 @@ -231,7 +231,7 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB # libxl_file_reference_unmap. libxl_domain_build_info = Struct("domain_build_info",[ ("max_vcpus", integer), - ("cur_vcpus", integer), + ("avail_vcpus", libxl_cpumap), ("cpumap", libxl_cpumap), ("tsc_mode", libxl_tsc_mode), ("max_memkb", MemKB), diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_utils.c Fri May 04 10:47:00 2012 +0800 @@ -447,6 +447,21 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l return 0; } +int libxl_cpumap_alloc_size(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus) +{ + int sz; + + if (max_cpus == 0) + return ERROR_FAIL; + + sz = (max_cpus + 7) / 8; + cpumap->map = calloc(sz, sizeof(*cpumap->map)); + if (!cpumap->map) + return ERROR_NOMEM; + cpumap->size = sz; + return 0; +} + void libxl_cpumap_dispose(libxl_cpumap *map) { free(map->map); diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_utils.h --- a/tools/libxl/libxl_utils.h Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_utils.h Fri May 04 10:47:00 2012 +0800 @@ -65,6 +65,7 @@ int libxl_vdev_to_device_disk(libxl_ctx libxl_device_disk *disk); int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap); +int libxl_cpumap_alloc_size(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus); 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); diff -r c6bde42c8845 -r b1229c220984 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 04 10:47:00 2012 +0800 @@ -589,7 +589,14 @@ static void parse_config_data(const char /* the following is the actual config parsing with overriding values in the structures */ if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) { b_info->max_vcpus = l; - b_info->cur_vcpus = (1 << l) - 1; + + if (libxl_cpumap_alloc_size(ctx, &b_info->avail_vcpus, l)) { + fprintf(stderr, "Unable to allocate cpumap\n"); + exit(1); + } + libxl_cpumap_set_none(&b_info->avail_vcpus); + while (l-- > 0) + libxl_cpumap_set((&b_info->avail_vcpus), l); } if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 02:57:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 02:57:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ8hI-000714-6O; Fri, 04 May 2012 02:56:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQ8hG-00070z-0M for xen-devel@lists.xensource.com; Fri, 04 May 2012 02:56:42 +0000 Received: from [193.109.254.147:63334] by server-6.bemta-14.messagelabs.com id DF/10-04960-96543AF4; Fri, 04 May 2012 02:56:41 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336100199!7543647!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI4NjYx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27331 invoked from network); 4 May 2012 02:56:40 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-27.messagelabs.com with SMTP; 4 May 2012 02:56:40 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 03 May 2012 19:56:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="138722609" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 03 May 2012 19:56:38 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 May 2012 19:56:38 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Fri, 4 May 2012 10:56:36 +0800 From: "Zhang, Yang Z" To: "xen-devel@lists.xensource.com" Thread-Topic: [PATCH]libxl: allow to set more than 31 vcpus Thread-Index: Ac0poYSvmJALVq5wRuSA2SJW/RtHzw== Date: Fri, 4 May 2012 02:56:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User yang zhang # Date 1336099620 -28800 # Node ID b1229c22098499e677270d7b95ed0878347ac953 # Parent c6bde42c8845439183336602a78bc07869f3651b libxl: allow to set more than 31 vcpus In current implementation, it uses integer for record current avail cpus and this only allows user to specify 31 vcpus. In following patch, it uses cpumap instead interger which make more sense than before. Also there is no limit to the max vcpus. Signed-off-by: Yang Zhang diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_create.c Fri May 04 10:47:00 2012 +0800 @@ -112,8 +112,11 @@ int libxl__domain_build_info_setdefault( if (!b_info->max_vcpus) b_info->max_vcpus = 1; - if (!b_info->cur_vcpus) - b_info->cur_vcpus = 1; + if (!b_info->avail_vcpus.size) { + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) + return ERROR_NOMEM; + libxl_cpumap_set(&b_info->avail_vcpus, 0); + } if (!b_info->cpumap.size) { if (libxl_cpumap_alloc(CTX, &b_info->cpumap)) diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dm.c --- a/tools/libxl/libxl_dm.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_dm.c Fri May 04 10:47:00 2012 +0800 @@ -200,10 +200,35 @@ static char ** libxl__build_device_model libxl__sprintf(gc, "%d", b_info->max_vcpus), NULL); } - if (b_info->cur_vcpus) { + if (b_info->avail_vcpus.size) { + int i, nr_set_cpus = 0; + char *s; + + libxl_for_each_set_cpu(i, + ((libxl_domain_build_info *)b_info)->avail_vcpus) + nr_set_cpus++; + + s = (char *)malloc((nr_set_cpus + 3) / 4 + 1); + + memset(s + ((nr_set_cpus % 4) ? 1 : 0), 'f', nr_set_cpus / 4); + switch (nr_set_cpus % 4) { + case 1: + s[0] = '1'; + break; + case 2: + s[0] = '3'; + break; + case 3: + s[0] = '7'; + break; + } + + s[(nr_set_cpus + 3) / 4] = '\0'; + flexarray_vappend(dm_args, "-vcpu_avail", - libxl__sprintf(gc, "0x%x", b_info->cur_vcpus), + libxl__sprintf(gc, "0x%s", s), NULL); + free(s); } for (i = 0; i < num_vifs; i++) { if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) { @@ -437,11 +462,16 @@ static char ** libxl__build_device_model } if (b_info->max_vcpus > 1) { flexarray_append(dm_args, "-smp"); - if (b_info->cur_vcpus) + if (b_info->avail_vcpus.size) { + int i, nr_set_cpus = 0; + libxl_for_each_set_cpu(i, + ((libxl_domain_build_info *)b_info)->avail_vcpus) + nr_set_cpus++; + flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", b_info->max_vcpus, - b_info->cur_vcpus)); - else + nr_set_cpus)); + } else flexarray_append(dm_args, libxl__sprintf(gc, "%d", b_info->max_vcpus)); } diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); for (i = 0; i < info->max_vcpus; i++) { ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i))) + ents[12+(i*2)+1] = (i && info->avail_vcpus.size + && !libxl_cpumap_test(&info->avail_vcpus, i)) ? "offline" : "online"; } @@ -297,7 +298,7 @@ static int hvm_build_set_params(xc_inter va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET); 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)); + memcpy(va_hvm->vcpu_online, info->avail_vcpus.map, info->avail_vcpus.size); for (i = 0, sum = 0; i < va_hvm->length; i++) sum += ((uint8_t *) va_hvm)[i]; va_hvm->checksum -= sum; diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_types.idl Fri May 04 10:47:00 2012 +0800 @@ -231,7 +231,7 @@ MemKB = UInt(64, init_val = "LIBXL_MEMKB # libxl_file_reference_unmap. libxl_domain_build_info = Struct("domain_build_info",[ ("max_vcpus", integer), - ("cur_vcpus", integer), + ("avail_vcpus", libxl_cpumap), ("cpumap", libxl_cpumap), ("tsc_mode", libxl_tsc_mode), ("max_memkb", MemKB), diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_utils.c --- a/tools/libxl/libxl_utils.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_utils.c Fri May 04 10:47:00 2012 +0800 @@ -447,6 +447,21 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l return 0; } +int libxl_cpumap_alloc_size(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus) +{ + int sz; + + if (max_cpus == 0) + return ERROR_FAIL; + + sz = (max_cpus + 7) / 8; + cpumap->map = calloc(sz, sizeof(*cpumap->map)); + if (!cpumap->map) + return ERROR_NOMEM; + cpumap->size = sz; + return 0; +} + void libxl_cpumap_dispose(libxl_cpumap *map) { free(map->map); diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_utils.h --- a/tools/libxl/libxl_utils.h Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/libxl_utils.h Fri May 04 10:47:00 2012 +0800 @@ -65,6 +65,7 @@ int libxl_vdev_to_device_disk(libxl_ctx libxl_device_disk *disk); int libxl_cpumap_alloc(libxl_ctx *ctx, libxl_cpumap *cpumap); +int libxl_cpumap_alloc_size(libxl_ctx *ctx, libxl_cpumap *cpumap, int max_cpus); 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); diff -r c6bde42c8845 -r b1229c220984 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu Apr 12 14:01:27 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 04 10:47:00 2012 +0800 @@ -589,7 +589,14 @@ static void parse_config_data(const char /* the following is the actual config parsing with overriding values in the structures */ if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) { b_info->max_vcpus = l; - b_info->cur_vcpus = (1 << l) - 1; + + if (libxl_cpumap_alloc_size(ctx, &b_info->avail_vcpus, l)) { + fprintf(stderr, "Unable to allocate cpumap\n"); + exit(1); + } + libxl_cpumap_set_none(&b_info->avail_vcpus); + while (l-- > 0) + libxl_cpumap_set((&b_info->avail_vcpus), l); } if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 06:39:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 06: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 ) id 1SQC9p-00006L-Q4; Fri, 04 May 2012 06:38:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQC9n-00006G-Gh for xen-devel@lists.xensource.com; Fri, 04 May 2012 06:38:23 +0000 Received: from [193.109.254.147:10217] by server-1.bemta-14.messagelabs.com id ED/93-29372-E5973AF4; Fri, 04 May 2012 06:38:22 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336113501!769303!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9241 invoked from network); 4 May 2012 06:38:22 -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; 4 May 2012 06:38:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12289286" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 06:38: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, 4 May 2012 07:38:21 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQC9l-0007pY-9F; Fri, 04 May 2012 06:38:21 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQC9l-0000G5-58; Fri, 04 May 2012 07:38:21 +0100 To: Message-ID: From: xen.org Date: Fri, 4 May 2012 07:38:21 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12789: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12789 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12789/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12788 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 8f556a70ae0b baseline version: xen 8f556a70ae0b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 06:39:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 06: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 ) id 1SQC9p-00006L-Q4; Fri, 04 May 2012 06:38:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQC9n-00006G-Gh for xen-devel@lists.xensource.com; Fri, 04 May 2012 06:38:23 +0000 Received: from [193.109.254.147:10217] by server-1.bemta-14.messagelabs.com id ED/93-29372-E5973AF4; Fri, 04 May 2012 06:38:22 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336113501!769303!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9241 invoked from network); 4 May 2012 06:38:22 -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; 4 May 2012 06:38:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12289286" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 06:38: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, 4 May 2012 07:38:21 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQC9l-0007pY-9F; Fri, 04 May 2012 06:38:21 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQC9l-0000G5-58; Fri, 04 May 2012 07:38:21 +0100 To: Message-ID: From: xen.org Date: Fri, 4 May 2012 07:38:21 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12789: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12789 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12789/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12788 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass version targeted for testing: xen 8f556a70ae0b baseline version: xen 8f556a70ae0b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:10:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:10:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCdt-0000Tv-VS; Fri, 04 May 2012 07:09:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCdr-0000Tq-Px for xen-devel@lists.xen.org; Fri, 04 May 2012 07:09:27 +0000 Received: from [85.158.143.99:19752] by server-2.bemta-4.messagelabs.com id 21/D9-17550-7A083AF4; Fri, 04 May 2012 07:09:27 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336115365!23076538!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12057 invoked from network); 4 May 2012 07:09:25 -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; 4 May 2012 07:09:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:09:24 +0100 Message-Id: <4FA39CC202000078000817FD@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:09:22 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <4FA2C94802000078000816E3@nat28.tlf.novell.com> <20120503172211.GE9992@phenom.dumpdata.com> In-Reply-To: <20120503172211.GE9992@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 19:22, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 05:07:04PM +0100, Jan Beulich wrote: >> Both Linux and Xen offer only ways to set the IOPL. While on native Linux >> this is not a problem since user mode code can read the IOPL by inspecting >> EFLAGS, on Xen this would always yield zero. >> >> Now X folks appear to be using save-modify-restore cycles in some newer >> code, and this obviously breaks under Xen, as they would restore IOPL 0 > > This is in the KMS drivers or in the user-land Xorg? Userland code (as explained above). Jan >> even when IOPL 3 was in effect before. >> >> Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. >> XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add >> e.g. a "get" counterpart to PHYSDEVOP_set_iopl. >> >> Or am I overlooking some other access mechanism? >> >> Jan >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:10:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:10:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCdt-0000Tv-VS; Fri, 04 May 2012 07:09:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCdr-0000Tq-Px for xen-devel@lists.xen.org; Fri, 04 May 2012 07:09:27 +0000 Received: from [85.158.143.99:19752] by server-2.bemta-4.messagelabs.com id 21/D9-17550-7A083AF4; Fri, 04 May 2012 07:09:27 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336115365!23076538!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12057 invoked from network); 4 May 2012 07:09:25 -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; 4 May 2012 07:09:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:09:24 +0100 Message-Id: <4FA39CC202000078000817FD@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:09:22 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <4FA2C94802000078000816E3@nat28.tlf.novell.com> <20120503172211.GE9992@phenom.dumpdata.com> In-Reply-To: <20120503172211.GE9992@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] reading IOPL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 19:22, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 05:07:04PM +0100, Jan Beulich wrote: >> Both Linux and Xen offer only ways to set the IOPL. While on native Linux >> this is not a problem since user mode code can read the IOPL by inspecting >> EFLAGS, on Xen this would always yield zero. >> >> Now X folks appear to be using save-modify-restore cycles in some newer >> code, and this obviously breaks under Xen, as they would restore IOPL 0 > > This is in the KMS drivers or in the user-land Xorg? Userland code (as explained above). Jan >> even when IOPL 3 was in effect before. >> >> Since the only way to read the IOPL is xc_vcpu_getcontext() (i.e. >> XEN_DOMCTL_getvcpucontext), I wonder whether we shouldn't add >> e.g. a "get" counterpart to PHYSDEVOP_set_iopl. >> >> Or am I overlooking some other access mechanism? >> >> Jan >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:29:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07: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 ) id 1SQCwP-0000i5-TJ; Fri, 04 May 2012 07:28:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCwN-0000i0-QB for xen-devel@lists.xen.org; Fri, 04 May 2012 07:28:35 +0000 Received: from [85.158.138.51:36465] by server-10.bemta-3.messagelabs.com id C8/F9-29478-22583AF4; Fri, 04 May 2012 07:28:34 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336116513!17267448!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21168 invoked from network); 4 May 2012 07:28:34 -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; 4 May 2012 07:28:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:28:33 +0100 Message-Id: <4FA3A1400200007800081808@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:28:32 +0100 From: "Jan Beulich" To: "Ruslan Nikolaev" References: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> In-Reply-To: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 20:46, Ruslan Nikolaev wrote: > I want to set up an inter-domain event channel, and I want to receive > interrupts in both directions (i.e. Dom1 can independently send an interrupt > to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and > the other one on Dom 2, and on each domain I simply bind it to the > corresponding interrupt handler? Or do I need to have 4 ports: one pair is > used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? One port on each end should suffice. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:29:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07: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 ) id 1SQCwP-0000i5-TJ; Fri, 04 May 2012 07:28:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQCwN-0000i0-QB for xen-devel@lists.xen.org; Fri, 04 May 2012 07:28:35 +0000 Received: from [85.158.138.51:36465] by server-10.bemta-3.messagelabs.com id C8/F9-29478-22583AF4; Fri, 04 May 2012 07:28:34 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336116513!17267448!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21168 invoked from network); 4 May 2012 07:28:34 -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; 4 May 2012 07:28:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:28:33 +0100 Message-Id: <4FA3A1400200007800081808@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:28:32 +0100 From: "Jan Beulich" To: "Ruslan Nikolaev" References: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> In-Reply-To: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.05.12 at 20:46, Ruslan Nikolaev wrote: > I want to set up an inter-domain event channel, and I want to receive > interrupts in both directions (i.e. Dom1 can independently send an interrupt > to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and > the other one on Dom 2, and on each domain I simply bind it to the > corresponding interrupt handler? Or do I need to have 4 ports: one pair is > used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? One port on each end should suffice. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07: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 ) id 1SQDBL-0000wa-CM; Fri, 04 May 2012 07:44:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDBJ-0000wV-Vj for xen-devel@lists.xen.org; Fri, 04 May 2012 07:44:02 +0000 Received: from [85.158.139.83:59133] by server-7.bemta-5.messagelabs.com id D5/03-16195-0C883AF4; Fri, 04 May 2012 07:44:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336117440!26643431!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30848 invoked from network); 4 May 2012 07:44:00 -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; 4 May 2012 07:44:00 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:43:59 +0100 Message-Id: <4FA3A4DE020000780008181A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:43:58 +0100 From: "Jan Beulich" To: "Mukesh Rathor" References: <20120503191025.7c2cec2e@mantra.us.oracle.com> In-Reply-To: <20120503191025.7c2cec2e@mantra.us.oracle.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 04:10, Mukesh Rathor wrote: > At a loss trying to figure why > if (has_eflag(X86_EFLAGS_ID)) > > returns false in my HVM domU. Standard function has_eflag() in > cpucheck.c running in real mode. Works fine on PV dom0, How that? This is 16-bit code. If called with a 32-bit code segment (I'm not aware of PV setting up any 16-bit segments), it'll be touching only the low 16 bits of all operands (as the operand size prefixes all these instructions have will have inverted meaning). > but fails when guest is booting on my hybrid dom0. Unless PV works because you made this 32-bit code (and you call this in a 16-bit code segment in your hybrid), I can't make other suggestions. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07: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 ) id 1SQDBL-0000wa-CM; Fri, 04 May 2012 07:44:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDBJ-0000wV-Vj for xen-devel@lists.xen.org; Fri, 04 May 2012 07:44:02 +0000 Received: from [85.158.139.83:59133] by server-7.bemta-5.messagelabs.com id D5/03-16195-0C883AF4; Fri, 04 May 2012 07:44:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336117440!26643431!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30848 invoked from network); 4 May 2012 07:44:00 -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; 4 May 2012 07:44:00 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 08:43:59 +0100 Message-Id: <4FA3A4DE020000780008181A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 08:43:58 +0100 From: "Jan Beulich" To: "Mukesh Rathor" References: <20120503191025.7c2cec2e@mantra.us.oracle.com> In-Reply-To: <20120503191025.7c2cec2e@mantra.us.oracle.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 04:10, Mukesh Rathor wrote: > At a loss trying to figure why > if (has_eflag(X86_EFLAGS_ID)) > > returns false in my HVM domU. Standard function has_eflag() in > cpucheck.c running in real mode. Works fine on PV dom0, How that? This is 16-bit code. If called with a 32-bit code segment (I'm not aware of PV setting up any 16-bit segments), it'll be touching only the low 16 bits of all operands (as the operand size prefixes all these instructions have will have inverted meaning). > but fails when guest is booting on my hybrid dom0. Unless PV works because you made this 32-bit code (and you call this in a 16-bit code segment in your hybrid), I can't make other suggestions. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:50:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:50:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDGc-00014K-4T; Fri, 04 May 2012 07:49:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDGa-00014E-UQ for xen-devel@lists.xensource.com; Fri, 04 May 2012 07:49:29 +0000 Received: from [85.158.143.35:53458] by server-2.bemta-4.messagelabs.com id 85/54-17550-80A83AF4; Fri, 04 May 2012 07:49:28 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336117765!11503172!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjczODg3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28531 invoked from network); 4 May 2012 07:49:26 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-16.tower-21.messagelabs.com with SMTP; 4 May 2012 07:49:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 04 May 2012 00:49:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96300356" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 04 May 2012 00:49:24 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 May 2012 00:49:23 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Fri, 4 May 2012 15:49:21 +0800 From: "Hao, Xudong" To: "konrad.wilk@oracle.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSQ== Date: Fri, 4 May 2012 07:49:21 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted. Changes from v1: - put the variable definition at the start of function - add error log report Signed-off-by: Xudong Hao diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 097e536..74fbf23 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) struct xen_pcibk_dev_data *dev_data; int err = 0; + /* set default value */ + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; + dev_dbg(&dev->dev, "initializing...\n"); /* The PCI backend is not intended to be a module (or to work with @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) dev_dbg(&dev->dev, "reset device\n"); xen_pcibk_reset_device(dev); + /* Enable LTR and OBFF before do device assignment */ + /* LTR(Latency tolerance reporting) allows devices to send + * messages to the root complex indicating their latency tolerance + * for snooped & unsnooped memory transactions. + */ + err = pci_enable_ltr(dev); + if (err) + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); + + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); + if (err) + dev_err(&dev->dev, "Set LTR latency values failed.\n"); + + /* OBFF (optimized buffer flush/fill), where supported, can help + * improve energy efficiency by giving devices information about + * when interrupts and other activity will have a reduced power + * impact. + */ + err = pci_enable_obff(dev, type); + if (err) + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); + dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:50:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:50:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDGc-00014K-4T; Fri, 04 May 2012 07:49:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDGa-00014E-UQ for xen-devel@lists.xensource.com; Fri, 04 May 2012 07:49:29 +0000 Received: from [85.158.143.35:53458] by server-2.bemta-4.messagelabs.com id 85/54-17550-80A83AF4; Fri, 04 May 2012 07:49:28 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336117765!11503172!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjczODg3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28531 invoked from network); 4 May 2012 07:49:26 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-16.tower-21.messagelabs.com with SMTP; 4 May 2012 07:49:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 04 May 2012 00:49:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96300356" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 04 May 2012 00:49:24 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 May 2012 00:49:23 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Fri, 4 May 2012 15:49:21 +0800 From: "Hao, Xudong" To: "konrad.wilk@oracle.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSQ== Date: Fri, 4 May 2012 07:49:21 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted. Changes from v1: - put the variable definition at the start of function - add error log report Signed-off-by: Xudong Hao diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 097e536..74fbf23 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) struct xen_pcibk_dev_data *dev_data; int err = 0; + /* set default value */ + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; + dev_dbg(&dev->dev, "initializing...\n"); /* The PCI backend is not intended to be a module (or to work with @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) dev_dbg(&dev->dev, "reset device\n"); xen_pcibk_reset_device(dev); + /* Enable LTR and OBFF before do device assignment */ + /* LTR(Latency tolerance reporting) allows devices to send + * messages to the root complex indicating their latency tolerance + * for snooped & unsnooped memory transactions. + */ + err = pci_enable_ltr(dev); + if (err) + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); + + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); + if (err) + dev_err(&dev->dev, "Set LTR latency values failed.\n"); + + /* OBFF (optimized buffer flush/fill), where supported, can help + * improve energy efficiency by giving devices information about + * when interrupts and other activity will have a reduced power + * impact. + */ + err = pci_enable_obff(dev, type); + if (err) + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); + dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:57:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:57:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNW-0001EP-0V; Fri, 04 May 2012 07:56:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNV-0001EK-0k for xen-devel@lists.xen.org; Fri, 04 May 2012 07:56:37 +0000 Received: from [85.158.138.51:29789] by server-6.bemta-3.messagelabs.com id 37/C4-05145-4BB83AF4; Fri, 04 May 2012 07:56:36 +0000 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-15.tower-174.messagelabs.com!1336118195!23402589!1 X-Originating-IP: [78.47.43.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5640 invoked from network); 4 May 2012 07:56:35 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-15.tower-174.messagelabs.com with SMTP; 4 May 2012 07:56:35 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id DB2DDD3462F; Fri, 4 May 2012 09:56:34 +0200 (CEST) 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 Re-FooenUwGy; Fri, 4 May 2012 09:56:30 +0200 (CEST) Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 40AD9D3472C; Fri, 4 May 2012 09:56:26 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 09:56:24 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <4F7B66A3.3080802@amd.com> <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <1336091533825-5684634.post@n5.nabble.com> MIME-Version: 1.0 Message-Id: <201205040956.25283.tobias.geiger@vido.info> Cc: n4rC0t1C , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am Freitag, 4. Mai 2012, 02:32:13 schrieb n4rC0t1C: > Huang2, Wei wrote > > > I just re-spin the patch, but haven't tested it yet. You want to try it > > (attached)? Make sure you are using AMD GPU as the primary. > > > > -Wei > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > Works perfectly here. > Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. > Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. > Gfx passthrough=0, just install ati drivers with vnc, then reboot and > monitors turn on with full 3D acceleration. > if i understand this patch and the gfx_passthrough parameter right, you don't need this patch for this scenario: with gfx_passthrough=0 this patch does not what its intended to do, i.e. "declare" itself as the primary gpu within the DomU which would mean you could also see early boot messages and windows start screen on the monitor of the passed-through gpu (a feature i not really need). Greetings Tobias > I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, > not a single bsod. > Thanks everyone, > Ivo > > > -- > View this message in context: > http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611 > 297p5684634.html Sent from the Xen - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:57:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:57:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNW-0001EP-0V; Fri, 04 May 2012 07:56:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNV-0001EK-0k for xen-devel@lists.xen.org; Fri, 04 May 2012 07:56:37 +0000 Received: from [85.158.138.51:29789] by server-6.bemta-3.messagelabs.com id 37/C4-05145-4BB83AF4; Fri, 04 May 2012 07:56:36 +0000 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-15.tower-174.messagelabs.com!1336118195!23402589!1 X-Originating-IP: [78.47.43.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5640 invoked from network); 4 May 2012 07:56:35 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-15.tower-174.messagelabs.com with SMTP; 4 May 2012 07:56:35 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id DB2DDD3462F; Fri, 4 May 2012 09:56:34 +0200 (CEST) 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 Re-FooenUwGy; Fri, 4 May 2012 09:56:30 +0200 (CEST) Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 40AD9D3472C; Fri, 4 May 2012 09:56:26 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 09:56:24 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <4F7B66A3.3080802@amd.com> <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <1336091533825-5684634.post@n5.nabble.com> MIME-Version: 1.0 Message-Id: <201205040956.25283.tobias.geiger@vido.info> Cc: n4rC0t1C , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am Freitag, 4. Mai 2012, 02:32:13 schrieb n4rC0t1C: > Huang2, Wei wrote > > > I just re-spin the patch, but haven't tested it yet. You want to try it > > (attached)? Make sure you are using AMD GPU as the primary. > > > > -Wei > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > Works perfectly here. > Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. > Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. > Gfx passthrough=0, just install ati drivers with vnc, then reboot and > monitors turn on with full 3D acceleration. > if i understand this patch and the gfx_passthrough parameter right, you don't need this patch for this scenario: with gfx_passthrough=0 this patch does not what its intended to do, i.e. "declare" itself as the primary gpu within the DomU which would mean you could also see early boot messages and windows start screen on the monitor of the passed-through gpu (a feature i not really need). Greetings Tobias > I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, > not a single bsod. > Thanks everyone, > Ivo > > > -- > View this message in context: > http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611 > 297p5684634.html Sent from the Xen - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:57:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:57:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNa-0001Ek-CX; Fri, 04 May 2012 07:56:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNY-0001EZ-Cv for xen-devel@lists.xensource.com; Fri, 04 May 2012 07:56:40 +0000 Received: from [85.158.143.35:24884] by server-2.bemta-4.messagelabs.com id 5F/3C-17550-7BB83AF4; Fri, 04 May 2012 07:56:39 +0000 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-4.tower-21.messagelabs.com!1336118195!9759473!1 X-Originating-IP: [78.47.43.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7077 invoked from network); 4 May 2012 07:56:35 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-4.tower-21.messagelabs.com with SMTP; 4 May 2012 07:56:35 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id DB2DDD3462F; Fri, 4 May 2012 09:56:34 +0200 (CEST) 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 Re-FooenUwGy; Fri, 4 May 2012 09:56:30 +0200 (CEST) Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 40AD9D3472C; Fri, 4 May 2012 09:56:26 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 09:56:24 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <4F7B66A3.3080802@amd.com> <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <1336091533825-5684634.post@n5.nabble.com> MIME-Version: 1.0 Message-Id: <201205040956.25283.tobias.geiger@vido.info> Cc: n4rC0t1C , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am Freitag, 4. Mai 2012, 02:32:13 schrieb n4rC0t1C: > Huang2, Wei wrote > > > I just re-spin the patch, but haven't tested it yet. You want to try it > > (attached)? Make sure you are using AMD GPU as the primary. > > > > -Wei > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > Works perfectly here. > Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. > Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. > Gfx passthrough=0, just install ati drivers with vnc, then reboot and > monitors turn on with full 3D acceleration. > if i understand this patch and the gfx_passthrough parameter right, you don't need this patch for this scenario: with gfx_passthrough=0 this patch does not what its intended to do, i.e. "declare" itself as the primary gpu within the DomU which would mean you could also see early boot messages and windows start screen on the monitor of the passed-through gpu (a feature i not really need). Greetings Tobias > I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, > not a single bsod. > Thanks everyone, > Ivo > > > -- > View this message in context: > http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611 > 297p5684634.html Sent from the Xen - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 07:57:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 07:57:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNa-0001Ek-CX; Fri, 04 May 2012 07:56:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDNY-0001EZ-Cv for xen-devel@lists.xensource.com; Fri, 04 May 2012 07:56:40 +0000 Received: from [85.158.143.35:24884] by server-2.bemta-4.messagelabs.com id 5F/3C-17550-7BB83AF4; Fri, 04 May 2012 07:56:39 +0000 X-Env-Sender: tobias.geiger@vido.info X-Msg-Ref: server-4.tower-21.messagelabs.com!1336118195!9759473!1 X-Originating-IP: [78.47.43.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7077 invoked from network); 4 May 2012 07:56:35 -0000 Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171) by server-4.tower-21.messagelabs.com with SMTP; 4 May 2012 07:56:35 -0000 Received: from localhost (ip6-localhost [127.0.0.1]) by mail.vido.info (Postfix) with ESMTP id DB2DDD3462F; Fri, 4 May 2012 09:56:34 +0200 (CEST) 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 Re-FooenUwGy; Fri, 4 May 2012 09:56:30 +0200 (CEST) Received: from lxgeigert.localnet (et-0-10.gw-nat.bs.kae.de.oneandone.net [212.227.35.74]) by mail.vido.info (Postfix) with ESMTPSA id 40AD9D3472C; Fri, 4 May 2012 09:56:26 +0200 (CEST) From: Tobias Geiger Organization: VIDO IT-Service To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 09:56:24 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <4F7B66A3.3080802@amd.com> <1336091533825-5684634.post@n5.nabble.com> In-Reply-To: <1336091533825-5684634.post@n5.nabble.com> MIME-Version: 1.0 Message-Id: <201205040956.25283.tobias.geiger@vido.info> Cc: n4rC0t1C , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] AMD/ATI patch for xen 4.2-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am Freitag, 4. Mai 2012, 02:32:13 schrieb n4rC0t1C: > Huang2, Wei wrote > > > I just re-spin the patch, but haven't tested it yet. You want to try it > > (attached)? Make sure you are using AMD GPU as the primary. > > > > -Wei > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > Works perfectly here. > Intel i5-2500, Asrock z68 Extreme4 Gen3, AMD 6870 as primary. > Xen Unstable 25254, Ubuntu 12.04, ubuntu 3.3.3 kernel. > Gfx passthrough=0, just install ati drivers with vnc, then reboot and > monitors turn on with full 3D acceleration. > if i understand this patch and the gfx_passthrough parameter right, you don't need this patch for this scenario: with gfx_passthrough=0 this patch does not what its intended to do, i.e. "declare" itself as the primary gpu within the DomU which would mean you could also see early boot messages and windows start screen on the monitor of the passed-through gpu (a feature i not really need). Greetings Tobias > I've been using this patch (4.1 patch, 4.2 a couple of weeks) 6 months now, > not a single bsod. > Thanks everyone, > Ivo > > > -- > View this message in context: > http://xen.1045712.n5.nabble.com/AMD-ATI-patch-for-xen-4-2-unstable-tp5611 > 297p5684634.html Sent from the Xen - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:01:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:01:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDRk-0001ui-S9; Fri, 04 May 2012 08:01:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDRi-0001uY-2N for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:00:59 +0000 Received: from [85.158.138.51:21612] by server-10.bemta-3.messagelabs.com id C6/58-29478-9BC83AF4; Fri, 04 May 2012 08:00:57 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336118450!25177657!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4361 invoked from network); 4 May 2012 08:00:50 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-3.tower-174.messagelabs.com with SMTP; 4 May 2012 08:00:50 -0000 Received: from p5b2e1f1c.dip.t-dialin.net ([91.46.31.28] 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 ) id 1SQDRS-0007Pq-O2; Fri, 04 May 2012 08:00:44 +0000 Message-ID: <4FA38CA0.3020601@canonical.com> Date: Fri, 04 May 2012 10:00:32 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> <20120503170858.GC9992@phenom.dumpdata.com> In-Reply-To: <20120503170858.GC9992@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Jan Beulich , Boris Ostrovsky Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5525228139078192454==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============5525228139078192454== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEB40C659F3DC487B0CD9A40F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB40C659F3DC487B0CD9A40F Content-Type: multipart/mixed; boundary="------------070800050300030104070507" This is a multi-part message in MIME format. --------------070800050300030104070507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 19:08, Konrad Rzeszutek Wilk wrote: >>> Hmmm, so xen_apic_read is still correct... >>> >>> [ 0.000000] ACPI: Local APIC address 0xfee00000 >>> [ 0.000000] xxx xen_apic_read(20) >>> [ 0.000000] xxx xen_apic_read -> 10 >>> [ 0.000000] boot_cpu_physical_apicid =3D 0 >>> [ 0.000000] xxx xen_apic_read(30) >>> [ 0.000000] +- apic version =3D 10 >>> >>> there seems to be a slightly strange tweak (at least for me) in read_= apic_id... >>> >>> static inline unsigned int read_apic_id(void) >>> { >>> unsigned int reg; >>> >>> reg =3D apic_read(APIC_ID); // calls apic->read(reg) >>> >>> return apic->get_apic_id(reg); >> >> Duh!! Let me spin out a new patch that will do this. >=20 > Meaning bit-shift it. We ended up doing 10 >> 24 (get_apic_id does that= ) > which results in zero. So lets be a bit more cautious and over-write > the get_apic_id and set_apic_id and as well do the proper bit-shifting.= >=20 I can confirm that with this patch applied I can load the xen-acpi-proces= sor driver and see P-states changing in xenpm. No BIOS bug messages. Also tested on the i7 and it does still work. I am attaching the dmesg ou= tput of both runs. On the i7 the xen apic functions are called in two places and = for cpu#0 only. On AMD, I see additional call later and for all cpus while en= abling them. apic->read bails out, but apic->get_apic_id returns 0 (though I cou= ld see no immediate problem from that). Maybe that info is helpful for the next = stage. -Stefan > commit 4bb450ea9dca1b8d845f1b53ab6476615a32badf > Author: Konrad Rzeszutek Wilk > Date: Wed May 2 15:04:51 2012 -0400 >=20 > xen/apic: Return the APIC ID (and version) for CPU 0. > =20 > On x86_64 on AMD machines where the first APIC_ID is not zero, we g= et: > =20 > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) > BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 > BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 > =20 > which means that when the ACPI processor driver loads and > tries to parse the _Pxx states it fails to do as, as it > ends up calling acpi_get_cpuid which does this: > =20 > for_each_possible_cpu(i) { > if (cpu_physical_id(i) =3D=3D apic_id) > return i; > } > =20 > And the bootup CPU, has not been found so it fails and returns -1 > for the first CPU - which then subsequently in the loop that > "acpi_processor_get_info" does results in returning an error, which= > means that "acpi_processor_add" failing and per_cpu(processor) > is never set (and is NULL). > =20 > That means that when xen-acpi-processor tries to load (much much > later on) and parse the P-states it gets -ENODEV from > acpi_processor_register_performance() (which tries to read > the per_cpu(processor)) and fails to parse the data. > =20 > Reported-by: Stefan Bader > Suggested-by: Boris Ostrovsky > [v2: Bit-shift APIC ID by 24 bits] > Signed-off-by: Konrad Rzeszutek Wilk Tested-by: Stefan Bader >=20 > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..63d6c22 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -53,6 +53,9 @@ > #include > #include > #include > +#ifdef CONFIG_NUMA > +#include > +#endif > #include > #include > #include > @@ -809,9 +812,40 @@ static void xen_io_delay(void) > } > =20 > #ifdef CONFIG_X86_LOCAL_APIC > +static unsigned long xen_set_apic_id(unsigned int x) > +{ > + WARN_ON(1); > + return x; > +} > +static unsigned int xen_get_apic_id(unsigned long x) > +{ > + return (((x)>>24) & 0xFFu); > +} > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op =3D { > + .cmd =3D XENPF_get_cpuinfo, > + .interface_version =3D XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid =3D 0, > + }; > + int ret =3D 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg =3D=3D APIC_LVR) > + return 0x10; > + > + if (reg !=3D APIC_ID) > + return 0; > + > + ret =3D HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id << 24; > } > =20 > static void xen_apic_write(u32 reg, u32 val) > @@ -849,6 +883,8 @@ static void set_xen_basic_apic_ops(void) > apic->icr_write =3D xen_apic_icr_write; > apic->wait_icr_idle =3D xen_apic_wait_icr_idle; > apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle; > + apic->set_apic_id =3D xen_set_apic_id; > + apic->get_apic_id =3D xen_get_apic_id; > } > =20 > #endif > @@ -1294,6 +1330,9 @@ asmlinkage void __init xen_start_kernel(void) > */ > acpi_numa =3D -1; > #endif > +#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32) > + numa_off =3D 1; > +#endif > =20 > pgd =3D (pgd_t *)xen_start_info->pt_base; > =20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------070800050300030104070507 Content-Type: text/plain; charset=UTF-8; name="dmesg.i7.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.i7.txt" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg8 SMP Thu May 3 17:40:0= 6 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg8-generic 3.2.16) [ 0.000000] Command line: placeholder root=3D/dev/mapper/rootvg-magrat= hea ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglevel=3D10 earlypr= intk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 97-100 pfn range: 105 pages freed [ 0.000000] 1-1 mapping on 97->100 [ 0.000000] 1-1 mapping on dfee0->100000 [ 0.000000] Released 105 pages of unused memory [ 0.000000] Set 131465 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000097000 (usable) [ 0.000000] Xen: 000000000009f800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfee0000 (usable) [ 0.000000] Xen: 00000000dfee0000 - 00000000dfee1000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee1000 - 00000000dfef0000 (ACPI data) [ 0.000000] Xen: 00000000dfef0000 - 00000000dff00000 (reserved) [ 0.000000] Xen: 00000000f0000000 - 00000000f4000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 0000000180120000 (usable) [ 0.000000] Xen: 0000000180120000 - 0000000220000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] DMI: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BI= OS F11 03/11/2010 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x180120 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfee0 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000f5cc0] f5cc0 [ 0.000000] initial memory mapped : 0 - 047e7000 [ 0.000000] Base memory trampoline at [ffff880000092000] 92000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfee0000 [ 0.000000] 0000000000 - 00dfee0000 page 4k [ 0.000000] kernel direct mapping tables up to dfee0000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-0000000180120000 [ 0.000000] 0100000000 - 0180120000 page 4k [ 0.000000] kernel direct mapping tables up to 180120000 @ 1f3f7000-20= 000000 [ 0.000000] xen: setting RW the range 1f7fb000 - 20000000 [ 0.000000] RAMDISK: 02060000 - 047e7000 [ 0.000000] ACPI: RSDP 00000000000f7680 00014 (v00 GBT ) [ 0.000000] ACPI: RSDT 00000000dfee1040 00040 (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: FACP 00000000dfee10c0 00074 (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: DSDT 00000000dfee1180 04BA7 (v01 GBT GBTUACPI 000= 01000 MSFT 0100000C) [ 0.000000] ACPI: FACS 00000000dfee0000 00040 [ 0.000000] ACPI: HPET 00000000dfee5f00 00038 (v01 GBT GBTUACPI 423= 02E31 GBTU 00000098) [ 0.000000] ACPI: MCFG 00000000dfee5f80 0003C (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: EUDS 00000000dfee5fc0 00470 (v01 GBT 000= 00000 00000000) [ 0.000000] ACPI: TAMG 00000000dfee6430 00B72 (v01 GBT GBT B0 545= 5312E BG?? 53450101) [ 0.000000] ACPI: APIC 00000000dfee5d80 0012C (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: SSDT 00000000dfee6fb0 02FE4 (v01 INTEL PPM RCM 800= 00001 INTL 20061109) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(0x20) -> 0x0 [ 0.000000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.000000] xxx xen_apic_read(0x30) -> 0x10 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000180120000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000180120000 [ 0.000000] NODE_DATA [000000001fffb000 - 000000001fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x00180120 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000097 [ 0.000000] 0: 0x00000100 -> 0x000dfee0 [ 0.000000] 0: 0x00100000 -> 0x00180120 [ 0.000000] On node 0 totalpages: 1441671 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2153 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896800 pages, LIFO batch:31 [ 0.000000] Normal zone: 8197 pages used for memmap [ 0.000000] Normal zone: 516379 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] dfl dfl lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level= ) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] SMP: Allowing 16 CPUs, 8 hotplug CPUs [ 0.000000] xxx xen_apic_read(0x20) -> 0x0 [ 0.000000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 00a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000d= fee1000 [ 0.000000] PM: Registered nosave memory: 00000000dfee1000 - 00000000d= fef0000 [ 0.000000] PM: Registered nosave memory: 00000000dfef0000 - 00000000d= ff00000 [ 0.000000] PM: Registered nosave memory: 00000000dff00000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= 4000000 [ 0.000000] PM: Registered nosave memory: 00000000f4000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at dff00000 (gap: dff000= 00:10100000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 6 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88001fdeb000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] = 14 [0] 15=20 [ 2.348911] Built 1 zonelists in Node order, mobility grouping on. To= tal pages: 1415332 [ 2.348914] Policy zone: Normal [ 2.348917] Kernel command line: placeholder root=3D/dev/mapper/rootvg= -magrathea ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglevel=3D10 = earlyprintk=3Dxenboot [ 2.349396] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 2.378521] Placing 64MB software IO TLB between ffff880015400000 - ff= ff880019400000 [ 2.378525] software IO TLB at phys 0x15400000 - 0x19400000 [ 2.379958] Memory: 294916k/6292608k available (6654k kernel code, 525= 924k absent, 5471768k reserved, 6550k data, 920k init) [ 2.380035] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D16, Nodes=3D1 [ 2.380070] Hierarchical RCU implementation. [ 2.380072] RCU dyntick-idle grace-period acceleration is enabled. [ 2.380083] NR_IRQS:16640 nr_irqs:4096 16 [ 2.380142] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D0= [ 2.380145] xen: registering gsi 9 triggering 0 polarity 0 [ 2.380154] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 2.380159] xen: acpi sci 9 [ 2.380162] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 2.380166] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 2.380169] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 2.380173] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 2.380176] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 2.380179] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 2.380182] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 2.380186] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 2.380188] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 2.380190] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 2.380193] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 2.380197] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 2.380200] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 2.380204] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 2.380207] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 2.380210] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 2.382007] Console: colour VGA+ 80x25 [ 2.382011] console [hvc0] enabled, bootconsole disabled [ 2.390775] allocated 47185920 bytes of page_cgroup [ 2.390779] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 2.390818] Xen: using vcpuop timer interface [ 2.390825] installing Xen timer for CPU 0 [ 2.390854] Detected 2664.850 MHz processor. [ 2.390861] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 5329.70 BogoMIPS (lpj=3D10659400) [ 2.390866] pid_max: default: 32768 minimum: 301 [ 2.390896] Security Framework initialized [ 2.390906] AppArmor: AppArmor initialized [ 2.390908] Yama: becoming mindful. [ 2.393465] Dentry cache hash table entries: 1048576 (order: 11, 83886= 08 bytes) [ 2.395968] Inode-cache hash table entries: 524288 (order: 10, 4194304= bytes) [ 2.396755] Mount-cache hash table entries: 256 [ 2.396908] Initializing cgroup subsys cpuacct [ 2.396914] Initializing cgroup subsys memory [ 2.396926] Initializing cgroup subsys devices [ 2.396929] Initializing cgroup subsys freezer [ 2.396932] Initializing cgroup subsys blkio [ 2.396943] Initializing cgroup subsys perf_event [ 2.396999] CPU: Physical Processor ID: 0 [ 2.397001] CPU: Processor Core ID: 0 [ 2.399115] ACPI: Core revision 20110623 [ 2.408066] ftrace: allocating 27104 entries in 107 pages [ 2.414834] cpu 0 spinlock event irq 273 [ 2.414887] Performance Events: unsupported p6 CPU model 26 no PMU dri= ver, software events only. [ 2.415004] NMI watchdog disabled (cpu0): hardware events not enabled [ 2.415078] installing Xen timer for CPU 1 [ 2.415089] cpu 1 spinlock event irq 279 [ 2.415214] NMI watchdog disabled (cpu1): hardware events not enabled [ 2.415291] installing Xen timer for CPU 2 [ 2.415302] cpu 2 spinlock event irq 285 [ 2.415386] NMI watchdog disabled (cpu2): hardware events not enabled [ 2.415455] installing Xen timer for CPU 3 [ 2.415466] cpu 3 spinlock event irq 291 [ 2.415545] NMI watchdog disabled (cpu3): hardware events not enabled [ 2.415617] installing Xen timer for CPU 4 [ 2.415627] cpu 4 spinlock event irq 297 [ 2.415712] NMI watchdog disabled (cpu4): hardware events not enabled [ 2.415786] installing Xen timer for CPU 5 [ 2.415797] cpu 5 spinlock event irq 303 [ 2.415880] NMI watchdog disabled (cpu5): hardware events not enabled [ 2.415950] installing Xen timer for CPU 6 [ 2.415960] cpu 6 spinlock event irq 309 [ 2.416047] NMI watchdog disabled (cpu6): hardware events not enabled [ 2.416118] installing Xen timer for CPU 7 [ 2.416131] cpu 7 spinlock event irq 315 [ 2.416213] NMI watchdog disabled (cpu7): hardware events not enabled [ 2.416234] Brought up 8 CPUs [ 2.416605] devtmpfs: initialized [ 2.417654] EVM: security.selinux [ 2.417657] EVM: security.SMACK64 [ 2.417659] EVM: security.capability [ 2.417704] PM: Registering ACPI NVS region at dfee0000 (4096 bytes) [ 2.418293] Grant table initialized [ 2.418336] print_constraints: dummy:=20 [ 2.418372] RTC time: 9:37:06, date: 05/04/12 [ 2.418401] NET: Registered protocol family 16 [ 2.418497] Trying to unpack rootfs image as initramfs... [ 2.423099] ACPI: bus type pci registered [ 2.423174] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf00000= 00-0xf3ffffff] (base 0xf0000000) [ 2.423178] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E= 820 [ 2.440460] PCI: Using configuration type 1 for base access [ 2.441457] bio: create slab at 0 [ 2.441567] ACPI: Added _OSI(Module Device) [ 2.441570] ACPI: Added _OSI(Processor Device) [ 2.441573] ACPI: Added _OSI(3.0 _SCP Extensions) [ 2.441576] ACPI: Added _OSI(Processor Aggregator Device) [ 2.443539] ACPI: EC: Look up EC in DSDT [ 2.451390] ACPI Warning: Incorrect checksum in table [TAMG] - 0x0C, s= hould be 0x0B (20110623/tbutils-314) [ 2.454463] ACPI: Interpreter enabled [ 2.454468] ACPI: (supports S0 S3 S4 S5) [ 2.454494] ACPI: Using IOAPIC for interrupt routing [ 2.458582] Freeing initrd memory: 40476k freed [ 2.461357] ACPI: No dock devices found. [ 2.461362] HEST: Table not found. [ 2.461366] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 2.461499] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) [ 2.461744] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7= ] [ 2.461748] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff= ] [ 2.461751] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 2.461754] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x= 000dffff] [ 2.461758] pci_root PNP0A03:00: host bridge window [mem 0xdff00000-0x= febfffff] [ 2.461784] pci 0000:00:00.0: [8086:3405] type 0 class 0x000600 [ 2.461890] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold [ 2.461896] pci 0000:00:00.0: PME# disabled [ 2.461939] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604 [ 2.462052] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 2.462058] pci 0000:00:01.0: PME# disabled [ 2.462101] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604 [ 2.462214] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold [ 2.462220] pci 0000:00:03.0: PME# disabled [ 2.462266] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604 [ 2.462378] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold [ 2.462384] pci 0000:00:07.0: PME# disabled [ 2.462430] pci 0000:00:10.0: [8086:3425] type 0 class 0x000800 [ 2.462559] pci 0000:00:10.1: [8086:3426] type 0 class 0x000800 [ 2.462672] pci 0000:00:11.0: [8086:3427] type 0 class 0x000800 [ 2.462802] pci 0000:00:11.1: [8086:3428] type 0 class 0x000800 [ 2.462917] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800 [ 2.462939] pci 0000:00:13.0: reg 10: [mem 0xfbfff000-0xfbffffff] [ 2.463037] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold [ 2.463043] pci 0000:00:13.0: PME# disabled [ 2.463078] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800 [ 2.463209] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800 [ 2.463342] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800 [ 2.463476] pci 0000:00:15.0: [8086:342f] type 0 class 0x000800 [ 2.463596] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03 [ 2.463672] pci 0000:00:1a.0: reg 20: [io 0xff00-0xff1f] [ 2.463761] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03 [ 2.463836] pci 0000:00:1a.1: reg 20: [io 0xfe00-0xfe1f] [ 2.463928] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03 [ 2.464000] pci 0000:00:1a.2: reg 20: [io 0xfd00-0xfd1f] [ 2.464113] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03 [ 2.464148] pci 0000:00:1a.7: reg 10: [mem 0xfbffe000-0xfbffe3ff] [ 2.464305] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 2.464312] pci 0000:00:1a.7: PME# disabled [ 2.464357] pci 0000:00:1b.0: [8086:3a3e] type 0 class 0x000403 [ 2.464384] pci 0000:00:1b.0: reg 10: [mem 0xfbff4000-0xfbff7fff 64bit= ] [ 2.464508] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 2.464515] pci 0000:00:1b.0: PME# disabled [ 2.464549] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604 [ 2.464677] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 2.464683] pci 0000:00:1c.0: PME# disabled [ 2.464721] pci 0000:00:1c.1: [8086:3a42] type 1 class 0x000604 [ 2.464849] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold [ 2.464855] pci 0000:00:1c.1: PME# disabled [ 2.464897] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604 [ 2.465026] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 2.465032] pci 0000:00:1c.4: PME# disabled [ 2.465074] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03 [ 2.465149] pci 0000:00:1d.0: reg 20: [io 0xfc00-0xfc1f] [ 2.465238] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03 [ 2.465313] pci 0000:00:1d.1: reg 20: [io 0xfb00-0xfb1f] [ 2.465402] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03 [ 2.465477] pci 0000:00:1d.2: reg 20: [io 0xfa00-0xfa1f] [ 2.465582] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03 [ 2.465617] pci 0000:00:1d.7: reg 10: [mem 0xfbffd000-0xfbffd3ff] [ 2.465771] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 2.465779] pci 0000:00:1d.7: PME# disabled [ 2.465815] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604 [ 2.465928] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601 [ 2.466059] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800= (mask 000f) [ 2.466064] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290= (mask 000f) [ 2.466147] pci 0000:00:1f.2: [8086:2822] type 0 class 0x000104 [ 2.466182] pci 0000:00:1f.2: reg 10: [io 0xf900-0xf907] [ 2.466196] pci 0000:00:1f.2: reg 14: [io 0xf800-0xf803] [ 2.466211] pci 0000:00:1f.2: reg 18: [io 0xf700-0xf707] [ 2.466225] pci 0000:00:1f.2: reg 1c: [io 0xf600-0xf603] [ 2.466239] pci 0000:00:1f.2: reg 20: [io 0xf500-0xf51f] [ 2.466253] pci 0000:00:1f.2: reg 24: [mem 0xfbffc000-0xfbffc7ff] [ 2.466340] pci 0000:00:1f.2: PME# supported from D3hot [ 2.466346] pci 0000:00:1f.2: PME# disabled [ 2.466375] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05 [ 2.466402] pci 0000:00:1f.3: reg 10: [mem 0xfbffb000-0xfbffb0ff 64bit= ] [ 2.466441] pci 0000:00:1f.3: reg 20: [io 0x0500-0x051f] [ 2.466557] pci 0000:00:01.0: PCI bridge to [bus 01-01] [ 2.466656] pci 0000:02:00.0: [10de:05e1] type 0 class 0x000300 [ 2.466676] pci 0000:02:00.0: reg 10: [mem 0xf8000000-0xf8ffffff] [ 2.466696] pci 0000:02:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit= pref] [ 2.466717] pci 0000:02:00.0: reg 1c: [mem 0xf6000000-0xf7ffffff 64bit= ] [ 2.466730] pci 0000:02:00.0: reg 24: [io 0xef00-0xef7f] [ 2.466744] pci 0000:02:00.0: reg 30: [mem 0x00000000-0x0007ffff pref]= [ 2.472216] pci 0000:00:03.0: PCI bridge to [bus 02-02] [ 2.472227] pci 0000:00:03.0: bridge window [io 0xe000-0xefff] [ 2.472237] pci 0000:00:03.0: bridge window [mem 0xf6000000-0xf9ffff= ff] [ 2.472251] pci 0000:00:03.0: bridge window [mem 0xe0000000-0xefffff= ff 64bit pref] [ 2.472331] pci 0000:00:07.0: PCI bridge to [bus 03-03] [ 2.472414] pci 0000:00:1c.0: PCI bridge to [bus 04-04] [ 2.472521] pci 0000:05:00.0: [197b:2363] type 0 class 0x000101 [ 2.472649] pci 0000:05:00.0: reg 24: [mem 0xfbefe000-0xfbefffff] [ 2.472741] pci 0000:05:00.0: PME# supported from D3hot [ 2.472749] pci 0000:05:00.0: PME# disabled [ 2.472789] pci 0000:05:00.1: [197b:2363] type 0 class 0x000101 [ 2.472824] pci 0000:05:00.1: reg 10: [io 0xdf00-0xdf07] [ 2.472845] pci 0000:05:00.1: reg 14: [io 0xde00-0xde03] [ 2.472864] pci 0000:05:00.1: reg 18: [io 0xdd00-0xdd07] [ 2.472884] pci 0000:05:00.1: reg 1c: [io 0xdc00-0xdc03] [ 2.472904] pci 0000:05:00.1: reg 20: [io 0xdb00-0xdb0f] [ 2.473025] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. = You can enable it with 'pcie_aspm=3Dforce' [ 2.473045] pci 0000:00:1c.1: PCI bridge to [bus 05-05] [ 2.473051] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff] [ 2.473057] pci 0000:00:1c.1: bridge window [mem 0xfbe00000-0xfbefff= ff] [ 2.473161] pci 0000:06:00.0: [10ec:8168] type 0 class 0x000200 [ 2.473185] pci 0000:06:00.0: reg 10: [io 0xce00-0xceff] [ 2.473228] pci 0000:06:00.0: reg 18: [mem 0xfbbff000-0xfbbfffff 64bit= pref] [ 2.473256] pci 0000:06:00.0: reg 20: [mem 0xfbbf8000-0xfbbfbfff 64bit= pref] [ 2.473274] pci 0000:06:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]= [ 2.473374] pci 0000:06:00.0: supports D1 D2 [ 2.473376] pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3col= d [ 2.473384] pci 0000:06:00.0: PME# disabled [ 2.480327] pci 0000:00:1c.4: PCI bridge to [bus 06-06] [ 2.480338] pci 0000:00:1c.4: bridge window [io 0xc000-0xcfff] [ 2.480348] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfff= ff] [ 2.480363] pci 0000:00:1c.4: bridge window [mem 0xfbb00000-0xfbbfff= ff 64bit pref] [ 2.480446] pci 0000:07:06.0: [104c:8024] type 0 class 0x000c00 [ 2.480475] pci 0000:07:06.0: reg 10: [mem 0xfbdff000-0xfbdff7ff] [ 2.480491] pci 0000:07:06.0: reg 14: [mem 0xfbdf8000-0xfbdfbfff] [ 2.480606] pci 0000:07:06.0: supports D1 D2 [ 2.480608] pci 0000:07:06.0: PME# supported from D0 D1 D2 D3hot [ 2.480615] pci 0000:07:06.0: PME# disabled [ 2.480674] pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive d= ecode) [ 2.480684] pci 0000:00:1e.0: bridge window [mem 0xfbd00000-0xfbdfff= ff] [ 2.480694] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 2.480698] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 2.480701] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 2.480705] pci 0000:00:1e.0: bridge window [mem 0x000c0000-0x000dff= ff] (subtractive decode) [ 2.480708] pci 0000:00:1e.0: bridge window [mem 0xdff00000-0xfebfff= ff] (subtractive decode) [ 2.480766] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 2.481021] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT] [ 2.481077] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT] [ 2.481158] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT] [ 2.481215] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] [ 2.481382] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 2.481387] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 2.481390] ACPI _OSC control for PCIe not granted, disabling ASPM [ 2.511626] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 1= 2 14 15) [ 2.511725] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 1= 2 14 15) [ 2.511822] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 1= 2 14 15) [ 2.511918] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 1= 2 14 15) [ 2.512015] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12= 14 15) *0, disabled. [ 2.512113] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 1= 2 14 15) [ 2.512210] ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 *7 9 10 11 1= 2 14 15) [ 2.512306] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 *4 5 6 7 9 10 11 1= 2 14 15) [ 2.512365] xen/balloon: Initialising balloon driver. [ 2.528500] xen-balloon: Initialising balloon driver. [ 2.528525] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 2.528652] vgaarb: device added: PCI:0000:02:00.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 2.528658] vgaarb: loaded [ 2.528659] vgaarb: bridge control possible 0000:02:00.0 [ 2.528742] i2c-core: driver [aat2870] using legacy suspend method [ 2.528745] i2c-core: driver [aat2870] using legacy resume method [ 2.528802] SCSI subsystem initialized [ 2.528882] libata version 3.00 loaded. [ 2.528927] usbcore: registered new interface driver usbfs [ 2.528939] usbcore: registered new interface driver hub [ 2.528981] usbcore: registered new device driver usb [ 2.529085] PCI: Using ACPI for IRQ routing [ 2.531669] PCI: Discovered peer bus 3f [ 2.531705] pci 0000:3f:00.0: [8086:2c41] type 0 class 0x000600 [ 2.531765] pci 0000:3f:00.1: [8086:2c01] type 0 class 0x000600 [ 2.531826] pci 0000:3f:02.0: [8086:2c10] type 0 class 0x000600 [ 2.531878] pci 0000:3f:02.1: [8086:2c11] type 0 class 0x000600 [ 2.531936] pci 0000:3f:03.0: [8086:2c18] type 0 class 0x000600 [ 2.531990] pci 0000:3f:03.1: [8086:2c19] type 0 class 0x000600 [ 2.532044] pci 0000:3f:03.4: [8086:2c1c] type 0 class 0x000600 [ 2.532100] pci 0000:3f:04.0: [8086:2c20] type 0 class 0x000600 [ 2.532152] pci 0000:3f:04.1: [8086:2c21] type 0 class 0x000600 [ 2.532203] pci 0000:3f:04.2: [8086:2c22] type 0 class 0x000600 [ 2.532255] pci 0000:3f:04.3: [8086:2c23] type 0 class 0x000600 [ 2.532312] pci 0000:3f:05.0: [8086:2c28] type 0 class 0x000600 [ 2.532364] pci 0000:3f:05.1: [8086:2c29] type 0 class 0x000600 [ 2.532417] pci 0000:3f:05.2: [8086:2c2a] type 0 class 0x000600 [ 2.532470] pci 0000:3f:05.3: [8086:2c2b] type 0 class 0x000600 [ 2.532527] pci 0000:3f:06.0: [8086:2c30] type 0 class 0x000600 [ 2.532579] pci 0000:3f:06.1: [8086:2c31] type 0 class 0x000600 [ 2.532631] pci 0000:3f:06.2: [8086:2c32] type 0 class 0x000600 [ 2.532683] pci 0000:3f:06.3: [8086:2c33] type 0 class 0x000600 [ 2.533181] PCI: pci_cache_line_size set to 64 bytes [ 2.533395] reserve RAM buffer: 0000000000097000 - 000000000009ffff=20 [ 2.533399] reserve RAM buffer: 00000000dfee0000 - 00000000dfffffff=20 [ 2.533402] reserve RAM buffer: 0000000180120000 - 0000000183ffffff=20 [ 2.533484] NetLabel: Initializing [ 2.533487] NetLabel: domain hash size =3D 128 [ 2.533489] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 2.533498] NetLabel: unlabeled traffic allowed by default [ 2.533578] Switching to clocksource xen [ 2.539394] AppArmor: AppArmor Filesystem Enabled [ 2.539411] pnp: PnP ACPI init [ 2.539420] ACPI: bus type pnp registered [ 2.539581] pnp 00:00: [bus 00-3f] [ 2.539585] pnp 00:00: [io 0x0cf8-0x0cff] [ 2.539587] pnp 00:00: [io 0x0000-0x0cf7 window] [ 2.539590] pnp 00:00: [io 0x0d00-0xffff window] [ 2.539593] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 2.539596] pnp 00:00: [mem 0x000c0000-0x000dffff window] [ 2.539598] pnp 00:00: [mem 0xdff00000-0xfebfffff window] [ 2.539673] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)= [ 2.539822] pnp 00:01: [io 0x0010-0x001f] [ 2.539825] pnp 00:01: [io 0x0022-0x003f] [ 2.539827] pnp 00:01: [io 0x0044-0x005f] [ 2.539830] pnp 00:01: [io 0x0062-0x0063] [ 2.539832] pnp 00:01: [io 0x0065-0x006f] [ 2.539834] pnp 00:01: [io 0x0074-0x007f] [ 2.539837] pnp 00:01: [io 0x0091-0x0093] [ 2.539839] pnp 00:01: [io 0x00a2-0x00bf] [ 2.539841] pnp 00:01: [io 0x00e0-0x00ef] [ 2.539844] pnp 00:01: [io 0x04d0-0x04d1] [ 2.539846] pnp 00:01: [io 0x0290-0x029f] [ 2.539848] pnp 00:01: [io 0x0800-0x087f] [ 2.539850] pnp 00:01: [io 0x0290-0x0294] [ 2.539853] pnp 00:01: [io 0x0880-0x088f] [ 2.539927] system 00:01: [io 0x04d0-0x04d1] has been reserved [ 2.539930] system 00:01: [io 0x0290-0x029f] has been reserved [ 2.539934] system 00:01: [io 0x0800-0x087f] has been reserved [ 2.539937] system 00:01: [io 0x0290-0x0294] has been reserved [ 2.539940] system 00:01: [io 0x0880-0x088f] has been reserved [ 2.539944] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.539964] pnp 00:02: [dma 4] [ 2.539966] pnp 00:02: [io 0x0000-0x000f] [ 2.539968] pnp 00:02: [io 0x0080-0x0090] [ 2.539971] pnp 00:02: [io 0x0094-0x009f] [ 2.539973] pnp 00:02: [io 0x00c0-0x00df] [ 2.540007] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)= [ 2.540105] pnp 00:03: [irq 0 disabled] [ 2.540109] xen: registering gsi 8 triggering 1 polarity 0 [ 2.540114] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 2.540116] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 2.540123] pnp 00:03: [irq 8] [ 2.540125] pnp 00:03: [mem 0xfed00000-0xfed003ff] [ 2.540166] pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active)= [ 2.540220] pnp 00:04: [io 0x0070-0x0073] [ 2.540260] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 2.540276] pnp 00:05: [io 0x0061] [ 2.540313] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)= [ 2.540327] pnp 00:06: [io 0x00f0-0x00ff] [ 2.540330] xen: registering gsi 13 triggering 1 polarity 0 [ 2.540334] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 2.540336] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 2.540341] pnp 00:06: [irq 13] [ 2.540380] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 2.540755] pnp 00:07: [io 0x0400-0x04cf] [ 2.540758] pnp 00:07: [io 0x04d2-0x04ff] [ 2.540828] system 00:07: [io 0x0400-0x04cf] has been reserved [ 2.540832] system 00:07: [io 0x04d2-0x04ff] has been reserved [ 2.540836] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.541231] pnp 00:08: [mem 0xf0000000-0xf3ffffff] [ 2.541316] system 00:08: [mem 0xf0000000-0xf3ffffff] has been reserve= d [ 2.541320] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.541752] pnp 00:09: [mem 0x000d5200-0x000d7fff] [ 2.541756] pnp 00:09: [mem 0x000f0000-0x000f7fff] [ 2.541758] pnp 00:09: [mem 0x000f8000-0x000fbfff] [ 2.541761] pnp 00:09: [mem 0x000fc000-0x000fffff] [ 2.541764] pnp 00:09: [mem 0xdfee0000-0xdfefffff] [ 2.541766] pnp 00:09: [mem 0x00000000-0x0009ffff] [ 2.541769] pnp 00:09: [mem 0x00100000-0xdfedffff] [ 2.541771] pnp 00:09: [mem 0xfec00000-0xfec00fff] [ 2.541774] pnp 00:09: [mem 0xfed10000-0xfed1dfff] [ 2.541776] pnp 00:09: [mem 0xfed20000-0xfed8ffff] [ 2.541779] pnp 00:09: [mem 0xfee00000-0xfee00fff] [ 2.541781] pnp 00:09: [mem 0xffb00000-0xffb7ffff] [ 2.541784] pnp 00:09: [mem 0xfff00000-0xffffffff] [ 2.541786] pnp 00:09: [mem 0x000e0000-0x000effff] [ 2.541878] system 00:09: [mem 0x000d5200-0x000d7fff] could not be res= erved [ 2.541881] system 00:09: [mem 0x000f0000-0x000f7fff] could not be res= erved [ 2.541885] system 00:09: [mem 0x000f8000-0x000fbfff] could not be res= erved [ 2.541888] system 00:09: [mem 0x000fc000-0x000fffff] could not be res= erved [ 2.541891] system 00:09: [mem 0xdfee0000-0xdfefffff] could not be res= erved [ 2.541894] system 00:09: [mem 0x00000000-0x0009ffff] could not be res= erved [ 2.541897] system 00:09: [mem 0x00100000-0xdfedffff] could not be res= erved [ 2.541901] system 00:09: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 2.541904] system 00:09: [mem 0xfed10000-0xfed1dfff] has been reserve= d [ 2.541907] system 00:09: [mem 0xfed20000-0xfed8ffff] has been reserve= d [ 2.541910] system 00:09: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 2.541914] system 00:09: [mem 0xffb00000-0xffb7ffff] has been reserve= d [ 2.541917] system 00:09: [mem 0xfff00000-0xffffffff] has been reserve= d [ 2.541920] system 00:09: [mem 0x000e0000-0x000effff] could not be res= erved [ 2.541924] system 00:09: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 2.541960] pnp 00:0a: [mem 0xffb80000-0xffbfffff] [ 2.542018] pnp 00:0a: Plug and Play ACPI device, IDs INT0800 (active)= [ 2.542028] pnp: PnP ACPI: found 11 devices [ 2.542030] ACPI: ACPI bus type pnp unregistered [ 2.548697] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 2.548723] PCI: max bus depth: 1 pci_try_num: 2 [ 2.548819] pci 0000:00:1c.1: BAR 15: assigned [mem 0xf4000000-0xf41ff= fff 64bit pref] [ 2.548824] pci 0000:00:1c.0: BAR 14: assigned [mem 0xf4200000-0xf43ff= fff] [ 2.548827] pci 0000:00:1c.0: BAR 15: assigned [mem 0xf4400000-0xf45ff= fff 64bit pref] [ 2.548832] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] [ 2.548835] pci 0000:00:01.0: PCI bridge to [bus 01-01] [ 2.548852] pci 0000:02:00.0: BAR 6: assigned [mem 0xf9000000-0xf907ff= ff pref] [ 2.548855] pci 0000:00:03.0: PCI bridge to [bus 02-02] [ 2.548860] pci 0000:00:03.0: bridge window [io 0xe000-0xefff] [ 2.548867] pci 0000:00:03.0: bridge window [mem 0xf6000000-0xf9ffff= ff] [ 2.548873] pci 0000:00:03.0: bridge window [mem 0xe0000000-0xefffff= ff 64bit pref] [ 2.548882] pci 0000:00:07.0: PCI bridge to [bus 03-03] [ 2.548897] pci 0000:00:1c.0: PCI bridge to [bus 04-04] [ 2.548902] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] [ 2.548910] pci 0000:00:1c.0: bridge window [mem 0xf4200000-0xf43fff= ff] [ 2.548916] pci 0000:00:1c.0: bridge window [mem 0xf4400000-0xf45fff= ff 64bit pref] [ 2.548926] pci 0000:00:1c.1: PCI bridge to [bus 05-05] [ 2.548930] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff] [ 2.548938] pci 0000:00:1c.1: bridge window [mem 0xfbe00000-0xfbefff= ff] [ 2.548944] pci 0000:00:1c.1: bridge window [mem 0xf4000000-0xf41fff= ff 64bit pref] [ 2.548955] pci 0000:06:00.0: BAR 6: assigned [mem 0xfbb00000-0xfbb1ff= ff pref] [ 2.548958] pci 0000:00:1c.4: PCI bridge to [bus 06-06] [ 2.548962] pci 0000:00:1c.4: bridge window [io 0xc000-0xcfff] [ 2.548970] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfff= ff] [ 2.548976] pci 0000:00:1c.4: bridge window [mem 0xfbb00000-0xfbbfff= ff 64bit pref] [ 2.548986] pci 0000:00:1e.0: PCI bridge to [bus 07-07] [ 2.548993] pci 0000:00:1e.0: bridge window [mem 0xfbd00000-0xfbdfff= ff] [ 2.549012] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549023] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549028] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549036] pci 0000:00:01.0: setting latency timer to 64 [ 2.549044] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549047] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549050] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549052] Already setup the GSI :16 [ 2.549055] pci 0000:00:03.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549061] pci 0000:00:03.0: setting latency timer to 64 [ 2.549068] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549071] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549074] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549076] Already setup the GSI :16 [ 2.549079] pci 0000:00:07.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549086] pci 0000:00:07.0: setting latency timer to 64 [ 2.549096] pci 0000:00:1c.0: enabling device (0000 -> 0003) [ 2.549100] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549103] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549106] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549108] Already setup the GSI :16 [ 2.549111] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549119] pci 0000:00:1c.0: setting latency timer to 64 [ 2.549127] xen: registering gsi 17 triggering 0 polarity 1 [ 2.549133] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.549138] pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 2.549144] pci 0000:00:1c.1: setting latency timer to 64 [ 2.549153] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549156] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549159] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549161] Already setup the GSI :16 [ 2.549164] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549170] pci 0000:00:1c.4: setting latency timer to 64 [ 2.549181] pci 0000:00:1e.0: setting latency timer to 64 [ 2.549186] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 2.549189] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 2.549192] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 2.549195] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000dffff] [ 2.549198] pci_bus 0000:00: resource 8 [mem 0xdff00000-0xfebfffff] [ 2.549201] pci_bus 0000:02: resource 0 [io 0xe000-0xefff] [ 2.549205] pci_bus 0000:02: resource 1 [mem 0xf6000000-0xf9ffffff] [ 2.549208] pci_bus 0000:02: resource 2 [mem 0xe0000000-0xefffffff 64b= it pref] [ 2.549213] pci_bus 0000:04: resource 0 [io 0x1000-0x1fff] [ 2.549216] pci_bus 0000:04: resource 1 [mem 0xf4200000-0xf43fffff] [ 2.549220] pci_bus 0000:04: resource 2 [mem 0xf4400000-0xf45fffff 64b= it pref] [ 2.549224] pci_bus 0000:05: resource 0 [io 0xd000-0xdfff] [ 2.549228] pci_bus 0000:05: resource 1 [mem 0xfbe00000-0xfbefffff] [ 2.549232] pci_bus 0000:05: resource 2 [mem 0xf4000000-0xf41fffff 64b= it pref] [ 2.549236] pci_bus 0000:06: resource 0 [io 0xc000-0xcfff] [ 2.549239] pci_bus 0000:06: resource 1 [mem 0xfbc00000-0xfbcfffff] [ 2.549243] pci_bus 0000:06: resource 2 [mem 0xfbb00000-0xfbbfffff 64b= it pref] [ 2.549247] pci_bus 0000:07: resource 1 [mem 0xfbd00000-0xfbdfffff] [ 2.549251] pci_bus 0000:07: resource 4 [io 0x0000-0x0cf7] [ 2.549254] pci_bus 0000:07: resource 5 [io 0x0d00-0xffff] [ 2.549258] pci_bus 0000:07: resource 6 [mem 0x000a0000-0x000bffff] [ 2.549262] pci_bus 0000:07: resource 7 [mem 0x000c0000-0x000dffff] [ 2.549265] pci_bus 0000:07: resource 8 [mem 0xdff00000-0xfebfffff] [ 2.549269] pci_bus 0000:3f: resource 0 [io 0x0000-0xffff] [ 2.549272] pci_bus 0000:3f: resource 1 [mem 0x00000000-0xfffffffff] [ 2.549307] NET: Registered protocol family 2 [ 2.549520] IP route cache hash table entries: 65536 (order: 7, 524288= bytes) [ 2.550969] TCP established hash table entries: 262144 (order: 10, 419= 4304 bytes) [ 2.551996] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 2.552158] TCP: Hash tables configured (established 262144 bind 65536= ) [ 2.552161] TCP reno registered [ 2.552204] UDP hash table entries: 4096 (order: 5, 131072 bytes) [ 2.552268] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)= [ 2.552352] NET: Registered protocol family 1 [ 2.552399] xen: registering gsi 16 triggering 0 polarity 1 [ 2.552405] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.552407] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.552410] Already setup the GSI :16 [ 2.552413] pci 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.552437] pci 0000:00:1a.0: PCI INT A disabled [ 2.552446] xen: registering gsi 21 triggering 0 polarity 1 [ 2.552453] xen: --> pirq=3D21 -> irq=3D21 (gsi=3D21) [ 2.552458] pci 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ = 21 [ 2.552481] pci 0000:00:1a.1: PCI INT B disabled [ 2.552489] xen: registering gsi 18 triggering 0 polarity 1 [ 2.552495] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.552500] pci 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.552523] pci 0000:00:1a.2: PCI INT C disabled [ 2.552533] xen: registering gsi 18 triggering 0 polarity 1 [ 2.552536] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.552539] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.552541] Already setup the GSI :18 [ 2.552544] pci 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.565694] pci 0000:00:1a.7: PCI INT C disabled [ 2.565728] xen: registering gsi 23 triggering 0 polarity 1 [ 2.565736] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.565741] pci 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ = 23 [ 2.565763] pci 0000:00:1d.0: PCI INT A disabled [ 2.565772] xen: registering gsi 19 triggering 0 polarity 1 [ 2.565778] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.565782] pci 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 2.565805] pci 0000:00:1d.1: PCI INT B disabled [ 2.565813] xen: registering gsi 18 triggering 0 polarity 1 [ 2.565816] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.565819] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.565821] Already setup the GSI :18 [ 2.565824] pci 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.565846] pci 0000:00:1d.2: PCI INT C disabled [ 2.565857] xen: registering gsi 23 triggering 0 polarity 1 [ 2.565860] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.565862] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.565865] Already setup the GSI :23 [ 2.565867] pci 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ = 23 [ 2.581691] pci 0000:00:1d.7: PCI INT A disabled [ 2.581738] pci 0000:02:00.0: Boot video device [ 2.581791] PCI: CLS 64 bytes, default 64 [ 2.582332] audit: initializing netlink socket (disabled) [ 2.582344] type=3D2000 audit(1336124227.574:1): initialized [ 2.601350] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 2.602798] VFS: Disk quotas dquot_6.5.2 [ 2.602848] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 2.603292] fuse init (API version 7.17) [ 2.603394] msgmni has been set to 655 [ 2.603880] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 2.603921] io scheduler noop registered [ 2.603925] io scheduler deadline registered [ 2.603959] io scheduler cfq registered (default) [ 2.604276] pcieport 0000:00:1c.0: setting latency timer to 64 [ 2.604443] pcieport 0000:00:1c.1: setting latency timer to 64 [ 2.604593] pcieport 0000:00:1c.4: setting latency timer to 64 [ 2.604763] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 2.604784] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 2.604895] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 2.604901] ACPI: Power Button [PWRB] [ 2.604945] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 2.604949] ACPI: Power Button [PWRF] [ 2.609738] ERST: Table is not found! [ 2.609742] GHES: HEST is not enabled! [ 2.610105] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 2.764246] hpet_acpi_add: no address or irqs in _CRS [ 2.764262] Linux agpgart interface v0.103 [ 2.765650] brd: module loaded [ 2.766434] loop: module loaded [ 2.766554] ahci 0000:00:1f.2: version 3.0 [ 2.766567] xen: registering gsi 19 triggering 0 polarity 1 [ 2.766572] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 2.766575] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.766578] Already setup the GSI :19 [ 2.766581] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ= 19 [ 2.766663] ahci 0000:00:1f.2: controller can't do SNTF, turning off C= AP_SNTF [ 2.766686] ahci: SSS flag set, parallel bus scan disabled [ 2.766725] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps = 0x3f impl RAID mode [ 2.766729] ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pmp pi= o slum part ccc ems=20 [ 2.766736] ahci 0000:00:1f.2: setting latency timer to 64 [ 2.806086] scsi0 : ahci [ 2.806164] scsi1 : ahci [ 2.806231] scsi2 : ahci [ 2.806301] scsi3 : ahci [ 2.806367] scsi4 : ahci [ 2.806433] scsi5 : ahci [ 2.806671] ata1: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 100 irq 325 [ 2.806676] ata2: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 180 irq 325 [ 2.806679] ata3: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 200 irq 325 [ 2.806683] ata4: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 280 irq 325 [ 2.806687] ata5: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 300 irq 325 [ 2.806690] ata6: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 380 irq 325 [ 2.806715] xen: registering gsi 17 triggering 0 polarity 1 [ 2.806719] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.806722] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.806724] Already setup the GSI :17 [ 2.806727] ahci 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ= 17 [ 2.821697] ahci 0000:05:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps = 0x3 impl SATA mode [ 2.821705] ahci 0000:05:00.0: flags: 64bit ncq pm led clo pmp pio slu= m part=20 [ 2.821717] ahci 0000:05:00.0: setting latency timer to 64 [ 2.821961] scsi6 : ahci [ 2.822036] scsi7 : ahci [ 2.822147] ata7: SATA max UDMA/133 abar m8192@0xfbefe000 port 0xfbefe= 100 irq 17 [ 2.822152] ata8: SATA max UDMA/133 abar m8192@0xfbefe000 port 0xfbefe= 180 irq 17 [ 2.822245] pata_acpi 0000:05:00.1: enabling device (0000 -> 0001) [ 2.822252] xen: registering gsi 18 triggering 0 polarity 1 [ 2.822257] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.822259] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.822262] Already setup the GSI :18 [ 2.822265] pata_acpi 0000:05:00.1: PCI INT B -> GSI 18 (level, low) -= > IRQ 18 [ 2.822293] pata_acpi 0000:05:00.1: setting latency timer to 64 [ 2.822308] pata_acpi 0000:05:00.1: PCI INT B disabled [ 2.822536] Fixed MDIO Bus: probed [ 2.822551] tun: Universal TUN/TAP device driver, 1.6 [ 2.822553] tun: (C) 1999-2004 Max Krasnyansky [ 2.822607] PPP generic driver version 2.4.2 [ 2.822704] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 2.822722] xen: registering gsi 18 triggering 0 polarity 1 [ 2.822727] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.822729] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.822732] Already setup the GSI :18 [ 2.822735] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.822753] ehci_hcd 0000:00:1a.7: setting latency timer to 64 [ 2.822758] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 2.822803] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bu= s number 1 [ 2.822850] ehci_hcd 0000:00:1a.7: debug port 1 [ 2.826735] ehci_hcd 0000:00:1a.7: cache line size of 64 is not suppor= ted [ 2.826753] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfbffe000 [ 2.841667] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 [ 2.841804] hub 1-0:1.0: USB hub found [ 2.841809] hub 1-0:1.0: 6 ports detected [ 2.841884] xen: registering gsi 23 triggering 0 polarity 1 [ 2.841888] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.841891] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.841893] Already setup the GSI :23 [ 2.841896] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) ->= IRQ 23 [ 2.841914] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 2.841919] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 2.841966] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bu= s number 2 [ 2.842007] ehci_hcd 0000:00:1d.7: debug port 1 [ 2.845901] ehci_hcd 0000:00:1d.7: cache line size of 64 is not suppor= ted [ 2.845919] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbffd000 [ 2.861667] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 [ 2.861792] hub 2-0:1.0: USB hub found [ 2.861797] hub 2-0:1.0: 6 ports detected [ 2.861871] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.861886] uhci_hcd: USB Universal Host Controller Interface driver [ 2.861905] xen: registering gsi 16 triggering 0 polarity 1 [ 2.861909] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.861912] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.861914] Already setup the GSI :16 [ 2.861917] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 2.861930] uhci_hcd 0000:00:1a.0: setting latency timer to 64 [ 2.861934] uhci_hcd 0000:00:1a.0: UHCI Host Controller [ 2.861981] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bu= s number 3 [ 2.862024] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000ff00 [ 2.862160] hub 3-0:1.0: USB hub found [ 2.862165] hub 3-0:1.0: 2 ports detected [ 2.862233] xen: registering gsi 21 triggering 0 polarity 1 [ 2.862237] xen_map_pirq_gsi: returning irq 21 for gsi 21 [ 2.862240] xen: --> pirq=3D21 -> irq=3D21 (gsi=3D21) [ 2.862242] Already setup the GSI :21 [ 2.862245] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) ->= IRQ 21 [ 2.862255] uhci_hcd 0000:00:1a.1: setting latency timer to 64 [ 2.862260] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 2.862310] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bu= s number 4 [ 2.862352] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000fe00 [ 2.862479] hub 4-0:1.0: USB hub found [ 2.862484] hub 4-0:1.0: 2 ports detected [ 2.862551] xen: registering gsi 18 triggering 0 polarity 1 [ 2.862556] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.862559] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.862561] Already setup the GSI :18 [ 2.862564] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.862574] uhci_hcd 0000:00:1a.2: setting latency timer to 64 [ 2.862579] uhci_hcd 0000:00:1a.2: UHCI Host Controller [ 2.862626] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bu= s number 5 [ 2.862656] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000fd00 [ 2.862781] hub 5-0:1.0: USB hub found [ 2.862786] hub 5-0:1.0: 2 ports detected [ 2.862854] xen: registering gsi 23 triggering 0 polarity 1 [ 2.862858] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.862861] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.862864] Already setup the GSI :23 [ 2.862867] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) ->= IRQ 23 [ 2.862877] uhci_hcd 0000:00:1d.0: setting latency timer to 64 [ 2.862881] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 2.862928] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bu= s number 6 [ 2.862959] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000fc00 [ 2.863090] hub 6-0:1.0: USB hub found [ 2.863095] hub 6-0:1.0: 2 ports detected [ 2.863165] xen: registering gsi 19 triggering 0 polarity 1 [ 2.863169] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 2.863172] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.863174] Already setup the GSI :19 [ 2.863177] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 2.863187] uhci_hcd 0000:00:1d.1: setting latency timer to 64 [ 2.863192] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 2.863239] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bu= s number 7 [ 2.863282] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000fb00 [ 2.863406] hub 7-0:1.0: USB hub found [ 2.863411] hub 7-0:1.0: 2 ports detected [ 2.863478] xen: registering gsi 18 triggering 0 polarity 1 [ 2.863483] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.863486] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.863488] Already setup the GSI :18 [ 2.863491] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.863501] uhci_hcd 0000:00:1d.2: setting latency timer to 64 [ 2.863506] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 2.863556] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bu= s number 8 [ 2.863588] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000fa00 [ 2.863713] hub 8-0:1.0: USB hub found [ 2.863718] hub 8-0:1.0: 2 ports detected [ 2.863832] usbcore: registered new interface driver libusual [ 2.863860] i8042: PNP: No PS/2 controller found. Probing ports direct= ly. [ 2.864282] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.864290] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.864434] mousedev: PS/2 mouse device common for all mice [ 2.864615] rtc_cmos 00:04: RTC can wake from S4 [ 2.864746] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.864778] rtc0: alarms up to one month, 242 bytes nvram [ 2.864840] device-mapper: uevent: version 1.0.3 [ 2.864917] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.864924] EFI Variables Facility v0.08 2004-May-17 [ 2.865139] TCP cubic registered [ 2.865218] NET: Registered protocol family 10 [ 2.865693] NET: Registered protocol family 17 [ 2.865709] Registering the dns_resolver key type [ 2.865853] PM: Hibernation image not present or could not be loaded. [ 2.865863] registered taskstats version 1 [ 2.874865] Magic number: 12:825:625 [ 2.874953] rtc_cmos 00:04: setting system clock to 2012-05-04 09:37:0= 7 UTC (1336124227) [ 2.875310] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.875313] EDD information not available. [ 3.125677] ata1: SATA link down (SStatus 0 SControl 300) [ 3.209669] usb 1-2: new high-speed USB device number 3 using ehci_hcd= [ 3.313680] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.313711] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.314188] ata8.00: ATAPI: TSSTcorp CDDVDW SH-S223Q, SB02, max UDMA/1= 00 [ 3.314514] ata7.00: HPA detected: current 976771055, native 976773168= [ 3.314603] ata7.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 3.314610] ata7.00: 976771055 sectors, multi 16: LBA48 NCQ (depth 31/= 32), AA [ 3.314919] ata8.00: configured for UDMA/100 [ 3.315569] ata7.00: configured for UDMA/133 [ 3.343469] hub 1-2:1.0: USB hub found [ 3.343799] hub 1-2:1.0: 4 ports detected [ 3.445676] ata2: SATA link down (SStatus 0 SControl 300) [ 3.581676] usb 3-1: new low-speed USB device number 2 using uhci_hcd [ 3.845940] usb 1-2.1: new full-speed USB device number 4 using ehci_h= cd [ 3.937680] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.938574] ata3.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 3.938581] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 3.939522] ata3.00: configured for UDMA/133 [ 3.939618] scsi 2:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 3.939738] sd 2:0:0:0: [sda] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 3.939764] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 3.939857] sd 2:0:0:0: [sda] Write Protect is off [ 3.939862] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.939910] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 3.952649] sda: sda1 < > [ 3.952948] sd 2:0:0:0: [sda] Attached SCSI disk [ 4.013936] usb 1-2.3: new high-speed USB device number 5 using ehci_h= cd [ 4.107479] hub 1-2.3:1.0: USB hub found [ 4.107808] hub 1-2.3:1.0: 4 ports detected [ 4.257672] ata4: SATA link down (SStatus 0 SControl 300) [ 4.377921] usb 1-2.3.3: new low-speed USB device number 6 using ehci_= hcd [ 4.749671] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.750538] ata5.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 4.750545] ata5.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 4.751475] ata5.00: configured for UDMA/133 [ 4.751552] scsi 4:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 4.751681] sd 4:0:0:0: Attached scsi generic sg1 type 0 [ 4.751686] sd 4:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 4.751768] sd 4:0:0:0: [sdb] Write Protect is off [ 4.751772] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 4.751797] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 4.759298] sdb: sdb1 < sdb5 > [ 4.759566] sd 4:0:0:0: [sdb] Attached SCSI disk [ 5.241676] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 5.242570] ata6.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 5.242577] ata6.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 5.243554] ata6.00: configured for UDMA/133 [ 5.243619] scsi 5:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 5.243730] sd 5:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 5.243742] sd 5:0:0:0: Attached scsi generic sg2 type 0 [ 5.243804] sd 5:0:0:0: [sdc] Write Protect is off [ 5.243809] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 5.243837] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 5.243867] scsi 6:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 5.243993] sd 6:0:0:0: [sdd] 976771055 512-byte logical blocks: (500 = GB/465 GiB) [ 5.244017] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 5.244084] sd 6:0:0:0: [sdd] Write Protect is off [ 5.244089] sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 5.244155] sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 5.244645] scsi 7:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223Q = SB02 PQ: 0 ANSI: 5 [ 5.247992] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 5.247999] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 5.248118] sr 7:0:0:0: Attached scsi CD-ROM sr0 [ 5.248197] sr 7:0:0:0: Attached scsi generic sg4 type 5 [ 5.250149] sdc: unknown partition table [ 5.250336] sd 5:0:0:0: [sdc] Attached SCSI disk [ 5.267374] sdd: sdd1 sdd2 sdd3 sdd4 [ 5.267760] sd 6:0:0:0: [sdd] Attached SCSI disk [ 5.268071] Freeing unused kernel memory: 920k freed [ 5.268219] Write protecting the kernel read-only data: 12288k [ 5.272885] Freeing unused kernel memory: 1520k freed [ 5.273494] Freeing unused kernel memory: 1140k freed [ 5.308013] udevd[132]: starting version 175 [ 5.331716] xor: automatically using best checksumming function: gener= ic_sse [ 5.349663] generic_sse: 2980.000 MB/sec [ 5.349671] xor: using function: generic_sse (2980.000 MB/sec) [ 5.350809] device-mapper: dm-raid45: initialized v0.2594b [ 5.390280] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.390312] xen: registering gsi 16 triggering 0 polarity 1 [ 5.390324] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 5.390329] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 5.390335] Already setup the GSI :16 [ 5.390341] r8169 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IR= Q 16 [ 5.390390] r8169 0000:06:00.0: setting latency timer to 64 [ 5.391065] r8169 0000:06:00.0: eth0: RTL8168d/8111d at 0xffffc90000c2= a000, 00:1f:d0:dc:30:92, XID 081000c0 IRQ 326 [ 5.391072] r8169 0000:06:00.0: eth0: jumbo features [frames: 9200 byt= es, tx checksumming: ko] [ 5.400017] xen: registering gsi 18 triggering 0 polarity 1 [ 5.400028] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 5.400033] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 5.400037] Already setup the GSI :18 [ 5.400045] firewire_ohci 0000:07:06.0: PCI INT A -> GSI 18 (level, lo= w) -> IRQ 18 [ 5.426325] input: HID 046a:0011 as /devices/pci0000:00/0000:00:1a.0/u= sb3/3-1/3-1:1.0/input/input2 [ 5.426466] generic-usb 0003:046A:0011.0001: input,hidraw0: USB HID v1= =2E11 Keyboard [HID 046a:0011] on usb-0000:00:1a.0-1/input0 [ 5.444109] input: Microsoft SideWinder Force Feedback 2 Joystick as /= devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.1/1-2.1:1.0/input/input3 [ 5.453759] firewire_ohci: Added fw-ohci device 0000:07:06.0, OHCI v1.= 10, 4 IR + 8 IT contexts, quirks 0x2 [ 5.457035] generic-usb 0003:045E:001B.0002: device reports 0 simultan= eous effects [ 5.466411] generic-usb 0003:045E:001B.0002: pid_block_load failed 60 = times [ 5.466415] generic-usb 0003:045E:001B.0002: upload request failed [ 5.466422] generic-usb 0003:045E:001B.0002: input,hidraw1: USB HID v1= =2E00 Joystick [Microsoft SideWinder Force Feedback 2 Joystick] on usb-00= 00:00:1a.7-2.1/input0 [ 5.468987] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000= :00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3:1.0/input/input4 [ 5.469093] generic-usb 0003:046D:C03F.0003: input,hidraw2: USB HID v1= =2E10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1a.7-2.3.3/i= nput0 [ 5.469114] usbcore: registered new interface driver usbhid [ 5.469116] usbhid: USB HID core driver [ 5.887488] EXT4-fs (dm-0): mounted filesystem with ordered data mode.= Opts: (null) [ 5.953765] firewire_core: created device fw0: GUID 00ac14fa00001fd0, = S400 [ 6.089730] device-mapper: dm-raid45: /dev/sda is raid disk 0 [ 6.089735] device-mapper: dm-raid45: /dev/sdb is raid disk 1 [ 6.089738] device-mapper: dm-raid45: /dev/sdc is raid disk 2 [ 6.089742] device-mapper: dm-raid45: 128/128/256 sectors chunk/io/rec= overy size, 80 stripes [ 6.089743] algorithm "xor_32", 8 chunks with 9687MB/s [ 6.089744] RAID5 (left asymmetric) set with net 2/3 devices [ 12.114699] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.138489] udevd[813]: starting version 175 [ 12.142198] Adding 8000364k swap on /dev/sdd3. Priority:-1 extents:1 = across:8000364k=20 [ 12.154311] lp: driver loaded but no devices found [ 12.163818] it87: Found IT8720F chip at 0x290, revision 5 [ 12.163831] it87: VID is disabled (pins used for GPIO) [ 12.163850] it87: Routing internal VCCH to in7 [ 12.163857] it87: Beeping is supported [ 12.180420] wmi: Mapper loaded [ 12.184995] [drm] Initialized drm 1.1.0 20060810 [ 12.200678] EDAC MC: Ver: 2.1.0 [ 12.202418] EDAC MC0: Giving out device to 'i7core_edac.c' 'i7 core #0= ': DEV 0000:3f:03.0 [ 12.202444] EDAC PCI0: Giving out device to module 'i7core_edac' contr= oller 'EDAC PCI controller': DEV '0000:3f:03.0' (POLLED) [ 12.202451] EDAC i7core: Driver loaded, 1 memory controller(s) found. [ 12.216439] xen: registering gsi 22 triggering 0 polarity 1 [ 12.216454] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 12.216462] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, lo= w) -> IRQ 22 [ 12.216611] snd_hda_intel 0000:00:1b.0: setting latency timer to 64 [ 12.217497] xen: registering gsi 18 triggering 0 polarity 1 [ 12.217502] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 12.217505] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 12.217508] Already setup the GSI :18 [ 12.217512] pata_jmicron 0000:05:00.1: PCI INT B -> GSI 18 (level, low= ) -> IRQ 18 [ 12.217548] pata_jmicron 0000:05:00.1: setting latency timer to 64 [ 12.218032] scsi8 : pata_jmicron [ 12.218152] scsi9 : pata_jmicron [ 12.219786] ata9: PATA max UDMA/100 cmd 0xdf00 ctl 0xde00 bmdma 0xdb00= irq 18 [ 12.219790] ata10: PATA max UDMA/100 cmd 0xdd00 ctl 0xdc00 bmdma 0xdb0= 8 irq 18 [ 12.263346] device-mapper: multipath: version 1.3.0 loaded [ 12.336747] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro [ 12.542332] hda_codec: ALC888: BIOS auto-probing. [ 12.543375] Bridge firewalling registered [ 12.548962] device eth0 entered promiscuous mode [ 12.551463] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/= sound/card0/input5 [ 12.551572] input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:= 1b.0/sound/card0/input6 [ 12.551683] input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1= b.0/sound/card0/input7 [ 12.551935] input: HDA Intel Front Headphone as /devices/pci0000:00/00= 00:00:1b.0/sound/card0/input8 [ 12.552150] input: HDA Intel Line-Out Side as /devices/pci0000:00/0000= :00:1b.0/sound/card0/input9 [ 12.552297] input: HDA Intel Line-Out CLFE as /devices/pci0000:00/0000= :00:1b.0/sound/card0/input10 [ 12.552399] input: HDA Intel Line-Out Surround as /devices/pci0000:00/= 0000:00:1b.0/sound/card0/input11 [ 12.552528] input: HDA Intel Line-Out Front as /devices/pci0000:00/000= 0:00:1b.0/sound/card0/input12 [ 12.615063] r8169 0000:06:00.0: eth0: link down [ 12.615074] r8169 0000:06:00.0: eth0: link down [ 12.615254] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.620123] ADDRCONF(NETDEV_UP): br0: link is not ready [ 12.634440] kjournald starting. Commit interval 5 seconds [ 12.634669] EXT3-fs (sdd2): using internal journal [ 12.634675] EXT3-fs (sdd2): mounted filesystem with ordered data mode [ 12.664546] type=3D1400 audit(1336117037.284:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D1318 comm=3D"appa= rmor_parser" [ 12.664683] type=3D1400 audit(1336117037.284:3): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1330 comm=3D"a= pparmor_parser" [ 12.664979] type=3D1400 audit(1336117037.284:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D1318 comm=3D"apparmor_parser" [ 12.664991] type=3D1400 audit(1336117037.284:5): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1330 comm=3D"apparmor_parser" [ 12.665196] type=3D1400 audit(1336117037.284:6): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D1318 comm=3D"apparmor_parser" [ 12.665259] type=3D1400 audit(1336117037.284:7): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1330 comm=3D"apparmor_parser" [ 12.982722] EXT4-fs (dm-1): mounted filesystem with ordered data mode.= Opts: (null) [ 13.813737] init: failsafe main process (1433) killed by TERM signal [ 13.866358] init: udev-fallback-graphics main process (1546) terminate= d with status 1 [ 13.878401] type=3D1400 audit(1336117038.500:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1589 comm=3D"a= pparmor_parser" [ 13.878607] type=3D1400 audit(1336117038.500:9): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1591 comm=3D"= apparmor_parser" [ 13.878617] type=3D1400 audit(1336117038.500:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1590 comm=3D"apparmor_parser" [ 13.878735] type=3D1400 audit(1336117038.500:11): apparmor=3D"STATUS" = operation=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-cli= ent.action" pid=3D1589 comm=3D"apparmor_parser" [ 14.084048] Event-channel device installed. [ 14.119852] XENBUS: Unable to read cpu state [ 14.119937] XENBUS: Unable to read cpu state [ 14.120029] XENBUS: Unable to read cpu state [ 14.120112] XENBUS: Unable to read cpu state [ 14.120190] XENBUS: Unable to read cpu state [ 14.120327] XENBUS: Unable to read cpu state [ 14.120421] XENBUS: Unable to read cpu state [ 14.120504] XENBUS: Unable to read cpu state [ 14.276690] ip_tables: (C) 2000-2006 Netfilter Core Team [ 14.328570] nf_conntrack version 0.5.0 (2648 buckets, 10592 max) [ 14.353742] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 15.006250] r8169 0000:06:00.0: eth0: link up [ 15.006398] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.007175] br0: port 1(eth0) entering forwarding state [ 15.007179] br0: port 1(eth0) entering forwarding state [ 15.007314] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 15.266765] Ebtables v2.0 registered [ 15.283111] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 25.249649] br0: no IPv6 routers present [ 140.007915] xen-acpi-processor: Max ACPI ID: 14 [ 140.009899] ACPI CPU0 - P-states uploaded. [ 140.009901] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009904] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009906] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009907] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009909] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009911] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009913] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009915] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009917] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009918] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009926] ACPI CPU1 - P-states uploaded. [ 140.009928] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009930] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009932] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009934] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009935] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009937] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009939] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009941] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009943] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009945] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009950] ACPI CPU2 - P-states uploaded. [ 140.009952] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009954] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009956] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009958] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009960] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009962] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009964] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009965] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009967] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009969] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009975] ACPI CPU3 - P-states uploaded. [ 140.009977] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009979] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009981] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009983] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009984] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009986] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009988] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009990] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009992] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009994] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009999] ACPI CPU4 - P-states uploaded. [ 140.010001] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010003] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010005] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010007] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010008] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010010] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010012] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010014] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010016] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010018] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010023] ACPI CPU5 - P-states uploaded. [ 140.010025] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010027] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010029] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010031] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010033] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010035] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010036] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010038] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010040] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010042] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010046] ACPI CPU6 - P-states uploaded. [ 140.010048] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010050] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010051] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010053] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010055] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010057] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010059] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010061] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010062] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010064] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010070] ACPI CPU7 - P-states uploaded. [ 140.010072] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010074] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010075] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010077] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010079] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010081] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010083] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010085] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010086] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010088] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010095] xen-acpi-processor: ACPI CPU0 w/ PBLK:0x410 [ 140.010184] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x410 [ 140.010269] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x410 [ 140.010356] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x410 [ 140.010441] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x410 [ 140.010526] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x410 [ 140.010611] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x410 [ 140.010696] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x410 [ 140.010781] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x410 [ 140.010787] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x410 [ 140.010793] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x410 [ 140.010798] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x410 [ 140.010804] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x410 [ 140.010809] xen-acpi-processor: ACPI CPU13 w/ PBLK:0x410 [ 140.010815] xen-acpi-processor: ACPI CPU14 w/ PBLK:0x410 [ 140.010820] xen-acpi-processor: ACPI CPU15 w/ PBLK:0x410 [ 140.011061] xen-acpi-processor: No _Cx for ACPI CPU 8 [ 140.011064] xen-acpi-processor: No _Cx for ACPI CPU 9 [ 140.011066] xen-acpi-processor: No _Cx for ACPI CPU 10 [ 140.011068] xen-acpi-processor: No _Cx for ACPI CPU 11 [ 140.011070] xen-acpi-processor: No _Cx for ACPI CPU 12 [ 140.011072] xen-acpi-processor: No _Cx for ACPI CPU 13 [ 140.011074] xen-acpi-processor: No _Cx for ACPI CPU 14 [ 183.118282] init: tty1 main process ended, respawning --------------070800050300030104070507 Content-Type: text/plain; charset=UTF-8; name="dmesg.opt.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.opt.txt" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg8 SMP Thu May 3 17:40:0= 6 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg8-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglev= el=3D10 earlyprintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.000000] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.000000] xxx xen_apic_read(0x30) -> 0x10 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.000000] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug lapic=3Ddebug console=3Dhvc0= loglevel=3D10 earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.170 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.34 BogoMIPS (lpj=3D8000680) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008086] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.017132] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019745] Mount-cache hash table entries: 256 [ 0.019990] Initializing cgroup subsys cpuacct [ 0.020001] Initializing cgroup subsys memory [ 0.020001] Initializing cgroup subsys devices [ 0.020001] Initializing cgroup subsys freezer [ 0.020001] Initializing cgroup subsys blkio [ 0.020001] Initializing cgroup subsys perf_event [ 0.020072] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.020077] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.020089] tseg: 00dff00000 [ 0.020096] CPU: Physical Processor ID: 0 [ 0.020100] CPU: Processor Core ID: 0 [ 0.023042] ACPI: Core revision 20110623 [ 0.039041] ftrace: allocating 27104 entries in 107 pages [ 0.040131] cpu 0 spinlock event irq 273 [ 0.040231] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040494] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040626] installing Xen timer for CPU 1 [ 0.040644] cpu 1 spinlock event irq 279 [ 0.004000] dom0=3D1 cpuid=3D1 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.040859] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040985] installing Xen timer for CPU 2 [ 0.041004] cpu 2 spinlock event irq 285 [ 0.004000] dom0=3D1 cpuid=3D2 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041173] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041291] installing Xen timer for CPU 3 [ 0.041306] cpu 3 spinlock event irq 291 [ 0.004000] dom0=3D1 cpuid=3D3 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041477] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041597] installing Xen timer for CPU 4 [ 0.041612] cpu 4 spinlock event irq 297 [ 0.004000] dom0=3D1 cpuid=3D4 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041808] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041935] installing Xen timer for CPU 5 [ 0.041951] cpu 5 spinlock event irq 303 [ 0.004000] dom0=3D1 cpuid=3D5 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042121] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042241] installing Xen timer for CPU 6 [ 0.042257] cpu 6 spinlock event irq 309 [ 0.004000] dom0=3D1 cpuid=3D6 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042422] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042541] installing Xen timer for CPU 7 [ 0.042557] cpu 7 spinlock event irq 315 [ 0.004000] dom0=3D1 cpuid=3D7 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042727] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042763] Brought up 8 CPUs [ 0.042991] devtmpfs: initialized [ 0.045406] EVM: security.selinux [ 0.045410] EVM: security.SMACK64 [ 0.045414] EVM: security.capability [ 0.045490] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045490] Grant table initialized [ 0.045490] print_constraints: dummy:=20 [ 0.045490] RTC time: 7:45:48, date: 05/04/12 [ 0.045490] NET: Registered protocol family 16 [ 0.045490] Trying to unpack rootfs image as initramfs... [ 0.060265] node 0 link 0: io port [1000, ffffff] [ 0.060279] TOM: 00000000e0000000 aka 3584M [ 0.060286] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060296] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060305] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060313] node 0 link 0: mmio [a0000, bffff] [ 0.060321] TOM2: 0000000820000000 aka 33280M [ 0.060326] bus: [00, 1f] on node 0 link 0 [ 0.060331] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060336] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060341] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060345] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060369] Extended Config Space enabled on 2 nodes [ 0.060539] ACPI: bus type pci registered [ 0.060643] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060652] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.181523] Freeing initrd memory: 40072k freed [ 0.219949] PCI: Using configuration type 1 for base access [ 0.221489] bio: create slab at 0 [ 0.221489] ACPI: Added _OSI(Module Device) [ 0.221489] ACPI: Added _OSI(Processor Device) [ 0.221489] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221489] ACPI: Added _OSI(Processor Aggregator Device) [ 0.224154] ACPI: EC: Look up EC in DSDT [ 0.228666] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253662] ACPI: Interpreter enabled [ 0.253671] ACPI: (supports S0 S1 S4 S5) [ 0.253715] ACPI: Using IOAPIC for interrupt routing [ 0.267308] ACPI: No dock devices found. [ 0.267371] HEST: Table parsing has been initialized. [ 0.267379] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267684] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268245] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268252] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268258] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268265] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268271] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268344] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268542] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268745] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268862] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268871] pci 0000:00:09.0: PME# disabled [ 0.268913] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.269029] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.269038] pci 0000:00:0a.0: PME# disabled [ 0.269100] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269138] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269158] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269178] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269198] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269218] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269238] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269347] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269374] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269497] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269524] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269658] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269727] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269885] pci 0000:00:12.2: supports D1 D2 [ 0.269890] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269900] pci 0000:00:12.2: PME# disabled [ 0.269940] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269967] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270090] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270117] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270253] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270291] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270449] pci 0000:00:13.2: supports D1 D2 [ 0.270454] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270464] pci 0000:00:13.2: PME# disabled [ 0.270509] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270700] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270844] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270925] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270953] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271126] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271255] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271316] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271384] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271474] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271587] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271703] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271767] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271833] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271926] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280070] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280080] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280204] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280239] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280284] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280341] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280522] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280533] pci 0000:02:00.0: PME# disabled [ 0.288055] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288144] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288183] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288206] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288229] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288437] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288452] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288462] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288500] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288507] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288514] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288520] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288527] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288562] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288973] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289046] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289157] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289332] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289340] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289346] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307588] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307762] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307897] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.308018] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308136] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308278] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308414] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308552] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308623] xen/balloon: Initialising balloon driver. [ 0.352000] xen-balloon: Initialising balloon driver. [ 0.352021] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352167] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352167] vgaarb: loaded [ 0.352167] vgaarb: bridge control possible 0000:01:04.0 [ 0.352240] i2c-core: driver [aat2870] using legacy suspend method [ 0.352245] i2c-core: driver [aat2870] using legacy resume method [ 0.352336] SCSI subsystem initialized [ 0.352409] libata version 3.00 loaded. [ 0.352409] usbcore: registered new interface driver usbfs [ 0.352409] usbcore: registered new interface driver hub [ 0.352409] usbcore: registered new device driver usb [ 0.352409] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356116] NetLabel: Initializing [ 0.356120] NetLabel: domain hash size =3D 128 [ 0.356125] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356141] NetLabel: unlabeled traffic allowed by default [ 0.356218] Switching to clocksource xen [ 0.365440] AppArmor: AppArmor Filesystem Enabled [ 0.365479] pnp: PnP ACPI init [ 0.365499] ACPI: bus type pnp registered [ 0.365893] pnp 00:00: [bus 00-ff] [ 0.365898] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365904] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365909] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365914] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365919] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365925] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365930] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366054] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366329] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366335] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366414] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366595] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366656] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366664] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367350] pnp 00:03: [dma 4] [ 0.367355] pnp 00:03: [io 0x0000-0x000f] [ 0.367360] pnp 00:03: [io 0x0081-0x0083] [ 0.367365] pnp 00:03: [io 0x0087] [ 0.367369] pnp 00:03: [io 0x0089-0x008b] [ 0.367374] pnp 00:03: [io 0x008f] [ 0.367378] pnp 00:03: [io 0x00c0-0x00df] [ 0.367436] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367463] pnp 00:04: [io 0x0070-0x0071] [ 0.367470] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367480] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367485] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367507] pnp 00:04: [irq 8] [ 0.367564] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367635] pnp 00:05: [io 0x0060] [ 0.367639] pnp 00:05: [io 0x0064] [ 0.367644] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367649] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367654] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367671] pnp 00:05: [irq 1] [ 0.367726] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367842] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367848] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367852] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367869] pnp 00:06: [irq 12] [ 0.367929] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367951] pnp 00:07: [io 0x0061] [ 0.368009] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368030] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368035] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368041] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368045] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368071] pnp 00:08: [irq 13] [ 0.368128] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368329] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368335] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368340] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368456] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368463] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368556] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368618] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368922] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368927] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.369011] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.369018] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.369025] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369526] pnp 00:0c: [io 0x0010-0x001f] [ 0.369531] pnp 00:0c: [io 0x0022-0x003f] [ 0.369536] pnp 00:0c: [io 0x0062-0x0063] [ 0.369540] pnp 00:0c: [io 0x0065-0x006f] [ 0.369545] pnp 00:0c: [io 0x0072-0x007f] [ 0.369549] pnp 00:0c: [io 0x0080] [ 0.369553] pnp 00:0c: [io 0x0084-0x0086] [ 0.369558] pnp 00:0c: [io 0x0088] [ 0.369562] pnp 00:0c: [io 0x008c-0x008e] [ 0.369566] pnp 00:0c: [io 0x0090-0x009f] [ 0.369571] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369575] pnp 00:0c: [io 0x00b1] [ 0.369580] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369584] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369589] pnp 00:0c: [io 0x0550-0x0551] [ 0.369593] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369597] pnp 00:0c: [io 0x040b] [ 0.369602] pnp 00:0c: [io 0x04d6] [ 0.369606] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369610] pnp 00:0c: [io 0x0c14] [ 0.369615] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369619] pnp 00:0c: [io 0x0c52] [ 0.369623] pnp 00:0c: [io 0x0c6c] [ 0.369627] pnp 00:0c: [io 0x0c6f] [ 0.369632] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369636] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369640] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369645] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369649] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369654] pnp 00:0c: [io 0x0800-0x089f] [ 0.369659] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369664] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369668] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369673] pnp 00:0c: [io 0x0900-0x090f] [ 0.369677] pnp 00:0c: [io 0x0910-0x091f] [ 0.369682] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369686] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369691] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369696] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369704] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369849] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369855] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369861] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369867] system 00:0c: [io 0x040b] has been reserved [ 0.369873] system 00:0c: [io 0x04d6] has been reserved [ 0.369878] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369884] system 00:0c: [io 0x0c14] has been reserved [ 0.369889] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369895] system 00:0c: [io 0x0c52] has been reserved [ 0.369901] system 00:0c: [io 0x0c6c] has been reserved [ 0.369906] system 00:0c: [io 0x0c6f] has been reserved [ 0.369912] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369918] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369923] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369929] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369935] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369944] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369950] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369955] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369961] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369967] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369973] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369980] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369986] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369993] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370547] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370553] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370558] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370563] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370576] pnp 00:0d: [irq 4] [ 0.370581] pnp 00:0d: [dma 0 disabled] [ 0.370705] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371284] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371289] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371295] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371300] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371305] Already setup the GSI :3 [ 0.371309] pnp 00:0e: [irq 3] [ 0.371314] pnp 00:0e: [dma 0 disabled] [ 0.371433] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371577] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371661] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371668] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372634] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372640] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372645] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372650] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372659] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372759] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372766] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372772] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372779] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372785] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372792] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373111] pnp: PnP ACPI: found 17 devices [ 0.373116] ACPI: ACPI bus type pnp unregistered [ 0.380486] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380513] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380551] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380558] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380568] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380582] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380588] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380598] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380612] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380630] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380640] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380663] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380681] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380696] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380706] pci 0000:00:09.0: setting latency timer to 64 [ 0.380717] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380728] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380740] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380749] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380765] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380770] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380775] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380781] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380786] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380792] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380798] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380804] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380809] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380816] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380822] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380828] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380833] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380839] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380877] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380883] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380940] NET: Registered protocol family 2 [ 0.383015] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388281] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391514] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391860] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391866] TCP reno registered [ 0.392022] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392296] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392549] NET: Registered protocol family 1 [ 0.392605] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392628] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392649] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120157] pci 0000:00:12.0: PCI INT A disabled [ 1.120188] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120202] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120207] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120212] Already setup the GSI :16 [ 1.120218] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204175] pci 0000:00:12.1: PCI INT A disabled [ 1.204209] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204223] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204228] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204233] Already setup the GSI :17 [ 1.204239] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204376] pci 0000:00:12.2: PCI INT B disabled [ 1.204391] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204397] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204401] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204405] Already setup the GSI :18 [ 1.204410] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288203] pci 0000:00:13.0: PCI INT A disabled [ 1.288235] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288248] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288253] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288259] Already setup the GSI :18 [ 1.288264] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372178] pci 0000:00:13.1: PCI INT A disabled [ 1.372212] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372238] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372256] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372392] pci 0000:00:13.2: PCI INT B disabled [ 1.372417] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372423] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372428] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372433] Already setup the GSI :18 [ 1.372437] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456174] pci 0000:00:14.5: PCI INT C disabled [ 1.456260] pci 0000:01:04.0: Boot video device [ 1.456268] PCI: CLS 64 bytes, default 64 [ 1.457351] audit: initializing netlink socket (disabled) [ 1.457370] type=3D2000 audit(1336117549.732:1): initialized [ 1.485594] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487850] VFS: Disk quotas dquot_6.5.2 [ 1.487931] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488646] fuse init (API version 7.17) [ 1.488820] msgmni has been set to 1479 [ 1.489539] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489597] io scheduler noop registered [ 1.489602] io scheduler deadline registered [ 1.489645] io scheduler cfq registered (default) [ 1.490128] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490164] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490353] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490364] ACPI: Power Button [PWRB] [ 1.490424] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490432] ACPI: Power Button [PWRF] [ 1.692991] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.693118] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.693300] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.693866] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.697843] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.722349] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.848430] hpet_acpi_add: no address or irqs in _CRS [ 1.848451] Linux agpgart interface v0.103 [ 1.852373] brd: module loaded [ 1.853467] loop: module loaded [ 1.853824] ahci 0000:00:11.0: version 3.0 [ 1.853849] xen: registering gsi 22 triggering 0 polarity 1 [ 1.853871] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.853890] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.854111] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.854121] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.855082] scsi0 : ahci [ 1.855199] scsi1 : ahci [ 1.855293] scsi2 : ahci [ 1.855392] scsi3 : ahci [ 1.855498] scsi4 : ahci [ 1.855590] scsi5 : ahci [ 1.856528] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.856537] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.856544] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.856552] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.856559] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.856566] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.857062] Fixed MDIO Bus: probed [ 1.857086] tun: Universal TUN/TAP device driver, 1.6 [ 1.857092] tun: (C) 1999-2004 Max Krasnyansky [ 1.857178] PPP generic driver version 2.4.2 [ 1.857328] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.857416] xen: registering gsi 17 triggering 0 polarity 1 [ 1.857425] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.857430] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.857435] Already setup the GSI :17 [ 1.857441] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.857474] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.857569] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.857582] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.857679] ehci_hcd 0000:00:12.2: debug port 1 [ 1.857734] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.868101] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.868295] hub 1-0:1.0: USB hub found [ 1.868303] hub 1-0:1.0: 6 ports detected [ 1.868553] xen: registering gsi 19 triggering 0 polarity 1 [ 1.868561] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.868566] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.868571] Already setup the GSI :19 [ 1.868576] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.868610] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.868733] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.868749] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.868809] ehci_hcd 0000:00:13.2: debug port 1 [ 1.868857] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.880099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.880312] hub 2-0:1.0: USB hub found [ 1.880320] hub 2-0:1.0: 6 ports detected [ 1.880437] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.880591] xen: registering gsi 16 triggering 0 polarity 1 [ 1.880598] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.880603] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.880608] Already setup the GSI :16 [ 1.880613] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.880648] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.880742] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.880808] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.940279] hub 3-0:1.0: USB hub found [ 1.940294] hub 3-0:1.0: 3 ports detected [ 1.940504] xen: registering gsi 16 triggering 0 polarity 1 [ 1.940512] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.940517] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.940521] Already setup the GSI :16 [ 1.940527] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.940562] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.940640] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.940680] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 2.000312] hub 4-0:1.0: USB hub found [ 2.000326] hub 4-0:1.0: 3 ports detected [ 2.000550] xen: registering gsi 18 triggering 0 polarity 1 [ 2.000558] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.000562] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.000567] Already setup the GSI :18 [ 2.000572] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.000607] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 2.000697] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 2.000763] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.060288] hub 5-0:1.0: USB hub found [ 2.060302] hub 5-0:1.0: 3 ports detected [ 2.060512] xen: registering gsi 18 triggering 0 polarity 1 [ 2.060520] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.060525] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.060530] Already setup the GSI :18 [ 2.060535] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.060569] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.060639] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.060679] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.120307] hub 6-0:1.0: USB hub found [ 2.120322] hub 6-0:1.0: 3 ports detected [ 2.120531] xen: registering gsi 18 triggering 0 polarity 1 [ 2.120539] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.120544] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.120548] Already setup the GSI :18 [ 2.120554] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.120589] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.120658] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.120697] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.176217] ata5: SATA link down (SStatus 0 SControl 300) [ 2.180292] hub 7-0:1.0: USB hub found [ 2.180305] hub 7-0:1.0: 2 ports detected [ 2.180389] uhci_hcd: USB Universal Host Controller Interface driver [ 2.180472] usbcore: registered new interface driver libusual [ 2.180529] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.183449] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.183462] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.183618] mousedev: PS/2 mouse device common for all mice [ 2.183827] rtc_cmos 00:04: RTC can wake from S4 [ 2.184001] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.184056] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.184170] device-mapper: uevent: version 1.0.3 [ 2.184272] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.184285] EFI Variables Facility v0.08 2004-May-17 [ 2.184602] TCP cubic registered [ 2.184733] NET: Registered protocol family 10 [ 2.185460] NET: Registered protocol family 17 [ 2.185485] Registering the dns_resolver key type [ 2.185692] PM: Hibernation image not present or could not be loaded. [ 2.185709] registered taskstats version 1 [ 2.192089] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.203117] Magic number: 12:269:773 [ 2.203129] hub 2-0:1.0: hash matches [ 2.203312] rtc_cmos 00:04: setting system clock to 2012-05-04 07:45:5= 0 UTC (1336117550) [ 2.203445] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.203553] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.203558] EDD information not available. [ 2.216671] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.330229] Initializing USB Mass Storage driver... [ 2.330450] scsi6 : usb-storage 2-2:1.0 [ 2.330530] usbcore: registered new interface driver usb-storage [ 2.330536] USB Mass Storage support registered. [ 2.352138] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352171] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352197] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352222] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352246] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.352815] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.353565] ata6.00: configured for UDMA/100 [ 2.361793] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361801] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.362506] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.362513] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.362961] ata1.00: configured for UDMA/133 [ 2.363111] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.363320] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363455] sd 0:0:0:0: [sda] Write Protect is off [ 2.363461] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.363501] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.363592] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363707] ata4.00: configured for UDMA/133 [ 2.364219] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.364226] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.364758] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.364765] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.365423] ata2.00: configured for UDMA/133 [ 2.365595] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.365803] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.365808] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.365866] ata3.00: configured for UDMA/133 [ 2.365956] sd 1:0:0:0: [sdb] Write Protect is off [ 2.365962] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.366002] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.366038] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.366232] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.366251] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.366340] sd 2:0:0:0: [sdc] Write Protect is off [ 2.366347] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.366389] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.366409] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.366595] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.366642] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.366810] sd 3:0:0:0: [sdd] Write Protect is off [ 2.366817] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.366855] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.367260] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.370973] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.370981] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.371158] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.371246] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.375170] sdd: unknown partition table [ 2.375459] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.376358] sdb: sdb1 sdb2 [ 2.376797] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.377565] sdc: unknown partition table [ 2.377850] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.480467] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.481471] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.482098] Freeing unused kernel memory: 920k freed [ 2.482415] Write protecting the kernel read-only data: 12288k [ 2.489624] Freeing unused kernel memory: 1520k freed [ 2.490773] Freeing unused kernel memory: 1140k freed [ 2.557089] udevd[165]: starting version 175 [ 2.636458] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.636467] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.636601] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.636626] xen: registering gsi 17 triggering 0 polarity 1 [ 2.636639] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.636644] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.636650] Already setup the GSI :17 [ 2.636656] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.636687] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.708140] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.749851] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.749861] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.749946] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.750112] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.750137] xen: registering gsi 18 triggering 0 polarity 1 [ 2.750148] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.750153] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.750159] Already setup the GSI :18 [ 2.750164] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.750195] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.861339] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.861348] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.861432] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.890458] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.890716] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.894400] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.894568] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.894593] usbcore: registered new interface driver usbhid [ 2.894599] usbhid: USB HID core driver [ 3.329089] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.329668] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.330387] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.331105] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.332076] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.332307] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.332917] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.333248] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.337387] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.341169] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.341766] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.345257] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 9.072230] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.826798] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.826809] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.857000] udevd[690]: starting version 175 [ 15.968225] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.993626] MCE: In-kernel MCE decoding enabled. [ 15.994765] lp: driver loaded but no devices found [ 15.994879] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.996578] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.996892] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.998543] type=3D1400 audit(1336117564.289:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D796 comm=3D"appar= mor_parser" [ 15.999196] type=3D1400 audit(1336117564.289:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D796 comm=3D"apparmor_parser" [ 15.999554] type=3D1400 audit(1336117564.289:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D796 comm=3D"apparmor_parser" [ 16.006597] EDAC MC: Ver: 2.1.0 [ 16.012142] ipmi message handler version 39.2 [ 16.012461] device-mapper: multipath: version 1.3.0 loaded [ 16.014209] ipmi device interface [ 16.017746] AMD64 EDAC driver v3.4.0 [ 16.021604] EDAC amd64: DRAM ECC enabled. [ 16.021668] EDAC amd64: F10h detected (node 0). [ 16.021752] EDAC MC: DCT0 chip selects: [ 16.021756] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.021760] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.021763] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.021766] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.021769] EDAC MC: DCT1 chip selects: [ 16.021771] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.021774] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.021777] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.021780] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.021783] EDAC amd64: using x8 syndromes. [ 16.021786] EDAC amd64: MCT channel count: 2 [ 16.021829] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 16.021833] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 16.021836] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 16.021839] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 16.021916] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 16.022350] IPMI System Interface driver. [ 16.022584] ipmi_si: probing via SMBIOS [ 16.022589] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 16.022593] ipmi_si: Adding SMBIOS-specified kcs state machine [ 16.022600] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 16.022975] EDAC amd64: DRAM ECC enabled. [ 16.022981] EDAC amd64: F10h detected (node 1). [ 16.023069] EDAC MC: DCT0 chip selects: [ 16.023076] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.023080] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.023083] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.023086] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.023088] EDAC MC: DCT1 chip selects: [ 16.023091] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.023098] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.023101] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.023104] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.023107] EDAC amd64: using x8 syndromes. [ 16.023110] EDAC amd64: MCT channel count: 2 [ 16.023170] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 16.023173] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 16.023180] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 16.023183] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 16.023295] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 16.023410] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 16.042005] Bridge firewalling registered [ 16.053097] device eth0 entered promiscuous mode [ 16.132100] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 16.151879] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 16.160814] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 16.160999] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.182200] ADDRCONF(NETDEV_UP): br0: link is not ready [ 16.319392] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.330234] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 17.144823] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.593397] EXT4-fs (dm-30): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.417104] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.419524] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.419662] br0: port 1(eth0) entering forwarding state [ 19.419679] br0: port 1(eth0) entering forwarding state [ 19.421850] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 23.013339] init: udev-fallback-graphics main process (1809) terminate= d with status 1 [ 23.151179] init: failsafe main process (1693) killed by TERM signal [ 23.262932] type=3D1400 audit(1336117571.553:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1907 comm=3D"apparmor_parser" [ 23.263053] type=3D1400 audit(1336117571.553:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1905 comm=3D"a= pparmor_parser" [ 23.263150] type=3D1400 audit(1336117571.553:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1908 comm=3D"= apparmor_parser" [ 23.263716] type=3D1400 audit(1336117571.553:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1905 comm=3D"apparmor_parser" [ 23.264106] type=3D1400 audit(1336117571.557:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1905 comm=3D"apparmor_parser" [ 23.264198] type=3D1400 audit(1336117571.557:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1909 c= omm=3D"apparmor_parser" [ 23.264557] type=3D1400 audit(1336117571.557:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1909 comm=3D"apparmor_parser" [ 23.264863] type=3D1400 audit(1336117571.557:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1911 comm=3D"= apparmor_parser" [ 23.544492] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 23.762025] ip_tables: (C) 2000-2006 Netfilter Core Team [ 23.862906] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 23.915808] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 24.143570] Event-channel device installed. [ 24.207277] XENBUS: Unable to read cpu state [ 24.207486] XENBUS: Unable to read cpu state [ 24.207676] XENBUS: Unable to read cpu state [ 24.207856] XENBUS: Unable to read cpu state [ 24.208129] XENBUS: Unable to read cpu state [ 24.208292] XENBUS: Unable to read cpu state [ 24.208467] XENBUS: Unable to read cpu state [ 24.208605] XENBUS: Unable to read cpu state [ 25.164557] Ebtables v2.0 registered [ 25.195793] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.556089] br0: no IPv6 routers present [ 112.342255] xen-acpi-processor: Max ACPI ID: 16 [ 112.344764] ACPI CPU1 - P-states uploaded. [ 112.344771] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344775] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344779] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344782] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344785] P4: 800 MHz, 4777 mW, 4 uS [ 112.344804] ACPI CPU2 - P-states uploaded. [ 112.344809] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344817] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344823] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344829] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344834] P4: 800 MHz, 4777 mW, 4 uS [ 112.344856] ACPI CPU3 - P-states uploaded. [ 112.344861] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344865] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344871] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344876] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344881] P4: 800 MHz, 4777 mW, 4 uS [ 112.344900] ACPI CPU4 - P-states uploaded. [ 112.344905] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344910] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344915] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344920] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344925] P4: 800 MHz, 4777 mW, 4 uS [ 112.344937] ACPI CPU5 - P-states uploaded. [ 112.344942] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344947] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344952] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344957] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344962] P4: 800 MHz, 4777 mW, 4 uS [ 112.344972] ACPI CPU6 - P-states uploaded. [ 112.344979] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344984] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344991] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344995] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345000] P4: 800 MHz, 4777 mW, 4 uS [ 112.345013] ACPI CPU7 - P-states uploaded. [ 112.345017] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.345022] P1: 1500 MHz, 8265 mW, 4 uS [ 112.345028] P2: 1200 MHz, 6825 mW, 4 uS [ 112.345033] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345037] P4: 800 MHz, 4777 mW, 4 uS [ 112.345049] ACPI CPU8 - P-states uploaded. [ 112.345054] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.345059] P1: 1500 MHz, 8265 mW, 4 uS [ 112.345064] P2: 1200 MHz, 6825 mW, 4 uS [ 112.345069] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345074] P4: 800 MHz, 4777 mW, 4 uS [ 112.345100] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x810 [ 112.345116] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x0 [ 112.345128] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x0 [ 112.345140] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x0 [ 112.345150] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x0 [ 112.345163] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x0 [ 112.345175] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x0 [ 112.345188] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x0 [ 112.345199] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x0 [ 112.345208] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x0 [ 112.345216] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x0 [ 112.345225] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x0 --------------070800050300030104070507-- --------------enigEB40C659F3DC487B0CD9A40F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPo4yoAAoJEOhnXe7L7s6j0tUQAMsHymTHwqeHbTo/kiHCjxZl 1w+ktvBCCllVo2/3/bIVTVS+Pgk4DFkoGqBlryls+hPV5c8dxkKExS7coEdpEghG ubIWV3XMjgKFBGSZME4qErtxFLLQKvzVqQc4EJW7h/6lRQX+bYVQ6tyEVp06b/// kie/HuC06wDICKt3L6NS6k3Gm3qznyvwcPnHqNJUTDVPvq9OAC3zRGKxTOI6l5W5 +stLQ8RqGbtRnsi/SXtWXo32toz+QBvEi6poMSEHIYMpAN1NkXRpt8uJkZZMRHj2 J5TINRgOMEBo5X505M1/PxOxw+yGR2bpPP3d+dTA7UYfraBWQ9ee9XhPV169urtd MkusPYneVkaxsWcBCIRgdcARztvXK3zH6FB8uyEwYzBB9rgCReOOAYLzgOAMU7TW UDV4RNGfboH2f2EeHCYEDpjxPSu/f8nj12Y99c1YLWl0n/BPsyEgu04VE91n5Fyn se+TSdds1ha3lZGictiDhhGkFD1hBWaTgu4m9xYxKq4PcUKvWze/2hy8xqbhx+nk G3EiIHBLXHPEMLZ28NUfb9/6y0j9JsocjAXALNVXJsVtn4WZpPjA2YQ5Uj1OCkEI gqvWKKfosEk1VOhNNLUablDyuUEiNxnXtmN1RvFfEm17ykmGpiIIdivJWUIR+dOV 3NGyl7Jf4tyDokh9n1eK =3IO6 -----END PGP SIGNATURE----- --------------enigEB40C659F3DC487B0CD9A40F-- --===============5525228139078192454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5525228139078192454==-- From xen-devel-bounces@lists.xen.org Fri May 04 08:01:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:01:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDRk-0001ui-S9; Fri, 04 May 2012 08:01:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDRi-0001uY-2N for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:00:59 +0000 Received: from [85.158.138.51:21612] by server-10.bemta-3.messagelabs.com id C6/58-29478-9BC83AF4; Fri, 04 May 2012 08:00:57 +0000 X-Env-Sender: stefan.bader@canonical.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336118450!25177657!1 X-Originating-IP: [91.189.89.112] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4361 invoked from network); 4 May 2012 08:00:50 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by server-3.tower-174.messagelabs.com with SMTP; 4 May 2012 08:00:50 -0000 Received: from p5b2e1f1c.dip.t-dialin.net ([91.46.31.28] 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 ) id 1SQDRS-0007Pq-O2; Fri, 04 May 2012 08:00:44 +0000 Message-ID: <4FA38CA0.3020601@canonical.com> Date: Fri, 04 May 2012 10:00:32 +0200 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> <4FA280DA.9080505@canonical.com> <4FA29A92.2040601@canonical.com> <20120503154620.GB3464@andromeda.dapyr.net> <20120503170858.GC9992@phenom.dumpdata.com> In-Reply-To: <20120503170858.GC9992@phenom.dumpdata.com> X-Enigmail-Version: 1.4 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Jan Beulich , Boris Ostrovsky Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5525228139078192454==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============5525228139078192454== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigEB40C659F3DC487B0CD9A40F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB40C659F3DC487B0CD9A40F Content-Type: multipart/mixed; boundary="------------070800050300030104070507" This is a multi-part message in MIME format. --------------070800050300030104070507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 19:08, Konrad Rzeszutek Wilk wrote: >>> Hmmm, so xen_apic_read is still correct... >>> >>> [ 0.000000] ACPI: Local APIC address 0xfee00000 >>> [ 0.000000] xxx xen_apic_read(20) >>> [ 0.000000] xxx xen_apic_read -> 10 >>> [ 0.000000] boot_cpu_physical_apicid =3D 0 >>> [ 0.000000] xxx xen_apic_read(30) >>> [ 0.000000] +- apic version =3D 10 >>> >>> there seems to be a slightly strange tweak (at least for me) in read_= apic_id... >>> >>> static inline unsigned int read_apic_id(void) >>> { >>> unsigned int reg; >>> >>> reg =3D apic_read(APIC_ID); // calls apic->read(reg) >>> >>> return apic->get_apic_id(reg); >> >> Duh!! Let me spin out a new patch that will do this. >=20 > Meaning bit-shift it. We ended up doing 10 >> 24 (get_apic_id does that= ) > which results in zero. So lets be a bit more cautious and over-write > the get_apic_id and set_apic_id and as well do the proper bit-shifting.= >=20 I can confirm that with this patch applied I can load the xen-acpi-proces= sor driver and see P-states changing in xenpm. No BIOS bug messages. Also tested on the i7 and it does still work. I am attaching the dmesg ou= tput of both runs. On the i7 the xen apic functions are called in two places and = for cpu#0 only. On AMD, I see additional call later and for all cpus while en= abling them. apic->read bails out, but apic->get_apic_id returns 0 (though I cou= ld see no immediate problem from that). Maybe that info is helpful for the next = stage. -Stefan > commit 4bb450ea9dca1b8d845f1b53ab6476615a32badf > Author: Konrad Rzeszutek Wilk > Date: Wed May 2 15:04:51 2012 -0400 >=20 > xen/apic: Return the APIC ID (and version) for CPU 0. > =20 > On x86_64 on AMD machines where the first APIC_ID is not zero, we g= et: > =20 > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) > BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 > BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 > =20 > which means that when the ACPI processor driver loads and > tries to parse the _Pxx states it fails to do as, as it > ends up calling acpi_get_cpuid which does this: > =20 > for_each_possible_cpu(i) { > if (cpu_physical_id(i) =3D=3D apic_id) > return i; > } > =20 > And the bootup CPU, has not been found so it fails and returns -1 > for the first CPU - which then subsequently in the loop that > "acpi_processor_get_info" does results in returning an error, which= > means that "acpi_processor_add" failing and per_cpu(processor) > is never set (and is NULL). > =20 > That means that when xen-acpi-processor tries to load (much much > later on) and parse the P-states it gets -ENODEV from > acpi_processor_register_performance() (which tries to read > the per_cpu(processor)) and fails to parse the data. > =20 > Reported-by: Stefan Bader > Suggested-by: Boris Ostrovsky > [v2: Bit-shift APIC ID by 24 bits] > Signed-off-by: Konrad Rzeszutek Wilk Tested-by: Stefan Bader >=20 > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..63d6c22 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -53,6 +53,9 @@ > #include > #include > #include > +#ifdef CONFIG_NUMA > +#include > +#endif > #include > #include > #include > @@ -809,9 +812,40 @@ static void xen_io_delay(void) > } > =20 > #ifdef CONFIG_X86_LOCAL_APIC > +static unsigned long xen_set_apic_id(unsigned int x) > +{ > + WARN_ON(1); > + return x; > +} > +static unsigned int xen_get_apic_id(unsigned long x) > +{ > + return (((x)>>24) & 0xFFu); > +} > static u32 xen_apic_read(u32 reg) > { > - return 0; > + struct xen_platform_op op =3D { > + .cmd =3D XENPF_get_cpuinfo, > + .interface_version =3D XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid =3D 0, > + }; > + int ret =3D 0; > + > + /* Shouldn't need this as APIC is turned off for PV, and we only > + * get called on the bootup processor. But just in case. */ > + if (!xen_initial_domain() || smp_processor_id()) > + return 0; > + > + if (reg =3D=3D APIC_LVR) > + return 0x10; > + > + if (reg !=3D APIC_ID) > + return 0; > + > + ret =3D HYPERVISOR_dom0_op(&op); > + if (ret) > + return 0; > + > + return op.u.pcpu_info.apic_id << 24; > } > =20 > static void xen_apic_write(u32 reg, u32 val) > @@ -849,6 +883,8 @@ static void set_xen_basic_apic_ops(void) > apic->icr_write =3D xen_apic_icr_write; > apic->wait_icr_idle =3D xen_apic_wait_icr_idle; > apic->safe_wait_icr_idle =3D xen_safe_apic_wait_icr_idle; > + apic->set_apic_id =3D xen_set_apic_id; > + apic->get_apic_id =3D xen_get_apic_id; > } > =20 > #endif > @@ -1294,6 +1330,9 @@ asmlinkage void __init xen_start_kernel(void) > */ > acpi_numa =3D -1; > #endif > +#if defined(CONFIG_NUMA) && defined(CONFIG_X86_32) > + numa_off =3D 1; > +#endif > =20 > pgd =3D (pgd_t *)xen_start_info->pt_base; > =20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------070800050300030104070507 Content-Type: text/plain; charset=UTF-8; name="dmesg.i7.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.i7.txt" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg8 SMP Thu May 3 17:40:0= 6 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg8-generic 3.2.16) [ 0.000000] Command line: placeholder root=3D/dev/mapper/rootvg-magrat= hea ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglevel=3D10 earlypr= intk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 97-100 pfn range: 105 pages freed [ 0.000000] 1-1 mapping on 97->100 [ 0.000000] 1-1 mapping on dfee0->100000 [ 0.000000] Released 105 pages of unused memory [ 0.000000] Set 131465 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000097000 (usable) [ 0.000000] Xen: 000000000009f800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfee0000 (usable) [ 0.000000] Xen: 00000000dfee0000 - 00000000dfee1000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee1000 - 00000000dfef0000 (ACPI data) [ 0.000000] Xen: 00000000dfef0000 - 00000000dff00000 (reserved) [ 0.000000] Xen: 00000000f0000000 - 00000000f4000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 0000000180120000 (usable) [ 0.000000] Xen: 0000000180120000 - 0000000220000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] DMI: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BI= OS F11 03/11/2010 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x180120 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfee0 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000f5cc0] f5cc0 [ 0.000000] initial memory mapped : 0 - 047e7000 [ 0.000000] Base memory trampoline at [ffff880000092000] 92000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfee0000 [ 0.000000] 0000000000 - 00dfee0000 page 4k [ 0.000000] kernel direct mapping tables up to dfee0000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-0000000180120000 [ 0.000000] 0100000000 - 0180120000 page 4k [ 0.000000] kernel direct mapping tables up to 180120000 @ 1f3f7000-20= 000000 [ 0.000000] xen: setting RW the range 1f7fb000 - 20000000 [ 0.000000] RAMDISK: 02060000 - 047e7000 [ 0.000000] ACPI: RSDP 00000000000f7680 00014 (v00 GBT ) [ 0.000000] ACPI: RSDT 00000000dfee1040 00040 (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: FACP 00000000dfee10c0 00074 (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: DSDT 00000000dfee1180 04BA7 (v01 GBT GBTUACPI 000= 01000 MSFT 0100000C) [ 0.000000] ACPI: FACS 00000000dfee0000 00040 [ 0.000000] ACPI: HPET 00000000dfee5f00 00038 (v01 GBT GBTUACPI 423= 02E31 GBTU 00000098) [ 0.000000] ACPI: MCFG 00000000dfee5f80 0003C (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: EUDS 00000000dfee5fc0 00470 (v01 GBT 000= 00000 00000000) [ 0.000000] ACPI: TAMG 00000000dfee6430 00B72 (v01 GBT GBT B0 545= 5312E BG?? 53450101) [ 0.000000] ACPI: APIC 00000000dfee5d80 0012C (v01 GBT GBTUACPI 423= 02E31 GBTU 01010101) [ 0.000000] ACPI: SSDT 00000000dfee6fb0 02FE4 (v01 INTEL PPM RCM 800= 00001 INTL 20061109) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(0x20) -> 0x0 [ 0.000000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.000000] xxx xen_apic_read(0x30) -> 0x10 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000000180120000 [ 0.000000] Initmem setup node 0 0000000000000000-0000000180120000 [ 0.000000] NODE_DATA [000000001fffb000 - 000000001fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x00180120 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000097 [ 0.000000] 0: 0x00000100 -> 0x000dfee0 [ 0.000000] 0: 0x00100000 -> 0x00180120 [ 0.000000] On node 0 totalpages: 1441671 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2153 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896800 pages, LIFO batch:31 [ 0.000000] Normal zone: 8197 pages used for memmap [ 0.000000] Normal zone: 516379 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] dfl dfl lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level= ) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] SMP: Allowing 16 CPUs, 8 hotplug CPUs [ 0.000000] xxx xen_apic_read(0x20) -> 0x0 [ 0.000000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 00a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000d= fee1000 [ 0.000000] PM: Registered nosave memory: 00000000dfee1000 - 00000000d= fef0000 [ 0.000000] PM: Registered nosave memory: 00000000dfef0000 - 00000000d= ff00000 [ 0.000000] PM: Registered nosave memory: 00000000dff00000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= 4000000 [ 0.000000] PM: Registered nosave memory: 00000000f4000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at dff00000 (gap: dff000= 00:10100000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 6 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88001fdeb000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] = 14 [0] 15=20 [ 2.348911] Built 1 zonelists in Node order, mobility grouping on. To= tal pages: 1415332 [ 2.348914] Policy zone: Normal [ 2.348917] Kernel command line: placeholder root=3D/dev/mapper/rootvg= -magrathea ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglevel=3D10 = earlyprintk=3Dxenboot [ 2.349396] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 2.378521] Placing 64MB software IO TLB between ffff880015400000 - ff= ff880019400000 [ 2.378525] software IO TLB at phys 0x15400000 - 0x19400000 [ 2.379958] Memory: 294916k/6292608k available (6654k kernel code, 525= 924k absent, 5471768k reserved, 6550k data, 920k init) [ 2.380035] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D16, Nodes=3D1 [ 2.380070] Hierarchical RCU implementation. [ 2.380072] RCU dyntick-idle grace-period acceleration is enabled. [ 2.380083] NR_IRQS:16640 nr_irqs:4096 16 [ 2.380142] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D0= [ 2.380145] xen: registering gsi 9 triggering 0 polarity 0 [ 2.380154] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 2.380159] xen: acpi sci 9 [ 2.380162] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 2.380166] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 2.380169] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 2.380173] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 2.380176] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 2.380179] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 2.380182] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 2.380186] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 2.380188] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 2.380190] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 2.380193] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 2.380197] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 2.380200] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 2.380204] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 2.380207] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 2.380210] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 2.382007] Console: colour VGA+ 80x25 [ 2.382011] console [hvc0] enabled, bootconsole disabled [ 2.390775] allocated 47185920 bytes of page_cgroup [ 2.390779] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 2.390818] Xen: using vcpuop timer interface [ 2.390825] installing Xen timer for CPU 0 [ 2.390854] Detected 2664.850 MHz processor. [ 2.390861] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 5329.70 BogoMIPS (lpj=3D10659400) [ 2.390866] pid_max: default: 32768 minimum: 301 [ 2.390896] Security Framework initialized [ 2.390906] AppArmor: AppArmor initialized [ 2.390908] Yama: becoming mindful. [ 2.393465] Dentry cache hash table entries: 1048576 (order: 11, 83886= 08 bytes) [ 2.395968] Inode-cache hash table entries: 524288 (order: 10, 4194304= bytes) [ 2.396755] Mount-cache hash table entries: 256 [ 2.396908] Initializing cgroup subsys cpuacct [ 2.396914] Initializing cgroup subsys memory [ 2.396926] Initializing cgroup subsys devices [ 2.396929] Initializing cgroup subsys freezer [ 2.396932] Initializing cgroup subsys blkio [ 2.396943] Initializing cgroup subsys perf_event [ 2.396999] CPU: Physical Processor ID: 0 [ 2.397001] CPU: Processor Core ID: 0 [ 2.399115] ACPI: Core revision 20110623 [ 2.408066] ftrace: allocating 27104 entries in 107 pages [ 2.414834] cpu 0 spinlock event irq 273 [ 2.414887] Performance Events: unsupported p6 CPU model 26 no PMU dri= ver, software events only. [ 2.415004] NMI watchdog disabled (cpu0): hardware events not enabled [ 2.415078] installing Xen timer for CPU 1 [ 2.415089] cpu 1 spinlock event irq 279 [ 2.415214] NMI watchdog disabled (cpu1): hardware events not enabled [ 2.415291] installing Xen timer for CPU 2 [ 2.415302] cpu 2 spinlock event irq 285 [ 2.415386] NMI watchdog disabled (cpu2): hardware events not enabled [ 2.415455] installing Xen timer for CPU 3 [ 2.415466] cpu 3 spinlock event irq 291 [ 2.415545] NMI watchdog disabled (cpu3): hardware events not enabled [ 2.415617] installing Xen timer for CPU 4 [ 2.415627] cpu 4 spinlock event irq 297 [ 2.415712] NMI watchdog disabled (cpu4): hardware events not enabled [ 2.415786] installing Xen timer for CPU 5 [ 2.415797] cpu 5 spinlock event irq 303 [ 2.415880] NMI watchdog disabled (cpu5): hardware events not enabled [ 2.415950] installing Xen timer for CPU 6 [ 2.415960] cpu 6 spinlock event irq 309 [ 2.416047] NMI watchdog disabled (cpu6): hardware events not enabled [ 2.416118] installing Xen timer for CPU 7 [ 2.416131] cpu 7 spinlock event irq 315 [ 2.416213] NMI watchdog disabled (cpu7): hardware events not enabled [ 2.416234] Brought up 8 CPUs [ 2.416605] devtmpfs: initialized [ 2.417654] EVM: security.selinux [ 2.417657] EVM: security.SMACK64 [ 2.417659] EVM: security.capability [ 2.417704] PM: Registering ACPI NVS region at dfee0000 (4096 bytes) [ 2.418293] Grant table initialized [ 2.418336] print_constraints: dummy:=20 [ 2.418372] RTC time: 9:37:06, date: 05/04/12 [ 2.418401] NET: Registered protocol family 16 [ 2.418497] Trying to unpack rootfs image as initramfs... [ 2.423099] ACPI: bus type pci registered [ 2.423174] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf00000= 00-0xf3ffffff] (base 0xf0000000) [ 2.423178] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E= 820 [ 2.440460] PCI: Using configuration type 1 for base access [ 2.441457] bio: create slab at 0 [ 2.441567] ACPI: Added _OSI(Module Device) [ 2.441570] ACPI: Added _OSI(Processor Device) [ 2.441573] ACPI: Added _OSI(3.0 _SCP Extensions) [ 2.441576] ACPI: Added _OSI(Processor Aggregator Device) [ 2.443539] ACPI: EC: Look up EC in DSDT [ 2.451390] ACPI Warning: Incorrect checksum in table [TAMG] - 0x0C, s= hould be 0x0B (20110623/tbutils-314) [ 2.454463] ACPI: Interpreter enabled [ 2.454468] ACPI: (supports S0 S3 S4 S5) [ 2.454494] ACPI: Using IOAPIC for interrupt routing [ 2.458582] Freeing initrd memory: 40476k freed [ 2.461357] ACPI: No dock devices found. [ 2.461362] HEST: Table not found. [ 2.461366] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 2.461499] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) [ 2.461744] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7= ] [ 2.461748] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff= ] [ 2.461751] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 2.461754] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x= 000dffff] [ 2.461758] pci_root PNP0A03:00: host bridge window [mem 0xdff00000-0x= febfffff] [ 2.461784] pci 0000:00:00.0: [8086:3405] type 0 class 0x000600 [ 2.461890] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold [ 2.461896] pci 0000:00:00.0: PME# disabled [ 2.461939] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604 [ 2.462052] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 2.462058] pci 0000:00:01.0: PME# disabled [ 2.462101] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604 [ 2.462214] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold [ 2.462220] pci 0000:00:03.0: PME# disabled [ 2.462266] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604 [ 2.462378] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold [ 2.462384] pci 0000:00:07.0: PME# disabled [ 2.462430] pci 0000:00:10.0: [8086:3425] type 0 class 0x000800 [ 2.462559] pci 0000:00:10.1: [8086:3426] type 0 class 0x000800 [ 2.462672] pci 0000:00:11.0: [8086:3427] type 0 class 0x000800 [ 2.462802] pci 0000:00:11.1: [8086:3428] type 0 class 0x000800 [ 2.462917] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800 [ 2.462939] pci 0000:00:13.0: reg 10: [mem 0xfbfff000-0xfbffffff] [ 2.463037] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold [ 2.463043] pci 0000:00:13.0: PME# disabled [ 2.463078] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800 [ 2.463209] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800 [ 2.463342] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800 [ 2.463476] pci 0000:00:15.0: [8086:342f] type 0 class 0x000800 [ 2.463596] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03 [ 2.463672] pci 0000:00:1a.0: reg 20: [io 0xff00-0xff1f] [ 2.463761] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03 [ 2.463836] pci 0000:00:1a.1: reg 20: [io 0xfe00-0xfe1f] [ 2.463928] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03 [ 2.464000] pci 0000:00:1a.2: reg 20: [io 0xfd00-0xfd1f] [ 2.464113] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03 [ 2.464148] pci 0000:00:1a.7: reg 10: [mem 0xfbffe000-0xfbffe3ff] [ 2.464305] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 2.464312] pci 0000:00:1a.7: PME# disabled [ 2.464357] pci 0000:00:1b.0: [8086:3a3e] type 0 class 0x000403 [ 2.464384] pci 0000:00:1b.0: reg 10: [mem 0xfbff4000-0xfbff7fff 64bit= ] [ 2.464508] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 2.464515] pci 0000:00:1b.0: PME# disabled [ 2.464549] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604 [ 2.464677] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 2.464683] pci 0000:00:1c.0: PME# disabled [ 2.464721] pci 0000:00:1c.1: [8086:3a42] type 1 class 0x000604 [ 2.464849] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold [ 2.464855] pci 0000:00:1c.1: PME# disabled [ 2.464897] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604 [ 2.465026] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 2.465032] pci 0000:00:1c.4: PME# disabled [ 2.465074] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03 [ 2.465149] pci 0000:00:1d.0: reg 20: [io 0xfc00-0xfc1f] [ 2.465238] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03 [ 2.465313] pci 0000:00:1d.1: reg 20: [io 0xfb00-0xfb1f] [ 2.465402] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03 [ 2.465477] pci 0000:00:1d.2: reg 20: [io 0xfa00-0xfa1f] [ 2.465582] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03 [ 2.465617] pci 0000:00:1d.7: reg 10: [mem 0xfbffd000-0xfbffd3ff] [ 2.465771] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 2.465779] pci 0000:00:1d.7: PME# disabled [ 2.465815] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604 [ 2.465928] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601 [ 2.466059] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800= (mask 000f) [ 2.466064] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290= (mask 000f) [ 2.466147] pci 0000:00:1f.2: [8086:2822] type 0 class 0x000104 [ 2.466182] pci 0000:00:1f.2: reg 10: [io 0xf900-0xf907] [ 2.466196] pci 0000:00:1f.2: reg 14: [io 0xf800-0xf803] [ 2.466211] pci 0000:00:1f.2: reg 18: [io 0xf700-0xf707] [ 2.466225] pci 0000:00:1f.2: reg 1c: [io 0xf600-0xf603] [ 2.466239] pci 0000:00:1f.2: reg 20: [io 0xf500-0xf51f] [ 2.466253] pci 0000:00:1f.2: reg 24: [mem 0xfbffc000-0xfbffc7ff] [ 2.466340] pci 0000:00:1f.2: PME# supported from D3hot [ 2.466346] pci 0000:00:1f.2: PME# disabled [ 2.466375] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05 [ 2.466402] pci 0000:00:1f.3: reg 10: [mem 0xfbffb000-0xfbffb0ff 64bit= ] [ 2.466441] pci 0000:00:1f.3: reg 20: [io 0x0500-0x051f] [ 2.466557] pci 0000:00:01.0: PCI bridge to [bus 01-01] [ 2.466656] pci 0000:02:00.0: [10de:05e1] type 0 class 0x000300 [ 2.466676] pci 0000:02:00.0: reg 10: [mem 0xf8000000-0xf8ffffff] [ 2.466696] pci 0000:02:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit= pref] [ 2.466717] pci 0000:02:00.0: reg 1c: [mem 0xf6000000-0xf7ffffff 64bit= ] [ 2.466730] pci 0000:02:00.0: reg 24: [io 0xef00-0xef7f] [ 2.466744] pci 0000:02:00.0: reg 30: [mem 0x00000000-0x0007ffff pref]= [ 2.472216] pci 0000:00:03.0: PCI bridge to [bus 02-02] [ 2.472227] pci 0000:00:03.0: bridge window [io 0xe000-0xefff] [ 2.472237] pci 0000:00:03.0: bridge window [mem 0xf6000000-0xf9ffff= ff] [ 2.472251] pci 0000:00:03.0: bridge window [mem 0xe0000000-0xefffff= ff 64bit pref] [ 2.472331] pci 0000:00:07.0: PCI bridge to [bus 03-03] [ 2.472414] pci 0000:00:1c.0: PCI bridge to [bus 04-04] [ 2.472521] pci 0000:05:00.0: [197b:2363] type 0 class 0x000101 [ 2.472649] pci 0000:05:00.0: reg 24: [mem 0xfbefe000-0xfbefffff] [ 2.472741] pci 0000:05:00.0: PME# supported from D3hot [ 2.472749] pci 0000:05:00.0: PME# disabled [ 2.472789] pci 0000:05:00.1: [197b:2363] type 0 class 0x000101 [ 2.472824] pci 0000:05:00.1: reg 10: [io 0xdf00-0xdf07] [ 2.472845] pci 0000:05:00.1: reg 14: [io 0xde00-0xde03] [ 2.472864] pci 0000:05:00.1: reg 18: [io 0xdd00-0xdd07] [ 2.472884] pci 0000:05:00.1: reg 1c: [io 0xdc00-0xdc03] [ 2.472904] pci 0000:05:00.1: reg 20: [io 0xdb00-0xdb0f] [ 2.473025] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. = You can enable it with 'pcie_aspm=3Dforce' [ 2.473045] pci 0000:00:1c.1: PCI bridge to [bus 05-05] [ 2.473051] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff] [ 2.473057] pci 0000:00:1c.1: bridge window [mem 0xfbe00000-0xfbefff= ff] [ 2.473161] pci 0000:06:00.0: [10ec:8168] type 0 class 0x000200 [ 2.473185] pci 0000:06:00.0: reg 10: [io 0xce00-0xceff] [ 2.473228] pci 0000:06:00.0: reg 18: [mem 0xfbbff000-0xfbbfffff 64bit= pref] [ 2.473256] pci 0000:06:00.0: reg 20: [mem 0xfbbf8000-0xfbbfbfff 64bit= pref] [ 2.473274] pci 0000:06:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]= [ 2.473374] pci 0000:06:00.0: supports D1 D2 [ 2.473376] pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3col= d [ 2.473384] pci 0000:06:00.0: PME# disabled [ 2.480327] pci 0000:00:1c.4: PCI bridge to [bus 06-06] [ 2.480338] pci 0000:00:1c.4: bridge window [io 0xc000-0xcfff] [ 2.480348] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfff= ff] [ 2.480363] pci 0000:00:1c.4: bridge window [mem 0xfbb00000-0xfbbfff= ff 64bit pref] [ 2.480446] pci 0000:07:06.0: [104c:8024] type 0 class 0x000c00 [ 2.480475] pci 0000:07:06.0: reg 10: [mem 0xfbdff000-0xfbdff7ff] [ 2.480491] pci 0000:07:06.0: reg 14: [mem 0xfbdf8000-0xfbdfbfff] [ 2.480606] pci 0000:07:06.0: supports D1 D2 [ 2.480608] pci 0000:07:06.0: PME# supported from D0 D1 D2 D3hot [ 2.480615] pci 0000:07:06.0: PME# disabled [ 2.480674] pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive d= ecode) [ 2.480684] pci 0000:00:1e.0: bridge window [mem 0xfbd00000-0xfbdfff= ff] [ 2.480694] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 2.480698] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 2.480701] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 2.480705] pci 0000:00:1e.0: bridge window [mem 0x000c0000-0x000dff= ff] (subtractive decode) [ 2.480708] pci 0000:00:1e.0: bridge window [mem 0xdff00000-0xfebfff= ff] (subtractive decode) [ 2.480766] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 2.481021] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT] [ 2.481077] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT] [ 2.481158] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT] [ 2.481215] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] [ 2.481382] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 2.481387] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 2.481390] ACPI _OSC control for PCIe not granted, disabling ASPM [ 2.511626] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 1= 2 14 15) [ 2.511725] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 1= 2 14 15) [ 2.511822] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 1= 2 14 15) [ 2.511918] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 1= 2 14 15) [ 2.512015] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12= 14 15) *0, disabled. [ 2.512113] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 1= 2 14 15) [ 2.512210] ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 *7 9 10 11 1= 2 14 15) [ 2.512306] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 *4 5 6 7 9 10 11 1= 2 14 15) [ 2.512365] xen/balloon: Initialising balloon driver. [ 2.528500] xen-balloon: Initialising balloon driver. [ 2.528525] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 2.528652] vgaarb: device added: PCI:0000:02:00.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 2.528658] vgaarb: loaded [ 2.528659] vgaarb: bridge control possible 0000:02:00.0 [ 2.528742] i2c-core: driver [aat2870] using legacy suspend method [ 2.528745] i2c-core: driver [aat2870] using legacy resume method [ 2.528802] SCSI subsystem initialized [ 2.528882] libata version 3.00 loaded. [ 2.528927] usbcore: registered new interface driver usbfs [ 2.528939] usbcore: registered new interface driver hub [ 2.528981] usbcore: registered new device driver usb [ 2.529085] PCI: Using ACPI for IRQ routing [ 2.531669] PCI: Discovered peer bus 3f [ 2.531705] pci 0000:3f:00.0: [8086:2c41] type 0 class 0x000600 [ 2.531765] pci 0000:3f:00.1: [8086:2c01] type 0 class 0x000600 [ 2.531826] pci 0000:3f:02.0: [8086:2c10] type 0 class 0x000600 [ 2.531878] pci 0000:3f:02.1: [8086:2c11] type 0 class 0x000600 [ 2.531936] pci 0000:3f:03.0: [8086:2c18] type 0 class 0x000600 [ 2.531990] pci 0000:3f:03.1: [8086:2c19] type 0 class 0x000600 [ 2.532044] pci 0000:3f:03.4: [8086:2c1c] type 0 class 0x000600 [ 2.532100] pci 0000:3f:04.0: [8086:2c20] type 0 class 0x000600 [ 2.532152] pci 0000:3f:04.1: [8086:2c21] type 0 class 0x000600 [ 2.532203] pci 0000:3f:04.2: [8086:2c22] type 0 class 0x000600 [ 2.532255] pci 0000:3f:04.3: [8086:2c23] type 0 class 0x000600 [ 2.532312] pci 0000:3f:05.0: [8086:2c28] type 0 class 0x000600 [ 2.532364] pci 0000:3f:05.1: [8086:2c29] type 0 class 0x000600 [ 2.532417] pci 0000:3f:05.2: [8086:2c2a] type 0 class 0x000600 [ 2.532470] pci 0000:3f:05.3: [8086:2c2b] type 0 class 0x000600 [ 2.532527] pci 0000:3f:06.0: [8086:2c30] type 0 class 0x000600 [ 2.532579] pci 0000:3f:06.1: [8086:2c31] type 0 class 0x000600 [ 2.532631] pci 0000:3f:06.2: [8086:2c32] type 0 class 0x000600 [ 2.532683] pci 0000:3f:06.3: [8086:2c33] type 0 class 0x000600 [ 2.533181] PCI: pci_cache_line_size set to 64 bytes [ 2.533395] reserve RAM buffer: 0000000000097000 - 000000000009ffff=20 [ 2.533399] reserve RAM buffer: 00000000dfee0000 - 00000000dfffffff=20 [ 2.533402] reserve RAM buffer: 0000000180120000 - 0000000183ffffff=20 [ 2.533484] NetLabel: Initializing [ 2.533487] NetLabel: domain hash size =3D 128 [ 2.533489] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 2.533498] NetLabel: unlabeled traffic allowed by default [ 2.533578] Switching to clocksource xen [ 2.539394] AppArmor: AppArmor Filesystem Enabled [ 2.539411] pnp: PnP ACPI init [ 2.539420] ACPI: bus type pnp registered [ 2.539581] pnp 00:00: [bus 00-3f] [ 2.539585] pnp 00:00: [io 0x0cf8-0x0cff] [ 2.539587] pnp 00:00: [io 0x0000-0x0cf7 window] [ 2.539590] pnp 00:00: [io 0x0d00-0xffff window] [ 2.539593] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 2.539596] pnp 00:00: [mem 0x000c0000-0x000dffff window] [ 2.539598] pnp 00:00: [mem 0xdff00000-0xfebfffff window] [ 2.539673] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)= [ 2.539822] pnp 00:01: [io 0x0010-0x001f] [ 2.539825] pnp 00:01: [io 0x0022-0x003f] [ 2.539827] pnp 00:01: [io 0x0044-0x005f] [ 2.539830] pnp 00:01: [io 0x0062-0x0063] [ 2.539832] pnp 00:01: [io 0x0065-0x006f] [ 2.539834] pnp 00:01: [io 0x0074-0x007f] [ 2.539837] pnp 00:01: [io 0x0091-0x0093] [ 2.539839] pnp 00:01: [io 0x00a2-0x00bf] [ 2.539841] pnp 00:01: [io 0x00e0-0x00ef] [ 2.539844] pnp 00:01: [io 0x04d0-0x04d1] [ 2.539846] pnp 00:01: [io 0x0290-0x029f] [ 2.539848] pnp 00:01: [io 0x0800-0x087f] [ 2.539850] pnp 00:01: [io 0x0290-0x0294] [ 2.539853] pnp 00:01: [io 0x0880-0x088f] [ 2.539927] system 00:01: [io 0x04d0-0x04d1] has been reserved [ 2.539930] system 00:01: [io 0x0290-0x029f] has been reserved [ 2.539934] system 00:01: [io 0x0800-0x087f] has been reserved [ 2.539937] system 00:01: [io 0x0290-0x0294] has been reserved [ 2.539940] system 00:01: [io 0x0880-0x088f] has been reserved [ 2.539944] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.539964] pnp 00:02: [dma 4] [ 2.539966] pnp 00:02: [io 0x0000-0x000f] [ 2.539968] pnp 00:02: [io 0x0080-0x0090] [ 2.539971] pnp 00:02: [io 0x0094-0x009f] [ 2.539973] pnp 00:02: [io 0x00c0-0x00df] [ 2.540007] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)= [ 2.540105] pnp 00:03: [irq 0 disabled] [ 2.540109] xen: registering gsi 8 triggering 1 polarity 0 [ 2.540114] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 2.540116] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 2.540123] pnp 00:03: [irq 8] [ 2.540125] pnp 00:03: [mem 0xfed00000-0xfed003ff] [ 2.540166] pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active)= [ 2.540220] pnp 00:04: [io 0x0070-0x0073] [ 2.540260] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 2.540276] pnp 00:05: [io 0x0061] [ 2.540313] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)= [ 2.540327] pnp 00:06: [io 0x00f0-0x00ff] [ 2.540330] xen: registering gsi 13 triggering 1 polarity 0 [ 2.540334] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 2.540336] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 2.540341] pnp 00:06: [irq 13] [ 2.540380] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 2.540755] pnp 00:07: [io 0x0400-0x04cf] [ 2.540758] pnp 00:07: [io 0x04d2-0x04ff] [ 2.540828] system 00:07: [io 0x0400-0x04cf] has been reserved [ 2.540832] system 00:07: [io 0x04d2-0x04ff] has been reserved [ 2.540836] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.541231] pnp 00:08: [mem 0xf0000000-0xf3ffffff] [ 2.541316] system 00:08: [mem 0xf0000000-0xf3ffffff] has been reserve= d [ 2.541320] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 2.541752] pnp 00:09: [mem 0x000d5200-0x000d7fff] [ 2.541756] pnp 00:09: [mem 0x000f0000-0x000f7fff] [ 2.541758] pnp 00:09: [mem 0x000f8000-0x000fbfff] [ 2.541761] pnp 00:09: [mem 0x000fc000-0x000fffff] [ 2.541764] pnp 00:09: [mem 0xdfee0000-0xdfefffff] [ 2.541766] pnp 00:09: [mem 0x00000000-0x0009ffff] [ 2.541769] pnp 00:09: [mem 0x00100000-0xdfedffff] [ 2.541771] pnp 00:09: [mem 0xfec00000-0xfec00fff] [ 2.541774] pnp 00:09: [mem 0xfed10000-0xfed1dfff] [ 2.541776] pnp 00:09: [mem 0xfed20000-0xfed8ffff] [ 2.541779] pnp 00:09: [mem 0xfee00000-0xfee00fff] [ 2.541781] pnp 00:09: [mem 0xffb00000-0xffb7ffff] [ 2.541784] pnp 00:09: [mem 0xfff00000-0xffffffff] [ 2.541786] pnp 00:09: [mem 0x000e0000-0x000effff] [ 2.541878] system 00:09: [mem 0x000d5200-0x000d7fff] could not be res= erved [ 2.541881] system 00:09: [mem 0x000f0000-0x000f7fff] could not be res= erved [ 2.541885] system 00:09: [mem 0x000f8000-0x000fbfff] could not be res= erved [ 2.541888] system 00:09: [mem 0x000fc000-0x000fffff] could not be res= erved [ 2.541891] system 00:09: [mem 0xdfee0000-0xdfefffff] could not be res= erved [ 2.541894] system 00:09: [mem 0x00000000-0x0009ffff] could not be res= erved [ 2.541897] system 00:09: [mem 0x00100000-0xdfedffff] could not be res= erved [ 2.541901] system 00:09: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 2.541904] system 00:09: [mem 0xfed10000-0xfed1dfff] has been reserve= d [ 2.541907] system 00:09: [mem 0xfed20000-0xfed8ffff] has been reserve= d [ 2.541910] system 00:09: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 2.541914] system 00:09: [mem 0xffb00000-0xffb7ffff] has been reserve= d [ 2.541917] system 00:09: [mem 0xfff00000-0xffffffff] has been reserve= d [ 2.541920] system 00:09: [mem 0x000e0000-0x000effff] could not be res= erved [ 2.541924] system 00:09: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 2.541960] pnp 00:0a: [mem 0xffb80000-0xffbfffff] [ 2.542018] pnp 00:0a: Plug and Play ACPI device, IDs INT0800 (active)= [ 2.542028] pnp: PnP ACPI: found 11 devices [ 2.542030] ACPI: ACPI bus type pnp unregistered [ 2.548697] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 2.548723] PCI: max bus depth: 1 pci_try_num: 2 [ 2.548819] pci 0000:00:1c.1: BAR 15: assigned [mem 0xf4000000-0xf41ff= fff 64bit pref] [ 2.548824] pci 0000:00:1c.0: BAR 14: assigned [mem 0xf4200000-0xf43ff= fff] [ 2.548827] pci 0000:00:1c.0: BAR 15: assigned [mem 0xf4400000-0xf45ff= fff 64bit pref] [ 2.548832] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] [ 2.548835] pci 0000:00:01.0: PCI bridge to [bus 01-01] [ 2.548852] pci 0000:02:00.0: BAR 6: assigned [mem 0xf9000000-0xf907ff= ff pref] [ 2.548855] pci 0000:00:03.0: PCI bridge to [bus 02-02] [ 2.548860] pci 0000:00:03.0: bridge window [io 0xe000-0xefff] [ 2.548867] pci 0000:00:03.0: bridge window [mem 0xf6000000-0xf9ffff= ff] [ 2.548873] pci 0000:00:03.0: bridge window [mem 0xe0000000-0xefffff= ff 64bit pref] [ 2.548882] pci 0000:00:07.0: PCI bridge to [bus 03-03] [ 2.548897] pci 0000:00:1c.0: PCI bridge to [bus 04-04] [ 2.548902] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff] [ 2.548910] pci 0000:00:1c.0: bridge window [mem 0xf4200000-0xf43fff= ff] [ 2.548916] pci 0000:00:1c.0: bridge window [mem 0xf4400000-0xf45fff= ff 64bit pref] [ 2.548926] pci 0000:00:1c.1: PCI bridge to [bus 05-05] [ 2.548930] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff] [ 2.548938] pci 0000:00:1c.1: bridge window [mem 0xfbe00000-0xfbefff= ff] [ 2.548944] pci 0000:00:1c.1: bridge window [mem 0xf4000000-0xf41fff= ff 64bit pref] [ 2.548955] pci 0000:06:00.0: BAR 6: assigned [mem 0xfbb00000-0xfbb1ff= ff pref] [ 2.548958] pci 0000:00:1c.4: PCI bridge to [bus 06-06] [ 2.548962] pci 0000:00:1c.4: bridge window [io 0xc000-0xcfff] [ 2.548970] pci 0000:00:1c.4: bridge window [mem 0xfbc00000-0xfbcfff= ff] [ 2.548976] pci 0000:00:1c.4: bridge window [mem 0xfbb00000-0xfbbfff= ff 64bit pref] [ 2.548986] pci 0000:00:1e.0: PCI bridge to [bus 07-07] [ 2.548993] pci 0000:00:1e.0: bridge window [mem 0xfbd00000-0xfbdfff= ff] [ 2.549012] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549023] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549028] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549036] pci 0000:00:01.0: setting latency timer to 64 [ 2.549044] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549047] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549050] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549052] Already setup the GSI :16 [ 2.549055] pci 0000:00:03.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549061] pci 0000:00:03.0: setting latency timer to 64 [ 2.549068] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549071] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549074] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549076] Already setup the GSI :16 [ 2.549079] pci 0000:00:07.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549086] pci 0000:00:07.0: setting latency timer to 64 [ 2.549096] pci 0000:00:1c.0: enabling device (0000 -> 0003) [ 2.549100] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549103] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549106] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549108] Already setup the GSI :16 [ 2.549111] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549119] pci 0000:00:1c.0: setting latency timer to 64 [ 2.549127] xen: registering gsi 17 triggering 0 polarity 1 [ 2.549133] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.549138] pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 2.549144] pci 0000:00:1c.1: setting latency timer to 64 [ 2.549153] xen: registering gsi 16 triggering 0 polarity 1 [ 2.549156] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.549159] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.549161] Already setup the GSI :16 [ 2.549164] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.549170] pci 0000:00:1c.4: setting latency timer to 64 [ 2.549181] pci 0000:00:1e.0: setting latency timer to 64 [ 2.549186] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 2.549189] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 2.549192] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 2.549195] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000dffff] [ 2.549198] pci_bus 0000:00: resource 8 [mem 0xdff00000-0xfebfffff] [ 2.549201] pci_bus 0000:02: resource 0 [io 0xe000-0xefff] [ 2.549205] pci_bus 0000:02: resource 1 [mem 0xf6000000-0xf9ffffff] [ 2.549208] pci_bus 0000:02: resource 2 [mem 0xe0000000-0xefffffff 64b= it pref] [ 2.549213] pci_bus 0000:04: resource 0 [io 0x1000-0x1fff] [ 2.549216] pci_bus 0000:04: resource 1 [mem 0xf4200000-0xf43fffff] [ 2.549220] pci_bus 0000:04: resource 2 [mem 0xf4400000-0xf45fffff 64b= it pref] [ 2.549224] pci_bus 0000:05: resource 0 [io 0xd000-0xdfff] [ 2.549228] pci_bus 0000:05: resource 1 [mem 0xfbe00000-0xfbefffff] [ 2.549232] pci_bus 0000:05: resource 2 [mem 0xf4000000-0xf41fffff 64b= it pref] [ 2.549236] pci_bus 0000:06: resource 0 [io 0xc000-0xcfff] [ 2.549239] pci_bus 0000:06: resource 1 [mem 0xfbc00000-0xfbcfffff] [ 2.549243] pci_bus 0000:06: resource 2 [mem 0xfbb00000-0xfbbfffff 64b= it pref] [ 2.549247] pci_bus 0000:07: resource 1 [mem 0xfbd00000-0xfbdfffff] [ 2.549251] pci_bus 0000:07: resource 4 [io 0x0000-0x0cf7] [ 2.549254] pci_bus 0000:07: resource 5 [io 0x0d00-0xffff] [ 2.549258] pci_bus 0000:07: resource 6 [mem 0x000a0000-0x000bffff] [ 2.549262] pci_bus 0000:07: resource 7 [mem 0x000c0000-0x000dffff] [ 2.549265] pci_bus 0000:07: resource 8 [mem 0xdff00000-0xfebfffff] [ 2.549269] pci_bus 0000:3f: resource 0 [io 0x0000-0xffff] [ 2.549272] pci_bus 0000:3f: resource 1 [mem 0x00000000-0xfffffffff] [ 2.549307] NET: Registered protocol family 2 [ 2.549520] IP route cache hash table entries: 65536 (order: 7, 524288= bytes) [ 2.550969] TCP established hash table entries: 262144 (order: 10, 419= 4304 bytes) [ 2.551996] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 2.552158] TCP: Hash tables configured (established 262144 bind 65536= ) [ 2.552161] TCP reno registered [ 2.552204] UDP hash table entries: 4096 (order: 5, 131072 bytes) [ 2.552268] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)= [ 2.552352] NET: Registered protocol family 1 [ 2.552399] xen: registering gsi 16 triggering 0 polarity 1 [ 2.552405] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.552407] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.552410] Already setup the GSI :16 [ 2.552413] pci 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 2.552437] pci 0000:00:1a.0: PCI INT A disabled [ 2.552446] xen: registering gsi 21 triggering 0 polarity 1 [ 2.552453] xen: --> pirq=3D21 -> irq=3D21 (gsi=3D21) [ 2.552458] pci 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ = 21 [ 2.552481] pci 0000:00:1a.1: PCI INT B disabled [ 2.552489] xen: registering gsi 18 triggering 0 polarity 1 [ 2.552495] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.552500] pci 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.552523] pci 0000:00:1a.2: PCI INT C disabled [ 2.552533] xen: registering gsi 18 triggering 0 polarity 1 [ 2.552536] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.552539] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.552541] Already setup the GSI :18 [ 2.552544] pci 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.565694] pci 0000:00:1a.7: PCI INT C disabled [ 2.565728] xen: registering gsi 23 triggering 0 polarity 1 [ 2.565736] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.565741] pci 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ = 23 [ 2.565763] pci 0000:00:1d.0: PCI INT A disabled [ 2.565772] xen: registering gsi 19 triggering 0 polarity 1 [ 2.565778] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.565782] pci 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 2.565805] pci 0000:00:1d.1: PCI INT B disabled [ 2.565813] xen: registering gsi 18 triggering 0 polarity 1 [ 2.565816] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.565819] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.565821] Already setup the GSI :18 [ 2.565824] pci 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 2.565846] pci 0000:00:1d.2: PCI INT C disabled [ 2.565857] xen: registering gsi 23 triggering 0 polarity 1 [ 2.565860] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.565862] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.565865] Already setup the GSI :23 [ 2.565867] pci 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ = 23 [ 2.581691] pci 0000:00:1d.7: PCI INT A disabled [ 2.581738] pci 0000:02:00.0: Boot video device [ 2.581791] PCI: CLS 64 bytes, default 64 [ 2.582332] audit: initializing netlink socket (disabled) [ 2.582344] type=3D2000 audit(1336124227.574:1): initialized [ 2.601350] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 2.602798] VFS: Disk quotas dquot_6.5.2 [ 2.602848] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 2.603292] fuse init (API version 7.17) [ 2.603394] msgmni has been set to 655 [ 2.603880] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 2.603921] io scheduler noop registered [ 2.603925] io scheduler deadline registered [ 2.603959] io scheduler cfq registered (default) [ 2.604276] pcieport 0000:00:1c.0: setting latency timer to 64 [ 2.604443] pcieport 0000:00:1c.1: setting latency timer to 64 [ 2.604593] pcieport 0000:00:1c.4: setting latency timer to 64 [ 2.604763] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 2.604784] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 2.604895] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 2.604901] ACPI: Power Button [PWRB] [ 2.604945] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 2.604949] ACPI: Power Button [PWRF] [ 2.609738] ERST: Table is not found! [ 2.609742] GHES: HEST is not enabled! [ 2.610105] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 2.764246] hpet_acpi_add: no address or irqs in _CRS [ 2.764262] Linux agpgart interface v0.103 [ 2.765650] brd: module loaded [ 2.766434] loop: module loaded [ 2.766554] ahci 0000:00:1f.2: version 3.0 [ 2.766567] xen: registering gsi 19 triggering 0 polarity 1 [ 2.766572] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 2.766575] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.766578] Already setup the GSI :19 [ 2.766581] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ= 19 [ 2.766663] ahci 0000:00:1f.2: controller can't do SNTF, turning off C= AP_SNTF [ 2.766686] ahci: SSS flag set, parallel bus scan disabled [ 2.766725] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps = 0x3f impl RAID mode [ 2.766729] ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pmp pi= o slum part ccc ems=20 [ 2.766736] ahci 0000:00:1f.2: setting latency timer to 64 [ 2.806086] scsi0 : ahci [ 2.806164] scsi1 : ahci [ 2.806231] scsi2 : ahci [ 2.806301] scsi3 : ahci [ 2.806367] scsi4 : ahci [ 2.806433] scsi5 : ahci [ 2.806671] ata1: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 100 irq 325 [ 2.806676] ata2: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 180 irq 325 [ 2.806679] ata3: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 200 irq 325 [ 2.806683] ata4: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 280 irq 325 [ 2.806687] ata5: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 300 irq 325 [ 2.806690] ata6: SATA max UDMA/133 abar m2048@0xfbffc000 port 0xfbffc= 380 irq 325 [ 2.806715] xen: registering gsi 17 triggering 0 polarity 1 [ 2.806719] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.806722] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.806724] Already setup the GSI :17 [ 2.806727] ahci 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ= 17 [ 2.821697] ahci 0000:05:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps = 0x3 impl SATA mode [ 2.821705] ahci 0000:05:00.0: flags: 64bit ncq pm led clo pmp pio slu= m part=20 [ 2.821717] ahci 0000:05:00.0: setting latency timer to 64 [ 2.821961] scsi6 : ahci [ 2.822036] scsi7 : ahci [ 2.822147] ata7: SATA max UDMA/133 abar m8192@0xfbefe000 port 0xfbefe= 100 irq 17 [ 2.822152] ata8: SATA max UDMA/133 abar m8192@0xfbefe000 port 0xfbefe= 180 irq 17 [ 2.822245] pata_acpi 0000:05:00.1: enabling device (0000 -> 0001) [ 2.822252] xen: registering gsi 18 triggering 0 polarity 1 [ 2.822257] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.822259] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.822262] Already setup the GSI :18 [ 2.822265] pata_acpi 0000:05:00.1: PCI INT B -> GSI 18 (level, low) -= > IRQ 18 [ 2.822293] pata_acpi 0000:05:00.1: setting latency timer to 64 [ 2.822308] pata_acpi 0000:05:00.1: PCI INT B disabled [ 2.822536] Fixed MDIO Bus: probed [ 2.822551] tun: Universal TUN/TAP device driver, 1.6 [ 2.822553] tun: (C) 1999-2004 Max Krasnyansky [ 2.822607] PPP generic driver version 2.4.2 [ 2.822704] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 2.822722] xen: registering gsi 18 triggering 0 polarity 1 [ 2.822727] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.822729] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.822732] Already setup the GSI :18 [ 2.822735] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.822753] ehci_hcd 0000:00:1a.7: setting latency timer to 64 [ 2.822758] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 2.822803] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bu= s number 1 [ 2.822850] ehci_hcd 0000:00:1a.7: debug port 1 [ 2.826735] ehci_hcd 0000:00:1a.7: cache line size of 64 is not suppor= ted [ 2.826753] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfbffe000 [ 2.841667] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 [ 2.841804] hub 1-0:1.0: USB hub found [ 2.841809] hub 1-0:1.0: 6 ports detected [ 2.841884] xen: registering gsi 23 triggering 0 polarity 1 [ 2.841888] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.841891] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.841893] Already setup the GSI :23 [ 2.841896] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) ->= IRQ 23 [ 2.841914] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 2.841919] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 2.841966] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bu= s number 2 [ 2.842007] ehci_hcd 0000:00:1d.7: debug port 1 [ 2.845901] ehci_hcd 0000:00:1d.7: cache line size of 64 is not suppor= ted [ 2.845919] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbffd000 [ 2.861667] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 [ 2.861792] hub 2-0:1.0: USB hub found [ 2.861797] hub 2-0:1.0: 6 ports detected [ 2.861871] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.861886] uhci_hcd: USB Universal Host Controller Interface driver [ 2.861905] xen: registering gsi 16 triggering 0 polarity 1 [ 2.861909] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 2.861912] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 2.861914] Already setup the GSI :16 [ 2.861917] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 2.861930] uhci_hcd 0000:00:1a.0: setting latency timer to 64 [ 2.861934] uhci_hcd 0000:00:1a.0: UHCI Host Controller [ 2.861981] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bu= s number 3 [ 2.862024] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000ff00 [ 2.862160] hub 3-0:1.0: USB hub found [ 2.862165] hub 3-0:1.0: 2 ports detected [ 2.862233] xen: registering gsi 21 triggering 0 polarity 1 [ 2.862237] xen_map_pirq_gsi: returning irq 21 for gsi 21 [ 2.862240] xen: --> pirq=3D21 -> irq=3D21 (gsi=3D21) [ 2.862242] Already setup the GSI :21 [ 2.862245] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) ->= IRQ 21 [ 2.862255] uhci_hcd 0000:00:1a.1: setting latency timer to 64 [ 2.862260] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 2.862310] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bu= s number 4 [ 2.862352] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000fe00 [ 2.862479] hub 4-0:1.0: USB hub found [ 2.862484] hub 4-0:1.0: 2 ports detected [ 2.862551] xen: registering gsi 18 triggering 0 polarity 1 [ 2.862556] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.862559] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.862561] Already setup the GSI :18 [ 2.862564] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.862574] uhci_hcd 0000:00:1a.2: setting latency timer to 64 [ 2.862579] uhci_hcd 0000:00:1a.2: UHCI Host Controller [ 2.862626] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bu= s number 5 [ 2.862656] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000fd00 [ 2.862781] hub 5-0:1.0: USB hub found [ 2.862786] hub 5-0:1.0: 2 ports detected [ 2.862854] xen: registering gsi 23 triggering 0 polarity 1 [ 2.862858] xen_map_pirq_gsi: returning irq 23 for gsi 23 [ 2.862861] xen: --> pirq=3D23 -> irq=3D23 (gsi=3D23) [ 2.862864] Already setup the GSI :23 [ 2.862867] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) ->= IRQ 23 [ 2.862877] uhci_hcd 0000:00:1d.0: setting latency timer to 64 [ 2.862881] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 2.862928] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bu= s number 6 [ 2.862959] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000fc00 [ 2.863090] hub 6-0:1.0: USB hub found [ 2.863095] hub 6-0:1.0: 2 ports detected [ 2.863165] xen: registering gsi 19 triggering 0 polarity 1 [ 2.863169] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 2.863172] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 2.863174] Already setup the GSI :19 [ 2.863177] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 2.863187] uhci_hcd 0000:00:1d.1: setting latency timer to 64 [ 2.863192] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 2.863239] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bu= s number 7 [ 2.863282] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000fb00 [ 2.863406] hub 7-0:1.0: USB hub found [ 2.863411] hub 7-0:1.0: 2 ports detected [ 2.863478] xen: registering gsi 18 triggering 0 polarity 1 [ 2.863483] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.863486] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.863488] Already setup the GSI :18 [ 2.863491] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.863501] uhci_hcd 0000:00:1d.2: setting latency timer to 64 [ 2.863506] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 2.863556] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bu= s number 8 [ 2.863588] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000fa00 [ 2.863713] hub 8-0:1.0: USB hub found [ 2.863718] hub 8-0:1.0: 2 ports detected [ 2.863832] usbcore: registered new interface driver libusual [ 2.863860] i8042: PNP: No PS/2 controller found. Probing ports direct= ly. [ 2.864282] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.864290] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.864434] mousedev: PS/2 mouse device common for all mice [ 2.864615] rtc_cmos 00:04: RTC can wake from S4 [ 2.864746] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.864778] rtc0: alarms up to one month, 242 bytes nvram [ 2.864840] device-mapper: uevent: version 1.0.3 [ 2.864917] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.864924] EFI Variables Facility v0.08 2004-May-17 [ 2.865139] TCP cubic registered [ 2.865218] NET: Registered protocol family 10 [ 2.865693] NET: Registered protocol family 17 [ 2.865709] Registering the dns_resolver key type [ 2.865853] PM: Hibernation image not present or could not be loaded. [ 2.865863] registered taskstats version 1 [ 2.874865] Magic number: 12:825:625 [ 2.874953] rtc_cmos 00:04: setting system clock to 2012-05-04 09:37:0= 7 UTC (1336124227) [ 2.875310] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.875313] EDD information not available. [ 3.125677] ata1: SATA link down (SStatus 0 SControl 300) [ 3.209669] usb 1-2: new high-speed USB device number 3 using ehci_hcd= [ 3.313680] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.313711] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.314188] ata8.00: ATAPI: TSSTcorp CDDVDW SH-S223Q, SB02, max UDMA/1= 00 [ 3.314514] ata7.00: HPA detected: current 976771055, native 976773168= [ 3.314603] ata7.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 3.314610] ata7.00: 976771055 sectors, multi 16: LBA48 NCQ (depth 31/= 32), AA [ 3.314919] ata8.00: configured for UDMA/100 [ 3.315569] ata7.00: configured for UDMA/133 [ 3.343469] hub 1-2:1.0: USB hub found [ 3.343799] hub 1-2:1.0: 4 ports detected [ 3.445676] ata2: SATA link down (SStatus 0 SControl 300) [ 3.581676] usb 3-1: new low-speed USB device number 2 using uhci_hcd [ 3.845940] usb 1-2.1: new full-speed USB device number 4 using ehci_h= cd [ 3.937680] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.938574] ata3.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 3.938581] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 3.939522] ata3.00: configured for UDMA/133 [ 3.939618] scsi 2:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 3.939738] sd 2:0:0:0: [sda] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 3.939764] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 3.939857] sd 2:0:0:0: [sda] Write Protect is off [ 3.939862] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.939910] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 3.952649] sda: sda1 < > [ 3.952948] sd 2:0:0:0: [sda] Attached SCSI disk [ 4.013936] usb 1-2.3: new high-speed USB device number 5 using ehci_h= cd [ 4.107479] hub 1-2.3:1.0: USB hub found [ 4.107808] hub 1-2.3:1.0: 4 ports detected [ 4.257672] ata4: SATA link down (SStatus 0 SControl 300) [ 4.377921] usb 1-2.3.3: new low-speed USB device number 6 using ehci_= hcd [ 4.749671] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.750538] ata5.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 4.750545] ata5.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 4.751475] ata5.00: configured for UDMA/133 [ 4.751552] scsi 4:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 4.751681] sd 4:0:0:0: Attached scsi generic sg1 type 0 [ 4.751686] sd 4:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 4.751768] sd 4:0:0:0: [sdb] Write Protect is off [ 4.751772] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 4.751797] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 4.759298] sdb: sdb1 < sdb5 > [ 4.759566] sd 4:0:0:0: [sdb] Attached SCSI disk [ 5.241676] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 5.242570] ata6.00: ATA-8: WDC WD5002ABYS-01B1B0, 02.03B02, max UDMA/= 133 [ 5.242577] ata6.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 5.243554] ata6.00: configured for UDMA/133 [ 5.243619] scsi 5:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 5.243730] sd 5:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 = GB/465 GiB) [ 5.243742] sd 5:0:0:0: Attached scsi generic sg2 type 0 [ 5.243804] sd 5:0:0:0: [sdc] Write Protect is off [ 5.243809] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 5.243837] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 5.243867] scsi 6:0:0:0: Direct-Access ATA WDC WD5002ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 5.243993] sd 6:0:0:0: [sdd] 976771055 512-byte logical blocks: (500 = GB/465 GiB) [ 5.244017] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 5.244084] sd 6:0:0:0: [sdd] Write Protect is off [ 5.244089] sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 5.244155] sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 5.244645] scsi 7:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223Q = SB02 PQ: 0 ANSI: 5 [ 5.247992] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 5.247999] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 5.248118] sr 7:0:0:0: Attached scsi CD-ROM sr0 [ 5.248197] sr 7:0:0:0: Attached scsi generic sg4 type 5 [ 5.250149] sdc: unknown partition table [ 5.250336] sd 5:0:0:0: [sdc] Attached SCSI disk [ 5.267374] sdd: sdd1 sdd2 sdd3 sdd4 [ 5.267760] sd 6:0:0:0: [sdd] Attached SCSI disk [ 5.268071] Freeing unused kernel memory: 920k freed [ 5.268219] Write protecting the kernel read-only data: 12288k [ 5.272885] Freeing unused kernel memory: 1520k freed [ 5.273494] Freeing unused kernel memory: 1140k freed [ 5.308013] udevd[132]: starting version 175 [ 5.331716] xor: automatically using best checksumming function: gener= ic_sse [ 5.349663] generic_sse: 2980.000 MB/sec [ 5.349671] xor: using function: generic_sse (2980.000 MB/sec) [ 5.350809] device-mapper: dm-raid45: initialized v0.2594b [ 5.390280] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 5.390312] xen: registering gsi 16 triggering 0 polarity 1 [ 5.390324] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 5.390329] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 5.390335] Already setup the GSI :16 [ 5.390341] r8169 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IR= Q 16 [ 5.390390] r8169 0000:06:00.0: setting latency timer to 64 [ 5.391065] r8169 0000:06:00.0: eth0: RTL8168d/8111d at 0xffffc90000c2= a000, 00:1f:d0:dc:30:92, XID 081000c0 IRQ 326 [ 5.391072] r8169 0000:06:00.0: eth0: jumbo features [frames: 9200 byt= es, tx checksumming: ko] [ 5.400017] xen: registering gsi 18 triggering 0 polarity 1 [ 5.400028] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 5.400033] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 5.400037] Already setup the GSI :18 [ 5.400045] firewire_ohci 0000:07:06.0: PCI INT A -> GSI 18 (level, lo= w) -> IRQ 18 [ 5.426325] input: HID 046a:0011 as /devices/pci0000:00/0000:00:1a.0/u= sb3/3-1/3-1:1.0/input/input2 [ 5.426466] generic-usb 0003:046A:0011.0001: input,hidraw0: USB HID v1= =2E11 Keyboard [HID 046a:0011] on usb-0000:00:1a.0-1/input0 [ 5.444109] input: Microsoft SideWinder Force Feedback 2 Joystick as /= devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.1/1-2.1:1.0/input/input3 [ 5.453759] firewire_ohci: Added fw-ohci device 0000:07:06.0, OHCI v1.= 10, 4 IR + 8 IT contexts, quirks 0x2 [ 5.457035] generic-usb 0003:045E:001B.0002: device reports 0 simultan= eous effects [ 5.466411] generic-usb 0003:045E:001B.0002: pid_block_load failed 60 = times [ 5.466415] generic-usb 0003:045E:001B.0002: upload request failed [ 5.466422] generic-usb 0003:045E:001B.0002: input,hidraw1: USB HID v1= =2E00 Joystick [Microsoft SideWinder Force Feedback 2 Joystick] on usb-00= 00:00:1a.7-2.1/input0 [ 5.468987] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000= :00/0000:00:1a.7/usb1/1-2/1-2.3/1-2.3.3/1-2.3.3:1.0/input/input4 [ 5.469093] generic-usb 0003:046D:C03F.0003: input,hidraw2: USB HID v1= =2E10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1a.7-2.3.3/i= nput0 [ 5.469114] usbcore: registered new interface driver usbhid [ 5.469116] usbhid: USB HID core driver [ 5.887488] EXT4-fs (dm-0): mounted filesystem with ordered data mode.= Opts: (null) [ 5.953765] firewire_core: created device fw0: GUID 00ac14fa00001fd0, = S400 [ 6.089730] device-mapper: dm-raid45: /dev/sda is raid disk 0 [ 6.089735] device-mapper: dm-raid45: /dev/sdb is raid disk 1 [ 6.089738] device-mapper: dm-raid45: /dev/sdc is raid disk 2 [ 6.089742] device-mapper: dm-raid45: 128/128/256 sectors chunk/io/rec= overy size, 80 stripes [ 6.089743] algorithm "xor_32", 8 chunks with 9687MB/s [ 6.089744] RAID5 (left asymmetric) set with net 2/3 devices [ 12.114699] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.138489] udevd[813]: starting version 175 [ 12.142198] Adding 8000364k swap on /dev/sdd3. Priority:-1 extents:1 = across:8000364k=20 [ 12.154311] lp: driver loaded but no devices found [ 12.163818] it87: Found IT8720F chip at 0x290, revision 5 [ 12.163831] it87: VID is disabled (pins used for GPIO) [ 12.163850] it87: Routing internal VCCH to in7 [ 12.163857] it87: Beeping is supported [ 12.180420] wmi: Mapper loaded [ 12.184995] [drm] Initialized drm 1.1.0 20060810 [ 12.200678] EDAC MC: Ver: 2.1.0 [ 12.202418] EDAC MC0: Giving out device to 'i7core_edac.c' 'i7 core #0= ': DEV 0000:3f:03.0 [ 12.202444] EDAC PCI0: Giving out device to module 'i7core_edac' contr= oller 'EDAC PCI controller': DEV '0000:3f:03.0' (POLLED) [ 12.202451] EDAC i7core: Driver loaded, 1 memory controller(s) found. [ 12.216439] xen: registering gsi 22 triggering 0 polarity 1 [ 12.216454] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 12.216462] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, lo= w) -> IRQ 22 [ 12.216611] snd_hda_intel 0000:00:1b.0: setting latency timer to 64 [ 12.217497] xen: registering gsi 18 triggering 0 polarity 1 [ 12.217502] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 12.217505] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 12.217508] Already setup the GSI :18 [ 12.217512] pata_jmicron 0000:05:00.1: PCI INT B -> GSI 18 (level, low= ) -> IRQ 18 [ 12.217548] pata_jmicron 0000:05:00.1: setting latency timer to 64 [ 12.218032] scsi8 : pata_jmicron [ 12.218152] scsi9 : pata_jmicron [ 12.219786] ata9: PATA max UDMA/100 cmd 0xdf00 ctl 0xde00 bmdma 0xdb00= irq 18 [ 12.219790] ata10: PATA max UDMA/100 cmd 0xdd00 ctl 0xdc00 bmdma 0xdb0= 8 irq 18 [ 12.263346] device-mapper: multipath: version 1.3.0 loaded [ 12.336747] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro [ 12.542332] hda_codec: ALC888: BIOS auto-probing. [ 12.543375] Bridge firewalling registered [ 12.548962] device eth0 entered promiscuous mode [ 12.551463] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/= sound/card0/input5 [ 12.551572] input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:= 1b.0/sound/card0/input6 [ 12.551683] input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1= b.0/sound/card0/input7 [ 12.551935] input: HDA Intel Front Headphone as /devices/pci0000:00/00= 00:00:1b.0/sound/card0/input8 [ 12.552150] input: HDA Intel Line-Out Side as /devices/pci0000:00/0000= :00:1b.0/sound/card0/input9 [ 12.552297] input: HDA Intel Line-Out CLFE as /devices/pci0000:00/0000= :00:1b.0/sound/card0/input10 [ 12.552399] input: HDA Intel Line-Out Surround as /devices/pci0000:00/= 0000:00:1b.0/sound/card0/input11 [ 12.552528] input: HDA Intel Line-Out Front as /devices/pci0000:00/000= 0:00:1b.0/sound/card0/input12 [ 12.615063] r8169 0000:06:00.0: eth0: link down [ 12.615074] r8169 0000:06:00.0: eth0: link down [ 12.615254] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.620123] ADDRCONF(NETDEV_UP): br0: link is not ready [ 12.634440] kjournald starting. Commit interval 5 seconds [ 12.634669] EXT3-fs (sdd2): using internal journal [ 12.634675] EXT3-fs (sdd2): mounted filesystem with ordered data mode [ 12.664546] type=3D1400 audit(1336117037.284:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D1318 comm=3D"appa= rmor_parser" [ 12.664683] type=3D1400 audit(1336117037.284:3): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1330 comm=3D"a= pparmor_parser" [ 12.664979] type=3D1400 audit(1336117037.284:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D1318 comm=3D"apparmor_parser" [ 12.664991] type=3D1400 audit(1336117037.284:5): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1330 comm=3D"apparmor_parser" [ 12.665196] type=3D1400 audit(1336117037.284:6): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D1318 comm=3D"apparmor_parser" [ 12.665259] type=3D1400 audit(1336117037.284:7): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1330 comm=3D"apparmor_parser" [ 12.982722] EXT4-fs (dm-1): mounted filesystem with ordered data mode.= Opts: (null) [ 13.813737] init: failsafe main process (1433) killed by TERM signal [ 13.866358] init: udev-fallback-graphics main process (1546) terminate= d with status 1 [ 13.878401] type=3D1400 audit(1336117038.500:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1589 comm=3D"a= pparmor_parser" [ 13.878607] type=3D1400 audit(1336117038.500:9): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1591 comm=3D"= apparmor_parser" [ 13.878617] type=3D1400 audit(1336117038.500:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1590 comm=3D"apparmor_parser" [ 13.878735] type=3D1400 audit(1336117038.500:11): apparmor=3D"STATUS" = operation=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-cli= ent.action" pid=3D1589 comm=3D"apparmor_parser" [ 14.084048] Event-channel device installed. [ 14.119852] XENBUS: Unable to read cpu state [ 14.119937] XENBUS: Unable to read cpu state [ 14.120029] XENBUS: Unable to read cpu state [ 14.120112] XENBUS: Unable to read cpu state [ 14.120190] XENBUS: Unable to read cpu state [ 14.120327] XENBUS: Unable to read cpu state [ 14.120421] XENBUS: Unable to read cpu state [ 14.120504] XENBUS: Unable to read cpu state [ 14.276690] ip_tables: (C) 2000-2006 Netfilter Core Team [ 14.328570] nf_conntrack version 0.5.0 (2648 buckets, 10592 max) [ 14.353742] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 15.006250] r8169 0000:06:00.0: eth0: link up [ 15.006398] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.007175] br0: port 1(eth0) entering forwarding state [ 15.007179] br0: port 1(eth0) entering forwarding state [ 15.007314] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 15.266765] Ebtables v2.0 registered [ 15.283111] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 25.249649] br0: no IPv6 routers present [ 140.007915] xen-acpi-processor: Max ACPI ID: 14 [ 140.009899] ACPI CPU0 - P-states uploaded. [ 140.009901] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009904] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009906] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009907] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009909] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009911] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009913] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009915] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009917] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009918] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009926] ACPI CPU1 - P-states uploaded. [ 140.009928] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009930] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009932] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009934] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009935] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009937] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009939] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009941] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009943] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009945] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009950] ACPI CPU2 - P-states uploaded. [ 140.009952] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009954] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009956] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009958] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009960] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009962] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009964] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009965] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009967] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009969] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009975] ACPI CPU3 - P-states uploaded. [ 140.009977] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.009979] P1: 2660 MHz, 130000 mW, 10 uS [ 140.009981] P2: 2527 MHz, 109000 mW, 10 uS [ 140.009983] P3: 2394 MHz, 100000 mW, 10 uS [ 140.009984] P4: 2261 MHz, 83000 mW, 10 uS [ 140.009986] P5: 2128 MHz, 76000 mW, 10 uS [ 140.009988] P6: 1995 MHz, 63000 mW, 10 uS [ 140.009990] P7: 1862 MHz, 57000 mW, 10 uS [ 140.009992] P8: 1729 MHz, 47000 mW, 10 uS [ 140.009994] P9: 1596 MHz, 43000 mW, 10 uS [ 140.009999] ACPI CPU4 - P-states uploaded. [ 140.010001] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010003] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010005] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010007] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010008] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010010] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010012] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010014] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010016] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010018] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010023] ACPI CPU5 - P-states uploaded. [ 140.010025] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010027] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010029] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010031] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010033] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010035] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010036] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010038] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010040] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010042] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010046] ACPI CPU6 - P-states uploaded. [ 140.010048] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010050] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010051] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010053] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010055] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010057] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010059] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010061] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010062] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010064] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010070] ACPI CPU7 - P-states uploaded. [ 140.010072] *P0: 2661 MHz, 130000 mW, 10 uS [ 140.010074] P1: 2660 MHz, 130000 mW, 10 uS [ 140.010075] P2: 2527 MHz, 109000 mW, 10 uS [ 140.010077] P3: 2394 MHz, 100000 mW, 10 uS [ 140.010079] P4: 2261 MHz, 83000 mW, 10 uS [ 140.010081] P5: 2128 MHz, 76000 mW, 10 uS [ 140.010083] P6: 1995 MHz, 63000 mW, 10 uS [ 140.010085] P7: 1862 MHz, 57000 mW, 10 uS [ 140.010086] P8: 1729 MHz, 47000 mW, 10 uS [ 140.010088] P9: 1596 MHz, 43000 mW, 10 uS [ 140.010095] xen-acpi-processor: ACPI CPU0 w/ PBLK:0x410 [ 140.010184] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x410 [ 140.010269] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x410 [ 140.010356] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x410 [ 140.010441] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x410 [ 140.010526] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x410 [ 140.010611] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x410 [ 140.010696] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x410 [ 140.010781] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x410 [ 140.010787] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x410 [ 140.010793] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x410 [ 140.010798] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x410 [ 140.010804] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x410 [ 140.010809] xen-acpi-processor: ACPI CPU13 w/ PBLK:0x410 [ 140.010815] xen-acpi-processor: ACPI CPU14 w/ PBLK:0x410 [ 140.010820] xen-acpi-processor: ACPI CPU15 w/ PBLK:0x410 [ 140.011061] xen-acpi-processor: No _Cx for ACPI CPU 8 [ 140.011064] xen-acpi-processor: No _Cx for ACPI CPU 9 [ 140.011066] xen-acpi-processor: No _Cx for ACPI CPU 10 [ 140.011068] xen-acpi-processor: No _Cx for ACPI CPU 11 [ 140.011070] xen-acpi-processor: No _Cx for ACPI CPU 12 [ 140.011072] xen-acpi-processor: No _Cx for ACPI CPU 13 [ 140.011074] xen-acpi-processor: No _Cx for ACPI CPU 14 [ 183.118282] init: tty1 main process ended, respawning --------------070800050300030104070507 Content-Type: text/plain; charset=UTF-8; name="dmesg.opt.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.opt.txt" [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.0-24-generic (root@gomeisa) (gcc version= 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #38+xendbg8 SMP Thu May 3 17:40:0= 6 UTC 2012 (Ubuntu 3.2.0-24.38+xendbg8-generic 3.2.16) [ 0.000000] Command line: placeholder root=3DUUID=3Df2b75052-a98e-447a= -bf78-51b2e1b15b8b ro nomodeset debug lapic=3Ddebug console=3Dhvc0 loglev= el=3D10 earlyprintk=3Dxenboot [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] Freeing 96-100 pfn range: 106 pages freed [ 0.000000] 1-1 mapping on 96->100 [ 0.000000] 1-1 mapping on dfe90->100000 [ 0.000000] Released 106 pages of unused memory [ 0.000000] Set 131546 page(s) to 1-1 mapping [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 0000000000096000 (usable) [ 0.000000] Xen: 0000000000096800 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000dfe90000 (usable) [ 0.000000] Xen: 00000000dfe9e000 - 00000000dfea0000 type 9 [ 0.000000] Xen: 00000000dfea0000 - 00000000dfeb2000 (ACPI data) [ 0.000000] Xen: 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) [ 0.000000] Xen: 00000000dfee0000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000100000000 - 00000002e0170000 (usable) [ 0.000000] Xen: 00000002e0170000 - 0000000820000000 (unusable) [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI present. [ 0.000000] DMI: Supermicro H8SGL/H8SGL, BIOS 1.1a 02/17/11 =20 [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (us= able) =3D=3D> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (us= able) [ 0.000000] No AGP bridge found [ 0.000000] last_pfn =3D 0x2e0170 max_arch_pfn =3D 0x400000000 [ 0.000000] last_pfn =3D 0xdfe90 max_arch_pfn =3D 0x400000000 [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780 [ 0.000000] initial memory mapped : 0 - 04782000 [ 0.000000] Base memory trampoline at [ffff880000091000] 91000 size 20= 480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000dfe90000 [ 0.000000] 0000000000 - 00dfe90000 page 4k [ 0.000000] kernel direct mapping tables up to dfe90000 @ 8fb000-10000= 00 [ 0.000000] xen: setting RW the range fd4000 - 1000000 [ 0.000000] init_memory_mapping: 0000000100000000-00000002e0170000 [ 0.000000] 0100000000 - 02e0170000 page 4k [ 0.000000] kernel direct mapping tables up to 2e0170000 @ 3e8f2000-40= 000000 [ 0.000000] xen: setting RW the range 3f7fb000 - 40000000 [ 0.000000] RAMDISK: 02060000 - 04782000 [ 0.000000] ACPI: RSDP 00000000000f9fc0 00024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 00000000dfea0100 00084 (v01 SMCI 201= 10217 MSFT 00000097) [ 0.000000] ACPI: FACP 00000000dfea0290 000F4 (v04 021711 FACP1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: DSDT 00000000dfea0610 05A04 (v02 1A711 1A711000 000= 00000 INTL 20051117) [ 0.000000] ACPI: FACS 00000000dfeb2000 00040 [ 0.000000] ACPI: APIC 00000000dfea0390 000B8 (v02 021711 APIC1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: MCFG 00000000dfea0450 0003C (v01 021711 OEMMCFG 201= 10217 MSFT 00000097) [ 0.000000] ACPI: OEMB 00000000dfeb2040 00075 (v01 021711 OEMB1552 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HPET 00000000dfeaa610 00038 (v01 021711 OEMHPET 201= 10217 MSFT 00000097) [ 0.000000] ACPI: IVRS 00000000dfeaa650 000A8 (v01 AMD RD890S 002= 02031 AMD 00000000) [ 0.000000] ACPI: SRAT 00000000dfeaa700 00128 (v02 AMD F10 000= 00001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000dfeaa830 0143C (v01 A M I POWERNOW 000= 00001 AMD 00000001) [ 0.000000] ACPI: EINJ 00000000dfeabc70 00130 (v01 AMIER AMI_EINJ 201= 10217 MSFT 00000097) [ 0.000000] ACPI: BERT 00000000dfeabe00 00030 (v01 AMIER AMI_BERT 201= 10217 MSFT 00000097) [ 0.000000] ACPI: ERST 00000000dfeabe30 001B0 (v01 AMIER AMI_ERST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: HEST 00000000dfeabfe0 000A8 (v01 AMIER ABC_HEST 201= 10217 MSFT 00000097) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.000000] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.000000] xxx xen_apic_read(0x30) -> 0x10 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] Number of physical nodes 2 [ 0.000000] Node 0 using interleaving mode 1/0 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-00000002e0170000 [ 0.000000] Initmem setup node 0 0000000000000000-00000002e0170000 [ 0.000000] NODE_DATA [000000003fffb000 - 000000003fffffff] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000010 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x002e0170 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000010 -> 0x00000096 [ 0.000000] 0: 0x00000100 -> 0x000dfe90 [ 0.000000] 0: 0x00100000 -> 0x002e0170 [ 0.000000] On node 0 totalpages: 2883462 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 1758 pages reserved [ 0.000000] DMA zone: 2152 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 16320 pages used for memmap [ 0.000000] DMA32 zone: 896720 pages, LIFO batch:31 [ 0.000000] Normal zone: 30726 pages used for memmap [ 0.000000] Normal zone: 1935722 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[0x10] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x11] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x12] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x13] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x15] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x16] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x17] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI= 0-255 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 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 12 CPUs, 4 hotplug CPUs [ 0.000000] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.000000] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.000000] nr_irqs_gsi: 272 [ 0.000000] PM: Registered nosave memory: 0000000000096000 - 000000000= 0097000 [ 0.000000] PM: Registered nosave memory: 0000000000097000 - 000000000= 0100000 [ 0.000000] PM: Registered nosave memory: 00000000dfe90000 - 00000000d= fe9e000 [ 0.000000] PM: Registered nosave memory: 00000000dfe9e000 - 00000000d= fea0000 [ 0.000000] PM: Registered nosave memory: 00000000dfea0000 - 00000000d= feb2000 [ 0.000000] PM: Registered nosave memory: 00000000dfeb2000 - 00000000d= fee0000 [ 0.000000] PM: Registered nosave memory: 00000000dfee0000 - 00000000f= 0000000 [ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f= ec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000f= ec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000f= ee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000f= ee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000f= fe00000 [ 0.000000] PM: Registered nosave memory: 00000000ffe00000 - 000000010= 0000000 [ 0.000000] Allocating PCI resources starting at f0000000 (gap: f00000= 00:ec00000) [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.1.2 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1= 2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fe5b000 s83072 r81= 92 d23424 u114688 [ 0.000000] pcpu-alloc: s83072 r8192 d23424 u114688 alloc=3D28*4096 [ 0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] = 06 [0] 07=20 [ 0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11=20 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. To= tal pages: 2834594 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=3DUUID=3Df2b75052-a9= 8e-447a-bf78-51b2e1b15b8b ro nomodeset debug lapic=3Ddebug console=3Dhvc0= loglevel=3D10 earlyprintk=3Dxenboot [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Placing 64MB software IO TLB between ffff88002f200000 - ff= ff880033200000 [ 0.000000] software IO TLB at phys 0x2f200000 - 0x33200000 [ 0.000000] Memory: 717456k/12060096k available (6654k kernel code, 52= 6248k absent, 10816392k reserved, 6550k data, 920k init) [ 0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects= =3D0, CPUs=3D12, Nodes=3D1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:16640 nr_irqs:3072 16 [ 0.000000] xen: sci override: global_irq=3D9 trigger=3D0 polarity=3D1= [ 0.000000] xen: registering gsi 9 triggering 0 polarity 1 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: acpi sci 9 [ 0.000000] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.000000] xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2) [ 0.000000] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.000000] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.000000] xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5) [ 0.000000] xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6) [ 0.000000] xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7) [ 0.000000] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9 [ 0.000000] xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9) [ 0.000000] xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10) [ 0.000000] xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11) [ 0.000000] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.000000] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.000000] xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14) [ 0.000000] xen: --> pirq=3D15 -> irq=3D15 (gsi=3D15) [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled, bootconsole disabled [ 0.000000] allocated 93323264 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=3Dmemory' option if you don't w= ant memory cgroups [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] Detected 2000.170 MHz processor. [ 0.004000] Calibrating delay loop (skipped), value calculated using t= imer frequency.. 4000.34 BogoMIPS (lpj=3D8000680) [ 0.004000] pid_max: default: 32768 minimum: 301 [ 0.004000] Security Framework initialized [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Yama: becoming mindful. [ 0.008086] Dentry cache hash table entries: 2097152 (order: 12, 16777= 216 bytes) [ 0.017132] Inode-cache hash table entries: 1048576 (order: 11, 838860= 8 bytes) [ 0.019745] Mount-cache hash table entries: 256 [ 0.019990] Initializing cgroup subsys cpuacct [ 0.020001] Initializing cgroup subsys memory [ 0.020001] Initializing cgroup subsys devices [ 0.020001] Initializing cgroup subsys freezer [ 0.020001] Initializing cgroup subsys blkio [ 0.020001] Initializing cgroup subsys perf_event [ 0.020072] xxx xen_apic_read(0x20) -> 0x10000000 [ 0.020077] xxx xen_get_apic_id(0x10000000) -> 0x10 [ 0.020089] tseg: 00dff00000 [ 0.020096] CPU: Physical Processor ID: 0 [ 0.020100] CPU: Processor Core ID: 0 [ 0.023042] ACPI: Core revision 20110623 [ 0.039041] ftrace: allocating 27104 entries in 107 pages [ 0.040131] cpu 0 spinlock event irq 273 [ 0.040231] Performance Events: Broken PMU hardware detected, using so= ftware events only. [ 0.040494] NMI watchdog disabled (cpu0): hardware events not enabled [ 0.040626] installing Xen timer for CPU 1 [ 0.040644] cpu 1 spinlock event irq 279 [ 0.004000] dom0=3D1 cpuid=3D1 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.040859] NMI watchdog disabled (cpu1): hardware events not enabled [ 0.040985] installing Xen timer for CPU 2 [ 0.041004] cpu 2 spinlock event irq 285 [ 0.004000] dom0=3D1 cpuid=3D2 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041173] NMI watchdog disabled (cpu2): hardware events not enabled [ 0.041291] installing Xen timer for CPU 3 [ 0.041306] cpu 3 spinlock event irq 291 [ 0.004000] dom0=3D1 cpuid=3D3 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041477] NMI watchdog disabled (cpu3): hardware events not enabled [ 0.041597] installing Xen timer for CPU 4 [ 0.041612] cpu 4 spinlock event irq 297 [ 0.004000] dom0=3D1 cpuid=3D4 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.041808] NMI watchdog disabled (cpu4): hardware events not enabled [ 0.041935] installing Xen timer for CPU 5 [ 0.041951] cpu 5 spinlock event irq 303 [ 0.004000] dom0=3D1 cpuid=3D5 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042121] NMI watchdog disabled (cpu5): hardware events not enabled [ 0.042241] installing Xen timer for CPU 6 [ 0.042257] cpu 6 spinlock event irq 309 [ 0.004000] dom0=3D1 cpuid=3D6 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042422] NMI watchdog disabled (cpu6): hardware events not enabled [ 0.042541] installing Xen timer for CPU 7 [ 0.042557] cpu 7 spinlock event irq 315 [ 0.004000] dom0=3D1 cpuid=3D7 [ 0.004000] xxx xen_get_apic_id(0x0) -> 0x0 [ 0.042727] NMI watchdog disabled (cpu7): hardware events not enabled [ 0.042763] Brought up 8 CPUs [ 0.042991] devtmpfs: initialized [ 0.045406] EVM: security.selinux [ 0.045410] EVM: security.SMACK64 [ 0.045414] EVM: security.capability [ 0.045490] PM: Registering ACPI NVS region at dfeb2000 (188416 bytes)= [ 0.045490] Grant table initialized [ 0.045490] print_constraints: dummy:=20 [ 0.045490] RTC time: 7:45:48, date: 05/04/12 [ 0.045490] NET: Registered protocol family 16 [ 0.045490] Trying to unpack rootfs image as initramfs... [ 0.060265] node 0 link 0: io port [1000, ffffff] [ 0.060279] TOM: 00000000e0000000 aka 3584M [ 0.060286] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.060296] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none [ 0.060305] node 0 link 0: mmio [f0000000, ffffffff] [ 0.060313] node 0 link 0: mmio [a0000, bffff] [ 0.060321] TOM2: 0000000820000000 aka 33280M [ 0.060326] bus: [00, 1f] on node 0 link 0 [ 0.060331] bus: 00 index 0 [io 0x0000-0xffff] [ 0.060336] bus: 00 index 1 [mem 0xf0000000-0xffffffff] [ 0.060341] bus: 00 index 2 [mem 0x000a0000-0x000bffff] [ 0.060345] bus: 00 index 3 [mem 0x820000000-0xfcffffffff] [ 0.060369] Extended Config Space enabled on 2 nodes [ 0.060539] ACPI: bus type pci registered [ 0.060643] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe00000= 00-0xefffffff] (base 0xe0000000) [ 0.060652] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E= 820 [ 0.181523] Freeing initrd memory: 40072k freed [ 0.219949] PCI: Using configuration type 1 for base access [ 0.221489] bio: create slab at 0 [ 0.221489] ACPI: Added _OSI(Module Device) [ 0.221489] ACPI: Added _OSI(Processor Device) [ 0.221489] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.221489] ACPI: Added _OSI(Processor Aggregator Device) [ 0.224154] ACPI: EC: Look up EC in DSDT [ 0.228666] ACPI: Executed 2 blocks of module-level executable AML cod= e [ 0.253662] ACPI: Interpreter enabled [ 0.253671] ACPI: (supports S0 S1 S4 S5) [ 0.253715] ACPI: Using IOAPIC for interrupt routing [ 0.267308] ACPI: No dock devices found. [ 0.267371] HEST: Table parsing has been initialized. [ 0.267379] PCI: Using host bridge windows from ACPI; if necessary, us= e "pci=3Dnocrs" and report a bug [ 0.267684] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.268245] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7= ] [ 0.268252] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff= ] [ 0.268258] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x= 000bffff] [ 0.268265] pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x= 000dffff] [ 0.268271] pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0x= febfffff] [ 0.268344] pci 0000:00:00.0: [1002:5a13] type 0 class 0x000600 [ 0.268542] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806 [ 0.268745] pci 0000:00:09.0: [1002:5a1c] type 1 class 0x000604 [ 0.268862] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold [ 0.268871] pci 0000:00:09.0: PME# disabled [ 0.268913] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604 [ 0.269029] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.269038] pci 0000:00:0a.0: PME# disabled [ 0.269100] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106 [ 0.269138] pci 0000:00:11.0: reg 10: [io 0xc000-0xc007] [ 0.269158] pci 0000:00:11.0: reg 14: [io 0xb000-0xb003] [ 0.269178] pci 0000:00:11.0: reg 18: [io 0xa000-0xa007] [ 0.269198] pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003] [ 0.269218] pci 0000:00:11.0: reg 20: [io 0x8000-0x800f] [ 0.269238] pci 0000:00:11.0: reg 24: [mem 0xfe9fa400-0xfe9fa7ff] [ 0.269347] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03 [ 0.269374] pci 0000:00:12.0: reg 10: [mem 0xfe9f6000-0xfe9f6fff] [ 0.269497] pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03 [ 0.269524] pci 0000:00:12.1: reg 10: [mem 0xfe9f7000-0xfe9f7fff] [ 0.269658] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03 [ 0.269727] pci 0000:00:12.2: reg 10: [mem 0xfe9fa800-0xfe9fa8ff] [ 0.269885] pci 0000:00:12.2: supports D1 D2 [ 0.269890] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.269900] pci 0000:00:12.2: PME# disabled [ 0.269940] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03 [ 0.269967] pci 0000:00:13.0: reg 10: [mem 0xfe9f8000-0xfe9f8fff] [ 0.270090] pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03 [ 0.270117] pci 0000:00:13.1: reg 10: [mem 0xfe9f9000-0xfe9f9fff] [ 0.270253] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03 [ 0.270291] pci 0000:00:13.2: reg 10: [mem 0xfe9fac00-0xfe9facff] [ 0.270449] pci 0000:00:13.2: supports D1 D2 [ 0.270454] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.270464] pci 0000:00:13.2: PME# disabled [ 0.270509] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05 [ 0.270700] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601 [ 0.270844] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604 [ 0.270925] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03 [ 0.270953] pci 0000:00:14.5: reg 10: [mem 0xfe9fb000-0xfe9fbfff] [ 0.271126] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600 [ 0.271255] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600 [ 0.271316] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600 [ 0.271384] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600 [ 0.271474] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600 [ 0.271587] pci 0000:00:19.0: [1022:1200] type 0 class 0x000600 [ 0.271703] pci 0000:00:19.1: [1022:1201] type 0 class 0x000600 [ 0.271767] pci 0000:00:19.2: [1022:1202] type 0 class 0x000600 [ 0.271833] pci 0000:00:19.3: [1022:1203] type 0 class 0x000600 [ 0.271926] pci 0000:00:19.4: [1022:1204] type 0 class 0x000600 [ 0.272016] pci 0000:03:00.0: [8086:10d3] type 0 class 0x000200 [ 0.272016] pci 0000:03:00.0: reg 10: [mem 0xfebe0000-0xfebfffff] [ 0.272016] pci 0000:03:00.0: reg 18: [io 0xe800-0xe81f] [ 0.272016] pci 0000:03:00.0: reg 1c: [mem 0xfebdc000-0xfebdffff] [ 0.272031] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.272042] pci 0000:03:00.0: PME# disabled [ 0.280056] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.280070] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.280080] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.280204] pci 0000:02:00.0: [8086:10d3] type 0 class 0x000200 [ 0.280239] pci 0000:02:00.0: reg 10: [mem 0xfeae0000-0xfeafffff] [ 0.280284] pci 0000:02:00.0: reg 18: [io 0xd800-0xd81f] [ 0.280341] pci 0000:02:00.0: reg 1c: [mem 0xfeadc000-0xfeadffff] [ 0.280522] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold [ 0.280533] pci 0000:02:00.0: PME# disabled [ 0.288055] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.288068] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.288077] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.288144] pci 0000:01:04.0: [102b:0532] type 0 class 0x000300 [ 0.288183] pci 0000:01:04.0: reg 10: [mem 0xfc000000-0xfcffffff pref]= [ 0.288206] pci 0000:01:04.0: reg 14: [mem 0xfdffc000-0xfdffffff] [ 0.288229] pci 0000:01:04.0: reg 18: [mem 0xfe000000-0xfe7fffff] [ 0.288437] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive d= ecode) [ 0.288452] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.288462] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.288500] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (sub= tractive decode) [ 0.288507] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (sub= tractive decode) [ 0.288514] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bff= ff] (subtractive decode) [ 0.288520] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dff= ff] (subtractive decode) [ 0.288527] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfff= ff] (subtractive decode) [ 0.288562] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.288973] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC09._PRT] [ 0.289046] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT] [ 0.289157] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] [ 0.289332] pci0000:00: Requesting ACPI _OSC control (0x1d) [ 0.289340] pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), retu= rned control mask: 0x1d [ 0.289346] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.307588] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 *7 10 11 12 14 15)= [ 0.307762] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)= [ 0.307897] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)= [ 0.308018] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 *14 15)= [ 0.308136] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 *15)= [ 0.308278] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308414] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)= [ 0.308552] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) = *0, disabled. [ 0.308623] xen/balloon: Initialising balloon driver. [ 0.352000] xen-balloon: Initialising balloon driver. [ 0.352021] xen/balloon: Xen selfballooning driver disabled for domain= 0. [ 0.352167] vgaarb: device added: PCI:0000:01:04.0,decodes=3Dio+mem,ow= ns=3Dio+mem,locks=3Dnone [ 0.352167] vgaarb: loaded [ 0.352167] vgaarb: bridge control possible 0000:01:04.0 [ 0.352240] i2c-core: driver [aat2870] using legacy suspend method [ 0.352245] i2c-core: driver [aat2870] using legacy resume method [ 0.352336] SCSI subsystem initialized [ 0.352409] libata version 3.00 loaded. [ 0.352409] usbcore: registered new interface driver usbfs [ 0.352409] usbcore: registered new interface driver hub [ 0.352409] usbcore: registered new device driver usb [ 0.352409] PCI: Using ACPI for IRQ routing [ 0.356021] PCI: pci_cache_line_size set to 64 bytes [ 0.356021] reserve RAM buffer: 0000000000096000 - 000000000009ffff=20 [ 0.356021] reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff=20 [ 0.356021] reserve RAM buffer: 00000002e0170000 - 00000002e3ffffff=20 [ 0.356116] NetLabel: Initializing [ 0.356120] NetLabel: domain hash size =3D 128 [ 0.356125] NetLabel: protocols =3D UNLABELED CIPSOv4 [ 0.356141] NetLabel: unlabeled traffic allowed by default [ 0.356218] Switching to clocksource xen [ 0.365440] AppArmor: AppArmor Filesystem Enabled [ 0.365479] pnp: PnP ACPI init [ 0.365499] ACPI: bus type pnp registered [ 0.365893] pnp 00:00: [bus 00-ff] [ 0.365898] pnp 00:00: [io 0x0cf8-0x0cff] [ 0.365904] pnp 00:00: [io 0x0000-0x0cf7 window] [ 0.365909] pnp 00:00: [io 0x0d00-0xffff window] [ 0.365914] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 0.365919] pnp 00:00: [mem 0x000d0000-0x000dffff window] [ 0.365925] pnp 00:00: [mem 0xe0000000-0xdfffffff window disabled] [ 0.365930] pnp 00:00: [mem 0xf0000000-0xfebfffff window] [ 0.366054] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 = (active) [ 0.366329] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366335] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled] [ 0.366414] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.366595] pnp 00:02: [mem 0xf6000000-0xf6003fff] [ 0.366656] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserve= d [ 0.366664] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.367350] pnp 00:03: [dma 4] [ 0.367355] pnp 00:03: [io 0x0000-0x000f] [ 0.367360] pnp 00:03: [io 0x0081-0x0083] [ 0.367365] pnp 00:03: [io 0x0087] [ 0.367369] pnp 00:03: [io 0x0089-0x008b] [ 0.367374] pnp 00:03: [io 0x008f] [ 0.367378] pnp 00:03: [io 0x00c0-0x00df] [ 0.367436] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)= [ 0.367463] pnp 00:04: [io 0x0070-0x0071] [ 0.367470] xen: registering gsi 8 triggering 1 polarity 0 [ 0.367480] xen_map_pirq_gsi: returning irq 8 for gsi 8 [ 0.367485] xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8) [ 0.367507] pnp 00:04: [irq 8] [ 0.367564] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)= [ 0.367635] pnp 00:05: [io 0x0060] [ 0.367639] pnp 00:05: [io 0x0064] [ 0.367644] xen: registering gsi 1 triggering 1 polarity 0 [ 0.367649] xen_map_pirq_gsi: returning irq 1 for gsi 1 [ 0.367654] xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1) [ 0.367671] pnp 00:05: [irq 1] [ 0.367726] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b = (active) [ 0.367842] xen: registering gsi 12 triggering 1 polarity 0 [ 0.367848] xen_map_pirq_gsi: returning irq 12 for gsi 12 [ 0.367852] xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12) [ 0.367869] pnp 00:06: [irq 12] [ 0.367929] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 = (active) [ 0.367951] pnp 00:07: [io 0x0061] [ 0.368009] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)= [ 0.368030] pnp 00:08: [io 0x00f0-0x00ff] [ 0.368035] xen: registering gsi 13 triggering 1 polarity 0 [ 0.368041] xen_map_pirq_gsi: returning irq 13 for gsi 13 [ 0.368045] xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13) [ 0.368071] pnp 00:08: [irq 13] [ 0.368128] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)= [ 0.368329] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368335] pnp 00:09: [io 0x0000-0xffffffffffffffff disabled] [ 0.368340] pnp 00:09: [io 0x0a10-0x0a1f] [ 0.368456] system 00:09: [io 0x0a10-0x0a1f] has been reserved [ 0.368463] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.368556] pnp 00:0a: [mem 0xfed00000-0xfed003ff] [ 0.368618] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)= [ 0.368922] pnp 00:0b: [mem 0xfec00000-0xfec00fff] [ 0.368927] pnp 00:0b: [mem 0xfee00000-0xfee00fff] [ 0.369011] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be res= erved [ 0.369018] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserve= d [ 0.369025] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.369526] pnp 00:0c: [io 0x0010-0x001f] [ 0.369531] pnp 00:0c: [io 0x0022-0x003f] [ 0.369536] pnp 00:0c: [io 0x0062-0x0063] [ 0.369540] pnp 00:0c: [io 0x0065-0x006f] [ 0.369545] pnp 00:0c: [io 0x0072-0x007f] [ 0.369549] pnp 00:0c: [io 0x0080] [ 0.369553] pnp 00:0c: [io 0x0084-0x0086] [ 0.369558] pnp 00:0c: [io 0x0088] [ 0.369562] pnp 00:0c: [io 0x008c-0x008e] [ 0.369566] pnp 00:0c: [io 0x0090-0x009f] [ 0.369571] pnp 00:0c: [io 0x00a2-0x00bf] [ 0.369575] pnp 00:0c: [io 0x00b1] [ 0.369580] pnp 00:0c: [io 0x00e0-0x00ef] [ 0.369584] pnp 00:0c: [io 0x0ca2-0x0ca3] [ 0.369589] pnp 00:0c: [io 0x0550-0x0551] [ 0.369593] pnp 00:0c: [io 0x04d0-0x04d1] [ 0.369597] pnp 00:0c: [io 0x040b] [ 0.369602] pnp 00:0c: [io 0x04d6] [ 0.369606] pnp 00:0c: [io 0x0c00-0x0c01] [ 0.369610] pnp 00:0c: [io 0x0c14] [ 0.369615] pnp 00:0c: [io 0x0c50-0x0c51] [ 0.369619] pnp 00:0c: [io 0x0c52] [ 0.369623] pnp 00:0c: [io 0x0c6c] [ 0.369627] pnp 00:0c: [io 0x0c6f] [ 0.369632] pnp 00:0c: [io 0x0cd0-0x0cd1] [ 0.369636] pnp 00:0c: [io 0x0cd2-0x0cd3] [ 0.369640] pnp 00:0c: [io 0x0cd4-0x0cd5] [ 0.369645] pnp 00:0c: [io 0x0cd6-0x0cd7] [ 0.369649] pnp 00:0c: [io 0x0cd8-0x0cdf] [ 0.369654] pnp 00:0c: [io 0x0800-0x089f] [ 0.369659] pnp 00:0c: [io 0x0000-0xffffffffffffffff disabled] [ 0.369664] pnp 00:0c: [io 0x0b00-0x0b0f] [ 0.369668] pnp 00:0c: [io 0x0b20-0x0b3f] [ 0.369673] pnp 00:0c: [io 0x0900-0x090f] [ 0.369677] pnp 00:0c: [io 0x0910-0x091f] [ 0.369682] pnp 00:0c: [io 0xfe00-0xfefe] [ 0.369686] pnp 00:0c: [io 0x0060-0x005f disabled] [ 0.369691] pnp 00:0c: [io 0x0064-0x0063 disabled] [ 0.369696] pnp 00:0c: [mem 0xffb80000-0xffbfffff] [ 0.369704] pnp 00:0c: [mem 0xfec10000-0xfec1001f] [ 0.369849] system 00:0c: [io 0x0ca2-0x0ca3] has been reserved [ 0.369855] system 00:0c: [io 0x0550-0x0551] has been reserved [ 0.369861] system 00:0c: [io 0x04d0-0x04d1] has been reserved [ 0.369867] system 00:0c: [io 0x040b] has been reserved [ 0.369873] system 00:0c: [io 0x04d6] has been reserved [ 0.369878] system 00:0c: [io 0x0c00-0x0c01] has been reserved [ 0.369884] system 00:0c: [io 0x0c14] has been reserved [ 0.369889] system 00:0c: [io 0x0c50-0x0c51] has been reserved [ 0.369895] system 00:0c: [io 0x0c52] has been reserved [ 0.369901] system 00:0c: [io 0x0c6c] has been reserved [ 0.369906] system 00:0c: [io 0x0c6f] has been reserved [ 0.369912] system 00:0c: [io 0x0cd0-0x0cd1] has been reserved [ 0.369918] system 00:0c: [io 0x0cd2-0x0cd3] has been reserved [ 0.369923] system 00:0c: [io 0x0cd4-0x0cd5] has been reserved [ 0.369929] system 00:0c: [io 0x0cd6-0x0cd7] has been reserved [ 0.369935] system 00:0c: [io 0x0cd8-0x0cdf] has been reserved [ 0.369944] system 00:0c: [io 0x0800-0x089f] has been reserved [ 0.369950] system 00:0c: [io 0x0b00-0x0b0f] has been reserved [ 0.369955] system 00:0c: [io 0x0b20-0x0b3f] has been reserved [ 0.369961] system 00:0c: [io 0x0900-0x090f] has been reserved [ 0.369967] system 00:0c: [io 0x0910-0x091f] has been reserved [ 0.369973] system 00:0c: [io 0xfe00-0xfefe] has been reserved [ 0.369980] system 00:0c: [mem 0xffb80000-0xffbfffff] has been reserve= d [ 0.369986] system 00:0c: [mem 0xfec10000-0xfec1001f] has been reserve= d [ 0.369993] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.370547] pnp 00:0d: [io 0x03f8-0x03ff] [ 0.370553] xen: registering gsi 4 triggering 1 polarity 0 [ 0.370558] xen_map_pirq_gsi: returning irq 4 for gsi 4 [ 0.370563] xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4) [ 0.370576] pnp 00:0d: [irq 4] [ 0.370581] pnp 00:0d: [dma 0 disabled] [ 0.370705] pnp 00:0d: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371284] pnp 00:0e: [io 0x02f8-0x02ff] [ 0.371289] xen: registering gsi 3 triggering 1 polarity 0 [ 0.371295] xen_map_pirq_gsi: returning irq 3 for gsi 3 [ 0.371300] xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3) [ 0.371305] Already setup the GSI :3 [ 0.371309] pnp 00:0e: [irq 3] [ 0.371314] pnp 00:0e: [dma 0 disabled] [ 0.371433] pnp 00:0e: Plug and Play ACPI device, IDs PNP0501 (active)= [ 0.371577] pnp 00:0f: [mem 0xe0000000-0xefffffff] [ 0.371661] system 00:0f: [mem 0xe0000000-0xefffffff] has been reserve= d [ 0.371668] system 00:0f: Plug and Play ACPI device, IDs PNP0c02 (acti= ve) [ 0.372634] pnp 00:10: [mem 0x00000000-0x0009ffff] [ 0.372640] pnp 00:10: [mem 0x000c0000-0x000cffff] [ 0.372645] pnp 00:10: [mem 0x000e0000-0x000fffff] [ 0.372650] pnp 00:10: [mem 0x00100000-0xdfffffff] [ 0.372659] pnp 00:10: [mem 0xfec00000-0xffffffff] [ 0.372759] system 00:10: [mem 0x00000000-0x0009ffff] could not be res= erved [ 0.372766] system 00:10: [mem 0x000c0000-0x000cffff] could not be res= erved [ 0.372772] system 00:10: [mem 0x000e0000-0x000fffff] could not be res= erved [ 0.372779] system 00:10: [mem 0x00100000-0xdfffffff] could not be res= erved [ 0.372785] system 00:10: [mem 0xfec00000-0xffffffff] could not be res= erved [ 0.372792] system 00:10: Plug and Play ACPI device, IDs PNP0c01 (acti= ve) [ 0.373111] pnp: PnP ACPI: found 17 devices [ 0.373116] ACPI: ACPI bus type pnp unregistered [ 0.380486] PM-Timer failed consistency check (0x0xffffff) - aborting= =2E [ 0.380513] PCI: max bus depth: 1 pci_try_num: 2 [ 0.380551] pci 0000:00:09.0: PCI bridge to [bus 03-03] [ 0.380558] pci 0000:00:09.0: bridge window [io 0xe000-0xefff] [ 0.380568] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfff= ff] [ 0.380582] pci 0000:00:0a.0: PCI bridge to [bus 02-02] [ 0.380588] pci 0000:00:0a.0: bridge window [io 0xd000-0xdfff] [ 0.380598] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafff= ff] [ 0.380612] pci 0000:00:14.4: PCI bridge to [bus 01-01] [ 0.380630] pci 0000:00:14.4: bridge window [mem 0xfdf00000-0xfe7fff= ff] [ 0.380640] pci 0000:00:14.4: bridge window [mem 0xfc000000-0xfcffff= ff pref] [ 0.380663] xen: registering gsi 17 triggering 0 polarity 1 [ 0.380681] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 0.380696] pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ = 17 [ 0.380706] pci 0000:00:09.0: setting latency timer to 64 [ 0.380717] xen: registering gsi 18 triggering 0 polarity 1 [ 0.380728] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 0.380740] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 0.380749] pci 0000:00:0a.0: setting latency timer to 64 [ 0.380765] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.380770] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.380775] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380781] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380786] pci_bus 0000:00: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380792] pci_bus 0000:03: resource 0 [io 0xe000-0xefff] [ 0.380798] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.380804] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff] [ 0.380809] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.380816] pci_bus 0000:01: resource 1 [mem 0xfdf00000-0xfe7fffff] [ 0.380822] pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff pre= f] [ 0.380828] pci_bus 0000:01: resource 4 [io 0x0000-0x0cf7] [ 0.380833] pci_bus 0000:01: resource 5 [io 0x0d00-0xffff] [ 0.380839] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff] [ 0.380877] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff] [ 0.380883] pci_bus 0000:01: resource 8 [mem 0xf0000000-0xfebfffff] [ 0.380940] NET: Registered protocol family 2 [ 0.383015] IP route cache hash table entries: 524288 (order: 10, 4194= 304 bytes) [ 0.388281] TCP established hash table entries: 524288 (order: 11, 838= 8608 bytes) [ 0.391514] TCP bind hash table entries: 65536 (order: 8, 1048576 byte= s) [ 0.391860] TCP: Hash tables configured (established 524288 bind 65536= ) [ 0.391866] TCP reno registered [ 0.392022] UDP hash table entries: 8192 (order: 6, 262144 bytes) [ 0.392296] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)= [ 0.392549] NET: Registered protocol family 1 [ 0.392605] xen: registering gsi 16 triggering 0 polarity 1 [ 0.392628] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 0.392649] pci 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.120157] pci 0000:00:12.0: PCI INT A disabled [ 1.120188] xen: registering gsi 16 triggering 0 polarity 1 [ 1.120202] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.120207] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.120212] Already setup the GSI :16 [ 1.120218] pci 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ = 16 [ 1.204175] pci 0000:00:12.1: PCI INT A disabled [ 1.204209] xen: registering gsi 17 triggering 0 polarity 1 [ 1.204223] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.204228] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.204233] Already setup the GSI :17 [ 1.204239] pci 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ = 17 [ 1.204376] pci 0000:00:12.2: PCI INT B disabled [ 1.204391] xen: registering gsi 18 triggering 0 polarity 1 [ 1.204397] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.204401] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.204405] Already setup the GSI :18 [ 1.204410] pci 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.288203] pci 0000:00:13.0: PCI INT A disabled [ 1.288235] xen: registering gsi 18 triggering 0 polarity 1 [ 1.288248] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.288253] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.288259] Already setup the GSI :18 [ 1.288264] pci 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ = 18 [ 1.372178] pci 0000:00:13.1: PCI INT A disabled [ 1.372212] xen: registering gsi 19 triggering 0 polarity 1 [ 1.372238] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.372256] pci 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ = 19 [ 1.372392] pci 0000:00:13.2: PCI INT B disabled [ 1.372417] xen: registering gsi 18 triggering 0 polarity 1 [ 1.372423] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 1.372428] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 1.372433] Already setup the GSI :18 [ 1.372437] pci 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ = 18 [ 1.456174] pci 0000:00:14.5: PCI INT C disabled [ 1.456260] pci 0000:01:04.0: Boot video device [ 1.456268] PCI: CLS 64 bytes, default 64 [ 1.457351] audit: initializing netlink socket (disabled) [ 1.457370] type=3D2000 audit(1336117549.732:1): initialized [ 1.485594] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.487850] VFS: Disk quotas dquot_6.5.2 [ 1.487931] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.488646] fuse init (API version 7.17) [ 1.488820] msgmni has been set to 1479 [ 1.489539] Block layer SCSI generic (bsg) driver version 0.4 loaded (= major 253) [ 1.489597] io scheduler noop registered [ 1.489602] io scheduler deadline registered [ 1.489645] io scheduler cfq registered (default) [ 1.490128] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.490164] pciehp: PCI Express Hot Plug Controller Driver version: 0.= 4 [ 1.490353] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0= C0C:00/input/input0 [ 1.490364] ACPI: Power Button [PWRB] [ 1.490424] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/in= put/input1 [ 1.490432] ACPI: Power Button [PWRF] [ 1.692991] APEI: Can not request iomem region <00000000dfec60ea-00000= 000dfec60ec> for GARs. [ 1.693118] [Firmware Warn]: GHES: Poll interval is 0 for generic hard= ware error source: 1, disabled. [ 1.693300] GHES: APEI firmware first mode is enabled by WHEA _OSC. [ 1.693866] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.697843] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.722349] 00:0d: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A [ 1.848430] hpet_acpi_add: no address or irqs in _CRS [ 1.848451] Linux agpgart interface v0.103 [ 1.852373] brd: module loaded [ 1.853467] loop: module loaded [ 1.853824] ahci 0000:00:11.0: version 3.0 [ 1.853849] xen: registering gsi 22 triggering 0 polarity 1 [ 1.853871] xen: --> pirq=3D22 -> irq=3D22 (gsi=3D22) [ 1.853890] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ= 22 [ 1.854111] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps = 0x3f impl SATA mode [ 1.854121] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p= mp pio slum part ccc=20 [ 1.855082] scsi0 : ahci [ 1.855199] scsi1 : ahci [ 1.855293] scsi2 : ahci [ 1.855392] scsi3 : ahci [ 1.855498] scsi4 : ahci [ 1.855590] scsi5 : ahci [ 1.856528] ata1: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 500 irq 22 [ 1.856537] ata2: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 580 irq 22 [ 1.856544] ata3: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 600 irq 22 [ 1.856552] ata4: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 680 irq 22 [ 1.856559] ata5: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 700 irq 22 [ 1.856566] ata6: SATA max UDMA/133 abar m1024@0xfe9fa400 port 0xfe9fa= 780 irq 22 [ 1.857062] Fixed MDIO Bus: probed [ 1.857086] tun: Universal TUN/TAP device driver, 1.6 [ 1.857092] tun: (C) 1999-2004 Max Krasnyansky [ 1.857178] PPP generic driver version 2.4.2 [ 1.857328] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver= [ 1.857416] xen: registering gsi 17 triggering 0 polarity 1 [ 1.857425] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 1.857430] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 1.857435] Already setup the GSI :17 [ 1.857441] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) ->= IRQ 17 [ 1.857474] ehci_hcd 0000:00:12.2: EHCI Host Controller [ 1.857569] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bu= s number 1 [ 1.857582] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.857679] ehci_hcd 0000:00:12.2: debug port 1 [ 1.857734] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe9fa800 [ 1.868101] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 1.868295] hub 1-0:1.0: USB hub found [ 1.868303] hub 1-0:1.0: 6 ports detected [ 1.868553] xen: registering gsi 19 triggering 0 polarity 1 [ 1.868561] xen_map_pirq_gsi: returning irq 19 for gsi 19 [ 1.868566] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19) [ 1.868571] Already setup the GSI :19 [ 1.868576] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) ->= IRQ 19 [ 1.868610] ehci_hcd 0000:00:13.2: EHCI Host Controller [ 1.868733] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bu= s number 2 [ 1.868749] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3= EHCI dummy qh workaround [ 1.868809] ehci_hcd 0000:00:13.2: debug port 1 [ 1.868857] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe9fac00 [ 1.880099] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 1.880312] hub 2-0:1.0: USB hub found [ 1.880320] hub 2-0:1.0: 6 ports detected [ 1.880437] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.880591] xen: registering gsi 16 triggering 0 polarity 1 [ 1.880598] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.880603] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.880608] Already setup the GSI :16 [ 1.880613] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.880648] ohci_hcd 0000:00:12.0: OHCI Host Controller [ 1.880742] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bu= s number 3 [ 1.880808] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe9f6000 [ 1.940279] hub 3-0:1.0: USB hub found [ 1.940294] hub 3-0:1.0: 3 ports detected [ 1.940504] xen: registering gsi 16 triggering 0 polarity 1 [ 1.940512] xen_map_pirq_gsi: returning irq 16 for gsi 16 [ 1.940517] xen: --> pirq=3D16 -> irq=3D16 (gsi=3D16) [ 1.940521] Already setup the GSI :16 [ 1.940527] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) ->= IRQ 16 [ 1.940562] ohci_hcd 0000:00:12.1: OHCI Host Controller [ 1.940640] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bu= s number 4 [ 1.940680] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe9f7000 [ 2.000312] hub 4-0:1.0: USB hub found [ 2.000326] hub 4-0:1.0: 3 ports detected [ 2.000550] xen: registering gsi 18 triggering 0 polarity 1 [ 2.000558] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.000562] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.000567] Already setup the GSI :18 [ 2.000572] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.000607] ohci_hcd 0000:00:13.0: OHCI Host Controller [ 2.000697] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bu= s number 5 [ 2.000763] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe9f8000 [ 2.060288] hub 5-0:1.0: USB hub found [ 2.060302] hub 5-0:1.0: 3 ports detected [ 2.060512] xen: registering gsi 18 triggering 0 polarity 1 [ 2.060520] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.060525] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.060530] Already setup the GSI :18 [ 2.060535] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) ->= IRQ 18 [ 2.060569] ohci_hcd 0000:00:13.1: OHCI Host Controller [ 2.060639] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bu= s number 6 [ 2.060679] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe9f9000 [ 2.120307] hub 6-0:1.0: USB hub found [ 2.120322] hub 6-0:1.0: 3 ports detected [ 2.120531] xen: registering gsi 18 triggering 0 polarity 1 [ 2.120539] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.120544] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.120548] Already setup the GSI :18 [ 2.120554] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) ->= IRQ 18 [ 2.120589] ohci_hcd 0000:00:14.5: OHCI Host Controller [ 2.120658] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bu= s number 7 [ 2.120697] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe9fb000 [ 2.176217] ata5: SATA link down (SStatus 0 SControl 300) [ 2.180292] hub 7-0:1.0: USB hub found [ 2.180305] hub 7-0:1.0: 2 ports detected [ 2.180389] uhci_hcd: USB Universal Host Controller Interface driver [ 2.180472] usbcore: registered new interface driver libusual [ 2.180529] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at= 0x60,0x64 irq 1,12 [ 2.183449] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.183462] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.183618] mousedev: PS/2 mouse device common for all mice [ 2.183827] rtc_cmos 00:04: RTC can wake from S4 [ 2.184001] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 [ 2.184056] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 2.184170] device-mapper: uevent: version 1.0.3 [ 2.184272] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialise= d: dm-devel@redhat.com [ 2.184285] EFI Variables Facility v0.08 2004-May-17 [ 2.184602] TCP cubic registered [ 2.184733] NET: Registered protocol family 10 [ 2.185460] NET: Registered protocol family 17 [ 2.185485] Registering the dns_resolver key type [ 2.185692] PM: Hibernation image not present or could not be loaded. [ 2.185709] registered taskstats version 1 [ 2.192089] usb 2-2: new high-speed USB device number 2 using ehci_hcd= [ 2.203117] Magic number: 12:269:773 [ 2.203129] hub 2-0:1.0: hash matches [ 2.203312] rtc_cmos 00:04: setting system clock to 2012-05-04 07:45:5= 0 UTC (1336117550) [ 2.203445] powernow-k8: Found 1 AMD Opteron(tm) Processor 6128 (8 cpu= cores) (version 2.20.00) [ 2.203553] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 2.203558] EDD information not available. [ 2.216671] input: AT Translated Set 2 keyboard as /devices/platform/i= 8042/serio0/input/input2 [ 2.330229] Initializing USB Mass Storage driver... [ 2.330450] scsi6 : usb-storage 2-2:1.0 [ 2.330530] usbcore: registered new interface driver usb-storage [ 2.330536] USB Mass Storage support registered. [ 2.352138] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352171] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352197] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352222] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.352246] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.352815] ata6.00: ATAPI: TSSTcorp CDDVDW SH-S223L, SB03, max UDMA/1= 00 [ 2.353565] ata6.00: configured for UDMA/100 [ 2.361793] ata1.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.361801] ata1.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.362506] ata4.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.362513] ata4.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.362961] ata1.00: configured for UDMA/133 [ 2.363111] scsi 0:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.363320] sd 0:0:0:0: [sda] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.363455] sd 0:0:0:0: [sda] Write Protect is off [ 2.363461] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.363501] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 2.363592] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.363707] ata4.00: configured for UDMA/133 [ 2.364219] ata2.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.364226] ata2.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.364758] ata3.00: ATA-8: WDC WD2502ABYS-02B7A0, 02.03B03, max UDMA/= 133 [ 2.364765] ata3.00: 490350672 sectors, multi 0: LBA48 NCQ (depth 31/3= 2), AA [ 2.365423] ata2.00: configured for UDMA/133 [ 2.365595] scsi 1:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.365803] sd 1:0:0:0: [sdb] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.365808] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 2.365866] ata3.00: configured for UDMA/133 [ 2.365956] sd 1:0:0:0: [sdb] Write Protect is off [ 2.365962] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.366002] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.366038] scsi 2:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.366232] sd 2:0:0:0: [sdc] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.366251] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.366340] sd 2:0:0:0: [sdc] Write Protect is off [ 2.366347] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 2.366389] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.366409] scsi 3:0:0:0: Direct-Access ATA WDC WD2502ABYS-0 = 02.0 PQ: 0 ANSI: 5 [ 2.366595] sd 3:0:0:0: Attached scsi generic sg3 type 0 [ 2.366642] sd 3:0:0:0: [sdd] 490350672 512-byte logical blocks: (251 = GB/233 GiB) [ 2.366810] sd 3:0:0:0: [sdd] Write Protect is off [ 2.366817] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 2.366855] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enable= d, doesn't support DPO or FUA [ 2.367260] scsi 5:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S223L = SB03 PQ: 0 ANSI: 5 [ 2.370973] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form= 2 cdda tray [ 2.370981] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.371158] sr 5:0:0:0: Attached scsi CD-ROM sr0 [ 2.371246] sr 5:0:0:0: Attached scsi generic sg4 type 5 [ 2.375170] sdd: unknown partition table [ 2.375459] sd 3:0:0:0: [sdd] Attached SCSI disk [ 2.376358] sdb: sdb1 sdb2 [ 2.376797] sd 1:0:0:0: [sdb] Attached SCSI disk [ 2.377565] sdc: unknown partition table [ 2.377850] sd 2:0:0:0: [sdc] Attached SCSI disk [ 2.480467] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda1= 1 sda12 sda13 sda14 sda15 sda16 > [ 2.481471] sd 0:0:0:0: [sda] Attached SCSI disk [ 2.482098] Freeing unused kernel memory: 920k freed [ 2.482415] Write protecting the kernel read-only data: 12288k [ 2.489624] Freeing unused kernel memory: 1520k freed [ 2.490773] Freeing unused kernel memory: 1140k freed [ 2.557089] udevd[165]: starting version 175 [ 2.636458] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k [ 2.636467] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 2.636601] e1000e 0000:03:00.0: Disabling ASPM L0s=20 [ 2.636626] xen: registering gsi 17 triggering 0 polarity 1 [ 2.636639] xen_map_pirq_gsi: returning irq 17 for gsi 17 [ 2.636644] xen: --> pirq=3D17 -> irq=3D17 (gsi=3D17) [ 2.636650] Already setup the GSI :17 [ 2.636656] e1000e 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> I= RQ 17 [ 2.636687] e1000e 0000:03:00.0: setting latency timer to 64 [ 2.708140] usb 5-3: new full-speed USB device number 2 using ohci_hcd= [ 2.749851] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:05 [ 2.749861] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Conne= ction [ 2.749946] e1000e 0000:03:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.750112] e1000e 0000:02:00.0: Disabling ASPM L0s=20 [ 2.750137] xen: registering gsi 18 triggering 0 polarity 1 [ 2.750148] xen_map_pirq_gsi: returning irq 18 for gsi 18 [ 2.750153] xen: --> pirq=3D18 -> irq=3D18 (gsi=3D18) [ 2.750159] Already setup the GSI :18 [ 2.750164] e1000e 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> I= RQ 18 [ 2.750195] e1000e 0000:02:00.0: setting latency timer to 64 [ 2.861339] e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) = 00:25:90:29:de:04 [ 2.861348] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Conne= ction [ 2.861432] e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-= 0FF [ 2.890458] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.0/input/input3 [ 2.890716] generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1= =2E00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-= 0000:00:13.0-3/input0 [ 2.894400] input: Winbond Electronics Corp Hermon USB hidmouse Device= as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.1/input/input4 [ 2.894568] generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1= =2E00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on u= sb-0000:00:13.0-3/input1 [ 2.894593] usbcore: registered new interface driver usbhid [ 2.894599] usbhid: USB HID core driver [ 3.329089] scsi 6:0:0:0: Direct-Access Generic- SD/MMC = 1.00 PQ: 0 ANSI: 0 [ 3.329668] scsi 6:0:0:1: Direct-Access Generic- Compact Flash = 1.01 PQ: 0 ANSI: 0 [ 3.330387] scsi 6:0:0:2: Direct-Access Generic- SM/xD-Picture = 1.02 PQ: 0 ANSI: 0 [ 3.331105] scsi 6:0:0:3: Direct-Access Generic- MS/MS-Pro = 1.03 PQ: 0 ANSI: 0 [ 3.332076] sd 6:0:0:0: Attached scsi generic sg5 type 0 [ 3.332307] sd 6:0:0:1: Attached scsi generic sg6 type 0 [ 3.332917] sd 6:0:0:2: Attached scsi generic sg7 type 0 [ 3.333248] sd 6:0:0:3: Attached scsi generic sg8 type 0 [ 3.337387] sd 6:0:0:1: [sdf] Attached SCSI removable disk [ 3.341169] sd 6:0:0:3: [sdh] Attached SCSI removable disk [ 3.341766] sd 6:0:0:0: [sde] Attached SCSI removable disk [ 3.345257] sd 6:0:0:2: [sdg] Attached SCSI removable disk [ 9.072230] EXT4-fs (sda15): mounted filesystem with ordered data mode= =2E Opts: (null) [ 15.826798] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.826809] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 15.857000] udevd[690]: starting version 175 [ 15.968225] Adding 32226300k swap on /dev/sda2. Priority:-1 extents:1= across:32226300k=20 [ 15.993626] MCE: In-kernel MCE decoding enabled. [ 15.994765] lp: driver loaded but no devices found [ 15.994879] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, = revision 0 [ 15.996578] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [ 15.996892] SP5100 TCO timer: mmio address 0xfec000f0 already in use [ 15.998543] type=3D1400 audit(1336117564.289:2): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/sbin/dhclient" pid=3D796 comm=3D"appar= mor_parser" [ 15.999196] type=3D1400 audit(1336117564.289:3): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/NetworkManager/nm-dhcp-client.= action" pid=3D796 comm=3D"apparmor_parser" [ 15.999554] type=3D1400 audit(1336117564.289:4): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/connman/scripts/dhclient-scrip= t" pid=3D796 comm=3D"apparmor_parser" [ 16.006597] EDAC MC: Ver: 2.1.0 [ 16.012142] ipmi message handler version 39.2 [ 16.012461] device-mapper: multipath: version 1.3.0 loaded [ 16.014209] ipmi device interface [ 16.017746] AMD64 EDAC driver v3.4.0 [ 16.021604] EDAC amd64: DRAM ECC enabled. [ 16.021668] EDAC amd64: F10h detected (node 0). [ 16.021752] EDAC MC: DCT0 chip selects: [ 16.021756] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.021760] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.021763] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.021766] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.021769] EDAC MC: DCT1 chip selects: [ 16.021771] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.021774] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.021777] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.021780] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.021783] EDAC amd64: using x8 syndromes. [ 16.021786] EDAC amd64: MCT channel count: 2 [ 16.021829] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 16.021833] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 16.021836] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 16.021839] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 16.021916] EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:18.2 [ 16.022350] IPMI System Interface driver. [ 16.022584] ipmi_si: probing via SMBIOS [ 16.022589] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 16.022593] ipmi_si: Adding SMBIOS-specified kcs state machine [ 16.022600] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o = address 0xca2, slave address 0x0, irq 0 [ 16.022975] EDAC amd64: DRAM ECC enabled. [ 16.022981] EDAC amd64: F10h detected (node 1). [ 16.023069] EDAC MC: DCT0 chip selects: [ 16.023076] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.023080] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.023083] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.023086] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.023088] EDAC MC: DCT1 chip selects: [ 16.023091] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 16.023098] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 16.023101] EDAC amd64: MC: 4: 0MB 5: 0MB [ 16.023104] EDAC amd64: MC: 6: 0MB 7: 0MB [ 16.023107] EDAC amd64: using x8 syndromes. [ 16.023110] EDAC amd64: MCT channel count: 2 [ 16.023170] EDAC amd64: CS0: Unbuffered DDR3 RAM [ 16.023173] EDAC amd64: CS1: Unbuffered DDR3 RAM [ 16.023180] EDAC amd64: CS2: Unbuffered DDR3 RAM [ 16.023183] EDAC amd64: CS3: Unbuffered DDR3 RAM [ 16.023295] EDAC MC1: Giving out device to 'amd64_edac' 'F10h': DEV 00= 00:00:19.2 [ 16.023410] EDAC PCI0: Giving out device to module 'amd64_edac' contro= ller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED) [ 16.042005] Bridge firewalling registered [ 16.053097] device eth0 entered promiscuous mode [ 16.132100] ipmi_si: Invalid return from get global enables command, c= annot enable the event buffer. [ 16.151879] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 16.160814] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x00b980, prod_i= d: 0xa711, dev_id: 0x20) [ 16.160999] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 16.182200] ADDRCONF(NETDEV_UP): br0: link is not ready [ 16.319392] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 16.330234] EXT4-fs (sda15): re-mounted. Opts: errors=3Dremount-ro [ 17.144823] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i80= 42/serio1/input/input5 [ 17.593397] EXT4-fs (dm-30): mounted filesystem with ordered data mode= =2E Opts: (null) [ 19.417104] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Co= ntrol: Rx/Tx [ 19.419524] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.419662] br0: port 1(eth0) entering forwarding state [ 19.419679] br0: port 1(eth0) entering forwarding state [ 19.421850] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 23.013339] init: udev-fallback-graphics main process (1809) terminate= d with status 1 [ 23.151179] init: failsafe main process (1693) killed by TERM signal [ 23.262932] type=3D1400 audit(1336117571.553:5): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/lib/libvirt/virt-aa-helper" pid=3D= 1907 comm=3D"apparmor_parser" [ 23.263053] type=3D1400 audit(1336117571.553:6): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/sbin/dhclient" pid=3D1905 comm=3D"a= pparmor_parser" [ 23.263150] type=3D1400 audit(1336117571.553:7): apparmor=3D"STATUS" o= peration=3D"profile_load" name=3D"/usr/sbin/libvirtd" pid=3D1908 comm=3D"= apparmor_parser" [ 23.263716] type=3D1400 audit(1336117571.553:8): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/NetworkManager/nm-dhcp-clie= nt.action" pid=3D1905 comm=3D"apparmor_parser" [ 23.264106] type=3D1400 audit(1336117571.557:9): apparmor=3D"STATUS" o= peration=3D"profile_replace" name=3D"/usr/lib/connman/scripts/dhclient-sc= ript" pid=3D1905 comm=3D"apparmor_parser" [ 23.264198] type=3D1400 audit(1336117571.557:10): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi" pid=3D1909 c= omm=3D"apparmor_parser" [ 23.264557] type=3D1400 audit(1336117571.557:11): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/mysqld-akonadi///usr/sbin/my= sqld" pid=3D1909 comm=3D"apparmor_parser" [ 23.264863] type=3D1400 audit(1336117571.557:12): apparmor=3D"STATUS" = operation=3D"profile_load" name=3D"/usr/sbin/tcpdump" pid=3D1911 comm=3D"= apparmor_parser" [ 23.544492] init: Failed to spawn alsa-restore main process: unable to= execute: No such file or directory [ 23.762025] ip_tables: (C) 2000-2006 Netfilter Core Team [ 23.862906] nf_conntrack version 0.5.0 (5946 buckets, 23784 max) [ 23.915808] ADDRCONF(NETDEV_UP): virbr0: link is not ready [ 24.143570] Event-channel device installed. [ 24.207277] XENBUS: Unable to read cpu state [ 24.207486] XENBUS: Unable to read cpu state [ 24.207676] XENBUS: Unable to read cpu state [ 24.207856] XENBUS: Unable to read cpu state [ 24.208129] XENBUS: Unable to read cpu state [ 24.208292] XENBUS: Unable to read cpu state [ 24.208467] XENBUS: Unable to read cpu state [ 24.208605] XENBUS: Unable to read cpu state [ 25.164557] Ebtables v2.0 registered [ 25.195793] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 29.556089] br0: no IPv6 routers present [ 112.342255] xen-acpi-processor: Max ACPI ID: 16 [ 112.344764] ACPI CPU1 - P-states uploaded. [ 112.344771] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344775] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344779] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344782] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344785] P4: 800 MHz, 4777 mW, 4 uS [ 112.344804] ACPI CPU2 - P-states uploaded. [ 112.344809] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344817] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344823] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344829] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344834] P4: 800 MHz, 4777 mW, 4 uS [ 112.344856] ACPI CPU3 - P-states uploaded. [ 112.344861] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344865] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344871] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344876] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344881] P4: 800 MHz, 4777 mW, 4 uS [ 112.344900] ACPI CPU4 - P-states uploaded. [ 112.344905] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344910] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344915] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344920] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344925] P4: 800 MHz, 4777 mW, 4 uS [ 112.344937] ACPI CPU5 - P-states uploaded. [ 112.344942] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344947] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344952] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344957] P3: 1000 MHz, 5600 mW, 4 uS [ 112.344962] P4: 800 MHz, 4777 mW, 4 uS [ 112.344972] ACPI CPU6 - P-states uploaded. [ 112.344979] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.344984] P1: 1500 MHz, 8265 mW, 4 uS [ 112.344991] P2: 1200 MHz, 6825 mW, 4 uS [ 112.344995] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345000] P4: 800 MHz, 4777 mW, 4 uS [ 112.345013] ACPI CPU7 - P-states uploaded. [ 112.345017] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.345022] P1: 1500 MHz, 8265 mW, 4 uS [ 112.345028] P2: 1200 MHz, 6825 mW, 4 uS [ 112.345033] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345037] P4: 800 MHz, 4777 mW, 4 uS [ 112.345049] ACPI CPU8 - P-states uploaded. [ 112.345054] *P0: 2000 MHz, 10580 mW, 4 uS [ 112.345059] P1: 1500 MHz, 8265 mW, 4 uS [ 112.345064] P2: 1200 MHz, 6825 mW, 4 uS [ 112.345069] P3: 1000 MHz, 5600 mW, 4 uS [ 112.345074] P4: 800 MHz, 4777 mW, 4 uS [ 112.345100] xen-acpi-processor: ACPI CPU1 w/ PBLK:0x810 [ 112.345116] xen-acpi-processor: ACPI CPU2 w/ PBLK:0x0 [ 112.345128] xen-acpi-processor: ACPI CPU3 w/ PBLK:0x0 [ 112.345140] xen-acpi-processor: ACPI CPU4 w/ PBLK:0x0 [ 112.345150] xen-acpi-processor: ACPI CPU5 w/ PBLK:0x0 [ 112.345163] xen-acpi-processor: ACPI CPU6 w/ PBLK:0x0 [ 112.345175] xen-acpi-processor: ACPI CPU7 w/ PBLK:0x0 [ 112.345188] xen-acpi-processor: ACPI CPU8 w/ PBLK:0x0 [ 112.345199] xen-acpi-processor: ACPI CPU9 w/ PBLK:0x0 [ 112.345208] xen-acpi-processor: ACPI CPU10 w/ PBLK:0x0 [ 112.345216] xen-acpi-processor: ACPI CPU11 w/ PBLK:0x0 [ 112.345225] xen-acpi-processor: ACPI CPU12 w/ PBLK:0x0 --------------070800050300030104070507-- --------------enigEB40C659F3DC487B0CD9A40F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPo4yoAAoJEOhnXe7L7s6j0tUQAMsHymTHwqeHbTo/kiHCjxZl 1w+ktvBCCllVo2/3/bIVTVS+Pgk4DFkoGqBlryls+hPV5c8dxkKExS7coEdpEghG ubIWV3XMjgKFBGSZME4qErtxFLLQKvzVqQc4EJW7h/6lRQX+bYVQ6tyEVp06b/// kie/HuC06wDICKt3L6NS6k3Gm3qznyvwcPnHqNJUTDVPvq9OAC3zRGKxTOI6l5W5 +stLQ8RqGbtRnsi/SXtWXo32toz+QBvEi6poMSEHIYMpAN1NkXRpt8uJkZZMRHj2 J5TINRgOMEBo5X505M1/PxOxw+yGR2bpPP3d+dTA7UYfraBWQ9ee9XhPV169urtd MkusPYneVkaxsWcBCIRgdcARztvXK3zH6FB8uyEwYzBB9rgCReOOAYLzgOAMU7TW UDV4RNGfboH2f2EeHCYEDpjxPSu/f8nj12Y99c1YLWl0n/BPsyEgu04VE91n5Fyn se+TSdds1ha3lZGictiDhhGkFD1hBWaTgu4m9xYxKq4PcUKvWze/2hy8xqbhx+nk G3EiIHBLXHPEMLZ28NUfb9/6y0j9JsocjAXALNVXJsVtn4WZpPjA2YQ5Uj1OCkEI gqvWKKfosEk1VOhNNLUablDyuUEiNxnXtmN1RvFfEm17ykmGpiIIdivJWUIR+dOV 3NGyl7Jf4tyDokh9n1eK =3IO6 -----END PGP SIGNATURE----- --------------enigEB40C659F3DC487B0CD9A40F-- --===============5525228139078192454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5525228139078192454==-- From xen-devel-bounces@lists.xen.org Fri May 04 08:07:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDXt-00027y-4e; Fri, 04 May 2012 08:07:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDXs-00027s-3u for xen-devel@lists.xen.org; Fri, 04 May 2012 08:07:20 +0000 Received: from [85.158.139.83:62552] by server-10.bemta-5.messagelabs.com id 02/4D-08260-73E83AF4; Fri, 04 May 2012 08:07:19 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336118837!22850928!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2821 invoked from network); 4 May 2012 08:07:17 -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; 4 May 2012 08:07:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 09:07:16 +0100 Message-Id: <4FA3AA540200007800081840@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 09:07:16 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > guest with device assigned can be benefitted. > > Changes from v1: > - put the variable definition at the start of function > - add error log report > > Signed-off-by: Xudong Hao I continue to disagree to doing this always, unconditionally, with hard-coded settings. If these features require explicit enabling, there likely is something that drivers unaware of them could have problems with - otherwise I would think these features would be always enabled when a device supports them, and no options would exist to control certain parameters. Plus, if the patch is nevertheless going to be acceptable, ... > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev > *dev) > struct xen_pcibk_dev_data *dev_data; > int err = 0; > > + /* set default value */ > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > + > dev_dbg(&dev->dev, "initializing...\n"); > > /* The PCI backend is not intended to be a module (or to work with > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev > *dev) > dev_dbg(&dev->dev, "reset device\n"); > xen_pcibk_reset_device(dev); > > + /* Enable LTR and OBFF before do device assignment */ > + /* LTR(Latency tolerance reporting) allows devices to send > + * messages to the root complex indicating their latency tolerance > + * for snooped & unsnooped memory transactions. > + */ > + err = pci_enable_ltr(dev); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); ... dev_err() here and below is certainly too severe, particularly for the -ENOTSUPP cases. And the spelling would need fixing, especially with it being broken exactly the same way a second time below. > + > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); What's the point of calling this function when pci_enable_ltr() failed? Jan > + if (err) > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > + > + /* OBFF (optimized buffer flush/fill), where supported, can help > + * improve energy efficiency by giving devices information about > + * when interrupts and other activity will have a reduced power > + * impact. > + */ > + err = pci_enable_obff(dev, type); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > + > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > return 0; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:07:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDXt-00027y-4e; Fri, 04 May 2012 08:07:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDXs-00027s-3u for xen-devel@lists.xen.org; Fri, 04 May 2012 08:07:20 +0000 Received: from [85.158.139.83:62552] by server-10.bemta-5.messagelabs.com id 02/4D-08260-73E83AF4; Fri, 04 May 2012 08:07:19 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336118837!22850928!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2821 invoked from network); 4 May 2012 08:07:17 -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; 4 May 2012 08:07:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 09:07:16 +0100 Message-Id: <4FA3AA540200007800081840@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 09:07:16 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > guest with device assigned can be benefitted. > > Changes from v1: > - put the variable definition at the start of function > - add error log report > > Signed-off-by: Xudong Hao I continue to disagree to doing this always, unconditionally, with hard-coded settings. If these features require explicit enabling, there likely is something that drivers unaware of them could have problems with - otherwise I would think these features would be always enabled when a device supports them, and no options would exist to control certain parameters. Plus, if the patch is nevertheless going to be acceptable, ... > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev > *dev) > struct xen_pcibk_dev_data *dev_data; > int err = 0; > > + /* set default value */ > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > + > dev_dbg(&dev->dev, "initializing...\n"); > > /* The PCI backend is not intended to be a module (or to work with > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev > *dev) > dev_dbg(&dev->dev, "reset device\n"); > xen_pcibk_reset_device(dev); > > + /* Enable LTR and OBFF before do device assignment */ > + /* LTR(Latency tolerance reporting) allows devices to send > + * messages to the root complex indicating their latency tolerance > + * for snooped & unsnooped memory transactions. > + */ > + err = pci_enable_ltr(dev); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); ... dev_err() here and below is certainly too severe, particularly for the -ENOTSUPP cases. And the spelling would need fixing, especially with it being broken exactly the same way a second time below. > + > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); What's the point of calling this function when pci_enable_ltr() failed? Jan > + if (err) > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > + > + /* OBFF (optimized buffer flush/fill), where supported, can help > + * improve energy efficiency by giving devices information about > + * when interrupts and other activity will have a reduced power > + * impact. > + */ > + err = pci_enable_obff(dev, type); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > + > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > return 0; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:18:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDiN-0002SM-6c; Fri, 04 May 2012 08:18:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDiL-0002S5-Jv for xen-devel@lists.xen.org; Fri, 04 May 2012 08:18:09 +0000 Received: from [85.158.143.99:36407] by server-2.bemta-4.messagelabs.com id A6/E9-17550-0C093AF4; Fri, 04 May 2012 08:18:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336119486!26439050!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19446 invoked from network); 4 May 2012 08:18:06 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 08:18:06 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 09:18:05 +0100 Message-Id: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 09:18:03 +0100 From: "Jan Beulich" To: "Keir Fraser" Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Keir, does this really need to be a per-CPU variable? Can't a timer run only once at a time on the entire system (the more that it gets re-armed only at the end of the poll function, whereas the variable is consumed at the start), and hence the variable can be a simple one? Or else, what subtlety am I overlooking? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:18:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDiN-0002SM-6c; Fri, 04 May 2012 08:18:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDiL-0002S5-Jv for xen-devel@lists.xen.org; Fri, 04 May 2012 08:18:09 +0000 Received: from [85.158.143.99:36407] by server-2.bemta-4.messagelabs.com id A6/E9-17550-0C093AF4; Fri, 04 May 2012 08:18:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336119486!26439050!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19446 invoked from network); 4 May 2012 08:18:06 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 08:18:06 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 09:18:05 +0100 Message-Id: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 09:18:03 +0100 From: "Jan Beulich" To: "Keir Fraser" Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Keir, does this really need to be a per-CPU variable? Can't a timer run only once at a time on the entire system (the more that it gets re-armed only at the end of the poll function, whereas the variable is consumed at the start), and hence the variable can be a simple one? Or else, what subtlety am I overlooking? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:23:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDnL-0002jg-Ur; Fri, 04 May 2012 08:23:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDnK-0002jZ-HW for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:23:18 +0000 Received: from [85.158.138.51:48503] by server-4.bemta-3.messagelabs.com id 83/B0-15341-5F193AF4; Fri, 04 May 2012 08:23:17 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-174.messagelabs.com!1336119795!17278053!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25611 invoked from network); 4 May 2012 08:23:17 -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; 4 May 2012 08:23:17 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQDnH-0007zx-0A for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:23:15 -0700 Date: Fri, 4 May 2012 01:23:15 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336119794999-5685158.post@n5.nabble.com> In-Reply-To: <20120503160244.GQ2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ClBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlCj4gCj4gT24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMDc6 Mjc6MTFBTSAtMDcwMCwgRmFudHUgd3JvdGU6Cj4+IAo+PiBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZQo+PiA+IAo+PiA+IE9uIFRodSwgTWF5IDAzLCAyMDEyIGF0IDA1OjI4OjQ0QU0gLTA3MDAsIEZh bnR1IHdyb3RlOgo+PiA+PiAKPj4gPj4gQWJvdXQgcXhsIHRoZXJlIGFyZSBwcm9ibGVtcyBhYm91 dCB2aWRlb3JhbSBub3QgYWxsb2NhdGVkIG9yIG5vdCB1c2VkCj4+ID4+IG92ZXIgNAo+PiA+PiBt YiAoc2FtZSBhcyBkZWZhdWx0IGNpcnJ1cyB2Z2EpLgo+PiA+PiBBdCB0aGUgbW9tZW50IEkgaGF2 ZW4ndCBmb3VuZCBzb2x1dGlvbiBmb3IgdGhpcyBwcm9ibGVtLCBwcm9iYWJseSBzb21lCj4+ID4+ IGJ1Z2ZpeCBhbmQvb3IgY2hhbmdlIGFyZSBuZWVkZWQgb24geGVuLgo+PiA+PiAKPj4gPiAKPj4g PiBJcyB0aGlzIGEgcmVncmVzc2lvbiBpbiB4ZW4tdW5zdGFibGUgY29tcGFyZWQgdG8geGVuIDQu MSA/IAo+PiA+IAo+PiA+IGFmYWlrIHlvdSBjYW4gZ2V0IGF0IGxlYXN0IDE2IE1CIG9mIHZpZGVv IG1lbW9yeSBmb3IgSFZNIGd1ZXN0IHdpdGggWGVuCj4+ID4gNC4xLgo+PiA+IAo+PiA+IC0tIFBh c2kKPj4gPiAKPj4gPiAKPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+PiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gPiBYZW4tZGV2ZWxALnhl bgo+PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+PiA+IAo+PiBUaGFua3MgZm9y IHJlcGx5Cj4+IFByb2JhYmx5IHhlbi11bnN0YWJsZSB3aXRoIHFlbXUgdXBzdHJlYW0gZG9lc24n dCBzdXBwb3J0IHZpZGVvcmFtCj4+IHNldHRpbmcuCj4+IHF4bCBkZWZhdWx0IHZpZGVvcmFtIGlz IDY0IG1iIGJ1dCBJIGFsc28gdHJpZWQgdG8gc2V0IDE2IG1iIHdpdGhvdXQKPj4gcmVzdWx0LAo+ PiBpdCBhbHdheXMgc2VlIG9ubHkgNCBtYiwgbm90IGVub3VnaCBmb3IgY29ycmVjdCB3b3JraW5n IHF4bC4KPj4gCj4gCj4gT2suIElmIHlvdSB1c2UgcWVtdS11cHN0cmVhbSBhbmQgY2lycnVzL3N0 ZHZnYSAod2l0aG91dCBxeGwpLCBkb2VzCj4gdmlkZW9tZW0gPjRNQiB3b3JrIHRoZW4gPwo+IAo+ IC0tIFBhc2kKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxALnhlbgo+IGh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IApObywgYWx3YXlzIDQgbWIsIGFsc28gd2l0aCBj aXJydXMgb3Igc3RkdmdhIHZpZGVvcmFtIHNldHRpbmcgbm90IHdvcmsuCgotLQpWaWV3IHRoaXMg bWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9VbmFi bGUtdG8tZ2V0LVFYTC12Z2Etd29ya2luZy10cDU2Njc5MTlwNTY4NTE1OC5odG1sClNlbnQgZnJv bSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl bi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri May 04 08:23:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDnL-0002jg-Ur; Fri, 04 May 2012 08:23:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDnK-0002jZ-HW for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:23:18 +0000 Received: from [85.158.138.51:48503] by server-4.bemta-3.messagelabs.com id 83/B0-15341-5F193AF4; Fri, 04 May 2012 08:23:17 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-174.messagelabs.com!1336119795!17278053!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25611 invoked from network); 4 May 2012 08:23:17 -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; 4 May 2012 08:23:17 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQDnH-0007zx-0A for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:23:15 -0700 Date: Fri, 4 May 2012 01:23:15 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336119794999-5685158.post@n5.nabble.com> In-Reply-To: <20120503160244.GQ2058@reaktio.net> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ClBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlCj4gCj4gT24gVGh1LCBNYXkgMDMsIDIwMTIgYXQgMDc6 Mjc6MTFBTSAtMDcwMCwgRmFudHUgd3JvdGU6Cj4+IAo+PiBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZQo+PiA+IAo+PiA+IE9uIFRodSwgTWF5IDAzLCAyMDEyIGF0IDA1OjI4OjQ0QU0gLTA3MDAsIEZh bnR1IHdyb3RlOgo+PiA+PiAKPj4gPj4gQWJvdXQgcXhsIHRoZXJlIGFyZSBwcm9ibGVtcyBhYm91 dCB2aWRlb3JhbSBub3QgYWxsb2NhdGVkIG9yIG5vdCB1c2VkCj4+ID4+IG92ZXIgNAo+PiA+PiBt YiAoc2FtZSBhcyBkZWZhdWx0IGNpcnJ1cyB2Z2EpLgo+PiA+PiBBdCB0aGUgbW9tZW50IEkgaGF2 ZW4ndCBmb3VuZCBzb2x1dGlvbiBmb3IgdGhpcyBwcm9ibGVtLCBwcm9iYWJseSBzb21lCj4+ID4+ IGJ1Z2ZpeCBhbmQvb3IgY2hhbmdlIGFyZSBuZWVkZWQgb24geGVuLgo+PiA+PiAKPj4gPiAKPj4g PiBJcyB0aGlzIGEgcmVncmVzc2lvbiBpbiB4ZW4tdW5zdGFibGUgY29tcGFyZWQgdG8geGVuIDQu MSA/IAo+PiA+IAo+PiA+IGFmYWlrIHlvdSBjYW4gZ2V0IGF0IGxlYXN0IDE2IE1CIG9mIHZpZGVv IG1lbW9yeSBmb3IgSFZNIGd1ZXN0IHdpdGggWGVuCj4+ID4gNC4xLgo+PiA+IAo+PiA+IC0tIFBh c2kKPj4gPiAKPj4gPiAKPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+PiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gPiBYZW4tZGV2ZWxALnhl bgo+PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+PiA+IAo+PiBUaGFua3MgZm9y IHJlcGx5Cj4+IFByb2JhYmx5IHhlbi11bnN0YWJsZSB3aXRoIHFlbXUgdXBzdHJlYW0gZG9lc24n dCBzdXBwb3J0IHZpZGVvcmFtCj4+IHNldHRpbmcuCj4+IHF4bCBkZWZhdWx0IHZpZGVvcmFtIGlz IDY0IG1iIGJ1dCBJIGFsc28gdHJpZWQgdG8gc2V0IDE2IG1iIHdpdGhvdXQKPj4gcmVzdWx0LAo+ PiBpdCBhbHdheXMgc2VlIG9ubHkgNCBtYiwgbm90IGVub3VnaCBmb3IgY29ycmVjdCB3b3JraW5n IHF4bC4KPj4gCj4gCj4gT2suIElmIHlvdSB1c2UgcWVtdS11cHN0cmVhbSBhbmQgY2lycnVzL3N0 ZHZnYSAod2l0aG91dCBxeGwpLCBkb2VzCj4gdmlkZW9tZW0gPjRNQiB3b3JrIHRoZW4gPwo+IAo+ IC0tIFBhc2kKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxALnhlbgo+IGh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IApObywgYWx3YXlzIDQgbWIsIGFsc28gd2l0aCBj aXJydXMgb3Igc3RkdmdhIHZpZGVvcmFtIHNldHRpbmcgbm90IHdvcmsuCgotLQpWaWV3IHRoaXMg bWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS9VbmFi bGUtdG8tZ2V0LVFYTC12Z2Etd29ya2luZy10cDU2Njc5MTlwNTY4NTE1OC5odG1sClNlbnQgZnJv bSB0aGUgWGVuIC0gRGV2IG1haWxpbmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl bi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri May 04 08:26:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDq3-0002rC-Gh; Fri, 04 May 2012 08:26:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDq1-0002qw-Or for xen-devel@lists.xen.org; Fri, 04 May 2012 08:26:05 +0000 Received: from [193.109.254.147:16070] by server-8.bemta-14.messagelabs.com id AB/23-23244-D9293AF4; Fri, 04 May 2012 08:26:05 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336119950!7590811!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29106 invoked from network); 4 May 2012 08:25:50 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 08:25:50 -0000 Received: by eaaf11 with SMTP id f11so812382eaa.32 for ; Fri, 04 May 2012 01:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=wF3rQhO/HahzX2wPgIPzZ5JtQu+0K6FWPVXbTnzs0JY=; b=yU/H6wlf6pzKyQqBSRnJ2PLIaa0SAXzlTERLJl6I0ASaSaG5uEZKypwFZYoz+rShRz XkrzAi3Hn9TRpGkNak9BoRAi1lAaHbWLJPOgOCs/1mNpqCEUCqE44qgrstdVcaHtgFdK N29Ov0PX6fvwBbfdjBxSILTdkB0oNXtIN94Ip0PhFMXNjXG62DgnJhJyMkudh0hY4xe1 4VHP3aRKmgJ75+CNUioAG81abSZXVC1CmxyC/tMhAQZ2dRa2CMO88H9UDF35zESgWWLK oBaEqCha0S96WrDjCLt1CvGr1EzXHZ1fKLYvY+m5NZO+jv0tIPAEZsUjLZ1t9AZ15plj 8m4w== Received: by 10.213.29.138 with SMTP id q10mr1039136ebc.15.1336119949833; Fri, 04 May 2012 01:25:49 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id u10sm22055072eem.1.2012.05.04.01.25.47 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 01:25:49 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 09:25:38 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0pz3wPgv5LAnWG3UW82f8d46J5Gg== In-Reply-To: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 09:18, "Jan Beulich" wrote: > Hi Keir, > > does this really need to be a per-CPU variable? Can't a timer run only > once at a time on the entire system (the more that it gets re-armed only > at the end of the poll function, whereas the variable is consumed at the > start), and hence the variable can be a simple one? Or else, what > subtlety am I overlooking? We set up a timer per initialised uart. There can be more than one (although granted it is rare). -- Keir > Thanks, Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:26:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDq3-0002rC-Gh; Fri, 04 May 2012 08:26:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDq1-0002qw-Or for xen-devel@lists.xen.org; Fri, 04 May 2012 08:26:05 +0000 Received: from [193.109.254.147:16070] by server-8.bemta-14.messagelabs.com id AB/23-23244-D9293AF4; Fri, 04 May 2012 08:26:05 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336119950!7590811!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29106 invoked from network); 4 May 2012 08:25:50 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 08:25:50 -0000 Received: by eaaf11 with SMTP id f11so812382eaa.32 for ; Fri, 04 May 2012 01:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=wF3rQhO/HahzX2wPgIPzZ5JtQu+0K6FWPVXbTnzs0JY=; b=yU/H6wlf6pzKyQqBSRnJ2PLIaa0SAXzlTERLJl6I0ASaSaG5uEZKypwFZYoz+rShRz XkrzAi3Hn9TRpGkNak9BoRAi1lAaHbWLJPOgOCs/1mNpqCEUCqE44qgrstdVcaHtgFdK N29Ov0PX6fvwBbfdjBxSILTdkB0oNXtIN94Ip0PhFMXNjXG62DgnJhJyMkudh0hY4xe1 4VHP3aRKmgJ75+CNUioAG81abSZXVC1CmxyC/tMhAQZ2dRa2CMO88H9UDF35zESgWWLK oBaEqCha0S96WrDjCLt1CvGr1EzXHZ1fKLYvY+m5NZO+jv0tIPAEZsUjLZ1t9AZ15plj 8m4w== Received: by 10.213.29.138 with SMTP id q10mr1039136ebc.15.1336119949833; Fri, 04 May 2012 01:25:49 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id u10sm22055072eem.1.2012.05.04.01.25.47 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 01:25:49 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 09:25:38 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0pz3wPgv5LAnWG3UW82f8d46J5Gg== In-Reply-To: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 09:18, "Jan Beulich" wrote: > Hi Keir, > > does this really need to be a per-CPU variable? Can't a timer run only > once at a time on the entire system (the more that it gets re-armed only > at the end of the poll function, whereas the variable is consumed at the > start), and hence the variable can be a simple one? Or else, what > subtlety am I overlooking? We set up a timer per initialised uart. There can be more than one (although granted it is rare). -- Keir > Thanks, Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:29:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDsd-00030h-2q; Fri, 04 May 2012 08:28:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDsb-00030Y-CI for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:28:45 +0000 Received: from [193.109.254.147:5672] by server-6.bemta-14.messagelabs.com id FF/BF-04960-C3393AF4; Fri, 04 May 2012 08:28:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336120124!7591342!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6820 invoked from network); 4 May 2012 08:28:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 08:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291289" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:28:31 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:28:30 +0100 Message-ID: <1336120109.26385.7.camel@dagon.hellion.org.uk> From: Ian Campbell To: Fantu Date: Fri, 4 May 2012 09:28:29 +0100 In-Reply-To: <1336119794999-5685158.post@n5.nabble.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (putting Pasi back in the CC, please retain CCs on xen-devel) On Fri, 2012-05-04 at 09:23 +0100, Fantu wrote: > Pasi K=E4rkk=E4inen wrote > > Ok. If you use qemu-upstream and cirrus/stdvga (without qxl), does > > videomem >4MB work then ? > > = > No, always 4 mb, also with cirrus or stdvga videoram setting not work. But with Qemu-xen-traditional it does work? Anthony -- any idea why the videoram setting doesn't work with upstream qemu? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:29:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDsd-00030h-2q; Fri, 04 May 2012 08:28:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDsb-00030Y-CI for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:28:45 +0000 Received: from [193.109.254.147:5672] by server-6.bemta-14.messagelabs.com id FF/BF-04960-C3393AF4; Fri, 04 May 2012 08:28:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336120124!7591342!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6820 invoked from network); 4 May 2012 08:28:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 08:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291289" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:28:31 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:28:30 +0100 Message-ID: <1336120109.26385.7.camel@dagon.hellion.org.uk> From: Ian Campbell To: Fantu Date: Fri, 4 May 2012 09:28:29 +0100 In-Reply-To: <1336119794999-5685158.post@n5.nabble.com> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (putting Pasi back in the CC, please retain CCs on xen-devel) On Fri, 2012-05-04 at 09:23 +0100, Fantu wrote: > Pasi K=E4rkk=E4inen wrote > > Ok. If you use qemu-upstream and cirrus/stdvga (without qxl), does > > videomem >4MB work then ? > > = > No, always 4 mb, also with cirrus or stdvga videoram setting not work. But with Qemu-xen-traditional it does work? Anthony -- any idea why the videoram setting doesn't work with upstream qemu? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:30:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDuP-00038u-Iw; Fri, 04 May 2012 08:30:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDuO-00038m-RJ for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:30:37 +0000 Received: from [85.158.139.83:48606] by server-2.bemta-5.messagelabs.com id C5/99-17016-CA393AF4; Fri, 04 May 2012 08:30:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336120235!22772829!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19284 invoked from network); 4 May 2012 08:30:35 -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; 4 May 2012 08:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291333" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:30:34 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:30:33 +0100 Message-ID: <1336120233.26385.10.camel@dagon.hellion.org.uk> From: Ian Campbell To: ZhouPeng Date: Fri, 4 May 2012 09:30:33 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 02:15 +0100, ZhouPeng wrote: > On Thu, May 3, 2012 at 9:56 PM, Stefano Stabellini > wrote: > > On Thu, 3 May 2012, ZhouPeng wrote: > >> >> > What do you mean by "disabling graphic"? Do you mean disabling the vga > >> >> > card? > >> >> No, not disable the vga card. > >> >> But booting in Text mode. > >> > > >> > Then you are manually starting X11 with the spice driver? > >> Always in text mode. > >> Never start X11. > >> Using stdard vga but not qxl-vga. > > > > so you didn't actually test qxl at all, did you? > Didn't test qxl but only spice. So to return to my question at the start of this thread -- is qxl something you would be interested in supporting? (I think you said yes, but we've been somewhat sidetracked on the distinction between SPICE support and QXL support). In any case this is definitely 4.3 material IMHO since we are now feature frozen for 4.2. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:30:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDuP-00038u-Iw; Fri, 04 May 2012 08:30:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDuO-00038m-RJ for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:30:37 +0000 Received: from [85.158.139.83:48606] by server-2.bemta-5.messagelabs.com id C5/99-17016-CA393AF4; Fri, 04 May 2012 08:30:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336120235!22772829!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19284 invoked from network); 4 May 2012 08:30:35 -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; 4 May 2012 08:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291333" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:30:34 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:30:33 +0100 Message-ID: <1336120233.26385.10.camel@dagon.hellion.org.uk> From: Ian Campbell To: ZhouPeng Date: Fri, 4 May 2012 09:30:33 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Unable to get QXL vga working X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 02:15 +0100, ZhouPeng wrote: > On Thu, May 3, 2012 at 9:56 PM, Stefano Stabellini > wrote: > > On Thu, 3 May 2012, ZhouPeng wrote: > >> >> > What do you mean by "disabling graphic"? Do you mean disabling the vga > >> >> > card? > >> >> No, not disable the vga card. > >> >> But booting in Text mode. > >> > > >> > Then you are manually starting X11 with the spice driver? > >> Always in text mode. > >> Never start X11. > >> Using stdard vga but not qxl-vga. > > > > so you didn't actually test qxl at all, did you? > Didn't test qxl but only spice. So to return to my question at the start of this thread -- is qxl something you would be interested in supporting? (I think you said yes, but we've been somewhat sidetracked on the distinction between SPICE support and QXL support). In any case this is definitely 4.3 material IMHO since we are now feature frozen for 4.2. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:34:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDxi-0003bD-Vl; Fri, 04 May 2012 08:34:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDxh-0003av-B4 for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:34:01 +0000 Received: from [85.158.143.99:11046] by server-3.bemta-4.messagelabs.com id AB/A8-05853-87493AF4; Fri, 04 May 2012 08:34:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336120439!16831979!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3967 invoked from network); 4 May 2012 08:34:00 -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; 4 May 2012 08:34:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291414" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:33:59 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:33:59 +0100 Message-ID: <1336120438.26385.13.camel@dagon.hellion.org.uk> From: Ian Campbell To: Olaf Hering Date: Fri, 4 May 2012 09:33:58 +0100 In-Reply-To: <20120503155716.GA14354@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 16:57 +0100, Olaf Hering wrote: > On Thu, May 03, Olaf Hering wrote: > > > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > > disabled for some reason. I will double check. > > While preparing the patch I accidently disabled vtpm in my rpm spec > file, so the code was not exectued anymore. > Sorry for that. So should c5b7d49ca3ee be reverted for now? Or are you going to come up with a fix soon? > I see some nice patch handing in tools/firmware/etherboot/Makefile, > which could be copied to tools/vtpm/Makefile. However, this would make > the make targets updatepatches and orig in tools/vtpm/Makefile obsolete. > Would that be an acceptable approach to maintain a stack of patches for > vtpm? It could be considered for 4.3. I'm not sure we want to be fiddling with obscure parts of the build system for 4.2 at this stage. Lets just fix the immediate breakage for 4.2. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:34:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08: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 ) id 1SQDxi-0003bD-Vl; Fri, 04 May 2012 08:34:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQDxh-0003av-B4 for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:34:01 +0000 Received: from [85.158.143.99:11046] by server-3.bemta-4.messagelabs.com id AB/A8-05853-87493AF4; Fri, 04 May 2012 08:34:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336120439!16831979!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3967 invoked from network); 4 May 2012 08:34:00 -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; 4 May 2012 08:34:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12291414" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:33:59 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 09:33:59 +0100 Message-ID: <1336120438.26385.13.camel@dagon.hellion.org.uk> From: Ian Campbell To: Olaf Hering Date: Fri, 4 May 2012 09:33:58 +0100 In-Reply-To: <20120503155716.GA14354@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-03 at 16:57 +0100, Olaf Hering wrote: > On Thu, May 03, Olaf Hering wrote: > > > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > > disabled for some reason. I will double check. > > While preparing the patch I accidently disabled vtpm in my rpm spec > file, so the code was not exectued anymore. > Sorry for that. So should c5b7d49ca3ee be reverted for now? Or are you going to come up with a fix soon? > I see some nice patch handing in tools/firmware/etherboot/Makefile, > which could be copied to tools/vtpm/Makefile. However, this would make > the make targets updatepatches and orig in tools/vtpm/Makefile obsolete. > Would that be an acceptable approach to maintain a stack of patches for > vtpm? It could be considered for 4.3. I'm not sure we want to be fiddling with obscure parts of the build system for 4.2 at this stage. Lets just fix the immediate breakage for 4.2. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 08:54:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:54:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEHC-00041J-R4; Fri, 04 May 2012 08:54:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEHC-00041E-6b for xen-devel@lists.xen.org; Fri, 04 May 2012 08:54:10 +0000 Received: from [85.158.143.99:39079] by server-3.bemta-4.messagelabs.com id ED/A4-05853-13993AF4; Fri, 04 May 2012 08:54:09 +0000 X-Env-Sender: hahn@univention.de X-Msg-Ref: server-10.tower-216.messagelabs.com!1336121647!20079846!1 X-Originating-IP: [82.198.197.8] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13648 invoked from network); 4 May 2012 08:54:07 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-10.tower-216.messagelabs.com with SMTP; 4 May 2012 08:54:07 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 46D7E67BB0D; Fri, 4 May 2012 10:54:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 27F1867BB0E; Fri, 4 May 2012 10:54:06 +0200 (CEST) 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 gVepBKd6q3Jf; Fri, 4 May 2012 10:54:05 +0200 (CEST) Received: from stave.knut.univention.de (port-92-196-73-46.dynamic.qsc.de [92.196.73.46]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 0E32767BB0D; Fri, 4 May 2012 10:54:04 +0200 (CEST) From: Philipp Hahn Organization: Univention.de To: Xen-devel@lists.xen.org Date: Fri, 4 May 2012 10:54:03 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286) MIME-Version: 1.0 Message-Id: <201205041054.04079.hahn@univention.de> Cc: Thomas Gleixner , Jeremy Fitzhardinge Subject: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4798092387412600323==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4798092387412600323== Content-Type: multipart/signed; boundary="nextPart13234650.LQF3ZOgi9e"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart13234650.LQF3ZOgi9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I encountered the following bug when migrating a Linux-2.6.32.54 PV domain = on=20 Xen-3.4.3 between different hosts, whose uptime differs by several minutes = (3=20 hosts, each ~5 minutes apart): When migrating from a host with lower uptime= =20 to a host with higher uptime, the VM looses it's network connection for som= e=20 time and then continues after some minutes (roughly equivalent to the=20 difference in uptime?). There are two different symptoms: Either the VM becomes unpingable, or the = VM=20 is pingable but the ssh-connection freezes: a while-loop dumping /proc/upti= me=20 freezes and continues without a jump after the freeze is over. When looking at the output of dmesg of the domU, I also see a jump in the=20 timestamp: [1967742.320218] eth0: no IPv6 routers present [1968779.217256] suspending xenstore... [1968779.217358] trying to map vcpu_info 0 at ffff88000bcbc020, mfn 85e61e, offset 32 [1968779.217358] cpu 0 using vcpu_info at ffff88000bcbc020 [ 5655.842391] suspending xenstore... [ 5655.842477] trying to map vcpu_info 0 at ffff88000bcbc020, mfn d5e61e, offset 32 [ 5655.842477] cpu 0 using vcpu_info at ffff88000bcbc020 [ 7745.941585] suspending xenstore... [ 7745.941667] trying to map vcpu_info 0 at ffff88000bcbc020, mfn be4163, offset 32 [ 7745.941667] cpu 0 using vcpu_info at ffff88000bcbc020 [342272.197261] suspending xenstore... If I revert the following commit (original from 2.6.36-rc1), the problem do= es=20 not show in 2.6.32.y: commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a Author: Jeremy Fitzhardinge Date: Mon Jul 12 11:49:59 2010 -0700 xen: drop xen_sched_clock in favour of using plain wallclock time =20 xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a proce= ss actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. =20 So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. 2.6.36 does not work, since 489fb49 and e7a3481 are missing: Without=20 the "global synchonization point for pvclock" (AKA last_value) plus the fix= =20 to "reset it to 0 on resume" VMs migrate fine in the opposite direction=20 (older=3Dhigher uptime =E2=86=92 newer=3Dlower uptime), but the original di= rection=20 (lower=E2=86=92higher) now stalls for 5 minutes. 2.6.37 (which includes above patches) works fine in both directions (I only= =20 see a 2 second network dropout for 2 VMs going lower=E2=86=92higher). So so= mething=20 other must have changed also, which is missing in 2.6.32.59 so far. I tried to unserstand all those clockevent, timer, pvclock, sched_clock()=20 details, but now I'm stuck. To me it looks like xen_clocksource_read() is n= ot=20 monotonic over migration, which seems to break some assumtion of=20 sched_clock() being monotonic. Has sombody else observed a similar problem and can provide a helpful hint? Is there anything I can look at to get this issue solved? Sincerely Philipp PS: bisecting did not help much, since 2.6.32.59 contains a lot of back-por= ts=20 from 2.6.33, 35, 36 and 37. 2.6.33 needs 281ff33 # x86_64, cpa: Don't work hard in preserving kernel 2M= =20 mappings when using 4K already 2.6.33-rc1: c5cae66 fixes 65f6338 # do_suspend error handling 2.6.35-rc1: e7a3481 fixes 489fb49 # global sync point 2.6.37 needs ceff1a7 # /proc/kcore: fix seeking =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ --nextPart13234650.LQF3ZOgi9e 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) iEYEABECAAYFAk+jmSwACgkQYPlgoZpUDjkQjwCfXx7naF4FJqPmVxb90peYuItO qPgAn0BQiYLhoCo2839rE8Hx7LVZRMjQ =zwQo -----END PGP SIGNATURE----- --nextPart13234650.LQF3ZOgi9e-- --===============4798092387412600323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4798092387412600323==-- From xen-devel-bounces@lists.xen.org Fri May 04 08:54:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 08:54:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEHC-00041J-R4; Fri, 04 May 2012 08:54:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEHC-00041E-6b for xen-devel@lists.xen.org; Fri, 04 May 2012 08:54:10 +0000 Received: from [85.158.143.99:39079] by server-3.bemta-4.messagelabs.com id ED/A4-05853-13993AF4; Fri, 04 May 2012 08:54:09 +0000 X-Env-Sender: hahn@univention.de X-Msg-Ref: server-10.tower-216.messagelabs.com!1336121647!20079846!1 X-Originating-IP: [82.198.197.8] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13648 invoked from network); 4 May 2012 08:54:07 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-10.tower-216.messagelabs.com with SMTP; 4 May 2012 08:54:07 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 46D7E67BB0D; Fri, 4 May 2012 10:54:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 27F1867BB0E; Fri, 4 May 2012 10:54:06 +0200 (CEST) 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 gVepBKd6q3Jf; Fri, 4 May 2012 10:54:05 +0200 (CEST) Received: from stave.knut.univention.de (port-92-196-73-46.dynamic.qsc.de [92.196.73.46]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 0E32767BB0D; Fri, 4 May 2012 10:54:04 +0200 (CEST) From: Philipp Hahn Organization: Univention.de To: Xen-devel@lists.xen.org Date: Fri, 4 May 2012 10:54:03 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286) MIME-Version: 1.0 Message-Id: <201205041054.04079.hahn@univention.de> Cc: Thomas Gleixner , Jeremy Fitzhardinge Subject: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4798092387412600323==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4798092387412600323== Content-Type: multipart/signed; boundary="nextPart13234650.LQF3ZOgi9e"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart13234650.LQF3ZOgi9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I encountered the following bug when migrating a Linux-2.6.32.54 PV domain = on=20 Xen-3.4.3 between different hosts, whose uptime differs by several minutes = (3=20 hosts, each ~5 minutes apart): When migrating from a host with lower uptime= =20 to a host with higher uptime, the VM looses it's network connection for som= e=20 time and then continues after some minutes (roughly equivalent to the=20 difference in uptime?). There are two different symptoms: Either the VM becomes unpingable, or the = VM=20 is pingable but the ssh-connection freezes: a while-loop dumping /proc/upti= me=20 freezes and continues without a jump after the freeze is over. When looking at the output of dmesg of the domU, I also see a jump in the=20 timestamp: [1967742.320218] eth0: no IPv6 routers present [1968779.217256] suspending xenstore... [1968779.217358] trying to map vcpu_info 0 at ffff88000bcbc020, mfn 85e61e, offset 32 [1968779.217358] cpu 0 using vcpu_info at ffff88000bcbc020 [ 5655.842391] suspending xenstore... [ 5655.842477] trying to map vcpu_info 0 at ffff88000bcbc020, mfn d5e61e, offset 32 [ 5655.842477] cpu 0 using vcpu_info at ffff88000bcbc020 [ 7745.941585] suspending xenstore... [ 7745.941667] trying to map vcpu_info 0 at ffff88000bcbc020, mfn be4163, offset 32 [ 7745.941667] cpu 0 using vcpu_info at ffff88000bcbc020 [342272.197261] suspending xenstore... If I revert the following commit (original from 2.6.36-rc1), the problem do= es=20 not show in 2.6.32.y: commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a Author: Jeremy Fitzhardinge Date: Mon Jul 12 11:49:59 2010 -0700 xen: drop xen_sched_clock in favour of using plain wallclock time =20 xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a proce= ss actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. =20 So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. 2.6.36 does not work, since 489fb49 and e7a3481 are missing: Without=20 the "global synchonization point for pvclock" (AKA last_value) plus the fix= =20 to "reset it to 0 on resume" VMs migrate fine in the opposite direction=20 (older=3Dhigher uptime =E2=86=92 newer=3Dlower uptime), but the original di= rection=20 (lower=E2=86=92higher) now stalls for 5 minutes. 2.6.37 (which includes above patches) works fine in both directions (I only= =20 see a 2 second network dropout for 2 VMs going lower=E2=86=92higher). So so= mething=20 other must have changed also, which is missing in 2.6.32.59 so far. I tried to unserstand all those clockevent, timer, pvclock, sched_clock()=20 details, but now I'm stuck. To me it looks like xen_clocksource_read() is n= ot=20 monotonic over migration, which seems to break some assumtion of=20 sched_clock() being monotonic. Has sombody else observed a similar problem and can provide a helpful hint? Is there anything I can look at to get this issue solved? Sincerely Philipp PS: bisecting did not help much, since 2.6.32.59 contains a lot of back-por= ts=20 from 2.6.33, 35, 36 and 37. 2.6.33 needs 281ff33 # x86_64, cpa: Don't work hard in preserving kernel 2M= =20 mappings when using 4K already 2.6.33-rc1: c5cae66 fixes 65f6338 # do_suspend error handling 2.6.35-rc1: e7a3481 fixes 489fb49 # global sync point 2.6.37 needs ceff1a7 # /proc/kcore: fix seeking =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ --nextPart13234650.LQF3ZOgi9e 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) iEYEABECAAYFAk+jmSwACgkQYPlgoZpUDjkQjwCfXx7naF4FJqPmVxb90peYuItO qPgAn0BQiYLhoCo2839rE8Hx7LVZRMjQ =zwQo -----END PGP SIGNATURE----- --nextPart13234650.LQF3ZOgi9e-- --===============4798092387412600323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4798092387412600323==-- From xen-devel-bounces@lists.xen.org Fri May 04 08:57:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQEJm-0004A0-Hu; Fri, 04 May 2012 08:56:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEJk-00049u-O9 for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:56:48 +0000 Received: from [85.158.138.51:20715] by server-5.bemta-3.messagelabs.com id 44/24-17113-FC993AF4; Fri, 04 May 2012 08:56:47 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-174.messagelabs.com!1336121805!17285226!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22532 invoked from network); 4 May 2012 08:56:46 -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; 4 May 2012 08:56:46 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQEJg-00068y-TO for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:56:44 -0700 Date: Fri, 4 May 2012 01:56:44 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336121804904-5685216.post@n5.nabble.com> In-Reply-To: <1336120109.26385.7.camel@dagon.hellion.org.uk> References: <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IChwdXR0aW5nIFBhc2kgYmFjayBpbiB0aGUgQ0Ms IHBsZWFzZSByZXRhaW4gQ0NzIG9uIHhlbi1kZXZlbCkKPiAKPiBPbiBGcmksIDIwMTItMDUtMDQg YXQgMDk6MjMgKzAxMDAsIEZhbnR1IHdyb3RlOgo+PiBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZQo+ PiA+IE9rLiBJZiB5b3UgdXNlIHFlbXUtdXBzdHJlYW0gYW5kIGNpcnJ1cy9zdGR2Z2EgKHdpdGhv dXQgcXhsKSwgZG9lcwo+PiA+IHZpZGVvbWVtID40TUIgd29yayB0aGVuID8KPj4gPiAKPj4gTm8s IGFsd2F5cyA0IG1iLCBhbHNvIHdpdGggY2lycnVzIG9yIHN0ZHZnYSB2aWRlb3JhbSBzZXR0aW5n IG5vdCB3b3JrLgo+IAo+IEJ1dCB3aXRoIFFlbXUteGVuLXRyYWRpdGlvbmFsIGl0IGRvZXMgd29y az8KPiAKPiBBbnRob255IC0tIGFueSBpZGVhIHdoeSB0aGUgdmlkZW9yYW0gc2V0dGluZyBkb2Vz bid0IHdvcmsgd2l0aCB1cHN0cmVhbQo+IHFlbXU/Cj4gCj4gCj4gCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0 Cj4gWGVuLWRldmVsQC54ZW4KPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAKV2l0 aCBxZW11LXhlbi10cmFkaXRpb25hbCB2aWRlb3JhbSBzZXR0aW5nIHdpdGggc3RkdmdhIHdvcmsu CkFib3V0IFNwaWNlIG9uIHFlbXUtdXBzdHJlYW0gZm9yIG5vdyB3ZSBkaWQgb25seSBiYXNpYyB0 ZXN0cyBhbmQgaXQgc2VlbXMgdG8KYmUgd29ya2luZyBidXQgd2l0aG91dCBxeGwgIGxpbWl0ZWQg dG8gNCBtYiBtYW55IG9mIHNwaWNlcyBmZWF0dXJlcyBhcmUgbm90CmZ1bGwgd29ya2luZy4KUXhs IHZnYSBjYW4gYmUgdXNlZCBhbHNvIHdpdGhvdXQgc3BpY2UgYW5kIHdpdGggdmlkZW9yYW0gdG8g MzIgb3IgNjQgbWIgSQp0aGluayBjYW4gZ2l2ZSBiZXR0ZXIgZ3JhcGhpYyBwZXJmb3JtYW5jZSB3 aXRoIGh2bSBkb21VLgpGb3Igbm93IGlzIG5vdCBnb29kIGV2ZW4gd2l0aG91dCBtdWx0aW1lZGlh IHVzZS4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcx Mi5uNS5uYWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2NzkxOXA1 Njg1MjE2Lmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUg YXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0 cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 04 08:57:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQEJm-0004A0-Hu; Fri, 04 May 2012 08:56:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEJk-00049u-O9 for xen-devel@lists.xensource.com; Fri, 04 May 2012 08:56:48 +0000 Received: from [85.158.138.51:20715] by server-5.bemta-3.messagelabs.com id 44/24-17113-FC993AF4; Fri, 04 May 2012 08:56:47 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-174.messagelabs.com!1336121805!17285226!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22532 invoked from network); 4 May 2012 08:56:46 -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; 4 May 2012 08:56:46 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQEJg-00068y-TO for xen-devel@lists.xensource.com; Fri, 04 May 2012 01:56:44 -0700 Date: Fri, 4 May 2012 01:56:44 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336121804904-5685216.post@n5.nabble.com> In-Reply-To: <1336120109.26385.7.camel@dagon.hellion.org.uk> References: <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IChwdXR0aW5nIFBhc2kgYmFjayBpbiB0aGUgQ0Ms IHBsZWFzZSByZXRhaW4gQ0NzIG9uIHhlbi1kZXZlbCkKPiAKPiBPbiBGcmksIDIwMTItMDUtMDQg YXQgMDk6MjMgKzAxMDAsIEZhbnR1IHdyb3RlOgo+PiBQYXNpIEvDpHJra8OkaW5lbiB3cm90ZQo+ PiA+IE9rLiBJZiB5b3UgdXNlIHFlbXUtdXBzdHJlYW0gYW5kIGNpcnJ1cy9zdGR2Z2EgKHdpdGhv dXQgcXhsKSwgZG9lcwo+PiA+IHZpZGVvbWVtID40TUIgd29yayB0aGVuID8KPj4gPiAKPj4gTm8s IGFsd2F5cyA0IG1iLCBhbHNvIHdpdGggY2lycnVzIG9yIHN0ZHZnYSB2aWRlb3JhbSBzZXR0aW5n IG5vdCB3b3JrLgo+IAo+IEJ1dCB3aXRoIFFlbXUteGVuLXRyYWRpdGlvbmFsIGl0IGRvZXMgd29y az8KPiAKPiBBbnRob255IC0tIGFueSBpZGVhIHdoeSB0aGUgdmlkZW9yYW0gc2V0dGluZyBkb2Vz bid0IHdvcmsgd2l0aCB1cHN0cmVhbQo+IHFlbXU/Cj4gCj4gCj4gCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0 Cj4gWGVuLWRldmVsQC54ZW4KPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAKV2l0 aCBxZW11LXhlbi10cmFkaXRpb25hbCB2aWRlb3JhbSBzZXR0aW5nIHdpdGggc3RkdmdhIHdvcmsu CkFib3V0IFNwaWNlIG9uIHFlbXUtdXBzdHJlYW0gZm9yIG5vdyB3ZSBkaWQgb25seSBiYXNpYyB0 ZXN0cyBhbmQgaXQgc2VlbXMgdG8KYmUgd29ya2luZyBidXQgd2l0aG91dCBxeGwgIGxpbWl0ZWQg dG8gNCBtYiBtYW55IG9mIHNwaWNlcyBmZWF0dXJlcyBhcmUgbm90CmZ1bGwgd29ya2luZy4KUXhs IHZnYSBjYW4gYmUgdXNlZCBhbHNvIHdpdGhvdXQgc3BpY2UgYW5kIHdpdGggdmlkZW9yYW0gdG8g MzIgb3IgNjQgbWIgSQp0aGluayBjYW4gZ2l2ZSBiZXR0ZXIgZ3JhcGhpYyBwZXJmb3JtYW5jZSB3 aXRoIGh2bSBkb21VLgpGb3Igbm93IGlzIG5vdCBnb29kIGV2ZW4gd2l0aG91dCBtdWx0aW1lZGlh IHVzZS4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0NTcx Mi5uNS5uYWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2NzkxOXA1 Njg1MjE2Lmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUg YXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0 cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 04 09:07:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQETx-0004QH-Um; Fri, 04 May 2012 09:07:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWZH-0004cd-65 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:13:55 +0000 Received: from [85.158.143.99:60968] by server-1.bemta-4.messagelabs.com id 97/B4-20925-2E801AF4; Wed, 02 May 2012 10:13:54 +0000 X-Env-Sender: jana@saout.de X-Msg-Ref: server-4.tower-216.messagelabs.com!1335953632!20851945!1 X-Originating-IP: [78.46.99.52] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32333 invoked from network); 2 May 2012 10:13:53 -0000 Received: from websrv.saout.de (HELO websrv.saout.de) (78.46.99.52) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:13:53 -0000 Received: from [192.168.128.60] (p50994a5e.dip0.t-ipconnect.de [80.153.74.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.saout.de (Postfix) with ESMTPSA id 9ED33C125; Wed, 2 May 2012 12:13:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default; t=1335953631; bh=oFXyDOnPmrTzPn1p9tNG6BQbGmlVcrIwKlGBADD2PEs=; h=Message-ID:Subject:From:Date:In-Reply-To:References; b=APHquRfe8QTbrDM/6Ou4FLdUwkVLM/f9d9hna4Cvw/SiYtyQX+4UMFO/KBI8SFJx+ 12mhyW1wn27veOglwa72DtU9y3fKGJjsTNPzswW0NAAKPtIpI77flEYcAqGNVVMMF9 QeGVNxua1sLKTqtlsWj6OhFhZaM/ivUmciCqJntA= Message-ID: <1335953632.3599.16.camel@localhost> From: Jana Saout To: Dan Magenheimer Date: Wed, 02 May 2012 12:13:52 +0200 In-Reply-To: References: <1335728058.4574.18.camel@localhost> X-Mailer: Evolution 3.4.1 Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 09:07:20 +0000 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Dan, > > I have been testing autoballooning on a production Xen system today > > (with cleancache + frontswap on Xen-provided tmem). For most of the > > idle or CPU-centric VMs it seems to work just fine. > > > > However, on one of the web-serving VMs, there is also a cron job running > > every few minutes which runs over a rather large directory (plus, this > > directory is on OCFS2 so this is a rather time-consuming process). Now, > > if the dcache/inode cache is large enough (which it was before, since > > the VM got allocated 4 GB and is only using 1-2 most of the time), this > > was not a problem. > > > > Now, with self-ballooning, the memory gets reduced to somewhat between 1 > > and 2 GB and after a few minutes the load is going through the ceiling. > > Jobs reading through said directories are piling up (stuck in D state, > > waiting for the FS). And most of the time kswapd is spinning at 100%. > > If I deactivate self-ballooning and assign the VM 3 GB, everything goes > > back to normal after a few minutes. (and, "ls -l" on said directory is > > served from the cache again). > > > > Now, I am aware that said problem is a self-made one. The directory was > > not actually supposed to contain that many files and the next job not > > waiting for the previous job to terminate is cause for trouble - but > > still, I would consider this a possible regression since it seems > > self-ballooning is constantly thrashing the VM's caches. Not all caches > > can be saved in cleancache. > > > > What about an additional tunable: a user-specified amount of pages that > > is added on top of the computed target number of pages? This way, one > > could manually reserve a bit more room for other types of caches. (in > > fact, I might try this myself, since it shouldn't be too hard to do so) > > > > Any opinions on this? > > Thanks for doing this analysis. While your workload is a bit > unusual, I agree that you have exposed a problem that will need > to be resolved. It was observed three years ago that the next > "frontend" for tmem could handle a cleancache-like mechanism > for the dcache. Until now, I had thought that this was purely > optional and would yield only a small performance improvement. > But with your workload, I think the combination of the facts that > selfballooning is forcing out dcache entries and they aren't > being saved in tmem is resulting in the problem you are seeing. Yes. In fact, I've been rolling out selfballooning across a development system and most VMs were just fine with the default. The overall memory savings from going from a static to a dynamic memory allocation is quite significant - without the VMs having to resort to actual to-disk-paging when there is a sudden increase in memory usage. Quite nice. Just for information: The filesystem which this machine was using is OCFS2 (shared across 5 VMs) and the directory contains 45k files (*cough* - I'm aware that's not optimal, I'm currently talking to the dev of that application to not scan the entire list of files every minute) - which takes a few minutes (especially stat'ing every file). I have been observing, that kswapd seems rather busy at times on some VMs, even when there is no actual swapping taking place. (or, could it be frontswap or just page reclaim?) This can be migitated by increasing the memory reserve a bit using my trivial test patch (see below). > I think the best solution for this will be a "cleandcache" > patch in the Linux guest... but given how long it has taken > to get cleancache and frontswap into the kernel (and the fact > that a working cleandcache patch doesn't even exist yet), I > wouldn't hold my breath ;-) I will put it on the "to do" > list though. That sounds nice! > Your idea of the tunable is interesting (and patches are always > welcome!) but I am skeptical that it will solve the problem > since I would guess the Linux kernel is shrinking dcache > proportional to the size of the page cache. So adding more > RAM with your "user-specified amount of pages that is > added on top of the computed target number of pages", > the RAM will still be shared across all caches and only > some small portion of the added RAM will likely be used > for dcache. That's true. In fact, I have to add about 1 GB of memory in order to keep the relevant dcache / inode cache entries to stay in the cache. When I do that the largest portion of memory is still eaten up by the regular page cache. So this is more of a workaround than a solution, but for now it works. I've attached the simple patch I've whipped up below. > However, if you have a chance to try it, I would be interested > in your findings. Note that you already can set a > permanent floor for selfballooning ("min_usable_mb") or, > of course, just turn off selfballooning altogether. Sure, that's always a possibility. However, the VM already had an overly large amount of memory before to avoid the problem. Now it runs with less memory (still a bit more than required), and when a load spike comes, it can quickly balloon up, which is exactly what I was looking for. Jana ---- Author: Jana Saout Date: Sun Apr 29 22:09:29 2012 +0200 Add selfballoning memory reservation tunable. diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 146c948..7d041cb 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; */ static unsigned int selfballoon_min_usable_mb; +/* + * Amount of RAM in MB to add to the target number of pages. + * Can be used to reserve some more room for caches and the like. + */ +static unsigned int selfballoon_reserved_mb; + static void selfballoon_process(struct work_struct *work); static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) cur_pages = totalram_pages; tgt_pages = cur_pages; /* default is no change */ goal_pages = percpu_counter_read_positive(&vm_committed_as) + - totalreserve_pages; + totalreserve_pages + + MB2PAGES(selfballoon_reserved_mb); #ifdef CONFIG_FRONTSWAP /* allow space for frontswap pages to be repatriated */ if (frontswap_selfshrinking && frontswap_enabled) @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, show_selfballoon_min_usable_mb, store_selfballoon_min_usable_mb); +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", + selfballoon_reserved_mb); + +static ssize_t store_selfballoon_reserved_mb(struct device *dev, + struct device_attribute *attr, + const char *buf, + size_t count) +{ + unsigned long val; + int err; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + err = strict_strtoul(buf, 10, &val); + if (err) + return -EINVAL; + selfballoon_reserved_mb = val; + return count; +} + +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, + show_selfballoon_reserved_mb, + store_selfballoon_reserved_mb); + #ifdef CONFIG_FRONTSWAP SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { &dev_attr_selfballoon_downhysteresis.attr, &dev_attr_selfballoon_uphysteresis.attr, &dev_attr_selfballoon_min_usable_mb.attr, + &dev_attr_selfballoon_reserved_mb.attr, #ifdef CONFIG_FRONTSWAP &dev_attr_frontswap_selfshrinking.attr, &dev_attr_frontswap_hysteresis.attr, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQETx-0004QH-Um; Fri, 04 May 2012 09:07:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWZH-0004cd-65 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:13:55 +0000 Received: from [85.158.143.99:60968] by server-1.bemta-4.messagelabs.com id 97/B4-20925-2E801AF4; Wed, 02 May 2012 10:13:54 +0000 X-Env-Sender: jana@saout.de X-Msg-Ref: server-4.tower-216.messagelabs.com!1335953632!20851945!1 X-Originating-IP: [78.46.99.52] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32333 invoked from network); 2 May 2012 10:13:53 -0000 Received: from websrv.saout.de (HELO websrv.saout.de) (78.46.99.52) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:13:53 -0000 Received: from [192.168.128.60] (p50994a5e.dip0.t-ipconnect.de [80.153.74.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.saout.de (Postfix) with ESMTPSA id 9ED33C125; Wed, 2 May 2012 12:13:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default; t=1335953631; bh=oFXyDOnPmrTzPn1p9tNG6BQbGmlVcrIwKlGBADD2PEs=; h=Message-ID:Subject:From:Date:In-Reply-To:References; b=APHquRfe8QTbrDM/6Ou4FLdUwkVLM/f9d9hna4Cvw/SiYtyQX+4UMFO/KBI8SFJx+ 12mhyW1wn27veOglwa72DtU9y3fKGJjsTNPzswW0NAAKPtIpI77flEYcAqGNVVMMF9 QeGVNxua1sLKTqtlsWj6OhFhZaM/ivUmciCqJntA= Message-ID: <1335953632.3599.16.camel@localhost> From: Jana Saout To: Dan Magenheimer Date: Wed, 02 May 2012 12:13:52 +0200 In-Reply-To: References: <1335728058.4574.18.camel@localhost> X-Mailer: Evolution 3.4.1 Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 09:07:20 +0000 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Dan, > > I have been testing autoballooning on a production Xen system today > > (with cleancache + frontswap on Xen-provided tmem). For most of the > > idle or CPU-centric VMs it seems to work just fine. > > > > However, on one of the web-serving VMs, there is also a cron job running > > every few minutes which runs over a rather large directory (plus, this > > directory is on OCFS2 so this is a rather time-consuming process). Now, > > if the dcache/inode cache is large enough (which it was before, since > > the VM got allocated 4 GB and is only using 1-2 most of the time), this > > was not a problem. > > > > Now, with self-ballooning, the memory gets reduced to somewhat between 1 > > and 2 GB and after a few minutes the load is going through the ceiling. > > Jobs reading through said directories are piling up (stuck in D state, > > waiting for the FS). And most of the time kswapd is spinning at 100%. > > If I deactivate self-ballooning and assign the VM 3 GB, everything goes > > back to normal after a few minutes. (and, "ls -l" on said directory is > > served from the cache again). > > > > Now, I am aware that said problem is a self-made one. The directory was > > not actually supposed to contain that many files and the next job not > > waiting for the previous job to terminate is cause for trouble - but > > still, I would consider this a possible regression since it seems > > self-ballooning is constantly thrashing the VM's caches. Not all caches > > can be saved in cleancache. > > > > What about an additional tunable: a user-specified amount of pages that > > is added on top of the computed target number of pages? This way, one > > could manually reserve a bit more room for other types of caches. (in > > fact, I might try this myself, since it shouldn't be too hard to do so) > > > > Any opinions on this? > > Thanks for doing this analysis. While your workload is a bit > unusual, I agree that you have exposed a problem that will need > to be resolved. It was observed three years ago that the next > "frontend" for tmem could handle a cleancache-like mechanism > for the dcache. Until now, I had thought that this was purely > optional and would yield only a small performance improvement. > But with your workload, I think the combination of the facts that > selfballooning is forcing out dcache entries and they aren't > being saved in tmem is resulting in the problem you are seeing. Yes. In fact, I've been rolling out selfballooning across a development system and most VMs were just fine with the default. The overall memory savings from going from a static to a dynamic memory allocation is quite significant - without the VMs having to resort to actual to-disk-paging when there is a sudden increase in memory usage. Quite nice. Just for information: The filesystem which this machine was using is OCFS2 (shared across 5 VMs) and the directory contains 45k files (*cough* - I'm aware that's not optimal, I'm currently talking to the dev of that application to not scan the entire list of files every minute) - which takes a few minutes (especially stat'ing every file). I have been observing, that kswapd seems rather busy at times on some VMs, even when there is no actual swapping taking place. (or, could it be frontswap or just page reclaim?) This can be migitated by increasing the memory reserve a bit using my trivial test patch (see below). > I think the best solution for this will be a "cleandcache" > patch in the Linux guest... but given how long it has taken > to get cleancache and frontswap into the kernel (and the fact > that a working cleandcache patch doesn't even exist yet), I > wouldn't hold my breath ;-) I will put it on the "to do" > list though. That sounds nice! > Your idea of the tunable is interesting (and patches are always > welcome!) but I am skeptical that it will solve the problem > since I would guess the Linux kernel is shrinking dcache > proportional to the size of the page cache. So adding more > RAM with your "user-specified amount of pages that is > added on top of the computed target number of pages", > the RAM will still be shared across all caches and only > some small portion of the added RAM will likely be used > for dcache. That's true. In fact, I have to add about 1 GB of memory in order to keep the relevant dcache / inode cache entries to stay in the cache. When I do that the largest portion of memory is still eaten up by the regular page cache. So this is more of a workaround than a solution, but for now it works. I've attached the simple patch I've whipped up below. > However, if you have a chance to try it, I would be interested > in your findings. Note that you already can set a > permanent floor for selfballooning ("min_usable_mb") or, > of course, just turn off selfballooning altogether. Sure, that's always a possibility. However, the VM already had an overly large amount of memory before to avoid the problem. Now it runs with less memory (still a bit more than required), and when a load spike comes, it can quickly balloon up, which is exactly what I was looking for. Jana ---- Author: Jana Saout Date: Sun Apr 29 22:09:29 2012 +0200 Add selfballoning memory reservation tunable. diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c index 146c948..7d041cb 100644 --- a/drivers/xen/xen-selfballoon.c +++ b/drivers/xen/xen-selfballoon.c @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; */ static unsigned int selfballoon_min_usable_mb; +/* + * Amount of RAM in MB to add to the target number of pages. + * Can be used to reserve some more room for caches and the like. + */ +static unsigned int selfballoon_reserved_mb; + static void selfballoon_process(struct work_struct *work); static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) cur_pages = totalram_pages; tgt_pages = cur_pages; /* default is no change */ goal_pages = percpu_counter_read_positive(&vm_committed_as) + - totalreserve_pages; + totalreserve_pages + + MB2PAGES(selfballoon_reserved_mb); #ifdef CONFIG_FRONTSWAP /* allow space for frontswap pages to be repatriated */ if (frontswap_selfshrinking && frontswap_enabled) @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, show_selfballoon_min_usable_mb, store_selfballoon_min_usable_mb); +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", + selfballoon_reserved_mb); + +static ssize_t store_selfballoon_reserved_mb(struct device *dev, + struct device_attribute *attr, + const char *buf, + size_t count) +{ + unsigned long val; + int err; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + err = strict_strtoul(buf, 10, &val); + if (err) + return -EINVAL; + selfballoon_reserved_mb = val; + return count; +} + +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, + show_selfballoon_reserved_mb, + store_selfballoon_reserved_mb); + #ifdef CONFIG_FRONTSWAP SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { &dev_attr_selfballoon_downhysteresis.attr, &dev_attr_selfballoon_uphysteresis.attr, &dev_attr_selfballoon_min_usable_mb.attr, + &dev_attr_selfballoon_reserved_mb.attr, #ifdef CONFIG_FRONTSWAP &dev_attr_frontswap_selfshrinking.attr, &dev_attr_frontswap_hysteresis.attr, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEU3-0004Qb-AX; Fri, 04 May 2012 09:07:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCXa-0006jo-82 for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:50:50 +0000 Received: from [85.158.138.51:49263] by server-6.bemta-3.messagelabs.com id 9C/C1-05145-92CDF9F4; Tue, 01 May 2012 12:50:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1335876648!22833356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26073 invoked from network); 1 May 2012 12:50:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 12:50:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12222346" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 12:50: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, 1 May 2012 13:50:47 +0100 Message-ID: <1335876646.6038.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Raghavendra K T Date: Tue, 1 May 2012 13:50:46 +0100 In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue> References: <20120419201209.5411.43877.sendpatchset@codeblue> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 09:07:26 +0000 Cc: Andrew Jones , Xen Devel , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , LKML , Srivatsa Vaddagiri , Marcelo Tosatti , Andi Kleen , Stephan Diestelhorst , Jeremy Fitzhardinge , "H. Peter Anvin" , Attilio Rao , Ingo Molnar , Virtualization , Linus Torvalds , Konrad Rzeszutek Wilk , Avi Kivity Subject: Re: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-04-19 at 21:12 +0100, Raghavendra K T wrote: > From: Jeremy Fitzhardinge > > This series replaces the existing paravirtualized spinlock mechanism > with a paravirtualized ticketlock mechanism. (targeted for 3.5 window) Which tree is this series going through, tip.git I guess? I don't see it there. Ian. > > Changes in V7: > - Reabsed patches to 3.4-rc3 > - Added jumplabel split patch (originally from Andrew Jones rebased to > 3.4-rc3 > - jumplabel changes from Ingo and Jason taken and now using static_key_* > instead of static_branch. > - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus) > - This patch series is rebased on debugfs patch (that sould be already in > Xen/linux-next https://lkml.org/lkml/2012/3/23/51) > > Ticket locks have an inherent problem in a virtualized case, because > the vCPUs are scheduled rather than running concurrently (ignoring > gang scheduled vCPUs). This can result in catastrophic performance > collapses when the vCPU scheduler doesn't schedule the correct "next" > vCPU, and ends up scheduling a vCPU which burns its entire timeslice > spinning. (Note that this is not the same problem as lock-holder > preemption, which this series also addresses; that's also a problem, > but not catastrophic). > > (See Thomas Friebel's talk "Prevent Guests from Spinning Around" > http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) > > Currently we deal with this by having PV spinlocks, which adds a layer > of indirection in front of all the spinlock functions, and defining a > completely new implementation for Xen (and for other pvops users, but > there are none at present). > > PV ticketlocks keeps the existing ticketlock implemenentation > (fastpath) as-is, but adds a couple of pvops for the slow paths: > > - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD > iterations, then call out to the __ticket_lock_spinning() pvop, > which allows a backend to block the vCPU rather than spinning. This > pvop can set the lock into "slowpath state". > > - When releasing a lock, if it is in "slowpath state", the call > __ticket_unlock_kick() to kick the next vCPU in line awake. If the > lock is no longer in contention, it also clears the slowpath flag. > > The "slowpath state" is stored in the LSB of the within the lock tail > ticket. This has the effect of reducing the max number of CPUs by > half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" > 32768). > > This series provides a Xen implementation, KVM implementation will be > posted in next 2-3 days. > > Overall, it results in a large reduction in code, it makes the native > and virtualized cases closer, and it removes a layer of indirection > around all the spinlock functions. > > The fast path (taking an uncontended lock which isn't in "slowpath" > state) is optimal, identical to the non-paravirtualized case. > > The inner part of ticket lock code becomes: > inc = xadd(&lock->tickets, inc); > inc.tail &= ~TICKET_SLOWPATH_FLAG; > > if (likely(inc.head == inc.tail)) > goto out; > for (;;) { > unsigned count = SPIN_THRESHOLD; > do { > if (ACCESS_ONCE(lock->tickets.head) == inc.tail) > goto out; > cpu_relax(); > } while (--count); > __ticket_lock_spinning(lock, inc.tail); > } > out: barrier(); > which results in: > push %rbp > mov %rsp,%rbp > > mov $0x200,%eax > lock xadd %ax,(%rdi) > movzbl %ah,%edx > cmp %al,%dl > jne 1f # Slowpath if lock in contention > > pop %rbp > retq > > ### SLOWPATH START > 1: and $-2,%edx > movzbl %dl,%esi > > 2: mov $0x800,%eax > jmp 4f > > 3: pause > sub $0x1,%eax > je 5f > > 4: movzbl (%rdi),%ecx > cmp %cl,%dl > jne 3b > > pop %rbp > retq > > 5: callq *__ticket_lock_spinning > jmp 2b > ### SLOWPATH END > > with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where > the fastpath case is straight through (taking the lock without > contention), and the spin loop is out of line: > > push %rbp > mov %rsp,%rbp > > mov $0x100,%eax > lock xadd %ax,(%rdi) > movzbl %ah,%edx > cmp %al,%dl > jne 1f > > pop %rbp > retq > > ### SLOWPATH START > 1: pause > movzbl (%rdi),%eax > cmp %dl,%al > jne 1b > > pop %rbp > retq > ### SLOWPATH END > > The unlock code is complicated by the need to both add to the lock's > "head" and fetch the slowpath flag from "tail". This version of the > patch uses a locked add to do this, followed by a test to see if the > slowflag is set. The lock prefix acts as a full memory barrier, so we > can be sure that other CPUs will have seen the unlock before we read > the flag (without the barrier the read could be fetched from the > store queue before it hits memory, which could result in a deadlock). > > This is is all unnecessary complication if you're not using PV ticket > locks, it also uses the jump-label machinery to use the standard > "add"-based unlock in the non-PV case. > > if (TICKET_SLOWPATH_FLAG && > static_key_false(¶virt_ticketlocks_enabled))) { > arch_spinlock_t prev; > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) > __ticket_unlock_slowpath(lock, prev); > } else > __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); > which generates: > push %rbp > mov %rsp,%rbp > > nop5 # replaced by 5-byte jmp 2f when PV enabled > > # non-PV unlock > addb $0x2,(%rdi) > > 1: pop %rbp > retq > > ### PV unlock ### > 2: movzwl (%rdi),%esi # Fetch prev > > lock addb $0x2,(%rdi) # Do unlock > > testb $0x1,0x1(%rdi) # Test flag > je 1b # Finished if not set > > ### Slow path ### > add $2,%sil # Add "head" in old lock state > mov %esi,%edx > and $0xfe,%dh # clear slowflag for comparison > movzbl %dh,%eax > cmp %dl,%al # If head == tail (uncontended) > je 4f # clear slowpath flag > > # Kick next CPU waiting for lock > 3: movzbl %sil,%esi > callq *pv_lock_ops.kick > > pop %rbp > retq > > # Lock no longer contended - clear slowflag > 4: mov %esi,%eax > lock cmpxchg %dx,(%rdi) # cmpxchg to clear flag > cmp %si,%ax > jne 3b # If clear failed, then kick > > pop %rbp > retq > > So when not using PV ticketlocks, the unlock sequence just has a > 5-byte nop added to it, and the PV case is reasonable straightforward > aside from requiring a "lock add". > > TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ? > 2) experiments on further optimization possibilities. (discussed in V6) > > Results: > ======= > various form of results based on V6 of the patch series are posted in following links > https://lkml.org/lkml/2012/3/21/161 > https://lkml.org/lkml/2012/3/21/198 > > kvm results: > https://lkml.org/lkml/2012/3/23/50 > https://lkml.org/lkml/2012/4/5/73 > > Thoughts? Comments? Suggestions? > > Jeremy Fitzhardinge (9): > x86/spinlock: replace pv spinlocks with pv ticketlocks > x86/ticketlock: collapse a layer of functions > xen: defer spinlock setup until boot CPU setup > xen/pvticketlock: Xen implementation for PV ticket locks > xen/pvticketlocks: add xen_nopvspin parameter to disable xen pv > ticketlocks > x86/pvticketlock: use callee-save for lock_spinning > x86/pvticketlock: when paravirtualizing ticket locks, increment by 2 > x86/ticketlock: add slowpath logic > xen/pvticketlock: allow interrupts to be enabled while blocking > > Raghavendra K T (1): > x86/ticketlock: don't inline _spin_unlock when using paravirt > spinlocks > > Andrew Jones (1): > split out rate limiting from jump_label.h > > Stefano Stabellini (1): > xen: enable PV ticketlocks on HVM Xen > --- > > V6 : https://lkml.org/lkml/2012/3/21/161 > > Changes in V6 posting: (Raghavendra K T) > - Rebased to linux-3.3-rc6. > - used function+enum in place of macro (better type checking) > - use cmpxchg while resetting zero status for possible race > [suggested by Dave Hansen for KVM patches ] > > arch/x86/Kconfig | 1 + > arch/x86/include/asm/paravirt.h | 32 +--- > arch/x86/include/asm/paravirt_types.h | 10 +- > arch/x86/include/asm/spinlock.h | 128 ++++++++---- > arch/x86/include/asm/spinlock_types.h | 16 +- > arch/x86/kernel/paravirt-spinlocks.c | 18 +-- > arch/x86/xen/smp.c | 3 +- > arch/x86/xen/spinlock.c | 383 +++++++++++---------------------- > include/linux/jump_label.h | 26 +--- > include/linux/jump_label_ratelimit.h | 34 +++ > include/linux/perf_event.h | 1 + > kernel/jump_label.c | 1 + > 12 files changed, 279 insertions(+), 374 deletions(-) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEU3-0004Qb-AX; Fri, 04 May 2012 09:07:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPCXa-0006jo-82 for xen-devel@lists.xensource.com; Tue, 01 May 2012 12:50:50 +0000 Received: from [85.158.138.51:49263] by server-6.bemta-3.messagelabs.com id 9C/C1-05145-92CDF9F4; Tue, 01 May 2012 12:50:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1335876648!22833356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzA5NQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26073 invoked from network); 1 May 2012 12:50:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 12:50:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208";a="12222346" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 May 2012 12:50: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, 1 May 2012 13:50:47 +0100 Message-ID: <1335876646.6038.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Raghavendra K T Date: Tue, 1 May 2012 13:50:46 +0100 In-Reply-To: <20120419201209.5411.43877.sendpatchset@codeblue> References: <20120419201209.5411.43877.sendpatchset@codeblue> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 09:07:26 +0000 Cc: Andrew Jones , Xen Devel , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , LKML , Srivatsa Vaddagiri , Marcelo Tosatti , Andi Kleen , Stephan Diestelhorst , Jeremy Fitzhardinge , "H. Peter Anvin" , Attilio Rao , Ingo Molnar , Virtualization , Linus Torvalds , Konrad Rzeszutek Wilk , Avi Kivity Subject: Re: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-04-19 at 21:12 +0100, Raghavendra K T wrote: > From: Jeremy Fitzhardinge > > This series replaces the existing paravirtualized spinlock mechanism > with a paravirtualized ticketlock mechanism. (targeted for 3.5 window) Which tree is this series going through, tip.git I guess? I don't see it there. Ian. > > Changes in V7: > - Reabsed patches to 3.4-rc3 > - Added jumplabel split patch (originally from Andrew Jones rebased to > 3.4-rc3 > - jumplabel changes from Ingo and Jason taken and now using static_key_* > instead of static_branch. > - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus) > - This patch series is rebased on debugfs patch (that sould be already in > Xen/linux-next https://lkml.org/lkml/2012/3/23/51) > > Ticket locks have an inherent problem in a virtualized case, because > the vCPUs are scheduled rather than running concurrently (ignoring > gang scheduled vCPUs). This can result in catastrophic performance > collapses when the vCPU scheduler doesn't schedule the correct "next" > vCPU, and ends up scheduling a vCPU which burns its entire timeslice > spinning. (Note that this is not the same problem as lock-holder > preemption, which this series also addresses; that's also a problem, > but not catastrophic). > > (See Thomas Friebel's talk "Prevent Guests from Spinning Around" > http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) > > Currently we deal with this by having PV spinlocks, which adds a layer > of indirection in front of all the spinlock functions, and defining a > completely new implementation for Xen (and for other pvops users, but > there are none at present). > > PV ticketlocks keeps the existing ticketlock implemenentation > (fastpath) as-is, but adds a couple of pvops for the slow paths: > > - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD > iterations, then call out to the __ticket_lock_spinning() pvop, > which allows a backend to block the vCPU rather than spinning. This > pvop can set the lock into "slowpath state". > > - When releasing a lock, if it is in "slowpath state", the call > __ticket_unlock_kick() to kick the next vCPU in line awake. If the > lock is no longer in contention, it also clears the slowpath flag. > > The "slowpath state" is stored in the LSB of the within the lock tail > ticket. This has the effect of reducing the max number of CPUs by > half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" > 32768). > > This series provides a Xen implementation, KVM implementation will be > posted in next 2-3 days. > > Overall, it results in a large reduction in code, it makes the native > and virtualized cases closer, and it removes a layer of indirection > around all the spinlock functions. > > The fast path (taking an uncontended lock which isn't in "slowpath" > state) is optimal, identical to the non-paravirtualized case. > > The inner part of ticket lock code becomes: > inc = xadd(&lock->tickets, inc); > inc.tail &= ~TICKET_SLOWPATH_FLAG; > > if (likely(inc.head == inc.tail)) > goto out; > for (;;) { > unsigned count = SPIN_THRESHOLD; > do { > if (ACCESS_ONCE(lock->tickets.head) == inc.tail) > goto out; > cpu_relax(); > } while (--count); > __ticket_lock_spinning(lock, inc.tail); > } > out: barrier(); > which results in: > push %rbp > mov %rsp,%rbp > > mov $0x200,%eax > lock xadd %ax,(%rdi) > movzbl %ah,%edx > cmp %al,%dl > jne 1f # Slowpath if lock in contention > > pop %rbp > retq > > ### SLOWPATH START > 1: and $-2,%edx > movzbl %dl,%esi > > 2: mov $0x800,%eax > jmp 4f > > 3: pause > sub $0x1,%eax > je 5f > > 4: movzbl (%rdi),%ecx > cmp %cl,%dl > jne 3b > > pop %rbp > retq > > 5: callq *__ticket_lock_spinning > jmp 2b > ### SLOWPATH END > > with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where > the fastpath case is straight through (taking the lock without > contention), and the spin loop is out of line: > > push %rbp > mov %rsp,%rbp > > mov $0x100,%eax > lock xadd %ax,(%rdi) > movzbl %ah,%edx > cmp %al,%dl > jne 1f > > pop %rbp > retq > > ### SLOWPATH START > 1: pause > movzbl (%rdi),%eax > cmp %dl,%al > jne 1b > > pop %rbp > retq > ### SLOWPATH END > > The unlock code is complicated by the need to both add to the lock's > "head" and fetch the slowpath flag from "tail". This version of the > patch uses a locked add to do this, followed by a test to see if the > slowflag is set. The lock prefix acts as a full memory barrier, so we > can be sure that other CPUs will have seen the unlock before we read > the flag (without the barrier the read could be fetched from the > store queue before it hits memory, which could result in a deadlock). > > This is is all unnecessary complication if you're not using PV ticket > locks, it also uses the jump-label machinery to use the standard > "add"-based unlock in the non-PV case. > > if (TICKET_SLOWPATH_FLAG && > static_key_false(¶virt_ticketlocks_enabled))) { > arch_spinlock_t prev; > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) > __ticket_unlock_slowpath(lock, prev); > } else > __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); > which generates: > push %rbp > mov %rsp,%rbp > > nop5 # replaced by 5-byte jmp 2f when PV enabled > > # non-PV unlock > addb $0x2,(%rdi) > > 1: pop %rbp > retq > > ### PV unlock ### > 2: movzwl (%rdi),%esi # Fetch prev > > lock addb $0x2,(%rdi) # Do unlock > > testb $0x1,0x1(%rdi) # Test flag > je 1b # Finished if not set > > ### Slow path ### > add $2,%sil # Add "head" in old lock state > mov %esi,%edx > and $0xfe,%dh # clear slowflag for comparison > movzbl %dh,%eax > cmp %dl,%al # If head == tail (uncontended) > je 4f # clear slowpath flag > > # Kick next CPU waiting for lock > 3: movzbl %sil,%esi > callq *pv_lock_ops.kick > > pop %rbp > retq > > # Lock no longer contended - clear slowflag > 4: mov %esi,%eax > lock cmpxchg %dx,(%rdi) # cmpxchg to clear flag > cmp %si,%ax > jne 3b # If clear failed, then kick > > pop %rbp > retq > > So when not using PV ticketlocks, the unlock sequence just has a > 5-byte nop added to it, and the PV case is reasonable straightforward > aside from requiring a "lock add". > > TODO: 1) remove CONFIG_PARAVIRT_SPINLOCK ? > 2) experiments on further optimization possibilities. (discussed in V6) > > Results: > ======= > various form of results based on V6 of the patch series are posted in following links > https://lkml.org/lkml/2012/3/21/161 > https://lkml.org/lkml/2012/3/21/198 > > kvm results: > https://lkml.org/lkml/2012/3/23/50 > https://lkml.org/lkml/2012/4/5/73 > > Thoughts? Comments? Suggestions? > > Jeremy Fitzhardinge (9): > x86/spinlock: replace pv spinlocks with pv ticketlocks > x86/ticketlock: collapse a layer of functions > xen: defer spinlock setup until boot CPU setup > xen/pvticketlock: Xen implementation for PV ticket locks > xen/pvticketlocks: add xen_nopvspin parameter to disable xen pv > ticketlocks > x86/pvticketlock: use callee-save for lock_spinning > x86/pvticketlock: when paravirtualizing ticket locks, increment by 2 > x86/ticketlock: add slowpath logic > xen/pvticketlock: allow interrupts to be enabled while blocking > > Raghavendra K T (1): > x86/ticketlock: don't inline _spin_unlock when using paravirt > spinlocks > > Andrew Jones (1): > split out rate limiting from jump_label.h > > Stefano Stabellini (1): > xen: enable PV ticketlocks on HVM Xen > --- > > V6 : https://lkml.org/lkml/2012/3/21/161 > > Changes in V6 posting: (Raghavendra K T) > - Rebased to linux-3.3-rc6. > - used function+enum in place of macro (better type checking) > - use cmpxchg while resetting zero status for possible race > [suggested by Dave Hansen for KVM patches ] > > arch/x86/Kconfig | 1 + > arch/x86/include/asm/paravirt.h | 32 +--- > arch/x86/include/asm/paravirt_types.h | 10 +- > arch/x86/include/asm/spinlock.h | 128 ++++++++---- > arch/x86/include/asm/spinlock_types.h | 16 +- > arch/x86/kernel/paravirt-spinlocks.c | 18 +-- > arch/x86/xen/smp.c | 3 +- > arch/x86/xen/spinlock.c | 383 +++++++++++---------------------- > include/linux/jump_label.h | 26 +--- > include/linux/jump_label_ratelimit.h | 34 +++ > include/linux/perf_event.h | 1 + > kernel/jump_label.c | 1 + > 12 files changed, 279 insertions(+), 374 deletions(-) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:07:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEUL-0004T5-Af; Fri, 04 May 2012 09:07:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJvk-0004BH-8b for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:44:16 +0000 Received: from [85.158.143.35:8240] by server-2.bemta-4.messagelabs.com id C4/12-17550-F1B40AF4; Tue, 01 May 2012 20:44:15 +0000 X-Env-Sender: jwboyer@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335905053!13779706!1 X-Originating-IP: [209.85.216.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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18631 invoked from network); 1 May 2012 20:44:14 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 20:44:14 -0000 Received: by qadb15 with SMTP id b15so2459005qad.9 for ; Tue, 01 May 2012 13:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S3i1lDy3auaEGNZC5ryDIqnBLkXpBsqo/X8RYt8HqUM=; b=dWY2FnFRxRtbh+aLWvJ0mtoHt1dsqHoC579TxMM4M5zO9gemAt5Oc2k3kMx/1Rtv5h eqAUlp/pjbgdA8sG1B0IwmnSDDXmw4AAarTvzSrIE8ZwhtDMLBvb7f3g4n1X+jlAOBg+ i0dgsA9uXhcrvUad6x0El/El5nblVAaSVJ4FdtNiav5R2y86h1mF0oI00re2AtBPRyhD s2uca7DntJ4D88jxyOpvth1jvCh9GObMHA6heocVEdNivsDW9bigGJSSLXp7pR7JhAJZ sHf6xrvlXLNMixRASSjMiPH6osBmJQqxQnAEHEKnvd4AUUiotjgade2BMj/a32depNI9 8S4A== MIME-Version: 1.0 Received: by 10.224.1.135 with SMTP id 7mr7175622qaf.16.1335905053356; Tue, 01 May 2012 13:44:13 -0700 (PDT) Received: by 10.229.249.193 with HTTP; Tue, 1 May 2012 13:44:13 -0700 (PDT) In-Reply-To: <20120501202640.GB16209@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> <20120501202640.GB16209@phenom.dumpdata.com> Date: Tue, 1 May 2012 16:44:13 -0400 Message-ID: From: Josh Boyer To: Konrad Rzeszutek Wilk X-Mailman-Approved-At: Fri, 04 May 2012 09:07:44 +0000 Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 1, 2012 at 4:26 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 04:08:19PM -0400, Josh Boyer wrote: >> On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk >> wrote: >> > + >> > +struct x86_io_apic_ops x86_io_apic_ops =3D { >> > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, >> > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, >> > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, >> > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, >> > +}; >> >> You'll get a section mismatch warning on this struct. =A0It's not a huge >> deal, but native_io_apic_init_mappings is annotated as __init whereas >> this struct isn't. =A0In practice it doesn't seem to matter as >> x86_io_apic_ops.init is only called in setup_arch, but it's still a >> valid warning. > > I think that the mismatch disappears if the structure has the word > _ops in it. At least that is what I saw (when I ran with the MODULE_SECTI= ON=3Dy > with the initial implementation of this and then fixed it up). > > However, let me double check - I might have seen that with something > else and misremebered it. Oh, you might very well be correct. The bug has an older version of this patch that just calls it 'x86_ioapic'. Guess I'll need to poke around and update whatever we're carrying to the latest version. If it's gone, sorry for the noise. josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:07:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEUL-0004T5-Af; Fri, 04 May 2012 09:07:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJvk-0004BH-8b for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:44:16 +0000 Received: from [85.158.143.35:8240] by server-2.bemta-4.messagelabs.com id C4/12-17550-F1B40AF4; Tue, 01 May 2012 20:44:15 +0000 X-Env-Sender: jwboyer@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1335905053!13779706!1 X-Originating-IP: [209.85.216.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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18631 invoked from network); 1 May 2012 20:44:14 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 20:44:14 -0000 Received: by qadb15 with SMTP id b15so2459005qad.9 for ; Tue, 01 May 2012 13:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S3i1lDy3auaEGNZC5ryDIqnBLkXpBsqo/X8RYt8HqUM=; b=dWY2FnFRxRtbh+aLWvJ0mtoHt1dsqHoC579TxMM4M5zO9gemAt5Oc2k3kMx/1Rtv5h eqAUlp/pjbgdA8sG1B0IwmnSDDXmw4AAarTvzSrIE8ZwhtDMLBvb7f3g4n1X+jlAOBg+ i0dgsA9uXhcrvUad6x0El/El5nblVAaSVJ4FdtNiav5R2y86h1mF0oI00re2AtBPRyhD s2uca7DntJ4D88jxyOpvth1jvCh9GObMHA6heocVEdNivsDW9bigGJSSLXp7pR7JhAJZ sHf6xrvlXLNMixRASSjMiPH6osBmJQqxQnAEHEKnvd4AUUiotjgade2BMj/a32depNI9 8S4A== MIME-Version: 1.0 Received: by 10.224.1.135 with SMTP id 7mr7175622qaf.16.1335905053356; Tue, 01 May 2012 13:44:13 -0700 (PDT) Received: by 10.229.249.193 with HTTP; Tue, 1 May 2012 13:44:13 -0700 (PDT) In-Reply-To: <20120501202640.GB16209@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> <20120501202640.GB16209@phenom.dumpdata.com> Date: Tue, 1 May 2012 16:44:13 -0400 Message-ID: From: Josh Boyer To: Konrad Rzeszutek Wilk X-Mailman-Approved-At: Fri, 04 May 2012 09:07:44 +0000 Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 1, 2012 at 4:26 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 01, 2012 at 04:08:19PM -0400, Josh Boyer wrote: >> On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk >> wrote: >> > + >> > +struct x86_io_apic_ops x86_io_apic_ops =3D { >> > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, >> > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, >> > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, >> > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, >> > +}; >> >> You'll get a section mismatch warning on this struct. =A0It's not a huge >> deal, but native_io_apic_init_mappings is annotated as __init whereas >> this struct isn't. =A0In practice it doesn't seem to matter as >> x86_io_apic_ops.init is only called in setup_arch, but it's still a >> valid warning. > > I think that the mismatch disappears if the structure has the word > _ops in it. At least that is what I saw (when I ran with the MODULE_SECTI= ON=3Dy > with the initial implementation of this and then fixed it up). > > However, let me double check - I might have seen that with something > else and misremebered it. Oh, you might very well be correct. The bug has an older version of this patch that just calls it 'x86_ioapic'. Guess I'll need to poke around and update whatever we're carrying to the latest version. If it's gone, sorry for the noise. josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEUF-0004RW-NW; Fri, 04 May 2012 09:07:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJN3-0003WK-Gq for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:08:25 +0000 Received: from [85.158.139.83:64045] by server-10.bemta-5.messagelabs.com id FD/49-08260-8B240AF4; Tue, 01 May 2012 20:08:24 +0000 X-Env-Sender: jwboyer@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1335902901!19068898!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10764 invoked from network); 1 May 2012 20:08:22 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 20:08:22 -0000 Received: by qady23 with SMTP id y23so2764205qad.7 for ; Tue, 01 May 2012 13:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ybwwV7zah6QUVKN5Onz+jkqk9qlkFlDcBYdAbjA2tW0=; b=Bau4g6YS5tEYQMINGr2yDxsXkyUQG8TABPhpaxEH3v4UluUN+0rdrdfADT66sKBJEJ +sEys28pwtt21/CxOTbEybY7eXBTKfGRcdLoPFwoOJ7PnMfN/nOLJOU16NyV+diCLKpo k6snZIOQkz+//6+ve+wMwE+RloH29xN36Mdwr9+kjUVSZyaTQ/IfNZCE1HnYCJ0FacLA KX0IH4+RCz+1fLEJkDGt22qbpmIH7I9nfDEMctKh+3Nb+M5zzTF0cPvj55sR8zYM1zX4 dxQ1ZBGG6ali6ObR86T2u559SM6LcmKEX9I3Ny1tz6O6LKc/1OTZpaYSdk3lFmuctgfp iPMA== MIME-Version: 1.0 Received: by 10.224.117.6 with SMTP id o6mr623774qaq.18.1335902900054; Tue, 01 May 2012 13:08:20 -0700 (PDT) Received: by 10.229.249.193 with HTTP; Tue, 1 May 2012 13:08:19 -0700 (PDT) In-Reply-To: <20120501194240.GA15237@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> Date: Tue, 1 May 2012 16:08:19 -0400 Message-ID: From: Josh Boyer To: Konrad Rzeszutek Wilk X-Mailman-Approved-At: Fri, 04 May 2012 09:07:38 +0000 Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk wrote: > -static void __init __ioapic_init_mappings(void) > +void __init native_io_apic_init_mappings(void) > =A0{ > =A0 =A0 =A0 =A0unsigned long ioapic_phys, idx =3D FIX_IO_APIC_BASE_0; > =A0 =A0 =A0 =A0struct resource *ioapic_res; > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 1a29015..8526317 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) > =A0 =A0 =A0 =A0init_cpu_to_node(); > > =A0 =A0 =A0 =A0init_apic_mappings(); > - =A0 =A0 =A0 ioapic_and_gsi_init(); > + =A0 =A0 =A0 x86_io_apic_ops.init(); > > =A0 =A0 =A0 =A0kvm_guest_init(); > > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > index 9cf71d0..35c5e54 100644 > --- a/arch/x86/kernel/x86_init.c > +++ b/arch/x86/kernel/x86_init.c > @@ -18,6 +18,7 @@ > =A0#include > =A0#include > =A0#include > +#include > =A0#include > =A0#include > =A0#include > @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi =3D { > =A0 =A0 =A0 =A0.teardown_msi_irqs =3D default_teardown_msi_irqs, > =A0 =A0 =A0 =A0.restore_msi_irqs =3D default_restore_msi_irqs, > =A0}; > + > +struct x86_io_apic_ops x86_io_apic_ops =3D { > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, > +}; You'll get a section mismatch warning on this struct. It's not a huge deal, but native_io_apic_init_mappings is annotated as __init whereas this struct isn't. In practice it doesn't seem to matter as x86_io_apic_ops.init is only called in setup_arch, but it's still a valid warning. (First noticed in https://bugzilla.redhat.com/show_bug.cgi?id=3D817645 ) josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:07:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEUF-0004RW-NW; Fri, 04 May 2012 09:07:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPJN3-0003WK-Gq for xen-devel@lists.xensource.com; Tue, 01 May 2012 20:08:25 +0000 Received: from [85.158.139.83:64045] by server-10.bemta-5.messagelabs.com id FD/49-08260-8B240AF4; Tue, 01 May 2012 20:08:24 +0000 X-Env-Sender: jwboyer@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1335902901!19068898!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10764 invoked from network); 1 May 2012 20:08:22 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 May 2012 20:08:22 -0000 Received: by qady23 with SMTP id y23so2764205qad.7 for ; Tue, 01 May 2012 13:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ybwwV7zah6QUVKN5Onz+jkqk9qlkFlDcBYdAbjA2tW0=; b=Bau4g6YS5tEYQMINGr2yDxsXkyUQG8TABPhpaxEH3v4UluUN+0rdrdfADT66sKBJEJ +sEys28pwtt21/CxOTbEybY7eXBTKfGRcdLoPFwoOJ7PnMfN/nOLJOU16NyV+diCLKpo k6snZIOQkz+//6+ve+wMwE+RloH29xN36Mdwr9+kjUVSZyaTQ/IfNZCE1HnYCJ0FacLA KX0IH4+RCz+1fLEJkDGt22qbpmIH7I9nfDEMctKh+3Nb+M5zzTF0cPvj55sR8zYM1zX4 dxQ1ZBGG6ali6ObR86T2u559SM6LcmKEX9I3Ny1tz6O6LKc/1OTZpaYSdk3lFmuctgfp iPMA== MIME-Version: 1.0 Received: by 10.224.117.6 with SMTP id o6mr623774qaq.18.1335902900054; Tue, 01 May 2012 13:08:20 -0700 (PDT) Received: by 10.229.249.193 with HTTP; Tue, 1 May 2012 13:08:19 -0700 (PDT) In-Reply-To: <20120501194240.GA15237@phenom.dumpdata.com> References: <20120501194240.GA15237@phenom.dumpdata.com> Date: Tue, 1 May 2012 16:08:19 -0400 Message-ID: From: Josh Boyer To: Konrad Rzeszutek Wilk X-Mailman-Approved-At: Fri, 04 May 2012 09:07:38 +0000 Cc: suresh.b.siddha@intel.com, mlin@ss.pku.edu.cn, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [Xen-devel] [GIT PULL] stable/for-ingo-v3.5 of IOAPIC abstraction (and then some users) for v3.5 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 1, 2012 at 3:42 PM, Konrad Rzeszutek Wilk wrote: > -static void __init __ioapic_init_mappings(void) > +void __init native_io_apic_init_mappings(void) > =A0{ > =A0 =A0 =A0 =A0unsigned long ioapic_phys, idx =3D FIX_IO_APIC_BASE_0; > =A0 =A0 =A0 =A0struct resource *ioapic_res; > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 1a29015..8526317 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1012,7 +1012,7 @@ void __init setup_arch(char **cmdline_p) > =A0 =A0 =A0 =A0init_cpu_to_node(); > > =A0 =A0 =A0 =A0init_apic_mappings(); > - =A0 =A0 =A0 ioapic_and_gsi_init(); > + =A0 =A0 =A0 x86_io_apic_ops.init(); > > =A0 =A0 =A0 =A0kvm_guest_init(); > > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c > index 9cf71d0..35c5e54 100644 > --- a/arch/x86/kernel/x86_init.c > +++ b/arch/x86/kernel/x86_init.c > @@ -18,6 +18,7 @@ > =A0#include > =A0#include > =A0#include > +#include > =A0#include > =A0#include > =A0#include > @@ -119,3 +120,10 @@ struct x86_msi_ops x86_msi =3D { > =A0 =A0 =A0 =A0.teardown_msi_irqs =3D default_teardown_msi_irqs, > =A0 =A0 =A0 =A0.restore_msi_irqs =3D default_restore_msi_irqs, > =A0}; > + > +struct x86_io_apic_ops x86_io_apic_ops =3D { > + =A0 =A0 =A0 .init =A0 =3D native_io_apic_init_mappings, > + =A0 =A0 =A0 .read =A0 =3D native_io_apic_read, > + =A0 =A0 =A0 .write =A0=3D native_io_apic_write, > + =A0 =A0 =A0 .modify =3D native_io_apic_modify, > +}; You'll get a section mismatch warning on this struct. It's not a huge deal, but native_io_apic_init_mappings is annotated as __init whereas this struct isn't. In practice it doesn't seem to matter as x86_io_apic_ops.init is only called in setup_arch, but it's still a valid warning. (First noticed in https://bugzilla.redhat.com/show_bug.cgi?id=3D817645 ) josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:08:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:08:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEUh-0004ZE-OT; Fri, 04 May 2012 09:08:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPegi-0002Ze-Eh for xen-devel@lists.xen.org; Wed, 02 May 2012 18:54:08 +0000 Received: from [85.158.139.83:56502] by server-1.bemta-5.messagelabs.com id A8/F8-28458-FC281AF4; Wed, 02 May 2012 18:54:07 +0000 X-Env-Sender: jwestfall@surrealistic.net X-Msg-Ref: server-6.tower-182.messagelabs.com!1335984844!22595178!1 X-Originating-IP: [75.151.103.193] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19858 invoked from network); 2 May 2012 18:54:06 -0000 Received: from whipper.surrealistic.net (HELO whipper.surrealistic.net) (75.151.103.193) by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 2 May 2012 18:54:06 -0000 Received: from jwestfall by whipper.surrealistic.net with local (Exim 4.69) (envelope-from ) id 1SPegc-00033S-Vx for xen-devel@lists.xen.org; Wed, 02 May 2012 11:54:02 -0700 Date: Wed, 2 May 2012 11:54:02 -0700 From: Jim Westfall To: xen-devel@lists.xen.org Message-ID: <20120502185402.GV5985@surrealistic.net> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Mailman-Approved-At: Fri, 04 May 2012 09:08:06 +0000 Subject: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi I wanted to bring this to your attention https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051 The summary is that when gcc compiles something with -mfma4 it also enables the use of the avx instruction set. Since by default xen disables avx it leads to invalid opcodes. This ends up being kinda nasty with the multiarch glibc since its doing stuff like (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) run_fma4_func() can end up bombing out from the invalid opcode when run under xen. Its not clear to me if xen should be filtering fma4 as part of its avx filter or if gcc should not assume avx support when compiling with -mfma4. thoughts? thanks jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:08:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:08:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEUh-0004ZE-OT; Fri, 04 May 2012 09:08:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPegi-0002Ze-Eh for xen-devel@lists.xen.org; Wed, 02 May 2012 18:54:08 +0000 Received: from [85.158.139.83:56502] by server-1.bemta-5.messagelabs.com id A8/F8-28458-FC281AF4; Wed, 02 May 2012 18:54:07 +0000 X-Env-Sender: jwestfall@surrealistic.net X-Msg-Ref: server-6.tower-182.messagelabs.com!1335984844!22595178!1 X-Originating-IP: [75.151.103.193] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19858 invoked from network); 2 May 2012 18:54:06 -0000 Received: from whipper.surrealistic.net (HELO whipper.surrealistic.net) (75.151.103.193) by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 2 May 2012 18:54:06 -0000 Received: from jwestfall by whipper.surrealistic.net with local (Exim 4.69) (envelope-from ) id 1SPegc-00033S-Vx for xen-devel@lists.xen.org; Wed, 02 May 2012 11:54:02 -0700 Date: Wed, 2 May 2012 11:54:02 -0700 From: Jim Westfall To: xen-devel@lists.xen.org Message-ID: <20120502185402.GV5985@surrealistic.net> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Mailman-Approved-At: Fri, 04 May 2012 09:08:06 +0000 Subject: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi I wanted to bring this to your attention https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051 The summary is that when gcc compiles something with -mfma4 it also enables the use of the avx instruction set. Since by default xen disables avx it leads to invalid opcodes. This ends up being kinda nasty with the multiarch glibc since its doing stuff like (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) run_fma4_func() can end up bombing out from the invalid opcode when run under xen. Its not clear to me if xen should be filtering fma4 as part of its avx filter or if gcc should not assume avx support when compiling with -mfma4. thoughts? thanks jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004ks-Fz; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSk-0004RE-QK for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:11 +0000 Received: from [193.109.254.147:20379] by server-11.bemta-14.messagelabs.com id FE/BD-05858-A4701AF4; Wed, 02 May 2012 10:07:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1335953221!2073323!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzc4NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16037 invoked from network); 2 May 2012 10:07:04 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:04 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:30 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:01:28 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q429xo4E880700 for ; Wed, 2 May 2012 19:59:50 +1000 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 q42A6d6I008640 for ; Wed, 2 May 2012 20:06:43 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A6Yd5008473; Wed, 2 May 2012 20:06:35 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:36:25 +0530 Message-Id: <20120502100625.13206.42167.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-7014-0000-0000-0000010448B1 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 1/17] x86/spinlock: Replace pv spinlocks with pv ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Rather than outright replacing the entire spinlock implementation in order to paravirtualize it, keep the ticket lock implementation but add a couple of pvops hooks on the slow patch (long spin on lock, unlocking a contended lock). Ticket locks have a number of nice properties, but they also have some surprising behaviours in virtual environments. They enforce a strict FIFO ordering on cpus trying to take a lock; however, if the hypervisor scheduler does not schedule the cpus in the correct order, the system can waste a huge amount of time spinning until the next cpu can take the lock. (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) To address this, we add two hooks: - __ticket_spin_lock which is called after the cpu has been spinning on the lock for a significant number of iterations but has failed to take the lock (presumably because the cpu holding the lock has been descheduled). The lock_spinning pvop is expected to block the cpu until it has been kicked by the current lock holder. - __ticket_spin_unlock, which on releasing a contended lock (there are more cpus with tail tickets), it looks to see if the next cpu is blocked and wakes it if so. When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub functions causes all the extra code to go away. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 32 ++++---------------- arch/x86/include/asm/paravirt_types.h | 10 ++---- arch/x86/include/asm/spinlock.h | 53 ++++++++++++++++++++++++++------ arch/x86/include/asm/spinlock_types.h | 4 -- arch/x86/kernel/paravirt-spinlocks.c | 15 +-------- arch/x86/xen/spinlock.c | 8 ++++- 6 files changed, 61 insertions(+), 61 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index aa0f913..4bcd146 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -751,36 +751,16 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline int arch_spin_is_locked(struct arch_spinlock *lock) +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, + __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock); + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline int arch_spin_is_contended(struct arch_spinlock *lock) +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock); -} -#define arch_spin_is_contended arch_spin_is_contended - -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_lock, lock); -} - -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock, - unsigned long flags) -{ - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags); -} - -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock) -{ - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock); -} - -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock); + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } #endif diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..005e24d 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -327,13 +327,11 @@ struct pv_mmu_ops { }; struct arch_spinlock; +#include + struct pv_lock_ops { - int (*spin_is_locked)(struct arch_spinlock *lock); - int (*spin_is_contended)(struct arch_spinlock *lock); - void (*spin_lock)(struct arch_spinlock *lock); - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags); - int (*spin_trylock)(struct arch_spinlock *lock); - void (*spin_unlock)(struct arch_spinlock *lock); + void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; /* This contains all the paravirt structures: we get a convenient diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 76bfa2c..3e47608 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -37,6 +37,35 @@ # define UNLOCK_LOCK_PREFIX #endif +/* How long a lock should spin before we consider blocking */ +#define SPIN_THRESHOLD (1 << 11) + +#ifndef CONFIG_PARAVIRT_SPINLOCKS + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, + __ticket_t ticket) +{ +} + +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t ticket) +{ +} + +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + +/* + * If a spinlock has someone waiting on it, then kick the appropriate + * waiting cpu. + */ +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t next) +{ + if (unlikely(lock->tickets.tail != next)) + ____ticket_unlock_kick(lock, next); +} + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -50,19 +79,24 @@ * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) +static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; inc = xadd(&lock->tickets, inc); for (;;) { - if (inc.head == inc.tail) - break; - cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); + 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); } - barrier(); /* make sure nothing creeps before the lock is taken */ +out: barrier(); /* make sure nothing creeps before the lock is taken */ } static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) @@ -81,7 +115,10 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) { + __ticket_t next = lock->tickets.head + 1; + __add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX); + __ticket_unlock_kick(lock, next); } static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) @@ -98,8 +135,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) return (__ticket_t)(tmp.tail - tmp.head) > 1; } -#ifndef CONFIG_PARAVIRT_SPINLOCKS - static inline int arch_spin_is_locked(arch_spinlock_t *lock) { return __ticket_spin_is_locked(lock); @@ -132,8 +167,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, arch_spin_lock(lock); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) { while (arch_spin_is_locked(lock)) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index ad0ad07..83fd3c7 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_SPINLOCK_TYPES_H #define _ASM_X86_SPINLOCK_TYPES_H -#ifndef __LINUX_SPINLOCK_TYPES_H -# error "please don't include this file directly" -#endif - #include #if (CONFIG_NR_CPUS < 256) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 676b8c7..c2e010e 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -7,21 +7,10 @@ #include -static inline void -default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) -{ - arch_spin_lock(lock); -} - struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .spin_is_locked = __ticket_spin_is_locked, - .spin_is_contended = __ticket_spin_is_contended, - - .spin_lock = __ticket_spin_lock, - .spin_lock_flags = default_spin_lock_flags, - .spin_trylock = __ticket_spin_trylock, - .spin_unlock = __ticket_spin_unlock, + .lock_spinning = paravirt_nop, + .unlock_kick = paravirt_nop, #endif }; EXPORT_SYMBOL(pv_lock_ops); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 00461a4..f1f4540 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -138,6 +138,9 @@ struct xen_spinlock { xen_spinners_t spinners; /* count of waiting cpus */ }; +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; + +#if 0 static int xen_spin_is_locked(struct arch_spinlock *lock) { struct xen_spinlock *xl = (struct xen_spinlock *)lock; @@ -165,7 +168,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock) return old == 0; } -static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); /* @@ -353,6 +355,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock) if (unlikely(xl->spinners)) xen_spin_unlock_slow(xl); } +#endif static irqreturn_t dummy_handler(int irq, void *dev_id) { @@ -389,13 +392,14 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t)); - +#if 0 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; pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; pv_lock_ops.spin_trylock = xen_spin_trylock; pv_lock_ops.spin_unlock = xen_spin_unlock; +#endif } #ifdef CONFIG_XEN_DEBUG_FS _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004ks-Fz; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSk-0004RE-QK for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:11 +0000 Received: from [193.109.254.147:20379] by server-11.bemta-14.messagelabs.com id FE/BD-05858-A4701AF4; Wed, 02 May 2012 10:07:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1335953221!2073323!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzc4NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16037 invoked from network); 2 May 2012 10:07:04 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:04 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:30 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:01:28 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q429xo4E880700 for ; Wed, 2 May 2012 19:59:50 +1000 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 q42A6d6I008640 for ; Wed, 2 May 2012 20:06:43 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A6Yd5008473; Wed, 2 May 2012 20:06:35 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:36:25 +0530 Message-Id: <20120502100625.13206.42167.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-7014-0000-0000-0000010448B1 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 1/17] x86/spinlock: Replace pv spinlocks with pv ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Rather than outright replacing the entire spinlock implementation in order to paravirtualize it, keep the ticket lock implementation but add a couple of pvops hooks on the slow patch (long spin on lock, unlocking a contended lock). Ticket locks have a number of nice properties, but they also have some surprising behaviours in virtual environments. They enforce a strict FIFO ordering on cpus trying to take a lock; however, if the hypervisor scheduler does not schedule the cpus in the correct order, the system can waste a huge amount of time spinning until the next cpu can take the lock. (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) To address this, we add two hooks: - __ticket_spin_lock which is called after the cpu has been spinning on the lock for a significant number of iterations but has failed to take the lock (presumably because the cpu holding the lock has been descheduled). The lock_spinning pvop is expected to block the cpu until it has been kicked by the current lock holder. - __ticket_spin_unlock, which on releasing a contended lock (there are more cpus with tail tickets), it looks to see if the next cpu is blocked and wakes it if so. When compiled with CONFIG_PARAVIRT_SPINLOCKS disabled, a set of stub functions causes all the extra code to go away. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 32 ++++---------------- arch/x86/include/asm/paravirt_types.h | 10 ++---- arch/x86/include/asm/spinlock.h | 53 ++++++++++++++++++++++++++------ arch/x86/include/asm/spinlock_types.h | 4 -- arch/x86/kernel/paravirt-spinlocks.c | 15 +-------- arch/x86/xen/spinlock.c | 8 ++++- 6 files changed, 61 insertions(+), 61 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index aa0f913..4bcd146 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -751,36 +751,16 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS) -static inline int arch_spin_is_locked(struct arch_spinlock *lock) +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, + __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_locked, lock); + PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); } -static inline int arch_spin_is_contended(struct arch_spinlock *lock) +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t ticket) { - return PVOP_CALL1(int, pv_lock_ops.spin_is_contended, lock); -} -#define arch_spin_is_contended arch_spin_is_contended - -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_lock, lock); -} - -static __always_inline void arch_spin_lock_flags(struct arch_spinlock *lock, - unsigned long flags) -{ - PVOP_VCALL2(pv_lock_ops.spin_lock_flags, lock, flags); -} - -static __always_inline int arch_spin_trylock(struct arch_spinlock *lock) -{ - return PVOP_CALL1(int, pv_lock_ops.spin_trylock, lock); -} - -static __always_inline void arch_spin_unlock(struct arch_spinlock *lock) -{ - PVOP_VCALL1(pv_lock_ops.spin_unlock, lock); + PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); } #endif diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..005e24d 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -327,13 +327,11 @@ struct pv_mmu_ops { }; struct arch_spinlock; +#include + struct pv_lock_ops { - int (*spin_is_locked)(struct arch_spinlock *lock); - int (*spin_is_contended)(struct arch_spinlock *lock); - void (*spin_lock)(struct arch_spinlock *lock); - void (*spin_lock_flags)(struct arch_spinlock *lock, unsigned long flags); - int (*spin_trylock)(struct arch_spinlock *lock); - void (*spin_unlock)(struct arch_spinlock *lock); + void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; /* This contains all the paravirt structures: we get a convenient diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 76bfa2c..3e47608 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -37,6 +37,35 @@ # define UNLOCK_LOCK_PREFIX #endif +/* How long a lock should spin before we consider blocking */ +#define SPIN_THRESHOLD (1 << 11) + +#ifndef CONFIG_PARAVIRT_SPINLOCKS + +static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, + __ticket_t ticket) +{ +} + +static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t ticket) +{ +} + +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + + +/* + * If a spinlock has someone waiting on it, then kick the appropriate + * waiting cpu. + */ +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, + __ticket_t next) +{ + if (unlikely(lock->tickets.tail != next)) + ____ticket_unlock_kick(lock, next); +} + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -50,19 +79,24 @@ * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock) +static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; inc = xadd(&lock->tickets, inc); for (;;) { - if (inc.head == inc.tail) - break; - cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); + 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); } - barrier(); /* make sure nothing creeps before the lock is taken */ +out: barrier(); /* make sure nothing creeps before the lock is taken */ } static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) @@ -81,7 +115,10 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) { + __ticket_t next = lock->tickets.head + 1; + __add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX); + __ticket_unlock_kick(lock, next); } static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) @@ -98,8 +135,6 @@ static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) return (__ticket_t)(tmp.tail - tmp.head) > 1; } -#ifndef CONFIG_PARAVIRT_SPINLOCKS - static inline int arch_spin_is_locked(arch_spinlock_t *lock) { return __ticket_spin_is_locked(lock); @@ -132,8 +167,6 @@ static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, arch_spin_lock(lock); } -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - static inline void arch_spin_unlock_wait(arch_spinlock_t *lock) { while (arch_spin_is_locked(lock)) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index ad0ad07..83fd3c7 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -1,10 +1,6 @@ #ifndef _ASM_X86_SPINLOCK_TYPES_H #define _ASM_X86_SPINLOCK_TYPES_H -#ifndef __LINUX_SPINLOCK_TYPES_H -# error "please don't include this file directly" -#endif - #include #if (CONFIG_NR_CPUS < 256) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 676b8c7..c2e010e 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -7,21 +7,10 @@ #include -static inline void -default_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) -{ - arch_spin_lock(lock); -} - struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .spin_is_locked = __ticket_spin_is_locked, - .spin_is_contended = __ticket_spin_is_contended, - - .spin_lock = __ticket_spin_lock, - .spin_lock_flags = default_spin_lock_flags, - .spin_trylock = __ticket_spin_trylock, - .spin_unlock = __ticket_spin_unlock, + .lock_spinning = paravirt_nop, + .unlock_kick = paravirt_nop, #endif }; EXPORT_SYMBOL(pv_lock_ops); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 00461a4..f1f4540 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -138,6 +138,9 @@ struct xen_spinlock { xen_spinners_t spinners; /* count of waiting cpus */ }; +static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; + +#if 0 static int xen_spin_is_locked(struct arch_spinlock *lock) { struct xen_spinlock *xl = (struct xen_spinlock *)lock; @@ -165,7 +168,6 @@ static int xen_spin_trylock(struct arch_spinlock *lock) return old == 0; } -static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); /* @@ -353,6 +355,7 @@ static void xen_spin_unlock(struct arch_spinlock *lock) if (unlikely(xl->spinners)) xen_spin_unlock_slow(xl); } +#endif static irqreturn_t dummy_handler(int irq, void *dev_id) { @@ -389,13 +392,14 @@ void xen_uninit_lock_cpu(int cpu) void __init xen_init_spinlocks(void) { BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t)); - +#if 0 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; pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; pv_lock_ops.spin_trylock = xen_spin_trylock; pv_lock_ops.spin_unlock = xen_spin_unlock; +#endif } #ifdef CONFIG_XEN_DEBUG_FS _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVW-0004lf-M9; Fri, 04 May 2012 09:08:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTH-0004Sg-Fg for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:43 +0000 Received: from [85.158.138.51:46596] by server-11.bemta-3.messagelabs.com id C8/45-18894-E6701AF4; Wed, 02 May 2012 10:07:42 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335953257!13784790!1 X-Originating-IP: [202.81.31.143] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNzEwNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13557 invoked from network); 2 May 2012 10:07:41 -0000 Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:41 -0000 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:59:33 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:59:30 +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 q42A0fFN1822942 for ; Wed, 2 May 2012 20:00:42 +1000 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 q42A7VMJ012837 for ; Wed, 2 May 2012 20:07:33 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A7QkG012658; Wed, 2 May 2012 20:07:26 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:37:16 +0530 Message-Id: <20120502100716.13206.23938.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-1618-0000-0000-00000172F84E X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 5/17] xen/pvticketlock: Xen implementation for PV ticket locks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Replace the old Xen implementation of PV spinlocks with and implementation of xen_lock_spinning and xen_unlock_kick. xen_lock_spinning simply registers the cpu in its entry in lock_waiting, adds itself to the waiting_cpus set, and blocks on an event channel until the channel becomes pending. xen_unlock_kick searches the cpus in waiting_cpus looking for the one which next wants this lock with the next ticket, if any. If found, it kicks it by making its event channel pending, which wakes it up. We need to make sure interrupts are disabled while we're relying on the contents of the per-cpu lock_waiting values, otherwise an interrupt handler could come in, try to take some other lock, block, and overwrite our values. Raghu: use function + enum instead of macro, cmpxchg for zero status reset Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 348 +++++++++++------------------------------------ 1 files changed, 78 insertions(+), 270 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index f1f4540..4e98a07 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -16,45 +16,44 @@ #include "xen-ops.h" #include "debugfs.h" -#ifdef CONFIG_XEN_DEBUG_FS -static struct xen_spinlock_stats -{ - u64 taken; - u32 taken_slow; - u32 taken_slow_nested; - u32 taken_slow_pickup; - u32 taken_slow_spurious; - u32 taken_slow_irqenable; +enum xen_contention_stat { + TAKEN_SLOW, + TAKEN_SLOW_PICKUP, + TAKEN_SLOW_SPURIOUS, + RELEASED_SLOW, + RELEASED_SLOW_KICKED, + NR_CONTENTION_STATS +}; - u64 released; - u32 released_slow; - u32 released_slow_kicked; +#ifdef CONFIG_XEN_DEBUG_FS #define HISTO_BUCKETS 30 - u32 histo_spin_total[HISTO_BUCKETS+1]; - u32 histo_spin_spinning[HISTO_BUCKETS+1]; +static struct xen_spinlock_stats +{ + u32 contention_stats[NR_CONTENTION_STATS]; u32 histo_spin_blocked[HISTO_BUCKETS+1]; - - u64 time_total; - u64 time_spinning; u64 time_blocked; } spinlock_stats; static u8 zero_stats; -static unsigned lock_timeout = 1 << 10; -#define TIMEOUT lock_timeout - static inline void check_zero(void) { - if (unlikely(zero_stats)) { - memset(&spinlock_stats, 0, sizeof(spinlock_stats)); - zero_stats = 0; + 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)); } } -#define ADD_STATS(elem, val) \ - do { check_zero(); spinlock_stats.elem += (val); } while(0) +static inline void add_stats(enum xen_contention_stat var, u32 val) +{ + check_zero(); + spinlock_stats.contention_stats[var] += val; +} static inline u64 spin_time_start(void) { @@ -73,22 +72,6 @@ static void __spin_time_accum(u64 delta, u32 *array) array[HISTO_BUCKETS]++; } -static inline void spin_time_accum_spinning(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_spinning); - spinlock_stats.time_spinning += delta; -} - -static inline void spin_time_accum_total(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_total); - spinlock_stats.time_total += delta; -} - static inline void spin_time_accum_blocked(u64 start) { u32 delta = xen_clocksource_read() - start; @@ -98,19 +81,15 @@ static inline void spin_time_accum_blocked(u64 start) } #else /* !CONFIG_XEN_DEBUG_FS */ #define TIMEOUT (1 << 10) -#define ADD_STATS(elem, val) do { (void)(val); } while(0) +static inline void add_stats(enum xen_contention_stat var, u32 val) +{ +} static inline u64 spin_time_start(void) { return 0; } -static inline void spin_time_accum_total(u64 start) -{ -} -static inline void spin_time_accum_spinning(u64 start) -{ -} static inline void spin_time_accum_blocked(u64 start) { } @@ -133,230 +112,83 @@ typedef u16 xen_spinners_t; asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory"); #endif -struct xen_spinlock { - unsigned char lock; /* 0 -> free; 1 -> locked */ - xen_spinners_t spinners; /* count of waiting cpus */ +struct xen_lock_waiting { + struct arch_spinlock *lock; + __ticket_t want; }; static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; +static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); +static cpumask_t waiting_cpus; -#if 0 -static int xen_spin_is_locked(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - return xl->lock != 0; -} - -static int xen_spin_is_contended(struct arch_spinlock *lock) +static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - /* Not strictly true; this is only the count of contended - lock-takers entering the slow path. */ - return xl->spinners != 0; -} - -static int xen_spin_trylock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - u8 old = 1; - - asm("xchgb %b0,%1" - : "+q" (old), "+m" (xl->lock) : : "memory"); - - return old == 0; -} - -static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); - -/* - * Mark a cpu as interested in a lock. Returns the CPU's previous - * lock of interest, in case we got preempted by an interrupt. - */ -static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl) -{ - struct xen_spinlock *prev; - - prev = __this_cpu_read(lock_spinners); - __this_cpu_write(lock_spinners, xl); - - wmb(); /* set lock of interest before count */ - - inc_spinners(xl); - - return prev; -} - -/* - * Mark a cpu as no longer interested in a lock. Restores previous - * lock of interest (NULL for none). - */ -static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev) -{ - dec_spinners(xl); - wmb(); /* decrement count before restoring lock */ - __this_cpu_write(lock_spinners, prev); -} - -static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __this_cpu_read(lock_kicker_irq); - int ret; + struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); + int cpu = smp_processor_id(); u64 start; + unsigned long flags; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) - return 0; + return; start = spin_time_start(); - /* announce we're spinning */ - prev = spinning_lock(xl); - - ADD_STATS(taken_slow, 1); - ADD_STATS(taken_slow_nested, prev != NULL); - - do { - unsigned long flags; - - /* clear pending */ - xen_clear_irq_pending(irq); - - /* check again make sure it didn't become free while - we weren't looking */ - ret = xen_spin_trylock(lock); - if (ret) { - ADD_STATS(taken_slow_pickup, 1); - - /* - * If we interrupted another spinlock while it - * was blocking, make sure it doesn't block - * without rechecking the lock. - */ - if (prev != NULL) - xen_set_irq_pending(irq); - goto out; - } + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ + local_irq_save(flags); - flags = arch_local_save_flags(); - if (irq_enable) { - ADD_STATS(taken_slow_irqenable, 1); - raw_local_irq_enable(); - } + w->want = want; + smp_wmb(); + w->lock = lock; - /* - * Block until irq becomes pending. If we're - * interrupted at this point (after the trylock but - * before entering the block), then the nested lock - * handler guarantees that the irq will be left - * pending if there's any chance the lock became free; - * xen_poll_irq() returns immediately if the irq is - * pending. - */ - xen_poll_irq(irq); + /* This uses set_bit, which atomic and therefore a barrier */ + cpumask_set_cpu(cpu, &waiting_cpus); + add_stats(TAKEN_SLOW, 1); - raw_local_irq_restore(flags); + /* clear pending */ + xen_clear_irq_pending(irq); - ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); - } while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */ + /* Only check lock once pending cleared */ + barrier(); + /* 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; + } + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ + xen_poll_irq(irq); + add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq)); kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); - out: - unspinning_lock(xl, prev); + cpumask_clear_cpu(cpu, &waiting_cpus); + w->lock = NULL; + local_irq_restore(flags); spin_time_accum_blocked(start); - - return ret; } -static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - unsigned timeout; - u8 oldval; - u64 start_spin; - - ADD_STATS(taken, 1); - - start_spin = spin_time_start(); - - do { - u64 start_spin_fast = spin_time_start(); - - timeout = TIMEOUT; - - asm("1: xchgb %1,%0\n" - " testb %1,%1\n" - " jz 3f\n" - "2: rep;nop\n" - " cmpb $0,%0\n" - " je 1b\n" - " dec %2\n" - " jnz 2b\n" - "3:\n" - : "+m" (xl->lock), "=q" (oldval), "+r" (timeout) - : "1" (1) - : "memory"); - - spin_time_accum_spinning(start_spin_fast); - - } while (unlikely(oldval != 0 && - (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable)))); - - spin_time_accum_total(start_spin); -} - -static void xen_spin_lock(struct arch_spinlock *lock) -{ - __xen_spin_lock(lock, false); -} - -static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags) -{ - __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags)); -} - -static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) +static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { int cpu; - ADD_STATS(released_slow, 1); + add_stats(RELEASED_SLOW, 1); + + for_each_cpu(cpu, &waiting_cpus) { + const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - for_each_online_cpu(cpu) { - /* XXX should mix up next cpu selection */ - if (per_cpu(lock_spinners, cpu) == xl) { - ADD_STATS(released_slow_kicked, 1); + if (w->lock == lock && w->want == next) { + add_stats(RELEASED_SLOW_KICKED, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; } } } -static void xen_spin_unlock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - ADD_STATS(released, 1); - - smp_wmb(); /* make sure no writes get moved after unlock */ - xl->lock = 0; /* release lock */ - - /* - * Make sure unlock happens before checking for waiting - * spinners. We need a strong barrier to enforce the - * write-read ordering to different memory locations, as the - * CPU makes no implied guarantees about their ordering. - */ - mb(); - - if (unlikely(xl->spinners)) - xen_spin_unlock_slow(xl); -} -#endif - static irqreturn_t dummy_handler(int irq, void *dev_id) { BUG(); @@ -391,15 +223,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)); -#if 0 - 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; - pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; - pv_lock_ops.spin_trylock = xen_spin_trylock; - pv_lock_ops.spin_unlock = xen_spin_unlock; -#endif + pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.unlock_kick = xen_unlock_kick; } #ifdef CONFIG_XEN_DEBUG_FS @@ -417,42 +242,25 @@ static int __init xen_spinlock_debugfs(void) debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats); - debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout); - - debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken); debugfs_create_u32("taken_slow", 0444, d_spin_debug, - &spinlock_stats.taken_slow); - debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug, - &spinlock_stats.taken_slow_nested); + &spinlock_stats.contention_stats[TAKEN_SLOW]); debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug, - &spinlock_stats.taken_slow_pickup); + &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]); debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug, - &spinlock_stats.taken_slow_spurious); - debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug, - &spinlock_stats.taken_slow_irqenable); + &spinlock_stats.contention_stats[TAKEN_SLOW_SPURIOUS]); - debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released); debugfs_create_u32("released_slow", 0444, d_spin_debug, - &spinlock_stats.released_slow); + &spinlock_stats.contention_stats[RELEASED_SLOW]); debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug, - &spinlock_stats.released_slow_kicked); + &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]); - debugfs_create_u64("time_spinning", 0444, d_spin_debug, - &spinlock_stats.time_spinning); debugfs_create_u64("time_blocked", 0444, d_spin_debug, &spinlock_stats.time_blocked); - debugfs_create_u64("time_total", 0444, d_spin_debug, - &spinlock_stats.time_total); - debugfs_create_u32_array("histo_total", 0444, d_spin_debug, - spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1); - debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug, - spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1); debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug, spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1); return 0; } fs_initcall(xen_spinlock_debugfs); - #endif /* CONFIG_XEN_DEBUG_FS */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVW-0004lf-M9; Fri, 04 May 2012 09:08:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTH-0004Sg-Fg for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:43 +0000 Received: from [85.158.138.51:46596] by server-11.bemta-3.messagelabs.com id C8/45-18894-E6701AF4; Wed, 02 May 2012 10:07:42 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335953257!13784790!1 X-Originating-IP: [202.81.31.143] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNzEwNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13557 invoked from network); 2 May 2012 10:07:41 -0000 Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:41 -0000 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:59:33 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:59:30 +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 q42A0fFN1822942 for ; Wed, 2 May 2012 20:00:42 +1000 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 q42A7VMJ012837 for ; Wed, 2 May 2012 20:07:33 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A7QkG012658; Wed, 2 May 2012 20:07:26 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:37:16 +0530 Message-Id: <20120502100716.13206.23938.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-1618-0000-0000-00000172F84E X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 5/17] xen/pvticketlock: Xen implementation for PV ticket locks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Replace the old Xen implementation of PV spinlocks with and implementation of xen_lock_spinning and xen_unlock_kick. xen_lock_spinning simply registers the cpu in its entry in lock_waiting, adds itself to the waiting_cpus set, and blocks on an event channel until the channel becomes pending. xen_unlock_kick searches the cpus in waiting_cpus looking for the one which next wants this lock with the next ticket, if any. If found, it kicks it by making its event channel pending, which wakes it up. We need to make sure interrupts are disabled while we're relying on the contents of the per-cpu lock_waiting values, otherwise an interrupt handler could come in, try to take some other lock, block, and overwrite our values. Raghu: use function + enum instead of macro, cmpxchg for zero status reset Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 348 +++++++++++------------------------------------ 1 files changed, 78 insertions(+), 270 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index f1f4540..4e98a07 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -16,45 +16,44 @@ #include "xen-ops.h" #include "debugfs.h" -#ifdef CONFIG_XEN_DEBUG_FS -static struct xen_spinlock_stats -{ - u64 taken; - u32 taken_slow; - u32 taken_slow_nested; - u32 taken_slow_pickup; - u32 taken_slow_spurious; - u32 taken_slow_irqenable; +enum xen_contention_stat { + TAKEN_SLOW, + TAKEN_SLOW_PICKUP, + TAKEN_SLOW_SPURIOUS, + RELEASED_SLOW, + RELEASED_SLOW_KICKED, + NR_CONTENTION_STATS +}; - u64 released; - u32 released_slow; - u32 released_slow_kicked; +#ifdef CONFIG_XEN_DEBUG_FS #define HISTO_BUCKETS 30 - u32 histo_spin_total[HISTO_BUCKETS+1]; - u32 histo_spin_spinning[HISTO_BUCKETS+1]; +static struct xen_spinlock_stats +{ + u32 contention_stats[NR_CONTENTION_STATS]; u32 histo_spin_blocked[HISTO_BUCKETS+1]; - - u64 time_total; - u64 time_spinning; u64 time_blocked; } spinlock_stats; static u8 zero_stats; -static unsigned lock_timeout = 1 << 10; -#define TIMEOUT lock_timeout - static inline void check_zero(void) { - if (unlikely(zero_stats)) { - memset(&spinlock_stats, 0, sizeof(spinlock_stats)); - zero_stats = 0; + 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)); } } -#define ADD_STATS(elem, val) \ - do { check_zero(); spinlock_stats.elem += (val); } while(0) +static inline void add_stats(enum xen_contention_stat var, u32 val) +{ + check_zero(); + spinlock_stats.contention_stats[var] += val; +} static inline u64 spin_time_start(void) { @@ -73,22 +72,6 @@ static void __spin_time_accum(u64 delta, u32 *array) array[HISTO_BUCKETS]++; } -static inline void spin_time_accum_spinning(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_spinning); - spinlock_stats.time_spinning += delta; -} - -static inline void spin_time_accum_total(u64 start) -{ - u32 delta = xen_clocksource_read() - start; - - __spin_time_accum(delta, spinlock_stats.histo_spin_total); - spinlock_stats.time_total += delta; -} - static inline void spin_time_accum_blocked(u64 start) { u32 delta = xen_clocksource_read() - start; @@ -98,19 +81,15 @@ static inline void spin_time_accum_blocked(u64 start) } #else /* !CONFIG_XEN_DEBUG_FS */ #define TIMEOUT (1 << 10) -#define ADD_STATS(elem, val) do { (void)(val); } while(0) +static inline void add_stats(enum xen_contention_stat var, u32 val) +{ +} static inline u64 spin_time_start(void) { return 0; } -static inline void spin_time_accum_total(u64 start) -{ -} -static inline void spin_time_accum_spinning(u64 start) -{ -} static inline void spin_time_accum_blocked(u64 start) { } @@ -133,230 +112,83 @@ typedef u16 xen_spinners_t; asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory"); #endif -struct xen_spinlock { - unsigned char lock; /* 0 -> free; 1 -> locked */ - xen_spinners_t spinners; /* count of waiting cpus */ +struct xen_lock_waiting { + struct arch_spinlock *lock; + __ticket_t want; }; static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; +static DEFINE_PER_CPU(struct xen_lock_waiting, lock_waiting); +static cpumask_t waiting_cpus; -#if 0 -static int xen_spin_is_locked(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - return xl->lock != 0; -} - -static int xen_spin_is_contended(struct arch_spinlock *lock) +static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - /* Not strictly true; this is only the count of contended - lock-takers entering the slow path. */ - return xl->spinners != 0; -} - -static int xen_spin_trylock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - u8 old = 1; - - asm("xchgb %b0,%1" - : "+q" (old), "+m" (xl->lock) : : "memory"); - - return old == 0; -} - -static DEFINE_PER_CPU(struct xen_spinlock *, lock_spinners); - -/* - * Mark a cpu as interested in a lock. Returns the CPU's previous - * lock of interest, in case we got preempted by an interrupt. - */ -static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl) -{ - struct xen_spinlock *prev; - - prev = __this_cpu_read(lock_spinners); - __this_cpu_write(lock_spinners, xl); - - wmb(); /* set lock of interest before count */ - - inc_spinners(xl); - - return prev; -} - -/* - * Mark a cpu as no longer interested in a lock. Restores previous - * lock of interest (NULL for none). - */ -static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev) -{ - dec_spinners(xl); - wmb(); /* decrement count before restoring lock */ - __this_cpu_write(lock_spinners, prev); -} - -static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __this_cpu_read(lock_kicker_irq); - int ret; + struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting); + int cpu = smp_processor_id(); u64 start; + unsigned long flags; /* If kicker interrupts not initialized yet, just spin */ if (irq == -1) - return 0; + return; start = spin_time_start(); - /* announce we're spinning */ - prev = spinning_lock(xl); - - ADD_STATS(taken_slow, 1); - ADD_STATS(taken_slow_nested, prev != NULL); - - do { - unsigned long flags; - - /* clear pending */ - xen_clear_irq_pending(irq); - - /* check again make sure it didn't become free while - we weren't looking */ - ret = xen_spin_trylock(lock); - if (ret) { - ADD_STATS(taken_slow_pickup, 1); - - /* - * If we interrupted another spinlock while it - * was blocking, make sure it doesn't block - * without rechecking the lock. - */ - if (prev != NULL) - xen_set_irq_pending(irq); - goto out; - } + /* + * Make sure an interrupt handler can't upset things in a + * partially setup state. + */ + local_irq_save(flags); - flags = arch_local_save_flags(); - if (irq_enable) { - ADD_STATS(taken_slow_irqenable, 1); - raw_local_irq_enable(); - } + w->want = want; + smp_wmb(); + w->lock = lock; - /* - * Block until irq becomes pending. If we're - * interrupted at this point (after the trylock but - * before entering the block), then the nested lock - * handler guarantees that the irq will be left - * pending if there's any chance the lock became free; - * xen_poll_irq() returns immediately if the irq is - * pending. - */ - xen_poll_irq(irq); + /* This uses set_bit, which atomic and therefore a barrier */ + cpumask_set_cpu(cpu, &waiting_cpus); + add_stats(TAKEN_SLOW, 1); - raw_local_irq_restore(flags); + /* clear pending */ + xen_clear_irq_pending(irq); - ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq)); - } while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */ + /* Only check lock once pending cleared */ + barrier(); + /* 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; + } + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ + xen_poll_irq(irq); + add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq)); kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); - out: - unspinning_lock(xl, prev); + cpumask_clear_cpu(cpu, &waiting_cpus); + w->lock = NULL; + local_irq_restore(flags); spin_time_accum_blocked(start); - - return ret; } -static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_enable) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - unsigned timeout; - u8 oldval; - u64 start_spin; - - ADD_STATS(taken, 1); - - start_spin = spin_time_start(); - - do { - u64 start_spin_fast = spin_time_start(); - - timeout = TIMEOUT; - - asm("1: xchgb %1,%0\n" - " testb %1,%1\n" - " jz 3f\n" - "2: rep;nop\n" - " cmpb $0,%0\n" - " je 1b\n" - " dec %2\n" - " jnz 2b\n" - "3:\n" - : "+m" (xl->lock), "=q" (oldval), "+r" (timeout) - : "1" (1) - : "memory"); - - spin_time_accum_spinning(start_spin_fast); - - } while (unlikely(oldval != 0 && - (TIMEOUT == ~0 || !xen_spin_lock_slow(lock, irq_enable)))); - - spin_time_accum_total(start_spin); -} - -static void xen_spin_lock(struct arch_spinlock *lock) -{ - __xen_spin_lock(lock, false); -} - -static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags) -{ - __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags)); -} - -static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl) +static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { int cpu; - ADD_STATS(released_slow, 1); + add_stats(RELEASED_SLOW, 1); + + for_each_cpu(cpu, &waiting_cpus) { + const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - for_each_online_cpu(cpu) { - /* XXX should mix up next cpu selection */ - if (per_cpu(lock_spinners, cpu) == xl) { - ADD_STATS(released_slow_kicked, 1); + if (w->lock == lock && w->want == next) { + add_stats(RELEASED_SLOW_KICKED, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; } } } -static void xen_spin_unlock(struct arch_spinlock *lock) -{ - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - - ADD_STATS(released, 1); - - smp_wmb(); /* make sure no writes get moved after unlock */ - xl->lock = 0; /* release lock */ - - /* - * Make sure unlock happens before checking for waiting - * spinners. We need a strong barrier to enforce the - * write-read ordering to different memory locations, as the - * CPU makes no implied guarantees about their ordering. - */ - mb(); - - if (unlikely(xl->spinners)) - xen_spin_unlock_slow(xl); -} -#endif - static irqreturn_t dummy_handler(int irq, void *dev_id) { BUG(); @@ -391,15 +223,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)); -#if 0 - 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; - pv_lock_ops.spin_lock_flags = xen_spin_lock_flags; - pv_lock_ops.spin_trylock = xen_spin_trylock; - pv_lock_ops.spin_unlock = xen_spin_unlock; -#endif + pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.unlock_kick = xen_unlock_kick; } #ifdef CONFIG_XEN_DEBUG_FS @@ -417,42 +242,25 @@ static int __init xen_spinlock_debugfs(void) debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats); - debugfs_create_u32("timeout", 0644, d_spin_debug, &lock_timeout); - - debugfs_create_u64("taken", 0444, d_spin_debug, &spinlock_stats.taken); debugfs_create_u32("taken_slow", 0444, d_spin_debug, - &spinlock_stats.taken_slow); - debugfs_create_u32("taken_slow_nested", 0444, d_spin_debug, - &spinlock_stats.taken_slow_nested); + &spinlock_stats.contention_stats[TAKEN_SLOW]); debugfs_create_u32("taken_slow_pickup", 0444, d_spin_debug, - &spinlock_stats.taken_slow_pickup); + &spinlock_stats.contention_stats[TAKEN_SLOW_PICKUP]); debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug, - &spinlock_stats.taken_slow_spurious); - debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug, - &spinlock_stats.taken_slow_irqenable); + &spinlock_stats.contention_stats[TAKEN_SLOW_SPURIOUS]); - debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.released); debugfs_create_u32("released_slow", 0444, d_spin_debug, - &spinlock_stats.released_slow); + &spinlock_stats.contention_stats[RELEASED_SLOW]); debugfs_create_u32("released_slow_kicked", 0444, d_spin_debug, - &spinlock_stats.released_slow_kicked); + &spinlock_stats.contention_stats[RELEASED_SLOW_KICKED]); - debugfs_create_u64("time_spinning", 0444, d_spin_debug, - &spinlock_stats.time_spinning); debugfs_create_u64("time_blocked", 0444, d_spin_debug, &spinlock_stats.time_blocked); - debugfs_create_u64("time_total", 0444, d_spin_debug, - &spinlock_stats.time_total); - debugfs_create_u32_array("histo_total", 0444, d_spin_debug, - spinlock_stats.histo_spin_total, HISTO_BUCKETS + 1); - debugfs_create_u32_array("histo_spinning", 0444, d_spin_debug, - spinlock_stats.histo_spin_spinning, HISTO_BUCKETS + 1); debugfs_create_u32_array("histo_blocked", 0444, d_spin_debug, spinlock_stats.histo_spin_blocked, HISTO_BUCKETS + 1); return 0; } fs_initcall(xen_spinlock_debugfs); - #endif /* CONFIG_XEN_DEBUG_FS */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004ke-2F; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSh-0004Qu-0W for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:07 +0000 Received: from [85.158.143.99:51288] by server-2.bemta-4.messagelabs.com id 37/CF-17550-A4701AF4; Wed, 02 May 2012 10:07:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1335953221!20850473!1 X-Originating-IP: [202.81.31.143] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNzEwNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6822 invoked from network); 2 May 2012 10:07:04 -0000 Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:04 -0000 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:58:57 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:58:28 +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 q429xboM1994854 for ; Wed, 2 May 2012 19:59:39 +1000 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 q42A6Ojb018483 for ; Wed, 2 May 2012 20:06:28 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A6J5Q018333; Wed, 2 May 2012 20:06:20 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:36:10 +0530 Message-Id: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-1618-0000-0000-00000172F7C4 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM.(targeted for 3.5 window) Note: This needs debugfs changes patch that should be in Xen / linux-next https://lkml.org/lkml/2012/3/30/687 Changes in V8: - Reabsed patches to 3.4-rc4 - Combined the KVM changes with ticketlock + Xen changes (Ingo) - Removed CAP_PV_UNHALT since it is redundant (Avi). But note that we need newer qemu which uses KVM_GET_SUPPORTED_CPUID ioctl. - Rewrite GET_MP_STATE condition (Avi) - Make pv_unhalt = bool (Avi) - Move out reset pv_unhalt code to vcpu_run from vcpu_block (Gleb) - Documentation changes (Rob Landley) - Have a printk to recognize that paravirt spinlock is enabled (Nikunj) - Move out kick hypercall out of CONFIG_PARAVIRT_SPINLOCK now so that it can be used for other optimizations such as flush_tlb_ipi_others etc. (Nikunj) Ticket locks have an inherent problem in a virtualized case, because the vCPUs are scheduled rather than running concurrently (ignoring gang scheduled vCPUs). This can result in catastrophic performance collapses when the vCPU scheduler doesn't schedule the correct "next" vCPU, and ends up scheduling a vCPU which burns its entire timeslice spinning. (Note that this is not the same problem as lock-holder preemption, which this series also addresses; that's also a problem, but not catastrophic). (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spinning. This pvop can set the lock into "slowpath state". - When releasing a lock, if it is in "slowpath state", the call __ticket_unlock_kick() to kick the next vCPU in line awake. If the lock is no longer in contention, it also clears the slowpath flag. The "slowpath state" is stored in the LSB of the within the lock tail ticket. This has the effect of reducing the max number of CPUs by half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" 32768). For KVM, one hypercall is introduced in 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. Overall, it results in a large reduction in code, it makes the native and virtualized cases closer, and it removes a layer of indirection around all the spinlock functions. The fast path (taking an uncontended lock which isn't in "slowpath" state) is optimal, identical to the non-paravirtualized case. The inner part of ticket lock code becomes: inc = xadd(&lock->tickets, inc); inc.tail &= ~TICKET_SLOWPATH_FLAG; if (likely(inc.head == inc.tail)) goto out; for (;;) { unsigned count = SPIN_THRESHOLD; do { if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); } while (--count); __ticket_lock_spinning(lock, inc.tail); } out: barrier(); which results in: push %rbp mov %rsp,%rbp mov $0x200,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f # Slowpath if lock in contention pop %rbp retq ### SLOWPATH START 1: and $-2,%edx movzbl %dl,%esi 2: mov $0x800,%eax jmp 4f 3: pause sub $0x1,%eax je 5f 4: movzbl (%rdi),%ecx cmp %cl,%dl jne 3b pop %rbp retq 5: callq *__ticket_lock_spinning jmp 2b ### SLOWPATH END with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where the fastpath case is straight through (taking the lock without contention), and the spin loop is out of line: push %rbp mov %rsp,%rbp mov $0x100,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: pause movzbl (%rdi),%eax cmp %dl,%al jne 1b pop %rbp retq ### SLOWPATH END The unlock code is complicated by the need to both add to the lock's "head" and fetch the slowpath flag from "tail". This version of the patch uses a locked add to do this, followed by a test to see if the slowflag is set. The lock prefix acts as a full memory barrier, so we can be sure that other CPUs will have seen the unlock before we read the flag (without the barrier the read could be fetched from the store queue before it hits memory, which could result in a deadlock). This is is all unnecessary complication if you're not using PV ticket locks, it also uses the jump-label machinery to use the standard "add"-based unlock in the non-PV case. if (TICKET_SLOWPATH_FLAG && static_key_false(¶virt_ticketlocks_enabled))) { arch_spinlock_t prev; prev = *lock; add_smp(&lock->tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); } else __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); which generates: push %rbp mov %rsp,%rbp nop5 # replaced by 5-byte jmp 2f when PV enabled # non-PV unlock addb $0x2,(%rdi) 1: pop %rbp retq ### PV unlock ### 2: movzwl (%rdi),%esi # Fetch prev lock addb $0x2,(%rdi) # Do unlock testb $0x1,0x1(%rdi) # Test flag je 1b # Finished if not set ### Slow path ### add $2,%sil # Add "head" in old lock state mov %esi,%edx and $0xfe,%dh # clear slowflag for comparison movzbl %dh,%eax cmp %dl,%al # If head == tail (uncontended) je 4f # clear slowpath flag # Kick next CPU waiting for lock 3: movzbl %sil,%esi callq *pv_lock_ops.kick pop %rbp retq # Lock no longer contended - clear slowflag 4: mov %esi,%eax lock cmpxchg %dx,(%rdi) # cmpxchg to clear flag cmp %si,%ax jne 3b # If clear failed, then kick pop %rbp retq So when not using PV ticketlocks, the unlock sequence just has a 5-byte nop added to it, and the PV case is reasonable straightforward aside from requiring a "lock add". TODO: 1) Remove CONFIG_PARAVIRT_SPINLOCK ? 2) Experiments on further optimization possibilities. (discussed in V6) 3) Use kvm_irq_delivery_to_apic() in kvm hypercall (suggested by Gleb) 4) Any cleanups for e.g. Xen/KVM common code for debugfs. PS: TODOs are no blockers for the current series merge. Results: ======= various form of results based on V6 of the patch series are posted in following links https://lkml.org/lkml/2012/3/21/161 https://lkml.org/lkml/2012/3/21/198 kvm results: https://lkml.org/lkml/2012/3/23/50 https://lkml.org/lkml/2012/4/5/73 Benchmarking on the current set of patches will be posted soon. Thoughts? Comments? Suggestions?. It would be nice to see Acked-by/Reviewed-by/Tested-by for the patch series. Jeremy Fitzhardinge (9): x86/spinlock: Replace pv spinlocks with pv ticketlocks x86/ticketlock: Collapse a layer of functions xen: Defer spinlock setup until boot CPU setup xen/pvticketlock: Xen implementation for PV ticket locks xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks x86/pvticketlock: Use callee-save for lock_spinning x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 x86/ticketlock: Add slowpath logic xen/pvticketlock: Allow interrupts to be enabled while blocking Srivatsa Vaddagiri (3): Add a hypercall to KVM hypervisor to support pv-ticketlocks Added configuration support to enable debug information for KVM Guests Paravirtual ticketlock support for linux guests running on KVM hypervisor Raghavendra K T (3): x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration Add documentation on Hypercalls and features used for PV spinlock Andrew Jones (1): Split out rate limiting from jump_label.h Stefano Stabellini (1): xen: Enable PV ticketlocks on HVM Xen --- PS: Had to trim down recipient list because, LKML archive does not support list > 20. Though many more people should have been in To/CC list. Ticketlock links: V7 : https://lkml.org/lkml/2012/4/19/335 V6 : https://lkml.org/lkml/2012/3/21/161 KVM patch links: V6: https://lkml.org/lkml/2012/4/23/123 V5 kernel changes: https://lkml.org/lkml/2012/3/23/50 Qemu changes for V5: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04455.html V4 kernel changes: https://lkml.org/lkml/2012/1/14/66 Qemu changes for V4: http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html V3 kernel Changes: https://lkml.org/lkml/2011/11/30/62 Qemu patch for V3: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html 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 Ticketlock change history: Changes in V7: - Reabsed patches to 3.4-rc3 - Added jumplabel split patch (originally from Andrew Jones rebased to 3.4-rc3 - jumplabel changes from Ingo and Jason taken and now using static_key_* instead of static_branch. - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus) - This patch series is rebased on debugfs patch (that sould be already in Xen/linux-next https://lkml.org/lkml/2012/3/23/51) Changes in V6 posting: (Raghavendra K T) - Rebased to linux-3.3-rc6. - used function+enum in place of macro (better type checking) - use cmpxchg while resetting zero status for possible race [suggested by Dave Hansen for KVM patches ] KVM patch Change history: Changes in V6: - Rebased to 3.4-rc3 - Removed debugfs changes patch which should now be in Xen/linux-next. (https://lkml.org/lkml/2012/3/30/687) - Removed PV_UNHALT_MSR since currently we don't need guest communication, and made pv_unhalt folded to GET_MP_STATE (Marcello, Avi[long back]) - Take jumplabel changes from Ingo/Jason into use (static_key_slow_inc usage) - Added inline to spinlock_init in non PARAVIRT case - Move arch specific code to arch/x86 and add stubs to other archs (Marcello) - Added more comments on pv_unhalt usage etc (Marcello) Changes in V5: - rebased to 3.3-rc6 - added PV_UNHALT_MSR that would help in live migration (Avi) - removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added. - Changed hypercall documentaion (Alex). - mode_t changed to umode_t in debugfs. - MSR related documentation added. - rename PV_LOCK_KICK to PV_UNHALT. - host and guest patches not mixed. (Marcelo, Alex) - kvm_kick_cpu now takes cpu so it can be used by flush_tlb_ipi_other paravirtualization (Nikunj) - coding style changes in variable declarion etc (Srikar) 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 ) pointed by Stephan Diestelhorst - enabling 32 bit guests - splitted patches into two more chunks Documentation/virtual/kvm/cpuid.txt | 4 + Documentation/virtual/kvm/hypercalls.txt | 60 +++++ arch/x86/Kconfig | 10 + arch/x86/include/asm/kvm_host.h | 4 + arch/x86/include/asm/kvm_para.h | 16 +- arch/x86/include/asm/paravirt.h | 32 +-- arch/x86/include/asm/paravirt_types.h | 10 +- arch/x86/include/asm/spinlock.h | 128 +++++++---- arch/x86/include/asm/spinlock_types.h | 16 +- arch/x86/kernel/kvm.c | 256 ++++++++++++++++++++ arch/x86/kernel/paravirt-spinlocks.c | 18 +- arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 44 ++++- arch/x86/xen/smp.c | 3 +- arch/x86/xen/spinlock.c | 387 ++++++++++-------------------- include/linux/jump_label.h | 26 +-- include/linux/jump_label_ratelimit.h | 34 +++ include/linux/kvm_para.h | 1 + include/linux/perf_event.h | 1 + kernel/jump_label.c | 1 + 20 files changed, 673 insertions(+), 381 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVU-0004kE-93; Fri, 04 May 2012 09:08:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClb-0006vW-Iz for xen-devel@lists.xensource.com; Tue, 01 May 2012 13:05:19 +0000 Received: from [85.158.139.83:22331] by server-4.bemta-5.messagelabs.com id 13/A8-10788-E8FDF9F4; Tue, 01 May 2012 13:05:18 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1335877514!25570809!1 X-Originating-IP: [202.81.31.145] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyNDg0MzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21637 invoked from network); 1 May 2012 13:05:17 -0000 Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 13:05:17 -0000 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2012 12:55:37 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2012 12:55:32 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q41Cw66u2093126 for ; Tue, 1 May 2012 22:58:08 +1000 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 q41D4u2Q005512 for ; Tue, 1 May 2012 23:04:58 +1000 Received: from [9.79.194.34] ([9.79.194.34]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q41D4nGN005420; Tue, 1 May 2012 23:04:50 +1000 Message-ID: <4F9FDF69.8090101@linux.vnet.ibm.com> Date: Tue, 01 May 2012 18:34:41 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ian Campbell References: <20120419201209.5411.43877.sendpatchset@codeblue> <1335876646.6038.101.camel@zakaz.uk.xensource.com> In-Reply-To: <1335876646.6038.101.camel@zakaz.uk.xensource.com> x-cbid: 12050102-6102-0000-0000-0000015A3BFF X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Andrew Jones , Xen Devel , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , LKML , Srivatsa Vaddagiri , Marcelo Tosatti , Andi Kleen , Stephan Diestelhorst , Jeremy Fitzhardinge , "H. Peter Anvin" , Attilio Rao , Ingo Molnar , Virtualization , Linus Torvalds , Konrad Rzeszutek Wilk , Avi Kivity Subject: Re: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 06:20 PM, Ian Campbell wrote: > On Thu, 2012-04-19 at 21:12 +0100, Raghavendra K T wrote: >> From: Jeremy Fitzhardinge >> >> This series replaces the existing paravirtualized spinlock mechanism >> with a paravirtualized ticketlock mechanism. (targeted for 3.5 window) > > Which tree is this series going through, tip.git I guess? > > I don't see it there. > > Ian. > Yes you are right. I am trying to post ticketlock + xen + kvm patches series in one go. There are some discussions on kvm patches last few days. So I am putting up all of them together now. I am planning to post within half/one day. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVX-0004m0-2c; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTb-0004T4-2J for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:03 +0000 Received: from [85.158.138.51:48896] by server-4.bemta-3.messagelabs.com id 84/CA-15341-28701AF4; Wed, 02 May 2012 10:08:02 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1335953268!20717950!1 X-Originating-IP: [122.248.162.3] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxODk1OTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14407 invoked from network); 2 May 2012 10:08:00 -0000 Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:00 -0000 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:37:46 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:44 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A7hdZ28639338 for ; Wed, 2 May 2012 15:37:43 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FavL1000576 for ; Thu, 3 May 2012 01:36:59 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FauMB000537; Thu, 3 May 2012 01:36:56 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:32 +0530 Message-Id: <20120502100732.13206.30121.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-3864-0000-0000-00000285335A X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 6/17] xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 4e98a07..c4886dc 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -221,12 +221,26 @@ void xen_uninit_lock_cpu(int cpu) unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL); } +static bool xen_pvspin __initdata = true; + void __init xen_init_spinlocks(void) { + if (!xen_pvspin) { + printk(KERN_DEBUG "xen: PV spinlocks disabled\n"); + return; + } + pv_lock_ops.lock_spinning = xen_lock_spinning; pv_lock_ops.unlock_kick = xen_unlock_kick; } +static __init int xen_parse_nopvspin(char *arg) +{ + xen_pvspin = false; + return 0; +} +early_param("xen_nopvspin", xen_parse_nopvspin); + #ifdef CONFIG_XEN_DEBUG_FS static struct dentry *d_spin_debug; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004no-Ri; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUL-0004Um-FF for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:49 +0000 Received: from [85.158.143.99:28650] by server-3.bemta-4.messagelabs.com id 43/E7-05853-0B701AF4; Wed, 02 May 2012 10:08:48 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1335953324!16494300!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 2 May 2012 10:08:47 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:47 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:44 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:43 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A8gp829556792 for ; Wed, 2 May 2012 15:38:42 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FcSCs014997 for ; Thu, 3 May 2012 01:38:30 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcR6k014974; Thu, 3 May 2012 01:38:27 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:30 +0530 Message-Id: <20120502100830.13206.31058.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-000002725812 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 11/17] xen/pvticketlock: Allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge If interrupts were enabled when taking the spinlock, we can leave them enabled while blocking to get the lock. If we can enable interrupts while waiting for the lock to become available, and we take an interrupt before entering the poll, and the handler takes a spinlock which ends up going into the slow state (invalidating the per-cpu "lock" and "want" values), then when the interrupt handler returns the event channel will remain pending so the poll will return immediately, causing it to return out to the main spinlock loop. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 46 ++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 40 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index d4abaf9..3bf93d5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -140,7 +140,20 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) * partially setup state. */ local_irq_save(flags); - + /* + * We don't really care if we're overwriting some other + * (lock,want) pair, as that would mean that we're currently + * in an interrupt context, and the outer context had + * interrupts enabled. That has already kicked the VCPU out + * of xen_poll_irq(), so it will just return spuriously and + * retry with newly setup (lock,want). + * + * 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; @@ -155,24 +168,43 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); - /* Mark entry to slowpath before doing the pickup test to make - sure we don't deadlock with an unlocker. */ + /* + * 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 */ + /* + * 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); + + /* + * If an interrupt happens here, it will leave the wakeup irq + * pending, which will cause xen_poll_irq() to return + * immediately. + */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ xen_poll_irq(irq); add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq)); + + local_irq_save(flags); + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: cpumask_clear_cpu(cpu, &waiting_cpus); w->lock = NULL; + local_irq_restore(flags); + spin_time_accum_blocked(start); } PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); @@ -186,7 +218,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) for_each_cpu(cpu, &waiting_cpus) { const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - if (w->lock == lock && w->want == next) { + /* Make sure we read lock before want */ + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == next) { add_stats(RELEASED_SLOW_KICKED, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004ke-2F; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSh-0004Qu-0W for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:07 +0000 Received: from [85.158.143.99:51288] by server-2.bemta-4.messagelabs.com id 37/CF-17550-A4701AF4; Wed, 02 May 2012 10:07:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1335953221!20850473!1 X-Originating-IP: [202.81.31.143] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyNzEwNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6822 invoked from network); 2 May 2012 10:07:04 -0000 Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:04 -0000 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:58:57 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:58:28 +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 q429xboM1994854 for ; Wed, 2 May 2012 19:59:39 +1000 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 q42A6Ojb018483 for ; Wed, 2 May 2012 20:06:28 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A6J5Q018333; Wed, 2 May 2012 20:06:20 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:36:10 +0530 Message-Id: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-1618-0000-0000-00000172F7C4 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM.(targeted for 3.5 window) Note: This needs debugfs changes patch that should be in Xen / linux-next https://lkml.org/lkml/2012/3/30/687 Changes in V8: - Reabsed patches to 3.4-rc4 - Combined the KVM changes with ticketlock + Xen changes (Ingo) - Removed CAP_PV_UNHALT since it is redundant (Avi). But note that we need newer qemu which uses KVM_GET_SUPPORTED_CPUID ioctl. - Rewrite GET_MP_STATE condition (Avi) - Make pv_unhalt = bool (Avi) - Move out reset pv_unhalt code to vcpu_run from vcpu_block (Gleb) - Documentation changes (Rob Landley) - Have a printk to recognize that paravirt spinlock is enabled (Nikunj) - Move out kick hypercall out of CONFIG_PARAVIRT_SPINLOCK now so that it can be used for other optimizations such as flush_tlb_ipi_others etc. (Nikunj) Ticket locks have an inherent problem in a virtualized case, because the vCPUs are scheduled rather than running concurrently (ignoring gang scheduled vCPUs). This can result in catastrophic performance collapses when the vCPU scheduler doesn't schedule the correct "next" vCPU, and ends up scheduling a vCPU which burns its entire timeslice spinning. (Note that this is not the same problem as lock-holder preemption, which this series also addresses; that's also a problem, but not catastrophic). (See Thomas Friebel's talk "Prevent Guests from Spinning Around" http://www.xen.org/files/xensummitboston08/LHP.pdf for more details.) Currently we deal with this by having PV spinlocks, which adds a layer of indirection in front of all the spinlock functions, and defining a completely new implementation for Xen (and for other pvops users, but there are none at present). PV ticketlocks keeps the existing ticketlock implemenentation (fastpath) as-is, but adds a couple of pvops for the slow paths: - If a CPU has been waiting for a spinlock for SPIN_THRESHOLD iterations, then call out to the __ticket_lock_spinning() pvop, which allows a backend to block the vCPU rather than spinning. This pvop can set the lock into "slowpath state". - When releasing a lock, if it is in "slowpath state", the call __ticket_unlock_kick() to kick the next vCPU in line awake. If the lock is no longer in contention, it also clears the slowpath flag. The "slowpath state" is stored in the LSB of the within the lock tail ticket. This has the effect of reducing the max number of CPUs by half (so, a "small ticket" can deal with 128 CPUs, and "large ticket" 32768). For KVM, one hypercall is introduced in 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. Overall, it results in a large reduction in code, it makes the native and virtualized cases closer, and it removes a layer of indirection around all the spinlock functions. The fast path (taking an uncontended lock which isn't in "slowpath" state) is optimal, identical to the non-paravirtualized case. The inner part of ticket lock code becomes: inc = xadd(&lock->tickets, inc); inc.tail &= ~TICKET_SLOWPATH_FLAG; if (likely(inc.head == inc.tail)) goto out; for (;;) { unsigned count = SPIN_THRESHOLD; do { if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); } while (--count); __ticket_lock_spinning(lock, inc.tail); } out: barrier(); which results in: push %rbp mov %rsp,%rbp mov $0x200,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f # Slowpath if lock in contention pop %rbp retq ### SLOWPATH START 1: and $-2,%edx movzbl %dl,%esi 2: mov $0x800,%eax jmp 4f 3: pause sub $0x1,%eax je 5f 4: movzbl (%rdi),%ecx cmp %cl,%dl jne 3b pop %rbp retq 5: callq *__ticket_lock_spinning jmp 2b ### SLOWPATH END with CONFIG_PARAVIRT_SPINLOCKS=n, the code has changed slightly, where the fastpath case is straight through (taking the lock without contention), and the spin loop is out of line: push %rbp mov %rsp,%rbp mov $0x100,%eax lock xadd %ax,(%rdi) movzbl %ah,%edx cmp %al,%dl jne 1f pop %rbp retq ### SLOWPATH START 1: pause movzbl (%rdi),%eax cmp %dl,%al jne 1b pop %rbp retq ### SLOWPATH END The unlock code is complicated by the need to both add to the lock's "head" and fetch the slowpath flag from "tail". This version of the patch uses a locked add to do this, followed by a test to see if the slowflag is set. The lock prefix acts as a full memory barrier, so we can be sure that other CPUs will have seen the unlock before we read the flag (without the barrier the read could be fetched from the store queue before it hits memory, which could result in a deadlock). This is is all unnecessary complication if you're not using PV ticket locks, it also uses the jump-label machinery to use the standard "add"-based unlock in the non-PV case. if (TICKET_SLOWPATH_FLAG && static_key_false(¶virt_ticketlocks_enabled))) { arch_spinlock_t prev; prev = *lock; add_smp(&lock->tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); } else __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); which generates: push %rbp mov %rsp,%rbp nop5 # replaced by 5-byte jmp 2f when PV enabled # non-PV unlock addb $0x2,(%rdi) 1: pop %rbp retq ### PV unlock ### 2: movzwl (%rdi),%esi # Fetch prev lock addb $0x2,(%rdi) # Do unlock testb $0x1,0x1(%rdi) # Test flag je 1b # Finished if not set ### Slow path ### add $2,%sil # Add "head" in old lock state mov %esi,%edx and $0xfe,%dh # clear slowflag for comparison movzbl %dh,%eax cmp %dl,%al # If head == tail (uncontended) je 4f # clear slowpath flag # Kick next CPU waiting for lock 3: movzbl %sil,%esi callq *pv_lock_ops.kick pop %rbp retq # Lock no longer contended - clear slowflag 4: mov %esi,%eax lock cmpxchg %dx,(%rdi) # cmpxchg to clear flag cmp %si,%ax jne 3b # If clear failed, then kick pop %rbp retq So when not using PV ticketlocks, the unlock sequence just has a 5-byte nop added to it, and the PV case is reasonable straightforward aside from requiring a "lock add". TODO: 1) Remove CONFIG_PARAVIRT_SPINLOCK ? 2) Experiments on further optimization possibilities. (discussed in V6) 3) Use kvm_irq_delivery_to_apic() in kvm hypercall (suggested by Gleb) 4) Any cleanups for e.g. Xen/KVM common code for debugfs. PS: TODOs are no blockers for the current series merge. Results: ======= various form of results based on V6 of the patch series are posted in following links https://lkml.org/lkml/2012/3/21/161 https://lkml.org/lkml/2012/3/21/198 kvm results: https://lkml.org/lkml/2012/3/23/50 https://lkml.org/lkml/2012/4/5/73 Benchmarking on the current set of patches will be posted soon. Thoughts? Comments? Suggestions?. It would be nice to see Acked-by/Reviewed-by/Tested-by for the patch series. Jeremy Fitzhardinge (9): x86/spinlock: Replace pv spinlocks with pv ticketlocks x86/ticketlock: Collapse a layer of functions xen: Defer spinlock setup until boot CPU setup xen/pvticketlock: Xen implementation for PV ticket locks xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks x86/pvticketlock: Use callee-save for lock_spinning x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 x86/ticketlock: Add slowpath logic xen/pvticketlock: Allow interrupts to be enabled while blocking Srivatsa Vaddagiri (3): Add a hypercall to KVM hypervisor to support pv-ticketlocks Added configuration support to enable debug information for KVM Guests Paravirtual ticketlock support for linux guests running on KVM hypervisor Raghavendra K T (3): x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration Add documentation on Hypercalls and features used for PV spinlock Andrew Jones (1): Split out rate limiting from jump_label.h Stefano Stabellini (1): xen: Enable PV ticketlocks on HVM Xen --- PS: Had to trim down recipient list because, LKML archive does not support list > 20. Though many more people should have been in To/CC list. Ticketlock links: V7 : https://lkml.org/lkml/2012/4/19/335 V6 : https://lkml.org/lkml/2012/3/21/161 KVM patch links: V6: https://lkml.org/lkml/2012/4/23/123 V5 kernel changes: https://lkml.org/lkml/2012/3/23/50 Qemu changes for V5: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04455.html V4 kernel changes: https://lkml.org/lkml/2012/1/14/66 Qemu changes for V4: http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html V3 kernel Changes: https://lkml.org/lkml/2011/11/30/62 Qemu patch for V3: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html 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 Ticketlock change history: Changes in V7: - Reabsed patches to 3.4-rc3 - Added jumplabel split patch (originally from Andrew Jones rebased to 3.4-rc3 - jumplabel changes from Ingo and Jason taken and now using static_key_* instead of static_branch. - using UNINLINE_SPIN_UNLOCK (which was splitted as per suggestion from Linus) - This patch series is rebased on debugfs patch (that sould be already in Xen/linux-next https://lkml.org/lkml/2012/3/23/51) Changes in V6 posting: (Raghavendra K T) - Rebased to linux-3.3-rc6. - used function+enum in place of macro (better type checking) - use cmpxchg while resetting zero status for possible race [suggested by Dave Hansen for KVM patches ] KVM patch Change history: Changes in V6: - Rebased to 3.4-rc3 - Removed debugfs changes patch which should now be in Xen/linux-next. (https://lkml.org/lkml/2012/3/30/687) - Removed PV_UNHALT_MSR since currently we don't need guest communication, and made pv_unhalt folded to GET_MP_STATE (Marcello, Avi[long back]) - Take jumplabel changes from Ingo/Jason into use (static_key_slow_inc usage) - Added inline to spinlock_init in non PARAVIRT case - Move arch specific code to arch/x86 and add stubs to other archs (Marcello) - Added more comments on pv_unhalt usage etc (Marcello) Changes in V5: - rebased to 3.3-rc6 - added PV_UNHALT_MSR that would help in live migration (Avi) - removed PV_LOCK_KICK vcpu request and pv_unhalt flag (re)added. - Changed hypercall documentaion (Alex). - mode_t changed to umode_t in debugfs. - MSR related documentation added. - rename PV_LOCK_KICK to PV_UNHALT. - host and guest patches not mixed. (Marcelo, Alex) - kvm_kick_cpu now takes cpu so it can be used by flush_tlb_ipi_other paravirtualization (Nikunj) - coding style changes in variable declarion etc (Srikar) 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 ) pointed by Stephan Diestelhorst - enabling 32 bit guests - splitted patches into two more chunks Documentation/virtual/kvm/cpuid.txt | 4 + Documentation/virtual/kvm/hypercalls.txt | 60 +++++ arch/x86/Kconfig | 10 + arch/x86/include/asm/kvm_host.h | 4 + arch/x86/include/asm/kvm_para.h | 16 +- arch/x86/include/asm/paravirt.h | 32 +-- arch/x86/include/asm/paravirt_types.h | 10 +- arch/x86/include/asm/spinlock.h | 128 +++++++---- arch/x86/include/asm/spinlock_types.h | 16 +- arch/x86/kernel/kvm.c | 256 ++++++++++++++++++++ arch/x86/kernel/paravirt-spinlocks.c | 18 +- arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 44 ++++- arch/x86/xen/smp.c | 3 +- arch/x86/xen/spinlock.c | 387 ++++++++++-------------------- include/linux/jump_label.h | 26 +-- include/linux/jump_label_ratelimit.h | 34 +++ include/linux/kvm_para.h | 1 + include/linux/perf_event.h | 1 + kernel/jump_label.c | 1 + 20 files changed, 673 insertions(+), 381 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVU-0004kE-93; Fri, 04 May 2012 09:08:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPClb-0006vW-Iz for xen-devel@lists.xensource.com; Tue, 01 May 2012 13:05:19 +0000 Received: from [85.158.139.83:22331] by server-4.bemta-5.messagelabs.com id 13/A8-10788-E8FDF9F4; Tue, 01 May 2012 13:05:18 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1335877514!25570809!1 X-Originating-IP: [202.81.31.145] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyNDg0MzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21637 invoked from network); 1 May 2012 13:05:17 -0000 Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2012 13:05:17 -0000 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2012 12:55:37 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2012 12:55:32 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q41Cw66u2093126 for ; Tue, 1 May 2012 22:58:08 +1000 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 q41D4u2Q005512 for ; Tue, 1 May 2012 23:04:58 +1000 Received: from [9.79.194.34] ([9.79.194.34]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q41D4nGN005420; Tue, 1 May 2012 23:04:50 +1000 Message-ID: <4F9FDF69.8090101@linux.vnet.ibm.com> Date: Tue, 01 May 2012 18:34:41 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ian Campbell References: <20120419201209.5411.43877.sendpatchset@codeblue> <1335876646.6038.101.camel@zakaz.uk.xensource.com> In-Reply-To: <1335876646.6038.101.camel@zakaz.uk.xensource.com> x-cbid: 12050102-6102-0000-0000-0000015A3BFF X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Andrew Jones , Xen Devel , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , LKML , Srivatsa Vaddagiri , Marcelo Tosatti , Andi Kleen , Stephan Diestelhorst , Jeremy Fitzhardinge , "H. Peter Anvin" , Attilio Rao , Ingo Molnar , Virtualization , Linus Torvalds , Konrad Rzeszutek Wilk , Avi Kivity Subject: Re: [Xen-devel] [PATCH RFC V7 0/12] Paravirtualized ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/01/2012 06:20 PM, Ian Campbell wrote: > On Thu, 2012-04-19 at 21:12 +0100, Raghavendra K T wrote: >> From: Jeremy Fitzhardinge >> >> This series replaces the existing paravirtualized spinlock mechanism >> with a paravirtualized ticketlock mechanism. (targeted for 3.5 window) > > Which tree is this series going through, tip.git I guess? > > I don't see it there. > > Ian. > Yes you are right. I am trying to post ticketlock + xen + kvm patches series in one go. There are some discussions on kvm patches last few days. So I am putting up all of them together now. I am planning to post within half/one day. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVX-0004m0-2c; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTb-0004T4-2J for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:03 +0000 Received: from [85.158.138.51:48896] by server-4.bemta-3.messagelabs.com id 84/CA-15341-28701AF4; Wed, 02 May 2012 10:08:02 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1335953268!20717950!1 X-Originating-IP: [122.248.162.3] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMyA9PiAxODk1OTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14407 invoked from network); 2 May 2012 10:08:00 -0000 Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:00 -0000 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:37:46 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:44 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A7hdZ28639338 for ; Wed, 2 May 2012 15:37:43 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FavL1000576 for ; Thu, 3 May 2012 01:36:59 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FauMB000537; Thu, 3 May 2012 01:36:56 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:32 +0530 Message-Id: <20120502100732.13206.30121.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-3864-0000-0000-00000285335A X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 6/17] xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 4e98a07..c4886dc 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -221,12 +221,26 @@ void xen_uninit_lock_cpu(int cpu) unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL); } +static bool xen_pvspin __initdata = true; + void __init xen_init_spinlocks(void) { + if (!xen_pvspin) { + printk(KERN_DEBUG "xen: PV spinlocks disabled\n"); + return; + } + pv_lock_ops.lock_spinning = xen_lock_spinning; pv_lock_ops.unlock_kick = xen_unlock_kick; } +static __init int xen_parse_nopvspin(char *arg) +{ + xen_pvspin = false; + return 0; +} +early_param("xen_nopvspin", xen_parse_nopvspin); + #ifdef CONFIG_XEN_DEBUG_FS static struct dentry *d_spin_debug; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004nP-GA; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUF-0004UE-Rs for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:44 +0000 Received: from [85.158.138.51:57837] by server-7.bemta-3.messagelabs.com id D8/F7-03078-AA701AF4; Wed, 02 May 2012 10:08:42 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1335953318!22979837!1 X-Originating-IP: [202.81.31.140] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAzMTQxNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 758 invoked from network); 2 May 2012 10:08:41 -0000 Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:41 -0000 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:14 +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; Wed, 2 May 2012 10:01:12 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A1b0t1519806 for ; Wed, 2 May 2012 20:01:37 +1000 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 q42A8TI5013709 for ; Wed, 2 May 2012 20:08:30 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A8OCh013264; Wed, 2 May 2012 20:08:25 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:38:15 +0530 Message-Id: <20120502100815.13206.85635.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-0260-0000-0000-000000F8F6BD X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 10/17] x86/ticketlock: Add slowpath logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Maintain a flag in the LSB of the ticket lock tail which indicates whether anyone is in the lock slowpath and may need kicking when the current holder unlocks. The flags are set when the first locker enters the slowpath, and cleared when unlocking to an empty queue (ie, no contention). In the specific implementation of lock_spinning(), make sure to set the slowpath flags on the lock just before blocking. We must do this before the last-chance pickup test to prevent a deadlock with the unlocker: Unlocker Locker test for lock pickup -> fail unlock test slowpath -> false set slowpath flags block Whereas this works in any ordering: Unlocker Locker set slowpath flags test for lock pickup -> fail block unlock test slowpath -> true, kick If the unlocker finds that the lock has the slowpath flag set but it is actually uncontended (ie, head == tail, so nobody is waiting), then it clears the slowpath flag. The unlock code uses a locked add to update the head counter. This also acts as a full memory barrier so that its safe to subsequently read back the slowflag state, knowing that the updated lock is visible to the other CPUs. If it were an unlocked add, then the flag read may just be forwarded from the store buffer before it was visible to the other CPUs, which could result in a deadlock. Unfortunately this means we need to do a locked instruction when unlocking with PV ticketlocks. However, if PV ticketlocks are not enabled, then the old non-locked "add" is the only unlocking code. Note: this code relies on gcc making sure that unlikely() code is out of line of the fastpath, which only happens when OPTIMIZE_SIZE=n. If it doesn't the generated code isn't too bad, but its definitely suboptimal. Thanks to Srivatsa Vaddagiri for providing a bugfix to the original version of this change, which has been folded in. Thanks to Stephan Diestelhorst for commenting on some code which relied on an inaccurate reading of the x86 memory ordering rules. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Srivatsa Vaddagiri Reviewed-by: Konrad Rzeszutek Wilk Cc: Stephan Diestelhorst Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/spinlock.h | 86 +++++++++++++++++++++++--------- arch/x86/include/asm/spinlock_types.h | 2 + arch/x86/kernel/paravirt-spinlocks.c | 3 + arch/x86/xen/spinlock.c | 6 ++ 5 files changed, 74 insertions(+), 25 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 9769096..af49670 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -757,7 +757,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 60b7e83..e6881fd 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -1,11 +1,14 @@ #ifndef _ASM_X86_SPINLOCK_H #define _ASM_X86_SPINLOCK_H +#include #include #include #include #include #include +#include + /* * Your basic SMP spinlocks, allowing only a single CPU anywhere * @@ -40,32 +43,28 @@ /* How long a lock should spin before we consider blocking */ #define SPIN_THRESHOLD (1 << 11) -#ifndef CONFIG_PARAVIRT_SPINLOCKS +extern struct static_key paravirt_ticketlocks_enabled; +static __always_inline bool static_key_false(struct static_key *key); -static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, - __ticket_t ticket) +#ifdef CONFIG_PARAVIRT_SPINLOCKS + +static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) { + set_bit(0, (volatile unsigned long *)&lock->tickets.tail); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, - __ticket_t ticket) +#else /* !CONFIG_PARAVIRT_SPINLOCKS */ +static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock, + __ticket_t ticket) { } - -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - - -/* - * If a spinlock has someone waiting on it, then kick the appropriate - * waiting cpu. - */ -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, - __ticket_t next) +static inline void __ticket_unlock_kick(arch_spinlock_t *lock, + __ticket_t ticket) { - if (unlikely(lock->tickets.tail != next)) - ____ticket_unlock_kick(lock, next); } +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -79,20 +78,22 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(arch_spinlock_t *lock) { register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); + if (likely(inc.head == inc.tail)) + goto out; + inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; do { - if (inc.head == inc.tail) + if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); } while (--count); __ticket_lock_spinning(lock, inc.tail); } @@ -104,7 +105,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) arch_spinlock_t old, new; old.tickets = ACCESS_ONCE(lock->tickets); - if (old.tickets.head != old.tickets.tail) + if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG)) return 0; new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); @@ -113,12 +114,49 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; } +static inline void __ticket_unlock_slowpath(arch_spinlock_t *lock, + arch_spinlock_t old) +{ + arch_spinlock_t new; + + BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); + + /* Perform the unlock on the "before" copy */ + old.tickets.head += TICKET_LOCK_INC; + + /* Clear the slowpath flag */ + new.head_tail = old.head_tail & ~(TICKET_SLOWPATH_FLAG << TICKET_SHIFT); + + /* + * If the lock is uncontended, clear the flag - use cmpxchg in + * case it changes behind our back though. + */ + if (new.tickets.head != new.tickets.tail || + cmpxchg(&lock->head_tail, old.head_tail, + new.head_tail) != old.head_tail) { + /* + * Lock still has someone queued for it, so wake up an + * appropriate waiter. + */ + __ticket_unlock_kick(lock, old.tickets.head); + } +} + static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; + if (TICKET_SLOWPATH_FLAG && + static_key_false(¶virt_ticketlocks_enabled)) { + arch_spinlock_t prev; + + prev = *lock; + add_smp(&lock->tickets.head, TICKET_LOCK_INC); + + /* add_smp() is a full mb() */ - __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); - __ticket_unlock_kick(lock, next); + if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) + __ticket_unlock_slowpath(lock, prev); + } else + __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index e96fcbd..4f1bea1 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -5,8 +5,10 @@ #ifdef CONFIG_PARAVIRT_SPINLOCKS #define __TICKET_LOCK_INC 2 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else #define __TICKET_LOCK_INC 1 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 4251c1d..bbb6c73 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -4,6 +4,7 @@ */ #include #include +#include #include @@ -15,3 +16,5 @@ struct pv_lock_ops pv_lock_ops = { }; EXPORT_SYMBOL(pv_lock_ops); +struct static_key paravirt_ticketlocks_enabled = STATIC_KEY_INIT_FALSE; +EXPORT_SYMBOL(paravirt_ticketlocks_enabled); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c47a8d1..d4abaf9 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -155,6 +155,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ 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) { @@ -231,6 +235,8 @@ void __init xen_init_spinlocks(void) return; } + static_key_slow_inc(¶virt_ticketlocks_enabled); + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004no-Ri; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUL-0004Um-FF for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:49 +0000 Received: from [85.158.143.99:28650] by server-3.bemta-4.messagelabs.com id 43/E7-05853-0B701AF4; Wed, 02 May 2012 10:08:48 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1335953324!16494300!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 2 May 2012 10:08:47 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:47 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:44 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:43 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A8gp829556792 for ; Wed, 2 May 2012 15:38:42 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FcSCs014997 for ; Thu, 3 May 2012 01:38:30 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcR6k014974; Thu, 3 May 2012 01:38:27 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:30 +0530 Message-Id: <20120502100830.13206.31058.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-000002725812 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 11/17] xen/pvticketlock: Allow interrupts to be enabled while blocking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge If interrupts were enabled when taking the spinlock, we can leave them enabled while blocking to get the lock. If we can enable interrupts while waiting for the lock to become available, and we take an interrupt before entering the poll, and the handler takes a spinlock which ends up going into the slow state (invalidating the per-cpu "lock" and "want" values), then when the interrupt handler returns the event channel will remain pending so the poll will return immediately, causing it to return out to the main spinlock loop. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/spinlock.c | 46 ++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 40 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index d4abaf9..3bf93d5 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -140,7 +140,20 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) * partially setup state. */ local_irq_save(flags); - + /* + * We don't really care if we're overwriting some other + * (lock,want) pair, as that would mean that we're currently + * in an interrupt context, and the outer context had + * interrupts enabled. That has already kicked the VCPU out + * of xen_poll_irq(), so it will just return spuriously and + * retry with newly setup (lock,want). + * + * 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; @@ -155,24 +168,43 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ barrier(); - /* Mark entry to slowpath before doing the pickup test to make - sure we don't deadlock with an unlocker. */ + /* + * 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 */ + /* + * 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); + + /* + * If an interrupt happens here, it will leave the wakeup irq + * pending, which will cause xen_poll_irq() to return + * immediately. + */ + /* Block until irq becomes pending (or perhaps a spurious wakeup) */ xen_poll_irq(irq); add_stats(TAKEN_SLOW_SPURIOUS, !xen_test_irq_pending(irq)); + + local_irq_save(flags); + kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); out: cpumask_clear_cpu(cpu, &waiting_cpus); w->lock = NULL; + local_irq_restore(flags); + spin_time_accum_blocked(start); } PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); @@ -186,7 +218,9 @@ static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) for_each_cpu(cpu, &waiting_cpus) { const struct xen_lock_waiting *w = &per_cpu(lock_waiting, cpu); - if (w->lock == lock && w->want == next) { + /* Make sure we read lock before want */ + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == next) { add_stats(RELEASED_SLOW_KICKED, 1); xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004nP-GA; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUF-0004UE-Rs for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:44 +0000 Received: from [85.158.138.51:57837] by server-7.bemta-3.messagelabs.com id D8/F7-03078-AA701AF4; Wed, 02 May 2012 10:08:42 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1335953318!22979837!1 X-Originating-IP: [202.81.31.140] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAzMTQxNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 758 invoked from network); 2 May 2012 10:08:41 -0000 Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:41 -0000 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:14 +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; Wed, 2 May 2012 10:01:12 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A1b0t1519806 for ; Wed, 2 May 2012 20:01:37 +1000 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 q42A8TI5013709 for ; Wed, 2 May 2012 20:08:30 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A8OCh013264; Wed, 2 May 2012 20:08:25 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:38:15 +0530 Message-Id: <20120502100815.13206.85635.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-0260-0000-0000-000000F8F6BD X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 10/17] x86/ticketlock: Add slowpath logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Maintain a flag in the LSB of the ticket lock tail which indicates whether anyone is in the lock slowpath and may need kicking when the current holder unlocks. The flags are set when the first locker enters the slowpath, and cleared when unlocking to an empty queue (ie, no contention). In the specific implementation of lock_spinning(), make sure to set the slowpath flags on the lock just before blocking. We must do this before the last-chance pickup test to prevent a deadlock with the unlocker: Unlocker Locker test for lock pickup -> fail unlock test slowpath -> false set slowpath flags block Whereas this works in any ordering: Unlocker Locker set slowpath flags test for lock pickup -> fail block unlock test slowpath -> true, kick If the unlocker finds that the lock has the slowpath flag set but it is actually uncontended (ie, head == tail, so nobody is waiting), then it clears the slowpath flag. The unlock code uses a locked add to update the head counter. This also acts as a full memory barrier so that its safe to subsequently read back the slowflag state, knowing that the updated lock is visible to the other CPUs. If it were an unlocked add, then the flag read may just be forwarded from the store buffer before it was visible to the other CPUs, which could result in a deadlock. Unfortunately this means we need to do a locked instruction when unlocking with PV ticketlocks. However, if PV ticketlocks are not enabled, then the old non-locked "add" is the only unlocking code. Note: this code relies on gcc making sure that unlikely() code is out of line of the fastpath, which only happens when OPTIMIZE_SIZE=n. If it doesn't the generated code isn't too bad, but its definitely suboptimal. Thanks to Srivatsa Vaddagiri for providing a bugfix to the original version of this change, which has been folded in. Thanks to Stephan Diestelhorst for commenting on some code which relied on an inaccurate reading of the x86 memory ordering rules. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Srivatsa Vaddagiri Reviewed-by: Konrad Rzeszutek Wilk Cc: Stephan Diestelhorst Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/spinlock.h | 86 +++++++++++++++++++++++--------- arch/x86/include/asm/spinlock_types.h | 2 + arch/x86/kernel/paravirt-spinlocks.c | 3 + arch/x86/xen/spinlock.c | 6 ++ 5 files changed, 74 insertions(+), 25 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 9769096..af49670 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -757,7 +757,7 @@ static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, +static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) { PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket); diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 60b7e83..e6881fd 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -1,11 +1,14 @@ #ifndef _ASM_X86_SPINLOCK_H #define _ASM_X86_SPINLOCK_H +#include #include #include #include #include #include +#include + /* * Your basic SMP spinlocks, allowing only a single CPU anywhere * @@ -40,32 +43,28 @@ /* How long a lock should spin before we consider blocking */ #define SPIN_THRESHOLD (1 << 11) -#ifndef CONFIG_PARAVIRT_SPINLOCKS +extern struct static_key paravirt_ticketlocks_enabled; +static __always_inline bool static_key_false(struct static_key *key); -static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, - __ticket_t ticket) +#ifdef CONFIG_PARAVIRT_SPINLOCKS + +static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) { + set_bit(0, (volatile unsigned long *)&lock->tickets.tail); } -static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, - __ticket_t ticket) +#else /* !CONFIG_PARAVIRT_SPINLOCKS */ +static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock, + __ticket_t ticket) { } - -#endif /* CONFIG_PARAVIRT_SPINLOCKS */ - - -/* - * If a spinlock has someone waiting on it, then kick the appropriate - * waiting cpu. - */ -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, - __ticket_t next) +static inline void __ticket_unlock_kick(arch_spinlock_t *lock, + __ticket_t ticket) { - if (unlikely(lock->tickets.tail != next)) - ____ticket_unlock_kick(lock, next); } +#endif /* CONFIG_PARAVIRT_SPINLOCKS */ + /* * Ticket locks are conceptually two parts, one indicating the current head of * the queue, and the other indicating the current tail. The lock is acquired @@ -79,20 +78,22 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void arch_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(arch_spinlock_t *lock) { register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); + if (likely(inc.head == inc.tail)) + goto out; + inc.tail &= ~TICKET_SLOWPATH_FLAG; for (;;) { unsigned count = SPIN_THRESHOLD; do { - if (inc.head == inc.tail) + if (ACCESS_ONCE(lock->tickets.head) == inc.tail) goto out; cpu_relax(); - inc.head = ACCESS_ONCE(lock->tickets.head); } while (--count); __ticket_lock_spinning(lock, inc.tail); } @@ -104,7 +105,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) arch_spinlock_t old, new; old.tickets = ACCESS_ONCE(lock->tickets); - if (old.tickets.head != old.tickets.tail) + if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG)) return 0; new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); @@ -113,12 +114,49 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; } +static inline void __ticket_unlock_slowpath(arch_spinlock_t *lock, + arch_spinlock_t old) +{ + arch_spinlock_t new; + + BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); + + /* Perform the unlock on the "before" copy */ + old.tickets.head += TICKET_LOCK_INC; + + /* Clear the slowpath flag */ + new.head_tail = old.head_tail & ~(TICKET_SLOWPATH_FLAG << TICKET_SHIFT); + + /* + * If the lock is uncontended, clear the flag - use cmpxchg in + * case it changes behind our back though. + */ + if (new.tickets.head != new.tickets.tail || + cmpxchg(&lock->head_tail, old.head_tail, + new.head_tail) != old.head_tail) { + /* + * Lock still has someone queued for it, so wake up an + * appropriate waiter. + */ + __ticket_unlock_kick(lock, old.tickets.head); + } +} + static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; + if (TICKET_SLOWPATH_FLAG && + static_key_false(¶virt_ticketlocks_enabled)) { + arch_spinlock_t prev; + + prev = *lock; + add_smp(&lock->tickets.head, TICKET_LOCK_INC); + + /* add_smp() is a full mb() */ - __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); - __ticket_unlock_kick(lock, next); + if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) + __ticket_unlock_slowpath(lock, prev); + } else + __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); } static inline int arch_spin_is_locked(arch_spinlock_t *lock) diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index e96fcbd..4f1bea1 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -5,8 +5,10 @@ #ifdef CONFIG_PARAVIRT_SPINLOCKS #define __TICKET_LOCK_INC 2 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else #define __TICKET_LOCK_INC 1 +#define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif #if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index 4251c1d..bbb6c73 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -4,6 +4,7 @@ */ #include #include +#include #include @@ -15,3 +16,5 @@ struct pv_lock_ops pv_lock_ops = { }; EXPORT_SYMBOL(pv_lock_ops); +struct static_key paravirt_ticketlocks_enabled = STATIC_KEY_INIT_FALSE; +EXPORT_SYMBOL(paravirt_ticketlocks_enabled); diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c47a8d1..d4abaf9 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -155,6 +155,10 @@ static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) /* Only check lock once pending cleared */ 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) { @@ -231,6 +235,8 @@ void __init xen_init_spinlocks(void) return; } + static_key_slow_inc(¶virt_ticketlocks_enabled); + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004lC-Rs; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSl-0004RK-GL for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:11 +0000 Received: from [85.158.138.51:40637] by server-10.bemta-3.messagelabs.com id 3E/78-29478-E4701AF4; Wed, 02 May 2012 10:07:10 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1335953226!24750291!1 X-Originating-IP: [122.248.162.8] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA3NzQwNw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18133 invoked from network); 2 May 2012 10:07:09 -0000 Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:09 -0000 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:37:05 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:03 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A72ua28377270 for ; Wed, 2 May 2012 15:37:02 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FanQ5008723 for ; Thu, 3 May 2012 01:36:50 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FanQ8008694; Thu, 3 May 2012 01:36:49 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:36:51 +0530 Message-Id: <20120502100651.13206.1226.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-2000-0000-0000-00000751870E X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 3/17] x86/ticketlock: Collapse a layer of functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Now that the paravirtualization layer doesn't exist at the spinlock level any more, we can collapse the __ticket_ functions into the arch_ functions. Signed-off-by: Jeremy Fitzhardinge Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/spinlock.h | 35 +++++------------------------------ 1 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 3e47608..ee4bbd4 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -79,7 +79,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; @@ -99,7 +99,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) out: barrier(); /* make sure nothing creeps before the lock is taken */ } -static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) +static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) { arch_spinlock_t old, new; @@ -113,7 +113,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; } -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { __ticket_t next = lock->tickets.head + 1; @@ -121,46 +121,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) __ticket_unlock_kick(lock, next); } -static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) +static inline int arch_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return tmp.tail != tmp.head; } -static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) +static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return (__ticket_t)(tmp.tail - tmp.head) > 1; } - -static inline int arch_spin_is_locked(arch_spinlock_t *lock) -{ - return __ticket_spin_is_locked(lock); -} - -static inline int arch_spin_is_contended(arch_spinlock_t *lock) -{ - return __ticket_spin_is_contended(lock); -} #define arch_spin_is_contended arch_spin_is_contended -static __always_inline void arch_spin_lock(arch_spinlock_t *lock) -{ - __ticket_spin_lock(lock); -} - -static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) -{ - return __ticket_spin_trylock(lock); -} - -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) -{ - __ticket_spin_unlock(lock); -} - static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVZ-0004oo-JS; Fri, 04 May 2012 09:09:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUt-0004WW-2B for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:23 +0000 Received: from [85.158.139.83:45496] by server-10.bemta-5.messagelabs.com id 26/2D-08260-2D701AF4; Wed, 02 May 2012 10:09:22 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335953357!26377433!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzc4NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27450 invoked from network); 2 May 2012 10:09:20 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:20 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:04:00 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:03:58 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9Dxk37814350 for ; Wed, 2 May 2012 20:09:13 +1000 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 q42A9AK5022014 for ; Wed, 2 May 2012 20:09:12 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A957X021885; Wed, 2 May 2012 20:09:06 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:56 +0530 Message-Id: <20120502100856.13206.88245.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-7014-0000-0000-0000010449AC X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 13/17] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: srivatsa vaddagiri 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_pv_unhalt. Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/include/asm/kvm_host.h | 4 ++++ arch/x86/include/asm/kvm_para.h | 2 ++ arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/x86.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/kvm_para.h | 1 + 5 files changed, 46 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index e216ba0..e187a9b 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -481,6 +481,10 @@ struct kvm_vcpu_arch { u64 length; u64 status; } osvw; + /* pv related host specific info */ + struct { + bool pv_unhalted; + } pv; }; struct kvm_lpage_info { diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h index 734c376..5b647ea 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_PV_UNHALT 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/cpuid.c b/arch/x86/kvm/cpuid.c index 9fed5be..7c93806 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -408,7 +408,8 @@ static int 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_PV_UNHALT); if (sched_info_on()) entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 91a5e98..f188cdc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4993,6 +4993,36 @@ 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) { + /* + * Setting unhalt flag here can result in spurious runnable + * state when unhalt reset does not happen in vcpu_block. + * But that is harmless since that should soon result in halt. + */ + vcpu->arch.pv.pv_unhalted = true; + /* We need everybody see unhalt before vcpu unblocks */ + smp_wmb(); + kvm_vcpu_kick(vcpu); + } +} + int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) { unsigned long nr, a0, a1, a2, a3, ret; @@ -5026,6 +5056,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) case KVM_HC_VAPIC_POLL_IRQ: ret = 0; break; + case KVM_HC_KICK_CPU: + kvm_pv_kick_cpu_op(vcpu->kvm, a0); + ret = 0; + break; default: ret = -KVM_ENOSYS; break; @@ -5409,6 +5443,7 @@ static int __vcpu_run(struct kvm_vcpu *vcpu) { switch(vcpu->arch.mp_state) { case KVM_MP_STATE_HALTED: + vcpu->arch.pv.pv_unhalted = false; vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; case KVM_MP_STATE_RUNNABLE: @@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu) BUG_ON(vcpu->kvm == NULL); kvm = vcpu->kvm; + vcpu->arch.pv.pv_unhalted = false; vcpu->arch.emulate_ctxt.ops = &emulate_ops; if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu)) vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; @@ -6394,6 +6430,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 + || vcpu->arch.pv.pv_unhalted || atomic_read(&vcpu->arch.nmi_queued) || (kvm_arch_interrupt_allowed(vcpu) && kvm_cpu_has_interrupt(vcpu)); diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h index ff476dd..38226e1 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVX-0004mK-Ec; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTo-0004TM-3a for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:16 +0000 Received: from [85.158.143.35:23953] by server-1.bemta-4.messagelabs.com id 71/AB-20925-F8701AF4; Wed, 02 May 2012 10:08:15 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1335953290!14413952!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25762 invoked from network); 2 May 2012 10:08:14 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:14 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:09 +0530 Received: from d28relay05.in.ibm.com (9.184.220.62) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:06 +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 q42A85Qo21233686 for ; Wed, 2 May 2012 15:38:06 +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 q42FbilE006757 for ; Wed, 2 May 2012 21:07:46 +0530 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42Fbipn006722; Wed, 2 May 2012 21:07:44 +0530 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:54 +0530 Message-Id: <20120502100754.13206.10986.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-00000272577F X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 8/17] x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Increment ticket head/tails by 2 rather than 1 to leave the LSB free to store a "is in slowpath state" bit. This halves the number of possible CPUs for a given ticket size, but this shouldn't matter in practice - kernels built for 32k+ CPU systems are probably specially built for the hardware rather than a generic distro kernel. Signed-off-by: Jeremy Fitzhardinge Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/spinlock.h | 10 +++++----- arch/x86/include/asm/spinlock_types.h | 10 +++++++++- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index ee4bbd4..60b7e83 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -81,7 +81,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, */ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { - register struct __raw_tickets inc = { .tail = 1 }; + register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); @@ -107,7 +107,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) if (old.tickets.head != old.tickets.tail) return 0; - new.head_tail = old.head_tail + (1 << TICKET_SHIFT); + new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); /* cmpxchg is a full barrier, so nothing can move before it */ return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; @@ -115,9 +115,9 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + 1; + __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; - __add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX); + __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); __ticket_unlock_kick(lock, next); } @@ -132,7 +132,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); - return (__ticket_t)(tmp.tail - tmp.head) > 1; + return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC; } #define arch_spin_is_contended arch_spin_is_contended diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 83fd3c7..e96fcbd 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -3,7 +3,13 @@ #include -#if (CONFIG_NR_CPUS < 256) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +#define __TICKET_LOCK_INC 2 +#else +#define __TICKET_LOCK_INC 1 +#endif + +#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -11,6 +17,8 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif +#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) + #define TICKET_SHIFT (sizeof(__ticket_t) * 8) typedef struct arch_spinlock { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVZ-0004oA-6o; Fri, 04 May 2012 09:09:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUc-0004Vf-Ss for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:07 +0000 Received: from [193.109.254.147:45540] by server-4.bemta-14.messagelabs.com id FC/9B-11570-2C701AF4; Wed, 02 May 2012 10:09:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1335953342!7238076!1 X-Originating-IP: [202.81.31.140] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAzMTQxNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28683 invoked from network); 2 May 2012 10:09:05 -0000 Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:05 -0000 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:41 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:01:39 +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 q42A262W1732732 for ; Wed, 2 May 2012 20:02:06 +1000 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 q42A8tBN023480 for ; Wed, 2 May 2012 20:08:57 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A8oSw023314; Wed, 2 May 2012 20:08:50 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:38:40 +0530 Message-Id: <20120502100840.13206.44392.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-0260-0000-0000-000000F8F6E0 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 12/17] xen: Enable PV ticketlocks on HVM Xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/smp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 7dc400a..6a7a3da 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -589,4 +589,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVX-0004mf-Q7; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUB-0004Th-1L for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:39 +0000 Received: from [193.109.254.147:37168] by server-12.bemta-14.messagelabs.com id 11/D9-05898-6A701AF4; Wed, 02 May 2012 10:08:38 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335953314!7230159!1 X-Originating-IP: [122.248.162.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxODU3NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22983 invoked from network); 2 May 2012 10:08:37 -0000 Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:37 -0000 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:33 +0530 Received: from d28relay04.in.ibm.com (9.184.220.61) by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:17 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A8GoI15859730 for ; Wed, 2 May 2012 15:38:16 +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 q42FciYd006823 for ; Thu, 3 May 2012 01:38:46 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FciIY006814; Thu, 3 May 2012 01:38:44 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:05 +0530 Message-Id: <20120502100805.13206.73345.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-4790-0000-0000-0000026EB92D X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 9/17] Split out rate limiting from jump_label.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Andrew Jones Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting for jump label disabling. The changes were made in the jump label code in order to be more widely available and to keep things tidier. This is all fine, except now jump_label.h includes linux/workqueue.h, which makes it impossible to include jump_label.h from anything that workqueue.h needs. For example, it's now impossible to include jump_label.h from asm/spinlock.h, which is done in proposed pv-ticketlock patches. This patch splits out the rate limiting related changes from jump_label.h into a new file, jump_label_ratelimit.h, to resolve the issue. Signed-off-by: Andrew Jones Signed-off-by: Raghavendra K T --- include/linux/jump_label.h | 26 +------------------------- include/linux/jump_label_ratelimit.h | 34 ++++++++++++++++++++++++++++++++++ include/linux/perf_event.h | 1 + kernel/jump_label.c | 1 + 4 files changed, 37 insertions(+), 25 deletions(-) diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index c513a40..8195227 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -49,7 +49,6 @@ #include #include -#include #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) @@ -62,12 +61,6 @@ struct static_key { #endif }; -struct static_key_deferred { - struct static_key key; - unsigned long timeout; - struct delayed_work work; -}; - # include # define HAVE_JUMP_LABEL #endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */ @@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry, extern int jump_label_text_reserved(void *start, void *end); extern void static_key_slow_inc(struct static_key *key); extern void static_key_slow_dec(struct static_key *key); -extern void static_key_slow_dec_deferred(struct static_key_deferred *key); extern void jump_label_apply_nops(struct module *mod); -extern void -jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl); #define STATIC_KEY_INIT_TRUE ((struct static_key) \ { .enabled = ATOMIC_INIT(1), .entries = (void *)1 }) @@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void) { } -struct static_key_deferred { - struct static_key key; -}; - static __always_inline bool static_key_false(struct static_key *key) { if (unlikely(atomic_read(&key->enabled)) > 0) @@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key) atomic_dec(&key->enabled); } -static inline void static_key_slow_dec_deferred(struct static_key_deferred *key) -{ - static_key_slow_dec(&key->key); -} - static inline int jump_label_text_reserved(void *start, void *end) { return 0; @@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod) return 0; } -static inline void -jump_label_rate_limit(struct static_key_deferred *key, - unsigned long rl) -{ -} - #define STATIC_KEY_INIT_TRUE ((struct static_key) \ { .enabled = ATOMIC_INIT(1) }) #define STATIC_KEY_INIT_FALSE ((struct static_key) \ @@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key, #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE #define jump_label_enabled static_key_enabled +static inline int atomic_read(const atomic_t *v); static inline bool static_key_enabled(struct static_key *key) { return (atomic_read(&key->enabled) > 0); diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h new file mode 100644 index 0000000..1137883 --- /dev/null +++ b/include/linux/jump_label_ratelimit.h @@ -0,0 +1,34 @@ +#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H +#define _LINUX_JUMP_LABEL_RATELIMIT_H + +#include +#include + +#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) +struct static_key_deferred { + struct static_key key; + unsigned long timeout; + struct delayed_work work; +}; +#endif + +#ifdef HAVE_JUMP_LABEL +extern void static_key_slow_dec_deferred(struct static_key_deferred *key); +extern void +jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl); + +#else /* !HAVE_JUMP_LABEL */ +struct static_key_deferred { + struct static_key key; +}; +static inline void static_key_slow_dec_deferred(struct static_key_deferred *key) +{ + static_key_slow_dec(&key->key); +} +static inline void +jump_label_rate_limit(struct static_key_deferred *key, + unsigned long rl) +{ +} +#endif /* HAVE_JUMP_LABEL */ +#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */ diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index ddbb6a9..a0e6118 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -605,6 +605,7 @@ struct perf_guest_info_callbacks { #include #include #include +#include #include #include #include diff --git a/kernel/jump_label.c b/kernel/jump_label.c index 4304919..e17f8d6 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef HAVE_JUMP_LABEL _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004qd-FT; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWVH-0004X9-9Q for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:47 +0000 Received: from [193.109.254.147:33981] by server-5.bemta-14.messagelabs.com id 22/3B-30733-AE701AF4; Wed, 02 May 2012 10:09:46 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1335953382!7238237!1 X-Originating-IP: [202.81.31.144] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNTEwMDA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31910 invoked from network); 2 May 2012 10:09:45 -0000 Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:45 -0000 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:51:37 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:51:34 +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 q42A9b4b35455074 for ; Wed, 2 May 2012 20:09:37 +1000 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 q42A9ZGL016344 for ; Wed, 2 May 2012 20:09:37 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A9VD9016241; Wed, 2 May 2012 20:09:31 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:39:21 +0530 Message-Id: <20120502100921.13206.19019.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-5490-0000-0000-00000142E06C X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 15/17] kvm guest : Add configuration support to enable debug information for KVM Guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Srivatsa Vaddagiri Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/Kconfig | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 35eb2e4..a9ec0da 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -584,6 +584,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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVV-0004lC-Rs; Fri, 04 May 2012 09:08:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSl-0004RK-GL for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:11 +0000 Received: from [85.158.138.51:40637] by server-10.bemta-3.messagelabs.com id 3E/78-29478-E4701AF4; Wed, 02 May 2012 10:07:10 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1335953226!24750291!1 X-Originating-IP: [122.248.162.8] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA3NzQwNw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18133 invoked from network); 2 May 2012 10:07:09 -0000 Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:09 -0000 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:37:05 +0530 Received: from d28relay01.in.ibm.com (9.184.220.58) by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:03 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A72ua28377270 for ; Wed, 2 May 2012 15:37:02 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42FanQ5008723 for ; Thu, 3 May 2012 01:36:50 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FanQ8008694; Thu, 3 May 2012 01:36:49 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:36:51 +0530 Message-Id: <20120502100651.13206.1226.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-2000-0000-0000-00000751870E X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 3/17] x86/ticketlock: Collapse a layer of functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Now that the paravirtualization layer doesn't exist at the spinlock level any more, we can collapse the __ticket_ functions into the arch_ functions. Signed-off-by: Jeremy Fitzhardinge Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/spinlock.h | 35 +++++------------------------------ 1 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index 3e47608..ee4bbd4 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -79,7 +79,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, * in the high part, because a wide xadd increment of the low part would carry * up and contaminate the high part. */ -static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) +static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { register struct __raw_tickets inc = { .tail = 1 }; @@ -99,7 +99,7 @@ static __always_inline void __ticket_spin_lock(struct arch_spinlock *lock) out: barrier(); /* make sure nothing creeps before the lock is taken */ } -static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) +static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) { arch_spinlock_t old, new; @@ -113,7 +113,7 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock) return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; } -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { __ticket_t next = lock->tickets.head + 1; @@ -121,46 +121,21 @@ static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock) __ticket_unlock_kick(lock, next); } -static inline int __ticket_spin_is_locked(arch_spinlock_t *lock) +static inline int arch_spin_is_locked(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return tmp.tail != tmp.head; } -static inline int __ticket_spin_is_contended(arch_spinlock_t *lock) +static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); return (__ticket_t)(tmp.tail - tmp.head) > 1; } - -static inline int arch_spin_is_locked(arch_spinlock_t *lock) -{ - return __ticket_spin_is_locked(lock); -} - -static inline int arch_spin_is_contended(arch_spinlock_t *lock) -{ - return __ticket_spin_is_contended(lock); -} #define arch_spin_is_contended arch_spin_is_contended -static __always_inline void arch_spin_lock(arch_spinlock_t *lock) -{ - __ticket_spin_lock(lock); -} - -static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) -{ - return __ticket_spin_trylock(lock); -} - -static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) -{ - __ticket_spin_unlock(lock); -} - static __always_inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVU-0004kP-Mt; Fri, 04 May 2012 09:08:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSd-0004Qh-F1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:03 +0000 Received: from [85.158.139.83:25661] by server-6.bemta-5.messagelabs.com id 20/F2-13222-64701AF4; Wed, 02 May 2012 10:07:02 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1335953218!22427010!1 X-Originating-IP: [122.248.162.8] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA3NzQwNw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11588 invoked from network); 2 May 2012 10:07:01 -0000 Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:01 -0000 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:36:57 +0530 Received: from d28relay04.in.ibm.com (9.184.220.61) by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:36:55 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A6shb32309296 for ; Wed, 2 May 2012 15:36:54 +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 q42FbKuP002245 for ; Thu, 3 May 2012 01:37:23 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FbJkS002205; Thu, 3 May 2012 01:37:19 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:36:40 +0530 Message-Id: <20120502100640.13206.37245.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-2000-0000-0000-0000075186F2 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 2/17] x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T The code size expands somewhat, and its better to just call a function rather than inline it. Thanks Jeremy for original version of ARCH_NOINLINE_SPIN_UNLOCK config patch, which is simplified. Suggested-by: Linus Torvalds Signed-off-by: Raghavendra K T --- arch/x86/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1d14cc6..35eb2e4 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -597,6 +597,7 @@ config PARAVIRT config PARAVIRT_SPINLOCKS bool "Paravirtualization layer for spinlocks" depends on PARAVIRT && SMP && EXPERIMENTAL + select UNINLINE_SPIN_UNLOCK ---help--- Paravirtualized spinlocks allow a pvops backend to replace the spinlock implementation with something virtualization-friendly _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVZ-0004oA-6o; Fri, 04 May 2012 09:09:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUc-0004Vf-Ss for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:07 +0000 Received: from [193.109.254.147:45540] by server-4.bemta-14.messagelabs.com id FC/9B-11570-2C701AF4; Wed, 02 May 2012 10:09:06 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1335953342!7238076!1 X-Originating-IP: [202.81.31.140] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAzMTQxNTY=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28683 invoked from network); 2 May 2012 10:09:05 -0000 Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:05 -0000 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:01:41 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:01:39 +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 q42A262W1732732 for ; Wed, 2 May 2012 20:02:06 +1000 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 q42A8tBN023480 for ; Wed, 2 May 2012 20:08:57 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A8oSw023314; Wed, 2 May 2012 20:08:50 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:38:40 +0530 Message-Id: <20120502100840.13206.44392.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-0260-0000-0000-000000F8F6E0 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 12/17] xen: Enable PV ticketlocks on HVM Xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/smp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 7dc400a..6a7a3da 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -589,4 +589,5 @@ void __init xen_hvm_smp_init(void) smp_ops.cpu_die = xen_hvm_cpu_die; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; + xen_init_spinlocks(); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVb-0004s8-By; Fri, 04 May 2012 09:09:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWWD-0004Yh-5k for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:10:45 +0000 Received: from [193.109.254.147:12819] by server-1.bemta-14.messagelabs.com id 2E/C4-29372-42801AF4; Wed, 02 May 2012 10:10:44 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335953409!7230535!1 X-Originating-IP: [122.248.162.5] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTA2MDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30881 invoked from network); 2 May 2012 10:10:19 -0000 Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:10:19 -0000 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:40:09 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:40:06 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42AA5892490696 for ; Wed, 2 May 2012 15:40:05 +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 q42FeYQ3000393 for ; Thu, 3 May 2012 01:40:39 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FeY1h000383; Thu, 3 May 2012 01:40:34 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:39:47 +0530 Message-Id: <20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-8256-0000-0000-000002361FBD X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual spinlock enabled guest. KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled in guest. Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Raghavendra K T --- Documentation/virtual/kvm/cpuid.txt | 4 ++ Documentation/virtual/kvm/hypercalls.txt | 60 ++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+), 0 deletions(-) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 8820685..062dff9 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_PV_UNHALT || 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..bc3f14a --- /dev/null +++ b/Documentation/virtual/kvm/hypercalls.txt @@ -0,0 +1,60 @@ +KVM Hypercalls Documentation +=========================== +The template for each hypercall is: +1. Hypercall name, value. +2. Architecture(s) +3. Status (deprecated, obsolete, active) +4. Purpose + +1. KVM_HC_VAPIC_POLL_IRQ +------------------------ +Value: 1 +Architecture: x86 +Purpose: None + +2. KVM_HC_MMU_OP +------------------------ +Value: 2 +Architecture: x86 +Status: deprecated. +Purpose: Support MMU operations such as writing to PTE, +flushing TLB, release PT. + +3. KVM_HC_FEATURES +------------------------ +Value: 3 +Architecture: PPC +Status: active +Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid +used to enumerate which hypercalls are available. On PPC, either device tree +based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration +mechanism (which is this hypercall) can be used. + +4. KVM_HC_PPC_MAP_MAGIC_PAGE +------------------------ +Value: 4 +Architecture: PPC +Status: active +Purpose: To enable communication between the hypervisor and guest there is a +shared page that contains parts of supervisor visible register state. +The guest can map this shared page to access its supervisor register through +memory using this hypercall. + +5. KVM_HC_KICK_CPU +------------------------ +Value: 5 +Architecture: x86 +Status: active +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 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVX-0004mK-Ec; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWTo-0004TM-3a for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:16 +0000 Received: from [85.158.143.35:23953] by server-1.bemta-4.messagelabs.com id 71/AB-20925-F8701AF4; Wed, 02 May 2012 10:08:15 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1335953290!14413952!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25762 invoked from network); 2 May 2012 10:08:14 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:14 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:09 +0530 Received: from d28relay05.in.ibm.com (9.184.220.62) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:06 +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 q42A85Qo21233686 for ; Wed, 2 May 2012 15:38:06 +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 q42FbilE006757 for ; Wed, 2 May 2012 21:07:46 +0530 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42Fbipn006722; Wed, 2 May 2012 21:07:44 +0530 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:54 +0530 Message-Id: <20120502100754.13206.10986.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-00000272577F X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 8/17] x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Increment ticket head/tails by 2 rather than 1 to leave the LSB free to store a "is in slowpath state" bit. This halves the number of possible CPUs for a given ticket size, but this shouldn't matter in practice - kernels built for 32k+ CPU systems are probably specially built for the hardware rather than a generic distro kernel. Signed-off-by: Jeremy Fitzhardinge Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/spinlock.h | 10 +++++----- arch/x86/include/asm/spinlock_types.h | 10 +++++++++- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h index ee4bbd4..60b7e83 100644 --- a/arch/x86/include/asm/spinlock.h +++ b/arch/x86/include/asm/spinlock.h @@ -81,7 +81,7 @@ static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock, */ static __always_inline void arch_spin_lock(struct arch_spinlock *lock) { - register struct __raw_tickets inc = { .tail = 1 }; + register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC }; inc = xadd(&lock->tickets, inc); @@ -107,7 +107,7 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) if (old.tickets.head != old.tickets.tail) return 0; - new.head_tail = old.head_tail + (1 << TICKET_SHIFT); + new.head_tail = old.head_tail + (TICKET_LOCK_INC << TICKET_SHIFT); /* cmpxchg is a full barrier, so nothing can move before it */ return cmpxchg(&lock->head_tail, old.head_tail, new.head_tail) == old.head_tail; @@ -115,9 +115,9 @@ static __always_inline int arch_spin_trylock(arch_spinlock_t *lock) static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) { - __ticket_t next = lock->tickets.head + 1; + __ticket_t next = lock->tickets.head + TICKET_LOCK_INC; - __add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX); + __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); __ticket_unlock_kick(lock, next); } @@ -132,7 +132,7 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock) { struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); - return (__ticket_t)(tmp.tail - tmp.head) > 1; + return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC; } #define arch_spin_is_contended arch_spin_is_contended diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 83fd3c7..e96fcbd 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -3,7 +3,13 @@ #include -#if (CONFIG_NR_CPUS < 256) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +#define __TICKET_LOCK_INC 2 +#else +#define __TICKET_LOCK_INC 1 +#endif + +#if (CONFIG_NR_CPUS < (256 / __TICKET_LOCK_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -11,6 +17,8 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif +#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) + #define TICKET_SHIFT (sizeof(__ticket_t) * 8) typedef struct arch_spinlock { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004rO-TV; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWW0-0004YK-I2 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:10:32 +0000 Received: from [193.109.254.147:63134] by server-8.bemta-14.messagelabs.com id D1/19-23244-71801AF4; Wed, 02 May 2012 10:10:31 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335953393!413491!1 X-Originating-IP: [122.248.162.5] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTA2MDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26316 invoked from network); 2 May 2012 10:10:11 -0000 Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:10:11 -0000 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:39:52 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:39:49 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9nnF1180092 for ; Wed, 2 May 2012 15:39:49 +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 q42FeGYi011975 for ; Thu, 3 May 2012 01:40:19 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FeF28011954; Thu, 3 May 2012 01:40:16 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:39:36 +0530 Message-Id: <20120502100936.13206.8094.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-8256-0000-0000-000002361F75 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 16/17] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Srivatsa Vaddagiri During smp_boot_cpus paravirtualied KVM guest detects if the hypervisor has required feature (KVM_FEATURE_PV_UNHALT) 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 Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/include/asm/kvm_para.h | 14 ++- arch/x86/kernel/kvm.c | 256 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 268 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h index 5b647ea..77266d3 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 inline 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 b8ba6e4..7c46567 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -368,6 +369,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) @@ -450,3 +452,257 @@ static __init int activate_jump_labels(void) return 0; } arch_initcall(activate_jump_labels); + +/* Kick a cpu by its apicid. Used to wake up a halted vcpu */ +void kvm_kick_cpu(int cpu) +{ + int apicid; + + apicid = per_cpu(x86_cpu_to_apicid, cpu); + kvm_hypercall1(KVM_HC_KICK_CPU, apicid); +} + +#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 +#define HISTO_BUCKETS 30 + +static struct kvm_spinlock_stats +{ + u32 contention_stats[NR_CONTENTION_STATS]; + 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; + + 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; + + 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; + + 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; + + 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; + int cpu; + u64 start; + unsigned long flags; + + w = &__get_cpu_var(lock_waiting); + cpu = smp_processor_id(); + 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 vcpu waiting on @lock->head to reach value @ticket */ +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +{ + int cpu; + + add_stats(RELEASED_SLOW, 1); + for_each_cpu(cpu, &waiting_cpus) { + const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu); + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == ticket) { + add_stats(RELEASED_SLOW_KICKED, 1); + kvm_kick_cpu(cpu); + break; + } + } +} + +/* + * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present. + */ +void __init kvm_spinlock_init(void) +{ + if (!kvm_para_available()) + return; + /* Does host kernel support KVM_FEATURE_PV_UNHALT? */ + if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) + return; + + printk(KERN_INFO"KVM setup paravirtual spinlock\n"); + + static_key_slow_inc(¶virt_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 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVZ-0004oo-JS; Fri, 04 May 2012 09:09:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUt-0004WW-2B for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:23 +0000 Received: from [85.158.139.83:45496] by server-10.bemta-5.messagelabs.com id 26/2D-08260-2D701AF4; Wed, 02 May 2012 10:09:22 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1335953357!26377433!1 X-Originating-IP: [202.81.31.148] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAyNzc4NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27450 invoked from network); 2 May 2012 10:09:20 -0000 Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:20 -0000 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:04:00 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 10:03:58 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9Dxk37814350 for ; Wed, 2 May 2012 20:09:13 +1000 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 q42A9AK5022014 for ; Wed, 2 May 2012 20:09:12 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A957X021885; Wed, 2 May 2012 20:09:06 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:56 +0530 Message-Id: <20120502100856.13206.88245.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-7014-0000-0000-0000010449AC X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 13/17] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: srivatsa vaddagiri 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_pv_unhalt. Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/include/asm/kvm_host.h | 4 ++++ arch/x86/include/asm/kvm_para.h | 2 ++ arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/x86.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/kvm_para.h | 1 + 5 files changed, 46 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index e216ba0..e187a9b 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -481,6 +481,10 @@ struct kvm_vcpu_arch { u64 length; u64 status; } osvw; + /* pv related host specific info */ + struct { + bool pv_unhalted; + } pv; }; struct kvm_lpage_info { diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h index 734c376..5b647ea 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_PV_UNHALT 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/cpuid.c b/arch/x86/kvm/cpuid.c index 9fed5be..7c93806 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -408,7 +408,8 @@ static int 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_PV_UNHALT); if (sched_info_on()) entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 91a5e98..f188cdc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4993,6 +4993,36 @@ 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) { + /* + * Setting unhalt flag here can result in spurious runnable + * state when unhalt reset does not happen in vcpu_block. + * But that is harmless since that should soon result in halt. + */ + vcpu->arch.pv.pv_unhalted = true; + /* We need everybody see unhalt before vcpu unblocks */ + smp_wmb(); + kvm_vcpu_kick(vcpu); + } +} + int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) { unsigned long nr, a0, a1, a2, a3, ret; @@ -5026,6 +5056,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) case KVM_HC_VAPIC_POLL_IRQ: ret = 0; break; + case KVM_HC_KICK_CPU: + kvm_pv_kick_cpu_op(vcpu->kvm, a0); + ret = 0; + break; default: ret = -KVM_ENOSYS; break; @@ -5409,6 +5443,7 @@ static int __vcpu_run(struct kvm_vcpu *vcpu) { switch(vcpu->arch.mp_state) { case KVM_MP_STATE_HALTED: + vcpu->arch.pv.pv_unhalted = false; vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; case KVM_MP_STATE_RUNNABLE: @@ -6128,6 +6163,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu) BUG_ON(vcpu->kvm == NULL); kvm = vcpu->kvm; + vcpu->arch.pv.pv_unhalted = false; vcpu->arch.emulate_ctxt.ops = &emulate_ops; if (!irqchip_in_kernel(kvm) || kvm_vcpu_is_bsp(vcpu)) vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; @@ -6394,6 +6430,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 + || vcpu->arch.pv.pv_unhalted || atomic_read(&vcpu->arch.nmi_queued) || (kvm_arch_interrupt_allowed(vcpu) && kvm_cpu_has_interrupt(vcpu)); diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h index ff476dd..38226e1 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004n4-55; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUB-0004Ti-G9 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:39 +0000 Received: from [193.109.254.147:37196] by server-9.bemta-14.messagelabs.com id CE/B2-05787-6A701AF4; Wed, 02 May 2012 10:08:38 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1335953314!366164!1 X-Originating-IP: [122.248.162.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxODU3NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 384 invoked from network); 2 May 2012 10:08:37 -0000 Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:37 -0000 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:33 +0530 Received: from d28relay05.in.ibm.com (9.184.220.62) by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:57 +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 q42A7u7r22347888 for ; Wed, 2 May 2012 15:37:56 +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 q42FcVYG026194 for ; Thu, 3 May 2012 01:38:34 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcU8Q026136; Thu, 3 May 2012 01:38:30 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:37:42 +0530 Message-Id: <20120502100742.13206.30771.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-4790-0000-0000-0000026EB8DB X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 7/17] x86/pvticketlock: Use callee-save for lock_spinning X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Although the lock_spinning calls in the spinlock code are on the uncommon path, their presence can cause the compiler to generate many more register save/restores in the function pre/postamble, which is in the fast path. To avoid this, convert it to using the pvops callee-save calling convention, which defers all the save/restores until the actual function is called, keeping the fastpath clean. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/kernel/paravirt-spinlocks.c | 2 +- arch/x86/xen/spinlock.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 4bcd146..9769096 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -754,7 +754,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); + PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 005e24d..5e0c138 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -330,7 +330,7 @@ struct arch_spinlock; #include struct pv_lock_ops { - void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + struct paravirt_callee_save lock_spinning; void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index c2e010e..4251c1d 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -9,7 +9,7 @@ struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .lock_spinning = paravirt_nop, + .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop), .unlock_kick = paravirt_nop, #endif }; diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c4886dc..c47a8d1 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -171,6 +171,7 @@ out: local_irq_restore(flags); spin_time_accum_blocked(start); } +PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { @@ -230,7 +231,7 @@ void __init xen_init_spinlocks(void) return; } - pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVW-0004lO-9R; Fri, 04 May 2012 09:08:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWT0-0004SB-Ae for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:26 +0000 Received: from [85.158.143.99:18194] by server-1.bemta-4.messagelabs.com id 9E/2A-20925-D5701AF4; Wed, 02 May 2012 10:07:25 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1335953241!26102482!1 X-Originating-IP: [202.81.31.141] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMzQ1OTE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29407 invoked from network); 2 May 2012 10:07:24 -0000 Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:24 -0000 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:04:34 +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; Wed, 2 May 2012 10:04:31 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A7HP729425862 for ; Wed, 2 May 2012 20:07:17 +1000 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 q42A7FPU017448 for ; Wed, 2 May 2012 20:07:17 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A7BFv017367; Wed, 2 May 2012 20:07:11 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:01 +0530 Message-Id: <20120502100701.13206.12548.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-5140-0000-0000-0000012AB63F X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 4/17] xen: Defer spinlock setup until boot CPU setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge There's no need to do it at very early init, and doing it there makes it impossible to use the jump_label machinery. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/smp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 0503c0c..7dc400a 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -222,6 +222,7 @@ static void __init xen_smp_prepare_boot_cpu(void) xen_filter_cpu_maps(); xen_setup_vcpu_info_placement(); + xen_init_spinlocks(); } static void __init xen_smp_prepare_cpus(unsigned int max_cpus) @@ -551,7 +552,6 @@ void __init xen_smp_init(void) { smp_ops = xen_smp_ops; xen_fill_possible_map(); - xen_init_spinlocks(); } static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004qd-FT; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWVH-0004X9-9Q for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:47 +0000 Received: from [193.109.254.147:33981] by server-5.bemta-14.messagelabs.com id 22/3B-30733-AE701AF4; Wed, 02 May 2012 10:09:46 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1335953382!7238237!1 X-Originating-IP: [202.81.31.144] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAyNTEwMDA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31910 invoked from network); 2 May 2012 10:09:45 -0000 Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:45 -0000 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 09:51:37 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 09:51:34 +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 q42A9b4b35455074 for ; Wed, 2 May 2012 20:09:37 +1000 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 q42A9ZGL016344 for ; Wed, 2 May 2012 20:09:37 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A9VD9016241; Wed, 2 May 2012 20:09:31 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:39:21 +0530 Message-Id: <20120502100921.13206.19019.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050123-5490-0000-0000-00000142E06C X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 15/17] kvm guest : Add configuration support to enable debug information for KVM Guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Srivatsa Vaddagiri Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/Kconfig | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 35eb2e4..a9ec0da 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -584,6 +584,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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVU-0004kP-Mt; Fri, 04 May 2012 09:08:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWSd-0004Qh-F1 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:03 +0000 Received: from [85.158.139.83:25661] by server-6.bemta-5.messagelabs.com id 20/F2-13222-64701AF4; Wed, 02 May 2012 10:07:02 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1335953218!22427010!1 X-Originating-IP: [122.248.162.8] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOCA9PiA3NzQwNw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11588 invoked from network); 2 May 2012 10:07:01 -0000 Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:01 -0000 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:36:57 +0530 Received: from d28relay04.in.ibm.com (9.184.220.61) by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:36:55 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A6shb32309296 for ; Wed, 2 May 2012 15:36:54 +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 q42FbKuP002245 for ; Thu, 3 May 2012 01:37:23 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FbJkS002205; Thu, 3 May 2012 01:37:19 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:36:40 +0530 Message-Id: <20120502100640.13206.37245.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-2000-0000-0000-0000075186F2 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 2/17] x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T The code size expands somewhat, and its better to just call a function rather than inline it. Thanks Jeremy for original version of ARCH_NOINLINE_SPIN_UNLOCK config patch, which is simplified. Suggested-by: Linus Torvalds Signed-off-by: Raghavendra K T --- arch/x86/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1d14cc6..35eb2e4 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -597,6 +597,7 @@ config PARAVIRT config PARAVIRT_SPINLOCKS bool "Paravirtualization layer for spinlocks" depends on PARAVIRT && SMP && EXPERIMENTAL + select UNINLINE_SPIN_UNLOCK ---help--- Paravirtualized spinlocks allow a pvops backend to replace the spinlock implementation with something virtualization-friendly _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVb-0004s8-By; Fri, 04 May 2012 09:09:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWWD-0004Yh-5k for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:10:45 +0000 Received: from [193.109.254.147:12819] by server-1.bemta-14.messagelabs.com id 2E/C4-29372-42801AF4; Wed, 02 May 2012 10:10:44 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335953409!7230535!1 X-Originating-IP: [122.248.162.5] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTA2MDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30881 invoked from network); 2 May 2012 10:10:19 -0000 Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:10:19 -0000 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:40:09 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:40:06 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42AA5892490696 for ; Wed, 2 May 2012 15:40:05 +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 q42FeYQ3000393 for ; Thu, 3 May 2012 01:40:39 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FeY1h000383; Thu, 3 May 2012 01:40:34 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:39:47 +0530 Message-Id: <20120502100947.13206.26518.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-8256-0000-0000-000002361FBD X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 17/17] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual spinlock enabled guest. KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled in guest. Thanks Alex for KVM_HC_FEATURES inputs and Vatsa for rewriting KVM_HC_KICK_CPU Signed-off-by: Srivatsa Vaddagiri Signed-off-by: Raghavendra K T --- Documentation/virtual/kvm/cpuid.txt | 4 ++ Documentation/virtual/kvm/hypercalls.txt | 60 ++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+), 0 deletions(-) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 8820685..062dff9 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_PV_UNHALT || 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..bc3f14a --- /dev/null +++ b/Documentation/virtual/kvm/hypercalls.txt @@ -0,0 +1,60 @@ +KVM Hypercalls Documentation +=========================== +The template for each hypercall is: +1. Hypercall name, value. +2. Architecture(s) +3. Status (deprecated, obsolete, active) +4. Purpose + +1. KVM_HC_VAPIC_POLL_IRQ +------------------------ +Value: 1 +Architecture: x86 +Purpose: None + +2. KVM_HC_MMU_OP +------------------------ +Value: 2 +Architecture: x86 +Status: deprecated. +Purpose: Support MMU operations such as writing to PTE, +flushing TLB, release PT. + +3. KVM_HC_FEATURES +------------------------ +Value: 3 +Architecture: PPC +Status: active +Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid +used to enumerate which hypercalls are available. On PPC, either device tree +based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration +mechanism (which is this hypercall) can be used. + +4. KVM_HC_PPC_MAP_MAGIC_PAGE +------------------------ +Value: 4 +Architecture: PPC +Status: active +Purpose: To enable communication between the hypervisor and guest there is a +shared page that contains parts of supervisor visible register state. +The guest can map this shared page to access its supervisor register through +memory using this hypercall. + +5. KVM_HC_KICK_CPU +------------------------ +Value: 5 +Architecture: x86 +Status: active +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 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004pZ-17; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWVF-0004X2-Ga for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:45 +0000 Received: from [85.158.143.35:39376] by server-2.bemta-4.messagelabs.com id 1E/44-17550-8E701AF4; Wed, 02 May 2012 10:09:44 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1335953367!11246867!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14317 invoked from network); 2 May 2012 10:09:42 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:42 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:39:26 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:39:23 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9MtG62783670 for ; Wed, 2 May 2012 15:39:23 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42Fcavq007042 for ; Thu, 3 May 2012 01:38:37 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcZb6007032; Thu, 3 May 2012 01:38:36 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:39:11 +0530 Message-Id: <20120502100911.13206.63174.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-0000027258FE X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 14/17] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T During migration, any vcpu that got kicked but did not become runnable (still in halted state) should be runnable after migration. Signed-off-by: Raghavendra K T --- arch/x86/kvm/x86.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f188cdc..5b09b67 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5691,7 +5691,12 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu, int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu, struct kvm_mp_state *mp_state) { - mp_state->mp_state = vcpu->arch.mp_state; + if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED && + vcpu->arch.pv.pv_unhalted) + mp_state->mp_state = KVM_MP_STATE_RUNNABLE; + else + mp_state->mp_state = vcpu->arch.mp_state; + return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004rO-TV; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWW0-0004YK-I2 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:10:32 +0000 Received: from [193.109.254.147:63134] by server-8.bemta-14.messagelabs.com id D1/19-23244-71801AF4; Wed, 02 May 2012 10:10:31 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335953393!413491!1 X-Originating-IP: [122.248.162.5] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNSA9PiAxOTA2MDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26316 invoked from network); 2 May 2012 10:10:11 -0000 Received: from e28smtp05.in.ibm.com (HELO e28smtp05.in.ibm.com) (122.248.162.5) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:10:11 -0000 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:39:52 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp05.in.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:39:49 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9nnF1180092 for ; Wed, 2 May 2012 15:39:49 +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 q42FeGYi011975 for ; Thu, 3 May 2012 01:40:19 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FeF28011954; Thu, 3 May 2012 01:40:16 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:39:36 +0530 Message-Id: <20120502100936.13206.8094.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-8256-0000-0000-000002361F75 X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 16/17] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Srivatsa Vaddagiri During smp_boot_cpus paravirtualied KVM guest detects if the hypervisor has required feature (KVM_FEATURE_PV_UNHALT) 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 Signed-off-by: Suzuki Poulose Signed-off-by: Raghavendra K T --- arch/x86/include/asm/kvm_para.h | 14 ++- arch/x86/kernel/kvm.c | 256 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 268 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h index 5b647ea..77266d3 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 inline 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 b8ba6e4..7c46567 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -368,6 +369,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) @@ -450,3 +452,257 @@ static __init int activate_jump_labels(void) return 0; } arch_initcall(activate_jump_labels); + +/* Kick a cpu by its apicid. Used to wake up a halted vcpu */ +void kvm_kick_cpu(int cpu) +{ + int apicid; + + apicid = per_cpu(x86_cpu_to_apicid, cpu); + kvm_hypercall1(KVM_HC_KICK_CPU, apicid); +} + +#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 +#define HISTO_BUCKETS 30 + +static struct kvm_spinlock_stats +{ + u32 contention_stats[NR_CONTENTION_STATS]; + 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; + + 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; + + 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; + + 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; + + 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; + int cpu; + u64 start; + unsigned long flags; + + w = &__get_cpu_var(lock_waiting); + cpu = smp_processor_id(); + 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 vcpu waiting on @lock->head to reach value @ticket */ +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket) +{ + int cpu; + + add_stats(RELEASED_SLOW, 1); + for_each_cpu(cpu, &waiting_cpus) { + const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu); + if (ACCESS_ONCE(w->lock) == lock && + ACCESS_ONCE(w->want) == ticket) { + add_stats(RELEASED_SLOW_KICKED, 1); + kvm_kick_cpu(cpu); + break; + } + } +} + +/* + * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present. + */ +void __init kvm_spinlock_init(void) +{ + if (!kvm_para_available()) + return; + /* Does host kernel support KVM_FEATURE_PV_UNHALT? */ + if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) + return; + + printk(KERN_INFO"KVM setup paravirtual spinlock\n"); + + static_key_slow_inc(¶virt_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 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVY-0004n4-55; Fri, 04 May 2012 09:09:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUB-0004Ti-G9 for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:39 +0000 Received: from [193.109.254.147:37196] by server-9.bemta-14.messagelabs.com id CE/B2-05787-6A701AF4; Wed, 02 May 2012 10:08:38 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1335953314!366164!1 X-Originating-IP: [122.248.162.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxODU3NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 384 invoked from network); 2 May 2012 10:08:37 -0000 Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:37 -0000 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:33 +0530 Received: from d28relay05.in.ibm.com (9.184.220.62) by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:37:57 +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 q42A7u7r22347888 for ; Wed, 2 May 2012 15:37:56 +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 q42FcVYG026194 for ; Thu, 3 May 2012 01:38:34 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcU8Q026136; Thu, 3 May 2012 01:38:30 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:37:42 +0530 Message-Id: <20120502100742.13206.30771.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-4790-0000-0000-0000026EB8DB X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 7/17] x86/pvticketlock: Use callee-save for lock_spinning X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge Although the lock_spinning calls in the spinlock code are on the uncommon path, their presence can cause the compiler to generate many more register save/restores in the function pre/postamble, which is in the fast path. To avoid this, convert it to using the pvops callee-save calling convention, which defers all the save/restores until the actual function is called, keeping the fastpath clean. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Attilio Rao Signed-off-by: Raghavendra K T --- arch/x86/include/asm/paravirt.h | 2 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/kernel/paravirt-spinlocks.c | 2 +- arch/x86/xen/spinlock.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 4bcd146..9769096 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -754,7 +754,7 @@ static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx, static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock, __ticket_t ticket) { - PVOP_VCALL2(pv_lock_ops.lock_spinning, lock, ticket); + PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket); } static __always_inline void ____ticket_unlock_kick(struct arch_spinlock *lock, diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 005e24d..5e0c138 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -330,7 +330,7 @@ struct arch_spinlock; #include struct pv_lock_ops { - void (*lock_spinning)(struct arch_spinlock *lock, __ticket_t ticket); + struct paravirt_callee_save lock_spinning; void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket); }; diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c index c2e010e..4251c1d 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -9,7 +9,7 @@ struct pv_lock_ops pv_lock_ops = { #ifdef CONFIG_SMP - .lock_spinning = paravirt_nop, + .lock_spinning = __PV_IS_CALLEE_SAVE(paravirt_nop), .unlock_kick = paravirt_nop, #endif }; diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index c4886dc..c47a8d1 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -171,6 +171,7 @@ out: local_irq_restore(flags); spin_time_accum_blocked(start); } +PV_CALLEE_SAVE_REGS_THUNK(xen_lock_spinning); static void xen_unlock_kick(struct arch_spinlock *lock, __ticket_t next) { @@ -230,7 +231,7 @@ void __init xen_init_spinlocks(void) return; } - pv_lock_ops.lock_spinning = xen_lock_spinning; + pv_lock_ops.lock_spinning = PV_CALLEE_SAVE(xen_lock_spinning); pv_lock_ops.unlock_kick = xen_unlock_kick; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVX-0004mf-Q7; Fri, 04 May 2012 09:08:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWUB-0004Th-1L for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:08:39 +0000 Received: from [193.109.254.147:37168] by server-12.bemta-14.messagelabs.com id 11/D9-05898-6A701AF4; Wed, 02 May 2012 10:08:38 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1335953314!7230159!1 X-Originating-IP: [122.248.162.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAxODU3NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22983 invoked from network); 2 May 2012 10:08:37 -0000 Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:08:37 -0000 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:38:33 +0530 Received: from d28relay04.in.ibm.com (9.184.220.61) by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:38:17 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A8GoI15859730 for ; Wed, 2 May 2012 15:38:16 +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 q42FciYd006823 for ; Thu, 3 May 2012 01:38:46 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FciIY006814; Thu, 3 May 2012 01:38:44 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Avi Kivity , X86 , Gleb Natapov , Ingo Molnar , Marcelo Tosatti Date: Wed, 02 May 2012 15:38:05 +0530 Message-Id: <20120502100805.13206.73345.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-4790-0000-0000-0000026EB92D X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 9/17] Split out rate limiting from jump_label.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Andrew Jones Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting for jump label disabling. The changes were made in the jump label code in order to be more widely available and to keep things tidier. This is all fine, except now jump_label.h includes linux/workqueue.h, which makes it impossible to include jump_label.h from anything that workqueue.h needs. For example, it's now impossible to include jump_label.h from asm/spinlock.h, which is done in proposed pv-ticketlock patches. This patch splits out the rate limiting related changes from jump_label.h into a new file, jump_label_ratelimit.h, to resolve the issue. Signed-off-by: Andrew Jones Signed-off-by: Raghavendra K T --- include/linux/jump_label.h | 26 +------------------------- include/linux/jump_label_ratelimit.h | 34 ++++++++++++++++++++++++++++++++++ include/linux/perf_event.h | 1 + kernel/jump_label.c | 1 + 4 files changed, 37 insertions(+), 25 deletions(-) diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index c513a40..8195227 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -49,7 +49,6 @@ #include #include -#include #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) @@ -62,12 +61,6 @@ struct static_key { #endif }; -struct static_key_deferred { - struct static_key key; - unsigned long timeout; - struct delayed_work work; -}; - # include # define HAVE_JUMP_LABEL #endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */ @@ -126,10 +119,7 @@ extern void arch_jump_label_transform_static(struct jump_entry *entry, extern int jump_label_text_reserved(void *start, void *end); extern void static_key_slow_inc(struct static_key *key); extern void static_key_slow_dec(struct static_key *key); -extern void static_key_slow_dec_deferred(struct static_key_deferred *key); extern void jump_label_apply_nops(struct module *mod); -extern void -jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl); #define STATIC_KEY_INIT_TRUE ((struct static_key) \ { .enabled = ATOMIC_INIT(1), .entries = (void *)1 }) @@ -148,10 +138,6 @@ static __always_inline void jump_label_init(void) { } -struct static_key_deferred { - struct static_key key; -}; - static __always_inline bool static_key_false(struct static_key *key) { if (unlikely(atomic_read(&key->enabled)) > 0) @@ -184,11 +170,6 @@ static inline void static_key_slow_dec(struct static_key *key) atomic_dec(&key->enabled); } -static inline void static_key_slow_dec_deferred(struct static_key_deferred *key) -{ - static_key_slow_dec(&key->key); -} - static inline int jump_label_text_reserved(void *start, void *end) { return 0; @@ -202,12 +183,6 @@ static inline int jump_label_apply_nops(struct module *mod) return 0; } -static inline void -jump_label_rate_limit(struct static_key_deferred *key, - unsigned long rl) -{ -} - #define STATIC_KEY_INIT_TRUE ((struct static_key) \ { .enabled = ATOMIC_INIT(1) }) #define STATIC_KEY_INIT_FALSE ((struct static_key) \ @@ -218,6 +193,7 @@ jump_label_rate_limit(struct static_key_deferred *key, #define STATIC_KEY_INIT STATIC_KEY_INIT_FALSE #define jump_label_enabled static_key_enabled +static inline int atomic_read(const atomic_t *v); static inline bool static_key_enabled(struct static_key *key) { return (atomic_read(&key->enabled) > 0); diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h new file mode 100644 index 0000000..1137883 --- /dev/null +++ b/include/linux/jump_label_ratelimit.h @@ -0,0 +1,34 @@ +#ifndef _LINUX_JUMP_LABEL_RATELIMIT_H +#define _LINUX_JUMP_LABEL_RATELIMIT_H + +#include +#include + +#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) +struct static_key_deferred { + struct static_key key; + unsigned long timeout; + struct delayed_work work; +}; +#endif + +#ifdef HAVE_JUMP_LABEL +extern void static_key_slow_dec_deferred(struct static_key_deferred *key); +extern void +jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl); + +#else /* !HAVE_JUMP_LABEL */ +struct static_key_deferred { + struct static_key key; +}; +static inline void static_key_slow_dec_deferred(struct static_key_deferred *key) +{ + static_key_slow_dec(&key->key); +} +static inline void +jump_label_rate_limit(struct static_key_deferred *key, + unsigned long rl) +{ +} +#endif /* HAVE_JUMP_LABEL */ +#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */ diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index ddbb6a9..a0e6118 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -605,6 +605,7 @@ struct perf_guest_info_callbacks { #include #include #include +#include #include #include #include diff --git a/kernel/jump_label.c b/kernel/jump_label.c index 4304919..e17f8d6 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef HAVE_JUMP_LABEL _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEVW-0004lO-9R; Fri, 04 May 2012 09:08:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWT0-0004SB-Ae for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:07:26 +0000 Received: from [85.158.143.99:18194] by server-1.bemta-4.messagelabs.com id 9E/2A-20925-D5701AF4; Wed, 02 May 2012 10:07:25 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1335953241!26102482!1 X-Originating-IP: [202.81.31.141] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiAxMzQ1OTE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29407 invoked from network); 2 May 2012 10:07:24 -0000 Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:07:24 -0000 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 10:04:34 +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; Wed, 2 May 2012 10:04:31 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A7HP729425862 for ; Wed, 2 May 2012 20:07:17 +1000 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 q42A7FPU017448 for ; Wed, 2 May 2012 20:07:17 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42A7BFv017367; Wed, 2 May 2012 20:07:11 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:37:01 +0530 Message-Id: <20120502100701.13206.12548.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050200-5140-0000-0000-0000012AB63F X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 4/17] xen: Defer spinlock setup until boot CPU setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Jeremy Fitzhardinge There's no need to do it at very early init, and doing it there makes it impossible to use the jump_label machinery. Signed-off-by: Jeremy Fitzhardinge Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Raghavendra K T --- arch/x86/xen/smp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 0503c0c..7dc400a 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -222,6 +222,7 @@ static void __init xen_smp_prepare_boot_cpu(void) xen_filter_cpu_maps(); xen_setup_vcpu_info_placement(); + xen_init_spinlocks(); } static void __init xen_smp_prepare_cpus(unsigned int max_cpus) @@ -551,7 +552,6 @@ void __init xen_smp_init(void) { smp_ops = xen_smp_ops; xen_fill_possible_map(); - xen_init_spinlocks(); } static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004pZ-17; Fri, 04 May 2012 09:09:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SPWVF-0004X2-Ga for xen-devel@lists.xensource.com; Wed, 02 May 2012 10:09:45 +0000 Received: from [85.158.143.35:39376] by server-2.bemta-4.messagelabs.com id 1E/44-17550-8E701AF4; Wed, 02 May 2012 10:09:44 +0000 X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1335953367!11246867!1 X-Originating-IP: [122.248.162.6] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNiA9PiAxODg5MTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14317 invoked from network); 2 May 2012 10:09:42 -0000 Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (122.248.162.6) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2012 10:09:42 -0000 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 May 2012 15:39:26 +0530 Received: from d28relay03.in.ibm.com (9.184.220.60) by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 May 2012 15:39:23 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q42A9MtG62783670 for ; Wed, 2 May 2012 15:39:23 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q42Fcavq007042 for ; Thu, 3 May 2012 01:38:37 +1000 Received: from codeblue.in.ibm.com (codeblue.in.ibm.com [9.124.158.149]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q42FcZb6007032; Thu, 3 May 2012 01:38:36 +1000 From: Raghavendra K T To: Jeremy Fitzhardinge , Greg Kroah-Hartman , Konrad Rzeszutek Wilk , "H. Peter Anvin" , Marcelo Tosatti , X86 , Gleb Natapov , Ingo Molnar , Avi Kivity Date: Wed, 02 May 2012 15:39:11 +0530 Message-Id: <20120502100911.13206.63174.sendpatchset@codeblue.in.ibm.com> In-Reply-To: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> References: <20120502100610.13206.40.sendpatchset@codeblue.in.ibm.com> x-cbid: 12050210-9574-0000-0000-0000027258FE X-Mailman-Approved-At: Fri, 04 May 2012 09:08:54 +0000 Cc: Xen Devel , KVM , linux-doc@vger.kernel.org, LKML , Raghavendra K T , Srivatsa Vaddagiri , Virtualization , Andi Kleen , Stephan Diestelhorst , Attilio Rao , Linus Torvalds , Stefano Stabellini Subject: [Xen-devel] [PATCH RFC V8 14/17] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Raghavendra K T During migration, any vcpu that got kicked but did not become runnable (still in halted state) should be runnable after migration. Signed-off-by: Raghavendra K T --- arch/x86/kvm/x86.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f188cdc..5b09b67 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5691,7 +5691,12 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu, int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu, struct kvm_mp_state *mp_state) { - mp_state->mp_state = vcpu->arch.mp_state; + if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED && + vcpu->arch.pv.pv_unhalted) + mp_state->mp_state = KVM_MP_STATE_RUNNABLE; + else + mp_state->mp_state = vcpu->arch.mp_state; + return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVe-00050B-Am; Fri, 04 May 2012 09:09:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004p4-BT for Xen-devel@lists.xensource.com; Fri, 04 May 2012 09:09:02 +0000 Received: from [85.158.138.51:23218] by server-5.bemta-3.messagelabs.com id 00/EF-17113-DAC93AF4; Fri, 04 May 2012 09:09:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336122540!25219451!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9498 invoked from network); 4 May 2012 09:09:01 -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; 4 May 2012 09:09:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12292387" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:08: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, 4 May 2012 10:08:24 +0100 Message-ID: <1336122502.2361.7.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 4 May 2012 10:08:22 +0100 In-Reply-To: <20120503191025.7c2cec2e@mantra.us.oracle.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 03:10 +0100, Mukesh Rathor wrote: > Hi guys, > > At a loss trying to figure why > if (has_eflag(X86_EFLAGS_ID)) > > returns false in my HVM domU. Standard function has_eflag() in > cpucheck.c running in real mode. Works fine on PV dom0, Are you sure code in cpucheck.c is even being called for the PV/dom0 case? I'm reasonably sure that PV Xen boot doesn't go anywhere near arch/x86/boot -- we have a totally different entry point. > but fails when guest is booting on my hybrid dom0. What does the guest EFLAGS actually contain at this point? Is it different to what it contains on non-hybrid dom0? How do we execute 16 bit code in a VMX guest these days, using vm86 or by emulation? How does that interact with EFLAGS_ID I wonder (although why hybrid dom0 would have any bearing on this I've no idea). > LMK if any ideas. I'll keep digging in the manuals, but nothing so far. > > thanks, > Mukesh > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:09:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVe-00050B-Am; Fri, 04 May 2012 09:09:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEVa-0004p4-BT for Xen-devel@lists.xensource.com; Fri, 04 May 2012 09:09:02 +0000 Received: from [85.158.138.51:23218] by server-5.bemta-3.messagelabs.com id 00/EF-17113-DAC93AF4; Fri, 04 May 2012 09:09:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336122540!25219451!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzE4Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9498 invoked from network); 4 May 2012 09:09:01 -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; 4 May 2012 09:09:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12292387" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:08: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, 4 May 2012 10:08:24 +0100 Message-ID: <1336122502.2361.7.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 4 May 2012 10:08:22 +0100 In-Reply-To: <20120503191025.7c2cec2e@mantra.us.oracle.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 03:10 +0100, Mukesh Rathor wrote: > Hi guys, > > At a loss trying to figure why > if (has_eflag(X86_EFLAGS_ID)) > > returns false in my HVM domU. Standard function has_eflag() in > cpucheck.c running in real mode. Works fine on PV dom0, Are you sure code in cpucheck.c is even being called for the PV/dom0 case? I'm reasonably sure that PV Xen boot doesn't go anywhere near arch/x86/boot -- we have a totally different entry point. > but fails when guest is booting on my hybrid dom0. What does the guest EFLAGS actually contain at this point? Is it different to what it contains on non-hybrid dom0? How do we execute 16 bit code in a VMX guest these days, using vm86 or by emulation? How does that interact with EFLAGS_ID I wonder (although why hybrid dom0 would have any bearing on this I've no idea). > LMK if any ideas. I'll keep digging in the manuals, but nothing so far. > > thanks, > Mukesh > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:13:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:13:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEZO-0007bD-Ha; Fri, 04 May 2012 09:12:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEZN-0007ag-7c for xen-devel@lists.xen.org; Fri, 04 May 2012 09:12:57 +0000 Received: from [85.158.143.99:43691] by server-2.bemta-4.messagelabs.com id 70/D5-17550-89D93AF4; Fri, 04 May 2012 09:12:56 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336122775!21148487!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19664 invoked from network); 4 May 2012 09:12:55 -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; 4 May 2012 09:12:55 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 10:12:54 +0100 Message-Id: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 10:12:54 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 10:25, Keir Fraser wrote: > On 04/05/2012 09:18, "Jan Beulich" wrote: >> does this really need to be a per-CPU variable? Can't a timer run only >> once at a time on the entire system (the more that it gets re-armed only >> at the end of the poll function, whereas the variable is consumed at the >> start), and hence the variable can be a simple one? Or else, what >> subtlety am I overlooking? > > We set up a timer per initialised uart. There can be more than one (although > granted it is rare). Is that actually useful? console.c can't really use more than one at a time (for there being a single sercon_handle), so perhaps it would be a good thing to avoid the setup for those that aren't actively used, e.g. by not calling ->init_postirq() for other than the used one? Oh, wait, with crash_debug there can be a second call to serial_parse_handle(), so in that case serial console and gdb stub may run through different ports. With crash_debug off by default, wouldn't it make sense to optimize for that common case, so that specifying both "com1=" and "com2=" on the command line wouldn't needlessly consume resources (as serial_parse_handle() can easily tag which ports it got called for)? Or would you rather take the position of expecting people to remove unnecessary command line options, or live with them having side effects? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:13:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:13:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEZO-0007bD-Ha; Fri, 04 May 2012 09:12:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEZN-0007ag-7c for xen-devel@lists.xen.org; Fri, 04 May 2012 09:12:57 +0000 Received: from [85.158.143.99:43691] by server-2.bemta-4.messagelabs.com id 70/D5-17550-89D93AF4; Fri, 04 May 2012 09:12:56 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336122775!21148487!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19664 invoked from network); 4 May 2012 09:12:55 -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; 4 May 2012 09:12:55 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 10:12:54 +0100 Message-Id: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 10:12:54 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3ACDB0200007800081847@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 10:25, Keir Fraser wrote: > On 04/05/2012 09:18, "Jan Beulich" wrote: >> does this really need to be a per-CPU variable? Can't a timer run only >> once at a time on the entire system (the more that it gets re-armed only >> at the end of the poll function, whereas the variable is consumed at the >> start), and hence the variable can be a simple one? Or else, what >> subtlety am I overlooking? > > We set up a timer per initialised uart. There can be more than one (although > granted it is rare). Is that actually useful? console.c can't really use more than one at a time (for there being a single sercon_handle), so perhaps it would be a good thing to avoid the setup for those that aren't actively used, e.g. by not calling ->init_postirq() for other than the used one? Oh, wait, with crash_debug there can be a second call to serial_parse_handle(), so in that case serial console and gdb stub may run through different ports. With crash_debug off by default, wouldn't it make sense to optimize for that common case, so that specifying both "com1=" and "com2=" on the command line wouldn't needlessly consume resources (as serial_parse_handle() can easily tag which ports it got called for)? Or would you rather take the position of expecting people to remove unnecessary command line options, or live with them having side effects? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQElX-00088R-8v; Fri, 04 May 2012 09:25:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQElV-00088M-Oh for xen-devel@lists.xen.org; Fri, 04 May 2012 09:25:29 +0000 Received: from [193.109.254.147:38622] by server-11.bemta-14.messagelabs.com id 0A/40-05858-980A3AF4; Fri, 04 May 2012 09:25:29 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336123527!2450718!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6143 invoked from network); 4 May 2012 09:25:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:25:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12292975" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:25: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, 4 May 2012 10:25:26 +0100 Message-ID: <1336123525.2361.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Westfall Date: Fri, 4 May 2012 10:25:25 +0100 In-Reply-To: <20120502185402.GV5985@surrealistic.net> References: <20120502185402.GV5985@surrealistic.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 19:54 +0100, Jim Westfall wrote: > Hi > > I wanted to bring this to your attention > > https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051 > > The summary is that when gcc compiles something with -mfma4 it also > enables the use of the avx instruction set. Since by default xen > disables avx it leads to invalid opcodes. > > This ends up being kinda nasty with the multiarch glibc since its doing > stuff like > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) > > run_fma4_func() can end up bombing out from the invalid opcode when run > under xen. > > Its not clear to me if xen should be filtering fma4 as part of its avx > filter or if gcc should not assume avx support when compiling with > -mfma4. http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/ is pretty clear about the need for code to verify that the OS supports these instructions before using them (see under "Detecting Availability and Support"). The bit people seem to forget is the requirement to check CPUID.1:ECX.OSXSAVE = 1 to ensure the OS supports the use of these instructions (since they are not transparent to the OS) as well as checking the processor features themselves. If gcc/eglibc is not doing this before using those instructions then that seems like it is a bug in either gcc or eglibc. If the user is using some gcc option which forces the use of those instructions when the (virtualised, or otherwise) processor does not support them that seems like user error to me, it's no different to using -mcpu=686 and then trying to run on a 486 class processor. Sounds a lot like the same issue as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646549 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945 Ian > > thoughts? > > thanks > jim > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQElX-00088R-8v; Fri, 04 May 2012 09:25:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQElV-00088M-Oh for xen-devel@lists.xen.org; Fri, 04 May 2012 09:25:29 +0000 Received: from [193.109.254.147:38622] by server-11.bemta-14.messagelabs.com id 0A/40-05858-980A3AF4; Fri, 04 May 2012 09:25:29 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336123527!2450718!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6143 invoked from network); 4 May 2012 09:25:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:25:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12292975" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:25: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, 4 May 2012 10:25:26 +0100 Message-ID: <1336123525.2361.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Westfall Date: Fri, 4 May 2012 10:25:25 +0100 In-Reply-To: <20120502185402.GV5985@surrealistic.net> References: <20120502185402.GV5985@surrealistic.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-02 at 19:54 +0100, Jim Westfall wrote: > Hi > > I wanted to bring this to your attention > > https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051 > > The summary is that when gcc compiles something with -mfma4 it also > enables the use of the avx instruction set. Since by default xen > disables avx it leads to invalid opcodes. > > This ends up being kinda nasty with the multiarch glibc since its doing > stuff like > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) > > run_fma4_func() can end up bombing out from the invalid opcode when run > under xen. > > Its not clear to me if xen should be filtering fma4 as part of its avx > filter or if gcc should not assume avx support when compiling with > -mfma4. http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/ is pretty clear about the need for code to verify that the OS supports these instructions before using them (see under "Detecting Availability and Support"). The bit people seem to forget is the requirement to check CPUID.1:ECX.OSXSAVE = 1 to ensure the OS supports the use of these instructions (since they are not transparent to the OS) as well as checking the processor features themselves. If gcc/eglibc is not doing this before using those instructions then that seems like it is a bug in either gcc or eglibc. If the user is using some gcc option which forces the use of those instructions when the (virtualised, or otherwise) processor does not support them that seems like user error to me, it's no different to using -mcpu=686 and then trying to run on a 486 class processor. Sounds a lot like the same issue as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646549 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646945 Ian > > thoughts? > > thanks > jim > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:27:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEnZ-0008F8-UG; Fri, 04 May 2012 09:27:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEnY-0008F2-F4 for xen-devel@lists.xen.org; Fri, 04 May 2012 09:27:36 +0000 Received: from [193.109.254.147:18873] by server-9.bemta-14.messagelabs.com id 1F/F8-05787-701A3AF4; Fri, 04 May 2012 09:27:35 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336123655!7631742!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10753 invoked from network); 4 May 2012 09:27:35 -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; 4 May 2012 09:27:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 10:27:34 +0100 Message-Id: <4FA3BD2602000078000818F7@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 10:27:34 +0100 From: "Jan Beulich" To: "Jim Westfall" References: <20120502185402.GV5985@surrealistic.net> In-Reply-To: <20120502185402.GV5985@surrealistic.net> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 20:54, Jim Westfall wrote: > The summary is that when gcc compiles something with -mfma4 it also > enables the use of the avx instruction set. Since by default xen > disables avx it leads to invalid opcodes. Not that I know of, at least not anymore in current -unstable. > This ends up being kinda nasty with the multiarch glibc since its doing > stuff like > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) The question is what (runtime) tests HAS_FMA includes. I know that some glibc versions had a broken AVX check (which only checked for the AVX feature flag, while the specification explicitly states that a prerequisite check of the OSXSAVE feature flag is also necessary). > run_fma4_func() can end up bombing out from the invalid opcode when run > under xen. > > Its not clear to me if xen should be filtering fma4 as part of its avx > filter or if gcc should not assume avx support when compiling with > -mfma4. -mfma4 implying AVX and OSXSAVE is quite okay afaict, so long as the runtime checks are done correctly. Though (didn't check) from my experience with other instruction set related -m options I would really expect this to result in code using FMA4 instructions without any runtime check. But perhaps your explanation above was just a simplified version of what's really being done... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:27:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEnZ-0008F8-UG; Fri, 04 May 2012 09:27:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEnY-0008F2-F4 for xen-devel@lists.xen.org; Fri, 04 May 2012 09:27:36 +0000 Received: from [193.109.254.147:18873] by server-9.bemta-14.messagelabs.com id 1F/F8-05787-701A3AF4; Fri, 04 May 2012 09:27:35 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336123655!7631742!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10753 invoked from network); 4 May 2012 09:27:35 -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; 4 May 2012 09:27:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 10:27:34 +0100 Message-Id: <4FA3BD2602000078000818F7@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 10:27:34 +0100 From: "Jan Beulich" To: "Jim Westfall" References: <20120502185402.GV5985@surrealistic.net> In-Reply-To: <20120502185402.GV5985@surrealistic.net> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.05.12 at 20:54, Jim Westfall wrote: > The summary is that when gcc compiles something with -mfma4 it also > enables the use of the avx instruction set. Since by default xen > disables avx it leads to invalid opcodes. Not that I know of, at least not anymore in current -unstable. > This ends up being kinda nasty with the multiarch glibc since its doing > stuff like > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) The question is what (runtime) tests HAS_FMA includes. I know that some glibc versions had a broken AVX check (which only checked for the AVX feature flag, while the specification explicitly states that a prerequisite check of the OSXSAVE feature flag is also necessary). > run_fma4_func() can end up bombing out from the invalid opcode when run > under xen. > > Its not clear to me if xen should be filtering fma4 as part of its avx > filter or if gcc should not assume avx support when compiling with > -mfma4. -mfma4 implying AVX and OSXSAVE is quite okay afaict, so long as the runtime checks are done correctly. Though (didn't check) from my experience with other instruction set related -m options I would really expect this to result in code using FMA4 instructions without any runtime check. But perhaps your explanation above was just a simplified version of what's really being done... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:28:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEoK-0008Jh-CD; Fri, 04 May 2012 09:28:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEoI-0008JM-IT for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:28:22 +0000 Received: from [85.158.143.99:46321] by server-2.bemta-4.messagelabs.com id 38/FB-17550-531A3AF4; Fri, 04 May 2012 09:28:21 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-216.messagelabs.com!1336123701!16841940!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTg0Nzc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTg0Nzc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8964 invoked from network); 4 May 2012 09:28:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 09:28:21 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo87) (RZmta 28.16 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0416co4477rgA ; Fri, 4 May 2012 11:28:20 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 2B92018637; Fri, 4 May 2012 11:28:20 +0200 (CEST) Date: Fri, 4 May 2012 11:28:20 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120504092819.GA10010@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336120438.26385.13.camel@dagon.hellion.org.uk> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Campbell wrote: > On Thu, 2012-05-03 at 16:57 +0100, Olaf Hering wrote: > > On Thu, May 03, Olaf Hering wrote: > > > > > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > > > disabled for some reason. I will double check. > > > > While preparing the patch I accidently disabled vtpm in my rpm spec > > file, so the code was not exectued anymore. > > Sorry for that. > > So should c5b7d49ca3ee be reverted for now? Or are you going to come up > with a fix soon? Reverting c5b7d49ca3ee is ok. I will send another patch on top which will just crate and apply a second patch to use LDLIBS. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:28:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQEoK-0008Jh-CD; Fri, 04 May 2012 09:28:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQEoI-0008JM-IT for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:28:22 +0000 Received: from [85.158.143.99:46321] by server-2.bemta-4.messagelabs.com id 38/FB-17550-531A3AF4; Fri, 04 May 2012 09:28:21 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-216.messagelabs.com!1336123701!16841940!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTg0Nzc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTg0Nzc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8964 invoked from network); 4 May 2012 09:28:21 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 09:28:21 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo87) (RZmta 28.16 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U0416co4477rgA ; Fri, 4 May 2012 11:28:20 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 2B92018637; Fri, 4 May 2012 11:28:20 +0200 (CEST) Date: Fri, 4 May 2012 11:28:20 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120504092819.GA10010@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336120438.26385.13.camel@dagon.hellion.org.uk> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Campbell wrote: > On Thu, 2012-05-03 at 16:57 +0100, Olaf Hering wrote: > > On Thu, May 03, Olaf Hering wrote: > > > > > Perhaps I made a mistake somewhere in my queue of changes, or vtpm got > > > disabled for some reason. I will double check. > > > > While preparing the patch I accidently disabled vtpm in my rpm spec > > file, so the code was not exectued anymore. > > Sorry for that. > > So should c5b7d49ca3ee be reverted for now? Or are you going to come up > with a fix soon? Reverting c5b7d49ca3ee is ok. I will send another patch on top which will just crate and apply a second patch to use LDLIBS. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:40:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:40:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF0B-0000f5-8X; Fri, 04 May 2012 09:40:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF09-0000ev-NG for xen-devel@lists.xen.org; Fri, 04 May 2012 09:40:38 +0000 Received: from [85.158.138.51:39275] by server-3.bemta-3.messagelabs.com id B9/2A-04048-414A3AF4; Fri, 04 May 2012 09:40:36 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336124435!25097663!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24599 invoked from network); 4 May 2012 09:40:35 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:40:35 -0000 Received: by eekc4 with SMTP id c4so293722eek.32 for ; Fri, 04 May 2012 02:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=17xVVqr1Bkz9Twc5Uuwa3cHhc11/swZ7arSMoKouHlM=; b=q5Cqsgf/JatV7wljKTF8I9JwqMIyJCKjVuwuNhthQKbJDaAzkqFEmMJTOD7S251o6s kNe0BbYDp3BQNp25RbioQVnrJQbb1lp3HUZYw57ga+NEEnKA1bH2sfyZCb35++3EaKYr pc5jyc3n0UmEfbdL5rcmCGk3vYjtvq3J40oj7j4sgirHmLZCM/cFi6NJa04VDCkTYiRU 5/5/YXVU+vsoSf/XJ12rEjhZxw6XDfJW6fJcByfboCzst4SjOoXcWiKZZmxqiJd2SpEx QRHl/jgnDbVFbSbk4Gl63fWDtow81ysLjPFcpFSUVSYmVfOk6uG8mjCTmqh5p8xZFMSt jAVQ== Received: by 10.213.19.209 with SMTP id c17mr1049982ebb.46.1336124435164; Fri, 04 May 2012 02:40:35 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm38819852eea.3.2012.05.04.02.40.32 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 02:40:34 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 10:40:28 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p2fBPS3U5ySj/Yk+JFXCz9Yn0Ng== In-Reply-To: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 10:12, "Jan Beulich" wrote: >>>> On 04.05.12 at 10:25, Keir Fraser wrote: >> On 04/05/2012 09:18, "Jan Beulich" wrote: >>> does this really need to be a per-CPU variable? Can't a timer run only >>> once at a time on the entire system (the more that it gets re-armed only >>> at the end of the poll function, whereas the variable is consumed at the >>> start), and hence the variable can be a simple one? Or else, what >>> subtlety am I overlooking? >> >> We set up a timer per initialised uart. There can be more than one (although >> granted it is rare). > > Is that actually useful? console.c can't really use more than one at a > time (for there being a single sercon_handle), so perhaps it would be > a good thing to avoid the setup for those that aren't actively used, > e.g. by not calling ->init_postirq() for other than the used one? > > Oh, wait, with crash_debug there can be a second call to > serial_parse_handle(), so in that case serial console and gdb stub > may run through different ports. With crash_debug off by default, > wouldn't it make sense to optimize for that common case, so that > specifying both "com1=" and "com2=" on the command line wouldn't > needlessly consume resources (as serial_parse_handle() can easily > tag which ports it got called for)? Or would you rather take the > position of expecting people to remove unnecessary command line > options, or live with them having side effects? I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes per CPU of the poll_port variable isn't worth much optimising effort. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:40:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:40:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF0B-0000f5-8X; Fri, 04 May 2012 09:40:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF09-0000ev-NG for xen-devel@lists.xen.org; Fri, 04 May 2012 09:40:38 +0000 Received: from [85.158.138.51:39275] by server-3.bemta-3.messagelabs.com id B9/2A-04048-414A3AF4; Fri, 04 May 2012 09:40:36 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336124435!25097663!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24599 invoked from network); 4 May 2012 09:40:35 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:40:35 -0000 Received: by eekc4 with SMTP id c4so293722eek.32 for ; Fri, 04 May 2012 02:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=17xVVqr1Bkz9Twc5Uuwa3cHhc11/swZ7arSMoKouHlM=; b=q5Cqsgf/JatV7wljKTF8I9JwqMIyJCKjVuwuNhthQKbJDaAzkqFEmMJTOD7S251o6s kNe0BbYDp3BQNp25RbioQVnrJQbb1lp3HUZYw57ga+NEEnKA1bH2sfyZCb35++3EaKYr pc5jyc3n0UmEfbdL5rcmCGk3vYjtvq3J40oj7j4sgirHmLZCM/cFi6NJa04VDCkTYiRU 5/5/YXVU+vsoSf/XJ12rEjhZxw6XDfJW6fJcByfboCzst4SjOoXcWiKZZmxqiJd2SpEx QRHl/jgnDbVFbSbk4Gl63fWDtow81ysLjPFcpFSUVSYmVfOk6uG8mjCTmqh5p8xZFMSt jAVQ== Received: by 10.213.19.209 with SMTP id c17mr1049982ebb.46.1336124435164; Fri, 04 May 2012 02:40:35 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm38819852eea.3.2012.05.04.02.40.32 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 02:40:34 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 10:40:28 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p2fBPS3U5ySj/Yk+JFXCz9Yn0Ng== In-Reply-To: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 10:12, "Jan Beulich" wrote: >>>> On 04.05.12 at 10:25, Keir Fraser wrote: >> On 04/05/2012 09:18, "Jan Beulich" wrote: >>> does this really need to be a per-CPU variable? Can't a timer run only >>> once at a time on the entire system (the more that it gets re-armed only >>> at the end of the poll function, whereas the variable is consumed at the >>> start), and hence the variable can be a simple one? Or else, what >>> subtlety am I overlooking? >> >> We set up a timer per initialised uart. There can be more than one (although >> granted it is rare). > > Is that actually useful? console.c can't really use more than one at a > time (for there being a single sercon_handle), so perhaps it would be > a good thing to avoid the setup for those that aren't actively used, > e.g. by not calling ->init_postirq() for other than the used one? > > Oh, wait, with crash_debug there can be a second call to > serial_parse_handle(), so in that case serial console and gdb stub > may run through different ports. With crash_debug off by default, > wouldn't it make sense to optimize for that common case, so that > specifying both "com1=" and "com2=" on the command line wouldn't > needlessly consume resources (as serial_parse_handle() can easily > tag which ports it got called for)? Or would you rather take the > position of expecting people to remove unnecessary command line > options, or live with them having side effects? I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes per CPU of the poll_port variable isn't worth much optimising effort. -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:43:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQF2m-0000vP-RJ; Fri, 04 May 2012 09:43:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF2k-0000uy-SD for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:43:19 +0000 Received: from [85.158.138.51:14584] by server-4.bemta-3.messagelabs.com id 0A/29-15341-4B4A3AF4; Fri, 04 May 2012 09:43:16 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-5.tower-174.messagelabs.com!1336124593!25274184!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22218 invoked from network); 4 May 2012 09:43:14 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 09:43:14 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQF2c-00030h-16 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:43:10 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 11:43:10 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 11:43:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Fri, 4 May 2012 09:42:59 +0000 (UTC) Lines: 192 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini eu.citrix.com> writes: > Are you using xm or xl? I'm using xm. > Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? modprobe pciback says fatal error. xen-pciback.hide does not hide pci device. > Try assigning something that is not a graphic card, do you see the > device if you execute lspci? Nope. I get a error Error: Timed out waiting for device model action > Is it your primary graphic card? Yes it was a primary card.Now I inserted another card [quadro 570] which is acting as primary card. Now, i'm able to passthrough c2050 card. But on assigning them I get a msg Error: Timed out waiting for device model action log: [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2498) XendDomainInfo.constructDomain [2012-05-04 12:51:09 2006] DEBUG (balloon:187) Balloon: 1048700 KiB free; need 16384; done. [2012-05-04 12:51:09 2006] DEBUG (XendDomain:476) Adding Domain: 2 [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2836) XendDomainInfo.initDomain: 2 256 [2012-05-04 12:51:09 2006] DEBUG (image:337) Stored a VNC password for vfb access [2012-05-04 12:51:09 2006] DEBUG (image:891) args: boot, val: c [2012-05-04 12:51:09 2006] DEBUG (image:891) args: fda, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: fdb, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: soundhw, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: localtime, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: serial, val: ['pty'] [2012-05-04 12:51:09 2006] DEBUG (image:891) args: std-vga, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: isa, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: acpi, val: 1 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: usb, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: usbdevice, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: gfx_passthru, val: None [2012-05-04 12:51:09 2006] INFO (image:822) Need to create platform device.[domid:2] [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2863) _initDomain:shadow_memory=0x0, memory_static_max=0x20000000, memory_static_min=0x0. [2012-05-04 12:51:09 2006] INFO (image:182) buildDomain os=hvm dom=2 vcpus=1 [2012-05-04 12:51:09 2006] DEBUG (image:949) domid = 2 [2012-05-04 12:51:09 2006] DEBUG (image:950) image = /usr/lib/xen/boot/hvmloader [2012-05-04 12:51:09 2006] DEBUG (image:951) store_evtchn = 2 [2012-05-04 12:51:09 2006] DEBUG (image:952) memsize = 512 [2012-05-04 12:51:09 2006] DEBUG (image:953) target = 512 [2012-05-04 12:51:09 2006] DEBUG (image:954) vcpus = 1 [2012-05-04 12:51:09 2006] DEBUG (image:955) vcpu_avail = 1 [2012-05-04 12:51:09 2006] DEBUG (image:956) acpi = 1 [2012-05-04 12:51:09 2006] DEBUG (image:957) apic = 1 [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: vfb : {'vncpasswd': 'XXXXXXXX', 'vncunused': 1, 'other_config': {'vncunused': 1, 'vncpasswd': 'XXXXXXXX', 'vnc': '1'}, 'vnc': '1', 'uuid': '686bf850-485f-2089-4207-fe4cce4a55d4'} [2012-05-04 12:51:09 2006] DEBUG (DevController:95) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vfb/2/0'} to /local/domain/2/device/vfb/0. [2012-05-04 12:51:09 2006] DEBUG (DevController:97) DevController: writing {'vncunused': '1', 'domain': 'xen10_04', 'frontend': '/local/domain/2/device/vfb/0', 'uuid': '686bf850-485f-2089-4207-fe4cce4a55d4', 'frontend-id': '2', 'vncpasswd': 'XXXXXXXX', 'state': '1', 'online': '1', 'vnc':'1'} to /local/domain/0/backend/vfb/2/0. [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: vbd : {'uuid': '7e43a0f7-9c76-d2c5-86eb-66e599b19b7e', 'bootable': 1, 'driver': 'ioemu', 'dev': 'ioemu:xvda', 'uname': 'file:/home/gpu/XenGuest.img', 'mode': 'w'} [2012-05-04 12:51:09 2006] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '51712', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/2/51712'} to /local/domain/2/device/vbd/51712. [2012-05-04 12:51:09 2006] DEBUG (DevController:97) DevController: writing {'domain': 'xen10_04', 'frontend': '/local/domain/2/device/vbd/51712', 'uuid': '7e43a0f7-9c76-d2c5-86eb-66e599b19b7e', 'bootable': '1', 'dev': 'xvda', 'state': '1', 'params': '/home/gpu/XenGuest.img', 'mode': 'w', 'online': '1', 'frontend-id': '2', 'type': 'file'} to /local/domain/0/backend/vbd/2/51712. [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: pci : {'devs': [{'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'}, {'slot': '0x00', 'domain': '0x0000', 'key': '42:00.1', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x1', 'uuid': '7ab51e57-6c63-14fb-ea42-eee3c6aaedac'}], 'uuid': '503788f2-e43d-1869-ad44-347a7a735bc6'} [2012-05-04 12:51:12 2006] INFO (image:418) spawning device models: /usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '2', '-domain-name', 'xen10_04', '-videoram', '4', '-vnc', '127.0.0.1:0,password', '-vncunused', '-vcpus', '1', '-vcpu_avail', '0x1', '-boot', 'c', '-serial', 'pty', '-acpi', '-net', 'none', '-M', 'xenfv'] [2012-05-04 12:51:12 2006] INFO (image:467) device model pid: 2849 [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:893) XendDomainInfo.pci_device_configure: ['pci', ['dev', ['slot', '0x00'], ['domain', '0x0000'], ['key', '42:00.0'], ['bus', '0x42'], ['vdevfn', '0x100'], ['func', '0x0'], ['uuid', '92c19814-33ea-4094-a391-e958c5ff8b39']], ['state', 'Initialising'], ['sub_state', 'Booting']] [2012-05-04 12:51:12 2006] INFO (image:590) waiting for sentinel_fifo [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:779) XendDomainInfo.hvm_pci_device_insert: {'devs': [{'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'}], 'states': ['Initialising']} [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:790) XendDomainInfo.hvm_pci_device_insert_dev: {'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'} [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:811) XendDomainInfo.hvm_pci_device_insert_dev: 0000:42:00.0@100,msitranslate=1,power_mgmt=0 [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:815) pci: assign device 0000:42:00.0@100,msitranslate=1,power_mgmt=0 [2012-05-04 12:51:12 2006] DEBUG (image:508) signalDeviceModel: orig_state is None, retrying [2012-05-04 12:51:22 2006] ERROR (XendDomainInfo:2922) XendDomainInfo.initDomain: exception occurred Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain self._createDevices() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2395, in _createDevices self.pci_device_configure_boot() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 627, in pci_device_configure_boot self.pci_device_configure(dev_sxp, first_dev = first) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 921, in pci_device_configure vdevfn = self.hvm_pci_device_insert(dev_config) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 786, in hvm_pci_device_insert return self.hvm_pci_device_insert_dev(new_dev) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 816, in hvm_pci_device_insert_dev self.image.signalDeviceModel('pci-ins', 'pci-inserted', bdf_str) File "/usr/local/lib/python2.7/dist-packages/xen/xend/image.py", line 533, in signalDeviceModel raise VmError('Timed out waiting for device model action') VmError: Timed out waiting for device model action [2012-05-04 12:51:22 2006] ERROR (XendDomainInfo:488) VM start failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2925, in _initDomain raise exn VmError: Timed out waiting for device model action [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy: domid=2 [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2401) Destroying device model [2012-05-04 12:51:22 2006] INFO (image:615) xen10_04 device model terminated [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2408) Releasing devices [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2414) Removing vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2414) Removing vfb/0 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2406) No device model [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2408) Releasing devices [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2414) Removing vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51712 [2012-05-04 12:51:23 2006] ERROR (XendDomainInfo:108) Domain construction failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 106, in create vm.start() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2925, in _initDomain raise exn VmError: Timed out waiting for device model action _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:43:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQF2m-0000vP-RJ; Fri, 04 May 2012 09:43:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF2k-0000uy-SD for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:43:19 +0000 Received: from [85.158.138.51:14584] by server-4.bemta-3.messagelabs.com id 0A/29-15341-4B4A3AF4; Fri, 04 May 2012 09:43:16 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-5.tower-174.messagelabs.com!1336124593!25274184!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22218 invoked from network); 4 May 2012 09:43:14 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 09:43:14 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQF2c-00030h-16 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:43:10 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 11:43:10 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 11:43:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Fri, 4 May 2012 09:42:59 +0000 (UTC) Lines: 192 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini eu.citrix.com> writes: > Are you using xm or xl? I'm using xm. > Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? modprobe pciback says fatal error. xen-pciback.hide does not hide pci device. > Try assigning something that is not a graphic card, do you see the > device if you execute lspci? Nope. I get a error Error: Timed out waiting for device model action > Is it your primary graphic card? Yes it was a primary card.Now I inserted another card [quadro 570] which is acting as primary card. Now, i'm able to passthrough c2050 card. But on assigning them I get a msg Error: Timed out waiting for device model action log: [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2498) XendDomainInfo.constructDomain [2012-05-04 12:51:09 2006] DEBUG (balloon:187) Balloon: 1048700 KiB free; need 16384; done. [2012-05-04 12:51:09 2006] DEBUG (XendDomain:476) Adding Domain: 2 [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2836) XendDomainInfo.initDomain: 2 256 [2012-05-04 12:51:09 2006] DEBUG (image:337) Stored a VNC password for vfb access [2012-05-04 12:51:09 2006] DEBUG (image:891) args: boot, val: c [2012-05-04 12:51:09 2006] DEBUG (image:891) args: fda, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: fdb, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: soundhw, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: localtime, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: serial, val: ['pty'] [2012-05-04 12:51:09 2006] DEBUG (image:891) args: std-vga, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: isa, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: acpi, val: 1 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: usb, val: 0 [2012-05-04 12:51:09 2006] DEBUG (image:891) args: usbdevice, val: None [2012-05-04 12:51:09 2006] DEBUG (image:891) args: gfx_passthru, val: None [2012-05-04 12:51:09 2006] INFO (image:822) Need to create platform device.[domid:2] [2012-05-04 12:51:09 2006] DEBUG (XendDomainInfo:2863) _initDomain:shadow_memory=0x0, memory_static_max=0x20000000, memory_static_min=0x0. [2012-05-04 12:51:09 2006] INFO (image:182) buildDomain os=hvm dom=2 vcpus=1 [2012-05-04 12:51:09 2006] DEBUG (image:949) domid = 2 [2012-05-04 12:51:09 2006] DEBUG (image:950) image = /usr/lib/xen/boot/hvmloader [2012-05-04 12:51:09 2006] DEBUG (image:951) store_evtchn = 2 [2012-05-04 12:51:09 2006] DEBUG (image:952) memsize = 512 [2012-05-04 12:51:09 2006] DEBUG (image:953) target = 512 [2012-05-04 12:51:09 2006] DEBUG (image:954) vcpus = 1 [2012-05-04 12:51:09 2006] DEBUG (image:955) vcpu_avail = 1 [2012-05-04 12:51:09 2006] DEBUG (image:956) acpi = 1 [2012-05-04 12:51:09 2006] DEBUG (image:957) apic = 1 [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: vfb : {'vncpasswd': 'XXXXXXXX', 'vncunused': 1, 'other_config': {'vncunused': 1, 'vncpasswd': 'XXXXXXXX', 'vnc': '1'}, 'vnc': '1', 'uuid': '686bf850-485f-2089-4207-fe4cce4a55d4'} [2012-05-04 12:51:09 2006] DEBUG (DevController:95) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vfb/2/0'} to /local/domain/2/device/vfb/0. [2012-05-04 12:51:09 2006] DEBUG (DevController:97) DevController: writing {'vncunused': '1', 'domain': 'xen10_04', 'frontend': '/local/domain/2/device/vfb/0', 'uuid': '686bf850-485f-2089-4207-fe4cce4a55d4', 'frontend-id': '2', 'vncpasswd': 'XXXXXXXX', 'state': '1', 'online': '1', 'vnc':'1'} to /local/domain/0/backend/vfb/2/0. [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: vbd : {'uuid': '7e43a0f7-9c76-d2c5-86eb-66e599b19b7e', 'bootable': 1, 'driver': 'ioemu', 'dev': 'ioemu:xvda', 'uname': 'file:/home/gpu/XenGuest.img', 'mode': 'w'} [2012-05-04 12:51:09 2006] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '51712', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/2/51712'} to /local/domain/2/device/vbd/51712. [2012-05-04 12:51:09 2006] DEBUG (DevController:97) DevController: writing {'domain': 'xen10_04', 'frontend': '/local/domain/2/device/vbd/51712', 'uuid': '7e43a0f7-9c76-d2c5-86eb-66e599b19b7e', 'bootable': '1', 'dev': 'xvda', 'state': '1', 'params': '/home/gpu/XenGuest.img', 'mode': 'w', 'online': '1', 'frontend-id': '2', 'type': 'file'} to /local/domain/0/backend/vbd/2/51712. [2012-05-04 12:51:09 2006] INFO (XendDomainInfo:2357) createDevice: pci : {'devs': [{'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'}, {'slot': '0x00', 'domain': '0x0000', 'key': '42:00.1', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x1', 'uuid': '7ab51e57-6c63-14fb-ea42-eee3c6aaedac'}], 'uuid': '503788f2-e43d-1869-ad44-347a7a735bc6'} [2012-05-04 12:51:12 2006] INFO (image:418) spawning device models: /usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '2', '-domain-name', 'xen10_04', '-videoram', '4', '-vnc', '127.0.0.1:0,password', '-vncunused', '-vcpus', '1', '-vcpu_avail', '0x1', '-boot', 'c', '-serial', 'pty', '-acpi', '-net', 'none', '-M', 'xenfv'] [2012-05-04 12:51:12 2006] INFO (image:467) device model pid: 2849 [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:893) XendDomainInfo.pci_device_configure: ['pci', ['dev', ['slot', '0x00'], ['domain', '0x0000'], ['key', '42:00.0'], ['bus', '0x42'], ['vdevfn', '0x100'], ['func', '0x0'], ['uuid', '92c19814-33ea-4094-a391-e958c5ff8b39']], ['state', 'Initialising'], ['sub_state', 'Booting']] [2012-05-04 12:51:12 2006] INFO (image:590) waiting for sentinel_fifo [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:779) XendDomainInfo.hvm_pci_device_insert: {'devs': [{'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'}], 'states': ['Initialising']} [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:790) XendDomainInfo.hvm_pci_device_insert_dev: {'slot': '0x00', 'domain': '0x0000', 'key': '42:00.0', 'bus': '0x42', 'vdevfn': '0x100', 'func': '0x0', 'uuid': '92c19814-33ea-4094-a391-e958c5ff8b39'} [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:811) XendDomainInfo.hvm_pci_device_insert_dev: 0000:42:00.0@100,msitranslate=1,power_mgmt=0 [2012-05-04 12:51:12 2006] DEBUG (XendDomainInfo:815) pci: assign device 0000:42:00.0@100,msitranslate=1,power_mgmt=0 [2012-05-04 12:51:12 2006] DEBUG (image:508) signalDeviceModel: orig_state is None, retrying [2012-05-04 12:51:22 2006] ERROR (XendDomainInfo:2922) XendDomainInfo.initDomain: exception occurred Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2914, in _initDomain self._createDevices() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2395, in _createDevices self.pci_device_configure_boot() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 627, in pci_device_configure_boot self.pci_device_configure(dev_sxp, first_dev = first) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 921, in pci_device_configure vdevfn = self.hvm_pci_device_insert(dev_config) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 786, in hvm_pci_device_insert return self.hvm_pci_device_insert_dev(new_dev) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 816, in hvm_pci_device_insert_dev self.image.signalDeviceModel('pci-ins', 'pci-inserted', bdf_str) File "/usr/local/lib/python2.7/dist-packages/xen/xend/image.py", line 533, in signalDeviceModel raise VmError('Timed out waiting for device model action') VmError: Timed out waiting for device model action [2012-05-04 12:51:22 2006] ERROR (XendDomainInfo:488) VM start failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2925, in _initDomain raise exn VmError: Timed out waiting for device model action [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy: domid=2 [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2401) Destroying device model [2012-05-04 12:51:22 2006] INFO (image:615) xen10_04 device model terminated [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2408) Releasing devices [2012-05-04 12:51:22 2006] DEBUG (XendDomainInfo:2414) Removing vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2414) Removing vfb/0 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2406) No device model [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2408) Releasing devices [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:2414) Removing vbd/51712 [2012-05-04 12:51:23 2006] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51712 [2012-05-04 12:51:23 2006] ERROR (XendDomainInfo:108) Domain construction failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 106, in create vm.start() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2925, in _initDomain raise exn VmError: Timed out waiting for device model action _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:50:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQF9H-0001FU-NP; Fri, 04 May 2012 09:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF9G-0001FK-4Z for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:50:02 +0000 Received: from [85.158.139.83:5479] by server-7.bemta-5.messagelabs.com id 92/26-16195-946A3AF4; Fri, 04 May 2012 09:50:01 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336124998!26058053!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20462 invoked from network); 4 May 2012 09:49:59 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:49:59 -0000 Received: by qcsp15 with SMTP id p15so2265077qcs.30 for ; Fri, 04 May 2012 02:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9O5g+1zrZKUrzK+kpYvRsU0AimjrFK57kGo3FnCqkWM=; b=PXT57YQ1Rq35DvKd7bOsPgFMyQP5x7CzucF49h9gWr3z2IQjIib3xmVwaS9ng3NYXQ vM4oVCdE9fr6YtfFLGNh6SFafQfcsEzmKP7+23sxqOZCX6vY7N7yYkU0+7qK3ekiHe7P TnkxfqTg/BtBu3Rt800SgG2esKTCtdyYHB51vwZvIaqbFJm1CT9bwnuZoAwZj4HV9+Kd DWdg/KF4XnnG29UzDpcq/ulNtGLO1AiNc8P0FFgMjk967OR4KeiFrbHuccGUmb/zD8Kl P6r2P7OX+6Q1at0kqQokxycX5iWY1m3uz3gKmjBmc10mjNDuGpLNwovdQ0blCoLaC+bc A5WQ== MIME-Version: 1.0 Received: by 10.224.173.210 with SMTP id q18mr9031923qaz.11.1336124998231; Fri, 04 May 2012 02:49:58 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Fri, 4 May 2012 02:49:58 -0700 (PDT) In-Reply-To: <60013c9b8d62e39988db.1335971423@kodo2> References: <60013c9b8d62e39988db.1335971423@kodo2> Date: Fri, 4 May 2012 10:49:58 +0100 X-Google-Sender-Auth: 2XXuqZfX8XvBHRBm1YHu-FRfGiw Message-ID: From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hmm -- sorry, I seemed so have mucked some things up on the rebase... please don't apply this one. -George On Wed, May 2, 2012 at 4:10 PM, George Dunlap wrote: > # HG changeset patch > # User George Dunlap > # Date 1335971129 -3600 > # Node ID 60013c9b8d62e39988db3c5b22c0510f5557756b > # Parent =A0c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 > xl: Make clear distinction between "filename" and "data source" > > Many places in xl there's a variable or element named "filename" which > does not contain a filename, but the source of the data for reporting > purposes. =A0Worse, there are variables which are sometimes actually > used or interpreted as a filename depending on what other variables > are set. =A0This makes it difficult to tell when a string is purely > cosmetic, and when another bit of code may actually attempt to call > "open" with the string. > > This patch makes a consistent distinction between "filename" (which > always refers to the name of an actual file, and may be interpreted as > such at some point) and "source" (which may be a filename, or may be > another data source such as a migration stream or saved data). > > This does add some variables and reshuffle where assignments happen; > most notably, the "restore_filename" element of struct domain_create > is now only set when restoring from a file. > > But at a high level, there should be no funcitonal changes. > > Signed-off-by: George Dunlap > > diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/libxl_utils.c > --- a/tools/libxl/libxl_utils.c Wed May 02 16:05:26 2012 +0100 > +++ b/tools/libxl/libxl_utils.c Wed May 02 16:05:29 2012 +0100 > @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= \ > =A0 int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constdata void *da= ta, ssize_t sz, =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *filenam= e, const char *what) { =A0 =A0 =A0\ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *source,= const char *what) { =A0 =A0 =A0\ > =A0 =A0 =A0 ssize_t got; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= \ > =A0 =A0 =A0 while (sz > 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (errno =3D=3D EINTR) continue; =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!ctx) return errno; =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fail= ed to " #rw " %s%s%s", \ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?= " from ":"", filename); =A0 =A0 \ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?= " from ":"", source); =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return errno; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 if (got =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zero_is_eof =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? "file/stream truncated readi= ng %s%s%s" =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "file/stream write returned = 0! writing %s%s%s", =A0 =A0\ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?" from ":"",= filename); =A0 =A0 =A0 =A0 =A0 \ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?" from ":"",= source); =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return EPROTO; =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 sz -=3D got; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c =A0Wed May 02 16:05:26 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c =A0Wed May 02 16:05:29 2012 +0100 > @@ -520,9 +520,9 @@ vcpp_out: > =A0 =A0 return rc; > =A0} > > -static void parse_config_data(const char *configfile_filename_report, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *= configfile_data, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int configfi= le_len, > +static void parse_config_data(const char *config_source, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *= config_data, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int config_l= en, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_domain_= config *d_config) > =A0{ > =A0 =A0 const char *buf; > @@ -537,15 +537,15 @@ static void parse_config_data(const char > =A0 =A0 libxl_domain_create_info *c_info =3D &d_config->c_info; > =A0 =A0 libxl_domain_build_info *b_info =3D &d_config->b_info; > > - =A0 =A0config=3D xlu_cfg_init(stderr, configfile_filename_report); > + =A0 =A0config=3D xlu_cfg_init(stderr, config_source); > =A0 =A0 if (!config) { > =A0 =A0 =A0 =A0 fprintf(stderr, "Failed to allocate for configuration\n"); > =A0 =A0 =A0 =A0 exit(1); > =A0 =A0 } > > - =A0 =A0e=3D xlu_cfg_readdata(config, configfile_data, configfile_len); > + =A0 =A0e=3D xlu_cfg_readdata(config, config_data, config_len); > =A0 =A0 if (e) { > - =A0 =A0 =A0 =A0fprintf(stderr, "Failed to parse config file: %s\n", str= error(e)); > + =A0 =A0 =A0 =A0fprintf(stderr, "Failed to parse config: %s\n", strerror= (e)); > =A0 =A0 =A0 =A0 exit(1); > =A0 =A0 } > > @@ -1522,6 +1522,8 @@ static int create_domain(struct domain_c > =A0 =A0 const char *config_file =3D dom_info->config_file; > =A0 =A0 const char *extra_config =3D dom_info->extra_config; > =A0 =A0 const char *restore_file =3D dom_info->restore_file; > + =A0 =A0const char *config_source =3D NULL; > + =A0 =A0const char *restore_source =3D NULL; > =A0 =A0 int migrate_fd =3D dom_info->migrate_fd; > > =A0 =A0 int i; > @@ -1537,24 +1539,28 @@ static int create_domain(struct domain_c > =A0 =A0 pid_t child_console_pid =3D -1; > =A0 =A0 struct save_file_header hdr; > > + =A0 =A0int restoring =3D (restore_file || (migrate_fd >=3D 0)); > + > =A0 =A0 libxl_domain_config_init(&d_config); > > - =A0 =A0if (restore_file) { > + =A0 =A0if (restoring) { > =A0 =A0 =A0 =A0 uint8_t *optdata_begin =3D 0; > =A0 =A0 =A0 =A0 const uint8_t *optdata_here =3D 0; > =A0 =A0 =A0 =A0 union { uint32_t u32; char b[4]; } u32buf; > =A0 =A0 =A0 =A0 uint32_t badflags; > > =A0 =A0 =A0 =A0 if (migrate_fd >=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0restore_source =3D "" > =A0 =A0 =A0 =A0 =A0 =A0 restore_fd =3D migrate_fd; > =A0 =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0restore_source =3D restore_file; > =A0 =A0 =A0 =A0 =A0 =A0 restore_fd =3D open(restore_file, O_RDONLY); > =A0 =A0 =A0 =A0 =A0 =A0 rc =3D libxl_fd_set_cloexec(ctx, restore_fd, 1); > =A0 =A0 =A0 =A0 =A0 =A0 if (rc) return rc; > =A0 =A0 =A0 =A0 } > > =A0 =A0 =A0 =A0 CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sizeof(hdr), restore_file, "header"= ) ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sizeof(hdr), restore_source, "heade= r") ); > =A0 =A0 =A0 =A0 if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.ma= gic))) { > =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "File has wrong magic number -" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " corrupt or for a different tool= ?\n"); > @@ -1567,7 +1573,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 fprintf(stderr, "Loading new save file %s" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (new xl fmt info" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0restore_file, hdr.mandatory_flags, hdr.o= ptional_flags, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0restore_source, hdr.mandatory_flags, hdr= .optional_flags, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len); > > =A0 =A0 =A0 =A0 badflags =3D hdr.mandatory_flags & ~( 0 /* none understoo= d yet */ ); > @@ -1580,7 +1586,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 if (hdr.optional_data_len) { > =A0 =A0 =A0 =A0 =A0 =A0 optdata_begin =3D xmalloc(hdr.optional_data_len); > =A0 =A0 =A0 =A0 =A0 =A0 CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, op= tdata_begin, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len, restore_file= , "optdata") ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len, restore_sour= ce, "optdata") ); > =A0 =A0 =A0 =A0 } > > =A0#define OPTDATA_LEFT =A0(hdr.optional_data_len - (optdata_here - optda= ta_begin)) > @@ -1615,7 +1621,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0&config_data, &config_len); > =A0 =A0 =A0 =A0 if (ret) { fprintf(stderr, "Failed to read config file: %= s: %s\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_file, strer= ror(errno)); return ERROR_FAIL; } > - =A0 =A0 =A0 =A0if (!restore_file && extra_config && strlen(extra_config= )) { > + =A0 =A0 =A0 =A0if (!restoring && extra_config && strlen(extra_config)) { > =A0 =A0 =A0 =A0 =A0 =A0 if (config_len > INT_MAX - (strlen(extra_config) = + 2 + 1)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "Failed to attach extra c= onfigration\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_FAIL; > @@ -1630,19 +1636,20 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 =A0 =A0 config_len +=3D sprintf(config_data + config_len,= "\n%s\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extra_config); > =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0config_source=3Dconfig_file; > =A0 =A0 } else { > =A0 =A0 =A0 =A0 if (!config_data) { > =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "Config file not specified and" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " none in save file\n"); > =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_INVAL; > =A0 =A0 =A0 =A0 } > - =A0 =A0 =A0 =A0config_file =3D ""; > + =A0 =A0 =A0 =A0config_source =3D ""; > =A0 =A0 } > > =A0 =A0 if (!dom_info->quiet) > - =A0 =A0 =A0 =A0printf("Parsing config file %s\n", config_file); > - > - =A0 =A0parse_config_data(config_file, config_data, config_len, &d_confi= g); > + =A0 =A0 =A0 =A0printf("Parsing config from %s\n", config_source); > + > + =A0 =A0parse_config_data(config_source, config_data, config_len, &d_con= fig); > > =A0 =A0 if (migrate_fd >=3D 0) { > =A0 =A0 =A0 =A0 if (d_config.c_info.name) { > @@ -1693,7 +1700,7 @@ start: > =A0 =A0 =A0 =A0 cb =3D NULL; > =A0 =A0 } > > - =A0 =A0if ( restore_file ) { > + =A0 =A0if ( restoring ) { > =A0 =A0 =A0 =A0 ret =3D libxl_domain_create_restore(ctx, &d_config, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 cb, &child_console_pid, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 &domid, restore_fd); > @@ -2469,7 +2476,7 @@ static void list_domains_details(const l > =A0{ > =A0 =A0 libxl_domain_config d_config; > > - =A0 =A0char *config_file; > + =A0 =A0char *config_source; > =A0 =A0 uint8_t *data; > =A0 =A0 int i, len, rc; > > @@ -2480,13 +2487,13 @@ static void list_domains_details(const l > =A0 =A0 =A0 =A0 rc =3D libxl_userdata_retrieve(ctx, info[i].domid, "xl", = &data, &len); > =A0 =A0 =A0 =A0 if (rc) > =A0 =A0 =A0 =A0 =A0 =A0 continue; > - =A0 =A0 =A0 =A0CHK_ERRNO(asprintf(&config_file, "", info= [i].domid)); > + =A0 =A0 =A0 =A0CHK_ERRNO(asprintf(&config_source, "", in= fo[i].domid)); > =A0 =A0 =A0 =A0 libxl_domain_config_init(&d_config); > - =A0 =A0 =A0 =A0parse_config_data(config_file, (char *)data, len, &d_con= fig); > + =A0 =A0 =A0 =A0parse_config_data(config_source, (char *)data, len, &d_c= onfig); > =A0 =A0 =A0 =A0 printf_info(default_output_format, info[i].domid, &d_conf= ig); > =A0 =A0 =A0 =A0 libxl_domain_config_dispose(&d_config); > =A0 =A0 =A0 =A0 free(data); > - =A0 =A0 =A0 =A0free(config_file); > + =A0 =A0 =A0 =A0free(config_source); > =A0 =A0 } > =A0} > > @@ -2589,7 +2596,7 @@ static void save_domain_core_begin(const > =A0 =A0 } > =A0} > > -static void save_domain_core_writeconfig(int fd, const char *filename, > +static void save_domain_core_writeconfig(int fd, const char *source, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const= uint8_t *config_data, int config_len) > =A0{ > =A0 =A0 struct save_file_header hdr; > @@ -2618,13 +2625,13 @@ static void save_domain_core_writeconfig > =A0 =A0 /* that's the optional data */ > > =A0 =A0 CHK_ERRNO( libxl_write_exactly(ctx, fd, > - =A0 =A0 =A0 =A0&hdr, sizeof(hdr), filename, "header") ); > + =A0 =A0 =A0 =A0&hdr, sizeof(hdr), source, "header") ); > =A0 =A0 CHK_ERRNO( libxl_write_exactly(ctx, fd, > - =A0 =A0 =A0 =A0optdata_begin, hdr.optional_data_len, filename, "header"= ) ); > + =A0 =A0 =A0 =A0optdata_begin, hdr.optional_data_len, source, "header") = ); > > =A0 =A0 fprintf(stderr, "Saving to %s new xl format (info" > =A0 =A0 =A0 =A0 =A0 =A0 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", > - =A0 =A0 =A0 =A0 =A0 =A0filename, hdr.mandatory_flags, hdr.optional_flag= s, > + =A0 =A0 =A0 =A0 =A0 =A0source, hdr.mandatory_flags, hdr.optional_flags, > =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len); > =A0} > > @@ -2950,7 +2957,6 @@ static void migrate_receive(int debug, i > =A0 =A0 dom_info.daemonize =3D daemonize; > =A0 =A0 dom_info.monitor =3D monitor; > =A0 =A0 dom_info.paused =3D 1; > - =A0 =A0dom_info.restore_file =3D "incoming migration stream"; > =A0 =A0 dom_info.migrate_fd =3D 0; /* stdin */ > =A0 =A0 dom_info.migration_domname_r =3D &migration_domname; > =A0 =A0 dom_info.incr_generationid =3D 0; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:50:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09: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 ) id 1SQF9H-0001FU-NP; Fri, 04 May 2012 09:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQF9G-0001FK-4Z for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:50:02 +0000 Received: from [85.158.139.83:5479] by server-7.bemta-5.messagelabs.com id 92/26-16195-946A3AF4; Fri, 04 May 2012 09:50:01 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336124998!26058053!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20462 invoked from network); 4 May 2012 09:49:59 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 09:49:59 -0000 Received: by qcsp15 with SMTP id p15so2265077qcs.30 for ; Fri, 04 May 2012 02:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9O5g+1zrZKUrzK+kpYvRsU0AimjrFK57kGo3FnCqkWM=; b=PXT57YQ1Rq35DvKd7bOsPgFMyQP5x7CzucF49h9gWr3z2IQjIib3xmVwaS9ng3NYXQ vM4oVCdE9fr6YtfFLGNh6SFafQfcsEzmKP7+23sxqOZCX6vY7N7yYkU0+7qK3ekiHe7P TnkxfqTg/BtBu3Rt800SgG2esKTCtdyYHB51vwZvIaqbFJm1CT9bwnuZoAwZj4HV9+Kd DWdg/KF4XnnG29UzDpcq/ulNtGLO1AiNc8P0FFgMjk967OR4KeiFrbHuccGUmb/zD8Kl P6r2P7OX+6Q1at0kqQokxycX5iWY1m3uz3gKmjBmc10mjNDuGpLNwovdQ0blCoLaC+bc A5WQ== MIME-Version: 1.0 Received: by 10.224.173.210 with SMTP id q18mr9031923qaz.11.1336124998231; Fri, 04 May 2012 02:49:58 -0700 (PDT) Received: by 10.229.44.145 with HTTP; Fri, 4 May 2012 02:49:58 -0700 (PDT) In-Reply-To: <60013c9b8d62e39988db.1335971423@kodo2> References: <60013c9b8d62e39988db.1335971423@kodo2> Date: Fri, 4 May 2012 10:49:58 +0100 X-Google-Sender-Auth: 2XXuqZfX8XvBHRBm1YHu-FRfGiw Message-ID: From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: Re: [Xen-devel] [PATCH 2 of 2] xl: Make clear distinction between "filename" and "data source" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hmm -- sorry, I seemed so have mucked some things up on the rebase... please don't apply this one. -George On Wed, May 2, 2012 at 4:10 PM, George Dunlap wrote: > # HG changeset patch > # User George Dunlap > # Date 1335971129 -3600 > # Node ID 60013c9b8d62e39988db3c5b22c0510f5557756b > # Parent =A0c3eda4333f1562d68c8b56ae3ef9d73e6b68d873 > xl: Make clear distinction between "filename" and "data source" > > Many places in xl there's a variable or element named "filename" which > does not contain a filename, but the source of the data for reporting > purposes. =A0Worse, there are variables which are sometimes actually > used or interpreted as a filename depending on what other variables > are set. =A0This makes it difficult to tell when a string is purely > cosmetic, and when another bit of code may actually attempt to call > "open" with the string. > > This patch makes a consistent distinction between "filename" (which > always refers to the name of an actual file, and may be interpreted as > such at some point) and "source" (which may be a filename, or may be > another data source such as a migration stream or saved data). > > This does add some variables and reshuffle where assignments happen; > most notably, the "restore_filename" element of struct domain_create > is now only set when restoring from a file. > > But at a high level, there should be no funcitonal changes. > > Signed-off-by: George Dunlap > > diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/libxl_utils.c > --- a/tools/libxl/libxl_utils.c Wed May 02 16:05:26 2012 +0100 > +++ b/tools/libxl/libxl_utils.c Wed May 02 16:05:29 2012 +0100 > @@ -334,7 +334,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= \ > =A0 int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constdata void *da= ta, ssize_t sz, =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *filenam= e, const char *what) { =A0 =A0 =A0\ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const char *source,= const char *what) { =A0 =A0 =A0\ > =A0 =A0 =A0 ssize_t got; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= \ > =A0 =A0 =A0 while (sz > 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > @@ -343,7 +343,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (errno =3D=3D EINTR) continue; =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!ctx) return errno; =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fail= ed to " #rw " %s%s%s", \ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?= " from ":"", filename); =A0 =A0 \ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?= " from ":"", source); =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return errno; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 if (got =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > @@ -352,7 +352,7 @@ int libxl_read_file_contents(libxl_ctx * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zero_is_eof =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0? "file/stream truncated readi= ng %s%s%s" =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "file/stream write returned = 0! writing %s%s%s", =A0 =A0\ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?" from ":"",= filename); =A0 =A0 =A0 =A0 =A0 \ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 what?what:"", what?" from ":"",= source); =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return EPROTO; =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0 =A0 sz -=3D got; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > diff -r c3eda4333f15 -r 60013c9b8d62 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c =A0Wed May 02 16:05:26 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c =A0Wed May 02 16:05:29 2012 +0100 > @@ -520,9 +520,9 @@ vcpp_out: > =A0 =A0 return rc; > =A0} > > -static void parse_config_data(const char *configfile_filename_report, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *= configfile_data, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int configfi= le_len, > +static void parse_config_data(const char *config_source, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *= config_data, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int config_l= en, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_domain_= config *d_config) > =A0{ > =A0 =A0 const char *buf; > @@ -537,15 +537,15 @@ static void parse_config_data(const char > =A0 =A0 libxl_domain_create_info *c_info =3D &d_config->c_info; > =A0 =A0 libxl_domain_build_info *b_info =3D &d_config->b_info; > > - =A0 =A0config=3D xlu_cfg_init(stderr, configfile_filename_report); > + =A0 =A0config=3D xlu_cfg_init(stderr, config_source); > =A0 =A0 if (!config) { > =A0 =A0 =A0 =A0 fprintf(stderr, "Failed to allocate for configuration\n"); > =A0 =A0 =A0 =A0 exit(1); > =A0 =A0 } > > - =A0 =A0e=3D xlu_cfg_readdata(config, configfile_data, configfile_len); > + =A0 =A0e=3D xlu_cfg_readdata(config, config_data, config_len); > =A0 =A0 if (e) { > - =A0 =A0 =A0 =A0fprintf(stderr, "Failed to parse config file: %s\n", str= error(e)); > + =A0 =A0 =A0 =A0fprintf(stderr, "Failed to parse config: %s\n", strerror= (e)); > =A0 =A0 =A0 =A0 exit(1); > =A0 =A0 } > > @@ -1522,6 +1522,8 @@ static int create_domain(struct domain_c > =A0 =A0 const char *config_file =3D dom_info->config_file; > =A0 =A0 const char *extra_config =3D dom_info->extra_config; > =A0 =A0 const char *restore_file =3D dom_info->restore_file; > + =A0 =A0const char *config_source =3D NULL; > + =A0 =A0const char *restore_source =3D NULL; > =A0 =A0 int migrate_fd =3D dom_info->migrate_fd; > > =A0 =A0 int i; > @@ -1537,24 +1539,28 @@ static int create_domain(struct domain_c > =A0 =A0 pid_t child_console_pid =3D -1; > =A0 =A0 struct save_file_header hdr; > > + =A0 =A0int restoring =3D (restore_file || (migrate_fd >=3D 0)); > + > =A0 =A0 libxl_domain_config_init(&d_config); > > - =A0 =A0if (restore_file) { > + =A0 =A0if (restoring) { > =A0 =A0 =A0 =A0 uint8_t *optdata_begin =3D 0; > =A0 =A0 =A0 =A0 const uint8_t *optdata_here =3D 0; > =A0 =A0 =A0 =A0 union { uint32_t u32; char b[4]; } u32buf; > =A0 =A0 =A0 =A0 uint32_t badflags; > > =A0 =A0 =A0 =A0 if (migrate_fd >=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0restore_source =3D "" > =A0 =A0 =A0 =A0 =A0 =A0 restore_fd =3D migrate_fd; > =A0 =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0restore_source =3D restore_file; > =A0 =A0 =A0 =A0 =A0 =A0 restore_fd =3D open(restore_file, O_RDONLY); > =A0 =A0 =A0 =A0 =A0 =A0 rc =3D libxl_fd_set_cloexec(ctx, restore_fd, 1); > =A0 =A0 =A0 =A0 =A0 =A0 if (rc) return rc; > =A0 =A0 =A0 =A0 } > > =A0 =A0 =A0 =A0 CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sizeof(hdr), restore_file, "header"= ) ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sizeof(hdr), restore_source, "heade= r") ); > =A0 =A0 =A0 =A0 if (memcmp(hdr.magic, savefileheader_magic, sizeof(hdr.ma= gic))) { > =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "File has wrong magic number -" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " corrupt or for a different tool= ?\n"); > @@ -1567,7 +1573,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 fprintf(stderr, "Loading new save file %s" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " (new xl fmt info" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0restore_file, hdr.mandatory_flags, hdr.o= ptional_flags, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0restore_source, hdr.mandatory_flags, hdr= .optional_flags, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len); > > =A0 =A0 =A0 =A0 badflags =3D hdr.mandatory_flags & ~( 0 /* none understoo= d yet */ ); > @@ -1580,7 +1586,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 if (hdr.optional_data_len) { > =A0 =A0 =A0 =A0 =A0 =A0 optdata_begin =3D xmalloc(hdr.optional_data_len); > =A0 =A0 =A0 =A0 =A0 =A0 CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, op= tdata_begin, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len, restore_file= , "optdata") ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len, restore_sour= ce, "optdata") ); > =A0 =A0 =A0 =A0 } > > =A0#define OPTDATA_LEFT =A0(hdr.optional_data_len - (optdata_here - optda= ta_begin)) > @@ -1615,7 +1621,7 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0&config_data, &config_len); > =A0 =A0 =A0 =A0 if (ret) { fprintf(stderr, "Failed to read config file: %= s: %s\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0config_file, strer= ror(errno)); return ERROR_FAIL; } > - =A0 =A0 =A0 =A0if (!restore_file && extra_config && strlen(extra_config= )) { > + =A0 =A0 =A0 =A0if (!restoring && extra_config && strlen(extra_config)) { > =A0 =A0 =A0 =A0 =A0 =A0 if (config_len > INT_MAX - (strlen(extra_config) = + 2 + 1)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "Failed to attach extra c= onfigration\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_FAIL; > @@ -1630,19 +1636,20 @@ static int create_domain(struct domain_c > =A0 =A0 =A0 =A0 =A0 =A0 config_len +=3D sprintf(config_data + config_len,= "\n%s\n", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extra_config); > =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0config_source=3Dconfig_file; > =A0 =A0 } else { > =A0 =A0 =A0 =A0 if (!config_data) { > =A0 =A0 =A0 =A0 =A0 =A0 fprintf(stderr, "Config file not specified and" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " none in save file\n"); > =A0 =A0 =A0 =A0 =A0 =A0 return ERROR_INVAL; > =A0 =A0 =A0 =A0 } > - =A0 =A0 =A0 =A0config_file =3D ""; > + =A0 =A0 =A0 =A0config_source =3D ""; > =A0 =A0 } > > =A0 =A0 if (!dom_info->quiet) > - =A0 =A0 =A0 =A0printf("Parsing config file %s\n", config_file); > - > - =A0 =A0parse_config_data(config_file, config_data, config_len, &d_confi= g); > + =A0 =A0 =A0 =A0printf("Parsing config from %s\n", config_source); > + > + =A0 =A0parse_config_data(config_source, config_data, config_len, &d_con= fig); > > =A0 =A0 if (migrate_fd >=3D 0) { > =A0 =A0 =A0 =A0 if (d_config.c_info.name) { > @@ -1693,7 +1700,7 @@ start: > =A0 =A0 =A0 =A0 cb =3D NULL; > =A0 =A0 } > > - =A0 =A0if ( restore_file ) { > + =A0 =A0if ( restoring ) { > =A0 =A0 =A0 =A0 ret =3D libxl_domain_create_restore(ctx, &d_config, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 cb, &child_console_pid, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 &domid, restore_fd); > @@ -2469,7 +2476,7 @@ static void list_domains_details(const l > =A0{ > =A0 =A0 libxl_domain_config d_config; > > - =A0 =A0char *config_file; > + =A0 =A0char *config_source; > =A0 =A0 uint8_t *data; > =A0 =A0 int i, len, rc; > > @@ -2480,13 +2487,13 @@ static void list_domains_details(const l > =A0 =A0 =A0 =A0 rc =3D libxl_userdata_retrieve(ctx, info[i].domid, "xl", = &data, &len); > =A0 =A0 =A0 =A0 if (rc) > =A0 =A0 =A0 =A0 =A0 =A0 continue; > - =A0 =A0 =A0 =A0CHK_ERRNO(asprintf(&config_file, "", info= [i].domid)); > + =A0 =A0 =A0 =A0CHK_ERRNO(asprintf(&config_source, "", in= fo[i].domid)); > =A0 =A0 =A0 =A0 libxl_domain_config_init(&d_config); > - =A0 =A0 =A0 =A0parse_config_data(config_file, (char *)data, len, &d_con= fig); > + =A0 =A0 =A0 =A0parse_config_data(config_source, (char *)data, len, &d_c= onfig); > =A0 =A0 =A0 =A0 printf_info(default_output_format, info[i].domid, &d_conf= ig); > =A0 =A0 =A0 =A0 libxl_domain_config_dispose(&d_config); > =A0 =A0 =A0 =A0 free(data); > - =A0 =A0 =A0 =A0free(config_file); > + =A0 =A0 =A0 =A0free(config_source); > =A0 =A0 } > =A0} > > @@ -2589,7 +2596,7 @@ static void save_domain_core_begin(const > =A0 =A0 } > =A0} > > -static void save_domain_core_writeconfig(int fd, const char *filename, > +static void save_domain_core_writeconfig(int fd, const char *source, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const= uint8_t *config_data, int config_len) > =A0{ > =A0 =A0 struct save_file_header hdr; > @@ -2618,13 +2625,13 @@ static void save_domain_core_writeconfig > =A0 =A0 /* that's the optional data */ > > =A0 =A0 CHK_ERRNO( libxl_write_exactly(ctx, fd, > - =A0 =A0 =A0 =A0&hdr, sizeof(hdr), filename, "header") ); > + =A0 =A0 =A0 =A0&hdr, sizeof(hdr), source, "header") ); > =A0 =A0 CHK_ERRNO( libxl_write_exactly(ctx, fd, > - =A0 =A0 =A0 =A0optdata_begin, hdr.optional_data_len, filename, "header"= ) ); > + =A0 =A0 =A0 =A0optdata_begin, hdr.optional_data_len, source, "header") = ); > > =A0 =A0 fprintf(stderr, "Saving to %s new xl format (info" > =A0 =A0 =A0 =A0 =A0 =A0 " 0x%"PRIx32"/0x%"PRIx32"/%"PRIu32")\n", > - =A0 =A0 =A0 =A0 =A0 =A0filename, hdr.mandatory_flags, hdr.optional_flag= s, > + =A0 =A0 =A0 =A0 =A0 =A0source, hdr.mandatory_flags, hdr.optional_flags, > =A0 =A0 =A0 =A0 =A0 =A0 hdr.optional_data_len); > =A0} > > @@ -2950,7 +2957,6 @@ static void migrate_receive(int debug, i > =A0 =A0 dom_info.daemonize =3D daemonize; > =A0 =A0 dom_info.monitor =3D monitor; > =A0 =A0 dom_info.paused =3D 1; > - =A0 =A0dom_info.restore_file =3D "incoming migration stream"; > =A0 =A0 dom_info.migrate_fd =3D 0; /* stdin */ > =A0 =A0 dom_info.migration_domname_r =3D &migration_domname; > =A0 =A0 dom_info.incr_generationid =3D 0; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:54:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:54:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFDm-0001Vz-Sc; Fri, 04 May 2012 09:54:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFDl-0001Vt-Da for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:54:41 +0000 Received: from [85.158.143.99:9407] by server-2.bemta-4.messagelabs.com id 81/E0-17550-067A3AF4; Fri, 04 May 2012 09:54:40 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336125279!25565955!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3715 invoked from network); 4 May 2012 09:54:39 -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; 4 May 2012 09:54:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12293722" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:54: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, 4 May 2012 10:54:38 +0100 Date: Fri, 4 May 2012 10:54:23 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "Vinaya MS (MT2010166)" In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> , User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012, Vinaya MS (MT2010166) wrote: > Stefano Stabellini eu.citrix.com> writes: > > > Are you using xm or xl? > I'm using xm. > > > Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? > modprobe pciback says fatal error. > xen-pciback.hide does not hide pci device. If I am not mistaken Ubuntu 11.04 comes with Linux 2.6.38 that is too old to have CONFIG_XEN_PCIDEV_BACKEND: if you are using the default Ubuntu 11.04 kernel as dom0 kernel CONFIG_XEN_PCIDEV_BACKEND is not going to work. > > Try assigning something that is not a graphic card, do you see the > > device if you execute lspci? > Nope. I get a error Error: Timed out waiting for device model action > > > Is it your primary graphic card? > Yes it was a primary card.Now I inserted another card [quadro 570] > which is acting as primary card. > > Now, i'm able to passthrough c2050 card. But on assigning them I get a msg > Error: Timed out waiting for device model action Could you please post QEMU's logs (/var/log/xen/qemu-dm-name*.log)? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 09:54:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 09:54:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFDm-0001Vz-Sc; Fri, 04 May 2012 09:54:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFDl-0001Vt-Da for xen-devel@lists.xensource.com; Fri, 04 May 2012 09:54:41 +0000 Received: from [85.158.143.99:9407] by server-2.bemta-4.messagelabs.com id 81/E0-17550-067A3AF4; Fri, 04 May 2012 09:54:40 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336125279!25565955!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3715 invoked from network); 4 May 2012 09:54:39 -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; 4 May 2012 09:54:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12293722" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:54: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, 4 May 2012 10:54:38 +0100 Date: Fri, 4 May 2012 10:54:23 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "Vinaya MS (MT2010166)" In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> , User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012, Vinaya MS (MT2010166) wrote: > Stefano Stabellini eu.citrix.com> writes: > > > Are you using xm or xl? > I'm using xm. > > > Why do you say that CONFIG_XEN_PCIDEV_BACKEND is not working for you? > modprobe pciback says fatal error. > xen-pciback.hide does not hide pci device. If I am not mistaken Ubuntu 11.04 comes with Linux 2.6.38 that is too old to have CONFIG_XEN_PCIDEV_BACKEND: if you are using the default Ubuntu 11.04 kernel as dom0 kernel CONFIG_XEN_PCIDEV_BACKEND is not going to work. > > Try assigning something that is not a graphic card, do you see the > > device if you execute lspci? > Nope. I get a error Error: Timed out waiting for device model action > > > Is it your primary graphic card? > Yes it was a primary card.Now I inserted another card [quadro 570] > which is acting as primary card. > > Now, i'm able to passthrough c2050 card. But on assigning them I get a msg > Error: Timed out waiting for device model action Could you please post QEMU's logs (/var/log/xen/qemu-dm-name*.log)? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:06:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:06:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFPF-00026y-OM; Fri, 04 May 2012 10:06:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFPD-00026t-R9 for xen-devel@lists.xen.org; Fri, 04 May 2012 10:06:32 +0000 Received: from [85.158.143.99:9122] by server-3.bemta-4.messagelabs.com id 64/F0-05853-72AA3AF4; Fri, 04 May 2012 10:06:31 +0000 X-Env-Sender: gabrielx.wu@intel.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336125989!20092386!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI5MTkw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32044 invoked from network); 4 May 2012 10:06:30 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-10.tower-216.messagelabs.com with SMTP; 4 May 2012 10:06:30 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 04 May 2012 03:06:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96337615" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 04 May 2012 03:06:29 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 May 2012 03:06:28 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Fri, 4 May 2012 18:06:27 +0800 From: "Wu, GabrielX" To: "xen-devel@lists.xen.org" Thread-Topic: VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKd2RIykB5nZwyk2zCq36bhIDaw== Date: Fri, 4 May 2012 10:06:26 +0000 Message-ID: References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, This is the test report of xen-unstable tree. There are one bug found. Version Info: ================================================================= xen-changeset: 25256 Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) ================================================================= New issue(1) ============== 1. cpu weight out of range error when create hvm domU http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 Fixed issue(0) ============== Old issues(8) ============== 1. [ACPI] System cann't resume after do suspend http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 2. [XL]"xl vcpu-set" causes dom0 crash or panic http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 3. [VT-D]fail to detach NIC from guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 5. [VT-D] device reset fail when create/destroy guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 7. RHEL6.2/6.1 guest runs quite slow http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 8. after detaching a VF from a guest, shutdown the guest is very slow http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 Thanks, Wu Ronghui(Gabriel) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:06:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:06:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFPF-00026y-OM; Fri, 04 May 2012 10:06:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFPD-00026t-R9 for xen-devel@lists.xen.org; Fri, 04 May 2012 10:06:32 +0000 Received: from [85.158.143.99:9122] by server-3.bemta-4.messagelabs.com id 64/F0-05853-72AA3AF4; Fri, 04 May 2012 10:06:31 +0000 X-Env-Sender: gabrielx.wu@intel.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336125989!20092386!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI5MTkw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32044 invoked from network); 4 May 2012 10:06:30 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-10.tower-216.messagelabs.com with SMTP; 4 May 2012 10:06:30 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 04 May 2012 03:06:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96337615" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 04 May 2012 03:06:29 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 May 2012 03:06:28 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Fri, 4 May 2012 18:06:27 +0800 From: "Wu, GabrielX" To: "xen-devel@lists.xen.org" Thread-Topic: VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKd2RIykB5nZwyk2zCq36bhIDaw== Date: Fri, 4 May 2012 10:06:26 +0000 Message-ID: References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, This is the test report of xen-unstable tree. There are one bug found. Version Info: ================================================================= xen-changeset: 25256 Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) ================================================================= New issue(1) ============== 1. cpu weight out of range error when create hvm domU http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 Fixed issue(0) ============== Old issues(8) ============== 1. [ACPI] System cann't resume after do suspend http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 2. [XL]"xl vcpu-set" causes dom0 crash or panic http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 3. [VT-D]fail to detach NIC from guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 5. [VT-D] device reset fail when create/destroy guest http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 7. RHEL6.2/6.1 guest runs quite slow http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 8. after detaching a VF from a guest, shutdown the guest is very slow http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 Thanks, Wu Ronghui(Gabriel) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:20:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:20:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFbu-0002hb-O5; Fri, 04 May 2012 10:19:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFbu-0002hV-0z for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:19:38 +0000 Received: from [85.158.143.99:57610] by server-3.bemta-4.messagelabs.com id A1/F2-05853-93DA3AF4; Fri, 04 May 2012 10:19:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336126776!25570236!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25253 invoked from network); 4 May 2012 10:19:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:19:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12294379" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:19:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:19:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQFbs-0000kR-B5; Fri, 04 May 2012 10:19:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQFbs-0001MI-9a; Fri, 04 May 2012 11:19:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20387.44344.187553.704998@mariner.uk.xensource.com> Date: Fri, 4 May 2012 11:19:36 +0100 To: Olaf Hering In-Reply-To: <20120504092819.GA10010@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > will just crate and apply a second patch to use LDLIBS. Thanks. I have done the revert. I don't know why I didn't spot this when I was reviewing and applying 25142:c5b7d49ca3ee in the first place. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:20:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:20:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFbu-0002hb-O5; Fri, 04 May 2012 10:19:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFbu-0002hV-0z for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:19:38 +0000 Received: from [85.158.143.99:57610] by server-3.bemta-4.messagelabs.com id A1/F2-05853-93DA3AF4; Fri, 04 May 2012 10:19:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336126776!25570236!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25253 invoked from network); 4 May 2012 10:19:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:19:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12294379" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:19:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:19:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQFbs-0000kR-B5; Fri, 04 May 2012 10:19:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQFbs-0001MI-9a; Fri, 04 May 2012 11:19:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20387.44344.187553.704998@mariner.uk.xensource.com> Date: Fri, 4 May 2012 11:19:36 +0100 To: Olaf Hering In-Reply-To: <20120504092819.GA10010@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > will just crate and apply a second patch to use LDLIBS. Thanks. I have done the revert. I don't know why I didn't spot this when I was reviewing and applying 25142:c5b7d49ca3ee in the first place. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:26:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:26:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFiU-0002ut-JZ; Fri, 04 May 2012 10:26:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFiT-0002un-H8 for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:26:25 +0000 Received: from [193.109.254.147:28560] by server-10.bemta-14.messagelabs.com id 3B/1A-05847-0DEA3AF4; Fri, 04 May 2012 10:26:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1336127171!757819!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11085 invoked from network); 4 May 2012 10:26:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 10:26:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo55) (RZmta 29.1 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y0031ao44A49SX ; Fri, 4 May 2012 12:26:11 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A2C9718637; Fri, 4 May 2012 12:26:10 +0200 (CEST) Date: Fri, 4 May 2012 12:26:10 +0200 From: Olaf Hering To: Ian Jackson Message-ID: <20120504102610.GA22031@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20387.44344.187553.704998@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > > will just crate and apply a second patch to use LDLIBS. > > Thanks. I have done the revert. I don't know why I didn't spot this > when I was reviewing and applying 25142:c5b7d49ca3ee in the first > place. Oh, you did. But unfortunately I convinced myself and you that my change is ok. Sorry again for that. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:26:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:26:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFiU-0002ut-JZ; Fri, 04 May 2012 10:26:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFiT-0002un-H8 for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:26:25 +0000 Received: from [193.109.254.147:28560] by server-10.bemta-14.messagelabs.com id 3B/1A-05847-0DEA3AF4; Fri, 04 May 2012 10:26:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1336127171!757819!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11085 invoked from network); 4 May 2012 10:26:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 10:26:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo55) (RZmta 29.1 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y0031ao44A49SX ; Fri, 4 May 2012 12:26:11 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A2C9718637; Fri, 4 May 2012 12:26:10 +0200 (CEST) Date: Fri, 4 May 2012 12:26:10 +0200 From: Olaf Hering To: Ian Jackson Message-ID: <20120504102610.GA22031@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20387.44344.187553.704998@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > > will just crate and apply a second patch to use LDLIBS. > > Thanks. I have done the revert. I don't know why I didn't spot this > when I was reviewing and applying 25142:c5b7d49ca3ee in the first > place. Oh, you did. But unfortunately I convinced myself and you that my change is ok. Sorry again for that. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:28:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:28:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFjx-0002zO-2n; Fri, 04 May 2012 10:27:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFjv-0002zG-LA for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:27:55 +0000 Received: from [193.109.254.147:51916] by server-1.bemta-14.messagelabs.com id 30/58-29372-A2FA3AF4; Fri, 04 May 2012 10:27:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336127274!7628001!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24160 invoked from network); 4 May 2012 10:27:54 -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; 4 May 2012 10:27:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12294591" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:27: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, 4 May 2012 11:27:53 +0100 Message-ID: <1336127272.2361.42.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 11:27:52 +0100 In-Reply-To: <20387.44344.187553.704998@mariner.uk.xensource.com> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 11:19 +0100, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > > will just crate and apply a second patch to use LDLIBS. > > Thanks. I have done the revert. I don't know why I didn't spot this > when I was reviewing and applying 25142:c5b7d49ca3ee in the first > place. FWIW we don't build vTPM by default so you wouldn't have noticed the actual failure. Perhaps the test system should enable non-default things like this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:28:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:28:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFjx-0002zO-2n; Fri, 04 May 2012 10:27:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFjv-0002zG-LA for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:27:55 +0000 Received: from [193.109.254.147:51916] by server-1.bemta-14.messagelabs.com id 30/58-29372-A2FA3AF4; Fri, 04 May 2012 10:27:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336127274!7628001!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24160 invoked from network); 4 May 2012 10:27:54 -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; 4 May 2012 10:27:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12294591" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:27: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, 4 May 2012 11:27:53 +0100 Message-ID: <1336127272.2361.42.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 11:27:52 +0100 In-Reply-To: <20387.44344.187553.704998@mariner.uk.xensource.com> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 11:19 +0100, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] vTPM patch does not apply"): > > Reverting c5b7d49ca3ee is ok. I will send another patch on top which > > will just crate and apply a second patch to use LDLIBS. > > Thanks. I have done the revert. I don't know why I didn't spot this > when I was reviewing and applying 25142:c5b7d49ca3ee in the first > place. FWIW we don't build vTPM by default so you wouldn't have noticed the actual failure. Perhaps the test system should enable non-default things like this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:28:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10: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 ) id 1SQFkY-00032f-G5; Fri, 04 May 2012 10:28:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFkX-00032Z-Tt for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:28:34 +0000 Received: from [85.158.139.83:4181] by server-10.bemta-5.messagelabs.com id E1/4D-08260-15FA3AF4; Fri, 04 May 2012 10:28:33 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-11.tower-182.messagelabs.com!1336127311!19518202!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21268 invoked from network); 4 May 2012 10:28:32 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 10:28:32 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQFkU-0005Pn-Ex for xen-devel@lists.xensource.com; Fri, 04 May 2012 12:28:30 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 12:28:30 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 12:28:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Fri, 4 May 2012 10:28:21 +0000 (UTC) Lines: 12 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If I am not mistaken Ubuntu 11.04 comes with Linux 2.6.38 that is too old to have CONFIG_XEN_PCIDEV_BACKEND: if you are using the default Ubuntu 11.04 kernel as dom0 kernel CONFIG_XEN_PCIDEV_BACKEND is not going to work. I'm not using default kernel. I have downloaded kernel 2.6.32.40 pv from http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=2b494f184d3337d10d59226e3632af56ea66629a and have followed http://wiki.xensource.com/xenwiki/XenParavirtOps to configure the kernel. I had grub2 issue which I resolved by installing legacy grub. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:28:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10: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 ) id 1SQFkY-00032f-G5; Fri, 04 May 2012 10:28:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFkX-00032Z-Tt for xen-devel@lists.xensource.com; Fri, 04 May 2012 10:28:34 +0000 Received: from [85.158.139.83:4181] by server-10.bemta-5.messagelabs.com id E1/4D-08260-15FA3AF4; Fri, 04 May 2012 10:28:33 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-11.tower-182.messagelabs.com!1336127311!19518202!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21268 invoked from network); 4 May 2012 10:28:32 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 10:28:32 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQFkU-0005Pn-Ex for xen-devel@lists.xensource.com; Fri, 04 May 2012 12:28:30 +0200 Received: from static.bangaore.mp.59.90.239.152/21.bsnl.in ([static.bangaore.mp.59.90.239.152/21.bsnl.in]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 12:28:30 +0200 Received: from vinaya.ms by static.bangaore.mp.59.90.239.152/21.bsnl.in with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 12:28:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Vinaya M S Date: Fri, 4 May 2012 10:28:21 +0000 (UTC) Lines: 12 Message-ID: References: <4E65F794.6060705@gmail.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 59.90.239.152 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0) Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If I am not mistaken Ubuntu 11.04 comes with Linux 2.6.38 that is too old to have CONFIG_XEN_PCIDEV_BACKEND: if you are using the default Ubuntu 11.04 kernel as dom0 kernel CONFIG_XEN_PCIDEV_BACKEND is not going to work. I'm not using default kernel. I have downloaded kernel 2.6.32.40 pv from http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=2b494f184d3337d10d59226e3632af56ea66629a and have followed http://wiki.xensource.com/xenwiki/XenParavirtOps to configure the kernel. I had grub2 issue which I resolved by installing legacy grub. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:39:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQFuo-0003Rv-Mk; Fri, 04 May 2012 10:39:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFun-0003Rn-EH for Xen-devel@lists.xen.org; Fri, 04 May 2012 10:39:09 +0000 Received: from [85.158.143.35:64515] by server-3.bemta-4.messagelabs.com id 32/0D-05853-CC1B3AF4; Fri, 04 May 2012 10:39:08 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336127945!14138650!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8466 invoked from network); 4 May 2012 10:39:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:39:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859190" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 06:39:04 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 06:39:04 -0400 Message-ID: <4FA3B1C7.4060201@citrix.com> Date: Fri, 4 May 2012 11:39:03 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Philipp Hahn References: <201205041054.04079.hahn@univention.de> In-Reply-To: <201205041054.04079.hahn@univention.de> Cc: Thomas Gleixner , Jeremy Fitzhardinge , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 09:54, Philipp Hahn wrote: > Hello, > > I encountered the following bug when migrating a Linux-2.6.32.54 PV domain on > Xen-3.4.3 between different hosts, whose uptime differs by several minutes (3 > hosts, each ~5 minutes apart): When migrating from a host with lower uptime > to a host with higher uptime, the VM looses it's network connection for some > time and then continues after some minutes (roughly equivalent to the > difference in uptime?). > There are two different symptoms: Either the VM becomes unpingable, or the VM > is pingable but the ssh-connection freezes: a while-loop dumping /proc/uptime > freezes and continues without a jump after the freeze is over. Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power Management CPUID leaf it will pass this through to the guest which makes the guest think the TSC is stable. Can you try this libxc patch? 8<------------------------ libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf Even if the TSC is constant on a host, it won't be constant across a migrate. Signed-off-by: David Vrabel Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQFuo-0003Rv-Mk; Fri, 04 May 2012 10:39:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQFun-0003Rn-EH for Xen-devel@lists.xen.org; Fri, 04 May 2012 10:39:09 +0000 Received: from [85.158.143.35:64515] by server-3.bemta-4.messagelabs.com id 32/0D-05853-CC1B3AF4; Fri, 04 May 2012 10:39:08 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336127945!14138650!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8466 invoked from network); 4 May 2012 10:39:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:39:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859190" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 06:39:04 -0400 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 06:39:04 -0400 Message-ID: <4FA3B1C7.4060201@citrix.com> Date: Fri, 4 May 2012 11:39:03 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Philipp Hahn References: <201205041054.04079.hahn@univention.de> In-Reply-To: <201205041054.04079.hahn@univention.de> Cc: Thomas Gleixner , Jeremy Fitzhardinge , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 09:54, Philipp Hahn wrote: > Hello, > > I encountered the following bug when migrating a Linux-2.6.32.54 PV domain on > Xen-3.4.3 between different hosts, whose uptime differs by several minutes (3 > hosts, each ~5 minutes apart): When migrating from a host with lower uptime > to a host with higher uptime, the VM looses it's network connection for some > time and then continues after some minutes (roughly equivalent to the > difference in uptime?). > There are two different symptoms: Either the VM becomes unpingable, or the VM > is pingable but the ssh-connection freezes: a while-loop dumping /proc/uptime > freezes and continues without a jump after the freeze is over. Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power Management CPUID leaf it will pass this through to the guest which makes the guest think the TSC is stable. Can you try this libxc patch? 8<------------------------ libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf Even if the TSC is constant on a host, it won't be constant across a migrate. Signed-off-by: David Vrabel Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:49:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG4S-0003f8-Qh; Fri, 04 May 2012 10:49:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG4S-0003f3-2t for Xen-devel@lists.xensource.com; Fri, 04 May 2012 10:49:08 +0000 Received: from [85.158.143.99:47667] by server-2.bemta-4.messagelabs.com id 52/3B-17550-324B3AF4; Fri, 04 May 2012 10:49:07 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-15.tower-216.messagelabs.com!1336128546!26463880!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15130 invoked from network); 4 May 2012 10:49:06 -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; 4 May 2012 10:49:06 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQG4M-0001dw-V9; Fri, 04 May 2012 10:49:02 +0000 Date: Fri, 4 May 2012 11:49:02 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504104902.GA6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 10:08 +0100 on 04 May (1336126102), Ian Campbell wrote: > What does the guest EFLAGS actually contain at this point? Is it > different to what it contains on non-hybrid dom0? > > How do we execute 16 bit code in a VMX guest these days, using vm86 or > by emulation? Both, and also sometimes neither. :) If the chip supports it, we just run in real mode inside the VM (this is called "unrestricted guest" in the VMX code and will be reported in the Xen boot messages). Otherwise we run in vm86 when we can, and emulate things that vm86 doesn't support, and all I/O. We also have to emulate when the segment state is wierd (e.g., big-real-mode) because the VMENTER into vm86 has stricter checks on segment state than actual real mode. > How does that interact with EFLAGS_ID I wonder (although > why hybrid dom0 would have any bearing on this I've no idea). I'm not aware of anything deliberately tinkering with EFLAGS_ID, but it's possible that vm86 interacts with it (of that we accidentally lose some parts of EFLAGS in emulation). Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:49:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:49:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG4S-0003f8-Qh; Fri, 04 May 2012 10:49:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG4S-0003f3-2t for Xen-devel@lists.xensource.com; Fri, 04 May 2012 10:49:08 +0000 Received: from [85.158.143.99:47667] by server-2.bemta-4.messagelabs.com id 52/3B-17550-324B3AF4; Fri, 04 May 2012 10:49:07 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-15.tower-216.messagelabs.com!1336128546!26463880!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15130 invoked from network); 4 May 2012 10:49:06 -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; 4 May 2012 10:49:06 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQG4M-0001dw-V9; Fri, 04 May 2012 10:49:02 +0000 Date: Fri, 4 May 2012 11:49:02 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504104902.GA6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 10:08 +0100 on 04 May (1336126102), Ian Campbell wrote: > What does the guest EFLAGS actually contain at this point? Is it > different to what it contains on non-hybrid dom0? > > How do we execute 16 bit code in a VMX guest these days, using vm86 or > by emulation? Both, and also sometimes neither. :) If the chip supports it, we just run in real mode inside the VM (this is called "unrestricted guest" in the VMX code and will be reported in the Xen boot messages). Otherwise we run in vm86 when we can, and emulate things that vm86 doesn't support, and all I/O. We also have to emulate when the segment state is wierd (e.g., big-real-mode) because the VMENTER into vm86 has stricter checks on segment state than actual real mode. > How does that interact with EFLAGS_ID I wonder (although > why hybrid dom0 would have any bearing on this I've no idea). I'm not aware of anything deliberately tinkering with EFLAGS_ID, but it's possible that vm86 interacts with it (of that we accidentally lose some parts of EFLAGS in emulation). Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:52:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10: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 ) id 1SQG7o-0003p4-Id; Fri, 04 May 2012 10:52:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG7m-0003or-Tt for xen-devel@lists.xen.org; Fri, 04 May 2012 10:52:35 +0000 Received: from [85.158.143.35:11016] by server-2.bemta-4.messagelabs.com id F1/7F-17550-2F4B3AF4; Fri, 04 May 2012 10:52:34 +0000 X-Env-Sender: accept.acm@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336128750!7536365!1 X-Originating-IP: [209.85.210.42] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20247 invoked from network); 4 May 2012 10:52:33 -0000 Received: from mail-pz0-f42.google.com (HELO mail-pz0-f42.google.com) (209.85.210.42) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:52:33 -0000 Received: by dalf4 with SMTP id f4so189153dal.29 for ; Fri, 04 May 2012 03:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=yW2FclpYJSf/TdxGuVyG8FaIMYKASqwIlilqMWXe3lk=; b=gIif48zj084DYo7X8CbFbpYeWdFnllzIL3Nl3ehkvgSLdPc6zGbk9o4AwXN76EE7R7 XUfh90n9cro0vQFmL2gxo4fJAkLgv+sT+Mq5lmXddFlCFylYElPHESCbkNwEHPtdFF29 eGVC70x1f5i6utflo+67AdpZQM6se6wC/prrYv6g4BzjEriBfU1Kkw7JJfkm+ZNYFHqT GyVa0Tg7KaOcKqvckYQ/24rhP5aKnre+E0chyaM4uzyQv4xLa49zn5SD9ga+QgbswHr4 Af/O+4x4lMd7JAx38+7kvc1S7myZwElmo9d92joHb4oa+ZdACOuMXV27g71Sd274k/01 fk7A== Received: by 10.68.221.194 with SMTP id qg2mr46663pbc.18.1336128750625; Fri, 04 May 2012 03:52:30 -0700 (PDT) Received: from [10.30.0.13] ([159.226.43.35]) by mx.google.com with ESMTPS id gv2sm8277406pbc.73.2012.05.04.03.52.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 03:52:30 -0700 (PDT) From: wang zhihao Date: Fri, 4 May 2012 18:52:27 +0800 Message-Id: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> To: xen-devel Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Ian Jackson Subject: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi All I try to test flight 12785 job test-amd64-amd64-xl on my own machine. I download kerndist.tar.gz , dist.tar.gz and xendist.tar.gz from logfiles generated by job build-amd64-pvops and build-amd64. But there is no clue on how to get a root file system. So I try Ubuntu 11.10 as its rootfs, which is ext3 format. Unfortunately, it complains the . So which root file system should I use? Any help are appreciated. Regards Wang zhihao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:52:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10: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 ) id 1SQG7o-0003p4-Id; Fri, 04 May 2012 10:52:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG7m-0003or-Tt for xen-devel@lists.xen.org; Fri, 04 May 2012 10:52:35 +0000 Received: from [85.158.143.35:11016] by server-2.bemta-4.messagelabs.com id F1/7F-17550-2F4B3AF4; Fri, 04 May 2012 10:52:34 +0000 X-Env-Sender: accept.acm@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336128750!7536365!1 X-Originating-IP: [209.85.210.42] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20247 invoked from network); 4 May 2012 10:52:33 -0000 Received: from mail-pz0-f42.google.com (HELO mail-pz0-f42.google.com) (209.85.210.42) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:52:33 -0000 Received: by dalf4 with SMTP id f4so189153dal.29 for ; Fri, 04 May 2012 03:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=yW2FclpYJSf/TdxGuVyG8FaIMYKASqwIlilqMWXe3lk=; b=gIif48zj084DYo7X8CbFbpYeWdFnllzIL3Nl3ehkvgSLdPc6zGbk9o4AwXN76EE7R7 XUfh90n9cro0vQFmL2gxo4fJAkLgv+sT+Mq5lmXddFlCFylYElPHESCbkNwEHPtdFF29 eGVC70x1f5i6utflo+67AdpZQM6se6wC/prrYv6g4BzjEriBfU1Kkw7JJfkm+ZNYFHqT GyVa0Tg7KaOcKqvckYQ/24rhP5aKnre+E0chyaM4uzyQv4xLa49zn5SD9ga+QgbswHr4 Af/O+4x4lMd7JAx38+7kvc1S7myZwElmo9d92joHb4oa+ZdACOuMXV27g71Sd274k/01 fk7A== Received: by 10.68.221.194 with SMTP id qg2mr46663pbc.18.1336128750625; Fri, 04 May 2012 03:52:30 -0700 (PDT) Received: from [10.30.0.13] ([159.226.43.35]) by mx.google.com with ESMTPS id gv2sm8277406pbc.73.2012.05.04.03.52.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 03:52:30 -0700 (PDT) From: wang zhihao Date: Fri, 4 May 2012 18:52:27 +0800 Message-Id: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> To: xen-devel Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Ian Jackson Subject: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi All I try to test flight 12785 job test-amd64-amd64-xl on my own machine. I download kerndist.tar.gz , dist.tar.gz and xendist.tar.gz from logfiles generated by job build-amd64-pvops and build-amd64. But there is no clue on how to get a root file system. So I try Ubuntu 11.10 as its rootfs, which is ext3 format. Unfortunately, it complains the . So which root file system should I use? Any help are appreciated. Regards Wang zhihao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:54:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:54:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG9L-0003vs-2Y; Fri, 04 May 2012 10:54:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG9J-0003vh-0e for Xen-devel@lists.xensource.com; Fri, 04 May 2012 10:54:09 +0000 Received: from [85.158.143.99:16864] by server-3.bemta-4.messagelabs.com id 9A/C0-05853-055B3AF4; Fri, 04 May 2012 10:54:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336128847!21206950!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30403 invoked from network); 4 May 2012 10:54:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:54:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295145" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:53:28 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:53:28 +0100 Message-ID: <1336128807.2361.56.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Fri, 4 May 2012 11:53:27 +0100 In-Reply-To: <20120504104902.GA6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 11:49 +0100, Tim Deegan wrote: > At 10:08 +0100 on 04 May (1336126102), Ian Campbell wrote: > > What does the guest EFLAGS actually contain at this point? Is it > > different to what it contains on non-hybrid dom0? > > > > How do we execute 16 bit code in a VMX guest these days, using vm86 or > > by emulation? > > Both, and also sometimes neither. :) Of course ;-) > If the chip supports it, we just run in real mode inside the VM (this is > called "unrestricted guest" in the VMX code and will be reported in the > Xen boot messages). Thanks, I thought this had been added but didn't know the name of the feature. > Otherwise we run in vm86 when we can, and emulate things that vm86 > doesn't support, and all I/O. We also have to emulate when the segment > state is wierd (e.g., big-real-mode) because the VMENTER into vm86 has > stricter checks on segment state than actual real mode. > > > How does that interact with EFLAGS_ID I wonder (although > > why hybrid dom0 would have any bearing on this I've no idea). > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, I couldn't find any use other than the definition, although it maybe open coded somewhere. > but > it's possible that vm86 interacts with it (of that we accidentally lose > some parts of EFLAGS in emulation). Yeah, but I can't figure out why hybrid dom0 would change that... Ian, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:54:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:54:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG9L-0003vs-2Y; Fri, 04 May 2012 10:54:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQG9J-0003vh-0e for Xen-devel@lists.xensource.com; Fri, 04 May 2012 10:54:09 +0000 Received: from [85.158.143.99:16864] by server-3.bemta-4.messagelabs.com id 9A/C0-05853-055B3AF4; Fri, 04 May 2012 10:54:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336128847!21206950!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30403 invoked from network); 4 May 2012 10:54:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 10:54:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295145" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:53:28 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:53:28 +0100 Message-ID: <1336128807.2361.56.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Fri, 4 May 2012 11:53:27 +0100 In-Reply-To: <20120504104902.GA6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 11:49 +0100, Tim Deegan wrote: > At 10:08 +0100 on 04 May (1336126102), Ian Campbell wrote: > > What does the guest EFLAGS actually contain at this point? Is it > > different to what it contains on non-hybrid dom0? > > > > How do we execute 16 bit code in a VMX guest these days, using vm86 or > > by emulation? > > Both, and also sometimes neither. :) Of course ;-) > If the chip supports it, we just run in real mode inside the VM (this is > called "unrestricted guest" in the VMX code and will be reported in the > Xen boot messages). Thanks, I thought this had been added but didn't know the name of the feature. > Otherwise we run in vm86 when we can, and emulate things that vm86 > doesn't support, and all I/O. We also have to emulate when the segment > state is wierd (e.g., big-real-mode) because the VMENTER into vm86 has > stricter checks on segment state than actual real mode. > > > How does that interact with EFLAGS_ID I wonder (although > > why hybrid dom0 would have any bearing on this I've no idea). > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, I couldn't find any use other than the definition, although it maybe open coded somewhere. > but > it's possible that vm86 interacts with it (of that we accidentally lose > some parts of EFLAGS in emulation). Yeah, but I can't figure out why hybrid dom0 would change that... Ian, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:57:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:57:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGCF-00046q-Ko; Fri, 04 May 2012 10:57:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGCE-00046d-Aa for xen-devel@lists.xen.org; Fri, 04 May 2012 10:57:10 +0000 Received: from [85.158.143.35:32501] by server-1.bemta-4.messagelabs.com id 11/4A-20925-506B3AF4; Fri, 04 May 2012 10:57:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336129028!14141326!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2283 invoked from network); 4 May 2012 10:57: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; 4 May 2012 10:57:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295210" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:57:07 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:57:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQGCB-00012g-Da; Fri, 04 May 2012 10:57:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQGCB-0001Pg-Bv; Fri, 04 May 2012 11:57:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20387.46595.198406.571329@mariner.uk.xensource.com> Date: Fri, 4 May 2012 11:57:07 +0100 To: wang zhihao In-Reply-To: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org wang zhihao writes ("How to select a rootfs to test job test-amd64-amd64-xl on my own machine ?"): > I try to test flight 12785 job test-amd64-amd64-xl on my own machine. I download kerndist.tar.gz , dist.tar.gz and xendist.tar.gz from logfiles generated by job build-amd64-pvops and build-amd64. > But there is no clue on how to get a root file system. So I try Ubuntu 11.10 as its rootfs, which is ext3 format. Unfortunately, it complains the . > So which root file system should I use? You mean how does the guest get created ? It is generated each time using the Debian "xen-tools" package, specifically xen-create-image. See the logs for "ts-debian-install" and "ts-debian-fixup" which show the commands the tester executed. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 10:57:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 10:57:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGCF-00046q-Ko; Fri, 04 May 2012 10:57:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGCE-00046d-Aa for xen-devel@lists.xen.org; Fri, 04 May 2012 10:57:10 +0000 Received: from [85.158.143.35:32501] by server-1.bemta-4.messagelabs.com id 11/4A-20925-506B3AF4; Fri, 04 May 2012 10:57:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336129028!14141326!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2283 invoked from network); 4 May 2012 10:57: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; 4 May 2012 10:57:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295210" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 10:57:07 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:57:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQGCB-00012g-Da; Fri, 04 May 2012 10:57:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQGCB-0001Pg-Bv; Fri, 04 May 2012 11:57:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20387.46595.198406.571329@mariner.uk.xensource.com> Date: Fri, 4 May 2012 11:57:07 +0100 To: wang zhihao In-Reply-To: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org wang zhihao writes ("How to select a rootfs to test job test-amd64-amd64-xl on my own machine ?"): > I try to test flight 12785 job test-amd64-amd64-xl on my own machine. I download kerndist.tar.gz , dist.tar.gz and xendist.tar.gz from logfiles generated by job build-amd64-pvops and build-amd64. > But there is no clue on how to get a root file system. So I try Ubuntu 11.10 as its rootfs, which is ext3 format. Unfortunately, it complains the . > So which root file system should I use? You mean how does the guest get created ? It is generated each time using the Debian "xen-tools" package, specifically xen-create-image. See the logs for "ts-debian-install" and "ts-debian-fixup" which show the commands the tester executed. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:03:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGHo-0004LC-FH; Fri, 04 May 2012 11:02:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGHn-0004L4-2q for xen-devel@lists.xen.org; Fri, 04 May 2012 11:02:55 +0000 Received: from [85.158.139.83:49816] by server-9.bemta-5.messagelabs.com id 7B/53-09826-E57B3AF4; Fri, 04 May 2012 11:02:54 +0000 X-Env-Sender: accept.acm@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336129371!26754202!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21971 invoked from network); 4 May 2012 11:02:53 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:02:53 -0000 Received: by pbbro12 with SMTP id ro12so4006969pbb.32 for ; Fri, 04 May 2012 04:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GeXUnEXPUxnbWk1eZYM3p2N01h9mDu2LvVtxk1oy7Gg=; b=WNSAYij6NM1tGcrR8qSHmhC1qXjhe82pzZP6p9t5Ykv22qajT2H1LvumN1qipb6MB9 LI2XkOYUP8uALr6r8uG2HN8AfaHbkBFL8AXtG4DrkdRkHUuggsQBhaC68WJKZKL6hRmo qvmC3Hh5yaCFT4rGZfOJ9CQ/CpZfxtyk++JBrHz54Eapsowup+27nJVadSwSX3bwSvPc nS/dya09LrGAO+Pd0jLyPUI3r1mGtfXmfcP4BQt+CQdmo0EAlrBySv3xZtclBqkUBbcD CWWkXFig2miE8DyGJiP6qE/p/fc2+CPGbz+3+AbtcQ4Gd4a2rsg/aZaBXZCsY8Gcuvwc vyCA== Received: by 10.68.72.70 with SMTP id b6mr8950519pbv.58.1336129370711; Fri, 04 May 2012 04:02:50 -0700 (PDT) Received: from [10.30.0.13] ([159.226.43.35]) by mx.google.com with ESMTPS id pp8sm8303627pbb.21.2012.05.04.04.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 04:02:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: wang zhihao In-Reply-To: <20387.46595.198406.571329@mariner.uk.xensource.com> Date: Fri, 4 May 2012 19:02:47 +0800 Message-Id: <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> <20387.46595.198406.571329@mariner.uk.xensource.com> To: xen-devel X-Mailer: Apple Mail (2.1084) Cc: Ian Jackson Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org SGksIElhbgoK1NogMjAxMi01LTSjrM/Czuc2OjU3o6wgSWFuIEphY2tzb24g0LS1wKO6Cj4gWW91 IG1lYW4gaG93IGRvZXMgdGhlIGd1ZXN0IGdldCBjcmVhdGVkID8KCkkgbWVhbiBob3cgdG8gc2Vs ZWN0IHRoZSBkb20wJ3Mgcm9vdCBmaWxlc3lzdGVtLgoKUmVnYXJkcwpXYW5nIFpoaWhhbwoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv eGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 04 11:03:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGHo-0004LC-FH; Fri, 04 May 2012 11:02:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGHn-0004L4-2q for xen-devel@lists.xen.org; Fri, 04 May 2012 11:02:55 +0000 Received: from [85.158.139.83:49816] by server-9.bemta-5.messagelabs.com id 7B/53-09826-E57B3AF4; Fri, 04 May 2012 11:02:54 +0000 X-Env-Sender: accept.acm@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336129371!26754202!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21971 invoked from network); 4 May 2012 11:02:53 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:02:53 -0000 Received: by pbbro12 with SMTP id ro12so4006969pbb.32 for ; Fri, 04 May 2012 04:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GeXUnEXPUxnbWk1eZYM3p2N01h9mDu2LvVtxk1oy7Gg=; b=WNSAYij6NM1tGcrR8qSHmhC1qXjhe82pzZP6p9t5Ykv22qajT2H1LvumN1qipb6MB9 LI2XkOYUP8uALr6r8uG2HN8AfaHbkBFL8AXtG4DrkdRkHUuggsQBhaC68WJKZKL6hRmo qvmC3Hh5yaCFT4rGZfOJ9CQ/CpZfxtyk++JBrHz54Eapsowup+27nJVadSwSX3bwSvPc nS/dya09LrGAO+Pd0jLyPUI3r1mGtfXmfcP4BQt+CQdmo0EAlrBySv3xZtclBqkUBbcD CWWkXFig2miE8DyGJiP6qE/p/fc2+CPGbz+3+AbtcQ4Gd4a2rsg/aZaBXZCsY8Gcuvwc vyCA== Received: by 10.68.72.70 with SMTP id b6mr8950519pbv.58.1336129370711; Fri, 04 May 2012 04:02:50 -0700 (PDT) Received: from [10.30.0.13] ([159.226.43.35]) by mx.google.com with ESMTPS id pp8sm8303627pbb.21.2012.05.04.04.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 04:02:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: wang zhihao In-Reply-To: <20387.46595.198406.571329@mariner.uk.xensource.com> Date: Fri, 4 May 2012 19:02:47 +0800 Message-Id: <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> <20387.46595.198406.571329@mariner.uk.xensource.com> To: xen-devel X-Mailer: Apple Mail (2.1084) Cc: Ian Jackson Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org SGksIElhbgoK1NogMjAxMi01LTSjrM/Czuc2OjU3o6wgSWFuIEphY2tzb24g0LS1wKO6Cj4gWW91 IG1lYW4gaG93IGRvZXMgdGhlIGd1ZXN0IGdldCBjcmVhdGVkID8KCkkgbWVhbiBob3cgdG8gc2Vs ZWN0IHRoZSBkb20wJ3Mgcm9vdCBmaWxlc3lzdGVtLgoKUmVnYXJkcwpXYW5nIFpoaWhhbwoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv eGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 04 11:06:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGKm-0004VF-1n; Fri, 04 May 2012 11:06:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGKk-0004V8-5y for xen-devel@lists.xen.org; Fri, 04 May 2012 11:05:58 +0000 Received: from [85.158.139.83:29807] by server-9.bemta-5.messagelabs.com id EF/5D-09826-518B3AF4; Fri, 04 May 2012 11:05:57 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336129556!15489527!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30566 invoked from network); 4 May 2012 11:05:56 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 11:05:56 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:05:56 +0100 Message-Id: <4FA3D4320200007800081987@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:05:54 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 11:40, Keir Fraser wrote: > On 04/05/2012 10:12, "Jan Beulich" wrote: > >>>>> On 04.05.12 at 10:25, Keir Fraser wrote: >>> On 04/05/2012 09:18, "Jan Beulich" wrote: >>>> does this really need to be a per-CPU variable? Can't a timer run only >>>> once at a time on the entire system (the more that it gets re-armed only >>>> at the end of the poll function, whereas the variable is consumed at the >>>> start), and hence the variable can be a simple one? Or else, what >>>> subtlety am I overlooking? >>> >>> We set up a timer per initialised uart. There can be more than one (although >>> granted it is rare). >> >> Is that actually useful? console.c can't really use more than one at a >> time (for there being a single sercon_handle), so perhaps it would be >> a good thing to avoid the setup for those that aren't actively used, >> e.g. by not calling ->init_postirq() for other than the used one? >> >> Oh, wait, with crash_debug there can be a second call to >> serial_parse_handle(), so in that case serial console and gdb stub >> may run through different ports. With crash_debug off by default, >> wouldn't it make sense to optimize for that common case, so that >> specifying both "com1=" and "com2=" on the command line wouldn't >> needlessly consume resources (as serial_parse_handle() can easily >> tag which ports it got called for)? Or would you rather take the >> position of expecting people to remove unnecessary command line >> options, or live with them having side effects? > > I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes > per CPU of the poll_port variable isn't worth much optimising effort. Certainly not (and as you say they are actually needed, even if only rarely). But the pointlessly running timer(s) might be, as might the buffer(s) set up via serial_async_transmit(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:06:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGKm-0004VF-1n; Fri, 04 May 2012 11:06:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGKk-0004V8-5y for xen-devel@lists.xen.org; Fri, 04 May 2012 11:05:58 +0000 Received: from [85.158.139.83:29807] by server-9.bemta-5.messagelabs.com id EF/5D-09826-518B3AF4; Fri, 04 May 2012 11:05:57 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336129556!15489527!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30566 invoked from network); 4 May 2012 11:05:56 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 11:05:56 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:05:56 +0100 Message-Id: <4FA3D4320200007800081987@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:05:54 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 11:40, Keir Fraser wrote: > On 04/05/2012 10:12, "Jan Beulich" wrote: > >>>>> On 04.05.12 at 10:25, Keir Fraser wrote: >>> On 04/05/2012 09:18, "Jan Beulich" wrote: >>>> does this really need to be a per-CPU variable? Can't a timer run only >>>> once at a time on the entire system (the more that it gets re-armed only >>>> at the end of the poll function, whereas the variable is consumed at the >>>> start), and hence the variable can be a simple one? Or else, what >>>> subtlety am I overlooking? >>> >>> We set up a timer per initialised uart. There can be more than one (although >>> granted it is rare). >> >> Is that actually useful? console.c can't really use more than one at a >> time (for there being a single sercon_handle), so perhaps it would be >> a good thing to avoid the setup for those that aren't actively used, >> e.g. by not calling ->init_postirq() for other than the used one? >> >> Oh, wait, with crash_debug there can be a second call to >> serial_parse_handle(), so in that case serial console and gdb stub >> may run through different ports. With crash_debug off by default, >> wouldn't it make sense to optimize for that common case, so that >> specifying both "com1=" and "com2=" on the command line wouldn't >> needlessly consume resources (as serial_parse_handle() can easily >> tag which ports it got called for)? Or would you rather take the >> position of expecting people to remove unnecessary command line >> options, or live with them having side effects? > > I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes > per CPU of the poll_port variable isn't worth much optimising effort. Certainly not (and as you say they are actually needed, even if only rarely). But the pointlessly running timer(s) might be, as might the buffer(s) set up via serial_async_transmit(). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:12:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGRD-0004m9-Sn; Fri, 04 May 2012 11:12:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGRD-0004m4-CR for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:12:39 +0000 Received: from [85.158.143.99:11166] by server-2.bemta-4.messagelabs.com id 74/AA-17550-6A9B3AF4; Fri, 04 May 2012 11:12:38 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336129958!25925472!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26732 invoked from network); 4 May 2012 11:12:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:12:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295579" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:12: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; Fri, 4 May 2012 12:12:37 +0100 Date: Fri, 4 May 2012 12:12:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "xen-devel@lists.xensource.com" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Ian Jackson , Ian Campbell , Stefano Stabellini Subject: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, this patch implements local_attach support for QDISK: that means that you can use qcow2 as disk format for your PV guests disks and use pygrub to retrieve the kernel and initrd in dom0. The idea is that we start a QEMU instance at boot time to listen to local_attach requests. When libxl_device_disk_local_attach is called on a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk so that blkfront in dom0 will create a new xvd device for it. Then pygrub can be pointed at this device to retrieve kernel and initrd. Changes in v5: - remove _hidden from the libxl_device_disk_local_attach/detach implementation; - libxl__device_disk_local_attach: rename disk to in_disk; - libxl__device_disk_local_attach: rename tmpdisk to disk; - libxl__device_disk_local_attach: copy disk to new_disk only on success; - libxl__device_disk_local_attach: remove check on libxl__zalloc success. - rename libxl__device_generic_add_t to libxl__device_generic_add; - change the type of the blkdev_start parameter to libxl__device_disk_local_attach to const char *; - remove domid paramter to libxl__alloc_vdev (assume LIBXL_TOOLSTACK_DOMID); - remove scaling limit from libxl__alloc_vdev; - libxl__device_disk_local_attach: replace LIBXL__LOG with LOG; - libxl__device_disk_local_attach: unify error paths. Changes in v4: - split the first patch into 2 patches: the first is a simple move, the second one adds a new parameter; - libxl__device_generic_add: do not end the transaction is the caller provided it; - libxl__device_generic_add: fix success exit path; - pass blkdev_start in libxl_domain_build_info; - rename libxl__devid_to_vdev to libxl__devid_to_localdev; - introduce upper bound for encode_disk_name; - improve error handling and exit paths in libxl__alloc_vdev and libxl__device_disk_local_attach. Changes in v3: - libxl__device_disk_local_attach: wait for the backend to be "connected" before returning. Changes in v2: - make libxl_device_disk_local_(de)attach internal functions; - allocate the new disk in libxl_device_disk_local_attatch on the GC; - remove libxl__device_generic_add_t, add a transaction parameter to libxl__device_generic_add instead; - add a new patch to introduce a blkdev_start option to xl.conf; - reimplement libxl__alloc_vdev checking for the frontend path and starting from blkdev_start; - introduce a Linux specific libxl__devid_to_vdev function based on last Jan's patch to blkfront. Stefano Stabellini (8): libxl: make libxl_device_disk_local_attach/detach internal functions libxl: libxl__device_disk_local_attach return a new libxl_device_disk libxl: add a transaction parameter to libxl__device_generic_add libxl: introduce libxl__device_disk_add xl/libxl: add a blkdev_start parameter libxl: introduce libxl__alloc_vdev xl/libxl: implement QDISK libxl_device_disk_local_attach libxl__device_disk_local_attach: wait for state "connected" tools/examples/xl.conf | 3 + tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + tools/hotplug/Linux/init.d/xencommons | 3 + tools/libxl/libxl.c | 232 +---------------- tools/libxl/libxl.h | 7 - tools/libxl/libxl_bootloader.c | 11 +- tools/libxl/libxl_create.c | 3 + tools/libxl/libxl_device.c | 17 +- tools/libxl/libxl_internal.c | 319 +++++++++++++++++++++++ tools/libxl/libxl_internal.h | 25 ++- tools/libxl/libxl_linux.c | 45 ++++ tools/libxl/libxl_netbsd.c | 6 + tools/libxl/libxl_pci.c | 2 +- tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 3 + tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 2 + 17 files changed, 435 insertions(+), 248 deletions(-) Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:12:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGRD-0004m9-Sn; Fri, 04 May 2012 11:12:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGRD-0004m4-CR for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:12:39 +0000 Received: from [85.158.143.99:11166] by server-2.bemta-4.messagelabs.com id 74/AA-17550-6A9B3AF4; Fri, 04 May 2012 11:12:38 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336129958!25925472!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26732 invoked from network); 4 May 2012 11:12:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:12:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295579" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:12: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; Fri, 4 May 2012 12:12:37 +0100 Date: Fri, 4 May 2012 12:12:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "xen-devel@lists.xensource.com" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Ian Jackson , Ian Campbell , Stefano Stabellini Subject: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, this patch implements local_attach support for QDISK: that means that you can use qcow2 as disk format for your PV guests disks and use pygrub to retrieve the kernel and initrd in dom0. The idea is that we start a QEMU instance at boot time to listen to local_attach requests. When libxl_device_disk_local_attach is called on a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk so that blkfront in dom0 will create a new xvd device for it. Then pygrub can be pointed at this device to retrieve kernel and initrd. Changes in v5: - remove _hidden from the libxl_device_disk_local_attach/detach implementation; - libxl__device_disk_local_attach: rename disk to in_disk; - libxl__device_disk_local_attach: rename tmpdisk to disk; - libxl__device_disk_local_attach: copy disk to new_disk only on success; - libxl__device_disk_local_attach: remove check on libxl__zalloc success. - rename libxl__device_generic_add_t to libxl__device_generic_add; - change the type of the blkdev_start parameter to libxl__device_disk_local_attach to const char *; - remove domid paramter to libxl__alloc_vdev (assume LIBXL_TOOLSTACK_DOMID); - remove scaling limit from libxl__alloc_vdev; - libxl__device_disk_local_attach: replace LIBXL__LOG with LOG; - libxl__device_disk_local_attach: unify error paths. Changes in v4: - split the first patch into 2 patches: the first is a simple move, the second one adds a new parameter; - libxl__device_generic_add: do not end the transaction is the caller provided it; - libxl__device_generic_add: fix success exit path; - pass blkdev_start in libxl_domain_build_info; - rename libxl__devid_to_vdev to libxl__devid_to_localdev; - introduce upper bound for encode_disk_name; - improve error handling and exit paths in libxl__alloc_vdev and libxl__device_disk_local_attach. Changes in v3: - libxl__device_disk_local_attach: wait for the backend to be "connected" before returning. Changes in v2: - make libxl_device_disk_local_(de)attach internal functions; - allocate the new disk in libxl_device_disk_local_attatch on the GC; - remove libxl__device_generic_add_t, add a transaction parameter to libxl__device_generic_add instead; - add a new patch to introduce a blkdev_start option to xl.conf; - reimplement libxl__alloc_vdev checking for the frontend path and starting from blkdev_start; - introduce a Linux specific libxl__devid_to_vdev function based on last Jan's patch to blkfront. Stefano Stabellini (8): libxl: make libxl_device_disk_local_attach/detach internal functions libxl: libxl__device_disk_local_attach return a new libxl_device_disk libxl: add a transaction parameter to libxl__device_generic_add libxl: introduce libxl__device_disk_add xl/libxl: add a blkdev_start parameter libxl: introduce libxl__alloc_vdev xl/libxl: implement QDISK libxl_device_disk_local_attach libxl__device_disk_local_attach: wait for state "connected" tools/examples/xl.conf | 3 + tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + tools/hotplug/Linux/init.d/xencommons | 3 + tools/libxl/libxl.c | 232 +---------------- tools/libxl/libxl.h | 7 - tools/libxl/libxl_bootloader.c | 11 +- tools/libxl/libxl_create.c | 3 + tools/libxl/libxl_device.c | 17 +- tools/libxl/libxl_internal.c | 319 +++++++++++++++++++++++ tools/libxl/libxl_internal.h | 25 ++- tools/libxl/libxl_linux.c | 45 ++++ tools/libxl/libxl_netbsd.c | 6 + tools/libxl/libxl_pci.c | 2 +- tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 3 + tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 2 + 17 files changed, 435 insertions(+), 248 deletions(-) Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:13:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS3-0004oi-AZ; Fri, 04 May 2012 11:13:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS2-0004ob-5R for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:30 +0000 Received: from [85.158.143.99:16269] by server-1.bemta-4.messagelabs.com id 58/F0-20925-9D9B3AF4; Fri, 04 May 2012 11:13:29 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336130007!25579432!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29383 invoked from network); 4 May 2012 11:13:28 -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; 4 May 2012 11:13:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193395759" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:27 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:26 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-51; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:13 +0100 Message-ID: <1336130000-27261-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 1/8] libxl: make libxl_device_disk_local_attach/detach internal functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Changes in v5: - remove _hidden from the implementation. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- tools/libxl/libxl.c | 73 ---------------------------------------- tools/libxl/libxl.h | 7 ---- tools/libxl/libxl_bootloader.c | 4 +- tools/libxl/libxl_internal.c | 72 +++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 9 +++++ 5 files changed, 83 insertions(+), 82 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 9984d46..1357efc 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1664,79 +1664,6 @@ out: return ret; } -char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk) -{ - GC_INIT(ctx); - char *dev = NULL; - char *ret = NULL; - int rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s", - disk->pdev_path); - dev = disk->pdev_path; - break; - case LIBXL_DISK_BACKEND_TAP: - switch (disk->format) { - case LIBXL_DISK_FORMAT_RAW: - /* optimise away the early tapdisk attach in this case */ - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching" - " tap disk %s directly (ie without using blktap)", - disk->pdev_path); - dev = disk->pdev_path; - break; - case LIBXL_DISK_FORMAT_VHD: - dev = libxl__blktap_devpath(gc, disk->pdev_path, - disk->format); - break; - case LIBXL_DISK_FORMAT_QCOW: - case LIBXL_DISK_FORMAT_QCOW2: - abort(); /* prevented by libxl__device_disk_set_backend */ - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "unrecognized disk format: %d", disk->format); - break; - } - break; - case LIBXL_DISK_BACKEND_QDISK: - if (disk->format != LIBXL_DISK_FORMAT_RAW) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" - " attach a qdisk image if the format is not raw"); - break; - } - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - disk->pdev_path); - dev = disk->pdev_path; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " - "type: %d", disk->backend); - break; - } - - out: - if (dev != NULL) - ret = strdup(dev); - GC_FREE; - return ret; -} - -int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk) -{ - /* Nothing to do for PHYSTYPE_PHY. */ - - /* - * For other device types assume that the blktap2 process is - * needed by the soon to be started domain and do nothing. - */ - - return 0; -} - /******************************************************************************/ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d59f0ee..79d5679 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -619,13 +619,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, */ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); -/* - * Make a disk available in this (the control) domain. Returns path to - * a device. - */ -char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); -int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); - /* Network Interfaces */ 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, diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 2774062..977c6d3 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -386,7 +386,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl_device_disk_local_attach(ctx, disk); + diskpath = libxl__device_disk_local_attach(gc, disk); if (!diskpath) { goto out_close; } @@ -453,7 +453,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, rc = 0; out_close: if (diskpath) { - libxl_device_disk_local_detach(ctx, disk); + libxl__device_disk_local_detach(gc, disk); free(diskpath); } if (fifo_fd > -1) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index b89aef7..fc771ff 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,6 +323,78 @@ out: return rc; } +char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) +{ + libxl_ctx *ctx = gc->owner; + char *dev = NULL; + char *ret = NULL; + int rc; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s", + disk->pdev_path); + dev = disk->pdev_path; + break; + case LIBXL_DISK_BACKEND_TAP: + switch (disk->format) { + case LIBXL_DISK_FORMAT_RAW: + /* optimise away the early tapdisk attach in this case */ + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching" + " tap disk %s directly (ie without using blktap)", + disk->pdev_path); + dev = disk->pdev_path; + break; + case LIBXL_DISK_FORMAT_VHD: + dev = libxl__blktap_devpath(gc, disk->pdev_path, + disk->format); + break; + case LIBXL_DISK_FORMAT_QCOW: + case LIBXL_DISK_FORMAT_QCOW2: + abort(); /* prevented by libxl__device_disk_set_backend */ + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "unrecognized disk format: %d", disk->format); + break; + } + break; + case LIBXL_DISK_BACKEND_QDISK: + if (disk->format != LIBXL_DISK_FORMAT_RAW) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" + " attach a qdisk image if the format is not raw"); + break; + } + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", + disk->pdev_path); + dev = disk->pdev_path; + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " + "type: %d", disk->backend); + break; + } + + out: + if (dev != NULL) + ret = strdup(dev); + return ret; +} + +int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) +{ + /* Nothing to do for PHYSTYPE_PHY. */ + + /* + * For other device types assume that the blktap2 process is + * needed by the soon to be started domain and do nothing. + */ + + return 0; +} + libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc, uint32_t domid) { diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 34ea15c..ddd6a37 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1003,6 +1003,15 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, */ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); +/* + * Make a disk available in this (the control) domain. Returns path to + * a device. + */ +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, + libxl_device_disk *disk); +_hidden int libxl__device_disk_local_detach(libxl__gc *gc, + libxl_device_disk *disk); + _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid); struct libxl__xen_console_reader { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:13:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS3-0004oi-AZ; Fri, 04 May 2012 11:13:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS2-0004ob-5R for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:30 +0000 Received: from [85.158.143.99:16269] by server-1.bemta-4.messagelabs.com id 58/F0-20925-9D9B3AF4; Fri, 04 May 2012 11:13:29 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336130007!25579432!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29383 invoked from network); 4 May 2012 11:13:28 -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; 4 May 2012 11:13:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193395759" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:27 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:26 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-51; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:13 +0100 Message-ID: <1336130000-27261-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 1/8] libxl: make libxl_device_disk_local_attach/detach internal functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Changes in v5: - remove _hidden from the implementation. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- tools/libxl/libxl.c | 73 ---------------------------------------- tools/libxl/libxl.h | 7 ---- tools/libxl/libxl_bootloader.c | 4 +- tools/libxl/libxl_internal.c | 72 +++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 9 +++++ 5 files changed, 83 insertions(+), 82 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 9984d46..1357efc 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1664,79 +1664,6 @@ out: return ret; } -char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk) -{ - GC_INIT(ctx); - char *dev = NULL; - char *ret = NULL; - int rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s", - disk->pdev_path); - dev = disk->pdev_path; - break; - case LIBXL_DISK_BACKEND_TAP: - switch (disk->format) { - case LIBXL_DISK_FORMAT_RAW: - /* optimise away the early tapdisk attach in this case */ - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching" - " tap disk %s directly (ie without using blktap)", - disk->pdev_path); - dev = disk->pdev_path; - break; - case LIBXL_DISK_FORMAT_VHD: - dev = libxl__blktap_devpath(gc, disk->pdev_path, - disk->format); - break; - case LIBXL_DISK_FORMAT_QCOW: - case LIBXL_DISK_FORMAT_QCOW2: - abort(); /* prevented by libxl__device_disk_set_backend */ - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "unrecognized disk format: %d", disk->format); - break; - } - break; - case LIBXL_DISK_BACKEND_QDISK: - if (disk->format != LIBXL_DISK_FORMAT_RAW) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" - " attach a qdisk image if the format is not raw"); - break; - } - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - disk->pdev_path); - dev = disk->pdev_path; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " - "type: %d", disk->backend); - break; - } - - out: - if (dev != NULL) - ret = strdup(dev); - GC_FREE; - return ret; -} - -int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk) -{ - /* Nothing to do for PHYSTYPE_PHY. */ - - /* - * For other device types assume that the blktap2 process is - * needed by the soon to be started domain and do nothing. - */ - - return 0; -} - /******************************************************************************/ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d59f0ee..79d5679 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -619,13 +619,6 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid, */ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); -/* - * Make a disk available in this (the control) domain. Returns path to - * a device. - */ -char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); -int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); - /* Network Interfaces */ 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, diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 2774062..977c6d3 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -386,7 +386,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl_device_disk_local_attach(ctx, disk); + diskpath = libxl__device_disk_local_attach(gc, disk); if (!diskpath) { goto out_close; } @@ -453,7 +453,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, rc = 0; out_close: if (diskpath) { - libxl_device_disk_local_detach(ctx, disk); + libxl__device_disk_local_detach(gc, disk); free(diskpath); } if (fifo_fd > -1) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index b89aef7..fc771ff 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,6 +323,78 @@ out: return rc; } +char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) +{ + libxl_ctx *ctx = gc->owner; + char *dev = NULL; + char *ret = NULL; + int rc; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s", + disk->pdev_path); + dev = disk->pdev_path; + break; + case LIBXL_DISK_BACKEND_TAP: + switch (disk->format) { + case LIBXL_DISK_FORMAT_RAW: + /* optimise away the early tapdisk attach in this case */ + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching" + " tap disk %s directly (ie without using blktap)", + disk->pdev_path); + dev = disk->pdev_path; + break; + case LIBXL_DISK_FORMAT_VHD: + dev = libxl__blktap_devpath(gc, disk->pdev_path, + disk->format); + break; + case LIBXL_DISK_FORMAT_QCOW: + case LIBXL_DISK_FORMAT_QCOW2: + abort(); /* prevented by libxl__device_disk_set_backend */ + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "unrecognized disk format: %d", disk->format); + break; + } + break; + case LIBXL_DISK_BACKEND_QDISK: + if (disk->format != LIBXL_DISK_FORMAT_RAW) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" + " attach a qdisk image if the format is not raw"); + break; + } + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", + disk->pdev_path); + dev = disk->pdev_path; + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " + "type: %d", disk->backend); + break; + } + + out: + if (dev != NULL) + ret = strdup(dev); + return ret; +} + +int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) +{ + /* Nothing to do for PHYSTYPE_PHY. */ + + /* + * For other device types assume that the blktap2 process is + * needed by the soon to be started domain and do nothing. + */ + + return 0; +} + libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc, uint32_t domid) { diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 34ea15c..ddd6a37 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1003,6 +1003,15 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, */ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); +/* + * Make a disk available in this (the control) domain. Returns path to + * a device. + */ +_hidden char * libxl__device_disk_local_attach(libxl__gc *gc, + libxl_device_disk *disk); +_hidden int libxl__device_disk_local_detach(libxl__gc *gc, + libxl_device_disk *disk); + _hidden char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid); struct libxl__xen_console_reader { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSB-0004qn-2J; Fri, 04 May 2012 11:13:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS9-0004q1-FY for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:37 +0000 Received: from [85.158.143.35:53034] by server-3.bemta-4.messagelabs.com id 64/0C-05853-0E9B3AF4; Fri, 04 May 2012 11:13:36 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19607 invoked from network); 4 May 2012 11:13:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859851" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-60; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:15 +0100 Message-ID: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 3/8] libxl: add a transaction parameter to libxl__device_generic_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add a xs_transaction_t parameter to libxl__device_generic_add, if it is XBT_NULL, allocate a proper one. Update all the callers. This patch contains a large number of unchecked xenstore operations, we might want to fix this in the future. Changes in v4: - libxl__device_generic_add: do not end the transaction is the caller provided it; - libxl__device_generic_add: fix success exit path. Signed-off-by: Stefano Stabellini Acked-by: Ian Jackson --- tools/libxl/libxl.c | 10 +++++----- tools/libxl/libxl_device.c | 17 +++++++++++------ tools/libxl/libxl_internal.h | 4 ++-- tools/libxl/libxl_pci.c | 2 +- 4 files changed, 19 insertions(+), 14 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1357efc..525f0d6 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis flexarray_append(front, "device-type"); flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); @@ -1802,7 +1802,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) flexarray_append(front, "mac"); flexarray_append(front, libxl__sprintf(gc, LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); @@ -2080,7 +2080,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL); } - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; @@ -2151,7 +2151,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) flexarray_append(front, "state"); flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; @@ -2284,7 +2284,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) libxl__sprintf(gc, "%d", vfb->backend_domid)); flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c7e057d..88cdc7d 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc, return libxl__device_kind_from_string(strkind, &dev->backend_kind); } -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, - char **bents, char **fents) +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, + libxl__device *device, char **bents, char **fents) { libxl_ctx *ctx = libxl__gc_owner(gc); char *frontend_path, *backend_path; - xs_transaction_t t; struct xs_permissions frontend_perms[2]; struct xs_permissions backend_perms[2]; + int create_transaction = t == XBT_NULL; frontend_path = libxl__device_frontend_path(gc, device); backend_path = libxl__device_backend_path(gc, device); @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, backend_perms[1].perms = XS_PERM_READ; retry_transaction: - t = xs_transaction_start(ctx->xsh); + if (create_transaction) + t = xs_transaction_start(ctx->xsh); /* FIXME: read frontend_path and check state before removing stuff */ if (fents) { @@ -100,13 +101,17 @@ retry_transaction: libxl__xs_writev(gc, t, backend_path, bents); } + if (!create_transaction) + return 0; + if (!xs_transaction_end(ctx->xsh, t, 0)) { if (errno == EAGAIN) goto retry_transaction; - else + else { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed"); + return ERROR_FAIL; + } } - return 0; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 965d13b..2c8f06a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -683,8 +683,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__device_console *console, libxl__domain_build_state *state); -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, - char **bents, char **fents); +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, + libxl__device *device, char **bents, char **fents); _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 3856bd9..335c645 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0)); flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSB-0004qn-2J; Fri, 04 May 2012 11:13:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS9-0004q1-FY for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:37 +0000 Received: from [85.158.143.35:53034] by server-3.bemta-4.messagelabs.com id 64/0C-05853-0E9B3AF4; Fri, 04 May 2012 11:13:36 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19607 invoked from network); 4 May 2012 11:13:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859851" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-60; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:15 +0100 Message-ID: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 3/8] libxl: add a transaction parameter to libxl__device_generic_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add a xs_transaction_t parameter to libxl__device_generic_add, if it is XBT_NULL, allocate a proper one. Update all the callers. This patch contains a large number of unchecked xenstore operations, we might want to fix this in the future. Changes in v4: - libxl__device_generic_add: do not end the transaction is the caller provided it; - libxl__device_generic_add: fix success exit path. Signed-off-by: Stefano Stabellini Acked-by: Ian Jackson --- tools/libxl/libxl.c | 10 +++++----- tools/libxl/libxl_device.c | 17 +++++++++++------ tools/libxl/libxl_internal.h | 4 ++-- tools/libxl/libxl_pci.c | 2 +- 4 files changed, 19 insertions(+), 14 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1357efc..525f0d6 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis flexarray_append(front, "device-type"); flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); @@ -1802,7 +1802,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) flexarray_append(front, "mac"); flexarray_append(front, libxl__sprintf(gc, LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); @@ -2080,7 +2080,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL); } - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; @@ -2151,7 +2151,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) flexarray_append(front, "state"); flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; @@ -2284,7 +2284,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) libxl__sprintf(gc, "%d", vfb->backend_domid)); flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c7e057d..88cdc7d 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc, return libxl__device_kind_from_string(strkind, &dev->backend_kind); } -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, - char **bents, char **fents) +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, + libxl__device *device, char **bents, char **fents) { libxl_ctx *ctx = libxl__gc_owner(gc); char *frontend_path, *backend_path; - xs_transaction_t t; struct xs_permissions frontend_perms[2]; struct xs_permissions backend_perms[2]; + int create_transaction = t == XBT_NULL; frontend_path = libxl__device_frontend_path(gc, device); backend_path = libxl__device_backend_path(gc, device); @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, backend_perms[1].perms = XS_PERM_READ; retry_transaction: - t = xs_transaction_start(ctx->xsh); + if (create_transaction) + t = xs_transaction_start(ctx->xsh); /* FIXME: read frontend_path and check state before removing stuff */ if (fents) { @@ -100,13 +101,17 @@ retry_transaction: libxl__xs_writev(gc, t, backend_path, bents); } + if (!create_transaction) + return 0; + if (!xs_transaction_end(ctx->xsh, t, 0)) { if (errno == EAGAIN) goto retry_transaction; - else + else { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed"); + return ERROR_FAIL; + } } - return 0; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 965d13b..2c8f06a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -683,8 +683,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__device_console *console, libxl__domain_build_state *state); -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, - char **bents, char **fents); +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, + libxl__device *device, char **bents, char **fents); _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 3856bd9..335c645 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0)); flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, + libxl__device_generic_add(gc, XBT_NULL, &device, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS9-0004q3-9F; Fri, 04 May 2012 11:13:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS7-0004pZ-Rb for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:36 +0000 Received: from [85.158.143.35:39637] by server-2.bemta-4.messagelabs.com id 38/0C-17550-FD9B3AF4; Fri, 04 May 2012 11:13:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19553 invoked from network); 4 May 2012 11:13: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; 4 May 2012 11:13:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859849" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-5Z; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:14 +0100 Message-ID: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce a new libxl_device_disk** parameter to libxl__device_disk_local_attach, the parameter is allocated on the gc by libxl__device_disk_local_attach. It is going to fill it with informations about the new locally attached disk. The new libxl_device_disk should be passed to libxl_device_disk_local_detach afterwards. Changes in v5: - rename disk to in_disk; - rename tmpdisk to disk; - copy disk to new_disk only on success; - remove check on libxl__zalloc success. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_bootloader.c | 10 +++++----- tools/libxl/libxl_internal.c | 20 ++++++++++++++------ tools/libxl/libxl_internal.h | 3 ++- 3 files changed, 21 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 977c6d3..83cac78 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, char *fifo = NULL; char *diskpath = NULL; char **args = NULL; + libxl_device_disk *tmpdisk = NULL; char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; char *tempdir; @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl__device_disk_local_attach(gc, disk); + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); if (!diskpath) { + rc = ERROR_FAIL; goto out_close; } @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, rc = 0; out_close: - if (diskpath) { - libxl__device_disk_local_detach(gc, disk); - free(diskpath); - } + if (tmpdisk) + libxl__device_disk_local_detach(gc, tmpdisk); if (fifo_fd > -1) close(fifo_fd); if (bootloader_fd > -1) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index fc771ff..55dc55c 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,12 +323,21 @@ out: return rc; } -char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) +char * libxl__device_disk_local_attach(libxl__gc *gc, + const libxl_device_disk *in_disk, + libxl_device_disk **new_disk) { libxl_ctx *ctx = gc->owner; char *dev = NULL; - char *ret = NULL; int rc; + libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); + + memcpy(disk, in_disk, sizeof(libxl_device_disk)); + if (in_disk->pdev_path != NULL) + disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path); + if (in_disk->script != NULL) + disk->script = libxl__strdup(gc, in_disk->script); + disk->vdev = NULL; rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; @@ -368,7 +377,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) break; } LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - disk->pdev_path); + in_disk->pdev_path); dev = disk->pdev_path; break; default: @@ -378,9 +387,8 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) } out: - if (dev != NULL) - ret = strdup(dev); - return ret; + *new_disk = disk; + return dev; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index ddd6a37..965d13b 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1008,7 +1008,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); * a device. */ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, - libxl_device_disk *disk); + const libxl_device_disk *in_disk, + libxl_device_disk **new_disk); _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS9-0004q3-9F; Fri, 04 May 2012 11:13:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS7-0004pZ-Rb for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:36 +0000 Received: from [85.158.143.35:39637] by server-2.bemta-4.messagelabs.com id 38/0C-17550-FD9B3AF4; Fri, 04 May 2012 11:13:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19553 invoked from network); 4 May 2012 11:13: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; 4 May 2012 11:13:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859849" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-5Z; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:14 +0100 Message-ID: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce a new libxl_device_disk** parameter to libxl__device_disk_local_attach, the parameter is allocated on the gc by libxl__device_disk_local_attach. It is going to fill it with informations about the new locally attached disk. The new libxl_device_disk should be passed to libxl_device_disk_local_detach afterwards. Changes in v5: - rename disk to in_disk; - rename tmpdisk to disk; - copy disk to new_disk only on success; - remove check on libxl__zalloc success. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_bootloader.c | 10 +++++----- tools/libxl/libxl_internal.c | 20 ++++++++++++++------ tools/libxl/libxl_internal.h | 3 ++- 3 files changed, 21 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 977c6d3..83cac78 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, char *fifo = NULL; char *diskpath = NULL; char **args = NULL; + libxl_device_disk *tmpdisk = NULL; char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; char *tempdir; @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl__device_disk_local_attach(gc, disk); + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); if (!diskpath) { + rc = ERROR_FAIL; goto out_close; } @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, rc = 0; out_close: - if (diskpath) { - libxl__device_disk_local_detach(gc, disk); - free(diskpath); - } + if (tmpdisk) + libxl__device_disk_local_detach(gc, tmpdisk); if (fifo_fd > -1) close(fifo_fd); if (bootloader_fd > -1) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index fc771ff..55dc55c 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,12 +323,21 @@ out: return rc; } -char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) +char * libxl__device_disk_local_attach(libxl__gc *gc, + const libxl_device_disk *in_disk, + libxl_device_disk **new_disk) { libxl_ctx *ctx = gc->owner; char *dev = NULL; - char *ret = NULL; int rc; + libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); + + memcpy(disk, in_disk, sizeof(libxl_device_disk)); + if (in_disk->pdev_path != NULL) + disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path); + if (in_disk->script != NULL) + disk->script = libxl__strdup(gc, in_disk->script); + disk->vdev = NULL; rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; @@ -368,7 +377,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) break; } LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - disk->pdev_path); + in_disk->pdev_path); dev = disk->pdev_path; break; default: @@ -378,9 +387,8 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) } out: - if (dev != NULL) - ret = strdup(dev); - return ret; + *new_disk = disk; + return dev; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index ddd6a37..965d13b 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1008,7 +1008,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); * a device. */ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, - libxl_device_disk *disk); + const libxl_device_disk *in_disk, + libxl_device_disk **new_disk); _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS7-0004pb-SJ; Fri, 04 May 2012 11:13:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS6-0004ob-7p for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:34 +0000 Received: from [85.158.143.99:16530] by server-1.bemta-4.messagelabs.com id AD/01-20925-DD9B3AF4; Fri, 04 May 2012 11:13:33 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336130007!25579432!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29706 invoked from network); 4 May 2012 11:13:33 -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; 4 May 2012 11:13:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193395762" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-RS; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:19 +0100 Message-ID: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org - Spawn a QEMU instance at boot time to handle disk local attach requests. - Implement libxl_device_disk_local_attach for QDISKs in terms of a regular disk attach with the frontend and backend running in the same domain. Chanegs in v5: - replace LIBXL__LOG with LOG. Changes on v4: - improve error handling and exit paths in libxl__device_disk_local_attach. Signed-off-by: Stefano Stabellini --- tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + tools/hotplug/Linux/init.d/xencommons | 3 + tools/libxl/libxl_internal.c | 58 ++++++++++++++++++---- 3 files changed, 53 insertions(+), 11 deletions(-) diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons index 6543204..0f3b9ad 100644 --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons @@ -12,3 +12,6 @@ # Running xenbackendd in debug mode #XENBACKENDD_DEBUG=[yes|on|1] + +# qemu path and log file +#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons index 2f81ea2..9dda6e2 100644 --- a/tools/hotplug/Linux/init.d/xencommons +++ b/tools/hotplug/Linux/init.d/xencommons @@ -104,6 +104,9 @@ do_start () { xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d" test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS + echo Starting QEMU as disk backend for dom0 + test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 + $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null } do_stop () { echo Stopping xenconsoled diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 7a1e017..e180498 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -519,6 +519,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_ctx *ctx = gc->owner; char *dev = NULL; int rc; + xs_transaction_t t = XBT_NULL; libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); memcpy(disk, in_disk, sizeof(libxl_device_disk)); @@ -561,13 +562,35 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, break; case LIBXL_DISK_BACKEND_QDISK: if (disk->format != LIBXL_DISK_FORMAT_RAW) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" - " attach a qdisk image if the format is not raw"); - break; + do { + t = xs_transaction_start(ctx->xsh); + if (t == XBT_NULL) { + LOG(ERROR, "failed to start a xenstore transaction"); + goto out; + } + disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t); + if (disk->vdev == NULL) { + LOG(ERROR, "libxl__alloc_vdev failed"); + goto out; + } + if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID, + t, disk)) { + LOG(ERROR, "libxl_device_disk_add failed"); + goto out; + } + rc = xs_transaction_end(ctx->xsh, t, 0); + } while (rc == 0 && errno == EAGAIN); + t = XBT_NULL; + if (rc == 0) { + LOGE(ERROR, "xenstore transaction failed"); + goto out; + } + dev = GCSPRINTF("/dev/%s", disk->vdev); + } else { + dev = disk->pdev_path; } LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - in_disk->pdev_path); - dev = disk->pdev_path; + dev); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " @@ -576,18 +599,31 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, } out: + if (t != XBT_NULL) + xs_transaction_end(ctx->xsh, t, 1); *new_disk = disk; return dev; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) { - /* Nothing to do for PHYSTYPE_PHY. */ - - /* - * For other device types assume that the blktap2 process is - * needed by the soon to be started domain and do nothing. - */ + switch (disk->backend) { + case LIBXL_DISK_BACKEND_QDISK: + if (disk->vdev != NULL) { + libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID, + disk, 0); + return libxl_device_disk_destroy(gc->owner, + LIBXL_TOOLSTACK_DOMID, disk); + } + break; + default: + /* + * Nothing to do for PHYSTYPE_PHY. + * For other device types assume that the blktap2 process is + * needed by the soon to be started domain and do nothing. + */ + break; + } return 0; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS7-0004pb-SJ; Fri, 04 May 2012 11:13:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS6-0004ob-7p for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:34 +0000 Received: from [85.158.143.99:16530] by server-1.bemta-4.messagelabs.com id AD/01-20925-DD9B3AF4; Fri, 04 May 2012 11:13:33 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336130007!25579432!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29706 invoked from network); 4 May 2012 11:13:33 -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; 4 May 2012 11:13:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193395762" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-RS; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:19 +0100 Message-ID: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org - Spawn a QEMU instance at boot time to handle disk local attach requests. - Implement libxl_device_disk_local_attach for QDISKs in terms of a regular disk attach with the frontend and backend running in the same domain. Chanegs in v5: - replace LIBXL__LOG with LOG. Changes on v4: - improve error handling and exit paths in libxl__device_disk_local_attach. Signed-off-by: Stefano Stabellini --- tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + tools/hotplug/Linux/init.d/xencommons | 3 + tools/libxl/libxl_internal.c | 58 ++++++++++++++++++---- 3 files changed, 53 insertions(+), 11 deletions(-) diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons index 6543204..0f3b9ad 100644 --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons @@ -12,3 +12,6 @@ # Running xenbackendd in debug mode #XENBACKENDD_DEBUG=[yes|on|1] + +# qemu path and log file +#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons index 2f81ea2..9dda6e2 100644 --- a/tools/hotplug/Linux/init.d/xencommons +++ b/tools/hotplug/Linux/init.d/xencommons @@ -104,6 +104,9 @@ do_start () { xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d" test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS + echo Starting QEMU as disk backend for dom0 + test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 + $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null } do_stop () { echo Stopping xenconsoled diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 7a1e017..e180498 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -519,6 +519,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_ctx *ctx = gc->owner; char *dev = NULL; int rc; + xs_transaction_t t = XBT_NULL; libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); memcpy(disk, in_disk, sizeof(libxl_device_disk)); @@ -561,13 +562,35 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, break; case LIBXL_DISK_BACKEND_QDISK: if (disk->format != LIBXL_DISK_FORMAT_RAW) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" - " attach a qdisk image if the format is not raw"); - break; + do { + t = xs_transaction_start(ctx->xsh); + if (t == XBT_NULL) { + LOG(ERROR, "failed to start a xenstore transaction"); + goto out; + } + disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t); + if (disk->vdev == NULL) { + LOG(ERROR, "libxl__alloc_vdev failed"); + goto out; + } + if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID, + t, disk)) { + LOG(ERROR, "libxl_device_disk_add failed"); + goto out; + } + rc = xs_transaction_end(ctx->xsh, t, 0); + } while (rc == 0 && errno == EAGAIN); + t = XBT_NULL; + if (rc == 0) { + LOGE(ERROR, "xenstore transaction failed"); + goto out; + } + dev = GCSPRINTF("/dev/%s", disk->vdev); + } else { + dev = disk->pdev_path; } LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", - in_disk->pdev_path); - dev = disk->pdev_path; + dev); break; default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " @@ -576,18 +599,31 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, } out: + if (t != XBT_NULL) + xs_transaction_end(ctx->xsh, t, 1); *new_disk = disk; return dev; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) { - /* Nothing to do for PHYSTYPE_PHY. */ - - /* - * For other device types assume that the blktap2 process is - * needed by the soon to be started domain and do nothing. - */ + switch (disk->backend) { + case LIBXL_DISK_BACKEND_QDISK: + if (disk->vdev != NULL) { + libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID, + disk, 0); + return libxl_device_disk_destroy(gc->owner, + LIBXL_TOOLSTACK_DOMID, disk); + } + break; + default: + /* + * Nothing to do for PHYSTYPE_PHY. + * For other device types assume that the blktap2 process is + * needed by the soon to be started domain and do nothing. + */ + break; + } return 0; } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS9-0004qD-LU; Fri, 04 May 2012 11:13:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS8-0004pZ-BM for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:36 +0000 Received: from [85.158.143.35:52989] by server-2.bemta-4.messagelabs.com id 9C/0C-17550-FD9B3AF4; Fri, 04 May 2012 11:13:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19586 invoked from network); 4 May 2012 11:13:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859850" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-Qu; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:18 +0100 Message-ID: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl__alloc_vdev: find a spare virtual block device in the domain passed as argument. Changes in v5: - remove domid paramter to libxl__alloc_vdev (assume LIBXL_TOOLSTACK_DOMID); - remove scaling limit from libxl__alloc_vdev. Changes in v4: - rename libxl__devid_to_vdev to libxl__devid_to_localdev; - introduce upper bound for encode_disk_name; - better error handling; Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_internal.c | 31 ++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 4 +++ tools/libxl/libxl_linux.c | 45 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_netbsd.c | 6 +++++ 4 files changed, 86 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index bd5ebb3..7a1e017 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -480,6 +480,37 @@ out: return rc; } +/* libxl__alloc_vdev only works on the local domain, that is the domain + * where the toolstack is running */ +static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start, + xs_transaction_t t) +{ + int devid = 0, disk = 0, part = 0; + char *vdev = NULL; + char *dompath = libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID); + + libxl__device_disk_dev_number(blkdev_start, &disk, &part); + if (part != 0) { + LOG(ERROR, "blkdev_start is invalid"); + return NULL; + } + + do { + vdev = GCSPRINTF("d%dp0", disk); + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); + if (libxl__xs_read(gc, t, + libxl__sprintf(gc, "%s/device/vbd/%d/backend", + dompath, devid)) == NULL) { + if (errno == ENOENT) + return libxl__devid_to_localdev(gc, devid); + else + return NULL; + } + disk++; + } while (disk <= (1 << 20)); + return NULL; +} + char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, libxl_device_disk **new_disk, diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 0074ec4..a451c79 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -77,6 +77,8 @@ #define LIBXL_PV_EXTRA_MEMORY 1024 #define LIBXL_HVM_EXTRA_MEMORY 2048 #define LIBXL_MIN_DOM0_MEM (128*1024) +/* use 0 as the domid of the toolstack domain for now */ +#define LIBXL_TOOLSTACK_DOMID 0 #define QEMU_SIGNATURE "DeviceModelRecord0002" #define STUBDOM_CONSOLE_LOGGING 0 #define STUBDOM_CONSOLE_SAVE 1 @@ -763,6 +765,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, */ _hidden int libxl__try_phy_backend(mode_t st_mode); +_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 925248b..cb596a9 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode) return 1; } + +#define EXT_SHIFT 28 +#define EXTENDED (1<= 26) + ptr = encode_disk_name(ptr, n / 26 - 1); + *ptr = 'a' + n % 26; + return ptr + 1; +} + +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) +{ + int minor; + int offset; + int nr_parts; + char *ptr = NULL; + char *ret = libxl__zalloc(gc, 32); + + if (!VDEV_IS_EXTENDED(devid)) { + minor = devid & 0xff; + nr_parts = 16; + } else { + minor = BLKIF_MINOR_EXT(devid); + nr_parts = 256; + } + offset = minor / nr_parts; + + /* arbitrary upper bound */ + if (offset > 676) + return NULL; + + strcpy(ret, "xvd"); + ptr = encode_disk_name(ret + 3, offset); + if (minor % nr_parts == 0) + *ptr = 0; + else + snprintf(ptr, ret + 32 - ptr, + "%d", minor & (nr_parts - 1)); + return ret; +} diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c index 9e0ed6d..dbf5f71 100644 --- a/tools/libxl/libxl_netbsd.c +++ b/tools/libxl/libxl_netbsd.c @@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode) return 0; } + +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) +{ + /* TODO */ + return NULL; +} -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGS9-0004qD-LU; Fri, 04 May 2012 11:13:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS8-0004pZ-BM for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:36 +0000 Received: from [85.158.143.35:52989] by server-2.bemta-4.messagelabs.com id 9C/0C-17550-FD9B3AF4; Fri, 04 May 2012 11:13:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19586 invoked from network); 4 May 2012 11:13:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859850" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-Qu; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:18 +0100 Message-ID: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl__alloc_vdev: find a spare virtual block device in the domain passed as argument. Changes in v5: - remove domid paramter to libxl__alloc_vdev (assume LIBXL_TOOLSTACK_DOMID); - remove scaling limit from libxl__alloc_vdev. Changes in v4: - rename libxl__devid_to_vdev to libxl__devid_to_localdev; - introduce upper bound for encode_disk_name; - better error handling; Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_internal.c | 31 ++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 4 +++ tools/libxl/libxl_linux.c | 45 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_netbsd.c | 6 +++++ 4 files changed, 86 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index bd5ebb3..7a1e017 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -480,6 +480,37 @@ out: return rc; } +/* libxl__alloc_vdev only works on the local domain, that is the domain + * where the toolstack is running */ +static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start, + xs_transaction_t t) +{ + int devid = 0, disk = 0, part = 0; + char *vdev = NULL; + char *dompath = libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID); + + libxl__device_disk_dev_number(blkdev_start, &disk, &part); + if (part != 0) { + LOG(ERROR, "blkdev_start is invalid"); + return NULL; + } + + do { + vdev = GCSPRINTF("d%dp0", disk); + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); + if (libxl__xs_read(gc, t, + libxl__sprintf(gc, "%s/device/vbd/%d/backend", + dompath, devid)) == NULL) { + if (errno == ENOENT) + return libxl__devid_to_localdev(gc, devid); + else + return NULL; + } + disk++; + } while (disk <= (1 << 20)); + return NULL; +} + char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, libxl_device_disk **new_disk, diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 0074ec4..a451c79 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -77,6 +77,8 @@ #define LIBXL_PV_EXTRA_MEMORY 1024 #define LIBXL_HVM_EXTRA_MEMORY 2048 #define LIBXL_MIN_DOM0_MEM (128*1024) +/* use 0 as the domid of the toolstack domain for now */ +#define LIBXL_TOOLSTACK_DOMID 0 #define QEMU_SIGNATURE "DeviceModelRecord0002" #define STUBDOM_CONSOLE_LOGGING 0 #define STUBDOM_CONSOLE_SAVE 1 @@ -763,6 +765,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, */ _hidden int libxl__try_phy_backend(mode_t st_mode); +_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 925248b..cb596a9 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode) return 1; } + +#define EXT_SHIFT 28 +#define EXTENDED (1<= 26) + ptr = encode_disk_name(ptr, n / 26 - 1); + *ptr = 'a' + n % 26; + return ptr + 1; +} + +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) +{ + int minor; + int offset; + int nr_parts; + char *ptr = NULL; + char *ret = libxl__zalloc(gc, 32); + + if (!VDEV_IS_EXTENDED(devid)) { + minor = devid & 0xff; + nr_parts = 16; + } else { + minor = BLKIF_MINOR_EXT(devid); + nr_parts = 256; + } + offset = minor / nr_parts; + + /* arbitrary upper bound */ + if (offset > 676) + return NULL; + + strcpy(ret, "xvd"); + ptr = encode_disk_name(ret + 3, offset); + if (minor % nr_parts == 0) + *ptr = 0; + else + snprintf(ptr, ret + 32 - ptr, + "%d", minor & (nr_parts - 1)); + return ret; +} diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c index 9e0ed6d..dbf5f71 100644 --- a/tools/libxl/libxl_netbsd.c +++ b/tools/libxl/libxl_netbsd.c @@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode) return 0; } + +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) +{ + /* TODO */ + return NULL; +} -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSC-0004rc-Ce; Fri, 04 May 2012 11:13:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSA-0004ob-D4 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:38 +0000 Received: from [85.158.143.35:53106] by server-1.bemta-4.messagelabs.com id B6/21-20925-2E9B3AF4; Fri, 04 May 2012 11:13:38 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336130015!7539042!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24587 invoked from network); 4 May 2012 11:13:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859854" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-Oc; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:16 +0100 Message-ID: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 4/8] libxl: introduce libxl__device_disk_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl__device_disk_add that takes an additional xs_transaction_t paramter. Implement libxl_device_disk_add using libxl__device_disk_add. Move libxl__device_from_disk to libxl_internal.c. No functional change. Changes in v5: - rename libxl__device_generic_add_t to libxl__device_generic_add. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl.c | 151 +---------------------------------------- tools/libxl/libxl_internal.c | 157 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 6 ++ 3 files changed, 164 insertions(+), 150 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 525f0d6..941dbb9 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) return rc; } -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, - libxl_device_disk *disk, - libxl__device *device) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - int devid; - - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - if (devid==-1) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - return ERROR_INVAL; - } - - device->backend_domid = disk->backend_domid; - device->backend_devid = devid; - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_TAP: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_QDISK: - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", - disk->backend); - return ERROR_INVAL; - } - - device->domid = domid; - device->devid = devid; - device->kind = LIBXL__DEVICE_KIND_VBD; - - return 0; -} - int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) { GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - char *dev; - libxl__device device; - int major, minor, rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (disk->script) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" - " not yet supported, sorry"); - rc = ERROR_INVAL; - goto out_free; - } - - rc = libxl__device_from_disk(gc, domid, disk, &device); - if (rc != 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - goto out_free; - } - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - dev = disk->pdev_path; - do_backend_phy: - libxl__device_physdisk_major_minor(dev, &major, &minor); - flexarray_append(back, "physical-device"); - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); - - flexarray_append(back, "params"); - flexarray_append(back, dev); - - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); - break; - case LIBXL_DISK_BACKEND_TAP: - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); - if (!dev) { - rc = ERROR_FAIL; - goto out_free; - } - flexarray_append(back, "tapdisk-params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), - disk->pdev_path)); - - /* now create a phy device to export the device to the guest */ - goto do_backend_phy; - case LIBXL_DISK_BACKEND_QDISK: - flexarray_append(back, "params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); - rc = ERROR_INVAL; - goto out_free; - } - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "removable"); - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); - flexarray_append(back, "bootable"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "dev"); - flexarray_append(back, disk->vdev); - flexarray_append(back, "type"); - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); - flexarray_append(back, "mode"); - flexarray_append(back, disk->readwrite ? "w" : "r"); - flexarray_append(back, "device-type"); - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "virtual-device"); - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); - flexarray_append(front, "device-type"); - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - - libxl__device_generic_add(gc, XBT_NULL, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - - rc = 0; - -out_free: - flexarray_free(back); - flexarray_free(front); -out: + int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk); GC_FREE; return rc; } diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 55dc55c..1bf5d73 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,6 +323,163 @@ out: return rc; } +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int devid; + + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + if (devid==-1) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + return ERROR_INVAL; + } + + device->backend_domid = disk->backend_domid; + device->backend_devid = devid; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_TAP: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_QDISK: + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", + disk->backend); + return ERROR_INVAL; + } + + device->domid = domid; + device->devid = devid; + device->kind = LIBXL__DEVICE_KIND_VBD; + + return 0; +} + +int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, + xs_transaction_t t, libxl_device_disk *disk) +{ + flexarray_t *front; + flexarray_t *back; + char *dev; + libxl__device device; + int major, minor, rc; + libxl_ctx *ctx = gc->owner; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (disk->script) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" + " not yet supported, sorry"); + rc = ERROR_INVAL; + goto out_free; + } + + rc = libxl__device_from_disk(gc, domid, disk, &device); + if (rc != 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + goto out_free; + } + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + dev = disk->pdev_path; + do_backend_phy: + libxl__device_physdisk_major_minor(dev, &major, &minor); + flexarray_append(back, "physical-device"); + flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); + + flexarray_append(back, "params"); + flexarray_append(back, dev); + + assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); + break; + case LIBXL_DISK_BACKEND_TAP: + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); + if (!dev) { + rc = ERROR_FAIL; + goto out_free; + } + flexarray_append(back, "tapdisk-params"); + flexarray_append(back, libxl__sprintf(gc, "%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + + /* now create a phy device to export the device to the guest */ + goto do_backend_phy; + case LIBXL_DISK_BACKEND_QDISK: + flexarray_append(back, "params"); + flexarray_append(back, libxl__sprintf(gc, "%s:%s", + libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); + assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); + rc = ERROR_INVAL; + goto out_free; + } + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "removable"); + flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); + flexarray_append(back, "bootable"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + flexarray_append(back, "dev"); + flexarray_append(back, disk->vdev); + flexarray_append(back, "type"); + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); + flexarray_append(back, "mode"); + flexarray_append(back, disk->readwrite ? "w" : "r"); + flexarray_append(back, "device-type"); + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "virtual-device"); + flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); + flexarray_append(front, "device-type"); + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); + + libxl__device_generic_add(gc, t, &device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + rc = 0; + +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, libxl_device_disk **new_disk) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 2c8f06a..096c96d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1003,6 +1003,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, */ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); + +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device); +_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, + xs_transaction_t t, libxl_device_disk *disk); /* * Make a disk available in this (the control) domain. Returns path to * a device. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSB-0004qz-FH; Fri, 04 May 2012 11:13:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS9-0004ob-PI for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:37 +0000 Received: from [85.158.143.35:53064] by server-1.bemta-4.messagelabs.com id 12/21-20925-1E9B3AF4; Fri, 04 May 2012 11:13:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19636 invoked from network); 4 May 2012 11:13:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859853" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-P7; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:17 +0100 Message-ID: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce a blkdev_start in xl.conf and a corresponding string in libxl_domain_build_info. Add a blkdev_start parameter to libxl__device_disk_local_attach: it is going to be used in a following patch. blkdev_start specifies the first block device to be used for temporary block device allocations by the toolstack. Changes in v5: - change the type of the blkdev_start parameter to libxl__device_disk_local_attach to const char *. Changes in v4: - pass blkdev_start in libxl_domain_build_info. Signed-off-by: Stefano Stabellini --- tools/examples/xl.conf | 3 +++ tools/libxl/libxl_bootloader.c | 3 ++- tools/libxl/libxl_create.c | 3 +++ tools/libxl/libxl_internal.c | 3 ++- tools/libxl/libxl_internal.h | 3 ++- tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 3 +++ tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 2 ++ 9 files changed, 19 insertions(+), 3 deletions(-) diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf index 56d3b3b..ebf057c 100644 --- a/tools/examples/xl.conf +++ b/tools/examples/xl.conf @@ -12,3 +12,6 @@ # default output format used by "xl list -l" #output_format="json" + +# first block device to be used for temporary VM disk mounts +#blkdev_start="xvda" diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 83cac78..123b06e 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk, + info->blkdev_start); if (!diskpath) { rc = ERROR_FAIL; goto out_close; diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 7ab2f72..f2fcdf0 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -107,6 +107,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, } } + if (b_info->blkdev_start == NULL) + b_info->blkdev_start = strdup("xvda"); + if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { if (!b_info->u.hvm.bios) switch (b_info->device_model_version) { diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 1bf5d73..bd5ebb3 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -482,7 +482,8 @@ out: char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, - libxl_device_disk **new_disk) + libxl_device_disk **new_disk, + const char *blkdev_start) { libxl_ctx *ctx = gc->owner; char *dev = NULL; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 096c96d..0074ec4 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1015,7 +1015,8 @@ _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, */ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, - libxl_device_disk **new_disk); + libxl_device_disk **new_disk, + const char *blkdev_start); _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk); diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 68599cb..7131696 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -253,6 +253,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), + ("blkdev_start", string), ("device_model_version", libxl_device_model_version), ("device_model_stubdomain", libxl_defbool), diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index a6ffd25..4596c4f 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -35,6 +35,7 @@ xentoollog_logger_stdiostream *logger; int dryrun_only; int autoballoon = 1; +char *blkdev_start; char *lockfile; char *default_vifscript = NULL; char *default_bridge = NULL; @@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile, fprintf(stderr, "invalid default output format \"%s\"\n", buf); } } + if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0)) + blkdev_start = strdup(buf); xlu_cfg_destroy(config); } diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index f0d0ec8..3fbe14d 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -112,6 +112,7 @@ extern int dryrun_only; extern char *lockfile; extern char *default_vifscript; extern char *default_bridge; +extern char *blkdev_start; enum output_format { OUTPUT_FORMAT_JSON, diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 28f5cab..7338562 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -595,6 +595,8 @@ static void parse_config_data(const char *configfile_filename_report, } libxl_domain_build_info_init_type(b_info, c_info->type); + if (blkdev_start) + b_info->blkdev_start = strdup(blkdev_start); /* the following is the actual config parsing with overriding values in the structures */ if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSC-0004rc-Ce; Fri, 04 May 2012 11:13:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSA-0004ob-D4 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:38 +0000 Received: from [85.158.143.35:53106] by server-1.bemta-4.messagelabs.com id B6/21-20925-2E9B3AF4; Fri, 04 May 2012 11:13:38 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336130015!7539042!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24587 invoked from network); 4 May 2012 11:13:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859854" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-Oc; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:16 +0100 Message-ID: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 4/8] libxl: introduce libxl__device_disk_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl__device_disk_add that takes an additional xs_transaction_t paramter. Implement libxl_device_disk_add using libxl__device_disk_add. Move libxl__device_from_disk to libxl_internal.c. No functional change. Changes in v5: - rename libxl__device_generic_add_t to libxl__device_generic_add. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl.c | 151 +---------------------------------------- tools/libxl/libxl_internal.c | 157 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 6 ++ 3 files changed, 164 insertions(+), 150 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 525f0d6..941dbb9 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) return rc; } -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, - libxl_device_disk *disk, - libxl__device *device) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - int devid; - - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - if (devid==-1) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - return ERROR_INVAL; - } - - device->backend_domid = disk->backend_domid; - device->backend_devid = devid; - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_TAP: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_QDISK: - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", - disk->backend); - return ERROR_INVAL; - } - - device->domid = domid; - device->devid = devid; - device->kind = LIBXL__DEVICE_KIND_VBD; - - return 0; -} - int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) { GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - char *dev; - libxl__device device; - int major, minor, rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (disk->script) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" - " not yet supported, sorry"); - rc = ERROR_INVAL; - goto out_free; - } - - rc = libxl__device_from_disk(gc, domid, disk, &device); - if (rc != 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - goto out_free; - } - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - dev = disk->pdev_path; - do_backend_phy: - libxl__device_physdisk_major_minor(dev, &major, &minor); - flexarray_append(back, "physical-device"); - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); - - flexarray_append(back, "params"); - flexarray_append(back, dev); - - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); - break; - case LIBXL_DISK_BACKEND_TAP: - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); - if (!dev) { - rc = ERROR_FAIL; - goto out_free; - } - flexarray_append(back, "tapdisk-params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), - disk->pdev_path)); - - /* now create a phy device to export the device to the guest */ - goto do_backend_phy; - case LIBXL_DISK_BACKEND_QDISK: - flexarray_append(back, "params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); - rc = ERROR_INVAL; - goto out_free; - } - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "removable"); - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); - flexarray_append(back, "bootable"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "dev"); - flexarray_append(back, disk->vdev); - flexarray_append(back, "type"); - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); - flexarray_append(back, "mode"); - flexarray_append(back, disk->readwrite ? "w" : "r"); - flexarray_append(back, "device-type"); - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "virtual-device"); - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); - flexarray_append(front, "device-type"); - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - - libxl__device_generic_add(gc, XBT_NULL, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - - rc = 0; - -out_free: - flexarray_free(back); - flexarray_free(front); -out: + int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk); GC_FREE; return rc; } diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 55dc55c..1bf5d73 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -323,6 +323,163 @@ out: return rc; } +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int devid; + + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + if (devid==-1) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + return ERROR_INVAL; + } + + device->backend_domid = disk->backend_domid; + device->backend_devid = devid; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_TAP: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_QDISK: + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", + disk->backend); + return ERROR_INVAL; + } + + device->domid = domid; + device->devid = devid; + device->kind = LIBXL__DEVICE_KIND_VBD; + + return 0; +} + +int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, + xs_transaction_t t, libxl_device_disk *disk) +{ + flexarray_t *front; + flexarray_t *back; + char *dev; + libxl__device device; + int major, minor, rc; + libxl_ctx *ctx = gc->owner; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (disk->script) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" + " not yet supported, sorry"); + rc = ERROR_INVAL; + goto out_free; + } + + rc = libxl__device_from_disk(gc, domid, disk, &device); + if (rc != 0) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + goto out_free; + } + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + dev = disk->pdev_path; + do_backend_phy: + libxl__device_physdisk_major_minor(dev, &major, &minor); + flexarray_append(back, "physical-device"); + flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); + + flexarray_append(back, "params"); + flexarray_append(back, dev); + + assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); + break; + case LIBXL_DISK_BACKEND_TAP: + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); + if (!dev) { + rc = ERROR_FAIL; + goto out_free; + } + flexarray_append(back, "tapdisk-params"); + flexarray_append(back, libxl__sprintf(gc, "%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + + /* now create a phy device to export the device to the guest */ + goto do_backend_phy; + case LIBXL_DISK_BACKEND_QDISK: + flexarray_append(back, "params"); + flexarray_append(back, libxl__sprintf(gc, "%s:%s", + libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); + assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); + break; + default: + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); + rc = ERROR_INVAL; + goto out_free; + } + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "removable"); + flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); + flexarray_append(back, "bootable"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + flexarray_append(back, "dev"); + flexarray_append(back, disk->vdev); + flexarray_append(back, "type"); + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); + flexarray_append(back, "mode"); + flexarray_append(back, disk->readwrite ? "w" : "r"); + flexarray_append(back, "device-type"); + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "virtual-device"); + flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); + flexarray_append(front, "device-type"); + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); + + libxl__device_generic_add(gc, t, &device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + rc = 0; + +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, libxl_device_disk **new_disk) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 2c8f06a..096c96d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1003,6 +1003,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, */ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); + +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device); +_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, + xs_transaction_t t, libxl_device_disk *disk); /* * Make a disk available in this (the control) domain. Returns path to * a device. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGSB-0004qz-FH; Fri, 04 May 2012 11:13:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGS9-0004ob-PI for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:37 +0000 Received: from [85.158.143.35:53064] by server-1.bemta-4.messagelabs.com id 12/21-20925-1E9B3AF4; Fri, 04 May 2012 11:13:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336130013!13704814!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19636 invoked from network); 4 May 2012 11:13:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859853" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-P7; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:17 +0100 Message-ID: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce a blkdev_start in xl.conf and a corresponding string in libxl_domain_build_info. Add a blkdev_start parameter to libxl__device_disk_local_attach: it is going to be used in a following patch. blkdev_start specifies the first block device to be used for temporary block device allocations by the toolstack. Changes in v5: - change the type of the blkdev_start parameter to libxl__device_disk_local_attach to const char *. Changes in v4: - pass blkdev_start in libxl_domain_build_info. Signed-off-by: Stefano Stabellini --- tools/examples/xl.conf | 3 +++ tools/libxl/libxl_bootloader.c | 3 ++- tools/libxl/libxl_create.c | 3 +++ tools/libxl/libxl_internal.c | 3 ++- tools/libxl/libxl_internal.h | 3 ++- tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 3 +++ tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 2 ++ 9 files changed, 19 insertions(+), 3 deletions(-) diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf index 56d3b3b..ebf057c 100644 --- a/tools/examples/xl.conf +++ b/tools/examples/xl.conf @@ -12,3 +12,6 @@ # default output format used by "xl list -l" #output_format="json" + +# first block device to be used for temporary VM disk mounts +#blkdev_start="xvda" diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 83cac78..123b06e 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } - diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk, + info->blkdev_start); if (!diskpath) { rc = ERROR_FAIL; goto out_close; diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 7ab2f72..f2fcdf0 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -107,6 +107,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, } } + if (b_info->blkdev_start == NULL) + b_info->blkdev_start = strdup("xvda"); + if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { if (!b_info->u.hvm.bios) switch (b_info->device_model_version) { diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 1bf5d73..bd5ebb3 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -482,7 +482,8 @@ out: char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, - libxl_device_disk **new_disk) + libxl_device_disk **new_disk, + const char *blkdev_start) { libxl_ctx *ctx = gc->owner; char *dev = NULL; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 096c96d..0074ec4 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1015,7 +1015,8 @@ _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, */ _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, const libxl_device_disk *in_disk, - libxl_device_disk **new_disk); + libxl_device_disk **new_disk, + const char *blkdev_start); _hidden int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk); diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 68599cb..7131696 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -253,6 +253,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), + ("blkdev_start", string), ("device_model_version", libxl_device_model_version), ("device_model_stubdomain", libxl_defbool), diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index a6ffd25..4596c4f 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -35,6 +35,7 @@ xentoollog_logger_stdiostream *logger; int dryrun_only; int autoballoon = 1; +char *blkdev_start; char *lockfile; char *default_vifscript = NULL; char *default_bridge = NULL; @@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile, fprintf(stderr, "invalid default output format \"%s\"\n", buf); } } + if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0)) + blkdev_start = strdup(buf); xlu_cfg_destroy(config); } diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index f0d0ec8..3fbe14d 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -112,6 +112,7 @@ extern int dryrun_only; extern char *lockfile; extern char *default_vifscript; extern char *default_bridge; +extern char *blkdev_start; enum output_format { OUTPUT_FORMAT_JSON, diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 28f5cab..7338562 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -595,6 +595,8 @@ static void parse_config_data(const char *configfile_filename_report, } libxl_domain_build_info_init_type(b_info, c_info->type); + if (blkdev_start) + b_info->blkdev_start = strdup(blkdev_start); /* the following is the actual config parsing with overriding values in the structures */ if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSC-0004rQ-0b; Fri, 04 May 2012 11:13:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSA-0004q1-2j for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:38 +0000 Received: from [85.158.143.35:43711] by server-3.bemta-4.messagelabs.com id D6/0C-05853-1E9B3AF4; Fri, 04 May 2012 11:13:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336130015!7539042!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24559 invoked from network); 4 May 2012 11:13:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859852" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-TW; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:20 +0100 Message-ID: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 8/8] libxl__device_disk_local_attach: wait for state "connected" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org In order to make sure that the block device is available and ready to be used, wait for state "connected" in the backend before returning. Signed-off-by: Stefano Stabellini Changes in v5: - unify error paths. Changes in v4: - improve exit paths. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_internal.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index e180498..05faff5 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -517,8 +517,9 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, const char *blkdev_start) { libxl_ctx *ctx = gc->owner; - char *dev = NULL; + char *dev = NULL, *be_path = NULL; int rc; + libxl__device device; xs_transaction_t t = XBT_NULL; libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); @@ -598,11 +599,24 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, break; } + if (disk->vdev != NULL) { + rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device); + if (rc < 0) + goto out; + be_path = libxl__device_backend_path(gc, &device); + rc = libxl__wait_for_backend(gc, be_path, "4"); + if (rc < 0) + goto out; + } + + *new_disk = disk; + return dev; out: if (t != XBT_NULL) xs_transaction_end(ctx->xsh, t, 1); - *new_disk = disk; - return dev; + else + libxl__device_disk_local_detach(gc, disk); + return NULL; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:13:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSC-0004rQ-0b; Fri, 04 May 2012 11:13:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGSA-0004q1-2j for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:13:38 +0000 Received: from [85.158.143.35:43711] by server-3.bemta-4.messagelabs.com id D6/0C-05853-1E9B3AF4; Fri, 04 May 2012 11:13:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336130015!7539042!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24559 invoked from network); 4 May 2012 11:13:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:13:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24859852" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:13:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 07:13:32 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQGRt-0003Im-TW; Fri, 04 May 2012 12:13:21 +0100 From: Stefano Stabellini To: xen-devel@lists.xensource.com Date: Fri, 4 May 2012 12:13:20 +0100 Message-ID: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Stefano Stabellini Subject: [Xen-devel] [PATCH v5 8/8] libxl__device_disk_local_attach: wait for state "connected" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org In order to make sure that the block device is available and ready to be used, wait for state "connected" in the backend before returning. Signed-off-by: Stefano Stabellini Changes in v5: - unify error paths. Changes in v4: - improve exit paths. Signed-off-by: Stefano Stabellini --- tools/libxl/libxl_internal.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index e180498..05faff5 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -517,8 +517,9 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, const char *blkdev_start) { libxl_ctx *ctx = gc->owner; - char *dev = NULL; + char *dev = NULL, *be_path = NULL; int rc; + libxl__device device; xs_transaction_t t = XBT_NULL; libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); @@ -598,11 +599,24 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, break; } + if (disk->vdev != NULL) { + rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device); + if (rc < 0) + goto out; + be_path = libxl__device_backend_path(gc, &device); + rc = libxl__wait_for_backend(gc, be_path, "4"); + if (rc < 0) + goto out; + } + + *new_disk = disk; + return dev; out: if (t != XBT_NULL) xs_transaction_end(ctx->xsh, t, 1); - *new_disk = disk; - return dev; + else + libxl__device_disk_local_detach(gc, disk); + return NULL; } int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:15:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:15:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTO-0005Or-Sc; Fri, 04 May 2012 11:14:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTN-0005OV-Qz for Xen-devel@lists.xensource.com; Fri, 04 May 2012 11:14:54 +0000 Received: from [193.109.254.147:23240] by server-2.bemta-14.messagelabs.com id 1A/1F-19409-D2AB3AF4; Fri, 04 May 2012 11:14:53 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336130092!767371!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8443 invoked from network); 4 May 2012 11:14: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; 4 May 2012 11:14:52 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQGTK-0001iV-To; Fri, 04 May 2012 11:14:50 +0000 Date: Fri, 4 May 2012 12:14:50 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504111450.GB6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <1336128807.2361.56.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, > > I couldn't find any use other than the definition, although it maybe > open coded somewhere. Looks like maybe it's the absence of it that we should worry about: Mukesh, can you try the attached patch? > > but > > it's possible that vm86 interacts with it (of that we accidentally lose > > some parts of EFLAGS in emulation). > > Yeah, but I can't figure out why hybrid dom0 would change that... Indeed. I'd expect this to fail for the same kernel in normal HVM. Maybe there's some difference in how the segment state is set up Tim. --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=x diff -r 8f556a70ae0b xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu May 03 17:21:09 2012 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Fri May 04 12:13:55 2012 +0100 @@ -372,6 +372,7 @@ typedef union { #define CR4_TSD (1<<2) /* EFLAGS bit definitions. */ +#define EFLG_ID (1<<21) #define EFLG_VIP (1<<20) #define EFLG_VIF (1<<19) #define EFLG_AC (1<<18) @@ -424,7 +425,7 @@ typedef union { * These EFLAGS bits are restored from saved value during emulation, and * any changes are written back to the saved value after emulation. */ -#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF) +#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF|EFLG_ID) /* Before executing instruction: restore necessary bits in EFLAGS. */ #define _PRE_EFLAGS(_sav, _msk, _tmp) \ --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --fUYQa+Pmc3FrFX/N-- From xen-devel-bounces@lists.xen.org Fri May 04 11:15:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:15:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTO-0005Or-Sc; Fri, 04 May 2012 11:14:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTN-0005OV-Qz for Xen-devel@lists.xensource.com; Fri, 04 May 2012 11:14:54 +0000 Received: from [193.109.254.147:23240] by server-2.bemta-14.messagelabs.com id 1A/1F-19409-D2AB3AF4; Fri, 04 May 2012 11:14:53 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336130092!767371!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8443 invoked from network); 4 May 2012 11:14: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; 4 May 2012 11:14:52 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQGTK-0001iV-To; Fri, 04 May 2012 11:14:50 +0000 Date: Fri, 4 May 2012 12:14:50 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504111450.GB6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <1336128807.2361.56.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: "Xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, > > I couldn't find any use other than the definition, although it maybe > open coded somewhere. Looks like maybe it's the absence of it that we should worry about: Mukesh, can you try the attached patch? > > but > > it's possible that vm86 interacts with it (of that we accidentally lose > > some parts of EFLAGS in emulation). > > Yeah, but I can't figure out why hybrid dom0 would change that... Indeed. I'd expect this to fail for the same kernel in normal HVM. Maybe there's some difference in how the segment state is set up Tim. --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=x diff -r 8f556a70ae0b xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu May 03 17:21:09 2012 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Fri May 04 12:13:55 2012 +0100 @@ -372,6 +372,7 @@ typedef union { #define CR4_TSD (1<<2) /* EFLAGS bit definitions. */ +#define EFLG_ID (1<<21) #define EFLG_VIP (1<<20) #define EFLG_VIF (1<<19) #define EFLG_AC (1<<18) @@ -424,7 +425,7 @@ typedef union { * These EFLAGS bits are restored from saved value during emulation, and * any changes are written back to the saved value after emulation. */ -#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF) +#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF|EFLG_ID) /* Before executing instruction: restore necessary bits in EFLAGS. */ #define _PRE_EFLAGS(_sav, _msk, _tmp) \ --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --fUYQa+Pmc3FrFX/N-- From xen-devel-bounces@lists.xen.org Fri May 04 11:15:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:15:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGU0-0005ZX-IE; Fri, 04 May 2012 11:15:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTy-0005Yu-V5 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:15:31 +0000 Received: from [85.158.138.51:54191] by server-11.bemta-3.messagelabs.com id 72/FE-18894-25AB3AF4; Fri, 04 May 2012 11:15:30 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336130128!21180052!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16107 invoked from network); 4 May 2012 11:15:29 -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; 4 May 2012 11:15:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:15: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; Fri, 4 May 2012 12:15:27 +0100 Date: Fri, 4 May 2012 12:15:11 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "Vinaya MS (MT2010166)" In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> , , User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012, Vinaya MS (MT2010166) wrote: > /var/log/xen/qemu-dm-xen10_04.log.2 > > domid: 3 > Using xvda for guest's hda > Using file /home/gpu/XenGuest.img in read-write mode > Watching /local/domain/0/device-model/3/logdirty/cmd > Watching /local/domain/0/device-model/3/command > Watching /local/domain/3/cpu > char device redirected to /dev/pts/2 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = ca8e8bb1-7b8f-13ae-9e67-2feac93b6989 > Time offset set 0 > populating video RAM at ff000000 > mapping video RAM from ff000000 > Register xen platform. > Done register platform. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. > xs_read(/local/domain/0/device-model/3/xen_extended_power_mgmt): read error > Log-dirty: no command yet. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > vcpu-set: watch node error. > xs_read(/local/domain/3/log-throttling): read error > qemu: ignoring not-understood drive `/local/domain/3/log-throttling' > medium change watch on `/local/domain/3/log-throttling' - unknown device, ignored > char device redirected to /dev/pts/3 > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > cirrus vga map change while on lfb mode > mapping vram to f0000000 - f0400000 > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. > dm-command: unknown command"pci-ins" I think that your qemu-dm has been compiled without CONFIG_PASSTHROUGH. Maybe you didn't have pciutils-dev installed? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:15:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:15:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGU0-0005ZX-IE; Fri, 04 May 2012 11:15:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGTy-0005Yu-V5 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:15:31 +0000 Received: from [85.158.138.51:54191] by server-11.bemta-3.messagelabs.com id 72/FE-18894-25AB3AF4; Fri, 04 May 2012 11:15:30 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336130128!21180052!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16107 invoked from network); 4 May 2012 11:15:29 -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; 4 May 2012 11:15:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12295668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:15: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; Fri, 4 May 2012 12:15:27 +0100 Date: Fri, 4 May 2012 12:15:11 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: "Vinaya MS (MT2010166)" In-Reply-To: Message-ID: References: <4E65F794.6060705@gmail.com> , , User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Problems with xen 4.1.x + passthrough + pvonhvm X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012, Vinaya MS (MT2010166) wrote: > /var/log/xen/qemu-dm-xen10_04.log.2 > > domid: 3 > Using xvda for guest's hda > Using file /home/gpu/XenGuest.img in read-write mode > Watching /local/domain/0/device-model/3/logdirty/cmd > Watching /local/domain/0/device-model/3/command > Watching /local/domain/3/cpu > char device redirected to /dev/pts/2 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = ca8e8bb1-7b8f-13ae-9e67-2feac93b6989 > Time offset set 0 > populating video RAM at ff000000 > mapping video RAM from ff000000 > Register xen platform. > Done register platform. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. > xs_read(/local/domain/0/device-model/3/xen_extended_power_mgmt): read error > Log-dirty: no command yet. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > vcpu-set: watch node error. > xs_read(/local/domain/3/log-throttling): read error > qemu: ignoring not-understood drive `/local/domain/3/log-throttling' > medium change watch on `/local/domain/3/log-throttling' - unknown device, ignored > char device redirected to /dev/pts/3 > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > xen be: console-0: xen be: console-0: initialise() failed > initialise() failed > cirrus vga map change while on lfb mode > mapping vram to f0000000 - f0400000 > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. > dm-command: unknown command"pci-ins" I think that your qemu-dm has been compiled without CONFIG_PASSTHROUGH. Maybe you didn't have pciutils-dev installed? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:19:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGXf-0006Hr-7d; Fri, 04 May 2012 11:19:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGXd-0006Hi-BG for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:19:17 +0000 Received: from [85.158.138.51:4021] by server-8.bemta-3.messagelabs.com id 9C/99-24428-43BB3AF4; Fri, 04 May 2012 11:19:16 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-174.messagelabs.com!1336130355!25281029!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14553 invoked from network); 4 May 2012 11:19:15 -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; 4 May 2012 11:19:15 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQGXa-0001k5-Px; Fri, 04 May 2012 11:19:14 +0000 Date: Fri, 4 May 2012 12:19:14 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504111914.GC6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> <20120504111450.GB6127@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120504111450.GB6127@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (oops, seem to have dropped Mukesh from CC) At 12:14 +0100 on 04 May (1336133690), Tim Deegan wrote: > At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: > > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, > > > > I couldn't find any use other than the definition, although it maybe > > open coded somewhere. > > Looks like maybe it's the absence of it that we should worry about: > Mukesh, can you try the attached patch? > > > > but > > > it's possible that vm86 interacts with it (of that we accidentally lose > > > some parts of EFLAGS in emulation). > > > > Yeah, but I can't figure out why hybrid dom0 would change that... > > Indeed. I'd expect this to fail for the same kernel in normal HVM. > Maybe there's some difference in how the segment state is set up > > Tim. > diff -r 8f556a70ae0b xen/arch/x86/x86_emulate/x86_emulate.c > --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu May 03 17:21:09 2012 +0100 > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Fri May 04 12:13:55 2012 +0100 > @@ -372,6 +372,7 @@ typedef union { > #define CR4_TSD (1<<2) > > /* EFLAGS bit definitions. */ > +#define EFLG_ID (1<<21) > #define EFLG_VIP (1<<20) > #define EFLG_VIF (1<<19) > #define EFLG_AC (1<<18) > @@ -424,7 +425,7 @@ typedef union { > * These EFLAGS bits are restored from saved value during emulation, and > * any changes are written back to the saved value after emulation. > */ > -#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF) > +#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF|EFLG_ID) > > /* Before executing instruction: restore necessary bits in EFLAGS. */ > #define _PRE_EFLAGS(_sav, _msk, _tmp) \ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:19:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGXf-0006Hr-7d; Fri, 04 May 2012 11:19:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGXd-0006Hi-BG for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:19:17 +0000 Received: from [85.158.138.51:4021] by server-8.bemta-3.messagelabs.com id 9C/99-24428-43BB3AF4; Fri, 04 May 2012 11:19:16 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-174.messagelabs.com!1336130355!25281029!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14553 invoked from network); 4 May 2012 11:19:15 -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; 4 May 2012 11:19:15 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SQGXa-0001k5-Px; Fri, 04 May 2012 11:19:14 +0000 Date: Fri, 4 May 2012 12:19:14 +0100 From: Tim Deegan To: Ian Campbell Message-ID: <20120504111914.GC6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> <20120504111450.GB6127@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120504111450.GB6127@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (oops, seem to have dropped Mukesh from CC) At 12:14 +0100 on 04 May (1336133690), Tim Deegan wrote: > At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: > > > I'm not aware of anything deliberately tinkering with EFLAGS_ID, > > > > I couldn't find any use other than the definition, although it maybe > > open coded somewhere. > > Looks like maybe it's the absence of it that we should worry about: > Mukesh, can you try the attached patch? > > > > but > > > it's possible that vm86 interacts with it (of that we accidentally lose > > > some parts of EFLAGS in emulation). > > > > Yeah, but I can't figure out why hybrid dom0 would change that... > > Indeed. I'd expect this to fail for the same kernel in normal HVM. > Maybe there's some difference in how the segment state is set up > > Tim. > diff -r 8f556a70ae0b xen/arch/x86/x86_emulate/x86_emulate.c > --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu May 03 17:21:09 2012 +0100 > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Fri May 04 12:13:55 2012 +0100 > @@ -372,6 +372,7 @@ typedef union { > #define CR4_TSD (1<<2) > > /* EFLAGS bit definitions. */ > +#define EFLG_ID (1<<21) > #define EFLG_VIP (1<<20) > #define EFLG_VIF (1<<19) > #define EFLG_AC (1<<18) > @@ -424,7 +425,7 @@ typedef union { > * These EFLAGS bits are restored from saved value during emulation, and > * any changes are written back to the saved value after emulation. > */ > -#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF) > +#define EFLAGS_MASK (EFLG_OF|EFLG_SF|EFLG_ZF|EFLG_AF|EFLG_PF|EFLG_CF|EFLG_ID) > > /* Before executing instruction: restore necessary bits in EFLAGS. */ > #define _PRE_EFLAGS(_sav, _msk, _tmp) \ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:21:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQGZt-0006PE-Ox; Fri, 04 May 2012 11:21:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGZs-0006P4-CG for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:21:36 +0000 Received: from [193.109.254.147:56570] by server-12.bemta-14.messagelabs.com id C8/54-05898-FBBB3AF4; Fri, 04 May 2012 11:21:35 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336130493!7668388!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24326 invoked from network); 4 May 2012 11:21:35 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:21:35 -0000 Received: by yenq11 with SMTP id q11so2000847yen.30 for ; Fri, 04 May 2012 04:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9S4jBJQOKhEx4pAbt/EqI3nRN6szZg/HkJtyOe6v4Qg=; b=zoT8btDefp/N6t9boxWqLxVMexwwwQ1pjCBa+95VYemdCuD79ru9ael8unti57EoKh s4GVkKkyO9Pb5MvrIN91nksIGuI5pOdqep6V5N5szChuPnD1ZseQSHDCLeLTwqh2Sv78 3mCQf2smMyETxQa5RMOn2qJLuwWAl+RXJ08mTHZLR5rvFoBZbK8vg+lOQCSWhqkSR/2U YYGyOLL44gne3m3EVRMFpMQ6eUWhaaqhbtlEf2LBV5YAOHkNwhd2wLQI9LniBccq6tb8 99KIy7uvoiuwq6TJ+uHcZNEdSt+/BosfsYK5vMHeLcwHBKMedzIHh/417cEPb+aH7G4P mxLw== Received: by 10.50.220.136 with SMTP id pw8mr2784392igc.1.1336130493222; Fri, 04 May 2012 04:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Fri, 4 May 2012 04:21:03 -0700 (PDT) In-Reply-To: <1336120109.26385.7.camel@dagon.hellion.org.uk> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> From: Anthony PERARD Date: Fri, 4 May 2012 12:21:03 +0100 X-Google-Sender-Auth: 4JYQHEtCFdAi3zmJImVCR4LWJuM Message-ID: To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > Anthony -- any idea why the videoram setting doesn't work with upstream > qemu? Well, the parameter could be pass to qemu qxl, but it's not yet. But then, it seams you have to have this value of at least 32MB, otherwise the value is increase in qemu. For cirrus/stdvga, there is no way to pass the parameter to qemu, the size in qemu is fixed to 8MB. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:21:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQGZt-0006PE-Ox; Fri, 04 May 2012 11:21:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGZs-0006P4-CG for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:21:36 +0000 Received: from [193.109.254.147:56570] by server-12.bemta-14.messagelabs.com id C8/54-05898-FBBB3AF4; Fri, 04 May 2012 11:21:35 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336130493!7668388!1 X-Originating-IP: [209.85.213.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24326 invoked from network); 4 May 2012 11:21:35 -0000 Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:21:35 -0000 Received: by yenq11 with SMTP id q11so2000847yen.30 for ; Fri, 04 May 2012 04:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9S4jBJQOKhEx4pAbt/EqI3nRN6szZg/HkJtyOe6v4Qg=; b=zoT8btDefp/N6t9boxWqLxVMexwwwQ1pjCBa+95VYemdCuD79ru9ael8unti57EoKh s4GVkKkyO9Pb5MvrIN91nksIGuI5pOdqep6V5N5szChuPnD1ZseQSHDCLeLTwqh2Sv78 3mCQf2smMyETxQa5RMOn2qJLuwWAl+RXJ08mTHZLR5rvFoBZbK8vg+lOQCSWhqkSR/2U YYGyOLL44gne3m3EVRMFpMQ6eUWhaaqhbtlEf2LBV5YAOHkNwhd2wLQI9LniBccq6tb8 99KIy7uvoiuwq6TJ+uHcZNEdSt+/BosfsYK5vMHeLcwHBKMedzIHh/417cEPb+aH7G4P mxLw== Received: by 10.50.220.136 with SMTP id pw8mr2784392igc.1.1336130493222; Fri, 04 May 2012 04:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Fri, 4 May 2012 04:21:03 -0700 (PDT) In-Reply-To: <1336120109.26385.7.camel@dagon.hellion.org.uk> References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> From: Anthony PERARD Date: Fri, 4 May 2012 12:21:03 +0100 X-Google-Sender-Auth: 4JYQHEtCFdAi3zmJImVCR4LWJuM Message-ID: To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > Anthony -- any idea why the videoram setting doesn't work with upstream > qemu? Well, the parameter could be pass to qemu qxl, but it's not yet. But then, it seams you have to have this value of at least 32MB, otherwise the value is increase in qemu. For cirrus/stdvga, there is no way to pass the parameter to qemu, the size in qemu is fixed to 8MB. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:28:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:28:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGfu-0006c4-Nk; Fri, 04 May 2012 11:27:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGft-0006bz-Lm for Xen-devel@lists.xensource.com; Fri, 04 May 2012 11:27:49 +0000 Received: from [85.158.138.51:2943] by server-4.bemta-3.messagelabs.com id 8D/4A-15341-43DB3AF4; Fri, 04 May 2012 11:27:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336130867!14246866!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10242 invoked from network); 4 May 2012 11:27:48 -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; 4 May 2012 11:27:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:27:47 +0100 Message-Id: <4FA3D95102000078000819CB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:27:45 +0100 From: "Jan Beulich" To: "Tim Deegan" References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> <20120504111450.GB6127@ocelot.phlegethon.org> In-Reply-To: <20120504111450.GB6127@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline Cc: "Xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:14, Tim Deegan wrote: > At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: >> > I'm not aware of anything deliberately tinkering with EFLAGS_ID, >> >> I couldn't find any use other than the definition, although it maybe >> open coded somewhere. > > Looks like maybe it's the absence of it that we should worry about: > Mukesh, can you try the attached patch? But EFLAGS_MASK doesn't affect PUSHF/POPF emulation, and that's the only ones that would matter here (short of some of the arithmetic emulation being broken, which wouldn't be addressed by this mask change either). POPF emulation itself only disallows modifying VIP, VIF, and VM. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:28:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:28:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGfu-0006c4-Nk; Fri, 04 May 2012 11:27:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGft-0006bz-Lm for Xen-devel@lists.xensource.com; Fri, 04 May 2012 11:27:49 +0000 Received: from [85.158.138.51:2943] by server-4.bemta-3.messagelabs.com id 8D/4A-15341-43DB3AF4; Fri, 04 May 2012 11:27:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336130867!14246866!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10242 invoked from network); 4 May 2012 11:27:48 -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; 4 May 2012 11:27:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:27:47 +0100 Message-Id: <4FA3D95102000078000819CB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:27:45 +0100 From: "Jan Beulich" To: "Tim Deegan" References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504104902.GA6127@ocelot.phlegethon.org> <1336128807.2361.56.camel@zakaz.uk.xensource.com> <20120504111450.GB6127@ocelot.phlegethon.org> In-Reply-To: <20120504111450.GB6127@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline Cc: "Xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:14, Tim Deegan wrote: > At 11:53 +0100 on 04 May (1336132407), Ian Campbell wrote: >> > I'm not aware of anything deliberately tinkering with EFLAGS_ID, >> >> I couldn't find any use other than the definition, although it maybe >> open coded somewhere. > > Looks like maybe it's the absence of it that we should worry about: > Mukesh, can you try the attached patch? But EFLAGS_MASK doesn't affect PUSHF/POPF emulation, and that's the only ones that would matter here (short of some of the arithmetic emulation being broken, which wouldn't be addressed by this mask change either). POPF emulation itself only disallows modifying VIP, VIF, and VM. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:31:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:31:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGj3-0006k4-AW; Fri, 04 May 2012 11:31:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGj1-0006jv-Ni for xen-devel@lists.xen.org; Fri, 04 May 2012 11:31:03 +0000 Received: from [85.158.138.51:13219] by server-8.bemta-3.messagelabs.com id A2/9F-24428-6FDB3AF4; Fri, 04 May 2012 11:31:02 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336131061!16311393!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25911 invoked from network); 4 May 2012 11:31:02 -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; 4 May 2012 11:31:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:31:01 +0100 Message-Id: <4FA3DA1302000078000819D6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:30:59 +0100 From: "Jan Beulich" To: "GabrielX Wu" References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 12:06, "Wu, GabrielX" wrote: > 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning > information > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 Are you sure you still see those messages? Original separate testing of the patch before it went in confirmed they were gone. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:31:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:31:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGj3-0006k4-AW; Fri, 04 May 2012 11:31:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGj1-0006jv-Ni for xen-devel@lists.xen.org; Fri, 04 May 2012 11:31:03 +0000 Received: from [85.158.138.51:13219] by server-8.bemta-3.messagelabs.com id A2/9F-24428-6FDB3AF4; Fri, 04 May 2012 11:31:02 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336131061!16311393!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25911 invoked from network); 4 May 2012 11:31:02 -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; 4 May 2012 11:31:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 12:31:01 +0100 Message-Id: <4FA3DA1302000078000819D6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 12:30:59 +0100 From: "Jan Beulich" To: "GabrielX Wu" References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 12:06, "Wu, GabrielX" wrote: > 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning > information > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 Are you sure you still see those messages? Original separate testing of the patch before it went in confirmed they were gone. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:32:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:32:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGkJ-0006pF-P3; Fri, 04 May 2012 11:32:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGkI-0006p5-E1 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:32:22 +0000 Received: from [193.109.254.147:31950] by server-3.bemta-14.messagelabs.com id A5/C3-23274-54EB3AF4; Fri, 04 May 2012 11:32:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336131141!2475696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30404 invoked from network); 4 May 2012 11:32:21 -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 May 2012 11:32:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12296015" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:32: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, 4 May 2012 12:32:20 +0100 Message-ID: <1336131139.2361.60.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 4 May 2012 12:32:19 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > Anthony -- any idea why the videoram setting doesn't work with upstream > > qemu? > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > then, it seams you have to have this value of at least 32MB, otherwise > the value is increase in qemu. > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. OK, so this is simply a feature which upstream qemu doesn't have. That's fine. I guess xl.cfg(5) needs updating to make it clear that this option only applies to qemu-xen-traditional. The docs also currently say that for stdvga the default is 8MB and for not stdvga (by which I guess it means Cirrus) the default if 4MB. So I guess even this is inaccurate for qemu-xen-upstream? Can someone send a patch please? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:32:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11:32:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGkJ-0006pF-P3; Fri, 04 May 2012 11:32:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGkI-0006p5-E1 for xen-devel@lists.xensource.com; Fri, 04 May 2012 11:32:22 +0000 Received: from [193.109.254.147:31950] by server-3.bemta-14.messagelabs.com id A5/C3-23274-54EB3AF4; Fri, 04 May 2012 11:32:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336131141!2475696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30404 invoked from network); 4 May 2012 11:32:21 -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 May 2012 11:32:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12296015" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:32: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, 4 May 2012 12:32:20 +0100 Message-ID: <1336131139.2361.60.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 4 May 2012 12:32:19 +0100 In-Reply-To: References: <1335453835300-5667919.post@n5.nabble.com> <1335454757.28015.160.camel@zakaz.uk.xensource.com> <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > Anthony -- any idea why the videoram setting doesn't work with upstream > > qemu? > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > then, it seams you have to have this value of at least 32MB, otherwise > the value is increase in qemu. > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. OK, so this is simply a feature which upstream qemu doesn't have. That's fine. I guess xl.cfg(5) needs updating to make it clear that this option only applies to qemu-xen-traditional. The docs also currently say that for stdvga the default is 8MB and for not stdvga (by which I guess it means Cirrus) the default if 4MB. So I guess even this is inaccurate for qemu-xen-upstream? Can someone send a patch please? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 11:42:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGuB-00074d-Sk; Fri, 04 May 2012 11:42:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGuA-00074Y-Nu for xen-devel@lists.xen.org; Fri, 04 May 2012 11:42:34 +0000 Received: from [85.158.138.51:26028] by server-6.bemta-3.messagelabs.com id A1/18-05145-9A0C3AF4; Fri, 04 May 2012 11:42:33 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336131751!25300379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15633 invoked from network); 4 May 2012 11:42:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:42:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193398508" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:42:30 -0400 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, 4 May 2012 07:42:30 -0400 Message-ID: <4FA3C0A5.7030309@citrix.com> Date: Fri, 4 May 2012 12:42:29 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------050301060803020709070907" Cc: Keir Fraser , Jan Beulich Subject: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------050301060803020709070907 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I know that xen-unstable is on a feature freeze, and this is not strictly a bugfix (yet; see below), but as it is safe and designed to help clarity in the case of a crash, so I request that it be considered for inclusion. I have constructed an artificial case where the information reported in 1 per-cpu crash note was stale by using low_crashinfo mode, crashing Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This leaves stale register state written into the offlined CPU crash information. In this case, the information was stale but correct, due to the predictable nature of the Xen crash path from the 'C' debug key, but there is no guarantee that in the case of a real crash, the same will still be true. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------050301060803020709070907 Content-Type: text/x-patch; name="kexec-clear-notes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kexec-clear-notes.patch" # HG changeset patch # Parent 98fe3b2a572d4ffe704124e75c7aa8d94dbb51bc kexec: clear notes during setup Explicity zero the memory backing the crash notes during setup. This allows the crash environment to be rather more certain whether the crash notes were actually written, rather than trusting that the memory was clear beforehand. Signed-off-by: Andrew Cooper diff -r 98fe3b2a572d xen/common/kexec.c --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -401,7 +401,7 @@ static int kexec_init_cpu_notes(const un /* If we dont care about the position of allocation, malloc. */ if ( low_crashinfo_mode == LOW_CRASHINFO_NONE ) - note = xmalloc_bytes(nr_bytes); + note = xzalloc_bytes(nr_bytes); /* Protect the write into crash_notes[] with a spinlock, as this function * is on a hotplug path and a hypercall path. */ @@ -505,7 +505,7 @@ static int __init kexec_init(void) if ( low_crashinfo_mode > LOW_CRASHINFO_NONE ) { - size_t crash_heap_size; + size_t crash_heap_size, i; /* This calculation is safe even if the machine is booted in * uniprocessor mode. */ @@ -520,6 +520,9 @@ static int __init kexec_init(void) if ( ! crash_heap_current ) return -ENOMEM; + for ( i=0; i< (crash_heap_size >> PAGE_SHIFT); ++i ) + clear_page(crash_heap_current + (i << PAGE_SHIFT)); + crash_heap_end = crash_heap_current + crash_heap_size; } --------------050301060803020709070907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------050301060803020709070907-- From xen-devel-bounces@lists.xen.org Fri May 04 11:42:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 11: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 ) id 1SQGuB-00074d-Sk; Fri, 04 May 2012 11:42:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQGuA-00074Y-Nu for xen-devel@lists.xen.org; Fri, 04 May 2012 11:42:34 +0000 Received: from [85.158.138.51:26028] by server-6.bemta-3.messagelabs.com id A1/18-05145-9A0C3AF4; Fri, 04 May 2012 11:42:33 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336131751!25300379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15633 invoked from network); 4 May 2012 11:42:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 11:42:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193398508" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 07:42:30 -0400 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, 4 May 2012 07:42:30 -0400 Message-ID: <4FA3C0A5.7030309@citrix.com> Date: Fri, 4 May 2012 12:42:29 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------050301060803020709070907" Cc: Keir Fraser , Jan Beulich Subject: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------050301060803020709070907 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I know that xen-unstable is on a feature freeze, and this is not strictly a bugfix (yet; see below), but as it is safe and designed to help clarity in the case of a crash, so I request that it be considered for inclusion. I have constructed an artificial case where the information reported in 1 per-cpu crash note was stale by using low_crashinfo mode, crashing Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This leaves stale register state written into the offlined CPU crash information. In this case, the information was stale but correct, due to the predictable nature of the Xen crash path from the 'C' debug key, but there is no guarantee that in the case of a real crash, the same will still be true. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------050301060803020709070907 Content-Type: text/x-patch; name="kexec-clear-notes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kexec-clear-notes.patch" # HG changeset patch # Parent 98fe3b2a572d4ffe704124e75c7aa8d94dbb51bc kexec: clear notes during setup Explicity zero the memory backing the crash notes during setup. This allows the crash environment to be rather more certain whether the crash notes were actually written, rather than trusting that the memory was clear beforehand. Signed-off-by: Andrew Cooper diff -r 98fe3b2a572d xen/common/kexec.c --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -401,7 +401,7 @@ static int kexec_init_cpu_notes(const un /* If we dont care about the position of allocation, malloc. */ if ( low_crashinfo_mode == LOW_CRASHINFO_NONE ) - note = xmalloc_bytes(nr_bytes); + note = xzalloc_bytes(nr_bytes); /* Protect the write into crash_notes[] with a spinlock, as this function * is on a hotplug path and a hypercall path. */ @@ -505,7 +505,7 @@ static int __init kexec_init(void) if ( low_crashinfo_mode > LOW_CRASHINFO_NONE ) { - size_t crash_heap_size; + size_t crash_heap_size, i; /* This calculation is safe even if the machine is booted in * uniprocessor mode. */ @@ -520,6 +520,9 @@ static int __init kexec_init(void) if ( ! crash_heap_current ) return -ENOMEM; + for ( i=0; i< (crash_heap_size >> PAGE_SHIFT); ++i ) + clear_page(crash_heap_current + (i << PAGE_SHIFT)); + crash_heap_end = crash_heap_current + crash_heap_size; } --------------050301060803020709070907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------050301060803020709070907-- From xen-devel-bounces@lists.xen.org Fri May 04 12:03:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:03:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHDw-0007dj-Dv; Fri, 04 May 2012 12:03:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHDv-0007dc-En for xen-devel@lists.xensource.com; Fri, 04 May 2012 12:02:59 +0000 Received: from [193.109.254.147:27133] by server-1.bemta-14.messagelabs.com id 7F/52-29372-275C3AF4; Fri, 04 May 2012 12:02:58 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-2.tower-27.messagelabs.com!1336132977!7618524!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6238 invoked from network); 4 May 2012 12:02:58 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 12:02:58 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQHDs-0003Y8-DL for xen-devel@lists.xensource.com; Fri, 04 May 2012 05:02:56 -0700 Date: Fri, 4 May 2012 05:02:56 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336132976402-5685659.post@n5.nabble.com> In-Reply-To: References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD-2 wrote > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell <Ian.Campbell@> wrote: >> Anthony -- any idea why the videoram setting doesn't work with upstream >> qemu? > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > then, it seams you have to have this value of at least 32MB, otherwise > the value is increase in qemu. > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. > > -- > Anthony PERARD > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > I have already tried -global qxl-vga.vram_size for setting more videoram on qxl but not work,have always 4 mb, also with qemu-upstream unstable, the default code in qemu should have 64 mb and minimum 16 mb, why and where it sets 4 mb? Now I will try also with 1.1-rc0 and seabios 1.7.0. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5685659.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:03:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:03:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHDw-0007dj-Dv; Fri, 04 May 2012 12:03:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHDv-0007dc-En for xen-devel@lists.xensource.com; Fri, 04 May 2012 12:02:59 +0000 Received: from [193.109.254.147:27133] by server-1.bemta-14.messagelabs.com id 7F/52-29372-275C3AF4; Fri, 04 May 2012 12:02:58 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-2.tower-27.messagelabs.com!1336132977!7618524!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6238 invoked from network); 4 May 2012 12:02:58 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 12:02:58 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SQHDs-0003Y8-DL for xen-devel@lists.xensource.com; Fri, 04 May 2012 05:02:56 -0700 Date: Fri, 4 May 2012 05:02:56 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336132976402-5685659.post@n5.nabble.com> In-Reply-To: References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD-2 wrote > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell <Ian.Campbell@> wrote: >> Anthony -- any idea why the videoram setting doesn't work with upstream >> qemu? > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > then, it seams you have to have this value of at least 32MB, otherwise > the value is increase in qemu. > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. > > -- > Anthony PERARD > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > I have already tried -global qxl-vga.vram_size for setting more videoram on qxl but not work,have always 4 mb, also with qemu-upstream unstable, the default code in qemu should have 64 mb and minimum 16 mb, why and where it sets 4 mb? Now I will try also with 1.1-rc0 and seabios 1.7.0. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5685659.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:03:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:03:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHEW-0007h0-RO; Fri, 04 May 2012 12:03:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHEU-0007gh-W7 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:03:35 +0000 Received: from [85.158.139.83:32021] by server-8.bemta-5.messagelabs.com id A4/87-26964-695C3AF4; Fri, 04 May 2012 12:03:34 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336133013!26225025!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2453 invoked from network); 4 May 2012 12:03:33 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:03:33 -0000 Received: by eekc4 with SMTP id c4so341128eek.32 for ; Fri, 04 May 2012 05:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=WDzpZXKrWnq6NuDCcWpqJKkv9402Qy07i5qKOYgorxM=; b=APaET2yStdXe37u6jeYdFSbBNcKWsNi4JYmPk7Wj7gHv5XOvtCKv64eH6dMsvwGsUP YpDmbL3qAAPNL3lcqprsgEK3K2t7LItvi4mNMQWreXAc3a5tZFRV/7W5JEEd0vlGocXP 2kVjGJkV3qH3bBdrLNAeyP4txpLCD728TRHlGIyDKh+sx8IAUsf7+mc1BIVkP8Y91yMI 2dV+bd/21t+Fae+lxRE4I6BgJQ/DyEhKc2WnnDhz5SaVajl82tRnVNFRZCG0XT2z7UBg qJmDVAa8/tynZr3kY0KeiTGSbdWbeI1Q02+UKdeDwJCydJw2iLZMhTx5BSbu4sdmnpVi XXOQ== Received: by 10.14.52.133 with SMTP id e5mr1091655eec.127.1336133013155; Fri, 04 May 2012 05:03:33 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id e56sm40556817eea.11.2012.05.04.05.03.32 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 05:03:32 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 13:03:24 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p7egB5aWCdwmCcUyc7rTf6Ze7FQ== In-Reply-To: <4FA3D4320200007800081987@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 12:05, "Jan Beulich" wrote: >> I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes >> per CPU of the poll_port variable isn't worth much optimising effort. > > Certainly not (and as you say they are actually needed, even if > only rarely). But the pointlessly running timer(s) might be, as might > the buffer(s) set up via serial_async_transmit(). We could delay {init,setup}_postirq until a corresponding serial handle has been created via serial_parse_handle()? The logic might be a bit ugly and spread across both serial.c and ns16550.c but not actually particularly complicated? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:03:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:03:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHEW-0007h0-RO; Fri, 04 May 2012 12:03:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHEU-0007gh-W7 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:03:35 +0000 Received: from [85.158.139.83:32021] by server-8.bemta-5.messagelabs.com id A4/87-26964-695C3AF4; Fri, 04 May 2012 12:03:34 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336133013!26225025!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2453 invoked from network); 4 May 2012 12:03:33 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:03:33 -0000 Received: by eekc4 with SMTP id c4so341128eek.32 for ; Fri, 04 May 2012 05:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=WDzpZXKrWnq6NuDCcWpqJKkv9402Qy07i5qKOYgorxM=; b=APaET2yStdXe37u6jeYdFSbBNcKWsNi4JYmPk7Wj7gHv5XOvtCKv64eH6dMsvwGsUP YpDmbL3qAAPNL3lcqprsgEK3K2t7LItvi4mNMQWreXAc3a5tZFRV/7W5JEEd0vlGocXP 2kVjGJkV3qH3bBdrLNAeyP4txpLCD728TRHlGIyDKh+sx8IAUsf7+mc1BIVkP8Y91yMI 2dV+bd/21t+Fae+lxRE4I6BgJQ/DyEhKc2WnnDhz5SaVajl82tRnVNFRZCG0XT2z7UBg qJmDVAa8/tynZr3kY0KeiTGSbdWbeI1Q02+UKdeDwJCydJw2iLZMhTx5BSbu4sdmnpVi XXOQ== Received: by 10.14.52.133 with SMTP id e5mr1091655eec.127.1336133013155; Fri, 04 May 2012 05:03:33 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id e56sm40556817eea.11.2012.05.04.05.03.32 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 05:03:32 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 13:03:24 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p7egB5aWCdwmCcUyc7rTf6Ze7FQ== In-Reply-To: <4FA3D4320200007800081987@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 12:05, "Jan Beulich" wrote: >> I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes >> per CPU of the poll_port variable isn't worth much optimising effort. > > Certainly not (and as you say they are actually needed, even if > only rarely). But the pointlessly running timer(s) might be, as might > the buffer(s) set up via serial_async_transmit(). We could delay {init,setup}_postirq until a corresponding serial handle has been created via serial_parse_handle()? The logic might be a bit ugly and spread across both serial.c and ns16550.c but not actually particularly complicated? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:36:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQHjz-00006f-Qi; Fri, 04 May 2012 12:36:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHjy-00006a-63 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:36:06 +0000 Received: from [85.158.143.99:15088] by server-1.bemta-4.messagelabs.com id D4/CF-20925-53DC3AF4; Fri, 04 May 2012 12:36:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336134964!23131772!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8457 invoked from network); 4 May 2012 12:36:04 -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; 4 May 2012 12:36:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:36:04 +0100 Message-Id: <4FA3E9530200007800081A2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:36:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part6A448B23.0__=" Subject: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6A448B23.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ... as it conflicts with the one made in asm/byteorder.h, and hence build fails when both happen to be included from the same source file. Signed-off-by: Jan Beulich --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -3,6 +3,7 @@ =20 #include #include +#include =20 /* * Constants for Intel APIC based MSI messages. @@ -165,8 +166,6 @@ int msi_free_irq(struct msi_desc *entry) #define MSI_LOGICAL_MODE 1 #define MSI_REDIRECTION_HINT_MODE 0 =20 -#define __LITTLE_ENDIAN_BITFIELD 1 - struct msg_data { #if defined(__LITTLE_ENDIAN_BITFIELD) __u32 vector : 8; --=__Part6A448B23.0__= Content-Type: text/plain; name="x86-msi-endianness.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-msi-endianness.patch" x86/MSI: remove stray endianness definition=0A=0A... as it conflicts with = the one made in asm/byteorder.h, and hence=0Abuild fails when both happen = to be included from the same source file.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/includ= e/asm-x86/msi.h=0A@@ -3,6 +3,7 @@=0A =0A #include =0A = #include =0A+#include =0A =0A /*=0A * = Constants for Intel APIC based MSI messages.=0A@@ -165,8 +166,6 @@ int = msi_free_irq(struct msi_desc *entry)=0A #define MSI_LOGICAL_MODE = 1=0A #define MSI_REDIRECTION_HINT_MODE 0=0A =0A-#define __LITTLE_ENDIAN_BI= TFIELD 1=0A-=0A struct msg_data {=0A #if defined(__LITTLE_ENDIAN_BITFIELD)= =0A __u32 vector : 8;=0A --=__Part6A448B23.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part6A448B23.0__=-- From xen-devel-bounces@lists.xen.org Fri May 04 12:36:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQHjz-00006f-Qi; Fri, 04 May 2012 12:36:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHjy-00006a-63 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:36:06 +0000 Received: from [85.158.143.99:15088] by server-1.bemta-4.messagelabs.com id D4/CF-20925-53DC3AF4; Fri, 04 May 2012 12:36:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336134964!23131772!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8457 invoked from network); 4 May 2012 12:36:04 -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; 4 May 2012 12:36:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:36:04 +0100 Message-Id: <4FA3E9530200007800081A2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:36:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part6A448B23.0__=" Subject: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6A448B23.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ... as it conflicts with the one made in asm/byteorder.h, and hence build fails when both happen to be included from the same source file. Signed-off-by: Jan Beulich --- a/xen/include/asm-x86/msi.h +++ b/xen/include/asm-x86/msi.h @@ -3,6 +3,7 @@ =20 #include #include +#include =20 /* * Constants for Intel APIC based MSI messages. @@ -165,8 +166,6 @@ int msi_free_irq(struct msi_desc *entry) #define MSI_LOGICAL_MODE 1 #define MSI_REDIRECTION_HINT_MODE 0 =20 -#define __LITTLE_ENDIAN_BITFIELD 1 - struct msg_data { #if defined(__LITTLE_ENDIAN_BITFIELD) __u32 vector : 8; --=__Part6A448B23.0__= Content-Type: text/plain; name="x86-msi-endianness.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-msi-endianness.patch" x86/MSI: remove stray endianness definition=0A=0A... as it conflicts with = the one made in asm/byteorder.h, and hence=0Abuild fails when both happen = to be included from the same source file.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/includ= e/asm-x86/msi.h=0A@@ -3,6 +3,7 @@=0A =0A #include =0A = #include =0A+#include =0A =0A /*=0A * = Constants for Intel APIC based MSI messages.=0A@@ -165,8 +166,6 @@ int = msi_free_irq(struct msi_desc *entry)=0A #define MSI_LOGICAL_MODE = 1=0A #define MSI_REDIRECTION_HINT_MODE 0=0A =0A-#define __LITTLE_ENDIAN_BI= TFIELD 1=0A-=0A struct msg_data {=0A #if defined(__LITTLE_ENDIAN_BITFIELD)= =0A __u32 vector : 8;=0A --=__Part6A448B23.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part6A448B23.0__=-- From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009u-KN; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkx-00009K-GN for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:07 +0000 Received: from [85.158.138.51:25932] by server-10.bemta-3.messagelabs.com id 24/F7-29478-27DC3AF4; Fri, 04 May 2012 12:37:06 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8035 invoked from network); 4 May 2012 12:37:05 -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; 4 May 2012 12:37:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861934" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-OL; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:44 +0100 Message-ID: <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Qemu debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bios was outputing into port 0xe9 while Qemu use 0x12 Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vgabios.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c index a9dbe00..e0b1ed9 100644 --- a/tools/firmware/vgabios/vgabios.c +++ b/tools/firmware/vgabios/vgabios.c @@ -3811,9 +3811,9 @@ void printf(s) for (i=0; i> (4 * digit)) & 0x000f; if (nibble <= 9) - outb(0xe9, nibble + '0'); + outb(0x12, nibble + '0'); else - outb(0xe9, (nibble - 10) + 'A'); + outb(0x12, (nibble - 10) + 'A'); digit--; } in_format = 0; @@ -3823,7 +3823,7 @@ void printf(s) // } } else { - outb(0xe9, c); + outb(0x12, c); } s ++; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009u-KN; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkx-00009K-GN for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:07 +0000 Received: from [85.158.138.51:25932] by server-10.bemta-3.messagelabs.com id 24/F7-29478-27DC3AF4; Fri, 04 May 2012 12:37:06 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8035 invoked from network); 4 May 2012 12:37:05 -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; 4 May 2012 12:37:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861934" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-OL; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:44 +0100 Message-ID: <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 1/7] vgabios: Output to Qemu debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bios was outputing into port 0xe9 while Qemu use 0x12 Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vgabios.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c index a9dbe00..e0b1ed9 100644 --- a/tools/firmware/vgabios/vgabios.c +++ b/tools/firmware/vgabios/vgabios.c @@ -3811,9 +3811,9 @@ void printf(s) for (i=0; i> (4 * digit)) & 0x000f; if (nibble <= 9) - outb(0xe9, nibble + '0'); + outb(0x12, nibble + '0'); else - outb(0xe9, (nibble - 10) + 'A'); + outb(0x12, (nibble - 10) + 'A'); digit--; } in_format = 0; @@ -3823,7 +3823,7 @@ void printf(s) // } } else { - outb(0xe9, c); + outb(0x12, c); } s ++; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl0-0000AM-G4; Fri, 04 May 2012 12:37:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009P-Ao for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.139.83:48407] by server-1.bemta-5.messagelabs.com id 5B/07-28458-37DC3AF4; Fri, 04 May 2012 12:37:07 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6342 invoked from network); 4 May 2012 12:37:06 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861936" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-PH; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:46 +0100 Message-ID: <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove an overflow computing width x height x bit which does not fit into a 16 bits. I wrote a routine to multiple these value and get the size required for framebuffer in segment unit (64k). Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- 1 files changed, 28 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3d42216..35d9866 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -742,6 +742,29 @@ no_vbe_flag: jmp _display_string ASM_END +ASM_START +_size64: + push bp + mov bp, sp + push dx + +; multiply bbp by yres first as results fit in 16bits +; then multiply by xres + mov ax, 8[bp] + mul word 6[bp] + mul word 4[bp] +; divide by 2^19 ceiling result + add ax, #0xffff + adc dx, #7 + mov ax, dx + shr ax, #3 + + pop dx + pop bp + ret +ASM_END + + /** Function 00h - Return VBE Controller Information * * Input: @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; do { + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); + Bit16u max_bpp = dispi_get_max_bpp(); + if ((cur_info->info.XResolution <= dispi_get_max_xres()) && - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { + (cur_info->info.BitsPerPixel <= max_bpp) && + (size_64k <= vbe_info_block.TotalMemory)) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); cur_mode++; -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl0-0000AM-G4; Fri, 04 May 2012 12:37:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009P-Ao for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.139.83:48407] by server-1.bemta-5.messagelabs.com id 5B/07-28458-37DC3AF4; Fri, 04 May 2012 12:37:07 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6342 invoked from network); 4 May 2012 12:37:06 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861936" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-PH; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:46 +0100 Message-ID: <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove an overflow computing width x height x bit which does not fit into a 16 bits. I wrote a routine to multiple these value and get the size required for framebuffer in segment unit (64k). Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- 1 files changed, 28 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3d42216..35d9866 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -742,6 +742,29 @@ no_vbe_flag: jmp _display_string ASM_END +ASM_START +_size64: + push bp + mov bp, sp + push dx + +; multiply bbp by yres first as results fit in 16bits +; then multiply by xres + mov ax, 8[bp] + mul word 6[bp] + mul word 4[bp] +; divide by 2^19 ceiling result + add ax, #0xffff + adc dx, #7 + mov ax, dx + shr ax, #3 + + pop dx + pop bp + ret +ASM_END + + /** Function 00h - Return VBE Controller Information * * Input: @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; do { + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); + Bit16u max_bpp = dispi_get_max_bpp(); + if ((cur_info->info.XResolution <= dispi_get_max_xres()) && - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { + (cur_info->info.BitsPerPixel <= max_bpp) && + (size_64k <= vbe_info_block.TotalMemory)) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); cur_mode++; -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl3-0000Br-At; Fri, 04 May 2012 12:37:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-00009h-TJ for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:12 +0000 Received: from [85.158.139.83:50219] by server-8.bemta-5.messagelabs.com id 15/C0-26964-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6471 invoked from network); 4 May 2012 12:37:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861941" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-RE; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:50 +0100 Message-ID: <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Apparently Windows 8 refuse to use any mode if has more than one page. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index a7b06b9..9131721 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; (size_64k > totalMemory)) info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; - if (using_lfb) { - info.NumberOfBanks = 1; - } + /* Windows 8 require this to be 1! */ + info.NumberOfBanks = 1; + if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { info.WinFuncPtr = 0xC0000000UL; *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl3-0000Br-At; Fri, 04 May 2012 12:37:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-00009h-TJ for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:12 +0000 Received: from [85.158.139.83:50219] by server-8.bemta-5.messagelabs.com id 15/C0-26964-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6471 invoked from network); 4 May 2012 12:37:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861941" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-RE; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:50 +0100 Message-ID: <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Apparently Windows 8 refuse to use any mode if has more than one page. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index a7b06b9..9131721 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; (size_64k > totalMemory)) info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; - if (using_lfb) { - info.NumberOfBanks = 1; - } + /* Windows 8 require this to be 1! */ + info.NumberOfBanks = 1; + if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { info.WinFuncPtr = 0xC0000000UL; *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009j-8y; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkx-00009I-EB for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:07 +0000 Received: from [85.158.138.51:23550] by server-9.bemta-3.messagelabs.com id EB/B6-26691-17DC3AF4; Fri, 04 May 2012 12:37:05 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7996 invoked from network); 4 May 2012 12:37:04 -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; 4 May 2012 12:37:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861933" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-MO; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:43 +0100 Message-ID: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 0/7] VGA BIOS patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org There are a could of patch to vgabios code that - make some optimizations - fix a overflow computing frame buffer size - make Windows 8 suport greater resolutions - fix some informations returned from interrupt Frediano Ziglio (7): vgabios: Output to Qemu debug port instead of using Bochs one vgabios: Does not define cur_mode if not required vgabios: Fix size computation overflow vgabios: Report mode not supported getting mode informations vgabios: Reduce stack usage getting mode informations vgabios: Check if mode is currently supported as vesa specifications vgabios: Make Windows 8 support greater resolutions tools/firmware/vgabios/vbe.c | 69 +++++++++++++++++++++++++++++--------- tools/firmware/vgabios/vgabios.c | 6 ++-- 2 files changed, 56 insertions(+), 19 deletions(-) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-0000A4-W4; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009K-52 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.138.51:23744] by server-10.bemta-3.messagelabs.com id A4/08-29478-37DC3AF4; Fri, 04 May 2012 12:37:07 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8104 invoked from network); 4 May 2012 12:37:06 -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; 4 May 2012 12:37:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861935" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Op; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:45 +0100 Message-ID: <1336135010-26940-3-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 2/7] vgabios: Does not define cur_mode if not required X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Declare and use cur_mode only if debug is enabled Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3fc786d..3d42216 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -761,7 +761,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; Bit16u status; Bit16u result; Bit16u vbe2_info; +#ifdef DEBUG Bit16u cur_mode=0; +#endif Bit16u cur_ptr=34; ModeInfoListItem *cur_info=&mode_info_list; @@ -849,9 +851,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); + cur_mode++; #endif write_word(ES, DI + cur_ptr, cur_info->mode); - cur_mode++; cur_ptr+=2; } else { #ifdef DEBUG -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-0000A4-W4; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009K-52 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.138.51:23744] by server-10.bemta-3.messagelabs.com id A4/08-29478-37DC3AF4; Fri, 04 May 2012 12:37:07 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8104 invoked from network); 4 May 2012 12:37:06 -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; 4 May 2012 12:37:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861935" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Op; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:45 +0100 Message-ID: <1336135010-26940-3-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 2/7] vgabios: Does not define cur_mode if not required X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Declare and use cur_mode only if debug is enabled Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 3fc786d..3d42216 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -761,7 +761,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; Bit16u status; Bit16u result; Bit16u vbe2_info; +#ifdef DEBUG Bit16u cur_mode=0; +#endif Bit16u cur_ptr=34; ModeInfoListItem *cur_info=&mode_info_list; @@ -849,9 +851,9 @@ Bit16u *AX;Bit16u ES;Bit16u DI; (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { #ifdef DEBUG printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); + cur_mode++; #endif write_word(ES, DI + cur_ptr, cur_info->mode); - cur_mode++; cur_ptr+=2; } else { #ifdef DEBUG -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009j-8y; Fri, 04 May 2012 12:37:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkx-00009I-EB for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:07 +0000 Received: from [85.158.138.51:23550] by server-9.bemta-3.messagelabs.com id EB/B6-26691-17DC3AF4; Fri, 04 May 2012 12:37:05 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7996 invoked from network); 4 May 2012 12:37:04 -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; 4 May 2012 12:37:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861933" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-MO; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:43 +0100 Message-ID: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 0/7] VGA BIOS patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org There are a could of patch to vgabios code that - make some optimizations - fix a overflow computing frame buffer size - make Windows 8 suport greater resolutions - fix some informations returned from interrupt Frediano Ziglio (7): vgabios: Output to Qemu debug port instead of using Bochs one vgabios: Does not define cur_mode if not required vgabios: Fix size computation overflow vgabios: Report mode not supported getting mode informations vgabios: Reduce stack usage getting mode informations vgabios: Check if mode is currently supported as vesa specifications vgabios: Make Windows 8 support greater resolutions tools/firmware/vgabios/vbe.c | 69 +++++++++++++++++++++++++++++--------- tools/firmware/vgabios/vgabios.c | 6 ++-- 2 files changed, 56 insertions(+), 19 deletions(-) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl0-0000AW-Tq; Fri, 04 May 2012 12:37:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009K-Jp for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.138.51:26092] by server-10.bemta-3.messagelabs.com id 37/08-29478-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8158 invoked from network); 4 May 2012 12:37:07 -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; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861937" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Qj; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:49 +0100 Message-ID: <1336135010-26940-7-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 6/7] vgabios: Check if mode is currently supported as vesa specifications X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Vesa specification require that mode information return if a given mode is supported or not so test if we can support it checking required memory and set correctly supported bit. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 0b8b736..a7b06b9 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -930,10 +930,22 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; if (cur_info != 0) { + Bit16u max_bpp = dispi_get_max_bpp(); + Bit16u size_64k; + Bit16u totalMemory; + + outw(VBE_DISPI_IOPORT_INDEX, VBE_DISPI_INDEX_VIDEO_MEMORY_64K); + totalMemory = inw(VBE_DISPI_IOPORT_DATA); #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); + size_64k = size64(info.XResolution, info.YResolution, info.BitsPerPixel); + if ((info.XResolution > dispi_get_max_xres()) || + (info.BitsPerPixel > max_bpp) || + (size_64k > totalMemory)) + info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; + if (using_lfb) { info.NumberOfBanks = 1; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-0000Ai-BH; Fri, 04 May 2012 12:37:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009Y-13 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:09 +0000 Received: from [85.158.139.83:48475] by server-11.bemta-5.messagelabs.com id 90/F7-12959-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6394 invoked from network); 4 May 2012 12:37:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861938" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-QE; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:48 +0100 Message-ID: <1336135010-26940-6-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 5/7] vgabios: Reduce stack usage getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Informations are stored in a structure that is smaller than final one. Previous code copy this structure to stack extending with zeroes then update it and copy to caller while now the not-extended version is copied into stack and then is extended during copy reducing stack usage. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index fff314e..0b8b736 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -914,9 +914,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; // error by default is 0x014f which means supported but error Bit16u result=0x014f; Bit16u ss=get_SS(); - ModeInfoBlock info; ModeInfoListItem *cur_info; Boolean using_lfb; + ModeInfoBlockCompact info; #ifdef DEBUG printf("VBE vbe_biosfn_return_mode_information ES%x DI%x CX%x\n",ES,DI,CX); @@ -933,7 +933,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif - memsetb(ss, &info, 0, sizeof(ModeInfoBlock)); memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); if (using_lfb) { info.NumberOfBanks = 1; @@ -950,6 +949,10 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; info.PhysBasePtr |= inw(VBE_DISPI_IOPORT_DATA); #endif result = 0x4f; + + // copy updates in mode_info_block back + memsetb(ES, DI, 0, sizeof(ModeInfoBlock)); + memcpyb(ES, DI, ss, &info, sizeof(info)); } else { @@ -957,12 +960,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; printf("VBE *NOT* found mode %x\n",CX); #endif } - - if (result == 0x4f) - { - // copy updates in mode_info_block back - memcpyb(ES, DI, ss, &info, sizeof(info)); - } write_word(ss, AX, result); } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl0-0000AW-Tq; Fri, 04 May 2012 12:37:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHky-00009K-Jp for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:08 +0000 Received: from [85.158.138.51:26092] by server-10.bemta-3.messagelabs.com id 37/08-29478-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8158 invoked from network); 4 May 2012 12:37:07 -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; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861937" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Qj; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:49 +0100 Message-ID: <1336135010-26940-7-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 6/7] vgabios: Check if mode is currently supported as vesa specifications X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Vesa specification require that mode information return if a given mode is supported or not so test if we can support it checking required memory and set correctly supported bit. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 0b8b736..a7b06b9 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -930,10 +930,22 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; if (cur_info != 0) { + Bit16u max_bpp = dispi_get_max_bpp(); + Bit16u size_64k; + Bit16u totalMemory; + + outw(VBE_DISPI_IOPORT_INDEX, VBE_DISPI_INDEX_VIDEO_MEMORY_64K); + totalMemory = inw(VBE_DISPI_IOPORT_DATA); #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); + size_64k = size64(info.XResolution, info.YResolution, info.BitsPerPixel); + if ((info.XResolution > dispi_get_max_xres()) || + (info.BitsPerPixel > max_bpp) || + (size_64k > totalMemory)) + info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; + if (using_lfb) { info.NumberOfBanks = 1; } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-0000B8-Tp; Fri, 04 May 2012 12:37:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009i-Na for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:09 +0000 Received: from [85.158.138.51:26136] by server-4.bemta-3.messagelabs.com id CB/1E-15341-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!5 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8204 invoked from network); 4 May 2012 12:37:07 -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; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861939" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Pm; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:47 +0100 Message-ID: <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If you try to get mode information for an unsupported mode interrupt should return error but not that the function is not supported. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 35d9866..fff314e 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; void vbe_biosfn_return_mode_information(AX, CX, ES, DI) Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; { - Bit16u result=0x0100; + // error by default is 0x014f which means supported but error + Bit16u result=0x014f; Bit16u ss=get_SS(); ModeInfoBlock info; ModeInfoListItem *cur_info; @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE *NOT* found mode %x\n",CX); #endif - result = 0x100; } if (result == 0x4f) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-0000Ai-BH; Fri, 04 May 2012 12:37:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009Y-13 for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:09 +0000 Received: from [85.158.139.83:48475] by server-11.bemta-5.messagelabs.com id 90/F7-12959-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336135025!26809151!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6394 invoked from network); 4 May 2012 12:37:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861938" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-QE; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:48 +0100 Message-ID: <1336135010-26940-6-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 5/7] vgabios: Reduce stack usage getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Informations are stored in a structure that is smaller than final one. Previous code copy this structure to stack extending with zeroes then update it and copy to caller while now the not-extended version is copied into stack and then is extended during copy reducing stack usage. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index fff314e..0b8b736 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -914,9 +914,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; // error by default is 0x014f which means supported but error Bit16u result=0x014f; Bit16u ss=get_SS(); - ModeInfoBlock info; ModeInfoListItem *cur_info; Boolean using_lfb; + ModeInfoBlockCompact info; #ifdef DEBUG printf("VBE vbe_biosfn_return_mode_information ES%x DI%x CX%x\n",ES,DI,CX); @@ -933,7 +933,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE found mode %x\n",CX); #endif - memsetb(ss, &info, 0, sizeof(ModeInfoBlock)); memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact)); if (using_lfb) { info.NumberOfBanks = 1; @@ -950,6 +949,10 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; info.PhysBasePtr |= inw(VBE_DISPI_IOPORT_DATA); #endif result = 0x4f; + + // copy updates in mode_info_block back + memsetb(ES, DI, 0, sizeof(ModeInfoBlock)); + memcpyb(ES, DI, ss, &info, sizeof(info)); } else { @@ -957,12 +960,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; printf("VBE *NOT* found mode %x\n",CX); #endif } - - if (result == 0x4f) - { - // copy updates in mode_info_block back - memcpyb(ES, DI, ss, &info, sizeof(info)); - } write_word(ss, AX, result); } -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:37:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHl1-0000B8-Tp; Fri, 04 May 2012 12:37:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHkz-00009i-Na for xen-devel@lists.xen.org; Fri, 04 May 2012 12:37:09 +0000 Received: from [85.158.138.51:26136] by server-4.bemta-3.messagelabs.com id CB/1E-15341-47DC3AF4; Fri, 04 May 2012 12:37:08 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336135023!25133940!5 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8204 invoked from network); 4 May 2012 12:37:07 -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; 4 May 2012 12:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24861939" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 08:37:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 08:37:02 -0400 Received: from [10.80.3.57] (helo=hamster.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQHkr-0004dB-Pm; Fri, 04 May 2012 13:37:01 +0100 From: Frediano Ziglio To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 13:36:47 +0100 Message-ID: <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio Subject: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If you try to get mode information for an unsupported mode interrupt should return error but not that the function is not supported. Signed-off-by: Frediano Ziglio --- tools/firmware/vgabios/vbe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c index 35d9866..fff314e 100644 --- a/tools/firmware/vgabios/vbe.c +++ b/tools/firmware/vgabios/vbe.c @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; void vbe_biosfn_return_mode_information(AX, CX, ES, DI) Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; { - Bit16u result=0x0100; + // error by default is 0x014f which means supported but error + Bit16u result=0x014f; Bit16u ss=get_SS(); ModeInfoBlock info; ModeInfoListItem *cur_info; @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; #ifdef DEBUG printf("VBE *NOT* found mode %x\n",CX); #endif - result = 0x100; } if (result == 0x4f) -- 1.7.5.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:46:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:46:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHu9-0001ae-DC; Fri, 04 May 2012 12:46:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHu8-0001aR-1e for xen-devel@lists.xen.org; Fri, 04 May 2012 12:46:36 +0000 Received: from [85.158.143.99:30929] by server-1.bemta-4.messagelabs.com id 04/4D-20925-BAFC3AF4; Fri, 04 May 2012 12:46:35 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336135594!15301893!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31906 invoked from network); 4 May 2012 12:46:34 -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 May 2012 12:46:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:46:34 +0100 Message-Id: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:46:33 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3D4320200007800081987@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 14:03, Keir Fraser wrote: > On 04/05/2012 12:05, "Jan Beulich" wrote: > >>> I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes >>> per CPU of the poll_port variable isn't worth much optimising effort. >> >> Certainly not (and as you say they are actually needed, even if >> only rarely). But the pointlessly running timer(s) might be, as might >> the buffer(s) set up via serial_async_transmit(). > > We could delay {init,setup}_postirq until a corresponding serial handle has > been created via serial_parse_handle()? The logic might be a bit ugly and > spread across both serial.c and ns16550.c but not actually particularly > complicated? I think this can be done entirely in serial.c - serial_init_postirq() would directly call any drivers that already got a handle parsed for them, and serial_parse_handle() would need to call ->init_postirq() for any driver that didn't have it called already. serial_suspend() and serial_resume() should then call drivers only if they previously had ->init_postirq() called. I definitely want to avoid putting any part of this into ns16550.c, as it would need to be replicated for ARM's pl011.c as well as any future ones (I'm now mostly done with an EHCI debug port driver, but due to feature freeze won't be able to post this as other than an RFC any time soon; xHCI appears to also have a debug port, so in the future that might become a third alternative). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:46:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:46:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHu9-0001ae-DC; Fri, 04 May 2012 12:46:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHu8-0001aR-1e for xen-devel@lists.xen.org; Fri, 04 May 2012 12:46:36 +0000 Received: from [85.158.143.99:30929] by server-1.bemta-4.messagelabs.com id 04/4D-20925-BAFC3AF4; Fri, 04 May 2012 12:46:35 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336135594!15301893!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31906 invoked from network); 4 May 2012 12:46:34 -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 May 2012 12:46:34 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:46:34 +0100 Message-Id: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:46:33 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3D4320200007800081987@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 14:03, Keir Fraser wrote: > On 04/05/2012 12:05, "Jan Beulich" wrote: > >>> I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes >>> per CPU of the poll_port variable isn't worth much optimising effort. >> >> Certainly not (and as you say they are actually needed, even if >> only rarely). But the pointlessly running timer(s) might be, as might >> the buffer(s) set up via serial_async_transmit(). > > We could delay {init,setup}_postirq until a corresponding serial handle has > been created via serial_parse_handle()? The logic might be a bit ugly and > spread across both serial.c and ns16550.c but not actually particularly > complicated? I think this can be done entirely in serial.c - serial_init_postirq() would directly call any drivers that already got a handle parsed for them, and serial_parse_handle() would need to call ->init_postirq() for any driver that didn't have it called already. serial_suspend() and serial_resume() should then call drivers only if they previously had ->init_postirq() called. I definitely want to avoid putting any part of this into ns16550.c, as it would need to be replicated for ARM's pl011.c as well as any future ones (I'm now mostly done with an EHCI debug port driver, but due to feature freeze won't be able to post this as other than an RFC any time soon; xHCI appears to also have a debug port, so in the future that might become a third alternative). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:52:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:52:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHzC-0001zP-RK; Fri, 04 May 2012 12:51:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHzB-0001z8-8Z for xen-devel@lists.xen.org; Fri, 04 May 2012 12:51:49 +0000 Received: from [193.109.254.147:35767] by server-6.bemta-14.messagelabs.com id 9A/7F-04960-4E0D3AF4; Fri, 04 May 2012 12:51:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336135898!7627649!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20570 invoked from network); 4 May 2012 12:51:38 -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; 4 May 2012 12:51:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:51:38 +0100 Message-Id: <4FA3ECF90200007800081A71@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:51:37 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FA3C0A5.7030309@citrix.com> In-Reply-To: <4FA3C0A5.7030309@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:42, Andrew Cooper wrote: > I know that xen-unstable is on a feature freeze, and this is not > strictly a bugfix (yet; see below), but as it is safe and designed to > help clarity in the case of a crash, so I request that it be considered > for inclusion. > > I have constructed an artificial case where the information reported in > 1 per-cpu crash note was stale by using low_crashinfo mode, crashing > Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This > leaves stale register state written into the offlined CPU crash > information. In this case, the information was stale but correct, due > to the predictable nature of the Xen crash path from the 'C' debug key, > but there is no guarantee that in the case of a real crash, the same > will still be true. Apart from the missing blanks in the for() statement (which could as well be a simple memset() afaict), Acked-by: Jan Beulich I personally would think that this can go in as a bug fix. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 12:52:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 12:52:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHzC-0001zP-RK; Fri, 04 May 2012 12:51:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQHzB-0001z8-8Z for xen-devel@lists.xen.org; Fri, 04 May 2012 12:51:49 +0000 Received: from [193.109.254.147:35767] by server-6.bemta-14.messagelabs.com id 9A/7F-04960-4E0D3AF4; Fri, 04 May 2012 12:51:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336135898!7627649!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20570 invoked from network); 4 May 2012 12:51:38 -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; 4 May 2012 12:51:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 13:51:38 +0100 Message-Id: <4FA3ECF90200007800081A71@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 13:51:37 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FA3C0A5.7030309@citrix.com> In-Reply-To: <4FA3C0A5.7030309@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:42, Andrew Cooper wrote: > I know that xen-unstable is on a feature freeze, and this is not > strictly a bugfix (yet; see below), but as it is safe and designed to > help clarity in the case of a crash, so I request that it be considered > for inclusion. > > I have constructed an artificial case where the information reported in > 1 per-cpu crash note was stale by using low_crashinfo mode, crashing > Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This > leaves stale register state written into the offlined CPU crash > information. In this case, the information was stale but correct, due > to the predictable nature of the Xen crash path from the 'C' debug key, > but there is no guarantee that in the case of a real crash, the same > will still be true. Apart from the missing blanks in the for() statement (which could as well be a simple memset() afaict), Acked-by: Jan Beulich I personally would think that this can go in as a bug fix. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:11:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:11:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIHn-0002dt-Nl; Fri, 04 May 2012 13:11:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIHm-0002do-UL for xen-devel@lists.xen.org; Fri, 04 May 2012 13:11:03 +0000 Received: from [193.109.254.147:58113] by server-8.bemta-14.messagelabs.com id 23/70-23244-665D3AF4; Fri, 04 May 2012 13:11:02 +0000 X-Env-Sender: hahn@univention.de X-Msg-Ref: server-4.tower-27.messagelabs.com!1336137059!7658472!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.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10457 invoked from network); 4 May 2012 13:10:59 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-4.tower-27.messagelabs.com with SMTP; 4 May 2012 13:10:59 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 22DF7A63113; Fri, 4 May 2012 15:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 0FAC0A63115; Fri, 4 May 2012 15:10:59 +0200 (CEST) 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 BENmPa1wAgMC; Fri, 4 May 2012 15:10:58 +0200 (CEST) Received: from stave.knut.univention.de (port-92-196-73-46.dynamic.qsc.de [92.196.73.46]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 62378A63113; Fri, 4 May 2012 15:10:58 +0200 (CEST) From: Philipp Hahn Organization: Univention.de To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 15:10:53 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286) References: <201205041054.04079.hahn@univention.de> <4FA3B1C7.4060201@citrix.com> In-Reply-To: <4FA3B1C7.4060201@citrix.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Message-Id: <201205041510.56986.hahn@univention.de> Cc: Thomas Gleixner , David Vrabel Subject: Re: [Xen-devel] =?iso-8859-1?q?=5BBUG_2=2E6=2E32=2Ey=5D_Broken_PV_mig?= =?iso-8859-1?q?ration_between_hosts_with=09different_uptime=2C_non?= =?iso-8859-1?q?-monotonic_time=3F?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8699982309584793595==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8699982309584793595== Content-Type: multipart/signed; boundary="nextPart11425697.Xf5rhIgNHA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart11425697.Xf5rhIgNHA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello David, On Friday 04 May 2012 12:39:03 David Vrabel wrote: > On 04/05/12 09:54, Philipp Hahn wrote: > > I encountered the following bug when migrating a Linux-2.6.32.54 PV > > domain on Xen-3.4.3 between different hosts, whose uptime differs by > > several minutes =2E..=20 > Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 > does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power > Management CPUID leaf it will pass this through to the guest which makes > the guest think the TSC is stable. > > Can you try this libxc patch? > > 8<------------------------ > libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf Excellent, that fixes the problem for me and makes perfect sense for me, si= nce=20 AFAIK 2.6.37 also received a big TSC patch which is not part of 2.6.32.y=20 backport. Thank your for your help. Sincerely Philipp Hahn =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ --nextPart11425697.Xf5rhIgNHA 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) iEYEABECAAYFAk+j1V0ACgkQYPlgoZpUDjmMJQCfbe8pg8Jae07dV1linaE8Mvbw 7msAoMDZagErQfRoESEI4uO5ToqIsovU =4Kof -----END PGP SIGNATURE----- --nextPart11425697.Xf5rhIgNHA-- --===============8699982309584793595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8699982309584793595==-- From xen-devel-bounces@lists.xen.org Fri May 04 13:11:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:11:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIHn-0002dt-Nl; Fri, 04 May 2012 13:11:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIHm-0002do-UL for xen-devel@lists.xen.org; Fri, 04 May 2012 13:11:03 +0000 Received: from [193.109.254.147:58113] by server-8.bemta-14.messagelabs.com id 23/70-23244-665D3AF4; Fri, 04 May 2012 13:11:02 +0000 X-Env-Sender: hahn@univention.de X-Msg-Ref: server-4.tower-27.messagelabs.com!1336137059!7658472!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.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10457 invoked from network); 4 May 2012 13:10:59 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-4.tower-27.messagelabs.com with SMTP; 4 May 2012 13:10:59 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 22DF7A63113; Fri, 4 May 2012 15:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 0FAC0A63115; Fri, 4 May 2012 15:10:59 +0200 (CEST) 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 BENmPa1wAgMC; Fri, 4 May 2012 15:10:58 +0200 (CEST) Received: from stave.knut.univention.de (port-92-196-73-46.dynamic.qsc.de [92.196.73.46]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 62378A63113; Fri, 4 May 2012 15:10:58 +0200 (CEST) From: Philipp Hahn Organization: Univention.de To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 15:10:53 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286) References: <201205041054.04079.hahn@univention.de> <4FA3B1C7.4060201@citrix.com> In-Reply-To: <4FA3B1C7.4060201@citrix.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Message-Id: <201205041510.56986.hahn@univention.de> Cc: Thomas Gleixner , David Vrabel Subject: Re: [Xen-devel] =?iso-8859-1?q?=5BBUG_2=2E6=2E32=2Ey=5D_Broken_PV_mig?= =?iso-8859-1?q?ration_between_hosts_with=09different_uptime=2C_non?= =?iso-8859-1?q?-monotonic_time=3F?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8699982309584793595==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8699982309584793595== Content-Type: multipart/signed; boundary="nextPart11425697.Xf5rhIgNHA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart11425697.Xf5rhIgNHA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello David, On Friday 04 May 2012 12:39:03 David Vrabel wrote: > On 04/05/12 09:54, Philipp Hahn wrote: > > I encountered the following bug when migrating a Linux-2.6.32.54 PV > > domain on Xen-3.4.3 between different hosts, whose uptime differs by > > several minutes =2E..=20 > Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 > does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power > Management CPUID leaf it will pass this through to the guest which makes > the guest think the TSC is stable. > > Can you try this libxc patch? > > 8<------------------------ > libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf Excellent, that fixes the problem for me and makes perfect sense for me, si= nce=20 AFAIK 2.6.37 also received a big TSC patch which is not part of 2.6.32.y=20 backport. Thank your for your help. Sincerely Philipp Hahn =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ --nextPart11425697.Xf5rhIgNHA 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) iEYEABECAAYFAk+j1V0ACgkQYPlgoZpUDjmMJQCfbe8pg8Jae07dV1linaE8Mvbw 7msAoMDZagErQfRoESEI4uO5ToqIsovU =4Kof -----END PGP SIGNATURE----- --nextPart11425697.Xf5rhIgNHA-- --===============8699982309584793595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8699982309584793595==-- From xen-devel-bounces@lists.xen.org Fri May 04 13:18:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:18:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIP5-0002ny-NK; Fri, 04 May 2012 13:18:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIP4-0002nt-I4 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:18:34 +0000 Received: from [85.158.138.51:33186] by server-9.bemta-3.messagelabs.com id 1F/B1-26691-927D3AF4; Fri, 04 May 2012 13:18:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336137511!18890778!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22235 invoked from network); 4 May 2012 13:18:32 -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; 4 May 2012 13:18:32 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44DISrE001437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 13:18:29 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 q44DISWl023496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 13:18:28 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 q44DISbq027665; Fri, 4 May 2012 08:18:28 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 06:18:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8A5194031D; Fri, 4 May 2012 09:12:44 -0400 (EDT) Date: Fri, 4 May 2012 09:12:44 -0400 From: Konrad Rzeszutek Wilk To: "Wu, GabrielX" Message-ID: <20120504131244.GA26418@phenom.dumpdata.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 10:06:26AM +0000, Wu, GabrielX wrote: > Hi all, > > This is the test report of xen-unstable tree. There are one bug found. > > Version Info: > ================================================================= > xen-changeset: 25256 > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) Please update your dom0. > ================================================================= > > New issue(1) > ============== > 1. cpu weight out of range error when create hvm domU > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 And what is the guest config? Does it have any cpu weights? > > Fixed issue(0) > ============== > > Old issues(8) > ============== > 1. [ACPI] System cann't resume after do suspend > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 That shouldn't be a surprise. The patches for that are not yet in the mainline. > 2. [XL]"xl vcpu-set" causes dom0 crash or panic This should be fixed with 3.4-rc5. > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > 3. [VT-D]fail to detach NIC from guest Hmm, the last update is from a year ago. Are you sure this is an issue? > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 the bug talks about 2.6.32. Can you update it to include the 3.4 (or 3.3) dmesg output? > 5. [VT-D] device reset fail when create/destroy guest > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 Does this happen if you manually echo 1 > ../reset? And is this an issue with the kernel if you upgrade it to 3.4-rc5? > 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 .. Not sure about that. > 7. RHEL6.2/6.1 guest runs quite slow > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 Is the issue present when using an LVM disk? > 8. after detaching a VF from a guest, shutdown the guest is very slow > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 Where does it slow down? When bringing the NIC down or in specific cases? Is this an issue with if you are using a different guest (say Fedora Core 16?) > > Thanks, > Wu Ronghui(Gabriel) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:18:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:18:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIP5-0002ny-NK; Fri, 04 May 2012 13:18:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIP4-0002nt-I4 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:18:34 +0000 Received: from [85.158.138.51:33186] by server-9.bemta-3.messagelabs.com id 1F/B1-26691-927D3AF4; Fri, 04 May 2012 13:18:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336137511!18890778!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22235 invoked from network); 4 May 2012 13:18:32 -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; 4 May 2012 13:18:32 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44DISrE001437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 13:18:29 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 q44DISWl023496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 13:18:28 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 q44DISbq027665; Fri, 4 May 2012 08:18:28 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 06:18:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8A5194031D; Fri, 4 May 2012 09:12:44 -0400 (EDT) Date: Fri, 4 May 2012 09:12:44 -0400 From: Konrad Rzeszutek Wilk To: "Wu, GabrielX" Message-ID: <20120504131244.GA26418@phenom.dumpdata.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 10:06:26AM +0000, Wu, GabrielX wrote: > Hi all, > > This is the test report of xen-unstable tree. There are one bug found. > > Version Info: > ================================================================= > xen-changeset: 25256 > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) Please update your dom0. > ================================================================= > > New issue(1) > ============== > 1. cpu weight out of range error when create hvm domU > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 And what is the guest config? Does it have any cpu weights? > > Fixed issue(0) > ============== > > Old issues(8) > ============== > 1. [ACPI] System cann't resume after do suspend > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 That shouldn't be a surprise. The patches for that are not yet in the mainline. > 2. [XL]"xl vcpu-set" causes dom0 crash or panic This should be fixed with 3.4-rc5. > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > 3. [VT-D]fail to detach NIC from guest Hmm, the last update is from a year ago. Are you sure this is an issue? > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 the bug talks about 2.6.32. Can you update it to include the 3.4 (or 3.3) dmesg output? > 5. [VT-D] device reset fail when create/destroy guest > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 Does this happen if you manually echo 1 > ../reset? And is this an issue with the kernel if you upgrade it to 3.4-rc5? > 6. when detaching a VF from hvm guest, "xl dmesg" will show some warning information > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 .. Not sure about that. > 7. RHEL6.2/6.1 guest runs quite slow > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 Is the issue present when using an LVM disk? > 8. after detaching a VF from a guest, shutdown the guest is very slow > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 Where does it slow down? When bringing the NIC down or in specific cases? Is this an issue with if you are using a different guest (say Fedora Core 16?) > > Thanks, > Wu Ronghui(Gabriel) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:20:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIQz-0002sl-7R; Fri, 04 May 2012 13:20:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIQx-0002sH-Ux for xen-devel@lists.xen.org; Fri, 04 May 2012 13:20:32 +0000 Received: from [85.158.139.83:20632] by server-2.bemta-5.messagelabs.com id 18/EF-17016-F97D3AF4; Fri, 04 May 2012 13:20:31 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336137615!22509010!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16306 invoked from network); 4 May 2012 13:20:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:20:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24863443" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:20:14 -0400 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, 4 May 2012 09:20:14 -0400 Message-ID: <4FA3D78D.3000201@citrix.com> Date: Fri, 4 May 2012 14:20:13 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Philipp Hahn References: <201205041054.04079.hahn@univention.de> <4FA3B1C7.4060201@citrix.com> <201205041510.56986.hahn@univention.de> In-Reply-To: <201205041510.56986.hahn@univention.de> Cc: Thomas Gleixner , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 14:10, Philipp Hahn wrote: > Hello David, > > On Friday 04 May 2012 12:39:03 David Vrabel wrote: >> On 04/05/12 09:54, Philipp Hahn wrote: >>> I encountered the following bug when migrating a Linux-2.6.32.54 PV >>> domain on Xen-3.4.3 between different hosts, whose uptime differs by >>> several minutes > ... >> Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 >> does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power >> Management CPUID leaf it will pass this through to the guest which makes >> the guest think the TSC is stable. >> >> Can you try this libxc patch? >> >> 8<------------------------ >> libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf > > Excellent, that fixes the problem for me and makes perfect sense for me, since > AFAIK 2.6.37 also received a big TSC patch which is not part of 2.6.32.y > backport. Thanks for testing! I could never repro the migration failures. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:20:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIQz-0002sl-7R; Fri, 04 May 2012 13:20:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIQx-0002sH-Ux for xen-devel@lists.xen.org; Fri, 04 May 2012 13:20:32 +0000 Received: from [85.158.139.83:20632] by server-2.bemta-5.messagelabs.com id 18/EF-17016-F97D3AF4; Fri, 04 May 2012 13:20:31 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336137615!22509010!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16306 invoked from network); 4 May 2012 13:20:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:20:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24863443" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 09:20:14 -0400 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, 4 May 2012 09:20:14 -0400 Message-ID: <4FA3D78D.3000201@citrix.com> Date: Fri, 4 May 2012 14:20:13 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Philipp Hahn References: <201205041054.04079.hahn@univention.de> <4FA3B1C7.4060201@citrix.com> <201205041510.56986.hahn@univention.de> In-Reply-To: <201205041510.56986.hahn@univention.de> Cc: Thomas Gleixner , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 14:10, Philipp Hahn wrote: > Hello David, > > On Friday 04 May 2012 12:39:03 David Vrabel wrote: >> On 04/05/12 09:54, Philipp Hahn wrote: >>> I encountered the following bug when migrating a Linux-2.6.32.54 PV >>> domain on Xen-3.4.3 between different hosts, whose uptime differs by >>> several minutes > ... >> Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0 >> does). If the host CPU has the CONSTANT_TSC bit in the Advanced Power >> Management CPUID leaf it will pass this through to the guest which makes >> the guest think the TSC is stable. >> >> Can you try this libxc patch? >> >> 8<------------------------ >> libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf > > Excellent, that fixes the problem for me and makes perfect sense for me, since > AFAIK 2.6.37 also received a big TSC patch which is not part of 2.6.32.y > backport. Thanks for testing! I could never repro the migration failures. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:26:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIW3-0003G1-8a; Fri, 04 May 2012 13:25:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIW2-0003Fu-I3 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:25:46 +0000 Received: from [85.158.143.99:29512] by server-1.bemta-4.messagelabs.com id 0D/A7-20925-9D8D3AF4; Fri, 04 May 2012 13:25:45 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336137945!20125463!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26836 invoked from network); 4 May 2012 13:25:45 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:25:45 -0000 Received: by eaaf11 with SMTP id f11so911577eaa.32 for ; Fri, 04 May 2012 06:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=m18v0rz50lq05azXC4Sv8+6FdkOrR57IkzDQxjUL3gQ=; b=QYEIybGKeKcLgg5skgsquN7Fxrs5ulegZgG+zk6CW5+yhoXLhsp2E07RDbKjXswLf6 xc/zxiOVQpdJWTI4Gr7Rk2mGfxXv6cKCASpun23odWcuicRR1R+DDj2u7mU+3oh+YOFR yfPj01Ty0kmpxc4hdf+zsLa1pFjZ8tk3buyipSGsYqQeDvrpz+rNoYTTm8Gp42cW+svZ u/VOiIAyNqP725hO/VMZa/+7Cux06NI2wwTLUporQJs3AIl87PsTnbDi0hx25HQDfaBO 4Be4+KJY5MHqnUu/mqmU49yNhayZ6hJGB4v0KEubXjvQIK966TfKPHWl0ALS+S/Ql16D e/aA== Received: by 10.213.113.20 with SMTP id y20mr483437ebp.37.1336137943912; Fri, 04 May 2012 06:25:43 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id u10sm25786871eem.1.2012.05.04.06.25.42 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:25:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:25:40 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition Thread-Index: Ac0p+WYX1PeZYNBT+ECmgZYc6fFZrA== In-Reply-To: <4FA3E9530200007800081A2F@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 13:36, "Jan Beulich" wrote: > ... as it conflicts with the one made in asm/byteorder.h, and hence > build fails when both happen to be included from the same source file. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/include/asm-x86/msi.h > +++ b/xen/include/asm-x86/msi.h > @@ -3,6 +3,7 @@ > > #include > #include > +#include > > /* > * Constants for Intel APIC based MSI messages. > @@ -165,8 +166,6 @@ int msi_free_irq(struct msi_desc *entry) > #define MSI_LOGICAL_MODE 1 > #define MSI_REDIRECTION_HINT_MODE 0 > > -#define __LITTLE_ENDIAN_BITFIELD 1 > - > struct msg_data { > #if defined(__LITTLE_ENDIAN_BITFIELD) > __u32 vector : 8; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:26:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIW3-0003G1-8a; Fri, 04 May 2012 13:25:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIW2-0003Fu-I3 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:25:46 +0000 Received: from [85.158.143.99:29512] by server-1.bemta-4.messagelabs.com id 0D/A7-20925-9D8D3AF4; Fri, 04 May 2012 13:25:45 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336137945!20125463!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26836 invoked from network); 4 May 2012 13:25:45 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:25:45 -0000 Received: by eaaf11 with SMTP id f11so911577eaa.32 for ; Fri, 04 May 2012 06:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=m18v0rz50lq05azXC4Sv8+6FdkOrR57IkzDQxjUL3gQ=; b=QYEIybGKeKcLgg5skgsquN7Fxrs5ulegZgG+zk6CW5+yhoXLhsp2E07RDbKjXswLf6 xc/zxiOVQpdJWTI4Gr7Rk2mGfxXv6cKCASpun23odWcuicRR1R+DDj2u7mU+3oh+YOFR yfPj01Ty0kmpxc4hdf+zsLa1pFjZ8tk3buyipSGsYqQeDvrpz+rNoYTTm8Gp42cW+svZ u/VOiIAyNqP725hO/VMZa/+7Cux06NI2wwTLUporQJs3AIl87PsTnbDi0hx25HQDfaBO 4Be4+KJY5MHqnUu/mqmU49yNhayZ6hJGB4v0KEubXjvQIK966TfKPHWl0ALS+S/Ql16D e/aA== Received: by 10.213.113.20 with SMTP id y20mr483437ebp.37.1336137943912; Fri, 04 May 2012 06:25:43 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id u10sm25786871eem.1.2012.05.04.06.25.42 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:25:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:25:40 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition Thread-Index: Ac0p+WYX1PeZYNBT+ECmgZYc6fFZrA== In-Reply-To: <4FA3E9530200007800081A2F@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86/MSI: remove stray endianness definition X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 13:36, "Jan Beulich" wrote: > ... as it conflicts with the one made in asm/byteorder.h, and hence > build fails when both happen to be included from the same source file. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/include/asm-x86/msi.h > +++ b/xen/include/asm-x86/msi.h > @@ -3,6 +3,7 @@ > > #include > #include > +#include > > /* > * Constants for Intel APIC based MSI messages. > @@ -165,8 +166,6 @@ int msi_free_irq(struct msi_desc *entry) > #define MSI_LOGICAL_MODE 1 > #define MSI_REDIRECTION_HINT_MODE 0 > > -#define __LITTLE_ENDIAN_BITFIELD 1 > - > struct msg_data { > #if defined(__LITTLE_ENDIAN_BITFIELD) > __u32 vector : 8; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:26:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIWv-0003J6-Ma; Fri, 04 May 2012 13:26:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIWu-0003Iv-2S for xen-devel@lists.xensource.com; Fri, 04 May 2012 13:26:40 +0000 Received: from [85.158.138.51:37858] by server-9.bemta-3.messagelabs.com id 66/EB-26691-C09D3AF4; Fri, 04 May 2012 13:26:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336137994!21206908!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17810 invoked from network); 4 May 2012 13:26:36 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 13:26:36 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44DQVGI009440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 13:26:31 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44DQUMN025213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 13:26:30 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 q44DQU5P000828; Fri, 4 May 2012 08:26:30 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 06:26:30 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C99C24031D; Fri, 4 May 2012 09:20:46 -0400 (EDT) Date: Fri, 4 May 2012 09:20:46 -0400 From: Konrad Rzeszutek Wilk To: "Hao, Xudong" Message-ID: <20120504132046.GD26418@phenom.dumpdata.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted. > > Changes from v1: > - put the variable definition at the start of function > - add error log report > Don't you need to disable this when the device is un-assigned from the guest? > Signed-off-by: Xudong Hao > > diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c > index 097e536..74fbf23 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) > struct xen_pcibk_dev_data *dev_data; > int err = 0; > > + /* set default value */ > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; Why these values? Is there a way to fetch optimal values? > + > dev_dbg(&dev->dev, "initializing...\n"); > > /* The PCI backend is not intended to be a module (or to work with > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) > dev_dbg(&dev->dev, "reset device\n"); > xen_pcibk_reset_device(dev); > > + /* Enable LTR and OBFF before do device assignment */ > + /* LTR(Latency tolerance reporting) allows devices to send > + * messages to the root complex indicating their latency tolerance > + * for snooped & unsnooped memory transactions. > + */ > + err = pci_enable_ltr(dev); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > + > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > + if (err) > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > + > + /* OBFF (optimized buffer flush/fill), where supported, can help > + * improve energy efficiency by giving devices information about > + * when interrupts and other activity will have a reduced power > + * impact. > + */ > + err = pci_enable_obff(dev, type); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > + > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > return 0; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:26:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIWv-0003J6-Ma; Fri, 04 May 2012 13:26:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIWu-0003Iv-2S for xen-devel@lists.xensource.com; Fri, 04 May 2012 13:26:40 +0000 Received: from [85.158.138.51:37858] by server-9.bemta-3.messagelabs.com id 66/EB-26691-C09D3AF4; Fri, 04 May 2012 13:26:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336137994!21206908!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17810 invoked from network); 4 May 2012 13:26:36 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 13:26:36 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44DQVGI009440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 13:26:31 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44DQUMN025213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 13:26:30 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 q44DQU5P000828; Fri, 4 May 2012 08:26:30 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 06:26:30 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C99C24031D; Fri, 4 May 2012 09:20:46 -0400 (EDT) Date: Fri, 4 May 2012 09:20:46 -0400 From: Konrad Rzeszutek Wilk To: "Hao, Xudong" Message-ID: <20120504132046.GD26418@phenom.dumpdata.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > When PCIE device which has LTR/OBFF capabilities is owned by pciback, LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that guest with device assigned can be benefitted. > > Changes from v1: > - put the variable definition at the start of function > - add error log report > Don't you need to disable this when the device is un-assigned from the guest? > Signed-off-by: Xudong Hao > > diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c > index 097e536..74fbf23 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) > struct xen_pcibk_dev_data *dev_data; > int err = 0; > > + /* set default value */ > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; Why these values? Is there a way to fetch optimal values? > + > dev_dbg(&dev->dev, "initializing...\n"); > > /* The PCI backend is not intended to be a module (or to work with > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) > dev_dbg(&dev->dev, "reset device\n"); > xen_pcibk_reset_device(dev); > > + /* Enable LTR and OBFF before do device assignment */ > + /* LTR(Latency tolerance reporting) allows devices to send > + * messages to the root complex indicating their latency tolerance > + * for snooped & unsnooped memory transactions. > + */ > + err = pci_enable_ltr(dev); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > + > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > + if (err) > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > + > + /* OBFF (optimized buffer flush/fill), where supported, can help > + * improve energy efficiency by giving devices information about > + * when interrupts and other activity will have a reduced power > + * impact. > + */ > + err = pci_enable_obff(dev, type); > + if (err) > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > + > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > return 0; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:27:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIXU-0003Mk-48; Fri, 04 May 2012 13:27:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIXS-0003MV-5q for xen-devel@lists.xen.org; Fri, 04 May 2012 13:27:14 +0000 Received: from [85.158.143.35:44624] by server-2.bemta-4.messagelabs.com id AD/FF-17550-039D3AF4; Fri, 04 May 2012 13:27:12 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336138031!12682125!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8564 invoked from network); 4 May 2012 13:27:11 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:27:11 -0000 Received: by eaaf11 with SMTP id f11so912105eaa.32 for ; Fri, 04 May 2012 06:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=GhtzIXCHlM0VrscpG0mw/ecXZ+LNlDmhm0EWFIbSu+s=; b=Fs8hw8f0UDS8US6vAsdIVaxjSXIwpBZO++n6EuPIb/NzzpB9WDlHZNU1hN8eyKu8XL 7QVfLnluyktK0eS9+vdR4NSMGc/ACO9UyArlPBra8RKp5NaQADL6jlSaaH+Zds2Tqysn YaIaH2RAvbl2Z6TY8IREIQ2zObw7GC5bitCu+/IVV1l1GtcntJ9jzkL4JKk3q5QtPY7b /LYVA8LRfbaPi28uBbyMKp3dt/ZO5+e8glJsqyPU8RL240oPfzvUmSX//GooDuSQKmpf oqQVly2kvVxKI1BJZ662dAmBdZIKpnAgXXKp1vSrfxPZH9w4UnB1tck38OhV/DoxlJfr oa0w== Received: by 10.14.95.131 with SMTP id p3mr1139567eef.75.1336138030959; Fri, 04 May 2012 06:27:10 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id s54sm12932235eeb.4.2012.05.04.06.27.09 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:27:10 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:27:03 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p+ZePRBwmIx2VskqK62N/W2PmeA== In-Reply-To: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 13:46, "Jan Beulich" wrote: >>>> On 04.05.12 at 14:03, Keir Fraser wrote: >> On 04/05/2012 12:05, "Jan Beulich" wrote: >> >>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 >>>> bytes >>>> per CPU of the poll_port variable isn't worth much optimising effort. >>> >>> Certainly not (and as you say they are actually needed, even if >>> only rarely). But the pointlessly running timer(s) might be, as might >>> the buffer(s) set up via serial_async_transmit(). >> >> We could delay {init,setup}_postirq until a corresponding serial handle has >> been created via serial_parse_handle()? The logic might be a bit ugly and >> spread across both serial.c and ns16550.c but not actually particularly >> complicated? > > I think this can be done entirely in serial.c - serial_init_postirq() > would directly call any drivers that already got a handle parsed > for them, and serial_parse_handle() would need to call > ->init_postirq() for any driver that didn't have it called already. > serial_suspend() and serial_resume() should then call drivers only > if they previously had ->init_postirq() called. Ah yes, that would work. Feel free to make a patch. -- Keir > I definitely want to avoid putting any part of this into ns16550.c, > as it would need to be replicated for ARM's pl011.c as well as any > future ones (I'm now mostly done with an EHCI debug port driver, > but due to feature freeze won't be able to post this as other than > an RFC any time soon; xHCI appears to also have a debug port, > so in the future that might become a third alternative). > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:27:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIXU-0003Mk-48; Fri, 04 May 2012 13:27:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIXS-0003MV-5q for xen-devel@lists.xen.org; Fri, 04 May 2012 13:27:14 +0000 Received: from [85.158.143.35:44624] by server-2.bemta-4.messagelabs.com id AD/FF-17550-039D3AF4; Fri, 04 May 2012 13:27:12 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336138031!12682125!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8564 invoked from network); 4 May 2012 13:27:11 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:27:11 -0000 Received: by eaaf11 with SMTP id f11so912105eaa.32 for ; Fri, 04 May 2012 06:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=GhtzIXCHlM0VrscpG0mw/ecXZ+LNlDmhm0EWFIbSu+s=; b=Fs8hw8f0UDS8US6vAsdIVaxjSXIwpBZO++n6EuPIb/NzzpB9WDlHZNU1hN8eyKu8XL 7QVfLnluyktK0eS9+vdR4NSMGc/ACO9UyArlPBra8RKp5NaQADL6jlSaaH+Zds2Tqysn YaIaH2RAvbl2Z6TY8IREIQ2zObw7GC5bitCu+/IVV1l1GtcntJ9jzkL4JKk3q5QtPY7b /LYVA8LRfbaPi28uBbyMKp3dt/ZO5+e8glJsqyPU8RL240oPfzvUmSX//GooDuSQKmpf oqQVly2kvVxKI1BJZ662dAmBdZIKpnAgXXKp1vSrfxPZH9w4UnB1tck38OhV/DoxlJfr oa0w== Received: by 10.14.95.131 with SMTP id p3mr1139567eef.75.1336138030959; Fri, 04 May 2012 06:27:10 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id s54sm12932235eeb.4.2012.05.04.06.27.09 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:27:10 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:27:03 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p+ZePRBwmIx2VskqK62N/W2PmeA== In-Reply-To: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 13:46, "Jan Beulich" wrote: >>>> On 04.05.12 at 14:03, Keir Fraser wrote: >> On 04/05/2012 12:05, "Jan Beulich" wrote: >> >>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 >>>> bytes >>>> per CPU of the poll_port variable isn't worth much optimising effort. >>> >>> Certainly not (and as you say they are actually needed, even if >>> only rarely). But the pointlessly running timer(s) might be, as might >>> the buffer(s) set up via serial_async_transmit(). >> >> We could delay {init,setup}_postirq until a corresponding serial handle has >> been created via serial_parse_handle()? The logic might be a bit ugly and >> spread across both serial.c and ns16550.c but not actually particularly >> complicated? > > I think this can be done entirely in serial.c - serial_init_postirq() > would directly call any drivers that already got a handle parsed > for them, and serial_parse_handle() would need to call > ->init_postirq() for any driver that didn't have it called already. > serial_suspend() and serial_resume() should then call drivers only > if they previously had ->init_postirq() called. Ah yes, that would work. Feel free to make a patch. -- Keir > I definitely want to avoid putting any part of this into ns16550.c, > as it would need to be replicated for ARM's pl011.c as well as any > future ones (I'm now mostly done with an EHCI debug port driver, > but due to feature freeze won't be able to post this as other than > an RFC any time soon; xHCI appears to also have a debug port, > so in the future that might become a third alternative). > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:30:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:30:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIaJ-0003aF-MV; Fri, 04 May 2012 13:30:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIaI-0003a8-5G for xen-devel@lists.xensource.com; Fri, 04 May 2012 13:30:10 +0000 Received: from [85.158.143.35:28860] by server-3.bemta-4.messagelabs.com id FB/DE-05853-1E9D3AF4; Fri, 04 May 2012 13:30:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336138206!14733858!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19874 invoked from network); 4 May 2012 13:30:08 -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 May 2012 13:30:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12298981" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 13:30:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 14:30:06 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQIaE-00020X-7J; Fri, 04 May 2012 13:30:06 +0000 From: David Vrabel To: Date: Fri, 4 May 2012 14:29:46 +0100 Message-ID: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: linux-pci@vger.kernel.org, x86@kernel.org, David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH v2] x86, xen, pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Signed-off-by: David Vrabel --- Changes in v2: - improve commit message --- arch/x86/xen/enlighten.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..7ce2c78 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -63,6 +63,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI #include @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void) /* Make sure ACS will be enabled */ pci_request_acs(); } - + + /* PCI BIOS service won't work from a PV guest. */ + pci_probe &= ~PCI_PROBE_BIOS; xen_raw_console_write("about to get started...\n"); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:30:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:30:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIaJ-0003aF-MV; Fri, 04 May 2012 13:30:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIaI-0003a8-5G for xen-devel@lists.xensource.com; Fri, 04 May 2012 13:30:10 +0000 Received: from [85.158.143.35:28860] by server-3.bemta-4.messagelabs.com id FB/DE-05853-1E9D3AF4; Fri, 04 May 2012 13:30:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336138206!14733858!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19874 invoked from network); 4 May 2012 13:30:08 -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 May 2012 13:30:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12298981" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 13:30:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 14:30:06 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQIaE-00020X-7J; Fri, 04 May 2012 13:30:06 +0000 From: David Vrabel To: Date: Fri, 4 May 2012 14:29:46 +0100 Message-ID: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: linux-pci@vger.kernel.org, x86@kernel.org, David Vrabel , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH v2] x86, xen, pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Signed-off-by: David Vrabel --- Changes in v2: - improve commit message --- arch/x86/xen/enlighten.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..7ce2c78 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -63,6 +63,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI #include @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void) /* Make sure ACS will be enabled */ pci_request_acs(); } - + + /* PCI BIOS service won't work from a PV guest. */ + pci_probe &= ~PCI_PROBE_BIOS; xen_raw_console_write("about to get started...\n"); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:55:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIyd-0004cK-4U; Fri, 04 May 2012 13:55:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIyb-0004cC-KF for xen-devel@lists.xen.org; Fri, 04 May 2012 13:55:17 +0000 Received: from [85.158.138.51:12516] by server-6.bemta-3.messagelabs.com id 44/2C-05145-4CFD3AF4; Fri, 04 May 2012 13:55:16 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336139715!19220493!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12791 invoked from network); 4 May 2012 13:55:15 -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; 4 May 2012 13:55:15 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 14:55:14 +0100 Message-Id: <4FA3FBE10200007800081ABA@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 14:55:13 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 15:27, Keir Fraser wrote: > On 04/05/2012 13:46, "Jan Beulich" wrote: > >>>>> On 04.05.12 at 14:03, Keir Fraser wrote: >>> On 04/05/2012 12:05, "Jan Beulich" wrote: >>> >>>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 >>>>> bytes >>>>> per CPU of the poll_port variable isn't worth much optimising effort. >>>> >>>> Certainly not (and as you say they are actually needed, even if >>>> only rarely). But the pointlessly running timer(s) might be, as might >>>> the buffer(s) set up via serial_async_transmit(). >>> >>> We could delay {init,setup}_postirq until a corresponding serial handle has >>> been created via serial_parse_handle()? The logic might be a bit ugly and >>> spread across both serial.c and ns16550.c but not actually particularly >>> complicated? >> >> I think this can be done entirely in serial.c - serial_init_postirq() >> would directly call any drivers that already got a handle parsed >> for them, and serial_parse_handle() would need to call >> ->init_postirq() for any driver that didn't have it called already. >> serial_suspend() and serial_resume() should then call drivers only >> if they previously had ->init_postirq() called. > > Ah yes, that would work. Feel free to make a patch. That'll be on top of the other post-4.2 changes I'm in the process of piling up, as this isn't really a bug fix. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:55:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13: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 ) id 1SQIyd-0004cK-4U; Fri, 04 May 2012 13:55:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQIyb-0004cC-KF for xen-devel@lists.xen.org; Fri, 04 May 2012 13:55:17 +0000 Received: from [85.158.138.51:12516] by server-6.bemta-3.messagelabs.com id 44/2C-05145-4CFD3AF4; Fri, 04 May 2012 13:55:16 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336139715!19220493!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12791 invoked from network); 4 May 2012 13:55:15 -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; 4 May 2012 13:55:15 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 14:55:14 +0100 Message-Id: <4FA3FBE10200007800081ABA@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 14:55:13 +0100 From: "Jan Beulich" To: "Keir Fraser" References: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 15:27, Keir Fraser wrote: > On 04/05/2012 13:46, "Jan Beulich" wrote: > >>>>> On 04.05.12 at 14:03, Keir Fraser wrote: >>> On 04/05/2012 12:05, "Jan Beulich" wrote: >>> >>>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 >>>>> bytes >>>>> per CPU of the poll_port variable isn't worth much optimising effort. >>>> >>>> Certainly not (and as you say they are actually needed, even if >>>> only rarely). But the pointlessly running timer(s) might be, as might >>>> the buffer(s) set up via serial_async_transmit(). >>> >>> We could delay {init,setup}_postirq until a corresponding serial handle has >>> been created via serial_parse_handle()? The logic might be a bit ugly and >>> spread across both serial.c and ns16550.c but not actually particularly >>> complicated? >> >> I think this can be done entirely in serial.c - serial_init_postirq() >> would directly call any drivers that already got a handle parsed >> for them, and serial_parse_handle() would need to call >> ->init_postirq() for any driver that didn't have it called already. >> serial_suspend() and serial_resume() should then call drivers only >> if they previously had ->init_postirq() called. > > Ah yes, that would work. Feel free to make a patch. That'll be on top of the other post-4.2 changes I'm in the process of piling up, as this isn't really a bug fix. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:58:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:58:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ1L-0004jI-N5; Fri, 04 May 2012 13:58:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ1K-0004jD-26 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:58:06 +0000 Received: from [85.158.138.51:56664] by server-8.bemta-3.messagelabs.com id 6C/4E-24428-D60E3AF4; Fri, 04 May 2012 13:58:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336139884!19221002!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23905 invoked from network); 4 May 2012 13:58:04 -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; 4 May 2012 13:58:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 14:58:03 +0100 Message-Id: <4FA3FC8A0200007800081AC3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 14:58:02 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: linux-pci@vger.kernel.org, x86@kernel.org, Konrad Rzeszutek Wilk , xen-devel Subject: Re: [Xen-devel] [PATCH v2] x86, xen, pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 15:29, David Vrabel wrote: > From: David Vrabel > > The accessing PCI configuration space with the PCI BIOS32 service does > not work in PV guests. > > On systems without MMCONFIG or where the BIOS hasn't marked the > MMCONFIG region as reserved in the e820 map, the BIOS service is > probed (even though direct access is preferred) and this hangs. > > Signed-off-by: David Vrabel Acked-by: Jan Beulich > --- > Changes in v2: > - improve commit message > > --- > arch/x86/xen/enlighten.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..7ce2c78 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -63,6 +63,7 @@ > #include > #include > #include > +#include > > #ifdef CONFIG_ACPI > #include > @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void) > /* Make sure ACS will be enabled */ > pci_request_acs(); > } > - > + > + /* PCI BIOS service won't work from a PV guest. */ > + pci_probe &= ~PCI_PROBE_BIOS; > > xen_raw_console_write("about to get started...\n"); > > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 13:58:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 13:58:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ1L-0004jI-N5; Fri, 04 May 2012 13:58:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ1K-0004jD-26 for xen-devel@lists.xen.org; Fri, 04 May 2012 13:58:06 +0000 Received: from [85.158.138.51:56664] by server-8.bemta-3.messagelabs.com id 6C/4E-24428-D60E3AF4; Fri, 04 May 2012 13:58:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336139884!19221002!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23905 invoked from network); 4 May 2012 13:58:04 -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; 4 May 2012 13:58:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 14:58:03 +0100 Message-Id: <4FA3FC8A0200007800081AC3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 14:58:02 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1336138186-11423-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: linux-pci@vger.kernel.org, x86@kernel.org, Konrad Rzeszutek Wilk , xen-devel Subject: Re: [Xen-devel] [PATCH v2] x86, xen, pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 15:29, David Vrabel wrote: > From: David Vrabel > > The accessing PCI configuration space with the PCI BIOS32 service does > not work in PV guests. > > On systems without MMCONFIG or where the BIOS hasn't marked the > MMCONFIG region as reserved in the e820 map, the BIOS service is > probed (even though direct access is preferred) and this hangs. > > Signed-off-by: David Vrabel Acked-by: Jan Beulich > --- > Changes in v2: > - improve commit message > > --- > arch/x86/xen/enlighten.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a8f8844..7ce2c78 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -63,6 +63,7 @@ > #include > #include > #include > +#include > > #ifdef CONFIG_ACPI > #include > @@ -1365,7 +1366,9 @@ asmlinkage void __init xen_start_kernel(void) > /* Make sure ACS will be enabled */ > pci_request_acs(); > } > - > + > + /* PCI BIOS service won't work from a PV guest. */ > + pci_probe &= ~PCI_PROBE_BIOS; > > xen_raw_console_write("about to get started...\n"); > > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:00:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:00:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ3A-0004qD-5o; Fri, 04 May 2012 14:00:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ39-0004q5-9y for xen-devel@lists.xen.org; Fri, 04 May 2012 13:59:59 +0000 Received: from [85.158.139.83:48253] by server-4.bemta-5.messagelabs.com id 41/CA-10788-ED0E3AF4; Fri, 04 May 2012 13:59:58 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336139997!22913025!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22295 invoked from network); 4 May 2012 13:59:57 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:59:57 -0000 Received: by eekc4 with SMTP id c4so380477eek.32 for ; Fri, 04 May 2012 06:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=YkCzDQNvGXA2Gc3NfeJ5zu/Sss2oYOMdaQPrbkOTFnQ=; b=uxgKaaurdSBYTjiGGJgDsl0KYovbtbD6trT+bCJ2eAtGyovSIUFYwzm8luZHNewVmR hnQESbX2dV8IydEaSSrtul4LLYYEUXZC1UB7EReGjlXucXZyQAmeFbrraTrP6bHYE9gJ GmdeTE5Xa+aq/hRQWutPyrB49rJPJZOTpAoNWCRWiCtl4e2CONJza0piWjW/IQhP8P4k Pa+KLWbPR+acgltAHimMql2I/tm3F1vaINZAXtMk0kl9zeCaGjphUIjZ1l2zVLl8NgGF X8xx+2UXXFj5h4soe9KldJGxYLtdeEZ+et4jwA/5dyWHVAhxLyYDZ208NT+5xnLM05SM bW2A== Received: by 10.14.101.134 with SMTP id b6mr1202261eeg.5.1336139997451; Fri, 04 May 2012 06:59:57 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm42052906eea.3.2012.05.04.06.59.55 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:59:57 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:59:49 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p/itjtjYB3tjYNk+PubpVtLGcMg== In-Reply-To: <4FA3FBE10200007800081ABA@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 14:55, "Jan Beulich" wrote: >>> I think this can be done entirely in serial.c - serial_init_postirq() >>> would directly call any drivers that already got a handle parsed >>> for them, and serial_parse_handle() would need to call >>> ->init_postirq() for any driver that didn't have it called already. >>> serial_suspend() and serial_resume() should then call drivers only >>> if they previously had ->init_postirq() called. >> >> Ah yes, that would work. Feel free to make a patch. > > That'll be on top of the other post-4.2 changes I'm in the process > of piling up, as this isn't really a bug fix. Agreed. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:00:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:00:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ3A-0004qD-5o; Fri, 04 May 2012 14:00:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ39-0004q5-9y for xen-devel@lists.xen.org; Fri, 04 May 2012 13:59:59 +0000 Received: from [85.158.139.83:48253] by server-4.bemta-5.messagelabs.com id 41/CA-10788-ED0E3AF4; Fri, 04 May 2012 13:59:58 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336139997!22913025!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22295 invoked from network); 4 May 2012 13:59:57 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 13:59:57 -0000 Received: by eekc4 with SMTP id c4so380477eek.32 for ; Fri, 04 May 2012 06:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=YkCzDQNvGXA2Gc3NfeJ5zu/Sss2oYOMdaQPrbkOTFnQ=; b=uxgKaaurdSBYTjiGGJgDsl0KYovbtbD6trT+bCJ2eAtGyovSIUFYwzm8luZHNewVmR hnQESbX2dV8IydEaSSrtul4LLYYEUXZC1UB7EReGjlXucXZyQAmeFbrraTrP6bHYE9gJ GmdeTE5Xa+aq/hRQWutPyrB49rJPJZOTpAoNWCRWiCtl4e2CONJza0piWjW/IQhP8P4k Pa+KLWbPR+acgltAHimMql2I/tm3F1vaINZAXtMk0kl9zeCaGjphUIjZ1l2zVLl8NgGF X8xx+2UXXFj5h4soe9KldJGxYLtdeEZ+et4jwA/5dyWHVAhxLyYDZ208NT+5xnLM05SM bW2A== Received: by 10.14.101.134 with SMTP id b6mr1202261eeg.5.1336139997451; Fri, 04 May 2012 06:59:57 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm42052906eea.3.2012.05.04.06.59.55 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 06:59:57 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 04 May 2012 14:59:49 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: ns16550.c's poll_port variable Thread-Index: Ac0p/itjtjYB3tjYNk+PubpVtLGcMg== In-Reply-To: <4FA3FBE10200007800081ABA@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] ns16550.c's poll_port variable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/2012 14:55, "Jan Beulich" wrote: >>> I think this can be done entirely in serial.c - serial_init_postirq() >>> would directly call any drivers that already got a handle parsed >>> for them, and serial_parse_handle() would need to call >>> ->init_postirq() for any driver that didn't have it called already. >>> serial_suspend() and serial_resume() should then call drivers only >>> if they previously had ->init_postirq() called. >> >> Ah yes, that would work. Feel free to make a patch. > > That'll be on top of the other post-4.2 changes I'm in the process > of piling up, as this isn't really a bug fix. Agreed. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:05:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJ8C-00059O-67; Fri, 04 May 2012 14:05:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ8A-00059I-OW for xen-devel@lists.xen.org; Fri, 04 May 2012 14:05:10 +0000 Received: from [85.158.138.51:58884] by server-11.bemta-3.messagelabs.com id 84/F5-18894-612E3AF4; Fri, 04 May 2012 14:05:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336140309!19222711!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4695 invoked from network); 4 May 2012 14:05:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:05:09 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300119" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:04:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:04:43 +0100 Message-ID: <1336140282.2361.71.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:04:42 +0100 In-Reply-To: <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/7] vgabios: Output to Qemu debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Bios was outputing into port 0xe9 while Qemu use 0x12 0xe9 is also the Xen HVM debug port (see hvm_print_line), don't be confused by the fact that it happens to be the same as the bochs port. Ian. > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vgabios.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c > index a9dbe00..e0b1ed9 100644 > --- a/tools/firmware/vgabios/vgabios.c > +++ b/tools/firmware/vgabios/vgabios.c > @@ -3811,9 +3811,9 @@ void printf(s) > for (i=0; i nibble = (arg >> (4 * digit)) & 0x000f; > if (nibble <= 9) > - outb(0xe9, nibble + '0'); > + outb(0x12, nibble + '0'); > else > - outb(0xe9, (nibble - 10) + 'A'); > + outb(0x12, (nibble - 10) + 'A'); > digit--; > } > in_format = 0; > @@ -3823,7 +3823,7 @@ void printf(s) > // } > } > else { > - outb(0xe9, c); > + outb(0x12, c); > } > s ++; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:05:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJ8C-00059O-67; Fri, 04 May 2012 14:05:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJ8A-00059I-OW for xen-devel@lists.xen.org; Fri, 04 May 2012 14:05:10 +0000 Received: from [85.158.138.51:58884] by server-11.bemta-3.messagelabs.com id 84/F5-18894-612E3AF4; Fri, 04 May 2012 14:05:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336140309!19222711!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4695 invoked from network); 4 May 2012 14:05:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:05:09 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300119" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:04:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:04:43 +0100 Message-ID: <1336140282.2361.71.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:04:42 +0100 In-Reply-To: <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-2-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/7] vgabios: Output to Qemu debug port instead of using Bochs one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Bios was outputing into port 0xe9 while Qemu use 0x12 0xe9 is also the Xen HVM debug port (see hvm_print_line), don't be confused by the fact that it happens to be the same as the bochs port. Ian. > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vgabios.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vgabios.c b/tools/firmware/vgabios/vgabios.c > index a9dbe00..e0b1ed9 100644 > --- a/tools/firmware/vgabios/vgabios.c > +++ b/tools/firmware/vgabios/vgabios.c > @@ -3811,9 +3811,9 @@ void printf(s) > for (i=0; i nibble = (arg >> (4 * digit)) & 0x000f; > if (nibble <= 9) > - outb(0xe9, nibble + '0'); > + outb(0x12, nibble + '0'); > else > - outb(0xe9, (nibble - 10) + 'A'); > + outb(0x12, (nibble - 10) + 'A'); > digit--; > } > in_format = 0; > @@ -3823,7 +3823,7 @@ void printf(s) > // } > } > else { > - outb(0xe9, c); > + outb(0x12, c); > } > s ++; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQJDC-0005N4-2s; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mo-7q for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [85.158.138.51:54921] by server-11.bemta-3.messagelabs.com id D6/36-18894-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336140617!25248460!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18718 invoked from network); 4 May 2012 14:10:18 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAF3V029295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAFor000755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAFRN009853; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id CE59F4031E; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:23 -0400 Message-Id: <1336140267-7399-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] Subject: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Was thinking to push these patches to Linus for v3.5-rc6. arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++-- arch/x86/xen/mmu.c | 7 ++++++- drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- 3 files changed, 59 insertions(+), 13 deletions(-) David Vrabel (1): xen/pci: don't use PCI BIOS service for configuration space accesses Julia Lawall (1): drivers/video/xen-fbfront.c: add missing cleanup code Konrad Rzeszutek Wilk (2): xen/apic: Return the APIC ID (and version) for CPU 0. xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQJDC-0005N4-2s; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mo-7q for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [85.158.138.51:54921] by server-11.bemta-3.messagelabs.com id D6/36-18894-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336140617!25248460!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18718 invoked from network); 4 May 2012 14:10:18 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAF3V029295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAFor000755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAFRN009853; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id CE59F4031E; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:23 -0400 Message-Id: <1336140267-7399-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] Subject: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Was thinking to push these patches to Linus for v3.5-rc6. arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++-- arch/x86/xen/mmu.c | 7 ++++++- drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- 3 files changed, 59 insertions(+), 13 deletions(-) David Vrabel (1): xen/pci: don't use PCI BIOS service for configuration space accesses Julia Lawall (1): drivers/video/xen-fbfront.c: add missing cleanup code Konrad Rzeszutek Wilk (2): xen/apic: Return the APIC ID (and version) for CPU 0. xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDC-0005NK-QR; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mq-CF for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [85.158.139.83:17632] by server-12.bemta-5.messagelabs.com id 7C/AF-01344-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336140617!22834979!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8554 invoked from network); 4 May 2012 14:10:18 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:18 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGUj032717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAFbJ021153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAF2v001562; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DE6C54035B; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:25 -0400 Message-Id: <1336140267-7399-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/4] xen/apic: Return the APIC ID (and version) for CPU 0. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On x86_64 on AMD machines where the first APIC_ID is not zero, we get: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 which means that when the ACPI processor driver loads and tries to parse the _Pxx states it fails to do as, as it ends up calling acpi_get_cpuid which does this: for_each_possible_cpu(i) { if (cpu_physical_id(i) == apic_id) return i; } And the bootup CPU, has not been found so it fails and returns -1 for the first CPU - which then subsequently in the loop that "acpi_processor_get_info" does results in returning an error, which means that "acpi_processor_add" failing and per_cpu(processor) is never set (and is NULL). That means that when xen-acpi-processor tries to load (much much later on) and parse the P-states it gets -ENODEV from acpi_processor_register_performance() (which tries to read the per_cpu(processor)) and fails to parse the data. Reported-by-and-Tested-by: Stefan Bader Suggested-by: Boris Ostrovsky [v2: Bit-shift APIC ID by 24 bits] Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/enlighten.c | 35 ++++++++++++++++++++++++++++++++++- 1 files changed, 34 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..4f437de 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -809,9 +809,40 @@ static void xen_io_delay(void) } #ifdef CONFIG_X86_LOCAL_APIC +static unsigned long xen_set_apic_id(unsigned int x) +{ + WARN_ON(1); + return x; +} +static unsigned int xen_get_apic_id(unsigned long x) +{ + return ((x)>>24) & 0xFFu; +} static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id << 24; } static void xen_apic_write(u32 reg, u32 val) @@ -849,6 +880,8 @@ static void set_xen_basic_apic_ops(void) apic->icr_write = xen_apic_icr_write; apic->wait_icr_idle = xen_apic_wait_icr_idle; apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; + apic->set_apic_id = xen_set_apic_id; + apic->get_apic_id = xen_get_apic_id; } #endif -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDC-0005NK-QR; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mq-CF for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [85.158.139.83:17632] by server-12.bemta-5.messagelabs.com id 7C/AF-01344-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336140617!22834979!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8554 invoked from network); 4 May 2012 14:10:18 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:18 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGUj032717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAFbJ021153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAF2v001562; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DE6C54035B; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:25 -0400 Message-Id: <1336140267-7399-3-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 2/4] xen/apic: Return the APIC ID (and version) for CPU 0. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On x86_64 on AMD machines where the first APIC_ID is not zero, we get: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x10] enabled) BIOS bug: APIC version is 0 for CPU 1/0x10, fixing up to 0x10 BIOS bug: APIC version mismatch, boot CPU: 0, CPU 1: version 10 which means that when the ACPI processor driver loads and tries to parse the _Pxx states it fails to do as, as it ends up calling acpi_get_cpuid which does this: for_each_possible_cpu(i) { if (cpu_physical_id(i) == apic_id) return i; } And the bootup CPU, has not been found so it fails and returns -1 for the first CPU - which then subsequently in the loop that "acpi_processor_get_info" does results in returning an error, which means that "acpi_processor_add" failing and per_cpu(processor) is never set (and is NULL). That means that when xen-acpi-processor tries to load (much much later on) and parse the P-states it gets -ENODEV from acpi_processor_register_performance() (which tries to read the per_cpu(processor)) and fails to parse the data. Reported-by-and-Tested-by: Stefan Bader Suggested-by: Boris Ostrovsky [v2: Bit-shift APIC ID by 24 bits] Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/enlighten.c | 35 ++++++++++++++++++++++++++++++++++- 1 files changed, 34 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a8f8844..4f437de 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -809,9 +809,40 @@ static void xen_io_delay(void) } #ifdef CONFIG_X86_LOCAL_APIC +static unsigned long xen_set_apic_id(unsigned int x) +{ + WARN_ON(1); + return x; +} +static unsigned int xen_get_apic_id(unsigned long x) +{ + return ((x)>>24) & 0xFFu; +} static u32 xen_apic_read(u32 reg) { - return 0; + struct xen_platform_op op = { + .cmd = XENPF_get_cpuinfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid = 0, + }; + int ret = 0; + + /* Shouldn't need this as APIC is turned off for PV, and we only + * get called on the bootup processor. But just in case. */ + if (!xen_initial_domain() || smp_processor_id()) + return 0; + + if (reg == APIC_LVR) + return 0x10; + + if (reg != APIC_ID) + return 0; + + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return 0; + + return op.u.pcpu_info.apic_id << 24; } static void xen_apic_write(u32 reg, u32 val) @@ -849,6 +880,8 @@ static void set_xen_basic_apic_ops(void) apic->icr_write = xen_apic_icr_write; apic->wait_icr_idle = xen_apic_wait_icr_idle; apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle; + apic->set_apic_id = xen_set_apic_id; + apic->get_apic_id = xen_get_apic_id; } #endif -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJDK-0005OO-6t; Fri, 04 May 2012 14:10:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDI-0005Ny-Mq for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:28 +0000 Received: from [85.158.143.35:48567] by server-1.bemta-4.messagelabs.com id 5C/37-20925-453E3AF4; Fri, 04 May 2012 14:10:28 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336140624!14166789!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7880 invoked from network); 4 May 2012 14:10:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGG0032716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44EAFXq000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44EAFHT001565; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id F122D4035E; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:27 -0400 Message-Id: <1336140267-7399-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Konrad Rzeszutek Wilk , David Vrabel , stable@kernel.org Subject: [Xen-devel] [PATCH 4/4] xen/pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. CC: stable@kernel.org Acked-by: Jan Beulich Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/enlighten.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 4f437de..fbf9a75 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -63,6 +63,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI #include @@ -1398,7 +1399,9 @@ asmlinkage void __init xen_start_kernel(void) /* Make sure ACS will be enabled */ pci_request_acs(); } - + + /* PCI BIOS service won't work from a PV guest. */ + pci_probe &= ~PCI_PROBE_BIOS; xen_raw_console_write("about to get started...\n"); -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJDK-0005OO-6t; Fri, 04 May 2012 14:10:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDI-0005Ny-Mq for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:28 +0000 Received: from [85.158.143.35:48567] by server-1.bemta-4.messagelabs.com id 5C/37-20925-453E3AF4; Fri, 04 May 2012 14:10:28 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336140624!14166789!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7880 invoked from network); 4 May 2012 14:10:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 14:10:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGG0032716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44EAFXq000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44EAFHT001565; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id F122D4035E; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:27 -0400 Message-Id: <1336140267-7399-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Konrad Rzeszutek Wilk , David Vrabel , stable@kernel.org Subject: [Xen-devel] [PATCH 4/4] xen/pci: don't use PCI BIOS service for configuration space accesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. CC: stable@kernel.org Acked-by: Jan Beulich Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/enlighten.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 4f437de..fbf9a75 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -63,6 +63,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI #include @@ -1398,7 +1399,9 @@ asmlinkage void __init xen_start_kernel(void) /* Make sure ACS will be enabled */ pci_request_acs(); } - + + /* PCI BIOS service won't work from a PV guest. */ + pci_probe &= ~PCI_PROBE_BIOS; xen_raw_console_write("about to get started...\n"); -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJDL-0005Op-ME; Fri, 04 May 2012 14:10:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDJ-0005O5-Cx for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:29 +0000 Received: from [85.158.143.35:9420] by server-3.bemta-4.messagelabs.com id 55/BB-05853-453E3AF4; Fri, 04 May 2012 14:10:28 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336140625!4354928!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6232 invoked from network); 4 May 2012 14:10:27 -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 May 2012 14:10:27 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAG1a029314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10: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 q44EAFBg025992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:16 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 q44EAFMX009857; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D4F9B4031D; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:24 -0400 Message-Id: <1336140267-7399-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Julia Lawall , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/4] drivers/video/xen-fbfront.c: add missing cleanup code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Julia Lawall The operations in the subsequent error-handling code appear to be also useful here. Acked-by: Florian Tobias Schandinat Signed-off-by: Julia Lawall [v1: Collapse some of the error handling functions] Signed-off-by: Konrad Rzeszutek Wilk --- drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- 1 files changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index cb4529c..aa42160 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev, xenfb_init_shared_page(info, fb_info); ret = xenfb_connect_backend(dev, info); - if (ret < 0) - goto error; + if (ret < 0) { + xenbus_dev_fatal(dev, ret, "xenfb_connect_backend"); + goto error_fb; + } ret = register_framebuffer(fb_info); if (ret) { - fb_deferred_io_cleanup(fb_info); - fb_dealloc_cmap(&fb_info->cmap); - framebuffer_release(fb_info); xenbus_dev_fatal(dev, ret, "register_framebuffer"); - goto error; + goto error_fb; } info->fb_info = fb_info; xenfb_make_preferred_console(); return 0; - error_nomem: - ret = -ENOMEM; - xenbus_dev_fatal(dev, ret, "allocating device memory"); - error: +error_fb: + fb_deferred_io_cleanup(fb_info); + fb_dealloc_cmap(&fb_info->cmap); + framebuffer_release(fb_info); +error_nomem: + if (!ret) { + ret = -ENOMEM; + xenbus_dev_fatal(dev, ret, "allocating device memory"); + } +error: xenfb_remove(dev); return ret; } -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJDL-0005Op-ME; Fri, 04 May 2012 14:10:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDJ-0005O5-Cx for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:29 +0000 Received: from [85.158.143.35:9420] by server-3.bemta-4.messagelabs.com id 55/BB-05853-453E3AF4; Fri, 04 May 2012 14:10:28 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336140625!4354928!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6232 invoked from network); 4 May 2012 14:10:27 -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 May 2012 14:10:27 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAG1a029314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10: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 q44EAFBg025992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:16 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 q44EAFMX009857; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D4F9B4031D; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:24 -0400 Message-Id: <1336140267-7399-2-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Julia Lawall , Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 1/4] drivers/video/xen-fbfront.c: add missing cleanup code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Julia Lawall The operations in the subsequent error-handling code appear to be also useful here. Acked-by: Florian Tobias Schandinat Signed-off-by: Julia Lawall [v1: Collapse some of the error handling functions] Signed-off-by: Konrad Rzeszutek Wilk --- drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- 1 files changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index cb4529c..aa42160 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -458,26 +458,31 @@ static int __devinit xenfb_probe(struct xenbus_device *dev, xenfb_init_shared_page(info, fb_info); ret = xenfb_connect_backend(dev, info); - if (ret < 0) - goto error; + if (ret < 0) { + xenbus_dev_fatal(dev, ret, "xenfb_connect_backend"); + goto error_fb; + } ret = register_framebuffer(fb_info); if (ret) { - fb_deferred_io_cleanup(fb_info); - fb_dealloc_cmap(&fb_info->cmap); - framebuffer_release(fb_info); xenbus_dev_fatal(dev, ret, "register_framebuffer"); - goto error; + goto error_fb; } info->fb_info = fb_info; xenfb_make_preferred_console(); return 0; - error_nomem: - ret = -ENOMEM; - xenbus_dev_fatal(dev, ret, "allocating device memory"); - error: +error_fb: + fb_deferred_io_cleanup(fb_info); + fb_dealloc_cmap(&fb_info->cmap); + framebuffer_release(fb_info); +error_nomem: + if (!ret) { + ret = -ENOMEM; + xenbus_dev_fatal(dev, ret, "allocating device memory"); + } +error: xenfb_remove(dev); return ret; } -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:10:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDC-0005ND-EQ; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mp-6J for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [193.109.254.147:12176] by server-2.bemta-14.messagelabs.com id 06/4E-19409-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336140617!7641001!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12612 invoked from network); 4 May 2012 14:10:18 -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; 4 May 2012 14:10:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGHl029299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAF4g000760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAFuF030457; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E7EBB4035D; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:26 -0400 Message-Id: <1336140267-7399-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 3/4] xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. In this case the ptdump_show bitshifts it and we get this invalid value. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/mmu.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..69f5857 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -353,8 +353,13 @@ static pteval_t pte_mfn_to_pfn(pteval_t val) { if (val & _PAGE_PRESENT) { unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT; + unsigned long pfn = mfn_to_pfn(mfn); + pteval_t flags = val & PTE_FLAGS_MASK; - val = ((pteval_t)mfn_to_pfn(mfn) << PAGE_SHIFT) | flags; + if (unlikely(pfn == ~0)) + val = flags & ~_PAGE_PRESENT; + else + val = ((pteval_t)pfn << PAGE_SHIFT) | flags; } return val; -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:10:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:10:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDC-0005ND-EQ; Fri, 04 May 2012 14:10:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJDA-0005Mp-6J for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:10:20 +0000 Received: from [193.109.254.147:12176] by server-2.bemta-14.messagelabs.com id 06/4E-19409-B43E3AF4; Fri, 04 May 2012 14:10:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336140617!7641001!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12612 invoked from network); 4 May 2012 14:10:18 -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; 4 May 2012 14:10:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44EAGHl029299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 14:10:16 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 q44EAF4g000760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:10:15 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 q44EAFuF030457; Fri, 4 May 2012 09:10:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 07:10:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E7EBB4035D; Fri, 4 May 2012 10:04:30 -0400 (EDT) From: Konrad Rzeszutek Wilk To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Date: Fri, 4 May 2012 10:04:26 -0400 Message-Id: <1336140267-7399-4-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 1.7.7.5 In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 3/4] xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. In this case the ptdump_show bitshifts it and we get this invalid value. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/mmu.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index b8e2794..69f5857 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -353,8 +353,13 @@ static pteval_t pte_mfn_to_pfn(pteval_t val) { if (val & _PAGE_PRESENT) { unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT; + unsigned long pfn = mfn_to_pfn(mfn); + pteval_t flags = val & PTE_FLAGS_MASK; - val = ((pteval_t)mfn_to_pfn(mfn) << PAGE_SHIFT) | flags; + if (unlikely(pfn == ~0)) + val = flags & ~_PAGE_PRESENT; + else + val = ((pteval_t)pfn << PAGE_SHIFT) | flags; } return val; -- 1.7.7.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:12:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJF6-0005kQ-7P; Fri, 04 May 2012 14:12:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJF4-0005jo-JY for xen-devel@lists.xen.org; Fri, 04 May 2012 14:12:18 +0000 Received: from [85.158.139.83:34257] by server-7.bemta-5.messagelabs.com id 93/93-16195-1C3E3AF4; Fri, 04 May 2012 14:12:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336140736!15523533!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17263 invoked from network); 4 May 2012 14:12:17 -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; 4 May 2012 14:12:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300302" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:12: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, 4 May 2012 15:12:16 +0100 Message-ID: <1336140734.2361.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:12:14 +0100 In-Reply-To: <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Remove an overflow computing width x height x bit which does > not fit into a 16 bits. I wrote a routine to multiple these value > and get the size required for framebuffer in segment unit (64k). Couldn't this be done in C using a suitably wide temporary variable? > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- > 1 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index 3d42216..35d9866 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -742,6 +742,29 @@ no_vbe_flag: > jmp _display_string > ASM_END > > +ASM_START > +_size64: > + push bp > + mov bp, sp > + push dx > + > +; multiply bbp by yres first as results fit in 16bits > +; then multiply by xres > + mov ax, 8[bp] > + mul word 6[bp] > + mul word 4[bp] > +; divide by 2^19 ceiling result > + add ax, #0xffff > + adc dx, #7 > + mov ax, dx > + shr ax, #3 > + > + pop dx > + pop bp > + ret > +ASM_END > + > + > /** Function 00h - Return VBE Controller Information > * > * Input: > @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > > do > { > + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); > + Bit16u max_bpp = dispi_get_max_bpp(); > + > if ((cur_info->info.XResolution <= dispi_get_max_xres()) && > - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && > - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { > + (cur_info->info.BitsPerPixel <= max_bpp) && > + (size_64k <= vbe_info_block.TotalMemory)) { > #ifdef DEBUG > printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); > cur_mode++; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:12:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJF6-0005kQ-7P; Fri, 04 May 2012 14:12:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJF4-0005jo-JY for xen-devel@lists.xen.org; Fri, 04 May 2012 14:12:18 +0000 Received: from [85.158.139.83:34257] by server-7.bemta-5.messagelabs.com id 93/93-16195-1C3E3AF4; Fri, 04 May 2012 14:12:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336140736!15523533!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17263 invoked from network); 4 May 2012 14:12:17 -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; 4 May 2012 14:12:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300302" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:12: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, 4 May 2012 15:12:16 +0100 Message-ID: <1336140734.2361.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:12:14 +0100 In-Reply-To: <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Remove an overflow computing width x height x bit which does > not fit into a 16 bits. I wrote a routine to multiple these value > and get the size required for framebuffer in segment unit (64k). Couldn't this be done in C using a suitably wide temporary variable? > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- > 1 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index 3d42216..35d9866 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -742,6 +742,29 @@ no_vbe_flag: > jmp _display_string > ASM_END > > +ASM_START > +_size64: > + push bp > + mov bp, sp > + push dx > + > +; multiply bbp by yres first as results fit in 16bits > +; then multiply by xres > + mov ax, 8[bp] > + mul word 6[bp] > + mul word 4[bp] > +; divide by 2^19 ceiling result > + add ax, #0xffff > + adc dx, #7 > + mov ax, dx > + shr ax, #3 > + > + pop dx > + pop bp > + ret > +ASM_END > + > + > /** Function 00h - Return VBE Controller Information > * > * Input: > @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > > do > { > + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); > + Bit16u max_bpp = dispi_get_max_bpp(); > + > if ((cur_info->info.XResolution <= dispi_get_max_xres()) && > - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && > - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { > + (cur_info->info.BitsPerPixel <= max_bpp) && > + (size_64k <= vbe_info_block.TotalMemory)) { > #ifdef DEBUG > printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); > cur_mode++; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:18:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:18:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKr-0006IK-1s; Fri, 04 May 2012 14:18:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKp-0006IF-6S for xen-devel@lists.xen.org; Fri, 04 May 2012 14:18:15 +0000 Received: from [85.158.138.51:27664] by server-7.bemta-3.messagelabs.com id 79/CE-03078-625E3AF4; Fri, 04 May 2012 14:18:14 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336141093!25290396!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24492 invoked from network); 4 May 2012 14:18:14 -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; 4 May 2012 14:18:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300440" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:13 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:18:13 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:18:13 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qAL2ay3MzUtUZS/mnwIIahEQ0rA== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> In-Reply-To: <1336140734.2361.72.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > Remove an overflow computing width x height x bit which does > > not fit into a 16 bits. I wrote a routine to multiple these value > > and get the size required for framebuffer in segment unit (64k). > > Couldn't this be done in C using a suitably wide temporary variable? > I'd like :( BCC compiler used need some function which are not linked by BIOS. Personally I would switch to something more clever like OpenWatcom but mainly I wrote some small asm. I think bochs code fix the issue providing a asm function used by compiler but seems more hacky than my function. Frediano > > > > Signed-off-by: Frediano Ziglio > > --- > > tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- > > 1 files changed, 28 insertions(+), 2 deletions(-) > > > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > > index 3d42216..35d9866 100644 > > --- a/tools/firmware/vgabios/vbe.c > > +++ b/tools/firmware/vgabios/vbe.c > > @@ -742,6 +742,29 @@ no_vbe_flag: > > jmp _display_string > > ASM_END > > > > +ASM_START > > +_size64: > > + push bp > > + mov bp, sp > > + push dx > > + > > +; multiply bbp by yres first as results fit in 16bits > > +; then multiply by xres > > + mov ax, 8[bp] > > + mul word 6[bp] > > + mul word 4[bp] > > +; divide by 2^19 ceiling result > > + add ax, #0xffff > > + adc dx, #7 > > + mov ax, dx > > + shr ax, #3 > > + > > + pop dx > > + pop bp > > + ret > > +ASM_END > > + > > + > > /** Function 00h - Return VBE Controller Information > > * > > * Input: > > @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > > > > do > > { > > + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); > > + Bit16u max_bpp = dispi_get_max_bpp(); > > + > > if ((cur_info->info.XResolution <= dispi_get_max_xres()) && > > - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && > > - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { > > + (cur_info->info.BitsPerPixel <= max_bpp) && > > + (size_64k <= vbe_info_block.TotalMemory)) { > > #ifdef DEBUG > > printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); > > cur_mode++; > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:18:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:18:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKr-0006IK-1s; Fri, 04 May 2012 14:18:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKp-0006IF-6S for xen-devel@lists.xen.org; Fri, 04 May 2012 14:18:15 +0000 Received: from [85.158.138.51:27664] by server-7.bemta-3.messagelabs.com id 79/CE-03078-625E3AF4; Fri, 04 May 2012 14:18:14 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336141093!25290396!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24492 invoked from network); 4 May 2012 14:18:14 -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; 4 May 2012 14:18:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300440" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:13 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:18:13 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:18:13 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qAL2ay3MzUtUZS/mnwIIahEQ0rA== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> In-Reply-To: <1336140734.2361.72.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > Remove an overflow computing width x height x bit which does > > not fit into a 16 bits. I wrote a routine to multiple these value > > and get the size required for framebuffer in segment unit (64k). > > Couldn't this be done in C using a suitably wide temporary variable? > I'd like :( BCC compiler used need some function which are not linked by BIOS. Personally I would switch to something more clever like OpenWatcom but mainly I wrote some small asm. I think bochs code fix the issue providing a asm function used by compiler but seems more hacky than my function. Frediano > > > > Signed-off-by: Frediano Ziglio > > --- > > tools/firmware/vgabios/vbe.c | 30 ++++++++++++++++++++++++++++-- > > 1 files changed, 28 insertions(+), 2 deletions(-) > > > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > > index 3d42216..35d9866 100644 > > --- a/tools/firmware/vgabios/vbe.c > > +++ b/tools/firmware/vgabios/vbe.c > > @@ -742,6 +742,29 @@ no_vbe_flag: > > jmp _display_string > > ASM_END > > > > +ASM_START > > +_size64: > > + push bp > > + mov bp, sp > > + push dx > > + > > +; multiply bbp by yres first as results fit in 16bits > > +; then multiply by xres > > + mov ax, 8[bp] > > + mul word 6[bp] > > + mul word 4[bp] > > +; divide by 2^19 ceiling result > > + add ax, #0xffff > > + adc dx, #7 > > + mov ax, dx > > + shr ax, #3 > > + > > + pop dx > > + pop bp > > + ret > > +ASM_END > > + > > + > > /** Function 00h - Return VBE Controller Information > > * > > * Input: > > @@ -846,9 +869,12 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > > > > do > > { > > + Bit16u size_64k = size64(cur_info->info.XResolution, cur_info->info.YResolution, cur_info->info.BitsPerPixel); > > + Bit16u max_bpp = dispi_get_max_bpp(); > > + > > if ((cur_info->info.XResolution <= dispi_get_max_xres()) && > > - (cur_info->info.BitsPerPixel <= dispi_get_max_bpp()) && > > - (cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel <= vbe_info_block.TotalMemory << 19 )) { > > + (cur_info->info.BitsPerPixel <= max_bpp) && > > + (size_64k <= vbe_info_block.TotalMemory)) { > > #ifdef DEBUG > > printf("VBE found mode %x => %x\n", cur_info->mode,cur_mode); > > cur_mode++; > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:18:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:18:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKy-0006JC-Mk; Fri, 04 May 2012 14:18:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKx-0006J4-EN for xen-devel@lists.xen.org; Fri, 04 May 2012 14:18:23 +0000 Received: from [85.158.143.99:59427] by server-3.bemta-4.messagelabs.com id D5/A6-05853-E25E3AF4; Fri, 04 May 2012 14:18:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336141102!25610867!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21178 invoked from network); 4 May 2012 14:18:22 -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; 4 May 2012 14:18:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300445" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:18:21 +0100 Message-ID: <1336141100.2361.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:18:20 +0100 In-Reply-To: <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > If you try to get mode information for an unsupported mode > interrupt should return error but not that the function is not > supported. > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index 35d9866..fff314e 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > void vbe_biosfn_return_mode_information(AX, CX, ES, DI) > Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > { > - Bit16u result=0x0100; > + // error by default is 0x014f which means supported but error > + Bit16u result=0x014f; Something odd has happened to the whitepace here. Otherwise: Acked-by: Ian Campbell > Bit16u ss=get_SS(); > ModeInfoBlock info; > ModeInfoListItem *cur_info; > @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > #ifdef DEBUG > printf("VBE *NOT* found mode %x\n",CX); > #endif > - result = 0x100; > } > > if (result == 0x4f) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:18:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:18:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKy-0006JC-Mk; Fri, 04 May 2012 14:18:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJKx-0006J4-EN for xen-devel@lists.xen.org; Fri, 04 May 2012 14:18:23 +0000 Received: from [85.158.143.99:59427] by server-3.bemta-4.messagelabs.com id D5/A6-05853-E25E3AF4; Fri, 04 May 2012 14:18:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336141102!25610867!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21178 invoked from network); 4 May 2012 14:18:22 -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; 4 May 2012 14:18:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300445" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 15:18:21 +0100 Message-ID: <1336141100.2361.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:18:20 +0100 In-Reply-To: <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-5-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4/7] vgabios: Report mode not supported getting mode informations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > If you try to get mode information for an unsupported mode > interrupt should return error but not that the function is not > supported. > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index 35d9866..fff314e 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -911,7 +911,8 @@ Bit16u *AX;Bit16u ES;Bit16u DI; > void vbe_biosfn_return_mode_information(AX, CX, ES, DI) > Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > { > - Bit16u result=0x0100; > + // error by default is 0x014f which means supported but error > + Bit16u result=0x014f; Something odd has happened to the whitepace here. Otherwise: Acked-by: Ian Campbell > Bit16u ss=get_SS(); > ModeInfoBlock info; > ModeInfoListItem *cur_info; > @@ -955,7 +956,6 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > #ifdef DEBUG > printf("VBE *NOT* found mode %x\n",CX); > #endif > - result = 0x100; > } > > if (result == 0x4f) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:20:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJMV-0006Th-7e; Fri, 04 May 2012 14:19:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJMT-0006Ta-KA for xen-devel@lists.xen.org; Fri, 04 May 2012 14:19:57 +0000 Received: from [85.158.138.51:35238] by server-12.bemta-3.messagelabs.com id 4B/32-29760-C85E3AF4; Fri, 04 May 2012 14:19:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336141195!17356467!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2440 invoked from network); 4 May 2012 14:19:56 -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; 4 May 2012 14:19:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300481" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:19: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; Fri, 4 May 2012 15:19:47 +0100 Message-ID: <1336141185.2361.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:19:45 +0100 In-Reply-To: <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Apparently Windows 8 refuse to use any mode if has more than one page. What about OSes other than Windows 8? Did you test with any of them? > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index a7b06b9..9131721 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > (size_64k > totalMemory)) > info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; > > - if (using_lfb) { > - info.NumberOfBanks = 1; > - } > + /* Windows 8 require this to be 1! */ > + info.NumberOfBanks = 1; > + > if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { > info.WinFuncPtr = 0xC0000000UL; > *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:20:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJMV-0006Th-7e; Fri, 04 May 2012 14:19:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJMT-0006Ta-KA for xen-devel@lists.xen.org; Fri, 04 May 2012 14:19:57 +0000 Received: from [85.158.138.51:35238] by server-12.bemta-3.messagelabs.com id 4B/32-29760-C85E3AF4; Fri, 04 May 2012 14:19:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336141195!17356467!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2440 invoked from network); 4 May 2012 14:19:56 -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; 4 May 2012 14:19:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300481" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:19: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; Fri, 4 May 2012 15:19:47 +0100 Message-ID: <1336141185.2361.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:19:45 +0100 In-Reply-To: <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-8-git-send-email-frediano.ziglio@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 7/7] vgabios: Make Windows 8 support greater resolutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > Apparently Windows 8 refuse to use any mode if has more than one page. What about OSes other than Windows 8? Did you test with any of them? > > Signed-off-by: Frediano Ziglio > --- > tools/firmware/vgabios/vbe.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/firmware/vgabios/vbe.c b/tools/firmware/vgabios/vbe.c > index a7b06b9..9131721 100644 > --- a/tools/firmware/vgabios/vbe.c > +++ b/tools/firmware/vgabios/vbe.c > @@ -946,9 +946,9 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI; > (size_64k > totalMemory)) > info.ModeAttributes &= ~VBE_MODE_ATTRIBUTE_SUPPORTED; > > - if (using_lfb) { > - info.NumberOfBanks = 1; > - } > + /* Windows 8 require this to be 1! */ > + info.NumberOfBanks = 1; > + > if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) { > info.WinFuncPtr = 0xC0000000UL; > *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:27:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:27:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJTF-0006n9-7q; Fri, 04 May 2012 14:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJTD-0006n0-EX for xen-devel@lists.xen.org; Fri, 04 May 2012 14:26:55 +0000 Received: from [85.158.139.83:27843] by server-10.bemta-5.messagelabs.com id 47/71-08260-B27E3AF4; Fri, 04 May 2012 14:26:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336141610!26828479!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11392 invoked from network); 4 May 2012 14:26:51 -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; 4 May 2012 14:26:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300658" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14: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; Fri, 4 May 2012 15:26:50 +0100 Message-ID: <1336141609.7535.2.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:26:49 +0100 In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > Remove an overflow computing width x height x bit which does > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > and get the size required for framebuffer in segment unit (64k). > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > I'd like :( > > BCC compiler used need some function which are not linked by BIOS. In which case Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:27:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:27:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJTF-0006n9-7q; Fri, 04 May 2012 14:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJTD-0006n0-EX for xen-devel@lists.xen.org; Fri, 04 May 2012 14:26:55 +0000 Received: from [85.158.139.83:27843] by server-10.bemta-5.messagelabs.com id 47/71-08260-B27E3AF4; Fri, 04 May 2012 14:26:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336141610!26828479!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11392 invoked from network); 4 May 2012 14:26:51 -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; 4 May 2012 14:26:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300658" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14: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; Fri, 4 May 2012 15:26:50 +0100 Message-ID: <1336141609.7535.2.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Frediano Ziglio Date: Fri, 4 May 2012 15:26:49 +0100 In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > Remove an overflow computing width x height x bit which does > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > and get the size required for framebuffer in segment unit (64k). > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > I'd like :( > > BCC compiler used need some function which are not linked by BIOS. In which case Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:40:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJg9-0007IY-7I; Fri, 04 May 2012 14:40:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJg8-0007IT-8w for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:40:16 +0000 Received: from [85.158.138.51:53361] by server-10.bemta-3.messagelabs.com id D4/ED-29478-F4AE3AF4; Fri, 04 May 2012 14:40:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336142414!25294768!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3701 invoked from network); 4 May 2012 14:40:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:40:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300963" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:40: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, 4 May 2012 15:40:13 +0100 Message-ID: <1336142412.7535.8.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:40:12 +0100 In-Reply-To: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce a new libxl_device_disk** parameter to > libxl__device_disk_local_attach, the parameter is allocated on the gc by > libxl__device_disk_local_attach. It is going to fill it with > informations about the new locally attached disk. The new > libxl_device_disk should be passed to libxl_device_disk_local_detach > afterwards. > > Changes in v5: > - rename disk to in_disk; > - rename tmpdisk to disk; > - copy disk to new_disk only on success; > - remove check on libxl__zalloc success. > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_bootloader.c | 10 +++++----- > tools/libxl/libxl_internal.c | 20 ++++++++++++++------ > tools/libxl/libxl_internal.h | 3 ++- > 3 files changed, 21 insertions(+), 12 deletions(-) > > diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c > index 977c6d3..83cac78 100644 > --- a/tools/libxl/libxl_bootloader.c > +++ b/tools/libxl/libxl_bootloader.c > @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > char *fifo = NULL; > char *diskpath = NULL; > char **args = NULL; > + libxl_device_disk *tmpdisk = NULL; Do you need to keep tmpdisk valid outside the scope of this function? You don't seem to in this patch (I didn't look over the next patches yet). If not then you could just use "libxl_device_disk tmpdisk" and have libxl__device_disk_local_attach update in place instead allocating and passing the pointer back. > char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; > char *tempdir; > @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > - diskpath = libxl__device_disk_local_attach(gc, disk); > + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); > if (!diskpath) { > + rc = ERROR_FAIL; > goto out_close; > } > > @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, > > rc = 0; > out_close: > - if (diskpath) { > - libxl__device_disk_local_detach(gc, disk); > - free(diskpath); > - } > + if (tmpdisk) > + libxl__device_disk_local_detach(gc, tmpdisk); > if (fifo_fd > -1) > close(fifo_fd); > if (bootloader_fd > -1) > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index fc771ff..55dc55c 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -323,12 +323,21 @@ out: > return rc; > } > > -char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > +char * libxl__device_disk_local_attach(libxl__gc *gc, > + const libxl_device_disk *in_disk, > + libxl_device_disk **new_disk) > { > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > - char *ret = NULL; > int rc; > + libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > + > + memcpy(disk, in_disk, sizeof(libxl_device_disk)); > + if (in_disk->pdev_path != NULL) > + disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path); > + if (in_disk->script != NULL) > + disk->script = libxl__strdup(gc, in_disk->script); > + disk->vdev = NULL; > > rc = libxl__device_disk_setdefault(gc, disk); > if (rc) goto out; > @@ -368,7 +377,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > break; > } > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - disk->pdev_path); > + in_disk->pdev_path); > dev = disk->pdev_path; > break; > default: > @@ -378,9 +387,8 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > } > > out: > - if (dev != NULL) > - ret = strdup(dev); > - return ret; > + *new_disk = disk; > + return dev; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index ddd6a37..965d13b 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1008,7 +1008,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); > * a device. > */ > _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, > - libxl_device_disk *disk); > + const libxl_device_disk *in_disk, > + libxl_device_disk **new_disk); > _hidden int libxl__device_disk_local_detach(libxl__gc *gc, > libxl_device_disk *disk); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:40:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJg9-0007IY-7I; Fri, 04 May 2012 14:40:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJg8-0007IT-8w for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:40:16 +0000 Received: from [85.158.138.51:53361] by server-10.bemta-3.messagelabs.com id D4/ED-29478-F4AE3AF4; Fri, 04 May 2012 14:40:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336142414!25294768!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3701 invoked from network); 4 May 2012 14:40:14 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:40:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300963" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:40: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, 4 May 2012 15:40:13 +0100 Message-ID: <1336142412.7535.8.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:40:12 +0100 In-Reply-To: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce a new libxl_device_disk** parameter to > libxl__device_disk_local_attach, the parameter is allocated on the gc by > libxl__device_disk_local_attach. It is going to fill it with > informations about the new locally attached disk. The new > libxl_device_disk should be passed to libxl_device_disk_local_detach > afterwards. > > Changes in v5: > - rename disk to in_disk; > - rename tmpdisk to disk; > - copy disk to new_disk only on success; > - remove check on libxl__zalloc success. > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_bootloader.c | 10 +++++----- > tools/libxl/libxl_internal.c | 20 ++++++++++++++------ > tools/libxl/libxl_internal.h | 3 ++- > 3 files changed, 21 insertions(+), 12 deletions(-) > > diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c > index 977c6d3..83cac78 100644 > --- a/tools/libxl/libxl_bootloader.c > +++ b/tools/libxl/libxl_bootloader.c > @@ -330,6 +330,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > char *fifo = NULL; > char *diskpath = NULL; > char **args = NULL; > + libxl_device_disk *tmpdisk = NULL; Do you need to keep tmpdisk valid outside the scope of this function? You don't seem to in this patch (I didn't look over the next patches yet). If not then you could just use "libxl_device_disk tmpdisk" and have libxl__device_disk_local_attach update in place instead allocating and passing the pointer back. > char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; > char *tempdir; > @@ -386,8 +387,9 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > - diskpath = libxl__device_disk_local_attach(gc, disk); > + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); > if (!diskpath) { > + rc = ERROR_FAIL; > goto out_close; > } > > @@ -452,10 +454,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, > > rc = 0; > out_close: > - if (diskpath) { > - libxl__device_disk_local_detach(gc, disk); > - free(diskpath); > - } > + if (tmpdisk) > + libxl__device_disk_local_detach(gc, tmpdisk); > if (fifo_fd > -1) > close(fifo_fd); > if (bootloader_fd > -1) > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index fc771ff..55dc55c 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -323,12 +323,21 @@ out: > return rc; > } > > -char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > +char * libxl__device_disk_local_attach(libxl__gc *gc, > + const libxl_device_disk *in_disk, > + libxl_device_disk **new_disk) > { > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > - char *ret = NULL; > int rc; > + libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > + > + memcpy(disk, in_disk, sizeof(libxl_device_disk)); > + if (in_disk->pdev_path != NULL) > + disk->pdev_path = libxl__strdup(gc, in_disk->pdev_path); > + if (in_disk->script != NULL) > + disk->script = libxl__strdup(gc, in_disk->script); > + disk->vdev = NULL; > > rc = libxl__device_disk_setdefault(gc, disk); > if (rc) goto out; > @@ -368,7 +377,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > break; > } > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - disk->pdev_path); > + in_disk->pdev_path); > dev = disk->pdev_path; > break; > default: > @@ -378,9 +387,8 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, libxl_device_disk *disk) > } > > out: > - if (dev != NULL) > - ret = strdup(dev); > - return ret; > + *new_disk = disk; > + return dev; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index ddd6a37..965d13b 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1008,7 +1008,8 @@ _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); > * a device. > */ > _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, > - libxl_device_disk *disk); > + const libxl_device_disk *in_disk, > + libxl_device_disk **new_disk); > _hidden int libxl__device_disk_local_detach(libxl__gc *gc, > libxl_device_disk *disk); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:42:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:42:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJhb-0007Nf-N7; Fri, 04 May 2012 14:41:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJha-0007NT-5J for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:41:46 +0000 Received: from [193.109.254.147:22971] by server-2.bemta-14.messagelabs.com id 14/E5-19409-9AAE3AF4; Fri, 04 May 2012 14:41:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336142504!2511263!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7989 invoked from network); 4 May 2012 14:41:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:41:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:41: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, 4 May 2012 15:41:44 +0100 Message-ID: <1336142502.7535.9.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:41:42 +0100 In-Reply-To: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 3/8] libxl: add a transaction parameter to libxl__device_generic_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Add a xs_transaction_t parameter to libxl__device_generic_add, if it is > XBT_NULL, allocate a proper one. > > Update all the callers. > > This patch contains a large number of unchecked xenstore operations, we > might want to fix this in the future. > > Changes in v4: > - libxl__device_generic_add: do not end the transaction is the caller > provided it; > - libxl__device_generic_add: fix success exit path. > > Signed-off-by: Stefano Stabellini > Acked-by: Ian Jackson Acked-by: Ian Campbell > --- > tools/libxl/libxl.c | 10 +++++----- > tools/libxl/libxl_device.c | 17 +++++++++++------ > tools/libxl/libxl_internal.h | 4 ++-- > tools/libxl/libxl_pci.c | 2 +- > 4 files changed, 19 insertions(+), 14 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 1357efc..525f0d6 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis > flexarray_append(front, "device-type"); > flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > > @@ -1802,7 +1802,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) > flexarray_append(front, "mac"); > flexarray_append(front, libxl__sprintf(gc, > LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > > @@ -2080,7 +2080,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, > flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL); > } > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > @@ -2151,7 +2151,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) > flexarray_append(front, "state"); > flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > @@ -2284,7 +2284,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) > libxl__sprintf(gc, "%d", vfb->backend_domid)); > flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c > index c7e057d..88cdc7d 100644 > --- a/tools/libxl/libxl_device.c > +++ b/tools/libxl/libxl_device.c > @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc, > return libxl__device_kind_from_string(strkind, &dev->backend_kind); > } > > -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > - char **bents, char **fents) > +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, > + libxl__device *device, char **bents, char **fents) > { > libxl_ctx *ctx = libxl__gc_owner(gc); > char *frontend_path, *backend_path; > - xs_transaction_t t; > struct xs_permissions frontend_perms[2]; > struct xs_permissions backend_perms[2]; > + int create_transaction = t == XBT_NULL; > > frontend_path = libxl__device_frontend_path(gc, device); > backend_path = libxl__device_backend_path(gc, device); > @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > backend_perms[1].perms = XS_PERM_READ; > > retry_transaction: > - t = xs_transaction_start(ctx->xsh); > + if (create_transaction) > + t = xs_transaction_start(ctx->xsh); > /* FIXME: read frontend_path and check state before removing stuff */ > > if (fents) { > @@ -100,13 +101,17 @@ retry_transaction: > libxl__xs_writev(gc, t, backend_path, bents); > } > > + if (!create_transaction) > + return 0; > + > if (!xs_transaction_end(ctx->xsh, t, 0)) { > if (errno == EAGAIN) > goto retry_transaction; > - else > + else { > LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed"); > + return ERROR_FAIL; > + } > } > - > return 0; > } > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 965d13b..2c8f06a 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -683,8 +683,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid, > libxl__device_console *console, > libxl__domain_build_state *state); > > -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > - char **bents, char **fents); > +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, > + libxl__device *device, char **bents, char **fents); > _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); > _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); > _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 3856bd9..335c645 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, > flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0)); > flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:42:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:42:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJhb-0007Nf-N7; Fri, 04 May 2012 14:41:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJha-0007NT-5J for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:41:46 +0000 Received: from [193.109.254.147:22971] by server-2.bemta-14.messagelabs.com id 14/E5-19409-9AAE3AF4; Fri, 04 May 2012 14:41:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336142504!2511263!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7989 invoked from network); 4 May 2012 14:41:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:41:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12300997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:41: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, 4 May 2012 15:41:44 +0100 Message-ID: <1336142502.7535.9.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:41:42 +0100 In-Reply-To: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-3-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 3/8] libxl: add a transaction parameter to libxl__device_generic_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Add a xs_transaction_t parameter to libxl__device_generic_add, if it is > XBT_NULL, allocate a proper one. > > Update all the callers. > > This patch contains a large number of unchecked xenstore operations, we > might want to fix this in the future. > > Changes in v4: > - libxl__device_generic_add: do not end the transaction is the caller > provided it; > - libxl__device_generic_add: fix success exit path. > > Signed-off-by: Stefano Stabellini > Acked-by: Ian Jackson Acked-by: Ian Campbell > --- > tools/libxl/libxl.c | 10 +++++----- > tools/libxl/libxl_device.c | 17 +++++++++++------ > tools/libxl/libxl_internal.h | 4 ++-- > tools/libxl/libxl_pci.c | 2 +- > 4 files changed, 19 insertions(+), 14 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 1357efc..525f0d6 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -1401,7 +1401,7 @@ int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *dis > flexarray_append(front, "device-type"); > flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > > @@ -1802,7 +1802,7 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) > flexarray_append(front, "mac"); > flexarray_append(front, libxl__sprintf(gc, > LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > > @@ -2080,7 +2080,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, > flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL); > } > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > @@ -2151,7 +2151,7 @@ int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) > flexarray_append(front, "state"); > flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > @@ -2284,7 +2284,7 @@ int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) > libxl__sprintf(gc, "%d", vfb->backend_domid)); > flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > rc = 0; > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c > index c7e057d..88cdc7d 100644 > --- a/tools/libxl/libxl_device.c > +++ b/tools/libxl/libxl_device.c > @@ -58,14 +58,14 @@ int libxl__parse_backend_path(libxl__gc *gc, > return libxl__device_kind_from_string(strkind, &dev->backend_kind); > } > > -int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > - char **bents, char **fents) > +int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, > + libxl__device *device, char **bents, char **fents) > { > libxl_ctx *ctx = libxl__gc_owner(gc); > char *frontend_path, *backend_path; > - xs_transaction_t t; > struct xs_permissions frontend_perms[2]; > struct xs_permissions backend_perms[2]; > + int create_transaction = t == XBT_NULL; > > frontend_path = libxl__device_frontend_path(gc, device); > backend_path = libxl__device_backend_path(gc, device); > @@ -81,7 +81,8 @@ int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > backend_perms[1].perms = XS_PERM_READ; > > retry_transaction: > - t = xs_transaction_start(ctx->xsh); > + if (create_transaction) > + t = xs_transaction_start(ctx->xsh); > /* FIXME: read frontend_path and check state before removing stuff */ > > if (fents) { > @@ -100,13 +101,17 @@ retry_transaction: > libxl__xs_writev(gc, t, backend_path, bents); > } > > + if (!create_transaction) > + return 0; > + > if (!xs_transaction_end(ctx->xsh, t, 0)) { > if (errno == EAGAIN) > goto retry_transaction; > - else > + else { > LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs transaction failed"); > + return ERROR_FAIL; > + } > } > - > return 0; > } > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 965d13b..2c8f06a 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -683,8 +683,8 @@ _hidden int libxl__device_console_add(libxl__gc *gc, uint32_t domid, > libxl__device_console *console, > libxl__domain_build_state *state); > > -_hidden int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, > - char **bents, char **fents); > +_hidden int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t, > + libxl__device *device, char **bents, char **fents); > _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device); > _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device); > _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path, > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 3856bd9..335c645 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -102,7 +102,7 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, > flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", 0)); > flexarray_append_pair(front, "state", libxl__sprintf(gc, "%d", 1)); > > - libxl__device_generic_add(gc, &device, > + libxl__device_generic_add(gc, XBT_NULL, &device, > libxl__xs_kvs_of_flexarray(gc, back, back->count), > libxl__xs_kvs_of_flexarray(gc, front, front->count)); > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:45:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJlJ-0007dV-Bn; Fri, 04 May 2012 14:45:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJlH-0007dM-56 for xen-devel@lists.xen.org; Fri, 04 May 2012 14:45:35 +0000 Received: from [85.158.139.83:60483] by server-6.bemta-5.messagelabs.com id 75/45-13222-E8BE3AF4; Fri, 04 May 2012 14:45:34 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336142733!26252972!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17458 invoked from network); 4 May 2012 14:45:33 -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; 4 May 2012 14:45:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301079" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:45:32 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:45:32 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:45:32 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBI7mg6ABydPFQH67Dznwebwlnw== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDC@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:45:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJlJ-0007dV-Bn; Fri, 04 May 2012 14:45:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJlH-0007dM-56 for xen-devel@lists.xen.org; Fri, 04 May 2012 14:45:35 +0000 Received: from [85.158.139.83:60483] by server-6.bemta-5.messagelabs.com id 75/45-13222-E8BE3AF4; Fri, 04 May 2012 14:45:34 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336142733!26252972!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17458 invoked from network); 4 May 2012 14:45:33 -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; 4 May 2012 14:45:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301079" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:45:32 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:45:32 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:45:32 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBI7mg6ABydPFQH67Dznwebwlnw== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDC@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:47:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:47:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJnA-0007m6-5A; Fri, 04 May 2012 14:47:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJn9-0007lq-8I for xen-devel@lists.xen.org; Fri, 04 May 2012 14:47:31 +0000 Received: from [85.158.143.99:47853] by server-3.bemta-4.messagelabs.com id 66/1F-05853-20CE3AF4; Fri, 04 May 2012 14:47:30 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336142849!21205897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6937 invoked from network); 4 May 2012 14:47:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:47:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301212" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:47:28 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 4 May 2012 15:47:28 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:47:28 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBNPvXHAvTm0PQliwtECjRDtUPg== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDD@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:47:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:47:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJnA-0007m6-5A; Fri, 04 May 2012 14:47:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJn9-0007lq-8I for xen-devel@lists.xen.org; Fri, 04 May 2012 14:47:31 +0000 Received: from [85.158.143.99:47853] by server-3.bemta-4.messagelabs.com id 66/1F-05853-20CE3AF4; Fri, 04 May 2012 14:47:30 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336142849!21205897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6937 invoked from network); 4 May 2012 14:47:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 14:47:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301212" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:47:28 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 4 May 2012 15:47:28 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:47:28 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBNPvXHAvTm0PQliwtECjRDtUPg== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDD@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoE-0007sV-Oa; Fri, 04 May 2012 14:48:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoC-0007s9-Qy for xen-devel@lists.xen.org; Fri, 04 May 2012 14:48:36 +0000 Received: from [85.158.143.99:4417] by server-2.bemta-4.messagelabs.com id 4B/61-17550-44CE3AF4; Fri, 04 May 2012 14:48:36 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336142914!26192117!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23053 invoked from network); 4 May 2012 14:48:34 -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 May 2012 14:48:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301242" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:48:33 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:48:33 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:48:33 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBPqaZY1fwDu2SvaJ8NkVRAPkPw== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDE@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoE-0007sV-Oa; Fri, 04 May 2012 14:48:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoC-0007s9-Qy for xen-devel@lists.xen.org; Fri, 04 May 2012 14:48:36 +0000 Received: from [85.158.143.99:4417] by server-2.bemta-4.messagelabs.com id 4B/61-17550-44CE3AF4; Fri, 04 May 2012 14:48:36 +0000 X-Env-Sender: frediano.ziglio@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336142914!26192117!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23053 invoked from network); 4 May 2012 14:48:34 -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 May 2012 14:48:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301242" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:48:33 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 4 May 2012 15:48:33 +0100 From: Frediano Ziglio To: Ian Campbell Date: Fri, 4 May 2012 15:48:33 +0100 Thread-Topic: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow Thread-Index: Ac0qBPqaZY1fwDu2SvaJ8NkVRAPkPw== Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDE@LONPMAILBOX01.citrite.net> References: <1336135010-26940-1-git-send-email-frediano.ziglio@citrix.com> <1336135010-26940-4-git-send-email-frediano.ziglio@citrix.com> <1336140734.2361.72.camel@zakaz.uk.xensource.com> <7CE799CC0E4DE04B88D5FDF226E18AC2CDE9E24CDB@LONPMAILBOX01.citrite.net> <1336141609.7535.2.camel@zakaz.uk.xensource.com> In-Reply-To: <1336141609.7535.2.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.xen.org" Subject: Re: [Xen-devel] [PATCH 3/7] vgabios: Fix size computation overflow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 15:26 +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 15:18 +0100, Frediano Ziglio wrote: > > On Fri, 2012-05-04 at 15:12 +0100, Ian Campbell wrote: > > > On Fri, 2012-05-04 at 13:36 +0100, Frediano Ziglio wrote: > > > > Remove an overflow computing width x height x bit which does > > > > not fit into a 16 bits. I wrote a routine to multiple these value > > > > and get the size required for framebuffer in segment unit (64k). > > > > > > Couldn't this be done in C using a suitably wide temporary variable? > > > > > > > I'd like :( > > > > BCC compiler used need some function which are not linked by BIOS. > > In which case > > Acked-by: Ian Campbell > > In current vgabios (from Bochs not Xen copy) size is computed using size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; If you try to use this code you get an undefined call to lmulul. Bochs code (still in vbe.c) provide this internal function with this asm code: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret Note also that Bochs line have some problems - it multiply Xres by Xres intead of Xres by Yref - it does not take into account ceiling division Frediano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:49:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJp0-0007z8-6Z; Fri, 04 May 2012 14:49:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoy-0007yl-3a for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:49:24 +0000 Received: from [85.158.138.51:20715] by server-11.bemta-3.messagelabs.com id A7/DF-18894-37CE3AF4; Fri, 04 May 2012 14:49:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336142952!25322950!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1508 invoked from network); 4 May 2012 14:49:13 -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; 4 May 2012 14:49:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301259" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:49: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, 4 May 2012 15:49:12 +0100 Message-ID: <1336142951.7535.11.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:49:11 +0100 In-Reply-To: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 4/8] libxl: introduce libxl__device_disk_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce libxl__device_disk_add that takes an additional > xs_transaction_t paramter. > Implement libxl_device_disk_add using libxl__device_disk_add. > Move libxl__device_from_disk to libxl_internal.c. > No functional change. > > Changes in v5: > - rename libxl__device_generic_add_t to libxl__device_generic_add. > > Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell > --- > tools/libxl/libxl.c | 151 +---------------------------------------- > tools/libxl/libxl_internal.c | 157 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxl/libxl_internal.h | 6 ++ > 3 files changed, 164 insertions(+), 150 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 525f0d6..941dbb9 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) > return rc; > } > > -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > - libxl_device_disk *disk, > - libxl__device *device) > -{ > - libxl_ctx *ctx = libxl__gc_owner(gc); > - int devid; > - > - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); > - if (devid==-1) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > - " virtual disk identifier %s", disk->vdev); > - return ERROR_INVAL; > - } > - > - device->backend_domid = disk->backend_domid; > - device->backend_devid = devid; > - > - switch (disk->backend) { > - case LIBXL_DISK_BACKEND_PHY: > - device->backend_kind = LIBXL__DEVICE_KIND_VBD; > - break; > - case LIBXL_DISK_BACKEND_TAP: > - device->backend_kind = LIBXL__DEVICE_KIND_VBD; > - break; > - case LIBXL_DISK_BACKEND_QDISK: > - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; > - break; > - default: > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", > - disk->backend); > - return ERROR_INVAL; > - } > - > - device->domid = domid; > - device->devid = devid; > - device->kind = LIBXL__DEVICE_KIND_VBD; > - > - return 0; > -} > - > int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) > { > GC_INIT(ctx); > - flexarray_t *front; > - flexarray_t *back; > - char *dev; > - libxl__device device; > - int major, minor, rc; > - > - rc = libxl__device_disk_setdefault(gc, disk); > - if (rc) goto out; > - > - front = flexarray_make(16, 1); > - if (!front) { > - rc = ERROR_NOMEM; > - goto out; > - } > - back = flexarray_make(16, 1); > - if (!back) { > - rc = ERROR_NOMEM; > - goto out_free; > - } > - > - if (disk->script) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" > - " not yet supported, sorry"); > - rc = ERROR_INVAL; > - goto out_free; > - } > - > - rc = libxl__device_from_disk(gc, domid, disk, &device); > - if (rc != 0) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > - " virtual disk identifier %s", disk->vdev); > - goto out_free; > - } > - > - switch (disk->backend) { > - case LIBXL_DISK_BACKEND_PHY: > - dev = disk->pdev_path; > - do_backend_phy: > - libxl__device_physdisk_major_minor(dev, &major, &minor); > - flexarray_append(back, "physical-device"); > - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); > - > - flexarray_append(back, "params"); > - flexarray_append(back, dev); > - > - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); > - break; > - case LIBXL_DISK_BACKEND_TAP: > - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); > - if (!dev) { > - rc = ERROR_FAIL; > - goto out_free; > - } > - flexarray_append(back, "tapdisk-params"); > - flexarray_append(back, libxl__sprintf(gc, "%s:%s", > - libxl__device_disk_string_of_format(disk->format), > - disk->pdev_path)); > - > - /* now create a phy device to export the device to the guest */ > - goto do_backend_phy; > - case LIBXL_DISK_BACKEND_QDISK: > - flexarray_append(back, "params"); > - flexarray_append(back, libxl__sprintf(gc, "%s:%s", > - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); > - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); > - break; > - default: > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); > - rc = ERROR_INVAL; > - goto out_free; > - } > - > - flexarray_append(back, "frontend-id"); > - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); > - flexarray_append(back, "online"); > - flexarray_append(back, "1"); > - flexarray_append(back, "removable"); > - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); > - flexarray_append(back, "bootable"); > - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(back, "state"); > - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(back, "dev"); > - flexarray_append(back, disk->vdev); > - flexarray_append(back, "type"); > - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); > - flexarray_append(back, "mode"); > - flexarray_append(back, disk->readwrite ? "w" : "r"); > - flexarray_append(back, "device-type"); > - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); > - > - flexarray_append(front, "backend-id"); > - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); > - flexarray_append(front, "state"); > - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(front, "virtual-device"); > - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); > - flexarray_append(front, "device-type"); > - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > - > - libxl__device_generic_add(gc, XBT_NULL, &device, > - libxl__xs_kvs_of_flexarray(gc, back, back->count), > - libxl__xs_kvs_of_flexarray(gc, front, front->count)); > - > - rc = 0; > - > -out_free: > - flexarray_free(back); > - flexarray_free(front); > -out: > + int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk); > GC_FREE; > return rc; > } > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 55dc55c..1bf5d73 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -323,6 +323,163 @@ out: > return rc; > } > > +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > + libxl_device_disk *disk, > + libxl__device *device) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int devid; > + > + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); > + if (devid==-1) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > + " virtual disk identifier %s", disk->vdev); > + return ERROR_INVAL; > + } > + > + device->backend_domid = disk->backend_domid; > + device->backend_devid = devid; > + > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_PHY: > + device->backend_kind = LIBXL__DEVICE_KIND_VBD; > + break; > + case LIBXL_DISK_BACKEND_TAP: > + device->backend_kind = LIBXL__DEVICE_KIND_VBD; > + break; > + case LIBXL_DISK_BACKEND_QDISK: > + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; > + break; > + default: > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", > + disk->backend); > + return ERROR_INVAL; > + } > + > + device->domid = domid; > + device->devid = devid; > + device->kind = LIBXL__DEVICE_KIND_VBD; > + > + return 0; > +} > + > +int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > + xs_transaction_t t, libxl_device_disk *disk) > +{ > + flexarray_t *front; > + flexarray_t *back; > + char *dev; > + libxl__device device; > + int major, minor, rc; > + libxl_ctx *ctx = gc->owner; > + > + rc = libxl__device_disk_setdefault(gc, disk); > + if (rc) goto out; > + > + front = flexarray_make(16, 1); > + if (!front) { > + rc = ERROR_NOMEM; > + goto out; > + } > + back = flexarray_make(16, 1); > + if (!back) { > + rc = ERROR_NOMEM; > + goto out_free; > + } > + > + if (disk->script) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" > + " not yet supported, sorry"); > + rc = ERROR_INVAL; > + goto out_free; > + } > + > + rc = libxl__device_from_disk(gc, domid, disk, &device); > + if (rc != 0) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > + " virtual disk identifier %s", disk->vdev); > + goto out_free; > + } > + > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_PHY: > + dev = disk->pdev_path; > + do_backend_phy: > + libxl__device_physdisk_major_minor(dev, &major, &minor); > + flexarray_append(back, "physical-device"); > + flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); > + > + flexarray_append(back, "params"); > + flexarray_append(back, dev); > + > + assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); > + break; > + case LIBXL_DISK_BACKEND_TAP: > + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); > + if (!dev) { > + rc = ERROR_FAIL; > + goto out_free; > + } > + flexarray_append(back, "tapdisk-params"); > + flexarray_append(back, libxl__sprintf(gc, "%s:%s", > + libxl__device_disk_string_of_format(disk->format), > + disk->pdev_path)); > + > + /* now create a phy device to export the device to the guest */ > + goto do_backend_phy; > + case LIBXL_DISK_BACKEND_QDISK: > + flexarray_append(back, "params"); > + flexarray_append(back, libxl__sprintf(gc, "%s:%s", > + libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); > + assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); > + break; > + default: > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); > + rc = ERROR_INVAL; > + goto out_free; > + } > + > + flexarray_append(back, "frontend-id"); > + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); > + flexarray_append(back, "online"); > + flexarray_append(back, "1"); > + flexarray_append(back, "removable"); > + flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); > + flexarray_append(back, "bootable"); > + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(back, "state"); > + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(back, "dev"); > + flexarray_append(back, disk->vdev); > + flexarray_append(back, "type"); > + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); > + flexarray_append(back, "mode"); > + flexarray_append(back, disk->readwrite ? "w" : "r"); > + flexarray_append(back, "device-type"); > + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); > + > + flexarray_append(front, "backend-id"); > + flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); > + flexarray_append(front, "state"); > + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(front, "virtual-device"); > + flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); > + flexarray_append(front, "device-type"); > + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > + > + libxl__device_generic_add(gc, t, &device, > + libxl__xs_kvs_of_flexarray(gc, back, back->count), > + libxl__xs_kvs_of_flexarray(gc, front, front->count)); > + > + rc = 0; > + > +out_free: > + flexarray_free(back); > + flexarray_free(front); > +out: > + return rc; > +} > + > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > libxl_device_disk **new_disk) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 2c8f06a..096c96d 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1003,6 +1003,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, > */ > _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); > > + > +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > + libxl_device_disk *disk, > + libxl__device *device); > +_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > + xs_transaction_t t, libxl_device_disk *disk); > /* > * Make a disk available in this (the control) domain. Returns path to > * a device. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:49:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJp0-0007z8-6Z; Fri, 04 May 2012 14:49:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJoy-0007yl-3a for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:49:24 +0000 Received: from [85.158.138.51:20715] by server-11.bemta-3.messagelabs.com id A7/DF-18894-37CE3AF4; Fri, 04 May 2012 14:49:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336142952!25322950!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1508 invoked from network); 4 May 2012 14:49:13 -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; 4 May 2012 14:49:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301259" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:49: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, 4 May 2012 15:49:12 +0100 Message-ID: <1336142951.7535.11.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:49:11 +0100 In-Reply-To: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 4/8] libxl: introduce libxl__device_disk_add X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce libxl__device_disk_add that takes an additional > xs_transaction_t paramter. > Implement libxl_device_disk_add using libxl__device_disk_add. > Move libxl__device_from_disk to libxl_internal.c. > No functional change. > > Changes in v5: > - rename libxl__device_generic_add_t to libxl__device_generic_add. > > Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell > --- > tools/libxl/libxl.c | 151 +---------------------------------------- > tools/libxl/libxl_internal.c | 157 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxl/libxl_internal.h | 6 ++ > 3 files changed, 164 insertions(+), 150 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 525f0d6..941dbb9 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -1258,159 +1258,10 @@ int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) > return rc; > } > > -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > - libxl_device_disk *disk, > - libxl__device *device) > -{ > - libxl_ctx *ctx = libxl__gc_owner(gc); > - int devid; > - > - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); > - if (devid==-1) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > - " virtual disk identifier %s", disk->vdev); > - return ERROR_INVAL; > - } > - > - device->backend_domid = disk->backend_domid; > - device->backend_devid = devid; > - > - switch (disk->backend) { > - case LIBXL_DISK_BACKEND_PHY: > - device->backend_kind = LIBXL__DEVICE_KIND_VBD; > - break; > - case LIBXL_DISK_BACKEND_TAP: > - device->backend_kind = LIBXL__DEVICE_KIND_VBD; > - break; > - case LIBXL_DISK_BACKEND_QDISK: > - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; > - break; > - default: > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", > - disk->backend); > - return ERROR_INVAL; > - } > - > - device->domid = domid; > - device->devid = devid; > - device->kind = LIBXL__DEVICE_KIND_VBD; > - > - return 0; > -} > - > int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) > { > GC_INIT(ctx); > - flexarray_t *front; > - flexarray_t *back; > - char *dev; > - libxl__device device; > - int major, minor, rc; > - > - rc = libxl__device_disk_setdefault(gc, disk); > - if (rc) goto out; > - > - front = flexarray_make(16, 1); > - if (!front) { > - rc = ERROR_NOMEM; > - goto out; > - } > - back = flexarray_make(16, 1); > - if (!back) { > - rc = ERROR_NOMEM; > - goto out_free; > - } > - > - if (disk->script) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" > - " not yet supported, sorry"); > - rc = ERROR_INVAL; > - goto out_free; > - } > - > - rc = libxl__device_from_disk(gc, domid, disk, &device); > - if (rc != 0) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > - " virtual disk identifier %s", disk->vdev); > - goto out_free; > - } > - > - switch (disk->backend) { > - case LIBXL_DISK_BACKEND_PHY: > - dev = disk->pdev_path; > - do_backend_phy: > - libxl__device_physdisk_major_minor(dev, &major, &minor); > - flexarray_append(back, "physical-device"); > - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); > - > - flexarray_append(back, "params"); > - flexarray_append(back, dev); > - > - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); > - break; > - case LIBXL_DISK_BACKEND_TAP: > - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); > - if (!dev) { > - rc = ERROR_FAIL; > - goto out_free; > - } > - flexarray_append(back, "tapdisk-params"); > - flexarray_append(back, libxl__sprintf(gc, "%s:%s", > - libxl__device_disk_string_of_format(disk->format), > - disk->pdev_path)); > - > - /* now create a phy device to export the device to the guest */ > - goto do_backend_phy; > - case LIBXL_DISK_BACKEND_QDISK: > - flexarray_append(back, "params"); > - flexarray_append(back, libxl__sprintf(gc, "%s:%s", > - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); > - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); > - break; > - default: > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); > - rc = ERROR_INVAL; > - goto out_free; > - } > - > - flexarray_append(back, "frontend-id"); > - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); > - flexarray_append(back, "online"); > - flexarray_append(back, "1"); > - flexarray_append(back, "removable"); > - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); > - flexarray_append(back, "bootable"); > - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(back, "state"); > - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(back, "dev"); > - flexarray_append(back, disk->vdev); > - flexarray_append(back, "type"); > - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); > - flexarray_append(back, "mode"); > - flexarray_append(back, disk->readwrite ? "w" : "r"); > - flexarray_append(back, "device-type"); > - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); > - > - flexarray_append(front, "backend-id"); > - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); > - flexarray_append(front, "state"); > - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > - flexarray_append(front, "virtual-device"); > - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); > - flexarray_append(front, "device-type"); > - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > - > - libxl__device_generic_add(gc, XBT_NULL, &device, > - libxl__xs_kvs_of_flexarray(gc, back, back->count), > - libxl__xs_kvs_of_flexarray(gc, front, front->count)); > - > - rc = 0; > - > -out_free: > - flexarray_free(back); > - flexarray_free(front); > -out: > + int rc = libxl__device_disk_add(gc, domid, XBT_NULL, disk); > GC_FREE; > return rc; > } > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 55dc55c..1bf5d73 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -323,6 +323,163 @@ out: > return rc; > } > > +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > + libxl_device_disk *disk, > + libxl__device *device) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int devid; > + > + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); > + if (devid==-1) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > + " virtual disk identifier %s", disk->vdev); > + return ERROR_INVAL; > + } > + > + device->backend_domid = disk->backend_domid; > + device->backend_devid = devid; > + > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_PHY: > + device->backend_kind = LIBXL__DEVICE_KIND_VBD; > + break; > + case LIBXL_DISK_BACKEND_TAP: > + device->backend_kind = LIBXL__DEVICE_KIND_VBD; > + break; > + case LIBXL_DISK_BACKEND_QDISK: > + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; > + break; > + default: > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", > + disk->backend); > + return ERROR_INVAL; > + } > + > + device->domid = domid; > + device->devid = devid; > + device->kind = LIBXL__DEVICE_KIND_VBD; > + > + return 0; > +} > + > +int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > + xs_transaction_t t, libxl_device_disk *disk) > +{ > + flexarray_t *front; > + flexarray_t *back; > + char *dev; > + libxl__device device; > + int major, minor, rc; > + libxl_ctx *ctx = gc->owner; > + > + rc = libxl__device_disk_setdefault(gc, disk); > + if (rc) goto out; > + > + front = flexarray_make(16, 1); > + if (!front) { > + rc = ERROR_NOMEM; > + goto out; > + } > + back = flexarray_make(16, 1); > + if (!back) { > + rc = ERROR_NOMEM; > + goto out_free; > + } > + > + if (disk->script) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" > + " not yet supported, sorry"); > + rc = ERROR_INVAL; > + goto out_free; > + } > + > + rc = libxl__device_from_disk(gc, domid, disk, &device); > + if (rc != 0) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" > + " virtual disk identifier %s", disk->vdev); > + goto out_free; > + } > + > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_PHY: > + dev = disk->pdev_path; > + do_backend_phy: > + libxl__device_physdisk_major_minor(dev, &major, &minor); > + flexarray_append(back, "physical-device"); > + flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); > + > + flexarray_append(back, "params"); > + flexarray_append(back, dev); > + > + assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); > + break; > + case LIBXL_DISK_BACKEND_TAP: > + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); > + if (!dev) { > + rc = ERROR_FAIL; > + goto out_free; > + } > + flexarray_append(back, "tapdisk-params"); > + flexarray_append(back, libxl__sprintf(gc, "%s:%s", > + libxl__device_disk_string_of_format(disk->format), > + disk->pdev_path)); > + > + /* now create a phy device to export the device to the guest */ > + goto do_backend_phy; > + case LIBXL_DISK_BACKEND_QDISK: > + flexarray_append(back, "params"); > + flexarray_append(back, libxl__sprintf(gc, "%s:%s", > + libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); > + assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); > + break; > + default: > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); > + rc = ERROR_INVAL; > + goto out_free; > + } > + > + flexarray_append(back, "frontend-id"); > + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); > + flexarray_append(back, "online"); > + flexarray_append(back, "1"); > + flexarray_append(back, "removable"); > + flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); > + flexarray_append(back, "bootable"); > + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(back, "state"); > + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(back, "dev"); > + flexarray_append(back, disk->vdev); > + flexarray_append(back, "type"); > + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); > + flexarray_append(back, "mode"); > + flexarray_append(back, disk->readwrite ? "w" : "r"); > + flexarray_append(back, "device-type"); > + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); > + > + flexarray_append(front, "backend-id"); > + flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); > + flexarray_append(front, "state"); > + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); > + flexarray_append(front, "virtual-device"); > + flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); > + flexarray_append(front, "device-type"); > + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); > + > + libxl__device_generic_add(gc, t, &device, > + libxl__xs_kvs_of_flexarray(gc, back, back->count), > + libxl__xs_kvs_of_flexarray(gc, front, front->count)); > + > + rc = 0; > + > +out_free: > + flexarray_free(back); > + flexarray_free(front); > +out: > + return rc; > +} > + > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > libxl_device_disk **new_disk) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 2c8f06a..096c96d 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1003,6 +1003,12 @@ _hidden char *libxl__blktap_devpath(libxl__gc *gc, > */ > _hidden void libxl__device_destroy_tapdisk(libxl__gc *gc, char *be_path); > > + > +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, > + libxl_device_disk *disk, > + libxl__device *device); > +_hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > + xs_transaction_t t, libxl_device_disk *disk); > /* > * Make a disk available in this (the control) domain. Returns path to > * a device. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJuW-0008O4-VU; Fri, 04 May 2012 14:55:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJuW-0008Nz-76 for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:55:08 +0000 Received: from [193.109.254.147:40834] by server-12.bemta-14.messagelabs.com id DE/B7-05898-BCDE3AF4; Fri, 04 May 2012 14:55:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336143306!2513827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 4 May 2012 14:55:06 -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; 4 May 2012 14:55:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301411" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14: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; Fri, 4 May 2012 15:54:55 +0100 Message-ID: <1336143294.7535.13.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:54:54 +0100 In-Reply-To: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce a blkdev_start in xl.conf and a corresponding string in > libxl_domain_build_info. > > Add a blkdev_start parameter to libxl__device_disk_local_attach: it is > going to be used in a following patch. > > blkdev_start specifies the first block device to be used for temporary > block device allocations by the toolstack. > > Changes in v5: > - change the type of the blkdev_start parameter to > libxl__device_disk_local_attach to const char *. > > Changes in v4: > - pass blkdev_start in libxl_domain_build_info. > > Signed-off-by: Stefano Stabellini > --- > tools/examples/xl.conf | 3 +++ > tools/libxl/libxl_bootloader.c | 3 ++- > tools/libxl/libxl_create.c | 3 +++ > tools/libxl/libxl_internal.c | 3 ++- > tools/libxl/libxl_internal.h | 3 ++- > tools/libxl/libxl_types.idl | 1 + > tools/libxl/xl.c | 3 +++ > tools/libxl/xl.h | 1 + > tools/libxl/xl_cmdimpl.c | 2 ++ > 9 files changed, 19 insertions(+), 3 deletions(-) > > diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf > index 56d3b3b..ebf057c 100644 > --- a/tools/examples/xl.conf > +++ b/tools/examples/xl.conf > @@ -12,3 +12,6 @@ > > # default output format used by "xl list -l" > #output_format="json" > + > +# first block device to be used for temporary VM disk mounts > +#blkdev_start="xvda" Need a patch to docs/man/xl.conf.pod.5 as well. If you add that then: Acked-by: Ian Campbell I suppose this is necessarily Linux specific and we'll need a patch from the BSD folks? > diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c > index 83cac78..123b06e 100644 > --- a/tools/libxl/libxl_bootloader.c > +++ b/tools/libxl/libxl_bootloader.c > @@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > - diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); > + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk, > + info->blkdev_start); > if (!diskpath) { > rc = ERROR_FAIL; > goto out_close; > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index 7ab2f72..f2fcdf0 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -107,6 +107,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, > } > } > > + if (b_info->blkdev_start == NULL) > + b_info->blkdev_start = strdup("xvda"); > + > if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { > if (!b_info->u.hvm.bios) > switch (b_info->device_model_version) { > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 1bf5d73..bd5ebb3 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -482,7 +482,8 @@ out: > > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > - libxl_device_disk **new_disk) > + libxl_device_disk **new_disk, > + const char *blkdev_start) > { > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 096c96d..0074ec4 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1015,7 +1015,8 @@ _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > */ > _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > - libxl_device_disk **new_disk); > + libxl_device_disk **new_disk, > + const char *blkdev_start); > _hidden int libxl__device_disk_local_detach(libxl__gc *gc, > libxl_device_disk *disk); > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 68599cb..7131696 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -253,6 +253,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > ("localtime", libxl_defbool), > ("disable_migrate", libxl_defbool), > ("cpuid", libxl_cpuid_policy_list), > + ("blkdev_start", string), > > ("device_model_version", libxl_device_model_version), > ("device_model_stubdomain", libxl_defbool), > diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c > index a6ffd25..4596c4f 100644 > --- a/tools/libxl/xl.c > +++ b/tools/libxl/xl.c > @@ -35,6 +35,7 @@ > xentoollog_logger_stdiostream *logger; > int dryrun_only; > int autoballoon = 1; > +char *blkdev_start; > char *lockfile; > char *default_vifscript = NULL; > char *default_bridge = NULL; > @@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile, > fprintf(stderr, "invalid default output format \"%s\"\n", buf); > } > } > + if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0)) > + blkdev_start = strdup(buf); > xlu_cfg_destroy(config); > } > > diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h > index f0d0ec8..3fbe14d 100644 > --- a/tools/libxl/xl.h > +++ b/tools/libxl/xl.h > @@ -112,6 +112,7 @@ extern int dryrun_only; > extern char *lockfile; > extern char *default_vifscript; > extern char *default_bridge; > +extern char *blkdev_start; > > enum output_format { > OUTPUT_FORMAT_JSON, > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c > index 28f5cab..7338562 100644 > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -595,6 +595,8 @@ static void parse_config_data(const char *configfile_filename_report, > } > > libxl_domain_build_info_init_type(b_info, c_info->type); > + if (blkdev_start) > + b_info->blkdev_start = strdup(blkdev_start); > > /* the following is the actual config parsing with overriding values in the structures */ > if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 14:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 14: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 ) id 1SQJuW-0008O4-VU; Fri, 04 May 2012 14:55:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJuW-0008Nz-76 for xen-devel@lists.xensource.com; Fri, 04 May 2012 14:55:08 +0000 Received: from [193.109.254.147:40834] by server-12.bemta-14.messagelabs.com id DE/B7-05898-BCDE3AF4; Fri, 04 May 2012 14:55:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336143306!2513827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 4 May 2012 14:55:06 -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; 4 May 2012 14:55:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301411" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14: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; Fri, 4 May 2012 15:54:55 +0100 Message-ID: <1336143294.7535.13.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:54:54 +0100 In-Reply-To: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce a blkdev_start in xl.conf and a corresponding string in > libxl_domain_build_info. > > Add a blkdev_start parameter to libxl__device_disk_local_attach: it is > going to be used in a following patch. > > blkdev_start specifies the first block device to be used for temporary > block device allocations by the toolstack. > > Changes in v5: > - change the type of the blkdev_start parameter to > libxl__device_disk_local_attach to const char *. > > Changes in v4: > - pass blkdev_start in libxl_domain_build_info. > > Signed-off-by: Stefano Stabellini > --- > tools/examples/xl.conf | 3 +++ > tools/libxl/libxl_bootloader.c | 3 ++- > tools/libxl/libxl_create.c | 3 +++ > tools/libxl/libxl_internal.c | 3 ++- > tools/libxl/libxl_internal.h | 3 ++- > tools/libxl/libxl_types.idl | 1 + > tools/libxl/xl.c | 3 +++ > tools/libxl/xl.h | 1 + > tools/libxl/xl_cmdimpl.c | 2 ++ > 9 files changed, 19 insertions(+), 3 deletions(-) > > diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf > index 56d3b3b..ebf057c 100644 > --- a/tools/examples/xl.conf > +++ b/tools/examples/xl.conf > @@ -12,3 +12,6 @@ > > # default output format used by "xl list -l" > #output_format="json" > + > +# first block device to be used for temporary VM disk mounts > +#blkdev_start="xvda" Need a patch to docs/man/xl.conf.pod.5 as well. If you add that then: Acked-by: Ian Campbell I suppose this is necessarily Linux specific and we'll need a patch from the BSD folks? > diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c > index 83cac78..123b06e 100644 > --- a/tools/libxl/libxl_bootloader.c > +++ b/tools/libxl/libxl_bootloader.c > @@ -387,7 +387,8 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > - diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk); > + diskpath = libxl__device_disk_local_attach(gc, disk, &tmpdisk, > + info->blkdev_start); > if (!diskpath) { > rc = ERROR_FAIL; > goto out_close; > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index 7ab2f72..f2fcdf0 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -107,6 +107,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, > } > } > > + if (b_info->blkdev_start == NULL) > + b_info->blkdev_start = strdup("xvda"); > + > if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) { > if (!b_info->u.hvm.bios) > switch (b_info->device_model_version) { > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 1bf5d73..bd5ebb3 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -482,7 +482,8 @@ out: > > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > - libxl_device_disk **new_disk) > + libxl_device_disk **new_disk, > + const char *blkdev_start) > { > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 096c96d..0074ec4 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1015,7 +1015,8 @@ _hidden int libxl__device_disk_add(libxl__gc *gc, uint32_t domid, > */ > _hidden char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > - libxl_device_disk **new_disk); > + libxl_device_disk **new_disk, > + const char *blkdev_start); > _hidden int libxl__device_disk_local_detach(libxl__gc *gc, > libxl_device_disk *disk); > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 68599cb..7131696 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -253,6 +253,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > ("localtime", libxl_defbool), > ("disable_migrate", libxl_defbool), > ("cpuid", libxl_cpuid_policy_list), > + ("blkdev_start", string), > > ("device_model_version", libxl_device_model_version), > ("device_model_stubdomain", libxl_defbool), > diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c > index a6ffd25..4596c4f 100644 > --- a/tools/libxl/xl.c > +++ b/tools/libxl/xl.c > @@ -35,6 +35,7 @@ > xentoollog_logger_stdiostream *logger; > int dryrun_only; > int autoballoon = 1; > +char *blkdev_start; > char *lockfile; > char *default_vifscript = NULL; > char *default_bridge = NULL; > @@ -91,6 +92,8 @@ static void parse_global_config(const char *configfile, > fprintf(stderr, "invalid default output format \"%s\"\n", buf); > } > } > + if (!xlu_cfg_get_string (config, "blkdev_start", &buf, 0)) > + blkdev_start = strdup(buf); > xlu_cfg_destroy(config); > } > > diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h > index f0d0ec8..3fbe14d 100644 > --- a/tools/libxl/xl.h > +++ b/tools/libxl/xl.h > @@ -112,6 +112,7 @@ extern int dryrun_only; > extern char *lockfile; > extern char *default_vifscript; > extern char *default_bridge; > +extern char *blkdev_start; > > enum output_format { > OUTPUT_FORMAT_JSON, > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c > index 28f5cab..7338562 100644 > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -595,6 +595,8 @@ static void parse_config_data(const char *configfile_filename_report, > } > > libxl_domain_build_info_init_type(b_info, c_info->type); > + if (blkdev_start) > + b_info->blkdev_start = strdup(blkdev_start); > > /* the following is the actual config parsing with overriding values in the structures */ > if (!xlu_cfg_get_long (config, "cpu_weight", &l, 0)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:00:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQJzb-00007w-V0; Fri, 04 May 2012 15:00:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJza-00007q-Am for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:00:22 +0000 Received: from [85.158.139.83:3093] by server-9.bemta-5.messagelabs.com id 0B/FD-09826-50FE3AF4; Fri, 04 May 2012 15:00:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336143620!15531596!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19205 invoked from network); 4 May 2012 15:00:21 -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; 4 May 2012 15:00:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301562" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15: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; Fri, 4 May 2012 16:00:01 +0100 Message-ID: <1336143599.7535.17.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:59:59 +0100 In-Reply-To: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce libxl__alloc_vdev: find a spare virtual block device in the > domain passed as argument. > > Changes in v5: > - remove domid paramter to libxl__alloc_vdev (assume > LIBXL_TOOLSTACK_DOMID); > - remove scaling limit from libxl__alloc_vdev. > > Changes in v4: > - rename libxl__devid_to_vdev to libxl__devid_to_localdev; > - introduce upper bound for encode_disk_name; > - better error handling; > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_internal.c | 31 ++++++++++++++++++++++++++++ > tools/libxl/libxl_internal.h | 4 +++ > tools/libxl/libxl_linux.c | 45 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxl/libxl_netbsd.c | 6 +++++ > 4 files changed, 86 insertions(+), 0 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index bd5ebb3..7a1e017 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -480,6 +480,37 @@ out: > return rc; > } > > +/* libxl__alloc_vdev only works on the local domain, that is the domain > + * where the toolstack is running */ > +static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start, > + xs_transaction_t t) > +{ > + int devid = 0, disk = 0, part = 0; > + char *vdev = NULL; > + char *dompath = libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID); > + > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); If you specify the default blkdev_start in xl as d0 instead of xvda doesn't at least this bit magically become portable to BSD etc too? Or couldn't it actually be an int and save you parsing at all? > + if (part != 0) { > + LOG(ERROR, "blkdev_start is invalid"); > + return NULL; > + } > + > + do { > + vdev = GCSPRINTF("d%dp0", disk); > + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); libxl__device_disk_dev_number does the right thing with "d" (i.e. without the hardcoded "p0"), I think. I'd be tempted to inline the GCSPRINTF in the arg and do away with vdev since you don't use it again. > + if (libxl__xs_read(gc, t, > + libxl__sprintf(gc, "%s/device/vbd/%d/backend", > + dompath, devid)) == NULL) { > + if (errno == ENOENT) > + return libxl__devid_to_localdev(gc, devid); > + else > + return NULL; > + } > + disk++; > + } while (disk <= (1 << 20)); That's a whole lotta disks ;-) > + return NULL; > +} > + > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > libxl_device_disk **new_disk, > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 0074ec4..a451c79 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -77,6 +77,8 @@ > #define LIBXL_PV_EXTRA_MEMORY 1024 > #define LIBXL_HVM_EXTRA_MEMORY 2048 > #define LIBXL_MIN_DOM0_MEM (128*1024) > +/* use 0 as the domid of the toolstack domain for now */ > +#define LIBXL_TOOLSTACK_DOMID 0 > #define QEMU_SIGNATURE "DeviceModelRecord0002" > #define STUBDOM_CONSOLE_LOGGING 0 > #define STUBDOM_CONSOLE_SAVE 1 > @@ -763,6 +765,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, > */ > _hidden int libxl__try_phy_backend(mode_t st_mode); > > +_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid); > + > /* from libxl_pci */ > > _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); > diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c > index 925248b..cb596a9 100644 > --- a/tools/libxl/libxl_linux.c > +++ b/tools/libxl/libxl_linux.c > @@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode) > > return 1; > } > + > +#define EXT_SHIFT 28 > +#define EXTENDED (1< +#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED)) > +#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED)) > + > +/* same as in Linux */ > +static char *encode_disk_name(char *ptr, unsigned int n) > +{ > + if (n >= 26) > + ptr = encode_disk_name(ptr, n / 26 - 1); > + *ptr = 'a' + n % 26; > + return ptr + 1; > +} > + > +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) > +{ > + int minor; > + int offset; > + int nr_parts; > + char *ptr = NULL; > + char *ret = libxl__zalloc(gc, 32); > + > + if (!VDEV_IS_EXTENDED(devid)) { > + minor = devid & 0xff; > + nr_parts = 16; > + } else { > + minor = BLKIF_MINOR_EXT(devid); > + nr_parts = 256; > + } > + offset = minor / nr_parts; > + > + /* arbitrary upper bound */ > + if (offset > 676) > + return NULL; > + > + strcpy(ret, "xvd"); > + ptr = encode_disk_name(ret + 3, offset); > + if (minor % nr_parts == 0) > + *ptr = 0; > + else > + snprintf(ptr, ret + 32 - ptr, > + "%d", minor & (nr_parts - 1)); > + return ret; > +} > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c > index 9e0ed6d..dbf5f71 100644 > --- a/tools/libxl/libxl_netbsd.c > +++ b/tools/libxl/libxl_netbsd.c Aha, here's where we need a BSD contribution. CC someone? > @@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode) > > return 0; > } > + > +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) > +{ > + /* TODO */ > + return NULL; > +} _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:00:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQJzb-00007w-V0; Fri, 04 May 2012 15:00:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQJza-00007q-Am for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:00:22 +0000 Received: from [85.158.139.83:3093] by server-9.bemta-5.messagelabs.com id 0B/FD-09826-50FE3AF4; Fri, 04 May 2012 15:00:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336143620!15531596!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19205 invoked from network); 4 May 2012 15:00:21 -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; 4 May 2012 15:00:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301562" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15: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; Fri, 4 May 2012 16:00:01 +0100 Message-ID: <1336143599.7535.17.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 15:59:59 +0100 In-Reply-To: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > Introduce libxl__alloc_vdev: find a spare virtual block device in the > domain passed as argument. > > Changes in v5: > - remove domid paramter to libxl__alloc_vdev (assume > LIBXL_TOOLSTACK_DOMID); > - remove scaling limit from libxl__alloc_vdev. > > Changes in v4: > - rename libxl__devid_to_vdev to libxl__devid_to_localdev; > - introduce upper bound for encode_disk_name; > - better error handling; > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_internal.c | 31 ++++++++++++++++++++++++++++ > tools/libxl/libxl_internal.h | 4 +++ > tools/libxl/libxl_linux.c | 45 ++++++++++++++++++++++++++++++++++++++++++ > tools/libxl/libxl_netbsd.c | 6 +++++ > 4 files changed, 86 insertions(+), 0 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index bd5ebb3..7a1e017 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -480,6 +480,37 @@ out: > return rc; > } > > +/* libxl__alloc_vdev only works on the local domain, that is the domain > + * where the toolstack is running */ > +static char * libxl__alloc_vdev(libxl__gc *gc, const char *blkdev_start, > + xs_transaction_t t) > +{ > + int devid = 0, disk = 0, part = 0; > + char *vdev = NULL; > + char *dompath = libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID); > + > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); If you specify the default blkdev_start in xl as d0 instead of xvda doesn't at least this bit magically become portable to BSD etc too? Or couldn't it actually be an int and save you parsing at all? > + if (part != 0) { > + LOG(ERROR, "blkdev_start is invalid"); > + return NULL; > + } > + > + do { > + vdev = GCSPRINTF("d%dp0", disk); > + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); libxl__device_disk_dev_number does the right thing with "d" (i.e. without the hardcoded "p0"), I think. I'd be tempted to inline the GCSPRINTF in the arg and do away with vdev since you don't use it again. > + if (libxl__xs_read(gc, t, > + libxl__sprintf(gc, "%s/device/vbd/%d/backend", > + dompath, devid)) == NULL) { > + if (errno == ENOENT) > + return libxl__devid_to_localdev(gc, devid); > + else > + return NULL; > + } > + disk++; > + } while (disk <= (1 << 20)); That's a whole lotta disks ;-) > + return NULL; > +} > + > char * libxl__device_disk_local_attach(libxl__gc *gc, > const libxl_device_disk *in_disk, > libxl_device_disk **new_disk, > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 0074ec4..a451c79 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -77,6 +77,8 @@ > #define LIBXL_PV_EXTRA_MEMORY 1024 > #define LIBXL_HVM_EXTRA_MEMORY 2048 > #define LIBXL_MIN_DOM0_MEM (128*1024) > +/* use 0 as the domid of the toolstack domain for now */ > +#define LIBXL_TOOLSTACK_DOMID 0 > #define QEMU_SIGNATURE "DeviceModelRecord0002" > #define STUBDOM_CONSOLE_LOGGING 0 > #define STUBDOM_CONSOLE_SAVE 1 > @@ -763,6 +765,8 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, > */ > _hidden int libxl__try_phy_backend(mode_t st_mode); > > +_hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid); > + > /* from libxl_pci */ > > _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); > diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c > index 925248b..cb596a9 100644 > --- a/tools/libxl/libxl_linux.c > +++ b/tools/libxl/libxl_linux.c > @@ -25,3 +25,48 @@ int libxl__try_phy_backend(mode_t st_mode) > > return 1; > } > + > +#define EXT_SHIFT 28 > +#define EXTENDED (1< +#define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED)) > +#define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED)) > + > +/* same as in Linux */ > +static char *encode_disk_name(char *ptr, unsigned int n) > +{ > + if (n >= 26) > + ptr = encode_disk_name(ptr, n / 26 - 1); > + *ptr = 'a' + n % 26; > + return ptr + 1; > +} > + > +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) > +{ > + int minor; > + int offset; > + int nr_parts; > + char *ptr = NULL; > + char *ret = libxl__zalloc(gc, 32); > + > + if (!VDEV_IS_EXTENDED(devid)) { > + minor = devid & 0xff; > + nr_parts = 16; > + } else { > + minor = BLKIF_MINOR_EXT(devid); > + nr_parts = 256; > + } > + offset = minor / nr_parts; > + > + /* arbitrary upper bound */ > + if (offset > 676) > + return NULL; > + > + strcpy(ret, "xvd"); > + ptr = encode_disk_name(ret + 3, offset); > + if (minor % nr_parts == 0) > + *ptr = 0; > + else > + snprintf(ptr, ret + 32 - ptr, > + "%d", minor & (nr_parts - 1)); > + return ret; > +} > diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c > index 9e0ed6d..dbf5f71 100644 > --- a/tools/libxl/libxl_netbsd.c > +++ b/tools/libxl/libxl_netbsd.c Aha, here's where we need a BSD contribution. CC someone? > @@ -24,3 +24,9 @@ int libxl__try_phy_backend(mode_t st_mode) > > return 0; > } > + > +char *libxl__devid_to_localdev(libxl__gc *gc, int devid) > +{ > + /* TODO */ > + return NULL; > +} _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:12:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:12:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKAb-0000UF-6r; Fri, 04 May 2012 15:11:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKAY-0000UA-LM for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:11:43 +0000 Received: from [85.158.138.51:32364] by server-1.bemta-3.messagelabs.com id D1/DE-11491-DA1F3AF4; Fri, 04 May 2012 15:11:41 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336144300!25168592!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24154 invoked from network); 4 May 2012 15:11:41 -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; 4 May 2012 15:11:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301791" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15:11:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 16:11:39 +0100 Message-ID: <1336144298.7535.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 16:11:38 +0100 In-Reply-To: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > - Spawn a QEMU instance at boot time to handle disk local attach > requests. > > - Implement libxl_device_disk_local_attach for QDISKs in terms of a > regular disk attach with the frontend and backend running in the same > domain. > > Chanegs in v5: > - replace LIBXL__LOG with LOG. > > Changes on v4: > - improve error handling and exit paths in libxl__device_disk_local_attach. > > Signed-off-by: Stefano Stabellini > --- > tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + > tools/hotplug/Linux/init.d/xencommons | 3 + > tools/libxl/libxl_internal.c | 58 ++++++++++++++++++---- > 3 files changed, 53 insertions(+), 11 deletions(-) > > diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons > index 6543204..0f3b9ad 100644 > --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons > +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons > @@ -12,3 +12,6 @@ > > # Running xenbackendd in debug mode > #XENBACKENDD_DEBUG=[yes|on|1] > + > +# qemu path and log file What does "and log file" mean? Apart from that: Acked-by:Ian Campbell > +#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 > diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons > index 2f81ea2..9dda6e2 100644 > --- a/tools/hotplug/Linux/init.d/xencommons > +++ b/tools/hotplug/Linux/init.d/xencommons > @@ -104,6 +104,9 @@ do_start () { > xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS > test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d" > test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS > + echo Starting QEMU as disk backend for dom0 > + test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 > + $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null > } > do_stop () { > echo Stopping xenconsoled > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 7a1e017..e180498 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -519,6 +519,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > int rc; > + xs_transaction_t t = XBT_NULL; > libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > > memcpy(disk, in_disk, sizeof(libxl_device_disk)); > @@ -561,13 +562,35 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > break; > case LIBXL_DISK_BACKEND_QDISK: > if (disk->format != LIBXL_DISK_FORMAT_RAW) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" > - " attach a qdisk image if the format is not raw"); > - break; > + do { > + t = xs_transaction_start(ctx->xsh); > + if (t == XBT_NULL) { > + LOG(ERROR, "failed to start a xenstore transaction"); > + goto out; > + } > + disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t); > + if (disk->vdev == NULL) { > + LOG(ERROR, "libxl__alloc_vdev failed"); > + goto out; > + } > + if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID, > + t, disk)) { > + LOG(ERROR, "libxl_device_disk_add failed"); > + goto out; > + } > + rc = xs_transaction_end(ctx->xsh, t, 0); > + } while (rc == 0 && errno == EAGAIN); > + t = XBT_NULL; > + if (rc == 0) { > + LOGE(ERROR, "xenstore transaction failed"); > + goto out; > + } > + dev = GCSPRINTF("/dev/%s", disk->vdev); > + } else { > + dev = disk->pdev_path; > } > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - in_disk->pdev_path); > - dev = disk->pdev_path; > + dev); > break; > default: > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " > @@ -576,18 +599,31 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > } > > out: > + if (t != XBT_NULL) > + xs_transaction_end(ctx->xsh, t, 1); > *new_disk = disk; > return dev; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) > { > - /* Nothing to do for PHYSTYPE_PHY. */ > - > - /* > - * For other device types assume that the blktap2 process is > - * needed by the soon to be started domain and do nothing. > - */ > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_QDISK: > + if (disk->vdev != NULL) { > + libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID, > + disk, 0); > + return libxl_device_disk_destroy(gc->owner, > + LIBXL_TOOLSTACK_DOMID, disk); > + } > + break; > + default: > + /* > + * Nothing to do for PHYSTYPE_PHY. > + * For other device types assume that the blktap2 process is > + * needed by the soon to be started domain and do nothing. > + */ > + break; > + } > > return 0; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:12:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:12:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKAb-0000UF-6r; Fri, 04 May 2012 15:11:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKAY-0000UA-LM for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:11:43 +0000 Received: from [85.158.138.51:32364] by server-1.bemta-3.messagelabs.com id D1/DE-11491-DA1F3AF4; Fri, 04 May 2012 15:11:41 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336144300!25168592!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24154 invoked from network); 4 May 2012 15:11:41 -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; 4 May 2012 15:11:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301791" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15:11:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 16:11:39 +0100 Message-ID: <1336144298.7535.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 16:11:38 +0100 In-Reply-To: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > - Spawn a QEMU instance at boot time to handle disk local attach > requests. > > - Implement libxl_device_disk_local_attach for QDISKs in terms of a > regular disk attach with the frontend and backend running in the same > domain. > > Chanegs in v5: > - replace LIBXL__LOG with LOG. > > Changes on v4: > - improve error handling and exit paths in libxl__device_disk_local_attach. > > Signed-off-by: Stefano Stabellini > --- > tools/hotplug/Linux/init.d/sysconfig.xencommons | 3 + > tools/hotplug/Linux/init.d/xencommons | 3 + > tools/libxl/libxl_internal.c | 58 ++++++++++++++++++---- > 3 files changed, 53 insertions(+), 11 deletions(-) > > diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons > index 6543204..0f3b9ad 100644 > --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons > +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons > @@ -12,3 +12,6 @@ > > # Running xenbackendd in debug mode > #XENBACKENDD_DEBUG=[yes|on|1] > + > +# qemu path and log file What does "and log file" mean? Apart from that: Acked-by:Ian Campbell > +#QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 > diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons > index 2f81ea2..9dda6e2 100644 > --- a/tools/hotplug/Linux/init.d/xencommons > +++ b/tools/hotplug/Linux/init.d/xencommons > @@ -104,6 +104,9 @@ do_start () { > xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS > test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d" > test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS > + echo Starting QEMU as disk backend for dom0 > + test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386 > + $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null > } > do_stop () { > echo Stopping xenconsoled > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 7a1e017..e180498 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -519,6 +519,7 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > libxl_ctx *ctx = gc->owner; > char *dev = NULL; > int rc; > + xs_transaction_t t = XBT_NULL; > libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > > memcpy(disk, in_disk, sizeof(libxl_device_disk)); > @@ -561,13 +562,35 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > break; > case LIBXL_DISK_BACKEND_QDISK: > if (disk->format != LIBXL_DISK_FORMAT_RAW) { > - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot locally" > - " attach a qdisk image if the format is not raw"); > - break; > + do { > + t = xs_transaction_start(ctx->xsh); > + if (t == XBT_NULL) { > + LOG(ERROR, "failed to start a xenstore transaction"); > + goto out; > + } > + disk->vdev = libxl__alloc_vdev(gc, blkdev_start, t); > + if (disk->vdev == NULL) { > + LOG(ERROR, "libxl__alloc_vdev failed"); > + goto out; > + } > + if (libxl__device_disk_add(gc, LIBXL_TOOLSTACK_DOMID, > + t, disk)) { > + LOG(ERROR, "libxl_device_disk_add failed"); > + goto out; > + } > + rc = xs_transaction_end(ctx->xsh, t, 0); > + } while (rc == 0 && errno == EAGAIN); > + t = XBT_NULL; > + if (rc == 0) { > + LOGE(ERROR, "xenstore transaction failed"); > + goto out; > + } > + dev = GCSPRINTF("/dev/%s", disk->vdev); > + } else { > + dev = disk->pdev_path; > } > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - in_disk->pdev_path); > - dev = disk->pdev_path; > + dev); > break; > default: > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend " > @@ -576,18 +599,31 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > } > > out: > + if (t != XBT_NULL) > + xs_transaction_end(ctx->xsh, t, 1); > *new_disk = disk; > return dev; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) > { > - /* Nothing to do for PHYSTYPE_PHY. */ > - > - /* > - * For other device types assume that the blktap2 process is > - * needed by the soon to be started domain and do nothing. > - */ > + switch (disk->backend) { > + case LIBXL_DISK_BACKEND_QDISK: > + if (disk->vdev != NULL) { > + libxl_device_disk_remove(gc->owner, LIBXL_TOOLSTACK_DOMID, > + disk, 0); > + return libxl_device_disk_destroy(gc->owner, > + LIBXL_TOOLSTACK_DOMID, disk); > + } > + break; > + default: > + /* > + * Nothing to do for PHYSTYPE_PHY. > + * For other device types assume that the blktap2 process is > + * needed by the soon to be started domain and do nothing. > + */ > + break; > + } > > return 0; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:14:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:14:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKCm-0000ZP-OP; Fri, 04 May 2012 15:14:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKCl-0000ZF-CY for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:13:59 +0000 Received: from [193.109.254.147:12151] by server-6.bemta-14.messagelabs.com id 7E/1A-04960-632F3AF4; Fri, 04 May 2012 15:13:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336144437!7710690!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6197 invoked from network); 4 May 2012 15:13:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 15:13:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15:13: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; Fri, 4 May 2012 16:13:57 +0100 Message-ID: <1336144436.7535.22.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 16:13:56 +0100 In-Reply-To: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 8/8] libxl__device_disk_local_attach: wait for state "connected" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > In order to make sure that the block device is available and ready to be > used, wait for state "connected" in the backend before returning. > > Signed-off-by: Stefano Stabellini > > Changes in v5: > - unify error paths. > > Changes in v4: > - improve exit paths. > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_internal.c | 20 +++++++++++++++++--- > 1 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index e180498..05faff5 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -517,8 +517,9 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > const char *blkdev_start) > { > libxl_ctx *ctx = gc->owner; > - char *dev = NULL; > + char *dev = NULL, *be_path = NULL; > int rc; > + libxl__device device; > xs_transaction_t t = XBT_NULL; > libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > > @@ -598,11 +599,24 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > break; > } > > + if (disk->vdev != NULL) { > + rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device); > + if (rc < 0) > + goto out; > + be_path = libxl__device_backend_path(gc, &device); > + rc = libxl__wait_for_backend(gc, be_path, "4"); > + if (rc < 0) > + goto out; > + } > + > + *new_disk = disk; > + return dev; > out: > if (t != XBT_NULL) > xs_transaction_end(ctx->xsh, t, 1); There's no way to reach the preceding "return dev" with the transaction still open? Previously we would have fallen through and done it. > - *new_disk = disk; > - return dev; > + else > + libxl__device_disk_local_detach(gc, disk); > + return NULL; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:14:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:14:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKCm-0000ZP-OP; Fri, 04 May 2012 15:14:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKCl-0000ZF-CY for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:13:59 +0000 Received: from [193.109.254.147:12151] by server-6.bemta-14.messagelabs.com id 7E/1A-04960-632F3AF4; Fri, 04 May 2012 15:13:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336144437!7710690!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6197 invoked from network); 4 May 2012 15:13:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 15:13:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="12301851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 15:13: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; Fri, 4 May 2012 16:13:57 +0100 Message-ID: <1336144436.7535.22.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 4 May 2012 16:13:56 +0100 In-Reply-To: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-8-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH v5 8/8] libxl__device_disk_local_attach: wait for state "connected" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > In order to make sure that the block device is available and ready to be > used, wait for state "connected" in the backend before returning. > > Signed-off-by: Stefano Stabellini > > Changes in v5: > - unify error paths. > > Changes in v4: > - improve exit paths. > > Signed-off-by: Stefano Stabellini > --- > tools/libxl/libxl_internal.c | 20 +++++++++++++++++--- > 1 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index e180498..05faff5 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c > @@ -517,8 +517,9 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > const char *blkdev_start) > { > libxl_ctx *ctx = gc->owner; > - char *dev = NULL; > + char *dev = NULL, *be_path = NULL; > int rc; > + libxl__device device; > xs_transaction_t t = XBT_NULL; > libxl_device_disk *disk = libxl__zalloc(gc, sizeof(libxl_device_disk)); > > @@ -598,11 +599,24 @@ char * libxl__device_disk_local_attach(libxl__gc *gc, > break; > } > > + if (disk->vdev != NULL) { > + rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device); > + if (rc < 0) > + goto out; > + be_path = libxl__device_backend_path(gc, &device); > + rc = libxl__wait_for_backend(gc, be_path, "4"); > + if (rc < 0) > + goto out; > + } > + > + *new_disk = disk; > + return dev; > out: > if (t != XBT_NULL) > xs_transaction_end(ctx->xsh, t, 1); There's no way to reach the preceding "return dev" with the transaction still open? Previously we would have fallen through and done it. > - *new_disk = disk; > - return dev; > + else > + libxl__device_disk_local_detach(gc, disk); > + return NULL; > } > > int libxl__device_disk_local_detach(libxl__gc *gc, libxl_device_disk *disk) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:14:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKDC-0000be-4w; Fri, 04 May 2012 15:14:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKDB-0000bO-7F for xen-devel@lists.xen.org; Fri, 04 May 2012 15:14:25 +0000 Received: from [85.158.138.51:53086] by server-11.bemta-3.messagelabs.com id 8F/FC-18894-052F3AF4; Fri, 04 May 2012 15:14:24 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336144462!14294702!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14879 invoked from network); 4 May 2012 15:14:23 -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; 4 May 2012 15:14:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24870439" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:14:21 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:14:21 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQKD7-00077s-2T; Fri, 04 May 2012 16:14:21 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 16:14:15 +0100 Message-ID: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is needed in order to perform the domain destruction if libxl__domain_make fails. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- To be applied after IanJ libxl: subprocess handling series tools/libxl/libxl_create.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 928a48c..788e553 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -607,6 +607,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:14:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKDC-0000be-4w; Fri, 04 May 2012 15:14:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKDB-0000bO-7F for xen-devel@lists.xen.org; Fri, 04 May 2012 15:14:25 +0000 Received: from [85.158.138.51:53086] by server-11.bemta-3.messagelabs.com id 8F/FC-18894-052F3AF4; Fri, 04 May 2012 15:14:24 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336144462!14294702!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14879 invoked from network); 4 May 2012 15:14:23 -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; 4 May 2012 15:14:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24870439" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:14:21 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 11:14:21 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SQKD7-00077s-2T; Fri, 04 May 2012 16:14:21 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 4 May 2012 16:14:15 +0100 Message-ID: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is needed in order to perform the domain destruction if libxl__domain_make fails. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- To be applied after IanJ libxl: subprocess handling series tools/libxl/libxl_create.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 928a48c..788e553 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -607,6 +607,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:19:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKHi-0000yC-Rb; Fri, 04 May 2012 15:19:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKHh-0000y5-8f for xen-devel@lists.xen.org; Fri, 04 May 2012 15:19:05 +0000 Received: from [85.158.143.99:51843] by server-3.bemta-4.messagelabs.com id 7A/B9-05853-863F3AF4; Fri, 04 May 2012 15:19:04 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336144742!21211122!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2219 invoked from network); 4 May 2012 15:19:03 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 15:19:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193437307" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:19:01 -0400 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, 4 May 2012 11:19:01 -0400 Message-ID: <4FA3F364.5050105@citrix.com> Date: Fri, 4 May 2012 16:19:00 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> In-Reply-To: <4FA3ECF90200007800081A71@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 13:51, Jan Beulich wrote: >>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >> I know that xen-unstable is on a feature freeze, and this is not >> strictly a bugfix (yet; see below), but as it is safe and designed to >> help clarity in the case of a crash, so I request that it be considered >> for inclusion. >> >> I have constructed an artificial case where the information reported in >> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >> leaves stale register state written into the offlined CPU crash >> information. In this case, the information was stale but correct, due >> to the predictable nature of the Xen crash path from the 'C' debug key, >> but there is no guarantee that in the case of a real crash, the same >> will still be true. > Apart from the missing blanks in the for() statement (which could as > well be a simple memset() afaict), > Acked-by: Jan Beulich > > I personally would think that this can go in as a bug fix. > > Jan How would you format the for loop differently? (Not that I mind - just so I know for next time) As for clear_page vs memset - clear_page is faster, and liable to be conditionally tuned more in the future. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:19:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKHi-0000yC-Rb; Fri, 04 May 2012 15:19:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKHh-0000y5-8f for xen-devel@lists.xen.org; Fri, 04 May 2012 15:19:05 +0000 Received: from [85.158.143.99:51843] by server-3.bemta-4.messagelabs.com id 7A/B9-05853-863F3AF4; Fri, 04 May 2012 15:19:04 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336144742!21211122!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2219 invoked from network); 4 May 2012 15:19:03 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 15:19:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="193437307" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:19:01 -0400 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, 4 May 2012 11:19:01 -0400 Message-ID: <4FA3F364.5050105@citrix.com> Date: Fri, 4 May 2012 16:19:00 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> In-Reply-To: <4FA3ECF90200007800081A71@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 13:51, Jan Beulich wrote: >>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >> I know that xen-unstable is on a feature freeze, and this is not >> strictly a bugfix (yet; see below), but as it is safe and designed to >> help clarity in the case of a crash, so I request that it be considered >> for inclusion. >> >> I have constructed an artificial case where the information reported in >> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >> leaves stale register state written into the offlined CPU crash >> information. In this case, the information was stale but correct, due >> to the predictable nature of the Xen crash path from the 'C' debug key, >> but there is no guarantee that in the case of a real crash, the same >> will still be true. > Apart from the missing blanks in the for() statement (which could as > well be a simple memset() afaict), > Acked-by: Jan Beulich > > I personally would think that this can go in as a bug fix. > > Jan How would you format the for loop differently? (Not that I mind - just so I know for next time) As for clear_page vs memset - clear_page is faster, and liable to be conditionally tuned more in the future. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:25:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKNa-000179-LU; Fri, 04 May 2012 15:25:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKNZ-00016z-Hx for xen-devel@lists.xen.org; Fri, 04 May 2012 15:25:09 +0000 Received: from [85.158.139.83:63665] by server-8.bemta-5.messagelabs.com id 40/C1-26964-4D4F3AF4; Fri, 04 May 2012 15:25:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336145105!26724600!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17308 invoked from network); 4 May 2012 15:25:06 -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; 4 May 2012 15:25:06 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 16:25:04 +0100 Message-Id: <4FA410F00200007800081B86@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 16:25:04 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> In-Reply-To: <4FA3F364.5050105@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 17:19, Andrew Cooper wrote: > On 04/05/12 13:51, Jan Beulich wrote: >>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>> I know that xen-unstable is on a feature freeze, and this is not >>> strictly a bugfix (yet; see below), but as it is safe and designed to >>> help clarity in the case of a crash, so I request that it be considered >>> for inclusion. >>> >>> I have constructed an artificial case where the information reported in >>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>> leaves stale register state written into the offlined CPU crash >>> information. In this case, the information was stale but correct, due >>> to the predictable nature of the Xen crash path from the 'C' debug key, >>> but there is no guarantee that in the case of a real crash, the same >>> will still be true. >> Apart from the missing blanks in the for() statement (which could as >> well be a simple memset() afaict), >> Acked-by: Jan Beulich >> >> I personally would think that this can go in as a bug fix. >> >> Jan > > How would you format the for loop differently? (Not that I mind - just > so I know for next time) for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) > As for clear_page vs memset - clear_page is faster, and liable to be > conditionally tuned more in the future. Certainly, but does this matter here? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:25:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKNa-000179-LU; Fri, 04 May 2012 15:25:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKNZ-00016z-Hx for xen-devel@lists.xen.org; Fri, 04 May 2012 15:25:09 +0000 Received: from [85.158.139.83:63665] by server-8.bemta-5.messagelabs.com id 40/C1-26964-4D4F3AF4; Fri, 04 May 2012 15:25:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336145105!26724600!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17308 invoked from network); 4 May 2012 15:25:06 -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; 4 May 2012 15:25:06 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 16:25:04 +0100 Message-Id: <4FA410F00200007800081B86@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 16:25:04 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> In-Reply-To: <4FA3F364.5050105@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 17:19, Andrew Cooper wrote: > On 04/05/12 13:51, Jan Beulich wrote: >>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>> I know that xen-unstable is on a feature freeze, and this is not >>> strictly a bugfix (yet; see below), but as it is safe and designed to >>> help clarity in the case of a crash, so I request that it be considered >>> for inclusion. >>> >>> I have constructed an artificial case where the information reported in >>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>> leaves stale register state written into the offlined CPU crash >>> information. In this case, the information was stale but correct, due >>> to the predictable nature of the Xen crash path from the 'C' debug key, >>> but there is no guarantee that in the case of a real crash, the same >>> will still be true. >> Apart from the missing blanks in the for() statement (which could as >> well be a simple memset() afaict), >> Acked-by: Jan Beulich >> >> I personally would think that this can go in as a bug fix. >> >> Jan > > How would you format the for loop differently? (Not that I mind - just > so I know for next time) for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) > As for clear_page vs memset - clear_page is faster, and liable to be > conditionally tuned more in the future. Certainly, but does this matter here? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKba-0001Kq-6h; Fri, 04 May 2012 15:39:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKbY-0001Kl-Jq for xen-devel@lists.xen.org; Fri, 04 May 2012 15:39:36 +0000 Received: from [85.158.139.83:32186] by server-11.bemta-5.messagelabs.com id 6F/A3-12959-538F3AF4; Fri, 04 May 2012 15:39:33 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336145970!26118034!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29627 invoked from network); 4 May 2012 15:39:32 -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; 4 May 2012 15:39:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24871762" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:39:30 -0400 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, 4 May 2012 11:39:29 -0400 Message-ID: <4FA3F830.1050304@citrix.com> Date: Fri, 4 May 2012 16:39:28 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> <4FA410F00200007800081B86@nat28.tlf.novell.com> In-Reply-To: <4FA410F00200007800081B86@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------080707010503030902060200" Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------080707010503030902060200 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 04/05/12 16:25, Jan Beulich wrote: >>>> On 04.05.12 at 17:19, Andrew Cooper wrote: >> On 04/05/12 13:51, Jan Beulich wrote: >>>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>>> I know that xen-unstable is on a feature freeze, and this is not >>>> strictly a bugfix (yet; see below), but as it is safe and designed to >>>> help clarity in the case of a crash, so I request that it be considered >>>> for inclusion. >>>> >>>> I have constructed an artificial case where the information reported in >>>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>>> leaves stale register state written into the offlined CPU crash >>>> information. In this case, the information was stale but correct, due >>>> to the predictable nature of the Xen crash path from the 'C' debug key, >>>> but there is no guarantee that in the case of a real crash, the same >>>> will still be true. >>> Apart from the missing blanks in the for() statement (which could as >>> well be a simple memset() afaict), >>> Acked-by: Jan Beulich >>> >>> I personally would think that this can go in as a bug fix. >>> >>> Jan >> How would you format the for loop differently? (Not that I mind - just >> so I know for next time) > for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) Ok - refreshed the patch as such > >> As for clear_page vs memset - clear_page is faster, and liable to be >> conditionally tuned more in the future. > Certainly, but does this matter here? > > Jan > crash_heap_size scales linearly with the number of PCPUs on the system, so very large boxes might start noticing a difference in boot speed. (Probably not in the grand scheme of things, but as we are explicitly allocating pages, it makes sense to clear them as pages) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------080707010503030902060200 Content-Type: text/x-patch; name="kexec-clear-notes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kexec-clear-notes.patch" # HG changeset patch # Parent 98fe3b2a572d4ffe704124e75c7aa8d94dbb51bc kexec: clear notes during setup Explicity zero the memory backing the crash notes during setup. This allows the crash environment to be rather more certain whether the crash notes were actually written, rather than trusting that the memory was clear beforehand. Signed-off-by: Andrew Cooper diff -r 98fe3b2a572d xen/common/kexec.c --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -401,7 +401,7 @@ static int kexec_init_cpu_notes(const un /* If we dont care about the position of allocation, malloc. */ if ( low_crashinfo_mode == LOW_CRASHINFO_NONE ) - note = xmalloc_bytes(nr_bytes); + note = xzalloc_bytes(nr_bytes); /* Protect the write into crash_notes[] with a spinlock, as this function * is on a hotplug path and a hypercall path. */ @@ -505,7 +505,7 @@ static int __init kexec_init(void) if ( low_crashinfo_mode > LOW_CRASHINFO_NONE ) { - size_t crash_heap_size; + size_t crash_heap_size, i; /* This calculation is safe even if the machine is booted in * uniprocessor mode. */ @@ -520,6 +520,9 @@ static int __init kexec_init(void) if ( ! crash_heap_current ) return -ENOMEM; + for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) + clear_page(crash_heap_current + (i << PAGE_SHIFT)); + crash_heap_end = crash_heap_current + crash_heap_size; } --------------080707010503030902060200 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------080707010503030902060200-- From xen-devel-bounces@lists.xen.org Fri May 04 15:39:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15: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 ) id 1SQKba-0001Kq-6h; Fri, 04 May 2012 15:39:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKbY-0001Kl-Jq for xen-devel@lists.xen.org; Fri, 04 May 2012 15:39:36 +0000 Received: from [85.158.139.83:32186] by server-11.bemta-5.messagelabs.com id 6F/A3-12959-538F3AF4; Fri, 04 May 2012 15:39:33 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336145970!26118034!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDI1NDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29627 invoked from network); 4 May 2012 15:39:32 -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; 4 May 2012 15:39:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,530,1330923600"; d="scan'208";a="24871762" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 11:39:30 -0400 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, 4 May 2012 11:39:29 -0400 Message-ID: <4FA3F830.1050304@citrix.com> Date: Fri, 4 May 2012 16:39:28 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> <4FA410F00200007800081B86@nat28.tlf.novell.com> In-Reply-To: <4FA410F00200007800081B86@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------080707010503030902060200" Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------080707010503030902060200 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 04/05/12 16:25, Jan Beulich wrote: >>>> On 04.05.12 at 17:19, Andrew Cooper wrote: >> On 04/05/12 13:51, Jan Beulich wrote: >>>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>>> I know that xen-unstable is on a feature freeze, and this is not >>>> strictly a bugfix (yet; see below), but as it is safe and designed to >>>> help clarity in the case of a crash, so I request that it be considered >>>> for inclusion. >>>> >>>> I have constructed an artificial case where the information reported in >>>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>>> leaves stale register state written into the offlined CPU crash >>>> information. In this case, the information was stale but correct, due >>>> to the predictable nature of the Xen crash path from the 'C' debug key, >>>> but there is no guarantee that in the case of a real crash, the same >>>> will still be true. >>> Apart from the missing blanks in the for() statement (which could as >>> well be a simple memset() afaict), >>> Acked-by: Jan Beulich >>> >>> I personally would think that this can go in as a bug fix. >>> >>> Jan >> How would you format the for loop differently? (Not that I mind - just >> so I know for next time) > for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) Ok - refreshed the patch as such > >> As for clear_page vs memset - clear_page is faster, and liable to be >> conditionally tuned more in the future. > Certainly, but does this matter here? > > Jan > crash_heap_size scales linearly with the number of PCPUs on the system, so very large boxes might start noticing a difference in boot speed. (Probably not in the grand scheme of things, but as we are explicitly allocating pages, it makes sense to clear them as pages) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------080707010503030902060200 Content-Type: text/x-patch; name="kexec-clear-notes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kexec-clear-notes.patch" # HG changeset patch # Parent 98fe3b2a572d4ffe704124e75c7aa8d94dbb51bc kexec: clear notes during setup Explicity zero the memory backing the crash notes during setup. This allows the crash environment to be rather more certain whether the crash notes were actually written, rather than trusting that the memory was clear beforehand. Signed-off-by: Andrew Cooper diff -r 98fe3b2a572d xen/common/kexec.c --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -401,7 +401,7 @@ static int kexec_init_cpu_notes(const un /* If we dont care about the position of allocation, malloc. */ if ( low_crashinfo_mode == LOW_CRASHINFO_NONE ) - note = xmalloc_bytes(nr_bytes); + note = xzalloc_bytes(nr_bytes); /* Protect the write into crash_notes[] with a spinlock, as this function * is on a hotplug path and a hypercall path. */ @@ -505,7 +505,7 @@ static int __init kexec_init(void) if ( low_crashinfo_mode > LOW_CRASHINFO_NONE ) { - size_t crash_heap_size; + size_t crash_heap_size, i; /* This calculation is safe even if the machine is booted in * uniprocessor mode. */ @@ -520,6 +520,9 @@ static int __init kexec_init(void) if ( ! crash_heap_current ) return -ENOMEM; + for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) + clear_page(crash_heap_current + (i << PAGE_SHIFT)); + crash_heap_end = crash_heap_current + crash_heap_size; } --------------080707010503030902060200 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------080707010503030902060200-- From xen-devel-bounces@lists.xen.org Fri May 04 15:41:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKd3-0001Oj-NS; Fri, 04 May 2012 15:41:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKd2-0001Oe-9r for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:41:08 +0000 Received: from [85.158.143.99:53216] by server-3.bemta-4.messagelabs.com id 8A/15-05853-398F3AF4; Fri, 04 May 2012 15:41:07 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-216.messagelabs.com!1336146066!26554007!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,UPPERCASE_25_50 X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21185 invoked from network); 4 May 2012 15:41:06 -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 DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 15:41:06 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo72) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J01c52o44FAic3 for ; Fri, 4 May 2012 17:41:06 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id A32EA18630 for ; Fri, 4 May 2012 17:41:05 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 77ed22f4b55b4528d71e897831fe8686d8aa595e Message-Id: <77ed22f4b55b4528d71e.1336146061@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 17:41:01 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336146040 -7200 # Node ID 77ed22f4b55b4528d71e897831fe8686d8aa595e # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 tools/vtpm_manager: add missing DESTDIR to install rule Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r 77ed22f4b55b tools/vtpm_manager/manager/Makefile --- a/tools/vtpm_manager/manager/Makefile +++ b/tools/vtpm_manager/manager/Makefile @@ -17,7 +17,7 @@ install: build if [ ! -d "$(DESTDIR)/var/vtpm/socks" ]; \ then mkdir -p $(DESTDIR)/var/vtpm/socks; \ fi - $(INSTALL_PROG) $(BIN) $(BINDIR) + $(INSTALL_PROG) $(BIN) $(DESTDIR)$(BINDIR) .PHONY: clean clean: diff -r 8f556a70ae0b -r 77ed22f4b55b tools/vtpm_manager/migration/Makefile --- a/tools/vtpm_manager/migration/Makefile +++ b/tools/vtpm_manager/migration/Makefile @@ -20,8 +20,8 @@ build: $(BIND) $(BINC) .PHONY: install install: build - $(INSTALL_PROG) $(BIND) $(BINDIR) - $(INSTALL_PROG) $(BINC) $(BINDIR) + $(INSTALL_PROG) $(BIND) $(DESTDIR)$(BINDIR) + $(INSTALL_PROG) $(BINC) $(DESTDIR)$(BINDIR) .PHONY: clean clean: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:41:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKd3-0001Oj-NS; Fri, 04 May 2012 15:41:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKd2-0001Oe-9r for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:41:08 +0000 Received: from [85.158.143.99:53216] by server-3.bemta-4.messagelabs.com id 8A/15-05853-398F3AF4; Fri, 04 May 2012 15:41:07 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-216.messagelabs.com!1336146066!26554007!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,UPPERCASE_25_50 X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21185 invoked from network); 4 May 2012 15:41:06 -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 DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 15:41:06 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo72) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J01c52o44FAic3 for ; Fri, 4 May 2012 17:41:06 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id A32EA18630 for ; Fri, 4 May 2012 17:41:05 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 77ed22f4b55b4528d71e897831fe8686d8aa595e Message-Id: <77ed22f4b55b4528d71e.1336146061@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 17:41:01 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336146040 -7200 # Node ID 77ed22f4b55b4528d71e897831fe8686d8aa595e # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 tools/vtpm_manager: add missing DESTDIR to install rule Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r 77ed22f4b55b tools/vtpm_manager/manager/Makefile --- a/tools/vtpm_manager/manager/Makefile +++ b/tools/vtpm_manager/manager/Makefile @@ -17,7 +17,7 @@ install: build if [ ! -d "$(DESTDIR)/var/vtpm/socks" ]; \ then mkdir -p $(DESTDIR)/var/vtpm/socks; \ fi - $(INSTALL_PROG) $(BIN) $(BINDIR) + $(INSTALL_PROG) $(BIN) $(DESTDIR)$(BINDIR) .PHONY: clean clean: diff -r 8f556a70ae0b -r 77ed22f4b55b tools/vtpm_manager/migration/Makefile --- a/tools/vtpm_manager/migration/Makefile +++ b/tools/vtpm_manager/migration/Makefile @@ -20,8 +20,8 @@ build: $(BIND) $(BINC) .PHONY: install install: build - $(INSTALL_PROG) $(BIND) $(BINDIR) - $(INSTALL_PROG) $(BINC) $(BINDIR) + $(INSTALL_PROG) $(BIND) $(DESTDIR)$(BINDIR) + $(INSTALL_PROG) $(BINC) $(DESTDIR)$(BINDIR) .PHONY: clean clean: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:45:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:45:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKh8-0001e8-Cp; Fri, 04 May 2012 15:45:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKh7-0001dz-Ln for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:45:21 +0000 Received: from [193.109.254.147:37734] by server-3.bemta-14.messagelabs.com id 65/B1-23274-199F3AF4; Fri, 04 May 2012 15:45:21 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-27.messagelabs.com!1336146320!7685025!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1581 invoked from network); 4 May 2012 15:45:20 -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 DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 15:45:20 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo86) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id F02699o44DSOf8 ; Fri, 4 May 2012 17:45:19 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 4EE4618637; Fri, 4 May 2012 17:45:19 +0200 (CEST) Date: Fri, 4 May 2012 17:45:19 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120504154519.GA4958@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> <1336127272.2361.42.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336127272.2361.42.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Campbell wrote: > FWIW we don't build vTPM by default so you wouldn't have noticed the > actual failure. > > Perhaps the test system should enable non-default things like this? Sounds like a good idea to have a full featured build test. I just sent a patch out which fixes package build with '--enable-vtpm' at least in a SLES11 SP1 chroot for me. For some reason I did not send it earlier. Its 'tools/vtpm_manager: add missing DESTDIR to install rule' Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:45:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 15:45:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKh8-0001e8-Cp; Fri, 04 May 2012 15:45:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKh7-0001dz-Ln for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:45:21 +0000 Received: from [193.109.254.147:37734] by server-3.bemta-14.messagelabs.com id 65/B1-23274-199F3AF4; Fri, 04 May 2012 15:45:21 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-27.messagelabs.com!1336146320!7685025!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1581 invoked from network); 4 May 2012 15:45:20 -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 DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 15:45:20 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (joses mo86) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id F02699o44DSOf8 ; Fri, 4 May 2012 17:45:19 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 4EE4618637; Fri, 4 May 2012 17:45:19 +0200 (CEST) Date: Fri, 4 May 2012 17:45:19 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120504154519.GA4958@aepfle.de> References: <831D55AF5A11D64C9B4B43F59EEBF720A10D810DCA@FTLPMAILBOX02.citrite.net> <1336058302.20716.100.camel@zakaz.uk.xensource.com> <20120503153616.GA10918@aepfle.de> <20120503155716.GA14354@aepfle.de> <1336120438.26385.13.camel@dagon.hellion.org.uk> <20120504092819.GA10010@aepfle.de> <20387.44344.187553.704998@mariner.uk.xensource.com> <1336127272.2361.42.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336127272.2361.42.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ross Philipson Subject: Re: [Xen-devel] vTPM patch does not apply X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Ian Campbell wrote: > FWIW we don't build vTPM by default so you wouldn't have noticed the > actual failure. > > Perhaps the test system should enable non-default things like this? Sounds like a good idea to have a full featured build test. I just sent a patch out which fixes package build with '--enable-vtpm' at least in a SLES11 SP1 chroot for me. For some reason I did not send it earlier. Its 'tools/vtpm_manager: add missing DESTDIR to install rule' Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:50:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKld-0001te-5W; Fri, 04 May 2012 15:50:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKlc-0001tZ-De for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:50:00 +0000 Received: from [85.158.143.35:37983] by server-1.bemta-4.messagelabs.com id 92/88-20925-7AAF3AF4; Fri, 04 May 2012 15:49:59 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1336146598!14077568!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18537 invoked from network); 4 May 2012 15:49:59 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 15:49:59 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQKlW-0008JR-HG for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:49:54 +0200 Received: from 94.103.167.176 ([94.103.167.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:49:54 +0200 Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:49:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Christian Tramnitz Date: Fri, 4 May 2012 15:49:45 +0000 (UTC) Lines: 18 Message-ID: References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0) Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell citrix.com> writes: > AFAIK it is going to be an (experimental) feature in 4.2. Short follow-up: I haven't tried with Hyper-V yet, but on current (today's unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, but during load ESXi 5u1 crashes and Xen log shows: (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. Does anyone have an idea what MSR 485 does? It is not documented in "Intel 64 and IA-32 Architectures Software Developer's Manual"... Regards, Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 15:50:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKld-0001te-5W; Fri, 04 May 2012 15:50:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKlc-0001tZ-De for xen-devel@lists.xensource.com; Fri, 04 May 2012 15:50:00 +0000 Received: from [85.158.143.35:37983] by server-1.bemta-4.messagelabs.com id 92/88-20925-7AAF3AF4; Fri, 04 May 2012 15:49:59 +0000 X-Env-Sender: gcvxd-xen-devel@m.gmane.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1336146598!14077568!1 X-Originating-IP: [80.91.229.3] X-SpamReason: No, hits=1.7 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,RCVD_NUMERIC_HELO,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18537 invoked from network); 4 May 2012 15:49:59 -0000 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 15:49:59 -0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQKlW-0008JR-HG for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:49:54 +0200 Received: from 94.103.167.176 ([94.103.167.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:49:54 +0200 Received: from chris.ace by 94.103.167.176 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:49:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: xen-devel@lists.xensource.com From: Christian Tramnitz Date: Fri, 4 May 2012 15:49:45 +0000 (UTC) Lines: 18 Message-ID: References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 94.103.167.176 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0) Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell citrix.com> writes: > AFAIK it is going to be an (experimental) feature in 4.2. Short follow-up: I haven't tried with Hyper-V yet, but on current (today's unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, but during load ESXi 5u1 crashes and Xen log shows: (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. Does anyone have an idea what MSR 485 does? It is not documented in "Intel 64 and IA-32 Architectures Software Developer's Manual"... Regards, Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:01:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:01:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKwW-0002Sh-C8; Fri, 04 May 2012 16:01:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKwU-0002Sc-F7 for xen-devel@lists.xen.org; Fri, 04 May 2012 16:01:14 +0000 Received: from [85.158.143.99:39902] by server-3.bemta-4.messagelabs.com id 92/FC-05853-94DF3AF4; Fri, 04 May 2012 16:01:13 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336147271!26556577!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3351 invoked from network); 4 May 2012 16:01:12 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:01:12 -0000 Received: by ggno5 with SMTP id o5so413166ggn.32 for ; Fri, 04 May 2012 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SlnGZjAGdv1YE/J+NjVw11rsNggb8R3jFkRpbYmw9G4=; b=cPTscRlXjnAzcSjov75fqGZ++fcDcp9PZKOmaOrLayre6iXU8PBvzcrwlLizAOjzq3 +N+ChrEmJEuEU9Gjbq+4lk2Wvl0nlDPVrh0H67SdgH2kT7XxYSoV3Xzxm6ePpo5JDukG mwobxcd7r0vUSkz5Ri06c3QuHksZfNC5qWtGAhT11HFQTPi0VAT9KwxfXtoJap2l1+zw 5nTweJusa28wIgIeO0gsu4GXuZWYhpscLOKPztNMolsJUT894S6dzvNk286My5w/C/0x MH2vLBignj5SNfJOr07ZnNT54pITGz7LpjLeqWcc5QFOrNj+3clb6bpyd8JjCB3NUgao rI9A== Received: by 10.236.76.35 with SMTP id a23mr8373070yhe.125.1336147271307; Fri, 04 May 2012 09:01:11 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id j24sm13950334ann.18.2012.05.04.09.01.07 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 09:01:09 -0700 (PDT) Message-ID: <4FA3FD42.2040802@cantab.net> Date: Fri, 04 May 2012 17:01:06 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Andrew Cooper References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> <4FA410F00200007800081B86@nat28.tlf.novell.com> <4FA3F830.1050304@citrix.com> In-Reply-To: <4FA3F830.1050304@citrix.com> Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 16:39, Andrew Cooper wrote: > On 04/05/12 16:25, Jan Beulich wrote: >>>>> On 04.05.12 at 17:19, Andrew Cooper wrote: >>> On 04/05/12 13:51, Jan Beulich wrote: >>>>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>>>> I know that xen-unstable is on a feature freeze, and this is not >>>>> strictly a bugfix (yet; see below), but as it is safe and designed to >>>>> help clarity in the case of a crash, so I request that it be considered >>>>> for inclusion. >>>>> >>>>> I have constructed an artificial case where the information reported in >>>>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>>>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>>>> leaves stale register state written into the offlined CPU crash >>>>> information. In this case, the information was stale but correct, due >>>>> to the predictable nature of the Xen crash path from the 'C' debug key, >>>>> but there is no guarantee that in the case of a real crash, the same >>>>> will still be true. >>>> Apart from the missing blanks in the for() statement (which could as >>>> well be a simple memset() afaict), >>>> Acked-by: Jan Beulich >>>> >>>> I personally would think that this can go in as a bug fix. >>>> >>>> Jan >>> How would you format the for loop differently? (Not that I mind - just >>> so I know for next time) >> for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) > > Ok - refreshed the patch as such See also CODING_STYLE in the top level of the Xen source tree. >>> As for clear_page vs memset - clear_page is faster, and liable to be >>> conditionally tuned more in the future. >> Certainly, but does this matter here? >> >> Jan >> > > crash_heap_size scales linearly with the number of PCPUs on the system, > so very large boxes might start noticing a difference in boot speed. > (Probably not in the grand scheme of things, but as we are explicitly > allocating pages, it makes sense to clear them as pages) If this is important then there should be a alloc_zeroed_xenheap_pages() function for this and not an open-coded loop. I'd just use a memset() here. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:01:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:01:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKwW-0002Sh-C8; Fri, 04 May 2012 16:01:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKwU-0002Sc-F7 for xen-devel@lists.xen.org; Fri, 04 May 2012 16:01:14 +0000 Received: from [85.158.143.99:39902] by server-3.bemta-4.messagelabs.com id 92/FC-05853-94DF3AF4; Fri, 04 May 2012 16:01:13 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336147271!26556577!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3351 invoked from network); 4 May 2012 16:01:12 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:01:12 -0000 Received: by ggno5 with SMTP id o5so413166ggn.32 for ; Fri, 04 May 2012 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SlnGZjAGdv1YE/J+NjVw11rsNggb8R3jFkRpbYmw9G4=; b=cPTscRlXjnAzcSjov75fqGZ++fcDcp9PZKOmaOrLayre6iXU8PBvzcrwlLizAOjzq3 +N+ChrEmJEuEU9Gjbq+4lk2Wvl0nlDPVrh0H67SdgH2kT7XxYSoV3Xzxm6ePpo5JDukG mwobxcd7r0vUSkz5Ri06c3QuHksZfNC5qWtGAhT11HFQTPi0VAT9KwxfXtoJap2l1+zw 5nTweJusa28wIgIeO0gsu4GXuZWYhpscLOKPztNMolsJUT894S6dzvNk286My5w/C/0x MH2vLBignj5SNfJOr07ZnNT54pITGz7LpjLeqWcc5QFOrNj+3clb6bpyd8JjCB3NUgao rI9A== Received: by 10.236.76.35 with SMTP id a23mr8373070yhe.125.1336147271307; Fri, 04 May 2012 09:01:11 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id j24sm13950334ann.18.2012.05.04.09.01.07 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 09:01:09 -0700 (PDT) Message-ID: <4FA3FD42.2040802@cantab.net> Date: Fri, 04 May 2012 17:01:06 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Andrew Cooper References: <4FA3C0A5.7030309@citrix.com> <4FA3ECF90200007800081A71@nat28.tlf.novell.com> <4FA3F364.5050105@citrix.com> <4FA410F00200007800081B86@nat28.tlf.novell.com> <4FA3F830.1050304@citrix.com> In-Reply-To: <4FA3F830.1050304@citrix.com> Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] kexec: Clear notes during setup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 16:39, Andrew Cooper wrote: > On 04/05/12 16:25, Jan Beulich wrote: >>>>> On 04.05.12 at 17:19, Andrew Cooper wrote: >>> On 04/05/12 13:51, Jan Beulich wrote: >>>>>>> On 04.05.12 at 13:42, Andrew Cooper wrote: >>>>> I know that xen-unstable is on a feature freeze, and this is not >>>>> strictly a bugfix (yet; see below), but as it is safe and designed to >>>>> help clarity in the case of a crash, so I request that it be considered >>>>> for inclusion. >>>>> >>>>> I have constructed an artificial case where the information reported in >>>>> 1 per-cpu crash note was stale by using low_crashinfo mode, crashing >>>>> Xen, allowing it to reboot, offlining a CPU then re-crashing Xen. This >>>>> leaves stale register state written into the offlined CPU crash >>>>> information. In this case, the information was stale but correct, due >>>>> to the predictable nature of the Xen crash path from the 'C' debug key, >>>>> but there is no guarantee that in the case of a real crash, the same >>>>> will still be true. >>>> Apart from the missing blanks in the for() statement (which could as >>>> well be a simple memset() afaict), >>>> Acked-by: Jan Beulich >>>> >>>> I personally would think that this can go in as a bug fix. >>>> >>>> Jan >>> How would you format the for loop differently? (Not that I mind - just >>> so I know for next time) >> for ( i = 0; i < (crash_heap_size >> PAGE_SHIFT); ++i ) > > Ok - refreshed the patch as such See also CODING_STYLE in the top level of the Xen source tree. >>> As for clear_page vs memset - clear_page is faster, and liable to be >>> conditionally tuned more in the future. >> Certainly, but does this matter here? >> >> Jan >> > > crash_heap_size scales linearly with the number of PCPUs on the system, > so very large boxes might start noticing a difference in boot speed. > (Probably not in the grand scheme of things, but as we are explicitly > allocating pages, it makes sense to clear them as pages) If this is important then there should be a alloc_zeroed_xenheap_pages() function for this and not an open-coded loop. I'd just use a memset() here. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:02:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQKxB-0002Uq-PR; Fri, 04 May 2012 16:01:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKx9-0002Ui-Sv for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:01:56 +0000 Received: from [85.158.138.51:61182] by server-3.bemta-3.messagelabs.com id F7/81-04048-37DF3AF4; Fri, 04 May 2012 16:01:55 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336147314!25336408!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21181 invoked from network); 4 May 2012 16:01:54 -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; 4 May 2012 16:01:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12303701" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16: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; Fri, 4 May 2012 17:01:53 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQKx7-0002nf-Ju; Fri, 04 May 2012 16:01:53 +0000 From: David Vrabel To: Date: Fri, 4 May 2012 17:01:41 +0100 Message-ID: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel , Jan Beulich Subject: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The dom0_max_vcpus command line option only allows the exact number of VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs but no more than the number physically present." Add min: and max: prefixes to the option to set a minimum number of VCPUs, and a maximum which does not exceed the number of PCPUs. For example, with "dom0_max_vcpus=min:4,max:8": PCPUs Dom0 VCPUs 2 4 4 4 6 6 8 8 10 8 The existing behaviour of "dom0_max_vcpus=N" still works as before. Signed-off-by: David Vrabel --- docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++++++++-- xen/arch/x86/domain_build.c | 23 ++++++++++++++++++++++- 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index a6195f2..5f0c2cd 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -272,10 +272,35 @@ Specify the bit width of the DMA heap. ### dom0\_ioports\_disable ### dom0\_max\_vcpus + +Either: + > `= ` -Specify the maximum number of vcpus to give to dom0. This defaults -to the number of pcpus on the host. +The maximum number of VCPUs to give to dom0. This number of VCPUs can +be more than the number of PCPUs on the host. The default is the +number of PCPUs. + +Or: + +> `= List of ( min: | max: )` + +With the `min:` option dom0 will have at least this minimum number of +VCPUs (default: 1). This may be more than the number of PCPUs on the +host. + +With the `max:` option dom0 will have a VCPUs for each PCPUs but no +more than this maximum number (default: unlimited). + +For example, with `dom0_max_vcpus=min:4,max:8`: + + Number of + PCPUs | Dom0 VCPUs + 2 | 4 + 4 | 4 + 6 | 6 + 8 | 8 + 10 | 8 ### dom0\_mem (ia64) > `= ` diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c index b3c5d4c..5407f8d 100644 --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -83,7 +83,24 @@ static void __init parse_dom0_mem(const char *s) custom_param("dom0_mem", parse_dom0_mem); static unsigned int __initdata opt_dom0_max_vcpus; -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; + +static void __init parse_dom0_max_vcpus(const char *s) +{ + do { + if ( !strncmp(s, "min:", 4) ) + opt_dom0_max_vcpus_min = simple_strtoul(s+4, &s, 0); + else if ( !strncmp(s, "max:", 4) ) + opt_dom0_max_vcpus_max = simple_strtoul(s+4, &s, 0); + else + opt_dom0_max_vcpus = simple_strtoul(s, &s, 0); + if ( *s != ',' ) + break; + } while ( *s++ == ',' ); + +} +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); struct vcpu *__init alloc_dom0_vcpu0(void) { @@ -91,6 +108,10 @@ struct vcpu *__init alloc_dom0_vcpu0(void) opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) opt_dom0_max_vcpus = MAX_VIRT_CPUS; + if ( opt_dom0_max_vcpus_min > opt_dom0_max_vcpus ) + opt_dom0_max_vcpus = opt_dom0_max_vcpus_min; + if ( opt_dom0_max_vcpus_max < opt_dom0_max_vcpus ) + opt_dom0_max_vcpus = opt_dom0_max_vcpus_max; dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); if ( !dom0->vcpu ) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:02:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQKxB-0002Uq-PR; Fri, 04 May 2012 16:01:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKx9-0002Ui-Sv for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:01:56 +0000 Received: from [85.158.138.51:61182] by server-3.bemta-3.messagelabs.com id F7/81-04048-37DF3AF4; Fri, 04 May 2012 16:01:55 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336147314!25336408!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21181 invoked from network); 4 May 2012 16:01:54 -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; 4 May 2012 16:01:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12303701" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16: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; Fri, 4 May 2012 17:01:53 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQKx7-0002nf-Ju; Fri, 04 May 2012 16:01:53 +0000 From: David Vrabel To: Date: Fri, 4 May 2012 17:01:41 +0100 Message-ID: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel , Jan Beulich Subject: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The dom0_max_vcpus command line option only allows the exact number of VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs but no more than the number physically present." Add min: and max: prefixes to the option to set a minimum number of VCPUs, and a maximum which does not exceed the number of PCPUs. For example, with "dom0_max_vcpus=min:4,max:8": PCPUs Dom0 VCPUs 2 4 4 4 6 6 8 8 10 8 The existing behaviour of "dom0_max_vcpus=N" still works as before. Signed-off-by: David Vrabel --- docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++++++++-- xen/arch/x86/domain_build.c | 23 ++++++++++++++++++++++- 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index a6195f2..5f0c2cd 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -272,10 +272,35 @@ Specify the bit width of the DMA heap. ### dom0\_ioports\_disable ### dom0\_max\_vcpus + +Either: + > `= ` -Specify the maximum number of vcpus to give to dom0. This defaults -to the number of pcpus on the host. +The maximum number of VCPUs to give to dom0. This number of VCPUs can +be more than the number of PCPUs on the host. The default is the +number of PCPUs. + +Or: + +> `= List of ( min: | max: )` + +With the `min:` option dom0 will have at least this minimum number of +VCPUs (default: 1). This may be more than the number of PCPUs on the +host. + +With the `max:` option dom0 will have a VCPUs for each PCPUs but no +more than this maximum number (default: unlimited). + +For example, with `dom0_max_vcpus=min:4,max:8`: + + Number of + PCPUs | Dom0 VCPUs + 2 | 4 + 4 | 4 + 6 | 6 + 8 | 8 + 10 | 8 ### dom0\_mem (ia64) > `= ` diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c index b3c5d4c..5407f8d 100644 --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -83,7 +83,24 @@ static void __init parse_dom0_mem(const char *s) custom_param("dom0_mem", parse_dom0_mem); static unsigned int __initdata opt_dom0_max_vcpus; -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; + +static void __init parse_dom0_max_vcpus(const char *s) +{ + do { + if ( !strncmp(s, "min:", 4) ) + opt_dom0_max_vcpus_min = simple_strtoul(s+4, &s, 0); + else if ( !strncmp(s, "max:", 4) ) + opt_dom0_max_vcpus_max = simple_strtoul(s+4, &s, 0); + else + opt_dom0_max_vcpus = simple_strtoul(s, &s, 0); + if ( *s != ',' ) + break; + } while ( *s++ == ',' ); + +} +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); struct vcpu *__init alloc_dom0_vcpu0(void) { @@ -91,6 +108,10 @@ struct vcpu *__init alloc_dom0_vcpu0(void) opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) opt_dom0_max_vcpus = MAX_VIRT_CPUS; + if ( opt_dom0_max_vcpus_min > opt_dom0_max_vcpus ) + opt_dom0_max_vcpus = opt_dom0_max_vcpus_min; + if ( opt_dom0_max_vcpus_max < opt_dom0_max_vcpus ) + opt_dom0_max_vcpus = opt_dom0_max_vcpus_max; dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); if ( !dom0->vcpu ) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:03:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKyH-0002fh-7e; Fri, 04 May 2012 16:03:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKyG-0002fV-EN for xen-devel@lists.xen.org; Fri, 04 May 2012 16:03:04 +0000 Received: from [85.158.139.83:22193] by server-5.bemta-5.messagelabs.com id B6/C6-13566-7BDF3AF4; Fri, 04 May 2012 16:03:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336147381!26805302!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29845 invoked from network); 4 May 2012 16:03:02 -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; 4 May 2012 16:03:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 17:03:00 +0100 Message-Id: <4FA419D30200007800081BE8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 17:02:59 +0100 From: "Jan Beulich" To: "Christian Tramnitz" References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 17:49, Christian Tramnitz wrote: > Ian Campbell citrix.com> writes: >> AFAIK it is going to be an (experimental) feature in 4.2. > > Short follow-up: I haven't tried with Hyper-V yet, but on current (today's > unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, but > during load ESXi 5u1 crashes and Xen log shows: > > (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. > (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. > > > Does anyone have an idea what MSR 485 does? It is not documented in "Intel > 64 and IA-32 Architectures Software Developer's Manual"... xen/include/asm-x86/msr-index.h says #define MSR_IA32_VMX_MISC 0x485 Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:03:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 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 ) id 1SQKyH-0002fh-7e; Fri, 04 May 2012 16:03:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQKyG-0002fV-EN for xen-devel@lists.xen.org; Fri, 04 May 2012 16:03:04 +0000 Received: from [85.158.139.83:22193] by server-5.bemta-5.messagelabs.com id B6/C6-13566-7BDF3AF4; Fri, 04 May 2012 16:03:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336147381!26805302!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29845 invoked from network); 4 May 2012 16:03:02 -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; 4 May 2012 16:03:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 17:03:00 +0100 Message-Id: <4FA419D30200007800081BE8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 17:02:59 +0100 From: "Jan Beulich" To: "Christian Tramnitz" References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 17:49, Christian Tramnitz wrote: > Ian Campbell citrix.com> writes: >> AFAIK it is going to be an (experimental) feature in 4.2. > > Short follow-up: I haven't tried with Hyper-V yet, but on current (today's > unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, but > during load ESXi 5u1 crashes and Xen log shows: > > (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. > (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. > > > Does anyone have an idea what MSR 485 does? It is not documented in "Intel > 64 and IA-32 Architectures Software Developer's Manual"... xen/include/asm-x86/msr-index.h says #define MSR_IA32_VMX_MISC 0x485 Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:06:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:06:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL0w-0002x9-VC; Fri, 04 May 2012 16:05:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL0v-0002x0-2S for xen-devel@lists.xen.org; Fri, 04 May 2012 16:05:49 +0000 Received: from [85.158.143.35:15986] by server-2.bemta-4.messagelabs.com id B6/70-17550-C5EF3AF4; Fri, 04 May 2012 16:05:48 +0000 X-Env-Sender: jwestfall@surrealistic.net X-Msg-Ref: server-14.tower-21.messagelabs.com!1336147545!14181569!1 X-Originating-IP: [75.151.103.193] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5401 invoked from network); 4 May 2012 16:05:46 -0000 Received: from whipper.surrealistic.net (HELO whipper.surrealistic.net) (75.151.103.193) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 16:05:46 -0000 Received: from jwestfall by whipper.surrealistic.net with local (Exim 4.69) (envelope-from ) id 1SQL07-0005eY-C6; Fri, 04 May 2012 09:04:59 -0700 Date: Fri, 4 May 2012 09:04:59 -0700 From: Jim Westfall To: Jan Beulich Message-ID: <20120504160459.GX5985@surrealistic.net> References: <20120502185402.GV5985@surrealistic.net> <4FA3BD2602000078000818F7@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA3BD2602000078000818F7@nat28.tlf.novell.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich wrote [05.04.12]: > >>> On 02.05.12 at 20:54, Jim Westfall wrote: > > The summary is that when gcc compiles something with -mfma4 it also > > enables the use of the avx instruction set. Since by default xen > > disables avx it leads to invalid opcodes. > > Not that I know of, at least not anymore in current -unstable. > > > This ends up being kinda nasty with the multiarch glibc since its doing > > stuff like > > > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) > > The question is what (runtime) tests HAS_FMA includes. I know that > some glibc versions had a broken AVX check (which only checked for > the AVX feature flag, while the specification explicitly states that > a prerequisite check of the OSXSAVE feature flag is also necessary). Its just a basic cpuid() call and seeing if the FMA4 bit is set. I will bug the glibc guys. Thanks for the feedback. jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:06:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:06:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL0w-0002x9-VC; Fri, 04 May 2012 16:05:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL0v-0002x0-2S for xen-devel@lists.xen.org; Fri, 04 May 2012 16:05:49 +0000 Received: from [85.158.143.35:15986] by server-2.bemta-4.messagelabs.com id B6/70-17550-C5EF3AF4; Fri, 04 May 2012 16:05:48 +0000 X-Env-Sender: jwestfall@surrealistic.net X-Msg-Ref: server-14.tower-21.messagelabs.com!1336147545!14181569!1 X-Originating-IP: [75.151.103.193] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5401 invoked from network); 4 May 2012 16:05:46 -0000 Received: from whipper.surrealistic.net (HELO whipper.surrealistic.net) (75.151.103.193) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 4 May 2012 16:05:46 -0000 Received: from jwestfall by whipper.surrealistic.net with local (Exim 4.69) (envelope-from ) id 1SQL07-0005eY-C6; Fri, 04 May 2012 09:04:59 -0700 Date: Fri, 4 May 2012 09:04:59 -0700 From: Jim Westfall To: Jan Beulich Message-ID: <20120504160459.GX5985@surrealistic.net> References: <20120502185402.GV5985@surrealistic.net> <4FA3BD2602000078000818F7@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA3BD2602000078000818F7@nat28.tlf.novell.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] fma4/avx under xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich wrote [05.04.12]: > >>> On 02.05.12 at 20:54, Jim Westfall wrote: > > The summary is that when gcc compiles something with -mfma4 it also > > enables the use of the avx instruction set. Since by default xen > > disables avx it leads to invalid opcodes. > > Not that I know of, at least not anymore in current -unstable. > > > This ends up being kinda nasty with the multiarch glibc since its doing > > stuff like > > > > (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func())) > > The question is what (runtime) tests HAS_FMA includes. I know that > some glibc versions had a broken AVX check (which only checked for > the AVX feature flag, while the specification explicitly states that > a prerequisite check of the OSXSAVE feature flag is also necessary). Its just a basic cpuid() call and seeing if the FMA4 bit is set. I will bug the glibc guys. Thanks for the feedback. jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:12:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQL72-0003BM-QC; Fri, 04 May 2012 16:12:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL70-0003BH-MZ for xen-devel@lists.xen.org; Fri, 04 May 2012 16:12:06 +0000 Received: from [85.158.139.83:18387] by server-8.bemta-5.messagelabs.com id 6E/74-26964-5DFF3AF4; Fri, 04 May 2012 16:12:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336147923!19579185!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14911 invoked from network); 4 May 2012 16:12:04 -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 May 2012 16:12:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 17:12:02 +0100 Message-Id: <4FA41BF20200007800081BFE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 17:12:02 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 18:01, David Vrabel wrote: > From: David Vrabel > > The dom0_max_vcpus command line option only allows the exact number of > VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs > but no more than the number physically present." > > Add min: and max: prefixes to the option to set a minimum number of > VCPUs, and a maximum which does not exceed the number of PCPUs. > > For example, with "dom0_max_vcpus=min:4,max:8": Both "...max...=min:..." and "...max...=max:" look pretty odd to me; how about simply allowing a range along with a simple number (since negative values make no sense, omitting either side of the range would be supportable if necessary. > PCPUs Dom0 VCPUs > 2 4 > 4 4 > 6 6 > 8 8 > 10 8 > > The existing behaviour of "dom0_max_vcpus=N" still works as before. > > Signed-off-by: David Vrabel > --- > docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++++++++-- > xen/arch/x86/domain_build.c | 23 ++++++++++++++++++++++- > 2 files changed, 49 insertions(+), 3 deletions(-) > > diff --git a/docs/misc/xen-command-line.markdown > b/docs/misc/xen-command-line.markdown > index a6195f2..5f0c2cd 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -272,10 +272,35 @@ Specify the bit width of the DMA heap. > > ### dom0\_ioports\_disable > ### dom0\_max\_vcpus > + > +Either: > + > > `= ` > > -Specify the maximum number of vcpus to give to dom0. This defaults > -to the number of pcpus on the host. > +The maximum number of VCPUs to give to dom0. This number of VCPUs can > +be more than the number of PCPUs on the host. The default is the > +number of PCPUs. > + > +Or: > + > +> `= List of ( min: | max: )` > + > +With the `min:` option dom0 will have at least this minimum number of > +VCPUs (default: 1). This may be more than the number of PCPUs on the > +host. > + > +With the `max:` option dom0 will have a VCPUs for each PCPUs but no > +more than this maximum number (default: unlimited). > + > +For example, with `dom0_max_vcpus=min:4,max:8`: > + > + Number of > + PCPUs | Dom0 VCPUs > + 2 | 4 > + 4 | 4 > + 6 | 6 > + 8 | 8 > + 10 | 8 > > ### dom0\_mem (ia64) > > `= ` > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c > index b3c5d4c..5407f8d 100644 > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -83,7 +83,24 @@ static void __init parse_dom0_mem(const char *s) > custom_param("dom0_mem", parse_dom0_mem); > > static unsigned int __initdata opt_dom0_max_vcpus; > -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; > +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; > + > +static void __init parse_dom0_max_vcpus(const char *s) > +{ > + do { > + if ( !strncmp(s, "min:", 4) ) > + opt_dom0_max_vcpus_min = simple_strtoul(s+4, &s, 0); > + else if ( !strncmp(s, "max:", 4) ) > + opt_dom0_max_vcpus_max = simple_strtoul(s+4, &s, 0); > + else > + opt_dom0_max_vcpus = simple_strtoul(s, &s, 0); > + if ( *s != ',' ) > + break; > + } while ( *s++ == ',' ); > + > +} > +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); > > struct vcpu *__init alloc_dom0_vcpu0(void) > { > @@ -91,6 +108,10 @@ struct vcpu *__init alloc_dom0_vcpu0(void) > opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); > if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) > opt_dom0_max_vcpus = MAX_VIRT_CPUS; > + if ( opt_dom0_max_vcpus_min > opt_dom0_max_vcpus ) > + opt_dom0_max_vcpus = opt_dom0_max_vcpus_min; Enlarging the value after the MAX_VIRT_CPUS range check must not be done. You probably simply want to move your addition up two lines. > + if ( opt_dom0_max_vcpus_max < opt_dom0_max_vcpus ) > + opt_dom0_max_vcpus = opt_dom0_max_vcpus_max; But please avoid ...=max: (number lost for some reason) rendering the box unbootable (I'd say a maximum of zero should be interpreted as 1). Jan > > dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); > if ( !dom0->vcpu ) > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:12:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQL72-0003BM-QC; Fri, 04 May 2012 16:12:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL70-0003BH-MZ for xen-devel@lists.xen.org; Fri, 04 May 2012 16:12:06 +0000 Received: from [85.158.139.83:18387] by server-8.bemta-5.messagelabs.com id 6E/74-26964-5DFF3AF4; Fri, 04 May 2012 16:12:05 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336147923!19579185!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14911 invoked from network); 4 May 2012 16:12:04 -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 May 2012 16:12:04 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 04 May 2012 17:12:02 +0100 Message-Id: <4FA41BF20200007800081BFE@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 04 May 2012 17:12:02 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> In-Reply-To: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 18:01, David Vrabel wrote: > From: David Vrabel > > The dom0_max_vcpus command line option only allows the exact number of > VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs > but no more than the number physically present." > > Add min: and max: prefixes to the option to set a minimum number of > VCPUs, and a maximum which does not exceed the number of PCPUs. > > For example, with "dom0_max_vcpus=min:4,max:8": Both "...max...=min:..." and "...max...=max:" look pretty odd to me; how about simply allowing a range along with a simple number (since negative values make no sense, omitting either side of the range would be supportable if necessary. > PCPUs Dom0 VCPUs > 2 4 > 4 4 > 6 6 > 8 8 > 10 8 > > The existing behaviour of "dom0_max_vcpus=N" still works as before. > > Signed-off-by: David Vrabel > --- > docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++++++++-- > xen/arch/x86/domain_build.c | 23 ++++++++++++++++++++++- > 2 files changed, 49 insertions(+), 3 deletions(-) > > diff --git a/docs/misc/xen-command-line.markdown > b/docs/misc/xen-command-line.markdown > index a6195f2..5f0c2cd 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -272,10 +272,35 @@ Specify the bit width of the DMA heap. > > ### dom0\_ioports\_disable > ### dom0\_max\_vcpus > + > +Either: > + > > `= ` > > -Specify the maximum number of vcpus to give to dom0. This defaults > -to the number of pcpus on the host. > +The maximum number of VCPUs to give to dom0. This number of VCPUs can > +be more than the number of PCPUs on the host. The default is the > +number of PCPUs. > + > +Or: > + > +> `= List of ( min: | max: )` > + > +With the `min:` option dom0 will have at least this minimum number of > +VCPUs (default: 1). This may be more than the number of PCPUs on the > +host. > + > +With the `max:` option dom0 will have a VCPUs for each PCPUs but no > +more than this maximum number (default: unlimited). > + > +For example, with `dom0_max_vcpus=min:4,max:8`: > + > + Number of > + PCPUs | Dom0 VCPUs > + 2 | 4 > + 4 | 4 > + 6 | 6 > + 8 | 8 > + 10 | 8 > > ### dom0\_mem (ia64) > > `= ` > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c > index b3c5d4c..5407f8d 100644 > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -83,7 +83,24 @@ static void __init parse_dom0_mem(const char *s) > custom_param("dom0_mem", parse_dom0_mem); > > static unsigned int __initdata opt_dom0_max_vcpus; > -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; > +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; > + > +static void __init parse_dom0_max_vcpus(const char *s) > +{ > + do { > + if ( !strncmp(s, "min:", 4) ) > + opt_dom0_max_vcpus_min = simple_strtoul(s+4, &s, 0); > + else if ( !strncmp(s, "max:", 4) ) > + opt_dom0_max_vcpus_max = simple_strtoul(s+4, &s, 0); > + else > + opt_dom0_max_vcpus = simple_strtoul(s, &s, 0); > + if ( *s != ',' ) > + break; > + } while ( *s++ == ',' ); > + > +} > +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); > > struct vcpu *__init alloc_dom0_vcpu0(void) > { > @@ -91,6 +108,10 @@ struct vcpu *__init alloc_dom0_vcpu0(void) > opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); > if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) > opt_dom0_max_vcpus = MAX_VIRT_CPUS; > + if ( opt_dom0_max_vcpus_min > opt_dom0_max_vcpus ) > + opt_dom0_max_vcpus = opt_dom0_max_vcpus_min; Enlarging the value after the MAX_VIRT_CPUS range check must not be done. You probably simply want to move your addition up two lines. > + if ( opt_dom0_max_vcpus_max < opt_dom0_max_vcpus ) > + opt_dom0_max_vcpus = opt_dom0_max_vcpus_max; But please avoid ...=max: (number lost for some reason) rendering the box unbootable (I'd say a maximum of zero should be interpreted as 1). Jan > > dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); > if ( !dom0->vcpu ) > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:12:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:12:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL7F-0003CB-66; Fri, 04 May 2012 16:12:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL7E-0003C2-Ao for xen-devel@lists.xen.org; Fri, 04 May 2012 16:12:20 +0000 Received: from [85.158.143.99:35518] by server-3.bemta-4.messagelabs.com id 09/48-05853-3EFF3AF4; Fri, 04 May 2012 16:12:19 +0000 X-Env-Sender: jun.nakajima@intel.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336147937!21258025!1 X-Originating-IP: [143.182.124.22] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8587 invoked from network); 4 May 2012 16:12:18 -0000 Received: from mga07.intel.com (HELO azsmga101.ch.intel.com) (143.182.124.22) by server-4.tower-216.messagelabs.com with SMTP; 4 May 2012 16:12:18 -0000 Received: from mail-bk0-f52.google.com ([209.85.214.52]) by mga03.intel.com with ESMTP/TLS/RC4-SHA; 04 May 2012 09:12:16 -0700 Received: by bkcjc3 with SMTP id jc3so2392323bkc.25 for ; Fri, 04 May 2012 09:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QNHuzyu9/5AQUJtCFjw0xmwDXpphaqdsPJM7IAWhSDI=; b=RJnoSipYyovE9BQdbH+JCSdblouk3L3xUYSUwT2g5Hi3hqhZpkFLCvz85FArjvQUCf 37+u7z2sCYuDm7x/PtR38aqDFzv9KZ+mXw+5Fhe22kpavuL1iJiOvTEVQuRV+6+uyn2X Gl1MRBDazqPmbiuvE6eVW4U0ig/H1qxW+s1/quZo4eE47FGBSjHojGtEL96IomUfIrm1 ZnQ0toAG2CcqNe9j2LYxKHPZw1s5XwGDUxRap4xS7ZgKZPIyCp8iO71PIaMXNf4J7HSJ Ht8Pt52XPNH35VgFU1GO/cOhKlNhU2/Xphn0fRZb+dgA5x75+/H8kbt5s1fAeGmKt1xk Bm9g== MIME-Version: 1.0 Received: by 10.204.151.200 with SMTP id d8mr2446253bkw.82.1336147934774; Fri, 04 May 2012 09:12:14 -0700 (PDT) Received: by 10.204.171.10 with HTTP; Fri, 4 May 2012 09:12:14 -0700 (PDT) In-Reply-To: <4FA419D30200007800081BE8@nat28.tlf.novell.com> References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> <4FA419D30200007800081BE8@nat28.tlf.novell.com> Date: Fri, 4 May 2012 09:12:14 -0700 Message-ID: From: "Nakajima, Jun" To: Jan Beulich X-Gm-Message-State: ALoCoQnhVHOzyHG5efJTLi/0qZCyM9A0QfVOUKqAAz0K3mR2gRe+xRB3SK9foxethoh9Wif7EIx4 Cc: Christian Tramnitz , xen-devel Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8263549427243016779==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8263549427243016779== Content-Type: multipart/alternative; boundary=0015175cba8405044b04bf382f4a --0015175cba8405044b04bf382f4a Content-Type: text/plain; charset=ISO-8859-1 And it's documented in A.6 (Appendix A). A.6 MISCELLANEOUS DATA The IA32_VMX_MISC MSR (index 485H) consists of the following fields: ... On Fri, May 4, 2012 at 9:02 AM, Jan Beulich wrote: > >>> On 04.05.12 at 17:49, Christian Tramnitz wrote: > > Ian Campbell citrix.com> writes: > >> AFAIK it is going to be an (experimental) feature in 4.2. > > > > Short follow-up: I haven't tried with Hyper-V yet, but on current > (today's > > unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, > but > > during load ESXi 5u1 crashes and Xen log shows: > > > > (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. > > (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. > > > > > > Does anyone have an idea what MSR 485 does? It is not documented in > "Intel > > 64 and IA-32 Architectures Software Developer's Manual"... > > xen/include/asm-x86/msr-index.h says > > #define MSR_IA32_VMX_MISC 0x485 > > Jan > > -- Jun Intel Open Source Technology Center --0015175cba8405044b04bf382f4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And it's documented in A.6 (Appendix A).

A.6 MISCELLA= NEOUS DATA
The IA32_VMX_MISC MSR (index 485H) consists of the fol= lowing fields:
...


On Fri, May 4, 2012 at 9:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 04.05.12 at 17:49, Christian Tramnitz <= ;chris.ace@gmx.net> wrote:
> Ian Campbell <Ian.Campbell <at> citrix.com> writes:
>> AFAIK it is going to be an (experimental) feature in 4.2.
>
> Short follow-up: I haven't tried with Hyper-V yet, but on current = (today's
> unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible,= but
> during load ESXi 5u1 crashes and Xen log shows:
>
> (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet.
> (XEN) hvm.c:1143:d8 All CPUs offline -- powering off.
>
>
> Does anyone have an idea what MSR 485 does? It is not documented in &q= uot;Intel
> 64 and IA-32 Architectures Software Developer's Manual"...
xen/include/asm-x86/msr-index.h says

#define MSR_IA32_VMX_MISC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x485=

Jan

--
Jun
Inte= l Open Source Technology Center

--0015175cba8405044b04bf382f4a-- --===============8263549427243016779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8263549427243016779==-- From xen-devel-bounces@lists.xen.org Fri May 04 16:12:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:12:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL7F-0003CB-66; Fri, 04 May 2012 16:12:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQL7E-0003C2-Ao for xen-devel@lists.xen.org; Fri, 04 May 2012 16:12:20 +0000 Received: from [85.158.143.99:35518] by server-3.bemta-4.messagelabs.com id 09/48-05853-3EFF3AF4; Fri, 04 May 2012 16:12:19 +0000 X-Env-Sender: jun.nakajima@intel.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336147937!21258025!1 X-Originating-IP: [143.182.124.22] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8587 invoked from network); 4 May 2012 16:12:18 -0000 Received: from mga07.intel.com (HELO azsmga101.ch.intel.com) (143.182.124.22) by server-4.tower-216.messagelabs.com with SMTP; 4 May 2012 16:12:18 -0000 Received: from mail-bk0-f52.google.com ([209.85.214.52]) by mga03.intel.com with ESMTP/TLS/RC4-SHA; 04 May 2012 09:12:16 -0700 Received: by bkcjc3 with SMTP id jc3so2392323bkc.25 for ; Fri, 04 May 2012 09:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QNHuzyu9/5AQUJtCFjw0xmwDXpphaqdsPJM7IAWhSDI=; b=RJnoSipYyovE9BQdbH+JCSdblouk3L3xUYSUwT2g5Hi3hqhZpkFLCvz85FArjvQUCf 37+u7z2sCYuDm7x/PtR38aqDFzv9KZ+mXw+5Fhe22kpavuL1iJiOvTEVQuRV+6+uyn2X Gl1MRBDazqPmbiuvE6eVW4U0ig/H1qxW+s1/quZo4eE47FGBSjHojGtEL96IomUfIrm1 ZnQ0toAG2CcqNe9j2LYxKHPZw1s5XwGDUxRap4xS7ZgKZPIyCp8iO71PIaMXNf4J7HSJ Ht8Pt52XPNH35VgFU1GO/cOhKlNhU2/Xphn0fRZb+dgA5x75+/H8kbt5s1fAeGmKt1xk Bm9g== MIME-Version: 1.0 Received: by 10.204.151.200 with SMTP id d8mr2446253bkw.82.1336147934774; Fri, 04 May 2012 09:12:14 -0700 (PDT) Received: by 10.204.171.10 with HTTP; Fri, 4 May 2012 09:12:14 -0700 (PDT) In-Reply-To: <4FA419D30200007800081BE8@nat28.tlf.novell.com> References: <1334591061.14560.213.camel@zakaz.uk.xensource.com> <4FA419D30200007800081BE8@nat28.tlf.novell.com> Date: Fri, 4 May 2012 09:12:14 -0700 Message-ID: From: "Nakajima, Jun" To: Jan Beulich X-Gm-Message-State: ALoCoQnhVHOzyHG5efJTLi/0qZCyM9A0QfVOUKqAAz0K3mR2gRe+xRB3SK9foxethoh9Wif7EIx4 Cc: Christian Tramnitz , xen-devel Subject: Re: [Xen-devel] Status of nestedhvm (on Intel) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8263549427243016779==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8263549427243016779== Content-Type: multipart/alternative; boundary=0015175cba8405044b04bf382f4a --0015175cba8405044b04bf382f4a Content-Type: text/plain; charset=ISO-8859-1 And it's documented in A.6 (Appendix A). A.6 MISCELLANEOUS DATA The IA32_VMX_MISC MSR (index 485H) consists of the following fields: ... On Fri, May 4, 2012 at 9:02 AM, Jan Beulich wrote: > >>> On 04.05.12 at 17:49, Christian Tramnitz wrote: > > Ian Campbell citrix.com> writes: > >> AFAIK it is going to be an (experimental) feature in 4.2. > > > > Short follow-up: I haven't tried with Hyper-V yet, but on current > (today's > > unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible, > but > > during load ESXi 5u1 crashes and Xen log shows: > > > > (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet. > > (XEN) hvm.c:1143:d8 All CPUs offline -- powering off. > > > > > > Does anyone have an idea what MSR 485 does? It is not documented in > "Intel > > 64 and IA-32 Architectures Software Developer's Manual"... > > xen/include/asm-x86/msr-index.h says > > #define MSR_IA32_VMX_MISC 0x485 > > Jan > > -- Jun Intel Open Source Technology Center --0015175cba8405044b04bf382f4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And it's documented in A.6 (Appendix A).

A.6 MISCELLA= NEOUS DATA
The IA32_VMX_MISC MSR (index 485H) consists of the fol= lowing fields:
...


On Fri, May 4, 2012 at 9:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 04.05.12 at 17:49, Christian Tramnitz <= ;chris.ace@gmx.net> wrote:
> Ian Campbell <Ian.Campbell <at> citrix.com> writes:
>> AFAIK it is going to be an (experimental) feature in 4.2.
>
> Short follow-up: I haven't tried with Hyper-V yet, but on current = (today's
> unstable.hg) Xen 4.2 at least ESXi does not work. VMX flag is visible,= but
> during load ESXi 5u1 crashes and Xen log shows:
>
> (XEN) vvmx.c:1366:d8 VMX MSR 485 not fully supported yet.
> (XEN) hvm.c:1143:d8 All CPUs offline -- powering off.
>
>
> Does anyone have an idea what MSR 485 does? It is not documented in &q= uot;Intel
> 64 and IA-32 Architectures Software Developer's Manual"...
xen/include/asm-x86/msr-index.h says

#define MSR_IA32_VMX_MISC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x485=

Jan

--
Jun
Inte= l Open Source Technology Center

--0015175cba8405044b04bf382f4a-- --===============8263549427243016779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8263549427243016779==-- From xen-devel-bounces@lists.xen.org Fri May 04 16:16:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLBP-0003SD-TW; Fri, 04 May 2012 16:16:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLBO-0003S5-Ur for xen-devel@lists.xen.org; Fri, 04 May 2012 16:16:39 +0000 Received: from [193.109.254.147:12848] by server-2.bemta-14.messagelabs.com id C3/F2-19409-6E004AF4; Fri, 04 May 2012 16:16:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336148197!7662416!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12469 invoked from network); 4 May 2012 16:16:37 -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; 4 May 2012 16:16:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304073" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:16: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, 4 May 2012 17:16:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLBM-0002t9-Vn; Fri, 04 May 2012 16:16:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLBM-00028e-Ta; Fri, 04 May 2012 17:16:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.225.953974.833538@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:16:33 +0100 To: wang zhihao In-Reply-To: <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> <20387.46595.198406.571329@mariner.uk.xensource.com> <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org d2FuZyB6aGloYW8gd3JpdGVzICgiUmU6IEhvdyB0byBzZWxlY3QgYSByb290ZnMgdG8gdGVzdCBq b2IgdGVzdC1hbWQ2NC1hbWQ2NC14bCBvbiBteSBvd24gbWFjaGluZSA/Iik6Cj4g5ZyoIDIwMTIt NS0077yM5LiL5Y2INjo1N++8jCBJYW4gSmFja3NvbiDlhpnpgZPvvJoKPiA+IFlvdSBtZWFuIGhv dyBkb2VzIHRoZSBndWVzdCBnZXQgY3JlYXRlZCA/Cj4gCj4gSSBtZWFuIGhvdyB0byBzZWxlY3Qg dGhlIGRvbTAncyByb290IGZpbGVzeXN0ZW0uCgpUaGUgZG9tMCBpcyBhIGZhaXJseSBub3JtYWwg bmV0d29yayBhdXRvaW5zdGFsbCBvZiBEZWJpYW4gc3F1ZWV6ZS4gIElmCnlvdSBsb29rIGF0ICJ0 cy14ZW4taW5zdGFsbCIgeW91J2xsIHNlZSB0aGUgc3RlcHMgdGhlIHRlc3Qgc3lzdGVtIGRvZXMK dG8gZHJvcCB0aGUgaHlwZXJ2aXNvciBhbmQga2VybmVsIGluIHBsYWNlIGFuZCByZWNvbmZpZ3Vy ZSB0aGUKYm9vdGxvYWRlciBldGMuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri May 04 16:16:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLBP-0003SD-TW; Fri, 04 May 2012 16:16:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLBO-0003S5-Ur for xen-devel@lists.xen.org; Fri, 04 May 2012 16:16:39 +0000 Received: from [193.109.254.147:12848] by server-2.bemta-14.messagelabs.com id C3/F2-19409-6E004AF4; Fri, 04 May 2012 16:16:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336148197!7662416!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12469 invoked from network); 4 May 2012 16:16:37 -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; 4 May 2012 16:16:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304073" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:16: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, 4 May 2012 17:16:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLBM-0002t9-Vn; Fri, 04 May 2012 16:16:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLBM-00028e-Ta; Fri, 04 May 2012 17:16:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.225.953974.833538@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:16:33 +0100 To: wang zhihao In-Reply-To: <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> References: <15C5FE97-8363-4266-97FC-4C86A7025DC2@gmail.com> <20387.46595.198406.571329@mariner.uk.xensource.com> <4D66E26E-05BF-4DE4-9162-F719368F1529@gmail.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel Subject: Re: [Xen-devel] How to select a rootfs to test job test-amd64-amd64-xl on my own machine ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org d2FuZyB6aGloYW8gd3JpdGVzICgiUmU6IEhvdyB0byBzZWxlY3QgYSByb290ZnMgdG8gdGVzdCBq b2IgdGVzdC1hbWQ2NC1hbWQ2NC14bCBvbiBteSBvd24gbWFjaGluZSA/Iik6Cj4g5ZyoIDIwMTIt NS0077yM5LiL5Y2INjo1N++8jCBJYW4gSmFja3NvbiDlhpnpgZPvvJoKPiA+IFlvdSBtZWFuIGhv dyBkb2VzIHRoZSBndWVzdCBnZXQgY3JlYXRlZCA/Cj4gCj4gSSBtZWFuIGhvdyB0byBzZWxlY3Qg dGhlIGRvbTAncyByb290IGZpbGVzeXN0ZW0uCgpUaGUgZG9tMCBpcyBhIGZhaXJseSBub3JtYWwg bmV0d29yayBhdXRvaW5zdGFsbCBvZiBEZWJpYW4gc3F1ZWV6ZS4gIElmCnlvdSBsb29rIGF0ICJ0 cy14ZW4taW5zdGFsbCIgeW91J2xsIHNlZSB0aGUgc3RlcHMgdGhlIHRlc3Qgc3lzdGVtIGRvZXMK dG8gZHJvcCB0aGUgaHlwZXJ2aXNvciBhbmQga2VybmVsIGluIHBsYWNlIGFuZCByZWNvbmZpZ3Vy ZSB0aGUKYm9vdGxvYWRlciBldGMuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri May 04 16:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLHc-0003h4-Pe; Fri, 04 May 2012 16:23:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLHa-0003gz-Uk for xen-devel@lists.xen.org; Fri, 04 May 2012 16:23:03 +0000 Received: from [85.158.139.83:19858] by server-7.bemta-5.messagelabs.com id DB/EB-16195-46204AF4; Fri, 04 May 2012 16:23:00 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336148579!26846390!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26650 invoked from network); 4 May 2012 16:22:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:22:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304162" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:22:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:22:58 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLHV-0002vR-Ta; Fri, 04 May 2012 16:22:57 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLHV-00029h-SR; Fri, 04 May 2012 17:22:57 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.609.866463.305037@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:22:57 +0100 To: Roger Pau Monne In-Reply-To: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> References: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[PATCH] libxl: set guest_domid even if libxl__domain_make fails"): > This is needed in order to perform the domain destruction if > libxl__domain_make fails. > ret = libxl__domain_make(gc, &d_config->c_info, &domid); > if (ret) { > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); > + dcs->guest_domid = domid; > ret = ERROR_FAIL; > goto error_out; This is a bit odd. The documentation for libxl__domain_make says: /* from xl_create */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); Yes, that's it. So apparently this function does actually create the domain on error ? Oh wait I see there is a doc comment but it's next to the definition. /* on entry, libxl_domid_valid_guest(domid) must be false; * on exit (even error exit), domid may be valid and refer to a domain */ So yes, that's correct. Acked-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLHc-0003h4-Pe; Fri, 04 May 2012 16:23:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLHa-0003gz-Uk for xen-devel@lists.xen.org; Fri, 04 May 2012 16:23:03 +0000 Received: from [85.158.139.83:19858] by server-7.bemta-5.messagelabs.com id DB/EB-16195-46204AF4; Fri, 04 May 2012 16:23:00 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336148579!26846390!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26650 invoked from network); 4 May 2012 16:22:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:22:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304162" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:22:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:22:58 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLHV-0002vR-Ta; Fri, 04 May 2012 16:22:57 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLHV-00029h-SR; Fri, 04 May 2012 17:22:57 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.609.866463.305037@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:22:57 +0100 To: Roger Pau Monne In-Reply-To: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> References: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[PATCH] libxl: set guest_domid even if libxl__domain_make fails"): > This is needed in order to perform the domain destruction if > libxl__domain_make fails. > ret = libxl__domain_make(gc, &d_config->c_info, &domid); > if (ret) { > LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); > + dcs->guest_domid = domid; > ret = ERROR_FAIL; > goto error_out; This is a bit odd. The documentation for libxl__domain_make says: /* from xl_create */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); Yes, that's it. So apparently this function does actually create the domain on error ? Oh wait I see there is a doc comment but it's next to the definition. /* on entry, libxl_domid_valid_guest(domid) must be false; * on exit (even error exit), domid may be valid and refer to a domain */ So yes, that's correct. Acked-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:26:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLL8-0003o3-Dj; Fri, 04 May 2012 16:26:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLL7-0003nv-CF for xen-devel@lists.xen.org; Fri, 04 May 2012 16:26:41 +0000 Received: from [193.109.254.147:30056] by server-7.bemta-14.messagelabs.com id 4C/07-01627-04304AF4; Fri, 04 May 2012 16:26:40 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336148796!7685218!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22033 invoked from network); 4 May 2012 16:26:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:26:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330923600"; d="scan'208";a="193451672" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 12:26:11 -0400 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, 4 May 2012 12:26:11 -0400 Message-ID: <4FA40321.3080201@citrix.com> Date: Fri, 4 May 2012 17:26:09 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> In-Reply-To: <4FA41BF20200007800081BFE@nat28.tlf.novell.com> Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 17:12, Jan Beulich wrote: >>>> On 04.05.12 at 18:01, David Vrabel wrote: >> From: David Vrabel >> >> The dom0_max_vcpus command line option only allows the exact number of >> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >> but no more than the number physically present." >> >> Add min: and max: prefixes to the option to set a minimum number of >> VCPUs, and a maximum which does not exceed the number of PCPUs. >> >> For example, with "dom0_max_vcpus=min:4,max:8": > > Both "...max...=min:..." and "...max...=max:" look pretty odd to me; > how about simply allowing a range along with a simple number (since > negative values make no sense, omitting either side of the range would > be supportable if necessary. I was copying the way dom0_mem worked but yeah, it's not very pretty. Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were thinking of? Using a single value would have to set both and or the behaviour of the option changes (i.e., =N is the same as =N-N). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:26:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLL8-0003o3-Dj; Fri, 04 May 2012 16:26:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLL7-0003nv-CF for xen-devel@lists.xen.org; Fri, 04 May 2012 16:26:41 +0000 Received: from [193.109.254.147:30056] by server-7.bemta-14.messagelabs.com id 4C/07-01627-04304AF4; Fri, 04 May 2012 16:26:40 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336148796!7685218!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22033 invoked from network); 4 May 2012 16:26:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:26:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330923600"; d="scan'208";a="193451672" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 12:26:11 -0400 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, 4 May 2012 12:26:11 -0400 Message-ID: <4FA40321.3080201@citrix.com> Date: Fri, 4 May 2012 17:26:09 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> In-Reply-To: <4FA41BF20200007800081BFE@nat28.tlf.novell.com> Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 17:12, Jan Beulich wrote: >>>> On 04.05.12 at 18:01, David Vrabel wrote: >> From: David Vrabel >> >> The dom0_max_vcpus command line option only allows the exact number of >> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >> but no more than the number physically present." >> >> Add min: and max: prefixes to the option to set a minimum number of >> VCPUs, and a maximum which does not exceed the number of PCPUs. >> >> For example, with "dom0_max_vcpus=min:4,max:8": > > Both "...max...=min:..." and "...max...=max:" look pretty odd to me; > how about simply allowing a range along with a simple number (since > negative values make no sense, omitting either side of the range would > be supportable if necessary. I was copying the way dom0_mem worked but yeah, it's not very pretty. Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were thinking of? Using a single value would have to set both and or the behaviour of the option changes (i.e., =N is the same as =N-N). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:27:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:27:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLLt-0003ra-RT; Fri, 04 May 2012 16:27:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLLs-0003rQ-Un for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:27:29 +0000 Received: from [85.158.138.51:22414] by server-5.bemta-3.messagelabs.com id 18/BD-17113-07304AF4; Fri, 04 May 2012 16:27:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336148847!14307995!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4099 invoked from network); 4 May 2012 16:27:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:27:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304222" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:27:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:27:26 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLLq-0002ws-Mb; Fri, 04 May 2012 16:27:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLLq-0002A0-LI; Fri, 04 May 2012 17:27:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.878.645214.92917@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:27:26 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-2-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"): > Introduce a new libxl_device_disk** parameter to > libxl__device_disk_local_attach, the parameter is allocated on the gc by > libxl__device_disk_local_attach. It is going to fill it with > informations about the new locally attached disk. The new > libxl_device_disk should be passed to libxl_device_disk_local_detach > afterwards. ... > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index fc771ff..55dc55c 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c ... > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - disk->pdev_path); > + in_disk->pdev_path); I think in_disk->pdev_path can be NULL here ? Also log messages should not contain "\n"; the logging functions add it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:27:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:27:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLLt-0003ra-RT; Fri, 04 May 2012 16:27:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLLs-0003rQ-Un for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:27:29 +0000 Received: from [85.158.138.51:22414] by server-5.bemta-3.messagelabs.com id 18/BD-17113-07304AF4; Fri, 04 May 2012 16:27:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336148847!14307995!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4099 invoked from network); 4 May 2012 16:27:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:27:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304222" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:27:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:27:26 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLLq-0002ws-Mb; Fri, 04 May 2012 16:27:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLLq-0002A0-LI; Fri, 04 May 2012 17:27:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.878.645214.92917@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:27:26 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-2-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-2-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 2/8] libxl: libxl__device_disk_local_attach return a new libxl_device_disk"): > Introduce a new libxl_device_disk** parameter to > libxl__device_disk_local_attach, the parameter is allocated on the gc by > libxl__device_disk_local_attach. It is going to fill it with > informations about the new locally attached disk. The new > libxl_device_disk should be passed to libxl_device_disk_local_detach > afterwards. ... > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index fc771ff..55dc55c 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c ... > LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching qdisk %s\n", > - disk->pdev_path); > + in_disk->pdev_path); I think in_disk->pdev_path can be NULL here ? Also log messages should not contain "\n"; the logging functions add it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:30:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:30:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLP2-00045f-Jd; Fri, 04 May 2012 16:30:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLP1-00045W-AC for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:30:43 +0000 Received: from [85.158.139.83:63803] by server-8.bemta-5.messagelabs.com id 8C/23-26964-23404AF4; Fri, 04 May 2012 16:30:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336149041!22538998!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9576 invoked from network); 4 May 2012 16:30:41 -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; 4 May 2012 16:30:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304259" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:30:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:30:40 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLOy-0002y6-JU; Fri, 04 May 2012 16:30:40 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLOy-0002AK-IV; Fri, 04 May 2012 17:30:40 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1072.555507.607949@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:30:40 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: <20374.51661.526651.289834@mariner.uk.xensource.com>, <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com> <20374.51661.526651.289834@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 4/8] libxl: introduce libxl__device_disk_add"): > Introduce libxl__device_disk_add that takes an additional > xs_transaction_t paramter. > Implement libxl_device_disk_add using libxl__device_disk_add. > Move libxl__device_from_disk to libxl_internal.c. > No functional change. The last time you posted this I wrote: Ian Jackson writes ("Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"): > Apart from that it's rather hard to review because this patch seems to > have an awful lot of code motion mixed up with other changes. Can you split the code motion out into a separate patch, so that we can see what has changed in the code that is being moved ? Also I think "no functional change" is stretching it a bit unless what you mean is "no callers of libxl__device_disk_add yet". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:30:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:30:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLP2-00045f-Jd; Fri, 04 May 2012 16:30:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLP1-00045W-AC for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:30:43 +0000 Received: from [85.158.139.83:63803] by server-8.bemta-5.messagelabs.com id 8C/23-26964-23404AF4; Fri, 04 May 2012 16:30:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336149041!22538998!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9576 invoked from network); 4 May 2012 16:30:41 -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; 4 May 2012 16:30:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304259" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:30:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:30:40 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLOy-0002y6-JU; Fri, 04 May 2012 16:30:40 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLOy-0002AK-IV; Fri, 04 May 2012 17:30:40 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1072.555507.607949@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:30:40 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: <20374.51661.526651.289834@mariner.uk.xensource.com>, <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-4-git-send-email-stefano.stabellini@eu.citrix.com> <1335264358-20182-4-git-send-email-stefano.stabellini@eu.citrix.com> <20374.51661.526651.289834@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com Subject: Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 4/8] libxl: introduce libxl__device_disk_add"): > Introduce libxl__device_disk_add that takes an additional > xs_transaction_t paramter. > Implement libxl_device_disk_add using libxl__device_disk_add. > Move libxl__device_from_disk to libxl_internal.c. > No functional change. The last time you posted this I wrote: Ian Jackson writes ("Re: [Xen-devel] [PATCH v4 4/8] libxl: introduce libxl__device_disk_add_t"): > Apart from that it's rather hard to review because this patch seems to > have an awful lot of code motion mixed up with other changes. Can you split the code motion out into a separate patch, so that we can see what has changed in the code that is being moved ? Also I think "no functional change" is stretching it a bit unless what you mean is "no callers of libxl__device_disk_add yet". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:33:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:33:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLRC-0004GN-58; Fri, 04 May 2012 16:32:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLRB-0004GF-25 for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:32:57 +0000 Received: from [85.158.143.99:15073] by server-1.bemta-4.messagelabs.com id EE/F1-20925-8B404AF4; Fri, 04 May 2012 16:32:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336149175!21288707!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27895 invoked from network); 4 May 2012 16:32:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:32:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304303" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:32: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, 4 May 2012 17:32:55 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLR9-0002yr-2o; Fri, 04 May 2012 16:32:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLR9-0002Af-1k; Fri, 04 May 2012 17:32:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1207.38715.51627@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:32:55 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 5/8] xl/libxl: add a blkdev_start parameter"): > + if (b_info->blkdev_start == NULL) > + b_info->blkdev_start = strdup("xvda"); This should be libxl__strdup(0, "xvda") to get the correct error behaviour. Aside from that, Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:33:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:33:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLRC-0004GN-58; Fri, 04 May 2012 16:32:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLRB-0004GF-25 for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:32:57 +0000 Received: from [85.158.143.99:15073] by server-1.bemta-4.messagelabs.com id EE/F1-20925-8B404AF4; Fri, 04 May 2012 16:32:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336149175!21288707!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27895 invoked from network); 4 May 2012 16:32:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 16:32:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304303" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:32: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, 4 May 2012 17:32:55 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLR9-0002yr-2o; Fri, 04 May 2012 16:32:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLR9-0002Af-1k; Fri, 04 May 2012 17:32:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1207.38715.51627@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:32:55 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-5-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 5/8] xl/libxl: add a blkdev_start parameter X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 5/8] xl/libxl: add a blkdev_start parameter"): > + if (b_info->blkdev_start == NULL) > + b_info->blkdev_start = strdup("xvda"); This should be libxl__strdup(0, "xvda") to get the correct error behaviour. Aside from that, Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:40:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLXn-0004cK-L8; Fri, 04 May 2012 16:39:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLXl-0004c0-EC for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:39:45 +0000 Received: from [193.109.254.147:2081] by server-9.bemta-14.messagelabs.com id 28/EE-05787-05604AF4; Fri, 04 May 2012 16:39:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336149584!862416!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17479 invoked from network); 4 May 2012 16:39:44 -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; 4 May 2012 16:39:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304445" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:39: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, 4 May 2012 17:39:43 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLXj-000315-Do; Fri, 04 May 2012 16:39:43 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLXj-0002BF-Cq; Fri, 04 May 2012 17:39:43 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1615.382752.914755@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:39:43 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-6-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > Introduce libxl__alloc_vdev: find a spare virtual block device in the > domain passed as argument. ... > + do { > + vdev = GCSPRINTF("d%dp0", disk); > + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); > + if (libxl__xs_read(gc, t, > + libxl__sprintf(gc, "%s/device/vbd/%d/backend", > + dompath, devid)) == NULL) { > + if (errno == ENOENT) > + return libxl__devid_to_localdev(gc, devid); > + else > + return NULL; > + } > + disk++; > + } while (disk <= (1 << 20)); This should be "<", as disk==(1<<20) is too big. And the magic number 20 should not be repeated. But it turns out that you don't need to do this check here at all because libxl__device_disk_dev_number will check this, correctly. All you need to do is actually pay attention to its error return. > + return NULL; All the NULL error exits should log an error surely. > +/* same as in Linux */ > +static char *encode_disk_name(char *ptr, unsigned int n) > +{ > + if (n >= 26) > + ptr = encode_disk_name(ptr, n / 26 - 1); > + *ptr = 'a' + n % 26; > + return ptr + 1; > +} This still makes it difficult to see that the buffer cannot be overrun. I mentioned this in response to a previous posting of this code and IIRC you were going to do something about it, if only a comment explaining what the maximum buffer length is and why it's safe. > + strcpy(ret, "xvd"); > + ptr = encode_disk_name(ret + 3, offset); > + if (minor % nr_parts == 0) > + *ptr = 0; > + else > + snprintf(ptr, ret + 32 - ptr, > + "%d", minor & (nr_parts - 1)); You do not handle snprintf buffer truncation sensibly here. As it happens I think this overflow cannot happen but this deserves a comment at the very least, to explain the lack of error handling. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:40:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16: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 ) id 1SQLXn-0004cK-L8; Fri, 04 May 2012 16:39:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLXl-0004c0-EC for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:39:45 +0000 Received: from [193.109.254.147:2081] by server-9.bemta-14.messagelabs.com id 28/EE-05787-05604AF4; Fri, 04 May 2012 16:39:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336149584!862416!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17479 invoked from network); 4 May 2012 16:39:44 -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; 4 May 2012 16:39:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304445" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:39: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, 4 May 2012 17:39:43 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLXj-000315-Do; Fri, 04 May 2012 16:39:43 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLXj-0002BF-Cq; Fri, 04 May 2012 17:39:43 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1615.382752.914755@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:39:43 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-6-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > Introduce libxl__alloc_vdev: find a spare virtual block device in the > domain passed as argument. ... > + do { > + vdev = GCSPRINTF("d%dp0", disk); > + devid = libxl__device_disk_dev_number(vdev, NULL, NULL); > + if (libxl__xs_read(gc, t, > + libxl__sprintf(gc, "%s/device/vbd/%d/backend", > + dompath, devid)) == NULL) { > + if (errno == ENOENT) > + return libxl__devid_to_localdev(gc, devid); > + else > + return NULL; > + } > + disk++; > + } while (disk <= (1 << 20)); This should be "<", as disk==(1<<20) is too big. And the magic number 20 should not be repeated. But it turns out that you don't need to do this check here at all because libxl__device_disk_dev_number will check this, correctly. All you need to do is actually pay attention to its error return. > + return NULL; All the NULL error exits should log an error surely. > +/* same as in Linux */ > +static char *encode_disk_name(char *ptr, unsigned int n) > +{ > + if (n >= 26) > + ptr = encode_disk_name(ptr, n / 26 - 1); > + *ptr = 'a' + n % 26; > + return ptr + 1; > +} This still makes it difficult to see that the buffer cannot be overrun. I mentioned this in response to a previous posting of this code and IIRC you were going to do something about it, if only a comment explaining what the maximum buffer length is and why it's safe. > + strcpy(ret, "xvd"); > + ptr = encode_disk_name(ret + 3, offset); > + if (minor % nr_parts == 0) > + *ptr = 0; > + else > + snprintf(ptr, ret + 32 - ptr, > + "%d", minor & (nr_parts - 1)); You do not handle snprintf buffer truncation sensibly here. As it happens I think this overflow cannot happen but this deserves a comment at the very least, to explain the lack of error handling. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:42:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:42:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLaT-0004qc-8E; Fri, 04 May 2012 16:42:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLaR-0004qR-Lg for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:42:31 +0000 Received: from [85.158.143.35:32176] by server-2.bemta-4.messagelabs.com id 93/50-17550-7F604AF4; Fri, 04 May 2012 16:42:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336149750!11552438!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9669 invoked from network); 4 May 2012 16:42: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; 4 May 2012 16:42:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304582" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:42:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:42:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLaO-000321-SB; Fri, 04 May 2012 16:42:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLaO-0002BT-RJ; Fri, 04 May 2012 17:42:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1780.828830.419864@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:42:28 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-7-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach"): > - Spawn a QEMU instance at boot time to handle disk local attach > requests. ... > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 7a1e017..e180498 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c ... > + rc = xs_transaction_end(ctx->xsh, t, 0); > + } while (rc == 0 && errno == EAGAIN); > + t = XBT_NULL; > + if (rc == 0) { > + LOGE(ERROR, "xenstore transaction failed"); > + goto out; Maybe I'm being excessively picky, but I think "rc" should be used only for a variable which contains libxl error codes. I had to do a double-take when I saw if (rc == 0) { error handling; since rc==0 is of course the success case. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:42:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:42:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLaT-0004qc-8E; Fri, 04 May 2012 16:42:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLaR-0004qR-Lg for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:42:31 +0000 Received: from [85.158.143.35:32176] by server-2.bemta-4.messagelabs.com id 93/50-17550-7F604AF4; Fri, 04 May 2012 16:42:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336149750!11552438!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9669 invoked from network); 4 May 2012 16:42: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; 4 May 2012 16:42:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304582" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:42:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:42:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLaO-000321-SB; Fri, 04 May 2012 16:42:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLaO-0002BT-RJ; Fri, 04 May 2012 17:42:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.1780.828830.419864@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:42:28 +0100 To: Stefano Stabellini In-Reply-To: <1336130000-27261-7-git-send-email-stefano.stabellini@eu.citrix.com> References: <1336130000-27261-7-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" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[PATCH v5 7/8] xl/libxl: implement QDISK libxl_device_disk_local_attach"): > - Spawn a QEMU instance at boot time to handle disk local attach > requests. ... > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c > index 7a1e017..e180498 100644 > --- a/tools/libxl/libxl_internal.c > +++ b/tools/libxl/libxl_internal.c ... > + rc = xs_transaction_end(ctx->xsh, t, 0); > + } while (rc == 0 && errno == EAGAIN); > + t = XBT_NULL; > + if (rc == 0) { > + LOGE(ERROR, "xenstore transaction failed"); > + goto out; Maybe I'm being excessively picky, but I think "rc" should be used only for a variable which contains libxl error codes. I had to do a double-take when I saw if (rc == 0) { error handling; since rc==0 is of course the success case. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:46:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:46:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLeR-00056l-UG; Fri, 04 May 2012 16:46:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLeQ-00056f-K5 for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:46:38 +0000 Received: from [85.158.138.51:25693] by server-10.bemta-3.messagelabs.com id C8/E6-29478-DE704AF4; Fri, 04 May 2012 16:46:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336149996!25184227!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24140 invoked from network); 4 May 2012 16:46:37 -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; 4 May 2012 16:46:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304637" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:46:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:46:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLeO-00033F-9I; Fri, 04 May 2012 16:46:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLeO-0002Bo-7c; Fri, 04 May 2012 17:46:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.2028.216374.311465@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:46:36 +0100 To: Ian Campbell In-Reply-To: <1336143599.7535.17.camel@zakaz.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.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" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > > Introduce libxl__alloc_vdev: find a spare virtual block device in the > > domain passed as argument. ... > > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); > > If you specify the default blkdev_start in xl as d0 instead of xvda > doesn't at least this bit magically become portable to BSD etc too? This bit is portable already. It's specified in terms of the guest device name rather than the host device name. This may be confusing but it saves on having a converter for host device names to disk numbers. > Or couldn't it actually be an int and save you parsing at all? In general it's surely more friendly to allow the user to specify this with a name, like we do with vdevs elsewhere. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:46:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:46:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLeR-00056l-UG; Fri, 04 May 2012 16:46:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLeQ-00056f-K5 for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:46:38 +0000 Received: from [85.158.138.51:25693] by server-10.bemta-3.messagelabs.com id C8/E6-29478-DE704AF4; Fri, 04 May 2012 16:46:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336149996!25184227!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24140 invoked from network); 4 May 2012 16:46:37 -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; 4 May 2012 16:46:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304637" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:46:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:46:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLeO-00033F-9I; Fri, 04 May 2012 16:46:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQLeO-0002Bo-7c; Fri, 04 May 2012 17:46:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.2028.216374.311465@mariner.uk.xensource.com> Date: Fri, 4 May 2012 17:46:36 +0100 To: Ian Campbell In-Reply-To: <1336143599.7535.17.camel@zakaz.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.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" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > > Introduce libxl__alloc_vdev: find a spare virtual block device in the > > domain passed as argument. ... > > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); > > If you specify the default blkdev_start in xl as d0 instead of xvda > doesn't at least this bit magically become portable to BSD etc too? This bit is portable already. It's specified in terms of the guest device name rather than the host device name. This may be confusing but it saves on having a converter for host device names to disk numbers. > Or couldn't it actually be an int and save you parsing at all? In general it's surely more friendly to allow the user to specify this with a name, like we do with vdevs elsewhere. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:54:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLm7-0005LC-Sb; Fri, 04 May 2012 16:54:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLm6-0005L7-4s for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:54:34 +0000 Received: from [85.158.139.83:56088] by server-3.bemta-5.messagelabs.com id 6E/BA-25237-9C904AF4; Fri, 04 May 2012 16:54:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336150472!22939817!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8557 invoked from network); 4 May 2012 16:54:32 -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; 4 May 2012 16:54:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304799" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:54:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:54:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLm3-00035u-PK; Fri, 04 May 2012 16:54:31 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQLm3-00088F-Kz; Fri, 04 May 2012 17:54:31 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 4 May 2012 17:54:31 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12790: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12790 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12790/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12789 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 8f556a70ae0b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=0f53540494f7 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 0f53540494f7 + branch=xen-unstable + revision=0f53540494f7 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 0f53540494f7 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 16:54:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 16:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLm7-0005LC-Sb; Fri, 04 May 2012 16:54:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLm6-0005L7-4s for xen-devel@lists.xensource.com; Fri, 04 May 2012 16:54:34 +0000 Received: from [85.158.139.83:56088] by server-3.bemta-5.messagelabs.com id 6E/BA-25237-9C904AF4; Fri, 04 May 2012 16:54:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336150472!22939817!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8557 invoked from network); 4 May 2012 16:54:32 -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; 4 May 2012 16:54:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12304799" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:54:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 17:54:32 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQLm3-00035u-PK; Fri, 04 May 2012 16:54:31 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQLm3-00088F-Kz; Fri, 04 May 2012 17:54:31 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 4 May 2012 17:54:31 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12790: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12790 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12790/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12789 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-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 8f556a70ae0b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=0f53540494f7 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 0f53540494f7 + branch=xen-unstable + revision=0f53540494f7 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 0f53540494f7 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:08:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:08:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLzZ-0005id-F1; Fri, 04 May 2012 17:08:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLzY-0005iY-E0 for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:08:28 +0000 Received: from [85.158.143.35:37510] by server-3.bemta-4.messagelabs.com id B6/17-05853-B0D04AF4; Fri, 04 May 2012 17:08:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336151304!15152667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5647 invoked from network); 4 May 2012 17:08:25 -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; 4 May 2012 17:08:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305219" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:08:24 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:08:23 +0100 Message-ID: <1336151303.3735.3.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 18:08:23 +0100 In-Reply-To: <20388.2028.216374.311465@mariner.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 17:46 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > > On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > > > Introduce libxl__alloc_vdev: find a spare virtual block device in the > > > domain passed as argument. > ... > > > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); > > > > If you specify the default blkdev_start in xl as d0 instead of xvda > > doesn't at least this bit magically become portable to BSD etc too? > > This bit is portable already. It's specified in terms of the guest > device name rather than the host device name. This may be confusing > but it saves on having a converter for host device names to disk > numbers. Right. I think I really should have made this comment on the previous patch, What I was trying to suggest is that using the Linux specific "xvda" in the example in the config file and as the default (as patch 5/8 does) is not portable, even though the infrastructure itself is quite capable of dealing with the portable alternatives -- IOW using "d0" both in the example and in the actual default would make xl be automatically portable without other patches (libxl still needs a patch for the BSD libxl__devid_to_localdev but that's it). > > Or couldn't it actually be an int and save you parsing at all? > > In general it's surely more friendly to allow the user to specify this > with a name, like we do with vdevs elsewhere. That seems reasonable. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:08:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:08:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLzZ-0005id-F1; Fri, 04 May 2012 17:08:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQLzY-0005iY-E0 for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:08:28 +0000 Received: from [85.158.143.35:37510] by server-3.bemta-4.messagelabs.com id B6/17-05853-B0D04AF4; Fri, 04 May 2012 17:08:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336151304!15152667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5647 invoked from network); 4 May 2012 17:08:25 -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; 4 May 2012 17:08:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305219" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:08:24 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:08:23 +0100 Message-ID: <1336151303.3735.3.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 18:08:23 +0100 In-Reply-To: <20388.2028.216374.311465@mariner.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 17:46 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > > On Fri, 2012-05-04 at 12:13 +0100, Stefano Stabellini wrote: > > > Introduce libxl__alloc_vdev: find a spare virtual block device in the > > > domain passed as argument. > ... > > > + libxl__device_disk_dev_number(blkdev_start, &disk, &part); > > > > If you specify the default blkdev_start in xl as d0 instead of xvda > > doesn't at least this bit magically become portable to BSD etc too? > > This bit is portable already. It's specified in terms of the guest > device name rather than the host device name. This may be confusing > but it saves on having a converter for host device names to disk > numbers. Right. I think I really should have made this comment on the previous patch, What I was trying to suggest is that using the Linux specific "xvda" in the example in the config file and as the default (as patch 5/8 does) is not portable, even though the infrastructure itself is quite capable of dealing with the portable alternatives -- IOW using "d0" both in the example and in the actual default would make xl be automatically portable without other patches (libxl still needs a patch for the BSD libxl__devid_to_localdev but that's it). > > Or couldn't it actually be an int and save you parsing at all? > > In general it's surely more friendly to allow the user to specify this > with a name, like we do with vdevs elsewhere. That seems reasonable. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:17:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQM8G-0005wv-FP; Fri, 04 May 2012 17:17:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM8F-0005wq-Eo for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:17:27 +0000 Received: from [85.158.143.99:45291] by server-3.bemta-4.messagelabs.com id 8C/6C-05853-62F04AF4; Fri, 04 May 2012 17:17:26 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336151845!20159411!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22332 invoked from network); 4 May 2012 17:17:25 -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; 4 May 2012 17:17:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:16:21 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:16:21 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQM7B-0003Cs-I7; Fri, 04 May 2012 17:16:21 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQM7B-0008Gd-9v; Fri, 04 May 2012 18:16:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.3809.683062.947217@mariner.uk.xensource.com> Date: Fri, 4 May 2012 18:16:17 +0100 To: Ian Campbell In-Reply-To: <1336151303.3735.3.camel@dagon.hellion.org.uk> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> <1336151303.3735.3.camel@dagon.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > Right. I think I really should have made this comment on the previous > patch, What I was trying to suggest is that using the Linux specific > "xvda" in the example in the config file "xvda" is not currently thought to be necessarily Linux-specific. See docs/misc/vbd-interface.text. Perhaps that needs to be revisited, but in general it's perfectly possible to pass "xvda" in a domain config file for a BSD guest, or whatever. And Linux writing "xvdfoo" in the config file doesn't always make Linux call the device /dev/xvdfoo. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:17:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQM8G-0005wv-FP; Fri, 04 May 2012 17:17:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM8F-0005wq-Eo for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:17:27 +0000 Received: from [85.158.143.99:45291] by server-3.bemta-4.messagelabs.com id 8C/6C-05853-62F04AF4; Fri, 04 May 2012 17:17:26 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336151845!20159411!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22332 invoked from network); 4 May 2012 17:17:25 -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; 4 May 2012 17:17:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:16:21 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:16:21 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQM7B-0003Cs-I7; Fri, 04 May 2012 17:16:21 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQM7B-0008Gd-9v; Fri, 04 May 2012 18:16:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.3809.683062.947217@mariner.uk.xensource.com> Date: Fri, 4 May 2012 18:16:17 +0100 To: Ian Campbell In-Reply-To: <1336151303.3735.3.camel@dagon.hellion.org.uk> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> <1336151303.3735.3.camel@dagon.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > Right. I think I really should have made this comment on the previous > patch, What I was trying to suggest is that using the Linux specific > "xvda" in the example in the config file "xvda" is not currently thought to be necessarily Linux-specific. See docs/misc/vbd-interface.text. Perhaps that needs to be revisited, but in general it's perfectly possible to pass "xvda" in a domain config file for a BSD guest, or whatever. And Linux writing "xvdfoo" in the config file doesn't always make Linux call the device /dev/xvdfoo. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:19:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:19:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM9p-00061A-Um; Fri, 04 May 2012 17:19:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM9o-000612-NQ for xen-devel@lists.xen.org; Fri, 04 May 2012 17:19:04 +0000 Received: from [85.158.138.51:10541] by server-3.bemta-3.messagelabs.com id 56/84-04048-78F04AF4; Fri, 04 May 2012 17:19:03 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336151942!14315177!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31158 invoked from network); 4 May 2012 17:19:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 17:19:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305355" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:19:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:19:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQM9m-0003Dw-HK; Fri, 04 May 2012 17:19:02 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQM9l-0003p3-UO; Fri, 04 May 2012 18:19:02 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.3963.30725.320365@mariner.uk.xensource.com> Date: Fri, 4 May 2012 18:18:51 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> References: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid"): > Fix qemu dm model destruction if the pid in xenstore is 0 (or is not > present). Firstly, this needs rewrapping. Secondly, > pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); > if (!pid) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); > + ret = ERROR_INVAL; > + goto out; > + } > + if (!atoi(pid)) { > int stubdomid = libxl_get_stubdom_id(ctx, domid); This seems to change the logic regarding stubdoms. Are you sure this is correct ? Previously if the entry didn't exist, we took the stubdom path. > - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); > - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); > > out: > + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); > + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); While moving this, you might as well rewrap it (or use GCSPRINTF). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:19:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:19:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM9p-00061A-Um; Fri, 04 May 2012 17:19:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQM9o-000612-NQ for xen-devel@lists.xen.org; Fri, 04 May 2012 17:19:04 +0000 Received: from [85.158.138.51:10541] by server-3.bemta-3.messagelabs.com id 56/84-04048-78F04AF4; Fri, 04 May 2012 17:19:03 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336151942!14315177!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31158 invoked from network); 4 May 2012 17:19:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 17:19:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305355" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:19:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:19:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQM9m-0003Dw-HK; Fri, 04 May 2012 17:19:02 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SQM9l-0003p3-UO; Fri, 04 May 2012 18:19:02 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20388.3963.30725.320365@mariner.uk.xensource.com> Date: Fri, 4 May 2012 18:18:51 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> References: <1336048277-39554-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: fix dm destruction when there is no pid"): > Fix qemu dm model destruction if the pid in xenstore is 0 (or is not > present). Firstly, this needs rewrapping. Secondly, > pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); > if (!pid) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); > + ret = ERROR_INVAL; > + goto out; > + } > + if (!atoi(pid)) { > int stubdomid = libxl_get_stubdom_id(ctx, domid); This seems to change the logic regarding stubdoms. Are you sure this is correct ? Previously if the entry didn't exist, we took the stubdom path. > - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); > - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); > > out: > + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); > + xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); While moving this, you might as well rewrap it (or use GCSPRINTF). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:21:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQMBl-00068A-Ht; Fri, 04 May 2012 17:21:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMBk-000682-7u for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:21:04 +0000 Received: from [193.109.254.147:46710] by server-7.bemta-14.messagelabs.com id 92/64-01627-FFF04AF4; Fri, 04 May 2012 17:21:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336152061!878637!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14037 invoked from network); 4 May 2012 17:21:01 -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; 4 May 2012 17:21:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305378" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:20:47 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:20:47 +0100 Message-ID: <1336152047.3735.8.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 18:20:47 +0100 In-Reply-To: <20388.3809.683062.947217@mariner.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> <1336151303.3735.3.camel@dagon.hellion.org.uk> <20388.3809.683062.947217@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 18:16 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > > Right. I think I really should have made this comment on the previous > > patch, What I was trying to suggest is that using the Linux specific > > "xvda" in the example in the config file > > "xvda" is not currently thought to be necessarily Linux-specific. See > docs/misc/vbd-interface.text. Perhaps that needs to be revisited, but > in general it's perfectly possible to pass "xvda" in a domain config > file for a BSD guest, or whatever. And Linux writing "xvdfoo" in the > config file doesn't always make Linux call the device /dev/xvdfoo. Hrm, I guess. It certainly gives the impression of being Linux specific, even if technically it isn't, since people associate xvd* with Linux even if it happens to be valid and work elsewhere. I guess in reality very few people, including BSD folks, are going to change this (because it'll just work) so there's no chance of them getting confused. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:21:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQMBl-00068A-Ht; Fri, 04 May 2012 17:21:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMBk-000682-7u for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:21:04 +0000 Received: from [193.109.254.147:46710] by server-7.bemta-14.messagelabs.com id 92/64-01627-FFF04AF4; Fri, 04 May 2012 17:21:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336152061!878637!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzI3OQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14037 invoked from network); 4 May 2012 17:21:01 -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; 4 May 2012 17:21:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330905600"; d="scan'208";a="12305378" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 17:20:47 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 18:20:47 +0100 Message-ID: <1336152047.3735.8.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Fri, 4 May 2012 18:20:47 +0100 In-Reply-To: <20388.3809.683062.947217@mariner.uk.xensource.com> References: <1336130000-27261-6-git-send-email-stefano.stabellini@eu.citrix.com> <1336143599.7535.17.camel@zakaz.uk.xensource.com> <20388.2028.216374.311465@mariner.uk.xensource.com> <1336151303.3735.3.camel@dagon.hellion.org.uk> <20388.3809.683062.947217@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 18:16 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH v5 6/8] libxl: introduce libxl__alloc_vdev"): > > Right. I think I really should have made this comment on the previous > > patch, What I was trying to suggest is that using the Linux specific > > "xvda" in the example in the config file > > "xvda" is not currently thought to be necessarily Linux-specific. See > docs/misc/vbd-interface.text. Perhaps that needs to be revisited, but > in general it's perfectly possible to pass "xvda" in a domain config > file for a BSD guest, or whatever. And Linux writing "xvdfoo" in the > config file doesn't always make Linux call the device /dev/xvdfoo. Hrm, I guess. It certainly gives the impression of being Linux specific, even if technically it isn't, since people associate xvd* with Linux even if it happens to be valid and work elsewhere. I guess in reality very few people, including BSD folks, are going to change this (because it'll just work) so there's no chance of them getting confused. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:39:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:39:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMSm-0006QK-6J; Fri, 04 May 2012 17:38:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMSk-0006QF-7h for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:38:38 +0000 Received: from [85.158.139.83:3175] by server-2.bemta-5.messagelabs.com id D7/56-17016-D1414AF4; Fri, 04 May 2012 17:38:37 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-182.messagelabs.com!1336153116!19468373!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19789 invoked from network); 4 May 2012 17:38:36 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 17:38:36 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jored mo91) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e00dd3o44GI7Xo for ; Fri, 4 May 2012 19:38:35 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 3BEE318630 for ; Fri, 4 May 2012 19:38:35 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 9a430b7e2df2893f7f4f75d10e66d52bdffa7efa Message-Id: <9a430b7e2df2893f7f4f.1336153114@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 19:38:34 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336153082 -7200 # Node ID 9a430b7e2df2893f7f4f75d10e66d52bdffa7efa # Parent 113fd57259b91af06a5352404dd94b484a98d2bc tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as reserved for local use, the local sysadmin is responsible for symlink creation in rc4.d. Runlevel 4 was specified in Default-Start since a very long time. Then it was copied also to the new xen-watchdog in 21861:fb3649141e19. Until now this was not an issue since only xencommons is automatically enabled during package install, and a custom xend and xendomains script is included in the SuSE packages. Since some time a rpmlint check complains about the wrong Default-Start entry in xen-watchdog. Signed-off-by: Olaf Hering diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xen-watchdog --- a/tools/hotplug/Linux/init.d/xen-watchdog +++ b/tools/hotplug/Linux/init.d/xen-watchdog @@ -10,7 +10,7 @@ # Should-Start: xend # Required-Stop: $syslog $remote_fs # Should-Stop: xend -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop xen-watchdog # Description: Run domain watchdog daemon. diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xend --- a/tools/hotplug/Linux/init.d/xend +++ b/tools/hotplug/Linux/init.d/xend @@ -12,7 +12,7 @@ # Should-Start: # Required-Stop: $syslog $remote_fs xenstored xenconsoled # Should-Stop: -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop xend # Description: Starts and stops the Xen control daemon. diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xendomains --- a/tools/hotplug/Linux/init.d/xendomains +++ b/tools/hotplug/Linux/init.d/xendomains @@ -20,7 +20,7 @@ # Should-Start: xend # Required-Stop: $syslog $remote_fs xenstored xenconsoled # Should-Stop: xend -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop secondary xen domains # Description: Start / stop domains automatically when domain 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:39:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17:39:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMSm-0006QK-6J; Fri, 04 May 2012 17:38:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMSk-0006QF-7h for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:38:38 +0000 Received: from [85.158.139.83:3175] by server-2.bemta-5.messagelabs.com id D7/56-17016-D1414AF4; Fri, 04 May 2012 17:38:37 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-182.messagelabs.com!1336153116!19468373!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19789 invoked from network); 4 May 2012 17:38:36 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 17:38:36 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jored mo91) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e00dd3o44GI7Xo for ; Fri, 4 May 2012 19:38:35 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 3BEE318630 for ; Fri, 4 May 2012 19:38:35 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 9a430b7e2df2893f7f4f75d10e66d52bdffa7efa Message-Id: <9a430b7e2df2893f7f4f.1336153114@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 19:38:34 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336153082 -7200 # Node ID 9a430b7e2df2893f7f4f75d10e66d52bdffa7efa # Parent 113fd57259b91af06a5352404dd94b484a98d2bc tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as reserved for local use, the local sysadmin is responsible for symlink creation in rc4.d. Runlevel 4 was specified in Default-Start since a very long time. Then it was copied also to the new xen-watchdog in 21861:fb3649141e19. Until now this was not an issue since only xencommons is automatically enabled during package install, and a custom xend and xendomains script is included in the SuSE packages. Since some time a rpmlint check complains about the wrong Default-Start entry in xen-watchdog. Signed-off-by: Olaf Hering diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xen-watchdog --- a/tools/hotplug/Linux/init.d/xen-watchdog +++ b/tools/hotplug/Linux/init.d/xen-watchdog @@ -10,7 +10,7 @@ # Should-Start: xend # Required-Stop: $syslog $remote_fs # Should-Stop: xend -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop xen-watchdog # Description: Run domain watchdog daemon. diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xend --- a/tools/hotplug/Linux/init.d/xend +++ b/tools/hotplug/Linux/init.d/xend @@ -12,7 +12,7 @@ # Should-Start: # Required-Stop: $syslog $remote_fs xenstored xenconsoled # Should-Stop: -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop xend # Description: Starts and stops the Xen control daemon. diff -r 113fd57259b9 -r 9a430b7e2df2 tools/hotplug/Linux/init.d/xendomains --- a/tools/hotplug/Linux/init.d/xendomains +++ b/tools/hotplug/Linux/init.d/xendomains @@ -20,7 +20,7 @@ # Should-Start: xend # Required-Stop: $syslog $remote_fs xenstored xenconsoled # Should-Stop: xend -# Default-Start: 2 3 4 5 +# Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Short-Description: Start/stop secondary xen domains # Description: Start / stop domains automatically when domain 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:44:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQMYV-0006cu-Vl; Fri, 04 May 2012 17:44:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMYU-0006cn-GT for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:44:34 +0000 Received: from [193.109.254.147:23732] by server-8.bemta-14.messagelabs.com id 38/9F-23244-18514AF4; Fri, 04 May 2012 17:44:33 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1336153473!831240!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3351 invoked from network); 4 May 2012 17:44:33 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 17:44:33 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jorabe mo32) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V01bcfo44GD2cn ; Fri, 4 May 2012 19:44:33 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 6C96918630; Fri, 4 May 2012 19:44:32 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c19bca94a5ade9c8a528f346bce3c90eee319306 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 19:43:49 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Cc: Ross Philipson Subject: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336153405 -7200 # Node ID c19bca94a5ade9c8a528f346bce3c90eee319306 # Parent 2ef28bf88b290d01ca92581dcd68f1aa32017e4e tools/vtpm: use LDLIBS to pass -lgmp Linking tpmd will fail with recent toolchains because -lgmp is passed via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the end of the gcc cmdline and linking tpmd succeeds again. Signed-off-by: Olaf Hering diff -r 2ef28bf88b29 -r c19bca94a5ad tools/vtpm/Makefile --- a/tools/vtpm/Makefile +++ b/tools/vtpm/Makefile @@ -50,7 +50,8 @@ mrproper: mv $(TPM_EMULATOR_NAME) $(VTPM_DIR) set -e; cd $(VTPM_DIR); \ - patch -p1 < ../vtpm-0.5.1.patch + patch -p1 < ../vtpm-0.5.1.patch; \ + patch -p1 < ../vtpm-0.5.1-LDLIBS.patch orig: $(TPM_EMULATOR_TARFILE) mkdir $(ORIG_DIR); diff -r 2ef28bf88b29 -r c19bca94a5ad tools/vtpm/vtpm-0.5.1-LDLIBS.patch --- /dev/null +++ b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch @@ -0,0 +1,12 @@ +diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm_emulator-0.5.1/tpmd/Makefile +--- tpm_emulator-0.5.1/tpmd/Makefile ++++ tpm_emulator-0.5.1/tpmd/Makefile +@@ -8,7 +8,7 @@ WFLAGS := -Wall -Wno-unused -Wpointer-a + #WFLAGS += -Wextra -Wcast-qual -Wmissing-prototypes -Wmissing-declarations -Wstrict-aliasing + CFLAGS += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing + CFLAGS += -I../../../../tools/vtpm_manager/manager +-LDFLAGS += -lgmp ++LDLIBS += -lgmp + + BINDIR := /usr/bin/ + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 17:44:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 17: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 ) id 1SQMYV-0006cu-Vl; Fri, 04 May 2012 17:44:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQMYU-0006cn-GT for xen-devel@lists.xensource.com; Fri, 04 May 2012 17:44:34 +0000 Received: from [193.109.254.147:23732] by server-8.bemta-14.messagelabs.com id 38/9F-23244-18514AF4; Fri, 04 May 2012 17:44:33 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1336153473!831240!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3351 invoked from network); 4 May 2012 17:44:33 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 17:44:33 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jorabe mo32) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V01bcfo44GD2cn ; Fri, 4 May 2012 19:44:33 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 6C96918630; Fri, 4 May 2012 19:44:32 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c19bca94a5ade9c8a528f346bce3c90eee319306 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 19:43:49 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Cc: Ross Philipson Subject: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336153405 -7200 # Node ID c19bca94a5ade9c8a528f346bce3c90eee319306 # Parent 2ef28bf88b290d01ca92581dcd68f1aa32017e4e tools/vtpm: use LDLIBS to pass -lgmp Linking tpmd will fail with recent toolchains because -lgmp is passed via LDFLAGS instead of LDLIBS. With this change -lgpm is placed at the end of the gcc cmdline and linking tpmd succeeds again. Signed-off-by: Olaf Hering diff -r 2ef28bf88b29 -r c19bca94a5ad tools/vtpm/Makefile --- a/tools/vtpm/Makefile +++ b/tools/vtpm/Makefile @@ -50,7 +50,8 @@ mrproper: mv $(TPM_EMULATOR_NAME) $(VTPM_DIR) set -e; cd $(VTPM_DIR); \ - patch -p1 < ../vtpm-0.5.1.patch + patch -p1 < ../vtpm-0.5.1.patch; \ + patch -p1 < ../vtpm-0.5.1-LDLIBS.patch orig: $(TPM_EMULATOR_TARFILE) mkdir $(ORIG_DIR); diff -r 2ef28bf88b29 -r c19bca94a5ad tools/vtpm/vtpm-0.5.1-LDLIBS.patch --- /dev/null +++ b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch @@ -0,0 +1,12 @@ +diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm_emulator-0.5.1/tpmd/Makefile +--- tpm_emulator-0.5.1/tpmd/Makefile ++++ tpm_emulator-0.5.1/tpmd/Makefile +@@ -8,7 +8,7 @@ WFLAGS := -Wall -Wno-unused -Wpointer-a + #WFLAGS += -Wextra -Wcast-qual -Wmissing-prototypes -Wmissing-declarations -Wstrict-aliasing + CFLAGS += $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing + CFLAGS += -I../../../../tools/vtpm_manager/manager +-LDFLAGS += -lgmp ++LDLIBS += -lgmp + + BINDIR := /usr/bin/ + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:19:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18: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 ) id 1SQN5d-00079v-Qr; Fri, 04 May 2012 18:18:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN5c-00079p-5Z for xen-devel@lists.xen.org; Fri, 04 May 2012 18:18:48 +0000 Received: from [193.109.254.147:45906] by server-10.bemta-14.messagelabs.com id A1/30-05847-78D14AF4; Fri, 04 May 2012 18:18:47 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336155525!7696896!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17814 invoked from network); 4 May 2012 18:18:46 -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; 4 May 2012 18:18:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330923600"; d="scan'208";a="193472614" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:45 -0400 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, 4 May 2012 14:18:44 -0400 Message-ID: <4FA41D83.2010809@citrix.com> Date: Fri, 4 May 2012 19:18:43 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> In-Reply-To: <4FA40321.3080201@citrix.com> Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 17:26, David Vrabel wrote: > On 04/05/12 17:12, Jan Beulich wrote: >>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>> From: David Vrabel >>> >>> The dom0_max_vcpus command line option only allows the exact number of >>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>> but no more than the number physically present." >>> >>> Add min: and max: prefixes to the option to set a minimum number of >>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>> >>> For example, with "dom0_max_vcpus=min:4,max:8": >> >> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >> how about simply allowing a range along with a simple number (since >> negative values make no sense, omitting either side of the range would >> be supportable if necessary. > > I was copying the way dom0_mem worked but yeah, it's not very pretty. > > Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were > thinking of? > > Using a single value would have to set both and or the > behaviour of the option changes (i.e., =N is the same as =N-N). This is what I ended up with. 8<------------------------------ >From af1543965db76ab81139de7f072a7c4daf61157f Mon Sep 17 00:00:00 2001 From: David Vrabel Date: Fri, 4 May 2012 16:09:52 +0100 Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible The dom0_max_vcpus command line option only allows the exact number of VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs but no more than the number physically present." Allow a range for the option to set a minimum number of VCPUs, and a maximum which does not exceed the number of PCPUs. For example, with "dom0_max_vcpus=4-8": PCPUs Dom0 VCPUs 2 4 4 4 6 6 8 8 10 8 Existing command lines with "dom0_max_vcpus=N" still work as before. Signed-off-by: David Vrabel --- docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++-- xen/arch/x86/domain_build.c | 43 +++++++++++++++++++++++++--------- 2 files changed, 57 insertions(+), 15 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index a6195f2..4e4f713 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -272,10 +272,33 @@ Specify the bit width of the DMA heap. ### dom0\_ioports\_disable ### dom0\_max\_vcpus -> `= ` -Specify the maximum number of vcpus to give to dom0. This defaults -to the number of pcpus on the host. +Either: + +> `= `. + +The number of VCPUs to give to dom0. This number of VCPUs can be more +than the number of PCPUs on the host. The default is the number of +PCPUs. + +Or: + +> `= -` where `` and `` are integers. + +Gives dom0 a number of VCPUs equal to the number of PCPUs, but always +at least `` and no more than ``. Using `` may give +more VCPUs than PCPUs. `` or `` may be omitted and the +defaults of 1 and unlimited respectively are used instead. + +For example, with `dom0_max_vcpus=4-8`: + + Number of + PCPUs | Dom0 VCPUs + 2 | 4 + 4 | 4 + 6 | 6 + 8 | 8 + 10 | 8 ### dom0\_mem (ia64) > `= ` diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c index b3c5d4c..686b626 100644 --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s) } custom_param("dom0_mem", parse_dom0_mem); -static unsigned int __initdata opt_dom0_max_vcpus; -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; + +static void __init parse_dom0_max_vcpus(const char *s) +{ + if (*s == '-') /* -M */ + opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0); + else { /* N, N-, or N-M */ + opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0); + if (*s++ == '\0') /* N */ + opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min; + else if (*s != '\0') /* N-M */ + opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0); + } +} +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); struct vcpu *__init alloc_dom0_vcpu0(void) { - if ( opt_dom0_max_vcpus == 0 ) - opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); - if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) - opt_dom0_max_vcpus = MAX_VIRT_CPUS; + unsigned max_vcpus; + + max_vcpus = num_cpupool_cpus(cpupool0); + if ( opt_dom0_max_vcpus_min > max_vcpus ) + max_vcpus = opt_dom0_max_vcpus_min; + if ( opt_dom0_max_vcpus_max < max_vcpus ) + max_vcpus = opt_dom0_max_vcpus_max; + if ( max_vcpus > MAX_VIRT_CPUS ) + max_vcpus = MAX_VIRT_CPUS; - dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); + dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus); if ( !dom0->vcpu ) return NULL; - dom0->max_vcpus = opt_dom0_max_vcpus; + dom0->max_vcpus = max_vcpus; return alloc_vcpu(dom0, 0, 0); } @@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages( unsigned long max_pages = dom0_max_nrpages; /* Reserve memory for further dom0 vcpu-struct allocations... */ - avail -= (opt_dom0_max_vcpus - 1UL) + avail -= (d->max_vcpus - 1UL) << get_order_from_bytes(sizeof(struct vcpu)); /* ...and compat_l4's, if needed. */ if ( is_pv_32on64_domain(d) ) - avail -= opt_dom0_max_vcpus - 1; + avail -= d->max_vcpus - 1; /* Reserve memory for iommu_dom0_init() (rough estimate). */ if ( iommu_enabled ) @@ -883,10 +902,10 @@ int __init construct_dom0( for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ ) shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1; - printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus); + printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus); cpu = cpumask_first(cpupool0->cpu_valid); - for ( i = 1; i < opt_dom0_max_vcpus; i++ ) + for ( i = 1; i < d->max_vcpus; i++ ) { cpu = cpumask_cycle(cpu, cpupool0->cpu_valid); (void)alloc_vcpu(d, i, cpu); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:19:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18: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 ) id 1SQN5d-00079v-Qr; Fri, 04 May 2012 18:18:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN5c-00079p-5Z for xen-devel@lists.xen.org; Fri, 04 May 2012 18:18:48 +0000 Received: from [193.109.254.147:45906] by server-10.bemta-14.messagelabs.com id A1/30-05847-78D14AF4; Fri, 04 May 2012 18:18:47 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336155525!7696896!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17814 invoked from network); 4 May 2012 18:18:46 -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; 4 May 2012 18:18:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,532,1330923600"; d="scan'208";a="193472614" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 14:18:45 -0400 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, 4 May 2012 14:18:44 -0400 Message-ID: <4FA41D83.2010809@citrix.com> Date: Fri, 4 May 2012 19:18:43 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> In-Reply-To: <4FA40321.3080201@citrix.com> Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/05/12 17:26, David Vrabel wrote: > On 04/05/12 17:12, Jan Beulich wrote: >>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>> From: David Vrabel >>> >>> The dom0_max_vcpus command line option only allows the exact number of >>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>> but no more than the number physically present." >>> >>> Add min: and max: prefixes to the option to set a minimum number of >>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>> >>> For example, with "dom0_max_vcpus=min:4,max:8": >> >> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >> how about simply allowing a range along with a simple number (since >> negative values make no sense, omitting either side of the range would >> be supportable if necessary. > > I was copying the way dom0_mem worked but yeah, it's not very pretty. > > Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were > thinking of? > > Using a single value would have to set both and or the > behaviour of the option changes (i.e., =N is the same as =N-N). This is what I ended up with. 8<------------------------------ >From af1543965db76ab81139de7f072a7c4daf61157f Mon Sep 17 00:00:00 2001 From: David Vrabel Date: Fri, 4 May 2012 16:09:52 +0100 Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible The dom0_max_vcpus command line option only allows the exact number of VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs but no more than the number physically present." Allow a range for the option to set a minimum number of VCPUs, and a maximum which does not exceed the number of PCPUs. For example, with "dom0_max_vcpus=4-8": PCPUs Dom0 VCPUs 2 4 4 4 6 6 8 8 10 8 Existing command lines with "dom0_max_vcpus=N" still work as before. Signed-off-by: David Vrabel --- docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++-- xen/arch/x86/domain_build.c | 43 +++++++++++++++++++++++++--------- 2 files changed, 57 insertions(+), 15 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index a6195f2..4e4f713 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -272,10 +272,33 @@ Specify the bit width of the DMA heap. ### dom0\_ioports\_disable ### dom0\_max\_vcpus -> `= ` -Specify the maximum number of vcpus to give to dom0. This defaults -to the number of pcpus on the host. +Either: + +> `= `. + +The number of VCPUs to give to dom0. This number of VCPUs can be more +than the number of PCPUs on the host. The default is the number of +PCPUs. + +Or: + +> `= -` where `` and `` are integers. + +Gives dom0 a number of VCPUs equal to the number of PCPUs, but always +at least `` and no more than ``. Using `` may give +more VCPUs than PCPUs. `` or `` may be omitted and the +defaults of 1 and unlimited respectively are used instead. + +For example, with `dom0_max_vcpus=4-8`: + + Number of + PCPUs | Dom0 VCPUs + 2 | 4 + 4 | 4 + 6 | 6 + 8 | 8 + 10 | 8 ### dom0\_mem (ia64) > `= ` diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c index b3c5d4c..686b626 100644 --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s) } custom_param("dom0_mem", parse_dom0_mem); -static unsigned int __initdata opt_dom0_max_vcpus; -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; + +static void __init parse_dom0_max_vcpus(const char *s) +{ + if (*s == '-') /* -M */ + opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0); + else { /* N, N-, or N-M */ + opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0); + if (*s++ == '\0') /* N */ + opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min; + else if (*s != '\0') /* N-M */ + opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0); + } +} +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); struct vcpu *__init alloc_dom0_vcpu0(void) { - if ( opt_dom0_max_vcpus == 0 ) - opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); - if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) - opt_dom0_max_vcpus = MAX_VIRT_CPUS; + unsigned max_vcpus; + + max_vcpus = num_cpupool_cpus(cpupool0); + if ( opt_dom0_max_vcpus_min > max_vcpus ) + max_vcpus = opt_dom0_max_vcpus_min; + if ( opt_dom0_max_vcpus_max < max_vcpus ) + max_vcpus = opt_dom0_max_vcpus_max; + if ( max_vcpus > MAX_VIRT_CPUS ) + max_vcpus = MAX_VIRT_CPUS; - dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); + dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus); if ( !dom0->vcpu ) return NULL; - dom0->max_vcpus = opt_dom0_max_vcpus; + dom0->max_vcpus = max_vcpus; return alloc_vcpu(dom0, 0, 0); } @@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages( unsigned long max_pages = dom0_max_nrpages; /* Reserve memory for further dom0 vcpu-struct allocations... */ - avail -= (opt_dom0_max_vcpus - 1UL) + avail -= (d->max_vcpus - 1UL) << get_order_from_bytes(sizeof(struct vcpu)); /* ...and compat_l4's, if needed. */ if ( is_pv_32on64_domain(d) ) - avail -= opt_dom0_max_vcpus - 1; + avail -= d->max_vcpus - 1; /* Reserve memory for iommu_dom0_init() (rough estimate). */ if ( iommu_enabled ) @@ -883,10 +902,10 @@ int __init construct_dom0( for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ ) shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1; - printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus); + printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus); cpu = cpumask_first(cpupool0->cpu_valid); - for ( i = 1; i < opt_dom0_max_vcpus; i++ ) + for ( i = 1; i < d->max_vcpus; i++ ) { cpu = cpumask_cycle(cpu, cpupool0->cpu_valid); (void)alloc_vcpu(d, i, cpu); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:20:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:20:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN6i-0007EB-E4; Fri, 04 May 2012 18:19:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN6g-0007Dz-MV for Xen-devel@lists.xensource.com; Fri, 04 May 2012 18:19:54 +0000 Received: from [85.158.143.99:15009] by server-2.bemta-4.messagelabs.com id EF/EC-17550-ACD14AF4; Fri, 04 May 2012 18:19:54 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336155590!26216475!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8766 invoked from network); 4 May 2012 18:19:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:19:52 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44IJkiV007336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 18:19:47 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44IJjkl026427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 18:19:45 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 q44IJihc021476; Fri, 4 May 2012 13:19:44 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 11:19:44 -0700 Date: Fri, 4 May 2012 11:19:35 -0700 From: Mukesh Rathor To: Ian Campbell , "Tim.Deegan@citrix.com" Message-ID: <20120504111935.7553aaed@mantra.us.oracle.com> In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012 10:08:22 +0100 Ian Campbell wrote: > Are you sure code in cpucheck.c is even being called for the PV/dom0 > case? I'm reasonably sure that PV Xen boot doesn't go anywhere near > arch/x86/boot -- we have a totally different entry point. I didn't make myself clear (rushing to type email and leave with a brain fried from debugging all day :).) I'm talking about HVM domU on PV/dom0. Basically, I've the PV linux kernel modified for hybrid. I can boot it as both hybrid domU (say Lu) and hybrid dom0 (say L0). Orig/normal PV DOM0: Lu boots in hybrid mode, PV mode, HVM mode. L0 as Dom0: Lu boots in hybrid mode, PV mode but in HVM mode fails. HVM mode is failing because very early during boot its failing the eflags.ID test, which should be simple. It should be running in real mode in the VMX. I just got outb working, so I can debug further now. It's not doing vmexit's so should be running in the 'unrestricted mode' in the container, which is why i'm baffled. Anyways, i'll dig further. thanks a lot, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:20:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:20:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN6i-0007EB-E4; Fri, 04 May 2012 18:19:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQN6g-0007Dz-MV for Xen-devel@lists.xensource.com; Fri, 04 May 2012 18:19:54 +0000 Received: from [85.158.143.99:15009] by server-2.bemta-4.messagelabs.com id EF/EC-17550-ACD14AF4; Fri, 04 May 2012 18:19:54 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336155590!26216475!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8766 invoked from network); 4 May 2012 18:19:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:19:52 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44IJkiV007336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 18:19:47 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q44IJjkl026427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 18:19:45 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 q44IJihc021476; Fri, 4 May 2012 13:19:44 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 11:19:44 -0700 Date: Fri, 4 May 2012 11:19:35 -0700 From: Mukesh Rathor To: Ian Campbell , "Tim.Deegan@citrix.com" Message-ID: <20120504111935.7553aaed@mantra.us.oracle.com> In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012 10:08:22 +0100 Ian Campbell wrote: > Are you sure code in cpucheck.c is even being called for the PV/dom0 > case? I'm reasonably sure that PV Xen boot doesn't go anywhere near > arch/x86/boot -- we have a totally different entry point. I didn't make myself clear (rushing to type email and leave with a brain fried from debugging all day :).) I'm talking about HVM domU on PV/dom0. Basically, I've the PV linux kernel modified for hybrid. I can boot it as both hybrid domU (say Lu) and hybrid dom0 (say L0). Orig/normal PV DOM0: Lu boots in hybrid mode, PV mode, HVM mode. L0 as Dom0: Lu boots in hybrid mode, PV mode but in HVM mode fails. HVM mode is failing because very early during boot its failing the eflags.ID test, which should be simple. It should be running in real mode in the VMX. I just got outb working, so I can debug further now. It's not doing vmexit's so should be running in the 'unrestricted mode' in the container, which is why i'm baffled. Anyways, i'll dig further. thanks a lot, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:24:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:24:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNAp-0007QA-3C; Fri, 04 May 2012 18:24:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNAn-0007Px-Gj for xen-devel@lists.xensource.com; Fri, 04 May 2012 18:24:09 +0000 Received: from [85.158.139.83:43204] by server-11.bemta-5.messagelabs.com id 5F/32-12959-6CE14AF4; Fri, 04 May 2012 18:24:06 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-182.messagelabs.com!1336155845!26858969!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19488 invoked from network); 4 May 2012 18:24:05 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:24:05 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo14) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d071ddo44GOcMu for ; Fri, 4 May 2012 20:24:05 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 8739F18630 for ; Fri, 4 May 2012 20:24:04 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: fb4089f411e49a3f60596c6782083a2785e544ea Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 20:24:03 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: add missing space to rename-restart X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336155798 -7200 # Node ID fb4089f411e49a3f60596c6782083a2785e544ea # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 xl.cfg: add missing space to rename-restart Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r fb4089f411e4 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -172,7 +172,7 @@ configuration =item B -rename the domain which terminated, and thenimmediately create a new +rename the domain which terminated, and then immediately create a new domain with the same configuration as the original =item B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:24:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:24:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNAp-0007QA-3C; Fri, 04 May 2012 18:24:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNAn-0007Px-Gj for xen-devel@lists.xensource.com; Fri, 04 May 2012 18:24:09 +0000 Received: from [85.158.139.83:43204] by server-11.bemta-5.messagelabs.com id 5F/32-12959-6CE14AF4; Fri, 04 May 2012 18:24:06 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-182.messagelabs.com!1336155845!26858969!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODUwOTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19488 invoked from network); 4 May 2012 18:24:05 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:24:05 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo14) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d071ddo44GOcMu for ; Fri, 4 May 2012 20:24:05 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 8739F18630 for ; Fri, 4 May 2012 20:24:04 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: fb4089f411e49a3f60596c6782083a2785e544ea Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 20:24:03 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: add missing space to rename-restart X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336155798 -7200 # Node ID fb4089f411e49a3f60596c6782083a2785e544ea # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 xl.cfg: add missing space to rename-restart Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r fb4089f411e4 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -172,7 +172,7 @@ configuration =item B -rename the domain which terminated, and thenimmediately create a new +rename the domain which terminated, and then immediately create a new domain with the same configuration as the original =item B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:55:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNeQ-0007po-P7; Fri, 04 May 2012 18:54:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNeP-0007ph-7i for Xen-devel@lists.xensource.com; Fri, 04 May 2012 18:54:45 +0000 Received: from [193.109.254.147:30167] by server-5.bemta-14.messagelabs.com id B0/7E-30733-4F524AF4; Fri, 04 May 2012 18:54:44 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336157682!7693774!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22797 invoked from network); 4 May 2012 18:54:44 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:54:44 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44Isd8u031806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 18:54:39 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 q44IsbV1024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 18:54:38 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44Isa6q007200; Fri, 4 May 2012 13:54:36 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 11:54:36 -0700 Date: Fri, 4 May 2012 11:54:27 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20120504115427.6a79abb8@mantra.us.oracle.com> In-Reply-To: <20120504111935.7553aaed@mantra.us.oracle.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504111935.7553aaed@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Jan Beulich , "Tim.Deegan@citrix.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012 11:19:35 -0700 Mukesh Rathor wrote: > HVM mode is failing because very early during boot its failing the > eflags.ID test, which should be simple. It should be running > in real mode in the VMX. I just got outb working, so I can debug > further now. It's not doing vmexit's so should be running in the > 'unrestricted mode' in the container, which is why i'm baffled. > Anyways, i'll dig further. Now that I'm able to print stuff, because of the outb working, I see the problem is executing cpuid and not eflags.ID. I should be able to nail this soon. Thanks a lot, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 18:55:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 18:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNeQ-0007po-P7; Fri, 04 May 2012 18:54:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQNeP-0007ph-7i for Xen-devel@lists.xensource.com; Fri, 04 May 2012 18:54:45 +0000 Received: from [193.109.254.147:30167] by server-5.bemta-14.messagelabs.com id B0/7E-30733-4F524AF4; Fri, 04 May 2012 18:54:44 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336157682!7693774!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMzQzNA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22797 invoked from network); 4 May 2012 18:54:44 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 18:54:44 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44Isd8u031806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 18:54:39 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 q44IsbV1024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 18:54:38 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44Isa6q007200; Fri, 4 May 2012 13:54:36 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 11:54:36 -0700 Date: Fri, 4 May 2012 11:54:27 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20120504115427.6a79abb8@mantra.us.oracle.com> In-Reply-To: <20120504111935.7553aaed@mantra.us.oracle.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> <20120504111935.7553aaed@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Jan Beulich , "Tim.Deegan@citrix.com" Subject: Re: [Xen-devel] [hybrid]: unable to boot hvm due to eflags.ID X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 4 May 2012 11:19:35 -0700 Mukesh Rathor wrote: > HVM mode is failing because very early during boot its failing the > eflags.ID test, which should be simple. It should be running > in real mode in the VMX. I just got outb working, so I can debug > further now. It's not doing vmexit's so should be running in the > 'unrestricted mode' in the container, which is why i'm baffled. > Anyways, i'll dig further. Now that I'm able to print stuff, because of the outb working, I see the problem is executing cpuid and not eflags.ID. I should be able to nail this soon. Thanks a lot, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:30:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:30:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOCi-0008F5-NL; Fri, 04 May 2012 19:30:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOCg-0008Ex-Q6 for xen-devel@lists.xen.org; Fri, 04 May 2012 19:30:11 +0000 Received: from [193.109.254.147:42693] by server-12.bemta-14.messagelabs.com id A8/2A-05898-24E24AF4; Fri, 04 May 2012 19:30:10 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336159806!7710316!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13622 invoked from network); 4 May 2012 19:30:07 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 19:30:07 -0000 Received: by qcsc20 with SMTP id c20so196642qcs.32 for ; Fri, 04 May 2012 12:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6x6NwAiie8Ko0MbYCAg4bznKuUOnFlg9SuD8wYVyyo8=; b=YoqUJXalY/X3iUXtREIGQrfAAvnfqe+Ak50u80W7LTGs2rItuS17OkQ1LCNdJIYRqp RgwEn299ODa3rdOBRyv5LocN4jr+7CkcLtu/8xNrxgn5v7C9LCOlgjHUQLgKKSykKchR uYOB82hitL8WxN4+k6CvtZVIlDrMaU6sXxmzpQ1g5wqTQdWH1lNZ4iXNVU8ARCgffuRj Ml28JHDPXH4Hh3ZOpSN1qF/GI1ROOt8arBN46eaVEDpqRJY49ehueauLUjPT1Qc6K4o8 ZP5OcAmU1z1n6mkg75tXlUa6nNj/d8GTCX0FRbv/HhCltkoozOG+aedqX1fY4/51QHar r2QA== MIME-Version: 1.0 Received: by 10.224.176.3 with SMTP id bc3mr5727060qab.0.1336159806486; Fri, 04 May 2012 12:30:06 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 12:30:06 -0700 (PDT) In-Reply-To: References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> Date: Fri, 4 May 2012 12:30:06 -0700 Message-ID: From: AP To: Jan Beulich Content-Type: multipart/mixed; boundary=20cf303b410fa0f89904bf3af225 Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf303b410fa0f89904bf3af225 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 3, 2012 at 11:09 AM, AP wrote: > On Thu, May 3, 2012 at 2:15 AM, Jan Beulich wrote: >>>>> On 02.05.12 at 20:42, AP wrote: >>> On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>>>> I somehow thought that this has been fixed but I've been >>>>> getting reports that people are running into this. >>>> >>>> "this" being what? I too thought that all xsave related issues were >>>> sorted out by now. >>> >>> I see the following crash if I run without xsave=0 with Ubuntu 11.10 >>> 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with >>> Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. >> >> And in the thread starting at >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html >> I gave debugging instructions that apparently no-one followed so >> far. Without someone seeing the problem doing so I don't think we >> will ever get anywhere with this (unless, as also indicated there, >> someone can spot something wrong with the code that non-obvious >> to everyone else). > > I missed that thread. I will add some debugging to > pv_guest_cr4_fixup() and the XSETBV handling in > emulate_privileged_op() and post the output. I ran with the attached xsave_debug patch and saw the following output: (XEN) CPU: After generic identify, caps: bfebfbff 28100800 00000000 00000000 17bae3ff 00000000 00000001 00000000 (XEN) CPU: After vendor identify, caps: bfebfbff 28100800 00000000 00000000 17bae3ff 00000000 00000001 00000000 (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) CPU: After all inits, caps: bfebfbff 28100800 00000000 00003f40 17bae3ff 00000000 00000001 00000000 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4: 0x2660 [ 6.791945] invalid opcode: 0000 [#1] SMP >From the above I realized that X86_CR4_OSXSAVE was never getting set in v->arch.pv_vcpu.ctrlreg[4]. So I tried the following patch: diff -r 5a0d60bb536b xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s hv_cr4_mask &= ~X86_CR4_DE; if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) hv_cr4_mask &= ~X86_CR4_FSGSBASE; - if ( xsave_enabled(v) ) - hv_cr4_mask &= ~X86_CR4_OSXSAVE; if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) gdprintk(XENLOG_WARNING, diff -r 5a0d60bb536b xen/include/asm-x86/domain.h --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s & ~X86_CR4_DE) #define real_cr4_to_pv_guest_cr4(c) \ ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) + | X86_CR4_SMEP)) void domain_cpuid(struct domain *d, unsigned int input, That allowed the system to boot successfully though I did see the following message: (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 Not sure if the above patch is right fix but I hope it was at least helpful in pointing at where the problem might be. BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. Thanks, AP --20cf303b410fa0f89904bf3af225 Content-Type: application/octet-stream; name="xsave_debug.patch" Content-Disposition: attachment; filename="xsave_debug.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1tmyvda0 ZGlmZiAtciA1YTBkNjBiYjUzNmIgeGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwotLS0gYS94ZW4v YXJjaC94ODYvY3B1L2NvbW1vbi5jCUZyaSBBcHIgMjcgMjE6MTA6NTkgMjAxMiAtMDcwMAorKysg Yi94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCUZyaSBNYXkgMDQgMTI6MDE6NDIgMjAxMiAtMDcw MApAQCAtMzA1LDYgKzMwNSw3IEBAIHN0YXRpYyB2b2lkIF9fY3B1aW5pdCBzcXVhc2hfdGhlX3N0 dXBpZF8KIAogI2VuZGlmCiAKKyNkZWZpbmUgTk9JU1lfQ0FQUyAxCiAvKgogICogVGhpcyBkb2Vz IHRoZSBoYXJkIHdvcmsgb2YgYWN0dWFsbHkgcGlja2luZyBhcGFydCB0aGUgQ1BVIHN0dWZmLi4u CiAgKi8KZGlmZiAtciA1YTBkNjBiYjUzNmIgeGVuL2FyY2gveDg2L2RvbWFpbi5jCi0tLSBhL3hl bi9hcmNoL3g4Ni9kb21haW4uYwlGcmkgQXByIDI3IDIxOjEwOjU5IDIwMTIgLTA3MDAKKysrIGIv eGVuL2FyY2gveDg2L2RvbWFpbi5jCUZyaSBNYXkgMDQgMTI6MDE6NDIgMjAxMiAtMDcwMApAQCAt Njk5LDYgKzY5OSwxMCBAQCB1bnNpZ25lZCBsb25nIHB2X2d1ZXN0X2NyNF9maXh1cChjb25zdCBz CiAgICAgICAgICAgICAgICAgICJBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgJTA4bHggLT4g JTA4bHhcbiIsCiAgICAgICAgICAgICAgICAgIGh2X2NyNCwgZ3Vlc3RfY3I0KTsKIAorICAgIGdk cHJpbnRrKFhFTkxPR19JTkZPLCAidmNwdVslZF0gaHZfY3I0OiAweCVseCBodl9jcjRfbWFzazog MHglbHggIgorICAgICAgICAgICAgICJyZXR1cm5pbmcgY3I0OiAweCVseFxuIiwgdi0+dmNwdV9p ZCwgaHZfY3I0LCBodl9jcjRfbWFzaywKKyAgICAgICAgICAgICAoaHZfY3I0ICYgaHZfY3I0X21h c2spIHwgKGd1ZXN0X2NyNCAmIH5odl9jcjRfbWFzaykpOworCiAgICAgcmV0dXJuIChodl9jcjQg JiBodl9jcjRfbWFzaykgfCAoZ3Vlc3RfY3I0ICYgfmh2X2NyNF9tYXNrKTsKIH0KIApkaWZmIC1y IDVhMGQ2MGJiNTM2YiB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4vYXJjaC94ODYvdHJh cHMuYwlGcmkgQXByIDI3IDIxOjEwOjU5IDIwMTIgLTA3MDAKKysrIGIveGVuL2FyY2gveDg2L3Ry YXBzLmMJRnJpIE1heSAwNCAxMjowMTo0MiAyMDEyIC0wNzAwCkBAIC04NDYsNiArODQ2LDggQEAg c3RhdGljIHZvaWQgcHZfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZwogICAgICAgICBfX2NsZWFy X2JpdChYODZfRkVBVFVSRV9EQ0EgJSAzMiwgJmMpOwogICAgICAgICBpZiAoICF4c2F2ZV9lbmFi bGVkKGN1cnJlbnQpICkKICAgICAgICAgeworICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0lO Rk8sICJ2Y3B1WyVkXSBDbGVhcmluZyBYU0FWRVxuIiwKKyAgICAgICAgICAgICAgICAgICAgIGdl dF9wcm9jZXNzb3JfaWQoKSk7CiAgICAgICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9Y U0FWRSAlIDMyLCAmYyk7CiAgICAgICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9BVlgg JSAzMiwgJmMpOwogICAgICAgICB9CkBAIC04NjksOCArODcxLDEyIEBAIHN0YXRpYyB2b2lkIHB2 X2NwdWlkKHN0cnVjdCBjcHVfdXNlcl9yZWcKICAgICAgICAgYnJlYWs7CiAKICAgICBjYXNlIDB4 MDAwMDAwMGQ6IC8qIFhTQVZFICovCi0gICAgICAgIGlmICggIXhzYXZlX2VuYWJsZWQoY3VycmVu dCkgKQorICAgICAgICBnZHByaW50ayhYRU5MT0dfSU5GTywgInZjcHVbJWRdIGNwdWlkIFhTQVZF IiwgZ2V0X3Byb2Nlc3Nvcl9pZCgpKTsKKyAgICAgICAgaWYgKCAheHNhdmVfZW5hYmxlZChjdXJy ZW50KSApIHsKKyAgICAgICAgICAgIHByaW50aygiIG5vdCBzdXBwb3J0ZWRcbiIpOwogICAgICAg ICAgICAgZ290byB1bnN1cHBvcnRlZDsKKyAgICAgICAgfQorICAgICAgICBwcmludGsoIiBzdXBw b3J0ZWRcbiIpOwogICAgICAgICBicmVhazsKIAogICAgIGNhc2UgMHg4MDAwMDAwMToKQEAgLTIy NDMsNiArMjI0OSw5IEBAIHN0YXRpYyBpbnQgZW11bGF0ZV9wcml2aWxlZ2VkX29wKHN0cnVjdCAK ICAgICAgICAgICAgIGlmICggbG9jayB8fCByZXBfcHJlZml4IHx8IG9wc2l6ZV9wcmVmaXgKICAg ICAgICAgICAgICAgICAgfHwgISh2LT5hcmNoLnB2X3ZjcHUuY3RybHJlZ1s0XSAmIFg4Nl9DUjRf T1NYU0FWRSkgKQogICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxP R19FUlIsICJYU0VUQlY6IGxvY2s6ICVkIHJlcF9wcmVmaXg6ICVkICIKKyAgICAgICAgICAgICAg ICAgICAgICAgICAib3BzaXplX3ByZWZpeDogJWQgY3I0OiAweCVseFxuIiwgbG9jaywgcmVwX3By ZWZpeCwKKyAgICAgICAgICAgICAgICAgICAgICAgICBvcHNpemVfcHJlZml4LCB2LT5hcmNoLnB2 X3ZjcHUuY3RybHJlZ1s0XSk7CiAgICAgICAgICAgICAgICAgZG9fZ3Vlc3RfdHJhcChUUkFQX2lu dmFsaWRfb3AsIHJlZ3MsIDApOwogICAgICAgICAgICAgICAgIGdvdG8gc2tpcDsKICAgICAgICAg ICAgIH0KQEAgLTIzOTUsNiArMjQwNCw5IEBAIHN0YXRpYyBpbnQgZW11bGF0ZV9wcml2aWxlZ2Vk X29wKHN0cnVjdCAKIAogICAgICAgICBjYXNlIDQ6IC8qIFdyaXRlIENSNCAqLwogICAgICAgICAg ICAgdi0+YXJjaC5wdl92Y3B1LmN0cmxyZWdbNF0gPSBwdl9ndWVzdF9jcjRfZml4dXAodiwgKnJl Zyk7CisgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfSU5GTywgInZjcHVbJWRdIHB2IGNyNDog MHglbHggd3JpdGUgQ1I0OiAweCVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgIHYtPnZjcHVf aWQsIHYtPmFyY2gucHZfdmNwdS5jdHJscmVnWzRdLAorICAgICAgICAgICAgICAgICAgICAgcHZf Z3Vlc3RfY3I0X3RvX3JlYWxfY3I0KHYpKTsKICAgICAgICAgICAgIHdyaXRlX2NyNChwdl9ndWVz dF9jcjRfdG9fcmVhbF9jcjQodikpOwogICAgICAgICAgICAgYnJlYWs7CiAK --20cf303b410fa0f89904bf3af225 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf303b410fa0f89904bf3af225-- From xen-devel-bounces@lists.xen.org Fri May 04 19:30:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:30:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOCi-0008F5-NL; Fri, 04 May 2012 19:30:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOCg-0008Ex-Q6 for xen-devel@lists.xen.org; Fri, 04 May 2012 19:30:11 +0000 Received: from [193.109.254.147:42693] by server-12.bemta-14.messagelabs.com id A8/2A-05898-24E24AF4; Fri, 04 May 2012 19:30:10 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336159806!7710316!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13622 invoked from network); 4 May 2012 19:30:07 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 19:30:07 -0000 Received: by qcsc20 with SMTP id c20so196642qcs.32 for ; Fri, 04 May 2012 12:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6x6NwAiie8Ko0MbYCAg4bznKuUOnFlg9SuD8wYVyyo8=; b=YoqUJXalY/X3iUXtREIGQrfAAvnfqe+Ak50u80W7LTGs2rItuS17OkQ1LCNdJIYRqp RgwEn299ODa3rdOBRyv5LocN4jr+7CkcLtu/8xNrxgn5v7C9LCOlgjHUQLgKKSykKchR uYOB82hitL8WxN4+k6CvtZVIlDrMaU6sXxmzpQ1g5wqTQdWH1lNZ4iXNVU8ARCgffuRj Ml28JHDPXH4Hh3ZOpSN1qF/GI1ROOt8arBN46eaVEDpqRJY49ehueauLUjPT1Qc6K4o8 ZP5OcAmU1z1n6mkg75tXlUa6nNj/d8GTCX0FRbv/HhCltkoozOG+aedqX1fY4/51QHar r2QA== MIME-Version: 1.0 Received: by 10.224.176.3 with SMTP id bc3mr5727060qab.0.1336159806486; Fri, 04 May 2012 12:30:06 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 12:30:06 -0700 (PDT) In-Reply-To: References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> Date: Fri, 4 May 2012 12:30:06 -0700 Message-ID: From: AP To: Jan Beulich Content-Type: multipart/mixed; boundary=20cf303b410fa0f89904bf3af225 Cc: Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf303b410fa0f89904bf3af225 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 3, 2012 at 11:09 AM, AP wrote: > On Thu, May 3, 2012 at 2:15 AM, Jan Beulich wrote: >>>>> On 02.05.12 at 20:42, AP wrote: >>> On Wed, May 2, 2012 at 2:00 AM, Jan Beulich wrote: >>>>>>> On 30.04.12 at 21:37, Konrad Rzeszutek Wilk wrote: >>>>> I somehow thought that this has been fixed but I've been >>>>> getting reports that people are running into this. >>>> >>>> "this" being what? I too thought that all xsave related issues were >>>> sorted out by now. >>> >>> I see the following crash if I run without xsave=0 with Ubuntu 11.10 >>> 3.0.0-17 kernel (Intel(R) Core(TM) i7-2620M). I don't see this with >>> Xen 4.1.2. Looks like the OSXSAVE bit is not getting set in CR4. >> >> And in the thread starting at >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00426.html >> I gave debugging instructions that apparently no-one followed so >> far. Without someone seeing the problem doing so I don't think we >> will ever get anywhere with this (unless, as also indicated there, >> someone can spot something wrong with the code that non-obvious >> to everyone else). > > I missed that thread. I will add some debugging to > pv_guest_cr4_fixup() and the XSETBV handling in > emulate_privileged_op() and post the output. I ran with the attached xsave_debug patch and saw the following output: (XEN) CPU: After generic identify, caps: bfebfbff 28100800 00000000 00000000 17bae3ff 00000000 00000001 00000000 (XEN) CPU: After vendor identify, caps: bfebfbff 28100800 00000000 00000000 17bae3ff 00000000 00000001 00000000 (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) CPU: After all inits, caps: bfebfbff 28100800 00000000 00003f40 17bae3ff 00000000 00000001 00000000 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4: 0x2660 [ 6.791945] invalid opcode: 0000 [#1] SMP >From the above I realized that X86_CR4_OSXSAVE was never getting set in v->arch.pv_vcpu.ctrlreg[4]. So I tried the following patch: diff -r 5a0d60bb536b xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s hv_cr4_mask &= ~X86_CR4_DE; if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) hv_cr4_mask &= ~X86_CR4_FSGSBASE; - if ( xsave_enabled(v) ) - hv_cr4_mask &= ~X86_CR4_OSXSAVE; if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) gdprintk(XENLOG_WARNING, diff -r 5a0d60bb536b xen/include/asm-x86/domain.h --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s & ~X86_CR4_DE) #define real_cr4_to_pv_guest_cr4(c) \ ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) + | X86_CR4_SMEP)) void domain_cpuid(struct domain *d, unsigned int input, That allowed the system to boot successfully though I did see the following message: (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 Not sure if the above patch is right fix but I hope it was at least helpful in pointing at where the problem might be. BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. Thanks, AP --20cf303b410fa0f89904bf3af225 Content-Type: application/octet-stream; name="xsave_debug.patch" Content-Disposition: attachment; filename="xsave_debug.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1tmyvda0 ZGlmZiAtciA1YTBkNjBiYjUzNmIgeGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwotLS0gYS94ZW4v YXJjaC94ODYvY3B1L2NvbW1vbi5jCUZyaSBBcHIgMjcgMjE6MTA6NTkgMjAxMiAtMDcwMAorKysg Yi94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCUZyaSBNYXkgMDQgMTI6MDE6NDIgMjAxMiAtMDcw MApAQCAtMzA1LDYgKzMwNSw3IEBAIHN0YXRpYyB2b2lkIF9fY3B1aW5pdCBzcXVhc2hfdGhlX3N0 dXBpZF8KIAogI2VuZGlmCiAKKyNkZWZpbmUgTk9JU1lfQ0FQUyAxCiAvKgogICogVGhpcyBkb2Vz IHRoZSBoYXJkIHdvcmsgb2YgYWN0dWFsbHkgcGlja2luZyBhcGFydCB0aGUgQ1BVIHN0dWZmLi4u CiAgKi8KZGlmZiAtciA1YTBkNjBiYjUzNmIgeGVuL2FyY2gveDg2L2RvbWFpbi5jCi0tLSBhL3hl bi9hcmNoL3g4Ni9kb21haW4uYwlGcmkgQXByIDI3IDIxOjEwOjU5IDIwMTIgLTA3MDAKKysrIGIv eGVuL2FyY2gveDg2L2RvbWFpbi5jCUZyaSBNYXkgMDQgMTI6MDE6NDIgMjAxMiAtMDcwMApAQCAt Njk5LDYgKzY5OSwxMCBAQCB1bnNpZ25lZCBsb25nIHB2X2d1ZXN0X2NyNF9maXh1cChjb25zdCBz CiAgICAgICAgICAgICAgICAgICJBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgJTA4bHggLT4g JTA4bHhcbiIsCiAgICAgICAgICAgICAgICAgIGh2X2NyNCwgZ3Vlc3RfY3I0KTsKIAorICAgIGdk cHJpbnRrKFhFTkxPR19JTkZPLCAidmNwdVslZF0gaHZfY3I0OiAweCVseCBodl9jcjRfbWFzazog MHglbHggIgorICAgICAgICAgICAgICJyZXR1cm5pbmcgY3I0OiAweCVseFxuIiwgdi0+dmNwdV9p ZCwgaHZfY3I0LCBodl9jcjRfbWFzaywKKyAgICAgICAgICAgICAoaHZfY3I0ICYgaHZfY3I0X21h c2spIHwgKGd1ZXN0X2NyNCAmIH5odl9jcjRfbWFzaykpOworCiAgICAgcmV0dXJuIChodl9jcjQg JiBodl9jcjRfbWFzaykgfCAoZ3Vlc3RfY3I0ICYgfmh2X2NyNF9tYXNrKTsKIH0KIApkaWZmIC1y IDVhMGQ2MGJiNTM2YiB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4vYXJjaC94ODYvdHJh cHMuYwlGcmkgQXByIDI3IDIxOjEwOjU5IDIwMTIgLTA3MDAKKysrIGIveGVuL2FyY2gveDg2L3Ry YXBzLmMJRnJpIE1heSAwNCAxMjowMTo0MiAyMDEyIC0wNzAwCkBAIC04NDYsNiArODQ2LDggQEAg c3RhdGljIHZvaWQgcHZfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZwogICAgICAgICBfX2NsZWFy X2JpdChYODZfRkVBVFVSRV9EQ0EgJSAzMiwgJmMpOwogICAgICAgICBpZiAoICF4c2F2ZV9lbmFi bGVkKGN1cnJlbnQpICkKICAgICAgICAgeworICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0lO Rk8sICJ2Y3B1WyVkXSBDbGVhcmluZyBYU0FWRVxuIiwKKyAgICAgICAgICAgICAgICAgICAgIGdl dF9wcm9jZXNzb3JfaWQoKSk7CiAgICAgICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9Y U0FWRSAlIDMyLCAmYyk7CiAgICAgICAgICAgICBfX2NsZWFyX2JpdChYODZfRkVBVFVSRV9BVlgg JSAzMiwgJmMpOwogICAgICAgICB9CkBAIC04NjksOCArODcxLDEyIEBAIHN0YXRpYyB2b2lkIHB2 X2NwdWlkKHN0cnVjdCBjcHVfdXNlcl9yZWcKICAgICAgICAgYnJlYWs7CiAKICAgICBjYXNlIDB4 MDAwMDAwMGQ6IC8qIFhTQVZFICovCi0gICAgICAgIGlmICggIXhzYXZlX2VuYWJsZWQoY3VycmVu dCkgKQorICAgICAgICBnZHByaW50ayhYRU5MT0dfSU5GTywgInZjcHVbJWRdIGNwdWlkIFhTQVZF IiwgZ2V0X3Byb2Nlc3Nvcl9pZCgpKTsKKyAgICAgICAgaWYgKCAheHNhdmVfZW5hYmxlZChjdXJy ZW50KSApIHsKKyAgICAgICAgICAgIHByaW50aygiIG5vdCBzdXBwb3J0ZWRcbiIpOwogICAgICAg ICAgICAgZ290byB1bnN1cHBvcnRlZDsKKyAgICAgICAgfQorICAgICAgICBwcmludGsoIiBzdXBw b3J0ZWRcbiIpOwogICAgICAgICBicmVhazsKIAogICAgIGNhc2UgMHg4MDAwMDAwMToKQEAgLTIy NDMsNiArMjI0OSw5IEBAIHN0YXRpYyBpbnQgZW11bGF0ZV9wcml2aWxlZ2VkX29wKHN0cnVjdCAK ICAgICAgICAgICAgIGlmICggbG9jayB8fCByZXBfcHJlZml4IHx8IG9wc2l6ZV9wcmVmaXgKICAg ICAgICAgICAgICAgICAgfHwgISh2LT5hcmNoLnB2X3ZjcHUuY3RybHJlZ1s0XSAmIFg4Nl9DUjRf T1NYU0FWRSkgKQogICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxP R19FUlIsICJYU0VUQlY6IGxvY2s6ICVkIHJlcF9wcmVmaXg6ICVkICIKKyAgICAgICAgICAgICAg ICAgICAgICAgICAib3BzaXplX3ByZWZpeDogJWQgY3I0OiAweCVseFxuIiwgbG9jaywgcmVwX3By ZWZpeCwKKyAgICAgICAgICAgICAgICAgICAgICAgICBvcHNpemVfcHJlZml4LCB2LT5hcmNoLnB2 X3ZjcHUuY3RybHJlZ1s0XSk7CiAgICAgICAgICAgICAgICAgZG9fZ3Vlc3RfdHJhcChUUkFQX2lu dmFsaWRfb3AsIHJlZ3MsIDApOwogICAgICAgICAgICAgICAgIGdvdG8gc2tpcDsKICAgICAgICAg ICAgIH0KQEAgLTIzOTUsNiArMjQwNCw5IEBAIHN0YXRpYyBpbnQgZW11bGF0ZV9wcml2aWxlZ2Vk X29wKHN0cnVjdCAKIAogICAgICAgICBjYXNlIDQ6IC8qIFdyaXRlIENSNCAqLwogICAgICAgICAg ICAgdi0+YXJjaC5wdl92Y3B1LmN0cmxyZWdbNF0gPSBwdl9ndWVzdF9jcjRfZml4dXAodiwgKnJl Zyk7CisgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfSU5GTywgInZjcHVbJWRdIHB2IGNyNDog MHglbHggd3JpdGUgQ1I0OiAweCVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgIHYtPnZjcHVf aWQsIHYtPmFyY2gucHZfdmNwdS5jdHJscmVnWzRdLAorICAgICAgICAgICAgICAgICAgICAgcHZf Z3Vlc3RfY3I0X3RvX3JlYWxfY3I0KHYpKTsKICAgICAgICAgICAgIHdyaXRlX2NyNChwdl9ndWVz dF9jcjRfdG9fcmVhbF9jcjQodikpOwogICAgICAgICAgICAgYnJlYWs7CiAK --20cf303b410fa0f89904bf3af225 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf303b410fa0f89904bf3af225-- From xen-devel-bounces@lists.xen.org Fri May 04 19:32:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOEG-0008Iw-6H; Fri, 04 May 2012 19:31:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOEE-0008Il-3C for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:31:46 +0000 Received: from [193.109.254.147:13952] by server-12.bemta-14.messagelabs.com id 86/EA-05898-1AE24AF4; Fri, 04 May 2012 19:31:45 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1336159904!7738708!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7447 invoked from network); 4 May 2012 19:31:44 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 19:31:44 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jorabe mo54) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N02aa0o44Giviv for ; Fri, 4 May 2012 21:31:44 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 987FB18630 for ; Fri, 4 May 2012 21:31:43 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c414728d0d12f1c3e416e40cceefca2f0b00578e Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 21:31:42 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336159720 -7200 # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 xl.cfg: document the maxmem= option Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -484,6 +484,14 @@ are not using hardware assisted paging ( mode) and your guest workload consists of a a very large number of similar processes then increasing this value may improve performance. +=item B + +Specifies the maximum amount of memory the HVM guest can ever see. +In combination with the memory= option it will enable the PoD (populate +on demand) mode for the guest iff the values of memory= and maxmem= +differ. The guest needs a balloon driver in this case. The value of +maxmem= must be equal or greater than memory=. + =back =head3 Processor and Platform Features @@ -955,10 +963,6 @@ XXX XXX -=item B - -XXX - =item B XXX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:32:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOEG-0008Iw-6H; Fri, 04 May 2012 19:31:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOEE-0008Il-3C for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:31:46 +0000 Received: from [193.109.254.147:13952] by server-12.bemta-14.messagelabs.com id 86/EA-05898-1AE24AF4; Fri, 04 May 2012 19:31:45 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1336159904!7738708!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7447 invoked from network); 4 May 2012 19:31:44 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 19:31:44 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (jorabe mo54) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N02aa0o44Giviv for ; Fri, 4 May 2012 21:31:44 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 987FB18630 for ; Fri, 4 May 2012 21:31:43 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c414728d0d12f1c3e416e40cceefca2f0b00578e Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 04 May 2012 21:31:42 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336159720 -7200 # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 xl.cfg: document the maxmem= option Signed-off-by: Olaf Hering diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -484,6 +484,14 @@ are not using hardware assisted paging ( mode) and your guest workload consists of a a very large number of similar processes then increasing this value may improve performance. +=item B + +Specifies the maximum amount of memory the HVM guest can ever see. +In combination with the memory= option it will enable the PoD (populate +on demand) mode for the guest iff the values of memory= and maxmem= +differ. The guest needs a balloon driver in this case. The value of +maxmem= must be equal or greater than memory=. + =back =head3 Processor and Platform Features @@ -955,10 +963,6 @@ XXX XXX -=item B - -XXX - =item B XXX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:48:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:48:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUA-0000HR-OS; Fri, 04 May 2012 19:48:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUA-0000HM-2G for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:48:14 +0000 Received: from [85.158.143.35:28416] by server-2.bemta-4.messagelabs.com id E3/48-17550-D7234AF4; Fri, 04 May 2012 19:48:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336160890!7593534!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21347 invoked from network); 4 May 2012 19:48:11 -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; 4 May 2012 19:48:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44Jm7bC025115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 19:48: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 q44Jm6Eu011583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 19:48:06 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44Jm6HD010270; Fri, 4 May 2012 14:48:06 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 12:48:05 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 93D714031E; Fri, 4 May 2012 15:42:22 -0400 (EDT) Date: Fri, 4 May 2012 15:42:22 -0400 From: Konrad Rzeszutek Wilk To: Olaf Hering Message-ID: <20120504194222.GA28634@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336159720 -7200 > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > xl.cfg: document the maxmem= option > > Signed-off-by: Olaf Hering > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > mode) and your guest workload consists of a a very large number of > similar processes then increasing this value may improve performance. > > +=item B > + > +Specifies the maximum amount of memory the HVM guest can ever see. Isn't it also for PV guests (though without the PoD functionality)? > +In combination with the memory= option it will enable the PoD (populate > +on demand) mode for the guest iff the values of memory= and maxmem= > +differ. The guest needs a balloon driver in this case. The value of > +maxmem= must be equal or greater than memory=. > + > =back > > =head3 Processor and Platform Features > @@ -955,10 +963,6 @@ XXX > > XXX > > -=item B > - > -XXX > - > =item B > > XXX > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:48:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:48:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUA-0000HR-OS; Fri, 04 May 2012 19:48:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUA-0000HM-2G for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:48:14 +0000 Received: from [85.158.143.35:28416] by server-2.bemta-4.messagelabs.com id E3/48-17550-D7234AF4; Fri, 04 May 2012 19:48:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336160890!7593534!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTExMDIx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21347 invoked from network); 4 May 2012 19:48:11 -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; 4 May 2012 19:48:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q44Jm7bC025115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 19:48: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 q44Jm6Eu011583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 19:48:06 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q44Jm6HD010270; Fri, 4 May 2012 14:48:06 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 May 2012 12:48:05 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 93D714031E; Fri, 4 May 2012 15:42:22 -0400 (EDT) Date: Fri, 4 May 2012 15:42:22 -0400 From: Konrad Rzeszutek Wilk To: Olaf Hering Message-ID: <20120504194222.GA28634@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336159720 -7200 > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > xl.cfg: document the maxmem= option > > Signed-off-by: Olaf Hering > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > mode) and your guest workload consists of a a very large number of > similar processes then increasing this value may improve performance. > > +=item B > + > +Specifies the maximum amount of memory the HVM guest can ever see. Isn't it also for PV guests (though without the PoD functionality)? > +In combination with the memory= option it will enable the PoD (populate > +on demand) mode for the guest iff the values of memory= and maxmem= > +differ. The guest needs a balloon driver in this case. The value of > +maxmem= must be equal or greater than memory=. > + > =back > > =head3 Processor and Platform Features > @@ -955,10 +963,6 @@ XXX > > XXX > > -=item B > - > -XXX > - > =item B > > XXX > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUT-0000Ij-9r; Fri, 04 May 2012 19:48:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUR-0000IU-PI for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:48:32 +0000 Received: from [85.158.139.83:60862] by server-1.bemta-5.messagelabs.com id 42/9D-28458-E8234AF4; Fri, 04 May 2012 19:48:30 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336160907!19599256!1 X-Originating-IP: [209.85.216.48] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29849 invoked from network); 4 May 2012 19:48:29 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 19:48:29 -0000 Received: by qady23 with SMTP id y23so1852561qad.7 for ; Fri, 04 May 2012 12:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TIBLwvZgNVQLUW42Jj7WBuk8s4xbm6AXhJmw1rTX5JI=; b=SG6zW1iyET3akr5VsKUKl+V2oJrls6O2AmE/JEmgLn37a0KCmjKVqR6RooswA+MDz4 k9jknF1yHP7LTR2BVm7kmGlerPhVHG4IHyYJUwNl63FSrJOqrRP2Lc6doM1UTMOg30K9 oZ3oevhHN0R2+f2ML8ZB0LFuN2MCmWIkL9wMH6lFv5eEbc4dHtCbD886PdIV6haIsuhm ikOJ9zwItuKAcf92/Hw4x5d8OsqCTfs2/vwflhhGNf2wdJ3buplcd/3nP5u0MatCYqvv QxlLns6O+WoV1nZA7H1O/P2NnAxDv78MCyBCDOVTeD0+jwoKWvHyGx371IHdX8zxRywR nIWw== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr5806321qao.23.1336160906636; Fri, 04 May 2012 12:48:26 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 12:48:26 -0700 (PDT) In-Reply-To: <1332844592.25560.9.camel@zakaz.uk.xensource.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> Date: Fri, 4 May 2012 12:48:26 -0700 Message-ID: From: AP To: Ian Campbell Cc: "Keir \(Xen.org\)" , Andrew Cooper , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wro= te: > On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: >> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: >> > flight 11946 xen-unstable real [real] >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > =A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 =A0 = =A0 =A0fail REGR. vs. 11944 >> >> Host crash: >> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-x= l-credit2/serial-woodlouse.log >> >> This is the debug Andrew Cooper added recently to track down the IRQ >> assertion we've been seeing, sadly it looks like the debug code tries to >> call xfree from interrupt context and therefore doesn't produce full >> output :-( > > Are we still seeing the issue this debugging was intended to address? We > don't seem to be seeing the host crashes any more. Should the debug code > be patched up as in the following patch, otherwise when we do see it it > doesn't end up printing any useful info. > > Someone recently reported bugs.debian.org/665433 to Debian, is this the > same underlying issue? That report is with Xen 4.0 FWIW. I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging code added. Can the fix to the debugging code be checked in until the original issue has been fixed? Thanks, AP (XEN) *** IRQ BUG found *** (XEN) CPU0 -Testing vector 236 from bitmap 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,= 208 (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=3DIO-APIC-edge status=3D00000000 mapped, unbound (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 (XEN) ----[ Xen-4.2-unstable x86_64 debug=3Dy Tainted: C ]---- (XEN) CPU: 0 (XEN) RIP: e008:[] xfree+0x33/0x118 (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) Xen stack trace from rsp=3Dffff82c4802b7c58: (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 (XEN) Xen call trace: (XEN) [] xfree+0x33/0x118 (XEN) [] dump_irqs+0x2a4/0x2e8 (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db (XEN) [] do_IRQ+0x9e/0x5a4 (XEN) [] common_interrupt+0x26/0x30 (XEN) [] async_exception_cleanup+0x1/0x35a (XEN) [] syscall_enter+0xc8/0x122 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 19:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 19:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUT-0000Ij-9r; Fri, 04 May 2012 19:48:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOUR-0000IU-PI for xen-devel@lists.xensource.com; Fri, 04 May 2012 19:48:32 +0000 Received: from [85.158.139.83:60862] by server-1.bemta-5.messagelabs.com id 42/9D-28458-E8234AF4; Fri, 04 May 2012 19:48:30 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336160907!19599256!1 X-Originating-IP: [209.85.216.48] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29849 invoked from network); 4 May 2012 19:48:29 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 19:48:29 -0000 Received: by qady23 with SMTP id y23so1852561qad.7 for ; Fri, 04 May 2012 12:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TIBLwvZgNVQLUW42Jj7WBuk8s4xbm6AXhJmw1rTX5JI=; b=SG6zW1iyET3akr5VsKUKl+V2oJrls6O2AmE/JEmgLn37a0KCmjKVqR6RooswA+MDz4 k9jknF1yHP7LTR2BVm7kmGlerPhVHG4IHyYJUwNl63FSrJOqrRP2Lc6doM1UTMOg30K9 oZ3oevhHN0R2+f2ML8ZB0LFuN2MCmWIkL9wMH6lFv5eEbc4dHtCbD886PdIV6haIsuhm ikOJ9zwItuKAcf92/Hw4x5d8OsqCTfs2/vwflhhGNf2wdJ3buplcd/3nP5u0MatCYqvv QxlLns6O+WoV1nZA7H1O/P2NnAxDv78MCyBCDOVTeD0+jwoKWvHyGx371IHdX8zxRywR nIWw== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr5806321qao.23.1336160906636; Fri, 04 May 2012 12:48:26 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 12:48:26 -0700 (PDT) In-Reply-To: <1332844592.25560.9.camel@zakaz.uk.xensource.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> Date: Fri, 4 May 2012 12:48:26 -0700 Message-ID: From: AP To: Ian Campbell Cc: "Keir \(Xen.org\)" , Andrew Cooper , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wro= te: > On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: >> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: >> > flight 11946 xen-unstable real [real] >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > =A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 =A0 = =A0 =A0fail REGR. vs. 11944 >> >> Host crash: >> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-x= l-credit2/serial-woodlouse.log >> >> This is the debug Andrew Cooper added recently to track down the IRQ >> assertion we've been seeing, sadly it looks like the debug code tries to >> call xfree from interrupt context and therefore doesn't produce full >> output :-( > > Are we still seeing the issue this debugging was intended to address? We > don't seem to be seeing the host crashes any more. Should the debug code > be patched up as in the following patch, otherwise when we do see it it > doesn't end up printing any useful info. > > Someone recently reported bugs.debian.org/665433 to Debian, is this the > same underlying issue? That report is with Xen 4.0 FWIW. I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging code added. Can the fix to the debugging code be checked in until the original issue has been fixed? Thanks, AP (XEN) *** IRQ BUG found *** (XEN) CPU0 -Testing vector 236 from bitmap 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,= 208 (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=3DIO-APIC-edge status=3D00000000 mapped, unbound (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 (XEN) ----[ Xen-4.2-unstable x86_64 debug=3Dy Tainted: C ]---- (XEN) CPU: 0 (XEN) RIP: e008:[] xfree+0x33/0x118 (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) Xen stack trace from rsp=3Dffff82c4802b7c58: (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 (XEN) Xen call trace: (XEN) [] xfree+0x33/0x118 (XEN) [] dump_irqs+0x2a4/0x2e8 (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db (XEN) [] do_IRQ+0x9e/0x5a4 (XEN) [] common_interrupt+0x26/0x30 (XEN) [] async_exception_cleanup+0x1/0x35a (XEN) [] syscall_enter+0xc8/0x122 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 20:11:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 20: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 ) id 1SQOqc-00019K-2C; Fri, 04 May 2012 20:11:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOqa-00019F-TL for xen-devel@lists.xensource.com; Fri, 04 May 2012 20:11:25 +0000 Received: from [85.158.139.83:24559] by server-12.bemta-5.messagelabs.com id 3F/83-01344-CE734AF4; Fri, 04 May 2012 20:11:24 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336162281!19481127!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29640 invoked from network); 4 May 2012 20:11:22 -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; 4 May 2012 20:11:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,533,1330923600"; d="scan'208";a="193489031" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:11:21 -0400 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, 4 May 2012 16:11:20 -0400 Message-ID: <4FA437E7.6040105@citrix.com> Date: Fri, 4 May 2012 21:11:19 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: AP , Ian Jackson , "Keir (Xen.org)" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------070806000207030108000402" Cc: Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070806000207030108000402 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 04/05/12 20:48, AP wrote: > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wrote: >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: >>>> flight 11946 xen-unstable real [real] >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ >>>> >>>> Regressions :-( >>>> >>>> Tests which did not succeed and are blocking, >>>> including tests which could not be run: >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. vs. 11944 >>> Host crash: >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log >>> >>> This is the debug Andrew Cooper added recently to track down the IRQ >>> assertion we've been seeing, sadly it looks like the debug code tries to >>> call xfree from interrupt context and therefore doesn't produce full >>> output :-( >> Are we still seeing the issue this debugging was intended to address? We >> don't seem to be seeing the host crashes any more. Should the debug code >> be patched up as in the following patch, otherwise when we do see it it >> doesn't end up printing any useful info. >> >> Someone recently reported bugs.debian.org/665433 to Debian, is this the >> same underlying issue? That report is with Xen 4.0 FWIW. > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > code added. Can the fix to the debugging code be checked in until the > original issue has been fixed? > > Thanks, > AP > > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > status=00000000 mapped, unbound > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[] xfree+0x33/0x118 > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 > (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 > (XEN) Xen call trace: > (XEN) [] xfree+0x33/0x118 > (XEN) [] dump_irqs+0x2a4/0x2e8 > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > (XEN) [] do_IRQ+0x9e/0x5a4 > (XEN) [] common_interrupt+0x26/0x30 > (XEN) [] async_exception_cleanup+0x1/0x35a > (XEN) [] syscall_enter+0xc8/0x122 > (XEN) > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... The attached patch should prevent this panic, allowing for all the debug information to be printed to the console. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------070806000207030108000402 Content-Type: text/x-patch; name="irq-fix-dump_irqs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="irq-fix-dump_irqs.patch" # HG changeset patch # Parent 3b563b2c79f991f226bd383d40402d96ddf9a168 x86/irq: Prevent call to xfree in dump_irqs while in an irq context. Because of c/s 24707:96987c324a4f, dump_irqs() can now be called in an irq context when a bug condition is encountered. If this is the case, ignore the call to xsm_show_irq_ssid() and the subsequent call to xfree. This prevents an assertion failure in xfree(), and should allow all the debug information to be dumped, before failing with a BUG() because of the underlying race condition we are attempting to reproduce. Signed-off-by: Andrew Cooper diff -r 3b563b2c79f9 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2039,7 +2039,7 @@ static void dump_irqs(unsigned char key) struct domain *d; const struct pirq *info; unsigned long flags; - char *ssid; + char *ssid = NULL; printk("Guest interrupt information:\n"); @@ -2051,7 +2051,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); + if ( ! in_irq() ) + ssid = xsm_show_irq_sid(irq); spin_lock_irqsave(&desc->lock, flags); @@ -2098,7 +2099,8 @@ static void dump_irqs(unsigned char key) spin_unlock_irqrestore(&desc->lock, flags); - xfree(ssid); + if ( ! in_irq() ) + xfree(ssid); } dump_ioapic_irq_info(); --------------070806000207030108000402 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070806000207030108000402-- From xen-devel-bounces@lists.xen.org Fri May 04 20:11:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 20: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 ) id 1SQOqc-00019K-2C; Fri, 04 May 2012 20:11:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOqa-00019F-TL for xen-devel@lists.xensource.com; Fri, 04 May 2012 20:11:25 +0000 Received: from [85.158.139.83:24559] by server-12.bemta-5.messagelabs.com id 3F/83-01344-CE734AF4; Fri, 04 May 2012 20:11:24 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336162281!19481127!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNDk5MTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29640 invoked from network); 4 May 2012 20:11:22 -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; 4 May 2012 20:11:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,533,1330923600"; d="scan'208";a="193489031" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 May 2012 16:11:21 -0400 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, 4 May 2012 16:11:20 -0400 Message-ID: <4FA437E7.6040105@citrix.com> Date: Fri, 4 May 2012 21:11:19 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: AP , Ian Jackson , "Keir (Xen.org)" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------070806000207030108000402" Cc: Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070806000207030108000402 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 04/05/12 20:48, AP wrote: > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wrote: >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: >>>> flight 11946 xen-unstable real [real] >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ >>>> >>>> Regressions :-( >>>> >>>> Tests which did not succeed and are blocking, >>>> including tests which could not be run: >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. vs. 11944 >>> Host crash: >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log >>> >>> This is the debug Andrew Cooper added recently to track down the IRQ >>> assertion we've been seeing, sadly it looks like the debug code tries to >>> call xfree from interrupt context and therefore doesn't produce full >>> output :-( >> Are we still seeing the issue this debugging was intended to address? We >> don't seem to be seeing the host crashes any more. Should the debug code >> be patched up as in the following patch, otherwise when we do see it it >> doesn't end up printing any useful info. >> >> Someone recently reported bugs.debian.org/665433 to Debian, is this the >> same underlying issue? That report is with Xen 4.0 FWIW. > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > code added. Can the fix to the debugging code be checked in until the > original issue has been fixed? > > Thanks, > AP > > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > status=00000000 mapped, unbound > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[] xfree+0x33/0x118 > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 > (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 > (XEN) Xen call trace: > (XEN) [] xfree+0x33/0x118 > (XEN) [] dump_irqs+0x2a4/0x2e8 > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > (XEN) [] do_IRQ+0x9e/0x5a4 > (XEN) [] common_interrupt+0x26/0x30 > (XEN) [] async_exception_cleanup+0x1/0x35a > (XEN) [] syscall_enter+0xc8/0x122 > (XEN) > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... The attached patch should prevent this panic, allowing for all the debug information to be printed to the console. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------070806000207030108000402 Content-Type: text/x-patch; name="irq-fix-dump_irqs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="irq-fix-dump_irqs.patch" # HG changeset patch # Parent 3b563b2c79f991f226bd383d40402d96ddf9a168 x86/irq: Prevent call to xfree in dump_irqs while in an irq context. Because of c/s 24707:96987c324a4f, dump_irqs() can now be called in an irq context when a bug condition is encountered. If this is the case, ignore the call to xsm_show_irq_ssid() and the subsequent call to xfree. This prevents an assertion failure in xfree(), and should allow all the debug information to be dumped, before failing with a BUG() because of the underlying race condition we are attempting to reproduce. Signed-off-by: Andrew Cooper diff -r 3b563b2c79f9 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2039,7 +2039,7 @@ static void dump_irqs(unsigned char key) struct domain *d; const struct pirq *info; unsigned long flags; - char *ssid; + char *ssid = NULL; printk("Guest interrupt information:\n"); @@ -2051,7 +2051,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); + if ( ! in_irq() ) + ssid = xsm_show_irq_sid(irq); spin_lock_irqsave(&desc->lock, flags); @@ -2098,7 +2099,8 @@ static void dump_irqs(unsigned char key) spin_unlock_irqrestore(&desc->lock, flags); - xfree(ssid); + if ( ! in_irq() ) + xfree(ssid); } dump_ioapic_irq_info(); --------------070806000207030108000402 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070806000207030108000402-- From xen-devel-bounces@lists.xen.org Fri May 04 20:18:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 20:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOx6-0001Ki-To; Fri, 04 May 2012 20:18:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOx5-0001Kd-Mf for xen-devel@lists.xensource.com; Fri, 04 May 2012 20:18:07 +0000 Received: from [193.109.254.147:46562] by server-10.bemta-14.messagelabs.com id F5/58-05847-E7934AF4; Fri, 04 May 2012 20:18:06 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-4.tower-27.messagelabs.com!1336162686!7714416!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18202 invoked from network); 4 May 2012 20:18:06 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 20:18:06 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo80) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L021e7o44GaOtu ; Fri, 4 May 2012 22:18:03 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id CAC3E18637; Fri, 4 May 2012 22:18:02 +0200 (CEST) Date: Fri, 4 May 2012 22:18:02 +0200 From: Olaf Hering To: Konrad Rzeszutek Wilk Message-ID: <20120504201802.GA16466@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120504194222.GA28634@phenom.dumpdata.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Konrad Rzeszutek Wilk wrote: > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering > > # Date 1336159720 -7200 > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > xl.cfg: document the maxmem= option > > > > Signed-off-by: Olaf Hering > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > --- a/docs/man/xl.cfg.pod.5 > > +++ b/docs/man/xl.cfg.pod.5 > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > mode) and your guest workload consists of a a very large number of > > similar processes then increasing this value may improve performance. > > > > +=item B > > + > > +Specifies the maximum amount of memory the HVM guest can ever see. > > Isn't it also for PV guests (though without the PoD functionality)? Now that I look again at libxl__build_pre(), it appearently does also something for PV guests. I will resend the patch. Thanks for the review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 20:18:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 20:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOx6-0001Ki-To; Fri, 04 May 2012 20:18:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQOx5-0001Kd-Mf for xen-devel@lists.xensource.com; Fri, 04 May 2012 20:18:07 +0000 Received: from [193.109.254.147:46562] by server-10.bemta-14.messagelabs.com id F5/58-05847-E7934AF4; Fri, 04 May 2012 20:18:06 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-4.tower-27.messagelabs.com!1336162686!7714416!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyOTkzODg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18202 invoked from network); 4 May 2012 20:18:06 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2012 20:18:06 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0HFLs= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-093-097.pools.arcor-ip.net [88.65.93.97]) by smtp.strato.de (josoe mo80) (RZmta 29.2 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L021e7o44GaOtu ; Fri, 4 May 2012 22:18:03 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id CAC3E18637; Fri, 4 May 2012 22:18:02 +0200 (CEST) Date: Fri, 4 May 2012 22:18:02 +0200 From: Olaf Hering To: Konrad Rzeszutek Wilk Message-ID: <20120504201802.GA16466@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120504194222.GA28634@phenom.dumpdata.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, Konrad Rzeszutek Wilk wrote: > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering > > # Date 1336159720 -7200 > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > xl.cfg: document the maxmem= option > > > > Signed-off-by: Olaf Hering > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > --- a/docs/man/xl.cfg.pod.5 > > +++ b/docs/man/xl.cfg.pod.5 > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > mode) and your guest workload consists of a a very large number of > > similar processes then increasing this value may improve performance. > > > > +=item B > > + > > +Specifies the maximum amount of memory the HVM guest can ever see. > > Isn't it also for PV guests (though without the PoD functionality)? Now that I look again at libxl__build_pre(), it appearently does also something for PV guests. I will resend the patch. Thanks for the review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 21:14:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 21:14:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQPod-0001yX-FL; Fri, 04 May 2012 21:13:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQPob-0001yR-Lk for xen-devel@lists.xen.org; Fri, 04 May 2012 21:13:25 +0000 Received: from [85.158.138.51:33281] by server-11.bemta-3.messagelabs.com id D0/A9-18894-47644AF4; Fri, 04 May 2012 21:13:24 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336166003!14339863!1 X-Originating-IP: [98.138.229.117] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25401 invoked from network); 4 May 2012 21:13:24 -0000 Received: from nm36-vm5.bullet.mail.ne1.yahoo.com (HELO nm36-vm5.bullet.mail.ne1.yahoo.com) (98.138.229.117) by server-13.tower-174.messagelabs.com with SMTP; 4 May 2012 21:13:24 -0000 Received: from [98.138.90.51] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 Received: from [98.138.89.163] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 148402.87235.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 22159 invoked by uid 60001); 4 May 2012 21:13:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1336166003; bh=H1EtCpDHcbKgdnsA62hrnhpJR8K0Ikiz5qPusdoABTg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RXhhSkE/vRriQSN5lrWdEeVSbrLswfOobGyxxHpcr4mDzbMNhryrmvK5bvxWU45h/hGQiC+LMdYGeSllQdJe9u48RW8UCw3xZQTo/NWzWeVz923H6jBM9shDnVXx8raKQztgEnaSs9AZmO14pno9b2jiIfdlJ6HiT3UAjtKqZ9o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xckj0tQe6sGgIVLH7hJ10wSlLDjUkVbVWdfOKZIm3cDZY3cMUvyRCJ3xMDp8DbAI21ctZctcx4B1iTn093GUeAY+j3odxB3Fu3eyjmkryLuuPoou5uBeElVfP5ufhywMiuOCqK+ZLAX4i6SzFW7/+C8e5wuDr15RLrenE1XPa+c=; X-YMail-OSG: QeYIQVAVM1nbvSdwzLjiqQ0IhiDAGzcPHaiHKJip4th4nVY G4DeIvUzePECnAoUWnmuQpZPZHDcD3qSPWm.o7AZSJq9bqqb.OZmDWhgx0vc tcsV3Z9.xqaI9A3Df2YlVY3TAuH1_DpaTDsBljw19cVw_WLV_9QOkuzQjPpZ 3sk0WcOLQOZ4aR6.ASAgEs3sHYtx9WNdrlyVI2pa7G3n98RzPgwJaE7JDWYa _ZBe2oxChChh5BbBJyTW8gwNDggBbOlMmZfdHuZ_g6AEG7jSHZ9wXXpZvhyI n_LAltg2skvBbMaseD4XWEEctOFvkHxwBum6vvZy0CJ6oIrARuB6Gez.I_ve gfwMuynLRJViDHXQGiw.LRH8bzm8K8HZzN8jBlwo9oBUZ_BNjNlYRVfWPGFb uZQrlinzj9L77bje0brkJP8846VSVR8CjI5f5v3TtcW001PE2d6Nigwe81E. ZLM621xJs6ue91giHmCmtLoGqDgsKY6ye Received: from [128.173.237.43] by web124506.mail.ne1.yahoo.com via HTTP; Fri, 04 May 2012 14:13:23 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> <4FA3A1400200007800081808@nat28.tlf.novell.com> Message-ID: <1336166003.4115.YahooMailNeo@web124506.mail.ne1.yahoo.com> Date: Fri, 4 May 2012 14:13:23 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" In-Reply-To: <4FA3A1400200007800081808@nat28.tlf.novell.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Thanks! Also, if I pass some parameters in shared buffer (a shared page between domains), is it required to use a memory barrier before 'notify_remote_via_evtchn'? Ruslan ----- Original Message ----- From: Jan Beulich To: Ruslan Nikolaev Cc: "xen-devel@lists.xen.org" Sent: Friday, May 4, 2012 3:28 AM Subject: Re: [Xen-devel] Inter-domain event channel question >>> On 03.05.12 at 20:46, Ruslan Nikolaev wrote: > I want to set up an inter-domain event channel, and I want to receive > interrupts in both directions (i.e. Dom1 can independently send an interrupt > to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and > the other one on Dom 2, and on each domain I simply bind it to the > corresponding interrupt handler? Or do I need to have 4 ports: one pair is > used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? One port on each end should suffice. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 21:14:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 21:14:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQPod-0001yX-FL; Fri, 04 May 2012 21:13:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQPob-0001yR-Lk for xen-devel@lists.xen.org; Fri, 04 May 2012 21:13:25 +0000 Received: from [85.158.138.51:33281] by server-11.bemta-3.messagelabs.com id D0/A9-18894-47644AF4; Fri, 04 May 2012 21:13:24 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336166003!14339863!1 X-Originating-IP: [98.138.229.117] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25401 invoked from network); 4 May 2012 21:13:24 -0000 Received: from nm36-vm5.bullet.mail.ne1.yahoo.com (HELO nm36-vm5.bullet.mail.ne1.yahoo.com) (98.138.229.117) by server-13.tower-174.messagelabs.com with SMTP; 4 May 2012 21:13:24 -0000 Received: from [98.138.90.51] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 Received: from [98.138.89.163] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 04 May 2012 21:13:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 148402.87235.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 22159 invoked by uid 60001); 4 May 2012 21:13:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1336166003; bh=H1EtCpDHcbKgdnsA62hrnhpJR8K0Ikiz5qPusdoABTg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RXhhSkE/vRriQSN5lrWdEeVSbrLswfOobGyxxHpcr4mDzbMNhryrmvK5bvxWU45h/hGQiC+LMdYGeSllQdJe9u48RW8UCw3xZQTo/NWzWeVz923H6jBM9shDnVXx8raKQztgEnaSs9AZmO14pno9b2jiIfdlJ6HiT3UAjtKqZ9o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xckj0tQe6sGgIVLH7hJ10wSlLDjUkVbVWdfOKZIm3cDZY3cMUvyRCJ3xMDp8DbAI21ctZctcx4B1iTn093GUeAY+j3odxB3Fu3eyjmkryLuuPoou5uBeElVfP5ufhywMiuOCqK+ZLAX4i6SzFW7/+C8e5wuDr15RLrenE1XPa+c=; X-YMail-OSG: QeYIQVAVM1nbvSdwzLjiqQ0IhiDAGzcPHaiHKJip4th4nVY G4DeIvUzePECnAoUWnmuQpZPZHDcD3qSPWm.o7AZSJq9bqqb.OZmDWhgx0vc tcsV3Z9.xqaI9A3Df2YlVY3TAuH1_DpaTDsBljw19cVw_WLV_9QOkuzQjPpZ 3sk0WcOLQOZ4aR6.ASAgEs3sHYtx9WNdrlyVI2pa7G3n98RzPgwJaE7JDWYa _ZBe2oxChChh5BbBJyTW8gwNDggBbOlMmZfdHuZ_g6AEG7jSHZ9wXXpZvhyI n_LAltg2skvBbMaseD4XWEEctOFvkHxwBum6vvZy0CJ6oIrARuB6Gez.I_ve gfwMuynLRJViDHXQGiw.LRH8bzm8K8HZzN8jBlwo9oBUZ_BNjNlYRVfWPGFb uZQrlinzj9L77bje0brkJP8846VSVR8CjI5f5v3TtcW001PE2d6Nigwe81E. ZLM621xJs6ue91giHmCmtLoGqDgsKY6ye Received: from [128.173.237.43] by web124506.mail.ne1.yahoo.com via HTTP; Fri, 04 May 2012 14:13:23 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <1336070762.10686.YahooMailNeo@web124502.mail.ne1.yahoo.com> <4FA3A1400200007800081808@nat28.tlf.novell.com> Message-ID: <1336166003.4115.YahooMailNeo@web124506.mail.ne1.yahoo.com> Date: Fri, 4 May 2012 14:13:23 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" In-Reply-To: <4FA3A1400200007800081808@nat28.tlf.novell.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Inter-domain event channel question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Thanks! Also, if I pass some parameters in shared buffer (a shared page between domains), is it required to use a memory barrier before 'notify_remote_via_evtchn'? Ruslan ----- Original Message ----- From: Jan Beulich To: Ruslan Nikolaev Cc: "xen-devel@lists.xen.org" Sent: Friday, May 4, 2012 3:28 AM Subject: Re: [Xen-devel] Inter-domain event channel question >>> On 03.05.12 at 20:46, Ruslan Nikolaev wrote: > I want to set up an inter-domain event channel, and I want to receive > interrupts in both directions (i.e. Dom1 can independently send an interrupt > to Dom2 or vice versa).Do I need to have just 2 ports: one is on Dom 1 and > the other one on Dom 2, and on each domain I simply bind it to the > corresponding interrupt handler? Or do I need to have 4 ports: one pair is > used for Dom2-to-Dom1 interrupts and the other pair for Dom1-to-Dom2 interrupts? One port on each end should suffice. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 04 22:03:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 22: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 ) id 1SQQa8-0002m9-6w; Fri, 04 May 2012 22:02:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQQa7-0002m4-9x for xen-devel@lists.xen.org; Fri, 04 May 2012 22:02:31 +0000 Received: from [85.158.143.35:22130] by server-3.bemta-4.messagelabs.com id 1B/B8-05853-6F154AF4; Fri, 04 May 2012 22:02:30 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336168948!4392548!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26571 invoked from network); 4 May 2012 22:02:29 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 22:02:29 -0000 Received: by lahe6 with SMTP id e6so2959146lah.32 for ; Fri, 04 May 2012 15:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WhlZNT3t6VpqeEyS7wctK70vBcBrirnqBaMocJhEsxM=; b=0k+ul4kYSRMamPYJQyGTn/WBkXa3OSlNN8x5YnyMQgj9IkK1p0I1DSM5s1Ke1hKyMt VU8EK+aie3jFnozIL4MfqX72KjSrBnn30qaxkVe/+xoB1egY03G4zgNRYCHa9Mf+FPWY EhK/ghcZ84AJGafMb2cp8K06s7HRQZExI6X90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WhlZNT3t6VpqeEyS7wctK70vBcBrirnqBaMocJhEsxM=; b=UrSKmsh+J0t5U433QwyeV8Qy4t5eiqw+fCu02c+bTS/yu0IS7SgDyeBznfTBWCcxTK KpqdM/ZHLOjiO0HKkvwfgCbCfjsdQe2miSGdEM1IzjN1InarPsqwMeG61p1ljmhgobEY ThAt3WNPYPRHKCq7tbIdYLJyO9Q02bTD5h6dfcQnC8QmbaJnuZYUWLLYfwRB0GkXX3uR GdZ8jPk0YoDcaUM+nJCQm2ZTEPqRAl2qsQhZ6jbLfXr8vuurSBceK3Nbn6Y7R8jWoIDp iTwfxEa6z/VAMhNpKgdWy6b/oVH1uS7cqnS1qSGDtllEkx90bX4NpXpVF53pGufcBAsk uDOg== MIME-Version: 1.0 Received: by 10.152.162.68 with SMTP id xy4mr7843583lab.49.1336168948087; Fri, 04 May 2012 15:02:28 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Fri, 4 May 2012 15:02:28 -0700 (PDT) X-Originating-IP: [69.181.20.64] In-Reply-To: References: Date: Fri, 4 May 2012 15:02:28 -0700 Message-ID: From: Aravindh Puthiyaparambil To: Christian.Limpach@gmail.com X-Gm-Message-State: ALoCoQnd3cD+ff9MXUy3AjRvV1hZTJatnqJTo9Pg1GQJl6fXdIQ+vlabk/t2zD/nkijHv+XaJpjg Cc: tim@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5527823330018310019==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5527823330018310019== Content-Type: multipart/alternative; boundary=f46d0442682282ba0604bf3d13ad --f46d0442682282ba0604bf3d13ad Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 2, 2012 at 8:28 PM, Christian Limpach < christian.limpach@gmail.com> wrote: > On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil > wrote: >>>> Let me re-iterate: >>>> - if it's a leaf entry, then there's no need to call ept_free_entry >>>> - if you don't need to call ept_free_entry, then you can defer >>>> ept_sync_domain (subject to the iommu case) >>>> - you could pass in a pointer to a bool to indicate to the caller that >>>> ept_sync_domain was deferred and that the caller needs to do it, with >>>> a NULL pointer indicating that the caller doesn't support defer >> >> How does this look? > > It's missing the "leaf entry" part of my description of how I think > things should work. Without that, you're effectively ignoring the > following comment at the end of ept_set_entry: > /* Release the old intermediate tables, if any. This has to be the > last thing we do, after the ept_sync_domain() and removal > from the iommu tables, so as to avoid a potential > use-after-free. */ > > See inline comments in your patch below for how I'd change this, untested... > > christian > >> @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un >> int needs_sync = 1; >> struct domain *d = p2m->domain; >> ept_entry_t old_entry = { .epte = 0 }; >> + bool_t _sync_deferred = 0; > > don't need that > >> /* >> * the caller must make sure: >> @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un >> (target == 1 && hvm_hap_has_2mb(d)) || >> (target == 0)); >> >> + if (sync_deferred) >> + *sync_deferred = 1; >> + >> table = map_domain_page(ept_get_asr(d)); >> >> for ( i = ept_get_wl(d); i > target; i-- ) >> @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un >> >> /* No need to flush if the old entry wasn't valid */ >> if ( !is_epte_present(ept_entry) ) >> needs_sync = 0; > > This should be: > if ( !is_epte_present(ept_entry) || > (!target && sync_deferred) ) { > needs_sync = 0; > if (sync_deferred) > *sync_deferred = 0; > } > > This expresses the notion that we're going to skip the call to > ept_free_entry since it's a leaf entry (target == 0) and that the > caller will make the ept_sync_domain call (sync_deferred != NULL). > >> >> /* If we're replacing a non-leaf entry with a leaf entry >> (1GiB or 2MiB), >> * the intermediate tables will be freed below after the ept flush >> @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un >> >> ASSERT(is_epte_superpage(ept_entry)); >> >> + if ( sync_deferred ) >> + _sync_deferred = 1; >> + > > don't need that > >> split_ept_entry = atomic_read_ept_entry(ept_entry); >> >> if ( !ept_split_super_page(p2m, &split_ept_entry, i, target) ) >> @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un >> out: >> unmap_domain_page(table); >> >> - if ( needs_sync ) >> + if ( needs_sync && !_sync_deferred ) >> ept_sync_domain(p2m->domain); > > don't need that change, test on needs_sync is sufficient > >> >> if ( rv && iommu_enabled && need_iommu(p2m->domain) && >> need_modify_vtd_table ) > > Then at the end of ept_set_pte add the test for non-leaf, which is > more like an optimization/clarification since ept_free_entry has the > same test already. > > if ( target && is_epte_present(&old_entry) ) > ept_free_entry(p2m, &old_entry, target); Sorry for not following and thanks for your patience. Hopefully this looks correct. I have just included the pertinent bit of the patch you were commenting on. diff -r 9dda0efd8ce1 -r c180942992bf xen/arch/x86/mm/p2m-ept.c --- a/xen/arch/x86/mm/p2m-ept.c Fri Apr 27 17:57:55 2012 +0200 +++ b/xen/arch/x86/mm/p2m-ept.c Fri May 04 14:56:12 2012 -0700 @@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom /* * ept_set_entry() computes 'need_modify_vtd_table' for itself, * by observing whether any gfn->mfn translations are modified. + * If sync_deferred is not NULL, then the caller will take care of + * calling ept_sync_domain() in the cases where it can be deferred. */ static int ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, - unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma) + unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma, + bool_t *sync_deferred) { ept_entry_t *table, *ept_entry = NULL; unsigned long gfn_remainder = gfn; @@ -309,6 +312,9 @@ ept_set_entry(struct p2m_domain *p2m, un (target == 1 && hvm_hap_has_2mb(d)) || (target == 0)); + if (sync_deferred) + *sync_deferred = 1; + table = map_domain_page(ept_get_asr(d)); for ( i = ept_get_wl(d); i > target; i-- ) @@ -345,8 +351,12 @@ ept_set_entry(struct p2m_domain *p2m, un ept_entry_t new_entry = { .epte = 0 }; /* No need to flush if the old entry wasn't valid */ - if ( !is_epte_present(ept_entry) ) + if ( !is_epte_present(ept_entry) || (!target && sync_deferred) ) + { needs_sync = 0; + if ( sync_deferred ) + *sync_deferred = 0; + } /* If we're replacing a non-leaf entry with a leaf entry (1GiB or 2MiB), * the intermediate tables will be freed below after the ept flush @@ -477,7 +487,7 @@ out: last thing we do, after the ept_sync_domain() and removal from the iommu tables, so as to avoid a potential use-after-free. */ - if ( is_epte_present(&old_entry) ) + if ( target && is_epte_present(&old_entry) ) ept_free_entry(p2m, &old_entry, target); return rv; --f46d0442682282ba0604bf3d13ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2012 at 8:28 PM, Christian Limpach <christian.limpach@gmail.com> wrote:
>= ; On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:<= br> >>>> Let me re-iterate:
>>>> - if it's a lea= f entry, then there's no need to call ept_free_entry
>>>>= ; - if you don't need to call ept_free_entry, then you can defer
>>>> ept_sync_domain (subject to the iommu case)
>>>= ;> - you could pass in a pointer to a bool to indicate to the caller tha= t
>>>> ept_sync_domain was deferred and that the caller need= s to do it, with
>>>> a NULL pointer indicating that the caller doesn't supp= ort defer
>>
>> How does this look?
>
> It= 9;s missing the "leaf entry" part of my description of how I thin= k
> things should work. =A0Without that, you're effectively ignoring t= he
> following comment at the end of ept_set_entry:
> =A0 =A0/*= Release the old intermediate tables, if any. =A0This has to be the
>= =A0 =A0 =A0 last thing we do, after the ept_sync_domain() and removal
> =A0 =A0 =A0 from the iommu tables, so as to avoid a potential
> = =A0 =A0 =A0 use-after-free. */
>
> See inline comments in your = patch below for how I'd change this, untested...
>
> =A0 = =A0christian
>
>> @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, = un
>> =A0 =A0 int needs_sync =3D 1;
>> =A0 =A0 struct dom= ain *d =3D p2m->domain;
>> =A0 =A0 ept_entry_t old_entry =3D { = .epte =3D 0 };
>> + =A0 =A0bool_t _sync_deferred =3D 0;
>
> don't ne= ed that
>
>> =A0 =A0 /*
>> =A0 =A0 =A0* the caller = must make sure:
>> @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_do= main *p2m, un
>> =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 1 && hvm_hap_has_2mb= (d)) ||
>> =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 0));
>><= br>>> + =A0 =A0if (sync_deferred)
>> + =A0 =A0 =A0 =A0*sync_= deferred =3D 1;
>> +
>> =A0 =A0 table =3D map_domain_page= (ept_get_asr(d));
>>
>> =A0 =A0 for ( i =3D ept_get_wl(d); i > target; i-- = )
>> @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un=
>>
>> =A0 =A0 =A0 =A0 /* No need to flush if the old ent= ry wasn't valid */
>> =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) )
>> =A0= =A0 =A0 =A0 =A0 =A0 needs_sync =3D 0;
>
> This should be:
&= gt; =A0 =A0 =A0 =A0if ( !is_epte_present(ept_entry) ||
> =A0 =A0 =A0 = =A0 =A0 =A0 (!target && sync_deferred) ) {
> =A0 =A0 =A0 =A0 =A0 =A0needs_sync =3D 0;
> =A0 =A0 =A0 =A0 =A0 = =A0if (sync_deferred)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sync_deferred= =3D 0;
> =A0 =A0 =A0 =A0}
>
> This expresses the notion = that we're going to skip the call to
> ept_free_entry since it= 9;s a leaf entry (target =3D=3D 0) and that the
> caller will make the ept_sync_domain call (sync_deferred !=3D NULL).>
>>
>> =A0 =A0 =A0 =A0 /* If we're replacing a = non-leaf entry with a leaf entry
>> (1GiB or 2MiB),
>> = =A0 =A0 =A0 =A0 =A0* the intermediate tables will be freed below after the = ept flush
>> @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un
&g= t;>
>> =A0 =A0 =A0 =A0 ASSERT(is_epte_superpage(ept_entry));>>
>> + =A0 =A0 =A0 =A0if ( sync_deferred )
>> + = =A0 =A0 =A0 =A0 =A0 =A0_sync_deferred =3D 1;
>> +
>
> don't need that
>
>> =A0 =A0 = =A0 =A0 split_ept_entry =3D atomic_read_ept_entry(ept_entry);
>>>> =A0 =A0 =A0 =A0 if ( !ept_split_super_page(p2m, &split_ept_e= ntry, i, target) )
>> @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un
&g= t;> =A0out:
>> =A0 =A0 unmap_domain_page(table);
>>>> - =A0 =A0if ( needs_sync )
>> + =A0 =A0if ( needs_sync &= amp;& !_sync_deferred )
>> =A0 =A0 =A0 =A0 ept_sync_domain(p2m->domain);
>
> d= on't need that change, test on needs_sync is sufficient
>
>= >
>> =A0 =A0 if ( rv && iommu_enabled && need_i= ommu(p2m->domain) &&
>> need_modify_vtd_table )
>
> Then at the end of ept_set= _pte add the test for non-leaf, which is
> more like an optimization/= clarification since ept_free_entry has the
> same test already.
>
> =A0 =A0if ( target && is_epte_present(&old_entry) = )
> =A0 =A0 =A0 =A0ept_free_entry(p2m, &old_entry, target);
Sorry for not following and thanks for your patience. Hopefully this= looks correct. I have just included the pertinent bit of the patch you wer= e commenting on.

diff -r 9dda0efd8ce1 -r c180942992bf xen/arch/x86/= mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c Fri Apr 27 17:57:55 = 2012 +0200
+++ b/xen/arch/x86/mm/p2m-ept.c Fri May 04 14:56:12 20= 12 -0700
@@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom
=A0/*
=A0 * ept_set_entry() computes 'need_modify_vtd_tabl= e' for itself,
=A0 * by observing whether any gfn->mfn tra= nslations are modified.
+ * If sync_deferred is not NULL, then the caller will take care of
+ * calling ept_sync_domain() in the cases where it can be deferred= .
=A0 */
=A0static int
=A0ept_set_entry(struc= t p2m_domain *p2m, unsigned long gfn, mfn_t mfn,=A0
- =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int order, p2m_type_t p2mt, p2m_= access_t p2ma)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int order, p= 2m_type_t p2mt, p2m_access_t p2ma,
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0b= ool_t *sync_deferred)
=A0{
=A0 =A0 =A0ept_entry_t *table, *ept_entry =3D NULL;
=A0 =A0 = =A0unsigned long gfn_remainder =3D gfn;
@@ -309,6 +312,9 @@ ept_s= et_entry(struct p2m_domain *p2m, un
=A0 =A0 =A0 =A0 =A0 =A0 (targ= et =3D=3D 1 && hvm_hap_has_2mb(d)) ||
=A0 =A0 =A0 =A0 =A0 =A0 (target =3D=3D 0));
=A0
+ = =A0 =A0if (sync_deferred)
+ =A0 =A0 =A0 =A0*sync_deferred =3D 1;<= /div>
+
=A0 =A0 =A0table =3D map_domain_page(ept_get_asr(d));=
=A0
=A0 =A0 =A0for ( i =3D ept_get_wl(d); i > targe= t; i-- )
@@ -345,8 +351,12 @@ ept_set_entry(struct p2m_domain *p2m, un
=A0 =A0 =A0 =A0 =A0ept_entry_t new_entry =3D { .epte =3D 0 };
= =A0
=A0 =A0 =A0 =A0 =A0/* No need to flush if the old entry wasn&= #39;t valid */
- =A0 =A0 =A0 =A0if ( !is_epte_present(ept_entry) )
+ =A0 =A0 =A0= =A0if ( !is_epte_present(ept_entry) || (!target && sync_deferred) = )
+ =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0needs_s= ync =3D 0;
+ =A0 =A0 =A0 =A0 =A0 =A0if ( sync_deferred )
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sync_deferred =3D 0;
+ =A0= =A0 =A0 =A0}
=A0
=A0 =A0 =A0 =A0 =A0/* If we're re= placing a non-leaf entry with a leaf entry (1GiB or 2MiB),
=A0 = =A0 =A0 =A0 =A0 * the intermediate tables will be freed below after the ept= flush
@@ -477,7 +487,7 @@ out:
=A0 =A0 =A0 =A0 last thing we do, a= fter the ept_sync_domain() and removal
=A0 =A0 =A0 =A0 from the i= ommu tables, so as to avoid a potential
=A0 =A0 =A0 =A0 use-after= -free. */
- =A0 =A0if ( is_epte_present(&old_entry) )
+ =A0 =A0if ( tar= get && is_epte_present(&old_entry) )
=A0 =A0 =A0 =A0 = =A0ept_free_entry(p2m, &old_entry, target);
=A0
=A0= =A0 =A0return rv;


--f46d0442682282ba0604bf3d13ad-- --===============5527823330018310019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5527823330018310019==-- From xen-devel-bounces@lists.xen.org Fri May 04 22:03:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 May 2012 22: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 ) id 1SQQa8-0002m9-6w; Fri, 04 May 2012 22:02:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQQa7-0002m4-9x for xen-devel@lists.xen.org; Fri, 04 May 2012 22:02:31 +0000 Received: from [85.158.143.35:22130] by server-3.bemta-4.messagelabs.com id 1B/B8-05853-6F154AF4; Fri, 04 May 2012 22:02:30 +0000 X-Env-Sender: aravindh@virtuata.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336168948!4392548!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26571 invoked from network); 4 May 2012 22:02:29 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 May 2012 22:02:29 -0000 Received: by lahe6 with SMTP id e6so2959146lah.32 for ; Fri, 04 May 2012 15:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WhlZNT3t6VpqeEyS7wctK70vBcBrirnqBaMocJhEsxM=; b=0k+ul4kYSRMamPYJQyGTn/WBkXa3OSlNN8x5YnyMQgj9IkK1p0I1DSM5s1Ke1hKyMt VU8EK+aie3jFnozIL4MfqX72KjSrBnn30qaxkVe/+xoB1egY03G4zgNRYCHa9Mf+FPWY EhK/ghcZ84AJGafMb2cp8K06s7HRQZExI6X90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WhlZNT3t6VpqeEyS7wctK70vBcBrirnqBaMocJhEsxM=; b=UrSKmsh+J0t5U433QwyeV8Qy4t5eiqw+fCu02c+bTS/yu0IS7SgDyeBznfTBWCcxTK KpqdM/ZHLOjiO0HKkvwfgCbCfjsdQe2miSGdEM1IzjN1InarPsqwMeG61p1ljmhgobEY ThAt3WNPYPRHKCq7tbIdYLJyO9Q02bTD5h6dfcQnC8QmbaJnuZYUWLLYfwRB0GkXX3uR GdZ8jPk0YoDcaUM+nJCQm2ZTEPqRAl2qsQhZ6jbLfXr8vuurSBceK3Nbn6Y7R8jWoIDp iTwfxEa6z/VAMhNpKgdWy6b/oVH1uS7cqnS1qSGDtllEkx90bX4NpXpVF53pGufcBAsk uDOg== MIME-Version: 1.0 Received: by 10.152.162.68 with SMTP id xy4mr7843583lab.49.1336168948087; Fri, 04 May 2012 15:02:28 -0700 (PDT) Received: by 10.112.25.135 with HTTP; Fri, 4 May 2012 15:02:28 -0700 (PDT) X-Originating-IP: [69.181.20.64] In-Reply-To: References: Date: Fri, 4 May 2012 15:02:28 -0700 Message-ID: From: Aravindh Puthiyaparambil To: Christian.Limpach@gmail.com X-Gm-Message-State: ALoCoQnd3cD+ff9MXUy3AjRvV1hZTJatnqJTo9Pg1GQJl6fXdIQ+vlabk/t2zD/nkijHv+XaJpjg Cc: tim@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5527823330018310019==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5527823330018310019== Content-Type: multipart/alternative; boundary=f46d0442682282ba0604bf3d13ad --f46d0442682282ba0604bf3d13ad Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 2, 2012 at 8:28 PM, Christian Limpach < christian.limpach@gmail.com> wrote: > On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil > wrote: >>>> Let me re-iterate: >>>> - if it's a leaf entry, then there's no need to call ept_free_entry >>>> - if you don't need to call ept_free_entry, then you can defer >>>> ept_sync_domain (subject to the iommu case) >>>> - you could pass in a pointer to a bool to indicate to the caller that >>>> ept_sync_domain was deferred and that the caller needs to do it, with >>>> a NULL pointer indicating that the caller doesn't support defer >> >> How does this look? > > It's missing the "leaf entry" part of my description of how I think > things should work. Without that, you're effectively ignoring the > following comment at the end of ept_set_entry: > /* Release the old intermediate tables, if any. This has to be the > last thing we do, after the ept_sync_domain() and removal > from the iommu tables, so as to avoid a potential > use-after-free. */ > > See inline comments in your patch below for how I'd change this, untested... > > christian > >> @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, un >> int needs_sync = 1; >> struct domain *d = p2m->domain; >> ept_entry_t old_entry = { .epte = 0 }; >> + bool_t _sync_deferred = 0; > > don't need that > >> /* >> * the caller must make sure: >> @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_domain *p2m, un >> (target == 1 && hvm_hap_has_2mb(d)) || >> (target == 0)); >> >> + if (sync_deferred) >> + *sync_deferred = 1; >> + >> table = map_domain_page(ept_get_asr(d)); >> >> for ( i = ept_get_wl(d); i > target; i-- ) >> @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un >> >> /* No need to flush if the old entry wasn't valid */ >> if ( !is_epte_present(ept_entry) ) >> needs_sync = 0; > > This should be: > if ( !is_epte_present(ept_entry) || > (!target && sync_deferred) ) { > needs_sync = 0; > if (sync_deferred) > *sync_deferred = 0; > } > > This expresses the notion that we're going to skip the call to > ept_free_entry since it's a leaf entry (target == 0) and that the > caller will make the ept_sync_domain call (sync_deferred != NULL). > >> >> /* If we're replacing a non-leaf entry with a leaf entry >> (1GiB or 2MiB), >> * the intermediate tables will be freed below after the ept flush >> @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un >> >> ASSERT(is_epte_superpage(ept_entry)); >> >> + if ( sync_deferred ) >> + _sync_deferred = 1; >> + > > don't need that > >> split_ept_entry = atomic_read_ept_entry(ept_entry); >> >> if ( !ept_split_super_page(p2m, &split_ept_entry, i, target) ) >> @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un >> out: >> unmap_domain_page(table); >> >> - if ( needs_sync ) >> + if ( needs_sync && !_sync_deferred ) >> ept_sync_domain(p2m->domain); > > don't need that change, test on needs_sync is sufficient > >> >> if ( rv && iommu_enabled && need_iommu(p2m->domain) && >> need_modify_vtd_table ) > > Then at the end of ept_set_pte add the test for non-leaf, which is > more like an optimization/clarification since ept_free_entry has the > same test already. > > if ( target && is_epte_present(&old_entry) ) > ept_free_entry(p2m, &old_entry, target); Sorry for not following and thanks for your patience. Hopefully this looks correct. I have just included the pertinent bit of the patch you were commenting on. diff -r 9dda0efd8ce1 -r c180942992bf xen/arch/x86/mm/p2m-ept.c --- a/xen/arch/x86/mm/p2m-ept.c Fri Apr 27 17:57:55 2012 +0200 +++ b/xen/arch/x86/mm/p2m-ept.c Fri May 04 14:56:12 2012 -0700 @@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom /* * ept_set_entry() computes 'need_modify_vtd_table' for itself, * by observing whether any gfn->mfn translations are modified. + * If sync_deferred is not NULL, then the caller will take care of + * calling ept_sync_domain() in the cases where it can be deferred. */ static int ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, - unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma) + unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma, + bool_t *sync_deferred) { ept_entry_t *table, *ept_entry = NULL; unsigned long gfn_remainder = gfn; @@ -309,6 +312,9 @@ ept_set_entry(struct p2m_domain *p2m, un (target == 1 && hvm_hap_has_2mb(d)) || (target == 0)); + if (sync_deferred) + *sync_deferred = 1; + table = map_domain_page(ept_get_asr(d)); for ( i = ept_get_wl(d); i > target; i-- ) @@ -345,8 +351,12 @@ ept_set_entry(struct p2m_domain *p2m, un ept_entry_t new_entry = { .epte = 0 }; /* No need to flush if the old entry wasn't valid */ - if ( !is_epte_present(ept_entry) ) + if ( !is_epte_present(ept_entry) || (!target && sync_deferred) ) + { needs_sync = 0; + if ( sync_deferred ) + *sync_deferred = 0; + } /* If we're replacing a non-leaf entry with a leaf entry (1GiB or 2MiB), * the intermediate tables will be freed below after the ept flush @@ -477,7 +487,7 @@ out: last thing we do, after the ept_sync_domain() and removal from the iommu tables, so as to avoid a potential use-after-free. */ - if ( is_epte_present(&old_entry) ) + if ( target && is_epte_present(&old_entry) ) ept_free_entry(p2m, &old_entry, target); return rv; --f46d0442682282ba0604bf3d13ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2012 at 8:28 PM, Christian Limpach <christian.limpach@gmail.com> wrote:
>= ; On Fri, Apr 27, 2012 at 9:22 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:<= br> >>>> Let me re-iterate:
>>>> - if it's a lea= f entry, then there's no need to call ept_free_entry
>>>>= ; - if you don't need to call ept_free_entry, then you can defer
>>>> ept_sync_domain (subject to the iommu case)
>>>= ;> - you could pass in a pointer to a bool to indicate to the caller tha= t
>>>> ept_sync_domain was deferred and that the caller need= s to do it, with
>>>> a NULL pointer indicating that the caller doesn't supp= ort defer
>>
>> How does this look?
>
> It= 9;s missing the "leaf entry" part of my description of how I thin= k
> things should work. =A0Without that, you're effectively ignoring t= he
> following comment at the end of ept_set_entry:
> =A0 =A0/*= Release the old intermediate tables, if any. =A0This has to be the
>= =A0 =A0 =A0 last thing we do, after the ept_sync_domain() and removal
> =A0 =A0 =A0 from the iommu tables, so as to avoid a potential
> = =A0 =A0 =A0 use-after-free. */
>
> See inline comments in your = patch below for how I'd change this, untested...
>
> =A0 = =A0christian
>
>> @@ -293,6 +296,7 @@ ept_set_entry(struct p2m_domain *p2m, = un
>> =A0 =A0 int needs_sync =3D 1;
>> =A0 =A0 struct dom= ain *d =3D p2m->domain;
>> =A0 =A0 ept_entry_t old_entry =3D { = .epte =3D 0 };
>> + =A0 =A0bool_t _sync_deferred =3D 0;
>
> don't ne= ed that
>
>> =A0 =A0 /*
>> =A0 =A0 =A0* the caller = must make sure:
>> @@ -309,6 +313,9 @@ ept_set_entry(struct p2m_do= main *p2m, un
>> =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 1 && hvm_hap_has_2mb= (d)) ||
>> =A0 =A0 =A0 =A0 =A0 =A0(target =3D=3D 0));
>><= br>>> + =A0 =A0if (sync_deferred)
>> + =A0 =A0 =A0 =A0*sync_= deferred =3D 1;
>> +
>> =A0 =A0 table =3D map_domain_page= (ept_get_asr(d));
>>
>> =A0 =A0 for ( i =3D ept_get_wl(d); i > target; i-- = )
>> @@ -346,7 +353,11 @@ ept_set_entry(struct p2m_domain *p2m, un=
>>
>> =A0 =A0 =A0 =A0 /* No need to flush if the old ent= ry wasn't valid */
>> =A0 =A0 =A0 =A0 if ( !is_epte_present(ept_entry) )
>> =A0= =A0 =A0 =A0 =A0 =A0 needs_sync =3D 0;
>
> This should be:
&= gt; =A0 =A0 =A0 =A0if ( !is_epte_present(ept_entry) ||
> =A0 =A0 =A0 = =A0 =A0 =A0 (!target && sync_deferred) ) {
> =A0 =A0 =A0 =A0 =A0 =A0needs_sync =3D 0;
> =A0 =A0 =A0 =A0 =A0 = =A0if (sync_deferred)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sync_deferred= =3D 0;
> =A0 =A0 =A0 =A0}
>
> This expresses the notion = that we're going to skip the call to
> ept_free_entry since it= 9;s a leaf entry (target =3D=3D 0) and that the
> caller will make the ept_sync_domain call (sync_deferred !=3D NULL).>
>>
>> =A0 =A0 =A0 =A0 /* If we're replacing a = non-leaf entry with a leaf entry
>> (1GiB or 2MiB),
>> = =A0 =A0 =A0 =A0 =A0* the intermediate tables will be freed below after the = ept flush
>> @@ -385,6 +396,9 @@ ept_set_entry(struct p2m_domain *p2m, un
&g= t;>
>> =A0 =A0 =A0 =A0 ASSERT(is_epte_superpage(ept_entry));>>
>> + =A0 =A0 =A0 =A0if ( sync_deferred )
>> + = =A0 =A0 =A0 =A0 =A0 =A0_sync_deferred =3D 1;
>> +
>
> don't need that
>
>> =A0 =A0 = =A0 =A0 split_ept_entry =3D atomic_read_ept_entry(ept_entry);
>>>> =A0 =A0 =A0 =A0 if ( !ept_split_super_page(p2m, &split_ept_e= ntry, i, target) )
>> @@ -438,7 +452,7 @@ ept_set_entry(struct p2m_domain *p2m, un
&g= t;> =A0out:
>> =A0 =A0 unmap_domain_page(table);
>>>> - =A0 =A0if ( needs_sync )
>> + =A0 =A0if ( needs_sync &= amp;& !_sync_deferred )
>> =A0 =A0 =A0 =A0 ept_sync_domain(p2m->domain);
>
> d= on't need that change, test on needs_sync is sufficient
>
>= >
>> =A0 =A0 if ( rv && iommu_enabled && need_i= ommu(p2m->domain) &&
>> need_modify_vtd_table )
>
> Then at the end of ept_set= _pte add the test for non-leaf, which is
> more like an optimization/= clarification since ept_free_entry has the
> same test already.
>
> =A0 =A0if ( target && is_epte_present(&old_entry) = )
> =A0 =A0 =A0 =A0ept_free_entry(p2m, &old_entry, target);
Sorry for not following and thanks for your patience. Hopefully this= looks correct. I have just included the pertinent bit of the patch you wer= e commenting on.

diff -r 9dda0efd8ce1 -r c180942992bf xen/arch/x86/= mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c Fri Apr 27 17:57:55 = 2012 +0200
+++ b/xen/arch/x86/mm/p2m-ept.c Fri May 04 14:56:12 20= 12 -0700
@@ -274,10 +274,13 @@ static int ept_next_level(struct p2m_dom
=A0/*
=A0 * ept_set_entry() computes 'need_modify_vtd_tabl= e' for itself,
=A0 * by observing whether any gfn->mfn tra= nslations are modified.
+ * If sync_deferred is not NULL, then the caller will take care of
+ * calling ept_sync_domain() in the cases where it can be deferred= .
=A0 */
=A0static int
=A0ept_set_entry(struc= t p2m_domain *p2m, unsigned long gfn, mfn_t mfn,=A0
- =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int order, p2m_type_t p2mt, p2m_= access_t p2ma)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int order, p= 2m_type_t p2mt, p2m_access_t p2ma,
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0b= ool_t *sync_deferred)
=A0{
=A0 =A0 =A0ept_entry_t *table, *ept_entry =3D NULL;
=A0 =A0 = =A0unsigned long gfn_remainder =3D gfn;
@@ -309,6 +312,9 @@ ept_s= et_entry(struct p2m_domain *p2m, un
=A0 =A0 =A0 =A0 =A0 =A0 (targ= et =3D=3D 1 && hvm_hap_has_2mb(d)) ||
=A0 =A0 =A0 =A0 =A0 =A0 (target =3D=3D 0));
=A0
+ = =A0 =A0if (sync_deferred)
+ =A0 =A0 =A0 =A0*sync_deferred =3D 1;<= /div>
+
=A0 =A0 =A0table =3D map_domain_page(ept_get_asr(d));=
=A0
=A0 =A0 =A0for ( i =3D ept_get_wl(d); i > targe= t; i-- )
@@ -345,8 +351,12 @@ ept_set_entry(struct p2m_domain *p2m, un
=A0 =A0 =A0 =A0 =A0ept_entry_t new_entry =3D { .epte =3D 0 };
= =A0
=A0 =A0 =A0 =A0 =A0/* No need to flush if the old entry wasn&= #39;t valid */
- =A0 =A0 =A0 =A0if ( !is_epte_present(ept_entry) )
+ =A0 =A0 =A0= =A0if ( !is_epte_present(ept_entry) || (!target && sync_deferred) = )
+ =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0needs_s= ync =3D 0;
+ =A0 =A0 =A0 =A0 =A0 =A0if ( sync_deferred )
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*sync_deferred =3D 0;
+ =A0= =A0 =A0 =A0}
=A0
=A0 =A0 =A0 =A0 =A0/* If we're re= placing a non-leaf entry with a leaf entry (1GiB or 2MiB),
=A0 = =A0 =A0 =A0 =A0 * the intermediate tables will be freed below after the ept= flush
@@ -477,7 +487,7 @@ out:
=A0 =A0 =A0 =A0 last thing we do, a= fter the ept_sync_domain() and removal
=A0 =A0 =A0 =A0 from the i= ommu tables, so as to avoid a potential
=A0 =A0 =A0 =A0 use-after= -free. */
- =A0 =A0if ( is_epte_present(&old_entry) )
+ =A0 =A0if ( tar= get && is_epte_present(&old_entry) )
=A0 =A0 =A0 =A0 = =A0ept_free_entry(p2m, &old_entry, target);
=A0
=A0= =A0 =A0return rv;


--f46d0442682282ba0604bf3d13ad-- --===============5527823330018310019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5527823330018310019==-- From xen-devel-bounces@lists.xen.org Sat May 05 00:22:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 00:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQSkf-0004Z6-Ls; Sat, 05 May 2012 00:21:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQSke-0004Z1-GQ for xen-devel@lists.xensource.com; Sat, 05 May 2012 00:21:32 +0000 Received: from [85.158.143.35:8757] by server-3.bemta-4.messagelabs.com id C3/A4-05853-B8274AF4; Sat, 05 May 2012 00:21:31 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336177288!14212343!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12227 invoked from network); 5 May 2012 00:21:29 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 00:21:29 -0000 Received: by qadb33 with SMTP id b33so1524392qad.9 for ; Fri, 04 May 2012 17:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zL1cB30H+D7It5tA5DWBPcnVnt9PJsHQlLvytsJbkRA=; b=VdrE3Vh0O/TfR9UWNqWou9TX68LNreH48zvAAFX2HoQe4+n1eAAUz4JLjGolgamwsh A+sZSH3O33kWZVakK44LnhFdJQoF9ovaXfh2Kbc3O7wh6+sNR5SH9vA8u9l4UdWPy2np 2gvxIfpWVnNvZ3OGYCnegzo9XOUt5eXx4EJZI0ZTrk+cDdiQINMlKoniOuVb3cy2IN7D UeAJqx0n1pLDnpISPs9hIGQYZqWRou4BZOM0PRE1ueQwcosxe2Z1KUUA77JO5Cl6EXqL 2EP1yXaZvsyGy5ofNhru8KAq9TgDDxPxq2q8FTlp5eH97GO72EyFmdvIDtym1qFTqQNa CzFQ== MIME-Version: 1.0 Received: by 10.224.195.136 with SMTP id ec8mr13007123qab.58.1336177288026; Fri, 04 May 2012 17:21:28 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 17:21:27 -0700 (PDT) In-Reply-To: <4FA437E7.6040105@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> Date: Sat, 5 May 2012 00:21:27 +0000 Message-ID: From: AP To: Andrew Cooper Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8944874938970141147==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8944874938970141147== Content-Type: multipart/alternative; boundary=20cf3005dcae9c1bcb04bf3f04ed --20cf3005dcae9c1bcb04bf3f04ed Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 4, 2012 at 8:11 PM, Andrew Cooper wrote: > > On 04/05/12 20:48, AP wrote: > > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell > > wrote: > >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: > >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: > >>>> flight 11946 xen-unstable real [real] > >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ > >>>> > >>>> Regressions :-( > >>>> > >>>> Tests which did not succeed and are blocking, > >>>> including tests which could not be run: > >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. > >>>> vs. 11944 > >>> Host crash: > >>> > >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log > >>> > >>> This is the debug Andrew Cooper added recently to track down the IRQ > >>> assertion we've been seeing, sadly it looks like the debug code tries > >>> to > >>> call xfree from interrupt context and therefore doesn't produce full > >>> output :-( > >> Are we still seeing the issue this debugging was intended to address? > >> We > >> don't seem to be seeing the host crashes any more. Should the debug > >> code > >> be patched up as in the following patch, otherwise when we do see it it > >> doesn't end up printing any useful info. > >> > >> Someone recently reported bugs.debian.org/665433 to Debian, is this the > >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > > code added. Can the fix to the debugging code be checked in until the > > original issue has been fixed? > > > > Thanks, > > AP > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > > > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > > (XEN) CPU: 0 > > (XEN) RIP: e008:[] xfree+0x33/0x118 > > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: > > 0000000000000000 > > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: > > 0000000000000000 > > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: > > 0000000000000004 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > > 0000000000000010 > > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: > > ffff830214ac0ca8 > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: > > 00000000000426f0 > > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c > > ffff830214ac0ca8 > > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a > > ffff82c400000020 > > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 > > 0000000000000000 > > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 > > 000000000000000c > > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 > > ffff82c480168000 > > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 > > ffff82c4802b7f18 > > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 > > 0000000000000020 > > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 > > 0000000000000000 > > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 > > ffff8300da996000 > > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 > > ffff82c4802b7e20 > > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 > > 0000000000000003 > > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 > > ffff82c480160426 > > (XEN) 0000000000000000 0000000000000000 0000000000000003 > > ffff8300da991000 > > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 > > ffff82c4802319a0 > > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 > > 0000000000000000 > > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 > > 0000002000000000 > > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 > > ffff82c4802b7e88 > > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 > > ffff82c4802230d8 > > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 > > ffffffff810013aa > > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 > > 0000000000000246 > > (XEN) Xen call trace: > > (XEN) [] xfree+0x33/0x118 > > (XEN) [] dump_irqs+0x2a4/0x2e8 > > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > > (XEN) [] do_IRQ+0x9e/0x5a4 > > (XEN) [] common_interrupt+0x26/0x30 > > (XEN) [] async_exception_cleanup+0x1/0x35a > > (XEN) [] syscall_enter+0xc8/0x122 > > (XEN) > > (XEN) > > (XEN) **************************************** > > (XEN) Panic on CPU 0: > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) **************************************** > > (XEN) > > (XEN) Reboot in five seconds... > The attached patch should prevent this panic, allowing for all the debug > information to be printed to the console. Thanks, that fixed it. Here is what I see now: (XEN) *** IRQ BUG found *** (XEN) CPU0 -Testing vector 236 from bitmap 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 mapped, unbound (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 1(-S--), (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 mapped, unbound (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 8(-S--), (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 9(-S--), (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 mapped, unbound [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? Let me know if you need any more info. Thanks, AP --20cf3005dcae9c1bcb04bf3f04ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 4, 2012 at 8:11 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>= ; On 04/05/12 20:48, AP wrote:
> > On Tue, Mar 27, 2012 at 3:36 AM= , Ian Campbell <Ian.Campbell@= citrix.com>
> > wrote:
> >> On Tue, 2012-02-14 at 10:44 +0000, Ian Ca= mpbell wrote:
> >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
> >>>> flight 11= 946 xen-unstable real [real]
> >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/<= br>> >>>>
> >>>> Regressions :-(
> &= gt;>>>
> >>>> Tests which did not succeed and are blocking,
>= >>>> including tests which could not be run:
> >>&= gt;> =A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 = =A0 =A0 =A0fail REGR.
> >>>> vs. 11944
> >>> Host crash:
> &g= t;>>
> >>> htt= p://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-cred= it2/serial-woodlouse.log
> >>>
> >>> This is the debug Andrew Cooper adde= d recently to track down the IRQ
> >>> assertion we've b= een seeing, sadly it looks like the debug code tries
> >>> t= o
> >>> call xfree from interrupt context and therefore doesn'= ;t produce full
> >>> output :-(
> >> Are we sti= ll seeing the issue this debugging was intended to address?
> >>= ; We
> >> don't seem to be seeing the host crashes any more. Should= the debug
> >> code
> >> be patched up as in the f= ollowing patch, otherwise when we do see it it
> >> doesn't= end up printing any useful info.
> >>
> >> Someone recently reported bugs.debian.org/665433 to Debian, is this the> >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugg= ing
> > code added. Can the fix to the debugging code be checked i= n until the
> > original issue has been fixed?
> >
> > Thanks,
> > AP
> >
> > (XEN) *** IRQ B= UG found ***
> > (XEN) CPU0 -Testing vector 236 from bitmap
>= ; >
> > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,= 168,171,192,200-201,208
> > (XEN) Guest interrupt information:
> > (XEN) =A0 =A0IRQ:= =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge
> > status=3D0000000= 0 mapped, unbound
> > (XEN) Assertion '!in_irq()' failed a= t xmalloc_tlsf.c:607
> > (XEN) ----[ Xen-4.2-unstable =A0x86_64 =A0debug=3Dy =A0Tainted: = =A0 =A0C ]----
> > (XEN) CPU: =A0 =A00
> > (XEN) RIP: =A0= =A0e008:[<ffff82c48012cefb>] xfree+0x33/0x118
> > (XEN) RFL= AGS: 0000000000010002 =A0 CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000 =A0 rbx: ffff830214ac0080 =A0 rcx:> > 0000000000000000
> > (XEN) rdx: ffff82c4802d8880 =A0 rs= i: 0000000000000083 =A0 rdi:
> > 0000000000000000
> > (XE= N) rbp: ffff82c4802b7c78 =A0 rsp: ffff82c4802b7c58 =A0 r8:
> > =A00000000000000004
> > (XEN) r9: =A00000000000000000 = =A0 r10: 0000000000000000 =A0 r11:
> > 0000000000000010
> &g= t; (XEN) r12: ffff830214ac0c80 =A0 r13: 000000000000000c =A0 r14:
> &= gt; ffff830214ac0ca8
> > (XEN) r15: 0000000000000000 =A0 cr0: 000000008005003b =A0 cr4:> > 00000000000426f0
> > (XEN) cr3: 0000000168971000 =A0 cr= 2: 0000000001095e00
> > (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 = =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> > (XEN) Xen stack trace from rsp=3Dffff82c4802b7c58:
> > (= XEN) =A0 =A0ffff830214ac0080 ffff830214ac0c80 000000000000000c
> >= ffff830214ac0ca8
> > (XEN) =A0 =A0ffff82c4802b7ce8 ffff82c4801664= d4 ffff82c4802e214a
> > ffff82c400000020
> > (XEN) =A0 =A0ffff82c4802b7cf8 00000= 00000000083 ffff830214ac00a8
> > 0000000000000000
> > (XE= N) =A0 =A000000000000000ec 00000000000000ec ffff830214ac0c80
> > 0= 00000000000000c
> > (XEN) =A0 =A0ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58> > ffff82c480168000
> > (XEN) =A0 =A0ffff82c4802b7f18 fff= f82c4802b7f18 000000ec00000000
> > ffff82c4802b7f18
> > (= XEN) =A0 =A00000000000000000 0000000000000000 ffff82c480302324
> > 0000000000000020
> > (XEN) =A0 =A0ffff82c4802b7dd8 00000= 00000000003 0000000000000000
> > 0000000000000000
> > (XE= N) =A0 =A0ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000
> > f= fff8300da996000
> > (XEN) =A0 =A00000000000000000 ffffffff802b7d90 ffff82c480159160> > ffff82c4802b7e20
> > (XEN) =A0 =A0ffff82c48015d7db fff= f82c4802b7f18 ffff8300da991000
> > 0000000000000003
> > (= XEN) =A0 =A00000000000000000 0000000000000000 00007d3b7fd48207
> > ffff82c480160426
> > (XEN) =A0 =A00000000000000000 00000= 00000000000 0000000000000003
> > ffff8300da991000
> > (XE= N) =A0 =A0ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282
> > f= fff82c4802319a0
> > (XEN) =A0 =A000000000deadbeef 0000000000000000 ffff83021c0b8081> > 0000000000000000
> > (XEN) =A0 =A00000000000000048 fff= f8801d7227ec0 ffff8300da991000
> > 0000002000000000
> > (= XEN) =A0 =A0ffff82c4801865c1 000000000000e008 0000000000000202
> > ffff82c4802b7e88
> > (XEN) =A0 =A0000000000000e010 00000= 00000000003 ffff82c4802b7ef8
> > ffff82c4802230d8
> > (XE= N) =A0 =A0ffff82c4802b7f18 0000000000000000 0000000000000246
> > f= fffffff810013aa
> > (XEN) =A0 =A00000000000000000 ffffffff810013aa 000000000000e030> > 0000000000000246
> > (XEN) Xen call trace:
> >= ; (XEN) =A0 =A0[<ffff82c48012cefb>] xfree+0x33/0x118
> > (XE= N) =A0 =A0[<ffff82c4801664d4>] dump_irqs+0x2a4/0x2e8
> > (XEN) =A0 =A0[<ffff82c480168000>] irq_move_cleanup_interrup= t+0x29f/0x2db
> > (XEN) =A0 =A0[<ffff82c4801683d3>] do_IRQ+0= x9e/0x5a4
> > (XEN) =A0 =A0[<ffff82c480160426>] common_inter= rupt+0x26/0x30
> > (XEN) =A0 =A0[<ffff82c4801865c1>] async_exception_cleanup+0= x1/0x35a
> > (XEN) =A0 =A0[<ffff82c480228438>] syscall_enter= +0xc8/0x122
> > (XEN)
> > (XEN)
> > (XEN) ******= **********************************
> > (XEN) Panic on CPU 0:
> > (XEN) Assertion '!in_irq()= ' failed at xmalloc_tlsf.c:607
> > (XEN) *********************= *******************
> > (XEN)
> > (XEN) Reboot in five se= conds...
> The attached patch should prevent this panic, allowing for all the deb= ug
> information to be printed to the console.

Thanks, that fi= xed it. Here is what I see now:

(XEN) *** IRQ BUG found ***
(XEN)= CPU0 -Testing vector 236 from bitmap 37,41,49,51,64,72,80,88,96,104,120,13= 6,145,152,158,160,168,175,182,192,200,211
(XEN) Guest interrupt information:
(XEN)=A0=A0=A0 IRQ:=A0=A0 0 affinity:= 01 vec:f0 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000000 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 1 affinity:01 vec:d3 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 1(-S--),
(XEN)=A0=A0=A0 IRQ:=A0=A0 2 affinity:ff vec:e2 type=3DXT-PIC=A0=A0=A0=A0=A0= =A0=A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0= 3 affinity:01 vec:40 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped= , unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 4 affinity:01 vec:48 type=3DIO-APIC-= edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 5 affinity:01 vec:50 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 6 affinity:= 01 vec:58 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 7 affinity:01 vec:60 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 8 affinity:08 vec:29 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 8(-S--),
(XEN)=A0= =A0=A0 IRQ:=A0=A0 9 affinity:02 vec:25 type=3DIO-APIC-level=A0=A0 status=3D= 00000030 in-flight=3D0 domain-list=3D0:=A0 9(-S--),
(XEN)=A0=A0=A0 IRQ:=A0 10 affinity:01 vec:78 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 11 affinity:01 v= ec:88 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
[ 5= 129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed.= .. blt ring idle [waiting on 1800652, at 1800652], missed IRQ?

Let me know if you need any more info.
Thanks,
AP

--20cf3005dcae9c1bcb04bf3f04ed-- --===============8944874938970141147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8944874938970141147==-- From xen-devel-bounces@lists.xen.org Sat May 05 00:22:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 00:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQSkf-0004Z6-Ls; Sat, 05 May 2012 00:21:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQSke-0004Z1-GQ for xen-devel@lists.xensource.com; Sat, 05 May 2012 00:21:32 +0000 Received: from [85.158.143.35:8757] by server-3.bemta-4.messagelabs.com id C3/A4-05853-B8274AF4; Sat, 05 May 2012 00:21:31 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336177288!14212343!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12227 invoked from network); 5 May 2012 00:21:29 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 00:21:29 -0000 Received: by qadb33 with SMTP id b33so1524392qad.9 for ; Fri, 04 May 2012 17:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zL1cB30H+D7It5tA5DWBPcnVnt9PJsHQlLvytsJbkRA=; b=VdrE3Vh0O/TfR9UWNqWou9TX68LNreH48zvAAFX2HoQe4+n1eAAUz4JLjGolgamwsh A+sZSH3O33kWZVakK44LnhFdJQoF9ovaXfh2Kbc3O7wh6+sNR5SH9vA8u9l4UdWPy2np 2gvxIfpWVnNvZ3OGYCnegzo9XOUt5eXx4EJZI0ZTrk+cDdiQINMlKoniOuVb3cy2IN7D UeAJqx0n1pLDnpISPs9hIGQYZqWRou4BZOM0PRE1ueQwcosxe2Z1KUUA77JO5Cl6EXqL 2EP1yXaZvsyGy5ofNhru8KAq9TgDDxPxq2q8FTlp5eH97GO72EyFmdvIDtym1qFTqQNa CzFQ== MIME-Version: 1.0 Received: by 10.224.195.136 with SMTP id ec8mr13007123qab.58.1336177288026; Fri, 04 May 2012 17:21:28 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Fri, 4 May 2012 17:21:27 -0700 (PDT) In-Reply-To: <4FA437E7.6040105@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> Date: Sat, 5 May 2012 00:21:27 +0000 Message-ID: From: AP To: Andrew Cooper Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8944874938970141147==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8944874938970141147== Content-Type: multipart/alternative; boundary=20cf3005dcae9c1bcb04bf3f04ed --20cf3005dcae9c1bcb04bf3f04ed Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 4, 2012 at 8:11 PM, Andrew Cooper wrote: > > On 04/05/12 20:48, AP wrote: > > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell > > wrote: > >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: > >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: > >>>> flight 11946 xen-unstable real [real] > >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ > >>>> > >>>> Regressions :-( > >>>> > >>>> Tests which did not succeed and are blocking, > >>>> including tests which could not be run: > >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. > >>>> vs. 11944 > >>> Host crash: > >>> > >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log > >>> > >>> This is the debug Andrew Cooper added recently to track down the IRQ > >>> assertion we've been seeing, sadly it looks like the debug code tries > >>> to > >>> call xfree from interrupt context and therefore doesn't produce full > >>> output :-( > >> Are we still seeing the issue this debugging was intended to address? > >> We > >> don't seem to be seeing the host crashes any more. Should the debug > >> code > >> be patched up as in the following patch, otherwise when we do see it it > >> doesn't end up printing any useful info. > >> > >> Someone recently reported bugs.debian.org/665433 to Debian, is this the > >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > > code added. Can the fix to the debugging code be checked in until the > > original issue has been fixed? > > > > Thanks, > > AP > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > > > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > > (XEN) CPU: 0 > > (XEN) RIP: e008:[] xfree+0x33/0x118 > > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: > > 0000000000000000 > > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: > > 0000000000000000 > > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: > > 0000000000000004 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > > 0000000000000010 > > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: > > ffff830214ac0ca8 > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: > > 00000000000426f0 > > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c > > ffff830214ac0ca8 > > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a > > ffff82c400000020 > > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 > > 0000000000000000 > > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 > > 000000000000000c > > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 > > ffff82c480168000 > > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 > > ffff82c4802b7f18 > > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 > > 0000000000000020 > > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 > > 0000000000000000 > > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 > > ffff8300da996000 > > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 > > ffff82c4802b7e20 > > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 > > 0000000000000003 > > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 > > ffff82c480160426 > > (XEN) 0000000000000000 0000000000000000 0000000000000003 > > ffff8300da991000 > > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 > > ffff82c4802319a0 > > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 > > 0000000000000000 > > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 > > 0000002000000000 > > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 > > ffff82c4802b7e88 > > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 > > ffff82c4802230d8 > > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 > > ffffffff810013aa > > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 > > 0000000000000246 > > (XEN) Xen call trace: > > (XEN) [] xfree+0x33/0x118 > > (XEN) [] dump_irqs+0x2a4/0x2e8 > > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > > (XEN) [] do_IRQ+0x9e/0x5a4 > > (XEN) [] common_interrupt+0x26/0x30 > > (XEN) [] async_exception_cleanup+0x1/0x35a > > (XEN) [] syscall_enter+0xc8/0x122 > > (XEN) > > (XEN) > > (XEN) **************************************** > > (XEN) Panic on CPU 0: > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) **************************************** > > (XEN) > > (XEN) Reboot in five seconds... > The attached patch should prevent this panic, allowing for all the debug > information to be printed to the console. Thanks, that fixed it. Here is what I see now: (XEN) *** IRQ BUG found *** (XEN) CPU0 -Testing vector 236 from bitmap 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 mapped, unbound (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 1(-S--), (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 mapped, unbound (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 8(-S--), (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 9(-S--), (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 mapped, unbound [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? Let me know if you need any more info. Thanks, AP --20cf3005dcae9c1bcb04bf3f04ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 4, 2012 at 8:11 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>= ; On 04/05/12 20:48, AP wrote:
> > On Tue, Mar 27, 2012 at 3:36 AM= , Ian Campbell <Ian.Campbell@= citrix.com>
> > wrote:
> >> On Tue, 2012-02-14 at 10:44 +0000, Ian Ca= mpbell wrote:
> >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote:
> >>>> flight 11= 946 xen-unstable real [real]
> >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/<= br>> >>>>
> >>>> Regressions :-(
> &= gt;>>>
> >>>> Tests which did not succeed and are blocking,
>= >>>> including tests which could not be run:
> >>&= gt;> =A0test-amd64-i386-xl-credit2 =A0 =A07 debian-install =A0 =A0 =A0 = =A0 =A0 =A0fail REGR.
> >>>> vs. 11944
> >>> Host crash:
> &g= t;>>
> >>> htt= p://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-cred= it2/serial-woodlouse.log
> >>>
> >>> This is the debug Andrew Cooper adde= d recently to track down the IRQ
> >>> assertion we've b= een seeing, sadly it looks like the debug code tries
> >>> t= o
> >>> call xfree from interrupt context and therefore doesn'= ;t produce full
> >>> output :-(
> >> Are we sti= ll seeing the issue this debugging was intended to address?
> >>= ; We
> >> don't seem to be seeing the host crashes any more. Should= the debug
> >> code
> >> be patched up as in the f= ollowing patch, otherwise when we do see it it
> >> doesn't= end up printing any useful info.
> >>
> >> Someone recently reported bugs.debian.org/665433 to Debian, is this the> >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugg= ing
> > code added. Can the fix to the debugging code be checked i= n until the
> > original issue has been fixed?
> >
> > Thanks,
> > AP
> >
> > (XEN) *** IRQ B= UG found ***
> > (XEN) CPU0 -Testing vector 236 from bitmap
>= ; >
> > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,= 168,171,192,200-201,208
> > (XEN) Guest interrupt information:
> > (XEN) =A0 =A0IRQ:= =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge
> > status=3D0000000= 0 mapped, unbound
> > (XEN) Assertion '!in_irq()' failed a= t xmalloc_tlsf.c:607
> > (XEN) ----[ Xen-4.2-unstable =A0x86_64 =A0debug=3Dy =A0Tainted: = =A0 =A0C ]----
> > (XEN) CPU: =A0 =A00
> > (XEN) RIP: =A0= =A0e008:[<ffff82c48012cefb>] xfree+0x33/0x118
> > (XEN) RFL= AGS: 0000000000010002 =A0 CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000 =A0 rbx: ffff830214ac0080 =A0 rcx:> > 0000000000000000
> > (XEN) rdx: ffff82c4802d8880 =A0 rs= i: 0000000000000083 =A0 rdi:
> > 0000000000000000
> > (XE= N) rbp: ffff82c4802b7c78 =A0 rsp: ffff82c4802b7c58 =A0 r8:
> > =A00000000000000004
> > (XEN) r9: =A00000000000000000 = =A0 r10: 0000000000000000 =A0 r11:
> > 0000000000000010
> &g= t; (XEN) r12: ffff830214ac0c80 =A0 r13: 000000000000000c =A0 r14:
> &= gt; ffff830214ac0ca8
> > (XEN) r15: 0000000000000000 =A0 cr0: 000000008005003b =A0 cr4:> > 00000000000426f0
> > (XEN) cr3: 0000000168971000 =A0 cr= 2: 0000000001095e00
> > (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 = =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> > (XEN) Xen stack trace from rsp=3Dffff82c4802b7c58:
> > (= XEN) =A0 =A0ffff830214ac0080 ffff830214ac0c80 000000000000000c
> >= ffff830214ac0ca8
> > (XEN) =A0 =A0ffff82c4802b7ce8 ffff82c4801664= d4 ffff82c4802e214a
> > ffff82c400000020
> > (XEN) =A0 =A0ffff82c4802b7cf8 00000= 00000000083 ffff830214ac00a8
> > 0000000000000000
> > (XE= N) =A0 =A000000000000000ec 00000000000000ec ffff830214ac0c80
> > 0= 00000000000000c
> > (XEN) =A0 =A0ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58> > ffff82c480168000
> > (XEN) =A0 =A0ffff82c4802b7f18 fff= f82c4802b7f18 000000ec00000000
> > ffff82c4802b7f18
> > (= XEN) =A0 =A00000000000000000 0000000000000000 ffff82c480302324
> > 0000000000000020
> > (XEN) =A0 =A0ffff82c4802b7dd8 00000= 00000000003 0000000000000000
> > 0000000000000000
> > (XE= N) =A0 =A0ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000
> > f= fff8300da996000
> > (XEN) =A0 =A00000000000000000 ffffffff802b7d90 ffff82c480159160> > ffff82c4802b7e20
> > (XEN) =A0 =A0ffff82c48015d7db fff= f82c4802b7f18 ffff8300da991000
> > 0000000000000003
> > (= XEN) =A0 =A00000000000000000 0000000000000000 00007d3b7fd48207
> > ffff82c480160426
> > (XEN) =A0 =A00000000000000000 00000= 00000000000 0000000000000003
> > ffff8300da991000
> > (XE= N) =A0 =A0ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282
> > f= fff82c4802319a0
> > (XEN) =A0 =A000000000deadbeef 0000000000000000 ffff83021c0b8081> > 0000000000000000
> > (XEN) =A0 =A00000000000000048 fff= f8801d7227ec0 ffff8300da991000
> > 0000002000000000
> > (= XEN) =A0 =A0ffff82c4801865c1 000000000000e008 0000000000000202
> > ffff82c4802b7e88
> > (XEN) =A0 =A0000000000000e010 00000= 00000000003 ffff82c4802b7ef8
> > ffff82c4802230d8
> > (XE= N) =A0 =A0ffff82c4802b7f18 0000000000000000 0000000000000246
> > f= fffffff810013aa
> > (XEN) =A0 =A00000000000000000 ffffffff810013aa 000000000000e030> > 0000000000000246
> > (XEN) Xen call trace:
> >= ; (XEN) =A0 =A0[<ffff82c48012cefb>] xfree+0x33/0x118
> > (XE= N) =A0 =A0[<ffff82c4801664d4>] dump_irqs+0x2a4/0x2e8
> > (XEN) =A0 =A0[<ffff82c480168000>] irq_move_cleanup_interrup= t+0x29f/0x2db
> > (XEN) =A0 =A0[<ffff82c4801683d3>] do_IRQ+0= x9e/0x5a4
> > (XEN) =A0 =A0[<ffff82c480160426>] common_inter= rupt+0x26/0x30
> > (XEN) =A0 =A0[<ffff82c4801865c1>] async_exception_cleanup+0= x1/0x35a
> > (XEN) =A0 =A0[<ffff82c480228438>] syscall_enter= +0xc8/0x122
> > (XEN)
> > (XEN)
> > (XEN) ******= **********************************
> > (XEN) Panic on CPU 0:
> > (XEN) Assertion '!in_irq()= ' failed at xmalloc_tlsf.c:607
> > (XEN) *********************= *******************
> > (XEN)
> > (XEN) Reboot in five se= conds...
> The attached patch should prevent this panic, allowing for all the deb= ug
> information to be printed to the console.

Thanks, that fi= xed it. Here is what I see now:

(XEN) *** IRQ BUG found ***
(XEN)= CPU0 -Testing vector 236 from bitmap 37,41,49,51,64,72,80,88,96,104,120,13= 6,145,152,158,160,168,175,182,192,200,211
(XEN) Guest interrupt information:
(XEN)=A0=A0=A0 IRQ:=A0=A0 0 affinity:= 01 vec:f0 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000000 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 1 affinity:01 vec:d3 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 1(-S--),
(XEN)=A0=A0=A0 IRQ:=A0=A0 2 affinity:ff vec:e2 type=3DXT-PIC=A0=A0=A0=A0=A0= =A0=A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0= 3 affinity:01 vec:40 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped= , unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 4 affinity:01 vec:48 type=3DIO-APIC-= edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 5 affinity:01 vec:50 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 6 affinity:= 01 vec:58 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 7 affinity:01 vec:60 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 8 affinity:08 vec:29 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 8(-S--),
(XEN)=A0= =A0=A0 IRQ:=A0=A0 9 affinity:02 vec:25 type=3DIO-APIC-level=A0=A0 status=3D= 00000030 in-flight=3D0 domain-list=3D0:=A0 9(-S--),
(XEN)=A0=A0=A0 IRQ:=A0 10 affinity:01 vec:78 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 11 affinity:01 v= ec:88 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
[ 5= 129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed.= .. blt ring idle [waiting on 1800652, at 1800652], missed IRQ?

Let me know if you need any more info.
Thanks,
AP

--20cf3005dcae9c1bcb04bf3f04ed-- --===============8944874938970141147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8944874938970141147==-- From xen-devel-bounces@lists.xen.org Sat May 05 05:59:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 05: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 ) id 1SQY1G-0002Bh-Au; Sat, 05 May 2012 05:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQY1E-0002Bc-6b for xen-devel@lists.xensource.com; Sat, 05 May 2012 05:59:00 +0000 Received: from [85.158.139.83:3367] by server-7.bemta-5.messagelabs.com id CF/81-16195-3A1C4AF4; Sat, 05 May 2012 05:58:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336197537!19519843!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24014 invoked from network); 5 May 2012 05:58:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 05:58:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12309853" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 05:58: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; Sat, 5 May 2012 06:58:56 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQY19-0007C9-Sy; Sat, 05 May 2012 05:58:55 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQY19-0000wS-SV; Sat, 05 May 2012 06:58:55 +0100 To: Message-ID: From: xen.org Date: Sat, 5 May 2012 06:58:55 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12791: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12791 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12791/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 9 guest-start fail pass in 12790 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12790 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv 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-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 05:59:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 05: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 ) id 1SQY1G-0002Bh-Au; Sat, 05 May 2012 05:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQY1E-0002Bc-6b for xen-devel@lists.xensource.com; Sat, 05 May 2012 05:59:00 +0000 Received: from [85.158.139.83:3367] by server-7.bemta-5.messagelabs.com id CF/81-16195-3A1C4AF4; Sat, 05 May 2012 05:58:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336197537!19519843!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24014 invoked from network); 5 May 2012 05:58:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 05:58:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12309853" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 05:58: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; Sat, 5 May 2012 06:58:56 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQY19-0007C9-Sy; Sat, 05 May 2012 05:58:55 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQY19-0000wS-SV; Sat, 05 May 2012 06:58:55 +0100 To: Message-ID: From: xen.org Date: Sat, 5 May 2012 06:58:55 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12791: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12791 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12791/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 9 guest-start fail pass in 12790 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12790 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv 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-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 10:34:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 10: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 ) id 1SQcJE-0003v1-NU; Sat, 05 May 2012 10:33:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcJC-0003uw-Mm for xen-devel@lists.xensource.com; Sat, 05 May 2012 10:33:50 +0000 Received: from [85.158.143.99:29613] by server-1.bemta-4.messagelabs.com id F1/B7-20925-E0205AF4; Sat, 05 May 2012 10:33:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336214028!21362882!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9218 invoked from network); 5 May 2012 10:33:49 -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 May 2012 10:33:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311029" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 10:33:47 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 11:33:47 +0100 Message-ID: <1336214027.3735.16.camel@dagon.hellion.org.uk> From: Ian Campbell To: Andrew Cooper Date: Sat, 5 May 2012 11:33:47 +0100 In-Reply-To: <4FA437E7.6040105@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , Daniel De Graaf , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 21:11 +0100, Andrew Cooper wrote: > On 04/05/12 20:48, AP wrote: > > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wrote: > >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: > >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: > >>>> flight 11946 xen-unstable real [real] > >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ > >>>> > >>>> Regressions :-( > >>>> > >>>> Tests which did not succeed and are blocking, > >>>> including tests which could not be run: > >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. vs. 11944 > >>> Host crash: > >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log > >>> > >>> This is the debug Andrew Cooper added recently to track down the IRQ > >>> assertion we've been seeing, sadly it looks like the debug code tries to > >>> call xfree from interrupt context and therefore doesn't produce full > >>> output :-( > >> Are we still seeing the issue this debugging was intended to address? We > >> don't seem to be seeing the host crashes any more. Should the debug code > >> be patched up as in the following patch, otherwise when we do see it it > >> doesn't end up printing any useful info. > >> > >> Someone recently reported bugs.debian.org/665433 to Debian, is this the > >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > > code added. Can the fix to the debugging code be checked in until the > > original issue has been fixed? > > > > Thanks, > > AP > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > > (XEN) CPU: 0 > > (XEN) RIP: e008:[] xfree+0x33/0x118 > > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 > > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 > > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 > > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 > > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 > > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 > > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 > > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c > > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 > > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 > > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 > > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 > > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 > > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 > > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 > > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 > > (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 > > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 > > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 > > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 > > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 > > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 > > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa > > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 > > (XEN) Xen call trace: > > (XEN) [] xfree+0x33/0x118 > > (XEN) [] dump_irqs+0x2a4/0x2e8 > > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > > (XEN) [] do_IRQ+0x9e/0x5a4 > > (XEN) [] common_interrupt+0x26/0x30 > > (XEN) [] async_exception_cleanup+0x1/0x35a > > (XEN) [] syscall_enter+0xc8/0x122 > > (XEN) > > (XEN) > > (XEN) **************************************** > > (XEN) Panic on CPU 0: > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) **************************************** > > (XEN) > > (XEN) Reboot in five seconds... > The attached patch should prevent this panic This is effectively the same as my patch from <1332844592.25560.9.camel@zakaz.uk.xensource.com>. I think "if (ssid) xfree(...)" is preferable to "if (in_irq()) xfree(...)" but not enough to prevent me: Acked-by: Ian Campbell If the debug code is going to stay for 4.2 then IMHO we should also take this patch to make it actually useful. Otherwise we should just revert the original debug patch before the release. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 10:34:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 10: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 ) id 1SQcJE-0003v1-NU; Sat, 05 May 2012 10:33:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcJC-0003uw-Mm for xen-devel@lists.xensource.com; Sat, 05 May 2012 10:33:50 +0000 Received: from [85.158.143.99:29613] by server-1.bemta-4.messagelabs.com id F1/B7-20925-E0205AF4; Sat, 05 May 2012 10:33:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336214028!21362882!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9218 invoked from network); 5 May 2012 10:33:49 -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 May 2012 10:33:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311029" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 10:33:47 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 11:33:47 +0100 Message-ID: <1336214027.3735.16.camel@dagon.hellion.org.uk> From: Ian Campbell To: Andrew Cooper Date: Sat, 5 May 2012 11:33:47 +0100 In-Reply-To: <4FA437E7.6040105@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , Daniel De Graaf , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 21:11 +0100, Andrew Cooper wrote: > On 04/05/12 20:48, AP wrote: > > On Tue, Mar 27, 2012 at 3:36 AM, Ian Campbell wrote: > >> On Tue, 2012-02-14 at 10:44 +0000, Ian Campbell wrote: > >>> On Mon, 2012-02-13 at 20:16 +0000, xen.org wrote: > >>>> flight 11946 xen-unstable real [real] > >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/ > >>>> > >>>> Regressions :-( > >>>> > >>>> Tests which did not succeed and are blocking, > >>>> including tests which could not be run: > >>>> test-amd64-i386-xl-credit2 7 debian-install fail REGR. vs. 11944 > >>> Host crash: > >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/11946/test-amd64-i386-xl-credit2/serial-woodlouse.log > >>> > >>> This is the debug Andrew Cooper added recently to track down the IRQ > >>> assertion we've been seeing, sadly it looks like the debug code tries to > >>> call xfree from interrupt context and therefore doesn't produce full > >>> output :-( > >> Are we still seeing the issue this debugging was intended to address? We > >> don't seem to be seeing the host crashes any more. Should the debug code > >> be patched up as in the following patch, otherwise when we do see it it > >> doesn't end up printing any useful info. > >> > >> Someone recently reported bugs.debian.org/665433 to Debian, is this the > >> same underlying issue? That report is with Xen 4.0 FWIW. > > I saw the issue (xen-unstable 25256:9dda0efd8ce1) that the debugging > > code added. Can the fix to the debugging code be checked in until the > > original issue has been fixed? > > > > Thanks, > > AP > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > 41,47,49,57,64,72,80,88,96,100,104,120,136,152,160-161,168,171,192,200-201,208 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Tainted: C ]---- > > (XEN) CPU: 0 > > (XEN) RIP: e008:[] xfree+0x33/0x118 > > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > > (XEN) rax: 0000000000000000 rbx: ffff830214ac0080 rcx: 0000000000000000 > > (XEN) rdx: ffff82c4802d8880 rsi: 0000000000000083 rdi: 0000000000000000 > > (XEN) rbp: ffff82c4802b7c78 rsp: ffff82c4802b7c58 r8: 0000000000000004 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000010 > > (XEN) r12: ffff830214ac0c80 r13: 000000000000000c r14: ffff830214ac0ca8 > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 > > (XEN) cr3: 0000000168971000 cr2: 0000000001095e00 > > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > > (XEN) Xen stack trace from rsp=ffff82c4802b7c58: > > (XEN) ffff830214ac0080 ffff830214ac0c80 000000000000000c ffff830214ac0ca8 > > (XEN) ffff82c4802b7ce8 ffff82c4801664d4 ffff82c4802e214a ffff82c400000020 > > (XEN) ffff82c4802b7cf8 0000000000000083 ffff830214ac00a8 0000000000000000 > > (XEN) 00000000000000ec 00000000000000ec ffff830214ac0c80 000000000000000c > > (XEN) ffff830214ac0ca8 ffff82c480302760 ffff82c4802b7d58 ffff82c480168000 > > (XEN) ffff82c4802b7f18 ffff82c4802b7f18 000000ec00000000 ffff82c4802b7f18 > > (XEN) 0000000000000000 0000000000000000 ffff82c480302324 0000000000000020 > > (XEN) ffff82c4802b7dd8 0000000000000003 0000000000000000 0000000000000000 > > (XEN) ffff82c4802b7dc8 ffff82c4801683d3 ffff8300da991000 ffff8300da996000 > > (XEN) 0000000000000000 ffffffff802b7d90 ffff82c480159160 ffff82c4802b7e20 > > (XEN) ffff82c48015d7db ffff82c4802b7f18 ffff8300da991000 0000000000000003 > > (XEN) 0000000000000000 0000000000000000 00007d3b7fd48207 ffff82c480160426 > > (XEN) 0000000000000000 0000000000000000 0000000000000003 ffff8300da991000 > > (XEN) ffff82c4802b7ef8 ffff82c4802b7f18 0000000000000282 ffff82c4802319a0 > > (XEN) 00000000deadbeef 0000000000000000 ffff83021c0b8081 0000000000000000 > > (XEN) 0000000000000048 ffff8801d7227ec0 ffff8300da991000 0000002000000000 > > (XEN) ffff82c4801865c1 000000000000e008 0000000000000202 ffff82c4802b7e88 > > (XEN) 000000000000e010 0000000000000003 ffff82c4802b7ef8 ffff82c4802230d8 > > (XEN) ffff82c4802b7f18 0000000000000000 0000000000000246 ffffffff810013aa > > (XEN) 0000000000000000 ffffffff810013aa 000000000000e030 0000000000000246 > > (XEN) Xen call trace: > > (XEN) [] xfree+0x33/0x118 > > (XEN) [] dump_irqs+0x2a4/0x2e8 > > (XEN) [] irq_move_cleanup_interrupt+0x29f/0x2db > > (XEN) [] do_IRQ+0x9e/0x5a4 > > (XEN) [] common_interrupt+0x26/0x30 > > (XEN) [] async_exception_cleanup+0x1/0x35a > > (XEN) [] syscall_enter+0xc8/0x122 > > (XEN) > > (XEN) > > (XEN) **************************************** > > (XEN) Panic on CPU 0: > > (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:607 > > (XEN) **************************************** > > (XEN) > > (XEN) Reboot in five seconds... > The attached patch should prevent this panic This is effectively the same as my patch from <1332844592.25560.9.camel@zakaz.uk.xensource.com>. I think "if (ssid) xfree(...)" is preferable to "if (in_irq()) xfree(...)" but not enough to prevent me: Acked-by: Ian Campbell If the debug code is going to stay for 4.2 then IMHO we should also take this patch to make it actually useful. Otherwise we should just revert the original debug patch before the release. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 11:05:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 11: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 ) id 1SQcnN-0004DD-Dn; Sat, 05 May 2012 11:05:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcnL-0004D8-1f for xen-devel@lists.xensource.com; Sat, 05 May 2012 11:04:59 +0000 Received: from [85.158.138.51:14288] by server-6.bemta-3.messagelabs.com id 2C/03-05145-A5905AF4; Sat, 05 May 2012 11:04:58 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336215897!19353916!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22935 invoked from network); 5 May 2012 11:04:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 11:04:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311131" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 11:04:37 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 12:04:37 +0100 Message-ID: <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 12:04:39 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: AP References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> In-Reply-To: Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Thanks, that fixed it. Here is what I see now: > > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > status=00000000 mapped, unbound > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > status=00000030 in-flight=0 domain-list=0: 1(-S--), > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > status=00000000 mapped, unbound > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > status=00000030 in-flight=0 domain-list=0: 8(-S--), > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > status=00000030 in-flight=0 domain-list=0: 9(-S--), > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > status=00000002 mapped, unbound > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > Let me know if you need any more info. > Thanks, > AP > There should be quite a lot more irq information dumped than just that. Was there any more on the console or had it given up by that point? It might be worth trying to set synchronous console to get all of that debug information? How easy is this error to reproduce for you? I never managed to reproduce it reliably enough to be able to debug? If you could provide your Xen boot console log, that would be very useful ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 11:05:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 11: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 ) id 1SQcnN-0004DD-Dn; Sat, 05 May 2012 11:05:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcnL-0004D8-1f for xen-devel@lists.xensource.com; Sat, 05 May 2012 11:04:59 +0000 Received: from [85.158.138.51:14288] by server-6.bemta-3.messagelabs.com id 2C/03-05145-A5905AF4; Sat, 05 May 2012 11:04:58 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336215897!19353916!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22935 invoked from network); 5 May 2012 11:04:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 11:04:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311131" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 11:04:37 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 12:04:37 +0100 Message-ID: <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 12:04:39 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: AP References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> In-Reply-To: Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Thanks, that fixed it. Here is what I see now: > > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > status=00000000 mapped, unbound > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > status=00000030 in-flight=0 domain-list=0: 1(-S--), > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > status=00000000 mapped, unbound > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > status=00000030 in-flight=0 domain-list=0: 8(-S--), > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > status=00000030 in-flight=0 domain-list=0: 9(-S--), > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > status=00000002 mapped, unbound > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > status=00000002 mapped, unbound > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > Let me know if you need any more info. > Thanks, > AP > There should be quite a lot more irq information dumped than just that. Was there any more on the console or had it given up by that point? It might be worth trying to set synchronous console to get all of that debug information? How easy is this error to reproduce for you? I never managed to reproduce it reliably enough to be able to debug? If you could provide your Xen boot console log, that would be very useful ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 11:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 11:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQctt-0004LD-8f; Sat, 05 May 2012 11:11:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcts-0004L6-JP for xen-devel@lists.xensource.com; Sat, 05 May 2012 11:11:44 +0000 Received: from [85.158.143.99:18056] by server-2.bemta-4.messagelabs.com id 5C/F9-17550-FEA05AF4; Sat, 05 May 2012 11:11:43 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336216303!26596303!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 5 May 2012 11:11:43 -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 May 2012 11:11:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311155" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 11:11:43 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 12:11:43 +0100 Message-ID: <4FA50AF1.8010608@citrix.com> Date: Sat, 5 May 2012 12:11:45 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <1336214027.3735.16.camel@dagon.hellion.org.uk> In-Reply-To: <1336214027.3735.16.camel@dagon.hellion.org.uk> Cc: Ian Jackson , Daniel De Graaf , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> The attached patch should prevent this panic > This is effectively the same as my patch from > <1332844592.25560.9.camel@zakaz.uk.xensource.com>. I think "if (ssid) > xfree(...)" is preferable to "if (in_irq()) xfree(...)" but not enough > to prevent me: > > Acked-by: Ian Campbell > > If the debug code is going to stay for 4.2 then IMHO we should also take > this patch to make it actually useful. Otherwise we should just revert > the original debug patch before the release. > > Yes - I was thinking the same. I suggest that when xen-4.2-testing.hg gets branched off unstable, this debugging gets put back to just being an assert as before. However, I am quite unsure as to what would happen with interrupts following that failed assert. I shall re-do the patch. I think it is a fairly sensible patch to have in even after the main debugging has been removed, especially if similar debugging needs to be done in the future. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 11:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 11:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQctt-0004LD-8f; Sat, 05 May 2012 11:11:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQcts-0004L6-JP for xen-devel@lists.xensource.com; Sat, 05 May 2012 11:11:44 +0000 Received: from [85.158.143.99:18056] by server-2.bemta-4.messagelabs.com id 5C/F9-17550-FEA05AF4; Sat, 05 May 2012 11:11:43 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336216303!26596303!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQyOA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 5 May 2012 11:11:43 -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 May 2012 11:11:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,535,1330905600"; d="scan'208";a="12311155" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 11:11:43 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 5 May 2012 12:11:43 +0100 Message-ID: <4FA50AF1.8010608@citrix.com> Date: Sat, 5 May 2012 12:11:45 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <1336214027.3735.16.camel@dagon.hellion.org.uk> In-Reply-To: <1336214027.3735.16.camel@dagon.hellion.org.uk> Cc: Ian Jackson , Daniel De Graaf , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> The attached patch should prevent this panic > This is effectively the same as my patch from > <1332844592.25560.9.camel@zakaz.uk.xensource.com>. I think "if (ssid) > xfree(...)" is preferable to "if (in_irq()) xfree(...)" but not enough > to prevent me: > > Acked-by: Ian Campbell > > If the debug code is going to stay for 4.2 then IMHO we should also take > this patch to make it actually useful. Otherwise we should just revert > the original debug patch before the release. > > Yes - I was thinking the same. I suggest that when xen-4.2-testing.hg gets branched off unstable, this debugging gets put back to just being an assert as before. However, I am quite unsure as to what would happen with interrupts following that failed assert. I shall re-do the patch. I think it is a fairly sensible patch to have in even after the main debugging has been removed, especially if similar debugging needs to be done in the future. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 05 18:42:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 18:42:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQjv6-0006fj-Dc; Sat, 05 May 2012 18:41:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQjv4-0006fe-KL for xen-devel@lists.xensource.com; Sat, 05 May 2012 18:41:26 +0000 Received: from [85.158.143.35:34467] by server-1.bemta-4.messagelabs.com id B9/E4-20925-55475AF4; Sat, 05 May 2012 18:41:25 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336243283!15142692!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20668 invoked from network); 5 May 2012 18:41:24 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 18:41:24 -0000 Received: by qadb33 with SMTP id b33so1826494qad.9 for ; Sat, 05 May 2012 11:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oQ5fY80Ei8P+sSXEtoxQjCpisTJwgcfnx46lpGGUpss=; b=uhgkvMuT57f8/mUrnDuhaFHuGJ7U8NvvojPyhcuRT6keaKa8I0CMaRiold1hGAymOu tzdGS38e6iXrNgTlnEDtPcQWsverwRgUtiYDrKUlnt6gWP5ycX3TtxfIjgLO6qTDALcU ztJYnTE5kaUudG1tcA9lU4K86qx2rx0n8IsEhj2pxD6I9LDWujDnSCG2pgpFPzXXBgfk 740kNzlTlYC3L6/855dGmwL7AMOFxcX2Vfdb2NxbIRAOm5VMSwxocK2T1X6VK7CkOYiv cJ+bfb4fDXxy923yqArSJgMNF3x09y3ql50+8K4C/VW3Mby8kLtMRDNdLL3S0ujreZLH BVxw== MIME-Version: 1.0 Received: by 10.229.135.143 with SMTP id n15mr5044106qct.70.1336243282628; Sat, 05 May 2012 11:41:22 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Sat, 5 May 2012 11:41:22 -0700 (PDT) In-Reply-To: <4FA50947.8030703@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 11:41:22 -0700 Message-ID: From: AP To: Andrew Cooper Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8936353274837748921==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8936353274837748921== Content-Type: multipart/alternative; boundary=00248c768f2a31d1bd04bf4e6258 --00248c768f2a31d1bd04bf4e6258 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper wrote: > > > > Thanks, that fixed it. Here is what I see now: > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > > status=00000030 in-flight=0 domain-list=0: 1(-S--), > > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > > status=00000000 mapped, unbound > > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > > status=00000030 in-flight=0 domain-list=0: 8(-S--), > > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > > status=00000030 in-flight=0 domain-list=0: 9(-S--), > > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > > status=00000002 mapped, unbound > > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > > > Let me know if you need any more info. > > Thanks, > > AP > > > > There should be quite a lot more irq information dumped than just that. > Was there any more on the console or had it given up by that point? It There was nothing more on the console. The system was hung. > might be worth trying to set synchronous console to get all of that > debug information? I was running with sync_console and console_to_ring options. > How easy is this error to reproduce for you? I never managed to > reproduce it reliably enough to be able to debug? I cannot reproduce it easily either. > If you could provide your Xen boot console log, that would be very useful I will send full logs the next time I see the problem. Thanks, AP --00248c768f2a31d1bd04bf4e6258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>= ;
> > Thanks, that fixed it. Here is what I see now:
> ><= br> > > (XEN) *** IRQ BUG found ***
> > (XEN) CPU0 -Testing vect= or 236 from bitmap
> > 37,41,49,51,64,72,80,88,96,104,120,136,145,= 152,158,160,168,175,182,192,200,211
> > (XEN) Guest interrupt info= rmation:
> > (XEN) =A0 =A0IRQ: =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge> > status=3D00000000 mapped, unbound
> > (XEN) =A0 =A0IRQ:= =A0 1 affinity:01 vec:d3 type=3DIO-APIC-edge
> > status=3D0000003= 0 in-flight=3D0 domain-list=3D0: =A01(-S--),
> > (XEN) =A0 =A0IRQ: =A0 2 affinity:ff vec:e2 type=3DXT-PIC
> = > status=3D00000000 mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 3= affinity:01 vec:40 type=3DIO-APIC-edge
> > status=3D00000002 mapp= ed, unbound
> > (XEN) =A0 =A0IRQ: =A0 4 affinity:01 vec:48 type=3D= IO-APIC-edge
> > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A0 5 affinity:01 vec:50 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 6 affinity:01 vec:58 ty= pe=3DIO-APIC-edge
> > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A0 7 affinity:01 vec:60 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 8 affinity:08 vec:29 ty= pe=3DIO-APIC-edge
> > status=3D00000030 in-flight=3D0 domain-list=3D0: =A08(-S--),
&= gt; > (XEN) =A0 =A0IRQ: =A0 9 affinity:02 vec:25 type=3DIO-APIC-level> > status=3D00000030 in-flight=3D0 domain-list=3D0: =A09(-S--),
= > > (XEN) =A0 =A0IRQ: =A010 affinity:01 vec:78 type=3DIO-APIC-edge > > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A011 affinity:01 vec:88 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > [ 5129.737147] [drm:i915_hangcheck_ring_idle]= *ERROR* Hangcheck timer
> > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed= IRQ?
> >
> > Let me know if you need any more info.
&= gt; > Thanks,
> > AP
> >
>
> There should = be quite a lot more irq information dumped than just that.
> Was there any more on the console or had it given up by that point? It=

There was nothing more on the console. The system was hung.

> might be worth trying to set synchronous console to ge= t all of that
> debug information?

I was running with sync_console and console_= to_ring options.

> How easy is this error to reproduce for you? I= never managed to
> reproduce it reliably enough to be able to debug?=

I cannot reproduce it easily either.=A0

> If you could provid= e your Xen boot console log, that would be very useful

I will send f= ull logs the next time I see the problem.

Thanks,
AP
--00248c768f2a31d1bd04bf4e6258-- --===============8936353274837748921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8936353274837748921==-- From xen-devel-bounces@lists.xen.org Sat May 05 18:42:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 18:42:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQjv6-0006fj-Dc; Sat, 05 May 2012 18:41:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQjv4-0006fe-KL for xen-devel@lists.xensource.com; Sat, 05 May 2012 18:41:26 +0000 Received: from [85.158.143.35:34467] by server-1.bemta-4.messagelabs.com id B9/E4-20925-55475AF4; Sat, 05 May 2012 18:41:25 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336243283!15142692!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20668 invoked from network); 5 May 2012 18:41:24 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 18:41:24 -0000 Received: by qadb33 with SMTP id b33so1826494qad.9 for ; Sat, 05 May 2012 11:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oQ5fY80Ei8P+sSXEtoxQjCpisTJwgcfnx46lpGGUpss=; b=uhgkvMuT57f8/mUrnDuhaFHuGJ7U8NvvojPyhcuRT6keaKa8I0CMaRiold1hGAymOu tzdGS38e6iXrNgTlnEDtPcQWsverwRgUtiYDrKUlnt6gWP5ycX3TtxfIjgLO6qTDALcU ztJYnTE5kaUudG1tcA9lU4K86qx2rx0n8IsEhj2pxD6I9LDWujDnSCG2pgpFPzXXBgfk 740kNzlTlYC3L6/855dGmwL7AMOFxcX2Vfdb2NxbIRAOm5VMSwxocK2T1X6VK7CkOYiv cJ+bfb4fDXxy923yqArSJgMNF3x09y3ql50+8K4C/VW3Mby8kLtMRDNdLL3S0ujreZLH BVxw== MIME-Version: 1.0 Received: by 10.229.135.143 with SMTP id n15mr5044106qct.70.1336243282628; Sat, 05 May 2012 11:41:22 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Sat, 5 May 2012 11:41:22 -0700 (PDT) In-Reply-To: <4FA50947.8030703@citrix.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 11:41:22 -0700 Message-ID: From: AP To: Andrew Cooper Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8936353274837748921==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8936353274837748921== Content-Type: multipart/alternative; boundary=00248c768f2a31d1bd04bf4e6258 --00248c768f2a31d1bd04bf4e6258 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper wrote: > > > > Thanks, that fixed it. Here is what I see now: > > > > (XEN) *** IRQ BUG found *** > > (XEN) CPU0 -Testing vector 236 from bitmap > > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > > (XEN) Guest interrupt information: > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > status=00000000 mapped, unbound > > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > > status=00000030 in-flight=0 domain-list=0: 1(-S--), > > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > > status=00000000 mapped, unbound > > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > > status=00000030 in-flight=0 domain-list=0: 8(-S--), > > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > > status=00000030 in-flight=0 domain-list=0: 9(-S--), > > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > > status=00000002 mapped, unbound > > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > > status=00000002 mapped, unbound > > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > > > Let me know if you need any more info. > > Thanks, > > AP > > > > There should be quite a lot more irq information dumped than just that. > Was there any more on the console or had it given up by that point? It There was nothing more on the console. The system was hung. > might be worth trying to set synchronous console to get all of that > debug information? I was running with sync_console and console_to_ring options. > How easy is this error to reproduce for you? I never managed to > reproduce it reliably enough to be able to debug? I cannot reproduce it easily either. > If you could provide your Xen boot console log, that would be very useful I will send full logs the next time I see the problem. Thanks, AP --00248c768f2a31d1bd04bf4e6258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>= ;
> > Thanks, that fixed it. Here is what I see now:
> ><= br> > > (XEN) *** IRQ BUG found ***
> > (XEN) CPU0 -Testing vect= or 236 from bitmap
> > 37,41,49,51,64,72,80,88,96,104,120,136,145,= 152,158,160,168,175,182,192,200,211
> > (XEN) Guest interrupt info= rmation:
> > (XEN) =A0 =A0IRQ: =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge> > status=3D00000000 mapped, unbound
> > (XEN) =A0 =A0IRQ:= =A0 1 affinity:01 vec:d3 type=3DIO-APIC-edge
> > status=3D0000003= 0 in-flight=3D0 domain-list=3D0: =A01(-S--),
> > (XEN) =A0 =A0IRQ: =A0 2 affinity:ff vec:e2 type=3DXT-PIC
> = > status=3D00000000 mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 3= affinity:01 vec:40 type=3DIO-APIC-edge
> > status=3D00000002 mapp= ed, unbound
> > (XEN) =A0 =A0IRQ: =A0 4 affinity:01 vec:48 type=3D= IO-APIC-edge
> > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A0 5 affinity:01 vec:50 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 6 affinity:01 vec:58 ty= pe=3DIO-APIC-edge
> > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A0 7 affinity:01 vec:60 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > (XEN) =A0 =A0IRQ: =A0 8 affinity:08 vec:29 ty= pe=3DIO-APIC-edge
> > status=3D00000030 in-flight=3D0 domain-list=3D0: =A08(-S--),
&= gt; > (XEN) =A0 =A0IRQ: =A0 9 affinity:02 vec:25 type=3DIO-APIC-level> > status=3D00000030 in-flight=3D0 domain-list=3D0: =A09(-S--),
= > > (XEN) =A0 =A0IRQ: =A010 affinity:01 vec:78 type=3DIO-APIC-edge > > status=3D00000002 mapped, unbound
> > (XEN) =A0 =A0IRQ: = =A011 affinity:01 vec:88 type=3DIO-APIC-edge
> > status=3D00000002= mapped, unbound
> > [ 5129.737147] [drm:i915_hangcheck_ring_idle]= *ERROR* Hangcheck timer
> > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed= IRQ?
> >
> > Let me know if you need any more info.
&= gt; > Thanks,
> > AP
> >
>
> There should = be quite a lot more irq information dumped than just that.
> Was there any more on the console or had it given up by that point? It=

There was nothing more on the console. The system was hung.

> might be worth trying to set synchronous console to ge= t all of that
> debug information?

I was running with sync_console and console_= to_ring options.

> How easy is this error to reproduce for you? I= never managed to
> reproduce it reliably enough to be able to debug?=

I cannot reproduce it easily either.=A0

> If you could provid= e your Xen boot console log, that would be very useful

I will send f= ull logs the next time I see the problem.

Thanks,
AP
--00248c768f2a31d1bd04bf4e6258-- --===============8936353274837748921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8936353274837748921==-- From xen-devel-bounces@lists.xen.org Sat May 05 19:07:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 19:07:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQkJm-000786-EY; Sat, 05 May 2012 19:06:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQkJk-00077z-VF for xen-devel@lists.xensource.com; Sat, 05 May 2012 19:06:57 +0000 Received: from [85.158.143.35:18843] by server-1.bemta-4.messagelabs.com id 6C/AB-20925-05A75AF4; Sat, 05 May 2012 19:06:56 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336244813!7668840!1 X-Originating-IP: [209.85.216.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20543 invoked from network); 5 May 2012 19:06:54 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 19:06:54 -0000 Received: by qcsp15 with SMTP id p15so3220636qcs.30 for ; Sat, 05 May 2012 12:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u7J+EPMs3L53mJVbdMpcRjRBmCYpSZ6SNzdVKbLr2u4=; b=COamM8eanCOugdOt6paYwnKeqSj4zwSXzo17CvEiEITnuNORW1j7rseucoDW4ztHRe uGf4TVuxRUEgEoqCmO9e0tKWxMPsSpTxvoTn9IFlCS/VVAe2jDJSAb0JhwCVtn79r0S1 bz6DjFqy8svEXh1BJFBG3ObXYobvsEtKtmdykZgUf/iW9nDwazYblGuuyRR98M975wr6 7/Kxrybrdi/2Sdm4niQgQ6i2rQeZtGdToFXlJPQU6zmJ6ct4PtzuCsAY+SG3lC7eMTLJ sk7y7w9xWGfK8n8/hWW5Yb0n7MMbT1+MuCMKfxnFf3p99PVD11cU/hqFRMXnUA+//U9j vU9A== MIME-Version: 1.0 Received: by 10.224.42.16 with SMTP id q16mr5292515qae.70.1336244812786; Sat, 05 May 2012 12:06:52 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Sat, 5 May 2012 12:06:52 -0700 (PDT) In-Reply-To: References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 12:06:52 -0700 Message-ID: From: AP To: Andrew Cooper Content-Type: multipart/mixed; boundary=20cf3074d4fe662a8904bf4ebda6 Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3074d4fe662a8904bf4ebda6 Content-Type: multipart/alternative; boundary=20cf3074d4fe662a8504bf4ebda4 --20cf3074d4fe662a8504bf4ebda4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 11:41 AM, AP wrote: > > On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper wrote: > > > > > > > Thanks, that fixed it. Here is what I see now: > > > > > > (XEN) *** IRQ BUG found *** > > > (XEN) CPU0 -Testing vector 236 from bitmap > > > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > > > (XEN) Guest interrupt information: > > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > > status=00000000 mapped, unbound > > > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > > > status=00000030 in-flight=0 domain-list=0: 1(-S--), > > > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > > > status=00000000 mapped, unbound > > > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > > > status=00000030 in-flight=0 domain-list=0: 8(-S--), > > > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > > > status=00000030 in-flight=0 domain-list=0: 9(-S--), > > > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > > > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > > > > > Let me know if you need any more info. > > > Thanks, > > > AP > > > > > > > There should be quite a lot more irq information dumped than just that. > > Was there any more on the console or had it given up by that point? It > > There was nothing more on the console. The system was hung. > > > might be worth trying to set synchronous console to get all of that > > debug information? > > I was running with sync_console and console_to_ring options. > > > > How easy is this error to reproduce for you? I never managed to > > reproduce it reliably enough to be able to debug? > > I cannot reproduce it easily either. > > > > If you could provide your Xen boot console log, that would be very useful > > I will send full logs the next time I see the problem. I have attached the full logs. I had a CentOS 5.6 and a Windows 7 HVM domain running. Thanks, AP --20cf3074d4fe662a8504bf4ebda4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 5, 2012 at 11:41 AM, AP <apxeng@gmail.com> wrote:
>
> On Sat, May 5, 2012 at 4:0= 4 AM, Andrew Cooper <andrew= .cooper3@citrix.com> wrote:
> >
> >
> > > Thanks, that fixed it. Here is wha= t I see now:
> > >
> > > (XEN) *** IRQ BUG found **= *
> > > (XEN) CPU0 -Testing vector 236 from bitmap
> >= > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,19= 2,200,211
> > > (XEN) Guest interrupt information:
> > > (XEN) = =A0 =A0IRQ: =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge
> > > = status=3D00000000 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 1= affinity:01 vec:d3 type=3DIO-APIC-edge
> > > status=3D00000030 in-flight=3D0 domain-list=3D0: =A01(-S--),=
> > > (XEN) =A0 =A0IRQ: =A0 2 affinity:ff vec:e2 type=3DXT-PIC=
> > > status=3D00000000 mapped, unbound
> > > (XEN= ) =A0 =A0IRQ: =A0 3 affinity:01 vec:40 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 4 affinity:01 vec:48 type=3DIO-APIC-edge
> > > = status=3D00000002 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 5= affinity:01 vec:50 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 6 affinity:01 vec:58 type=3DIO-APIC-edge
> > > = status=3D00000002 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 7= affinity:01 vec:60 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 8 affinity:08 vec:29 type=3DIO-APIC-edge
> > > = status=3D00000030 in-flight=3D0 domain-list=3D0: =A08(-S--),
> > &= gt; (XEN) =A0 =A0IRQ: =A0 9 affinity:02 vec:25 type=3DIO-APIC-level
> > > status=3D00000030 in-flight=3D0 domain-list=3D0: =A09(-S--),=
> > > (XEN) =A0 =A0IRQ: =A010 affinity:01 vec:78 type=3DIO-API= C-edge
> > > status=3D00000002 mapped, unbound
> > >= ; (XEN) =A0 =A0IRQ: =A011 affinity:01 vec:88 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > [ 5129.7= 37147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer
> > = > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ?=
> > >
> > > Let me know if you need any more info.
= > > > Thanks,
> > > AP
> > >
> ><= br>> > There should be quite a lot more irq information dumped than j= ust that.
> > Was there any more on the console or had it given up by that poin= t? It
>
> There was nothing more on the console. The system was= hung.
>
> > might be worth trying to set synchronous consol= e to get all of that
> > debug information?
>
> I was running with sync_consol= e and console_to_ring options.
>
>
> > How easy is thi= s error to reproduce for you? I never managed to
> > reproduce it = reliably enough to be able to debug?
>
> I cannot reproduce it easily either.=A0
>
>
>= ; > If you could provide your Xen boot console log, that would be very u= seful
>
> I will send full logs the next time I see the problem= .

I have attached the full logs. I had a CentOS 5.6 and a Windows 7 HVM d= omain running.

Thanks,
AP

--20cf3074d4fe662a8504bf4ebda4-- --20cf3074d4fe662a8904bf4ebda6 Content-Type: application/octet-stream; name="irq_bug.log" Content-Disposition: attachment; filename="irq_bug.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1v1kgcr0 IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICAgICAgICAgICAgICAgICAgIF8gICAg ICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAg IF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18gXCAgfCB8 fCB8XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKICAv ICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy98X198IHxffCB8IHwgfE4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAj MCA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBs YXBpY19pZFsweDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEgNjoxMCBBUElDIHZlcnNp b24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5h YmxlZCkKKFhFTikgUHJvY2Vzc29yICMyIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpCihYRU4pIFByb2Nl c3NvciAjMyA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw eDA1XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwNl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDddIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA4XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDBdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAo YWNwaV9pZFsweDAxXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlk WzB4MDJdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCihYRU4pIElPQVBJQ1swXTog YXBpY19pZCAyLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4p IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwp CihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhp Z2ggbGV2ZWwpCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgQUNQSTog SVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUu CihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAxIEkvTyBBUElDcwooWEVO KSBBQ1BJOiBIUEVUIGlkOiAweDgwODZhMzAxIGJhc2U6IDB4ZmVkMDAwMDAKKFhFTikgVGFibGUg aXMgbm90IGZvdW5kIQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRp b24gaW5mb3JtYXRpb24KKFhFTikgU01QOiBBbGxvd2luZyA4IENQVXMgKDQgaG90cGx1ZyBDUFVz KQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgKKFhFTikgU3dpdGNoZWQg dG8gQVBJQyBkcml2ZXIgeDJhcGljX2NsdXN0ZXIuCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMjY5MS4zNjEgTUh6IHBy b2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgeHN0YXRlX2luaXQ6 IHVzaW5nIGNudHh0X3NpemU6IDB4MzQwIGFuZCBzdGF0ZXM6IDB4NwooWEVOKSBtY2VfaW50ZWwu YzoxMjM5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBTRVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAg ZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIEludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVu YWJsZWQKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBmODAwMDAwMCBzZWdt ZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBmODAwMDAwMCBy ZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1 cyAwMC0zZgooWEVOKSBJbnRlbCBWVC1kIFNub29wIENvbnRyb2wgbm90IGVuYWJsZWQuCihYRU4p IEludGVsIFZULWQgRG9tMCBETUEgUGFzc3Rocm91Z2ggbm90IGVuYWJsZWQuCihYRU4pIEludGVs IFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIEludGVy cnVwdCBSZW1hcHBpbmcgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBTaGFyZWQgRVBUIHRhYmxl cyBub3QgZW5hYmxlZC4KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKKFhFTikgIC0g RG9tMCBtb2RlOiBSZWxheGVkCihYRU4pIEVuYWJsZWQgZGlyZWN0ZWQgRU9JIHdpdGggaW9hcGlj X2Fja19vbGQgb24hCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNpbmcg b2xkIEFDSyBtZXRob2QKKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIg YXBpYzI9LTEgcGluMj0tMQooWEVOKSBUU0MgZGVhZGxpbmUgdGltZXIgZW5hYmxlZAooWEVOKSBQ bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVAooWEVOKSBBbGxvY2F0ZWQgY29uc29sZSBy aW5nIG9mIDMyIEtpQi4KKFhFTikgVk1YOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihY RU4pICAtIEFQSUMgTU1JTyBhY2Nlc3MgdmlydHVhbGlzYXRpb24KKFhFTikgIC0gQVBJQyBUUFIg c2hhZG93CihYRU4pICAtIEV4dGVuZGVkIFBhZ2UgVGFibGVzIChFUFQpCihYRU4pICAtIFZpcnR1 YWwtUHJvY2Vzc29yIElkZW50aWZpZXJzIChWUElEKQooWEVOKSAgLSBWaXJ0dWFsIE5NSQooWEVO KSAgLSBNU1IgZGlyZWN0LWFjY2VzcyBiaXRtYXAKKFhFTikgIC0gVW5yZXN0cmljdGVkIEd1ZXN0 CihYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgSFZNOiBWTVggZW5hYmxlZAooWEVOKSBI Vk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBkZXRlY3RlZAooWEVOKSBIVk06IEhB UCBwYWdlIHNpemVzOiA0a0IsIDJNQiBbZGlzYWJsZWRdCihYRU4pIEJyb3VnaHQgdXAgNCBDUFVz CihYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNo ZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioq CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weGFh NTAwMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjMDAwMDAgbWVtc3o9 MHhiYWM4MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjYmIwMDAgbWVt c3o9MHhkNjAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2JjMDAwIG1l bXN6PTB4MTM3MDAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2QwMDAw IG1lbXN6PTB4MzczMDAwCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAw IC0+IDB4MjA0MzAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4 IgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODFjZDAyMDAKKFhFTikgZWxmX3hlbl9wYXJz ZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJf YWJvdmVfNGdiIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhF TikgZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog UEFERFJfT0ZGU0VUID0gMHgwCihYRU4pIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNz ZXM6CihYRU4pICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4p ICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCihYRU4pICAgICB2aXJ0X29mZnNldCAgICAgID0g MHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZm ZjgxMDAwMDAwCihYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyMDQzMDAw CihYRU4pICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxY2QwMjAwCihYRU4pICAg ICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pICBYZW4gIGtlcm5l bDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUs IGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MjA0MzAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkg QVJSQU5HRU1FTlQ6CihYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjEwMDAwMDAwLT4wMDAw MDAwMjE0MDAwMDAwICgxOTc5NDY1IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQu IHJhbWRpc2s6IDAwMDAwMDAyMWMxNTQwMDAtPjAwMDAwMDAyMWU1ZmZjMDAKKFhFTikgVklSVFVB TCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAw MDAwLT5mZmZmZmZmZjgyMDQzMDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyMDQz MDAwLT5mZmZmZmZmZjg0NGVlYzAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjg0NGVm MDAwLT5mZmZmZmZmZjg1NDNiN2E4CihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjg1NDNj MDAwLT5mZmZmZmZmZjg1NDNjNGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg1NDNk MDAwLT5mZmZmZmZmZjg1NDZjMDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjg1NDZj MDAwLT5mZmZmZmZmZjg1NDZkMDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAw MDAwLT5mZmZmZmZmZjg1ODAwMDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2Qw MjAwCihYRU4pIERvbTAgaGFzIG1heGltdW0gNCBWQ1BVcwooWEVOKSBlbGZfbG9hZF9iaW5hcnk6 IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxYWE1MDAwCihYRU4p IGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAwMCAtPiAweGZmZmZm ZmZmODFjYmFjODAKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgx Y2JiMDAwIC0+IDB4ZmZmZmZmZmY4MWNiYmQ2MAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIg MyBhdCAweGZmZmZmZmZmODFjYmMwMDAgLT4gMHhmZmZmZmZmZjgxY2NmNzAwCihYRU4pIGVsZl9s b2FkX2JpbmFyeTogcGhkciA0IGF0IDB4ZmZmZmZmZmY4MWNkMDAwMCAtPiAweGZmZmZmZmZmODFk YmEwMDAKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNOiAuZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cg bWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9n bGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBD T05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlz IGludGVuZGVkIHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioq KiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJp YWwgbGluZS4KKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNB TlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKKFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMg Tk9UIHJlY29tbWVuZGVkIGZvciBwcm9kdWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhF TikgWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuCihYRU4pICoqKiBTZXJpYWwgaW5w dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8g WGVuKQooWEVOKSBGcmVlZCAyMzZrQiBpbml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBw aHlzaWNhbCBtZW1vcnkKWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQg c3RhcnRlZC4uLgpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVz ZXQKWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1ClsgICAgMC4w MDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjAtMTctZ2VuZXJpYyAoYnVpbGRkQHllbGxvdykgKGdj YyB2ZXJzaW9uIDQuNi4xIChVYnVudHUvTGluYXJvIDQuNi4xLTl1YnVudHUzKSApICMzMC1VYnVu dHUgU01QIFRodSBNYXIgOCAyMDo0NTozOSBVVEMgMjAxMiAoVWJ1bnR1IDMuMC4wLTE3LjMwLWdl bmVyaWMgMy4wLjIyKQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJv b3Q9VVVJRD1jNzgxNWFmZS1hZTcyLTRjZmEtYjhiMC05NGIzMDM1YzBiYjcgcm8gZGVidWcgY29u c29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgpbICAgIDAuMDAwMDAwXSBLRVJORUwgc3VwcG9ydGVk IGNwdXM6ClsgICAgMC4wMDAwMDBdICAgSW50ZWwgR2VudWluZUludGVsClsgICAgMC4wMDAwMDBd ICAgQU1EIEF1dGhlbnRpY0FNRApbICAgIDAuMDAwMDAwXSAgIENlbnRhdXIgQ2VudGF1ckhhdWxz ClsgICAgMC4wMDAwMDBdIERpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMKWyAgICAwLjAw MDAwMF0geGVuX3JlbGVhc2VfY2h1bms6IGxvb2tpbmcgYXQgYXJlYSBwZm4gZGZhMDAtZjgwMDA6 IDk5ODQwIHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29r aW5nIGF0IGFyZWEgcGZuIGZjMDAwLWZlYzAwOiAxMTI2NCBwYWdlcyBmcmVlZApbICAgIDAuMDAw MDAwXSB4ZW5fcmVsZWFzZV9jaHVuazogbG9va2luZyBhdCBhcmVhIHBmbiBmZWMwMS1mZWQwODog MjYzIHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29raW5n IGF0IGFyZWEgcGZuIGZlZDA5LWZlZDEwOiA3IHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhl bl9yZWxlYXNlX2NodW5rOiBsb29raW5nIGF0IGFyZWEgcGZuIGZlZDFhLWZlZDFjOiAyIHBhZ2Vz IGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29raW5nIGF0IGFyZWEg cGZuIGZlZDIwLWZlZTAwOiAyMjQgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0geGVuX3JlbGVh c2VfY2h1bms6IGxvb2tpbmcgYXQgYXJlYSBwZm4gZmVlMDEtZmZkMjA6IDM4NzEgcGFnZXMgZnJl ZWQKWyAgICAwLjAwMDAwMF0gcmVsZWFzZWQgMTE1NDcxIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkK WyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gOWUtPjEwMApbICAgIDAuMDAwMDAwXSAxLTEg bWFwcGluZyBvbiAyMDAwMC0+MjAyMDAKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gNDAw MDAtPjQwMjAwClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIGRhOTlmLT5kYWZmZgpbICAg IDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBkYjAwMC0+MTAwMDAwClsgICAgMC4wMDAwMDBdIDEt MSBtYXBwaW5nIG9uIDIxZTYwMC0+MjFlODAwClsgICAgMC4wMDAwMDBdIFNldCAxNTQ4MTggcGFn ZShzKSB0byAxLTEgbWFwcGluZy4KWyAgICAwLjAwMDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNh bCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw MDAwMDA5ZDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDlkODAw IC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBY ZW46IDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNlcnZlZCkKWyAgICAw LjAwMDAwMF0gIFhlbjogMDAwMDAwMDAyMDIwMDAwMCAtIDAwMDAwMDAwNDAwMDAwMDAgKHVzYWJs ZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDA0MDAwMDAwMCAtIDAwMDAwMDAwNDAyMDAw MDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDQwMjAwMDAwIC0gMDAw MDAwMDBkYTk5ZjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGRhOTlm MDAwIC0gMDAwMDAwMDBkYWU5ZjAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAw MDAwMDAwZGFlOWYwMDAgLSAwMDAwMDAwMGRhZjlmMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAw MF0gIFhlbjogMDAwMDAwMDBkYWY5ZjAwMCAtIDAwMDAwMDAwZGFmZmYwMDAgKEFDUEkgZGF0YSkK WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBkYWZmZjAwMCAtIDAwMDAwMDAwZGIwMDAwMDAg KHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBkYjAwMDAwMCAtIDAwMDAwMDAw ZGZhMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGY4MDAwMDAw IC0gMDAwMDAwMDBmYzAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw MDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0g IFhlbjogMDAwMDAwMDBmZWQwODAwMCAtIDAwMDAwMDAwZmVkMDkwMDAgKHJlc2VydmVkKQpbICAg IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZlZDEwMDAwIC0gMDAwMDAwMDBmZWQxYTAwMCAocmVz ZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZl ZDIwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAt IDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAw MGZmZDIwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBY ZW46IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWU5OGY1MDAwICh1c2FibGUpClsgICAgMC4w MDAwMDBdICBYZW46IDAwMDAwMDAyMWU2MDAwMDAgLSAwMDAwMDAwMjFlODAwMDAwIChyZXNlcnZl ZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDIxZTgwMDAwMCAtIDAwMDAwMDAyNmY4MWEw MDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFibGVk ClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpb ICAgIDAuMDAwMDAwXSBETUkgMi42IHByZXNlbnQuClsgICAgMC4wMDAwMDBdIERNSTogTEVOT1ZP IDQyODZDVE8vNDI4NkNUTywgQklPUyA4REVUNThXVyAoMS4yOCApIDAyLzE0LzIwMTIKWyAgICAw LjAwMDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw MDEwMDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdIGU4MjAgcmVtb3Zl IHJhbmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAodXNhYmxlKQpbICAg IDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0g MHgyNmY4MWEgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKWyAgICAwLjAwMDAwMF0geDJhcGlj IGVuYWJsZWQgYnkgQklPUywgc3dpdGNoaW5nIHRvIHgyYXBpYyBvcHMKWyAgICAwLjAwMDAwMF0g bGFzdF9wZm4gPSAweGRiMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAw MDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZCA6IDAgLSAwNDRlZjAwMApbICAgIDAuMDAwMDAwXSBC YXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDIw NDgwClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt MDAwMDAwMDBkYjAwMDAwMApbICAgIDAuMDAwMDAwXSAgMDAwMDAwMDAwMCAtIDAwZGIwMDAwMDAg cGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRv IGRiMDAwMDAwIEAgOTIzMDAwLTEwMDAwMDAKWyAgICAwLjAwMDAwMF0geGVuOiBzZXR0aW5nIFJX IHRoZSByYW5nZSBmY2UwMDAgLSAxMDAwMDAwClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21h cHBpbmc6IDAwMDAwMDAxMDAwMDAwMDAtMDAwMDAwMDI2ZjgxYTAwMApbICAgIDAuMDAwMDAwXSAg MDEwMDAwMDAwMCAtIDAyNmY4MWEwMDAgcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGly ZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDI2ZjgxYTAwMCBAIGQ5NjE3MDAwLWRhOTlmMDAwClsg ICAgMC4wMDAwMDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgZGExOWEwMDAgLSBkYTk5ZjAw MApbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiAwMjA0MzAwMCAtIDA0NGVmMDAwClsgICAgMC4wMDAw MDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmMDBlMCAwMDAyNCAodjAyIExFTk9WTykKWyAgICAw LjAwMDAwMF0gQUNQSTogWFNEVCAwMDAwMDAwMGRhZmZlMTIwIDAwMEFDICh2MDEgTEVOT1ZPIFRQ LThEICAgIDAwMDAxMjgwIFBURUMgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1Ag MDAwMDAwMDBkYWZlNzAwMCAwMDBGNCAodjA0IExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQVEwg IDAwMDAwMDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwZGFmZWEwMDAgMEY2 RDggKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAw MDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGRhZjJkMDAwIDAwMDQwClsgICAgMC4wMDAwMDBdIEFD UEk6IFNMSUMgMDAwMDAwMDBkYWZmZDAwMCAwMDE3NiAodjAxIExFTk9WTyBUUC04RCAgICAwMDAw MTI4MCBQVEVDIDAwMDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwZGFm ZmMwMDAgMDAyNDkgKHYwMSBMRU5PVk8gVFAtU1NEVDIgMDAwMDAyMDAgSU5UTCAyMDA2MTEwOSkK WyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGRhZmZiMDAwIDAwMDMzICh2MDEgTEVO T1ZPIFRQLVNTRFQxIDAwMDAwMTAwIElOVEwgMjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6 IFNTRFQgMDAwMDAwMDBkYWZmYTAwMCAwMDdEMSAodjAxIExFTk9WTyBTYXRhQWhjaSAwMDAwMTAw MCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIDAwMDAwMDAwZGFmZTYw MDAgMDAwMzggKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAg ICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGRhZmU1MDAwIDAwMDk4ICh2MDEgTEVOT1ZP IFRQLThEICAgIDAwMDAxMjgwIFBUTCAgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IE1D RkcgMDAwMDAwMDBkYWZlNDAwMCAwMDAzQyAodjAxIExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQ VEwgIDAwMDAwMDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBFQ0RUIDAwMDAwMDAwZGFmZTMwMDAg MDAwNTIgKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAgICAw LjAwMDAwMF0gQUNQSTogQVNGISAwMDAwMDAwMGRhZmU5MDAwIDAwMEE1ICh2MzIgTEVOT1ZPIFRQ LThEICAgIDAwMDAxMjgwIFBUTCAgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IFRDUEEg MDAwMDAwMDBkYWZlMjAwMCAwMDAzMiAodjAyICAgIFBUTCAgIExFTk9WTyAwNjA0MDAwMCBMTlZP IDAwMDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwZGFmZTEwMDAgMDBB NjkgKHYwMSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAw MDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGRhZmUwMDAwIDAwOTk2ICh2MDEgIFBtUmVmICAgIENw dVBtIDAwMDAzMDAwIElOVEwgMjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhNQVIgMDAw MDAwMDBkYWZkZjAwMCAwMDBFOCAodjAxIElOVEVMICAgICAgU05CICAwMDAwMDAwMSBJTlRMIDAw MDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBVRUZJIDAwMDAwMDAwZGFmZGUwMDAgMDAwM0Ug KHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAgICAwLjAwMDAw MF0gQUNQSTogVUVGSSAwMDAwMDAwMGRhZmRkMDAwIDAwMDQyICh2MDEgUFRMICAgICAgQ09NQlVG IDAwMDAwMDAxIFBUTCAgMDAwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IFVFRkkgMDAwMDAw MDBkYWZkYzAwMCAwMDI5MiAodjAxIExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQVEwgIDAwMDAw MDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApb ICAgIDAuMDAwMDAwXSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAg ICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZh a2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMjZmODFhMDAwClsgICAgMC4w MDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDI2Zjgx YTAwMApbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDFlOThmMDAwMCAtIDAwMDAw MDAxZTk4ZjRmZmZdClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAw MF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBE TUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwg ICAweDAwMTAwMDAwIC0+IDB4MDAyNmY4MWEKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0 YXJ0IFBGTiBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzddIGFj dGl2ZSBQRk4gcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAw MDAwOWQKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApbICAg IDAuMDAwMDAwXSAgICAgMDogMHgwMDAyMDIwMCAtPiAweDAwMDQwMDAwClsgICAgMC4wMDAwMDBd ICAgICAwOiAweDAwMDQwMjAwIC0+IDB4MDAwZGE5OWYKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4 MDAwZGFmZmYgLT4gMHgwMDBkYjAwMApbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAt PiAweDAwMWU5OGY1ClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMjFlODAwIC0+IDB4MDAyNmY4 MWEKWyAgICAwLjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDIxODI3MTYKWyAgICAwLjAw MDAwMF0gICBETUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBd ICAgRE1BIHpvbmU6IDE3MTIgcGFnZXMgcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gICBETUEgem9u ZTogMjIxMyBwYWdlcywgTElGTyBiYXRjaDowClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog MTQyODAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog ODc1OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6 IDIwNTgxIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcApbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCB6b25l OiAxMjY3ODgyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRp bWVyIElPIFBvcnQ6IDB4NDA4ClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz cyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxh cGljX2lkWzB4MDBdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpClsgICAgMC4w MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVk KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDAw XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFw aWNfaWRbMHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDhdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwMF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0g QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAg MC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwMl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf YmFzZVswXSkKWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMjU1 LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf U1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAw MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdo IGxldmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAg MC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQ STogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURU KSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTog SFBFVCBpZDogMHg4MDg2YTMwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDog QWxsb3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dz aTogMjcyClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMDllMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMTAwMDAwClsg ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMjAwMDAw MDAgLSAwMDAwMDAwMDIwMjAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2 ZSBtZW1vcnk6IDAwMDAwMDAwNDAwMDAwMDAgLSAwMDAwMDAwMDQwMjAwMDAwClsgICAgMC4wMDAw MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGE5OWYwMDAgLSAwMDAw MDAwMGRhZTlmMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6 IDAwMDAwMDAwZGFlOWYwMDAgLSAwMDAwMDAwMGRhZjlmMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGFmOWYwMDAgLSAwMDAwMDAwMGRhZmZm MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw ZGIwMDAwMDAgLSAwMDAwMDAwMGRmYTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGZhMDAwMDAgLSAwMDAwMDAwMGY4MDAwMDAwClsgICAg MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZjgwMDAwMDAg LSAwMDAwMDAwMGZjMDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt ZW1vcnk6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBd IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAw MGZlYzAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw MDAwMDAwZmVjMDEwMDAgLSAwMDAwMDAwMGZlZDA4MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMDgwMDAgLSAwMDAwMDAwMGZlZDA5MDAw ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVk MDkwMDAgLSAwMDAwMDAwMGZlZDEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwClsgICAgMC4w MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMWEwMDAgLSAw MDAwMDAwMGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v cnk6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDIwMDAwClsgICAgMC4wMDAwMDBdIFBN OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMjAwMDAgLSAwMDAwMDAwMGZl ZTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZmZDIwMDAwClsg ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmZkMjAw MDAgLSAwMDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2 ZSBtZW1vcnk6IDAwMDAwMDAxZTk4ZjUwMDAgLSAwMDAwMDAwMjFlNjAwMDAwClsgICAgMC4wMDAw MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAyMWU2MDAwMDAgLSAwMDAw MDAwMjFlODAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFy dGluZyBhdCBkZmEwMDAwMCAoZ2FwOiBkZmEwMDAwMDoxODYwMDAwMCkKWyAgICAwLjAwMDAwMF0g Qm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpbICAgIDAuMDAwMDAwXSBYZW4g dmVyc2lvbjogNC4yLXVuc3RhYmxlIChwcmVzZXJ2ZS1BRCkKWyAgICAwLjAwMDAwMF0gc2V0dXBf cGVyY3B1OiBOUl9DUFVTOjI1NiBucl9jcHVtYXNrX2JpdHM6MjU2IG5yX2NwdV9pZHM6OCBucl9u b2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQgMjcgcGFnZXMvY3B1IEBm ZmZmODgwMWU5N2UwMDAwIHM3OTYxNiByODE5MiBkMjI3ODQgdTExMDU5MgpbICAgIDAuMDAwMDAw XSBwY3B1LWFsbG9jOiBzNzk2MTYgcjgxOTIgZDIyNzg0IHUxMTA1OTIgYWxsb2M9MjcqNDA5Ngpb ICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCBbMF0gMSBbMF0gMiBbMF0gMyBbMF0gNCBb MF0gNSBbMF0gNiBbMF0gNyAKWyAgICA2LjY1MzM1Nl0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9u ZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjE0NjA4NwpbICAg IDYuNjYxNzUyXSBQb2xpY3kgem9uZTogTm9ybWFsClsgICAgNi42NjUwMTFdIEtlcm5lbCBjb21t YW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJvb3Q9VVVJRD1jNzgxNWFmZS1hZTcyLTRjZmEtYjhiMC05 NGIzMDM1YzBiYjcgcm8gZGVidWcgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgpbICAgIDYu Njc3MTgzXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0 ZXMpCihYRU4pIGRvbWFpbi5jOjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAw NDI2NjAgLT4gMDAwMDI2NjAKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdl IENSNCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0 ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwClsgICAgNi43MDMx MjhdIHhzYXZlL3hyc3RvcjogZW5hYmxlZCB4c3RhdGVfYnYgMHg3LCBjbnR4dCBzaXplIDB4MzQw ClsgICAgNi43NTg1MTddIFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBUTEIgYmV0d2VlbiBmZmZm ODgwMWRjNjAwMDAwIC0gZmZmZjg4MDFlMDYwMDAwMApbICAgIDYuNzY2NTA0XSBzb2Z0d2FyZSBJ TyBUTEIgYXQgcGh5cyAweDFkYzYwMDAwMCAtIDB4MWUwNjAwMDAwClsgICAgNi43OTYwNzZdIE1l bW9yeTogNzEyNTA2MGsvMTAyMTU1MjhrIGF2YWlsYWJsZSAoNjE0MGsga2VybmVsIGNvZGUsIDE0 ODQ2NjRrIGFic2VudCwgMTYwNTgwNGsgcmVzZXJ2ZWQsIDY4OTRrIGRhdGEsIDk4OGsgaW5pdCkK WyAgICA2LjgwODAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywg TWluT2JqZWN0cz0wLCBDUFVzPTgsIE5vZGVzPTEKWyAgICA2LjgxNTkxN10gSGllcmFyY2hpY2Fs IFJDVSBpbXBsZW1lbnRhdGlvbi4KWyAgICA2LjgyMDMxNV0gCVJDVSBkeW50aWNrLWlkbGUgZ3Jh Y2UtcGVyaW9kIGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLgpbICAgIDYuODI2ODMyXSBOUl9JUlFT OjE2NjQwIG5yX2lycXM6MjA0OCAxNgpbICAgIDYuODMxMDQ3XSB4ZW46IHNjaSBvdmVycmlkZTog Z2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgNi44MzcyMjBdIHhlbjogcmVn aXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICA2Ljg0MjkyMl0geGVu OiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICA2Ljg0NzM2N10geGVuOiBhY3BpIHNj aSA5ClsgICAgNi44NTAyMjldIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAg Ni44NTQ2NTddIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpClsgICAgNi44NTkwNzhd IHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsgICAgNi44NjM1MDVdIHhlbjogLS0+ IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgNi44Njc5MzFdIHhlbjogLS0+IHBpcnE9NSAt PiBpcnE9NSAoZ3NpPTUpClsgICAgNi44NzIzNjZdIHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAo Z3NpPTYpClsgICAgNi44NzY3OThdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsg ICAgNi44ODEyMzBdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgNi44ODU2 NTJdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkKWyAgICA2Ljg5 MTA2OV0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICA2Ljg5NTQ5N10geGVu OiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkKWyAgICA2LjkwMDE5Nl0geGVuOiAtLT4g cGlycT0xMSAtPiBpcnE9MTEgKGdzaT0xMSkKWyAgICA2LjkwNDkwMl0geGVuOiAtLT4gcGlycT0x MiAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICA2LjkwOTYwM10geGVuOiAtLT4gcGlycT0xMyAtPiBp cnE9MTMgKGdzaT0xMykKWyAgICA2LjkxNDMwOF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQg KGdzaT0xNCkKWyAgICA2LjkxODk5OV0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0x NSkKWyAgICA2LjkyNDYzNl0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICA2LjkyODQ0 OV0gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICA2Ljky ODQ0OV0gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICA2 Ljk0Nzk5NF0gYWxsb2NhdGVkIDcyMzUxNzQ0IGJ5dGVzIG9mIHBhZ2VfY2dyb3VwClsgICAgNi45 NTMwNjJdIHBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxlPW1lbW9yeScgb3B0aW9uIGlmIHlvdSBk b24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzClsgICAgNi45NjE0MjhdIFhlbjogdXNpbmcgdmNwdW9w IHRpbWVyIGludGVyZmFjZQpbICAgIDYuOTY2MDA2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig Q1BVIDAKWyAgICA2Ljk3MDM3MV0gRGV0ZWN0ZWQgMjY5MS4zNjAgTUh6IHByb2Nlc3Nvci4KWyAg ICA2Ljk3NDg1N10gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTM4Mi43MiBCb2dvTUlQUyAobHBqPTEwNzY1 NDQwKQpbICAgIDYuOTg2MDQ5XSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEK WyAgICA2Ljk5MDk3MF0gU2VjdXJpdHkgRnJhbWV3b3JrIGluaXRpYWxpemVkClsgICAgNi45OTUy NzRdIEFwcEFybW9yOiBBcHBBcm1vciBpbml0aWFsaXplZApbICAgIDYuOTk5NTk2XSBZYW1hOiBi ZWNvbWluZyBtaW5kZnVsLgpbICAgIDcuMDA3ODI1XSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBl bnRyaWVzOiAyMDk3MTUyIChvcmRlcjogMTIsIDE2Nzc3MjE2IGJ5dGVzKQpbICAgIDcuMDIwMjkz XSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwNDg1NzYgKG9yZGVyOiAxMSwgODM4 ODYwOCBieXRlcykKWyAgICA3LjAyOTA4N10gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVz OiAyNTYKWyAgICA3LjAzMzk3Ml0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdApb ICAgIDcuMDM4NTg4XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKWyAgICA3LjA0 MzIwNl0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAgIDcuMDQ3OTAzXSBJ bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgNy4wNTI1OTRdIEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICA3LjA1NzI4OV0gSW5pdGlhbGl6aW5nIGNn cm91cCBzdWJzeXMgYmxraW8KWyAgICA3LjA2MTgxNF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz eXMgcGVyZl9ldmVudApbICAgIDcuMDY2ODI0XSBEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRp b25zClsgICAgNy4wNzEyMTBdIEVORVJHWV9QRVJGX0JJQVM6IFNldCB0byAnbm9ybWFsJywgd2Fz ICdwZXJmb3JtYW5jZScKWyAgICA3LjA3MTIxMV0gRU5FUkdZX1BFUkZfQklBUzogVmlldyBhbmQg dXBkYXRlIHdpdGggeDg2X2VuZXJneV9wZXJmX3BvbGljeSg4KQpbICAgIDcuMDg0OTE0XSBDUFU6 IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMApbICAgIDcuMDg5MTYzXSBDUFU6IFByb2Nlc3NvciBD b3JlIElEOiAwClsgICAgNy4wOTUyMzhdIEFDUEk6IENvcmUgcmV2aXNpb24gMjAxMTA0MTMKWyAg ICA3LjEyODIzNF0gZnRyYWNlOiBhbGxvY2F0aW5nIDI1NzUwIGVudHJpZXMgaW4gMTAxIHBhZ2Vz ClsgICAgNy4xNDA5MDBdIGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSAyNzMKWyAgICA3LjE0NTA0 Nl0gUGVyZm9ybWFuY2UgRXZlbnRzOiB1bnN1cHBvcnRlZCBwNiBDUFUgbW9kZWwgNDIgbm8gUE1V IGRyaXZlciwgc29mdHdhcmUgZXZlbnRzIG9ubHkuClsgICAgNy4xNTQ2ODddIGluc3RhbGxpbmcg WGVuIHRpbWVyIGZvciBDUFUgMQpbICAgIDcuMTU4OTg4XSBjcHUgMSBzcGlubG9jayBldmVudCBp cnEgMjc5CihYRU4pIGRvbWFpbi5jOjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3Mg MDAwNDI2NjAgLT4gMDAwMDI2NjAKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hh bmdlIENSNCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAg QXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwClsgICAgNy4x ODI4MDVdIERpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMKWyAgICA3LjE4MjkwOF0gaW5z dGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAyClsgICAgNy4xOTE2NjhdIGNwdSAyIHNwaW5sb2Nr IGV2ZW50IGlycSAyODUKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENS NCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0ZW1w dCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwCihYRU4pIGRvbWFpbi5j OjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwNDI2NjAgLT4gMDAwMDI2NjAK WyAgICA3LjIxNTUwMV0gRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucwpbICAgIDcuMjE1 NTk1XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMKWyAgICA3LjIyNDM0NV0gY3B1IDMg c3BpbmxvY2sgZXZlbnQgaXJxIDI5MQooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0ZW1wdCB0byBj aGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwCihYRU4pIGRvbWFpbi5jOjY5ODpk MCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwNDI2NjAgLT4gMDAwMDI2NjAKKFhFTikg ZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDA0MjY2MCAtPiAw MDAwMjY2MApbICAgIDcuMjQ4MTgwXSBEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zClsg ICAgNy4yNDgyMDddIEJyb3VnaHQgdXAgNCBDUFVzClsgICAgNy4yNTU5OTldIGRldnRtcGZzOiBp bml0aWFsaXplZApbICAgIDcuMjU5NzA5XSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9u IGF0IGRhZTlmMDAwICgxMDQ4NTc2IGJ5dGVzKQpbICAgIDcuMjY3NzU4XSBHcmFudCB0YWJsZSBp bml0aWFsaXplZApbICAgIDcuMjcxNDMzXSBwcmludF9jb25zdHJhaW50czogZHVtbXk6IApbICAg IDcuMjc1NDM1XSBUaW1lOiAxMDo1ODoyNCAgRGF0ZTogMDUvMDUvMTIKWyAgICA3LjI3OTc5MF0g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAgIDcuMjg0NTkyXSBUcnlpbmcg dG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4KWyAgICA3LjI5NDU1MV0gQUNQ SSBGQURUIGRlY2xhcmVzIHRoZSBzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IFBDSWUgQVNQTSwgc28g ZGlzYWJsZSBpdApbICAgIDcuMzAyNDczXSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApb ICAgIDcuMzA3MDcwXSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLTNmXSBh dCBbbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZl0gKGJhc2UgMHhmODAwMDAwMCkKWyAgICA3LjMx NjgwOF0gUENJOiBNTUNPTkZJRyBhdCBbbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZl0gcmVzZXJ2 ZWQgaW4gRTgyMApbICAgIDcuMzMyMTg3XSBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDM3NTUyayBm cmVlZApbICAgIDcuMzQ4NzE3XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBi YXNlIGFjY2VzcwpbICAgIDcuMzU1MjE1XSBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMD4gYXQgMApb ICAgIDcuMzY0MTgwXSBBQ1BJOiBFQzogRUMgZGVzY3JpcHRpb24gdGFibGUgaXMgZm91bmQsIGNv bmZpZ3VyaW5nIGJvb3QgRUMKWyAgICA3LjM4MDg3OV0gW0Zpcm13YXJlIEJ1Z106IEFDUEk6IEJJ T1MgX09TSShMaW51eCkgcXVlcnkgaWdub3JlZApbICAgIDcuNDI0ODI1XSBBQ1BJOiBTU0RUIDAw MDAwMDAwZGFlOGMwMTggMDA4QzAgKHYwMSAgUG1SZWYgIENwdTBDc3QgMDAwMDMwMDEgSU5UTCAy MDA2MTEwOSkKWyAgICA3LjQzMzg5MV0gQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAg ICA3LjQzODA3N10gQUNQSTogU1NEVCAgICAgICAgICAgKG51bGwpIDAwOEMwICh2MDEgIFBtUmVm ICBDcHUwQ3N0IDAwMDAzMDAxIElOVEwgMjAwNjExMDkpClsgICAgNy40NzE0OTJdIEFDUEk6IFNT RFQgMDAwMDAwMDBkYWU4ZGE5OCAwMDMwMyAodjAxICBQbVJlZiAgICBBcElzdCAwMDAwMzAwMCBJ TlRMIDIwMDYxMTA5KQpbICAgIDcuNDgwNTkzXSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2Fk OgpbICAgIDcuNDg0Nzg2XSBBQ1BJOiBTU0RUICAgICAgICAgICAobnVsbCkgMDAzMDMgKHYwMSAg UG1SZWYgICAgQXBJc3QgMDAwMDMwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICA3LjUwOTkzMl0gQUNQ STogU1NEVCAwMDAwMDAwMGRhZThiZDk4IDAwMTE5ICh2MDEgIFBtUmVmICAgIEFwQ3N0IDAwMDAz MDAwIElOVEwgMjAwNjExMDkpClsgICAgNy41MTk3MzldIEFDUEk6IER5bmFtaWMgT0VNIFRhYmxl IExvYWQ6ClsgICAgNy41MjM5MzBdIEFDUEk6IFNTRFQgICAgICAgICAgIChudWxsKSAwMDExOSAo djAxICBQbVJlZiAgICBBcENzdCAwMDAwMzAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDcuNTQ5NzAy XSBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkClsgICAgNy41NTM1MjddIEFDUEk6IChzdXBwb3J0 cyBTMCBTMyBTNCBTNSkKWyAgICA3LjU1NzcwOV0gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRl cnJ1cHQgcm91dGluZwpbICAgIDcuNTg3OTc0XSBBQ1BJOiBQb3dlciBSZXNvdXJjZSBbUFVCU10g KG9uKQpbICAgIDcuNTk2Njk3XSBBQ1BJOiBFQzogR1BFID0gMHgxMSwgSS9POiBjb21tYW5kL3N0 YXR1cyA9IDB4NjYsIGRhdGEgPSAweDYyClsgICAgNy42MDU1MjJdIEFDUEk6IEFDUEkgRG9jayBT dGF0aW9uIERyaXZlcjogMyBkb2Nrcy9iYXlzIGZvdW5kClsgICAgNy42MTE2MThdIEhFU1Q6IFRh YmxlIG5vdCBmb3VuZC4KWyAgICA3LjYxNTI1Ml0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5k b3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBh IGJ1ZwpbICAgIDcuNjI1MDE5XSBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4g MDAwMCBbYnVzIDAwLWZlXSkKWyAgICA3LjYzMTUzNF0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9z dCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwMDAwLTB4MGNmN10KWyAgICA3LjYzODQ4MV0gcGNpX3Jv b3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwZDAwLTB4ZmZmZl0KWyAg ICA3LjY0NTQ3NF0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0g MHgwMDBhMDAwMC0weDAwMGJmZmZmXQpbICAgIDcuNjUzMjA1XSBwY2lfcm9vdCBQTlAwQTA4OjAw OiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYTAwMDAwLTB4ZmViZmZmZmZdClsgICAgNy42 NjA5MjddIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmVk NDAwMDAtMHhmZWQ0YmZmZl0KWyAgICA3LjY2ODY2NV0gcGNpIDAwMDA6MDA6MDAuMDogWzgwODY6 MDEwNF0gdHlwZSAwIGNsYXNzIDB4MDAwNjAwClsgICAgNy42NzUwMzVdIHBjaSAwMDAwOjAwOjAy LjA6IFs4MDg2OjAxMjZdIHR5cGUgMCBjbGFzcyAweDAwMDMwMApbICAgIDcuNjgxMjUyXSBwY2kg MDAwMDowMDowMi4wOiByZWcgMTA6IFttZW0gMHhmMDAwMDAwMC0weGYwM2ZmZmZmIDY0Yml0XQpb ICAgIDcuNjg4MjI3XSBwY2kgMDAwMDowMDowMi4wOiByZWcgMTg6IFttZW0gMHhlMDAwMDAwMC0w eGVmZmZmZmZmIDY0Yml0IHByZWZdClsgICAgNy42OTU2NjldIHBjaSAwMDAwOjAwOjAyLjA6IHJl ZyAyMDogW2lvICAweDUwMDAtMHg1MDNmXQpbICAgIDcuNzAxNTQ3XSBwY2kgMDAwMDowMDoxNi4w OiBbODA4NjoxYzNhXSB0eXBlIDAgY2xhc3MgMHgwMDA3ODAKWyAgICA3LjcwNzc4NF0gcGNpIDAw MDA6MDA6MTYuMDogcmVnIDEwOiBbbWVtIDB4ZjI2MjUwMDAtMHhmMjYyNTAwZiA2NGJpdF0KWyAg ICA3LjcxNDg5NF0gcGNpIDAwMDA6MDA6MTYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv dCBEM2NvbGQKWyAgICA3LjcyMTI2MF0gcGNpIDAwMDA6MDA6MTYuMDogUE1FIyBkaXNhYmxlZApb ICAgIDcuNzI1NzU4XSBwY2kgMDAwMDowMDoxNi4zOiBbODA4NjoxYzNkXSB0eXBlIDAgY2xhc3Mg MHgwMDA3MDAKWyAgICA3LjczMjAxNV0gcGNpIDAwMDA6MDA6MTYuMzogcmVnIDEwOiBbaW8gIDB4 NTBiMC0weDUwYjddClsgICAgNy43Mzc3MTNdIHBjaSAwMDAwOjAwOjE2LjM6IHJlZyAxNDogW21l bSAweGYyNjJjMDAwLTB4ZjI2MmNmZmZdClsgICAgNy43NDQzOTldIHBjaSAwMDAwOjAwOjE5LjA6 IFs4MDg2OjE1MDJdIHR5cGUgMCBjbGFzcyAweDAwMDIwMApbICAgIDcuNzUwNjI5XSBwY2kgMDAw MDowMDoxOS4wOiByZWcgMTA6IFttZW0gMHhmMjYwMDAwMC0weGYyNjFmZmZmXQpbICAgIDcuNzU3 MDUzXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMTQ6IFttZW0gMHhmMjYyYjAwMC0weGYyNjJiZmZm XQpbICAgIDcuNzYzNTEyXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMTg6IFtpbyAgMHg1MDgwLTB4 NTA5Zl0KWyAgICA3Ljc2OTQwMF0gcGNpIDAwMDA6MDA6MTkuMDogUE1FIyBzdXBwb3J0ZWQgZnJv bSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljc3NTc2OV0gcGNpIDAwMDA6MDA6MTkuMDogUE1FIyBk aXNhYmxlZApbICAgIDcuNzgwMjY0XSBwY2kgMDAwMDowMDoxYS4wOiBbODA4NjoxYzJkXSB0eXBl IDAgY2xhc3MgMHgwMDBjMDMKWyAgICA3Ljc4NjUxOV0gcGNpIDAwMDA6MDA6MWEuMDogcmVnIDEw OiBbbWVtIDB4ZjI2MmEwMDAtMHhmMjYyYTNmZl0KWyAgICA3Ljc5MzE0M10gcGNpIDAwMDA6MDA6 MWEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljc5OTUwMl0g cGNpIDAwMDA6MDA6MWEuMDogUE1FIyBkaXNhYmxlZApbICAgIDcuODA0MDEwXSBwY2kgMDAwMDow MDoxYi4wOiBbODA4NjoxYzIwXSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAgICA3LjgxMDI1Ml0g cGNpIDAwMDA6MDA6MWIuMDogcmVnIDEwOiBbbWVtIDB4ZjI2MjAwMDAtMHhmMjYyM2ZmZiA2NGJp dF0KWyAgICA3LjgxNzQwOV0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE MCBEM2hvdCBEM2NvbGQKWyAgICA3LjgyMzc2Nl0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBkaXNh YmxlZApbICAgIDcuODI4MjU0XSBwY2kgMDAwMDowMDoxYy4wOiBbODA4NjoxYzEwXSB0eXBlIDEg Y2xhc3MgMHgwMDA2MDQKWyAgICA3LjgzNDY3Nl0gcGNpIDAwMDA6MDA6MWMuMDogUE1FIyBzdXBw b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljg0MTA0OF0gcGNpIDAwMDA6MDA6MWMu MDogUE1FIyBkaXNhYmxlZApbICAgIDcuODQ1NTM5XSBwY2kgMDAwMDowMDoxYy4xOiBbODA4Njox YzEyXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3Ljg1MTk1MV0gcGNpIDAwMDA6MDA6MWMu MTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljg1ODMyNl0gcGNp IDAwMDA6MDA6MWMuMTogUE1FIyBkaXNhYmxlZApbICAgIDcuODYyODIzXSBwY2kgMDAwMDowMDox Yy4zOiBbODA4NjoxYzE2XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3Ljg2OTI2MV0gcGNp IDAwMDA6MDA6MWMuMzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3 Ljg3NTYyMV0gcGNpIDAwMDA6MDA6MWMuMzogUE1FIyBkaXNhYmxlZApbICAgIDcuODgwMTIxXSBw Y2kgMDAwMDowMDoxYy40OiBbODA4NjoxYzE4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3 Ljg4NjU0Ml0gcGNpIDAwMDA6MDA6MWMuNDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBE M2NvbGQKWyAgICA3Ljg5MjkyMl0gcGNpIDAwMDA6MDA6MWMuNDogUE1FIyBkaXNhYmxlZApbICAg IDcuODk3NDEyXSBwY2kgMDAwMDowMDoxYy42OiBbODA4NjoxYzFjXSB0eXBlIDEgY2xhc3MgMHgw MDA2MDQKWyAgICA3LjkwMzgzOF0gcGNpIDAwMDA6MDA6MWMuNjogUE1FIyBzdXBwb3J0ZWQgZnJv bSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3LjkxMDIwNV0gcGNpIDAwMDA6MDA6MWMuNjogUE1FIyBk aXNhYmxlZApbICAgIDcuOTE0NzIzXSBwY2kgMDAwMDowMDoxZC4wOiBbODA4NjoxYzI2XSB0eXBl IDAgY2xhc3MgMHgwMDBjMDMKWyAgICA3LjkyMDk4Ml0gcGNpIDAwMDA6MDA6MWQuMDogcmVnIDEw OiBbbWVtIDB4ZjI2MjkwMDAtMHhmMjYyOTNmZl0KWyAgICA3LjkyNzYwMV0gcGNpIDAwMDA6MDA6 MWQuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3LjkzMzk3N10g cGNpIDAwMDA6MDA6MWQuMDogUE1FIyBkaXNhYmxlZApbICAgIDcuOTM4NDczXSBwY2kgMDAwMDow MDoxZi4wOiBbODA4NjoxYzRmXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDEKWyAgICA3Ljk0NDk4M10g cGNpIDAwMDA6MDA6MWYuMjogWzgwODY6MWMwM10gdHlwZSAwIGNsYXNzIDB4MDAwMTA2ClsgICAg Ny45NTEyMDZdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxMDogW2lvICAweDUwYTgtMHg1MGFmXQpb ICAgIDcuOTU2ODkxXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTQ6IFtpbyAgMHg1MGJjLTB4NTBi Zl0KWyAgICA3Ljk2MjYyMl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDE4OiBbaW8gIDB4NTBhMC0w eDUwYTddClsgICAgNy45NjgzMzhdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxYzogW2lvICAweDUw YjgtMHg1MGJiXQpbICAgIDcuOTc0MDUwXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjA6IFtpbyAg MHg1MDYwLTB4NTA3Zl0KWyAgICA3Ljk3OTc2Nl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDI0OiBb bWVtIDB4ZjI2MjgwMDAtMHhmMjYyODdmZl0KWyAgICA3Ljk4NjMzMl0gcGNpIDAwMDA6MDA6MWYu MjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEM2hvdApbICAgIDcuOTkxNzkwXSBwY2kgMDAwMDowMDox Zi4yOiBQTUUjIGRpc2FibGVkClsgICAgNy45OTYyNjNdIHBjaSAwMDAwOjAwOjFmLjM6IFs4MDg2 OjFjMjJdIHR5cGUgMCBjbGFzcyAweDAwMGMwNQpbICAgIDguMDAyNTM3XSBwY2kgMDAwMDowMDox Zi4zOiByZWcgMTA6IFttZW0gMHhmMjYyNDAwMC0weGYyNjI0MGZmIDY0Yml0XQpbICAgIDguMDA5 NTY0XSBwY2kgMDAwMDowMDoxZi4zOiByZWcgMjA6IFtpbyAgMHhlZmEwLTB4ZWZiZl0KWyAgICA4 LjAxNTQxN10gcGNpIDAwMDA6MDA6MWMuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAyXQpbICAg IDguMDIwODg3XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAt MHgwMDAwXSAoZGlzYWJsZWQpClsgICAgOC4wMjgzMjNdIHBjaSAwMDAwOjAwOjFjLjA6ICAgYnJp ZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZl0gKGRpc2FibGVkKQpbICAgIDgu MDM2NDk2XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAw LTB4MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDguMDQ1NTA4XSBwY2kgMDAwMDowMzow MC4wOiBbODA4Njo0MjM4XSB0eXBlIDAgY2xhc3MgMHgwMDAyODAKWyAgICA4LjA1MjA2MV0gcGNp IDAwMDA6MDM6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjI1MDAwMDAtMHhmMjUwMWZmZiA2NGJpdF0K WyAgICA4LjA2MDc3MV0gcGNpIDAwMDA6MDM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE M2hvdCBEM2NvbGQKWyAgICA4LjA2NzE5Nl0gcGNpIDAwMDA6MDM6MDAuMDogUE1FIyBkaXNhYmxl ZApbICAgIDguMDc2MTg5XSBwY2kgMDAwMDowMDoxYy4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMt MDNdClsgICAgOC4wODE2NTZdIHBjaSAwMDAwOjAwOjFjLjE6ICAgYnJpZGdlIHdpbmRvdyBbaW8g IDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAgICA4LjA4OTExMF0gcGNpIDAwMDA6MDA6MWMu MTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMjUwMDAwMC0weGYyNWZmZmZmXQpbICAgIDguMDk2 MzAyXSBwY2kgMDAwMDowMDoxYy4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4 MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDguMTA1MDU4XSBwY2kgMDAwMDowNTowMC4w OiBbMTQxNTpjMTIwXSB0eXBlIDAgY2xhc3MgMHgwMDA3MDAKWyAgICA4LjExMTI3Ml0gcGNpIDAw MDA6MDU6MDAuMDogcmVnIDEwOiBbaW8gIDB4NDAwMC0weDQwMDddClsgICAgOC4xMTcyMDZdIHBj aSAwMDAwOjA1OjAwLjA6IHN1cHBvcnRzIEQxIEQyClsgICAgOC4xMjE2NTldIHBjaSAwMDAwOjA1 OjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDEgRDIgRDNob3QgRDNjb2xkClsgICAgOC4xMjgz OTBdIHBjaSAwMDAwOjA1OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA4LjEzNzAxMV0gcGNpIDAw MDA6MDA6MWMuMzogUENJIGJyaWRnZSB0byBbYnVzIDA1LTBjXQpbICAgIDguMTQyNDg1XSBwY2kg MDAwMDowMDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweDQwMDAtMHg0ZmZmXQpbICAgIDgu MTQ4OTI2XSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGYxZDAwMDAw LTB4ZjI0ZmZmZmZdClsgICAgOC4xNTYxMjNdIHBjaSAwMDAwOjAwOjFjLjM6ICAgYnJpZGdlIHdp bmRvdyBbbWVtIDB4ZjA0MDAwMDAtMHhmMGJmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDguMTY0NjMy XSBwY2kgMDAwMDowZDowMC4wOiBbMTE4MDplODIyXSB0eXBlIDAgY2xhc3MgMHgwMDA4ODAKWyAg ICA4LjE3MDk4NV0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjE1MDAwMDAtMHhm MTUwMDBmZl0KWyAgICA4LjE3NzgwMl0gcGNpIDAwMDA6MGQ6MDAuMDogc3VwcG9ydHMgRDEgRDIK WyAgICA4LjE4MjI2Ml0gcGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE MSBEMiBEM2hvdCBEM2NvbGQKWyAgICA4LjE4OTQwMV0gcGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBk aXNhYmxlZApbICAgIDguMTk4MjcwXSBwY2kgMDAwMDowMDoxYy40OiBQQ0kgYnJpZGdlIHRvIFti dXMgMGQtMGRdClsgICAgOC4yMDM3MzNdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRv dyBbaW8gIDB4MzAwMC0weDNmZmZdClsgICAgOC4yMTAxNzldIHBjaSAwMDAwOjAwOjFjLjQ6ICAg YnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjE1MDAwMDAtMHhmMWNmZmZmZl0KWyAgICA4LjIxNzM5Ml0g cGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMGMwMDAwMC0weGYxM2Zm ZmZmIDY0Yml0IHByZWZdClsgICAgOC4yMjU3MDhdIHBjaSAwMDAwOjBlOjAwLjA6IFsxMDMzOjAx OTRdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDguMjMxOTQ3XSBwY2kgMDAwMDowZTowMC4w OiByZWcgMTA6IFttZW0gMHhmMTQwMDAwMC0weGYxNDAxZmZmIDY0Yml0XQpbICAgIDguMjM5MTM3 XSBwY2kgMDAwMDowZTowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApb ICAgIDguMjQ1NTAyXSBwY2kgMDAwMDowZTowMC4wOiBQTUUjIGRpc2FibGVkClsgICAgOC4yNTAw NDNdIHBjaSAwMDAwOjAwOjFjLjY6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZS0wZV0KWyAgICA4LjI1 NTUwM10gcGNpIDAwMDA6MDA6MWMuNjogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhmMDAwLTB4MDAw MF0gKGRpc2FibGVkKQpbICAgIDguMjYyOTU1XSBwY2kgMDAwMDowMDoxYy42OiAgIGJyaWRnZSB3 aW5kb3cgW21lbSAweGYxNDAwMDAwLTB4ZjE0ZmZmZmZdClsgICAgOC4yNzAxMzRdIHBjaSAwMDAw OjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVm XSAoZGlzYWJsZWQpClsgICAgOC4yNzg3OThdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU YWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDguMjg1MDg1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQMS5fUFJUXQpbICAgIDguMjkxNzU4XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQMi5fUFJUXQpbICAg IDguMjk4NDg0XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAu RVhQNC5fUFJUXQpbICAgIDguMzA1MjEwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFi bGUgW1xfU0JfLlBDSTAuRVhQNS5fUFJUXQpbICAgIDguMzExOTMzXSBBQ1BJOiBQQ0kgSW50ZXJy dXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQNy5fUFJUXQpbICAgIDguMzE4Nzg2XSAg cGNpMDAwMDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKWyAgICA4LjMy NDkzMF0gIHBjaTAwMDA6MDA6IEFDUEkgX09TQyByZXF1ZXN0IGZhaWxlZCAoQUVfU1VQUE9SVCks IHJldHVybmVkIGNvbnRyb2wgbWFzazogMHgwZApbICAgIDguMzMzNjU0XSBBQ1BJIF9PU0MgY29u dHJvbCBmb3IgUENJZSBub3QgZ3JhbnRlZCwgZGlzYWJsaW5nIEFTUE0KKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAooWEVO KSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNi4zCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTkuMAooWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDAwOjAwOjFhLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYi4wCihYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw OjFjLjEKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYy4zCihYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwMDA6MDA6MWMuNAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFjLjYKKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MWYuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFmLjIKKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxZi4zCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDAuMAooWEVOKSBQ Q0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowZDow MC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGU6MDAuMApbICAgIDguNDA1Mjc1XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyA5IDEwICoxMSkKWyAg ICA4LjQxMjA3OV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyAzIDQgNSA2 ICo3IDkgMTAgMTEpClsgICAgOC40MTg4ODVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L Q10gKElSUXMgMyA0IDUgNiAqNyA5IDEwIDExKQpbICAgIDguNDI1NzA2XSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDMgNCA1IDYgNyA5IDEwICoxMSkKWyAgICA4LjQzMjUw OV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgOSAqMTAg MTEpClsgICAgOC40MzkzMjJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRl0gKElSUXMg MyA0IDUgNiA3IDkgMTAgMTEpICowLCBkaXNhYmxlZC4KWyAgICA4LjQ0NzMxM10gQUNQSTogUENJ IEludGVycnVwdCBMaW5rIFtMTktHXSAoSVJRcyAzIDQgNSA2IDcgOSAxMCAqMTEpClsgICAgOC40 NTQxMzJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNiA3IDkg KjEwIDExKQpbICAgIDguNDYwOTE3XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g ZHJpdmVyLgpbICAgIDguNDY2MjU3XSBsYXN0X3BmbiA9IDB4MjZmODFhIG1heF9hcmNoX3BmbiA9 IDB4NDAwMDAwMDAwClsgICAgOC40NzQ4ODhdIHhlbi1iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFs bG9vbiBkcml2ZXIuClsgICAgOC40ODAyNjJdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAw MDowMDowMi4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxvY2tzPW5vbmUKWyAgICA4LjQ4 ODczOF0gdmdhYXJiOiBsb2FkZWQKWyAgICA4LjQ5MTYzOF0gdmdhYXJiOiBicmlkZ2UgY29udHJv bCBwb3NzaWJsZSAwMDAwOjAwOjAyLjAKWyAgICA4LjQ5NzQwNF0gU0NTSSBzdWJzeXN0ZW0gaW5p dGlhbGl6ZWQKWyAgICA4LjUwMTQxM10gbGliYXRhIHZlcnNpb24gMy4wMCBsb2FkZWQuClsgICAg OC41MDU0NjNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiZnMK WyAgICA4LjUxMTI0OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBo dWIKWyAgICA4LjUxNjkxM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1 c2IKWyAgICA4LjUyMjMxOF0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpbICAgIDgu NTMxNDYxXSBQQ0k6IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgOC41 MzcwNDJdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDAwMDA5ZDAwMCAtIDAwMDAwMDAwMDAw OWZmZmYgClsgICAgOC41NDM0MDNdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBkYTk5ZjAw MCAtIDAwMDAwMDAwZGJmZmZmZmYgClsgICAgOC41NTAxMjddIHJlc2VydmUgUkFNIGJ1ZmZlcjog MDAwMDAwMDBkYjAwMDAwMCAtIDAwMDAwMDAwZGJmZmZmZmYgClsgICAgOC41NTY4NTJdIHJlc2Vy dmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDFlOThmNTAwMCAtIDAwMDAwMDAxZWJmZmZmZmYgClsgICAg OC41NjM1NjldIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDI2ZjgxYTAwMCAtIDAwMDAwMDAy NmZmZmZmZmYgClsgICAgOC41NzAzODJdIE5ldExhYmVsOiBJbml0aWFsaXppbmcKWyAgICA4LjU3 NDIxM10gTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4ClsgICAgOC41Nzg4NDNdIE5l dExhYmVsOiAgcHJvdG9jb2xzID0gVU5MQUJFTEVEIENJUFNPdjQKWyAgICA4LjU4NDEyMF0gTmV0 TGFiZWw6ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2VkIGJ5IGRlZmF1bHQKWyAgICA4LjU5MDA2 M10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDguNTk4MjUzXSBTd2l0Y2hlZCB0 byBOT0h6IG1vZGUgb24gQ1BVICMwClsgICAgOC42MDE1OThdIFN3aXRjaGVkIHRvIE5PSHogbW9k ZSBvbiBDUFUgIzMKWyAgICA4LjYwMTc4M10gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAj MQpbICAgIDguNjA0MDYyXSBTd2l0Y2hlZCB0byBOT0h6IG1vZGUgb24gQ1BVICMyClsgICAgOC42 MTY4MTNdIEFwcEFybW9yOiBBcHBBcm1vciBGaWxlc3lzdGVtIEVuYWJsZWQKWyAgICA4LjYyMTcz N10gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgOC42MjUwMDhdIEFDUEk6IGJ1cyB0eXBlIHBucCBy ZWdpc3RlcmVkClsgICAgOC42Mjk3MTZdIHBucCAwMDowMDogW21lbSAweDAwMDAwMDAwLTB4MDAw OWZmZmZdClsgICAgOC42MzQ3MTVdIHBucCAwMDowMDogW21lbSAweDAwMGMwMDAwLTB4MDAwYzNm ZmZdClsgICAgOC42Mzk4MDhdIHBucCAwMDowMDogW21lbSAweDAwMGM0MDAwLTB4MDAwYzdmZmZd ClsgICAgOC42NDQ5MDddIHBucCAwMDowMDogW21lbSAweDAwMGM4MDAwLTB4MDAwY2JmZmZdClsg ICAgOC42NDk5OTJdIHBucCAwMDowMDogW21lbSAweDAwMGNjMDAwLTB4MDAwY2ZmZmZdClsgICAg OC42NTUwODVdIHBucCAwMDowMDogW21lbSAweDAwMGQwMDAwLTB4MDAwZDNmZmZdClsgICAgOC42 NjAxNzVdIHBucCAwMDowMDogW21lbSAweDAwMGQ0MDAwLTB4MDAwZDdmZmZdClsgICAgOC42NjUy NjVdIHBucCAwMDowMDogW21lbSAweDAwMGQ4MDAwLTB4MDAwZGJmZmZdClsgICAgOC42NzAzNDhd IHBucCAwMDowMDogW21lbSAweDAwMGRjMDAwLTB4MDAwZGZmZmZdClsgICAgOC42NzU0NDJdIHBu cCAwMDowMDogW21lbSAweDAwMGUwMDAwLTB4MDAwZTNmZmZdClsgICAgOC42ODA1MjNdIHBucCAw MDowMDogW21lbSAweDAwMGU0MDAwLTB4MDAwZTdmZmZdClsgICAgOC42ODU2MjRdIHBucCAwMDow MDogW21lbSAweDAwMGU4MDAwLTB4MDAwZWJmZmZdClsgICAgOC42OTA3MjFdIHBucCAwMDowMDog W21lbSAweDAwMGVjMDAwLTB4MDAwZWZmZmZdClsgICAgOC42OTU4MDddIHBucCAwMDowMDogW21l bSAweDAwMGYwMDAwLTB4MDAwZmZmZmZdClsgICAgOC43MDA4OTZdIHBucCAwMDowMDogW21lbSAw eDAwMTAwMDAwLTB4ZGY5ZmZmZmZdClsgICAgOC43MDU5ODFdIHBucCAwMDowMDogW21lbSAweGZl YzAwMDAwLTB4ZmVkM2ZmZmZdClsgICAgOC43MTEwNjFdIHBucCAwMDowMDogW21lbSAweGZlZDRj MDAwLTB4ZmZmZmZmZmZdClsgICAgOC43MTYyMDldIHN5c3RlbSAwMDowMDogW21lbSAweDAwMDAw MDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguNzIzNTEyXSBzeXN0 ZW0gMDA6MDA6IFttZW0gMHgwMDBjMDAwMC0weDAwMGMzZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2 ZWQKWyAgICA4LjczMDg3Nl0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwYzQwMDAtMHgwMDBjN2Zm Zl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43MzgyNDZdIHN5c3RlbSAwMDowMDogW21l bSAweDAwMGM4MDAwLTB4MDAwY2JmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguNzQ1 NjA0XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBjYzAwMC0weDAwMGNmZmZmXSBjb3VsZCBub3Qg YmUgcmVzZXJ2ZWQKWyAgICA4Ljc1Mjk2OF0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwZDAwMDAt MHgwMDBkM2ZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43NjAzMzJdIHN5c3RlbSAw MDowMDogW21lbSAweDAwMGQ0MDAwLTB4MDAwZDdmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApb ICAgIDguNzY3Njg4XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBkODAwMC0weDAwMGRiZmZmXSBj b3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljc3NTA1M10gc3lzdGVtIDAwOjAwOiBbbWVtIDB4 MDAwZGMwMDAtMHgwMDBkZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43ODI0MDhd IHN5c3RlbSAwMDowMDogW21lbSAweDAwMGUwMDAwLTB4MDAwZTNmZmZdIGNvdWxkIG5vdCBiZSBy ZXNlcnZlZApbICAgIDguNzg5NzY4XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBlNDAwMC0weDAw MGU3ZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljc5NzEyNl0gc3lzdGVtIDAwOjAw OiBbbWVtIDB4MDAwZTgwMDAtMHgwMDBlYmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAg OC44MDQ0OTddIHN5c3RlbSAwMDowMDogW21lbSAweDAwMGVjMDAwLTB4MDAwZWZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZApbICAgIDguODExODU5XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBm MDAwMC0weDAwMGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4LjgxOTIyMl0gc3lz dGVtIDAwOjAwOiBbbWVtIDB4MDAxMDAwMDAtMHhkZjlmZmZmZl0gY291bGQgbm90IGJlIHJlc2Vy dmVkClsgICAgOC44MjY1NzldIHN5c3RlbSAwMDowMDogW21lbSAweGZlYzAwMDAwLTB4ZmVkM2Zm ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguODMzOTM1XSBzeXN0ZW0gMDA6MDA6IFtt ZW0gMHhmZWQ0YzAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljg0 MTI5NV0gc3lzdGVtIDAwOjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMw MSAoYWN0aXZlKQpbICAgIDguODQ4NDg5XSBwbnAgMDA6MDE6IFtidXMgMDAtZmVdClsgICAgOC44 NTIxMDddIHBucCAwMDowMTogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDguODU2NDY0XSBwbnAg MDA6MDE6IFtpbyAgMHgwMDAwLTB4MGNmNyB3aW5kb3ddClsgICAgOC44NjE0NTZdIHBucCAwMDow MTogW2lvICAweDBkMDAtMHhmZmZmIHdpbmRvd10KWyAgICA4Ljg2NjQ0OV0gcG5wIDAwOjAxOiBb bWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZiB3aW5kb3ddClsgICAgOC44NzIxNzJdIHBucCAwMDow MTogW21lbSAweDAwMGMwMDAwLTB4MDAwYzNmZmYgd2luZG93XQpbICAgIDguODc3ODkwXSBwbnAg MDA6MDE6IFttZW0gMHgwMDBjNDAwMC0weDAwMGM3ZmZmIHdpbmRvd10KWyAgICA4Ljg4MzYxM10g cG5wIDAwOjAxOiBbbWVtIDB4MDAwYzgwMDAtMHgwMDBjYmZmZiB3aW5kb3ddClsgICAgOC44ODkz MzVdIHBucCAwMDowMTogW21lbSAweDAwMGNjMDAwLTB4MDAwY2ZmZmYgd2luZG93XQpbICAgIDgu ODk1MDU5XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBkMDAwMC0weDAwMGQzZmZmIHdpbmRvd10KWyAg ICA4LjkwMDc3NV0gcG5wIDAwOjAxOiBbbWVtIDB4MDAwZDQwMDAtMHgwMDBkN2ZmZiB3aW5kb3dd ClsgICAgOC45MDY1MDBdIHBucCAwMDowMTogW21lbSAweDAwMGQ4MDAwLTB4MDAwZGJmZmYgd2lu ZG93XQpbICAgIDguOTEyMjI5XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBkYzAwMC0weDAwMGRmZmZm IHdpbmRvd10KWyAgICA4LjkxNzk1M10gcG5wIDAwOjAxOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBl M2ZmZiB3aW5kb3ddClsgICAgOC45MjM2ODddIHBucCAwMDowMTogW21lbSAweDAwMGU0MDAwLTB4 MDAwZTdmZmYgd2luZG93XQpbICAgIDguOTI5NDE0XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBlODAw MC0weDAwMGViZmZmIHdpbmRvd10KWyAgICA4LjkzNTEzOF0gcG5wIDAwOjAxOiBbbWVtIDB4MDAw ZWMwMDAtMHgwMDBlZmZmZiB3aW5kb3ddClsgICAgOC45NDA4NTFdIHBucCAwMDowMTogW21lbSAw eGRmYTAwMDAwLTB4ZmViZmZmZmYgd2luZG93XQpbICAgIDguOTQ2NTg1XSBwbnAgMDA6MDE6IFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDRiZmZmIHdpbmRvd10KWyAgICA4Ljk1MjM1NF0gcG5wIDAwOjAx OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3RpdmUp ClsgICAgOC45NjAwMDJdIHBucCAwMDowMjogW2lvICAweDAwMTAtMHgwMDFmXQpbICAgIDguOTY0 Mjk4XSBwbnAgMDA6MDI6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAgICA4Ljk2ODY1OV0gcG5wIDAw OjAyOiBbaW8gIDB4MDAyNC0weDAwMjVdClsgICAgOC45NzMwMTRdIHBucCAwMDowMjogW2lvICAw eDAwMjgtMHgwMDI5XQpbICAgIDguOTc3MzYxXSBwbnAgMDA6MDI6IFtpbyAgMHgwMDJjLTB4MDAy ZF0KWyAgICA4Ljk4MTcyNV0gcG5wIDAwOjAyOiBbaW8gIDB4MDAzMC0weDAwMzFdClsgICAgOC45 ODYwODhdIHBucCAwMDowMjogW2lvICAweDAwMzQtMHgwMDM1XQpbICAgIDguOTkwNDUyXSBwbnAg MDA6MDI6IFtpbyAgMHgwMDM4LTB4MDAzOV0KWyAgICA4Ljk5NDgxMl0gcG5wIDAwOjAyOiBbaW8g IDB4MDAzYy0weDAwM2RdClsgICAgOC45OTkxNzZdIHBucCAwMDowMjogW2lvICAweDAwYTQtMHgw MGE1XQpbICAgIDkuMDAzNTMxXSBwbnAgMDA6MDI6IFtpbyAgMHgwMGE4LTB4MDBhOV0KWyAgICA5 LjAwNzg5Ml0gcG5wIDAwOjAyOiBbaW8gIDB4MDBhYy0weDAwYWRdClsgICAgOS4wMTIyNjRdIHBu cCAwMDowMjogW2lvICAweDAwYjAtMHgwMGI1XQpbICAgIDkuMDE2NjI3XSBwbnAgMDA6MDI6IFtp byAgMHgwMGI4LTB4MDBiOV0KWyAgICA5LjAyMDk4Ml0gcG5wIDAwOjAyOiBbaW8gIDB4MDBiYy0w eDAwYmRdClsgICAgOS4wMjUzNDNdIHBucCAwMDowMjogW2lvICAweDAwNTAtMHgwMDUzXQpbICAg IDkuMDI5NzAwXSBwbnAgMDA6MDI6IFtpbyAgMHgwMDcyLTB4MDA3N10KWyAgICA5LjAzNDA2NF0g cG5wIDAwOjAyOiBbaW8gIDB4MDQwMC0weDA0N2ZdClsgICAgOS4wMzg0MzFdIHBucCAwMDowMjog W2lvICAweDA1MDAtMHgwNTdmXQpbICAgIDkuMDQyNzk4XSBwbnAgMDA6MDI6IFtpbyAgMHgwODAw LTB4MDgwZl0KWyAgICA5LjA0NzE1OV0gcG5wIDAwOjAyOiBbaW8gIDB4MTVlMC0weDE1ZWZdClsg ICAgOS4wNTE1MThdIHBucCAwMDowMjogW2lvICAweDE2MDAtMHgxNjdmXQpbICAgIDkuMDU1ODc2 XSBwbnAgMDA6MDI6IFttZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDkuMDYwOTYxXSBw bnAgMDA6MDI6IFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXQpbICAgIDkuMDY2MDUyXSBwbnAg MDA6MDI6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXQpbICAgIDkuMDcxMTM4XSBwbnAgMDA6 MDI6IFttZW0gMHhmZWQxMDAwMC0weGZlZDEzZmZmXQpbICAgIDkuMDc2MjI2XSBwbnAgMDA6MDI6 IFttZW0gMHhmZWQxODAwMC0weGZlZDE4ZmZmXQpbICAgIDkuMDgxMzE4XSBwbnAgMDA6MDI6IFtt ZW0gMHhmZWQxOTAwMC0weGZlZDE5ZmZmXQpbICAgIDkuMDg2NDAzXSBwbnAgMDA6MDI6IFttZW0g MHhmZWQ0NTAwMC0weGZlZDRiZmZmXQpbICAgIDkuMDkxNTQxXSBzeXN0ZW0gMDA6MDI6IFtpbyAg MHgwNDAwLTB4MDQ3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA5LjA5Nzc1NV0gc3lzdGVtIDAw OjAyOiBbaW8gIDB4MDUwMC0weDA1N2ZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgOS4xMDQwMjhd IHN5c3RlbSAwMDowMjogW2lvICAweDA4MDAtMHgwODBmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg IDkuMTEwMjk2XSBzeXN0ZW0gMDA6MDI6IFtpbyAgMHgxNWUwLTB4MTVlZl0gaGFzIGJlZW4gcmVz ZXJ2ZWQKWyAgICA5LjExNjU2NV0gc3lzdGVtIDAwOjAyOiBbaW8gIDB4MTYwMC0weDE2N2ZdIGhh cyBiZWVuIHJlc2VydmVkClsgICAgOS4xMjI4MzJdIHN5c3RlbSAwMDowMjogW21lbSAweGY4MDAw MDAwLTB4ZmJmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgOS4xMjk4MzZdIHN5c3RlbSAw MDowMjogW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApb ICAgIDkuMTM3MjA1XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBo YXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTQ0MjAyXSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQx MDAwMC0weGZlZDEzZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTUxMTk5XSBzeXN0ZW0g MDA6MDI6IFttZW0gMHhmZWQxODAwMC0weGZlZDE4ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg IDkuMTU4MTg5XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQxOTAwMC0weGZlZDE5ZmZmXSBoYXMg YmVlbiByZXNlcnZlZApbICAgIDkuMTY1MTg2XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQ0NTAw MC0weGZlZDRiZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTcyMTg1XSBzeXN0ZW0gMDA6 MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAg OS4xNzkzOTddIHBucCAwMDowMzogW21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmZdClsgICAgOS4x ODQ0NjRdIHBucCAwMDowMzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAxMDMg KGFjdGl2ZSkKWyAgICA5LjE5MTM0N10gcG5wIDAwOjA0OiBbaW8gIDB4MDAwMC0weDAwMGZdClsg ICAgOS4xOTU2NzZdIHBucCAwMDowNDogW2lvICAweDAwODAtMHgwMDhmXQpbICAgIDkuMjAwMDI1 XSBwbnAgMDA6MDQ6IFtpbyAgMHgwMGMwLTB4MDBkZl0KWyAgICA5LjIwNDM4N10gcG5wIDAwOjA0 OiBbZG1hIDRdClsgICAgOS4yMDc2OThdIHBucCAwMDowNDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRl dmljZSwgSURzIFBOUDAyMDAgKGFjdGl2ZSkKWyAgICA5LjIxNDU2Ml0gcG5wIDAwOjA1OiBbaW8g IDB4MDA2MV0KWyAgICA5LjIxODMzOF0gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2 aWNlLCBJRHMgUE5QMDgwMCAoYWN0aXZlKQpbICAgIDkuMjI1MjMxXSBwbnAgMDA6MDY6IFtpbyAg MHgwMGYwXQpbICAgIDkuMjI4OTU0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxMyB0cmlnZ2VyaW5n IDEgcG9sYXJpdHkgMApbICAgIDkuMjM0ODQyXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg aXJxIDEzIGZvciBnc2kgMTMKWyAgICA5LjI0MDU2Nl0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9 MTMgKGdzaT0xMykKWyAgICA5LjI0NTQxM10gcG5wIDAwOjA2OiBbaXJxIDEzXQpbICAgIDkuMjQ4 NzY1XSBwbnAgMDA6MDY6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzA0IChh Y3RpdmUpClsgICAgOS4yNTU2NzRdIHBucCAwMDowNzogW2lvICAweDAwNzAtMHgwMDcxXQpbICAg IDkuMjYwMDMzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAw ClsgICAgOS4yNjU4NDFdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOCBmb3IgZ3Np IDgKWyAgICA5LjI3MTM3Nl0geGVuOiAtLT4gcGlycT04IC0+IGlycT04IChnc2k9OCkKWyAgICA5 LjI3NTk0M10gcG5wIDAwOjA3OiBbaXJxIDhdClsgICAgOS4yNzkyMTVdIHBucCAwMDowNzogUGx1 ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkKWyAgICA5LjI4NjA5 N10gcG5wIDAwOjA4OiBbaW8gIDB4MDA2MF0KWyAgICA5LjI4OTgxMV0gcG5wIDAwOjA4OiBbaW8g IDB4MDA2NF0KWyAgICA5LjI5MzUzOF0geGVuOiByZWdpc3RlcmluZyBnc2kgMSB0cmlnZ2VyaW5n IDEgcG9sYXJpdHkgMApbICAgIDkuMjk5MzQ2XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg aXJxIDEgZm9yIGdzaSAxClsgICAgOS4zMDQ4OTNdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAo Z3NpPTEpClsgICAgOS4zMDk0NDldIHBucCAwMDowODogW2lycSAxXQpbICAgIDkuMzEyNzIxXSBw bnAgMDA6MDg6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMzAzIChhY3RpdmUp ClsgICAgOS4zMTk2MThdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDEyIHRyaWdnZXJpbmcgMSBwb2xh cml0eSAwClsgICAgOS4zMjU1MjFdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTIg Zm9yIGdzaSAxMgpbICAgIDkuMzMxMjQ2XSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3Np PTEyKQpbICAgIDkuMzM2MDg2XSBwbnAgMDA6MDk6IFtpcnEgMTJdClsgICAgOS4zMzk0NTNdIHBu cCAwMDowOTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIExFTjAwMjAgUE5QMGYxMyAo YWN0aXZlKQpbICAgIDkuMzQ3MDgyXSBwbnAgMDA6MGE6IFttZW0gMHhmZWQ0MDAwMC0weGZlZDQ0 ZmZmXQpbICAgIDkuMzUyMTQzXSBwbnAgMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us IElEcyBTTU8xMjAwIFBOUDBjMzEgKGFjdGl2ZSkKWyAgICA5LjM2MDQwOV0gcG5wOiBQblAgQUNQ STogZm91bmQgMTEgZGV2aWNlcwpbICAgIDkuMzY0NzgyXSBBQ1BJOiBBQ1BJIGJ1cyB0eXBlIHBu cCB1bnJlZ2lzdGVyZWQKWyAgICA5LjM3NTA1NF0gUE0tVGltZXIgZmFpbGVkIGNvbnNpc3RlbmN5 IGNoZWNrICAoMHgweGZmZmZmZikgLSBhYm9ydGluZy4KWyAgICA5LjM4MTk4N10gUENJOiBtYXgg YnVzIGRlcHRoOiAxIHBjaV90cnlfbnVtOiAyClsgICAgOS4zODY5NThdIHBjaSAwMDAwOjAwOjFj LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KWyAgICA5LjM5MjQxNF0gcGNpIDAwMDA6MDA6 MWMuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgZGlzYWJsZWRdClsgICAgOS4zOTg0MTldIHBjaSAw MDAwOjAwOjFjLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIGRpc2FibGVkXQpbICAgIDkuNDA0NDE3 XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRpc2FibGVkXQpb ICAgIDkuNDEwODgzXSBwY2kgMDAwMDowMDoxYy4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNd ClsgICAgOS40MTY0MDldIHBjaSAwMDAwOjAwOjFjLjE6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRp c2FibGVkXQpbICAgIDkuNDIyNDE2XSBwY2kgMDAwMDowMDoxYy4xOiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGYyNTAwMDAwLTB4ZjI1ZmZmZmZdClsgICAgOS40Mjk1OTZdIHBjaSAwMDAwOjAwOjFj LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgOS40MzYwMzFdIHBj aSAwMDAwOjAwOjFjLjM6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wY10KWyAgICA5LjQ0MTU2NV0g cGNpIDAwMDA6MDA6MWMuMzogICBicmlkZ2Ugd2luZG93IFtpbyAgMHg0MDAwLTB4NGZmZl0KWyAg ICA5LjQ0ODAyN10gcGNpIDAwMDA6MDA6MWMuMzogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMWQw MDAwMC0weGYyNGZmZmZmXQpbICAgIDkuNDU1MjAwXSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRn ZSB3aW5kb3cgW21lbSAweGYwNDAwMDAwLTB4ZjBiZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA5LjQ2 MzM4M10gcGNpIDAwMDA6MDA6MWMuNDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpbICAgIDku NDY4OTIwXSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweDMwMDAtMHgz ZmZmXQpbICAgIDkuNDc1Mzc1XSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW21l bSAweGYxNTAwMDAwLTB4ZjFjZmZmZmZdClsgICAgOS40ODI1NjddIHBjaSAwMDAwOjAwOjFjLjQ6 ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjBjMDAwMDAtMHhmMTNmZmZmZiA2NGJpdCBwcmVmXQpb ICAgIDkuNDkwNzUyXSBwY2kgMDAwMDowMDoxYy42OiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVd ClsgICAgOS40OTYyNzhdIHBjaSAwMDAwOjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRp c2FibGVkXQpbICAgIDkuNTAyMjkxXSBwY2kgMDAwMDowMDoxYy42OiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGYxNDAwMDAwLTB4ZjE0ZmZmZmZdClsgICAgOS41MDk0NzBdIHBjaSAwMDAwOjAwOjFj LjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgOS41MTU5NDNdIHhl bjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgOS41MjE4 NDhdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAgOS41MjY2NzRdIHBj aSAwMDAwOjAwOjFjLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAx NgpbICAgIDkuNTMzNzQyXSBwY2kgMDAwMDowMDoxYy4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg dG8gNjQKWyAgICA5LjUzOTQ3M10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw IHBvbGFyaXR5IDEKWyAgICA5LjU0NTM4M10geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdz aT0xNykKWyAgICA5LjU1MDIxMF0gcGNpIDAwMDA6MDA6MWMuMTogUENJIElOVCBCIC0+IEdTSSAx NyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgOS41NTcyOTZdIHBjaSAwMDAwOjAwOjFjLjE6 IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDkuNTYzMDMzXSB4ZW46IHJlZ2lzdGVy aW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDkuNTY4OTQ1XSB4ZW46IC0t PiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDkuNTczNzg2XSBwY2kgMDAwMDowMDox Yy4zOiBQQ0kgSU5UIEQgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICA5LjU4 MDg2MV0gcGNpIDAwMDA6MDA6MWMuMzogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAg OS41ODY1NzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAx ClsgICAgOS41OTI0NzRdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdz aSAxNgpbICAgIDkuNTk4MjAwXSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpb ICAgIDkuNjAzMDE0XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgOS42MDY5MDNdIHBj aSAwMDAwOjAwOjFjLjQ6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAx NgpbICAgIDkuNjEzOTkxXSBwY2kgMDAwMDowMDoxYy40OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg dG8gNjQKWyAgICA5LjYxOTcwM10geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAw IHBvbGFyaXR5IDEKWyAgICA5LjYyNTYwN10geGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdz aT0xOCkKWyAgICA5LjYzMDQ0N10gcGNpIDAwMDA6MDA6MWMuNjogUENJIElOVCBDIC0+IEdTSSAx OCAobGV2ZWwsIGxvdykgLT4gSVJRIDE4ClsgICAgOS42Mzc1MDZdIHBjaSAwMDAwOjAwOjFjLjY6 IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDkuNjQzMjI0XSBwY2lfYnVzIDAwMDA6 MDA6IHJlc291cmNlIDQgW2lvICAweDAwMDAtMHgwY2Y3XQpbICAgIDkuNjQ5MTE4XSBwY2lfYnVz IDAwMDA6MDA6IHJlc291cmNlIDUgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDkuNjU1MDQwXSBw Y2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsg ICAgOS42NjE2NzhdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNyBbbWVtIDB4ZGZhMDAwMDAt MHhmZWJmZmZmZl0KWyAgICA5LjY2ODMxMF0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDRiZmZmXQpbICAgIDkuNjc0OTM5XSBwY2lfYnVzIDAwMDA6MDM6 IHJlc291cmNlIDEgW21lbSAweGYyNTAwMDAwLTB4ZjI1ZmZmZmZdClsgICAgOS42ODE1NTldIHBj aV9idXMgMDAwMDowNTogcmVzb3VyY2UgMCBbaW8gIDB4NDAwMC0weDRmZmZdClsgICAgOS42ODc0 NjRdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2UgMSBbbWVtIDB4ZjFkMDAwMDAtMHhmMjRmZmZm Zl0KWyAgICA5LjY5NDEwOV0gcGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhmMDQw MDAwMC0weGYwYmZmZmZmIDY0Yml0IHByZWZdClsgICAgOS43MDE3MzRdIHBjaV9idXMgMDAwMDow ZDogcmVzb3VyY2UgMCBbaW8gIDB4MzAwMC0weDNmZmZdClsgICAgOS43MDc2MzldIHBjaV9idXMg MDAwMDowZDogcmVzb3VyY2UgMSBbbWVtIDB4ZjE1MDAwMDAtMHhmMWNmZmZmZl0KWyAgICA5Ljcx NDI3Ml0gcGNpX2J1cyAwMDAwOjBkOiByZXNvdXJjZSAyIFttZW0gMHhmMGMwMDAwMC0weGYxM2Zm ZmZmIDY0Yml0IHByZWZdClsgICAgOS43MjE4OTVdIHBjaV9idXMgMDAwMDowZTogcmVzb3VyY2Ug MSBbbWVtIDB4ZjE0MDAwMDAtMHhmMTRmZmZmZl0KWyAgICA5LjcyODU2OV0gTkVUOiBSZWdpc3Rl cmVkIHByb3RvY29sIGZhbWlseSAyClsgICAgOS43MzQzMzldIElQIHJvdXRlIGNhY2hlIGhhc2gg dGFibGUgZW50cmllczogNTI0Mjg4IChvcmRlcjogMTAsIDQxOTQzMDQgYnl0ZXMpClsgICAgOS43 NDYxNzZdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6 IDExLCA4Mzg4NjA4IGJ5dGVzKQpbICAgIDkuNzU1MzMxXSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVu dHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKWyAgICA5Ljc2MjQ1Nl0gVENQ OiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCA1MjQyODggYmluZCA2NTUzNikK WyAgICA5Ljc2OTM4OF0gVENQIHJlbm8gcmVnaXN0ZXJlZApbICAgIDkuNzcyODEyXSBVRFAgaGFz aCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDkuNzc5 MzMxXSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiA2LCAyNjIxNDQg Ynl0ZXMpClsgICAgOS43ODYyNjldIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpb ICAgIDkuNzkwODI3XSBwY2kgMDAwMDowMDowMi4wOiBCb290IHZpZGVvIGRldmljZQpbICAgIDku Nzk1OTY4XSBQQ0k6IENMUyA2NCBieXRlcywgZGVmYXVsdCA2NApbICAgIDkuODAwNTQ2XSBhdWRp dDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICA5LjgwNjIwM10g dHlwZT0yMDAwIGF1ZGl0KDEzMzYyMTU1MDUuODAyOjEpOiBpbml0aWFsaXplZApbICAgIDkuODM2 Njg5XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBw YWdlcwpbICAgIDkuODQ0NTI2XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgOS44 NDg2NzhdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2 IGJ5dGVzKQpbICAgIDkuODU1ODcxXSBmdXNlIGluaXQgKEFQSSB2ZXJzaW9uIDcuMTYpClsgICAg OS44NjAwMzhdIG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMTM5ODkKWyAgICA5Ljg2NDY4OF0gQmxv Y2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9uIDAuNCBsb2FkZWQgKG1h am9yIDI1MykKWyAgICA5Ljg3MjQ0OV0gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZApbICAg IDkuODc2NTc3XSBpbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZApbICAgIDkuODgxMTU3 XSBpbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQgKGRlZmF1bHQpClsgICAgOS44ODY3MzBdIHBj aV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41ClsgICAgOS44OTI1 NjNdIHBjaWVocDogUENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lv bjogMC40ClsgICAgOS44OTk4MTZdIEFDUEk6IERlcHJlY2F0ZWQgcHJvY2ZzIEkvRiBmb3IgQUMg aXMgbG9hZGVkLCBwbGVhc2UgcmV0cnkgd2l0aCBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgY2xl YXJlZApbICAgIDkuOTEwMjk4XSBBQ1BJOiBBQyBBZGFwdGVyIFtBQ10gKG9uLWxpbmUpClsgICAg OS45MTQ4ODldIGlucHV0OiBMaWQgU3dpdGNoIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2Rldmlj ZTowMC9QTlAwQzBEOjAwL2lucHV0L2lucHV0MApbICAgIDkuOTIzNjE2XSBBQ1BJOiBMaWQgU3dp dGNoIFtMSURdClsgICAgOS45MjcxODNdIGlucHV0OiBTbGVlcCBCdXR0b24gYXMgL2RldmljZXMv TE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBDMEU6MDAvaW5wdXQvaW5wdXQxClsgICAgOS45MzU3 NzNdIEFDUEk6IFNsZWVwIEJ1dHRvbiBbU0xQQl0KWyAgICA5LjkzOTcyMV0gaW5wdXQ6IFBvd2Vy IEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1dDIK WyAgICA5Ljk0NzQ3OF0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQpbICAgIDkuOTUxNDE3XSBB Q1BJOiBhY3BpX2lkbGUgcmVnaXN0ZXJlZCB3aXRoIGNwdWlkbGUKWyAgICA5Ljk2MDAzNV0gdGhl cm1hbCBMTlhUSEVSTTowMDogcmVnaXN0ZXJlZCBhcyB0aGVybWFsX3pvbmUwClsgICAgOS45NjU5 MzldIEFDUEk6IFRoZXJtYWwgWm9uZSBbVEhNMF0gKDYwIEMpClsgICAgOS45NzA0OTZdIEFDUEk6 IERlcHJlY2F0ZWQgcHJvY2ZzIEkvRiBmb3IgYmF0dGVyeSBpcyBsb2FkZWQsIHBsZWFzZSByZXRy eSB3aXRoIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBjbGVhcmVkClsgICAgOS45ODEzMTFdIEVS U1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKWyAgICA5Ljk4NTY0Nl0gU2VyaWFsOiA4MjUwLzE2NTUw IGRyaXZlciwgMzIgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQKWyAgIDEwLjAxMTQxNV0gQUNQ STogQmF0dGVyeSBTbG90IFtCQVQwXSAoYmF0dGVyeSBwcmVzZW50KQpbICAgMTAuMDYyNDQyXSB4 ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTAuMDY4 Mjc0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE5IGZvciBnc2kgMTkKWyAgIDEw LjA3Mzk5N10geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgIDEwLjA3ODgz MV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgMTAuMDgyNzM0XSBzZXJpYWwgMDAwMDow MDoxNi4zOiBQQ0kgSU5UIEIgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgIDEw LjExMDcwOV0gMDAwMDowMDoxNi4zOiB0dHlTNCBhdCBJL08gMHg1MGIwIChpcnEgPSAxOSkgaXMg YSAxNjU1MEEKWyAgIDEwLjExNzQzNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmlu ZyAwIHBvbGFyaXR5IDEKWyAgIDEwLjEyMzI0NF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxOSBmb3IgZ3NpIDE5ClsgICAxMC4xMjg5NDRdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJx PTE5IChnc2k9MTkpClsgICAxMC4xMzM3NTddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAg IDEwLjEzNzYzNV0gc2VyaWFsIDAwMDA6MDU6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxOSAobGV2 ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAxMC4xNDUyMDFdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJl c3Mgb3IgaXJxcyBpbiBfQ1JTClsgICAxMC4xNTA0OTJdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNl IHYwLjEwMwpbICAgMTAuMTU0OTM2XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogSW50ZWwg U2FuZHlicmlkZ2UgQ2hpcHNldApbICAgMTAuMTYxNTE4XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6 MDAuMDogZGV0ZWN0ZWQgZ3R0IHNpemU6IDIwOTcxNTJLIHRvdGFsLCAyNjIxNDRLIG1hcHBhYmxl ClsgICAxMC4xNzE4MTBdIGFncGdhcnQtaW50ZWwgMDAwMDowMDowMC4wOiBkZXRlY3RlZCA2NTUz Nksgc3RvbGVuIG1lbW9yeQpbICAgMTAuMTc4NzA0XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAu MDogQUdQIGFwZXJ0dXJlIGlzIDI1Nk0gQCAweGUwMDAwMDAwClsgICAxMC4xODY1ODhdIGJyZDog bW9kdWxlIGxvYWRlZApbICAgMTAuMTkwMDk2XSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAxMC4x OTM2OTBdIEZpeGVkIE1ESU8gQnVzOiBwcm9iZWQKWyAgIDEwLjE5NzI1N10gUFBQIGdlbmVyaWMg ZHJpdmVyIHZlcnNpb24gMi40LjIKWyAgIDEwLjIwMTgzOF0gdHVuOiBVbml2ZXJzYWwgVFVOL1RB UCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgIDEwLjIwNzE2N10gdHVuOiAoQykgMTk5OS0yMDA0IE1h eCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+ClsgICAxMC4yMTM3NzZdIGVoY2lfaGNk OiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXIKWyAgIDEw LjIyMDY4M10gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBwb3dlciBzdGF0ZSBjaGFuZ2VkIGJ5IEFD UEkgdG8gRDAKWyAgIDEwLjIyNzM2NV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBwb3dlciBzdGF0 ZSBjaGFuZ2VkIGJ5IEFDUEkgdG8gRDAKWyAgIDEwLjIzNDA4N10geGVuOiByZWdpc3RlcmluZyBn c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDEwLjIzOTk3MV0geGVuX21hcF9waXJx X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAxMC4yNDU2ODBdIHhlbjogLS0+ IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAxMC4yNTA0OTVdIEFscmVhZHkgc2V0dXAg dGhlIEdTSSA6MTYKWyAgIDEwLjI1NDM4OV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBQQ0kgSU5U IEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgIDEwLjI2MTkyN10gZWhjaV9o Y2QgMDAwMDowMDoxYS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDEwLjI2ODA2 OV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgMTAuMjcz NjI5XSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2ln bmVkIGJ1cyBudW1iZXIgMQpbICAgMTAuMjgxNDU2XSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGRl YnVnIHBvcnQgMgpbICAgMTAuMjkwMDkxXSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGNhY2hlIGxp bmUgc2l6ZSBvZiA2NCBpcyBub3Qgc3VwcG9ydGVkClsgICAxMC4yOTcyMTNdIGVoY2lfaGNkIDAw MDA6MDA6MWEuMDogaXJxIDE2LCBpbyBtZW0gMHhmMjYyYTAwMApbICAgMTAuMzA3MDcwXSBlaGNp X2hjZCAwMDAwOjAwOjFhLjA6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwClsgICAxMC4zMTMx NzBdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAxMC4zMTcwODldIGh1YiAxLTA6MS4w OiAzIHBvcnRzIGRldGVjdGVkClsgICAxMC4zMjE0MDZdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDog cG93ZXIgc3RhdGUgY2hhbmdlZCBieSBBQ1BJIHRvIEQwClsgICAxMC4zMjgwNzRdIGVoY2lfaGNk IDAwMDA6MDA6MWQuMDogcG93ZXIgc3RhdGUgY2hhbmdlZCBieSBBQ1BJIHRvIEQwClsgICAxMC4z MzQ4MDVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIzIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsg ICAxMC4zNDA3MDddIHhlbjogLS0+IHBpcnE9MjMgLT4gaXJxPTIzIChnc2k9MjMpClsgICAxMC4z NDU1MjFdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogUENJIElOVCBBIC0+IEdTSSAyMyAobGV2ZWws IGxvdykgLT4gSVJRIDIzClsgICAxMC4zNTMwNjRdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogc2V0 dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAxMC4zNTkyMjhdIGVoY2lfaGNkIDAwMDA6MDA6 MWQuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjM2NDc5Ml0gZWhjaV9oY2QgMDAwMDow MDoxZC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIKWyAg IDEwLjM3MjU5OF0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBkZWJ1ZyBwb3J0IDIKWyAgIDEwLjM4 MTI0Ml0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBjYWNoZSBsaW5lIHNpemUgb2YgNjQgaXMgbm90 IHN1cHBvcnRlZApbICAgMTAuMzg4MzY1XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IGlycSAyMywg aW8gbWVtIDB4ZjI2MjkwMDAKWyAgIDEwLjM5ODI1M10gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBV U0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgMTAuNDA0MzQxXSBodWIgMi0wOjEuMDogVVNC IGh1YiBmb3VuZApbICAgMTAuNDA4MjY1XSBodWIgMi0wOjEuMDogMyBwb3J0cyBkZXRlY3RlZApb ICAgMTAuNDEyNTcyXSBvaGNpX2hjZDogVVNCIDEuMSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChP SENJKSBEcml2ZXIKWyAgIDEwLjQxOTA4NF0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBD b250cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKWyAgIDEwLjQyNTgwOV0gaTgwNDI6IFBOUDogUFMv MiBDb250cm9sbGVyIFtQTlAwMzAzOktCRCxQTlAwZjEzOk1PVV0gYXQgMHg2MCwweDY0IGlycSAx LDEyClsgICAxMC40Mzc0NTddIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJx IDEKWyAgIDEwLjQ0MjYxN10gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEg MTIKWyAgIDEwLjQ0ODA1M10gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig YWxsIG1pY2UKWyAgIDEwLjQ1NDAxMV0gcnRjX2Ntb3MgMDA6MDc6IFJUQyBjYW4gd2FrZSBmcm9t IFM0ClsgICAxMC40NTg5ODVdIHJ0Y19jbW9zIDAwOjA3OiBydGMgY29yZTogcmVnaXN0ZXJlZCBy dGNfY21vcyBhcyBydGMwClsgICAxMC40NjU0MzFdIHJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgbW9u dGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtClsgICAxMC40NzE2NTJdIGRldmljZS1tYXBwZXI6IHVl dmVudDogdmVyc2lvbiAxLjAuMwpbICAgMTAuNDc2NTI3XSBkZXZpY2UtbWFwcGVyOiBpb2N0bDog NC4yMC4wLWlvY3RsICgyMDExLTAyLTAyKSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv bQpbICAgMTAuNDg1MzYyXSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBsYWRkZXIKWyAgIDEwLjQ4 OTcxM10gY3B1aWRsZTogdXNpbmcgZ292ZXJub3IgbWVudQpbICAgMTAuNDkzODc3XSBFRkkgVmFy aWFibGVzIEZhY2lsaXR5IHYwLjA4IDIwMDQtTWF5LTE3ClsgICAxMC40OTkzOTldIFRDUCBjdWJp YyByZWdpc3RlcmVkClsgICAxMC41MDA5MzddIGlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtl eWJvYXJkIGFzIC9kZXZpY2VzL3BsYXRmb3JtL2k4MDQyL3NlcmlvMC9pbnB1dC9pbnB1dDMKWyAg IDEwLjUxMTkxNl0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApbICAgMTAuNTE2 OTY4XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAxMC41MjE2MTZdIFJl Z2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5IHR5cGUKWyAgIDEwLjUyNjY1Nl0gUE06IEhp YmVybmF0aW9uIGltYWdlIG5vdCBwcmVzZW50IG9yIGNvdWxkIG5vdCBiZSBsb2FkZWQuClsgICAx MC41MzMzODJdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQpbICAgMTAuNTQ5MTQyXSAg IE1hZ2ljIG51bWJlcjogMTI6ODY4Ojk4MQpbICAgMTAuNTUzMTQxXSBydGNfY21vcyAwMDowNzog c2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMi0wNS0wNSAxMDo1ODoyNyBVVEMgKDEzMzYyMTU1 MDcpClsgICAxMC41NzAzODVdIEJJT1MgRUREIGZhY2lsaXR5IHYwLjE2IDIwMDQtSnVuLTI1LCAw IGRldmljZXMgZm91bmQKWyAgIDEwLjU3NjY3MV0gRUREIGluZm9ybWF0aW9uIG5vdCBhdmFpbGFi bGUuClsgICAxMC41ODE0NjldIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDk4OGsgZnJl ZWQKWyAgIDEwLjU4Njc2OF0gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBk YXRhOiAxMjI4OGsKWyAgIDEwLjU5ODE3Nl0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTog MjAzMmsgZnJlZWQKWyAgIDEwLjYwNDE5M10gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTog MTM4OGsgZnJlZWQKTG9hZGluZywgcGxlYXNlIHdhaXQuLi4KWyAgIDEwLjYzMDI2OV0gdXNiIDEt MTogbmV3IGhpZ2ggc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNpX2hjZApbICAg MTAuNjU4OTI1XSB1ZGV2ZFs4N106IHN0YXJ0aW5nIHZlcnNpb24gMTczClsgICAxMC43NTEzMjNd IGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAxLjMuMTAtazIKWyAg IDEwLjc1NzYyMV0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTEgSW50ZWwgQ29ycG9y YXRpb24uClsgICAxMC43NjM5MzldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcg MCBwb2xhcml0eSAxClsgICAxMC43Njk4MjZdIHhlbjogLS0+IHBpcnE9MjAgLT4gaXJxPTIwIChn c2k9MjApClsgICAxMC43NzQ3MjRdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IFBDSSBJTlQgQSAtPiBH U0kgMjAgKGxldmVsLCBsb3cpIC0+IElSUSAyMApbICAgMTAuNzgyNzc2XSBodWIgMS0xOjEuMDog VVNCIGh1YiBmb3VuZApbICAgMTAuNzg2ODI2XSBodWIgMS0xOjEuMDogNiBwb3J0cyBkZXRlY3Rl ZApbICAgMTAuNzk5NDE2XSBzZGhjaTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250cm9sbGVyIElu dGVyZmFjZSBkcml2ZXIKWyAgIDEwLjgwNTg2OV0gc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUg T3NzbWFuClsgICAxMC44MTA1NjZdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IHNldHRpbmcgbGF0ZW5j eSB0aW1lciB0byA2NApbICAgMTAuODE5MDI4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmln Z2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTAuODI0ODM5XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKWyAgIDEwLjgzMDU1OV0geGVuOiAtLT4gcGlycT0xOCAt PiBpcnE9MTggKGdzaT0xOCkKWyAgIDEwLjgzNTQwM10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox OApbICAgMTAuODM5Mjk1XSB4aGNpX2hjZCAwMDAwOjBlOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kg MTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAgMTAuODU2Nzc0XSBzZGhjaS1wY2kgMDAwMDow ZDowMC4wOiBTREhDSSBjb250cm9sbGVyIGZvdW5kIFsxMTgwOmU4MjJdIChyZXYgNykKWyAgIDEw Ljg2NDQ4NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK WyAgIDEwLjg3MDI4M10geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np IDE2ClsgICAxMC44NzU5OTJdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg ICAxMC44ODA4MzddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgIDEwLjg4NDY5NF0gc2Ro Y2ktcGNpIDAwMDA6MGQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4g SVJRIDE2ClsgICAxMC44OTI1ODRdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogc2V0dGluZyBsYXRl bmN5IHRpbWVyIHRvIDY0ClsgICAxMC44OTg2ODhdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogeEhD SSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjkwNDczOV0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBu ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMKWyAgIDEwLjkxMjU1 Nl0gdXNiIDItMTogbmV3IGhpZ2ggc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNp X2hjZApbICAgMTAuOTE5NzU3XSBzZGhjaS1wY2kgMDAwMDowZDowMC4wOiBzZXR0aW5nIGxhdGVu Y3kgdGltZXIgdG8gNjQKWyAgIDEwLjkyNjEyNl0gbW1jMDogbm8gdm1tYyByZWd1bGF0b3IgZm91 bmQKWyAgIDEwLjkzMDg1OF0gUmVnaXN0ZXJlZCBsZWQgZGV2aWNlOiBtbWMwOjoKWyAgIDEwLjkz NTU3MF0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBpcnEgMTgsIGlvIG1lbSAweGYxNDAwMDAwClsg ICAxMC45NDIyODVdIG1tYzA6IFNESENJIGNvbnRyb2xsZXIgb24gUENJIFswMDAwOjBkOjAwLjBd IHVzaW5nIERNQQpbICAgMTAuOTQ5NTM0XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBm b3Igcm9vdCBodWIKWyAgIDEwLjk1NDk0N10geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs ZWQgZm9yIHJvb3QgaHViClsgICAxMC45NjA3MTJdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5k ClsgICAxMC45NjQ3MDddIGh1YiAzLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAxMC45Njkw MjNdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjk3 NDU1MV0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3Np Z25lZCBidXMgbnVtYmVyIDQKWyAgIDEwLjk4MjU3M10geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBj YWxsZWQgZm9yIHJvb3QgaHViClsgICAxMC45ODc5NDFdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lk dGggY2FsbGVkIGZvciByb290IGh1YgpbICAgMTAuOTkzNjg0XSBodWIgNC0wOjEuMDogVVNCIGh1 YiBmb3VuZApbICAgMTAuOTk3NjU5XSBodWIgNC0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAg MTEuMDQ4MDkwXSBlMTAwMGUgMDAwMDowMDoxOS4wOiBldGgwOiAoUENJIEV4cHJlc3M6Mi41R1Qv czpXaWR0aCB4MSkgZjA6ZGU6ZjE6NWI6YjM6N2QKWyAgIDExLjA1NjQwNV0gZTEwMDBlIDAwMDA6 MDA6MTkuMDogZXRoMDogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uClsgICAx MS4wNjI3MjJdIGh1YiAyLTE6MS4wOiBVU0IgaHViIGZvdW5kClsgICAxMS4wNjI4MTddIGh1YiAy LTE6MS4wOiA4IHBvcnRzIGRldGVjdGVkClsgICAxMS4wNzIwNDVdIGUxMDAwZSAwMDAwOjAwOjE5 LjA6IGV0aDA6IE1BQzogMTAsIFBIWTogMTEsIFBCQSBObzogMTAwMEZGLTBGRgpbICAgMTEuMDc5 MzMzXSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgIDExLjA4MzY3N10geGVuOiBy ZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDExLjA4OTUwN10g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOSBmb3IgZ3NpIDE5ClsgICAxMS4wOTUx ODhdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpClsgICAxMS4wOTk5OTRdIEFs cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAgIDExLjEwMzg2M10gYWhjaSAwMDAwOjAwOjFmLjI6 IFBDSSBJTlQgQiAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgMTEuMTExMjc2 XSBhaGNpOiBTU1MgZmxhZyBzZXQsIHBhcmFsbGVsIGJ1cyBzY2FuIGRpc2FibGVkClsgICAxMS4x MjYzMzZdIGFoY2kgMDAwMDowMDoxZi4yOiBBSENJIDAwMDEuMDMwMCAzMiBzbG90cyA2IHBvcnRz IDYgR2JwcyAweDEzIGltcGwgU0FUQSBtb2RlClsgICAxMS4xMzQ4OTBdIGFoY2kgMDAwMDowMDox Zi4yOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBzdGFnIHBtIGxlZCBjbG8gcGlvIHNsdW0g cGFydCBlbXMgc3hzIGFwc3QgClsgICAxMS4xNDQ2MTFdIGFoY2kgMDAwMDowMDoxZi4yOiBzZXR0 aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDExLjE1NDUxMl0gdXNiIDEtMS4zOiBuZXcgZnVs bCBzcGVlZCBVU0IgZGV2aWNlIG51bWJlciAzIHVzaW5nIGVoY2lfaGNkClsgICAxMS4xNjY3ODVd IHNjc2kwIDogYWhjaQpbICAgMTEuMTY5NTU4XSBzY3NpMSA6IGFoY2kKWyAgIDExLjE3MjI4OF0g c2NzaTIgOiBhaGNpClsgICAxMS4xNzUwMzRdIHNjc2kzIDogYWhjaQpbICAgMTEuMTc3NzUwXSBz Y3NpNCA6IGFoY2kKWyAgIDExLjE4MDQ3Ml0gc2NzaTUgOiBhaGNpClsgICAxMS4xODM4ODddIGF0 YTE6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmMjYyODAwMCBwb3J0IDB4ZjI2Mjgx MDAgaXJxIDMwNApbICAgMTEuMTkxNjc0XSBhdGEyOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0y MDQ4QDB4ZjI2MjgwMDAgcG9ydCAweGYyNjI4MTgwIGlycSAzMDQKWyAgIDExLjE5OTU1M10gYXRh MzogRFVNTVkKWyAgIDExLjIwMjE3OF0gYXRhNDogRFVNTVkKWyAgIDExLjIwNDgwMF0gYXRhNTog U0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGYyNjI4MDAwIHBvcnQgMHhmMjYyODMwMCBp cnEgMzA0ClsgICAxMS4yMTI3MDBdIGF0YTY6IERVTU1ZClsgICAxMS4zMjI2NjBdIHVzYiAxLTEu NDogbmV3IGZ1bGwgc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNpX2hjZApbICAg MTEuNTM0MzE0XSBhdGExOiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250 cm9sIDMwMCkKWyAgIDExLjU0MzQwN10gYXRhMS4wMDogQUNQSSBjbWQgZWYvMDI6MDA6MDA6MDA6 MDA6YTAgKFNFVCBGRUFUVVJFUykgc3VjY2VlZGVkClsgICAxMS41NTA2OTBdIGF0YTEuMDA6IEFD UEkgY21kIGY1LzAwOjAwOjAwOjAwOjAwOmEwIChTRUNVUklUWSBGUkVFWkUgTE9DSykgZmlsdGVy ZWQgb3V0ClsgICAxMS41NTkwNDBdIGF0YTEuMDA6IEFDUEkgY21kIGVmLzEwOjAzOjAwOjAwOjAw OmEwIChTRVQgRkVBVFVSRVMpIGZpbHRlcmVkIG91dApbICAgMTEuNTY5MTY2XSBhdGExLjAwOiBB VEEtODogU1QzMjBMVDAwMC05VkwxNDIsIDAwMDNMVk0xLCBtYXggVURNQS8xMzMKWyAgIDExLjU3 NTkxNl0gYXRhMS4wMDogNjI1MTQyNDQ4IHNlY3RvcnMsIG11bHRpIDE2OiBMQkE0OCBOQ1EgKGRl cHRoIDMxLzMyKQpbICAgMTEuNTg2MDE5XSBhdGExLjAwOiBBQ1BJIGNtZCBlZi8wMjowMDowMDow MDowMDphMCAoU0VUIEZFQVRVUkVTKSBzdWNjZWVkZWQKWyAgIDExLjU5MzMxNF0gYXRhMS4wMDog QUNQSSBjbWQgZjUvMDA6MDA6MDA6MDA6MDA6YTAgKFNFQ1VSSVRZIEZSRUVaRSBMT0NLKSBmaWx0 ZXJlZCBvdXQKWyAgIDExLjYwMTY2Ml0gYXRhMS4wMDogQUNQSSBjbWQgZWYvMTA6MDM6MDA6MDA6 MDA6YTAgKFNFVCBGRUFUVVJFUykgZmlsdGVyZWQgb3V0ClsgICAxMS42MTE4MDBdIGF0YTEuMDA6 IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAxMS42MTY0MjBdIHNjc2kgMDowOjA6MDogRGly ZWN0LUFjY2VzcyAgICAgQVRBICAgICAgU1QzMjBMVDAwMC05VkwxNCAwMDAzIFBROiAwIEFOU0k6 IDUKWyAgIDExLjYyNTA0OF0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0 eXBlIDAKWyAgIDExLjYyNTA1M10gc2QgMDowOjA6MDogW3NkYV0gNjI1MTQyNDQ4IDUxMi1ieXRl IGxvZ2ljYWwgYmxvY2tzOiAoMzIwIEdCLzI5OCBHaUIpClsgICAxMS42MjUxMDhdIHNkIDA6MDow OjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAxMS42MjUxMTBdIHNkIDA6MDowOjA6 IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAxMS42MjUxMzNdIHNkIDA6MDowOjA6 IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBkb2Vzbid0 IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgMTEuNjcxOTczXSAgc2RhOiBzZGExIHNkYTIgc2RhMyBz ZGE0IDwgc2RhNSBzZGE2IHNkYTcgPgpbICAgMTEuNjc3ODY3XSBzZCAwOjA6MDowOiBbc2RhXSBB dHRhY2hlZCBTQ1NJIGRpc2sKWyAgIDExLjk3ODI5OV0gYXRhMjogU0FUQSBsaW5rIGRvd24gKFNT dGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAxMi4zMDYyOTldIGF0YTU6IFNBVEEgbGluayBkb3du IChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgMTIuOTkwNzAzXSBFWFQ0LWZzIChzZGE3KTog bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpm c2NrIGZyb20gdXRpbC1saW51eCAyLjE5LjEKZnNjayBmcm9tIHV0aWwtbGludXggMi4xOS4xCi9k ZXYvc2RhNzogY2xlYW4sIDg5Mzc4OS8xNDkyNTgyNCBmaWxlcywgMjkxNjA0NDIvNTk2Nzc0NDAg YmxvY2tzIChjaGVjayBpbiA0IG1vdW50cykKL2Rldi9zZGE1OiBjbGVhbiwgMjc0LzYyMjQ4IGZp bGVzLCA3NjU0NS8yNDg4MzIgYmxvY2tzIChjaGVjayBpbiA0IG1vdW50cykKU2tpcHBpbmcgcHJv ZmlsZSBpbiAvZXRjL2FwcGFybW9yLmQvZGlzYWJsZTogdXNyLmJpbi5maXJlZm94CiAqIFN0YXJ0 aW5nIG1ETlMvRE5TLVNEIGRhZW1vbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbIE9LIF0KICogU3RhcnRpbmcgQXBwQXJtb3IgcHJvZmlsZXMgICAgICAgKFhFTikg Q2Fubm90IGJpbmQgSVJRMTkgdG8gZG9tMC4gSW4gdXNlIGJ5ICduczE2NTUwJy4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFsgT0sgXSAKICogU3RvcHBpbmcgRmFpbHNhZmUgQm9vdCBEZWxheSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgT0sgXQogKiBTdG9wcGluZyBTeXN0ZW0g ViBpbml0aWFsaXNhdGlvbiBjb21wYXRpYmlsaXR5ICAgICAgICAgICAgICAgICAgICAgICAgWyBP SyBdCiAqIFN0YXJ0aW5nIFN5c3RlbSBWIHJ1bmxldmVsIGNvbXBhdGliaWxpdHkgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3RvcHBpbmcgYXV0b21hdGljIGNyYXNoIHJl cG9ydCBnZW5lcmF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtmYWlsXQogKiBTdGFy dGluZyBMaWdodERNIERpc3BsYXkgTWFuYWdlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIHNhdmUga2VybmVsIG1lc3NhZ2VzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3RhcnRpbmcgS1ZNICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsg T0sgXQogKiBTdGFydGluZyBhbmFjKGgpcm9uaXN0aWMgY3JvbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIEFDUEkgZGFlbW9uICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3Rh cnRpbmcgcmVndWxhciBiYWNrZ3JvdW5kIHByb2dyYW0gcHJvY2Vzc2luZyBkYWVtb24gICAgICAg ICAgICAgICAgIFsgT0sgXQogKiBTdGFydGluZyBkZWZlcnJlZCBleGVjdXRpb24gc2NoZWR1bGVy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIENQVSBp bnRlcnJ1cHRzIGJhbGFuY2luZyBkYWVtb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb IE9LIF0KICogU3RhcnRpbmcgQ1BVIGludGVycnVwdHMgYmFsYW5jaW5nIGRhZW1vbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtmYWlsXQpTdGFydGluZyBveGVuc3RvcmVkLi4uICogU3Rv cHBpbmcgc2F2ZSBrZXJuZWwgbWVzc2FnZXMgICAgICAgICAgICAgICAgICAgWyBPSyBdClsgICAz MS42NTM0NDFdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAzMS42NTgwMTRd IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAzMS42NjI2ODFdIFgKRU5CVVM6 IFVuYWJsZSB0b1NldHRpbmcgZG9tYWluIDAgbmFtZS4uLiByZWFkIGNwdSBzdGF0ZQoKWyAgIDMx LjY2OTk5MF0gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKU3RhcnRpbmcgeGVuY29u c29sZWQuLi4Kc3BlZWNoLWRpc3BhdGNoZXIgZGlzYWJsZWQ7IGVkaXQgL2V0Yy9kZWZhdWx0L3Nw ZWVjaC1kaXNwYXRjaGVyCkNoZWNraW5nIGZvciBydW5uaW5nIHVuYXR0ZW5kZWQtdXBncmFkZXM6 IAogKiBTdGFydGluZyBWaXJ0dWFsQm94IGtlcm5lbCBtb2R1bGVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgWyBPSyBdIApTdGFydGluZyBkb21haW4gd2F0Y2hkb2cgZGFlbW9u OiAgKiB4ZW53YXRjaGRvZ2Qgc3RhcnR1cAoKICogU3RhcnRpbmcgYmx1ZXRvb3RoICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgT0sgXSAKICogUHVs c2VBdWRpbyBjb25maWd1cmVkIGZvciBwZXItdXNlciBzZXNzaW9ucwpzYW5lZCBkaXNhYmxlZDsg ZWRpdCAvZXRjL2RlZmF1bHQvc2FuZWQKCiAqIENoZWNraW5nIGJhdHRlcnkgc3RhdGUuLi4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0gCihYRU4pIENh bm5vdCBiaW5kIElSUTE5IHRvIGRvbTAuIEluIHVzZSBieSAnbnMxNjU1MCcuCihYRU4pIEhWTTE6 IEhWTSBMb2FkZXIKKFhFTikgSFZNMTogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKKFhFTikg SFZNMTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDMKKFhFTikgSFZN MTogU3lzdGVtIHJlcXVlc3RlZCBST01CSU9TCihYRU4pIEhWTTE6IENQVSBzcGVlZCBpcyAyNjkx IE1IegooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooWEVO KSBIVk0xOiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQooWEVOKSBpcnEuYzoyNzA6IERv bTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDEg cm91dGVkIHRvIElSUTEwCihYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQg MCAtPiAxMQooWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKKFhFTikg aXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKFhFTikgSFZNMTogUENJ LUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwMToyIElOVEQt PklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihYRU4pIEhWTTE6IHBj aSBkZXYgMDM6MCBJTlRBLT5JUlE1CihYRU4pIEhWTTE6IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6 ZSAwMTAwMDAwMDogZjAwMDAwMDgKKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBzaXpl IDAxMDAwMDAwOiBmMTAwMDAwOAooWEVOKSBIVk0xOiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUg MDAwMDAxMDA6IDAwMDBjMDAxCihYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSAw MDAwMDAyMDogMDAwMGMxMDEKKFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAw MDAwMDEwOiAwMDAwYzEyMQooWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv bjoKKFhFTikgSFZNMTogIC0gQ1BVMCAuLi4gMzYtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4u LiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIEhWTTE6IFRlc3RpbmcgSFZNIGVudmly b25tZW50OgooWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4u LiBwYXNzZWQKKFhFTikgSFZNMTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3Nl ZAooWEVOKSBIVk0xOiBQYXNzZWQgMiBvZiAyIHRlc3RzCihYRU4pIEhWTTE6IFdyaXRpbmcgU01C SU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMTogTG9hZGluZyBST01CSU9TIC4uLgooWEVOKSBIVk0x OiAxMjYzNiBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6CihYRU4pIEhW TTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAxMDAwLTB4ZmMwMDQxNWMgLi4uIGRvbmUKKFhFTikg SFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooWEVOKSBIVk0xOiBMb2FkaW5nIFN0YW5kYXJk IFZHQUJJT1MgLi4uCihYRU4pIEhWTTE6IE9wdGlvbiBST01zOgooWEVOKSBIVk0xOiAgYzAwMDAt YzlmZmY6IFZHQSBCSU9TCihYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KKFhFTikgSFZNMTog dm04NiBUU1MgYXQgZmMwMTAyODAKKFhFTikgSFZNMTogQklPUyBtYXA6CihYRU4pIEhWTTE6ICBm MDAwMC1mZmZmZjogTWFpbiBCSU9TCihYRU4pIEhWTTE6IEU4MjAgdGFibGU6CihYRU4pIEhWTTE6 ICBbMDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0KKFhFTikg SFZNMTogIFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VS VkVECihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw MDAwCihYRU4pIEhWTTE6ICBbMDJdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAw MDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw MDAwMDoxZjAwMDAwMDogUkFNCihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDoxZjAwMDAwMCAt IDAwMDAwMDAwOmZjMDAwMDAwCihYRU4pIEhWTTE6ICBbMDRdOiAwMDAwMDAwMDpmYzAwMDAwMCAt IDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiBJbnZva2luZyBST01CSU9T IC4uLgooWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6 MzI6MjkgJAooWEVOKSBzdGR2Z2EuYzoxNDc6ZDEgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5n IG1vZGVzCihYRU4pIEhWTTE6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEv MjcgMDk6NDQ6MTIgdnJ1cHBlcnQgRXhwICQKKFhFTikgSFZNMTogVkJFIEJpb3MgJElkOiB2YmUu Yyx2IDEuNjAgMjAwOC8wMy8wMiAwNzo0NzoyMSB2cnVwcGVydCBFeHAgJAooWEVOKSBIVk0xOiBC b2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5CihYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEg JCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkCihYRU4pIEhWTTE6IE9wdGlvbnM6IGFwbWJp b3MgcGNpYmlvcyBlbHRvcml0byBQTU0gCihYRU4pIEhWTTE6IAooWEVOKSBIVk0xOiBhdGEwLTA6 IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMKKFhFTikg SFZNMTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDAwMCBN Qnl0ZXMpCihYRU4pIEhWTTE6IElERSB0aW1lIG91dAooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTog CihYRU4pIEhWTTE6IAooWEVOKSBIVk0xOiBQcmVzcyBGMTIgZm9yIGJvb3QgbWVudS4KKFhFTikg SFZNMTogCihYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKFhFTikgSFZNMTog Qm9vdGluZyBmcm9tIDAwMDA6N2MwMAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp b24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0xOiBpbnQxM19oYXJk ZGlzazogZnVuY3Rpb24gMDgsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0x OiAqKiogaW50IDE1aCBmdW5jdGlvbiBBWD0wMGMwLCBCWD0wMDAwIG5vdCB5ZXQgc3VwcG9ydGVk IQooWEVOKSBIVk0yOiBIVk0gTG9hZGVyCihYRU4pIEhWTTI6IERldGVjdGVkIFhlbiB2NC4yLXVu c3RhYmxlCihYRU4pIEhWTTI6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5l bCA0CihYRU4pIEhWTTI6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwooWEVOKSBIVk0yOiBDUFUg c3BlZWQgaXMgMjY5MSBNSHoKKFhFTikgaXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDAgY2hhbmdl ZCAwIC0+IDUKKFhFTikgSFZNMjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikg aXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihYRU4pIEhWTTI6IFBD SS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBpcnEuYzoyNzA6IERvbTIgUENJIGxp bmsgMiBjaGFuZ2VkIDAgLT4gMTEKKFhFTikgSFZNMjogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRv IElSUTExCihYRU4pIGlycS5jOjI3MDogRG9tMiBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihY RU4pIEhWTTI6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihYRU4pIEhWTTI6IHBjaSBk ZXYgMDE6MiBJTlRELT5JUlE1CihYRU4pIEhWTTI6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAoo WEVOKSBIVk0yOiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQooWEVOKSBIVk0yOiBwY2kgZGV2IDA0 OjAgSU5UQS0+SVJRNQooWEVOKSBIVk0yOiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDEwMDAw MDA6IGYwMDAwMDA4CihYRU4pIEhWTTI6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAw MDogZjEwMDAwMDgKKFhFTikgSFZNMjogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMDAwMTAw OiAwMDAwYzAwMQooWEVOKSBIVk0yOiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6 IDAwMDBjMTAxCihYRU4pIEhWTTI6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDog ZjIwMDAwMDAKKFhFTikgSFZNMjogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAwMDAwMDIwOiAw MDAwYzIwMQooWEVOKSBIVk0yOiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAw MDBjMjIxCihYRU4pIEhWTTI6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOgooWEVOKSBI Vk0yOiAgLSBDUFUwIC4uLiAzNi1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMi84XSAuLi4gZG9uZS4KKFhFTikgSFZNMjogIC0gQ1BVMSAuLi4gMzYtYml0IHBoeXMgLi4u IGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIEhWTTI6IFRl c3RpbmcgSFZNIGVudmlyb25tZW50OgooWEVOKSBIVk0yOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFn ZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKFhFTikgSFZNMjogIC0gR1MgYmFzZSBNU1JzIGFuZCBT V0FQR1MgLi4uIHBhc3NlZAooWEVOKSBIVk0yOiBQYXNzZWQgMiBvZiAyIHRlc3RzCihYRU4pIEhW TTI6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMjogTG9hZGluZyBST01CSU9T IC4uLgooWEVOKSBIVk0yOiAxMjYzNiBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVu c2lvbnM6CihYRU4pIEhWTTI6ICAgUmVsb2NhdGluZyB0byAweGZjMDAxMDAwLTB4ZmMwMDQxNWMg Li4uIGRvbmUKKFhFTikgSFZNMjogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooWEVOKSBIVk0yOiBM b2FkaW5nIFN0YW5kYXJkIFZHQUJJT1MgLi4uCihYRU4pIEhWTTI6IExvYWRpbmcgUENJIE9wdGlv biBST00gLi4uCihYRU4pIEhWTTI6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnCihY RU4pIEhWTTI6ICAtIFByb2R1Y3QgbmFtZTogaVBYRQooWEVOKSBIVk0yOiBPcHRpb24gUk9NczoK KFhFTikgSFZNMjogIGMwMDAwLWM5ZmZmOiBWR0EgQklPUwooWEVOKSBIVk0yOiAgY2EwMDAtZDlm ZmY6IEV0aGVyYm9vdCBST00KKFhFTikgSFZNMjogTG9hZGluZyBBQ1BJIC4uLgooWEVOKSBIVk0y OiB2bTg2IFRTUyBhdCBmYzAxMDI4MAooWEVOKSBIVk0yOiBCSU9TIG1hcDoKKFhFTikgSFZNMjog IGYwMDAwLWZmZmZmOiBNYWluIEJJT1MKKFhFTikgSFZNMjogRTgyMCB0YWJsZToKKFhFTikgSFZN MjogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQooWEVO KSBIVk0yOiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVT RVJWRUQKKFhFTikgSFZNMjogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAw ZTAwMDAKKFhFTikgSFZNMjogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAx MDAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTI6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAw MDAwMDAwOjNmMDAwMDAwOiBSQU0KKFhFTikgSFZNMjogIEhPTEU6IDAwMDAwMDAwOjNmMDAwMDAw IC0gMDAwMDAwMDA6ZmMwMDAwMDAKKFhFTikgSFZNMjogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAw IC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTI6IEludm9raW5nIFJPTUJJ T1MgLi4uCihYRU4pIEhWTTI6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAx NzozMjoyOSAkCihYRU4pIHN0ZHZnYS5jOjE0NzpkMiBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hp bmcgbW9kZXMKKFhFTikgSFZNMjogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8w MS8yNyAwOTo0NDoxMiB2cnVwcGVydCBFeHAgJAooWEVOKSBIVk0yOiBWQkUgQmlvcyAkSWQ6IHZi ZS5jLHYgMS42MCAyMDA4LzAzLzAyIDA3OjQ3OjIxIHZydXBwZXJ0IEV4cCAkCihYRU4pIEhWTTI6 IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkKKFhFTikgSFZNMjogJFJldmlzaW9uOiAxLjIy MSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKKFhFTikgSFZNMjogT3B0aW9uczogYXBt YmlvcyBwY2liaW9zIGVsdG9yaXRvIFBNTSAKKFhFTikgSFZNMjogCihYRU4pIEhWTTI6IGF0YTAt MDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MwooWEVO KSBIVk0yOiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDIwMDAw IE1CeXRlcykKKFhFTikgSFZNMjogSURFIHRpbWUgb3V0CihYRU4pIEhWTTI6IAooWEVOKSBIVk0y OiAKKFhFTikgSFZNMjogCihYRU4pIEhWTTI6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooWEVO KSBIVk0yOiAKKFhFTikgSFZNMjogQm9vdGluZyBmcm9tIENELVJvbS4uLgooWEVOKSBIVk0yOiBD RFJPTSBib290IGZhaWx1cmUgY29kZSA6IDAwMDIKKFhFTikgSFZNMjogQm9vdCBmcm9tIENELVJv bSBmYWlsZWQ6IGNvdWxkIG5vdCByZWFkIHRoZSBib290IGRpc2sKKFhFTikgSFZNMjogCihYRU4p IEhWTTI6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKFhFTikgSFZNMjogQm9vdGluZyBmcm9t IDAwMDA6N2MwMAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMTUsIHVubWFw cGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0xOiAqKiogaW50IDE1aCBmdW5jdGlvbiBB WD1lYzAwLCBCWD0wMDAyIG5vdCB5ZXQgc3VwcG9ydGVkIQooWEVOKSBIVk0xOiBLQkQ6IHVuc3Vw cG9ydGVkIGludCAxNmggZnVuY3Rpb24gMDMKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1 bmN0aW9uIDE1LCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVMREw9ODEKKFhFTikgSFZNMTogaW50MTNf aGFyZGRpc2s6IGZ1bmN0aW9uIDAyLCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVMREw9ODEKKFhFTikg SFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVM REw9ODEKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhF TikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIGlycS5j OjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERv bTEgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBpcnEuYzozNTA6IERvbTEgY2FsbGJh Y2sgdmlhIGNoYW5nZWQgdG8gUENJIElOVHggRGV2IDB4MDMgSW50QQooWEVOKSBpcnEuYzoyNzA6 IERvbTIgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERvbTIgUENJ IGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgaXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDIg Y2hhbmdlZCAxMSAtPiAwCihYRU4pIGlycS5jOjI3MDogRG9tMiBQQ0kgbGluayAzIGNoYW5nZWQg NSAtPiAwCihYRU4pICoqKiBJUlEgQlVHIGZvdW5kICoqKgooWEVOKSBDUFUwIC1UZXN0aW5nIHZl Y3RvciAyMzYgZnJvbSBiaXRtYXAgNDEsNDksNjQsNzIsODAsODIsODQsODgsOTYsOTgsMTA0LDEy MCwxMjMsMTM2LDE0NSwxNTIsMTYwLDE2OCwxOTIsMjAwLTIwMSwyMjMKKFhFTikgR3Vlc3QgaW50 ZXJydXB0IGluZm9ybWF0aW9uOgooWEVOKSAgICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAg dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZAooWEVO KSAgICBJUlE6ICAgMSBhZmZpbml0eTowMiB2ZWM6N2IgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh dHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICAxKC0tLS0pLAooWEVOKSAg ICBJUlE6ICAgMiBhZmZpbml0eTpmZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVz PTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgMyBhZmZpbml0eTowMSB2 ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu ZAooWEVOKSAgICBJUlE6ICAgNCBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVkZ2Ug ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgNSBhZmZp bml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl ZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NTggdHlwZT1JTy1B UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6 ICAgNyBhZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAw MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgOCBhZmZpbml0eTowOCB2ZWM6Mjkg dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s aXN0PTA6ICA4KC0tLS0pLAooWEVOKSAgICBJUlE6ICAgOSBhZmZpbml0eTowMSB2ZWM6OTEgdHlw ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0 PTA6ICA5KC0tLS0pLAooWEVOKSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6NzggdHlwZT1J Ty1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJ UlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoKCg== --20cf3074d4fe662a8904bf4ebda6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3074d4fe662a8904bf4ebda6-- From xen-devel-bounces@lists.xen.org Sat May 05 19:07:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 19:07:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQkJm-000786-EY; Sat, 05 May 2012 19:06:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQkJk-00077z-VF for xen-devel@lists.xensource.com; Sat, 05 May 2012 19:06:57 +0000 Received: from [85.158.143.35:18843] by server-1.bemta-4.messagelabs.com id 6C/AB-20925-05A75AF4; Sat, 05 May 2012 19:06:56 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336244813!7668840!1 X-Originating-IP: [209.85.216.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20543 invoked from network); 5 May 2012 19:06:54 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2012 19:06:54 -0000 Received: by qcsp15 with SMTP id p15so3220636qcs.30 for ; Sat, 05 May 2012 12:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u7J+EPMs3L53mJVbdMpcRjRBmCYpSZ6SNzdVKbLr2u4=; b=COamM8eanCOugdOt6paYwnKeqSj4zwSXzo17CvEiEITnuNORW1j7rseucoDW4ztHRe uGf4TVuxRUEgEoqCmO9e0tKWxMPsSpTxvoTn9IFlCS/VVAe2jDJSAb0JhwCVtn79r0S1 bz6DjFqy8svEXh1BJFBG3ObXYobvsEtKtmdykZgUf/iW9nDwazYblGuuyRR98M975wr6 7/Kxrybrdi/2Sdm4niQgQ6i2rQeZtGdToFXlJPQU6zmJ6ct4PtzuCsAY+SG3lC7eMTLJ sk7y7w9xWGfK8n8/hWW5Yb0n7MMbT1+MuCMKfxnFf3p99PVD11cU/hqFRMXnUA+//U9j vU9A== MIME-Version: 1.0 Received: by 10.224.42.16 with SMTP id q16mr5292515qae.70.1336244812786; Sat, 05 May 2012 12:06:52 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Sat, 5 May 2012 12:06:52 -0700 (PDT) In-Reply-To: References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA50947.8030703@citrix.com> Date: Sat, 5 May 2012 12:06:52 -0700 Message-ID: From: AP To: Andrew Cooper Content-Type: multipart/mixed; boundary=20cf3074d4fe662a8904bf4ebda6 Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3074d4fe662a8904bf4ebda6 Content-Type: multipart/alternative; boundary=20cf3074d4fe662a8504bf4ebda4 --20cf3074d4fe662a8504bf4ebda4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 11:41 AM, AP wrote: > > On Sat, May 5, 2012 at 4:04 AM, Andrew Cooper wrote: > > > > > > > Thanks, that fixed it. Here is what I see now: > > > > > > (XEN) *** IRQ BUG found *** > > > (XEN) CPU0 -Testing vector 236 from bitmap > > > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > > > (XEN) Guest interrupt information: > > > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge > > > status=00000000 mapped, unbound > > > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge > > > status=00000030 in-flight=0 domain-list=0: 1(-S--), > > > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC > > > status=00000000 mapped, unbound > > > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge > > > status=00000030 in-flight=0 domain-list=0: 8(-S--), > > > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level > > > status=00000030 in-flight=0 domain-list=0: 9(-S--), > > > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge > > > status=00000002 mapped, unbound > > > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > > > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > > > > > Let me know if you need any more info. > > > Thanks, > > > AP > > > > > > > There should be quite a lot more irq information dumped than just that. > > Was there any more on the console or had it given up by that point? It > > There was nothing more on the console. The system was hung. > > > might be worth trying to set synchronous console to get all of that > > debug information? > > I was running with sync_console and console_to_ring options. > > > > How easy is this error to reproduce for you? I never managed to > > reproduce it reliably enough to be able to debug? > > I cannot reproduce it easily either. > > > > If you could provide your Xen boot console log, that would be very useful > > I will send full logs the next time I see the problem. I have attached the full logs. I had a CentOS 5.6 and a Windows 7 HVM domain running. Thanks, AP --20cf3074d4fe662a8504bf4ebda4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 5, 2012 at 11:41 AM, AP <apxeng@gmail.com> wrote:
>
> On Sat, May 5, 2012 at 4:0= 4 AM, Andrew Cooper <andrew= .cooper3@citrix.com> wrote:
> >
> >
> > > Thanks, that fixed it. Here is wha= t I see now:
> > >
> > > (XEN) *** IRQ BUG found **= *
> > > (XEN) CPU0 -Testing vector 236 from bitmap
> >= > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,19= 2,200,211
> > > (XEN) Guest interrupt information:
> > > (XEN) = =A0 =A0IRQ: =A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge
> > > = status=3D00000000 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 1= affinity:01 vec:d3 type=3DIO-APIC-edge
> > > status=3D00000030 in-flight=3D0 domain-list=3D0: =A01(-S--),=
> > > (XEN) =A0 =A0IRQ: =A0 2 affinity:ff vec:e2 type=3DXT-PIC=
> > > status=3D00000000 mapped, unbound
> > > (XEN= ) =A0 =A0IRQ: =A0 3 affinity:01 vec:40 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 4 affinity:01 vec:48 type=3DIO-APIC-edge
> > > = status=3D00000002 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 5= affinity:01 vec:50 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 6 affinity:01 vec:58 type=3DIO-APIC-edge
> > > = status=3D00000002 mapped, unbound
> > > (XEN) =A0 =A0IRQ: =A0 7= affinity:01 vec:60 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > (XEN) = =A0 =A0IRQ: =A0 8 affinity:08 vec:29 type=3DIO-APIC-edge
> > > = status=3D00000030 in-flight=3D0 domain-list=3D0: =A08(-S--),
> > &= gt; (XEN) =A0 =A0IRQ: =A0 9 affinity:02 vec:25 type=3DIO-APIC-level
> > > status=3D00000030 in-flight=3D0 domain-list=3D0: =A09(-S--),=
> > > (XEN) =A0 =A0IRQ: =A010 affinity:01 vec:78 type=3DIO-API= C-edge
> > > status=3D00000002 mapped, unbound
> > >= ; (XEN) =A0 =A0IRQ: =A011 affinity:01 vec:88 type=3DIO-APIC-edge
> > > status=3D00000002 mapped, unbound
> > > [ 5129.7= 37147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer
> > = > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ?=
> > >
> > > Let me know if you need any more info.
= > > > Thanks,
> > > AP
> > >
> ><= br>> > There should be quite a lot more irq information dumped than j= ust that.
> > Was there any more on the console or had it given up by that poin= t? It
>
> There was nothing more on the console. The system was= hung.
>
> > might be worth trying to set synchronous consol= e to get all of that
> > debug information?
>
> I was running with sync_consol= e and console_to_ring options.
>
>
> > How easy is thi= s error to reproduce for you? I never managed to
> > reproduce it = reliably enough to be able to debug?
>
> I cannot reproduce it easily either.=A0
>
>
>= ; > If you could provide your Xen boot console log, that would be very u= seful
>
> I will send full logs the next time I see the problem= .

I have attached the full logs. I had a CentOS 5.6 and a Windows 7 HVM d= omain running.

Thanks,
AP

--20cf3074d4fe662a8504bf4ebda4-- --20cf3074d4fe662a8904bf4ebda6 Content-Type: application/octet-stream; name="irq_bug.log" Content-Disposition: attachment; filename="irq_bug.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1v1kgcr0 IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICAgICAgICAgICAgICAgICAgIF8gICAg ICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAg IF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwgJ18gXCAgfCB8 fCB8XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKICAv ICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy98X198IHxffCB8IHwgfE4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAj MCA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBs YXBpY19pZFsweDAxXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzEgNjoxMCBBUElDIHZlcnNp b24gMjEKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5h YmxlZCkKKFhFTikgUHJvY2Vzc29yICMyIDY6MTAgQVBJQyB2ZXJzaW9uIDIxCihYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpCihYRU4pIFByb2Nl c3NvciAjMyA2OjEwIEFQSUMgdmVyc2lvbiAyMQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw eDA1XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwNl0gbGFwaWNfaWRbMHgwMF0gZGlzYWJsZWQpCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDddIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA4XSBsYXBpY19pZFsweDAwXSBkaXNhYmxlZCkKKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDBdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCihYRU4pIEFDUEk6IExBUElDX05NSSAo YWNwaV9pZFsweDAxXSBoaWdoIGVkZ2UgbGludFsweDFdKQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlk WzB4MDJdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCihYRU4pIElPQVBJQ1swXTog YXBpY19pZCAyLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4p IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwp CihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhp Z2ggbGV2ZWwpCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4KKFhFTikgQUNQSTog SVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUu CihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAxIEkvTyBBUElDcwooWEVO KSBBQ1BJOiBIUEVUIGlkOiAweDgwODZhMzAxIGJhc2U6IDB4ZmVkMDAwMDAKKFhFTikgVGFibGUg aXMgbm90IGZvdW5kIQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRp b24gaW5mb3JtYXRpb24KKFhFTikgU01QOiBBbGxvd2luZyA4IENQVXMgKDQgaG90cGx1ZyBDUFVz KQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgKKFhFTikgU3dpdGNoZWQg dG8gQVBJQyBkcml2ZXIgeDJhcGljX2NsdXN0ZXIuCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMjY5MS4zNjEgTUh6IHBy b2Nlc3Nvci4KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgeHN0YXRlX2luaXQ6 IHVzaW5nIGNudHh0X3NpemU6IDB4MzQwIGFuZCBzdGF0ZXM6IDB4NwooWEVOKSBtY2VfaW50ZWwu YzoxMjM5OiBNQ0EgQ2FwYWJpbGl0eTogQkNBU1QgMSBTRVIgMCBDTUNJIDEgZmlyc3RiYW5rIDAg ZXh0ZW5kZWQgTUNFIE1TUiAwCihYRU4pIEludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVu YWJsZWQKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBmODAwMDAwMCBzZWdt ZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBmODAwMDAwMCBy ZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1 cyAwMC0zZgooWEVOKSBJbnRlbCBWVC1kIFNub29wIENvbnRyb2wgbm90IGVuYWJsZWQuCihYRU4p IEludGVsIFZULWQgRG9tMCBETUEgUGFzc3Rocm91Z2ggbm90IGVuYWJsZWQuCihYRU4pIEludGVs IFZULWQgUXVldWVkIEludmFsaWRhdGlvbiBlbmFibGVkLgooWEVOKSBJbnRlbCBWVC1kIEludGVy cnVwdCBSZW1hcHBpbmcgZW5hYmxlZC4KKFhFTikgSW50ZWwgVlQtZCBTaGFyZWQgRVBUIHRhYmxl cyBub3QgZW5hYmxlZC4KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKKFhFTikgIC0g RG9tMCBtb2RlOiBSZWxheGVkCihYRU4pIEVuYWJsZWQgZGlyZWN0ZWQgRU9JIHdpdGggaW9hcGlj X2Fja19vbGQgb24hCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNpbmcg b2xkIEFDSyBtZXRob2QKKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIg YXBpYzI9LTEgcGluMj0tMQooWEVOKSBUU0MgZGVhZGxpbmUgdGltZXIgZW5hYmxlZAooWEVOKSBQ bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVAooWEVOKSBBbGxvY2F0ZWQgY29uc29sZSBy aW5nIG9mIDMyIEtpQi4KKFhFTikgVk1YOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihY RU4pICAtIEFQSUMgTU1JTyBhY2Nlc3MgdmlydHVhbGlzYXRpb24KKFhFTikgIC0gQVBJQyBUUFIg c2hhZG93CihYRU4pICAtIEV4dGVuZGVkIFBhZ2UgVGFibGVzIChFUFQpCihYRU4pICAtIFZpcnR1 YWwtUHJvY2Vzc29yIElkZW50aWZpZXJzIChWUElEKQooWEVOKSAgLSBWaXJ0dWFsIE5NSQooWEVO KSAgLSBNU1IgZGlyZWN0LWFjY2VzcyBiaXRtYXAKKFhFTikgIC0gVW5yZXN0cmljdGVkIEd1ZXN0 CihYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KKFhFTikgSFZNOiBWTVggZW5hYmxlZAooWEVOKSBI Vk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBkZXRlY3RlZAooWEVOKSBIVk06IEhB UCBwYWdlIHNpemVzOiA0a0IsIDJNQiBbZGlzYWJsZWRdCihYRU4pIEJyb3VnaHQgdXAgNCBDUFVz CihYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCihYRU4pIG1jaGVja19wb2xsOiBNYWNoaW5lIGNo ZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioq CihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weGFh NTAwMAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjMDAwMDAgbWVtc3o9 MHhiYWM4MAooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFjYmIwMDAgbWVt c3o9MHhkNjAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2JjMDAwIG1l bXN6PTB4MTM3MDAKKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxY2QwMDAw IG1lbXN6PTB4MzczMDAwCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAw IC0+IDB4MjA0MzAwMAooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4 IgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42IgooWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCihYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODFjZDAyMDAKKFhFTikgZWxmX3hlbl9wYXJz ZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMAooWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJf YWJvdmVfNGdiIgooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKKFhF TikgZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQooWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog UEFERFJfT0ZGU0VUID0gMHgwCihYRU4pIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNz ZXM6CihYRU4pICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCihYRU4p ICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCihYRU4pICAgICB2aXJ0X29mZnNldCAgICAgID0g MHhmZmZmZmZmZjgwMDAwMDAwCihYRU4pICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZm ZjgxMDAwMDAwCihYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyMDQzMDAw CihYRU4pICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxY2QwMjAwCihYRU4pICAg ICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmCihYRU4pICBYZW4gIGtlcm5l bDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUs IGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MjA0MzAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkg QVJSQU5HRU1FTlQ6CihYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjEwMDAwMDAwLT4wMDAw MDAwMjE0MDAwMDAwICgxOTc5NDY1IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKKFhFTikgIEluaXQu IHJhbWRpc2s6IDAwMDAwMDAyMWMxNTQwMDAtPjAwMDAwMDAyMWU1ZmZjMDAKKFhFTikgVklSVFVB TCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAw MDAwLT5mZmZmZmZmZjgyMDQzMDAwCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyMDQz MDAwLT5mZmZmZmZmZjg0NGVlYzAwCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjg0NGVm MDAwLT5mZmZmZmZmZjg1NDNiN2E4CihYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjg1NDNj MDAwLT5mZmZmZmZmZjg1NDNjNGI0CihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg1NDNk MDAwLT5mZmZmZmZmZjg1NDZjMDAwCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjg1NDZj MDAwLT5mZmZmZmZmZjg1NDZkMDAwCihYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAw MDAwLT5mZmZmZmZmZjg1ODAwMDAwCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2Qw MjAwCihYRU4pIERvbTAgaGFzIG1heGltdW0gNCBWQ1BVcwooWEVOKSBlbGZfbG9hZF9iaW5hcnk6 IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxYWE1MDAwCihYRU4p IGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAwMCAtPiAweGZmZmZm ZmZmODFjYmFjODAKKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgx Y2JiMDAwIC0+IDB4ZmZmZmZmZmY4MWNiYmQ2MAooWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIg MyBhdCAweGZmZmZmZmZmODFjYmMwMDAgLT4gMHhmZmZmZmZmZjgxY2NmNzAwCihYRU4pIGVsZl9s b2FkX2JpbmFyeTogcGhkciA0IGF0IDB4ZmZmZmZmZmY4MWNkMDAwMCAtPiAweGZmZmZmZmZmODFk YmEwMDAKKFhFTikgU2NydWJiaW5nIEZyZWUgUkFNOiAuZG9uZS4KKFhFTikgSW5pdGlhbCBsb3cg bWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFN0ZC4gTG9n bGV2ZWw6IEFsbAooWEVOKSBHdWVzdCBMb2dsZXZlbDogQWxsCihYRU4pICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKFhFTikgKioqKioqKiBXQVJOSU5HOiBD T05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwooWEVOKSAqKioqKioqIFRoaXMgb3B0aW9uIGlz IGludGVuZGVkIHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nCihYRU4pICoqKioq KiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNocm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJp YWwgbGluZS4KKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNB TlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKKFhFTikgKioqKioqKiB0aW1la2VlcGluZy4gSXQgaXMg Tk9UIHJlY29tbWVuZGVkIGZvciBwcm9kdWN0aW9uIHVzZSEKKFhFTikgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgooWEVOKSAzLi4uIDIuLi4gMS4uLiAKKFhF TikgWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuCihYRU4pICoqKiBTZXJpYWwgaW5w dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8g WGVuKQooWEVOKSBGcmVlZCAyMzZrQiBpbml0IG1lbW9yeS4KbWFwcGluZyBrZXJuZWwgaW50byBw aHlzaWNhbCBtZW1vcnkKWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwphYm91dCB0byBnZXQg c3RhcnRlZC4uLgpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVz ZXQKWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1ClsgICAgMC4w MDAwMDBdIExpbnV4IHZlcnNpb24gMy4wLjAtMTctZ2VuZXJpYyAoYnVpbGRkQHllbGxvdykgKGdj YyB2ZXJzaW9uIDQuNi4xIChVYnVudHUvTGluYXJvIDQuNi4xLTl1YnVudHUzKSApICMzMC1VYnVu dHUgU01QIFRodSBNYXIgOCAyMDo0NTozOSBVVEMgMjAxMiAoVWJ1bnR1IDMuMC4wLTE3LjMwLWdl bmVyaWMgMy4wLjIyKQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJv b3Q9VVVJRD1jNzgxNWFmZS1hZTcyLTRjZmEtYjhiMC05NGIzMDM1YzBiYjcgcm8gZGVidWcgY29u c29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgpbICAgIDAuMDAwMDAwXSBLRVJORUwgc3VwcG9ydGVk IGNwdXM6ClsgICAgMC4wMDAwMDBdICAgSW50ZWwgR2VudWluZUludGVsClsgICAgMC4wMDAwMDBd ICAgQU1EIEF1dGhlbnRpY0FNRApbICAgIDAuMDAwMDAwXSAgIENlbnRhdXIgQ2VudGF1ckhhdWxz ClsgICAgMC4wMDAwMDBdIERpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMKWyAgICAwLjAw MDAwMF0geGVuX3JlbGVhc2VfY2h1bms6IGxvb2tpbmcgYXQgYXJlYSBwZm4gZGZhMDAtZjgwMDA6 IDk5ODQwIHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29r aW5nIGF0IGFyZWEgcGZuIGZjMDAwLWZlYzAwOiAxMTI2NCBwYWdlcyBmcmVlZApbICAgIDAuMDAw MDAwXSB4ZW5fcmVsZWFzZV9jaHVuazogbG9va2luZyBhdCBhcmVhIHBmbiBmZWMwMS1mZWQwODog MjYzIHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29raW5n IGF0IGFyZWEgcGZuIGZlZDA5LWZlZDEwOiA3IHBhZ2VzIGZyZWVkClsgICAgMC4wMDAwMDBdIHhl bl9yZWxlYXNlX2NodW5rOiBsb29raW5nIGF0IGFyZWEgcGZuIGZlZDFhLWZlZDFjOiAyIHBhZ2Vz IGZyZWVkClsgICAgMC4wMDAwMDBdIHhlbl9yZWxlYXNlX2NodW5rOiBsb29raW5nIGF0IGFyZWEg cGZuIGZlZDIwLWZlZTAwOiAyMjQgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAwMF0geGVuX3JlbGVh c2VfY2h1bms6IGxvb2tpbmcgYXQgYXJlYSBwZm4gZmVlMDEtZmZkMjA6IDM4NzEgcGFnZXMgZnJl ZWQKWyAgICAwLjAwMDAwMF0gcmVsZWFzZWQgMTE1NDcxIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkK WyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gOWUtPjEwMApbICAgIDAuMDAwMDAwXSAxLTEg bWFwcGluZyBvbiAyMDAwMC0+MjAyMDAKWyAgICAwLjAwMDAwMF0gMS0xIG1hcHBpbmcgb24gNDAw MDAtPjQwMjAwClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIGRhOTlmLT5kYWZmZgpbICAg IDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiBkYjAwMC0+MTAwMDAwClsgICAgMC4wMDAwMDBdIDEt MSBtYXBwaW5nIG9uIDIxZTYwMC0+MjFlODAwClsgICAgMC4wMDAwMDBdIFNldCAxNTQ4MTggcGFn ZShzKSB0byAxLTEgbWFwcGluZy4KWyAgICAwLjAwMDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNh bCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw MDAwMDA5ZDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDlkODAw IC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDIwMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBY ZW46IDAwMDAwMDAwMjAwMDAwMDAgLSAwMDAwMDAwMDIwMjAwMDAwIChyZXNlcnZlZCkKWyAgICAw LjAwMDAwMF0gIFhlbjogMDAwMDAwMDAyMDIwMDAwMCAtIDAwMDAwMDAwNDAwMDAwMDAgKHVzYWJs ZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDA0MDAwMDAwMCAtIDAwMDAwMDAwNDAyMDAw MDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDQwMjAwMDAwIC0gMDAw MDAwMDBkYTk5ZjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGRhOTlm MDAwIC0gMDAwMDAwMDBkYWU5ZjAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAw MDAwMDAwZGFlOWYwMDAgLSAwMDAwMDAwMGRhZjlmMDAwIChBQ1BJIE5WUykKWyAgICAwLjAwMDAw MF0gIFhlbjogMDAwMDAwMDBkYWY5ZjAwMCAtIDAwMDAwMDAwZGFmZmYwMDAgKEFDUEkgZGF0YSkK WyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBkYWZmZjAwMCAtIDAwMDAwMDAwZGIwMDAwMDAg KHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBkYjAwMDAwMCAtIDAwMDAwMDAw ZGZhMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGY4MDAwMDAw IC0gMDAwMDAwMDBmYzAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw MDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0g IFhlbjogMDAwMDAwMDBmZWQwODAwMCAtIDAwMDAwMDAwZmVkMDkwMDAgKHJlc2VydmVkKQpbICAg IDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMGZlZDEwMDAwIC0gMDAwMDAwMDBmZWQxYTAwMCAocmVz ZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZl ZDIwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAt IDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAw MGZmZDIwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBY ZW46IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMWU5OGY1MDAwICh1c2FibGUpClsgICAgMC4w MDAwMDBdICBYZW46IDAwMDAwMDAyMWU2MDAwMDAgLSAwMDAwMDAwMjFlODAwMDAwIChyZXNlcnZl ZCkKWyAgICAwLjAwMDAwMF0gIFhlbjogMDAwMDAwMDIxZTgwMDAwMCAtIDAwMDAwMDAyNmY4MWEw MDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFibGVk ClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpb ICAgIDAuMDAwMDAwXSBETUkgMi42IHByZXNlbnQuClsgICAgMC4wMDAwMDBdIERNSTogTEVOT1ZP IDQyODZDVE8vNDI4NkNUTywgQklPUyA4REVUNThXVyAoMS4yOCApIDAyLzE0LzIwMTIKWyAgICAw LjAwMDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw MDEwMDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdIGU4MjAgcmVtb3Zl IHJhbmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAodXNhYmxlKQpbICAg IDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0g MHgyNmY4MWEgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKWyAgICAwLjAwMDAwMF0geDJhcGlj IGVuYWJsZWQgYnkgQklPUywgc3dpdGNoaW5nIHRvIHgyYXBpYyBvcHMKWyAgICAwLjAwMDAwMF0g bGFzdF9wZm4gPSAweGRiMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwClsgICAgMC4wMDAw MDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZCA6IDAgLSAwNDRlZjAwMApbICAgIDAuMDAwMDAwXSBC YXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDIw NDgwClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IDAwMDAwMDAwMDAwMDAwMDAt MDAwMDAwMDBkYjAwMDAwMApbICAgIDAuMDAwMDAwXSAgMDAwMDAwMDAwMCAtIDAwZGIwMDAwMDAg cGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRv IGRiMDAwMDAwIEAgOTIzMDAwLTEwMDAwMDAKWyAgICAwLjAwMDAwMF0geGVuOiBzZXR0aW5nIFJX IHRoZSByYW5nZSBmY2UwMDAgLSAxMDAwMDAwClsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21h cHBpbmc6IDAwMDAwMDAxMDAwMDAwMDAtMDAwMDAwMDI2ZjgxYTAwMApbICAgIDAuMDAwMDAwXSAg MDEwMDAwMDAwMCAtIDAyNmY4MWEwMDAgcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGly ZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDI2ZjgxYTAwMCBAIGQ5NjE3MDAwLWRhOTlmMDAwClsg ICAgMC4wMDAwMDBdIHhlbjogc2V0dGluZyBSVyB0aGUgcmFuZ2UgZGExOWEwMDAgLSBkYTk5ZjAw MApbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiAwMjA0MzAwMCAtIDA0NGVmMDAwClsgICAgMC4wMDAw MDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmMDBlMCAwMDAyNCAodjAyIExFTk9WTykKWyAgICAw LjAwMDAwMF0gQUNQSTogWFNEVCAwMDAwMDAwMGRhZmZlMTIwIDAwMEFDICh2MDEgTEVOT1ZPIFRQ LThEICAgIDAwMDAxMjgwIFBURUMgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1Ag MDAwMDAwMDBkYWZlNzAwMCAwMDBGNCAodjA0IExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQVEwg IDAwMDAwMDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwZGFmZWEwMDAgMEY2 RDggKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAw MDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGRhZjJkMDAwIDAwMDQwClsgICAgMC4wMDAwMDBdIEFD UEk6IFNMSUMgMDAwMDAwMDBkYWZmZDAwMCAwMDE3NiAodjAxIExFTk9WTyBUUC04RCAgICAwMDAw MTI4MCBQVEVDIDAwMDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwZGFm ZmMwMDAgMDAyNDkgKHYwMSBMRU5PVk8gVFAtU1NEVDIgMDAwMDAyMDAgSU5UTCAyMDA2MTEwOSkK WyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGRhZmZiMDAwIDAwMDMzICh2MDEgTEVO T1ZPIFRQLVNTRFQxIDAwMDAwMTAwIElOVEwgMjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6 IFNTRFQgMDAwMDAwMDBkYWZmYTAwMCAwMDdEMSAodjAxIExFTk9WTyBTYXRhQWhjaSAwMDAwMTAw MCBJTlRMIDIwMDYxMTA5KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIDAwMDAwMDAwZGFmZTYw MDAgMDAwMzggKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAg ICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGRhZmU1MDAwIDAwMDk4ICh2MDEgTEVOT1ZP IFRQLThEICAgIDAwMDAxMjgwIFBUTCAgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IE1D RkcgMDAwMDAwMDBkYWZlNDAwMCAwMDAzQyAodjAxIExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQ VEwgIDAwMDAwMDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBFQ0RUIDAwMDAwMDAwZGFmZTMwMDAg MDAwNTIgKHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAgICAw LjAwMDAwMF0gQUNQSTogQVNGISAwMDAwMDAwMGRhZmU5MDAwIDAwMEE1ICh2MzIgTEVOT1ZPIFRQ LThEICAgIDAwMDAxMjgwIFBUTCAgMDAwMDAwMDIpClsgICAgMC4wMDAwMDBdIEFDUEk6IFRDUEEg MDAwMDAwMDBkYWZlMjAwMCAwMDAzMiAodjAyICAgIFBUTCAgIExFTk9WTyAwNjA0MDAwMCBMTlZP IDAwMDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwZGFmZTEwMDAgMDBB NjkgKHYwMSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICAwLjAw MDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGRhZmUwMDAwIDAwOTk2ICh2MDEgIFBtUmVmICAgIENw dVBtIDAwMDAzMDAwIElOVEwgMjAwNjExMDkpClsgICAgMC4wMDAwMDBdIEFDUEk6IFhNQVIgMDAw MDAwMDBkYWZkZjAwMCAwMDBFOCAodjAxIElOVEVMICAgICAgU05CICAwMDAwMDAwMSBJTlRMIDAw MDAwMDAxKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBVRUZJIDAwMDAwMDAwZGFmZGUwMDAgMDAwM0Ug KHYwMSBMRU5PVk8gVFAtOEQgICAgMDAwMDEyODAgUFRMICAwMDAwMDAwMikKWyAgICAwLjAwMDAw MF0gQUNQSTogVUVGSSAwMDAwMDAwMGRhZmRkMDAwIDAwMDQyICh2MDEgUFRMICAgICAgQ09NQlVG IDAwMDAwMDAxIFBUTCAgMDAwMDAwMDEpClsgICAgMC4wMDAwMDBdIEFDUEk6IFVFRkkgMDAwMDAw MDBkYWZkYzAwMCAwMDI5MiAodjAxIExFTk9WTyBUUC04RCAgICAwMDAwMTI4MCBQVEwgIDAwMDAw MDAyKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApb ICAgIDAuMDAwMDAwXSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBjbHVzdGVyIHgyYXBpYy4KWyAg ICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZh a2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMjZmODFhMDAwClsgICAgMC4w MDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDI2Zjgx YTAwMApbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDFlOThmMDAwMCAtIDAwMDAw MDAxZTk4ZjRmZmZdClsgICAgMC4wMDAwMDBdIFpvbmUgUEZOIHJhbmdlczoKWyAgICAwLjAwMDAw MF0gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKWyAgICAwLjAwMDAwMF0gICBE TUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAwMDAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwg ICAweDAwMTAwMDAwIC0+IDB4MDAyNmY4MWEKWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0 YXJ0IFBGTiBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAwMDBdIGVhcmx5X25vZGVfbWFwWzddIGFj dGl2ZSBQRk4gcmFuZ2VzClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAw MDAwOWQKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwMDAxMDAgLT4gMHgwMDAyMDAwMApbICAg IDAuMDAwMDAwXSAgICAgMDogMHgwMDAyMDIwMCAtPiAweDAwMDQwMDAwClsgICAgMC4wMDAwMDBd ICAgICAwOiAweDAwMDQwMjAwIC0+IDB4MDAwZGE5OWYKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4 MDAwZGFmZmYgLT4gMHgwMDBkYjAwMApbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDEwMDAwMCAt PiAweDAwMWU5OGY1ClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMjFlODAwIC0+IDB4MDAyNmY4 MWEKWyAgICAwLjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDIxODI3MTYKWyAgICAwLjAw MDAwMF0gICBETUEgem9uZTogNTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBd ICAgRE1BIHpvbmU6IDE3MTIgcGFnZXMgcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gICBETUEgem9u ZTogMjIxMyBwYWdlcywgTElGTyBiYXRjaDowClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog MTQyODAgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTog ODc1OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgTm9ybWFsIHpvbmU6 IDIwNTgxIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcApbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCB6b25l OiAxMjY3ODgyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRp bWVyIElPIFBvcnQ6IDB4NDA4ClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz cyAweGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxh cGljX2lkWzB4MDBdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpClsgICAgMC4wMDAwMDBdIEFD UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpClsgICAgMC4w MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVk KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDAw XSBkaXNhYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFw aWNfaWRbMHgwMF0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lk WzB4MDhdIGxhcGljX2lkWzB4MDBdIGRpc2FibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwMF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0g QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pClsgICAg MC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwMl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf YmFzZVswXSkKWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDIsIHZlcnNpb24gMjU1 LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1NQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRf U1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQpbICAgIDAuMDAw MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBoaWdo IGxldmVsKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuClsgICAg MC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAwMDAwMF0gQUNQ STogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURU KSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gQUNQSTog SFBFVCBpZDogMHg4MDg2YTMwMSBiYXNlOiAweGZlZDAwMDAwClsgICAgMC4wMDAwMDBdIFNNUDog QWxsb3dpbmcgOCBDUFVzLCA0IGhvdHBsdWcgQ1BVcwpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dz aTogMjcyClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwMDAwOWQwMDAgLSAwMDAwMDAwMDAwMDllMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMTAwMDAwClsg ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMjAwMDAw MDAgLSAwMDAwMDAwMDIwMjAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2 ZSBtZW1vcnk6IDAwMDAwMDAwNDAwMDAwMDAgLSAwMDAwMDAwMDQwMjAwMDAwClsgICAgMC4wMDAw MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGE5OWYwMDAgLSAwMDAw MDAwMGRhZTlmMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6 IDAwMDAwMDAwZGFlOWYwMDAgLSAwMDAwMDAwMGRhZjlmMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGFmOWYwMDAgLSAwMDAwMDAwMGRhZmZm MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw ZGIwMDAwMDAgLSAwMDAwMDAwMGRmYTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGZhMDAwMDAgLSAwMDAwMDAwMGY4MDAwMDAwClsgICAg MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZjgwMDAwMDAg LSAwMDAwMDAwMGZjMDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt ZW1vcnk6IDAwMDAwMDAwZmMwMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBd IFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAw MGZlYzAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAw MDAwMDAwZmVjMDEwMDAgLSAwMDAwMDAwMGZlZDA4MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdp c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMDgwMDAgLSAwMDAwMDAwMGZlZDA5MDAw ClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVk MDkwMDAgLSAwMDAwMDAwMGZlZDEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5v c2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMTAwMDAgLSAwMDAwMDAwMGZlZDFhMDAwClsgICAgMC4w MDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMWEwMDAgLSAw MDAwMDAwMGZlZDFjMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v cnk6IDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDIwMDAwClsgICAgMC4wMDAwMDBdIFBN OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVkMjAwMDAgLSAwMDAwMDAwMGZl ZTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDEwMDAgLSAwMDAwMDAwMGZmZDIwMDAwClsg ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmZkMjAw MDAgLSAwMDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2 ZSBtZW1vcnk6IDAwMDAwMDAxZTk4ZjUwMDAgLSAwMDAwMDAwMjFlNjAwMDAwClsgICAgMC4wMDAw MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAyMWU2MDAwMDAgLSAwMDAw MDAwMjFlODAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFy dGluZyBhdCBkZmEwMDAwMCAoZ2FwOiBkZmEwMDAwMDoxODYwMDAwMCkKWyAgICAwLjAwMDAwMF0g Qm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbgpbICAgIDAuMDAwMDAwXSBYZW4g dmVyc2lvbjogNC4yLXVuc3RhYmxlIChwcmVzZXJ2ZS1BRCkKWyAgICAwLjAwMDAwMF0gc2V0dXBf cGVyY3B1OiBOUl9DUFVTOjI1NiBucl9jcHVtYXNrX2JpdHM6MjU2IG5yX2NwdV9pZHM6OCBucl9u b2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1iZWRkZWQgMjcgcGFnZXMvY3B1IEBm ZmZmODgwMWU5N2UwMDAwIHM3OTYxNiByODE5MiBkMjI3ODQgdTExMDU5MgpbICAgIDAuMDAwMDAw XSBwY3B1LWFsbG9jOiBzNzk2MTYgcjgxOTIgZDIyNzg0IHUxMTA1OTIgYWxsb2M9MjcqNDA5Ngpb ICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCBbMF0gMSBbMF0gMiBbMF0gMyBbMF0gNCBb MF0gNSBbMF0gNiBbMF0gNyAKWyAgICA2LjY1MzM1Nl0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9u ZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjE0NjA4NwpbICAg IDYuNjYxNzUyXSBQb2xpY3kgem9uZTogTm9ybWFsClsgICAgNi42NjUwMTFdIEtlcm5lbCBjb21t YW5kIGxpbmU6IHBsYWNlaG9sZGVyIHJvb3Q9VVVJRD1jNzgxNWFmZS1hZTcyLTRjZmEtYjhiMC05 NGIzMDM1YzBiYjcgcm8gZGVidWcgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgpbICAgIDYu Njc3MTgzXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMywgMzI3NjggYnl0 ZXMpCihYRU4pIGRvbWFpbi5jOjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAw NDI2NjAgLT4gMDAwMDI2NjAKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdl IENSNCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0 ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwClsgICAgNi43MDMx MjhdIHhzYXZlL3hyc3RvcjogZW5hYmxlZCB4c3RhdGVfYnYgMHg3LCBjbnR4dCBzaXplIDB4MzQw ClsgICAgNi43NTg1MTddIFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBUTEIgYmV0d2VlbiBmZmZm ODgwMWRjNjAwMDAwIC0gZmZmZjg4MDFlMDYwMDAwMApbICAgIDYuNzY2NTA0XSBzb2Z0d2FyZSBJ TyBUTEIgYXQgcGh5cyAweDFkYzYwMDAwMCAtIDB4MWUwNjAwMDAwClsgICAgNi43OTYwNzZdIE1l bW9yeTogNzEyNTA2MGsvMTAyMTU1MjhrIGF2YWlsYWJsZSAoNjE0MGsga2VybmVsIGNvZGUsIDE0 ODQ2NjRrIGFic2VudCwgMTYwNTgwNGsgcmVzZXJ2ZWQsIDY4OTRrIGRhdGEsIDk4OGsgaW5pdCkK WyAgICA2LjgwODAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywg TWluT2JqZWN0cz0wLCBDUFVzPTgsIE5vZGVzPTEKWyAgICA2LjgxNTkxN10gSGllcmFyY2hpY2Fs IFJDVSBpbXBsZW1lbnRhdGlvbi4KWyAgICA2LjgyMDMxNV0gCVJDVSBkeW50aWNrLWlkbGUgZ3Jh Y2UtcGVyaW9kIGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLgpbICAgIDYuODI2ODMyXSBOUl9JUlFT OjE2NjQwIG5yX2lycXM6MjA0OCAxNgpbICAgIDYuODMxMDQ3XSB4ZW46IHNjaSBvdmVycmlkZTog Z2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0wClsgICAgNi44MzcyMjBdIHhlbjogcmVn aXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDAKWyAgICA2Ljg0MjkyMl0geGVu OiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICA2Ljg0NzM2N10geGVuOiBhY3BpIHNj aSA5ClsgICAgNi44NTAyMjldIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpClsgICAg Ni44NTQ2NTddIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIpClsgICAgNi44NTkwNzhd IHhlbjogLS0+IHBpcnE9MyAtPiBpcnE9MyAoZ3NpPTMpClsgICAgNi44NjM1MDVdIHhlbjogLS0+ IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpClsgICAgNi44Njc5MzFdIHhlbjogLS0+IHBpcnE9NSAt PiBpcnE9NSAoZ3NpPTUpClsgICAgNi44NzIzNjZdIHhlbjogLS0+IHBpcnE9NiAtPiBpcnE9NiAo Z3NpPTYpClsgICAgNi44NzY3OThdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpClsg ICAgNi44ODEyMzBdIHhlbjogLS0+IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpClsgICAgNi44ODU2 NTJdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOSBmb3IgZ3NpIDkKWyAgICA2Ljg5 MTA2OV0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkKWyAgICA2Ljg5NTQ5N10geGVu OiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkKWyAgICA2LjkwMDE5Nl0geGVuOiAtLT4g cGlycT0xMSAtPiBpcnE9MTEgKGdzaT0xMSkKWyAgICA2LjkwNDkwMl0geGVuOiAtLT4gcGlycT0x MiAtPiBpcnE9MTIgKGdzaT0xMikKWyAgICA2LjkwOTYwM10geGVuOiAtLT4gcGlycT0xMyAtPiBp cnE9MTMgKGdzaT0xMykKWyAgICA2LjkxNDMwOF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQg KGdzaT0xNCkKWyAgICA2LjkxODk5OV0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0x NSkKWyAgICA2LjkyNDYzNl0gQ29uc29sZTogY29sb3VyIFZHQSsgODB4MjUKWyAgICA2LjkyODQ0 OV0gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICA2Ljky ODQ0OV0gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKWyAgICA2 Ljk0Nzk5NF0gYWxsb2NhdGVkIDcyMzUxNzQ0IGJ5dGVzIG9mIHBhZ2VfY2dyb3VwClsgICAgNi45 NTMwNjJdIHBsZWFzZSB0cnkgJ2Nncm91cF9kaXNhYmxlPW1lbW9yeScgb3B0aW9uIGlmIHlvdSBk b24ndCB3YW50IG1lbW9yeSBjZ3JvdXBzClsgICAgNi45NjE0MjhdIFhlbjogdXNpbmcgdmNwdW9w IHRpbWVyIGludGVyZmFjZQpbICAgIDYuOTY2MDA2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig Q1BVIDAKWyAgICA2Ljk3MDM3MV0gRGV0ZWN0ZWQgMjY5MS4zNjAgTUh6IHByb2Nlc3Nvci4KWyAg ICA2Ljk3NDg1N10gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNTM4Mi43MiBCb2dvTUlQUyAobHBqPTEwNzY1 NDQwKQpbICAgIDYuOTg2MDQ5XSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDEK WyAgICA2Ljk5MDk3MF0gU2VjdXJpdHkgRnJhbWV3b3JrIGluaXRpYWxpemVkClsgICAgNi45OTUy NzRdIEFwcEFybW9yOiBBcHBBcm1vciBpbml0aWFsaXplZApbICAgIDYuOTk5NTk2XSBZYW1hOiBi ZWNvbWluZyBtaW5kZnVsLgpbICAgIDcuMDA3ODI1XSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBl bnRyaWVzOiAyMDk3MTUyIChvcmRlcjogMTIsIDE2Nzc3MjE2IGJ5dGVzKQpbICAgIDcuMDIwMjkz XSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwNDg1NzYgKG9yZGVyOiAxMSwgODM4 ODYwOCBieXRlcykKWyAgICA3LjAyOTA4N10gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVz OiAyNTYKWyAgICA3LjAzMzk3Ml0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdApb ICAgIDcuMDM4NTg4XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkKWyAgICA3LjA0 MzIwNl0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcwpbICAgIDcuMDQ3OTAzXSBJ bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyClsgICAgNy4wNTI1OTRdIEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIG5ldF9jbHMKWyAgICA3LjA1NzI4OV0gSW5pdGlhbGl6aW5nIGNn cm91cCBzdWJzeXMgYmxraW8KWyAgICA3LjA2MTgxNF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJz eXMgcGVyZl9ldmVudApbICAgIDcuMDY2ODI0XSBEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRp b25zClsgICAgNy4wNzEyMTBdIEVORVJHWV9QRVJGX0JJQVM6IFNldCB0byAnbm9ybWFsJywgd2Fz ICdwZXJmb3JtYW5jZScKWyAgICA3LjA3MTIxMV0gRU5FUkdZX1BFUkZfQklBUzogVmlldyBhbmQg dXBkYXRlIHdpdGggeDg2X2VuZXJneV9wZXJmX3BvbGljeSg4KQpbICAgIDcuMDg0OTE0XSBDUFU6 IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMApbICAgIDcuMDg5MTYzXSBDUFU6IFByb2Nlc3NvciBD b3JlIElEOiAwClsgICAgNy4wOTUyMzhdIEFDUEk6IENvcmUgcmV2aXNpb24gMjAxMTA0MTMKWyAg ICA3LjEyODIzNF0gZnRyYWNlOiBhbGxvY2F0aW5nIDI1NzUwIGVudHJpZXMgaW4gMTAxIHBhZ2Vz ClsgICAgNy4xNDA5MDBdIGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSAyNzMKWyAgICA3LjE0NTA0 Nl0gUGVyZm9ybWFuY2UgRXZlbnRzOiB1bnN1cHBvcnRlZCBwNiBDUFUgbW9kZWwgNDIgbm8gUE1V IGRyaXZlciwgc29mdHdhcmUgZXZlbnRzIG9ubHkuClsgICAgNy4xNTQ2ODddIGluc3RhbGxpbmcg WGVuIHRpbWVyIGZvciBDUFUgMQpbICAgIDcuMTU4OTg4XSBjcHUgMSBzcGlubG9jayBldmVudCBp cnEgMjc5CihYRU4pIGRvbWFpbi5jOjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3Mg MDAwNDI2NjAgLT4gMDAwMDI2NjAKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hh bmdlIENSNCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAg QXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwClsgICAgNy4x ODI4MDVdIERpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMKWyAgICA3LjE4MjkwOF0gaW5z dGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAyClsgICAgNy4xOTE2NjhdIGNwdSAyIHNwaW5sb2Nr IGV2ZW50IGlycSAyODUKKFhFTikgZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENS NCBmbGFncyAwMDA0MjY2MCAtPiAwMDAwMjY2MAooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0ZW1w dCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwCihYRU4pIGRvbWFpbi5j OjY5ODpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwNDI2NjAgLT4gMDAwMDI2NjAK WyAgICA3LjIxNTUwMV0gRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucwpbICAgIDcuMjE1 NTk1XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMKWyAgICA3LjIyNDM0NV0gY3B1IDMg c3BpbmxvY2sgZXZlbnQgaXJxIDI5MQooWEVOKSBkb21haW4uYzo2OTg6ZDAgQXR0ZW1wdCB0byBj aGFuZ2UgQ1I0IGZsYWdzIDAwMDQyNjYwIC0+IDAwMDAyNjYwCihYRU4pIGRvbWFpbi5jOjY5ODpk MCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwNDI2NjAgLT4gMDAwMDI2NjAKKFhFTikg ZG9tYWluLmM6Njk4OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDA0MjY2MCAtPiAw MDAwMjY2MApbICAgIDcuMjQ4MTgwXSBEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zClsg ICAgNy4yNDgyMDddIEJyb3VnaHQgdXAgNCBDUFVzClsgICAgNy4yNTU5OTldIGRldnRtcGZzOiBp bml0aWFsaXplZApbICAgIDcuMjU5NzA5XSBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9u IGF0IGRhZTlmMDAwICgxMDQ4NTc2IGJ5dGVzKQpbICAgIDcuMjY3NzU4XSBHcmFudCB0YWJsZSBp bml0aWFsaXplZApbICAgIDcuMjcxNDMzXSBwcmludF9jb25zdHJhaW50czogZHVtbXk6IApbICAg IDcuMjc1NDM1XSBUaW1lOiAxMDo1ODoyNCAgRGF0ZTogMDUvMDUvMTIKWyAgICA3LjI3OTc5MF0g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpbICAgIDcuMjg0NTkyXSBUcnlpbmcg dG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4KWyAgICA3LjI5NDU1MV0gQUNQ SSBGQURUIGRlY2xhcmVzIHRoZSBzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IFBDSWUgQVNQTSwgc28g ZGlzYWJsZSBpdApbICAgIDcuMzAyNDczXSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApb ICAgIDcuMzA3MDcwXSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLTNmXSBh dCBbbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZl0gKGJhc2UgMHhmODAwMDAwMCkKWyAgICA3LjMx NjgwOF0gUENJOiBNTUNPTkZJRyBhdCBbbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZl0gcmVzZXJ2 ZWQgaW4gRTgyMApbICAgIDcuMzMyMTg3XSBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDM3NTUyayBm cmVlZApbICAgIDcuMzQ4NzE3XSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBi YXNlIGFjY2VzcwpbICAgIDcuMzU1MjE1XSBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMD4gYXQgMApb ICAgIDcuMzY0MTgwXSBBQ1BJOiBFQzogRUMgZGVzY3JpcHRpb24gdGFibGUgaXMgZm91bmQsIGNv bmZpZ3VyaW5nIGJvb3QgRUMKWyAgICA3LjM4MDg3OV0gW0Zpcm13YXJlIEJ1Z106IEFDUEk6IEJJ T1MgX09TSShMaW51eCkgcXVlcnkgaWdub3JlZApbICAgIDcuNDI0ODI1XSBBQ1BJOiBTU0RUIDAw MDAwMDAwZGFlOGMwMTggMDA4QzAgKHYwMSAgUG1SZWYgIENwdTBDc3QgMDAwMDMwMDEgSU5UTCAy MDA2MTEwOSkKWyAgICA3LjQzMzg5MV0gQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKWyAg ICA3LjQzODA3N10gQUNQSTogU1NEVCAgICAgICAgICAgKG51bGwpIDAwOEMwICh2MDEgIFBtUmVm ICBDcHUwQ3N0IDAwMDAzMDAxIElOVEwgMjAwNjExMDkpClsgICAgNy40NzE0OTJdIEFDUEk6IFNT RFQgMDAwMDAwMDBkYWU4ZGE5OCAwMDMwMyAodjAxICBQbVJlZiAgICBBcElzdCAwMDAwMzAwMCBJ TlRMIDIwMDYxMTA5KQpbICAgIDcuNDgwNTkzXSBBQ1BJOiBEeW5hbWljIE9FTSBUYWJsZSBMb2Fk OgpbICAgIDcuNDg0Nzg2XSBBQ1BJOiBTU0RUICAgICAgICAgICAobnVsbCkgMDAzMDMgKHYwMSAg UG1SZWYgICAgQXBJc3QgMDAwMDMwMDAgSU5UTCAyMDA2MTEwOSkKWyAgICA3LjUwOTkzMl0gQUNQ STogU1NEVCAwMDAwMDAwMGRhZThiZDk4IDAwMTE5ICh2MDEgIFBtUmVmICAgIEFwQ3N0IDAwMDAz MDAwIElOVEwgMjAwNjExMDkpClsgICAgNy41MTk3MzldIEFDUEk6IER5bmFtaWMgT0VNIFRhYmxl IExvYWQ6ClsgICAgNy41MjM5MzBdIEFDUEk6IFNTRFQgICAgICAgICAgIChudWxsKSAwMDExOSAo djAxICBQbVJlZiAgICBBcENzdCAwMDAwMzAwMCBJTlRMIDIwMDYxMTA5KQpbICAgIDcuNTQ5NzAy XSBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkClsgICAgNy41NTM1MjddIEFDUEk6IChzdXBwb3J0 cyBTMCBTMyBTNCBTNSkKWyAgICA3LjU1NzcwOV0gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRl cnJ1cHQgcm91dGluZwpbICAgIDcuNTg3OTc0XSBBQ1BJOiBQb3dlciBSZXNvdXJjZSBbUFVCU10g KG9uKQpbICAgIDcuNTk2Njk3XSBBQ1BJOiBFQzogR1BFID0gMHgxMSwgSS9POiBjb21tYW5kL3N0 YXR1cyA9IDB4NjYsIGRhdGEgPSAweDYyClsgICAgNy42MDU1MjJdIEFDUEk6IEFDUEkgRG9jayBT dGF0aW9uIERyaXZlcjogMyBkb2Nrcy9iYXlzIGZvdW5kClsgICAgNy42MTE2MThdIEhFU1Q6IFRh YmxlIG5vdCBmb3VuZC4KWyAgICA3LjYxNTI1Ml0gUENJOiBVc2luZyBob3N0IGJyaWRnZSB3aW5k b3dzIGZyb20gQUNQSTsgaWYgbmVjZXNzYXJ5LCB1c2UgInBjaT1ub2NycyIgYW5kIHJlcG9ydCBh IGJ1ZwpbICAgIDcuNjI1MDE5XSBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4g MDAwMCBbYnVzIDAwLWZlXSkKWyAgICA3LjYzMTUzNF0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9z dCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwMDAwLTB4MGNmN10KWyAgICA3LjYzODQ4MV0gcGNpX3Jv b3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwZDAwLTB4ZmZmZl0KWyAg ICA3LjY0NTQ3NF0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0g MHgwMDBhMDAwMC0weDAwMGJmZmZmXQpbICAgIDcuNjUzMjA1XSBwY2lfcm9vdCBQTlAwQTA4OjAw OiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGRmYTAwMDAwLTB4ZmViZmZmZmZdClsgICAgNy42 NjA5MjddIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmVk NDAwMDAtMHhmZWQ0YmZmZl0KWyAgICA3LjY2ODY2NV0gcGNpIDAwMDA6MDA6MDAuMDogWzgwODY6 MDEwNF0gdHlwZSAwIGNsYXNzIDB4MDAwNjAwClsgICAgNy42NzUwMzVdIHBjaSAwMDAwOjAwOjAy LjA6IFs4MDg2OjAxMjZdIHR5cGUgMCBjbGFzcyAweDAwMDMwMApbICAgIDcuNjgxMjUyXSBwY2kg MDAwMDowMDowMi4wOiByZWcgMTA6IFttZW0gMHhmMDAwMDAwMC0weGYwM2ZmZmZmIDY0Yml0XQpb ICAgIDcuNjg4MjI3XSBwY2kgMDAwMDowMDowMi4wOiByZWcgMTg6IFttZW0gMHhlMDAwMDAwMC0w eGVmZmZmZmZmIDY0Yml0IHByZWZdClsgICAgNy42OTU2NjldIHBjaSAwMDAwOjAwOjAyLjA6IHJl ZyAyMDogW2lvICAweDUwMDAtMHg1MDNmXQpbICAgIDcuNzAxNTQ3XSBwY2kgMDAwMDowMDoxNi4w OiBbODA4NjoxYzNhXSB0eXBlIDAgY2xhc3MgMHgwMDA3ODAKWyAgICA3LjcwNzc4NF0gcGNpIDAw MDA6MDA6MTYuMDogcmVnIDEwOiBbbWVtIDB4ZjI2MjUwMDAtMHhmMjYyNTAwZiA2NGJpdF0KWyAg ICA3LjcxNDg5NF0gcGNpIDAwMDA6MDA6MTYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv dCBEM2NvbGQKWyAgICA3LjcyMTI2MF0gcGNpIDAwMDA6MDA6MTYuMDogUE1FIyBkaXNhYmxlZApb ICAgIDcuNzI1NzU4XSBwY2kgMDAwMDowMDoxNi4zOiBbODA4NjoxYzNkXSB0eXBlIDAgY2xhc3Mg MHgwMDA3MDAKWyAgICA3LjczMjAxNV0gcGNpIDAwMDA6MDA6MTYuMzogcmVnIDEwOiBbaW8gIDB4 NTBiMC0weDUwYjddClsgICAgNy43Mzc3MTNdIHBjaSAwMDAwOjAwOjE2LjM6IHJlZyAxNDogW21l bSAweGYyNjJjMDAwLTB4ZjI2MmNmZmZdClsgICAgNy43NDQzOTldIHBjaSAwMDAwOjAwOjE5LjA6 IFs4MDg2OjE1MDJdIHR5cGUgMCBjbGFzcyAweDAwMDIwMApbICAgIDcuNzUwNjI5XSBwY2kgMDAw MDowMDoxOS4wOiByZWcgMTA6IFttZW0gMHhmMjYwMDAwMC0weGYyNjFmZmZmXQpbICAgIDcuNzU3 MDUzXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMTQ6IFttZW0gMHhmMjYyYjAwMC0weGYyNjJiZmZm XQpbICAgIDcuNzYzNTEyXSBwY2kgMDAwMDowMDoxOS4wOiByZWcgMTg6IFtpbyAgMHg1MDgwLTB4 NTA5Zl0KWyAgICA3Ljc2OTQwMF0gcGNpIDAwMDA6MDA6MTkuMDogUE1FIyBzdXBwb3J0ZWQgZnJv bSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljc3NTc2OV0gcGNpIDAwMDA6MDA6MTkuMDogUE1FIyBk aXNhYmxlZApbICAgIDcuNzgwMjY0XSBwY2kgMDAwMDowMDoxYS4wOiBbODA4NjoxYzJkXSB0eXBl IDAgY2xhc3MgMHgwMDBjMDMKWyAgICA3Ljc4NjUxOV0gcGNpIDAwMDA6MDA6MWEuMDogcmVnIDEw OiBbbWVtIDB4ZjI2MmEwMDAtMHhmMjYyYTNmZl0KWyAgICA3Ljc5MzE0M10gcGNpIDAwMDA6MDA6 MWEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljc5OTUwMl0g cGNpIDAwMDA6MDA6MWEuMDogUE1FIyBkaXNhYmxlZApbICAgIDcuODA0MDEwXSBwY2kgMDAwMDow MDoxYi4wOiBbODA4NjoxYzIwXSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAgICA3LjgxMDI1Ml0g cGNpIDAwMDA6MDA6MWIuMDogcmVnIDEwOiBbbWVtIDB4ZjI2MjAwMDAtMHhmMjYyM2ZmZiA2NGJp dF0KWyAgICA3LjgxNzQwOV0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE MCBEM2hvdCBEM2NvbGQKWyAgICA3LjgyMzc2Nl0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBkaXNh YmxlZApbICAgIDcuODI4MjU0XSBwY2kgMDAwMDowMDoxYy4wOiBbODA4NjoxYzEwXSB0eXBlIDEg Y2xhc3MgMHgwMDA2MDQKWyAgICA3LjgzNDY3Nl0gcGNpIDAwMDA6MDA6MWMuMDogUE1FIyBzdXBw b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljg0MTA0OF0gcGNpIDAwMDA6MDA6MWMu MDogUE1FIyBkaXNhYmxlZApbICAgIDcuODQ1NTM5XSBwY2kgMDAwMDowMDoxYy4xOiBbODA4Njox YzEyXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3Ljg1MTk1MV0gcGNpIDAwMDA6MDA6MWMu MTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3Ljg1ODMyNl0gcGNp IDAwMDA6MDA6MWMuMTogUE1FIyBkaXNhYmxlZApbICAgIDcuODYyODIzXSBwY2kgMDAwMDowMDox Yy4zOiBbODA4NjoxYzE2XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3Ljg2OTI2MV0gcGNp IDAwMDA6MDA6MWMuMzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3 Ljg3NTYyMV0gcGNpIDAwMDA6MDA6MWMuMzogUE1FIyBkaXNhYmxlZApbICAgIDcuODgwMTIxXSBw Y2kgMDAwMDowMDoxYy40OiBbODA4NjoxYzE4XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICA3 Ljg4NjU0Ml0gcGNpIDAwMDA6MDA6MWMuNDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBE M2NvbGQKWyAgICA3Ljg5MjkyMl0gcGNpIDAwMDA6MDA6MWMuNDogUE1FIyBkaXNhYmxlZApbICAg IDcuODk3NDEyXSBwY2kgMDAwMDowMDoxYy42OiBbODA4NjoxYzFjXSB0eXBlIDEgY2xhc3MgMHgw MDA2MDQKWyAgICA3LjkwMzgzOF0gcGNpIDAwMDA6MDA6MWMuNjogUE1FIyBzdXBwb3J0ZWQgZnJv bSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3LjkxMDIwNV0gcGNpIDAwMDA6MDA6MWMuNjogUE1FIyBk aXNhYmxlZApbICAgIDcuOTE0NzIzXSBwY2kgMDAwMDowMDoxZC4wOiBbODA4NjoxYzI2XSB0eXBl IDAgY2xhc3MgMHgwMDBjMDMKWyAgICA3LjkyMDk4Ml0gcGNpIDAwMDA6MDA6MWQuMDogcmVnIDEw OiBbbWVtIDB4ZjI2MjkwMDAtMHhmMjYyOTNmZl0KWyAgICA3LjkyNzYwMV0gcGNpIDAwMDA6MDA6 MWQuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICA3LjkzMzk3N10g cGNpIDAwMDA6MDA6MWQuMDogUE1FIyBkaXNhYmxlZApbICAgIDcuOTM4NDczXSBwY2kgMDAwMDow MDoxZi4wOiBbODA4NjoxYzRmXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDEKWyAgICA3Ljk0NDk4M10g cGNpIDAwMDA6MDA6MWYuMjogWzgwODY6MWMwM10gdHlwZSAwIGNsYXNzIDB4MDAwMTA2ClsgICAg Ny45NTEyMDZdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxMDogW2lvICAweDUwYTgtMHg1MGFmXQpb ICAgIDcuOTU2ODkxXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTQ6IFtpbyAgMHg1MGJjLTB4NTBi Zl0KWyAgICA3Ljk2MjYyMl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDE4OiBbaW8gIDB4NTBhMC0w eDUwYTddClsgICAgNy45NjgzMzhdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxYzogW2lvICAweDUw YjgtMHg1MGJiXQpbICAgIDcuOTc0MDUwXSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMjA6IFtpbyAg MHg1MDYwLTB4NTA3Zl0KWyAgICA3Ljk3OTc2Nl0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDI0OiBb bWVtIDB4ZjI2MjgwMDAtMHhmMjYyODdmZl0KWyAgICA3Ljk4NjMzMl0gcGNpIDAwMDA6MDA6MWYu MjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEM2hvdApbICAgIDcuOTkxNzkwXSBwY2kgMDAwMDowMDox Zi4yOiBQTUUjIGRpc2FibGVkClsgICAgNy45OTYyNjNdIHBjaSAwMDAwOjAwOjFmLjM6IFs4MDg2 OjFjMjJdIHR5cGUgMCBjbGFzcyAweDAwMGMwNQpbICAgIDguMDAyNTM3XSBwY2kgMDAwMDowMDox Zi4zOiByZWcgMTA6IFttZW0gMHhmMjYyNDAwMC0weGYyNjI0MGZmIDY0Yml0XQpbICAgIDguMDA5 NTY0XSBwY2kgMDAwMDowMDoxZi4zOiByZWcgMjA6IFtpbyAgMHhlZmEwLTB4ZWZiZl0KWyAgICA4 LjAxNTQxN10gcGNpIDAwMDA6MDA6MWMuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAyXQpbICAg IDguMDIwODg3XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAt MHgwMDAwXSAoZGlzYWJsZWQpClsgICAgOC4wMjgzMjNdIHBjaSAwMDAwOjAwOjFjLjA6ICAgYnJp ZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZl0gKGRpc2FibGVkKQpbICAgIDgu MDM2NDk2XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAw LTB4MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDguMDQ1NTA4XSBwY2kgMDAwMDowMzow MC4wOiBbODA4Njo0MjM4XSB0eXBlIDAgY2xhc3MgMHgwMDAyODAKWyAgICA4LjA1MjA2MV0gcGNp IDAwMDA6MDM6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjI1MDAwMDAtMHhmMjUwMWZmZiA2NGJpdF0K WyAgICA4LjA2MDc3MV0gcGNpIDAwMDA6MDM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE M2hvdCBEM2NvbGQKWyAgICA4LjA2NzE5Nl0gcGNpIDAwMDA6MDM6MDAuMDogUE1FIyBkaXNhYmxl ZApbICAgIDguMDc2MTg5XSBwY2kgMDAwMDowMDoxYy4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMt MDNdClsgICAgOC4wODE2NTZdIHBjaSAwMDAwOjAwOjFjLjE6ICAgYnJpZGdlIHdpbmRvdyBbaW8g IDB4ZjAwMC0weDAwMDBdIChkaXNhYmxlZCkKWyAgICA4LjA4OTExMF0gcGNpIDAwMDA6MDA6MWMu MTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMjUwMDAwMC0weGYyNWZmZmZmXQpbICAgIDguMDk2 MzAyXSBwY2kgMDAwMDowMDoxYy4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4 MDAwZmZmZmYgcHJlZl0gKGRpc2FibGVkKQpbICAgIDguMTA1MDU4XSBwY2kgMDAwMDowNTowMC4w OiBbMTQxNTpjMTIwXSB0eXBlIDAgY2xhc3MgMHgwMDA3MDAKWyAgICA4LjExMTI3Ml0gcGNpIDAw MDA6MDU6MDAuMDogcmVnIDEwOiBbaW8gIDB4NDAwMC0weDQwMDddClsgICAgOC4xMTcyMDZdIHBj aSAwMDAwOjA1OjAwLjA6IHN1cHBvcnRzIEQxIEQyClsgICAgOC4xMjE2NTldIHBjaSAwMDAwOjA1 OjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDEgRDIgRDNob3QgRDNjb2xkClsgICAgOC4xMjgz OTBdIHBjaSAwMDAwOjA1OjAwLjA6IFBNRSMgZGlzYWJsZWQKWyAgICA4LjEzNzAxMV0gcGNpIDAw MDA6MDA6MWMuMzogUENJIGJyaWRnZSB0byBbYnVzIDA1LTBjXQpbICAgIDguMTQyNDg1XSBwY2kg MDAwMDowMDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweDQwMDAtMHg0ZmZmXQpbICAgIDgu MTQ4OTI2XSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGYxZDAwMDAw LTB4ZjI0ZmZmZmZdClsgICAgOC4xNTYxMjNdIHBjaSAwMDAwOjAwOjFjLjM6ICAgYnJpZGdlIHdp bmRvdyBbbWVtIDB4ZjA0MDAwMDAtMHhmMGJmZmZmZiA2NGJpdCBwcmVmXQpbICAgIDguMTY0NjMy XSBwY2kgMDAwMDowZDowMC4wOiBbMTE4MDplODIyXSB0eXBlIDAgY2xhc3MgMHgwMDA4ODAKWyAg ICA4LjE3MDk4NV0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjE1MDAwMDAtMHhm MTUwMDBmZl0KWyAgICA4LjE3NzgwMl0gcGNpIDAwMDA6MGQ6MDAuMDogc3VwcG9ydHMgRDEgRDIK WyAgICA4LjE4MjI2Ml0gcGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE MSBEMiBEM2hvdCBEM2NvbGQKWyAgICA4LjE4OTQwMV0gcGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBk aXNhYmxlZApbICAgIDguMTk4MjcwXSBwY2kgMDAwMDowMDoxYy40OiBQQ0kgYnJpZGdlIHRvIFti dXMgMGQtMGRdClsgICAgOC4yMDM3MzNdIHBjaSAwMDAwOjAwOjFjLjQ6ICAgYnJpZGdlIHdpbmRv dyBbaW8gIDB4MzAwMC0weDNmZmZdClsgICAgOC4yMTAxNzldIHBjaSAwMDAwOjAwOjFjLjQ6ICAg YnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjE1MDAwMDAtMHhmMWNmZmZmZl0KWyAgICA4LjIxNzM5Ml0g cGNpIDAwMDA6MDA6MWMuNDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMGMwMDAwMC0weGYxM2Zm ZmZmIDY0Yml0IHByZWZdClsgICAgOC4yMjU3MDhdIHBjaSAwMDAwOjBlOjAwLjA6IFsxMDMzOjAx OTRdIHR5cGUgMCBjbGFzcyAweDAwMGMwMwpbICAgIDguMjMxOTQ3XSBwY2kgMDAwMDowZTowMC4w OiByZWcgMTA6IFttZW0gMHhmMTQwMDAwMC0weGYxNDAxZmZmIDY0Yml0XQpbICAgIDguMjM5MTM3 XSBwY2kgMDAwMDowZTowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApb ICAgIDguMjQ1NTAyXSBwY2kgMDAwMDowZTowMC4wOiBQTUUjIGRpc2FibGVkClsgICAgOC4yNTAw NDNdIHBjaSAwMDAwOjAwOjFjLjY6IFBDSSBicmlkZ2UgdG8gW2J1cyAwZS0wZV0KWyAgICA4LjI1 NTUwM10gcGNpIDAwMDA6MDA6MWMuNjogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhmMDAwLTB4MDAw MF0gKGRpc2FibGVkKQpbICAgIDguMjYyOTU1XSBwY2kgMDAwMDowMDoxYy42OiAgIGJyaWRnZSB3 aW5kb3cgW21lbSAweGYxNDAwMDAwLTB4ZjE0ZmZmZmZdClsgICAgOC4yNzAxMzRdIHBjaSAwMDAw OjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZmMDAwMDAtMHgwMDBmZmZmZiBwcmVm XSAoZGlzYWJsZWQpClsgICAgOC4yNzg3OThdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU YWJsZSBbXF9TQl8uUENJMC5fUFJUXQpbICAgIDguMjg1MDg1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQMS5fUFJUXQpbICAgIDguMjkxNzU4XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQMi5fUFJUXQpbICAg IDguMjk4NDg0XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAu RVhQNC5fUFJUXQpbICAgIDguMzA1MjEwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFi bGUgW1xfU0JfLlBDSTAuRVhQNS5fUFJUXQpbICAgIDguMzExOTMzXSBBQ1BJOiBQQ0kgSW50ZXJy dXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuRVhQNy5fUFJUXQpbICAgIDguMzE4Nzg2XSAg cGNpMDAwMDowMDogUmVxdWVzdGluZyBBQ1BJIF9PU0MgY29udHJvbCAoMHgxZCkKWyAgICA4LjMy NDkzMF0gIHBjaTAwMDA6MDA6IEFDUEkgX09TQyByZXF1ZXN0IGZhaWxlZCAoQUVfU1VQUE9SVCks IHJldHVybmVkIGNvbnRyb2wgbWFzazogMHgwZApbICAgIDguMzMzNjU0XSBBQ1BJIF9PU0MgY29u dHJvbCBmb3IgUENJZSBub3QgZ3JhbnRlZCwgZGlzYWJsaW5nIEFTUE0KKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDowMC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAooWEVO KSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNi4zCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTkuMAooWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDAwOjAwOjFhLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYi4wCihYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MWMuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw OjFjLjEKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxYy4zCihYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwMDA6MDA6MWMuNAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFjLjYKKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxZC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MWYuMAooWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjFmLjIKKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxZi4zCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDAuMAooWEVOKSBQ Q0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjAKKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowZDow MC4wCihYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGU6MDAuMApbICAgIDguNDA1Mjc1XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDMgNCA1IDYgNyA5IDEwICoxMSkKWyAg ICA4LjQxMjA3OV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyAzIDQgNSA2 ICo3IDkgMTAgMTEpClsgICAgOC40MTg4ODVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L Q10gKElSUXMgMyA0IDUgNiAqNyA5IDEwIDExKQpbICAgIDguNDI1NzA2XSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDMgNCA1IDYgNyA5IDEwICoxMSkKWyAgICA4LjQzMjUw OV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktFXSAoSVJRcyAzIDQgNSA2IDcgOSAqMTAg MTEpClsgICAgOC40MzkzMjJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRl0gKElSUXMg MyA0IDUgNiA3IDkgMTAgMTEpICowLCBkaXNhYmxlZC4KWyAgICA4LjQ0NzMxM10gQUNQSTogUENJ IEludGVycnVwdCBMaW5rIFtMTktHXSAoSVJRcyAzIDQgNSA2IDcgOSAxMCAqMTEpClsgICAgOC40 NTQxMzJdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNiA3IDkg KjEwIDExKQpbICAgIDguNDYwOTE3XSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g ZHJpdmVyLgpbICAgIDguNDY2MjU3XSBsYXN0X3BmbiA9IDB4MjZmODFhIG1heF9hcmNoX3BmbiA9 IDB4NDAwMDAwMDAwClsgICAgOC40NzQ4ODhdIHhlbi1iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFs bG9vbiBkcml2ZXIuClsgICAgOC40ODAyNjJdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6MDAw MDowMDowMi4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVtLGxvY2tzPW5vbmUKWyAgICA4LjQ4 ODczOF0gdmdhYXJiOiBsb2FkZWQKWyAgICA4LjQ5MTYzOF0gdmdhYXJiOiBicmlkZ2UgY29udHJv bCBwb3NzaWJsZSAwMDAwOjAwOjAyLjAKWyAgICA4LjQ5NzQwNF0gU0NTSSBzdWJzeXN0ZW0gaW5p dGlhbGl6ZWQKWyAgICA4LjUwMTQxM10gbGliYXRhIHZlcnNpb24gMy4wMCBsb2FkZWQuClsgICAg OC41MDU0NjNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiZnMK WyAgICA4LjUxMTI0OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBo dWIKWyAgICA4LjUxNjkxM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1 c2IKWyAgICA4LjUyMjMxOF0gUENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwpbICAgIDgu NTMxNDYxXSBQQ0k6IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgOC41 MzcwNDJdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDAwMDA5ZDAwMCAtIDAwMDAwMDAwMDAw OWZmZmYgClsgICAgOC41NDM0MDNdIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDBkYTk5ZjAw MCAtIDAwMDAwMDAwZGJmZmZmZmYgClsgICAgOC41NTAxMjddIHJlc2VydmUgUkFNIGJ1ZmZlcjog MDAwMDAwMDBkYjAwMDAwMCAtIDAwMDAwMDAwZGJmZmZmZmYgClsgICAgOC41NTY4NTJdIHJlc2Vy dmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDFlOThmNTAwMCAtIDAwMDAwMDAxZWJmZmZmZmYgClsgICAg OC41NjM1NjldIHJlc2VydmUgUkFNIGJ1ZmZlcjogMDAwMDAwMDI2ZjgxYTAwMCAtIDAwMDAwMDAy NmZmZmZmZmYgClsgICAgOC41NzAzODJdIE5ldExhYmVsOiBJbml0aWFsaXppbmcKWyAgICA4LjU3 NDIxM10gTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4ClsgICAgOC41Nzg4NDNdIE5l dExhYmVsOiAgcHJvdG9jb2xzID0gVU5MQUJFTEVEIENJUFNPdjQKWyAgICA4LjU4NDEyMF0gTmV0 TGFiZWw6ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2VkIGJ5IGRlZmF1bHQKWyAgICA4LjU5MDA2 M10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgpbICAgIDguNTk4MjUzXSBTd2l0Y2hlZCB0 byBOT0h6IG1vZGUgb24gQ1BVICMwClsgICAgOC42MDE1OThdIFN3aXRjaGVkIHRvIE5PSHogbW9k ZSBvbiBDUFUgIzMKWyAgICA4LjYwMTc4M10gU3dpdGNoZWQgdG8gTk9IeiBtb2RlIG9uIENQVSAj MQpbICAgIDguNjA0MDYyXSBTd2l0Y2hlZCB0byBOT0h6IG1vZGUgb24gQ1BVICMyClsgICAgOC42 MTY4MTNdIEFwcEFybW9yOiBBcHBBcm1vciBGaWxlc3lzdGVtIEVuYWJsZWQKWyAgICA4LjYyMTcz N10gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgOC42MjUwMDhdIEFDUEk6IGJ1cyB0eXBlIHBucCBy ZWdpc3RlcmVkClsgICAgOC42Mjk3MTZdIHBucCAwMDowMDogW21lbSAweDAwMDAwMDAwLTB4MDAw OWZmZmZdClsgICAgOC42MzQ3MTVdIHBucCAwMDowMDogW21lbSAweDAwMGMwMDAwLTB4MDAwYzNm ZmZdClsgICAgOC42Mzk4MDhdIHBucCAwMDowMDogW21lbSAweDAwMGM0MDAwLTB4MDAwYzdmZmZd ClsgICAgOC42NDQ5MDddIHBucCAwMDowMDogW21lbSAweDAwMGM4MDAwLTB4MDAwY2JmZmZdClsg ICAgOC42NDk5OTJdIHBucCAwMDowMDogW21lbSAweDAwMGNjMDAwLTB4MDAwY2ZmZmZdClsgICAg OC42NTUwODVdIHBucCAwMDowMDogW21lbSAweDAwMGQwMDAwLTB4MDAwZDNmZmZdClsgICAgOC42 NjAxNzVdIHBucCAwMDowMDogW21lbSAweDAwMGQ0MDAwLTB4MDAwZDdmZmZdClsgICAgOC42NjUy NjVdIHBucCAwMDowMDogW21lbSAweDAwMGQ4MDAwLTB4MDAwZGJmZmZdClsgICAgOC42NzAzNDhd IHBucCAwMDowMDogW21lbSAweDAwMGRjMDAwLTB4MDAwZGZmZmZdClsgICAgOC42NzU0NDJdIHBu cCAwMDowMDogW21lbSAweDAwMGUwMDAwLTB4MDAwZTNmZmZdClsgICAgOC42ODA1MjNdIHBucCAw MDowMDogW21lbSAweDAwMGU0MDAwLTB4MDAwZTdmZmZdClsgICAgOC42ODU2MjRdIHBucCAwMDow MDogW21lbSAweDAwMGU4MDAwLTB4MDAwZWJmZmZdClsgICAgOC42OTA3MjFdIHBucCAwMDowMDog W21lbSAweDAwMGVjMDAwLTB4MDAwZWZmZmZdClsgICAgOC42OTU4MDddIHBucCAwMDowMDogW21l bSAweDAwMGYwMDAwLTB4MDAwZmZmZmZdClsgICAgOC43MDA4OTZdIHBucCAwMDowMDogW21lbSAw eDAwMTAwMDAwLTB4ZGY5ZmZmZmZdClsgICAgOC43MDU5ODFdIHBucCAwMDowMDogW21lbSAweGZl YzAwMDAwLTB4ZmVkM2ZmZmZdClsgICAgOC43MTEwNjFdIHBucCAwMDowMDogW21lbSAweGZlZDRj MDAwLTB4ZmZmZmZmZmZdClsgICAgOC43MTYyMDldIHN5c3RlbSAwMDowMDogW21lbSAweDAwMDAw MDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguNzIzNTEyXSBzeXN0 ZW0gMDA6MDA6IFttZW0gMHgwMDBjMDAwMC0weDAwMGMzZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2 ZWQKWyAgICA4LjczMDg3Nl0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwYzQwMDAtMHgwMDBjN2Zm Zl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43MzgyNDZdIHN5c3RlbSAwMDowMDogW21l bSAweDAwMGM4MDAwLTB4MDAwY2JmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguNzQ1 NjA0XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBjYzAwMC0weDAwMGNmZmZmXSBjb3VsZCBub3Qg YmUgcmVzZXJ2ZWQKWyAgICA4Ljc1Mjk2OF0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4MDAwZDAwMDAt MHgwMDBkM2ZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43NjAzMzJdIHN5c3RlbSAw MDowMDogW21lbSAweDAwMGQ0MDAwLTB4MDAwZDdmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApb ICAgIDguNzY3Njg4XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBkODAwMC0weDAwMGRiZmZmXSBj b3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljc3NTA1M10gc3lzdGVtIDAwOjAwOiBbbWVtIDB4 MDAwZGMwMDAtMHgwMDBkZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAgOC43ODI0MDhd IHN5c3RlbSAwMDowMDogW21lbSAweDAwMGUwMDAwLTB4MDAwZTNmZmZdIGNvdWxkIG5vdCBiZSBy ZXNlcnZlZApbICAgIDguNzg5NzY4XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBlNDAwMC0weDAw MGU3ZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljc5NzEyNl0gc3lzdGVtIDAwOjAw OiBbbWVtIDB4MDAwZTgwMDAtMHgwMDBlYmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkClsgICAg OC44MDQ0OTddIHN5c3RlbSAwMDowMDogW21lbSAweDAwMGVjMDAwLTB4MDAwZWZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZApbICAgIDguODExODU5XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHgwMDBm MDAwMC0weDAwMGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4LjgxOTIyMl0gc3lz dGVtIDAwOjAwOiBbbWVtIDB4MDAxMDAwMDAtMHhkZjlmZmZmZl0gY291bGQgbm90IGJlIHJlc2Vy dmVkClsgICAgOC44MjY1NzldIHN5c3RlbSAwMDowMDogW21lbSAweGZlYzAwMDAwLTB4ZmVkM2Zm ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDguODMzOTM1XSBzeXN0ZW0gMDA6MDA6IFtt ZW0gMHhmZWQ0YzAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICA4Ljg0 MTI5NV0gc3lzdGVtIDAwOjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMw MSAoYWN0aXZlKQpbICAgIDguODQ4NDg5XSBwbnAgMDA6MDE6IFtidXMgMDAtZmVdClsgICAgOC44 NTIxMDddIHBucCAwMDowMTogW2lvICAweDBjZjgtMHgwY2ZmXQpbICAgIDguODU2NDY0XSBwbnAg MDA6MDE6IFtpbyAgMHgwMDAwLTB4MGNmNyB3aW5kb3ddClsgICAgOC44NjE0NTZdIHBucCAwMDow MTogW2lvICAweDBkMDAtMHhmZmZmIHdpbmRvd10KWyAgICA4Ljg2NjQ0OV0gcG5wIDAwOjAxOiBb bWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZiB3aW5kb3ddClsgICAgOC44NzIxNzJdIHBucCAwMDow MTogW21lbSAweDAwMGMwMDAwLTB4MDAwYzNmZmYgd2luZG93XQpbICAgIDguODc3ODkwXSBwbnAg MDA6MDE6IFttZW0gMHgwMDBjNDAwMC0weDAwMGM3ZmZmIHdpbmRvd10KWyAgICA4Ljg4MzYxM10g cG5wIDAwOjAxOiBbbWVtIDB4MDAwYzgwMDAtMHgwMDBjYmZmZiB3aW5kb3ddClsgICAgOC44ODkz MzVdIHBucCAwMDowMTogW21lbSAweDAwMGNjMDAwLTB4MDAwY2ZmZmYgd2luZG93XQpbICAgIDgu ODk1MDU5XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBkMDAwMC0weDAwMGQzZmZmIHdpbmRvd10KWyAg ICA4LjkwMDc3NV0gcG5wIDAwOjAxOiBbbWVtIDB4MDAwZDQwMDAtMHgwMDBkN2ZmZiB3aW5kb3dd ClsgICAgOC45MDY1MDBdIHBucCAwMDowMTogW21lbSAweDAwMGQ4MDAwLTB4MDAwZGJmZmYgd2lu ZG93XQpbICAgIDguOTEyMjI5XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBkYzAwMC0weDAwMGRmZmZm IHdpbmRvd10KWyAgICA4LjkxNzk1M10gcG5wIDAwOjAxOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBl M2ZmZiB3aW5kb3ddClsgICAgOC45MjM2ODddIHBucCAwMDowMTogW21lbSAweDAwMGU0MDAwLTB4 MDAwZTdmZmYgd2luZG93XQpbICAgIDguOTI5NDE0XSBwbnAgMDA6MDE6IFttZW0gMHgwMDBlODAw MC0weDAwMGViZmZmIHdpbmRvd10KWyAgICA4LjkzNTEzOF0gcG5wIDAwOjAxOiBbbWVtIDB4MDAw ZWMwMDAtMHgwMDBlZmZmZiB3aW5kb3ddClsgICAgOC45NDA4NTFdIHBucCAwMDowMTogW21lbSAw eGRmYTAwMDAwLTB4ZmViZmZmZmYgd2luZG93XQpbICAgIDguOTQ2NTg1XSBwbnAgMDA6MDE6IFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDRiZmZmIHdpbmRvd10KWyAgICA4Ljk1MjM1NF0gcG5wIDAwOjAx OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAzIChhY3RpdmUp ClsgICAgOC45NjAwMDJdIHBucCAwMDowMjogW2lvICAweDAwMTAtMHgwMDFmXQpbICAgIDguOTY0 Mjk4XSBwbnAgMDA6MDI6IFtpbyAgMHgwMDkwLTB4MDA5Zl0KWyAgICA4Ljk2ODY1OV0gcG5wIDAw OjAyOiBbaW8gIDB4MDAyNC0weDAwMjVdClsgICAgOC45NzMwMTRdIHBucCAwMDowMjogW2lvICAw eDAwMjgtMHgwMDI5XQpbICAgIDguOTc3MzYxXSBwbnAgMDA6MDI6IFtpbyAgMHgwMDJjLTB4MDAy ZF0KWyAgICA4Ljk4MTcyNV0gcG5wIDAwOjAyOiBbaW8gIDB4MDAzMC0weDAwMzFdClsgICAgOC45 ODYwODhdIHBucCAwMDowMjogW2lvICAweDAwMzQtMHgwMDM1XQpbICAgIDguOTkwNDUyXSBwbnAg MDA6MDI6IFtpbyAgMHgwMDM4LTB4MDAzOV0KWyAgICA4Ljk5NDgxMl0gcG5wIDAwOjAyOiBbaW8g IDB4MDAzYy0weDAwM2RdClsgICAgOC45OTkxNzZdIHBucCAwMDowMjogW2lvICAweDAwYTQtMHgw MGE1XQpbICAgIDkuMDAzNTMxXSBwbnAgMDA6MDI6IFtpbyAgMHgwMGE4LTB4MDBhOV0KWyAgICA5 LjAwNzg5Ml0gcG5wIDAwOjAyOiBbaW8gIDB4MDBhYy0weDAwYWRdClsgICAgOS4wMTIyNjRdIHBu cCAwMDowMjogW2lvICAweDAwYjAtMHgwMGI1XQpbICAgIDkuMDE2NjI3XSBwbnAgMDA6MDI6IFtp byAgMHgwMGI4LTB4MDBiOV0KWyAgICA5LjAyMDk4Ml0gcG5wIDAwOjAyOiBbaW8gIDB4MDBiYy0w eDAwYmRdClsgICAgOS4wMjUzNDNdIHBucCAwMDowMjogW2lvICAweDAwNTAtMHgwMDUzXQpbICAg IDkuMDI5NzAwXSBwbnAgMDA6MDI6IFtpbyAgMHgwMDcyLTB4MDA3N10KWyAgICA5LjAzNDA2NF0g cG5wIDAwOjAyOiBbaW8gIDB4MDQwMC0weDA0N2ZdClsgICAgOS4wMzg0MzFdIHBucCAwMDowMjog W2lvICAweDA1MDAtMHgwNTdmXQpbICAgIDkuMDQyNzk4XSBwbnAgMDA6MDI6IFtpbyAgMHgwODAw LTB4MDgwZl0KWyAgICA5LjA0NzE1OV0gcG5wIDAwOjAyOiBbaW8gIDB4MTVlMC0weDE1ZWZdClsg ICAgOS4wNTE1MThdIHBucCAwMDowMjogW2lvICAweDE2MDAtMHgxNjdmXQpbICAgIDkuMDU1ODc2 XSBwbnAgMDA6MDI6IFttZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmXQpbICAgIDkuMDYwOTYxXSBw bnAgMDA6MDI6IFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXQpbICAgIDkuMDY2MDUyXSBwbnAg MDA6MDI6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXQpbICAgIDkuMDcxMTM4XSBwbnAgMDA6 MDI6IFttZW0gMHhmZWQxMDAwMC0weGZlZDEzZmZmXQpbICAgIDkuMDc2MjI2XSBwbnAgMDA6MDI6 IFttZW0gMHhmZWQxODAwMC0weGZlZDE4ZmZmXQpbICAgIDkuMDgxMzE4XSBwbnAgMDA6MDI6IFtt ZW0gMHhmZWQxOTAwMC0weGZlZDE5ZmZmXQpbICAgIDkuMDg2NDAzXSBwbnAgMDA6MDI6IFttZW0g MHhmZWQ0NTAwMC0weGZlZDRiZmZmXQpbICAgIDkuMDkxNTQxXSBzeXN0ZW0gMDA6MDI6IFtpbyAg MHgwNDAwLTB4MDQ3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICA5LjA5Nzc1NV0gc3lzdGVtIDAw OjAyOiBbaW8gIDB4MDUwMC0weDA1N2ZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgOS4xMDQwMjhd IHN5c3RlbSAwMDowMjogW2lvICAweDA4MDAtMHgwODBmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg IDkuMTEwMjk2XSBzeXN0ZW0gMDA6MDI6IFtpbyAgMHgxNWUwLTB4MTVlZl0gaGFzIGJlZW4gcmVz ZXJ2ZWQKWyAgICA5LjExNjU2NV0gc3lzdGVtIDAwOjAyOiBbaW8gIDB4MTYwMC0weDE2N2ZdIGhh cyBiZWVuIHJlc2VydmVkClsgICAgOS4xMjI4MzJdIHN5c3RlbSAwMDowMjogW21lbSAweGY4MDAw MDAwLTB4ZmJmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgOS4xMjk4MzZdIHN5c3RlbSAw MDowMjogW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApb ICAgIDkuMTM3MjA1XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQxYzAwMC0weGZlZDFmZmZmXSBo YXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTQ0MjAyXSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQx MDAwMC0weGZlZDEzZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTUxMTk5XSBzeXN0ZW0g MDA6MDI6IFttZW0gMHhmZWQxODAwMC0weGZlZDE4ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAg IDkuMTU4MTg5XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQxOTAwMC0weGZlZDE5ZmZmXSBoYXMg YmVlbiByZXNlcnZlZApbICAgIDkuMTY1MTg2XSBzeXN0ZW0gMDA6MDI6IFttZW0gMHhmZWQ0NTAw MC0weGZlZDRiZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDkuMTcyMTg1XSBzeXN0ZW0gMDA6 MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAg OS4xNzkzOTddIHBucCAwMDowMzogW21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmZdClsgICAgOS4x ODQ0NjRdIHBucCAwMDowMzogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAxMDMg KGFjdGl2ZSkKWyAgICA5LjE5MTM0N10gcG5wIDAwOjA0OiBbaW8gIDB4MDAwMC0weDAwMGZdClsg ICAgOS4xOTU2NzZdIHBucCAwMDowNDogW2lvICAweDAwODAtMHgwMDhmXQpbICAgIDkuMjAwMDI1 XSBwbnAgMDA6MDQ6IFtpbyAgMHgwMGMwLTB4MDBkZl0KWyAgICA5LjIwNDM4N10gcG5wIDAwOjA0 OiBbZG1hIDRdClsgICAgOS4yMDc2OThdIHBucCAwMDowNDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRl dmljZSwgSURzIFBOUDAyMDAgKGFjdGl2ZSkKWyAgICA5LjIxNDU2Ml0gcG5wIDAwOjA1OiBbaW8g IDB4MDA2MV0KWyAgICA5LjIxODMzOF0gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2 aWNlLCBJRHMgUE5QMDgwMCAoYWN0aXZlKQpbICAgIDkuMjI1MjMxXSBwbnAgMDA6MDY6IFtpbyAg MHgwMGYwXQpbICAgIDkuMjI4OTU0XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxMyB0cmlnZ2VyaW5n IDEgcG9sYXJpdHkgMApbICAgIDkuMjM0ODQyXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg aXJxIDEzIGZvciBnc2kgMTMKWyAgICA5LjI0MDU2Nl0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9 MTMgKGdzaT0xMykKWyAgICA5LjI0NTQxM10gcG5wIDAwOjA2OiBbaXJxIDEzXQpbICAgIDkuMjQ4 NzY1XSBwbnAgMDA6MDY6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzA0IChh Y3RpdmUpClsgICAgOS4yNTU2NzRdIHBucCAwMDowNzogW2lvICAweDAwNzAtMHgwMDcxXQpbICAg IDkuMjYwMDMzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAw ClsgICAgOS4yNjU4NDFdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOCBmb3IgZ3Np IDgKWyAgICA5LjI3MTM3Nl0geGVuOiAtLT4gcGlycT04IC0+IGlycT04IChnc2k9OCkKWyAgICA5 LjI3NTk0M10gcG5wIDAwOjA3OiBbaXJxIDhdClsgICAgOS4yNzkyMTVdIHBucCAwMDowNzogUGx1 ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkKWyAgICA5LjI4NjA5 N10gcG5wIDAwOjA4OiBbaW8gIDB4MDA2MF0KWyAgICA5LjI4OTgxMV0gcG5wIDAwOjA4OiBbaW8g IDB4MDA2NF0KWyAgICA5LjI5MzUzOF0geGVuOiByZWdpc3RlcmluZyBnc2kgMSB0cmlnZ2VyaW5n IDEgcG9sYXJpdHkgMApbICAgIDkuMjk5MzQ2XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcg aXJxIDEgZm9yIGdzaSAxClsgICAgOS4zMDQ4OTNdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAo Z3NpPTEpClsgICAgOS4zMDk0NDldIHBucCAwMDowODogW2lycSAxXQpbICAgIDkuMzEyNzIxXSBw bnAgMDA6MDg6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMzAzIChhY3RpdmUp ClsgICAgOS4zMTk2MThdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDEyIHRyaWdnZXJpbmcgMSBwb2xh cml0eSAwClsgICAgOS4zMjU1MjFdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTIg Zm9yIGdzaSAxMgpbICAgIDkuMzMxMjQ2XSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3Np PTEyKQpbICAgIDkuMzM2MDg2XSBwbnAgMDA6MDk6IFtpcnEgMTJdClsgICAgOS4zMzk0NTNdIHBu cCAwMDowOTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIExFTjAwMjAgUE5QMGYxMyAo YWN0aXZlKQpbICAgIDkuMzQ3MDgyXSBwbnAgMDA6MGE6IFttZW0gMHhmZWQ0MDAwMC0weGZlZDQ0 ZmZmXQpbICAgIDkuMzUyMTQzXSBwbnAgMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us IElEcyBTTU8xMjAwIFBOUDBjMzEgKGFjdGl2ZSkKWyAgICA5LjM2MDQwOV0gcG5wOiBQblAgQUNQ STogZm91bmQgMTEgZGV2aWNlcwpbICAgIDkuMzY0NzgyXSBBQ1BJOiBBQ1BJIGJ1cyB0eXBlIHBu cCB1bnJlZ2lzdGVyZWQKWyAgICA5LjM3NTA1NF0gUE0tVGltZXIgZmFpbGVkIGNvbnNpc3RlbmN5 IGNoZWNrICAoMHgweGZmZmZmZikgLSBhYm9ydGluZy4KWyAgICA5LjM4MTk4N10gUENJOiBtYXgg YnVzIGRlcHRoOiAxIHBjaV90cnlfbnVtOiAyClsgICAgOS4zODY5NThdIHBjaSAwMDAwOjAwOjFj LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KWyAgICA5LjM5MjQxNF0gcGNpIDAwMDA6MDA6 MWMuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgZGlzYWJsZWRdClsgICAgOS4zOTg0MTldIHBjaSAw MDAwOjAwOjFjLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIGRpc2FibGVkXQpbICAgIDkuNDA0NDE3 XSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSBwcmVmIGRpc2FibGVkXQpb ICAgIDkuNDEwODgzXSBwY2kgMDAwMDowMDoxYy4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNd ClsgICAgOS40MTY0MDldIHBjaSAwMDAwOjAwOjFjLjE6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRp c2FibGVkXQpbICAgIDkuNDIyNDE2XSBwY2kgMDAwMDowMDoxYy4xOiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGYyNTAwMDAwLTB4ZjI1ZmZmZmZdClsgICAgOS40Mjk1OTZdIHBjaSAwMDAwOjAwOjFj LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgOS40MzYwMzFdIHBj aSAwMDAwOjAwOjFjLjM6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wY10KWyAgICA5LjQ0MTU2NV0g cGNpIDAwMDA6MDA6MWMuMzogICBicmlkZ2Ugd2luZG93IFtpbyAgMHg0MDAwLTB4NGZmZl0KWyAg ICA5LjQ0ODAyN10gcGNpIDAwMDA6MDA6MWMuMzogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmMWQw MDAwMC0weGYyNGZmZmZmXQpbICAgIDkuNDU1MjAwXSBwY2kgMDAwMDowMDoxYy4zOiAgIGJyaWRn ZSB3aW5kb3cgW21lbSAweGYwNDAwMDAwLTB4ZjBiZmZmZmYgNjRiaXQgcHJlZl0KWyAgICA5LjQ2 MzM4M10gcGNpIDAwMDA6MDA6MWMuNDogUENJIGJyaWRnZSB0byBbYnVzIDBkLTBkXQpbICAgIDku NDY4OTIwXSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweDMwMDAtMHgz ZmZmXQpbICAgIDkuNDc1Mzc1XSBwY2kgMDAwMDowMDoxYy40OiAgIGJyaWRnZSB3aW5kb3cgW21l bSAweGYxNTAwMDAwLTB4ZjFjZmZmZmZdClsgICAgOS40ODI1NjddIHBjaSAwMDAwOjAwOjFjLjQ6 ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjBjMDAwMDAtMHhmMTNmZmZmZiA2NGJpdCBwcmVmXQpb ICAgIDkuNDkwNzUyXSBwY2kgMDAwMDowMDoxYy42OiBQQ0kgYnJpZGdlIHRvIFtidXMgMGUtMGVd ClsgICAgOS40OTYyNzhdIHBjaSAwMDAwOjAwOjFjLjY6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIGRp c2FibGVkXQpbICAgIDkuNTAyMjkxXSBwY2kgMDAwMDowMDoxYy42OiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGYxNDAwMDAwLTB4ZjE0ZmZmZmZdClsgICAgOS41MDk0NzBdIHBjaSAwMDAwOjAwOjFj LjY6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgOS41MTU5NDNdIHhl bjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsgICAgOS41MjE4 NDhdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAgOS41MjY2NzRdIHBj aSAwMDAwOjAwOjFjLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAx NgpbICAgIDkuNTMzNzQyXSBwY2kgMDAwMDowMDoxYy4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg dG8gNjQKWyAgICA5LjUzOTQ3M10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw IHBvbGFyaXR5IDEKWyAgICA5LjU0NTM4M10geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdz aT0xNykKWyAgICA5LjU1MDIxMF0gcGNpIDAwMDA6MDA6MWMuMTogUENJIElOVCBCIC0+IEdTSSAx NyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3ClsgICAgOS41NTcyOTZdIHBjaSAwMDAwOjAwOjFjLjE6 IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDkuNTYzMDMzXSB4ZW46IHJlZ2lzdGVy aW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgIDkuNTY4OTQ1XSB4ZW46IC0t PiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQpbICAgIDkuNTczNzg2XSBwY2kgMDAwMDowMDox Yy4zOiBQQ0kgSU5UIEQgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICA5LjU4 MDg2MV0gcGNpIDAwMDA6MDA6MWMuMzogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAg OS41ODY1NzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAx ClsgICAgOS41OTI0NzRdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTYgZm9yIGdz aSAxNgpbICAgIDkuNTk4MjAwXSB4ZW46IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQpb ICAgIDkuNjAzMDE0XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE2ClsgICAgOS42MDY5MDNdIHBj aSAwMDAwOjAwOjFjLjQ6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAx NgpbICAgIDkuNjEzOTkxXSBwY2kgMDAwMDowMDoxYy40OiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg dG8gNjQKWyAgICA5LjYxOTcwM10geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAw IHBvbGFyaXR5IDEKWyAgICA5LjYyNTYwN10geGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdz aT0xOCkKWyAgICA5LjYzMDQ0N10gcGNpIDAwMDA6MDA6MWMuNjogUENJIElOVCBDIC0+IEdTSSAx OCAobGV2ZWwsIGxvdykgLT4gSVJRIDE4ClsgICAgOS42Mzc1MDZdIHBjaSAwMDAwOjAwOjFjLjY6 IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDkuNjQzMjI0XSBwY2lfYnVzIDAwMDA6 MDA6IHJlc291cmNlIDQgW2lvICAweDAwMDAtMHgwY2Y3XQpbICAgIDkuNjQ5MTE4XSBwY2lfYnVz IDAwMDA6MDA6IHJlc291cmNlIDUgW2lvICAweDBkMDAtMHhmZmZmXQpbICAgIDkuNjU1MDQwXSBw Y2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdClsg ICAgOS42NjE2NzhdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNyBbbWVtIDB4ZGZhMDAwMDAt MHhmZWJmZmZmZl0KWyAgICA5LjY2ODMxMF0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDRiZmZmXQpbICAgIDkuNjc0OTM5XSBwY2lfYnVzIDAwMDA6MDM6 IHJlc291cmNlIDEgW21lbSAweGYyNTAwMDAwLTB4ZjI1ZmZmZmZdClsgICAgOS42ODE1NTldIHBj aV9idXMgMDAwMDowNTogcmVzb3VyY2UgMCBbaW8gIDB4NDAwMC0weDRmZmZdClsgICAgOS42ODc0 NjRdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2UgMSBbbWVtIDB4ZjFkMDAwMDAtMHhmMjRmZmZm Zl0KWyAgICA5LjY5NDEwOV0gcGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhmMDQw MDAwMC0weGYwYmZmZmZmIDY0Yml0IHByZWZdClsgICAgOS43MDE3MzRdIHBjaV9idXMgMDAwMDow ZDogcmVzb3VyY2UgMCBbaW8gIDB4MzAwMC0weDNmZmZdClsgICAgOS43MDc2MzldIHBjaV9idXMg MDAwMDowZDogcmVzb3VyY2UgMSBbbWVtIDB4ZjE1MDAwMDAtMHhmMWNmZmZmZl0KWyAgICA5Ljcx NDI3Ml0gcGNpX2J1cyAwMDAwOjBkOiByZXNvdXJjZSAyIFttZW0gMHhmMGMwMDAwMC0weGYxM2Zm ZmZmIDY0Yml0IHByZWZdClsgICAgOS43MjE4OTVdIHBjaV9idXMgMDAwMDowZTogcmVzb3VyY2Ug MSBbbWVtIDB4ZjE0MDAwMDAtMHhmMTRmZmZmZl0KWyAgICA5LjcyODU2OV0gTkVUOiBSZWdpc3Rl cmVkIHByb3RvY29sIGZhbWlseSAyClsgICAgOS43MzQzMzldIElQIHJvdXRlIGNhY2hlIGhhc2gg dGFibGUgZW50cmllczogNTI0Mjg4IChvcmRlcjogMTAsIDQxOTQzMDQgYnl0ZXMpClsgICAgOS43 NDYxNzZdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6 IDExLCA4Mzg4NjA4IGJ5dGVzKQpbICAgIDkuNzU1MzMxXSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVu dHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKWyAgICA5Ljc2MjQ1Nl0gVENQ OiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCA1MjQyODggYmluZCA2NTUzNikK WyAgICA5Ljc2OTM4OF0gVENQIHJlbm8gcmVnaXN0ZXJlZApbICAgIDkuNzcyODEyXSBVRFAgaGFz aCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDkuNzc5 MzMxXSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiA2LCAyNjIxNDQg Ynl0ZXMpClsgICAgOS43ODYyNjldIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpb ICAgIDkuNzkwODI3XSBwY2kgMDAwMDowMDowMi4wOiBCb290IHZpZGVvIGRldmljZQpbICAgIDku Nzk1OTY4XSBQQ0k6IENMUyA2NCBieXRlcywgZGVmYXVsdCA2NApbICAgIDkuODAwNTQ2XSBhdWRp dDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICA5LjgwNjIwM10g dHlwZT0yMDAwIGF1ZGl0KDEzMzYyMTU1MDUuODAyOjEpOiBpbml0aWFsaXplZApbICAgIDkuODM2 Njg5XSBIdWdlVExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBw YWdlcwpbICAgIDkuODQ0NTI2XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgOS44 NDg2NzhdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2 IGJ5dGVzKQpbICAgIDkuODU1ODcxXSBmdXNlIGluaXQgKEFQSSB2ZXJzaW9uIDcuMTYpClsgICAg OS44NjAwMzhdIG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMTM5ODkKWyAgICA5Ljg2NDY4OF0gQmxv Y2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9uIDAuNCBsb2FkZWQgKG1h am9yIDI1MykKWyAgICA5Ljg3MjQ0OV0gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZApbICAg IDkuODc2NTc3XSBpbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZApbICAgIDkuODgxMTU3 XSBpbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQgKGRlZmF1bHQpClsgICAgOS44ODY3MzBdIHBj aV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41ClsgICAgOS44OTI1 NjNdIHBjaWVocDogUENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lv bjogMC40ClsgICAgOS44OTk4MTZdIEFDUEk6IERlcHJlY2F0ZWQgcHJvY2ZzIEkvRiBmb3IgQUMg aXMgbG9hZGVkLCBwbGVhc2UgcmV0cnkgd2l0aCBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgY2xl YXJlZApbICAgIDkuOTEwMjk4XSBBQ1BJOiBBQyBBZGFwdGVyIFtBQ10gKG9uLWxpbmUpClsgICAg OS45MTQ4ODldIGlucHV0OiBMaWQgU3dpdGNoIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2Rldmlj ZTowMC9QTlAwQzBEOjAwL2lucHV0L2lucHV0MApbICAgIDkuOTIzNjE2XSBBQ1BJOiBMaWQgU3dp dGNoIFtMSURdClsgICAgOS45MjcxODNdIGlucHV0OiBTbGVlcCBCdXR0b24gYXMgL2RldmljZXMv TE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBDMEU6MDAvaW5wdXQvaW5wdXQxClsgICAgOS45MzU3 NzNdIEFDUEk6IFNsZWVwIEJ1dHRvbiBbU0xQQl0KWyAgICA5LjkzOTcyMV0gaW5wdXQ6IFBvd2Vy IEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1dDIK WyAgICA5Ljk0NzQ3OF0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQpbICAgIDkuOTUxNDE3XSBB Q1BJOiBhY3BpX2lkbGUgcmVnaXN0ZXJlZCB3aXRoIGNwdWlkbGUKWyAgICA5Ljk2MDAzNV0gdGhl cm1hbCBMTlhUSEVSTTowMDogcmVnaXN0ZXJlZCBhcyB0aGVybWFsX3pvbmUwClsgICAgOS45NjU5 MzldIEFDUEk6IFRoZXJtYWwgWm9uZSBbVEhNMF0gKDYwIEMpClsgICAgOS45NzA0OTZdIEFDUEk6 IERlcHJlY2F0ZWQgcHJvY2ZzIEkvRiBmb3IgYmF0dGVyeSBpcyBsb2FkZWQsIHBsZWFzZSByZXRy eSB3aXRoIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBjbGVhcmVkClsgICAgOS45ODEzMTFdIEVS U1Q6IFRhYmxlIGlzIG5vdCBmb3VuZCEKWyAgICA5Ljk4NTY0Nl0gU2VyaWFsOiA4MjUwLzE2NTUw IGRyaXZlciwgMzIgcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQKWyAgIDEwLjAxMTQxNV0gQUNQ STogQmF0dGVyeSBTbG90IFtCQVQwXSAoYmF0dGVyeSBwcmVzZW50KQpbICAgMTAuMDYyNDQyXSB4 ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTAuMDY4 Mjc0XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE5IGZvciBnc2kgMTkKWyAgIDEw LjA3Mzk5N10geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkKWyAgIDEwLjA3ODgz MV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOQpbICAgMTAuMDgyNzM0XSBzZXJpYWwgMDAwMDow MDoxNi4zOiBQQ0kgSU5UIEIgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgIDEw LjExMDcwOV0gMDAwMDowMDoxNi4zOiB0dHlTNCBhdCBJL08gMHg1MGIwIChpcnEgPSAxOSkgaXMg YSAxNjU1MEEKWyAgIDEwLjExNzQzNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmlu ZyAwIHBvbGFyaXR5IDEKWyAgIDEwLjEyMzI0NF0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxOSBmb3IgZ3NpIDE5ClsgICAxMC4xMjg5NDRdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJx PTE5IChnc2k9MTkpClsgICAxMC4xMzM3NTddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAg IDEwLjEzNzYzNV0gc2VyaWFsIDAwMDA6MDU6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxOSAobGV2 ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAxMC4xNDUyMDFdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJl c3Mgb3IgaXJxcyBpbiBfQ1JTClsgICAxMC4xNTA0OTJdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNl IHYwLjEwMwpbICAgMTAuMTU0OTM2XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAuMDogSW50ZWwg U2FuZHlicmlkZ2UgQ2hpcHNldApbICAgMTAuMTYxNTE4XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6 MDAuMDogZGV0ZWN0ZWQgZ3R0IHNpemU6IDIwOTcxNTJLIHRvdGFsLCAyNjIxNDRLIG1hcHBhYmxl ClsgICAxMC4xNzE4MTBdIGFncGdhcnQtaW50ZWwgMDAwMDowMDowMC4wOiBkZXRlY3RlZCA2NTUz Nksgc3RvbGVuIG1lbW9yeQpbICAgMTAuMTc4NzA0XSBhZ3BnYXJ0LWludGVsIDAwMDA6MDA6MDAu MDogQUdQIGFwZXJ0dXJlIGlzIDI1Nk0gQCAweGUwMDAwMDAwClsgICAxMC4xODY1ODhdIGJyZDog bW9kdWxlIGxvYWRlZApbICAgMTAuMTkwMDk2XSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAxMC4x OTM2OTBdIEZpeGVkIE1ESU8gQnVzOiBwcm9iZWQKWyAgIDEwLjE5NzI1N10gUFBQIGdlbmVyaWMg ZHJpdmVyIHZlcnNpb24gMi40LjIKWyAgIDEwLjIwMTgzOF0gdHVuOiBVbml2ZXJzYWwgVFVOL1RB UCBkZXZpY2UgZHJpdmVyLCAxLjYKWyAgIDEwLjIwNzE2N10gdHVuOiAoQykgMTk5OS0yMDA0IE1h eCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+ClsgICAxMC4yMTM3NzZdIGVoY2lfaGNk OiBVU0IgMi4wICdFbmhhbmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXIKWyAgIDEw LjIyMDY4M10gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBwb3dlciBzdGF0ZSBjaGFuZ2VkIGJ5IEFD UEkgdG8gRDAKWyAgIDEwLjIyNzM2NV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBwb3dlciBzdGF0 ZSBjaGFuZ2VkIGJ5IEFDUEkgdG8gRDAKWyAgIDEwLjIzNDA4N10geGVuOiByZWdpc3RlcmluZyBn c2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDEwLjIzOTk3MV0geGVuX21hcF9waXJx X2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3NpIDE2ClsgICAxMC4yNDU2ODBdIHhlbjogLS0+ IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsgICAxMC4yNTA0OTVdIEFscmVhZHkgc2V0dXAg dGhlIEdTSSA6MTYKWyAgIDEwLjI1NDM4OV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBQQ0kgSU5U IEEgLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTYKWyAgIDEwLjI2MTkyN10gZWhjaV9o Y2QgMDAwMDowMDoxYS4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDEwLjI2ODA2 OV0gZWhjaV9oY2QgMDAwMDowMDoxYS4wOiBFSENJIEhvc3QgQ29udHJvbGxlcgpbICAgMTAuMjcz NjI5XSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2ln bmVkIGJ1cyBudW1iZXIgMQpbICAgMTAuMjgxNDU2XSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGRl YnVnIHBvcnQgMgpbICAgMTAuMjkwMDkxXSBlaGNpX2hjZCAwMDAwOjAwOjFhLjA6IGNhY2hlIGxp bmUgc2l6ZSBvZiA2NCBpcyBub3Qgc3VwcG9ydGVkClsgICAxMC4yOTcyMTNdIGVoY2lfaGNkIDAw MDA6MDA6MWEuMDogaXJxIDE2LCBpbyBtZW0gMHhmMjYyYTAwMApbICAgMTAuMzA3MDcwXSBlaGNp X2hjZCAwMDAwOjAwOjFhLjA6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwClsgICAxMC4zMTMx NzBdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAxMC4zMTcwODldIGh1YiAxLTA6MS4w OiAzIHBvcnRzIGRldGVjdGVkClsgICAxMC4zMjE0MDZdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDog cG93ZXIgc3RhdGUgY2hhbmdlZCBieSBBQ1BJIHRvIEQwClsgICAxMC4zMjgwNzRdIGVoY2lfaGNk IDAwMDA6MDA6MWQuMDogcG93ZXIgc3RhdGUgY2hhbmdlZCBieSBBQ1BJIHRvIEQwClsgICAxMC4z MzQ4MDVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIzIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxClsg ICAxMC4zNDA3MDddIHhlbjogLS0+IHBpcnE9MjMgLT4gaXJxPTIzIChnc2k9MjMpClsgICAxMC4z NDU1MjFdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogUENJIElOVCBBIC0+IEdTSSAyMyAobGV2ZWws IGxvdykgLT4gSVJRIDIzClsgICAxMC4zNTMwNjRdIGVoY2lfaGNkIDAwMDA6MDA6MWQuMDogc2V0 dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAxMC4zNTkyMjhdIGVoY2lfaGNkIDAwMDA6MDA6 MWQuMDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjM2NDc5Ml0gZWhjaV9oY2QgMDAwMDow MDoxZC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDIKWyAg IDEwLjM3MjU5OF0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBkZWJ1ZyBwb3J0IDIKWyAgIDEwLjM4 MTI0Ml0gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBjYWNoZSBsaW5lIHNpemUgb2YgNjQgaXMgbm90 IHN1cHBvcnRlZApbICAgMTAuMzg4MzY1XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjA6IGlycSAyMywg aW8gbWVtIDB4ZjI2MjkwMDAKWyAgIDEwLjM5ODI1M10gZWhjaV9oY2QgMDAwMDowMDoxZC4wOiBV U0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgMTAuNDA0MzQxXSBodWIgMi0wOjEuMDogVVNC IGh1YiBmb3VuZApbICAgMTAuNDA4MjY1XSBodWIgMi0wOjEuMDogMyBwb3J0cyBkZXRlY3RlZApb ICAgMTAuNDEyNTcyXSBvaGNpX2hjZDogVVNCIDEuMSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChP SENJKSBEcml2ZXIKWyAgIDEwLjQxOTA4NF0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBD b250cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKWyAgIDEwLjQyNTgwOV0gaTgwNDI6IFBOUDogUFMv MiBDb250cm9sbGVyIFtQTlAwMzAzOktCRCxQTlAwZjEzOk1PVV0gYXQgMHg2MCwweDY0IGlycSAx LDEyClsgICAxMC40Mzc0NTddIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJx IDEKWyAgIDEwLjQ0MjYxN10gc2VyaW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEg MTIKWyAgIDEwLjQ0ODA1M10gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig YWxsIG1pY2UKWyAgIDEwLjQ1NDAxMV0gcnRjX2Ntb3MgMDA6MDc6IFJUQyBjYW4gd2FrZSBmcm9t IFM0ClsgICAxMC40NTg5ODVdIHJ0Y19jbW9zIDAwOjA3OiBydGMgY29yZTogcmVnaXN0ZXJlZCBy dGNfY21vcyBhcyBydGMwClsgICAxMC40NjU0MzFdIHJ0YzA6IGFsYXJtcyB1cCB0byBvbmUgbW9u dGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtClsgICAxMC40NzE2NTJdIGRldmljZS1tYXBwZXI6IHVl dmVudDogdmVyc2lvbiAxLjAuMwpbICAgMTAuNDc2NTI3XSBkZXZpY2UtbWFwcGVyOiBpb2N0bDog NC4yMC4wLWlvY3RsICgyMDExLTAyLTAyKSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv bQpbICAgMTAuNDg1MzYyXSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBsYWRkZXIKWyAgIDEwLjQ4 OTcxM10gY3B1aWRsZTogdXNpbmcgZ292ZXJub3IgbWVudQpbICAgMTAuNDkzODc3XSBFRkkgVmFy aWFibGVzIEZhY2lsaXR5IHYwLjA4IDIwMDQtTWF5LTE3ClsgICAxMC40OTkzOTldIFRDUCBjdWJp YyByZWdpc3RlcmVkClsgICAxMC41MDA5MzddIGlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtl eWJvYXJkIGFzIC9kZXZpY2VzL3BsYXRmb3JtL2k4MDQyL3NlcmlvMC9pbnB1dC9pbnB1dDMKWyAg IDEwLjUxMTkxNl0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApbICAgMTAuNTE2 OTY4XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAxMC41MjE2MTZdIFJl Z2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5IHR5cGUKWyAgIDEwLjUyNjY1Nl0gUE06IEhp YmVybmF0aW9uIGltYWdlIG5vdCBwcmVzZW50IG9yIGNvdWxkIG5vdCBiZSBsb2FkZWQuClsgICAx MC41MzMzODJdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQpbICAgMTAuNTQ5MTQyXSAg IE1hZ2ljIG51bWJlcjogMTI6ODY4Ojk4MQpbICAgMTAuNTUzMTQxXSBydGNfY21vcyAwMDowNzog c2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMi0wNS0wNSAxMDo1ODoyNyBVVEMgKDEzMzYyMTU1 MDcpClsgICAxMC41NzAzODVdIEJJT1MgRUREIGZhY2lsaXR5IHYwLjE2IDIwMDQtSnVuLTI1LCAw IGRldmljZXMgZm91bmQKWyAgIDEwLjU3NjY3MV0gRUREIGluZm9ybWF0aW9uIG5vdCBhdmFpbGFi bGUuClsgICAxMC41ODE0NjldIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDk4OGsgZnJl ZWQKWyAgIDEwLjU4Njc2OF0gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBk YXRhOiAxMjI4OGsKWyAgIDEwLjU5ODE3Nl0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTog MjAzMmsgZnJlZWQKWyAgIDEwLjYwNDE5M10gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTog MTM4OGsgZnJlZWQKTG9hZGluZywgcGxlYXNlIHdhaXQuLi4KWyAgIDEwLjYzMDI2OV0gdXNiIDEt MTogbmV3IGhpZ2ggc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNpX2hjZApbICAg MTAuNjU4OTI1XSB1ZGV2ZFs4N106IHN0YXJ0aW5nIHZlcnNpb24gMTczClsgICAxMC43NTEzMjNd IGUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXIgLSAxLjMuMTAtazIKWyAg IDEwLjc1NzYyMV0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTEgSW50ZWwgQ29ycG9y YXRpb24uClsgICAxMC43NjM5MzldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDIwIHRyaWdnZXJpbmcg MCBwb2xhcml0eSAxClsgICAxMC43Njk4MjZdIHhlbjogLS0+IHBpcnE9MjAgLT4gaXJxPTIwIChn c2k9MjApClsgICAxMC43NzQ3MjRdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IFBDSSBJTlQgQSAtPiBH U0kgMjAgKGxldmVsLCBsb3cpIC0+IElSUSAyMApbICAgMTAuNzgyNzc2XSBodWIgMS0xOjEuMDog VVNCIGh1YiBmb3VuZApbICAgMTAuNzg2ODI2XSBodWIgMS0xOjEuMDogNiBwb3J0cyBkZXRlY3Rl ZApbICAgMTAuNzk5NDE2XSBzZGhjaTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250cm9sbGVyIElu dGVyZmFjZSBkcml2ZXIKWyAgIDEwLjgwNTg2OV0gc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUg T3NzbWFuClsgICAxMC44MTA1NjZdIGUxMDAwZSAwMDAwOjAwOjE5LjA6IHNldHRpbmcgbGF0ZW5j eSB0aW1lciB0byA2NApbICAgMTAuODE5MDI4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmln Z2VyaW5nIDAgcG9sYXJpdHkgMQpbICAgMTAuODI0ODM5XSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKWyAgIDEwLjgzMDU1OV0geGVuOiAtLT4gcGlycT0xOCAt PiBpcnE9MTggKGdzaT0xOCkKWyAgIDEwLjgzNTQwM10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDox OApbICAgMTAuODM5Mjk1XSB4aGNpX2hjZCAwMDAwOjBlOjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kg MTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAgMTAuODU2Nzc0XSBzZGhjaS1wY2kgMDAwMDow ZDowMC4wOiBTREhDSSBjb250cm9sbGVyIGZvdW5kIFsxMTgwOmU4MjJdIChyZXYgNykKWyAgIDEw Ljg2NDQ4NF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTYgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEK WyAgIDEwLjg3MDI4M10geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNiBmb3IgZ3Np IDE2ClsgICAxMC44NzU5OTJdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChnc2k9MTYpClsg ICAxMC44ODA4MzddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTYKWyAgIDEwLjg4NDY5NF0gc2Ro Y2ktcGNpIDAwMDA6MGQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4g SVJRIDE2ClsgICAxMC44OTI1ODRdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogc2V0dGluZyBsYXRl bmN5IHRpbWVyIHRvIDY0ClsgICAxMC44OTg2ODhdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogeEhD SSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjkwNDczOV0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBu ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMKWyAgIDEwLjkxMjU1 Nl0gdXNiIDItMTogbmV3IGhpZ2ggc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNp X2hjZApbICAgMTAuOTE5NzU3XSBzZGhjaS1wY2kgMDAwMDowZDowMC4wOiBzZXR0aW5nIGxhdGVu Y3kgdGltZXIgdG8gNjQKWyAgIDEwLjkyNjEyNl0gbW1jMDogbm8gdm1tYyByZWd1bGF0b3IgZm91 bmQKWyAgIDEwLjkzMDg1OF0gUmVnaXN0ZXJlZCBsZWQgZGV2aWNlOiBtbWMwOjoKWyAgIDEwLjkz NTU3MF0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBpcnEgMTgsIGlvIG1lbSAweGYxNDAwMDAwClsg ICAxMC45NDIyODVdIG1tYzA6IFNESENJIGNvbnRyb2xsZXIgb24gUENJIFswMDAwOjBkOjAwLjBd IHVzaW5nIERNQQpbICAgMTAuOTQ5NTM0XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBm b3Igcm9vdCBodWIKWyAgIDEwLjk1NDk0N10geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs ZWQgZm9yIHJvb3QgaHViClsgICAxMC45NjA3MTJdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5k ClsgICAxMC45NjQ3MDddIGh1YiAzLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAxMC45Njkw MjNdIHhoY2lfaGNkIDAwMDA6MGU6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXIKWyAgIDEwLjk3 NDU1MV0geGhjaV9oY2QgMDAwMDowZTowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3Np Z25lZCBidXMgbnVtYmVyIDQKWyAgIDEwLjk4MjU3M10geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBj YWxsZWQgZm9yIHJvb3QgaHViClsgICAxMC45ODc5NDFdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lk dGggY2FsbGVkIGZvciByb290IGh1YgpbICAgMTAuOTkzNjg0XSBodWIgNC0wOjEuMDogVVNCIGh1 YiBmb3VuZApbICAgMTAuOTk3NjU5XSBodWIgNC0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZApbICAg MTEuMDQ4MDkwXSBlMTAwMGUgMDAwMDowMDoxOS4wOiBldGgwOiAoUENJIEV4cHJlc3M6Mi41R1Qv czpXaWR0aCB4MSkgZjA6ZGU6ZjE6NWI6YjM6N2QKWyAgIDExLjA1NjQwNV0gZTEwMDBlIDAwMDA6 MDA6MTkuMDogZXRoMDogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uClsgICAx MS4wNjI3MjJdIGh1YiAyLTE6MS4wOiBVU0IgaHViIGZvdW5kClsgICAxMS4wNjI4MTddIGh1YiAy LTE6MS4wOiA4IHBvcnRzIGRldGVjdGVkClsgICAxMS4wNzIwNDVdIGUxMDAwZSAwMDAwOjAwOjE5 LjA6IGV0aDA6IE1BQzogMTAsIFBIWTogMTEsIFBCQSBObzogMTAwMEZGLTBGRgpbICAgMTEuMDc5 MzMzXSBhaGNpIDAwMDA6MDA6MWYuMjogdmVyc2lvbiAzLjAKWyAgIDExLjA4MzY3N10geGVuOiBy ZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEKWyAgIDExLjA4OTUwN10g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOSBmb3IgZ3NpIDE5ClsgICAxMS4wOTUx ODhdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpClsgICAxMS4wOTk5OTRdIEFs cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTkKWyAgIDExLjEwMzg2M10gYWhjaSAwMDAwOjAwOjFmLjI6 IFBDSSBJTlQgQiAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgMTEuMTExMjc2 XSBhaGNpOiBTU1MgZmxhZyBzZXQsIHBhcmFsbGVsIGJ1cyBzY2FuIGRpc2FibGVkClsgICAxMS4x MjYzMzZdIGFoY2kgMDAwMDowMDoxZi4yOiBBSENJIDAwMDEuMDMwMCAzMiBzbG90cyA2IHBvcnRz IDYgR2JwcyAweDEzIGltcGwgU0FUQSBtb2RlClsgICAxMS4xMzQ4OTBdIGFoY2kgMDAwMDowMDox Zi4yOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBzdGFnIHBtIGxlZCBjbG8gcGlvIHNsdW0g cGFydCBlbXMgc3hzIGFwc3QgClsgICAxMS4xNDQ2MTFdIGFoY2kgMDAwMDowMDoxZi4yOiBzZXR0 aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDExLjE1NDUxMl0gdXNiIDEtMS4zOiBuZXcgZnVs bCBzcGVlZCBVU0IgZGV2aWNlIG51bWJlciAzIHVzaW5nIGVoY2lfaGNkClsgICAxMS4xNjY3ODVd IHNjc2kwIDogYWhjaQpbICAgMTEuMTY5NTU4XSBzY3NpMSA6IGFoY2kKWyAgIDExLjE3MjI4OF0g c2NzaTIgOiBhaGNpClsgICAxMS4xNzUwMzRdIHNjc2kzIDogYWhjaQpbICAgMTEuMTc3NzUwXSBz Y3NpNCA6IGFoY2kKWyAgIDExLjE4MDQ3Ml0gc2NzaTUgOiBhaGNpClsgICAxMS4xODM4ODddIGF0 YTE6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmMjYyODAwMCBwb3J0IDB4ZjI2Mjgx MDAgaXJxIDMwNApbICAgMTEuMTkxNjc0XSBhdGEyOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0y MDQ4QDB4ZjI2MjgwMDAgcG9ydCAweGYyNjI4MTgwIGlycSAzMDQKWyAgIDExLjE5OTU1M10gYXRh MzogRFVNTVkKWyAgIDExLjIwMjE3OF0gYXRhNDogRFVNTVkKWyAgIDExLjIwNDgwMF0gYXRhNTog U0FUQSBtYXggVURNQS8xMzMgYWJhciBtMjA0OEAweGYyNjI4MDAwIHBvcnQgMHhmMjYyODMwMCBp cnEgMzA0ClsgICAxMS4yMTI3MDBdIGF0YTY6IERVTU1ZClsgICAxMS4zMjI2NjBdIHVzYiAxLTEu NDogbmV3IGZ1bGwgc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNCB1c2luZyBlaGNpX2hjZApbICAg MTEuNTM0MzE0XSBhdGExOiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250 cm9sIDMwMCkKWyAgIDExLjU0MzQwN10gYXRhMS4wMDogQUNQSSBjbWQgZWYvMDI6MDA6MDA6MDA6 MDA6YTAgKFNFVCBGRUFUVVJFUykgc3VjY2VlZGVkClsgICAxMS41NTA2OTBdIGF0YTEuMDA6IEFD UEkgY21kIGY1LzAwOjAwOjAwOjAwOjAwOmEwIChTRUNVUklUWSBGUkVFWkUgTE9DSykgZmlsdGVy ZWQgb3V0ClsgICAxMS41NTkwNDBdIGF0YTEuMDA6IEFDUEkgY21kIGVmLzEwOjAzOjAwOjAwOjAw OmEwIChTRVQgRkVBVFVSRVMpIGZpbHRlcmVkIG91dApbICAgMTEuNTY5MTY2XSBhdGExLjAwOiBB VEEtODogU1QzMjBMVDAwMC05VkwxNDIsIDAwMDNMVk0xLCBtYXggVURNQS8xMzMKWyAgIDExLjU3 NTkxNl0gYXRhMS4wMDogNjI1MTQyNDQ4IHNlY3RvcnMsIG11bHRpIDE2OiBMQkE0OCBOQ1EgKGRl cHRoIDMxLzMyKQpbICAgMTEuNTg2MDE5XSBhdGExLjAwOiBBQ1BJIGNtZCBlZi8wMjowMDowMDow MDowMDphMCAoU0VUIEZFQVRVUkVTKSBzdWNjZWVkZWQKWyAgIDExLjU5MzMxNF0gYXRhMS4wMDog QUNQSSBjbWQgZjUvMDA6MDA6MDA6MDA6MDA6YTAgKFNFQ1VSSVRZIEZSRUVaRSBMT0NLKSBmaWx0 ZXJlZCBvdXQKWyAgIDExLjYwMTY2Ml0gYXRhMS4wMDogQUNQSSBjbWQgZWYvMTA6MDM6MDA6MDA6 MDA6YTAgKFNFVCBGRUFUVVJFUykgZmlsdGVyZWQgb3V0ClsgICAxMS42MTE4MDBdIGF0YTEuMDA6 IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzClsgICAxMS42MTY0MjBdIHNjc2kgMDowOjA6MDogRGly ZWN0LUFjY2VzcyAgICAgQVRBICAgICAgU1QzMjBMVDAwMC05VkwxNCAwMDAzIFBROiAwIEFOU0k6 IDUKWyAgIDExLjYyNTA0OF0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0 eXBlIDAKWyAgIDExLjYyNTA1M10gc2QgMDowOjA6MDogW3NkYV0gNjI1MTQyNDQ4IDUxMi1ieXRl IGxvZ2ljYWwgYmxvY2tzOiAoMzIwIEdCLzI5OCBHaUIpClsgICAxMS42MjUxMDhdIHNkIDA6MDow OjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAxMS42MjUxMTBdIHNkIDA6MDowOjA6 IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAxMS42MjUxMzNdIHNkIDA6MDowOjA6 IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBkb2Vzbid0 IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgMTEuNjcxOTczXSAgc2RhOiBzZGExIHNkYTIgc2RhMyBz ZGE0IDwgc2RhNSBzZGE2IHNkYTcgPgpbICAgMTEuNjc3ODY3XSBzZCAwOjA6MDowOiBbc2RhXSBB dHRhY2hlZCBTQ1NJIGRpc2sKWyAgIDExLjk3ODI5OV0gYXRhMjogU0FUQSBsaW5rIGRvd24gKFNT dGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAxMi4zMDYyOTldIGF0YTU6IFNBVEEgbGluayBkb3du IChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgMTIuOTkwNzAzXSBFWFQ0LWZzIChzZGE3KTog bW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpm c2NrIGZyb20gdXRpbC1saW51eCAyLjE5LjEKZnNjayBmcm9tIHV0aWwtbGludXggMi4xOS4xCi9k ZXYvc2RhNzogY2xlYW4sIDg5Mzc4OS8xNDkyNTgyNCBmaWxlcywgMjkxNjA0NDIvNTk2Nzc0NDAg YmxvY2tzIChjaGVjayBpbiA0IG1vdW50cykKL2Rldi9zZGE1OiBjbGVhbiwgMjc0LzYyMjQ4IGZp bGVzLCA3NjU0NS8yNDg4MzIgYmxvY2tzIChjaGVjayBpbiA0IG1vdW50cykKU2tpcHBpbmcgcHJv ZmlsZSBpbiAvZXRjL2FwcGFybW9yLmQvZGlzYWJsZTogdXNyLmJpbi5maXJlZm94CiAqIFN0YXJ0 aW5nIG1ETlMvRE5TLVNEIGRhZW1vbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbIE9LIF0KICogU3RhcnRpbmcgQXBwQXJtb3IgcHJvZmlsZXMgICAgICAgKFhFTikg Q2Fubm90IGJpbmQgSVJRMTkgdG8gZG9tMC4gSW4gdXNlIGJ5ICduczE2NTUwJy4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFsgT0sgXSAKICogU3RvcHBpbmcgRmFpbHNhZmUgQm9vdCBEZWxheSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgT0sgXQogKiBTdG9wcGluZyBTeXN0ZW0g ViBpbml0aWFsaXNhdGlvbiBjb21wYXRpYmlsaXR5ICAgICAgICAgICAgICAgICAgICAgICAgWyBP SyBdCiAqIFN0YXJ0aW5nIFN5c3RlbSBWIHJ1bmxldmVsIGNvbXBhdGliaWxpdHkgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3RvcHBpbmcgYXV0b21hdGljIGNyYXNoIHJl cG9ydCBnZW5lcmF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtmYWlsXQogKiBTdGFy dGluZyBMaWdodERNIERpc3BsYXkgTWFuYWdlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIHNhdmUga2VybmVsIG1lc3NhZ2VzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3RhcnRpbmcgS1ZNICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsg T0sgXQogKiBTdGFydGluZyBhbmFjKGgpcm9uaXN0aWMgY3JvbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIEFDUEkgZGFlbW9uICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0KICogU3Rh cnRpbmcgcmVndWxhciBiYWNrZ3JvdW5kIHByb2dyYW0gcHJvY2Vzc2luZyBkYWVtb24gICAgICAg ICAgICAgICAgIFsgT0sgXQogKiBTdGFydGluZyBkZWZlcnJlZCBleGVjdXRpb24gc2NoZWR1bGVy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBPSyBdCiAqIFN0YXJ0aW5nIENQVSBp bnRlcnJ1cHRzIGJhbGFuY2luZyBkYWVtb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb IE9LIF0KICogU3RhcnRpbmcgQ1BVIGludGVycnVwdHMgYmFsYW5jaW5nIGRhZW1vbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtmYWlsXQpTdGFydGluZyBveGVuc3RvcmVkLi4uICogU3Rv cHBpbmcgc2F2ZSBrZXJuZWwgbWVzc2FnZXMgICAgICAgICAgICAgICAgICAgWyBPSyBdClsgICAz MS42NTM0NDFdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAzMS42NTgwMTRd IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlClsgICAzMS42NjI2ODFdIFgKRU5CVVM6 IFVuYWJsZSB0b1NldHRpbmcgZG9tYWluIDAgbmFtZS4uLiByZWFkIGNwdSBzdGF0ZQoKWyAgIDMx LjY2OTk5MF0gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKU3RhcnRpbmcgeGVuY29u c29sZWQuLi4Kc3BlZWNoLWRpc3BhdGNoZXIgZGlzYWJsZWQ7IGVkaXQgL2V0Yy9kZWZhdWx0L3Nw ZWVjaC1kaXNwYXRjaGVyCkNoZWNraW5nIGZvciBydW5uaW5nIHVuYXR0ZW5kZWQtdXBncmFkZXM6 IAogKiBTdGFydGluZyBWaXJ0dWFsQm94IGtlcm5lbCBtb2R1bGVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgWyBPSyBdIApTdGFydGluZyBkb21haW4gd2F0Y2hkb2cgZGFlbW9u OiAgKiB4ZW53YXRjaGRvZ2Qgc3RhcnR1cAoKICogU3RhcnRpbmcgYmx1ZXRvb3RoICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgT0sgXSAKICogUHVs c2VBdWRpbyBjb25maWd1cmVkIGZvciBwZXItdXNlciBzZXNzaW9ucwpzYW5lZCBkaXNhYmxlZDsg ZWRpdCAvZXRjL2RlZmF1bHQvc2FuZWQKCiAqIENoZWNraW5nIGJhdHRlcnkgc3RhdGUuLi4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIE9LIF0gCihYRU4pIENh bm5vdCBiaW5kIElSUTE5IHRvIGRvbTAuIEluIHVzZSBieSAnbnMxNjU1MCcuCihYRU4pIEhWTTE6 IEhWTSBMb2FkZXIKKFhFTikgSFZNMTogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKKFhFTikg SFZNMTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDMKKFhFTikgSFZN MTogU3lzdGVtIHJlcXVlc3RlZCBST01CSU9TCihYRU4pIEhWTTE6IENQVSBzcGVlZCBpcyAyNjkx IE1IegooWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQooWEVO KSBIVk0xOiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQooWEVOKSBpcnEuYzoyNzA6IERv bTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDEg cm91dGVkIHRvIElSUTEwCihYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQg MCAtPiAxMQooWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKKFhFTikg aXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKFhFTikgSFZNMTogUENJ LUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwMToyIElOVEQt PklSUTUKKFhFTikgSFZNMTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCihYRU4pIEhWTTE6IHBj aSBkZXYgMDM6MCBJTlRBLT5JUlE1CihYRU4pIEhWTTE6IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6 ZSAwMTAwMDAwMDogZjAwMDAwMDgKKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBzaXpl IDAxMDAwMDAwOiBmMTAwMDAwOAooWEVOKSBIVk0xOiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUg MDAwMDAxMDA6IDAwMDBjMDAxCihYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSAw MDAwMDAyMDogMDAwMGMxMDEKKFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAw MDAwMDEwOiAwMDAwYzEyMQooWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv bjoKKFhFTikgSFZNMTogIC0gQ1BVMCAuLi4gMzYtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4u LiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIEhWTTE6IFRlc3RpbmcgSFZNIGVudmly b25tZW50OgooWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4u LiBwYXNzZWQKKFhFTikgSFZNMTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3Nl ZAooWEVOKSBIVk0xOiBQYXNzZWQgMiBvZiAyIHRlc3RzCihYRU4pIEhWTTE6IFdyaXRpbmcgU01C SU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMTogTG9hZGluZyBST01CSU9TIC4uLgooWEVOKSBIVk0x OiAxMjYzNiBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6CihYRU4pIEhW TTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAxMDAwLTB4ZmMwMDQxNWMgLi4uIGRvbmUKKFhFTikg SFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooWEVOKSBIVk0xOiBMb2FkaW5nIFN0YW5kYXJk IFZHQUJJT1MgLi4uCihYRU4pIEhWTTE6IE9wdGlvbiBST01zOgooWEVOKSBIVk0xOiAgYzAwMDAt YzlmZmY6IFZHQSBCSU9TCihYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KKFhFTikgSFZNMTog dm04NiBUU1MgYXQgZmMwMTAyODAKKFhFTikgSFZNMTogQklPUyBtYXA6CihYRU4pIEhWTTE6ICBm MDAwMC1mZmZmZjogTWFpbiBCSU9TCihYRU4pIEhWTTE6IEU4MjAgdGFibGU6CihYRU4pIEhWTTE6 ICBbMDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0KKFhFTikg SFZNMTogIFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VS VkVECihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw MDAwCihYRU4pIEhWTTE6ICBbMDJdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAw MDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw MDAwMDoxZjAwMDAwMDogUkFNCihYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDoxZjAwMDAwMCAt IDAwMDAwMDAwOmZjMDAwMDAwCihYRU4pIEhWTTE6ICBbMDRdOiAwMDAwMDAwMDpmYzAwMDAwMCAt IDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRAooWEVOKSBIVk0xOiBJbnZva2luZyBST01CSU9T IC4uLgooWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6 MzI6MjkgJAooWEVOKSBzdGR2Z2EuYzoxNDc6ZDEgZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5n IG1vZGVzCihYRU4pIEhWTTE6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEv MjcgMDk6NDQ6MTIgdnJ1cHBlcnQgRXhwICQKKFhFTikgSFZNMTogVkJFIEJpb3MgJElkOiB2YmUu Yyx2IDEuNjAgMjAwOC8wMy8wMiAwNzo0NzoyMSB2cnVwcGVydCBFeHAgJAooWEVOKSBIVk0xOiBC b2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5CihYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEg JCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkCihYRU4pIEhWTTE6IE9wdGlvbnM6IGFwbWJp b3MgcGNpYmlvcyBlbHRvcml0byBQTU0gCihYRU4pIEhWTTE6IAooWEVOKSBIVk0xOiBhdGEwLTA6 IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMKKFhFTikg SFZNMTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgxMDAwMCBN Qnl0ZXMpCihYRU4pIEhWTTE6IElERSB0aW1lIG91dAooWEVOKSBIVk0xOiAKKFhFTikgSFZNMTog CihYRU4pIEhWTTE6IAooWEVOKSBIVk0xOiBQcmVzcyBGMTIgZm9yIGJvb3QgbWVudS4KKFhFTikg SFZNMTogCihYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKFhFTikgSFZNMTog Qm9vdGluZyBmcm9tIDAwMDA6N2MwMAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rp b24gNDEsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0xOiBpbnQxM19oYXJk ZGlzazogZnVuY3Rpb24gMDgsIHVubWFwcGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0x OiAqKiogaW50IDE1aCBmdW5jdGlvbiBBWD0wMGMwLCBCWD0wMDAwIG5vdCB5ZXQgc3VwcG9ydGVk IQooWEVOKSBIVk0yOiBIVk0gTG9hZGVyCihYRU4pIEhWTTI6IERldGVjdGVkIFhlbiB2NC4yLXVu c3RhYmxlCihYRU4pIEhWTTI6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5l bCA0CihYRU4pIEhWTTI6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwooWEVOKSBIVk0yOiBDUFUg c3BlZWQgaXMgMjY5MSBNSHoKKFhFTikgaXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDAgY2hhbmdl ZCAwIC0+IDUKKFhFTikgSFZNMjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKKFhFTikg aXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihYRU4pIEhWTTI6IFBD SS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAooWEVOKSBpcnEuYzoyNzA6IERvbTIgUENJIGxp bmsgMiBjaGFuZ2VkIDAgLT4gMTEKKFhFTikgSFZNMjogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRv IElSUTExCihYRU4pIGlycS5jOjI3MDogRG9tMiBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1CihY RU4pIEhWTTI6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1CihYRU4pIEhWTTI6IHBjaSBk ZXYgMDE6MiBJTlRELT5JUlE1CihYRU4pIEhWTTI6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAoo WEVOKSBIVk0yOiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQooWEVOKSBIVk0yOiBwY2kgZGV2IDA0 OjAgSU5UQS0+SVJRNQooWEVOKSBIVk0yOiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgMDEwMDAw MDA6IGYwMDAwMDA4CihYRU4pIEhWTTI6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAw MDogZjEwMDAwMDgKKFhFTikgSFZNMjogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMDAwMTAw OiAwMDAwYzAwMQooWEVOKSBIVk0yOiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6 IDAwMDBjMTAxCihYRU4pIEhWTTI6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDEwMDog ZjIwMDAwMDAKKFhFTikgSFZNMjogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAwMDAwMDIwOiAw MDAwYzIwMQooWEVOKSBIVk0yOiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAw MDBjMjIxCihYRU4pIEhWTTI6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOgooWEVOKSBI Vk0yOiAgLSBDUFUwIC4uLiAzNi1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMi84XSAuLi4gZG9uZS4KKFhFTikgSFZNMjogIC0gQ1BVMSAuLi4gMzYtYml0IHBoeXMgLi4u IGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIEhWTTI6IFRl c3RpbmcgSFZNIGVudmlyb25tZW50OgooWEVOKSBIVk0yOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFn ZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKKFhFTikgSFZNMjogIC0gR1MgYmFzZSBNU1JzIGFuZCBT V0FQR1MgLi4uIHBhc3NlZAooWEVOKSBIVk0yOiBQYXNzZWQgMiBvZiAyIHRlc3RzCihYRU4pIEhW TTI6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KKFhFTikgSFZNMjogTG9hZGluZyBST01CSU9T IC4uLgooWEVOKSBIVk0yOiAxMjYzNiBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVu c2lvbnM6CihYRU4pIEhWTTI6ICAgUmVsb2NhdGluZyB0byAweGZjMDAxMDAwLTB4ZmMwMDQxNWMg Li4uIGRvbmUKKFhFTikgSFZNMjogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgooWEVOKSBIVk0yOiBM b2FkaW5nIFN0YW5kYXJkIFZHQUJJT1MgLi4uCihYRU4pIEhWTTI6IExvYWRpbmcgUENJIE9wdGlv biBST00gLi4uCihYRU4pIEhWTTI6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnCihY RU4pIEhWTTI6ICAtIFByb2R1Y3QgbmFtZTogaVBYRQooWEVOKSBIVk0yOiBPcHRpb24gUk9NczoK KFhFTikgSFZNMjogIGMwMDAwLWM5ZmZmOiBWR0EgQklPUwooWEVOKSBIVk0yOiAgY2EwMDAtZDlm ZmY6IEV0aGVyYm9vdCBST00KKFhFTikgSFZNMjogTG9hZGluZyBBQ1BJIC4uLgooWEVOKSBIVk0y OiB2bTg2IFRTUyBhdCBmYzAxMDI4MAooWEVOKSBIVk0yOiBCSU9TIG1hcDoKKFhFTikgSFZNMjog IGYwMDAwLWZmZmZmOiBNYWluIEJJT1MKKFhFTikgSFZNMjogRTgyMCB0YWJsZToKKFhFTikgSFZN MjogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQooWEVO KSBIVk0yOiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVT RVJWRUQKKFhFTikgSFZNMjogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAw ZTAwMDAKKFhFTikgSFZNMjogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAx MDAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTI6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAw MDAwMDAwOjNmMDAwMDAwOiBSQU0KKFhFTikgSFZNMjogIEhPTEU6IDAwMDAwMDAwOjNmMDAwMDAw IC0gMDAwMDAwMDA6ZmMwMDAwMDAKKFhFTikgSFZNMjogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAw IC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihYRU4pIEhWTTI6IEludm9raW5nIFJPTUJJ T1MgLi4uCihYRU4pIEhWTTI6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAx NzozMjoyOSAkCihYRU4pIHN0ZHZnYS5jOjE0NzpkMiBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hp bmcgbW9kZXMKKFhFTikgSFZNMjogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8w MS8yNyAwOTo0NDoxMiB2cnVwcGVydCBFeHAgJAooWEVOKSBIVk0yOiBWQkUgQmlvcyAkSWQ6IHZi ZS5jLHYgMS42MCAyMDA4LzAzLzAyIDA3OjQ3OjIxIHZydXBwZXJ0IEV4cCAkCihYRU4pIEhWTTI6 IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkKKFhFTikgSFZNMjogJFJldmlzaW9uOiAxLjIy MSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKKFhFTikgSFZNMjogT3B0aW9uczogYXBt YmlvcyBwY2liaW9zIGVsdG9yaXRvIFBNTSAKKFhFTikgSFZNMjogCihYRU4pIEhWTTI6IGF0YTAt MDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82MwooWEVO KSBIVk0yOiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDIwMDAw IE1CeXRlcykKKFhFTikgSFZNMjogSURFIHRpbWUgb3V0CihYRU4pIEhWTTI6IAooWEVOKSBIVk0y OiAKKFhFTikgSFZNMjogCihYRU4pIEhWTTI6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51LgooWEVO KSBIVk0yOiAKKFhFTikgSFZNMjogQm9vdGluZyBmcm9tIENELVJvbS4uLgooWEVOKSBIVk0yOiBD RFJPTSBib290IGZhaWx1cmUgY29kZSA6IDAwMDIKKFhFTikgSFZNMjogQm9vdCBmcm9tIENELVJv bSBmYWlsZWQ6IGNvdWxkIG5vdCByZWFkIHRoZSBib290IGRpc2sKKFhFTikgSFZNMjogCihYRU4p IEhWTTI6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KKFhFTikgSFZNMjogQm9vdGluZyBmcm9t IDAwMDA6N2MwMAooWEVOKSBIVk0xOiBpbnQxM19oYXJkZGlzazogZnVuY3Rpb24gMTUsIHVubWFw cGVkIGRldmljZSBmb3IgRUxETD04MQooWEVOKSBIVk0xOiAqKiogaW50IDE1aCBmdW5jdGlvbiBB WD1lYzAwLCBCWD0wMDAyIG5vdCB5ZXQgc3VwcG9ydGVkIQooWEVOKSBIVk0xOiBLQkQ6IHVuc3Vw cG9ydGVkIGludCAxNmggZnVuY3Rpb24gMDMKKFhFTikgSFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1 bmN0aW9uIDE1LCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVMREw9ODEKKFhFTikgSFZNMTogaW50MTNf aGFyZGRpc2s6IGZ1bmN0aW9uIDAyLCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVMREw9ODEKKFhFTikg SFZNMTogaW50MTNfaGFyZGRpc2s6IGZ1bmN0aW9uIDQxLCB1bm1hcHBlZCBkZXZpY2UgZm9yIEVM REw9ODEKKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKKFhF TikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCihYRU4pIGlycS5j OjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERv bTEgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMAooWEVOKSBpcnEuYzozNTA6IERvbTEgY2FsbGJh Y2sgdmlhIGNoYW5nZWQgdG8gUENJIElOVHggRGV2IDB4MDMgSW50QQooWEVOKSBpcnEuYzoyNzA6 IERvbTIgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAooWEVOKSBpcnEuYzoyNzA6IERvbTIgUENJ IGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKKFhFTikgaXJxLmM6MjcwOiBEb20yIFBDSSBsaW5rIDIg Y2hhbmdlZCAxMSAtPiAwCihYRU4pIGlycS5jOjI3MDogRG9tMiBQQ0kgbGluayAzIGNoYW5nZWQg NSAtPiAwCihYRU4pICoqKiBJUlEgQlVHIGZvdW5kICoqKgooWEVOKSBDUFUwIC1UZXN0aW5nIHZl Y3RvciAyMzYgZnJvbSBiaXRtYXAgNDEsNDksNjQsNzIsODAsODIsODQsODgsOTYsOTgsMTA0LDEy MCwxMjMsMTM2LDE0NSwxNTIsMTYwLDE2OCwxOTIsMjAwLTIwMSwyMjMKKFhFTikgR3Vlc3QgaW50 ZXJydXB0IGluZm9ybWF0aW9uOgooWEVOKSAgICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAg dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZAooWEVO KSAgICBJUlE6ICAgMSBhZmZpbml0eTowMiB2ZWM6N2IgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh dHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICAxKC0tLS0pLAooWEVOKSAg ICBJUlE6ICAgMiBhZmZpbml0eTpmZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVz PTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgMyBhZmZpbml0eTowMSB2 ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu ZAooWEVOKSAgICBJUlE6ICAgNCBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVkZ2Ug ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgNSBhZmZp bml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl ZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NTggdHlwZT1JTy1B UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6 ICAgNyBhZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAw MDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJUlE6ICAgOCBhZmZpbml0eTowOCB2ZWM6Mjkg dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1s aXN0PTA6ICA4KC0tLS0pLAooWEVOKSAgICBJUlE6ICAgOSBhZmZpbml0eTowMSB2ZWM6OTEgdHlw ZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDMwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0 PTA6ICA5KC0tLS0pLAooWEVOKSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6NzggdHlwZT1J Ty1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZAooWEVOKSAgICBJ UlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw MDAwMDAyIG1hcHBlZCwgdW5ib3VuZAoKCg== --20cf3074d4fe662a8904bf4ebda6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3074d4fe662a8904bf4ebda6-- From xen-devel-bounces@lists.xen.org Sat May 05 23:23:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 23: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 ) id 1SQoJO-0008OE-97; Sat, 05 May 2012 23:22:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQoJM-0008O8-Np for xen-devel@lists.xensource.com; Sat, 05 May 2012 23:22:48 +0000 Received: from [85.158.138.51:34665] by server-10.bemta-3.messagelabs.com id DF/26-29478-746B5AF4; Sat, 05 May 2012 23:22:47 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336260166!25527130!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3592 invoked from network); 5 May 2012 23:22:46 -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; 5 May 2012 23:22:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,537,1330905600"; d="scan'208";a="12313368" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 23:22:43 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 00:22:42 +0100 Date: Sun, 6 May 2012 00:19:26 +0100 From: Goncalo Gomes To: Message-ID: <20120505231926.GA8059@eire.uk.xensource.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline I'm currently working with xen-unstable changeset 25260:0f53540494f7 and trying to add a `vncviewer` type to the libxl_types.idl, but having difficulties understanding the root of a failure that occurs after I add my changes. Hopefully I enclose enough detail below, but if not, I'm happy to provide more information. I've created a small patch to add a 'vncviewer' bool type to the configuration parser of xl and based these changes on the "localtime" implementation part of c/s 25131, see below: diff -r 0f53540494f7 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/libxl_create.c Sat May 05 21:27:41 2012 +0000 @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) b_info->target_memkb = b_info->max_memkb; + libxl_defbool_setdefault(&b_info->vncviewer, false); libxl_defbool_setdefault(&b_info->localtime, false); libxl_defbool_setdefault(&b_info->disable_migrate, false); diff -r 0f53540494f7 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/libxl_types.idl Sat May 05 21:27:41 2012 +0000 @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain ("video_memkb", MemKB), ("shadow_memkb", MemKB), ("rtc_timeoffset", uint32), + ("vncviewer", libxl_defbool), ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), diff -r 0f53540494f7 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Sat May 05 21:27:41 2012 +0000 @@ -728,6 +728,7 @@ static void parse_config_data(const char if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) b_info->rtc_timeoffset = l; + xlu_cfg_get_defbool(config, "vncviewer", &b_info->localtime, 0); xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); if (!xlu_cfg_get_long (config, "videoram", &l, 0)) The outcome of this patch when applied and compiled in is that xl aborts during the parse_config_data() call in the create_domain(). # ./xl create win7 Parsing config file win7 Aborted This abort is the `default` case in the switch at xl_cmdimpl.c:736, which gets triggered from an erroneous b_info->type with a bogus value of 0x84 (which is neither PV nor HVM.) For reference, the backtrace is: (gdb) bt #0 0xb7fe2416 in __kernel_vsyscall () #1 0xb7e28781 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7e2bbb2 in *__GI_abort () at abort.c:92 #3 0x0804fe4b in parse_config_data (configfile_filename_report=, configfile_data=, configfile_len=250, d_config=0xbffff55c) at xl_cmdimpl.c:841 #4 0x080526ba in create_domain (dom_info=) at xl_cmdimpl.c:1646 #5 0x0805c098 in main_create (argc=2, argv=0xbffffcc8) at xl_cmdimpl.c:3470 #6 0x0804cfe4 in main (argc=3, argv=0xbffffcc4) at xl.c:176 I've also attached the win7 config file which I'm using, in case this is a side effect of something wrong in config file itself (I should add that it's mostly copied from an example and it successfully creates a win7 domain without my patch applied.) Any guesses or suggestions how to troubleshoot this further would be greatly appreciated. Thanks, Goncalo --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="win7" builder = "hvm" name = "win7" memory = 1024 acpi = 1 apic = 1 disk = [ 'file:/root/vm/win7/disk1.img,hda,w', 'file:/root/win7.iso,hdc:cdrom,r' ] device_model = "/usr/lib/xen/bin/qemu-dm" boot="dca" kernel = "/usr/lib/xen/boot/hvmloader" vncviewer=1 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --FL5UXtIhxfXey3p5-- From xen-devel-bounces@lists.xen.org Sat May 05 23:23:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 May 2012 23: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 ) id 1SQoJO-0008OE-97; Sat, 05 May 2012 23:22:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQoJM-0008O8-Np for xen-devel@lists.xensource.com; Sat, 05 May 2012 23:22:48 +0000 Received: from [85.158.138.51:34665] by server-10.bemta-3.messagelabs.com id DF/26-29478-746B5AF4; Sat, 05 May 2012 23:22:47 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336260166!25527130!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3592 invoked from network); 5 May 2012 23:22:46 -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; 5 May 2012 23:22:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,537,1330905600"; d="scan'208";a="12313368" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 May 2012 23:22:43 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 00:22:42 +0100 Date: Sun, 6 May 2012 00:19:26 +0100 From: Goncalo Gomes To: Message-ID: <20120505231926.GA8059@eire.uk.xensource.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline I'm currently working with xen-unstable changeset 25260:0f53540494f7 and trying to add a `vncviewer` type to the libxl_types.idl, but having difficulties understanding the root of a failure that occurs after I add my changes. Hopefully I enclose enough detail below, but if not, I'm happy to provide more information. I've created a small patch to add a 'vncviewer' bool type to the configuration parser of xl and based these changes on the "localtime" implementation part of c/s 25131, see below: diff -r 0f53540494f7 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/libxl_create.c Sat May 05 21:27:41 2012 +0000 @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) b_info->target_memkb = b_info->max_memkb; + libxl_defbool_setdefault(&b_info->vncviewer, false); libxl_defbool_setdefault(&b_info->localtime, false); libxl_defbool_setdefault(&b_info->disable_migrate, false); diff -r 0f53540494f7 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/libxl_types.idl Sat May 05 21:27:41 2012 +0000 @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain ("video_memkb", MemKB), ("shadow_memkb", MemKB), ("rtc_timeoffset", uint32), + ("vncviewer", libxl_defbool), ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), diff -r 0f53540494f7 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 04 11:18:48 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Sat May 05 21:27:41 2012 +0000 @@ -728,6 +728,7 @@ static void parse_config_data(const char if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) b_info->rtc_timeoffset = l; + xlu_cfg_get_defbool(config, "vncviewer", &b_info->localtime, 0); xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); if (!xlu_cfg_get_long (config, "videoram", &l, 0)) The outcome of this patch when applied and compiled in is that xl aborts during the parse_config_data() call in the create_domain(). # ./xl create win7 Parsing config file win7 Aborted This abort is the `default` case in the switch at xl_cmdimpl.c:736, which gets triggered from an erroneous b_info->type with a bogus value of 0x84 (which is neither PV nor HVM.) For reference, the backtrace is: (gdb) bt #0 0xb7fe2416 in __kernel_vsyscall () #1 0xb7e28781 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7e2bbb2 in *__GI_abort () at abort.c:92 #3 0x0804fe4b in parse_config_data (configfile_filename_report=, configfile_data=, configfile_len=250, d_config=0xbffff55c) at xl_cmdimpl.c:841 #4 0x080526ba in create_domain (dom_info=) at xl_cmdimpl.c:1646 #5 0x0805c098 in main_create (argc=2, argv=0xbffffcc8) at xl_cmdimpl.c:3470 #6 0x0804cfe4 in main (argc=3, argv=0xbffffcc4) at xl.c:176 I've also attached the win7 config file which I'm using, in case this is a side effect of something wrong in config file itself (I should add that it's mostly copied from an example and it successfully creates a win7 domain without my patch applied.) Any guesses or suggestions how to troubleshoot this further would be greatly appreciated. Thanks, Goncalo --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="win7" builder = "hvm" name = "win7" memory = 1024 acpi = 1 apic = 1 disk = [ 'file:/root/vm/win7/disk1.img,hda,w', 'file:/root/win7.iso,hdc:cdrom,r' ] device_model = "/usr/lib/xen/bin/qemu-dm" boot="dca" kernel = "/usr/lib/xen/boot/hvmloader" vncviewer=1 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --FL5UXtIhxfXey3p5-- From xen-devel-bounces@lists.xen.org Sun May 06 06:11:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 06:11:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQufi-0006OJ-Jq; Sun, 06 May 2012 06:10:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQufg-0006OE-TB for xen-devel@lists.xensource.com; Sun, 06 May 2012 06:10:17 +0000 Received: from [85.158.138.51:63002] by server-7.bemta-3.messagelabs.com id 4D/20-03078-7C516AF4; Sun, 06 May 2012 06:10:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336284615!25473861!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4Mw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5205 invoked from network); 6 May 2012 06:10:15 -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; 6 May 2012 06:10:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330905600"; d="scan'208";a="12314187" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 06:10: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, 6 May 2012 07:10:13 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQufd-0006W1-IE; Sun, 06 May 2012 06:10:13 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQufd-00036I-GO; Sun, 06 May 2012 07:10:13 +0100 To: Message-ID: From: xen.org Date: Sun, 6 May 2012 07:10:13 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12792: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12792 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12792/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail pass in 12791 test-amd64-amd64-pv 9 guest-start fail in 12791 pass in 12792 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12791 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 06:11:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 06:11:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQufi-0006OJ-Jq; Sun, 06 May 2012 06:10:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQufg-0006OE-TB for xen-devel@lists.xensource.com; Sun, 06 May 2012 06:10:17 +0000 Received: from [85.158.138.51:63002] by server-7.bemta-3.messagelabs.com id 4D/20-03078-7C516AF4; Sun, 06 May 2012 06:10:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336284615!25473861!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4Mw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5205 invoked from network); 6 May 2012 06:10:15 -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; 6 May 2012 06:10:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330905600"; d="scan'208";a="12314187" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 06:10: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, 6 May 2012 07:10:13 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SQufd-0006W1-IE; Sun, 06 May 2012 06:10:13 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SQufd-00036I-GO; Sun, 06 May 2012 07:10:13 +0100 To: Message-ID: From: xen.org Date: Sun, 6 May 2012 07:10:13 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12792: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12792 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12792/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail pass in 12791 test-amd64-amd64-pv 9 guest-start fail in 12791 pass in 12792 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12791 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 07:36:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 07: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 ) id 1SQw0a-0006wf-Ey; Sun, 06 May 2012 07:35:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQw0Y-0006wa-4j for xen-devel@lists.xensource.com; Sun, 06 May 2012 07:35:54 +0000 Received: from [193.109.254.147:40739] by server-2.bemta-14.messagelabs.com id 44/F7-19409-9D926AF4; Sun, 06 May 2012 07:35:53 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336289751!7839217!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MDg5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17473 invoked from network); 6 May 2012 07:35:52 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-16.tower-27.messagelabs.com with SMTP; 6 May 2012 07:35:52 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 06 May 2012 00:35:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139416584" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 06 May 2012 00:35:50 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 00:35:50 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Sun, 6 May 2012 15:35:48 +0800 From: "Hao, Xudong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnA= Date: Sun, 6 May 2012 07:35:47 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> In-Reply-To: <20120504132046.GD26418@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, May 04, 2012 9:21 PM > To: Hao, Xudong > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > guest with device assigned can be benefitted. > > > > Changes from v1: > > - put the variable definition at the start of function > > - add error log report > > > > Don't you need to disable this when the device is un-assigned from the guest? > I don't think this need to be disabled when device is un-assigned from guest. If host want to use device again, the host device driver need re-load, so whether disabling ltr/obff is up to host device driver. > > Signed-off-by: Xudong Hao > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > b/drivers/xen/xen-pciback/pci_stub.c > > index 097e536..74fbf23 100644 > > --- a/drivers/xen/xen-pciback/pci_stub.c > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > pci_dev *dev) > > struct xen_pcibk_dev_data *dev_data; > > int err = 0; > > > > + /* set default value */ > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > Why these values? Is there a way to fetch optimal values? These values is the max value that the register supported. I've no idea to get an optimal value, here it just be set max value as default. > > + > > dev_dbg(&dev->dev, "initializing...\n"); > > > > /* The PCI backend is not intended to be a module (or to work with > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > pci_dev *dev) > > dev_dbg(&dev->dev, "reset device\n"); > > xen_pcibk_reset_device(dev); > > > > + /* Enable LTR and OBFF before do device assignment */ > > + /* LTR(Latency tolerance reporting) allows devices to send > > + * messages to the root complex indicating their latency tolerance > > + * for snooped & unsnooped memory transactions. > > + */ > > + err = pci_enable_ltr(dev); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > + > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > + if (err) > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > + > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > + * improve energy efficiency by giving devices information about > > + * when interrupts and other activity will have a reduced power > > + * impact. > > + */ > > + err = pci_enable_obff(dev, type); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > + > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > return 0; > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 07:36:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 07: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 ) id 1SQw0a-0006wf-Ey; Sun, 06 May 2012 07:35:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQw0Y-0006wa-4j for xen-devel@lists.xensource.com; Sun, 06 May 2012 07:35:54 +0000 Received: from [193.109.254.147:40739] by server-2.bemta-14.messagelabs.com id 44/F7-19409-9D926AF4; Sun, 06 May 2012 07:35:53 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336289751!7839217!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MDg5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17473 invoked from network); 6 May 2012 07:35:52 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-16.tower-27.messagelabs.com with SMTP; 6 May 2012 07:35:52 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 06 May 2012 00:35:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139416584" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 06 May 2012 00:35:50 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 00:35:50 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Sun, 6 May 2012 15:35:48 +0800 From: "Hao, Xudong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnA= Date: Sun, 6 May 2012 07:35:47 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> In-Reply-To: <20120504132046.GD26418@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, May 04, 2012 9:21 PM > To: Hao, Xudong > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > guest with device assigned can be benefitted. > > > > Changes from v1: > > - put the variable definition at the start of function > > - add error log report > > > > Don't you need to disable this when the device is un-assigned from the guest? > I don't think this need to be disabled when device is un-assigned from guest. If host want to use device again, the host device driver need re-load, so whether disabling ltr/obff is up to host device driver. > > Signed-off-by: Xudong Hao > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > b/drivers/xen/xen-pciback/pci_stub.c > > index 097e536..74fbf23 100644 > > --- a/drivers/xen/xen-pciback/pci_stub.c > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > pci_dev *dev) > > struct xen_pcibk_dev_data *dev_data; > > int err = 0; > > > > + /* set default value */ > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > Why these values? Is there a way to fetch optimal values? These values is the max value that the register supported. I've no idea to get an optimal value, here it just be set max value as default. > > + > > dev_dbg(&dev->dev, "initializing...\n"); > > > > /* The PCI backend is not intended to be a module (or to work with > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > pci_dev *dev) > > dev_dbg(&dev->dev, "reset device\n"); > > xen_pcibk_reset_device(dev); > > > > + /* Enable LTR and OBFF before do device assignment */ > > + /* LTR(Latency tolerance reporting) allows devices to send > > + * messages to the root complex indicating their latency tolerance > > + * for snooped & unsnooped memory transactions. > > + */ > > + err = pci_enable_ltr(dev); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > + > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > + if (err) > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > + > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > + * improve energy efficiency by giving devices information about > > + * when interrupts and other activity will have a reduced power > > + * impact. > > + */ > > + err = pci_enable_obff(dev, type); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > + > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > return 0; > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 08:12:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 08: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 ) id 1SQwYj-0007bz-8x; Sun, 06 May 2012 08:11:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQwYi-0007bu-KF for xen-devel@lists.xen.org; Sun, 06 May 2012 08:11:12 +0000 Received: from [193.109.254.147:8274] by server-4.bemta-14.messagelabs.com id 40/4D-11570-F1236AF4; Sun, 06 May 2012 08:11:11 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336291870!7824516!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMDYy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2220 invoked from network); 6 May 2012 08:11:11 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-27.messagelabs.com with SMTP; 6 May 2012 08:11:11 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 06 May 2012 01:11:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96888636" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 06 May 2012 01:11:09 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 01:11:07 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Sun, 6 May 2012 16:11:00 +0800 From: "Hao, Xudong" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//gGkA//xdGwA= Date: Sun, 6 May 2012 08:10:59 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> In-Reply-To: <4FA3AA540200007800081840@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: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Friday, May 04, 2012 4:07 PM > To: Hao, Xudong > Cc: xen-devel; konrad.wilk@oracle.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so > that > > guest with device assigned can be benefitted. > > > > Changes from v1: > > - put the variable definition at the start of function > > - add error log report > > > > Signed-off-by: Xudong Hao > > I continue to disagree to doing this always, unconditionally, with > hard-coded settings. If these features require explicit enabling, > there likely is something that drivers unaware of them could have > problems with - otherwise I would think these features would be > always enabled when a device supports them, and no options > would exist to control certain parameters. > I agree the driver control it, but it's difficult to let guest driver do it till now(because of PCIe emulation by qemu issue). > Plus, if the patch is nevertheless going to be acceptable, ... > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > pci_dev > > *dev) > > struct xen_pcibk_dev_data *dev_data; > > int err = 0; > > > > + /* set default value */ > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > + > > dev_dbg(&dev->dev, "initializing...\n"); > > > > /* The PCI backend is not intended to be a module (or to work with > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > pci_dev > > *dev) > > dev_dbg(&dev->dev, "reset device\n"); > > xen_pcibk_reset_device(dev); > > > > + /* Enable LTR and OBFF before do device assignment */ > > + /* LTR(Latency tolerance reporting) allows devices to send > > + * messages to the root complex indicating their latency tolerance > > + * for snooped & unsnooped memory transactions. > > + */ > > + err = pci_enable_ltr(dev); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > ... dev_err() here and below is certainly too severe, particularly for > the -ENOTSUPP cases. And the spelling would need fixing, especially > with it being broken exactly the same way a second time below. > dev_alert should be ok. Thanks for the careful review of typo "enable", I'll modify it in next version. > > + > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > What's the point of calling this function when pci_enable_ltr() failed? > Oh, thanks the point. It's unnecessary to call this function when pci_enable_ltr() failed indeed, I'll insert this calling in pci_enable_ltr() passing logical in next version. > Jan > > > + if (err) > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > + > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > + * improve energy efficiency by giving devices information about > > + * when interrupts and other activity will have a reduced power > > + * impact. > > + */ > > + err = pci_enable_obff(dev, type); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > + > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > return 0; > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 08:12:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 08: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 ) id 1SQwYj-0007bz-8x; Sun, 06 May 2012 08:11:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQwYi-0007bu-KF for xen-devel@lists.xen.org; Sun, 06 May 2012 08:11:12 +0000 Received: from [193.109.254.147:8274] by server-4.bemta-14.messagelabs.com id 40/4D-11570-F1236AF4; Sun, 06 May 2012 08:11:11 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336291870!7824516!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMDYy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2220 invoked from network); 6 May 2012 08:11:11 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-27.messagelabs.com with SMTP; 6 May 2012 08:11:11 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 06 May 2012 01:11:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="96888636" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 06 May 2012 01:11:09 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 01:11:07 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Sun, 6 May 2012 16:11:00 +0800 From: "Hao, Xudong" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//gGkA//xdGwA= Date: Sun, 6 May 2012 08:10:59 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> In-Reply-To: <4FA3AA540200007800081840@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: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Friday, May 04, 2012 4:07 PM > To: Hao, Xudong > Cc: xen-devel; konrad.wilk@oracle.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so > that > > guest with device assigned can be benefitted. > > > > Changes from v1: > > - put the variable definition at the start of function > > - add error log report > > > > Signed-off-by: Xudong Hao > > I continue to disagree to doing this always, unconditionally, with > hard-coded settings. If these features require explicit enabling, > there likely is something that drivers unaware of them could have > problems with - otherwise I would think these features would be > always enabled when a device supports them, and no options > would exist to control certain parameters. > I agree the driver control it, but it's difficult to let guest driver do it till now(because of PCIe emulation by qemu issue). > Plus, if the patch is nevertheless going to be acceptable, ... > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > pci_dev > > *dev) > > struct xen_pcibk_dev_data *dev_data; > > int err = 0; > > > > + /* set default value */ > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > + > > dev_dbg(&dev->dev, "initializing...\n"); > > > > /* The PCI backend is not intended to be a module (or to work with > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > pci_dev > > *dev) > > dev_dbg(&dev->dev, "reset device\n"); > > xen_pcibk_reset_device(dev); > > > > + /* Enable LTR and OBFF before do device assignment */ > > + /* LTR(Latency tolerance reporting) allows devices to send > > + * messages to the root complex indicating their latency tolerance > > + * for snooped & unsnooped memory transactions. > > + */ > > + err = pci_enable_ltr(dev); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > ... dev_err() here and below is certainly too severe, particularly for > the -ENOTSUPP cases. And the spelling would need fixing, especially > with it being broken exactly the same way a second time below. > dev_alert should be ok. Thanks for the careful review of typo "enable", I'll modify it in next version. > > + > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > What's the point of calling this function when pci_enable_ltr() failed? > Oh, thanks the point. It's unnecessary to call this function when pci_enable_ltr() failed indeed, I'll insert this calling in pci_enable_ltr() passing logical in next version. > Jan > > > + if (err) > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > + > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > + * improve energy efficiency by giving devices information about > > + * when interrupts and other activity will have a reduced power > > + * impact. > > + */ > > + err = pci_enable_obff(dev, type); > > + if (err) > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > + > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > return 0; > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:05:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09: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 ) id 1SQxOd-0007vy-O7; Sun, 06 May 2012 09:04:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxOc-0007vt-TL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:04:51 +0000 Received: from [85.158.139.83:18566] by server-3.bemta-5.messagelabs.com id E4/7A-25237-1BE36AF4; Sun, 06 May 2012 09:04:49 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-182.messagelabs.com!1336295088!22699205!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzcwMDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12674 invoked from network); 6 May 2012 09:04:49 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 May 2012 09:04:49 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 6B1A62969; Sun, 6 May 2012 12:04:47 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9922AEC027; Sun, 6 May 2012 12:04:46 +0300 (EEST) Date: Sun, 6 May 2012 12:04:46 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120506090446.GU2058@reaktio.net> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 10:04:23AM -0400, Konrad Rzeszutek Wilk wrote: > Was thinking to push these patches to Linus for v3.5-rc6. > Hmm.. that probably should say for v3.4-rc6 ? :) -- Pasi > arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++-- > arch/x86/xen/mmu.c | 7 ++++++- > drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- > 3 files changed, 59 insertions(+), 13 deletions(-) > > David Vrabel (1): > xen/pci: don't use PCI BIOS service for configuration space accesses > > Julia Lawall (1): > drivers/video/xen-fbfront.c: add missing cleanup code > > Konrad Rzeszutek Wilk (2): > xen/apic: Return the APIC ID (and version) for CPU 0. > xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:05:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09: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 ) id 1SQxOd-0007vy-O7; Sun, 06 May 2012 09:04:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxOc-0007vt-TL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:04:51 +0000 Received: from [85.158.139.83:18566] by server-3.bemta-5.messagelabs.com id E4/7A-25237-1BE36AF4; Sun, 06 May 2012 09:04:49 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-182.messagelabs.com!1336295088!22699205!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzcwMDU=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12674 invoked from network); 6 May 2012 09:04:49 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 May 2012 09:04:49 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 6B1A62969; Sun, 6 May 2012 12:04:47 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9922AEC027; Sun, 6 May 2012 12:04:46 +0300 (EEST) Date: Sun, 6 May 2012 12:04:46 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120506090446.GU2058@reaktio.net> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 10:04:23AM -0400, Konrad Rzeszutek Wilk wrote: > Was thinking to push these patches to Linus for v3.5-rc6. > Hmm.. that probably should say for v3.4-rc6 ? :) -- Pasi > arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++-- > arch/x86/xen/mmu.c | 7 ++++++- > drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- > 3 files changed, 59 insertions(+), 13 deletions(-) > > David Vrabel (1): > xen/pci: don't use PCI BIOS service for configuration space accesses > > Julia Lawall (1): > drivers/video/xen-fbfront.c: add missing cleanup code > > Konrad Rzeszutek Wilk (2): > xen/apic: Return the APIC ID (and version) for CPU 0. > xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:23:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09: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 ) id 1SQxfh-000867-F0; Sun, 06 May 2012 09:22:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxfg-000862-BL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:22:28 +0000 Received: from [193.109.254.147:56406] by server-9.bemta-14.messagelabs.com id FF/9C-05787-3D246AF4; Sun, 06 May 2012 09:22:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336296145!2696452!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA1MDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6810 invoked from network); 6 May 2012 09:22:27 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 09:22:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330923600"; d="scan'208";a="193583413" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 05:22:25 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 05:22:24 -0400 Message-ID: <1336296147.5933.5.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Goncalo Gomes Date: Sun, 6 May 2012 10:22:27 +0100 In-Reply-To: <20120505231926.GA8059@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-05 at 19:19 -0400, Goncalo Gomes wrote: > diff -r 0f53540494f7 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Fri May 04 11:18:48 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Sat May 05 21:27:41 2012 +0000 > @@ -728,6 +728,7 @@ static void parse_config_data(const char > if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) > b_info->rtc_timeoffset = l; > > + xlu_cfg_get_defbool(config, "vncviewer", &b_info->localtime, 0); > xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); You have a small typo here (localtime instead of vncviewer), but that won't effect the crux of this issue. I've tried reproducing using your config file with the patch applied and I can't. > [...] > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > which gets triggered from an erroneous b_info->type with a bogus value > of 0x84 (which is neither PV nor HVM.) I think it might be useful to sprinkle prints of b_info->type everywhere from the call to libxl_domain_build_info_init_type up until this switch statement to see if you can identify the line which is overwriting this field. I couldn't spot it by eye but something in there is presumably blowing off the end of a buffer or something similar. You should probably also validate the initial value, which comes from c_info->type, and if that is wrong trace it back to the place which sets that initial value. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:23:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09: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 ) id 1SQxfh-000867-F0; Sun, 06 May 2012 09:22:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxfg-000862-BL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:22:28 +0000 Received: from [193.109.254.147:56406] by server-9.bemta-14.messagelabs.com id FF/9C-05787-3D246AF4; Sun, 06 May 2012 09:22:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336296145!2696452!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA1MDE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6810 invoked from network); 6 May 2012 09:22:27 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 09:22:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330923600"; d="scan'208";a="193583413" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 05:22:25 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 05:22:24 -0400 Message-ID: <1336296147.5933.5.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Goncalo Gomes Date: Sun, 6 May 2012 10:22:27 +0100 In-Reply-To: <20120505231926.GA8059@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-05 at 19:19 -0400, Goncalo Gomes wrote: > diff -r 0f53540494f7 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Fri May 04 11:18:48 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Sat May 05 21:27:41 2012 +0000 > @@ -728,6 +728,7 @@ static void parse_config_data(const char > if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) > b_info->rtc_timeoffset = l; > > + xlu_cfg_get_defbool(config, "vncviewer", &b_info->localtime, 0); > xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); You have a small typo here (localtime instead of vncviewer), but that won't effect the crux of this issue. I've tried reproducing using your config file with the patch applied and I can't. > [...] > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > which gets triggered from an erroneous b_info->type with a bogus value > of 0x84 (which is neither PV nor HVM.) I think it might be useful to sprinkle prints of b_info->type everywhere from the call to libxl_domain_build_info_init_type up until this switch statement to see if you can identify the line which is overwriting this field. I couldn't spot it by eye but something in there is presumably blowing off the end of a buffer or something similar. You should probably also validate the initial value, which comes from c_info->type, and if that is wrong trace it back to the place which sets that initial value. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxsM-0008VY-Fd; Sun, 06 May 2012 09:35:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxsL-0008VT-EL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:35:33 +0000 Received: from [85.158.139.83:49603] by server-7.bemta-5.messagelabs.com id 7A/36-16195-4E546AF4; Sun, 06 May 2012 09:35:32 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336296930!23099820!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDMxNjA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1221 invoked from network); 6 May 2012 09:35:31 -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; 6 May 2012 09:35:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330923600"; d="scan'208";a="24910085" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 05:35:29 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 05:35:29 -0400 Message-ID: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Olaf Hering Date: Sun, 6 May 2012 10:35:32 +0100 In-Reply-To: <20120504201802.GA16466@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > # HG changeset patch > > > # User Olaf Hering > > > # Date 1336159720 -7200 > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > xl.cfg: document the maxmem= option > > > > > > Signed-off-by: Olaf Hering > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > --- a/docs/man/xl.cfg.pod.5 > > > +++ b/docs/man/xl.cfg.pod.5 > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > mode) and your guest workload consists of a a very large number of > > > similar processes then increasing this value may improve performance. > > > > > > +=item B > > > + > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > Isn't it also for PV guests (though without the PoD functionality)? > > Now that I look again at libxl__build_pre(), it appearently does also > something for PV guests. Right. Some people call this booting "pre-ballooned". Essentially n PV the balloon driver can be initialised early enough that something like PoD is not required -- the missing pages are just incorporated directly into the balloon. (strictly speaking the balloon driver isn't actually initialised early, but rather the pages are reserved/set-aside for it very early on). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 09:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 09:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxsM-0008VY-Fd; Sun, 06 May 2012 09:35:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SQxsL-0008VT-EL for xen-devel@lists.xensource.com; Sun, 06 May 2012 09:35:33 +0000 Received: from [85.158.139.83:49603] by server-7.bemta-5.messagelabs.com id 7A/36-16195-4E546AF4; Sun, 06 May 2012 09:35:32 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336296930!23099820!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDMxNjA=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1221 invoked from network); 6 May 2012 09:35:31 -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; 6 May 2012 09:35:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,538,1330923600"; d="scan'208";a="24910085" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 05:35:29 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 05:35:29 -0400 Message-ID: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Olaf Hering Date: Sun, 6 May 2012 10:35:32 +0100 In-Reply-To: <20120504201802.GA16466@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > # HG changeset patch > > > # User Olaf Hering > > > # Date 1336159720 -7200 > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > xl.cfg: document the maxmem= option > > > > > > Signed-off-by: Olaf Hering > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > --- a/docs/man/xl.cfg.pod.5 > > > +++ b/docs/man/xl.cfg.pod.5 > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > mode) and your guest workload consists of a a very large number of > > > similar processes then increasing this value may improve performance. > > > > > > +=item B > > > + > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > Isn't it also for PV guests (though without the PoD functionality)? > > Now that I look again at libxl__build_pre(), it appearently does also > something for PV guests. Right. Some people call this booting "pre-ballooned". Essentially n PV the balloon driver can be initialised early enough that something like PoD is not required -- the missing pages are just incorporated directly into the balloon. (strictly speaking the balloon driver isn't actually initialised early, but rather the pages are reserved/set-aside for it very early on). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 12:14:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 12: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 ) id 1SR0Lj-0001KN-Ew; Sun, 06 May 2012 12:14:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0Li-0001KI-IS for xen-devel@lists.xensource.com; Sun, 06 May 2012 12:14:02 +0000 Received: from [85.158.138.51:28462] by server-10.bemta-3.messagelabs.com id C6/00-29478-90B66AF4; Sun, 06 May 2012 12:14:01 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336306439!25563449!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMTAx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11903 invoked from network); 6 May 2012 12:14:00 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-174.messagelabs.com with SMTP; 6 May 2012 12:14:00 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 06 May 2012 05:13:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139462545" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 06 May 2012 05:13:58 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 05:13:58 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Sun, 6 May 2012 20:13:49 +0800 From: "Liu, Jinsong" To: Jan Beulich , "keir.xen@gmail.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH] Fix vmce addr/misc wrmsr bug Thread-Index: Ac0rgbB7WdDs/9mcQ9qVPfKaVnNF8Q== Date: Sun, 6 May 2012 12:13:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_" MIME-Version: 1.0 Subject: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fix vmce addr/misc wrmsr bug This patch fix a bug related to wrmsr vmce bank addr/misc registers, since they are not read-only. Intel SDM recommanded os mce driver clear bank status/addr/misc. So guest mce driver may clear addr and misc registers. Under such case, old vmce wrmsr logic would generate a #GP fault at guest mce context, and make guest crash. Signed-off-by: Liu, Jinsong diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce =3D dom_vmce(v->domain); struct bank_entry *entry =3D NULL; =20 + /* Give the first entry of the list, it corresponds to current + * vMCE# injection. When vMCE# is finished processing by the + * the guest, this node will be deleted. + * Only error bank is written. Non-error banks simply return. + */ + if ( !list_empty(&vmce->impact_header) ) + entry =3D list_entry(vmce->impact_header.next, struct bank_entry, = list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) { case MSR_IA32_MC0_CTL: @@ -216,32 +224,28 @@ vmce->mci_ctl[bank] =3D val; break; case MSR_IA32_MC0_STATUS: - /* Give the first entry of the list, it corresponds to current - * vMCE# injection. When vMCE# is finished processing by the - * the guest, this node will be deleted. - * Only error bank is written. Non-error banks simply return. - */ - if ( !list_empty(&vmce->impact_header) ) + if ( entry && (entry->bank =3D=3D bank) ) { - entry =3D list_entry(vmce->impact_header.next, - struct bank_entry, list); - if ( entry->bank =3D=3D bank ) - entry->mci_status =3D val; + entry->mci_status =3D val; mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", - bank, val); + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, v= al); } - else - mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_ADDR: - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); - ret =3D -1; + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_addr =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val= ); + } break; case MSR_IA32_MC0_MISC: - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); - ret =3D -1; + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_misc =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val= ); + } break; default: switch ( boot_cpu_data.x86_vendor )= --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="vmce-bug-fix.patch" Content-Description: vmce-bug-fix.patch Content-Disposition: attachment; filename="vmce-bug-fix.patch"; size=3051; creation-date="Sat, 05 May 2012 14:42:19 GMT"; modification-date="Sat, 05 May 2012 19:46:46 GMT" Content-Transfer-Encoding: base64 Rml4IHZtY2UgYWRkci9taXNjIHdybXNyIGJ1ZwoKVGhpcyBwYXRjaCBmaXggYSBidWcgcmVsYXRl ZCB0byB3cm1zciB2bWNlIGJhbmsgYWRkci9taXNjCnJlZ2lzdGVycywgc2luY2UgdGhleSBhcmUg bm90IHJlYWQtb25seS4KCkludGVsIFNETSByZWNvbW1hbmRlZCBvcyBtY2UgZHJpdmVyIGNsZWFy IGJhbmsgc3RhdHVzL2FkZHIvbWlzYy4KU28gZ3Vlc3QgbWNlIGRyaXZlciBtYXkgY2xlYXIgYWRk ciBhbmQgbWlzYyByZWdpc3RlcnMuClVuZGVyIHN1Y2ggY2FzZSwgb2xkIHZtY2Ugd3Jtc3IgbG9n aWMgd291bGQgZ2VuZXJhdGUKYSAjR1AgZmF1bHQgYXQgZ3Vlc3QgbWNlIGNvbnRleHQsIGFuZCBt YWtlIGd1ZXN0IGNyYXNoLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxp dUBpbnRlbC5jb20+CgpkaWZmIC1yIDc1NWY0NDBiM2I3OCB4ZW4vYXJjaC94ODYvY3B1L21jaGVj ay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBBcHIgMTgg MTg6MzM6MzYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJ U3VuIE1heSAwNiAwMzowNToyMCAyMDEyICswODAwCkBAIC0yMDksNiArMjA5LDE0IEBACiAgICAg c3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92bWNlKHYtPmRvbWFpbik7CiAgICAg c3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVMTDsKIAorICAgIC8qIEdpdmUgdGhlIGZpcnN0 IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3JyZXNwb25kcyB0byBjdXJyZW50CisgICAgICogdk1D RSMgaW5qZWN0aW9uLiBXaGVuIHZNQ0UjIGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcgYnkgdGhlCisg ICAgICogdGhlIGd1ZXN0LCB0aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVkLgorICAgICAqIE9ubHkg ZXJyb3IgYmFuayBpcyB3cml0dGVuLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KKyAg ICAgKi8KKyAgICBpZiAoICFsaXN0X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAg ICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsIHN0cnVjdCBi YW5rX2VudHJ5LCBsaXN0KTsKKwogICAgIHN3aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RM IHwgMykgKQogICAgIHsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9DVEw6CkBAIC0yMTYsMzIgKzIy NCwyOCBAQAogICAgICAgICAgICAgdm1jZS0+bWNpX2N0bFtiYW5rXSA9IHZhbDsKICAgICAgICAg YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfU1RBVFVTOgotICAgICAgICAvKiBHaXZlIHRo ZSBmaXJzdCBlbnRyeSBvZiB0aGUgbGlzdCwgaXQgY29ycmVzcG9uZHMgdG8gY3VycmVudAotICAg ICAgICAgKiB2TUNFIyBpbmplY3Rpb24uIFdoZW4gdk1DRSMgaXMgZmluaXNoZWQgcHJvY2Vzc2lu ZyBieSB0aGUKLSAgICAgICAgICogdGhlIGd1ZXN0LCB0aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVk LgotICAgICAgICAgKiBPbmx5IGVycm9yIGJhbmsgaXMgd3JpdHRlbi4gTm9uLWVycm9yIGJhbmtz IHNpbXBseSByZXR1cm4uCi0gICAgICAgICAqLwotICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZ2 bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r ID09IGJhbmspICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZt Y2UtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5rID09 IGJhbmsgKQotICAgICAgICAgICAgICAgIGVudHJ5LT5tY2lfc3RhdHVzID0gdmFsOworICAgICAg ICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSB2YWw7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1D RV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyAl IlBSSXg2NCIgaW4gdk1DRSNcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgIGJhbmssIHZhbCk7 CisgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IiBp biB2TUNFI1xuIiwgYmFuaywgdmFsKTsKICAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAg ICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNF OiB3ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgTVNSX0lBMzJfTUMwX0FERFI6Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FV SUVULCAiTUNFOiBNQyV1X0FERFIgaXMgcmVhZC1vbmx5XG4iLCBiYW5rKTsKLSAgICAgICAgcmV0 ID0gLTE7CisgICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5rID09IGJhbmspICkKKyAg ICAgICAgeworICAgICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOworICAgICAgICAgICAg bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3Ig TUMldV9BRERSICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQog ICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBtY2Vf cHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTUMldV9NSVNDIGlzIHJlYWQtb25seVxuIiwgYmFuayk7 Ci0gICAgICAgIHJldCA9IC0xOworICAgICAgICBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9 PSBiYW5rKSApCisgICAgICAgIHsKKyAgICAgICAgICAgIGVudHJ5LT5tY2lfbWlzYyA9IHZhbDsK KyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCisgICAgICAgICAgICAgICAgICAg ICAgICJNQ0U6IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIsIGJhbmssIHZhbCk7 CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVsdDoKICAgICAgICAgc3dpdGNo ICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yICkK --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Sun May 06 12:14:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 12: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 ) id 1SR0Lj-0001KN-Ew; Sun, 06 May 2012 12:14:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0Li-0001KI-IS for xen-devel@lists.xensource.com; Sun, 06 May 2012 12:14:02 +0000 Received: from [85.158.138.51:28462] by server-10.bemta-3.messagelabs.com id C6/00-29478-90B66AF4; Sun, 06 May 2012 12:14:01 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336306439!25563449!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMTAx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11903 invoked from network); 6 May 2012 12:14:00 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-174.messagelabs.com with SMTP; 6 May 2012 12:14:00 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 06 May 2012 05:13:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139462545" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 06 May 2012 05:13:58 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 6 May 2012 05:13:58 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Sun, 6 May 2012 20:13:49 +0800 From: "Liu, Jinsong" To: Jan Beulich , "keir.xen@gmail.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH] Fix vmce addr/misc wrmsr bug Thread-Index: Ac0rgbB7WdDs/9mcQ9qVPfKaVnNF8Q== Date: Sun, 6 May 2012 12:13:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_" MIME-Version: 1.0 Subject: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fix vmce addr/misc wrmsr bug This patch fix a bug related to wrmsr vmce bank addr/misc registers, since they are not read-only. Intel SDM recommanded os mce driver clear bank status/addr/misc. So guest mce driver may clear addr and misc registers. Under such case, old vmce wrmsr logic would generate a #GP fault at guest mce context, and make guest crash. Signed-off-by: Liu, Jinsong diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce =3D dom_vmce(v->domain); struct bank_entry *entry =3D NULL; =20 + /* Give the first entry of the list, it corresponds to current + * vMCE# injection. When vMCE# is finished processing by the + * the guest, this node will be deleted. + * Only error bank is written. Non-error banks simply return. + */ + if ( !list_empty(&vmce->impact_header) ) + entry =3D list_entry(vmce->impact_header.next, struct bank_entry, = list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) { case MSR_IA32_MC0_CTL: @@ -216,32 +224,28 @@ vmce->mci_ctl[bank] =3D val; break; case MSR_IA32_MC0_STATUS: - /* Give the first entry of the list, it corresponds to current - * vMCE# injection. When vMCE# is finished processing by the - * the guest, this node will be deleted. - * Only error bank is written. Non-error banks simply return. - */ - if ( !list_empty(&vmce->impact_header) ) + if ( entry && (entry->bank =3D=3D bank) ) { - entry =3D list_entry(vmce->impact_header.next, - struct bank_entry, list); - if ( entry->bank =3D=3D bank ) - entry->mci_status =3D val; + entry->mci_status =3D val; mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", - bank, val); + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, v= al); } - else - mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_ADDR: - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); - ret =3D -1; + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_addr =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val= ); + } break; case MSR_IA32_MC0_MISC: - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); - ret =3D -1; + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_misc =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val= ); + } break; default: switch ( boot_cpu_data.x86_vendor )= --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="vmce-bug-fix.patch" Content-Description: vmce-bug-fix.patch Content-Disposition: attachment; filename="vmce-bug-fix.patch"; size=3051; creation-date="Sat, 05 May 2012 14:42:19 GMT"; modification-date="Sat, 05 May 2012 19:46:46 GMT" Content-Transfer-Encoding: base64 Rml4IHZtY2UgYWRkci9taXNjIHdybXNyIGJ1ZwoKVGhpcyBwYXRjaCBmaXggYSBidWcgcmVsYXRl ZCB0byB3cm1zciB2bWNlIGJhbmsgYWRkci9taXNjCnJlZ2lzdGVycywgc2luY2UgdGhleSBhcmUg bm90IHJlYWQtb25seS4KCkludGVsIFNETSByZWNvbW1hbmRlZCBvcyBtY2UgZHJpdmVyIGNsZWFy IGJhbmsgc3RhdHVzL2FkZHIvbWlzYy4KU28gZ3Vlc3QgbWNlIGRyaXZlciBtYXkgY2xlYXIgYWRk ciBhbmQgbWlzYyByZWdpc3RlcnMuClVuZGVyIHN1Y2ggY2FzZSwgb2xkIHZtY2Ugd3Jtc3IgbG9n aWMgd291bGQgZ2VuZXJhdGUKYSAjR1AgZmF1bHQgYXQgZ3Vlc3QgbWNlIGNvbnRleHQsIGFuZCBt YWtlIGd1ZXN0IGNyYXNoLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxp dUBpbnRlbC5jb20+CgpkaWZmIC1yIDc1NWY0NDBiM2I3OCB4ZW4vYXJjaC94ODYvY3B1L21jaGVj ay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBBcHIgMTgg MTg6MzM6MzYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJ U3VuIE1heSAwNiAwMzowNToyMCAyMDEyICswODAwCkBAIC0yMDksNiArMjA5LDE0IEBACiAgICAg c3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92bWNlKHYtPmRvbWFpbik7CiAgICAg c3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVMTDsKIAorICAgIC8qIEdpdmUgdGhlIGZpcnN0 IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3JyZXNwb25kcyB0byBjdXJyZW50CisgICAgICogdk1D RSMgaW5qZWN0aW9uLiBXaGVuIHZNQ0UjIGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcgYnkgdGhlCisg ICAgICogdGhlIGd1ZXN0LCB0aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVkLgorICAgICAqIE9ubHkg ZXJyb3IgYmFuayBpcyB3cml0dGVuLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KKyAg ICAgKi8KKyAgICBpZiAoICFsaXN0X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAg ICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsIHN0cnVjdCBi YW5rX2VudHJ5LCBsaXN0KTsKKwogICAgIHN3aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RM IHwgMykgKQogICAgIHsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9DVEw6CkBAIC0yMTYsMzIgKzIy NCwyOCBAQAogICAgICAgICAgICAgdm1jZS0+bWNpX2N0bFtiYW5rXSA9IHZhbDsKICAgICAgICAg YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfU1RBVFVTOgotICAgICAgICAvKiBHaXZlIHRo ZSBmaXJzdCBlbnRyeSBvZiB0aGUgbGlzdCwgaXQgY29ycmVzcG9uZHMgdG8gY3VycmVudAotICAg ICAgICAgKiB2TUNFIyBpbmplY3Rpb24uIFdoZW4gdk1DRSMgaXMgZmluaXNoZWQgcHJvY2Vzc2lu ZyBieSB0aGUKLSAgICAgICAgICogdGhlIGd1ZXN0LCB0aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVk LgotICAgICAgICAgKiBPbmx5IGVycm9yIGJhbmsgaXMgd3JpdHRlbi4gTm9uLWVycm9yIGJhbmtz IHNpbXBseSByZXR1cm4uCi0gICAgICAgICAqLwotICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZ2 bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r ID09IGJhbmspICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZt Y2UtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5rID09 IGJhbmsgKQotICAgICAgICAgICAgICAgIGVudHJ5LT5tY2lfc3RhdHVzID0gdmFsOworICAgICAg ICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSB2YWw7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1D RV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyAl IlBSSXg2NCIgaW4gdk1DRSNcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgIGJhbmssIHZhbCk7 CisgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IiBp biB2TUNFI1xuIiwgYmFuaywgdmFsKTsKICAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAg ICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNF OiB3ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgTVNSX0lBMzJfTUMwX0FERFI6Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FV SUVULCAiTUNFOiBNQyV1X0FERFIgaXMgcmVhZC1vbmx5XG4iLCBiYW5rKTsKLSAgICAgICAgcmV0 ID0gLTE7CisgICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5rID09IGJhbmspICkKKyAg ICAgICAgeworICAgICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOworICAgICAgICAgICAg bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3Ig TUMldV9BRERSICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQog ICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBtY2Vf cHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTUMldV9NSVNDIGlzIHJlYWQtb25seVxuIiwgYmFuayk7 Ci0gICAgICAgIHJldCA9IC0xOworICAgICAgICBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9 PSBiYW5rKSApCisgICAgICAgIHsKKyAgICAgICAgICAgIGVudHJ5LT5tY2lfbWlzYyA9IHZhbDsK KyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCisgICAgICAgICAgICAgICAgICAg ICAgICJNQ0U6IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIsIGJhbmssIHZhbCk7 CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVsdDoKICAgICAgICAgc3dpdGNo ICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yICkK --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC829233519F023SHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Sun May 06 12:45:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 12:45:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0pH-0001Wf-39; Sun, 06 May 2012 12:44:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0pF-0001Wa-4o for xen-devel@lists.xensource.com; Sun, 06 May 2012 12:44:33 +0000 Received: from [85.158.138.51:50032] by server-8.bemta-3.messagelabs.com id 3A/F5-24428-03276AF4; Sun, 06 May 2012 12:44:32 +0000 X-Env-Sender: bugs@humanleg.org.uk X-Msg-Ref: server-11.tower-174.messagelabs.com!1336308271!25504152!1 X-Originating-IP: [81.103.221.47] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18841 invoked from network); 6 May 2012 12:44:31 -0000 Received: from mtaout01-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by server-11.tower-174.messagelabs.com with SMTP; 6 May 2012 12:44:31 -0000 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20120506124430.IAYW10903.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Sun, 6 May 2012 13:44:30 +0100 Received: from leclerc.lan ([81.105.12.50]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20120506124430.WXD13318.aamtaout03-winn.ispmail.ntl.com@leclerc.lan>; Sun, 6 May 2012 13:44:30 +0100 From: Robert Scott Organization: none To: Jonathan Nieder Date: Sun, 6 May 2012 13:44:17 +0100 User-Agent: KMail/1.9.9 References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <201204161905.13260.bugs@humanleg.org.uk> <20120417020433.GA15848@burratino> In-Reply-To: <20120417020433.GA15848@burratino> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201205061344.25275.bugs@humanleg.org.uk> X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=oafpOytrBa8A:10 a=l5_RjRQ6opQA:10 a=8nJEP1OIZ-IA:10 a=hLW_Fef1W2nHZV0zz8kA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Kevin Tian , xen-devel@lists.xensource.com, Fengzhe Zhang , linux-kernel@vger.kernel.org, Ian Campbell , mingo@redhat.com, hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net, Thomas Gleixner , "Liu, Chuansheng" , Lars Boegild Thomsen Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: bugs@humanleg.org.uk List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tuesday 17 April 2012, Jonathan Nieder wrote: > Robert Scott wrote: > > On Sunday 15 April 2012, Jonathan Nieder wrote: > > >> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how > >> it goes? I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable > >> semantics in fixup_irqs()") will fix this. > > > > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid. > > Alas. Does suspend-to-disk ("echo disk >/sys/power/state") have the > same problem? Can you get a log of the failure with > "no_console_suspend" appended to the kernel command line, for example > with a serial console or netconsole? Well, for what it's worth, using a USB serial console to capture output, all you get is: [ 814.016541] PM: Syncing filesystems ... done. [ 814.018516] PM: Preparing system for mem sleep [ 814.100393] Freezing user space processes ... (elapsed 0.01 se before it goes to sleep, and it doesn't output anything on (attempted) wakeup. Though I don't know if this is due to USB being woken up quite late or something. robert. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 12:45:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 12:45:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0pH-0001Wf-39; Sun, 06 May 2012 12:44:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR0pF-0001Wa-4o for xen-devel@lists.xensource.com; Sun, 06 May 2012 12:44:33 +0000 Received: from [85.158.138.51:50032] by server-8.bemta-3.messagelabs.com id 3A/F5-24428-03276AF4; Sun, 06 May 2012 12:44:32 +0000 X-Env-Sender: bugs@humanleg.org.uk X-Msg-Ref: server-11.tower-174.messagelabs.com!1336308271!25504152!1 X-Originating-IP: [81.103.221.47] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18841 invoked from network); 6 May 2012 12:44:31 -0000 Received: from mtaout01-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by server-11.tower-174.messagelabs.com with SMTP; 6 May 2012 12:44:31 -0000 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20120506124430.IAYW10903.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Sun, 6 May 2012 13:44:30 +0100 Received: from leclerc.lan ([81.105.12.50]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20120506124430.WXD13318.aamtaout03-winn.ispmail.ntl.com@leclerc.lan>; Sun, 6 May 2012 13:44:30 +0100 From: Robert Scott Organization: none To: Jonathan Nieder Date: Sun, 6 May 2012 13:44:17 +0100 User-Agent: KMail/1.9.9 References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <201204161905.13260.bugs@humanleg.org.uk> <20120417020433.GA15848@burratino> In-Reply-To: <20120417020433.GA15848@burratino> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201205061344.25275.bugs@humanleg.org.uk> X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=oafpOytrBa8A:10 a=l5_RjRQ6opQA:10 a=8nJEP1OIZ-IA:10 a=hLW_Fef1W2nHZV0zz8kA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Kevin Tian , xen-devel@lists.xensource.com, Fengzhe Zhang , linux-kernel@vger.kernel.org, Ian Campbell , mingo@redhat.com, hpa@zytor.com, e568b31a443d@6cc2cce7af2d.anonbox.net, Thomas Gleixner , "Liu, Chuansheng" , Lars Boegild Thomsen Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: bugs@humanleg.org.uk List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tuesday 17 April 2012, Jonathan Nieder wrote: > Robert Scott wrote: > > On Sunday 15 April 2012, Jonathan Nieder wrote: > > >> Lars, Robert, anon: can you try 3.4-rc2 or newer and let us know how > >> it goes? I suspect v3.4-rc2~24^2~4 ("x86: Preserve lazy irq disable > >> semantics in fixup_irqs()") will fix this. > > > > Hmm, no, 3.4-rc2 seems to produce the same results I'm afraid. > > Alas. Does suspend-to-disk ("echo disk >/sys/power/state") have the > same problem? Can you get a log of the failure with > "no_console_suspend" appended to the kernel command line, for example > with a serial console or netconsole? Well, for what it's worth, using a USB serial console to capture output, all you get is: [ 814.016541] PM: Syncing filesystems ... done. [ 814.018516] PM: Preparing system for mem sleep [ 814.100393] Freezing user space processes ... (elapsed 0.01 se before it goes to sleep, and it doesn't output anything on (attempted) wakeup. Though I don't know if this is due to USB being woken up quite late or something. robert. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 15:12:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 15:12:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR37z-0002T3-AD; Sun, 06 May 2012 15:12:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR37x-0002Sy-El for xen-devel@lists.xen.org; Sun, 06 May 2012 15:12:01 +0000 Received: from [85.158.139.83:20290] by server-11.bemta-5.messagelabs.com id B5/BD-12959-0C496AF4; Sun, 06 May 2012 15:12:00 +0000 X-Env-Sender: sillyyax@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336317117!23041425!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17380 invoked from network); 6 May 2012 15:11:59 -0000 Received: from mail-gh0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 15:11:59 -0000 Received: by ghrr18 with SMTP id r18so3814833ghr.28 for ; Sun, 06 May 2012 08:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O5oYXHPYBIU0LeyXK7FVDYw0s+CgSXJq+qyR0zjySkE=; b=pZnitjBDpTh7RBR9JgmWoCm84KJi6zwg4fOlERLct56zRsjde3QW1pvPZ4+JY99Zct +H0FwzQ/QkXkm/Af5yXmZH5zdlAT6dVI9vXkGpB19u2bMXbniAuR3hEr9bm2DN3g6hCw MARwKvXs/3Zove+EDTLMNlpTLs6UliRALogRR+V8PYiUX0uRssdT+bkoq32uAOkpYqR5 la90k4ekLOwbmowScYLMB5SIvEfE1jyxyddUPjJU6UGNF63B86hDmXwMrESaY2smsPCR ePE8DazFMXHA006/2vCgyUI60cXmfang6ppR9mWCj2djSuWBGcc3VwUGjpJeH7sKFq0Q NsXg== MIME-Version: 1.0 Received: by 10.50.181.194 with SMTP id dy2mr6579054igc.48.1336317117344; Sun, 06 May 2012 08:11:57 -0700 (PDT) Received: by 10.64.62.225 with HTTP; Sun, 6 May 2012 08:11:57 -0700 (PDT) Date: Sun, 6 May 2012 16:11:57 +0100 Message-ID: From: Yaqub Alwan To: xen-devel@lists.xen.org Subject: [Xen-devel] "UEFI firmware, Xen not detecting e820 map" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8398942041968092731==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8398942041968092731== Content-Type: multipart/alternative; boundary=14dae934096b162dac04bf5f934f --14dae934096b162dac04bf5f934f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I was in the ##xen freenode channel seeking help for an issue with memory being unrecognised above 512mb, and iommu not being detected using xen 4.1.2. The guys there determined that xen was not recognising my system e820 map and using only the e801 map, and recommended I emailed the details to this list. I appreciate that this list is not for technical queries, so I do not expect any help, but write this to enable xen developers to troubleshoot the issue for future patches. My system is a Supermicro X9SCV-Q with 16GB of installed memory and a 2720QM CPU. The motherboard, as far as I am aware, only supports EFI booting (I have a query with the manufacturer to find out if it supports legacy boot). Xen hypervisor only detects 511MB memory, but If I boot the regular linux kernel, I get the full 16GB. Please find the output from xm dmesg here: http://pastebin.com/a1LC2csr Please find the output from normal linux boot dmesg here: http://pastebin.com/CjePrLkx You can see that native Linux kernel is finding the e820 memory map, but xen only sees e801 map. Please let me know if you would require more information, I shall do my best to assist. Kind regards, Yaqub --14dae934096b162dac04bf5f934f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I was in the ##xen freenode channel seeking help for an issu= e with memory being unrecognised above 512mb, and iommu not being detected = using xen 4.1.2. The guys there determined that xen was not recognising my = system e820 map and using only the e801 map, and recommended I emailed the = details to this list. I appreciate that this list is not for technical quer= ies, so I do not expect any help, but write this to enable xen developers t= o troubleshoot the issue for future patches.

My system is a Supermicro X9SCV-Q with 16GB of installed memory and a 2= 720QM CPU. The motherboard, as far as I am aware, only supports EFI booting= (I have a query with the manufacturer to find out if it supports legacy bo= ot).
Xen hypervisor only detects 511MB memory, but If I boot the regular linux k= ernel, I get the full 16GB.

Please find the output from xm dmesg he= re: http://pastebin.com/a1LC2csr

Please find the output from normal linux boot dmesg here: http://pastebin.com/CjePrLkx

You can= see that native Linux kernel is finding the e820 memory map, but xen only = sees e801 map.

Please let me know if you would require more information, I shall do my= best to assist.

Kind regards,

Yaqub
--14dae934096b162dac04bf5f934f-- --===============8398942041968092731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8398942041968092731==-- From xen-devel-bounces@lists.xen.org Sun May 06 15:12:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 15:12:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR37z-0002T3-AD; Sun, 06 May 2012 15:12:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR37x-0002Sy-El for xen-devel@lists.xen.org; Sun, 06 May 2012 15:12:01 +0000 Received: from [85.158.139.83:20290] by server-11.bemta-5.messagelabs.com id B5/BD-12959-0C496AF4; Sun, 06 May 2012 15:12:00 +0000 X-Env-Sender: sillyyax@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336317117!23041425!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17380 invoked from network); 6 May 2012 15:11:59 -0000 Received: from mail-gh0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 15:11:59 -0000 Received: by ghrr18 with SMTP id r18so3814833ghr.28 for ; Sun, 06 May 2012 08:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O5oYXHPYBIU0LeyXK7FVDYw0s+CgSXJq+qyR0zjySkE=; b=pZnitjBDpTh7RBR9JgmWoCm84KJi6zwg4fOlERLct56zRsjde3QW1pvPZ4+JY99Zct +H0FwzQ/QkXkm/Af5yXmZH5zdlAT6dVI9vXkGpB19u2bMXbniAuR3hEr9bm2DN3g6hCw MARwKvXs/3Zove+EDTLMNlpTLs6UliRALogRR+V8PYiUX0uRssdT+bkoq32uAOkpYqR5 la90k4ekLOwbmowScYLMB5SIvEfE1jyxyddUPjJU6UGNF63B86hDmXwMrESaY2smsPCR ePE8DazFMXHA006/2vCgyUI60cXmfang6ppR9mWCj2djSuWBGcc3VwUGjpJeH7sKFq0Q NsXg== MIME-Version: 1.0 Received: by 10.50.181.194 with SMTP id dy2mr6579054igc.48.1336317117344; Sun, 06 May 2012 08:11:57 -0700 (PDT) Received: by 10.64.62.225 with HTTP; Sun, 6 May 2012 08:11:57 -0700 (PDT) Date: Sun, 6 May 2012 16:11:57 +0100 Message-ID: From: Yaqub Alwan To: xen-devel@lists.xen.org Subject: [Xen-devel] "UEFI firmware, Xen not detecting e820 map" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8398942041968092731==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8398942041968092731== Content-Type: multipart/alternative; boundary=14dae934096b162dac04bf5f934f --14dae934096b162dac04bf5f934f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I was in the ##xen freenode channel seeking help for an issue with memory being unrecognised above 512mb, and iommu not being detected using xen 4.1.2. The guys there determined that xen was not recognising my system e820 map and using only the e801 map, and recommended I emailed the details to this list. I appreciate that this list is not for technical queries, so I do not expect any help, but write this to enable xen developers to troubleshoot the issue for future patches. My system is a Supermicro X9SCV-Q with 16GB of installed memory and a 2720QM CPU. The motherboard, as far as I am aware, only supports EFI booting (I have a query with the manufacturer to find out if it supports legacy boot). Xen hypervisor only detects 511MB memory, but If I boot the regular linux kernel, I get the full 16GB. Please find the output from xm dmesg here: http://pastebin.com/a1LC2csr Please find the output from normal linux boot dmesg here: http://pastebin.com/CjePrLkx You can see that native Linux kernel is finding the e820 memory map, but xen only sees e801 map. Please let me know if you would require more information, I shall do my best to assist. Kind regards, Yaqub --14dae934096b162dac04bf5f934f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I was in the ##xen freenode channel seeking help for an issu= e with memory being unrecognised above 512mb, and iommu not being detected = using xen 4.1.2. The guys there determined that xen was not recognising my = system e820 map and using only the e801 map, and recommended I emailed the = details to this list. I appreciate that this list is not for technical quer= ies, so I do not expect any help, but write this to enable xen developers t= o troubleshoot the issue for future patches.

My system is a Supermicro X9SCV-Q with 16GB of installed memory and a 2= 720QM CPU. The motherboard, as far as I am aware, only supports EFI booting= (I have a query with the manufacturer to find out if it supports legacy bo= ot).
Xen hypervisor only detects 511MB memory, but If I boot the regular linux k= ernel, I get the full 16GB.

Please find the output from xm dmesg he= re: http://pastebin.com/a1LC2csr

Please find the output from normal linux boot dmesg here: http://pastebin.com/CjePrLkx

You can= see that native Linux kernel is finding the e820 memory map, but xen only = sees e801 map.

Please let me know if you would require more information, I shall do my= best to assist.

Kind regards,

Yaqub
--14dae934096b162dac04bf5f934f-- --===============8398942041968092731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8398942041968092731==-- From xen-devel-bounces@lists.xen.org Sun May 06 15:24:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 15:24:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR3JL-0002cy-FF; Sun, 06 May 2012 15:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR3JK-0002ct-8u for xen-devel@lists.xensource.com; Sun, 06 May 2012 15:23:46 +0000 Received: from [85.158.143.99:2919] by server-1.bemta-4.messagelabs.com id DA/75-20925-18796AF4; Sun, 06 May 2012 15:23:45 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-216.messagelabs.com!1336317823!16944788!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzczODI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17240 invoked from network); 6 May 2012 15:23:44 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 May 2012 15:23:44 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id B1D491EAA; Sun, 6 May 2012 18:23:41 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 6F114EC027; Sun, 6 May 2012 18:23:41 +0300 (EEST) Date: Sun, 6 May 2012 18:23:41 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120506152341.GX2058@reaktio.net> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120426170426.GI26830@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > >> > > >> This I would take as C3 and C6 really not being used and the frequency scaling > > > > > > To go in deeper modes there is also a need to backport a Xen unstable > > > hypercall which will allow the kernel to detect the other states besides > > > C0-C2. > > > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > "ACPI: add _PDC input override mechanism". > > > > > > > I see. There is a kernel patch about enabling MWAIT that refers to that... > > Yeah, I should see about back-porting it in Xen 4.1.. > Should this patch be backported and merged to xen-4.1-testing.hg for Xen 4.1.3 release ? Thanks, -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 15:24:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 15:24:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR3JL-0002cy-FF; Sun, 06 May 2012 15:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR3JK-0002ct-8u for xen-devel@lists.xensource.com; Sun, 06 May 2012 15:23:46 +0000 Received: from [85.158.143.99:2919] by server-1.bemta-4.messagelabs.com id DA/75-20925-18796AF4; Sun, 06 May 2012 15:23:45 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-216.messagelabs.com!1336317823!16944788!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzczODI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17240 invoked from network); 6 May 2012 15:23:44 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 May 2012 15:23:44 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id B1D491EAA; Sun, 6 May 2012 18:23:41 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 6F114EC027; Sun, 6 May 2012 18:23:41 +0300 (EEST) Date: Sun, 6 May 2012 18:23:41 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120506152341.GX2058@reaktio.net> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120426170426.GI26830@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Stefan Bader Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > >> > > >> This I would take as C3 and C6 really not being used and the frequency scaling > > > > > > To go in deeper modes there is also a need to backport a Xen unstable > > > hypercall which will allow the kernel to detect the other states besides > > > C0-C2. > > > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > "ACPI: add _PDC input override mechanism". > > > > > > > I see. There is a kernel patch about enabling MWAIT that refers to that... > > Yeah, I should see about back-porting it in Xen 4.1.. > Should this patch be backported and merged to xen-4.1-testing.hg for Xen 4.1.3 release ? Thanks, -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 17:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 17:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR5AL-0003rC-5G; Sun, 06 May 2012 17:22:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR5AJ-0003r3-Qa for xen-devel@lists.xensource.com; Sun, 06 May 2012 17:22:36 +0000 Received: from [85.158.143.99:33876] by server-2.bemta-4.messagelabs.com id 90/CB-17550-B53B6AF4; Sun, 06 May 2012 17:22:35 +0000 X-Env-Sender: vhpc.dist@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336324950!23353311!1 X-Originating-IP: [209.85.210.47] X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19223 invoked from network); 6 May 2012 17:22:32 -0000 Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 17:22:32 -0000 Received: by dalh21 with SMTP id h21so5661615dal.6 for ; Sun, 06 May 2012 10:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2EMWtPczTKE2wwm5BzOPswJX9/qXDlemqHKdc3sUpAc=; b=iOwSOCdVCkY/WItVpiUcuAN5WDeRxZbb1FS9/dGxBr4GFQIwf8u6zHGvpLae4yuWSU 7ej0PCWhF/+0uRU7bUYG6fsq25ODhJYuZNLUAo2/dDjD8AyUe2nI9mSLQ6G4YCZS0Vyp JfWSLOF7WSov6Y6KC2Lw0RIXTerAuvssqVWtXWd74yeqoPc2FlK3Lqp5aA+RUbOT2x97 DMl0dKJc8rC3Of/JRL1X8XUojBUpVmKgvd7sU1SP3vc7amrjG0Uy69NRz1pvvLPuxLFg WP6xpTtss2wzZbnxvOQQU86UWvQrKM1VDklQxoh38urYQpHI1rpLxF4MZ3HxqdVL24YB /Npw== MIME-Version: 1.0 Received: by 10.68.224.36 with SMTP id qz4mr7804250pbc.69.1336324949757; Sun, 06 May 2012 10:22:29 -0700 (PDT) Received: by 10.68.223.1 with HTTP; Sun, 6 May 2012 10:22:29 -0700 (PDT) Date: Sun, 6 May 2012 19:22:29 +0200 Message-ID: From: VHPC 12 To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Submission Deadline Extension X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org we apologize if you receive multiple copies of this CFP =================================================================== CALL FOR PAPERS 7th Workshop on Virtualization in High-Performance Cloud Computing VHPC '12 as part of Euro-Par 2012, Rhodes Island, Greece =================================================================== Date: August 28, 2012 Workshop URL: http://vhpc.org SUBMISSION DEADLINE: June 11, 2012 - Full paper submission (extended) SCOPE: Virtualization has become a common abstraction layer in modern data centers, enabling resource owners to manage complex infrastructure independently of their applications. Conjointly, virtualization is becoming a driving technology for a manifold of industry grade IT services. The cloud concept includes the notion of a separation between resource owners and users, adding services such as hosted application frameworks and queueing. Utilizing the same infrastructure, clouds carry significant potential for use in high-performance scientific computing. The ability of clouds to provide for requests and releases of vast computing resources dynamically and close to the marginal cost of providing the services is unprecedented in the history of scientific and commercial computing. Distributed computing concepts that leverage federated resource access are popular within the grid community, but have not seen previously desired deployed levels so far. Also, many of the scientific data centers have not adopted virtualization or cloud concepts yet. This workshop aims to bring together industrial providers with the scientific community in order to foster discussion, collaboration and mutual exchange of knowledge and experience. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections. Presentations may be accompanied by interactive demonstrations. TOPICS Topics of interest include, but are not limited to: Higher-level cloud architectures, focusing on issues such as: - Languages for describing highly-distributed compute jobs - Workload characterization for VM-based environments - Optimized communication libraries/protocols in the cloud - Cross-layer optimization of numeric algorithms on VM infrastructure - System and process/bytecode VM convergence - Cloud frameworks and API sets - Checkpointing/migration of large compute jobs - Instrumentation interfaces and languages - VMM performance (auto-)tuning on various load types - Cloud reliability, fault-tolerance, and security - Software as a Service (SaaS) architectures - Research and education use cases - Virtualization in cloud, cluster and grid environments - Cross-layer VM optimizations - Cloud use cases including optimizations - VM-based cloud performance modelling - Performance and cost modelling Lower-level design challenges for Hypervisors, VM-aware I/O devices, hardware accelerators or filesystems in VM environments, especially: - Cloud, grid and distributed filesystems - Hardware for I/O virtualization (storage/network/accelerators) - Storage and network I/O subsystems in virtualized environments - Novel software approaches to I/O virtualization - Paravirtualized I/O subsystems for modified/unmodified guests - Virtualization-aware cluster interconnects - Direct device assignment - NUMA-aware subsystems in virtualized environments - Hardware Accelerators in virtualization (GPUs/FPGAs) - Hardware extensions for virtualization - VMMs/Hypervisors for embedded systems Data Center management methods, including: - QoS and and service levels - VM cloud and cluster distribution algorithms - VM load-balancing in Clouds - Hypervisor extensions and tools for cluster and grid computing - Fault tolerant VM environments - Virtual machine monitor platforms - Management, deployment and monitoring of VM-based environments - Cluster provisioning in the Cloud PAPER SUBMISSION Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, key words, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in the Springer LNCS series - the format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Format Guidelines: http://www.springer.de/comp/lncs/authors.html Style template: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Abstract Submission Link: http://edas.info/newPaper.php?c=11943 IMPORTANT DATES Rolling abstract submission June 11, 2012 - Full paper submission (extended) June 29, 2012 - Acceptance notification July 20, 2012 - Camera-ready version due August 28, 2012 - Workshop Date CHAIR Michael Alexander (chair), TU Wien, Austria Gianluigi Zanetti (co-chair), CRS4, Italy Anastassios Nanos (co-chair), NTUA, Greece PROGRAM COMMITTEE Paolo Anedda, CRS4, Italy Giovanni Busonera, CRS4, Italy Brad Calder, Microsoft, USA Roberto Canonico, University of Napoli Federico II, Italy Tommaso Cucinotta, Alcatel-Lucent Bell Labs, Ireland Werner Fischer, Thomas-Krenn AG, Germany William Gardner, University of Guelph, USA Marcus Hardt, Forschungszentrum Karlsruhe, Germany Sverre Jarp, CERN, Switzerland Shantenu Jha, Louisiana State University, USA Xuxian Jiang, NC State, USA Nectarios Koziris, National Technical University of Athens, Greece Simone Leo, CRS4, Italy Ignacio Llorente, Universidad Complutense de Madrid, Spain Naoya Maruyama, Tokyo Institute of Technology, Japan Jean-Marc Menaud, Ecole des Mines de Nantes, France Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece Jose Renato Santos, HP Labs, USA Walter Schwaiger, TU Wien, Austria Yoshio Turner, HP Labs, USA Kurt Tutschku, University of Vienna, Austria Lizhe Wang, Indiana University, USA Chao-Tung Yang, Tunghai University, Taiwan DURATION: Workshop Duration is one day. GENERAL INFORMATION The workshop will be held as part of Euro-Par 2012. Euro-Par 2012: http://europar2012.cti.gr/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 17:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 17:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR5AL-0003rC-5G; Sun, 06 May 2012 17:22:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR5AJ-0003r3-Qa for xen-devel@lists.xensource.com; Sun, 06 May 2012 17:22:36 +0000 Received: from [85.158.143.99:33876] by server-2.bemta-4.messagelabs.com id 90/CB-17550-B53B6AF4; Sun, 06 May 2012 17:22:35 +0000 X-Env-Sender: vhpc.dist@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336324950!23353311!1 X-Originating-IP: [209.85.210.47] X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19223 invoked from network); 6 May 2012 17:22:32 -0000 Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2012 17:22:32 -0000 Received: by dalh21 with SMTP id h21so5661615dal.6 for ; Sun, 06 May 2012 10:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2EMWtPczTKE2wwm5BzOPswJX9/qXDlemqHKdc3sUpAc=; b=iOwSOCdVCkY/WItVpiUcuAN5WDeRxZbb1FS9/dGxBr4GFQIwf8u6zHGvpLae4yuWSU 7ej0PCWhF/+0uRU7bUYG6fsq25ODhJYuZNLUAo2/dDjD8AyUe2nI9mSLQ6G4YCZS0Vyp JfWSLOF7WSov6Y6KC2Lw0RIXTerAuvssqVWtXWd74yeqoPc2FlK3Lqp5aA+RUbOT2x97 DMl0dKJc8rC3Of/JRL1X8XUojBUpVmKgvd7sU1SP3vc7amrjG0Uy69NRz1pvvLPuxLFg WP6xpTtss2wzZbnxvOQQU86UWvQrKM1VDklQxoh38urYQpHI1rpLxF4MZ3HxqdVL24YB /Npw== MIME-Version: 1.0 Received: by 10.68.224.36 with SMTP id qz4mr7804250pbc.69.1336324949757; Sun, 06 May 2012 10:22:29 -0700 (PDT) Received: by 10.68.223.1 with HTTP; Sun, 6 May 2012 10:22:29 -0700 (PDT) Date: Sun, 6 May 2012 19:22:29 +0200 Message-ID: From: VHPC 12 To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com Subject: [Xen-devel] Submission Deadline Extension X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org we apologize if you receive multiple copies of this CFP =================================================================== CALL FOR PAPERS 7th Workshop on Virtualization in High-Performance Cloud Computing VHPC '12 as part of Euro-Par 2012, Rhodes Island, Greece =================================================================== Date: August 28, 2012 Workshop URL: http://vhpc.org SUBMISSION DEADLINE: June 11, 2012 - Full paper submission (extended) SCOPE: Virtualization has become a common abstraction layer in modern data centers, enabling resource owners to manage complex infrastructure independently of their applications. Conjointly, virtualization is becoming a driving technology for a manifold of industry grade IT services. The cloud concept includes the notion of a separation between resource owners and users, adding services such as hosted application frameworks and queueing. Utilizing the same infrastructure, clouds carry significant potential for use in high-performance scientific computing. The ability of clouds to provide for requests and releases of vast computing resources dynamically and close to the marginal cost of providing the services is unprecedented in the history of scientific and commercial computing. Distributed computing concepts that leverage federated resource access are popular within the grid community, but have not seen previously desired deployed levels so far. Also, many of the scientific data centers have not adopted virtualization or cloud concepts yet. This workshop aims to bring together industrial providers with the scientific community in order to foster discussion, collaboration and mutual exchange of knowledge and experience. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections. Presentations may be accompanied by interactive demonstrations. TOPICS Topics of interest include, but are not limited to: Higher-level cloud architectures, focusing on issues such as: - Languages for describing highly-distributed compute jobs - Workload characterization for VM-based environments - Optimized communication libraries/protocols in the cloud - Cross-layer optimization of numeric algorithms on VM infrastructure - System and process/bytecode VM convergence - Cloud frameworks and API sets - Checkpointing/migration of large compute jobs - Instrumentation interfaces and languages - VMM performance (auto-)tuning on various load types - Cloud reliability, fault-tolerance, and security - Software as a Service (SaaS) architectures - Research and education use cases - Virtualization in cloud, cluster and grid environments - Cross-layer VM optimizations - Cloud use cases including optimizations - VM-based cloud performance modelling - Performance and cost modelling Lower-level design challenges for Hypervisors, VM-aware I/O devices, hardware accelerators or filesystems in VM environments, especially: - Cloud, grid and distributed filesystems - Hardware for I/O virtualization (storage/network/accelerators) - Storage and network I/O subsystems in virtualized environments - Novel software approaches to I/O virtualization - Paravirtualized I/O subsystems for modified/unmodified guests - Virtualization-aware cluster interconnects - Direct device assignment - NUMA-aware subsystems in virtualized environments - Hardware Accelerators in virtualization (GPUs/FPGAs) - Hardware extensions for virtualization - VMMs/Hypervisors for embedded systems Data Center management methods, including: - QoS and and service levels - VM cloud and cluster distribution algorithms - VM load-balancing in Clouds - Hypervisor extensions and tools for cluster and grid computing - Fault tolerant VM environments - Virtual machine monitor platforms - Management, deployment and monitoring of VM-based environments - Cluster provisioning in the Cloud PAPER SUBMISSION Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, key words, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in the Springer LNCS series - the format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Format Guidelines: http://www.springer.de/comp/lncs/authors.html Style template: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Abstract Submission Link: http://edas.info/newPaper.php?c=11943 IMPORTANT DATES Rolling abstract submission June 11, 2012 - Full paper submission (extended) June 29, 2012 - Acceptance notification July 20, 2012 - Camera-ready version due August 28, 2012 - Workshop Date CHAIR Michael Alexander (chair), TU Wien, Austria Gianluigi Zanetti (co-chair), CRS4, Italy Anastassios Nanos (co-chair), NTUA, Greece PROGRAM COMMITTEE Paolo Anedda, CRS4, Italy Giovanni Busonera, CRS4, Italy Brad Calder, Microsoft, USA Roberto Canonico, University of Napoli Federico II, Italy Tommaso Cucinotta, Alcatel-Lucent Bell Labs, Ireland Werner Fischer, Thomas-Krenn AG, Germany William Gardner, University of Guelph, USA Marcus Hardt, Forschungszentrum Karlsruhe, Germany Sverre Jarp, CERN, Switzerland Shantenu Jha, Louisiana State University, USA Xuxian Jiang, NC State, USA Nectarios Koziris, National Technical University of Athens, Greece Simone Leo, CRS4, Italy Ignacio Llorente, Universidad Complutense de Madrid, Spain Naoya Maruyama, Tokyo Institute of Technology, Japan Jean-Marc Menaud, Ecole des Mines de Nantes, France Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece Jose Renato Santos, HP Labs, USA Walter Schwaiger, TU Wien, Austria Yoshio Turner, HP Labs, USA Kurt Tutschku, University of Vienna, Austria Lizhe Wang, Indiana University, USA Chao-Tung Yang, Tunghai University, Taiwan DURATION: Workshop Duration is one day. GENERAL INFORMATION The workshop will be held as part of Euro-Par 2012. Euro-Par 2012: http://europar2012.cti.gr/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 21:27:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 21: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 ) id 1SR8yt-00056G-HA; Sun, 06 May 2012 21:27:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR8ys-00056B-2o for xen-devel@lists.xensource.com; Sun, 06 May 2012 21:27:02 +0000 Received: from [85.158.138.51:55395] by server-9.bemta-3.messagelabs.com id AF/18-26691-5ACE6AF4; Sun, 06 May 2012 21:27:01 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336339620!25497073!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5907 invoked from network); 6 May 2012 21:27:00 -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; 6 May 2012 21:27:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12319406" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 21:26:59 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 22:26:59 +0100 Date: Sun, 6 May 2012 22:23:37 +0100 From: Goncalo Gomes To: Ian Campbell Message-ID: <20120506212337.GA15262@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336296147.5933.5.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 06 May 2012, Ian Campbell wrote: > I've tried reproducing using your config file with the patch applied and > I can't. > > > [...] > > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > > which gets triggered from an erroneous b_info->type with a bogus value > > of 0x84 (which is neither PV nor HVM.) > > I think it might be useful to sprinkle prints of b_info->type everywhere > from the call to libxl_domain_build_info_init_type up until this switch > statement to see if you can identify the line which is overwriting this > field. I couldn't spot it by eye but something in there is presumably > blowing off the end of a buffer or something similar. > > You should probably also validate the initial value, which comes from > c_info->type, and if that is wrong trace it back to the place which sets > that initial value. Running 'make install' after various attempts seems to have done it. I was all along under the impression that the dynamic linker would pick the libxenlight in the current dir, which is why I hadn't run 'make install' every so often, but did instead occasionally run 'make clean all' Coming to think of it, if the DLD was to pick the library from the current directory, a world of security bugs and pain would ensue, but for some reason I kept expecting the behaviour to be that. Thanks though! Goncalo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 06 21:27:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 May 2012 21: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 ) id 1SR8yt-00056G-HA; Sun, 06 May 2012 21:27:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SR8ys-00056B-2o for xen-devel@lists.xensource.com; Sun, 06 May 2012 21:27:02 +0000 Received: from [85.158.138.51:55395] by server-9.bemta-3.messagelabs.com id AF/18-26691-5ACE6AF4; Sun, 06 May 2012 21:27:01 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336339620!25497073!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ4Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5907 invoked from network); 6 May 2012 21:27:00 -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; 6 May 2012 21:27:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12319406" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 May 2012 21:26:59 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 6 May 2012 22:26:59 +0100 Date: Sun, 6 May 2012 22:23:37 +0100 From: Goncalo Gomes To: Ian Campbell Message-ID: <20120506212337.GA15262@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336296147.5933.5.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 06 May 2012, Ian Campbell wrote: > I've tried reproducing using your config file with the patch applied and > I can't. > > > [...] > > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > > which gets triggered from an erroneous b_info->type with a bogus value > > of 0x84 (which is neither PV nor HVM.) > > I think it might be useful to sprinkle prints of b_info->type everywhere > from the call to libxl_domain_build_info_init_type up until this switch > statement to see if you can identify the line which is overwriting this > field. I couldn't spot it by eye but something in there is presumably > blowing off the end of a buffer or something similar. > > You should probably also validate the initial value, which comes from > c_info->type, and if that is wrong trace it back to the place which sets > that initial value. Running 'make install' after various attempts seems to have done it. I was all along under the impression that the dynamic linker would pick the libxenlight in the current dir, which is why I hadn't run 'make install' every so often, but did instead occasionally run 'make clean all' Coming to think of it, if the DLD was to pick the library from the current directory, a world of security bugs and pain would ensue, but for some reason I kept expecting the behaviour to be that. Thanks though! Goncalo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002Zd-JB; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YW-BG for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55191] by server-7.bemta-3.messagelabs.com id 20/4E-03078-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20777 invoked from network); 7 May 2012 02:24:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320403" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: c2ed845386befd621e7433d5f3694c8e61622282 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:21 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 6 of 6] xl: extend the help options of the create and restore commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r ed41714d9ce9 -r c2ed845386be tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdtable.c Mon May 07 01:10:58 2012 +0000 @@ -30,7 +30,10 @@ struct cmd_spec cmd_table[] = { "-n, --dryrun Dry run - prints the resulting configuration\n" " (deprecated in favour of global -N option).\n" "-d Enable debug messages.\n" - "-e Do not wait in the background for the death of the domain." + "-e Do not wait in the background for the death of the domain.\n" + "-V, --vncviewer Connect to the VNC display after the domain is created.\n" + "-A, --vncviewer-autopass\n" + " Pass VNC password to viewer via stdin." }, { "config-update", &main_config_update, 1, @@ -147,7 +150,9 @@ struct cmd_spec cmd_table[] = { "-h Print this help.\n" "-p Do not unpause domain after restoring it.\n" "-e Do not wait in the background for the death of the domain.\n" - "-d Enable debug messages." + "-d Enable debug messages.\n" + "-V Connect to the VNC display after the domain is created.\n" + "-A Pass VNC password to viewer via stdin." }, { "migrate-receive", &main_migrate_receive, 0, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002Zd-JB; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YW-BG for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55191] by server-7.bemta-3.messagelabs.com id 20/4E-03078-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20777 invoked from network); 7 May 2012 02:24:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320403" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: c2ed845386befd621e7433d5f3694c8e61622282 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:21 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 6 of 6] xl: extend the help options of the create and restore commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r ed41714d9ce9 -r c2ed845386be tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdtable.c Mon May 07 01:10:58 2012 +0000 @@ -30,7 +30,10 @@ struct cmd_spec cmd_table[] = { "-n, --dryrun Dry run - prints the resulting configuration\n" " (deprecated in favour of global -N option).\n" "-d Enable debug messages.\n" - "-e Do not wait in the background for the death of the domain." + "-e Do not wait in the background for the death of the domain.\n" + "-V, --vncviewer Connect to the VNC display after the domain is created.\n" + "-A, --vncviewer-autopass\n" + " Pass VNC password to viewer via stdin." }, { "config-update", &main_config_update, 1, @@ -147,7 +150,9 @@ struct cmd_spec cmd_table[] = { "-h Print this help.\n" "-p Do not unpause domain after restoring it.\n" "-e Do not wait in the background for the death of the domain.\n" - "-d Enable debug messages." + "-d Enable debug messages.\n" + "-V Connect to the VNC display after the domain is created.\n" + "-A Pass VNC password to viewer via stdin." }, { "migrate-receive", &main_migrate_receive, 0, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002Zo-Vb; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002Yg-LZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.139.83:61276] by server-5.bemta-5.messagelabs.com id 61/6E-13566-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336357447!15768639!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19373 invoked from network); 7 May 2012 02:24:08 -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; 7 May 2012 02:24:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320401" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: 0663afbb57f586cea07ff916d34cb8f56f633942 Message-ID: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:19 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 497a6061df08 -r 0663afbb57f5 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 @@ -186,6 +186,14 @@ static void find_domain(const char *p) common_domname = was_name ? p : libxl_domid_to_name(ctx, domid); } +static int vncviewer(const char *domain_spec, int autopass) +{ + find_domain(domain_spec); + libxl_vncviewer_exec(ctx, domid, autopass); + fprintf(stderr, "Unable to execute vncviewer\n"); + return 1; +} + static int acquire_lock(void) { int rc; @@ -2170,14 +2178,6 @@ int main_console(int argc, char **argv) return 1; } -static int vncviewer(const char *domain_spec, int autopass) -{ - find_domain(domain_spec); - libxl_vncviewer_exec(ctx, domid, autopass); - fprintf(stderr, "Unable to execute vncviewer\n"); - return 1; -} - int main_vncviewer(int argc, char **argv) { static const struct option long_options[] = { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002Zo-Vb; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002Yg-LZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.139.83:61276] by server-5.bemta-5.messagelabs.com id 61/6E-13566-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336357447!15768639!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19373 invoked from network); 7 May 2012 02:24:08 -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; 7 May 2012 02:24:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320401" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: 0663afbb57f586cea07ff916d34cb8f56f633942 Message-ID: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:19 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 497a6061df08 -r 0663afbb57f5 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 @@ -186,6 +186,14 @@ static void find_domain(const char *p) common_domname = was_name ? p : libxl_domid_to_name(ctx, domid); } +static int vncviewer(const char *domain_spec, int autopass) +{ + find_domain(domain_spec); + libxl_vncviewer_exec(ctx, domid, autopass); + fprintf(stderr, "Unable to execute vncviewer\n"); + return 1; +} + static int acquire_lock(void) { int rc; @@ -2170,14 +2178,6 @@ int main_console(int argc, char **argv) return 1; } -static int vncviewer(const char *domain_spec, int autopass) -{ - find_domain(domain_spec); - libxl_vncviewer_exec(ctx, domid, autopass); - fprintf(stderr, "Unable to execute vncviewer\n"); - return 1; -} - int main_vncviewer(int argc, char **argv) { static const struct option long_options[] = { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002ZW-6u; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YU-7T for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55209] by server-11.bemta-3.messagelabs.com id 96/DC-18894-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20768 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320402" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: ed41714d9ce9bc73b792782299ada259c7763db6 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:20 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 5 of 6] xl: Add vncviewer options to create and restore X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 0663afbb57f5 -r ed41714d9ce9 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 @@ -736,6 +736,7 @@ static void parse_config_data(const char if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) b_info->rtc_timeoffset = l; + xlu_cfg_get_defbool(config, "vncviewer", &b_info->vncviewer, 0); xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); if (!xlu_cfg_get_long (config, "videoram", &l, 0)) @@ -1414,6 +1415,8 @@ struct domain_create { int paused; int dryrun; int quiet; + int vnc; + int vncautopass; int console_autoconnect; const char *config_file; const char *extra_config; /* extra config string */ @@ -1527,6 +1530,8 @@ static int create_domain(struct domain_c int daemonize = dom_info->daemonize; int monitor = dom_info->monitor; int paused = dom_info->paused; + int vnc = dom_info->vnc; + int vncautopass = dom_info->vncautopass; const char *config_file = dom_info->config_file; const char *extra_config = dom_info->extra_config; const char *restore_file = dom_info->restore_file; @@ -1734,6 +1739,14 @@ start: if (!daemonize && !monitor) goto out; + if (vnc || (libxl_defbool_val(d_config.b_info.vncviewer) == 1)) { + char *domspec = libxl_domid_to_name(ctx, domid); + if (domspec) { + vncviewer(domspec, vncautopass); + free(domsec); + } + } + if (need_daemon) { char *fullname, *name; pid_t child1, got_child; @@ -3033,10 +3046,10 @@ int main_restore(int argc, char **argv) const char *config_file = NULL; struct domain_create dom_info; int paused = 0, debug = 0, daemonize = 1, monitor = 1, - console_autoconnect = 0; + console_autoconnect = 0, vnc = 0, vncautopass = 0; int opt, rc; - while ((opt = def_getopt(argc, argv, "Fcpde", "restore", 1)) != -1) { + while ((opt = def_getopt(argc, argv, "FcpdeVA", "restore", 1)) != -1) { switch (opt) { case 0: case 2: return opt; @@ -3056,6 +3069,12 @@ int main_restore(int argc, char **argv) daemonize = 0; monitor = 0; break; + case 'V': + vnc = 1; + break; + case 'A': + vnc = vncautopass = 1; + break; } } @@ -3077,6 +3096,8 @@ int main_restore(int argc, char **argv) dom_info.config_file = config_file; dom_info.restore_file = checkpoint_file; dom_info.migrate_fd = -1; + dom_info.vnc = vnc; + dom_info.vncautopass = vncautopass; dom_info.console_autoconnect = console_autoconnect; dom_info.incr_generationid = 1; @@ -3384,7 +3405,7 @@ int main_create(int argc, char **argv) char extra_config[1024]; struct domain_create dom_info; int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0, - quiet = 0, monitor = 1; + quiet = 0, monitor = 1, vnc = 0, vncautopass = 0; int opt, rc; int option_index = 0; static struct option long_options[] = { @@ -3392,6 +3413,8 @@ int main_create(int argc, char **argv) {"quiet", 0, 0, 'q'}, {"help", 0, 0, 'h'}, {"defconfig", 1, 0, 'f'}, + {"vncviewer", 0, 0, 'V'}, + {"vncviewer-autopass", 0, 0, 'A'}, {0, 0, 0, 0} }; @@ -3401,7 +3424,7 @@ int main_create(int argc, char **argv) } while (1) { - opt = getopt_long(argc, argv, "Fhnqf:pcde", long_options, &option_index); + opt = getopt_long(argc, argv, "Fhnqf:pcdeVA", long_options, &option_index); if (opt == -1) break; @@ -3434,6 +3457,12 @@ int main_create(int argc, char **argv) case 'q': quiet = 1; break; + case 'V': + vnc = 1; + break; + case 'A': + vnc = vncautopass = 1; + break; default: fprintf(stderr, "option `%c' not supported.\n", optopt); break; @@ -3463,6 +3492,8 @@ int main_create(int argc, char **argv) dom_info.config_file = filename; dom_info.extra_config = extra_config; dom_info.migrate_fd = -1; + dom_info.vnc = vnc; + dom_info.vncautopass = vncautopass; dom_info.console_autoconnect = console_autoconnect; dom_info.incr_generationid = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcS-0002ZW-6u; Mon, 07 May 2012 02:24:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YU-7T for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55209] by server-11.bemta-3.messagelabs.com id 96/DC-18894-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20768 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320402" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: ed41714d9ce9bc73b792782299ada259c7763db6 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:20 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 5 of 6] xl: Add vncviewer options to create and restore X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 0663afbb57f5 -r ed41714d9ce9 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 @@ -736,6 +736,7 @@ static void parse_config_data(const char if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0)) b_info->rtc_timeoffset = l; + xlu_cfg_get_defbool(config, "vncviewer", &b_info->vncviewer, 0); xlu_cfg_get_defbool(config, "localtime", &b_info->localtime, 0); if (!xlu_cfg_get_long (config, "videoram", &l, 0)) @@ -1414,6 +1415,8 @@ struct domain_create { int paused; int dryrun; int quiet; + int vnc; + int vncautopass; int console_autoconnect; const char *config_file; const char *extra_config; /* extra config string */ @@ -1527,6 +1530,8 @@ static int create_domain(struct domain_c int daemonize = dom_info->daemonize; int monitor = dom_info->monitor; int paused = dom_info->paused; + int vnc = dom_info->vnc; + int vncautopass = dom_info->vncautopass; const char *config_file = dom_info->config_file; const char *extra_config = dom_info->extra_config; const char *restore_file = dom_info->restore_file; @@ -1734,6 +1739,14 @@ start: if (!daemonize && !monitor) goto out; + if (vnc || (libxl_defbool_val(d_config.b_info.vncviewer) == 1)) { + char *domspec = libxl_domid_to_name(ctx, domid); + if (domspec) { + vncviewer(domspec, vncautopass); + free(domsec); + } + } + if (need_daemon) { char *fullname, *name; pid_t child1, got_child; @@ -3033,10 +3046,10 @@ int main_restore(int argc, char **argv) const char *config_file = NULL; struct domain_create dom_info; int paused = 0, debug = 0, daemonize = 1, monitor = 1, - console_autoconnect = 0; + console_autoconnect = 0, vnc = 0, vncautopass = 0; int opt, rc; - while ((opt = def_getopt(argc, argv, "Fcpde", "restore", 1)) != -1) { + while ((opt = def_getopt(argc, argv, "FcpdeVA", "restore", 1)) != -1) { switch (opt) { case 0: case 2: return opt; @@ -3056,6 +3069,12 @@ int main_restore(int argc, char **argv) daemonize = 0; monitor = 0; break; + case 'V': + vnc = 1; + break; + case 'A': + vnc = vncautopass = 1; + break; } } @@ -3077,6 +3096,8 @@ int main_restore(int argc, char **argv) dom_info.config_file = config_file; dom_info.restore_file = checkpoint_file; dom_info.migrate_fd = -1; + dom_info.vnc = vnc; + dom_info.vncautopass = vncautopass; dom_info.console_autoconnect = console_autoconnect; dom_info.incr_generationid = 1; @@ -3384,7 +3405,7 @@ int main_create(int argc, char **argv) char extra_config[1024]; struct domain_create dom_info; int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0, - quiet = 0, monitor = 1; + quiet = 0, monitor = 1, vnc = 0, vncautopass = 0; int opt, rc; int option_index = 0; static struct option long_options[] = { @@ -3392,6 +3413,8 @@ int main_create(int argc, char **argv) {"quiet", 0, 0, 'q'}, {"help", 0, 0, 'h'}, {"defconfig", 1, 0, 'f'}, + {"vncviewer", 0, 0, 'V'}, + {"vncviewer-autopass", 0, 0, 'A'}, {0, 0, 0, 0} }; @@ -3401,7 +3424,7 @@ int main_create(int argc, char **argv) } while (1) { - opt = getopt_long(argc, argv, "Fhnqf:pcde", long_options, &option_index); + opt = getopt_long(argc, argv, "Fhnqf:pcdeVA", long_options, &option_index); if (opt == -1) break; @@ -3434,6 +3457,12 @@ int main_create(int argc, char **argv) case 'q': quiet = 1; break; + case 'V': + vnc = 1; + break; + case 'A': + vnc = vncautopass = 1; + break; default: fprintf(stderr, "option `%c' not supported.\n", optopt); break; @@ -3463,6 +3492,8 @@ int main_create(int argc, char **argv) dom_info.config_file = filename; dom_info.extra_config = extra_config; dom_info.migrate_fd = -1; + dom_info.vnc = vnc; + dom_info.vncautopass = vncautopass; dom_info.console_autoconnect = console_autoconnect; dom_info.incr_generationid = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcQ-0002Z1-Nk; Mon, 07 May 2012 02:24:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YU-LZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:08 +0000 Received: from [85.158.138.51:55155] by server-11.bemta-3.messagelabs.com id D2/DC-18894-74237AF4; Mon, 07 May 2012 02:24:07 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20650 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320397" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:50 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:15 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 0 of 6] Add vncviewer xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following series of patches introduce vncviewer compatibility options to the create and restore commands. It also introduces a boolean vncviewer keyword in configuration files. Signed-off-by: Goncalo Gomes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcQ-0002Z1-Nk; Mon, 07 May 2012 02:24:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YU-LZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:08 +0000 Received: from [85.158.138.51:55155] by server-11.bemta-3.messagelabs.com id D2/DC-18894-74237AF4; Mon, 07 May 2012 02:24:07 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20650 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320397" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:50 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:15 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 0 of 6] Add vncviewer xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following series of patches introduce vncviewer compatibility options to the create and restore commands. It also introduces a boolean vncviewer keyword in configuration files. Signed-off-by: Goncalo Gomes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002Z8-48; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YV-NG for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:08 +0000 Received: from [85.158.138.51:55164] by server-5.bemta-3.messagelabs.com id 63/43-17113-74237AF4; Mon, 07 May 2012 02:24:07 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320398" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:50 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 X-Mercurial-Node: 53f124f82cfd5a8760bb64acf9842f13dba5cf85 Message-ID: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:16 +0000 From: Goncalo Gomes To: xen-devel@lists.xensource.com Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 @@ -120,6 +120,14 @@ Use the given configuration file. Leave the domain paused after it is created. +=item B<-V>, B<--vncviewer> + +Attach to domain's VNC server, forking a vncviewer process. + +=item B<-A>, B<--vncviewer-autopass> + +Pass VNC password to vncviewer via stdin. + =item B<-c> Attach console to the domain as soon as it has started. This is @@ -433,6 +441,14 @@ See the corresponding option of the I + +Attach to domain's VNC server, forking a vncviewer process. + +=item B<-A> + +Pass VNC password to vncviewer via stdin. + =back =item B [I] I I [I] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002Z8-48; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YV-NG for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:08 +0000 Received: from [85.158.138.51:55164] by server-5.bemta-3.messagelabs.com id 63/43-17113-74237AF4; Mon, 07 May 2012 02:24:07 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320398" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:50 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 X-Mercurial-Node: 53f124f82cfd5a8760bb64acf9842f13dba5cf85 Message-ID: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:16 +0000 From: Goncalo Gomes To: xen-devel@lists.xensource.com Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 @@ -120,6 +120,14 @@ Use the given configuration file. Leave the domain paused after it is created. +=item B<-V>, B<--vncviewer> + +Attach to domain's VNC server, forking a vncviewer process. + +=item B<-A>, B<--vncviewer-autopass> + +Pass VNC password to vncviewer via stdin. + =item B<-c> Attach console to the domain as soon as it has started. This is @@ -433,6 +441,14 @@ See the corresponding option of the I + +Attach to domain's VNC server, forking a vncviewer process. + +=item B<-A> + +Pass VNC password to vncviewer via stdin. + =back =item B [I] I I [I] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002ZF-FD; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YW-Ti for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:2389] by server-7.bemta-3.messagelabs.com id EE/3E-03078-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20747 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320399" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 X-Mercurial-Node: 79526068a8743f4a593c41447b3ab92c6fbc5661 Message-ID: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:17 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 53f124f82cfd -r 79526068a874 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 Mon May 07 01:10:57 2012 +0000 +++ b/docs/man/xl.cfg.pod.5 Mon May 07 01:10:58 2012 +0000 @@ -624,6 +624,11 @@ frequency changes. Please see F for more information on this option. +=item B + +Automatically attach to domain's VNC server forking a vncviewer process +on domain creation and/or restore. + =item B Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002ZF-FD; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcO-0002YW-Ti for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:2389] by server-7.bemta-3.messagelabs.com id EE/3E-03078-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20747 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320399" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:50 +0100 MIME-Version: 1.0 X-Mercurial-Node: 79526068a8743f4a593c41447b3ab92c6fbc5661 Message-ID: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:17 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 53f124f82cfd -r 79526068a874 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 Mon May 07 01:10:57 2012 +0000 +++ b/docs/man/xl.cfg.pod.5 Mon May 07 01:10:58 2012 +0000 @@ -624,6 +624,11 @@ frequency changes. Please see F for more information on this option. +=item B + +Automatically attach to domain's VNC server forking a vncviewer process +on domain creation and/or restore. + =item B Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002ZM-Qj; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YX-1H for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55168] by server-2.bemta-3.messagelabs.com id 07/C6-09269-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20756 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320400" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: 497a6061df08d6451f3b4e77e1f66f94ece62225 Message-ID: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:18 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 3 of 6] libxl: add vncviewer boolean options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) b_info->target_memkb = b_info->max_memkb; + libxl_defbool_setdefault(&b_info->vncviewer, false); libxl_defbool_setdefault(&b_info->localtime, false); libxl_defbool_setdefault(&b_info->disable_migrate, false); diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain ("video_memkb", MemKB), ("shadow_memkb", MemKB), ("rtc_timeoffset", uint32), + ("vncviewer", libxl_defbool), ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 02:24:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 02:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcR-0002ZM-Qj; Mon, 07 May 2012 02:24:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRDcP-0002YX-1H for xen-devel@lists.xensource.com; Mon, 07 May 2012 02:24:09 +0000 Received: from [85.158.138.51:55168] by server-2.bemta-3.messagelabs.com id 07/C6-09269-84237AF4; Mon, 07 May 2012 02:24:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336357447!17667389!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20756 invoked from network); 7 May 2012 02:24:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 02:24:07 -0000 X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208";a="12320400" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 02:23:51 +0000 Received: from dt29.uk.xensource.com (10.80.227.196) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 03:23:51 +0100 MIME-Version: 1.0 X-Mercurial-Node: 497a6061df08d6451f3b4e77e1f66f94ece62225 Message-ID: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 7 May 2012 01:20:18 +0000 From: Goncalo Gomes To: Cc: ian.campbell@citrix.com Subject: [Xen-devel] [PATCH 3 of 6] libxl: add vncviewer boolean options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Goncalo Gomes diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) b_info->target_memkb = b_info->max_memkb; + libxl_defbool_setdefault(&b_info->vncviewer, false); libxl_defbool_setdefault(&b_info->localtime, false); libxl_defbool_setdefault(&b_info->disable_migrate, false); diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 +++ b/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain ("video_memkb", MemKB), ("shadow_memkb", MemKB), ("rtc_timeoffset", uint32), + ("vncviewer", libxl_defbool), ("localtime", libxl_defbool), ("disable_migrate", libxl_defbool), ("cpuid", libxl_cpuid_policy_list), _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 05:21:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 05:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGNF-0004lw-Sz; Mon, 07 May 2012 05:20:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGND-0004ln-7F for xen-devel@lists.xen.org; Mon, 07 May 2012 05:20:39 +0000 Received: from [85.158.143.35:4080] by server-1.bemta-4.messagelabs.com id 06/3C-20925-6AB57AF4; Mon, 07 May 2012 05:20:38 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336368032!10022378!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32326 invoked from network); 7 May 2012 05:20:34 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 05:20:34 -0000 Received: by pbbro12 with SMTP id ro12so6577832pbb.32 for ; Sun, 06 May 2012 22:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=MxYDoFmtSQ0DNi50h22iifN3MSva2XrBsm9ZnXk2lfE=; b=vDrbTFj+Xpg20Ja00dRO1NqN2pC3Ab9x4+Twlw9aQs8ns2YgvfI9XIj0syqQi+4N03 +fhugsn1n4mD+XZkaCMO+qRRy6mN0TOkvTh7DHnIOLKoXRxoCYgHmcP+ZR0t3M4O4YBO voTbpZmWUDxadM+sc6oQYi1WR1V//9gAChdIwISUdhqOGP3E8NZwMTPZQYDj3BHgGYwA QjfaGtg533aib6P5CjzJivrB47SAHezeWD5vlrCDASCmRXgBRlnFjKExZxX6ZhU34940 s1JqMUd5EWff2+LxLtiFTFh/yf8wLiikUbj3Cv/DP0KpjUrUdjYUIj1q1/G5hmYRmMcj y1Aw== Received: by 10.68.224.66 with SMTP id ra2mr16991797pbc.103.1336368031612; Sun, 06 May 2012 22:20:31 -0700 (PDT) Received: from [192.168.1.2] (cm11.gamma206.maxonline.com.sg. [202.156.206.11]) by mx.google.com with ESMTPS id nk2sm3731273pbc.54.2012.05.06.22.20.28 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 22:20:30 -0700 (PDT) Message-ID: <4FA75B9B.6000908@gmail.com> Date: Mon, 07 May 2012 13:20:27 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: wei.huang2@amd.com References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F75384B.6080904@gmail.com> <4F75C551.9070700@amd.com> In-Reply-To: <4F75C551.9070700@amd.com> Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3747995595132454217==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============3747995595132454217== Content-Type: multipart/alternative; boundary="------------090102090706070302030002" This is a multi-part message in MIME format. --------------090102090706070302030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/03/2012 22:38, Wei Huang wrote: > On 03/29/2012 11:36 PM, Teo En Ming (Zhang Enming) wrote: >> On 30/03/2012 04:11, Wei Huang wrote: >>> On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: >>>> Dear Casey DeLorme, >>>> >>>> This guy, Sebastien Gauthier, also has the same problems as us. He >>>> was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei >>>> Huang's patch. After installing the latest ATI/AMD Catalyst >>>> drivers, he got a BSOD with Xen VGA Passthrough to Windows 7. >>>> >>>> Please read Sebastien Gauthier's case here: >>>> >>>> http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html >>>> >>>> Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL >>>> SUCCESS, like us. >>>> >>>> Dear Tobias Geiger, >>>> >>>> You were saying that with ATI VGA cards, you do not need to apply >>>> any Xen VGA Passthrough patches. But this guy Sebastien Gauthier >>>> applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after >>>> installing ATI Catalyst drivers. Sebastien Gauthier did not get >>>> 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA >>>> card. >>>> >>> Hi Teo, >>> >>> The VBIOS patch I sent out did not work for all ATI cards. The patch >>> itself assumed certain behavior of GPU VBIOS. But this doesn't apply >>> to every GPU generation. From this perspective, my patch isn't >>> universal. Also there are many factors, some of which are not in >>> control by us (like graphics driver), can contribute to BSOD you >>> mentioned. I am not in a position to debug it for everyone's card >>> (as I don't have all cards). >>> >>> Thanks, >>> -Wei >> >> Dear Mr. Wei Huang at AMD Corporation, >> >> Thank you very much for your kind reply. >> >> I want to buy the following ATI Radeon VGA card. Do you think it >> would work with your Xen VGA Passthrough patch to Xen 4.2-unstable??? >> >> Sapphire HD5450 512MB Singapore Dollars $55 >> >> I am a cheapskate when it comes to spending money. >> > I don't have HD5450 card. So I can't test it and can't answer your > question directly. If I have some time later, I will test other HD5xxx > cards and test you the result. Normally GPUs of same family behave > similarly. >> If your Xen VGA Passthrough patch to Xen 4.2-unstable works with the >> above ATI VGA card, I will go ahead and buy it. Do I have to manually >> patch Xen 4.2-unstable or is your patch already included in Xen >> 4.2-unstable source tree? > My patch was against QEMU. It is not included in the tree. Dear Wei Huang, How do I use your VGA Passthrough patch with Xen 4.2-unstable? Thank you. >> >> Secondly, I have a request/favor to ask of you. Do you think it is >> possible for you to examine the Xen 4.2-unstable VGA Passthrough >> patches hosted at Jean David Techer's website and check if it is >> compatible with Xen 4.2-unstable code? >> >> Thirdly and finally, could you read through my Xen VGA Passthrough >> Version 1.7 documentation to see if there are ANY MISTAKES with >> NVIDIA Geforce 8400 GS VGA Passthrough, because I am only getting >> PARTIAL SUCCESS. >> >> If you could write Xen VGA Passthrough patches, you are an expert >> software engineer. >> >> Thank you very very very much. >> >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >> >>>> -- >>>> Yours sincerely, >>>> >>>> Mr. Teo En Ming (Zhang Enming) >>>> Singapore >>>> >>>> >>>> >>>> >>>> On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: >>>>> On 29/03/2012 12:29, Casey DeLorme wrote: >>>>>> My mistake for not hitting "Reply to All", sorry. >>>>> >>>>> No worries Casey. >>>>> >>>>>> >>>>>> It might be of some value to mention that my tests were with >>>>>> Windows 7, I have no interest in using XP anymore. Also, I did >>>>>> all of my testing through remote VNC, not once did I actually get >>>>>> video, even 2D, working. >>>>> >>>>> I bought 2 copies of Windows XP Home Edition in the past because >>>>> it is cheap, at S$145. I did not buy Windows 7 because it is >>>>> expensive. I got video working all right, but only 2D. I cannot >>>>> get 3D graphics working. >>>>> >>>>>> However, my errors are exactly as you described: >>>>>> >>>>>> 1. Windows recognizes the model (GTX 460), not "unknown PCI device". >>>>>> 2. Device code 43. >>>>>> 3. No resources assigned to the device. >>>>> >>>>> We have the same set of errors. >>>>> >>>>>> >>>>>> Might be worth mentioning, I was able to run the latest nVidia >>>>>> driver installation without errors, but after rebooting there was >>>>>> no change, same error code, still no video. >>>>> >>>>> Same situation here with the latest NVIDIA drivers. But I only >>>>> have 2D video working. I can't get 3D video to work. >>>>> >>>>>> To me this would be evidence that driver version isn't a >>>>>> problem, but then again I didn't have anything actually working. >>>>> >>>>> I agree that driver version isn't a problem. Something is wrong >>>>> somewhere. >>>>> >>>>>> >>>>>> >>>>>> I am an IT student in college, so my experience is limited to >>>>>> mostly programming with very little knowledge of the >>>>>> inner-workings of hardware. So, forgive me for being unable to >>>>>> help with regards to memory addresses on the cards. >>>>> >>>>> I am hoping that Intel engineers and Xen developers would be able >>>>> to help. >>>>> >>>>>> >>>>>> I've been using *nix for about 4 years, and Windows since I my >>>>>> age was a single digit. I have had experience setting up server >>>>>> features such as web, database, and application servers but I am >>>>>> still green when it comes to kernel or hardware configuration. >>>>> >>>>> I started learning Linux/UNIX since the year 2005, that is about 7 >>>>> years ago. I started using Windows when it was version 3.1. I love >>>>> compiling the latest Linux kernel and assembling my own computer >>>>> hardware. >>>>> >>>>>> >>>>>> My Xen adventure began 35 days ago, and it is no exaggeration to >>>>>> say that in those 35 days I have learned more about linux than I >>>>>> had in the past two years. I like challenges as much as the next >>>>>> IT person, but I ran out of time and ideas for debugging my >>>>>> nVidia problems. The nVidia stretch of my adventure lasted for >>>>>> 24 days through 54 fresh linux installations accompanied by over >>>>>> 200~ pages worth of documented failures and not a single pixel >>>>>> sighted. >>>>> >>>>> Why not make your documentation into PDF? It is a very popular >>>>> document format. >>>>> >>>>>> >>>>>> The ATI card took me a day, less than 12 hours of relatively easy >>>>>> debugging by comparison to the aforementioned testing. I do >>>>>> fully understanding financial constraints, but it is a working >>>>>> solution and worth mentioning. I do not know what the prices are >>>>>> like in Singapore, but in the states I was able to buy an ATI >>>>>> Radeon HD 6870 for $160. For me it came down to weighing my >>>>>> objectives against my curiosity. >>>>> >>>>> That ATI Radeon HD 6870 would cost me $279, I think. >>>>> >>>>>> >>>>>> If you do continue your nVidia endeavors I wish you success, but >>>>>> as in my former email VGA passthrough is a new frontier, not even >>>>>> Guru's like David may not be able to help beyond their own >>>>>> hardware experiences. >>>>> >>>>> I don't think VGA passthrough is a new frontier. Oracle VirtualBox >>>>> and Linux KVM supports VGA passthrough as well. Xen ATI VGA >>>>> Passthrough works out of the box, as Tobias Geiger suggested, but >>>>> NVIDIA requires patches. >>>>> >>>>>> >>>>>> >>>>>> Documentation is one problem I agree with you on 100%. I came >>>>>> into this knowing relatively little about Linux & hardware, and >>>>>> nothing about Xen, and most every guide I found assumed I had >>>>>> been in a deep relationship with Linux for many years and had a >>>>>> basic understanding of Xen commands. >>>>> >>>>> I started learning Xen since the year 2007, which is about 5 years >>>>> ago. >>>>> >>>>>> >>>>>> Like you, I intend to use those documented failures as well as my >>>>>> recent success to create a comprehensive guide with photographs, >>>>>> screen captures, and perhaps even videos going from "assembled >>>>>> computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough". >>>>>> Provided the wiki will allow me to upload the screenshots, I'll >>>>>> be certain to post it there. >>>>> >>>>> I will be looking forward to your documentation and videos. Right >>>>> now Xen wiki allows uploading image files and PDF files. Why not >>>>> create a PDF document and share it with all of us? It is known as >>>>> portable document format and is very popular, but it appears that >>>>> xen mailing lists don't like PDF format. >>>>> >>>>> _*I don't like wiki pages because anybody can edit and >>>>> fundamentally mess up the wiki pages, even providing bogus and >>>>> erroneous information. That's why I don't like creating wiki >>>>> pages. Anybody can edit and mess up the information you have >>>>> painstakingly created on the wiki pages. So please take note.*_ >>>>> >>>>> -- >>>>> Yours sincerely, >>>>> >>>>> Mr. Teo En Ming (Zhang Enming) >>>>> Singapore >>>>> >>>>> >>>>>> >>>>>> ~Casey >>>>>> >>>>>> On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) >>>>>> >>>>> > wrote: >>>>>> >>>>>> Dearest Casey DeLorme, >>>>>> >>>>>> Thank you very very much for your kind feedback and input. I >>>>>> would also like to thank Mr. Tobias Geiger, again, for >>>>>> providing his suggestion on exposing the fourth memory region >>>>>> in tools/firmware/hvmloader/acpi/dsdt.asl. _In any case, >>>>>> either exposing the first 3 memory regions only or exposing >>>>>> all the 4 memory regions does not work._ Sadly, Tobias Geiger >>>>>> is unable to help me further. >>>>>> >>>>>> I have asked Jean David Techer, what about the 4th PCI memory >>>>>> region? Why only expose the first 3 PCI memory regions? I >>>>>> don't understand, of course. Jean David Techer did not reply >>>>>> to my question. >>>>>> >>>>>> I have decided to post your prompt reply to the xen-users and >>>>>> xen-devel mailing lists, in case people think that I am >>>>>> finding fault with Jean David Techer, or trying to irritate >>>>>> him, or trying to make him angry, or trying to aggravate him. >>>>>> Jean David Techer replied me with an email saying that I >>>>>> _spent too much time_ and _too bent_ on solving the yellow >>>>>> exclamation mark glitch for my NVIDIA Geforce 8400GS in >>>>>> Device Manager in Windows 8 Consumer Preview and Windows XP >>>>>> Home Edition, and that I sent *_stupid_* requests. Stupid >>>>>> requests? Did he read my emails carefully, word by word? >>>>>> >>>>>> Casey DeLorme, please, can I confirm with you again that you >>>>>> are getting the following errors after applying Jean David >>>>>> Techer's Xen 4.2-unstable VGA Passthrough patches: >>>>>> >>>>>> *_(1) Yellow exclamation mark besides your NVIDIA GTX 460 in >>>>>> Device Manager >>>>>> (2) Windows has stopped this device because it has reported >>>>>> problems. (Code 43) >>>>>> (3) This device isn't using any resources because it has a >>>>>> problem._* >>>>>> >>>>>> Jean David Techer insists that our technical issues are due >>>>>> to a NVIDIA driver problem. He insists that you have to >>>>>> install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. >>>>>> Any other NVIDIA driver versions (above 280.XX) will not >>>>>> work, according to Jean David Techer. *_However, I have tried >>>>>> installing NVIDIA driver versions 275.33 and 275.50 from >>>>>> www.softpedia.com , as he >>>>>> suggested, but it caused my Windows XP Home Edition HVM >>>>>> virtual machine to be destroyed/terminated/crash after a few >>>>>> minutes and my dom0 to crash as well._* NVIDIA driver >>>>>> versions 275.33 and 275.50 for Windows XP 32-bit is not >>>>>> available from the official NVIDIA website. >>>>>> >>>>>> So it is definitely not a NVIDIA driver problem. I suspect >>>>>> that the technical issue has to do with *_MMIO BARs pBAR:vBAR >>>>>> 1:1 matching_*. I don't think there is any problem with >>>>>> vgabios-pt.bin extracted out from our NVIDIA VGA cards, >>>>>> because I have performed a "hexdump -C" on my extracted VGA >>>>>> BIOS EEPROM, or Electrically Erasable Programmable Read Only >>>>>> Memory. >>>>>> >>>>>> Secondly, it does seem strange that Jean David Techer was >>>>>> able to attain *_100%_*, ie. *_perfect success_* with Xen >>>>>> 4.2-unstable VGA Passthrough to his Windows XP 32-bit and >>>>>> 64-bit HVM domU. Have you watched his Youtube video? It is >>>>>> only 4 minutes. Please do watch Jean David Techer's Youtube >>>>>> video at the following URL: >>>>>> >>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough to >>>>>> Windows XP x64 HVM domU Youtube video link: >>>>>> *_http://www.youtube.com/watch?v=3SaYO0ERW44_* >>>>>> >>>>>> I am *_appalled_* and *_baffle__d_* that he has attained >>>>>> *_100% success_* while both of us have only attained >>>>>> *_partial succes__s_* (*_i.e. less than 100%_*) on Xen >>>>>> 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview >>>>>> and Windows XP. >>>>>> >>>>>> *_Solving the yellow exclamation mark issue is important >>>>>> because we would not be able to run 3D graphics benchmarks >>>>>> and play 3D games without solving it. I am not sending silly >>>>>> emails about some yellow marks, as Jean David Techer >>>>>> suggested. I can't even run Unigine Heaven DX11, and 3dmark11 >>>>>> 3D display benchmarks, because of the yellow exclamation mark >>>>>> for NVIDIA Geforce 8400 GS in Device Manager._* >>>>>> >>>>>> Casey DeLorme, with your report on relatively easy success >>>>>> with ATI VGA cards, I think I would go the ATI way, but I >>>>>> would have to spend a few hundred dollars compared to my >>>>>> cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding >>>>>> to go the ATI way, I would also like to continue >>>>>> troubleshooting with the NVIDIA problem, because I consider >>>>>> it to be a technical challenge. >>>>>> >>>>>> In essence, Jean David Techner is considered to be a "boss", >>>>>> or business owner, or proprietor, or technopreneur, or >>>>>> entrepreneur, or technical support officer, or customer >>>>>> support officer, or IT helpdesk engineer, providing services >>>>>> like his forward-ported Xen 4.2-unstable VGA Passthrough >>>>>> patches and the documentation on his blog. I repost Jean >>>>>> David Techer's official website here: >>>>>> >>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: >>>>>> *_http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through_* >>>>>> >>>>>> Jean David Techer's official website is his business venture. >>>>>> >>>>>> Basically, I am Jean David Techer's *_"customer"_*, trying to >>>>>> obtain technical support from him. Of course, he is *_not >>>>>> obliged_* to provide technical support to me since he is >>>>>> providing *_free_* services. It is, after all, an open source >>>>>> software project. Nobody is obliged to provide anybody with >>>>>> technical support. *_To do Jean David Techer justice, he >>>>>> replied most of my questions while avoiding some of my >>>>>> questions._* >>>>>> >>>>>> Finally, I have also failed to obtain technical support from >>>>>> Xen developers like Ian Campbell from *_Citrix Corporation_* >>>>>> and Konrad Wilk from *_Oracle Corporation_*. _*I have always >>>>>> provided all the steps which I have taken, the configuration >>>>>> files and necessary documentation, and kernel messages and >>>>>> error logs*_ to xen-users and xen-devel mailing lists, but >>>>>> they keep insisting I did not provide the information they >>>>>> required. I wondered why. I think they did not read my emails >>>>>> carefully. They told me they would not reply to me any more >>>>>> if I do not provide the information they requested. _*But the >>>>>> problem is that I have always provided information they >>>>>> requested!*_ I think they missed some of my emails, or did >>>>>> not read my emails carefully enough. I am an *_ardent >>>>>> supporter_* and *_SERIOUS software tester_* for open source >>>>>> Xen virtualization/hypervisor but they treated me lightly. >>>>>> _*I always read my emails WORD BY WORD.*_ I have even went to >>>>>> the point of making a video on the *_BUG_* and uploading my >>>>>> video to Youtube. The video is only THREE minutes. >>>>>> >>>>>> _*As everybody says, a picture is worth a thousand words. A >>>>>> video is worth a BILLION words!*_ >>>>>> >>>>>> I have also failed to obtain technical support from Xen >>>>>> developers regarding Xen 4.2-unstable VGA Passthrough. >>>>>> >>>>>> I am hoping Xen 4.2 would have official support for Xen VGA >>>>>> Passthrough for both NVIDIA and ATI cards. >>>>>> >>>>>> Casey DeLorme, thank you very much once again. I will be >>>>>> making changes to my Xen, Linux Kernel and Xen VGA >>>>>> Passthrough Documentation and will be releasing Version 1.7 >>>>>> shortly. Jean David Techer's documentation assumes some level >>>>>> of advanced Linux technical knowledge, so I am writing >>>>>> documentation on my own so that everybody, not just advanced >>>>>> Linux and Xen users, can follow. I have made references to >>>>>> Jean David Techer's documentation in my own documentation. >>>>>> >>>>>> I would be very happy if people would use my documentation. >>>>>> Of course, it satisfies my ego and my vanity. Haha. >>>>>> >>>>>> I have been un-employed for nearly three years now, and I >>>>>> would hesitate to spend a few hundred dollars on an ATI VGA >>>>>> card. I quit my job as an IT engineer 3 years ago because my >>>>>> father suffered from lacunar infarct, or more commonly known >>>>>> as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please >>>>>> understand why I hesitate to buy an ATI VGA card. The >>>>>> cheapest one costs SGD$279. >>>>>> >>>>>> I have a diploma in Mechanical+Electronics engineering from >>>>>> Singapore Polytechnic and a Bachelor's degree in Mechanical >>>>>> Engineering from the National University of Singapore. But I >>>>>> do not have qualifications in Computer Science or Information >>>>>> Technology. I have worked as an Information Technology >>>>>> engineer in Defense Science and Technology Agency, Ministry >>>>>> of Defense, Singapore, National Computer Systems Pte Ltd, >>>>>> Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd. >>>>>> >>>>>> Google search terms: Frenchman Jean David Techer, Singaporean >>>>>> Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough >>>>>> Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 >>>>>> Consumer Preview and Windows XP HVM Virtual Machines >>>>>> >>>>>> Thank you very much for reading my lengthy email. I am always >>>>>> courteous, saying "Please help me. Please. Please. Please." >>>>>> and "Thank you very much for your kind assistance" in my emails. >>>>>> >>>>>> Thank you very much. >>>>>> >>>>>> -- >>>>>> Yours sincerely, >>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>> Singapore Citizen >>>>>> >>>>>> cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, >>>>>> Prime Minister's Office, Republic of Singapore >>>>>> >>>>>> On 29/03/2012 03:53, Casey DeLorme wrote: >>>>>>> Hi Teo, >>>>>>> >>>>>>> I tried David's patch files a while ago *_without success_*. >>>>>>> I had Xen compiled with the patch files and my GTX 460 VGA >>>>>>> BIOS rom, _*but I got the same as you, either a BSOD or Code >>>>>>> 43 in Device Manager.*_ >>>>>>> >>>>>>> You sound plenty competent, but it's important to remember >>>>>>> that you are pioneering a technology that for consumers is >>>>>>> still in its infancy. Very few people are testing this with >>>>>>> consumer equipment, so finding results seems to be a rarity. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-users mailing list >>>>>> Xen-users@lists.xen.org >>>>>> http://lists.xen.org/xen-users >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------090102090706070302030002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 30/03/2012 22:38, Wei Huang wrote:
On 03/29/2012 11:36 PM, Teo En Ming (Zhang Enming) wrote:
On 30/03/2012 04:11, Wei Huang wrote:
On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote:
Dear Casey DeLorme,

This guy, Sebastien Gauthier, also has the same problems as us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS, like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen VGA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst drivers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA card.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU generation. From this perspective, my patch isn't universal. Also there are many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you mentioned. I am not in a position to debug it for everyone's card (as I don't have all cards).

Thanks,
-Wei

Dear Mr. Wei Huang at AMD Corporation,

Thank you very much for your kind reply.

I want to buy the following ATI Radeon VGA card. Do you think it would work with your Xen VGA Passthrough patch to Xen 4.2-unstable???

Sapphire HD5450 512MB             Singapore Dollars $55

I am a cheapskate when it comes to spending money.

I don't have HD5450 card. So I can't test it and can't answer your question directly. If I have some time later, I will test other HD5xxx cards and test you the result. Normally GPUs of same family behave similarly.
If your Xen VGA Passthrough patch to Xen 4.2-unstable works with the above ATI VGA card, I will go ahead and buy it. Do I have to manually patch Xen 4.2-unstable or is your patch already included in Xen 4.2-unstable source tree?
My patch was against QEMU. It is not included in the tree.


Dear Wei Huang,

How do I use your VGA Passthrough patch with Xen 4.2-unstable?

Thank you.



Secondly, I have a request/favor to ask of you. Do you think it is possible for you to examine the Xen 4.2-unstable VGA Passthrough patches hosted at Jean David Techer's website and check if it is compatible with Xen 4.2-unstable code?

Thirdly and finally, could you read through my Xen VGA Passthrough Version 1.7 documentation to see if there are ANY MISTAKES with NVIDIA Geforce 8400 GS VGA Passthrough, because I am only getting PARTIAL SUCCESS.

If you could write Xen VGA Passthrough patches, you are an expert software engineer.

Thank you very very very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:
On 29/03/2012 12:29, Casey DeLorme wrote:
My mistake for not hitting "Reply to All", sorry.

No worries Casey.


It might be of some value to mention that my tests were with Windows 7, I have no interest in using XP anymore.  Also, I did all of my testing through remote VNC, not once did I actually get video, even 2D, working. 

I bought 2 copies of Windows XP Home Edition in the past because it is cheap, at S$145. I did not buy Windows 7 because it is expensive. I got video working all right, but only 2D. I cannot get 3D graphics working.

However, my errors are exactly as you described:

1.  Windows recognizes the model (GTX 460), not "unknown PCI device".
2.  Device code 43.
3.  No resources assigned to the device.

We have the same set of errors.


Might be worth mentioning, I was able to run the latest nVidia driver installation without errors, but after rebooting there was no change, same error code, still no video.

Same situation here with the latest NVIDIA drivers. But I only have 2D video working. I can't get 3D video to work.

 To me this would be evidence that driver version isn't a problem, but then again I didn't have anything actually working.

I agree that driver version isn't a problem. Something is wrong somewhere.



I am an IT student in college, so my experience is limited to mostly programming with very little knowledge of the inner-workings of hardware.  So, forgive me for being unable to help with regards to memory addresses on the cards.

I am hoping that Intel engineers and Xen developers would be able to help.


I've been using *nix for about 4 years, and Windows since I my age was a single digit.  I have had experience setting up server features such as web, database, and application servers but I am still green when it comes to kernel or hardware configuration.

I started learning Linux/UNIX since the year 2005, that is about 7 years ago. I started using Windows when it was version 3.1. I love compiling the latest Linux kernel and assembling my own computer hardware.


My Xen adventure began 35 days ago, and it is no exaggeration to say that in those 35 days I have learned more about linux than I had in the past two years.  I like challenges as much as the next IT person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure lasted for 24 days through 54 fresh linux installations accompanied by over 200~ pages worth of documented failures and not a single pixel sighted.

Why not make your documentation into PDF? It is a very popular document format.


The ATI card took me a day, less than 12 hours of relatively easy debugging by comparison to the aforementioned testing.  I do fully understanding financial constraints, but it is a working solution and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy an ATI Radeon HD 6870 for $160.  For me it came down to weighing my objectives against my curiosity.

That ATI Radeon HD 6870 would cost me $279, I think.


If you do continue your nVidia endeavors I wish you success, but as in my former email VGA passthrough is a new frontier, not even Guru's like David may not be able to help beyond their own hardware experiences.

I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linux KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out of the box, as Tobias Geiger suggested, but NVIDIA requires patches.



Documentation is one problem I agree with you on 100%.  I came into this knowing relatively little about Linux & hardware, and nothing about Xen, and most every guide I found assumed I had been in a deep relationship with Linux for many years and had a basic understanding of Xen commands.

I started learning Xen since the year 2007, which is about 5 years ago.


Like you, I intend to use those documented failures as well as my recent success to create a comprehensive guide with photographs, screen captures, and perhaps even videos going from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the screenshots, I'll be certain to post it there.

I will be looking forward to your documentation and videos. Right now Xen wiki allows uploading image files and PDF files. Why not create a PDF document and share it with all of us? It is known as portable document format and is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally mess up the wiki pages, even providing bogus and erroneous information. That's why I don't like creating wiki pages. Anybody can edit and mess up the information you have painstakingly created on the wiki pages. So please take note.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



~Casey

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:
Dearest Casey DeLorme,

Thank you very very much for your kind feedback and input. I would also like to thank Mr. Tobias Geiger, again, for providing his suggestion on exposing the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing all the 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why only expose the first 3 PCI memory regions? I don't understand, of course. Jean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mailing lists, in case people think that I am finding fault with Jean David Techer, or trying to irritate him, or trying to make him angry, or trying to aggravate him. Jean David Techer replied me with an email saying that I spent too much time and too bent on solving the yellow exclamation mark glitch for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails carefully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting the following errors after applying Jean David Techer's Xen 4.2-unstable VGA Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager
(2) Windows has stopped this device because it has reported problems. (Code 43)
(3) This device isn't using any resources because it has a problem.

Jean David Techer insists that our technical issues are due to a NVIDIA driver problem. He insists that you have to install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) will not work, according to Jean David Techer. However, I have tried installing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual machine to be destroyed/terminated/crash after a few minutes and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technical issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM, or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is only 4 minutes. Please do watch Jean David Techer's Youtube video at the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM domU Youtube video link: http://www.youtube.com/watch?v=3SaYO0ERW44

I am appalled and baffled that he has attained 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.

Solving the yellow exclamation mark issue is important because we would not be able to run 3D graphics benchmarks and play 3D games without solving it. I am not sending silly emails about some yellow marks, as Jean David Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.

Casey DeLorme, with your report on relatively easy success with ATI VGA cards, I think I would go the ATI way, but I would have to spend a few hundred dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I consider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or business owner, or proprietor, or technopreneur, or entrepreneur, or technical support officer, or customer support officer, or IT helpdesk engineer, providing services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog. I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", trying to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is providing free services. It is, after all, an open source software project. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions while avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corporation. I have always provided all the steps which I have taken, the configuration files and necessary documentation, and kernel messages and error logs to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information they required. I wondered why. I think they did not read my emails carefully. They told me they would not reply to me any more if I do not provide the information they requested. But the problem is that I have always provided information they requested! I think they missed some of my emails, or did not read my emails carefully enough. I am an ardent supporter and SERIOUS software tester for open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the point of making a video on the BUG and uploading my video to Youtube. The video is only THREE minutes.

As everybody says, a picture is worth a thousand words. A video is worth a BILLION words!

I have also failed to obtain technical support from Xen developers regarding Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be releasing Version 1.7 shortly. Jean David Techer's documentation assumes some level of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not just advanced Linux and Xen users, can follow. I have made references to Jean David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it satisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to spend a few hundred dollars on an ATI VGA card. I quit my job as an IT engineer 3 years ago because my father suffered from lacunar infarct, or more commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy an ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore Polytechnic and a Bachelor's degree in Mechanical Engineering from the National University of Singapore. But I do not have qualifications in Computer Science or Information Technology. I have worked as an Information Technology engineer in Defense Science and Technology Agency, Ministry of Defense, Singapore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Machines

Thank you very much for reading my lengthy email. I am always courteous, saying "Please help me. Please. Please. Please." and "Thank you very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:
Hi Teo,

I tried David's patch files a while ago without success.  I had Xen compiled with the patch files and my GTX 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager.

You sound plenty competent, but it's important to remember that you are pioneering a technology that for consumers is still in its infancy.  Very few people are testing this with consumer equipment, so finding results seems to be a rarity.





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











-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------090102090706070302030002-- --===============3747995595132454217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3747995595132454217==-- From xen-devel-bounces@lists.xen.org Mon May 07 05:21:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 05:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGNF-0004lw-Sz; Mon, 07 May 2012 05:20:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGND-0004ln-7F for xen-devel@lists.xen.org; Mon, 07 May 2012 05:20:39 +0000 Received: from [85.158.143.35:4080] by server-1.bemta-4.messagelabs.com id 06/3C-20925-6AB57AF4; Mon, 07 May 2012 05:20:38 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336368032!10022378!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32326 invoked from network); 7 May 2012 05:20:34 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 05:20:34 -0000 Received: by pbbro12 with SMTP id ro12so6577832pbb.32 for ; Sun, 06 May 2012 22:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=MxYDoFmtSQ0DNi50h22iifN3MSva2XrBsm9ZnXk2lfE=; b=vDrbTFj+Xpg20Ja00dRO1NqN2pC3Ab9x4+Twlw9aQs8ns2YgvfI9XIj0syqQi+4N03 +fhugsn1n4mD+XZkaCMO+qRRy6mN0TOkvTh7DHnIOLKoXRxoCYgHmcP+ZR0t3M4O4YBO voTbpZmWUDxadM+sc6oQYi1WR1V//9gAChdIwISUdhqOGP3E8NZwMTPZQYDj3BHgGYwA QjfaGtg533aib6P5CjzJivrB47SAHezeWD5vlrCDASCmRXgBRlnFjKExZxX6ZhU34940 s1JqMUd5EWff2+LxLtiFTFh/yf8wLiikUbj3Cv/DP0KpjUrUdjYUIj1q1/G5hmYRmMcj y1Aw== Received: by 10.68.224.66 with SMTP id ra2mr16991797pbc.103.1336368031612; Sun, 06 May 2012 22:20:31 -0700 (PDT) Received: from [192.168.1.2] (cm11.gamma206.maxonline.com.sg. [202.156.206.11]) by mx.google.com with ESMTPS id nk2sm3731273pbc.54.2012.05.06.22.20.28 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 22:20:30 -0700 (PDT) Message-ID: <4FA75B9B.6000908@gmail.com> Date: Mon, 07 May 2012 13:20:27 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: wei.huang2@amd.com References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F75384B.6080904@gmail.com> <4F75C551.9070700@amd.com> In-Reply-To: <4F75C551.9070700@amd.com> Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3747995595132454217==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============3747995595132454217== Content-Type: multipart/alternative; boundary="------------090102090706070302030002" This is a multi-part message in MIME format. --------------090102090706070302030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/03/2012 22:38, Wei Huang wrote: > On 03/29/2012 11:36 PM, Teo En Ming (Zhang Enming) wrote: >> On 30/03/2012 04:11, Wei Huang wrote: >>> On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: >>>> Dear Casey DeLorme, >>>> >>>> This guy, Sebastien Gauthier, also has the same problems as us. He >>>> was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei >>>> Huang's patch. After installing the latest ATI/AMD Catalyst >>>> drivers, he got a BSOD with Xen VGA Passthrough to Windows 7. >>>> >>>> Please read Sebastien Gauthier's case here: >>>> >>>> http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html >>>> >>>> Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL >>>> SUCCESS, like us. >>>> >>>> Dear Tobias Geiger, >>>> >>>> You were saying that with ATI VGA cards, you do not need to apply >>>> any Xen VGA Passthrough patches. But this guy Sebastien Gauthier >>>> applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after >>>> installing ATI Catalyst drivers. Sebastien Gauthier did not get >>>> 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA >>>> card. >>>> >>> Hi Teo, >>> >>> The VBIOS patch I sent out did not work for all ATI cards. The patch >>> itself assumed certain behavior of GPU VBIOS. But this doesn't apply >>> to every GPU generation. From this perspective, my patch isn't >>> universal. Also there are many factors, some of which are not in >>> control by us (like graphics driver), can contribute to BSOD you >>> mentioned. I am not in a position to debug it for everyone's card >>> (as I don't have all cards). >>> >>> Thanks, >>> -Wei >> >> Dear Mr. Wei Huang at AMD Corporation, >> >> Thank you very much for your kind reply. >> >> I want to buy the following ATI Radeon VGA card. Do you think it >> would work with your Xen VGA Passthrough patch to Xen 4.2-unstable??? >> >> Sapphire HD5450 512MB Singapore Dollars $55 >> >> I am a cheapskate when it comes to spending money. >> > I don't have HD5450 card. So I can't test it and can't answer your > question directly. If I have some time later, I will test other HD5xxx > cards and test you the result. Normally GPUs of same family behave > similarly. >> If your Xen VGA Passthrough patch to Xen 4.2-unstable works with the >> above ATI VGA card, I will go ahead and buy it. Do I have to manually >> patch Xen 4.2-unstable or is your patch already included in Xen >> 4.2-unstable source tree? > My patch was against QEMU. It is not included in the tree. Dear Wei Huang, How do I use your VGA Passthrough patch with Xen 4.2-unstable? Thank you. >> >> Secondly, I have a request/favor to ask of you. Do you think it is >> possible for you to examine the Xen 4.2-unstable VGA Passthrough >> patches hosted at Jean David Techer's website and check if it is >> compatible with Xen 4.2-unstable code? >> >> Thirdly and finally, could you read through my Xen VGA Passthrough >> Version 1.7 documentation to see if there are ANY MISTAKES with >> NVIDIA Geforce 8400 GS VGA Passthrough, because I am only getting >> PARTIAL SUCCESS. >> >> If you could write Xen VGA Passthrough patches, you are an expert >> software engineer. >> >> Thank you very very very much. >> >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >> >>>> -- >>>> Yours sincerely, >>>> >>>> Mr. Teo En Ming (Zhang Enming) >>>> Singapore >>>> >>>> >>>> >>>> >>>> On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: >>>>> On 29/03/2012 12:29, Casey DeLorme wrote: >>>>>> My mistake for not hitting "Reply to All", sorry. >>>>> >>>>> No worries Casey. >>>>> >>>>>> >>>>>> It might be of some value to mention that my tests were with >>>>>> Windows 7, I have no interest in using XP anymore. Also, I did >>>>>> all of my testing through remote VNC, not once did I actually get >>>>>> video, even 2D, working. >>>>> >>>>> I bought 2 copies of Windows XP Home Edition in the past because >>>>> it is cheap, at S$145. I did not buy Windows 7 because it is >>>>> expensive. I got video working all right, but only 2D. I cannot >>>>> get 3D graphics working. >>>>> >>>>>> However, my errors are exactly as you described: >>>>>> >>>>>> 1. Windows recognizes the model (GTX 460), not "unknown PCI device". >>>>>> 2. Device code 43. >>>>>> 3. No resources assigned to the device. >>>>> >>>>> We have the same set of errors. >>>>> >>>>>> >>>>>> Might be worth mentioning, I was able to run the latest nVidia >>>>>> driver installation without errors, but after rebooting there was >>>>>> no change, same error code, still no video. >>>>> >>>>> Same situation here with the latest NVIDIA drivers. But I only >>>>> have 2D video working. I can't get 3D video to work. >>>>> >>>>>> To me this would be evidence that driver version isn't a >>>>>> problem, but then again I didn't have anything actually working. >>>>> >>>>> I agree that driver version isn't a problem. Something is wrong >>>>> somewhere. >>>>> >>>>>> >>>>>> >>>>>> I am an IT student in college, so my experience is limited to >>>>>> mostly programming with very little knowledge of the >>>>>> inner-workings of hardware. So, forgive me for being unable to >>>>>> help with regards to memory addresses on the cards. >>>>> >>>>> I am hoping that Intel engineers and Xen developers would be able >>>>> to help. >>>>> >>>>>> >>>>>> I've been using *nix for about 4 years, and Windows since I my >>>>>> age was a single digit. I have had experience setting up server >>>>>> features such as web, database, and application servers but I am >>>>>> still green when it comes to kernel or hardware configuration. >>>>> >>>>> I started learning Linux/UNIX since the year 2005, that is about 7 >>>>> years ago. I started using Windows when it was version 3.1. I love >>>>> compiling the latest Linux kernel and assembling my own computer >>>>> hardware. >>>>> >>>>>> >>>>>> My Xen adventure began 35 days ago, and it is no exaggeration to >>>>>> say that in those 35 days I have learned more about linux than I >>>>>> had in the past two years. I like challenges as much as the next >>>>>> IT person, but I ran out of time and ideas for debugging my >>>>>> nVidia problems. The nVidia stretch of my adventure lasted for >>>>>> 24 days through 54 fresh linux installations accompanied by over >>>>>> 200~ pages worth of documented failures and not a single pixel >>>>>> sighted. >>>>> >>>>> Why not make your documentation into PDF? It is a very popular >>>>> document format. >>>>> >>>>>> >>>>>> The ATI card took me a day, less than 12 hours of relatively easy >>>>>> debugging by comparison to the aforementioned testing. I do >>>>>> fully understanding financial constraints, but it is a working >>>>>> solution and worth mentioning. I do not know what the prices are >>>>>> like in Singapore, but in the states I was able to buy an ATI >>>>>> Radeon HD 6870 for $160. For me it came down to weighing my >>>>>> objectives against my curiosity. >>>>> >>>>> That ATI Radeon HD 6870 would cost me $279, I think. >>>>> >>>>>> >>>>>> If you do continue your nVidia endeavors I wish you success, but >>>>>> as in my former email VGA passthrough is a new frontier, not even >>>>>> Guru's like David may not be able to help beyond their own >>>>>> hardware experiences. >>>>> >>>>> I don't think VGA passthrough is a new frontier. Oracle VirtualBox >>>>> and Linux KVM supports VGA passthrough as well. Xen ATI VGA >>>>> Passthrough works out of the box, as Tobias Geiger suggested, but >>>>> NVIDIA requires patches. >>>>> >>>>>> >>>>>> >>>>>> Documentation is one problem I agree with you on 100%. I came >>>>>> into this knowing relatively little about Linux & hardware, and >>>>>> nothing about Xen, and most every guide I found assumed I had >>>>>> been in a deep relationship with Linux for many years and had a >>>>>> basic understanding of Xen commands. >>>>> >>>>> I started learning Xen since the year 2007, which is about 5 years >>>>> ago. >>>>> >>>>>> >>>>>> Like you, I intend to use those documented failures as well as my >>>>>> recent success to create a comprehensive guide with photographs, >>>>>> screen captures, and perhaps even videos going from "assembled >>>>>> computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough". >>>>>> Provided the wiki will allow me to upload the screenshots, I'll >>>>>> be certain to post it there. >>>>> >>>>> I will be looking forward to your documentation and videos. Right >>>>> now Xen wiki allows uploading image files and PDF files. Why not >>>>> create a PDF document and share it with all of us? It is known as >>>>> portable document format and is very popular, but it appears that >>>>> xen mailing lists don't like PDF format. >>>>> >>>>> _*I don't like wiki pages because anybody can edit and >>>>> fundamentally mess up the wiki pages, even providing bogus and >>>>> erroneous information. That's why I don't like creating wiki >>>>> pages. Anybody can edit and mess up the information you have >>>>> painstakingly created on the wiki pages. So please take note.*_ >>>>> >>>>> -- >>>>> Yours sincerely, >>>>> >>>>> Mr. Teo En Ming (Zhang Enming) >>>>> Singapore >>>>> >>>>> >>>>>> >>>>>> ~Casey >>>>>> >>>>>> On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) >>>>>> >>>>> > wrote: >>>>>> >>>>>> Dearest Casey DeLorme, >>>>>> >>>>>> Thank you very very much for your kind feedback and input. I >>>>>> would also like to thank Mr. Tobias Geiger, again, for >>>>>> providing his suggestion on exposing the fourth memory region >>>>>> in tools/firmware/hvmloader/acpi/dsdt.asl. _In any case, >>>>>> either exposing the first 3 memory regions only or exposing >>>>>> all the 4 memory regions does not work._ Sadly, Tobias Geiger >>>>>> is unable to help me further. >>>>>> >>>>>> I have asked Jean David Techer, what about the 4th PCI memory >>>>>> region? Why only expose the first 3 PCI memory regions? I >>>>>> don't understand, of course. Jean David Techer did not reply >>>>>> to my question. >>>>>> >>>>>> I have decided to post your prompt reply to the xen-users and >>>>>> xen-devel mailing lists, in case people think that I am >>>>>> finding fault with Jean David Techer, or trying to irritate >>>>>> him, or trying to make him angry, or trying to aggravate him. >>>>>> Jean David Techer replied me with an email saying that I >>>>>> _spent too much time_ and _too bent_ on solving the yellow >>>>>> exclamation mark glitch for my NVIDIA Geforce 8400GS in >>>>>> Device Manager in Windows 8 Consumer Preview and Windows XP >>>>>> Home Edition, and that I sent *_stupid_* requests. Stupid >>>>>> requests? Did he read my emails carefully, word by word? >>>>>> >>>>>> Casey DeLorme, please, can I confirm with you again that you >>>>>> are getting the following errors after applying Jean David >>>>>> Techer's Xen 4.2-unstable VGA Passthrough patches: >>>>>> >>>>>> *_(1) Yellow exclamation mark besides your NVIDIA GTX 460 in >>>>>> Device Manager >>>>>> (2) Windows has stopped this device because it has reported >>>>>> problems. (Code 43) >>>>>> (3) This device isn't using any resources because it has a >>>>>> problem._* >>>>>> >>>>>> Jean David Techer insists that our technical issues are due >>>>>> to a NVIDIA driver problem. He insists that you have to >>>>>> install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. >>>>>> Any other NVIDIA driver versions (above 280.XX) will not >>>>>> work, according to Jean David Techer. *_However, I have tried >>>>>> installing NVIDIA driver versions 275.33 and 275.50 from >>>>>> www.softpedia.com , as he >>>>>> suggested, but it caused my Windows XP Home Edition HVM >>>>>> virtual machine to be destroyed/terminated/crash after a few >>>>>> minutes and my dom0 to crash as well._* NVIDIA driver >>>>>> versions 275.33 and 275.50 for Windows XP 32-bit is not >>>>>> available from the official NVIDIA website. >>>>>> >>>>>> So it is definitely not a NVIDIA driver problem. I suspect >>>>>> that the technical issue has to do with *_MMIO BARs pBAR:vBAR >>>>>> 1:1 matching_*. I don't think there is any problem with >>>>>> vgabios-pt.bin extracted out from our NVIDIA VGA cards, >>>>>> because I have performed a "hexdump -C" on my extracted VGA >>>>>> BIOS EEPROM, or Electrically Erasable Programmable Read Only >>>>>> Memory. >>>>>> >>>>>> Secondly, it does seem strange that Jean David Techer was >>>>>> able to attain *_100%_*, ie. *_perfect success_* with Xen >>>>>> 4.2-unstable VGA Passthrough to his Windows XP 32-bit and >>>>>> 64-bit HVM domU. Have you watched his Youtube video? It is >>>>>> only 4 minutes. Please do watch Jean David Techer's Youtube >>>>>> video at the following URL: >>>>>> >>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough to >>>>>> Windows XP x64 HVM domU Youtube video link: >>>>>> *_http://www.youtube.com/watch?v=3SaYO0ERW44_* >>>>>> >>>>>> I am *_appalled_* and *_baffle__d_* that he has attained >>>>>> *_100% success_* while both of us have only attained >>>>>> *_partial succes__s_* (*_i.e. less than 100%_*) on Xen >>>>>> 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview >>>>>> and Windows XP. >>>>>> >>>>>> *_Solving the yellow exclamation mark issue is important >>>>>> because we would not be able to run 3D graphics benchmarks >>>>>> and play 3D games without solving it. I am not sending silly >>>>>> emails about some yellow marks, as Jean David Techer >>>>>> suggested. I can't even run Unigine Heaven DX11, and 3dmark11 >>>>>> 3D display benchmarks, because of the yellow exclamation mark >>>>>> for NVIDIA Geforce 8400 GS in Device Manager._* >>>>>> >>>>>> Casey DeLorme, with your report on relatively easy success >>>>>> with ATI VGA cards, I think I would go the ATI way, but I >>>>>> would have to spend a few hundred dollars compared to my >>>>>> cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding >>>>>> to go the ATI way, I would also like to continue >>>>>> troubleshooting with the NVIDIA problem, because I consider >>>>>> it to be a technical challenge. >>>>>> >>>>>> In essence, Jean David Techner is considered to be a "boss", >>>>>> or business owner, or proprietor, or technopreneur, or >>>>>> entrepreneur, or technical support officer, or customer >>>>>> support officer, or IT helpdesk engineer, providing services >>>>>> like his forward-ported Xen 4.2-unstable VGA Passthrough >>>>>> patches and the documentation on his blog. I repost Jean >>>>>> David Techer's official website here: >>>>>> >>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: >>>>>> *_http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through_* >>>>>> >>>>>> Jean David Techer's official website is his business venture. >>>>>> >>>>>> Basically, I am Jean David Techer's *_"customer"_*, trying to >>>>>> obtain technical support from him. Of course, he is *_not >>>>>> obliged_* to provide technical support to me since he is >>>>>> providing *_free_* services. It is, after all, an open source >>>>>> software project. Nobody is obliged to provide anybody with >>>>>> technical support. *_To do Jean David Techer justice, he >>>>>> replied most of my questions while avoiding some of my >>>>>> questions._* >>>>>> >>>>>> Finally, I have also failed to obtain technical support from >>>>>> Xen developers like Ian Campbell from *_Citrix Corporation_* >>>>>> and Konrad Wilk from *_Oracle Corporation_*. _*I have always >>>>>> provided all the steps which I have taken, the configuration >>>>>> files and necessary documentation, and kernel messages and >>>>>> error logs*_ to xen-users and xen-devel mailing lists, but >>>>>> they keep insisting I did not provide the information they >>>>>> required. I wondered why. I think they did not read my emails >>>>>> carefully. They told me they would not reply to me any more >>>>>> if I do not provide the information they requested. _*But the >>>>>> problem is that I have always provided information they >>>>>> requested!*_ I think they missed some of my emails, or did >>>>>> not read my emails carefully enough. I am an *_ardent >>>>>> supporter_* and *_SERIOUS software tester_* for open source >>>>>> Xen virtualization/hypervisor but they treated me lightly. >>>>>> _*I always read my emails WORD BY WORD.*_ I have even went to >>>>>> the point of making a video on the *_BUG_* and uploading my >>>>>> video to Youtube. The video is only THREE minutes. >>>>>> >>>>>> _*As everybody says, a picture is worth a thousand words. A >>>>>> video is worth a BILLION words!*_ >>>>>> >>>>>> I have also failed to obtain technical support from Xen >>>>>> developers regarding Xen 4.2-unstable VGA Passthrough. >>>>>> >>>>>> I am hoping Xen 4.2 would have official support for Xen VGA >>>>>> Passthrough for both NVIDIA and ATI cards. >>>>>> >>>>>> Casey DeLorme, thank you very much once again. I will be >>>>>> making changes to my Xen, Linux Kernel and Xen VGA >>>>>> Passthrough Documentation and will be releasing Version 1.7 >>>>>> shortly. Jean David Techer's documentation assumes some level >>>>>> of advanced Linux technical knowledge, so I am writing >>>>>> documentation on my own so that everybody, not just advanced >>>>>> Linux and Xen users, can follow. I have made references to >>>>>> Jean David Techer's documentation in my own documentation. >>>>>> >>>>>> I would be very happy if people would use my documentation. >>>>>> Of course, it satisfies my ego and my vanity. Haha. >>>>>> >>>>>> I have been un-employed for nearly three years now, and I >>>>>> would hesitate to spend a few hundred dollars on an ATI VGA >>>>>> card. I quit my job as an IT engineer 3 years ago because my >>>>>> father suffered from lacunar infarct, or more commonly known >>>>>> as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please >>>>>> understand why I hesitate to buy an ATI VGA card. The >>>>>> cheapest one costs SGD$279. >>>>>> >>>>>> I have a diploma in Mechanical+Electronics engineering from >>>>>> Singapore Polytechnic and a Bachelor's degree in Mechanical >>>>>> Engineering from the National University of Singapore. But I >>>>>> do not have qualifications in Computer Science or Information >>>>>> Technology. I have worked as an Information Technology >>>>>> engineer in Defense Science and Technology Agency, Ministry >>>>>> of Defense, Singapore, National Computer Systems Pte Ltd, >>>>>> Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd. >>>>>> >>>>>> Google search terms: Frenchman Jean David Techer, Singaporean >>>>>> Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough >>>>>> Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 >>>>>> Consumer Preview and Windows XP HVM Virtual Machines >>>>>> >>>>>> Thank you very much for reading my lengthy email. I am always >>>>>> courteous, saying "Please help me. Please. Please. Please." >>>>>> and "Thank you very much for your kind assistance" in my emails. >>>>>> >>>>>> Thank you very much. >>>>>> >>>>>> -- >>>>>> Yours sincerely, >>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>> Singapore Citizen >>>>>> >>>>>> cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, >>>>>> Prime Minister's Office, Republic of Singapore >>>>>> >>>>>> On 29/03/2012 03:53, Casey DeLorme wrote: >>>>>>> Hi Teo, >>>>>>> >>>>>>> I tried David's patch files a while ago *_without success_*. >>>>>>> I had Xen compiled with the patch files and my GTX 460 VGA >>>>>>> BIOS rom, _*but I got the same as you, either a BSOD or Code >>>>>>> 43 in Device Manager.*_ >>>>>>> >>>>>>> You sound plenty competent, but it's important to remember >>>>>>> that you are pioneering a technology that for consumers is >>>>>>> still in its infancy. Very few people are testing this with >>>>>>> consumer equipment, so finding results seems to be a rarity. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-users mailing list >>>>>> Xen-users@lists.xen.org >>>>>> http://lists.xen.org/xen-users >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------090102090706070302030002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 30/03/2012 22:38, Wei Huang wrote:
On 03/29/2012 11:36 PM, Teo En Ming (Zhang Enming) wrote:
On 30/03/2012 04:11, Wei Huang wrote:
On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote:
Dear Casey DeLorme,

This guy, Sebastien Gauthier, also has the same problems as us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS, like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen VGA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst drivers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA card.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU generation. From this perspective, my patch isn't universal. Also there are many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you mentioned. I am not in a position to debug it for everyone's card (as I don't have all cards).

Thanks,
-Wei

Dear Mr. Wei Huang at AMD Corporation,

Thank you very much for your kind reply.

I want to buy the following ATI Radeon VGA card. Do you think it would work with your Xen VGA Passthrough patch to Xen 4.2-unstable???

Sapphire HD5450 512MB             Singapore Dollars $55

I am a cheapskate when it comes to spending money.

I don't have HD5450 card. So I can't test it and can't answer your question directly. If I have some time later, I will test other HD5xxx cards and test you the result. Normally GPUs of same family behave similarly.
If your Xen VGA Passthrough patch to Xen 4.2-unstable works with the above ATI VGA card, I will go ahead and buy it. Do I have to manually patch Xen 4.2-unstable or is your patch already included in Xen 4.2-unstable source tree?
My patch was against QEMU. It is not included in the tree.


Dear Wei Huang,

How do I use your VGA Passthrough patch with Xen 4.2-unstable?

Thank you.



Secondly, I have a request/favor to ask of you. Do you think it is possible for you to examine the Xen 4.2-unstable VGA Passthrough patches hosted at Jean David Techer's website and check if it is compatible with Xen 4.2-unstable code?

Thirdly and finally, could you read through my Xen VGA Passthrough Version 1.7 documentation to see if there are ANY MISTAKES with NVIDIA Geforce 8400 GS VGA Passthrough, because I am only getting PARTIAL SUCCESS.

If you could write Xen VGA Passthrough patches, you are an expert software engineer.

Thank you very very very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:
On 29/03/2012 12:29, Casey DeLorme wrote:
My mistake for not hitting "Reply to All", sorry.

No worries Casey.


It might be of some value to mention that my tests were with Windows 7, I have no interest in using XP anymore.  Also, I did all of my testing through remote VNC, not once did I actually get video, even 2D, working. 

I bought 2 copies of Windows XP Home Edition in the past because it is cheap, at S$145. I did not buy Windows 7 because it is expensive. I got video working all right, but only 2D. I cannot get 3D graphics working.

However, my errors are exactly as you described:

1.  Windows recognizes the model (GTX 460), not "unknown PCI device".
2.  Device code 43.
3.  No resources assigned to the device.

We have the same set of errors.


Might be worth mentioning, I was able to run the latest nVidia driver installation without errors, but after rebooting there was no change, same error code, still no video.

Same situation here with the latest NVIDIA drivers. But I only have 2D video working. I can't get 3D video to work.

 To me this would be evidence that driver version isn't a problem, but then again I didn't have anything actually working.

I agree that driver version isn't a problem. Something is wrong somewhere.



I am an IT student in college, so my experience is limited to mostly programming with very little knowledge of the inner-workings of hardware.  So, forgive me for being unable to help with regards to memory addresses on the cards.

I am hoping that Intel engineers and Xen developers would be able to help.


I've been using *nix for about 4 years, and Windows since I my age was a single digit.  I have had experience setting up server features such as web, database, and application servers but I am still green when it comes to kernel or hardware configuration.

I started learning Linux/UNIX since the year 2005, that is about 7 years ago. I started using Windows when it was version 3.1. I love compiling the latest Linux kernel and assembling my own computer hardware.


My Xen adventure began 35 days ago, and it is no exaggeration to say that in those 35 days I have learned more about linux than I had in the past two years.  I like challenges as much as the next IT person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure lasted for 24 days through 54 fresh linux installations accompanied by over 200~ pages worth of documented failures and not a single pixel sighted.

Why not make your documentation into PDF? It is a very popular document format.


The ATI card took me a day, less than 12 hours of relatively easy debugging by comparison to the aforementioned testing.  I do fully understanding financial constraints, but it is a working solution and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy an ATI Radeon HD 6870 for $160.  For me it came down to weighing my objectives against my curiosity.

That ATI Radeon HD 6870 would cost me $279, I think.


If you do continue your nVidia endeavors I wish you success, but as in my former email VGA passthrough is a new frontier, not even Guru's like David may not be able to help beyond their own hardware experiences.

I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linux KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out of the box, as Tobias Geiger suggested, but NVIDIA requires patches.



Documentation is one problem I agree with you on 100%.  I came into this knowing relatively little about Linux & hardware, and nothing about Xen, and most every guide I found assumed I had been in a deep relationship with Linux for many years and had a basic understanding of Xen commands.

I started learning Xen since the year 2007, which is about 5 years ago.


Like you, I intend to use those documented failures as well as my recent success to create a comprehensive guide with photographs, screen captures, and perhaps even videos going from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the screenshots, I'll be certain to post it there.

I will be looking forward to your documentation and videos. Right now Xen wiki allows uploading image files and PDF files. Why not create a PDF document and share it with all of us? It is known as portable document format and is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally mess up the wiki pages, even providing bogus and erroneous information. That's why I don't like creating wiki pages. Anybody can edit and mess up the information you have painstakingly created on the wiki pages. So please take note.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



~Casey

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:
Dearest Casey DeLorme,

Thank you very very much for your kind feedback and input. I would also like to thank Mr. Tobias Geiger, again, for providing his suggestion on exposing the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing all the 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why only expose the first 3 PCI memory regions? I don't understand, of course. Jean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mailing lists, in case people think that I am finding fault with Jean David Techer, or trying to irritate him, or trying to make him angry, or trying to aggravate him. Jean David Techer replied me with an email saying that I spent too much time and too bent on solving the yellow exclamation mark glitch for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails carefully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting the following errors after applying Jean David Techer's Xen 4.2-unstable VGA Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager
(2) Windows has stopped this device because it has reported problems. (Code 43)
(3) This device isn't using any resources because it has a problem.

Jean David Techer insists that our technical issues are due to a NVIDIA driver problem. He insists that you have to install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) will not work, according to Jean David Techer. However, I have tried installing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual machine to be destroyed/terminated/crash after a few minutes and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technical issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM, or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is only 4 minutes. Please do watch Jean David Techer's Youtube video at the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM domU Youtube video link: http://www.youtube.com/watch?v=3SaYO0ERW44

I am appalled and baffled that he has attained 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.

Solving the yellow exclamation mark issue is important because we would not be able to run 3D graphics benchmarks and play 3D games without solving it. I am not sending silly emails about some yellow marks, as Jean David Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.

Casey DeLorme, with your report on relatively easy success with ATI VGA cards, I think I would go the ATI way, but I would have to spend a few hundred dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I consider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or business owner, or proprietor, or technopreneur, or entrepreneur, or technical support officer, or customer support officer, or IT helpdesk engineer, providing services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog. I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", trying to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is providing free services. It is, after all, an open source software project. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions while avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corporation. I have always provided all the steps which I have taken, the configuration files and necessary documentation, and kernel messages and error logs to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information they required. I wondered why. I think they did not read my emails carefully. They told me they would not reply to me any more if I do not provide the information they requested. But the problem is that I have always provided information they requested! I think they missed some of my emails, or did not read my emails carefully enough. I am an ardent supporter and SERIOUS software tester for open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the point of making a video on the BUG and uploading my video to Youtube. The video is only THREE minutes.

As everybody says, a picture is worth a thousand words. A video is worth a BILLION words!

I have also failed to obtain technical support from Xen developers regarding Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be releasing Version 1.7 shortly. Jean David Techer's documentation assumes some level of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not just advanced Linux and Xen users, can follow. I have made references to Jean David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it satisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to spend a few hundred dollars on an ATI VGA card. I quit my job as an IT engineer 3 years ago because my father suffered from lacunar infarct, or more commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy an ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore Polytechnic and a Bachelor's degree in Mechanical Engineering from the National University of Singapore. But I do not have qualifications in Computer Science or Information Technology. I have worked as an Information Technology engineer in Defense Science and Technology Agency, Ministry of Defense, Singapore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Machines

Thank you very much for reading my lengthy email. I am always courteous, saying "Please help me. Please. Please. Please." and "Thank you very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:
Hi Teo,

I tried David's patch files a while ago without success.  I had Xen compiled with the patch files and my GTX 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager.

You sound plenty competent, but it's important to remember that you are pioneering a technology that for consumers is still in its infancy.  Very few people are testing this with consumer equipment, so finding results seems to be a rarity.





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











-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------090102090706070302030002-- --===============3747995595132454217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3747995595132454217==-- From xen-devel-bounces@lists.xen.org Mon May 07 05:43:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 05: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 ) id 1SRGiO-0005JM-RZ; Mon, 07 May 2012 05:42:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGiM-0005JD-95 for xen-devel@lists.xen.org; Mon, 07 May 2012 05:42:30 +0000 Received: from [85.158.143.35:31277] by server-3.bemta-4.messagelabs.com id 00/0C-05853-5C067AF4; Mon, 07 May 2012 05:42:29 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336369343!14969577!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_60_70, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9262 invoked from network); 7 May 2012 05:42:25 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 05:42:25 -0000 Received: by pbbro12 with SMTP id ro12so6597241pbb.32 for ; Sun, 06 May 2012 22:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=eV/T06icd0TergATHpN37ixeZxThD3dDW0sIYBsYuBY=; b=asGavIIzdNzcwyKpjP5qiJ2SGwlZIcHiADdh01wPCzOpFiywSoYy+Nw+K7unrRcxkZ uZlVuOd5s+qTYlTKa/EMj+3HfniJWAcmiqFjRPFR45tc9d+1JxQ70+LSCCn86fy5mmWW AcyOFNJqgG4ayPTsEBNd5atGCd4P5XtJrWptV93+1b3kHSxx1EYb1e2wq27Gp5wno5f9 mRGZ8Ugq3eXBmJZpotrGzFHeUwQONs0KTPIxNPyq2Dlwhc/awH3aFXphQ6Sg6nl0MChE 1mD0xU2QH0+y+9wTwSuyQZGge1zxNsHUB/XyCCNkWm4vEFo//86H2qBRgwqnznR6Y2+l iVBA== Received: by 10.68.72.70 with SMTP id b6mr34071227pbv.58.1336369342706; Sun, 06 May 2012 22:42:22 -0700 (PDT) Received: from [192.168.1.2] (cm11.gamma206.maxonline.com.sg. [202.156.206.11]) by mx.google.com with ESMTPS id py6sm17069592pbc.13.2012.05.06.22.42.18 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 22:42:21 -0700 (PDT) Message-ID: <4FA760B9.4060501@gmail.com> Date: Mon, 07 May 2012 13:42:17 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: wei.huang2@amd.com References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F74EA35.4030305@amd.com> <4F753CD8.4050300@gmail.com> <4F75C59F.8030407@amd.com> In-Reply-To: <4F75C59F.8030407@amd.com> Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , 'Teo En Ming' , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5838769769867168659==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5838769769867168659== Content-Type: multipart/alternative; boundary="------------070309050200070401020705" This is a multi-part message in MIME format. --------------070309050200070401020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/03/2012 22:39, Wei Huang wrote: > On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote: >> On 30/03/2012 07:03, Wei Huang wrote: >>> On 03/29/2012 04:29 PM, Casey DeLorme wrote: >>>> David, >>>> >>>> XenServer VGA Passthrough requires a paid/licensed copy, which >>>> costs $2500, a bit out of my price range for experimentation. >>>> Important to note that the feature is not a part of the 30-day >>>> trial license. >>>> >>>> However, Citrix recently visited my college and I was able to >>>> preview hardware access on a laptop one of the employees had, where >>>> they swapped between Ubuntu and Windows with a hotkey, and various >>>> hardware components including onboard GPU and the WebCam were >>>> accessible. >>>> >>>> In testing XenServer, I can say that if I had a business, that's >>>> the product I would use. In the past month having tried Xen and >>>> ESXi, I was astonished with the ease of use for XenServer. >>>> >>>> As for Catalyst, version 12.2 (the latest currently) worked for me. >>>> >>>> Important to note that until I followed Andrews advice to omit the >>>> Catalyst Control Center, the installation resulted in a BSOD. >>> I saw similar issue whiling playing with XenClient. After discussing >>> with AMD GPU driver team, the conclusion was that the installer has >>> a bug. But I have not received any further update from them. Also >>> manual driver installation (after many tries) did fix problem for me. >>>> >>>> The solution, select "Custom" installation and uncheck the CCC. >>>> After the installation your first reboot should run some follow-up >>>> updates via cmd, you need to reboot a second time for fully >>>> functional drivers. >>>> >>>> Also, I had underscan on my monitor so I went out on a limb and >>>> re-ran the setup for Catalyst, and was able to get CCC installed >>>> with a second run through, which allowed me to fix my underscan issue. >>>> >>>> My conclusion is that the CCC requires some driver functionality >>>> that isn't available until after you install the drivers, this >>>> could be on all systems or it might be related to how HVM's handle >>>> the PCI devices, that much I can't say. >>>> >>>> >>>> >>>> Teo, >>>> >>>> I could be spouting nonsense, and if so I'm sure Wei can correct >>>> me, but I am pretty sure AMD engineers have been contributing to >>>> Xen for a while, and some patches have already been applied. >>>> Obviously it isn't flawless, I myself haven't gotten video at boot >>>> time, only at the login screen. >>>> >>> This is because VBIOS patch wasn't applied. But as I said before, my >>> VBIOS wasn't universal enough to put it as a production patch. So I >>> am hesitant to put it out. >> >> Dear Wei Huang at AMD Corporation, >> >> Please put your Xen VGA Passthrough patch out so that all of us can >> have a try. >> >> Thank you very much. >> > http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html Dear Wei Huang, Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tree? Thank you. >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >>>> Mine works on 4.1.2, but it is possible that 4.1.0 had less of >>>> these "patches" hence Sebastien's post. >>>> >>>> Also, I apologize as I did not properly word my opinion before. >>>> VGA Passthrough is new "for consumer components". In 2010 the >>>> number of desktop (not server) boards boasting VT-d functionality >>>> could probably be counted on one hand. To my understanding that >>>> means the technology is at most 3 years old, still a baby in my >>>> opinion. >>>> >>>> I didn't mean that the technology hadn't been implemented into >>>> various Hypervisors, just that it is clearly not a perfected >>>> feature. If you consider 3 years of consumer availability, dates >>>> become important when researching. Sebastien's post was May 2011, >>>> just shy of one year ago, and Thomas's was in 2010. >>>> >>>> There are newer patches still for ATI in Xen 4.2, which I intend to >>>> test over the next week. I have NOT gotten ATI to work at boot >>>> time, video starts at the login screen. >>>> >>>> I agree with Wei that drivers can contribute to BSOD's and errors, >>>> but when an install doesn't fail but the hardware reacts the same >>>> as before, I would like to assume the driver is irrelative. >>>> >>> Have you looked at XenClient project? It has a customized ATI >>> component which allows you to switch between VMs flawlessly. I think >>> it is the most mature Xen solution for GPU passthru in client area. >> >> Dear Wei Huang at AMD Corporation, >> >> May I know what is the XenClient project? >> >> >>>> >>>> ~Casey >>>> >>>> On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang >>> > wrote: >>>> >>>> On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: >>>>> Dear Casey DeLorme, >>>>> >>>>> This guy, Sebastien Gauthier, also has the same problems as >>>>> us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied >>>>> Mr. Wei Huang's patch. After installing the latest ATI/AMD >>>>> Catalyst drivers, he got a BSOD with Xen VGA Passthrough to >>>>> Windows 7. >>>>> >>>>> Please read Sebastien Gauthier's case here: >>>>> >>>>> http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html >>>>> >>>>> Hence Sebastien Gauthier reported Xen VGA Passthrough with >>>>> PARTIAL SUCCESS, like us. >>>>> >>>>> Dear Tobias Geiger, >>>>> >>>>> You were saying that with ATI VGA cards, you do not need to >>>>> apply any Xen VGA Passthrough patches. But this guy Sebastien >>>>> Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got >>>>> a BSOD after installing ATI Catalyst drivers. Sebastien >>>>> Gauthier did not get 100% success with Xen VGA Passthrough to >>>>> Windows 7 using an ATI VGA card. >>>>> >>>> Hi Teo, >>>> >>>> The VBIOS patch I sent out did not work for all ATI cards. The >>>> patch itself assumed certain behavior of GPU VBIOS. But this >>>> doesn't apply to every GPU generation. From this perspective, >>>> my patch isn't universal. Also there are many factors, some of >>>> which are not in control by us (like graphics driver), can >>>> contribute to BSOD you mentioned. I am not in a position to >>>> debug it for everyone's card (as I don't have all cards). >>>> >>>> Thanks, >>>> -Wei >>>> >>>>> -- >>>>> Yours sincerely, >>>>> >>>>> Mr. Teo En Ming (Zhang Enming) >>>>> Singapore >>>>> >>>>> >>>>> >>>>> >>>>> On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: >>>>>> On 29/03/2012 12:29, Casey DeLorme wrote: >>>>>>> My mistake for not hitting "Reply to All", sorry. >>>>>> >>>>>> No worries Casey. >>>>>> >>>>>>> >>>>>>> It might be of some value to mention that my tests were with >>>>>>> Windows 7, I have no interest in using XP anymore. Also, I >>>>>>> did all of my testing through remote VNC, not once did I >>>>>>> actually get video, even 2D, working. >>>>>> >>>>>> I bought 2 copies of Windows XP Home Edition in the past >>>>>> because it is cheap, at S$145. I did not buy Windows 7 >>>>>> because it is expensive. I got video working all right, but >>>>>> only 2D. I cannot get 3D graphics working. >>>>>> >>>>>>> However, my errors are exactly as you described: >>>>>>> >>>>>>> 1. Windows recognizes the model (GTX 460), not "unknown PCI >>>>>>> device". >>>>>>> 2. Device code 43. >>>>>>> 3. No resources assigned to the device. >>>>>> >>>>>> We have the same set of errors. >>>>>> >>>>>>> >>>>>>> Might be worth mentioning, I was able to run the latest >>>>>>> nVidia driver installation without errors, but after >>>>>>> rebooting there was no change, same error code, still no video. >>>>>> >>>>>> Same situation here with the latest NVIDIA drivers. But I >>>>>> only have 2D video working. I can't get 3D video to work. >>>>>> >>>>>>> To me this would be evidence that driver version isn't a >>>>>>> problem, but then again I didn't have anything actually working. >>>>>> >>>>>> I agree that driver version isn't a problem. Something is >>>>>> wrong somewhere. >>>>>> >>>>>>> >>>>>>> >>>>>>> I am an IT student in college, so my experience is limited >>>>>>> to mostly programming with very little knowledge of the >>>>>>> inner-workings of hardware. So, forgive me for being unable >>>>>>> to help with regards to memory addresses on the cards. >>>>>> >>>>>> I am hoping that Intel engineers and Xen developers would be >>>>>> able to help. >>>>>> >>>>>>> >>>>>>> I've been using *nix for about 4 years, and Windows since I >>>>>>> my age was a single digit. I have had experience setting up >>>>>>> server features such as web, database, and application >>>>>>> servers but I am still green when it comes to kernel or >>>>>>> hardware configuration. >>>>>> >>>>>> I started learning Linux/UNIX since the year 2005, that is >>>>>> about 7 years ago. I started using Windows when it was >>>>>> version 3.1. I love compiling the latest Linux kernel and >>>>>> assembling my own computer hardware. >>>>>> >>>>>>> >>>>>>> My Xen adventure began 35 days ago, and it is no >>>>>>> exaggeration to say that in those 35 days I have learned >>>>>>> more about linux than I had in the past two years. I like >>>>>>> challenges as much as the next IT person, but I ran out of >>>>>>> time and ideas for debugging my nVidia problems. The nVidia >>>>>>> stretch of my adventure lasted for 24 days through 54 fresh >>>>>>> linux installations accompanied by over 200~ pages worth of >>>>>>> documented failures and not a single pixel sighted. >>>>>> >>>>>> Why not make your documentation into PDF? It is a very >>>>>> popular document format. >>>>>> >>>>>>> >>>>>>> The ATI card took me a day, less than 12 hours of relatively >>>>>>> easy debugging by comparison to the aforementioned testing. >>>>>>> I do fully understanding financial constraints, but it is a >>>>>>> working solution and worth mentioning. I do not know what >>>>>>> the prices are like in Singapore, but in the states I was >>>>>>> able to buy an ATI Radeon HD 6870 for $160. For me it came >>>>>>> down to weighing my objectives against my curiosity. >>>>>> >>>>>> That ATI Radeon HD 6870 would cost me $279, I think. >>>>>> >>>>>>> >>>>>>> If you do continue your nVidia endeavors I wish you success, >>>>>>> but as in my former email VGA passthrough is a new frontier, >>>>>>> not even Guru's like David may not be able to help beyond >>>>>>> their own hardware experiences. >>>>>> >>>>>> I don't think VGA passthrough is a new frontier. Oracle >>>>>> VirtualBox and Linux KVM supports VGA passthrough as well. >>>>>> Xen ATI VGA Passthrough works out of the box, as Tobias >>>>>> Geiger suggested, but NVIDIA requires patches. >>>>>> >>>>>>> >>>>>>> >>>>>>> Documentation is one problem I agree with you on 100%. I >>>>>>> came into this knowing relatively little about Linux & >>>>>>> hardware, and nothing about Xen, and most every guide I >>>>>>> found assumed I had been in a deep relationship with Linux >>>>>>> for many years and had a basic understanding of Xen commands. >>>>>> >>>>>> I started learning Xen since the year 2007, which is about 5 >>>>>> years ago. >>>>>> >>>>>>> >>>>>>> Like you, I intend to use those documented failures as well >>>>>>> as my recent success to create a comprehensive guide with >>>>>>> photographs, screen captures, and perhaps even videos going >>>>>>> from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA >>>>>>> Passthrough". Provided the wiki will allow me to upload the >>>>>>> screenshots, I'll be certain to post it there. >>>>>> >>>>>> I will be looking forward to your documentation and videos. >>>>>> Right now Xen wiki allows uploading image files and PDF >>>>>> files. Why not create a PDF document and share it with all of >>>>>> us? It is known as portable document format and is very >>>>>> popular, but it appears that xen mailing lists don't like PDF >>>>>> format. >>>>>> >>>>>> _*I don't like wiki pages because anybody can edit and >>>>>> fundamentally mess up the wiki pages, even providing bogus >>>>>> and erroneous information. That's why I don't like creating >>>>>> wiki pages. Anybody can edit and mess up the information you >>>>>> have painstakingly created on the wiki pages. So please take >>>>>> note.*_ >>>>>> >>>>>> -- >>>>>> Yours sincerely, >>>>>> >>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>> Singapore >>>>>> >>>>>> >>>>>>> >>>>>>> ~Casey >>>>>>> >>>>>>> On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Dearest Casey DeLorme, >>>>>>> >>>>>>> Thank you very very much for your kind feedback and >>>>>>> input. I would also like to thank Mr. Tobias Geiger, >>>>>>> again, for providing his suggestion on exposing the >>>>>>> fourth memory region in >>>>>>> tools/firmware/hvmloader/acpi/dsdt.asl. _In any case, >>>>>>> either exposing the first 3 memory regions only or >>>>>>> exposing all the 4 memory regions does not work._ Sadly, >>>>>>> Tobias Geiger is unable to help me further. >>>>>>> >>>>>>> I have asked Jean David Techer, what about the 4th PCI >>>>>>> memory region? Why only expose the first 3 PCI memory >>>>>>> regions? I don't understand, of course. Jean David >>>>>>> Techer did not reply to my question. >>>>>>> >>>>>>> I have decided to post your prompt reply to the >>>>>>> xen-users and xen-devel mailing lists, in case people >>>>>>> think that I am finding fault with Jean David Techer, or >>>>>>> trying to irritate him, or trying to make him angry, or >>>>>>> trying to aggravate him. Jean David Techer replied me >>>>>>> with an email saying that I _spent too much time_ and >>>>>>> _too bent_ on solving the yellow exclamation mark glitch >>>>>>> for my NVIDIA Geforce 8400GS in Device Manager in >>>>>>> Windows 8 Consumer Preview and Windows XP Home Edition, >>>>>>> and that I sent *_stupid_* requests. Stupid requests? >>>>>>> Did he read my emails carefully, word by word? >>>>>>> >>>>>>> Casey DeLorme, please, can I confirm with you again that >>>>>>> you are getting the following errors after applying Jean >>>>>>> David Techer's Xen 4.2-unstable VGA Passthrough patches: >>>>>>> >>>>>>> *_(1) Yellow exclamation mark besides your NVIDIA GTX >>>>>>> 460 in Device Manager >>>>>>> (2) Windows has stopped this device because it has >>>>>>> reported problems. (Code 43) >>>>>>> (3) This device isn't using any resources because it has >>>>>>> a problem._* >>>>>>> >>>>>>> Jean David Techer insists that our technical issues are >>>>>>> due to a NVIDIA driver problem. He insists that you have >>>>>>> to install NVIDIA driver versions 275.33 WHQL and 275.50 >>>>>>> BETA. Any other NVIDIA driver versions (above 280.XX) >>>>>>> will not work, according to Jean David Techer. >>>>>>> *_However, I have tried installing NVIDIA driver >>>>>>> versions 275.33 and 275.50 from www.softpedia.com >>>>>>> , as he suggested, but it >>>>>>> caused my Windows XP Home Edition HVM virtual machine to >>>>>>> be destroyed/terminated/crash after a few minutes and my >>>>>>> dom0 to crash as well._* NVIDIA driver versions 275.33 >>>>>>> and 275.50 for Windows XP 32-bit is not available from >>>>>>> the official NVIDIA website. >>>>>>> >>>>>>> So it is definitely not a NVIDIA driver problem. I >>>>>>> suspect that the technical issue has to do with *_MMIO >>>>>>> BARs pBAR:vBAR 1:1 matching_*. I don't think there is >>>>>>> any problem with vgabios-pt.bin extracted out from our >>>>>>> NVIDIA VGA cards, because I have performed a "hexdump >>>>>>> -C" on my extracted VGA BIOS EEPROM, or Electrically >>>>>>> Erasable Programmable Read Only Memory. >>>>>>> >>>>>>> Secondly, it does seem strange that Jean David Techer >>>>>>> was able to attain *_100%_*, ie. *_perfect success_* >>>>>>> with Xen 4.2-unstable VGA Passthrough to his Windows XP >>>>>>> 32-bit and 64-bit HVM domU. Have you watched his Youtube >>>>>>> video? It is only 4 minutes. Please do watch Jean David >>>>>>> Techer's Youtube video at the following URL: >>>>>>> >>>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough to >>>>>>> Windows XP x64 HVM domU Youtube video link: >>>>>>> *_http://www.youtube.com/watch?v=3SaYO0ERW44_* >>>>>>> >>>>>>> I am *_appalled_* and *_baffle__d_* that he has attained >>>>>>> *_100% success_* while both of us have only attained >>>>>>> *_partial succes__s_* (*_i.e. less than 100%_*) on Xen >>>>>>> 4.2-unstable VGA Passthrough to Windows 8 Consumer >>>>>>> Preview and Windows XP. >>>>>>> >>>>>>> *_Solving the yellow exclamation mark issue is important >>>>>>> because we would not be able to run 3D graphics >>>>>>> benchmarks and play 3D games without solving it. I am >>>>>>> not sending silly emails about some yellow marks, as >>>>>>> Jean David Techer suggested. I can't even run Unigine >>>>>>> Heaven DX11, and 3dmark11 3D display benchmarks, because >>>>>>> of the yellow exclamation mark for NVIDIA Geforce 8400 >>>>>>> GS in Device Manager._* >>>>>>> >>>>>>> Casey DeLorme, with your report on relatively easy >>>>>>> success with ATI VGA cards, I think I would go the ATI >>>>>>> way, but I would have to spend a few hundred dollars >>>>>>> compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. >>>>>>> And while deciding to go the ATI way, I would also like >>>>>>> to continue troubleshooting with the NVIDIA problem, >>>>>>> because I consider it to be a technical challenge. >>>>>>> >>>>>>> In essence, Jean David Techner is considered to be a >>>>>>> "boss", or business owner, or proprietor, or >>>>>>> technopreneur, or entrepreneur, or technical support >>>>>>> officer, or customer support officer, or IT helpdesk >>>>>>> engineer, providing services like his forward-ported Xen >>>>>>> 4.2-unstable VGA Passthrough patches and the >>>>>>> documentation on his blog. I repost Jean David Techer's >>>>>>> official website here: >>>>>>> >>>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough >>>>>>> blog: >>>>>>> *_http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through_* >>>>>>> >>>>>>> Jean David Techer's official website is his business >>>>>>> venture. >>>>>>> >>>>>>> Basically, I am Jean David Techer's *_"customer"_*, >>>>>>> trying to obtain technical support from him. Of course, >>>>>>> he is *_not obliged_* to provide technical support to me >>>>>>> since he is providing *_free_* services. It is, after >>>>>>> all, an open source software project. Nobody is obliged >>>>>>> to provide anybody with technical support. *_To do Jean >>>>>>> David Techer justice, he replied most of my questions >>>>>>> while avoiding some of my questions._* >>>>>>> >>>>>>> Finally, I have also failed to obtain technical support >>>>>>> from Xen developers like Ian Campbell from *_Citrix >>>>>>> Corporation_* and Konrad Wilk from *_Oracle >>>>>>> Corporation_*. _*I have always provided all the steps >>>>>>> which I have taken, the configuration files and >>>>>>> necessary documentation, and kernel messages and error >>>>>>> logs*_ to xen-users and xen-devel mailing lists, but >>>>>>> they keep insisting I did not provide the information >>>>>>> they required. I wondered why. I think they did not read >>>>>>> my emails carefully. They told me they would not reply >>>>>>> to me any more if I do not provide the information they >>>>>>> requested. _*But the problem is that I have always >>>>>>> provided information they requested!*_ I think they >>>>>>> missed some of my emails, or did not read my emails >>>>>>> carefully enough. I am an *_ardent supporter_* and >>>>>>> *_SERIOUS software tester_* for open source Xen >>>>>>> virtualization/hypervisor but they treated me lightly. >>>>>>> _*I always read my emails WORD BY WORD.*_ I have even >>>>>>> went to the point of making a video on the *_BUG_* and >>>>>>> uploading my video to Youtube. The video is only THREE >>>>>>> minutes. >>>>>>> >>>>>>> _*As everybody says, a picture is worth a thousand >>>>>>> words. A video is worth a BILLION words!*_ >>>>>>> >>>>>>> I have also failed to obtain technical support from Xen >>>>>>> developers regarding Xen 4.2-unstable VGA Passthrough. >>>>>>> >>>>>>> I am hoping Xen 4.2 would have official support for Xen >>>>>>> VGA Passthrough for both NVIDIA and ATI cards. >>>>>>> >>>>>>> Casey DeLorme, thank you very much once again. I will be >>>>>>> making changes to my Xen, Linux Kernel and Xen VGA >>>>>>> Passthrough Documentation and will be releasing Version >>>>>>> 1.7 shortly. Jean David Techer's documentation assumes >>>>>>> some level of advanced Linux technical knowledge, so I >>>>>>> am writing documentation on my own so that everybody, >>>>>>> not just advanced Linux and Xen users, can follow. I >>>>>>> have made references to Jean David Techer's >>>>>>> documentation in my own documentation. >>>>>>> >>>>>>> I would be very happy if people would use my >>>>>>> documentation. Of course, it satisfies my ego and my >>>>>>> vanity. Haha. >>>>>>> >>>>>>> I have been un-employed for nearly three years now, and >>>>>>> I would hesitate to spend a few hundred dollars on an >>>>>>> ATI VGA card. I quit my job as an IT engineer 3 years >>>>>>> ago because my father suffered from lacunar infarct, or >>>>>>> more commonly known as stroke. My NVIDIA Geforce 8400 GS >>>>>>> costs only S$44. Please understand why I hesitate to buy >>>>>>> an ATI VGA card. The cheapest one costs SGD$279. >>>>>>> >>>>>>> I have a diploma in Mechanical+Electronics engineering >>>>>>> from Singapore Polytechnic and a Bachelor's degree in >>>>>>> Mechanical Engineering from the National University of >>>>>>> Singapore. But I do not have qualifications in Computer >>>>>>> Science or Information Technology. I have worked as an >>>>>>> Information Technology engineer in Defense Science and >>>>>>> Technology Agency, Ministry of Defense, Singapore, >>>>>>> National Computer Systems Pte Ltd, Asiasoft Online Pte >>>>>>> Ltd, and Ishinemax Singapore Pte Ltd. >>>>>>> >>>>>>> Google search terms: Frenchman Jean David Techer, >>>>>>> Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA >>>>>>> Passthrough Documentation, Xen 4.2-unstable VGA >>>>>>> Passthrough to Windows 8 Consumer Preview and Windows XP >>>>>>> HVM Virtual Machines >>>>>>> >>>>>>> Thank you very much for reading my lengthy email. I am >>>>>>> always courteous, saying "Please help me. Please. >>>>>>> Please. Please." and "Thank you very much for your kind >>>>>>> assistance" in my emails. >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>>> -- >>>>>>> Yours sincerely, >>>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>>> Singapore Citizen >>>>>>> >>>>>>> cc: His Excellency The Prime Minister Mr. Lee Hsien >>>>>>> Loong, Prime Minister's Office, Republic of Singapore >>>>>>> >>>>>>> On 29/03/2012 03:53, Casey DeLorme wrote: >>>>>>>> Hi Teo, >>>>>>>> >>>>>>>> I tried David's patch files a while ago *_without >>>>>>>> success_*. I had Xen compiled with the patch files and >>>>>>>> my GTX 460 VGA BIOS rom, _*but I got the same as you, >>>>>>>> either a BSOD or Code 43 in Device Manager.*_ >>>>>>>> >>>>>>>> You sound plenty competent, but it's important to >>>>>>>> remember that you are pioneering a technology that for >>>>>>>> consumers is still in its infancy. Very few people are >>>>>>>> testing this with consumer equipment, so finding >>>>>>>> results seems to be a rarity. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-users mailing list >>>>>>> Xen-users@lists.xen.org >>>>>>> http://lists.xen.org/xen-users >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------070309050200070401020705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 30/03/2012 22:39, Wei Huang wrote:
On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote:
On 30/03/2012 07:03, Wei Huang wrote:
On 03/29/2012 04:29 PM, Casey DeLorme wrote:
David,

XenServer VGA Passthrough requires a paid/licensed copy, which costs $2500, a bit out of my price range for experimentation.  Important to note that the feature is not a part of the 30-day trial license.

However, Citrix recently visited my college and I was able to preview hardware access on a laptop one of the employees had, where they swapped between Ubuntu and Windows with a hotkey, and various hardware components including onboard GPU and the WebCam were accessible.

In testing XenServer, I can say that if I had a business, that's the product I would use.  In the past month having tried Xen and ESXi, I was astonished with the ease of use for XenServer.

As for Catalyst, version 12.2 (the latest currently) worked for me.

Important to note that until I followed Andrews advice to omit the Catalyst Control Center, the installation resulted in a BSOD.
I saw similar issue whiling playing with XenClient. After discussing with AMD GPU driver team, the conclusion was that the installer has a bug. But I have not received any further update from them. Also manual driver installation (after many tries) did fix problem for me.

The solution, select "Custom" installation and uncheck the CCC.  After the installation your first reboot should run some follow-up updates via cmd, you need to reboot a second time for fully functional drivers.

Also, I had underscan on my monitor so I went out on a limb and re-ran the setup for Catalyst, and was able to get CCC installed with a second run through, which allowed me to fix my underscan issue.

My conclusion is that the CCC requires some driver functionality that isn't available until after you install the drivers, this could be on all systems or it might be related to how HVM's handle the PCI devices, that much I can't say.



Teo,

I could be spouting nonsense, and if so I'm sure Wei can correct me, but I am pretty sure AMD engineers have been contributing to Xen for a while, and some patches have already been applied.  Obviously it isn't flawless, I myself haven't gotten video at boot time, only at the login screen.

This is because VBIOS patch wasn't applied. But as I said before, my VBIOS wasn't universal enough to put it as a production patch. So I am hesitant to put it out.

Dear Wei Huang at AMD Corporation,

Please put your Xen VGA Passthrough patch out so that all of us can have a try.

Thank you very much.

http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html


Dear Wei Huang,

Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tree?

Thank you.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

Mine works on 4.1.2, but it is possible that 4.1.0 had less of these "patches" hence Sebastien's post.

Also, I apologize as I did not properly word my opinion before.  VGA Passthrough is new "for consumer components".  In 2010 the number of desktop (not server) boards boasting VT-d functionality could probably be counted on one hand.  To my understanding that means the technology is at most 3 years old, still a baby in my opinion.

I didn't mean that the technology hadn't been implemented into various Hypervisors, just that it is clearly not a perfected feature.  If you consider 3 years of consumer availability, dates become important when researching.  Sebastien's post was May 2011, just shy of one year ago, and Thomas's was in 2010.

There are newer patches still for ATI in Xen 4.2, which I intend to test over the next week.  I have NOT gotten ATI to work at boot time, video starts at the login screen.

I agree with Wei that drivers can contribute to BSOD's and errors, but when an install doesn't fail but the hardware reacts the same as before, I would like to assume the driver is irrelative.

Have you looked at XenClient project? It has a customized ATI component which allows you to switch between VMs flawlessly. I think it is the most mature Xen solution for GPU passthru in client area.

Dear Wei Huang at AMD Corporation,

May I know what is the XenClient project?



~Casey

On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang <wei.huang2@amd.com> wrote:
On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote:
Dear Casey DeLorme,

This guy, Sebastien Gauthier, also has the same problems as us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS, like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen VGA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst drivers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA card.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU generation. From this perspective, my patch isn't universal. Also there are many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you mentioned. I am not in a position to debug it for everyone's card (as I don't have all cards).

Thanks,
-Wei 

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:
On 29/03/2012 12:29, Casey DeLorme wrote:
My mistake for not hitting "Reply to All", sorry.

No worries Casey.


It might be of some value to mention that my tests were with Windows 7, I have no interest in using XP anymore.  Also, I did all of my testing through remote VNC, not once did I actually get video, even 2D, working. 

I bought 2 copies of Windows XP Home Edition in the past because it is cheap, at S$145. I did not buy Windows 7 because it is expensive. I got video working all right, but only 2D. I cannot get 3D graphics working.

However, my errors are exactly as you described:

1.  Windows recognizes the model (GTX 460), not "unknown PCI device".
2.  Device code 43.
3.  No resources assigned to the device.

We have the same set of errors.


Might be worth mentioning, I was able to run the latest nVidia driver installation without errors, but after rebooting there was no change, same error code, still no video.

Same situation here with the latest NVIDIA drivers. But I only have 2D video working. I can't get 3D video to work.

 To me this would be evidence that driver version isn't a problem, but then again I didn't have anything actually working.

I agree that driver version isn't a problem. Something is wrong somewhere.



I am an IT student in college, so my experience is limited to mostly programming with very little knowledge of the inner-workings of hardware.  So, forgive me for being unable to help with regards to memory addresses on the cards.

I am hoping that Intel engineers and Xen developers would be able to help.


I've been using *nix for about 4 years, and Windows since I my age was a single digit.  I have had experience setting up server features such as web, database, and application servers but I am still green when it comes to kernel or hardware configuration.

I started learning Linux/UNIX since the year 2005, that is about 7 years ago. I started using Windows when it was version 3.1. I love compiling the latest Linux kernel and assembling my own computer hardware.


My Xen adventure began 35 days ago, and it is no exaggeration to say that in those 35 days I have learned more about linux than I had in the past two years.  I like challenges as much as the next IT person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure lasted for 24 days through 54 fresh linux installations accompanied by over 200~ pages worth of documented failures and not a single pixel sighted.

Why not make your documentation into PDF? It is a very popular document format.


The ATI card took me a day, less than 12 hours of relatively easy debugging by comparison to the aforementioned testing.  I do fully understanding financial constraints, but it is a working solution and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy an ATI Radeon HD 6870 for $160.  For me it came down to weighing my objectives against my curiosity.

That ATI Radeon HD 6870 would cost me $279, I think.


If you do continue your nVidia endeavors I wish you success, but as in my former email VGA passthrough is a new frontier, not even Guru's like David may not be able to help beyond their own hardware experiences.

I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linux KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out of the box, as Tobias Geiger suggested, but NVIDIA requires patches.



Documentation is one problem I agree with you on 100%.  I came into this knowing relatively little about Linux & hardware, and nothing about Xen, and most every guide I found assumed I had been in a deep relationship with Linux for many years and had a basic understanding of Xen commands.

I started learning Xen since the year 2007, which is about 5 years ago.


Like you, I intend to use those documented failures as well as my recent success to create a comprehensive guide with photographs, screen captures, and perhaps even videos going from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the screenshots, I'll be certain to post it there.

I will be looking forward to your documentation and videos. Right now Xen wiki allows uploading image files and PDF files. Why not create a PDF document and share it with all of us? It is known as portable document format and is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally mess up the wiki pages, even providing bogus and erroneous information. That's why I don't like creating wiki pages. Anybody can edit and mess up the information you have painstakingly created on the wiki pages. So please take note.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



~Casey

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:
Dearest Casey DeLorme,

Thank you very very much for your kind feedback and input. I would also like to thank Mr. Tobias Geiger, again, for providing his suggestion on exposing the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing all the 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why only expose the first 3 PCI memory regions? I don't understand, of course. Jean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mailing lists, in case people think that I am finding fault with Jean David Techer, or trying to irritate him, or trying to make him angry, or trying to aggravate him. Jean David Techer replied me with an email saying that I spent too much time and too bent on solving the yellow exclamation mark glitch for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails carefully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting the following errors after applying Jean David Techer's Xen 4.2-unstable VGA Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager
(2) Windows has stopped this device because it has reported problems. (Code 43)
(3) This device isn't using any resources because it has a problem.

Jean David Techer insists that our technical issues are due to a NVIDIA driver problem. He insists that you have to install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) will not work, according to Jean David Techer. However, I have tried installing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual machine to be destroyed/terminated/crash after a few minutes and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technical issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM, or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is only 4 minutes. Please do watch Jean David Techer's Youtube video at the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM domU Youtube video link: http://www.youtube.com/watch?v=3SaYO0ERW44

I am appalled and baffled that he has attained 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.

Solving the yellow exclamation mark issue is important because we would not be able to run 3D graphics benchmarks and play 3D games without solving it. I am not sending silly emails about some yellow marks, as Jean David Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.

Casey DeLorme, with your report on relatively easy success with ATI VGA cards, I think I would go the ATI way, but I would have to spend a few hundred dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I consider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or business owner, or proprietor, or technopreneur, or entrepreneur, or technical support officer, or customer support officer, or IT helpdesk engineer, providing services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog. I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", trying to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is providing free services. It is, after all, an open source software project. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions while avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corporation. I have always provided all the steps which I have taken, the configuration files and necessary documentation, and kernel messages and error logs to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information they required. I wondered why. I think they did not read my emails carefully. They told me they would not reply to me any more if I do not provide the information they requested. But the problem is that I have always provided information they requested! I think they missed some of my emails, or did not read my emails carefully enough. I am an ardent supporter and SERIOUS software tester for open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the point of making a video on the BUG and uploading my video to Youtube. The video is only THREE minutes.

As everybody says, a picture is worth a thousand words. A video is worth a BILLION words!

I have also failed to obtain technical support from Xen developers regarding Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be releasing Version 1.7 shortly. Jean David Techer's documentation assumes some level of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not just advanced Linux and Xen users, can follow. I have made references to Jean David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it satisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to spend a few hundred dollars on an ATI VGA card. I quit my job as an IT engineer 3 years ago because my father suffered from lacunar infarct, or more commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy an ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore Polytechnic and a Bachelor's degree in Mechanical Engineering from the National University of Singapore. But I do not have qualifications in Computer Science or Information Technology. I have worked as an Information Technology engineer in Defense Science and Technology Agency, Ministry of Defense, Singapore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Machines

Thank you very much for reading my lengthy email. I am always courteous, saying "Please help me. Please. Please. Please." and "Thank you very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:
Hi Teo,

I tried David's patch files a while ago without success.  I had Xen compiled with the patch files and my GTX 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager.

You sound plenty competent, but it's important to remember that you are pioneering a technology that for consumers is still in its infancy.  Very few people are testing this with consumer equipment, so finding results seems to be a rarity.





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













-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------070309050200070401020705-- --===============5838769769867168659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5838769769867168659==-- From xen-devel-bounces@lists.xen.org Mon May 07 05:43:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 05: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 ) id 1SRGiO-0005JM-RZ; Mon, 07 May 2012 05:42:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGiM-0005JD-95 for xen-devel@lists.xen.org; Mon, 07 May 2012 05:42:30 +0000 Received: from [85.158.143.35:31277] by server-3.bemta-4.messagelabs.com id 00/0C-05853-5C067AF4; Mon, 07 May 2012 05:42:29 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336369343!14969577!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_60_70, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9262 invoked from network); 7 May 2012 05:42:25 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 05:42:25 -0000 Received: by pbbro12 with SMTP id ro12so6597241pbb.32 for ; Sun, 06 May 2012 22:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=eV/T06icd0TergATHpN37ixeZxThD3dDW0sIYBsYuBY=; b=asGavIIzdNzcwyKpjP5qiJ2SGwlZIcHiADdh01wPCzOpFiywSoYy+Nw+K7unrRcxkZ uZlVuOd5s+qTYlTKa/EMj+3HfniJWAcmiqFjRPFR45tc9d+1JxQ70+LSCCn86fy5mmWW AcyOFNJqgG4ayPTsEBNd5atGCd4P5XtJrWptV93+1b3kHSxx1EYb1e2wq27Gp5wno5f9 mRGZ8Ugq3eXBmJZpotrGzFHeUwQONs0KTPIxNPyq2Dlwhc/awH3aFXphQ6Sg6nl0MChE 1mD0xU2QH0+y+9wTwSuyQZGge1zxNsHUB/XyCCNkWm4vEFo//86H2qBRgwqnznR6Y2+l iVBA== Received: by 10.68.72.70 with SMTP id b6mr34071227pbv.58.1336369342706; Sun, 06 May 2012 22:42:22 -0700 (PDT) Received: from [192.168.1.2] (cm11.gamma206.maxonline.com.sg. [202.156.206.11]) by mx.google.com with ESMTPS id py6sm17069592pbc.13.2012.05.06.22.42.18 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 22:42:21 -0700 (PDT) Message-ID: <4FA760B9.4060501@gmail.com> Date: Mon, 07 May 2012 13:42:17 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: wei.huang2@amd.com References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F74EA35.4030305@amd.com> <4F753CD8.4050300@gmail.com> <4F75C59F.8030407@amd.com> In-Reply-To: <4F75C59F.8030407@amd.com> Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , 'Teo En Ming' , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5838769769867168659==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5838769769867168659== Content-Type: multipart/alternative; boundary="------------070309050200070401020705" This is a multi-part message in MIME format. --------------070309050200070401020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/03/2012 22:39, Wei Huang wrote: > On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote: >> On 30/03/2012 07:03, Wei Huang wrote: >>> On 03/29/2012 04:29 PM, Casey DeLorme wrote: >>>> David, >>>> >>>> XenServer VGA Passthrough requires a paid/licensed copy, which >>>> costs $2500, a bit out of my price range for experimentation. >>>> Important to note that the feature is not a part of the 30-day >>>> trial license. >>>> >>>> However, Citrix recently visited my college and I was able to >>>> preview hardware access on a laptop one of the employees had, where >>>> they swapped between Ubuntu and Windows with a hotkey, and various >>>> hardware components including onboard GPU and the WebCam were >>>> accessible. >>>> >>>> In testing XenServer, I can say that if I had a business, that's >>>> the product I would use. In the past month having tried Xen and >>>> ESXi, I was astonished with the ease of use for XenServer. >>>> >>>> As for Catalyst, version 12.2 (the latest currently) worked for me. >>>> >>>> Important to note that until I followed Andrews advice to omit the >>>> Catalyst Control Center, the installation resulted in a BSOD. >>> I saw similar issue whiling playing with XenClient. After discussing >>> with AMD GPU driver team, the conclusion was that the installer has >>> a bug. But I have not received any further update from them. Also >>> manual driver installation (after many tries) did fix problem for me. >>>> >>>> The solution, select "Custom" installation and uncheck the CCC. >>>> After the installation your first reboot should run some follow-up >>>> updates via cmd, you need to reboot a second time for fully >>>> functional drivers. >>>> >>>> Also, I had underscan on my monitor so I went out on a limb and >>>> re-ran the setup for Catalyst, and was able to get CCC installed >>>> with a second run through, which allowed me to fix my underscan issue. >>>> >>>> My conclusion is that the CCC requires some driver functionality >>>> that isn't available until after you install the drivers, this >>>> could be on all systems or it might be related to how HVM's handle >>>> the PCI devices, that much I can't say. >>>> >>>> >>>> >>>> Teo, >>>> >>>> I could be spouting nonsense, and if so I'm sure Wei can correct >>>> me, but I am pretty sure AMD engineers have been contributing to >>>> Xen for a while, and some patches have already been applied. >>>> Obviously it isn't flawless, I myself haven't gotten video at boot >>>> time, only at the login screen. >>>> >>> This is because VBIOS patch wasn't applied. But as I said before, my >>> VBIOS wasn't universal enough to put it as a production patch. So I >>> am hesitant to put it out. >> >> Dear Wei Huang at AMD Corporation, >> >> Please put your Xen VGA Passthrough patch out so that all of us can >> have a try. >> >> Thank you very much. >> > http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html Dear Wei Huang, Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tree? Thank you. >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >>>> Mine works on 4.1.2, but it is possible that 4.1.0 had less of >>>> these "patches" hence Sebastien's post. >>>> >>>> Also, I apologize as I did not properly word my opinion before. >>>> VGA Passthrough is new "for consumer components". In 2010 the >>>> number of desktop (not server) boards boasting VT-d functionality >>>> could probably be counted on one hand. To my understanding that >>>> means the technology is at most 3 years old, still a baby in my >>>> opinion. >>>> >>>> I didn't mean that the technology hadn't been implemented into >>>> various Hypervisors, just that it is clearly not a perfected >>>> feature. If you consider 3 years of consumer availability, dates >>>> become important when researching. Sebastien's post was May 2011, >>>> just shy of one year ago, and Thomas's was in 2010. >>>> >>>> There are newer patches still for ATI in Xen 4.2, which I intend to >>>> test over the next week. I have NOT gotten ATI to work at boot >>>> time, video starts at the login screen. >>>> >>>> I agree with Wei that drivers can contribute to BSOD's and errors, >>>> but when an install doesn't fail but the hardware reacts the same >>>> as before, I would like to assume the driver is irrelative. >>>> >>> Have you looked at XenClient project? It has a customized ATI >>> component which allows you to switch between VMs flawlessly. I think >>> it is the most mature Xen solution for GPU passthru in client area. >> >> Dear Wei Huang at AMD Corporation, >> >> May I know what is the XenClient project? >> >> >>>> >>>> ~Casey >>>> >>>> On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang >>> > wrote: >>>> >>>> On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: >>>>> Dear Casey DeLorme, >>>>> >>>>> This guy, Sebastien Gauthier, also has the same problems as >>>>> us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied >>>>> Mr. Wei Huang's patch. After installing the latest ATI/AMD >>>>> Catalyst drivers, he got a BSOD with Xen VGA Passthrough to >>>>> Windows 7. >>>>> >>>>> Please read Sebastien Gauthier's case here: >>>>> >>>>> http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html >>>>> >>>>> Hence Sebastien Gauthier reported Xen VGA Passthrough with >>>>> PARTIAL SUCCESS, like us. >>>>> >>>>> Dear Tobias Geiger, >>>>> >>>>> You were saying that with ATI VGA cards, you do not need to >>>>> apply any Xen VGA Passthrough patches. But this guy Sebastien >>>>> Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got >>>>> a BSOD after installing ATI Catalyst drivers. Sebastien >>>>> Gauthier did not get 100% success with Xen VGA Passthrough to >>>>> Windows 7 using an ATI VGA card. >>>>> >>>> Hi Teo, >>>> >>>> The VBIOS patch I sent out did not work for all ATI cards. The >>>> patch itself assumed certain behavior of GPU VBIOS. But this >>>> doesn't apply to every GPU generation. From this perspective, >>>> my patch isn't universal. Also there are many factors, some of >>>> which are not in control by us (like graphics driver), can >>>> contribute to BSOD you mentioned. I am not in a position to >>>> debug it for everyone's card (as I don't have all cards). >>>> >>>> Thanks, >>>> -Wei >>>> >>>>> -- >>>>> Yours sincerely, >>>>> >>>>> Mr. Teo En Ming (Zhang Enming) >>>>> Singapore >>>>> >>>>> >>>>> >>>>> >>>>> On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: >>>>>> On 29/03/2012 12:29, Casey DeLorme wrote: >>>>>>> My mistake for not hitting "Reply to All", sorry. >>>>>> >>>>>> No worries Casey. >>>>>> >>>>>>> >>>>>>> It might be of some value to mention that my tests were with >>>>>>> Windows 7, I have no interest in using XP anymore. Also, I >>>>>>> did all of my testing through remote VNC, not once did I >>>>>>> actually get video, even 2D, working. >>>>>> >>>>>> I bought 2 copies of Windows XP Home Edition in the past >>>>>> because it is cheap, at S$145. I did not buy Windows 7 >>>>>> because it is expensive. I got video working all right, but >>>>>> only 2D. I cannot get 3D graphics working. >>>>>> >>>>>>> However, my errors are exactly as you described: >>>>>>> >>>>>>> 1. Windows recognizes the model (GTX 460), not "unknown PCI >>>>>>> device". >>>>>>> 2. Device code 43. >>>>>>> 3. No resources assigned to the device. >>>>>> >>>>>> We have the same set of errors. >>>>>> >>>>>>> >>>>>>> Might be worth mentioning, I was able to run the latest >>>>>>> nVidia driver installation without errors, but after >>>>>>> rebooting there was no change, same error code, still no video. >>>>>> >>>>>> Same situation here with the latest NVIDIA drivers. But I >>>>>> only have 2D video working. I can't get 3D video to work. >>>>>> >>>>>>> To me this would be evidence that driver version isn't a >>>>>>> problem, but then again I didn't have anything actually working. >>>>>> >>>>>> I agree that driver version isn't a problem. Something is >>>>>> wrong somewhere. >>>>>> >>>>>>> >>>>>>> >>>>>>> I am an IT student in college, so my experience is limited >>>>>>> to mostly programming with very little knowledge of the >>>>>>> inner-workings of hardware. So, forgive me for being unable >>>>>>> to help with regards to memory addresses on the cards. >>>>>> >>>>>> I am hoping that Intel engineers and Xen developers would be >>>>>> able to help. >>>>>> >>>>>>> >>>>>>> I've been using *nix for about 4 years, and Windows since I >>>>>>> my age was a single digit. I have had experience setting up >>>>>>> server features such as web, database, and application >>>>>>> servers but I am still green when it comes to kernel or >>>>>>> hardware configuration. >>>>>> >>>>>> I started learning Linux/UNIX since the year 2005, that is >>>>>> about 7 years ago. I started using Windows when it was >>>>>> version 3.1. I love compiling the latest Linux kernel and >>>>>> assembling my own computer hardware. >>>>>> >>>>>>> >>>>>>> My Xen adventure began 35 days ago, and it is no >>>>>>> exaggeration to say that in those 35 days I have learned >>>>>>> more about linux than I had in the past two years. I like >>>>>>> challenges as much as the next IT person, but I ran out of >>>>>>> time and ideas for debugging my nVidia problems. The nVidia >>>>>>> stretch of my adventure lasted for 24 days through 54 fresh >>>>>>> linux installations accompanied by over 200~ pages worth of >>>>>>> documented failures and not a single pixel sighted. >>>>>> >>>>>> Why not make your documentation into PDF? It is a very >>>>>> popular document format. >>>>>> >>>>>>> >>>>>>> The ATI card took me a day, less than 12 hours of relatively >>>>>>> easy debugging by comparison to the aforementioned testing. >>>>>>> I do fully understanding financial constraints, but it is a >>>>>>> working solution and worth mentioning. I do not know what >>>>>>> the prices are like in Singapore, but in the states I was >>>>>>> able to buy an ATI Radeon HD 6870 for $160. For me it came >>>>>>> down to weighing my objectives against my curiosity. >>>>>> >>>>>> That ATI Radeon HD 6870 would cost me $279, I think. >>>>>> >>>>>>> >>>>>>> If you do continue your nVidia endeavors I wish you success, >>>>>>> but as in my former email VGA passthrough is a new frontier, >>>>>>> not even Guru's like David may not be able to help beyond >>>>>>> their own hardware experiences. >>>>>> >>>>>> I don't think VGA passthrough is a new frontier. Oracle >>>>>> VirtualBox and Linux KVM supports VGA passthrough as well. >>>>>> Xen ATI VGA Passthrough works out of the box, as Tobias >>>>>> Geiger suggested, but NVIDIA requires patches. >>>>>> >>>>>>> >>>>>>> >>>>>>> Documentation is one problem I agree with you on 100%. I >>>>>>> came into this knowing relatively little about Linux & >>>>>>> hardware, and nothing about Xen, and most every guide I >>>>>>> found assumed I had been in a deep relationship with Linux >>>>>>> for many years and had a basic understanding of Xen commands. >>>>>> >>>>>> I started learning Xen since the year 2007, which is about 5 >>>>>> years ago. >>>>>> >>>>>>> >>>>>>> Like you, I intend to use those documented failures as well >>>>>>> as my recent success to create a comprehensive guide with >>>>>>> photographs, screen captures, and perhaps even videos going >>>>>>> from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA >>>>>>> Passthrough". Provided the wiki will allow me to upload the >>>>>>> screenshots, I'll be certain to post it there. >>>>>> >>>>>> I will be looking forward to your documentation and videos. >>>>>> Right now Xen wiki allows uploading image files and PDF >>>>>> files. Why not create a PDF document and share it with all of >>>>>> us? It is known as portable document format and is very >>>>>> popular, but it appears that xen mailing lists don't like PDF >>>>>> format. >>>>>> >>>>>> _*I don't like wiki pages because anybody can edit and >>>>>> fundamentally mess up the wiki pages, even providing bogus >>>>>> and erroneous information. That's why I don't like creating >>>>>> wiki pages. Anybody can edit and mess up the information you >>>>>> have painstakingly created on the wiki pages. So please take >>>>>> note.*_ >>>>>> >>>>>> -- >>>>>> Yours sincerely, >>>>>> >>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>> Singapore >>>>>> >>>>>> >>>>>>> >>>>>>> ~Casey >>>>>>> >>>>>>> On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Dearest Casey DeLorme, >>>>>>> >>>>>>> Thank you very very much for your kind feedback and >>>>>>> input. I would also like to thank Mr. Tobias Geiger, >>>>>>> again, for providing his suggestion on exposing the >>>>>>> fourth memory region in >>>>>>> tools/firmware/hvmloader/acpi/dsdt.asl. _In any case, >>>>>>> either exposing the first 3 memory regions only or >>>>>>> exposing all the 4 memory regions does not work._ Sadly, >>>>>>> Tobias Geiger is unable to help me further. >>>>>>> >>>>>>> I have asked Jean David Techer, what about the 4th PCI >>>>>>> memory region? Why only expose the first 3 PCI memory >>>>>>> regions? I don't understand, of course. Jean David >>>>>>> Techer did not reply to my question. >>>>>>> >>>>>>> I have decided to post your prompt reply to the >>>>>>> xen-users and xen-devel mailing lists, in case people >>>>>>> think that I am finding fault with Jean David Techer, or >>>>>>> trying to irritate him, or trying to make him angry, or >>>>>>> trying to aggravate him. Jean David Techer replied me >>>>>>> with an email saying that I _spent too much time_ and >>>>>>> _too bent_ on solving the yellow exclamation mark glitch >>>>>>> for my NVIDIA Geforce 8400GS in Device Manager in >>>>>>> Windows 8 Consumer Preview and Windows XP Home Edition, >>>>>>> and that I sent *_stupid_* requests. Stupid requests? >>>>>>> Did he read my emails carefully, word by word? >>>>>>> >>>>>>> Casey DeLorme, please, can I confirm with you again that >>>>>>> you are getting the following errors after applying Jean >>>>>>> David Techer's Xen 4.2-unstable VGA Passthrough patches: >>>>>>> >>>>>>> *_(1) Yellow exclamation mark besides your NVIDIA GTX >>>>>>> 460 in Device Manager >>>>>>> (2) Windows has stopped this device because it has >>>>>>> reported problems. (Code 43) >>>>>>> (3) This device isn't using any resources because it has >>>>>>> a problem._* >>>>>>> >>>>>>> Jean David Techer insists that our technical issues are >>>>>>> due to a NVIDIA driver problem. He insists that you have >>>>>>> to install NVIDIA driver versions 275.33 WHQL and 275.50 >>>>>>> BETA. Any other NVIDIA driver versions (above 280.XX) >>>>>>> will not work, according to Jean David Techer. >>>>>>> *_However, I have tried installing NVIDIA driver >>>>>>> versions 275.33 and 275.50 from www.softpedia.com >>>>>>> , as he suggested, but it >>>>>>> caused my Windows XP Home Edition HVM virtual machine to >>>>>>> be destroyed/terminated/crash after a few minutes and my >>>>>>> dom0 to crash as well._* NVIDIA driver versions 275.33 >>>>>>> and 275.50 for Windows XP 32-bit is not available from >>>>>>> the official NVIDIA website. >>>>>>> >>>>>>> So it is definitely not a NVIDIA driver problem. I >>>>>>> suspect that the technical issue has to do with *_MMIO >>>>>>> BARs pBAR:vBAR 1:1 matching_*. I don't think there is >>>>>>> any problem with vgabios-pt.bin extracted out from our >>>>>>> NVIDIA VGA cards, because I have performed a "hexdump >>>>>>> -C" on my extracted VGA BIOS EEPROM, or Electrically >>>>>>> Erasable Programmable Read Only Memory. >>>>>>> >>>>>>> Secondly, it does seem strange that Jean David Techer >>>>>>> was able to attain *_100%_*, ie. *_perfect success_* >>>>>>> with Xen 4.2-unstable VGA Passthrough to his Windows XP >>>>>>> 32-bit and 64-bit HVM domU. Have you watched his Youtube >>>>>>> video? It is only 4 minutes. Please do watch Jean David >>>>>>> Techer's Youtube video at the following URL: >>>>>>> >>>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough to >>>>>>> Windows XP x64 HVM domU Youtube video link: >>>>>>> *_http://www.youtube.com/watch?v=3SaYO0ERW44_* >>>>>>> >>>>>>> I am *_appalled_* and *_baffle__d_* that he has attained >>>>>>> *_100% success_* while both of us have only attained >>>>>>> *_partial succes__s_* (*_i.e. less than 100%_*) on Xen >>>>>>> 4.2-unstable VGA Passthrough to Windows 8 Consumer >>>>>>> Preview and Windows XP. >>>>>>> >>>>>>> *_Solving the yellow exclamation mark issue is important >>>>>>> because we would not be able to run 3D graphics >>>>>>> benchmarks and play 3D games without solving it. I am >>>>>>> not sending silly emails about some yellow marks, as >>>>>>> Jean David Techer suggested. I can't even run Unigine >>>>>>> Heaven DX11, and 3dmark11 3D display benchmarks, because >>>>>>> of the yellow exclamation mark for NVIDIA Geforce 8400 >>>>>>> GS in Device Manager._* >>>>>>> >>>>>>> Casey DeLorme, with your report on relatively easy >>>>>>> success with ATI VGA cards, I think I would go the ATI >>>>>>> way, but I would have to spend a few hundred dollars >>>>>>> compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. >>>>>>> And while deciding to go the ATI way, I would also like >>>>>>> to continue troubleshooting with the NVIDIA problem, >>>>>>> because I consider it to be a technical challenge. >>>>>>> >>>>>>> In essence, Jean David Techner is considered to be a >>>>>>> "boss", or business owner, or proprietor, or >>>>>>> technopreneur, or entrepreneur, or technical support >>>>>>> officer, or customer support officer, or IT helpdesk >>>>>>> engineer, providing services like his forward-ported Xen >>>>>>> 4.2-unstable VGA Passthrough patches and the >>>>>>> documentation on his blog. I repost Jean David Techer's >>>>>>> official website here: >>>>>>> >>>>>>> Jean David Techer's Xen 4.2-unstable VGA Passthrough >>>>>>> blog: >>>>>>> *_http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through_* >>>>>>> >>>>>>> Jean David Techer's official website is his business >>>>>>> venture. >>>>>>> >>>>>>> Basically, I am Jean David Techer's *_"customer"_*, >>>>>>> trying to obtain technical support from him. Of course, >>>>>>> he is *_not obliged_* to provide technical support to me >>>>>>> since he is providing *_free_* services. It is, after >>>>>>> all, an open source software project. Nobody is obliged >>>>>>> to provide anybody with technical support. *_To do Jean >>>>>>> David Techer justice, he replied most of my questions >>>>>>> while avoiding some of my questions._* >>>>>>> >>>>>>> Finally, I have also failed to obtain technical support >>>>>>> from Xen developers like Ian Campbell from *_Citrix >>>>>>> Corporation_* and Konrad Wilk from *_Oracle >>>>>>> Corporation_*. _*I have always provided all the steps >>>>>>> which I have taken, the configuration files and >>>>>>> necessary documentation, and kernel messages and error >>>>>>> logs*_ to xen-users and xen-devel mailing lists, but >>>>>>> they keep insisting I did not provide the information >>>>>>> they required. I wondered why. I think they did not read >>>>>>> my emails carefully. They told me they would not reply >>>>>>> to me any more if I do not provide the information they >>>>>>> requested. _*But the problem is that I have always >>>>>>> provided information they requested!*_ I think they >>>>>>> missed some of my emails, or did not read my emails >>>>>>> carefully enough. I am an *_ardent supporter_* and >>>>>>> *_SERIOUS software tester_* for open source Xen >>>>>>> virtualization/hypervisor but they treated me lightly. >>>>>>> _*I always read my emails WORD BY WORD.*_ I have even >>>>>>> went to the point of making a video on the *_BUG_* and >>>>>>> uploading my video to Youtube. The video is only THREE >>>>>>> minutes. >>>>>>> >>>>>>> _*As everybody says, a picture is worth a thousand >>>>>>> words. A video is worth a BILLION words!*_ >>>>>>> >>>>>>> I have also failed to obtain technical support from Xen >>>>>>> developers regarding Xen 4.2-unstable VGA Passthrough. >>>>>>> >>>>>>> I am hoping Xen 4.2 would have official support for Xen >>>>>>> VGA Passthrough for both NVIDIA and ATI cards. >>>>>>> >>>>>>> Casey DeLorme, thank you very much once again. I will be >>>>>>> making changes to my Xen, Linux Kernel and Xen VGA >>>>>>> Passthrough Documentation and will be releasing Version >>>>>>> 1.7 shortly. Jean David Techer's documentation assumes >>>>>>> some level of advanced Linux technical knowledge, so I >>>>>>> am writing documentation on my own so that everybody, >>>>>>> not just advanced Linux and Xen users, can follow. I >>>>>>> have made references to Jean David Techer's >>>>>>> documentation in my own documentation. >>>>>>> >>>>>>> I would be very happy if people would use my >>>>>>> documentation. Of course, it satisfies my ego and my >>>>>>> vanity. Haha. >>>>>>> >>>>>>> I have been un-employed for nearly three years now, and >>>>>>> I would hesitate to spend a few hundred dollars on an >>>>>>> ATI VGA card. I quit my job as an IT engineer 3 years >>>>>>> ago because my father suffered from lacunar infarct, or >>>>>>> more commonly known as stroke. My NVIDIA Geforce 8400 GS >>>>>>> costs only S$44. Please understand why I hesitate to buy >>>>>>> an ATI VGA card. The cheapest one costs SGD$279. >>>>>>> >>>>>>> I have a diploma in Mechanical+Electronics engineering >>>>>>> from Singapore Polytechnic and a Bachelor's degree in >>>>>>> Mechanical Engineering from the National University of >>>>>>> Singapore. But I do not have qualifications in Computer >>>>>>> Science or Information Technology. I have worked as an >>>>>>> Information Technology engineer in Defense Science and >>>>>>> Technology Agency, Ministry of Defense, Singapore, >>>>>>> National Computer Systems Pte Ltd, Asiasoft Online Pte >>>>>>> Ltd, and Ishinemax Singapore Pte Ltd. >>>>>>> >>>>>>> Google search terms: Frenchman Jean David Techer, >>>>>>> Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA >>>>>>> Passthrough Documentation, Xen 4.2-unstable VGA >>>>>>> Passthrough to Windows 8 Consumer Preview and Windows XP >>>>>>> HVM Virtual Machines >>>>>>> >>>>>>> Thank you very much for reading my lengthy email. I am >>>>>>> always courteous, saying "Please help me. Please. >>>>>>> Please. Please." and "Thank you very much for your kind >>>>>>> assistance" in my emails. >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>>> -- >>>>>>> Yours sincerely, >>>>>>> Mr. Teo En Ming (Zhang Enming) >>>>>>> Singapore Citizen >>>>>>> >>>>>>> cc: His Excellency The Prime Minister Mr. Lee Hsien >>>>>>> Loong, Prime Minister's Office, Republic of Singapore >>>>>>> >>>>>>> On 29/03/2012 03:53, Casey DeLorme wrote: >>>>>>>> Hi Teo, >>>>>>>> >>>>>>>> I tried David's patch files a while ago *_without >>>>>>>> success_*. I had Xen compiled with the patch files and >>>>>>>> my GTX 460 VGA BIOS rom, _*but I got the same as you, >>>>>>>> either a BSOD or Code 43 in Device Manager.*_ >>>>>>>> >>>>>>>> You sound plenty competent, but it's important to >>>>>>>> remember that you are pioneering a technology that for >>>>>>>> consumers is still in its infancy. Very few people are >>>>>>>> testing this with consumer equipment, so finding >>>>>>>> results seems to be a rarity. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-users mailing list >>>>>>> Xen-users@lists.xen.org >>>>>>> http://lists.xen.org/xen-users >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------070309050200070401020705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 30/03/2012 22:39, Wei Huang wrote:
On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote:
On 30/03/2012 07:03, Wei Huang wrote:
On 03/29/2012 04:29 PM, Casey DeLorme wrote:
David,

XenServer VGA Passthrough requires a paid/licensed copy, which costs $2500, a bit out of my price range for experimentation.  Important to note that the feature is not a part of the 30-day trial license.

However, Citrix recently visited my college and I was able to preview hardware access on a laptop one of the employees had, where they swapped between Ubuntu and Windows with a hotkey, and various hardware components including onboard GPU and the WebCam were accessible.

In testing XenServer, I can say that if I had a business, that's the product I would use.  In the past month having tried Xen and ESXi, I was astonished with the ease of use for XenServer.

As for Catalyst, version 12.2 (the latest currently) worked for me.

Important to note that until I followed Andrews advice to omit the Catalyst Control Center, the installation resulted in a BSOD.
I saw similar issue whiling playing with XenClient. After discussing with AMD GPU driver team, the conclusion was that the installer has a bug. But I have not received any further update from them. Also manual driver installation (after many tries) did fix problem for me.

The solution, select "Custom" installation and uncheck the CCC.  After the installation your first reboot should run some follow-up updates via cmd, you need to reboot a second time for fully functional drivers.

Also, I had underscan on my monitor so I went out on a limb and re-ran the setup for Catalyst, and was able to get CCC installed with a second run through, which allowed me to fix my underscan issue.

My conclusion is that the CCC requires some driver functionality that isn't available until after you install the drivers, this could be on all systems or it might be related to how HVM's handle the PCI devices, that much I can't say.



Teo,

I could be spouting nonsense, and if so I'm sure Wei can correct me, but I am pretty sure AMD engineers have been contributing to Xen for a while, and some patches have already been applied.  Obviously it isn't flawless, I myself haven't gotten video at boot time, only at the login screen.

This is because VBIOS patch wasn't applied. But as I said before, my VBIOS wasn't universal enough to put it as a production patch. So I am hesitant to put it out.

Dear Wei Huang at AMD Corporation,

Please put your Xen VGA Passthrough patch out so that all of us can have a try.

Thank you very much.

http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.html


Dear Wei Huang,

Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tree?

Thank you.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

Mine works on 4.1.2, but it is possible that 4.1.0 had less of these "patches" hence Sebastien's post.

Also, I apologize as I did not properly word my opinion before.  VGA Passthrough is new "for consumer components".  In 2010 the number of desktop (not server) boards boasting VT-d functionality could probably be counted on one hand.  To my understanding that means the technology is at most 3 years old, still a baby in my opinion.

I didn't mean that the technology hadn't been implemented into various Hypervisors, just that it is clearly not a perfected feature.  If you consider 3 years of consumer availability, dates become important when researching.  Sebastien's post was May 2011, just shy of one year ago, and Thomas's was in 2010.

There are newer patches still for ATI in Xen 4.2, which I intend to test over the next week.  I have NOT gotten ATI to work at boot time, video starts at the login screen.

I agree with Wei that drivers can contribute to BSOD's and errors, but when an install doesn't fail but the hardware reacts the same as before, I would like to assume the driver is irrelative.

Have you looked at XenClient project? It has a customized ATI component which allows you to switch between VMs flawlessly. I think it is the most mature Xen solution for GPU passthru in client area.

Dear Wei Huang at AMD Corporation,

May I know what is the XenClient project?



~Casey

On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang <wei.huang2@amd.com> wrote:
On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote:
Dear Casey DeLorme,

This guy, Sebastien Gauthier, also has the same problems as us. He was using Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS, like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen VGA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Huang's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst drivers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA card.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU generation. From this perspective, my patch isn't universal. Also there are many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you mentioned. I am not in a position to debug it for everyone's card (as I don't have all cards).

Thanks,
-Wei 

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:
On 29/03/2012 12:29, Casey DeLorme wrote:
My mistake for not hitting "Reply to All", sorry.

No worries Casey.


It might be of some value to mention that my tests were with Windows 7, I have no interest in using XP anymore.  Also, I did all of my testing through remote VNC, not once did I actually get video, even 2D, working. 

I bought 2 copies of Windows XP Home Edition in the past because it is cheap, at S$145. I did not buy Windows 7 because it is expensive. I got video working all right, but only 2D. I cannot get 3D graphics working.

However, my errors are exactly as you described:

1.  Windows recognizes the model (GTX 460), not "unknown PCI device".
2.  Device code 43.
3.  No resources assigned to the device.

We have the same set of errors.


Might be worth mentioning, I was able to run the latest nVidia driver installation without errors, but after rebooting there was no change, same error code, still no video.

Same situation here with the latest NVIDIA drivers. But I only have 2D video working. I can't get 3D video to work.

 To me this would be evidence that driver version isn't a problem, but then again I didn't have anything actually working.

I agree that driver version isn't a problem. Something is wrong somewhere.



I am an IT student in college, so my experience is limited to mostly programming with very little knowledge of the inner-workings of hardware.  So, forgive me for being unable to help with regards to memory addresses on the cards.

I am hoping that Intel engineers and Xen developers would be able to help.


I've been using *nix for about 4 years, and Windows since I my age was a single digit.  I have had experience setting up server features such as web, database, and application servers but I am still green when it comes to kernel or hardware configuration.

I started learning Linux/UNIX since the year 2005, that is about 7 years ago. I started using Windows when it was version 3.1. I love compiling the latest Linux kernel and assembling my own computer hardware.


My Xen adventure began 35 days ago, and it is no exaggeration to say that in those 35 days I have learned more about linux than I had in the past two years.  I like challenges as much as the next IT person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure lasted for 24 days through 54 fresh linux installations accompanied by over 200~ pages worth of documented failures and not a single pixel sighted.

Why not make your documentation into PDF? It is a very popular document format.


The ATI card took me a day, less than 12 hours of relatively easy debugging by comparison to the aforementioned testing.  I do fully understanding financial constraints, but it is a working solution and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy an ATI Radeon HD 6870 for $160.  For me it came down to weighing my objectives against my curiosity.

That ATI Radeon HD 6870 would cost me $279, I think.


If you do continue your nVidia endeavors I wish you success, but as in my former email VGA passthrough is a new frontier, not even Guru's like David may not be able to help beyond their own hardware experiences.

I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linux KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out of the box, as Tobias Geiger suggested, but NVIDIA requires patches.



Documentation is one problem I agree with you on 100%.  I came into this knowing relatively little about Linux & hardware, and nothing about Xen, and most every guide I found assumed I had been in a deep relationship with Linux for many years and had a basic understanding of Xen commands.

I started learning Xen since the year 2007, which is about 5 years ago.


Like you, I intend to use those documented failures as well as my recent success to create a comprehensive guide with photographs, screen captures, and perhaps even videos going from "assembled computer" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the screenshots, I'll be certain to post it there.

I will be looking forward to your documentation and videos. Right now Xen wiki allows uploading image files and PDF files. Why not create a PDF document and share it with all of us? It is known as portable document format and is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally mess up the wiki pages, even providing bogus and erroneous information. That's why I don't like creating wiki pages. Anybody can edit and mess up the information you have painstakingly created on the wiki pages. So please take note.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



~Casey

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:
Dearest Casey DeLorme,

Thank you very very much for your kind feedback and input. I would also like to thank Mr. Tobias Geiger, again, for providing his suggestion on exposing the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing all the 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why only expose the first 3 PCI memory regions? I don't understand, of course. Jean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mailing lists, in case people think that I am finding fault with Jean David Techer, or trying to irritate him, or trying to make him angry, or trying to aggravate him. Jean David Techer replied me with an email saying that I spent too much time and too bent on solving the yellow exclamation mark glitch for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails carefully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting the following errors after applying Jean David Techer's Xen 4.2-unstable VGA Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager
(2) Windows has stopped this device because it has reported problems. (Code 43)
(3) This device isn't using any resources because it has a problem.

Jean David Techer insists that our technical issues are due to a NVIDIA driver problem. He insists that you have to install NVIDIA driver versions 275.33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) will not work, according to Jean David Techer. However, I have tried installing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual machine to be destroyed/terminated/crash after a few minutes and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technical issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM, or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is only 4 minutes. Please do watch Jean David Techer's Youtube video at the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM domU Youtube video link: http://www.youtube.com/watch?v=3SaYO0ERW44

I am appalled and baffled that he has attained 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.

Solving the yellow exclamation mark issue is important because we would not be able to run 3D graphics benchmarks and play 3D games without solving it. I am not sending silly emails about some yellow marks, as Jean David Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.

Casey DeLorme, with your report on relatively easy success with ATI VGA cards, I think I would go the ATI way, but I would have to spend a few hundred dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I consider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or business owner, or proprietor, or technopreneur, or entrepreneur, or technical support officer, or customer support officer, or IT helpdesk engineer, providing services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog. I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", trying to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is providing free services. It is, after all, an open source software project. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions while avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corporation. I have always provided all the steps which I have taken, the configuration files and necessary documentation, and kernel messages and error logs to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information they required. I wondered why. I think they did not read my emails carefully. They told me they would not reply to me any more if I do not provide the information they requested. But the problem is that I have always provided information they requested! I think they missed some of my emails, or did not read my emails carefully enough. I am an ardent supporter and SERIOUS software tester for open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the point of making a video on the BUG and uploading my video to Youtube. The video is only THREE minutes.

As everybody says, a picture is worth a thousand words. A video is worth a BILLION words!

I have also failed to obtain technical support from Xen developers regarding Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be releasing Version 1.7 shortly. Jean David Techer's documentation assumes some level of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not just advanced Linux and Xen users, can follow. I have made references to Jean David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it satisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to spend a few hundred dollars on an ATI VGA card. I quit my job as an IT engineer 3 years ago because my father suffered from lacunar infarct, or more commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy an ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore Polytechnic and a Bachelor's degree in Mechanical Engineering from the National University of Singapore. But I do not have qualifications in Computer Science or Information Technology. I have worked as an Information Technology engineer in Defense Science and Technology Agency, Ministry of Defense, Singapore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Machines

Thank you very much for reading my lengthy email. I am always courteous, saying "Please help me. Please. Please. Please." and "Thank you very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:
Hi Teo,

I tried David's patch files a while ago without success.  I had Xen compiled with the patch files and my GTX 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager.

You sound plenty competent, but it's important to remember that you are pioneering a technology that for consumers is still in its infancy.  Very few people are testing this with consumer equipment, so finding results seems to be a rarity.





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













-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------070309050200070401020705-- --===============5838769769867168659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5838769769867168659==-- From xen-devel-bounces@lists.xen.org Mon May 07 06:24:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06: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 ) id 1SRHMD-00061T-Gx; Mon, 07 May 2012 06:23:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHMB-00061O-8U for xen-devel@lists.xensource.com; Mon, 07 May 2012 06:23:39 +0000 Received: from [85.158.138.51:53335] by server-7.bemta-3.messagelabs.com id EF/6A-03078-A6A67AF4; Mon, 07 May 2012 06:23:38 +0000 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336371816!25667744!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8492 invoked from network); 7 May 2012 06:23:37 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 06:23:37 -0000 Received: by vcbfl15 with SMTP id fl15so4125296vcb.30 for ; Sun, 06 May 2012 23:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=C5euvMD3mV2pkZRAgHEbn56EHcR5YzPj9C9+TEyMY+A=; b=vfUSi3CgS4mYWEn6E9tDwarc/G9gMzGjkbIZ7pUne65sU78+QSLwXWS8uUsZTrxfze R0qSGzkJUguLnYHPG8w1whWIynQ21OZzgSUTWvn03pyzaMZAMMtyalOjP+mICRX6YVk9 +SP/5XHVWG5gXJRRD7Nf8xEhexgI699kdJTnLLgcIBSJ4nahCp4TzRnwMjCv0C8nsYmp GYSjfinlrTxbrXSOikf8i0KEtmg6Acdh3k3sMb0ljDkUvQDBItFG/bdyN+W+4kf9tEog /0qCJqX8PP7jV5VGIiZn85J1fgRDJhPFUkxtHwpjZYsNQtMTVTMFEqN8hCD05pBjOWUM Hnbg== MIME-Version: 1.0 Received: by 10.52.179.35 with SMTP id dd3mr6227742vdc.2.1336371815940; Sun, 06 May 2012 23:23:35 -0700 (PDT) Received: by 10.220.35.142 with HTTP; Sun, 6 May 2012 23:23:35 -0700 (PDT) Date: Mon, 7 May 2012 15:23:35 +0900 Message-ID: From: Daniel Castro To: xen-devel@lists.xensource.com Subject: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello List, I have a small problem with the ring when transferring blocks the id on the response is different from the request. This is the boot up read, count 0. The guest requests block 0, it has to be located at 7c00. I go ahead and create a REQUEST with this data: ring_req =3D RING_GET_REQUEST(priv,priv->req_prod_pvt); ring_req->id =3D 9; ring_req->nr_segments=3D1; ring_req->operation =3D BLKIF_OP_READ; ring_req->sector_number =3D (int)op->lba; //sector to be read ring_req->seg[0].gref =3D (bi->buffer_gref); //this should be get_free_gref= (); ring_req->seg[0].first_sect =3D 0;//op->lba; ring_req->seg[0].last_sect =3D 7;//op->lba + op->count; RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return notify=3D0 if(notify){ dprintf(1,"Start notify procedure\n"); evtchn_send_t send; send.port =3D (bi->port); dprintf(1,"In notify before hypercall port is %d\n",send.port); //hypercall_event_channel_op(EVTCHNOP_send, &send); dprintf(1,"HYPERCALL read operation notify res %d\n", hypercall_event_channel_op(EVTCHNOP_send,&send)); } ring_res =3D RING_GET_RESPONSE((priv),(temp->rsp_prod)); Then I get: FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is the line: = dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", ring_res,ring_res->id,ring_res->status,ring_res->operation); The id should be the same on both the request and response, there are bi ither requests on the fly. Any clue?=3D Thanks, Daniel -- = +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 06:24:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06: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 ) id 1SRHMD-00061T-Gx; Mon, 07 May 2012 06:23:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHMB-00061O-8U for xen-devel@lists.xensource.com; Mon, 07 May 2012 06:23:39 +0000 Received: from [85.158.138.51:53335] by server-7.bemta-3.messagelabs.com id EF/6A-03078-A6A67AF4; Mon, 07 May 2012 06:23:38 +0000 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336371816!25667744!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8492 invoked from network); 7 May 2012 06:23:37 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vx0-f171.google.com) (209.85.220.171) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 06:23:37 -0000 Received: by vcbfl15 with SMTP id fl15so4125296vcb.30 for ; Sun, 06 May 2012 23:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=C5euvMD3mV2pkZRAgHEbn56EHcR5YzPj9C9+TEyMY+A=; b=vfUSi3CgS4mYWEn6E9tDwarc/G9gMzGjkbIZ7pUne65sU78+QSLwXWS8uUsZTrxfze R0qSGzkJUguLnYHPG8w1whWIynQ21OZzgSUTWvn03pyzaMZAMMtyalOjP+mICRX6YVk9 +SP/5XHVWG5gXJRRD7Nf8xEhexgI699kdJTnLLgcIBSJ4nahCp4TzRnwMjCv0C8nsYmp GYSjfinlrTxbrXSOikf8i0KEtmg6Acdh3k3sMb0ljDkUvQDBItFG/bdyN+W+4kf9tEog /0qCJqX8PP7jV5VGIiZn85J1fgRDJhPFUkxtHwpjZYsNQtMTVTMFEqN8hCD05pBjOWUM Hnbg== MIME-Version: 1.0 Received: by 10.52.179.35 with SMTP id dd3mr6227742vdc.2.1336371815940; Sun, 06 May 2012 23:23:35 -0700 (PDT) Received: by 10.220.35.142 with HTTP; Sun, 6 May 2012 23:23:35 -0700 (PDT) Date: Mon, 7 May 2012 15:23:35 +0900 Message-ID: From: Daniel Castro To: xen-devel@lists.xensource.com Subject: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello List, I have a small problem with the ring when transferring blocks the id on the response is different from the request. This is the boot up read, count 0. The guest requests block 0, it has to be located at 7c00. I go ahead and create a REQUEST with this data: ring_req =3D RING_GET_REQUEST(priv,priv->req_prod_pvt); ring_req->id =3D 9; ring_req->nr_segments=3D1; ring_req->operation =3D BLKIF_OP_READ; ring_req->sector_number =3D (int)op->lba; //sector to be read ring_req->seg[0].gref =3D (bi->buffer_gref); //this should be get_free_gref= (); ring_req->seg[0].first_sect =3D 0;//op->lba; ring_req->seg[0].last_sect =3D 7;//op->lba + op->count; RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return notify=3D0 if(notify){ dprintf(1,"Start notify procedure\n"); evtchn_send_t send; send.port =3D (bi->port); dprintf(1,"In notify before hypercall port is %d\n",send.port); //hypercall_event_channel_op(EVTCHNOP_send, &send); dprintf(1,"HYPERCALL read operation notify res %d\n", hypercall_event_channel_op(EVTCHNOP_send,&send)); } ring_res =3D RING_GET_RESPONSE((priv),(temp->rsp_prod)); Then I get: FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is the line: = dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", ring_res,ring_res->id,ring_res->status,ring_res->operation); The id should be the same on both the request and response, there are bi ither requests on the fly. Any clue?=3D Thanks, Daniel -- = +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 06:40:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHcN-0006DC-36; Mon, 07 May 2012 06:40:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHcL-0006D7-Cc for xen-devel@lists.xensource.com; Mon, 07 May 2012 06:40:21 +0000 Received: from [85.158.143.99:58244] by server-3.bemta-4.messagelabs.com id FD/54-05853-45E67AF4; Mon, 07 May 2012 06:40:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336372819!21461147!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6772 invoked from network); 7 May 2012 06:40:19 -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; 7 May 2012 06:40:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="12321471" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 06: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; Mon, 7 May 2012 07:39:54 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRHbu-000606-4t; Mon, 07 May 2012 06:39:54 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRHbu-0002wy-15; Mon, 07 May 2012 07:39:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 07:39:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12793: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12793 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12793/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail pass in 12792 test-amd64-i386-pair 16 guest-start fail pass in 12792 test-amd64-amd64-xl-sedf 9 guest-start fail in 12792 pass in 12793 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12792 like 12791 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 06:40:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHcN-0006DC-36; Mon, 07 May 2012 06:40:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHcL-0006D7-Cc for xen-devel@lists.xensource.com; Mon, 07 May 2012 06:40:21 +0000 Received: from [85.158.143.99:58244] by server-3.bemta-4.messagelabs.com id FD/54-05853-45E67AF4; Mon, 07 May 2012 06:40:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336372819!21461147!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ5Ng==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6772 invoked from network); 7 May 2012 06:40:19 -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; 7 May 2012 06:40:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="12321471" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 06: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; Mon, 7 May 2012 07:39:54 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRHbu-000606-4t; Mon, 07 May 2012 06:39:54 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRHbu-0002wy-15; Mon, 07 May 2012 07:39:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 07:39:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12793: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12793 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12793/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail pass in 12792 test-amd64-i386-pair 16 guest-start fail pass in 12792 test-amd64-amd64-xl-sedf 9 guest-start fail in 12792 pass in 12793 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail in 12792 like 12791 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 0f53540494f7 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 06:43:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06:43:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHew-0006IR-KX; Mon, 07 May 2012 06:43:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHev-0006IM-2T for xen-devel@lists.xen.org; Mon, 07 May 2012 06:43:01 +0000 Received: from [85.158.139.83:46450] by server-2.bemta-5.messagelabs.com id 9D/BA-17016-4FE67AF4; Mon, 07 May 2012 06:43:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336372978!15788796!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17109 invoked from network); 7 May 2012 06:42:59 -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; 7 May 2012 06:42:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 07:42:57 +0100 Message-Id: <4FA78B0B0200007800081EF0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 07:42:51 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> In-Reply-To: <4FA40321.3080201@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 18:26, David Vrabel wrote: > On 04/05/12 17:12, Jan Beulich wrote: >>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>> From: David Vrabel >>> >>> The dom0_max_vcpus command line option only allows the exact number of >>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>> but no more than the number physically present." >>> >>> Add min: and max: prefixes to the option to set a minimum number of >>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>> >>> For example, with "dom0_max_vcpus=min:4,max:8": >> >> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >> how about simply allowing a range along with a simple number (since >> negative values make no sense, omitting either side of the range would >> be supportable if necessary. > > I was copying the way dom0_mem worked but yeah, it's not very pretty. > > Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were > thinking of? Yes. > Using a single value would have to set both and or the > behaviour of the option changes (i.e., =N is the same as =N-N). That sounds plausible. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 06:43:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 06:43:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHew-0006IR-KX; Mon, 07 May 2012 06:43:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHev-0006IM-2T for xen-devel@lists.xen.org; Mon, 07 May 2012 06:43:01 +0000 Received: from [85.158.139.83:46450] by server-2.bemta-5.messagelabs.com id 9D/BA-17016-4FE67AF4; Mon, 07 May 2012 06:43:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336372978!15788796!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17109 invoked from network); 7 May 2012 06:42:59 -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; 7 May 2012 06:42:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 07:42:57 +0100 Message-Id: <4FA78B0B0200007800081EF0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 07:42:51 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> In-Reply-To: <4FA40321.3080201@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 18:26, David Vrabel wrote: > On 04/05/12 17:12, Jan Beulich wrote: >>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>> From: David Vrabel >>> >>> The dom0_max_vcpus command line option only allows the exact number of >>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>> but no more than the number physically present." >>> >>> Add min: and max: prefixes to the option to set a minimum number of >>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>> >>> For example, with "dom0_max_vcpus=min:4,max:8": >> >> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >> how about simply allowing a range along with a simple number (since >> negative values make no sense, omitting either side of the range would >> be supportable if necessary. > > I was copying the way dom0_mem worked but yeah, it's not very pretty. > > Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were > thinking of? Yes. > Using a single value would have to set both and or the > behaviour of the option changes (i.e., =N is the same as =N-N). That sounds plausible. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:16:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:16:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIAh-0006ze-Vr; Mon, 07 May 2012 07:15:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIAg-0006zY-Tf for xen-devel@lists.xen.org; Mon, 07 May 2012 07:15:51 +0000 Received: from [85.158.143.99:43332] by server-3.bemta-4.messagelabs.com id 77/F5-05853-6A677AF4; Mon, 07 May 2012 07:15:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336374949!19740764!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23973 invoked from network); 7 May 2012 07:15:49 -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; 7 May 2012 07:15:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:15:48 +0100 Message-Id: <4FA792C00200007800081F06@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:15:44 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 21:30, AP wrote: > From the above I realized that X86_CR4_OSXSAVE was never getting set > in v->arch.pv_vcpu.ctrlreg[4]. Yes, that was the observation in the previous thread too, but the reporter didn't seem interested in continuing on from there. > So I tried the following patch: > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 > +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > hv_cr4_mask &= ~X86_CR4_DE; > if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > hv_cr4_mask &= ~X86_CR4_FSGSBASE; > - if ( xsave_enabled(v) ) > - hv_cr4_mask &= ~X86_CR4_OSXSAVE; > > if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) > gdprintk(XENLOG_WARNING, > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 > +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > & ~X86_CR4_DE) > #define real_cr4_to_pv_guest_cr4(c) \ > ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ > - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > + | X86_CR4_SMEP)) > > void domain_cpuid(struct domain *d, > unsigned int input, No, this is specifically the wrong thing. From what we know so far (i.e. the outcome of the above printing you added) the problem in in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to attempting XSETBV). What your patch efectively does is take away control from the guest kernels to control the (virtual) CR4 flag... > That allowed the system to boot successfully though I did see the > following message: > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 ... which is what this message is telling you. > Not sure if the above patch is right fix but I hope it was at least > helpful in pointing at where the problem might be. > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. Sure, as it's a kernel problem. It's the kernel that needs logging added, to find out why the CR4 write supposedly happening immediately prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually happen, or doesn't set the flag. Perhaps something fishy going on with the paravirt ops patching, since the disassembly of the opcode bytes shown with the oops message are indicating that the right thing is being attempted: ff 14 25 10 33 c1 81 callq *0xffffffff81c13310 48 89 c7 mov %rax,%rdi 48 81 cf 00 00 04 00 or $0x40000,%rdi ^^^^^^^^ ff 14 25 18 33 c1 81 callq *0xffffffff81c13318 48 8b 05 0d 15 db 00 mov 0xdb150d(%rip),%rax 31 c9 xor %ecx,%ecx 48 89 c2 mov %rax,%rdx 48 c1 ea 20 shr $0x20,%rdx 0f 01 d1 xsetbv 5d pop %rbp c3 retq The primary thing that strikes me as odd is that both calls are still indirect ones, even though I thought that they should get replaced by direct ones (or even the actual instruction, namely in the read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? And the dumped %rdi value indicates that bit 18 did _not_ get set. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:16:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:16:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIAh-0006ze-Vr; Mon, 07 May 2012 07:15:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIAg-0006zY-Tf for xen-devel@lists.xen.org; Mon, 07 May 2012 07:15:51 +0000 Received: from [85.158.143.99:43332] by server-3.bemta-4.messagelabs.com id 77/F5-05853-6A677AF4; Mon, 07 May 2012 07:15:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336374949!19740764!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23973 invoked from network); 7 May 2012 07:15:49 -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; 7 May 2012 07:15:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:15:48 +0100 Message-Id: <4FA792C00200007800081F06@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:15:44 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 21:30, AP wrote: > From the above I realized that X86_CR4_OSXSAVE was never getting set > in v->arch.pv_vcpu.ctrlreg[4]. Yes, that was the observation in the previous thread too, but the reporter didn't seem interested in continuing on from there. > So I tried the following patch: > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 > +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > hv_cr4_mask &= ~X86_CR4_DE; > if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > hv_cr4_mask &= ~X86_CR4_FSGSBASE; > - if ( xsave_enabled(v) ) > - hv_cr4_mask &= ~X86_CR4_OSXSAVE; > > if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) > gdprintk(XENLOG_WARNING, > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 > +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > & ~X86_CR4_DE) > #define real_cr4_to_pv_guest_cr4(c) \ > ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ > - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > + | X86_CR4_SMEP)) > > void domain_cpuid(struct domain *d, > unsigned int input, No, this is specifically the wrong thing. From what we know so far (i.e. the outcome of the above printing you added) the problem in in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to attempting XSETBV). What your patch efectively does is take away control from the guest kernels to control the (virtual) CR4 flag... > That allowed the system to boot successfully though I did see the > following message: > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 ... which is what this message is telling you. > Not sure if the above patch is right fix but I hope it was at least > helpful in pointing at where the problem might be. > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. Sure, as it's a kernel problem. It's the kernel that needs logging added, to find out why the CR4 write supposedly happening immediately prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually happen, or doesn't set the flag. Perhaps something fishy going on with the paravirt ops patching, since the disassembly of the opcode bytes shown with the oops message are indicating that the right thing is being attempted: ff 14 25 10 33 c1 81 callq *0xffffffff81c13310 48 89 c7 mov %rax,%rdi 48 81 cf 00 00 04 00 or $0x40000,%rdi ^^^^^^^^ ff 14 25 18 33 c1 81 callq *0xffffffff81c13318 48 8b 05 0d 15 db 00 mov 0xdb150d(%rip),%rax 31 c9 xor %ecx,%ecx 48 89 c2 mov %rax,%rdx 48 c1 ea 20 shr $0x20,%rdx 0f 01 d1 xsetbv 5d pop %rbp c3 retq The primary thing that strikes me as odd is that both calls are still indirect ones, even though I thought that they should get replaced by direct ones (or even the actual instruction, namely in the read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? And the dumped %rdi value indicates that bit 18 did _not_ get set. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:25:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07: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 ) id 1SRIJD-0007Cs-Va; Mon, 07 May 2012 07:24:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIJC-0007Cm-He for xen-devel@lists.xen.org; Mon, 07 May 2012 07:24:38 +0000 Received: from [85.158.143.99:28776] by server-3.bemta-4.messagelabs.com id E2/EE-05853-5B877AF4; Mon, 07 May 2012 07:24:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336375476!26766788!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16809 invoked from network); 7 May 2012 07:24:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 07:24:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:24:36 +0100 Message-Id: <4FA794D00200007800081F1E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:24:32 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 10:10, "Hao, Xudong" wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: >> I continue to disagree to doing this always, unconditionally, with >> hard-coded settings. If these features require explicit enabling, >> there likely is something that drivers unaware of them could have >> problems with - otherwise I would think these features would be >> always enabled when a device supports them, and no options >> would exist to control certain parameters. >> > I agree the driver control it, but it's difficult to let guest driver do it > till now(because of PCIe emulation by qemu issue). Then why not think about how to address this properly? >> > + /* Enable LTR and OBFF before do device assignment */ >> > + /* LTR(Latency tolerance reporting) allows devices to send >> > + * messages to the root complex indicating their latency tolerance >> > + * for snooped & unsnooped memory transactions. >> > + */ >> > + err = pci_enable_ltr(dev); >> > + if (err) >> > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); >> >> ... dev_err() here and below is certainly too severe, particularly for >> the -ENOTSUPP cases. And the spelling would need fixing, especially >> with it being broken exactly the same way a second time below. >> > > dev_alert should be ok. dev_alert() is even higher severity, whereas I was hinting towards lowering it (and perhaps being completely silent upon encountering -ENOTSUPP), i.e. dev_warn() or even dev_notice(), . > Thanks for the careful review of typo "enable", I'll > modify it in next version. Plus the one in "Could". Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:25:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07: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 ) id 1SRIJD-0007Cs-Va; Mon, 07 May 2012 07:24:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIJC-0007Cm-He for xen-devel@lists.xen.org; Mon, 07 May 2012 07:24:38 +0000 Received: from [85.158.143.99:28776] by server-3.bemta-4.messagelabs.com id E2/EE-05853-5B877AF4; Mon, 07 May 2012 07:24:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336375476!26766788!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16809 invoked from network); 7 May 2012 07:24:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 07:24:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:24:36 +0100 Message-Id: <4FA794D00200007800081F1E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:24:32 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 10:10, "Hao, Xudong" wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: >> I continue to disagree to doing this always, unconditionally, with >> hard-coded settings. If these features require explicit enabling, >> there likely is something that drivers unaware of them could have >> problems with - otherwise I would think these features would be >> always enabled when a device supports them, and no options >> would exist to control certain parameters. >> > I agree the driver control it, but it's difficult to let guest driver do it > till now(because of PCIe emulation by qemu issue). Then why not think about how to address this properly? >> > + /* Enable LTR and OBFF before do device assignment */ >> > + /* LTR(Latency tolerance reporting) allows devices to send >> > + * messages to the root complex indicating their latency tolerance >> > + * for snooped & unsnooped memory transactions. >> > + */ >> > + err = pci_enable_ltr(dev); >> > + if (err) >> > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); >> >> ... dev_err() here and below is certainly too severe, particularly for >> the -ENOTSUPP cases. And the spelling would need fixing, especially >> with it being broken exactly the same way a second time below. >> > > dev_alert should be ok. dev_alert() is even higher severity, whereas I was hinting towards lowering it (and perhaps being completely silent upon encountering -ENOTSUPP), i.e. dev_warn() or even dev_notice(), . > Thanks for the careful review of typo "enable", I'll > modify it in next version. Plus the one in "Could". Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:32:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIQP-0007NU-U8; Mon, 07 May 2012 07:32:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIQO-0007NP-0O for xen-devel@lists.xen.org; Mon, 07 May 2012 07:32:04 +0000 Received: from [85.158.143.99:50943] by server-3.bemta-4.messagelabs.com id B2/16-05853-37A77AF4; Mon, 07 May 2012 07:32:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336375921!17154972!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6736 invoked from network); 7 May 2012 07:32:02 -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; 7 May 2012 07:32:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:32:01 +0100 Message-Id: <4FA7968D0200007800081F2E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:31:57 +0100 From: "Jan Beulich" To: "Jinsong Liu" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "keir.xen@gmail.com" , xen-devel Subject: Re: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 14:13, "Liu, Jinsong" wrote: > Fix vmce addr/misc wrmsr bug > > This patch fix a bug related to wrmsr vmce bank addr/misc > registers, since they are not read-only. > > Intel SDM recommanded os mce driver clear bank status/addr/misc. > So guest mce driver may clear addr and misc registers. > Under such case, old vmce wrmsr logic would generate > a #GP fault at guest mce context, and make guest crash. > > Signed-off-by: Liu, Jinsong > > diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c > --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 > +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 > @@ -209,6 +209,14 @@ > struct domain_mca_msrs *vmce = dom_vmce(v->domain); > struct bank_entry *entry = NULL; > > + /* Give the first entry of the list, it corresponds to current > + * vMCE# injection. When vMCE# is finished processing by the > + * the guest, this node will be deleted. > + * Only error bank is written. Non-error banks simply return. > + */ > + if ( !list_empty(&vmce->impact_header) ) > + entry = list_entry(vmce->impact_header.next, struct bank_entry, list); > + > switch ( msr & (MSR_IA32_MC0_CTL | 3) ) > { > case MSR_IA32_MC0_CTL: > @@ -216,32 +224,28 @@ > vmce->mci_ctl[bank] = val; > break; > case MSR_IA32_MC0_STATUS: > - /* Give the first entry of the list, it corresponds to current > - * vMCE# injection. When vMCE# is finished processing by the > - * the guest, this node will be deleted. > - * Only error bank is written. Non-error banks simply return. > - */ > - if ( !list_empty(&vmce->impact_header) ) > + if ( entry && (entry->bank == bank) ) > { > - entry = list_entry(vmce->impact_header.next, > - struct bank_entry, list); > - if ( entry->bank == bank ) > - entry->mci_status = val; > + entry->mci_status = val; > mce_printk(MCE_VERBOSE, > - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", > - bank, val); > + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, val); > } > - else > - mce_printk(MCE_VERBOSE, > - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); Why do you delete this printk()? It'll be impossible to track down ignored guest writes, should those cause a problem in the guest. > break; > case MSR_IA32_MC0_ADDR: > - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); > - ret = -1; > + if ( entry && (entry->bank == bank) ) > + { > + entry->mci_addr = val; > + mce_printk(MCE_VERBOSE, > + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val); > + } The patch description talks only about clearing the register, yet you silently accept all writes here. Would real hardware accept writes of other than zero? Further, just as above, ignore writes won't be possible to track down. > break; > case MSR_IA32_MC0_MISC: > - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); > - ret = -1; > + if ( entry && (entry->bank == bank) ) > + { > + entry->mci_misc = val; > + mce_printk(MCE_VERBOSE, > + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val); > + } Same here in both respects. Jan > break; > default: > switch ( boot_cpu_data.x86_vendor ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:32:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIQP-0007NU-U8; Mon, 07 May 2012 07:32:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIQO-0007NP-0O for xen-devel@lists.xen.org; Mon, 07 May 2012 07:32:04 +0000 Received: from [85.158.143.99:50943] by server-3.bemta-4.messagelabs.com id B2/16-05853-37A77AF4; Mon, 07 May 2012 07:32:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336375921!17154972!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6736 invoked from network); 7 May 2012 07:32:02 -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; 7 May 2012 07:32:02 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 08:32:01 +0100 Message-Id: <4FA7968D0200007800081F2E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 08:31:57 +0100 From: "Jan Beulich" To: "Jinsong Liu" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "keir.xen@gmail.com" , xen-devel Subject: Re: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 14:13, "Liu, Jinsong" wrote: > Fix vmce addr/misc wrmsr bug > > This patch fix a bug related to wrmsr vmce bank addr/misc > registers, since they are not read-only. > > Intel SDM recommanded os mce driver clear bank status/addr/misc. > So guest mce driver may clear addr and misc registers. > Under such case, old vmce wrmsr logic would generate > a #GP fault at guest mce context, and make guest crash. > > Signed-off-by: Liu, Jinsong > > diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c > --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 > +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 > @@ -209,6 +209,14 @@ > struct domain_mca_msrs *vmce = dom_vmce(v->domain); > struct bank_entry *entry = NULL; > > + /* Give the first entry of the list, it corresponds to current > + * vMCE# injection. When vMCE# is finished processing by the > + * the guest, this node will be deleted. > + * Only error bank is written. Non-error banks simply return. > + */ > + if ( !list_empty(&vmce->impact_header) ) > + entry = list_entry(vmce->impact_header.next, struct bank_entry, list); > + > switch ( msr & (MSR_IA32_MC0_CTL | 3) ) > { > case MSR_IA32_MC0_CTL: > @@ -216,32 +224,28 @@ > vmce->mci_ctl[bank] = val; > break; > case MSR_IA32_MC0_STATUS: > - /* Give the first entry of the list, it corresponds to current > - * vMCE# injection. When vMCE# is finished processing by the > - * the guest, this node will be deleted. > - * Only error bank is written. Non-error banks simply return. > - */ > - if ( !list_empty(&vmce->impact_header) ) > + if ( entry && (entry->bank == bank) ) > { > - entry = list_entry(vmce->impact_header.next, > - struct bank_entry, list); > - if ( entry->bank == bank ) > - entry->mci_status = val; > + entry->mci_status = val; > mce_printk(MCE_VERBOSE, > - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", > - bank, val); > + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, val); > } > - else > - mce_printk(MCE_VERBOSE, > - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); Why do you delete this printk()? It'll be impossible to track down ignored guest writes, should those cause a problem in the guest. > break; > case MSR_IA32_MC0_ADDR: > - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); > - ret = -1; > + if ( entry && (entry->bank == bank) ) > + { > + entry->mci_addr = val; > + mce_printk(MCE_VERBOSE, > + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val); > + } The patch description talks only about clearing the register, yet you silently accept all writes here. Would real hardware accept writes of other than zero? Further, just as above, ignore writes won't be possible to track down. > break; > case MSR_IA32_MC0_MISC: > - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); > - ret = -1; > + if ( entry && (entry->bank == bank) ) > + { > + entry->mci_misc = val; > + mce_printk(MCE_VERBOSE, > + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val); > + } Same here in both respects. Jan > break; > default: > switch ( boot_cpu_data.x86_vendor ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:39:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:39:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIXd-0007aP-Up; Mon, 07 May 2012 07:39:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIXc-0007aK-Jn for xen-devel@lists.xen.org; Mon, 07 May 2012 07:39:32 +0000 Received: from [85.158.143.99:50966] by server-3.bemta-4.messagelabs.com id C3/0E-05853-33C77AF4; Mon, 07 May 2012 07:39:31 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336376370!23415302!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MTY0\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2538 invoked from network); 7 May 2012 07:39:30 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-216.messagelabs.com with SMTP; 7 May 2012 07:39:30 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 07 May 2012 00:39:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97120457" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 07 May 2012 00:39:29 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 00:39:29 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Mon, 7 May 2012 15:39:27 +0800 From: "Hao, Xudong" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//gGkA//xdGwCACE3zAP//eLSg Date: Mon, 7 May 2012 07:39:26 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDAE993@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> <4FA794D00200007800081F1E@nat28.tlf.novell.com> In-Reply-To: <4FA794D00200007800081F1E@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: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Monday, May 07, 2012 3:25 PM > To: Hao, Xudong > Cc: xen-devel; konrad.wilk@oracle.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 06.05.12 at 10:10, "Hao, Xudong" wrote: > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > >> I continue to disagree to doing this always, unconditionally, with > >> hard-coded settings. If these features require explicit enabling, > >> there likely is something that drivers unaware of them could have > >> problems with - otherwise I would think these features would be > >> always enabled when a device supports them, and no options > >> would exist to control certain parameters. > >> > > I agree the driver control it, but it's difficult to let guest driver do it > > till now(because of PCIe emulation by qemu issue). > > Then why not think about how to address this properly? > I means the patch is the most appropriate method now. When qemu can emulate PCIe, then we shall migrate the method to guest driver controlling. > >> > + /* Enable LTR and OBFF before do device assignment */ > >> > + /* LTR(Latency tolerance reporting) allows devices to send > >> > + * messages to the root complex indicating their latency tolerance > >> > + * for snooped & unsnooped memory transactions. > >> > + */ > >> > + err = pci_enable_ltr(dev); > >> > + if (err) > >> > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > >> > >> ... dev_err() here and below is certainly too severe, particularly for > >> the -ENOTSUPP cases. And the spelling would need fixing, especially > >> with it being broken exactly the same way a second time below. > >> > > > > dev_alert should be ok. > > dev_alert() is even higher severity, whereas I was hinting towards > lowering it (and perhaps being completely silent upon encountering > -ENOTSUPP), i.e. dev_warn() or even dev_notice(), . > > > Thanks for the careful review of typo "enable", I'll > > modify it in next version. > > Plus the one in "Could". > Thanks. > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 07:39:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 07:39:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIXd-0007aP-Up; Mon, 07 May 2012 07:39:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRIXc-0007aK-Jn for xen-devel@lists.xen.org; Mon, 07 May 2012 07:39:32 +0000 Received: from [85.158.143.99:50966] by server-3.bemta-4.messagelabs.com id C3/0E-05853-33C77AF4; Mon, 07 May 2012 07:39:31 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336376370!23415302!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MTY0\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2538 invoked from network); 7 May 2012 07:39:30 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-216.messagelabs.com with SMTP; 7 May 2012 07:39:30 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 07 May 2012 00:39:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97120457" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 07 May 2012 00:39:29 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 00:39:29 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.226]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.232]) with mapi id 14.01.0355.002; Mon, 7 May 2012 15:39:27 +0800 From: "Hao, Xudong" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//gGkA//xdGwCACE3zAP//eLSg Date: Mon, 7 May 2012 07:39:26 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDAE993@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <4FA3AA540200007800081840@nat28.tlf.novell.com> <403610A45A2B5242BD291EDAE8B37D300FDADF4E@SHSMSX102.ccr.corp.intel.com> <4FA794D00200007800081F1E@nat28.tlf.novell.com> In-Reply-To: <4FA794D00200007800081F1E@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: "konrad.wilk@oracle.com" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Monday, May 07, 2012 3:25 PM > To: Hao, Xudong > Cc: xen-devel; konrad.wilk@oracle.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 06.05.12 at 10:10, "Hao, Xudong" wrote: > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >>> On 04.05.12 at 09:49, "Hao, Xudong" wrote: > >> I continue to disagree to doing this always, unconditionally, with > >> hard-coded settings. If these features require explicit enabling, > >> there likely is something that drivers unaware of them could have > >> problems with - otherwise I would think these features would be > >> always enabled when a device supports them, and no options > >> would exist to control certain parameters. > >> > > I agree the driver control it, but it's difficult to let guest driver do it > > till now(because of PCIe emulation by qemu issue). > > Then why not think about how to address this properly? > I means the patch is the most appropriate method now. When qemu can emulate PCIe, then we shall migrate the method to guest driver controlling. > >> > + /* Enable LTR and OBFF before do device assignment */ > >> > + /* LTR(Latency tolerance reporting) allows devices to send > >> > + * messages to the root complex indicating their latency tolerance > >> > + * for snooped & unsnooped memory transactions. > >> > + */ > >> > + err = pci_enable_ltr(dev); > >> > + if (err) > >> > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > >> > >> ... dev_err() here and below is certainly too severe, particularly for > >> the -ENOTSUPP cases. And the spelling would need fixing, especially > >> with it being broken exactly the same way a second time below. > >> > > > > dev_alert should be ok. > > dev_alert() is even higher severity, whereas I was hinting towards > lowering it (and perhaps being completely silent upon encountering > -ENOTSUPP), i.e. dev_warn() or even dev_notice(), . > > > Thanks for the careful review of typo "enable", I'll > > modify it in next version. > > Plus the one in "Could". > Thanks. > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:11:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJ1r-0008Iv-8L; Mon, 07 May 2012 08:10:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJ1p-0008IZ-Ih for xen-devel@lists.xensource.com; Mon, 07 May 2012 08:10:45 +0000 Received: from [85.158.138.51:7848] by server-3.bemta-3.messagelabs.com id C7/F3-04048-48387AF4; Mon, 07 May 2012 08:10:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336378243!25637383!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16994 invoked from network); 7 May 2012 08:10:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 08:10:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:10:42 +0100 Message-Id: <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:10:39 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.05.12 at 02:21, AP wrote: > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming in through the 8259A. Something fundamentally fishy must be going on here, and I would suppose the code in question shouldn't even be reached for legacy vectors. Furthermore, calling dump_irqs() from the debugging code with desc->lock still held makes it impossible to get full output, as that function wants to lock all initialized IRQ descriptors. Jan > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 > mapped, unbound > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge status=00000030 > in-flight=0 domain-list=0: 1(-S--), > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 > mapped, unbound > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 > in-flight=0 domain-list=0: 8(-S--), > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level status=00000030 > in-flight=0 domain-list=0: 9(-S--), > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 > mapped, unbound > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > Let me know if you need any more info. > Thanks, > AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:11:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJ1r-0008Iv-8L; Mon, 07 May 2012 08:10:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJ1p-0008IZ-Ih for xen-devel@lists.xensource.com; Mon, 07 May 2012 08:10:45 +0000 Received: from [85.158.138.51:7848] by server-3.bemta-3.messagelabs.com id C7/F3-04048-48387AF4; Mon, 07 May 2012 08:10:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336378243!25637383!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16994 invoked from network); 7 May 2012 08:10:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 08:10:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:10:42 +0100 Message-Id: <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:10:39 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.05.12 at 02:21, AP wrote: > (XEN) *** IRQ BUG found *** > (XEN) CPU0 -Testing vector 236 from bitmap 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming in through the 8259A. Something fundamentally fishy must be going on here, and I would suppose the code in question shouldn't even be reached for legacy vectors. Furthermore, calling dump_irqs() from the debugging code with desc->lock still held makes it impossible to get full output, as that function wants to lock all initialized IRQ descriptors. Jan > 37,41,49,51,64,72,80,88,96,104,120,136,145,152,158,160,168,175,182,192,200,211 > (XEN) Guest interrupt information: > (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 > mapped, unbound > (XEN) IRQ: 1 affinity:01 vec:d3 type=IO-APIC-edge status=00000030 > in-flight=0 domain-list=0: 1(-S--), > (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 > mapped, unbound > (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 > in-flight=0 domain-list=0: 8(-S--), > (XEN) IRQ: 9 affinity:02 vec:25 type=IO-APIC-level status=00000030 > in-flight=0 domain-list=0: 9(-S--), > (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 > mapped, unbound > (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 > mapped, unbound > [ 5129.737147] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer > elapsed... blt ring idle [waiting on 1800652, at 1800652], missed IRQ? > > Let me know if you need any more info. > Thanks, > AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:19:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJAJ-0000U5-Ic; Mon, 07 May 2012 08:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJAI-0000Tq-21 for xen-devel@lists.xen.org; Mon, 07 May 2012 08:19:30 +0000 Received: from [193.109.254.147:46078] by server-3.bemta-14.messagelabs.com id 91/B1-23274-19587AF4; Mon, 07 May 2012 08:19:29 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336378768!2802750!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6497 invoked from network); 7 May 2012 08:19:28 -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; 7 May 2012 08:19:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:19:27 +0100 Message-Id: <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:19:23 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> <4FA41D83.2010809@citrix.com> In-Reply-To: <4FA41D83.2010809@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 20:18, David Vrabel wrote: > On 04/05/12 17:26, David Vrabel wrote: >> On 04/05/12 17:12, Jan Beulich wrote: >>>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>>> From: David Vrabel >>>> >>>> The dom0_max_vcpus command line option only allows the exact number of >>>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>>> but no more than the number physically present." >>>> >>>> Add min: and max: prefixes to the option to set a minimum number of >>>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>>> >>>> For example, with "dom0_max_vcpus=min:4,max:8": >>> >>> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >>> how about simply allowing a range along with a simple number (since >>> negative values make no sense, omitting either side of the range would >>> be supportable if necessary. >> >> I was copying the way dom0_mem worked but yeah, it's not very pretty. >> >> Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were >> thinking of? >> >> Using a single value would have to set both and or the >> behaviour of the option changes (i.e., =N is the same as =N-N). > > This is what I ended up with. > > 8<------------------------------ > From af1543965db76ab81139de7f072a7c4daf61157f Mon Sep 17 00:00:00 2001 > From: David Vrabel > Date: Fri, 4 May 2012 16:09:52 +0100 > Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible > > The dom0_max_vcpus command line option only allows the exact number of > VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs > but no more than the number physically present." > > Allow a range for the option to set a minimum number of VCPUs, and a > maximum which does not exceed the number of PCPUs. > > For example, with "dom0_max_vcpus=4-8": > > PCPUs Dom0 VCPUs > 2 4 > 4 4 > 6 6 > 8 8 > 10 8 > > Existing command lines with "dom0_max_vcpus=N" still work as before. > > Signed-off-by: David Vrabel Acked-by: Jan Beulich But I'm not sure whether this qualifies for going in for 4.2... Jan > --- > docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++-- > xen/arch/x86/domain_build.c | 43 +++++++++++++++++++++++++--------- > 2 files changed, 57 insertions(+), 15 deletions(-) > > diff --git a/docs/misc/xen-command-line.markdown > b/docs/misc/xen-command-line.markdown > index a6195f2..4e4f713 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -272,10 +272,33 @@ Specify the bit width of the DMA heap. > > ### dom0\_ioports\_disable > ### dom0\_max\_vcpus > -> `= ` > > -Specify the maximum number of vcpus to give to dom0. This defaults > -to the number of pcpus on the host. > +Either: > + > +> `= `. > + > +The number of VCPUs to give to dom0. This number of VCPUs can be more > +than the number of PCPUs on the host. The default is the number of > +PCPUs. > + > +Or: > + > +> `= -` where `` and `` are integers. > + > +Gives dom0 a number of VCPUs equal to the number of PCPUs, but always > +at least `` and no more than ``. Using `` may give > +more VCPUs than PCPUs. `` or `` may be omitted and the > +defaults of 1 and unlimited respectively are used instead. > + > +For example, with `dom0_max_vcpus=4-8`: > + > + Number of > + PCPUs | Dom0 VCPUs > + 2 | 4 > + 4 | 4 > + 6 | 6 > + 8 | 8 > + 10 | 8 > > ### dom0\_mem (ia64) > > `= ` > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c > index b3c5d4c..686b626 100644 > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s) > } > custom_param("dom0_mem", parse_dom0_mem); > > -static unsigned int __initdata opt_dom0_max_vcpus; > -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; > +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; > + > +static void __init parse_dom0_max_vcpus(const char *s) > +{ > + if (*s == '-') /* -M */ > + opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0); > + else { /* N, N-, or N-M */ > + opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0); > + if (*s++ == '\0') /* N */ > + opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min; > + else if (*s != '\0') /* N-M */ > + opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0); > + } > +} > +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); > > struct vcpu *__init alloc_dom0_vcpu0(void) > { > - if ( opt_dom0_max_vcpus == 0 ) > - opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); > - if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) > - opt_dom0_max_vcpus = MAX_VIRT_CPUS; > + unsigned max_vcpus; > + > + max_vcpus = num_cpupool_cpus(cpupool0); > + if ( opt_dom0_max_vcpus_min > max_vcpus ) > + max_vcpus = opt_dom0_max_vcpus_min; > + if ( opt_dom0_max_vcpus_max < max_vcpus ) > + max_vcpus = opt_dom0_max_vcpus_max; > + if ( max_vcpus > MAX_VIRT_CPUS ) > + max_vcpus = MAX_VIRT_CPUS; > > - dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); > + dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus); > if ( !dom0->vcpu ) > return NULL; > - dom0->max_vcpus = opt_dom0_max_vcpus; > + dom0->max_vcpus = max_vcpus; > > return alloc_vcpu(dom0, 0, 0); > } > @@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages( > unsigned long max_pages = dom0_max_nrpages; > > /* Reserve memory for further dom0 vcpu-struct allocations... */ > - avail -= (opt_dom0_max_vcpus - 1UL) > + avail -= (d->max_vcpus - 1UL) > << get_order_from_bytes(sizeof(struct vcpu)); > /* ...and compat_l4's, if needed. */ > if ( is_pv_32on64_domain(d) ) > - avail -= opt_dom0_max_vcpus - 1; > + avail -= d->max_vcpus - 1; > > /* Reserve memory for iommu_dom0_init() (rough estimate). */ > if ( iommu_enabled ) > @@ -883,10 +902,10 @@ int __init construct_dom0( > for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ ) > shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1; > > - printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus); > + printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus); > > cpu = cpumask_first(cpupool0->cpu_valid); > - for ( i = 1; i < opt_dom0_max_vcpus; i++ ) > + for ( i = 1; i < d->max_vcpus; i++ ) > { > cpu = cpumask_cycle(cpu, cpupool0->cpu_valid); > (void)alloc_vcpu(d, i, cpu); > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:19:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJAJ-0000U5-Ic; Mon, 07 May 2012 08:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJAI-0000Tq-21 for xen-devel@lists.xen.org; Mon, 07 May 2012 08:19:30 +0000 Received: from [193.109.254.147:46078] by server-3.bemta-14.messagelabs.com id 91/B1-23274-19587AF4; Mon, 07 May 2012 08:19:29 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336378768!2802750!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6497 invoked from network); 7 May 2012 08:19:28 -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; 7 May 2012 08:19:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:19:27 +0100 Message-Id: <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:19:23 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> <4FA41D83.2010809@citrix.com> In-Reply-To: <4FA41D83.2010809@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 20:18, David Vrabel wrote: > On 04/05/12 17:26, David Vrabel wrote: >> On 04/05/12 17:12, Jan Beulich wrote: >>>>>> On 04.05.12 at 18:01, David Vrabel wrote: >>>> From: David Vrabel >>>> >>>> The dom0_max_vcpus command line option only allows the exact number of >>>> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >>>> but no more than the number physically present." >>>> >>>> Add min: and max: prefixes to the option to set a minimum number of >>>> VCPUs, and a maximum which does not exceed the number of PCPUs. >>>> >>>> For example, with "dom0_max_vcpus=min:4,max:8": >>> >>> Both "...max...=min:..." and "...max...=max:" look pretty odd to me; >>> how about simply allowing a range along with a simple number (since >>> negative values make no sense, omitting either side of the range would >>> be supportable if necessary. >> >> I was copying the way dom0_mem worked but yeah, it's not very pretty. >> >> Is dom0_max_vcpus=- (e.g., dom0_max_vcpus=4-8) what you were >> thinking of? >> >> Using a single value would have to set both and or the >> behaviour of the option changes (i.e., =N is the same as =N-N). > > This is what I ended up with. > > 8<------------------------------ > From af1543965db76ab81139de7f072a7c4daf61157f Mon Sep 17 00:00:00 2001 > From: David Vrabel > Date: Fri, 4 May 2012 16:09:52 +0100 > Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible > > The dom0_max_vcpus command line option only allows the exact number of > VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs > but no more than the number physically present." > > Allow a range for the option to set a minimum number of VCPUs, and a > maximum which does not exceed the number of PCPUs. > > For example, with "dom0_max_vcpus=4-8": > > PCPUs Dom0 VCPUs > 2 4 > 4 4 > 6 6 > 8 8 > 10 8 > > Existing command lines with "dom0_max_vcpus=N" still work as before. > > Signed-off-by: David Vrabel Acked-by: Jan Beulich But I'm not sure whether this qualifies for going in for 4.2... Jan > --- > docs/misc/xen-command-line.markdown | 29 +++++++++++++++++++++-- > xen/arch/x86/domain_build.c | 43 +++++++++++++++++++++++++--------- > 2 files changed, 57 insertions(+), 15 deletions(-) > > diff --git a/docs/misc/xen-command-line.markdown > b/docs/misc/xen-command-line.markdown > index a6195f2..4e4f713 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -272,10 +272,33 @@ Specify the bit width of the DMA heap. > > ### dom0\_ioports\_disable > ### dom0\_max\_vcpus > -> `= ` > > -Specify the maximum number of vcpus to give to dom0. This defaults > -to the number of pcpus on the host. > +Either: > + > +> `= `. > + > +The number of VCPUs to give to dom0. This number of VCPUs can be more > +than the number of PCPUs on the host. The default is the number of > +PCPUs. > + > +Or: > + > +> `= -` where `` and `` are integers. > + > +Gives dom0 a number of VCPUs equal to the number of PCPUs, but always > +at least `` and no more than ``. Using `` may give > +more VCPUs than PCPUs. `` or `` may be omitted and the > +defaults of 1 and unlimited respectively are used instead. > + > +For example, with `dom0_max_vcpus=4-8`: > + > + Number of > + PCPUs | Dom0 VCPUs > + 2 | 4 > + 4 | 4 > + 6 | 6 > + 8 | 8 > + 10 | 8 > > ### dom0\_mem (ia64) > > `= ` > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c > index b3c5d4c..686b626 100644 > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s) > } > custom_param("dom0_mem", parse_dom0_mem); > > -static unsigned int __initdata opt_dom0_max_vcpus; > -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); > +static unsigned int __initdata opt_dom0_max_vcpus_min = 1; > +static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; > + > +static void __init parse_dom0_max_vcpus(const char *s) > +{ > + if (*s == '-') /* -M */ > + opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0); > + else { /* N, N-, or N-M */ > + opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0); > + if (*s++ == '\0') /* N */ > + opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min; > + else if (*s != '\0') /* N-M */ > + opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0); > + } > +} > +custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); > > struct vcpu *__init alloc_dom0_vcpu0(void) > { > - if ( opt_dom0_max_vcpus == 0 ) > - opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0); > - if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS ) > - opt_dom0_max_vcpus = MAX_VIRT_CPUS; > + unsigned max_vcpus; > + > + max_vcpus = num_cpupool_cpus(cpupool0); > + if ( opt_dom0_max_vcpus_min > max_vcpus ) > + max_vcpus = opt_dom0_max_vcpus_min; > + if ( opt_dom0_max_vcpus_max < max_vcpus ) > + max_vcpus = opt_dom0_max_vcpus_max; > + if ( max_vcpus > MAX_VIRT_CPUS ) > + max_vcpus = MAX_VIRT_CPUS; > > - dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus); > + dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus); > if ( !dom0->vcpu ) > return NULL; > - dom0->max_vcpus = opt_dom0_max_vcpus; > + dom0->max_vcpus = max_vcpus; > > return alloc_vcpu(dom0, 0, 0); > } > @@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages( > unsigned long max_pages = dom0_max_nrpages; > > /* Reserve memory for further dom0 vcpu-struct allocations... */ > - avail -= (opt_dom0_max_vcpus - 1UL) > + avail -= (d->max_vcpus - 1UL) > << get_order_from_bytes(sizeof(struct vcpu)); > /* ...and compat_l4's, if needed. */ > if ( is_pv_32on64_domain(d) ) > - avail -= opt_dom0_max_vcpus - 1; > + avail -= d->max_vcpus - 1; > > /* Reserve memory for iommu_dom0_init() (rough estimate). */ > if ( iommu_enabled ) > @@ -883,10 +902,10 @@ int __init construct_dom0( > for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ ) > shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1; > > - printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus); > + printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus); > > cpu = cpumask_first(cpupool0->cpu_valid); > - for ( i = 1; i < opt_dom0_max_vcpus; i++ ) > + for ( i = 1; i < d->max_vcpus; i++ ) > { > cpu = cpumask_cycle(cpu, cpupool0->cpu_valid); > (void)alloc_vcpu(d, i, cpu); > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:21:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJCG-0000j3-2p; Mon, 07 May 2012 08:21:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJCE-0000it-0n for xen-devel@lists.xen.org; Mon, 07 May 2012 08:21:30 +0000 Received: from [85.158.143.35:32236] by server-2.bemta-4.messagelabs.com id CA/E2-17550-90687AF4; Mon, 07 May 2012 08:21:29 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336378886!13068689!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MTY0\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 441 invoked from network); 7 May 2012 08:21:27 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-13.tower-21.messagelabs.com with SMTP; 7 May 2012 08:21:27 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 07 May 2012 01:21:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139707418" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 01:21:25 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 01:21:25 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Mon, 7 May 2012 16:21:22 +0800 From: "Liu, Jinsong" To: Jan Beulich Thread-Topic: [PATCH] Fix vmce addr/misc wrmsr bug Thread-Index: AQHNLCN7WdDs/9mcQ9qVPfKaVnNF8Za9+8cg Date: Mon, 7 May 2012 08:21:22 +0000 Message-ID: References: <4FA7968D0200007800081F2E@nat28.tlf.novell.com> In-Reply-To: <4FA7968D0200007800081F2E@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: "keir.xen@gmail.com" , xen-devel Subject: Re: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich wrote: >>>> On 06.05.12 at 14:13, "Liu, Jinsong" >>>> wrote: Fix vmce addr/misc wrmsr bug >> >> This patch fix a bug related to wrmsr vmce bank addr/misc >> registers, since they are not read-only. >> >> Intel SDM recommanded os mce driver clear bank status/addr/misc. >> So guest mce driver may clear addr and misc registers. >> Under such case, old vmce wrmsr logic would generate >> a #GP fault at guest mce context, and make guest crash. >> >> Signed-off-by: Liu, Jinsong >> >> diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c >> --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 >> +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 >> @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce = >> dom_vmce(v->domain); struct bank_entry *entry = NULL; >> >> + /* Give the first entry of the list, it corresponds to current >> + * vMCE# injection. When vMCE# is finished processing by the >> + * the guest, this node will be deleted. >> + * Only error bank is written. Non-error banks simply return. + >> */ + if ( !list_empty(&vmce->impact_header) ) >> + entry = list_entry(vmce->impact_header.next, struct >> bank_entry, list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) >> { >> case MSR_IA32_MC0_CTL: >> @@ -216,32 +224,28 @@ >> vmce->mci_ctl[bank] = val; >> break; >> case MSR_IA32_MC0_STATUS: >> - /* Give the first entry of the list, it corresponds to >> current >> - * vMCE# injection. When vMCE# is finished processing by the >> - * the guest, this node will be deleted. >> - * Only error bank is written. Non-error banks simply >> return. >> - */ >> - if ( !list_empty(&vmce->impact_header) ) >> + if ( entry && (entry->bank == bank) ) >> { >> - entry = list_entry(vmce->impact_header.next, >> - struct bank_entry, list); >> - if ( entry->bank == bank ) >> - entry->mci_status = val; >> + entry->mci_status = val; >> mce_printk(MCE_VERBOSE, >> - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", >> - bank, val); >> + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", >> bank, val); } >> - else >> - mce_printk(MCE_VERBOSE, >> - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, >> val); > > Why do you delete this printk()? It'll be impossible to track down > ignored guest writes, should those cause a problem in the guest. OK, will add printk. > >> break; >> case MSR_IA32_MC0_ADDR: >> - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", >> bank); >> - ret = -1; >> + if ( entry && (entry->bank == bank) ) >> + { >> + entry->mci_addr = val; >> + mce_printk(MCE_VERBOSE, >> + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", >> bank, val); + } > > The patch description talks only about clearing the register, yet you > silently accept all writes here. Would real hardware accept writes of > other than zero? Yes, except write all 1's would cause GP. Will add code to handle writing all 1's case. > > Further, just as above, ignore writes won't be possible to track down. > >> break; >> case MSR_IA32_MC0_MISC: >> - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", >> bank); >> - ret = -1; >> + if ( entry && (entry->bank == bank) ) >> + { >> + entry->mci_misc = val; >> + mce_printk(MCE_VERBOSE, >> + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", >> bank, val); + } > > Same here in both respects. Same as above. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:21:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJCG-0000j3-2p; Mon, 07 May 2012 08:21:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJCE-0000it-0n for xen-devel@lists.xen.org; Mon, 07 May 2012 08:21:30 +0000 Received: from [85.158.143.35:32236] by server-2.bemta-4.messagelabs.com id CA/E2-17550-90687AF4; Mon, 07 May 2012 08:21:29 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336378886!13068689!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc1MTY0\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 441 invoked from network); 7 May 2012 08:21:27 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-13.tower-21.messagelabs.com with SMTP; 7 May 2012 08:21:27 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 07 May 2012 01:21:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139707418" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 01:21:25 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 01:21:25 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Mon, 7 May 2012 16:21:22 +0800 From: "Liu, Jinsong" To: Jan Beulich Thread-Topic: [PATCH] Fix vmce addr/misc wrmsr bug Thread-Index: AQHNLCN7WdDs/9mcQ9qVPfKaVnNF8Za9+8cg Date: Mon, 7 May 2012 08:21:22 +0000 Message-ID: References: <4FA7968D0200007800081F2E@nat28.tlf.novell.com> In-Reply-To: <4FA7968D0200007800081F2E@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: "keir.xen@gmail.com" , xen-devel Subject: Re: [Xen-devel] [PATCH] Fix vmce addr/misc wrmsr bug X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich wrote: >>>> On 06.05.12 at 14:13, "Liu, Jinsong" >>>> wrote: Fix vmce addr/misc wrmsr bug >> >> This patch fix a bug related to wrmsr vmce bank addr/misc >> registers, since they are not read-only. >> >> Intel SDM recommanded os mce driver clear bank status/addr/misc. >> So guest mce driver may clear addr and misc registers. >> Under such case, old vmce wrmsr logic would generate >> a #GP fault at guest mce context, and make guest crash. >> >> Signed-off-by: Liu, Jinsong >> >> diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c >> --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 >> +++ b/xen/arch/x86/cpu/mcheck/vmce.c Sun May 06 03:05:20 2012 +0800 >> @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce = >> dom_vmce(v->domain); struct bank_entry *entry = NULL; >> >> + /* Give the first entry of the list, it corresponds to current >> + * vMCE# injection. When vMCE# is finished processing by the >> + * the guest, this node will be deleted. >> + * Only error bank is written. Non-error banks simply return. + >> */ + if ( !list_empty(&vmce->impact_header) ) >> + entry = list_entry(vmce->impact_header.next, struct >> bank_entry, list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) >> { >> case MSR_IA32_MC0_CTL: >> @@ -216,32 +224,28 @@ >> vmce->mci_ctl[bank] = val; >> break; >> case MSR_IA32_MC0_STATUS: >> - /* Give the first entry of the list, it corresponds to >> current >> - * vMCE# injection. When vMCE# is finished processing by the >> - * the guest, this node will be deleted. >> - * Only error bank is written. Non-error banks simply >> return. >> - */ >> - if ( !list_empty(&vmce->impact_header) ) >> + if ( entry && (entry->bank == bank) ) >> { >> - entry = list_entry(vmce->impact_header.next, >> - struct bank_entry, list); >> - if ( entry->bank == bank ) >> - entry->mci_status = val; >> + entry->mci_status = val; >> mce_printk(MCE_VERBOSE, >> - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", >> - bank, val); >> + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", >> bank, val); } >> - else >> - mce_printk(MCE_VERBOSE, >> - "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, >> val); > > Why do you delete this printk()? It'll be impossible to track down > ignored guest writes, should those cause a problem in the guest. OK, will add printk. > >> break; >> case MSR_IA32_MC0_ADDR: >> - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", >> bank); >> - ret = -1; >> + if ( entry && (entry->bank == bank) ) >> + { >> + entry->mci_addr = val; >> + mce_printk(MCE_VERBOSE, >> + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", >> bank, val); + } > > The patch description talks only about clearing the register, yet you > silently accept all writes here. Would real hardware accept writes of > other than zero? Yes, except write all 1's would cause GP. Will add code to handle writing all 1's case. > > Further, just as above, ignore writes won't be possible to track down. > >> break; >> case MSR_IA32_MC0_MISC: >> - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", >> bank); >> - ret = -1; >> + if ( entry && (entry->bank == bank) ) >> + { >> + entry->mci_misc = val; >> + mce_printk(MCE_VERBOSE, >> + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", >> bank, val); + } > > Same here in both respects. Same as above. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:25:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:25:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJFf-00013k-MC; Mon, 07 May 2012 08:25:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJFf-00013e-4z for xen-devel@lists.xen.org; Mon, 07 May 2012 08:25:03 +0000 Received: from [193.109.254.147:13772] by server-5.bemta-14.messagelabs.com id 50/23-30733-ED687AF4; Mon, 07 May 2012 08:25:02 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336379101!1134717!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1672 invoked from network); 7 May 2012 08:25:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 08:25:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:25:01 +0100 Message-Id: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:24:57 +0100 From: "Jan Beulich" To: "Daniel Castro" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 08:23, Daniel Castro wrote: > Hello List, > > I have a small problem with the ring when transferring blocks the id > on the response is different from the request. > This is the boot up read, count 0. > The guest requests block 0, it has to be located at 7c00. > > I go ahead and create a REQUEST with this data: > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > ring_req->id = 9; > ring_req->nr_segments=1; > ring_req->operation = BLKIF_OP_READ; > ring_req->sector_number = (int)op->lba; //sector to be read > ring_req->seg[0].gref = (bi->buffer_gref); //this should be get_free_gref(); > ring_req->seg[0].first_sect = 0;//op->lba; > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return notify=0 > if(notify){ > dprintf(1,"Start notify procedure\n"); > evtchn_send_t send; > send.port = (bi->port); > dprintf(1,"In notify before hypercall port is %d\n",send.port); > //hypercall_event_channel_op(EVTCHNOP_send, &send); > dprintf(1,"HYPERCALL read operation notify res %d\n", > hypercall_event_channel_op(EVTCHNOP_send,&send)); > } > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > Then I get: > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 > this is the line: > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > The id should be the same on both the request and response, there are > bi ither requests on the fly. > > Any clue?= With status happening to be 9 when id should be, is this perhaps a broken response structure definition? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:25:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:25:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJFf-00013k-MC; Mon, 07 May 2012 08:25:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJFf-00013e-4z for xen-devel@lists.xen.org; Mon, 07 May 2012 08:25:03 +0000 Received: from [193.109.254.147:13772] by server-5.bemta-14.messagelabs.com id 50/23-30733-ED687AF4; Mon, 07 May 2012 08:25:02 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336379101!1134717!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1672 invoked from network); 7 May 2012 08:25:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 08:25:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:25:01 +0100 Message-Id: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:24:57 +0100 From: "Jan Beulich" To: "Daniel Castro" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 08:23, Daniel Castro wrote: > Hello List, > > I have a small problem with the ring when transferring blocks the id > on the response is different from the request. > This is the boot up read, count 0. > The guest requests block 0, it has to be located at 7c00. > > I go ahead and create a REQUEST with this data: > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > ring_req->id = 9; > ring_req->nr_segments=1; > ring_req->operation = BLKIF_OP_READ; > ring_req->sector_number = (int)op->lba; //sector to be read > ring_req->seg[0].gref = (bi->buffer_gref); //this should be get_free_gref(); > ring_req->seg[0].first_sect = 0;//op->lba; > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return notify=0 > if(notify){ > dprintf(1,"Start notify procedure\n"); > evtchn_send_t send; > send.port = (bi->port); > dprintf(1,"In notify before hypercall port is %d\n",send.port); > //hypercall_event_channel_op(EVTCHNOP_send, &send); > dprintf(1,"HYPERCALL read operation notify res %d\n", > hypercall_event_channel_op(EVTCHNOP_send,&send)); > } > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > Then I get: > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 > this is the line: > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > The id should be the same on both the request and response, there are > bi ither requests on the fly. > > Any clue?= With status happening to be 9 when id should be, is this perhaps a broken response structure definition? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:31:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJM5-0001Lj-ID; Mon, 07 May 2012 08:31:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJM3-0001Lc-LK for xen-devel@lists.xen.org; Mon, 07 May 2012 08:31:39 +0000 Received: from [85.158.143.99:2700] by server-3.bemta-4.messagelabs.com id 38/07-05853-B6887AF4; Mon, 07 May 2012 08:31:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336379498!20410502!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15604 invoked from network); 7 May 2012 08:31:38 -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; 7 May 2012 08:31:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:31:37 +0100 Message-Id: <4FA7A4860200007800081F95@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:31:34 +0100 From: "Jan Beulich" To: "Yaqub Alwan" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] "UEFI firmware, Xen not detecting e820 map" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 17:11, Yaqub Alwan wrote: > I was in the ##xen freenode channel seeking help for an issue with memory > being unrecognised above 512mb, and iommu not being detected using xen > 4.1.2. The guys there determined that xen was not recognising my system > e820 map and using only the e801 map, and recommended I emailed the details > to this list. I appreciate that this list is not for technical queries, so > I do not expect any help, but write this to enable xen developers to > troubleshoot the issue for future patches. > > My system is a Supermicro X9SCV-Q with 16GB of installed memory and a > 2720QM CPU. The motherboard, as far as I am aware, only supports EFI > booting (I have a query with the manufacturer to find out if it supports > legacy boot). > Xen hypervisor only detects 511MB memory, but If I boot the regular linux > kernel, I get the full 16GB. > > Please find the output from xm dmesg here: http://pastebin.com/a1LC2csr > > Please find the output from normal linux boot dmesg here: > http://pastebin.com/CjePrLkx > > You can see that native Linux kernel is finding the e820 memory map, but > xen only sees e801 map. The Linux boot you looked at is an EFI one, so in order to do a proper comparison you should look at Xen booting from EFI too, without any intermediate boot loader involved (which requires that you use -unstable or a 4.1.x code base that backports the native EFI boot support, e.g. SLE11 SP2). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:31:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJM5-0001Lj-ID; Mon, 07 May 2012 08:31:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJM3-0001Lc-LK for xen-devel@lists.xen.org; Mon, 07 May 2012 08:31:39 +0000 Received: from [85.158.143.99:2700] by server-3.bemta-4.messagelabs.com id 38/07-05853-B6887AF4; Mon, 07 May 2012 08:31:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336379498!20410502!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15604 invoked from network); 7 May 2012 08:31:38 -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; 7 May 2012 08:31:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 09:31:37 +0100 Message-Id: <4FA7A4860200007800081F95@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 09:31:34 +0100 From: "Jan Beulich" To: "Yaqub Alwan" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] "UEFI firmware, Xen not detecting e820 map" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 06.05.12 at 17:11, Yaqub Alwan wrote: > I was in the ##xen freenode channel seeking help for an issue with memory > being unrecognised above 512mb, and iommu not being detected using xen > 4.1.2. The guys there determined that xen was not recognising my system > e820 map and using only the e801 map, and recommended I emailed the details > to this list. I appreciate that this list is not for technical queries, so > I do not expect any help, but write this to enable xen developers to > troubleshoot the issue for future patches. > > My system is a Supermicro X9SCV-Q with 16GB of installed memory and a > 2720QM CPU. The motherboard, as far as I am aware, only supports EFI > booting (I have a query with the manufacturer to find out if it supports > legacy boot). > Xen hypervisor only detects 511MB memory, but If I boot the regular linux > kernel, I get the full 16GB. > > Please find the output from xm dmesg here: http://pastebin.com/a1LC2csr > > Please find the output from normal linux boot dmesg here: > http://pastebin.com/CjePrLkx > > You can see that native Linux kernel is finding the e820 memory map, but > xen only sees e801 map. The Linux boot you looked at is an EFI one, so in order to do a proper comparison you should look at Xen booting from EFI too, without any intermediate boot loader involved (which requires that you use -unstable or a 4.1.x code base that backports the native EFI boot support, e.g. SLE11 SP2). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:41:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJVR-0001bm-Un; Mon, 07 May 2012 08:41:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJVR-0001bh-4l for xen-devel@lists.xen.org; Mon, 07 May 2012 08:41:21 +0000 Received: from [193.109.254.147:14068] by server-11.bemta-14.messagelabs.com id 77/8B-05858-0BA87AF4; Mon, 07 May 2012 08:41:20 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-7.tower-27.messagelabs.com!1336380076!275589!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 564 invoked from network); 7 May 2012 08:41:19 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 08:41:19 -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 ) id 1SRJVE-0002HP-RU; Mon, 07 May 2012 18:41:08 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 18:41:08 +1000 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi; Mon, 7 May 2012 18:41:08 +1000 From: James Harper To: Jan Beulich , Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DA= Date: Mon, 7 May 2012 08:41:06 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> In-Reply-To: <4FA7A2F90200007800081F7F@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: 07 May 2012 08:41:08.0838 (UTC) FILETIME=[261FC860:01CD2C2D] X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > >>> On 07.05.12 at 08:23, Daniel Castro wrote: > > Hello List, > > > > I have a small problem with the ring when transferring blocks the id > > on the response is different from the request. > > This is the boot up read, count 0. > > The guest requests block 0, it has to be located at 7c00. > > > > I go ahead and create a REQUEST with this data: > > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > > ring_req->id = 9; > > ring_req->nr_segments=1; > > ring_req->operation = BLKIF_OP_READ; > > ring_req->sector_number = (int)op->lba; //sector to be read > > ring_req->seg[0].gref = (bi->buffer_gref); //this should be > > get_free_gref(); ring_req->seg[0].first_sect = 0;//op->lba; > > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return > notify=0 > > if(notify){ > > dprintf(1,"Start notify procedure\n"); > > evtchn_send_t send; > > send.port = (bi->port); > > dprintf(1,"In notify before hypercall port is %d\n",send.port); > > //hypercall_event_channel_op(EVTCHNOP_send, &send); > > dprintf(1,"HYPERCALL read operation notify res %d\n", > > hypercall_event_channel_op(EVTCHNOP_send,&send)); > > } > > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > > Then I get: > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 > > this is the line: > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > > > > The id should be the same on both the request and response, there are > > bi ither requests on the fly. > > > > Any clue?= > > With status happening to be 9 when id should be, is this perhaps a broken > response structure definition? > That would be my guess too. The structure aligns differently under 64 and 32 bits so I'd guess the OP is talking between the two. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:41:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJVR-0001bm-Un; Mon, 07 May 2012 08:41:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJVR-0001bh-4l for xen-devel@lists.xen.org; Mon, 07 May 2012 08:41:21 +0000 Received: from [193.109.254.147:14068] by server-11.bemta-14.messagelabs.com id 77/8B-05858-0BA87AF4; Mon, 07 May 2012 08:41:20 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-7.tower-27.messagelabs.com!1336380076!275589!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 564 invoked from network); 7 May 2012 08:41:19 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 08:41:19 -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 ) id 1SRJVE-0002HP-RU; Mon, 07 May 2012 18:41:08 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 18:41:08 +1000 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi; Mon, 7 May 2012 18:41:08 +1000 From: James Harper To: Jan Beulich , Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DA= Date: Mon, 7 May 2012 08:41:06 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> In-Reply-To: <4FA7A2F90200007800081F7F@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: 07 May 2012 08:41:08.0838 (UTC) FILETIME=[261FC860:01CD2C2D] X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > >>> On 07.05.12 at 08:23, Daniel Castro wrote: > > Hello List, > > > > I have a small problem with the ring when transferring blocks the id > > on the response is different from the request. > > This is the boot up read, count 0. > > The guest requests block 0, it has to be located at 7c00. > > > > I go ahead and create a REQUEST with this data: > > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > > ring_req->id = 9; > > ring_req->nr_segments=1; > > ring_req->operation = BLKIF_OP_READ; > > ring_req->sector_number = (int)op->lba; //sector to be read > > ring_req->seg[0].gref = (bi->buffer_gref); //this should be > > get_free_gref(); ring_req->seg[0].first_sect = 0;//op->lba; > > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return > notify=0 > > if(notify){ > > dprintf(1,"Start notify procedure\n"); > > evtchn_send_t send; > > send.port = (bi->port); > > dprintf(1,"In notify before hypercall port is %d\n",send.port); > > //hypercall_event_channel_op(EVTCHNOP_send, &send); > > dprintf(1,"HYPERCALL read operation notify res %d\n", > > hypercall_event_channel_op(EVTCHNOP_send,&send)); > > } > > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > > Then I get: > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 > > this is the line: > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > > > > The id should be the same on both the request and response, there are > > bi ither requests on the fly. > > > > Any clue?= > > With status happening to be 9 when id should be, is this perhaps a broken > response structure definition? > That would be my guess too. The structure aligns differently under 64 and 32 bits so I'd guess the OP is talking between the two. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:53:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJhJ-0001xN-PN; Mon, 07 May 2012 08:53:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJhH-0001xF-MU for xen-devel@lists.xen.org; Mon, 07 May 2012 08:53:35 +0000 Received: from [85.158.138.51:21695] by server-10.bemta-3.messagelabs.com id B8/9F-29478-E8D87AF4; Mon, 07 May 2012 08:53:34 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-11.tower-174.messagelabs.com!1336380810!25612096!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16241 invoked from network); 7 May 2012 08:53:33 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 08:53:33 -0000 Received: from mail.bendigoit.com.au ([203.16.207.99]) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from ) id 1SRJh9-0002KK-Vy; Mon, 07 May 2012 18:53:28 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 18:53:28 +1000 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi; Mon, 7 May 2012 18:53:28 +1000 From: James Harper To: James Harper , Jan Beulich , Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DCAAAKHAA== Date: Mon, 7 May 2012 08:53:23 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFB73E8@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 May 2012 08:53:28.0017 (UTC) FILETIME=[DEB58C10:01CD2C2E] X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > > >>> On 07.05.12 at 08:23, Daniel Castro wrote: > > > Hello List, > > > > > > I have a small problem with the ring when transferring blocks the id > > > on the response is different from the request. > > > This is the boot up read, count 0. > > > The guest requests block 0, it has to be located at 7c00. > > > > > > I go ahead and create a REQUEST with this data: > > > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > > > ring_req->id = 9; > > > ring_req->nr_segments=1; > > > ring_req->operation = BLKIF_OP_READ; ring_req->sector_number = > > > (int)op->lba; //sector to be read ring_req->seg[0].gref = > > > (bi->buffer_gref); //this should be get_free_gref(); > > > ring_req->seg[0].first_sect = 0;//op->lba; > > > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > > > > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return > > notify=0 > > > if(notify){ > > > dprintf(1,"Start notify procedure\n"); > > > evtchn_send_t send; > > > send.port = (bi->port); > > > dprintf(1,"In notify before hypercall port is %d\n",send.port); > > > //hypercall_event_channel_op(EVTCHNOP_send, &send); > > > dprintf(1,"HYPERCALL read operation notify res %d\n", > > > hypercall_event_channel_op(EVTCHNOP_send,&send)); > > > } > > > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > > > Then I get: > > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is > > > the line: > > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > > > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > > > > > > > The id should be the same on both the request and response, there > > > are bi ither requests on the fly. > > > > > > Any clue?= > > > > With status happening to be 9 when id should be, is this perhaps a > > broken response structure definition? > > > > That would be my guess too. The structure aligns differently under 64 and 32 > bits so I'd guess the OP is talking between the two. > Further to this, Dom0 sets the "protocol" entry in the frontend xenstore (/local/domain//device/vbd//protocol) to tell it what alignment it is using. I wrote GPLPV before this setting existed so I solved the problem by sending 2 invalid requests down the ring and checking the response. If the fields have shifted around I assume that dom0 is not the same bit width as the domu and switch structure definitions on the fly. Are you writing a new frontend driver? James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:53:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 08: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 ) id 1SRJhJ-0001xN-PN; Mon, 07 May 2012 08:53:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJhH-0001xF-MU for xen-devel@lists.xen.org; Mon, 07 May 2012 08:53:35 +0000 Received: from [85.158.138.51:21695] by server-10.bemta-3.messagelabs.com id B8/9F-29478-E8D87AF4; Mon, 07 May 2012 08:53:34 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-11.tower-174.messagelabs.com!1336380810!25612096!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16241 invoked from network); 7 May 2012 08:53:33 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 08:53:33 -0000 Received: from mail.bendigoit.com.au ([203.16.207.99]) by smtp1.bendigoit.com.au with esmtp (Exim 4.69) (envelope-from ) id 1SRJh9-0002KK-Vy; Mon, 07 May 2012 18:53:28 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 18:53:28 +1000 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi; Mon, 7 May 2012 18:53:28 +1000 From: James Harper To: James Harper , Jan Beulich , Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DCAAAKHAA== Date: Mon, 7 May 2012 08:53:23 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFB73E8@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 May 2012 08:53:28.0017 (UTC) FILETIME=[DEB58C10:01CD2C2E] X-Really-From-Bendigo-IT: magichashvalue Cc: xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > > >>> On 07.05.12 at 08:23, Daniel Castro wrote: > > > Hello List, > > > > > > I have a small problem with the ring when transferring blocks the id > > > on the response is different from the request. > > > This is the boot up read, count 0. > > > The guest requests block 0, it has to be located at 7c00. > > > > > > I go ahead and create a REQUEST with this data: > > > ring_req = RING_GET_REQUEST(priv,priv->req_prod_pvt); > > > ring_req->id = 9; > > > ring_req->nr_segments=1; > > > ring_req->operation = BLKIF_OP_READ; ring_req->sector_number = > > > (int)op->lba; //sector to be read ring_req->seg[0].gref = > > > (bi->buffer_gref); //this should be get_free_gref(); > > > ring_req->seg[0].first_sect = 0;//op->lba; > > > ring_req->seg[0].last_sect = 7;//op->lba + op->count; > > > > > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); //return > > notify=0 > > > if(notify){ > > > dprintf(1,"Start notify procedure\n"); > > > evtchn_send_t send; > > > send.port = (bi->port); > > > dprintf(1,"In notify before hypercall port is %d\n",send.port); > > > //hypercall_event_channel_op(EVTCHNOP_send, &send); > > > dprintf(1,"HYPERCALL read operation notify res %d\n", > > > hypercall_event_channel_op(EVTCHNOP_send,&send)); > > > } > > > ring_res = RING_GET_RESPONSE((priv),(temp->rsp_prod)); > > > Then I get: > > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is > > > the line: > > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", > > > ring_res,ring_res->id,ring_res->status,ring_res->operation); > > > > > > > > > The id should be the same on both the request and response, there > > > are bi ither requests on the fly. > > > > > > Any clue?= > > > > With status happening to be 9 when id should be, is this perhaps a > > broken response structure definition? > > > > That would be my guess too. The structure aligns differently under 64 and 32 > bits so I'd guess the OP is talking between the two. > Further to this, Dom0 sets the "protocol" entry in the frontend xenstore (/local/domain//device/vbd//protocol) to tell it what alignment it is using. I wrote GPLPV before this setting existed so I solved the problem by sending 2 invalid requests down the ring and checking the response. If the fields have shifted around I assume that dom0 is not the same bit width as the domu and switch structure definitions on the fly. Are you writing a new frontend driver? James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRJlD-00028H-Fc; Mon, 07 May 2012 08:57:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJlB-000289-V0 for xen-devel@lists.xen.org; Mon, 07 May 2012 08:57:38 +0000 Received: from [85.158.143.99:36328] by server-3.bemta-4.messagelabs.com id 6C/B3-05853-18E87AF4; Mon, 07 May 2012 08:57:37 +0000 X-Env-Sender: yongjie.ren@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336381054!21481035!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMTQ4\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28426 invoked from network); 7 May 2012 08:57:35 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-216.messagelabs.com with SMTP; 7 May 2012 08:57:35 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 07 May 2012 01:57:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139721554" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 01:57:32 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 01:57:32 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Mon, 7 May 2012 16:57:15 +0800 From: "Ren, Yongjie" To: Jan Beulich , "Wu, GabrielX" Thread-Topic: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKemuJsb0jMTM1kmo0tMgmN2cyJa+AjQw Date: Mon, 7 May 2012 08:57:14 +0000 Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100AD9DA@SHSMSX101.ccr.corp.intel.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <4FA3DA1302000078000819D6@nat28.tlf.novell.com> In-Reply-To: <4FA3DA1302000078000819D6@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.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich > Sent: Friday, May 04, 2012 7:31 PM > To: Wu, GabrielX > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... > > >>> On 04.05.12 at 12:06, "Wu, GabrielX" > wrote: > > 6. when detaching a VF from hvm guest, "xl dmesg" will show some > warning > > information > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 > > Are you sure you still see those messages? Original separate testing > of the patch before it went in confirmed they were gone. > Sorry, your patch is already in qemu-xen-unstable tree and the bug has been fixed. And, just marked it as verified in the bugzilla. -Jay > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 08:57:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRJlD-00028H-Fc; Mon, 07 May 2012 08:57:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRJlB-000289-V0 for xen-devel@lists.xen.org; Mon, 07 May 2012 08:57:38 +0000 Received: from [85.158.143.99:36328] by server-3.bemta-4.messagelabs.com id 6C/B3-05853-18E87AF4; Mon, 07 May 2012 08:57:37 +0000 X-Env-Sender: yongjie.ren@intel.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336381054!21481035!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMTQ4\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28426 invoked from network); 7 May 2012 08:57:35 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-216.messagelabs.com with SMTP; 7 May 2012 08:57:35 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 07 May 2012 01:57:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139721554" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 01:57:32 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 01:57:32 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.243]) with mapi id 14.01.0355.002; Mon, 7 May 2012 16:57:15 +0800 From: "Ren, Yongjie" To: Jan Beulich , "Wu, GabrielX" Thread-Topic: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKemuJsb0jMTM1kmo0tMgmN2cyJa+AjQw Date: Mon, 7 May 2012 08:57:14 +0000 Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100AD9DA@SHSMSX101.ccr.corp.intel.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <4FA3DA1302000078000819D6@nat28.tlf.novell.com> In-Reply-To: <4FA3DA1302000078000819D6@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.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich > Sent: Friday, May 04, 2012 7:31 PM > To: Wu, GabrielX > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... > > >>> On 04.05.12 at 12:06, "Wu, GabrielX" > wrote: > > 6. when detaching a VF from hvm guest, "xl dmesg" will show some > warning > > information > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 > > Are you sure you still see those messages? Original separate testing > of the patch before it went in confirmed they were gone. > Sorry, your patch is already in qemu-xen-unstable tree and the bug has been fixed. And, just marked it as verified in the bugzilla. -Jay > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 11:20:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:20:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRLyq-0003t3-Bh; Mon, 07 May 2012 11:19:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRLyo-0003sy-LL for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:19:50 +0000 Received: from [85.158.143.35:49749] by server-2.bemta-4.messagelabs.com id 95/41-17550-5DFA7AF4; Mon, 07 May 2012 11:19:49 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336389587!12936266!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMjY1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30834 invoked from network); 7 May 2012 11:19:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-21.messagelabs.com with SMTP; 7 May 2012 11:19:48 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 07 May 2012 04:19:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139764071" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 04:19:30 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 04:19:29 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.226]) with mapi id 14.01.0355.002; Mon, 7 May 2012 19:19:27 +0800 From: "Liu, Jinsong" To: Jan Beulich , "keir.xen@gmail.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH] Fix vmce MCi_ADDR/MCi_MISC wrmsr bug (v2) Thread-Index: Ac0sQ0OvBC9EpOIaTL+A4EwGPh/oBA== Date: Mon, 7 May 2012 11:19:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_" MIME-Version: 1.0 Subject: [Xen-devel] [PATCH] Fix vmce MCi_ADDR/MCi_MISC wrmsr bug (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fix vmce MCi_ADDR/MCi_MISC wrmsr bug This patch fix a bug related to wrmsr vmce MCi_ADDR/MCi_MISC registers, since they are not read-only. Intel SDM recommanded os mce driver clear MCi_ADDR/MCi_MISC So guest mce driver may clear MCi_ADDR/MCi_MISC registers. Under such case, old vmce wrmsr logic would generate a #GP fault at guest mce context, and make guest crash. When wrmsr MCi_ADDR/MCi_MISC, writing 1s will cause #GP. Signed-off-by: Liu, Jinsong diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 +++ b/xen/arch/x86/cpu/mcheck/vmce.c Tue May 08 03:02:50 2012 +0800 @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce =3D dom_vmce(v->domain); struct bank_entry *entry =3D NULL; =20 + /* Give the first entry of the list, it corresponds to current + * vMCE# injection. When vMCE# is finished processing by the + * the guest, this node will be deleted. + * Only error bank is written. Non-error banks simply return. + */ + if ( !list_empty(&vmce->impact_header) ) + entry =3D list_entry(vmce->impact_header.next, struct bank_entry, = list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) { case MSR_IA32_MC0_CTL: @@ -216,32 +224,53 @@ vmce->mci_ctl[bank] =3D val; break; case MSR_IA32_MC0_STATUS: - /* Give the first entry of the list, it corresponds to current - * vMCE# injection. When vMCE# is finished processing by the - * the guest, this node will be deleted. - * Only error bank is written. Non-error banks simply return. - */ - if ( !list_empty(&vmce->impact_header) ) + if ( entry && (entry->bank =3D=3D bank) ) { - entry =3D list_entry(vmce->impact_header.next, - struct bank_entry, list); - if ( entry->bank =3D=3D bank ) - entry->mci_status =3D val; + entry->mci_status =3D val; mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", - bank, val); + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, v= al); } else mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_ADDR: - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); - ret =3D -1; + if ( val =3D=3D ~0 ) + { + mce_printk(MCE_QUIET, + "MCE: wr MC%u_ADDR with 1s will cause #GP\n", bank)= ; + ret =3D -1; + break; + } + + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_addr =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val= ); + } + else + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_MISC: - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); - ret =3D -1; + if ( val =3D=3D ~0 ) + { + mce_printk(MCE_QUIET, + "MCE: wr MC%u_MISC with 1s will cause #GP\n", bank)= ; + ret =3D -1; + break; + } + + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_misc =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val= ); + } + else + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val); break; default: switch ( boot_cpu_data.x86_vendor )= --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="vmce-bug-fix.patch" Content-Description: vmce-bug-fix.patch Content-Disposition: attachment; filename="vmce-bug-fix.patch"; size=3769; creation-date="Mon, 07 May 2012 11:15:40 GMT"; modification-date="Mon, 07 May 2012 19:09:06 GMT" Content-Transfer-Encoding: base64 Rml4IHZtY2UgTUNpX0FERFIvTUNpX01JU0Mgd3Jtc3IgYnVnCgpUaGlzIHBhdGNoIGZpeCBhIGJ1 ZyByZWxhdGVkIHRvIHdybXNyIHZtY2UgTUNpX0FERFIvTUNpX01JU0MKcmVnaXN0ZXJzLCBzaW5j ZSB0aGV5IGFyZSBub3QgcmVhZC1vbmx5LgoKSW50ZWwgU0RNIHJlY29tbWFuZGVkIG9zIG1jZSBk cml2ZXIgY2xlYXIgTUNpX0FERFIvTUNpX01JU0MKU28gZ3Vlc3QgbWNlIGRyaXZlciBtYXkgY2xl YXIgTUNpX0FERFIvTUNpX01JU0MgcmVnaXN0ZXJzLgpVbmRlciBzdWNoIGNhc2UsIG9sZCB2bWNl IHdybXNyIGxvZ2ljIHdvdWxkIGdlbmVyYXRlCmEgI0dQIGZhdWx0IGF0IGd1ZXN0IG1jZSBjb250 ZXh0LCBhbmQgbWFrZSBndWVzdCBjcmFzaC4KCldoZW4gd3Jtc3IgTUNpX0FERFIvTUNpX01JU0Ms IHdyaXRpbmcgMXMgd2lsbCBjYXVzZSAjR1AuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg PGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgNzU1ZjQ0MGIzYjc4IHhlbi9hcmNoL3g4 Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJ V2VkIEFwciAxOCAxODozMzozNiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNo ZWNrL3ZtY2UuYwlUdWUgTWF5IDA4IDAzOjAyOjUwIDIwMTIgKzA4MDAKQEAgLTIwOSw2ICsyMDks MTQgQEAKICAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNlID0gZG9tX3ZtY2Uodi0+ZG9t YWluKTsKICAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnkgPSBOVUxMOwogCisgICAgLyogR2l2 ZSB0aGUgZmlyc3QgZW50cnkgb2YgdGhlIGxpc3QsIGl0IGNvcnJlc3BvbmRzIHRvIGN1cnJlbnQK KyAgICAgKiB2TUNFIyBpbmplY3Rpb24uIFdoZW4gdk1DRSMgaXMgZmluaXNoZWQgcHJvY2Vzc2lu ZyBieSB0aGUKKyAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3aWxsIGJlIGRlbGV0ZWQuCisg ICAgICogT25seSBlcnJvciBiYW5rIGlzIHdyaXR0ZW4uIE5vbi1lcnJvciBiYW5rcyBzaW1wbHkg cmV0dXJuLgorICAgICAqLworICAgIGlmICggIWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFk ZXIpICkKKyAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZtY2UtPmltcGFjdF9oZWFkZXIubmV4 dCwgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOworCiAgICAgc3dpdGNoICggbXNyICYgKE1TUl9J QTMyX01DMF9DVEwgfCAzKSApCiAgICAgewogICAgIGNhc2UgTVNSX0lBMzJfTUMwX0NUTDoKQEAg LTIxNiwzMiArMjI0LDUzIEBACiAgICAgICAgICAgICB2bWNlLT5tY2lfY3RsW2JhbmtdID0gdmFs OwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAgICAg IC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3JyZXNwb25kcyB0byBj dXJyZW50Ci0gICAgICAgICAqIHZNQ0UjIGluamVjdGlvbi4gV2hlbiB2TUNFIyBpcyBmaW5pc2hl ZCBwcm9jZXNzaW5nIGJ5IHRoZQotICAgICAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3aWxs IGJlIGRlbGV0ZWQuCi0gICAgICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0dGVuLiBOb24t ZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KLSAgICAgICAgICovCi0gICAgICAgIGlmICggIWxp c3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYgKCBlbnRyeSAmJiAo ZW50cnktPmJhbmsgPT0gYmFuaykgKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeSA9IGxp c3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlmICggZW50 cnktPmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSB2 YWw7CisgICAgICAgICAgICBlbnRyeS0+bWNpX3N0YXR1cyA9IHZhbDsKICAgICAgICAgICAgIG1j ZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1D JXVfU1RBVFVTICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg YmFuaywgdmFsKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9TVEFUVVMg JSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOwogICAgICAgICB9CiAgICAgICAgIGVs c2UKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCiAgICAgICAgICAgICAgICAg ICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKICAg ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgbWNlX3By aW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1DJXVfQUREUiBpcyByZWFkLW9ubHlcbiIsIGJhbmspOwot ICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgaWYgKCB2YWwgPT0gfjAgKQorICAgICAgICB7Cisg ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKKyAgICAgICAgICAgICAgICAgICAgICAg Ik1DRTogd3IgTUMldV9BRERSIHdpdGggMXMgd2lsbCBjYXVzZSAjR1BcbiIsIGJhbmspOworICAg ICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorCisgICAg ICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5rID09IGJhbmspICkKKyAgICAgICAgeworICAg ICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOworICAgICAgICAgICAgbWNlX3ByaW50ayhN Q0VfVkVSQk9TRSwKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9BRERSICUi UFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQorICAgICAgICBlbHNl CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAorICAgICAgICAgICAgICAgICAg ICAgICAiTUNFOiB3ciBNQyV1X0FERFIgJSJQUkl4NjQiXG4iLCBiYW5rLCB2YWwpOwogICAgICAg ICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBtY2VfcHJpbnRr KE1DRV9RVUlFVCwgIk1DRTogTUMldV9NSVNDIGlzIHJlYWQtb25seVxuIiwgYmFuayk7Ci0gICAg ICAgIHJldCA9IC0xOworICAgICAgICBpZiAoIHZhbCA9PSB+MCApCisgICAgICAgIHsKKyAgICAg ICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULAorICAgICAgICAgICAgICAgICAgICAgICAiTUNF OiB3ciBNQyV1X01JU0Mgd2l0aCAxcyB3aWxsIGNhdXNlICNHUFxuIiwgYmFuayk7CisgICAgICAg ICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICB9CisKKyAgICAgICAg aWYgKCBlbnRyeSAmJiAoZW50cnktPmJhbmsgPT0gYmFuaykgKQorICAgICAgICB7CisgICAgICAg ICAgICBlbnRyeS0+bWNpX21pc2MgPSB2YWw7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9W RVJCT1NFLAorICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0MgJSJQUkl4 NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAg ICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCisgICAgICAgICAgICAgICAgICAgICAg ICJNQ0U6IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJy ZWFrOwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHN3aXRjaCAoIGJvb3RfY3B1X2RhdGEueDg2X3Zl bmRvciApCg== --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Mon May 07 11:20:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:20:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRLyq-0003t3-Bh; Mon, 07 May 2012 11:19:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRLyo-0003sy-LL for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:19:50 +0000 Received: from [85.158.143.35:49749] by server-2.bemta-4.messagelabs.com id 95/41-17550-5DFA7AF4; Mon, 07 May 2012 11:19:49 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336389587!12936266!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwMjY1\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30834 invoked from network); 7 May 2012 11:19:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-21.messagelabs.com with SMTP; 7 May 2012 11:19:48 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 07 May 2012 04:19:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="139764071" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 07 May 2012 04:19:30 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 May 2012 04:19:29 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.240]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.226]) with mapi id 14.01.0355.002; Mon, 7 May 2012 19:19:27 +0800 From: "Liu, Jinsong" To: Jan Beulich , "keir.xen@gmail.com" , "xen-devel@lists.xensource.com" Thread-Topic: [PATCH] Fix vmce MCi_ADDR/MCi_MISC wrmsr bug (v2) Thread-Index: Ac0sQ0OvBC9EpOIaTL+A4EwGPh/oBA== Date: Mon, 7 May 2012 11:19:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_" MIME-Version: 1.0 Subject: [Xen-devel] [PATCH] Fix vmce MCi_ADDR/MCi_MISC wrmsr bug (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fix vmce MCi_ADDR/MCi_MISC wrmsr bug This patch fix a bug related to wrmsr vmce MCi_ADDR/MCi_MISC registers, since they are not read-only. Intel SDM recommanded os mce driver clear MCi_ADDR/MCi_MISC So guest mce driver may clear MCi_ADDR/MCi_MISC registers. Under such case, old vmce wrmsr logic would generate a #GP fault at guest mce context, and make guest crash. When wrmsr MCi_ADDR/MCi_MISC, writing 1s will cause #GP. Signed-off-by: Liu, Jinsong diff -r 755f440b3b78 xen/arch/x86/cpu/mcheck/vmce.c --- a/xen/arch/x86/cpu/mcheck/vmce.c Wed Apr 18 18:33:36 2012 +0800 +++ b/xen/arch/x86/cpu/mcheck/vmce.c Tue May 08 03:02:50 2012 +0800 @@ -209,6 +209,14 @@ struct domain_mca_msrs *vmce =3D dom_vmce(v->domain); struct bank_entry *entry =3D NULL; =20 + /* Give the first entry of the list, it corresponds to current + * vMCE# injection. When vMCE# is finished processing by the + * the guest, this node will be deleted. + * Only error bank is written. Non-error banks simply return. + */ + if ( !list_empty(&vmce->impact_header) ) + entry =3D list_entry(vmce->impact_header.next, struct bank_entry, = list); + switch ( msr & (MSR_IA32_MC0_CTL | 3) ) { case MSR_IA32_MC0_CTL: @@ -216,32 +224,53 @@ vmce->mci_ctl[bank] =3D val; break; case MSR_IA32_MC0_STATUS: - /* Give the first entry of the list, it corresponds to current - * vMCE# injection. When vMCE# is finished processing by the - * the guest, this node will be deleted. - * Only error bank is written. Non-error banks simply return. - */ - if ( !list_empty(&vmce->impact_header) ) + if ( entry && (entry->bank =3D=3D bank) ) { - entry =3D list_entry(vmce->impact_header.next, - struct bank_entry, list); - if ( entry->bank =3D=3D bank ) - entry->mci_status =3D val; + entry->mci_status =3D val; mce_printk(MCE_VERBOSE, - "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", - bank, val); + "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n", bank, v= al); } else mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_ADDR: - mce_printk(MCE_QUIET, "MCE: MC%u_ADDR is read-only\n", bank); - ret =3D -1; + if ( val =3D=3D ~0 ) + { + mce_printk(MCE_QUIET, + "MCE: wr MC%u_ADDR with 1s will cause #GP\n", bank)= ; + ret =3D -1; + break; + } + + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_addr =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val= ); + } + else + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val); break; case MSR_IA32_MC0_MISC: - mce_printk(MCE_QUIET, "MCE: MC%u_MISC is read-only\n", bank); - ret =3D -1; + if ( val =3D=3D ~0 ) + { + mce_printk(MCE_QUIET, + "MCE: wr MC%u_MISC with 1s will cause #GP\n", bank)= ; + ret =3D -1; + break; + } + + if ( entry && (entry->bank =3D=3D bank) ) + { + entry->mci_misc =3D val; + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val= ); + } + else + mce_printk(MCE_VERBOSE, + "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val); break; default: switch ( boot_cpu_data.x86_vendor )= --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="vmce-bug-fix.patch" Content-Description: vmce-bug-fix.patch Content-Disposition: attachment; filename="vmce-bug-fix.patch"; size=3769; creation-date="Mon, 07 May 2012 11:15:40 GMT"; modification-date="Mon, 07 May 2012 19:09:06 GMT" Content-Transfer-Encoding: base64 Rml4IHZtY2UgTUNpX0FERFIvTUNpX01JU0Mgd3Jtc3IgYnVnCgpUaGlzIHBhdGNoIGZpeCBhIGJ1 ZyByZWxhdGVkIHRvIHdybXNyIHZtY2UgTUNpX0FERFIvTUNpX01JU0MKcmVnaXN0ZXJzLCBzaW5j ZSB0aGV5IGFyZSBub3QgcmVhZC1vbmx5LgoKSW50ZWwgU0RNIHJlY29tbWFuZGVkIG9zIG1jZSBk cml2ZXIgY2xlYXIgTUNpX0FERFIvTUNpX01JU0MKU28gZ3Vlc3QgbWNlIGRyaXZlciBtYXkgY2xl YXIgTUNpX0FERFIvTUNpX01JU0MgcmVnaXN0ZXJzLgpVbmRlciBzdWNoIGNhc2UsIG9sZCB2bWNl IHdybXNyIGxvZ2ljIHdvdWxkIGdlbmVyYXRlCmEgI0dQIGZhdWx0IGF0IGd1ZXN0IG1jZSBjb250 ZXh0LCBhbmQgbWFrZSBndWVzdCBjcmFzaC4KCldoZW4gd3Jtc3IgTUNpX0FERFIvTUNpX01JU0Ms IHdyaXRpbmcgMXMgd2lsbCBjYXVzZSAjR1AuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcg PGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgNzU1ZjQ0MGIzYjc4IHhlbi9hcmNoL3g4 Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJ V2VkIEFwciAxOCAxODozMzozNiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNo ZWNrL3ZtY2UuYwlUdWUgTWF5IDA4IDAzOjAyOjUwIDIwMTIgKzA4MDAKQEAgLTIwOSw2ICsyMDks MTQgQEAKICAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNlID0gZG9tX3ZtY2Uodi0+ZG9t YWluKTsKICAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnkgPSBOVUxMOwogCisgICAgLyogR2l2 ZSB0aGUgZmlyc3QgZW50cnkgb2YgdGhlIGxpc3QsIGl0IGNvcnJlc3BvbmRzIHRvIGN1cnJlbnQK KyAgICAgKiB2TUNFIyBpbmplY3Rpb24uIFdoZW4gdk1DRSMgaXMgZmluaXNoZWQgcHJvY2Vzc2lu ZyBieSB0aGUKKyAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3aWxsIGJlIGRlbGV0ZWQuCisg ICAgICogT25seSBlcnJvciBiYW5rIGlzIHdyaXR0ZW4uIE5vbi1lcnJvciBiYW5rcyBzaW1wbHkg cmV0dXJuLgorICAgICAqLworICAgIGlmICggIWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFk ZXIpICkKKyAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZtY2UtPmltcGFjdF9oZWFkZXIubmV4 dCwgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOworCiAgICAgc3dpdGNoICggbXNyICYgKE1TUl9J QTMyX01DMF9DVEwgfCAzKSApCiAgICAgewogICAgIGNhc2UgTVNSX0lBMzJfTUMwX0NUTDoKQEAg LTIxNiwzMiArMjI0LDUzIEBACiAgICAgICAgICAgICB2bWNlLT5tY2lfY3RsW2JhbmtdID0gdmFs OwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAgICAg IC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0LCBpdCBjb3JyZXNwb25kcyB0byBj dXJyZW50Ci0gICAgICAgICAqIHZNQ0UjIGluamVjdGlvbi4gV2hlbiB2TUNFIyBpcyBmaW5pc2hl ZCBwcm9jZXNzaW5nIGJ5IHRoZQotICAgICAgICAgKiB0aGUgZ3Vlc3QsIHRoaXMgbm9kZSB3aWxs IGJlIGRlbGV0ZWQuCi0gICAgICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0dGVuLiBOb24t ZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KLSAgICAgICAgICovCi0gICAgICAgIGlmICggIWxp c3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYgKCBlbnRyeSAmJiAo ZW50cnktPmJhbmsgPT0gYmFuaykgKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeSA9IGxp c3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlmICggZW50 cnktPmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSB2 YWw7CisgICAgICAgICAgICBlbnRyeS0+bWNpX3N0YXR1cyA9IHZhbDsKICAgICAgICAgICAgIG1j ZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1D JXVfU1RBVFVTICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg YmFuaywgdmFsKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9TVEFUVVMg JSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOwogICAgICAgICB9CiAgICAgICAgIGVs c2UKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCiAgICAgICAgICAgICAgICAg ICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKICAg ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgbWNlX3By aW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1DJXVfQUREUiBpcyByZWFkLW9ubHlcbiIsIGJhbmspOwot ICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgaWYgKCB2YWwgPT0gfjAgKQorICAgICAgICB7Cisg ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKKyAgICAgICAgICAgICAgICAgICAgICAg Ik1DRTogd3IgTUMldV9BRERSIHdpdGggMXMgd2lsbCBjYXVzZSAjR1BcbiIsIGJhbmspOworICAg ICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorCisgICAg ICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5rID09IGJhbmspICkKKyAgICAgICAgeworICAg ICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOworICAgICAgICAgICAgbWNlX3ByaW50ayhN Q0VfVkVSQk9TRSwKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9BRERSICUi UFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQorICAgICAgICBlbHNl CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAorICAgICAgICAgICAgICAgICAg ICAgICAiTUNFOiB3ciBNQyV1X0FERFIgJSJQUkl4NjQiXG4iLCBiYW5rLCB2YWwpOwogICAgICAg ICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBtY2VfcHJpbnRr KE1DRV9RVUlFVCwgIk1DRTogTUMldV9NSVNDIGlzIHJlYWQtb25seVxuIiwgYmFuayk7Ci0gICAg ICAgIHJldCA9IC0xOworICAgICAgICBpZiAoIHZhbCA9PSB+MCApCisgICAgICAgIHsKKyAgICAg ICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULAorICAgICAgICAgICAgICAgICAgICAgICAiTUNF OiB3ciBNQyV1X01JU0Mgd2l0aCAxcyB3aWxsIGNhdXNlICNHUFxuIiwgYmFuayk7CisgICAgICAg ICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAgICB9CisKKyAgICAgICAg aWYgKCBlbnRyeSAmJiAoZW50cnktPmJhbmsgPT0gYmFuaykgKQorICAgICAgICB7CisgICAgICAg ICAgICBlbnRyeS0+bWNpX21pc2MgPSB2YWw7CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9W RVJCT1NFLAorICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0MgJSJQUkl4 NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAg ICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCisgICAgICAgICAgICAgICAgICAgICAg ICJNQ0U6IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJy ZWFrOwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHN3aXRjaCAoIGJvb3RfY3B1X2RhdGEueDg2X3Zl bmRvciApCg== --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC82923351A076FSHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Mon May 07 11:52:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:52:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMTg-0004QQ-M5; Mon, 07 May 2012 11:51:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMTf-0004QL-6Y for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:51:43 +0000 Received: from [85.158.143.35:41662] by server-2.bemta-4.messagelabs.com id 69/81-17550-E47B7AF4; Mon, 07 May 2012 11:51:42 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336391501!11165268!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28957 invoked from network); 7 May 2012 11:51:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 11:51:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="12328154" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 11:50:09 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 12:50:08 +0100 Message-ID: <4FA7B6EF.9030403@citrix.com> Date: Mon, 7 May 2012 12:50:07 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich , AP References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> In-Reply-To: <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 09:10, Jan Beulich wrote: >>>> On 05.05.12 at 02:21, AP wrote: >> (XEN) *** IRQ BUG found *** >> (XEN) CPU0 -Testing vector 236 from bitmap > 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming > in through the 8259A. Something fundamentally fishy must be going > on here, and I would suppose the code in question shouldn't even be > reached for legacy vectors. > > Furthermore, calling dump_irqs() from the debugging code with > desc->lock still held makes it impossible to get full output, as that > function wants to lock all initialized IRQ descriptors. > > Jan Yes - it has been vector 236 on each of the 3 reported failures from AP, and I believe it was also vector 236 in the one case I managed to reproduce the issue. However, once we have set up the IO-APIC, the 8259A should not be used any more. The boot dmeg shows that io_ack_method is indeed "old" (which was going to be my first suggestion), and that EOI Broadcast Suppression is enabled, which I have already identified as a source of problems for some customers. As a 'fix', I provided the ability for "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not completely fixed the customer problems - just made it substantially more rare. AP: Can you manually invoke the 'i' debug key and provide that - it will help to see how Xen is setting up the IO-APIC(s) on your system. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 11:52:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:52:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMTg-0004QQ-M5; Mon, 07 May 2012 11:51:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMTf-0004QL-6Y for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:51:43 +0000 Received: from [85.158.143.35:41662] by server-2.bemta-4.messagelabs.com id 69/81-17550-E47B7AF4; Mon, 07 May 2012 11:51:42 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336391501!11165268!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28957 invoked from network); 7 May 2012 11:51:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 11:51:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="12328154" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 11:50:09 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 12:50:08 +0100 Message-ID: <4FA7B6EF.9030403@citrix.com> Date: Mon, 7 May 2012 12:50:07 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich , AP References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> In-Reply-To: <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 09:10, Jan Beulich wrote: >>>> On 05.05.12 at 02:21, AP wrote: >> (XEN) *** IRQ BUG found *** >> (XEN) CPU0 -Testing vector 236 from bitmap > 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming > in through the 8259A. Something fundamentally fishy must be going > on here, and I would suppose the code in question shouldn't even be > reached for legacy vectors. > > Furthermore, calling dump_irqs() from the debugging code with > desc->lock still held makes it impossible to get full output, as that > function wants to lock all initialized IRQ descriptors. > > Jan Yes - it has been vector 236 on each of the 3 reported failures from AP, and I believe it was also vector 236 in the one case I managed to reproduce the issue. However, once we have set up the IO-APIC, the 8259A should not be used any more. The boot dmeg shows that io_ack_method is indeed "old" (which was going to be my first suggestion), and that EOI Broadcast Suppression is enabled, which I have already identified as a source of problems for some customers. As a 'fix', I provided the ability for "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not completely fixed the customer problems - just made it substantially more rare. AP: Can you manually invoke the 'i' debug key and provide that - it will help to see how Xen is setting up the IO-APIC(s) on your system. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 11:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMUV-0004Tp-AN; Mon, 07 May 2012 11:52:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMUS-0004Td-HU for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:52:33 +0000 Received: from [85.158.138.51:24643] by server-7.bemta-3.messagelabs.com id 1A/85-03078-F77B7AF4; Mon, 07 May 2012 11:52:31 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-7.tower-174.messagelabs.com!1336391140!16737548!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25933 invoked from network); 7 May 2012 11:45:40 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-7.tower-174.messagelabs.com with SMTP; 7 May 2012 11:45:40 -0000 Received: (qmail 31365 invoked from network); 7 May 2012 13:45:26 +0200 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; 7 May 2012 13:45:26 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: "xen-devel@lists.xensource.com" Date: Mon, 7 May 2012 13:45:23 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_TX7pPqk9X0OyHh/" Message-Id: <201205071345.23619.pavel@netsafe.cz> Subject: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm trying to run AMD VGA passthru on latest XEN unstable with latest kernel. I already have working setup with ancient xen-devel 4.2 and 2.6.32.x xenified kernel. See attached log. So I tried just to update and patch xen and kernel, but I had no luck so far. Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang recently. http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html I tried two kernels testing-3.5-with-extra and xen/next-3.2 from git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git and git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Both with ioperm opcode patch which is required by the ATI patch. See attachement. The xen/next-3.2 branch kernel was able to start booting windows. With Catalyst driver installed I just saw bluescreen during Windows boot. Without Catalyst driver Windows were able to boot but Windows ended frozen or USB was not working. It was hard to tell because input devices had no response at all. The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 kernel during Windows boot. I guess I have to rework the io_bitmap patch somehow. -- Pavel Mateja --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="2.6.32.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="2.6.32.log" __ __ _ _ ____ _ _ _ =20 \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___=20 \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| =20 (XEN) Xen version 4.2-unstable (root@netsafe.cz) (gcc version 4.4.5 (Debian= 4.4.5-8) ) Sun Feb 5 15:55:33 CET 2012 (XEN) Latest ChangeSet: Thu May 05 17:40:34 2011 +0100 23300:4b0692880dfa (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=3D2G dom0_max_vcpus=3D6 loglvl=3Da= ll guest_loglvl=3Dall sync_console com1=3D115200,8n1,0xac00 console=3Dcom1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.254 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =FF(XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is ena= bled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL =3D 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=3D0x1000000 memsz=3D0x77c000 (XEN) elf_parse_binary: phdr: paddr=3D0x177c000 memsz=3D0x8da88 (XEN) elf_parse_binary: phdr: paddr=3D0x180a000 memsz=3D0x8c8 (XEN) elf_parse_binary: phdr: paddr=3D0x180b000 memsz=3D0x14a58 (XEN) elf_parse_binary: phdr: paddr=3D0x1820000 memsz=3D0x212000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1a32000 (XEN) elf_xen_parse_note: GUEST_OS =3D "linux" (XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6" (XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff81820200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo= ve_4gb" (XEN) elf_xen_parse_note: PAE_MODE =3D "yes" (XEN) elf_xen_parse_note: LOADER =3D "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1 (XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base =3D 0xffffffff80000000 (XEN) elf_paddr_offset =3D 0x0 (XEN) virt_offset =3D 0xffffffff80000000 (XEN) virt_kstart =3D 0xffffffff81000000 (XEN) virt_kend =3D 0xffffffff81a32000 (XEN) virt_entry =3D 0xffffffff81820200 (XEN) p2m_base =3D 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a32000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506263 pages to b= e allocated) (XEN) Init. ramdisk: 000000022f997000->000000022ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a32000 (XEN) Init. ramdisk: ffffffff81a32000->ffffffff8209a600 (XEN) Phys-Mach map: ffffffff8209b000->ffffffff8249b000 (XEN) Start info: ffffffff8249b000->ffffffff8249b4b4 (XEN) Page tables: ffffffff8249c000->ffffffff824b3000 (XEN) Boot stack: ffffffff824b3000->ffffffff824b4000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81820200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8177c000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8177c000 -> 0xffffffff81809a88 (XEN) elf_load_binary: phdr 2 at 0xffffffff8180a000 -> 0xffffffff8180a8c8 (XEN) elf_load_binary: phdr 3 at 0xffffffff8180b000 -> 0xffffffff8181fa58 (XEN) elf_load_binary: phdr 4 at 0xffffffff81820000 -> 0xffffffff818b3000 (XEN) Scrubbing Free RAM: .................................................= =2E...........done. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1...=20 (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 236kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... ERROR: Unable to locate IOAPIC for GSI 2 ERROR: Unable to locate IOAPIC for GSI 9 (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010004 from 0x000024= a74db06404 to 0x0000000000000000. (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010000 from 0x000003= 061a0effc9 to 0x0000000000430076. ERROR: Unable to locate IOAPIC for GSI 9 (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 registering netback IT87 WDT: Unknown Chip found, Chip 8721 Revision 0001 [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. [Firmware Bug]: powernow-k8: Try again with latest BIOS. Loading, please wait... INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...udevd-work[1437]: kernel-provided = name 'blktap-control' and NAME=3D 'xen/blktap-2/control' disagree, please u= se SYMLINK+=3D or change the kernel to provide the proper name done. Setting preliminary keymap...done. Activating swap...done. Checking root file system...fsck from util-linux-ng 2.17.2 HOWTO_ROOT: clean, 95054/1419840 files, 731180/5679104 blocks (check in 4 m= ounts) done. Loading kernel modules...done. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take = a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active =2E Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Setting kernel variables ...done. Configuring network interfaces...done. Cleaning up temporary files.... Setting console screen modes. Rcannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. acpid: starting up with proc fs acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting periodic command scheduler: cron. Starting OpenBSD Secure Shell server: sshd. Starting xenstored...XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Setting domain 0 name... Starting xenconsoled... BLKTAPCTRL[2168]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2168]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2168]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2168]: blktapctrl.c:922: Unable to start blktapctrl (XEN) PCI remove device 00:12.2 (XEN) PCI add device 00:12.2 /usr/local/bin/xen_start.sh: line 15: /sys/bus/pci/devices/0000:07:00.0/dri= ver/unbind: No such file or directory Using config file "/etc/xen/windows". (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 Started domain windows (id=3D1)(XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:258: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM2: HVM Loader (XEN) HVM2: Detected Xen v4.2-unstable (XEN) HVM2: Xenbus rings @0xfeffc000, event channel 7 (XEN) HVM2: System requested ROMBIOS (XEN) HVM2: CPU speed is 3010 MHz (XEN) irq.c:258: Dom2 PCI link 0 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom2 PCI link 1 changed 0 -> 10 (XEN) HVM2: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom2 PCI link 2 changed 0 -> 11 (XEN) HVM2: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom2 PCI link 3 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 3 routed to IRQ5 (XEN) HVM2: pci dev 01:3 INTA->IRQ10 (XEN) HVM2: pci dev 03:0 INTA->IRQ5 (XEN) HVM2: pci dev 04:0 INTA->IRQ5 (XEN) HVM2: pci dev 05:0 INTA->IRQ10 (XEN) HVM2: pci dev 06:0 INTB->IRQ5 (XEN) HVM2: pci dev 07:0 INTA->IRQ5 (XEN) HVM2: pci dev 08:0 INTB->IRQ10 (XEN) HVM2: pci dev 09:0 INTA->IRQ10 (XEN) HVM2: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM2: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM2: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM2: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM2: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM2: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM2: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM2: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM2: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM2: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM2: Multiprocessor initialisation: (XEN) HVM2: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: Testing HVM environment: (XEN) HVM2: - REP INSB across page boundaries ... passed (XEN) HVM2: - GS base MSRs and SWAPGS ... passed (XEN) HVM2: Passed 2 of 2 tests (XEN) HVM2: Writing SMBIOS tables ... (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM3: HVM Loader (XEN) HVM3: Detected Xen v4.2-unstable (XEN) HVM3: Xenbus rings @0xfeffc000, event channel 7 (XEN) HVM3: System requested ROMBIOS (XEN) HVM3: CPU speed is 3010 MHz (XEN) irq.c:258: Dom3 PCI link 0 changed 0 -> 5 (XEN) HVM3: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom3 PCI link 1 changed 0 -> 10 (XEN) HVM3: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom3 PCI link 2 changed 0 -> 11 (XEN) HVM3: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom3 PCI link 3 changed 0 -> 5 (XEN) HVM3: PCI-ISA link 3 routed to 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 05:0 INTA->IRQ10 (XEN) HVM3: pci dev 06:0 INTB->IRQ5 (XEN) HVM3: pci dev 07:0 INTA->IRQ5 (XEN) HVM3: pci dev 08:0 INTB->IRQ10 (XEN) HVM3: pci dev 09:0 INTA->IRQ10 (XEN) HVM3: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM3: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM3: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM3: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM3: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM3: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM3: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM3: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM3: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM3: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM3: Multiprocessor initialisation: (XEN) HVM3: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: Testing HVM environment: (XEN) HVM3: - REP INSB across page boundaries ... passed (XEN) HVM3: - GS base MSRs and SWAPGS ... passed (XEN) HVM3: Passed 2 of 2 tests (XEN) HVM3: Writing SMBIOS tables ... __ __ _ _ ____ _ _ _ =20 \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___=20 \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| =20 (XEN) Xen version 4.2-unstable (root@netsafe.cz) (gcc version 4.4.5 (Debian= 4.4.5-8) ) Sun Feb 5 15:55:33 CET 2012 (XEN) Latest ChangeSet: Thu May 05 17:40:34 2011 +0100 23300:4b0692880dfa (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=3D2G dom0_max_vcpus=3D6 loglvl=3Da= ll guest_loglvl=3Dall sync_console com1=3D115200,8n1,0xac00 console=3Dcom1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.220 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =FF(XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is ena= bled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL =3D 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=3D0x1000000 memsz=3D0x77c000 (XEN) elf_parse_binary: phdr: paddr=3D0x177c000 memsz=3D0x8da88 (XEN) elf_parse_binary: phdr: paddr=3D0x180a000 memsz=3D0x8c8 (XEN) elf_parse_binary: phdr: paddr=3D0x180b000 memsz=3D0x14a58 (XEN) elf_parse_binary: phdr: paddr=3D0x1820000 memsz=3D0x212000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1a32000 (XEN) elf_xen_parse_note: GUEST_OS =3D "linux" (XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6" (XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff81820200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo= ve_4gb" (XEN) elf_xen_parse_note: PAE_MODE =3D "yes" (XEN) elf_xen_parse_note: LOADER =3D "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1 (XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base =3D 0xffffffff80000000 (XEN) elf_paddr_offset =3D 0x0 (XEN) virt_offset =3D 0xffffffff80000000 (XEN) virt_kstart =3D 0xffffffff81000000 (XEN) virt_kend =3D 0xffffffff81a32000 (XEN) virt_entry =3D 0xffffffff81820200 (XEN) p2m_base =3D 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a32000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506263 pages to b= e allocated) (XEN) Init. ramdisk: 000000022f997000->000000022ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a32000 (XEN) Init. ramdisk: ffffffff81a32000->ffffffff8209a600 (XEN) Phys-Mach map: ffffffff8209b000->ffffffff8249b000 (XEN) Start info: ffffffff8249b000->ffffffff8249b4b4 (XEN) Page tables: ffffffff8249c000->ffffffff824b3000 (XEN) Boot stack: ffffffff824b3000->ffffffff824b4000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81820200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8177c000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8177c000 -> 0xffffffff81809a88 (XEN) elf_load_binary: phdr 2 at 0xffffffff8180a000 -> 0xffffffff8180a8c8 (XEN) elf_load_binary: phdr 3 at 0xffffffff8180b000 -> 0xffffffff8181fa58 (XEN) elf_load_binary: phdr 4 at 0xffffffff81820000 -> 0xffffffff818b3000 (XEN) Scrubbing Free RAM: .................................................= =2E...........done. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1...=20 (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 236kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... ERROR: Unable to locate IOAPIC for GSI 2 ERROR: Unable to locate IOAPIC for GSI 9 (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4= a75df86514 to 0x0000000000000000. (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010000 from 0x000003= 0e1b0effe9 to 0x0000000000430076. ERROR: Unable to locate IOAPIC for GSI 9 (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 registering netback IT87 WDT: Unknown Chip found, Chip 8721 Revision 0001 [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. [Firmware Bug]: powernow-k8: Try again with latest BIOS. Loading, please wait... INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...udevd-work[1429]: kernel-provided = name 'blktap-control' and NAME=3D 'xen/blktap-2/control' disagree, please u= se SYMLINK+=3D or change the kernel to provide the proper name done. Setting preliminary keymap...done. Activating swap...done. Checking root file system...fsck from util-linux-ng 2.17.2 HOWTO_ROOT: clean, 95056/1419840 files, 731207/5679104 blocks (check in 3 m= ounts) done. Loading kernel modules...done. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take = a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active =2E Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Setting kernel variables ...done. Configuring network interfaces...done. Cleaning up temporary files.... Setting console screen modes. Rcannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. acpid: starting up with proc fs acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting periodic command scheduler: cron. Starting OpenBSD Secure Shell server: sshd. Starting xenstored...XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Setting domain 0 name... Starting xenconsoled... BLKTAPCTRL[2156]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2156]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2156]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2156]: blktapctrl.c:922: Unable to start blktapctrl (XEN) PCI remove device 00:12.2 (XEN) PCI add device 00:12.2 /usr/local/bin/xen_start.sh: line 15: /sys/bus/pci/devices/0000:07:00.0/dri= ver/unbind: No such file or directory Using config file "/etc/xen/windows". (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 Started domain windows (id=3D1)(XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:258: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc000000-0xfc0025bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://etherboot.org (XEN) HVM1: - Product name: gPXE (XEN) HVM1: Loading ACPI ... (XEN) HVM1: - Lo data: 000ea020-000ea04f (XEN) HVM1: - Hi data: fc002800-fc01291f (XEN) HVM1: vm86 TSS at fc012c00 (XEN) HVM1: BIOS map: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e1fff: Etherboot ROM (XEN) HVM1: eb000-eb20f: SMBIOS tables (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED (XEN) HVM1: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [04]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [06]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM=20 (XEN) HVM1:=20 (XEN) HVM1: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1:=20 (XEN) HVM1:=20 (XEN) HVM1:=20 (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1:=20 (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:258: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:258: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:258: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:258: Dom1 PCI link 3 changed 5 -> 0 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D= 10000 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D= 20 (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) grant_table.c:1156:d1 Expanding dom (1) grant table from (4) to (32) = frames. (XEN) irq.c:324: Dom1 callback via changed to GSI 28 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D= 10000 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D= 20 (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="3.2.0-rc2.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="3.2.0-rc2.log" __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.225 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5b2000 (XEN) elf_parse_binary: phdr: paddr=0x15b2000 memsz=0x660e0 (XEN) elf_parse_binary: phdr: paddr=0x1619000 memsz=0x12500 (XEN) elf_parse_binary: phdr: paddr=0x162c000 memsz=0x21b000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1847000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff8162c200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81847000 (XEN) virt_entry = 0xffffffff8162c200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1847000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000226000000->0000000228000000 (514500 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81847000 (XEN) Init. ramdisk: ffffffff81847000->ffffffff81e82200 (XEN) Phys-Mach map: ffffffff81e83000->ffffffff82283000 (XEN) Start info: ffffffff82283000->ffffffff822834b4 (XEN) Page tables: ffffffff82284000->ffffffff82299000 (XEN) Boot stack: ffffffff82299000->ffffffff8229a000 (XEN) TOTAL: ffffffff80000000->ffffffff82400000 (XEN) ENTRY ADDRESS: ffffffff8162c200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815b2000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815b2000 -> 0xffffffff816180e0 (XEN) elf_load_binary: phdr 2 at 0xffffffff81619000 -> 0xffffffff8162b500 (XEN) elf_load_binary: phdr 3 at 0xffffffff8162c000 -> 0xffffffff816b2000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.2.0-rc2-11202-gd3507af-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 SMP PREEMPT Sat May 5 20:13:29 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 00000000cfe80000 (usable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (usable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01847000 - 01e83000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffb000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at 80000000 (gap: 80000000:4fe80000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4b000 s75008 r8192 d23296 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 514973 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975220k/2097152k available (4470k kernel code, 472k absent, 121460k reserved, 1768k data, 596k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Verbose stalled-CPUs detection is disabled. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.224 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.44 BogoMIPS (lpj=3010224) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 ACPI: Core revision 20110623 cpu 0 spinlock event irq 297 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 303 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 315 installing Xen timer for CPU 4 cpu 4 spinlock event irq 321 installing Xen timer for CPU 5 cpu 5 spinlock event irq 327 Brought up 6 CPUs devtmpfs: initialized Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M Extended Config Space enabled on 1 nodes ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 HEST: Table not found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] pci 0000:00:02.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:04.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:05.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 pci 0000:00:06.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 pci 0000:00:07.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 pci 0000:00:0d.0: PCI INT A -> GSI 54 (level, low) -> IRQ 54 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] ERST: Table is not found! GHES: HEST is not enabled! Event-channel device installed. pciback 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pciback 0000:00:14.2: PCI INT A disabled xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:02:00.0: PCI INT A -> GSI 40 (level, low) -> IRQ 40 serial 0000:02:00.1: PCI INT B -> GSI 41 (level, low) -> IRQ 41 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata1: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: PCI INT A -> GSI 44 (level, low) -> IRQ 44 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata7: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.29 sky2 0000:04:00.0: PCI INT A -> GSI 51 (level, low) -> IRQ 51 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 cdc_ncm: 04-Aug-2011 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46 firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata5: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 ata7: SATA link down (SStatus 0 SControl 300) ata8: SATA link down (SStatus 0 SControl 300) usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver sda: sda1 sda2 ohci_hcd 0000:00:12.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb 1-1: new high-speed USB device number 2 using ehci_hcd usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected firewire_core: created device fw0: GUID 001e8c0000de9136, S400 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xhci_hcd 0000:03:00.0: PCI INT A -> GSI 50 (level, low) -> IRQ 50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 ATK0110 ATK0110:00: EC enabled SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 SP5100 TCO timer: mmio address 0xb8fe00 already in use IT87 WDT: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) wdt: Xen WatchDog Timer Driver v0.01 wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 usb 4-2: new full-speed USB device number 2 using ohci_hcd EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 11:07:15 UTC (1336388835) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. powernow-k8: invalid pstate 1 - bad value 1. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 2 - bad value 2. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 3 - bad value 3. powernow-k8: Please report to BIOS manufacturer [Firmware Bug]: powernow-k8: invalid powernow_table Freeing unused kernel memory: 596k freed Loading, please wait... udev[1087]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/local-premount ... done. EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 done. INIT: version 2.88 booting usb 1-1.2: new low-speed USB device number 5 using ehci_hcd Using makefile-style concurrent boot in runlevel S. Files under mount point '/lib/init/rw' will be hidden. ... (warning). usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony Files under mount point '/var/run' will be hidden. ...input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 (warning). input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 firewire_net: firewire0: IPv4 over FireWire on device 001e8c0000de9136 firewire_core: refreshed device fw0 Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1296]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 175647/1310720 files, 1276770/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting the Winbind daemon: winbind.sshd (2066): /pr oc/2066/oom_adj is deprecated, please use /proc/2066/oom_score_adj instead. XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting OpenBSD Secure Shell server: sshd. Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2231]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2231]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2231]: blktapctrl.c:861: couldn't open blktap interface BLKTAPCTRL[2231]: blktapctrl.c:924: Unable to start blktapctrl Starting S.M.A.R.T. daemon: smartd. sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 [CPU0] failed to set governor name [CPU1] failed to set governor name [CPU2] failed to set governor name [CPU3] failed to set governor name [CPU4] failed to set governor name [CPU5] failed to set governor name . acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0701, fault address = 0x9db44000 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa94324e0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa94324b0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9508a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab040 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab0c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab100 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab140 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab180 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab1c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab200 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab240 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab280 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab2c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab300 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab340 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab340 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab380 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab380 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab3c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab3c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa950ea80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96f6a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa950ea80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9402a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9402a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96fca80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96fca80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80040 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-patch; charset="ISO-8859-1"; name="ioperm.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ioperm.patch" diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index aa0f913..259ef7f 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, int entry, const gate_desc *g) { PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); } + static inline void set_iopl_mask(unsigned mask) { PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); } +static inline void set_io_bitmap(struct thread_struct *thread, + unsigned long bytes_updated) +{ + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); +} + /* The paravirtualized I/O functions */ static inline void slow_down_io(void) { diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..96f267c 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -142,6 +142,8 @@ struct pv_cpu_ops { void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); void (*set_iopl_mask)(unsigned mask); + void (*set_io_bitmap)(struct thread_struct *thread, + unsigned long bytes_updated); void (*wbinvd)(void); void (*io_delay)(void); diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 4fa7dcc..62becce 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned mask) #endif } +extern void native_set_io_bitmap(struct thread_struct *thread, + unsigned long updated_bytes); + static inline void native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) { @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, } #define set_iopl_mask native_set_iopl_mask +#define set_io_bitmap native_set_io_bitmap #endif /* CONFIG_PARAVIRT */ /* diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c index 8c96897..c372ef0 100644 --- a/arch/x86/kernel/ioport.c +++ b/arch/x86/kernel/ioport.c @@ -17,13 +17,29 @@ #include #include +void native_set_io_bitmap(struct thread_struct *t, + unsigned long bytes_updated) +{ + struct tss_struct *tss; + + if (!bytes_updated) + return; + + tss = &__get_cpu_var(init_tss); + + /* Update the TSS: */ + if (t->io_bitmap_ptr) + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); + else + memset(tss->io_bitmap, 0xff, bytes_updated); +} + /* * this changes the io permissions bitmap in the current task. */ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) { struct thread_struct *t = ¤t->thread; - struct tss_struct *tss; unsigned int i, max_long, bytes, bytes_updated; if ((from + num <= from) || (from + num > IO_BITMAP_BITS)) @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) } /* - * do it in the per-thread copy and in the TSS ... + * do it in the per-thread copy * - * Disable preemption via get_cpu() - we must not switch away + * Disable preemption - we must not switch away * because the ->io_bitmap_max value must match the bitmap * contents: */ - tss = &per_cpu(init_tss, get_cpu()); + preempt_disable(); if (turn_on) bitmap_clear(t->io_bitmap_ptr, from, num); @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) t->io_bitmap_max = bytes; - /* Update the TSS: */ - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); + set_io_bitmap(t, bytes_updated); - put_cpu(); + preempt_enable(); return 0; } diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index ab13760..aa420e7 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops = { .swapgs = native_swapgs, .set_iopl_mask = native_set_iopl_mask, + .set_io_bitmap = native_set_io_bitmap, .io_delay = native_io_delay, .start_context_switch = paravirt_nop, diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 1d92a5a..e8436cc 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -91,16 +91,12 @@ void exit_thread(void) unsigned long *bp = t->io_bitmap_ptr; if (bp) { - struct tss_struct *tss = &per_cpu(init_tss, get_cpu()); - + preempt_disable(); t->io_bitmap_ptr = NULL; clear_thread_flag(TIF_IO_BITMAP); - /* - * Careful, clear this in the TSS too: - */ - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); + set_io_bitmap(t, t->io_bitmap_max); t->io_bitmap_max = 0; - put_cpu(); + preempt_enable(); kfree(bp); } } @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p, hard_enable_TSC(); } - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { - /* - * Copy the relevant range of the IO bitmap. - * Normally this is 128 bytes or less: - */ - memcpy(tss->io_bitmap, next->io_bitmap_ptr, - max(prev->io_bitmap_max, next->io_bitmap_max)); - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { - /* - * Clear any possible leftover bits: - */ - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); - } + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) + set_io_bitmap(next, + max(prev->io_bitmap_max, next->io_bitmap_max)); + propagate_user_return_notify(prev_p, next_p); } diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 8853204..7a05509 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); } +static void xen_set_io_bitmap(struct thread_struct *thread, + int changed, unsigned long bytes_updated) +{ + struct physdev_set_iobitmap set_iobitmap; + + set_xen_guest_handle(set_iobitmap.bitmap, + (char *)thread->io_bitmap_ptr); + set_iobitmap.nr_ports = thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, + &set_iobitmap)); +} + static void xen_io_delay(void) { } @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = { .load_sp0 = xen_load_sp0, .set_iopl_mask = xen_set_iopl_mask, + .set_io_bitmap = xen_set_io_bitmap, .io_delay = xen_io_delay, /* Xen takes care of %gs when switching to usermode for us */ --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="3.4.0-rc4.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="3.4.0-rc4.log" __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.238 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5d3000 (XEN) elf_parse_binary: phdr: paddr=0x15d3000 memsz=0x6e0e8 (XEN) elf_parse_binary: phdr: paddr=0x1642000 memsz=0x12980 (XEN) elf_parse_binary: phdr: paddr=0x1655000 memsz=0x4ff000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1b54000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81655200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81b54000 (XEN) virt_entry = 0xffffffff81655200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b54000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506308 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81b54000 (XEN) Init. ramdisk: ffffffff81b54000->ffffffff8218f200 (XEN) Phys-Mach map: ffffffff82190000->ffffffff82590000 (XEN) Start info: ffffffff82590000->ffffffff825904b4 (XEN) Page tables: ffffffff82591000->ffffffff825a8000 (XEN) Boot stack: ffffffff825a8000->ffffffff825a9000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81655200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815d3000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815d3000 -> 0xffffffff816410e8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81642000 -> 0xffffffff81654980 (XEN) elf_load_binary: phdr 3 at 0xffffffff81655000 -> 0xffffffff816cc000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc4-00395-g87b5d90-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #5 SMP PREEMPT Sat May 5 19:29:42 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping Populating 80000-80066 pfn range: 102 pages added BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000080066000 (usable) Xen: 0000000080066000 - 00000000cfe80000 (unusable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (unusable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 0000000080066000 - 00000000cfe80000 (unusable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) user: 0000000100000000 - 0000000230000000 (unusable) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01b54000 - 02190000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffc000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 253, address 0xfec20000, GSI 24-277 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at cff00000 (gap: cff00000:2ed00000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4c000 s76160 r8192 d22144 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 515976 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975064k/2097152k available (4567k kernel code, 472k absent, 121616k reserved, 1833k data, 532k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Dump stacks of tasks blocking RCU-preempt GP. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.238 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.47 BogoMIPS (lpj=3010238) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks ACPI: Core revision 20120320 cpu 0 spinlock event irq 295 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 302 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 316 installing Xen timer for CPU 4 cpu 4 spinlock event irq 323 installing Xen timer for CPU 5 cpu 5 spinlock event irq 330 Brought up 6 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff] pci_bus 0000:00: root bus resource [mem 0xcff00000-0xdfffffff] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: CPU0: patch_level=0x010000bf microcode: CPU1: patch_level=0x010000bf microcode: CPU2: patch_level=0x010000bf microcode: CPU3: patch_level=0x010000bf microcode: CPU4: patch_level=0x010000bf microcode: CPU5: patch_level=0x010000bf microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] GHES: HEST is not enabled! Event-channel device installed. xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata7: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata9: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.30 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:16.2: debug port 1 ata7: SATA link down (SStatus 0 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata2.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata9: SATA link down (SStatus 0 SControl 300) ata8: SATA link down (SStatus 0 SControl 300) ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ata2.00: configured for UDMA/133 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb 1-1: new high-speed USB device number 2 using ehci_hcd usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: OHCI Host Controller firewire_core 0000:05:00.0: created device fw0: GUID 001e8c0000de9136, S400 ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xen_map_pirq_gsi: returning irq 50 for gsi 50 Already setup the GSI :50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \_SB_.PCI0.SBRG.ASOC.SMRG 1 (20120320/utaddress-251) usb 4-2: new full-speed USB device number 2 using ohci_hcd ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ATK0110 ATK0110:00: EC enabled sp5100_tco: SP5100 TCO WatchDog Timer Driver v0.01 sp5100_tco: mmio address 0xb8fe00 already in use it87_wdt: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) xen_wdt: Xen WatchDog Timer Driver v0.01 xen_wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP: cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 10:55:22 UTC (1336388122) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. Freeing unused kernel memory: 532k freed Loading, please wait... udev[1078]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer done. input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 Begin: Running /scripts/local-premount ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony INIT: version 2.88 booting input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 Using makefile-style concurrent boot in runlevel S.input: Chicony U SB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Files under mount point '/lib/init/rw' will be hidden. ...net firewire0: IPv4 over IEEE 1394 on card 0000:05:00.0 firewire_core 0000:05:00.0: refreshed device fw0 (warning). Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1286]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 175647/1310720 files, 1276635/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2064): /proc/2064/oom_adj is deprecated, please use /proc/2064/oom_score_adj instead. Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2234]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2234]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2234]: blktapctrl.c:861: couldn't open blktap interfacesky2 0000:04:00. 0: eth0: Link is up at 100 Mbps, full duplex, flow control both BLKTAPCTRL[2234]: blktapctrl.c:924: Unable to start blktapctrlbr0: port 1(eth0 ) entered forwarding state br0: port 1(eth0) entered forwarding state Starting S.M.A.R.T. daemon: smartd. br0: port 1(eth0) entered forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.254 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5d3000 (XEN) elf_parse_binary: phdr: paddr=0x15d3000 memsz=0x6e0e8 (XEN) elf_parse_binary: phdr: paddr=0x1642000 memsz=0x12980 (XEN) elf_parse_binary: phdr: paddr=0x1655000 memsz=0x4ff000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1b54000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81655200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81b54000 (XEN) virt_entry = 0xffffffff81655200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b54000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506308 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81b54000 (XEN) Init. ramdisk: ffffffff81b54000->ffffffff8218f200 (XEN) Phys-Mach map: ffffffff82190000->ffffffff82590000 (XEN) Start info: ffffffff82590000->ffffffff825904b4 (XEN) Page tables: ffffffff82591000->ffffffff825a8000 (XEN) Boot stack: ffffffff825a8000->ffffffff825a9000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81655200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815d3000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815d3000 -> 0xffffffff816410e8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81642000 -> 0xffffffff81654980 (XEN) elf_load_binary: phdr 3 at 0xffffffff81655000 -> 0xffffffff816cc000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc4-00395-g87b5d90-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #7 SMP PREEMPT Mon May 7 13:16:10 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping Populating 80000-80066 pfn range: 102 pages added BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000080066000 (usable) Xen: 0000000080066000 - 00000000cfe80000 (unusable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (unusable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 0000000080066000 - 00000000cfe80000 (unusable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) user: 0000000100000000 - 0000000230000000 (unusable) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01b54000 - 02190000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffc000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 253, address 0xfec20000, GSI 24-277 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at cff00000 (gap: cff00000:2ed00000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4c000 s76160 r8192 d22144 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 515976 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975064k/2097152k available (4567k kernel code, 472k absent, 121616k reserved, 1833k data, 532k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Dump stacks of tasks blocking RCU-preempt GP. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.254 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.50 BogoMIPS (lpj=3010254) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks ACPI: Core revision 20120320 cpu 0 spinlock event irq 295 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 302 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 316 installing Xen timer for CPU 4 cpu 4 spinlock event irq 323 installing Xen timer for CPU 5 cpu 5 spinlock event irq 330 Brought up 6 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff] pci_bus 0000:00: root bus resource [mem 0xcff00000-0xdfffffff] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: CPU0: patch_level=0x010000bf microcode: CPU1: patch_level=0x010000bf microcode: CPU2: patch_level=0x010000bf microcode: CPU3: patch_level=0x010000bf microcode: CPU4: patch_level=0x010000bf microcode: CPU5: patch_level=0x010000bf microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] GHES: HEST is not enabled! Event-channel device installed. xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata7: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata9: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.30 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata5: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata8: SATA link down (SStatus 0 SControl 300) hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 ata9: SATA link down (SStatus 0 SControl 300) ata7: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata2.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) ata6: SATA link down (SStatus 0 SControl 300) usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 ata2.00: configured for UDMA/133 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: new high-speed USB device number 2 using ehci_hcd sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 firewire_core 0000:05:00.0: created device fw0: GUID 001e8c0000de9136, S400 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xen_map_pirq_gsi: returning irq 50 for gsi 50 Already setup the GSI :50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller hub 1-1:1.0: USB hub found usb usb8: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 1-1:1.0: 4 ports detected hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \_SB_.PCI0.SBRG.ASOC.SMRG 1 (20120320/utaddress-251) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ATK0110 ATK0110:00: EC enabled sp5100_tco: SP5100 TCO WatchDog Timer Driver v0.01 sp5100_tco: mmio address 0xb8fe00 already in use it87_wdt: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) xen_wdt: Xen WatchDog Timer Driver v0.01 xen_wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP: cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 11:19:10 UTC (1336389550) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. Freeing unused kernel memory: 532k freed Loading, please wait... udev[1078]: starting version 164 usb 4-2: new full-speed USB device number 2 using ohci_hcd usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 usb 1-1.1: new full-speed USB device number 4 using ehci_hcd Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 done. Begin: Running /scripts/local-premount ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 INIT: version 2.88 booting input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Using makefile-style concurrent boot in runlevel S.net firewire0: I Pv4 over IEEE 1394 on card 0000:05:00.0 firewire_core 0000:05:00.0: refreshed device fw0 Files under mount point '/lib/init/rw' will be hidden. ... (warning). Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1302]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 176617/1310720 files, 1280562/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2084): /proc/2084/oom_adj is deprecated, please use /proc/2084/oom_score_adj instead. Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting domain name service...: bind9. Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2253]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2253]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2253]: blktapctrl.c:861: couldn't open blktap interface BLKTAPCTRL[2253]: blktapctrl.c:924: Unable to start blktapctrl sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entered forwarding state br0: port 1(eth0) entered forwarding state Starting S.M.A.R.T. daemon: smartd. br0: port 1(eth0) entered forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_TX7pPqk9X0OyHh/-- From xen-devel-bounces@lists.xen.org Mon May 07 11:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 11:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMUV-0004Tp-AN; Mon, 07 May 2012 11:52:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRMUS-0004Td-HU for xen-devel@lists.xensource.com; Mon, 07 May 2012 11:52:33 +0000 Received: from [85.158.138.51:24643] by server-7.bemta-3.messagelabs.com id 1A/85-03078-F77B7AF4; Mon, 07 May 2012 11:52:31 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-7.tower-174.messagelabs.com!1336391140!16737548!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25933 invoked from network); 7 May 2012 11:45:40 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-7.tower-174.messagelabs.com with SMTP; 7 May 2012 11:45:40 -0000 Received: (qmail 31365 invoked from network); 7 May 2012 13:45:26 +0200 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; 7 May 2012 13:45:26 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: "xen-devel@lists.xensource.com" Date: Mon, 7 May 2012 13:45:23 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_TX7pPqk9X0OyHh/" Message-Id: <201205071345.23619.pavel@netsafe.cz> Subject: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm trying to run AMD VGA passthru on latest XEN unstable with latest kernel. I already have working setup with ancient xen-devel 4.2 and 2.6.32.x xenified kernel. See attached log. So I tried just to update and patch xen and kernel, but I had no luck so far. Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang recently. http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html I tried two kernels testing-3.5-with-extra and xen/next-3.2 from git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git and git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Both with ioperm opcode patch which is required by the ATI patch. See attachement. The xen/next-3.2 branch kernel was able to start booting windows. With Catalyst driver installed I just saw bluescreen during Windows boot. Without Catalyst driver Windows were able to boot but Windows ended frozen or USB was not working. It was hard to tell because input devices had no response at all. The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 kernel during Windows boot. I guess I have to rework the io_bitmap patch somehow. -- Pavel Mateja --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="2.6.32.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="2.6.32.log" __ __ _ _ ____ _ _ _ =20 \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___=20 \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| =20 (XEN) Xen version 4.2-unstable (root@netsafe.cz) (gcc version 4.4.5 (Debian= 4.4.5-8) ) Sun Feb 5 15:55:33 CET 2012 (XEN) Latest ChangeSet: Thu May 05 17:40:34 2011 +0100 23300:4b0692880dfa (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=3D2G dom0_max_vcpus=3D6 loglvl=3Da= ll guest_loglvl=3Dall sync_console com1=3D115200,8n1,0xac00 console=3Dcom1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.254 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =FF(XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is ena= bled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL =3D 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=3D0x1000000 memsz=3D0x77c000 (XEN) elf_parse_binary: phdr: paddr=3D0x177c000 memsz=3D0x8da88 (XEN) elf_parse_binary: phdr: paddr=3D0x180a000 memsz=3D0x8c8 (XEN) elf_parse_binary: phdr: paddr=3D0x180b000 memsz=3D0x14a58 (XEN) elf_parse_binary: phdr: paddr=3D0x1820000 memsz=3D0x212000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1a32000 (XEN) elf_xen_parse_note: GUEST_OS =3D "linux" (XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6" (XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff81820200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo= ve_4gb" (XEN) elf_xen_parse_note: PAE_MODE =3D "yes" (XEN) elf_xen_parse_note: LOADER =3D "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1 (XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base =3D 0xffffffff80000000 (XEN) elf_paddr_offset =3D 0x0 (XEN) virt_offset =3D 0xffffffff80000000 (XEN) virt_kstart =3D 0xffffffff81000000 (XEN) virt_kend =3D 0xffffffff81a32000 (XEN) virt_entry =3D 0xffffffff81820200 (XEN) p2m_base =3D 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a32000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506263 pages to b= e allocated) (XEN) Init. ramdisk: 000000022f997000->000000022ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a32000 (XEN) Init. ramdisk: ffffffff81a32000->ffffffff8209a600 (XEN) Phys-Mach map: ffffffff8209b000->ffffffff8249b000 (XEN) Start info: ffffffff8249b000->ffffffff8249b4b4 (XEN) Page tables: ffffffff8249c000->ffffffff824b3000 (XEN) Boot stack: ffffffff824b3000->ffffffff824b4000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81820200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8177c000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8177c000 -> 0xffffffff81809a88 (XEN) elf_load_binary: phdr 2 at 0xffffffff8180a000 -> 0xffffffff8180a8c8 (XEN) elf_load_binary: phdr 3 at 0xffffffff8180b000 -> 0xffffffff8181fa58 (XEN) elf_load_binary: phdr 4 at 0xffffffff81820000 -> 0xffffffff818b3000 (XEN) Scrubbing Free RAM: .................................................= =2E...........done. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1...=20 (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 236kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... ERROR: Unable to locate IOAPIC for GSI 2 ERROR: Unable to locate IOAPIC for GSI 9 (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010004 from 0x000024= a74db06404 to 0x0000000000000000. (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010000 from 0x000003= 061a0effc9 to 0x0000000000430076. ERROR: Unable to locate IOAPIC for GSI 9 (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 registering netback IT87 WDT: Unknown Chip found, Chip 8721 Revision 0001 [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. [Firmware Bug]: powernow-k8: Try again with latest BIOS. Loading, please wait... INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...udevd-work[1437]: kernel-provided = name 'blktap-control' and NAME=3D 'xen/blktap-2/control' disagree, please u= se SYMLINK+=3D or change the kernel to provide the proper name done. Setting preliminary keymap...done. Activating swap...done. Checking root file system...fsck from util-linux-ng 2.17.2 HOWTO_ROOT: clean, 95054/1419840 files, 731180/5679104 blocks (check in 4 m= ounts) done. Loading kernel modules...done. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take = a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active =2E Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Setting kernel variables ...done. Configuring network interfaces...done. Cleaning up temporary files.... Setting console screen modes. Rcannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. acpid: starting up with proc fs acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting periodic command scheduler: cron. Starting OpenBSD Secure Shell server: sshd. Starting xenstored...XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Setting domain 0 name... Starting xenconsoled... BLKTAPCTRL[2168]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2168]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2168]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2168]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2168]: blktapctrl.c:922: Unable to start blktapctrl (XEN) PCI remove device 00:12.2 (XEN) PCI add device 00:12.2 /usr/local/bin/xen_start.sh: line 15: /sys/bus/pci/devices/0000:07:00.0/dri= ver/unbind: No such file or directory Using config file "/etc/xen/windows". (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 Started domain windows (id=3D1)(XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:258: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM2: HVM Loader (XEN) HVM2: Detected Xen v4.2-unstable (XEN) HVM2: Xenbus rings @0xfeffc000, event channel 7 (XEN) HVM2: System requested ROMBIOS (XEN) HVM2: CPU speed is 3010 MHz (XEN) irq.c:258: Dom2 PCI link 0 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom2 PCI link 1 changed 0 -> 10 (XEN) HVM2: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom2 PCI link 2 changed 0 -> 11 (XEN) HVM2: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom2 PCI link 3 changed 0 -> 5 (XEN) HVM2: PCI-ISA link 3 routed to IRQ5 (XEN) HVM2: pci dev 01:3 INTA->IRQ10 (XEN) HVM2: pci dev 03:0 INTA->IRQ5 (XEN) HVM2: pci dev 04:0 INTA->IRQ5 (XEN) HVM2: pci dev 05:0 INTA->IRQ10 (XEN) HVM2: pci dev 06:0 INTB->IRQ5 (XEN) HVM2: pci dev 07:0 INTA->IRQ5 (XEN) HVM2: pci dev 08:0 INTB->IRQ10 (XEN) HVM2: pci dev 09:0 INTA->IRQ10 (XEN) HVM2: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM2: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM2: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM2: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM2: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM2: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM2: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM2: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM2: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM2: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM2: Multiprocessor initialisation: (XEN) HVM2: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM2: Testing HVM environment: (XEN) HVM2: - REP INSB across page boundaries ... passed (XEN) HVM2: - GS base MSRs and SWAPGS ... passed (XEN) HVM2: Passed 2 of 2 tests (XEN) HVM2: Writing SMBIOS tables ... (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM3: HVM Loader (XEN) HVM3: Detected Xen v4.2-unstable (XEN) HVM3: Xenbus rings @0xfeffc000, event channel 7 (XEN) HVM3: System requested ROMBIOS (XEN) HVM3: CPU speed is 3010 MHz (XEN) irq.c:258: Dom3 PCI link 0 changed 0 -> 5 (XEN) HVM3: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom3 PCI link 1 changed 0 -> 10 (XEN) HVM3: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom3 PCI link 2 changed 0 -> 11 (XEN) HVM3: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom3 PCI link 3 changed 0 -> 5 (XEN) HVM3: PCI-ISA link 3 routed to 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 05:0 INTA->IRQ10 (XEN) HVM3: pci dev 06:0 INTB->IRQ5 (XEN) HVM3: pci dev 07:0 INTA->IRQ5 (XEN) HVM3: pci dev 08:0 INTB->IRQ10 (XEN) HVM3: pci dev 09:0 INTA->IRQ10 (XEN) HVM3: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM3: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM3: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM3: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM3: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM3: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM3: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM3: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM3: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM3: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM3: Multiprocessor initialisation: (XEN) HVM3: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM3: Testing HVM environment: (XEN) HVM3: - REP INSB across page boundaries ... passed (XEN) HVM3: - GS base MSRs and SWAPGS ... passed (XEN) HVM3: Passed 2 of 2 tests (XEN) HVM3: Writing SMBIOS tables ... __ __ _ _ ____ _ _ _ =20 \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___=20 \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| =20 (XEN) Xen version 4.2-unstable (root@netsafe.cz) (gcc version 4.4.5 (Debian= 4.4.5-8) ) Sun Feb 5 15:55:33 CET 2012 (XEN) Latest ChangeSet: Thu May 05 17:40:34 2011 +0100 23300:4b0692880dfa (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=3D2G dom0_max_vcpus=3D6 loglvl=3Da= ll guest_loglvl=3Dall sync_console com1=3D115200,8n1,0xac00 console=3Dcom1 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.220 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Platform timer is 14.318MHz HPET =FF(XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging detected. (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is ena= bled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL =3D 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=3D0x1000000 memsz=3D0x77c000 (XEN) elf_parse_binary: phdr: paddr=3D0x177c000 memsz=3D0x8da88 (XEN) elf_parse_binary: phdr: paddr=3D0x180a000 memsz=3D0x8c8 (XEN) elf_parse_binary: phdr: paddr=3D0x180b000 memsz=3D0x14a58 (XEN) elf_parse_binary: phdr: paddr=3D0x1820000 memsz=3D0x212000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1a32000 (XEN) elf_xen_parse_note: GUEST_OS =3D "linux" (XEN) elf_xen_parse_note: GUEST_VERSION =3D "2.6" (XEN) elf_xen_parse_note: XEN_VERSION =3D "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE =3D 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY =3D 0xffffffff81820200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE =3D 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES =3D "!writable_page_tables|pae_pgdir_abo= ve_4gb" (XEN) elf_xen_parse_note: PAE_MODE =3D "yes" (XEN) elf_xen_parse_note: LOADER =3D "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL =3D 0x1 (XEN) elf_xen_parse_note: HV_START_LOW =3D 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET =3D 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base =3D 0xffffffff80000000 (XEN) elf_paddr_offset =3D 0x0 (XEN) virt_offset =3D 0xffffffff80000000 (XEN) virt_kstart =3D 0xffffffff81000000 (XEN) virt_kend =3D 0xffffffff81a32000 (XEN) virt_entry =3D 0xffffffff81820200 (XEN) p2m_base =3D 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a32000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506263 pages to b= e allocated) (XEN) Init. ramdisk: 000000022f997000->000000022ffff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a32000 (XEN) Init. ramdisk: ffffffff81a32000->ffffffff8209a600 (XEN) Phys-Mach map: ffffffff8209b000->ffffffff8249b000 (XEN) Start info: ffffffff8249b000->ffffffff8249b4b4 (XEN) Page tables: ffffffff8249c000->ffffffff824b3000 (XEN) Boot stack: ffffffff824b3000->ffffffff824b4000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81820200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8177c000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8177c000 -> 0xffffffff81809a88 (XEN) elf_load_binary: phdr 2 at 0xffffffff8180a000 -> 0xffffffff8180a8c8 (XEN) elf_load_binary: phdr 3 at 0xffffffff8180b000 -> 0xffffffff8181fa58 (XEN) elf_load_binary: phdr 4 at 0xffffffff81820000 -> 0xffffffff818b3000 (XEN) Scrubbing Free RAM: .................................................= =2E...........done. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1...=20 (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 236kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... ERROR: Unable to locate IOAPIC for GSI 2 ERROR: Unable to locate IOAPIC for GSI 9 (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4= a75df86514 to 0x0000000000000000. (XEN) traps.c:2405:d0 Domain attempted WRMSR 00000000c0010000 from 0x000003= 0e1b0effe9 to 0x0000000000430076. ERROR: Unable to locate IOAPIC for GSI 9 (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 registering netback IT87 WDT: Unknown Chip found, Chip 8721 Revision 0001 [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. [Firmware Bug]: powernow-k8: Try again with latest BIOS. Loading, please wait... INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...udevd-work[1429]: kernel-provided = name 'blktap-control' and NAME=3D 'xen/blktap-2/control' disagree, please u= se SYMLINK+=3D or change the kernel to provide the proper name done. Setting preliminary keymap...done. Activating swap...done. Checking root file system...fsck from util-linux-ng 2.17.2 HOWTO_ROOT: clean, 95056/1419840 files, 731207/5679104 blocks (check in 3 m= ounts) done. Loading kernel modules...done. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take = a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active =2E Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Setting kernel variables ...done. Configuring network interfaces...done. Cleaning up temporary files.... Setting console screen modes. Rcannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. acpid: starting up with proc fs acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting periodic command scheduler: cron. Starting OpenBSD Secure Shell server: sshd. Starting xenstored...XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Setting domain 0 name... Starting xenconsoled... BLKTAPCTRL[2156]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2156]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2156]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2156]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2156]: blktapctrl.c:922: Unable to start blktapctrl (XEN) PCI remove device 00:12.2 (XEN) PCI add device 00:12.2 /usr/local/bin/xen_start.sh: line 15: /sys/bus/pci/devices/0000:07:00.0/dri= ver/unbind: No such file or directory Using config file "/etc/xen/windows". (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3b0 f_mport=3D3b0 np=3Dc (XEN) domctl.c:986:d0 memory_map:add: gfn=3Da0 mfn=3Da0 nr_mfns=3D20 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c0 f_mport=3D3c0 np=3D3 (XEN) domctl.c:1042:d0 ioport_map:add f_gport=3D3c4 f_mport=3D3c4 np=3D1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 Started domain windows (id=3D1)(XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:258: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:258: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:258: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:258: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ...= done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc000000-0xfc0025bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://etherboot.org (XEN) HVM1: - Product name: gPXE (XEN) HVM1: Loading ACPI ... (XEN) HVM1: - Lo data: 000ea020-000ea04f (XEN) HVM1: - Hi data: fc002800-fc01291f (XEN) HVM1: vm86 TSS at fc012c00 (XEN) HVM1: BIOS map: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e1fff: Etherboot ROM (XEN) HVM1: eb000-eb20f: SMBIOS tables (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED (XEN) HVM1: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [04]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [06]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM=20 (XEN) HVM1:=20 (XEN) HVM1: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1:=20 (XEN) HVM1:=20 (XEN) HVM1:=20 (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1:=20 (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:258: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:258: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:258: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:258: Dom1 PCI link 3 changed 5 -> 0 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D= 10000 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D= 20 (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) grant_table.c:1156:d1 Expanding dom (1) grant table from (4) to (32) = frames. (XEN) irq.c:324: Dom1 callback via changed to GSI 28 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D= 10000 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D= 20 (XEN) domctl.c:986:d0 memory_map:add: gfn=3De0000 mfn=3Dd0000 nr_mfns=3D100= 00 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1020 mfn=3Dfe9e0 nr_mfns=3D20 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1068 mfn=3Dfe3f7 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1060 mfn=3Dfe9bc nr_mfns=3D4 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1069 mfn=3Df0000 nr_mfns=3D1 (XEN) domctl.c:996:d0 memory_map:remove: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 (XEN) domctl.c:986:d0 memory_map:add: gfn=3Df1064 mfn=3Dfe3f8 nr_mfns=3D4 --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="3.2.0-rc2.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="3.2.0-rc2.log" __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.225 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5b2000 (XEN) elf_parse_binary: phdr: paddr=0x15b2000 memsz=0x660e0 (XEN) elf_parse_binary: phdr: paddr=0x1619000 memsz=0x12500 (XEN) elf_parse_binary: phdr: paddr=0x162c000 memsz=0x21b000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1847000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff8162c200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81847000 (XEN) virt_entry = 0xffffffff8162c200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1847000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000226000000->0000000228000000 (514500 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81847000 (XEN) Init. ramdisk: ffffffff81847000->ffffffff81e82200 (XEN) Phys-Mach map: ffffffff81e83000->ffffffff82283000 (XEN) Start info: ffffffff82283000->ffffffff822834b4 (XEN) Page tables: ffffffff82284000->ffffffff82299000 (XEN) Boot stack: ffffffff82299000->ffffffff8229a000 (XEN) TOTAL: ffffffff80000000->ffffffff82400000 (XEN) ENTRY ADDRESS: ffffffff8162c200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815b2000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815b2000 -> 0xffffffff816180e0 (XEN) elf_load_binary: phdr 2 at 0xffffffff81619000 -> 0xffffffff8162b500 (XEN) elf_load_binary: phdr 3 at 0xffffffff8162c000 -> 0xffffffff816b2000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.2.0-rc2-11202-gd3507af-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 SMP PREEMPT Sat May 5 20:13:29 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 00000000cfe80000 (usable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (usable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01847000 - 01e83000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffb000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at 80000000 (gap: 80000000:4fe80000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4b000 s75008 r8192 d23296 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 514973 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975220k/2097152k available (4470k kernel code, 472k absent, 121460k reserved, 1768k data, 596k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Verbose stalled-CPUs detection is disabled. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.224 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.44 BogoMIPS (lpj=3010224) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 ACPI: Core revision 20110623 cpu 0 spinlock event irq 297 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 303 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 315 installing Xen timer for CPU 4 cpu 4 spinlock event irq 321 installing Xen timer for CPU 5 cpu 5 spinlock event irq 327 Brought up 6 CPUs devtmpfs: initialized Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M Extended Config Space enabled on 1 nodes ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 HEST: Table not found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] pci 0000:00:02.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:04.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:05.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 pci 0000:00:06.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 pci 0000:00:07.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 pci 0000:00:0d.0: PCI INT A -> GSI 54 (level, low) -> IRQ 54 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] ERST: Table is not found! GHES: HEST is not enabled! Event-channel device installed. pciback 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pciback 0000:00:14.2: PCI INT A disabled xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:02:00.0: PCI INT A -> GSI 40 (level, low) -> IRQ 40 serial 0000:02:00.1: PCI INT B -> GSI 41 (level, low) -> IRQ 41 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata1: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: PCI INT A -> GSI 44 (level, low) -> IRQ 44 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata7: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.29 sky2 0000:04:00.0: PCI INT A -> GSI 51 (level, low) -> IRQ 51 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 cdc_ncm: 04-Aug-2011 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46 firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata5: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 ata7: SATA link down (SStatus 0 SControl 300) ata8: SATA link down (SStatus 0 SControl 300) usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver sda: sda1 sda2 ohci_hcd 0000:00:12.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb 1-1: new high-speed USB device number 2 using ehci_hcd usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected firewire_core: created device fw0: GUID 001e8c0000de9136, S400 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xhci_hcd 0000:03:00.0: PCI INT A -> GSI 50 (level, low) -> IRQ 50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 ATK0110 ATK0110:00: EC enabled SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 SP5100 TCO timer: mmio address 0xb8fe00 already in use IT87 WDT: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) wdt: Xen WatchDog Timer Driver v0.01 wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 usb 4-2: new full-speed USB device number 2 using ohci_hcd EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 11:07:15 UTC (1336388835) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. powernow-k8: invalid pstate 1 - bad value 1. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 2 - bad value 2. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 3 - bad value 3. powernow-k8: Please report to BIOS manufacturer [Firmware Bug]: powernow-k8: invalid powernow_table Freeing unused kernel memory: 596k freed Loading, please wait... udev[1087]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/local-premount ... done. EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 done. INIT: version 2.88 booting usb 1-1.2: new low-speed USB device number 5 using ehci_hcd Using makefile-style concurrent boot in runlevel S. Files under mount point '/lib/init/rw' will be hidden. ... (warning). usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony Files under mount point '/var/run' will be hidden. ...input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 (warning). input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 firewire_net: firewire0: IPv4 over FireWire on device 001e8c0000de9136 firewire_core: refreshed device fw0 Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1296]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 175647/1310720 files, 1276770/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. Starting the Winbind daemon: winbind.sshd (2066): /pr oc/2066/oom_adj is deprecated, please use /proc/2066/oom_score_adj instead. XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting OpenBSD Secure Shell server: sshd. Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2231]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2231]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2231]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2231]: blktapctrl.c:861: couldn't open blktap interface BLKTAPCTRL[2231]: blktapctrl.c:924: Unable to start blktapctrl Starting S.M.A.R.T. daemon: smartd. sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 [CPU0] failed to set governor name [CPU1] failed to set governor name [CPU2] failed to set governor name [CPU3] failed to set governor name [CPU4] failed to set governor name [CPU5] failed to set governor name . acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0701, fault address = 0x9db44000 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x00a2, fault address = 0x9debe000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa94324e0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa94324b0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432510 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9508a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab040 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab0c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab100 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab140 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab180 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab1c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab200 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab240 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab280 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab2c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab300 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab340 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab340 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab380 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab380 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab3c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0700, fault address = 0x9d7ab3c0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa950ea80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0090, fault address = 0xa9526460 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96f6a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa950ea80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9538a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9402a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9402a80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96fca80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9432a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9526a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa952ca30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa9514a30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa961aa30 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 1, device id = 0x0092, fault address = 0xa96fca80 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80040 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80080 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xdfe80000 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0090, fault address = 0xffffffc0 --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-patch; charset="ISO-8859-1"; name="ioperm.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ioperm.patch" diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index aa0f913..259ef7f 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, int entry, const gate_desc *g) { PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); } + static inline void set_iopl_mask(unsigned mask) { PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); } +static inline void set_io_bitmap(struct thread_struct *thread, + unsigned long bytes_updated) +{ + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); +} + /* The paravirtualized I/O functions */ static inline void slow_down_io(void) { diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..96f267c 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -142,6 +142,8 @@ struct pv_cpu_ops { void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); void (*set_iopl_mask)(unsigned mask); + void (*set_io_bitmap)(struct thread_struct *thread, + unsigned long bytes_updated); void (*wbinvd)(void); void (*io_delay)(void); diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 4fa7dcc..62becce 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned mask) #endif } +extern void native_set_io_bitmap(struct thread_struct *thread, + unsigned long updated_bytes); + static inline void native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) { @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, } #define set_iopl_mask native_set_iopl_mask +#define set_io_bitmap native_set_io_bitmap #endif /* CONFIG_PARAVIRT */ /* diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c index 8c96897..c372ef0 100644 --- a/arch/x86/kernel/ioport.c +++ b/arch/x86/kernel/ioport.c @@ -17,13 +17,29 @@ #include #include +void native_set_io_bitmap(struct thread_struct *t, + unsigned long bytes_updated) +{ + struct tss_struct *tss; + + if (!bytes_updated) + return; + + tss = &__get_cpu_var(init_tss); + + /* Update the TSS: */ + if (t->io_bitmap_ptr) + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); + else + memset(tss->io_bitmap, 0xff, bytes_updated); +} + /* * this changes the io permissions bitmap in the current task. */ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) { struct thread_struct *t = ¤t->thread; - struct tss_struct *tss; unsigned int i, max_long, bytes, bytes_updated; if ((from + num <= from) || (from + num > IO_BITMAP_BITS)) @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) } /* - * do it in the per-thread copy and in the TSS ... + * do it in the per-thread copy * - * Disable preemption via get_cpu() - we must not switch away + * Disable preemption - we must not switch away * because the ->io_bitmap_max value must match the bitmap * contents: */ - tss = &per_cpu(init_tss, get_cpu()); + preempt_disable(); if (turn_on) bitmap_clear(t->io_bitmap_ptr, from, num); @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) t->io_bitmap_max = bytes; - /* Update the TSS: */ - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); + set_io_bitmap(t, bytes_updated); - put_cpu(); + preempt_enable(); return 0; } diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index ab13760..aa420e7 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops = { .swapgs = native_swapgs, .set_iopl_mask = native_set_iopl_mask, + .set_io_bitmap = native_set_io_bitmap, .io_delay = native_io_delay, .start_context_switch = paravirt_nop, diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 1d92a5a..e8436cc 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -91,16 +91,12 @@ void exit_thread(void) unsigned long *bp = t->io_bitmap_ptr; if (bp) { - struct tss_struct *tss = &per_cpu(init_tss, get_cpu()); - + preempt_disable(); t->io_bitmap_ptr = NULL; clear_thread_flag(TIF_IO_BITMAP); - /* - * Careful, clear this in the TSS too: - */ - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); + set_io_bitmap(t, t->io_bitmap_max); t->io_bitmap_max = 0; - put_cpu(); + preempt_enable(); kfree(bp); } } @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p, hard_enable_TSC(); } - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { - /* - * Copy the relevant range of the IO bitmap. - * Normally this is 128 bytes or less: - */ - memcpy(tss->io_bitmap, next->io_bitmap_ptr, - max(prev->io_bitmap_max, next->io_bitmap_max)); - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { - /* - * Clear any possible leftover bits: - */ - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); - } + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) + set_io_bitmap(next, + max(prev->io_bitmap_max, next->io_bitmap_max)); + propagate_user_return_notify(prev_p, next_p); } diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 8853204..7a05509 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); } +static void xen_set_io_bitmap(struct thread_struct *thread, + int changed, unsigned long bytes_updated) +{ + struct physdev_set_iobitmap set_iobitmap; + + set_xen_guest_handle(set_iobitmap.bitmap, + (char *)thread->io_bitmap_ptr); + set_iobitmap.nr_ports = thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, + &set_iobitmap)); +} + static void xen_io_delay(void) { } @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = { .load_sp0 = xen_load_sp0, .set_iopl_mask = xen_set_iopl_mask, + .set_io_bitmap = xen_set_io_bitmap, .io_delay = xen_io_delay, /* Xen takes care of %gs when switching to usermode for us */ --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/x-log; charset="ISO-8859-1"; name="3.4.0-rc4.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="3.4.0-rc4.log" __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.238 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5d3000 (XEN) elf_parse_binary: phdr: paddr=0x15d3000 memsz=0x6e0e8 (XEN) elf_parse_binary: phdr: paddr=0x1642000 memsz=0x12980 (XEN) elf_parse_binary: phdr: paddr=0x1655000 memsz=0x4ff000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1b54000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81655200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81b54000 (XEN) virt_entry = 0xffffffff81655200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b54000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506308 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81b54000 (XEN) Init. ramdisk: ffffffff81b54000->ffffffff8218f200 (XEN) Phys-Mach map: ffffffff82190000->ffffffff82590000 (XEN) Start info: ffffffff82590000->ffffffff825904b4 (XEN) Page tables: ffffffff82591000->ffffffff825a8000 (XEN) Boot stack: ffffffff825a8000->ffffffff825a9000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81655200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815d3000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815d3000 -> 0xffffffff816410e8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81642000 -> 0xffffffff81654980 (XEN) elf_load_binary: phdr 3 at 0xffffffff81655000 -> 0xffffffff816cc000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc4-00395-g87b5d90-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #5 SMP PREEMPT Sat May 5 19:29:42 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping Populating 80000-80066 pfn range: 102 pages added BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000080066000 (usable) Xen: 0000000080066000 - 00000000cfe80000 (unusable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (unusable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 0000000080066000 - 00000000cfe80000 (unusable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) user: 0000000100000000 - 0000000230000000 (unusable) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01b54000 - 02190000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffc000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 253, address 0xfec20000, GSI 24-277 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at cff00000 (gap: cff00000:2ed00000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4c000 s76160 r8192 d22144 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 515976 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975064k/2097152k available (4567k kernel code, 472k absent, 121616k reserved, 1833k data, 532k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Dump stacks of tasks blocking RCU-preempt GP. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.238 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.47 BogoMIPS (lpj=3010238) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks ACPI: Core revision 20120320 cpu 0 spinlock event irq 295 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 302 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 316 installing Xen timer for CPU 4 cpu 4 spinlock event irq 323 installing Xen timer for CPU 5 cpu 5 spinlock event irq 330 Brought up 6 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff] pci_bus 0000:00: root bus resource [mem 0xcff00000-0xdfffffff] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: CPU0: patch_level=0x010000bf microcode: CPU1: patch_level=0x010000bf microcode: CPU2: patch_level=0x010000bf microcode: CPU3: patch_level=0x010000bf microcode: CPU4: patch_level=0x010000bf microcode: CPU5: patch_level=0x010000bf microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] GHES: HEST is not enabled! Event-channel device installed. xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata7: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata9: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.30 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:16.2: debug port 1 ata7: SATA link down (SStatus 0 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata2.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata9: SATA link down (SStatus 0 SControl 300) ata8: SATA link down (SStatus 0 SControl 300) ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ata2.00: configured for UDMA/133 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb 1-1: new high-speed USB device number 2 using ehci_hcd usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: OHCI Host Controller firewire_core 0000:05:00.0: created device fw0: GUID 001e8c0000de9136, S400 ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xen_map_pirq_gsi: returning irq 50 for gsi 50 Already setup the GSI :50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \_SB_.PCI0.SBRG.ASOC.SMRG 1 (20120320/utaddress-251) usb 4-2: new full-speed USB device number 2 using ohci_hcd ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ATK0110 ATK0110:00: EC enabled sp5100_tco: SP5100 TCO WatchDog Timer Driver v0.01 sp5100_tco: mmio address 0xb8fe00 already in use it87_wdt: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) xen_wdt: Xen WatchDog Timer Driver v0.01 xen_wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP: cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 10:55:22 UTC (1336388122) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. Freeing unused kernel memory: 532k freed Loading, please wait... udev[1078]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer done. input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 Begin: Running /scripts/local-premount ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony INIT: version 2.88 booting input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 Using makefile-style concurrent boot in runlevel S.input: Chicony U SB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Files under mount point '/lib/init/rw' will be hidden. ...net firewire0: IPv4 over IEEE 1394 on card 0000:05:00.0 firewire_core 0000:05:00.0: refreshed device fw0 (warning). Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1286]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 175647/1310720 files, 1276635/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2064): /proc/2064/oom_adj is deprecated, please use /proc/2064/oom_score_adj instead. Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2234]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2234]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2234]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2234]: blktapctrl.c:861: couldn't open blktap interfacesky2 0000:04:00. 0: eth0: Link is up at 100 Mbps, full duplex, flow control both BLKTAPCTRL[2234]: blktapctrl.c:924: Unable to start blktapctrlbr0: port 1(eth0 ) entered forwarding state br0: port 1(eth0) entered forwarding state Starting S.M.A.R.T. daemon: smartd. br0: port 1(eth0) entered forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. __ __ _ _ ____ _ _ _ \ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)_____| \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.2-unstable (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Sat May 5 15:48:48 CEST 2012 (XEN) Latest ChangeSet: Fri May 04 11:18:48 2012 +0100 25259:0f53540494f7 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) Table is not found! (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (2 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.254 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) Brought up 6 CPUs (XEN) microcode: collect_cpu_info: patch_id=0x10000bf (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5d3000 (XEN) elf_parse_binary: phdr: paddr=0x15d3000 memsz=0x6e0e8 (XEN) elf_parse_binary: phdr: paddr=0x1642000 memsz=0x12980 (XEN) elf_parse_binary: phdr: paddr=0x1655000 memsz=0x4ff000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1b54000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81655200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81b54000 (XEN) virt_entry = 0xffffffff81655200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b54000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000224000000->0000000228000000 (506308 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81b54000 (XEN) Init. ramdisk: ffffffff81b54000->ffffffff8218f200 (XEN) Phys-Mach map: ffffffff82190000->ffffffff82590000 (XEN) Start info: ffffffff82590000->ffffffff825904b4 (XEN) Page tables: ffffffff82591000->ffffffff825a8000 (XEN) Boot stack: ffffffff825a8000->ffffffff825a9000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff81655200 (XEN) Dom0 has maximum 6 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815d3000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815d3000 -> 0xffffffff816410e8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81642000 -> 0xffffffff81654980 (XEN) elf_load_binary: phdr 3 at 0xffffffff81655000 -> 0xffffffff816cc000 (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 256kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc4-00395-g87b5d90-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #7 SMP PREEMPT Mon May 7 13:16:10 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping Populating 80000-80066 pfn range: 102 pages added BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000080066000 (usable) Xen: 0000000080066000 - 00000000cfe80000 (unusable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (unusable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 0000000080066000 - 00000000cfe80000 (unusable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) user: 0000000100000000 - 0000000230000000 (unusable) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01b54000 - 02190000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffc000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 253, address 0xfec20000, GSI 24-277 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at cff00000 (gap: cff00000:2ed00000) Booting paravirtualized kernel on Xen Xen version: 4.2-unstable (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4c000 s76160 r8192 d22144 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 515976 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975064k/2097152k available (4567k kernel code, 472k absent, 121616k reserved, 1833k data, 532k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Dump stacks of tasks blocking RCU-preempt GP. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.254 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.50 BogoMIPS (lpj=3010254) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks ACPI: Core revision 20120320 cpu 0 spinlock event irq 295 Performance Events: (XEN) traps.c:2561:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000e4a75df86514 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 302 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 316 installing Xen timer for CPU 4 cpu 4 spinlock event irq 323 installing Xen timer for CPU 5 cpu 5 spinlock event irq 330 Brought up 6 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff] pci_bus 0000:00: root bus resource [mem 0xcff00000-0xdfffffff] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:00.2 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:05.0 (XEN) PCI add device 0000:00:06.0 (XEN) PCI add device 0000:00:07.0 (XEN) PCI add device 0000:00:0d.0 (XEN) PCI add device 0000:00:11.0 (XEN) PCI add device 0000:00:12.0 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.0 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:14.3 (XEN) PCI add device 0000:00:14.4 (XEN) PCI add device 0000:00:14.5 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.2 (XEN) PCI add device 0000:00:18.0 (XEN) PCI add device 0000:00:18.1 (XEN) PCI add device 0000:00:18.2 (XEN) PCI add device 0000:00:18.3 (XEN) PCI add device 0000:00:18.4 (XEN) PCI add device 0000:07:00.0 (XEN) PCI add device 0000:07:00.1 (XEN) PCI add device 0000:06:00.0 (XEN) PCI add device 0000:06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 0000:05:00.0 (XEN) PCI add device 0000:04:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP: reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: CPU0: patch_level=0x010000bf microcode: CPU1: patch_level=0x010000bf microcode: CPU2: patch_level=0x010000bf microcode: CPU3: patch_level=0x010000bf microcode: CPU4: patch_level=0x010000bf microcode: CPU5: patch_level=0x010000bf microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] GHES: HEST is not enabled! Event-channel device installed. xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata7: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata9: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.30 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata5: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata8: SATA link down (SStatus 0 SControl 300) hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 ata9: SATA link down (SStatus 0 SControl 300) ata7: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata2.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) ata6: SATA link down (SStatus 0 SControl 300) usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 ata2.00: configured for UDMA/133 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: new high-speed USB device number 2 using ehci_hcd sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 firewire_core 0000:05:00.0: created device fw0: GUID 001e8c0000de9136, S400 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xen_map_pirq_gsi: returning irq 50 for gsi 50 Already setup the GSI :50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller hub 1-1:1.0: USB hub found usb usb8: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 1-1:1.0: 4 ports detected hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.4.0-rc4-00395-g87b5d90-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver ACPI Warning: 0x0000000000000b00-0x0000000000000b07 SystemIO conflicts with Region \_SB_.PCI0.SBRG.ASOC.SMRG 1 (20120320/utaddress-251) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ATK0110 ATK0110:00: EC enabled sp5100_tco: SP5100 TCO WatchDog Timer Driver v0.01 sp5100_tco: mmio address 0xb8fe00 already in use it87_wdt: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) xen_wdt: Xen WatchDog Timer Driver v0.01 xen_wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP: cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 11:19:10 UTC (1336389550) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. Freeing unused kernel memory: 532k freed Loading, please wait... udev[1078]: starting version 164 usb 4-2: new full-speed USB device number 2 using ohci_hcd usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 usb 1-1.1: new full-speed USB device number 4 using ehci_hcd Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 done. Begin: Running /scripts/local-premount ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 INIT: version 2.88 booting input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Using makefile-style concurrent boot in runlevel S.net firewire0: I Pv4 over IEEE 1394 on card 0000:05:00.0 firewire_core 0000:05:00.0: refreshed device fw0 Files under mount point '/lib/init/rw' will be hidden. ... (warning). Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). Starting the hotplug events dispatcher: udevdudev[1302]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 176617/1310720 files, 1280562/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2084): /proc/2084/oom_adj is deprecated, please use /proc/2084/oom_score_adj instead. Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting domain name service...: bind9. Starting oxenstored... Setting domain 0 name... Starting xenconsoled... Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2253]: blktapctrl.c:792: blktapctrl: v1.0.0 BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [raw image (aio)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [raw image (sync)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2253]: blktapctrl.c:794: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2253]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2253]: blktapctrl.c:861: couldn't open blktap interface BLKTAPCTRL[2253]: blktapctrl.c:924: Unable to start blktapctrl sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entered forwarding state br0: port 1(eth0) entered forwarding state Starting S.M.A.R.T. daemon: smartd. br0: port 1(eth0) entered forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 0000:00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 0000:00:13.2 (XEN) PCI remove device 0000:00:16.2 (XEN) PCI add device 0000:00:12.2 (XEN) PCI add device 0000:00:13.2 (XEN) PCI add device 0000:00:16.2 . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) ioport_map:add: dom1 gport=3b0 mport=3b0 nr=c (XEN) memory_map:add: dom1 gfn=a0 mfn=a0 nr=20 (XEN) ioport_map:add: dom1 gport=3c0 mport=3c0 nr=3 (XEN) ioport_map:add: dom1 gport=3c4 mport=3c4 nr=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.2-unstable (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 8 (XEN) HVM1: System requested ROMBIOS (XEN) HVM1: CPU speed is 3010 MHz (XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc001000-0xfc0035bc ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://ipxe.org (XEN) HVM1: - Product name: iPXE (XEN) HVM1: Option ROMs: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e0fff: Etherboot ROM (XEN) HVM1: Loading ACPI ... (XEN) HVM1: vm86 TSS at fc00f700 (XEN) HVM1: BIOS map: (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [03]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [05]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0 (XEN) memory_map:remove: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:remove: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:add: dom1 gfn=e0000 mfn=d0000 nr=10000 (XEN) memory_map:add: dom1 gfn=f1020 mfn=fe9e0 nr=20 (XEN) memory_map:remove: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:add: dom1 gfn=f1060 mfn=fe9bc nr=4 (XEN) memory_map:remove: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:add: dom1 gfn=f1068 mfn=fe3f7 nr=1 (XEN) memory_map:remove: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:add: dom1 gfn=f1069 mfn=f0000 nr=1 (XEN) memory_map:remove: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) memory_map:add: dom1 gfn=f1064 mfn=fe3f8 nr=4 (XEN) grant_table.c:1174:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:350: Dom1 callback via changed to GSI 28 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. --Boundary-00=_TX7pPqk9X0OyHh/ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_TX7pPqk9X0OyHh/-- From xen-devel-bounces@lists.xen.org Mon May 07 12:59:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 12:59:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNWk-0005Dt-9y; Mon, 07 May 2012 12:58:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNWi-0005Do-Ny for xen-devel@lists.xen.org; Mon, 07 May 2012 12:58:56 +0000 Received: from [85.158.138.51:63645] by server-8.bemta-3.messagelabs.com id 0F/6F-24428-F07C7AF4; Mon, 07 May 2012 12:58:55 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336395535!25657087!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2398 invoked from network); 7 May 2012 12:58:55 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 12:58:55 -0000 Received: by eekc4 with SMTP id c4so982004eek.32 for ; Mon, 07 May 2012 05:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=HLfxlSP/4ayX/4nGyiPyzsjaJn06IeXnQfTKhofpwGo=; b=ECHTCZ/fAbWchuloRY+g678uSZQDFg1OeWaO/EkCb5Uu0Gm2CHyuEVQGOY2P4HVCx9 mnIYTVaLcER6NrmDK6ksJKI/LeG/EYXxeV9GBEgkExbczHoJr4ZJYRAS+CDfI4lM8C5m PvKahOVI0y34H6a0B4D3+/1CEQmqlA2ZNG1IpdasT77VEvU4FZYE7HFXIsk+JqZt6BnM Ff8m2+VCSdgQ42ZIh66lQiaTSDT4eNknYnJIm1CGSpjd3iwAyrmHwuZskaxhAfWm14nr duAZpM3dah8ljQhOdS1jF6nDRzMX6239c5t3Rputb0dQJCet4R4iU1OYIppIV+F3YBxO rKnQ== Received: by 10.14.188.7 with SMTP id z7mr133532eem.91.1336395534927; Mon, 07 May 2012 05:58:54 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id e56sm85864614eea.11.2012.05.07.05.58.53 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 05:58:54 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 13:58:44 +0100 From: Keir Fraser To: Message-ID: Thread-Topic: [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0sUSIeI+CnfYpUDkCPlH/iMq0O9w== Mime-version: 1.0 Subject: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Folks, I have just tagged first release candidates for 4.0.4 and 4.1.3: http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 12:59:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 12:59:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNWk-0005Dt-9y; Mon, 07 May 2012 12:58:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNWi-0005Do-Ny for xen-devel@lists.xen.org; Mon, 07 May 2012 12:58:56 +0000 Received: from [85.158.138.51:63645] by server-8.bemta-3.messagelabs.com id 0F/6F-24428-F07C7AF4; Mon, 07 May 2012 12:58:55 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336395535!25657087!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2398 invoked from network); 7 May 2012 12:58:55 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 12:58:55 -0000 Received: by eekc4 with SMTP id c4so982004eek.32 for ; Mon, 07 May 2012 05:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=HLfxlSP/4ayX/4nGyiPyzsjaJn06IeXnQfTKhofpwGo=; b=ECHTCZ/fAbWchuloRY+g678uSZQDFg1OeWaO/EkCb5Uu0Gm2CHyuEVQGOY2P4HVCx9 mnIYTVaLcER6NrmDK6ksJKI/LeG/EYXxeV9GBEgkExbczHoJr4ZJYRAS+CDfI4lM8C5m PvKahOVI0y34H6a0B4D3+/1CEQmqlA2ZNG1IpdasT77VEvU4FZYE7HFXIsk+JqZt6BnM Ff8m2+VCSdgQ42ZIh66lQiaTSDT4eNknYnJIm1CGSpjd3iwAyrmHwuZskaxhAfWm14nr duAZpM3dah8ljQhOdS1jF6nDRzMX6239c5t3Rputb0dQJCet4R4iU1OYIppIV+F3YBxO rKnQ== Received: by 10.14.188.7 with SMTP id z7mr133532eem.91.1336395534927; Mon, 07 May 2012 05:58:54 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id e56sm85864614eea.11.2012.05.07.05.58.53 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 05:58:54 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 13:58:44 +0100 From: Keir Fraser To: Message-ID: Thread-Topic: [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0sUSIeI+CnfYpUDkCPlH/iMq0O9w== Mime-version: 1.0 Subject: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Folks, I have just tagged first release candidates for 4.0.4 and 4.1.3: http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:06:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:06:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNdp-0005Rk-7c; Mon, 07 May 2012 13:06:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNdn-0005Rf-Pl for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:06:15 +0000 Received: from [85.158.143.35:8568] by server-3.bemta-4.messagelabs.com id 43/F1-05853-7C8C7AF4; Mon, 07 May 2012 13:06:15 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1336395970!9970661!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15966 invoked from network); 7 May 2012 13:06:11 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 13:06:11 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (jored mo38) (RZmta 29.4 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j058efo47CHrbn ; Mon, 7 May 2012 15:06:07 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 7741D18637; Mon, 7 May 2012 15:06:06 +0200 (CEST) Date: Mon, 7 May 2012 15:06:06 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120507130605.GA781@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, Ian Campbell wrote: > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > # HG changeset patch > > > > # User Olaf Hering > > > > # Date 1336159720 -7200 > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > xl.cfg: document the maxmem= option > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > --- a/docs/man/xl.cfg.pod.5 > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > mode) and your guest workload consists of a a very large number of > > > > similar processes then increasing this value may improve performance. > > > > > > > > +=item B > > > > + > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > > > Isn't it also for PV guests (though without the PoD functionality)? > > > > Now that I look again at libxl__build_pre(), it appearently does also > > something for PV guests. > > Right. Some people call this booting "pre-ballooned". Essentially n PV > the balloon driver can be initialised early enough that something like > PoD is not required -- the missing pages are just incorporated directly > into the balloon. What about this wording? Specifies the maximum amount of memory a guest can ever see. The value of maxmem= must be equal or greater than memory=. In combination with the memory= option it will start the guest "pre-ballooned". In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ. The guest needs a balloon driver in this case, without a balloon driver it will crash. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:06:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:06:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNdp-0005Rk-7c; Mon, 07 May 2012 13:06:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRNdn-0005Rf-Pl for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:06:15 +0000 Received: from [85.158.143.35:8568] by server-3.bemta-4.messagelabs.com id 43/F1-05853-7C8C7AF4; Mon, 07 May 2012 13:06:15 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1336395970!9970661!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15966 invoked from network); 7 May 2012 13:06:11 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 13:06:11 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (jored mo38) (RZmta 29.4 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j058efo47CHrbn ; Mon, 7 May 2012 15:06:07 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 7741D18637; Mon, 7 May 2012 15:06:06 +0200 (CEST) Date: Mon, 7 May 2012 15:06:06 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120507130605.GA781@aepfle.de> References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, Ian Campbell wrote: > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > # HG changeset patch > > > > # User Olaf Hering > > > > # Date 1336159720 -7200 > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > xl.cfg: document the maxmem= option > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > --- a/docs/man/xl.cfg.pod.5 > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > mode) and your guest workload consists of a a very large number of > > > > similar processes then increasing this value may improve performance. > > > > > > > > +=item B > > > > + > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > > > Isn't it also for PV guests (though without the PoD functionality)? > > > > Now that I look again at libxl__build_pre(), it appearently does also > > something for PV guests. > > Right. Some people call this booting "pre-ballooned". Essentially n PV > the balloon driver can be initialised early enough that something like > PoD is not required -- the missing pages are just incorporated directly > into the balloon. What about this wording? Specifies the maximum amount of memory a guest can ever see. The value of maxmem= must be equal or greater than memory=. In combination with the memory= option it will start the guest "pre-ballooned". In a HVM guest it will enable the PoD (populate on demand) mode, iff the values of memory= and maxmem= differ. The guest needs a balloon driver in this case, without a balloon driver it will crash. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:35:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRO5A-0005gC-QZ; Mon, 07 May 2012 13:34:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRO58-0005g4-Ru for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:34:31 +0000 Received: from [85.158.143.99:13991] by server-2.bemta-4.messagelabs.com id 9D/30-17550-66FC7AF4; Mon, 07 May 2012 13:34:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336397669!20456825!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1193 invoked from network); 7 May 2012 13:34:29 -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; 7 May 2012 13:34:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 14:34:28 +0100 Message-Id: <4FA7EB80020000780008204B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 14:34:24 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> In-Reply-To: <4FA7B6EF.9030403@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 13:50, Andrew Cooper wrote: > On 07/05/2012 09:10, Jan Beulich wrote: >>>>> On 05.05.12 at 02:21, AP wrote: >>> (XEN) *** IRQ BUG found *** >>> (XEN) CPU0 -Testing vector 236 from bitmap >> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming >> in through the 8259A. Something fundamentally fishy must be going >> on here, and I would suppose the code in question shouldn't even be >> reached for legacy vectors. >> >> Furthermore, calling dump_irqs() from the debugging code with >> desc->lock still held makes it impossible to get full output, as that >> function wants to lock all initialized IRQ descriptors. > > Yes - it has been vector 236 on each of the 3 reported failures from AP, > and I believe it was also vector 236 in the one case I managed to > reproduce the issue. > > However, once we have set up the IO-APIC, the 8259A should not be used > any more. The boot dmeg shows that io_ack_method is indeed "old" (which > was going to be my first suggestion), and that EOI Broadcast Suppression > is enabled, which I have already identified as a source of problems for > some customers. As a 'fix', I provided the ability for > "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. > This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not > completely fixed the customer problems - just made it substantially more > rare. > > AP: Can you manually invoke the 'i' debug key and provide that - it will > help to see how Xen is setting up the IO-APIC(s) on your system. Seeing the 'z' output might also be helpful, especially to see whether any of the IO-APICs' RTEs is an ExtINT one. Further, checking that no 8259A IRQ got (or was left) enabled for some reason might be useful as well (cached_irq_mask plus the raw port 0x21 and 0xA1 values). In any case the debugging code's locking should be fixed. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:35:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRO5A-0005gC-QZ; Mon, 07 May 2012 13:34:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRO58-0005g4-Ru for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:34:31 +0000 Received: from [85.158.143.99:13991] by server-2.bemta-4.messagelabs.com id 9D/30-17550-66FC7AF4; Mon, 07 May 2012 13:34:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336397669!20456825!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1193 invoked from network); 7 May 2012 13:34:29 -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; 7 May 2012 13:34:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 14:34:28 +0100 Message-Id: <4FA7EB80020000780008204B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 14:34:24 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> In-Reply-To: <4FA7B6EF.9030403@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 13:50, Andrew Cooper wrote: > On 07/05/2012 09:10, Jan Beulich wrote: >>>>> On 05.05.12 at 02:21, AP wrote: >>> (XEN) *** IRQ BUG found *** >>> (XEN) CPU0 -Testing vector 236 from bitmap >> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming >> in through the 8259A. Something fundamentally fishy must be going >> on here, and I would suppose the code in question shouldn't even be >> reached for legacy vectors. >> >> Furthermore, calling dump_irqs() from the debugging code with >> desc->lock still held makes it impossible to get full output, as that >> function wants to lock all initialized IRQ descriptors. > > Yes - it has been vector 236 on each of the 3 reported failures from AP, > and I believe it was also vector 236 in the one case I managed to > reproduce the issue. > > However, once we have set up the IO-APIC, the 8259A should not be used > any more. The boot dmeg shows that io_ack_method is indeed "old" (which > was going to be my first suggestion), and that EOI Broadcast Suppression > is enabled, which I have already identified as a source of problems for > some customers. As a 'fix', I provided the ability for > "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. > This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not > completely fixed the customer problems - just made it substantially more > rare. > > AP: Can you manually invoke the 'i' debug key and provide that - it will > help to see how Xen is setting up the IO-APIC(s) on your system. Seeing the 'z' output might also be helpful, especially to see whether any of the IO-APICs' RTEs is an ExtINT one. Further, checking that no 8259A IRQ got (or was left) enabled for some reason might be useful as well (cached_irq_mask plus the raw port 0x21 and 0xA1 values). In any case the debugging code's locking should be fixed. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:46:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:46:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROGV-0005qf-2U; Mon, 07 May 2012 13:46:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROGS-0005qa-CN for xen-devel@lists.xen.org; Mon, 07 May 2012 13:46:13 +0000 Received: from [85.158.138.51:32039] by server-1.bemta-3.messagelabs.com id FE/96-11491-322D7AF4; Mon, 07 May 2012 13:46:11 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-9.tower-174.messagelabs.com!1336398367!25727830!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2801 invoked from network); 7 May 2012 13:46:08 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-9.tower-174.messagelabs.com with SMTP; 7 May 2012 13:46:08 -0000 Received: (qmail 8046 invoked from network); 7 May 2012 15:46:04 +0200 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; 7 May 2012 15:46:04 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Mon, 7 May 2012 15:46:03 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> In-Reply-To: <201205071345.23619.pavel@netsafe.cz> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_bI9pPLDXbMX40PR" Message-Id: <201205071546.03637.pavel@netsafe.cz> Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_bI9pPLDXbMX40PR Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon 7. of May 2012 13:45:23 Pavel Mat=C4=9Bja wrote: > Hi, > I'm trying to run AMD VGA passthru on latest XEN unstable with latest > kernel. I already have working setup with ancient xen-devel 4.2 and > 2.6.32.x xenified kernel. See attached log. >=20 > So I tried just to update and patch xen and kernel, but I had no luck so > far. >=20 > Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang recentl= y. > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html >=20 > I tried two kernels > testing-3.5-with-extra and xen/next-3.2 from > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > and > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > Both with ioperm opcode patch which is required by the ATI patch. See > attachement. >=20 > The xen/next-3.2 branch kernel was able to start booting windows. > With Catalyst driver installed I just saw bluescreen during Windows boot. > Without Catalyst driver Windows were able to boot but Windows ended frozen > or USB was not working. It was hard to tell because input devices had no > response at all. >=20 > The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 kern= el > during Windows boot. I guess I have to rework the io_bitmap patch somehow. Hmm, I just tried the http://xenbits.xen.org/staging/xen-4.1-testing.hg (ta= g=20 4.1.3-rc1) and the 3.2 with both patches mentioned above and Windows booted= =20 just fine. Log is attached. =2D-=20 Pavel Mateja --Boundary-00=_bI9pPLDXbMX40PR Content-Type: text/x-log; charset="ISO-8859-1"; name="xen-4.1.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-4.1.log" __ __ _ _ _ _____ _ \ \/ /___ _ __ | || | / | |___ / _ __ ___/ | \ // _ \ '_ \ | || |_ | | |_ \ __| '__/ __| | / \ __/ | | | |__ _|| |_ ___) |__| | | (__| | /_/\_\___|_| |_| |_|(_)_(_)____/ |_| \___|_| (XEN) Xen version 4.1.3-rc1 (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Mon May 7 15:26:18 CEST 2012 (XEN) Latest ChangeSet: Mon May 07 13:44:08 2012 +0100 23290:513ca342fd86 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.281 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1847000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000226000000->0000000228000000 (514500 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81847000 (XEN) Init. ramdisk: ffffffff81847000->ffffffff81e82200 (XEN) Phys-Mach map: ffffffff81e83000->ffffffff82283000 (XEN) Start info: ffffffff82283000->ffffffff822834b4 (XEN) Page tables: ffffffff82284000->ffffffff82299000 (XEN) Boot stack: ffffffff82299000->ffffffff8229a000 (XEN) TOTAL: ffffffff80000000->ffffffff82400000 (XEN) ENTRY ADDRESS: ffffffff8162c200 (XEN) Dom0 has maximum 6 VCPUs (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 216kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.2.0-rc2-11202-gd3507af-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 SMP PREEMPT Sat May 5 20:13:29 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 00000000cfe80000 (usable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (usable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01847000 - 01e83000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffb000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at 80000000 (gap: 80000000:4fe80000) Booting paravirtualized kernel on Xen Xen version: 4.1.3-rc1 (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4b000 s75008 r8192 d23296 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 514973 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975220k/2097152k available (4470k kernel code, 472k absent, 121460k reserved, 1768k data, 596k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Verbose stalled-CPUs detection is disabled. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.280 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.56 BogoMIPS (lpj=3010280) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 ACPI: Core revision 20110623 cpu 0 spinlock event irq 297 Performance Events: (XEN) traps.c:2488:d0 Domain attempted WRMSR 00000000c0010004 from 0x000025a74db06414 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 303 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 315 installing Xen timer for CPU 4 cpu 4 spinlock event irq 321 installing Xen timer for CPU 5 cpu 5 spinlock event irq 327 Brought up 6 CPUs devtmpfs: initialized Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M Extended Config Space enabled on 1 nodes ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 HEST: Table not found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] pci 0000:00:02.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:04.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:05.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 pci 0000:00:06.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 pci 0000:00:07.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 pci 0000:00:0d.0: PCI INT A -> GSI 54 (level, low) -> IRQ 54 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) (XEN) physdev.c:164: dom0: wrong map_pirq type 3 pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] ERST: Table is not found! GHES: HEST is not enabled! Event-channel device installed. pciback 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pciback 0000:00:14.2: PCI INT A disabled xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:02:00.0: PCI INT A -> GSI 40 (level, low) -> IRQ 40 serial 0000:02:00.1: PCI INT B -> GSI 41 (level, low) -> IRQ 41 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata1: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: PCI INT A -> GSI 44 (level, low) -> IRQ 44 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata7: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.29 sky2 0000:04:00.0: PCI INT A -> GSI 51 (level, low) -> IRQ 51 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 cdc_ncm: 04-Aug-2011 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46 firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata3: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 ata8: SATA link down (SStatus 0 SControl 300) ata7: SATA link down (SStatus 0 SControl 300) usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata1.00: configured for UDMA/133 hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd 0000:00:12.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:12.0: OHCI Host Controller scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 usb 1-1: new high-speed USB device number 2 using ehci_hcd ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 firewire_core: created device fw0: GUID 001e8c0000de9136, S400 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xhci_hcd 0000:03:00.0: PCI INT A -> GSI 50 (level, low) -> IRQ 50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 ATK0110 ATK0110:00: EC enabled SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 SP5100 TCO timer: mmio address 0xb8fe00 already in use usb 4-2: new full-speed USB device number 2 using ohci_hcd IT87 WDT: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) wdt: Xen WatchDog Timer Driver v0.01 wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 13:42:51 UTC (1336398171) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. powernow-k8: invalid pstate 1 - bad value 1. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 2 - bad value 2. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 3 - bad value 3. powernow-k8: Please report to BIOS manufacturer [Firmware Bug]: powernow-k8: invalid powernow_table Freeing unused kernel memory: 596k freed Loading, please wait... udev[1086]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/local-premount ... done. EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Files under mount point '/lib/init/rw' will be hidden. ...usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony (warning). input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). firewire_net: firewire0: IPv4 over FireWire on device 001e8c0000de9136 firewire_core: refreshed device fw0 Starting the hotplug events dispatcher: udevdudev[1280]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 199611/1310720 files, 1390142/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): recovery complete EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2049): /proc/2049/oom_adj is deprecated, please use /proc/2049/oom_score_adj instead. XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting xenstored... Setting domain 0 name... Starting xenconsoled... Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2216]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2216]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2216]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2216]: blktapctrl.c:922: Unable to start blktapctrl Starting S.M.A.R.T. daemon: smartd. sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 00:13.2 (XEN) PCI remove device 00:16.2 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:16.2 [CPU0] failed to set governor name [CPU1] failed to set governor name [CPU2] failed to set governor name [CPU3] failed to set governor name [CPU4] failed to set governor name [CPU5] failed to set governor name . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3b0 f_mport=3b0 np=c (XEN) domctl.c:985:d0 memory_map:add: gfn=a0 mfn=a0 nr_mfns=20 (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3c0 f_mport=3c0 np=3 (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3c4 f_mport=3c4 np=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.1.3-rc1 (XEN) HVM1: CPU speed is 3010 MHz (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 (XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 10588 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc000000-0xfc00295c ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://etherboot.org (XEN) HVM1: - Product name: gPXE (XEN) HVM1: Loading ACPI ... (XEN) HVM1: - Lo data: 000ea020-000ea04f (XEN) HVM1: - Hi data: fc002c00-fc00eb1f (XEN) HVM1: vm86 TSS at fc00ec00 (XEN) HVM1: BIOS map: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e1fff: Etherboot ROM (XEN) HVM1: eb000-eb209: SMBIOS tables (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED (XEN) HVM1: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [04]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [06]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0 (XEN) domctl.c:995:d0 memory_map:remove: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) grant_table.c:1160:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:330: Dom1 callback via changed to GSI 28 (XEN) domctl.c:995:d0 memory_map:remove: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 --Boundary-00=_bI9pPLDXbMX40PR Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_bI9pPLDXbMX40PR-- From xen-devel-bounces@lists.xen.org Mon May 07 13:46:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:46:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROGV-0005qf-2U; Mon, 07 May 2012 13:46:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROGS-0005qa-CN for xen-devel@lists.xen.org; Mon, 07 May 2012 13:46:13 +0000 Received: from [85.158.138.51:32039] by server-1.bemta-3.messagelabs.com id FE/96-11491-322D7AF4; Mon, 07 May 2012 13:46:11 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-9.tower-174.messagelabs.com!1336398367!25727830!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2801 invoked from network); 7 May 2012 13:46:08 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-9.tower-174.messagelabs.com with SMTP; 7 May 2012 13:46:08 -0000 Received: (qmail 8046 invoked from network); 7 May 2012 15:46:04 +0200 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; 7 May 2012 15:46:04 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Mon, 7 May 2012 15:46:03 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> In-Reply-To: <201205071345.23619.pavel@netsafe.cz> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_bI9pPLDXbMX40PR" Message-Id: <201205071546.03637.pavel@netsafe.cz> Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_bI9pPLDXbMX40PR Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon 7. of May 2012 13:45:23 Pavel Mat=C4=9Bja wrote: > Hi, > I'm trying to run AMD VGA passthru on latest XEN unstable with latest > kernel. I already have working setup with ancient xen-devel 4.2 and > 2.6.32.x xenified kernel. See attached log. >=20 > So I tried just to update and patch xen and kernel, but I had no luck so > far. >=20 > Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang recentl= y. > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html >=20 > I tried two kernels > testing-3.5-with-extra and xen/next-3.2 from > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > and > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > Both with ioperm opcode patch which is required by the ATI patch. See > attachement. >=20 > The xen/next-3.2 branch kernel was able to start booting windows. > With Catalyst driver installed I just saw bluescreen during Windows boot. > Without Catalyst driver Windows were able to boot but Windows ended frozen > or USB was not working. It was hard to tell because input devices had no > response at all. >=20 > The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 kern= el > during Windows boot. I guess I have to rework the io_bitmap patch somehow. Hmm, I just tried the http://xenbits.xen.org/staging/xen-4.1-testing.hg (ta= g=20 4.1.3-rc1) and the 3.2 with both patches mentioned above and Windows booted= =20 just fine. Log is attached. =2D-=20 Pavel Mateja --Boundary-00=_bI9pPLDXbMX40PR Content-Type: text/x-log; charset="ISO-8859-1"; name="xen-4.1.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-4.1.log" __ __ _ _ _ _____ _ \ \/ /___ _ __ | || | / | |___ / _ __ ___/ | \ // _ \ '_ \ | || |_ | | |_ \ __| '__/ __| | / \ __/ | | | |__ _|| |_ ___) |__| | | (__| | /_/\_\___|_| |_| |_|(_)_(_)____/ |_| \___|_| (XEN) Xen version 4.1.3-rc1 (root@(none)) (gcc version 4.4.5 (Debian 4.4.5-8) ) Mon May 7 15:26:18 CEST 2012 (XEN) Latest ChangeSet: Mon May 07 13:44:08 2012 +0100 23290:513ca342fd86 (XEN) Console output is synchronous. (XEN) Bootloader: GRUB 1.98+20100804-14+squeeze1 (XEN) Command line: placeholder dom0_mem=2G dom0_max_vcpus=6 loglvl=all guest_loglvl=all sync_console com1=115200,8n1,0xac00 console=com1 (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 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cfe80000 (usable) (XEN) 00000000cfe80000 - 00000000cfe98000 (ACPI data) (XEN) 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) (XEN) 00000000cfec0000 - 00000000cff00000 (reserved) (XEN) 00000000ffe00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000230000000 (usable) (XEN) ACPI: RSDP 000FBF20, 0024 (r2 ACPIAM) (XEN) ACPI: XSDT CFE80100, 005C (r1 102811 XSDT1740 20111028 MSFT 97) (XEN) ACPI: FACP CFE80290, 00F4 (r3 102811 FACP1740 20111028 MSFT 97) (XEN) ACPI: DSDT CFE80470, E6E3 (r1 A1595 A1595000 0 INTL 20060113) (XEN) ACPI: FACS CFE98000, 0040 (XEN) ACPI: APIC CFE80390, 0098 (r1 102811 APIC1740 20111028 MSFT 97) (XEN) ACPI: MCFG CFE80430, 003C (r1 102811 OEMMCFG 20111028 MSFT 97) (XEN) ACPI: OEMB CFE98040, 0072 (r1 102811 OEMB1740 20111028 MSFT 97) (XEN) ACPI: HPET CFE8F8C0, 0038 (r1 102811 OEMHPET 20111028 MSFT 97) (XEN) ACPI: IVRS CFE8F900, 00E0 (r1 AMD RD890S 202031 AMD 0) (XEN) ACPI: SSDT CFE8F9E0, 0E10 (r1 A M I POWERNOW 1 AMD 1) (XEN) System RAM: 8190MB (8386664kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000230000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0] (XEN) ACPI: wakeup_vec[cfe9800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 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: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (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) IRQ limits: 56 GSI, 1112 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3010.281 MHz processor. (XEN) Initing memory sharing. (XEN) AMD Fam10h machine check reporting enabled (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) AMD-Vi: Enabling global vector map (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - Pause-Intercept Filter (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 6 CPUs (XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled. (XEN) ACPI sleep modes: S3 (XEN) MCA: Use hw thresholding to adjust polling frequency (XEN) mcheck_poll: Machine check polling timer started. (XEN) Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1847000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000226000000->0000000228000000 (514500 pages to be allocated) (XEN) Init. ramdisk: 000000022f9c4000->000000022ffff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81847000 (XEN) Init. ramdisk: ffffffff81847000->ffffffff81e82200 (XEN) Phys-Mach map: ffffffff81e83000->ffffffff82283000 (XEN) Start info: ffffffff82283000->ffffffff822834b4 (XEN) Page tables: ffffffff82284000->ffffffff82299000 (XEN) Boot stack: ffffffff82299000->ffffffff8229a000 (XEN) TOTAL: ffffffff80000000->ffffffff82400000 (XEN) ENTRY ADDRESS: ffffffff8162c200 (XEN) Dom0 has maximum 6 VCPUs (XEN) Scrubbing Free RAM: .............................................................done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 216kB init memory. mapping kernel into physical memory Xen: setup ISA identity maps about to get started... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.2.0-rc2-11202-gd3507af-dirty (root@xen) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 SMP PREEMPT Sat May 5 20:13:29 CEST 2012 Command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen Freeing 9a-100 pfn range: 102 pages freed Released 102 pages of unused memory Set 197094 page(s) to 1-1 mapping BIOS-provided physical RAM map: Xen: 0000000000000000 - 000000000009a000 (usable) Xen: 000000000009ac00 - 0000000000100000 (reserved) Xen: 0000000000100000 - 00000000cfe80000 (usable) Xen: 00000000cfe80000 - 00000000cfe98000 (ACPI data) Xen: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) Xen: 00000000cfec0000 - 00000000cff00000 (reserved) Xen: 00000000fec00000 - 00000000fec01000 (reserved) Xen: 00000000fec20000 - 00000000fec21000 (reserved) Xen: 00000000fee00000 - 00000000fee01000 (reserved) Xen: 00000000ffe00000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 0000000230000000 (usable) bootconsole [xenboot0] enabled NX (Execute Disable) protection: active user-defined physical RAM map: user: 0000000000000000 - 000000000009a000 (usable) user: 000000000009ac00 - 0000000000100000 (reserved) user: 0000000000100000 - 0000000080000000 (usable) user: 00000000cfe80000 - 00000000cfe98000 (ACPI data) user: 00000000cfe98000 - 00000000cfec0000 (ACPI NVS) user: 00000000cfec0000 - 00000000cff00000 (reserved) user: 00000000fec00000 - 00000000fec01000 (reserved) user: 00000000fec20000 - 00000000fec21000 (reserved) user: 00000000fee00000 - 00000000fee01000 (reserved) user: 00000000ffe00000 - 0000000100000000 (reserved) DMI present. No AGP bridge found last_pfn = 0x80000 max_arch_pfn = 0x400000000 found SMP MP-table at [ffff8800000ff780] ff780 init_memory_mapping: 0000000000000000-0000000080000000 RAMDISK: 01847000 - 01e83000 ACPI: RSDP 00000000000fbf20 00024 (v02 ACPIAM) ACPI: XSDT 00000000cfe80100 0005C (v01 102811 XSDT1740 20111028 MSFT 00000097) ACPI: FACP 00000000cfe80290 000F4 (v03 102811 FACP1740 20111028 MSFT 00000097) ACPI: DSDT 00000000cfe80470 0E6E3 (v01 A1595 A1595000 00000000 INTL 20060113) ACPI: FACS 00000000cfe98000 00040 ACPI: APIC 00000000cfe80390 00098 (v01 102811 APIC1740 20111028 MSFT 00000097) ACPI: MCFG 00000000cfe80430 0003C (v01 102811 OEMMCFG 20111028 MSFT 00000097) ACPI: OEMB 00000000cfe98040 00072 (v01 102811 OEMB1740 20111028 MSFT 00000097) ACPI: HPET 00000000cfe8f8c0 00038 (v01 102811 OEMHPET 20111028 MSFT 00000097) ACPI: IVRS 00000000cfe8f900 000E0 (v01 AMD RD890S 00202031 AMD 00000000) ACPI: SSDT 00000000cfe8f9e0 00E10 (v01 A M I POWERNOW 00000001 AMD 00000001) No NUMA configuration found Faking a node at 0000000000000000-0000000080000000 Initmem setup node 0 0000000000000000-0000000080000000 NODE_DATA [000000007fffb000 - 000000007fffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000010 -> 0x0000009a 0: 0x00000100 -> 0x00080000 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255 ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24]) IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 8 Processors exceeds NR_CPUS limit of 6 SMP: Allowing 6 CPUs, 0 hotplug CPUs Allocating PCI resources starting at 80000000 (gap: 80000000:4fe80000) Booting paravirtualized kernel on Xen Xen version: 4.1.3-rc1 (preserve-AD) setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1 PERCPU: Embedded 26 pages/cpu @ffff88007ff4b000 s75008 r8192 d23296 u106496 Built 1 zonelists in Node order, mobility grouping on. Total pages: 514973 Policy zone: DMA32 Kernel command line: placeholder root=/dev/mapper/lemrouch-xen ro mem=2G panic=15 xen-pciback.hide=(00:14.2) console=hvc0 earlyprintk=xen PID hash table entries: 4096 (order: 3, 32768 bytes) Placing 64MB software IO TLB between ffff880079600000 - ffff88007d600000 software IO TLB at phys 0x79600000 - 0x7d600000 Memory: 1975220k/2097152k available (4470k kernel code, 472k absent, 121460k reserved, 1768k data, 596k init) SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 Preemptible hierarchical RCU implementation. Verbose stalled-CPUs detection is disabled. NR_IRQS:4352 nr_irqs:1536 16 xen: sci override: global_irq=9 trigger=0 polarity=1 xen: acpi sci 9 xen_map_pirq_gsi: returning irq 9 for gsi 9 Console: colour VGA+ 80x25 console [hvc0] enabled, bootconsole disabled console [hvc0] enabled, bootconsole disabled installing Xen timer for CPU 0 Detected 3010.280 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 6020.56 BogoMIPS (lpj=3010280) pid_max: default: 32768 minimum: 301 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 ACPI: Core revision 20110623 cpu 0 spinlock event irq 297 Performance Events: (XEN) traps.c:2488:d0 Domain attempted WRMSR 00000000c0010004 from 0x000025a74db06414 to 0x000000000000abcd. Broken PMU hardware detected, using software events only. MCE: In-kernel MCE decoding enabled. installing Xen timer for CPU 1 cpu 1 spinlock event irq 303 installing Xen timer for CPU 2 cpu 2 spinlock event irq 309 installing Xen timer for CPU 3 cpu 3 spinlock event irq 315 installing Xen timer for CPU 4 cpu 4 spinlock event irq 321 installing Xen timer for CPU 5 cpu 5 spinlock event irq 327 Brought up 6 CPUs devtmpfs: initialized Grant table initialized NET: Registered protocol family 16 TOM: 00000000d0000000 aka 3328M TOM2: 0000000230000000 aka 8960M Extended Config Space enabled on 1 nodes ACPI: bus type pci registered PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab at 0 ACPI: Added _OSI(Module Device) ACPI: Added _OSI(Processor Device) ACPI: Added _OSI(3.0 _SCP Extensions) ACPI: Added _OSI(Processor Aggregator Device) ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources ACPI: EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 HEST: Table not found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] pci_root PNP0A03:00: host bridge window [mem 0xcff00000-0xdfffffff] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff] pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:14.4: PCI bridge to [bus 01-01] (subtractive decode) pci0000:00: Requesting ACPI _OSC control (0x1d) pci0000:00: ACPI _OSC control (0x1c) granted (XEN) PCI add device 00:00.0 (XEN) PCI add device 00:00.2 (XEN) PCI add device 00:02.0 (XEN) PCI add device 00:04.0 (XEN) PCI add device 00:05.0 (XEN) PCI add device 00:06.0 (XEN) PCI add device 00:07.0 (XEN) PCI add device 00:0d.0 (XEN) PCI add device 00:11.0 (XEN) PCI add device 00:12.0 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.0 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:14.0 (XEN) PCI add device 00:14.2 (XEN) PCI add device 00:14.3 (XEN) PCI add device 00:14.4 (XEN) PCI add device 00:14.5 (XEN) PCI add device 00:16.0 (XEN) PCI add device 00:16.2 (XEN) PCI add device 00:18.0 (XEN) PCI add device 00:18.1 (XEN) PCI add device 00:18.2 (XEN) PCI add device 00:18.3 (XEN) PCI add device 00:18.4 (XEN) PCI add device 07:00.0 (XEN) PCI add device 07:00.1 (XEN) PCI add device 06:00.0 (XEN) PCI add device 06:00.1 pci 0000:06:00.1: Failed to add - passthrough or MSI/MSI-X might fail! (XEN) PCI add device 05:00.0 (XEN) PCI add device 04:00.0 (XEN) PCI add device 03:00.0 (XEN) PCI add device 02:00.0 (XEN) PCI add device 02:00.1 ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 14 15) *0, disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing Switching to clocksource xen FS-Cache: Loaded CacheFiles: Loaded pnp: PnP ACPI init ACPI: bus type pnp registered system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved xen_map_pirq_gsi: returning irq 8 for gsi 8 xen_map_pirq_gsi: returning irq 13 for gsi 13 system 00:08: [mem 0xfec00000-0xfec00fff] could not be reserved system 00:08: [mem 0xfee00000-0xfee00fff] has been reserved system 00:09: [io 0x04d0-0x04d1] has been reserved system 00:09: [io 0x040b] has been reserved system 00:09: [io 0x04d6] has been reserved system 00:09: [io 0x0c00-0x0c01] has been reserved system 00:09: [io 0x0c14] has been reserved system 00:09: [io 0x0c50-0x0c51] has been reserved system 00:09: [io 0x0c52] has been reserved system 00:09: [io 0x0c6c] has been reserved system 00:09: [io 0x0c6f] has been reserved system 00:09: [io 0x0cd0-0x0cd1] has been reserved system 00:09: [io 0x0cd2-0x0cd3] has been reserved system 00:09: [io 0x0cd4-0x0cd5] has been reserved system 00:09: [io 0x0cd6-0x0cd7] has been reserved system 00:09: [io 0x0cd8-0x0cdf] has been reserved system 00:09: [io 0x0800-0x089f] has been reserved system 00:09: [io 0x0b00-0x0b1f] has been reserved system 00:09: [io 0x0b20-0x0b3f] has been reserved system 00:09: [io 0x0900-0x090f] has been reserved system 00:09: [io 0x0910-0x091f] has been reserved system 00:09: [io 0xfe00-0xfefe] has been reserved system 00:09: [mem 0xcff00000-0xcfffffff] has been reserved system 00:09: [mem 0xffb80000-0xffbfffff] has been reserved system 00:09: [mem 0xfec10000-0xfec1001f] has been reserved system 00:09: [mem 0xfed80000-0xfed80fff] has been reserved system 00:0a: [io 0x0230-0x023f] has been reserved system 00:0a: [io 0x0290-0x029f] has been reserved system 00:0a: [io 0x0f40-0x0f4f] has been reserved system 00:0a: [io 0x0a30-0x0a3f] has been reserved system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved system 00:0c: [mem 0x000c0000-0x000cffff] could not be reserved system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved system 00:0c: [mem 0x00100000-0xcfefffff] could not be reserved system 00:0c: [mem 0xfec00000-0xffffffff] could not be reserved pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered pciback 0000:00:14.2: seizing device PM-Timer failed consistency check (0x0xffffff) - aborting. pci 0000:00:02.0: PCI bridge to [bus 07-07] pci 0000:00:02.0: bridge window [io 0xe000-0xefff] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] pci 0000:00:04.0: PCI bridge to [bus 06-06] pci 0000:00:04.0: bridge window [io 0xd000-0xdfff] pci 0000:00:04.0: bridge window [mem 0xfe800000-0xfe8fffff] pci 0000:00:05.0: PCI bridge to [bus 05-05] pci 0000:00:05.0: bridge window [io 0xc000-0xcfff] pci 0000:00:05.0: bridge window [mem 0xfe700000-0xfe7fffff] pci 0000:00:06.0: PCI bridge to [bus 04-04] pci 0000:00:06.0: bridge window [io 0xb000-0xbfff] pci 0000:00:06.0: bridge window [mem 0xfe600000-0xfe6fffff] pci 0000:00:07.0: PCI bridge to [bus 03-03] pci 0000:00:07.0: bridge window [mem 0xfe500000-0xfe5fffff] pci 0000:00:0d.0: PCI bridge to [bus 02-02] pci 0000:00:0d.0: bridge window [io 0xa000-0xafff] pci 0000:00:0d.0: bridge window [mem 0xfe400000-0xfe4fffff] pci 0000:00:14.4: PCI bridge to [bus 01-01] pci 0000:00:02.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:04.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 xen_map_pirq_gsi: returning irq 52 for gsi 52 Already setup the GSI :52 pci 0000:00:05.0: PCI INT A -> GSI 52 (level, low) -> IRQ 52 pci 0000:00:06.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 xen_map_pirq_gsi: returning irq 53 for gsi 53 Already setup the GSI :53 pci 0000:00:07.0: PCI INT A -> GSI 53 (level, low) -> IRQ 53 pci 0000:00:0d.0: PCI INT A -> GSI 54 (level, low) -> IRQ 54 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered UDP hash table entries: 1024 (order: 3, 32768 bytes) UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) NET: Registered protocol family 1 Unpacking initramfs... Freeing initrd memory: 6384k freed microcode: Microcode Update Driver: v2.00 , Peter Oruba NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 3870 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) (XEN) physdev.c:164: dom0: wrong map_pirq type 3 pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.0: Signaling PME through PCIe PME interrupt pci 0000:07:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:04.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.0: Signaling PME through PCIe PME interrupt pci 0000:06:00.1: Signaling PME through PCIe PME interrupt pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt pci 0000:05:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:06.0: Signaling PME through PCIe PME interrupt pci 0000:04:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt pci 0000:03:00.0: Signaling PME through PCIe PME interrupt pcieport 0000:00:0d.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.0: Signaling PME through PCIe PME interrupt pci 0000:02:00.1: Signaling PME through PCIe PME interrupt pci_hotplug: PCI Hot Plug PCI Core version: 0.5 input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] ERST: Table is not found! GHES: HEST is not enabled! Event-channel device installed. pciback 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pciback 0000:00:14.2: PCI INT A disabled xen-pciback: backend is vpci Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:02:00.0: PCI INT A -> GSI 40 (level, low) -> IRQ 40 serial 0000:02:00.1: PCI INT B -> GSI 41 (level, low) -> IRQ 41 0000:02:00.1: ttyS0 at I/O 0xa880 (irq = 41) is a ST16650V2 hpet_acpi_add: no address or irqs in _CRS Non-volatile memory driver v1.3 Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). Hangcheck: Using getrawmonotonic(). loop: module loaded ahci 0000:00:11.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata1: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe100 irq 19 ata2: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe180 irq 19 ata3: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe200 irq 19 ata4: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe280 irq 19 ata5: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe300 irq 19 ata6: SATA max UDMA/133 abar m1024@0xfe3fe000 port 0xfe3fe380 irq 19 ahci 0000:06:00.0: PCI INT A -> GSI 44 (level, low) -> IRQ 44 ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part scsi6 : ahci scsi7 : ahci ata7: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe100 irq 44 ata8: SATA max UDMA/133 abar m8192@0xfe8fe000 port 0xfe8fe180 irq 44 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky sky2: driver version 1.29 sky2 0000:04:00.0: PCI INT A -> GSI 51 (level, low) -> IRQ 51 sky2 0000:04:00.0: Yukon-2 Optima chip revision 1 sky2 0000:04:00.0: eth0: addr 20:cf:30:6d:89:a5 cdc_ncm: 04-Aug-2011 usbcore: registered new interface driver cdc_ncm firewire_ohci 0000:05:00.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46 firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:12.2: debug port 1 ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe3fe400 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb1: SerialNumber: 0000:00:12.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:13.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ehci_hcd 0000:00:13.2: debug port 1 ehci_hcd 0000:00:13.2: irq 17, io mem 0xfe3fe800 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb2: SerialNumber: 0000:00:13.2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 17 for gsi 17 Already setup the GSI :17 ehci_hcd 0000:00:16.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ehci_hcd 0000:00:16.2: EHCI Host Controller ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround ata3: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ehci_hcd 0000:00:16.2: debug port 1 ehci_hcd 0000:00:16.2: irq 17, io mem 0xfe3fec00 ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00 ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133 ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32) usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 ata8: SATA link down (SStatus 0 SControl 300) ata7: SATA link down (SStatus 0 SControl 300) usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ehci_hcd usb usb3: SerialNumber: 0000:00:16.2 ata1.00: configured for UDMA/133 hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd 0000:00:12.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:12.0: OHCI Host Controller scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:12.0: irq 18, io mem 0xfe3f7000 sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: OHCI Host Controller usb usb4: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb4: SerialNumber: 0000:00:12.0 hub 4-0:1.0: USB hub found hub 4-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5 usb 1-1: new high-speed USB device number 2 using ehci_hcd ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe3fc000 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: OHCI Host Controller usb usb5: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb5: SerialNumber: 0000:00:13.0 firewire_core: created device fw0: GUID 001e8c0000de9136, S400 hub 5-0:1.0: USB hub found hub 5-0:1.0: 5 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:14.5: OHCI Host Controller ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe3fd000 usb 1-1: New USB device found, idVendor=0424, idProduct=2504 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: OHCI Host Controller usb usb6: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb6: SerialNumber: 0000:00:14.5 hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected xen_map_pirq_gsi: returning irq 18 for gsi 18 Already setup the GSI :18 ohci_hcd 0000:00:16.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:16.0: OHCI Host Controller ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7 ohci_hcd 0000:00:16.0: irq 18, io mem 0xfe3ff000 usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb7: Product: OHCI Host Controller usb usb7: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty ohci_hcd usb usb7: SerialNumber: 0000:00:16.0 hub 7-0:1.0: USB hub found hub 7-0:1.0: 4 ports detected xhci_hcd 0000:03:00.0: PCI INT A -> GSI 50 (level, low) -> IRQ 50 xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8 xhci_hcd 0000:03:00.0: irq 50, io mem 0xfe5fe000 usb usb8: New USB device found, idVendor=1d6b, idProduct=0002 usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb8: Product: xHCI Host Controller usb usb8: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb8: SerialNumber: 0000:03:00.0 hub 8-0:1.0: USB hub found hub 8-0:1.0: 2 ports detected xhci_hcd 0000:03:00.0: xHCI Host Controller xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9 usb usb9: New USB device found, idVendor=1d6b, idProduct=0003 usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb9: Product: xHCI Host Controller usb usb9: Manufacturer: Linux 3.2.0-rc2-11202-gd3507af-dirty xhci_hcd usb usb9: SerialNumber: 0000:03:00.0 hub 9-0:1.0: USB hub found hub 9-0:1.0: 2 ports detected usbcore: registered new interface driver usblp usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver libusual usbcore: registered new interface driver ums_eneub6250 i8042: PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mousedev: PS/2 mouse device common for all mice input: PC Speaker as /devices/platform/pcspkr/input/input2 rtc_cmos 00:04: RTC can wake from S4 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 114 bytes nvram i2c /dev entries driver piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 ATK0110 ATK0110:00: EC enabled SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 SP5100 TCO timer: mmio address 0xb8fe00 already in use usb 4-2: new full-speed USB device number 2 using ohci_hcd IT87 WDT: Chip IT8721 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) wdt: Xen WatchDog Timer Driver v0.01 wdt: cannot register miscdev on minor=130 (-16) wdt: probe of wdt failed with error -16 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com EDAC MC: Ver: 2.1.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC disabled. EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Either enable ECC checking or force module loading by setting 'ecc_enable_override'. (Note that use of the override may cause unknown side effects.) usbcore: registered new interface driver usbhid usbhid: USB HID core driver TCP cubic registered NET: Registered protocol family 17 rtc_cmos 00:04: setting system clock to 2012-05-07 13:42:51 UTC (1336398171) powernow-k8: Found 1 AMD Phenom(tm) II X6 1075T Processor (6 cpu cores) (version 2.20.00) powernow-k8: Core Performance Boosting: on. powernow-k8: invalid pstate 1 - bad value 1. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 2 - bad value 2. powernow-k8: Please report to BIOS manufacturer powernow-k8: invalid pstate 3 - bad value 3. powernow-k8: Please report to BIOS manufacturer [Firmware Bug]: powernow-k8: invalid powernow_table Freeing unused kernel memory: 596k freed Loading, please wait... udev[1086]: starting version 164 usb 4-2: New USB device found, idVendor=041e, idProduct=30dc usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Sound Blaster Tactic(3D) Alpha usb 4-2: Manufacturer: Creative Technology Ltd usb 4-2: SerialNumber: 00023162 input: Creative Technology Ltd Sound Blaster Tactic(3D) Alpha as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.3/input/input3 generic-usb 0003:041E:30DC.0001: input,hiddev0: USB HID v1.00 Device [Creative Technology Ltd Sound Blaster Tactic(3D) Alpha] on usb-0000:00:12.0-2/input3 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... usb 1-1.1: new full-speed USB device number 4 using ehci_hcd done. Begin: Running /scripts/local-premount ... done. EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) usb 1-1.1: New USB device found, idVendor=1532, idProduct=0013 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: Razer Orochi usb 1-1.1: Manufacturer: Razer input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input4 generic-usb 0003:1532:0013.0002: input: USB HID v1.11 Mouse [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input0 input: Razer Razer Orochi as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.1/input/input5 generic-usb 0003:1532:0013.0003: input: USB HID v1.11 Keyboard [Razer Razer Orochi] on usb-0000:00:12.2-1.1/input1 Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. usb 1-1.2: new low-speed USB device number 5 using ehci_hcd INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Files under mount point '/lib/init/rw' will be hidden. ...usb 1-1.2: New USB device found, idVendor=04f2, idProduct=0403 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: USB Keyboard usb 1-1.2: Manufacturer: Chicony (warning). input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.0/input/input6 generic-usb 0003:04F2:0403.0004: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input0 input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.2/1-1.2:1.1/input/input7 generic-usb 0003:04F2:0403.0005: input,hiddev0: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:12.2-1.2/input1 Files under mount point '/var/run' will be hidden. ... (warning). Files under mount point '/var/lock' will be hidden. ... (warning). firewire_net: firewire0: IPv4 over FireWire on device 001e8c0000de9136 firewire_core: refreshed device fw0 Starting the hotplug events dispatcher: udevdudev[1280]: starting version 164 . Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...done. Setting hostname to 'xen'...done. Setting preliminary keymap...done. Activating swap:. EXT4-fs (dm-0): re-mounted. Opts: (null) Will now check root file system:fsck from util-linux-ng 2.17.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a -C0 /dev/mapper/lemrouch-xen /dev/mapper/lemrouch-xen: clean, 199611/1310720 files, 1390142/5242880 blocks . EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro Loading kernel module firewire-sbp2. Loading kernel module loop. Cleaning up ifupdown.... Setting up networking.... Setting up LVM Volume Groups Reading all physical volumes. This may take a while... Found volume group "lemrouch" using metadata type lvm2 4 logical volume(s) in volume group "lemrouch" now active . Will now activate lvm and md swap:done. Will now check all file systems. fsck from util-linux-ng 2.17.2 Checking all file systems. Done checking file systems. A log is being saved in /var/log/fsck/checkfs if that location is writable.. Will now mount local filesystems:EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended EXT4-fs (sda1): recovery complete EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) . Will now activate swapfile swap:done. Cleaning up temporary files...Cleaning /tmp...done. . Checking minimum space in /tmp...done. Setting kernel variables ... /etc/sysctl.conf...done. Initializing random number generator...done. Setting up X server socket directory /tmp/.X11-unix.... Setting up ICE socket directory /tmp/.ICE-unix.... Configuring network interfaces...device eth0 entered promiscuous mode sky2 0000:04:00.0: eth0: enabling interface done. Cleaning up temporary files.... Starting filesystem in userspace: fuse. Setting console screen modes. cannot (un)set powersave mode Skipping font and keymap setup (handled by console-setup). Setting up console font and keymap...done. Setting sensors limits. INIT: Entering runlevel: 3 Using makefile-style concurrent boot in runlevel 3. Not starting fancontrol; run pwmconfig first. ... (warning). acpid: starting up with netlink and the input layer acpid: 1 rule loaded acpid: waiting for events: event logging is off Starting ACPI services.... Starting system message bus: dbus. sshd (2049): /proc/2049/oom_adj is deprecated, please use /proc/2049/oom_score_adj instead. XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state XENBUS: Unable to read cpu state Starting the Winbind daemon: winbind. Starting OpenBSD Secure Shell server: sshd. Starting xenstored... Setting domain 0 name... Starting xenconsoled... Starting domain name service...: bind9. Starting Samba daemons: nmbd smbd. Starting periodic command scheduler: cron. Starting Postfix Mail Transport Agent: postfix. BLKTAPCTRL[2216]: blktapctrl.c:790: blktapctrl: v1.0.0 BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [raw image (aio)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [raw image (sync)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [vmware image (vmdk)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [ramdisk image (ram)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [qcow disk (qcow)] BLKTAPCTRL[2216]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)] BLKTAPCTRL[2216]: blktapctrl_linux.c:86: blktap0 open failed BLKTAPCTRL[2216]: blktapctrl.c:859: couldn't open blktap interface BLKTAPCTRL[2216]: blktapctrl.c:922: Unable to start blktapctrl Starting S.M.A.R.T. daemon: smartd. sky2 0000:04:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both br0: port 1(eth0) entering forwarding state br0: port 1(eth0) entering forwarding state Running local boot scripts (/etc/rc.local)(XEN) PCI remove device 00:12.2 acpid: input device has been disconnected acpid: input device has been disconnected acpid: input device has been disconnected (XEN) PCI remove device 00:13.2 (XEN) PCI remove device 00:16.2 (XEN) PCI add device 00:12.2 (XEN) PCI add device 00:13.2 (XEN) PCI add device 00:16.2 [CPU0] failed to set governor name [CPU1] failed to set governor name [CPU2] failed to set governor name [CPU3] failed to set governor name [CPU4] failed to set governor name [CPU5] failed to set governor name . acpid: input device has been disconnected acpid: input device has been disconnected (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3b0 f_mport=3b0 np=c (XEN) domctl.c:985:d0 memory_map:add: gfn=a0 mfn=a0 nr_mfns=20 (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3c0 f_mport=3c0 np=3 (XEN) domctl.c:1041:d0 ioport_map:add f_gport=3c4 f_mport=3c4 np=1c (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v4.1.3-rc1 (XEN) HVM1: CPU speed is 3010 MHz (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 7 (XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 05:0 INTA->IRQ10 (XEN) HVM1: pci dev 06:0 INTB->IRQ5 (XEN) HVM1: pci dev 07:0 INTA->IRQ5 (XEN) HVM1: pci dev 08:0 INTB->IRQ10 (XEN) HVM1: pci dev 09:0 INTA->IRQ10 (XEN) HVM1: pci dev 05:0 bar 10 size 10000000: e000000c (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f0000008 (XEN) HVM1: pci dev 04:0 bar 10 size 00020000: f1000000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) HVM1: pci dev 05:0 bar 18 size 00020000: f1020004 (XEN) HVM1: pci dev 05:0 bar 30 size 00020000: f1040000 (XEN) HVM1: pci dev 06:0 bar 10 size 00004000: f1060004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) HVM1: pci dev 09:0 bar 10 size 00004000: f1064004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) HVM1: pci dev 07:0 bar 10 size 00001000: f1068000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) HVM1: pci dev 08:0 bar 10 size 00001000: f1069000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 05:0 bar 20 size 00000100: 0000c101 (XEN) HVM1: pci dev 04:0 bar 14 size 00000040: 0000c201 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c241 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU2 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU3 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU4 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: - CPU5 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 10588 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc000000-0xfc00295c ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading VGABIOS of passthroughed gfx ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://etherboot.org (XEN) HVM1: - Product name: gPXE (XEN) HVM1: Loading ACPI ... (XEN) HVM1: - Lo data: 000ea020-000ea04f (XEN) HVM1: - Hi data: fc002c00-fc00eb1f (XEN) HVM1: vm86 TSS at fc00ec00 (XEN) HVM1: BIOS map: (XEN) HVM1: c0000-cffff: VGA BIOS (XEN) HVM1: d0000-e1fff: Etherboot ROM (XEN) HVM1: eb000-eb209: SMBIOS tables (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: E820 table: (XEN) HVM1: [00]: 00000000:00000000 - 00000000:0009e000: RAM (XEN) HVM1: [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED (XEN) HVM1: [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED (XEN) HVM1: HOLE: 00000000:000a0000 - 00000000:000e0000 (XEN) HVM1: [03]: 00000000:000e0000 - 00000000:00100000: RESERVED (XEN) HVM1: [04]: 00000000:00100000 - 00000000:e0000000: RAM (XEN) HVM1: HOLE: 00000000:e0000000 - 00000000:fc000000 (XEN) HVM1: [05]: 00000000:fc000000 - 00000001:00000000: RESERVED (XEN) HVM1: [06]: 00000001:00000000 - 00000001:20000000: RAM (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (20480 MBytes) (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0 (XEN) domctl.c:995:d0 memory_map:remove: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) grant_table.c:1160:d1 Expanding dom (1) grant table from (4) to (32) frames. (XEN) irq.c:330: Dom1 callback via changed to GSI 28 (XEN) domctl.c:995:d0 memory_map:remove: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:985:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1020 mfn=fe9e0 nr_mfns=20 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1069 mfn=f0000 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:985:d0 memory_map:add: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1060 mfn=fe9bc nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1064 mfn=fe3f8 nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1068 mfn=fe3f7 nr_mfns=1 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f1069 mfn=f0000 nr_mfns=1 --Boundary-00=_bI9pPLDXbMX40PR Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_bI9pPLDXbMX40PR-- From xen-devel-bounces@lists.xen.org Mon May 07 13:49:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROJc-0005xn-US; Mon, 07 May 2012 13:49:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROJb-0005xf-US for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:49:28 +0000 Received: from [85.158.143.35:58184] by server-2.bemta-4.messagelabs.com id 94/00-17550-7E2D7AF4; Mon, 07 May 2012 13:49:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336398562!11824449!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31380 invoked from network); 7 May 2012 13:49:23 -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; 7 May 2012 13:49:23 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47DnBUU015175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 13:49:11 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 q47DnA3V013134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 13:49:10 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 q47DnAeS017322; Mon, 7 May 2012 08:49:10 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 06:49:10 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A033C4031D; Mon, 7 May 2012 09:43:21 -0400 (EDT) Date: Mon, 7 May 2012 09:43:21 -0400 From: Konrad Rzeszutek Wilk To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Message-ID: <20120507134321.GA361@phenom.dumpdata.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> <20120506090446.GU2058@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120506090446.GU2058@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 12:04:46PM +0300, Pasi K=E4rkk=E4inen wrote: > On Fri, May 04, 2012 at 10:04:23AM -0400, Konrad Rzeszutek Wilk wrote: > > Was thinking to push these patches to Linus for v3.5-rc6. > > = > = > Hmm.. that probably should say for v3.4-rc6 ? :) Yeah :-) > = > -- Pasi > = > > arch/x86/xen/enlighten.c | 40 +++++++++++++++++++++++++++++++++++= +++-- > > arch/x86/xen/mmu.c | 7 ++++++- > > drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- > > 3 files changed, 59 insertions(+), 13 deletions(-) > > = > > David Vrabel (1): > > xen/pci: don't use PCI BIOS service for configuration space acces= ses > > = > > Julia Lawall (1): > > drivers/video/xen-fbfront.c: add missing cleanup code > > = > > Konrad Rzeszutek Wilk (2): > > xen/apic: Return the APIC ID (and version) for CPU 0. > > xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/= PTEs > > = > = > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 13:49:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 13:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROJc-0005xn-US; Mon, 07 May 2012 13:49:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROJb-0005xf-US for xen-devel@lists.xensource.com; Mon, 07 May 2012 13:49:28 +0000 Received: from [85.158.143.35:58184] by server-2.bemta-4.messagelabs.com id 94/00-17550-7E2D7AF4; Mon, 07 May 2012 13:49:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336398562!11824449!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31380 invoked from network); 7 May 2012 13:49:23 -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; 7 May 2012 13:49:23 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47DnBUU015175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 13:49:11 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 q47DnA3V013134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 13:49:10 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 q47DnAeS017322; Mon, 7 May 2012 08:49:10 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 06:49:10 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id A033C4031D; Mon, 7 May 2012 09:43:21 -0400 (EDT) Date: Mon, 7 May 2012 09:43:21 -0400 From: Konrad Rzeszutek Wilk To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Message-ID: <20120507134321.GA361@phenom.dumpdata.com> References: <1336140267-7399-1-git-send-email-konrad.wilk@oracle.com> <20120506090446.GU2058@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120506090446.GU2058@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] patches for v3.5-rc6. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 12:04:46PM +0300, Pasi K=E4rkk=E4inen wrote: > On Fri, May 04, 2012 at 10:04:23AM -0400, Konrad Rzeszutek Wilk wrote: > > Was thinking to push these patches to Linus for v3.5-rc6. > > = > = > Hmm.. that probably should say for v3.4-rc6 ? :) Yeah :-) > = > -- Pasi > = > > arch/x86/xen/enlighten.c | 40 +++++++++++++++++++++++++++++++++++= +++-- > > arch/x86/xen/mmu.c | 7 ++++++- > > drivers/video/xen-fbfront.c | 25 +++++++++++++++---------- > > 3 files changed, 59 insertions(+), 13 deletions(-) > > = > > David Vrabel (1): > > xen/pci: don't use PCI BIOS service for configuration space acces= ses > > = > > Julia Lawall (1): > > drivers/video/xen-fbfront.c: add missing cleanup code > > = > > Konrad Rzeszutek Wilk (2): > > xen/apic: Return the APIC ID (and version) for CPU 0. > > xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/= PTEs > > = > = > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:00:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SROTu-0006Fn-G8; Mon, 07 May 2012 14:00:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROTt-0006Fi-5W for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:00:05 +0000 Received: from [85.158.138.51:53445] by server-7.bemta-3.messagelabs.com id A9/8E-03078-465D7AF4; Mon, 07 May 2012 14:00:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336399201!23902880!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23838 invoked from network); 7 May 2012 14:00:03 -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; 7 May 2012 14:00:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47DxxHm027637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 14:00:00 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 q47DxxWt015496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 13:59:59 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 q47DxxxU025427; Mon, 7 May 2012 08:59:59 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 06:59:59 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DFA4C4031D; Mon, 7 May 2012 09:54:10 -0400 (EDT) Date: Mon, 7 May 2012 09:54:10 -0400 From: Konrad Rzeszutek Wilk To: "Hao, Xudong" Message-ID: <20120507135410.GD361@phenom.dumpdata.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > > > -----Original Message----- > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > Sent: Friday, May 04, 2012 9:21 PM > > To: Hao, Xudong > > Cc: xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > > by pciback > > > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > > guest with device assigned can be benefitted. > > > > > > Changes from v1: > > > - put the variable definition at the start of function > > > - add error log report > > > > > > > Don't you need to disable this when the device is un-assigned from the guest? > > > > I don't think this need to be disabled when device is un-assigned from guest. If host want to use device again, the host device driver need re-load, so whether disabling ltr/obff is up to host device driver. What if the driver isn't doing that? > > > > Signed-off-by: Xudong Hao > > > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > > b/drivers/xen/xen-pciback/pci_stub.c > > > index 097e536..74fbf23 100644 > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > > pci_dev *dev) > > > struct xen_pcibk_dev_data *dev_data; > > > int err = 0; > > > > > > + /* set default value */ > > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > > > Why these values? Is there a way to fetch optimal values? > > These values is the max value that the register supported. I've no idea to get an optimal value, here it just be set max value as default. Is the max value defined somewhere? Can it be defined somewhere so that both KVM adn the Xen patches re-use the same #define? > > > > + > > > dev_dbg(&dev->dev, "initializing...\n"); > > > > > > /* The PCI backend is not intended to be a module (or to work with > > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > > pci_dev *dev) > > > dev_dbg(&dev->dev, "reset device\n"); > > > xen_pcibk_reset_device(dev); > > > > > > + /* Enable LTR and OBFF before do device assignment */ > > > + /* LTR(Latency tolerance reporting) allows devices to send > > > + * messages to the root complex indicating their latency tolerance > > > + * for snooped & unsnooped memory transactions. > > > + */ > > > + err = pci_enable_ltr(dev); > > > + if (err) > > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > > + > > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > > + if (err) > > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > > + > > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > > + * improve energy efficiency by giving devices information about > > > + * when interrupts and other activity will have a reduced power > > > + * impact. > > > + */ > > > + err = pci_enable_obff(dev, type); > > > + if (err) > > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > > + > > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > > return 0; > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xen.org > > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:00:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SROTu-0006Fn-G8; Mon, 07 May 2012 14:00:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROTt-0006Fi-5W for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:00:05 +0000 Received: from [85.158.138.51:53445] by server-7.bemta-3.messagelabs.com id A9/8E-03078-465D7AF4; Mon, 07 May 2012 14:00:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336399201!23902880!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23838 invoked from network); 7 May 2012 14:00:03 -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; 7 May 2012 14:00:03 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47DxxHm027637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 14:00:00 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 q47DxxWt015496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 13:59:59 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 q47DxxxU025427; Mon, 7 May 2012 08:59:59 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 06:59:59 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DFA4C4031D; Mon, 7 May 2012 09:54:10 -0400 (EDT) Date: Mon, 7 May 2012 09:54:10 -0400 From: Konrad Rzeszutek Wilk To: "Hao, Xudong" Message-ID: <20120507135410.GD361@phenom.dumpdata.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > > > -----Original Message----- > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > Sent: Friday, May 04, 2012 9:21 PM > > To: Hao, Xudong > > Cc: xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > > by pciback > > > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so that > > guest with device assigned can be benefitted. > > > > > > Changes from v1: > > > - put the variable definition at the start of function > > > - add error log report > > > > > > > Don't you need to disable this when the device is un-assigned from the guest? > > > > I don't think this need to be disabled when device is un-assigned from guest. If host want to use device again, the host device driver need re-load, so whether disabling ltr/obff is up to host device driver. What if the driver isn't doing that? > > > > Signed-off-by: Xudong Hao > > > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > > b/drivers/xen/xen-pciback/pci_stub.c > > > index 097e536..74fbf23 100644 > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > > pci_dev *dev) > > > struct xen_pcibk_dev_data *dev_data; > > > int err = 0; > > > > > > + /* set default value */ > > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > > > Why these values? Is there a way to fetch optimal values? > > These values is the max value that the register supported. I've no idea to get an optimal value, here it just be set max value as default. Is the max value defined somewhere? Can it be defined somewhere so that both KVM adn the Xen patches re-use the same #define? > > > > + > > > dev_dbg(&dev->dev, "initializing...\n"); > > > > > > /* The PCI backend is not intended to be a module (or to work with > > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > > pci_dev *dev) > > > dev_dbg(&dev->dev, "reset device\n"); > > > xen_pcibk_reset_device(dev); > > > > > > + /* Enable LTR and OBFF before do device assignment */ > > > + /* LTR(Latency tolerance reporting) allows devices to send > > > + * messages to the root complex indicating their latency tolerance > > > + * for snooped & unsnooped memory transactions. > > > + */ > > > + err = pci_enable_ltr(dev); > > > + if (err) > > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > > + > > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > > + if (err) > > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > > + > > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > > + * improve energy efficiency by giving devices information about > > > + * when interrupts and other activity will have a reduced power > > > + * impact. > > > + */ > > > + err = pci_enable_obff(dev, type); > > > + if (err) > > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > > + > > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > > return 0; > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xen.org > > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:12:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14: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 ) id 1SROfj-0006eU-D7; Mon, 07 May 2012 14:12:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROfi-0006eP-3N for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:12:18 +0000 Received: from [85.158.143.99:40046] by server-1.bemta-4.messagelabs.com id 9D/79-20925-148D7AF4; Mon, 07 May 2012 14:12:17 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-5.tower-216.messagelabs.com!1336399933!26513193!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12976 invoked from network); 7 May 2012 14:12:15 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 14:12:15 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SROfc-00014k-Cg for xen-devel@lists.xensource.com; Mon, 07 May 2012 07:12:12 -0700 Date: Mon, 7 May 2012 07:12:12 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336399932385-5691153.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25259:0f53540494f7) vi Makefile # removed dist-kernel to not compile kernel vi Config.mk # test seabios unstable PYTHON_PREFIX_ARG = QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit 8f473dd104f0937ce98523fa6f9de0bd845aebbe SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit 74f96123e7e37c219403b50e39dabc8e8c450948 SEABIOS_UPSTREAM_TAG ?= master ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb ------------------------- Recent regression: ------------- - CRITICAL - PV domU unable to start: With pygrub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 With pv-grub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Daemon running with PID 6136 Same error also with other linux pv domU. ------------------------- ------------------------- Old issue: - Save/restore not working with qemu-xen ------------- - Unable to get QXL vga working correctly and with full videoram ------------- - On hvm domU start, domU work also this output on xl create: libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 ------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:12:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14: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 ) id 1SROfj-0006eU-D7; Mon, 07 May 2012 14:12:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROfi-0006eP-3N for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:12:18 +0000 Received: from [85.158.143.99:40046] by server-1.bemta-4.messagelabs.com id 9D/79-20925-148D7AF4; Mon, 07 May 2012 14:12:17 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-5.tower-216.messagelabs.com!1336399933!26513193!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12976 invoked from network); 7 May 2012 14:12:15 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 14:12:15 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SROfc-00014k-Cg for xen-devel@lists.xensource.com; Mon, 07 May 2012 07:12:12 -0700 Date: Mon, 7 May 2012 07:12:12 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336399932385-5691153.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25259:0f53540494f7) vi Makefile # removed dist-kernel to not compile kernel vi Config.mk # test seabios unstable PYTHON_PREFIX_ARG = QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit 8f473dd104f0937ce98523fa6f9de0bd845aebbe SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit 74f96123e7e37c219403b50e39dabc8e8c450948 SEABIOS_UPSTREAM_TAG ?= master ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb ------------------------- Recent regression: ------------- - CRITICAL - PV domU unable to start: With pygrub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 With pv-grub: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Daemon running with PID 6136 Same error also with other linux pv domU. ------------------------- ------------------------- Old issue: - Save/restore not working with qemu-xen ------------- - Unable to get QXL vga working correctly and with full videoram ------------- - On hvm domU start, domU work also this output on xl create: libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 ------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:26:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14: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 ) id 1SROsg-0007RR-W5; Mon, 07 May 2012 14:25:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROsg-0007RJ-6s for xen-devel@lists.xen.org; Mon, 07 May 2012 14:25:42 +0000 Received: from [85.158.143.35:23035] by server-2.bemta-4.messagelabs.com id F6/44-17550-56BD7AF4; Mon, 07 May 2012 14:25:41 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336400740!13529164!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11874 invoked from network); 7 May 2012 14:25:40 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 14:25:40 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:25:39 +0100 Message-Id: <4FA7F7810200007800082084@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:25:36 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2B05CE70.0__=" Subject: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2B05CE70.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For xen.efi, this eliminates a pointless gap between .text and .text.unlikely of almost 2Mb size. Signed-off-by: Jan Beulich --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -47,6 +47,8 @@ SECTIONS .text : { _stext =3D .; /* Text and read-only data */ *(.text) + *(.text.cold) + *(.text.unlikely) *(.fixup) *(.gnu.warning) _etext =3D .; /* End of text section */ --=__Part2B05CE70.0__= Content-Type: text/plain; name="x86-text-unlikely.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-text-unlikely.patch" x86: merge .text.* into .text while linking=0A=0AFor xen.efi, this = eliminates a pointless gap between .text and=0A.text.unlikely of almost = 2Mb size.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/xen.lds.S=0A+++ b/xen/arch/x86/xen.lds.S=0A@@ -47,6 +47,8 = @@ SECTIONS=0A .text : {=0A _stext =3D .; /* Text and = read-only data */=0A *(.text)=0A+ *(.text.cold)=0A+ = *(.text.unlikely)=0A *(.fixup)=0A *(.gnu.warning)=0A = _etext =3D .; /* End of text section */=0A --=__Part2B05CE70.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2B05CE70.0__=-- From xen-devel-bounces@lists.xen.org Mon May 07 14:26:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14: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 ) id 1SROsg-0007RR-W5; Mon, 07 May 2012 14:25:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SROsg-0007RJ-6s for xen-devel@lists.xen.org; Mon, 07 May 2012 14:25:42 +0000 Received: from [85.158.143.35:23035] by server-2.bemta-4.messagelabs.com id F6/44-17550-56BD7AF4; Mon, 07 May 2012 14:25:41 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336400740!13529164!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11874 invoked from network); 7 May 2012 14:25:40 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 14:25:40 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:25:39 +0100 Message-Id: <4FA7F7810200007800082084@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:25:36 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2B05CE70.0__=" Subject: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2B05CE70.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For xen.efi, this eliminates a pointless gap between .text and .text.unlikely of almost 2Mb size. Signed-off-by: Jan Beulich --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -47,6 +47,8 @@ SECTIONS .text : { _stext =3D .; /* Text and read-only data */ *(.text) + *(.text.cold) + *(.text.unlikely) *(.fixup) *(.gnu.warning) _etext =3D .; /* End of text section */ --=__Part2B05CE70.0__= Content-Type: text/plain; name="x86-text-unlikely.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-text-unlikely.patch" x86: merge .text.* into .text while linking=0A=0AFor xen.efi, this = eliminates a pointless gap between .text and=0A.text.unlikely of almost = 2Mb size.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/xen.lds.S=0A+++ b/xen/arch/x86/xen.lds.S=0A@@ -47,6 +47,8 = @@ SECTIONS=0A .text : {=0A _stext =3D .; /* Text and = read-only data */=0A *(.text)=0A+ *(.text.cold)=0A+ = *(.text.unlikely)=0A *(.fixup)=0A *(.gnu.warning)=0A = _etext =3D .; /* End of text section */=0A --=__Part2B05CE70.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2B05CE70.0__=-- From xen-devel-bounces@lists.xen.org Mon May 07 14:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14:42:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRP8y-0007qQ-O9; Mon, 07 May 2012 14:42:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRP8w-0007qL-M0 for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:42:30 +0000 Received: from [85.158.138.51:23021] by server-12.bemta-3.messagelabs.com id 37/72-29760-55FD7AF4; Mon, 07 May 2012 14:42:29 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336401748!17779527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22596 invoked from network); 7 May 2012 14:42:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 14:42:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12332094" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 14:41:50 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 15:41:49 +0100 Message-ID: <4FA7DF2B.3020000@citrix.com> Date: Mon, 7 May 2012 15:41:47 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> In-Reply-To: <4FA7EB80020000780008204B@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 14:34, Jan Beulich wrote: >>>> On 07.05.12 at 13:50, Andrew Cooper wrote: >> On 07/05/2012 09:10, Jan Beulich wrote: >>>>>> On 05.05.12 at 02:21, AP wrote: >>>> (XEN) *** IRQ BUG found *** >>>> (XEN) CPU0 -Testing vector 236 from bitmap >>> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming >>> in through the 8259A. Something fundamentally fishy must be going >>> on here, and I would suppose the code in question shouldn't even be >>> reached for legacy vectors. >>> >>> Furthermore, calling dump_irqs() from the debugging code with >>> desc->lock still held makes it impossible to get full output, as that >>> function wants to lock all initialized IRQ descriptors. >> Yes - it has been vector 236 on each of the 3 reported failures from AP, >> and I believe it was also vector 236 in the one case I managed to >> reproduce the issue. >> >> However, once we have set up the IO-APIC, the 8259A should not be used >> any more. The boot dmeg shows that io_ack_method is indeed "old" (which >> was going to be my first suggestion), and that EOI Broadcast Suppression >> is enabled, which I have already identified as a source of problems for >> some customers. As a 'fix', I provided the ability for >> "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. >> This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not >> completely fixed the customer problems - just made it substantially more >> rare. >> >> AP: Can you manually invoke the 'i' debug key and provide that - it will >> help to see how Xen is setting up the IO-APIC(s) on your system. > Seeing the 'z' output might also be helpful, especially to see whether > any of the IO-APICs' RTEs is an ExtINT one. > > Further, checking that no 8259A IRQ got (or was left) enabled for > some reason might be useful as well (cached_irq_mask plus the raw > port 0x21 and 0xA1 values). > > In any case the debugging code's locking should be fixed. > > Jan > It appears we have two functions to dump the IO-APIC state: __print_IO_APIC() which gets called on boot and from 'z', and dump_ioapic_irq_info() which gets called from the end of 'i'. These should probably be consolidated somehow. As for the debugging, perhaps change the call to dump_irqs() with a call to dump_ioapic_irq_info() instead. Given that the legacy vectors cant migrate, is it wise including them in the loop in irq_move_cleanup_interrupt()? In fact, is it wise including any vector above LAST_DYNAMIC_VECTOR? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14:42:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRP8y-0007qQ-O9; Mon, 07 May 2012 14:42:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRP8w-0007qL-M0 for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:42:30 +0000 Received: from [85.158.138.51:23021] by server-12.bemta-3.messagelabs.com id 37/72-29760-55FD7AF4; Mon, 07 May 2012 14:42:29 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336401748!17779527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22596 invoked from network); 7 May 2012 14:42:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 14:42:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12332094" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 14:41:50 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 15:41:49 +0100 Message-ID: <4FA7DF2B.3020000@citrix.com> Date: Mon, 7 May 2012 15:41:47 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> In-Reply-To: <4FA7EB80020000780008204B@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 14:34, Jan Beulich wrote: >>>> On 07.05.12 at 13:50, Andrew Cooper wrote: >> On 07/05/2012 09:10, Jan Beulich wrote: >>>>>> On 05.05.12 at 02:21, AP wrote: >>>> (XEN) *** IRQ BUG found *** >>>> (XEN) CPU0 -Testing vector 236 from bitmap >>> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming >>> in through the 8259A. Something fundamentally fishy must be going >>> on here, and I would suppose the code in question shouldn't even be >>> reached for legacy vectors. >>> >>> Furthermore, calling dump_irqs() from the debugging code with >>> desc->lock still held makes it impossible to get full output, as that >>> function wants to lock all initialized IRQ descriptors. >> Yes - it has been vector 236 on each of the 3 reported failures from AP, >> and I believe it was also vector 236 in the one case I managed to >> reproduce the issue. >> >> However, once we have set up the IO-APIC, the 8259A should not be used >> any more. The boot dmeg shows that io_ack_method is indeed "old" (which >> was going to be my first suggestion), and that EOI Broadcast Suppression >> is enabled, which I have already identified as a source of problems for >> some customers. As a 'fix', I provided the ability for >> "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. >> This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not >> completely fixed the customer problems - just made it substantially more >> rare. >> >> AP: Can you manually invoke the 'i' debug key and provide that - it will >> help to see how Xen is setting up the IO-APIC(s) on your system. > Seeing the 'z' output might also be helpful, especially to see whether > any of the IO-APICs' RTEs is an ExtINT one. > > Further, checking that no 8259A IRQ got (or was left) enabled for > some reason might be useful as well (cached_irq_mask plus the raw > port 0x21 and 0xA1 values). > > In any case the debugging code's locking should be fixed. > > Jan > It appears we have two functions to dump the IO-APIC state: __print_IO_APIC() which gets called on boot and from 'z', and dump_ioapic_irq_info() which gets called from the end of 'i'. These should probably be consolidated somehow. As for the debugging, perhaps change the call to dump_irqs() with a call to dump_ioapic_irq_info() instead. Given that the legacy vectors cant migrate, is it wise including them in the loop in irq_move_cleanup_interrupt()? In fact, is it wise including any vector above LAST_DYNAMIC_VECTOR? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:50:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14:50:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPGN-0007zl-N7; Mon, 07 May 2012 14:50:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPGM-0007zd-14 for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:50:10 +0000 Received: from [85.158.143.35:3482] by server-2.bemta-4.messagelabs.com id AC/4A-17550-121E7AF4; Mon, 07 May 2012 14:50:09 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336402207!14442077!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14951 invoked from network); 7 May 2012 14:50:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 14:50:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:50:06 +0100 Message-Id: <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:50:03 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> In-Reply-To: <4FA7DF2B.3020000@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 16:41, Andrew Cooper wrote: > Given that the legacy vectors cant migrate, is it wise including them in > the loop in irq_move_cleanup_interrupt()? In fact, is it wise including > any vector above LAST_DYNAMIC_VECTOR? Likely not, but then again this is the final piece of moving an interrupt, so there must have been something earlier that incorrectly initiated a move. In other words, rather than fixing the loop here, we should make sure execution can't even make it there for legacy vectors. And of course this is irrespective of the fact that no legacy interrupt should occur in the first place, unless this is a very strange system. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 14:50:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 14:50:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPGN-0007zl-N7; Mon, 07 May 2012 14:50:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPGM-0007zd-14 for xen-devel@lists.xensource.com; Mon, 07 May 2012 14:50:10 +0000 Received: from [85.158.143.35:3482] by server-2.bemta-4.messagelabs.com id AC/4A-17550-121E7AF4; Mon, 07 May 2012 14:50:09 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336402207!14442077!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14951 invoked from network); 7 May 2012 14:50:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 14:50:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:50:06 +0100 Message-Id: <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:50:03 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> In-Reply-To: <4FA7DF2B.3020000@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 16:41, Andrew Cooper wrote: > Given that the legacy vectors cant migrate, is it wise including them in > the loop in irq_move_cleanup_interrupt()? In fact, is it wise including > any vector above LAST_DYNAMIC_VECTOR? Likely not, but then again this is the final piece of moving an interrupt, so there must have been something earlier that incorrectly initiated a move. In other words, rather than fixing the loop here, we should make sure execution can't even make it there for legacy vectors. And of course this is irrespective of the fact that no legacy interrupt should occur in the first place, unless this is a very strange system. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:01:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPRG-0008C5-0e; Mon, 07 May 2012 15:01:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPRE-0008C0-2X for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:01:24 +0000 Received: from [85.158.143.99:38800] by server-1.bemta-4.messagelabs.com id 7D/96-20925-3C3E7AF4; Mon, 07 May 2012 15:01:23 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-216.messagelabs.com!1336402879!21599351!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11483 invoked from network); 7 May 2012 15:01:21 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 15:01:21 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRPR9-0006Mi-3h for xen-devel@lists.xensource.com; Mon, 07 May 2012 08:01:19 -0700 Date: Mon, 7 May 2012 08:01:19 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336402879103-5691285.post@n5.nabble.com> In-Reply-To: <1336132976402-5685659.post@n5.nabble.com> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336132976402-5685659.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fantu wrote > > > Anthony PERARD-2 wrote >> >> On Fri, May 4, 2012 at 9:28 AM, Ian Campbell <Ian.Campbell@> wrote: >>> Anthony -- any idea why the videoram setting doesn't work with upstream >>> qemu? >> >> Well, the parameter could be pass to qemu qxl, but it's not yet. But >> then, it seams you have to have this value of at least 32MB, otherwise >> the value is increase in qemu. >> >> For cirrus/stdvga, there is no way to pass the parameter to qemu, the >> size in qemu is fixed to 8MB. >> >> -- >> Anthony PERARD >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@.xen >> http://lists.xen.org/xen-devel >> > I have already tried -global qxl-vga.vram_size for setting more videoram > on qxl but not work,have always 4 mb, also with qemu-upstream unstable, > the default code in qemu should have 64 mb and minimum 16 mb, why and > where it sets 4 mb? > Now I will try also with 1.1-rc0 and seabios 1.7.0. > I did other tests with new build (see http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-td5691153.html here for detail) Precise domU start but X crash, same error also with Wheezy with more update package include qxl driver Here some details: ------------------------------- PRECISEHVM.cfg -------- name='PRECISEHVM' builder="hvm" memory=1024 #maxmem=1536 vcpus=2 hap=1 pae=1 acpi=1 apic=1 nx=1 vif=['bridge=xenbr0'] #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"'] #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw', '/dev/sr0,raw,hdb,ro,cdrom'] disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw'] boot='c' xen_platform_pci=1 device_model_version='qemu-xen' #vnc=1 #vncunused=1 #vnclisten="0.0.0.0" #keymap="it" stdvga=0 spice=1 spicehost='0.0.0.0' spiceport=6000 spicedisable_ticketing=1 #device_model_args=["-device","qxl-vga","-global","qxl-vga.vram_size=33554432"] device_model_args=["-vga","qxl"] videoram=128 ------------------------------- Full X log: http://xen.1045712.n5.nabble.com/file/n5691285/Xorg.0.log Xorg.0.log I also tried to remove videoram parameter but not start ------------------------------- xl create /etc/xen/PRECISEHVM.cfg Parsing config file /etc/xen/PRECISEHVM.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dc88 TOTAL: 0000000000000000->000000003f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 libxl: error: libxl_qmp.c:687:libxl__qmp_initialize: Connection error: Connection refused libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died during startup libxl: error: libxl_create.c:709:do_domain_create: device model did not start: -1 ------------------------------- /var/log/xen/qemu-dm-PRECISEHVM.log ------------------------- do_spice_init: starting 0.10.1 spice_server_add_interface: SPICE_INTERFACE_MIGRATION spice_server_add_interface: SPICE_INTERFACE_KEYBOARD spice_server_add_interface: SPICE_INTERFACE_MOUSE qemu: hardware error: xen: failed to populate ram at 3f800000 CPU #0: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 CPU #1: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 ------------------------------- videoram seems reserve the ram and from X log QXL videoram seems to be at correct size but probably qemu can't use it. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5691285.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:01:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPRG-0008C5-0e; Mon, 07 May 2012 15:01:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPRE-0008C0-2X for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:01:24 +0000 Received: from [85.158.143.99:38800] by server-1.bemta-4.messagelabs.com id 7D/96-20925-3C3E7AF4; Mon, 07 May 2012 15:01:23 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-216.messagelabs.com!1336402879!21599351!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11483 invoked from network); 7 May 2012 15:01:21 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 7 May 2012 15:01:21 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRPR9-0006Mi-3h for xen-devel@lists.xensource.com; Mon, 07 May 2012 08:01:19 -0700 Date: Mon, 7 May 2012 08:01:19 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336402879103-5691285.post@n5.nabble.com> In-Reply-To: <1336132976402-5685659.post@n5.nabble.com> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336132976402-5685659.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fantu wrote > > > Anthony PERARD-2 wrote >> >> On Fri, May 4, 2012 at 9:28 AM, Ian Campbell <Ian.Campbell@> wrote: >>> Anthony -- any idea why the videoram setting doesn't work with upstream >>> qemu? >> >> Well, the parameter could be pass to qemu qxl, but it's not yet. But >> then, it seams you have to have this value of at least 32MB, otherwise >> the value is increase in qemu. >> >> For cirrus/stdvga, there is no way to pass the parameter to qemu, the >> size in qemu is fixed to 8MB. >> >> -- >> Anthony PERARD >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@.xen >> http://lists.xen.org/xen-devel >> > I have already tried -global qxl-vga.vram_size for setting more videoram > on qxl but not work,have always 4 mb, also with qemu-upstream unstable, > the default code in qemu should have 64 mb and minimum 16 mb, why and > where it sets 4 mb? > Now I will try also with 1.1-rc0 and seabios 1.7.0. > I did other tests with new build (see http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-td5691153.html here for detail) Precise domU start but X crash, same error also with Wheezy with more update package include qxl driver Here some details: ------------------------------- PRECISEHVM.cfg -------- name='PRECISEHVM' builder="hvm" memory=1024 #maxmem=1536 vcpus=2 hap=1 pae=1 acpi=1 apic=1 nx=1 vif=['bridge=xenbr0'] #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap="it"'] #disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw', '/dev/sr0,raw,hdb,ro,cdrom'] disk=['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw'] boot='c' xen_platform_pci=1 device_model_version='qemu-xen' #vnc=1 #vncunused=1 #vnclisten="0.0.0.0" #keymap="it" stdvga=0 spice=1 spicehost='0.0.0.0' spiceport=6000 spicedisable_ticketing=1 #device_model_args=["-device","qxl-vga","-global","qxl-vga.vram_size=33554432"] device_model_args=["-vga","qxl"] videoram=128 ------------------------------- Full X log: http://xen.1045712.n5.nabble.com/file/n5691285/Xorg.0.log Xorg.0.log I also tried to remove videoram parameter but not start ------------------------------- xl create /etc/xen/PRECISEHVM.cfg Parsing config file /etc/xen/PRECISEHVM.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dc88 TOTAL: 0000000000000000->000000003f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 libxl: error: libxl_qmp.c:687:libxl__qmp_initialize: Connection error: Connection refused libxl: error: libxl_exec.c:200:libxl__wait_for_offspring: Device Model died during startup libxl: error: libxl_create.c:709:do_domain_create: device model did not start: -1 ------------------------------- /var/log/xen/qemu-dm-PRECISEHVM.log ------------------------- do_spice_init: starting 0.10.1 spice_server_add_interface: SPICE_INTERFACE_MIGRATION spice_server_add_interface: SPICE_INTERFACE_KEYBOARD spice_server_add_interface: SPICE_INTERFACE_MOUSE qemu: hardware error: xen: failed to populate ram at 3f800000 CPU #0: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 CPU #1: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 ------------------------------- videoram seems reserve the ram and from X log QXL videoram seems to be at correct size but probably qemu can't use it. -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5691285.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:14:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPdm-0008RR-N5; Mon, 07 May 2012 15:14:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPdl-0008RM-Cd for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:14:21 +0000 Received: from [85.158.139.83:9200] by server-11.bemta-5.messagelabs.com id 22/FE-12959-CC6E7AF4; Mon, 07 May 2012 15:14:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336403659!26590446!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18736 invoked from network); 7 May 2012 15:14:19 -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; 7 May 2012 15:14:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:54:08 +0100 Message-Id: <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:54:04 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> In-Reply-To: <4FA7DF2B.3020000@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 16:41, Andrew Cooper wrote: > It appears we have two functions to dump the IO-APIC state: > __print_IO_APIC() which gets called on boot and from 'z', and > dump_ioapic_irq_info() which gets called from the end of 'i'. These > should probably be consolidated somehow. Rather not - 'z' provides information on the IO-APIC that isn't directly related to specific interrupts, while 'i' (when it comes to the IO-APIC) is exclusively interested in the RTEs. Unless dump_ioapic_irq_info() is _fully_ redundant with 'z' (didn't check in detail yet), in which case I'd vote for removing this function. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:14:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPdm-0008RR-N5; Mon, 07 May 2012 15:14:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPdl-0008RM-Cd for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:14:21 +0000 Received: from [85.158.139.83:9200] by server-11.bemta-5.messagelabs.com id 22/FE-12959-CC6E7AF4; Mon, 07 May 2012 15:14:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336403659!26590446!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18736 invoked from network); 7 May 2012 15:14:19 -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; 7 May 2012 15:14:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 15:54:08 +0100 Message-Id: <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 15:54:04 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> In-Reply-To: <4FA7DF2B.3020000@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 16:41, Andrew Cooper wrote: > It appears we have two functions to dump the IO-APIC state: > __print_IO_APIC() which gets called on boot and from 'z', and > dump_ioapic_irq_info() which gets called from the end of 'i'. These > should probably be consolidated somehow. Rather not - 'z' provides information on the IO-APIC that isn't directly related to specific interrupts, while 'i' (when it comes to the IO-APIC) is exclusively interested in the RTEs. Unless dump_ioapic_irq_info() is _fully_ redundant with 'z' (didn't check in detail yet), in which case I'd vote for removing this function. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:29:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPsO-0000A3-67; Mon, 07 May 2012 15:29:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPsN-00009y-FV for xen-devel@lists.xen.org; Mon, 07 May 2012 15:29:27 +0000 Received: from [85.158.143.35:50842] by server-1.bemta-4.messagelabs.com id 40/5E-20925-65AE7AF4; Mon, 07 May 2012 15:29:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336404565!14446213!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17077 invoked from network); 7 May 2012 15:29:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:29:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 16:29:25 +0100 Message-Id: <4FA8067302000078000820E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 16:29:23 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2907CC43.0__=" Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2907CC43.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - no need to read BAR during suspend - command register is 16-bits rather than 32 - BAR and command register must be restored before trying to access the device - use ps_bdf[] for storing the device coordinates (pb_bdf[] is used to store the bridge's ones) --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -49,7 +49,9 @@ static struct ns16550 { unsigned int ps_bdf[3]; /* pci serial port BDF */ bool_t pb_bdf_enable; /* if =3D1, pb-bdf effective, port behind = bridge */ bool_t ps_bdf_enable; /* if =3D1, ps_bdf effective, port on pci = card */ - int bar, cr, bar_idx; + u32 bar; + u16 cr; + u8 bar_idx; } ns16550_com[2] =3D { { 0 } }; =20 /* Register offsets */ @@ -324,30 +326,24 @@ static void ns16550_suspend(struct seria stop_timer(&uart->timer); =20 if ( uart->bar ) - { - uart->bar =3D pci_conf_read32( - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], - PCI_BASE_ADDRESS_0 + uart->bar_idx*4); - uart->cr =3D pci_conf_read32( - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], - PCI_COMMAND); - } + uart->cr =3D pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1], + uart->ps_bdf[2], PCI_COMMAND); } =20 static void ns16550_resume(struct serial_port *port) { struct ns16550 *uart =3D port->uart; =20 - ns16550_setup_preirq(port->uart); - ns16550_setup_postirq(port->uart); - if ( uart->bar ) { - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], + pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[= 2], PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar); - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], + pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[= 2], PCI_COMMAND, uart->cr); } + + ns16550_setup_preirq(port->uart); + ns16550_setup_postirq(port->uart); } =20 #ifdef CONFIG_X86 @@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i if ( (len & 0xffff) !=3D 0xfff9 ) continue; =20 - uart->pb_bdf[0] =3D b; - uart->pb_bdf[1] =3D d; - uart->pb_bdf[2] =3D f; + uart->ps_bdf[0] =3D b; + uart->ps_bdf[1] =3D d; + uart->ps_bdf[2] =3D f; uart->bar =3D bar; uart->bar_idx =3D bar_idx; uart->io_base =3D bar & 0xfffe; --=__Part2907CC43.0__= Content-Type: text/plain; name="sercon-ns16550-suspend.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sercon-ns16550-suspend.patch" ns16550: adjust suspend/resume logic=0A=0A- no need to read BAR during = suspend=0A- command register is 16-bits rather than 32=0A- BAR and command = register must be restored before trying to access=0A the device=0A- use = ps_bdf[] for storing the device coordinates (pb_bdf[] is used to=0A store = the bridge's ones)=0A=0A--- a/xen/drivers/char/ns16550.c=0A+++ b/xen/driver= s/char/ns16550.c=0A@@ -49,7 +49,9 @@ static struct ns16550 {=0A = unsigned int ps_bdf[3]; /* pci serial port BDF */=0A bool_t pb_bdf_enab= le; /* if =3D1, pb-bdf effective, port behind bridge */=0A bool_t = ps_bdf_enable; /* if =3D1, ps_bdf effective, port on pci card */=0A- = int bar, cr, bar_idx;=0A+ u32 bar;=0A+ u16 cr;=0A+ u8 bar_idx;=0A = } ns16550_com[2] =3D { { 0 } };=0A =0A /* Register offsets */=0A@@ -324,30 = +326,24 @@ static void ns16550_suspend(struct seria=0A stop_timer(&uart= ->timer);=0A =0A if ( uart->bar )=0A- {=0A- uart->bar =3D = pci_conf_read32(=0A- 0, uart->pb_bdf[0], uart->pb_bdf[1], = uart->pb_bdf[2],=0A- PCI_BASE_ADDRESS_0 + uart->bar_idx*4);=0A- = uart->cr =3D pci_conf_read32(=0A- 0, uart->pb_bdf[0], = uart->pb_bdf[1], uart->pb_bdf[2],=0A- PCI_COMMAND);=0A- }=0A+ = uart->cr =3D pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1],=0A+= uart->ps_bdf[2], PCI_COMMAND);=0A }=0A = =0A static void ns16550_resume(struct serial_port *port)=0A {=0A = struct ns16550 *uart =3D port->uart;=0A =0A- ns16550_setup_preirq(port->= uart);=0A- ns16550_setup_postirq(port->uart);=0A-=0A if ( uart->bar = )=0A {=0A- pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], = uart->pb_bdf[2],=0A+ pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bd= f[1], uart->ps_bdf[2],=0A PCI_BASE_ADDRESS_0 + = uart->bar_idx*4, uart->bar);=0A- pci_conf_write32(0, uart->pb_bdf[0],= uart->pb_bdf[1], uart->pb_bdf[2],=0A+ pci_conf_write16(0, uart->ps_b= df[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A = PCI_COMMAND, uart->cr);=0A }=0A+=0A+ ns16550_setup_preirq(port->uart= );=0A+ ns16550_setup_postirq(port->uart);=0A }=0A =0A #ifdef CONFIG_X86= =0A@@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i=0A = if ( (len & 0xffff) !=3D 0xfff9 )=0A = continue;=0A =0A- uart->pb_bdf[0] =3D b;=0A- = uart->pb_bdf[1] =3D d;=0A- uart->pb_bdf[2] =3D f;=0A+ = uart->ps_bdf[0] =3D b;=0A+ uart->ps_bdf[1] =3D = d;=0A+ uart->ps_bdf[2] =3D f;=0A uart->bar = =3D bar;=0A uart->bar_idx =3D bar_idx;=0A = uart->io_base =3D bar & 0xfffe;=0A --=__Part2907CC43.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2907CC43.0__=-- From xen-devel-bounces@lists.xen.org Mon May 07 15:29:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPsO-0000A3-67; Mon, 07 May 2012 15:29:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPsN-00009y-FV for xen-devel@lists.xen.org; Mon, 07 May 2012 15:29:27 +0000 Received: from [85.158.143.35:50842] by server-1.bemta-4.messagelabs.com id 40/5E-20925-65AE7AF4; Mon, 07 May 2012 15:29:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336404565!14446213!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17077 invoked from network); 7 May 2012 15:29:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:29:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 16:29:25 +0100 Message-Id: <4FA8067302000078000820E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 16:29:23 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2907CC43.0__=" Cc: Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2907CC43.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - no need to read BAR during suspend - command register is 16-bits rather than 32 - BAR and command register must be restored before trying to access the device - use ps_bdf[] for storing the device coordinates (pb_bdf[] is used to store the bridge's ones) --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -49,7 +49,9 @@ static struct ns16550 { unsigned int ps_bdf[3]; /* pci serial port BDF */ bool_t pb_bdf_enable; /* if =3D1, pb-bdf effective, port behind = bridge */ bool_t ps_bdf_enable; /* if =3D1, ps_bdf effective, port on pci = card */ - int bar, cr, bar_idx; + u32 bar; + u16 cr; + u8 bar_idx; } ns16550_com[2] =3D { { 0 } }; =20 /* Register offsets */ @@ -324,30 +326,24 @@ static void ns16550_suspend(struct seria stop_timer(&uart->timer); =20 if ( uart->bar ) - { - uart->bar =3D pci_conf_read32( - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], - PCI_BASE_ADDRESS_0 + uart->bar_idx*4); - uart->cr =3D pci_conf_read32( - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], - PCI_COMMAND); - } + uart->cr =3D pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1], + uart->ps_bdf[2], PCI_COMMAND); } =20 static void ns16550_resume(struct serial_port *port) { struct ns16550 *uart =3D port->uart; =20 - ns16550_setup_preirq(port->uart); - ns16550_setup_postirq(port->uart); - if ( uart->bar ) { - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], + pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[= 2], PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar); - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[= 2], + pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[= 2], PCI_COMMAND, uart->cr); } + + ns16550_setup_preirq(port->uart); + ns16550_setup_postirq(port->uart); } =20 #ifdef CONFIG_X86 @@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i if ( (len & 0xffff) !=3D 0xfff9 ) continue; =20 - uart->pb_bdf[0] =3D b; - uart->pb_bdf[1] =3D d; - uart->pb_bdf[2] =3D f; + uart->ps_bdf[0] =3D b; + uart->ps_bdf[1] =3D d; + uart->ps_bdf[2] =3D f; uart->bar =3D bar; uart->bar_idx =3D bar_idx; uart->io_base =3D bar & 0xfffe; --=__Part2907CC43.0__= Content-Type: text/plain; name="sercon-ns16550-suspend.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sercon-ns16550-suspend.patch" ns16550: adjust suspend/resume logic=0A=0A- no need to read BAR during = suspend=0A- command register is 16-bits rather than 32=0A- BAR and command = register must be restored before trying to access=0A the device=0A- use = ps_bdf[] for storing the device coordinates (pb_bdf[] is used to=0A store = the bridge's ones)=0A=0A--- a/xen/drivers/char/ns16550.c=0A+++ b/xen/driver= s/char/ns16550.c=0A@@ -49,7 +49,9 @@ static struct ns16550 {=0A = unsigned int ps_bdf[3]; /* pci serial port BDF */=0A bool_t pb_bdf_enab= le; /* if =3D1, pb-bdf effective, port behind bridge */=0A bool_t = ps_bdf_enable; /* if =3D1, ps_bdf effective, port on pci card */=0A- = int bar, cr, bar_idx;=0A+ u32 bar;=0A+ u16 cr;=0A+ u8 bar_idx;=0A = } ns16550_com[2] =3D { { 0 } };=0A =0A /* Register offsets */=0A@@ -324,30 = +326,24 @@ static void ns16550_suspend(struct seria=0A stop_timer(&uart= ->timer);=0A =0A if ( uart->bar )=0A- {=0A- uart->bar =3D = pci_conf_read32(=0A- 0, uart->pb_bdf[0], uart->pb_bdf[1], = uart->pb_bdf[2],=0A- PCI_BASE_ADDRESS_0 + uart->bar_idx*4);=0A- = uart->cr =3D pci_conf_read32(=0A- 0, uart->pb_bdf[0], = uart->pb_bdf[1], uart->pb_bdf[2],=0A- PCI_COMMAND);=0A- }=0A+ = uart->cr =3D pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1],=0A+= uart->ps_bdf[2], PCI_COMMAND);=0A }=0A = =0A static void ns16550_resume(struct serial_port *port)=0A {=0A = struct ns16550 *uart =3D port->uart;=0A =0A- ns16550_setup_preirq(port->= uart);=0A- ns16550_setup_postirq(port->uart);=0A-=0A if ( uart->bar = )=0A {=0A- pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], = uart->pb_bdf[2],=0A+ pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bd= f[1], uart->ps_bdf[2],=0A PCI_BASE_ADDRESS_0 + = uart->bar_idx*4, uart->bar);=0A- pci_conf_write32(0, uart->pb_bdf[0],= uart->pb_bdf[1], uart->pb_bdf[2],=0A+ pci_conf_write16(0, uart->ps_b= df[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A = PCI_COMMAND, uart->cr);=0A }=0A+=0A+ ns16550_setup_preirq(port->uart= );=0A+ ns16550_setup_postirq(port->uart);=0A }=0A =0A #ifdef CONFIG_X86= =0A@@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i=0A = if ( (len & 0xffff) !=3D 0xfff9 )=0A = continue;=0A =0A- uart->pb_bdf[0] =3D b;=0A- = uart->pb_bdf[1] =3D d;=0A- uart->pb_bdf[2] =3D f;=0A+ = uart->ps_bdf[0] =3D b;=0A+ uart->ps_bdf[1] =3D = d;=0A+ uart->ps_bdf[2] =3D f;=0A uart->bar = =3D bar;=0A uart->bar_idx =3D bar_idx;=0A = uart->io_base =3D bar & 0xfffe;=0A --=__Part2907CC43.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2907CC43.0__=-- From xen-devel-bounces@lists.xen.org Mon May 07 15:36:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPzA-0000Ny-MV; Mon, 07 May 2012 15:36:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPz9-0000Nk-2C for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:36:27 +0000 Received: from [85.158.143.99:32460] by server-3.bemta-4.messagelabs.com id B0/35-05853-AFBE7AF4; Mon, 07 May 2012 15:36:26 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-5.tower-216.messagelabs.com!1336404984!26523681!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23987 invoked from network); 7 May 2012 15:36:25 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-5.tower-216.messagelabs.com with SMTP; 7 May 2012 15:36:25 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47FaMnV004882 for ; Mon, 7 May 2012 11:36:22 -0400 Message-ID: <4FA7EBF6.6040204@theshore.net> Date: Mon, 07 May 2012 11:36:22 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen devel Subject: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xen: 4.1.3-rc1-pre (xenbits @ 23285) Dom0: 3.2.6 PAE and 3.3.4 PAE We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove loop deployed to a few dozen boxes will hit it quite reliably within a short time. This happens on both an older LVM userspace and newest, and in production we have seen this hit on lvremove, lvrename, and lvdelete. #!/bin/bash while true; do lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 done BUG: unable to handle kernel paging request at bffff628 IP: [] __page_check_address+0xb8/0x170 *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 EIP: 0061:[] EFLAGS: 00010246 CPU: 6 EIP is at __page_check_address+0xb8/0x170 EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) Stack: e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 Call Trace: [] try_to_unmap_one+0x29/0x310 [] try_to_unmap_file+0x83/0x560 [] ? xen_pte_val+0xb9/0x140 [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [] ? vm_normal_page+0x28/0xc0 [] ? kmap_atomic_prot+0x45/0x110 [] try_to_munlock+0x1c/0x40 [] munlock_vma_page+0x49/0x90 [] munlock_vma_pages_range+0x57/0xa0 [] mlock_fixup+0xc2/0x130 [] do_mlockall+0x6c/0x80 [] sys_munlockall+0x29/0x50 [] sysenter_do_call+0x12/0x28 Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c CR2: 00000000bffff628 ---[ end trace 8039aeca9c19f5ab ]--- note: lvremove[27902] exited with preempt_count 1 BUG: scheduling while atomic: lvremove/27902/0x00000001 Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 Call Trace: [] __schedule_bug+0x5d/0x70 [] __schedule+0x679/0x830 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? rcu_enter_nohz+0x3c/0x60 [] ? xen_evtchn_do_upcall+0x20/0x30 [] ? hypercall_page+0x227/0x1000 [] ? xen_force_evtchn_callback+0x1a/0x30 [] schedule+0x30/0x50 [] rwsem_down_failed_common+0x9d/0xf0 [] rwsem_down_read_failed+0x12/0x14 [] call_rwsem_down_read_failed+0x7/0xc [] ? down_read+0xd/0x10 [] acct_collect+0x3a/0x170 [] do_exit+0x62a/0x7d0 [] ? kmsg_dump+0x37/0xc0 [] oops_end+0x90/0xd0 [] no_context+0xbe/0x190 [] __bad_area_nosemaphore+0x98/0x140 [] ? xen_clocksource_read+0x19/0x20 [] ? xen_vcpuop_set_next_event+0x47/0x80 [] bad_area_nosemaphore+0x12/0x20 [] do_page_fault+0x2d2/0x3f0 [] ? hrtimer_interrupt+0x1a9/0x2b0 [] ? xen_force_evtchn_callback+0x1a/0x30 [] ? check_events+0x8/0xc [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? _raw_spin_unlock_irqrestore+0x14/0x20 [] ? spurious_fault+0x130/0x130 [] error_code+0x5a/0x60 [] ? spurious_fault+0x130/0x130 [] ? __page_check_address+0xb8/0x170 [] try_to_unmap_one+0x29/0x310 [] try_to_unmap_file+0x83/0x560 [] ? xen_pte_val+0xb9/0x140 [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [] ? vm_normal_page+0x28/0xc0 [] ? kmap_atomic_prot+0x45/0x110 [] try_to_munlock+0x1c/0x40 [] munlock_vma_page+0x49/0x90 [] munlock_vma_pages_range+0x57/0xa0 [] mlock_fixup+0xc2/0x130 [] do_mlockall+0x6c/0x80 [] sys_munlockall+0x29/0x50 [] sysenter_do_call+0x12/0x28 Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:36:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRPzA-0000Ny-MV; Mon, 07 May 2012 15:36:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRPz9-0000Nk-2C for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:36:27 +0000 Received: from [85.158.143.99:32460] by server-3.bemta-4.messagelabs.com id B0/35-05853-AFBE7AF4; Mon, 07 May 2012 15:36:26 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-5.tower-216.messagelabs.com!1336404984!26523681!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23987 invoked from network); 7 May 2012 15:36:25 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-5.tower-216.messagelabs.com with SMTP; 7 May 2012 15:36:25 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47FaMnV004882 for ; Mon, 7 May 2012 11:36:22 -0400 Message-ID: <4FA7EBF6.6040204@theshore.net> Date: Mon, 07 May 2012 11:36:22 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen devel Subject: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xen: 4.1.3-rc1-pre (xenbits @ 23285) Dom0: 3.2.6 PAE and 3.3.4 PAE We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove loop deployed to a few dozen boxes will hit it quite reliably within a short time. This happens on both an older LVM userspace and newest, and in production we have seen this hit on lvremove, lvrename, and lvdelete. #!/bin/bash while true; do lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 done BUG: unable to handle kernel paging request at bffff628 IP: [] __page_check_address+0xb8/0x170 *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 EIP: 0061:[] EFLAGS: 00010246 CPU: 6 EIP is at __page_check_address+0xb8/0x170 EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) Stack: e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 Call Trace: [] try_to_unmap_one+0x29/0x310 [] try_to_unmap_file+0x83/0x560 [] ? xen_pte_val+0xb9/0x140 [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [] ? vm_normal_page+0x28/0xc0 [] ? kmap_atomic_prot+0x45/0x110 [] try_to_munlock+0x1c/0x40 [] munlock_vma_page+0x49/0x90 [] munlock_vma_pages_range+0x57/0xa0 [] mlock_fixup+0xc2/0x130 [] do_mlockall+0x6c/0x80 [] sys_munlockall+0x29/0x50 [] sysenter_do_call+0x12/0x28 Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c CR2: 00000000bffff628 ---[ end trace 8039aeca9c19f5ab ]--- note: lvremove[27902] exited with preempt_count 1 BUG: scheduling while atomic: lvremove/27902/0x00000001 Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 Call Trace: [] __schedule_bug+0x5d/0x70 [] __schedule+0x679/0x830 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? rcu_enter_nohz+0x3c/0x60 [] ? xen_evtchn_do_upcall+0x20/0x30 [] ? hypercall_page+0x227/0x1000 [] ? xen_force_evtchn_callback+0x1a/0x30 [] schedule+0x30/0x50 [] rwsem_down_failed_common+0x9d/0xf0 [] rwsem_down_read_failed+0x12/0x14 [] call_rwsem_down_read_failed+0x7/0xc [] ? down_read+0xd/0x10 [] acct_collect+0x3a/0x170 [] do_exit+0x62a/0x7d0 [] ? kmsg_dump+0x37/0xc0 [] oops_end+0x90/0xd0 [] no_context+0xbe/0x190 [] __bad_area_nosemaphore+0x98/0x140 [] ? xen_clocksource_read+0x19/0x20 [] ? xen_vcpuop_set_next_event+0x47/0x80 [] bad_area_nosemaphore+0x12/0x20 [] do_page_fault+0x2d2/0x3f0 [] ? hrtimer_interrupt+0x1a9/0x2b0 [] ? xen_force_evtchn_callback+0x1a/0x30 [] ? check_events+0x8/0xc [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? _raw_spin_unlock_irqrestore+0x14/0x20 [] ? spurious_fault+0x130/0x130 [] error_code+0x5a/0x60 [] ? spurious_fault+0x130/0x130 [] ? __page_check_address+0xb8/0x170 [] try_to_unmap_one+0x29/0x310 [] try_to_unmap_file+0x83/0x560 [] ? xen_pte_val+0xb9/0x140 [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [] ? vm_normal_page+0x28/0xc0 [] ? kmap_atomic_prot+0x45/0x110 [] try_to_munlock+0x1c/0x40 [] munlock_vma_page+0x49/0x90 [] munlock_vma_pages_range+0x57/0xa0 [] mlock_fixup+0xc2/0x130 [] do_mlockall+0x6c/0x80 [] sys_munlockall+0x29/0x50 [] sysenter_do_call+0x12/0x28 Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:40:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:40:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ31-0000e5-BI; Mon, 07 May 2012 15:40:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ2z-0000dr-6N for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:40:25 +0000 Received: from [85.158.143.35:58972] by server-3.bemta-4.messagelabs.com id 7E/18-05853-8ECE7AF4; Mon, 07 May 2012 15:40:24 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336405223!11813790!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29399 invoked from network); 7 May 2012 15:40:23 -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; 7 May 2012 15:40:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12333463" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 15:40:23 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 16:40:22 +0100 Message-ID: <4FA7ECE2.4080208@citrix.com> Date: Mon, 7 May 2012 16:40:18 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> In-Reply-To: <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:50, Jan Beulich wrote: >>>> On 07.05.12 at 16:41, Andrew Cooper wrote: >> Given that the legacy vectors cant migrate, is it wise including them in >> the loop in irq_move_cleanup_interrupt()? In fact, is it wise including >> any vector above LAST_DYNAMIC_VECTOR? > Likely not, but then again this is the final piece of moving an interrupt, > so there must have been something earlier that incorrectly initiated a > move. In other words, rather than fixing the loop here, we should > make sure execution can't even make it there for legacy vectors. > > And of course this is irrespective of the fact that no legacy interrupt > should occur in the first place, unless this is a very strange system. > > Jan > The only way to get to this point is if desc->arch.move_cleanup_count is non 0, in which case, one of these functions: hpet_msi_ack (hpet.c) ack_edge_ioapic_irq (io_apci.c) mask_and_ack_level_ioapic_irq (io_apic.c) ack_nonmaskable_msi_irq (msi.c) iommu_msi_mask (iommu_init.c) dma_msi_mask (iommu.c) has called irq_complete_move, after something has called __assign_irq_vector() to move the irq to another CPU. I would say something very fishy is going on - no desc used by any of those functions should have a vector from the legacy region. As for the loop, it is probably quite sensible to reduce that down to LAST_DYNAMIC_VECTOR. Leaving it at NR_VECTORS is just 32 wasted iterations of the loop in interrupt context. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:40:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:40:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ31-0000e5-BI; Mon, 07 May 2012 15:40:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ2z-0000dr-6N for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:40:25 +0000 Received: from [85.158.143.35:58972] by server-3.bemta-4.messagelabs.com id 7E/18-05853-8ECE7AF4; Mon, 07 May 2012 15:40:24 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336405223!11813790!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29399 invoked from network); 7 May 2012 15:40:23 -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; 7 May 2012 15:40:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12333463" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 15:40:23 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 16:40:22 +0100 Message-ID: <4FA7ECE2.4080208@citrix.com> Date: Mon, 7 May 2012 16:40:18 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> In-Reply-To: <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:50, Jan Beulich wrote: >>>> On 07.05.12 at 16:41, Andrew Cooper wrote: >> Given that the legacy vectors cant migrate, is it wise including them in >> the loop in irq_move_cleanup_interrupt()? In fact, is it wise including >> any vector above LAST_DYNAMIC_VECTOR? > Likely not, but then again this is the final piece of moving an interrupt, > so there must have been something earlier that incorrectly initiated a > move. In other words, rather than fixing the loop here, we should > make sure execution can't even make it there for legacy vectors. > > And of course this is irrespective of the fact that no legacy interrupt > should occur in the first place, unless this is a very strange system. > > Jan > The only way to get to this point is if desc->arch.move_cleanup_count is non 0, in which case, one of these functions: hpet_msi_ack (hpet.c) ack_edge_ioapic_irq (io_apci.c) mask_and_ack_level_ioapic_irq (io_apic.c) ack_nonmaskable_msi_irq (msi.c) iommu_msi_mask (iommu_init.c) dma_msi_mask (iommu.c) has called irq_complete_move, after something has called __assign_irq_vector() to move the irq to another CPU. I would say something very fishy is going on - no desc used by any of those functions should have a vector from the legacy region. As for the loop, it is probably quite sensible to reduce that down to LAST_DYNAMIC_VECTOR. Leaving it at NR_VECTORS is just 32 wasted iterations of the loop in interrupt context. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:43:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRQ66-0000nr-Uz; Mon, 07 May 2012 15:43:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ66-0000nf-8V for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:43:38 +0000 Received: from [85.158.138.51:47703] by server-6.bemta-3.messagelabs.com id E8/DE-05145-9ADE7AF4; Mon, 07 May 2012 15:43:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336405416!23919138!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24810 invoked from network); 7 May 2012 15:43:36 -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; 7 May 2012 15:43:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 16:43:35 +0100 Message-Id: <4FA809C40200007800082109@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 16:43:32 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> <4FA7ECE2.4080208@citrix.com> In-Reply-To: <4FA7ECE2.4080208@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel DeGraaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 17:40, Andrew Cooper wrote: > As for the loop, it is probably quite sensible to reduce that down to > LAST_DYNAMIC_VECTOR. Leaving it at NR_VECTORS is just 32 wasted > iterations of the loop in interrupt context. No, you can't leave there. You'd have to skip the legacy vectors, and continue with the ones Xen itself may have in use. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:43:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRQ66-0000nr-Uz; Mon, 07 May 2012 15:43:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ66-0000nf-8V for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:43:38 +0000 Received: from [85.158.138.51:47703] by server-6.bemta-3.messagelabs.com id E8/DE-05145-9ADE7AF4; Mon, 07 May 2012 15:43:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336405416!23919138!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1NjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24810 invoked from network); 7 May 2012 15:43:36 -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; 7 May 2012 15:43:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 07 May 2012 16:43:35 +0100 Message-Id: <4FA809C40200007800082109@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 07 May 2012 16:43:32 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FD3B02000078000820A3@nat28.tlf.novell.com> <4FA7ECE2.4080208@citrix.com> In-Reply-To: <4FA7ECE2.4080208@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel DeGraaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 17:40, Andrew Cooper wrote: > As for the loop, it is probably quite sensible to reduce that down to > LAST_DYNAMIC_VECTOR. Leaving it at NR_VECTORS is just 32 wasted > iterations of the loop in interrupt context. No, you can't leave there. You'd have to skip the legacy vectors, and continue with the ones Xen itself may have in use. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:47:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRQ9F-0000zA-He; Mon, 07 May 2012 15:46:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ9E-0000z3-0m for xen-devel@lists.xen.org; Mon, 07 May 2012 15:46:52 +0000 Received: from [85.158.138.51:6371] by server-6.bemta-3.messagelabs.com id CE/F1-05145-B6EE7AF4; Mon, 07 May 2012 15:46:51 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336405610!17789259!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12401 invoked from network); 7 May 2012 15:46:50 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 15:46:50 -0000 Received: by eaak12 with SMTP id k12so367809eaa.32 for ; Mon, 07 May 2012 08:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=p6OlVU2h3qCKsIFJGj8JtPU8WZqgrcp97ZpMlbV3ixY=; b=LwTTElUsDfklbuELVbWtHR4tx6CB+u3JD/HZv9C8jUrIvCqVrn4Z0QPPoON3nrK2ys 9e+PEt0UQEFt+9JzAM73+cNOg9aWvRi+ss9G6F5eBaUQ0cxglHiMuxWtztE/vT03Kbrj MYxnAdtKMmDo8HfhzIxYI7I7v2AwCIx+KIJEs3fqDqBKBuj965FLYlg8wo+YuRVu85at nJrGib+77lzWMnDm2QhktAVcn3Vdyc26UpvRlB+XTGz1g2PjLflY0/C8uHLcC6BlQmob vTe1rjMINTkr2MWJ4FOj+OTwX9gG6RRHlgvE2SdVFfRB6xoM0aef2FxRwwrBI+M5PjfE DtzA== Received: by 10.14.123.197 with SMTP id v45mr2771297eeh.49.1336405609617; Mon, 07 May 2012 08:46:49 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y54sm28241617eef.10.2012.05.07.08.46.48 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 08:46:48 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 16:46:45 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking Thread-Index: Ac0saJrc+QT5oWA4R0S/SCXD4kDqtQ== In-Reply-To: <4FA7F7810200007800082084@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:25, "Jan Beulich" wrote: > For xen.efi, this eliminates a pointless gap between .text and > .text.unlikely of almost 2Mb size. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -47,6 +47,8 @@ SECTIONS > .text : { > _stext = .; /* Text and read-only data */ > *(.text) > + *(.text.cold) > + *(.text.unlikely) > *(.fixup) > *(.gnu.warning) > _etext = .; /* End of text section */ > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:47:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRQ9F-0000zA-He; Mon, 07 May 2012 15:46:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQ9E-0000z3-0m for xen-devel@lists.xen.org; Mon, 07 May 2012 15:46:52 +0000 Received: from [85.158.138.51:6371] by server-6.bemta-3.messagelabs.com id CE/F1-05145-B6EE7AF4; Mon, 07 May 2012 15:46:51 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336405610!17789259!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12401 invoked from network); 7 May 2012 15:46:50 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 15:46:50 -0000 Received: by eaak12 with SMTP id k12so367809eaa.32 for ; Mon, 07 May 2012 08:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=p6OlVU2h3qCKsIFJGj8JtPU8WZqgrcp97ZpMlbV3ixY=; b=LwTTElUsDfklbuELVbWtHR4tx6CB+u3JD/HZv9C8jUrIvCqVrn4Z0QPPoON3nrK2ys 9e+PEt0UQEFt+9JzAM73+cNOg9aWvRi+ss9G6F5eBaUQ0cxglHiMuxWtztE/vT03Kbrj MYxnAdtKMmDo8HfhzIxYI7I7v2AwCIx+KIJEs3fqDqBKBuj965FLYlg8wo+YuRVu85at nJrGib+77lzWMnDm2QhktAVcn3Vdyc26UpvRlB+XTGz1g2PjLflY0/C8uHLcC6BlQmob vTe1rjMINTkr2MWJ4FOj+OTwX9gG6RRHlgvE2SdVFfRB6xoM0aef2FxRwwrBI+M5PjfE DtzA== Received: by 10.14.123.197 with SMTP id v45mr2771297eeh.49.1336405609617; Mon, 07 May 2012 08:46:49 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y54sm28241617eef.10.2012.05.07.08.46.48 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 08:46:48 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 16:46:45 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking Thread-Index: Ac0saJrc+QT5oWA4R0S/SCXD4kDqtQ== In-Reply-To: <4FA7F7810200007800082084@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86: merge .text.* into .text while linking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:25, "Jan Beulich" wrote: > For xen.efi, this eliminates a pointless gap between .text and > .text.unlikely of almost 2Mb size. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -47,6 +47,8 @@ SECTIONS > .text : { > _stext = .; /* Text and read-only data */ > *(.text) > + *(.text.cold) > + *(.text.unlikely) > *(.fixup) > *(.gnu.warning) > _etext = .; /* End of text section */ > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:48:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:48:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAB-00013f-WD; Mon, 07 May 2012 15:47:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAA-00013O-8G for xen-devel@lists.xen.org; Mon, 07 May 2012 15:47:50 +0000 Received: from [85.158.143.35:26645] by server-2.bemta-4.messagelabs.com id 56/99-17550-5AEE7AF4; Mon, 07 May 2012 15:47:49 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336405659!11837597!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26126 invoked from network); 7 May 2012 15:47:40 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 15:47:40 -0000 Received: by eekc4 with SMTP id c4so1044947eek.32 for ; Mon, 07 May 2012 08:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=i61ALCFS8s8UCmPIqX8m3tAZ8grcp2qlfaGy9/yaNVM=; b=xF1DQm6hteACZfXTXxLlUfPPTCnXq9hiVmK58dDHXxSOZQffXgJid8u1sUvpsgJ1c3 KqsnjHPqkgGqg1gX8zDpoahyVEuaLbsNJyOLg7xZ69VC4LwQOuH8Xavxyr9ed2zmzXqT hXXWifmDRjCaw37MtWs6aY5LuGfho0wmELs+2U/FxhBSNdRkzaMloqgBekId+mDR5i5E qLwnQpQRxjL6D35XgadVFAEIhCr2ra0EK+dIya/G0vkg24ydZ/ovEyJAycRTucMh73ch h3M2g3XPEwHVYbllSBpKcBH6kRV/XrcaZH70Ejs89NbWDpcnMWe3/e1rtK00G6jFEhBb jHBw== Received: by 10.14.119.77 with SMTP id m53mr1025721eeh.26.1336405658879; Mon, 07 May 2012 08:47:38 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm88029952eea.3.2012.05.07.08.47.36 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 08:47:38 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 16:47:34 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic Thread-Index: Ac0saLgRxdLf8h6vpEmupahQ7+VHfQ== In-Reply-To: <4FA8067302000078000820E4@nat28.tlf.novell.com> Mime-version: 1.0 Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 16:29, "Jan Beulich" wrote: > - no need to read BAR during suspend > - command register is 16-bits rather than 32 > - BAR and command register must be restored before trying to access > the device > - use ps_bdf[] for storing the device coordinates (pb_bdf[] is used to > store the bridge's ones) Looks good to me. Acked-by: Keir Fraser > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -49,7 +49,9 @@ static struct ns16550 { > unsigned int ps_bdf[3]; /* pci serial port BDF */ > bool_t pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > bool_t ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */ > - int bar, cr, bar_idx; > + u32 bar; > + u16 cr; > + u8 bar_idx; > } ns16550_com[2] = { { 0 } }; > > /* Register offsets */ > @@ -324,30 +326,24 @@ static void ns16550_suspend(struct seria > stop_timer(&uart->timer); > > if ( uart->bar ) > - { > - uart->bar = pci_conf_read32( > - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > - PCI_BASE_ADDRESS_0 + uart->bar_idx*4); > - uart->cr = pci_conf_read32( > - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > - PCI_COMMAND); > - } > + uart->cr = pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1], > + uart->ps_bdf[2], PCI_COMMAND); > } > > static void ns16550_resume(struct serial_port *port) > { > struct ns16550 *uart = port->uart; > > - ns16550_setup_preirq(port->uart); > - ns16550_setup_postirq(port->uart); > - > if ( uart->bar ) > { > - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > + pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], > PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar); > - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > + pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], > PCI_COMMAND, uart->cr); > } > + > + ns16550_setup_preirq(port->uart); > + ns16550_setup_postirq(port->uart); > } > > #ifdef CONFIG_X86 > @@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i > if ( (len & 0xffff) != 0xfff9 ) > continue; > > - uart->pb_bdf[0] = b; > - uart->pb_bdf[1] = d; > - uart->pb_bdf[2] = f; > + uart->ps_bdf[0] = b; > + uart->ps_bdf[1] = d; > + uart->ps_bdf[2] = f; > uart->bar = bar; > uart->bar_idx = bar_idx; > uart->io_base = bar & 0xfffe; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:48:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:48:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAB-00013f-WD; Mon, 07 May 2012 15:47:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAA-00013O-8G for xen-devel@lists.xen.org; Mon, 07 May 2012 15:47:50 +0000 Received: from [85.158.143.35:26645] by server-2.bemta-4.messagelabs.com id 56/99-17550-5AEE7AF4; Mon, 07 May 2012 15:47:49 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336405659!11837597!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26126 invoked from network); 7 May 2012 15:47:40 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 15:47:40 -0000 Received: by eekc4 with SMTP id c4so1044947eek.32 for ; Mon, 07 May 2012 08:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=i61ALCFS8s8UCmPIqX8m3tAZ8grcp2qlfaGy9/yaNVM=; b=xF1DQm6hteACZfXTXxLlUfPPTCnXq9hiVmK58dDHXxSOZQffXgJid8u1sUvpsgJ1c3 KqsnjHPqkgGqg1gX8zDpoahyVEuaLbsNJyOLg7xZ69VC4LwQOuH8Xavxyr9ed2zmzXqT hXXWifmDRjCaw37MtWs6aY5LuGfho0wmELs+2U/FxhBSNdRkzaMloqgBekId+mDR5i5E qLwnQpQRxjL6D35XgadVFAEIhCr2ra0EK+dIya/G0vkg24ydZ/ovEyJAycRTucMh73ch h3M2g3XPEwHVYbllSBpKcBH6kRV/XrcaZH70Ejs89NbWDpcnMWe3/e1rtK00G6jFEhBb jHBw== Received: by 10.14.119.77 with SMTP id m53mr1025721eeh.26.1336405658879; Mon, 07 May 2012 08:47:38 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm88029952eea.3.2012.05.07.08.47.36 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 08:47:38 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 16:47:34 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic Thread-Index: Ac0saLgRxdLf8h6vpEmupahQ7+VHfQ== In-Reply-To: <4FA8067302000078000820E4@nat28.tlf.novell.com> Mime-version: 1.0 Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] ns16550: adjust suspend/resume logic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 16:29, "Jan Beulich" wrote: > - no need to read BAR during suspend > - command register is 16-bits rather than 32 > - BAR and command register must be restored before trying to access > the device > - use ps_bdf[] for storing the device coordinates (pb_bdf[] is used to > store the bridge's ones) Looks good to me. Acked-by: Keir Fraser > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -49,7 +49,9 @@ static struct ns16550 { > unsigned int ps_bdf[3]; /* pci serial port BDF */ > bool_t pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ > bool_t ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */ > - int bar, cr, bar_idx; > + u32 bar; > + u16 cr; > + u8 bar_idx; > } ns16550_com[2] = { { 0 } }; > > /* Register offsets */ > @@ -324,30 +326,24 @@ static void ns16550_suspend(struct seria > stop_timer(&uart->timer); > > if ( uart->bar ) > - { > - uart->bar = pci_conf_read32( > - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > - PCI_BASE_ADDRESS_0 + uart->bar_idx*4); > - uart->cr = pci_conf_read32( > - 0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > - PCI_COMMAND); > - } > + uart->cr = pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1], > + uart->ps_bdf[2], PCI_COMMAND); > } > > static void ns16550_resume(struct serial_port *port) > { > struct ns16550 *uart = port->uart; > > - ns16550_setup_preirq(port->uart); > - ns16550_setup_postirq(port->uart); > - > if ( uart->bar ) > { > - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > + pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], > PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar); > - pci_conf_write32(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf[2], > + pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], > PCI_COMMAND, uart->cr); > } > + > + ns16550_setup_preirq(port->uart); > + ns16550_setup_postirq(port->uart); > } > > #ifdef CONFIG_X86 > @@ -483,9 +479,9 @@ pci_uart_config (struct ns16550 *uart, i > if ( (len & 0xffff) != 0xfff9 ) > continue; > > - uart->pb_bdf[0] = b; > - uart->pb_bdf[1] = d; > - uart->pb_bdf[2] = f; > + uart->ps_bdf[0] = b; > + uart->ps_bdf[1] = d; > + uart->ps_bdf[2] = f; > uart->bar = bar; > uart->bar_idx = bar_idx; > uart->io_base = bar & 0xfffe; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:48:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:48:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAk-00018a-II; Mon, 07 May 2012 15:48:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAj-00018I-OQ for xen-devel@lists.xen.org; Mon, 07 May 2012 15:48:25 +0000 Received: from [85.158.143.99:50357] by server-2.bemta-4.messagelabs.com id 40/0A-17550-8CEE7AF4; Mon, 07 May 2012 15:48:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-216.messagelabs.com!1336405703!17085417!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21430 invoked from network); 7 May 2012 15:48:24 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:48:24 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (jored mo9) (RZmta 29.5 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m00268o47ElKGW ; Mon, 7 May 2012 17:48:20 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id E33FA18637; Mon, 7 May 2012 17:48:19 +0200 (CEST) Date: Mon, 7 May 2012 17:48:19 +0200 From: Olaf Hering To: George Dunlap Message-ID: <20120507154819.GA30760@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: Konrad Rzeszutek Wilk , Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, George Dunlap wrote: > Recently I pulled in new changesets from xen- and qemu-unstable, and > when creating a PV guest I'm getting errors like the stack trace > below. Is this likely to be caused by QEMU using AIO? It this a bug > in Xen or in the Debian kernel? Is there an easy way to turn off aio > using a config file so I can see if it is qemu's aio? I also hit bugs in the nfs code paths with the SuSE kernels. Try 'device_model_version="qemu-xen-traditional"' in your .cfg file. See changeset 25222:a095e157f280. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:48:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:48:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAk-00018a-II; Mon, 07 May 2012 15:48:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQAj-00018I-OQ for xen-devel@lists.xen.org; Mon, 07 May 2012 15:48:25 +0000 Received: from [85.158.143.99:50357] by server-2.bemta-4.messagelabs.com id 40/0A-17550-8CEE7AF4; Mon, 07 May 2012 15:48:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-8.tower-216.messagelabs.com!1336405703!17085417!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDE5MDc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21430 invoked from network); 7 May 2012 15:48:24 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:48:24 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (jored mo9) (RZmta 29.5 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m00268o47ElKGW ; Mon, 7 May 2012 17:48:20 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id E33FA18637; Mon, 7 May 2012 17:48:19 +0200 (CEST) Date: Mon, 7 May 2012 17:48:19 +0200 From: Olaf Hering To: George Dunlap Message-ID: <20120507154819.GA30760@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: Konrad Rzeszutek Wilk , Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel aio bug in Debian 2.6.32-5-xen kernel? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Apr 26, George Dunlap wrote: > Recently I pulled in new changesets from xen- and qemu-unstable, and > when creating a PV guest I'm getting errors like the stack trace > below. Is this likely to be caused by QEMU using AIO? It this a bug > in Xen or in the Debian kernel? Is there an easy way to turn off aio > using a config file so I can see if it is qemu's aio? I also hit bugs in the nfs code paths with the SuSE kernels. Try 'device_model_version="qemu-xen-traditional"' in your .cfg file. See changeset 25222:a095e157f280. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:51:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRQDn-0001ZZ-Q6; Mon, 07 May 2012 15:51:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQDm-0001ZL-RY for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:51:35 +0000 Received: from [85.158.143.99:65312] by server-1.bemta-4.messagelabs.com id F8/EE-20925-68FE7AF4; Mon, 07 May 2012 15:51:34 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336405893!23485863!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30304 invoked from network); 7 May 2012 15:51:33 -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; 7 May 2012 15:51:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12333609" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 15:51:33 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 16:51:32 +0100 Message-ID: <4FA7EF83.3030902@citrix.com> Date: Mon, 7 May 2012 16:51:31 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> In-Reply-To: <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:54, Jan Beulich wrote: >>>> On 07.05.12 at 16:41, Andrew Cooper wrote: >> It appears we have two functions to dump the IO-APIC state: >> __print_IO_APIC() which gets called on boot and from 'z', and >> dump_ioapic_irq_info() which gets called from the end of 'i'. These >> should probably be consolidated somehow. > Rather not - 'z' provides information on the IO-APIC that isn't > directly related to specific interrupts, while 'i' (when it comes to > the IO-APIC) is exclusively interested in the RTEs. Unless > dump_ioapic_irq_info() is _fully_ redundant with 'z' (didn't check > in detail yet), in which case I'd vote for removing this function. > > Jan > dump_ioapic_irq_info() loops through nr_irqs_gsi and uses irq_2_pin to work out which io-apic RTE to read and decode. __print_IO_APIC() loop through nr_ioapics, then through each RTE and decodes it. At the end, it loops through nr_irqs_gsi and matches irqs to ioapic:pin pairs. So they are probably different enough to be worth keeping. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:51:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15: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 ) id 1SRQDn-0001ZZ-Q6; Mon, 07 May 2012 15:51:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQDm-0001ZL-RY for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:51:35 +0000 Received: from [85.158.143.99:65312] by server-1.bemta-4.messagelabs.com id F8/EE-20925-68FE7AF4; Mon, 07 May 2012 15:51:34 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336405893!23485863!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30304 invoked from network); 7 May 2012 15:51:33 -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; 7 May 2012 15:51:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12333609" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 15:51:33 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 16:51:32 +0100 Message-ID: <4FA7EF83.3030902@citrix.com> Date: Mon, 7 May 2012 16:51:31 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> <4FA7DF2B.3020000@citrix.com> <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> In-Reply-To: <4FA7FE2C02000078000820A6@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 15:54, Jan Beulich wrote: >>>> On 07.05.12 at 16:41, Andrew Cooper wrote: >> It appears we have two functions to dump the IO-APIC state: >> __print_IO_APIC() which gets called on boot and from 'z', and >> dump_ioapic_irq_info() which gets called from the end of 'i'. These >> should probably be consolidated somehow. > Rather not - 'z' provides information on the IO-APIC that isn't > directly related to specific interrupts, while 'i' (when it comes to > the IO-APIC) is exclusively interested in the RTEs. Unless > dump_ioapic_irq_info() is _fully_ redundant with 'z' (didn't check > in detail yet), in which case I'd vote for removing this function. > > Jan > dump_ioapic_irq_info() loops through nr_irqs_gsi and uses irq_2_pin to work out which io-apic RTE to read and decode. __print_IO_APIC() loop through nr_ioapics, then through each RTE and decodes it. At the end, it loops through nr_irqs_gsi and matches irqs to ioapic:pin pairs. So they are probably different enough to be worth keeping. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:54:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:54:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQGO-0001uU-0Q; Mon, 07 May 2012 15:54:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQGM-0001uJ-Ou for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:54:14 +0000 Received: from [85.158.139.83:41342] by server-6.bemta-5.messagelabs.com id C8/C9-13222-520F7AF4; Mon, 07 May 2012 15:54:13 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-182.messagelabs.com!1336406052!26594938!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODc4ODQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODc4ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1265 invoked from network); 7 May 2012 15:54:13 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:54:13 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (josoe mo34) (RZmta 29.4 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j03ab0o47EJmcs for ; Mon, 7 May 2012 17:54:12 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0E61518630 for ; Mon, 7 May 2012 17:54:12 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: aa4a499106c37c60f955662da81000db559ab5be Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Mon, 07 May 2012 17:54:11 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336406048 -7200 # Node ID aa4a499106c37c60f955662da81000db559ab5be # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 xl.cfg: fix typo in opengl section Add missing i to qemu-xen-traditonal Signed-off-by: Olaf Hering diff -r 0f53540494f7 -r aa4a499106c3 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -278,7 +278,7 @@ Simple DirectMedia Layer). The default i =item C Enable OpenGL acceleration of the SDL display. Only effects machines -using C and only if the +using C and only if the device-model was compiled with OpenGL support. Disabled by default. =item C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 15:54:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 15:54:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQGO-0001uU-0Q; Mon, 07 May 2012 15:54:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQGM-0001uJ-Ou for xen-devel@lists.xensource.com; Mon, 07 May 2012 15:54:14 +0000 Received: from [85.158.139.83:41342] by server-6.bemta-5.messagelabs.com id C8/C9-13222-520F7AF4; Mon, 07 May 2012 15:54:13 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-182.messagelabs.com!1336406052!26594938!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODc4ODQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyODc4ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1265 invoked from network); 7 May 2012 15:54:13 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 15:54:13 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3M7qEP8j X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-075-125.pools.arcor-ip.net [84.57.75.125]) by smtp.strato.de (josoe mo34) (RZmta 29.4 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j03ab0o47EJmcs for ; Mon, 7 May 2012 17:54:12 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0E61518630 for ; Mon, 7 May 2012 17:54:12 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: aa4a499106c37c60f955662da81000db559ab5be Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Mon, 07 May 2012 17:54:11 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336406048 -7200 # Node ID aa4a499106c37c60f955662da81000db559ab5be # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 xl.cfg: fix typo in opengl section Add missing i to qemu-xen-traditonal Signed-off-by: Olaf Hering diff -r 0f53540494f7 -r aa4a499106c3 docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -278,7 +278,7 @@ Simple DirectMedia Layer). The default i =item C Enable OpenGL acceleration of the SDL display. Only effects machines -using C and only if the +using C and only if the device-model was compiled with OpenGL support. Disabled by default. =item C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 16:13:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 16: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 ) id 1SRQZ1-0003AA-Dh; Mon, 07 May 2012 16:13:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQZ0-0003A5-73 for xen-devel@lists.xen.org; Mon, 07 May 2012 16:13:30 +0000 Received: from [193.109.254.147:29620] by server-8.bemta-14.messagelabs.com id A4/1D-23244-9A4F7AF4; Mon, 07 May 2012 16:13:29 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336407207!2875446!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 909 invoked from network); 7 May 2012 16:13:28 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 16:13:28 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47GDLTR006425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 16:13:22 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 q47GDKQ7016905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 16:13:20 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 q47GDIJ9011952; Mon, 7 May 2012 11:13:18 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 09:13:18 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DC5344031D; Mon, 7 May 2012 12:07:29 -0400 (EDT) Date: Mon, 7 May 2012 12:07:29 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120507160729.GA30800@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: weidong.han@intel.com, Jeremy Fitzhardinge , Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 08:15:44AM +0100, Jan Beulich wrote: > >>> On 04.05.12 at 21:30, AP wrote: > > From the above I realized that X86_CR4_OSXSAVE was never getting set > > in v->arch.pv_vcpu.ctrlreg[4]. > > Yes, that was the observation in the previous thread too, but the > reporter didn't seem interested in continuing on from there. > > > > So I tried the following patch: > > > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > > --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 > > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > > hv_cr4_mask &= ~X86_CR4_DE; > > if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > > hv_cr4_mask &= ~X86_CR4_FSGSBASE; > > - if ( xsave_enabled(v) ) > > - hv_cr4_mask &= ~X86_CR4_OSXSAVE; > > > > if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) > > gdprintk(XENLOG_WARNING, > > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > > --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 > > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > > & ~X86_CR4_DE) > > #define real_cr4_to_pv_guest_cr4(c) \ > > ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ > > - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > > + | X86_CR4_SMEP)) > > > > void domain_cpuid(struct domain *d, > > unsigned int input, > > No, this is specifically the wrong thing. From what we know so far > (i.e. the outcome of the above printing you added) the problem in > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > attempting XSETBV). What your patch efectively does is take away > control from the guest kernels to control the (virtual) CR4 flag... > > > That allowed the system to boot successfully though I did see the > > following message: > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > ... which is what this message is telling you. > > > Not sure if the above patch is right fix but I hope it was at least > > helpful in pointing at where the problem might be. > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. > > Sure, as it's a kernel problem. It's the kernel that needs logging added, > to find out why the CR4 write supposedly happening immediately > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > happen, or doesn't set the flag. Perhaps something fishy going on > with the paravirt ops patching, since the disassembly of the opcode > bytes shown with the oops message are indicating that the right > thing is being attempted: > > ff 14 25 10 33 c1 81 callq *0xffffffff81c13310 [so xen_read_cr4 which is native_read_cr4] > 48 89 c7 mov %rax,%rdi > 48 81 cf 00 00 04 00 or $0x40000,%rdi > ^^^^^^^^ > ff 14 25 18 33 c1 81 callq *0xffffffff81c13318 [so xen_write_cr4] - which is filtering X86_CR4_PGE and X86_CR4_PSE] > 48 8b 05 0d 15 db 00 mov 0xdb150d(%rip),%rax > 31 c9 xor %ecx,%ecx > 48 89 c2 mov %rax,%rdx > 48 c1 ea 20 shr $0x20,%rdx > 0f 01 d1 xsetbv > 5d pop %rbp > c3 retq > > The primary thing that strikes me as odd is that both calls are still > indirect ones, even though I thought that they should get replaced > by direct ones (or even the actual instruction, namely in the > read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? They do get replaced (during runtime - and this is done by the alternative_instructions). Is this output from objdump or straight from the memory (so using the Xen debugger?). > > And the dumped %rdi value indicates that bit 18 did _not_ get set. That would imply that xen_write_cr4, which is just mov to cr4 is getting trapped but somehow the hypervisor isn't setting the rdi value? Or maybe the the native_write_cr4 ends up filtering in the wrong order? 0xffffffff8102e650 : push %rbp 0xffffffff8102e651 : and $0x6f,%dil 0xffffffff8102e655 : mov %rsp,%rbp 0xffffffff8102e658 : mov %rdi,%cr4 0xffffffff8102e65b : leaveq 0xffffffff8102e65c : retq > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 16:13:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 16: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 ) id 1SRQZ1-0003AA-Dh; Mon, 07 May 2012 16:13:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQZ0-0003A5-73 for xen-devel@lists.xen.org; Mon, 07 May 2012 16:13:30 +0000 Received: from [193.109.254.147:29620] by server-8.bemta-14.messagelabs.com id A4/1D-23244-9A4F7AF4; Mon, 07 May 2012 16:13:29 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336407207!2875446!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 909 invoked from network); 7 May 2012 16:13:28 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 16:13:28 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47GDLTR006425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 16:13:22 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 q47GDKQ7016905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 16:13:20 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 q47GDIJ9011952; Mon, 7 May 2012 11:13:18 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 09:13:18 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DC5344031D; Mon, 7 May 2012 12:07:29 -0400 (EDT) Date: Mon, 7 May 2012 12:07:29 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120507160729.GA30800@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: weidong.han@intel.com, Jeremy Fitzhardinge , Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 08:15:44AM +0100, Jan Beulich wrote: > >>> On 04.05.12 at 21:30, AP wrote: > > From the above I realized that X86_CR4_OSXSAVE was never getting set > > in v->arch.pv_vcpu.ctrlreg[4]. > > Yes, that was the observation in the previous thread too, but the > reporter didn't seem interested in continuing on from there. > > > > So I tried the following patch: > > > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > > --- a/xen/arch/x86/domain.c Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/arch/x86/domain.c Fri May 04 12:23:57 2012 -0700 > > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > > hv_cr4_mask &= ~X86_CR4_DE; > > if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > > hv_cr4_mask &= ~X86_CR4_FSGSBASE; > > - if ( xsave_enabled(v) ) > > - hv_cr4_mask &= ~X86_CR4_OSXSAVE; > > > > if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) ) > > gdprintk(XENLOG_WARNING, > > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > > --- a/xen/include/asm-x86/domain.h Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/include/asm-x86/domain.h Fri May 04 12:23:57 2012 -0700 > > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > > & ~X86_CR4_DE) > > #define real_cr4_to_pv_guest_cr4(c) \ > > ((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD \ > > - | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > > + | X86_CR4_SMEP)) > > > > void domain_cpuid(struct domain *d, > > unsigned int input, > > No, this is specifically the wrong thing. From what we know so far > (i.e. the outcome of the above printing you added) the problem in > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > attempting XSETBV). What your patch efectively does is take away > control from the guest kernels to control the (virtual) CR4 flag... > > > That allowed the system to boot successfully though I did see the > > following message: > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > ... which is what this message is telling you. > > > Not sure if the above patch is right fix but I hope it was at least > > helpful in pointing at where the problem might be. > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with xsave=1. > > Sure, as it's a kernel problem. It's the kernel that needs logging added, > to find out why the CR4 write supposedly happening immediately > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > happen, or doesn't set the flag. Perhaps something fishy going on > with the paravirt ops patching, since the disassembly of the opcode > bytes shown with the oops message are indicating that the right > thing is being attempted: > > ff 14 25 10 33 c1 81 callq *0xffffffff81c13310 [so xen_read_cr4 which is native_read_cr4] > 48 89 c7 mov %rax,%rdi > 48 81 cf 00 00 04 00 or $0x40000,%rdi > ^^^^^^^^ > ff 14 25 18 33 c1 81 callq *0xffffffff81c13318 [so xen_write_cr4] - which is filtering X86_CR4_PGE and X86_CR4_PSE] > 48 8b 05 0d 15 db 00 mov 0xdb150d(%rip),%rax > 31 c9 xor %ecx,%ecx > 48 89 c2 mov %rax,%rdx > 48 c1 ea 20 shr $0x20,%rdx > 0f 01 d1 xsetbv > 5d pop %rbp > c3 retq > > The primary thing that strikes me as odd is that both calls are still > indirect ones, even though I thought that they should get replaced > by direct ones (or even the actual instruction, namely in the > read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? They do get replaced (during runtime - and this is done by the alternative_instructions). Is this output from objdump or straight from the memory (so using the Xen debugger?). > > And the dumped %rdi value indicates that bit 18 did _not_ get set. That would imply that xen_write_cr4, which is just mov to cr4 is getting trapped but somehow the hypervisor isn't setting the rdi value? Or maybe the the native_write_cr4 ends up filtering in the wrong order? 0xffffffff8102e650 : push %rbp 0xffffffff8102e651 : and $0x6f,%dil 0xffffffff8102e655 : mov %rsp,%rbp 0xffffffff8102e658 : mov %rdi,%cr4 0xffffffff8102e65b : leaveq 0xffffffff8102e65c : retq > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 16:38:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 16:38:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQwX-0003ib-5z; Mon, 07 May 2012 16:37:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQwW-0003iV-7h for xen-devel@lists.xensource.com; Mon, 07 May 2012 16:37:48 +0000 Received: from [193.109.254.147:29672] by server-2.bemta-14.messagelabs.com id BA/E7-19409-B5AF7AF4; Mon, 07 May 2012 16:37:47 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336408665!1172006!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10081 invoked from network); 7 May 2012 16:37:46 -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; 7 May 2012 16:37:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47GbfUK024387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 16:37: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 q47GbeRQ014109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 16:37:41 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 q47Gbefr018064; Mon, 7 May 2012 11:37:40 -0500 MIME-Version: 1.0 Message-ID: Date: Mon, 7 May 2012 09:37:23 -0700 (PDT) From: Dan Magenheimer To: Ian Campbell , Olaf Hering References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> In-Reply-To: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Sunday, May 06, 2012 3:36 AM > To: Olaf Hering > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > # HG changeset patch > > > > # User Olaf Hering > > > > # Date 1336159720 -7200 > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > xl.cfg: document the maxmem= option > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > --- a/docs/man/xl.cfg.pod.5 > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > mode) and your guest workload consists of a a very large number of > > > > similar processes then increasing this value may improve performance. > > > > > > > > +=item B > > > > + > > > > +Specifies the maximum amount of memory the HVM guest can ever see. can _ever_ see... What about guest OS's that support hotplug memory? Also, a subtle point, but is this the maximum physical address that will contain read/write pages or the maximum amount of RAM that the guest OS should be prepared to map as read/writeable (e.g. after subtracting off reserved e820 ranges) or ??? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 16:38:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 16:38:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQwX-0003ib-5z; Mon, 07 May 2012 16:37:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRQwW-0003iV-7h for xen-devel@lists.xensource.com; Mon, 07 May 2012 16:37:48 +0000 Received: from [193.109.254.147:29672] by server-2.bemta-14.messagelabs.com id BA/E7-19409-B5AF7AF4; Mon, 07 May 2012 16:37:47 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336408665!1172006!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE0MTE3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10081 invoked from network); 7 May 2012 16:37:46 -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; 7 May 2012 16:37:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47GbfUK024387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 16:37: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 q47GbeRQ014109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 16:37:41 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 q47Gbefr018064; Mon, 7 May 2012 11:37:40 -0500 MIME-Version: 1.0 Message-ID: Date: Mon, 7 May 2012 09:37:23 -0700 (PDT) From: Dan Magenheimer To: Ian Campbell , Olaf Hering References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> In-Reply-To: <1336296932.5933.9.camel@cthulhu.hellion.org.uk> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Sunday, May 06, 2012 3:36 AM > To: Olaf Hering > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > # HG changeset patch > > > > # User Olaf Hering > > > > # Date 1336159720 -7200 > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > xl.cfg: document the maxmem= option > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > --- a/docs/man/xl.cfg.pod.5 > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > mode) and your guest workload consists of a a very large number of > > > > similar processes then increasing this value may improve performance. > > > > > > > > +=item B > > > > + > > > > +Specifies the maximum amount of memory the HVM guest can ever see. can _ever_ see... What about guest OS's that support hotplug memory? Also, a subtle point, but is this the maximum physical address that will contain read/write pages or the maximum amount of RAM that the guest OS should be prepared to map as read/writeable (e.g. after subtracting off reserved e820 ranges) or ??? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:12:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:12:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRTD-0004HG-IW; Mon, 07 May 2012 17:11:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRTB-0004HA-T8 for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:11:34 +0000 Received: from [85.158.139.83:55788] by server-6.bemta-5.messagelabs.com id 5A/1C-13222-44208AF4; Mon, 07 May 2012 17:11:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336410690!27142193!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24506 invoked from network); 7 May 2012 17:11:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 17:11:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12336278" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 17:11: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, 7 May 2012 18:11:28 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRRT6-0001Zw-Fx; Mon, 07 May 2012 17:11:28 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRRT6-0008GZ-BE; Mon, 07 May 2012 18:11:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 18:11:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12794: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12794 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12794/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12793 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12792 test-amd64-amd64-xl-sedf 3 host-install(3) broken REGR. vs. 12793 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen b9eac81e8564 baseline version: xen 0f53540494f7 jobs: build-amd64 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-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf broken test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:12:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:12:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRTD-0004HG-IW; Mon, 07 May 2012 17:11:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRTB-0004HA-T8 for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:11:34 +0000 Received: from [85.158.139.83:55788] by server-6.bemta-5.messagelabs.com id 5A/1C-13222-44208AF4; Mon, 07 May 2012 17:11:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336410690!27142193!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24506 invoked from network); 7 May 2012 17:11:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 17:11:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="12336278" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 17:11: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, 7 May 2012 18:11:28 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRRT6-0001Zw-Fx; Mon, 07 May 2012 17:11:28 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRRT6-0008GZ-BE; Mon, 07 May 2012 18:11:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 18:11:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12794: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12794 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12794/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12793 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12792 test-amd64-amd64-xl-sedf 3 host-install(3) broken REGR. vs. 12793 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen b9eac81e8564 baseline version: xen 0f53540494f7 jobs: build-amd64 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-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf broken test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:18:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:18:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRZd-0004Tk-M4; Mon, 07 May 2012 17:18:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRZc-0004Tf-Qg for xen-devel@lists.xen.org; Mon, 07 May 2012 17:18:12 +0000 Received: from [85.158.138.51:15884] by server-7.bemta-3.messagelabs.com id D6/72-03078-3D308AF4; Mon, 07 May 2012 17:18:11 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-13.tower-174.messagelabs.com!1336411090!14730120!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6353 invoked from network); 7 May 2012 17:18:11 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-13.tower-174.messagelabs.com with SMTP; 7 May 2012 17:18:11 -0000 Received: (qmail 29135 invoked from network); 7 May 2012 19:18:09 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz X-Spam-Level: X-Spam-Status: No, score=-104.5 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; 7 May 2012 19:18:09 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Mon, 7 May 2012 19:18:08 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201205071918.09014.pavel@netsafe.cz> Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon 7. of May 2012 14:58:44 Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! > > -- Keir And which kernel should we use please? -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:18:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:18:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRZd-0004Tk-M4; Mon, 07 May 2012 17:18:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRZc-0004Tf-Qg for xen-devel@lists.xen.org; Mon, 07 May 2012 17:18:12 +0000 Received: from [85.158.138.51:15884] by server-7.bemta-3.messagelabs.com id D6/72-03078-3D308AF4; Mon, 07 May 2012 17:18:11 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-13.tower-174.messagelabs.com!1336411090!14730120!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6353 invoked from network); 7 May 2012 17:18:11 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-13.tower-174.messagelabs.com with SMTP; 7 May 2012 17:18:11 -0000 Received: (qmail 29135 invoked from network); 7 May 2012 19:18:09 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz X-Spam-Level: X-Spam-Status: No, score=-104.5 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; 7 May 2012 19:18:09 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Mon, 7 May 2012 19:18:08 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201205071918.09014.pavel@netsafe.cz> Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon 7. of May 2012 14:58:44 Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! > > -- Keir And which kernel should we use please? -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:23:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:23:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRReI-0004cH-De; Mon, 07 May 2012 17:23:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRReG-0004c6-8J for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:23:00 +0000 Received: from [85.158.143.99:48882] by server-1.bemta-4.messagelabs.com id B2/F9-20925-3F408AF4; Mon, 07 May 2012 17:22:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336411376!21614665!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12397 invoked from network); 7 May 2012 17:22:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:22:58 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47HMsIl018775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:22:55 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 q47HMr3W010549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:22:54 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 q47HMrUx018902; Mon, 7 May 2012 12:22:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:22:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 76FC34031D; Mon, 7 May 2012 13:17:03 -0400 (EDT) Date: Mon, 7 May 2012 13:17:03 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120507171703.GA5746@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE This looks suspicious like a fix that went in some time ago, ah: 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode but that went in 3.2 so that can't be it. Hm, can you give more details on what parameters you are passing to dom0 and the hypervisor so I can reproduce it? Also, could you send me your .config file? Is the underlaying storage SCSI? And is this only happening on these SuperMicro boxes or are you seeing this on other hardware as well? > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done > > BUG: unable to handle kernel paging request at bffff628 > IP: [] __page_check_address+0xb8/0x170 > *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 > EIP: 0061:[] EFLAGS: 00010246 CPU: 6 > EIP is at __page_check_address+0xb8/0x170 > EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 > ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 > Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) > Stack: > e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 > 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 > b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 > Call Trace: > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 > e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c > 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 > EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c > CR2: 00000000bffff628 > ---[ end trace 8039aeca9c19f5ab ]--- > note: lvremove[27902] exited with preempt_count 1 > BUG: scheduling while atomic: lvremove/27902/0x00000001 > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 > Call Trace: > [] __schedule_bug+0x5d/0x70 > [] __schedule+0x679/0x830 > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? rcu_enter_nohz+0x3c/0x60 > [] ? xen_evtchn_do_upcall+0x20/0x30 > [] ? hypercall_page+0x227/0x1000 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] schedule+0x30/0x50 > [] rwsem_down_failed_common+0x9d/0xf0 > [] rwsem_down_read_failed+0x12/0x14 > [] call_rwsem_down_read_failed+0x7/0xc > [] ? down_read+0xd/0x10 > [] acct_collect+0x3a/0x170 > [] do_exit+0x62a/0x7d0 > [] ? kmsg_dump+0x37/0xc0 > [] oops_end+0x90/0xd0 > [] no_context+0xbe/0x190 > [] __bad_area_nosemaphore+0x98/0x140 > [] ? xen_clocksource_read+0x19/0x20 > [] ? xen_vcpuop_set_next_event+0x47/0x80 > [] bad_area_nosemaphore+0x12/0x20 > [] do_page_fault+0x2d2/0x3f0 > [] ? hrtimer_interrupt+0x1a9/0x2b0 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] ? check_events+0x8/0xc > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? _raw_spin_unlock_irqrestore+0x14/0x20 > [] ? spurious_fault+0x130/0x130 > [] error_code+0x5a/0x60 > [] ? spurious_fault+0x130/0x130 > [] ? __page_check_address+0xb8/0x170 > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > > Thanks, > -Chris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:23:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:23:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRReI-0004cH-De; Mon, 07 May 2012 17:23:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRReG-0004c6-8J for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:23:00 +0000 Received: from [85.158.143.99:48882] by server-1.bemta-4.messagelabs.com id B2/F9-20925-3F408AF4; Mon, 07 May 2012 17:22:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336411376!21614665!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12397 invoked from network); 7 May 2012 17:22:58 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:22:58 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47HMsIl018775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:22:55 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 q47HMr3W010549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:22:54 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 q47HMrUx018902; Mon, 7 May 2012 12:22:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:22:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 76FC34031D; Mon, 7 May 2012 13:17:03 -0400 (EDT) Date: Mon, 7 May 2012 13:17:03 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120507171703.GA5746@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE This looks suspicious like a fix that went in some time ago, ah: 2cd1c8d x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode but that went in 3.2 so that can't be it. Hm, can you give more details on what parameters you are passing to dom0 and the hypervisor so I can reproduce it? Also, could you send me your .config file? Is the underlaying storage SCSI? And is this only happening on these SuperMicro boxes or are you seeing this on other hardware as well? > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done > > BUG: unable to handle kernel paging request at bffff628 > IP: [] __page_check_address+0xb8/0x170 > *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 > EIP: 0061:[] EFLAGS: 00010246 CPU: 6 > EIP is at __page_check_address+0xb8/0x170 > EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 > ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 > Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) > Stack: > e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 > 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 > b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 > Call Trace: > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 > e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c > 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 > EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c > CR2: 00000000bffff628 > ---[ end trace 8039aeca9c19f5ab ]--- > note: lvremove[27902] exited with preempt_count 1 > BUG: scheduling while atomic: lvremove/27902/0x00000001 > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 > Call Trace: > [] __schedule_bug+0x5d/0x70 > [] __schedule+0x679/0x830 > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? rcu_enter_nohz+0x3c/0x60 > [] ? xen_evtchn_do_upcall+0x20/0x30 > [] ? hypercall_page+0x227/0x1000 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] schedule+0x30/0x50 > [] rwsem_down_failed_common+0x9d/0xf0 > [] rwsem_down_read_failed+0x12/0x14 > [] call_rwsem_down_read_failed+0x7/0xc > [] ? down_read+0xd/0x10 > [] acct_collect+0x3a/0x170 > [] do_exit+0x62a/0x7d0 > [] ? kmsg_dump+0x37/0xc0 > [] oops_end+0x90/0xd0 > [] no_context+0xbe/0x190 > [] __bad_area_nosemaphore+0x98/0x140 > [] ? xen_clocksource_read+0x19/0x20 > [] ? xen_vcpuop_set_next_event+0x47/0x80 > [] bad_area_nosemaphore+0x12/0x20 > [] do_page_fault+0x2d2/0x3f0 > [] ? hrtimer_interrupt+0x1a9/0x2b0 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] ? check_events+0x8/0xc > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? _raw_spin_unlock_irqrestore+0x14/0x20 > [] ? spurious_fault+0x130/0x130 > [] error_code+0x5a/0x60 > [] ? spurious_fault+0x130/0x130 > [] ? __page_check_address+0xb8/0x170 > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > > Thanks, > -Chris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:38:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRRsY-0004u6-KY; Mon, 07 May 2012 17:37:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRsW-0004tu-Cy for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:37:45 +0000 Received: from [85.158.138.51:9287] by server-7.bemta-3.messagelabs.com id 73/E3-03078-76808AF4; Mon, 07 May 2012 17:37:43 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336412259!25760654!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4796 invoked from network); 7 May 2012 17:37:41 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:37:41 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47Hbacf004479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:37: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 q47HbY61016744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:37:35 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 q47HbYw2027426; Mon, 7 May 2012 12:37:34 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:37:32 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 724C74031D; Mon, 7 May 2012 13:31:44 -0400 (EDT) Date: Mon, 7 May 2012 13:31:44 -0400 From: Konrad Rzeszutek Wilk To: Pavel =?utf-8?Q?Mat=C4=9Bja?= Message-ID: <20120507173144.GB17704@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201205071345.23619.pavel@netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gTW9uLCBNYXkgMDcsIDIwMTIgYXQgMDE6NDU6MjNQTSArMDIwMCwgUGF2ZWwgTWF0xJtqYSB3 cm90ZToKPiBIaSwKPiBJJ20gdHJ5aW5nIHRvIHJ1biBBTUQgVkdBIHBhc3N0aHJ1IG9uIGxhdGVz dCBYRU4gdW5zdGFibGUgd2l0aCBsYXRlc3Qga2VybmVsLgo+IEkgYWxyZWFkeSBoYXZlIHdvcmtp bmcgc2V0dXAgd2l0aCBhbmNpZW50IHhlbi1kZXZlbCA0LjIgYW5kIDIuNi4zMi54IHhlbmlmaWVk IAo+IGtlcm5lbC4gU2VlIGF0dGFjaGVkIGxvZy4KPiAKPiBTbyBJIHRyaWVkIGp1c3QgdG8gdXBk YXRlIGFuZCBwYXRjaCB4ZW4gYW5kIGtlcm5lbCwgYnV0IEkgaGFkIG5vIGx1Y2sgc28gZmFyLgo+ IAo+IFhlbiBoYXMgYXRpX3ZiaW9zX3BhdGNoX3Jlc3Bpbi50eHQgc2VudCB0byB4ZW4tZGV2ZWwg YnkgV2VpIEh1YW5nIHJlY2VudGx5Lgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0 bWwveGVuLWRldmVsLzIwMTItMDQvbXNnMDAyOTEuaHRtbAo+IAo+IEkgdHJpZWQgdHdvIGtlcm5l bHMgCj4gdGVzdGluZy0zLjUtd2l0aC1leHRyYSBhbmQgeGVuL25leHQtMy4yIGZyb20KPiBnaXQ6 Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQva29ucmFkL3hlbi5naXQK PiBhbmQKPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvamVy ZW15L3hlbi5naXQKPiBCb3RoIHdpdGggaW9wZXJtIG9wY29kZSBwYXRjaCB3aGljaCBpcyByZXF1 aXJlZCBieSB0aGUgQVRJIHBhdGNoLiBTZWUgCj4gYXR0YWNoZW1lbnQuCj4gCj4gVGhlIHhlbi9u ZXh0LTMuMiBicmFuY2gga2VybmVsIHdhcyBhYmxlIHRvIHN0YXJ0IGJvb3Rpbmcgd2luZG93cy4K PiBXaXRoIENhdGFseXN0IGRyaXZlciBpbnN0YWxsZWQgSSBqdXN0IHNhdyBibHVlc2NyZWVuIGR1 cmluZyBXaW5kb3dzIGJvb3QuCj4gV2l0aG91dCBDYXRhbHlzdCBkcml2ZXIgV2luZG93cyB3ZXJl IGFibGUgdG8gYm9vdCBidXQgV2luZG93cyBlbmRlZCBmcm96ZW4gb3IgCj4gVVNCIHdhcyBub3Qg d29ya2luZy4gSXQgd2FzIGhhcmQgdG8gdGVsbCBiZWNhdXNlIGlucHV0IGRldmljZXMgaGFkIG5v IHJlc3BvbnNlIAo+IGF0IGFsbC4KPiAKPiBUaGUgdGVzdGluZy0zLjUtd2l0aC1leHRyYSAocmVw b3J0ZWQgYXMgMy40LjAtcmM0KSBqdXN0IGNyYXNoZWQgZG9tMCBrZXJuZWwgCj4gZHVyaW5nIFdp bmRvd3MgYm9vdC4gSSBndWVzcyBJIGhhdmUgdG8gcmV3b3JrIHRoZSBpb19iaXRtYXAgcGF0Y2gg c29tZWhvdy4KCldoZW4geW91IHNheSAnaW9fYml0bWFwJyBwYXRjaCBhcmUgeW91IHJlZmVycmlu ZyB0byB0aGVzZSBvbmVzOgoKNzBhMzU3ZCB4ZW46IGltcGxlbWVudCBJTyBwZXJtaXNzaW9uIGJp dG1hcAowYzU5NmM1IHg4Ni9wYXJhdmlydDogcGFyYXZpcnR1YWxpemUgSU8gcGVybWlzc2lvbiBi aXRtYXAKOTNiN2EyYSB4ODY6IGRlbWFjcm8gc2V0X2lvcGxfbWFzaygpCgo/IEkgZG9uJ3QgdGhp bmsgdGhvc2UgYXJlIGluIHRoYXQgdGFnLiBUaGV5IGFyZSBpbiB0aGUga2l0Y2hlbnNpbmsgLSAj dGVzdGluZwotIGRvZXMgaXQgd29yayB3aXRoIHRoYXQgYnJhbmNoPwoKVGhlIG5leHQtMy4yIGlz IGEgYml0IG9sZC4gSSBzaG91bGQgYWN0dWFsbHkgZGVsZXRlIGl0LgoKPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEBuZXRzYWZlLmN6KSAo Z2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApIFN1biBGZWIgIDUgMTU6NTU6MzMg Q0VUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBUaHUgTWF5IDA1IDE3OjQwOjM0IDIw MTEgKzAxMDAgMjMzMDA6NGIwNjkyODgwZGZhCj4gKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3lu Y2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVl emUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBkb20wX21h eF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUgY29tMT0x MTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoK PiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikgIFZCRS9E REMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhFTikgRGlz YyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChYRU4pICBG b3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAgUkFNIG1h cDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVzYWJsZSkK PiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQo+ IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4g KFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUpCj4gKFhF TikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gKFhF TikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAoWEVO KSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+IChYRU4p ICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikg IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhFTikgQUNQ STogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhTRFQgQ0ZF ODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+ IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0MCAyMDEx MTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2RTMgKHIx ICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFDUEk6IEZB Q1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4IChyMSAx MDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBNQ0ZH IENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAgICAgICA5 NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VNQjE3NDAg MjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMwLCAwMDM4 IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAg ICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0gSSAgUE9X RVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIg KDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAoWEVOKSBG YWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+IChYRU4p IERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAw MGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVm YXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikgQUNQSTog QUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+IChYRU4p IEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19zaXplWzIw XQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhFTikgQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAoWEVOKSBQ cm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMSAw OjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh cGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJz aW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10g ZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVO KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQo+IChY RU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw N10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsw eDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJQ1swXTog YXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCj4gKFhF TikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0 XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZl YzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly cSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMg MCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJUlEwIHVz ZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgo+IChY RU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBBUElDIG1v ZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgz MDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJh c2UgZTAwMDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKPiAoWEVOKSBQQ0k6IE5vdCB1c2lu ZyBNTUNPTkZJRy4KPiAoWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCj4gKFhFTikgVXNpbmcgQUNQ SSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uCj4gKFhFTikgSVJRIGxp bWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjI1NCBNSHog cHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZh bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgQU1ELVZpOiBJT01N VSAwIEVuYWJsZWQuCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAoWEVOKSAg LSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKPiAoWEVO KSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBh cGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGltZXIgaXMg MTQuMzE4TUh6IEhQRVQKPiDDvyhYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgNjQgS2lC Lgo+IChYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KPiAoWEVOKSBTVk06IFN1cHBvcnRlZCBhZHZh bmNlZCBmZWF0dXJlczoKPiAoWEVOKSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkKPiAoWEVO KSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KPiAoWEVOKSAgLSBO ZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUCj4gKFhFTikgIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRl cgo+IChYRU4pIEhWTTogU1ZNIGVuYWJsZWQKPiAoWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVk IFBhZ2luZyBkZXRlY3RlZC4KPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIEhQRVQn cyBNU0kgbW9kZSBoYXNuJ3QgYmVlbiBzdXBwb3J0ZWQgd2hlbiBJbnRlcnJ1cHQgUmVtYXBwaW5n IGlzIGVuYWJsZWQuCj4gKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKPiAoWEVOKSBNQ0E6IFVz ZSBodyB0aHJlc2hvbGRpbmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5Cj4gKFhFTikgbWNo ZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgo+IChYRU4pIFhl bm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NUTCA9IDB4ZmZm ZmZmZmYKPiAoWEVOKSAqKiogTE9BRElORyBET01BSU4gMCAqKioKPiAoWEVOKSBlbGZfcGFyc2Vf YmluYXJ5OiBwaGRyOiBwYWRkcj0weDEwMDAwMDAgbWVtc3o9MHg3N2MwMDAKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE3N2MwMDAgbWVtc3o9MHg4ZGE4OAo+IChYRU4p IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgwYTAwMCBtZW1zej0weDhjOAo+IChY RU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgwYjAwMCBtZW1zej0weDE0YTU4 Cj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxODIwMDAwIG1lbXN6PTB4 MjEyMDAwCj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgx YTMyMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCIKPiAo WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIKPiAoWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pIGVsZl94 ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODE4MjAyMDAKPiAoWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDA5MDAwCj4gKFhFTikg ZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFl X3BnZGlyX2Fib3ZlXzRnYiIKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0g InllcyIKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgo+IChY RU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkKPiAoWEVO KSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCj4gKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAo+IChYRU4pIGVsZl94ZW5fYWRk cl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6Cj4gKFhFTikgICAgIHZpcnRfYmFzZSAgICAgICAgPSAw eGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MAo+IChY RU4pICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgICAg IHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9r ZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWEzMjAwMAo+IChYRU4pICAgICB2aXJ0X2VudHJ5ICAg ICAgID0gMHhmZmZmZmZmZjgxODIwMjAwCj4gKFhFTikgICAgIHAybV9iYXNlICAgICAgICAgPSAw eGZmZmZmZmZmZmZmZmZmZmYKPiAoWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w YXQzMgo+IChYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAw MDAwIC0+IDB4MWEzMjAwMAo+IChYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKPiAo WEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDIyNDAwMDAwMC0+MDAwMDAwMDIyODAwMDAwMCAo NTA2MjYzIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKPiAoWEVOKSAgSW5pdC4gcmFtZGlzazogMDAw MDAwMDIyZjk5NzAwMC0+MDAwMDAwMDIyZmZmZjYwMAo+IChYRU4pIFZJUlRVQUwgTUVNT1JZIEFS UkFOR0VNRU5UOgo+IChYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZm ZmZmZjgxYTMyMDAwCj4gKFhFTikgIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODFhMzIwMDAtPmZm ZmZmZmZmODIwOWE2MDAKPiAoWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MjA5YjAwMC0+ ZmZmZmZmZmY4MjQ5YjAwMAo+IChYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgyNDliMDAw LT5mZmZmZmZmZjgyNDliNGI0Cj4gKFhFTikgIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODI0OWMw MDAtPmZmZmZmZmZmODI0YjMwMDAKPiAoWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjRi MzAwMC0+ZmZmZmZmZmY4MjRiNDAwMAo+IChYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgw MDAwMDAwLT5mZmZmZmZmZjgyODAwMDAwCj4gKFhFTikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZm ODE4MjAyMDAKPiAoWEVOKSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKPiAoWEVOKSBlbGZfbG9h ZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxNzdj MDAwCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgxNzdjMDAw IC0+IDB4ZmZmZmZmZmY4MTgwOWE4OAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0 IDB4ZmZmZmZmZmY4MTgwYTAwMCAtPiAweGZmZmZmZmZmODE4MGE4YzgKPiAoWEVOKSBlbGZfbG9h ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODE4MGIwMDAgLT4gMHhmZmZmZmZmZjgxODFm YTU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDQgYXQgMHhmZmZmZmZmZjgxODIwMDAw IC0+IDB4ZmZmZmZmZmY4MThiMzAwMAo+IChYRU4pIFNjcnViYmluZyBGcmVlIFJBTTogLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRv bmUuCj4gKFhFTikgU3RkLiBMb2dsZXZlbDogQWxsCj4gKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFs bAo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK PiAoWEVOKSAqKioqKioqIFdBUk5JTkc6IENPTlNPTEUgT1VUUFVUIElTIFNZTkNIUk9OT1VTCj4g KFhFTikgKioqKioqKiBUaGlzIG9wdGlvbiBpcyBpbnRlbmRlZCB0byBhaWQgZGVidWdnaW5nIG9m IFhlbiBieSBlbnN1cmluZwo+IChYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNo cm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KPiAoWEVOKSAqKioqKioqIEhv d2V2ZXIgaXQgY2FuIGludHJvZHVjZSBTSUdOSUZJQ0FOVCBsYXRlbmNpZXMgYW5kIGFmZmVjdAo+ IChYRU4pICoqKioqKiogdGltZWtlZXBpbmcuIEl0IGlzIE5PVCByZWNvbW1lbmRlZCBmb3IgcHJv ZHVjdGlvbiB1c2UhCj4gKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgo+IChYRU4pIDMuLi4gMi4uLiAxLi4uIAo+IChYRU4pICoqKiBTZXJpYWwgaW5w dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8g WGVuKQo+IChYRU4pIEZyZWVkIDIzNmtCIGluaXQgbWVtb3J5Lgo+IG1hcHBpbmcga2VybmVsIGlu dG8gcGh5c2ljYWwgbWVtb3J5Cj4gWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwo+IGFib3V0 IHRvIGdldCBzdGFydGVkLi4uCj4gRVJST1I6IFVuYWJsZSB0byBsb2NhdGUgSU9BUElDIGZvciBH U0kgMgo+IEVSUk9SOiBVbmFibGUgdG8gbG9jYXRlIElPQVBJQyBmb3IgR1NJIDkKPiAoWEVOKSB0 cmFwcy5jOjI0MDU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy b20gMHgwMDAwMjRhNzRkYjA2NDA0IHRvIDB4MDAwMDAwMDAwMDAwMDAwMC4KPiAoWEVOKSB0cmFw cy5jOjI0MDU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDAwIGZyb20g MHgwMDAwMDMwNjFhMGVmZmM5IHRvIDB4MDAwMDAwMDAwMDQzMDA3Ni4KPiBFUlJPUjogVW5hYmxl IHRvIGxvY2F0ZSBJT0FQSUMgZm9yIEdTSSA5Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDAu MAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjAwLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAw MDowMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDQuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwOjA1LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowNi4wCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDA6MDcuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjBkLjAKPiAoWEVOKSBQ Q0kgYWRkIGRldmljZSAwMDoxMS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTIuMAo+IChY RU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxMy4w Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTMuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAw OjE0LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDA6MTQuMwo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjQKPiAoWEVOKSBQQ0kgYWRk IGRldmljZSAwMDoxNC41Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTYuMAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwOjE2LjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDA6MTguMQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjIK PiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6 MTguNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDA3OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmlj ZSAwNzowMC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDY6MDAuMAo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDA2OjAwLjEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwNTowMC4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDQ6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAzOjAwLjAKPiAoWEVO KSBQQ0kgYWRkIGRldmljZSAwMjowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDI6MDAuMQo+ IHJlZ2lzdGVyaW5nIG5ldGJhY2sKPiBJVDg3IFdEVDogVW5rbm93biBDaGlwIGZvdW5kLCBDaGlw IDg3MjEgUmV2aXNpb24gMDAwMQo+IFtGaXJtd2FyZSBCdWddOiBwb3dlcm5vdy1rODogTm8gY29t cGF0aWJsZSBBQ1BJIF9QU1Mgb2JqZWN0cyBmb3VuZC4KPiBbRmlybXdhcmUgQnVnXTogcG93ZXJu b3ctazg6IFRyeSBhZ2FpbiB3aXRoIGxhdGVzdCBCSU9TLgo+IExvYWRpbmcsIHBsZWFzZSB3YWl0 Li4uCj4gSU5JVDogdmVyc2lvbiAyLjg4IGJvb3RpbmcKPiBVc2luZyBtYWtlZmlsZS1zdHlsZSBj b25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy4KPiBTdGFydGluZyB0aGUgaG90cGx1ZyBldmVu dHMgZGlzcGF0Y2hlcjogdWRldmQuCj4gU3ludGhlc2l6aW5nIHRoZSBpbml0aWFsIGhvdHBsdWcg ZXZlbnRzLi4uZG9uZS4KPiBXYWl0aW5nIGZvciAvZGV2IHRvIGJlIGZ1bGx5IHBvcHVsYXRlZC4u LnVkZXZkLXdvcmtbMTQzN106IGtlcm5lbC1wcm92aWRlZCBuYW1lICdibGt0YXAtY29udHJvbCcg YW5kIE5BTUU9ICd4ZW4vYmxrdGFwLTIvY29udHJvbCcgZGlzYWdyZWUsIHBsZWFzZSB1c2UgU1lN TElOSys9IG9yIGNoYW5nZSB0aGUga2VybmVsIHRvIHByb3ZpZGUgdGhlIHByb3BlciBuYW1lCj4g Cj4gZG9uZS4KPiBTZXR0aW5nIHByZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGlu ZyBzd2FwLi4uZG9uZS4KPiBDaGVja2luZyByb290IGZpbGUgc3lzdGVtLi4uZnNjayBmcm9tIHV0 aWwtbGludXgtbmcgMi4xNy4yCj4gSE9XVE9fUk9PVDogY2xlYW4sIDk1MDU0LzE0MTk4NDAgZmls ZXMsIDczMTE4MC81Njc5MTA0IGJsb2NrcyAoY2hlY2sgaW4gNCBtb3VudHMpCj4gZG9uZS4KPiBM b2FkaW5nIGtlcm5lbCBtb2R1bGVzLi4uZG9uZS4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4uLi4K PiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdyb3Vw cyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGlsZS4u Lgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBs dm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2giIG5v dyBhY3RpdmUKPiAuCj4gQWN0aXZhdGluZyBsdm0gYW5kIG1kIHN3YXAuLi5kb25lLgo+IENoZWNr aW5nIGZpbGUgc3lzdGVtcy4uLmZzY2sgZnJvbSB1dGlsLWxpbnV4LW5nIDIuMTcuMgo+IGRvbmUu Cj4gTW91bnRpbmcgbG9jYWwgZmlsZXN5c3RlbXMuLi5kb25lLgo+IEFjdGl2YXRpbmcgc3dhcGZp bGUgc3dhcC4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uLgo+IFNldHRp bmcga2VybmVsIHZhcmlhYmxlcyAuLi5kb25lLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJm YWNlcy4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uLgo+IFNldHRpbmcg Y29uc29sZSBzY3JlZW4gbW9kZXMuCj4gUmNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4g U2tpcHBpbmcgZm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXAp Lgo+IFNldHRpbmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IElOSVQ6IEVu dGVyaW5nIHJ1bmxldmVsOiAyCj4gVXNpbmcgbWFrZWZpbGUtc3R5bGUgY29uY3VycmVudCBib290 IGluIHJ1bmxldmVsIDIuCj4gYWNwaWQ6IHN0YXJ0aW5nIHVwIHdpdGggcHJvYyBmcwo+IAo+IGFj cGlkOiAxIHJ1bGUgbG9hZGVkCj4gCj4gYWNwaWQ6IHdhaXRpbmcgZm9yIGV2ZW50czogZXZlbnQg bG9nZ2luZyBpcyBvZmYKPiAKPiBTdGFydGluZyBBQ1BJIHNlcnZpY2VzLi4uLgo+IFN0YXJ0aW5n IHN5c3RlbSBtZXNzYWdlIGJ1czogZGJ1cy4KPiBTdGFydGluZyBwZXJpb2RpYyBjb21tYW5kIHNj aGVkdWxlcjogY3Jvbi4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3VyZSBTaGVsbCBzZXJ2ZXI6IHNz aGQuCj4gU3RhcnRpbmcgeGVuc3RvcmVkLi4uWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3Rh dGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRv IHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5C VVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1 IHN0YXRlCj4gCj4gU2V0dGluZyBkb21haW4gMCBuYW1lLi4uCj4gU3RhcnRpbmcgeGVuY29uc29s ZWQuLi4KPiBCTEtUQVBDVFJMWzIxNjhdOiBibGt0YXBjdHJsLmM6NzkwOiBibGt0YXBjdHJsOiB2 MS4wLjAKPiAKPiBCTEtUQVBDVFJMWzIxNjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2 ZXI6IFtyYXcgaW1hZ2UgKGFpbyldCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5j Ojc5MjogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChzeW5jKV0KPiAKPiBCTEtUQVBDVFJMWzIx NjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFt2bXdhcmUgaW1hZ2UgKHZtZGsp XQo+IAo+IEJMS1RBUENUUkxbMjE2OF06IGJsa3RhcGN0cmwuYzo3OTI6IEZvdW5kIGRyaXZlcjog W3JhbWRpc2sgaW1hZ2UgKHJhbSldCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5j Ojc5MjogRm91bmQgZHJpdmVyOiBbcWNvdyBkaXNrIChxY293KV0KPiAKPiBCTEtUQVBDVFJMWzIx NjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFtxY293MiBkaXNrIChxY293Mild Cj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybF9saW51eC5jOjg2OiBibGt0YXAwIG9w ZW4gZmFpbGVkCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5jOjg1OTogY291bGRu J3Qgb3BlbiBibGt0YXAgaW50ZXJmYWNlCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3Ry bC5jOjkyMjogVW5hYmxlIHRvIHN0YXJ0IGJsa3RhcGN0cmwKPiAKPiAoWEVOKSBQQ0kgcmVtb3Zl IGRldmljZSAwMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTIuMgo+IC91c3IvbG9j YWwvYmluL3hlbl9zdGFydC5zaDogbGluZSAxNTogL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDow NzowMC4wL2RyaXZlci91bmJpbmQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKPiBVc2luZyBj b25maWcgZmlsZSAiL2V0Yy94ZW4vd2luZG93cyIuCj4gKFhFTikgZG9tY3RsLmM6MTA0MjpkMCBp b3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNiMCBmX21wb3J0PTNiMCBucD1jCj4gKFhFTikgZG9tY3Rs LmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49YTAgbWZuPWEwIG5yX21mbnM9MjAKPiAoWEVO KSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2MwIGZfbXBvcnQ9M2Mw IG5wPTMKPiAoWEVOKSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2M0 IGZfbXBvcnQ9M2M0IG5wPTFjCj4gKFhFTikgSFZNMTogSFZNIExvYWRlcgo+IChYRU4pIEhWTTE6 IERldGVjdGVkIFhlbiB2NC4yLXVuc3RhYmxlCj4gKFhFTikgSFZNMTogWGVuYnVzIHJpbmdzIEAw eGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDcKPiBTdGFydGVkIGRvbWFpbiB3aW5kb3dzIChpZD0x KShYRU4pIEhWTTE6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IAo+IChYRU4pIEhWTTE6IENQ VSBzcGVlZCBpcyAzMDEwIE1Iego+IChYRU4pIGlycS5jOjI1ODogRG9tMSBQQ0kgbGluayAwIGNo YW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUK PiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVO KSBIVk0xOiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNTg6 IERvbTEgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxp bmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMyBj aGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1 Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNp IGRldiAwMzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJR NQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBj aSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzowIElOVEEtPklS UTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0xOiBw Y2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDEw IHNpemUgMTAwMDAwMDA6IGUwMDAwMDBjCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9t YXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBIVk0xOiBw Y2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhFTikgSFZNMTog cGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMTAwMDAwMAo+IChYRU4pIGRvbWN0 bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAw NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAw MDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYw MDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjAgbWZu PWZlOWJjIG5yX21mbnM9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAw MDAwNDAwMDogZjEwNjQwMDQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6 IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzow IGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2ODAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBt ZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBIVk0x OiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgZG9t Y3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9 MQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMw MDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6IDAwMDBj MTAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAw YzIwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAw MGMyNDEKPiAoWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKPiAoWEVO KSBIVk0xOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0xOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAu Li4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0x OiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb My84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5cyAuLi4g Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiBU ZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBhY3Jvc3Mg cGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiAgLSBHUyBiYXNlIE1TUnMg YW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogUGFzc2VkIDIgb2YgMiB0ZXN0cwo+ IChYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBkb21jdGwuYzox MDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2IwIGZfbXBvcnQ9M2IwIG5wPWMKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1hMCBtZm49YTAgbnJfbWZucz0y MAo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzAgZl9t cG9ydD0zYzAgbnA9Mwo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9n cG9ydD0zYzQgZl9tcG9ydD0zYzQgbnA9MWMKPiAoWEVOKSBIVk0yOiBIVk0gTG9hZGVyCj4gKFhF TikgSFZNMjogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKPiAoWEVOKSBIVk0yOiBYZW5idXMg cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNwo+IChYRU4pIEhWTTI6IFN5c3RlbSBy ZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4pIEhWTTI6IENQVSBzcGVlZCBpcyAzMDEwIE1Iego+IChY RU4pIGlycS5jOjI1ODogRG9tMiBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZN MjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTIg UENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVOKSBIVk0yOiBQQ0ktSVNBIGxpbmsgMSBy b3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTIgUENJIGxpbmsgMiBjaGFuZ2Vk IDAgLT4gMTEKPiAoWEVOKSBIVk0yOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAo WEVOKSBpcnEuYzoyNTg6IERvbTIgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhW TTI6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikgSFZNMjogcGNpIGRldiAw MTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMjogcGNpIGRldiAwMzowIElOVEEtPklSUTUKPiAo WEVOKSBIVk0yOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTI6IHBjaSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4g KFhFTikgSFZNMjogcGNpIGRldiAwNzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAK PiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMTAwMDAwMDA6IGUwMDAwMDBj Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQw MDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUg MDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhFTikgSFZNMjogcGNpIGRldiAwNDowIGJhciAxMCBzaXpl IDAwMDIwMDAwOiBmMTAwMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFk ZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikgSFZNMjogcGNpIGRldiAw NTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAwNAo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAwMDAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYwMDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2 OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4p IEhWTTI6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAwMDAwNDAwMDogZjEwNjQwMDQKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJf bWZucz00Cj4gKFhFTikgSFZNMjogcGNpIGRldiAwNzowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBm MTA2ODAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4 IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNp emUgMDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6 YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMwMDEKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6IDAwMDBjMTAxCj4gKFhFTikgSFZNMjogcGNpIGRl diAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzIwMQo+IChYRU4pIEhWTTI6IHBjaSBk ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMyNDEKPiAoWEVOKSBIVk0yOiBNdWx0 aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKPiAoWEVOKSBIVk0yOiAgLSBDUFUwIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0yOiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiAgLSBDUFUyIC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0yOiAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0yOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoK PiAoWEVOKSBIVk0yOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNz ZWQKPiAoWEVOKSBIVk0yOiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4g KFhFTikgSFZNMjogUGFzc2VkIDIgb2YgMiB0ZXN0cwo+IChYRU4pIEhWTTI6IFdyaXRpbmcgU01C SU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZf Z3BvcnQ9M2IwIGZfbXBvcnQ9M2IwIG5wPWMKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5 X21hcDphZGQ6IGdmbj1hMCBtZm49YTAgbnJfbWZucz0yMAo+IChYRU4pIGRvbWN0bC5jOjEwNDI6 ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzAgZl9tcG9ydD0zYzAgbnA9Mwo+IChYRU4pIGRv bWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzQgZl9tcG9ydD0zYzQgbnA9 MWMKPiAoWEVOKSBIVk0zOiBIVk0gTG9hZGVyCj4gKFhFTikgSFZNMzogRGV0ZWN0ZWQgWGVuIHY0 LjItdW5zdGFibGUKPiAoWEVOKSBIVk0zOiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50 IGNoYW5uZWwgNwo+IChYRU4pIEhWTTM6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4p IEhWTTM6IENQVSBzcGVlZCBpcyAzMDEwIE1Iego+IChYRU4pIGlycS5jOjI1ODogRG9tMyBQQ0kg bGluayAwIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZNMzogUENJLUlTQSBsaW5rIDAgcm91dGVk IHRvIElSUTUKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTMgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4g MTAKPiAoWEVOKSBIVk0zOiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBp cnEuYzoyNTg6IERvbTMgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0zOiBQ Q0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTMgUENJ IGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhWTTM6IFBDSS1JU0EgbGluayAzIHJvdXRl ZCB0byBJUlE1Cj4gKFhFTikgSFZNMzogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikg SFZNMzogcGNpIGRldiAwMzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA0OjAg SU5UQS0+SVJRNQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4p IEhWTTM6IHBjaSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4gKFhFTikgSFZNMzogcGNpIGRldiAwNzow IElOVEEtPklSUTUKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVO KSBIVk0zOiBwY2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA1 OjAgYmFyIDEwIHNpemUgMTAwMDAwMDA6IGUwMDAwMDBjCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQw IG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVO KSBIVk0zOiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhF TikgSFZNMzogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMTAwMDAwMAo+IChY RU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBu cl9tZm5zPTIwCj4gKFhFTikgSFZNMzogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAw OiBmMTAyMDAwNAo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAw MDogZjEwNDAwMDAKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQw MDA6IGYxMDYwMDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49 ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDk6MCBiYXIg MTAgc2l6ZSAwMDAwNDAwMDogZjEwNjQwMDQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5 X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgSFZNMzogcGNp IGRldiAwNzowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2ODAwMAo+IChYRU4pIGRvbWN0bC5j Ojk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAo WEVOKSBIVk0zOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4g KFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAw IG5yX21mbnM9MQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEw MDogMDAwMGMwMDEKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAx MDA6IDAwMDBjMTAxCj4gKFhFTikgSFZNMzogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAw MDQwOiAwMDAwYzIwMQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAw MDAxMDogMDAwMGMyNDEKPiAoWEVOKSBIVk0zOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv bjoKPiAoWEVOKSBIVk0zOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg Li4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFUxIC4uLiA0 OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4K PiAoWEVOKSBIVk0zOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u IHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFUzIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0zOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFU1IC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0zOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0zOiAgLSBSRVAgSU5T QiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0zOiAgLSBHUyBi YXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMzogUGFzc2VkIDIgb2Yg MiB0ZXN0cwo+IChYRU4pIEhWTTM6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAgX18gIF9f ICAgICAgICAgICAgXyAgXyAgICBfX19fICAgICAgICAgICAgICAgICAgICAgXyAgICAgICAgXyAg ICAgXyAgICAgIAo+ICBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyBcICAgIF8gICBfIF8g X18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gCj4gICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8 XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKPiAgIC8g IFwgIF9fLyB8IHwgfCB8X18gICBffCAvIF9fL3xfX3wgfF98IHwgfCB8IFxfXyBcIHx8IChffCB8 IHxfKSB8IHwgIF9fLwo+ICAvXy9cX1xfX198X3wgfF98ICAgIHxffChfKV9fX19ffCAgIFxfXyxf fF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198Cj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPiAo WEVOKSBYZW4gdmVyc2lvbiA0LjItdW5zdGFibGUgKHJvb3RAbmV0c2FmZS5jeikgKGdjYyB2ZXJz aW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSBTdW4gRmViICA1IDE1OjU1OjMzIENFVCAyMDEy Cj4gKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IE1heSAwNSAxNzo0MDozNCAyMDExICswMTAw IDIzMzAwOjRiMDY5Mjg4MGRmYQo+IChYRU4pIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9ub3Vz Lgo+IChYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQo+IChY RU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgZG9tMF9tZW09MkcgZG9tMF9tYXhfdmNwdXM9 NiBsb2dsdmw9YWxsIGd1ZXN0X2xvZ2x2bD1hbGwgc3luY19jb25zb2xlIGNvbTE9MTE1MjAwLDhu MSwweGFjMDAgY29uc29sZT1jb20xCj4gKFhFTikgVmlkZW8gaW5mb3JtYXRpb246Cj4gKFhFTikg IFZHQSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgo+IChYRU4pICBWQkUvRERDIG1ldGhv ZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwo+IChYRU4pIERpc2MgaW5mb3Jt YXRpb246Cj4gKFhFTikgIEZvdW5kIDEgTUJSIHNpZ25hdHVyZXMKPiAoWEVOKSAgRm91bmQgMSBF REQgaW5mb3JtYXRpb24gc3RydWN0dXJlcwo+IChYRU4pIFhlbi1lODIwIFJBTSBtYXA6Cj4gKFhF TikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlhYzAwICh1c2FibGUpCj4gKFhFTikg IDAwMDAwMDAwMDAwOWFjMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAg MDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAw MDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBjZmU4MDAwMCAodXNhYmxlKQo+IChYRU4pICAwMDAw MDAwMGNmZTgwMDAwIC0gMDAwMDAwMDBjZmU5ODAwMCAoQUNQSSBkYXRhKQo+IChYRU4pICAwMDAw MDAwMGNmZTk4MDAwIC0gMDAwMDAwMDBjZmVjMDAwMCAoQUNQSSBOVlMpCj4gKFhFTikgIDAwMDAw MDAwY2ZlYzAwMDAgLSAwMDAwMDAwMGNmZjAwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAwMDAw MDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAw MTAwMDAwMDAwIC0gMDAwMDAwMDIzMDAwMDAwMCAodXNhYmxlKQo+IChYRU4pIEFDUEk6IFJTRFAg MDAwRkJGMjAsIDAwMjQgKHIyIEFDUElBTSkKPiAoWEVOKSBBQ1BJOiBYU0RUIENGRTgwMTAwLCAw MDVDIChyMSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBGQUNQIENGRTgwMjkwLCAwMEY0IChyMyAxMDI4MTEgRkFDUDE3NDAgMjAxMTEwMjggTVNG VCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBEU0RUIENGRTgwNDcwLCBFNkUzIChyMSAgQTE1OTUg QTE1OTUwMDAgICAgICAgIDAgSU5UTCAyMDA2MDExMykKPiAoWEVOKSBBQ1BJOiBGQUNTIENGRTk4 MDAwLCAwMDQwCj4gKFhFTikgQUNQSTogQVBJQyBDRkU4MDM5MCwgMDA5OCAocjEgMTAyODExIEFQ SUMxNzQwIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogTUNGRyBDRkU4MDQz MCwgMDAzQyAocjEgMTAyODExIE9FTU1DRkcgIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhF TikgQUNQSTogT0VNQiBDRkU5ODA0MCwgMDA3MiAocjEgMTAyODExIE9FTUIxNzQwIDIwMTExMDI4 IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogSFBFVCBDRkU4RjhDMCwgMDAzOCAocjEgMTAy ODExIE9FTUhQRVQgIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogSVZSUyBD RkU4RjkwMCwgMDBFMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAgICAgIDAp Cj4gKFhFTikgQUNQSTogU1NEVCBDRkU4RjlFMCwgMEUxMCAocjEgQSBNIEkgIFBPV0VSTk9XICAg ICAgICAxIEFNRCAgICAgICAgIDEpCj4gKFhFTikgU3lzdGVtIFJBTTogODE5ME1CICg4Mzg2NjY0 a0IpCj4gKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kCj4gKFhFTikgRmFraW5nIGEg bm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAyMzAwMDAwMDAKPiAoWEVOKSBEb21haW4g aGVhcCBpbml0aWFsaXNlZAo+IChYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MAo+ IChYRU4pIERNSSBwcmVzZW50Lgo+IChYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKPiAo WEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOAo+IChYRU4pIEFDUEk6IEFDUEkgU0xF RVAgSU5GTzogcG0xeF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0KPiAoWEVOKSBBQ1BJOiAg ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbY2ZlOTgwMGNdLCB2ZWNfc2l6ZVsyMF0KPiAoWEVO KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw Ml0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElD IHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw eDAyXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+ IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQp Cj4gKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9j ZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjNSAwOjEw IEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGlj X2lkWzB4ODZdIGRpc2FibGVkKQo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxh cGljX2lkWzB4ODddIGRpc2FibGVkKQo+IChYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRk cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKPiAoWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQg NiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMwo+IChYRU4pIEFDUEk6 IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCj4gKFhF TikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMyMDAwMCwg R1NJIDI0LTU1Cj4gKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9i YWxfaXJxIDIgZGZsIGRmbCkKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly cSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpCj4gKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92 ZXJyaWRlLgo+IChYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBBQ1BJ OiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxh dC4gIFVzaW5nIDIgSS9PIEFQSUNzCj4gKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6 IDB4ZmVkMDAwMDAKPiAoWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAw MDAwIHNlZ21lbnQgMCBidXNlcyAwIC0gMjU1Cj4gKFhFTikgUENJOiBOb3QgdXNpbmcgTU1DT05G SUcuCj4gKFhFTikgVGFibGUgaXMgbm90IGZvdW5kIQo+IChYRU4pIFVzaW5nIEFDUEkgKE1BRFQp IGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgo+IChYRU4pIElSUSBsaW1pdHM6IDU2 IEdTSSwgMTExMiBNU0kvTVNJLVgKPiAoWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQg U2NoZWR1bGVyIChjcmVkaXQpCj4gKFhFTikgRGV0ZWN0ZWQgMzAxMC4yMjAgTUh6IHByb2Nlc3Nv ci4KPiAoWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgo+IChYRU4pIEFNRCBGYW0xMGggbWFj aGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZAo+IChYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFi bGVkLgo+IChYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkCj4gKFhFTikgIC0gRG9tMCBt b2RlOiBSZWxheGVkCj4gKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCj4gKFhFTikgIC0+IFVz aW5nIG5ldyBBQ0sgbWV0aG9kCj4gKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBw aW4xPTIgYXBpYzI9LTEgcGluMj0tMQo+IChYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I eiBIUEVUCj4gw78oWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KPiAoWEVO KSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVh dHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4gKFhFTikgIC0gTGFz dCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikgIC0gTmV4dC1SSVAg U2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKPiAoWEVO KSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg ZGV0ZWN0ZWQuCj4gKFhFTikgQnJvdWdodCB1cCA2IENQVXMKPiAoWEVOKSBIUEVUJ3MgTVNJIG1v ZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi bGVkLgo+IChYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCj4gKFhFTikgTUNBOiBVc2UgaHcgdGhy ZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQo+IChYRU4pIG1jaGVja19wb2xs OiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KPiAoWEVOKSBYZW5vcHJvZmls ZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCj4g KFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqCj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTog cGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4NzdjMDAwCj4gKFhFTikgZWxmX3BhcnNlX2Jp bmFyeTogcGhkcjogcGFkZHI9MHgxNzdjMDAwIG1lbXN6PTB4OGRhODgKPiAoWEVOKSBlbGZfcGFy c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE4MGEwMDAgbWVtc3o9MHg4YzgKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE4MGIwMDAgbWVtc3o9MHgxNGE1OAo+IChYRU4p IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgyMDAwMCBtZW1zej0weDIxMjAwMAo+ IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MWEzMjAwMAo+ IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiCj4gKFhFTikgZWxm X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKPiAoWEVOKSBlbGZfeGVuX3Bh cnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxODIwMjAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwOTAwMAo+IChYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9h Ym92ZV80Z2IiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCj4g KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKPiAoWEVOKSBlbGZf eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpCj4gKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKPiAoWEVOKSBlbGZfeGVuX2FkZHJfY2FsY19j aGVjazogYWRkcmVzc2VzOgo+IChYRU4pICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm ZjgwMDAwMDAwCj4gKFhFTikgICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKPiAoWEVOKSAgICAg dmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tz dGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCj4gKFhFTikgICAgIHZpcnRfa2VuZCAgICAg ICAgPSAweGZmZmZmZmZmODFhMzIwMDAKPiAoWEVOKSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4 ZmZmZmZmZmY4MTgyMDIwMAo+IChYRU4pICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm ZmZmZmZmZmZmCj4gKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKPiAo WEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAw eDFhMzIwMDAKPiAoWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4gKFhFTikgIERv bTAgYWxsb2MuOiAgIDAwMDAwMDAyMjQwMDAwMDAtPjAwMDAwMDAyMjgwMDAwMDAgKDUwNjI2MyBw YWdlcyB0byBiZSBhbGxvY2F0ZWQpCj4gKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyMmY5 OTcwMDAtPjAwMDAwMDAyMmZmZmY2MDAKPiAoWEVOKSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVO VDoKPiAoWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MWEz MjAwMAo+IChYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgxYTMyMDAwLT5mZmZmZmZmZjgy MDlhNjAwCj4gKFhFTikgIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODIwOWIwMDAtPmZmZmZmZmZm ODI0OWIwMDAKPiAoWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjQ5YjAwMC0+ZmZmZmZm ZmY4MjQ5YjRiNAo+IChYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgyNDljMDAwLT5mZmZm ZmZmZjgyNGIzMDAwCj4gKFhFTikgIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODI0YjMwMDAtPmZm ZmZmZmZmODI0YjQwMDAKPiAoWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ ZmZmZmZmZmY4MjgwMDAwMAo+IChYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxODIwMjAw Cj4gKFhFTikgRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5 OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTc3YzAwMAo+IChY RU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MTc3YzAwMCAtPiAweGZm ZmZmZmZmODE4MDlhODgKPiAoWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZm ZmZmODE4MGEwMDAgLT4gMHhmZmZmZmZmZjgxODBhOGM4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5 OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxODBiMDAwIC0+IDB4ZmZmZmZmZmY4MTgxZmE1OAo+IChY RU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciA0IGF0IDB4ZmZmZmZmZmY4MTgyMDAwMCAtPiAweGZm ZmZmZmZmODE4YjMwMDAKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChY RU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVO KSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikg KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoq KioqKiogVGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkg ZW5zdXJpbmcKPiAoWEVOKSAqKioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5 IGRlbGl2ZXJlZCBvbiB0aGUgc2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0 IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAq KioqKioqIHRpbWVrZWVwaW5nLiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24g dXNlIQo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKPiAoWEVOKSAzLi4uIDIuLi4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERP TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAo WEVOKSBGcmVlZCAyMzZrQiBpbml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp Y2FsIG1lbW9yeQo+IFhlbjogc2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQg c3RhcnRlZC4uLgo+IEVSUk9SOiBVbmFibGUgdG8gbG9jYXRlIElPQVBJQyBmb3IgR1NJIDIKPiBF UlJPUjogVW5hYmxlIHRvIGxvY2F0ZSBJT0FQSUMgZm9yIEdTSSA5Cj4gKFhFTikgdHJhcHMuYzoy NDA1OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw MGU0YTc1ZGY4NjUxNCB0byAweDAwMDAwMDAwMDAwMDAwMDAuCj4gKFhFTikgdHJhcHMuYzoyNDA1 OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwMCBmcm9tIDB4MDAwMDAz MGUxYjBlZmZlOSB0byAweDAwMDAwMDAwMDA0MzAwNzYuCj4gRVJST1I6IFVuYWJsZSB0byBsb2Nh dGUgSU9BUElDIGZvciBHU0kgOQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjAwLjAKPiAoWEVO KSBQQ0kgYWRkIGRldmljZSAwMDowMC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDIuMAo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjA0LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDow NS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDYuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwOjA3LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowZC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDA6MTEuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjAKPiAoWEVOKSBQQ0kg YWRkIGRldmljZSAwMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTMuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwOjEzLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC4wCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTQuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE0 LjMKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDA6MTQuNQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE2LjAKPiAoWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTguMAo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwOjE4LjEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4yCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDA6MTguMwo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjQKPiAo WEVOKSBQQ0kgYWRkIGRldmljZSAwNzowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDc6MDAu MQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDA2OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAw NjowMC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDU6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDA0OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMzowMC4wCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDI6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAyOjAwLjEKPiByZWdpc3Rl cmluZyBuZXRiYWNrCj4gSVQ4NyBXRFQ6IFVua25vd24gQ2hpcCBmb3VuZCwgQ2hpcCA4NzIxIFJl dmlzaW9uIDAwMDEKPiBbRmlybXdhcmUgQnVnXTogcG93ZXJub3ctazg6IE5vIGNvbXBhdGlibGUg QUNQSSBfUFNTIG9iamVjdHMgZm91bmQuCj4gW0Zpcm13YXJlIEJ1Z106IHBvd2Vybm93LWs4OiBU cnkgYWdhaW4gd2l0aCBsYXRlc3QgQklPUy4KPiBMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLgo+IElO SVQ6IHZlcnNpb24gMi44OCBib290aW5nCj4gVXNpbmcgbWFrZWZpbGUtc3R5bGUgY29uY3VycmVu dCBib290IGluIHJ1bmxldmVsIFMuCj4gU3RhcnRpbmcgdGhlIGhvdHBsdWcgZXZlbnRzIGRpc3Bh dGNoZXI6IHVkZXZkLgo+IFN5bnRoZXNpemluZyB0aGUgaW5pdGlhbCBob3RwbHVnIGV2ZW50cy4u LmRvbmUuCj4gV2FpdGluZyBmb3IgL2RldiB0byBiZSBmdWxseSBwb3B1bGF0ZWQuLi51ZGV2ZC13 b3JrWzE0MjldOiBrZXJuZWwtcHJvdmlkZWQgbmFtZSAnYmxrdGFwLWNvbnRyb2wnIGFuZCBOQU1F PSAneGVuL2Jsa3RhcC0yL2NvbnRyb2wnIGRpc2FncmVlLCBwbGVhc2UgdXNlIFNZTUxJTksrPSBv ciBjaGFuZ2UgdGhlIGtlcm5lbCB0byBwcm92aWRlIHRoZSBwcm9wZXIgbmFtZQo+IAo+IGRvbmUu Cj4gU2V0dGluZyBwcmVsaW1pbmFyeSBrZXltYXAuLi5kb25lLgo+IEFjdGl2YXRpbmcgc3dhcC4u LmRvbmUuCj4gQ2hlY2tpbmcgcm9vdCBmaWxlIHN5c3RlbS4uLmZzY2sgZnJvbSB1dGlsLWxpbnV4 LW5nIDIuMTcuMgo+IEhPV1RPX1JPT1Q6IGNsZWFuLCA5NTA1Ni8xNDE5ODQwIGZpbGVzLCA3MzEy MDcvNTY3OTEwNCBibG9ja3MgKGNoZWNrIGluIDMgbW91bnRzKQo+IGRvbmUuCj4gTG9hZGluZyBr ZXJuZWwgbW9kdWxlcy4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgaWZ1cGRvd24uLi4uCj4gU2V0dGlu ZyB1cCBuZXR3b3JraW5nLi4uLgo+IFNldHRpbmcgdXAgTFZNIFZvbHVtZSBHcm91cHMgIFJlYWRp bmcgYWxsIHBoeXNpY2FsIHZvbHVtZXMuICBUaGlzIG1heSB0YWtlIGEgd2hpbGUuLi4KPiAgIEZv dW5kIHZvbHVtZSBncm91cCAibGVtcm91Y2giIHVzaW5nIG1ldGFkYXRhIHR5cGUgbHZtMgo+ICAg NCBsb2dpY2FsIHZvbHVtZShzKSBpbiB2b2x1bWUgZ3JvdXAgImxlbXJvdWNoIiBub3cgYWN0aXZl Cj4gLgo+IEFjdGl2YXRpbmcgbHZtIGFuZCBtZCBzd2FwLi4uZG9uZS4KPiBDaGVja2luZyBmaWxl IHN5c3RlbXMuLi5mc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBkb25lLgo+IE1vdW50 aW5nIGxvY2FsIGZpbGVzeXN0ZW1zLi4uZG9uZS4KPiBBY3RpdmF0aW5nIHN3YXBmaWxlIHN3YXAu Li5kb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTZXR0aW5nIGtlcm5l bCB2YXJpYWJsZXMgLi4uZG9uZS4KPiBDb25maWd1cmluZyBuZXR3b3JrIGludGVyZmFjZXMuLi5k b25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTZXR0aW5nIGNvbnNvbGUg c2NyZWVuIG1vZGVzLgo+IFJjYW5ub3QgKHVuKXNldCBwb3dlcnNhdmUgbW9kZQo+IFNraXBwaW5n IGZvbnQgYW5kIGtleW1hcCBzZXR1cCAoaGFuZGxlZCBieSBjb25zb2xlLXNldHVwKS4KPiBTZXR0 aW5nIHVwIGNvbnNvbGUgZm9udCBhbmQga2V5bWFwLi4uZG9uZS4KPiBJTklUOiBFbnRlcmluZyBy dW5sZXZlbDogMgo+IFVzaW5nIG1ha2VmaWxlLXN0eWxlIGNvbmN1cnJlbnQgYm9vdCBpbiBydW5s ZXZlbCAyLgo+IGFjcGlkOiBzdGFydGluZyB1cCB3aXRoIHByb2MgZnMKPiAKPiBhY3BpZDogMSBy dWxlIGxvYWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcg aXMgb2ZmCj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0g bWVzc2FnZSBidXM6IGRidXMuCj4gU3RhcnRpbmcgcGVyaW9kaWMgY29tbWFuZCBzY2hlZHVsZXI6 IGNyb24uCj4gU3RhcnRpbmcgT3BlbkJTRCBTZWN1cmUgU2hlbGwgc2VydmVyOiBzc2hkLgo+IFN0 YXJ0aW5nIHhlbnN0b3JlZC4uLlhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVO QlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw dSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFi bGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+ IAo+IFNldHRpbmcgZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4g QkxLVEFQQ1RSTFsyMTU2XTogYmxrdGFwY3RybC5jOjc5MDogYmxrdGFwY3RybDogdjEuMC4wCj4g Cj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxrdGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbcmF3 IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo3OTI6IEZv dW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxr dGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBC TEtUQVBDVFJMWzIxNTZdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNr IGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo3OTI6IEZv dW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxr dGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJM S1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxl ZAo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo4NTk6IGNvdWxkbid0IG9wZW4g YmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo5MjI6 IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2Ug MDA6MTIuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjIKPiAvdXNyL2xvY2FsL2Jpbi94 ZW5fc3RhcnQuc2g6IGxpbmUgMTU6IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDc6MDAuMC9k cml2ZXIvdW5iaW5kOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gVXNpbmcgY29uZmlnIGZp bGUgIi9ldGMveGVuL3dpbmRvd3MiLgo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21h cDphZGQgZl9ncG9ydD0zYjAgZl9tcG9ydD0zYjAgbnA9Ywo+IChYRU4pIGRvbWN0bC5jOjk4Njpk MCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWEwIG1mbj1hMCBucl9tZm5zPTIwCj4gKFhFTikgZG9tY3Rs LmM6MTA0MjpkMCBpb3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNjMCBmX21wb3J0PTNjMCBucD0zCj4g KFhFTikgZG9tY3RsLmM6MTA0MjpkMCBpb3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNjNCBmX21wb3J0 PTNjNCBucD0xYwo+IChYRU4pIEhWTTE6IEhWTSBMb2FkZXIKPiAoWEVOKSBIVk0xOiBEZXRlY3Rl ZCBYZW4gdjQuMi11bnN0YWJsZQo+IChYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAw MCwgZXZlbnQgY2hhbm5lbCA3Cj4gU3RhcnRlZCBkb21haW4gd2luZG93cyAoaWQ9MSkoWEVOKSBI Vk0xOiBTeXN0ZW0gcmVxdWVzdGVkIFJPTUJJT1MKPiAKPiAoWEVOKSBIVk0xOiBDUFUgc3BlZWQg aXMgMzAxMCBNSHoKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDAg LT4gNQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikg aXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCj4gKFhFTikgSFZNMTog UENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBD SSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExCj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDIgcm91 dGVkIHRvIElSUTExCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCAw IC0+IDUKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQo+IChYRU4p IEhWTTE6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6 MCBJTlRBLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIElOVEEtPklSUTUKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2 OjAgSU5UQi0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBJTlRBLT5JUlE1Cj4gKFhF TikgSFZNMTogcGNpIGRldiAwODowIElOVEItPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAw OTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDEw MDAwMDAwOiBlMDAwMDAwYwo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDog Z2ZuPWUwMDAwIG1mbj1kMDAwMCBucl9tZm5zPTEwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAw MzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMDAwMDAwOAo+IChYRU4pIEhWTTE6IHBjaSBkZXYg MDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjEwMDAwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6 ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnJfbWZucz0yMAo+IChYRU4p IEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTggc2l6ZSAwMDAyMDAwMDogZjEwMjAwMDQKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAwMjAwMDA6IGYxMDQwMDAwCj4gKFhF TikgSFZNMTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIDAwMDA0MDAwOiBmMTA2MDAwNAo+IChY RU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDYwIG1mbj1mZTliYyBu cl9tZm5zPTQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA5OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6 IGYxMDY0MDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEw NjQgbWZuPWZlM2Y4IG5yX21mbnM9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAg c2l6ZSAwMDAwMTAwMDogZjEwNjgwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21h cDphZGQ6IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnJfbWZucz0xCj4gKFhFTikgSFZNMTogcGNpIGRl diAwODowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2OTAwMAo+IChYRU4pIGRvbWN0bC5jOjk4 NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY5IG1mbj1mMDAwMCBucl9tZm5zPTEKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6IDAwMDBjMDAxCj4gKFhF TikgSFZNMTogcGNpIGRldiAwNTowIGJhciAyMCBzaXplIDAwMDAwMTAwOiAwMDAwYzEwMQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMyMDEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMjQxCj4g KFhFTikgSFZNMTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246Cj4gKFhFTikgSFZNMTog IC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMv OF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZp eGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0g Q1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0g Li4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BV NCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4u IGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVNSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U UlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogVGVzdGluZyBI Vk0gZW52aXJvbm1lbnQ6Cj4gKFhFTikgSFZNMTogIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91 bmRhcmllcyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQ R1MgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6IFBhc3NlZCAyIG9mIDIgdGVzdHMKPiAoWEVOKSBI Vk0xOiBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCj4gKFhFTikgSFZNMTogTG9hZGluZyBST01C SU9TIC4uLgo+IChYRU4pIEhWTTE6IDk2NjAgYnl0ZXMgb2YgUk9NQklPUyBoaWdoLW1lbW9yeSBl eHRlbnNpb25zOgo+IChYRU4pIEhWTTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAwMDAwLTB4ZmMw MDI1YmMgLi4uIGRvbmUKPiAoWEVOKSBIVk0xOiBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCj4gKFhF TikgSFZNMTogTG9hZGluZyBWR0FCSU9TIG9mIHBhc3N0aHJvdWdoZWQgZ2Z4IC4uLgo+IChYRU4p IEhWTTE6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uCj4gKFhFTikgSFZNMTogIC0gTWFudWZh Y3R1cmVyOiBodHRwOi8vZXRoZXJib290Lm9yZwo+IChYRU4pIEhWTTE6ICAtIFByb2R1Y3QgbmFt ZTogZ1BYRQo+IChYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBIVk0xOiAgLSBM byBkYXRhOiAwMDBlYTAyMC0wMDBlYTA0Zgo+IChYRU4pIEhWTTE6ICAtIEhpIGRhdGE6IGZjMDAy ODAwLWZjMDEyOTFmCj4gKFhFTikgSFZNMTogdm04NiBUU1MgYXQgZmMwMTJjMDAKPiAoWEVOKSBI Vk0xOiBCSU9TIG1hcDoKPiAoWEVOKSBIVk0xOiAgYzAwMDAtY2ZmZmY6IFZHQSBCSU9TCj4gKFhF TikgSFZNMTogIGQwMDAwLWUxZmZmOiBFdGhlcmJvb3QgUk9NCj4gKFhFTikgSFZNMTogIGViMDAw LWViMjBmOiBTTUJJT1MgdGFibGVzCj4gKFhFTikgSFZNMTogIGYwMDAwLWZmZmZmOiBNYWluIEJJ T1MKPiAoWEVOKSBIVk0xOiBFODIwIHRhYmxlOgo+IChYRU4pIEhWTTE6ICBbMDBdOiAwMDAwMDAw MDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0KPiAoWEVOKSBIVk0xOiAgWzAxXTog MDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDA5ZmMwMDogUkVTRVJWRUQKPiAoWEVOKSBI Vk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwOWZjMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVTRVJW RUQKPiAoWEVOKSBIVk0xOiAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBl MDAwMAo+IChYRU4pIEhWTTE6ICBbMDNdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAw MTAwMDAwOiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBbMDRdOiAwMDAwMDAwMDowMDEwMDAwMCAt IDAwMDAwMDAwOmUwMDAwMDAwOiBSQU0KPiAoWEVOKSBIVk0xOiAgSE9MRTogMDAwMDAwMDA6ZTAw MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMAo+IChYRU4pIEhWTTE6ICBbMDVdOiAwMDAwMDAwMDpm YzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBbMDZd OiAwMDAwMDAwMTowMDAwMDAwMCAtIDAwMDAwMDAxOjIwMDAwMDAwOiBSQU0KPiAoWEVOKSBIVk0x OiBJbnZva2luZyBST01CSU9TIC4uLgo+IChYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEgJCAk RGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkCj4gKFhFTikgSFZNMTogQm9jaHMgQklPUyAtIGJ1 aWxkOiAwNi8yMy85OQo+IChYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAw OC8xMi8wNyAxNzozMjoyOSAkCj4gKFhFTikgSFZNMTogT3B0aW9uczogYXBtYmlvcyBwY2liaW9z IGVsdG9yaXRvIFBNTSAKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBhdGEwLTA6IFBDSFM9 MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMKPiAoWEVOKSBIVk0x OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDIwNDgwIE1CeXRl cykKPiAoWEVOKSBIVk0xOiBhdGEwLTE6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJh IExDSFM9MTAyNC8yNTUvNjMKPiAoWEVOKSBIVk0xOiBhdGEwICBzbGF2ZTogUUVNVSBIQVJERElT SyBBVEEtNyBIYXJkLURpc2sgKDUxMjAwIE1CeXRlcykKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBI Vk0xOiAKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBQcmVzcyBGMTIgZm9yIGJvb3QgbWVu dS4KPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4u Cj4gKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIDAwMDA6N2MwMAo+IChYRU4pIGlycS5jOjI1ODog RG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBD SSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5r IDIgY2hhbmdlZCAxMSAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDMgY2hh bmdlZCA1IC0+IDAKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdm bj1lMDAwMCBtZm49ZDAwMDAgbnJfbWZucz0xMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBt ZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikg ZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21m bnM9MTAwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAy MCBtZm49ZmU5ZTAgbnJfbWZucz0yMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFw OnJlbW92ZTogZ2ZuPWYxMDYwIG1mbj1mZTliYyBucl9tZm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5 ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2MCBtZm49ZmU5YmMgbnJfbWZucz00Cj4gKFhF TikgZG9tY3RsLmM6OTk2OmQwIG1lbW9yeV9tYXA6cmVtb3ZlOiBnZm49ZjEwNjggbWZuPWZlM2Y3 IG5yX21mbnM9MQo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYx MDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21h cDpyZW1vdmU6IGdmbj1mMTA2OSBtZm49ZjAwMDAgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6 OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChY RU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY0IG1mbj1mZTNm OCBucl9tZm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1m MTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgZ3JhbnRfdGFibGUuYzoxMTU2OmQxIEV4 cGFuZGluZyBkb20gKDEpIGdyYW50IHRhYmxlIGZyb20gKDQpIHRvICgzMikgZnJhbWVzLgo+IChY RU4pIGlycS5jOjMyNDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBHU0kgMjgKPiAoWEVO KSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdmbj1lMDAwMCBtZm49ZDAwMDAg bnJfbWZucz0xMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTog Z2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1l bW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBk b21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnJfbWZu cz0yMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY4 IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDph ZGQ6IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6OTk2OmQw IG1lbW9yeV9tYXA6cmVtb3ZlOiBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4p IGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDYwIG1mbj1mZTliYyBucl9t Zm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdmbj1mMTA2 OSBtZm49ZjAwMDAgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6 YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChYRU4pIGRvbWN0bC5jOjk5Njpk MCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY0IG1mbj1mZTNmOCBucl9tZm5zPTQKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJf bWZucz00Cgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX18gICAgICAgICAgICAgICAg ICAgICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8 X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKPiAgIFwgIC8v IF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf IFx8IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IC8gX18vfF9ffCB8X3wgfCB8 IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xfXF9fX3xffCB8X3wgICAgfF98 KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEAobm9u ZSkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgpICkgU2F0IE1heSAgNSAxNTo0 ODo0OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBGcmkgTWF5IDA0IDExOjE4 OjQ4IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhFTikgQ29uc29sZSBvdXRwdXQg aXMgc3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0 K3NxdWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBk b20wX21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUg Y29tMT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1h dGlvbjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikg IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhF TikgRGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChY RU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAg UkFNIG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVz YWJsZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy dmVkKQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2 ZWQpCj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUp Cj4gKFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEp Cj4gKFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykK PiAoWEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+ IChYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4g KFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhF TikgQUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhT RFQgQ0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAg IDk3KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0 MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2 RTMgKHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFD UEk6IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4 IChyMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBNQ0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAg ICAgICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VN QjE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMw LCAwMDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVO KSBBQ1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEg QU1EICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0g SSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4 MTkwTUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAo WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+ IChYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxl IGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2 ZXIgZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikg QUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+ IChYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19z aXplWzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAo WEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3Nv ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ QyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRb MHgwM10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYK PiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVk KQo+IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJv Y2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFj cGlfaWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElD IChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJ Q1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIz Cj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9i YXNlWzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVz cyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg YnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZS IChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJ UlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRl Lgo+IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBB UElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlk OiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCEKPiAo WEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24K PiAoWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVnIENQVXMpCj4gKFhFTikgSVJR IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjog U01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjIyNSBN SHogcHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1E IEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgUENJOiBNQ0ZH IGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBm Zgo+IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYK PiAoWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVOKSBBTUQtVmk6IEVuYWJsaW5n IGdsb2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAo WEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMK PiAoWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9 MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGlt ZXIgaXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0 IEtpQi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQg YWR2YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4g KFhFTikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikg IC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBG aWx0ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Np c3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0 a0IsIDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9p ZD0weDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lk PTB4MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9 MHgxMDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w eDEwMDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIG1pY3JvY29kZTogY29s bGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgSFBFVCdzIE1TSSBtb2Rl IGhhc24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxl ZC4KPiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4pIE1DQTogVXNlIGh3IHRocmVz aG9sZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAoWEVOKSBtY2hlY2tfcG9sbDog TWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4gKFhFTikgWGVub3Byb2ZpbGU6 IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZgo+IChY RU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBo ZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDViMjAwMAo+IChYRU4pIGVsZl9wYXJzZV9iaW5h cnk6IHBoZHI6IHBhZGRyPTB4MTViMjAwMCBtZW1zej0weDY2MGUwCj4gKFhFTikgZWxmX3BhcnNl X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxNjE5MDAwIG1lbXN6PTB4MTI1MDAKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2MmMwMDAgbWVtc3o9MHgyMWIwMDAKPiAoWEVO KSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDE4NDcwMDAKPiAoWEVO KSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igo+IChYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog VklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl OiBFTlRSWSA9IDB4ZmZmZmZmZmY4MTYyYzIwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVf NGdiIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIgo+IChYRU4p IGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMiCj4gKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+IChYRU4pIGVsZl94ZW5fcGFy c2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6 IEhWX1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6 IGFkZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw MDAwMAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCj4gKFhFTikgICAgIHZpcnRf b2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9rc3RhcnQg ICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0g MHhmZmZmZmZmZjgxODQ3MDAwCj4gKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZm ZmZmODE2MmMyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZm ZmZmZgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCj4gKFhFTikg IERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxODQ3 MDAwCj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBEb20wIGFs bG9jLjogICAwMDAwMDAwMjI2MDAwMDAwLT4wMDAwMDAwMjI4MDAwMDAwICg1MTQ1MDAgcGFnZXMg dG8gYmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjJmOWM0MDAw LT4wMDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4g KFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODE4NDcwMDAK PiAoWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MTg0NzAwMC0+ZmZmZmZmZmY4MWU4MjIw MAo+IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgxZTgzMDAwLT5mZmZmZmZmZjgyMjgz MDAwCj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODIyODMwMDAtPmZmZmZmZmZmODIy ODM0YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjI4NDAwMC0+ZmZmZmZmZmY4 MjI5OTAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyMjk5MDAwLT5mZmZmZmZm ZjgyMjlhMDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZm ZmZmODI0MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTYyYzIwMAo+IChY RU4pIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk ciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODE1YjIwMDAKPiAoWEVOKSBl bGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1YjIwMDAgLT4gMHhmZmZmZmZm ZjgxNjE4MGUwCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgx NjE5MDAwIC0+IDB4ZmZmZmZmZmY4MTYyYjUwMAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk ciAzIGF0IDB4ZmZmZmZmZmY4MTYyYzAwMCAtPiAweGZmZmZmZmZmODE2YjIwMDAKPiAoWEVOKSBT Y3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2 aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChYRU4pIFN0ZC4gTG9nbGV2ZWw6 IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVOKSAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikgKioqKioqKiBXQVJOSU5HOiBD T05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoqKioqKiogVGhpcyBvcHRpb24g aXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkgZW5zdXJpbmcKPiAoWEVOKSAq KioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5IGRlbGl2ZXJlZCBvbiB0aGUg c2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lH TklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAqKioqKioqIHRpbWVrZWVwaW5n LiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQo+IChYRU4pICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPiAoWEVOKSAzLi4uIDIu Li4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScg dGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAoWEVOKSBGcmVlZCAyNTZrQiBp bml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQo+IFhlbjog c2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgo+IEluaXRp YWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lz IGNwdQo+IExpbnV4IHZlcnNpb24gMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IChyb290 QHhlbikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjNiBTTVAgUFJFRU1Q VCBTYXQgTWF5IDUgMjA6MTM6MjkgQ0VTVCAyMDEyCj4gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRl ciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBj aWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IEZyZWVp bmcgIDlhLTEwMCBwZm4gcmFuZ2U6IDEwMiBwYWdlcyBmcmVlZAo+IFJlbGVhc2VkIDEwMiBwYWdl cyBvZiB1bnVzZWQgbWVtb3J5Cj4gU2V0IDE5NzA5NCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nCj4g QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAwMDAwMDAwMDAwMDAg LSAwMDAwMDAwMDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAwMDA5YWMwMCAtIDAw MDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAw MDAwMGNmZTgwMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDBjZmU4MDAwMCAtIDAwMDAwMDAw Y2ZlOTgwMDAgKEFDUEkgZGF0YSkKPiAgWGVuOiAwMDAwMDAwMGNmZTk4MDAwIC0gMDAwMDAwMDBj ZmVjMDAwMCAoQUNQSSBOVlMpCj4gIFhlbjogMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2Zm MDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAx MDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzIwMDAwIC0gMDAwMDAwMDBmZWMyMTAw MCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAg KHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy ZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDIzMDAwMDAwMCAodXNh YmxlKQo+IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChFeGVjdXRlIERpc2Fi bGUpIHByb3RlY3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOgo+ ICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAodXNhYmxlKQo+ICB1 c2VyOiAwMDAwMDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gIHVz ZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCj4gIHVzZXI6 IDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gIHVzZXI6 IDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAgdXNlcjog MDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAw MDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAw MDAwMDAwZmVjMjAwMDAgLSAwMDAwMDAwMGZlYzIxMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAw MDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAwMDAw MDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gRE1JIHByZXNlbnQu Cj4gTm8gQUdQIGJyaWRnZSBmb3VuZAo+IGxhc3RfcGZuID0gMHg4MDAwMCBtYXhfYXJjaF9wZm4g PSAweDQwMDAwMDAwMAo+IGZvdW5kIFNNUCBNUC10YWJsZSBhdCBbZmZmZjg4MDAwMDBmZjc4MF0g ZmY3ODAKPiBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwODAw MDAwMDAKPiBSQU1ESVNLOiAwMTg0NzAwMCAtIDAxZTgzMDAwCj4gQUNQSTogUlNEUCAwMDAwMDAw MDAwMGZiZjIwIDAwMDI0ICh2MDIgQUNQSUFNKQo+IEFDUEk6IFhTRFQgMDAwMDAwMDBjZmU4MDEw MCAwMDA1QyAodjAxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFD UEk6IEZBQ1AgMDAwMDAwMDBjZmU4MDI5MCAwMDBGNCAodjAzIDEwMjgxMSBGQUNQMTc0MCAyMDEx MTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IERTRFQgMDAwMDAwMDBjZmU4MDQ3MCAwRTZFMyAo djAxICBBMTU5NSBBMTU5NTAwMCAwMDAwMDAwMCBJTlRMIDIwMDYwMTEzKQo+IEFDUEk6IEZBQ1Mg MDAwMDAwMDBjZmU5ODAwMCAwMDA0MAo+IEFDUEk6IEFQSUMgMDAwMDAwMDBjZmU4MDM5MCAwMDA5 OCAodjAxIDEwMjgxMSBBUElDMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IE1D RkcgMDAwMDAwMDBjZmU4MDQzMCAwMDAzQyAodjAxIDEwMjgxMSBPRU1NQ0ZHICAyMDExMTAyOCBN U0ZUIDAwMDAwMDk3KQo+IEFDUEk6IE9FTUIgMDAwMDAwMDBjZmU5ODA0MCAwMDA3MiAodjAxIDEw MjgxMSBPRU1CMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IEhQRVQgMDAwMDAw MDBjZmU4ZjhjMCAwMDAzOCAodjAxIDEwMjgxMSBPRU1IUEVUICAyMDExMTAyOCBNU0ZUIDAwMDAw MDk3KQo+IEFDUEk6IElWUlMgMDAwMDAwMDBjZmU4ZjkwMCAwMDBFMCAodjAxICBBTUQgICAgIFJE ODkwUyAwMDIwMjAzMSBBTUQgIDAwMDAwMDAwKQo+IEFDUEk6IFNTRFQgMDAwMDAwMDBjZmU4Zjll MCAwMEUxMCAodjAxIEEgTSBJICBQT1dFUk5PVyAwMDAwMDAwMSBBTUQgIDAwMDAwMDAxKQo+IE5v IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAo+IEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAw MDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gSW5pdG1lbSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAw MDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gICBOT0RFX0RBVEEgWzAwMDAwMDAwN2ZmZmIwMDAgLSAw MDAwMDAwMDdmZmZmZmZmXQo+IFpvbmUgUEZOIHJhbmdlczoKPiAgIERNQSAgICAgIDB4MDAwMDAw MTAgLT4gMHgwMDAwMTAwMAo+ICAgRE1BMzIgICAgMHgwMDAwMTAwMCAtPiAweDAwMTAwMDAwCj4g ICBOb3JtYWwgICBlbXB0eQo+IE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQo+ IGVhcmx5X25vZGVfbWFwWzJdIGFjdGl2ZSBQRk4gcmFuZ2VzCj4gICAgIDA6IDB4MDAwMDAwMTAg LT4gMHgwMDAwMDA5YQo+ICAgICAwOiAweDAwMDAwMTAwIC0+IDB4MDAwODAwMDAKPiBBQ1BJOiBQ TS1UaW1lciBJTyBQb3J0OiAweDgwOAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGlj X2lkWzB4MDBdIGVuYWJsZWQpCj4gQklPUyBidWc6IEFQSUMgdmVyc2lvbiBpcyAwIGZvciBDUFUg MC8weDAsIGZpeGluZyB1cCB0byAweDEwCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw aWNfaWRbMHgwMV0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p ZFsweDAyXSBlbmFibGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4 MDNdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0g ZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFi bGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGljX2lkWzB4ODZdIGRpc2FibGVk KQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxhcGljX2lkWzB4ODddIGRpc2FibGVkKQo+ IEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkK PiBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMwMDAwMCwg R1NJIDAtMjU1Cj4gQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdz aV9iYXNlWzI0XSkKPiBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAyNTUsIGFkZHJlc3Mg MHhmZWMyMDAwMCwgR1NJIDI0LTI3OQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJx IDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpCj4gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p cnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQo+IFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAg Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgo+IEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAw eGZlZDAwMDAwCj4gOCBQcm9jZXNzb3JzIGV4Y2VlZHMgTlJfQ1BVUyBsaW1pdCBvZiA2Cj4gU01Q OiBBbGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzCj4gQWxsb2NhdGluZyBQQ0kgcmVzb3Vy Y2VzIHN0YXJ0aW5nIGF0IDgwMDAwMDAwIChnYXA6IDgwMDAwMDAwOjRmZTgwMDAwKQo+IEJvb3Rp bmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KPiBYZW4gdmVyc2lvbjogNC4yLXVuc3Rh YmxlIChwcmVzZXJ2ZS1BRCkKPiBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6NiBucl9jcHVtYXNrX2Jp dHM6NiBucl9jcHVfaWRzOjYgbnJfbm9kZV9pZHM6MQo+IFBFUkNQVTogRW1iZWRkZWQgMjYgcGFn ZXMvY3B1IEBmZmZmODgwMDdmZjRiMDAwIHM3NTAwOCByODE5MiBkMjMyOTYgdTEwNjQ5Ngo+IEJ1 aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90 YWwgcGFnZXM6IDUxNDk3Mwo+IFBvbGljeSB6b25lOiBETUEzMgo+IEtlcm5lbCBjb21tYW5kIGxp bmU6IHBsYWNlaG9sZGVyIHJvb3Q9L2Rldi9tYXBwZXIvbGVtcm91Y2gteGVuIHJvIG1lbT0yRyBw YW5pYz0xNSB4ZW4tcGNpYmFjay5oaWRlPSgwMDoxNC4yKSBjb25zb2xlPWh2YzAgZWFybHlwcmlu dGs9eGVuCj4gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5 dGVzKQo+IFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBUTEIgYmV0d2VlbiBmZmZmODgwMDc5NjAw MDAwIC0gZmZmZjg4MDA3ZDYwMDAwMAo+IHNvZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4Nzk2MDAw MDAgLSAweDdkNjAwMDAwCj4gTWVtb3J5OiAxOTc1MjIway8yMDk3MTUyayBhdmFpbGFibGUgKDQ0 NzBrIGtlcm5lbCBjb2RlLCA0NzJrIGFic2VudCwgMTIxNDYwayByZXNlcnZlZCwgMTc2OGsgZGF0 YSwgNTk2ayBpbml0KQo+IFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0LCBPcmRlcj0wLTMs IE1pbk9iamVjdHM9MCwgQ1BVcz02LCBOb2Rlcz0xCj4gUHJlZW1wdGlibGUgaGllcmFyY2hpY2Fs IFJDVSBpbXBsZW1lbnRhdGlvbi4KPiAJVmVyYm9zZSBzdGFsbGVkLUNQVXMgZGV0ZWN0aW9uIGlz IGRpc2FibGVkLgo+IE5SX0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVy cmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5 Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6 IGNvbG91ciBWR0ErIDgweDI1Cj4gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg ZGlzYWJsZWQKPiBjb25zb2xlIFtodmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+ IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjI0IE1IeiBw cm9jZXNzb3IuCj4gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNjAyMC40NCBCb2dvTUlQUyAobHBqPTMwMTAy MjQpCj4gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hl IGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJ bm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYg Ynl0ZXMpCj4gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBkZXZpY2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQ cm9jZXNzb3IgSUQ6IDAKPiBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gQUNQSTogQ29yZSBy ZXZpc2lvbiAyMDExMDYyMwo+IGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSAyOTcKPiBQZXJmb3Jt YW5jZSBFdmVudHM6IChYRU4pIHRyYXBzLmM6MjU2MTpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlNGE3NWRmODY1MTQgdG8gMHgwMDAwMDAwMDAw MDBhYmNkLgo+IEJyb2tlbiBQTVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2 ZW50cyBvbmx5Lgo+IE1DRTogSW4ta2VybmVsIE1DRSBkZWNvZGluZyBlbmFibGVkLgo+IGluc3Rh bGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQo+IGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAzMDMK PiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIKPiBjcHUgMiBzcGlubG9jayBldmVudCBp cnEgMzA5Cj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzCj4gY3B1IDMgc3BpbmxvY2sg ZXZlbnQgaXJxIDMxNQo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgNAo+IGNwdSA0IHNw aW5sb2NrIGV2ZW50IGlycSAzMjEKPiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDUKPiBj cHUgNSBzcGlubG9jayBldmVudCBpcnEgMzI3Cj4gQnJvdWdodCB1cCA2IENQVXMKPiBkZXZ0bXBm czogaW5pdGlhbGl6ZWQKPiBHcmFudCB0YWJsZSBpbml0aWFsaXplZAo+IE5FVDogUmVnaXN0ZXJl ZCBwcm90b2NvbCBmYW1pbHkgMTYKPiBUT006IDAwMDAwMDAwZDAwMDAwMDAgYWthIDMzMjhNCj4g VE9NMjogMDAwMDAwMDIzMDAwMDAwMCBha2EgODk2ME0KPiBFeHRlbmRlZCBDb25maWcgU3BhY2Ug ZW5hYmxlZCBvbiAxIG5vZGVzCj4gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQKPiBQQ0k6 IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAwMDAt MHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKPiBQQ0k6IG5vdCB1c2luZyBNTUNPTkZJRwo+ IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzCj4gUENJOiBV c2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgZXh0ZW5kZWQgYWNjZXNzCj4gYmlvOiBjcmVh dGUgc2xhYiA8YmlvLTA+IGF0IDAKPiBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpCj4g QUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgRGV2aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koMy4w IF9TQ1AgRXh0ZW5zaW9ucykKPiBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9y IERldmljZSkKPiBBQ1BJOiBFeGVjdXRlZCAzIGJsb2NrcyBvZiBtb2R1bGUtbGV2ZWwgZXhlY3V0 YWJsZSBBTUwgY29kZQo+IEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKPiBBQ1BJOiAoc3VwcG9y dHMgUzAgUzUpCj4gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwo+IFBD STogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAw MC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQo+IFBDSTogTU1DT05GSUcgYXQgW21lbSAw eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2VydmVkIGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3Vy Y2VzCj4gQUNQSTogRUM6IEdQRSA9IDB4YSwgSS9POiBjb21tYW5kL3N0YXR1cyA9IDB4NjYsIGRh dGEgPSAweDYyCj4gSEVTVDogVGFibGUgbm90IGZvdW5kLgo+IFBDSTogVXNpbmcgaG9zdCBicmlk Z2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCBy ZXBvcnQgYSBidWcKPiBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBb YnVzIDAwLWZmXSkKPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lv ICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRv dyBbaW8gIDB4MGQwMC0weGZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ug d2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6MDA6 IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfcm9v dCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZmZmZm ZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhmMDAw MDAwMC0weGZlYmZmZmZmXQo+IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw Ny0wN10KPiBwY2kgMDAwMDowNjowMC4wOiBkaXNhYmxpbmcgQVNQTSBvbiBwcmUtMS4xIFBDSWUg ZGV2aWNlLiAgWW91IGNhbiBlbmFibGUgaXQgd2l0aCAncGNpZV9hc3BtPWZvcmNlJwo+IHBjaSAw MDAwOjAwOjA0LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KPiBwY2kgMDAwMDowMDowNS4w OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDUtMDVdCj4gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA0LTA0XQo+IHBjaSAwMDAwOjAwOjA3LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw My0wM10KPiBwY2kgMDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdCj4gcGNp IDAwMDA6MDA6MTQuNDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXSAoc3VidHJhY3RpdmUgZGVj b2RlKQo+ICBwY2kwMDAwOjAwOiBSZXF1ZXN0aW5nIEFDUEkgX09TQyBjb250cm9sICgweDFkKQo+ ICBwY2kwMDAwOjAwOiBBQ1BJIF9PU0MgY29udHJvbCAoMHgxYykgZ3JhbnRlZAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MDAuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDAwMDA6MDA6MDQuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDUuMAo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDYuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDA6MDcuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTEuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDA6MTIuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMgo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwMDA6MDA6MTMuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMu Mgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwMDA6MDA6MTQuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMwo+IChY RU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAw MDA6MDA6MTQuNQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MTguMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMQo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDAwMDA6MDA6MTguMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMwo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDc6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDc6MDAuMQo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDY6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDY6MDAuMQo+IHBjaSAwMDAwOjA2OjAwLjE6IEZhaWxlZCB0byBhZGQgLSBwYXNzdGhyb3VnaCBv ciBNU0kvTVNJLVggbWlnaHQgZmFpbCEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAw LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDAwOjAzOjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAyOjAwLjAKPiAo WEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAyOjAwLjEKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOS0FdIChJUlFzICo0IDcgMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBM aW5rIFtMTktCXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQg TGluayBbTE5LQ10gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xOS0RdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVw dCBMaW5rIFtMTktFXSAoSVJRcyA0ICo3IDEwIDExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1 cHQgTGluayBbTE5LRl0gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xOS0ddIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVy cnVwdCBMaW5rIFtMTktIXSAoSVJRcyA0IDcgMTAgMTEgMTQgMTUpICowLCBkaXNhYmxlZC4KPiB4 ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLgo+IHhlbi1iYWxsb29uOiBJ bml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTow MDAwOjA3OjAwLjAsZGVjb2Rlcz1pbyttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQo+IHZnYWFy YjogbG9hZGVkCj4gdmdhYXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA3OjAwLjAK PiBTQ1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu dGVyZmFjZSBkcml2ZXIgdXNiZnMKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug ZHJpdmVyIGh1Ygo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiCj4g UENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwo+IFN3aXRjaGluZyB0byBjbG9ja3NvdXJj ZSB4ZW4KPiBGUy1DYWNoZTogTG9hZGVkCj4gQ2FjaGVGaWxlczogTG9hZGVkCj4gcG5wOiBQblAg QUNQSSBpbml0Cj4gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lzdGVyZWQKPiBzeXN0ZW0gMDA6MDE6 IFttZW0gMHhmZWMyMDAwMC0weGZlYzIwMGZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0 ZW0gMDA6MDI6IFttZW0gMHhmNjAwMDAwMC0weGY2MDAzZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+ IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOCBmb3IgZ3NpIDgKPiB4ZW5fbWFwX3Bp cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDEzIGZvciBnc2kgMTMKPiBzeXN0ZW0gMDA6MDg6IFttZW0g MHhmZWMwMDAwMC0weGZlYzAwZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6 MDg6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3Rl bSAwMDowOTogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAw MDowOTogW2lvICAweDA0MGJdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MDRkNl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzAwLTB4 MGMwMV0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzE0XSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNTAtMHgwYzUxXSBoYXMgYmVl biByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNTJdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM2Y10gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwYzZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjZDAtMHgwY2QxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAw eDBjZDItMHgwY2QzXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBj ZDQtMHgwY2Q1XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjZDYt MHgwY2Q3XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjZDgtMHgw Y2RmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA4MDAtMHgwODlm XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBiMDAtMHgwYjFmXSBo YXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBiMjAtMHgwYjNmXSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA5MDAtMHgwOTBmXSBoYXMgYmVl biByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMgYmVlbiBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweGZlMDAtMHhmZWZlXSBoYXMgYmVlbiByZXNl cnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGNmZjAwMDAwLTB4Y2ZmZmZmZmZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmZiODAwMDAtMHhmZmJmZmZmZl0gaGFz IGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWMxMDAwMC0weGZlYzEwMDFm XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlZDgwMDAwLTB4ZmVk ODBmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDIzMC0weDAy M2ZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDI5MC0weDAyOWZd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGY0MC0weDBmNGZdIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGEzMC0weDBhM2ZdIGhhcyBi ZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBiOiBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0g aGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDAwMDAwMC0weDAwMDlm ZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDBjMDAw MC0weDAwMGNmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0g MHgwMDBlMDAwMC0weDAwMGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6 MGM6IFttZW0gMHgwMDEwMDAwMC0weGNmZWZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBz eXN0ZW0gMDA6MGM6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVz ZXJ2ZWQKPiBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBkZXZpY2VzCj4gQUNQSTogQUNQSSBidXMg dHlwZSBwbnAgdW5yZWdpc3RlcmVkCj4gcGNpYmFjayAwMDAwOjAwOjE0LjI6IHNlaXppbmcgZGV2 aWNlCj4gUE0tVGltZXIgZmFpbGVkIGNvbnNpc3RlbmN5IGNoZWNrICAoMHgweGZmZmZmZikgLSBh Ym9ydGluZy4KPiBwY2kgMDAwMDowMDowMi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDctMDddCj4g cGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0KPiBw Y2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlOTAwMDAwLTB4ZmU5ZmZm ZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0w eGRmZmZmZmZmIDY0Yml0IHByZWZdCj4gcGNpIDAwMDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBb YnVzIDA2LTA2XQo+IHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAw MC0weGRmZmZdCj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTgw MDAwMC0weGZlOGZmZmZmXQo+IHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw NS0wNV0KPiBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAtMHhj ZmZmXQo+IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU3MDAwMDAt MHhmZTdmZmZmZl0KPiBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRd Cj4gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhiMDAwLTB4YmZmZl0K PiBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNjAwMDAwLTB4ZmU2 ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQo+IHBj aSAwMDAwOjAwOjA3LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU1MDAwMDAtMHhmZTVmZmZm Zl0KPiBwY2kgMDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdCj4gcGNpIDAw MDA6MDA6MGQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhhMDAwLTB4YWZmZl0KPiBwY2kgMDAw MDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNDAwMDAwLTB4ZmU0ZmZmZmZdCj4g cGNpIDAwMDA6MDA6MTQuNDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXQo+IHBjaSAwMDAwOjAw OjAyLjA6IFBDSSBJTlQgQSAtPiBHU0kgNTIgKGxldmVsLCBsb3cpIC0+IElSUSA1Mgo+IHhlbl9t YXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9yIGdzaSA1Mgo+IEFscmVhZHkgc2V0dXAg dGhlIEdTSSA6NTIKPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDUyIChsZXZl bCwgbG93KSAtPiBJUlEgNTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUyIGZv ciBnc2kgNTIKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUyCj4gcGNpIDAwMDA6MDA6MDUuMDog UENJIElOVCBBIC0+IEdTSSA1MiAobGV2ZWwsIGxvdykgLT4gSVJRIDUyCj4gcGNpIDAwMDA6MDA6 MDYuMDogUENJIElOVCBBIC0+IEdTSSA1MyAobGV2ZWwsIGxvdykgLT4gSVJRIDUzCj4geGVuX21h cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MyBmb3IgZ3NpIDUzCj4gQWxyZWFkeSBzZXR1cCB0 aGUgR1NJIDo1Mwo+IHBjaSAwMDAwOjAwOjA3LjA6IFBDSSBJTlQgQSAtPiBHU0kgNTMgKGxldmVs LCBsb3cpIC0+IElSUSA1Mwo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBJTlQgQSAtPiBHU0kgNTQg KGxldmVsLCBsb3cpIC0+IElSUSA1NAo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkg Mgo+IElQIHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1 MjQyODggYnl0ZXMpCj4gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0 IChvcmRlcjogMTAsIDQxOTQzMDQgYnl0ZXMpCj4gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz OiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpCj4gVENQOiBIYXNoIHRhYmxlcyBjb25m aWd1cmVkIChlc3RhYmxpc2hlZCAyNjIxNDQgYmluZCA2NTUzNikKPiBUQ1AgcmVubyByZWdpc3Rl cmVkCj4gVURQIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVz KQo+IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5 dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQo+IFVucGFja2luZyBpbml0 cmFtZnMuLi4KPiBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDYzODRrIGZyZWVkCj4gbWljcm9jb2Rl OiBNaWNyb2NvZGUgVXBkYXRlIERyaXZlcjogdjIuMDAgPHRpZ3JhbkBhaXZhemlhbi5mc25ldC5j by51az4sIFBldGVyIE9ydWJhCj4gTlRGUyBkcml2ZXIgMi4xLjMwIFtGbGFnczogUi9XXS4KPiBt c2dtbmkgaGFzIGJlZW4gc2V0IHRvIDM4NzAKPiBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJz ZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQo+IGlvIHNjaGVkdWxlciBu b29wIHJlZ2lzdGVyZWQgKGRlZmF1bHQpCj4gcGNpZXBvcnQgMDAwMDowMDowMi4wOiBTaWduYWxp bmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDc6MDAuMDogU2ln bmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA3OjAwLjE6 IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAw OjAwOjA0LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kg MDAwMDowNjowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4g cGNpIDAwMDA6MDY6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw dAo+IHBjaWVwb3J0IDAwMDA6MDA6MDUuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F IGludGVycnVwdAo+IHBjaSAwMDAwOjA1OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAwOjAwOjA2LjA6IFNpZ25hbGluZyBQTUUgdGhy b3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNDowMC4wOiBTaWduYWxpbmcgUE1F IHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowNy4wOiBTaWdu YWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDM6MDAuMDog U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6 MDA6MGQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAw MDAwOjAyOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBw Y2kgMDAwMDowMjowMC4xOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0 Cj4gcGNpX2hvdHBsdWc6IFBDSSBIb3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUKPiBpbnB1 dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9QTlAwQzBD OjAwL2lucHV0L2lucHV0MAo+IEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSQl0KPiBpbnB1dDogUG93 ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0 MQo+IEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KPiBFUlNUOiBUYWJsZSBpcyBub3QgZm91bmQh Cj4gR0hFUzogSEVTVCBpcyBub3QgZW5hYmxlZCEKPiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0 YWxsZWQuCj4gcGNpYmFjayAwMDAwOjAwOjE0LjI6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVs LCBsb3cpIC0+IElSUSAxNgo+IHBjaWJhY2sgMDAwMDowMDoxNC4yOiBQQ0kgSU5UIEEgZGlzYWJs ZWQKPiB4ZW4tcGNpYmFjazogYmFja2VuZCBpcyB2cGNpCj4gU2VyaWFsOiA4MjUwLzE2NTUwIGRy aXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZGlzYWJsZWQKPiBzZXJpYWwgMDAwMDowMjowMC4w OiBQQ0kgSU5UIEEgLT4gR1NJIDQwIChsZXZlbCwgbG93KSAtPiBJUlEgNDAKPiBzZXJpYWwgMDAw MDowMjowMC4xOiBQQ0kgSU5UIEIgLT4gR1NJIDQxIChsZXZlbCwgbG93KSAtPiBJUlEgNDEKPiAw MDAwOjAyOjAwLjE6IHR0eVMwIGF0IEkvTyAweGE4ODAgKGlycSA9IDQxKSBpcyBhIFNUMTY2NTBW Mgo+IGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTCj4gTm9uLXZvbGF0 aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwo+IEhhbmdjaGVjazogc3RhcnRpbmcgaGFuZ2NoZWNrIHRp bWVyIDAuOS4xICh0aWNrIGlzIDE4MCBzZWNvbmRzLCBtYXJnaW4gaXMgNjAgc2Vjb25kcykuCj4g SGFuZ2NoZWNrOiBVc2luZyBnZXRyYXdtb25vdG9uaWMoKS4KPiBsb29wOiBtb2R1bGUgbG9hZGVk Cj4gYWhjaSAwMDAwOjAwOjExLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+ IElSUSAxOQo+IGFoY2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA2IHBv cnRzIDYgR2JwcyAweDNmIGltcGwgU0FUQSBtb2RlCj4gYWhjaSAwMDAwOjAwOjExLjA6IGZsYWdz OiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBpbyBzbHVtIHBhcnQgCj4gc2Nz aTAgOiBhaGNpCj4gc2NzaTEgOiBhaGNpCj4gc2NzaTIgOiBhaGNpCj4gc2NzaTMgOiBhaGNpCj4g c2NzaTQgOiBhaGNpCj4gc2NzaTUgOiBhaGNpCj4gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJh ciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTEwMCBpcnEgMTkKPiBhdGEyOiBTQVRBIG1h eCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMTgwIGlycSAxOQo+ IGF0YTM6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUz ZmUyMDAgaXJxIDE5Cj4gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2Zl MDAwIHBvcnQgMHhmZTNmZTI4MCBpcnEgMTkKPiBhdGE1OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFy IG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMzAwIGlycSAxOQo+IGF0YTY6IFNBVEEgbWF4 IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUzODAgaXJxIDE5Cj4g YWhjaSAwMDAwOjA2OjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgNDQgKGxldmVsLCBsb3cpIC0+IElS USA0NAo+IGFoY2kgMDAwMDowNjowMC4wOiBBSENJIDAwMDEuMDAwMCAzMiBzbG90cyAyIHBvcnRz IDMgR2JwcyAweDMgaW1wbCBTQVRBIG1vZGUKPiBhaGNpIDAwMDA6MDY6MDAuMDogZmxhZ3M6IDY0 Yml0IG5jcSBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2k2IDogYWhjaQo+IHNj c2k3IDogYWhjaQo+IGF0YTc6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTgxOTJAMHhmZThmZTAw MCBwb3J0IDB4ZmU4ZmUxMDAgaXJxIDQ0Cj4gYXRhODogU0FUQSBtYXggVURNQS8xMzMgYWJhciBt ODE5MkAweGZlOGZlMDAwIHBvcnQgMHhmZThmZTE4MCBpcnEgNDQKPiB0dW46IFVuaXZlcnNhbCBU VU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNgo+IHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255 YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgo+IHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMjkKPiBz a3kyIDAwMDA6MDQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSA1MSAobGV2ZWwsIGxvdykgLT4gSVJR IDUxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IFl1a29uLTIgT3B0aW1hIGNoaXAgcmV2aXNpb24gMQo+ IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBhZGRyIDIwOmNmOjMwOjZkOjg5OmE1Cj4gY2RjX25j bTogMDQtQXVnLTIwMTEKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy IGNkY19uY20KPiBmaXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogUENJIElOVCBBIC0+IEdTSSA0 NiAobGV2ZWwsIGxvdykgLT4gSVJRIDQ2Cj4gZmlyZXdpcmVfb2hjaTogQWRkZWQgZnctb2hjaSBk ZXZpY2UgMDAwMDowNTowMC4wLCBPSENJIHYxLjEwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVp cmtzIDB4MTEKPiBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAo RUhDSSkgRHJpdmVyCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBQQ0kgSU5UIEIgLT4gR1NJIDE3 IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IEVIQ0kgSG9z dCBDb250cm9sbGVyCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBuZXcgVVNCIGJ1cyByZWdpc3Rl cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGFwcGx5 aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+ IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogZGVidWcgcG9ydCAxCj4gZWhjaV9oY2QgMDAwMDowMDox Mi4yOiBpcnEgMTcsIGlvIG1lbSAweGZlM2ZlNDAwCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBV U0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMAo+IHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBmb3Vu ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKPiB1c2IgdXNiMTogTmV3IFVTQiBkZXZp Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKPiB1c2IgdXNiMTog UHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBM aW51eCAzLjIuMC1yYzItMTEyMDItZ2QzNTA3YWYtZGlydHkgZWhjaV9oY2QKPiB1c2IgdXNiMTog U2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjIKPiBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZAo+ IGh1YiAxLTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJu aW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwo+IGVoY2lf aGNkIDAwMDA6MDA6MTMuMjogUENJIElOVCBCIC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJR IDE3Cj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lf aGNkIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51 bWJlciAyCj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAv SHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEz LjI6IGRlYnVnIHBvcnQgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0g MHhmZTNmZTgwMAo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJ IDEuMDAKPiB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlk UHJvZHVjdD0wMDAyCj4gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQ cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBD b250cm9sbGVyCj4gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAy LWdkMzUwN2FmLWRpcnR5IGVoY2lfaGNkCj4gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDow MDoxMy4yCj4gaHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0 cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAx Nwo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFBD SSBJTlQgQiAtPiBHU0kgMTcgKGxldmVsLCBsb3cpIC0+IElSUSAxNwo+IGVoY2lfaGNkIDAwMDA6 MDA6MTYuMjogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IG5l dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMwo+IGVoY2lfaGNkIDAw MDA6MDA6MTYuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1t eSBxaCB3b3JrYXJvdW5kCj4gYXRhNTogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJv bCAzMDApCj4gYXRhMzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4g YXRhMTogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApCj4g YXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhNDogU0FU QSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMjogU0FUQSBsaW5rIGRv d24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBkZWJ1 ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4ZmUzZmVj MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwCj4g YXRhMS4wMDogQVRBLTg6IElOVEVMIFNTRFNBMkNXMTIwRzMsIDRQQzEwMzYyLCBtYXggVURNQS8x MzMKPiBhdGExLjAwOiAyMzQ0NDE2NDggc2VjdG9ycywgbXVsdGkgMTogTEJBNDggTkNRIChkZXB0 aCAzMS8zMikKPiB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs IGlkUHJvZHVjdD0wMDAyCj4gYXRhNzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJv bCAzMDApCj4gYXRhODogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4g dXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5 IGVoY2lfaGNkCj4gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4yCj4gYXRhMS4w MDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKPiBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3Mg ICAgIEFUQSAgICAgIElOVEVMIFNTRFNBMkNXMTIgNFBDMSBQUTogMCBBTlNJOiA1Cj4gaHViIDMt MDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMy0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+IHNk IDA6MDowOjA6IFtzZGFdIDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEyMCBH Qi8xMTEgR2lCKQo+IHNkIDA6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCj4gc2Qg MDowOjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQs IGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBCj4gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhv c3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyCj4gIHNkYTogc2RhMSBzZGEyCj4gb2hjaV9oY2Qg MDAwMDowMDoxMi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgK PiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2Qg MDAwMDowMDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy IDQKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUzZjcwMDAKPiBz ZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKPiB1c2IgdXNiNDogTmV3IFVTQiBk ZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4gdXNiIHVzYjQ6IE5l dyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4g dXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjQ6IE1hbnVm YWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IG9oY2lfaGNkCj4g dXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4wCj4gaHViIDQtMDoxLjA6IFVTQiBo dWIgZm91bmQKPiBodWIgNC0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9n c2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6 MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTggKGxldmVsLCBs b3cpIC0+IElSUSAxOAo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBIb3N0IENvbnRyb2xs ZXIKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2ln bmVkIGJ1cyBudW1iZXIgNQo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogaXJxIDE4LCBpbyBtZW0g MHhmZTNmYzAwMAo+IHVzYiAxLTE6IG5ldyBoaWdoLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg dXNpbmcgZWhjaV9oY2QKPiB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9y PTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6 IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjU6IFByb2R1Y3Q6IE9I Q0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAt cmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IG9oY2lfaGNkCj4gdXNiIHVzYjU6IFNlcmlhbE51bWJl cjogMDAwMDowMDoxMy4wCj4gaHViIDUtMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNS0wOjEu MDogNSBwb3J0cyBkZXRlY3RlZAo+IGZpcmV3aXJlX2NvcmU6IGNyZWF0ZWQgZGV2aWNlIGZ3MDog R1VJRCAwMDFlOGMwMDAwZGU5MTM2LCBTNDAwCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOAo+IG9oY2lfaGNk IDAwMDA6MDA6MTQuNTogUENJIElOVCBDIC0+IEdTSSAxOCAobGV2ZWwsIGxvdykgLT4gSVJRIDE4 Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNk IDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl ciA2Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZkMDAwCj4g dXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0MjQsIGlkUHJvZHVjdD0y NTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwg U2VyaWFsTnVtYmVyPTAKPiBodWIgMS0xOjEuMDogVVNCIGh1YiBmb3VuZAo+IGh1YiAxLTE6MS4w OiA0IHBvcnRzIGRldGVjdGVkCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I2OiBQcm9kdWN0 OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu Mi4wLXJjMi0xMTIwMi1nZDM1MDdhZi1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I2OiBTZXJpYWxO dW1iZXI6IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDYt MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx IDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAw MDowMDoxNi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKPiBv aGNpX2hjZCAwMDAwOjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2QgMDAw MDowMDoxNi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcK PiBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUzZmYwMDAKPiB1c2Ig dXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAx Cj4gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNl cmlhbE51bWJlcj0xCj4gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4g dXNiIHVzYjc6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRp cnR5IG9oY2lfaGNkCj4gdXNiIHVzYjc6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4wCj4gaHVi IDctMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNy0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+ IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogUENJIElOVCBBIC0+IEdTSSA1MCAobGV2ZWwsIGxvdykg LT4gSVJRIDUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgo+ IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQg YnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAsIGlvIG1lbSAweGZl NWZlMDAwCj4gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp ZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I4OiBQcm9kdWN0OiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMi4wLXJjMi0xMTIw Mi1nZDM1MDdhZi1kaXJ0eSB4aGNpX2hjZAo+IHVzYiB1c2I4OiBTZXJpYWxOdW1iZXI6IDAwMDA6 MDM6MDAuMAo+IGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDgtMDoxLjA6IDIgcG9y dHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAwMDAwOjAzOjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVy Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l ZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNiOTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9y PTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4gdXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6 IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjk6IFByb2R1Y3Q6IHhI Q0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjk6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAt cmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IHhoY2lfaGNkCj4gdXNiIHVzYjk6IFNlcmlhbE51bWJl cjogMDAwMDowMzowMC4wCj4gaHViIDktMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgOS0wOjEu MDogMiBwb3J0cyBkZXRlY3RlZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNibHAKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVh cwo+IEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLgo+IHVzYmNvcmU6IHJl Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UKPiBVU0IgTWFzcyBTdG9y YWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy aXZlciB1bXNfZW5ldWI2MjUwCj4gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5k LiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lgo+IHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYw LDB4NjQgaXJxIDEKPiBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgo+ IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlCj4gaW5wdXQ6 IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0Mgo+IHJ0 Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2UgZnJvbSBTNAo+IHJ0Y19jbW9zIDAwOjA0OiBydGMg Y29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwCj4gcnRjMDogYWxhcm1zIHVwIHRvIG9u ZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0KPiBpMmMgL2RldiBlbnRyaWVzIGRyaXZlcgo+ IHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDogU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAw LCByZXZpc2lvbiAwCj4gQVRLMDExMCBBVEswMTEwOjAwOiBFQyBlbmFibGVkCj4gU1A1MTAwIFRD TyB0aW1lcjogU1A1MTAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDEKPiBTUDUxMDAg VENPIHRpbWVyOiBtbWlvIGFkZHJlc3MgMHhiOGZlMDAgYWxyZWFkeSBpbiB1c2UKPiBJVDg3IFdE VDogQ2hpcCBJVDg3MjEgcmV2aXNpb24gMSBpbml0aWFsaXplZC4gdGltZW91dD02MCBzZWMgKG5v d2F5b3V0PTAgdGVzdG1vZGU9MCBleGNsdXNpdmU9MSBub2dhbWVwb3J0PTApCj4gd2R0OiBYZW4g V2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAxCj4gd2R0OiBjYW5ub3QgcmVnaXN0ZXIgbWlzY2Rl diBvbiBtaW5vcj0xMzAgKC0xNikKPiB3ZHQ6IHByb2JlIG9mIHdkdCBmYWlsZWQgd2l0aCBlcnJv ciAtMTYKPiBkZXZpY2UtbWFwcGVyOiB1ZXZlbnQ6IHZlcnNpb24gMS4wLjMKPiBkZXZpY2UtbWFw cGVyOiBpb2N0bDogNC4yMi4wLWlvY3RsICgyMDExLTEwLTE5KSBpbml0aWFsaXNlZDogZG0tZGV2 ZWxAcmVkaGF0LmNvbQo+IEVEQUMgTUM6IFZlcjogMi4xLjAKPiBBTUQ2NCBFREFDIGRyaXZlciB2 My40LjAKPiB1c2IgNC0yOiBuZXcgZnVsbC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5n IG9oY2lfaGNkCj4gRURBQyBhbWQ2NDogRFJBTSBFQ0MgZGlzYWJsZWQuCj4gRURBQyBhbWQ2NDog RUNDIGRpc2FibGVkIGluIHRoZSBCSU9TIG9yIG5vIEVDQyBjYXBhYmlsaXR5LCBtb2R1bGUgd2ls bCBub3QgbG9hZC4KPiAgRWl0aGVyIGVuYWJsZSBFQ0MgY2hlY2tpbmcgb3IgZm9yY2UgbW9kdWxl IGxvYWRpbmcgYnkgc2V0dGluZyAnZWNjX2VuYWJsZV9vdmVycmlkZScuCj4gIChOb3RlIHRoYXQg dXNlIG9mIHRoZSBvdmVycmlkZSBtYXkgY2F1c2UgdW5rbm93biBzaWRlIGVmZmVjdHMuKQo+IHVz YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCj4gdXNiaGlkOiBV U0IgSElEIGNvcmUgZHJpdmVyCj4gVENQIGN1YmljIHJlZ2lzdGVyZWQKPiBORVQ6IFJlZ2lzdGVy ZWQgcHJvdG9jb2wgZmFtaWx5IDE3Cj4gcnRjX2Ntb3MgMDA6MDQ6IHNldHRpbmcgc3lzdGVtIGNs b2NrIHRvIDIwMTItMDUtMDcgMTE6MDc6MTUgVVRDICgxMzM2Mzg4ODM1KQo+IHBvd2Vybm93LWs4 OiBGb3VuZCAxIEFNRCBQaGVub20odG0pIElJIFg2IDEwNzVUIFByb2Nlc3NvciAoNiBjcHUgY29y ZXMpICh2ZXJzaW9uIDIuMjAuMDApCj4gcG93ZXJub3ctazg6IENvcmUgUGVyZm9ybWFuY2UgQm9v c3Rpbmc6IG9uLgo+IHBvd2Vybm93LWs4OiBpbnZhbGlkIHBzdGF0ZSAxIC0gYmFkIHZhbHVlIDEu Cj4gcG93ZXJub3ctazg6IFBsZWFzZSByZXBvcnQgdG8gQklPUyBtYW51ZmFjdHVyZXIKPiBwb3dl cm5vdy1rODogaW52YWxpZCBwc3RhdGUgMiAtIGJhZCB2YWx1ZSAyLgo+IHBvd2Vybm93LWs4OiBQ bGVhc2UgcmVwb3J0IHRvIEJJT1MgbWFudWZhY3R1cmVyCj4gcG93ZXJub3ctazg6IGludmFsaWQg cHN0YXRlIDMgLSBiYWQgdmFsdWUgMy4KPiBwb3dlcm5vdy1rODogUGxlYXNlIHJlcG9ydCB0byBC SU9TIG1hbnVmYWN0dXJlcgo+IFtGaXJtd2FyZSBCdWddOiBwb3dlcm5vdy1rODogaW52YWxpZCBw b3dlcm5vd190YWJsZQo+IEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDU5NmsgZnJlZWQK PiBMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLgo+IHVkZXZbMTA4N106IHN0YXJ0aW5nIHZlcnNpb24g MTY0Cj4gdXNiIDQtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0MWUsIGlkUHJv ZHVjdD0zMGRjCj4gdXNiIDQtMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1 Y3Q9MiwgU2VyaWFsTnVtYmVyPTMKPiB1c2IgNC0yOiBQcm9kdWN0OiBTb3VuZCBCbGFzdGVyIFRh Y3RpYygzRCkgQWxwaGEKPiB1c2IgNC0yOiBNYW51ZmFjdHVyZXI6IENyZWF0aXZlIFRlY2hub2xv Z3kgTHRkCj4gdXNiIDQtMjogU2VyaWFsTnVtYmVyOiAwMDAyMzE2Mgo+IGlucHV0OiBDcmVhdGl2 ZSBUZWNobm9sb2d5IEx0ZCBTb3VuZCBCbGFzdGVyIFRhY3RpYygzRCkgQWxwaGEgYXMgL2Rldmlj ZXMvcGNpMDAwMDowMC8wMDAwOjAwOjEyLjAvdXNiNC80LTIvNC0yOjEuMy9pbnB1dC9pbnB1dDMK PiBnZW5lcmljLXVzYiAwMDAzOjA0MUU6MzBEQy4wMDAxOiBpbnB1dCxoaWRkZXYwOiBVU0IgSElE IHYxLjAwIERldmljZSBbQ3JlYXRpdmUgVGVjaG5vbG9neSBMdGQgU291bmQgQmxhc3RlciBUYWN0 aWMoM0QpIEFscGhhXSBvbiB1c2ItMDAwMDowMDoxMi4wLTIvaW5wdXQzCj4gQmVnaW46IExvYWRp bmcgZXNzZW50aWFsIGRyaXZlcnMgLi4uIGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv aW5pdC1wcmVtb3VudCAuLi4gZG9uZS4KPiBCZWdpbjogTW91bnRpbmcgcm9vdCBmaWxlIHN5c3Rl bSAuLi4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtdG9wIC4uLiB1c2IgMS0xLjE6IG5l dyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDQgdXNpbmcgZWhjaV9oY2QKPiBkb25lLgo+ IEJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXByZW1vdW50IC4uLiBkb25lLgo+IEVYVDQt ZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0 czogKG51bGwpCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtYm90dG9tIC4uLiBkb25l Lgo+IGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvaW5pdC1ib3R0b20gLi4uIHVzYiAx LTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDEz Cj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBT ZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVjdDogUmF6ZXIgT3JvY2hpCj4gdXNiIDEt MS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gaW5wdXQ6IFJhemVyIFJhemVyIE9yb2NoaSBhcyAv ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMS8xLTEuMToxLjAv aW5wdXQvaW5wdXQ0Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAwMjogaW5wdXQ6IFVT QiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE9yb2NoaV0gb24gdXNiLTAwMDA6MDA6MTIu Mi0xLjEvaW5wdXQwCj4gaW5wdXQ6IFJhemVyIFJhemVyIE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kw MDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMS8xLTEuMToxLjEvaW5wdXQvaW5wdXQ1 Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAwMzogaW5wdXQ6IFVTQiBISUQgdjEuMTEg S2V5Ym9hcmQgW1JhemVyIFJhemVyIE9yb2NoaV0gb24gdXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5w dXQxCj4gZG9uZS4KPiBJTklUOiB2ZXJzaW9uIDIuODggYm9vdGluZwo+IHVzYiAxLTEuMjogbmV3 IGxvdy1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciA1IHVzaW5nIGVoY2lfaGNkCj4gVXNpbmcgbWFr ZWZpbGUtc3R5bGUgY29uY3VycmVudCBib290IGluIHJ1bmxldmVsIFMuCj4gRmlsZXMgdW5kZXIg bW91bnQgcG9pbnQgJy9saWIvaW5pdC9ydycgd2lsbCBiZSBoaWRkZW4uIC4uLiAod2FybmluZyku Cj4gdXNiIDEtMS4yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDRmMiwgaWRQcm9k dWN0PTA0MDMKPiB1c2IgMS0xLjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9k dWN0PTIsIFNlcmlhbE51bWJlcj0wCj4gdXNiIDEtMS4yOiBQcm9kdWN0OiBVU0IgS2V5Ym9hcmQK PiB1c2IgMS0xLjI6IE1hbnVmYWN0dXJlcjogQ2hpY29ueQo+IEZpbGVzIHVuZGVyIG1vdW50IHBv aW50ICcvdmFyL3J1bicgd2lsbCBiZSBoaWRkZW4uIC4uLmlucHV0OiBDaGljb255IFVTQiBLZXli b2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8x LTEuMjoxLjAvaW5wdXQvaW5wdXQ2Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNDog aW5wdXQ6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1 c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDAKPiAgKHdhcm5pbmcpLgo+IGlucHV0OiBDaGljb255 IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEt MS8xLTEuMi8xLTEuMjoxLjEvaW5wdXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0 MDMuMDAwNTogaW5wdXQsaGlkZGV2MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkgVVNC IEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDEKPiBmaXJld2lyZV9uZXQ6 IGZpcmV3aXJlMDogSVB2NCBvdmVyIEZpcmVXaXJlIG9uIGRldmljZSAwMDFlOGMwMDAwZGU5MTM2 Cj4gZmlyZXdpcmVfY29yZTogcmVmcmVzaGVkIGRldmljZSBmdzAKPiBGaWxlcyB1bmRlciBtb3Vu dCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBTdGFy dGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hlcjogdWRldmR1ZGV2WzEyOTZdOiBzdGFy dGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXppbmcgdGhlIGluaXRpYWwgaG90cGx1ZyBl dmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYgdG8gYmUgZnVsbHkgcG9wdWxhdGVkLi4u ZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4nLi4uZG9uZS4KPiBTZXR0aW5nIHByZWxp bWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGluZyBzd2FwOi4KPiBFWFQ0LWZzIChkbS0w KTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2lsbCBub3cgY2hlY2sgcm9vdCBmaWxlIHN5 c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBbL3NiaW4vZnNjay5leHQ0ICgx KSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiAKPiAvZGV2 L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzU2NDcvMTMxMDcyMCBmaWxlcywgMTI3Njc3 MC81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czog ZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgZmlyZXdpcmUtc2JwMi4K PiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4uLi4K PiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdyb3Vw cyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGlsZS4u Lgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBs dm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2giIG5v dyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUgbHZtIGFuZCBtZCBzd2FwOmRvbmUuCj4g V2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4KPiBmc2NrIGZyb20gdXRpbC1saW51eC1u ZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0ZW1zLgo+IERvbmUgY2hlY2tpbmcgZmls ZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBpbiAvdmFyL2xvZy9mc2NrL2NoZWNrZnMg aWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4gV2lsbCBub3cgbW91bnQgbG9jYWwgZmls ZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6IG1vdW50aW5nIHVuY2hlY2tlZCBmcywg cnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBFWFQ0LWZzIChzZGExKTogbW91bnRlZCBm aWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQo+IC4KPiBXaWxs IG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5 IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4gLgo+IENoZWNraW5nIG1pbmltdW0gc3Bh Y2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJuZWwgdmFyaWFibGVzIC4uLiAvZXRjL3N5 c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJlciBnZW5lcmF0b3Iu Li5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29ja2V0IGRpcmVjdG9yeSAvdG1wLy5YMTEt dW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQgZGlyZWN0b3J5IC90bXAvLklDRS11bml4 Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLmRldmljZSBldGgwIGVudGVy ZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBlbmFibGluZyBp bnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTdGFy dGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVzZS4KPiBTZXR0aW5nIGNvbnNvbGUgc2Ny ZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4gU2tpcHBpbmcgZm9u dCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXApLgo+IFNldHRpbmcg dXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IFNldHRpbmcgc2Vuc29ycyBsaW1p dHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMKPiBVc2luZyBtYWtlZmlsZS1zdHlsZSBj b25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBOb3Qgc3RhcnRpbmcgZmFuY29udHJvbDsg cnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5nKS4KPiBhY3BpZDogc3RhcnRpbmcgdXAg d2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIKPiAKPiBhY3BpZDogMSBydWxlIGxvYWRl ZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcgaXMgb2ZmCj4g Cj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0gbWVzc2FnZSBi dXM6IGRidXMuCj4gU3RhcnRpbmcgdGhlIFdpbmJpbmQgZGFlbW9uOiB3aW5iaW5kLnNzaGQgKDIw NjYpOiAvcHIKPiBvYy8yMDY2L29vbV9hZGogaXMgZGVwcmVjYXRlZCwgcGxlYXNlIHVzZSAvcHJv Yy8yMDY2L29vbV9zY29yZV9hZGogaW5zdGVhZC4KPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw dSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFi bGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+ IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFibGUgdG8gcmVh ZCBjcHUgc3RhdGUKPiBTdGFydGluZyBveGVuc3RvcmVkLi4uCj4gU2V0dGluZyBkb21haW4gMCBu YW1lLi4uCj4gU3RhcnRpbmcgeGVuY29uc29sZWQuLi4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3Vy ZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgZG9tYWluIG5hbWUgc2VydmljZS4uLjog YmluZDkuCj4gU3RhcnRpbmcgU2FtYmEgZGFlbW9uczogbm1iZCBzbWJkLgo+IFN0YXJ0aW5nIHBl cmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLgo+IFN0YXJ0aW5nIFBvc3RmaXggTWFpbCBU cmFuc3BvcnQgQWdlbnQ6IHBvc3RmaXguCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5j Ojc5MjogYmxrdGFwY3RybDogdjEuMC4wCj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3Ry bC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxb MjIzMV06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyld Cj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBb dm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBCTEtUQVBDVFJMWzIyMzFdOiBibGt0YXBjdHJsLmM6 Nzk0OiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNrIGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxb MjIzMV06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyld Cj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBb cWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJMS1RBUENUUkxbMjIzMV06IGJsa3RhcGN0cmxfbGlu dXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxlZAo+IAo+IEJMS1RBUENUUkxbMjIzMV06IGJsa3Rh cGN0cmwuYzo4NjE6IGNvdWxkbid0IG9wZW4gYmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENU UkxbMjIzMV06IGJsa3RhcGN0cmwuYzo5MjQ6IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4g Cj4gU3RhcnRpbmcgUy5NLkEuUi5ULiBkYWVtb246IHNtYXJ0ZC4KPiBza3kyIDAwMDA6MDQ6MDAu MDogZXRoMDogTGluayBpcyB1cCBhdCAxMDAgTWJwcywgZnVsbCBkdXBsZXgsIGZsb3cgY29udHJv bCBib3RoCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJpbmcgZm9yd2FyZGluZyBzdGF0ZQo+IGJy MDogcG9ydCAxKGV0aDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKPiBicjA6IHBvcnQgMShl dGgwKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlCj4gUnVubmluZyBsb2NhbCBib290IHNjcmlw dHMgKC9ldGMvcmMubG9jYWwpKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMi4yCj4g YWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5w dXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5lY3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2Ug aGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDow MDoxMy4yCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox My4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gW0NQVTBdIGZhaWxlZCB0 byBzZXQgZ292ZXJub3IgbmFtZQo+IFtDUFUxXSBmYWlsZWQgdG8gc2V0IGdvdmVybm9yIG5hbWUK PiBbQ1BVMl0gZmFpbGVkIHRvIHNldCBnb3Zlcm5vciBuYW1lCj4gW0NQVTNdIGZhaWxlZCB0byBz ZXQgZ292ZXJub3IgbmFtZQo+IFtDUFU0XSBmYWlsZWQgdG8gc2V0IGdvdmVybm9yIG5hbWUKPiBb Q1BVNV0gZmFpbGVkIHRvIHNldCBnb3Zlcm5vciBuYW1lCj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZp Y2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVl biBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5l Y3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4g KFhFTikgaW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2IwIG1wb3J0PTNiMCBucj1jCj4gKFhF TikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWEwIG1mbj1hMCBucj0yMAo+IChYRU4pIGlvcG9y dF9tYXA6YWRkOiBkb20xIGdwb3J0PTNjMCBtcG9ydD0zYzAgbnI9Mwo+IChYRU4pIGlvcG9ydF9t YXA6YWRkOiBkb20xIGdwb3J0PTNjNCBtcG9ydD0zYzQgbnI9MWMKPiAoWEVOKSBIVk0xOiBIVk0g TG9hZGVyCj4gKFhFTikgSFZNMTogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKPiAoWEVOKSBI Vk0xOiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgOAo+IChYRU4pIEhW TTE6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4pIEhWTTE6IENQVSBzcGVlZCBpcyAz MDEwIE1Iego+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1 Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBpcnEu YzoyNzA6IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVOKSBIVk0xOiBQQ0kt SVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxp bmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQg dG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4g NQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikgSFZN MTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIElO VEEtPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhW TTE6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDY6MCBJ TlRCLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzowIElOVEEtPklSUTUKPiAoWEVOKSBI Vk0xOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA5OjAg SU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMTAwMDAw MDA6IGUwMDAwMDBjCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1k MDAwMCBucj0xMDAwMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAw MDAwMDogZjAwMDAwMDgKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAw MjAwMDA6IGYxMDAwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDIwIG1m bj1mZTllMCBucj0yMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTggc2l6ZSAwMDAy MDAwMDogZjEwMjAwMDQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAw MjAwMDA6IGYxMDQwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIDAw MDA0MDAwOiBmMTA2MDAwNAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2MCBt Zm49ZmU5YmMgbnI9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAwMDAw NDAwMDogZjEwNjQwMDQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZu PWZlM2Y4IG5yPTQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgYmFyIDEwIHNpemUgMDAwMDEw MDA6IGYxMDY4MDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY4IG1mbj1m ZTNmNyBucj0xCj4gKFhFTikgSFZNMTogcGNpIGRldiAwODowIGJhciAxMCBzaXplIDAwMDAxMDAw OiBmMTA2OTAwMAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAw MDAgbnI9MQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDog MDAwMGMwMDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6 IDAwMDBjMTAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQw OiAwMDAwYzIwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAx MDogMDAwMGMyNDEKPiAoWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoK PiAoWEVOKSBIVk0xOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u IHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUxIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0xOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUzIC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0xOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0xOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBh Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiAgLSBHUyBiYXNl IE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogUGFzc2VkIDIgb2YgMiB0 ZXN0cwo+IChYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBIVk0x OiBMb2FkaW5nIFJPTUJJT1MgLi4uCj4gKFhFTikgSFZNMTogOTY2MCBieXRlcyBvZiBST01CSU9T IGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6Cj4gKFhFTikgSFZNMTogICBSZWxvY2F0aW5nIHRvIDB4 ZmMwMDEwMDAtMHhmYzAwMzViYyAuLi4gZG9uZQo+IChYRU4pIEhWTTE6IENyZWF0aW5nIE1QIHRh YmxlcyAuLi4KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIFZHQUJJT1Mgb2YgcGFzc3Rocm91Z2hlZCBn ZnggLi4uCj4gKFhFTikgSFZNMTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4KPiAoWEVOKSBI Vk0xOiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6Ly9pcHhlLm9yZwo+IChYRU4pIEhWTTE6ICAtIFBy b2R1Y3QgbmFtZTogaVBYRQo+IChYRU4pIEhWTTE6IE9wdGlvbiBST01zOgo+IChYRU4pIEhWTTE6 ICBjMDAwMC1jZmZmZjogVkdBIEJJT1MKPiAoWEVOKSBIVk0xOiAgZDAwMDAtZTBmZmY6IEV0aGVy Ym9vdCBST00KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIEFDUEkgLi4uCj4gKFhFTikgSFZNMTogdm04 NiBUU1MgYXQgZmMwMGY3MDAKPiAoWEVOKSBIVk0xOiBCSU9TIG1hcDoKPiAoWEVOKSBIVk0xOiAg ZjAwMDAtZmZmZmY6IE1haW4gQklPUwo+IChYRU4pIEhWTTE6IEU4MjAgdGFibGU6Cj4gKFhFTikg SFZNMTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQo+ IChYRU4pIEhWTTE6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAwMGEwMDAw OiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAw MDAwOjAwMGUwMDAwCj4gKFhFTikgSFZNMTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAw MDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZNMTogIFswM106IDAwMDAwMDAwOjAw MTAwMDAwIC0gMDAwMDAwMDA6ZTAwMDAwMDA6IFJBTQo+IChYRU4pIEhWTTE6ICBIT0xFOiAwMDAw MDAwMDplMDAwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCj4gKFhFTikgSFZNMTogIFswNF06IDAw MDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZN MTogIFswNV06IDAwMDAwMDAxOjAwMDAwMDAwIC0gMDAwMDAwMDE6MjAwMDAwMDA6IFJBTQo+IChY RU4pIEhWTTE6IEludm9raW5nIFJPTUJJT1MgLi4uCj4gKFhFTikgSFZNMTogJFJldmlzaW9uOiAx LjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKPiAoWEVOKSBIVk0xOiBCb2NocyBC SU9TIC0gYnVpbGQ6IDA2LzIzLzk5Cj4gKFhFTikgSFZNMTogJFJldmlzaW9uOiAxLjIyMSAkICRE YXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKPiAoWEVOKSBIVk0xOiBPcHRpb25zOiBhcG1iaW9z IHBjaWJpb3MgZWx0b3JpdG8gUE1NIAo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IGF0YTAt MDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mwo+IChY RU4pIEhWTTE6IGF0YTAgbWFzdGVyOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMjA0 ODAgTUJ5dGVzKQo+IChYRU4pIEhWTTE6IGF0YTAtMTogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mwo+IChYRU4pIEhWTTE6IGF0YTAgIHNsYXZlOiBRRU1V IEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoNTEyMDAgTUJ5dGVzKQo+IChYRU4pIEhWTTE6IAo+ IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IFByZXNzIEYxMiBmb3Ig Ym9vdCBtZW51Lgo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSBIYXJk IERpc2suLi4KPiAoWEVOKSBIVk0xOiBCb290aW5nIGZyb20gMDAwMDo3YzAwCj4gKFhFTikgaXJx LmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6 IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEg UENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxp bmsgMyBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1l MDAwMCBtZm49ZDAwMDAgbnI9MTAwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBn Zm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2Zu PWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdm bj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBn Zm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49 ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49 ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEw NjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEw NjkgbWZuPWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjkg bWZuPWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjQg bWZuPWZlM2Y4IG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZu PWZlM2Y4IG5yPTQKPiAoWEVOKSBncmFudF90YWJsZS5jOjExNzQ6ZDEgRXhwYW5kaW5nIGRvbSAo MSkgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8gKDMyKSBmcmFtZXMuCj4gKFhFTikgaXJxLmM6MzUw OiBEb20xIGNhbGxiYWNrIHZpYSBjaGFuZ2VkIHRvIEdTSSAyOAo+IChYRU4pIG1lbW9yeV9tYXA6 cmVtb3ZlOiBkb20xIGdmbj1lMDAwMCBtZm49ZDAwMDAgbnI9MTAwMDAKPiAoWEVOKSBtZW1vcnlf bWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgbWVtb3J5 X21hcDphZGQ6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9y eV9tYXA6YWRkOiBkb20xIGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlf bWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlf bWFwOmFkZDogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFw OnJlbW92ZTogZG9tMSBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFw OmFkZDogZG9tMSBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMSwgZmF1bHQgYWRkcmVzcyA9 IDB4OWRiNDQwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjkgbWZu PWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjkgbWZuPWYw MDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjQgbWZuPWZl M2Y4IG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZuPWZlM2Y4 IG5yPTQKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVzcyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVz cyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVzcyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk0MzI0ZTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI0YjAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MDhhODAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwg ZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIw NDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9 IDB4OWQ3YWIwYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxMDAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQg YWRkcmVzcyA9IDB4OWQ3YWIxNDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxODAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcw MCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3 YWIyMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIyNDAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVz cyA9IDB4OWQ3YWIyODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIyYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1 bHQgYWRkcmVzcyA9IDB4OWQ3YWIzMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzNDAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzNDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4 OWQ3YWIzODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzODAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk cmVzcyA9IDB4OWQ3YWIzYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0 NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0 MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MGVhODAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2ZjZhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2 MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk1MGVhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MDJhODAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1 MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk0MDJhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MTRh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk2ZmNhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0 MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2ZmNhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZGZlODAwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwNDAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKCj4gZGlmZiAtLWdp dCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmggYi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9wYXJhdmlydC5oCj4gaW5kZXggYWEwZjkxMy4uMjU5ZWY3ZiAxMDA2NDQKPiAtLS0gYS9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oCj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v cGFyYXZpcnQuaAo+IEBAIC0zNDAsMTEgKzM0MCwxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgd3Jp dGVfaWR0X2VudHJ5KGdhdGVfZGVzYyAqZHQsIGludCBlbnRyeSwgY29uc3QgZ2F0ZV9kZXNjICpn KQo+ICB7Cj4gIAlQVk9QX1ZDQUxMMyhwdl9jcHVfb3BzLndyaXRlX2lkdF9lbnRyeSwgZHQsIGVu dHJ5LCBnKTsKPiAgfQo+ICsKPiAgc3RhdGljIGlubGluZSB2b2lkIHNldF9pb3BsX21hc2sodW5z aWduZWQgbWFzaykKPiAgewo+ICAJUFZPUF9WQ0FMTDEocHZfY3B1X29wcy5zZXRfaW9wbF9tYXNr LCBtYXNrKTsKPiAgfQo+ICAKPiArc3RhdGljIGlubGluZSB2b2lkIHNldF9pb19iaXRtYXAoc3Ry dWN0IHRocmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnNpZ25lZCBsb25nIGJ5dGVzX3VwZGF0ZWQpCj4gK3sKPiArICAgICAgIFBWT1BfVkNB TEwyKHB2X2NwdV9vcHMuc2V0X2lvX2JpdG1hcCwgdGhyZWFkLCBieXRlc191cGRhdGVkKTsKPiAr fQo+ICsKPiAgLyogVGhlIHBhcmF2aXJ0dWFsaXplZCBJL08gZnVuY3Rpb25zICovCj4gIHN0YXRp YyBpbmxpbmUgdm9pZCBzbG93X2Rvd25faW8odm9pZCkKPiAgewo+IGRpZmYgLS1naXQgYS9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90eXBlcy5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v cGFyYXZpcnRfdHlwZXMuaAo+IGluZGV4IDhlOGI5YTQuLjk2ZjI2N2MgMTAwNjQ0Cj4gLS0tIGEv YXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaAo+ICsrKyBiL2FyY2gveDg2L2lu Y2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmgKPiBAQCAtMTQyLDYgKzE0Miw4IEBAIHN0cnVjdCBw dl9jcHVfb3BzIHsKPiAgCXZvaWQgKCpsb2FkX3NwMCkoc3RydWN0IHRzc19zdHJ1Y3QgKnRzcywg c3RydWN0IHRocmVhZF9zdHJ1Y3QgKnQpOwo+ICAKPiAgCXZvaWQgKCpzZXRfaW9wbF9tYXNrKSh1 bnNpZ25lZCBtYXNrKTsKPiArICAgICAgICB2b2lkICgqc2V0X2lvX2JpdG1hcCkoc3RydWN0IHRo cmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5z aWduZWQgbG9uZyBieXRlc191cGRhdGVkKTsKPiAgCj4gIAl2b2lkICgqd2JpbnZkKSh2b2lkKTsK PiAgCXZvaWQgKCppb19kZWxheSkodm9pZCk7Cj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1 ZGUvYXNtL3Byb2Nlc3Nvci5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmgKPiBp bmRleCA0ZmE3ZGNjLi42MmJlY2NlIDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNt L3Byb2Nlc3Nvci5oCj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmgKPiBA QCAtNTAzLDYgKzUwMyw5IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBuYXRpdmVfc2V0X2lvcGxfbWFz ayh1bnNpZ25lZCBtYXNrKQo+ICAjZW5kaWYKPiAgfQo+ICAKPiArZXh0ZXJuIHZvaWQgbmF0aXZl X3NldF9pb19iaXRtYXAoc3RydWN0IHRocmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHVwZGF0ZWRfYnl0ZXMpOwo+ICsK PiAgc3RhdGljIGlubGluZSB2b2lkCj4gIG5hdGl2ZV9sb2FkX3NwMChzdHJ1Y3QgdHNzX3N0cnVj dCAqdHNzLCBzdHJ1Y3QgdGhyZWFkX3N0cnVjdCAqdGhyZWFkKQo+ICB7Cj4gQEAgLTUzNiw2ICs1 MzksNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgbG9hZF9zcDAoc3RydWN0IHRzc19zdHJ1Y3QgKnRz cywKPiAgfQo+ICAKPiAgI2RlZmluZSBzZXRfaW9wbF9tYXNrIG5hdGl2ZV9zZXRfaW9wbF9tYXNr Cj4gKyNkZWZpbmUgc2V0X2lvX2JpdG1hcCBuYXRpdmVfc2V0X2lvX2JpdG1hcAo+ICAjZW5kaWYg LyogQ09ORklHX1BBUkFWSVJUICovCj4gIAo+ICAvKgo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9r ZXJuZWwvaW9wb3J0LmMgYi9hcmNoL3g4Ni9rZXJuZWwvaW9wb3J0LmMKPiBpbmRleCA4Yzk2ODk3 Li5jMzcyZWYwIDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9pb3BvcnQuYwo+ICsrKyBi L2FyY2gveDg2L2tlcm5lbC9pb3BvcnQuYwo+IEBAIC0xNywxMyArMTcsMjkgQEAKPiAgI2luY2x1 ZGUgPGxpbnV4L2JpdG1hcC5oPgo+ICAjaW5jbHVkZSA8YXNtL3N5c2NhbGxzLmg+Cj4gIAo+ICt2 b2lkIG5hdGl2ZV9zZXRfaW9fYml0bWFwKHN0cnVjdCB0aHJlYWRfc3RydWN0ICp0LAo+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBieXRlc191cGRhdGVkKQo+ICt7Cj4g KyAgICAgICBzdHJ1Y3QgdHNzX3N0cnVjdCAqdHNzOwo+ICsKPiArICAgICAgIGlmICghYnl0ZXNf dXBkYXRlZCkKPiArICAgICAgICAgICAgICAgcmV0dXJuOwo+ICsKPiArICAgICAgIHRzcyA9ICZf X2dldF9jcHVfdmFyKGluaXRfdHNzKTsKPiArCj4gKyAgICAgICAvKiBVcGRhdGUgdGhlIFRTUzog Ki8KPiArICAgICAgIGlmICh0LT5pb19iaXRtYXBfcHRyKQo+ICsgICAgICAgICAgICAgICBtZW1j cHkodHNzLT5pb19iaXRtYXAsIHQtPmlvX2JpdG1hcF9wdHIsIGJ5dGVzX3VwZGF0ZWQpOwo+ICsg ICAgICAgZWxzZQo+ICsgICAgICAgICAgICAgICBtZW1zZXQodHNzLT5pb19iaXRtYXAsIDB4ZmYs IGJ5dGVzX3VwZGF0ZWQpOwo+ICt9Cj4gKwo+ICAvKgo+ICAgKiB0aGlzIGNoYW5nZXMgdGhlIGlv IHBlcm1pc3Npb25zIGJpdG1hcCBpbiB0aGUgY3VycmVudCB0YXNrLgo+ICAgKi8KPiAgYXNtbGlu a2FnZSBsb25nIHN5c19pb3Blcm0odW5zaWduZWQgbG9uZyBmcm9tLCB1bnNpZ25lZCBsb25nIG51 bSwgaW50IHR1cm5fb24pCj4gIHsKPiAgCXN0cnVjdCB0aHJlYWRfc3RydWN0ICp0ID0gJmN1cnJl bnQtPnRocmVhZDsKPiAtCXN0cnVjdCB0c3Nfc3RydWN0ICp0c3M7Cj4gIAl1bnNpZ25lZCBpbnQg aSwgbWF4X2xvbmcsIGJ5dGVzLCBieXRlc191cGRhdGVkOwo+ICAKPiAgCWlmICgoZnJvbSArIG51 bSA8PSBmcm9tKSB8fCAoZnJvbSArIG51bSA+IElPX0JJVE1BUF9CSVRTKSkKPiBAQCAtNDgsMTMg KzY0LDEzIEBAIGFzbWxpbmthZ2UgbG9uZyBzeXNfaW9wZXJtKHVuc2lnbmVkIGxvbmcgZnJvbSwg dW5zaWduZWQgbG9uZyBudW0sIGludCB0dXJuX29uKQo+ICAJfQo+ICAKPiAgCS8qCj4gLQkgKiBk byBpdCBpbiB0aGUgcGVyLXRocmVhZCBjb3B5IGFuZCBpbiB0aGUgVFNTIC4uLgo+ICsJICogZG8g aXQgaW4gdGhlIHBlci10aHJlYWQgY29weQo+ICAJICoKPiAtCSAqIERpc2FibGUgcHJlZW1wdGlv biB2aWEgZ2V0X2NwdSgpIC0gd2UgbXVzdCBub3Qgc3dpdGNoIGF3YXkKPiArCSAqIERpc2FibGUg cHJlZW1wdGlvbiAtIHdlIG11c3Qgbm90IHN3aXRjaCBhd2F5Cj4gIAkgKiBiZWNhdXNlIHRoZSAt PmlvX2JpdG1hcF9tYXggdmFsdWUgbXVzdCBtYXRjaCB0aGUgYml0bWFwCj4gIAkgKiBjb250ZW50 czoKPiAgCSAqLwo+IC0JdHNzID0gJnBlcl9jcHUoaW5pdF90c3MsIGdldF9jcHUoKSk7Cj4gKyAg ICAgICAgcHJlZW1wdF9kaXNhYmxlKCk7Cj4gIAo+ICAJaWYgKHR1cm5fb24pCj4gIAkJYml0bWFw X2NsZWFyKHQtPmlvX2JpdG1hcF9wdHIsIGZyb20sIG51bSk7Cj4gQEAgLTc1LDEwICs5MSw5IEBA IGFzbWxpbmthZ2UgbG9uZyBzeXNfaW9wZXJtKHVuc2lnbmVkIGxvbmcgZnJvbSwgdW5zaWduZWQg bG9uZyBudW0sIGludCB0dXJuX29uKQo+ICAKPiAgCXQtPmlvX2JpdG1hcF9tYXggPSBieXRlczsK PiAgCj4gLQkvKiBVcGRhdGUgdGhlIFRTUzogKi8KPiAtCW1lbWNweSh0c3MtPmlvX2JpdG1hcCwg dC0+aW9fYml0bWFwX3B0ciwgYnl0ZXNfdXBkYXRlZCk7Cj4gKyAgICAgICAgc2V0X2lvX2JpdG1h cCh0LCBieXRlc191cGRhdGVkKTsKPiAgCj4gLQlwdXRfY3B1KCk7Cj4gKyAgICAgICAgcHJlZW1w dF9lbmFibGUoKTsKPiAgCj4gIAlyZXR1cm4gMDsKPiAgfQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4 Ni9rZXJuZWwvcGFyYXZpcnQuYyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCj4gaW5kZXgg YWIxMzc2MC4uYWE0MjBlNyAxMDA2NDQKPiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZpcnQu Ywo+ICsrKyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCj4gQEAgLTM5MSw2ICszOTEsNyBA QCBzdHJ1Y3QgcHZfY3B1X29wcyBwdl9jcHVfb3BzID0gewo+ICAJLnN3YXBncyA9IG5hdGl2ZV9z d2FwZ3MsCj4gIAo+ICAJLnNldF9pb3BsX21hc2sgPSBuYXRpdmVfc2V0X2lvcGxfbWFzaywKPiAr ICAgICAgICAuc2V0X2lvX2JpdG1hcCA9IG5hdGl2ZV9zZXRfaW9fYml0bWFwLAo+ICAJLmlvX2Rl bGF5ID0gbmF0aXZlX2lvX2RlbGF5LAo+ICAKPiAgCS5zdGFydF9jb250ZXh0X3N3aXRjaCA9IHBh cmF2aXJ0X25vcCwKPiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYva2VybmVsL3Byb2Nlc3MuYyBiL2Fy Y2gveDg2L2tlcm5lbC9wcm9jZXNzLmMKPiBpbmRleCAxZDkyYTVhLi5lODQzNmNjIDEwMDY0NAo+ IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9wcm9jZXNzLmMKPiArKysgYi9hcmNoL3g4Ni9rZXJuZWwv cHJvY2Vzcy5jCj4gQEAgLTkxLDE2ICs5MSwxMiBAQCB2b2lkIGV4aXRfdGhyZWFkKHZvaWQpCj4g IAl1bnNpZ25lZCBsb25nICpicCA9IHQtPmlvX2JpdG1hcF9wdHI7Cj4gIAo+ICAJaWYgKGJwKSB7 Cj4gLQkJc3RydWN0IHRzc19zdHJ1Y3QgKnRzcyA9ICZwZXJfY3B1KGluaXRfdHNzLCBnZXRfY3B1 KCkpOwo+IC0KPiArICAgICAgICAgICAgICAgIHByZWVtcHRfZGlzYWJsZSgpOwo+ICAJCXQtPmlv X2JpdG1hcF9wdHIgPSBOVUxMOwo+ICAJCWNsZWFyX3RocmVhZF9mbGFnKFRJRl9JT19CSVRNQVAp Owo+IC0JCS8qCj4gLQkJICogQ2FyZWZ1bCwgY2xlYXIgdGhpcyBpbiB0aGUgVFNTIHRvbzoKPiAt CQkgKi8KPiAtCQltZW1zZXQodHNzLT5pb19iaXRtYXAsIDB4ZmYsIHQtPmlvX2JpdG1hcF9tYXgp Owo+ICsgICAgICAgICAgICAgICAgc2V0X2lvX2JpdG1hcCh0LCB0LT5pb19iaXRtYXBfbWF4KTsK PiAgCQl0LT5pb19iaXRtYXBfbWF4ID0gMDsKPiAtCQlwdXRfY3B1KCk7Cj4gKyAgICAgICAgICAg ICAgICBwcmVlbXB0X2VuYWJsZSgpOwo+ICAJCWtmcmVlKGJwKTsKPiAgCX0KPiAgfQo+IEBAIC0y MzcsMTkgKzIzMywxMSBAQCB2b2lkIF9fc3dpdGNoX3RvX3h0cmEoc3RydWN0IHRhc2tfc3RydWN0 ICpwcmV2X3AsIHN0cnVjdCB0YXNrX3N0cnVjdCAqbmV4dF9wLAo+ICAJCQloYXJkX2VuYWJsZV9U U0MoKTsKPiAgCX0KPiAgCj4gLQlpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcobmV4dF9wLCBUSUZf SU9fQklUTUFQKSkgewo+IC0JCS8qCj4gLQkJICogQ29weSB0aGUgcmVsZXZhbnQgcmFuZ2Ugb2Yg dGhlIElPIGJpdG1hcC4KPiAtCQkgKiBOb3JtYWxseSB0aGlzIGlzIDEyOCBieXRlcyBvciBsZXNz Ogo+IC0JCSAqLwo+IC0JCW1lbWNweSh0c3MtPmlvX2JpdG1hcCwgbmV4dC0+aW9fYml0bWFwX3B0 ciwKPiAtCQkgICAgICAgbWF4KHByZXYtPmlvX2JpdG1hcF9tYXgsIG5leHQtPmlvX2JpdG1hcF9t YXgpKTsKPiAtCX0gZWxzZSBpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcocHJldl9wLCBUSUZfSU9f QklUTUFQKSkgewo+IC0JCS8qCj4gLQkJICogQ2xlYXIgYW55IHBvc3NpYmxlIGxlZnRvdmVyIGJp dHM6Cj4gLQkJICovCj4gLQkJbWVtc2V0KHRzcy0+aW9fYml0bWFwLCAweGZmLCBwcmV2LT5pb19i aXRtYXBfbWF4KTsKPiAtCX0KPiArICAgICAgICBpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcobmV4 dF9wLCBUSUZfSU9fQklUTUFQKSB8fAo+ICsgICAgICAgICAgICB0ZXN0X3Rza190aHJlYWRfZmxh ZyhwcmV2X3AsIFRJRl9JT19CSVRNQVApKQo+ICsgICAgICAgICAgICAgICAgc2V0X2lvX2JpdG1h cChuZXh0LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXgocHJldi0+aW9fYml0 bWFwX21heCwgbmV4dC0+aW9fYml0bWFwX21heCkpOwo+ICsKPiAgCXByb3BhZ2F0ZV91c2VyX3Jl dHVybl9ub3RpZnkocHJldl9wLCBuZXh0X3ApOwo+ICB9Cj4gIAo+IGRpZmYgLS1naXQgYS9hcmNo L3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKPiBpbmRleCA4 ODUzMjA0Li43YTA1NTA5IDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwo+ ICsrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwo+IEBAIC04MDgsNiArODA4LDE4IEBAIHN0 YXRpYyB2b2lkIHhlbl9zZXRfaW9wbF9tYXNrKHVuc2lnbmVkIG1hc2spCj4gIAlIWVBFUlZJU09S X3BoeXNkZXZfb3AoUEhZU0RFVk9QX3NldF9pb3BsLCAmc2V0X2lvcGwpOwo+ICB9Cj4gIAo+ICtz dGF0aWMgdm9pZCB4ZW5fc2V0X2lvX2JpdG1hcChzdHJ1Y3QgdGhyZWFkX3N0cnVjdCAqdGhyZWFk LAo+ICsJaW50IGNoYW5nZWQsIHVuc2lnbmVkIGxvbmcgYnl0ZXNfdXBkYXRlZCkKPiArewo+ICsJ c3RydWN0IHBoeXNkZXZfc2V0X2lvYml0bWFwIHNldF9pb2JpdG1hcDsKPiArCj4gKwlzZXRfeGVu X2d1ZXN0X2hhbmRsZShzZXRfaW9iaXRtYXAuYml0bWFwLAo+ICsJCShjaGFyICopdGhyZWFkLT5p b19iaXRtYXBfcHRyKTsKPiArCXNldF9pb2JpdG1hcC5ucl9wb3J0cyA9IHRocmVhZC0+aW9fYml0 bWFwX3B0ciA/IElPX0JJVE1BUF9CSVRTIDogMDsKPiArCVdBUk5fT04oSFlQRVJWSVNPUl9waHlz ZGV2X29wKFBIWVNERVZPUF9zZXRfaW9iaXRtYXAsCj4gKwkJJnNldF9pb2JpdG1hcCkpOwo+ICt9 Cj4gKwo+ICBzdGF0aWMgdm9pZCB4ZW5faW9fZGVsYXkodm9pZCkKPiAgewo+ICB9Cj4gQEAgLTEx MTcsNiArMTEyOSw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgcHZfY3B1X29wcyB4ZW5fY3B1X29w cyBfX2luaXRjb25zdCA9IHsKPiAgCS5sb2FkX3NwMCA9IHhlbl9sb2FkX3NwMCwKPiAgCj4gIAku c2V0X2lvcGxfbWFzayA9IHhlbl9zZXRfaW9wbF9tYXNrLAo+ICsJLnNldF9pb19iaXRtYXAgPSB4 ZW5fc2V0X2lvX2JpdG1hcCwKPiAgCS5pb19kZWxheSA9IHhlbl9pb19kZWxheSwKPiAgCj4gIAkv KiBYZW4gdGFrZXMgY2FyZSBvZiAlZ3Mgd2hlbiBzd2l0Y2hpbmcgdG8gdXNlcm1vZGUgZm9yIHVz ICovCgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX18gICAgICAgICAgICAgICAgICAg ICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19f IFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKPiAgIFwgIC8vIF8g XCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdfIFx8 IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IC8gX18vfF9ffCB8X3wgfCB8IHwg XF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xfXF9fX3xffCB8X3wgICAgfF98KF8p X19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEAobm9uZSkp IChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgpICkgU2F0IE1heSAgNSAxNTo0ODo0 OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBGcmkgTWF5IDA0IDExOjE4OjQ4 IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhFTikgQ29uc29sZSBvdXRwdXQgaXMg c3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3Nx dWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBkb20w X21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUgY29t MT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1hdGlv bjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikgIFZC RS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhFTikg RGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChYRU4p ICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAgUkFN IG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVzYWJs ZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVk KQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQp Cj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUpCj4g KFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4g KFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAo WEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+IChY RU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gKFhF TikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhFTikg QUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhTRFQg Q0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3 KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0MCAy MDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2RTMg KHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFDUEk6 IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4IChy MSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBN Q0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAgICAg ICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VNQjE3 NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMwLCAw MDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1E ICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0gSSAg UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4MTkw TUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAoWEVO KSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+IChY RU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0 IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIg ZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikgQUNQ STogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+IChY RU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19zaXpl WzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAoWEVO KSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAj MSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNd IGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2 ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw M10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAo WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQo+ IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vz c29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElDIChp ZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJQ1sw XTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCj4g KFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNl WzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw eGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChi dXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJUlEw IHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgo+ IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBBUElD IG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAw eDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCEKPiAoWEVO KSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KPiAo WEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVnIENQVXMpCj4gKFhFTikgSVJRIGxp bWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjIzOCBNSHog cHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZh bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgUENJOiBNQ0ZHIGNv bmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZgo+ IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYKPiAo WEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVOKSBBTUQtVmk6IEVuYWJsaW5nIGds b2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAoWEVO KSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKPiAo WEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhG MCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGltZXIg aXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtp Qi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2 YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4gKFhF TikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikgIC0g TmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBGaWx0 ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3Rl ZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0Is IDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w eDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4 MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx MDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEw MDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIG1pY3JvY29kZTogY29sbGVj dF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgSFBFVCdzIE1TSSBtb2RlIGhh c24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxlZC4K PiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4pIE1DQTogVXNlIGh3IHRocmVzaG9s ZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAoWEVOKSBtY2hlY2tfcG9sbDogTWFj aGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4gKFhFTikgWGVub3Byb2ZpbGU6IEZh aWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZgo+IChYRU4p ICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6 IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDVkMzAwMAo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6 IHBoZHI6IHBhZGRyPTB4MTVkMzAwMCBtZW1zej0weDZlMGU4Cj4gKFhFTikgZWxmX3BhcnNlX2Jp bmFyeTogcGhkcjogcGFkZHI9MHgxNjQyMDAwIG1lbXN6PTB4MTI5ODAKPiAoWEVOKSBlbGZfcGFy c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2NTUwMDAgbWVtc3o9MHg0ZmYwMDAKPiAoWEVOKSBl bGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDFiNTQwMDAKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igo+IChYRU4pIGVsZl94ZW5fcGFy c2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl OiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS VF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBF TlRSWSA9IDB4ZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFlQ RVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25v dGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdi Igo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIgo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMiCj4gKFhFTikgZWxmX3hlbl9wYXJz ZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhW X1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90 ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFk ZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAw MAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCj4gKFhFTikgICAgIHZpcnRfb2Zm c2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9rc3RhcnQgICAg ICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhm ZmZmZmZmZjgxYjU0MDAwCj4gKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZm ODE2NTUyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZm Zgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCj4gKFhFTikgIERv bTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxYjU0MDAw Cj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBEb20wIGFsbG9j LjogICAwMDAwMDAwMjI0MDAwMDAwLT4wMDAwMDAwMjI4MDAwMDAwICg1MDYzMDggcGFnZXMgdG8g YmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjJmOWM0MDAwLT4w MDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4gKFhF TikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODFiNTQwMDAKPiAo WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWI1NDAwMC0+ZmZmZmZmZmY4MjE4ZjIwMAo+ IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyMTkwMDAwLT5mZmZmZmZmZjgyNTkwMDAw Cj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODI1OTAwMDAtPmZmZmZmZmZmODI1OTA0 YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjU5MTAwMC0+ZmZmZmZmZmY4MjVh ODAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyNWE4MDAwLT5mZmZmZmZmZjgy NWE5MDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZm ODI4MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4p IERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAw IGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODE1ZDMwMDAKPiAoWEVOKSBlbGZf bG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1ZDMwMDAgLT4gMHhmZmZmZmZmZjgx NjQxMGU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxNjQy MDAwIC0+IDB4ZmZmZmZmZmY4MTY1NDk4MAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAz IGF0IDB4ZmZmZmZmZmY4MTY1NTAwMCAtPiAweGZmZmZmZmZmODE2Y2MwMDAKPiAoWEVOKSBTY3J1 YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2aXJx IHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs bAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVOKSAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05T T0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoqKioqKiogVGhpcyBvcHRpb24gaXMg aW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkgZW5zdXJpbmcKPiAoWEVOKSAqKioq KioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5IGRlbGl2ZXJlZCBvbiB0aGUgc2Vy aWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklG SUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAqKioqKioqIHRpbWVrZWVwaW5nLiBJ dCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQo+IChYRU4pICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPiAoWEVOKSAzLi4uIDIuLi4g MS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhy ZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAoWEVOKSBGcmVlZCAyNTZrQiBpbml0 IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQo+IFhlbjogc2V0 dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgo+IEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw dQo+IExpbnV4IHZlcnNpb24gMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IChyb290QHhl bikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjNSBTTVAgUFJFRU1QVCBT YXQgTWF5IDUgMTk6Mjk6NDIgQ0VTVCAyMDEyCj4gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBy b290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBjaWJh Y2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IEZyZWVpbmcg OWEtMTAwIHBmbiByYW5nZTogMTAyIHBhZ2VzIGZyZWVkCj4gUmVsZWFzZWQgMTAyIHBhZ2VzIG9m IHVudXNlZCBtZW1vcnkKPiBTZXQgMTk3MDk0IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcKPiBQb3B1 bGF0aW5nIDgwMDAwLTgwMDY2IHBmbiByYW5nZTogMTAyIHBhZ2VzIGFkZGVkCj4gQklPUy1wcm92 aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAw MDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAx MDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDY2 MDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDA4MDA2NjAwMCAtIDAwMDAwMDAwY2ZlODAwMDAg KHVudXNhYmxlKQo+ICBYZW46IDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChB Q1BJIGRhdGEpCj4gIFhlbjogMDAwMDAwMDBjZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFD UEkgTlZTKQo+ICBYZW46IDAwMDAwMDAwY2ZlYzAwMDAgLSAwMDAwMDAwMGNmZjAwMDAwIChyZXNl cnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMCAocmVzZXJ2 ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVk KQo+ICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK PiAgWGVuOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4g IFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IGJv b3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChFeGVjdXRlIERpc2FibGUpIHByb3Rl Y3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICB1c2VyOiAw MDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAodXNhYmxlKQo+ICB1c2VyOiAwMDAw MDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAw MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCj4gIHVzZXI6IDAwMDAwMDAw ODAwNjYwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1bnVzYWJsZSkKPiAgdXNlcjogMDAwMDAwMDBj ZmU4MDAwMCAtIDAwMDAwMDAwY2ZlOTgwMDAgKEFDUEkgZGF0YSkKPiAgdXNlcjogMDAwMDAwMDBj ZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZTKQo+ICB1c2VyOiAwMDAwMDAwMGNm ZWMwMDAwIC0gMDAwMDAwMDBjZmYwMDAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwZmVj MDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAwMDAwMDBmZWMy MDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAwMDAwMDAwMGZlZTAw MDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwZmZlMDAw MDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAwMDAwMDEwMDAwMDAw MCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IERNSSBwcmVzZW50Lgo+IE5vIEFHUCBi cmlkZ2UgZm91bmQKPiBsYXN0X3BmbiA9IDB4ODAwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAw MDAKPiBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAwZmY3ODBdIGZmNzgwCj4gaW5p dF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gUkFN RElTSzogMDFiNTQwMDAgLSAwMjE5MDAwMAo+IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYmYyMCAw MDAyNCAodjAyIEFDUElBTSkKPiBBQ1BJOiBYU0RUIDAwMDAwMDAwY2ZlODAxMDAgMDAwNUMgKHYw MSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBGQUNQIDAw MDAwMDAwY2ZlODAyOTAgMDAwRjQgKHYwMyAxMDI4MTEgRkFDUDE3NDAgMjAxMTEwMjggTVNGVCAw MDAwMDA5NykKPiBBQ1BJOiBEU0RUIDAwMDAwMDAwY2ZlODA0NzAgMEU2RTMgKHYwMSAgQTE1OTUg QTE1OTUwMDAgMDAwMDAwMDAgSU5UTCAyMDA2MDExMykKPiBBQ1BJOiBGQUNTIDAwMDAwMDAwY2Zl OTgwMDAgMDAwNDAKPiBBQ1BJOiBBUElDIDAwMDAwMDAwY2ZlODAzOTAgMDAwOTggKHYwMSAxMDI4 MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBNQ0ZHIDAwMDAwMDAw Y2ZlODA0MzAgMDAwM0MgKHYwMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAwMDAwMDA5 NykKPiBBQ1BJOiBPRU1CIDAwMDAwMDAwY2ZlOTgwNDAgMDAwNzIgKHYwMSAxMDI4MTEgT0VNQjE3 NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBIUEVUIDAwMDAwMDAwY2ZlOGY4YzAg MDAwMzggKHYwMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJ OiBJVlJTIDAwMDAwMDAwY2ZlOGY5MDAgMDAwRTAgKHYwMSAgQU1EICAgICBSRDg5MFMgMDAyMDIw MzEgQU1EICAwMDAwMDAwMCkKPiBBQ1BJOiBTU0RUIDAwMDAwMDAwY2ZlOGY5ZTAgMDBFMTAgKHYw MSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkKPiBObyBOVU1BIGNvbmZp Z3VyYXRpb24gZm91bmQKPiBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAw MDA4MDAwMDAwMAo+IEluaXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAw MDA4MDAwMDAwMAo+ICAgTk9ERV9EQVRBIFswMDAwMDAwMDdmZmZjMDAwIC0gMDAwMDAwMDA3ZmZm ZmZmZl0KPiBab25lIFBGTiByYW5nZXM6Cj4gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAw MDEwMDAKPiAgIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMAo+ICAgTm9ybWFsICAg ZW1wdHkKPiBNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBlYWNoIG5vZGUKPiBFYXJseSBtZW1v cnkgUEZOIHJhbmdlcwo+ICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOWEKPiAgICAgMDog MHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCj4gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgK PiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQo+IEJJ T1MgYnVnOiBBUElDIHZlcnNpb24gaXMgMCBmb3IgQ1BVIDAvMHgwLCBmaXhpbmcgdXAgdG8gMHgx MAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCj4g QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKPiBBQ1BJ OiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQo+IEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMg KGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDA3XSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA4XSBsYXBpY19pZFsweDg3XSBkaXNhYmxlZCkKPiBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZd IGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCj4gSU9BUElDWzBdOiBhcGljX2lkIDYs IHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1Mwo+IEFDUEk6IElPQVBJ QyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCj4gSU9BUElDWzFd OiBhcGljX2lkIDcsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC0yNzcK PiBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZs KQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs ZXZlbCkKPiBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24KPiBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IDggUHJvY2Vzc29y cyBleGNlZWRzIE5SX0NQVVMgbGltaXQgb2YgNgo+IFNNUDogQWxsb3dpbmcgNiBDUFVzLCAwIGhv dHBsdWcgQ1BVcwo+IEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFydGluZyBhdCBjZmYwMDAw MCAoZ2FwOiBjZmYwMDAwMDoyZWQwMDAwMCkKPiBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu ZWwgb24gWGVuCj4gWGVuIHZlcnNpb246IDQuMi11bnN0YWJsZSAocHJlc2VydmUtQUQpCj4gc2V0 dXBfcGVyY3B1OiBOUl9DUFVTOjYgbnJfY3B1bWFza19iaXRzOjYgbnJfY3B1X2lkczo2IG5yX25v ZGVfaWRzOjEKPiBQRVJDUFU6IEVtYmVkZGVkIDI2IHBhZ2VzL2NwdSBAZmZmZjg4MDA3ZmY0YzAw MCBzNzYxNjAgcjgxOTIgZDIyMTQ0IHUxMDY0OTYKPiBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2Rl IG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA1MTU5NzYKPiBQb2xp Y3kgem9uZTogRE1BMzIKPiBLZXJuZWwgY29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9k ZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBjaWJhY2suaGlk ZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IFBJRCBoYXNoIHRhYmxl IGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykKPiBQbGFjaW5nIDY0TUIgc29m dHdhcmUgSU8gVExCIGJldHdlZW4gZmZmZjg4MDA3OTYwMDAwMCAtIGZmZmY4ODAwN2Q2MDAwMDAK PiBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDc5NjAwMDAwIC0gMHg3ZDYwMDAwMAo+IE1lbW9y eTogMTk3NTA2NGsvMjA5NzE1MmsgYXZhaWxhYmxlICg0NTY3ayBrZXJuZWwgY29kZSwgNDcyayBh YnNlbnQsIDEyMTYxNmsgcmVzZXJ2ZWQsIDE4MzNrIGRhdGEsIDUzMmsgaW5pdCkKPiBTTFVCOiBH ZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9Niwg Tm9kZXM9MQo+IFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCj4g CUR1bXAgc3RhY2tzIG9mIHRhc2tzIGJsb2NraW5nIFJDVS1wcmVlbXB0IEdQLgo+IE5SX0lSUVM6 NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRy aWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5Cj4geGVuX21hcF9waXJxX2dzaTog cmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1Cj4g Y29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKPiBjb25zb2xlIFto dmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+IGluc3RhbGxpbmcgWGVuIHRpbWVy IGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjM4IE1IeiBwcm9jZXNzb3IuCj4gQ2FsaWJyYXRp bmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJl cXVlbmN5Li4gNjAyMC40NyBCb2dvTUlQUyAobHBqPTMwMTAyMzgpCj4gcGlkX21heDogZGVmYXVs dDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczog MjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJbm9kZS1jYWNoZSBoYXNoIHRhYmxl IGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpCj4gTW91bnQtY2FjaGUg aGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBkZXZp Y2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgo+IEluaXRpYWxpemluZyBj Z3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKPiBDUFU6 IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gbWNlOiBDUFUgc3VwcG9ydHMgNiBNQ0UgYmFua3MKPiBB Q1BJOiBDb3JlIHJldmlzaW9uIDIwMTIwMzIwCj4gY3B1IDAgc3BpbmxvY2sgZXZlbnQgaXJxIDI5 NQo+IFBlcmZvcm1hbmNlIEV2ZW50czogKFhFTikgdHJhcHMuYzoyNTYxOmQwIERvbWFpbiBhdHRl bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGU0YTc1ZGY4NjUxNCB0byAw eDAwMDAwMDAwMDAwMGFiY2QuCj4gQnJva2VuIFBNVSBoYXJkd2FyZSBkZXRlY3RlZCwgdXNpbmcg c29mdHdhcmUgZXZlbnRzIG9ubHkuCj4gTUNFOiBJbi1rZXJuZWwgTUNFIGRlY29kaW5nIGVuYWJs ZWQuCj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxCj4gY3B1IDEgc3BpbmxvY2sgZXZl bnQgaXJxIDMwMgo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMgo+IGNwdSAyIHNwaW5s b2NrIGV2ZW50IGlycSAzMDkKPiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMKPiBjcHUg MyBzcGlubG9jayBldmVudCBpcnEgMzE2Cj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSA0 Cj4gY3B1IDQgc3BpbmxvY2sgZXZlbnQgaXJxIDMyMwo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv ciBDUFUgNQo+IGNwdSA1IHNwaW5sb2NrIGV2ZW50IGlycSAzMzAKPiBCcm91Z2h0IHVwIDYgQ1BV cwo+IGRldnRtcGZzOiBpbml0aWFsaXplZAo+IEdyYW50IHRhYmxlcyB1c2luZyB2ZXJzaW9uIDIg bGF5b3V0Lgo+IEdyYW50IHRhYmxlIGluaXRpYWxpemVkCj4gTkVUOiBSZWdpc3RlcmVkIHByb3Rv Y29sIGZhbWlseSAxNgo+IFRPTTogMDAwMDAwMDBkMDAwMDAwMCBha2EgMzMyOE0KPiBUT00yOiAw MDAwMDAwMjMwMDAwMDAwIGFrYSA4OTYwTQo+IEFDUEk6IGJ1cyB0eXBlIHBjaSByZWdpc3RlcmVk Cj4gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0gYXQgW21lbSAweGUw MDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApCj4gUENJOiBub3QgdXNpbmcgTU1D T05GSUcKPiBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBiYXNlIGFjY2Vzcwo+ IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGV4dGVuZGVkIGFjY2Vzcwo+IGJp bzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCj4gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2 aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERldmljZSkKPiBBQ1BJOiBBZGRlZCBf T1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpCj4gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdn cmVnYXRvciBEZXZpY2UpCj4gQUNQSTogRXhlY3V0ZWQgMyBibG9ja3Mgb2YgbW9kdWxlLWxldmVs IGV4ZWN1dGFibGUgQU1MIGNvZGUKPiBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkCj4gQUNQSTog KHN1cHBvcnRzIFMwIFM1KQo+IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRp bmcKPiBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4 ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKPiBQQ0k6IE1NQ09ORklHIGF0 IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJvYXJk IHJlc291cmNlcwo+IEFDUEk6IEVDOiBHUEUgPSAweGEsIEkvTzogY29tbWFuZC9zdGF0dXMgPSAw eDY2LCBkYXRhID0gMHg2Mgo+IFBDSTogVXNpbmcgaG9zdCBicmlkZ2Ugd2luZG93cyBmcm9tIEFD UEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCByZXBvcnQgYSBidWcKPiBBQ1BJ OiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKPiBwY2lf cm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDAwMDAtMHgwY2Y3XQo+ IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZm ZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBh MDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRv dyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0 IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZmZmZmZmZdCj4gcGNpX3Jvb3QgUE5Q MEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQo+ IFBDSSBob3N0IGJyaWRnZSB0byBidXMgMDAwMDowMAo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW2lvICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdCj4gcGNpX2J1cyAwMDAwOjAw OiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfYnVz IDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhjZmYwMDAwMC0weGRmZmZmZmZmXQo+ IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweGYwMDAwMDAwLTB4ZmVi ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBbYnVzIDA3LTA3XQo+IHBj aSAwMDAwOjA2OjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJZSBkZXZpY2UuICBZ b3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9yY2UnCj4gcGNpIDAwMDA6MDA6MDQu MDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQo+IHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlk Z2UgdG8gW2J1cyAwNS0wNV0KPiBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg MDQtMDRdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQo+IHBj aSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KPiBwY2kgMDAwMDowMDox NC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpCj4gIHBj aTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpCj4gIHBjaTAwMDA6 MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVkCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDowNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDowNi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDow Ny4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDoxMS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDAwMDowMDoxMy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41 Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDoxOC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDoxOC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzow MC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4xCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowNjowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4xCj4g cGNpIDAwMDA6MDY6MDAuMTogRmFpbGVkIHRvIGFkZCAtIHBhc3N0aHJvdWdoIG9yIE1TSS9NU0kt WCBtaWdodCBmYWlsIQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDU6MDAuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDM6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDI6MDAuMAo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwMDA6MDI6MDAuMQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQV0g KElSUXMgKjQgNyAxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0Jd IChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktD XSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L RF0gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO S0VdIChJUlFzIDQgKjcgMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtM TktGXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TE5LR10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg W0xOS0hdIChJUlFzIDQgNyAxMCAxMSAxNCAxNSkgKjAsIGRpc2FibGVkLgo+IHhlbi9iYWxsb29u OiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4geGVuLWJhbGxvb246IEluaXRpYWxpc2lu ZyBiYWxsb29uIGRyaXZlci4KPiB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDc6MDAu MCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lCj4gdmdhYXJiOiBsb2FkZWQK PiB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDc6MDAuMAo+IFNDU0kgc3Vi c3lzdGVtIGluaXRpYWxpemVkCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy aXZlciB1c2Jmcwo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaHVi Cj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2IKPiBQQ0k6IFVzaW5n IEFDUEkgZm9yIElSUSByb3V0aW5nCj4gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgo+IEZT LUNhY2hlOiBMb2FkZWQKPiBDYWNoZUZpbGVzOiBMb2FkZWQKPiBwbnA6IFBuUCBBQ1BJIGluaXQK PiBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZAo+IHN5c3RlbSAwMDowMTogW21lbSAweGZl YzIwMDAwLTB4ZmVjMjAwZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowMjog W21lbSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4geGVuX21hcF9w aXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBnc2kgOAo+IHhlbl9tYXBfcGlycV9nc2k6IHJl dHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwo+IHN5c3RlbSAwMDowODogW21lbSAweGZlYzAwMDAw LTB4ZmVjMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowODogW21lbSAw eGZlZTAwMDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBb aW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwNGQ2XSBo YXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjMDAtMHgwYzAxXSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjMTRdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1MC0weDBjNTFdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1Ml0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjNmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkMC0w eDBjZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkMi0weDBj ZDNdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkNC0weDBjZDVd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkNi0weDBjZDddIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkOC0weDBjZGZdIGhhcyBi ZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDgwMC0weDA4OWZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIwMC0weDBiMWZdIGhhcyBiZWVuIHJl c2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIyMC0weDBiM2ZdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkwMC0weDA5MGZdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkxMC0weDA5MWZdIGhhcyBiZWVuIHJlc2VydmVkCj4g c3lzdGVtIDAwOjA5OiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lz dGVtIDAwOjA5OiBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQK PiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZmI4MDAwMC0weGZmYmZmZmZmXSBoYXMgYmVlbiByZXNl cnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlYzEwMDAwLTB4ZmVjMTAwMWZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVkODAwMDAtMHhmZWQ4MGZmZl0gaGFz IGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwMjMwLTB4MDIzZl0gaGFzIGJl ZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwMjkwLTB4MDI5Zl0gaGFzIGJlZW4g cmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwZjQwLTB4MGY0Zl0gaGFzIGJlZW4gcmVz ZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYTMwLTB4MGEzZl0gaGFzIGJlZW4gcmVzZXJ2 ZWQKPiBzeXN0ZW0gMDA6MGI6IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSBoYXMgYmVlbiBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMGMwMDAwLTB4MDAwY2Zm ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMGUwMDAw LTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAw eDAwMTAwMDAwLTB4Y2ZlZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDow YzogW21lbSAweGZlYzAwMDAwLTB4ZmZmZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHBu cDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKPiBBQ1BJOiBBQ1BJIGJ1cyB0eXBlIHBucCB1 bnJlZ2lzdGVyZWQKPiBwY2liYWNrIDAwMDA6MDA6MTQuMjogc2VpemluZyBkZXZpY2UKPiBQTS1U aW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4ZmZmZmZmKSAtIGFib3J0aW5nLgo+ IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNy0wN10KPiBwY2kgMDAwMDow MDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQo+IHBjaSAwMDAwOjAw OjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZmZl0KPiBwY2kg MDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYg NjRiaXQgcHJlZl0KPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZd Cj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0K PiBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlODAwMDAwLTB4ZmU4 ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA1LTA1XQo+IHBj aSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdCj4gcGNp IDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTcwMDAwMC0weGZlN2ZmZmZm XQo+IHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNC0wNF0KPiBwY2kgMDAw MDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQo+IHBjaSAwMDAw OjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU2MDAwMDAtMHhmZTZmZmZmZl0KPiBw Y2kgMDAwMDowMDowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdCj4gcGNpIDAwMDA6MDA6 MDcuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTUwMDAwMC0weGZlNWZmZmZmXQo+IHBjaSAw MDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KPiBwY2kgMDAwMDowMDowZC4w OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZmXQo+IHBjaSAwMDAwOjAwOjBkLjA6 ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU0MDAwMDAtMHhmZTRmZmZmZl0KPiBwY2kgMDAwMDow MDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdCj4geGVuX21hcF9waXJxX2dzaTogcmV0 dXJuaW5nIGlycSA1MiBmb3IgZ3NpIDUyCj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1Mgo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9yIGdzaSA1Mgo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6NTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUzIGZvciBn c2kgNTMKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzCj4gTkVUOiBSZWdpc3RlcmVkIHByb3Rv Y29sIGZhbWlseSAyCj4gSVAgcm91dGUgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAo b3JkZXI6IDcsIDUyNDI4OCBieXRlcykKPiBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRy aWVzOiAyNjIxNDQgKG9yZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKPiBUQ1AgYmluZCBoYXNoIHRh YmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKPiBUQ1A6IEhhc2gg dGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDI2MjE0NCBiaW5kIDY1NTM2KQo+IFRDUDog cmVubyByZWdpc3RlcmVkCj4gVURQIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMs IDMyNzY4IGJ5dGVzKQo+IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6 IDMsIDMyNzY4IGJ5dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBn c2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4geGVuX21hcF9waXJxX2dzaTogcmV0 dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOAo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBn c2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gVW5wYWNraW5nIGluaXRyYW1mcy4u Lgo+IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogNjM4NGsgZnJlZWQKPiBtaWNyb2NvZGU6IENQVTA6 IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTE6IHBhdGNoX2xldmVsPTB4 MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTI6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNy b2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTQ6IHBh dGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTU6IHBhdGNoX2xldmVsPTB4MDEw MDAwYmYKPiBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUgRHJpdmVyOiB2Mi4wMCA8dGlncmFu QGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEKPiBOVEZTIGRyaXZlciAyLjEuMzAg W0ZsYWdzOiBSL1ddLgo+IG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMzg3MAo+IEJsb2NrIGxheWVy IFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAwLjQgbG9hZGVkIChtYWpvciAyNTMp Cj4gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKPiBwY2llcG9ydCAwMDAw OjAwOjAyLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kg MDAwMDowNzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4g cGNpIDAwMDA6MDc6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw dAo+IHBjaWVwb3J0IDAwMDA6MDA6MDQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F IGludGVycnVwdAo+IHBjaSAwMDAwOjA2OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNjowMC4xOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg UENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowNS4wOiBTaWduYWxpbmcgUE1F IHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDU6MDAuMDogU2lnbmFsaW5n IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6MDA6MDYuMDog U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA0OjAw LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAw MDAwOjAwOjA3LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBw Y2kgMDAwMDowMzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0 Cj4gcGNpZXBvcnQgMDAwMDowMDowZC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUg aW50ZXJydXB0Cj4gcGNpIDAwMDA6MDI6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUg UE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjAyOjAwLjE6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQ Q0llIFBNRSBpbnRlcnJ1cHQKPiBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZl cnNpb246IDAuNQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAv ZGV2aWNlOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwCj4gQUNQSTogUG93ZXIgQnV0dG9uIFtQ V1JCXQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdS Qk46MDAvaW5wdXQvaW5wdXQxCj4gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQo+IEdIRVM6IEhF U1QgaXMgbm90IGVuYWJsZWQhCj4gRXZlbnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkLgo+IHhl bi1wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kKPiBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0 IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNhYmxlZAo+IDAwMDA6MDI6MDAuMTogdHR5UzAgYXQgSS9P IDB4YTg4MCAoaXJxID0gNDEpIGlzIGEgU1QxNjY1MFYyCj4gaHBldF9hY3BpX2FkZDogbm8gYWRk cmVzcyBvciBpcnFzIGluIF9DUlMKPiBOb24tdm9sYXRpbGUgbWVtb3J5IGRyaXZlciB2MS4zCj4g SGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNl Y29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KPiBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21v bm90b25pYygpLgo+IGxvb3A6IG1vZHVsZSBsb2FkZWQKPiBhaGNpIDAwMDA6MDA6MTEuMDogQUhD SSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9kZQo+ IGFoY2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBwbSBsZWQgY2xv IHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2kwIDogYWhjaQo+IHNjc2kxIDogYWhjaQo+IHNjc2ky IDogYWhjaQo+IHNjc2kzIDogYWhjaQo+IHNjc2k0IDogYWhjaQo+IHNjc2k1IDogYWhjaQo+IGF0 YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUx MDAgaXJxIDE5Cj4gYXRhMzogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2ZlMDAw IHBvcnQgMHhmZTNmZTE4MCBpcnEgMTkKPiBhdGE0OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0x MDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMjAwIGlycSAxOQo+IGF0YTU6IFNBVEEgbWF4IFVE TUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUyODAgaXJxIDE5Cj4gYXRh NjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTMw MCBpcnEgMTkKPiBhdGE3OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAg cG9ydCAweGZlM2ZlMzgwIGlycSAxOQo+IGFoY2kgMDAwMDowNjowMC4wOiBBSENJIDAwMDEuMDAw MCAzMiBzbG90cyAyIHBvcnRzIDMgR2JwcyAweDMgaW1wbCBTQVRBIG1vZGUKPiBhaGNpIDAwMDA6 MDY6MDAuMDogZmxhZ3M6IDY0Yml0IG5jcSBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+ IHNjc2k2IDogYWhjaQo+IHNjc2k3IDogYWhjaQo+IGF0YTg6IFNBVEEgbWF4IFVETUEvMTMzIGFi YXIgbTgxOTJAMHhmZThmZTAwMCBwb3J0IDB4ZmU4ZmUxMDAgaXJxIDQ0Cj4gYXRhOTogU0FUQSBt YXggVURNQS8xMzMgYWJhciBtODE5MkAweGZlOGZlMDAwIHBvcnQgMHhmZThmZTE4MCBpcnEgNDQK PiB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNgo+IHR1bjogKEMpIDE5 OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgo+IHNreTI6IGRyaXZl ciB2ZXJzaW9uIDEuMzAKPiBza3kyIDAwMDA6MDQ6MDAuMDogWXVrb24tMiBPcHRpbWEgY2hpcCBy ZXZpc2lvbiAxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IGV0aDA6IGFkZHIgMjA6Y2Y6MzA6NmQ6ODk6 YTUKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNkY19uY20KPiBm aXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogYWRkZWQgT0hDSSB2MS4xMCBkZXZpY2UgYXMgY2Fy ZCAwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVpcmtzIDB4MTEKPiBlaGNpX2hjZDogVVNCIDIu MCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyCj4geGVuX21hcF9waXJx X2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJ IDoxNwo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiBlaGNp X2hjZCAwMDAwOjAwOjEyLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu dW1iZXIgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAw L0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kCj4gZWhjaV9oY2QgMDAwMDowMDox Mi4yOiBkZWJ1ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGlycSAxNywgaW8gbWVt IDB4ZmUzZmU0MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhD SSAxLjAwCj4gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp ZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2IxOiBQcm9kdWN0OiBFSENJIEhvc3Qg Q29udHJvbGxlcgo+IHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5 NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6 MDA6MTIuMgo+IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDEtMDoxLjA6IDUgcG9y dHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kg MTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBF SENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMg cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyCj4gZWhjaV9oY2QgMDAwMDowMDoxMy4y OiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmth cm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IGRlYnVnIHBvcnQgMQo+IGVoY2lfaGNkIDAw MDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0gMHhmZTNmZTgwMAo+IGVoY2lfaGNkIDAwMDA6MDA6 MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKPiB1c2IgdXNiMjogTmV3IFVTQiBkZXZp Y2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyCj4gdXNiIHVzYjI6IE5ldyBV U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNi IHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjI6IE1hbnVmYWN0 dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IGVoY2lfaGNkCj4gdXNi IHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yCj4gaHViIDItMDoxLjA6IFVTQiBodWIg Zm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6 IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcK PiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gZWhjaV9oY2Qg MDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy IDMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRz b24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+IGVoY2lfaGNkIDAwMDA6MDA6MTYuMjog ZGVidWcgcG9ydCAxCj4gYXRhNzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAz MDApCj4gYXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRh MjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApCj4gYXRh NTogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhNDogU0FUQSBs aW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMzogU0FUQSBsaW5rIGRvd24g KFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMi4wMDogQVRBLTg6IElOVEVMIFNTRFNBMkNX MTIwRzMsIDRQQzEwMzYyLCBtYXggVURNQS8xMzMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGly cSAxNywgaW8gbWVtIDB4ZmUzZmVjMDAKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFVTQiAyLjAg c3RhcnRlZCwgRUhDSSAxLjAwCj4gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2IzOiBQcm9kdWN0 OiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2IzOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu NC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2IzOiBTZXJpYWxO dW1iZXI6IDAwMDA6MDA6MTYuMgo+IGF0YTk6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0Nv bnRyb2wgMzAwKQo+IGF0YTg6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAw KQo+IGF0YTIuMDA6IDIzNDQ0MTY0OCBzZWN0b3JzLCBtdWx0aSAxOiBMQkE0OCBOQ1EgKGRlcHRo IDMxLzMyKQo+IGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDMtMDoxLjA6IDQgcG9y dHMgZGV0ZWN0ZWQKPiBvaGNpX2hjZDogVVNCIDEuMSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChP SENJKSBEcml2ZXIKPiBhdGEyLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMwo+IHhlbl9tYXBf cGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhl IEdTSSA6MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4g b2hjaV9oY2QgMDAwMDowMDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBi dXMgbnVtYmVyIDQKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUz ZjcwMDAKPiBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFUQSAgICAgIElOVEVMIFNT RFNBMkNXMTIgNFBDMSBQUTogMCBBTlNJOiA1Cj4gc2QgMDowOjA6MDogW3NkYV0gMjM0NDQxNjQ4 IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTIwIEdCLzExMSBHaUIpCj4gc2QgMDowOjA6MDog W3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKPiBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBjYWNo ZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBG VUEKPiAgc2RhOiBzZGExIHNkYTIKPiBzZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRp c2sKPiB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv ZHVjdD0wMDAxCj4gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k dWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250 cm9sbGVyCj4gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4 N2I1ZDkwLWRpcnR5IG9oY2lfaGNkCj4gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDox Mi4wCj4gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNC0wOjEuMDogNSBwb3J0cyBk ZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+ IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IE9IQ0kg SG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1cyByZWdp c3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IGly cSAxOCwgaW8gbWVtIDB4ZmUzZmMwMDAKPiB1c2IgMS0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2 aWNlIG51bWJlciAyIHVzaW5nIGVoY2lfaGNkCj4gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIGZv dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I1OiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I1 OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6 IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I1 OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTMuMAo+IGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k Cj4gaHViIDUtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hj aV9oY2QgMDAwMDowMDoxNC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IGZpcmV3aXJlX2NvcmUg MDAwMDowNTowMC4wOiBjcmVhdGVkIGRldmljZSBmdzA6IEdVSUQgMDAxZThjMDAwMGRlOTEzNiwg UzQwMAo+IG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz aWduZWQgYnVzIG51bWJlciA2Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1l bSAweGZlM2ZkMDAwCj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0 MjQsIGlkUHJvZHVjdD0yNTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZy PTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKPiBodWIgMS0xOjEuMDogVVNCIGh1YiBmb3Vu ZAo+IGh1YiAxLTE6MS4wOiA0IHBvcnRzIGRldGVjdGVkCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2 aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcg VVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVz YiB1c2I2OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFj dHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVz YiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHVi IGZvdW5kCj4gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3Np OiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4 Cj4gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNk IDAwMDA6MDA6MTYuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl ciA3Cj4gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZmMDAwCj4g dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9 MDAwMQo+IHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0y LCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I3OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxl cgo+IHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5 MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMAo+ IGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0ZWN0 ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUwIGZvciBnc2kgNTAKPiBBbHJl YWR5IHNldHVwIHRoZSBHU0kgOjUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl ZCwgYXNzaWduZWQgYnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAs IGlvIG1lbSAweGZlNWZlMDAwCj4gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I4OiBQcm9kdWN0 OiB4SENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu NC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSB4aGNpX2hjZAo+IHVzYiB1c2I4OiBTZXJpYWxO dW1iZXI6IDAwMDA6MDM6MDAuMAo+IGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDgt MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAwMDAwOjAzOjAwLjA6IHhIQ0kgSG9z dCBDb250cm9sbGVyCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNiOTogTmV3IFVTQiBkZXZpY2UgZm91 bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4gdXNiIHVzYjk6IE5ldyBVU0IgZGV2 aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjk6 IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjk6IE1hbnVmYWN0dXJlcjog TGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IHhoY2lfaGNkCj4gdXNiIHVzYjk6 IFNlcmlhbE51bWJlcjogMDAwMDowMzowMC4wCj4gaHViIDktMDoxLjA6IFVTQiBodWIgZm91bmQK PiBodWIgOS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgdXNibHAKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIHVhcwo+IEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLgo+ IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UKPiBV U0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KPiB1c2Jjb3JlOiByZWdpc3RlcmVk IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg aW50ZXJmYWNlIGRyaXZlciB1bXNfZW5ldWI2MjUwCj4gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250 cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lgo+IHNlcmlvOiBpODA0MiBLQkQg cG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKPiBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCww eDY0IGlycSAxMgo+IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBt aWNlCj4gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0 L2lucHV0Mgo+IHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2UgZnJvbSBTNAo+IHJ0Y19jbW9z IDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwCj4gcnRjMDogYWxh cm1zIHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0KPiBpMmMgL2RldiBlbnRy aWVzIGRyaXZlcgo+IEFDUEkgV2FybmluZzogMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAwMDAwMDAw MDAwMGIwNyBTeXN0ZW1JTyBjb25mbGljdHMgd2l0aCBSZWdpb24gXF9TQl8uUENJMC5TQlJHLkFT T0MuU01SRyAxICgyMDEyMDMyMC91dGFkZHJlc3MtMjUxKQo+IHVzYiA0LTI6IG5ldyBmdWxsLXNw ZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgb2hjaV9oY2QKPiBBQ1BJOiBJZiBhbiBBQ1BJ IGRyaXZlciBpcyBhdmFpbGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBp bnN0ZWFkIG9mIHRoZSBuYXRpdmUgZHJpdmVyCj4gQVRLMDExMCBBVEswMTEwOjAwOiBFQyBlbmFi bGVkCj4gc3A1MTAwX3RjbzogU1A1MTAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDEK PiBzcDUxMDBfdGNvOiBtbWlvIGFkZHJlc3MgMHhiOGZlMDAgYWxyZWFkeSBpbiB1c2UKPiBpdDg3 X3dkdDogQ2hpcCBJVDg3MjEgcmV2aXNpb24gMSBpbml0aWFsaXplZC4gdGltZW91dD02MCBzZWMg KG5vd2F5b3V0PTAgdGVzdG1vZGU9MCBleGNsdXNpdmU9MSBub2dhbWVwb3J0PTApCj4geGVuX3dk dDogWGVuIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQo+IHhlbl93ZHQ6IGNhbm5vdCByZWdp c3RlciBtaXNjZGV2IG9uIG1pbm9yPTEzMCAoLTE2KQo+IHdkdDogcHJvYmUgb2Ygd2R0IGZhaWxl ZCB3aXRoIGVycm9yIC0xNgo+IGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAxLjAuMwo+ IGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIyLjAtaW9jdGwgKDIwMTEtMTAtMTkpIGluaXRpYWxp c2VkOiBkbS1kZXZlbEByZWRoYXQuY29tCj4gRURBQyBNQzogVmVyOiAyLjEuMAo+IEFNRDY0IEVE QUMgZHJpdmVyIHYzLjQuMAo+IEVEQUMgYW1kNjQ6IERSQU0gRUNDIGRpc2FibGVkLgo+IEVEQUMg YW1kNjQ6IEVDQyBkaXNhYmxlZCBpbiB0aGUgQklPUyBvciBubyBFQ0MgY2FwYWJpbGl0eSwgbW9k dWxlIHdpbGwgbm90IGxvYWQuCj4gIEVpdGhlciBlbmFibGUgRUNDIGNoZWNraW5nIG9yIGZvcmNl IG1vZHVsZSBsb2FkaW5nIGJ5IHNldHRpbmcgJ2VjY19lbmFibGVfb3ZlcnJpZGUnLgo+ICAoTm90 ZSB0aGF0IHVzZSBvZiB0aGUgb3ZlcnJpZGUgbWF5IGNhdXNlIHVua25vd24gc2lkZSBlZmZlY3Rz LikKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmhpZAo+IHVz YmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgo+IFRDUDogY3ViaWMgcmVnaXN0ZXJlZAo+IE5FVDog UmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKPiBydGNfY21vcyAwMDowNDogc2V0dGluZyBz eXN0ZW0gY2xvY2sgdG8gMjAxMi0wNS0wNyAxMDo1NToyMiBVVEMgKDEzMzYzODgxMjIpCj4gcG93 ZXJub3ctazg6IEZvdW5kIDEgQU1EIFBoZW5vbSh0bSkgSUkgWDYgMTA3NVQgUHJvY2Vzc29yICg2 IGNwdSBjb3JlcykgKHZlcnNpb24gMi4yMC4wMCkKPiBwb3dlcm5vdy1rODogQ29yZSBQZXJmb3Jt YW5jZSBCb29zdGluZzogb24uCj4gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNTMyayBm cmVlZAo+IExvYWRpbmcsIHBsZWFzZSB3YWl0Li4uCj4gdWRldlsxMDc4XTogc3RhcnRpbmcgdmVy c2lvbiAxNjQKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDQxZSwg aWRQcm9kdWN0PTMwZGMKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9Mwo+IHVzYiA0LTI6IFByb2R1Y3Q6IFNvdW5kIEJsYXN0 ZXIgVGFjdGljKDNEKSBBbHBoYQo+IHVzYiA0LTI6IE1hbnVmYWN0dXJlcjogQ3JlYXRpdmUgVGVj aG5vbG9neSBMdGQKPiB1c2IgNC0yOiBTZXJpYWxOdW1iZXI6IDAwMDIzMTYyCj4gaW5wdXQ6IENy ZWF0aXZlIFRlY2hub2xvZ3kgTHRkIFNvdW5kIEJsYXN0ZXIgVGFjdGljKDNEKSBBbHBoYSBhcyAv ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMC91c2I0LzQtMi80LTI6MS4zL2lucHV0L2lu cHV0Mwo+IGdlbmVyaWMtdXNiIDAwMDM6MDQxRTozMERDLjAwMDE6IGlucHV0LGhpZGRldjA6IFVT QiBISUQgdjEuMDAgRGV2aWNlIFtDcmVhdGl2ZSBUZWNobm9sb2d5IEx0ZCBTb3VuZCBCbGFzdGVy IFRhY3RpYygzRCkgQWxwaGFdIG9uIHVzYi0wMDAwOjAwOjEyLjAtMi9pbnB1dDMKPiBCZWdpbjog TG9hZGluZyBlc3NlbnRpYWwgZHJpdmVycyAuLi4gdXNiIDEtMS4xOiBuZXcgZnVsbC1zcGVlZCBV U0IgZGV2aWNlIG51bWJlciA0IHVzaW5nIGVoY2lfaGNkCj4gZG9uZS4KPiBCZWdpbjogUnVubmlu ZyAvc2NyaXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLgo+IEJlZ2luOiBNb3VudGluZyByb290 IGZpbGUgc3lzdGVtIC4uLiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9sb2NhbC10b3AgLi4uIHVz YiAxLTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0w MDEzCj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0y LCBTZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVjdDogUmF6ZXIgT3JvY2hpCj4gdXNi IDEtMS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gZG9uZS4KPiBpbnB1dDogUmF6ZXIgUmF6ZXIg T3JvY2hpIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4x LzEtMS4xOjEuMC9pbnB1dC9pbnB1dDQKPiBnZW5lcmljLXVzYiAwMDAzOjE1MzI6MDAxMy4wMDAy OiBpbnB1dDogVVNCIEhJRCB2MS4xMSBNb3VzZSBbUmF6ZXIgUmF6ZXIgT3JvY2hpXSBvbiB1c2It MDAwMDowMDoxMi4yLTEuMS9pbnB1dDAKPiBpbnB1dDogUmF6ZXIgUmF6ZXIgT3JvY2hpIGFzIC9k ZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4xLzEtMS4xOjEuMS9p bnB1dC9pbnB1dDUKPiBnZW5lcmljLXVzYiAwMDAzOjE1MzI6MDAxMy4wMDAzOiBpbnB1dDogVVNC IEhJRCB2MS4xMSBLZXlib2FyZCBbUmF6ZXIgUmF6ZXIgT3JvY2hpXSBvbiB1c2ItMDAwMDowMDox Mi4yLTEuMS9pbnB1dDEKPiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9sb2NhbC1wcmVtb3VudCAu Li4gZG9uZS4KPiB1c2IgMS0xLjI6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNSB1 c2luZyBlaGNpX2hjZAo+IEVYVDQtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBv cmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv bG9jYWwtYm90dG9tIC4uLiBkb25lLgo+IGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv aW5pdC1ib3R0b20gLi4uIGRvbmUuCj4gdXNiIDEtMS4yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwg aWRWZW5kb3I9MDRmMiwgaWRQcm9kdWN0PTA0MDMKPiB1c2IgMS0xLjI6IE5ldyBVU0IgZGV2aWNl IHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wCj4gdXNiIDEtMS4yOiBQ cm9kdWN0OiBVU0IgS2V5Ym9hcmQKPiB1c2IgMS0xLjI6IE1hbnVmYWN0dXJlcjogQ2hpY29ueQo+ IElOSVQ6IHZlcnNpb24gMi44OCBib290aW5nCj4gaW5wdXQ6IENoaWNvbnkgVVNCIEtleWJvYXJk IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4yLzEtMS4y OjEuMC9pbnB1dC9pbnB1dDYKPiBnZW5lcmljLXVzYiAwMDAzOjA0RjI6MDQwMy4wMDA0OiBpbnB1 dDogVVNCIEhJRCB2MS4xMSBLZXlib2FyZCBbQ2hpY29ueSBVU0IgS2V5Ym9hcmRdIG9uIHVzYi0w MDAwOjAwOjEyLjItMS4yL2lucHV0MAo+IFVzaW5nIG1ha2VmaWxlLXN0eWxlIGNvbmN1cnJlbnQg Ym9vdCBpbiBydW5sZXZlbCBTLmlucHV0OiBDaGljb255IFUKPiBTQiBLZXlib2FyZCBhcyAvZGV2 aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8xLTEuMjoxLjEvaW5w dXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNTogaW5wdXQsaGlkZGV2 MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAw MDowMDoxMi4yLTEuMi9pbnB1dDEKPiBGaWxlcyB1bmRlciBtb3VudCBwb2ludCAnL2xpYi9pbml0 L3J3JyB3aWxsIGJlIGhpZGRlbi4gLi4ubmV0IGZpcmV3aXJlMDogSVB2NCBvdmVyIElFRUUgMTM5 NCBvbiBjYXJkIDAwMDA6MDU6MDAuMAo+IGZpcmV3aXJlX2NvcmUgMDAwMDowNTowMC4wOiByZWZy ZXNoZWQgZGV2aWNlIGZ3MAo+ICAod2FybmluZykuCj4gRmlsZXMgdW5kZXIgbW91bnQgcG9pbnQg Jy92YXIvcnVuJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBGaWxlcyB1bmRlciBt b3VudCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBT dGFydGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hlcjogdWRldmR1ZGV2WzEyODZdOiBz dGFydGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXppbmcgdGhlIGluaXRpYWwgaG90cGx1 ZyBldmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYgdG8gYmUgZnVsbHkgcG9wdWxhdGVk Li4uZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4nLi4uZG9uZS4KPiBTZXR0aW5nIHBy ZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGluZyBzd2FwOi4KPiBFWFQ0LWZzIChk bS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2lsbCBub3cgY2hlY2sgcm9vdCBmaWxl IHN5c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBbL3NiaW4vZnNjay5leHQ0 ICgxKSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiAKPiAv ZGV2L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzU2NDcvMTMxMDcyMCBmaWxlcywgMTI3 NjYzNS81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0 czogZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgZmlyZXdpcmUtc2Jw Mi4KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4u Li4KPiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdy b3VwcyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGls ZS4uLgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlw ZSBsdm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2gi IG5vdyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUgbHZtIGFuZCBtZCBzd2FwOmRvbmUu Cj4gV2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4KPiBmc2NrIGZyb20gdXRpbC1saW51 eC1uZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0ZW1zLgo+IERvbmUgY2hlY2tpbmcg ZmlsZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBpbiAvdmFyL2xvZy9mc2NrL2NoZWNr ZnMgaWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4gV2lsbCBub3cgbW91bnQgbG9jYWwg ZmlsZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6IG1vdW50aW5nIHVuY2hlY2tlZCBm cywgcnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBFWFQ0LWZzIChzZGExKTogbW91bnRl ZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQo+IC4KPiBX aWxsIG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9y YXJ5IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4gLgo+IENoZWNraW5nIG1pbmltdW0g c3BhY2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJuZWwgdmFyaWFibGVzIC4uLiAvZXRj L3N5c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJlciBnZW5lcmF0 b3IuLi5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29ja2V0IGRpcmVjdG9yeSAvdG1wLy5Y MTEtdW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQgZGlyZWN0b3J5IC90bXAvLklDRS11 bml4Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLmRldmljZSBldGgwIGVu dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBlbmFibGlu ZyBpbnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBT dGFydGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVzZS4KPiBTZXR0aW5nIGNvbnNvbGUg c2NyZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4gU2tpcHBpbmcg Zm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXApLgo+IFNldHRp bmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IFNldHRpbmcgc2Vuc29ycyBs aW1pdHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMKPiBVc2luZyBtYWtlZmlsZS1zdHls ZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBOb3Qgc3RhcnRpbmcgZmFuY29udHJv bDsgcnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5nKS4KPiBhY3BpZDogc3RhcnRpbmcg dXAgd2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIKPiAKPiBhY3BpZDogMSBydWxlIGxv YWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcgaXMgb2Zm Cj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0gbWVzc2Fn ZSBidXM6IGRidXMuCj4gc3NoZCAoMjA2NCk6IC9wcm9jLzIwNjQvb29tX2FkaiBpcyBkZXByZWNh dGVkLCBwbGVhc2UgdXNlIC9wcm9jLzIwNjQvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLgo+IFN0YXJ0 aW5nIHRoZSBXaW5iaW5kIGRhZW1vbjogd2luYmluZC4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3Vy ZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgb3hlbnN0b3JlZC4uLgo+IFNldHRpbmcg ZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4gU3RhcnRpbmcgZG9t YWluIG5hbWUgc2VydmljZS4uLjogYmluZDkuCj4gU3RhcnRpbmcgU2FtYmEgZGFlbW9uczogbm1i ZCBzbWJkLgo+IFN0YXJ0aW5nIHBlcmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLgo+IFN0 YXJ0aW5nIFBvc3RmaXggTWFpbCBUcmFuc3BvcnQgQWdlbnQ6IHBvc3RmaXguCj4gQkxLVEFQQ1RS TFsyMjM0XTogYmxrdGFwY3RybC5jOjc5MjogYmxrdGFwY3RybDogdjEuMC4wCj4gCj4gQkxLVEFQ Q1RSTFsyMjM0XTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChh aW8pXQo+IAo+IEJMS1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZl cjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RSTFsyMjM0XTogYmxrdGFwY3RybC5j Ojc5NDogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBCTEtUQVBDVFJM WzIyMzRdOiBibGt0YXBjdHJsLmM6Nzk0OiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNrIGltYWdlIChy YW0pXQo+IAo+IEJMS1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZl cjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RSTFsyMjM0XTogYmxrdGFwY3RybC5j Ojc5NDogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJMS1RBUENUUkxb MjIzNF06IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxlZAo+IAo+IEJM S1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo4NjE6IGNvdWxkbid0IG9wZW4gYmxrdGFwIGlu dGVyZmFjZXNreTIgMDAwMDowNDowMC4KPiAwOiBldGgwOiBMaW5rIGlzIHVwIGF0IDEwMCBNYnBz LAo+ICBmdWxsIGR1cGxleCwgZmxvdyBjb250cm9sIGJvdGgKPiBCTEtUQVBDVFJMWzIyMzRdOiBi bGt0YXBjdHJsLmM6OTI0OiBVbmFibGUgdG8gc3RhcnQgYmxrdGFwY3RybGJyMDogcG9ydCAxKGV0 aDAKPiApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IAo+IGJyMDogcG9ydCAxKGV0aDApIGVu dGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IFN0YXJ0aW5nIFMuTS5BLlIuVC4gZGFlbW9uOiBzbWFy dGQuCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlCj4gUnVubmlu ZyBsb2NhbCBib290IHNjcmlwdHMgKC9ldGMvcmMubG9jYWwpKFhFTikgUENJIHJlbW92ZSBkZXZp Y2UgMDAwMDowMDoxMi4yCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0 ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5lY3RlZAo+IAo+IGFj cGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gKFhFTikgUENJIHJl bW92ZSBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDow MDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4y Cj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gYWNw aWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiAoWEVOKSBpb3BvcnRf bWFwOmFkZDogZG9tMSBncG9ydD0zYjAgbXBvcnQ9M2IwIG5yPWMKPiAoWEVOKSBtZW1vcnlfbWFw OmFkZDogZG9tMSBnZm49YTAgbWZuPWEwIG5yPTIwCj4gKFhFTikgaW9wb3J0X21hcDphZGQ6IGRv bTEgZ3BvcnQ9M2MwIG1wb3J0PTNjMCBucj0zCj4gKFhFTikgaW9wb3J0X21hcDphZGQ6IGRvbTEg Z3BvcnQ9M2M0IG1wb3J0PTNjNCBucj0xYwo+IChYRU4pIEhWTTE6IEhWTSBMb2FkZXIKPiAoWEVO KSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMi11bnN0YWJsZQo+IChYRU4pIEhWTTE6IFhlbmJ1cyBy aW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA4Cj4gKFhFTikgSFZNMTogU3lzdGVtIHJl cXVlc3RlZCBST01CSU9TCj4gKFhFTikgSFZNMTogQ1BVIHNwZWVkIGlzIDMwMTAgTUh6Cj4gKFhF TikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUKPiAoWEVOKSBIVk0x OiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQ Q0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAxIHJv dXRlZCB0byBJUlExMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQg MCAtPiAxMQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQo+IChY RU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZN MTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDAx OjMgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAw NTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNjowIElOVEItPklSUTUKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYg MDg6MCBJTlRCLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBJTlRBLT5JUlExMAo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAxMDAwMDAwMDogZTAwMDAwMGMK PiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yPTEwMDAw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMDAwMDAw OAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjEwMDAw MDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAw NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAw MDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYw MDA0Cj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDYwIG1mbj1mZTliYyBucj00 Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwOTowIGJhciAxMCBzaXplIDAwMDA0MDAwOiBmMTA2NDAw NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAgc2l6ZSAwMDAwMTAwMDogZjEwNjgwMDAK PiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4g KFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY5IG1mbj1mMDAwMCBucj0xCj4gKFhF TikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMDAwMTAwOiAwMDAwYzAwMQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMjAgc2l6ZSAwMDAwMDEwMDogMDAwMGMxMDEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwNDA6IDAwMDBjMjAxCj4g KFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDEwOiAwMDAwYzI0MQo+ IChYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOgo+IChYRU4pIEhWTTE6 ICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsz LzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAt IENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhd IC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhl ZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQ VTQgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4u LiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTUgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBN VFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6IFRlc3Rpbmcg SFZNIGVudmlyb25tZW50Ogo+IChYRU4pIEhWTTE6ICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJv dW5kYXJpZXMgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dB UEdTIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiBQYXNzZWQgMiBvZiAyIHRlc3RzCj4gKFhFTikg SFZNMTogV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgo+IChYRU4pIEhWTTE6IExvYWRpbmcgUk9N QklPUyAuLi4KPiAoWEVOKSBIVk0xOiA5NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkg ZXh0ZW5zaW9uczoKPiAoWEVOKSBIVk0xOiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZj MDAzNWJjIC4uLiBkb25lCj4gKFhFTikgSFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgo+IChY RU4pIEhWTTE6IExvYWRpbmcgVkdBQklPUyBvZiBwYXNzdGhyb3VnaGVkIGdmeCAuLi4KPiAoWEVO KSBIVk0xOiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLgo+IChYRU4pIEhWTTE6ICAtIE1hbnVm YWN0dXJlcjogaHR0cDovL2lweGUub3JnCj4gKFhFTikgSFZNMTogIC0gUHJvZHVjdCBuYW1lOiBp UFhFCj4gKFhFTikgSFZNMTogT3B0aW9uIFJPTXM6Cj4gKFhFTikgSFZNMTogIGMwMDAwLWNmZmZm OiBWR0EgQklPUwo+IChYRU4pIEhWTTE6ICBkMDAwMC1lMGZmZjogRXRoZXJib290IFJPTQo+IChY RU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBIVk0xOiB2bTg2IFRTUyBhdCBmYzAw ZjcwMAo+IChYRU4pIEhWTTE6IEJJT1MgbWFwOgo+IChYRU4pIEhWTTE6ICBmMDAwMC1mZmZmZjog TWFpbiBCSU9TCj4gKFhFTikgSFZNMTogRTgyMCB0YWJsZToKPiAoWEVOKSBIVk0xOiAgWzAwXTog MDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNCj4gKFhFTikgSFZNMTog IFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVECj4g KFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDAK PiAoWEVOKSBIVk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAwMDAwMDAwMDowMDEwMDAw MDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw MDAwMDplMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOmUwMDAwMDAw IC0gMDAwMDAwMDA6ZmMwMDAwMDAKPiAoWEVOKSBIVk0xOiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAw MDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzA1XTogMDAw MDAwMDE6MDAwMDAwMDAgLSAwMDAwMDAwMToyMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogSW52 b2tpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6 IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IEJvY2hzIEJJT1MgLSBidWlsZDog MDYvMjMvOTkKPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIv MDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IE9wdGlvbnM6IGFwbWJpb3MgcGNpYmlvcyBlbHRv cml0byBQTU0gCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogYXRhMC0wOiBQQ0hTPTE2Mzgz LzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRh MCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgyMDQ4MCBNQnl0ZXMpCj4g KFhFTikgSFZNMTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hT PTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRhMCAgc2xhdmU6IFFFTVUgSEFSRERJU0sgQVRB LTcgSGFyZC1EaXNrICg1MTIwMCBNQnl0ZXMpCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTog Cj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogUHJlc3MgRjEyIGZvciBib290IG1lbnUuCj4g KFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLgo+IChY RU4pIEhWTTE6IEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEg UENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGlu ayAxIGNoYW5nZWQgMTAgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNo YW5nZWQgMTEgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5nZWQg NSAtPiAwCj4gKFhFTikgbWVtb3J5X21hcDpyZW1vdmU6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1kMDAw MCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTAyMCBtZm49 ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAwMDAgbWZuPWQw MDAwIG5yPTEwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDIwIG1mbj1m ZTllMCBucj0yMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2MCBtZm49 ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2MCBtZm49ZmU5 YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2OCBtZm49ZmUz ZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OCBtZm49ZmUzZjcg bnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAwMDAg bnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAwMDAgbnI9 MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9 NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+ IChYRU4pIGdyYW50X3RhYmxlLmM6MTE3NDpkMSBFeHBhbmRpbmcgZG9tICgxKSBncmFudCB0YWJs ZSBmcm9tICg0KSB0byAoMzIpIGZyYW1lcy4KPiAoWEVOKSBpcnEuYzozNTA6IERvbTEgY2FsbGJh Y2sgdmlhIGNoYW5nZWQgdG8gR1NJIDI4Cj4gKFhFTikgRG9tYWluIDAgY3Jhc2hlZDogcmVib290 aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9f X18gICAgICAgICAgICAgICAgICAgICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19f XyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18g fCB8IF9fXyAKPiAgIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18g XC8gX198IF9fLyBfYCB8ICdfIFx8IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98 IC8gX18vfF9ffCB8X3wgfCB8IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xf XF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8u X18vfF98XF9fX3wKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11 bnN0YWJsZSAocm9vdEAobm9uZSkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgp ICkgU2F0IE1heSAgNSAxNTo0ODo0OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0 OiBGcmkgTWF5IDA0IDExOjE4OjQ4IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhF TikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JV QiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhv bGRlciBkb20wX21lbT0yRyBkb20wX21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZs PWFsbCBzeW5jX2NvbnNvbGUgY29tMT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAo WEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwg Zm9udCA4eDE2Cj4gKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGlt ZTogMSBzZWNvbmRzCj4gKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBN QlIgc2lnbmF0dXJlcwo+IChYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVz Cj4gKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAw MDAwMDAwMDAwOWFjMDAgKHVzYWJsZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAw MDAwMDAwYTAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAw MDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAw MGNmZTgwMDAwICh1c2FibGUpCj4gKFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNm ZTk4MDAwIChBQ1BJIGRhdGEpCj4gKFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNm ZWMwMDAwIChBQ1BJIE5WUykKPiAoWEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2Zm MDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAw MDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAw MDAwICh1c2FibGUpCj4gKFhFTikgQUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFN KQo+IChYRU4pIEFDUEk6IFhTRFQgQ0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAy MDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQg KHIzIDEwMjgxMSBGQUNQMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6 IERTRFQgQ0ZFODA0NzAsIEU2RTMgKHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIw MDYwMTEzKQo+IChYRU4pIEFDUEk6IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBB UElDIENGRTgwMzkwLCAwMDk4IChyMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAg ICA5NykKPiAoWEVOKSBBQ1BJOiBNQ0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNG RyAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAw MDcyIChyMSAxMDI4MTEgT0VNQjE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBIUEVUIENGRThGOEMwLCAwMDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNG VCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAg ICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThG OUUwLCAwRTEwIChyMSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAo WEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZp Z3VyYXRpb24gZm91bmQKPiAoWEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAt MDAwMDAwMDIzMDAwMDAwMAo+IChYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikg Zm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhF TikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBv cnQ6IDB4ODA4Cj4gKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0s IHBtMXhfZXZ0WzgwMCwwXQo+IChYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3Zl Y1tjZmU5ODAwY10sIHZlY19zaXplWzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz cyAweGZlZTAwMDAwCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRb MHgwMF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYK PiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVk KQo+IChYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJv Y2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDox MCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp Y19pZFsweDA0XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lv biAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVu YWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4g KFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNl WzBdKQo+IChYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4 ZmVjMDAwMDAsIEdTSSAwLTIzCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNz WzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJ TlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4p IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZl bCkKPiAoWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJR MiB1c2VkIGJ5IG92ZXJyaWRlLgo+IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4K PiAoWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAo WEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxl IGlzIG5vdCBmb3VuZCEKPiAoWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24KPiAoWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVn IENQVXMpCj4gKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4p IFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBE ZXRlY3RlZCAzMDEwLjI1NCBNSHogcHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNo YXJpbmcuCj4gKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVk Cj4gKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50 IDAwMDAgYnVzZXMgMDAgLSBmZgo+IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21l bnQgMDAwMCBidXMgMDAtZmYKPiAoWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVO KSBBTUQtVmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxp c2F0aW9uIGVuYWJsZWQKPiAoWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFC TElORyBJTy1BUElDIElSUXMKPiAoWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVO KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4g KFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQg Y29uc29sZSByaW5nIG9mIDY0IEtpQi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhF TikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBh Z2UgVGFibGVzIChOUFQpCj4gKFhFTikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1 YWxpc2F0aW9uCj4gKFhFTikgIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAt IFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikg SFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06 IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0 X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3Rf Y3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9j cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2Nw dV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChY RU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhF TikgSFBFVCdzIE1TSSBtb2RlIGhhc24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBS ZW1hcHBpbmcgaXMgZW5hYmxlZC4KPiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4p IE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAo WEVOKSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4g KFhFTikgWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RM ID0gMHhmZmZmZmZmZgo+IChYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVs Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDVkMzAwMAo+IChY RU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTVkMzAwMCBtZW1zej0weDZlMGU4 Cj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxNjQyMDAwIG1lbXN6PTB4 MTI5ODAKPiAoWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2NTUwMDAgbWVt c3o9MHg0ZmYwMDAKPiAoWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAt PiAweDFiNTQwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4 Igo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhF TikgZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikg ZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAo WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxl c3xwYWVfcGdkaXJfYWJvdmVfNGdiIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01P REUgPSAieWVzIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMi Cj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+ IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChY RU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hl bl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAg ICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgw Cj4gKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVO KSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2 aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgxYjU0MDAwCj4gKFhFTikgICAgIHZpcnRfZW50 cnkgICAgICAgPSAweGZmZmZmZmZmODE2NTUyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAg ICA9IDB4ZmZmZmZmZmZmZmZmZmZmZgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is IGNvbXBhdDMyCj4gKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAw eDEwMDAwMDAgLT4gMHgxYjU0MDAwCj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5U Ogo+IChYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjI0MDAwMDAwLT4wMDAwMDAwMjI4MDAw MDAwICg1MDYzMDggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNr OiAwMDAwMDAwMjJmOWM0MDAwLT4wMDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1P UlkgQVJSQU5HRU1FTlQ6Cj4gKFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAt PmZmZmZmZmZmODFiNTQwMDAKPiAoWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWI1NDAw MC0+ZmZmZmZmZmY4MjE4ZjIwMAo+IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyMTkw MDAwLT5mZmZmZmZmZjgyNTkwMDAwCj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODI1 OTAwMDAtPmZmZmZmZmZmODI1OTA0YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4 MjU5MTAwMC0+ZmZmZmZmZmY4MjVhODAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZm ZjgyNWE4MDAwLT5mZmZmZmZmZjgyNWE5MDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZm ZmZmODAwMDAwMDAtPmZmZmZmZmZmODI4MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZm ZmZmZmY4MTY1NTIwMAo+IChYRU4pIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVs Zl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZm ODE1ZDMwMDAKPiAoWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1 ZDMwMDAgLT4gMHhmZmZmZmZmZjgxNjQxMGU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRy IDIgYXQgMHhmZmZmZmZmZjgxNjQyMDAwIC0+IDB4ZmZmZmZmZmY4MTY1NDk4MAo+IChYRU4pIGVs Zl9sb2FkX2JpbmFyeTogcGhkciAzIGF0IDB4ZmZmZmZmZmY4MTY1NTAwMCAtPiAweGZmZmZmZmZm ODE2Y2MwMDAKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIElu aXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChY RU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVO KSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikg KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoq KioqKiogVGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkg ZW5zdXJpbmcKPiAoWEVOKSAqKioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5 IGRlbGl2ZXJlZCBvbiB0aGUgc2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0 IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAq KioqKioqIHRpbWVrZWVwaW5nLiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24g dXNlIQo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKPiAoWEVOKSAzLi4uIDIuLi4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERP TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAo WEVOKSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp Y2FsIG1lbW9yeQo+IFhlbjogc2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQg c3RhcnRlZC4uLgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIGNwdQo+IExpbnV4IHZlcnNpb24gMy40LjAtcmM0LTAwMzk1LWc4 N2I1ZDkwLWRpcnR5IChyb290QHhlbikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUt OCkgKSAjNyBTTVAgUFJFRU1QVCBNb24gTWF5IDcgMTM6MTY6MTAgQ0VTVCAyMDEyCj4gQ29tbWFu ZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09 MkcgcGFuaWM9MTUgeGVuLXBjaWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5 cHJpbnRrPXhlbgo+IEZyZWVpbmcgOWEtMTAwIHBmbiByYW5nZTogMTAyIHBhZ2VzIGZyZWVkCj4g UmVsZWFzZWQgMTAyIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKPiBTZXQgMTk3MDk0IHBhZ2Uocykg dG8gMS0xIG1hcHBpbmcKPiBQb3B1bGF0aW5nIDgwMDAwLTgwMDY2IHBmbiByYW5nZTogMTAyIHBh Z2VzIGFkZGVkCj4gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAw MDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAw MDA5YWMwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAx MDAwMDAgLSAwMDAwMDAwMDgwMDY2MDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDA4MDA2NjAw MCAtIDAwMDAwMDAwY2ZlODAwMDAgKHVudXNhYmxlKQo+ICBYZW46IDAwMDAwMDAwY2ZlODAwMDAg LSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gIFhlbjogMDAwMDAwMDBjZmU5ODAwMCAt IDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZTKQo+ICBYZW46IDAwMDAwMDAwY2ZlYzAwMDAgLSAw MDAwMDAwMGNmZjAwMDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAw MDAwMDBmZWMwMTAwMCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAw MDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAw MGZlZTAxMDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw MDAwMDAwMCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAw MDAwMDAgKHVudXNhYmxlKQo+IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChF eGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNh bCBSQU0gbWFwOgo+ICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAo dXNhYmxlKQo+ICB1c2VyOiAwMDAwMDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVz ZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2Fi bGUpCj4gIHVzZXI6IDAwMDAwMDAwODAwNjYwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1bnVzYWJs ZSkKPiAgdXNlcjogMDAwMDAwMDBjZmU4MDAwMCAtIDAwMDAwMDAwY2ZlOTgwMDAgKEFDUEkgZGF0 YSkKPiAgdXNlcjogMDAwMDAwMDBjZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZT KQo+ICB1c2VyOiAwMDAwMDAwMGNmZWMwMDAwIC0gMDAwMDAwMDBjZmYwMDAwMCAocmVzZXJ2ZWQp Cj4gIHVzZXI6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkK PiAgdXNlcjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ ICB1c2VyOiAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCj4g IHVzZXI6IDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKPiAg dXNlcjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IERN SSBwcmVzZW50Lgo+IE5vIEFHUCBicmlkZ2UgZm91bmQKPiBsYXN0X3BmbiA9IDB4ODAwMDAgbWF4 X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKPiBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAw MDAwZmY3ODBdIGZmNzgwCj4gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0w MDAwMDAwMDgwMDAwMDAwCj4gUkFNRElTSzogMDFiNTQwMDAgLSAwMjE5MDAwMAo+IEFDUEk6IFJT RFAgMDAwMDAwMDAwMDBmYmYyMCAwMDAyNCAodjAyIEFDUElBTSkKPiBBQ1BJOiBYU0RUIDAwMDAw MDAwY2ZlODAxMDAgMDAwNUMgKHYwMSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAwMDAw MDA5NykKPiBBQ1BJOiBGQUNQIDAwMDAwMDAwY2ZlODAyOTAgMDAwRjQgKHYwMyAxMDI4MTEgRkFD UDE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBEU0RUIDAwMDAwMDAwY2ZlODA0 NzAgMEU2RTMgKHYwMSAgQTE1OTUgQTE1OTUwMDAgMDAwMDAwMDAgSU5UTCAyMDA2MDExMykKPiBB Q1BJOiBGQUNTIDAwMDAwMDAwY2ZlOTgwMDAgMDAwNDAKPiBBQ1BJOiBBUElDIDAwMDAwMDAwY2Zl ODAzOTAgMDAwOTggKHYwMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykK PiBBQ1BJOiBNQ0ZHIDAwMDAwMDAwY2ZlODA0MzAgMDAwM0MgKHYwMSAxMDI4MTEgT0VNTUNGRyAg MjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBPRU1CIDAwMDAwMDAwY2ZlOTgwNDAgMDAw NzIgKHYwMSAxMDI4MTEgT0VNQjE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBI UEVUIDAwMDAwMDAwY2ZlOGY4YzAgMDAwMzggKHYwMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjgg TVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBJVlJTIDAwMDAwMDAwY2ZlOGY5MDAgMDAwRTAgKHYwMSAg QU1EICAgICBSRDg5MFMgMDAyMDIwMzEgQU1EICAwMDAwMDAwMCkKPiBBQ1BJOiBTU0RUIDAwMDAw MDAwY2ZlOGY5ZTAgMDBFMTAgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAw MDAwMSkKPiBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiBGYWtpbmcgYSBub2RlIGF0IDAw MDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA4MDAwMDAwMAo+IEluaXRtZW0gc2V0dXAgbm9kZSAwIDAw MDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA4MDAwMDAwMAo+ICAgTk9ERV9EQVRBIFswMDAwMDAwMDdm ZmZjMDAwIC0gMDAwMDAwMDA3ZmZmZmZmZl0KPiBab25lIFBGTiByYW5nZXM6Cj4gICBETUEgICAg ICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKPiAgIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgw MDEwMDAwMAo+ICAgTm9ybWFsICAgZW1wdHkKPiBNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBl YWNoIG5vZGUKPiBFYXJseSBtZW1vcnkgUEZOIHJhbmdlcwo+ICAgICAwOiAweDAwMDAwMDEwIC0+ IDB4MDAwMDAwOWEKPiAgICAgMDogMHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCj4gQUNQSTogUE0t VGltZXIgSU8gUG9ydDogMHg4MDgKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19p ZFsweDAwXSBlbmFibGVkKQo+IEJJT1MgYnVnOiBBUElDIHZlcnNpb24gaXMgMCBmb3IgQ1BVIDAv MHgwLCBmaXhpbmcgdXAgdG8gMHgxMAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj X2lkWzB4MDFdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRb MHgwMl0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAz XSBlbmFibGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVu YWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl ZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkK PiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDg3XSBkaXNhYmxlZCkKPiBB Q1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCj4g SU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdT SSAwLTI1Mwo+IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lf YmFzZVsyNF0pCj4gSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4 ZmVjMjAwMDAsIEdTSSAyNC0yNzcKPiBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJx IDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KPiBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhm ZWQwMDAwMAo+IDggUHJvY2Vzc29ycyBleGNlZWRzIE5SX0NQVVMgbGltaXQgb2YgNgo+IFNNUDog QWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcwo+IEFsbG9jYXRpbmcgUENJIHJlc291cmNl cyBzdGFydGluZyBhdCBjZmYwMDAwMCAoZ2FwOiBjZmYwMDAwMDoyZWQwMDAwMCkKPiBCb290aW5n IHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuCj4gWGVuIHZlcnNpb246IDQuMi11bnN0YWJs ZSAocHJlc2VydmUtQUQpCj4gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjYgbnJfY3B1bWFza19iaXRz OjYgbnJfY3B1X2lkczo2IG5yX25vZGVfaWRzOjEKPiBQRVJDUFU6IEVtYmVkZGVkIDI2IHBhZ2Vz L2NwdSBAZmZmZjg4MDA3ZmY0YzAwMCBzNzYxNjAgcjgxOTIgZDIyMTQ0IHUxMDY0OTYKPiBCdWls dCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFs IHBhZ2VzOiA1MTU5NzYKPiBQb2xpY3kgem9uZTogRE1BMzIKPiBLZXJuZWwgY29tbWFuZCBsaW5l OiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFu aWM9MTUgeGVuLXBjaWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRr PXhlbgo+IFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRl cykKPiBQbGFjaW5nIDY0TUIgc29mdHdhcmUgSU8gVExCIGJldHdlZW4gZmZmZjg4MDA3OTYwMDAw MCAtIGZmZmY4ODAwN2Q2MDAwMDAKPiBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDc5NjAwMDAw IC0gMHg3ZDYwMDAwMAo+IE1lbW9yeTogMTk3NTA2NGsvMjA5NzE1MmsgYXZhaWxhYmxlICg0NTY3 ayBrZXJuZWwgY29kZSwgNDcyayBhYnNlbnQsIDEyMTYxNmsgcmVzZXJ2ZWQsIDE4MzNrIGRhdGEs IDUzMmsgaW5pdCkKPiBTTFVCOiBHZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBN aW5PYmplY3RzPTAsIENQVXM9NiwgTm9kZXM9MQo+IFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBS Q1UgaW1wbGVtZW50YXRpb24uCj4gCUR1bXAgc3RhY2tzIG9mIHRhc2tzIGJsb2NraW5nIFJDVS1w cmVlbXB0IEdQLgo+IE5SX0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVy cmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5 Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6 IGNvbG91ciBWR0ErIDgweDI1Cj4gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg ZGlzYWJsZWQKPiBjb25zb2xlIFtodmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+ IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjU0IE1IeiBw cm9jZXNzb3IuCj4gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNjAyMC41MCBCb2dvTUlQUyAobHBqPTMwMTAy NTQpCj4gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hl IGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJ bm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYg Ynl0ZXMpCj4gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBkZXZpY2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQ cm9jZXNzb3IgSUQ6IDAKPiBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gbWNlOiBDUFUgc3Vw cG9ydHMgNiBNQ0UgYmFua3MKPiBBQ1BJOiBDb3JlIHJldmlzaW9uIDIwMTIwMzIwCj4gY3B1IDAg c3BpbmxvY2sgZXZlbnQgaXJxIDI5NQo+IFBlcmZvcm1hbmNlIEV2ZW50czogKFhFTikgdHJhcHMu YzoyNTYxOmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4 MDAwMGU0YTc1ZGY4NjUxNCB0byAweDAwMDAwMDAwMDAwMGFiY2QuCj4gQnJva2VuIFBNVSBoYXJk d2FyZSBkZXRlY3RlZCwgdXNpbmcgc29mdHdhcmUgZXZlbnRzIG9ubHkuCj4gTUNFOiBJbi1rZXJu ZWwgTUNFIGRlY29kaW5nIGVuYWJsZWQuCj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAx Cj4gY3B1IDEgc3BpbmxvY2sgZXZlbnQgaXJxIDMwMgo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv ciBDUFUgMgo+IGNwdSAyIHNwaW5sb2NrIGV2ZW50IGlycSAzMDkKPiBpbnN0YWxsaW5nIFhlbiB0 aW1lciBmb3IgQ1BVIDMKPiBjcHUgMyBzcGlubG9jayBldmVudCBpcnEgMzE2Cj4gaW5zdGFsbGlu ZyBYZW4gdGltZXIgZm9yIENQVSA0Cj4gY3B1IDQgc3BpbmxvY2sgZXZlbnQgaXJxIDMyMwo+IGlu c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgNQo+IGNwdSA1IHNwaW5sb2NrIGV2ZW50IGlycSAz MzAKPiBCcm91Z2h0IHVwIDYgQ1BVcwo+IGRldnRtcGZzOiBpbml0aWFsaXplZAo+IEdyYW50IHRh YmxlcyB1c2luZyB2ZXJzaW9uIDIgbGF5b3V0Lgo+IEdyYW50IHRhYmxlIGluaXRpYWxpemVkCj4g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgo+IFRPTTogMDAwMDAwMDBkMDAwMDAw MCBha2EgMzMyOE0KPiBUT00yOiAwMDAwMDAwMjMwMDAwMDAwIGFrYSA4OTYwTQo+IEFDUEk6IGJ1 cyB0eXBlIHBjaSByZWdpc3RlcmVkCj4gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1 cyAwMC1mZl0gYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDAp Cj4gUENJOiBub3QgdXNpbmcgTU1DT05GSUcKPiBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlw ZSAxIGZvciBiYXNlIGFjY2Vzcwo+IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9y IGV4dGVuZGVkIGFjY2Vzcwo+IGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCj4gQUNQSTog QWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERl dmljZSkKPiBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpCj4gQUNQSTogQWRk ZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpCj4gQUNQSTogRXhlY3V0ZWQgMyBi bG9ja3Mgb2YgbW9kdWxlLWxldmVsIGV4ZWN1dGFibGUgQU1MIGNvZGUKPiBBQ1BJOiBJbnRlcnBy ZXRlciBlbmFibGVkCj4gQUNQSTogKHN1cHBvcnRzIFMwIFM1KQo+IEFDUEk6IFVzaW5nIElPQVBJ QyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKPiBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBb YnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAw MCkKPiBQQ0k6IE1NQ09ORklHIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZl ZCBpbiBBQ1BJIG1vdGhlcmJvYXJkIHJlc291cmNlcwo+IEFDUEk6IEVDOiBHUEUgPSAweGEsIEkv TzogY29tbWFuZC9zdGF0dXMgPSAweDY2LCBkYXRhID0gMHg2Mgo+IFBDSTogVXNpbmcgaG9zdCBi cmlkZ2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFu ZCByZXBvcnQgYSBidWcKPiBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAw MCBbYnVzIDAwLWZmXSkKPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cg W2lvICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdp bmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk Z2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6 MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lf cm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZm ZmZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhm MDAwMDAwMC0weGZlYmZmZmZmXQo+IFBDSSBob3N0IGJyaWRnZSB0byBidXMgMDAwMDowMAo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDAwMDAtMHgwY2Y3XQo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZm ZmZdCj4gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4MDAwZDAwMDAt MHgwMDBkZmZmZl0KPiBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhj ZmYwMDAwMC0weGRmZmZmZmZmXQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2Ug W21lbSAweGYwMDAwMDAwLTB4ZmViZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA3LTA3XQo+IHBjaSAwMDAwOjA2OjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHBy ZS0xLjEgUENJZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9y Y2UnCj4gcGNpIDAwMDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQo+IHBjaSAw MDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wNV0KPiBwY2kgMDAwMDowMDowNi4w OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRn ZSB0byBbYnVzIDAzLTAzXQo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw Mi0wMl0KPiBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdIChzdWJ0 cmFjdGl2ZSBkZWNvZGUpCj4gIHBjaTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRy b2wgKDB4MWQpCj4gIHBjaTAwMDA6MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVk Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDowMC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDowNS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDowNy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDow ZC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDoxMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40Cj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNC41Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4w Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxOC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDoxOC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40Cj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowNzowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzow MC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowNjowMC4xCj4gcGNpIDAwMDA6MDY6MDAuMTogRmFpbGVkIHRvIGFkZCAtIHBh c3N0aHJvdWdoIG9yIE1TSS9NU0ktWCBtaWdodCBmYWlsIQo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDU6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDI6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDI6MDAuMQo+IEFDUEk6IFBDSSBJ bnRlcnJ1cHQgTGluayBbTE5LQV0gKElSUXMgKjQgNyAxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJ IEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBD SSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQ Q0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFzIDQgKjcgMTAgMTEgMTQgMTUpCj4gQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFzIDQgNyAxMCAxMSAxNCAxNSkgKjAsIGRp c2FibGVkLgo+IHhlbi9iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4geGVu LWJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KPiB2Z2FhcmI6IGRldmljZSBh ZGRlZDogUENJOjAwMDA6MDc6MDAuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1u b25lCj4gdmdhYXJiOiBsb2FkZWQKPiB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAw MDA6MDc6MDAuMAo+IFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkCj4gdXNiY29yZTogcmVnaXN0 ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcwo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgaHViCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRy aXZlciB1c2IKPiBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nCj4gU3dpdGNoaW5nIHRv IGNsb2Nrc291cmNlIHhlbgo+IEZTLUNhY2hlOiBMb2FkZWQKPiBDYWNoZUZpbGVzOiBMb2FkZWQK PiBwbnA6IFBuUCBBQ1BJIGluaXQKPiBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZAo+IHN5 c3RlbSAwMDowMTogW21lbSAweGZlYzIwMDAwLTB4ZmVjMjAwZmZdIGNvdWxkIG5vdCBiZSByZXNl cnZlZAo+IHN5c3RlbSAwMDowMjogW21lbSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdIGhhcyBiZWVu IHJlc2VydmVkCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBnc2kgOAo+ IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwo+IHN5c3RlbSAw MDowODogW21lbSAweGZlYzAwMDAwLTB4ZmVjMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+ IHN5c3RlbSAwMDowODogW21lbSAweGZlZTAwMDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwNGQ2XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjMDAtMHgwYzAxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAw eDBjMTRdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1MC0weDBj NTFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1Ml0gaGFzIGJl ZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNlcnZl ZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVt IDAwOjA5OiBbaW8gIDB4MGNkMC0weDBjZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAw OjA5OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5 OiBbaW8gIDB4MGNkNC0weDBjZDVdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBb aW8gIDB4MGNkNi0weDBjZDddIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MGNkOC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4 MDgwMC0weDA4OWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIw MC0weDBiMWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIyMC0w eDBiM2ZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkwMC0weDA5 MGZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkxMC0weDA5MWZd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZm Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZmI4MDAwMC0weGZm YmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlYzEwMDAw LTB4ZmVjMTAwMWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVk ODAwMDAtMHhmZWQ4MGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAg MHgwMjMwLTB4MDIzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgw MjkwLTB4MDI5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwZjQw LTB4MGY0Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYTMwLTB4 MGEzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGI6IFttZW0gMHhlMDAwMDAwMC0w eGVmZmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMDAw MDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21l bSAweDAwMGMwMDAwLTB4MDAwY2ZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAw MDowYzogW21lbSAweDAwMGUwMDAwLTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+ IHN5c3RlbSAwMDowYzogW21lbSAweDAwMTAwMDAwLTB4Y2ZlZmZmZmZdIGNvdWxkIG5vdCBiZSBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweGZlYzAwMDAwLTB4ZmZmZmZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZAo+IHBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKPiBBQ1BJ OiBBQ1BJIGJ1cyB0eXBlIHBucCB1bnJlZ2lzdGVyZWQKPiBwY2liYWNrIDAwMDA6MDA6MTQuMjog c2VpemluZyBkZXZpY2UKPiBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4 ZmZmZmZmKSAtIGFib3J0aW5nLgo+IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1 cyAwNy0wN10KPiBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAt MHhlZmZmXQo+IHBjaSAwMDAwOjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAw MDAtMHhmZTlmZmZmZl0KPiBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw eGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0KPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kg YnJpZGdlIHRvIFtidXMgMDYtMDZdCj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93 IFtpbyAgMHhkMDAwLTB4ZGZmZl0KPiBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGZlODAwMDAwLTB4ZmU4ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA1LTA1XQo+IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g IDB4YzAwMC0weGNmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0g MHhmZTcwMDAwMC0weGZlN2ZmZmZmXQo+IHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8g W2J1cyAwNC0wNF0KPiBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIw MDAtMHhiZmZmXQo+IHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU2 MDAwMDAtMHhmZTZmZmZmZl0KPiBwY2kgMDAwMDowMDowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg MDMtMDNdCj4gcGNpIDAwMDA6MDA6MDcuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTUwMDAw MC0weGZlNWZmZmZmXQo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0w Ml0KPiBwY2kgMDAwMDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZm XQo+IHBjaSAwMDAwOjAwOjBkLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU0MDAwMDAtMHhm ZTRmZmZmZl0KPiBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdCj4g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MiBmb3IgZ3NpIDUyCj4gQWxyZWFkeSBz ZXR1cCB0aGUgR1NJIDo1Mgo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9y IGdzaSA1Mgo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDUzIGZvciBnc2kgNTMKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzCj4g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyCj4gSVAgcm91dGUgY2FjaGUgaGFzaCB0 YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKPiBUQ1AgZXN0YWJs aXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiAxMCwgNDE5NDMwNCBieXRl cykKPiBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3 NiBieXRlcykKPiBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDI2MjE0 NCBiaW5kIDY1NTM2KQo+IFRDUDogcmVubyByZWdpc3RlcmVkCj4gVURQIGhhc2ggdGFibGUgZW50 cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQo+IFVEUC1MaXRlIGhhc2ggdGFibGUg ZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBw cm90b2NvbCBmYW1pbHkgMQo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9y IGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBz ZXR1cCB0aGUgR1NJIDoxOAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9y IGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4g VW5wYWNraW5nIGluaXRyYW1mcy4uLgo+IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogNjM4NGsgZnJl ZWQKPiBtaWNyb2NvZGU6IENQVTA6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6 IENQVTE6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTI6IHBhdGNoX2xl dmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYK PiBtaWNyb2NvZGU6IENQVTQ6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQ VTU6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUg RHJpdmVyOiB2Mi4wMCA8dGlncmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEK PiBOVEZTIGRyaXZlciAyLjEuMzAgW0ZsYWdzOiBSL1ddLgo+IG1zZ21uaSBoYXMgYmVlbiBzZXQg dG8gMzg3MAo+IEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAw LjQgbG9hZGVkIChtYWpvciAyNTMpCj4gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZCAoZGVm YXVsdCkKPiBwY2llcG9ydCAwMDAwOjAwOjAyLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg UENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDc6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJv dWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6MDA6MDQuMDogU2lnbmFsaW5n IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA2OjAwLjA6IFNpZ25h bGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNjowMC4xOiBT aWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDow MDowNS4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAw MDA6MDU6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBj aWVwb3J0IDAwMDA6MDA6MDYuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVy cnVwdAo+IHBjaSAwMDAwOjA0OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBp bnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAwOjAwOjA3LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQ Q0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowMzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91 Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowZC4wOiBTaWduYWxpbmcg UE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDI6MDAuMDogU2lnbmFs aW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjAyOjAwLjE6IFNp Z25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2lfaG90cGx1ZzogUENJ IEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMg L2RldmljZXMvTE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwCj4g QUNQSTogUG93ZXIgQnV0dG9uIFtQV1JCXQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2Rldmlj ZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQxCj4gQUNQSTogUG93ZXIgQnV0 dG9uIFtQV1JGXQo+IEdIRVM6IEhFU1QgaXMgbm90IGVuYWJsZWQhCj4gRXZlbnQtY2hhbm5lbCBk ZXZpY2UgaW5zdGFsbGVkLgo+IHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kKPiBTZXJpYWw6 IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNhYmxlZAo+IDAwMDA6 MDI6MDAuMTogdHR5UzAgYXQgSS9PIDB4YTg4MCAoaXJxID0gNDEpIGlzIGEgU1QxNjY1MFYyCj4g aHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9DUlMKPiBOb24tdm9sYXRpbGUg bWVtb3J5IGRyaXZlciB2MS4zCj4gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIg MC45LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KPiBIYW5n Y2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLgo+IGxvb3A6IG1vZHVsZSBsb2FkZWQKPiBh aGNpIDAwMDA6MDA6MTEuMDogQUhDSSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMg MHgzZiBpbXBsIFNBVEEgbW9kZQo+IGFoY2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNx IHNudGYgaWxjayBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2kwIDogYWhjaQo+ IHNjc2kxIDogYWhjaQo+IHNjc2kyIDogYWhjaQo+IHNjc2kzIDogYWhjaQo+IHNjc2k0IDogYWhj aQo+IHNjc2k1IDogYWhjaQo+IGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhm ZTNmZTAwMCBwb3J0IDB4ZmUzZmUxMDAgaXJxIDE5Cj4gYXRhMzogU0FUQSBtYXggVURNQS8xMzMg YWJhciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTE4MCBpcnEgMTkKPiBhdGE0OiBTQVRB IG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMjAwIGlycSAx OQo+IGF0YTU6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4 ZmUzZmUyODAgaXJxIDE5Cj4gYXRhNjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZl M2ZlMDAwIHBvcnQgMHhmZTNmZTMwMCBpcnEgMTkKPiBhdGE3OiBTQVRBIG1heCBVRE1BLzEzMyBh YmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMzgwIGlycSAxOQo+IGFoY2kgMDAwMDow NjowMC4wOiBBSENJIDAwMDEuMDAwMCAzMiBzbG90cyAyIHBvcnRzIDMgR2JwcyAweDMgaW1wbCBT QVRBIG1vZGUKPiBhaGNpIDAwMDA6MDY6MDAuMDogZmxhZ3M6IDY0Yml0IG5jcSBwbSBsZWQgY2xv IHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2k2IDogYWhjaQo+IHNjc2k3IDogYWhjaQo+IGF0YTg6 IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTgxOTJAMHhmZThmZTAwMCBwb3J0IDB4ZmU4ZmUxMDAg aXJxIDQ0Cj4gYXRhOTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtODE5MkAweGZlOGZlMDAwIHBv cnQgMHhmZThmZTE4MCBpcnEgNDQKPiB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2 ZXIsIDEuNgo+IHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNv bW0uY29tPgo+IHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMzAKPiBza3kyIDAwMDA6MDQ6MDAuMDog WXVrb24tMiBPcHRpbWEgY2hpcCByZXZpc2lvbiAxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IGV0aDA6 IGFkZHIgMjA6Y2Y6MzA6NmQ6ODk6YTUKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIGNkY19uY20KPiBmaXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogYWRkZWQgT0hD SSB2MS4xMCBkZXZpY2UgYXMgY2FyZCAwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVpcmtzIDB4 MTEKPiBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkg RHJpdmVyCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4g QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogRUhDSSBI b3N0IENvbnRyb2xsZXIKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IG5ldyBVU0IgYnVzIHJlZ2lz dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBw bHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5k Cj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBkZWJ1ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAw OjEyLjI6IGlycSAxNywgaW8gbWVtIDB4ZmUzZmU0MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6 IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwCj4gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZv dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IxOiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2Ix OiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6 IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2Ix OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMgo+IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5k Cj4gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gZWhj aV9oY2QgMDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lfaGNkIDAwMDA6 MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyCj4g ZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIv MyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IGRlYnVn IHBvcnQgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0gMHhmZTNmZTgw MAo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKPiB1 c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0w MDAyCj4gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs IFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVy Cj4gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkw LWRpcnR5IGVoY2lfaGNkCj4gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yCj4g aHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3Rl ZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwo+IEFscmVh ZHkgc2V0dXAgdGhlIEdTSSA6MTcKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IEVIQ0kgSG9zdCBD b250cm9sbGVyCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVk LCBhc3NpZ25lZCBidXMgbnVtYmVyIDMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5aW5n IEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+IGF0 YTU6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGF0YTQ6IFNBVEEg bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGVoY2lfaGNkIDAwMDA6MDA6MTYu MjogZGVidWcgcG9ydCAxCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBpcnEgMTcsIGlvIG1lbSAw eGZlM2ZlYzAwCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kg MS4wMAo+IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQ cm9kdWN0PTAwMDIKPiB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKPiB1c2IgdXNiMzogUHJvZHVjdDogRUhDSSBIb3N0IENv bnRyb2xsZXIKPiB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjQuMC1yYzQtMDAzOTUt Zzg3YjVkOTAtZGlydHkgZWhjaV9oY2QKPiB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAw OjE2LjIKPiBhdGE4OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKPiBo dWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZAo+IGh1YiAzLTA6MS4wOiA0IHBvcnRzIGRldGVjdGVk Cj4gYXRhMjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDAp Cj4gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFk eSBzZXR1cCB0aGUgR1NJIDoxOAo+IG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogT0hDSSBIb3N0IENv bnRyb2xsZXIKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs IGFzc2lnbmVkIGJ1cyBudW1iZXIgNAo+IG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaXJxIDE4LCBp byBtZW0gMHhmZTNmNzAwMAo+IGF0YTk6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRy b2wgMzAwKQo+IGF0YTc6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+ IGF0YTM6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGF0YTIuMDA6 IEFUQS04OiBJTlRFTCBTU0RTQTJDVzEyMEczLCA0UEMxMDM2MiwgbWF4IFVETUEvMTMzCj4gYXRh Mi4wMDogMjM0NDQxNjQ4IHNlY3RvcnMsIG11bHRpIDE6IExCQTQ4IE5DUSAoZGVwdGggMzEvMzIp Cj4gYXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gdXNiIHVz YjQ6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+ IHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp YWxOdW1iZXI9MQo+IHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVz YiB1c2I0OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0 eSBvaGNpX2hjZAo+IHVzYiB1c2I0OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMAo+IGh1YiA0 LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4 ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNl dHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJv bGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz aWduZWQgYnVzIG51bWJlciA1Cj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1l bSAweGZlM2ZjMDAwCj4gYXRhMi4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKPiB1c2IgdXNi NTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4g dXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjU6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5 IG9oY2lfaGNkCj4gdXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4wCj4gc2NzaSAw OjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBJTlRFTCBTU0RTQTJDVzEyIDRQQzEg UFE6IDAgQU5TSTogNQo+IGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDUtMDoxLjA6 IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZv ciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDox NC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVT QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA2Cj4gb2hjaV9oY2QgMDAwMDow MDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZkMDAwCj4gdXNiIDEtMTogbmV3IGhpZ2gtc3Bl ZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNpX2hjZAo+IHNkIDA6MDowOjA6IFtzZGFd IDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEyMCBHQi8xMTEgR2lCKQo+IHNk IDA6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCj4gc2QgMDowOjA6MDogW3NkYV0g V3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9y dCBEUE8gb3IgRlVBCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0x ZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I2OiBQcm9kdWN0OiBPSENJ IEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJj NC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6 IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDYtMDoxLjA6 IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZv ciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDox Ni4wOiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogbmV3IFVT QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3Cj4gb2hjaV9oY2QgMDAwMDow MDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZmMDAwCj4gIHNkYTogc2RhMSBzZGEyCj4gc2Qg MDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrCj4gdXNiIHVzYjc6IE5ldyBVU0IgZGV2 aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I3OiBOZXcg VVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVz YiB1c2I3OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I3OiBNYW51ZmFj dHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVz YiB1c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMAo+IGZpcmV3aXJlX2NvcmUgMDAwMDow NTowMC4wOiBjcmVhdGVkIGRldmljZSBmdzA6IEdVSUQgMDAxZThjMDAwMGRlOTEzNiwgUzQwMAo+ IGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0ZWN0 ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUwIGZvciBnc2kgNTAKPiBBbHJl YWR5IHNldHVwIHRoZSBHU0kgOjUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl ZCwgYXNzaWduZWQgYnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAs IGlvIG1lbSAweGZlNWZlMDAwCj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu ZG9yPTA0MjQsIGlkUHJvZHVjdD0yNTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5n czogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKPiB1c2IgdXNiODogTmV3IFVTQiBk ZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyCj4gdXNiIHVzYjg6IE5l dyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4g dXNiIHVzYjg6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gaHViIDEtMToxLjA6IFVT QiBodWIgZm91bmQKPiB1c2IgdXNiODogTWFudWZhY3R1cmVyOiBMaW51eCAzLjQuMC1yYzQtMDAz OTUtZzg3YjVkOTAtZGlydHkgeGhjaV9oY2QKPiB1c2IgdXNiODogU2VyaWFsTnVtYmVyOiAwMDAw OjAzOjAwLjAKPiBodWIgMS0xOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+IGh1YiA4LTA6MS4wOiBV U0IgaHViIGZvdW5kCj4gaHViIDgtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAw MDAwOjAzOjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4geGhjaV9oY2QgMDAwMDowMzowMC4w OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNi OTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4g dXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjk6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjk6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5 IHhoY2lfaGNkCj4gdXNiIHVzYjk6IFNlcmlhbE51bWJlcjogMDAwMDowMzowMC4wCj4gaHViIDkt MDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgOS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZAo+IHVz YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHAKPiB1c2Jjb3JlOiBy ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVhcwo+IEluaXRpYWxpemluZyBVU0IgTWFz cyBTdG9yYWdlIGRyaXZlci4uLgo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNiLXN0b3JhZ2UKPiBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4K PiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNi Y29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1bXNfZW5ldWI2MjUwCj4gaTgw NDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5 Lgo+IHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKPiBzZXJpbzogaTgw NDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgo+IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRl dmljZSBjb21tb24gZm9yIGFsbCBtaWNlCj4gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMv cGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0Mgo+IHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdh a2UgZnJvbSBTNAo+IHJ0Y19jbW9zIDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21v cyBhcyBydGMwCj4gcnRjMDogYWxhcm1zIHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMg bnZyYW0KPiBpMmMgL2RldiBlbnRyaWVzIGRyaXZlcgo+IEFDUEkgV2FybmluZzogMHgwMDAwMDAw MDAwMDAwYjAwLTB4MDAwMDAwMDAwMDAwMGIwNyBTeXN0ZW1JTyBjb25mbGljdHMgd2l0aCBSZWdp b24gXF9TQl8uUENJMC5TQlJHLkFTT0MuU01SRyAxICgyMDEyMDMyMC91dGFkZHJlc3MtMjUxKQo+ IEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlv dSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXIKPiBBVEswMTEwIEFU SzAxMTA6MDA6IEVDIGVuYWJsZWQKPiBzcDUxMDBfdGNvOiBTUDUxMDAgVENPIFdhdGNoRG9nIFRp bWVyIERyaXZlciB2MC4wMQo+IHNwNTEwMF90Y286IG1taW8gYWRkcmVzcyAweGI4ZmUwMCBhbHJl YWR5IGluIHVzZQo+IGl0ODdfd2R0OiBDaGlwIElUODcyMSByZXZpc2lvbiAxIGluaXRpYWxpemVk LiB0aW1lb3V0PTYwIHNlYyAobm93YXlvdXQ9MCB0ZXN0bW9kZT0wIGV4Y2x1c2l2ZT0xIG5vZ2Ft ZXBvcnQ9MCkKPiB4ZW5fd2R0OiBYZW4gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAxCj4geGVu X3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYgb24gbWlub3I9MTMwICgtMTYpCj4gd2R0OiBw cm9iZSBvZiB3ZHQgZmFpbGVkIHdpdGggZXJyb3IgLTE2Cj4gZGV2aWNlLW1hcHBlcjogdWV2ZW50 OiB2ZXJzaW9uIDEuMC4zCj4gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuMC1pb2N0bCAoMjAx MS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KPiBFREFDIE1DOiBWZXI6 IDIuMS4wCj4gQU1ENjQgRURBQyBkcml2ZXIgdjMuNC4wCj4gRURBQyBhbWQ2NDogRFJBTSBFQ0Mg ZGlzYWJsZWQuCj4gRURBQyBhbWQ2NDogRUNDIGRpc2FibGVkIGluIHRoZSBCSU9TIG9yIG5vIEVD QyBjYXBhYmlsaXR5LCBtb2R1bGUgd2lsbCBub3QgbG9hZC4KPiAgRWl0aGVyIGVuYWJsZSBFQ0Mg Y2hlY2tpbmcgb3IgZm9yY2UgbW9kdWxlIGxvYWRpbmcgYnkgc2V0dGluZyAnZWNjX2VuYWJsZV9v dmVycmlkZScuCj4gIChOb3RlIHRoYXQgdXNlIG9mIHRoZSBvdmVycmlkZSBtYXkgY2F1c2UgdW5r bm93biBzaWRlIGVmZmVjdHMuKQo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNiaGlkCj4gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyCj4gVENQOiBjdWJpYyBy ZWdpc3RlcmVkCj4gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwo+IHJ0Y19jbW9z IDAwOjA0OiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDEyLTA1LTA3IDExOjE5OjEwIFVUQyAo MTMzNjM4OTU1MCkKPiBwb3dlcm5vdy1rODogRm91bmQgMSBBTUQgUGhlbm9tKHRtKSBJSSBYNiAx MDc1VCBQcm9jZXNzb3IgKDYgY3B1IGNvcmVzKSAodmVyc2lvbiAyLjIwLjAwKQo+IHBvd2Vybm93 LWs4OiBDb3JlIFBlcmZvcm1hbmNlIEJvb3N0aW5nOiBvbi4KPiBGcmVlaW5nIHVudXNlZCBrZXJu ZWwgbWVtb3J5OiA1MzJrIGZyZWVkCj4gTG9hZGluZywgcGxlYXNlIHdhaXQuLi4KPiB1ZGV2WzEw NzhdOiBzdGFydGluZyB2ZXJzaW9uIDE2NAo+IHVzYiA0LTI6IG5ldyBmdWxsLXNwZWVkIFVTQiBk ZXZpY2UgbnVtYmVyIDIgdXNpbmcgb2hjaV9oY2QKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBm b3VuZCwgaWRWZW5kb3I9MDQxZSwgaWRQcm9kdWN0PTMwZGMKPiB1c2IgNC0yOiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9Mwo+IHVzYiA0LTI6 IFByb2R1Y3Q6IFNvdW5kIEJsYXN0ZXIgVGFjdGljKDNEKSBBbHBoYQo+IHVzYiA0LTI6IE1hbnVm YWN0dXJlcjogQ3JlYXRpdmUgVGVjaG5vbG9neSBMdGQKPiB1c2IgNC0yOiBTZXJpYWxOdW1iZXI6 IDAwMDIzMTYyCj4gaW5wdXQ6IENyZWF0aXZlIFRlY2hub2xvZ3kgTHRkIFNvdW5kIEJsYXN0ZXIg VGFjdGljKDNEKSBBbHBoYSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMC91c2I0 LzQtMi80LTI6MS4zL2lucHV0L2lucHV0Mwo+IGdlbmVyaWMtdXNiIDAwMDM6MDQxRTozMERDLjAw MDE6IGlucHV0LGhpZGRldjA6IFVTQiBISUQgdjEuMDAgRGV2aWNlIFtDcmVhdGl2ZSBUZWNobm9s b2d5IEx0ZCBTb3VuZCBCbGFzdGVyIFRhY3RpYygzRCkgQWxwaGFdIG9uIHVzYi0wMDAwOjAwOjEy LjAtMi9pbnB1dDMKPiB1c2IgMS0xLjE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVy IDQgdXNpbmcgZWhjaV9oY2QKPiBCZWdpbjogTG9hZGluZyBlc3NlbnRpYWwgZHJpdmVycyAuLi4g ZG9uZS4KPiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLgo+ IEJlZ2luOiBNb3VudGluZyByb290IGZpbGUgc3lzdGVtIC4uLiBCZWdpbjogUnVubmluZyAvc2Ny aXB0cy9sb2NhbC10b3AgLi4uIHVzYiAxLTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu ZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDEzCj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVj dDogUmF6ZXIgT3JvY2hpCj4gdXNiIDEtMS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gaW5wdXQ6 IFJhemVyIFJhemVyIE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91 c2IxLzEtMS8xLTEuMS8xLTEuMToxLjAvaW5wdXQvaW5wdXQ0Cj4gZ2VuZXJpYy11c2IgMDAwMzox NTMyOjAwMTMuMDAwMjogaW5wdXQ6IFVTQiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE9y b2NoaV0gb24gdXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5wdXQwCj4gaW5wdXQ6IFJhemVyIFJhemVy IE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEu MS8xLTEuMToxLjEvaW5wdXQvaW5wdXQ1Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAw MzogaW5wdXQ6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW1JhemVyIFJhemVyIE9yb2NoaV0gb24g dXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5wdXQxCj4gZG9uZS4KPiBCZWdpbjogUnVubmluZyAvc2Ny aXB0cy9sb2NhbC1wcmVtb3VudCAuLi4gZG9uZS4KPiB1c2IgMS0xLjI6IG5ldyBsb3ctc3BlZWQg VVNCIGRldmljZSBudW1iZXIgNSB1c2luZyBlaGNpX2hjZAo+IEVYVDQtZnMgKGRtLTApOiBtb3Vu dGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpCj4gQmVn aW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtYm90dG9tIC4uLiBkb25lLgo+IGRvbmUuCj4gQmVn aW46IFJ1bm5pbmcgL3NjcmlwdHMvaW5pdC1ib3R0b20gLi4uIGRvbmUuCj4gdXNiIDEtMS4yOiBO ZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDRmMiwgaWRQcm9kdWN0PTA0MDMKPiB1c2Ig MS0xLjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51 bWJlcj0wCj4gdXNiIDEtMS4yOiBQcm9kdWN0OiBVU0IgS2V5Ym9hcmQKPiB1c2IgMS0xLjI6IE1h bnVmYWN0dXJlcjogQ2hpY29ueQo+IGlucHV0OiBDaGljb255IFVTQiBLZXlib2FyZCBhcyAvZGV2 aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8xLTEuMjoxLjAvaW5w dXQvaW5wdXQ2Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNDogaW5wdXQ6IFVTQiBI SUQgdjEuMTEgS2V5Ym9hcmQgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDox Mi4yLTEuMi9pbnB1dDAKPiBJTklUOiB2ZXJzaW9uIDIuODggYm9vdGluZwo+IGlucHV0OiBDaGlj b255IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2Ix LzEtMS8xLTEuMi8xLTEuMjoxLjEvaW5wdXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYy OjA0MDMuMDAwNTogaW5wdXQsaGlkZGV2MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkg VVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDEKPiBVc2luZyBtYWtl ZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy5uZXQgZmlyZXdpcmUwOiBJ Cj4gUHY0IG92ZXIgSUVFRSAxMzk0IG9uIGNhcmQgMDAwMDowNTowMC4wCj4gZmlyZXdpcmVfY29y ZSAwMDAwOjA1OjAwLjA6IHJlZnJlc2hlZCBkZXZpY2UgZncwCj4gRmlsZXMgdW5kZXIgbW91bnQg cG9pbnQgJy9saWIvaW5pdC9ydycgd2lsbCBiZSBoaWRkZW4uIC4uLiAod2FybmluZykuCj4gRmls ZXMgdW5kZXIgbW91bnQgcG9pbnQgJy92YXIvcnVuJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJu aW5nKS4KPiBGaWxlcyB1bmRlciBtb3VudCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRl bi4gLi4uICh3YXJuaW5nKS4KPiBTdGFydGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hl cjogdWRldmR1ZGV2WzEzMDJdOiBzdGFydGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXpp bmcgdGhlIGluaXRpYWwgaG90cGx1ZyBldmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYg dG8gYmUgZnVsbHkgcG9wdWxhdGVkLi4uZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4n Li4uZG9uZS4KPiBTZXR0aW5nIHByZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGlu ZyBzd2FwOi4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2ls bCBub3cgY2hlY2sgcm9vdCBmaWxlIHN5c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3 LjIKPiBbL3NiaW4vZnNjay5leHQ0ICgxKSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFw cGVyL2xlbXJvdWNoLXhlbiAKPiAvZGV2L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzY2 MTcvMTMxMDcyMCBmaWxlcywgMTI4MDU2Mi81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChk bS0wKTogcmUtbW91bnRlZC4gT3B0czogZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5l bCBtb2R1bGUgZmlyZXdpcmUtc2JwMi4KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBD bGVhbmluZyB1cCBpZnVwZG93bi4uLi4KPiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0 dGluZyB1cCBMVk0gVm9sdW1lIEdyb3VwcyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4g IFRoaXMgbWF5IHRha2UgYSB3aGlsZS4uLgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3Vj aCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBsdm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZv bHVtZSBncm91cCAibGVtcm91Y2giIG5vdyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUg bHZtIGFuZCBtZCBzd2FwOmRvbmUuCj4gV2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4K PiBmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0 ZW1zLgo+IERvbmUgY2hlY2tpbmcgZmlsZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBp biAvdmFyL2xvZy9mc2NrL2NoZWNrZnMgaWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4g V2lsbCBub3cgbW91bnQgbG9jYWwgZmlsZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6 IG1vdW50aW5nIHVuY2hlY2tlZCBmcywgcnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBF WFQ0LWZzIChzZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUu IE9wdHM6IChudWxsKQo+IC4KPiBXaWxsIG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUu Cj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4g Lgo+IENoZWNraW5nIG1pbmltdW0gc3BhY2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJu ZWwgdmFyaWFibGVzIC4uLiAvZXRjL3N5c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcg cmFuZG9tIG51bWJlciBnZW5lcmF0b3IuLi5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29j a2V0IGRpcmVjdG9yeSAvdG1wLy5YMTEtdW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQg ZGlyZWN0b3J5IC90bXAvLklDRS11bml4Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJm YWNlcy4uLmRldmljZSBldGgwIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDow NDowMC4wOiBldGgwOiBlbmFibGluZyBpbnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRl bXBvcmFyeSBmaWxlcy4uLi4KPiBTdGFydGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVz ZS4KPiBTZXR0aW5nIGNvbnNvbGUgc2NyZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vy c2F2ZSBtb2RlCj4gU2tpcHBpbmcgZm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNv bnNvbGUtc2V0dXApLgo+IFNldHRpbmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25l Lgo+IFNldHRpbmcgc2Vuc29ycyBsaW1pdHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMK PiBVc2luZyBtYWtlZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBO b3Qgc3RhcnRpbmcgZmFuY29udHJvbDsgcnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5n KS4KPiBhY3BpZDogc3RhcnRpbmcgdXAgd2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIK PiAKPiBhY3BpZDogMSBydWxlIGxvYWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6 IGV2ZW50IGxvZ2dpbmcgaXMgb2ZmCj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBT dGFydGluZyBzeXN0ZW0gbWVzc2FnZSBidXM6IGRidXMuCj4gc3NoZCAoMjA4NCk6IC9wcm9jLzIw ODQvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzIwODQvb29tX3Njb3Jl X2FkaiBpbnN0ZWFkLgo+IFN0YXJ0aW5nIHRoZSBXaW5iaW5kIGRhZW1vbjogd2luYmluZC4KPiBT dGFydGluZyBPcGVuQlNEIFNlY3VyZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgZG9t YWluIG5hbWUgc2VydmljZS4uLjogYmluZDkuCj4gU3RhcnRpbmcgb3hlbnN0b3JlZC4uLgo+IFNl dHRpbmcgZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4gU3RhcnRp bmcgU2FtYmEgZGFlbW9uczogbm1iZCBzbWJkLgo+IFN0YXJ0aW5nIHBlcmlvZGljIGNvbW1hbmQg c2NoZWR1bGVyOiBjcm9uLgo+IFN0YXJ0aW5nIFBvc3RmaXggTWFpbCBUcmFuc3BvcnQgQWdlbnQ6 IHBvc3RmaXguCj4gQkxLVEFQQ1RSTFsyMjUzXTogYmxrdGFwY3RybC5jOjc5MjogYmxrdGFwY3Ry bDogdjEuMC4wCj4gCj4gQkxLVEFQQ1RSTFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQg ZHJpdmVyOiBbcmF3IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0 cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RS TFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2 bWRrKV0KPiAKPiBCTEtUQVBDVFJMWzIyNTNdOiBibGt0YXBjdHJsLmM6Nzk0OiBGb3VuZCBkcml2 ZXI6IFtyYW1kaXNrIGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0 cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RS TFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNv dzIpXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFw MCBvcGVuIGZhaWxlZAo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0cmwuYzo4NjE6IGNv dWxkbid0IG9wZW4gYmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3Rh cGN0cmwuYzo5MjQ6IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4gCj4gc2t5MiAwMDAwOjA0 OjAwLjA6IGV0aDA6IExpbmsgaXMgdXAgYXQgMTAwIE1icHMsIGZ1bGwgZHVwbGV4LCBmbG93IGNv bnRyb2wgYm90aAo+IGJyMDogcG9ydCAxKGV0aDApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+ IGJyMDogcG9ydCAxKGV0aDApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IFN0YXJ0aW5nIFMu TS5BLlIuVC4gZGFlbW9uOiBzbWFydGQuCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJlZCBmb3J3 YXJkaW5nIHN0YXRlCj4gUnVubmluZyBsb2NhbCBib290IHNjcmlwdHMgKC9ldGMvcmMubG9jYWwp KFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMi4yCj4gYWNwaWQ6IGlucHV0IGRldmlj ZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVu IGRpc2Nvbm5lY3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVj dGVkCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJ IHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4g ZGlzY29ubmVjdGVkCj4gCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0 ZWQKPiAKPiAoWEVOKSBpb3BvcnRfbWFwOmFkZDogZG9tMSBncG9ydD0zYjAgbXBvcnQ9M2IwIG5y PWMKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49YTAgbWZuPWEwIG5yPTIwCj4gKFhF TikgaW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2MwIG1wb3J0PTNjMCBucj0zCj4gKFhFTikg aW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2M0IG1wb3J0PTNjNCBucj0xYwo+IChYRU4pIEhW TTE6IEhWTSBMb2FkZXIKPiAoWEVOKSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMi11bnN0YWJsZQo+ IChYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA4Cj4g KFhFTikgSFZNMTogU3lzdGVtIHJlcXVlc3RlZCBST01CSU9TCj4gKFhFTikgSFZNMTogQ1BVIHNw ZWVkIGlzIDMwMTAgTUh6Cj4gKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdl ZCAwIC0+IDUKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQo+IChY RU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAo+IChYRU4pIEhW TTE6IFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAo+IChYRU4pIGlycS5jOjI3MDogRG9t MSBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAy IHJvdXRlZCB0byBJUlExMQo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5n ZWQgMCAtPiA1Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2 IDAzOjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1Cj4g KFhFTikgSFZNMTogcGNpIGRldiAwNTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRl diAwNjowIElOVEItPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgSU5UQS0+SVJRNQo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDg6MCBJTlRCLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBk ZXYgMDk6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6 ZSAxMDAwMDAwMDogZTAwMDAwMGMKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAw MDAgbWZuPWQwMDAwIG5yPTEwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBz aXplIDAxMDAwMDAwOiBmMDAwMDAwOAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTAg c2l6ZSAwMDAyMDAwMDogZjEwMDAwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49 ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBz aXplIDAwMDIwMDAwOiBmMTAyMDAwNAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAg c2l6ZSAwMDAyMDAwMDogZjEwNDAwMDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEw IHNpemUgMDAwMDQwMDA6IGYxMDYwMDA0Cj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2Zu PWYxMDYwIG1mbj1mZTliYyBucj00Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwOTowIGJhciAxMCBz aXplIDAwMDA0MDAwOiBmMTA2NDAwNAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1m MTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAgc2l6 ZSAwMDAwMTAwMDogZjEwNjgwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEw NjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUg MDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY5 IG1mbj1mMDAwMCBucj0xCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAw MDAwMTAwOiAwMDAwYzAwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMjAgc2l6ZSAw MDAwMDEwMDogMDAwMGMxMDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUg MDAwMDAwNDA6IDAwMDBjMjAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXpl IDAwMDAwMDEwOiAwMDAwYzI0MQo+IChYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxp c2F0aW9uOgo+IChYRU4pIEhWTTE6ICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBN VFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTEg Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBk b25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJS cyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTMgLi4u IDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25l Lgo+IChYRU4pIEhWTTE6ICAtIENQVTQgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAu Li4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTUgLi4uIDQ4 LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+ IChYRU4pIEhWTTE6IFRlc3RpbmcgSFZNIGVudmlyb25tZW50Ogo+IChYRU4pIEhWTTE6ICAtIFJF UCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6ICAt IEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiBQYXNzZWQg MiBvZiAyIHRlc3RzCj4gKFhFTikgSFZNMTogV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgo+IChY RU4pIEhWTTE6IExvYWRpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiA5NjYwIGJ5dGVzIG9m IFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoKPiAoWEVOKSBIVk0xOiAgIFJlbG9jYXRp bmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJjIC4uLiBkb25lCj4gKFhFTikgSFZNMTogQ3JlYXRp bmcgTVAgdGFibGVzIC4uLgo+IChYRU4pIEhWTTE6IExvYWRpbmcgVkdBQklPUyBvZiBwYXNzdGhy b3VnaGVkIGdmeCAuLi4KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLgo+ IChYRU4pIEhWTTE6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnCj4gKFhFTikgSFZN MTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFCj4gKFhFTikgSFZNMTogT3B0aW9uIFJPTXM6Cj4gKFhF TikgSFZNMTogIGMwMDAwLWNmZmZmOiBWR0EgQklPUwo+IChYRU4pIEhWTTE6ICBkMDAwMC1lMGZm ZjogRXRoZXJib290IFJPTQo+IChYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBI Vk0xOiB2bTg2IFRTUyBhdCBmYzAwZjcwMAo+IChYRU4pIEhWTTE6IEJJT1MgbWFwOgo+IChYRU4p IEhWTTE6ICBmMDAwMC1mZmZmZjogTWFpbiBCSU9TCj4gKFhFTikgSFZNMTogRTgyMCB0YWJsZToK PiAoWEVOKSBIVk0xOiAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAw MDogUkFNCj4gKFhFTikgSFZNMTogIFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6 MDAwYTAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAw IC0gMDAwMDAwMDA6MDAwZTAwMDAKPiAoWEVOKSBIVk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwZTAw MDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzAzXTogMDAw MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDplMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogIEhP TEU6IDAwMDAwMDAwOmUwMDAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKPiAoWEVOKSBIVk0xOiAg WzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKPiAo WEVOKSBIVk0xOiAgWzA1XTogMDAwMDAwMDE6MDAwMDAwMDAgLSAwMDAwMDAwMToyMDAwMDAwMDog UkFNCj4gKFhFTikgSFZNMTogSW52b2tpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiAkUmV2 aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6 IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkKPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEu MjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IE9wdGlvbnM6 IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0byBQTU0gCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZN MTogYXRhMC0wOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1 LzYzCj4gKFhFTikgSFZNMTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1E aXNrICgyMDQ4MCBNQnl0ZXMpCj4gKFhFTikgSFZNMTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2LzYz IHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRhMCAgc2xh dmU6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwMCBNQnl0ZXMpCj4gKFhFTikg SFZNMTogCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogUHJlc3Mg RjEyIGZvciBib290IG1lbnUuCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogQm9vdGluZyBm cm9tIEhhcmQgRGlzay4uLgo+IChYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKPiAo WEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIGly cS5jOjI3MDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMTAgLT4gMAo+IChYRU4pIGlycS5jOjI3 MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9t MSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCj4gKFhFTikgbWVtb3J5X21hcDpyZW1vdmU6IGRv bTEgZ2ZuPWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3Zl OiBkb20xIGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDog ZG9tMSBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yPTEwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6 IGRvbTEgZ2ZuPWYxMDIwIG1mbj1mZTllMCBucj0yMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3Zl OiBkb20xIGdmbj1mMTA2MCBtZm49ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBk b20xIGdmbj1mMTA2MCBtZm49ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBk b20xIGdmbj1mMTA2OCBtZm49ZmUzZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20x IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x IGdmbj1mMTA2OSBtZm49ZjAwMDAgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdm bj1mMTA2OSBtZm49ZjAwMDAgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdm bj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1m MTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIGdyYW50X3RhYmxlLmM6MTE3NDpkMSBFeHBhbmRp bmcgZG9tICgxKSBncmFudCB0YWJsZSBmcm9tICg0KSB0byAoMzIpIGZyYW1lcy4KPiAoWEVOKSBp cnEuYzozNTA6IERvbTEgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gR1NJIDI4Cj4gKFhFTikgRG9t YWluIDAgY3Jhc2hlZDogcmVib290aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgoKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWls aW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3Jn L3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Mon May 07 17:38:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 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 ) id 1SRRsY-0004u6-KY; Mon, 07 May 2012 17:37:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRsW-0004tu-Cy for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:37:45 +0000 Received: from [85.158.138.51:9287] by server-7.bemta-3.messagelabs.com id 73/E3-03078-76808AF4; Mon, 07 May 2012 17:37:43 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336412259!25760654!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4796 invoked from network); 7 May 2012 17:37:41 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:37:41 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47Hbacf004479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:37: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 q47HbY61016744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:37:35 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 q47HbYw2027426; Mon, 7 May 2012 12:37:34 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:37:32 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 724C74031D; Mon, 7 May 2012 13:31:44 -0400 (EDT) Date: Mon, 7 May 2012 13:31:44 -0400 From: Konrad Rzeszutek Wilk To: Pavel =?utf-8?Q?Mat=C4=9Bja?= Message-ID: <20120507173144.GB17704@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201205071345.23619.pavel@netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gTW9uLCBNYXkgMDcsIDIwMTIgYXQgMDE6NDU6MjNQTSArMDIwMCwgUGF2ZWwgTWF0xJtqYSB3 cm90ZToKPiBIaSwKPiBJJ20gdHJ5aW5nIHRvIHJ1biBBTUQgVkdBIHBhc3N0aHJ1IG9uIGxhdGVz dCBYRU4gdW5zdGFibGUgd2l0aCBsYXRlc3Qga2VybmVsLgo+IEkgYWxyZWFkeSBoYXZlIHdvcmtp bmcgc2V0dXAgd2l0aCBhbmNpZW50IHhlbi1kZXZlbCA0LjIgYW5kIDIuNi4zMi54IHhlbmlmaWVk IAo+IGtlcm5lbC4gU2VlIGF0dGFjaGVkIGxvZy4KPiAKPiBTbyBJIHRyaWVkIGp1c3QgdG8gdXBk YXRlIGFuZCBwYXRjaCB4ZW4gYW5kIGtlcm5lbCwgYnV0IEkgaGFkIG5vIGx1Y2sgc28gZmFyLgo+ IAo+IFhlbiBoYXMgYXRpX3ZiaW9zX3BhdGNoX3Jlc3Bpbi50eHQgc2VudCB0byB4ZW4tZGV2ZWwg YnkgV2VpIEh1YW5nIHJlY2VudGx5Lgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0 bWwveGVuLWRldmVsLzIwMTItMDQvbXNnMDAyOTEuaHRtbAo+IAo+IEkgdHJpZWQgdHdvIGtlcm5l bHMgCj4gdGVzdGluZy0zLjUtd2l0aC1leHRyYSBhbmQgeGVuL25leHQtMy4yIGZyb20KPiBnaXQ6 Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQva29ucmFkL3hlbi5naXQK PiBhbmQKPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvamVy ZW15L3hlbi5naXQKPiBCb3RoIHdpdGggaW9wZXJtIG9wY29kZSBwYXRjaCB3aGljaCBpcyByZXF1 aXJlZCBieSB0aGUgQVRJIHBhdGNoLiBTZWUgCj4gYXR0YWNoZW1lbnQuCj4gCj4gVGhlIHhlbi9u ZXh0LTMuMiBicmFuY2gga2VybmVsIHdhcyBhYmxlIHRvIHN0YXJ0IGJvb3Rpbmcgd2luZG93cy4K PiBXaXRoIENhdGFseXN0IGRyaXZlciBpbnN0YWxsZWQgSSBqdXN0IHNhdyBibHVlc2NyZWVuIGR1 cmluZyBXaW5kb3dzIGJvb3QuCj4gV2l0aG91dCBDYXRhbHlzdCBkcml2ZXIgV2luZG93cyB3ZXJl IGFibGUgdG8gYm9vdCBidXQgV2luZG93cyBlbmRlZCBmcm96ZW4gb3IgCj4gVVNCIHdhcyBub3Qg d29ya2luZy4gSXQgd2FzIGhhcmQgdG8gdGVsbCBiZWNhdXNlIGlucHV0IGRldmljZXMgaGFkIG5v IHJlc3BvbnNlIAo+IGF0IGFsbC4KPiAKPiBUaGUgdGVzdGluZy0zLjUtd2l0aC1leHRyYSAocmVw b3J0ZWQgYXMgMy40LjAtcmM0KSBqdXN0IGNyYXNoZWQgZG9tMCBrZXJuZWwgCj4gZHVyaW5nIFdp bmRvd3MgYm9vdC4gSSBndWVzcyBJIGhhdmUgdG8gcmV3b3JrIHRoZSBpb19iaXRtYXAgcGF0Y2gg c29tZWhvdy4KCldoZW4geW91IHNheSAnaW9fYml0bWFwJyBwYXRjaCBhcmUgeW91IHJlZmVycmlu ZyB0byB0aGVzZSBvbmVzOgoKNzBhMzU3ZCB4ZW46IGltcGxlbWVudCBJTyBwZXJtaXNzaW9uIGJp dG1hcAowYzU5NmM1IHg4Ni9wYXJhdmlydDogcGFyYXZpcnR1YWxpemUgSU8gcGVybWlzc2lvbiBi aXRtYXAKOTNiN2EyYSB4ODY6IGRlbWFjcm8gc2V0X2lvcGxfbWFzaygpCgo/IEkgZG9uJ3QgdGhp bmsgdGhvc2UgYXJlIGluIHRoYXQgdGFnLiBUaGV5IGFyZSBpbiB0aGUga2l0Y2hlbnNpbmsgLSAj dGVzdGluZwotIGRvZXMgaXQgd29yayB3aXRoIHRoYXQgYnJhbmNoPwoKVGhlIG5leHQtMy4yIGlz IGEgYml0IG9sZC4gSSBzaG91bGQgYWN0dWFsbHkgZGVsZXRlIGl0LgoKPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEBuZXRzYWZlLmN6KSAo Z2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApIFN1biBGZWIgIDUgMTU6NTU6MzMg Q0VUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBUaHUgTWF5IDA1IDE3OjQwOjM0IDIw MTEgKzAxMDAgMjMzMDA6NGIwNjkyODgwZGZhCj4gKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3lu Y2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVl emUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBkb20wX21h eF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUgY29tMT0x MTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoK PiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikgIFZCRS9E REMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhFTikgRGlz YyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChYRU4pICBG b3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAgUkFNIG1h cDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVzYWJsZSkK PiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQo+ IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4g KFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUpCj4gKFhF TikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gKFhF TikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAoWEVO KSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+IChYRU4p ICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikg IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhFTikgQUNQ STogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhTRFQgQ0ZF ODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+ IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0MCAyMDEx MTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2RTMgKHIx ICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFDUEk6IEZB Q1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4IChyMSAx MDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBNQ0ZH IENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAgICAgICA5 NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VNQjE3NDAg MjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMwLCAwMDM4 IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAg ICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0gSSAgUE9X RVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIg KDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAoWEVOKSBG YWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+IChYRU4p IERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAw MGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVm YXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikgQUNQSTog QUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+IChYRU4p IEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19zaXplWzIw XQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhFTikgQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAoWEVOKSBQ cm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMSAw OjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh cGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJz aW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10g ZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVO KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQo+IChY RU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw N10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsw eDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJQ1swXTog YXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCj4gKFhF TikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0 XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZl YzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly cSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMg MCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJUlEwIHVz ZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgo+IChY RU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBBUElDIG1v ZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgz MDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJh c2UgZTAwMDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSAyNTUKPiAoWEVOKSBQQ0k6IE5vdCB1c2lu ZyBNTUNPTkZJRy4KPiAoWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCj4gKFhFTikgVXNpbmcgQUNQ SSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uCj4gKFhFTikgSVJRIGxp bWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjI1NCBNSHog cHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZh bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgQU1ELVZpOiBJT01N VSAwIEVuYWJsZWQuCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAoWEVOKSAg LSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKPiAoWEVO KSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBh cGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGltZXIgaXMg MTQuMzE4TUh6IEhQRVQKPiDDvyhYRU4pIEFsbG9jYXRlZCBjb25zb2xlIHJpbmcgb2YgNjQgS2lC Lgo+IChYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4KPiAoWEVOKSBTVk06IFN1cHBvcnRlZCBhZHZh bmNlZCBmZWF0dXJlczoKPiAoWEVOKSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkKPiAoWEVO KSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KPiAoWEVOKSAgLSBO ZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUCj4gKFhFTikgIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRl cgo+IChYRU4pIEhWTTogU1ZNIGVuYWJsZWQKPiAoWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVk IFBhZ2luZyBkZXRlY3RlZC4KPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIEhQRVQn cyBNU0kgbW9kZSBoYXNuJ3QgYmVlbiBzdXBwb3J0ZWQgd2hlbiBJbnRlcnJ1cHQgUmVtYXBwaW5n IGlzIGVuYWJsZWQuCj4gKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMKPiAoWEVOKSBNQ0E6IFVz ZSBodyB0aHJlc2hvbGRpbmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJlcXVlbmN5Cj4gKFhFTikgbWNo ZWNrX3BvbGw6IE1hY2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgo+IChYRU4pIFhl bm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZzZXQsIElCU0NUTCA9IDB4ZmZm ZmZmZmYKPiAoWEVOKSAqKiogTE9BRElORyBET01BSU4gMCAqKioKPiAoWEVOKSBlbGZfcGFyc2Vf YmluYXJ5OiBwaGRyOiBwYWRkcj0weDEwMDAwMDAgbWVtc3o9MHg3N2MwMDAKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE3N2MwMDAgbWVtc3o9MHg4ZGE4OAo+IChYRU4p IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgwYTAwMCBtZW1zej0weDhjOAo+IChY RU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgwYjAwMCBtZW1zej0weDE0YTU4 Cj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxODIwMDAwIG1lbXN6PTB4 MjEyMDAwCj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgx YTMyMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCIKPiAo WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIKPiAoWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pIGVsZl94 ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZmODE4MjAyMDAKPiAoWEVOKSBlbGZfeGVu X3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDA5MDAwCj4gKFhFTikg ZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90YWJsZXN8cGFl X3BnZGlyX2Fib3ZlXzRnYiIKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0g InllcyIKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgo+IChY RU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkKPiAoWEVO KSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCj4gKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAo+IChYRU4pIGVsZl94ZW5fYWRk cl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6Cj4gKFhFTikgICAgIHZpcnRfYmFzZSAgICAgICAgPSAw eGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MAo+IChY RU4pICAgICB2aXJ0X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgICAg IHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9r ZW5kICAgICAgICA9IDB4ZmZmZmZmZmY4MWEzMjAwMAo+IChYRU4pICAgICB2aXJ0X2VudHJ5ICAg ICAgID0gMHhmZmZmZmZmZjgxODIwMjAwCj4gKFhFTikgICAgIHAybV9iYXNlICAgICAgICAgPSAw eGZmZmZmZmZmZmZmZmZmZmYKPiAoWEVOKSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w YXQzMgo+IChYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAw MDAwIC0+IDB4MWEzMjAwMAo+IChYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKPiAo WEVOKSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDIyNDAwMDAwMC0+MDAwMDAwMDIyODAwMDAwMCAo NTA2MjYzIHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkKPiAoWEVOKSAgSW5pdC4gcmFtZGlzazogMDAw MDAwMDIyZjk5NzAwMC0+MDAwMDAwMDIyZmZmZjYwMAo+IChYRU4pIFZJUlRVQUwgTUVNT1JZIEFS UkFOR0VNRU5UOgo+IChYRU4pICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZm ZmZmZjgxYTMyMDAwCj4gKFhFTikgIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODFhMzIwMDAtPmZm ZmZmZmZmODIwOWE2MDAKPiAoWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MjA5YjAwMC0+ ZmZmZmZmZmY4MjQ5YjAwMAo+IChYRU4pICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgyNDliMDAw LT5mZmZmZmZmZjgyNDliNGI0Cj4gKFhFTikgIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODI0OWMw MDAtPmZmZmZmZmZmODI0YjMwMDAKPiAoWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjRi MzAwMC0+ZmZmZmZmZmY4MjRiNDAwMAo+IChYRU4pICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgw MDAwMDAwLT5mZmZmZmZmZjgyODAwMDAwCj4gKFhFTikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZm ODE4MjAyMDAKPiAoWEVOKSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKPiAoWEVOKSBlbGZfbG9h ZF9iaW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxNzdj MDAwCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgxNzdjMDAw IC0+IDB4ZmZmZmZmZmY4MTgwOWE4OAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0 IDB4ZmZmZmZmZmY4MTgwYTAwMCAtPiAweGZmZmZmZmZmODE4MGE4YzgKPiAoWEVOKSBlbGZfbG9h ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODE4MGIwMDAgLT4gMHhmZmZmZmZmZjgxODFm YTU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDQgYXQgMHhmZmZmZmZmZjgxODIwMDAw IC0+IDB4ZmZmZmZmZmY4MThiMzAwMAo+IChYRU4pIFNjcnViYmluZyBGcmVlIFJBTTogLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRv bmUuCj4gKFhFTikgU3RkLiBMb2dsZXZlbDogQWxsCj4gKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFs bAo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK PiAoWEVOKSAqKioqKioqIFdBUk5JTkc6IENPTlNPTEUgT1VUUFVUIElTIFNZTkNIUk9OT1VTCj4g KFhFTikgKioqKioqKiBUaGlzIG9wdGlvbiBpcyBpbnRlbmRlZCB0byBhaWQgZGVidWdnaW5nIG9m IFhlbiBieSBlbnN1cmluZwo+IChYRU4pICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNo cm9ub3VzbHkgZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4KPiAoWEVOKSAqKioqKioqIEhv d2V2ZXIgaXQgY2FuIGludHJvZHVjZSBTSUdOSUZJQ0FOVCBsYXRlbmNpZXMgYW5kIGFmZmVjdAo+ IChYRU4pICoqKioqKiogdGltZWtlZXBpbmcuIEl0IGlzIE5PVCByZWNvbW1lbmRlZCBmb3IgcHJv ZHVjdGlvbiB1c2UhCj4gKFhFTikgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgo+IChYRU4pIDMuLi4gMi4uLiAxLi4uIAo+IChYRU4pICoqKiBTZXJpYWwgaW5w dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8g WGVuKQo+IChYRU4pIEZyZWVkIDIzNmtCIGluaXQgbWVtb3J5Lgo+IG1hcHBpbmcga2VybmVsIGlu dG8gcGh5c2ljYWwgbWVtb3J5Cj4gWGVuOiBzZXR1cCBJU0EgaWRlbnRpdHkgbWFwcwo+IGFib3V0 IHRvIGdldCBzdGFydGVkLi4uCj4gRVJST1I6IFVuYWJsZSB0byBsb2NhdGUgSU9BUElDIGZvciBH U0kgMgo+IEVSUk9SOiBVbmFibGUgdG8gbG9jYXRlIElPQVBJQyBmb3IgR1NJIDkKPiAoWEVOKSB0 cmFwcy5jOjI0MDU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy b20gMHgwMDAwMjRhNzRkYjA2NDA0IHRvIDB4MDAwMDAwMDAwMDAwMDAwMC4KPiAoWEVOKSB0cmFw cy5jOjI0MDU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDAwIGZyb20g MHgwMDAwMDMwNjFhMGVmZmM5IHRvIDB4MDAwMDAwMDAwMDQzMDA3Ni4KPiBFUlJPUjogVW5hYmxl IHRvIGxvY2F0ZSBJT0FQSUMgZm9yIEdTSSA5Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDAu MAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjAwLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAw MDowMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDQuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwOjA1LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowNi4wCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDA6MDcuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjBkLjAKPiAoWEVOKSBQ Q0kgYWRkIGRldmljZSAwMDoxMS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTIuMAo+IChY RU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxMy4w Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTMuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAw OjE0LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDA6MTQuMwo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjQKPiAoWEVOKSBQQ0kgYWRk IGRldmljZSAwMDoxNC41Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTYuMAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwOjE2LjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDA6MTguMQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjIK PiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6 MTguNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDA3OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmlj ZSAwNzowMC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDY6MDAuMAo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDA2OjAwLjEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwNTowMC4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDQ6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAzOjAwLjAKPiAoWEVO KSBQQ0kgYWRkIGRldmljZSAwMjowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDI6MDAuMQo+ IHJlZ2lzdGVyaW5nIG5ldGJhY2sKPiBJVDg3IFdEVDogVW5rbm93biBDaGlwIGZvdW5kLCBDaGlw IDg3MjEgUmV2aXNpb24gMDAwMQo+IFtGaXJtd2FyZSBCdWddOiBwb3dlcm5vdy1rODogTm8gY29t cGF0aWJsZSBBQ1BJIF9QU1Mgb2JqZWN0cyBmb3VuZC4KPiBbRmlybXdhcmUgQnVnXTogcG93ZXJu b3ctazg6IFRyeSBhZ2FpbiB3aXRoIGxhdGVzdCBCSU9TLgo+IExvYWRpbmcsIHBsZWFzZSB3YWl0 Li4uCj4gSU5JVDogdmVyc2lvbiAyLjg4IGJvb3RpbmcKPiBVc2luZyBtYWtlZmlsZS1zdHlsZSBj b25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy4KPiBTdGFydGluZyB0aGUgaG90cGx1ZyBldmVu dHMgZGlzcGF0Y2hlcjogdWRldmQuCj4gU3ludGhlc2l6aW5nIHRoZSBpbml0aWFsIGhvdHBsdWcg ZXZlbnRzLi4uZG9uZS4KPiBXYWl0aW5nIGZvciAvZGV2IHRvIGJlIGZ1bGx5IHBvcHVsYXRlZC4u LnVkZXZkLXdvcmtbMTQzN106IGtlcm5lbC1wcm92aWRlZCBuYW1lICdibGt0YXAtY29udHJvbCcg YW5kIE5BTUU9ICd4ZW4vYmxrdGFwLTIvY29udHJvbCcgZGlzYWdyZWUsIHBsZWFzZSB1c2UgU1lN TElOSys9IG9yIGNoYW5nZSB0aGUga2VybmVsIHRvIHByb3ZpZGUgdGhlIHByb3BlciBuYW1lCj4g Cj4gZG9uZS4KPiBTZXR0aW5nIHByZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGlu ZyBzd2FwLi4uZG9uZS4KPiBDaGVja2luZyByb290IGZpbGUgc3lzdGVtLi4uZnNjayBmcm9tIHV0 aWwtbGludXgtbmcgMi4xNy4yCj4gSE9XVE9fUk9PVDogY2xlYW4sIDk1MDU0LzE0MTk4NDAgZmls ZXMsIDczMTE4MC81Njc5MTA0IGJsb2NrcyAoY2hlY2sgaW4gNCBtb3VudHMpCj4gZG9uZS4KPiBM b2FkaW5nIGtlcm5lbCBtb2R1bGVzLi4uZG9uZS4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4uLi4K PiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdyb3Vw cyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGlsZS4u Lgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBs dm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2giIG5v dyBhY3RpdmUKPiAuCj4gQWN0aXZhdGluZyBsdm0gYW5kIG1kIHN3YXAuLi5kb25lLgo+IENoZWNr aW5nIGZpbGUgc3lzdGVtcy4uLmZzY2sgZnJvbSB1dGlsLWxpbnV4LW5nIDIuMTcuMgo+IGRvbmUu Cj4gTW91bnRpbmcgbG9jYWwgZmlsZXN5c3RlbXMuLi5kb25lLgo+IEFjdGl2YXRpbmcgc3dhcGZp bGUgc3dhcC4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uLgo+IFNldHRp bmcga2VybmVsIHZhcmlhYmxlcyAuLi5kb25lLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJm YWNlcy4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uLgo+IFNldHRpbmcg Y29uc29sZSBzY3JlZW4gbW9kZXMuCj4gUmNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4g U2tpcHBpbmcgZm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXAp Lgo+IFNldHRpbmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IElOSVQ6IEVu dGVyaW5nIHJ1bmxldmVsOiAyCj4gVXNpbmcgbWFrZWZpbGUtc3R5bGUgY29uY3VycmVudCBib290 IGluIHJ1bmxldmVsIDIuCj4gYWNwaWQ6IHN0YXJ0aW5nIHVwIHdpdGggcHJvYyBmcwo+IAo+IGFj cGlkOiAxIHJ1bGUgbG9hZGVkCj4gCj4gYWNwaWQ6IHdhaXRpbmcgZm9yIGV2ZW50czogZXZlbnQg bG9nZ2luZyBpcyBvZmYKPiAKPiBTdGFydGluZyBBQ1BJIHNlcnZpY2VzLi4uLgo+IFN0YXJ0aW5n IHN5c3RlbSBtZXNzYWdlIGJ1czogZGJ1cy4KPiBTdGFydGluZyBwZXJpb2RpYyBjb21tYW5kIHNj aGVkdWxlcjogY3Jvbi4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3VyZSBTaGVsbCBzZXJ2ZXI6IHNz aGQuCj4gU3RhcnRpbmcgeGVuc3RvcmVkLi4uWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3Rh dGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRv IHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5C VVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1 IHN0YXRlCj4gCj4gU2V0dGluZyBkb21haW4gMCBuYW1lLi4uCj4gU3RhcnRpbmcgeGVuY29uc29s ZWQuLi4KPiBCTEtUQVBDVFJMWzIxNjhdOiBibGt0YXBjdHJsLmM6NzkwOiBibGt0YXBjdHJsOiB2 MS4wLjAKPiAKPiBCTEtUQVBDVFJMWzIxNjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2 ZXI6IFtyYXcgaW1hZ2UgKGFpbyldCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5j Ojc5MjogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChzeW5jKV0KPiAKPiBCTEtUQVBDVFJMWzIx NjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFt2bXdhcmUgaW1hZ2UgKHZtZGsp XQo+IAo+IEJMS1RBUENUUkxbMjE2OF06IGJsa3RhcGN0cmwuYzo3OTI6IEZvdW5kIGRyaXZlcjog W3JhbWRpc2sgaW1hZ2UgKHJhbSldCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5j Ojc5MjogRm91bmQgZHJpdmVyOiBbcWNvdyBkaXNrIChxY293KV0KPiAKPiBCTEtUQVBDVFJMWzIx NjhdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFtxY293MiBkaXNrIChxY293Mild Cj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybF9saW51eC5jOjg2OiBibGt0YXAwIG9w ZW4gZmFpbGVkCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3RybC5jOjg1OTogY291bGRu J3Qgb3BlbiBibGt0YXAgaW50ZXJmYWNlCj4gCj4gQkxLVEFQQ1RSTFsyMTY4XTogYmxrdGFwY3Ry bC5jOjkyMjogVW5hYmxlIHRvIHN0YXJ0IGJsa3RhcGN0cmwKPiAKPiAoWEVOKSBQQ0kgcmVtb3Zl IGRldmljZSAwMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTIuMgo+IC91c3IvbG9j YWwvYmluL3hlbl9zdGFydC5zaDogbGluZSAxNTogL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDow NzowMC4wL2RyaXZlci91bmJpbmQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKPiBVc2luZyBj b25maWcgZmlsZSAiL2V0Yy94ZW4vd2luZG93cyIuCj4gKFhFTikgZG9tY3RsLmM6MTA0MjpkMCBp b3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNiMCBmX21wb3J0PTNiMCBucD1jCj4gKFhFTikgZG9tY3Rs LmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49YTAgbWZuPWEwIG5yX21mbnM9MjAKPiAoWEVO KSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2MwIGZfbXBvcnQ9M2Mw IG5wPTMKPiAoWEVOKSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2M0 IGZfbXBvcnQ9M2M0IG5wPTFjCj4gKFhFTikgSFZNMTogSFZNIExvYWRlcgo+IChYRU4pIEhWTTE6 IERldGVjdGVkIFhlbiB2NC4yLXVuc3RhYmxlCj4gKFhFTikgSFZNMTogWGVuYnVzIHJpbmdzIEAw eGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDcKPiBTdGFydGVkIGRvbWFpbiB3aW5kb3dzIChpZD0x KShYRU4pIEhWTTE6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IAo+IChYRU4pIEhWTTE6IENQ VSBzcGVlZCBpcyAzMDEwIE1Iego+IChYRU4pIGlycS5jOjI1ODogRG9tMSBQQ0kgbGluayAwIGNo YW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUK PiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVO KSBIVk0xOiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNTg6 IERvbTEgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxp bmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMyBj aGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1 Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNp IGRldiAwMzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJR NQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBj aSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzowIElOVEEtPklS UTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0xOiBw Y2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDEw IHNpemUgMTAwMDAwMDA6IGUwMDAwMDBjCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9t YXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBIVk0xOiBw Y2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhFTikgSFZNMTog cGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMTAwMDAwMAo+IChYRU4pIGRvbWN0 bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAw NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAw MDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYw MDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjAgbWZu PWZlOWJjIG5yX21mbnM9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAw MDAwNDAwMDogZjEwNjQwMDQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6 IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzow IGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2ODAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBt ZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBIVk0x OiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgZG9t Y3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9 MQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMw MDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6IDAwMDBj MTAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAw YzIwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAw MGMyNDEKPiAoWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKPiAoWEVO KSBIVk0xOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0xOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAu Li4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0x OiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb My84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5cyAuLi4g Zml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiBU ZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBhY3Jvc3Mg cGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiAgLSBHUyBiYXNlIE1TUnMg YW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogUGFzc2VkIDIgb2YgMiB0ZXN0cwo+ IChYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBkb21jdGwuYzox MDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZfZ3BvcnQ9M2IwIGZfbXBvcnQ9M2IwIG5wPWMKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1hMCBtZm49YTAgbnJfbWZucz0y MAo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzAgZl9t cG9ydD0zYzAgbnA9Mwo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9n cG9ydD0zYzQgZl9tcG9ydD0zYzQgbnA9MWMKPiAoWEVOKSBIVk0yOiBIVk0gTG9hZGVyCj4gKFhF TikgSFZNMjogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKPiAoWEVOKSBIVk0yOiBYZW5idXMg cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNwo+IChYRU4pIEhWTTI6IFN5c3RlbSBy ZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4pIEhWTTI6IENQVSBzcGVlZCBpcyAzMDEwIE1Iego+IChY RU4pIGlycS5jOjI1ODogRG9tMiBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZN MjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTIg UENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVOKSBIVk0yOiBQQ0ktSVNBIGxpbmsgMSBy b3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTIgUENJIGxpbmsgMiBjaGFuZ2Vk IDAgLT4gMTEKPiAoWEVOKSBIVk0yOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAo WEVOKSBpcnEuYzoyNTg6IERvbTIgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhW TTI6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikgSFZNMjogcGNpIGRldiAw MTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMjogcGNpIGRldiAwMzowIElOVEEtPklSUTUKPiAo WEVOKSBIVk0yOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTI6IHBjaSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4g KFhFTikgSFZNMjogcGNpIGRldiAwNzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAK PiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMTAwMDAwMDA6IGUwMDAwMDBj Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQw MDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUg MDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhFTikgSFZNMjogcGNpIGRldiAwNDowIGJhciAxMCBzaXpl IDAwMDIwMDAwOiBmMTAwMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFk ZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikgSFZNMjogcGNpIGRldiAw NTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAwNAo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAwMDAKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYwMDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2 OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4p IEhWTTI6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAwMDAwNDAwMDogZjEwNjQwMDQKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJf bWZucz00Cj4gKFhFTikgSFZNMjogcGNpIGRldiAwNzowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBm MTA2ODAwMAo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4 IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBIVk0yOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNp emUgMDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6 YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChYRU4pIEhWTTI6IHBjaSBkZXYg MDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMwMDEKPiAoWEVOKSBIVk0yOiBwY2kgZGV2 IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6IDAwMDBjMTAxCj4gKFhFTikgSFZNMjogcGNpIGRl diAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzIwMQo+IChYRU4pIEhWTTI6IHBjaSBk ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMyNDEKPiAoWEVOKSBIVk0yOiBNdWx0 aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoKPiAoWEVOKSBIVk0yOiAgLSBDUFUwIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0yOiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiAgLSBDUFUyIC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0yOiAgLSBDUFUzIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0yOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJS cyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0yOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoK PiAoWEVOKSBIVk0yOiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNz ZWQKPiAoWEVOKSBIVk0yOiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4g KFhFTikgSFZNMjogUGFzc2VkIDIgb2YgMiB0ZXN0cwo+IChYRU4pIEhWTTI6IFdyaXRpbmcgU01C SU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBkb21jdGwuYzoxMDQyOmQwIGlvcG9ydF9tYXA6YWRkIGZf Z3BvcnQ9M2IwIGZfbXBvcnQ9M2IwIG5wPWMKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5 X21hcDphZGQ6IGdmbj1hMCBtZm49YTAgbnJfbWZucz0yMAo+IChYRU4pIGRvbWN0bC5jOjEwNDI6 ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzAgZl9tcG9ydD0zYzAgbnA9Mwo+IChYRU4pIGRv bWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21hcDphZGQgZl9ncG9ydD0zYzQgZl9tcG9ydD0zYzQgbnA9 MWMKPiAoWEVOKSBIVk0zOiBIVk0gTG9hZGVyCj4gKFhFTikgSFZNMzogRGV0ZWN0ZWQgWGVuIHY0 LjItdW5zdGFibGUKPiAoWEVOKSBIVk0zOiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50 IGNoYW5uZWwgNwo+IChYRU4pIEhWTTM6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4p IEhWTTM6IENQVSBzcGVlZCBpcyAzMDEwIE1Iego+IChYRU4pIGlycS5jOjI1ODogRG9tMyBQQ0kg bGluayAwIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZNMzogUENJLUlTQSBsaW5rIDAgcm91dGVk IHRvIElSUTUKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTMgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4g MTAKPiAoWEVOKSBIVk0zOiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBp cnEuYzoyNTg6IERvbTMgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0zOiBQ Q0ktSVNBIGxpbmsgMiByb3V0ZWQgdG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTMgUENJ IGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQo+IChYRU4pIEhWTTM6IFBDSS1JU0EgbGluayAzIHJvdXRl ZCB0byBJUlE1Cj4gKFhFTikgSFZNMzogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikg SFZNMzogcGNpIGRldiAwMzowIElOVEEtPklSUTUKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA0OjAg SU5UQS0+SVJRNQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4p IEhWTTM6IHBjaSBkZXYgMDY6MCBJTlRCLT5JUlE1Cj4gKFhFTikgSFZNMzogcGNpIGRldiAwNzow IElOVEEtPklSUTUKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVO KSBIVk0zOiBwY2kgZGV2IDA5OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA1 OjAgYmFyIDEwIHNpemUgMTAwMDAwMDA6IGUwMDAwMDBjCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQw IG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVO KSBIVk0zOiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYwMDAwMDA4Cj4gKFhF TikgSFZNMzogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAwMDIwMDAwOiBmMTAwMDAwMAo+IChY RU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDIwIG1mbj1mZTllMCBu cl9tZm5zPTIwCj4gKFhFTikgSFZNMzogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAw OiBmMTAyMDAwNAo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAw MDogZjEwNDAwMDAKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQw MDA6IGYxMDYwMDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49 ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDk6MCBiYXIg MTAgc2l6ZSAwMDAwNDAwMDogZjEwNjQwMDQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5 X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgSFZNMzogcGNp IGRldiAwNzowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2ODAwMAo+IChYRU4pIGRvbWN0bC5j Ojk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAo WEVOKSBIVk0zOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4g KFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAw IG5yX21mbnM9MQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEw MDogMDAwMGMwMDEKPiAoWEVOKSBIVk0zOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAx MDA6IDAwMDBjMTAxCj4gKFhFTikgSFZNMzogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAw MDQwOiAwMDAwYzIwMQo+IChYRU4pIEhWTTM6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAw MDAxMDogMDAwMGMyNDEKPiAoWEVOKSBIVk0zOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlv bjoKPiAoWEVOKSBIVk0zOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMg Li4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFUxIC4uLiA0 OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4K PiAoWEVOKSBIVk0zOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u IHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFUzIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0zOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0zOiAgLSBDUFU1IC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0zOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0zOiAgLSBSRVAgSU5T QiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0zOiAgLSBHUyBi YXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMzogUGFzc2VkIDIgb2Yg MiB0ZXN0cwo+IChYRU4pIEhWTTM6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAgX18gIF9f ICAgICAgICAgICAgXyAgXyAgICBfX19fICAgICAgICAgICAgICAgICAgICAgXyAgICAgICAgXyAg ICAgXyAgICAgIAo+ICBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyBcICAgIF8gICBfIF8g X18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gCj4gICBcICAvLyBfIFwgJ18gXCAgfCB8fCB8 XyAgIF9fKSB8X198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBcfCB8LyBfIFwKPiAgIC8g IFwgIF9fLyB8IHwgfCB8X18gICBffCAvIF9fL3xfX3wgfF98IHwgfCB8IFxfXyBcIHx8IChffCB8 IHxfKSB8IHwgIF9fLwo+ICAvXy9cX1xfX198X3wgfF98ICAgIHxffChfKV9fX19ffCAgIFxfXyxf fF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198Cj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPiAo WEVOKSBYZW4gdmVyc2lvbiA0LjItdW5zdGFibGUgKHJvb3RAbmV0c2FmZS5jeikgKGdjYyB2ZXJz aW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSBTdW4gRmViICA1IDE1OjU1OjMzIENFVCAyMDEy Cj4gKFhFTikgTGF0ZXN0IENoYW5nZVNldDogVGh1IE1heSAwNSAxNzo0MDozNCAyMDExICswMTAw IDIzMzAwOjRiMDY5Mjg4MGRmYQo+IChYRU4pIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9ub3Vz Lgo+IChYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQo+IChY RU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgZG9tMF9tZW09MkcgZG9tMF9tYXhfdmNwdXM9 NiBsb2dsdmw9YWxsIGd1ZXN0X2xvZ2x2bD1hbGwgc3luY19jb25zb2xlIGNvbTE9MTE1MjAwLDhu MSwweGFjMDAgY29uc29sZT1jb20xCj4gKFhFTikgVmlkZW8gaW5mb3JtYXRpb246Cj4gKFhFTikg IFZHQSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgo+IChYRU4pICBWQkUvRERDIG1ldGhv ZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vjb25kcwo+IChYRU4pIERpc2MgaW5mb3Jt YXRpb246Cj4gKFhFTikgIEZvdW5kIDEgTUJSIHNpZ25hdHVyZXMKPiAoWEVOKSAgRm91bmQgMSBF REQgaW5mb3JtYXRpb24gc3RydWN0dXJlcwo+IChYRU4pIFhlbi1lODIwIFJBTSBtYXA6Cj4gKFhF TikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlhYzAwICh1c2FibGUpCj4gKFhFTikg IDAwMDAwMDAwMDAwOWFjMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAg MDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAw MDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBjZmU4MDAwMCAodXNhYmxlKQo+IChYRU4pICAwMDAw MDAwMGNmZTgwMDAwIC0gMDAwMDAwMDBjZmU5ODAwMCAoQUNQSSBkYXRhKQo+IChYRU4pICAwMDAw MDAwMGNmZTk4MDAwIC0gMDAwMDAwMDBjZmVjMDAwMCAoQUNQSSBOVlMpCj4gKFhFTikgIDAwMDAw MDAwY2ZlYzAwMDAgLSAwMDAwMDAwMGNmZjAwMDAwIChyZXNlcnZlZCkKPiAoWEVOKSAgMDAwMDAw MDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAw MTAwMDAwMDAwIC0gMDAwMDAwMDIzMDAwMDAwMCAodXNhYmxlKQo+IChYRU4pIEFDUEk6IFJTRFAg MDAwRkJGMjAsIDAwMjQgKHIyIEFDUElBTSkKPiAoWEVOKSBBQ1BJOiBYU0RUIENGRTgwMTAwLCAw MDVDIChyMSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBGQUNQIENGRTgwMjkwLCAwMEY0IChyMyAxMDI4MTEgRkFDUDE3NDAgMjAxMTEwMjggTVNG VCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBEU0RUIENGRTgwNDcwLCBFNkUzIChyMSAgQTE1OTUg QTE1OTUwMDAgICAgICAgIDAgSU5UTCAyMDA2MDExMykKPiAoWEVOKSBBQ1BJOiBGQUNTIENGRTk4 MDAwLCAwMDQwCj4gKFhFTikgQUNQSTogQVBJQyBDRkU4MDM5MCwgMDA5OCAocjEgMTAyODExIEFQ SUMxNzQwIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogTUNGRyBDRkU4MDQz MCwgMDAzQyAocjEgMTAyODExIE9FTU1DRkcgIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhF TikgQUNQSTogT0VNQiBDRkU5ODA0MCwgMDA3MiAocjEgMTAyODExIE9FTUIxNzQwIDIwMTExMDI4 IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogSFBFVCBDRkU4RjhDMCwgMDAzOCAocjEgMTAy ODExIE9FTUhQRVQgIDIwMTExMDI4IE1TRlQgICAgICAgOTcpCj4gKFhFTikgQUNQSTogSVZSUyBD RkU4RjkwMCwgMDBFMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAgICAgIDAp Cj4gKFhFTikgQUNQSTogU1NEVCBDRkU4RjlFMCwgMEUxMCAocjEgQSBNIEkgIFBPV0VSTk9XICAg ICAgICAxIEFNRCAgICAgICAgIDEpCj4gKFhFTikgU3lzdGVtIFJBTTogODE5ME1CICg4Mzg2NjY0 a0IpCj4gKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kCj4gKFhFTikgRmFraW5nIGEg bm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAyMzAwMDAwMDAKPiAoWEVOKSBEb21haW4g aGVhcCBpbml0aWFsaXNlZAo+IChYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBmZjc4MAo+ IChYRU4pIERNSSBwcmVzZW50Lgo+IChYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQKPiAo WEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOAo+IChYRU4pIEFDUEk6IEFDUEkgU0xF RVAgSU5GTzogcG0xeF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0KPiAoWEVOKSBBQ1BJOiAg ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbY2ZlOTgwMGNdLCB2ZWNfc2l6ZVsyMF0KPiAoWEVO KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAo+IChYRU4pIEFDUEk6IExBUElD IChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29y ICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw Ml0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElD IHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw eDAyXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+ IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQp Cj4gKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9j ZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjNSAwOjEw IEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGlj X2lkWzB4ODZdIGRpc2FibGVkKQo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxh cGljX2lkWzB4ODddIGRpc2FibGVkKQo+IChYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRk cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKPiAoWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQg NiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMwo+IChYRU4pIEFDUEk6 IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCj4gKFhF TikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMyMDAwMCwg R1NJIDI0LTU1Cj4gKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9i YWxfaXJxIDIgZGZsIGRmbCkKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly cSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpCj4gKFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92 ZXJyaWRlLgo+IChYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBBQ1BJ OiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxh dC4gIFVzaW5nIDIgSS9PIEFQSUNzCj4gKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6 IDB4ZmVkMDAwMDAKPiAoWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAw MDAwIHNlZ21lbnQgMCBidXNlcyAwIC0gMjU1Cj4gKFhFTikgUENJOiBOb3QgdXNpbmcgTU1DT05G SUcuCj4gKFhFTikgVGFibGUgaXMgbm90IGZvdW5kIQo+IChYRU4pIFVzaW5nIEFDUEkgKE1BRFQp IGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgo+IChYRU4pIElSUSBsaW1pdHM6IDU2 IEdTSSwgMTExMiBNU0kvTVNJLVgKPiAoWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQg U2NoZWR1bGVyIChjcmVkaXQpCj4gKFhFTikgRGV0ZWN0ZWQgMzAxMC4yMjAgTUh6IHByb2Nlc3Nv ci4KPiAoWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgo+IChYRU4pIEFNRCBGYW0xMGggbWFj aGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZAo+IChYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFi bGVkLgo+IChYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkCj4gKFhFTikgIC0gRG9tMCBt b2RlOiBSZWxheGVkCj4gKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzCj4gKFhFTikgIC0+IFVz aW5nIG5ldyBBQ0sgbWV0aG9kCj4gKFhFTikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBw aW4xPTIgYXBpYzI9LTEgcGluMj0tMQo+IChYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I eiBIUEVUCj4gw78oWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4KPiAoWEVO KSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVh dHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4gKFhFTikgIC0gTGFz dCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikgIC0gTmV4dC1SSVAg U2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKPiAoWEVO KSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg ZGV0ZWN0ZWQuCj4gKFhFTikgQnJvdWdodCB1cCA2IENQVXMKPiAoWEVOKSBIUEVUJ3MgTVNJIG1v ZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi bGVkLgo+IChYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzCj4gKFhFTikgTUNBOiBVc2UgaHcgdGhy ZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQo+IChYRU4pIG1jaGVja19wb2xs OiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KPiAoWEVOKSBYZW5vcHJvZmls ZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmCj4g KFhFTikgKioqIExPQURJTkcgRE9NQUlOIDAgKioqCj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTog cGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4NzdjMDAwCj4gKFhFTikgZWxmX3BhcnNlX2Jp bmFyeTogcGhkcjogcGFkZHI9MHgxNzdjMDAwIG1lbXN6PTB4OGRhODgKPiAoWEVOKSBlbGZfcGFy c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE4MGEwMDAgbWVtc3o9MHg4YzgKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE4MGIwMDAgbWVtc3o9MHgxNGE1OAo+IChYRU4p IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTgyMDAwMCBtZW1zej0weDIxMjAwMAo+ IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MWEzMjAwMAo+ IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiCj4gKFhFTikgZWxm X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKPiAoWEVOKSBlbGZfeGVuX3Bh cnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxODIwMjAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwOTAwMAo+IChYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9h Ym92ZV80Z2IiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiCj4g KFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKPiAoWEVOKSBlbGZf eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpCj4gKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDAKPiAoWEVOKSBlbGZfeGVuX2FkZHJfY2FsY19j aGVjazogYWRkcmVzc2VzOgo+IChYRU4pICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm ZjgwMDAwMDAwCj4gKFhFTikgICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKPiAoWEVOKSAgICAg dmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tz dGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwCj4gKFhFTikgICAgIHZpcnRfa2VuZCAgICAg ICAgPSAweGZmZmZmZmZmODFhMzIwMDAKPiAoWEVOKSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4 ZmZmZmZmZmY4MTgyMDIwMAo+IChYRU4pICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm ZmZmZmZmZmZmCj4gKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIKPiAo WEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAw eDFhMzIwMDAKPiAoWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4gKFhFTikgIERv bTAgYWxsb2MuOiAgIDAwMDAwMDAyMjQwMDAwMDAtPjAwMDAwMDAyMjgwMDAwMDAgKDUwNjI2MyBw YWdlcyB0byBiZSBhbGxvY2F0ZWQpCj4gKFhFTikgIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyMmY5 OTcwMDAtPjAwMDAwMDAyMmZmZmY2MDAKPiAoWEVOKSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVO VDoKPiAoWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MWEz MjAwMAo+IChYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgxYTMyMDAwLT5mZmZmZmZmZjgy MDlhNjAwCj4gKFhFTikgIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODIwOWIwMDAtPmZmZmZmZmZm ODI0OWIwMDAKPiAoWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjQ5YjAwMC0+ZmZmZmZm ZmY4MjQ5YjRiNAo+IChYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgyNDljMDAwLT5mZmZm ZmZmZjgyNGIzMDAwCj4gKFhFTikgIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODI0YjMwMDAtPmZm ZmZmZmZmODI0YjQwMDAKPiAoWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ ZmZmZmZmZmY4MjgwMDAwMAo+IChYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxODIwMjAw Cj4gKFhFTikgRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5 OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MTc3YzAwMAo+IChY RU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MTc3YzAwMCAtPiAweGZm ZmZmZmZmODE4MDlhODgKPiAoWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZm ZmZmODE4MGEwMDAgLT4gMHhmZmZmZmZmZjgxODBhOGM4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5 OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxODBiMDAwIC0+IDB4ZmZmZmZmZmY4MTgxZmE1OAo+IChY RU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciA0IGF0IDB4ZmZmZmZmZmY4MTgyMDAwMCAtPiAweGZm ZmZmZmZmODE4YjMwMDAKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChY RU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVO KSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikg KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoq KioqKiogVGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkg ZW5zdXJpbmcKPiAoWEVOKSAqKioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5 IGRlbGl2ZXJlZCBvbiB0aGUgc2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0 IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAq KioqKioqIHRpbWVrZWVwaW5nLiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24g dXNlIQo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKPiAoWEVOKSAzLi4uIDIuLi4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERP TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAo WEVOKSBGcmVlZCAyMzZrQiBpbml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp Y2FsIG1lbW9yeQo+IFhlbjogc2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQg c3RhcnRlZC4uLgo+IEVSUk9SOiBVbmFibGUgdG8gbG9jYXRlIElPQVBJQyBmb3IgR1NJIDIKPiBF UlJPUjogVW5hYmxlIHRvIGxvY2F0ZSBJT0FQSUMgZm9yIEdTSSA5Cj4gKFhFTikgdHJhcHMuYzoy NDA1OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw MGU0YTc1ZGY4NjUxNCB0byAweDAwMDAwMDAwMDAwMDAwMDAuCj4gKFhFTikgdHJhcHMuYzoyNDA1 OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwMCBmcm9tIDB4MDAwMDAz MGUxYjBlZmZlOSB0byAweDAwMDAwMDAwMDA0MzAwNzYuCj4gRVJST1I6IFVuYWJsZSB0byBsb2Nh dGUgSU9BUElDIGZvciBHU0kgOQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjAwLjAKPiAoWEVO KSBQQ0kgYWRkIGRldmljZSAwMDowMC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDIuMAo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjA0LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDow NS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MDYuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwOjA3LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDowZC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDA6MTEuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjAKPiAoWEVOKSBQQ0kg YWRkIGRldmljZSAwMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTMuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwOjEzLjIKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC4wCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTQuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE0 LjMKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxNC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDA6MTQuNQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE2LjAKPiAoWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDA6MTguMAo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwOjE4LjEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDoxOC4yCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDA6MTguMwo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjQKPiAo WEVOKSBQQ0kgYWRkIGRldmljZSAwNzowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDc6MDAu MQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDA2OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAw NjowMC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDU6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDA0OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMzowMC4wCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDI6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAyOjAwLjEKPiByZWdpc3Rl cmluZyBuZXRiYWNrCj4gSVQ4NyBXRFQ6IFVua25vd24gQ2hpcCBmb3VuZCwgQ2hpcCA4NzIxIFJl dmlzaW9uIDAwMDEKPiBbRmlybXdhcmUgQnVnXTogcG93ZXJub3ctazg6IE5vIGNvbXBhdGlibGUg QUNQSSBfUFNTIG9iamVjdHMgZm91bmQuCj4gW0Zpcm13YXJlIEJ1Z106IHBvd2Vybm93LWs4OiBU cnkgYWdhaW4gd2l0aCBsYXRlc3QgQklPUy4KPiBMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLgo+IElO SVQ6IHZlcnNpb24gMi44OCBib290aW5nCj4gVXNpbmcgbWFrZWZpbGUtc3R5bGUgY29uY3VycmVu dCBib290IGluIHJ1bmxldmVsIFMuCj4gU3RhcnRpbmcgdGhlIGhvdHBsdWcgZXZlbnRzIGRpc3Bh dGNoZXI6IHVkZXZkLgo+IFN5bnRoZXNpemluZyB0aGUgaW5pdGlhbCBob3RwbHVnIGV2ZW50cy4u LmRvbmUuCj4gV2FpdGluZyBmb3IgL2RldiB0byBiZSBmdWxseSBwb3B1bGF0ZWQuLi51ZGV2ZC13 b3JrWzE0MjldOiBrZXJuZWwtcHJvdmlkZWQgbmFtZSAnYmxrdGFwLWNvbnRyb2wnIGFuZCBOQU1F PSAneGVuL2Jsa3RhcC0yL2NvbnRyb2wnIGRpc2FncmVlLCBwbGVhc2UgdXNlIFNZTUxJTksrPSBv ciBjaGFuZ2UgdGhlIGtlcm5lbCB0byBwcm92aWRlIHRoZSBwcm9wZXIgbmFtZQo+IAo+IGRvbmUu Cj4gU2V0dGluZyBwcmVsaW1pbmFyeSBrZXltYXAuLi5kb25lLgo+IEFjdGl2YXRpbmcgc3dhcC4u LmRvbmUuCj4gQ2hlY2tpbmcgcm9vdCBmaWxlIHN5c3RlbS4uLmZzY2sgZnJvbSB1dGlsLWxpbnV4 LW5nIDIuMTcuMgo+IEhPV1RPX1JPT1Q6IGNsZWFuLCA5NTA1Ni8xNDE5ODQwIGZpbGVzLCA3MzEy MDcvNTY3OTEwNCBibG9ja3MgKGNoZWNrIGluIDMgbW91bnRzKQo+IGRvbmUuCj4gTG9hZGluZyBr ZXJuZWwgbW9kdWxlcy4uLmRvbmUuCj4gQ2xlYW5pbmcgdXAgaWZ1cGRvd24uLi4uCj4gU2V0dGlu ZyB1cCBuZXR3b3JraW5nLi4uLgo+IFNldHRpbmcgdXAgTFZNIFZvbHVtZSBHcm91cHMgIFJlYWRp bmcgYWxsIHBoeXNpY2FsIHZvbHVtZXMuICBUaGlzIG1heSB0YWtlIGEgd2hpbGUuLi4KPiAgIEZv dW5kIHZvbHVtZSBncm91cCAibGVtcm91Y2giIHVzaW5nIG1ldGFkYXRhIHR5cGUgbHZtMgo+ICAg NCBsb2dpY2FsIHZvbHVtZShzKSBpbiB2b2x1bWUgZ3JvdXAgImxlbXJvdWNoIiBub3cgYWN0aXZl Cj4gLgo+IEFjdGl2YXRpbmcgbHZtIGFuZCBtZCBzd2FwLi4uZG9uZS4KPiBDaGVja2luZyBmaWxl IHN5c3RlbXMuLi5mc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBkb25lLgo+IE1vdW50 aW5nIGxvY2FsIGZpbGVzeXN0ZW1zLi4uZG9uZS4KPiBBY3RpdmF0aW5nIHN3YXBmaWxlIHN3YXAu Li5kb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTZXR0aW5nIGtlcm5l bCB2YXJpYWJsZXMgLi4uZG9uZS4KPiBDb25maWd1cmluZyBuZXR3b3JrIGludGVyZmFjZXMuLi5k b25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTZXR0aW5nIGNvbnNvbGUg c2NyZWVuIG1vZGVzLgo+IFJjYW5ub3QgKHVuKXNldCBwb3dlcnNhdmUgbW9kZQo+IFNraXBwaW5n IGZvbnQgYW5kIGtleW1hcCBzZXR1cCAoaGFuZGxlZCBieSBjb25zb2xlLXNldHVwKS4KPiBTZXR0 aW5nIHVwIGNvbnNvbGUgZm9udCBhbmQga2V5bWFwLi4uZG9uZS4KPiBJTklUOiBFbnRlcmluZyBy dW5sZXZlbDogMgo+IFVzaW5nIG1ha2VmaWxlLXN0eWxlIGNvbmN1cnJlbnQgYm9vdCBpbiBydW5s ZXZlbCAyLgo+IGFjcGlkOiBzdGFydGluZyB1cCB3aXRoIHByb2MgZnMKPiAKPiBhY3BpZDogMSBy dWxlIGxvYWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcg aXMgb2ZmCj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0g bWVzc2FnZSBidXM6IGRidXMuCj4gU3RhcnRpbmcgcGVyaW9kaWMgY29tbWFuZCBzY2hlZHVsZXI6 IGNyb24uCj4gU3RhcnRpbmcgT3BlbkJTRCBTZWN1cmUgU2hlbGwgc2VydmVyOiBzc2hkLgo+IFN0 YXJ0aW5nIHhlbnN0b3JlZC4uLlhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVO QlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw dSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFi bGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+ IAo+IFNldHRpbmcgZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4g QkxLVEFQQ1RSTFsyMTU2XTogYmxrdGFwY3RybC5jOjc5MDogYmxrdGFwY3RybDogdjEuMC4wCj4g Cj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxrdGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbcmF3 IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo3OTI6IEZv dW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxr dGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBC TEtUQVBDVFJMWzIxNTZdOiBibGt0YXBjdHJsLmM6NzkyOiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNr IGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo3OTI6IEZv dW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RSTFsyMTU2XTogYmxr dGFwY3RybC5jOjc5MjogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJM S1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxl ZAo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo4NTk6IGNvdWxkbid0IG9wZW4g YmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENUUkxbMjE1Nl06IGJsa3RhcGN0cmwuYzo5MjI6 IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2Ug MDA6MTIuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwOjEyLjIKPiAvdXNyL2xvY2FsL2Jpbi94 ZW5fc3RhcnQuc2g6IGxpbmUgMTU6IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDc6MDAuMC9k cml2ZXIvdW5iaW5kOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gVXNpbmcgY29uZmlnIGZp bGUgIi9ldGMveGVuL3dpbmRvd3MiLgo+IChYRU4pIGRvbWN0bC5jOjEwNDI6ZDAgaW9wb3J0X21h cDphZGQgZl9ncG9ydD0zYjAgZl9tcG9ydD0zYjAgbnA9Ywo+IChYRU4pIGRvbWN0bC5jOjk4Njpk MCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWEwIG1mbj1hMCBucl9tZm5zPTIwCj4gKFhFTikgZG9tY3Rs LmM6MTA0MjpkMCBpb3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNjMCBmX21wb3J0PTNjMCBucD0zCj4g KFhFTikgZG9tY3RsLmM6MTA0MjpkMCBpb3BvcnRfbWFwOmFkZCBmX2dwb3J0PTNjNCBmX21wb3J0 PTNjNCBucD0xYwo+IChYRU4pIEhWTTE6IEhWTSBMb2FkZXIKPiAoWEVOKSBIVk0xOiBEZXRlY3Rl ZCBYZW4gdjQuMi11bnN0YWJsZQo+IChYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAw MCwgZXZlbnQgY2hhbm5lbCA3Cj4gU3RhcnRlZCBkb21haW4gd2luZG93cyAoaWQ9MSkoWEVOKSBI Vk0xOiBTeXN0ZW0gcmVxdWVzdGVkIFJPTUJJT1MKPiAKPiAoWEVOKSBIVk0xOiBDUFUgc3BlZWQg aXMgMzAxMCBNSHoKPiAoWEVOKSBpcnEuYzoyNTg6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDAg LT4gNQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikg aXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCj4gKFhFTikgSFZNMTog UENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBD SSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExCj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDIgcm91 dGVkIHRvIElSUTExCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDMgY2hhbmdlZCAw IC0+IDUKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQo+IChYRU4p IEhWTTE6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6 MCBJTlRBLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIElOVEEtPklSUTUKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2 OjAgSU5UQi0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBJTlRBLT5JUlE1Cj4gKFhF TikgSFZNMTogcGNpIGRldiAwODowIElOVEItPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAw OTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxMCBzaXplIDEw MDAwMDAwOiBlMDAwMDAwYwo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDog Z2ZuPWUwMDAwIG1mbj1kMDAwMCBucl9tZm5zPTEwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAw MzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMDAwMDAwOAo+IChYRU4pIEhWTTE6IHBjaSBkZXYg MDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjEwMDAwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6 ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnJfbWZucz0yMAo+IChYRU4p IEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTggc2l6ZSAwMDAyMDAwMDogZjEwMjAwMDQKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAwMjAwMDA6IGYxMDQwMDAwCj4gKFhF TikgSFZNMTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIDAwMDA0MDAwOiBmMTA2MDAwNAo+IChY RU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDYwIG1mbj1mZTliYyBu cl9tZm5zPTQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA5OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6 IGYxMDY0MDA0Cj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEw NjQgbWZuPWZlM2Y4IG5yX21mbnM9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAg c2l6ZSAwMDAwMTAwMDogZjEwNjgwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21h cDphZGQ6IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnJfbWZucz0xCj4gKFhFTikgSFZNMTogcGNpIGRl diAwODowIGJhciAxMCBzaXplIDAwMDAxMDAwOiBmMTA2OTAwMAo+IChYRU4pIGRvbWN0bC5jOjk4 NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDY5IG1mbj1mMDAwMCBucl9tZm5zPTEKPiAoWEVO KSBIVk0xOiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6IDAwMDBjMDAxCj4gKFhF TikgSFZNMTogcGNpIGRldiAwNTowIGJhciAyMCBzaXplIDAwMDAwMTAwOiAwMDAwYzEwMQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMyMDEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMjQxCj4g KFhFTikgSFZNMTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246Cj4gKFhFTikgSFZNMTog IC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMv OF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZp eGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0g Q1BVMiAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0g Li4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVMyAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVk IE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BV NCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4u IGRvbmUuCj4gKFhFTikgSFZNMTogIC0gQ1BVNSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U UlJzIC4uLiB2YXIgTVRSUnMgWzMvOF0gLi4uIGRvbmUuCj4gKFhFTikgSFZNMTogVGVzdGluZyBI Vk0gZW52aXJvbm1lbnQ6Cj4gKFhFTikgSFZNMTogIC0gUkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91 bmRhcmllcyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQ R1MgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6IFBhc3NlZCAyIG9mIDIgdGVzdHMKPiAoWEVOKSBI Vk0xOiBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCj4gKFhFTikgSFZNMTogTG9hZGluZyBST01C SU9TIC4uLgo+IChYRU4pIEhWTTE6IDk2NjAgYnl0ZXMgb2YgUk9NQklPUyBoaWdoLW1lbW9yeSBl eHRlbnNpb25zOgo+IChYRU4pIEhWTTE6ICAgUmVsb2NhdGluZyB0byAweGZjMDAwMDAwLTB4ZmMw MDI1YmMgLi4uIGRvbmUKPiAoWEVOKSBIVk0xOiBDcmVhdGluZyBNUCB0YWJsZXMgLi4uCj4gKFhF TikgSFZNMTogTG9hZGluZyBWR0FCSU9TIG9mIHBhc3N0aHJvdWdoZWQgZ2Z4IC4uLgo+IChYRU4p IEhWTTE6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uCj4gKFhFTikgSFZNMTogIC0gTWFudWZh Y3R1cmVyOiBodHRwOi8vZXRoZXJib290Lm9yZwo+IChYRU4pIEhWTTE6ICAtIFByb2R1Y3QgbmFt ZTogZ1BYRQo+IChYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBIVk0xOiAgLSBM byBkYXRhOiAwMDBlYTAyMC0wMDBlYTA0Zgo+IChYRU4pIEhWTTE6ICAtIEhpIGRhdGE6IGZjMDAy ODAwLWZjMDEyOTFmCj4gKFhFTikgSFZNMTogdm04NiBUU1MgYXQgZmMwMTJjMDAKPiAoWEVOKSBI Vk0xOiBCSU9TIG1hcDoKPiAoWEVOKSBIVk0xOiAgYzAwMDAtY2ZmZmY6IFZHQSBCSU9TCj4gKFhF TikgSFZNMTogIGQwMDAwLWUxZmZmOiBFdGhlcmJvb3QgUk9NCj4gKFhFTikgSFZNMTogIGViMDAw LWViMjBmOiBTTUJJT1MgdGFibGVzCj4gKFhFTikgSFZNMTogIGYwMDAwLWZmZmZmOiBNYWluIEJJ T1MKPiAoWEVOKSBIVk0xOiBFODIwIHRhYmxlOgo+IChYRU4pIEhWTTE6ICBbMDBdOiAwMDAwMDAw MDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0KPiAoWEVOKSBIVk0xOiAgWzAxXTog MDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDA5ZmMwMDogUkVTRVJWRUQKPiAoWEVOKSBI Vk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwOWZjMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVTRVJW RUQKPiAoWEVOKSBIVk0xOiAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBl MDAwMAo+IChYRU4pIEhWTTE6ICBbMDNdOiAwMDAwMDAwMDowMDBlMDAwMCAtIDAwMDAwMDAwOjAw MTAwMDAwOiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBbMDRdOiAwMDAwMDAwMDowMDEwMDAwMCAt IDAwMDAwMDAwOmUwMDAwMDAwOiBSQU0KPiAoWEVOKSBIVk0xOiAgSE9MRTogMDAwMDAwMDA6ZTAw MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMAo+IChYRU4pIEhWTTE6ICBbMDVdOiAwMDAwMDAwMDpm YzAwMDAwMCAtIDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBbMDZd OiAwMDAwMDAwMTowMDAwMDAwMCAtIDAwMDAwMDAxOjIwMDAwMDAwOiBSQU0KPiAoWEVOKSBIVk0x OiBJbnZva2luZyBST01CSU9TIC4uLgo+IChYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEgJCAk RGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkCj4gKFhFTikgSFZNMTogQm9jaHMgQklPUyAtIGJ1 aWxkOiAwNi8yMy85OQo+IChYRU4pIEhWTTE6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAw OC8xMi8wNyAxNzozMjoyOSAkCj4gKFhFTikgSFZNMTogT3B0aW9uczogYXBtYmlvcyBwY2liaW9z IGVsdG9yaXRvIFBNTSAKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBhdGEwLTA6IFBDSFM9 MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMKPiAoWEVOKSBIVk0x OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDIwNDgwIE1CeXRl cykKPiAoWEVOKSBIVk0xOiBhdGEwLTE6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJh IExDSFM9MTAyNC8yNTUvNjMKPiAoWEVOKSBIVk0xOiBhdGEwICBzbGF2ZTogUUVNVSBIQVJERElT SyBBVEEtNyBIYXJkLURpc2sgKDUxMjAwIE1CeXRlcykKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBI Vk0xOiAKPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBQcmVzcyBGMTIgZm9yIGJvb3QgbWVu dS4KPiAoWEVOKSBIVk0xOiAKPiAoWEVOKSBIVk0xOiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4u Cj4gKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIDAwMDA6N2MwMAo+IChYRU4pIGlycS5jOjI1ODog RG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBD SSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5r IDIgY2hhbmdlZCAxMSAtPiAwCj4gKFhFTikgaXJxLmM6MjU4OiBEb20xIFBDSSBsaW5rIDMgY2hh bmdlZCA1IC0+IDAKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdm bj1lMDAwMCBtZm49ZDAwMDAgbnJfbWZucz0xMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBt ZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikg ZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21m bnM9MTAwMDAKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAy MCBtZm49ZmU5ZTAgbnJfbWZucz0yMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFw OnJlbW92ZTogZ2ZuPWYxMDYwIG1mbj1mZTliYyBucl9tZm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5 ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2MCBtZm49ZmU5YmMgbnJfbWZucz00Cj4gKFhF TikgZG9tY3RsLmM6OTk2OmQwIG1lbW9yeV9tYXA6cmVtb3ZlOiBnZm49ZjEwNjggbWZuPWZlM2Y3 IG5yX21mbnM9MQo+IChYRU4pIGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYx MDY4IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21h cDpyZW1vdmU6IGdmbj1mMTA2OSBtZm49ZjAwMDAgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6 OTg2OmQwIG1lbW9yeV9tYXA6YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChY RU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY0IG1mbj1mZTNm OCBucl9tZm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1m MTA2NCBtZm49ZmUzZjggbnJfbWZucz00Cj4gKFhFTikgZ3JhbnRfdGFibGUuYzoxMTU2OmQxIEV4 cGFuZGluZyBkb20gKDEpIGdyYW50IHRhYmxlIGZyb20gKDQpIHRvICgzMikgZnJhbWVzLgo+IChY RU4pIGlycS5jOjMyNDogRG9tMSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBHU0kgMjgKPiAoWEVO KSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdmbj1lMDAwMCBtZm49ZDAwMDAg bnJfbWZucz0xMDAwMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTog Z2ZuPWYxMDIwIG1mbj1mZTllMCBucl9tZm5zPTIwCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1l bW9yeV9tYXA6YWRkOiBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yX21mbnM9MTAwMDAKPiAoWEVOKSBk b21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnJfbWZu cz0yMAo+IChYRU4pIGRvbWN0bC5jOjk5NjpkMCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY4 IG1mbj1mZTNmNyBucl9tZm5zPTEKPiAoWEVOKSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDph ZGQ6IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6OTk2OmQw IG1lbW9yeV9tYXA6cmVtb3ZlOiBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yX21mbnM9NAo+IChYRU4p IGRvbWN0bC5jOjk4NjpkMCBtZW1vcnlfbWFwOmFkZDogZ2ZuPWYxMDYwIG1mbj1mZTliYyBucl9t Zm5zPTQKPiAoWEVOKSBkb21jdGwuYzo5OTY6ZDAgbWVtb3J5X21hcDpyZW1vdmU6IGdmbj1mMTA2 OSBtZm49ZjAwMDAgbnJfbWZucz0xCj4gKFhFTikgZG9tY3RsLmM6OTg2OmQwIG1lbW9yeV9tYXA6 YWRkOiBnZm49ZjEwNjkgbWZuPWYwMDAwIG5yX21mbnM9MQo+IChYRU4pIGRvbWN0bC5jOjk5Njpk MCBtZW1vcnlfbWFwOnJlbW92ZTogZ2ZuPWYxMDY0IG1mbj1mZTNmOCBucl9tZm5zPTQKPiAoWEVO KSBkb21jdGwuYzo5ODY6ZDAgbWVtb3J5X21hcDphZGQ6IGdmbj1mMTA2NCBtZm49ZmUzZjggbnJf bWZucz00Cgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX18gICAgICAgICAgICAgICAg ICAgICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8 X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKPiAgIFwgIC8v IF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf IFx8IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IC8gX18vfF9ffCB8X3wgfCB8 IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xfXF9fX3xffCB8X3wgICAgfF98 KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEAobm9u ZSkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgpICkgU2F0IE1heSAgNSAxNTo0 ODo0OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBGcmkgTWF5IDA0IDExOjE4 OjQ4IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhFTikgQ29uc29sZSBvdXRwdXQg aXMgc3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0 K3NxdWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBk b20wX21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUg Y29tMT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1h dGlvbjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikg IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhF TikgRGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChY RU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAg UkFNIG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVz YWJsZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy dmVkKQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2 ZWQpCj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUp Cj4gKFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEp Cj4gKFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykK PiAoWEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+ IChYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4g KFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhF TikgQUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhT RFQgQ0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAg IDk3KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0 MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2 RTMgKHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFD UEk6IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4 IChyMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJ OiBNQ0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAg ICAgICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VN QjE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMw LCAwMDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVO KSBBQ1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEg QU1EICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0g SSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4 MTkwTUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAo WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+ IChYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxl IGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2 ZXIgZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikg QUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+ IChYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19z aXplWzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAo WEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJ QyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3Nv ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ QyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRb MHgwM10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYK PiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVk KQo+IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJv Y2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFj cGlfaWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElD IChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJ Q1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIz Cj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9i YXNlWzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVz cyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg YnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZS IChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJ UlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRl Lgo+IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBB UElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlk OiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCEKPiAo WEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24K PiAoWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVnIENQVXMpCj4gKFhFTikgSVJR IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjog U01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjIyNSBN SHogcHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1E IEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgUENJOiBNQ0ZH IGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBm Zgo+IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYK PiAoWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVOKSBBTUQtVmk6IEVuYWJsaW5n IGdsb2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAo WEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMK PiAoWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9 MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGlt ZXIgaXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0 IEtpQi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQg YWR2YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4g KFhFTikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikg IC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBG aWx0ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Np c3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0 a0IsIDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9p ZD0weDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lk PTB4MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9 MHgxMDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w eDEwMDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIG1pY3JvY29kZTogY29s bGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgSFBFVCdzIE1TSSBtb2Rl IGhhc24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxl ZC4KPiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4pIE1DQTogVXNlIGh3IHRocmVz aG9sZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAoWEVOKSBtY2hlY2tfcG9sbDog TWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4gKFhFTikgWGVub3Byb2ZpbGU6 IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZgo+IChY RU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBo ZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDViMjAwMAo+IChYRU4pIGVsZl9wYXJzZV9iaW5h cnk6IHBoZHI6IHBhZGRyPTB4MTViMjAwMCBtZW1zej0weDY2MGUwCj4gKFhFTikgZWxmX3BhcnNl X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxNjE5MDAwIG1lbXN6PTB4MTI1MDAKPiAoWEVOKSBlbGZf cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2MmMwMDAgbWVtc3o9MHgyMWIwMDAKPiAoWEVO KSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDE4NDcwMDAKPiAoWEVO KSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igo+IChYRU4pIGVsZl94ZW5f cGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9u b3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog VklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl OiBFTlRSWSA9IDB4ZmZmZmZmZmY4MTYyYzIwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNl X25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVf NGdiIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIgo+IChYRU4p IGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMiCj4gKFhFTikgZWxmX3hlbl9w YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+IChYRU4pIGVsZl94ZW5fcGFy c2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6 IEhWX1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6 IGFkZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw MDAwMAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCj4gKFhFTikgICAgIHZpcnRf b2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9rc3RhcnQg ICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0g MHhmZmZmZmZmZjgxODQ3MDAwCj4gKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZm ZmZmODE2MmMyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZm ZmZmZgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCj4gKFhFTikg IERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxODQ3 MDAwCj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBEb20wIGFs bG9jLjogICAwMDAwMDAwMjI2MDAwMDAwLT4wMDAwMDAwMjI4MDAwMDAwICg1MTQ1MDAgcGFnZXMg dG8gYmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjJmOWM0MDAw LT4wMDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4g KFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODE4NDcwMDAK PiAoWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MTg0NzAwMC0+ZmZmZmZmZmY4MWU4MjIw MAo+IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgxZTgzMDAwLT5mZmZmZmZmZjgyMjgz MDAwCj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODIyODMwMDAtPmZmZmZmZmZmODIy ODM0YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjI4NDAwMC0+ZmZmZmZmZmY4 MjI5OTAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyMjk5MDAwLT5mZmZmZmZm ZjgyMjlhMDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZm ZmZmODI0MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTYyYzIwMAo+IChY RU4pIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk ciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODE1YjIwMDAKPiAoWEVOKSBl bGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1YjIwMDAgLT4gMHhmZmZmZmZm ZjgxNjE4MGUwCj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgx NjE5MDAwIC0+IDB4ZmZmZmZmZmY4MTYyYjUwMAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhk ciAzIGF0IDB4ZmZmZmZmZmY4MTYyYzAwMCAtPiAweGZmZmZmZmZmODE2YjIwMDAKPiAoWEVOKSBT Y3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2 aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChYRU4pIFN0ZC4gTG9nbGV2ZWw6 IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVOKSAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikgKioqKioqKiBXQVJOSU5HOiBD T05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoqKioqKiogVGhpcyBvcHRpb24g aXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkgZW5zdXJpbmcKPiAoWEVOKSAq KioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5IGRlbGl2ZXJlZCBvbiB0aGUg c2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lH TklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAqKioqKioqIHRpbWVrZWVwaW5n LiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQo+IChYRU4pICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPiAoWEVOKSAzLi4uIDIu Li4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScg dGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAoWEVOKSBGcmVlZCAyNTZrQiBp bml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQo+IFhlbjog c2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgo+IEluaXRp YWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lz IGNwdQo+IExpbnV4IHZlcnNpb24gMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IChyb290 QHhlbikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjNiBTTVAgUFJFRU1Q VCBTYXQgTWF5IDUgMjA6MTM6MjkgQ0VTVCAyMDEyCj4gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRl ciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBj aWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IEZyZWVp bmcgIDlhLTEwMCBwZm4gcmFuZ2U6IDEwMiBwYWdlcyBmcmVlZAo+IFJlbGVhc2VkIDEwMiBwYWdl cyBvZiB1bnVzZWQgbWVtb3J5Cj4gU2V0IDE5NzA5NCBwYWdlKHMpIHRvIDEtMSBtYXBwaW5nCj4g QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAwMDAwMDAwMDAwMDAg LSAwMDAwMDAwMDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAwMDA5YWMwMCAtIDAw MDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAw MDAwMGNmZTgwMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDBjZmU4MDAwMCAtIDAwMDAwMDAw Y2ZlOTgwMDAgKEFDUEkgZGF0YSkKPiAgWGVuOiAwMDAwMDAwMGNmZTk4MDAwIC0gMDAwMDAwMDBj ZmVjMDAwMCAoQUNQSSBOVlMpCj4gIFhlbjogMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2Zm MDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAx MDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzIwMDAwIC0gMDAwMDAwMDBmZWMyMTAw MCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAg KHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy ZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDIzMDAwMDAwMCAodXNh YmxlKQo+IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChFeGVjdXRlIERpc2Fi bGUpIHByb3RlY3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOgo+ ICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAodXNhYmxlKQo+ICB1 c2VyOiAwMDAwMDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gIHVz ZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCj4gIHVzZXI6 IDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gIHVzZXI6 IDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAgdXNlcjog MDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAw MDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAw MDAwMDAwZmVjMjAwMDAgLSAwMDAwMDAwMGZlYzIxMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAw MDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAwMDAw MDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gRE1JIHByZXNlbnQu Cj4gTm8gQUdQIGJyaWRnZSBmb3VuZAo+IGxhc3RfcGZuID0gMHg4MDAwMCBtYXhfYXJjaF9wZm4g PSAweDQwMDAwMDAwMAo+IGZvdW5kIFNNUCBNUC10YWJsZSBhdCBbZmZmZjg4MDAwMDBmZjc4MF0g ZmY3ODAKPiBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwODAw MDAwMDAKPiBSQU1ESVNLOiAwMTg0NzAwMCAtIDAxZTgzMDAwCj4gQUNQSTogUlNEUCAwMDAwMDAw MDAwMGZiZjIwIDAwMDI0ICh2MDIgQUNQSUFNKQo+IEFDUEk6IFhTRFQgMDAwMDAwMDBjZmU4MDEw MCAwMDA1QyAodjAxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFD UEk6IEZBQ1AgMDAwMDAwMDBjZmU4MDI5MCAwMDBGNCAodjAzIDEwMjgxMSBGQUNQMTc0MCAyMDEx MTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IERTRFQgMDAwMDAwMDBjZmU4MDQ3MCAwRTZFMyAo djAxICBBMTU5NSBBMTU5NTAwMCAwMDAwMDAwMCBJTlRMIDIwMDYwMTEzKQo+IEFDUEk6IEZBQ1Mg MDAwMDAwMDBjZmU5ODAwMCAwMDA0MAo+IEFDUEk6IEFQSUMgMDAwMDAwMDBjZmU4MDM5MCAwMDA5 OCAodjAxIDEwMjgxMSBBUElDMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IE1D RkcgMDAwMDAwMDBjZmU4MDQzMCAwMDAzQyAodjAxIDEwMjgxMSBPRU1NQ0ZHICAyMDExMTAyOCBN U0ZUIDAwMDAwMDk3KQo+IEFDUEk6IE9FTUIgMDAwMDAwMDBjZmU5ODA0MCAwMDA3MiAodjAxIDEw MjgxMSBPRU1CMTc0MCAyMDExMTAyOCBNU0ZUIDAwMDAwMDk3KQo+IEFDUEk6IEhQRVQgMDAwMDAw MDBjZmU4ZjhjMCAwMDAzOCAodjAxIDEwMjgxMSBPRU1IUEVUICAyMDExMTAyOCBNU0ZUIDAwMDAw MDk3KQo+IEFDUEk6IElWUlMgMDAwMDAwMDBjZmU4ZjkwMCAwMDBFMCAodjAxICBBTUQgICAgIFJE ODkwUyAwMDIwMjAzMSBBTUQgIDAwMDAwMDAwKQo+IEFDUEk6IFNTRFQgMDAwMDAwMDBjZmU4Zjll MCAwMEUxMCAodjAxIEEgTSBJICBQT1dFUk5PVyAwMDAwMDAwMSBBTUQgIDAwMDAwMDAxKQo+IE5v IE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZAo+IEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAw MDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gSW5pdG1lbSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAw MDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gICBOT0RFX0RBVEEgWzAwMDAwMDAwN2ZmZmIwMDAgLSAw MDAwMDAwMDdmZmZmZmZmXQo+IFpvbmUgUEZOIHJhbmdlczoKPiAgIERNQSAgICAgIDB4MDAwMDAw MTAgLT4gMHgwMDAwMTAwMAo+ICAgRE1BMzIgICAgMHgwMDAwMTAwMCAtPiAweDAwMTAwMDAwCj4g ICBOb3JtYWwgICBlbXB0eQo+IE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQo+ IGVhcmx5X25vZGVfbWFwWzJdIGFjdGl2ZSBQRk4gcmFuZ2VzCj4gICAgIDA6IDB4MDAwMDAwMTAg LT4gMHgwMDAwMDA5YQo+ICAgICAwOiAweDAwMDAwMTAwIC0+IDB4MDAwODAwMDAKPiBBQ1BJOiBQ TS1UaW1lciBJTyBQb3J0OiAweDgwOAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGlj X2lkWzB4MDBdIGVuYWJsZWQpCj4gQklPUyBidWc6IEFQSUMgdmVyc2lvbiBpcyAwIGZvciBDUFUg MC8weDAsIGZpeGluZyB1cCB0byAweDEwCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw aWNfaWRbMHgwMV0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p ZFsweDAyXSBlbmFibGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4 MDNdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0g ZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFi bGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDddIGxhcGljX2lkWzB4ODZdIGRpc2FibGVk KQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDhdIGxhcGljX2lkWzB4ODddIGRpc2FibGVkKQo+ IEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkK PiBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMwMDAwMCwg R1NJIDAtMjU1Cj4gQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdz aV9iYXNlWzI0XSkKPiBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAyNTUsIGFkZHJlc3Mg MHhmZWMyMDAwMCwgR1NJIDI0LTI3OQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJx IDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpCj4gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19p cnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQo+IFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAg Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgo+IEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAw eGZlZDAwMDAwCj4gOCBQcm9jZXNzb3JzIGV4Y2VlZHMgTlJfQ1BVUyBsaW1pdCBvZiA2Cj4gU01Q OiBBbGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzCj4gQWxsb2NhdGluZyBQQ0kgcmVzb3Vy Y2VzIHN0YXJ0aW5nIGF0IDgwMDAwMDAwIChnYXA6IDgwMDAwMDAwOjRmZTgwMDAwKQo+IEJvb3Rp bmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBYZW4KPiBYZW4gdmVyc2lvbjogNC4yLXVuc3Rh YmxlIChwcmVzZXJ2ZS1BRCkKPiBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6NiBucl9jcHVtYXNrX2Jp dHM6NiBucl9jcHVfaWRzOjYgbnJfbm9kZV9pZHM6MQo+IFBFUkNQVTogRW1iZWRkZWQgMjYgcGFn ZXMvY3B1IEBmZmZmODgwMDdmZjRiMDAwIHM3NTAwOCByODE5MiBkMjMyOTYgdTEwNjQ5Ngo+IEJ1 aWx0IDEgem9uZWxpc3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90 YWwgcGFnZXM6IDUxNDk3Mwo+IFBvbGljeSB6b25lOiBETUEzMgo+IEtlcm5lbCBjb21tYW5kIGxp bmU6IHBsYWNlaG9sZGVyIHJvb3Q9L2Rldi9tYXBwZXIvbGVtcm91Y2gteGVuIHJvIG1lbT0yRyBw YW5pYz0xNSB4ZW4tcGNpYmFjay5oaWRlPSgwMDoxNC4yKSBjb25zb2xlPWh2YzAgZWFybHlwcmlu dGs9eGVuCj4gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5 dGVzKQo+IFBsYWNpbmcgNjRNQiBzb2Z0d2FyZSBJTyBUTEIgYmV0d2VlbiBmZmZmODgwMDc5NjAw MDAwIC0gZmZmZjg4MDA3ZDYwMDAwMAo+IHNvZnR3YXJlIElPIFRMQiBhdCBwaHlzIDB4Nzk2MDAw MDAgLSAweDdkNjAwMDAwCj4gTWVtb3J5OiAxOTc1MjIway8yMDk3MTUyayBhdmFpbGFibGUgKDQ0 NzBrIGtlcm5lbCBjb2RlLCA0NzJrIGFic2VudCwgMTIxNDYwayByZXNlcnZlZCwgMTc2OGsgZGF0 YSwgNTk2ayBpbml0KQo+IFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0LCBPcmRlcj0wLTMs IE1pbk9iamVjdHM9MCwgQ1BVcz02LCBOb2Rlcz0xCj4gUHJlZW1wdGlibGUgaGllcmFyY2hpY2Fs IFJDVSBpbXBsZW1lbnRhdGlvbi4KPiAJVmVyYm9zZSBzdGFsbGVkLUNQVXMgZGV0ZWN0aW9uIGlz IGRpc2FibGVkLgo+IE5SX0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVy cmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5 Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6 IGNvbG91ciBWR0ErIDgweDI1Cj4gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg ZGlzYWJsZWQKPiBjb25zb2xlIFtodmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+ IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjI0IE1IeiBw cm9jZXNzb3IuCj4gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNjAyMC40NCBCb2dvTUlQUyAobHBqPTMwMTAy MjQpCj4gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hl IGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJ bm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYg Ynl0ZXMpCj4gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBkZXZpY2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQ cm9jZXNzb3IgSUQ6IDAKPiBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gQUNQSTogQ29yZSBy ZXZpc2lvbiAyMDExMDYyMwo+IGNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSAyOTcKPiBQZXJmb3Jt YW5jZSBFdmVudHM6IChYRU4pIHRyYXBzLmM6MjU2MTpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlNGE3NWRmODY1MTQgdG8gMHgwMDAwMDAwMDAw MDBhYmNkLgo+IEJyb2tlbiBQTVUgaGFyZHdhcmUgZGV0ZWN0ZWQsIHVzaW5nIHNvZnR3YXJlIGV2 ZW50cyBvbmx5Lgo+IE1DRTogSW4ta2VybmVsIE1DRSBkZWNvZGluZyBlbmFibGVkLgo+IGluc3Rh bGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQo+IGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAzMDMK PiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIKPiBjcHUgMiBzcGlubG9jayBldmVudCBp cnEgMzA5Cj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAzCj4gY3B1IDMgc3BpbmxvY2sg ZXZlbnQgaXJxIDMxNQo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgNAo+IGNwdSA0IHNw aW5sb2NrIGV2ZW50IGlycSAzMjEKPiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDUKPiBj cHUgNSBzcGlubG9jayBldmVudCBpcnEgMzI3Cj4gQnJvdWdodCB1cCA2IENQVXMKPiBkZXZ0bXBm czogaW5pdGlhbGl6ZWQKPiBHcmFudCB0YWJsZSBpbml0aWFsaXplZAo+IE5FVDogUmVnaXN0ZXJl ZCBwcm90b2NvbCBmYW1pbHkgMTYKPiBUT006IDAwMDAwMDAwZDAwMDAwMDAgYWthIDMzMjhNCj4g VE9NMjogMDAwMDAwMDIzMDAwMDAwMCBha2EgODk2ME0KPiBFeHRlbmRlZCBDb25maWcgU3BhY2Ug ZW5hYmxlZCBvbiAxIG5vZGVzCj4gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQKPiBQQ0k6 IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAwMDAt MHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKPiBQQ0k6IG5vdCB1c2luZyBNTUNPTkZJRwo+ IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzCj4gUENJOiBV c2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgZXh0ZW5kZWQgYWNjZXNzCj4gYmlvOiBjcmVh dGUgc2xhYiA8YmlvLTA+IGF0IDAKPiBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpCj4g QUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgRGV2aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koMy4w IF9TQ1AgRXh0ZW5zaW9ucykKPiBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9y IERldmljZSkKPiBBQ1BJOiBFeGVjdXRlZCAzIGJsb2NrcyBvZiBtb2R1bGUtbGV2ZWwgZXhlY3V0 YWJsZSBBTUwgY29kZQo+IEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKPiBBQ1BJOiAoc3VwcG9y dHMgUzAgUzUpCj4gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZwo+IFBD STogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAw MC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQo+IFBDSTogTU1DT05GSUcgYXQgW21lbSAw eGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2VydmVkIGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3Vy Y2VzCj4gQUNQSTogRUM6IEdQRSA9IDB4YSwgSS9POiBjb21tYW5kL3N0YXR1cyA9IDB4NjYsIGRh dGEgPSAweDYyCj4gSEVTVDogVGFibGUgbm90IGZvdW5kLgo+IFBDSTogVXNpbmcgaG9zdCBicmlk Z2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCBy ZXBvcnQgYSBidWcKPiBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBb YnVzIDAwLWZmXSkKPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lv ICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRv dyBbaW8gIDB4MGQwMC0weGZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ug d2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6MDA6 IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfcm9v dCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZmZmZm ZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhmMDAw MDAwMC0weGZlYmZmZmZmXQo+IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw Ny0wN10KPiBwY2kgMDAwMDowNjowMC4wOiBkaXNhYmxpbmcgQVNQTSBvbiBwcmUtMS4xIFBDSWUg ZGV2aWNlLiAgWW91IGNhbiBlbmFibGUgaXQgd2l0aCAncGNpZV9hc3BtPWZvcmNlJwo+IHBjaSAw MDAwOjAwOjA0LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0wNl0KPiBwY2kgMDAwMDowMDowNS4w OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDUtMDVdCj4gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA0LTA0XQo+IHBjaSAwMDAwOjAwOjA3LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw My0wM10KPiBwY2kgMDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdCj4gcGNp IDAwMDA6MDA6MTQuNDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXSAoc3VidHJhY3RpdmUgZGVj b2RlKQo+ICBwY2kwMDAwOjAwOiBSZXF1ZXN0aW5nIEFDUEkgX09TQyBjb250cm9sICgweDFkKQo+ ICBwY2kwMDAwOjAwOiBBQ1BJIF9PU0MgY29udHJvbCAoMHgxYykgZ3JhbnRlZAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MDAuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMAo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDAwMDA6MDA6MDQuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDUuMAo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDYuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDA6MDcuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTEuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDA6MTIuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMgo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwMDA6MDA6MTMuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMu Mgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMAo+IChYRU4pIFBDSSBhZGQgZGV2 aWNlIDAwMDA6MDA6MTQuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMwo+IChY RU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAw MDA6MDA6MTQuNQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAo+IChYRU4pIFBD SSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6 MTguMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMQo+IChYRU4pIFBDSSBhZGQg ZGV2aWNlIDAwMDA6MDA6MTguMgo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMwo+ IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNAo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDc6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDc6MDAuMQo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDY6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDY6MDAuMQo+IHBjaSAwMDAwOjA2OjAwLjE6IEZhaWxlZCB0byBhZGQgLSBwYXNzdGhyb3VnaCBv ciBNU0kvTVNJLVggbWlnaHQgZmFpbCEKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAw LjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRl dmljZSAwMDAwOjAzOjAwLjAKPiAoWEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAyOjAwLjAKPiAo WEVOKSBQQ0kgYWRkIGRldmljZSAwMDAwOjAyOjAwLjEKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOS0FdIChJUlFzICo0IDcgMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBM aW5rIFtMTktCXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQg TGluayBbTE5LQ10gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xOS0RdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVw dCBMaW5rIFtMTktFXSAoSVJRcyA0ICo3IDEwIDExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1 cHQgTGluayBbTE5LRl0gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xOS0ddIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVy cnVwdCBMaW5rIFtMTktIXSAoSVJRcyA0IDcgMTAgMTEgMTQgMTUpICowLCBkaXNhYmxlZC4KPiB4 ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLgo+IHhlbi1iYWxsb29uOiBJ bml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4gdmdhYXJiOiBkZXZpY2UgYWRkZWQ6IFBDSTow MDAwOjA3OjAwLjAsZGVjb2Rlcz1pbyttZW0sb3ducz1pbyttZW0sbG9ja3M9bm9uZQo+IHZnYWFy YjogbG9hZGVkCj4gdmdhYXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA3OjAwLjAK PiBTQ1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu dGVyZmFjZSBkcml2ZXIgdXNiZnMKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug ZHJpdmVyIGh1Ygo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiCj4g UENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZwo+IFN3aXRjaGluZyB0byBjbG9ja3NvdXJj ZSB4ZW4KPiBGUy1DYWNoZTogTG9hZGVkCj4gQ2FjaGVGaWxlczogTG9hZGVkCj4gcG5wOiBQblAg QUNQSSBpbml0Cj4gQUNQSTogYnVzIHR5cGUgcG5wIHJlZ2lzdGVyZWQKPiBzeXN0ZW0gMDA6MDE6 IFttZW0gMHhmZWMyMDAwMC0weGZlYzIwMGZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0 ZW0gMDA6MDI6IFttZW0gMHhmNjAwMDAwMC0weGY2MDAzZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+ IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgOCBmb3IgZ3NpIDgKPiB4ZW5fbWFwX3Bp cnFfZ3NpOiByZXR1cm5pbmcgaXJxIDEzIGZvciBnc2kgMTMKPiBzeXN0ZW0gMDA6MDg6IFttZW0g MHhmZWMwMDAwMC0weGZlYzAwZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6 MDg6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3Rl bSAwMDowOTogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAw MDowOTogW2lvICAweDA0MGJdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MDRkNl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzAwLTB4 MGMwMV0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzE0XSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNTAtMHgwYzUxXSBoYXMgYmVl biByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNTJdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM2Y10gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwYzZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjZDAtMHgwY2QxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAw eDBjZDItMHgwY2QzXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBj ZDQtMHgwY2Q1XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjZDYt MHgwY2Q3XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjZDgtMHgw Y2RmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA4MDAtMHgwODlm XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBiMDAtMHgwYjFmXSBo YXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBiMjAtMHgwYjNmXSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA5MDAtMHgwOTBmXSBoYXMgYmVl biByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMgYmVlbiBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweGZlMDAtMHhmZWZlXSBoYXMgYmVlbiByZXNl cnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGNmZjAwMDAwLTB4Y2ZmZmZmZmZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmZiODAwMDAtMHhmZmJmZmZmZl0gaGFz IGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZWMxMDAwMC0weGZlYzEwMDFm XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlZDgwMDAwLTB4ZmVk ODBmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDIzMC0weDAy M2ZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDI5MC0weDAyOWZd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGY0MC0weDBmNGZdIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGEzMC0weDBhM2ZdIGhhcyBi ZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjBiOiBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0g aGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDAwMDAwMC0weDAwMDlm ZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDBjMDAw MC0weDAwMGNmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGM6IFttZW0g MHgwMDBlMDAwMC0weDAwMGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6 MGM6IFttZW0gMHgwMDEwMDAwMC0weGNmZWZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKPiBz eXN0ZW0gMDA6MGM6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVz ZXJ2ZWQKPiBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBkZXZpY2VzCj4gQUNQSTogQUNQSSBidXMg dHlwZSBwbnAgdW5yZWdpc3RlcmVkCj4gcGNpYmFjayAwMDAwOjAwOjE0LjI6IHNlaXppbmcgZGV2 aWNlCj4gUE0tVGltZXIgZmFpbGVkIGNvbnNpc3RlbmN5IGNoZWNrICAoMHgweGZmZmZmZikgLSBh Ym9ydGluZy4KPiBwY2kgMDAwMDowMDowMi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDctMDddCj4g cGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0KPiBw Y2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlOTAwMDAwLTB4ZmU5ZmZm ZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0w eGRmZmZmZmZmIDY0Yml0IHByZWZdCj4gcGNpIDAwMDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBb YnVzIDA2LTA2XQo+IHBjaSAwMDAwOjAwOjA0LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAw MC0weGRmZmZdCj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTgw MDAwMC0weGZlOGZmZmZmXQo+IHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw NS0wNV0KPiBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGMwMDAtMHhj ZmZmXQo+IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU3MDAwMDAt MHhmZTdmZmZmZl0KPiBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRd Cj4gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhiMDAwLTB4YmZmZl0K PiBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNjAwMDAwLTB4ZmU2 ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQo+IHBj aSAwMDAwOjAwOjA3LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU1MDAwMDAtMHhmZTVmZmZm Zl0KPiBwY2kgMDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdCj4gcGNpIDAw MDA6MDA6MGQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhhMDAwLTB4YWZmZl0KPiBwY2kgMDAw MDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNDAwMDAwLTB4ZmU0ZmZmZmZdCj4g cGNpIDAwMDA6MDA6MTQuNDogUENJIGJyaWRnZSB0byBbYnVzIDAxLTAxXQo+IHBjaSAwMDAwOjAw OjAyLjA6IFBDSSBJTlQgQSAtPiBHU0kgNTIgKGxldmVsLCBsb3cpIC0+IElSUSA1Mgo+IHhlbl9t YXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9yIGdzaSA1Mgo+IEFscmVhZHkgc2V0dXAg dGhlIEdTSSA6NTIKPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDUyIChsZXZl bCwgbG93KSAtPiBJUlEgNTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUyIGZv ciBnc2kgNTIKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUyCj4gcGNpIDAwMDA6MDA6MDUuMDog UENJIElOVCBBIC0+IEdTSSA1MiAobGV2ZWwsIGxvdykgLT4gSVJRIDUyCj4gcGNpIDAwMDA6MDA6 MDYuMDogUENJIElOVCBBIC0+IEdTSSA1MyAobGV2ZWwsIGxvdykgLT4gSVJRIDUzCj4geGVuX21h cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MyBmb3IgZ3NpIDUzCj4gQWxyZWFkeSBzZXR1cCB0 aGUgR1NJIDo1Mwo+IHBjaSAwMDAwOjAwOjA3LjA6IFBDSSBJTlQgQSAtPiBHU0kgNTMgKGxldmVs LCBsb3cpIC0+IElSUSA1Mwo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBJTlQgQSAtPiBHU0kgNTQg KGxldmVsLCBsb3cpIC0+IElSUSA1NAo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkg Mgo+IElQIHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1 MjQyODggYnl0ZXMpCj4gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0 IChvcmRlcjogMTAsIDQxOTQzMDQgYnl0ZXMpCj4gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz OiA2NTUzNiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpCj4gVENQOiBIYXNoIHRhYmxlcyBjb25m aWd1cmVkIChlc3RhYmxpc2hlZCAyNjIxNDQgYmluZCA2NTUzNikKPiBUQ1AgcmVubyByZWdpc3Rl cmVkCj4gVURQIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVz KQo+IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5 dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQo+IFVucGFja2luZyBpbml0 cmFtZnMuLi4KPiBGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDYzODRrIGZyZWVkCj4gbWljcm9jb2Rl OiBNaWNyb2NvZGUgVXBkYXRlIERyaXZlcjogdjIuMDAgPHRpZ3JhbkBhaXZhemlhbi5mc25ldC5j by51az4sIFBldGVyIE9ydWJhCj4gTlRGUyBkcml2ZXIgMi4xLjMwIFtGbGFnczogUi9XXS4KPiBt c2dtbmkgaGFzIGJlZW4gc2V0IHRvIDM4NzAKPiBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJz ZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUzKQo+IGlvIHNjaGVkdWxlciBu b29wIHJlZ2lzdGVyZWQgKGRlZmF1bHQpCj4gcGNpZXBvcnQgMDAwMDowMDowMi4wOiBTaWduYWxp bmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDc6MDAuMDogU2ln bmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA3OjAwLjE6 IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAw OjAwOjA0LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kg MDAwMDowNjowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4g cGNpIDAwMDA6MDY6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw dAo+IHBjaWVwb3J0IDAwMDA6MDA6MDUuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F IGludGVycnVwdAo+IHBjaSAwMDAwOjA1OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAwOjAwOjA2LjA6IFNpZ25hbGluZyBQTUUgdGhy b3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNDowMC4wOiBTaWduYWxpbmcgUE1F IHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowNy4wOiBTaWdu YWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDM6MDAuMDog U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6 MDA6MGQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAw MDAwOjAyOjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBw Y2kgMDAwMDowMjowMC4xOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0 Cj4gcGNpX2hvdHBsdWc6IFBDSSBIb3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUKPiBpbnB1 dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9QTlAwQzBD OjAwL2lucHV0L2lucHV0MAo+IEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSQl0KPiBpbnB1dDogUG93 ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBXUkJOOjAwL2lucHV0L2lucHV0 MQo+IEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KPiBFUlNUOiBUYWJsZSBpcyBub3QgZm91bmQh Cj4gR0hFUzogSEVTVCBpcyBub3QgZW5hYmxlZCEKPiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0 YWxsZWQuCj4gcGNpYmFjayAwMDAwOjAwOjE0LjI6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVs LCBsb3cpIC0+IElSUSAxNgo+IHBjaWJhY2sgMDAwMDowMDoxNC4yOiBQQ0kgSU5UIEEgZGlzYWJs ZWQKPiB4ZW4tcGNpYmFjazogYmFja2VuZCBpcyB2cGNpCj4gU2VyaWFsOiA4MjUwLzE2NTUwIGRy aXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZGlzYWJsZWQKPiBzZXJpYWwgMDAwMDowMjowMC4w OiBQQ0kgSU5UIEEgLT4gR1NJIDQwIChsZXZlbCwgbG93KSAtPiBJUlEgNDAKPiBzZXJpYWwgMDAw MDowMjowMC4xOiBQQ0kgSU5UIEIgLT4gR1NJIDQxIChsZXZlbCwgbG93KSAtPiBJUlEgNDEKPiAw MDAwOjAyOjAwLjE6IHR0eVMwIGF0IEkvTyAweGE4ODAgKGlycSA9IDQxKSBpcyBhIFNUMTY2NTBW Mgo+IGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTCj4gTm9uLXZvbGF0 aWxlIG1lbW9yeSBkcml2ZXIgdjEuMwo+IEhhbmdjaGVjazogc3RhcnRpbmcgaGFuZ2NoZWNrIHRp bWVyIDAuOS4xICh0aWNrIGlzIDE4MCBzZWNvbmRzLCBtYXJnaW4gaXMgNjAgc2Vjb25kcykuCj4g SGFuZ2NoZWNrOiBVc2luZyBnZXRyYXdtb25vdG9uaWMoKS4KPiBsb29wOiBtb2R1bGUgbG9hZGVk Cj4gYWhjaSAwMDAwOjAwOjExLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+ IElSUSAxOQo+IGFoY2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA2IHBv cnRzIDYgR2JwcyAweDNmIGltcGwgU0FUQSBtb2RlCj4gYWhjaSAwMDAwOjAwOjExLjA6IGZsYWdz OiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBpbyBzbHVtIHBhcnQgCj4gc2Nz aTAgOiBhaGNpCj4gc2NzaTEgOiBhaGNpCj4gc2NzaTIgOiBhaGNpCj4gc2NzaTMgOiBhaGNpCj4g c2NzaTQgOiBhaGNpCj4gc2NzaTUgOiBhaGNpCj4gYXRhMTogU0FUQSBtYXggVURNQS8xMzMgYWJh ciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTEwMCBpcnEgMTkKPiBhdGEyOiBTQVRBIG1h eCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMTgwIGlycSAxOQo+ IGF0YTM6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUz ZmUyMDAgaXJxIDE5Cj4gYXRhNDogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2Zl MDAwIHBvcnQgMHhmZTNmZTI4MCBpcnEgMTkKPiBhdGE1OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFy IG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMzAwIGlycSAxOQo+IGF0YTY6IFNBVEEgbWF4 IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUzODAgaXJxIDE5Cj4g YWhjaSAwMDAwOjA2OjAwLjA6IFBDSSBJTlQgQSAtPiBHU0kgNDQgKGxldmVsLCBsb3cpIC0+IElS USA0NAo+IGFoY2kgMDAwMDowNjowMC4wOiBBSENJIDAwMDEuMDAwMCAzMiBzbG90cyAyIHBvcnRz IDMgR2JwcyAweDMgaW1wbCBTQVRBIG1vZGUKPiBhaGNpIDAwMDA6MDY6MDAuMDogZmxhZ3M6IDY0 Yml0IG5jcSBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2k2IDogYWhjaQo+IHNj c2k3IDogYWhjaQo+IGF0YTc6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTgxOTJAMHhmZThmZTAw MCBwb3J0IDB4ZmU4ZmUxMDAgaXJxIDQ0Cj4gYXRhODogU0FUQSBtYXggVURNQS8xMzMgYWJhciBt ODE5MkAweGZlOGZlMDAwIHBvcnQgMHhmZThmZTE4MCBpcnEgNDQKPiB0dW46IFVuaXZlcnNhbCBU VU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNgo+IHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255 YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgo+IHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMjkKPiBz a3kyIDAwMDA6MDQ6MDAuMDogUENJIElOVCBBIC0+IEdTSSA1MSAobGV2ZWwsIGxvdykgLT4gSVJR IDUxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IFl1a29uLTIgT3B0aW1hIGNoaXAgcmV2aXNpb24gMQo+ IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBhZGRyIDIwOmNmOjMwOjZkOjg5OmE1Cj4gY2RjX25j bTogMDQtQXVnLTIwMTEKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy IGNkY19uY20KPiBmaXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogUENJIElOVCBBIC0+IEdTSSA0 NiAobGV2ZWwsIGxvdykgLT4gSVJRIDQ2Cj4gZmlyZXdpcmVfb2hjaTogQWRkZWQgZnctb2hjaSBk ZXZpY2UgMDAwMDowNTowMC4wLCBPSENJIHYxLjEwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVp cmtzIDB4MTEKPiBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAo RUhDSSkgRHJpdmVyCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBQQ0kgSU5UIEIgLT4gR1NJIDE3 IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IEVIQ0kgSG9z dCBDb250cm9sbGVyCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBuZXcgVVNCIGJ1cyByZWdpc3Rl cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGFwcGx5 aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+ IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogZGVidWcgcG9ydCAxCj4gZWhjaV9oY2QgMDAwMDowMDox Mi4yOiBpcnEgMTcsIGlvIG1lbSAweGZlM2ZlNDAwCj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBV U0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMAo+IHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBmb3Vu ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIKPiB1c2IgdXNiMTogTmV3IFVTQiBkZXZp Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKPiB1c2IgdXNiMTog UHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBM aW51eCAzLjIuMC1yYzItMTEyMDItZ2QzNTA3YWYtZGlydHkgZWhjaV9oY2QKPiB1c2IgdXNiMTog U2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjIKPiBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZAo+ IGh1YiAxLTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJu aW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwo+IGVoY2lf aGNkIDAwMDA6MDA6MTMuMjogUENJIElOVCBCIC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJR IDE3Cj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lf aGNkIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51 bWJlciAyCj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAv SHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEz LjI6IGRlYnVnIHBvcnQgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0g MHhmZTNmZTgwMAo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJ IDEuMDAKPiB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlk UHJvZHVjdD0wMDAyCj4gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQ cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBD b250cm9sbGVyCj4gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAy LWdkMzUwN2FmLWRpcnR5IGVoY2lfaGNkCj4gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDow MDoxMy4yCj4gaHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0 cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAx Nwo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFBD SSBJTlQgQiAtPiBHU0kgMTcgKGxldmVsLCBsb3cpIC0+IElSUSAxNwo+IGVoY2lfaGNkIDAwMDA6 MDA6MTYuMjogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IG5l dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMwo+IGVoY2lfaGNkIDAw MDA6MDA6MTYuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1t eSBxaCB3b3JrYXJvdW5kCj4gYXRhNTogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJv bCAzMDApCj4gYXRhMzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4g YXRhMTogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApCj4g YXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhNDogU0FU QSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMjogU0FUQSBsaW5rIGRv d24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBkZWJ1 ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4ZmUzZmVj MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwCj4g YXRhMS4wMDogQVRBLTg6IElOVEVMIFNTRFNBMkNXMTIwRzMsIDRQQzEwMzYyLCBtYXggVURNQS8x MzMKPiBhdGExLjAwOiAyMzQ0NDE2NDggc2VjdG9ycywgbXVsdGkgMTogTEJBNDggTkNRIChkZXB0 aCAzMS8zMikKPiB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs IGlkUHJvZHVjdD0wMDAyCj4gYXRhNzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJv bCAzMDApCj4gYXRhODogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4g dXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5 IGVoY2lfaGNkCj4gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4yCj4gYXRhMS4w MDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKPiBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3Mg ICAgIEFUQSAgICAgIElOVEVMIFNTRFNBMkNXMTIgNFBDMSBQUTogMCBBTlNJOiA1Cj4gaHViIDMt MDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMy0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+IHNk IDA6MDowOjA6IFtzZGFdIDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEyMCBH Qi8xMTEgR2lCKQo+IHNkIDA6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCj4gc2Qg MDowOjA6MDogW3NkYV0gV3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQs IGRvZXNuJ3Qgc3VwcG9ydCBEUE8gb3IgRlVBCj4gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhv c3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyCj4gIHNkYTogc2RhMSBzZGEyCj4gb2hjaV9oY2Qg MDAwMDowMDoxMi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgK PiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2Qg MDAwMDowMDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy IDQKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUzZjcwMDAKPiBz ZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRpc2sKPiB1c2IgdXNiNDogTmV3IFVTQiBk ZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4gdXNiIHVzYjQ6IE5l dyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4g dXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjQ6IE1hbnVm YWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IG9oY2lfaGNkCj4g dXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4wCj4gaHViIDQtMDoxLjA6IFVTQiBo dWIgZm91bmQKPiBodWIgNC0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9n c2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6 MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTggKGxldmVsLCBs b3cpIC0+IElSUSAxOAo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBIb3N0IENvbnRyb2xs ZXIKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2ln bmVkIGJ1cyBudW1iZXIgNQo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogaXJxIDE4LCBpbyBtZW0g MHhmZTNmYzAwMAo+IHVzYiAxLTE6IG5ldyBoaWdoLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg dXNpbmcgZWhjaV9oY2QKPiB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9y PTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6 IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjU6IFByb2R1Y3Q6IE9I Q0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAt cmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IG9oY2lfaGNkCj4gdXNiIHVzYjU6IFNlcmlhbE51bWJl cjogMDAwMDowMDoxMy4wCj4gaHViIDUtMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNS0wOjEu MDogNSBwb3J0cyBkZXRlY3RlZAo+IGZpcmV3aXJlX2NvcmU6IGNyZWF0ZWQgZGV2aWNlIGZ3MDog R1VJRCAwMDFlOGMwMDAwZGU5MTM2LCBTNDAwCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5n IGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOAo+IG9oY2lfaGNk IDAwMDA6MDA6MTQuNTogUENJIElOVCBDIC0+IEdTSSAxOCAobGV2ZWwsIGxvdykgLT4gSVJRIDE4 Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNk IDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl ciA2Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZkMDAwCj4g dXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0MjQsIGlkUHJvZHVjdD0y NTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTAsIFByb2R1Y3Q9MCwg U2VyaWFsTnVtYmVyPTAKPiBodWIgMS0xOjEuMDogVVNCIGh1YiBmb3VuZAo+IGh1YiAxLTE6MS4w OiA0IHBvcnRzIGRldGVjdGVkCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I2OiBQcm9kdWN0 OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu Mi4wLXJjMi0xMTIwMi1nZDM1MDdhZi1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I2OiBTZXJpYWxO dW1iZXI6IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDYt MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJx IDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAw MDowMDoxNi4wOiBQQ0kgSU5UIEEgLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKPiBv aGNpX2hjZCAwMDAwOjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2QgMDAw MDowMDoxNi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcK PiBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUzZmYwMDAKPiB1c2Ig dXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAx Cj4gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNl cmlhbE51bWJlcj0xCj4gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4g dXNiIHVzYjc6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMyLTExMjAyLWdkMzUwN2FmLWRp cnR5IG9oY2lfaGNkCj4gdXNiIHVzYjc6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxNi4wCj4gaHVi IDctMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNy0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+ IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogUENJIElOVCBBIC0+IEdTSSA1MCAobGV2ZWwsIGxvdykg LT4gSVJRIDUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcgo+ IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQg YnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAsIGlvIG1lbSAweGZl NWZlMDAwCj4gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp ZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I4OiBQcm9kdWN0OiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuMi4wLXJjMi0xMTIw Mi1nZDM1MDdhZi1kaXJ0eSB4aGNpX2hjZAo+IHVzYiB1c2I4OiBTZXJpYWxOdW1iZXI6IDAwMDA6 MDM6MDAuMAo+IGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDgtMDoxLjA6IDIgcG9y dHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAwMDAwOjAzOjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVy Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l ZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNiOTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9y PTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4gdXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6 IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjk6IFByb2R1Y3Q6IHhI Q0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjk6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAt cmMyLTExMjAyLWdkMzUwN2FmLWRpcnR5IHhoY2lfaGNkCj4gdXNiIHVzYjk6IFNlcmlhbE51bWJl cjogMDAwMDowMzowMC4wCj4gaHViIDktMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgOS0wOjEu MDogMiBwb3J0cyBkZXRlY3RlZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNibHAKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVh cwo+IEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLgo+IHVzYmNvcmU6IHJl Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UKPiBVU0IgTWFzcyBTdG9y YWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy aXZlciB1bXNfZW5ldWI2MjUwCj4gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5k LiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lgo+IHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYw LDB4NjQgaXJxIDEKPiBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgo+ IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlCj4gaW5wdXQ6 IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0Mgo+IHJ0 Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2UgZnJvbSBTNAo+IHJ0Y19jbW9zIDAwOjA0OiBydGMg Y29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwCj4gcnRjMDogYWxhcm1zIHVwIHRvIG9u ZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0KPiBpMmMgL2RldiBlbnRyaWVzIGRyaXZlcgo+ IHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDogU01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAw LCByZXZpc2lvbiAwCj4gQVRLMDExMCBBVEswMTEwOjAwOiBFQyBlbmFibGVkCj4gU1A1MTAwIFRD TyB0aW1lcjogU1A1MTAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDEKPiBTUDUxMDAg VENPIHRpbWVyOiBtbWlvIGFkZHJlc3MgMHhiOGZlMDAgYWxyZWFkeSBpbiB1c2UKPiBJVDg3IFdE VDogQ2hpcCBJVDg3MjEgcmV2aXNpb24gMSBpbml0aWFsaXplZC4gdGltZW91dD02MCBzZWMgKG5v d2F5b3V0PTAgdGVzdG1vZGU9MCBleGNsdXNpdmU9MSBub2dhbWVwb3J0PTApCj4gd2R0OiBYZW4g V2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAxCj4gd2R0OiBjYW5ub3QgcmVnaXN0ZXIgbWlzY2Rl diBvbiBtaW5vcj0xMzAgKC0xNikKPiB3ZHQ6IHByb2JlIG9mIHdkdCBmYWlsZWQgd2l0aCBlcnJv ciAtMTYKPiBkZXZpY2UtbWFwcGVyOiB1ZXZlbnQ6IHZlcnNpb24gMS4wLjMKPiBkZXZpY2UtbWFw cGVyOiBpb2N0bDogNC4yMi4wLWlvY3RsICgyMDExLTEwLTE5KSBpbml0aWFsaXNlZDogZG0tZGV2 ZWxAcmVkaGF0LmNvbQo+IEVEQUMgTUM6IFZlcjogMi4xLjAKPiBBTUQ2NCBFREFDIGRyaXZlciB2 My40LjAKPiB1c2IgNC0yOiBuZXcgZnVsbC1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciAyIHVzaW5n IG9oY2lfaGNkCj4gRURBQyBhbWQ2NDogRFJBTSBFQ0MgZGlzYWJsZWQuCj4gRURBQyBhbWQ2NDog RUNDIGRpc2FibGVkIGluIHRoZSBCSU9TIG9yIG5vIEVDQyBjYXBhYmlsaXR5LCBtb2R1bGUgd2ls bCBub3QgbG9hZC4KPiAgRWl0aGVyIGVuYWJsZSBFQ0MgY2hlY2tpbmcgb3IgZm9yY2UgbW9kdWxl IGxvYWRpbmcgYnkgc2V0dGluZyAnZWNjX2VuYWJsZV9vdmVycmlkZScuCj4gIChOb3RlIHRoYXQg dXNlIG9mIHRoZSBvdmVycmlkZSBtYXkgY2F1c2UgdW5rbm93biBzaWRlIGVmZmVjdHMuKQo+IHVz YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkCj4gdXNiaGlkOiBV U0IgSElEIGNvcmUgZHJpdmVyCj4gVENQIGN1YmljIHJlZ2lzdGVyZWQKPiBORVQ6IFJlZ2lzdGVy ZWQgcHJvdG9jb2wgZmFtaWx5IDE3Cj4gcnRjX2Ntb3MgMDA6MDQ6IHNldHRpbmcgc3lzdGVtIGNs b2NrIHRvIDIwMTItMDUtMDcgMTE6MDc6MTUgVVRDICgxMzM2Mzg4ODM1KQo+IHBvd2Vybm93LWs4 OiBGb3VuZCAxIEFNRCBQaGVub20odG0pIElJIFg2IDEwNzVUIFByb2Nlc3NvciAoNiBjcHUgY29y ZXMpICh2ZXJzaW9uIDIuMjAuMDApCj4gcG93ZXJub3ctazg6IENvcmUgUGVyZm9ybWFuY2UgQm9v c3Rpbmc6IG9uLgo+IHBvd2Vybm93LWs4OiBpbnZhbGlkIHBzdGF0ZSAxIC0gYmFkIHZhbHVlIDEu Cj4gcG93ZXJub3ctazg6IFBsZWFzZSByZXBvcnQgdG8gQklPUyBtYW51ZmFjdHVyZXIKPiBwb3dl cm5vdy1rODogaW52YWxpZCBwc3RhdGUgMiAtIGJhZCB2YWx1ZSAyLgo+IHBvd2Vybm93LWs4OiBQ bGVhc2UgcmVwb3J0IHRvIEJJT1MgbWFudWZhY3R1cmVyCj4gcG93ZXJub3ctazg6IGludmFsaWQg cHN0YXRlIDMgLSBiYWQgdmFsdWUgMy4KPiBwb3dlcm5vdy1rODogUGxlYXNlIHJlcG9ydCB0byBC SU9TIG1hbnVmYWN0dXJlcgo+IFtGaXJtd2FyZSBCdWddOiBwb3dlcm5vdy1rODogaW52YWxpZCBw b3dlcm5vd190YWJsZQo+IEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDU5NmsgZnJlZWQK PiBMb2FkaW5nLCBwbGVhc2Ugd2FpdC4uLgo+IHVkZXZbMTA4N106IHN0YXJ0aW5nIHZlcnNpb24g MTY0Cj4gdXNiIDQtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0MWUsIGlkUHJv ZHVjdD0zMGRjCj4gdXNiIDQtMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1 Y3Q9MiwgU2VyaWFsTnVtYmVyPTMKPiB1c2IgNC0yOiBQcm9kdWN0OiBTb3VuZCBCbGFzdGVyIFRh Y3RpYygzRCkgQWxwaGEKPiB1c2IgNC0yOiBNYW51ZmFjdHVyZXI6IENyZWF0aXZlIFRlY2hub2xv Z3kgTHRkCj4gdXNiIDQtMjogU2VyaWFsTnVtYmVyOiAwMDAyMzE2Mgo+IGlucHV0OiBDcmVhdGl2 ZSBUZWNobm9sb2d5IEx0ZCBTb3VuZCBCbGFzdGVyIFRhY3RpYygzRCkgQWxwaGEgYXMgL2Rldmlj ZXMvcGNpMDAwMDowMC8wMDAwOjAwOjEyLjAvdXNiNC80LTIvNC0yOjEuMy9pbnB1dC9pbnB1dDMK PiBnZW5lcmljLXVzYiAwMDAzOjA0MUU6MzBEQy4wMDAxOiBpbnB1dCxoaWRkZXYwOiBVU0IgSElE IHYxLjAwIERldmljZSBbQ3JlYXRpdmUgVGVjaG5vbG9neSBMdGQgU291bmQgQmxhc3RlciBUYWN0 aWMoM0QpIEFscGhhXSBvbiB1c2ItMDAwMDowMDoxMi4wLTIvaW5wdXQzCj4gQmVnaW46IExvYWRp bmcgZXNzZW50aWFsIGRyaXZlcnMgLi4uIGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv aW5pdC1wcmVtb3VudCAuLi4gZG9uZS4KPiBCZWdpbjogTW91bnRpbmcgcm9vdCBmaWxlIHN5c3Rl bSAuLi4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtdG9wIC4uLiB1c2IgMS0xLjE6IG5l dyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDQgdXNpbmcgZWhjaV9oY2QKPiBkb25lLgo+ IEJlZ2luOiBSdW5uaW5nIC9zY3JpcHRzL2xvY2FsLXByZW1vdW50IC4uLiBkb25lLgo+IEVYVDQt ZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0 czogKG51bGwpCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtYm90dG9tIC4uLiBkb25l Lgo+IGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMvaW5pdC1ib3R0b20gLi4uIHVzYiAx LTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDEz Cj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBT ZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVjdDogUmF6ZXIgT3JvY2hpCj4gdXNiIDEt MS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gaW5wdXQ6IFJhemVyIFJhemVyIE9yb2NoaSBhcyAv ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMS8xLTEuMToxLjAv aW5wdXQvaW5wdXQ0Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAwMjogaW5wdXQ6IFVT QiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE9yb2NoaV0gb24gdXNiLTAwMDA6MDA6MTIu Mi0xLjEvaW5wdXQwCj4gaW5wdXQ6IFJhemVyIFJhemVyIE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kw MDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMS8xLTEuMToxLjEvaW5wdXQvaW5wdXQ1 Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAwMzogaW5wdXQ6IFVTQiBISUQgdjEuMTEg S2V5Ym9hcmQgW1JhemVyIFJhemVyIE9yb2NoaV0gb24gdXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5w dXQxCj4gZG9uZS4KPiBJTklUOiB2ZXJzaW9uIDIuODggYm9vdGluZwo+IHVzYiAxLTEuMjogbmV3 IGxvdy1zcGVlZCBVU0IgZGV2aWNlIG51bWJlciA1IHVzaW5nIGVoY2lfaGNkCj4gVXNpbmcgbWFr ZWZpbGUtc3R5bGUgY29uY3VycmVudCBib290IGluIHJ1bmxldmVsIFMuCj4gRmlsZXMgdW5kZXIg bW91bnQgcG9pbnQgJy9saWIvaW5pdC9ydycgd2lsbCBiZSBoaWRkZW4uIC4uLiAod2FybmluZyku Cj4gdXNiIDEtMS4yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDRmMiwgaWRQcm9k dWN0PTA0MDMKPiB1c2IgMS0xLjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9k dWN0PTIsIFNlcmlhbE51bWJlcj0wCj4gdXNiIDEtMS4yOiBQcm9kdWN0OiBVU0IgS2V5Ym9hcmQK PiB1c2IgMS0xLjI6IE1hbnVmYWN0dXJlcjogQ2hpY29ueQo+IEZpbGVzIHVuZGVyIG1vdW50IHBv aW50ICcvdmFyL3J1bicgd2lsbCBiZSBoaWRkZW4uIC4uLmlucHV0OiBDaGljb255IFVTQiBLZXli b2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8x LTEuMjoxLjAvaW5wdXQvaW5wdXQ2Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNDog aW5wdXQ6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1 c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDAKPiAgKHdhcm5pbmcpLgo+IGlucHV0OiBDaGljb255 IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEt MS8xLTEuMi8xLTEuMjoxLjEvaW5wdXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0 MDMuMDAwNTogaW5wdXQsaGlkZGV2MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkgVVNC IEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDEKPiBmaXJld2lyZV9uZXQ6 IGZpcmV3aXJlMDogSVB2NCBvdmVyIEZpcmVXaXJlIG9uIGRldmljZSAwMDFlOGMwMDAwZGU5MTM2 Cj4gZmlyZXdpcmVfY29yZTogcmVmcmVzaGVkIGRldmljZSBmdzAKPiBGaWxlcyB1bmRlciBtb3Vu dCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBTdGFy dGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hlcjogdWRldmR1ZGV2WzEyOTZdOiBzdGFy dGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXppbmcgdGhlIGluaXRpYWwgaG90cGx1ZyBl dmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYgdG8gYmUgZnVsbHkgcG9wdWxhdGVkLi4u ZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4nLi4uZG9uZS4KPiBTZXR0aW5nIHByZWxp bWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGluZyBzd2FwOi4KPiBFWFQ0LWZzIChkbS0w KTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2lsbCBub3cgY2hlY2sgcm9vdCBmaWxlIHN5 c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBbL3NiaW4vZnNjay5leHQ0ICgx KSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiAKPiAvZGV2 L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzU2NDcvMTMxMDcyMCBmaWxlcywgMTI3Njc3 MC81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czog ZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgZmlyZXdpcmUtc2JwMi4K PiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4uLi4K PiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdyb3Vw cyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGlsZS4u Lgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBs dm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2giIG5v dyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUgbHZtIGFuZCBtZCBzd2FwOmRvbmUuCj4g V2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4KPiBmc2NrIGZyb20gdXRpbC1saW51eC1u ZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0ZW1zLgo+IERvbmUgY2hlY2tpbmcgZmls ZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBpbiAvdmFyL2xvZy9mc2NrL2NoZWNrZnMg aWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4gV2lsbCBub3cgbW91bnQgbG9jYWwgZmls ZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6IG1vdW50aW5nIHVuY2hlY2tlZCBmcywg cnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBFWFQ0LWZzIChzZGExKTogbW91bnRlZCBm aWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQo+IC4KPiBXaWxs IG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5 IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4gLgo+IENoZWNraW5nIG1pbmltdW0gc3Bh Y2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJuZWwgdmFyaWFibGVzIC4uLiAvZXRjL3N5 c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJlciBnZW5lcmF0b3Iu Li5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29ja2V0IGRpcmVjdG9yeSAvdG1wLy5YMTEt dW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQgZGlyZWN0b3J5IC90bXAvLklDRS11bml4 Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLmRldmljZSBldGgwIGVudGVy ZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBlbmFibGluZyBp bnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBTdGFy dGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVzZS4KPiBTZXR0aW5nIGNvbnNvbGUgc2Ny ZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4gU2tpcHBpbmcgZm9u dCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXApLgo+IFNldHRpbmcg dXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IFNldHRpbmcgc2Vuc29ycyBsaW1p dHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMKPiBVc2luZyBtYWtlZmlsZS1zdHlsZSBj b25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBOb3Qgc3RhcnRpbmcgZmFuY29udHJvbDsg cnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5nKS4KPiBhY3BpZDogc3RhcnRpbmcgdXAg d2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIKPiAKPiBhY3BpZDogMSBydWxlIGxvYWRl ZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcgaXMgb2ZmCj4g Cj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0gbWVzc2FnZSBi dXM6IGRidXMuCj4gU3RhcnRpbmcgdGhlIFdpbmJpbmQgZGFlbW9uOiB3aW5iaW5kLnNzaGQgKDIw NjYpOiAvcHIKPiBvYy8yMDY2L29vbV9hZGogaXMgZGVwcmVjYXRlZCwgcGxlYXNlIHVzZSAvcHJv Yy8yMDY2L29vbV9zY29yZV9hZGogaW5zdGVhZC4KPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw dSBzdGF0ZQo+IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFi bGUgdG8gcmVhZCBjcHUgc3RhdGUKPiBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQo+ IFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlCj4gWEVOQlVTOiBVbmFibGUgdG8gcmVh ZCBjcHUgc3RhdGUKPiBTdGFydGluZyBveGVuc3RvcmVkLi4uCj4gU2V0dGluZyBkb21haW4gMCBu YW1lLi4uCj4gU3RhcnRpbmcgeGVuY29uc29sZWQuLi4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3Vy ZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgZG9tYWluIG5hbWUgc2VydmljZS4uLjog YmluZDkuCj4gU3RhcnRpbmcgU2FtYmEgZGFlbW9uczogbm1iZCBzbWJkLgo+IFN0YXJ0aW5nIHBl cmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLgo+IFN0YXJ0aW5nIFBvc3RmaXggTWFpbCBU cmFuc3BvcnQgQWdlbnQ6IHBvc3RmaXguCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5j Ojc5MjogYmxrdGFwY3RybDogdjEuMC4wCj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3Ry bC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxb MjIzMV06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyld Cj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBb dm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBCTEtUQVBDVFJMWzIyMzFdOiBibGt0YXBjdHJsLmM6 Nzk0OiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNrIGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxb MjIzMV06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyld Cj4gCj4gQkxLVEFQQ1RSTFsyMjMxXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBb cWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJMS1RBUENUUkxbMjIzMV06IGJsa3RhcGN0cmxfbGlu dXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxlZAo+IAo+IEJMS1RBUENUUkxbMjIzMV06IGJsa3Rh cGN0cmwuYzo4NjE6IGNvdWxkbid0IG9wZW4gYmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENU UkxbMjIzMV06IGJsa3RhcGN0cmwuYzo5MjQ6IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4g Cj4gU3RhcnRpbmcgUy5NLkEuUi5ULiBkYWVtb246IHNtYXJ0ZC4KPiBza3kyIDAwMDA6MDQ6MDAu MDogZXRoMDogTGluayBpcyB1cCBhdCAxMDAgTWJwcywgZnVsbCBkdXBsZXgsIGZsb3cgY29udHJv bCBib3RoCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJpbmcgZm9yd2FyZGluZyBzdGF0ZQo+IGJy MDogcG9ydCAxKGV0aDApIGVudGVyaW5nIGZvcndhcmRpbmcgc3RhdGUKPiBicjA6IHBvcnQgMShl dGgwKSBlbnRlcmluZyBmb3J3YXJkaW5nIHN0YXRlCj4gUnVubmluZyBsb2NhbCBib290IHNjcmlw dHMgKC9ldGMvcmMubG9jYWwpKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMi4yCj4g YWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5w dXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5lY3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2Ug aGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDow MDoxMy4yCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDox My4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gW0NQVTBdIGZhaWxlZCB0 byBzZXQgZ292ZXJub3IgbmFtZQo+IFtDUFUxXSBmYWlsZWQgdG8gc2V0IGdvdmVybm9yIG5hbWUK PiBbQ1BVMl0gZmFpbGVkIHRvIHNldCBnb3Zlcm5vciBuYW1lCj4gW0NQVTNdIGZhaWxlZCB0byBz ZXQgZ292ZXJub3IgbmFtZQo+IFtDUFU0XSBmYWlsZWQgdG8gc2V0IGdvdmVybm9yIG5hbWUKPiBb Q1BVNV0gZmFpbGVkIHRvIHNldCBnb3Zlcm5vciBuYW1lCj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZp Y2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVl biBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5l Y3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4g KFhFTikgaW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2IwIG1wb3J0PTNiMCBucj1jCj4gKFhF TikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWEwIG1mbj1hMCBucj0yMAo+IChYRU4pIGlvcG9y dF9tYXA6YWRkOiBkb20xIGdwb3J0PTNjMCBtcG9ydD0zYzAgbnI9Mwo+IChYRU4pIGlvcG9ydF9t YXA6YWRkOiBkb20xIGdwb3J0PTNjNCBtcG9ydD0zYzQgbnI9MWMKPiAoWEVOKSBIVk0xOiBIVk0g TG9hZGVyCj4gKFhFTikgSFZNMTogRGV0ZWN0ZWQgWGVuIHY0LjItdW5zdGFibGUKPiAoWEVOKSBI Vk0xOiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgOAo+IChYRU4pIEhW TTE6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklPUwo+IChYRU4pIEhWTTE6IENQVSBzcGVlZCBpcyAz MDEwIE1Iego+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1 Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBpcnEu YzoyNzA6IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDAgLT4gMTAKPiAoWEVOKSBIVk0xOiBQQ0kt SVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxp bmsgMiBjaGFuZ2VkIDAgLT4gMTEKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMiByb3V0ZWQg dG8gSVJRMTEKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4g NQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1Cj4gKFhFTikgSFZN MTogcGNpIGRldiAwMTozIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIElO VEEtPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhW TTE6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDY6MCBJ TlRCLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNzowIElOVEEtPklSUTUKPiAoWEVOKSBI Vk0xOiBwY2kgZGV2IDA4OjAgSU5UQi0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA5OjAg SU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgMTAwMDAw MDA6IGUwMDAwMDBjCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1k MDAwMCBucj0xMDAwMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAw MDAwMDogZjAwMDAwMDgKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNpemUgMDAw MjAwMDA6IGYxMDAwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDIwIG1m bj1mZTllMCBucj0yMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTggc2l6ZSAwMDAy MDAwMDogZjEwMjAwMDQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDMwIHNpemUgMDAw MjAwMDA6IGYxMDQwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIDAw MDA0MDAwOiBmMTA2MDAwNAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2MCBt Zm49ZmU5YmMgbnI9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBiYXIgMTAgc2l6ZSAwMDAw NDAwMDogZjEwNjQwMDQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZu PWZlM2Y4IG5yPTQKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgYmFyIDEwIHNpemUgMDAwMDEw MDA6IGYxMDY4MDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY4IG1mbj1m ZTNmNyBucj0xCj4gKFhFTikgSFZNMTogcGNpIGRldiAwODowIGJhciAxMCBzaXplIDAwMDAxMDAw OiBmMTA2OTAwMAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAw MDAgbnI9MQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAwMDEwMDog MDAwMGMwMDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA1OjAgYmFyIDIwIHNpemUgMDAwMDAxMDA6 IDAwMDBjMTAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQw OiAwMDAwYzIwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAx MDogMDAwMGMyNDEKPiAoWEVOKSBIVk0xOiBNdWx0aXByb2Nlc3NvciBpbml0aWFsaXNhdGlvbjoK PiAoWEVOKSBIVk0xOiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4u IHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUxIC4uLiA0OC1i aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAo WEVOKSBIVk0xOiAgLSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZh ciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFUzIC4uLiA0OC1iaXQg cGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVO KSBIVk0xOiAgLSBDUFU0IC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBN VFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBIVk0xOiAgLSBDUFU1IC4uLiA0OC1iaXQgcGh5 cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMy84XSAuLi4gZG9uZS4KPiAoWEVOKSBI Vk0xOiBUZXN0aW5nIEhWTSBlbnZpcm9ubWVudDoKPiAoWEVOKSBIVk0xOiAgLSBSRVAgSU5TQiBh Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiAgLSBHUyBiYXNl IE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkCj4gKFhFTikgSFZNMTogUGFzc2VkIDIgb2YgMiB0 ZXN0cwo+IChYRU4pIEhWTTE6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4KPiAoWEVOKSBIVk0x OiBMb2FkaW5nIFJPTUJJT1MgLi4uCj4gKFhFTikgSFZNMTogOTY2MCBieXRlcyBvZiBST01CSU9T IGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6Cj4gKFhFTikgSFZNMTogICBSZWxvY2F0aW5nIHRvIDB4 ZmMwMDEwMDAtMHhmYzAwMzViYyAuLi4gZG9uZQo+IChYRU4pIEhWTTE6IENyZWF0aW5nIE1QIHRh YmxlcyAuLi4KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIFZHQUJJT1Mgb2YgcGFzc3Rocm91Z2hlZCBn ZnggLi4uCj4gKFhFTikgSFZNMTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4KPiAoWEVOKSBI Vk0xOiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6Ly9pcHhlLm9yZwo+IChYRU4pIEhWTTE6ICAtIFBy b2R1Y3QgbmFtZTogaVBYRQo+IChYRU4pIEhWTTE6IE9wdGlvbiBST01zOgo+IChYRU4pIEhWTTE6 ICBjMDAwMC1jZmZmZjogVkdBIEJJT1MKPiAoWEVOKSBIVk0xOiAgZDAwMDAtZTBmZmY6IEV0aGVy Ym9vdCBST00KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIEFDUEkgLi4uCj4gKFhFTikgSFZNMTogdm04 NiBUU1MgYXQgZmMwMGY3MDAKPiAoWEVOKSBIVk0xOiBCSU9TIG1hcDoKPiAoWEVOKSBIVk0xOiAg ZjAwMDAtZmZmZmY6IE1haW4gQklPUwo+IChYRU4pIEhWTTE6IEU4MjAgdGFibGU6Cj4gKFhFTikg SFZNMTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQo+ IChYRU4pIEhWTTE6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAwMGEwMDAw OiBSRVNFUlZFRAo+IChYRU4pIEhWTTE6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAw MDAwOjAwMGUwMDAwCj4gKFhFTikgSFZNMTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAw MDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZNMTogIFswM106IDAwMDAwMDAwOjAw MTAwMDAwIC0gMDAwMDAwMDA6ZTAwMDAwMDA6IFJBTQo+IChYRU4pIEhWTTE6ICBIT0xFOiAwMDAw MDAwMDplMDAwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCj4gKFhFTikgSFZNMTogIFswNF06IDAw MDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZN MTogIFswNV06IDAwMDAwMDAxOjAwMDAwMDAwIC0gMDAwMDAwMDE6MjAwMDAwMDA6IFJBTQo+IChY RU4pIEhWTTE6IEludm9raW5nIFJPTUJJT1MgLi4uCj4gKFhFTikgSFZNMTogJFJldmlzaW9uOiAx LjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKPiAoWEVOKSBIVk0xOiBCb2NocyBC SU9TIC0gYnVpbGQ6IDA2LzIzLzk5Cj4gKFhFTikgSFZNMTogJFJldmlzaW9uOiAxLjIyMSAkICRE YXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQKPiAoWEVOKSBIVk0xOiBPcHRpb25zOiBhcG1iaW9z IHBjaWJpb3MgZWx0b3JpdG8gUE1NIAo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IGF0YTAt MDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mwo+IChY RU4pIEhWTTE6IGF0YTAgbWFzdGVyOiBRRU1VIEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoMjA0 ODAgTUJ5dGVzKQo+IChYRU4pIEhWTTE6IGF0YTAtMTogUENIUz0xNjM4My8xNi82MyB0cmFuc2xh dGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mwo+IChYRU4pIEhWTTE6IGF0YTAgIHNsYXZlOiBRRU1V IEhBUkRESVNLIEFUQS03IEhhcmQtRGlzayAoNTEyMDAgTUJ5dGVzKQo+IChYRU4pIEhWTTE6IAo+ IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IFByZXNzIEYxMiBmb3Ig Ym9vdCBtZW51Lgo+IChYRU4pIEhWTTE6IAo+IChYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSBIYXJk IERpc2suLi4KPiAoWEVOKSBIVk0xOiBCb290aW5nIGZyb20gMDAwMDo3YzAwCj4gKFhFTikgaXJx LmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6 IERvbTEgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEg UENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxp bmsgMyBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1l MDAwMCBtZm49ZDAwMDAgbnI9MTAwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBn Zm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2Zu PWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdm bj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBn Zm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49 ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49 ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEw NjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEw NjkgbWZuPWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjkg bWZuPWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjQg bWZuPWZlM2Y4IG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZu PWZlM2Y4IG5yPTQKPiAoWEVOKSBncmFudF90YWJsZS5jOjExNzQ6ZDEgRXhwYW5kaW5nIGRvbSAo MSkgZ3JhbnQgdGFibGUgZnJvbSAoNCkgdG8gKDMyKSBmcmFtZXMuCj4gKFhFTikgaXJxLmM6MzUw OiBEb20xIGNhbGxiYWNrIHZpYSBjaGFuZ2VkIHRvIEdTSSAyOAo+IChYRU4pIG1lbW9yeV9tYXA6 cmVtb3ZlOiBkb20xIGdmbj1lMDAwMCBtZm49ZDAwMDAgbnI9MTAwMDAKPiAoWEVOKSBtZW1vcnlf bWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgbWVtb3J5 X21hcDphZGQ6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9y eV9tYXA6YWRkOiBkb20xIGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlf bWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlf bWFwOmFkZDogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFw OnJlbW92ZTogZG9tMSBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFw OmFkZDogZG9tMSBnZm49ZjEwNjAgbWZuPWZlOWJjIG5yPTQKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMSwgZmF1bHQgYWRkcmVzcyA9 IDB4OWRiNDQwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjkgbWZu PWYwMDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjkgbWZuPWYw MDAwIG5yPTEKPiAoWEVOKSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMSBnZm49ZjEwNjQgbWZuPWZl M2Y4IG5yPTQKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjQgbWZuPWZlM2Y4 IG5yPTQKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVzcyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVz cyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDBhMiwgZmF1bHQgYWRkcmVzcyA9IDB4OWRlYmUwMDAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk0MzI0ZTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI0YjAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk0MzI1MTAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MDhhODAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwg ZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIw NDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9 IDB4OWQ3YWIwYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxMDAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQg YWRkcmVzcyA9IDB4OWQ3YWIxNDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxODAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcw MCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIxYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3 YWIyMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIyNDAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVz cyA9IDB4OWQ3YWIyODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIyYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1 bHQgYWRkcmVzcyA9IDB4OWQ3YWIzMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzNDAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzNDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4 OWQ3YWIzODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzODAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk cmVzcyA9IDB4OWQ3YWIzYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4OWQ3YWIzYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0 NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0 MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MGVhODAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4YTk1MjY0NjAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2ZjZhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2 MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk1MGVhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MzhhMzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MDJhODAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1 MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4 YTk0MDJhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmlj ZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRk cmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5Miwg ZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MTRh MzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9 IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9 IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRl dmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQg YWRkcmVzcyA9IDB4YTk2ZmNhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5 MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0 MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBp ZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk0MzJhMzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVz cyA9IDB4YTk1MjZhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEs IGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk1MmNhMzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1 bHQgYWRkcmVzcyA9IDB4YTk1MTRhMzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDEsIGRldmljZSBpZCA9IDB4MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2MWFhMzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDEsIGRldmljZSBpZCA9IDB4 MDA5MiwgZmF1bHQgYWRkcmVzcyA9IDB4YTk2ZmNhODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZGZlODAwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwNDAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZGZlODAwODAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZGZlODAwMDAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQt Vmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQg YWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFp biA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAo WEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5 MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFV TFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZm ZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp ZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElP X1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVz cyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAs IGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBB TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1 bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv bWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAK PiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4 MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0Vf RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4 ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmlj ZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6 IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRk cmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9 IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVO KSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwg ZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6 IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZm YzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9 IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BB R0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9 IDB4ZmZmZmZmYzAKPiAoWEVOKSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRl dmljZSBpZCA9IDB4MDA5MCwgZmF1bHQgYWRkcmVzcyA9IDB4ZmZmZmZmYzAKCj4gZGlmZiAtLWdp dCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmggYi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9wYXJhdmlydC5oCj4gaW5kZXggYWEwZjkxMy4uMjU5ZWY3ZiAxMDA2NDQKPiAtLS0gYS9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oCj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v cGFyYXZpcnQuaAo+IEBAIC0zNDAsMTEgKzM0MCwxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgd3Jp dGVfaWR0X2VudHJ5KGdhdGVfZGVzYyAqZHQsIGludCBlbnRyeSwgY29uc3QgZ2F0ZV9kZXNjICpn KQo+ICB7Cj4gIAlQVk9QX1ZDQUxMMyhwdl9jcHVfb3BzLndyaXRlX2lkdF9lbnRyeSwgZHQsIGVu dHJ5LCBnKTsKPiAgfQo+ICsKPiAgc3RhdGljIGlubGluZSB2b2lkIHNldF9pb3BsX21hc2sodW5z aWduZWQgbWFzaykKPiAgewo+ICAJUFZPUF9WQ0FMTDEocHZfY3B1X29wcy5zZXRfaW9wbF9tYXNr LCBtYXNrKTsKPiAgfQo+ICAKPiArc3RhdGljIGlubGluZSB2b2lkIHNldF9pb19iaXRtYXAoc3Ry dWN0IHRocmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnNpZ25lZCBsb25nIGJ5dGVzX3VwZGF0ZWQpCj4gK3sKPiArICAgICAgIFBWT1BfVkNB TEwyKHB2X2NwdV9vcHMuc2V0X2lvX2JpdG1hcCwgdGhyZWFkLCBieXRlc191cGRhdGVkKTsKPiAr fQo+ICsKPiAgLyogVGhlIHBhcmF2aXJ0dWFsaXplZCBJL08gZnVuY3Rpb25zICovCj4gIHN0YXRp YyBpbmxpbmUgdm9pZCBzbG93X2Rvd25faW8odm9pZCkKPiAgewo+IGRpZmYgLS1naXQgYS9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90eXBlcy5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v cGFyYXZpcnRfdHlwZXMuaAo+IGluZGV4IDhlOGI5YTQuLjk2ZjI2N2MgMTAwNjQ0Cj4gLS0tIGEv YXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaAo+ICsrKyBiL2FyY2gveDg2L2lu Y2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmgKPiBAQCAtMTQyLDYgKzE0Miw4IEBAIHN0cnVjdCBw dl9jcHVfb3BzIHsKPiAgCXZvaWQgKCpsb2FkX3NwMCkoc3RydWN0IHRzc19zdHJ1Y3QgKnRzcywg c3RydWN0IHRocmVhZF9zdHJ1Y3QgKnQpOwo+ICAKPiAgCXZvaWQgKCpzZXRfaW9wbF9tYXNrKSh1 bnNpZ25lZCBtYXNrKTsKPiArICAgICAgICB2b2lkICgqc2V0X2lvX2JpdG1hcCkoc3RydWN0IHRo cmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5z aWduZWQgbG9uZyBieXRlc191cGRhdGVkKTsKPiAgCj4gIAl2b2lkICgqd2JpbnZkKSh2b2lkKTsK PiAgCXZvaWQgKCppb19kZWxheSkodm9pZCk7Cj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1 ZGUvYXNtL3Byb2Nlc3Nvci5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmgKPiBp bmRleCA0ZmE3ZGNjLi42MmJlY2NlIDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNt L3Byb2Nlc3Nvci5oCj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmgKPiBA QCAtNTAzLDYgKzUwMyw5IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBuYXRpdmVfc2V0X2lvcGxfbWFz ayh1bnNpZ25lZCBtYXNrKQo+ICAjZW5kaWYKPiAgfQo+ICAKPiArZXh0ZXJuIHZvaWQgbmF0aXZl X3NldF9pb19iaXRtYXAoc3RydWN0IHRocmVhZF9zdHJ1Y3QgKnRocmVhZCwKPiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHVwZGF0ZWRfYnl0ZXMpOwo+ICsK PiAgc3RhdGljIGlubGluZSB2b2lkCj4gIG5hdGl2ZV9sb2FkX3NwMChzdHJ1Y3QgdHNzX3N0cnVj dCAqdHNzLCBzdHJ1Y3QgdGhyZWFkX3N0cnVjdCAqdGhyZWFkKQo+ICB7Cj4gQEAgLTUzNiw2ICs1 MzksNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgbG9hZF9zcDAoc3RydWN0IHRzc19zdHJ1Y3QgKnRz cywKPiAgfQo+ICAKPiAgI2RlZmluZSBzZXRfaW9wbF9tYXNrIG5hdGl2ZV9zZXRfaW9wbF9tYXNr Cj4gKyNkZWZpbmUgc2V0X2lvX2JpdG1hcCBuYXRpdmVfc2V0X2lvX2JpdG1hcAo+ICAjZW5kaWYg LyogQ09ORklHX1BBUkFWSVJUICovCj4gIAo+ICAvKgo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9r ZXJuZWwvaW9wb3J0LmMgYi9hcmNoL3g4Ni9rZXJuZWwvaW9wb3J0LmMKPiBpbmRleCA4Yzk2ODk3 Li5jMzcyZWYwIDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9pb3BvcnQuYwo+ICsrKyBi L2FyY2gveDg2L2tlcm5lbC9pb3BvcnQuYwo+IEBAIC0xNywxMyArMTcsMjkgQEAKPiAgI2luY2x1 ZGUgPGxpbnV4L2JpdG1hcC5oPgo+ICAjaW5jbHVkZSA8YXNtL3N5c2NhbGxzLmg+Cj4gIAo+ICt2 b2lkIG5hdGl2ZV9zZXRfaW9fYml0bWFwKHN0cnVjdCB0aHJlYWRfc3RydWN0ICp0LAo+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBieXRlc191cGRhdGVkKQo+ICt7Cj4g KyAgICAgICBzdHJ1Y3QgdHNzX3N0cnVjdCAqdHNzOwo+ICsKPiArICAgICAgIGlmICghYnl0ZXNf dXBkYXRlZCkKPiArICAgICAgICAgICAgICAgcmV0dXJuOwo+ICsKPiArICAgICAgIHRzcyA9ICZf X2dldF9jcHVfdmFyKGluaXRfdHNzKTsKPiArCj4gKyAgICAgICAvKiBVcGRhdGUgdGhlIFRTUzog Ki8KPiArICAgICAgIGlmICh0LT5pb19iaXRtYXBfcHRyKQo+ICsgICAgICAgICAgICAgICBtZW1j cHkodHNzLT5pb19iaXRtYXAsIHQtPmlvX2JpdG1hcF9wdHIsIGJ5dGVzX3VwZGF0ZWQpOwo+ICsg ICAgICAgZWxzZQo+ICsgICAgICAgICAgICAgICBtZW1zZXQodHNzLT5pb19iaXRtYXAsIDB4ZmYs IGJ5dGVzX3VwZGF0ZWQpOwo+ICt9Cj4gKwo+ICAvKgo+ICAgKiB0aGlzIGNoYW5nZXMgdGhlIGlv IHBlcm1pc3Npb25zIGJpdG1hcCBpbiB0aGUgY3VycmVudCB0YXNrLgo+ICAgKi8KPiAgYXNtbGlu a2FnZSBsb25nIHN5c19pb3Blcm0odW5zaWduZWQgbG9uZyBmcm9tLCB1bnNpZ25lZCBsb25nIG51 bSwgaW50IHR1cm5fb24pCj4gIHsKPiAgCXN0cnVjdCB0aHJlYWRfc3RydWN0ICp0ID0gJmN1cnJl bnQtPnRocmVhZDsKPiAtCXN0cnVjdCB0c3Nfc3RydWN0ICp0c3M7Cj4gIAl1bnNpZ25lZCBpbnQg aSwgbWF4X2xvbmcsIGJ5dGVzLCBieXRlc191cGRhdGVkOwo+ICAKPiAgCWlmICgoZnJvbSArIG51 bSA8PSBmcm9tKSB8fCAoZnJvbSArIG51bSA+IElPX0JJVE1BUF9CSVRTKSkKPiBAQCAtNDgsMTMg KzY0LDEzIEBAIGFzbWxpbmthZ2UgbG9uZyBzeXNfaW9wZXJtKHVuc2lnbmVkIGxvbmcgZnJvbSwg dW5zaWduZWQgbG9uZyBudW0sIGludCB0dXJuX29uKQo+ICAJfQo+ICAKPiAgCS8qCj4gLQkgKiBk byBpdCBpbiB0aGUgcGVyLXRocmVhZCBjb3B5IGFuZCBpbiB0aGUgVFNTIC4uLgo+ICsJICogZG8g aXQgaW4gdGhlIHBlci10aHJlYWQgY29weQo+ICAJICoKPiAtCSAqIERpc2FibGUgcHJlZW1wdGlv biB2aWEgZ2V0X2NwdSgpIC0gd2UgbXVzdCBub3Qgc3dpdGNoIGF3YXkKPiArCSAqIERpc2FibGUg cHJlZW1wdGlvbiAtIHdlIG11c3Qgbm90IHN3aXRjaCBhd2F5Cj4gIAkgKiBiZWNhdXNlIHRoZSAt PmlvX2JpdG1hcF9tYXggdmFsdWUgbXVzdCBtYXRjaCB0aGUgYml0bWFwCj4gIAkgKiBjb250ZW50 czoKPiAgCSAqLwo+IC0JdHNzID0gJnBlcl9jcHUoaW5pdF90c3MsIGdldF9jcHUoKSk7Cj4gKyAg ICAgICAgcHJlZW1wdF9kaXNhYmxlKCk7Cj4gIAo+ICAJaWYgKHR1cm5fb24pCj4gIAkJYml0bWFw X2NsZWFyKHQtPmlvX2JpdG1hcF9wdHIsIGZyb20sIG51bSk7Cj4gQEAgLTc1LDEwICs5MSw5IEBA IGFzbWxpbmthZ2UgbG9uZyBzeXNfaW9wZXJtKHVuc2lnbmVkIGxvbmcgZnJvbSwgdW5zaWduZWQg bG9uZyBudW0sIGludCB0dXJuX29uKQo+ICAKPiAgCXQtPmlvX2JpdG1hcF9tYXggPSBieXRlczsK PiAgCj4gLQkvKiBVcGRhdGUgdGhlIFRTUzogKi8KPiAtCW1lbWNweSh0c3MtPmlvX2JpdG1hcCwg dC0+aW9fYml0bWFwX3B0ciwgYnl0ZXNfdXBkYXRlZCk7Cj4gKyAgICAgICAgc2V0X2lvX2JpdG1h cCh0LCBieXRlc191cGRhdGVkKTsKPiAgCj4gLQlwdXRfY3B1KCk7Cj4gKyAgICAgICAgcHJlZW1w dF9lbmFibGUoKTsKPiAgCj4gIAlyZXR1cm4gMDsKPiAgfQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4 Ni9rZXJuZWwvcGFyYXZpcnQuYyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCj4gaW5kZXgg YWIxMzc2MC4uYWE0MjBlNyAxMDA2NDQKPiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZpcnQu Ywo+ICsrKyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jCj4gQEAgLTM5MSw2ICszOTEsNyBA QCBzdHJ1Y3QgcHZfY3B1X29wcyBwdl9jcHVfb3BzID0gewo+ICAJLnN3YXBncyA9IG5hdGl2ZV9z d2FwZ3MsCj4gIAo+ICAJLnNldF9pb3BsX21hc2sgPSBuYXRpdmVfc2V0X2lvcGxfbWFzaywKPiAr ICAgICAgICAuc2V0X2lvX2JpdG1hcCA9IG5hdGl2ZV9zZXRfaW9fYml0bWFwLAo+ICAJLmlvX2Rl bGF5ID0gbmF0aXZlX2lvX2RlbGF5LAo+ICAKPiAgCS5zdGFydF9jb250ZXh0X3N3aXRjaCA9IHBh cmF2aXJ0X25vcCwKPiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYva2VybmVsL3Byb2Nlc3MuYyBiL2Fy Y2gveDg2L2tlcm5lbC9wcm9jZXNzLmMKPiBpbmRleCAxZDkyYTVhLi5lODQzNmNjIDEwMDY0NAo+ IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9wcm9jZXNzLmMKPiArKysgYi9hcmNoL3g4Ni9rZXJuZWwv cHJvY2Vzcy5jCj4gQEAgLTkxLDE2ICs5MSwxMiBAQCB2b2lkIGV4aXRfdGhyZWFkKHZvaWQpCj4g IAl1bnNpZ25lZCBsb25nICpicCA9IHQtPmlvX2JpdG1hcF9wdHI7Cj4gIAo+ICAJaWYgKGJwKSB7 Cj4gLQkJc3RydWN0IHRzc19zdHJ1Y3QgKnRzcyA9ICZwZXJfY3B1KGluaXRfdHNzLCBnZXRfY3B1 KCkpOwo+IC0KPiArICAgICAgICAgICAgICAgIHByZWVtcHRfZGlzYWJsZSgpOwo+ICAJCXQtPmlv X2JpdG1hcF9wdHIgPSBOVUxMOwo+ICAJCWNsZWFyX3RocmVhZF9mbGFnKFRJRl9JT19CSVRNQVAp Owo+IC0JCS8qCj4gLQkJICogQ2FyZWZ1bCwgY2xlYXIgdGhpcyBpbiB0aGUgVFNTIHRvbzoKPiAt CQkgKi8KPiAtCQltZW1zZXQodHNzLT5pb19iaXRtYXAsIDB4ZmYsIHQtPmlvX2JpdG1hcF9tYXgp Owo+ICsgICAgICAgICAgICAgICAgc2V0X2lvX2JpdG1hcCh0LCB0LT5pb19iaXRtYXBfbWF4KTsK PiAgCQl0LT5pb19iaXRtYXBfbWF4ID0gMDsKPiAtCQlwdXRfY3B1KCk7Cj4gKyAgICAgICAgICAg ICAgICBwcmVlbXB0X2VuYWJsZSgpOwo+ICAJCWtmcmVlKGJwKTsKPiAgCX0KPiAgfQo+IEBAIC0y MzcsMTkgKzIzMywxMSBAQCB2b2lkIF9fc3dpdGNoX3RvX3h0cmEoc3RydWN0IHRhc2tfc3RydWN0 ICpwcmV2X3AsIHN0cnVjdCB0YXNrX3N0cnVjdCAqbmV4dF9wLAo+ICAJCQloYXJkX2VuYWJsZV9U U0MoKTsKPiAgCX0KPiAgCj4gLQlpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcobmV4dF9wLCBUSUZf SU9fQklUTUFQKSkgewo+IC0JCS8qCj4gLQkJICogQ29weSB0aGUgcmVsZXZhbnQgcmFuZ2Ugb2Yg dGhlIElPIGJpdG1hcC4KPiAtCQkgKiBOb3JtYWxseSB0aGlzIGlzIDEyOCBieXRlcyBvciBsZXNz Ogo+IC0JCSAqLwo+IC0JCW1lbWNweSh0c3MtPmlvX2JpdG1hcCwgbmV4dC0+aW9fYml0bWFwX3B0 ciwKPiAtCQkgICAgICAgbWF4KHByZXYtPmlvX2JpdG1hcF9tYXgsIG5leHQtPmlvX2JpdG1hcF9t YXgpKTsKPiAtCX0gZWxzZSBpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcocHJldl9wLCBUSUZfSU9f QklUTUFQKSkgewo+IC0JCS8qCj4gLQkJICogQ2xlYXIgYW55IHBvc3NpYmxlIGxlZnRvdmVyIGJp dHM6Cj4gLQkJICovCj4gLQkJbWVtc2V0KHRzcy0+aW9fYml0bWFwLCAweGZmLCBwcmV2LT5pb19i aXRtYXBfbWF4KTsKPiAtCX0KPiArICAgICAgICBpZiAodGVzdF90c2tfdGhyZWFkX2ZsYWcobmV4 dF9wLCBUSUZfSU9fQklUTUFQKSB8fAo+ICsgICAgICAgICAgICB0ZXN0X3Rza190aHJlYWRfZmxh ZyhwcmV2X3AsIFRJRl9JT19CSVRNQVApKQo+ICsgICAgICAgICAgICAgICAgc2V0X2lvX2JpdG1h cChuZXh0LAo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXgocHJldi0+aW9fYml0 bWFwX21heCwgbmV4dC0+aW9fYml0bWFwX21heCkpOwo+ICsKPiAgCXByb3BhZ2F0ZV91c2VyX3Jl dHVybl9ub3RpZnkocHJldl9wLCBuZXh0X3ApOwo+ICB9Cj4gIAo+IGRpZmYgLS1naXQgYS9hcmNo L3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKPiBpbmRleCA4 ODUzMjA0Li43YTA1NTA5IDEwMDY0NAo+IC0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwo+ ICsrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwo+IEBAIC04MDgsNiArODA4LDE4IEBAIHN0 YXRpYyB2b2lkIHhlbl9zZXRfaW9wbF9tYXNrKHVuc2lnbmVkIG1hc2spCj4gIAlIWVBFUlZJU09S X3BoeXNkZXZfb3AoUEhZU0RFVk9QX3NldF9pb3BsLCAmc2V0X2lvcGwpOwo+ICB9Cj4gIAo+ICtz dGF0aWMgdm9pZCB4ZW5fc2V0X2lvX2JpdG1hcChzdHJ1Y3QgdGhyZWFkX3N0cnVjdCAqdGhyZWFk LAo+ICsJaW50IGNoYW5nZWQsIHVuc2lnbmVkIGxvbmcgYnl0ZXNfdXBkYXRlZCkKPiArewo+ICsJ c3RydWN0IHBoeXNkZXZfc2V0X2lvYml0bWFwIHNldF9pb2JpdG1hcDsKPiArCj4gKwlzZXRfeGVu X2d1ZXN0X2hhbmRsZShzZXRfaW9iaXRtYXAuYml0bWFwLAo+ICsJCShjaGFyICopdGhyZWFkLT5p b19iaXRtYXBfcHRyKTsKPiArCXNldF9pb2JpdG1hcC5ucl9wb3J0cyA9IHRocmVhZC0+aW9fYml0 bWFwX3B0ciA/IElPX0JJVE1BUF9CSVRTIDogMDsKPiArCVdBUk5fT04oSFlQRVJWSVNPUl9waHlz ZGV2X29wKFBIWVNERVZPUF9zZXRfaW9iaXRtYXAsCj4gKwkJJnNldF9pb2JpdG1hcCkpOwo+ICt9 Cj4gKwo+ICBzdGF0aWMgdm9pZCB4ZW5faW9fZGVsYXkodm9pZCkKPiAgewo+ICB9Cj4gQEAgLTEx MTcsNiArMTEyOSw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgcHZfY3B1X29wcyB4ZW5fY3B1X29w cyBfX2luaXRjb25zdCA9IHsKPiAgCS5sb2FkX3NwMCA9IHhlbl9sb2FkX3NwMCwKPiAgCj4gIAku c2V0X2lvcGxfbWFzayA9IHhlbl9zZXRfaW9wbF9tYXNrLAo+ICsJLnNldF9pb19iaXRtYXAgPSB4 ZW5fc2V0X2lvX2JpdG1hcCwKPiAgCS5pb19kZWxheSA9IHhlbl9pb19kZWxheSwKPiAgCj4gIAkv KiBYZW4gdGFrZXMgY2FyZSBvZiAlZ3Mgd2hlbiBzd2l0Y2hpbmcgdG8gdXNlcm1vZGUgZm9yIHVz ICovCgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX18gICAgICAgICAgICAgICAgICAg ICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19f IFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKPiAgIFwgIC8vIF8g XCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdfIFx8 IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IC8gX18vfF9ffCB8X3wgfCB8IHwg XF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xfXF9fX3xffCB8X3wgICAgfF98KF8p X19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11bnN0YWJsZSAocm9vdEAobm9uZSkp IChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgpICkgU2F0IE1heSAgNSAxNTo0ODo0 OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBGcmkgTWF5IDA0IDExOjE4OjQ4 IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhFTikgQ29uc29sZSBvdXRwdXQgaXMg c3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3Nx dWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBkb20wX21lbT0yRyBkb20w X21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBzeW5jX2NvbnNvbGUgY29t MT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAoWEVOKSBWaWRlbyBpbmZvcm1hdGlv bjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2Cj4gKFhFTikgIFZC RS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzCj4gKFhFTikg RGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlcwo+IChYRU4p ICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCj4gKFhFTikgWGVuLWU4MjAgUkFN IG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVzYWJs ZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVk KQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQp Cj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1c2FibGUpCj4g KFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4g KFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNmZWMwMDAwIChBQ1BJIE5WUykKPiAo WEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2ZmMDAwMDAgKHJlc2VydmVkKQo+IChY RU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4gKFhF TikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAwMDAwICh1c2FibGUpCj4gKFhFTikg QUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFNKQo+IChYRU4pIEFDUEk6IFhTRFQg Q0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3 KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQgKHIzIDEwMjgxMSBGQUNQMTc0MCAy MDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IERTRFQgQ0ZFODA0NzAsIEU2RTMg KHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIwMDYwMTEzKQo+IChYRU4pIEFDUEk6 IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBBUElDIENGRTgwMzkwLCAwMDk4IChy MSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBN Q0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAgICAg ICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAwMDcyIChyMSAxMDI4MTEgT0VNQjE3 NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBIUEVUIENGRThGOEMwLCAw MDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1E ICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThGOUUwLCAwRTEwIChyMSBBIE0gSSAg UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAoWEVOKSBTeXN0ZW0gUkFNOiA4MTkw TUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiAoWEVO KSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDIzMDAwMDAwMAo+IChY RU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0 IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIg ZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4Cj4gKFhFTikgQUNQ STogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQo+IChY RU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3ZlY1tjZmU5ODAwY10sIHZlY19zaXpl WzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwCj4gKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkKPiAoWEVO KSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAj MSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNd IGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2 ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw M10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKPiAo WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQo+ IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCj4gKFhFTikgUHJvY2Vz c29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb MHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4gKFhFTikgQUNQSTogSU9BUElDIChp ZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQo+IChYRU4pIElPQVBJQ1sw XTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCj4g KFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVjMjAwMDBdIGdzaV9iYXNl WzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw eGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChi dXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiAoWEVOKSBBQ1BJOiBJUlEw IHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgo+ IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KPiAoWEVOKSBFbmFibGluZyBBUElD IG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAw eDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCEKPiAoWEVO KSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KPiAo WEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVnIENQVXMpCj4gKFhFTikgSVJRIGxp bWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01Q IENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBEZXRlY3RlZCAzMDEwLjIzOCBNSHog cHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuCj4gKFhFTikgQU1EIEZh bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkCj4gKFhFTikgUENJOiBNQ0ZHIGNv bmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZgo+ IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYKPiAo WEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVOKSBBTUQtVmk6IEVuYWJsaW5nIGds b2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQKPiAoWEVO KSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKPiAo WEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhG MCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4gKFhFTikgUGxhdGZvcm0gdGltZXIg aXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtp Qi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2 YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpCj4gKFhF TikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uCj4gKFhFTikgIC0g TmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAtIFBhdXNlLUludGVyY2VwdCBGaWx0 ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikgSFZNOiBIYXJkd2FyZSBBc3Npc3Rl ZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0Is IDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w eDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4 MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx MDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEw MDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChYRU4pIG1pY3JvY29kZTogY29sbGVj dF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgSFBFVCdzIE1TSSBtb2RlIGhh c24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxlZC4K PiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4pIE1DQTogVXNlIGh3IHRocmVzaG9s ZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAoWEVOKSBtY2hlY2tfcG9sbDogTWFj aGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4gKFhFTikgWGVub3Byb2ZpbGU6IEZh aWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZgo+IChYRU4p ICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6 IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDVkMzAwMAo+IChYRU4pIGVsZl9wYXJzZV9iaW5hcnk6 IHBoZHI6IHBhZGRyPTB4MTVkMzAwMCBtZW1zej0weDZlMGU4Cj4gKFhFTikgZWxmX3BhcnNlX2Jp bmFyeTogcGhkcjogcGFkZHI9MHgxNjQyMDAwIG1lbXN6PTB4MTI5ODAKPiAoWEVOKSBlbGZfcGFy c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2NTUwMDAgbWVtc3o9MHg0ZmYwMDAKPiAoWEVOKSBl bGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDFiNTQwMDAKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igo+IChYRU4pIGVsZl94ZW5fcGFy c2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3Rl OiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS VF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBF TlRSWSA9IDB4ZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFlQ RVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25v dGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdi Igo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIgo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMiCj4gKFhFTikgZWxmX3hlbl9wYXJz ZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+IChYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEhW X1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90 ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFk ZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAw MAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCj4gKFhFTikgICAgIHZpcnRfb2Zm c2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVOKSAgICAgdmlydF9rc3RhcnQgICAg ICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhm ZmZmZmZmZjgxYjU0MDAwCj4gKFhFTikgICAgIHZpcnRfZW50cnkgICAgICAgPSAweGZmZmZmZmZm ODE2NTUyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZm Zgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyCj4gKFhFTikgIERv bTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgxYjU0MDAw Cj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgo+IChYRU4pICBEb20wIGFsbG9j LjogICAwMDAwMDAwMjI0MDAwMDAwLT4wMDAwMDAwMjI4MDAwMDAwICg1MDYzMDggcGFnZXMgdG8g YmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjJmOWM0MDAwLT4w MDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6Cj4gKFhF TikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODFiNTQwMDAKPiAo WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWI1NDAwMC0+ZmZmZmZmZmY4MjE4ZjIwMAo+ IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyMTkwMDAwLT5mZmZmZmZmZjgyNTkwMDAw Cj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODI1OTAwMDAtPmZmZmZmZmZmODI1OTA0 YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjU5MTAwMC0+ZmZmZmZmZmY4MjVh ODAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyNWE4MDAwLT5mZmZmZmZmZjgy NWE5MDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZm ODI4MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4p IERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAw IGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODE1ZDMwMDAKPiAoWEVOKSBlbGZf bG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1ZDMwMDAgLT4gMHhmZmZmZmZmZjgx NjQxMGU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxNjQy MDAwIC0+IDB4ZmZmZmZmZmY4MTY1NDk4MAo+IChYRU4pIGVsZl9sb2FkX2JpbmFyeTogcGhkciAz IGF0IDB4ZmZmZmZmZmY4MTY1NTAwMCAtPiAweGZmZmZmZmZmODE2Y2MwMDAKPiAoWEVOKSBTY3J1 YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2aXJx IHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChYRU4pIFN0ZC4gTG9nbGV2ZWw6IEFs bAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVOKSAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05T T0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoqKioqKiogVGhpcyBvcHRpb24gaXMg aW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkgZW5zdXJpbmcKPiAoWEVOKSAqKioq KioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5IGRlbGl2ZXJlZCBvbiB0aGUgc2Vy aWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklG SUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAqKioqKioqIHRpbWVrZWVwaW5nLiBJ dCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQo+IChYRU4pICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPiAoWEVOKSAzLi4uIDIuLi4g MS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhy ZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAoWEVOKSBGcmVlZCAyNTZrQiBpbml0 IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNpY2FsIG1lbW9yeQo+IFhlbjogc2V0 dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQgc3RhcnRlZC4uLgo+IEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw dQo+IExpbnV4IHZlcnNpb24gMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IChyb290QHhl bikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjNSBTTVAgUFJFRU1QVCBT YXQgTWF5IDUgMTk6Mjk6NDIgQ0VTVCAyMDEyCj4gQ29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciBy b290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBjaWJh Y2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IEZyZWVpbmcg OWEtMTAwIHBmbiByYW5nZTogMTAyIHBhZ2VzIGZyZWVkCj4gUmVsZWFzZWQgMTAyIHBhZ2VzIG9m IHVudXNlZCBtZW1vcnkKPiBTZXQgMTk3MDk0IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcKPiBQb3B1 bGF0aW5nIDgwMDAwLTgwMDY2IHBmbiByYW5nZTogMTAyIHBhZ2VzIGFkZGVkCj4gQklPUy1wcm92 aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAw MDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAwMDAwMDAx MDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDY2 MDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDA4MDA2NjAwMCAtIDAwMDAwMDAwY2ZlODAwMDAg KHVudXNhYmxlKQo+ICBYZW46IDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNmZTk4MDAwIChB Q1BJIGRhdGEpCj4gIFhlbjogMDAwMDAwMDBjZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFD UEkgTlZTKQo+ICBYZW46IDAwMDAwMDAwY2ZlYzAwMDAgLSAwMDAwMDAwMGNmZjAwMDAwIChyZXNl cnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMCAocmVzZXJ2 ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVk KQo+ICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkK PiAgWGVuOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpCj4g IFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IGJv b3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChFeGVjdXRlIERpc2FibGUpIHByb3Rl Y3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICB1c2VyOiAw MDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAodXNhYmxlKQo+ICB1c2VyOiAwMDAw MDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAw MDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2FibGUpCj4gIHVzZXI6IDAwMDAwMDAw ODAwNjYwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1bnVzYWJsZSkKPiAgdXNlcjogMDAwMDAwMDBj ZmU4MDAwMCAtIDAwMDAwMDAwY2ZlOTgwMDAgKEFDUEkgZGF0YSkKPiAgdXNlcjogMDAwMDAwMDBj ZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZTKQo+ICB1c2VyOiAwMDAwMDAwMGNm ZWMwMDAwIC0gMDAwMDAwMDBjZmYwMDAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwZmVj MDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAwMDAwMDBmZWMy MDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ICB1c2VyOiAwMDAwMDAwMGZlZTAw MDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwZmZlMDAw MDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKPiAgdXNlcjogMDAwMDAwMDEwMDAwMDAw MCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IERNSSBwcmVzZW50Lgo+IE5vIEFHUCBi cmlkZ2UgZm91bmQKPiBsYXN0X3BmbiA9IDB4ODAwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAw MDAKPiBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAwMDAwZmY3ODBdIGZmNzgwCj4gaW5p dF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDgwMDAwMDAwCj4gUkFN RElTSzogMDFiNTQwMDAgLSAwMjE5MDAwMAo+IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYmYyMCAw MDAyNCAodjAyIEFDUElBTSkKPiBBQ1BJOiBYU0RUIDAwMDAwMDAwY2ZlODAxMDAgMDAwNUMgKHYw MSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBGQUNQIDAw MDAwMDAwY2ZlODAyOTAgMDAwRjQgKHYwMyAxMDI4MTEgRkFDUDE3NDAgMjAxMTEwMjggTVNGVCAw MDAwMDA5NykKPiBBQ1BJOiBEU0RUIDAwMDAwMDAwY2ZlODA0NzAgMEU2RTMgKHYwMSAgQTE1OTUg QTE1OTUwMDAgMDAwMDAwMDAgSU5UTCAyMDA2MDExMykKPiBBQ1BJOiBGQUNTIDAwMDAwMDAwY2Zl OTgwMDAgMDAwNDAKPiBBQ1BJOiBBUElDIDAwMDAwMDAwY2ZlODAzOTAgMDAwOTggKHYwMSAxMDI4 MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBNQ0ZHIDAwMDAwMDAw Y2ZlODA0MzAgMDAwM0MgKHYwMSAxMDI4MTEgT0VNTUNGRyAgMjAxMTEwMjggTVNGVCAwMDAwMDA5 NykKPiBBQ1BJOiBPRU1CIDAwMDAwMDAwY2ZlOTgwNDAgMDAwNzIgKHYwMSAxMDI4MTEgT0VNQjE3 NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBIUEVUIDAwMDAwMDAwY2ZlOGY4YzAg MDAwMzggKHYwMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJ OiBJVlJTIDAwMDAwMDAwY2ZlOGY5MDAgMDAwRTAgKHYwMSAgQU1EICAgICBSRDg5MFMgMDAyMDIw MzEgQU1EICAwMDAwMDAwMCkKPiBBQ1BJOiBTU0RUIDAwMDAwMDAwY2ZlOGY5ZTAgMDBFMTAgKHYw MSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkKPiBObyBOVU1BIGNvbmZp Z3VyYXRpb24gZm91bmQKPiBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAw MDA4MDAwMDAwMAo+IEluaXRtZW0gc2V0dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAw MDA4MDAwMDAwMAo+ICAgTk9ERV9EQVRBIFswMDAwMDAwMDdmZmZjMDAwIC0gMDAwMDAwMDA3ZmZm ZmZmZl0KPiBab25lIFBGTiByYW5nZXM6Cj4gICBETUEgICAgICAweDAwMDAwMDEwIC0+IDB4MDAw MDEwMDAKPiAgIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgwMDEwMDAwMAo+ICAgTm9ybWFsICAg ZW1wdHkKPiBNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBlYWNoIG5vZGUKPiBFYXJseSBtZW1v cnkgUEZOIHJhbmdlcwo+ICAgICAwOiAweDAwMDAwMDEwIC0+IDB4MDAwMDAwOWEKPiAgICAgMDog MHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCj4gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgK PiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQo+IEJJ T1MgYnVnOiBBUElDIHZlcnNpb24gaXMgMCBmb3IgQ1BVIDAvMHgwLCBmaXhpbmcgdXAgdG8gMHgx MAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpCj4g QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkKPiBBQ1BJ OiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQo+IEFDUEk6IExB UElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMg KGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDA3XSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDA4XSBsYXBpY19pZFsweDg3XSBkaXNhYmxlZCkKPiBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZd IGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCj4gSU9BUElDWzBdOiBhcGljX2lkIDYs IHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTI1Mwo+IEFDUEk6IElPQVBJ QyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCj4gSU9BUElDWzFd OiBhcGljX2lkIDcsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC0yNzcK PiBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZs KQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs ZXZlbCkKPiBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24KPiBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IDggUHJvY2Vzc29y cyBleGNlZWRzIE5SX0NQVVMgbGltaXQgb2YgNgo+IFNNUDogQWxsb3dpbmcgNiBDUFVzLCAwIGhv dHBsdWcgQ1BVcwo+IEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFydGluZyBhdCBjZmYwMDAw MCAoZ2FwOiBjZmYwMDAwMDoyZWQwMDAwMCkKPiBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu ZWwgb24gWGVuCj4gWGVuIHZlcnNpb246IDQuMi11bnN0YWJsZSAocHJlc2VydmUtQUQpCj4gc2V0 dXBfcGVyY3B1OiBOUl9DUFVTOjYgbnJfY3B1bWFza19iaXRzOjYgbnJfY3B1X2lkczo2IG5yX25v ZGVfaWRzOjEKPiBQRVJDUFU6IEVtYmVkZGVkIDI2IHBhZ2VzL2NwdSBAZmZmZjg4MDA3ZmY0YzAw MCBzNzYxNjAgcjgxOTIgZDIyMTQ0IHUxMDY0OTYKPiBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2Rl IG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA1MTU5NzYKPiBQb2xp Y3kgem9uZTogRE1BMzIKPiBLZXJuZWwgY29tbWFuZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9k ZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFuaWM9MTUgeGVuLXBjaWJhY2suaGlk ZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRrPXhlbgo+IFBJRCBoYXNoIHRhYmxl IGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykKPiBQbGFjaW5nIDY0TUIgc29m dHdhcmUgSU8gVExCIGJldHdlZW4gZmZmZjg4MDA3OTYwMDAwMCAtIGZmZmY4ODAwN2Q2MDAwMDAK PiBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDc5NjAwMDAwIC0gMHg3ZDYwMDAwMAo+IE1lbW9y eTogMTk3NTA2NGsvMjA5NzE1MmsgYXZhaWxhYmxlICg0NTY3ayBrZXJuZWwgY29kZSwgNDcyayBh YnNlbnQsIDEyMTYxNmsgcmVzZXJ2ZWQsIDE4MzNrIGRhdGEsIDUzMmsgaW5pdCkKPiBTTFVCOiBH ZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9Niwg Tm9kZXM9MQo+IFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uCj4g CUR1bXAgc3RhY2tzIG9mIHRhc2tzIGJsb2NraW5nIFJDVS1wcmVlbXB0IEdQLgo+IE5SX0lSUVM6 NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRy aWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5Cj4geGVuX21hcF9waXJxX2dzaTog cmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1Cj4g Y29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQKPiBjb25zb2xlIFto dmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+IGluc3RhbGxpbmcgWGVuIHRpbWVy IGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjM4IE1IeiBwcm9jZXNzb3IuCj4gQ2FsaWJyYXRp bmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJl cXVlbmN5Li4gNjAyMC40NyBCb2dvTUlQUyAobHBqPTMwMTAyMzgpCj4gcGlkX21heDogZGVmYXVs dDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczog MjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJbm9kZS1jYWNoZSBoYXNoIHRhYmxl IGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpCj4gTW91bnQtY2FjaGUg aGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBkZXZp Y2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcgo+IEluaXRpYWxpemluZyBj Z3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKPiBDUFU6 IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gbWNlOiBDUFUgc3VwcG9ydHMgNiBNQ0UgYmFua3MKPiBB Q1BJOiBDb3JlIHJldmlzaW9uIDIwMTIwMzIwCj4gY3B1IDAgc3BpbmxvY2sgZXZlbnQgaXJxIDI5 NQo+IFBlcmZvcm1hbmNlIEV2ZW50czogKFhFTikgdHJhcHMuYzoyNTYxOmQwIERvbWFpbiBhdHRl bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGU0YTc1ZGY4NjUxNCB0byAw eDAwMDAwMDAwMDAwMGFiY2QuCj4gQnJva2VuIFBNVSBoYXJkd2FyZSBkZXRlY3RlZCwgdXNpbmcg c29mdHdhcmUgZXZlbnRzIG9ubHkuCj4gTUNFOiBJbi1rZXJuZWwgTUNFIGRlY29kaW5nIGVuYWJs ZWQuCj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAxCj4gY3B1IDEgc3BpbmxvY2sgZXZl bnQgaXJxIDMwMgo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMgo+IGNwdSAyIHNwaW5s b2NrIGV2ZW50IGlycSAzMDkKPiBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMKPiBjcHUg MyBzcGlubG9jayBldmVudCBpcnEgMzE2Cj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSA0 Cj4gY3B1IDQgc3BpbmxvY2sgZXZlbnQgaXJxIDMyMwo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv ciBDUFUgNQo+IGNwdSA1IHNwaW5sb2NrIGV2ZW50IGlycSAzMzAKPiBCcm91Z2h0IHVwIDYgQ1BV cwo+IGRldnRtcGZzOiBpbml0aWFsaXplZAo+IEdyYW50IHRhYmxlcyB1c2luZyB2ZXJzaW9uIDIg bGF5b3V0Lgo+IEdyYW50IHRhYmxlIGluaXRpYWxpemVkCj4gTkVUOiBSZWdpc3RlcmVkIHByb3Rv Y29sIGZhbWlseSAxNgo+IFRPTTogMDAwMDAwMDBkMDAwMDAwMCBha2EgMzMyOE0KPiBUT00yOiAw MDAwMDAwMjMwMDAwMDAwIGFrYSA4OTYwTQo+IEFDUEk6IGJ1cyB0eXBlIHBjaSByZWdpc3RlcmVk Cj4gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0gYXQgW21lbSAweGUw MDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDApCj4gUENJOiBub3QgdXNpbmcgTU1D T05GSUcKPiBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBiYXNlIGFjY2Vzcwo+ IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGV4dGVuZGVkIGFjY2Vzcwo+IGJp bzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCj4gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2 aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERldmljZSkKPiBBQ1BJOiBBZGRlZCBf T1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpCj4gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdn cmVnYXRvciBEZXZpY2UpCj4gQUNQSTogRXhlY3V0ZWQgMyBibG9ja3Mgb2YgbW9kdWxlLWxldmVs IGV4ZWN1dGFibGUgQU1MIGNvZGUKPiBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkCj4gQUNQSTog KHN1cHBvcnRzIFMwIFM1KQo+IEFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJvdXRp bmcKPiBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4 ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkKPiBQQ0k6IE1NQ09ORklHIGF0 IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJvYXJk IHJlc291cmNlcwo+IEFDUEk6IEVDOiBHUEUgPSAweGEsIEkvTzogY29tbWFuZC9zdGF0dXMgPSAw eDY2LCBkYXRhID0gMHg2Mgo+IFBDSTogVXNpbmcgaG9zdCBicmlkZ2Ugd2luZG93cyBmcm9tIEFD UEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFuZCByZXBvcnQgYSBidWcKPiBBQ1BJ OiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKPiBwY2lf cm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW2lvICAweDAwMDAtMHgwY2Y3XQo+ IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZm ZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBh MDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRv dyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0 IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZmZmZmZmZdCj4gcGNpX3Jvb3QgUE5Q MEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQo+ IFBDSSBob3N0IGJyaWRnZSB0byBidXMgMDAwMDowMAo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW2lvICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBi dXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdCj4gcGNpX2J1cyAwMDAwOjAw OiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lfYnVz IDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhjZmYwMDAwMC0weGRmZmZmZmZmXQo+ IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweGYwMDAwMDAwLTB4ZmVi ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRnZSB0byBbYnVzIDA3LTA3XQo+IHBj aSAwMDAwOjA2OjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJZSBkZXZpY2UuICBZ b3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9yY2UnCj4gcGNpIDAwMDA6MDA6MDQu MDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQo+IHBjaSAwMDAwOjAwOjA1LjA6IFBDSSBicmlk Z2UgdG8gW2J1cyAwNS0wNV0KPiBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg MDQtMDRdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRnZSB0byBbYnVzIDAzLTAzXQo+IHBj aSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KPiBwY2kgMDAwMDowMDox NC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpCj4gIHBj aTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpCj4gIHBjaTAwMDA6 MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVkCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDowNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDowNi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDow Ny4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDoxMS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDAwMDowMDoxMy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41 Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDoxOC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDoxOC40Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzow MC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4xCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowNjowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4xCj4g cGNpIDAwMDA6MDY6MDAuMTogRmFpbGVkIHRvIGFkZCAtIHBhc3N0aHJvdWdoIG9yIE1TSS9NU0kt WCBtaWdodCBmYWlsIQo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDU6MDAuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDM6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDI6MDAuMAo+IChYRU4pIFBDSSBh ZGQgZGV2aWNlIDAwMDA6MDI6MDAuMQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQV0g KElSUXMgKjQgNyAxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0Jd IChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktD XSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L RF0gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO S0VdIChJUlFzIDQgKjcgMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtM TktGXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TE5LR10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg W0xOS0hdIChJUlFzIDQgNyAxMCAxMSAxNCAxNSkgKjAsIGRpc2FibGVkLgo+IHhlbi9iYWxsb29u OiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4geGVuLWJhbGxvb246IEluaXRpYWxpc2lu ZyBiYWxsb29uIGRyaXZlci4KPiB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDc6MDAu MCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lCj4gdmdhYXJiOiBsb2FkZWQK PiB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAwMDA6MDc6MDAuMAo+IFNDU0kgc3Vi c3lzdGVtIGluaXRpYWxpemVkCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy aXZlciB1c2Jmcwo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaHVi Cj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2IKPiBQQ0k6IFVzaW5n IEFDUEkgZm9yIElSUSByb3V0aW5nCj4gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNlIHhlbgo+IEZT LUNhY2hlOiBMb2FkZWQKPiBDYWNoZUZpbGVzOiBMb2FkZWQKPiBwbnA6IFBuUCBBQ1BJIGluaXQK PiBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZAo+IHN5c3RlbSAwMDowMTogW21lbSAweGZl YzIwMDAwLTB4ZmVjMjAwZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowMjog W21lbSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4geGVuX21hcF9w aXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBnc2kgOAo+IHhlbl9tYXBfcGlycV9nc2k6IHJl dHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwo+IHN5c3RlbSAwMDowODogW21lbSAweGZlYzAwMDAw LTB4ZmVjMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowODogW21lbSAw eGZlZTAwMDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBb aW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwNGQ2XSBo YXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjMDAtMHgwYzAxXSBoYXMg YmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjMTRdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1MC0weDBjNTFdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1Ml0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjNmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkMC0w eDBjZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkMi0weDBj ZDNdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkNC0weDBjZDVd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkNi0weDBjZDddIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGNkOC0weDBjZGZdIGhhcyBi ZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDgwMC0weDA4OWZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIwMC0weDBiMWZdIGhhcyBiZWVuIHJl c2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIyMC0weDBiM2ZdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkwMC0weDA5MGZdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkxMC0weDA5MWZdIGhhcyBiZWVuIHJlc2VydmVkCj4g c3lzdGVtIDAwOjA5OiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lz dGVtIDAwOjA5OiBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQK PiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZmI4MDAwMC0weGZmYmZmZmZmXSBoYXMgYmVlbiByZXNl cnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlYzEwMDAwLTB4ZmVjMTAwMWZdIGhhcyBiZWVu IHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVkODAwMDAtMHhmZWQ4MGZmZl0gaGFz IGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwMjMwLTB4MDIzZl0gaGFzIGJl ZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwMjkwLTB4MDI5Zl0gaGFzIGJlZW4g cmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwZjQwLTB4MGY0Zl0gaGFzIGJlZW4gcmVz ZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYTMwLTB4MGEzZl0gaGFzIGJlZW4gcmVzZXJ2 ZWQKPiBzeXN0ZW0gMDA6MGI6IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSBoYXMgYmVlbiBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMGMwMDAwLTB4MDAwY2Zm ZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMGUwMDAw LTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAw eDAwMTAwMDAwLTB4Y2ZlZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDow YzogW21lbSAweGZlYzAwMDAwLTB4ZmZmZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHBu cDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKPiBBQ1BJOiBBQ1BJIGJ1cyB0eXBlIHBucCB1 bnJlZ2lzdGVyZWQKPiBwY2liYWNrIDAwMDA6MDA6MTQuMjogc2VpemluZyBkZXZpY2UKPiBQTS1U aW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4ZmZmZmZmKSAtIGFib3J0aW5nLgo+ IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNy0wN10KPiBwY2kgMDAwMDow MDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQo+IHBjaSAwMDAwOjAw OjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZmZl0KPiBwY2kg MDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYg NjRiaXQgcHJlZl0KPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDZd Cj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0K PiBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlODAwMDAwLTB4ZmU4 ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA1LTA1XQo+IHBj aSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdCj4gcGNp IDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTcwMDAwMC0weGZlN2ZmZmZm XQo+IHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNC0wNF0KPiBwY2kgMDAw MDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQo+IHBjaSAwMDAw OjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU2MDAwMDAtMHhmZTZmZmZmZl0KPiBw Y2kgMDAwMDowMDowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDMtMDNdCj4gcGNpIDAwMDA6MDA6 MDcuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTUwMDAwMC0weGZlNWZmZmZmXQo+IHBjaSAw MDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0wMl0KPiBwY2kgMDAwMDowMDowZC4w OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZmXQo+IHBjaSAwMDAwOjAwOjBkLjA6 ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU0MDAwMDAtMHhmZTRmZmZmZl0KPiBwY2kgMDAwMDow MDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdCj4geGVuX21hcF9waXJxX2dzaTogcmV0 dXJuaW5nIGlycSA1MiBmb3IgZ3NpIDUyCj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1Mgo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9yIGdzaSA1Mgo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6NTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUzIGZvciBn c2kgNTMKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzCj4gTkVUOiBSZWdpc3RlcmVkIHByb3Rv Y29sIGZhbWlseSAyCj4gSVAgcm91dGUgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAo b3JkZXI6IDcsIDUyNDI4OCBieXRlcykKPiBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRy aWVzOiAyNjIxNDQgKG9yZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKPiBUQ1AgYmluZCBoYXNoIHRh YmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRlcykKPiBUQ1A6IEhhc2gg dGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDI2MjE0NCBiaW5kIDY1NTM2KQo+IFRDUDog cmVubyByZWdpc3RlcmVkCj4gVURQIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6IDMs IDMyNzY4IGJ5dGVzKQo+IFVEUC1MaXRlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXI6 IDMsIDMyNzY4IGJ5dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBn c2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4geGVuX21hcF9waXJxX2dzaTogcmV0 dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOAo+IHhl bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0 dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBn c2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gVW5wYWNraW5nIGluaXRyYW1mcy4u Lgo+IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogNjM4NGsgZnJlZWQKPiBtaWNyb2NvZGU6IENQVTA6 IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTE6IHBhdGNoX2xldmVsPTB4 MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTI6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNy b2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTQ6IHBh dGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTU6IHBhdGNoX2xldmVsPTB4MDEw MDAwYmYKPiBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUgRHJpdmVyOiB2Mi4wMCA8dGlncmFu QGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEKPiBOVEZTIGRyaXZlciAyLjEuMzAg W0ZsYWdzOiBSL1ddLgo+IG1zZ21uaSBoYXMgYmVlbiBzZXQgdG8gMzg3MAo+IEJsb2NrIGxheWVy IFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAwLjQgbG9hZGVkIChtYWpvciAyNTMp Cj4gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKPiBwY2llcG9ydCAwMDAw OjAwOjAyLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kg MDAwMDowNzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4g cGNpIDAwMDA6MDc6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVw dAo+IHBjaWVwb3J0IDAwMDA6MDA6MDQuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1F IGludGVycnVwdAo+IHBjaSAwMDAwOjA2OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNjowMC4xOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg UENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowNS4wOiBTaWduYWxpbmcgUE1F IHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDU6MDAuMDogU2lnbmFsaW5n IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6MDA6MDYuMDog U2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA0OjAw LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2llcG9ydCAw MDAwOjAwOjA3LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBw Y2kgMDAwMDowMzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0 Cj4gcGNpZXBvcnQgMDAwMDowMDowZC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUg aW50ZXJydXB0Cj4gcGNpIDAwMDA6MDI6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUg UE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjAyOjAwLjE6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQ Q0llIFBNRSBpbnRlcnJ1cHQKPiBwY2lfaG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZl cnNpb246IDAuNQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAv ZGV2aWNlOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwCj4gQUNQSTogUG93ZXIgQnV0dG9uIFtQ V1JCXQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdS Qk46MDAvaW5wdXQvaW5wdXQxCj4gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JGXQo+IEdIRVM6IEhF U1QgaXMgbm90IGVuYWJsZWQhCj4gRXZlbnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkLgo+IHhl bi1wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kKPiBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0 IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNhYmxlZAo+IDAwMDA6MDI6MDAuMTogdHR5UzAgYXQgSS9P IDB4YTg4MCAoaXJxID0gNDEpIGlzIGEgU1QxNjY1MFYyCj4gaHBldF9hY3BpX2FkZDogbm8gYWRk cmVzcyBvciBpcnFzIGluIF9DUlMKPiBOb24tdm9sYXRpbGUgbWVtb3J5IGRyaXZlciB2MS4zCj4g SGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEgKHRpY2sgaXMgMTgwIHNl Y29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KPiBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21v bm90b25pYygpLgo+IGxvb3A6IG1vZHVsZSBsb2FkZWQKPiBhaGNpIDAwMDA6MDA6MTEuMDogQUhD SSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMgMHgzZiBpbXBsIFNBVEEgbW9kZQo+ IGFoY2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBwbSBsZWQgY2xv IHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2kwIDogYWhjaQo+IHNjc2kxIDogYWhjaQo+IHNjc2ky IDogYWhjaQo+IHNjc2kzIDogYWhjaQo+IHNjc2k0IDogYWhjaQo+IHNjc2k1IDogYWhjaQo+IGF0 YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUx MDAgaXJxIDE5Cj4gYXRhMzogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2ZlMDAw IHBvcnQgMHhmZTNmZTE4MCBpcnEgMTkKPiBhdGE0OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0x MDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMjAwIGlycSAxOQo+IGF0YTU6IFNBVEEgbWF4IFVE TUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4ZmUzZmUyODAgaXJxIDE5Cj4gYXRh NjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTMw MCBpcnEgMTkKPiBhdGE3OiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAg cG9ydCAweGZlM2ZlMzgwIGlycSAxOQo+IGFoY2kgMDAwMDowNjowMC4wOiBBSENJIDAwMDEuMDAw MCAzMiBzbG90cyAyIHBvcnRzIDMgR2JwcyAweDMgaW1wbCBTQVRBIG1vZGUKPiBhaGNpIDAwMDA6 MDY6MDAuMDogZmxhZ3M6IDY0Yml0IG5jcSBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+ IHNjc2k2IDogYWhjaQo+IHNjc2k3IDogYWhjaQo+IGF0YTg6IFNBVEEgbWF4IFVETUEvMTMzIGFi YXIgbTgxOTJAMHhmZThmZTAwMCBwb3J0IDB4ZmU4ZmUxMDAgaXJxIDQ0Cj4gYXRhOTogU0FUQSBt YXggVURNQS8xMzMgYWJhciBtODE5MkAweGZlOGZlMDAwIHBvcnQgMHhmZThmZTE4MCBpcnEgNDQK PiB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNgo+IHR1bjogKEMpIDE5 OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNvbW0uY29tPgo+IHNreTI6IGRyaXZl ciB2ZXJzaW9uIDEuMzAKPiBza3kyIDAwMDA6MDQ6MDAuMDogWXVrb24tMiBPcHRpbWEgY2hpcCBy ZXZpc2lvbiAxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IGV0aDA6IGFkZHIgMjA6Y2Y6MzA6NmQ6ODk6 YTUKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNkY19uY20KPiBm aXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogYWRkZWQgT0hDSSB2MS4xMCBkZXZpY2UgYXMgY2Fy ZCAwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVpcmtzIDB4MTEKPiBlaGNpX2hjZDogVVNCIDIu MCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkgRHJpdmVyCj4geGVuX21hcF9waXJx X2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4gQWxyZWFkeSBzZXR1cCB0aGUgR1NJ IDoxNwo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogRUhDSSBIb3N0IENvbnRyb2xsZXIKPiBlaGNp X2hjZCAwMDAwOjAwOjEyLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu dW1iZXIgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAw L0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kCj4gZWhjaV9oY2QgMDAwMDowMDox Mi4yOiBkZWJ1ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGlycSAxNywgaW8gbWVt IDB4ZmUzZmU0MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhD SSAxLjAwCj4gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp ZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2IxOiBQcm9kdWN0OiBFSENJIEhvc3Qg Q29udHJvbGxlcgo+IHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5 NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6 MDA6MTIuMgo+IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDEtMDoxLjA6IDUgcG9y dHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kg MTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBF SENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBidXMg cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyCj4gZWhjaV9oY2QgMDAwMDowMDoxMy4y OiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmth cm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IGRlYnVnIHBvcnQgMQo+IGVoY2lfaGNkIDAw MDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0gMHhmZTNmZTgwMAo+IGVoY2lfaGNkIDAwMDA6MDA6 MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKPiB1c2IgdXNiMjogTmV3IFVTQiBkZXZp Y2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyCj4gdXNiIHVzYjI6IE5ldyBV U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNi IHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjI6IE1hbnVmYWN0 dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IGVoY2lfaGNkCj4gdXNi IHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yCj4gaHViIDItMDoxLjA6IFVTQiBodWIg Zm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6 IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcK PiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyCj4gZWhjaV9oY2Qg MDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy IDMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRz b24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+IGVoY2lfaGNkIDAwMDA6MDA6MTYuMjog ZGVidWcgcG9ydCAxCj4gYXRhNzogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAz MDApCj4gYXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRh MjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDApCj4gYXRh NTogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhNDogU0FUQSBs aW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMzogU0FUQSBsaW5rIGRvd24g KFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gYXRhMi4wMDogQVRBLTg6IElOVEVMIFNTRFNBMkNX MTIwRzMsIDRQQzEwMzYyLCBtYXggVURNQS8xMzMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGly cSAxNywgaW8gbWVtIDB4ZmUzZmVjMDAKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IFVTQiAyLjAg c3RhcnRlZCwgRUhDSSAxLjAwCj4gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2IzOiBQcm9kdWN0 OiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2IzOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu NC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2IzOiBTZXJpYWxO dW1iZXI6IDAwMDA6MDA6MTYuMgo+IGF0YTk6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0Nv bnRyb2wgMzAwKQo+IGF0YTg6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAw KQo+IGF0YTIuMDA6IDIzNDQ0MTY0OCBzZWN0b3JzLCBtdWx0aSAxOiBMQkE0OCBOQ1EgKGRlcHRo IDMxLzMyKQo+IGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDMtMDoxLjA6IDQgcG9y dHMgZGV0ZWN0ZWQKPiBvaGNpX2hjZDogVVNCIDEuMSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChP SENJKSBEcml2ZXIKPiBhdGEyLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMwo+IHhlbl9tYXBf cGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhl IEdTSSA6MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4g b2hjaV9oY2QgMDAwMDowMDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBi dXMgbnVtYmVyIDQKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IGlycSAxOCwgaW8gbWVtIDB4ZmUz ZjcwMDAKPiBzY3NpIDA6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEFUQSAgICAgIElOVEVMIFNT RFNBMkNXMTIgNFBDMSBQUTogMCBBTlNJOiA1Cj4gc2QgMDowOjA6MDogW3NkYV0gMjM0NDQxNjQ4 IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoMTIwIEdCLzExMSBHaUIpCj4gc2QgMDowOjA6MDog W3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKPiBzZCAwOjA6MDowOiBbc2RhXSBXcml0ZSBjYWNo ZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBG VUEKPiAgc2RhOiBzZGExIHNkYTIKPiBzZCAwOjA6MDowOiBbc2RhXSBBdHRhY2hlZCBTQ1NJIGRp c2sKPiB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv ZHVjdD0wMDAxCj4gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k dWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjQ6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250 cm9sbGVyCj4gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4 N2I1ZDkwLWRpcnR5IG9oY2lfaGNkCj4gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDox Mi4wCj4gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgNC0wOjEuMDogNSBwb3J0cyBk ZXRlY3RlZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOAo+ IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IE9IQ0kg SG9zdCBDb250cm9sbGVyCj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1cyByZWdp c3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUKPiBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IGly cSAxOCwgaW8gbWVtIDB4ZmUzZmMwMDAKPiB1c2IgMS0xOiBuZXcgaGlnaC1zcGVlZCBVU0IgZGV2 aWNlIG51bWJlciAyIHVzaW5nIGVoY2lfaGNkCj4gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIGZv dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I1OiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I1 OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I1OiBNYW51ZmFjdHVyZXI6 IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I1 OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTMuMAo+IGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k Cj4gaHViIDUtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hj aV9oY2QgMDAwMDowMDoxNC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IGZpcmV3aXJlX2NvcmUg MDAwMDowNTowMC4wOiBjcmVhdGVkIGRldmljZSBmdzA6IEdVSUQgMDAxZThjMDAwMGRlOTEzNiwg UzQwMAo+IG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz aWduZWQgYnVzIG51bWJlciA2Cj4gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1l bSAweGZlM2ZkMDAwCj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA0 MjQsIGlkUHJvZHVjdD0yNTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZy PTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKPiBodWIgMS0xOjEuMDogVVNCIGh1YiBmb3Vu ZAo+IGh1YiAxLTE6MS4wOiA0IHBvcnRzIGRldGVjdGVkCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2 aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcg VVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVz YiB1c2I2OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFj dHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVz YiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHVi IGZvdW5kCj4gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3Np OiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4 Cj4gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNk IDAwMDA6MDA6MTYuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl ciA3Cj4gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZmMDAwCj4g dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9 MDAwMQo+IHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0y LCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I3OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxl cgo+IHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5 MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMAo+ IGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0ZWN0 ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUwIGZvciBnc2kgNTAKPiBBbHJl YWR5IHNldHVwIHRoZSBHU0kgOjUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl ZCwgYXNzaWduZWQgYnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAs IGlvIG1lbSAweGZlNWZlMDAwCj4gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I4OiBQcm9kdWN0 OiB4SENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu NC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSB4aGNpX2hjZAo+IHVzYiB1c2I4OiBTZXJpYWxO dW1iZXI6IDAwMDA6MDM6MDAuMAo+IGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDgt MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAwMDAwOjAzOjAwLjA6IHhIQ0kgSG9z dCBDb250cm9sbGVyCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNiOTogTmV3IFVTQiBkZXZpY2UgZm91 bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4gdXNiIHVzYjk6IE5ldyBVU0IgZGV2 aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjk6 IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNiIHVzYjk6IE1hbnVmYWN0dXJlcjog TGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5IHhoY2lfaGNkCj4gdXNiIHVzYjk6 IFNlcmlhbE51bWJlcjogMDAwMDowMzowMC4wCj4gaHViIDktMDoxLjA6IFVTQiBodWIgZm91bmQK PiBodWIgOS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZAo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgdXNibHAKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIHVhcwo+IEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLgo+ IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UKPiBV U0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4KPiB1c2Jjb3JlOiByZWdpc3RlcmVk IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg aW50ZXJmYWNlIGRyaXZlciB1bXNfZW5ldWI2MjUwCj4gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250 cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lgo+IHNlcmlvOiBpODA0MiBLQkQg cG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKPiBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCww eDY0IGlycSAxMgo+IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBt aWNlCj4gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0 L2lucHV0Mgo+IHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2UgZnJvbSBTNAo+IHJ0Y19jbW9z IDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwCj4gcnRjMDogYWxh cm1zIHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0KPiBpMmMgL2RldiBlbnRy aWVzIGRyaXZlcgo+IEFDUEkgV2FybmluZzogMHgwMDAwMDAwMDAwMDAwYjAwLTB4MDAwMDAwMDAw MDAwMGIwNyBTeXN0ZW1JTyBjb25mbGljdHMgd2l0aCBSZWdpb24gXF9TQl8uUENJMC5TQlJHLkFT T0MuU01SRyAxICgyMDEyMDMyMC91dGFkZHJlc3MtMjUxKQo+IHVzYiA0LTI6IG5ldyBmdWxsLXNw ZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgb2hjaV9oY2QKPiBBQ1BJOiBJZiBhbiBBQ1BJ IGRyaXZlciBpcyBhdmFpbGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBp bnN0ZWFkIG9mIHRoZSBuYXRpdmUgZHJpdmVyCj4gQVRLMDExMCBBVEswMTEwOjAwOiBFQyBlbmFi bGVkCj4gc3A1MTAwX3RjbzogU1A1MTAwIFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDEK PiBzcDUxMDBfdGNvOiBtbWlvIGFkZHJlc3MgMHhiOGZlMDAgYWxyZWFkeSBpbiB1c2UKPiBpdDg3 X3dkdDogQ2hpcCBJVDg3MjEgcmV2aXNpb24gMSBpbml0aWFsaXplZC4gdGltZW91dD02MCBzZWMg KG5vd2F5b3V0PTAgdGVzdG1vZGU9MCBleGNsdXNpdmU9MSBub2dhbWVwb3J0PTApCj4geGVuX3dk dDogWGVuIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQo+IHhlbl93ZHQ6IGNhbm5vdCByZWdp c3RlciBtaXNjZGV2IG9uIG1pbm9yPTEzMCAoLTE2KQo+IHdkdDogcHJvYmUgb2Ygd2R0IGZhaWxl ZCB3aXRoIGVycm9yIC0xNgo+IGRldmljZS1tYXBwZXI6IHVldmVudDogdmVyc2lvbiAxLjAuMwo+ IGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIyLjAtaW9jdGwgKDIwMTEtMTAtMTkpIGluaXRpYWxp c2VkOiBkbS1kZXZlbEByZWRoYXQuY29tCj4gRURBQyBNQzogVmVyOiAyLjEuMAo+IEFNRDY0IEVE QUMgZHJpdmVyIHYzLjQuMAo+IEVEQUMgYW1kNjQ6IERSQU0gRUNDIGRpc2FibGVkLgo+IEVEQUMg YW1kNjQ6IEVDQyBkaXNhYmxlZCBpbiB0aGUgQklPUyBvciBubyBFQ0MgY2FwYWJpbGl0eSwgbW9k dWxlIHdpbGwgbm90IGxvYWQuCj4gIEVpdGhlciBlbmFibGUgRUNDIGNoZWNraW5nIG9yIGZvcmNl IG1vZHVsZSBsb2FkaW5nIGJ5IHNldHRpbmcgJ2VjY19lbmFibGVfb3ZlcnJpZGUnLgo+ICAoTm90 ZSB0aGF0IHVzZSBvZiB0aGUgb3ZlcnJpZGUgbWF5IGNhdXNlIHVua25vd24gc2lkZSBlZmZlY3Rz LikKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmhpZAo+IHVz YmhpZDogVVNCIEhJRCBjb3JlIGRyaXZlcgo+IFRDUDogY3ViaWMgcmVnaXN0ZXJlZAo+IE5FVDog UmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKPiBydGNfY21vcyAwMDowNDogc2V0dGluZyBz eXN0ZW0gY2xvY2sgdG8gMjAxMi0wNS0wNyAxMDo1NToyMiBVVEMgKDEzMzYzODgxMjIpCj4gcG93 ZXJub3ctazg6IEZvdW5kIDEgQU1EIFBoZW5vbSh0bSkgSUkgWDYgMTA3NVQgUHJvY2Vzc29yICg2 IGNwdSBjb3JlcykgKHZlcnNpb24gMi4yMC4wMCkKPiBwb3dlcm5vdy1rODogQ29yZSBQZXJmb3Jt YW5jZSBCb29zdGluZzogb24uCj4gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogNTMyayBm cmVlZAo+IExvYWRpbmcsIHBsZWFzZSB3YWl0Li4uCj4gdWRldlsxMDc4XTogc3RhcnRpbmcgdmVy c2lvbiAxNjQKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDQxZSwg aWRQcm9kdWN0PTMwZGMKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwg UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9Mwo+IHVzYiA0LTI6IFByb2R1Y3Q6IFNvdW5kIEJsYXN0 ZXIgVGFjdGljKDNEKSBBbHBoYQo+IHVzYiA0LTI6IE1hbnVmYWN0dXJlcjogQ3JlYXRpdmUgVGVj aG5vbG9neSBMdGQKPiB1c2IgNC0yOiBTZXJpYWxOdW1iZXI6IDAwMDIzMTYyCj4gaW5wdXQ6IENy ZWF0aXZlIFRlY2hub2xvZ3kgTHRkIFNvdW5kIEJsYXN0ZXIgVGFjdGljKDNEKSBBbHBoYSBhcyAv ZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMC91c2I0LzQtMi80LTI6MS4zL2lucHV0L2lu cHV0Mwo+IGdlbmVyaWMtdXNiIDAwMDM6MDQxRTozMERDLjAwMDE6IGlucHV0LGhpZGRldjA6IFVT QiBISUQgdjEuMDAgRGV2aWNlIFtDcmVhdGl2ZSBUZWNobm9sb2d5IEx0ZCBTb3VuZCBCbGFzdGVy IFRhY3RpYygzRCkgQWxwaGFdIG9uIHVzYi0wMDAwOjAwOjEyLjAtMi9pbnB1dDMKPiBCZWdpbjog TG9hZGluZyBlc3NlbnRpYWwgZHJpdmVycyAuLi4gdXNiIDEtMS4xOiBuZXcgZnVsbC1zcGVlZCBV U0IgZGV2aWNlIG51bWJlciA0IHVzaW5nIGVoY2lfaGNkCj4gZG9uZS4KPiBCZWdpbjogUnVubmlu ZyAvc2NyaXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLgo+IEJlZ2luOiBNb3VudGluZyByb290 IGZpbGUgc3lzdGVtIC4uLiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9sb2NhbC10b3AgLi4uIHVz YiAxLTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTE1MzIsIGlkUHJvZHVjdD0w MDEzCj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0y LCBTZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVjdDogUmF6ZXIgT3JvY2hpCj4gdXNi IDEtMS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gZG9uZS4KPiBpbnB1dDogUmF6ZXIgUmF6ZXIg T3JvY2hpIGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4x LzEtMS4xOjEuMC9pbnB1dC9pbnB1dDQKPiBnZW5lcmljLXVzYiAwMDAzOjE1MzI6MDAxMy4wMDAy OiBpbnB1dDogVVNCIEhJRCB2MS4xMSBNb3VzZSBbUmF6ZXIgUmF6ZXIgT3JvY2hpXSBvbiB1c2It MDAwMDowMDoxMi4yLTEuMS9pbnB1dDAKPiBpbnB1dDogUmF6ZXIgUmF6ZXIgT3JvY2hpIGFzIC9k ZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4xLzEtMS4xOjEuMS9p bnB1dC9pbnB1dDUKPiBnZW5lcmljLXVzYiAwMDAzOjE1MzI6MDAxMy4wMDAzOiBpbnB1dDogVVNC IEhJRCB2MS4xMSBLZXlib2FyZCBbUmF6ZXIgUmF6ZXIgT3JvY2hpXSBvbiB1c2ItMDAwMDowMDox Mi4yLTEuMS9pbnB1dDEKPiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9sb2NhbC1wcmVtb3VudCAu Li4gZG9uZS4KPiB1c2IgMS0xLjI6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgNSB1 c2luZyBlaGNpX2hjZAo+IEVYVDQtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBv cmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv bG9jYWwtYm90dG9tIC4uLiBkb25lLgo+IGRvbmUuCj4gQmVnaW46IFJ1bm5pbmcgL3NjcmlwdHMv aW5pdC1ib3R0b20gLi4uIGRvbmUuCj4gdXNiIDEtMS4yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwg aWRWZW5kb3I9MDRmMiwgaWRQcm9kdWN0PTA0MDMKPiB1c2IgMS0xLjI6IE5ldyBVU0IgZGV2aWNl IHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wCj4gdXNiIDEtMS4yOiBQ cm9kdWN0OiBVU0IgS2V5Ym9hcmQKPiB1c2IgMS0xLjI6IE1hbnVmYWN0dXJlcjogQ2hpY29ueQo+ IElOSVQ6IHZlcnNpb24gMi44OCBib290aW5nCj4gaW5wdXQ6IENoaWNvbnkgVVNCIEtleWJvYXJk IGFzIC9kZXZpY2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxMi4yL3VzYjEvMS0xLzEtMS4yLzEtMS4y OjEuMC9pbnB1dC9pbnB1dDYKPiBnZW5lcmljLXVzYiAwMDAzOjA0RjI6MDQwMy4wMDA0OiBpbnB1 dDogVVNCIEhJRCB2MS4xMSBLZXlib2FyZCBbQ2hpY29ueSBVU0IgS2V5Ym9hcmRdIG9uIHVzYi0w MDAwOjAwOjEyLjItMS4yL2lucHV0MAo+IFVzaW5nIG1ha2VmaWxlLXN0eWxlIGNvbmN1cnJlbnQg Ym9vdCBpbiBydW5sZXZlbCBTLmlucHV0OiBDaGljb255IFUKPiBTQiBLZXlib2FyZCBhcyAvZGV2 aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8xLTEuMjoxLjEvaW5w dXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNTogaW5wdXQsaGlkZGV2 MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAw MDowMDoxMi4yLTEuMi9pbnB1dDEKPiBGaWxlcyB1bmRlciBtb3VudCBwb2ludCAnL2xpYi9pbml0 L3J3JyB3aWxsIGJlIGhpZGRlbi4gLi4ubmV0IGZpcmV3aXJlMDogSVB2NCBvdmVyIElFRUUgMTM5 NCBvbiBjYXJkIDAwMDA6MDU6MDAuMAo+IGZpcmV3aXJlX2NvcmUgMDAwMDowNTowMC4wOiByZWZy ZXNoZWQgZGV2aWNlIGZ3MAo+ICAod2FybmluZykuCj4gRmlsZXMgdW5kZXIgbW91bnQgcG9pbnQg Jy92YXIvcnVuJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBGaWxlcyB1bmRlciBt b3VudCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJuaW5nKS4KPiBT dGFydGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hlcjogdWRldmR1ZGV2WzEyODZdOiBz dGFydGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXppbmcgdGhlIGluaXRpYWwgaG90cGx1 ZyBldmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYgdG8gYmUgZnVsbHkgcG9wdWxhdGVk Li4uZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4nLi4uZG9uZS4KPiBTZXR0aW5nIHBy ZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGluZyBzd2FwOi4KPiBFWFQ0LWZzIChk bS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2lsbCBub3cgY2hlY2sgcm9vdCBmaWxl IHN5c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBbL3NiaW4vZnNjay5leHQ0 ICgxKSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiAKPiAv ZGV2L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzU2NDcvMTMxMDcyMCBmaWxlcywgMTI3 NjYzNS81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0 czogZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgZmlyZXdpcmUtc2Jw Mi4KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBDbGVhbmluZyB1cCBpZnVwZG93bi4u Li4KPiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0dGluZyB1cCBMVk0gVm9sdW1lIEdy b3VwcyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4gIFRoaXMgbWF5IHRha2UgYSB3aGls ZS4uLgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3VjaCIgdXNpbmcgbWV0YWRhdGEgdHlw ZSBsdm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZvbHVtZSBncm91cCAibGVtcm91Y2gi IG5vdyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUgbHZtIGFuZCBtZCBzd2FwOmRvbmUu Cj4gV2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4KPiBmc2NrIGZyb20gdXRpbC1saW51 eC1uZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0ZW1zLgo+IERvbmUgY2hlY2tpbmcg ZmlsZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBpbiAvdmFyL2xvZy9mc2NrL2NoZWNr ZnMgaWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4gV2lsbCBub3cgbW91bnQgbG9jYWwg ZmlsZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6IG1vdW50aW5nIHVuY2hlY2tlZCBm cywgcnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBFWFQ0LWZzIChzZGExKTogbW91bnRl ZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQo+IC4KPiBX aWxsIG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUuCj4gQ2xlYW5pbmcgdXAgdGVtcG9y YXJ5IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4gLgo+IENoZWNraW5nIG1pbmltdW0g c3BhY2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJuZWwgdmFyaWFibGVzIC4uLiAvZXRj L3N5c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJlciBnZW5lcmF0 b3IuLi5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29ja2V0IGRpcmVjdG9yeSAvdG1wLy5Y MTEtdW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQgZGlyZWN0b3J5IC90bXAvLklDRS11 bml4Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJmYWNlcy4uLmRldmljZSBldGgwIGVu dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDowNDowMC4wOiBldGgwOiBlbmFibGlu ZyBpbnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRlbXBvcmFyeSBmaWxlcy4uLi4KPiBT dGFydGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVzZS4KPiBTZXR0aW5nIGNvbnNvbGUg c2NyZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vyc2F2ZSBtb2RlCj4gU2tpcHBpbmcg Zm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNvbnNvbGUtc2V0dXApLgo+IFNldHRp bmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25lLgo+IFNldHRpbmcgc2Vuc29ycyBs aW1pdHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMKPiBVc2luZyBtYWtlZmlsZS1zdHls ZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBOb3Qgc3RhcnRpbmcgZmFuY29udHJv bDsgcnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5nKS4KPiBhY3BpZDogc3RhcnRpbmcg dXAgd2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIKPiAKPiBhY3BpZDogMSBydWxlIGxv YWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6IGV2ZW50IGxvZ2dpbmcgaXMgb2Zm Cj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBTdGFydGluZyBzeXN0ZW0gbWVzc2Fn ZSBidXM6IGRidXMuCj4gc3NoZCAoMjA2NCk6IC9wcm9jLzIwNjQvb29tX2FkaiBpcyBkZXByZWNh dGVkLCBwbGVhc2UgdXNlIC9wcm9jLzIwNjQvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLgo+IFN0YXJ0 aW5nIHRoZSBXaW5iaW5kIGRhZW1vbjogd2luYmluZC4KPiBTdGFydGluZyBPcGVuQlNEIFNlY3Vy ZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgb3hlbnN0b3JlZC4uLgo+IFNldHRpbmcg ZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4gU3RhcnRpbmcgZG9t YWluIG5hbWUgc2VydmljZS4uLjogYmluZDkuCj4gU3RhcnRpbmcgU2FtYmEgZGFlbW9uczogbm1i ZCBzbWJkLgo+IFN0YXJ0aW5nIHBlcmlvZGljIGNvbW1hbmQgc2NoZWR1bGVyOiBjcm9uLgo+IFN0 YXJ0aW5nIFBvc3RmaXggTWFpbCBUcmFuc3BvcnQgQWdlbnQ6IHBvc3RmaXguCj4gQkxLVEFQQ1RS TFsyMjM0XTogYmxrdGFwY3RybC5jOjc5MjogYmxrdGFwY3RybDogdjEuMC4wCj4gCj4gQkxLVEFQ Q1RSTFsyMjM0XTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcmF3IGltYWdlIChh aW8pXQo+IAo+IEJMS1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZl cjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RSTFsyMjM0XTogYmxrdGFwY3RybC5j Ojc5NDogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2bWRrKV0KPiAKPiBCTEtUQVBDVFJM WzIyMzRdOiBibGt0YXBjdHJsLmM6Nzk0OiBGb3VuZCBkcml2ZXI6IFtyYW1kaXNrIGltYWdlIChy YW0pXQo+IAo+IEJMS1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo3OTQ6IEZvdW5kIGRyaXZl cjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RSTFsyMjM0XTogYmxrdGFwY3RybC5j Ojc5NDogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNvdzIpXQo+IAo+IEJMS1RBUENUUkxb MjIzNF06IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFwMCBvcGVuIGZhaWxlZAo+IAo+IEJM S1RBUENUUkxbMjIzNF06IGJsa3RhcGN0cmwuYzo4NjE6IGNvdWxkbid0IG9wZW4gYmxrdGFwIGlu dGVyZmFjZXNreTIgMDAwMDowNDowMC4KPiAwOiBldGgwOiBMaW5rIGlzIHVwIGF0IDEwMCBNYnBz LAo+ICBmdWxsIGR1cGxleCwgZmxvdyBjb250cm9sIGJvdGgKPiBCTEtUQVBDVFJMWzIyMzRdOiBi bGt0YXBjdHJsLmM6OTI0OiBVbmFibGUgdG8gc3RhcnQgYmxrdGFwY3RybGJyMDogcG9ydCAxKGV0 aDAKPiApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IAo+IGJyMDogcG9ydCAxKGV0aDApIGVu dGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IFN0YXJ0aW5nIFMuTS5BLlIuVC4gZGFlbW9uOiBzbWFy dGQuCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlCj4gUnVubmlu ZyBsb2NhbCBib290IHNjcmlwdHMgKC9ldGMvcmMubG9jYWwpKFhFTikgUENJIHJlbW92ZSBkZXZp Y2UgMDAwMDowMDoxMi4yCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0 ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVuIGRpc2Nvbm5lY3RlZAo+IAo+IGFj cGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gKFhFTikgUENJIHJl bW92ZSBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDow MDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4y Cj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVjdGVkCj4gCj4gYWNw aWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiAoWEVOKSBpb3BvcnRf bWFwOmFkZDogZG9tMSBncG9ydD0zYjAgbXBvcnQ9M2IwIG5yPWMKPiAoWEVOKSBtZW1vcnlfbWFw OmFkZDogZG9tMSBnZm49YTAgbWZuPWEwIG5yPTIwCj4gKFhFTikgaW9wb3J0X21hcDphZGQ6IGRv bTEgZ3BvcnQ9M2MwIG1wb3J0PTNjMCBucj0zCj4gKFhFTikgaW9wb3J0X21hcDphZGQ6IGRvbTEg Z3BvcnQ9M2M0IG1wb3J0PTNjNCBucj0xYwo+IChYRU4pIEhWTTE6IEhWTSBMb2FkZXIKPiAoWEVO KSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMi11bnN0YWJsZQo+IChYRU4pIEhWTTE6IFhlbmJ1cyBy aW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA4Cj4gKFhFTikgSFZNMTogU3lzdGVtIHJl cXVlc3RlZCBST01CSU9TCj4gKFhFTikgSFZNMTogQ1BVIHNwZWVkIGlzIDMwMTAgTUh6Cj4gKFhF TikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUKPiAoWEVOKSBIVk0x OiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQ Q0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAxIHJv dXRlZCB0byBJUlExMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQg MCAtPiAxMQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQo+IChY RU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5nZWQgMCAtPiA1Cj4gKFhFTikgSFZN MTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDAx OjMgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1Cj4gKFhFTikgSFZNMTogcGNpIGRldiAw NTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNjowIElOVEItPklSUTUKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYg MDg6MCBJTlRCLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDk6MCBJTlRBLT5JUlExMAo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6ZSAxMDAwMDAwMDogZTAwMDAwMGMK PiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yPTEwMDAw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBzaXplIDAxMDAwMDAwOiBmMDAwMDAw OAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjEwMDAw MDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwMjAgbWZuPWZlOWUwIG5yPTIw Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBzaXplIDAwMDIwMDAwOiBmMTAyMDAw NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAgc2l6ZSAwMDAyMDAwMDogZjEwNDAw MDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEwIHNpemUgMDAwMDQwMDA6IGYxMDYw MDA0Cj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDYwIG1mbj1mZTliYyBucj00 Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwOTowIGJhciAxMCBzaXplIDAwMDA0MDAwOiBmMTA2NDAw NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAgc2l6ZSAwMDAwMTAwMDogZjEwNjgwMDAK PiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEwNjggbWZuPWZlM2Y3IG5yPTEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgMDAwMDEwMDA6IGYxMDY5MDAwCj4g KFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY5IG1mbj1mMDAwMCBucj0xCj4gKFhF TikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAwMDAwMTAwOiAwMDAwYzAwMQo+IChY RU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMjAgc2l6ZSAwMDAwMDEwMDogMDAwMGMxMDEKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUgMDAwMDAwNDA6IDAwMDBjMjAxCj4g KFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIDAwMDAwMDEwOiAwMDAwYzI0MQo+ IChYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOgo+IChYRU4pIEhWTTE6 ICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsz LzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBm aXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAt IENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhd IC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTMgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhl ZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQ VTQgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4u LiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTUgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBN VFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6IFRlc3Rpbmcg SFZNIGVudmlyb25tZW50Ogo+IChYRU4pIEhWTTE6ICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJv dW5kYXJpZXMgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dB UEdTIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiBQYXNzZWQgMiBvZiAyIHRlc3RzCj4gKFhFTikg SFZNMTogV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgo+IChYRU4pIEhWTTE6IExvYWRpbmcgUk9N QklPUyAuLi4KPiAoWEVOKSBIVk0xOiA5NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkg ZXh0ZW5zaW9uczoKPiAoWEVOKSBIVk0xOiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZj MDAzNWJjIC4uLiBkb25lCj4gKFhFTikgSFZNMTogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLgo+IChY RU4pIEhWTTE6IExvYWRpbmcgVkdBQklPUyBvZiBwYXNzdGhyb3VnaGVkIGdmeCAuLi4KPiAoWEVO KSBIVk0xOiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLgo+IChYRU4pIEhWTTE6ICAtIE1hbnVm YWN0dXJlcjogaHR0cDovL2lweGUub3JnCj4gKFhFTikgSFZNMTogIC0gUHJvZHVjdCBuYW1lOiBp UFhFCj4gKFhFTikgSFZNMTogT3B0aW9uIFJPTXM6Cj4gKFhFTikgSFZNMTogIGMwMDAwLWNmZmZm OiBWR0EgQklPUwo+IChYRU4pIEhWTTE6ICBkMDAwMC1lMGZmZjogRXRoZXJib290IFJPTQo+IChY RU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBIVk0xOiB2bTg2IFRTUyBhdCBmYzAw ZjcwMAo+IChYRU4pIEhWTTE6IEJJT1MgbWFwOgo+IChYRU4pIEhWTTE6ICBmMDAwMC1mZmZmZjog TWFpbiBCSU9TCj4gKFhFTikgSFZNMTogRTgyMCB0YWJsZToKPiAoWEVOKSBIVk0xOiAgWzAwXTog MDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNCj4gKFhFTikgSFZNMTog IFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVECj4g KFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDAK PiAoWEVOKSBIVk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAwMDAwMDAwMDowMDEwMDAw MDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw MDAwMDplMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOmUwMDAwMDAw IC0gMDAwMDAwMDA6ZmMwMDAwMDAKPiAoWEVOKSBIVk0xOiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAw MDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzA1XTogMDAw MDAwMDE6MDAwMDAwMDAgLSAwMDAwMDAwMToyMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogSW52 b2tpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6 IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IEJvY2hzIEJJT1MgLSBidWlsZDog MDYvMjMvOTkKPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIv MDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IE9wdGlvbnM6IGFwbWJpb3MgcGNpYmlvcyBlbHRv cml0byBQTU0gCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogYXRhMC0wOiBQQ0hTPTE2Mzgz LzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRh MCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgyMDQ4MCBNQnl0ZXMpCj4g KFhFTikgSFZNMTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hT PTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRhMCAgc2xhdmU6IFFFTVUgSEFSRERJU0sgQVRB LTcgSGFyZC1EaXNrICg1MTIwMCBNQnl0ZXMpCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTog Cj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogUHJlc3MgRjEyIGZvciBib290IG1lbnUuCj4g KFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLgo+IChY RU4pIEhWTTE6IEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKPiAoWEVOKSBpcnEuYzoyNzA6IERvbTEg UENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGlu ayAxIGNoYW5nZWQgMTAgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAyIGNo YW5nZWQgMTEgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5nZWQg NSAtPiAwCj4gKFhFTikgbWVtb3J5X21hcDpyZW1vdmU6IGRvbTEgZ2ZuPWUwMDAwIG1mbj1kMDAw MCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTAyMCBtZm49 ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAwMDAgbWZuPWQw MDAwIG5yPTEwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDIwIG1mbj1m ZTllMCBucj0yMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2MCBtZm49 ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2MCBtZm49ZmU5 YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2OCBtZm49ZmUz ZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OCBtZm49ZmUzZjcg bnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAwMDAg bnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2OSBtZm49ZjAwMDAgbnI9 MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9 NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+ IChYRU4pIGdyYW50X3RhYmxlLmM6MTE3NDpkMSBFeHBhbmRpbmcgZG9tICgxKSBncmFudCB0YWJs ZSBmcm9tICg0KSB0byAoMzIpIGZyYW1lcy4KPiAoWEVOKSBpcnEuYzozNTA6IERvbTEgY2FsbGJh Y2sgdmlhIGNoYW5nZWQgdG8gR1NJIDI4Cj4gKFhFTikgRG9tYWluIDAgY3Jhc2hlZDogcmVib290 aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgo+ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9f X18gICAgICAgICAgICAgICAgICAgICBfICAgICAgICBfICAgICBfICAgICAgCj4gIFwgXC8gL19f XyBfIF9fICAgfCB8fCB8ICB8X19fIFwgICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18g fCB8IF9fXyAKPiAgIFwgIC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHxfX3wgfCB8IHwgJ18g XC8gX198IF9fLyBfYCB8ICdfIFx8IHwvIF8gXAo+ICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98 IC8gX18vfF9ffCB8X3wgfCB8IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vCj4gIC9fL1xf XF9fX3xffCB8X3wgICAgfF98KF8pX19fX198ICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8u X18vfF98XF9fX3wKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+IChYRU4pIFhlbiB2ZXJzaW9uIDQuMi11 bnN0YWJsZSAocm9vdEAobm9uZSkpIChnY2MgdmVyc2lvbiA0LjQuNSAoRGViaWFuIDQuNC41LTgp ICkgU2F0IE1heSAgNSAxNTo0ODo0OCBDRVNUIDIwMTIKPiAoWEVOKSBMYXRlc3QgQ2hhbmdlU2V0 OiBGcmkgTWF5IDA0IDExOjE4OjQ4IDIwMTIgKzAxMDAgMjUyNTk6MGY1MzU0MDQ5NGY3Cj4gKFhF TikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hyb25vdXMuCj4gKFhFTikgQm9vdGxvYWRlcjogR1JV QiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCj4gKFhFTikgQ29tbWFuZCBsaW5lOiBwbGFjZWhv bGRlciBkb20wX21lbT0yRyBkb20wX21heF92Y3B1cz02IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZs PWFsbCBzeW5jX2NvbnNvbGUgY29tMT0xMTUyMDAsOG4xLDB4YWMwMCBjb25zb2xlPWNvbTEKPiAo WEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwg Zm9udCA4eDE2Cj4gKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGlt ZTogMSBzZWNvbmRzCj4gKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKPiAoWEVOKSAgRm91bmQgMSBN QlIgc2lnbmF0dXJlcwo+IChYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVz Cj4gKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKPiAoWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAw MDAwMDAwMDAwOWFjMDAgKHVzYWJsZSkKPiAoWEVOKSAgMDAwMDAwMDAwMDA5YWMwMCAtIDAwMDAw MDAwMDAwYTAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAw MDAwMDEwMDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAw MGNmZTgwMDAwICh1c2FibGUpCj4gKFhFTikgIDAwMDAwMDAwY2ZlODAwMDAgLSAwMDAwMDAwMGNm ZTk4MDAwIChBQ1BJIGRhdGEpCj4gKFhFTikgIDAwMDAwMDAwY2ZlOTgwMDAgLSAwMDAwMDAwMGNm ZWMwMDAwIChBQ1BJIE5WUykKPiAoWEVOKSAgMDAwMDAwMDBjZmVjMDAwMCAtIDAwMDAwMDAwY2Zm MDAwMDAgKHJlc2VydmVkKQo+IChYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAw MDAwMCAocmVzZXJ2ZWQpCj4gKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjMwMDAw MDAwICh1c2FibGUpCj4gKFhFTikgQUNQSTogUlNEUCAwMDBGQkYyMCwgMDAyNCAocjIgQUNQSUFN KQo+IChYRU4pIEFDUEk6IFhTRFQgQ0ZFODAxMDAsIDAwNUMgKHIxIDEwMjgxMSBYU0RUMTc0MCAy MDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6IEZBQ1AgQ0ZFODAyOTAsIDAwRjQg KHIzIDEwMjgxMSBGQUNQMTc0MCAyMDExMTAyOCBNU0ZUICAgICAgIDk3KQo+IChYRU4pIEFDUEk6 IERTRFQgQ0ZFODA0NzAsIEU2RTMgKHIxICBBMTU5NSBBMTU5NTAwMCAgICAgICAgMCBJTlRMIDIw MDYwMTEzKQo+IChYRU4pIEFDUEk6IEZBQ1MgQ0ZFOTgwMDAsIDAwNDAKPiAoWEVOKSBBQ1BJOiBB UElDIENGRTgwMzkwLCAwMDk4IChyMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAgICAg ICA5NykKPiAoWEVOKSBBQ1BJOiBNQ0ZHIENGRTgwNDMwLCAwMDNDIChyMSAxMDI4MTEgT0VNTUNG RyAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBPRU1CIENGRTk4MDQwLCAw MDcyIChyMSAxMDI4MTEgT0VNQjE3NDAgMjAxMTEwMjggTVNGVCAgICAgICA5NykKPiAoWEVOKSBB Q1BJOiBIUEVUIENGRThGOEMwLCAwMDM4IChyMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjggTVNG VCAgICAgICA5NykKPiAoWEVOKSBBQ1BJOiBJVlJTIENGRThGOTAwLCAwMEUwIChyMSAgQU1EICAg ICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAgMCkKPiAoWEVOKSBBQ1BJOiBTU0RUIENGRThG OUUwLCAwRTEwIChyMSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkKPiAo WEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgzODY2NjRrQikKPiAoWEVOKSBObyBOVU1BIGNvbmZp Z3VyYXRpb24gZm91bmQKPiAoWEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAt MDAwMDAwMDIzMDAwMDAwMAo+IChYRU4pIERvbWFpbiBoZWFwIGluaXRpYWxpc2VkCj4gKFhFTikg Zm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwCj4gKFhFTikgRE1JIHByZXNlbnQuCj4gKFhF TikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdAo+IChYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBv cnQ6IDB4ODA4Cj4gKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0s IHBtMXhfZXZ0WzgwMCwwXQo+IChYRU4pIEFDUEk6ICAgICAgICAgICAgICAgICAgd2FrZXVwX3Zl Y1tjZmU5ODAwY10sIHZlY19zaXplWzIwXQo+IChYRU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz cyAweGZlZTAwMDAwCj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRb MHgwMF0gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZlcnNpb24gMTYK PiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVk KQo+IChYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNgo+IChYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpCj4gKFhFTikgUHJv Y2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkKPiAoWEVOKSBQcm9jZXNzb3IgIzMgMDox MCBBUElDIHZlcnNpb24gMTYKPiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp Y19pZFsweDA0XSBlbmFibGVkKQo+IChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lv biAxNgo+IChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVu YWJsZWQpCj4gKFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2Cj4gKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHg4Nl0gZGlzYWJsZWQpCj4gKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOF0gbGFwaWNfaWRbMHg4N10gZGlzYWJsZWQpCj4g KFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNl WzBdKQo+IChYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4 ZmVjMDAwMDAsIEdTSSAwLTIzCj4gKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNz WzB4ZmVjMjAwMDBdIGdzaV9iYXNlWzI0XSkKPiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUKPiAoWEVOKSBBQ1BJOiBJ TlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IChYRU4p IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZl bCkKPiAoWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuCj4gKFhFTikgQUNQSTogSVJR MiB1c2VkIGJ5IG92ZXJyaWRlLgo+IChYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4K PiAoWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MKPiAo WEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMAo+IChYRU4pIFRhYmxl IGlzIG5vdCBmb3VuZCEKPiAoWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24KPiAoWEVOKSBTTVA6IEFsbG93aW5nIDggQ1BVcyAoMiBob3RwbHVn IENQVXMpCj4gKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWAo+IChYRU4p IFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkKPiAoWEVOKSBE ZXRlY3RlZCAzMDEwLjI1NCBNSHogcHJvY2Vzc29yLgo+IChYRU4pIEluaXRpbmcgbWVtb3J5IHNo YXJpbmcuCj4gKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVk Cj4gKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50 IDAwMDAgYnVzZXMgMDAgLSBmZgo+IChYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21l bnQgMDAwMCBidXMgMDAtZmYKPiAoWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4KPiAoWEVO KSBBTUQtVmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwCj4gKFhFTikgSS9PIHZpcnR1YWxp c2F0aW9uIGVuYWJsZWQKPiAoWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQKPiAoWEVOKSBFTkFC TElORyBJTy1BUElDIElSUXMKPiAoWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKPiAoWEVO KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xCj4g KFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKPiAoWEVOKSBBbGxvY2F0ZWQg Y29uc29sZSByaW5nIG9mIDY0IEtpQi4KPiAoWEVOKSBIVk06IEFTSURzIGVuYWJsZWQuCj4gKFhF TikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6Cj4gKFhFTikgIC0gTmVzdGVkIFBh Z2UgVGFibGVzIChOUFQpCj4gKFhFTikgIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1 YWxpc2F0aW9uCj4gKFhFTikgIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAo+IChYRU4pICAt IFBhdXNlLUludGVyY2VwdCBGaWx0ZXIKPiAoWEVOKSBIVk06IFNWTSBlbmFibGVkCj4gKFhFTikg SFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQKPiAoWEVOKSBIVk06 IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0 X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKPiAoWEVOKSBtaWNyb2NvZGU6IGNvbGxlY3Rf Y3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgo+IChYRU4pIG1pY3JvY29kZTogY29sbGVjdF9j cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhFTikgbWljcm9jb2RlOiBjb2xsZWN0X2Nw dV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKPiAoWEVOKSBCcm91Z2h0IHVwIDYgQ1BVcwo+IChY RU4pIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmCj4gKFhF TikgSFBFVCdzIE1TSSBtb2RlIGhhc24ndCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBS ZW1hcHBpbmcgaXMgZW5hYmxlZC4KPiAoWEVOKSBBQ1BJIHNsZWVwIG1vZGVzOiBTMwo+IChYRU4p IE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kKPiAo WEVOKSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuCj4g KFhFTikgWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RM ID0gMHhmZmZmZmZmZgo+IChYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgo+IChYRU4pIGVs Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDVkMzAwMAo+IChY RU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTVkMzAwMCBtZW1zej0weDZlMGU4 Cj4gKFhFTikgZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxNjQyMDAwIG1lbXN6PTB4 MTI5ODAKPiAoWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDE2NTUwMDAgbWVt c3o9MHg0ZmYwMDAKPiAoWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAt PiAweDFiNTQwMDAKPiAoWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4 Igo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiCj4gKFhF TikgZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4tMy4wIgo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwCj4gKFhFTikg ZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MTY1NTIwMAo+IChYRU4pIGVs Zl94ZW5fcGFyc2Vfbm90ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDAKPiAo WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxl c3xwYWVfcGdkaXJfYWJvdmVfNGdiIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01P REUgPSAieWVzIgo+IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVyaWMi Cj4gKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQo+ IChYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDEKPiAoWEVOKSBl bGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4ZmZmZjgwMDAwMDAwMDAwMAo+IChY RU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwCj4gKFhFTikgZWxmX3hl bl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoKPiAoWEVOKSAgICAgdmlydF9iYXNlICAgICAg ICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAo+IChYRU4pICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgw Cj4gKFhFTikgICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKPiAoWEVO KSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMAo+IChYRU4pICAgICB2 aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgxYjU0MDAwCj4gKFhFTikgICAgIHZpcnRfZW50 cnkgICAgICAgPSAweGZmZmZmZmZmODE2NTUyMDAKPiAoWEVOKSAgICAgcDJtX2Jhc2UgICAgICAg ICA9IDB4ZmZmZmZmZmZmZmZmZmZmZgo+IChYRU4pICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is IGNvbXBhdDMyCj4gKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAw eDEwMDAwMDAgLT4gMHgxYjU0MDAwCj4gKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5U Ogo+IChYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjI0MDAwMDAwLT4wMDAwMDAwMjI4MDAw MDAwICg1MDYzMDggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQo+IChYRU4pICBJbml0LiByYW1kaXNr OiAwMDAwMDAwMjJmOWM0MDAwLT4wMDAwMDAwMjJmZmZmMjAwCj4gKFhFTikgVklSVFVBTCBNRU1P UlkgQVJSQU5HRU1FTlQ6Cj4gKFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAt PmZmZmZmZmZmODFiNTQwMDAKPiAoWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MWI1NDAw MC0+ZmZmZmZmZmY4MjE4ZjIwMAo+IChYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgyMTkw MDAwLT5mZmZmZmZmZjgyNTkwMDAwCj4gKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODI1 OTAwMDAtPmZmZmZmZmZmODI1OTA0YjQKPiAoWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4 MjU5MTAwMC0+ZmZmZmZmZmY4MjVhODAwMAo+IChYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZm ZjgyNWE4MDAwLT5mZmZmZmZmZjgyNWE5MDAwCj4gKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZm ZmZmODAwMDAwMDAtPmZmZmZmZmZmODI4MDAwMDAKPiAoWEVOKSAgRU5UUlkgQUREUkVTUzogZmZm ZmZmZmY4MTY1NTIwMAo+IChYRU4pIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcwo+IChYRU4pIGVs Zl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZm ODE1ZDMwMDAKPiAoWEVOKSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODE1 ZDMwMDAgLT4gMHhmZmZmZmZmZjgxNjQxMGU4Cj4gKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRy IDIgYXQgMHhmZmZmZmZmZjgxNjQyMDAwIC0+IDB4ZmZmZmZmZmY4MTY1NDk4MAo+IChYRU4pIGVs Zl9sb2FkX2JpbmFyeTogcGhkciAzIGF0IDB4ZmZmZmZmZmY4MTY1NTAwMCAtPiAweGZmZmZmZmZm ODE2Y2MwMDAKPiAoWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgo+IChYRU4pIElu aXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgo+IChY RU4pIFN0ZC4gTG9nbGV2ZWw6IEFsbAo+IChYRU4pIEd1ZXN0IExvZ2xldmVsOiBBbGwKPiAoWEVO KSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gKFhFTikg KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUwo+IChYRU4pICoq KioqKiogVGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4gYnkg ZW5zdXJpbmcKPiAoWEVOKSAqKioqKioqIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5jaHJvbm91c2x5 IGRlbGl2ZXJlZCBvbiB0aGUgc2VyaWFsIGxpbmUuCj4gKFhFTikgKioqKioqKiBIb3dldmVyIGl0 IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QKPiAoWEVOKSAq KioqKioqIHRpbWVrZWVwaW5nLiBJdCBpcyBOT1QgcmVjb21tZW5kZWQgZm9yIHByb2R1Y3Rpb24g dXNlIQo+IChYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKPiAoWEVOKSAzLi4uIDIuLi4gMS4uLiAKPiAoWEVOKSAqKiogU2VyaWFsIGlucHV0IC0+IERP TTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikKPiAo WEVOKSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4KPiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp Y2FsIG1lbW9yeQo+IFhlbjogc2V0dXAgSVNBIGlkZW50aXR5IG1hcHMKPiBhYm91dCB0byBnZXQg c3RhcnRlZC4uLgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldAo+IEluaXRpYWxp emluZyBjZ3JvdXAgc3Vic3lzIGNwdQo+IExpbnV4IHZlcnNpb24gMy40LjAtcmM0LTAwMzk1LWc4 N2I1ZDkwLWRpcnR5IChyb290QHhlbikgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUt OCkgKSAjNyBTTVAgUFJFRU1QVCBNb24gTWF5IDcgMTM6MTY6MTAgQ0VTVCAyMDEyCj4gQ29tbWFu ZCBsaW5lOiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09 MkcgcGFuaWM9MTUgeGVuLXBjaWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5 cHJpbnRrPXhlbgo+IEZyZWVpbmcgOWEtMTAwIHBmbiByYW5nZTogMTAyIHBhZ2VzIGZyZWVkCj4g UmVsZWFzZWQgMTAyIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkKPiBTZXQgMTk3MDk0IHBhZ2Uocykg dG8gMS0xIG1hcHBpbmcKPiBQb3B1bGF0aW5nIDgwMDAwLTgwMDY2IHBmbiByYW5nZTogMTAyIHBh Z2VzIGFkZGVkCj4gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgo+ICBYZW46IDAwMDAw MDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlhMDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDAw MDA5YWMwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwMDAx MDAwMDAgLSAwMDAwMDAwMDgwMDY2MDAwICh1c2FibGUpCj4gIFhlbjogMDAwMDAwMDA4MDA2NjAw MCAtIDAwMDAwMDAwY2ZlODAwMDAgKHVudXNhYmxlKQo+ICBYZW46IDAwMDAwMDAwY2ZlODAwMDAg LSAwMDAwMDAwMGNmZTk4MDAwIChBQ1BJIGRhdGEpCj4gIFhlbjogMDAwMDAwMDBjZmU5ODAwMCAt IDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZTKQo+ICBYZW46IDAwMDAwMDAwY2ZlYzAwMDAgLSAw MDAwMDAwMGNmZjAwMDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAw MDAwMDBmZWMwMTAwMCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAw MDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAw MGZlZTAxMDAwIChyZXNlcnZlZCkKPiAgWGVuOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw MDAwMDAwMCAocmVzZXJ2ZWQpCj4gIFhlbjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAw MDAwMDAgKHVudXNhYmxlKQo+IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZAo+IE5YIChF eGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQo+IHVzZXItZGVmaW5lZCBwaHlzaWNh bCBSQU0gbWFwOgo+ICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAo dXNhYmxlKQo+ICB1c2VyOiAwMDAwMDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVz ZXJ2ZWQpCj4gIHVzZXI6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDgwMDAwMDAwICh1c2Fi bGUpCj4gIHVzZXI6IDAwMDAwMDAwODAwNjYwMDAgLSAwMDAwMDAwMGNmZTgwMDAwICh1bnVzYWJs ZSkKPiAgdXNlcjogMDAwMDAwMDBjZmU4MDAwMCAtIDAwMDAwMDAwY2ZlOTgwMDAgKEFDUEkgZGF0 YSkKPiAgdXNlcjogMDAwMDAwMDBjZmU5ODAwMCAtIDAwMDAwMDAwY2ZlYzAwMDAgKEFDUEkgTlZT KQo+ICB1c2VyOiAwMDAwMDAwMGNmZWMwMDAwIC0gMDAwMDAwMDBjZmYwMDAwMCAocmVzZXJ2ZWQp Cj4gIHVzZXI6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkK PiAgdXNlcjogMDAwMDAwMDBmZWMyMDAwMCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQo+ ICB1c2VyOiAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCj4g IHVzZXI6IDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKPiAg dXNlcjogMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAyMzAwMDAwMDAgKHVudXNhYmxlKQo+IERN SSBwcmVzZW50Lgo+IE5vIEFHUCBicmlkZ2UgZm91bmQKPiBsYXN0X3BmbiA9IDB4ODAwMDAgbWF4 X2FyY2hfcGZuID0gMHg0MDAwMDAwMDAKPiBmb3VuZCBTTVAgTVAtdGFibGUgYXQgW2ZmZmY4ODAw MDAwZmY3ODBdIGZmNzgwCj4gaW5pdF9tZW1vcnlfbWFwcGluZzogMDAwMDAwMDAwMDAwMDAwMC0w MDAwMDAwMDgwMDAwMDAwCj4gUkFNRElTSzogMDFiNTQwMDAgLSAwMjE5MDAwMAo+IEFDUEk6IFJT RFAgMDAwMDAwMDAwMDBmYmYyMCAwMDAyNCAodjAyIEFDUElBTSkKPiBBQ1BJOiBYU0RUIDAwMDAw MDAwY2ZlODAxMDAgMDAwNUMgKHYwMSAxMDI4MTEgWFNEVDE3NDAgMjAxMTEwMjggTVNGVCAwMDAw MDA5NykKPiBBQ1BJOiBGQUNQIDAwMDAwMDAwY2ZlODAyOTAgMDAwRjQgKHYwMyAxMDI4MTEgRkFD UDE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBEU0RUIDAwMDAwMDAwY2ZlODA0 NzAgMEU2RTMgKHYwMSAgQTE1OTUgQTE1OTUwMDAgMDAwMDAwMDAgSU5UTCAyMDA2MDExMykKPiBB Q1BJOiBGQUNTIDAwMDAwMDAwY2ZlOTgwMDAgMDAwNDAKPiBBQ1BJOiBBUElDIDAwMDAwMDAwY2Zl ODAzOTAgMDAwOTggKHYwMSAxMDI4MTEgQVBJQzE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykK PiBBQ1BJOiBNQ0ZHIDAwMDAwMDAwY2ZlODA0MzAgMDAwM0MgKHYwMSAxMDI4MTEgT0VNTUNGRyAg MjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBPRU1CIDAwMDAwMDAwY2ZlOTgwNDAgMDAw NzIgKHYwMSAxMDI4MTEgT0VNQjE3NDAgMjAxMTEwMjggTVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBI UEVUIDAwMDAwMDAwY2ZlOGY4YzAgMDAwMzggKHYwMSAxMDI4MTEgT0VNSFBFVCAgMjAxMTEwMjgg TVNGVCAwMDAwMDA5NykKPiBBQ1BJOiBJVlJTIDAwMDAwMDAwY2ZlOGY5MDAgMDAwRTAgKHYwMSAg QU1EICAgICBSRDg5MFMgMDAyMDIwMzEgQU1EICAwMDAwMDAwMCkKPiBBQ1BJOiBTU0RUIDAwMDAw MDAwY2ZlOGY5ZTAgMDBFMTAgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAw MDAwMSkKPiBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKPiBGYWtpbmcgYSBub2RlIGF0IDAw MDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA4MDAwMDAwMAo+IEluaXRtZW0gc2V0dXAgbm9kZSAwIDAw MDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA4MDAwMDAwMAo+ICAgTk9ERV9EQVRBIFswMDAwMDAwMDdm ZmZjMDAwIC0gMDAwMDAwMDA3ZmZmZmZmZl0KPiBab25lIFBGTiByYW5nZXM6Cj4gICBETUEgICAg ICAweDAwMDAwMDEwIC0+IDB4MDAwMDEwMDAKPiAgIERNQTMyICAgIDB4MDAwMDEwMDAgLT4gMHgw MDEwMDAwMAo+ICAgTm9ybWFsICAgZW1wdHkKPiBNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBl YWNoIG5vZGUKPiBFYXJseSBtZW1vcnkgUEZOIHJhbmdlcwo+ICAgICAwOiAweDAwMDAwMDEwIC0+ IDB4MDAwMDAwOWEKPiAgICAgMDogMHgwMDAwMDEwMCAtPiAweDAwMDgwMDAwCj4gQUNQSTogUE0t VGltZXIgSU8gUG9ydDogMHg4MDgKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19p ZFsweDAwXSBlbmFibGVkKQo+IEJJT1MgYnVnOiBBUElDIHZlcnNpb24gaXMgMCBmb3IgQ1BVIDAv MHgwLCBmaXhpbmcgdXAgdG8gMHgxMAo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj X2lkWzB4MDFdIGVuYWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRb MHgwMl0gZW5hYmxlZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAz XSBlbmFibGVkKQo+IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVu YWJsZWQpCj4gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl ZCkKPiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA3XSBsYXBpY19pZFsweDg2XSBkaXNhYmxlZCkK PiBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDg3XSBkaXNhYmxlZCkKPiBB Q1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCj4g SU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdT SSAwLTI1Mwo+IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lf YmFzZVsyNF0pCj4gSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMjUzLCBhZGRyZXNzIDB4 ZmVjMjAwMDAsIEdTSSAyNC0yNzcKPiBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAw IGdsb2JhbF9pcnEgMiBkZmwgZGZsKQo+IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJx IDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKPiBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24KPiBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhm ZWQwMDAwMAo+IDggUHJvY2Vzc29ycyBleGNlZWRzIE5SX0NQVVMgbGltaXQgb2YgNgo+IFNNUDog QWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcwo+IEFsbG9jYXRpbmcgUENJIHJlc291cmNl cyBzdGFydGluZyBhdCBjZmYwMDAwMCAoZ2FwOiBjZmYwMDAwMDoyZWQwMDAwMCkKPiBCb290aW5n IHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuCj4gWGVuIHZlcnNpb246IDQuMi11bnN0YWJs ZSAocHJlc2VydmUtQUQpCj4gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjYgbnJfY3B1bWFza19iaXRz OjYgbnJfY3B1X2lkczo2IG5yX25vZGVfaWRzOjEKPiBQRVJDUFU6IEVtYmVkZGVkIDI2IHBhZ2Vz L2NwdSBAZmZmZjg4MDA3ZmY0YzAwMCBzNzYxNjAgcjgxOTIgZDIyMTQ0IHUxMDY0OTYKPiBCdWls dCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFs IHBhZ2VzOiA1MTU5NzYKPiBQb2xpY3kgem9uZTogRE1BMzIKPiBLZXJuZWwgY29tbWFuZCBsaW5l OiBwbGFjZWhvbGRlciByb290PS9kZXYvbWFwcGVyL2xlbXJvdWNoLXhlbiBybyBtZW09MkcgcGFu aWM9MTUgeGVuLXBjaWJhY2suaGlkZT0oMDA6MTQuMikgY29uc29sZT1odmMwIGVhcmx5cHJpbnRr PXhlbgo+IFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRl cykKPiBQbGFjaW5nIDY0TUIgc29mdHdhcmUgSU8gVExCIGJldHdlZW4gZmZmZjg4MDA3OTYwMDAw MCAtIGZmZmY4ODAwN2Q2MDAwMDAKPiBzb2Z0d2FyZSBJTyBUTEIgYXQgcGh5cyAweDc5NjAwMDAw IC0gMHg3ZDYwMDAwMAo+IE1lbW9yeTogMTk3NTA2NGsvMjA5NzE1MmsgYXZhaWxhYmxlICg0NTY3 ayBrZXJuZWwgY29kZSwgNDcyayBhYnNlbnQsIDEyMTYxNmsgcmVzZXJ2ZWQsIDE4MzNrIGRhdGEs IDUzMmsgaW5pdCkKPiBTTFVCOiBHZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBN aW5PYmplY3RzPTAsIENQVXM9NiwgTm9kZXM9MQo+IFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBS Q1UgaW1wbGVtZW50YXRpb24uCj4gCUR1bXAgc3RhY2tzIG9mIHRhc2tzIGJsb2NraW5nIFJDVS1w cmVlbXB0IEdQLgo+IE5SX0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYKPiB4ZW46IHNjaSBvdmVy cmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xCj4geGVuOiBhY3BpIHNjaSA5 Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQo+IENvbnNvbGU6 IGNvbG91ciBWR0ErIDgweDI1Cj4gY29uc29sZSBbaHZjMF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg ZGlzYWJsZWQKPiBjb25zb2xlIFtodmMwXSBlbmFibGVkLCBib290Y29uc29sZSBkaXNhYmxlZAo+ IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMAo+IERldGVjdGVkIDMwMTAuMjU0IE1IeiBw cm9jZXNzb3IuCj4gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1 bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNjAyMC41MCBCb2dvTUlQUyAobHBqPTMwMTAy NTQpCj4gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxCj4gRGVudHJ5IGNhY2hl IGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcykKPiBJ bm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYg Ynl0ZXMpCj4gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKPiBJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBkZXZpY2VzCj4gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcgo+IEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGJsa2lvCj4gQ1BVOiBQaHlzaWNhbCBQ cm9jZXNzb3IgSUQ6IDAKPiBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwCj4gbWNlOiBDUFUgc3Vw cG9ydHMgNiBNQ0UgYmFua3MKPiBBQ1BJOiBDb3JlIHJldmlzaW9uIDIwMTIwMzIwCj4gY3B1IDAg c3BpbmxvY2sgZXZlbnQgaXJxIDI5NQo+IFBlcmZvcm1hbmNlIEV2ZW50czogKFhFTikgdHJhcHMu YzoyNTYxOmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4 MDAwMGU0YTc1ZGY4NjUxNCB0byAweDAwMDAwMDAwMDAwMGFiY2QuCj4gQnJva2VuIFBNVSBoYXJk d2FyZSBkZXRlY3RlZCwgdXNpbmcgc29mdHdhcmUgZXZlbnRzIG9ubHkuCj4gTUNFOiBJbi1rZXJu ZWwgTUNFIGRlY29kaW5nIGVuYWJsZWQuCj4gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAx Cj4gY3B1IDEgc3BpbmxvY2sgZXZlbnQgaXJxIDMwMgo+IGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv ciBDUFUgMgo+IGNwdSAyIHNwaW5sb2NrIGV2ZW50IGlycSAzMDkKPiBpbnN0YWxsaW5nIFhlbiB0 aW1lciBmb3IgQ1BVIDMKPiBjcHUgMyBzcGlubG9jayBldmVudCBpcnEgMzE2Cj4gaW5zdGFsbGlu ZyBYZW4gdGltZXIgZm9yIENQVSA0Cj4gY3B1IDQgc3BpbmxvY2sgZXZlbnQgaXJxIDMyMwo+IGlu c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgNQo+IGNwdSA1IHNwaW5sb2NrIGV2ZW50IGlycSAz MzAKPiBCcm91Z2h0IHVwIDYgQ1BVcwo+IGRldnRtcGZzOiBpbml0aWFsaXplZAo+IEdyYW50IHRh YmxlcyB1c2luZyB2ZXJzaW9uIDIgbGF5b3V0Lgo+IEdyYW50IHRhYmxlIGluaXRpYWxpemVkCj4g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgo+IFRPTTogMDAwMDAwMDBkMDAwMDAw MCBha2EgMzMyOE0KPiBUT00yOiAwMDAwMDAwMjMwMDAwMDAwIGFrYSA4OTYwTQo+IEFDUEk6IGJ1 cyB0eXBlIHBjaSByZWdpc3RlcmVkCj4gUENJOiBNTUNPTkZJRyBmb3IgZG9tYWluIDAwMDAgW2J1 cyAwMC1mZl0gYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIChiYXNlIDB4ZTAwMDAwMDAp Cj4gUENJOiBub3QgdXNpbmcgTU1DT05GSUcKPiBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlw ZSAxIGZvciBiYXNlIGFjY2Vzcwo+IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9y IGV4dGVuZGVkIGFjY2Vzcwo+IGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwCj4gQUNQSTog QWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQo+IEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERl dmljZSkKPiBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpCj4gQUNQSTogQWRk ZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpCj4gQUNQSTogRXhlY3V0ZWQgMyBi bG9ja3Mgb2YgbW9kdWxlLWxldmVsIGV4ZWN1dGFibGUgQU1MIGNvZGUKPiBBQ1BJOiBJbnRlcnBy ZXRlciBlbmFibGVkCj4gQUNQSTogKHN1cHBvcnRzIFMwIFM1KQo+IEFDUEk6IFVzaW5nIElPQVBJ QyBmb3IgaW50ZXJydXB0IHJvdXRpbmcKPiBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBb YnVzIDAwLWZmXSBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAw MCkKPiBQQ0k6IE1NQ09ORklHIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZl ZCBpbiBBQ1BJIG1vdGhlcmJvYXJkIHJlc291cmNlcwo+IEFDUEk6IEVDOiBHUEUgPSAweGEsIEkv TzogY29tbWFuZC9zdGF0dXMgPSAweDY2LCBkYXRhID0gMHg2Mgo+IFBDSTogVXNpbmcgaG9zdCBi cmlkZ2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9jcnMiIGFu ZCByZXBvcnQgYSBidWcKPiBBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAw MCBbYnVzIDAwLWZmXSkKPiBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cg W2lvICAweDAwMDAtMHgwY2Y3XQo+IHBjaV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdp bmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk Z2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQo+IHBjaV9yb290IFBOUDBBMDM6 MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwZDAwMDAtMHgwMDBkZmZmZl0KPiBwY2lf cm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZjAwMDAwLTB4ZGZm ZmZmZmZdCj4gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhm MDAwMDAwMC0weGZlYmZmZmZmXQo+IFBDSSBob3N0IGJyaWRnZSB0byBidXMgMDAwMDowMAo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDAwMDAtMHgwY2Y3XQo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQo+IHBj aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZm ZmZdCj4gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4MDAwZDAwMDAt MHgwMDBkZmZmZl0KPiBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhj ZmYwMDAwMC0weGRmZmZmZmZmXQo+IHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2Ug W21lbSAweGYwMDAwMDAwLTB4ZmViZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDIuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA3LTA3XQo+IHBjaSAwMDAwOjA2OjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHBy ZS0xLjEgUENJZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9y Y2UnCj4gcGNpIDAwMDA6MDA6MDQuMDogUENJIGJyaWRnZSB0byBbYnVzIDA2LTA2XQo+IHBjaSAw MDAwOjAwOjA1LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNS0wNV0KPiBwY2kgMDAwMDowMDowNi4w OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdCj4gcGNpIDAwMDA6MDA6MDcuMDogUENJIGJyaWRn ZSB0byBbYnVzIDAzLTAzXQo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw Mi0wMl0KPiBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdIChzdWJ0 cmFjdGl2ZSBkZWNvZGUpCj4gIHBjaTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRy b2wgKDB4MWQpCj4gIHBjaTAwMDA6MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFjKSBncmFudGVk Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDowMC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDowNS4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wCj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowMDowNy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDow ZC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowMDoxMi4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yCj4g KFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2Ug MDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wCj4gKFhFTikg UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxNC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40Cj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNC41Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4w Cj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZp Y2UgMDAwMDowMDoxOC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xCj4gKFhF TikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAw MDowMDoxOC4zCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40Cj4gKFhFTikgUENJ IGFkZCBkZXZpY2UgMDAwMDowNzowMC4wCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNzow MC4xCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wCj4gKFhFTikgUENJIGFkZCBk ZXZpY2UgMDAwMDowNjowMC4xCj4gcGNpIDAwMDA6MDY6MDAuMTogRmFpbGVkIHRvIGFkZCAtIHBh c3N0aHJvdWdoIG9yIE1TSS9NU0ktWCBtaWdodCBmYWlsIQo+IChYRU4pIFBDSSBhZGQgZGV2aWNl IDAwMDA6MDU6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMAo+IChYRU4p IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6 MDI6MDAuMAo+IChYRU4pIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDI6MDAuMQo+IEFDUEk6IFBDSSBJ bnRlcnJ1cHQgTGluayBbTE5LQV0gKElSUXMgKjQgNyAxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpCj4gQUNQSTogUENJ IEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6IFBD SSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJOiBQ Q0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFzIDQgKjcgMTAgMTEgMTQgMTUpCj4gQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyA0IDcgMTAgKjExIDE0IDE1KQo+IEFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkKPiBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFzIDQgNyAxMCAxMSAxNCAxNSkgKjAsIGRp c2FibGVkLgo+IHhlbi9iYWxsb29uOiBJbml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuCj4geGVu LWJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4KPiB2Z2FhcmI6IGRldmljZSBh ZGRlZDogUENJOjAwMDA6MDc6MDAuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1u b25lCj4gdmdhYXJiOiBsb2FkZWQKPiB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlIDAw MDA6MDc6MDAuMAo+IFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkCj4gdXNiY29yZTogcmVnaXN0 ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcwo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3 IGludGVyZmFjZSBkcml2ZXIgaHViCj4gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRy aXZlciB1c2IKPiBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nCj4gU3dpdGNoaW5nIHRv IGNsb2Nrc291cmNlIHhlbgo+IEZTLUNhY2hlOiBMb2FkZWQKPiBDYWNoZUZpbGVzOiBMb2FkZWQK PiBwbnA6IFBuUCBBQ1BJIGluaXQKPiBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZAo+IHN5 c3RlbSAwMDowMTogW21lbSAweGZlYzIwMDAwLTB4ZmVjMjAwZmZdIGNvdWxkIG5vdCBiZSByZXNl cnZlZAo+IHN5c3RlbSAwMDowMjogW21lbSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdIGhhcyBiZWVu IHJlc2VydmVkCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA4IGZvciBnc2kgOAo+ IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTMgZm9yIGdzaSAxMwo+IHN5c3RlbSAw MDowODogW21lbSAweGZlYzAwMDAwLTB4ZmVjMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+ IHN5c3RlbSAwMDowODogW21lbSAweGZlZTAwMDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2Vy dmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDRkMC0weDA0ZDFdIGhhcyBiZWVuIHJlc2VydmVk Cj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0g MDA6MDk6IFtpbyAgMHgwNGQ2XSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lv ICAweDBjMDAtMHgwYzAxXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW2lvICAw eDBjMTRdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1MC0weDBj NTFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGM1Ml0gaGFzIGJl ZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNlcnZl ZAo+IHN5c3RlbSAwMDowOTogW2lvICAweDBjNmZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVt IDAwOjA5OiBbaW8gIDB4MGNkMC0weDBjZDFdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAw OjA5OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5 OiBbaW8gIDB4MGNkNC0weDBjZDVdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBb aW8gIDB4MGNkNi0weDBjZDddIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8g IDB4MGNkOC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4 MDgwMC0weDA4OWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIw MC0weDBiMWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MGIyMC0w eDBiM2ZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkwMC0weDA5 MGZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4MDkxMC0weDA5MWZd IGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhh cyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZm Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MDk6IFttZW0gMHhmZmI4MDAwMC0weGZm YmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowOTogW21lbSAweGZlYzEwMDAw LTB4ZmVjMTAwMWZdIGhhcyBiZWVuIHJlc2VydmVkCj4gc3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVk ODAwMDAtMHhmZWQ4MGZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAg MHgwMjMwLTB4MDIzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgw MjkwLTB4MDI5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwZjQw LTB4MGY0Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYTMwLTB4 MGEzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKPiBzeXN0ZW0gMDA6MGI6IFttZW0gMHhlMDAwMDAwMC0w eGVmZmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweDAwMDAw MDAwLTB4MDAwOWZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21l bSAweDAwMGMwMDAwLTB4MDAwY2ZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+IHN5c3RlbSAw MDowYzogW21lbSAweDAwMGUwMDAwLTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZAo+ IHN5c3RlbSAwMDowYzogW21lbSAweDAwMTAwMDAwLTB4Y2ZlZmZmZmZdIGNvdWxkIG5vdCBiZSBy ZXNlcnZlZAo+IHN5c3RlbSAwMDowYzogW21lbSAweGZlYzAwMDAwLTB4ZmZmZmZmZmZdIGNvdWxk IG5vdCBiZSByZXNlcnZlZAo+IHBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMKPiBBQ1BJ OiBBQ1BJIGJ1cyB0eXBlIHBucCB1bnJlZ2lzdGVyZWQKPiBwY2liYWNrIDAwMDA6MDA6MTQuMjog c2VpemluZyBkZXZpY2UKPiBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweDB4 ZmZmZmZmKSAtIGFib3J0aW5nLgo+IHBjaSAwMDAwOjAwOjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1 cyAwNy0wN10KPiBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAt MHhlZmZmXQo+IHBjaSAwMDAwOjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAw MDAtMHhmZTlmZmZmZl0KPiBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw eGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0KPiBwY2kgMDAwMDowMDowNC4wOiBQQ0kg YnJpZGdlIHRvIFtidXMgMDYtMDZdCj4gcGNpIDAwMDA6MDA6MDQuMDogICBicmlkZ2Ugd2luZG93 IFtpbyAgMHhkMDAwLTB4ZGZmZl0KPiBwY2kgMDAwMDowMDowNC4wOiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweGZlODAwMDAwLTB4ZmU4ZmZmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRn ZSB0byBbYnVzIDA1LTA1XQo+IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8g IDB4YzAwMC0weGNmZmZdCj4gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0g MHhmZTcwMDAwMC0weGZlN2ZmZmZmXQo+IHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8g W2J1cyAwNC0wNF0KPiBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGIw MDAtMHhiZmZmXQo+IHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU2 MDAwMDAtMHhmZTZmZmZmZl0KPiBwY2kgMDAwMDowMDowNy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg MDMtMDNdCj4gcGNpIDAwMDA6MDA6MDcuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTUwMDAw MC0weGZlNWZmZmZmXQo+IHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMi0w Ml0KPiBwY2kgMDAwMDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZm XQo+IHBjaSAwMDAwOjAwOjBkLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU0MDAwMDAtMHhm ZTRmZmZmZl0KPiBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdCj4g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MiBmb3IgZ3NpIDUyCj4gQWxyZWFkeSBz ZXR1cCB0aGUgR1NJIDo1Mgo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgNTIgZm9y IGdzaSA1Mgo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTIKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDUzIGZvciBnc2kgNTMKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzCj4g TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyCj4gSVAgcm91dGUgY2FjaGUgaGFzaCB0 YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKPiBUQ1AgZXN0YWJs aXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNjIxNDQgKG9yZGVyOiAxMCwgNDE5NDMwNCBieXRl cykKPiBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3 NiBieXRlcykKPiBUQ1A6IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDI2MjE0 NCBiaW5kIDY1NTM2KQo+IFRDUDogcmVubyByZWdpc3RlcmVkCj4gVURQIGhhc2ggdGFibGUgZW50 cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQo+IFVEUC1MaXRlIGhhc2ggdGFibGUg ZW50cmllczogMTAyNCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQo+IE5FVDogUmVnaXN0ZXJlZCBw cm90b2NvbCBmYW1pbHkgMQo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9y IGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4g eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFkeSBz ZXR1cCB0aGUgR1NJIDoxOAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9y IGdzaSAxOAo+IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgKPiB4ZW5fbWFwX3BpcnFfZ3NpOiBy ZXR1cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4g VW5wYWNraW5nIGluaXRyYW1mcy4uLgo+IEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogNjM4NGsgZnJl ZWQKPiBtaWNyb2NvZGU6IENQVTA6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6 IENQVTE6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTI6IHBhdGNoX2xl dmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYK PiBtaWNyb2NvZGU6IENQVTQ6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IENQ VTU6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYKPiBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUg RHJpdmVyOiB2Mi4wMCA8dGlncmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmEK PiBOVEZTIGRyaXZlciAyLjEuMzAgW0ZsYWdzOiBSL1ddLgo+IG1zZ21uaSBoYXMgYmVlbiBzZXQg dG8gMzg3MAo+IEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAw LjQgbG9hZGVkIChtYWpvciAyNTMpCj4gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZCAoZGVm YXVsdCkKPiBwY2llcG9ydCAwMDAwOjAwOjAyLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0ll IFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2gg UENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDc6MDAuMTogU2lnbmFsaW5nIFBNRSB0aHJv dWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaWVwb3J0IDAwMDA6MDA6MDQuMDogU2lnbmFsaW5n IFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjA2OjAwLjA6IFNpZ25h bGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowNjowMC4xOiBT aWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDow MDowNS4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAw MDA6MDU6MDAuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBj aWVwb3J0IDAwMDA6MDA6MDYuMDogU2lnbmFsaW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVy cnVwdAo+IHBjaSAwMDAwOjA0OjAwLjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBp bnRlcnJ1cHQKPiBwY2llcG9ydCAwMDAwOjAwOjA3LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQ Q0llIFBNRSBpbnRlcnJ1cHQKPiBwY2kgMDAwMDowMzowMC4wOiBTaWduYWxpbmcgUE1FIHRocm91 Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpZXBvcnQgMDAwMDowMDowZC4wOiBTaWduYWxpbmcg UE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0Cj4gcGNpIDAwMDA6MDI6MDAuMDogU2lnbmFs aW5nIFBNRSB0aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdAo+IHBjaSAwMDAwOjAyOjAwLjE6IFNp Z25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBpbnRlcnJ1cHQKPiBwY2lfaG90cGx1ZzogUENJ IEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMg L2RldmljZXMvTE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwCj4g QUNQSTogUG93ZXIgQnV0dG9uIFtQV1JCXQo+IGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2Rldmlj ZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQxCj4gQUNQSTogUG93ZXIgQnV0 dG9uIFtQV1JGXQo+IEdIRVM6IEhFU1QgaXMgbm90IGVuYWJsZWQhCj4gRXZlbnQtY2hhbm5lbCBk ZXZpY2UgaW5zdGFsbGVkLgo+IHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHZwY2kKPiBTZXJpYWw6 IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNhYmxlZAo+IDAwMDA6 MDI6MDAuMTogdHR5UzAgYXQgSS9PIDB4YTg4MCAoaXJxID0gNDEpIGlzIGEgU1QxNjY1MFYyCj4g aHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9DUlMKPiBOb24tdm9sYXRpbGUg bWVtb3J5IGRyaXZlciB2MS4zCj4gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIg MC45LjEgKHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4KPiBIYW5n Y2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLgo+IGxvb3A6IG1vZHVsZSBsb2FkZWQKPiBh aGNpIDAwMDA6MDA6MTEuMDogQUhDSSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBwb3J0cyA2IEdicHMg MHgzZiBpbXBsIFNBVEEgbW9kZQo+IGFoY2kgMDAwMDowMDoxMS4wOiBmbGFnczogNjRiaXQgbmNx IHNudGYgaWxjayBwbSBsZWQgY2xvIHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2kwIDogYWhjaQo+ IHNjc2kxIDogYWhjaQo+IHNjc2kyIDogYWhjaQo+IHNjc2kzIDogYWhjaQo+IHNjc2k0IDogYWhj aQo+IHNjc2k1IDogYWhjaQo+IGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhm ZTNmZTAwMCBwb3J0IDB4ZmUzZmUxMDAgaXJxIDE5Cj4gYXRhMzogU0FUQSBtYXggVURNQS8xMzMg YWJhciBtMTAyNEAweGZlM2ZlMDAwIHBvcnQgMHhmZTNmZTE4MCBpcnEgMTkKPiBhdGE0OiBTQVRB IG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMjAwIGlycSAx OQo+IGF0YTU6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmZTNmZTAwMCBwb3J0IDB4 ZmUzZmUyODAgaXJxIDE5Cj4gYXRhNjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGZl M2ZlMDAwIHBvcnQgMHhmZTNmZTMwMCBpcnEgMTkKPiBhdGE3OiBTQVRBIG1heCBVRE1BLzEzMyBh YmFyIG0xMDI0QDB4ZmUzZmUwMDAgcG9ydCAweGZlM2ZlMzgwIGlycSAxOQo+IGFoY2kgMDAwMDow NjowMC4wOiBBSENJIDAwMDEuMDAwMCAzMiBzbG90cyAyIHBvcnRzIDMgR2JwcyAweDMgaW1wbCBT QVRBIG1vZGUKPiBhaGNpIDAwMDA6MDY6MDAuMDogZmxhZ3M6IDY0Yml0IG5jcSBwbSBsZWQgY2xv IHBtcCBwaW8gc2x1bSBwYXJ0IAo+IHNjc2k2IDogYWhjaQo+IHNjc2k3IDogYWhjaQo+IGF0YTg6 IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTgxOTJAMHhmZThmZTAwMCBwb3J0IDB4ZmU4ZmUxMDAg aXJxIDQ0Cj4gYXRhOTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtODE5MkAweGZlOGZlMDAwIHBv cnQgMHhmZThmZTE4MCBpcnEgNDQKPiB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2 ZXIsIDEuNgo+IHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNv bW0uY29tPgo+IHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMzAKPiBza3kyIDAwMDA6MDQ6MDAuMDog WXVrb24tMiBPcHRpbWEgY2hpcCByZXZpc2lvbiAxCj4gc2t5MiAwMDAwOjA0OjAwLjA6IGV0aDA6 IGFkZHIgMjA6Y2Y6MzA6NmQ6ODk6YTUKPiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh Y2UgZHJpdmVyIGNkY19uY20KPiBmaXJld2lyZV9vaGNpIDAwMDA6MDU6MDAuMDogYWRkZWQgT0hD SSB2MS4xMCBkZXZpY2UgYXMgY2FyZCAwLCA0IElSICsgOCBJVCBjb250ZXh0cywgcXVpcmtzIDB4 MTEKPiBlaGNpX2hjZDogVVNCIDIuMCAnRW5oYW5jZWQnIEhvc3QgQ29udHJvbGxlciAoRUhDSSkg RHJpdmVyCj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3Cj4g QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNwo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogRUhDSSBI b3N0IENvbnRyb2xsZXIKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IG5ldyBVU0IgYnVzIHJlZ2lz dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBw bHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5k Cj4gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBkZWJ1ZyBwb3J0IDEKPiBlaGNpX2hjZCAwMDAwOjAw OjEyLjI6IGlycSAxNywgaW8gbWVtIDB4ZmUzZmU0MDAKPiBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6 IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwCj4gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZv dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMgo+IHVzYiB1c2IxOiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2Ix OiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6 IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBlaGNpX2hjZAo+IHVzYiB1c2Ix OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMgo+IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5k Cj4gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1 cm5pbmcgaXJxIDE3IGZvciBnc2kgMTcKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3Cj4gZWhj aV9oY2QgMDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcgo+IGVoY2lfaGNkIDAwMDA6 MDA6MTMuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyCj4g ZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIv MyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQKPiBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IGRlYnVn IHBvcnQgMQo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogaXJxIDE3LCBpbyBtZW0gMHhmZTNmZTgw MAo+IGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAKPiB1 c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0w MDAyCj4gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs IFNlcmlhbE51bWJlcj0xCj4gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVy Cj4gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkw LWRpcnR5IGVoY2lfaGNkCj4gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yCj4g aHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3Rl ZAo+IHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNwo+IEFscmVh ZHkgc2V0dXAgdGhlIEdTSSA6MTcKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IEVIQ0kgSG9zdCBD b250cm9sbGVyCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVk LCBhc3NpZ25lZCBidXMgbnVtYmVyIDMKPiBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5aW5n IEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZAo+IGF0 YTU6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGF0YTQ6IFNBVEEg bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGVoY2lfaGNkIDAwMDA6MDA6MTYu MjogZGVidWcgcG9ydCAxCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBpcnEgMTcsIGlvIG1lbSAw eGZlM2ZlYzAwCj4gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kg MS4wMAo+IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQ cm9kdWN0PTAwMDIKPiB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKPiB1c2IgdXNiMzogUHJvZHVjdDogRUhDSSBIb3N0IENv bnRyb2xsZXIKPiB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjQuMC1yYzQtMDAzOTUt Zzg3YjVkOTAtZGlydHkgZWhjaV9oY2QKPiB1c2IgdXNiMzogU2VyaWFsTnVtYmVyOiAwMDAwOjAw OjE2LjIKPiBhdGE4OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKPiBo dWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZAo+IGh1YiAzLTA6MS4wOiA0IHBvcnRzIGRldGVjdGVk Cj4gYXRhMjogU0FUQSBsaW5rIHVwIDMuMCBHYnBzIChTU3RhdHVzIDEyMyBTQ29udHJvbCAzMDAp Cj4gb2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy Cj4geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBmb3IgZ3NpIDE4Cj4gQWxyZWFk eSBzZXR1cCB0aGUgR1NJIDoxOAo+IG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogT0hDSSBIb3N0IENv bnRyb2xsZXIKPiBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs IGFzc2lnbmVkIGJ1cyBudW1iZXIgNAo+IG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaXJxIDE4LCBp byBtZW0gMHhmZTNmNzAwMAo+IGF0YTk6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRy b2wgMzAwKQo+IGF0YTc6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+ IGF0YTM6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQo+IGF0YTIuMDA6 IEFUQS04OiBJTlRFTCBTU0RTQTJDVzEyMEczLCA0UEMxMDM2MiwgbWF4IFVETUEvMTMzCj4gYXRh Mi4wMDogMjM0NDQxNjQ4IHNlY3RvcnMsIG11bHRpIDE6IExCQTQ4IE5DUSAoZGVwdGggMzEvMzIp Cj4gYXRhNjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApCj4gdXNiIHVz YjQ6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+ IHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp YWxOdW1iZXI9MQo+IHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVz YiB1c2I0OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0 eSBvaGNpX2hjZAo+IHVzYiB1c2I0OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTIuMAo+IGh1YiA0 LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4 ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgKPiBBbHJlYWR5IHNl dHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJv bGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz aWduZWQgYnVzIG51bWJlciA1Cj4gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1l bSAweGZlM2ZjMDAwCj4gYXRhMi4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMzMKPiB1c2IgdXNi NTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxCj4g dXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjU6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5 IG9oY2lfaGNkCj4gdXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4wCj4gc2NzaSAw OjA6MDowOiBEaXJlY3QtQWNjZXNzICAgICBBVEEgICAgICBJTlRFTCBTU0RTQTJDVzEyIDRQQzEg UFE6IDAgQU5TSTogNQo+IGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDUtMDoxLjA6 IDUgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZv ciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDox NC41OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVT QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA2Cj4gb2hjaV9oY2QgMDAwMDow MDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZkMDAwCj4gdXNiIDEtMTogbmV3IGhpZ2gtc3Bl ZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBlaGNpX2hjZAo+IHNkIDA6MDowOjA6IFtzZGFd IDIzNDQ0MTY0OCA1MTItYnl0ZSBsb2dpY2FsIGJsb2NrczogKDEyMCBHQi8xMTEgR2lCKQo+IHNk IDA6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmCj4gc2QgMDowOjA6MDogW3NkYV0g V3JpdGUgY2FjaGU6IGVuYWJsZWQsIHJlYWQgY2FjaGU6IGVuYWJsZWQsIGRvZXNuJ3Qgc3VwcG9y dCBEUE8gb3IgRlVBCj4gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0x ZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVzYiB1c2I2OiBQcm9kdWN0OiBPSENJ IEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNC4wLXJj NC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6 IDAwMDA6MDA6MTQuNQo+IGh1YiA2LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDYtMDoxLjA6 IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZv ciBnc2kgMTgKPiBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4Cj4gb2hjaV9oY2QgMDAwMDowMDox Ni4wOiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogbmV3IFVT QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3Cj4gb2hjaV9oY2QgMDAwMDow MDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGZlM2ZmMDAwCj4gIHNkYTogc2RhMSBzZGEyCj4gc2Qg MDowOjA6MDogW3NkYV0gQXR0YWNoZWQgU0NTSSBkaXNrCj4gdXNiIHVzYjc6IE5ldyBVU0IgZGV2 aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQo+IHVzYiB1c2I3OiBOZXcg VVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQo+IHVz YiB1c2I3OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcgo+IHVzYiB1c2I3OiBNYW51ZmFj dHVyZXI6IExpbnV4IDMuNC4wLXJjNC0wMDM5NS1nODdiNWQ5MC1kaXJ0eSBvaGNpX2hjZAo+IHVz YiB1c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMAo+IGZpcmV3aXJlX2NvcmUgMDAwMDow NTowMC4wOiBjcmVhdGVkIGRldmljZSBmdzA6IEdVSUQgMDAxZThjMDAwMGRlOTEzNiwgUzQwMAo+ IGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kCj4gaHViIDctMDoxLjA6IDQgcG9ydHMgZGV0ZWN0 ZWQKPiB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDUwIGZvciBnc2kgNTAKPiBBbHJl YWR5IHNldHVwIHRoZSBHU0kgOjUwCj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiB4SENJIEhvc3Qg Q29udHJvbGxlcgo+IHhoY2lfaGNkIDAwMDA6MDM6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl ZCwgYXNzaWduZWQgYnVzIG51bWJlciA4Cj4geGhjaV9oY2QgMDAwMDowMzowMC4wOiBpcnEgNTAs IGlvIG1lbSAweGZlNWZlMDAwCj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu ZG9yPTA0MjQsIGlkUHJvZHVjdD0yNTA0Cj4gdXNiIDEtMTogTmV3IFVTQiBkZXZpY2Ugc3RyaW5n czogTWZyPTAsIFByb2R1Y3Q9MCwgU2VyaWFsTnVtYmVyPTAKPiB1c2IgdXNiODogTmV3IFVTQiBk ZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyCj4gdXNiIHVzYjg6IE5l dyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xCj4g dXNiIHVzYjg6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gaHViIDEtMToxLjA6IFVT QiBodWIgZm91bmQKPiB1c2IgdXNiODogTWFudWZhY3R1cmVyOiBMaW51eCAzLjQuMC1yYzQtMDAz OTUtZzg3YjVkOTAtZGlydHkgeGhjaV9oY2QKPiB1c2IgdXNiODogU2VyaWFsTnVtYmVyOiAwMDAw OjAzOjAwLjAKPiBodWIgMS0xOjEuMDogNCBwb3J0cyBkZXRlY3RlZAo+IGh1YiA4LTA6MS4wOiBV U0IgaHViIGZvdW5kCj4gaHViIDgtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKPiB4aGNpX2hjZCAw MDAwOjAzOjAwLjA6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4geGhjaV9oY2QgMDAwMDowMzowMC4w OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkKPiB1c2IgdXNi OTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzCj4g dXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh bE51bWJlcj0xCj4gdXNiIHVzYjk6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyCj4gdXNi IHVzYjk6IE1hbnVmYWN0dXJlcjogTGludXggMy40LjAtcmM0LTAwMzk1LWc4N2I1ZDkwLWRpcnR5 IHhoY2lfaGNkCj4gdXNiIHVzYjk6IFNlcmlhbE51bWJlcjogMDAwMDowMzowMC4wCj4gaHViIDkt MDoxLjA6IFVTQiBodWIgZm91bmQKPiBodWIgOS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZAo+IHVz YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHAKPiB1c2Jjb3JlOiBy ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVhcwo+IEluaXRpYWxpemluZyBVU0IgTWFz cyBTdG9yYWdlIGRyaXZlci4uLgo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNiLXN0b3JhZ2UKPiBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4K PiB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsCj4gdXNi Y29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1bXNfZW5ldWI2MjUwCj4gaTgw NDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5 Lgo+IHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKPiBzZXJpbzogaTgw NDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgo+IG1vdXNlZGV2OiBQUy8yIG1vdXNlIGRl dmljZSBjb21tb24gZm9yIGFsbCBtaWNlCj4gaW5wdXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMv cGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0Mgo+IHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdh a2UgZnJvbSBTNAo+IHJ0Y19jbW9zIDAwOjA0OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21v cyBhcyBydGMwCj4gcnRjMDogYWxhcm1zIHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMg bnZyYW0KPiBpMmMgL2RldiBlbnRyaWVzIGRyaXZlcgo+IEFDUEkgV2FybmluZzogMHgwMDAwMDAw MDAwMDAwYjAwLTB4MDAwMDAwMDAwMDAwMGIwNyBTeXN0ZW1JTyBjb25mbGljdHMgd2l0aCBSZWdp b24gXF9TQl8uUENJMC5TQlJHLkFTT0MuU01SRyAxICgyMDEyMDMyMC91dGFkZHJlc3MtMjUxKQo+ IEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJsZSBmb3IgdGhpcyBkZXZpY2UsIHlv dSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5hdGl2ZSBkcml2ZXIKPiBBVEswMTEwIEFU SzAxMTA6MDA6IEVDIGVuYWJsZWQKPiBzcDUxMDBfdGNvOiBTUDUxMDAgVENPIFdhdGNoRG9nIFRp bWVyIERyaXZlciB2MC4wMQo+IHNwNTEwMF90Y286IG1taW8gYWRkcmVzcyAweGI4ZmUwMCBhbHJl YWR5IGluIHVzZQo+IGl0ODdfd2R0OiBDaGlwIElUODcyMSByZXZpc2lvbiAxIGluaXRpYWxpemVk LiB0aW1lb3V0PTYwIHNlYyAobm93YXlvdXQ9MCB0ZXN0bW9kZT0wIGV4Y2x1c2l2ZT0xIG5vZ2Ft ZXBvcnQ9MCkKPiB4ZW5fd2R0OiBYZW4gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAxCj4geGVu X3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYgb24gbWlub3I9MTMwICgtMTYpCj4gd2R0OiBw cm9iZSBvZiB3ZHQgZmFpbGVkIHdpdGggZXJyb3IgLTE2Cj4gZGV2aWNlLW1hcHBlcjogdWV2ZW50 OiB2ZXJzaW9uIDEuMC4zCj4gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjIuMC1pb2N0bCAoMjAx MS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KPiBFREFDIE1DOiBWZXI6 IDIuMS4wCj4gQU1ENjQgRURBQyBkcml2ZXIgdjMuNC4wCj4gRURBQyBhbWQ2NDogRFJBTSBFQ0Mg ZGlzYWJsZWQuCj4gRURBQyBhbWQ2NDogRUNDIGRpc2FibGVkIGluIHRoZSBCSU9TIG9yIG5vIEVD QyBjYXBhYmlsaXR5LCBtb2R1bGUgd2lsbCBub3QgbG9hZC4KPiAgRWl0aGVyIGVuYWJsZSBFQ0Mg Y2hlY2tpbmcgb3IgZm9yY2UgbW9kdWxlIGxvYWRpbmcgYnkgc2V0dGluZyAnZWNjX2VuYWJsZV9v dmVycmlkZScuCj4gIChOb3RlIHRoYXQgdXNlIG9mIHRoZSBvdmVycmlkZSBtYXkgY2F1c2UgdW5r bm93biBzaWRlIGVmZmVjdHMuKQo+IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgdXNiaGlkCj4gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyCj4gVENQOiBjdWJpYyBy ZWdpc3RlcmVkCj4gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwo+IHJ0Y19jbW9z IDAwOjA0OiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDEyLTA1LTA3IDExOjE5OjEwIFVUQyAo MTMzNjM4OTU1MCkKPiBwb3dlcm5vdy1rODogRm91bmQgMSBBTUQgUGhlbm9tKHRtKSBJSSBYNiAx MDc1VCBQcm9jZXNzb3IgKDYgY3B1IGNvcmVzKSAodmVyc2lvbiAyLjIwLjAwKQo+IHBvd2Vybm93 LWs4OiBDb3JlIFBlcmZvcm1hbmNlIEJvb3N0aW5nOiBvbi4KPiBGcmVlaW5nIHVudXNlZCBrZXJu ZWwgbWVtb3J5OiA1MzJrIGZyZWVkCj4gTG9hZGluZywgcGxlYXNlIHdhaXQuLi4KPiB1ZGV2WzEw NzhdOiBzdGFydGluZyB2ZXJzaW9uIDE2NAo+IHVzYiA0LTI6IG5ldyBmdWxsLXNwZWVkIFVTQiBk ZXZpY2UgbnVtYmVyIDIgdXNpbmcgb2hjaV9oY2QKPiB1c2IgNC0yOiBOZXcgVVNCIGRldmljZSBm b3VuZCwgaWRWZW5kb3I9MDQxZSwgaWRQcm9kdWN0PTMwZGMKPiB1c2IgNC0yOiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9Mwo+IHVzYiA0LTI6 IFByb2R1Y3Q6IFNvdW5kIEJsYXN0ZXIgVGFjdGljKDNEKSBBbHBoYQo+IHVzYiA0LTI6IE1hbnVm YWN0dXJlcjogQ3JlYXRpdmUgVGVjaG5vbG9neSBMdGQKPiB1c2IgNC0yOiBTZXJpYWxOdW1iZXI6 IDAwMDIzMTYyCj4gaW5wdXQ6IENyZWF0aXZlIFRlY2hub2xvZ3kgTHRkIFNvdW5kIEJsYXN0ZXIg VGFjdGljKDNEKSBBbHBoYSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMC91c2I0 LzQtMi80LTI6MS4zL2lucHV0L2lucHV0Mwo+IGdlbmVyaWMtdXNiIDAwMDM6MDQxRTozMERDLjAw MDE6IGlucHV0LGhpZGRldjA6IFVTQiBISUQgdjEuMDAgRGV2aWNlIFtDcmVhdGl2ZSBUZWNobm9s b2d5IEx0ZCBTb3VuZCBCbGFzdGVyIFRhY3RpYygzRCkgQWxwaGFdIG9uIHVzYi0wMDAwOjAwOjEy LjAtMi9pbnB1dDMKPiB1c2IgMS0xLjE6IG5ldyBmdWxsLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVy IDQgdXNpbmcgZWhjaV9oY2QKPiBCZWdpbjogTG9hZGluZyBlc3NlbnRpYWwgZHJpdmVycyAuLi4g ZG9uZS4KPiBCZWdpbjogUnVubmluZyAvc2NyaXB0cy9pbml0LXByZW1vdW50IC4uLiBkb25lLgo+ IEJlZ2luOiBNb3VudGluZyByb290IGZpbGUgc3lzdGVtIC4uLiBCZWdpbjogUnVubmluZyAvc2Ny aXB0cy9sb2NhbC10b3AgLi4uIHVzYiAxLTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu ZG9yPTE1MzIsIGlkUHJvZHVjdD0wMDEzCj4gdXNiIDEtMS4xOiBOZXcgVVNCIGRldmljZSBzdHJp bmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MAo+IHVzYiAxLTEuMTogUHJvZHVj dDogUmF6ZXIgT3JvY2hpCj4gdXNiIDEtMS4xOiBNYW51ZmFjdHVyZXI6IFJhemVyCj4gaW5wdXQ6 IFJhemVyIFJhemVyIE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91 c2IxLzEtMS8xLTEuMS8xLTEuMToxLjAvaW5wdXQvaW5wdXQ0Cj4gZ2VuZXJpYy11c2IgMDAwMzox NTMyOjAwMTMuMDAwMjogaW5wdXQ6IFVTQiBISUQgdjEuMTEgTW91c2UgW1JhemVyIFJhemVyIE9y b2NoaV0gb24gdXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5wdXQwCj4gaW5wdXQ6IFJhemVyIFJhemVy IE9yb2NoaSBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEu MS8xLTEuMToxLjEvaW5wdXQvaW5wdXQ1Cj4gZ2VuZXJpYy11c2IgMDAwMzoxNTMyOjAwMTMuMDAw MzogaW5wdXQ6IFVTQiBISUQgdjEuMTEgS2V5Ym9hcmQgW1JhemVyIFJhemVyIE9yb2NoaV0gb24g dXNiLTAwMDA6MDA6MTIuMi0xLjEvaW5wdXQxCj4gZG9uZS4KPiBCZWdpbjogUnVubmluZyAvc2Ny aXB0cy9sb2NhbC1wcmVtb3VudCAuLi4gZG9uZS4KPiB1c2IgMS0xLjI6IG5ldyBsb3ctc3BlZWQg VVNCIGRldmljZSBudW1iZXIgNSB1c2luZyBlaGNpX2hjZAo+IEVYVDQtZnMgKGRtLTApOiBtb3Vu dGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpCj4gQmVn aW46IFJ1bm5pbmcgL3NjcmlwdHMvbG9jYWwtYm90dG9tIC4uLiBkb25lLgo+IGRvbmUuCj4gQmVn aW46IFJ1bm5pbmcgL3NjcmlwdHMvaW5pdC1ib3R0b20gLi4uIGRvbmUuCj4gdXNiIDEtMS4yOiBO ZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDRmMiwgaWRQcm9kdWN0PTA0MDMKPiB1c2Ig MS0xLjI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51 bWJlcj0wCj4gdXNiIDEtMS4yOiBQcm9kdWN0OiBVU0IgS2V5Ym9hcmQKPiB1c2IgMS0xLjI6IE1h bnVmYWN0dXJlcjogQ2hpY29ueQo+IGlucHV0OiBDaGljb255IFVTQiBLZXlib2FyZCBhcyAvZGV2 aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2IxLzEtMS8xLTEuMi8xLTEuMjoxLjAvaW5w dXQvaW5wdXQ2Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYyOjA0MDMuMDAwNDogaW5wdXQ6IFVTQiBI SUQgdjEuMTEgS2V5Ym9hcmQgW0NoaWNvbnkgVVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDox Mi4yLTEuMi9pbnB1dDAKPiBJTklUOiB2ZXJzaW9uIDIuODggYm9vdGluZwo+IGlucHV0OiBDaGlj b255IFVTQiBLZXlib2FyZCBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTIuMi91c2Ix LzEtMS8xLTEuMi8xLTEuMjoxLjEvaW5wdXQvaW5wdXQ3Cj4gZ2VuZXJpYy11c2IgMDAwMzowNEYy OjA0MDMuMDAwNTogaW5wdXQsaGlkZGV2MDogVVNCIEhJRCB2MS4xMSBEZXZpY2UgW0NoaWNvbnkg VVNCIEtleWJvYXJkXSBvbiB1c2ItMDAwMDowMDoxMi4yLTEuMi9pbnB1dDEKPiBVc2luZyBtYWtl ZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgUy5uZXQgZmlyZXdpcmUwOiBJ Cj4gUHY0IG92ZXIgSUVFRSAxMzk0IG9uIGNhcmQgMDAwMDowNTowMC4wCj4gZmlyZXdpcmVfY29y ZSAwMDAwOjA1OjAwLjA6IHJlZnJlc2hlZCBkZXZpY2UgZncwCj4gRmlsZXMgdW5kZXIgbW91bnQg cG9pbnQgJy9saWIvaW5pdC9ydycgd2lsbCBiZSBoaWRkZW4uIC4uLiAod2FybmluZykuCj4gRmls ZXMgdW5kZXIgbW91bnQgcG9pbnQgJy92YXIvcnVuJyB3aWxsIGJlIGhpZGRlbi4gLi4uICh3YXJu aW5nKS4KPiBGaWxlcyB1bmRlciBtb3VudCBwb2ludCAnL3Zhci9sb2NrJyB3aWxsIGJlIGhpZGRl bi4gLi4uICh3YXJuaW5nKS4KPiBTdGFydGluZyB0aGUgaG90cGx1ZyBldmVudHMgZGlzcGF0Y2hl cjogdWRldmR1ZGV2WzEzMDJdOiBzdGFydGluZyB2ZXJzaW9uIDE2NAo+IC4KPiBTeW50aGVzaXpp bmcgdGhlIGluaXRpYWwgaG90cGx1ZyBldmVudHMuLi5kb25lLgo+IFdhaXRpbmcgZm9yIC9kZXYg dG8gYmUgZnVsbHkgcG9wdWxhdGVkLi4uZG9uZS4KPiBTZXR0aW5nIGhvc3RuYW1lIHRvICd4ZW4n Li4uZG9uZS4KPiBTZXR0aW5nIHByZWxpbWluYXJ5IGtleW1hcC4uLmRvbmUuCj4gQWN0aXZhdGlu ZyBzd2FwOi4KPiBFWFQ0LWZzIChkbS0wKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpCj4gV2ls bCBub3cgY2hlY2sgcm9vdCBmaWxlIHN5c3RlbTpmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3 LjIKPiBbL3NiaW4vZnNjay5leHQ0ICgxKSAtLSAvXSBmc2NrLmV4dDQgLWEgLUMwIC9kZXYvbWFw cGVyL2xlbXJvdWNoLXhlbiAKPiAvZGV2L21hcHBlci9sZW1yb3VjaC14ZW46IGNsZWFuLCAxNzY2 MTcvMTMxMDcyMCBmaWxlcywgMTI4MDU2Mi81MjQyODgwIGJsb2Nrcwo+IC4KPiBFWFQ0LWZzIChk bS0wKTogcmUtbW91bnRlZC4gT3B0czogZXJyb3JzPXJlbW91bnQtcm8KPiBMb2FkaW5nIGtlcm5l bCBtb2R1bGUgZmlyZXdpcmUtc2JwMi4KPiBMb2FkaW5nIGtlcm5lbCBtb2R1bGUgbG9vcC4KPiBD bGVhbmluZyB1cCBpZnVwZG93bi4uLi4KPiBTZXR0aW5nIHVwIG5ldHdvcmtpbmcuLi4uCj4gU2V0 dGluZyB1cCBMVk0gVm9sdW1lIEdyb3VwcyAgUmVhZGluZyBhbGwgcGh5c2ljYWwgdm9sdW1lcy4g IFRoaXMgbWF5IHRha2UgYSB3aGlsZS4uLgo+ICAgRm91bmQgdm9sdW1lIGdyb3VwICJsZW1yb3Vj aCIgdXNpbmcgbWV0YWRhdGEgdHlwZSBsdm0yCj4gICA0IGxvZ2ljYWwgdm9sdW1lKHMpIGluIHZv bHVtZSBncm91cCAibGVtcm91Y2giIG5vdyBhY3RpdmUKPiAuCj4gV2lsbCBub3cgYWN0aXZhdGUg bHZtIGFuZCBtZCBzd2FwOmRvbmUuCj4gV2lsbCBub3cgY2hlY2sgYWxsIGZpbGUgc3lzdGVtcy4K PiBmc2NrIGZyb20gdXRpbC1saW51eC1uZyAyLjE3LjIKPiBDaGVja2luZyBhbGwgZmlsZSBzeXN0 ZW1zLgo+IERvbmUgY2hlY2tpbmcgZmlsZSBzeXN0ZW1zLiBBIGxvZyBpcyBiZWluZyBzYXZlZCBp biAvdmFyL2xvZy9mc2NrL2NoZWNrZnMgaWYgdGhhdCBsb2NhdGlvbiBpcyB3cml0YWJsZS4uCj4g V2lsbCBub3cgbW91bnQgbG9jYWwgZmlsZXN5c3RlbXM6RVhUNC1mcyAoc2RhMSk6IHdhcm5pbmc6 IG1vdW50aW5nIHVuY2hlY2tlZCBmcywgcnVubmluZyBlMmZzY2sgaXMgcmVjb21tZW5kZWQKPiBF WFQ0LWZzIChzZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUu IE9wdHM6IChudWxsKQo+IC4KPiBXaWxsIG5vdyBhY3RpdmF0ZSBzd2FwZmlsZSBzd2FwOmRvbmUu Cj4gQ2xlYW5pbmcgdXAgdGVtcG9yYXJ5IGZpbGVzLi4uQ2xlYW5pbmcgL3RtcC4uLmRvbmUuCj4g Lgo+IENoZWNraW5nIG1pbmltdW0gc3BhY2UgaW4gL3RtcC4uLmRvbmUuCj4gU2V0dGluZyBrZXJu ZWwgdmFyaWFibGVzIC4uLiAvZXRjL3N5c2N0bC5jb25mLi4uZG9uZS4KPiBJbml0aWFsaXppbmcg cmFuZG9tIG51bWJlciBnZW5lcmF0b3IuLi5kb25lLgo+IFNldHRpbmcgdXAgWCBzZXJ2ZXIgc29j a2V0IGRpcmVjdG9yeSAvdG1wLy5YMTEtdW5peC4uLi4KPiBTZXR0aW5nIHVwIElDRSBzb2NrZXQg ZGlyZWN0b3J5IC90bXAvLklDRS11bml4Li4uLgo+IENvbmZpZ3VyaW5nIG5ldHdvcmsgaW50ZXJm YWNlcy4uLmRldmljZSBldGgwIGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZQo+IHNreTIgMDAwMDow NDowMC4wOiBldGgwOiBlbmFibGluZyBpbnRlcmZhY2UKPiBkb25lLgo+IENsZWFuaW5nIHVwIHRl bXBvcmFyeSBmaWxlcy4uLi4KPiBTdGFydGluZyBmaWxlc3lzdGVtIGluIHVzZXJzcGFjZTogZnVz ZS4KPiBTZXR0aW5nIGNvbnNvbGUgc2NyZWVuIG1vZGVzLgo+IGNhbm5vdCAodW4pc2V0IHBvd2Vy c2F2ZSBtb2RlCj4gU2tpcHBpbmcgZm9udCBhbmQga2V5bWFwIHNldHVwIChoYW5kbGVkIGJ5IGNv bnNvbGUtc2V0dXApLgo+IFNldHRpbmcgdXAgY29uc29sZSBmb250IGFuZCBrZXltYXAuLi5kb25l Lgo+IFNldHRpbmcgc2Vuc29ycyBsaW1pdHMuCj4gSU5JVDogRW50ZXJpbmcgcnVubGV2ZWw6IDMK PiBVc2luZyBtYWtlZmlsZS1zdHlsZSBjb25jdXJyZW50IGJvb3QgaW4gcnVubGV2ZWwgMy4KPiBO b3Qgc3RhcnRpbmcgZmFuY29udHJvbDsgcnVuIHB3bWNvbmZpZyBmaXJzdC4gLi4uICh3YXJuaW5n KS4KPiBhY3BpZDogc3RhcnRpbmcgdXAgd2l0aCBuZXRsaW5rIGFuZCB0aGUgaW5wdXQgbGF5ZXIK PiAKPiBhY3BpZDogMSBydWxlIGxvYWRlZAo+IAo+IGFjcGlkOiB3YWl0aW5nIGZvciBldmVudHM6 IGV2ZW50IGxvZ2dpbmcgaXMgb2ZmCj4gCj4gU3RhcnRpbmcgQUNQSSBzZXJ2aWNlcy4uLi4KPiBT dGFydGluZyBzeXN0ZW0gbWVzc2FnZSBidXM6IGRidXMuCj4gc3NoZCAoMjA4NCk6IC9wcm9jLzIw ODQvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzIwODQvb29tX3Njb3Jl X2FkaiBpbnN0ZWFkLgo+IFN0YXJ0aW5nIHRoZSBXaW5iaW5kIGRhZW1vbjogd2luYmluZC4KPiBT dGFydGluZyBPcGVuQlNEIFNlY3VyZSBTaGVsbCBzZXJ2ZXI6IHNzaGQuCj4gU3RhcnRpbmcgZG9t YWluIG5hbWUgc2VydmljZS4uLjogYmluZDkuCj4gU3RhcnRpbmcgb3hlbnN0b3JlZC4uLgo+IFNl dHRpbmcgZG9tYWluIDAgbmFtZS4uLgo+IFN0YXJ0aW5nIHhlbmNvbnNvbGVkLi4uCj4gU3RhcnRp bmcgU2FtYmEgZGFlbW9uczogbm1iZCBzbWJkLgo+IFN0YXJ0aW5nIHBlcmlvZGljIGNvbW1hbmQg c2NoZWR1bGVyOiBjcm9uLgo+IFN0YXJ0aW5nIFBvc3RmaXggTWFpbCBUcmFuc3BvcnQgQWdlbnQ6 IHBvc3RmaXguCj4gQkxLVEFQQ1RSTFsyMjUzXTogYmxrdGFwY3RybC5jOjc5MjogYmxrdGFwY3Ry bDogdjEuMC4wCj4gCj4gQkxLVEFQQ1RSTFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQg ZHJpdmVyOiBbcmF3IGltYWdlIChhaW8pXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0 cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3JhdyBpbWFnZSAoc3luYyldCj4gCj4gQkxLVEFQQ1RS TFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbdm13YXJlIGltYWdlICh2 bWRrKV0KPiAKPiBCTEtUQVBDVFJMWzIyNTNdOiBibGt0YXBjdHJsLmM6Nzk0OiBGb3VuZCBkcml2 ZXI6IFtyYW1kaXNrIGltYWdlIChyYW0pXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0 cmwuYzo3OTQ6IEZvdW5kIGRyaXZlcjogW3Fjb3cgZGlzayAocWNvdyldCj4gCj4gQkxLVEFQQ1RS TFsyMjUzXTogYmxrdGFwY3RybC5jOjc5NDogRm91bmQgZHJpdmVyOiBbcWNvdzIgZGlzayAocWNv dzIpXQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0cmxfbGludXguYzo4NjogYmxrdGFw MCBvcGVuIGZhaWxlZAo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3RhcGN0cmwuYzo4NjE6IGNv dWxkbid0IG9wZW4gYmxrdGFwIGludGVyZmFjZQo+IAo+IEJMS1RBUENUUkxbMjI1M106IGJsa3Rh cGN0cmwuYzo5MjQ6IFVuYWJsZSB0byBzdGFydCBibGt0YXBjdHJsCj4gCj4gc2t5MiAwMDAwOjA0 OjAwLjA6IGV0aDA6IExpbmsgaXMgdXAgYXQgMTAwIE1icHMsIGZ1bGwgZHVwbGV4LCBmbG93IGNv bnRyb2wgYm90aAo+IGJyMDogcG9ydCAxKGV0aDApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+ IGJyMDogcG9ydCAxKGV0aDApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQo+IFN0YXJ0aW5nIFMu TS5BLlIuVC4gZGFlbW9uOiBzbWFydGQuCj4gYnIwOiBwb3J0IDEoZXRoMCkgZW50ZXJlZCBmb3J3 YXJkaW5nIHN0YXRlCj4gUnVubmluZyBsb2NhbCBib290IHNjcmlwdHMgKC9ldGMvcmMubG9jYWwp KFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMi4yCj4gYWNwaWQ6IGlucHV0IGRldmlj ZSBoYXMgYmVlbiBkaXNjb25uZWN0ZWQKPiAKPiBhY3BpZDogaW5wdXQgZGV2aWNlIGhhcyBiZWVu IGRpc2Nvbm5lY3RlZAo+IAo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4gZGlzY29ubmVj dGVkCj4gCj4gKFhFTikgUENJIHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJ IHJlbW92ZSBkZXZpY2UgMDAwMDowMDoxNi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDow MDoxMi4yCj4gKFhFTikgUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yCj4gKFhFTikgUENJIGFk ZCBkZXZpY2UgMDAwMDowMDoxNi4yCj4gLgo+IGFjcGlkOiBpbnB1dCBkZXZpY2UgaGFzIGJlZW4g ZGlzY29ubmVjdGVkCj4gCj4gYWNwaWQ6IGlucHV0IGRldmljZSBoYXMgYmVlbiBkaXNjb25uZWN0 ZWQKPiAKPiAoWEVOKSBpb3BvcnRfbWFwOmFkZDogZG9tMSBncG9ydD0zYjAgbXBvcnQ9M2IwIG5y PWMKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49YTAgbWZuPWEwIG5yPTIwCj4gKFhF TikgaW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2MwIG1wb3J0PTNjMCBucj0zCj4gKFhFTikg aW9wb3J0X21hcDphZGQ6IGRvbTEgZ3BvcnQ9M2M0IG1wb3J0PTNjNCBucj0xYwo+IChYRU4pIEhW TTE6IEhWTSBMb2FkZXIKPiAoWEVOKSBIVk0xOiBEZXRlY3RlZCBYZW4gdjQuMi11bnN0YWJsZQo+ IChYRU4pIEhWTTE6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA4Cj4g KFhFTikgSFZNMTogU3lzdGVtIHJlcXVlc3RlZCBST01CSU9TCj4gKFhFTikgSFZNMTogQ1BVIHNw ZWVkIGlzIDMwMTAgTUh6Cj4gKFhFTikgaXJxLmM6MjcwOiBEb20xIFBDSSBsaW5rIDAgY2hhbmdl ZCAwIC0+IDUKPiAoWEVOKSBIVk0xOiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJRNQo+IChY RU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMAo+IChYRU4pIEhW TTE6IFBDSS1JU0EgbGluayAxIHJvdXRlZCB0byBJUlExMAo+IChYRU4pIGlycS5jOjI3MDogRG9t MSBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQo+IChYRU4pIEhWTTE6IFBDSS1JU0EgbGluayAy IHJvdXRlZCB0byBJUlExMQo+IChYRU4pIGlycS5jOjI3MDogRG9tMSBQQ0kgbGluayAzIGNoYW5n ZWQgMCAtPiA1Cj4gKFhFTikgSFZNMTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUKPiAo WEVOKSBIVk0xOiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2 IDAzOjAgSU5UQS0+SVJRNQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBJTlRBLT5JUlE1Cj4g KFhFTikgSFZNMTogcGNpIGRldiAwNTowIElOVEEtPklSUTEwCj4gKFhFTikgSFZNMTogcGNpIGRl diAwNjowIElOVEItPklSUTUKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA3OjAgSU5UQS0+SVJRNQo+ IChYRU4pIEhWTTE6IHBjaSBkZXYgMDg6MCBJTlRCLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBk ZXYgMDk6MCBJTlRBLT5JUlExMAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMTAgc2l6 ZSAxMDAwMDAwMDogZTAwMDAwMGMKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZTAw MDAgbWZuPWQwMDAwIG5yPTEwMDAwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxNCBz aXplIDAxMDAwMDAwOiBmMDAwMDAwOAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDQ6MCBiYXIgMTAg c2l6ZSAwMDAyMDAwMDogZjEwMDAwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49 ZjEwMjAgbWZuPWZlOWUwIG5yPTIwCj4gKFhFTikgSFZNMTogcGNpIGRldiAwNTowIGJhciAxOCBz aXplIDAwMDIwMDAwOiBmMTAyMDAwNAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMzAg c2l6ZSAwMDAyMDAwMDogZjEwNDAwMDAKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA2OjAgYmFyIDEw IHNpemUgMDAwMDQwMDA6IGYxMDYwMDA0Cj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2Zu PWYxMDYwIG1mbj1mZTliYyBucj00Cj4gKFhFTikgSFZNMTogcGNpIGRldiAwOTowIGJhciAxMCBz aXplIDAwMDA0MDAwOiBmMTA2NDAwNAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1m MTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDc6MCBiYXIgMTAgc2l6 ZSAwMDAwMTAwMDogZjEwNjgwMDAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDogZG9tMSBnZm49ZjEw NjggbWZuPWZlM2Y3IG5yPTEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUg MDAwMDEwMDA6IGYxMDY5MDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6IGRvbTEgZ2ZuPWYxMDY5 IG1mbj1mMDAwMCBucj0xCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIDAw MDAwMTAwOiAwMDAwYzAwMQo+IChYRU4pIEhWTTE6IHBjaSBkZXYgMDU6MCBiYXIgMjAgc2l6ZSAw MDAwMDEwMDogMDAwMGMxMDEKPiAoWEVOKSBIVk0xOiBwY2kgZGV2IDA0OjAgYmFyIDE0IHNpemUg MDAwMDAwNDA6IDAwMDBjMjAxCj4gKFhFTikgSFZNMTogcGNpIGRldiAwMToxIGJhciAyMCBzaXpl IDAwMDAwMDEwOiAwMDAwYzI0MQo+IChYRU4pIEhWTTE6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxp c2F0aW9uOgo+IChYRU4pIEhWTTE6ICAtIENQVTAgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBN VFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTEg Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBk b25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTIgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJS cyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTMgLi4u IDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25l Lgo+IChYRU4pIEhWTTE6ICAtIENQVTQgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAu Li4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+IChYRU4pIEhWTTE6ICAtIENQVTUgLi4uIDQ4 LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFszLzhdIC4uLiBkb25lLgo+ IChYRU4pIEhWTTE6IFRlc3RpbmcgSFZNIGVudmlyb25tZW50Ogo+IChYRU4pIEhWTTE6ICAtIFJF UCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZAo+IChYRU4pIEhWTTE6ICAt IEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4uLiBwYXNzZWQKPiAoWEVOKSBIVk0xOiBQYXNzZWQg MiBvZiAyIHRlc3RzCj4gKFhFTikgSFZNMTogV3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLgo+IChY RU4pIEhWTTE6IExvYWRpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiA5NjYwIGJ5dGVzIG9m IFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoKPiAoWEVOKSBIVk0xOiAgIFJlbG9jYXRp bmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJjIC4uLiBkb25lCj4gKFhFTikgSFZNMTogQ3JlYXRp bmcgTVAgdGFibGVzIC4uLgo+IChYRU4pIEhWTTE6IExvYWRpbmcgVkdBQklPUyBvZiBwYXNzdGhy b3VnaGVkIGdmeCAuLi4KPiAoWEVOKSBIVk0xOiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLgo+ IChYRU4pIEhWTTE6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnCj4gKFhFTikgSFZN MTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFCj4gKFhFTikgSFZNMTogT3B0aW9uIFJPTXM6Cj4gKFhF TikgSFZNMTogIGMwMDAwLWNmZmZmOiBWR0EgQklPUwo+IChYRU4pIEhWTTE6ICBkMDAwMC1lMGZm ZjogRXRoZXJib290IFJPTQo+IChYRU4pIEhWTTE6IExvYWRpbmcgQUNQSSAuLi4KPiAoWEVOKSBI Vk0xOiB2bTg2IFRTUyBhdCBmYzAwZjcwMAo+IChYRU4pIEhWTTE6IEJJT1MgbWFwOgo+IChYRU4p IEhWTTE6ICBmMDAwMC1mZmZmZjogTWFpbiBCSU9TCj4gKFhFTikgSFZNMTogRTgyMCB0YWJsZToK PiAoWEVOKSBIVk0xOiAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAw MDogUkFNCj4gKFhFTikgSFZNMTogIFswMV06IDAwMDAwMDAwOjAwMDllMDAwIC0gMDAwMDAwMDA6 MDAwYTAwMDA6IFJFU0VSVkVECj4gKFhFTikgSFZNMTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAw IC0gMDAwMDAwMDA6MDAwZTAwMDAKPiAoWEVOKSBIVk0xOiAgWzAyXTogMDAwMDAwMDA6MDAwZTAw MDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQKPiAoWEVOKSBIVk0xOiAgWzAzXTogMDAw MDAwMDA6MDAxMDAwMDAgLSAwMDAwMDAwMDplMDAwMDAwMDogUkFNCj4gKFhFTikgSFZNMTogIEhP TEU6IDAwMDAwMDAwOmUwMDAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDAKPiAoWEVOKSBIVk0xOiAg WzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQKPiAo WEVOKSBIVk0xOiAgWzA1XTogMDAwMDAwMDE6MDAwMDAwMDAgLSAwMDAwMDAwMToyMDAwMDAwMDog UkFNCj4gKFhFTikgSFZNMTogSW52b2tpbmcgUk9NQklPUyAuLi4KPiAoWEVOKSBIVk0xOiAkUmV2 aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6 IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkKPiAoWEVOKSBIVk0xOiAkUmV2aXNpb246IDEu MjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6MzI6MjkgJAo+IChYRU4pIEhWTTE6IE9wdGlvbnM6 IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0byBQTU0gCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZN MTogYXRhMC0wOiBQQ0hTPTE2MzgzLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1 LzYzCj4gKFhFTikgSFZNMTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1E aXNrICgyMDQ4MCBNQnl0ZXMpCj4gKFhFTikgSFZNMTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2LzYz IHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzCj4gKFhFTikgSFZNMTogYXRhMCAgc2xh dmU6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwMCBNQnl0ZXMpCj4gKFhFTikg SFZNMTogCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogUHJlc3Mg RjEyIGZvciBib290IG1lbnUuCj4gKFhFTikgSFZNMTogCj4gKFhFTikgSFZNMTogQm9vdGluZyBm cm9tIEhhcmQgRGlzay4uLgo+IChYRU4pIEhWTTE6IEJvb3RpbmcgZnJvbSAwMDAwOjdjMDAKPiAo WEVOKSBpcnEuYzoyNzA6IERvbTEgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMAo+IChYRU4pIGly cS5jOjI3MDogRG9tMSBQQ0kgbGluayAxIGNoYW5nZWQgMTAgLT4gMAo+IChYRU4pIGlycS5jOjI3 MDogRG9tMSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAo+IChYRU4pIGlycS5jOjI3MDogRG9t MSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwCj4gKFhFTikgbWVtb3J5X21hcDpyZW1vdmU6IGRv bTEgZ2ZuPWUwMDAwIG1mbj1kMDAwMCBucj0xMDAwMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3Zl OiBkb20xIGdmbj1mMTAyMCBtZm49ZmU5ZTAgbnI9MjAKPiAoWEVOKSBtZW1vcnlfbWFwOmFkZDog ZG9tMSBnZm49ZTAwMDAgbWZuPWQwMDAwIG5yPTEwMDAwCj4gKFhFTikgbWVtb3J5X21hcDphZGQ6 IGRvbTEgZ2ZuPWYxMDIwIG1mbj1mZTllMCBucj0yMAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3Zl OiBkb20xIGdmbj1mMTA2MCBtZm49ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBk b20xIGdmbj1mMTA2MCBtZm49ZmU5YmMgbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBk b20xIGdmbj1mMTA2OCBtZm49ZmUzZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20x IGdmbj1mMTA2OCBtZm49ZmUzZjcgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x IGdmbj1mMTA2OSBtZm49ZjAwMDAgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdm bj1mMTA2OSBtZm49ZjAwMDAgbnI9MQo+IChYRU4pIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xIGdm bj1mMTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIG1lbW9yeV9tYXA6YWRkOiBkb20xIGdmbj1m MTA2NCBtZm49ZmUzZjggbnI9NAo+IChYRU4pIGdyYW50X3RhYmxlLmM6MTE3NDpkMSBFeHBhbmRp bmcgZG9tICgxKSBncmFudCB0YWJsZSBmcm9tICg0KSB0byAoMzIpIGZyYW1lcy4KPiAoWEVOKSBp cnEuYzozNTA6IERvbTEgY2FsbGJhY2sgdmlhIGNoYW5nZWQgdG8gR1NJIDI4Cj4gKFhFTikgRG9t YWluIDAgY3Jhc2hlZDogcmVib290aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLgoKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWls aW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3Jn L3hlbi1kZXZlbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Mon May 07 17:39:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17: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 ) id 1SRRtx-00052G-LP; Mon, 07 May 2012 17:39:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRtw-00051x-Kf for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:39:12 +0000 Received: from [85.158.139.83:61286] by server-5.bemta-5.messagelabs.com id 75/F3-13566-FB808AF4; Mon, 07 May 2012 17:39:11 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336412349!24433203!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16561 invoked from network); 7 May 2012 17:39:10 -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; 7 May 2012 17:39:10 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47HcuOE005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:38:57 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 q47HctbB018864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:38:56 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 q47HctbQ028331; Mon, 7 May 2012 12:38:55 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:38:55 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E4B2B4031D; Mon, 7 May 2012 13:33:06 -0400 (EDT) Date: Mon, 7 May 2012 13:33:06 -0400 From: Konrad Rzeszutek Wilk To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Message-ID: <20120507173306.GC17704@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> <20120506152341.GX2058@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120506152341.GX2058@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 06:23:41PM +0300, Pasi K=E4rkk=E4inen wrote: > On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > > >> > > > >> This I would take as C3 and C6 really not being used and the frequ= ency scaling > > > > = > > > > To go in deeper modes there is also a need to backport a Xen unstab= le > > > > hypercall which will allow the kernel to detect the other states be= sides > > > > C0-C2. > > > > = > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > > "ACPI: add _PDC input override mechanism". > > > > = > > > = > > > I see. There is a kernel patch about enabling MWAIT that refers to th= at... > > = > > Yeah, I should see about back-porting it in Xen 4.1.. > > = > = > Should this patch be backported and merged to xen-4.1-testing.hg for Xen = 4.1.3 release ? = It is a new feature so no. Which does mean that the MWAIT states won't be u= ploaded to the hypervisor. But the legacy ones (so the ones that are in the ACPI _C= ST) are still uploaded. And TurboMode kicks in without the MWAIT states. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:39:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17: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 ) id 1SRRtx-00052G-LP; Mon, 07 May 2012 17:39:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRtw-00051x-Kf for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:39:12 +0000 Received: from [85.158.139.83:61286] by server-5.bemta-5.messagelabs.com id 75/F3-13566-FB808AF4; Mon, 07 May 2012 17:39:11 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336412349!24433203!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16561 invoked from network); 7 May 2012 17:39:10 -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; 7 May 2012 17:39:10 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47HcuOE005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 17:38:57 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 q47HctbB018864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 17:38:56 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 q47HctbQ028331; Mon, 7 May 2012 12:38:55 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 10:38:55 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E4B2B4031D; Mon, 7 May 2012 13:33:06 -0400 (EDT) Date: Mon, 7 May 2012 13:33:06 -0400 From: Konrad Rzeszutek Wilk To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Message-ID: <20120507173306.GC17704@phenom.dumpdata.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> <20120506152341.GX2058@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120506152341.GX2058@reaktio.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 06, 2012 at 06:23:41PM +0300, Pasi K=E4rkk=E4inen wrote: > On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > > >> > > > >> This I would take as C3 and C6 really not being used and the frequ= ency scaling > > > > = > > > > To go in deeper modes there is also a need to backport a Xen unstab= le > > > > hypercall which will allow the kernel to detect the other states be= sides > > > > C0-C2. > > > > = > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > > "ACPI: add _PDC input override mechanism". > > > > = > > > = > > > I see. There is a kernel patch about enabling MWAIT that refers to th= at... > > = > > Yeah, I should see about back-porting it in Xen 4.1.. > > = > = > Should this patch be backported and merged to xen-4.1-testing.hg for Xen = 4.1.3 release ? = It is a new feature so no. Which does mean that the MWAIT states won't be u= ploaded to the hypervisor. But the legacy ones (so the ones that are in the ACPI _C= ST) are still uploaded. And TurboMode kicks in without the MWAIT states. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:44:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:44:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRz2-0005M4-EU; Mon, 07 May 2012 17:44:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRz1-0005Ly-1O for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:44:27 +0000 Received: from [85.158.143.35:61472] by server-1.bemta-4.messagelabs.com id D3/75-20925-AF908AF4; Mon, 07 May 2012 17:44:26 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-21.messagelabs.com!1336412665!11202388!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzgyMTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25266 invoked from network); 7 May 2012 17:44:25 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:44:25 -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 02B7828B2; Mon, 7 May 2012 20:44:23 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A7BB4EC027; Mon, 7 May 2012 20:44:23 +0300 (EEST) Date: Mon, 7 May 2012 20:44:23 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120507174423.GY2058@reaktio.net> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> <20120506152341.GX2058@reaktio.net> <20120507173306.GC17704@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120507173306.GC17704@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 01:33:06PM -0400, Konrad Rzeszutek Wilk wrote: > On Sun, May 06, 2012 at 06:23:41PM +0300, Pasi K=E4rkk=E4inen wrote: > > On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > > > >> > > > > >> This I would take as C3 and C6 really not being used and the fre= quency scaling > > > > > = > > > > > To go in deeper modes there is also a need to backport a Xen unst= able > > > > > hypercall which will allow the kernel to detect the other states = besides > > > > > C0-C2. > > > > > = > > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > > > "ACPI: add _PDC input override mechanism". > > > > > = > > > > = > > > > I see. There is a kernel patch about enabling MWAIT that refers to = that... > > > = > > > Yeah, I should see about back-porting it in Xen 4.1.. > > > = > > = > > Should this patch be backported and merged to xen-4.1-testing.hg for Xe= n 4.1.3 release ? = > = > It is a new feature so no. Which does mean that the MWAIT states won't be= uploaded > to the hypervisor. But the legacy ones (so the ones that are in the ACPI = _CST) > are still uploaded. And TurboMode kicks in without the MWAIT states. > = Ah, thanks for clearing that up. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 17:44:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 17:44:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRz2-0005M4-EU; Mon, 07 May 2012 17:44:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRRz1-0005Ly-1O for xen-devel@lists.xensource.com; Mon, 07 May 2012 17:44:27 +0000 Received: from [85.158.143.35:61472] by server-1.bemta-4.messagelabs.com id D3/75-20925-AF908AF4; Mon, 07 May 2012 17:44:26 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-21.messagelabs.com!1336412665!11202388!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MzgyMTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25266 invoked from network); 7 May 2012 17:44:25 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 17:44:25 -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 02B7828B2; Mon, 7 May 2012 20:44:23 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A7BB4EC027; Mon, 7 May 2012 20:44:23 +0300 (EEST) Date: Mon, 7 May 2012 20:44:23 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120507174423.GY2058@reaktio.net> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120426170426.GI26830@phenom.dumpdata.com> <20120506152341.GX2058@reaktio.net> <20120507173306.GC17704@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120507173306.GC17704@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" , Stefan Bader , Jan Beulich Subject: Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 01:33:06PM -0400, Konrad Rzeszutek Wilk wrote: > On Sun, May 06, 2012 at 06:23:41PM +0300, Pasi K=E4rkk=E4inen wrote: > > On Thu, Apr 26, 2012 at 01:04:26PM -0400, Konrad Rzeszutek Wilk wrote: > > > > >> > > > > >> This I would take as C3 and C6 really not being used and the fre= quency scaling > > > > > = > > > > > To go in deeper modes there is also a need to backport a Xen unst= able > > > > > hypercall which will allow the kernel to detect the other states = besides > > > > > C0-C2. > > > > > = > > > > > "XEN_SET_PDC query was implemented in c/s 23783: > > > > > "ACPI: add _PDC input override mechanism". > > > > > = > > > > = > > > > I see. There is a kernel patch about enabling MWAIT that refers to = that... > > > = > > > Yeah, I should see about back-porting it in Xen 4.1.. > > > = > > = > > Should this patch be backported and merged to xen-4.1-testing.hg for Xe= n 4.1.3 release ? = > = > It is a new feature so no. Which does mean that the MWAIT states won't be= uploaded > to the hypervisor. But the legacy ones (so the ones that are in the ACPI = _CST) > are still uploaded. And TurboMode kicks in without the MWAIT states. > = Ah, thanks for clearing that up. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 18:29:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18: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 ) id 1SRSgW-0006Lp-RA; Mon, 07 May 2012 18:29:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSgU-0006Lh-Fv for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:29:23 +0000 Received: from [85.158.139.83:24311] by server-12.bemta-5.messagelabs.com id 22/98-01344-18418AF4; Mon, 07 May 2012 18:29:21 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336415358!26609862!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31414 invoked from network); 7 May 2012 18:29:19 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 18:29:19 -0000 Received: by qadb33 with SMTP id b33so2864802qad.9 for ; Mon, 07 May 2012 11:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lcb+zN2nLYpTZSW0WvPz8z6KZp4LglzWQ/3fTgrfJos=; b=qg3QFPiChICVNO0YigUPpak+2MSYfcRkY4H8xZOF9YA9BKBEi7xqDW92p6GK6CKkBb ykf4t2/0IuTnsyH+K3cga0p879S8UlCfk6duUQ6RERnYaO9TAE4EejUy00rZHJdW4cs/ 7knozKQDJJSkILwh1BWI7P27JCYAlrRMSlu4+YyNqM8WT1wgbBJwHkL1OPPx9T+/TqvT CvjhGh2rVIccJQdBJ4WPAPps543DyYv5lVCi7H/CVARxvj90Ztwa26eLjq/mT9tAR6tO tOSFpAG/qu2ipPj1+v7EqCoJ4N7vrgMkEagW0L+mAV4WtBAm87oHyDtFZp/6u6Cm8NiY dmSA== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr20320468qao.23.1336415357889; Mon, 07 May 2012 11:29:17 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 11:29:17 -0700 (PDT) In-Reply-To: <4FA7EB80020000780008204B@nat28.tlf.novell.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> Date: Mon, 7 May 2012 18:29:17 +0000 Message-ID: From: AP To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Andrew Cooper , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8154351702464538460==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8154351702464538460== Content-Type: multipart/alternative; boundary=20cf3074b41aadec7b04bf7672ab --20cf3074b41aadec7b04bf7672ab Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 1:34 PM, Jan Beulich wrote: > > >>> On 07.05.12 at 13:50, Andrew Cooper wrote: > > On 07/05/2012 09:10, Jan Beulich wrote: > >>>>> On 05.05.12 at 02:21, AP wrote: > >>> (XEN) *** IRQ BUG found *** > >>> (XEN) CPU0 -Testing vector 236 from bitmap > >> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming > >> in through the 8259A. Something fundamentally fishy must be going > >> on here, and I would suppose the code in question shouldn't even be > >> reached for legacy vectors. > >> > >> Furthermore, calling dump_irqs() from the debugging code with > >> desc->lock still held makes it impossible to get full output, as that > >> function wants to lock all initialized IRQ descriptors. > > > > Yes - it has been vector 236 on each of the 3 reported failures from AP, > > and I believe it was also vector 236 in the one case I managed to > > reproduce the issue. > > > > However, once we have set up the IO-APIC, the 8259A should not be used > > any more. The boot dmeg shows that io_ack_method is indeed "old" (which > > was going to be my first suggestion), and that EOI Broadcast Suppression > > is enabled, which I have already identified as a source of problems for > > some customers. As a 'fix', I provided the ability for > > "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. > > This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not > > completely fixed the customer problems - just made it substantially more > > rare. > > > > AP: Can you manually invoke the 'i' debug key and provide that - it will > > help to see how Xen is setting up the IO-APIC(s) on your system. (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 mapped, unbound (XEN) IRQ: 1 affinity:02 vec:85 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 1(----), (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 mapped, unbound (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 8(----), (XEN) IRQ: 9 affinity:02 vec:7f type=IO-APIC-level status=00000010 in-flight=0 domain-list=0: 9(----), (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 12 affinity:08 vec:d4 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 12(----), (XEN) IRQ: 13 affinity:0f vec:98 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 14 affinity:01 vec:a0 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 15 affinity:01 vec:a8 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 16 affinity:02 vec:a6 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 16(----), (XEN) IRQ: 17 affinity:0f vec:c0 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 18 affinity:0f vec:c8 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 19 affinity:0f vec:f1 type=IO-APIC-level status=00000000 mapped, unbound (XEN) IRQ: 20 affinity:0f vec:61 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 22 affinity:0f vec:32 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 23 affinity:01 vec:ac type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 23(----), (XEN) IRQ: 24 affinity:01 vec:28 type=DMA_MSI status=00000000 mapped, unbound (XEN) IRQ: 25 affinity:01 vec:30 type=DMA_MSI status=00000000 mapped, unbound (XEN) IRQ: 26 affinity:01 vec:31 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:279(----), (XEN) IRQ: 27 affinity:01 vec:39 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:278(----), (XEN) IRQ: 28 affinity:01 vec:41 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:277(----), (XEN) IRQ: 29 affinity:01 vec:49 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:276(----), (XEN) IRQ: 30 affinity:01 vec:51 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:275(----), (XEN) IRQ: 31 affinity:04 vec:d7 type=PCI-MSI status=00000030 in-flight=0 domain-list=0:274(----), (XEN) IRQ: 32 affinity:04 vec:df type=PCI-MSI status=00000030 in-flight=0 domain-list=0:273(----), (XEN) IRQ: 33 affinity:02 vec:b0 type=PCI-MSI status=00000010 in-flight=0 domain-list=0:272(----), (XEN) IRQ: 34 affinity:02 vec:a8 type=PCI-MSI status=00000010 in-flight=0 domain-list=0:271(----), (XEN) IRQ: 35 affinity:04 vec:ad type=PCI-MSI status=00000030 in-flight=0 domain-list=0:270(----), (XEN) IO-APIC interrupt information: (XEN) IRQ 0 Vec240: (XEN) Apic 0x00, Pin 2: vec=f0 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 1 Vec133: (XEN) Apic 0x00, Pin 1: vec=85 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 3 Vec 64: (XEN) Apic 0x00, Pin 3: vec=40 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 4 Vec 72: (XEN) Apic 0x00, Pin 4: vec=48 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 5 Vec 80: (XEN) Apic 0x00, Pin 5: vec=50 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 6 Vec 88: (XEN) Apic 0x00, Pin 6: vec=58 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 7 Vec 96: (XEN) Apic 0x00, Pin 7: vec=60 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 8 Vec 41: (XEN) Apic 0x00, Pin 8: vec=29 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 9 Vec127: (XEN) Apic 0x00, Pin 9: vec=7f delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 10 Vec120: (XEN) Apic 0x00, Pin 10: vec=78 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 11 Vec136: (XEN) Apic 0x00, Pin 11: vec=88 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 12 Vec212: (XEN) Apic 0x00, Pin 12: vec=d4 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 13 Vec152: (XEN) Apic 0x00, Pin 13: vec=98 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=1 dest_id:0 (XEN) IRQ 14 Vec160: (XEN) Apic 0x00, Pin 14: vec=a0 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 15 Vec168: (XEN) Apic 0x00, Pin 15: vec=a8 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 16 Vec166: (XEN) Apic 0x00, Pin 16: vec=a6 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 17 Vec192: (XEN) Apic 0x00, Pin 17: vec=c0 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 18 Vec200: (XEN) Apic 0x00, Pin 18: vec=c8 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 19 Vec241: (XEN) Apic 0x00, Pin 19: vec=f1 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 20 Vec 97: (XEN) Apic 0x00, Pin 20: vec=61 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 22 Vec 50: (XEN) Apic 0x00, Pin 22: vec=32 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 23 Vec172: (XEN) Apic 0x00, Pin 23: vec=ac delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 > Seeing the 'z' output might also be helpful, especially to see whether > any of the IO-APICs' RTEs is an ExtINT one. (XEN) number of MP IRQ sources: 15. (XEN) number of IO-APIC #2 registers: 24. (XEN) testing the IO APIC....................... (XEN) IO APIC #2...... (XEN) .... register #00: 02000000 (XEN) ....... : physical APIC id: 02 (XEN) ....... : Delivery Type: 0 (XEN) ....... : LTS : 0 (XEN) .... register #01: 00170020 (XEN) ....... : max redirection entries: 0017 (XEN) ....... : PRQ implemented: 0 (XEN) ....... : IO APIC version: 0020 (XEN) .... IRQ redirection table: (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: (XEN) 00 000 00 1 0 0 0 0 0 0 00 (XEN) 01 000 00 0 0 0 0 0 1 1 85 (XEN) 02 000 00 0 0 0 0 0 1 1 F0 (XEN) 03 000 00 0 0 0 0 0 1 1 40 (XEN) 04 000 00 0 0 0 0 0 1 1 48 (XEN) 05 000 00 0 0 0 0 0 1 1 50 (XEN) 06 000 00 0 0 0 0 0 1 1 58 (XEN) 07 000 00 0 0 0 0 0 1 1 60 (XEN) 08 000 00 0 0 0 0 0 1 1 29 (XEN) 09 000 00 0 1 0 0 0 1 1 A7 (XEN) 0a 000 00 0 0 0 0 0 1 1 78 (XEN) 0b 000 00 0 0 0 0 0 1 1 88 (XEN) 0c 000 00 0 0 0 0 0 1 1 D4 (XEN) 0d 000 00 1 0 0 0 0 1 1 98 (XEN) 0e 000 00 0 0 0 0 0 1 1 A0 (XEN) 0f 000 00 0 0 0 0 0 1 1 A8 (XEN) 10 000 00 0 1 0 1 0 1 1 AE (XEN) 11 000 00 1 1 0 1 0 1 1 C0 (XEN) 12 000 00 1 1 0 1 0 1 1 C8 (XEN) 13 000 00 0 1 0 1 0 1 1 F1 (XEN) 14 000 00 1 1 0 1 0 1 1 61 (XEN) 15 0CA 0A 1 0 0 0 0 1 2 71 (XEN) 16 000 00 1 1 0 1 0 1 1 32 (XEN) 17 000 00 0 1 0 1 0 1 1 AC (XEN) Using vector-based indexing (XEN) IRQ to pin mappings: (XEN) IRQ240 -> 0:2 (XEN) IRQ133 -> 0:1 (XEN) IRQ64 -> 0:3 (XEN) IRQ72 -> 0:4 (XEN) IRQ80 -> 0:5 (XEN) IRQ88 -> 0:6 (XEN) IRQ96 -> 0:7 (XEN) IRQ41 -> 0:8 (XEN) IRQ167 -> 0:9 (XEN) IRQ120 -> 0:10 (XEN) IRQ136 -> 0:11 (XEN) IRQ212 -> 0:12 (XEN) IRQ152 -> 0:13 (XEN) IRQ160 -> 0:14 (XEN) IRQ168 -> 0:15 (XEN) IRQ174 -> 0:16 (XEN) IRQ192 -> 0:17 (XEN) IRQ200 -> 0:18 (XEN) IRQ241 -> 0:19 (XEN) IRQ97 -> 0:20 (XEN) IRQ50 -> 0:22 (XEN) IRQ172 -> 0:23 (XEN) .................................... done. --20cf3074b41aadec7b04bf7672ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 1:34 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On = 07.05.12 at 13:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 07/05/2012 09:10, Jan Beulich wrote:
> >>>>&= gt; On 05.05.12 at 02:21, AP <apxeng= @gmail.com> wrote:
> >>> (XEN) *** IRQ BUG found ***<= br> > >>> (XEN) CPU0 -Testing vector 236 from bitmap
> >&g= t; 236 =3D 0xec =3D FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming
>= ; >> in through the 8259A. Something fundamentally fishy must be goin= g
> >> on here, and I would suppose the code in question shouldn'= ;t even be
> >> reached for legacy vectors.
> >>> >> Furthermore, calling dump_irqs() from the debugging code wit= h
> >> desc->lock still held makes it impossible to get full outp= ut, as that
> >> function wants to lock all initialized IRQ des= criptors.
> >
> > Yes - it has been vector 236 on each of= the 3 reported failures from AP,
> > and I believe it was also vector 236 in the one case I managed to=
> > reproduce the issue.
> >
> > However, once = we have set up the IO-APIC, the 8259A should not be used
> > any m= ore. =A0The boot dmeg shows that io_ack_method is indeed "old" (w= hich
> > was going to be my first suggestion), and that EOI Broadcast Supp= ression
> > is enabled, which I have already identified as a sourc= e of problems for
> > some customers. =A0As a 'fix', I pro= vided the ability for
> > "io_ack_method=3Dnew" to prevent EOI Broadcast Suppress= ion being enabled.
> > This was upstreamed in c/s 24870:9bf3ec036b= ef, but apparently has not
> > completely fixed the customer probl= ems - just made it substantially more
> > rare.
> >
> > AP: Can you manually invoke the &= #39;i' debug key and provide that - it will
> > help to see ho= w Xen is setting up the IO-APIC(s) on your system.

(XEN) Guest inter= rupt information:
(XEN)=A0=A0=A0 IRQ:=A0=A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 1 affinity:= 02 vec:85 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000030 in-flight=3D0 doma= in-list=3D0:=A0 1(----),
(XEN)=A0=A0=A0 IRQ:=A0=A0 2 affinity:ff vec:e2 = type=3DXT-PIC=A0=A0=A0=A0=A0=A0=A0=A0=A0 status=3D00000000 mapped, unbound<= br> (XEN)=A0=A0=A0 IRQ:=A0=A0 3 affinity:01 vec:40 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 4 affinity:= 01 vec:48 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 5 affinity:01 vec:50 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 6 affinity:01 vec:58 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 7 affinity:= 01 vec:60 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 8 affinity:08 vec:29 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 8(----),
(XEN)=A0=A0=A0 IRQ:=A0=A0 9 affinity:02 vec:7f type=3DIO-APIC-level=A0=A0 s= tatus=3D00000010 in-flight=3D0 domain-list=3D0:=A0 9(----),
(XEN)=A0=A0= =A0 IRQ:=A0 10 affinity:01 vec:78 type=3DIO-APIC-edge=A0=A0=A0 status=3D000= 00002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 11 affinity:01 vec:88 type= =3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 12 affinity:08 vec:d4 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000030 in-flight=3D0 domain-list=3D0: 12(----),
(XEN)=A0=A0=A0= IRQ:=A0 13 affinity:0f vec:98 type=3DIO-APIC-edge=A0=A0=A0 status=3D000000= 02 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 14 affinity:01 vec:a0 type=3DI= O-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 15 affinity:01 vec:a8 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 16 affinity:02 v= ec:a6 type=3DIO-APIC-level=A0=A0 status=3D00000030 in-flight=3D0 domain-lis= t=3D0: 16(----),
(XEN)=A0=A0=A0 IRQ:=A0 17 affinity:0f vec:c0 type=3DIO-= APIC-level=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 18 affinity:0f vec:c8 type=3DIO-APIC-level=A0=A0 sta= tus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 19 affinity:0f vec= :f1 type=3DIO-APIC-level=A0=A0 status=3D00000000 mapped, unbound
(XEN)= =A0=A0=A0 IRQ:=A0 20 affinity:0f vec:61 type=3DIO-APIC-level=A0=A0 status= =3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 22 affinity:0f vec:32 type=3DIO-APIC-level=A0=A0 sta= tus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 23 affinity:01 vec= :ac type=3DIO-APIC-level=A0=A0 status=3D00000030 in-flight=3D0 domain-list= =3D0: 23(----),
(XEN)=A0=A0=A0 IRQ:=A0 24 affinity:01 vec:28 type=3DDMA_= MSI=A0=A0=A0=A0=A0=A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 25 affinity:01 vec:30 type=3DDMA_MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 26 af= finity:01 vec:31 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 status=3D00000030 in-flig= ht=3D0 domain-list=3D0:279(----),
(XEN)=A0=A0=A0 IRQ:=A0 27 affinity:01 = vec:39 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 status=3D00000030 in-flight=3D0 dom= ain-list=3D0:278(----),
(XEN)=A0=A0=A0 IRQ:=A0 28 affinity:01 vec:41 type=3DPCI-MSI/-X=A0=A0=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:277(----),
(XEN)=A0= =A0=A0 IRQ:=A0 29 affinity:01 vec:49 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 statu= s=3D00000030 in-flight=3D0 domain-list=3D0:276(----),
(XEN)=A0=A0=A0 IRQ:=A0 30 affinity:01 vec:51 type=3DPCI-MSI/-X=A0=A0=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:275(----),
(XEN)=A0= =A0=A0 IRQ:=A0 31 affinity:04 vec:d7 type=3DPCI-MSI=A0=A0=A0=A0=A0=A0=A0=A0= status=3D00000030 in-flight=3D0 domain-list=3D0:274(----),
(XEN)=A0=A0=A0 IRQ:=A0 32 affinity:04 vec:df type=3DPCI-MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000030 in-flight=3D0 domain-list=3D0:273(----),
(XE= N)=A0=A0=A0 IRQ:=A0 33 affinity:02 vec:b0 type=3DPCI-MSI=A0=A0=A0=A0=A0=A0= =A0=A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(----),
(XEN)=A0=A0=A0 IRQ:=A0 34 affinity:02 vec:a8 type=3DPCI-MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(----),
(XE= N)=A0=A0=A0 IRQ:=A0 35 affinity:04 vec:ad type=3DPCI-MSI=A0=A0=A0=A0=A0=A0= =A0=A0 status=3D00000030 in-flight=3D0 domain-list=3D0:270(----),
(XEN) IO-APIC interrupt information:
(XEN)=A0=A0=A0=A0 IRQ=A0 0 Vec240:<= br>(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 2: vec=3Df0 delivery=3DLoPri d= est=3DL status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN= )=A0=A0=A0=A0 IRQ=A0 1 Vec133:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0= 1: vec=3D85 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 3 Vec 64:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 3: vec=3D40 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 4 Vec 72:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 4: vec=3D48 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 5 Vec 80:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 5: vec=3D50 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 6 Vec 88:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 6: vec=3D58 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 7 Vec 96:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 7: vec=3D60 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 8 Vec 41:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 8: vec=3D29 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 9 Vec127:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 9: vec=3D7f delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 10 Vec120:
(XEN)=A0= =A0=A0=A0=A0=A0 Apic 0x00, Pin 10: vec=3D78 delivery=3DLoPri dest=3DL statu= s=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 11 Vec136:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 11: vec=3D88 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 12 Vec212:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 12: vec=3Dd4 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 13 Vec152:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 13: vec=3D98 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 14 Vec160:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 14: vec=3Da0 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 15 Vec168:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 15: vec=3Da8 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 16 Vec166:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 16: vec=3Da6 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 17 Vec192:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 17: vec=3Dc0 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 18 Vec200:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 18: vec=3Dc8 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 19 Vec241:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 19: vec=3Df1 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 20 Vec 97:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 20: vec=3D61 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 22 Vec 50:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 22: vec=3D32 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 23 Vec172:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 23: vec=3Dac delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D0 dest_id:0

> Seeing the 'z' output might also be helpful, especially to= see whether
> any of the IO-APICs' RTEs is an ExtINT one.
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #2 register= s: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #2......<= br>(XEN) .... register #00: 02000000
(XEN) .......=A0=A0=A0 : physical A= PIC id: 02
(XEN) .......=A0=A0=A0 : Delivery Type: 0
(XEN) .......=A0= =A0=A0 : LTS=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 0
(XEN) .... register #01: 00170020
(XEN) .......=A0=A0=A0=A0 : max redire= ction entries: 0017
(XEN) .......=A0=A0=A0=A0 : PRQ implemented: 0
(X= EN) .......=A0=A0=A0=A0 : IO APIC version: 0020
(XEN) .... IRQ redirecti= on table:
(XEN)=A0 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=A0= =A0
(XEN)=A0 00 000 00=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 0=A0= =A0=A0 0=A0=A0=A0 00
(XEN)=A0 01 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 85
(XEN)=A0 02 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 F0
(X= EN)=A0 03 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 40
(XEN)=A0 04 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 48
(XEN)=A0 05 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 50
(XEN)=A0 06 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 58
(X= EN)=A0 07 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 60
(XEN)=A0 08 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 29
(XEN)=A0 09 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 A7
(XEN)=A0 0a 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 78
(X= EN)=A0 0b 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 88
(XEN)=A0 0c 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 D4
(XEN)=A0 0d 000 00=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 98
(XEN)=A0 0e 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 A0
(X= EN)=A0 0f 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 A8
(XEN)=A0 10 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 AE
(XEN)=A0 11 000 00=A0 1=A0=A0=A0 1=A0=A0=A0 0=A0=A0= 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 C0
(XEN)=A0 12 000 00=A0 1=A0= =A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 C8
(X= EN)=A0 13 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 F1
(XEN)=A0 14 000 00=A0 1=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 61
(XEN)=A0 15 0CA 0A=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 2=A0=A0=A0 71
(XEN)=A0 16 000 00=A0 1=A0= =A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 32
(X= EN)=A0 17 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 AC
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IR= Q240 -> 0:2
(XEN) IRQ133 -> 0:1
(XEN) IRQ64 -> 0:3
(XEN) = IRQ72 -> 0:4
(XEN) IRQ80 -> 0:5
(XEN) IRQ88 -> 0:6
(XEN) = IRQ96 -> 0:7
(XEN) IRQ41 -> 0:8
(XEN) IRQ167 -> 0:9
(XEN) IRQ120 -> 0:10<= br>(XEN) IRQ136 -> 0:11
(XEN) IRQ212 -> 0:12
(XEN) IRQ152 ->= 0:13
(XEN) IRQ160 -> 0:14
(XEN) IRQ168 -> 0:15
(XEN) IRQ174= -> 0:16
(XEN) IRQ192 -> 0:17
(XEN) IRQ200 -> 0:18
(XEN) IRQ241 -> 0:= 19
(XEN) IRQ97 -> 0:20
(XEN) IRQ50 -> 0:22
(XEN) IRQ172 ->= ; 0:23
(XEN) .................................... done.


--20cf3074b41aadec7b04bf7672ab-- --===============8154351702464538460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8154351702464538460==-- From xen-devel-bounces@lists.xen.org Mon May 07 18:29:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18: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 ) id 1SRSgW-0006Lp-RA; Mon, 07 May 2012 18:29:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSgU-0006Lh-Fv for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:29:23 +0000 Received: from [85.158.139.83:24311] by server-12.bemta-5.messagelabs.com id 22/98-01344-18418AF4; Mon, 07 May 2012 18:29:21 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336415358!26609862!1 X-Originating-IP: [209.85.216.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31414 invoked from network); 7 May 2012 18:29:19 -0000 Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 18:29:19 -0000 Received: by qadb33 with SMTP id b33so2864802qad.9 for ; Mon, 07 May 2012 11:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lcb+zN2nLYpTZSW0WvPz8z6KZp4LglzWQ/3fTgrfJos=; b=qg3QFPiChICVNO0YigUPpak+2MSYfcRkY4H8xZOF9YA9BKBEi7xqDW92p6GK6CKkBb ykf4t2/0IuTnsyH+K3cga0p879S8UlCfk6duUQ6RERnYaO9TAE4EejUy00rZHJdW4cs/ 7knozKQDJJSkILwh1BWI7P27JCYAlrRMSlu4+YyNqM8WT1wgbBJwHkL1OPPx9T+/TqvT CvjhGh2rVIccJQdBJ4WPAPps543DyYv5lVCi7H/CVARxvj90Ztwa26eLjq/mT9tAR6tO tOSFpAG/qu2ipPj1+v7EqCoJ4N7vrgMkEagW0L+mAV4WtBAm87oHyDtFZp/6u6Cm8NiY dmSA== MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr20320468qao.23.1336415357889; Mon, 07 May 2012 11:29:17 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 11:29:17 -0700 (PDT) In-Reply-To: <4FA7EB80020000780008204B@nat28.tlf.novell.com> References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> Date: Mon, 7 May 2012 18:29:17 +0000 Message-ID: From: AP To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Andrew Cooper , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8154351702464538460==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8154351702464538460== Content-Type: multipart/alternative; boundary=20cf3074b41aadec7b04bf7672ab --20cf3074b41aadec7b04bf7672ab Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 1:34 PM, Jan Beulich wrote: > > >>> On 07.05.12 at 13:50, Andrew Cooper wrote: > > On 07/05/2012 09:10, Jan Beulich wrote: > >>>>> On 05.05.12 at 02:21, AP wrote: > >>> (XEN) *** IRQ BUG found *** > >>> (XEN) CPU0 -Testing vector 236 from bitmap > >> 236 = 0xec = FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming > >> in through the 8259A. Something fundamentally fishy must be going > >> on here, and I would suppose the code in question shouldn't even be > >> reached for legacy vectors. > >> > >> Furthermore, calling dump_irqs() from the debugging code with > >> desc->lock still held makes it impossible to get full output, as that > >> function wants to lock all initialized IRQ descriptors. > > > > Yes - it has been vector 236 on each of the 3 reported failures from AP, > > and I believe it was also vector 236 in the one case I managed to > > reproduce the issue. > > > > However, once we have set up the IO-APIC, the 8259A should not be used > > any more. The boot dmeg shows that io_ack_method is indeed "old" (which > > was going to be my first suggestion), and that EOI Broadcast Suppression > > is enabled, which I have already identified as a source of problems for > > some customers. As a 'fix', I provided the ability for > > "io_ack_method=new" to prevent EOI Broadcast Suppression being enabled. > > This was upstreamed in c/s 24870:9bf3ec036bef, but apparently has not > > completely fixed the customer problems - just made it substantially more > > rare. > > > > AP: Can you manually invoke the 'i' debug key and provide that - it will > > help to see how Xen is setting up the IO-APIC(s) on your system. (XEN) Guest interrupt information: (XEN) IRQ: 0 affinity:01 vec:f0 type=IO-APIC-edge status=00000000 mapped, unbound (XEN) IRQ: 1 affinity:02 vec:85 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 1(----), (XEN) IRQ: 2 affinity:ff vec:e2 type=XT-PIC status=00000000 mapped, unbound (XEN) IRQ: 3 affinity:01 vec:40 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 4 affinity:01 vec:48 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 5 affinity:01 vec:50 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 6 affinity:01 vec:58 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 7 affinity:01 vec:60 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 8 affinity:08 vec:29 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 8(----), (XEN) IRQ: 9 affinity:02 vec:7f type=IO-APIC-level status=00000010 in-flight=0 domain-list=0: 9(----), (XEN) IRQ: 10 affinity:01 vec:78 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 11 affinity:01 vec:88 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 12 affinity:08 vec:d4 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 12(----), (XEN) IRQ: 13 affinity:0f vec:98 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 14 affinity:01 vec:a0 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 15 affinity:01 vec:a8 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) IRQ: 16 affinity:02 vec:a6 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 16(----), (XEN) IRQ: 17 affinity:0f vec:c0 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 18 affinity:0f vec:c8 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 19 affinity:0f vec:f1 type=IO-APIC-level status=00000000 mapped, unbound (XEN) IRQ: 20 affinity:0f vec:61 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 22 affinity:0f vec:32 type=IO-APIC-level status=00000002 mapped, unbound (XEN) IRQ: 23 affinity:01 vec:ac type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 23(----), (XEN) IRQ: 24 affinity:01 vec:28 type=DMA_MSI status=00000000 mapped, unbound (XEN) IRQ: 25 affinity:01 vec:30 type=DMA_MSI status=00000000 mapped, unbound (XEN) IRQ: 26 affinity:01 vec:31 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:279(----), (XEN) IRQ: 27 affinity:01 vec:39 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:278(----), (XEN) IRQ: 28 affinity:01 vec:41 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:277(----), (XEN) IRQ: 29 affinity:01 vec:49 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:276(----), (XEN) IRQ: 30 affinity:01 vec:51 type=PCI-MSI/-X status=00000030 in-flight=0 domain-list=0:275(----), (XEN) IRQ: 31 affinity:04 vec:d7 type=PCI-MSI status=00000030 in-flight=0 domain-list=0:274(----), (XEN) IRQ: 32 affinity:04 vec:df type=PCI-MSI status=00000030 in-flight=0 domain-list=0:273(----), (XEN) IRQ: 33 affinity:02 vec:b0 type=PCI-MSI status=00000010 in-flight=0 domain-list=0:272(----), (XEN) IRQ: 34 affinity:02 vec:a8 type=PCI-MSI status=00000010 in-flight=0 domain-list=0:271(----), (XEN) IRQ: 35 affinity:04 vec:ad type=PCI-MSI status=00000030 in-flight=0 domain-list=0:270(----), (XEN) IO-APIC interrupt information: (XEN) IRQ 0 Vec240: (XEN) Apic 0x00, Pin 2: vec=f0 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 1 Vec133: (XEN) Apic 0x00, Pin 1: vec=85 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 3 Vec 64: (XEN) Apic 0x00, Pin 3: vec=40 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 4 Vec 72: (XEN) Apic 0x00, Pin 4: vec=48 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 5 Vec 80: (XEN) Apic 0x00, Pin 5: vec=50 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 6 Vec 88: (XEN) Apic 0x00, Pin 6: vec=58 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 7 Vec 96: (XEN) Apic 0x00, Pin 7: vec=60 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 8 Vec 41: (XEN) Apic 0x00, Pin 8: vec=29 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 9 Vec127: (XEN) Apic 0x00, Pin 9: vec=7f delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 10 Vec120: (XEN) Apic 0x00, Pin 10: vec=78 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 11 Vec136: (XEN) Apic 0x00, Pin 11: vec=88 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 12 Vec212: (XEN) Apic 0x00, Pin 12: vec=d4 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 13 Vec152: (XEN) Apic 0x00, Pin 13: vec=98 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=1 dest_id:0 (XEN) IRQ 14 Vec160: (XEN) Apic 0x00, Pin 14: vec=a0 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 15 Vec168: (XEN) Apic 0x00, Pin 15: vec=a8 delivery=LoPri dest=L status=0 polarity=0 irr=0 trig=E mask=0 dest_id:0 (XEN) IRQ 16 Vec166: (XEN) Apic 0x00, Pin 16: vec=a6 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 17 Vec192: (XEN) Apic 0x00, Pin 17: vec=c0 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 18 Vec200: (XEN) Apic 0x00, Pin 18: vec=c8 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 19 Vec241: (XEN) Apic 0x00, Pin 19: vec=f1 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 (XEN) IRQ 20 Vec 97: (XEN) Apic 0x00, Pin 20: vec=61 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 22 Vec 50: (XEN) Apic 0x00, Pin 22: vec=32 delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=1 dest_id:0 (XEN) IRQ 23 Vec172: (XEN) Apic 0x00, Pin 23: vec=ac delivery=LoPri dest=L status=0 polarity=1 irr=0 trig=L mask=0 dest_id:0 > Seeing the 'z' output might also be helpful, especially to see whether > any of the IO-APICs' RTEs is an ExtINT one. (XEN) number of MP IRQ sources: 15. (XEN) number of IO-APIC #2 registers: 24. (XEN) testing the IO APIC....................... (XEN) IO APIC #2...... (XEN) .... register #00: 02000000 (XEN) ....... : physical APIC id: 02 (XEN) ....... : Delivery Type: 0 (XEN) ....... : LTS : 0 (XEN) .... register #01: 00170020 (XEN) ....... : max redirection entries: 0017 (XEN) ....... : PRQ implemented: 0 (XEN) ....... : IO APIC version: 0020 (XEN) .... IRQ redirection table: (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: (XEN) 00 000 00 1 0 0 0 0 0 0 00 (XEN) 01 000 00 0 0 0 0 0 1 1 85 (XEN) 02 000 00 0 0 0 0 0 1 1 F0 (XEN) 03 000 00 0 0 0 0 0 1 1 40 (XEN) 04 000 00 0 0 0 0 0 1 1 48 (XEN) 05 000 00 0 0 0 0 0 1 1 50 (XEN) 06 000 00 0 0 0 0 0 1 1 58 (XEN) 07 000 00 0 0 0 0 0 1 1 60 (XEN) 08 000 00 0 0 0 0 0 1 1 29 (XEN) 09 000 00 0 1 0 0 0 1 1 A7 (XEN) 0a 000 00 0 0 0 0 0 1 1 78 (XEN) 0b 000 00 0 0 0 0 0 1 1 88 (XEN) 0c 000 00 0 0 0 0 0 1 1 D4 (XEN) 0d 000 00 1 0 0 0 0 1 1 98 (XEN) 0e 000 00 0 0 0 0 0 1 1 A0 (XEN) 0f 000 00 0 0 0 0 0 1 1 A8 (XEN) 10 000 00 0 1 0 1 0 1 1 AE (XEN) 11 000 00 1 1 0 1 0 1 1 C0 (XEN) 12 000 00 1 1 0 1 0 1 1 C8 (XEN) 13 000 00 0 1 0 1 0 1 1 F1 (XEN) 14 000 00 1 1 0 1 0 1 1 61 (XEN) 15 0CA 0A 1 0 0 0 0 1 2 71 (XEN) 16 000 00 1 1 0 1 0 1 1 32 (XEN) 17 000 00 0 1 0 1 0 1 1 AC (XEN) Using vector-based indexing (XEN) IRQ to pin mappings: (XEN) IRQ240 -> 0:2 (XEN) IRQ133 -> 0:1 (XEN) IRQ64 -> 0:3 (XEN) IRQ72 -> 0:4 (XEN) IRQ80 -> 0:5 (XEN) IRQ88 -> 0:6 (XEN) IRQ96 -> 0:7 (XEN) IRQ41 -> 0:8 (XEN) IRQ167 -> 0:9 (XEN) IRQ120 -> 0:10 (XEN) IRQ136 -> 0:11 (XEN) IRQ212 -> 0:12 (XEN) IRQ152 -> 0:13 (XEN) IRQ160 -> 0:14 (XEN) IRQ168 -> 0:15 (XEN) IRQ174 -> 0:16 (XEN) IRQ192 -> 0:17 (XEN) IRQ200 -> 0:18 (XEN) IRQ241 -> 0:19 (XEN) IRQ97 -> 0:20 (XEN) IRQ50 -> 0:22 (XEN) IRQ172 -> 0:23 (XEN) .................................... done. --20cf3074b41aadec7b04bf7672ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 1:34 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On = 07.05.12 at 13:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 07/05/2012 09:10, Jan Beulich wrote:
> >>>>&= gt; On 05.05.12 at 02:21, AP <apxeng= @gmail.com> wrote:
> >>> (XEN) *** IRQ BUG found ***<= br> > >>> (XEN) CPU0 -Testing vector 236 from bitmap
> >&g= t; 236 =3D 0xec =3D FIRST_LEGACY_VECTOR + 0x0c, i.e. an IRQ12 coming
>= ; >> in through the 8259A. Something fundamentally fishy must be goin= g
> >> on here, and I would suppose the code in question shouldn'= ;t even be
> >> reached for legacy vectors.
> >>> >> Furthermore, calling dump_irqs() from the debugging code wit= h
> >> desc->lock still held makes it impossible to get full outp= ut, as that
> >> function wants to lock all initialized IRQ des= criptors.
> >
> > Yes - it has been vector 236 on each of= the 3 reported failures from AP,
> > and I believe it was also vector 236 in the one case I managed to=
> > reproduce the issue.
> >
> > However, once = we have set up the IO-APIC, the 8259A should not be used
> > any m= ore. =A0The boot dmeg shows that io_ack_method is indeed "old" (w= hich
> > was going to be my first suggestion), and that EOI Broadcast Supp= ression
> > is enabled, which I have already identified as a sourc= e of problems for
> > some customers. =A0As a 'fix', I pro= vided the ability for
> > "io_ack_method=3Dnew" to prevent EOI Broadcast Suppress= ion being enabled.
> > This was upstreamed in c/s 24870:9bf3ec036b= ef, but apparently has not
> > completely fixed the customer probl= ems - just made it substantially more
> > rare.
> >
> > AP: Can you manually invoke the &= #39;i' debug key and provide that - it will
> > help to see ho= w Xen is setting up the IO-APIC(s) on your system.

(XEN) Guest inter= rupt information:
(XEN)=A0=A0=A0 IRQ:=A0=A0 0 affinity:01 vec:f0 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 1 affinity:= 02 vec:85 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000030 in-flight=3D0 doma= in-list=3D0:=A0 1(----),
(XEN)=A0=A0=A0 IRQ:=A0=A0 2 affinity:ff vec:e2 = type=3DXT-PIC=A0=A0=A0=A0=A0=A0=A0=A0=A0 status=3D00000000 mapped, unbound<= br> (XEN)=A0=A0=A0 IRQ:=A0=A0 3 affinity:01 vec:40 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 4 affinity:= 01 vec:48 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 5 affinity:01 vec:50 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 6 affinity:01 vec:58 type=3DIO-APIC-edge=A0=A0=A0= status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0=A0 7 affinity:= 01 vec:60 type=3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound(XEN)=A0=A0=A0 IRQ:=A0=A0 8 affinity:08 vec:29 type=3DIO-APIC-edge=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:=A0 8(----),
(XEN)=A0=A0=A0 IRQ:=A0=A0 9 affinity:02 vec:7f type=3DIO-APIC-level=A0=A0 s= tatus=3D00000010 in-flight=3D0 domain-list=3D0:=A0 9(----),
(XEN)=A0=A0= =A0 IRQ:=A0 10 affinity:01 vec:78 type=3DIO-APIC-edge=A0=A0=A0 status=3D000= 00002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 11 affinity:01 vec:88 type= =3DIO-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 12 affinity:08 vec:d4 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000030 in-flight=3D0 domain-list=3D0: 12(----),
(XEN)=A0=A0=A0= IRQ:=A0 13 affinity:0f vec:98 type=3DIO-APIC-edge=A0=A0=A0 status=3D000000= 02 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 14 affinity:01 vec:a0 type=3DI= O-APIC-edge=A0=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 15 affinity:01 vec:a8 type=3DIO-APIC-edge=A0=A0=A0 s= tatus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 16 affinity:02 v= ec:a6 type=3DIO-APIC-level=A0=A0 status=3D00000030 in-flight=3D0 domain-lis= t=3D0: 16(----),
(XEN)=A0=A0=A0 IRQ:=A0 17 affinity:0f vec:c0 type=3DIO-= APIC-level=A0=A0 status=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 18 affinity:0f vec:c8 type=3DIO-APIC-level=A0=A0 sta= tus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 19 affinity:0f vec= :f1 type=3DIO-APIC-level=A0=A0 status=3D00000000 mapped, unbound
(XEN)= =A0=A0=A0 IRQ:=A0 20 affinity:0f vec:61 type=3DIO-APIC-level=A0=A0 status= =3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 22 affinity:0f vec:32 type=3DIO-APIC-level=A0=A0 sta= tus=3D00000002 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 23 affinity:01 vec= :ac type=3DIO-APIC-level=A0=A0 status=3D00000030 in-flight=3D0 domain-list= =3D0: 23(----),
(XEN)=A0=A0=A0 IRQ:=A0 24 affinity:01 vec:28 type=3DDMA_= MSI=A0=A0=A0=A0=A0=A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 25 affinity:01 vec:30 type=3DDMA_MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000000 mapped, unbound
(XEN)=A0=A0=A0 IRQ:=A0 26 af= finity:01 vec:31 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 status=3D00000030 in-flig= ht=3D0 domain-list=3D0:279(----),
(XEN)=A0=A0=A0 IRQ:=A0 27 affinity:01 = vec:39 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 status=3D00000030 in-flight=3D0 dom= ain-list=3D0:278(----),
(XEN)=A0=A0=A0 IRQ:=A0 28 affinity:01 vec:41 type=3DPCI-MSI/-X=A0=A0=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:277(----),
(XEN)=A0= =A0=A0 IRQ:=A0 29 affinity:01 vec:49 type=3DPCI-MSI/-X=A0=A0=A0=A0=A0 statu= s=3D00000030 in-flight=3D0 domain-list=3D0:276(----),
(XEN)=A0=A0=A0 IRQ:=A0 30 affinity:01 vec:51 type=3DPCI-MSI/-X=A0=A0=A0=A0= =A0 status=3D00000030 in-flight=3D0 domain-list=3D0:275(----),
(XEN)=A0= =A0=A0 IRQ:=A0 31 affinity:04 vec:d7 type=3DPCI-MSI=A0=A0=A0=A0=A0=A0=A0=A0= status=3D00000030 in-flight=3D0 domain-list=3D0:274(----),
(XEN)=A0=A0=A0 IRQ:=A0 32 affinity:04 vec:df type=3DPCI-MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000030 in-flight=3D0 domain-list=3D0:273(----),
(XE= N)=A0=A0=A0 IRQ:=A0 33 affinity:02 vec:b0 type=3DPCI-MSI=A0=A0=A0=A0=A0=A0= =A0=A0 status=3D00000010 in-flight=3D0 domain-list=3D0:272(----),
(XEN)=A0=A0=A0 IRQ:=A0 34 affinity:02 vec:a8 type=3DPCI-MSI=A0=A0=A0=A0=A0= =A0=A0=A0 status=3D00000010 in-flight=3D0 domain-list=3D0:271(----),
(XE= N)=A0=A0=A0 IRQ:=A0 35 affinity:04 vec:ad type=3DPCI-MSI=A0=A0=A0=A0=A0=A0= =A0=A0 status=3D00000030 in-flight=3D0 domain-list=3D0:270(----),
(XEN) IO-APIC interrupt information:
(XEN)=A0=A0=A0=A0 IRQ=A0 0 Vec240:<= br>(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 2: vec=3Df0 delivery=3DLoPri d= est=3DL status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN= )=A0=A0=A0=A0 IRQ=A0 1 Vec133:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0= 1: vec=3D85 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 3 Vec 64:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 3: vec=3D40 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 4 Vec 72:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 4: vec=3D48 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 5 Vec 80:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 5: vec=3D50 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 6 Vec 88:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 6: vec=3D58 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 7 Vec 96:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 7: vec=3D60 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 8 Vec 41:
(XEN)= =A0=A0=A0=A0=A0=A0 Apic 0x00, Pin=A0 8: vec=3D29 delivery=3DLoPri dest=3DL = status=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ=A0 9 Vec127:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pi= n=A0 9: vec=3D7f delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 = trig=3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 10 Vec120:
(XEN)=A0= =A0=A0=A0=A0=A0 Apic 0x00, Pin 10: vec=3D78 delivery=3DLoPri dest=3DL statu= s=3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 11 Vec136:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 11: vec=3D88 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 12 Vec212:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 12: vec=3Dd4 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 13 Vec152:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 13: vec=3D98 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 14 Vec160:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 14: vec=3Da0 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D0 irr=3D0 trig=3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 15 Vec168:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 15: vec=3Da8 delivery=3DLoPri dest=3DL status=3D0 polarity=3D0 irr=3D0 trig= =3DE mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 16 Vec166:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 16: vec=3Da6 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 17 Vec192:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 17: vec=3Dc0 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 18 Vec200:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 18: vec=3Dc8 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 19 Vec241:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 19: vec=3Df1 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D0 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 20 Vec 97:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 20: vec=3D61 delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 22 Vec 50:
(XEN)=A0=A0=A0=A0=A0=A0 Apic 0x00, Pin = 22: vec=3D32 delivery=3DLoPri dest=3DL status=3D0 polarity=3D1 irr=3D0 trig= =3DL mask=3D1 dest_id:0
(XEN)=A0=A0=A0=A0 IRQ 23 Vec172:
(XEN)=A0=A0= =A0=A0=A0=A0 Apic 0x00, Pin 23: vec=3Dac delivery=3DLoPri dest=3DL status= =3D0 polarity=3D1 irr=3D0 trig=3DL mask=3D0 dest_id:0

> Seeing the 'z' output might also be helpful, especially to= see whether
> any of the IO-APICs' RTEs is an ExtINT one.
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #2 register= s: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #2......<= br>(XEN) .... register #00: 02000000
(XEN) .......=A0=A0=A0 : physical A= PIC id: 02
(XEN) .......=A0=A0=A0 : Delivery Type: 0
(XEN) .......=A0= =A0=A0 : LTS=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 0
(XEN) .... register #01: 00170020
(XEN) .......=A0=A0=A0=A0 : max redire= ction entries: 0017
(XEN) .......=A0=A0=A0=A0 : PRQ implemented: 0
(X= EN) .......=A0=A0=A0=A0 : IO APIC version: 0020
(XEN) .... IRQ redirecti= on table:
(XEN)=A0 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=A0= =A0
(XEN)=A0 00 000 00=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 0=A0= =A0=A0 0=A0=A0=A0 00
(XEN)=A0 01 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 85
(XEN)=A0 02 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 F0
(X= EN)=A0 03 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 40
(XEN)=A0 04 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 48
(XEN)=A0 05 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 50
(XEN)=A0 06 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 58
(X= EN)=A0 07 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 60
(XEN)=A0 08 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 29
(XEN)=A0 09 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 A7
(XEN)=A0 0a 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 78
(X= EN)=A0 0b 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 88
(XEN)=A0 0c 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 D4
(XEN)=A0 0d 000 00=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 98
(XEN)=A0 0e 000 00=A0 0=A0= =A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 A0
(X= EN)=A0 0f 000 00=A0 0=A0=A0=A0 0=A0=A0=A0 0=A0=A0 0=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 A8
(XEN)=A0 10 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 AE
(XEN)=A0 11 000 00=A0 1=A0=A0=A0 1=A0=A0=A0 0=A0=A0= 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 C0
(XEN)=A0 12 000 00=A0 1=A0= =A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 C8
(X= EN)=A0 13 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 F1
(XEN)=A0 14 000 00=A0 1=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 61
(XEN)=A0 15 0CA 0A=A0 1=A0=A0=A0 0=A0=A0=A0 0=A0=A0= 0=A0=A0 0=A0=A0=A0 1=A0=A0=A0 2=A0=A0=A0 71
(XEN)=A0 16 000 00=A0 1=A0= =A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0=A0=A0 1=A0=A0=A0 32
(X= EN)=A0 17 000 00=A0 0=A0=A0=A0 1=A0=A0=A0 0=A0=A0 1=A0=A0 0=A0=A0=A0 1=A0= =A0=A0 1=A0=A0=A0 AC
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IR= Q240 -> 0:2
(XEN) IRQ133 -> 0:1
(XEN) IRQ64 -> 0:3
(XEN) = IRQ72 -> 0:4
(XEN) IRQ80 -> 0:5
(XEN) IRQ88 -> 0:6
(XEN) = IRQ96 -> 0:7
(XEN) IRQ41 -> 0:8
(XEN) IRQ167 -> 0:9
(XEN) IRQ120 -> 0:10<= br>(XEN) IRQ136 -> 0:11
(XEN) IRQ212 -> 0:12
(XEN) IRQ152 ->= 0:13
(XEN) IRQ160 -> 0:14
(XEN) IRQ168 -> 0:15
(XEN) IRQ174= -> 0:16
(XEN) IRQ192 -> 0:17
(XEN) IRQ200 -> 0:18
(XEN) IRQ241 -> 0:= 19
(XEN) IRQ97 -> 0:20
(XEN) IRQ50 -> 0:22
(XEN) IRQ172 ->= ; 0:23
(XEN) .................................... done.


--20cf3074b41aadec7b04bf7672ab-- --===============8154351702464538460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8154351702464538460==-- From xen-devel-bounces@lists.xen.org Mon May 07 18:37:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18:37:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSoQ-0006bj-IK; Mon, 07 May 2012 18:37:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSoO-0006bR-VD for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:37:33 +0000 Received: from [85.158.139.83:53660] by server-8.bemta-5.messagelabs.com id 08/2B-26964-C6618AF4; Mon, 07 May 2012 18:37:32 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-182.messagelabs.com!1336415850!27071776!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26095 invoked from network); 7 May 2012 18:37:31 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-182.messagelabs.com with SMTP; 7 May 2012 18:37:31 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47IbT40021154; Mon, 7 May 2012 14:37:29 -0400 Message-ID: <4FA81669.5040202@theshore.net> Date: Mon, 07 May 2012 14:37:29 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> In-Reply-To: <20120507171703.GA5746@phenom.dumpdata.com> Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This looks suspiciously like the problem described by Nai Xia in "mm: page_check_address bug fix and make it validate subpages in huge pages" - which never made it into mainline that I can detect. We've rebuilt without CONFIG_HIGHPTE and are running our test again. We shall see. -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 18:37:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18:37:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSoQ-0006bj-IK; Mon, 07 May 2012 18:37:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRSoO-0006bR-VD for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:37:33 +0000 Received: from [85.158.139.83:53660] by server-8.bemta-5.messagelabs.com id 08/2B-26964-C6618AF4; Mon, 07 May 2012 18:37:32 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-182.messagelabs.com!1336415850!27071776!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26095 invoked from network); 7 May 2012 18:37:31 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-182.messagelabs.com with SMTP; 7 May 2012 18:37:31 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47IbT40021154; Mon, 7 May 2012 14:37:29 -0400 Message-ID: <4FA81669.5040202@theshore.net> Date: Mon, 07 May 2012 14:37:29 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> In-Reply-To: <20120507171703.GA5746@phenom.dumpdata.com> Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This looks suspiciously like the problem described by Nai Xia in "mm: page_check_address bug fix and make it validate subpages in huge pages" - which never made it into mainline that I can detect. We've rebuilt without CONFIG_HIGHPTE and are running our test again. We shall see. -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 18:54:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18: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 ) id 1SRT4S-00077Y-D9; Mon, 07 May 2012 18:54:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRT4Q-00077T-Mr for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:54:06 +0000 Received: from [85.158.143.99:38055] by server-3.bemta-4.messagelabs.com id C6/7B-05853-E4A18AF4; Mon, 07 May 2012 18:54:06 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336416843!23504259!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21061 invoked from network); 7 May 2012 18:54:05 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 18:54:05 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47IrwYw023342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 18:53:59 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 q47IrvMm015741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 18:53:58 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q47IrvZE017664; Mon, 7 May 2012 13:53:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 11:53:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9CBB54031D; Mon, 7 May 2012 14:48:08 -0400 (EDT) Date: Mon, 7 May 2012 14:48:08 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120507184808.GA7249@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA2B1EF.8080900@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: > On 03/05/12 16:15, David Vrabel wrote: > > > > xen: update VA mapping when releasing memory during setup > > > > In xen_memory_setup(), if a page that is being released has a VA > > mapping this must also be updated. Otherwise, the page will be not > > released completely -- it will still be referenced in Xen and won't be > > freed util the mapping is removed and this prevents it from being > > reallocated at a different PFN. > > > > This was already being done for the ISA memory region in > > xen_ident_map_ISA() but on many systems this was omitting a few pages > > as many systems marked a few pages below the ISA memory region as > > reserved in the e820 map. > > > > Signed-off-by: David Vrabel > > --- > [...] > > --- a/arch/x86/xen/mmu.c > > +++ b/arch/x86/xen/mmu.c > > @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > > #endif > > } > > > > -void __init xen_ident_map_ISA(void) > > -{ > > - unsigned long pa; > > - > > - /* > > - * If we're dom0, then linear map the ISA machine addresses into > > - * the kernel's address space. > > - */ > > - if (!xen_initial_domain()) > > - return; > > It might look like this test has gone, however the new code which > updates the VA mapping uses the e820 map and for a domU its map will not > have a ISA region so there's no mapping to be updated. What if you use e820_hole=1 and the pci=xx in the guest? > > David > > > - > > - xen_raw_printk("Xen: setup ISA identity maps\n"); > > - > > - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { > > - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); > > - > > - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) > > - BUG(); > > - } > > - > > - xen_flush_tlb(); > > -} > > - > > static void __init xen_post_allocator_init(void) > > { > > pv_mmu_ops.set_pte = xen_set_pte; > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > > index 506a3e6..d5f8714 100644 > > --- a/arch/x86/xen/setup.c > > +++ b/arch/x86/xen/setup.c > > @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, > > > > return len; > > } > > + > > +static unsigned long __init xen_release_chunk(unsigned long start, > > + unsigned long end) > > +{ > > + return xen_do_chunk(start, end, true); > > +} > > + > > static unsigned long __init xen_populate_chunk( > > const struct e820entry *list, size_t map_size, > > unsigned long max_pfn, unsigned long *last_pfn, > > @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( > > } > > return done; > > } > > + > > +static void __init xen_set_identity_and_release_chunk( > > + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, > > + unsigned long *released, unsigned long *identity) > > +{ > > + unsigned long pfn; > > + > > + /* > > + * If the PFNs are currently mapped, the VA mapping also needs > > + * to be updated to be 1:1. > > + */ > > + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) > > + (void)HYPERVISOR_update_va_mapping( > > + (unsigned long)__va(pfn << PAGE_SHIFT), > > + mfn_pte(pfn, PAGE_KERNEL_IO), 0); > > + > > + if (start_pfn < nr_pages) > > + *released += xen_release_chunk( > > + start_pfn, min(end_pfn, nr_pages)); > > + > > + *identity += set_phys_range_identity(start_pfn, end_pfn); > > +} > > + > > static unsigned long __init xen_set_identity_and_release( > > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > > { > > @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( > > if (entry->type == E820_RAM) > > end_pfn = PFN_UP(entry->addr); > > > > - if (start_pfn < end_pfn) { > > - if (start_pfn < nr_pages) > > - released += xen_do_chunk( > > - start_pfn, min(end_pfn, nr_pages), true); > > + if (start_pfn < end_pfn) > > + xen_set_identity_and_release_chunk( > > + start_pfn, end_pfn, nr_pages, > > + &released, &identity); > > > > - identity += set_phys_range_identity( > > - start_pfn, end_pfn); > > - } > > start = end; > > } > > } > > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > > index b095739..506fa08 100644 > > --- a/arch/x86/xen/xen-ops.h > > +++ b/arch/x86/xen/xen-ops.h > > @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); > > void xen_build_mfn_list_list(void); > > void xen_setup_machphys_mapping(void); > > pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); > > -void xen_ident_map_ISA(void); > > void xen_reserve_top(void); > > extern unsigned long xen_max_p2m_pfn; > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 18:54:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 18: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 ) id 1SRT4S-00077Y-D9; Mon, 07 May 2012 18:54:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRT4Q-00077T-Mr for xen-devel@lists.xensource.com; Mon, 07 May 2012 18:54:06 +0000 Received: from [85.158.143.99:38055] by server-3.bemta-4.messagelabs.com id C6/7B-05853-E4A18AF4; Mon, 07 May 2012 18:54:06 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336416843!23504259!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21061 invoked from network); 7 May 2012 18:54:05 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 18:54:05 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47IrwYw023342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 18:53:59 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 q47IrvMm015741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 18:53:58 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q47IrvZE017664; Mon, 7 May 2012 13:53:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 11:53:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9CBB54031D; Mon, 7 May 2012 14:48:08 -0400 (EDT) Date: Mon, 7 May 2012 14:48:08 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120507184808.GA7249@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA2B1EF.8080900@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: > On 03/05/12 16:15, David Vrabel wrote: > > > > xen: update VA mapping when releasing memory during setup > > > > In xen_memory_setup(), if a page that is being released has a VA > > mapping this must also be updated. Otherwise, the page will be not > > released completely -- it will still be referenced in Xen and won't be > > freed util the mapping is removed and this prevents it from being > > reallocated at a different PFN. > > > > This was already being done for the ISA memory region in > > xen_ident_map_ISA() but on many systems this was omitting a few pages > > as many systems marked a few pages below the ISA memory region as > > reserved in the e820 map. > > > > Signed-off-by: David Vrabel > > --- > [...] > > --- a/arch/x86/xen/mmu.c > > +++ b/arch/x86/xen/mmu.c > > @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > > #endif > > } > > > > -void __init xen_ident_map_ISA(void) > > -{ > > - unsigned long pa; > > - > > - /* > > - * If we're dom0, then linear map the ISA machine addresses into > > - * the kernel's address space. > > - */ > > - if (!xen_initial_domain()) > > - return; > > It might look like this test has gone, however the new code which > updates the VA mapping uses the e820 map and for a domU its map will not > have a ISA region so there's no mapping to be updated. What if you use e820_hole=1 and the pci=xx in the guest? > > David > > > - > > - xen_raw_printk("Xen: setup ISA identity maps\n"); > > - > > - for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) { > > - pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO); > > - > > - if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0)) > > - BUG(); > > - } > > - > > - xen_flush_tlb(); > > -} > > - > > static void __init xen_post_allocator_init(void) > > { > > pv_mmu_ops.set_pte = xen_set_pte; > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > > index 506a3e6..d5f8714 100644 > > --- a/arch/x86/xen/setup.c > > +++ b/arch/x86/xen/setup.c > > @@ -139,6 +139,13 @@ static unsigned long __init xen_do_chunk(unsigned long start, > > > > return len; > > } > > + > > +static unsigned long __init xen_release_chunk(unsigned long start, > > + unsigned long end) > > +{ > > + return xen_do_chunk(start, end, true); > > +} > > + > > static unsigned long __init xen_populate_chunk( > > const struct e820entry *list, size_t map_size, > > unsigned long max_pfn, unsigned long *last_pfn, > > @@ -197,6 +204,29 @@ static unsigned long __init xen_populate_chunk( > > } > > return done; > > } > > + > > +static void __init xen_set_identity_and_release_chunk( > > + unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages, > > + unsigned long *released, unsigned long *identity) > > +{ > > + unsigned long pfn; > > + > > + /* > > + * If the PFNs are currently mapped, the VA mapping also needs > > + * to be updated to be 1:1. > > + */ > > + for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) > > + (void)HYPERVISOR_update_va_mapping( > > + (unsigned long)__va(pfn << PAGE_SHIFT), > > + mfn_pte(pfn, PAGE_KERNEL_IO), 0); > > + > > + if (start_pfn < nr_pages) > > + *released += xen_release_chunk( > > + start_pfn, min(end_pfn, nr_pages)); > > + > > + *identity += set_phys_range_identity(start_pfn, end_pfn); > > +} > > + > > static unsigned long __init xen_set_identity_and_release( > > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > > { > > @@ -226,14 +256,11 @@ static unsigned long __init xen_set_identity_and_release( > > if (entry->type == E820_RAM) > > end_pfn = PFN_UP(entry->addr); > > > > - if (start_pfn < end_pfn) { > > - if (start_pfn < nr_pages) > > - released += xen_do_chunk( > > - start_pfn, min(end_pfn, nr_pages), true); > > + if (start_pfn < end_pfn) > > + xen_set_identity_and_release_chunk( > > + start_pfn, end_pfn, nr_pages, > > + &released, &identity); > > > > - identity += set_phys_range_identity( > > - start_pfn, end_pfn); > > - } > > start = end; > > } > > } > > diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h > > index b095739..506fa08 100644 > > --- a/arch/x86/xen/xen-ops.h > > +++ b/arch/x86/xen/xen-ops.h > > @@ -28,7 +28,6 @@ void xen_setup_shared_info(void); > > void xen_build_mfn_list_list(void); > > void xen_setup_machphys_mapping(void); > > pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn); > > -void xen_ident_map_ISA(void); > > void xen_reserve_top(void); > > extern unsigned long xen_max_p2m_pfn; > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:16:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19:16:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRTQ8-0007MN-Cq; Mon, 07 May 2012 19:16:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRTQ6-0007MI-Kq for xen-devel@lists.xen.org; Mon, 07 May 2012 19:16:30 +0000 Received: from [193.109.254.147:24427] by server-9.bemta-14.messagelabs.com id D6/A6-05787-D8F18AF4; Mon, 07 May 2012 19:16:29 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-8.tower-27.messagelabs.com!1336418188!8083692!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16410 invoked from network); 7 May 2012 19:16:29 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-8.tower-27.messagelabs.com with SMTP; 7 May 2012 19:16:29 -0000 X-TM-IMSS-Message-ID: <2a06ab69000b1959@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2a06ab69000b1959 ; Mon, 7 May 2012 15:16:40 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q47JGLgx014644; Mon, 7 May 2012 15:16:21 -0400 From: Daniel De Graaf To: Ian Jackson , Ian Campbell Date: Mon, 7 May 2012 15:15:09 -0400 Message-Id: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 Cc: Daniel De Graaf , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Change the macro to a statement including the return variable to fix this. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 37 +++++++++++++++++++++---------------- 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..6aced19 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,23 @@ * 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__) +#define OSEVENT_HOOK_RET(rc, hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } else { \ + rc = 0; \ + } \ +} while (0) + +#define OSEVENT_HOOK_VOID(hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) /* * fd events @@ -54,7 +59,7 @@ int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev, CTX_LOCK; - rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev); + OSEVENT_HOOK_RET(rc, fd_register, fd, &ev->for_app_reg, events, ev); if (rc) goto out; ev->fd = fd; @@ -77,7 +82,7 @@ int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) CTX_LOCK; assert(libxl__ev_fd_isregistered(ev)); - rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events); + OSEVENT_HOOK_RET(rc, fd_modify, ev->fd, &ev->for_app_reg, events); if (rc) goto out; ev->events = events; @@ -147,7 +152,7 @@ static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev, { int rc; - rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev); + OSEVENT_HOOK_RET(rc, timeout_register, &ev->for_app_reg, abs, ev); if (rc) return rc; ev->infinite = 0; @@ -226,7 +231,7 @@ int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev, rc = time_register_finite(gc, ev, abs); if (rc) goto out; } else { - rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs); + OSEVENT_HOOK_RET(rc, timeout_modify, &ev->for_app_reg, abs); if (rc) goto out; LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry); -- 1.7.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:16:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19:16:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRTQ8-0007MN-Cq; Mon, 07 May 2012 19:16:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRTQ6-0007MI-Kq for xen-devel@lists.xen.org; Mon, 07 May 2012 19:16:30 +0000 Received: from [193.109.254.147:24427] by server-9.bemta-14.messagelabs.com id D6/A6-05787-D8F18AF4; Mon, 07 May 2012 19:16:29 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-8.tower-27.messagelabs.com!1336418188!8083692!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16410 invoked from network); 7 May 2012 19:16:29 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-8.tower-27.messagelabs.com with SMTP; 7 May 2012 19:16:29 -0000 X-TM-IMSS-Message-ID: <2a06ab69000b1959@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2a06ab69000b1959 ; Mon, 7 May 2012 15:16:40 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q47JGLgx014644; Mon, 7 May 2012 15:16:21 -0400 From: Daniel De Graaf To: Ian Jackson , Ian Campbell Date: Mon, 7 May 2012 15:15:09 -0400 Message-Id: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 Cc: Daniel De Graaf , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Change the macro to a statement including the return variable to fix this. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 37 +++++++++++++++++++++---------------- 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..6aced19 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,23 @@ * 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__) +#define OSEVENT_HOOK_RET(rc, hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } else { \ + rc = 0; \ + } \ +} while (0) + +#define OSEVENT_HOOK_VOID(hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) /* * fd events @@ -54,7 +59,7 @@ int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev, CTX_LOCK; - rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev); + OSEVENT_HOOK_RET(rc, fd_register, fd, &ev->for_app_reg, events, ev); if (rc) goto out; ev->fd = fd; @@ -77,7 +82,7 @@ int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) CTX_LOCK; assert(libxl__ev_fd_isregistered(ev)); - rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events); + OSEVENT_HOOK_RET(rc, fd_modify, ev->fd, &ev->for_app_reg, events); if (rc) goto out; ev->events = events; @@ -147,7 +152,7 @@ static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev, { int rc; - rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev); + OSEVENT_HOOK_RET(rc, timeout_register, &ev->for_app_reg, abs, ev); if (rc) return rc; ev->infinite = 0; @@ -226,7 +231,7 @@ int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev, rc = time_register_finite(gc, ev, abs); if (rc) goto out; } else { - rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs); + OSEVENT_HOOK_RET(rc, timeout_modify, &ev->for_app_reg, abs); if (rc) goto out; LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry); -- 1.7.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:55:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU1N-0007Zf-MD; Mon, 07 May 2012 19:55:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU1M-0007Za-Jt for xen-devel@lists.xensource.com; Mon, 07 May 2012 19:55:00 +0000 Received: from [193.109.254.147:50177] by server-11.bemta-14.messagelabs.com id A2/93-05858-39828AF4; Mon, 07 May 2012 19:54:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336420497!8087408!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4531 invoked from network); 7 May 2012 19:54:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 19:54:59 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47Jsj23019395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 19:54:45 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 q47JsiGc002527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 19:54:44 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q47Jsf3x007366; Mon, 7 May 2012 14:54:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 12:54:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4087D4031D; Mon, 7 May 2012 15:48:51 -0400 (EDT) Date: Mon, 7 May 2012 15:48:51 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20120507194851.GA17718@phenom.dumpdata.com> References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> <4FA2615C.1000301@hfp.de> <1336042317.20716.40.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336042317.20716.40.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Andreas Kinzler Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 11:51:57AM +0100, Ian Campbell wrote: > On Thu, 2012-05-03 at 11:43 +0100, Andreas Kinzler wrote: > > On 02.05.2012 15:31, Ian Campbell wrote: > > > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > > > workloads natively? > > > > Yes, I tested against 2.6.32.x. Differences exist, but are minor. > > Good to know, thanks for testing > > The other potential Xen perf thing which just occurred to to me is the > ACPI power management stuff which the xen-acpi-processor patches in > 3.4-rcN are fixing. These are necessary to enable things like turbo mode > so have a pretty large perf impact. > > Are you able to try the latest 3.4-rc kernel? > > I'm not sure if backports to the kernels you are running exist or not, > Konrad? No. But they should be easy to cherry-pick. However, I would suggest trying v3.4-rc6 first and seeing if that makes a difference. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:55:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU1N-0007Zf-MD; Mon, 07 May 2012 19:55:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU1M-0007Za-Jt for xen-devel@lists.xensource.com; Mon, 07 May 2012 19:55:00 +0000 Received: from [193.109.254.147:50177] by server-11.bemta-14.messagelabs.com id A2/93-05858-39828AF4; Mon, 07 May 2012 19:54:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336420497!8087408!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNjUzMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4531 invoked from network); 7 May 2012 19:54:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 19:54:59 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47Jsj23019395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 19:54:45 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 q47JsiGc002527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 19:54:44 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q47Jsf3x007366; Mon, 7 May 2012 14:54:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 12:54:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4087D4031D; Mon, 7 May 2012 15:48:51 -0400 (EDT) Date: Mon, 7 May 2012 15:48:51 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20120507194851.GA17718@phenom.dumpdata.com> References: <4FA1328B.6070602@hfp.de> <1335965470.26758.58.camel@zakaz.uk.xensource.com> <4FA2615C.1000301@hfp.de> <1336042317.20716.40.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336042317.20716.40.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Andreas Kinzler Subject: Re: [Xen-devel] Poor performance with Linux 3.x as dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 03, 2012 at 11:51:57AM +0100, Ian Campbell wrote: > On Thu, 2012-05-03 at 11:43 +0100, Andreas Kinzler wrote: > > On 02.05.2012 15:31, Ian Campbell wrote: > > > Did you happen to also compare 3.2.12 and 2.6.34.10 running these > > > workloads natively? > > > > Yes, I tested against 2.6.32.x. Differences exist, but are minor. > > Good to know, thanks for testing > > The other potential Xen perf thing which just occurred to to me is the > ACPI power management stuff which the xen-acpi-processor patches in > 3.4-rcN are fixing. These are necessary to enable things like turbo mode > so have a pretty large perf impact. > > Are you able to try the latest 3.4-rc kernel? > > I'm not sure if backports to the kernels you are running exist or not, > Konrad? No. But they should be easy to cherry-pick. However, I would suggest trying v3.4-rc6 first and seeing if that makes a difference. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:59:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19: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 ) id 1SRU5X-0007ga-BD; Mon, 07 May 2012 19:59:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU5V-0007gU-Uv for xen-devel@lists.xensource.com; Mon, 07 May 2012 19:59:18 +0000 Received: from [193.109.254.147:57258] by server-8.bemta-14.messagelabs.com id A4/CB-23244-59928AF4; Mon, 07 May 2012 19:59:17 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1336420755!8060744!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13590 invoked from network); 7 May 2012 19:59:16 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-4.tower-27.messagelabs.com with SMTP; 7 May 2012 19:59:16 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47JxEHA028382; Mon, 7 May 2012 15:59:14 -0400 Message-ID: <4FA82992.1030508@theshore.net> Date: Mon, 07 May 2012 15:59:14 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> <4FA81669.5040202@theshore.net> In-Reply-To: <4FA81669.5040202@theshore.net> Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 5/7/12 2:37 PM, Christopher S. Aker wrote: > This looks suspiciously like the problem described by Nai Xia in "mm: > page_check_address bug fix and make it validate subpages in huge pages" > - which never made it into mainline > that I can detect. > > We've rebuilt without CONFIG_HIGHPTE and are running our test again. We > shall see. No joy just disabling CONFIG_HIGHPTE. Triggered it on four boxes in no time. Bugs out exactly the same as before except the second BUG "scheduling while atomic" doesn't happen. On 5/7/12 1:17 PM, Konrad Rzeszutek Wilk wrote: > Hm, can you give more details on what parameters you are passing to > dom0 and the hypervisor so I can reproduce it? Xen and dom0 binaries and modules, and arguments here: http://theshore.net/~caker/xen/BUGS/lvm/ This is atop hardware RAID -- we haven't tested on anything other than Supermicro motherboards. Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 19:59:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 19: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 ) id 1SRU5X-0007ga-BD; Mon, 07 May 2012 19:59:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU5V-0007gU-Uv for xen-devel@lists.xensource.com; Mon, 07 May 2012 19:59:18 +0000 Received: from [193.109.254.147:57258] by server-8.bemta-14.messagelabs.com id A4/CB-23244-59928AF4; Mon, 07 May 2012 19:59:17 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1336420755!8060744!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13590 invoked from network); 7 May 2012 19:59:16 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-4.tower-27.messagelabs.com with SMTP; 7 May 2012 19:59:16 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q47JxEHA028382; Mon, 7 May 2012 15:59:14 -0400 Message-ID: <4FA82992.1030508@theshore.net> Date: Mon, 07 May 2012 15:59:14 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> <4FA81669.5040202@theshore.net> In-Reply-To: <4FA81669.5040202@theshore.net> Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 5/7/12 2:37 PM, Christopher S. Aker wrote: > This looks suspiciously like the problem described by Nai Xia in "mm: > page_check_address bug fix and make it validate subpages in huge pages" > - which never made it into mainline > that I can detect. > > We've rebuilt without CONFIG_HIGHPTE and are running our test again. We > shall see. No joy just disabling CONFIG_HIGHPTE. Triggered it on four boxes in no time. Bugs out exactly the same as before except the second BUG "scheduling while atomic" doesn't happen. On 5/7/12 1:17 PM, Konrad Rzeszutek Wilk wrote: > Hm, can you give more details on what parameters you are passing to > dom0 and the hypervisor so I can reproduce it? Xen and dom0 binaries and modules, and arguments here: http://theshore.net/~caker/xen/BUGS/lvm/ This is atop hardware RAID -- we haven't tested on anything other than Supermicro motherboards. Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:04:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU9s-0007uK-14; Mon, 07 May 2012 20:03:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU9q-0007uC-9s for xen-devel@lists.xen.org; Mon, 07 May 2012 20:03:46 +0000 Received: from [85.158.143.35:26037] by server-2.bemta-4.messagelabs.com id 0E/37-17550-1AA28AF4; Mon, 07 May 2012 20:03:45 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336421024!14367881!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15357 invoked from network); 7 May 2012 20:03:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 20:03:45 -0000 Received: by eekc4 with SMTP id c4so1121983eek.32 for ; Mon, 07 May 2012 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=P/mPIgppSnN6HbbnLmnaITxkW2XfeeAP+qBfz9Lju7Y=; b=XMzN1rWAMdHxb2WAsJ42IYuCQvVM+2IuYBqsBmQCIw50TG+bE+KW86YevLspQam02F ytlTbEZbeVTfQzSVAMuMsRBuQalwk+S6xVSG9Fu6IXQRDqr3l5AccIeKkrqLUDoOJEIZ Y9r/raDl/C0w3blkDkzSOBLGR7Z8g/AjQBPueCVbhbKex/TFx0D/Bj6iGLXZH8n/fH4a DSG34Yia4HQTdVmd6KG1pJ0mw4mPT7BUZWALGeL7OAF2KnokWZUkuDDEMt+nQCQZPCrP DiBi7rJj6Ts21U62jUBD/AA8cGzlhQ/hvTlN+hjn6iZNAgcsalOPU3HqIcNOdhsiQEAy m6yw== Received: by 10.213.108.195 with SMTP id g3mr642045ebp.11.1336421024270; Mon, 07 May 2012 13:03:44 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id d18sm91204512eeb.7.2012.05.07.13.03.42 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 13:03:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 21:03:38 +0100 From: Keir Fraser To: Pavel =?ISO-8859-2?B?TWF07Gph?= , Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0sjH26Iu1tku+sXU2sbaKqOjxtTw== In-Reply-To: <201205071918.09014.pavel@netsafe.cz> Mime-version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 18:18, "Pavel Mat=ECja" wrote: > On Mon 7. of May 2012 14:58:44 Keir Fraser wrote: >> Folks, >> = >> I have just tagged first release candidates for 4.0.4 and 4.1.3: >> = >> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) >> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) >> = >> Please test! >> = >> -- Keir > = > And which kernel should we use please? The kernel of your choice. We don't do kernels and hypervisors as matched pairs these days. A recent pv_ops kernel ought to work with either 4.0 or 4.1. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:04:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU9s-0007uK-14; Mon, 07 May 2012 20:03:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRU9q-0007uC-9s for xen-devel@lists.xen.org; Mon, 07 May 2012 20:03:46 +0000 Received: from [85.158.143.35:26037] by server-2.bemta-4.messagelabs.com id 0E/37-17550-1AA28AF4; Mon, 07 May 2012 20:03:45 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336421024!14367881!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15357 invoked from network); 7 May 2012 20:03:45 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 20:03:45 -0000 Received: by eekc4 with SMTP id c4so1121983eek.32 for ; Mon, 07 May 2012 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=P/mPIgppSnN6HbbnLmnaITxkW2XfeeAP+qBfz9Lju7Y=; b=XMzN1rWAMdHxb2WAsJ42IYuCQvVM+2IuYBqsBmQCIw50TG+bE+KW86YevLspQam02F ytlTbEZbeVTfQzSVAMuMsRBuQalwk+S6xVSG9Fu6IXQRDqr3l5AccIeKkrqLUDoOJEIZ Y9r/raDl/C0w3blkDkzSOBLGR7Z8g/AjQBPueCVbhbKex/TFx0D/Bj6iGLXZH8n/fH4a DSG34Yia4HQTdVmd6KG1pJ0mw4mPT7BUZWALGeL7OAF2KnokWZUkuDDEMt+nQCQZPCrP DiBi7rJj6Ts21U62jUBD/AA8cGzlhQ/hvTlN+hjn6iZNAgcsalOPU3HqIcNOdhsiQEAy m6yw== Received: by 10.213.108.195 with SMTP id g3mr642045ebp.11.1336421024270; Mon, 07 May 2012 13:03:44 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id d18sm91204512eeb.7.2012.05.07.13.03.42 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 13:03:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 07 May 2012 21:03:38 +0100 From: Keir Fraser To: Pavel =?ISO-8859-2?B?TWF07Gph?= , Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0sjH26Iu1tku+sXU2sbaKqOjxtTw== In-Reply-To: <201205071918.09014.pavel@netsafe.cz> Mime-version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 18:18, "Pavel Mat=ECja" wrote: > On Mon 7. of May 2012 14:58:44 Keir Fraser wrote: >> Folks, >> = >> I have just tagged first release candidates for 4.0.4 and 4.1.3: >> = >> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) >> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) >> = >> Please test! >> = >> -- Keir > = > And which kernel should we use please? The kernel of your choice. We don't do kernels and hypervisors as matched pairs these days. A recent pv_ops kernel ought to work with either 4.0 or 4.1. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:08:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:08:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUEQ-00083H-N8; Mon, 07 May 2012 20:08:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUEP-00083B-R6 for xen-devel@lists.xen.org; Mon, 07 May 2012 20:08:29 +0000 Received: from [85.158.143.35:15912] by server-2.bemta-4.messagelabs.com id 29/B9-17550-DBB28AF4; Mon, 07 May 2012 20:08:29 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336421308!11835245!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31160 invoked from network); 7 May 2012 20:08:28 -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; 7 May 2012 20:08:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,545,1330905600"; d="scan'208";a="12339207" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 20:08:08 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 21:08:07 +0100 Message-ID: <4FA82BA6.7040508@citrix.com> Date: Mon, 7 May 2012 21:08:06 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 13:58, Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! > > -- Keir XenServer trunk is currently running on xen-4.1-testing tip (minus the 3 changesets today) (plus a patch queue). I am not aware of any outstanding hypervisor issues. ~Andrew > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:08:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:08:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUEQ-00083H-N8; Mon, 07 May 2012 20:08:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUEP-00083B-R6 for xen-devel@lists.xen.org; Mon, 07 May 2012 20:08:29 +0000 Received: from [85.158.143.35:15912] by server-2.bemta-4.messagelabs.com id 29/B9-17550-DBB28AF4; Mon, 07 May 2012 20:08:29 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336421308!11835245!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31160 invoked from network); 7 May 2012 20:08:28 -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; 7 May 2012 20:08:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,545,1330905600"; d="scan'208";a="12339207" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 20:08:08 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 7 May 2012 21:08:07 +0100 Message-ID: <4FA82BA6.7040508@citrix.com> Date: Mon, 7 May 2012 21:08:06 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 13:58, Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! > > -- Keir XenServer trunk is currently running on xen-4.1-testing tip (minus the 3 changesets today) (plus a patch queue). I am not aware of any outstanding hypervisor issues. ~Andrew > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:53:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:53:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUvo-0008OE-Ml; Mon, 07 May 2012 20:53:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUvn-0008O9-48 for xen-devel@lists.xen.org; Mon, 07 May 2012 20:53:19 +0000 Received: from [85.158.139.83:65353] by server-2.bemta-5.messagelabs.com id 4E/C4-17016-E3638AF4; Mon, 07 May 2012 20:53:18 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-8.tower-182.messagelabs.com!1336423997!15895668!1 X-Originating-IP: [129.234.248.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzNjc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14683 invoked from network); 7 May 2012 20:53:17 -0000 Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 20:53:17 -0000 Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q47Kr2YL030778; Mon, 7 May 2012 21:53:06 +0100 Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134]) by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q47KqkcX016708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 21:52:46 +0100 Received: from vega-b.dur.ac.uk (localhost [127.0.0.1]) by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q47KqkY6015649; Mon, 7 May 2012 21:52:46 +0100 Received: from localhost (dcl0may@localhost) by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q47KqkQ8015645; Mon, 7 May 2012 21:52:46 +0100 Date: Mon, 7 May 2012 21:52:46 +0100 (BST) From: M A Young To: Keir Fraser In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q47Kr2YL030778 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 7 May 2012, Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! I am seeing problems building 4.1.3-rc1 on Fedora 17, though it might be changes in Fedora 17 rather than xen changes that have triggered it. When trying to compile objects such as scheduler.c in tools/blktap2/drivers I get the error /usr/include/features.h:329:3: error: #warning _FORTIFY_SOURCE requested but disabled [-Werror=cpp] On checking that file I see that this is because -Wp,-D_FORTIFY_SOURCE=2 is requested with -O0 . Fedora 17 decides to warn about this and it becomes an error as -Werror is specified. This conflict occurs because of the line CFLAGS += -Werror -g -O0 in tools/blktap2/drivers/Makefile I can of course work around the problem in my build, but I was wondering if optimization level 0 is still necessary for this code. I think the only other place -O0 is used now is tools/security/Makefile which I assume will also trigger the problem. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 20:53:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 20:53:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUvo-0008OE-Ml; Mon, 07 May 2012 20:53:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRUvn-0008O9-48 for xen-devel@lists.xen.org; Mon, 07 May 2012 20:53:19 +0000 Received: from [85.158.139.83:65353] by server-2.bemta-5.messagelabs.com id 4E/C4-17016-E3638AF4; Mon, 07 May 2012 20:53:18 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-8.tower-182.messagelabs.com!1336423997!15895668!1 X-Originating-IP: [129.234.248.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzNjc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14683 invoked from network); 7 May 2012 20:53:17 -0000 Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 20:53:17 -0000 Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q47Kr2YL030778; Mon, 7 May 2012 21:53:06 +0100 Received: from vega-b.dur.ac.uk (vega-b.dur.ac.uk [129.234.250.134]) by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q47KqkcX016708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 21:52:46 +0100 Received: from vega-b.dur.ac.uk (localhost [127.0.0.1]) by vega-b.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q47KqkY6015649; Mon, 7 May 2012 21:52:46 +0100 Received: from localhost (dcl0may@localhost) by vega-b.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q47KqkQ8015645; Mon, 7 May 2012 21:52:46 +0100 Date: Mon, 7 May 2012 21:52:46 +0100 (BST) From: M A Young To: Keir Fraser In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q47Kr2YL030778 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 7 May 2012, Keir Fraser wrote: > Folks, > > I have just tagged first release candidates for 4.0.4 and 4.1.3: > > http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) > > Please test! I am seeing problems building 4.1.3-rc1 on Fedora 17, though it might be changes in Fedora 17 rather than xen changes that have triggered it. When trying to compile objects such as scheduler.c in tools/blktap2/drivers I get the error /usr/include/features.h:329:3: error: #warning _FORTIFY_SOURCE requested but disabled [-Werror=cpp] On checking that file I see that this is because -Wp,-D_FORTIFY_SOURCE=2 is requested with -O0 . Fedora 17 decides to warn about this and it becomes an error as -Werror is specified. This conflict occurs because of the line CFLAGS += -Werror -g -O0 in tools/blktap2/drivers/Makefile I can of course work around the problem in my build, but I was wondering if optimization level 0 is still necessary for this code. I think the only other place -O0 is used now is tools/security/Makefile which I assume will also trigger the problem. Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:20:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21:20:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVLz-0000FU-AB; Mon, 07 May 2012 21:20:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVLx-0000FP-58 for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:20:21 +0000 Received: from [85.158.138.51:59690] by server-11.bemta-3.messagelabs.com id B7/4F-18894-49C38AF4; Mon, 07 May 2012 21:20:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336425619!25754203!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12233 invoked from network); 7 May 2012 21:20:19 -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; 7 May 2012 21:20:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,546,1330905600"; d="scan'208";a="12340837" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 21: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; Mon, 7 May 2012 22:20:18 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRVLu-0002w1-EC; Mon, 07 May 2012 21:20:18 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRVLu-0000Gf-6Z; Mon, 07 May 2012 22:20:18 +0100 To: Message-ID: From: xen.org Date: Mon, 7 May 2012 22:20:18 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12795: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12795 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12795/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 12784 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail like 12769 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-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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-credit2 15 guest-stop 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-i386-i386-xl-win 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install 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 version targeted for testing: xen 92c59e870d72 baseline version: xen d8fd425b60d3 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=92c59e870d72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 92c59e870d72 + branch=xen-4.0-testing + revision=92c59e870d72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.0-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.0-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git ++ : daily-cron.xen-4.0-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git + info_linux_tree xen-4.0-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r 92c59e870d72 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 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:20:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21:20:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVLz-0000FU-AB; Mon, 07 May 2012 21:20:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVLx-0000FP-58 for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:20:21 +0000 Received: from [85.158.138.51:59690] by server-11.bemta-3.messagelabs.com id B7/4F-18894-49C38AF4; Mon, 07 May 2012 21:20:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336425619!25754203!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12233 invoked from network); 7 May 2012 21:20:19 -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; 7 May 2012 21:20:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,546,1330905600"; d="scan'208";a="12340837" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 21: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; Mon, 7 May 2012 22:20:18 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRVLu-0002w1-EC; Mon, 07 May 2012 21:20:18 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRVLu-0000Gf-6Z; Mon, 07 May 2012 22:20:18 +0100 To: Message-ID: From: xen.org Date: Mon, 7 May 2012 22:20:18 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 12795: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12795 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12795/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 guest-start fail REGR. vs. 12784 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail like 12769 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-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-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-credit2 15 guest-stop 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-i386-i386-xl-win 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install 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 version targeted for testing: xen 92c59e870d72 baseline version: xen d8fd425b60d3 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-i386-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.0-testing + revision=92c59e870d72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 92c59e870d72 + branch=xen-4.0-testing + revision=92c59e870d72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.0-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/staging/xen-4.0-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.0-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.0-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.0-testing.git ++ : daily-cron.xen-4.0-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.0-testing.git + info_linux_tree xen-4.0-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.0-testing.hg + hg push -r 92c59e870d72 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 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:26:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21: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 ) id 1SRVRE-0000NO-2W; Mon, 07 May 2012 21:25:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVRD-0000NG-07 for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:25:47 +0000 Received: from [85.158.143.99:11639] by server-3.bemta-4.messagelabs.com id DB/E1-05853-ADD38AF4; Mon, 07 May 2012 21:25:46 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-7.tower-216.messagelabs.com!1336425942!23516242!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4655 invoked from network); 7 May 2012 21:25:43 -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; 7 May 2012 21:25:43 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q47LPaig024480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2012 17:25:36 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q47LPapV024478; Mon, 7 May 2012 17:25:36 -0400 Date: Mon, 7 May 2012 17:25:36 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120507212536.GA24344@andromeda.dapyr.net> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > domain. Then when blkfront un-share them, also removes the > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > We do it so that when the source and the destination domain are the same > > > (blkfront connected to blkback in the same domain) we can more easily So I've been testing it with my mini config and it worked great. But when I started using a distro .config it blew up. I am not really sure why it does that, but here is the dmesg and .config. Nothing fancy with the guest config: cat /crash.xm | grep -v \# memory = 4096 name = "OL6_X86_64_PVHVM" vcpus=12 vif = [ 'mac=00:0f:4b:00:00:72,bridge=switch' ] disk= ['phy:/dev/guests/OL6_X86_64_PVHVM,hda,w'] vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] vnc=1 vnclisten="0.0.0.0" hvm_loader="/usr/bin/pygrub" This is the #testing branch, but just using my #linux-next along with stable/for-jens-3.5 should reproduce this. I added a bit of debug statement and found that 0xffffffffffffffff was passed in as a PFN in the set_phys_to_machine. Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc6bug+ (root@g-oel6.dumpdata.com) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #2 SMP Mon May 7 16:34:26 EDT 2012 Command line: ro root=/dev/mapper/vg_goel6-lv_root rd_LVM_LV=vg_goel6/lv_root rd_LVM_LV=vg_goel6/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS0,115200 debug loglevel=8 ACPI in unprivileged domain disabled E820_RAM 100000->100800, last OK PFN is 100000 BIOS-provided physical RAM map: Xen: 0000000000000000 - 00000000000a0000 (usable) Xen: 00000000000a0000 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000100800000 (usable) NX (Execute Disable) protection: active DMI not present or invalid. e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) No AGP bridge found last_pfn = 0x100800 max_arch_pfn = 0x400000000 last_pfn = 0x100000 max_arch_pfn = 0x400000000 initial memory mapped : 0 - 0477c000 Base memory trampoline at [ffff88000009b000] 9b000 size 20480 init_memory_mapping: 0000000000000000-0000000100000000 0000000000 - 0100000000 page 4k kernel direct mapping tables up to 100000000 @ 7fb000-1000000 xen: setting RW the range fd0000 - 1000000 init_memory_mapping: 0000000100000000-0000000100800000 0100000000 - 0100800000 page 4k kernel direct mapping tables up to 100800000 @ ff7f6000-100000000 xen: setting RW the range ff7fb000 - 100000000 RAMDISK: 02136000 - 0477c000 No NUMA configuration found Faking a node at 0000000000000000-0000000100800000 Initmem setup node 0 0000000000000000-0000000100800000 NODE_DATA [00000000fffda000 - 00000000ffffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00100800 Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x000000a0 0: 0x00000100 -> 0x00100800 On node 0 totalpages: 1050512 DMA zone: 56 pages used for memmap DMA zone: 2010 pages reserved DMA zone: 1918 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 1030200 pages, LIFO batch:31 Normal zone: 28 pages used for memmap Normal zone: 2020 pages, LIFO batch:0 SFI: Simple Firmware Interface v0.81 http://simplefirmware.org SMP: Allowing 12 CPUs, 0 hotplug CPUs No local APIC present APIC: disable apic facility APIC: switched to apic NOOP nr_irqs_gsi: 16 PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 PCI: Warning: Cannot find a gap in the 32bit address range PCI: Unassigned devices with 32bit resource registers may break! Allocating PCI resources starting at 100900000 (gap: 100900000:400000) Booting paravirtualized kernel on Xen Xen version: 4.1-120507 (preserve-AD) setup_percpu: NR_CPUS:4096 nr_cpumask_bits:12 nr_cpu_ids:12 nr_node_ids:1 PERCPU: Embedded 28 pages/cpu @ffff8800ffe3a000 s82304 r8192 d24192 u114688 pcpu-alloc: s82304 r8192 d24192 u114688 alloc=28*4096 pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 Built 1 zonelists in Node order, mobility grouping on. Total pages: 1034138 Policy zone: Normal Kernel command line: ro root=/dev/mapper/vg_goel6-lv_root rd_LVM_LV=vg_goel6/lv_root rd_LVM_LV=vg_goel6/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS0,115200 debug loglevel=8 PID hash table entries: 4096 (order: 3, 32768 bytes) Checking aperture... No AGP bridge found Calgary: detecting Calgary via BIOS EBDA area Calgary: Unable to locate Rio Grande table in EBDA - bailing! Memory: 3997660k/4202496k available (5301k kernel code, 448k absent, 204388k reserved, 3502k data, 1492k init) Hierarchical RCU implementation. NR_IRQS:262400 nr_irqs:368 16 Console: colour dummy device 80x25 console [tty0] enabled console [hvc0] enabled console [ttyS0] enabled allocated 17301504 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2294.526 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.05 BogoMIPS (lpj=2294526) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys net_cls Initializing cgroup subsys blkio ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ftrace: allocating 21183 entries in 83 pages cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 45 no PMU driver, software events only. NMI watchdog: disabled (cpu0): hardware events not enabled installing Xen timer for CPU 1 cpu 1 spinlock event irq 24 SMP alternatives: switching to SMP code NMI watchdog: disabled (cpu1): hardware events not enabled installing Xen timer for CPU 2 cpu 2 spinlock event irq 31 NMI watchdog: disabled (cpu2): hardware events not enabled installing Xen timer for CPU 3 cpu 3 spinlock event irq 38 NMI watchdog: disabled (cpu3): hardware events not enabled installing Xen timer for CPU 4 cpu 4 spinlock event irq 45 NMI watchdog: disabled (cpu4): hardware events not enabled installing Xen timer for CPU 5 cpu 5 spinlock event irq 52 NMI watchdog: disabled (cpu5): hardware events not enabled installing Xen timer for CPU 6 cpu 6 spinlock event irq 59 NMI watchdog: disabled (cpu6): hardware events not enabled installing Xen timer for CPU 7 cpu 7 spinlock event irq 66 NMI watchdog: disabled (cpu7): hardware events not enabled installing Xen timer for CPU 8 cpu 8 spinlock event irq 73 NMI watchdog: disabled (cpu8): hardware events not enabled installing Xen timer for CPU 9 cpu 9 spinlock event irq 80 NMI watchdog: disabled (cpu9): hardware events not enabled installing Xen timer for CPU 10 cpu 10 spinlock event irq 87 NMI watchdog: disabled (cpu10): hardware events not enabled installing Xen timer for CPU 11 cpu 11 spinlock event irq 94 NMI watchdog: disabled (cpu11): hardware events not enabled Brought up 12 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized dummy: NET: Registered protocol family 16 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 2048 (order: 4, 65536 bytes) UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) NET: Registered protocol family 1 PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 39192k freed PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing 64MB software IO TLB between ffff8800f7000000 - ffff8800fb000000 software IO TLB at phys 0xf7000000 - 0xfb000000 platform rtc_cmos: registered platform RTC device (no PNP device found) audit: initializing netlink socket (disabled) type=2000 audit(1336425310.959:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 7884 SELinux: Registering netfilter hooks alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered (default) io scheduler cfq registered pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 Console: switching to colour frame buffer device 100x37 intel_idle: does not run on family 6 model 45 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 brd: module loaded loop: module loaded Fixed MDIO Bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice input: Xen Virtual Keyboard as /devices/virtual/input/input0 input: Xen Virtual Pointer as /devices/virtual/input/input1 rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 usbcore: registered new interface driver usbhid usbhid: USB HID core driver zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Registering the dns_resolver key type registered taskstats version 1 IMA: No TPM chip found, activating TPM-bypass! XENBUS: Device with no driver: device/vbd/768 XENBUS: Device with no driver: device/vif/0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Initializing network drop monitor service Freeing unused kernel memory: 1492k freed dracut: dracut-004-256.0.1.el6 dracut: rd_NO_LUKS: removing cryptoluks activation device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com udev: starting version 147 udevd (116): /proc/116/oom_adj is deprecated, please use /proc/116/oom_score_adj instead. dracut: Starting plymouth daemon blkfront: xvda: barrier or flush: disabled xvda: xvda1 xvda2 dracut: Scanning devices xvda2 for LVM logical volumes vg_goel6/lv_root vg_goel6/lv_swap dracut: inactive '/dev/vg_goel6/lv_root' [37.54 GiB] inherit dracut: inactive '/dev/vg_goel6/lv_swap' [1.97 GiB] inherit EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) dracut: Mounted root filesystem /dev/mapper/vg_goel6-lv_root dracut: Loading SELinux policy type=1404 audit(1336425312.753:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 SELinux: 2048 avtab hash slots, 225597 rules. SELinux: 2048 avtab hash slots, 225597 rules. SELinux: 9 users, 12 roles, 3577 types, 179 bools, 1 sens, 1024 cats SELinux: 81 classes, 225597 rules SELinux: Permission audit_access in class file not defined in policy. SELinux: Permission audit_access in class dir not defined in policy. SELinux: Permission execmod in class dir not defined in policy. SELinux: Permission audit_access in class lnk_file not defined in policy. SELinux: Permission open in class lnk_file not defined in policy. SELinux: Permission execmod in class lnk_file not defined in policy. SELinux: Permission audit_access in class chr_file not defined in policy. SELinux: Permission audit_access in class blk_file not defined in policy. SELinux: Permission execmod in class blk_file not defined in policy. SELinux: Permission audit_access in class sock_file not defined in policy. SELinux: Permission execmod in class sock_file not defined in policy. SELinux: Permission audit_access in class fifo_file not defined in policy. SELinux: Permission execmod in class fifo_file not defined in policy. SELinux: Permission syslog in class capability2 not defined in policy. SELinux: the above unknown classes and permissions will be allowed SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev devtmpfs, type devtmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses transition SIDs SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev securityfs, type securityfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev dm-0, type ext4), uses xattr type=1403 audit(1336425313.280:3): policy loaded auid=4294967295 ses=4294967295 dracut: dracut: Switching root SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts readahead: starting udev: starting version 147 input: PC Speaker as /devices/platform/pcspkr/input/input2 alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) Initialising Xen virtual ethernet driver. vif vif-0: single tx ring vif vif-0: single rx ring vif vif-0: single event channel, irq = 105 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky EXT4-fs (dm-0): re-mounted. Opts: (null) ------------[ cut here ]------------ kernel BUG at arch/x86/xen/p2m.c:634! invalid opcode: 0000 [#1] SMP CPU 0 Modules linked in: vhost_net macvtap macvlan tun uinput xen_netfront coretemp hwmon crc32c_intel ghash_clmulni_intel aesni_intel cryptd aes_x86_64 aes_generic pcspkr ext4 mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper/0 Not tainted 3.4.0-rc6bug+ #2 RIP: e030:[] [] __set_phys_to_machine+0x108/0x120 RSP: e02b:ffff8800ffe3ddb8 EFLAGS: 00010887 RAX: 7fffffffffffffff RBX: ffffffffffffffff RCX: 00000000000001ee RDX: 7fffffffffffffff RSI: 7fffffffffffffff RDI: ffffffffffffffff RBP: ffff8800ffe3ddb8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 7fffffffffffffff R13: ffff8800035be000 R14: 0000000000000019 R15: 000000000000240d FS: 00007fc24492c7e0(0000) GS:ffff8800ffe3a000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fc243c2f358 CR3: 0000000003a55000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/0 (pid: 0, threadinfo ffffffff817a2000, task ffffffff817b5020) Stack: ffff8800ffe3ddd8 ffffffff8100b431 0000000000000000 ffff8800035bf6d8 ffff8800ffe3de48 ffffffffa0034f04 ffff8800035ad000 ffff880003615378 0000000000000000 0000240e00000000 ffff8800035bf660 000000000000000d Call Trace: [] set_phys_to_machine+0x21/0x50 [] blkif_interrupt+0x114/0x360 [xen_blkfront] [] handle_irq_event_percpu+0x6d/0x220 [] handle_irq_event+0x51/0x80 [] handle_edge_irq+0x80/0x140 [] __xen_evtchn_do_upcall+0x1b1/0x280 [] xen_evtchn_do_upcall+0x2f/0x50 [] xen_do_hypervisor_callback+0x1e/0x30 [] ? hypercall_page+0x3aa/0x1000 [] ? hypercall_page+0x3aa/0x1000 [] ? xen_safe_halt+0x10/0x20 [] ? default_idle+0x5d/0x1b0 [] ? cpu_idle+0xd9/0x120 [] ? rest_init+0x75/0x80 [] ? start_kernel+0x3ec/0x3f9 [] ? kernel_init+0x284/0x284 [] ? x86_64_start_reservations+0x131/0x136 [] ? xen_start_kernel+0x6b0/0x6b7 Code: 0f 94 c0 c3 0f 1f 80 00 00 00 00 b8 01 00 00 00 c9 c3 48 83 fe ff 74 f3 48 39 f7 74 ee 0f 0b 0f 1f 40 00 eb fa 48 83 fe ff 74 e0 <0f> 0b 66 0f 1f 44 00 00 eb f8 66 66 66 66 66 2e 0f 1f 84 00 00 RIP [] __set_phys_to_machine+0x108/0x120 RSP ---[ end trace 595ea88467dca615 ]--- Kernel panic - not syncing: Fatal exception in interrupt > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:26:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21: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 ) id 1SRVRE-0000NO-2W; Mon, 07 May 2012 21:25:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVRD-0000NG-07 for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:25:47 +0000 Received: from [85.158.143.99:11639] by server-3.bemta-4.messagelabs.com id DB/E1-05853-ADD38AF4; Mon, 07 May 2012 21:25:46 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-7.tower-216.messagelabs.com!1336425942!23516242!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4655 invoked from network); 7 May 2012 21:25:43 -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; 7 May 2012 21:25:43 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q47LPaig024480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2012 17:25:36 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q47LPapV024478; Mon, 7 May 2012 17:25:36 -0400 Date: Mon, 7 May 2012 17:25:36 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120507212536.GA24344@andromeda.dapyr.net> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > domain. Then when blkfront un-share them, also removes the > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > We do it so that when the source and the destination domain are the same > > > (blkfront connected to blkback in the same domain) we can more easily So I've been testing it with my mini config and it worked great. But when I started using a distro .config it blew up. I am not really sure why it does that, but here is the dmesg and .config. Nothing fancy with the guest config: cat /crash.xm | grep -v \# memory = 4096 name = "OL6_X86_64_PVHVM" vcpus=12 vif = [ 'mac=00:0f:4b:00:00:72,bridge=switch' ] disk= ['phy:/dev/guests/OL6_X86_64_PVHVM,hda,w'] vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] vnc=1 vnclisten="0.0.0.0" hvm_loader="/usr/bin/pygrub" This is the #testing branch, but just using my #linux-next along with stable/for-jens-3.5 should reproduce this. I added a bit of debug statement and found that 0xffffffffffffffff was passed in as a PFN in the set_phys_to_machine. Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.4.0-rc6bug+ (root@g-oel6.dumpdata.com) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #2 SMP Mon May 7 16:34:26 EDT 2012 Command line: ro root=/dev/mapper/vg_goel6-lv_root rd_LVM_LV=vg_goel6/lv_root rd_LVM_LV=vg_goel6/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS0,115200 debug loglevel=8 ACPI in unprivileged domain disabled E820_RAM 100000->100800, last OK PFN is 100000 BIOS-provided physical RAM map: Xen: 0000000000000000 - 00000000000a0000 (usable) Xen: 00000000000a0000 - 0000000000100000 (reserved) Xen: 0000000000100000 - 0000000100800000 (usable) NX (Execute Disable) protection: active DMI not present or invalid. e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) No AGP bridge found last_pfn = 0x100800 max_arch_pfn = 0x400000000 last_pfn = 0x100000 max_arch_pfn = 0x400000000 initial memory mapped : 0 - 0477c000 Base memory trampoline at [ffff88000009b000] 9b000 size 20480 init_memory_mapping: 0000000000000000-0000000100000000 0000000000 - 0100000000 page 4k kernel direct mapping tables up to 100000000 @ 7fb000-1000000 xen: setting RW the range fd0000 - 1000000 init_memory_mapping: 0000000100000000-0000000100800000 0100000000 - 0100800000 page 4k kernel direct mapping tables up to 100800000 @ ff7f6000-100000000 xen: setting RW the range ff7fb000 - 100000000 RAMDISK: 02136000 - 0477c000 No NUMA configuration found Faking a node at 0000000000000000-0000000100800000 Initmem setup node 0 0000000000000000-0000000100800000 NODE_DATA [00000000fffda000 - 00000000ffffffff] Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00100800 Movable zone start PFN for each node Early memory PFN ranges 0: 0x00000010 -> 0x000000a0 0: 0x00000100 -> 0x00100800 On node 0 totalpages: 1050512 DMA zone: 56 pages used for memmap DMA zone: 2010 pages reserved DMA zone: 1918 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 1030200 pages, LIFO batch:31 Normal zone: 28 pages used for memmap Normal zone: 2020 pages, LIFO batch:0 SFI: Simple Firmware Interface v0.81 http://simplefirmware.org SMP: Allowing 12 CPUs, 0 hotplug CPUs No local APIC present APIC: disable apic facility APIC: switched to apic NOOP nr_irqs_gsi: 16 PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 PCI: Warning: Cannot find a gap in the 32bit address range PCI: Unassigned devices with 32bit resource registers may break! Allocating PCI resources starting at 100900000 (gap: 100900000:400000) Booting paravirtualized kernel on Xen Xen version: 4.1-120507 (preserve-AD) setup_percpu: NR_CPUS:4096 nr_cpumask_bits:12 nr_cpu_ids:12 nr_node_ids:1 PERCPU: Embedded 28 pages/cpu @ffff8800ffe3a000 s82304 r8192 d24192 u114688 pcpu-alloc: s82304 r8192 d24192 u114688 alloc=28*4096 pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 Built 1 zonelists in Node order, mobility grouping on. Total pages: 1034138 Policy zone: Normal Kernel command line: ro root=/dev/mapper/vg_goel6-lv_root rd_LVM_LV=vg_goel6/lv_root rd_LVM_LV=vg_goel6/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=ttyS0,115200 debug loglevel=8 PID hash table entries: 4096 (order: 3, 32768 bytes) Checking aperture... No AGP bridge found Calgary: detecting Calgary via BIOS EBDA area Calgary: Unable to locate Rio Grande table in EBDA - bailing! Memory: 3997660k/4202496k available (5301k kernel code, 448k absent, 204388k reserved, 3502k data, 1492k init) Hierarchical RCU implementation. NR_IRQS:262400 nr_irqs:368 16 Console: colour dummy device 80x25 console [tty0] enabled console [hvc0] enabled console [ttyS0] enabled allocated 17301504 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2294.526 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.05 BogoMIPS (lpj=2294526) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys net_cls Initializing cgroup subsys blkio ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ftrace: allocating 21183 entries in 83 pages cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 45 no PMU driver, software events only. NMI watchdog: disabled (cpu0): hardware events not enabled installing Xen timer for CPU 1 cpu 1 spinlock event irq 24 SMP alternatives: switching to SMP code NMI watchdog: disabled (cpu1): hardware events not enabled installing Xen timer for CPU 2 cpu 2 spinlock event irq 31 NMI watchdog: disabled (cpu2): hardware events not enabled installing Xen timer for CPU 3 cpu 3 spinlock event irq 38 NMI watchdog: disabled (cpu3): hardware events not enabled installing Xen timer for CPU 4 cpu 4 spinlock event irq 45 NMI watchdog: disabled (cpu4): hardware events not enabled installing Xen timer for CPU 5 cpu 5 spinlock event irq 52 NMI watchdog: disabled (cpu5): hardware events not enabled installing Xen timer for CPU 6 cpu 6 spinlock event irq 59 NMI watchdog: disabled (cpu6): hardware events not enabled installing Xen timer for CPU 7 cpu 7 spinlock event irq 66 NMI watchdog: disabled (cpu7): hardware events not enabled installing Xen timer for CPU 8 cpu 8 spinlock event irq 73 NMI watchdog: disabled (cpu8): hardware events not enabled installing Xen timer for CPU 9 cpu 9 spinlock event irq 80 NMI watchdog: disabled (cpu9): hardware events not enabled installing Xen timer for CPU 10 cpu 10 spinlock event irq 87 NMI watchdog: disabled (cpu10): hardware events not enabled installing Xen timer for CPU 11 cpu 11 spinlock event irq 94 NMI watchdog: disabled (cpu11): hardware events not enabled Brought up 12 CPUs devtmpfs: initialized Grant tables using version 2 layout. Grant table initialized dummy: NET: Registered protocol family 16 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 2048 (order: 4, 65536 bytes) UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) NET: Registered protocol family 1 PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 39192k freed PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing 64MB software IO TLB between ffff8800f7000000 - ffff8800fb000000 software IO TLB at phys 0xf7000000 - 0xfb000000 platform rtc_cmos: registered platform RTC device (no PNP device found) audit: initializing netlink socket (disabled) type=2000 audit(1336425310.959:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 7884 SELinux: Registering netfilter hooks alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered (default) io scheduler cfq registered pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 Console: switching to colour frame buffer device 100x37 intel_idle: does not run on family 6 model 45 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 brd: module loaded loop: module loaded Fixed MDIO Bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice input: Xen Virtual Keyboard as /devices/virtual/input/input0 input: Xen Virtual Pointer as /devices/virtual/input/input1 rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 usbcore: registered new interface driver usbhid usbhid: USB HID core driver zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Registering the dns_resolver key type registered taskstats version 1 IMA: No TPM chip found, activating TPM-bypass! XENBUS: Device with no driver: device/vbd/768 XENBUS: Device with no driver: device/vif/0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Initializing network drop monitor service Freeing unused kernel memory: 1492k freed dracut: dracut-004-256.0.1.el6 dracut: rd_NO_LUKS: removing cryptoluks activation device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com udev: starting version 147 udevd (116): /proc/116/oom_adj is deprecated, please use /proc/116/oom_score_adj instead. dracut: Starting plymouth daemon blkfront: xvda: barrier or flush: disabled xvda: xvda1 xvda2 dracut: Scanning devices xvda2 for LVM logical volumes vg_goel6/lv_root vg_goel6/lv_swap dracut: inactive '/dev/vg_goel6/lv_root' [37.54 GiB] inherit dracut: inactive '/dev/vg_goel6/lv_swap' [1.97 GiB] inherit EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) dracut: Mounted root filesystem /dev/mapper/vg_goel6-lv_root dracut: Loading SELinux policy type=1404 audit(1336425312.753:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 SELinux: 2048 avtab hash slots, 225597 rules. SELinux: 2048 avtab hash slots, 225597 rules. SELinux: 9 users, 12 roles, 3577 types, 179 bools, 1 sens, 1024 cats SELinux: 81 classes, 225597 rules SELinux: Permission audit_access in class file not defined in policy. SELinux: Permission audit_access in class dir not defined in policy. SELinux: Permission execmod in class dir not defined in policy. SELinux: Permission audit_access in class lnk_file not defined in policy. SELinux: Permission open in class lnk_file not defined in policy. SELinux: Permission execmod in class lnk_file not defined in policy. SELinux: Permission audit_access in class chr_file not defined in policy. SELinux: Permission audit_access in class blk_file not defined in policy. SELinux: Permission execmod in class blk_file not defined in policy. SELinux: Permission audit_access in class sock_file not defined in policy. SELinux: Permission execmod in class sock_file not defined in policy. SELinux: Permission audit_access in class fifo_file not defined in policy. SELinux: Permission execmod in class fifo_file not defined in policy. SELinux: Permission syslog in class capability2 not defined in policy. SELinux: the above unknown classes and permissions will be allowed SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev devtmpfs, type devtmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses transition SIDs SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev securityfs, type securityfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev dm-0, type ext4), uses xattr type=1403 audit(1336425313.280:3): policy loaded auid=4294967295 ses=4294967295 dracut: dracut: Switching root SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts readahead: starting udev: starting version 147 input: PC Speaker as /devices/platform/pcspkr/input/input2 alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) Initialising Xen virtual ethernet driver. vif vif-0: single tx ring vif vif-0: single rx ring vif vif-0: single event channel, irq = 105 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky EXT4-fs (dm-0): re-mounted. Opts: (null) ------------[ cut here ]------------ kernel BUG at arch/x86/xen/p2m.c:634! invalid opcode: 0000 [#1] SMP CPU 0 Modules linked in: vhost_net macvtap macvlan tun uinput xen_netfront coretemp hwmon crc32c_intel ghash_clmulni_intel aesni_intel cryptd aes_x86_64 aes_generic pcspkr ext4 mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper/0 Not tainted 3.4.0-rc6bug+ #2 RIP: e030:[] [] __set_phys_to_machine+0x108/0x120 RSP: e02b:ffff8800ffe3ddb8 EFLAGS: 00010887 RAX: 7fffffffffffffff RBX: ffffffffffffffff RCX: 00000000000001ee RDX: 7fffffffffffffff RSI: 7fffffffffffffff RDI: ffffffffffffffff RBP: ffff8800ffe3ddb8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 7fffffffffffffff R13: ffff8800035be000 R14: 0000000000000019 R15: 000000000000240d FS: 00007fc24492c7e0(0000) GS:ffff8800ffe3a000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fc243c2f358 CR3: 0000000003a55000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/0 (pid: 0, threadinfo ffffffff817a2000, task ffffffff817b5020) Stack: ffff8800ffe3ddd8 ffffffff8100b431 0000000000000000 ffff8800035bf6d8 ffff8800ffe3de48 ffffffffa0034f04 ffff8800035ad000 ffff880003615378 0000000000000000 0000240e00000000 ffff8800035bf660 000000000000000d Call Trace: [] set_phys_to_machine+0x21/0x50 [] blkif_interrupt+0x114/0x360 [xen_blkfront] [] handle_irq_event_percpu+0x6d/0x220 [] handle_irq_event+0x51/0x80 [] handle_edge_irq+0x80/0x140 [] __xen_evtchn_do_upcall+0x1b1/0x280 [] xen_evtchn_do_upcall+0x2f/0x50 [] xen_do_hypervisor_callback+0x1e/0x30 [] ? hypercall_page+0x3aa/0x1000 [] ? hypercall_page+0x3aa/0x1000 [] ? xen_safe_halt+0x10/0x20 [] ? default_idle+0x5d/0x1b0 [] ? cpu_idle+0xd9/0x120 [] ? rest_init+0x75/0x80 [] ? start_kernel+0x3ec/0x3f9 [] ? kernel_init+0x284/0x284 [] ? x86_64_start_reservations+0x131/0x136 [] ? xen_start_kernel+0x6b0/0x6b7 Code: 0f 94 c0 c3 0f 1f 80 00 00 00 00 b8 01 00 00 00 c9 c3 48 83 fe ff 74 f3 48 39 f7 74 ee 0f 0b 0f 1f 40 00 eb fa 48 83 fe ff 74 e0 <0f> 0b 66 0f 1f 44 00 00 eb f8 66 66 66 66 66 2e 0f 1f 84 00 00 RIP [] __set_phys_to_machine+0x108/0x120 RSP ---[ end trace 595ea88467dca615 ]--- Kernel panic - not syncing: Fatal exception in interrupt > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:38:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21: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 ) id 1SRVch-0000am-GK; Mon, 07 May 2012 21:37:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVcf-0000ah-IZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:37:38 +0000 Received: from [85.158.139.83:56117] by server-1.bemta-5.messagelabs.com id 6E/63-28458-0A048AF4; Mon, 07 May 2012 21:37:36 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1336426645!27204262!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=3.5 required=7.0 tests=UNIQUE_WORDS, UPPERCASE_75_100 X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11097 invoked from network); 7 May 2012 21:37:27 -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; 7 May 2012 21:37:27 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q47LbGwn024843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2012 17:37:16 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q47LbGuE024841; Mon, 7 May 2012 17:37:16 -0400 Date: Mon, 7 May 2012 17:37:16 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120507213716.GA24819@andromeda.dapyr.net> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Mutt/1.5.9i Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:25:36PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > > domain. Then when blkfront un-share them, also removes the > > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > > > We do it so that when the source and the destination domain are the same > > > > (blkfront connected to blkback in the same domain) we can more easily > > So I've been testing it with my mini config and it worked great. But > when I started using a distro .config it blew up. I am not really > sure why it does that, but here is the dmesg and .config. # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.4.0-rc6 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="bug" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_FHANDLE=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_FANOUT=64 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y # CONFIG_CGROUP_MEM_RES_CTLR_KMEM is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_MM_OWNER=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_OPTPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLK_DEV_THROTTLING=y # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set CONFIG_INLINE_SPIN_UNLOCK_IRQ=y # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set CONFIG_INLINE_READ_UNLOCK=y # CONFIG_INLINE_READ_UNLOCK_BH is not set CONFIG_INLINE_READ_UNLOCK_IRQ=y # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set CONFIG_INLINE_WRITE_UNLOCK=y # CONFIG_INLINE_WRITE_UNLOCK_BH is not set CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y # CONFIG_X86_VSMP is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=500 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_MICROCODE_XEN=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=6 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_MAXSMP=y CONFIG_NR_CPUS=4096 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=m CONFIG_X86_THERMAL_VECTOR=y CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=10 CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_MEMORY_PROBE=y CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMBLOCK_NODE_MAP=y CONFIG_ARCH_DISCARD_MEMBLOCK=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y # CONFIG_MEMORY_HOTREMOVE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=m CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set CONFIG_CLEANCACHE=y # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_EFI=y # CONFIG_EFI_STUB is not set CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_KEXEC_JUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_RUNTIME=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_IPMI=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_PCI_SLOT=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_HOTPLUG_MEMORY=m CONFIG_ACPI_SBS=m CONFIG_ACPI_HED=m # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_BGRT is not set CONFIG_ACPI_APEI=y # CONFIG_ACPI_APEI_GHES is not set # CONFIG_ACPI_APEI_PCIEAER is not set # CONFIG_ACPI_APEI_MEMORY_FAILURE is not set CONFIG_ACPI_APEI_EINJ=m CONFIG_ACPI_APEI_ERST_DEBUG=m CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # x86 CPU frequency scaling drivers # CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K8=m # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_P4_CLOCKMOD=m # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_INTEL_IDLE=y # # Memory power savings # CONFIG_I7300_IDLE_IOAT_CHANNEL=y CONFIG_I7300_IDLE=m # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_REALLOC_ENABLE_AUTO is not set CONFIG_PCI_STUB=y CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y CONFIG_PCI_PRI=y CONFIG_PCI_PASID=y CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=m CONFIG_RAPIDIO=y # CONFIG_RAPIDIO_TSI721 is not set CONFIG_RAPIDIO_DISC_TIMEOUT=30 # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set # CONFIG_RAPIDIO_DEBUG is not set # CONFIG_RAPIDIO_TSI57X is not set # CONFIG_RAPIDIO_CPS_XX is not set # CONFIG_RAPIDIO_TSI568 is not set # CONFIG_RAPIDIO_CPS_GEN2 is not set # CONFIG_RAPIDIO_TSI500 is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set # CONFIG_X86_X32 is not set CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y # CONFIG_UNIX_DIAG is not set CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_STATISTICS=y CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_CLASSID=y CONFIG_IP_PNP=y # CONFIG_IP_PNP_DHCP is not set # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE_DEMUX=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_MROUTE_MULTIPLE_TABLES=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_INET_UDP_DIAG is not set CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_IPV6_SUBTREES is not set CONFIG_IPV6_MROUTE=y CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y CONFIG_IPV6_PIMSM_V2=y CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m # CONFIG_NETFILTER_NETLINK_ACCT is not set CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y # CONFIG_NF_CONNTRACK_ZONES is not set CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_BROADCAST=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_SNMP=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m # CONFIG_NF_CT_NETLINK_TIMEOUT is not set CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m CONFIG_NETFILTER_XT_CONNMARK=m CONFIG_NETFILTER_XT_SET=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_AUDIT=m CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_CT=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m CONFIG_NETFILTER_XT_TARGET_LED=m # CONFIG_NETFILTER_XT_TARGET_LOG is not set CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TEE=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m CONFIG_NETFILTER_XT_MATCH_CLUSTER=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_CPU=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ECN=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_IPVS=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_IP_SET=m CONFIG_IP_SET_MAX=256 CONFIG_IP_SET_BITMAP_IP=m CONFIG_IP_SET_BITMAP_IPMAC=m CONFIG_IP_SET_BITMAP_PORT=m CONFIG_IP_SET_HASH_IP=m CONFIG_IP_SET_HASH_IPPORT=m CONFIG_IP_SET_HASH_IPPORTIP=m CONFIG_IP_SET_HASH_IPPORTNET=m CONFIG_IP_SET_HASH_NET=m CONFIG_IP_SET_HASH_NETPORT=m # CONFIG_IP_SET_HASH_NETIFACE is not set CONFIG_IP_SET_LIST_SET=m CONFIG_IP_VS=m CONFIG_IP_VS_IPV6=y # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_PROTO_SCTP=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS SH scheduler # CONFIG_IP_VS_SH_TAB_BITS=8 # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IP_VS_NFCT=y # CONFIG_IP_VS_PE_SIP is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m # CONFIG_IP_NF_MATCH_RPFILTER is not set CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_SECURITY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m # CONFIG_IP6_NF_MATCH_RPFILTER is not set CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_SECURITY=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m # # DCCP CCIDs Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=y # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_TFRC_LIB=y # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set CONFIG_NET_DCCPPROBE=m CONFIG_IP_SCTP=m CONFIG_NET_SCTPPROBE=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set CONFIG_SCTP_HMAC_SHA1=y # CONFIG_SCTP_HMAC_MD5 is not set CONFIG_RDS=m CONFIG_RDS_RDMA=m CONFIG_RDS_TCP=m # CONFIG_RDS_DEBUG is not set # CONFIG_TIPC is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_L2TP=m CONFIG_L2TP_DEBUGFS=m CONFIG_L2TP_V3=y CONFIG_L2TP_IP=m CONFIG_L2TP_ETH=m CONFIG_STP=m CONFIG_GARP=m CONFIG_BRIDGE=m CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_NET_DSA=y CONFIG_NET_DSA_TAG_DSA=y CONFIG_NET_DSA_TAG_EDSA=y CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set CONFIG_PHONET=m CONFIG_IEEE802154=m # CONFIG_IEEE802154_6LOWPAN is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_MULTIQ=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFB=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DRR=m CONFIG_NET_SCH_MQPRIO=m CONFIG_NET_SCH_CHOKE=m # CONFIG_NET_SCH_QFQ is not set CONFIG_NET_SCH_INGRESS=m # CONFIG_NET_SCH_PLUG is not set # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_CLS_CGROUP=y CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_ACT_SKBEDIT=m CONFIG_NET_ACT_CSUM=m CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y CONFIG_DCB=y CONFIG_DNS_RESOLVER=y CONFIG_BATMAN_ADV=m # CONFIG_BATMAN_ADV_DEBUG is not set # CONFIG_OPENVSWITCH is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # CONFIG_NETPRIO_CGROUP is not set CONFIG_BQL=y CONFIG_HAVE_BPF_JIT=y CONFIG_BPF_JIT=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NET_TCPPROBE is not set CONFIG_NET_DROP_MONITOR=y # CONFIG_HAMRADIO is not set CONFIG_CAN=m CONFIG_CAN_RAW=m CONFIG_CAN_BCM=m # CONFIG_CAN_GW is not set # # CAN Device Drivers # CONFIG_CAN_VCAN=m CONFIG_CAN_SLCAN=m CONFIG_CAN_DEV=m CONFIG_CAN_CALC_BITTIMING=y CONFIG_PCH_CAN=m CONFIG_CAN_SJA1000=m # CONFIG_CAN_SJA1000_ISA is not set CONFIG_CAN_SJA1000_PLATFORM=m # CONFIG_CAN_EMS_PCMCIA is not set CONFIG_CAN_EMS_PCI=m # CONFIG_CAN_PEAK_PCMCIA is not set # CONFIG_CAN_PEAK_PCI is not set CONFIG_CAN_KVASER_PCI=m CONFIG_CAN_PLX_PCI=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m # CONFIG_CAN_CC770 is not set # # CAN USB interfaces # CONFIG_CAN_EMS_USB=m CONFIG_CAN_ESD_USB2=m # CONFIG_CAN_PEAK_USB is not set CONFIG_CAN_SOFTING=m CONFIG_CAN_SOFTING_CS=m # CONFIG_CAN_DEBUG_DEVICES is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_ATH3K=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MRVL=m CONFIG_BT_MRVL_SDIO=m CONFIG_BT_ATH3K=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m # CONFIG_NL80211_TESTMODE is not set # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set # CONFIG_CFG80211_REG_DEBUG is not set CONFIG_CFG80211_DEFAULT_PS=y # CONFIG_CFG80211_DEBUGFS is not set # CONFIG_CFG80211_INTERNAL_REGDB is not set CONFIG_CFG80211_WEXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=m # CONFIG_LIB80211_DEBUG is not set CONFIG_MAC80211=m CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_WIMAX=m CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y # CONFIG_RFKILL_REGULATOR is not set CONFIG_NET_9P=m CONFIG_NET_9P_VIRTIO=m CONFIG_NET_9P_RDMA=m # CONFIG_NET_9P_DEBUG is not set # CONFIG_CAIF is not set CONFIG_CEPH_LIB=m # CONFIG_CEPH_LIB_PRETTYDEBUG is not set # CONFIG_CEPH_LIB_USE_DNS_RESOLVER is not set # CONFIG_NFC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set CONFIG_SYS_HYPERVISOR=y # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_REGMAP=y CONFIG_REGMAP_I2C=m CONFIG_DMA_SHARED_BUFFER=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=y # CONFIG_MTD_TESTS is not set CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_AR7_PARTS=m # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLKDEVS=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y # CONFIG_INFTL is not set CONFIG_RFD_FTL=m CONFIG_SSFDC=m CONFIG_SM_FTL=m CONFIG_MTD_OOPS=m CONFIG_MTD_SWAP=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_CFI_UTIL=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_TS5500=m # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICHXROM is not set CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m CONFIG_MTD_SCB2_FLASH=m # CONFIG_MTD_NETtel is not set # CONFIG_MTD_L440GX is not set # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 CONFIG_MTD_BLOCK2MTD=m # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_DOCG3 is not set CONFIG_MTD_NAND_ECC=m CONFIG_MTD_NAND_ECC_SMC=y CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_BCH=m CONFIG_MTD_NAND_ECC_BCH=y # CONFIG_MTD_SM_COMMON is not set # CONFIG_MTD_NAND_MUSEUM_IDS is not set # CONFIG_MTD_NAND_DENALI is not set CONFIG_MTD_NAND_IDS=m # CONFIG_MTD_NAND_RICOH is not set CONFIG_MTD_NAND_DISKONCHIP=m # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set # CONFIG_MTD_NAND_DOCG4 is not set # CONFIG_MTD_NAND_CAFE is not set CONFIG_MTD_NAND_NANDSIM=m # CONFIG_MTD_NAND_PLATFORM is not set CONFIG_MTD_ALAUDA=m # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # CONFIG_MTD_LPDDR=m CONFIG_MTD_QINFO_PROBE=m CONFIG_MTD_UBI=m CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_RESERVE=1 # CONFIG_MTD_UBI_GLUEBI is not set # CONFIG_MTD_UBI_DEBUG is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set # CONFIG_BLK_CPQ_DA is not set CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_DRBD=m CONFIG_DRBD_FAULT_INJECTION=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_NVME is not set CONFIG_BLK_DEV_OSD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=m CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_RBD=m # # Misc devices # # CONFIG_SENSORS_LIS3LV02D is not set CONFIG_AD525X_DPOT=m CONFIG_AD525X_DPOT_I2C=m # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set CONFIG_INTEL_MID_PTI=m CONFIG_SGI_IOC4=m CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_ICS932S401=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_HP_ILO=m CONFIG_APDS9802ALS=m CONFIG_ISL29003=m CONFIG_ISL29020=m CONFIG_SENSORS_TSL2550=m CONFIG_SENSORS_BH1780=m CONFIG_SENSORS_BH1770=m CONFIG_SENSORS_APDS990X=m CONFIG_HMC6352=m # CONFIG_DS1682 is not set CONFIG_VMWARE_BALLOON=m # CONFIG_BMP085 is not set # CONFIG_PCH_PHUB is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_C2PORT is not set # # EEPROM support # CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m CONFIG_CB710_CORE=m # CONFIG_CB710_DEBUG is not set CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_IWMC3200TOP=m # CONFIG_IWMC3200TOP_DEBUG is not set # CONFIG_IWMC3200TOP_DEBUGFS is not set # # Texas Instruments shared transport line discipline # # CONFIG_TI_ST is not set # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module # # CONFIG_ALTERA_STAPL is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SRP_ATTRS=m CONFIG_SCSI_SRP_TGT_ATTRS=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m CONFIG_SCSI_CXGB3_ISCSI=m CONFIG_SCSI_CXGB4_ISCSI=m CONFIG_SCSI_BNX2_ISCSI=m CONFIG_SCSI_BNX2X_FCOE=m CONFIG_BE2ISCSI=m CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_HPSA=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_3W_SAS=m # CONFIG_SCSI_ACARD is not set CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC7XXX_OLD is not set CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set # CONFIG_SCSI_MVSAS_TASKLET is not set # CONFIG_SCSI_MVUMI is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set CONFIG_SCSI_ARCMSR=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m # CONFIG_MEGARAID_LEGACY is not set CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y # CONFIG_SCSI_UFSHCD is not set CONFIG_SCSI_HPTIOP=m # CONFIG_SCSI_BUSLOGIC is not set CONFIG_VMWARE_PVSCSI=m CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m CONFIG_FCOE_FNIC=m # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_ISCSI=m CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set CONFIG_SCSI_DEBUG=m CONFIG_SCSI_PMCRAID=m # CONFIG_SCSI_PM8001 is not set CONFIG_SCSI_SRP=m CONFIG_SCSI_BFA_FC=m # CONFIG_SCSI_VIRTIO is not set CONFIG_XEN_SCSI_FRONTEND=m CONFIG_XEN_SCSI_BACKEND=m CONFIG_SCSI_LOWLEVEL_PCMCIA=y # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set CONFIG_SCSI_DH=y CONFIG_SCSI_DH_RDAC=m CONFIG_SCSI_DH_HP_SW=m CONFIG_SCSI_DH_EMC=m CONFIG_SCSI_DH_ALUA=m CONFIG_SCSI_OSD_INITIATOR=m CONFIG_SCSI_OSD_ULD=m CONFIG_SCSI_OSD_DPRINT_SENSE=1 # CONFIG_SCSI_OSD_DEBUG is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m CONFIG_SATA_AHCI_PLATFORM=m CONFIG_SATA_INIC162X=m CONFIG_SATA_ACARD_AHCI=m CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARASAN_CF=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_ATP867X=m CONFIG_PATA_CMD64X=m # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set CONFIG_PATA_CS5536=m # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m # CONFIG_PATA_HPT3X3_DMA is not set CONFIG_PATA_IT8213=m CONFIG_PATA_IT821X=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NINJA32=m # CONFIG_PATA_NS87415 is not set CONFIG_PATA_OLDPIIX=m # CONFIG_PATA_OPTIDMA is not set CONFIG_PATA_PDC2027X=m CONFIG_PATA_PDC_OLD=m # CONFIG_PATA_RADISYS is not set CONFIG_PATA_RDC=m # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SCH=m CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_TOSHIBA=m # CONFIG_PATA_TRIFLEX is not set CONFIG_PATA_VIA=m # CONFIG_PATA_WINBOND is not set # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # CONFIG_PATA_ACPI=m CONFIG_ATA_GENERIC=m # CONFIG_PATA_LEGACY is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MULTICORE_RAID456 is not set # CONFIG_MD_MULTIPATH is not set CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m CONFIG_DM_DEBUG=y CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m # CONFIG_DM_THIN_PROVISIONING is not set CONFIG_DM_MIRROR=m CONFIG_DM_RAID=m CONFIG_DM_LOG_USERSPACE=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_QL=m CONFIG_DM_MULTIPATH_ST=m CONFIG_DM_DELAY=m CONFIG_DM_UEVENT=y CONFIG_DM_FLAKEY=m # CONFIG_DM_VERITY is not set CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m # CONFIG_TCM_FC is not set # CONFIG_ISCSI_TARGET is not set CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=128 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m CONFIG_FUSION_LOGGING=y # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m CONFIG_FIREWIRE_NET=m # CONFIG_FIREWIRE_NOSY is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_NET_CORE=y CONFIG_BONDING=m CONFIG_DUMMY=m # CONFIG_EQUALIZER is not set CONFIG_NET_FC=y CONFIG_MII=m CONFIG_IEEE802154_DRIVERS=m CONFIG_IEEE802154_FAKEHARD=m CONFIG_IFB=m # CONFIG_NET_TEAM is not set CONFIG_MACVLAN=m CONFIG_MACVTAP=m CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_RIONET is not set CONFIG_TUN=m CONFIG_VETH=m CONFIG_VIRTIO_NET=m CONFIG_SUNGEM_PHY=m # CONFIG_ARCNET is not set CONFIG_ATM_DRIVERS=y # CONFIG_ATM_DUMMY is not set CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set # CONFIG_ATM_ENI is not set # CONFIG_ATM_FIRESTREAM is not set # CONFIG_ATM_ZATM is not set # CONFIG_ATM_NICSTAR is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E is not set # CONFIG_ATM_HE is not set # CONFIG_ATM_SOLOS is not set # # CAIF transport drivers # # # Distributed Switch Architecture drivers # CONFIG_NET_DSA_MV88E6XXX=y CONFIG_NET_DSA_MV88E6060=y CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y CONFIG_NET_DSA_MV88E6131=y CONFIG_NET_DSA_MV88E6123_61_65=y CONFIG_ETHERNET=y CONFIG_MDIO=m CONFIG_NET_VENDOR_3COM=y CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_3C589=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_VENDOR_ADAPTEC=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_NET_VENDOR_ALTEON=y CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_NET_VENDOR_AMD=y CONFIG_AMD8111_ETH=m CONFIG_PCNET32=m CONFIG_PCMCIA_NMCLAN=m CONFIG_NET_VENDOR_ATHEROS=y CONFIG_ATL2=m CONFIG_ATL1=m CONFIG_ATL1E=m CONFIG_ATL1C=m CONFIG_NET_VENDOR_BROADCOM=y CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_BNX2=m CONFIG_CNIC=m CONFIG_TIGON3=m CONFIG_BNX2X=m CONFIG_NET_VENDOR_BROCADE=y CONFIG_BNA=m # CONFIG_NET_CALXEDA_XGMAC is not set CONFIG_NET_VENDOR_CHELSIO=y CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T3=m CONFIG_CHELSIO_T4=m # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y CONFIG_ENIC=m CONFIG_DNET=m CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_DE2104X_DSL=0 CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_ULI526X=m CONFIG_PCMCIA_XIRCOM=m CONFIG_NET_VENDOR_DLINK=y # CONFIG_DE600 is not set # CONFIG_DE620 is not set CONFIG_DL2K=m # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y CONFIG_BE2NET=m CONFIG_NET_VENDOR_EXAR=y CONFIG_S2IO=m CONFIG_VXGE=m # CONFIG_VXGE_DEBUG_TRACE_ALL is not set CONFIG_NET_VENDOR_FUJITSU=y CONFIG_PCMCIA_FMVJ18X=m CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IGB=m CONFIG_IGB_DCA=y CONFIG_IGBVF=m CONFIG_IXGB=m CONFIG_IXGBE=m CONFIG_IXGBE_DCA=y CONFIG_IXGBE_DCB=y CONFIG_IXGBEVF=m CONFIG_NET_VENDOR_I825XX=y # CONFIG_ZNET is not set CONFIG_IP1000=m CONFIG_JME=m CONFIG_NET_VENDOR_MARVELL=y CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set # CONFIG_SKGE_GENESIS is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MELLANOX=y CONFIG_MLX4_EN=m CONFIG_MLX4_CORE=m CONFIG_MLX4_DEBUG=y CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8842 is not set # CONFIG_KS8851_MLL is not set # CONFIG_KSZ884X_PCI is not set CONFIG_NET_VENDOR_MYRI=y CONFIG_MYRI10GE=m CONFIG_MYRI10GE_DCA=y CONFIG_FEALNX=m CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NATSEMI=m CONFIG_NS83820=m CONFIG_NET_VENDOR_8390=y CONFIG_PCMCIA_AXNET=m CONFIG_NE2K_PCI=m CONFIG_PCMCIA_PCNET=m CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=m CONFIG_NET_VENDOR_OKI=y CONFIG_PCH_GBE=m CONFIG_ETHOC=m CONFIG_NET_PACKET_ENGINE=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y CONFIG_QLA3XXX=m CONFIG_QLCNIC=m CONFIG_QLGE=m CONFIG_NETXEN_NIC=m CONFIG_NET_VENDOR_REALTEK=y # CONFIG_ATP is not set CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_R8169=m CONFIG_NET_VENDOR_RDC=y CONFIG_R6040=m CONFIG_NET_VENDOR_SEEQ=y # CONFIG_SEEQ8005 is not set CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=m CONFIG_NET_VENDOR_SIS=y CONFIG_SIS900=m CONFIG_SIS190=m CONFIG_SFC=m CONFIG_SFC_MTD=y CONFIG_SFC_MCDI_MON=y CONFIG_SFC_SRIOV=y CONFIG_NET_VENDOR_SMSC=y CONFIG_PCMCIA_SMC91C92=m CONFIG_EPIC100=m CONFIG_SMSC9420=m CONFIG_NET_VENDOR_STMICRO=y CONFIG_STMMAC_ETH=m CONFIG_STMMAC_PLATFORM=m # CONFIG_STMMAC_PCI is not set # CONFIG_STMMAC_DEBUG_FS is not set CONFIG_STMMAC_DA=y CONFIG_STMMAC_RING=y # CONFIG_STMMAC_CHAINED is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NIU=m CONFIG_NET_VENDOR_TEHUTI=y CONFIG_TEHUTI=m CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=m CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_VELOCITY=m CONFIG_NET_VENDOR_XIRCOM=y CONFIG_PCMCIA_XIRC2PS=m CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # # CONFIG_AMD_PHY is not set CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_ICPLUS_PHY=m CONFIG_REALTEK_PHY=m CONFIG_NATIONAL_PHY=m CONFIG_STE10XP=m CONFIG_LSI_ET1011C_PHY=m CONFIG_MICREL_PHY=m CONFIG_FIXED_PHY=y CONFIG_MDIO_BITBANG=m # CONFIG_MDIO_GPIO is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_BSDCOMP is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_FILTER=y CONFIG_PPP_MPPE=m CONFIG_PPP_MULTILINK=y CONFIG_PPPOATM=m CONFIG_PPPOE=m CONFIG_PPTP=m CONFIG_PPPOL2TP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_SLIP=m CONFIG_SLHC=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set # CONFIG_TR is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_CDC_EEM=m CONFIG_USB_NET_CDC_NCM=m CONFIG_USB_NET_DM9601=m # CONFIG_USB_NET_SMSC75XX is not set CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_NET_CX82310_ETH=m CONFIG_USB_NET_KALMIA=m # CONFIG_USB_NET_QMI_WWAN is not set CONFIG_USB_HSO=m CONFIG_USB_NET_INT51X1=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_IPHETH=m CONFIG_USB_SIERRA_NET=m # CONFIG_USB_VL600 is not set CONFIG_WLAN=y # CONFIG_PCMCIA_RAYCS is not set CONFIG_LIBERTAS_THINFIRM=m # CONFIG_LIBERTAS_THINFIRM_DEBUG is not set CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_AIRO=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_PCMCIA_ATMEL=m CONFIG_AT76C50X_USB=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_WL3501=m # CONFIG_PRISM54 is not set CONFIG_USB_ZD1201=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_RTL8187_LEDS=y CONFIG_ADM8211=m CONFIG_MAC80211_HWSIM=m CONFIG_MWL8K=m # CONFIG_ATH_COMMON is not set CONFIG_B43=m CONFIG_B43_SSB=y CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y # CONFIG_B43_PHY_N is not set CONFIG_B43_PHY_LP=y # CONFIG_B43_PHY_HT is not set CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y # CONFIG_B43LEGACY_DEBUG is not set CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set # CONFIG_BRCMFMAC is not set CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m CONFIG_HOSTAP_CS=m CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set CONFIG_LIBIPW=m # CONFIG_LIBIPW_DEBUG is not set # CONFIG_IWLWIFI is not set CONFIG_IWLEGACY=m CONFIG_IWL4965=m CONFIG_IWL3945=m # # iwl3945 / iwl4965 Debugging Options # # CONFIG_IWLEGACY_DEBUG is not set CONFIG_IWM=m # CONFIG_IWM_DEBUG is not set # CONFIG_IWM_TRACING is not set CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_CS=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y # CONFIG_LIBERTAS_MESH is not set CONFIG_HERMES=m # CONFIG_HERMES_PRISM is not set CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCMCIA_HERMES=m CONFIG_PCMCIA_SPECTRUM=m # CONFIG_ORINOCO_USB is not set CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_P54_LEDS=y CONFIG_RT2X00=m CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m # CONFIG_RT2800PCI is not set CONFIG_RT2500USB=m CONFIG_RT73USB=m # CONFIG_RT2800USB is not set CONFIG_RT2X00_LIB_PCI=m CONFIG_RT2X00_LIB_USB=m CONFIG_RT2X00_LIB=m CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y # CONFIG_RT2X00_DEBUG is not set # CONFIG_RTL8192CE is not set CONFIG_RTL8192SE=m # CONFIG_RTL8192DE is not set CONFIG_RTL8192CU=m CONFIG_RTLWIFI=m CONFIG_RTLWIFI_DEBUG=y CONFIG_RTL8192C_COMMON=m CONFIG_WL1251=m CONFIG_WL1251_SDIO=m # CONFIG_WL12XX_MENU is not set CONFIG_WL12XX_PLATFORM_DATA=y CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set # CONFIG_MWIFIEX is not set # # WiMAX Wireless Broadband devices # CONFIG_WIMAX_I2400M=m CONFIG_WIMAX_I2400M_USB=m CONFIG_WIMAX_I2400M_SDIO=m # CONFIG_WIMAX_IWMC3200_SDIO is not set CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8 CONFIG_WAN=y # CONFIG_LANMEDIA is not set CONFIG_HDLC=m CONFIG_HDLC_RAW=m # CONFIG_HDLC_RAW_ETH is not set CONFIG_HDLC_CISCO=m CONFIG_HDLC_FR=m CONFIG_HDLC_PPP=m # # X.25/LAPB support is disabled # # CONFIG_PCI200SYN is not set # CONFIG_WANXL is not set # CONFIG_PC300TOO is not set # CONFIG_FARSYNC is not set # CONFIG_DSCC4 is not set CONFIG_DLCI=m CONFIG_DLCI_MAX=8 # CONFIG_SBNI is not set CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=m CONFIG_VMXNET3=m CONFIG_ISDN=y CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m # CONFIG_HISAX_HFCUSB is not set CONFIG_HISAX_HFC4S8S=m CONFIG_HISAX_FRITZ_PCIPNP=m # # Active cards # CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIDRV=m # # CAPI hardware drivers # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m CONFIG_CAPI_EICON=y # CONFIG_ISDN_DIVAS is not set CONFIG_ISDN_DRV_GIGASET=m # CONFIG_GIGASET_CAPI is not set CONFIG_GIGASET_I4L=y # CONFIG_GIGASET_DUMMYLL is not set CONFIG_GIGASET_BASE=m CONFIG_GIGASET_M105=m CONFIG_GIGASET_M101=m # CONFIG_GIGASET_DEBUG is not set CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y CONFIG_MISDN=m CONFIG_MISDN_DSP=m CONFIG_MISDN_L1OIP=m # # mISDN hardware drivers # CONFIG_MISDN_HFCPCI=m CONFIG_MISDN_HFCMULTI=m CONFIG_MISDN_HFCUSB=m CONFIG_MISDN_AVMFRITZ=m CONFIG_MISDN_SPEEDFAX=m CONFIG_MISDN_INFINEON=m CONFIG_MISDN_W6692=m CONFIG_MISDN_NETJET=m CONFIG_MISDN_IPAC=m CONFIG_MISDN_ISAR=m CONFIG_ISDN_HDLC=m # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_SPARSEKMAP=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_QT1070=m CONFIG_KEYBOARD_QT2160=m # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_GPIO=m CONFIG_KEYBOARD_GPIO_POLLED=m CONFIG_KEYBOARD_TCA6416=m # CONFIG_KEYBOARD_TCA8418 is not set CONFIG_KEYBOARD_MATRIX=m # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_MAX7359 is not set CONFIG_KEYBOARD_MCS=m # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_OMAP4 is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y CONFIG_MOUSE_PS2_ELANTECH=y # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m CONFIG_MOUSE_BCM5974=m CONFIG_MOUSE_VSXXXAA=m CONFIG_MOUSE_GPIO=m CONFIG_MOUSE_SYNAPTICS_I2C=m # CONFIG_MOUSE_SYNAPTICS_USB is not set # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_HANWANG=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_AD7879=m CONFIG_TOUCHSCREEN_AD7879_I2C=m CONFIG_TOUCHSCREEN_ATMEL_MXT=m # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set CONFIG_TOUCHSCREEN_BU21013=m CONFIG_TOUCHSCREEN_CY8CTMG110=m # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set CONFIG_TOUCHSCREEN_DYNAPRO=m CONFIG_TOUCHSCREEN_HAMPSHIRE=m CONFIG_TOUCHSCREEN_EETI=m # CONFIG_TOUCHSCREEN_EGALAX is not set CONFIG_TOUCHSCREEN_FUJITSU=m # CONFIG_TOUCHSCREEN_ILI210X is not set CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_WACOM_W8001=m # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set CONFIG_TOUCHSCREEN_MTOUCH=m CONFIG_TOUCHSCREEN_INEXIO=m CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_WM97XX is not set CONFIG_TOUCHSCREEN_USB_COMPOSITE=m CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y CONFIG_TOUCHSCREEN_USB_JASTEC=y CONFIG_TOUCHSCREEN_USB_ELO=y CONFIG_TOUCHSCREEN_USB_E2I=y CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y CONFIG_TOUCHSCREEN_USB_NEXIO=y CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y CONFIG_TOUCHSCREEN_TOUCHIT213=m # CONFIG_TOUCHSCREEN_TSC_SERIO is not set CONFIG_TOUCHSCREEN_TSC2007=m # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set CONFIG_INPUT_APANEL=m # CONFIG_INPUT_GP2A is not set # CONFIG_INPUT_GPIO_TILT_POLLED is not set CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m # CONFIG_INPUT_KXTJ9 is not set CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m CONFIG_INPUT_CM109=m CONFIG_INPUT_UINPUT=m # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_ROCKETPORT is not set CONFIG_CYCLADES=m # CONFIG_CYZ_INTR is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_NOZOMI=m # CONFIG_ISI is not set CONFIG_N_HDLC=m # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set # CONFIG_DEVKMEM is not set # CONFIG_STALDRV is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_MFD_HSU=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y CONFIG_SERIAL_JSM=m CONFIG_SERIAL_TIMBERDALE=m CONFIG_SERIAL_ALTERA_JTAGUART=m CONFIG_SERIAL_ALTERA_UART=m CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4 CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200 CONFIG_SERIAL_PCH_UART=m # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_HVC_XEN_FRONTEND=y CONFIG_VIRTIO_CONSOLE=m CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_IPWIRELESS=m # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=8192 CONFIG_HPET=y # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=y CONFIG_TCG_TIS=y CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m CONFIG_TELCLOCK=m CONFIG_DEVPORT=y CONFIG_RAMOOPS=m CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=m # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_ISCH=m CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_NFORCE2_S4985=m # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set CONFIG_I2C_SIS96X=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_DESIGNWARE_PCI is not set # CONFIG_I2C_EG20T is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_INTEL_MID is not set # CONFIG_I2C_OCORES is not set CONFIG_I2C_PCA_PLATFORM=m # CONFIG_I2C_PXA_PCI is not set CONFIG_I2C_SIMTEC=m # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m # CONFIG_I2C_TAOS_EVM is not set CONFIG_I2C_TINY_USB=m # # Other I2C/SMBus bus drivers # CONFIG_I2C_STUB=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_SPI is not set # CONFIG_HSI is not set # # PPS support # CONFIG_PPS=m # CONFIG_PPS_DEBUG is not set # # PPS clients support # # CONFIG_PPS_CLIENT_KTIMER is not set # CONFIG_PPS_CLIENT_LDISC is not set # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # # PPS generators support # # # PTP clock support # # CONFIG_PTP_1588_CLOCK is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set # CONFIG_GPIO_SYSFS is not set # # Memory mapped GPIO drivers: # # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_IT8761E is not set # CONFIG_GPIO_SCH is not set # CONFIG_GPIO_VX855 is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_ADP5588 is not set # # PCI GPIO expanders: # # CONFIG_GPIO_LANGWELL is not set # CONFIG_GPIO_PCH is not set # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders: # # CONFIG_GPIO_MCP23S08 is not set # # AC97 GPIO expanders: # # # MODULbus GPIO expanders: # # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2781 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_SBS is not set CONFIG_BATTERY_BQ27x00=m CONFIG_BATTERY_BQ27X00_I2C=y CONFIG_BATTERY_BQ27X00_PLATFORM=y CONFIG_BATTERY_MAX17040=m # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_ISP1704 is not set # CONFIG_CHARGER_MAX8903 is not set # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_MANAGER is not set # CONFIG_CHARGER_SMB347 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m CONFIG_SENSORS_AD7414=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ADT7411=m CONFIG_SENSORS_ADT7462=m CONFIG_SENSORS_ADT7470=m CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_ASC7621=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_K10TEMP=m # CONFIG_SENSORS_FAM15H_POWER is not set CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS620=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_F71882FG=m CONFIG_SENSORS_F75375S=m CONFIG_SENSORS_FSCHMD=m CONFIG_SENSORS_G760A=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_GPIO_FAN=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IBMAEM=m CONFIG_SENSORS_IBMPEX=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_JC42=m CONFIG_SENSORS_LINEAGE=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM73=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_LTC4151=m CONFIG_SENSORS_LTC4215=m CONFIG_SENSORS_LTC4245=m CONFIG_SENSORS_LTC4261=m CONFIG_SENSORS_LM95241=m # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_MAX16065 is not set CONFIG_SENSORS_MAX1619=m # CONFIG_SENSORS_MAX1668 is not set CONFIG_SENSORS_MAX6639=m # CONFIG_SENSORS_MAX6642 is not set CONFIG_SENSORS_MAX6650=m # CONFIG_SENSORS_MCP3021 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_PCF8591=m CONFIG_PMBUS=m CONFIG_SENSORS_PMBUS=m # CONFIG_SENSORS_ADM1275 is not set # CONFIG_SENSORS_LM25066 is not set # CONFIG_SENSORS_LTC2978 is not set CONFIG_SENSORS_MAX16064=m CONFIG_SENSORS_MAX34440=m CONFIG_SENSORS_MAX8688=m # CONFIG_SENSORS_UCD9000 is not set # CONFIG_SENSORS_UCD9200 is not set # CONFIG_SENSORS_ZL6100 is not set CONFIG_SENSORS_SHT15=m CONFIG_SENSORS_SHT21=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_SMM665=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_EMC1403=m CONFIG_SENSORS_EMC2103=m # CONFIG_SENSORS_EMC6W201 is not set CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_SCH56XX_COMMON=m CONFIG_SENSORS_SCH5627=m # CONFIG_SENSORS_SCH5636 is not set CONFIG_SENSORS_ADS1015=m CONFIG_SENSORS_ADS7828=m CONFIG_SENSORS_AMC6821=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP102=m CONFIG_SENSORS_TMP401=m # CONFIG_SENSORS_TMP421 is not set CONFIG_SENSORS_VIA_CPUTEMP=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m # CONFIG_SENSORS_W83795 is not set CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_APPLESMC=m # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set CONFIG_SENSORS_ATK0110=m CONFIG_THERMAL=y CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m # CONFIG_F71808E_WDT is not set # CONFIG_SP5100_TCO is not set # CONFIG_SC520_WDT is not set CONFIG_SBC_FITPC2_WATCHDOG=m # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set CONFIG_IBMASR=m # CONFIG_WAFER_WDT is not set CONFIG_I6300ESB_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y CONFIG_IT8712F_WDT=m CONFIG_IT87_WDT=m CONFIG_HP_WATCHDOG=m CONFIG_HPWDT_NMI_DECODING=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_NV_TCO is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_SMSC_SCH311X_WDT=m # CONFIG_SMSC37B787_WDT is not set # CONFIG_VIA_WDT is not set CONFIG_W83627HF_WDT=m CONFIG_W83697HF_WDT=m CONFIG_W83697UG_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set CONFIG_XEN_WDT=m # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # CONFIG_MFD_CORE=m CONFIG_MFD_SM501=m # CONFIG_MFD_SM501_GPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_UCB1400_CORE is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TMIO is not set CONFIG_MFD_WM8400=m # CONFIG_MFD_PCF50633 is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set # CONFIG_MFD_TIMBERDALE is not set CONFIG_LPC_SCH=m # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_WL1273_CORE is not set CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set # CONFIG_REGULATOR_DUMMY is not set CONFIG_REGULATOR_FIXED_VOLTAGE=m # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set CONFIG_REGULATOR_USERSPACE_CONSUMER=m # CONFIG_REGULATOR_GPIO is not set # CONFIG_REGULATOR_AD5398 is not set # CONFIG_REGULATOR_ISL6271A is not set CONFIG_REGULATOR_MAX1586=m # CONFIG_REGULATOR_MAX8649 is not set # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8952 is not set CONFIG_REGULATOR_LP3971=m # CONFIG_REGULATOR_LP3972 is not set # CONFIG_REGULATOR_TPS62360 is not set CONFIG_REGULATOR_TPS65023=m CONFIG_REGULATOR_TPS6507X=m CONFIG_REGULATOR_WM8400=m CONFIG_MEDIA_SUPPORT=m # # Multimedia core support # # CONFIG_MEDIA_CONTROLLER is not set CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_DVB_CORE=m CONFIG_DVB_NET=y CONFIG_VIDEO_MEDIA=m # # Multimedia drivers # CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_RC_CORE=m CONFIG_LIRC=m CONFIG_RC_MAP=m CONFIG_IR_NEC_DECODER=m CONFIG_IR_RC5_DECODER=m CONFIG_IR_RC6_DECODER=m CONFIG_IR_JVC_DECODER=m CONFIG_IR_SONY_DECODER=m CONFIG_IR_RC5_SZ_DECODER=m CONFIG_IR_SANYO_DECODER=m CONFIG_IR_MCE_KBD_DECODER=m CONFIG_IR_LIRC_CODEC=m # CONFIG_RC_ATI_REMOTE is not set CONFIG_IR_ENE=m CONFIG_IR_IMON=m CONFIG_IR_MCEUSB=m CONFIG_IR_ITE_CIR=m # CONFIG_IR_FINTEK is not set CONFIG_IR_NUVOTON=m # CONFIG_IR_REDRAT3 is not set CONFIG_IR_STREAMZAP=m CONFIG_IR_WINBOND_CIR=m # CONFIG_RC_LOOPBACK is not set # CONFIG_IR_GPIO_CIR is not set CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m # CONFIG_MEDIA_TUNER_CUSTOMISE is not set CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_XC4000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_MEDIA_TUNER_MC44S803=m CONFIG_MEDIA_TUNER_MAX2165=m CONFIG_MEDIA_TUNER_TDA18218=m CONFIG_MEDIA_TUNER_TDA18212=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m # # Audio decoders, processors and mixers # CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m # # RDS decoders # CONFIG_VIDEO_SAA6588=m # # Video decoders # CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_TVP5150=m # # Video and audio decoders # CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_CX25840=m # # MPEG video encoders # CONFIG_VIDEO_CX2341X=m # # Video encoders # CONFIG_VIDEO_SAA7127=m # # Camera sensor devices # CONFIG_VIDEO_MT9V011=m # # Flash devices # # # Video improvement chips # CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m # # Miscelaneous helper chips # CONFIG_VIDEO_M52790=m # CONFIG_VIDEO_VIVI is not set CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_BENQ=m CONFIG_USB_GSPCA_CONEX=m CONFIG_USB_GSPCA_CPIA1=m CONFIG_USB_GSPCA_ETOMS=m CONFIG_USB_GSPCA_FINEPIX=m # CONFIG_USB_GSPCA_JEILINJ is not set # CONFIG_USB_GSPCA_JL2005BCD is not set # CONFIG_USB_GSPCA_KINECT is not set CONFIG_USB_GSPCA_KONICA=m CONFIG_USB_GSPCA_MARS=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_NW80X=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_OV534_9=m CONFIG_USB_GSPCA_PAC207=m CONFIG_USB_GSPCA_PAC7302=m CONFIG_USB_GSPCA_PAC7311=m # CONFIG_USB_GSPCA_SE401 is not set CONFIG_USB_GSPCA_SN9C2028=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SPCA1528=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_SQ930X=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_STV0680=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m # CONFIG_USB_GSPCA_TOPRO is not set CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m # CONFIG_USB_GSPCA_VICAM is not set CONFIG_USB_GSPCA_XIRLINK_CIT=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_EM28XX_RC=y CONFIG_VIDEO_TLG2300=m CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_RC=y CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m # CONFIG_VIDEO_TM6000 is not set CONFIG_VIDEO_USBVISION=m CONFIG_USB_ET61X251=m CONFIG_USB_SN9C102=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_PWC_INPUT_EVDEV=y # CONFIG_VIDEO_CPIA2 is not set CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_V4L_PCI_DRIVERS=y CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CX18_ALSA=m CONFIG_VIDEO_CX23885=m # CONFIG_MEDIA_ALTERA_CI is not set # CONFIG_VIDEO_CX25821 is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_HEXIUM_ORION is not set CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m # CONFIG_VIDEO_MEYE is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_SAA7134 is not set CONFIG_VIDEO_SAA7164=m # CONFIG_VIDEO_ZORAN is not set # CONFIG_V4L_ISA_PARPORT_DRIVERS is not set # CONFIG_V4L_PLATFORM_DRIVERS is not set # CONFIG_V4L_MEM2MEM_DRIVERS is not set # CONFIG_RADIO_ADAPTERS is not set CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # CONFIG_TTPCI_EEPROM=m CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m # CONFIG_DVB_USB_PCTV452E is not set CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_USB_CE6230=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_USB_EC168=m # CONFIG_DVB_USB_AZ6007 is not set CONFIG_DVB_USB_AZ6027=m CONFIG_DVB_USB_LME2510=m # CONFIG_DVB_USB_TECHNISAT_USB2 is not set # CONFIG_DVB_USB_IT913X is not set # CONFIG_DVB_USB_MXL111SF is not set # CONFIG_DVB_USB_RTL28XXU is not set CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_SMS_SIANO_MDTV=m # # Siano module components # CONFIG_SMS_USB_DRV=m CONFIG_SMS_SDIO_DRV=m # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported Pluto2 Adapters # CONFIG_DVB_PLUTO2=m # # Supported SDMC DM1105 Adapters # CONFIG_DVB_DM1105=m # # Supported FireWire (IEEE 1394) Adapters # CONFIG_DVB_FIREDTV=m CONFIG_DVB_FIREDTV_INPUT=y # # Supported Earthsoft PT1 Adapters # CONFIG_DVB_PT1=m # # Supported Mantis Adapters # # CONFIG_MANTIS_CORE is not set # # Supported nGene Adapters # CONFIG_DVB_NGENE=m # # Supported ddbridge ('Octopus') Adapters # # CONFIG_DVB_DDBRIDGE is not set # # Supported DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # Multistandard (satellite) frontends # CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_STV090x=m CONFIG_DVB_STV6110x=m # # Multistandard (cable + terrestrial) frontends # CONFIG_DVB_DRXK=m CONFIG_DVB_TDA18271C2DD=m # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_ZL10039=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TUNER_CX24113=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_SI21XX=m CONFIG_DVB_DS3000=m CONFIG_DVB_TDA10071=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_DRXD=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m CONFIG_DVB_AF9013=m CONFIG_DVB_EC100=m CONFIG_DVB_STV0367=m CONFIG_DVB_CXD2820R=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m # # ISDB-T (terrestrial) frontends # CONFIG_DVB_S921=m CONFIG_DVB_DIB8000=m CONFIG_DVB_MB86A20S=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m CONFIG_DVB_TUNER_DIB0090=m # # SEC control devices for DVB-S # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6421=m CONFIG_DVB_ISL6423=m CONFIG_DVB_A8293=m CONFIG_DVB_LGS8GXX=m CONFIG_DVB_ATBM8830=m CONFIG_DVB_IX2505V=m CONFIG_DVB_M88RS2000=m # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_AGP_VIA=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=64 # CONFIG_VGA_SWITCHEROO is not set CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set CONFIG_DRM_TTM=m # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y # CONFIG_DRM_NOUVEAU_DEBUG is not set # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_DRM_I810 is not set CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m # CONFIG_DRM_VMWGFX is not set # CONFIG_DRM_GMA500 is not set # CONFIG_DRM_UDL is not set # CONFIG_STUB_POULSBO is not set CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=m # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y CONFIG_FB_EFI=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_RIVA_BACKLIGHT=y # CONFIG_FB_I740 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y # CONFIG_FB_SIS is not set CONFIG_FB_VIA=m # CONFIG_FB_VIA_DIRECT_PROCFS is not set # CONFIG_FB_VIA_X_COMPATIBILITY is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_TMIO is not set CONFIG_FB_SM501=m # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set CONFIG_FB_VIRTUAL=m CONFIG_XEN_FBDEV_FRONTEND=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_EXYNOS_VIDEO is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_BACKLIGHT_PROGEAR=m # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # CONFIG_BACKLIGHT_LP855X is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y # CONFIG_SND_DEBUG_VERBOSE is not set CONFIG_SND_PCM_XRUN_DEBUG=y CONFIG_SND_VMASTER=y CONFIG_SND_KCTL_JACK=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_OPL3_LIB_SEQ=m # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set CONFIG_SND_EMU10K1_SEQ=m CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_ALOOP=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m # CONFIG_SND_MTS64 is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # CONFIG_SND_PORTMAN2X4 is not set CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5 CONFIG_SND_SB_COMMON=m CONFIG_SND_SB16_DSP=m CONFIG_SND_TEA575X=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set CONFIG_SND_ALI5451=m # CONFIG_SND_ASIHPI is not set CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m # CONFIG_SND_CMIPCI is not set CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m # CONFIG_SND_CS4281 is not set CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS5530=m CONFIG_SND_CS5535AUDIO=m CONFIG_SND_CTXFI=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_INDIGOIOX=m CONFIG_SND_INDIGODJX=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_ES1968_INPUT=y # CONFIG_SND_ES1968_RADIO is not set CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_PREALLOC_SIZE=64 CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_INPUT_BEEP_MODE=1 CONFIG_SND_HDA_INPUT_JACK=y # CONFIG_SND_HDA_PATCH_LOADER is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_ENABLE_REALTEK_QUIRKS=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_HDMI=y CONFIG_SND_HDA_CODEC_CIRRUS=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CA0110=y CONFIG_SND_HDA_CODEC_CA0132=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m # CONFIG_SND_LOLA is not set CONFIG_SND_LX6464ES=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MAESTRO3_INPUT=y CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_UA101=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SND_USB_6FIRE=m CONFIG_SND_FIREWIRE=y CONFIG_SND_FIREWIRE_LIB=m CONFIG_SND_FIREWIRE_SPEAKERS=m # CONFIG_SND_ISIGHT is not set CONFIG_SND_PCMCIA=y CONFIG_SND_VXPOCKET=m CONFIG_SND_PDAUDIOCF=m # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_BATTERY_STRENGTH is not set CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=y CONFIG_HID_ACRUX=m # CONFIG_HID_ACRUX_FF is not set CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_PRODIKEYS=m CONFIG_HID_CYPRESS=y CONFIG_HID_DRAGONRISE=y CONFIG_DRAGONRISE_FF=y CONFIG_HID_EMS_FF=m CONFIG_HID_ELECOM=m CONFIG_HID_EZKEY=y # CONFIG_HID_HOLTEK is not set CONFIG_HID_KEYTOUCH=m CONFIG_HID_KYE=y CONFIG_HID_UCLOGIC=m CONFIG_HID_WALTOP=m CONFIG_HID_GYRATION=y CONFIG_HID_TWINHAN=y CONFIG_HID_KENSINGTON=y CONFIG_HID_LCPOWER=m CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=m CONFIG_LOGITECH_FF=y CONFIG_LOGIRUMBLEPAD2_FF=y CONFIG_LOGIG940_FF=y CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=m CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=m CONFIG_HID_NTRIG=y CONFIG_HID_ORTEK=m CONFIG_HID_PANTHERLORD=y CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=y CONFIG_HID_PICOLCD=m CONFIG_HID_PICOLCD_FB=y CONFIG_HID_PICOLCD_BACKLIGHT=y CONFIG_HID_PICOLCD_LCD=y CONFIG_HID_PICOLCD_LEDS=y # CONFIG_HID_PRIMAX is not set CONFIG_HID_ROCCAT=m # CONFIG_HID_SAITEK is not set CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y # CONFIG_HID_SPEEDLINK is not set CONFIG_HID_SUNPLUS=y CONFIG_HID_GREENASIA=y CONFIG_GREENASIA_FF=y CONFIG_HID_SMARTJOYPLUS=y CONFIG_SMARTJOYPLUS_FF=y # CONFIG_HID_TIVO is not set CONFIG_HID_TOPSEED=y CONFIG_HID_THRUSTMASTER=y CONFIG_THRUSTMASTER_FF=y CONFIG_HID_WACOM=m CONFIG_HID_WACOM_POWER_SUPPLY=y # CONFIG_HID_WIIMOTE is not set CONFIG_HID_ZEROPLUS=y CONFIG_ZEROPLUS_FF=y CONFIG_HID_ZYDACRON=m CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB_ARCH_HAS_XHCI=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_MON=y CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m # CONFIG_USB_WUSB_CBAF_DEBUG is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_XHCI_HCD=m # CONFIG_USB_XHCI_HCD_DEBUGGING is not set CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_ISP1362_HCD=m CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m # CONFIG_USB_SL811_HCD_ISO is not set # CONFIG_USB_SL811_CS is not set # CONFIG_USB_R8A66597_HCD is not set CONFIG_USB_WHCI_HCD=m CONFIG_USB_HWA_HCD=m CONFIG_XEN_USBDEV_FRONTEND=m CONFIG_XEN_USBDEV_BACKEND=m # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m CONFIG_USB_TMC=m # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set CONFIG_USB_STORAGE_DATAFAB=m CONFIG_USB_STORAGE_FREECOM=m CONFIG_USB_STORAGE_ISD200=m CONFIG_USB_STORAGE_USBAT=m CONFIG_USB_STORAGE_SDDR09=m CONFIG_USB_STORAGE_SDDR55=m CONFIG_USB_STORAGE_JUMPSHOT=m CONFIG_USB_STORAGE_ALAUDA=m CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # # USB port drivers # CONFIG_USB_USS720=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP210X=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_F81232 is not set CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m # CONFIG_USB_SERIAL_METRO is not set CONFIG_USB_SERIAL_MOS7720=m # CONFIG_USB_SERIAL_MOS7715_PARPORT is not set CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m # CONFIG_USB_SERIAL_QCAUX is not set CONFIG_USB_SERIAL_QUALCOMM=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIEMENS_MPI=m CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_SYMBOL=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_WWAN=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_OPTICON=m # CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set # CONFIG_USB_SERIAL_ZIO is not set # CONFIG_USB_SERIAL_SSU100 is not set CONFIG_USB_SERIAL_DEBUG=m # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_SEVSEG=m # CONFIG_USB_RIO500 is not set CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set CONFIG_USB_IOWARRIOR=m # CONFIG_USB_TEST is not set CONFIG_USB_ISIGHTFW=m # CONFIG_USB_YUREX is not set CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # CONFIG_USB_OTG_UTILS=y # CONFIG_USB_GPIO_VBUS is not set CONFIG_NOP_USB_XCEIV=m CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_I1480U=m CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # CONFIG_MMC_CLKGATE is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m # CONFIG_MMC_RICOH_MMC is not set CONFIG_MMC_SDHCI_PLTFM=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_MMC_SDRICOH_CS=m CONFIG_MMC_CB710=m CONFIG_MMC_VIA_SDMMC=m # CONFIG_MMC_VUB300 is not set CONFIG_MMC_USHC=m CONFIG_MEMSTICK=m # CONFIG_MEMSTICK_DEBUG is not set # # MemoryStick drivers # # CONFIG_MEMSTICK_UNSAFE_RESUME is not set CONFIG_MSPRO_BLOCK=m # # MemoryStick Host Controller Drivers # CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m # CONFIG_MEMSTICK_R592 is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_GPIO is not set CONFIG_LEDS_LP3944=m # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set CONFIG_LEDS_CLEVO_MAIL=m # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_PCA9633 is not set # CONFIG_LEDS_REGULATOR is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_DELL_NETBOOKS is not set # CONFIG_LEDS_TCA6507 is not set # CONFIG_LEDS_OT200 is not set CONFIG_LEDS_TRIGGERS=y # # LED Triggers # CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_BACKLIGHT=m # CONFIG_LEDS_TRIGGER_GPIO is not set CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # # iptables trigger is under Netfilter config (LED target) # # CONFIG_ACCESSIBILITY is not set CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_IPATH=m CONFIG_INFINIBAND_QIB=m # CONFIG_INFINIBAND_AMSO1100 is not set CONFIG_INFINIBAND_CXGB3=m # CONFIG_INFINIBAND_CXGB3_DEBUG is not set CONFIG_INFINIBAND_CXGB4=m CONFIG_MLX4_INFINIBAND=m CONFIG_INFINIBAND_NES=m # CONFIG_INFINIBAND_NES_DEBUG is not set CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y # CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set CONFIG_INFINIBAND_SRP=m # CONFIG_INFINIBAND_SRPT is not set CONFIG_INFINIBAND_ISER=m CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=m # CONFIG_EDAC_MCE_INJ is not set CONFIG_EDAC_MM_EDAC=m CONFIG_EDAC_AMD64=m # CONFIG_EDAC_AMD64_ERROR_INJECTION is not set CONFIG_EDAC_E752X=m CONFIG_EDAC_I82975X=m CONFIG_EDAC_I3000=m CONFIG_EDAC_I3200=m CONFIG_EDAC_X38=m CONFIG_EDAC_I5400=m CONFIG_EDAC_I7CORE=m CONFIG_EDAC_I5000=m CONFIG_EDAC_I5100=m CONFIG_EDAC_I7300=m # CONFIG_EDAC_SBRIDGE is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m # CONFIG_RTC_DRV_DS3232 is not set CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m # CONFIG_RTC_DRV_ISL12022 is not set CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set CONFIG_RTC_DRV_FM3130=m CONFIG_RTC_DRV_RX8581=m CONFIG_RTC_DRV_RX8025=m # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_STK17TA8=m # CONFIG_RTC_DRV_M48T86 is not set CONFIG_RTC_DRV_M48T35=m CONFIG_RTC_DRV_M48T59=m # CONFIG_RTC_DRV_MSM6242 is not set CONFIG_RTC_DRV_BQ4802=m # CONFIG_RTC_DRV_RP5C01 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_INTEL_MID_DMAC is not set CONFIG_INTEL_IOATDMA=m # CONFIG_TIMB_DMA is not set # CONFIG_PCH_DMA is not set CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y CONFIG_ASYNC_TX_DMA=y # CONFIG_DMATEST is not set CONFIG_DCA=m CONFIG_AUXDISPLAY=y CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=m CONFIG_CFAG12864B_RATE=20 CONFIG_UIO=m CONFIG_UIO_CIF=m CONFIG_UIO_PDRV=m CONFIG_UIO_PDRV_GENIRQ=m CONFIG_UIO_AEC=m CONFIG_UIO_SERCOS3=m CONFIG_UIO_PCI_GENERIC=m # CONFIG_UIO_NETX is not set CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m # CONFIG_VIRTIO_MMIO is not set # # Microsoft Hyper-V guest support # # CONFIG_HYPERV is not set # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=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_SWIOTLB_XEN=y CONFIG_XEN_TMEM=y CONFIG_XEN_PCIDEV_BACKEND=m CONFIG_XEN_PRIVCMD=m CONFIG_XEN_ACPI_PROCESSOR=y CONFIG_XEN_MCE_LOG=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set # CONFIG_USBIP_CORE is not set # CONFIG_W35UND is not set # CONFIG_PRISM2_USB is not set # CONFIG_ECHO is not set # CONFIG_COMEDI is not set # CONFIG_ASUS_OLED is not set # CONFIG_PANEL is not set # CONFIG_R8187SE is not set # CONFIG_RTL8192U is not set # CONFIG_RTLLIB is not set # CONFIG_R8712U is not set # CONFIG_RTS_PSTOR is not set # CONFIG_RTS5139 is not set # CONFIG_TRANZPORT is not set # CONFIG_IDE_PHISON is not set # CONFIG_LINE6_USB is not set # CONFIG_USB_SERIAL_QUATECH2 is not set # CONFIG_USB_SERIAL_QUATECH_USB2 is not set # CONFIG_VT6655 is not set # CONFIG_VT6656 is not set # CONFIG_VME_BUS is not set # CONFIG_DX_SEP is not set # CONFIG_IIO is not set CONFIG_ZRAM=y CONFIG_ZRAM_DEBUG=y CONFIG_ZCACHE=y CONFIG_ZSMALLOC=y # CONFIG_WLAGS49_H2 is not set # CONFIG_WLAGS49_H25 is not set # CONFIG_FB_SM7XX is not set # CONFIG_CRYSTALHD is not set # CONFIG_CXT1E1 is not set # CONFIG_FB_XGI is not set # CONFIG_ACPI_QUICKSTART is not set # CONFIG_SBE_2T3E3 is not set # CONFIG_USB_ENESTORAGE is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_INTEL_MEI is not set # CONFIG_STAGING_MEDIA is not set # # Android # # CONFIG_ANDROID is not set # CONFIG_PHONE is not set # CONFIG_USB_WPAN_HCD is not set CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACER_WMI=m CONFIG_ACERHDF=m CONFIG_ASUS_LAPTOP=m CONFIG_DELL_LAPTOP=m CONFIG_DELL_WMI=m # CONFIG_DELL_WMI_AIO is not set CONFIG_FUJITSU_LAPTOP=m # CONFIG_FUJITSU_LAPTOP_DEBUG is not set # CONFIG_FUJITSU_TABLET is not set # CONFIG_AMILO_RFKILL is not set # CONFIG_HP_ACCEL is not set CONFIG_HP_WMI=m CONFIG_MSI_LAPTOP=m CONFIG_PANASONIC_LAPTOP=m CONFIG_COMPAL_LAPTOP=m CONFIG_SONY_LAPTOP=m CONFIG_SONYPI_COMPAT=y # CONFIG_IDEAPAD_LAPTOP is not set CONFIG_THINKPAD_ACPI=m CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y # CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set # CONFIG_THINKPAD_ACPI_DEBUG is not set # CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_SENSORS_HDAPS=m # CONFIG_INTEL_MENLOW is not set # CONFIG_EEEPC_LAPTOP is not set # CONFIG_ASUS_WMI is not set CONFIG_ACPI_WMI=m CONFIG_MSI_WMI=m # CONFIG_TOPSTAR_LAPTOP is not set CONFIG_ACPI_TOSHIBA=m CONFIG_TOSHIBA_BT_RFKILL=m CONFIG_ACPI_CMPC=m CONFIG_INTEL_IPS=m CONFIG_IBM_RTL=m CONFIG_XO15_EBOOK=m CONFIG_SAMSUNG_LAPTOP=m CONFIG_MXM_WMI=m # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set # CONFIG_APPLE_GMUX is not set # # Hardware Spinlock drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y # CONFIG_AMD_IOMMU_V2 is not set # CONFIG_INTEL_IOMMU is not set # CONFIG_IRQ_REMAP is not set # # Remoteproc drivers (EXPERIMENTAL) # # # Rpmsg drivers (EXPERIMENTAL) # # CONFIG_VIRT_DRIVERS is not set # CONFIG_PM_DEVFREQ is not set # # Firmware Drivers # CONFIG_EDD=m # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=y CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y CONFIG_DMI_SYSFS=m CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_GOOGLE_FIRMWARE is not set # # File systems # CONFIG_DCACHE_WORD_ACCESS=y CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_FS_XIP=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=m # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_DLM=y CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m CONFIG_OCFS2_FS_STATS=y CONFIG_OCFS2_DEBUG_MASKLOG=y # CONFIG_OCFS2_DEBUG_FS is not set CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_CUSE=m CONFIG_GENERIC_ACL=y # # Caches # CONFIG_FSCACHE=m CONFIG_FSCACHE_STATS=y # CONFIG_FSCACHE_HISTOGRAM is not set # CONFIG_FSCACHE_DEBUG is not set # CONFIG_FSCACHE_OBJECT_LIST is not set CONFIG_CACHEFILES=m # CONFIG_CACHEFILES_DEBUG is not set # CONFIG_CACHEFILES_HISTOGRAM is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_ECRYPT_FS=m # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_WRITEBUFFER=y # CONFIG_JFFS2_FS_WBUF_VERIFY is not set CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y # CONFIG_JFFS2_LZO is not set CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set CONFIG_UBIFS_FS=m CONFIG_UBIFS_FS_XATTR=y # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set CONFIG_UBIFS_FS_LZO=y CONFIG_UBIFS_FS_ZLIB=y # CONFIG_UBIFS_FS_DEBUG is not set # CONFIG_LOGFS is not set CONFIG_CRAMFS=m CONFIG_SQUASHFS=m # CONFIG_SQUASHFS_XATTR is not set CONFIG_SQUASHFS_ZLIB=y # CONFIG_SQUASHFS_LZO is not set # CONFIG_SQUASHFS_XZ is not set # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX6FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_PSTORE=y # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # CONFIG_EXOFS_FS is not set CONFIG_ORE=m CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_PNFS_FILE_LAYOUT=m CONFIG_PNFS_BLOCK=m CONFIG_PNFS_OBJLAYOUT=m CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org" CONFIG_NFS_FSCACHE=y CONFIG_NFS_USE_LEGACY_DNS=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y # CONFIG_NFSD_FAULT_INJECTION is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BACKCHANNEL=y CONFIG_SUNRPC_XPRT_RDMA=m CONFIG_RPCSEC_GSS_KRB5=m # CONFIG_SUNRPC_DEBUG is not set # CONFIG_CEPH_FS is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_DFS_UPCALL=y # CONFIG_CIFS_FSCACHE is not set CONFIG_CIFS_ACL=y # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y CONFIG_STRIP_ASM_SYMS=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y CONFIG_HEADERS_CHECK=y CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DEBUG_LIST=y # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_CPU_STALL_INFO is not set # CONFIG_RCU_TRACE is not set # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_LKDTM is not set # CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set # CONFIG_FAULT_INJECTION is not set CONFIG_LATENCYTOP=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set CONFIG_RING_BUFFER_BENCHMARK=m CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set CONFIG_BUILD_DOCSRC=y CONFIG_DYNAMIC_DEBUG=y # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_ASYNC_RAID6_TEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set # CONFIG_KGDB_LOW_LEVEL_TRAP is not set # CONFIG_KGDB_KDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y # CONFIG_TEST_KSTRTOX is not set CONFIG_STRICT_DEVMEM=y # CONFIG_X86_VERBOSE_BOOTUP is not set CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_DEBUG_SET_MODULE_RONX is not set CONFIG_DEBUG_NX_TEST=m # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set # CONFIG_DEBUG_NMI_SELFTEST is not set # # Security options # CONFIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y # CONFIG_SECURITY_PATH is not set CONFIG_LSM_MMAP_MIN_ADDR=65535 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_SECURITY_YAMA is not set CONFIG_INTEGRITY=y # CONFIG_INTEGRITY_SIGNATURE is not set CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 CONFIG_IMA_AUDIT=y CONFIG_IMA_LSM_RULES=y # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_FIPS=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m # # Block modes # CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m # # Hash modes # CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA1_SSSE3 is not set CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_CAMELLIA_X86_64 is not set CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m # CONFIG_CRYPTO_SALSA20 is not set CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m # CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set CONFIG_CRYPTO_TEA=m # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=y # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m # CONFIG_KVM_MMU_AUDIT is not set CONFIG_VHOST_NET=m CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_IO=y CONFIG_CRC_CCITT=m CONFIG_CRC16=y CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC7=m CONFIG_LIBCRC32C=m # CONFIG_CRC8 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=m CONFIG_REED_SOLOMON_DEC16=y CONFIG_BCH=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPUMASK_OFFSTACK=y CONFIG_CPU_RMAP=y CONFIG_DQL=y CONFIG_NLATTR=y CONFIG_LRU_CACHE=m CONFIG_AVERAGE=y # CONFIG_CORDIC is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:38:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21: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 ) id 1SRVch-0000am-GK; Mon, 07 May 2012 21:37:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVcf-0000ah-IZ for xen-devel@lists.xensource.com; Mon, 07 May 2012 21:37:38 +0000 Received: from [85.158.139.83:56117] by server-1.bemta-5.messagelabs.com id 6E/63-28458-0A048AF4; Mon, 07 May 2012 21:37:36 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-5.tower-182.messagelabs.com!1336426645!27204262!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=3.5 required=7.0 tests=UNIQUE_WORDS, UPPERCASE_75_100 X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11097 invoked from network); 7 May 2012 21:37:27 -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; 7 May 2012 21:37:27 -0000 Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1]) by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id q47LbGwn024843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2012 17:37:16 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q47LbGuE024841; Mon, 7 May 2012 17:37:16 -0400 Date: Mon, 7 May 2012 17:37:16 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120507213716.GA24819@andromeda.dapyr.net> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Mutt/1.5.9i Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:25:36PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > > domain. Then when blkfront un-share them, also removes the > > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > > > We do it so that when the source and the destination domain are the same > > > > (blkfront connected to blkback in the same domain) we can more easily > > So I've been testing it with my mini config and it worked great. But > when I started using a distro .config it blew up. I am not really > sure why it does that, but here is the dmesg and .config. # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.4.0-rc6 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" # CONFIG_KTIME_SCALAR is not set CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="bug" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_FHANDLE=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_FANOUT=64 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y # CONFIG_CGROUP_MEM_RES_CTLR_KMEM is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_MM_OWNER=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_OPTPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLK_DEV_THROTTLING=y # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set CONFIG_INLINE_SPIN_UNLOCK_IRQ=y # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set CONFIG_INLINE_READ_UNLOCK=y # CONFIG_INLINE_READ_UNLOCK_BH is not set CONFIG_INLINE_READ_UNLOCK_IRQ=y # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set CONFIG_INLINE_WRITE_UNLOCK=y # CONFIG_INLINE_WRITE_UNLOCK_BH is not set CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y # CONFIG_X86_VSMP is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=500 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_MICROCODE_XEN=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=6 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_MAXSMP=y CONFIG_NR_CPUS=4096 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=m CONFIG_X86_THERMAL_VECTOR=y CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=10 CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_MEMORY_PROBE=y CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMBLOCK_NODE_MAP=y CONFIG_ARCH_DISCARD_MEMBLOCK=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y # CONFIG_MEMORY_HOTREMOVE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=m CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set CONFIG_CLEANCACHE=y # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_EFI=y # CONFIG_EFI_STUB is not set CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_KEXEC_JUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_RUNTIME=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_IPMI=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_PCI_SLOT=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_HOTPLUG_MEMORY=m CONFIG_ACPI_SBS=m CONFIG_ACPI_HED=m # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_BGRT is not set CONFIG_ACPI_APEI=y # CONFIG_ACPI_APEI_GHES is not set # CONFIG_ACPI_APEI_PCIEAER is not set # CONFIG_ACPI_APEI_MEMORY_FAILURE is not set CONFIG_ACPI_APEI_EINJ=m CONFIG_ACPI_APEI_ERST_DEBUG=m CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # x86 CPU frequency scaling drivers # CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K8=m # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_P4_CLOCKMOD=m # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_INTEL_IDLE=y # # Memory power savings # CONFIG_I7300_IDLE_IOAT_CHANNEL=y CONFIG_I7300_IDLE=m # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_REALLOC_ENABLE_AUTO is not set CONFIG_PCI_STUB=y CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y CONFIG_PCI_PRI=y CONFIG_PCI_PASID=y CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=m CONFIG_RAPIDIO=y # CONFIG_RAPIDIO_TSI721 is not set CONFIG_RAPIDIO_DISC_TIMEOUT=30 # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set # CONFIG_RAPIDIO_DEBUG is not set # CONFIG_RAPIDIO_TSI57X is not set # CONFIG_RAPIDIO_CPS_XX is not set # CONFIG_RAPIDIO_TSI568 is not set # CONFIG_RAPIDIO_CPS_GEN2 is not set # CONFIG_RAPIDIO_TSI500 is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set # CONFIG_X86_X32 is not set CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y # CONFIG_UNIX_DIAG is not set CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_STATISTICS=y CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_CLASSID=y CONFIG_IP_PNP=y # CONFIG_IP_PNP_DHCP is not set # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE_DEMUX=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_MROUTE_MULTIPLE_TABLES=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_INET_UDP_DIAG is not set CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_IPV6_SUBTREES is not set CONFIG_IPV6_MROUTE=y CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y CONFIG_IPV6_PIMSM_V2=y CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m # CONFIG_NETFILTER_NETLINK_ACCT is not set CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y # CONFIG_NF_CONNTRACK_ZONES is not set CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_BROADCAST=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_SNMP=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m # CONFIG_NF_CT_NETLINK_TIMEOUT is not set CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m CONFIG_NETFILTER_XT_CONNMARK=m CONFIG_NETFILTER_XT_SET=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_AUDIT=m CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_CT=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m CONFIG_NETFILTER_XT_TARGET_LED=m # CONFIG_NETFILTER_XT_TARGET_LOG is not set CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TEE=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m CONFIG_NETFILTER_XT_MATCH_CLUSTER=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_CPU=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ECN=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_IPVS=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_IP_SET=m CONFIG_IP_SET_MAX=256 CONFIG_IP_SET_BITMAP_IP=m CONFIG_IP_SET_BITMAP_IPMAC=m CONFIG_IP_SET_BITMAP_PORT=m CONFIG_IP_SET_HASH_IP=m CONFIG_IP_SET_HASH_IPPORT=m CONFIG_IP_SET_HASH_IPPORTIP=m CONFIG_IP_SET_HASH_IPPORTNET=m CONFIG_IP_SET_HASH_NET=m CONFIG_IP_SET_HASH_NETPORT=m # CONFIG_IP_SET_HASH_NETIFACE is not set CONFIG_IP_SET_LIST_SET=m CONFIG_IP_VS=m CONFIG_IP_VS_IPV6=y # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_PROTO_SCTP=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS SH scheduler # CONFIG_IP_VS_SH_TAB_BITS=8 # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IP_VS_NFCT=y # CONFIG_IP_VS_PE_SIP is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m # CONFIG_IP_NF_MATCH_RPFILTER is not set CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_SECURITY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m # CONFIG_IP6_NF_MATCH_RPFILTER is not set CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_SECURITY=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m # # DCCP CCIDs Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=y # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_TFRC_LIB=y # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set CONFIG_NET_DCCPPROBE=m CONFIG_IP_SCTP=m CONFIG_NET_SCTPPROBE=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set CONFIG_SCTP_HMAC_SHA1=y # CONFIG_SCTP_HMAC_MD5 is not set CONFIG_RDS=m CONFIG_RDS_RDMA=m CONFIG_RDS_TCP=m # CONFIG_RDS_DEBUG is not set # CONFIG_TIPC is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_L2TP=m CONFIG_L2TP_DEBUGFS=m CONFIG_L2TP_V3=y CONFIG_L2TP_IP=m CONFIG_L2TP_ETH=m CONFIG_STP=m CONFIG_GARP=m CONFIG_BRIDGE=m CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_NET_DSA=y CONFIG_NET_DSA_TAG_DSA=y CONFIG_NET_DSA_TAG_EDSA=y CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set CONFIG_PHONET=m CONFIG_IEEE802154=m # CONFIG_IEEE802154_6LOWPAN is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_MULTIQ=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFB=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DRR=m CONFIG_NET_SCH_MQPRIO=m CONFIG_NET_SCH_CHOKE=m # CONFIG_NET_SCH_QFQ is not set CONFIG_NET_SCH_INGRESS=m # CONFIG_NET_SCH_PLUG is not set # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_CLS_CGROUP=y CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_ACT_SKBEDIT=m CONFIG_NET_ACT_CSUM=m CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y CONFIG_DCB=y CONFIG_DNS_RESOLVER=y CONFIG_BATMAN_ADV=m # CONFIG_BATMAN_ADV_DEBUG is not set # CONFIG_OPENVSWITCH is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # CONFIG_NETPRIO_CGROUP is not set CONFIG_BQL=y CONFIG_HAVE_BPF_JIT=y CONFIG_BPF_JIT=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NET_TCPPROBE is not set CONFIG_NET_DROP_MONITOR=y # CONFIG_HAMRADIO is not set CONFIG_CAN=m CONFIG_CAN_RAW=m CONFIG_CAN_BCM=m # CONFIG_CAN_GW is not set # # CAN Device Drivers # CONFIG_CAN_VCAN=m CONFIG_CAN_SLCAN=m CONFIG_CAN_DEV=m CONFIG_CAN_CALC_BITTIMING=y CONFIG_PCH_CAN=m CONFIG_CAN_SJA1000=m # CONFIG_CAN_SJA1000_ISA is not set CONFIG_CAN_SJA1000_PLATFORM=m # CONFIG_CAN_EMS_PCMCIA is not set CONFIG_CAN_EMS_PCI=m # CONFIG_CAN_PEAK_PCMCIA is not set # CONFIG_CAN_PEAK_PCI is not set CONFIG_CAN_KVASER_PCI=m CONFIG_CAN_PLX_PCI=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m # CONFIG_CAN_CC770 is not set # # CAN USB interfaces # CONFIG_CAN_EMS_USB=m CONFIG_CAN_ESD_USB2=m # CONFIG_CAN_PEAK_USB is not set CONFIG_CAN_SOFTING=m CONFIG_CAN_SOFTING_CS=m # CONFIG_CAN_DEBUG_DEVICES is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_ATH3K=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MRVL=m CONFIG_BT_MRVL_SDIO=m CONFIG_BT_ATH3K=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m # CONFIG_NL80211_TESTMODE is not set # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set # CONFIG_CFG80211_REG_DEBUG is not set CONFIG_CFG80211_DEFAULT_PS=y # CONFIG_CFG80211_DEBUGFS is not set # CONFIG_CFG80211_INTERNAL_REGDB is not set CONFIG_CFG80211_WEXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=m # CONFIG_LIB80211_DEBUG is not set CONFIG_MAC80211=m CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_WIMAX=m CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y # CONFIG_RFKILL_REGULATOR is not set CONFIG_NET_9P=m CONFIG_NET_9P_VIRTIO=m CONFIG_NET_9P_RDMA=m # CONFIG_NET_9P_DEBUG is not set # CONFIG_CAIF is not set CONFIG_CEPH_LIB=m # CONFIG_CEPH_LIB_PRETTYDEBUG is not set # CONFIG_CEPH_LIB_USE_DNS_RESOLVER is not set # CONFIG_NFC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set CONFIG_SYS_HYPERVISOR=y # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_REGMAP=y CONFIG_REGMAP_I2C=m CONFIG_DMA_SHARED_BUFFER=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=y # CONFIG_MTD_TESTS is not set CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_AR7_PARTS=m # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLKDEVS=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y # CONFIG_INFTL is not set CONFIG_RFD_FTL=m CONFIG_SSFDC=m CONFIG_SM_FTL=m CONFIG_MTD_OOPS=m CONFIG_MTD_SWAP=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_CFI_UTIL=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_TS5500=m # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICHXROM is not set CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m CONFIG_MTD_SCB2_FLASH=m # CONFIG_MTD_NETtel is not set # CONFIG_MTD_L440GX is not set # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 CONFIG_MTD_BLOCK2MTD=m # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_DOCG3 is not set CONFIG_MTD_NAND_ECC=m CONFIG_MTD_NAND_ECC_SMC=y CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_BCH=m CONFIG_MTD_NAND_ECC_BCH=y # CONFIG_MTD_SM_COMMON is not set # CONFIG_MTD_NAND_MUSEUM_IDS is not set # CONFIG_MTD_NAND_DENALI is not set CONFIG_MTD_NAND_IDS=m # CONFIG_MTD_NAND_RICOH is not set CONFIG_MTD_NAND_DISKONCHIP=m # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set # CONFIG_MTD_NAND_DOCG4 is not set # CONFIG_MTD_NAND_CAFE is not set CONFIG_MTD_NAND_NANDSIM=m # CONFIG_MTD_NAND_PLATFORM is not set CONFIG_MTD_ALAUDA=m # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # CONFIG_MTD_LPDDR=m CONFIG_MTD_QINFO_PROBE=m CONFIG_MTD_UBI=m CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_RESERVE=1 # CONFIG_MTD_UBI_GLUEBI is not set # CONFIG_MTD_UBI_DEBUG is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set # CONFIG_BLK_CPQ_DA is not set CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_DRBD=m CONFIG_DRBD_FAULT_INJECTION=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_NVME is not set CONFIG_BLK_DEV_OSD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=m CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_RBD=m # # Misc devices # # CONFIG_SENSORS_LIS3LV02D is not set CONFIG_AD525X_DPOT=m CONFIG_AD525X_DPOT_I2C=m # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set CONFIG_INTEL_MID_PTI=m CONFIG_SGI_IOC4=m CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_ICS932S401=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_HP_ILO=m CONFIG_APDS9802ALS=m CONFIG_ISL29003=m CONFIG_ISL29020=m CONFIG_SENSORS_TSL2550=m CONFIG_SENSORS_BH1780=m CONFIG_SENSORS_BH1770=m CONFIG_SENSORS_APDS990X=m CONFIG_HMC6352=m # CONFIG_DS1682 is not set CONFIG_VMWARE_BALLOON=m # CONFIG_BMP085 is not set # CONFIG_PCH_PHUB is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_C2PORT is not set # # EEPROM support # CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m CONFIG_CB710_CORE=m # CONFIG_CB710_DEBUG is not set CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_IWMC3200TOP=m # CONFIG_IWMC3200TOP_DEBUG is not set # CONFIG_IWMC3200TOP_DEBUGFS is not set # # Texas Instruments shared transport line discipline # # CONFIG_TI_ST is not set # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module # # CONFIG_ALTERA_STAPL is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SRP_ATTRS=m CONFIG_SCSI_SRP_TGT_ATTRS=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m CONFIG_SCSI_CXGB3_ISCSI=m CONFIG_SCSI_CXGB4_ISCSI=m CONFIG_SCSI_BNX2_ISCSI=m CONFIG_SCSI_BNX2X_FCOE=m CONFIG_BE2ISCSI=m CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_HPSA=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_3W_SAS=m # CONFIG_SCSI_ACARD is not set CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC7XXX_OLD is not set CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set # CONFIG_SCSI_MVSAS_TASKLET is not set # CONFIG_SCSI_MVUMI is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set CONFIG_SCSI_ARCMSR=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m # CONFIG_MEGARAID_LEGACY is not set CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y # CONFIG_SCSI_UFSHCD is not set CONFIG_SCSI_HPTIOP=m # CONFIG_SCSI_BUSLOGIC is not set CONFIG_VMWARE_PVSCSI=m CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m CONFIG_FCOE_FNIC=m # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_ISCSI=m CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set CONFIG_SCSI_DEBUG=m CONFIG_SCSI_PMCRAID=m # CONFIG_SCSI_PM8001 is not set CONFIG_SCSI_SRP=m CONFIG_SCSI_BFA_FC=m # CONFIG_SCSI_VIRTIO is not set CONFIG_XEN_SCSI_FRONTEND=m CONFIG_XEN_SCSI_BACKEND=m CONFIG_SCSI_LOWLEVEL_PCMCIA=y # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set CONFIG_SCSI_DH=y CONFIG_SCSI_DH_RDAC=m CONFIG_SCSI_DH_HP_SW=m CONFIG_SCSI_DH_EMC=m CONFIG_SCSI_DH_ALUA=m CONFIG_SCSI_OSD_INITIATOR=m CONFIG_SCSI_OSD_ULD=m CONFIG_SCSI_OSD_DPRINT_SENSE=1 # CONFIG_SCSI_OSD_DEBUG is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m CONFIG_SATA_AHCI_PLATFORM=m CONFIG_SATA_INIC162X=m CONFIG_SATA_ACARD_AHCI=m CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARASAN_CF=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_ATP867X=m CONFIG_PATA_CMD64X=m # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set CONFIG_PATA_CS5536=m # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m # CONFIG_PATA_HPT3X3_DMA is not set CONFIG_PATA_IT8213=m CONFIG_PATA_IT821X=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NINJA32=m # CONFIG_PATA_NS87415 is not set CONFIG_PATA_OLDPIIX=m # CONFIG_PATA_OPTIDMA is not set CONFIG_PATA_PDC2027X=m CONFIG_PATA_PDC_OLD=m # CONFIG_PATA_RADISYS is not set CONFIG_PATA_RDC=m # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SCH=m CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_TOSHIBA=m # CONFIG_PATA_TRIFLEX is not set CONFIG_PATA_VIA=m # CONFIG_PATA_WINBOND is not set # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # CONFIG_PATA_ACPI=m CONFIG_ATA_GENERIC=m # CONFIG_PATA_LEGACY is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MULTICORE_RAID456 is not set # CONFIG_MD_MULTIPATH is not set CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m CONFIG_DM_DEBUG=y CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m # CONFIG_DM_THIN_PROVISIONING is not set CONFIG_DM_MIRROR=m CONFIG_DM_RAID=m CONFIG_DM_LOG_USERSPACE=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_QL=m CONFIG_DM_MULTIPATH_ST=m CONFIG_DM_DELAY=m CONFIG_DM_UEVENT=y CONFIG_DM_FLAKEY=m # CONFIG_DM_VERITY is not set CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m # CONFIG_TCM_FC is not set # CONFIG_ISCSI_TARGET is not set CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=128 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m CONFIG_FUSION_LOGGING=y # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m CONFIG_FIREWIRE_NET=m # CONFIG_FIREWIRE_NOSY is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_NET_CORE=y CONFIG_BONDING=m CONFIG_DUMMY=m # CONFIG_EQUALIZER is not set CONFIG_NET_FC=y CONFIG_MII=m CONFIG_IEEE802154_DRIVERS=m CONFIG_IEEE802154_FAKEHARD=m CONFIG_IFB=m # CONFIG_NET_TEAM is not set CONFIG_MACVLAN=m CONFIG_MACVTAP=m CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_RIONET is not set CONFIG_TUN=m CONFIG_VETH=m CONFIG_VIRTIO_NET=m CONFIG_SUNGEM_PHY=m # CONFIG_ARCNET is not set CONFIG_ATM_DRIVERS=y # CONFIG_ATM_DUMMY is not set CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set # CONFIG_ATM_ENI is not set # CONFIG_ATM_FIRESTREAM is not set # CONFIG_ATM_ZATM is not set # CONFIG_ATM_NICSTAR is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E is not set # CONFIG_ATM_HE is not set # CONFIG_ATM_SOLOS is not set # # CAIF transport drivers # # # Distributed Switch Architecture drivers # CONFIG_NET_DSA_MV88E6XXX=y CONFIG_NET_DSA_MV88E6060=y CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y CONFIG_NET_DSA_MV88E6131=y CONFIG_NET_DSA_MV88E6123_61_65=y CONFIG_ETHERNET=y CONFIG_MDIO=m CONFIG_NET_VENDOR_3COM=y CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_3C589=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_VENDOR_ADAPTEC=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_NET_VENDOR_ALTEON=y CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_NET_VENDOR_AMD=y CONFIG_AMD8111_ETH=m CONFIG_PCNET32=m CONFIG_PCMCIA_NMCLAN=m CONFIG_NET_VENDOR_ATHEROS=y CONFIG_ATL2=m CONFIG_ATL1=m CONFIG_ATL1E=m CONFIG_ATL1C=m CONFIG_NET_VENDOR_BROADCOM=y CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_BNX2=m CONFIG_CNIC=m CONFIG_TIGON3=m CONFIG_BNX2X=m CONFIG_NET_VENDOR_BROCADE=y CONFIG_BNA=m # CONFIG_NET_CALXEDA_XGMAC is not set CONFIG_NET_VENDOR_CHELSIO=y CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T3=m CONFIG_CHELSIO_T4=m # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y CONFIG_ENIC=m CONFIG_DNET=m CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_DE2104X_DSL=0 CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_ULI526X=m CONFIG_PCMCIA_XIRCOM=m CONFIG_NET_VENDOR_DLINK=y # CONFIG_DE600 is not set # CONFIG_DE620 is not set CONFIG_DL2K=m # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y CONFIG_BE2NET=m CONFIG_NET_VENDOR_EXAR=y CONFIG_S2IO=m CONFIG_VXGE=m # CONFIG_VXGE_DEBUG_TRACE_ALL is not set CONFIG_NET_VENDOR_FUJITSU=y CONFIG_PCMCIA_FMVJ18X=m CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IGB=m CONFIG_IGB_DCA=y CONFIG_IGBVF=m CONFIG_IXGB=m CONFIG_IXGBE=m CONFIG_IXGBE_DCA=y CONFIG_IXGBE_DCB=y CONFIG_IXGBEVF=m CONFIG_NET_VENDOR_I825XX=y # CONFIG_ZNET is not set CONFIG_IP1000=m CONFIG_JME=m CONFIG_NET_VENDOR_MARVELL=y CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set # CONFIG_SKGE_GENESIS is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MELLANOX=y CONFIG_MLX4_EN=m CONFIG_MLX4_CORE=m CONFIG_MLX4_DEBUG=y CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8842 is not set # CONFIG_KS8851_MLL is not set # CONFIG_KSZ884X_PCI is not set CONFIG_NET_VENDOR_MYRI=y CONFIG_MYRI10GE=m CONFIG_MYRI10GE_DCA=y CONFIG_FEALNX=m CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NATSEMI=m CONFIG_NS83820=m CONFIG_NET_VENDOR_8390=y CONFIG_PCMCIA_AXNET=m CONFIG_NE2K_PCI=m CONFIG_PCMCIA_PCNET=m CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=m CONFIG_NET_VENDOR_OKI=y CONFIG_PCH_GBE=m CONFIG_ETHOC=m CONFIG_NET_PACKET_ENGINE=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y CONFIG_QLA3XXX=m CONFIG_QLCNIC=m CONFIG_QLGE=m CONFIG_NETXEN_NIC=m CONFIG_NET_VENDOR_REALTEK=y # CONFIG_ATP is not set CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_R8169=m CONFIG_NET_VENDOR_RDC=y CONFIG_R6040=m CONFIG_NET_VENDOR_SEEQ=y # CONFIG_SEEQ8005 is not set CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=m CONFIG_NET_VENDOR_SIS=y CONFIG_SIS900=m CONFIG_SIS190=m CONFIG_SFC=m CONFIG_SFC_MTD=y CONFIG_SFC_MCDI_MON=y CONFIG_SFC_SRIOV=y CONFIG_NET_VENDOR_SMSC=y CONFIG_PCMCIA_SMC91C92=m CONFIG_EPIC100=m CONFIG_SMSC9420=m CONFIG_NET_VENDOR_STMICRO=y CONFIG_STMMAC_ETH=m CONFIG_STMMAC_PLATFORM=m # CONFIG_STMMAC_PCI is not set # CONFIG_STMMAC_DEBUG_FS is not set CONFIG_STMMAC_DA=y CONFIG_STMMAC_RING=y # CONFIG_STMMAC_CHAINED is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NIU=m CONFIG_NET_VENDOR_TEHUTI=y CONFIG_TEHUTI=m CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=m CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_VELOCITY=m CONFIG_NET_VENDOR_XIRCOM=y CONFIG_PCMCIA_XIRC2PS=m CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # # CONFIG_AMD_PHY is not set CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_ICPLUS_PHY=m CONFIG_REALTEK_PHY=m CONFIG_NATIONAL_PHY=m CONFIG_STE10XP=m CONFIG_LSI_ET1011C_PHY=m CONFIG_MICREL_PHY=m CONFIG_FIXED_PHY=y CONFIG_MDIO_BITBANG=m # CONFIG_MDIO_GPIO is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_BSDCOMP is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_FILTER=y CONFIG_PPP_MPPE=m CONFIG_PPP_MULTILINK=y CONFIG_PPPOATM=m CONFIG_PPPOE=m CONFIG_PPTP=m CONFIG_PPPOL2TP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_SLIP=m CONFIG_SLHC=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set # CONFIG_TR is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_CDC_EEM=m CONFIG_USB_NET_CDC_NCM=m CONFIG_USB_NET_DM9601=m # CONFIG_USB_NET_SMSC75XX is not set CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_NET_CX82310_ETH=m CONFIG_USB_NET_KALMIA=m # CONFIG_USB_NET_QMI_WWAN is not set CONFIG_USB_HSO=m CONFIG_USB_NET_INT51X1=m CONFIG_USB_CDC_PHONET=m CONFIG_USB_IPHETH=m CONFIG_USB_SIERRA_NET=m # CONFIG_USB_VL600 is not set CONFIG_WLAN=y # CONFIG_PCMCIA_RAYCS is not set CONFIG_LIBERTAS_THINFIRM=m # CONFIG_LIBERTAS_THINFIRM_DEBUG is not set CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_AIRO=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_PCMCIA_ATMEL=m CONFIG_AT76C50X_USB=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_WL3501=m # CONFIG_PRISM54 is not set CONFIG_USB_ZD1201=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_RTL8187_LEDS=y CONFIG_ADM8211=m CONFIG_MAC80211_HWSIM=m CONFIG_MWL8K=m # CONFIG_ATH_COMMON is not set CONFIG_B43=m CONFIG_B43_SSB=y CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y # CONFIG_B43_PHY_N is not set CONFIG_B43_PHY_LP=y # CONFIG_B43_PHY_HT is not set CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y # CONFIG_B43LEGACY_DEBUG is not set CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set # CONFIG_BRCMFMAC is not set CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m CONFIG_HOSTAP_CS=m CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set CONFIG_LIBIPW=m # CONFIG_LIBIPW_DEBUG is not set # CONFIG_IWLWIFI is not set CONFIG_IWLEGACY=m CONFIG_IWL4965=m CONFIG_IWL3945=m # # iwl3945 / iwl4965 Debugging Options # # CONFIG_IWLEGACY_DEBUG is not set CONFIG_IWM=m # CONFIG_IWM_DEBUG is not set # CONFIG_IWM_TRACING is not set CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_CS=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y # CONFIG_LIBERTAS_MESH is not set CONFIG_HERMES=m # CONFIG_HERMES_PRISM is not set CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCMCIA_HERMES=m CONFIG_PCMCIA_SPECTRUM=m # CONFIG_ORINOCO_USB is not set CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_P54_LEDS=y CONFIG_RT2X00=m CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m # CONFIG_RT2800PCI is not set CONFIG_RT2500USB=m CONFIG_RT73USB=m # CONFIG_RT2800USB is not set CONFIG_RT2X00_LIB_PCI=m CONFIG_RT2X00_LIB_USB=m CONFIG_RT2X00_LIB=m CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y # CONFIG_RT2X00_DEBUG is not set # CONFIG_RTL8192CE is not set CONFIG_RTL8192SE=m # CONFIG_RTL8192DE is not set CONFIG_RTL8192CU=m CONFIG_RTLWIFI=m CONFIG_RTLWIFI_DEBUG=y CONFIG_RTL8192C_COMMON=m CONFIG_WL1251=m CONFIG_WL1251_SDIO=m # CONFIG_WL12XX_MENU is not set CONFIG_WL12XX_PLATFORM_DATA=y CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set # CONFIG_MWIFIEX is not set # # WiMAX Wireless Broadband devices # CONFIG_WIMAX_I2400M=m CONFIG_WIMAX_I2400M_USB=m CONFIG_WIMAX_I2400M_SDIO=m # CONFIG_WIMAX_IWMC3200_SDIO is not set CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8 CONFIG_WAN=y # CONFIG_LANMEDIA is not set CONFIG_HDLC=m CONFIG_HDLC_RAW=m # CONFIG_HDLC_RAW_ETH is not set CONFIG_HDLC_CISCO=m CONFIG_HDLC_FR=m CONFIG_HDLC_PPP=m # # X.25/LAPB support is disabled # # CONFIG_PCI200SYN is not set # CONFIG_WANXL is not set # CONFIG_PC300TOO is not set # CONFIG_FARSYNC is not set # CONFIG_DSCC4 is not set CONFIG_DLCI=m CONFIG_DLCI_MAX=8 # CONFIG_SBNI is not set CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=m CONFIG_VMXNET3=m CONFIG_ISDN=y CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m # CONFIG_HISAX_HFCUSB is not set CONFIG_HISAX_HFC4S8S=m CONFIG_HISAX_FRITZ_PCIPNP=m # # Active cards # CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIDRV=m # # CAPI hardware drivers # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m CONFIG_CAPI_EICON=y # CONFIG_ISDN_DIVAS is not set CONFIG_ISDN_DRV_GIGASET=m # CONFIG_GIGASET_CAPI is not set CONFIG_GIGASET_I4L=y # CONFIG_GIGASET_DUMMYLL is not set CONFIG_GIGASET_BASE=m CONFIG_GIGASET_M105=m CONFIG_GIGASET_M101=m # CONFIG_GIGASET_DEBUG is not set CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y CONFIG_MISDN=m CONFIG_MISDN_DSP=m CONFIG_MISDN_L1OIP=m # # mISDN hardware drivers # CONFIG_MISDN_HFCPCI=m CONFIG_MISDN_HFCMULTI=m CONFIG_MISDN_HFCUSB=m CONFIG_MISDN_AVMFRITZ=m CONFIG_MISDN_SPEEDFAX=m CONFIG_MISDN_INFINEON=m CONFIG_MISDN_W6692=m CONFIG_MISDN_NETJET=m CONFIG_MISDN_IPAC=m CONFIG_MISDN_ISAR=m CONFIG_ISDN_HDLC=m # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_SPARSEKMAP=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_QT1070=m CONFIG_KEYBOARD_QT2160=m # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_GPIO=m CONFIG_KEYBOARD_GPIO_POLLED=m CONFIG_KEYBOARD_TCA6416=m # CONFIG_KEYBOARD_TCA8418 is not set CONFIG_KEYBOARD_MATRIX=m # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_MAX7359 is not set CONFIG_KEYBOARD_MCS=m # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_OMAP4 is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y CONFIG_MOUSE_PS2_ELANTECH=y # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m CONFIG_MOUSE_BCM5974=m CONFIG_MOUSE_VSXXXAA=m CONFIG_MOUSE_GPIO=m CONFIG_MOUSE_SYNAPTICS_I2C=m # CONFIG_MOUSE_SYNAPTICS_USB is not set # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_HANWANG=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_AD7879=m CONFIG_TOUCHSCREEN_AD7879_I2C=m CONFIG_TOUCHSCREEN_ATMEL_MXT=m # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set CONFIG_TOUCHSCREEN_BU21013=m CONFIG_TOUCHSCREEN_CY8CTMG110=m # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set CONFIG_TOUCHSCREEN_DYNAPRO=m CONFIG_TOUCHSCREEN_HAMPSHIRE=m CONFIG_TOUCHSCREEN_EETI=m # CONFIG_TOUCHSCREEN_EGALAX is not set CONFIG_TOUCHSCREEN_FUJITSU=m # CONFIG_TOUCHSCREEN_ILI210X is not set CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_WACOM_W8001=m # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set CONFIG_TOUCHSCREEN_MTOUCH=m CONFIG_TOUCHSCREEN_INEXIO=m CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_WM97XX is not set CONFIG_TOUCHSCREEN_USB_COMPOSITE=m CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y CONFIG_TOUCHSCREEN_USB_JASTEC=y CONFIG_TOUCHSCREEN_USB_ELO=y CONFIG_TOUCHSCREEN_USB_E2I=y CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y CONFIG_TOUCHSCREEN_USB_NEXIO=y CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y CONFIG_TOUCHSCREEN_TOUCHIT213=m # CONFIG_TOUCHSCREEN_TSC_SERIO is not set CONFIG_TOUCHSCREEN_TSC2007=m # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set CONFIG_INPUT_APANEL=m # CONFIG_INPUT_GP2A is not set # CONFIG_INPUT_GPIO_TILT_POLLED is not set CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m # CONFIG_INPUT_KXTJ9 is not set CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m CONFIG_INPUT_CM109=m CONFIG_INPUT_UINPUT=m # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_ROCKETPORT is not set CONFIG_CYCLADES=m # CONFIG_CYZ_INTR is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_NOZOMI=m # CONFIG_ISI is not set CONFIG_N_HDLC=m # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set # CONFIG_DEVKMEM is not set # CONFIG_STALDRV is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_MFD_HSU=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y CONFIG_SERIAL_JSM=m CONFIG_SERIAL_TIMBERDALE=m CONFIG_SERIAL_ALTERA_JTAGUART=m CONFIG_SERIAL_ALTERA_UART=m CONFIG_SERIAL_ALTERA_UART_MAXPORTS=4 CONFIG_SERIAL_ALTERA_UART_BAUDRATE=115200 CONFIG_SERIAL_PCH_UART=m # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_HVC_XEN_FRONTEND=y CONFIG_VIRTIO_CONSOLE=m CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_IPWIRELESS=m # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=8192 CONFIG_HPET=y # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=y CONFIG_TCG_TIS=y CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m CONFIG_TELCLOCK=m CONFIG_DEVPORT=y CONFIG_RAMOOPS=m CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=m # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_ISCH=m CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_NFORCE2_S4985=m # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set CONFIG_I2C_SIS96X=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_DESIGNWARE_PCI is not set # CONFIG_I2C_EG20T is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_INTEL_MID is not set # CONFIG_I2C_OCORES is not set CONFIG_I2C_PCA_PLATFORM=m # CONFIG_I2C_PXA_PCI is not set CONFIG_I2C_SIMTEC=m # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m # CONFIG_I2C_TAOS_EVM is not set CONFIG_I2C_TINY_USB=m # # Other I2C/SMBus bus drivers # CONFIG_I2C_STUB=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_SPI is not set # CONFIG_HSI is not set # # PPS support # CONFIG_PPS=m # CONFIG_PPS_DEBUG is not set # # PPS clients support # # CONFIG_PPS_CLIENT_KTIMER is not set # CONFIG_PPS_CLIENT_LDISC is not set # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # # PPS generators support # # # PTP clock support # # CONFIG_PTP_1588_CLOCK is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set # CONFIG_GPIO_SYSFS is not set # # Memory mapped GPIO drivers: # # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_IT8761E is not set # CONFIG_GPIO_SCH is not set # CONFIG_GPIO_VX855 is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_ADP5588 is not set # # PCI GPIO expanders: # # CONFIG_GPIO_LANGWELL is not set # CONFIG_GPIO_PCH is not set # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders: # # CONFIG_GPIO_MCP23S08 is not set # # AC97 GPIO expanders: # # # MODULbus GPIO expanders: # # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2781 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_SBS is not set CONFIG_BATTERY_BQ27x00=m CONFIG_BATTERY_BQ27X00_I2C=y CONFIG_BATTERY_BQ27X00_PLATFORM=y CONFIG_BATTERY_MAX17040=m # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_ISP1704 is not set # CONFIG_CHARGER_MAX8903 is not set # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_MANAGER is not set # CONFIG_CHARGER_SMB347 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m CONFIG_SENSORS_AD7414=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ADT7411=m CONFIG_SENSORS_ADT7462=m CONFIG_SENSORS_ADT7470=m CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_ASC7621=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_K10TEMP=m # CONFIG_SENSORS_FAM15H_POWER is not set CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS620=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_F71882FG=m CONFIG_SENSORS_F75375S=m CONFIG_SENSORS_FSCHMD=m CONFIG_SENSORS_G760A=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_GPIO_FAN=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IBMAEM=m CONFIG_SENSORS_IBMPEX=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_JC42=m CONFIG_SENSORS_LINEAGE=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM73=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_LTC4151=m CONFIG_SENSORS_LTC4215=m CONFIG_SENSORS_LTC4245=m CONFIG_SENSORS_LTC4261=m CONFIG_SENSORS_LM95241=m # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_MAX16065 is not set CONFIG_SENSORS_MAX1619=m # CONFIG_SENSORS_MAX1668 is not set CONFIG_SENSORS_MAX6639=m # CONFIG_SENSORS_MAX6642 is not set CONFIG_SENSORS_MAX6650=m # CONFIG_SENSORS_MCP3021 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_PCF8591=m CONFIG_PMBUS=m CONFIG_SENSORS_PMBUS=m # CONFIG_SENSORS_ADM1275 is not set # CONFIG_SENSORS_LM25066 is not set # CONFIG_SENSORS_LTC2978 is not set CONFIG_SENSORS_MAX16064=m CONFIG_SENSORS_MAX34440=m CONFIG_SENSORS_MAX8688=m # CONFIG_SENSORS_UCD9000 is not set # CONFIG_SENSORS_UCD9200 is not set # CONFIG_SENSORS_ZL6100 is not set CONFIG_SENSORS_SHT15=m CONFIG_SENSORS_SHT21=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_SMM665=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_EMC1403=m CONFIG_SENSORS_EMC2103=m # CONFIG_SENSORS_EMC6W201 is not set CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_SCH56XX_COMMON=m CONFIG_SENSORS_SCH5627=m # CONFIG_SENSORS_SCH5636 is not set CONFIG_SENSORS_ADS1015=m CONFIG_SENSORS_ADS7828=m CONFIG_SENSORS_AMC6821=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP102=m CONFIG_SENSORS_TMP401=m # CONFIG_SENSORS_TMP421 is not set CONFIG_SENSORS_VIA_CPUTEMP=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m # CONFIG_SENSORS_W83795 is not set CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_APPLESMC=m # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set CONFIG_SENSORS_ATK0110=m CONFIG_THERMAL=y CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m # CONFIG_F71808E_WDT is not set # CONFIG_SP5100_TCO is not set # CONFIG_SC520_WDT is not set CONFIG_SBC_FITPC2_WATCHDOG=m # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set CONFIG_IBMASR=m # CONFIG_WAFER_WDT is not set CONFIG_I6300ESB_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y CONFIG_IT8712F_WDT=m CONFIG_IT87_WDT=m CONFIG_HP_WATCHDOG=m CONFIG_HPWDT_NMI_DECODING=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_NV_TCO is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_SMSC_SCH311X_WDT=m # CONFIG_SMSC37B787_WDT is not set # CONFIG_VIA_WDT is not set CONFIG_W83627HF_WDT=m CONFIG_W83697HF_WDT=m CONFIG_W83697UG_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set CONFIG_XEN_WDT=m # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # CONFIG_MFD_CORE=m CONFIG_MFD_SM501=m # CONFIG_MFD_SM501_GPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_UCB1400_CORE is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TMIO is not set CONFIG_MFD_WM8400=m # CONFIG_MFD_PCF50633 is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set # CONFIG_MFD_TIMBERDALE is not set CONFIG_LPC_SCH=m # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_WL1273_CORE is not set CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set # CONFIG_REGULATOR_DUMMY is not set CONFIG_REGULATOR_FIXED_VOLTAGE=m # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set CONFIG_REGULATOR_USERSPACE_CONSUMER=m # CONFIG_REGULATOR_GPIO is not set # CONFIG_REGULATOR_AD5398 is not set # CONFIG_REGULATOR_ISL6271A is not set CONFIG_REGULATOR_MAX1586=m # CONFIG_REGULATOR_MAX8649 is not set # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8952 is not set CONFIG_REGULATOR_LP3971=m # CONFIG_REGULATOR_LP3972 is not set # CONFIG_REGULATOR_TPS62360 is not set CONFIG_REGULATOR_TPS65023=m CONFIG_REGULATOR_TPS6507X=m CONFIG_REGULATOR_WM8400=m CONFIG_MEDIA_SUPPORT=m # # Multimedia core support # # CONFIG_MEDIA_CONTROLLER is not set CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_DVB_CORE=m CONFIG_DVB_NET=y CONFIG_VIDEO_MEDIA=m # # Multimedia drivers # CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_RC_CORE=m CONFIG_LIRC=m CONFIG_RC_MAP=m CONFIG_IR_NEC_DECODER=m CONFIG_IR_RC5_DECODER=m CONFIG_IR_RC6_DECODER=m CONFIG_IR_JVC_DECODER=m CONFIG_IR_SONY_DECODER=m CONFIG_IR_RC5_SZ_DECODER=m CONFIG_IR_SANYO_DECODER=m CONFIG_IR_MCE_KBD_DECODER=m CONFIG_IR_LIRC_CODEC=m # CONFIG_RC_ATI_REMOTE is not set CONFIG_IR_ENE=m CONFIG_IR_IMON=m CONFIG_IR_MCEUSB=m CONFIG_IR_ITE_CIR=m # CONFIG_IR_FINTEK is not set CONFIG_IR_NUVOTON=m # CONFIG_IR_REDRAT3 is not set CONFIG_IR_STREAMZAP=m CONFIG_IR_WINBOND_CIR=m # CONFIG_RC_LOOPBACK is not set # CONFIG_IR_GPIO_CIR is not set CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m # CONFIG_MEDIA_TUNER_CUSTOMISE is not set CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_XC4000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_MEDIA_TUNER_MC44S803=m CONFIG_MEDIA_TUNER_MAX2165=m CONFIG_MEDIA_TUNER_TDA18218=m CONFIG_MEDIA_TUNER_TDA18212=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m # # Audio decoders, processors and mixers # CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m # # RDS decoders # CONFIG_VIDEO_SAA6588=m # # Video decoders # CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_TVP5150=m # # Video and audio decoders # CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_CX25840=m # # MPEG video encoders # CONFIG_VIDEO_CX2341X=m # # Video encoders # CONFIG_VIDEO_SAA7127=m # # Camera sensor devices # CONFIG_VIDEO_MT9V011=m # # Flash devices # # # Video improvement chips # CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m # # Miscelaneous helper chips # CONFIG_VIDEO_M52790=m # CONFIG_VIDEO_VIVI is not set CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_BENQ=m CONFIG_USB_GSPCA_CONEX=m CONFIG_USB_GSPCA_CPIA1=m CONFIG_USB_GSPCA_ETOMS=m CONFIG_USB_GSPCA_FINEPIX=m # CONFIG_USB_GSPCA_JEILINJ is not set # CONFIG_USB_GSPCA_JL2005BCD is not set # CONFIG_USB_GSPCA_KINECT is not set CONFIG_USB_GSPCA_KONICA=m CONFIG_USB_GSPCA_MARS=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_NW80X=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_OV534_9=m CONFIG_USB_GSPCA_PAC207=m CONFIG_USB_GSPCA_PAC7302=m CONFIG_USB_GSPCA_PAC7311=m # CONFIG_USB_GSPCA_SE401 is not set CONFIG_USB_GSPCA_SN9C2028=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SPCA1528=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_SQ930X=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_STV0680=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m # CONFIG_USB_GSPCA_TOPRO is not set CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m # CONFIG_USB_GSPCA_VICAM is not set CONFIG_USB_GSPCA_XIRLINK_CIT=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_EM28XX_RC=y CONFIG_VIDEO_TLG2300=m CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_RC=y CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m # CONFIG_VIDEO_TM6000 is not set CONFIG_VIDEO_USBVISION=m CONFIG_USB_ET61X251=m CONFIG_USB_SN9C102=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_PWC_INPUT_EVDEV=y # CONFIG_VIDEO_CPIA2 is not set CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_V4L_PCI_DRIVERS=y CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CX18_ALSA=m CONFIG_VIDEO_CX23885=m # CONFIG_MEDIA_ALTERA_CI is not set # CONFIG_VIDEO_CX25821 is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_HEXIUM_ORION is not set CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m # CONFIG_VIDEO_MEYE is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_SAA7134 is not set CONFIG_VIDEO_SAA7164=m # CONFIG_VIDEO_ZORAN is not set # CONFIG_V4L_ISA_PARPORT_DRIVERS is not set # CONFIG_V4L_PLATFORM_DRIVERS is not set # CONFIG_V4L_MEM2MEM_DRIVERS is not set # CONFIG_RADIO_ADAPTERS is not set CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # CONFIG_TTPCI_EEPROM=m CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m # CONFIG_DVB_USB_PCTV452E is not set CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_USB_CE6230=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_USB_EC168=m # CONFIG_DVB_USB_AZ6007 is not set CONFIG_DVB_USB_AZ6027=m CONFIG_DVB_USB_LME2510=m # CONFIG_DVB_USB_TECHNISAT_USB2 is not set # CONFIG_DVB_USB_IT913X is not set # CONFIG_DVB_USB_MXL111SF is not set # CONFIG_DVB_USB_RTL28XXU is not set CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_SMS_SIANO_MDTV=m # # Siano module components # CONFIG_SMS_USB_DRV=m CONFIG_SMS_SDIO_DRV=m # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported Pluto2 Adapters # CONFIG_DVB_PLUTO2=m # # Supported SDMC DM1105 Adapters # CONFIG_DVB_DM1105=m # # Supported FireWire (IEEE 1394) Adapters # CONFIG_DVB_FIREDTV=m CONFIG_DVB_FIREDTV_INPUT=y # # Supported Earthsoft PT1 Adapters # CONFIG_DVB_PT1=m # # Supported Mantis Adapters # # CONFIG_MANTIS_CORE is not set # # Supported nGene Adapters # CONFIG_DVB_NGENE=m # # Supported ddbridge ('Octopus') Adapters # # CONFIG_DVB_DDBRIDGE is not set # # Supported DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # Multistandard (satellite) frontends # CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_STV090x=m CONFIG_DVB_STV6110x=m # # Multistandard (cable + terrestrial) frontends # CONFIG_DVB_DRXK=m CONFIG_DVB_TDA18271C2DD=m # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_ZL10039=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TUNER_CX24113=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_SI21XX=m CONFIG_DVB_DS3000=m CONFIG_DVB_TDA10071=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_DRXD=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m CONFIG_DVB_AF9013=m CONFIG_DVB_EC100=m CONFIG_DVB_STV0367=m CONFIG_DVB_CXD2820R=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m # # ISDB-T (terrestrial) frontends # CONFIG_DVB_S921=m CONFIG_DVB_DIB8000=m CONFIG_DVB_MB86A20S=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m CONFIG_DVB_TUNER_DIB0090=m # # SEC control devices for DVB-S # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6421=m CONFIG_DVB_ISL6423=m CONFIG_DVB_A8293=m CONFIG_DVB_LGS8GXX=m CONFIG_DVB_ATBM8830=m CONFIG_DVB_IX2505V=m CONFIG_DVB_M88RS2000=m # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_AGP_VIA=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=64 # CONFIG_VGA_SWITCHEROO is not set CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set CONFIG_DRM_TTM=m # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y # CONFIG_DRM_NOUVEAU_DEBUG is not set # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_DRM_I810 is not set CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m # CONFIG_DRM_VMWGFX is not set # CONFIG_DRM_GMA500 is not set # CONFIG_DRM_UDL is not set # CONFIG_STUB_POULSBO is not set CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=m # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y CONFIG_FB_EFI=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_RIVA_BACKLIGHT=y # CONFIG_FB_I740 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y # CONFIG_FB_SIS is not set CONFIG_FB_VIA=m # CONFIG_FB_VIA_DIRECT_PROCFS is not set # CONFIG_FB_VIA_X_COMPATIBILITY is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_TMIO is not set CONFIG_FB_SM501=m # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set CONFIG_FB_VIRTUAL=m CONFIG_XEN_FBDEV_FRONTEND=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_EXYNOS_VIDEO is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_BACKLIGHT_PROGEAR=m # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # CONFIG_BACKLIGHT_LP855X is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y # CONFIG_SND_DEBUG_VERBOSE is not set CONFIG_SND_PCM_XRUN_DEBUG=y CONFIG_SND_VMASTER=y CONFIG_SND_KCTL_JACK=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_OPL3_LIB_SEQ=m # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set CONFIG_SND_EMU10K1_SEQ=m CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_ALOOP=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m # CONFIG_SND_MTS64 is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # CONFIG_SND_PORTMAN2X4 is not set CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5 CONFIG_SND_SB_COMMON=m CONFIG_SND_SB16_DSP=m CONFIG_SND_TEA575X=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set CONFIG_SND_ALI5451=m # CONFIG_SND_ASIHPI is not set CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m # CONFIG_SND_CMIPCI is not set CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m # CONFIG_SND_CS4281 is not set CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS5530=m CONFIG_SND_CS5535AUDIO=m CONFIG_SND_CTXFI=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_INDIGOIOX=m CONFIG_SND_INDIGODJX=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_ES1968_INPUT=y # CONFIG_SND_ES1968_RADIO is not set CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_PREALLOC_SIZE=64 CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_INPUT_BEEP_MODE=1 CONFIG_SND_HDA_INPUT_JACK=y # CONFIG_SND_HDA_PATCH_LOADER is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_ENABLE_REALTEK_QUIRKS=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_HDMI=y CONFIG_SND_HDA_CODEC_CIRRUS=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CA0110=y CONFIG_SND_HDA_CODEC_CA0132=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m # CONFIG_SND_LOLA is not set CONFIG_SND_LX6464ES=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MAESTRO3_INPUT=y CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_UA101=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SND_USB_6FIRE=m CONFIG_SND_FIREWIRE=y CONFIG_SND_FIREWIRE_LIB=m CONFIG_SND_FIREWIRE_SPEAKERS=m # CONFIG_SND_ISIGHT is not set CONFIG_SND_PCMCIA=y CONFIG_SND_VXPOCKET=m CONFIG_SND_PDAUDIOCF=m # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_BATTERY_STRENGTH is not set CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=y CONFIG_HID_ACRUX=m # CONFIG_HID_ACRUX_FF is not set CONFIG_HID_APPLE=y CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_PRODIKEYS=m CONFIG_HID_CYPRESS=y CONFIG_HID_DRAGONRISE=y CONFIG_DRAGONRISE_FF=y CONFIG_HID_EMS_FF=m CONFIG_HID_ELECOM=m CONFIG_HID_EZKEY=y # CONFIG_HID_HOLTEK is not set CONFIG_HID_KEYTOUCH=m CONFIG_HID_KYE=y CONFIG_HID_UCLOGIC=m CONFIG_HID_WALTOP=m CONFIG_HID_GYRATION=y CONFIG_HID_TWINHAN=y CONFIG_HID_KENSINGTON=y CONFIG_HID_LCPOWER=m CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=m CONFIG_LOGITECH_FF=y CONFIG_LOGIRUMBLEPAD2_FF=y CONFIG_LOGIG940_FF=y CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=m CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=m CONFIG_HID_NTRIG=y CONFIG_HID_ORTEK=m CONFIG_HID_PANTHERLORD=y CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=y CONFIG_HID_PICOLCD=m CONFIG_HID_PICOLCD_FB=y CONFIG_HID_PICOLCD_BACKLIGHT=y CONFIG_HID_PICOLCD_LCD=y CONFIG_HID_PICOLCD_LEDS=y # CONFIG_HID_PRIMAX is not set CONFIG_HID_ROCCAT=m # CONFIG_HID_SAITEK is not set CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y # CONFIG_HID_SPEEDLINK is not set CONFIG_HID_SUNPLUS=y CONFIG_HID_GREENASIA=y CONFIG_GREENASIA_FF=y CONFIG_HID_SMARTJOYPLUS=y CONFIG_SMARTJOYPLUS_FF=y # CONFIG_HID_TIVO is not set CONFIG_HID_TOPSEED=y CONFIG_HID_THRUSTMASTER=y CONFIG_THRUSTMASTER_FF=y CONFIG_HID_WACOM=m CONFIG_HID_WACOM_POWER_SUPPLY=y # CONFIG_HID_WIIMOTE is not set CONFIG_HID_ZEROPLUS=y CONFIG_ZEROPLUS_FF=y CONFIG_HID_ZYDACRON=m CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB_ARCH_HAS_XHCI=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_MON=y CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m # CONFIG_USB_WUSB_CBAF_DEBUG is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_XHCI_HCD=m # CONFIG_USB_XHCI_HCD_DEBUGGING is not set CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_ISP1362_HCD=m CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m # CONFIG_USB_SL811_HCD_ISO is not set # CONFIG_USB_SL811_CS is not set # CONFIG_USB_R8A66597_HCD is not set CONFIG_USB_WHCI_HCD=m CONFIG_USB_HWA_HCD=m CONFIG_XEN_USBDEV_FRONTEND=m CONFIG_XEN_USBDEV_BACKEND=m # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m CONFIG_USB_TMC=m # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set CONFIG_USB_STORAGE_DATAFAB=m CONFIG_USB_STORAGE_FREECOM=m CONFIG_USB_STORAGE_ISD200=m CONFIG_USB_STORAGE_USBAT=m CONFIG_USB_STORAGE_SDDR09=m CONFIG_USB_STORAGE_SDDR55=m CONFIG_USB_STORAGE_JUMPSHOT=m CONFIG_USB_STORAGE_ALAUDA=m CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # # USB port drivers # CONFIG_USB_USS720=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP210X=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_F81232 is not set CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m # CONFIG_USB_SERIAL_METRO is not set CONFIG_USB_SERIAL_MOS7720=m # CONFIG_USB_SERIAL_MOS7715_PARPORT is not set CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m # CONFIG_USB_SERIAL_QCAUX is not set CONFIG_USB_SERIAL_QUALCOMM=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIEMENS_MPI=m CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_SYMBOL=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_WWAN=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_OPTICON=m # CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set # CONFIG_USB_SERIAL_ZIO is not set # CONFIG_USB_SERIAL_SSU100 is not set CONFIG_USB_SERIAL_DEBUG=m # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_SEVSEG=m # CONFIG_USB_RIO500 is not set CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set CONFIG_USB_IOWARRIOR=m # CONFIG_USB_TEST is not set CONFIG_USB_ISIGHTFW=m # CONFIG_USB_YUREX is not set CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # CONFIG_USB_OTG_UTILS=y # CONFIG_USB_GPIO_VBUS is not set CONFIG_NOP_USB_XCEIV=m CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_I1480U=m CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # CONFIG_MMC_CLKGATE is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m # CONFIG_MMC_RICOH_MMC is not set CONFIG_MMC_SDHCI_PLTFM=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_MMC_SDRICOH_CS=m CONFIG_MMC_CB710=m CONFIG_MMC_VIA_SDMMC=m # CONFIG_MMC_VUB300 is not set CONFIG_MMC_USHC=m CONFIG_MEMSTICK=m # CONFIG_MEMSTICK_DEBUG is not set # # MemoryStick drivers # # CONFIG_MEMSTICK_UNSAFE_RESUME is not set CONFIG_MSPRO_BLOCK=m # # MemoryStick Host Controller Drivers # CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m # CONFIG_MEMSTICK_R592 is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_GPIO is not set CONFIG_LEDS_LP3944=m # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set CONFIG_LEDS_CLEVO_MAIL=m # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_PCA9633 is not set # CONFIG_LEDS_REGULATOR is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_DELL_NETBOOKS is not set # CONFIG_LEDS_TCA6507 is not set # CONFIG_LEDS_OT200 is not set CONFIG_LEDS_TRIGGERS=y # # LED Triggers # CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_BACKLIGHT=m # CONFIG_LEDS_TRIGGER_GPIO is not set CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # # iptables trigger is under Netfilter config (LED target) # # CONFIG_ACCESSIBILITY is not set CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_IPATH=m CONFIG_INFINIBAND_QIB=m # CONFIG_INFINIBAND_AMSO1100 is not set CONFIG_INFINIBAND_CXGB3=m # CONFIG_INFINIBAND_CXGB3_DEBUG is not set CONFIG_INFINIBAND_CXGB4=m CONFIG_MLX4_INFINIBAND=m CONFIG_INFINIBAND_NES=m # CONFIG_INFINIBAND_NES_DEBUG is not set CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y # CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set CONFIG_INFINIBAND_SRP=m # CONFIG_INFINIBAND_SRPT is not set CONFIG_INFINIBAND_ISER=m CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=m # CONFIG_EDAC_MCE_INJ is not set CONFIG_EDAC_MM_EDAC=m CONFIG_EDAC_AMD64=m # CONFIG_EDAC_AMD64_ERROR_INJECTION is not set CONFIG_EDAC_E752X=m CONFIG_EDAC_I82975X=m CONFIG_EDAC_I3000=m CONFIG_EDAC_I3200=m CONFIG_EDAC_X38=m CONFIG_EDAC_I5400=m CONFIG_EDAC_I7CORE=m CONFIG_EDAC_I5000=m CONFIG_EDAC_I5100=m CONFIG_EDAC_I7300=m # CONFIG_EDAC_SBRIDGE is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m # CONFIG_RTC_DRV_DS3232 is not set CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m # CONFIG_RTC_DRV_ISL12022 is not set CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set CONFIG_RTC_DRV_FM3130=m CONFIG_RTC_DRV_RX8581=m CONFIG_RTC_DRV_RX8025=m # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_STK17TA8=m # CONFIG_RTC_DRV_M48T86 is not set CONFIG_RTC_DRV_M48T35=m CONFIG_RTC_DRV_M48T59=m # CONFIG_RTC_DRV_MSM6242 is not set CONFIG_RTC_DRV_BQ4802=m # CONFIG_RTC_DRV_RP5C01 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_INTEL_MID_DMAC is not set CONFIG_INTEL_IOATDMA=m # CONFIG_TIMB_DMA is not set # CONFIG_PCH_DMA is not set CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y CONFIG_ASYNC_TX_DMA=y # CONFIG_DMATEST is not set CONFIG_DCA=m CONFIG_AUXDISPLAY=y CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=m CONFIG_CFAG12864B_RATE=20 CONFIG_UIO=m CONFIG_UIO_CIF=m CONFIG_UIO_PDRV=m CONFIG_UIO_PDRV_GENIRQ=m CONFIG_UIO_AEC=m CONFIG_UIO_SERCOS3=m CONFIG_UIO_PCI_GENERIC=m # CONFIG_UIO_NETX is not set CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m # CONFIG_VIRTIO_MMIO is not set # # Microsoft Hyper-V guest support # # CONFIG_HYPERV is not set # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=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_SWIOTLB_XEN=y CONFIG_XEN_TMEM=y CONFIG_XEN_PCIDEV_BACKEND=m CONFIG_XEN_PRIVCMD=m CONFIG_XEN_ACPI_PROCESSOR=y CONFIG_XEN_MCE_LOG=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set # CONFIG_USBIP_CORE is not set # CONFIG_W35UND is not set # CONFIG_PRISM2_USB is not set # CONFIG_ECHO is not set # CONFIG_COMEDI is not set # CONFIG_ASUS_OLED is not set # CONFIG_PANEL is not set # CONFIG_R8187SE is not set # CONFIG_RTL8192U is not set # CONFIG_RTLLIB is not set # CONFIG_R8712U is not set # CONFIG_RTS_PSTOR is not set # CONFIG_RTS5139 is not set # CONFIG_TRANZPORT is not set # CONFIG_IDE_PHISON is not set # CONFIG_LINE6_USB is not set # CONFIG_USB_SERIAL_QUATECH2 is not set # CONFIG_USB_SERIAL_QUATECH_USB2 is not set # CONFIG_VT6655 is not set # CONFIG_VT6656 is not set # CONFIG_VME_BUS is not set # CONFIG_DX_SEP is not set # CONFIG_IIO is not set CONFIG_ZRAM=y CONFIG_ZRAM_DEBUG=y CONFIG_ZCACHE=y CONFIG_ZSMALLOC=y # CONFIG_WLAGS49_H2 is not set # CONFIG_WLAGS49_H25 is not set # CONFIG_FB_SM7XX is not set # CONFIG_CRYSTALHD is not set # CONFIG_CXT1E1 is not set # CONFIG_FB_XGI is not set # CONFIG_ACPI_QUICKSTART is not set # CONFIG_SBE_2T3E3 is not set # CONFIG_USB_ENESTORAGE is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_INTEL_MEI is not set # CONFIG_STAGING_MEDIA is not set # # Android # # CONFIG_ANDROID is not set # CONFIG_PHONE is not set # CONFIG_USB_WPAN_HCD is not set CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACER_WMI=m CONFIG_ACERHDF=m CONFIG_ASUS_LAPTOP=m CONFIG_DELL_LAPTOP=m CONFIG_DELL_WMI=m # CONFIG_DELL_WMI_AIO is not set CONFIG_FUJITSU_LAPTOP=m # CONFIG_FUJITSU_LAPTOP_DEBUG is not set # CONFIG_FUJITSU_TABLET is not set # CONFIG_AMILO_RFKILL is not set # CONFIG_HP_ACCEL is not set CONFIG_HP_WMI=m CONFIG_MSI_LAPTOP=m CONFIG_PANASONIC_LAPTOP=m CONFIG_COMPAL_LAPTOP=m CONFIG_SONY_LAPTOP=m CONFIG_SONYPI_COMPAT=y # CONFIG_IDEAPAD_LAPTOP is not set CONFIG_THINKPAD_ACPI=m CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y # CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set # CONFIG_THINKPAD_ACPI_DEBUG is not set # CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_SENSORS_HDAPS=m # CONFIG_INTEL_MENLOW is not set # CONFIG_EEEPC_LAPTOP is not set # CONFIG_ASUS_WMI is not set CONFIG_ACPI_WMI=m CONFIG_MSI_WMI=m # CONFIG_TOPSTAR_LAPTOP is not set CONFIG_ACPI_TOSHIBA=m CONFIG_TOSHIBA_BT_RFKILL=m CONFIG_ACPI_CMPC=m CONFIG_INTEL_IPS=m CONFIG_IBM_RTL=m CONFIG_XO15_EBOOK=m CONFIG_SAMSUNG_LAPTOP=m CONFIG_MXM_WMI=m # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set # CONFIG_APPLE_GMUX is not set # # Hardware Spinlock drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y # CONFIG_AMD_IOMMU_V2 is not set # CONFIG_INTEL_IOMMU is not set # CONFIG_IRQ_REMAP is not set # # Remoteproc drivers (EXPERIMENTAL) # # # Rpmsg drivers (EXPERIMENTAL) # # CONFIG_VIRT_DRIVERS is not set # CONFIG_PM_DEVFREQ is not set # # Firmware Drivers # CONFIG_EDD=m # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=y CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y CONFIG_DMI_SYSFS=m CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_GOOGLE_FIRMWARE is not set # # File systems # CONFIG_DCACHE_WORD_ACCESS=y CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_FS_XIP=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=m # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_DLM=y CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m CONFIG_OCFS2_FS_STATS=y CONFIG_OCFS2_DEBUG_MASKLOG=y # CONFIG_OCFS2_DEBUG_FS is not set CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_CUSE=m CONFIG_GENERIC_ACL=y # # Caches # CONFIG_FSCACHE=m CONFIG_FSCACHE_STATS=y # CONFIG_FSCACHE_HISTOGRAM is not set # CONFIG_FSCACHE_DEBUG is not set # CONFIG_FSCACHE_OBJECT_LIST is not set CONFIG_CACHEFILES=m # CONFIG_CACHEFILES_DEBUG is not set # CONFIG_CACHEFILES_HISTOGRAM is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_ECRYPT_FS=m # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_WRITEBUFFER=y # CONFIG_JFFS2_FS_WBUF_VERIFY is not set CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y # CONFIG_JFFS2_LZO is not set CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set CONFIG_UBIFS_FS=m CONFIG_UBIFS_FS_XATTR=y # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set CONFIG_UBIFS_FS_LZO=y CONFIG_UBIFS_FS_ZLIB=y # CONFIG_UBIFS_FS_DEBUG is not set # CONFIG_LOGFS is not set CONFIG_CRAMFS=m CONFIG_SQUASHFS=m # CONFIG_SQUASHFS_XATTR is not set CONFIG_SQUASHFS_ZLIB=y # CONFIG_SQUASHFS_LZO is not set # CONFIG_SQUASHFS_XZ is not set # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX6FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_PSTORE=y # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # CONFIG_EXOFS_FS is not set CONFIG_ORE=m CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_PNFS_FILE_LAYOUT=m CONFIG_PNFS_BLOCK=m CONFIG_PNFS_OBJLAYOUT=m CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org" CONFIG_NFS_FSCACHE=y CONFIG_NFS_USE_LEGACY_DNS=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y # CONFIG_NFSD_FAULT_INJECTION is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BACKCHANNEL=y CONFIG_SUNRPC_XPRT_RDMA=m CONFIG_RPCSEC_GSS_KRB5=m # CONFIG_SUNRPC_DEBUG is not set # CONFIG_CEPH_FS is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_DFS_UPCALL=y # CONFIG_CIFS_FSCACHE is not set CONFIG_CIFS_ACL=y # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y CONFIG_STRIP_ASM_SYMS=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y CONFIG_HEADERS_CHECK=y CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DEBUG_LIST=y # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_CPU_STALL_INFO is not set # CONFIG_RCU_TRACE is not set # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_LKDTM is not set # CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set # CONFIG_FAULT_INJECTION is not set CONFIG_LATENCYTOP=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set CONFIG_RING_BUFFER_BENCHMARK=m CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set CONFIG_BUILD_DOCSRC=y CONFIG_DYNAMIC_DEBUG=y # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_ASYNC_RAID6_TEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set # CONFIG_KGDB_LOW_LEVEL_TRAP is not set # CONFIG_KGDB_KDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y # CONFIG_TEST_KSTRTOX is not set CONFIG_STRICT_DEVMEM=y # CONFIG_X86_VERBOSE_BOOTUP is not set CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_DEBUG_SET_MODULE_RONX is not set CONFIG_DEBUG_NX_TEST=m # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set # CONFIG_DEBUG_NMI_SELFTEST is not set # # Security options # CONFIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y # CONFIG_SECURITY_PATH is not set CONFIG_LSM_MMAP_MIN_ADDR=65535 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_SECURITY_YAMA is not set CONFIG_INTEGRITY=y # CONFIG_INTEGRITY_SIGNATURE is not set CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 CONFIG_IMA_AUDIT=y CONFIG_IMA_LSM_RULES=y # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_FIPS=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m # # Block modes # CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m # # Hash modes # CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA1_SSSE3 is not set CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_CAMELLIA_X86_64 is not set CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m # CONFIG_CRYPTO_SALSA20 is not set CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m # CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set CONFIG_CRYPTO_TEA=m # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=y # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m # CONFIG_KVM_MMU_AUDIT is not set CONFIG_VHOST_NET=m CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_IO=y CONFIG_CRC_CCITT=m CONFIG_CRC16=y CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC7=m CONFIG_LIBCRC32C=m # CONFIG_CRC8 is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=m CONFIG_REED_SOLOMON_DEC16=y CONFIG_BCH=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPUMASK_OFFSTACK=y CONFIG_CPU_RMAP=y CONFIG_DQL=y CONFIG_NLATTR=y CONFIG_LRU_CACHE=m CONFIG_AVERAGE=y # CONFIG_CORDIC is not set _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 21:45:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21:45:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVk9-0000yZ-Dw; Mon, 07 May 2012 21:45:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVk7-0000yM-DJ for xen-devel@lists.xen.org; Mon, 07 May 2012 21:45:20 +0000 Received: from [85.158.139.83:46798] by server-6.bemta-5.messagelabs.com id 24/0C-13222-E6248AF4; Mon, 07 May 2012 21:45:18 +0000 X-Env-Sender: Wei.Huang2@amd.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336427113!27086760!1 X-Originating-IP: [216.32.181.183] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20573 invoked from network); 7 May 2012 21:45:15 -0000 Received: from ch1ehsobe003.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.183) by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 7 May 2012 21:45:15 -0000 Received: from mail171-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012 21:45:00 +0000 Received: from mail171-ch1 (localhost [127.0.0.1]) by mail171-ch1-R.bigfish.com (Postfix) with ESMTP id E54A44E0608; Mon, 7 May 2012 21:44:59 +0000 (UTC) X-SpamScore: -17 X-BigFish: VPS-17(zzbb2dI9371Ic85fh14e3M98dK11f6N4015Izz1202hzz8275bh8275dhc704dhz2dh668h839hd25h) 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-ch1 (localhost.localdomain [127.0.0.1]) by mail171-ch1 (MessageSwitch) id 1336427096442035_5786; Mon, 7 May 2012 21:44:56 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail171-ch1.bigfish.com (Postfix) with ESMTP id 651662E00FF; Mon, 7 May 2012 21:44:56 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012 21:44:55 +0000 X-WSS-ID: 0M3O9R4-01-EHX-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 2EECD10281B9; Mon, 7 May 2012 16:45:03 -0500 (CDT) Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 7 May 2012 16:45:10 -0500 Received: from SAUSEXDAG03.amd.com ([fe80::85b5:3838:d8b4:20ba]) by sausexdag02.amd.com ([fe80::ed3c:9786:3083:dd99%21]) with mapi id 14.01.0323.003; Mon, 7 May 2012 16:45:03 -0500 From: "Huang2, Wei" To: "Teo En Ming (Zhang Enming)" Thread-Topic: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation Thread-Index: AQHNDVKcjm0Cx8zTR06RHTP4MgG7OZaBAluAgAC+IACAAC4WgP//xyKAgABpY4D//8aFgIAAtlQAgABPPICAO3ZUgIAAtl4Q Date: Mon, 7 May 2012 21:44:48 +0000 Message-ID: <4400B41FB768044EA720935D0808176C0911799D@sausexdag03.amd.com> References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F74EA35.4030305@amd.com> <4F753CD8.4050300@gmail.com> <4F75C59F.8030407@amd.com> <4FA760B9.4060501@gmail.com> In-Reply-To: <4FA760B9.4060501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.236.48.215] MIME-Version: 1.0 X-OriginatorOrg: amd.com Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , 'Teo En Ming' , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4355524141628207631==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4355524141628207631== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_" --_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I didn't ask them to include this patch in Xen 4.2. If you have an AMD = GPU, you can try it as a secondary passthru without VBIOS patch. Most of th= em will work from what I heard. Thanks, -Wei From: Teo En Ming (Zhang Enming) [mailto:singapore.mr.teo.en.ming@gmail.com= ] Sent: Monday, May 07, 2012 12:42 AM To: Huang2, Wei Cc: Casey DeLorme; xen-users@lists.xen.org; Tobias Geiger; xen-devel@lists.= xen.org; 'Teo En Ming' Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Att= empt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation On 30/03/2012 22:39, Wei Huang wrote: On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote: On 30/03/2012 07:03, Wei Huang wrote: On 03/29/2012 04:29 PM, Casey DeLorme wrote: David, XenServer VGA Passthrough requires a paid/licensed copy, which costs $2500,= a bit out of my price range for experimentation. Important to note that t= he feature is not a part of the 30-day trial license. However, Citrix recently visited my college and I was able to preview hardw= are access on a laptop one of the employees had, where they swapped between= Ubuntu and Windows with a hotkey, and various hardware components includin= g onboard GPU and the WebCam were accessible. In testing XenServer, I can say that if I had a business, that's the produc= t I would use. In the past month having tried Xen and ESXi, I was astonish= ed with the ease of use for XenServer. As for Catalyst, version 12.2 (the latest currently) worked for me. Important to note that until I followed Andrews advice to omit the Catalyst= Control Center, the installation resulted in a BSOD. I saw similar issue whiling playing with XenClient. After discussing with A= MD GPU driver team, the conclusion was that the installer has a bug. But I = have not received any further update from them. Also manual driver installa= tion (after many tries) did fix problem for me. The solution, select "Custom" installation and uncheck the CCC. After the = installation your first reboot should run some follow-up updates via cmd, y= ou need to reboot a second time for fully functional drivers. Also, I had underscan on my monitor so I went out on a limb and re-ran the = setup for Catalyst, and was able to get CCC installed with a second run thr= ough, which allowed me to fix my underscan issue. My conclusion is that the CCC requires some driver functionality that isn't= available until after you install the drivers, this could be on all system= s or it might be related to how HVM's handle the PCI devices, that much I c= an't say. Teo, I could be spouting nonsense, and if so I'm sure Wei can correct me, but I = am pretty sure AMD engineers have been contributing to Xen for a while, and= some patches have already been applied. Obviously it isn't flawless, I my= self haven't gotten video at boot time, only at the login screen. This is because VBIOS patch wasn't applied. But as I said before, my VBIOS = wasn't universal enough to put it as a production patch. So I am hesitant t= o put it out. Dear Wei Huang at AMD Corporation, Please put your Xen VGA Passthrough patch out so that all of us can have a = try. Thank you very much. http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.h= tml Dear Wei Huang, Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tr= ee? Thank you. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Mine works on 4.1.2, but it is possible that 4.1.0 had less of these "patch= es" hence Sebastien's post. Also, I apologize as I did not properly word my opinion before. VGA Passth= rough is new "for consumer components". In 2010 the number of desktop (not= server) boards boasting VT-d functionality could probably be counted on on= e hand. To my understanding that means the technology is at most 3 years o= ld, still a baby in my opinion. I didn't mean that the technology hadn't been implemented into various Hype= rvisors, just that it is clearly not a perfected feature. If you consider = 3 years of consumer availability, dates become important when researching. = Sebastien's post was May 2011, just shy of one year ago, and Thomas's was = in 2010. There are newer patches still for ATI in Xen 4.2, which I intend to test ov= er the next week. I have NOT gotten ATI to work at boot time, video starts= at the login screen. I agree with Wei that drivers can contribute to BSOD's and errors, but when= an install doesn't fail but the hardware reacts the same as before, I woul= d like to assume the driver is irrelative. Have you looked at XenClient project? It has a customized ATI component whi= ch allows you to switch between VMs flawlessly. I think it is the most matu= re Xen solution for GPU passthru in client area. Dear Wei Huang at AMD Corporation, May I know what is the XenClient project? ~Casey On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang > wrote: On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: Dear Casey DeLorme, This guy, Sebastien Gauthier, also has the same problems as us. He was usin= g Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After= installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA= Passthrough to Windows 7. Please read Sebastien Gauthier's case here: http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS,= like us. Dear Tobias Geiger, You were saying that with ATI VGA cards, you do not need to apply any Xen V= GA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Hua= ng's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst driv= ers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough t= o Windows 7 using an ATI VGA card. Hi Teo, The VBIOS patch I sent out did not work for all ATI cards. The patch itself= assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU= generation. From this perspective, my patch isn't universal. Also there ar= e many factors, some of which are not in control by us (like graphics drive= r), can contribute to BSOD you mentioned. I am not in a position to debug i= t for everyone's card (as I don't have all cards). Thanks, -Wei -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: On 29/03/2012 12:29, Casey DeLorme wrote: My mistake for not hitting "Reply to All", sorry. No worries Casey. It might be of some value to mention that my tests were with Windows 7, I h= ave no interest in using XP anymore. Also, I did all of my testing through= remote VNC, not once did I actually get video, even 2D, working. I bought 2 copies of Windows XP Home Edition in the past because it is chea= p, at S$145. I did not buy Windows 7 because it is expensive. I got video w= orking all right, but only 2D. I cannot get 3D graphics working. However, my errors are exactly as you described: 1. Windows recognizes the model (GTX 460), not "unknown PCI device". 2. Device code 43. 3. No resources assigned to the device. We have the same set of errors. Might be worth mentioning, I was able to run the latest nVidia driver insta= llation without errors, but after rebooting there was no change, same error= code, still no video. Same situation here with the latest NVIDIA drivers. But I only have 2D vide= o working. I can't get 3D video to work. To me this would be evidence that driver version isn't a problem, but then= again I didn't have anything actually working. I agree that driver version isn't a problem. Something is wrong somewhere. I am an IT student in college, so my experience is limited to mostly progra= mming with very little knowledge of the inner-workings of hardware. So, fo= rgive me for being unable to help with regards to memory addresses on the c= ards. I am hoping that Intel engineers and Xen developers would be able to help. I've been using *nix for about 4 years, and Windows since I my age was a si= ngle digit. I have had experience setting up server features such as web, = database, and application servers but I am still green when it comes to ker= nel or hardware configuration. I started learning Linux/UNIX since the year 2005, that is about 7 years ag= o. I started using Windows when it was version 3.1. I love compiling the la= test Linux kernel and assembling my own computer hardware. My Xen adventure began 35 days ago, and it is no exaggeration to say that i= n those 35 days I have learned more about linux than I had in the past two = years. I like challenges as much as the next IT person, but I ran out of t= ime and ideas for debugging my nVidia problems. The nVidia stretch of my a= dventure lasted for 24 days through 54 fresh linux installations accompanie= d by over 200~ pages worth of documented failures and not a single pixel si= ghted. Why not make your documentation into PDF? It is a very popular document for= mat. The ATI card took me a day, less than 12 hours of relatively easy debugging= by comparison to the aforementioned testing. I do fully understanding fin= ancial constraints, but it is a working solution and worth mentioning. I d= o not know what the prices are like in Singapore, but in the states I was a= ble to buy an ATI Radeon HD 6870 for $160. For me it came down to weighing= my objectives against my curiosity. That ATI Radeon HD 6870 would cost me $279, I think. If you do continue your nVidia endeavors I wish you success, but as in my f= ormer email VGA passthrough is a new frontier, not even Guru's like David m= ay not be able to help beyond their own hardware experiences. I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linu= x KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out o= f the box, as Tobias Geiger suggested, but NVIDIA requires patches. Documentation is one problem I agree with you on 100%. I came into this kn= owing relatively little about Linux & hardware, and nothing about Xen, and = most every guide I found assumed I had been in a deep relationship with Lin= ux for many years and had a basic understanding of Xen commands. I started learning Xen since the year 2007, which is about 5 years ago. Like you, I intend to use those documented failures as well as my recent su= ccess to create a comprehensive guide with photographs, screen captures, an= d perhaps even videos going from "assembled computer" to "Complete Xen Dom0= /w HVM & VGA Passthrough". Provided the wiki will allow me to upload the = screenshots, I'll be certain to post it there. I will be looking forward to your documentation and videos. Right now Xen w= iki allows uploading image files and PDF files. Why not create a PDF docume= nt and share it with all of us? It is known as portable document format and= is very popular, but it appears that xen mailing lists don't like PDF form= at. I don't like wiki pages because anybody can edit and fundamentally mess up = the wiki pages, even providing bogus and erroneous information. That's why = I don't like creating wiki pages. Anybody can edit and mess up the informat= ion you have painstakingly created on the wiki pages. So please take note. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore ~Casey On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) > wrote: Dearest Casey DeLorme, Thank you very very much for your kind feedback and input. I would also lik= e to thank Mr. Tobias Geiger, again, for providing his suggestion on exposi= ng the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In a= ny case, either exposing the first 3 memory regions only or exposing all th= e 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me= further. I have asked Jean David Techer, what about the 4th PCI memory region? Why o= nly expose the first 3 PCI memory regions? I don't understand, of course. J= ean David Techer did not reply to my question. I have decided to post your prompt reply to the xen-users and xen-devel mai= ling lists, in case people think that I am finding fault with Jean David Te= cher, or trying to irritate him, or trying to make him angry, or trying to = aggravate him. Jean David Techer replied me with an email saying that I spe= nt too much time and too bent on solving the yellow exclamation mark glitch= for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Previ= ew and Windows XP Home Edition, and that I sent stupid requests. Stupid req= uests? Did he read my emails carefully, word by word? Casey DeLorme, please, can I confirm with you again that you are getting th= e following errors after applying Jean David Techer's Xen 4.2-unstable VGA = Passthrough patches: (1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager (2) Windows has stopped this device because it has reported problems. (Code= 43) (3) This device isn't using any resources because it has a problem. Jean David Techer insists that our technical issues are due to a NVIDIA dri= ver problem. He insists that you have to install NVIDIA driver versions 275= .33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) w= ill not work, according to Jean David Techer. However, I have tried install= ing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Editi= on HVM virtual machine to be destroyed/terminated/crash after a few minutes= and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for= Windows XP 32-bit is not available from the official NVIDIA website. So it is definitely not a NVIDIA driver problem. I suspect that the technic= al issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think the= re is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA car= ds, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM= , or Electrically Erasable Programmable Read Only Memory. Secondly, it does seem strange that Jean David Techer was able to attain 10= 0%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Window= s XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is = only 4 minutes. Please do watch Jean David Techer's Youtube video at the fo= llowing URL: Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM = domU Youtube video link: http://www.youtube.com/watch?v=3D3SaYO0ERW44 I am appalled and baffled that he has attained 100% success while both of u= s have only attained partial success (i.e. less than 100%) on Xen 4.2-unsta= ble VGA Passthrough to Windows 8 Consumer Preview and Windows XP. Solving the yellow exclamation mark issue is important because we would not= be able to run 3D graphics benchmarks and play 3D games without solving it= . I am not sending silly emails about some yellow marks, as Jean David Tech= er suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display= benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400= GS in Device Manager. Casey DeLorme, with your report on relatively easy success with ATI VGA car= ds, I think I would go the ATI way, but I would have to spend a few hundred= dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while= deciding to go the ATI way, I would also like to continue troubleshooting = with the NVIDIA problem, because I consider it to be a technical challenge. In essence, Jean David Techner is considered to be a "boss", or business ow= ner, or proprietor, or technopreneur, or entrepreneur, or technical support= officer, or customer support officer, or IT helpdesk engineer, providing s= ervices like his forward-ported Xen 4.2-unstable VGA Passthrough patches an= d the documentation on his blog. I repost Jean David Techer's official webs= ite here: Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.david= gis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-th= rough Jean David Techer's official website is his business venture. Basically, I am Jean David Techer's "customer", trying to obtain technical = support from him. Of course, he is not obliged to provide technical support= to me since he is providing free services. It is, after all, an open sourc= e software project. Nobody is obliged to provide anybody with technical sup= port. To do Jean David Techer justice, he replied most of my questions whil= e avoiding some of my questions. Finally, I have also failed to obtain technical support from Xen developers= like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corp= oration. I have always provided all the steps which I have taken, the confi= guration files and necessary documentation, and kernel messages and error l= ogs to xen-users and xen-devel mailing lists, but they keep insisting I did= not provide the information they required. I wondered why. I think they di= d not read my emails carefully. They told me they would not reply to me any= more if I do not provide the information they requested. But the problem i= s that I have always provided information they requested! I think they miss= ed some of my emails, or did not read my emails carefully enough. I am an a= rdent supporter and SERIOUS software tester for open source Xen virtualizat= ion/hypervisor but they treated me lightly. I always read my emails WORD BY= WORD. I have even went to the point of making a video on the BUG and uploa= ding my video to Youtube. The video is only THREE minutes. As everybody says, a picture is worth a thousand words. A video is worth a = BILLION words! I have also failed to obtain technical support from Xen developers regardin= g Xen 4.2-unstable VGA Passthrough. I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for= both NVIDIA and ATI cards. Casey DeLorme, thank you very much once again. I will be making changes to = my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be rele= asing Version 1.7 shortly. Jean David Techer's documentation assumes some l= evel of advanced Linux technical knowledge, so I am writing documentation o= n my own so that everybody, not just advanced Linux and Xen users, can foll= ow. I have made references to Jean David Techer's documentation in my own d= ocumentation. I would be very happy if people would use my documentation. Of course, it s= atisfies my ego and my vanity. Haha. I have been un-employed for nearly three years now, and I would hesitate to= spend a few hundred dollars on an ATI VGA card. I quit my job as an IT eng= ineer 3 years ago because my father suffered from lacunar infarct, or more = commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please= understand why I hesitate to buy an ATI VGA card. The cheapest one costs S= GD$279. I have a diploma in Mechanical+Electronics engineering from Singapore Polyt= echnic and a Bachelor's degree in Mechanical Engineering from the National = University of Singapore. But I do not have qualifications in Computer Scien= ce or Information Technology. I have worked as an Information Technology en= gineer in Defense Science and Technology Agency, Ministry of Defense, Singa= pore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishin= emax Singapore Pte Ltd. Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's= Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable = VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Ma= chines Thank you very much for reading my lengthy email. I am always courteous, sa= ying "Please help me. Please. Please. Please." and "Thank you very much for= your kind assistance" in my emails. Thank you very much. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Citizen cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's= Office, Republic of Singapore On 29/03/2012 03:53, Casey DeLorme wrote: Hi Teo, I tried David's patch files a while ago without success. I had Xen compile= d with the patch files and my GTX 460 VGA BIOS rom, but I got the same as y= ou, either a BSOD or Code 43 in Device Manager. You sound plenty competent, but it's important to remember that you are pio= neering a technology that for consumers is still in its infancy. Very few = people are testing this with consumer equipment, so finding results seems t= o be a rarity. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I didn’t ask th= em to include this patch in Xen 4.2. If you have an AMD GPU, you can try it= as a secondary passthru without VBIOS patch. Most of them will work from what I heard.

 <= /p>

Thanks,=

-Wei

 <= /p>

From: Teo En Ming (Zhang Enming) [mailto:singapore.mr.t= eo.en.ming@gmail.com]
Sent: Monday, May 07, 2012 12:42 AM
To: Huang2, Wei
Cc: Casey DeLorme; xen-users@lists.xen.org; Tobias Geiger; xen-devel= @lists.xen.org; 'Teo En Ming'
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users= to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentat= ion

 

On 30/03/2012 22:39, Wei Huang wrote:

On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) w= rote:

On 30/03/2012 07:03, Wei Huang wrote:

On 03/29/2012 04:29 PM, Casey DeLorme wrote:

David,

 

XenServer VGA Passthrough requires a paid/licensed c= opy, which costs $2500, a bit out of my price range for experimentation. &n= bsp;Important to note that the feature is not a part of the 30-day trial li= cense.

 

However, Citrix recently visited my college and I wa= s able to preview hardware access on a laptop one of the employees had, whe= re they swapped between Ubuntu and Windows with a hotkey, and various hardw= are components including onboard GPU and the WebCam were accessible.

 

In testing XenServer, I can say that if I had a busi= ness, that's the product I would use.  In the past month having tried = Xen and ESXi, I was astonished with the ease of use for XenServer.

 

As for Catalyst, version 12.2 (the latest currently)= worked for me.

 

Important to note that until I followed Andrews advi= ce to omit the Catalyst Control Center, the installation resulted in a BSOD= .

I saw similar issue whiling playing with XenClient. = After discussing with AMD GPU driver team, the conclusion was that the inst= aller has a bug. But I have not received any further update from them. Also= manual driver installation (after many tries) did fix problem for me.

 

The solution, select "Custom" installation= and uncheck the CCC.  After the installation your first reboot should= run some follow-up updates via cmd, you need to reboot a second time for f= ully functional drivers.

 

Also, I had underscan on my monitor so I went out on= a limb and re-ran the setup for Catalyst, and was able to get CCC installe= d with a second run through, which allowed me to fix my underscan issue.

 

My conclusion is that the CCC requires some driver f= unctionality that isn't available until after you install the drivers, this= could be on all systems or it might be related to how HVM's handle the PCI= devices, that much I can't say.

 

 

 

Teo,

 

I could be spouting nonsense, and if so I'm sure Wei= can correct me, but I am pretty sure AMD engineers have been contributing = to Xen for a while, and some patches have already been applied.  Obvio= usly it isn't flawless, I myself haven't gotten video at boot time, only at the login screen.

 

This is because VBIOS patch wasn't applied. But as I= said before, my VBIOS wasn't universal enough to put it as a production pa= tch. So I am hesitant to put it out.


Dear Wei Huang at AMD Corporation,

Please put your Xen VGA Passthrough patch out so that all of us can have a = try.

Thank you very much.

http://old-list-archives.xen.org/arc= hives/html/xen-devel/2010-10/msg00284.html



Dear Wei Huang,

Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tr= ee?

Thank you.



-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore



Mine works on 4.1.2, but it is possible that 4.1.0 h= ad less of these "patches" hence Sebastien's post.

 

Also, I apologize as I did not properly word my opin= ion before.  VGA Passthrough is new "for consumer components"= ;.  In 2010 the number of desktop (not server) boards boasting VT-d fu= nctionality could probably be counted on one hand.  To my understanding that means the technology is at most 3 years old, still a= baby in my opinion.

 

I didn't mean that the technology hadn't been implem= ented into various Hypervisors, just that it is clearly not a perfected fea= ture.  If you consider 3 years of consumer availability, dates become = important when researching.  Sebastien's post was May 2011, just shy of one year ago, and Thomas's was in 2010.

 

There are newer patches still for ATI in Xen 4.2, wh= ich I intend to test over the next week.  I have NOT gotten ATI to wor= k at boot time, video starts at the login screen.

 

I agree with Wei that drivers can contribute to BSOD= 's and errors, but when an install doesn't fail but the hardware reacts the= same as before, I would like to assume the driver is irrelative.

 

Have you looked at XenClient project? It has a custo= mized ATI component which allows you to switch between VMs flawlessly. I th= ink it is the most mature Xen solution for GPU passthru in client area.


Dear Wei Huang at AMD Corporation,

May I know what is the XenClient project?



 

~Casey

 

On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang <wei.huang2@amd.com&g= t; wrote:

On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) w= rote:

Dear Casey DeLorme,
This guy, Sebastien Gauthier, also has the same problems as us. He was usin= g Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After= installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA= Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-= users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS,= like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen V= GA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Hua= ng's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst driv= ers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA ca= rd.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself= assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU= generation. From this perspective, my patch isn't universal. Also there ar= e many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you me= ntioned. I am not in a position to debug it for everyone's card (as I don't= have all cards).

Thanks,
-Wei 



-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore





On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:

On 29/03/2012 12:29, Casey DeLorme wrote:

My mistake for not hitting "Reply to All",= sorry.


No worries Casey.


 

It might be of some value to mention that my tests w= ere with Windows 7, I have no interest in using XP anymore.  Also, I d= id all of my testing through remote VNC, not once did I actually get video,= even 2D, working. 


I bought 2 copies of Windows XP Home Edition in the past because it is chea= p, at S$145. I did not buy Windows 7 because it is expensive. I got video w= orking all right, but only 2D. I cannot get 3D graphics working.


However, my errors are exactly as you described:

 

1.  Windows recognizes the model (GTX 460), not= "unknown PCI device".

2.  Device code 43.

3.  No resources assigned to the device.


We have the same set of errors.


 

Might be worth mentioning, I was able to run the lat= est nVidia driver installation without errors, but after rebooting there wa= s no change, same error code, still no video.


Same situation here with the latest NVIDIA drivers. But I only have 2D vide= o working. I can't get 3D video to work.


 To me this would be evidence that driver versi= on isn't a problem, but then again I didn't have anything actually working.=


I agree that driver version isn't a problem. Something is wrong somewhere.<= br>

 

 

I am an IT student in college, so my experience is l= imited to mostly programming with very little knowledge of the inner-workin= gs of hardware.  So, forgive me for being unable to help with regards = to memory addresses on the cards.


I am hoping that Intel engineers and Xen developers would be able to help.<= br>

 

I've been using *nix for about 4 years, and Windows = since I my age was a single digit.  I have had experience setting up s= erver features such as web, database, and application servers but I am stil= l green when it comes to kernel or hardware configuration.


I started learning Linux/UNIX since the year 2005, that is about 7 years ag= o. I started using Windows when it was version 3.1. I love compiling the la= test Linux kernel and assembling my own computer hardware.


 

My Xen adventure began 35 days ago, and it is no exa= ggeration to say that in those 35 days I have learned more about linux than= I had in the past two years.  I like challenges as much as the next I= T person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure= lasted for 24 days through 54 fresh linux installations accompanied by ove= r 200~ pages worth of documented failures and not a single pixel sighted.


Why not make your documentation into PDF? It is a very popular document for= mat.


 

The ATI card took me a day, less than 12 hours of re= latively easy debugging by comparison to the aforementioned testing.  = I do fully understanding financial constraints, but it is a working solutio= n and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy= an ATI Radeon HD 6870 for $160.  For me it came down to weighing my o= bjectives against my curiosity.


That ATI Radeon HD 6870 would cost me $279, I think.


 

If you do continue your nVidia endeavors I wish you = success, but as in my former email VGA passthrough is a new frontier, not e= ven Guru's like David may not be able to help beyond their own hardware exp= eriences.


I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linu= x KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out o= f the box, as Tobias Geiger suggested, but NVIDIA requires patches.


 

 

Documentation is one problem I agree with you on 100= %.  I came into this knowing relatively little about Linux & hardw= are, and nothing about Xen, and most every guide I found assumed I had been= in a deep relationship with Linux for many years and had a basic understanding of Xen commands.


I started learning Xen since the year 2007, which is about 5 years ago.


 

Like you, I intend to use those documented failures = as well as my recent success to create a comprehensive guide with photograp= hs, screen captures, and perhaps even videos going from "assembled com= puter" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the scr= eenshots, I'll be certain to post it there.


I will be looking forward to your documentation and videos. Right now Xen w= iki allows uploading image files and PDF files. Why not create a PDF docume= nt and share it with all of us? It is known as portable document format and= is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally me= ss up the wiki pages, even providing bogus and erroneous information. That'= s why I don't like creating wiki pages. Anybody can edit and mess up the in= formation you have painstakingly created on the wiki pages. So please take note.


-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore




 

~Casey

 

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang= Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:

Dearest Casey DeLorme= ,

Thank you very very much for your kind feedback and input. I would also lik= e to thank Mr. Tobias Geiger, again, for providing his suggestion on exposi= ng the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing= all the 4 memory regions does not work. Sadly, Tobias Geiger is unable= to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why o= nly expose the first 3 PCI memory regions? I don't understand, of course. J= ean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mai= ling lists, in case people think that I am finding fault with Jean David Te= cher, or trying to irritate him, or trying to make him angry, or trying to = aggravate him. Jean David Techer replied me with an email saying that I spent too much time and t= oo bent on solving the yellow exclamation mark glitch for my NVIDIA Gef= orce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP = Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails caref= ully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting th= e following errors after applying Jean David Techer's Xen 4.2-unstable VGA = Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Man= ager
(2) Windows has stopped this device because it has reported problems. (Code= 43)
(3) This device isn't using any resources because it has a problem.=

Jean David Techer insists that our technical issues are due to a NVIDIA dri= ver problem. He insists that you have to install NVIDIA driver versions 275= .33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) w= ill not work, according to Jean David Techer. However, I have tried installing NVIDIA driver version= s 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual ma= chine to be destroyed/terminated/crash after a few minutes and my dom0 to c= rash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the= official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technic= al issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any = problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, becaus= e I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM= , or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his = Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? = It is only 4 minutes. Please do watch Jean David Techer's Youtube video at = the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM = domU Youtube video link: http://www.youtube.com/watch?v=3D3SaYO0ERW44

I am appalled and baffled that he has attained = 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.= 2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.
Solving the yellow exclamation mark issue is important because we wou= ld not be able to run 3D graphics benchmarks and play 3D games without solv= ing it. I am not sending silly emails about some yellow marks, as Jean Davi= d Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of th= e yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.=

Casey DeLorme, with your report on relatively easy success with ATI VGA car= ds, I think I would go the ATI way, but I would have to spend a few hundred= dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while= deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I c= onsider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or b= usiness owner, or proprietor, or technopreneur, or entrepreneur, or technic= al support officer, or customer support officer, or IT helpdesk engineer, p= roviding services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog= . I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index= .php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through=

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", try= ing to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is pr= oviding free services. It is, after all, an open source software proj= ect. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions whil= e avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers= like Ian Campbell from Citrix Corporation an= d Konrad Wilk from Oracle Corporation. <= b>I have always provided all the steps which I have taken, the configura= tion files and necessary documentation, and kernel messages and error logs<= /u> to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information t= hey required. I wondered why. I think they did not read my emails carefully= . They told me they would not reply to me any more if I do not provide the = information they requested. But the problem is that I have always provided information they reque= sted! I think they missed some of my emails, or did not read my ema= ils carefully enough. I am an ardent supporter and SERIOUS software tester fo= r open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the= point of making a video on the BUG and uploading my video to Youtube. The video is only THRE= E minutes.

As everybody says, a picture is worth a thousand words. A video is wo= rth a BILLION words!

I have also failed to obtain technical support from Xen developers regardin= g Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for= both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to = my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be rele= asing Version 1.7 shortly. Jean David Techer's documentation assumes some l= evel of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not = just advanced Linux and Xen users, can follow. I have made references to Je= an David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it s= atisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to= spend a few hundred dollars on an ATI VGA card. I quit my job as an IT eng= ineer 3 years ago because my father suffered from lacunar infarct, or more = commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy a= n ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore P= olytechnic and a Bachelor's degree in Mechanical Engineering from the Natio= nal University of Singapore. But I do not have qualifications in Computer S= cience or Information Technology. I have worked as an Information Technology engineer in Defense Science and T= echnology Agency, Ministry of Defense, Singapore, National Computer Systems= Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's= Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable = VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Ma= chines

Thank you very much for reading my lengthy email. I am always courteous, sa= ying "Please help me. Please. Please. Please." and "Thank yo= u very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)

Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's= Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:

Hi Teo,

 

I tried David's patch files a while ago withou= t success.  I had Xen compiled with the patch files and my GTX= 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager= .

 

You sound plenty competent, but it's important to re= member that you are pioneering a technology that for consumers is still in = its infancy.  Very few people are testing this with consumer equipment= , so finding results seems to be a rarity.

 

 

 


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

 

 

 

 

 

 

 

 




-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore
--_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_-- --===============4355524141628207631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4355524141628207631==-- From xen-devel-bounces@lists.xen.org Mon May 07 21:45:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 21:45:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVk9-0000yZ-Dw; Mon, 07 May 2012 21:45:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRVk7-0000yM-DJ for xen-devel@lists.xen.org; Mon, 07 May 2012 21:45:20 +0000 Received: from [85.158.139.83:46798] by server-6.bemta-5.messagelabs.com id 24/0C-13222-E6248AF4; Mon, 07 May 2012 21:45:18 +0000 X-Env-Sender: Wei.Huang2@amd.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336427113!27086760!1 X-Originating-IP: [216.32.181.183] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20573 invoked from network); 7 May 2012 21:45:15 -0000 Received: from ch1ehsobe003.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.183) by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 7 May 2012 21:45:15 -0000 Received: from mail171-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012 21:45:00 +0000 Received: from mail171-ch1 (localhost [127.0.0.1]) by mail171-ch1-R.bigfish.com (Postfix) with ESMTP id E54A44E0608; Mon, 7 May 2012 21:44:59 +0000 (UTC) X-SpamScore: -17 X-BigFish: VPS-17(zzbb2dI9371Ic85fh14e3M98dK11f6N4015Izz1202hzz8275bh8275dhc704dhz2dh668h839hd25h) 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-ch1 (localhost.localdomain [127.0.0.1]) by mail171-ch1 (MessageSwitch) id 1336427096442035_5786; Mon, 7 May 2012 21:44:56 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail171-ch1.bigfish.com (Postfix) with ESMTP id 651662E00FF; Mon, 7 May 2012 21:44:56 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012 21:44:55 +0000 X-WSS-ID: 0M3O9R4-01-EHX-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 2EECD10281B9; Mon, 7 May 2012 16:45:03 -0500 (CDT) Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 7 May 2012 16:45:10 -0500 Received: from SAUSEXDAG03.amd.com ([fe80::85b5:3838:d8b4:20ba]) by sausexdag02.amd.com ([fe80::ed3c:9786:3083:dd99%21]) with mapi id 14.01.0323.003; Mon, 7 May 2012 16:45:03 -0500 From: "Huang2, Wei" To: "Teo En Ming (Zhang Enming)" Thread-Topic: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation Thread-Index: AQHNDVKcjm0Cx8zTR06RHTP4MgG7OZaBAluAgAC+IACAAC4WgP//xyKAgABpY4D//8aFgIAAtlQAgABPPICAO3ZUgIAAtl4Q Date: Mon, 7 May 2012 21:44:48 +0000 Message-ID: <4400B41FB768044EA720935D0808176C0911799D@sausexdag03.amd.com> References: <4F7334D9.2020700@gmail.com> <4F73C718.9020905@gmail.com> <4F7484C0.2060009@gmail.com> <4F74AB69.4080507@gmail.com> <4F74C205.9070104@amd.com> <4F74EA35.4030305@amd.com> <4F753CD8.4050300@gmail.com> <4F75C59F.8030407@amd.com> <4FA760B9.4060501@gmail.com> In-Reply-To: <4FA760B9.4060501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.236.48.215] MIME-Version: 1.0 X-OriginatorOrg: amd.com Cc: "xen-users@lists.xen.org" , Casey DeLorme , Tobias Geiger , 'Teo En Ming' , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4355524141628207631==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4355524141628207631== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_" --_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I didn't ask them to include this patch in Xen 4.2. If you have an AMD = GPU, you can try it as a secondary passthru without VBIOS patch. Most of th= em will work from what I heard. Thanks, -Wei From: Teo En Ming (Zhang Enming) [mailto:singapore.mr.teo.en.ming@gmail.com= ] Sent: Monday, May 07, 2012 12:42 AM To: Huang2, Wei Cc: Casey DeLorme; xen-users@lists.xen.org; Tobias Geiger; xen-devel@lists.= xen.org; 'Teo En Ming' Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users to Att= empt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentation On 30/03/2012 22:39, Wei Huang wrote: On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) wrote: On 30/03/2012 07:03, Wei Huang wrote: On 03/29/2012 04:29 PM, Casey DeLorme wrote: David, XenServer VGA Passthrough requires a paid/licensed copy, which costs $2500,= a bit out of my price range for experimentation. Important to note that t= he feature is not a part of the 30-day trial license. However, Citrix recently visited my college and I was able to preview hardw= are access on a laptop one of the employees had, where they swapped between= Ubuntu and Windows with a hotkey, and various hardware components includin= g onboard GPU and the WebCam were accessible. In testing XenServer, I can say that if I had a business, that's the produc= t I would use. In the past month having tried Xen and ESXi, I was astonish= ed with the ease of use for XenServer. As for Catalyst, version 12.2 (the latest currently) worked for me. Important to note that until I followed Andrews advice to omit the Catalyst= Control Center, the installation resulted in a BSOD. I saw similar issue whiling playing with XenClient. After discussing with A= MD GPU driver team, the conclusion was that the installer has a bug. But I = have not received any further update from them. Also manual driver installa= tion (after many tries) did fix problem for me. The solution, select "Custom" installation and uncheck the CCC. After the = installation your first reboot should run some follow-up updates via cmd, y= ou need to reboot a second time for fully functional drivers. Also, I had underscan on my monitor so I went out on a limb and re-ran the = setup for Catalyst, and was able to get CCC installed with a second run thr= ough, which allowed me to fix my underscan issue. My conclusion is that the CCC requires some driver functionality that isn't= available until after you install the drivers, this could be on all system= s or it might be related to how HVM's handle the PCI devices, that much I c= an't say. Teo, I could be spouting nonsense, and if so I'm sure Wei can correct me, but I = am pretty sure AMD engineers have been contributing to Xen for a while, and= some patches have already been applied. Obviously it isn't flawless, I my= self haven't gotten video at boot time, only at the login screen. This is because VBIOS patch wasn't applied. But as I said before, my VBIOS = wasn't universal enough to put it as a production patch. So I am hesitant t= o put it out. Dear Wei Huang at AMD Corporation, Please put your Xen VGA Passthrough patch out so that all of us can have a = try. Thank you very much. http://old-list-archives.xen.org/archives/html/xen-devel/2010-10/msg00284.h= tml Dear Wei Huang, Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tr= ee? Thank you. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Mine works on 4.1.2, but it is possible that 4.1.0 had less of these "patch= es" hence Sebastien's post. Also, I apologize as I did not properly word my opinion before. VGA Passth= rough is new "for consumer components". In 2010 the number of desktop (not= server) boards boasting VT-d functionality could probably be counted on on= e hand. To my understanding that means the technology is at most 3 years o= ld, still a baby in my opinion. I didn't mean that the technology hadn't been implemented into various Hype= rvisors, just that it is clearly not a perfected feature. If you consider = 3 years of consumer availability, dates become important when researching. = Sebastien's post was May 2011, just shy of one year ago, and Thomas's was = in 2010. There are newer patches still for ATI in Xen 4.2, which I intend to test ov= er the next week. I have NOT gotten ATI to work at boot time, video starts= at the login screen. I agree with Wei that drivers can contribute to BSOD's and errors, but when= an install doesn't fail but the hardware reacts the same as before, I woul= d like to assume the driver is irrelative. Have you looked at XenClient project? It has a customized ATI component whi= ch allows you to switch between VMs flawlessly. I think it is the most matu= re Xen solution for GPU passthru in client area. Dear Wei Huang at AMD Corporation, May I know what is the XenClient project? ~Casey On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang > wrote: On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) wrote: Dear Casey DeLorme, This guy, Sebastien Gauthier, also has the same problems as us. He was usin= g Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After= installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA= Passthrough to Windows 7. Please read Sebastien Gauthier's case here: http://readlist.com/lists/lists.xensource.com/xen-users/11/59090.html Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS,= like us. Dear Tobias Geiger, You were saying that with ATI VGA cards, you do not need to apply any Xen V= GA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Hua= ng's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst driv= ers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough t= o Windows 7 using an ATI VGA card. Hi Teo, The VBIOS patch I sent out did not work for all ATI cards. The patch itself= assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU= generation. From this perspective, my patch isn't universal. Also there ar= e many factors, some of which are not in control by us (like graphics drive= r), can contribute to BSOD you mentioned. I am not in a position to debug i= t for everyone's card (as I don't have all cards). Thanks, -Wei -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote: On 29/03/2012 12:29, Casey DeLorme wrote: My mistake for not hitting "Reply to All", sorry. No worries Casey. It might be of some value to mention that my tests were with Windows 7, I h= ave no interest in using XP anymore. Also, I did all of my testing through= remote VNC, not once did I actually get video, even 2D, working. I bought 2 copies of Windows XP Home Edition in the past because it is chea= p, at S$145. I did not buy Windows 7 because it is expensive. I got video w= orking all right, but only 2D. I cannot get 3D graphics working. However, my errors are exactly as you described: 1. Windows recognizes the model (GTX 460), not "unknown PCI device". 2. Device code 43. 3. No resources assigned to the device. We have the same set of errors. Might be worth mentioning, I was able to run the latest nVidia driver insta= llation without errors, but after rebooting there was no change, same error= code, still no video. Same situation here with the latest NVIDIA drivers. But I only have 2D vide= o working. I can't get 3D video to work. To me this would be evidence that driver version isn't a problem, but then= again I didn't have anything actually working. I agree that driver version isn't a problem. Something is wrong somewhere. I am an IT student in college, so my experience is limited to mostly progra= mming with very little knowledge of the inner-workings of hardware. So, fo= rgive me for being unable to help with regards to memory addresses on the c= ards. I am hoping that Intel engineers and Xen developers would be able to help. I've been using *nix for about 4 years, and Windows since I my age was a si= ngle digit. I have had experience setting up server features such as web, = database, and application servers but I am still green when it comes to ker= nel or hardware configuration. I started learning Linux/UNIX since the year 2005, that is about 7 years ag= o. I started using Windows when it was version 3.1. I love compiling the la= test Linux kernel and assembling my own computer hardware. My Xen adventure began 35 days ago, and it is no exaggeration to say that i= n those 35 days I have learned more about linux than I had in the past two = years. I like challenges as much as the next IT person, but I ran out of t= ime and ideas for debugging my nVidia problems. The nVidia stretch of my a= dventure lasted for 24 days through 54 fresh linux installations accompanie= d by over 200~ pages worth of documented failures and not a single pixel si= ghted. Why not make your documentation into PDF? It is a very popular document for= mat. The ATI card took me a day, less than 12 hours of relatively easy debugging= by comparison to the aforementioned testing. I do fully understanding fin= ancial constraints, but it is a working solution and worth mentioning. I d= o not know what the prices are like in Singapore, but in the states I was a= ble to buy an ATI Radeon HD 6870 for $160. For me it came down to weighing= my objectives against my curiosity. That ATI Radeon HD 6870 would cost me $279, I think. If you do continue your nVidia endeavors I wish you success, but as in my f= ormer email VGA passthrough is a new frontier, not even Guru's like David m= ay not be able to help beyond their own hardware experiences. I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linu= x KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out o= f the box, as Tobias Geiger suggested, but NVIDIA requires patches. Documentation is one problem I agree with you on 100%. I came into this kn= owing relatively little about Linux & hardware, and nothing about Xen, and = most every guide I found assumed I had been in a deep relationship with Lin= ux for many years and had a basic understanding of Xen commands. I started learning Xen since the year 2007, which is about 5 years ago. Like you, I intend to use those documented failures as well as my recent su= ccess to create a comprehensive guide with photographs, screen captures, an= d perhaps even videos going from "assembled computer" to "Complete Xen Dom0= /w HVM & VGA Passthrough". Provided the wiki will allow me to upload the = screenshots, I'll be certain to post it there. I will be looking forward to your documentation and videos. Right now Xen w= iki allows uploading image files and PDF files. Why not create a PDF docume= nt and share it with all of us? It is known as portable document format and= is very popular, but it appears that xen mailing lists don't like PDF form= at. I don't like wiki pages because anybody can edit and fundamentally mess up = the wiki pages, even providing bogus and erroneous information. That's why = I don't like creating wiki pages. Anybody can edit and mess up the informat= ion you have painstakingly created on the wiki pages. So please take note. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore ~Casey On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang Enming) > wrote: Dearest Casey DeLorme, Thank you very very much for your kind feedback and input. I would also lik= e to thank Mr. Tobias Geiger, again, for providing his suggestion on exposi= ng the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In a= ny case, either exposing the first 3 memory regions only or exposing all th= e 4 memory regions does not work. Sadly, Tobias Geiger is unable to help me= further. I have asked Jean David Techer, what about the 4th PCI memory region? Why o= nly expose the first 3 PCI memory regions? I don't understand, of course. J= ean David Techer did not reply to my question. I have decided to post your prompt reply to the xen-users and xen-devel mai= ling lists, in case people think that I am finding fault with Jean David Te= cher, or trying to irritate him, or trying to make him angry, or trying to = aggravate him. Jean David Techer replied me with an email saying that I spe= nt too much time and too bent on solving the yellow exclamation mark glitch= for my NVIDIA Geforce 8400GS in Device Manager in Windows 8 Consumer Previ= ew and Windows XP Home Edition, and that I sent stupid requests. Stupid req= uests? Did he read my emails carefully, word by word? Casey DeLorme, please, can I confirm with you again that you are getting th= e following errors after applying Jean David Techer's Xen 4.2-unstable VGA = Passthrough patches: (1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Manager (2) Windows has stopped this device because it has reported problems. (Code= 43) (3) This device isn't using any resources because it has a problem. Jean David Techer insists that our technical issues are due to a NVIDIA dri= ver problem. He insists that you have to install NVIDIA driver versions 275= .33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) w= ill not work, according to Jean David Techer. However, I have tried install= ing NVIDIA driver versions 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Editi= on HVM virtual machine to be destroyed/terminated/crash after a few minutes= and my dom0 to crash as well. NVIDIA driver versions 275.33 and 275.50 for= Windows XP 32-bit is not available from the official NVIDIA website. So it is definitely not a NVIDIA driver problem. I suspect that the technic= al issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think the= re is any problem with vgabios-pt.bin extracted out from our NVIDIA VGA car= ds, because I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM= , or Electrically Erasable Programmable Read Only Memory. Secondly, it does seem strange that Jean David Techer was able to attain 10= 0%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his Window= s XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? It is = only 4 minutes. Please do watch Jean David Techer's Youtube video at the fo= llowing URL: Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM = domU Youtube video link: http://www.youtube.com/watch?v=3D3SaYO0ERW44 I am appalled and baffled that he has attained 100% success while both of u= s have only attained partial success (i.e. less than 100%) on Xen 4.2-unsta= ble VGA Passthrough to Windows 8 Consumer Preview and Windows XP. Solving the yellow exclamation mark issue is important because we would not= be able to run 3D graphics benchmarks and play 3D games without solving it= . I am not sending silly emails about some yellow marks, as Jean David Tech= er suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display= benchmarks, because of the yellow exclamation mark for NVIDIA Geforce 8400= GS in Device Manager. Casey DeLorme, with your report on relatively easy success with ATI VGA car= ds, I think I would go the ATI way, but I would have to spend a few hundred= dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while= deciding to go the ATI way, I would also like to continue troubleshooting = with the NVIDIA problem, because I consider it to be a technical challenge. In essence, Jean David Techner is considered to be a "boss", or business ow= ner, or proprietor, or technopreneur, or entrepreneur, or technical support= officer, or customer support officer, or IT helpdesk engineer, providing s= ervices like his forward-ported Xen 4.2-unstable VGA Passthrough patches an= d the documentation on his blog. I repost Jean David Techer's official webs= ite here: Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.david= gis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-th= rough Jean David Techer's official website is his business venture. Basically, I am Jean David Techer's "customer", trying to obtain technical = support from him. Of course, he is not obliged to provide technical support= to me since he is providing free services. It is, after all, an open sourc= e software project. Nobody is obliged to provide anybody with technical sup= port. To do Jean David Techer justice, he replied most of my questions whil= e avoiding some of my questions. Finally, I have also failed to obtain technical support from Xen developers= like Ian Campbell from Citrix Corporation and Konrad Wilk from Oracle Corp= oration. I have always provided all the steps which I have taken, the confi= guration files and necessary documentation, and kernel messages and error l= ogs to xen-users and xen-devel mailing lists, but they keep insisting I did= not provide the information they required. I wondered why. I think they di= d not read my emails carefully. They told me they would not reply to me any= more if I do not provide the information they requested. But the problem i= s that I have always provided information they requested! I think they miss= ed some of my emails, or did not read my emails carefully enough. I am an a= rdent supporter and SERIOUS software tester for open source Xen virtualizat= ion/hypervisor but they treated me lightly. I always read my emails WORD BY= WORD. I have even went to the point of making a video on the BUG and uploa= ding my video to Youtube. The video is only THREE minutes. As everybody says, a picture is worth a thousand words. A video is worth a = BILLION words! I have also failed to obtain technical support from Xen developers regardin= g Xen 4.2-unstable VGA Passthrough. I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for= both NVIDIA and ATI cards. Casey DeLorme, thank you very much once again. I will be making changes to = my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be rele= asing Version 1.7 shortly. Jean David Techer's documentation assumes some l= evel of advanced Linux technical knowledge, so I am writing documentation o= n my own so that everybody, not just advanced Linux and Xen users, can foll= ow. I have made references to Jean David Techer's documentation in my own d= ocumentation. I would be very happy if people would use my documentation. Of course, it s= atisfies my ego and my vanity. Haha. I have been un-employed for nearly three years now, and I would hesitate to= spend a few hundred dollars on an ATI VGA card. I quit my job as an IT eng= ineer 3 years ago because my father suffered from lacunar infarct, or more = commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please= understand why I hesitate to buy an ATI VGA card. The cheapest one costs S= GD$279. I have a diploma in Mechanical+Electronics engineering from Singapore Polyt= echnic and a Bachelor's degree in Mechanical Engineering from the National = University of Singapore. But I do not have qualifications in Computer Scien= ce or Information Technology. I have worked as an Information Technology en= gineer in Defense Science and Technology Agency, Ministry of Defense, Singa= pore, National Computer Systems Pte Ltd, Asiasoft Online Pte Ltd, and Ishin= emax Singapore Pte Ltd. Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's= Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable = VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Ma= chines Thank you very much for reading my lengthy email. I am always courteous, sa= ying "Please help me. Please. Please. Please." and "Thank you very much for= your kind assistance" in my emails. Thank you very much. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Citizen cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's= Office, Republic of Singapore On 29/03/2012 03:53, Casey DeLorme wrote: Hi Teo, I tried David's patch files a while ago without success. I had Xen compile= d with the patch files and my GTX 460 VGA BIOS rom, but I got the same as y= ou, either a BSOD or Code 43 in Device Manager. You sound plenty competent, but it's important to remember that you are pio= neering a technology that for consumers is still in its infancy. Very few = people are testing this with consumer equipment, so finding results seems t= o be a rarity. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I didn’t ask th= em to include this patch in Xen 4.2. If you have an AMD GPU, you can try it= as a secondary passthru without VBIOS patch. Most of them will work from what I heard.

 <= /p>

Thanks,=

-Wei

 <= /p>

From: Teo En Ming (Zhang Enming) [mailto:singapore.mr.t= eo.en.ming@gmail.com]
Sent: Monday, May 07, 2012 12:42 AM
To: Huang2, Wei
Cc: Casey DeLorme; xen-users@lists.xen.org; Tobias Geiger; xen-devel= @lists.xen.org; 'Teo En Ming'
Subject: Re: [Xen-devel] [Xen-users] [REQUEST] Request for Xen Users= to Attempt Jean David Techer's Xen 4.2-unstable VGA Passthrough Documentat= ion

 

On 30/03/2012 22:39, Wei Huang wrote:

On 03/29/2012 11:55 PM, Teo En Ming (Zhang Enming) w= rote:

On 30/03/2012 07:03, Wei Huang wrote:

On 03/29/2012 04:29 PM, Casey DeLorme wrote:

David,

 

XenServer VGA Passthrough requires a paid/licensed c= opy, which costs $2500, a bit out of my price range for experimentation. &n= bsp;Important to note that the feature is not a part of the 30-day trial li= cense.

 

However, Citrix recently visited my college and I wa= s able to preview hardware access on a laptop one of the employees had, whe= re they swapped between Ubuntu and Windows with a hotkey, and various hardw= are components including onboard GPU and the WebCam were accessible.

 

In testing XenServer, I can say that if I had a busi= ness, that's the product I would use.  In the past month having tried = Xen and ESXi, I was astonished with the ease of use for XenServer.

 

As for Catalyst, version 12.2 (the latest currently)= worked for me.

 

Important to note that until I followed Andrews advi= ce to omit the Catalyst Control Center, the installation resulted in a BSOD= .

I saw similar issue whiling playing with XenClient. = After discussing with AMD GPU driver team, the conclusion was that the inst= aller has a bug. But I have not received any further update from them. Also= manual driver installation (after many tries) did fix problem for me.

 

The solution, select "Custom" installation= and uncheck the CCC.  After the installation your first reboot should= run some follow-up updates via cmd, you need to reboot a second time for f= ully functional drivers.

 

Also, I had underscan on my monitor so I went out on= a limb and re-ran the setup for Catalyst, and was able to get CCC installe= d with a second run through, which allowed me to fix my underscan issue.

 

My conclusion is that the CCC requires some driver f= unctionality that isn't available until after you install the drivers, this= could be on all systems or it might be related to how HVM's handle the PCI= devices, that much I can't say.

 

 

 

Teo,

 

I could be spouting nonsense, and if so I'm sure Wei= can correct me, but I am pretty sure AMD engineers have been contributing = to Xen for a while, and some patches have already been applied.  Obvio= usly it isn't flawless, I myself haven't gotten video at boot time, only at the login screen.

 

This is because VBIOS patch wasn't applied. But as I= said before, my VBIOS wasn't universal enough to put it as a production pa= tch. So I am hesitant to put it out.


Dear Wei Huang at AMD Corporation,

Please put your Xen VGA Passthrough patch out so that all of us can have a = try.

Thank you very much.

http://old-list-archives.xen.org/arc= hives/html/xen-devel/2010-10/msg00284.html



Dear Wei Huang,

Your VGA Passthrough patch is still not included in the Xen 4.2-unstable tr= ee?

Thank you.



-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore



Mine works on 4.1.2, but it is possible that 4.1.0 h= ad less of these "patches" hence Sebastien's post.

 

Also, I apologize as I did not properly word my opin= ion before.  VGA Passthrough is new "for consumer components"= ;.  In 2010 the number of desktop (not server) boards boasting VT-d fu= nctionality could probably be counted on one hand.  To my understanding that means the technology is at most 3 years old, still a= baby in my opinion.

 

I didn't mean that the technology hadn't been implem= ented into various Hypervisors, just that it is clearly not a perfected fea= ture.  If you consider 3 years of consumer availability, dates become = important when researching.  Sebastien's post was May 2011, just shy of one year ago, and Thomas's was in 2010.

 

There are newer patches still for ATI in Xen 4.2, wh= ich I intend to test over the next week.  I have NOT gotten ATI to wor= k at boot time, video starts at the login screen.

 

I agree with Wei that drivers can contribute to BSOD= 's and errors, but when an install doesn't fail but the hardware reacts the= same as before, I would like to assume the driver is irrelative.

 

Have you looked at XenClient project? It has a custo= mized ATI component which allows you to switch between VMs flawlessly. I th= ink it is the most mature Xen solution for GPU passthru in client area.


Dear Wei Huang at AMD Corporation,

May I know what is the XenClient project?



 

~Casey

 

On Thu, Mar 29, 2012 at 4:11 PM, Wei Huang <wei.huang2@amd.com&g= t; wrote:

On 03/29/2012 01:35 PM, Teo En Ming (Zhang Enming) w= rote:

Dear Casey DeLorme,
This guy, Sebastien Gauthier, also has the same problems as us. He was usin= g Xen 4.1.0 and an ATI Radeon 4550. He applied Mr. Wei Huang's patch. After= installing the latest ATI/AMD Catalyst drivers, he got a BSOD with Xen VGA= Passthrough to Windows 7.

Please read Sebastien Gauthier's case here:

http://readlist.com/lists/lists.xensource.com/xen-= users/11/59090.html

Hence Sebastien Gauthier reported Xen VGA Passthrough with PARTIAL SUCCESS,= like us.

Dear Tobias Geiger,

You were saying that with ATI VGA cards, you do not need to apply any Xen V= GA Passthrough patches. But this guy Sebastien Gauthier applied Mr. Wei Hua= ng's patches to Xen 4.1.0 and got a BSOD after installing ATI Catalyst driv= ers. Sebastien Gauthier did not get 100% success with Xen VGA Passthrough to Windows 7 using an ATI VGA ca= rd.

Hi Teo,

The VBIOS patch I sent out did not work for all ATI cards. The patch itself= assumed certain behavior of GPU VBIOS. But this doesn't apply to every GPU= generation. From this perspective, my patch isn't universal. Also there ar= e many factors, some of which are not in control by us (like graphics driver), can contribute to BSOD you me= ntioned. I am not in a position to debug it for everyone's card (as I don't= have all cards).

Thanks,
-Wei 



-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore





On 29/03/2012 23:50, Teo En Ming (Zhang Enming) wrote:

On 29/03/2012 12:29, Casey DeLorme wrote:

My mistake for not hitting "Reply to All",= sorry.


No worries Casey.


 

It might be of some value to mention that my tests w= ere with Windows 7, I have no interest in using XP anymore.  Also, I d= id all of my testing through remote VNC, not once did I actually get video,= even 2D, working. 


I bought 2 copies of Windows XP Home Edition in the past because it is chea= p, at S$145. I did not buy Windows 7 because it is expensive. I got video w= orking all right, but only 2D. I cannot get 3D graphics working.


However, my errors are exactly as you described:

 

1.  Windows recognizes the model (GTX 460), not= "unknown PCI device".

2.  Device code 43.

3.  No resources assigned to the device.


We have the same set of errors.


 

Might be worth mentioning, I was able to run the lat= est nVidia driver installation without errors, but after rebooting there wa= s no change, same error code, still no video.


Same situation here with the latest NVIDIA drivers. But I only have 2D vide= o working. I can't get 3D video to work.


 To me this would be evidence that driver versi= on isn't a problem, but then again I didn't have anything actually working.=


I agree that driver version isn't a problem. Something is wrong somewhere.<= br>

 

 

I am an IT student in college, so my experience is l= imited to mostly programming with very little knowledge of the inner-workin= gs of hardware.  So, forgive me for being unable to help with regards = to memory addresses on the cards.


I am hoping that Intel engineers and Xen developers would be able to help.<= br>

 

I've been using *nix for about 4 years, and Windows = since I my age was a single digit.  I have had experience setting up s= erver features such as web, database, and application servers but I am stil= l green when it comes to kernel or hardware configuration.


I started learning Linux/UNIX since the year 2005, that is about 7 years ag= o. I started using Windows when it was version 3.1. I love compiling the la= test Linux kernel and assembling my own computer hardware.


 

My Xen adventure began 35 days ago, and it is no exa= ggeration to say that in those 35 days I have learned more about linux than= I had in the past two years.  I like challenges as much as the next I= T person, but I ran out of time and ideas for debugging my nVidia problems.  The nVidia stretch of my adventure= lasted for 24 days through 54 fresh linux installations accompanied by ove= r 200~ pages worth of documented failures and not a single pixel sighted.


Why not make your documentation into PDF? It is a very popular document for= mat.


 

The ATI card took me a day, less than 12 hours of re= latively easy debugging by comparison to the aforementioned testing.  = I do fully understanding financial constraints, but it is a working solutio= n and worth mentioning.  I do not know what the prices are like in Singapore, but in the states I was able to buy= an ATI Radeon HD 6870 for $160.  For me it came down to weighing my o= bjectives against my curiosity.


That ATI Radeon HD 6870 would cost me $279, I think.


 

If you do continue your nVidia endeavors I wish you = success, but as in my former email VGA passthrough is a new frontier, not e= ven Guru's like David may not be able to help beyond their own hardware exp= eriences.


I don't think VGA passthrough is a new frontier. Oracle VirtualBox and Linu= x KVM supports VGA passthrough as well. Xen ATI VGA Passthrough works out o= f the box, as Tobias Geiger suggested, but NVIDIA requires patches.


 

 

Documentation is one problem I agree with you on 100= %.  I came into this knowing relatively little about Linux & hardw= are, and nothing about Xen, and most every guide I found assumed I had been= in a deep relationship with Linux for many years and had a basic understanding of Xen commands.


I started learning Xen since the year 2007, which is about 5 years ago.


 

Like you, I intend to use those documented failures = as well as my recent success to create a comprehensive guide with photograp= hs, screen captures, and perhaps even videos going from "assembled com= puter" to "Complete Xen Dom0 /w HVM & VGA Passthrough".  Provided the wiki will allow me to upload the scr= eenshots, I'll be certain to post it there.


I will be looking forward to your documentation and videos. Right now Xen w= iki allows uploading image files and PDF files. Why not create a PDF docume= nt and share it with all of us? It is known as portable document format and= is very popular, but it appears that xen mailing lists don't like PDF format.

I don't like wiki pages because anybody can edit and fundamentally me= ss up the wiki pages, even providing bogus and erroneous information. That'= s why I don't like creating wiki pages. Anybody can edit and mess up the in= formation you have painstakingly created on the wiki pages. So please take note.


-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore




 

~Casey

 

On Wed, Mar 28, 2012 at 10:21 PM, Teo En Ming (Zhang= Enming) <singapore.mr.teo.en.ming@gmail.com> wrote:

Dearest Casey DeLorme= ,

Thank you very very much for your kind feedback and input. I would also lik= e to thank Mr. Tobias Geiger, again, for providing his suggestion on exposi= ng the fourth memory region in tools/firmware/hvmloader/acpi/dsdt.asl. In any case, either exposing the first 3 memory regions only or exposing= all the 4 memory regions does not work. Sadly, Tobias Geiger is unable= to help me further.

I have asked Jean David Techer, what about the 4th PCI memory region? Why o= nly expose the first 3 PCI memory regions? I don't understand, of course. J= ean David Techer did not reply to my question.

I have decided to post your prompt reply to the xen-users and xen-devel mai= ling lists, in case people think that I am finding fault with Jean David Te= cher, or trying to irritate him, or trying to make him angry, or trying to = aggravate him. Jean David Techer replied me with an email saying that I spent too much time and t= oo bent on solving the yellow exclamation mark glitch for my NVIDIA Gef= orce 8400GS in Device Manager in Windows 8 Consumer Preview and Windows XP = Home Edition, and that I sent stupid requests. Stupid requests? Did he read my emails caref= ully, word by word?

Casey DeLorme, please, can I confirm with you again that you are getting th= e following errors after applying Jean David Techer's Xen 4.2-unstable VGA = Passthrough patches:

(1) Yellow exclamation mark besides your NVIDIA GTX 460 in Device Man= ager
(2) Windows has stopped this device because it has reported problems. (Code= 43)
(3) This device isn't using any resources because it has a problem.=

Jean David Techer insists that our technical issues are due to a NVIDIA dri= ver problem. He insists that you have to install NVIDIA driver versions 275= .33 WHQL and 275.50 BETA. Any other NVIDIA driver versions (above 280.XX) w= ill not work, according to Jean David Techer. However, I have tried installing NVIDIA driver version= s 275.33 and 275.50 from www.softpedia.com, as he suggested, but it caused my Windows XP Home Edition HVM virtual ma= chine to be destroyed/terminated/crash after a few minutes and my dom0 to c= rash as well. NVIDIA driver versions 275.33 and 275.50 for Windows XP 32-bit is not available from the= official NVIDIA website.

So it is definitely not a NVIDIA driver problem. I suspect that the technic= al issue has to do with MMIO BARs pBAR:vBAR 1:1 matching. I don't think there is any = problem with vgabios-pt.bin extracted out from our NVIDIA VGA cards, becaus= e I have performed a "hexdump -C" on my extracted VGA BIOS EEPROM= , or Electrically Erasable Programmable Read Only Memory.

Secondly, it does seem strange that Jean David Techer was able to attain 100%, ie. perfect success with Xen 4.2-unstable VGA Passthrough to his = Windows XP 32-bit and 64-bit HVM domU. Have you watched his Youtube video? = It is only 4 minutes. Please do watch Jean David Techer's Youtube video at = the following URL:

Jean David Techer's Xen 4.2-unstable VGA Passthrough to Windows XP x64 HVM = domU Youtube video link: http://www.youtube.com/watch?v=3D3SaYO0ERW44

I am appalled and baffled that he has attained = 100% success while both of us have only attained partial success (i.e. less than 100%) on Xen 4.= 2-unstable VGA Passthrough to Windows 8 Consumer Preview and Windows XP.
Solving the yellow exclamation mark issue is important because we wou= ld not be able to run 3D graphics benchmarks and play 3D games without solv= ing it. I am not sending silly emails about some yellow marks, as Jean Davi= d Techer suggested. I can't even run Unigine Heaven DX11, and 3dmark11 3D display benchmarks, because of th= e yellow exclamation mark for NVIDIA Geforce 8400 GS in Device Manager.=

Casey DeLorme, with your report on relatively easy success with ATI VGA car= ds, I think I would go the ATI way, but I would have to spend a few hundred= dollars compared to my cheap SGD$44 NVIDIA Geforce 8400 GS card. And while= deciding to go the ATI way, I would also like to continue troubleshooting with the NVIDIA problem, because I c= onsider it to be a technical challenge.

In essence, Jean David Techner is considered to be a "boss", or b= usiness owner, or proprietor, or technopreneur, or entrepreneur, or technic= al support officer, or customer support officer, or IT helpdesk engineer, p= roviding services like his forward-ported Xen 4.2-unstable VGA Passthrough patches and the documentation on his blog= . I repost Jean David Techer's official website here:

Jean David Techer's Xen 4.2-unstable VGA Passthrough blog: http://www.davidgis.fr/blog/index= .php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through=

Jean David Techer's official website is his business venture.

Basically, I am Jean David Techer's "customer", try= ing to obtain technical support from him. Of course, he is not obliged to provide technical support to me since he is pr= oviding free services. It is, after all, an open source software proj= ect. Nobody is obliged to provide anybody with technical support. To do Jean David Techer justice, he replied most of my questions whil= e avoiding some of my questions.

Finally, I have also failed to obtain technical support from Xen developers= like Ian Campbell from Citrix Corporation an= d Konrad Wilk from Oracle Corporation. <= b>I have always provided all the steps which I have taken, the configura= tion files and necessary documentation, and kernel messages and error logs<= /u> to xen-users and xen-devel mailing lists, but they keep insisting I did not provide the information t= hey required. I wondered why. I think they did not read my emails carefully= . They told me they would not reply to me any more if I do not provide the = information they requested. But the problem is that I have always provided information they reque= sted! I think they missed some of my emails, or did not read my ema= ils carefully enough. I am an ardent supporter and SERIOUS software tester fo= r open source Xen virtualization/hypervisor but they treated me lightly. I always read my emails WORD BY WORD. I have even went to the= point of making a video on the BUG and uploading my video to Youtube. The video is only THRE= E minutes.

As everybody says, a picture is worth a thousand words. A video is wo= rth a BILLION words!

I have also failed to obtain technical support from Xen developers regardin= g Xen 4.2-unstable VGA Passthrough.

I am hoping Xen 4.2 would have official support for Xen VGA Passthrough for= both NVIDIA and ATI cards.

Casey DeLorme, thank you very much once again. I will be making changes to = my Xen, Linux Kernel and Xen VGA Passthrough Documentation and will be rele= asing Version 1.7 shortly. Jean David Techer's documentation assumes some l= evel of advanced Linux technical knowledge, so I am writing documentation on my own so that everybody, not = just advanced Linux and Xen users, can follow. I have made references to Je= an David Techer's documentation in my own documentation.

I would be very happy if people would use my documentation. Of course, it s= atisfies my ego and my vanity. Haha.

I have been un-employed for nearly three years now, and I would hesitate to= spend a few hundred dollars on an ATI VGA card. I quit my job as an IT eng= ineer 3 years ago because my father suffered from lacunar infarct, or more = commonly known as stroke. My NVIDIA Geforce 8400 GS costs only S$44. Please understand why I hesitate to buy a= n ATI VGA card. The cheapest one costs SGD$279.

I have a diploma in Mechanical+Electronics engineering from Singapore P= olytechnic and a Bachelor's degree in Mechanical Engineering from the Natio= nal University of Singapore. But I do not have qualifications in Computer S= cience or Information Technology. I have worked as an Information Technology engineer in Defense Science and T= echnology Agency, Ministry of Defense, Singapore, National Computer Systems= Pte Ltd, Asiasoft Online Pte Ltd, and Ishinemax Singapore Pte Ltd.

Google search terms: Frenchman Jean David Techer, Singaporean Teo En Ming's= Xen, Linux Kernel and Xen VGA Passthrough Documentation, Xen 4.2-unstable = VGA Passthrough to Windows 8 Consumer Preview and Windows XP HVM Virtual Ma= chines

Thank you very much for reading my lengthy email. I am always courteous, sa= ying "Please help me. Please. Please. Please." and "Thank yo= u very much for your kind assistance" in my emails.

Thank you very much.

--
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)

Singapore Citizen

cc: His Excellency The Prime Minister Mr. Lee Hsien Loong, Prime Minister's= Office, Republic of Singapore

On 29/03/2012 03:53, Casey DeLorme wrote:

Hi Teo,

 

I tried David's patch files a while ago withou= t success.  I had Xen compiled with the patch files and my GTX= 460 VGA BIOS rom, but I got the same as you, either a BSOD or Code 43 in Device Manager= .

 

You sound plenty competent, but it's important to re= member that you are pioneering a technology that for consumers is still in = its infancy.  Very few people are testing this with consumer equipment= , so finding results seems to be a rarity.

 

 

 


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

 

 

 

 

 

 

 

 




-- 
Yours sincerely,
 
Mr. Teo En Ming (Zhang Enming)
Singapore
--_000_4400B41FB768044EA720935D0808176C0911799Dsausexdag03amdc_-- --===============4355524141628207631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4355524141628207631==-- From xen-devel-bounces@lists.xen.org Mon May 07 22:50:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 22:50:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWkl-0002U1-OL; Mon, 07 May 2012 22:50:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWkk-0002Tw-GQ for xen-devel@lists.xensource.com; Mon, 07 May 2012 22:50:02 +0000 Received: from [85.158.143.99:54555] by server-1.bemta-4.messagelabs.com id 02/AD-20925-99158AF4; Mon, 07 May 2012 22:50:01 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336430999!26913579!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5491 invoked from network); 7 May 2012 22:49: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; 7 May 2012 22:49:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,546,1330905600"; d="scan'208";a="12341299" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 22: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; Mon, 7 May 2012 23:49:57 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRWkf-0003SF-HA; Mon, 07 May 2012 22:49:57 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRWkf-0005GL-Fy; Mon, 07 May 2012 23:49:57 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 23:49:57 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12796: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12796 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12796/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 22:50:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 22:50:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWkl-0002U1-OL; Mon, 07 May 2012 22:50:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWkk-0002Tw-GQ for xen-devel@lists.xensource.com; Mon, 07 May 2012 22:50:02 +0000 Received: from [85.158.143.99:54555] by server-1.bemta-4.messagelabs.com id 02/AD-20925-99158AF4; Mon, 07 May 2012 22:50:01 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336430999!26913579!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ1Mg==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5491 invoked from network); 7 May 2012 22:49: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; 7 May 2012 22:49:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,546,1330905600"; d="scan'208";a="12341299" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 07 May 2012 22: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; Mon, 7 May 2012 23:49:57 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRWkf-0003SF-HA; Mon, 07 May 2012 22:49:57 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRWkf-0005GL-Fy; Mon, 07 May 2012 23:49:57 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 7 May 2012 23:49:57 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12796: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12796 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12796/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 22:55:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 22: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 ) id 1SRWpz-0002bi-G4; Mon, 07 May 2012 22:55:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWpw-0002bd-SZ for xen-devel@lists.xen.org; Mon, 07 May 2012 22:55:25 +0000 Received: from [193.109.254.147:42949] by server-10.bemta-14.messagelabs.com id 0C/6E-05847-CD258AF4; Mon, 07 May 2012 22:55:24 +0000 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336431321!8059899!1 X-Originating-IP: [74.207.240.146] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22252 invoked from network); 7 May 2012 22:55:23 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 22:55:23 -0000 Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net [50.76.62.73]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id DBFD2AA08; Mon, 7 May 2012 15:55:20 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D29E62046A; Mon, 7 May 2012 15:55:15 -0700 (PDT) Message-ID: <4FA852D3.7060104@goop.org> Date: Mon, 07 May 2012 15:55:15 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Jan Beulich References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: weidong.han@intel.com, Konrad Rzeszutek Wilk , Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/07/2012 12:15 AM, Jan Beulich wrote: > The primary thing that strikes me as odd is that both calls are still > indirect ones, even though I thought that they should get replaced > by direct ones (or even the actual instruction, namely in the > read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? Patching happens as an explicit step during (moderately late) boot, not as a side-effect of the first call, so it doesn't surprise me too much that they haven't been updated at this point. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 22:55:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 22: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 ) id 1SRWpz-0002bi-G4; Mon, 07 May 2012 22:55:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRWpw-0002bd-SZ for xen-devel@lists.xen.org; Mon, 07 May 2012 22:55:25 +0000 Received: from [193.109.254.147:42949] by server-10.bemta-14.messagelabs.com id 0C/6E-05847-CD258AF4; Mon, 07 May 2012 22:55:24 +0000 X-Env-Sender: jeremy@goop.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336431321!8059899!1 X-Originating-IP: [74.207.240.146] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22252 invoked from network); 7 May 2012 22:55:23 -0000 Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 22:55:23 -0000 Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net [50.76.62.73]) (Authenticated sender: smtp-saboo) by claw.goop.org (Postfix) with ESMTPSA id DBFD2AA08; Mon, 7 May 2012 15:55:20 -0700 (PDT) Received: from saboo.goop.org (localhost [IPv6:::1]) by saboo.goop.org (Postfix) with ESMTP id D29E62046A; Mon, 7 May 2012 15:55:15 -0700 (PDT) Message-ID: <4FA852D3.7060104@goop.org> Date: Mon, 07 May 2012 15:55:15 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Jan Beulich References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: weidong.han@intel.com, Konrad Rzeszutek Wilk , Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/07/2012 12:15 AM, Jan Beulich wrote: > The primary thing that strikes me as odd is that both calls are still > indirect ones, even though I thought that they should get replaced > by direct ones (or even the actual instruction, namely in the > read_cr4() case) upon first use. Konrad, Jeremy - am I wrong here? Patching happens as an explicit step during (moderately late) boot, not as a side-effect of the first call, so it doesn't surprise me too much that they haven't been updated at this point. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:11:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRX4i-0002pR-09; Mon, 07 May 2012 23:10:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRX4g-0002pM-7t for xen-devel@lists.xensource.com; Mon, 07 May 2012 23:10:38 +0000 Received: from [85.158.143.35:53437] by server-3.bemta-4.messagelabs.com id D9/AA-05853-D6658AF4; Mon, 07 May 2012 23:10:37 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-4.tower-21.messagelabs.com!1336432235!10121985!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17902 invoked from network); 7 May 2012 23:10:36 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-4.tower-21.messagelabs.com with SMTP; 7 May 2012 23:10:36 -0000 Received: (qmail 20972 invoked from network); 8 May 2012 01:10:31 +0200 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 mail.netsafe.cz) (127.0.0.1) by localhost with SMTP; 8 May 2012 01:10:31 +0200 Received: from 195.47.79.16 (SquirrelMail authenticated user pavel) by mail.netsafe.cz with HTTP; Tue, 8 May 2012 01:10:32 +0200 (CEST) Message-ID: <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> In-Reply-To: <20120507173144.GB17704@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <20120507173144.GB17704@phenom.dumpdata.com> Date: Tue, 8 May 2012 01:10:32 +0200 (CEST) From: "Pavel Mateja" To: "Konrad Rzeszutek Wilk" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: >> Hi, >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest >> kernel. >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x >> xenified >> kernel. See attached log. >> >> So I tried just to update and patch xen and kernel, but I had no luck so >> far. >> >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang >> recently. >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html >> >> I tried two kernels >> testing-3.5-with-extra and xen/next-3.2 from >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git >> and >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >> Both with ioperm opcode patch which is required by the ATI patch. See >> attachement. >> >> The xen/next-3.2 branch kernel was able to start booting windows. >> With Catalyst driver installed I just saw bluescreen during Windows >> boot. >> Without Catalyst driver Windows were able to boot but Windows ended >> frozen or >> USB was not working. It was hard to tell because input devices had no >> response >> at all. >> >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 >> kernel >> during Windows boot. I guess I have to rework the io_bitmap patch >> somehow. > > When you say 'io_bitmap' patch are you referring to these ones: > > 70a357d xen: implement IO permission bitmap > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > 93b7a2a x86: demacro set_iopl_mask() > > ? I don't think those are in that tag. They are in the kitchensink - > #testing > - does it work with that branch? > > The next-3.2 is a bit old. I should actually delete it. Hi, I mean this patch below. I think it was originally here: http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01139.h= tml Then I was told by you to use devel/ioperm branch which I think doesn't exist anymore: http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg01213.h= tml I'm too tired to test #testing branch now. I'll try it tomorrow after some sleep. >> diff --git a/arch/x86/include/asm/paravirt.h >> b/arch/x86/include/asm/paravirt.h >> index aa0f913..259ef7f 100644 >> --- a/arch/x86/include/asm/paravirt.h >> +++ b/arch/x86/include/asm/paravirt.h >> @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, >> int entry, const gate_desc *g) >> { >> PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); >> } >> + >> static inline void set_iopl_mask(unsigned mask) >> { >> PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); >> } >> >> +static inline void set_io_bitmap(struct thread_struct *thread, >> + unsigned long bytes_updated) >> +{ >> + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); >> +} >> + >> /* The paravirtualized I/O functions */ >> static inline void slow_down_io(void) >> { >> diff --git a/arch/x86/include/asm/paravirt_types.h >> b/arch/x86/include/asm/paravirt_types.h >> index 8e8b9a4..96f267c 100644 >> --- a/arch/x86/include/asm/paravirt_types.h >> +++ b/arch/x86/include/asm/paravirt_types.h >> @@ -142,6 +142,8 @@ struct pv_cpu_ops { >> void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); >> >> void (*set_iopl_mask)(unsigned mask); >> + void (*set_io_bitmap)(struct thread_struct *thread, >> + unsigned long bytes_updated); >> >> void (*wbinvd)(void); >> void (*io_delay)(void); >> diff --git a/arch/x86/include/asm/processor.h >> b/arch/x86/include/asm/processor.h >> index 4fa7dcc..62becce 100644 >> --- a/arch/x86/include/asm/processor.h >> +++ b/arch/x86/include/asm/processor.h >> @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned >> mask) >> #endif >> } >> >> +extern void native_set_io_bitmap(struct thread_struct *thread, >> + unsigned long updated_bytes); >> + >> static inline void >> native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) >> { >> @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, >> } >> >> #define set_iopl_mask native_set_iopl_mask >> +#define set_io_bitmap native_set_io_bitmap >> #endif /* CONFIG_PARAVIRT */ >> >> /* >> diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c >> index 8c96897..c372ef0 100644 >> --- a/arch/x86/kernel/ioport.c >> +++ b/arch/x86/kernel/ioport.c >> @@ -17,13 +17,29 @@ >> #include >> #include >> >> +void native_set_io_bitmap(struct thread_struct *t, >> + unsigned long bytes_updated) >> +{ >> + struct tss_struct *tss; >> + >> + if (!bytes_updated) >> + return; >> + >> + tss =3D &__get_cpu_var(init_tss); >> + >> + /* Update the TSS: */ >> + if (t->io_bitmap_ptr) >> + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); >> + else >> + memset(tss->io_bitmap, 0xff, bytes_updated); >> +} >> + >> /* >> * this changes the io permissions bitmap in the current task. >> */ >> asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int >> turn_on) >> { >> struct thread_struct *t =3D ¤t->thread; >> - struct tss_struct *tss; >> unsigned int i, max_long, bytes, bytes_updated; >> >> if ((from + num <=3D from) || (from + num > IO_BITMAP_BITS)) >> @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, >> unsigned long num, int turn_on) >> } >> >> /* >> - * do it in the per-thread copy and in the TSS ... >> + * do it in the per-thread copy >> * >> - * Disable preemption via get_cpu() - we must not switch away >> + * Disable preemption - we must not switch away >> * because the ->io_bitmap_max value must match the bitmap >> * contents: >> */ >> - tss =3D &per_cpu(init_tss, get_cpu()); >> + preempt_disable(); >> >> if (turn_on) >> bitmap_clear(t->io_bitmap_ptr, from, num); >> @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, >> unsigned long num, int turn_on) >> >> t->io_bitmap_max =3D bytes; >> >> - /* Update the TSS: */ >> - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); >> + set_io_bitmap(t, bytes_updated); >> >> - put_cpu(); >> + preempt_enable(); >> >> return 0; >> } >> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c >> index ab13760..aa420e7 100644 >> --- a/arch/x86/kernel/paravirt.c >> +++ b/arch/x86/kernel/paravirt.c >> @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops =3D { >> .swapgs =3D native_swapgs, >> >> .set_iopl_mask =3D native_set_iopl_mask, >> + .set_io_bitmap =3D native_set_io_bitmap, >> .io_delay =3D native_io_delay, >> >> .start_context_switch =3D paravirt_nop, >> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c >> index 1d92a5a..e8436cc 100644 >> --- a/arch/x86/kernel/process.c >> +++ b/arch/x86/kernel/process.c >> @@ -91,16 +91,12 @@ void exit_thread(void) >> unsigned long *bp =3D t->io_bitmap_ptr; >> >> if (bp) { >> - struct tss_struct *tss =3D &per_cpu(init_tss, get_cpu()); >> - >> + preempt_disable(); >> t->io_bitmap_ptr =3D NULL; >> clear_thread_flag(TIF_IO_BITMAP); >> - /* >> - * Careful, clear this in the TSS too: >> - */ >> - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); >> + set_io_bitmap(t, t->io_bitmap_max); >> t->io_bitmap_max =3D 0; >> - put_cpu(); >> + preempt_enable(); >> kfree(bp); >> } >> } >> @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, >> struct task_struct *next_p, >> hard_enable_TSC(); >> } >> >> - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { >> - /* >> - * Copy the relevant range of the IO bitmap. >> - * Normally this is 128 bytes or less: >> - */ >> - memcpy(tss->io_bitmap, next->io_bitmap_ptr, >> - max(prev->io_bitmap_max, next->io_bitmap_max)); >> - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { >> - /* >> - * Clear any possible leftover bits: >> - */ >> - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); >> - } >> + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || >> + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) >> + set_io_bitmap(next, >> + max(prev->io_bitmap_max, >> next->io_bitmap_max)); >> + >> propagate_user_return_notify(prev_p, next_p); >> } >> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >> index 8853204..7a05509 100644 >> --- a/arch/x86/xen/enlighten.c >> +++ b/arch/x86/xen/enlighten.c >> @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) >> HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); >> } >> >> +static void xen_set_io_bitmap(struct thread_struct *thread, >> + int changed, unsigned long bytes_updated) >> +{ >> + struct physdev_set_iobitmap set_iobitmap; >> + >> + set_xen_guest_handle(set_iobitmap.bitmap, >> + (char *)thread->io_bitmap_ptr); >> + set_iobitmap.nr_ports =3D thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; >> + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, >> + &set_iobitmap)); >> +} >> + >> static void xen_io_delay(void) >> { >> } >> @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops >> __initconst =3D { >> .load_sp0 =3D xen_load_sp0, >> >> .set_iopl_mask =3D xen_set_iopl_mask, >> + .set_io_bitmap =3D xen_set_io_bitmap, >> .io_delay =3D xen_io_delay, >> >> /* Xen takes care of %gs when switching to usermode for us */ -- = Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:11:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRX4i-0002pR-09; Mon, 07 May 2012 23:10:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRX4g-0002pM-7t for xen-devel@lists.xensource.com; Mon, 07 May 2012 23:10:38 +0000 Received: from [85.158.143.35:53437] by server-3.bemta-4.messagelabs.com id D9/AA-05853-D6658AF4; Mon, 07 May 2012 23:10:37 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-4.tower-21.messagelabs.com!1336432235!10121985!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17902 invoked from network); 7 May 2012 23:10:36 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-4.tower-21.messagelabs.com with SMTP; 7 May 2012 23:10:36 -0000 Received: (qmail 20972 invoked from network); 8 May 2012 01:10:31 +0200 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 mail.netsafe.cz) (127.0.0.1) by localhost with SMTP; 8 May 2012 01:10:31 +0200 Received: from 195.47.79.16 (SquirrelMail authenticated user pavel) by mail.netsafe.cz with HTTP; Tue, 8 May 2012 01:10:32 +0200 (CEST) Message-ID: <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> In-Reply-To: <20120507173144.GB17704@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <20120507173144.GB17704@phenom.dumpdata.com> Date: Tue, 8 May 2012 01:10:32 +0200 (CEST) From: "Pavel Mateja" To: "Konrad Rzeszutek Wilk" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: >> Hi, >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest >> kernel. >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x >> xenified >> kernel. See attached log. >> >> So I tried just to update and patch xen and kernel, but I had no luck so >> far. >> >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang >> recently. >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html >> >> I tried two kernels >> testing-3.5-with-extra and xen/next-3.2 from >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git >> and >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git >> Both with ioperm opcode patch which is required by the ATI patch. See >> attachement. >> >> The xen/next-3.2 branch kernel was able to start booting windows. >> With Catalyst driver installed I just saw bluescreen during Windows >> boot. >> Without Catalyst driver Windows were able to boot but Windows ended >> frozen or >> USB was not working. It was hard to tell because input devices had no >> response >> at all. >> >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 >> kernel >> during Windows boot. I guess I have to rework the io_bitmap patch >> somehow. > > When you say 'io_bitmap' patch are you referring to these ones: > > 70a357d xen: implement IO permission bitmap > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > 93b7a2a x86: demacro set_iopl_mask() > > ? I don't think those are in that tag. They are in the kitchensink - > #testing > - does it work with that branch? > > The next-3.2 is a bit old. I should actually delete it. Hi, I mean this patch below. I think it was originally here: http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01139.h= tml Then I was told by you to use devel/ioperm branch which I think doesn't exist anymore: http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg01213.h= tml I'm too tired to test #testing branch now. I'll try it tomorrow after some sleep. >> diff --git a/arch/x86/include/asm/paravirt.h >> b/arch/x86/include/asm/paravirt.h >> index aa0f913..259ef7f 100644 >> --- a/arch/x86/include/asm/paravirt.h >> +++ b/arch/x86/include/asm/paravirt.h >> @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, >> int entry, const gate_desc *g) >> { >> PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); >> } >> + >> static inline void set_iopl_mask(unsigned mask) >> { >> PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); >> } >> >> +static inline void set_io_bitmap(struct thread_struct *thread, >> + unsigned long bytes_updated) >> +{ >> + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); >> +} >> + >> /* The paravirtualized I/O functions */ >> static inline void slow_down_io(void) >> { >> diff --git a/arch/x86/include/asm/paravirt_types.h >> b/arch/x86/include/asm/paravirt_types.h >> index 8e8b9a4..96f267c 100644 >> --- a/arch/x86/include/asm/paravirt_types.h >> +++ b/arch/x86/include/asm/paravirt_types.h >> @@ -142,6 +142,8 @@ struct pv_cpu_ops { >> void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); >> >> void (*set_iopl_mask)(unsigned mask); >> + void (*set_io_bitmap)(struct thread_struct *thread, >> + unsigned long bytes_updated); >> >> void (*wbinvd)(void); >> void (*io_delay)(void); >> diff --git a/arch/x86/include/asm/processor.h >> b/arch/x86/include/asm/processor.h >> index 4fa7dcc..62becce 100644 >> --- a/arch/x86/include/asm/processor.h >> +++ b/arch/x86/include/asm/processor.h >> @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned >> mask) >> #endif >> } >> >> +extern void native_set_io_bitmap(struct thread_struct *thread, >> + unsigned long updated_bytes); >> + >> static inline void >> native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) >> { >> @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, >> } >> >> #define set_iopl_mask native_set_iopl_mask >> +#define set_io_bitmap native_set_io_bitmap >> #endif /* CONFIG_PARAVIRT */ >> >> /* >> diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c >> index 8c96897..c372ef0 100644 >> --- a/arch/x86/kernel/ioport.c >> +++ b/arch/x86/kernel/ioport.c >> @@ -17,13 +17,29 @@ >> #include >> #include >> >> +void native_set_io_bitmap(struct thread_struct *t, >> + unsigned long bytes_updated) >> +{ >> + struct tss_struct *tss; >> + >> + if (!bytes_updated) >> + return; >> + >> + tss =3D &__get_cpu_var(init_tss); >> + >> + /* Update the TSS: */ >> + if (t->io_bitmap_ptr) >> + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); >> + else >> + memset(tss->io_bitmap, 0xff, bytes_updated); >> +} >> + >> /* >> * this changes the io permissions bitmap in the current task. >> */ >> asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int >> turn_on) >> { >> struct thread_struct *t =3D ¤t->thread; >> - struct tss_struct *tss; >> unsigned int i, max_long, bytes, bytes_updated; >> >> if ((from + num <=3D from) || (from + num > IO_BITMAP_BITS)) >> @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, >> unsigned long num, int turn_on) >> } >> >> /* >> - * do it in the per-thread copy and in the TSS ... >> + * do it in the per-thread copy >> * >> - * Disable preemption via get_cpu() - we must not switch away >> + * Disable preemption - we must not switch away >> * because the ->io_bitmap_max value must match the bitmap >> * contents: >> */ >> - tss =3D &per_cpu(init_tss, get_cpu()); >> + preempt_disable(); >> >> if (turn_on) >> bitmap_clear(t->io_bitmap_ptr, from, num); >> @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, >> unsigned long num, int turn_on) >> >> t->io_bitmap_max =3D bytes; >> >> - /* Update the TSS: */ >> - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); >> + set_io_bitmap(t, bytes_updated); >> >> - put_cpu(); >> + preempt_enable(); >> >> return 0; >> } >> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c >> index ab13760..aa420e7 100644 >> --- a/arch/x86/kernel/paravirt.c >> +++ b/arch/x86/kernel/paravirt.c >> @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops =3D { >> .swapgs =3D native_swapgs, >> >> .set_iopl_mask =3D native_set_iopl_mask, >> + .set_io_bitmap =3D native_set_io_bitmap, >> .io_delay =3D native_io_delay, >> >> .start_context_switch =3D paravirt_nop, >> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c >> index 1d92a5a..e8436cc 100644 >> --- a/arch/x86/kernel/process.c >> +++ b/arch/x86/kernel/process.c >> @@ -91,16 +91,12 @@ void exit_thread(void) >> unsigned long *bp =3D t->io_bitmap_ptr; >> >> if (bp) { >> - struct tss_struct *tss =3D &per_cpu(init_tss, get_cpu()); >> - >> + preempt_disable(); >> t->io_bitmap_ptr =3D NULL; >> clear_thread_flag(TIF_IO_BITMAP); >> - /* >> - * Careful, clear this in the TSS too: >> - */ >> - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); >> + set_io_bitmap(t, t->io_bitmap_max); >> t->io_bitmap_max =3D 0; >> - put_cpu(); >> + preempt_enable(); >> kfree(bp); >> } >> } >> @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, >> struct task_struct *next_p, >> hard_enable_TSC(); >> } >> >> - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { >> - /* >> - * Copy the relevant range of the IO bitmap. >> - * Normally this is 128 bytes or less: >> - */ >> - memcpy(tss->io_bitmap, next->io_bitmap_ptr, >> - max(prev->io_bitmap_max, next->io_bitmap_max)); >> - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { >> - /* >> - * Clear any possible leftover bits: >> - */ >> - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); >> - } >> + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || >> + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) >> + set_io_bitmap(next, >> + max(prev->io_bitmap_max, >> next->io_bitmap_max)); >> + >> propagate_user_return_notify(prev_p, next_p); >> } >> >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >> index 8853204..7a05509 100644 >> --- a/arch/x86/xen/enlighten.c >> +++ b/arch/x86/xen/enlighten.c >> @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) >> HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); >> } >> >> +static void xen_set_io_bitmap(struct thread_struct *thread, >> + int changed, unsigned long bytes_updated) >> +{ >> + struct physdev_set_iobitmap set_iobitmap; >> + >> + set_xen_guest_handle(set_iobitmap.bitmap, >> + (char *)thread->io_bitmap_ptr); >> + set_iobitmap.nr_ports =3D thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; >> + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, >> + &set_iobitmap)); >> +} >> + >> static void xen_io_delay(void) >> { >> } >> @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops >> __initconst =3D { >> .load_sp0 =3D xen_load_sp0, >> >> .set_iopl_mask =3D xen_set_iopl_mask, >> + .set_io_bitmap =3D xen_set_io_bitmap, >> .io_delay =3D xen_io_delay, >> >> /* Xen takes care of %gs when switching to usermode for us */ -- = Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:13:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRX70-0002u9-Ht; Mon, 07 May 2012 23:13:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRX6z-0002u0-76 for xen-devel@lists.xensource.com; Mon, 07 May 2012 23:13:01 +0000 Received: from [193.109.254.147:62702] by server-8.bemta-14.messagelabs.com id 11/43-23244-CF658AF4; Mon, 07 May 2012 23:13:00 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336432378!380025!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE1MTc2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30923 invoked from network); 7 May 2012 23:12:59 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 23:12:59 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47NCusZ021416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 23:12: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 q47NCuck004699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 23:12:56 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 q47NCujn019907; Mon, 7 May 2012 18:12:56 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 16:12:56 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 040BB4031D; Mon, 7 May 2012 19:07:07 -0400 (EDT) Date: Mon, 7 May 2012 19:07:07 -0400 From: Konrad Rzeszutek Wilk To: Pavel Mateja Message-ID: <20120507230707.GA28744@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <20120507173144.GB17704@phenom.dumpdata.com> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 01:10:32AM +0200, Pavel Mateja wrote: > > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: > >> Hi, > >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest > >> kernel. > >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x > >> xenified > >> kernel. See attached log. > >> > >> So I tried just to update and patch xen and kernel, but I had no luck = so > >> far. > >> > >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang > >> recently. > >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html > >> > >> I tried two kernels > >> testing-3.5-with-extra and xen/next-3.2 from > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > >> and > >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > >> Both with ioperm opcode patch which is required by the ATI patch. See > >> attachement. > >> > >> The xen/next-3.2 branch kernel was able to start booting windows. > >> With Catalyst driver installed I just saw bluescreen during Windows > >> boot. > >> Without Catalyst driver Windows were able to boot but Windows ended > >> frozen or > >> USB was not working. It was hard to tell because input devices had no > >> response > >> at all. > >> > >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 > >> kernel > >> during Windows boot. I guess I have to rework the io_bitmap patch > >> somehow. > > > > When you say 'io_bitmap' patch are you referring to these ones: > > > > 70a357d xen: implement IO permission bitmap > > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > > 93b7a2a x86: demacro set_iopl_mask() > > > > ? I don't think those are in that tag. They are in the kitchensink - > > #testing > > - does it work with that branch? > > > > The next-3.2 is a bit old. I should actually delete it. > = > Hi, > I mean this patch below. > I think it was originally here: > http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01139= .html > Then I was told by you to use devel/ioperm branch which I think doesn't > exist anymore: > http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg01213= .html It certainly does :-) > = > I'm too tired to test #testing branch now. I'll try it tomorrow after some > sleep. OK, take your time. > = > >> diff --git a/arch/x86/include/asm/paravirt.h Looks like those patches all squashed together. > >> b/arch/x86/include/asm/paravirt.h > >> index aa0f913..259ef7f 100644 > >> --- a/arch/x86/include/asm/paravirt.h > >> +++ b/arch/x86/include/asm/paravirt.h > >> @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, > >> int entry, const gate_desc *g) > >> { > >> PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); > >> } > >> + > >> static inline void set_iopl_mask(unsigned mask) > >> { > >> PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); > >> } > >> > >> +static inline void set_io_bitmap(struct thread_struct *thread, > >> + unsigned long bytes_updated) > >> +{ > >> + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); > >> +} > >> + > >> /* The paravirtualized I/O functions */ > >> static inline void slow_down_io(void) > >> { > >> diff --git a/arch/x86/include/asm/paravirt_types.h > >> b/arch/x86/include/asm/paravirt_types.h > >> index 8e8b9a4..96f267c 100644 > >> --- a/arch/x86/include/asm/paravirt_types.h > >> +++ b/arch/x86/include/asm/paravirt_types.h > >> @@ -142,6 +142,8 @@ struct pv_cpu_ops { > >> void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); > >> > >> void (*set_iopl_mask)(unsigned mask); > >> + void (*set_io_bitmap)(struct thread_struct *thread, > >> + unsigned long bytes_updated); > >> > >> void (*wbinvd)(void); > >> void (*io_delay)(void); > >> diff --git a/arch/x86/include/asm/processor.h > >> b/arch/x86/include/asm/processor.h > >> index 4fa7dcc..62becce 100644 > >> --- a/arch/x86/include/asm/processor.h > >> +++ b/arch/x86/include/asm/processor.h > >> @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned > >> mask) > >> #endif > >> } > >> > >> +extern void native_set_io_bitmap(struct thread_struct *thread, > >> + unsigned long updated_bytes); > >> + > >> static inline void > >> native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) > >> { > >> @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, > >> } > >> > >> #define set_iopl_mask native_set_iopl_mask > >> +#define set_io_bitmap native_set_io_bitmap > >> #endif /* CONFIG_PARAVIRT */ > >> > >> /* > >> diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c > >> index 8c96897..c372ef0 100644 > >> --- a/arch/x86/kernel/ioport.c > >> +++ b/arch/x86/kernel/ioport.c > >> @@ -17,13 +17,29 @@ > >> #include > >> #include > >> > >> +void native_set_io_bitmap(struct thread_struct *t, > >> + unsigned long bytes_updated) > >> +{ > >> + struct tss_struct *tss; > >> + > >> + if (!bytes_updated) > >> + return; > >> + > >> + tss =3D &__get_cpu_var(init_tss); > >> + > >> + /* Update the TSS: */ > >> + if (t->io_bitmap_ptr) > >> + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated= ); > >> + else > >> + memset(tss->io_bitmap, 0xff, bytes_updated); > >> +} > >> + > >> /* > >> * this changes the io permissions bitmap in the current task. > >> */ > >> asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int > >> turn_on) > >> { > >> struct thread_struct *t =3D ¤t->thread; > >> - struct tss_struct *tss; > >> unsigned int i, max_long, bytes, bytes_updated; > >> > >> if ((from + num <=3D from) || (from + num > IO_BITMAP_BITS)) > >> @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, > >> unsigned long num, int turn_on) > >> } > >> > >> /* > >> - * do it in the per-thread copy and in the TSS ... > >> + * do it in the per-thread copy > >> * > >> - * Disable preemption via get_cpu() - we must not switch away > >> + * Disable preemption - we must not switch away > >> * because the ->io_bitmap_max value must match the bitmap > >> * contents: > >> */ > >> - tss =3D &per_cpu(init_tss, get_cpu()); > >> + preempt_disable(); > >> > >> if (turn_on) > >> bitmap_clear(t->io_bitmap_ptr, from, num); > >> @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, > >> unsigned long num, int turn_on) > >> > >> t->io_bitmap_max =3D bytes; > >> > >> - /* Update the TSS: */ > >> - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); > >> + set_io_bitmap(t, bytes_updated); > >> > >> - put_cpu(); > >> + preempt_enable(); > >> > >> return 0; > >> } > >> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c > >> index ab13760..aa420e7 100644 > >> --- a/arch/x86/kernel/paravirt.c > >> +++ b/arch/x86/kernel/paravirt.c > >> @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops =3D { > >> .swapgs =3D native_swapgs, > >> > >> .set_iopl_mask =3D native_set_iopl_mask, > >> + .set_io_bitmap =3D native_set_io_bitmap, > >> .io_delay =3D native_io_delay, > >> > >> .start_context_switch =3D paravirt_nop, > >> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > >> index 1d92a5a..e8436cc 100644 > >> --- a/arch/x86/kernel/process.c > >> +++ b/arch/x86/kernel/process.c > >> @@ -91,16 +91,12 @@ void exit_thread(void) > >> unsigned long *bp =3D t->io_bitmap_ptr; > >> > >> if (bp) { > >> - struct tss_struct *tss =3D &per_cpu(init_tss, get_cpu()); > >> - > >> + preempt_disable(); > >> t->io_bitmap_ptr =3D NULL; > >> clear_thread_flag(TIF_IO_BITMAP); > >> - /* > >> - * Careful, clear this in the TSS too: > >> - */ > >> - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); > >> + set_io_bitmap(t, t->io_bitmap_max); > >> t->io_bitmap_max =3D 0; > >> - put_cpu(); > >> + preempt_enable(); > >> kfree(bp); > >> } > >> } > >> @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, > >> struct task_struct *next_p, > >> hard_enable_TSC(); > >> } > >> > >> - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { > >> - /* > >> - * Copy the relevant range of the IO bitmap. > >> - * Normally this is 128 bytes or less: > >> - */ > >> - memcpy(tss->io_bitmap, next->io_bitmap_ptr, > >> - max(prev->io_bitmap_max, next->io_bitmap_max)); > >> - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { > >> - /* > >> - * Clear any possible leftover bits: > >> - */ > >> - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); > >> - } > >> + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || > >> + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) > >> + set_io_bitmap(next, > >> + max(prev->io_bitmap_max, > >> next->io_bitmap_max)); > >> + > >> propagate_user_return_notify(prev_p, next_p); > >> } > >> > >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >> index 8853204..7a05509 100644 > >> --- a/arch/x86/xen/enlighten.c > >> +++ b/arch/x86/xen/enlighten.c > >> @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) > >> HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); > >> } > >> > >> +static void xen_set_io_bitmap(struct thread_struct *thread, > >> + int changed, unsigned long bytes_updated) > >> +{ > >> + struct physdev_set_iobitmap set_iobitmap; > >> + > >> + set_xen_guest_handle(set_iobitmap.bitmap, > >> + (char *)thread->io_bitmap_ptr); > >> + set_iobitmap.nr_ports =3D thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; > >> + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, > >> + &set_iobitmap)); > >> +} > >> + > >> static void xen_io_delay(void) > >> { > >> } > >> @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops > >> __initconst =3D { > >> .load_sp0 =3D xen_load_sp0, > >> > >> .set_iopl_mask =3D xen_set_iopl_mask, > >> + .set_io_bitmap =3D xen_set_io_bitmap, > >> .io_delay =3D xen_io_delay, > >> > >> /* Xen takes care of %gs when switching to usermode for us */ > = > -- = > Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:13:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRX70-0002u9-Ht; Mon, 07 May 2012 23:13:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRX6z-0002u0-76 for xen-devel@lists.xensource.com; Mon, 07 May 2012 23:13:01 +0000 Received: from [193.109.254.147:62702] by server-8.bemta-14.messagelabs.com id 11/43-23244-CF658AF4; Mon, 07 May 2012 23:13:00 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336432378!380025!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE1MTc2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30923 invoked from network); 7 May 2012 23:12:59 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 May 2012 23:12:59 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47NCusZ021416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 23:12: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 q47NCuck004699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2012 23:12:56 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 q47NCujn019907; Mon, 7 May 2012 18:12:56 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 16:12:56 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 040BB4031D; Mon, 7 May 2012 19:07:07 -0400 (EDT) Date: Mon, 7 May 2012 19:07:07 -0400 From: Konrad Rzeszutek Wilk To: Pavel Mateja Message-ID: <20120507230707.GA28744@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <20120507173144.GB17704@phenom.dumpdata.com> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 01:10:32AM +0200, Pavel Mateja wrote: > > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: > >> Hi, > >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest > >> kernel. > >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x > >> xenified > >> kernel. See attached log. > >> > >> So I tried just to update and patch xen and kernel, but I had no luck = so > >> far. > >> > >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang > >> recently. > >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html > >> > >> I tried two kernels > >> testing-3.5-with-extra and xen/next-3.2 from > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > >> and > >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > >> Both with ioperm opcode patch which is required by the ATI patch. See > >> attachement. > >> > >> The xen/next-3.2 branch kernel was able to start booting windows. > >> With Catalyst driver installed I just saw bluescreen during Windows > >> boot. > >> Without Catalyst driver Windows were able to boot but Windows ended > >> frozen or > >> USB was not working. It was hard to tell because input devices had no > >> response > >> at all. > >> > >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 > >> kernel > >> during Windows boot. I guess I have to rework the io_bitmap patch > >> somehow. > > > > When you say 'io_bitmap' patch are you referring to these ones: > > > > 70a357d xen: implement IO permission bitmap > > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > > 93b7a2a x86: demacro set_iopl_mask() > > > > ? I don't think those are in that tag. They are in the kitchensink - > > #testing > > - does it work with that branch? > > > > The next-3.2 is a bit old. I should actually delete it. > = > Hi, > I mean this patch below. > I think it was originally here: > http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg01139= .html > Then I was told by you to use devel/ioperm branch which I think doesn't > exist anymore: > http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg01213= .html It certainly does :-) > = > I'm too tired to test #testing branch now. I'll try it tomorrow after some > sleep. OK, take your time. > = > >> diff --git a/arch/x86/include/asm/paravirt.h Looks like those patches all squashed together. > >> b/arch/x86/include/asm/paravirt.h > >> index aa0f913..259ef7f 100644 > >> --- a/arch/x86/include/asm/paravirt.h > >> +++ b/arch/x86/include/asm/paravirt.h > >> @@ -340,11 +340,18 @@ static inline void write_idt_entry(gate_desc *dt, > >> int entry, const gate_desc *g) > >> { > >> PVOP_VCALL3(pv_cpu_ops.write_idt_entry, dt, entry, g); > >> } > >> + > >> static inline void set_iopl_mask(unsigned mask) > >> { > >> PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask); > >> } > >> > >> +static inline void set_io_bitmap(struct thread_struct *thread, > >> + unsigned long bytes_updated) > >> +{ > >> + PVOP_VCALL2(pv_cpu_ops.set_io_bitmap, thread, bytes_updated); > >> +} > >> + > >> /* The paravirtualized I/O functions */ > >> static inline void slow_down_io(void) > >> { > >> diff --git a/arch/x86/include/asm/paravirt_types.h > >> b/arch/x86/include/asm/paravirt_types.h > >> index 8e8b9a4..96f267c 100644 > >> --- a/arch/x86/include/asm/paravirt_types.h > >> +++ b/arch/x86/include/asm/paravirt_types.h > >> @@ -142,6 +142,8 @@ struct pv_cpu_ops { > >> void (*load_sp0)(struct tss_struct *tss, struct thread_struct *t); > >> > >> void (*set_iopl_mask)(unsigned mask); > >> + void (*set_io_bitmap)(struct thread_struct *thread, > >> + unsigned long bytes_updated); > >> > >> void (*wbinvd)(void); > >> void (*io_delay)(void); > >> diff --git a/arch/x86/include/asm/processor.h > >> b/arch/x86/include/asm/processor.h > >> index 4fa7dcc..62becce 100644 > >> --- a/arch/x86/include/asm/processor.h > >> +++ b/arch/x86/include/asm/processor.h > >> @@ -503,6 +503,9 @@ static inline void native_set_iopl_mask(unsigned > >> mask) > >> #endif > >> } > >> > >> +extern void native_set_io_bitmap(struct thread_struct *thread, > >> + unsigned long updated_bytes); > >> + > >> static inline void > >> native_load_sp0(struct tss_struct *tss, struct thread_struct *thread) > >> { > >> @@ -536,6 +539,7 @@ static inline void load_sp0(struct tss_struct *tss, > >> } > >> > >> #define set_iopl_mask native_set_iopl_mask > >> +#define set_io_bitmap native_set_io_bitmap > >> #endif /* CONFIG_PARAVIRT */ > >> > >> /* > >> diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c > >> index 8c96897..c372ef0 100644 > >> --- a/arch/x86/kernel/ioport.c > >> +++ b/arch/x86/kernel/ioport.c > >> @@ -17,13 +17,29 @@ > >> #include > >> #include > >> > >> +void native_set_io_bitmap(struct thread_struct *t, > >> + unsigned long bytes_updated) > >> +{ > >> + struct tss_struct *tss; > >> + > >> + if (!bytes_updated) > >> + return; > >> + > >> + tss =3D &__get_cpu_var(init_tss); > >> + > >> + /* Update the TSS: */ > >> + if (t->io_bitmap_ptr) > >> + memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated= ); > >> + else > >> + memset(tss->io_bitmap, 0xff, bytes_updated); > >> +} > >> + > >> /* > >> * this changes the io permissions bitmap in the current task. > >> */ > >> asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int > >> turn_on) > >> { > >> struct thread_struct *t =3D ¤t->thread; > >> - struct tss_struct *tss; > >> unsigned int i, max_long, bytes, bytes_updated; > >> > >> if ((from + num <=3D from) || (from + num > IO_BITMAP_BITS)) > >> @@ -48,13 +64,13 @@ asmlinkage long sys_ioperm(unsigned long from, > >> unsigned long num, int turn_on) > >> } > >> > >> /* > >> - * do it in the per-thread copy and in the TSS ... > >> + * do it in the per-thread copy > >> * > >> - * Disable preemption via get_cpu() - we must not switch away > >> + * Disable preemption - we must not switch away > >> * because the ->io_bitmap_max value must match the bitmap > >> * contents: > >> */ > >> - tss =3D &per_cpu(init_tss, get_cpu()); > >> + preempt_disable(); > >> > >> if (turn_on) > >> bitmap_clear(t->io_bitmap_ptr, from, num); > >> @@ -75,10 +91,9 @@ asmlinkage long sys_ioperm(unsigned long from, > >> unsigned long num, int turn_on) > >> > >> t->io_bitmap_max =3D bytes; > >> > >> - /* Update the TSS: */ > >> - memcpy(tss->io_bitmap, t->io_bitmap_ptr, bytes_updated); > >> + set_io_bitmap(t, bytes_updated); > >> > >> - put_cpu(); > >> + preempt_enable(); > >> > >> return 0; > >> } > >> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c > >> index ab13760..aa420e7 100644 > >> --- a/arch/x86/kernel/paravirt.c > >> +++ b/arch/x86/kernel/paravirt.c > >> @@ -391,6 +391,7 @@ struct pv_cpu_ops pv_cpu_ops =3D { > >> .swapgs =3D native_swapgs, > >> > >> .set_iopl_mask =3D native_set_iopl_mask, > >> + .set_io_bitmap =3D native_set_io_bitmap, > >> .io_delay =3D native_io_delay, > >> > >> .start_context_switch =3D paravirt_nop, > >> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > >> index 1d92a5a..e8436cc 100644 > >> --- a/arch/x86/kernel/process.c > >> +++ b/arch/x86/kernel/process.c > >> @@ -91,16 +91,12 @@ void exit_thread(void) > >> unsigned long *bp =3D t->io_bitmap_ptr; > >> > >> if (bp) { > >> - struct tss_struct *tss =3D &per_cpu(init_tss, get_cpu()); > >> - > >> + preempt_disable(); > >> t->io_bitmap_ptr =3D NULL; > >> clear_thread_flag(TIF_IO_BITMAP); > >> - /* > >> - * Careful, clear this in the TSS too: > >> - */ > >> - memset(tss->io_bitmap, 0xff, t->io_bitmap_max); > >> + set_io_bitmap(t, t->io_bitmap_max); > >> t->io_bitmap_max =3D 0; > >> - put_cpu(); > >> + preempt_enable(); > >> kfree(bp); > >> } > >> } > >> @@ -237,19 +233,11 @@ void __switch_to_xtra(struct task_struct *prev_p, > >> struct task_struct *next_p, > >> hard_enable_TSC(); > >> } > >> > >> - if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) { > >> - /* > >> - * Copy the relevant range of the IO bitmap. > >> - * Normally this is 128 bytes or less: > >> - */ > >> - memcpy(tss->io_bitmap, next->io_bitmap_ptr, > >> - max(prev->io_bitmap_max, next->io_bitmap_max)); > >> - } else if (test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) { > >> - /* > >> - * Clear any possible leftover bits: > >> - */ > >> - memset(tss->io_bitmap, 0xff, prev->io_bitmap_max); > >> - } > >> + if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP) || > >> + test_tsk_thread_flag(prev_p, TIF_IO_BITMAP)) > >> + set_io_bitmap(next, > >> + max(prev->io_bitmap_max, > >> next->io_bitmap_max)); > >> + > >> propagate_user_return_notify(prev_p, next_p); > >> } > >> > >> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > >> index 8853204..7a05509 100644 > >> --- a/arch/x86/xen/enlighten.c > >> +++ b/arch/x86/xen/enlighten.c > >> @@ -808,6 +808,18 @@ static void xen_set_iopl_mask(unsigned mask) > >> HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl); > >> } > >> > >> +static void xen_set_io_bitmap(struct thread_struct *thread, > >> + int changed, unsigned long bytes_updated) > >> +{ > >> + struct physdev_set_iobitmap set_iobitmap; > >> + > >> + set_xen_guest_handle(set_iobitmap.bitmap, > >> + (char *)thread->io_bitmap_ptr); > >> + set_iobitmap.nr_ports =3D thread->io_bitmap_ptr ? IO_BITMAP_BITS : 0; > >> + WARN_ON(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, > >> + &set_iobitmap)); > >> +} > >> + > >> static void xen_io_delay(void) > >> { > >> } > >> @@ -1117,6 +1129,7 @@ static const struct pv_cpu_ops xen_cpu_ops > >> __initconst =3D { > >> .load_sp0 =3D xen_load_sp0, > >> > >> .set_iopl_mask =3D xen_set_iopl_mask, > >> + .set_io_bitmap =3D xen_set_io_bitmap, > >> .io_delay =3D xen_io_delay, > >> > >> /* Xen takes care of %gs when switching to usermode for us */ > = > -- = > Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:58:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRXoQ-0003EY-IY; Mon, 07 May 2012 23:57:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRXoP-0003ET-6J for xen-devel@lists.xen.org; Mon, 07 May 2012 23:57:53 +0000 Received: from [85.158.143.99:5612] by server-3.bemta-4.messagelabs.com id 75/99-05853-08168AF4; Mon, 07 May 2012 23:57:52 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336435062!19855655!1 X-Originating-IP: [209.85.216.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22482 invoked from network); 7 May 2012 23:57:43 -0000 Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com) (209.85.216.45) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 23:57:43 -0000 Received: by qaeb19 with SMTP id b19so103425qae.11 for ; Mon, 07 May 2012 16:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kGY1dxa8Bdho7/jdUvhFBuw3GWf3opfxOj5MraQWzS8=; b=YJGjfz8A6IflAvTR60znUKY/ACldOAeQB83MiuSgUrcF6oaihPEa8inqKwX2vYW/6r irAjjGtPENq0jgro6QRclpeLUSmD3pHotdR9b54QA8WKHKx2Z8CSi3XR/oKXOpoQA5oS tADxZpHSyTY5+K8RyEIPgjmw4lwVTHrKq9sc76vR2R7ro3I/h5pCl1ixHgzSEw5F+kOP BuSmK+Z4ZPzq1NIsXfdjXvapNjAjePzxKweuDo5UJ0xnI7Cr6qKbjGPuKXPFgaU5eKPn xYuzabdGcQ0sahFW80YpFWUsiDkyr1Z8DiXl4FZ4FX4R1T6czShg60nGj26gwykMjSHh 91+Q== MIME-Version: 1.0 Received: by 10.224.42.16 with SMTP id q16mr16621266qae.70.1336435061167; Mon, 07 May 2012 16:57:41 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 16:57:41 -0700 (PDT) In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> Date: Mon, 7 May 2012 23:57:41 +0000 Message-ID: From: AP To: Jan Beulich Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 7, 2012 at 7:15 AM, Jan Beulich wrote: > > >>> On 04.05.12 at 21:30, AP wrote: > > From the above I realized that X86_CR4_OSXSAVE was never getting set > > in v->arch.pv_vcpu.ctrlreg[4]. > > Yes, that was the observation in the previous thread too, but the > reporter didn't seem interested in continuing on from there. > > > > So I tried the following patch: > > > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > > --- a/xen/arch/x86/domain.c =A0 Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/arch/x86/domain.c =A0 Fri May 04 12:23:57 2012 -0700 > > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > > =A0 =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_DE; > > =A0 =A0 =A0if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > > =A0 =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_FSGSBASE; > > - =A0 =A0if ( xsave_enabled(v) ) > > - =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_OSXSAVE; > > > > =A0 =A0 =A0if ( (guest_cr4 & hv_cr4_mask) !=3D (hv_cr4 & hv_cr4_mask) ) > > =A0 =A0 =A0 =A0 =A0gdprintk(XENLOG_WARNING, > > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > > --- a/xen/include/asm-x86/domain.h =A0 =A0Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/include/asm-x86/domain.h =A0 =A0Fri May 04 12:23:57 2012 -0700 > > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > > =A0 =A0 =A0 & ~X86_CR4_DE) > > =A0#define real_cr4_to_pv_guest_cr4(c) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > > =A0 =A0 =A0((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD =A0 =A0 =A0= =A0\ > > - =A0 =A0 =A0 =A0 =A0 =A0 | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > > + =A0 =A0 =A0 =A0 =A0 =A0 | X86_CR4_SMEP)) > > > > =A0void domain_cpuid(struct domain *d, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int =A0input, > > No, this is specifically the wrong thing. From what we know so far > (i.e. the outcome of the above printing you added) the problem in > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > attempting XSETBV). What your patch efectively does is take away > control from the guest kernels to control the (virtual) CR4 flag... > > > That allowed the system to boot successfully though I did see the > > following message: > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > ... which is what this message is telling you. > > > Not sure if the above patch is right fix but I hope it was at least > > helpful in pointing at where the problem might be. > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > xsave=3D1. > > Sure, as it's a kernel problem. It's the kernel that needs logging added, > to find out why the CR4 write supposedly happening immediately > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > happen, or doesn't set the flag. Perhaps something fishy going on xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. static void xen_write_cr4(unsigned long cr4) { =A0 =A0 cr4 &=3D ~X86_CR4_PGE; =A0 =A0 cr4 &=3D ~X86_CR4_PSE; =A0 =A0 cr4 &=3D ~X86_CR4_OSXSAVE; =A0 =A0 native_write_cr4(cr4); } I added some prints to the Ubuntu kernel (3.0.0-17) to confirm. Here is what I see: (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [=A0=A0=A0 6.834419] xstate_enable: Setting X86_CR4_OSXSAVE [=A0=A0=A0 6.838041] set_in_cr4: cr4: 0x42660 [=A0=A0=A0 6.841743] xen_write_cr4: cr4: 0x2660 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 [=A0=A0=A0 6.860546] xstate_enable: Exec xsetbv (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4: 0= x2660 [=A0=A0=A0 6.870509] invalid opcode: 0000 [#1] SMP Removing the explicit turning off of=A0X86_CR4_OSXSAVE allowed the system t= o boot. (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [ 7.554262] Setting X86_CR4_OSXSAVE [ 7.557869] set_in_cr4: cr4: 0x42660 [ 7.561551] xen_write_cr4: cr4: 0x42660 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x42660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x42660 write CR4: 0x426f0 [ 7.580522] Exec xsetbv (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [ 7.597071] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340 Thanks, AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 07 23:58:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 May 2012 23: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 ) id 1SRXoQ-0003EY-IY; Mon, 07 May 2012 23:57:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRXoP-0003ET-6J for xen-devel@lists.xen.org; Mon, 07 May 2012 23:57:53 +0000 Received: from [85.158.143.99:5612] by server-3.bemta-4.messagelabs.com id 75/99-05853-08168AF4; Mon, 07 May 2012 23:57:52 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336435062!19855655!1 X-Originating-IP: [209.85.216.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22482 invoked from network); 7 May 2012 23:57:43 -0000 Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com) (209.85.216.45) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 May 2012 23:57:43 -0000 Received: by qaeb19 with SMTP id b19so103425qae.11 for ; Mon, 07 May 2012 16:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kGY1dxa8Bdho7/jdUvhFBuw3GWf3opfxOj5MraQWzS8=; b=YJGjfz8A6IflAvTR60znUKY/ACldOAeQB83MiuSgUrcF6oaihPEa8inqKwX2vYW/6r irAjjGtPENq0jgro6QRclpeLUSmD3pHotdR9b54QA8WKHKx2Z8CSi3XR/oKXOpoQA5oS tADxZpHSyTY5+K8RyEIPgjmw4lwVTHrKq9sc76vR2R7ro3I/h5pCl1ixHgzSEw5F+kOP BuSmK+Z4ZPzq1NIsXfdjXvapNjAjePzxKweuDo5UJ0xnI7Cr6qKbjGPuKXPFgaU5eKPn xYuzabdGcQ0sahFW80YpFWUsiDkyr1Z8DiXl4FZ4FX4R1T6czShg60nGj26gwykMjSHh 91+Q== MIME-Version: 1.0 Received: by 10.224.42.16 with SMTP id q16mr16621266qae.70.1336435061167; Mon, 07 May 2012 16:57:41 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 16:57:41 -0700 (PDT) In-Reply-To: <4FA792C00200007800081F06@nat28.tlf.novell.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> Date: Mon, 7 May 2012 23:57:41 +0000 Message-ID: From: AP To: Jan Beulich Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 7, 2012 at 7:15 AM, Jan Beulich wrote: > > >>> On 04.05.12 at 21:30, AP wrote: > > From the above I realized that X86_CR4_OSXSAVE was never getting set > > in v->arch.pv_vcpu.ctrlreg[4]. > > Yes, that was the observation in the previous thread too, but the > reporter didn't seem interested in continuing on from there. > > > > So I tried the following patch: > > > > diff -r 5a0d60bb536b xen/arch/x86/domain.c > > --- a/xen/arch/x86/domain.c =A0 Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/arch/x86/domain.c =A0 Fri May 04 12:23:57 2012 -0700 > > @@ -691,8 +691,6 @@ unsigned long pv_guest_cr4_fixup(const s > > =A0 =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_DE; > > =A0 =A0 =A0if ( cpu_has_fsgsbase && !is_pv_32bit_domain(v->domain) ) > > =A0 =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_FSGSBASE; > > - =A0 =A0if ( xsave_enabled(v) ) > > - =A0 =A0 =A0 =A0hv_cr4_mask &=3D ~X86_CR4_OSXSAVE; > > > > =A0 =A0 =A0if ( (guest_cr4 & hv_cr4_mask) !=3D (hv_cr4 & hv_cr4_mask) ) > > =A0 =A0 =A0 =A0 =A0gdprintk(XENLOG_WARNING, > > diff -r 5a0d60bb536b xen/include/asm-x86/domain.h > > --- a/xen/include/asm-x86/domain.h =A0 =A0Fri Apr 27 21:10:59 2012 -0700 > > +++ b/xen/include/asm-x86/domain.h =A0 =A0Fri May 04 12:23:57 2012 -0700 > > @@ -530,7 +530,7 @@ unsigned long pv_guest_cr4_fixup(const s > > =A0 =A0 =A0 & ~X86_CR4_DE) > > =A0#define real_cr4_to_pv_guest_cr4(c) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > > =A0 =A0 =A0((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD =A0 =A0 =A0= =A0\ > > - =A0 =A0 =A0 =A0 =A0 =A0 | X86_CR4_OSXSAVE | X86_CR4_SMEP)) > > + =A0 =A0 =A0 =A0 =A0 =A0 | X86_CR4_SMEP)) > > > > =A0void domain_cpuid(struct domain *d, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int =A0input, > > No, this is specifically the wrong thing. From what we know so far > (i.e. the outcome of the above printing you added) the problem in > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > attempting XSETBV). What your patch efectively does is take away > control from the guest kernels to control the (virtual) CR4 flag... > > > That allowed the system to boot successfully though I did see the > > following message: > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > ... which is what this message is telling you. > > > Not sure if the above patch is right fix but I hope it was at least > > helpful in pointing at where the problem might be. > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > xsave=3D1. > > Sure, as it's a kernel problem. It's the kernel that needs logging added, > to find out why the CR4 write supposedly happening immediately > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > happen, or doesn't set the flag. Perhaps something fishy going on xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. static void xen_write_cr4(unsigned long cr4) { =A0 =A0 cr4 &=3D ~X86_CR4_PGE; =A0 =A0 cr4 &=3D ~X86_CR4_PSE; =A0 =A0 cr4 &=3D ~X86_CR4_OSXSAVE; =A0 =A0 native_write_cr4(cr4); } I added some prints to the Ubuntu kernel (3.0.0-17) to confirm. Here is what I see: (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [=A0=A0=A0 6.834419] xstate_enable: Setting X86_CR4_OSXSAVE [=A0=A0=A0 6.838041] set_in_cr4: cr4: 0x42660 [=A0=A0=A0 6.841743] xen_write_cr4: cr4: 0x2660 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x2660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 [=A0=A0=A0 6.860546] xstate_enable: Exec xsetbv (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4: 0= x2660 [=A0=A0=A0 6.870509] invalid opcode: 0000 [#1] SMP Removing the explicit turning off of=A0X86_CR4_OSXSAVE allowed the system t= o boot. (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [ 7.554262] Setting X86_CR4_OSXSAVE [ 7.557869] set_in_cr4: cr4: 0x42660 [ 7.561551] xen_write_cr4: cr4: 0x42660 (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: 0xfffffffffffbfff3 returning cr4: 0x42660 (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x42660 write CR4: 0x426f0 [ 7.580522] Exec xsetbv (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported [ 7.597071] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340 Thanks, AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 00:14:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 00: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 ) id 1SRY4H-0003r6-65; Tue, 08 May 2012 00:14:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRY4F-0003r1-Ro for xen-devel@lists.xen.org; Tue, 08 May 2012 00:14:16 +0000 Received: from [193.109.254.147:22000] by server-3.bemta-14.messagelabs.com id A4/8F-23274-75568AF4; Tue, 08 May 2012 00:14:15 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336436053!8108173!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNzU4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20777 invoked from network); 8 May 2012 00:14:14 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 00:14:14 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q480E557026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 00:14:06 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 q480E3wV005731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 00:14:03 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 q480E2Mp017657; Mon, 7 May 2012 19:14:02 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 17:14:01 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7D0FD4031D; Mon, 7 May 2012 20:08:13 -0400 (EDT) Date: Mon, 7 May 2012 20:08:13 -0400 From: Konrad Rzeszutek Wilk To: AP , stefan.bader@canonical.com Message-ID: <20120508000813.GA29587@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Jeremy Fitzhardinge , weidong.han@intel.com, Tim.Deegan@citrix.com, Jan Beulich , xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > No, this is specifically the wrong thing. From what we know so far > > (i.e. the outcome of the above printing you added) the problem in > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > attempting XSETBV). What your patch efectively does is take away > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > That allowed the system to boot successfully though I did see the > > > following message: > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > > > ... which is what this message is telling you. > > > > > Not sure if the above patch is right fix but I hope it was at least > > > helpful in pointing at where the problem might be. > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > xsave=3D1. > > > > Sure, as it's a kernel problem. It's the kernel that needs logging adde= d, > > to find out why the CR4 write supposedly happening immediately > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > happen, or doesn't set the flag. Perhaps something fishy going on > = > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. Where did you see that code? Looking at the Linus's tree this is what I see http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f= =3Darch/x86/xen/enlighten.c;h=3Da8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb= =3DHEAD So who added that code? I am not seeing it in v3.0 either? > = > static void xen_write_cr4(unsigned long cr4) > { > =A0 =A0 cr4 &=3D ~X86_CR4_PGE; > =A0 =A0 cr4 &=3D ~X86_CR4_PSE; > =A0 =A0 cr4 &=3D ~X86_CR4_OSXSAVE; > = > =A0 =A0 native_write_cr4(cr4); > } > = > I added some prints to the Ubuntu kernel (3.0.0-17) to confirm. Here > is what I see: > = > > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [=A0=A0=A0 6.834419] xstate_enable: Setting X86_CR4_OSXSAVE > [=A0=A0=A0 6.838041] set_in_cr4: cr4: 0x42660 > [=A0=A0=A0 6.841743] xen_write_cr4: cr4: 0x2660 > (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: > 0xfffffffffffbfff3 returning cr4: 0x2660 > (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 > [=A0=A0=A0 6.860546] xstate_enable: Exec xsetbv > (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4:= 0x2660 > [=A0=A0=A0 6.870509] invalid opcode: 0000 [#1] SMP > > = > Removing the explicit turning off of=A0X86_CR4_OSXSAVE allowed the system= to boot. > = > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [ 7.554262] Setting X86_CR4_OSXSAVE > [ 7.557869] set_in_cr4: cr4: 0x42660 > [ 7.561551] xen_write_cr4: cr4: 0x42660 > (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: > 0xfffffffffffbfff3 returning cr4: 0x42660 > (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x42660 write CR4: 0x426f0 > [ 7.580522] Exec xsetbv > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [ 7.597071] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340 > = > Thanks, > AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 00:14:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 00: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 ) id 1SRY4H-0003r6-65; Tue, 08 May 2012 00:14:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRY4F-0003r1-Ro for xen-devel@lists.xen.org; Tue, 08 May 2012 00:14:16 +0000 Received: from [193.109.254.147:22000] by server-3.bemta-14.messagelabs.com id A4/8F-23274-75568AF4; Tue, 08 May 2012 00:14:15 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336436053!8108173!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNzU4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20777 invoked from network); 8 May 2012 00:14:14 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 00:14:14 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q480E557026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 00:14:06 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 q480E3wV005731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 00:14:03 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 q480E2Mp017657; Mon, 7 May 2012 19:14:02 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 May 2012 17:14:01 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7D0FD4031D; Mon, 7 May 2012 20:08:13 -0400 (EDT) Date: Mon, 7 May 2012 20:08:13 -0400 From: Konrad Rzeszutek Wilk To: AP , stefan.bader@canonical.com Message-ID: <20120508000813.GA29587@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Jeremy Fitzhardinge , weidong.han@intel.com, Tim.Deegan@citrix.com, Jan Beulich , xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > No, this is specifically the wrong thing. From what we know so far > > (i.e. the outcome of the above printing you added) the problem in > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > attempting XSETBV). What your patch efectively does is take away > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > That allowed the system to boot successfully though I did see the > > > following message: > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> 00002660 > > > > ... which is what this message is telling you. > > > > > Not sure if the above patch is right fix but I hope it was at least > > > helpful in pointing at where the problem might be. > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > xsave=3D1. > > > > Sure, as it's a kernel problem. It's the kernel that needs logging adde= d, > > to find out why the CR4 write supposedly happening immediately > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > happen, or doesn't set the flag. Perhaps something fishy going on > = > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. Where did you see that code? Looking at the Linus's tree this is what I see http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f= =3Darch/x86/xen/enlighten.c;h=3Da8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb= =3DHEAD So who added that code? I am not seeing it in v3.0 either? > = > static void xen_write_cr4(unsigned long cr4) > { > =A0 =A0 cr4 &=3D ~X86_CR4_PGE; > =A0 =A0 cr4 &=3D ~X86_CR4_PSE; > =A0 =A0 cr4 &=3D ~X86_CR4_OSXSAVE; > = > =A0 =A0 native_write_cr4(cr4); > } > = > I added some prints to the Ubuntu kernel (3.0.0-17) to confirm. Here > is what I see: > = > > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [=A0=A0=A0 6.834419] xstate_enable: Setting X86_CR4_OSXSAVE > [=A0=A0=A0 6.838041] set_in_cr4: cr4: 0x42660 > [=A0=A0=A0 6.841743] xen_write_cr4: cr4: 0x2660 > (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: > 0xfffffffffffbfff3 returning cr4: 0x2660 > (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x2660 write CR4: 0x426f0 > [=A0=A0=A0 6.860546] xstate_enable: Exec xsetbv > (XEN) traps.c:2254:d0 XSETBV: lock: 0 rep_prefix: 0 opsize_prefix: 0 cr4:= 0x2660 > [=A0=A0=A0 6.870509] invalid opcode: 0000 [#1] SMP > > = > Removing the explicit turning off of=A0X86_CR4_OSXSAVE allowed the system= to boot. > = > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [ 7.554262] Setting X86_CR4_OSXSAVE > [ 7.557869] set_in_cr4: cr4: 0x42660 > [ 7.561551] xen_write_cr4: cr4: 0x42660 > (XEN) domain.c:704:d0 vcpu[0] hv_cr4: 0x2660 hv_cr4_mask: > 0xfffffffffffbfff3 returning cr4: 0x42660 > (XEN) traps.c:2409:d0 vcpu[0] pv cr4: 0x42660 write CR4: 0x426f0 > [ 7.580522] Exec xsetbv > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > (XEN) traps.c:874:d0 vcpu[0] cpuid XSAVE supported > [ 7.597071] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340 > = > Thanks, > AP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 00:42:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 00: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 ) id 1SRYUf-00043O-FS; Tue, 08 May 2012 00:41:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRYUd-00043J-OJ for xen-devel@lists.xen.org; Tue, 08 May 2012 00:41:32 +0000 Received: from [193.109.254.147:42265] by server-10.bemta-14.messagelabs.com id 86/53-05847-BBB68AF4; Tue, 08 May 2012 00:41:31 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336437688!8076798!1 X-Originating-IP: [209.85.216.50] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32339 invoked from network); 8 May 2012 00:41:29 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 00:41:29 -0000 Received: by qafl39 with SMTP id l39so130493qaf.16 for ; Mon, 07 May 2012 17:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RPJynTei9EOzH205hPb9ailP727lf+kWRKaoJT98hJQ=; b=fW0jLzHVtlpIHt5qPkYg7OenOcrngkeFZpv11bOZMsYgQyFV551LLETez1fMpUzyzn CcYGx2iF11QuHsyMwTT4wee9KliST2uNHiTMWkpm1+/gEdGfCEw4JINXj+Fpo0Tz+tow 8VwVF0M8VBRCEcJo5Wb6NaGmpNTWviaf3t5/R5UokHvoR2ivzSoPqNzPlVqnSKjM+DjY CUuhlbpaTmHI8MeOCle7ym+GaNbI1ecB88FO9jmzF0S6C5e9tDOjStRzlEKel4E2EndN 3Vad4eFsYA+G89oRZ1TQnrCXLCx1Q7CkIvR4RNHHUxDg7HLNssg38IBINPl10C87XiUA Dr9Q== MIME-Version: 1.0 Received: by 10.224.100.71 with SMTP id x7mr28218404qan.92.1336437688424; Mon, 07 May 2012 17:41:28 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 17:41:28 -0700 (PDT) In-Reply-To: <20120508000813.GA29587@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> Date: Mon, 7 May 2012 17:41:28 -0700 Message-ID: From: AP To: Konrad Rzeszutek Wilk Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1582347597455724365==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1582347597455724365== Content-Type: multipart/alternative; boundary=20cf306f7414aed87e04bf7ba5ca --20cf306f7414aed87e04bf7ba5ca Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < konrad.wilk@oracle.com> wrote: > > > > No, this is specifically the wrong thing. From what we know so far > > > (i.e. the outcome of the above printing you added) the problem in > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > attempting XSETBV). What your patch efectively does is take away > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > That allowed the system to boot successfully though I did see the > > > > following message: > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > 00002660 > > > > > > ... which is what this message is telling you. > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > helpful in pointing at where the problem might be. > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > xsave=1. > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > added, > > > to find out why the CR4 write supposedly happening immediately > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > Where did you see that code? Looking at the Linus's tree this is what I > see > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > So who added that code? I am not seeing it in v3.0 either? This is in the Ubuntu 11.10 kernel: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 After some digging around, it looks like this is an Ubuntu 11.10 only patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Thanks, AP --20cf306f7414aed87e04bf7ba5ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
&= gt; > > No, this is specifically the wrong thing. From what we know s= o far
> > > (i.e. the outcome of the above printing you added) the probl= em in
> > > in the Dom0 kernel (in it never setting CR4.OSXSAVE= prior to
> > > attempting XSETBV). What your patch efectively = does is take away
> > > control from the guest kernels to control the (virtual) CR4 = flag...
> > >
> > > > That allowed the system to= boot successfully though I did see the
> > > > following me= ssage:
> > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042= 660 ->
> > > > 00002660
> > >
> > &g= t; ... which is what this message is telling you.
> > >
> > > > Not sure if the above patch is right fix but I hope it = was at least
> > > > helpful in pointing at where the proble= m might be.
> > > >
> > > > BTW, I see the sa= me invalid op issue with Xen 4.1.2 if I boot with
> > > > xsave=3D1.
> > >
> > > Sure, as= it's a kernel problem. It's the kernel that needs logging
> = > > added,
> > > to find out why the CR4 write supposedly= happening immediately
> > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn'= t actually
> > > happen, or doesn't set the flag. Perhaps s= omething fishy going on
> >
> > xen_write_cr4 explicitly = turns off X86_CR4_OSXSAVE.
>
> Where did you see that code? Looking at the Linus's tree t= his is what I
> see
>
> http://git.kern= el.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3Darch/x86/xen/e= nlighten.c;h=3Da8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=3DHEAD
>
> So who added that code? I am not seeing it in v3.0 either?
=
This is in the Ubuntu 11.10 kernel:

After some digging around, it looks=A0like this is an U= buntu 11.10 only patch:

Thanks,
AP

--20cf306f7414aed87e04bf7ba5ca-- --===============1582347597455724365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1582347597455724365==-- From xen-devel-bounces@lists.xen.org Tue May 08 00:42:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 00: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 ) id 1SRYUf-00043O-FS; Tue, 08 May 2012 00:41:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRYUd-00043J-OJ for xen-devel@lists.xen.org; Tue, 08 May 2012 00:41:32 +0000 Received: from [193.109.254.147:42265] by server-10.bemta-14.messagelabs.com id 86/53-05847-BBB68AF4; Tue, 08 May 2012 00:41:31 +0000 X-Env-Sender: apxeng@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336437688!8076798!1 X-Originating-IP: [209.85.216.50] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32339 invoked from network); 8 May 2012 00:41:29 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 00:41:29 -0000 Received: by qafl39 with SMTP id l39so130493qaf.16 for ; Mon, 07 May 2012 17:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RPJynTei9EOzH205hPb9ailP727lf+kWRKaoJT98hJQ=; b=fW0jLzHVtlpIHt5qPkYg7OenOcrngkeFZpv11bOZMsYgQyFV551LLETez1fMpUzyzn CcYGx2iF11QuHsyMwTT4wee9KliST2uNHiTMWkpm1+/gEdGfCEw4JINXj+Fpo0Tz+tow 8VwVF0M8VBRCEcJo5Wb6NaGmpNTWviaf3t5/R5UokHvoR2ivzSoPqNzPlVqnSKjM+DjY CUuhlbpaTmHI8MeOCle7ym+GaNbI1ecB88FO9jmzF0S6C5e9tDOjStRzlEKel4E2EndN 3Vad4eFsYA+G89oRZ1TQnrCXLCx1Q7CkIvR4RNHHUxDg7HLNssg38IBINPl10C87XiUA Dr9Q== MIME-Version: 1.0 Received: by 10.224.100.71 with SMTP id x7mr28218404qan.92.1336437688424; Mon, 07 May 2012 17:41:28 -0700 (PDT) Received: by 10.229.163.204 with HTTP; Mon, 7 May 2012 17:41:28 -0700 (PDT) In-Reply-To: <20120508000813.GA29587@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> Date: Mon, 7 May 2012 17:41:28 -0700 Message-ID: From: AP To: Konrad Rzeszutek Wilk Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1582347597455724365==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1582347597455724365== Content-Type: multipart/alternative; boundary=20cf306f7414aed87e04bf7ba5ca --20cf306f7414aed87e04bf7ba5ca Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < konrad.wilk@oracle.com> wrote: > > > > No, this is specifically the wrong thing. From what we know so far > > > (i.e. the outcome of the above printing you added) the problem in > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > attempting XSETBV). What your patch efectively does is take away > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > That allowed the system to boot successfully though I did see the > > > > following message: > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > 00002660 > > > > > > ... which is what this message is telling you. > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > helpful in pointing at where the problem might be. > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > xsave=1. > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > added, > > > to find out why the CR4 write supposedly happening immediately > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > Where did you see that code? Looking at the Linus's tree this is what I > see > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > So who added that code? I am not seeing it in v3.0 either? This is in the Ubuntu 11.10 kernel: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 After some digging around, it looks like this is an Ubuntu 11.10 only patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Thanks, AP --20cf306f7414aed87e04bf7ba5ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
&= gt; > > No, this is specifically the wrong thing. From what we know s= o far
> > > (i.e. the outcome of the above printing you added) the probl= em in
> > > in the Dom0 kernel (in it never setting CR4.OSXSAVE= prior to
> > > attempting XSETBV). What your patch efectively = does is take away
> > > control from the guest kernels to control the (virtual) CR4 = flag...
> > >
> > > > That allowed the system to= boot successfully though I did see the
> > > > following me= ssage:
> > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042= 660 ->
> > > > 00002660
> > >
> > &g= t; ... which is what this message is telling you.
> > >
> > > > Not sure if the above patch is right fix but I hope it = was at least
> > > > helpful in pointing at where the proble= m might be.
> > > >
> > > > BTW, I see the sa= me invalid op issue with Xen 4.1.2 if I boot with
> > > > xsave=3D1.
> > >
> > > Sure, as= it's a kernel problem. It's the kernel that needs logging
> = > > added,
> > > to find out why the CR4 write supposedly= happening immediately
> > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn'= t actually
> > > happen, or doesn't set the flag. Perhaps s= omething fishy going on
> >
> > xen_write_cr4 explicitly = turns off X86_CR4_OSXSAVE.
>
> Where did you see that code? Looking at the Linus's tree t= his is what I
> see
>
> http://git.kern= el.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3Darch/x86/xen/e= nlighten.c;h=3Da8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=3DHEAD
>
> So who added that code? I am not seeing it in v3.0 either?
=
This is in the Ubuntu 11.10 kernel:

After some digging around, it looks=A0like this is an U= buntu 11.10 only patch:

Thanks,
AP

--20cf306f7414aed87e04bf7ba5ca-- --===============1582347597455724365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1582347597455724365==-- From xen-devel-bounces@lists.xen.org Tue May 08 02:56:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 02: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 ) id 1SRaaN-0000Xz-CY; Tue, 08 May 2012 02:55:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRaaL-0000Xu-FS for xen-devel@lists.xensource.com; Tue, 08 May 2012 02:55:33 +0000 Received: from [85.158.139.83:22065] by server-6.bemta-5.messagelabs.com id F2/5C-13222-42B88AF4; Tue, 08 May 2012 02:55:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336445730!23314772!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21790 invoked from network); 8 May 2012 02:55:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 02:55:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,547,1330905600"; d="scan'208";a="12342335" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 02:55: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, 8 May 2012 03:55:28 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRaaG-0004js-75; Tue, 08 May 2012 02:55:28 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRaaG-00054c-2o; Tue, 08 May 2012 03:55:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 03:55:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12797: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12797 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12797/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12792 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8f1e0cc4a507 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8f1e0cc4a507 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8f1e0cc4a507 + branch=xen-unstable + revision=8f1e0cc4a507 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8f1e0cc4a507 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 7 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 02:56:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 02: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 ) id 1SRaaN-0000Xz-CY; Tue, 08 May 2012 02:55:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRaaL-0000Xu-FS for xen-devel@lists.xensource.com; Tue, 08 May 2012 02:55:33 +0000 Received: from [85.158.139.83:22065] by server-6.bemta-5.messagelabs.com id F2/5C-13222-42B88AF4; Tue, 08 May 2012 02:55:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336445730!23314772!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21790 invoked from network); 8 May 2012 02:55:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 02:55:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,547,1330905600"; d="scan'208";a="12342335" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 02:55: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, 8 May 2012 03:55:28 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRaaG-0004js-75; Tue, 08 May 2012 02:55:28 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRaaG-00054c-2o; Tue, 08 May 2012 03:55:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 03:55:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12797: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12797 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12797/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12792 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8f1e0cc4a507 baseline version: xen 0f53540494f7 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8f1e0cc4a507 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8f1e0cc4a507 + branch=xen-unstable + revision=8f1e0cc4a507 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8f1e0cc4a507 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 7 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 06:23:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 06:23:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRdp2-0001aQ-JH; Tue, 08 May 2012 06:22:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRdp1-0001aL-65 for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:22:55 +0000 Received: from [85.158.143.35:24497] by server-2.bemta-4.messagelabs.com id DE/80-17550-EBBB8AF4; Tue, 08 May 2012 06:22:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336458173!13181727!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11190 invoked from network); 8 May 2012 06:22:53 -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; 8 May 2012 06:22:53 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12343951" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 06:22:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 07:22:52 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRdoy-0005q3-ET; Tue, 08 May 2012 06:22:52 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRdoy-0004v1-8G; Tue, 08 May 2012 07:22:52 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 07:22:52 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12799: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12799 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12799/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12796 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail in 12796 never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 06:23:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 06:23:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRdp2-0001aQ-JH; Tue, 08 May 2012 06:22:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRdp1-0001aL-65 for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:22:55 +0000 Received: from [85.158.143.35:24497] by server-2.bemta-4.messagelabs.com id DE/80-17550-EBBB8AF4; Tue, 08 May 2012 06:22:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336458173!13181727!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11190 invoked from network); 8 May 2012 06:22:53 -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; 8 May 2012 06:22:53 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12343951" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 06:22:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 07:22:52 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRdoy-0005q3-ET; Tue, 08 May 2012 06:22:52 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRdoy-0004v1-8G; Tue, 08 May 2012 07:22:52 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 07:22:52 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12799: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12799 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12799/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12796 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-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-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail in 12796 never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 07:51:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 07: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 ) id 1SRfCO-0002NB-Jb; Tue, 08 May 2012 07:51:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfCN-0002N6-4b for xen-devel@lists.xen.org; Tue, 08 May 2012 07:51:07 +0000 Received: from [85.158.143.35:41477] by server-3.bemta-4.messagelabs.com id 9B/25-05853-A60D8AF4; Tue, 08 May 2012 07:51:06 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336463461!11885437!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26866 invoked from network); 8 May 2012 07:51:02 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 07:51:02 -0000 Received: by eekc4 with SMTP id c4so1235194eek.32 for ; Tue, 08 May 2012 00:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=DGTRGLiE2XICY/vLZxm/VxzcUdPhllxj8V83hZQnhkE=; b=R+SkF8P3sVvgWGeIhW+sjyeyCKVvHozUSPRrz4wUknWQZap6O12wP+4ssn6fLqiXfh Q5bdyyMDLPm6/3M+6QQIZMTtXYiy2as3zNxjPqWpDKxHVDV0Os68wJJ2D6JtR0q5jnZF 3lPwB4gBzqX3Io6/eIBZFkOPWBjCmU623rAKBRyCDxnGYA7YN03M8avIBdG7fKLWwjlb Nlp8GVeiPKoHjEwe9YFlyyVroq2bnkzSWapjxdOmC6CJiv02Wgl3ffUELWqkpAD+1J6i uW6mq1jDoYfp1Z9SdA3W1dkl0PCZ3cRFnKmLl/0Sq7czfYQjjxCAONjGtwTM5ArbaCLi eBAA== Received: by 10.14.97.11 with SMTP id s11mr3198601eef.60.1336463461605; Tue, 08 May 2012 00:51:01 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id n52sm91397494eef.6.2012.05.08.00.50.59 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 00:51:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 08 May 2012 08:50:51 +0100 From: Keir Fraser To: M A Young Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0s70nDwUS0vbgZ1ES46NHyU1nc4w== In-Reply-To: Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 21:52, "M A Young" wrote: > On Mon, 7 May 2012, Keir Fraser wrote: > >> Folks, >> >> I have just tagged first release candidates for 4.0.4 and 4.1.3: >> >> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) >> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) >> >> Please test! > > I am seeing problems building 4.1.3-rc1 on Fedora 17, though it might be > changes in Fedora 17 rather than xen changes that have triggered it. When > trying to compile objects such as scheduler.c in tools/blktap2/drivers I > get the error > /usr/include/features.h:329:3: error: #warning _FORTIFY_SOURCE requested but > disabled [-Werror=cpp] > > On checking that file I see that this is because -Wp,-D_FORTIFY_SOURCE=2 > is requested with -O0 . Fedora 17 decides to warn about this and it > becomes an error as -Werror is specified. > This conflict occurs because of the line > CFLAGS += -Werror -g -O0 > in tools/blktap2/drivers/Makefile > I can of course work around the problem in my build, but I was wondering > if optimization level 0 is still necessary for this code. I think the > only other place -O0 is used now is tools/security/Makefile which I > assume will also trigger the problem. Thanks. The same appears to be true in xen-unstable also. Is the solution to simply remove -O0 from the command line? We can test that out in xen-unstable if so, and backport if it causes no problems. -- Keir > Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 07:51:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 07: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 ) id 1SRfCO-0002NB-Jb; Tue, 08 May 2012 07:51:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfCN-0002N6-4b for xen-devel@lists.xen.org; Tue, 08 May 2012 07:51:07 +0000 Received: from [85.158.143.35:41477] by server-3.bemta-4.messagelabs.com id 9B/25-05853-A60D8AF4; Tue, 08 May 2012 07:51:06 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336463461!11885437!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26866 invoked from network); 8 May 2012 07:51:02 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 07:51:02 -0000 Received: by eekc4 with SMTP id c4so1235194eek.32 for ; Tue, 08 May 2012 00:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=DGTRGLiE2XICY/vLZxm/VxzcUdPhllxj8V83hZQnhkE=; b=R+SkF8P3sVvgWGeIhW+sjyeyCKVvHozUSPRrz4wUknWQZap6O12wP+4ssn6fLqiXfh Q5bdyyMDLPm6/3M+6QQIZMTtXYiy2as3zNxjPqWpDKxHVDV0Os68wJJ2D6JtR0q5jnZF 3lPwB4gBzqX3Io6/eIBZFkOPWBjCmU623rAKBRyCDxnGYA7YN03M8avIBdG7fKLWwjlb Nlp8GVeiPKoHjEwe9YFlyyVroq2bnkzSWapjxdOmC6CJiv02Wgl3ffUELWqkpAD+1J6i uW6mq1jDoYfp1Z9SdA3W1dkl0PCZ3cRFnKmLl/0Sq7czfYQjjxCAONjGtwTM5ArbaCLi eBAA== Received: by 10.14.97.11 with SMTP id s11mr3198601eef.60.1336463461605; Tue, 08 May 2012 00:51:01 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id n52sm91397494eef.6.2012.05.08.00.50.59 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 00:51:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 08 May 2012 08:50:51 +0100 From: Keir Fraser To: M A Young Message-ID: Thread-Topic: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 Thread-Index: Ac0s70nDwUS0vbgZ1ES46NHyU1nc4w== In-Reply-To: Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/2012 21:52, "M A Young" wrote: > On Mon, 7 May 2012, Keir Fraser wrote: > >> Folks, >> >> I have just tagged first release candidates for 4.0.4 and 4.1.3: >> >> http://xenbits.xen.org/staging/xen-4.0-testing.hg (tag 4.0.4-rc1) >> http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) >> >> Please test! > > I am seeing problems building 4.1.3-rc1 on Fedora 17, though it might be > changes in Fedora 17 rather than xen changes that have triggered it. When > trying to compile objects such as scheduler.c in tools/blktap2/drivers I > get the error > /usr/include/features.h:329:3: error: #warning _FORTIFY_SOURCE requested but > disabled [-Werror=cpp] > > On checking that file I see that this is because -Wp,-D_FORTIFY_SOURCE=2 > is requested with -O0 . Fedora 17 decides to warn about this and it > becomes an error as -Werror is specified. > This conflict occurs because of the line > CFLAGS += -Werror -g -O0 > in tools/blktap2/drivers/Makefile > I can of course work around the problem in my build, but I was wondering > if optimization level 0 is still necessary for this code. I think the > only other place -O0 is used now is tools/security/Makefile which I > assume will also trigger the problem. Thanks. The same appears to be true in xen-unstable also. Is the solution to simply remove -O0 from the command line? We can test that out in xen-unstable if so, and backport if it causes no problems. -- Keir > Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:32:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08:32:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq9-00032l-JJ; Tue, 08 May 2012 08:32:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq8-00032e-Rr for xen-devel@lists.xensource.com; Tue, 08 May 2012 08:32:13 +0000 Received: from [85.158.138.51:64458] by server-7.bemta-3.messagelabs.com id BD/BC-03078-C0AD8AF4; Tue, 08 May 2012 08:32:12 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336465930!25880235!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27547 invoked from network); 8 May 2012 08:32: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; 8 May 2012 08:32:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 09:33:29 +0100 Message-Id: <4FA8DB320200007800082312@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 07:37:06 +0100 From: "Jan Beulich" To: "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Andrew Cooper , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 20:29, AP wrote: > On Mon, May 7, 2012 at 1:34 PM, Jan Beulich wrote: >> Seeing the 'z' output might also be helpful, especially to see whether >> any of the IO-APICs' RTEs is an ExtINT one. > > (XEN) number of MP IRQ sources: 15. > (XEN) number of IO-APIC #2 registers: 24. > (XEN) testing the IO APIC....................... > (XEN) IO APIC #2...... > (XEN) .... register #00: 02000000 > (XEN) ....... : physical APIC id: 02 > (XEN) ....... : Delivery Type: 0 > (XEN) ....... : LTS : 0 > (XEN) .... register #01: 00170020 > (XEN) ....... : max redirection entries: 0017 > (XEN) ....... : PRQ implemented: 0 > (XEN) ....... : IO APIC version: 0020 > (XEN) .... IRQ redirection table: > (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > (XEN) 00 000 00 1 0 0 0 0 0 0 00 > (XEN) 01 000 00 0 0 0 0 0 1 1 85 > (XEN) 02 000 00 0 0 0 0 0 1 1 F0 > (XEN) 03 000 00 0 0 0 0 0 1 1 40 > (XEN) 04 000 00 0 0 0 0 0 1 1 48 > (XEN) 05 000 00 0 0 0 0 0 1 1 50 > (XEN) 06 000 00 0 0 0 0 0 1 1 58 > (XEN) 07 000 00 0 0 0 0 0 1 1 60 > (XEN) 08 000 00 0 0 0 0 0 1 1 29 > (XEN) 09 000 00 0 1 0 0 0 1 1 A7 > (XEN) 0a 000 00 0 0 0 0 0 1 1 78 > (XEN) 0b 000 00 0 0 0 0 0 1 1 88 > (XEN) 0c 000 00 0 0 0 0 0 1 1 D4 > (XEN) 0d 000 00 1 0 0 0 0 1 1 98 > (XEN) 0e 000 00 0 0 0 0 0 1 1 A0 > (XEN) 0f 000 00 0 0 0 0 0 1 1 A8 > (XEN) 10 000 00 0 1 0 1 0 1 1 AE > (XEN) 11 000 00 1 1 0 1 0 1 1 C0 > (XEN) 12 000 00 1 1 0 1 0 1 1 C8 > (XEN) 13 000 00 0 1 0 1 0 1 1 F1 > (XEN) 14 000 00 1 1 0 1 0 1 1 61 > (XEN) 15 0CA 0A 1 0 0 0 0 1 2 71 This entry is definitely bogus (delivery mode is SMI, which is not allowed in an IO-APIC RTE), but as it is masked it _shouldn't_ cause any harm. > (XEN) 16 000 00 1 1 0 1 0 1 1 32 > (XEN) 17 000 00 0 1 0 1 0 1 1 AC So we'll need to see the PIC (8259A) masks too. IRQ12 definitely appears to get touched a lot (judging by the vector it uses), so while this shouldn't be the case I would nevertheless consider the possibility of a window where the 8259A interrupt gets temporarily unmasked. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:32:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08:32:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq9-00032l-JJ; Tue, 08 May 2012 08:32:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq8-00032e-Rr for xen-devel@lists.xensource.com; Tue, 08 May 2012 08:32:13 +0000 Received: from [85.158.138.51:64458] by server-7.bemta-3.messagelabs.com id BD/BC-03078-C0AD8AF4; Tue, 08 May 2012 08:32:12 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336465930!25880235!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27547 invoked from network); 8 May 2012 08:32: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; 8 May 2012 08:32:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 09:33:29 +0100 Message-Id: <4FA8DB320200007800082312@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 07:37:06 +0100 From: "Jan Beulich" To: "AP" References: <1329216291.31256.207.camel@zakaz.uk.xensource.com> <1332844592.25560.9.camel@zakaz.uk.xensource.com> <4FA437E7.6040105@citrix.com> <4FA79F9F0200007800081F5F@nat28.tlf.novell.com> <4FA7B6EF.9030403@citrix.com> <4FA7EB80020000780008204B@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" , Ian Campbell , Andrew Cooper , Ian Jackson , Daniel De Graaf Subject: Re: [Xen-devel] [xen-unstable test] 11946: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 07.05.12 at 20:29, AP wrote: > On Mon, May 7, 2012 at 1:34 PM, Jan Beulich wrote: >> Seeing the 'z' output might also be helpful, especially to see whether >> any of the IO-APICs' RTEs is an ExtINT one. > > (XEN) number of MP IRQ sources: 15. > (XEN) number of IO-APIC #2 registers: 24. > (XEN) testing the IO APIC....................... > (XEN) IO APIC #2...... > (XEN) .... register #00: 02000000 > (XEN) ....... : physical APIC id: 02 > (XEN) ....... : Delivery Type: 0 > (XEN) ....... : LTS : 0 > (XEN) .... register #01: 00170020 > (XEN) ....... : max redirection entries: 0017 > (XEN) ....... : PRQ implemented: 0 > (XEN) ....... : IO APIC version: 0020 > (XEN) .... IRQ redirection table: > (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > (XEN) 00 000 00 1 0 0 0 0 0 0 00 > (XEN) 01 000 00 0 0 0 0 0 1 1 85 > (XEN) 02 000 00 0 0 0 0 0 1 1 F0 > (XEN) 03 000 00 0 0 0 0 0 1 1 40 > (XEN) 04 000 00 0 0 0 0 0 1 1 48 > (XEN) 05 000 00 0 0 0 0 0 1 1 50 > (XEN) 06 000 00 0 0 0 0 0 1 1 58 > (XEN) 07 000 00 0 0 0 0 0 1 1 60 > (XEN) 08 000 00 0 0 0 0 0 1 1 29 > (XEN) 09 000 00 0 1 0 0 0 1 1 A7 > (XEN) 0a 000 00 0 0 0 0 0 1 1 78 > (XEN) 0b 000 00 0 0 0 0 0 1 1 88 > (XEN) 0c 000 00 0 0 0 0 0 1 1 D4 > (XEN) 0d 000 00 1 0 0 0 0 1 1 98 > (XEN) 0e 000 00 0 0 0 0 0 1 1 A0 > (XEN) 0f 000 00 0 0 0 0 0 1 1 A8 > (XEN) 10 000 00 0 1 0 1 0 1 1 AE > (XEN) 11 000 00 1 1 0 1 0 1 1 C0 > (XEN) 12 000 00 1 1 0 1 0 1 1 C8 > (XEN) 13 000 00 0 1 0 1 0 1 1 F1 > (XEN) 14 000 00 1 1 0 1 0 1 1 61 > (XEN) 15 0CA 0A 1 0 0 0 0 1 2 71 This entry is definitely bogus (delivery mode is SMI, which is not allowed in an IO-APIC RTE), but as it is masked it _shouldn't_ cause any harm. > (XEN) 16 000 00 1 1 0 1 0 1 1 32 > (XEN) 17 000 00 0 1 0 1 0 1 1 AC So we'll need to see the PIC (8259A) masks too. IRQ12 definitely appears to get touched a lot (judging by the vector it uses), so while this shouldn't be the case I would nevertheless consider the possibility of a window where the 8259A interrupt gets temporarily unmasked. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:32:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08:32:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq7-00032U-80; Tue, 08 May 2012 08:32:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq5-00032P-Gu for xen-devel@lists.xen.org; Tue, 08 May 2012 08:32:09 +0000 Received: from [85.158.138.51:20427] by server-5.bemta-3.messagelabs.com id E0/EF-17113-80AD8AF4; Tue, 08 May 2012 08:32:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336465927!24033037!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23847 invoked from network); 8 May 2012 08:32:08 -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; 8 May 2012 08:32:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 09:33:16 +0100 Message-Id: <4FA8D88F020000780008230F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 07:25:51 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 08.05.12 at 01:57, AP wrote: > On Mon, May 7, 2012 at 7:15 AM, Jan Beulich wrote: >> Sure, as it's a kernel problem. It's the kernel that needs logging added, >> to find out why the CR4 write supposedly happening immediately >> prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually >> happen, or doesn't set the flag. Perhaps something fishy going on > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > static void xen_write_cr4(unsigned long cr4) > { > cr4 &= ~X86_CR4_PGE; > cr4 &= ~X86_CR4_PSE; > cr4 &= ~X86_CR4_OSXSAVE; > > native_write_cr4(cr4); > } That's definitely not the case in _any_ upstream Linux release. Which means that this must be introduced by a distro-specific (and broken) patch. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:32:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08:32:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq7-00032U-80; Tue, 08 May 2012 08:32:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfq5-00032P-Gu for xen-devel@lists.xen.org; Tue, 08 May 2012 08:32:09 +0000 Received: from [85.158.138.51:20427] by server-5.bemta-3.messagelabs.com id E0/EF-17113-80AD8AF4; Tue, 08 May 2012 08:32:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336465927!24033037!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23847 invoked from network); 8 May 2012 08:32:08 -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; 8 May 2012 08:32:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 09:33:16 +0100 Message-Id: <4FA8D88F020000780008230F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 07:25:51 +0100 From: "Jan Beulich" To: "AP" References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , weidong.han@intel.com, Tim.Deegan@citrix.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 08.05.12 at 01:57, AP wrote: > On Mon, May 7, 2012 at 7:15 AM, Jan Beulich wrote: >> Sure, as it's a kernel problem. It's the kernel that needs logging added, >> to find out why the CR4 write supposedly happening immediately >> prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually >> happen, or doesn't set the flag. Perhaps something fishy going on > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > static void xen_write_cr4(unsigned long cr4) > { > cr4 &= ~X86_CR4_PGE; > cr4 &= ~X86_CR4_PSE; > cr4 &= ~X86_CR4_OSXSAVE; > > native_write_cr4(cr4); > } That's definitely not the case in _any_ upstream Linux release. Which means that this must be introduced by a distro-specific (and broken) patch. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:51:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08: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 ) id 1SRg85-0003LQ-AZ; Tue, 08 May 2012 08:50:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRg84-0003LL-99 for xen-devel@lists.xen.org; Tue, 08 May 2012 08:50:44 +0000 Received: from [85.158.138.51:31333] by server-7.bemta-3.messagelabs.com id A6/32-03078-36ED8AF4; Tue, 08 May 2012 08:50:43 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-7.tower-174.messagelabs.com!1336467042!16896118!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18676 invoked from network); 8 May 2012 08:50:42 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 08:50:42 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SRg80-000880-G3; Tue, 08 May 2012 08:50:40 +0000 Date: Tue, 8 May 2012 09:50:40 +0100 From: Tim Deegan To: Christian Limpach Message-ID: <20120508085040.GB56981@ocelot.phlegethon.org> References: <4FA3E156.2020602@citrix.com> <20120508084951.GA56981@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120508084951.GA56981@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: Julien Grall , "Keir \(Xen.org\)" , Ian Pratt , "jean.guyader@gmail.com" , xen-devel@lists.xen.org Subject: Re: [Xen-devel] ioreq pages in vm memory and ioreq demux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 09:49 +0100 on 08 May (1336470591), Tim Deegan wrote: > Ccing xen-devel. Actually this time. > At 11:29 -0700 on 07 May (1336390171), Christian Limpach wrote: > > > The current version of Xen allocates the shared page directly > > > in vm memory with other pages (like XenStore page) called > > > special pages. I just begin to hack Xen, so I used the same > > > technique. If you have another idea I'm interested. > > > > Yes, I think the ioreq pages should be allocated from the xen heap. > > As far as I can tell, they don't need to be guest accessible. Your > > approach is fine, but since we're making the number of pages dynamic, > > now might be a good time to change this. > > > > I was hoping for someone to remember the reason why the pages are > > where they are in the first place, anybody? > > Before my time, but one advantage of it is that the pages are allocated > up front as part of the VM's memory so the balloon code in the toolstack > doesn't need to know about it. That's not a big deal, but if you're > going to change it it would be good to update xl, and at least contact > the XCP devs about it. > > Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 08:51:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 08: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 ) id 1SRg85-0003LQ-AZ; Tue, 08 May 2012 08:50:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRg84-0003LL-99 for xen-devel@lists.xen.org; Tue, 08 May 2012 08:50:44 +0000 Received: from [85.158.138.51:31333] by server-7.bemta-3.messagelabs.com id A6/32-03078-36ED8AF4; Tue, 08 May 2012 08:50:43 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-7.tower-174.messagelabs.com!1336467042!16896118!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18676 invoked from network); 8 May 2012 08:50:42 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 08:50:42 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SRg80-000880-G3; Tue, 08 May 2012 08:50:40 +0000 Date: Tue, 8 May 2012 09:50:40 +0100 From: Tim Deegan To: Christian Limpach Message-ID: <20120508085040.GB56981@ocelot.phlegethon.org> References: <4FA3E156.2020602@citrix.com> <20120508084951.GA56981@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120508084951.GA56981@ocelot.phlegethon.org> User-Agent: Mutt/1.4.2.1i Cc: Julien Grall , "Keir \(Xen.org\)" , Ian Pratt , "jean.guyader@gmail.com" , xen-devel@lists.xen.org Subject: Re: [Xen-devel] ioreq pages in vm memory and ioreq demux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 09:49 +0100 on 08 May (1336470591), Tim Deegan wrote: > Ccing xen-devel. Actually this time. > At 11:29 -0700 on 07 May (1336390171), Christian Limpach wrote: > > > The current version of Xen allocates the shared page directly > > > in vm memory with other pages (like XenStore page) called > > > special pages. I just begin to hack Xen, so I used the same > > > technique. If you have another idea I'm interested. > > > > Yes, I think the ioreq pages should be allocated from the xen heap. > > As far as I can tell, they don't need to be guest accessible. Your > > approach is fine, but since we're making the number of pages dynamic, > > now might be a good time to change this. > > > > I was hoping for someone to remember the reason why the pages are > > where they are in the first place, anybody? > > Before my time, but one advantage of it is that the pages are allocated > up front as part of the VM's memory so the balloon code in the toolstack > doesn't need to know about it. That's not a big deal, but if you're > going to change it it would be good to update xl, and at least contact > the XCP devs about it. > > Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:05:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:05:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgMJ-0003XN-P2; Tue, 08 May 2012 09:05:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgMI-0003XI-BC for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:05:26 +0000 Received: from [85.158.139.83:29702] by server-8.bemta-5.messagelabs.com id 72/8D-26964-5D1E8AF4; Tue, 08 May 2012 09:05:25 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336467922!26551056!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwNjc5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31411 invoked from network); 8 May 2012 09:05:23 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-182.messagelabs.com with SMTP; 8 May 2012 09:05:23 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 08 May 2012 02:05:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="140237899" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 08 May 2012 02:05:21 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 May 2012 02:05:21 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Tue, 8 May 2012 17:05:19 +0800 From: "Hao, Xudong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnCACAk9AP/+QLfw Date: Tue, 8 May 2012 09:05:19 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> In-Reply-To: <20120507135410.GD361@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Monday, May 07, 2012 9:54 PM > To: Hao, Xudong > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > > > > > -----Original Message----- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > > Sent: Friday, May 04, 2012 9:21 PM > > > To: Hao, Xudong > > > Cc: xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is > owned > > > by pciback > > > > > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so > that > > > guest with device assigned can be benefitted. > > > > > > > > Changes from v1: > > > > - put the variable definition at the start of function > > > > - add error log report > > > > > > > > > > Don't you need to disable this when the device is un-assigned from the > guest? > > > > > > > I don't think this need to be disabled when device is un-assigned from guest. > If host want to use device again, the host device driver need re-load, so > whether disabling ltr/obff is up to host device driver. > > What if the driver isn't doing that? Make it clear, here host side do not be considered, host has its own driver. The only thing is to make sure ltr/obff is enabled before assigning guest, so that benefit on power. Since device is owned by pciback again when it un-assigned from guest, we need not disable explicitly. > > > > > > Signed-off-by: Xudong Hao > > > > > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > > > b/drivers/xen/xen-pciback/pci_stub.c > > > > index 097e536..74fbf23 100644 > > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > > > pci_dev *dev) > > > > struct xen_pcibk_dev_data *dev_data; > > > > int err = 0; > > > > > > > > + /* set default value */ > > > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > > > > > Why these values? Is there a way to fetch optimal values? > > > > These values is the max value that the register supported. I've no idea to get > an optimal value, here it just be set max value as default. > > Is the max value defined somewhere? Can it be defined somewhere so that > both KVM adn the Xen patches re-use the same #define? > Since there is not real device with ltr/obff supported now, so we can't determine the platform's maximum supported latency. I think the best way is using the default value 0, so I'd like to remove value setting. (if device is reset, the value still is 0) > > > > > > + > > > > dev_dbg(&dev->dev, "initializing...\n"); > > > > > > > > /* The PCI backend is not intended to be a module (or to work with > > > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > > > pci_dev *dev) > > > > dev_dbg(&dev->dev, "reset device\n"); > > > > xen_pcibk_reset_device(dev); > > > > > > > > + /* Enable LTR and OBFF before do device assignment */ > > > > + /* LTR(Latency tolerance reporting) allows devices to send > > > > + * messages to the root complex indicating their latency tolerance > > > > + * for snooped & unsnooped memory transactions. > > > > + */ > > > > + err = pci_enable_ltr(dev); > > > > + if (err) > > > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > > > + > > > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > > > + if (err) > > > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > > > + > > > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > > > + * improve energy efficiency by giving devices information about > > > > + * when interrupts and other activity will have a reduced power > > > > + * impact. > > > > + */ > > > > + err = pci_enable_obff(dev, type); > > > > + if (err) > > > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > > > + > > > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > > > return 0; > > > > > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xen.org > > > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:05:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:05:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgMJ-0003XN-P2; Tue, 08 May 2012 09:05:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgMI-0003XI-BC for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:05:26 +0000 Received: from [85.158.139.83:29702] by server-8.bemta-5.messagelabs.com id 72/8D-26964-5D1E8AF4; Tue, 08 May 2012 09:05:25 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336467922!26551056!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMwNjc5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31411 invoked from network); 8 May 2012 09:05:23 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-182.messagelabs.com with SMTP; 8 May 2012 09:05:23 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 08 May 2012 02:05:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="140237899" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 08 May 2012 02:05:21 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 May 2012 02:05:21 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Tue, 8 May 2012 17:05:19 +0800 From: "Hao, Xudong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnCACAk9AP/+QLfw Date: Tue, 8 May 2012 09:05:19 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> In-Reply-To: <20120507135410.GD361@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Monday, May 07, 2012 9:54 PM > To: Hao, Xudong > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > > > > > -----Original Message----- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > > Sent: Friday, May 04, 2012 9:21 PM > > > To: Hao, Xudong > > > Cc: xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is > owned > > > by pciback > > > > > > On Fri, May 04, 2012 at 07:49:21AM +0000, Hao, Xudong wrote: > > > > When PCIE device which has LTR/OBFF capabilities is owned by pciback, > > > LTR/OBFF feature may be disabled. This patch re-enable LTR and OBFF, so > that > > > guest with device assigned can be benefitted. > > > > > > > > Changes from v1: > > > > - put the variable definition at the start of function > > > > - add error log report > > > > > > > > > > Don't you need to disable this when the device is un-assigned from the > guest? > > > > > > > I don't think this need to be disabled when device is un-assigned from guest. > If host want to use device again, the host device driver need re-load, so > whether disabling ltr/obff is up to host device driver. > > What if the driver isn't doing that? Make it clear, here host side do not be considered, host has its own driver. The only thing is to make sure ltr/obff is enabled before assigning guest, so that benefit on power. Since device is owned by pciback again when it un-assigned from guest, we need not disable explicitly. > > > > > > Signed-off-by: Xudong Hao > > > > > > > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > > > b/drivers/xen/xen-pciback/pci_stub.c > > > > index 097e536..74fbf23 100644 > > > > --- a/drivers/xen/xen-pciback/pci_stub.c > > > > +++ b/drivers/xen/xen-pciback/pci_stub.c > > > > @@ -313,6 +313,10 @@ static int __devinit pcistub_init_device(struct > > > pci_dev *dev) > > > > struct xen_pcibk_dev_data *dev_data; > > > > int err = 0; > > > > > > > > + /* set default value */ > > > > + unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS; > > > > + int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; > > > > > > Why these values? Is there a way to fetch optimal values? > > > > These values is the max value that the register supported. I've no idea to get > an optimal value, here it just be set max value as default. > > Is the max value defined somewhere? Can it be defined somewhere so that > both KVM adn the Xen patches re-use the same #define? > Since there is not real device with ltr/obff supported now, so we can't determine the platform's maximum supported latency. I think the best way is using the default value 0, so I'd like to remove value setting. (if device is reset, the value still is 0) > > > > > > + > > > > dev_dbg(&dev->dev, "initializing...\n"); > > > > > > > > /* The PCI backend is not intended to be a module (or to work with > > > > @@ -369,6 +373,28 @@ static int __devinit pcistub_init_device(struct > > > pci_dev *dev) > > > > dev_dbg(&dev->dev, "reset device\n"); > > > > xen_pcibk_reset_device(dev); > > > > > > > > + /* Enable LTR and OBFF before do device assignment */ > > > > + /* LTR(Latency tolerance reporting) allows devices to send > > > > + * messages to the root complex indicating their latency tolerance > > > > + * for snooped & unsnooped memory transactions. > > > > + */ > > > > + err = pci_enable_ltr(dev); > > > > + if (err) > > > > + dev_err(&dev->dev, "Counld not enalbe LTR for device!\n"); > > > > + > > > > + err = pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns); > > > > + if (err) > > > > + dev_err(&dev->dev, "Set LTR latency values failed.\n"); > > > > + > > > > + /* OBFF (optimized buffer flush/fill), where supported, can help > > > > + * improve energy efficiency by giving devices information about > > > > + * when interrupts and other activity will have a reduced power > > > > + * impact. > > > > + */ > > > > + err = pci_enable_obff(dev, type); > > > > + if (err) > > > > + dev_err(&dev->dev, "Counld not enalbe OBFF for device!\n"); > > > > + > > > > dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED; > > > > return 0; > > > > > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xen.org > > > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:25:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRgfS-0003l1-0X; Tue, 08 May 2012 09:25:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgfQ-0003kt-Fh for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:25:12 +0000 Received: from [85.158.139.83:47910] by server-9.bemta-5.messagelabs.com id 11/89-09826-776E8AF4; Tue, 08 May 2012 09:25:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336469107!24525253!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29895 invoked from network); 8 May 2012 09:25:08 -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; 8 May 2012 09:25:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12347719" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:25: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, 8 May 2012 10:25:05 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRgfJ-0006vq-ET; Tue, 08 May 2012 09:25:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRgfJ-0002K1-7F; Tue, 08 May 2012 10:25:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 10:25:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12800 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12797 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12797 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail in 12797 never pass version targeted for testing: xen 8f1e0cc4a507 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:25:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRgfS-0003l1-0X; Tue, 08 May 2012 09:25:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgfQ-0003kt-Fh for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:25:12 +0000 Received: from [85.158.139.83:47910] by server-9.bemta-5.messagelabs.com id 11/89-09826-776E8AF4; Tue, 08 May 2012 09:25:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336469107!24525253!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29895 invoked from network); 8 May 2012 09:25:08 -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; 8 May 2012 09:25:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12347719" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:25: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, 8 May 2012 10:25:05 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRgfJ-0006vq-ET; Tue, 08 May 2012 09:25:05 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRgfJ-0002K1-7F; Tue, 08 May 2012 10:25:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 10:25:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12800 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12797 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12797 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail in 12797 never pass version targeted for testing: xen 8f1e0cc4a507 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:35:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:35:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgpG-0003ut-42; Tue, 08 May 2012 09:35:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgpE-0003uo-TG for xen-devel@lists.xen.org; Tue, 08 May 2012 09:35:21 +0000 Received: from [85.158.139.83:29704] by server-12.bemta-5.messagelabs.com id 7B/26-01344-7D8E8AF4; Tue, 08 May 2012 09:35:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336469718!15974814!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4538 invoked from network); 8 May 2012 09:35:19 -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; 8 May 2012 09:35:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:34:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:34:16 +0100 Message-ID: <1336469655.14542.21.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 10:34:15 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Subject: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8PCBXRSBBUkUgSEVSRQpNaWQvTGF0ZSBNYXkgICAgLS0gRmlyc3Qg cmVsZWFzZSBjYW5kaWRhdGUKV2Vla2x5ICAgICAgICAgIC0tIFJDTisxIHVudGlsIGl0IGlzIHJl YWR5CgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBsYW4g YSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUgYXMgdG8gd2h5IG5ldyBpdGVt cyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFsbHkgYXMgYSBibG9ja2VyLCBy YXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpoeXBlcnZpc29yLCBibG9ja2VyczoKICAgICAg KiBQZXJmb3JtYW5jZSByZWdyZXNzaW9uIGR1ZSB0byBjb250ZW50aW9uIG9uIHAybSBsb2NrLiBQ YXRjaGVzCiAgICAgICAgcG9zdGVkLCByZXZpZXdlZCwgdXBkYXRlZCwgdG8gZ28gaW4gc2hvcnRs eSAoVGltLCBBbmRyZXMpIAogCnRvb2xzLCBibG9ja2VyczoKICAgICAgKiBsaWJ4bCBzdGFibGUg QVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgICB3 aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBBc3Bl Y3RzIG9mCiAgICAgICAgdGhpcyBhcmU6CiAgICAgICAgICAgICAgKiBTYWZlIGZvcmsgdnMuIGZk IGhhbmRsaW5nIGhvb2tzLiBJbnZvbHZlcyBBUEkgY2hhbmdlcwogICAgICAgICAgICAgICAgKElh biBKLCBwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAqIGxpYnhsX3dhaXRfZm9yX2ZyZWVf bWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQuCiAgICAgICAgICAgICAgICBJbnRl cmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8KICAgICAgICAgICAgICAgIGxvY2tp bmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVycmVkIHRvCiAgICAgICAg ICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50ZXJmYWNlIGJlaW5n CiAgICAgICAgICAgICAgICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4K ICAgICAgICAgICAgICAqIGxpYnhsXypfcGF0aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwgb25s eSBjb25maWdkaXIgYW5kCiAgICAgICAgICAgICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVz ZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KICAgICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2gg bWF5IG5lZWQgdG8gYmUgYXN5bmM6CiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFp bl9zdXNwZW5kLiBQcm9iYWJseSBuZWVkIHRvIG1vdmUKICAgICAgICAgICAgICAgICAgICAgICAg eGNfZG9tYWluX3NhdmUgaW50byBhIHNlcGFyYXRlIHByb2Nlc3MsIGFzIHBlcgogICAgICAgICAg ICAgICAgICAgICAgICA8MjAzNjYuNDAxODMuNDEwMzg4LjQ0NzYzMEBtYXJpbmVyLnVrLnhlbnNv dXJjZS5jb20+LiBMaWtlbHkgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgeGNfZG9tYWluX3Jlc3Rv cmUgdG9vLiBJJ20gbm90IHN1cmUgaWYgSWFuSiBpcyB3b3JraW5nIChvciBwbGFubmluZyB0byB3 b3JrIG9uKSB0aGlzLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fY3JlYXRl X3tuZXcscmVzdG9yZX0gLS0gSWFuSiBoYXMKICAgICAgICAgICAgICAgICAgICAgICAgcGF0Y2hl cyBhcyBwYXJ0IG9mIGV2ZW50IHNlcmllcy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf ZG9tYWluX2NvcmVfZHVtcC4gQ2FuIHRha2UgYSBkdW1teSBhb19ob3cKICAgICAgICAgICAgICAg ICAgICAgICAgYW5kIHJlbWFpbiBzeW5jaHJvbm91cyBpbnRlcm5hbGx5LiAoSWFuQywgcGF0Y2gK ICAgICAgICAgICAgICAgICAgICAgICAgcG9zdGVkKQogICAgICAgICAgICAgICAgICAgICAgKiBs aWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCiAgICAgICAgICAgICAgICAg ICAgICAgIHJlbW92ZT8pLiBSb2dlciBQYXUgTW9ubsOpIGZpeGVzIGRpc2sgYXMgcGFydCBvZgog ICAgICAgICAgICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5m cmFzdHJ1Y3R1cmUKICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hvdWxkIG1ha2UgdGhl IG90aGVycyB0cml2aWFsLiAoUm9nZXIKICAgICAgICAgICAgICAgICAgICAgICAgaW52ZXN0aWdh dGluZykKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQg YmUgZWFzeSBvbmNlCiAgICAgICAgICAgICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRv bmUsIElhbkogdG8gbG9vayBhdCAob3IKICAgICAgICAgICAgICAgICAgICAgICAgZG9pbmcgc28/ KS4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX2Rpc2tfbG9jYWxfe2F0dGFj aCxkZXRhY2h9LiBCZWNvbWUKICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJuYWwgYXMgcGFy dCBvZiBTdGVmYW5vJ3MgZG9tYWluIDAgZGlzawogICAgICAgICAgICAgICAgICAgICAgICBhdHRh Y2ggc2VyaWVzIChwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf ZGV2aWNlX3BjaV97YWRkLHJlbW92ZX0uIFJvZ2VyCiAgICAgICAgICAgICAgICAgICAgICAgIGlu dmVzdGlnYXRpbmcgYWxvbmcgd2l0aCBvdGhlciBhZGQscmVtb3ZlCiAgICAgICAgICAgICAgICAg ICAgICAgIGZ1bmN0aW9ucy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX3RtZW1f Ki4gQWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAogICAgICAgICAgICAgICAgICAgICAgICB0 aGVyZWZvcmUgbm8gYXN5bmMgbmVlZGVkLiBFeGNlcHRpb24gaXMKICAgICAgICAgICAgICAgICAg ICAgICAgdG1lbV9kZXN0cm95IHdoaWNoIERhbiBNYWdlbmhlaW1lciBzYXlzIGlzCiAgICAgICAg ICAgICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVzdCBiZSByZW1vdmVkLiAoSWFuIEMs IHBhdGNoCiAgICAgICAgICAgICAgICAgICAgICAgIHRvIHJlbW92ZSB0bWVtX2Rlc3Ryb3kgaW5j bHVkZWQsIERPTkUpCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2ZvcmsgLS0gSWFuSidz IGV2ZW50IHNlcmllcyB3aWxsIHJlbW92ZQogICAgICAgICAgICAgICAgICAgICAgICBhbGwgdXNl cnMgb2YgdGhpcy4KICAgICAgKiBbQlVHXSBNYW51YWxseSBiYWxsb29uaW5nIGRvbTAuICB4bCBt ZW0tc2V0IDAgW2Zvb10gZmFpbHMgd2l0aAogICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6 MjU2OTpsaWJ4bF9zZXRfbWVtb3J5X3RhcmdldDogY2Fubm90IGdldAogICAgICAgIG1lbW9yeSBp bmZvIGZyb20gL2xvY2FsL2RvbWFpbi8wL21lbW9yeS9zdGF0aWMtbWF4OiBObyBzdWNoIGZpbGUK ICAgICAgICBvciBkaXJlY3RvcnkiLiBUaGlzIG1pZ2h0IGJlIHN1aXRhYmxlIGZvciBhbiBlbnRo dXNpYXN0aWMKICAgICAgICBvbi1sb29rZXIuIChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5j ZSBvZiBzYWlkIG9ubG9va2VyKQogICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAg ICAgICAgICAgICAqIFtCVUddIGNhbm5vdCBjcmVhdGUgYW4gZW1wdHkgQ0QtUk9NIGRyaXZlciBv biBIVk0gZ3Vlc3QsCiAgICAgICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGlu CiAgICAgICAgICAgICAgICA8NEY5NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0PgogICAgICAgICAg ICAgICogW0JVR10gZG9lcyBub3QgaG9ub3VyIHNjaGVkdWxlciB3ZWlnaHQgcGFyYW1zLCByZXBv cnRlZAogICAgICAgICAgICAgICAgYnkgRGlldGVyIEJsb21zIGluIDwyMDEyMDQyMzE5MzUxOC5H QTE2MTM0QGJsb21zLmRlPiwKICAgICAgICAgICAgICAgIERpZXRlcidzIHBhdGNoIGhhcyBiZWVu IGFjY2VwdGVkLiAoRE9ORSwgSG93ZXZlciBzZWUKICAgICAgICAgICAgICAgIG5leHQgYnVnLi4u KQogICAgICAgICAgICAgICogW0JVR10gU3B1cmlvdXMgQ1BVIHBhcmFtcyBlcnJvciBtZXNzYWdl IHdoZW4gc3RhcnRpbmcgYQogICAgICAgICAgICAgICAgZG9tYWluLCBlLmcuICJDcHUgd2VpZ2h0 IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZQogICAgICAgICAgICAgICAgd2l0aGluIHJh bmdlIGZyb20gMSB0byA2NTUzNSIuIFRoaXMgaXMgYW4gaXNzdWUgd2l0aAogICAgICAgICAgICAg ICAgRGlldGVyIEJsb21zJyBwYXRjaCB0byBob25vdXIgc2NoZWR1bGVyIHBhcmFtcy4KICAgICAg ICAgICAgICAqIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkgdHJ5IHRvIHNlbGVjdCBhIChzZXQgb2Yp ICBub2RlKHMpCiAgICAgICAgICAgICAgICBvbiB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGlu IGl0cyB2Y3B1cyB0aGVyZS4gKERhcmlvCiAgICAgICAgICAgICAgICBGYWdnaW9saSkKICAgICAg KiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFk eSBpbgogICAgICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9u IGFyb3VuZCAtcmMxIHRvCiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAq IHhsIHRvIHJlZnVzZSB0byBydW4gaWYgeGVuZCBpcyBydW5uaW5nLCBSb2dlciBQYXUgTW9ubsOp IChwYXRjaAogICAgICAgIHBvc3RlZCkKICAgICAgKiBEb21haW4gMCBibG9jayBhdHRhY2ggJiBn ZW5lcmFsIGhvdHBsdWcgd2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCiAgICAgICAgKG5lZWQgdG8g c3RhcnQgcWVtdSBhcyBuZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCiAgICAgICAg cG9zdGVkKQogICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZSAoRE9ORSkKICAgICAg ICAgICAgICAqIHFlbXUteGVuLXRyYWRpdGlvbmFsIGFuZCB1cHN0cmVhbSBxZW11LXhlbiBwZXJm b3JtYW5jZQogICAgICAgICAgICAgICAgaGFzIGJlZW4gaW1wcm92ZWQgYW5kIGlzIG5vdyBzYXRp c2ZhY3RvcnkuIChIZW5jZSB0aGlzCiAgICAgICAgICAgICAgICB3aG9sZSBpdGVtIGlzIERPTkUp CiAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYgYSBrZXJuZWwg bW9kdWxlIGlzCiAgICAgICAgICAgICAgICBhdmFpbGFibGUgKGUuZy4gb2xkZXIgZG9tMCBrZXJu ZWwgb3IgREtNUyBwcm92aWRlZAogICAgICAgICAgICAgICAga2VybmVsIG1vZHVsZSkgYW5kIHdp bGwgZmFsbGJhY2sgdG8gcWVtdSBxZGlzayBpZiBubwogICAgICAgICAgICAgICAgYmxrdGFwMiBp cyBhdmFpbGFibGUuCiAgICAgICAgICAgICAgKiBUaGVyZSB3aWxsIGJlIG5vIHVzZXJzcGFjZSAi YmxrdGFwMyIgZm9yIFhlbiA0LjIKICAgICAgKiBJbXByb3ZlZCBIb3RwbHVnIHNjcmlwdCBzdXBw b3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCiAgICAgICAgcG9zdGVkKQogICAgICAqIEJs b2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9n ZXIKICAgICAgICBQYXUgTW9ubsOpKQoKaHlwZXJ2aXNvciwgbmljZSB0byBoYXZlOgogICAgICAq IFBvRCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXApCgp0b29scywgbmlj ZSB0byBoYXZlOgogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgogICAgICAg ICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50aG9ueSBQ ZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAgKiBVcHN0 cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAgICAgICAg ICAgICAgIFN0YWJlbGxpbmksIHFlbXUgcGF0Y2hlcyBhcHBsaWVkLCB3YWl0aW5nIGZvciBsaWJ4 bCBldGMKICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkgcmVwb3N0 ZWQpCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNoZWNrcG9p bnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCB3YWl0aW5nIG9uIGxpYnhsIHNpZGUg b2YgcWVtdSB1cHN0cmVhbSBzYXZlL3Jlc3RvcmUpCiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3 aXRoIHhtOgogICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3Zp ZXdlciAodm5jdmlld2VyPTEgb3IKICAgICAgICAgICAgICAgIG90aGVyd2lzZSkgKEdvbmNhbG8g R29tZXMsIG5ldyB2ZXJzaW9uIG9mIHBhdGNoIHBvc3RlZAogICAgICAgICAgICAgICAgcmVjZW50 bHkpCiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0 aGlldSBHYWduw6ksIGFsbCBub3cKICAgICAgICAgICAgICAgIGFwcGxpZWQsIERPTkUpCgpbMF0g aHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cw MDg4My5odG1sCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue May 08 09:35:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:35:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgpG-0003ut-42; Tue, 08 May 2012 09:35:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgpE-0003uo-TG for xen-devel@lists.xen.org; Tue, 08 May 2012 09:35:21 +0000 Received: from [85.158.139.83:29704] by server-12.bemta-5.messagelabs.com id 7B/26-01344-7D8E8AF4; Tue, 08 May 2012 09:35:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336469718!15974814!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4538 invoked from network); 8 May 2012 09:35:19 -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; 8 May 2012 09:35:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:34:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:34:16 +0100 Message-ID: <1336469655.14542.21.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 10:34:15 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Subject: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRt bC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDc5My5odG1sCgpUaGUgdGltZSBsaW5lIGlzIGFzIGZv bGxvd3M6CgoxOSBNYXJjaCAgICAgICAgLS0gVE9ETyBsaXN0IGxvY2tlZCBkb3duCjIgQXByaWwg ICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8PCBXRSBBUkUgSEVSRQpNaWQvTGF0ZSBNYXkgICAgLS0gRmlyc3Qg cmVsZWFzZSBjYW5kaWRhdGUKV2Vla2x5ICAgICAgICAgIC0tIFJDTisxIHVudGlsIGl0IGlzIHJl YWR5CgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4gUGVyIHRoZSByZWxlYXNlIHBsYW4g YSBzdHJvbmcgY2FzZSB3aWxsCm5vdyBoYXZlIHRvIGJlIG1hZGUgYXMgdG8gd2h5IG5ldyBpdGVt cyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGxpc3QsCmVzcGVjaWFsbHkgYXMgYSBibG9ja2VyLCBy YXRoZXIgdGhhbiBkZWZlcnJlZCB0byA0LjMuCgpoeXBlcnZpc29yLCBibG9ja2VyczoKICAgICAg KiBQZXJmb3JtYW5jZSByZWdyZXNzaW9uIGR1ZSB0byBjb250ZW50aW9uIG9uIHAybSBsb2NrLiBQ YXRjaGVzCiAgICAgICAgcG9zdGVkLCByZXZpZXdlZCwgdXBkYXRlZCwgdG8gZ28gaW4gc2hvcnRs eSAoVGltLCBBbmRyZXMpIAogCnRvb2xzLCBibG9ja2VyczoKICAgICAgKiBsaWJ4bCBzdGFibGUg QVBJIC0tIHdlIHdvdWxkIGxpa2UgNC4yIHRvIGRlZmluZSBhIHN0YWJsZSBBUEkKICAgICAgICB3 aGljaCBkb3duc3RyZWFtJ3MgY2FuIHN0YXJ0IHRvIHJlbHkgb24gbm90IGNoYW5naW5nLiBBc3Bl Y3RzIG9mCiAgICAgICAgdGhpcyBhcmU6CiAgICAgICAgICAgICAgKiBTYWZlIGZvcmsgdnMuIGZk IGhhbmRsaW5nIGhvb2tzLiBJbnZvbHZlcyBBUEkgY2hhbmdlcwogICAgICAgICAgICAgICAgKElh biBKLCBwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAqIGxpYnhsX3dhaXRfZm9yX2ZyZWVf bWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQuCiAgICAgICAgICAgICAgICBJbnRl cmZhY2UgbmVlZHMgYW4gb3ZlcmhhdWwsIHJlbGF0ZWQgdG8KICAgICAgICAgICAgICAgIGxvY2tp bmcvc2VyaWFsaXphdGlvbiBvdmVyIGRvbWFpbiBjcmVhdGUgKGRlZmVycmVkIHRvCiAgICAgICAg ICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRoaXMgaW50ZXJmYWNlIGJlaW5n CiAgICAgICAgICAgICAgICBzdWJzdGFuZGFyZCBidXQgb3RoZXJ3aXNlIGRlZmVyIHRvIDQuMy4K ICAgICAgICAgICAgICAqIGxpYnhsXypfcGF0aC4gTWFqb3JpdHkgbWFkZSBpbnRlcm5hbCwgb25s eSBjb25maWdkaXIgYW5kCiAgICAgICAgICAgICAgICBsb2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVz ZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KICAgICAgICAgICAgICAqIEludGVyZmFjZXMgd2hpY2gg bWF5IG5lZWQgdG8gYmUgYXN5bmM6CiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RvbWFp bl9zdXNwZW5kLiBQcm9iYWJseSBuZWVkIHRvIG1vdmUKICAgICAgICAgICAgICAgICAgICAgICAg eGNfZG9tYWluX3NhdmUgaW50byBhIHNlcGFyYXRlIHByb2Nlc3MsIGFzIHBlcgogICAgICAgICAg ICAgICAgICAgICAgICA8MjAzNjYuNDAxODMuNDEwMzg4LjQ0NzYzMEBtYXJpbmVyLnVrLnhlbnNv dXJjZS5jb20+LiBMaWtlbHkgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgeGNfZG9tYWluX3Jlc3Rv cmUgdG9vLiBJJ20gbm90IHN1cmUgaWYgSWFuSiBpcyB3b3JraW5nIChvciBwbGFubmluZyB0byB3 b3JrIG9uKSB0aGlzLgogICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fY3JlYXRl X3tuZXcscmVzdG9yZX0gLS0gSWFuSiBoYXMKICAgICAgICAgICAgICAgICAgICAgICAgcGF0Y2hl cyBhcyBwYXJ0IG9mIGV2ZW50IHNlcmllcy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf ZG9tYWluX2NvcmVfZHVtcC4gQ2FuIHRha2UgYSBkdW1teSBhb19ob3cKICAgICAgICAgICAgICAg ICAgICAgICAgYW5kIHJlbWFpbiBzeW5jaHJvbm91cyBpbnRlcm5hbGx5LiAoSWFuQywgcGF0Y2gK ICAgICAgICAgICAgICAgICAgICAgICAgcG9zdGVkKQogICAgICAgICAgICAgICAgICAgICAgKiBs aWJ4bF9kZXZpY2Vfe2Rpc2ssbmljLHZrYixhZGR9X2FkZCAoYW5kCiAgICAgICAgICAgICAgICAg ICAgICAgIHJlbW92ZT8pLiBSb2dlciBQYXUgTW9ubsOpIGZpeGVzIGRpc2sgYXMgcGFydCBvZgog ICAgICAgICAgICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5m cmFzdHJ1Y3R1cmUKICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggc2hvdWxkIG1ha2UgdGhl IG90aGVycyB0cml2aWFsLiAoUm9nZXIKICAgICAgICAgICAgICAgICAgICAgICAgaW52ZXN0aWdh dGluZykKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQg YmUgZWFzeSBvbmNlCiAgICAgICAgICAgICAgICAgICAgICAgIGRpc2tfe2FkZCxyZW1vdmV9IGRv bmUsIElhbkogdG8gbG9vayBhdCAob3IKICAgICAgICAgICAgICAgICAgICAgICAgZG9pbmcgc28/ KS4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX2Rpc2tfbG9jYWxfe2F0dGFj aCxkZXRhY2h9LiBCZWNvbWUKICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJuYWwgYXMgcGFy dCBvZiBTdGVmYW5vJ3MgZG9tYWluIDAgZGlzawogICAgICAgICAgICAgICAgICAgICAgICBhdHRh Y2ggc2VyaWVzIChwYXRjaGVzIHBvc3RlZCkKICAgICAgICAgICAgICAgICAgICAgICogbGlieGxf ZGV2aWNlX3BjaV97YWRkLHJlbW92ZX0uIFJvZ2VyCiAgICAgICAgICAgICAgICAgICAgICAgIGlu dmVzdGlnYXRpbmcgYWxvbmcgd2l0aCBvdGhlciBhZGQscmVtb3ZlCiAgICAgICAgICAgICAgICAg ICAgICAgIGZ1bmN0aW9ucy4KICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfeGVuX3RtZW1f Ki4gQWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAogICAgICAgICAgICAgICAgICAgICAgICB0 aGVyZWZvcmUgbm8gYXN5bmMgbmVlZGVkLiBFeGNlcHRpb24gaXMKICAgICAgICAgICAgICAgICAg ICAgICAgdG1lbV9kZXN0cm95IHdoaWNoIERhbiBNYWdlbmhlaW1lciBzYXlzIGlzCiAgICAgICAg ICAgICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVzdCBiZSByZW1vdmVkLiAoSWFuIEMs IHBhdGNoCiAgICAgICAgICAgICAgICAgICAgICAgIHRvIHJlbW92ZSB0bWVtX2Rlc3Ryb3kgaW5j bHVkZWQsIERPTkUpCiAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2ZvcmsgLS0gSWFuSidz IGV2ZW50IHNlcmllcyB3aWxsIHJlbW92ZQogICAgICAgICAgICAgICAgICAgICAgICBhbGwgdXNl cnMgb2YgdGhpcy4KICAgICAgKiBbQlVHXSBNYW51YWxseSBiYWxsb29uaW5nIGRvbTAuICB4bCBt ZW0tc2V0IDAgW2Zvb10gZmFpbHMgd2l0aAogICAgICAgICJsaWJ4bDogZXJyb3I6IGxpYnhsLmM6 MjU2OTpsaWJ4bF9zZXRfbWVtb3J5X3RhcmdldDogY2Fubm90IGdldAogICAgICAgIG1lbW9yeSBp bmZvIGZyb20gL2xvY2FsL2RvbWFpbi8wL21lbW9yeS9zdGF0aWMtbWF4OiBObyBzdWNoIGZpbGUK ICAgICAgICBvciBkaXJlY3RvcnkiLiBUaGlzIG1pZ2h0IGJlIHN1aXRhYmxlIGZvciBhbiBlbnRo dXNpYXN0aWMKICAgICAgICBvbi1sb29rZXIuIChHZW9yZ2UgRHVubGFwLCBpbiB0aGUgYWJzZW5j ZSBvZiBzYWlkIG9ubG9va2VyKQogICAgICAqIHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKICAg ICAgICAgICAgICAqIFtCVUddIGNhbm5vdCBjcmVhdGUgYW4gZW1wdHkgQ0QtUk9NIGRyaXZlciBv biBIVk0gZ3Vlc3QsCiAgICAgICAgICAgICAgICByZXBvcnRlZCBieSBGYWJpbyBGYW50b25pIGlu CiAgICAgICAgICAgICAgICA8NEY5NjcyREQuMjA4MDkwMkB0aXNjYWxpLml0PgogICAgICAgICAg ICAgICogW0JVR10gZG9lcyBub3QgaG9ub3VyIHNjaGVkdWxlciB3ZWlnaHQgcGFyYW1zLCByZXBv cnRlZAogICAgICAgICAgICAgICAgYnkgRGlldGVyIEJsb21zIGluIDwyMDEyMDQyMzE5MzUxOC5H QTE2MTM0QGJsb21zLmRlPiwKICAgICAgICAgICAgICAgIERpZXRlcidzIHBhdGNoIGhhcyBiZWVu IGFjY2VwdGVkLiAoRE9ORSwgSG93ZXZlciBzZWUKICAgICAgICAgICAgICAgIG5leHQgYnVnLi4u KQogICAgICAgICAgICAgICogW0JVR10gU3B1cmlvdXMgQ1BVIHBhcmFtcyBlcnJvciBtZXNzYWdl IHdoZW4gc3RhcnRpbmcgYQogICAgICAgICAgICAgICAgZG9tYWluLCBlLmcuICJDcHUgd2VpZ2h0 IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZQogICAgICAgICAgICAgICAgd2l0aGluIHJh bmdlIGZyb20gMSB0byA2NTUzNSIuIFRoaXMgaXMgYW4gaXNzdWUgd2l0aAogICAgICAgICAgICAg ICAgRGlldGVyIEJsb21zJyBwYXRjaCB0byBob25vdXIgc2NoZWR1bGVyIHBhcmFtcy4KICAgICAg ICAgICAgICAqIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkgdHJ5IHRvIHNlbGVjdCBhIChzZXQgb2Yp ICBub2RlKHMpCiAgICAgICAgICAgICAgICBvbiB3aGljaCB0byBjcmVhdGUgYSBWTSBhbmQgcGlu IGl0cyB2Y3B1cyB0aGVyZS4gKERhcmlvCiAgICAgICAgICAgICAgICBGYWdnaW9saSkKICAgICAg KiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFk eSBpbgogICAgICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9u IGFyb3VuZCAtcmMxIHRvCiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgogICAgICAq IHhsIHRvIHJlZnVzZSB0byBydW4gaWYgeGVuZCBpcyBydW5uaW5nLCBSb2dlciBQYXUgTW9ubsOp IChwYXRjaAogICAgICAgIHBvc3RlZCkKICAgICAgKiBEb21haW4gMCBibG9jayBhdHRhY2ggJiBn ZW5lcmFsIGhvdHBsdWcgd2hlbiB1c2luZyBxZGlzayBiYWNrZW5kCiAgICAgICAgKG5lZWQgdG8g c3RhcnQgcWVtdSBhcyBuZWNlc3NhcnkgZXRjKSAoU3RlZmFubyBTLCBwYXRjaGVzCiAgICAgICAg cG9zdGVkKQogICAgICAqIGZpbGU6Ly8gYmFja2VuZCBwZXJmb3JtYW5jZSAoRE9ORSkKICAgICAg ICAgICAgICAqIHFlbXUteGVuLXRyYWRpdGlvbmFsIGFuZCB1cHN0cmVhbSBxZW11LXhlbiBwZXJm b3JtYW5jZQogICAgICAgICAgICAgICAgaGFzIGJlZW4gaW1wcm92ZWQgYW5kIGlzIG5vdyBzYXRp c2ZhY3RvcnkuIChIZW5jZSB0aGlzCiAgICAgICAgICAgICAgICB3aG9sZSBpdGVtIGlzIERPTkUp CiAgICAgICAgICAgICAgKiBYZW4gNC4yIHdpbGwgcHJlZmVyIGJsa3RhcDIgaWYgYSBrZXJuZWwg bW9kdWxlIGlzCiAgICAgICAgICAgICAgICBhdmFpbGFibGUgKGUuZy4gb2xkZXIgZG9tMCBrZXJu ZWwgb3IgREtNUyBwcm92aWRlZAogICAgICAgICAgICAgICAga2VybmVsIG1vZHVsZSkgYW5kIHdp bGwgZmFsbGJhY2sgdG8gcWVtdSBxZGlzayBpZiBubwogICAgICAgICAgICAgICAgYmxrdGFwMiBp cyBhdmFpbGFibGUuCiAgICAgICAgICAgICAgKiBUaGVyZSB3aWxsIGJlIG5vIHVzZXJzcGFjZSAi YmxrdGFwMyIgZm9yIFhlbiA0LjIKICAgICAgKiBJbXByb3ZlZCBIb3RwbHVnIHNjcmlwdCBzdXBw b3J0IChSb2dlciBQYXUgTW9ubsOpLCBwYXRjaGVzCiAgICAgICAgcG9zdGVkKQogICAgICAqIEJs b2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9n ZXIKICAgICAgICBQYXUgTW9ubsOpKQoKaHlwZXJ2aXNvciwgbmljZSB0byBoYXZlOgogICAgICAq IFBvRCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMgKEdlb3JnZSBEdW5sYXApCgp0b29scywgbmlj ZSB0byBoYXZlOgogICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgogICAgICAg ICAgICAgICogVXBzdHJlYW0gcWVtdSBQQ0kgcGFzc3Rocm91Z2ggc3VwcG9ydCAoQW50aG9ueSBQ ZXJhcmQsCiAgICAgICAgICAgICAgICBwYXRjaGVzIHNlbnQpCiAgICAgICAgICAgICAgKiBVcHN0 cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KICAgICAgICAg ICAgICAgIFN0YWJlbGxpbmksIHFlbXUgcGF0Y2hlcyBhcHBsaWVkLCB3YWl0aW5nIGZvciBsaWJ4 bCBldGMKICAgICAgICAgICAgICAgIHNpZGUgd2hpY2ggaGFzIGJlZW4gcmVjZW50bHkgcmVwb3N0 ZWQpCiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNoZWNrcG9p bnQsIGJsYWNraG9saW5nKQogICAgICAgIChTaHJpcmFtLCB3YWl0aW5nIG9uIGxpYnhsIHNpZGUg b2YgcWVtdSB1cHN0cmVhbSBzYXZlL3Jlc3RvcmUpCiAgICAgICogeGwgY29tcGF0aWJpbGl0eSB3 aXRoIHhtOgogICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3NwYXduaW5nIHZuY3Zp ZXdlciAodm5jdmlld2VyPTEgb3IKICAgICAgICAgICAgICAgIG90aGVyd2lzZSkgKEdvbmNhbG8g R29tZXMsIG5ldyB2ZXJzaW9uIG9mIHBhdGNoIHBvc3RlZAogICAgICAgICAgICAgICAgcmVjZW50 bHkpCiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0 aGlldSBHYWduw6ksIGFsbCBub3cKICAgICAgICAgICAgICAgIGFwcGxpZWQsIERPTkUpCgpbMF0g aHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cw MDg4My5odG1sCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue May 08 09:37:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRgqk-0003yX-Ja; Tue, 08 May 2012 09:36:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgqj-0003yQ-BS for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:36:53 +0000 Received: from [85.158.143.35:61624] by server-1.bemta-4.messagelabs.com id 91/CF-20925-439E8AF4; Tue, 08 May 2012 09:36:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336469810!10076847!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32149 invoked from network); 8 May 2012 09:36:51 -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; 8 May 2012 09:36:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348065" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:36:21 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:36:21 +0100 Message-ID: <1336469780.14542.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Tue, 8 May 2012 10:36:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] xl.cfg: add missing space to rename-restart X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 19:24 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336155798 -7200 > # Node ID fb4089f411e49a3f60596c6782083a2785e544ea > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > xl.cfg: add missing space to rename-restart > > Signed-off-by: Olaf Hering Acked-by: Ian Campbell > > diff -r 8f556a70ae0b -r fb4089f411e4 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -172,7 +172,7 @@ configuration > > =item B > > -rename the domain which terminated, and thenimmediately create a new > +rename the domain which terminated, and then immediately create a new > domain with the same configuration as the original > > =item B > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:37:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRgqk-0003yX-Ja; Tue, 08 May 2012 09:36:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgqj-0003yQ-BS for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:36:53 +0000 Received: from [85.158.143.35:61624] by server-1.bemta-4.messagelabs.com id 91/CF-20925-439E8AF4; Tue, 08 May 2012 09:36:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336469810!10076847!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32149 invoked from network); 8 May 2012 09:36:51 -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; 8 May 2012 09:36:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348065" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:36:21 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:36:21 +0100 Message-ID: <1336469780.14542.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Tue, 8 May 2012 10:36:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] xl.cfg: add missing space to rename-restart X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-04 at 19:24 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336155798 -7200 > # Node ID fb4089f411e49a3f60596c6782083a2785e544ea > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > xl.cfg: add missing space to rename-restart > > Signed-off-by: Olaf Hering Acked-by: Ian Campbell > > diff -r 8f556a70ae0b -r fb4089f411e4 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -172,7 +172,7 @@ configuration > > =item B > > -rename the domain which terminated, and thenimmediately create a new > +rename the domain which terminated, and then immediately create a new > domain with the same configuration as the original > > =item B > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:42:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgvY-0004BK-Ar; Tue, 08 May 2012 09:41:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgvW-0004BE-Mp for xen-devel@lists.xen.org; Tue, 08 May 2012 09:41:50 +0000 Received: from [193.109.254.147:41054] by server-4.bemta-14.messagelabs.com id E7/1D-11570-E5AE8AF4; Tue, 08 May 2012 09:41:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336470108!8136367!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31192 invoked from network); 8 May 2012 09:41:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 09:41:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 10:41:47 +0100 Message-Id: <4FA906780200007800082364@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 10:41:44 +0100 From: "Jan Beulich" To: "Xudong Hao" , "Konrad Rzeszutek Wilk" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 08.05.12 at 11:05, "Hao, Xudong" wrote: >> -----Original Message----- >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> > > Don't you need to disable this when the device is un-assigned from the >> guest? >> > > >> > >> > I don't think this need to be disabled when device is un-assigned from > guest. >> If host want to use device again, the host device driver need re-load, so >> whether disabling ltr/obff is up to host device driver. >> >> What if the driver isn't doing that? > > Make it clear, here host side do not be considered, host has its own driver. > The only thing is to make sure ltr/obff is enabled before assigning guest, so > that benefit on power. > > Since device is owned by pciback again when it un-assigned from guest, we > need not disable explicitly. As you didn't answer my respective earlier question - _if_ this is a feature needing enabling (and parameter tweaking), I'd imply there are possible incompatibilities (i.e. reasons for not enabling this always), and hence this shouldn't be done universally (and with fixed values for the parameters) _and_ should be properly reset. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:42:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgvY-0004BK-Ar; Tue, 08 May 2012 09:41:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRgvW-0004BE-Mp for xen-devel@lists.xen.org; Tue, 08 May 2012 09:41:50 +0000 Received: from [193.109.254.147:41054] by server-4.bemta-14.messagelabs.com id E7/1D-11570-E5AE8AF4; Tue, 08 May 2012 09:41:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336470108!8136367!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31192 invoked from network); 8 May 2012 09:41:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 09:41:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 08 May 2012 10:41:47 +0100 Message-Id: <4FA906780200007800082364@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 08 May 2012 10:41:44 +0100 From: "Jan Beulich" To: "Xudong Hao" , "Konrad Rzeszutek Wilk" References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 08.05.12 at 11:05, "Hao, Xudong" wrote: >> -----Original Message----- >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> > > Don't you need to disable this when the device is un-assigned from the >> guest? >> > > >> > >> > I don't think this need to be disabled when device is un-assigned from > guest. >> If host want to use device again, the host device driver need re-load, so >> whether disabling ltr/obff is up to host device driver. >> >> What if the driver isn't doing that? > > Make it clear, here host side do not be considered, host has its own driver. > The only thing is to make sure ltr/obff is enabled before assigning guest, so > that benefit on power. > > Since device is owned by pciback again when it un-assigned from guest, we > need not disable explicitly. As you didn't answer my respective earlier question - _if_ this is a feature needing enabling (and parameter tweaking), I'd imply there are possible incompatibilities (i.e. reasons for not enabling this always), and hence this shouldn't be done universally (and with fixed values for the parameters) _and_ should be properly reset. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:51:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRh4n-0004xo-AN; Tue, 08 May 2012 09:51:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRh4l-0004xV-T0 for xen-devel@lists.xen.org; Tue, 08 May 2012 09:51:24 +0000 Received: from [85.158.143.35:2678] by server-1.bemta-4.messagelabs.com id F6/89-20925-B9CE8AF4; Tue, 08 May 2012 09:51:23 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336470679!11283193!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24814 invoked from network); 8 May 2012 09:51:21 -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; 8 May 2012 09:51:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330923600"; d="scan'208";a="24969013" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 05:51:18 -0400 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, 8 May 2012 05:51:18 -0400 Message-ID: <4FA8EC95.8020508@citrix.com> Date: Tue, 8 May 2012 10:51:17 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Jan Beulich , Keir Fraser X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------000708070408040800030402" Subject: [Xen-devel] x86_64: fix naming of rflags in elf regset structure X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------000708070408040800030402 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is a trivial, non-functional, change so should be considered for 4.2, and backported to 4.1 and 4.0 release candidates. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------000708070408040800030402 Content-Type: text/x-patch; name="x86-elf-rflags-name.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86-elf-rflags-name.patch" # HG changeset patch # Parent 8f1e0cc4a507a52a49a2eb7832a57ecc7e032dce x86_64: fix naming of rflags in elf regset structure 'pushfq' pushes rflags, not eflags. Fix up naming of the structure. No functional change. Signed-off-by: Andrew Cooper diff -r 8f1e0cc4a507 xen/include/asm-x86/x86_64/elf.h --- a/xen/include/asm-x86/x86_64/elf.h +++ b/xen/include/asm-x86/x86_64/elf.h @@ -20,7 +20,7 @@ typedef struct { unsigned long orig_rax; unsigned long rip; unsigned long cs; - unsigned long eflags; + unsigned long rflags; unsigned long rsp; unsigned long ss; unsigned long thread_fs; @@ -54,7 +54,7 @@ static inline void elf_core_save_regs(EL /* orig_rax not filled in for now */ core_regs->rip = (unsigned long)elf_core_save_regs; asm volatile("movl %%cs, %%eax;" :"=a"(core_regs->cs)); - asm volatile("pushfq; popq %0" :"=m"(core_regs->eflags)); + asm volatile("pushfq; popq %0" :"=m"(core_regs->rflags)); asm volatile("movq %%rsp,%0" : "=m"(core_regs->rsp)); asm volatile("movl %%ss, %%eax;" :"=a"(core_regs->ss)); /* thread_fs not filled in for now */ --------------000708070408040800030402 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000708070408040800030402-- From xen-devel-bounces@lists.xen.org Tue May 08 09:51:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09: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 ) id 1SRh4n-0004xo-AN; Tue, 08 May 2012 09:51:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRh4l-0004xV-T0 for xen-devel@lists.xen.org; Tue, 08 May 2012 09:51:24 +0000 Received: from [85.158.143.35:2678] by server-1.bemta-4.messagelabs.com id F6/89-20925-B9CE8AF4; Tue, 08 May 2012 09:51:23 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336470679!11283193!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24814 invoked from network); 8 May 2012 09:51:21 -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; 8 May 2012 09:51:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330923600"; d="scan'208";a="24969013" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 05:51:18 -0400 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, 8 May 2012 05:51:18 -0400 Message-ID: <4FA8EC95.8020508@citrix.com> Date: Tue, 8 May 2012 10:51:17 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Jan Beulich , Keir Fraser X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------000708070408040800030402" Subject: [Xen-devel] x86_64: fix naming of rflags in elf regset structure X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------000708070408040800030402 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is a trivial, non-functional, change so should be considered for 4.2, and backported to 4.1 and 4.0 release candidates. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------000708070408040800030402 Content-Type: text/x-patch; name="x86-elf-rflags-name.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86-elf-rflags-name.patch" # HG changeset patch # Parent 8f1e0cc4a507a52a49a2eb7832a57ecc7e032dce x86_64: fix naming of rflags in elf regset structure 'pushfq' pushes rflags, not eflags. Fix up naming of the structure. No functional change. Signed-off-by: Andrew Cooper diff -r 8f1e0cc4a507 xen/include/asm-x86/x86_64/elf.h --- a/xen/include/asm-x86/x86_64/elf.h +++ b/xen/include/asm-x86/x86_64/elf.h @@ -20,7 +20,7 @@ typedef struct { unsigned long orig_rax; unsigned long rip; unsigned long cs; - unsigned long eflags; + unsigned long rflags; unsigned long rsp; unsigned long ss; unsigned long thread_fs; @@ -54,7 +54,7 @@ static inline void elf_core_save_regs(EL /* orig_rax not filled in for now */ core_regs->rip = (unsigned long)elf_core_save_regs; asm volatile("movl %%cs, %%eax;" :"=a"(core_regs->cs)); - asm volatile("pushfq; popq %0" :"=m"(core_regs->eflags)); + asm volatile("pushfq; popq %0" :"=m"(core_regs->rflags)); asm volatile("movq %%rsp,%0" : "=m"(core_regs->rsp)); asm volatile("movl %%ss, %%eax;" :"=a"(core_regs->ss)); /* thread_fs not filled in for now */ --------------000708070408040800030402 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000708070408040800030402-- From xen-devel-bounces@lists.xen.org Tue May 08 09:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhBU-0005Mc-8F; Tue, 08 May 2012 09:58:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhBS-0005MW-G1 for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:58:18 +0000 Received: from [85.158.143.99:63811] by server-1.bemta-4.messagelabs.com id D5/E5-20925-93EE8AF4; Tue, 08 May 2012 09:58:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336471096!17336821!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5607 invoked from network); 8 May 2012 09:58:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 09:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348795" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:58:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:58:15 +0100 Message-ID: <1336471094.14542.35.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 10:58:14 +0100 In-Reply-To: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> References: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes > > diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 > +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 > @@ -120,6 +120,14 @@ Use the given configuration file. > > Leave the domain paused after it is created. > > +=item B<-V>, B<--vncviewer> > + > +Attach to domain's VNC server, forking a vncviewer process. > + > +=item B<-A>, B<--vncviewer-autopass> > + > +Pass VNC password to vncviewer via stdin. > + > =item B<-c> > > Attach console to the domain as soon as it has started. This is > @@ -433,6 +441,14 @@ See the corresponding option of the I > Enable debug messages. > > +=item B<-V> > + > +Attach to domain's VNC server, forking a vncviewer process. > + > +=item B<-A> > + > +Pass VNC password to vncviewer via stdin. No long form for these two? > + > =back > > =item B [I] I I [I] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 09:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 09:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhBU-0005Mc-8F; Tue, 08 May 2012 09:58:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhBS-0005MW-G1 for xen-devel@lists.xensource.com; Tue, 08 May 2012 09:58:18 +0000 Received: from [85.158.143.99:63811] by server-1.bemta-4.messagelabs.com id D5/E5-20925-93EE8AF4; Tue, 08 May 2012 09:58:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336471096!17336821!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5607 invoked from network); 8 May 2012 09:58:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 09:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348795" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:58:16 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:58:15 +0100 Message-ID: <1336471094.14542.35.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 10:58:14 +0100 In-Reply-To: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> References: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes > > diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 > +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 > @@ -120,6 +120,14 @@ Use the given configuration file. > > Leave the domain paused after it is created. > > +=item B<-V>, B<--vncviewer> > + > +Attach to domain's VNC server, forking a vncviewer process. > + > +=item B<-A>, B<--vncviewer-autopass> > + > +Pass VNC password to vncviewer via stdin. > + > =item B<-c> > > Attach console to the domain as soon as it has started. This is > @@ -433,6 +441,14 @@ See the corresponding option of the I > Enable debug messages. > > +=item B<-V> > + > +Attach to domain's VNC server, forking a vncviewer process. > + > +=item B<-A> > + > +Pass VNC password to vncviewer via stdin. No long form for these two? > + > =back > > =item B [I] I I [I] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:00:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRhDg-0005Z4-UE; Tue, 08 May 2012 10:00:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhDg-0005Yx-5m for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:00:36 +0000 Received: from [85.158.143.35:20159] by server-3.bemta-4.messagelabs.com id 70/BB-05853-3CEE8AF4; Tue, 08 May 2012 10:00:35 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336471227!13214290!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28139 invoked from network); 8 May 2012 10:00: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; 8 May 2012 10:00:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348857" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:00: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, 8 May 2012 11:00:26 +0100 Message-ID: <1336471225.14542.38.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:00:25 +0100 In-Reply-To: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> References: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: add vncviewer boolean options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes > > diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_create.c > --- a/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 > @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( > if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) > b_info->target_memkb = b_info->max_memkb; > > + libxl_defbool_setdefault(&b_info->vncviewer, false); > libxl_defbool_setdefault(&b_info->localtime, false); > > libxl_defbool_setdefault(&b_info->disable_migrate, false); > diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_types.idl > --- a/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 > @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain > ("video_memkb", MemKB), > ("shadow_memkb", MemKB), > ("rtc_timeoffset", uint32), > + ("vncviewer", libxl_defbool), libxl never does anything with this, other that set the default as above. Does this value need to be in the libxl API, could it not be entirely an xl thing, as part of the struct domain_create? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:00:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRhDg-0005Z4-UE; Tue, 08 May 2012 10:00:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhDg-0005Yx-5m for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:00:36 +0000 Received: from [85.158.143.35:20159] by server-3.bemta-4.messagelabs.com id 70/BB-05853-3CEE8AF4; Tue, 08 May 2012 10:00:35 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336471227!13214290!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28139 invoked from network); 8 May 2012 10:00: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; 8 May 2012 10:00:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348857" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:00: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, 8 May 2012 11:00:26 +0100 Message-ID: <1336471225.14542.38.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:00:25 +0100 In-Reply-To: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> References: <497a6061df08d6451f3b.1336353618@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: add vncviewer boolean options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes > > diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_create.c > --- a/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/libxl_create.c Mon May 07 01:10:58 2012 +0000 > @@ -156,6 +156,7 @@ int libxl__domain_build_info_setdefault( > if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) > b_info->target_memkb = b_info->max_memkb; > > + libxl_defbool_setdefault(&b_info->vncviewer, false); > libxl_defbool_setdefault(&b_info->localtime, false); > > libxl_defbool_setdefault(&b_info->disable_migrate, false); > diff -r 79526068a874 -r 497a6061df08 tools/libxl/libxl_types.idl > --- a/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/libxl_types.idl Mon May 07 01:10:58 2012 +0000 > @@ -250,6 +250,7 @@ libxl_domain_build_info = Struct("domain > ("video_memkb", MemKB), > ("shadow_memkb", MemKB), > ("rtc_timeoffset", uint32), > + ("vncviewer", libxl_defbool), libxl never does anything with this, other that set the default as above. Does this value need to be in the libxl API, could it not be entirely an xl thing, as part of the struct domain_create? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:01:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhDz-0005b5-BU; Tue, 08 May 2012 10:00:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhDx-0005af-Ux for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:00:54 +0000 Received: from [85.158.143.99:22696] by server-3.bemta-4.messagelabs.com id 9A/4C-05853-4DEE8AF4; Tue, 08 May 2012 10:00:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336471251!21687199!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25578 invoked from network); 8 May 2012 10:00:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:00:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348871" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:00: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, 8 May 2012 11:00:50 +0100 Message-ID: <1336471249.14542.39.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:00:49 +0100 In-Reply-To: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> References: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes Acked-by: Ian Campbell > > diff -r 497a6061df08 -r 0663afbb57f5 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 > @@ -186,6 +186,14 @@ static void find_domain(const char *p) > common_domname = was_name ? p : libxl_domid_to_name(ctx, domid); > } > > +static int vncviewer(const char *domain_spec, int autopass) > +{ > + find_domain(domain_spec); > + libxl_vncviewer_exec(ctx, domid, autopass); > + fprintf(stderr, "Unable to execute vncviewer\n"); > + return 1; > +} > + > static int acquire_lock(void) > { > int rc; > @@ -2170,14 +2178,6 @@ int main_console(int argc, char **argv) > return 1; > } > > -static int vncviewer(const char *domain_spec, int autopass) > -{ > - find_domain(domain_spec); > - libxl_vncviewer_exec(ctx, domid, autopass); > - fprintf(stderr, "Unable to execute vncviewer\n"); > - return 1; > -} > - > int main_vncviewer(int argc, char **argv) > { > static const struct option long_options[] = { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:01:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhDz-0005b5-BU; Tue, 08 May 2012 10:00:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhDx-0005af-Ux for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:00:54 +0000 Received: from [85.158.143.99:22696] by server-3.bemta-4.messagelabs.com id 9A/4C-05853-4DEE8AF4; Tue, 08 May 2012 10:00:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336471251!21687199!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25578 invoked from network); 8 May 2012 10:00:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:00:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12348871" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:00: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, 8 May 2012 11:00:50 +0100 Message-ID: <1336471249.14542.39.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:00:49 +0100 In-Reply-To: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> References: <0663afbb57f586cea07f.1336353619@dt29.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > Signed-off-by: Goncalo Gomes Acked-by: Ian Campbell > > diff -r 497a6061df08 -r 0663afbb57f5 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 > +++ b/tools/libxl/xl_cmdimpl.c Mon May 07 01:10:58 2012 +0000 > @@ -186,6 +186,14 @@ static void find_domain(const char *p) > common_domname = was_name ? p : libxl_domid_to_name(ctx, domid); > } > > +static int vncviewer(const char *domain_spec, int autopass) > +{ > + find_domain(domain_spec); > + libxl_vncviewer_exec(ctx, domid, autopass); > + fprintf(stderr, "Unable to execute vncviewer\n"); > + return 1; > +} > + > static int acquire_lock(void) > { > int rc; > @@ -2170,14 +2178,6 @@ int main_console(int argc, char **argv) > return 1; > } > > -static int vncviewer(const char *domain_spec, int autopass) > -{ > - find_domain(domain_spec); > - libxl_vncviewer_exec(ctx, domid, autopass); > - fprintf(stderr, "Unable to execute vncviewer\n"); > - return 1; > -} > - > int main_vncviewer(int argc, char **argv) > { > static const struct option long_options[] = { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:04:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhHO-0005v8-0U; Tue, 08 May 2012 10:04:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhHL-0005up-SU for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:04:23 +0000 Received: from [193.109.254.147:56194] by server-11.bemta-14.messagelabs.com id 16/78-05858-7AFE8AF4; Tue, 08 May 2012 10:04:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336471462!5719897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7449 invoked from network); 8 May 2012 10:04:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:04:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12349060" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:04: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, 8 May 2012 11:04:21 +0100 Message-ID: <1336471460.14542.42.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:04:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 5 of 6] xl: Add vncviewer options to create and restore X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > @@ -1734,6 +1739,14 @@ start: > if (!daemonize && !monitor) > goto out; > > + if (vnc || (libxl_defbool_val(d_config.b_info.vncviewer) == 1)) { I think this can be just "if (vnc)", per my previous comment about including this in the libxl API. > + char *domspec = libxl_domid_to_name(ctx, domid); Error out if this fails? But... vncviewer will immediately call "find_domain(domain_spec)" to turn this back into a domid. I think you'd be better to make that function take a domid and pull the find_domain call up into main_vncviewer. > + if (domspec) { > + vncviewer(domspec, vncautopass); > + free(domsec); > + } > + } > + > if (need_daemon) { > char *fullname, *name; > pid_t child1, got_child; Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:04:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhHO-0005v8-0U; Tue, 08 May 2012 10:04:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhHL-0005up-SU for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:04:23 +0000 Received: from [193.109.254.147:56194] by server-11.bemta-14.messagelabs.com id 16/78-05858-7AFE8AF4; Tue, 08 May 2012 10:04:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336471462!5719897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7449 invoked from network); 8 May 2012 10:04:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:04:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12349060" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:04: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, 8 May 2012 11:04:21 +0100 Message-ID: <1336471460.14542.42.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:04:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 5 of 6] xl: Add vncviewer options to create and restore X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > @@ -1734,6 +1739,14 @@ start: > if (!daemonize && !monitor) > goto out; > > + if (vnc || (libxl_defbool_val(d_config.b_info.vncviewer) == 1)) { I think this can be just "if (vnc)", per my previous comment about including this in the libxl API. > + char *domspec = libxl_domid_to_name(ctx, domid); Error out if this fails? But... vncviewer will immediately call "find_domain(domain_spec)" to turn this back into a domid. I think you'd be better to make that function take a domid and pull the find_domain call up into main_vncviewer. > + if (domspec) { > + vncviewer(domspec, vncautopass); > + free(domsec); > + } > + } > + > if (need_daemon) { > char *fullname, *name; > pid_t child1, got_child; Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:17:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:17:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhTj-00067Y-C7; Tue, 08 May 2012 10:17:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhTh-00067T-UQ for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:17:10 +0000 Received: from [85.158.138.51:60298] by server-8.bemta-3.messagelabs.com id 15/2D-24428-4A2F8AF4; Tue, 08 May 2012 10:17:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336472228!24061643!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8612 invoked from network); 8 May 2012 10:17:08 -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; 8 May 2012 10:17:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12349370" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:16:33 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:16:33 +0100 Date: Tue, 8 May 2012 11:13:01 +0100 From: Goncalo Gomes To: Ian Campbell Message-ID: <20120508101301.GA14795@eire.uk.xensource.com> References: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> <1336471094.14542.35.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336471094.14542.35.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 08 May 2012, Ian Campbell wrote: > On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > > Signed-off-by: Goncalo Gomes > > > > diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 > > --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 > > +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 > > @@ -120,6 +120,14 @@ Use the given configuration file. > > > > Leave the domain paused after it is created. > > > > +=item B<-V>, B<--vncviewer> > > + > > +Attach to domain's VNC server, forking a vncviewer process. > > + > > +=item B<-A>, B<--vncviewer-autopass> > > + > > +Pass VNC password to vncviewer via stdin. > > + > > =item B<-c> > > > > Attach console to the domain as soon as it has started. This is > > @@ -433,6 +441,14 @@ See the corresponding option of the I > > > Enable debug messages. > > > > +=item B<-V> > > + > > +Attach to domain's VNC server, forking a vncviewer process. > > + > > +=item B<-A> > > + > > +Pass VNC password to vncviewer via stdin. > > No long form for these two? It was deliberate as (1) `xm restore` doesn't originally have these options and (2) `xl restore` only supports short options. I'm happy to add long options and will include them in my follow up patch. Thanks, Goncalo > > + > > =back > > > > =item B [I] I I [I] > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:17:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:17:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhTj-00067Y-C7; Tue, 08 May 2012 10:17:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhTh-00067T-UQ for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:17:10 +0000 Received: from [85.158.138.51:60298] by server-8.bemta-3.messagelabs.com id 15/2D-24428-4A2F8AF4; Tue, 08 May 2012 10:17:08 +0000 X-Env-Sender: Goncalo.Gomes@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336472228!24061643!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8612 invoked from network); 8 May 2012 10:17:08 -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; 8 May 2012 10:17:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12349370" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:16:33 +0000 Received: from eire.uk.xensource.com (10.80.2.151) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:16:33 +0100 Date: Tue, 8 May 2012 11:13:01 +0100 From: Goncalo Gomes To: Ian Campbell Message-ID: <20120508101301.GA14795@eire.uk.xensource.com> References: <53f124f82cfd5a8760bb.1336353616@dt29.uk.xensource.com> <1336471094.14542.35.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336471094.14542.35.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 6] Update xl man page to include vncviewer options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 08 May 2012, Ian Campbell wrote: > On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > > Signed-off-by: Goncalo Gomes > > > > diff -r 0f53540494f7 -r 53f124f82cfd docs/man/xl.pod.1 > > --- a/docs/man/xl.pod.1 Fri May 04 11:18:48 2012 +0100 > > +++ b/docs/man/xl.pod.1 Mon May 07 01:10:57 2012 +0000 > > @@ -120,6 +120,14 @@ Use the given configuration file. > > > > Leave the domain paused after it is created. > > > > +=item B<-V>, B<--vncviewer> > > + > > +Attach to domain's VNC server, forking a vncviewer process. > > + > > +=item B<-A>, B<--vncviewer-autopass> > > + > > +Pass VNC password to vncviewer via stdin. > > + > > =item B<-c> > > > > Attach console to the domain as soon as it has started. This is > > @@ -433,6 +441,14 @@ See the corresponding option of the I > > > Enable debug messages. > > > > +=item B<-V> > > + > > +Attach to domain's VNC server, forking a vncviewer process. > > + > > +=item B<-A> > > + > > +Pass VNC password to vncviewer via stdin. > > No long form for these two? It was deliberate as (1) `xm restore` doesn't originally have these options and (2) `xl restore` only supports short options. I'm happy to add long options and will include them in my follow up patch. Thanks, Goncalo > > + > > =back > > > > =item B [I] I I [I] > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:31:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:31:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhh8-0006He-Np; Tue, 08 May 2012 10:31:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhh7-0006HZ-HW for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:31:01 +0000 Received: from [85.158.138.51:35076] by server-1.bemta-3.messagelabs.com id 8B/D1-11491-4E5F8AF4; Tue, 08 May 2012 10:31:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336473059!19799963!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8821 invoked from network); 8 May 2012 10:30:59 -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; 8 May 2012 10:30:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350004" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:30: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, 8 May 2012 11:30:59 +0100 Message-ID: <1336473058.14542.45.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:30:58 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 6] Add vncviewer xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > The following series of patches introduce vncviewer compatibility > options to the create and restore commands. I have a look through and it generally looks good, I made some comments on specific patches as I went. One overall comment is that, while we generally prefer that a series is broken down into "one feature per patch", I think you've gone a little too far here. The docs updates, parser updates and the implementation can all reasonably come together in the same patch. The only thing which could be separate is "[...4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain" which it would be useful to have as an early patch in the series (since splitting pure code motion out is always useful). Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:31:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:31:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhh8-0006He-Np; Tue, 08 May 2012 10:31:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhh7-0006HZ-HW for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:31:01 +0000 Received: from [85.158.138.51:35076] by server-1.bemta-3.messagelabs.com id 8B/D1-11491-4E5F8AF4; Tue, 08 May 2012 10:31:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336473059!19799963!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8821 invoked from network); 8 May 2012 10:30:59 -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; 8 May 2012 10:30:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350004" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:30: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, 8 May 2012 11:30:59 +0100 Message-ID: <1336473058.14542.45.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:30:58 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 6] Add vncviewer xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 02:20 +0100, Goncalo Gomes wrote: > The following series of patches introduce vncviewer compatibility > options to the create and restore commands. I have a look through and it generally looks good, I made some comments on specific patches as I went. One overall comment is that, while we generally prefer that a series is broken down into "one feature per patch", I think you've gone a little too far here. The docs updates, parser updates and the implementation can all reasonably come together in the same patch. The only thing which could be separate is "[...4 of 6] xl: move vncviewer function closer to the start of file so it can be seen by create_domain" which it would be useful to have as an early patch in the series (since splitting pure code motion out is always useful). Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:33:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhio-0006Mm-7h; Tue, 08 May 2012 10:32:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhim-0006Ma-37 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:32:44 +0000 Received: from [85.158.143.99:59014] by server-2.bemta-4.messagelabs.com id 1A/5F-17550-B46F8AF4; Tue, 08 May 2012 10:32:43 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336473162!26066838!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17049 invoked from network); 8 May 2012 10:32:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:32:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350053" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:32: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; Tue, 8 May 2012 11:32:42 +0100 Message-ID: <1336473160.14542.47.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:32:40 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George.Dunlap@citrix.com Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with > "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get > memory info from /local/domain/0/memory/static-max: No such file > or directory". This might be suitable for an enthusiastic > on-looker. (George Dunlap, in the absence of said onlooker) I just tried this and it appeared to work, has it been sneakily fixed? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:33:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhio-0006Mm-7h; Tue, 08 May 2012 10:32:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhim-0006Ma-37 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:32:44 +0000 Received: from [85.158.143.99:59014] by server-2.bemta-4.messagelabs.com id 1A/5F-17550-B46F8AF4; Tue, 08 May 2012 10:32:43 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336473162!26066838!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17049 invoked from network); 8 May 2012 10:32:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:32:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350053" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:32: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; Tue, 8 May 2012 11:32:42 +0100 Message-ID: <1336473160.14542.47.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:32:40 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George.Dunlap@citrix.com Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with > "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get > memory info from /local/domain/0/memory/static-max: No such file > or directory". This might be suitable for an enthusiastic > on-looker. (George Dunlap, in the absence of said onlooker) I just tried this and it appeared to work, has it been sneakily fixed? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:41:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhqb-0006bI-5t; Tue, 08 May 2012 10:40:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhqa-0006bD-J0 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:40:48 +0000 Received: from [85.158.143.35:41294] by server-3.bemta-4.messagelabs.com id 2A/E2-05853-F28F8AF4; Tue, 08 May 2012 10:40:47 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336473645!13221110!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26241 invoked from network); 8 May 2012 10:40:47 -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; 8 May 2012 10:40:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330923600"; d="scan'208";a="24970160" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 06:40:45 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 06:40:44 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SRhqW-00008Q-BQ; Tue, 08 May 2012 11:40:44 +0100 Message-ID: <4FA8F7E8.9030204@eu.citrix.com> Date: Tue, 8 May 2012 11:39:36 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473160.14542.47.camel@zakaz.uk.xensource.com> In-Reply-To: <1336473160.14542.47.camel@zakaz.uk.xensource.com> Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 08/05/12 11:32, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: >> * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with >> "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get >> memory info from /local/domain/0/memory/static-max: No such file >> or directory". This might be suitable for an enthusiastic >> on-looker. (George Dunlap, in the absence of said onlooker) > I just tried this and it appeared to work, has it been sneakily fixed? Seems to work for me too -- I do vaguely recall someone (perhaps Goncalo?) volunteering to fix it. At any rate, I'm happy taking it off the list. Thanks for checking. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:41:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhqb-0006bI-5t; Tue, 08 May 2012 10:40:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhqa-0006bD-J0 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:40:48 +0000 Received: from [85.158.143.35:41294] by server-3.bemta-4.messagelabs.com id 2A/E2-05853-F28F8AF4; Tue, 08 May 2012 10:40:47 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336473645!13221110!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26241 invoked from network); 8 May 2012 10:40:47 -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; 8 May 2012 10:40:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330923600"; d="scan'208";a="24970160" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 06:40:45 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 06:40:44 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SRhqW-00008Q-BQ; Tue, 08 May 2012 11:40:44 +0100 Message-ID: <4FA8F7E8.9030204@eu.citrix.com> Date: Tue, 8 May 2012 11:39:36 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473160.14542.47.camel@zakaz.uk.xensource.com> In-Reply-To: <1336473160.14542.47.camel@zakaz.uk.xensource.com> Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 08/05/12 11:32, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: >> * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with >> "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get >> memory info from /local/domain/0/memory/static-max: No such file >> or directory". This might be suitable for an enthusiastic >> on-looker. (George Dunlap, in the absence of said onlooker) > I just tried this and it appeared to work, has it been sneakily fixed? Seems to work for me too -- I do vaguely recall someone (perhaps Goncalo?) volunteering to fix it. At any rate, I'm happy taking it off the list. Thanks for checking. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRht3-0006hn-2b; Tue, 08 May 2012 10:43:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRht1-0006hU-B6 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:43:19 +0000 Received: from [85.158.143.35:54272] by server-1.bemta-4.messagelabs.com id 45/D2-20925-6C8F8AF4; Tue, 08 May 2012 10:43:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336473797!11914765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 561 invoked from network); 8 May 2012 10:43:18 -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; 8 May 2012 10:43:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350372" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:42: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, 8 May 2012 11:42:46 +0100 Message-ID: <1336473765.14542.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:42:45 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTA1LTA4IGF0IDEwOjM0ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9o dG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwNzkzLmh0bWwKPiAKPiBUaGUgdGltZSBsaW5lIGlz IGFzIGZvbGxvd3M6Cj4gCj4gMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93 bgo+IDIgQXByaWwgICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCj4gTWlkL0xhdGUg TWF5ICAgIC0tIEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCj4gV2Vla2x5ICAgICAgICAgIC0tIFJD TisxIHVudGlsIGl0IGlzIHJlYWR5CgpJIHRoaW5rIHRoZSBjcml0aWNhbCBwYXRoIGhlcmUgaXMg dGhlIGxpYnhsIHN0YWJsZSBBUEkgc3R1ZmYuCgpPZiB0aGVzZSBJIHRoaW5rIHRoZSBlbGVtZW50 cyBhcmUgSWFuSidzIHNlcmllcyB0byBoYW5kbGUgZm9yayBldGMgYW5kCnZhcmlvdXMgb3RoZXIg Yml0cywgZm9sbG93ZWQgYnkgUm9nZXIncyBob3RwbHVnIHN0dWZmICh3aGljaCBkZXBlbmRzIG9u CklhbkoncyBzdHVmZikuCgpJJ20gYml0IHVuc3VyZSB3aGljaCBiaXRzIG9mIHRoZSBmb2xsb3dp bmcgbGlzdCBhcmUgZG9uZSwgaW4tcHJvZ3Jlc3MKKHBhcnQgb2YgYSBwb3N0ZWQgb3IgdW5wb3N0 ZWQgc2VyaWVzKSBvciB5ZXQgdG8gYmUgc3RhcnRlZC4gQ291bGQgeW91Cmd1eXMgaGF2ZSBhIHF1 aWNrIGxvb2sgdGhyb3VnaCBhbmQgbGV0IG1lIGtub3c/CgpBbHNvLCBpcyBpdCB3b3J0aCB0cnlp bmcgdG8gZmluZCBzb21lIG90aGVyIGhlYWRzIHRvIHRha2Ugb3ZlciBzb21lIG9mCnRoZSBzbWFs bGVyIHNpZGUsIG5vbi1kZXBlbmRlbnQgaXNzdWVzIHRvIGNsZWFyIHlvdXIgcGF0aCAoSWFuSiBp bgpwYXJ0aWN1bGFyKT8KIAo+IHRvb2xzLCBibG9ja2VyczoKPiAgICAgICAqIGxpYnhsIHN0YWJs ZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+ICAgICAg ICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4g QXNwZWN0cyBvZgo+ICAgICAgICAgdGhpcyBhcmU6Cj4gICAgICAgICAgICAgICAqIFNhZmUgZm9y ayB2cy4gZmQgaGFuZGxpbmcgaG9va3MuIEludm9sdmVzIEFQSSBjaGFuZ2VzCj4gICAgICAgICAg ICAgICAgIChJYW4gSiwgcGF0Y2hlcyBwb3N0ZWQpCj4gICAgICAgICAgICAgICAqIGxpYnhsX3dh aXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQuCj4gICAgICAg ICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwo+ICAgICAg ICAgICAgICAgICBsb2NraW5nL3NlcmlhbGl6YXRpb24gb3ZlciBkb21haW4gY3JlYXRlIChkZWZl cnJlZCB0bwo+ICAgICAgICAgICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRo aXMgaW50ZXJmYWNlIGJlaW5nCj4gICAgICAgICAgICAgICAgIHN1YnN0YW5kYXJkIGJ1dCBvdGhl cndpc2UgZGVmZXIgdG8gNC4zLgo+ICAgICAgICAgICAgICAgKiBsaWJ4bF8qX3BhdGguIE1ham9y aXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGlyIGFuZAo+ICAgICAgICAgICAgICAgICBs b2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVzZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KPiAgICAgICAg ICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPiAgICAgICAg ICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fc3VzcGVuZC4gUHJvYmFibHkgbmVlZCB0byBt b3ZlCj4gICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluX3NhdmUgaW50byBhIHNlcGFy YXRlIHByb2Nlc3MsIGFzIHBlcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIDwyMDM2Ni40MDE4 My40MTAzODguNDQ3NjMwQG1hcmluZXIudWsueGVuc291cmNlLmNvbT4uIExpa2VseSBuZWVkIHRv IGRvIHRoZSBzYW1lIGZvciB4Y19kb21haW5fcmVzdG9yZSB0b28uIEknbSBub3Qgc3VyZSBpZiBJ YW5KIGlzIHdvcmtpbmcgKG9yIHBsYW5uaW5nIHRvIHdvcmsgb24pIHRoaXMuCj4gICAgICAgICAg ICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NyZWF0ZV97bmV3LHJlc3RvcmV9IC0tIElhbkog aGFzCj4gICAgICAgICAgICAgICAgICAgICAgICAgcGF0Y2hlcyBhcyBwYXJ0IG9mIGV2ZW50IHNl cmllcy4KPiAgICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fY29yZV9kdW1wLiBD YW4gdGFrZSBhIGR1bW15IGFvX2hvdwo+ICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCByZW1h aW4gc3luY2hyb25vdXMgaW50ZXJuYWxseS4gKElhbkMsIHBhdGNoCj4gICAgICAgICAgICAgICAg ICAgICAgICAgcG9zdGVkKQo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV97 ZGlzayxuaWMsdmtiLGFkZH1fYWRkIChhbmQKPiAgICAgICAgICAgICAgICAgICAgICAgICByZW1v dmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhlcyBkaXNrIGFzIHBhcnQgb2YKPiAgICAgICAgICAg ICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5mcmFzdHJ1Y3R1 cmUKPiAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBzaG91bGQgbWFrZSB0aGUgb3RoZXJz IHRyaXZpYWwuIChSb2dlcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcp Cj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUg ZWFzeSBvbmNlCj4gICAgICAgICAgICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9u ZSwgSWFuSiB0byBsb29rIGF0IChvcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGRvaW5nIHNv PykuCj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX2Rpc2tfbG9jYWxfe2F0 dGFjaCxkZXRhY2h9LiBCZWNvbWUKPiAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcm5hbCBh cyBwYXJ0IG9mIFN0ZWZhbm8ncyBkb21haW4gMCBkaXNrCj4gICAgICAgICAgICAgICAgICAgICAg ICAgYXR0YWNoIHNlcmllcyAocGF0Y2hlcyBwb3N0ZWQpCj4gICAgICAgICAgICAgICAgICAgICAg ICogbGlieGxfZGV2aWNlX3BjaV97YWRkLHJlbW92ZX0uIFJvZ2VyCj4gICAgICAgICAgICAgICAg ICAgICAgICAgaW52ZXN0aWdhdGluZyBhbG9uZyB3aXRoIG90aGVyIGFkZCxyZW1vdmUKPiAgICAg ICAgICAgICAgICAgICAgICAgICBmdW5jdGlvbnMuCj4gICAgICAgICAgICAgICAgICAgICAgICog bGlieGxfeGVuX3RtZW1fKi4gQWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAo+ICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZXJlZm9yZSBubyBhc3luYyBuZWVkZWQuIEV4Y2VwdGlvbiBpcwo+ ICAgICAgICAgICAgICAgICAgICAgICAgIHRtZW1fZGVzdHJveSB3aGljaCBEYW4gTWFnZW5oZWlt ZXIgc2F5cyBpcwo+ICAgICAgICAgICAgICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVz dCBiZSByZW1vdmVkLiAoSWFuIEMsIHBhdGNoCj4gICAgICAgICAgICAgICAgICAgICAgICAgdG8g cmVtb3ZlIHRtZW1fZGVzdHJveSBpbmNsdWRlZCwgRE9ORSkKPiAgICAgICAgICAgICAgICAgICAg ICAgKiBsaWJ4bF9mb3JrIC0tIElhbkoncyBldmVudCBzZXJpZXMgd2lsbCByZW1vdmUKPiAgICAg ICAgICAgICAgICAgICAgICAgICBhbGwgdXNlcnMgb2YgdGhpcy4KCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 10:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRht3-0006hn-2b; Tue, 08 May 2012 10:43:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRht1-0006hU-B6 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:43:19 +0000 Received: from [85.158.143.35:54272] by server-1.bemta-4.messagelabs.com id 45/D2-20925-6C8F8AF4; Tue, 08 May 2012 10:43:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336473797!11914765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 561 invoked from network); 8 May 2012 10:43:18 -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; 8 May 2012 10:43:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350372" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:42: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, 8 May 2012 11:42:46 +0100 Message-ID: <1336473765.14542.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:42:45 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTA1LTA4IGF0IDEwOjM0ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g UGxhbiBmb3IgYSA0LjIgcmVsZWFzZToKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9o dG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwNzkzLmh0bWwKPiAKPiBUaGUgdGltZSBsaW5lIGlz IGFzIGZvbGxvd3M6Cj4gCj4gMTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93 bgo+IDIgQXByaWwgICAgICAgICAtLSBGZWF0dXJlIEZyZWV6ZQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCj4gTWlkL0xhdGUg TWF5ICAgIC0tIEZpcnN0IHJlbGVhc2UgY2FuZGlkYXRlCj4gV2Vla2x5ICAgICAgICAgIC0tIFJD TisxIHVudGlsIGl0IGlzIHJlYWR5CgpJIHRoaW5rIHRoZSBjcml0aWNhbCBwYXRoIGhlcmUgaXMg dGhlIGxpYnhsIHN0YWJsZSBBUEkgc3R1ZmYuCgpPZiB0aGVzZSBJIHRoaW5rIHRoZSBlbGVtZW50 cyBhcmUgSWFuSidzIHNlcmllcyB0byBoYW5kbGUgZm9yayBldGMgYW5kCnZhcmlvdXMgb3RoZXIg Yml0cywgZm9sbG93ZWQgYnkgUm9nZXIncyBob3RwbHVnIHN0dWZmICh3aGljaCBkZXBlbmRzIG9u CklhbkoncyBzdHVmZikuCgpJJ20gYml0IHVuc3VyZSB3aGljaCBiaXRzIG9mIHRoZSBmb2xsb3dp bmcgbGlzdCBhcmUgZG9uZSwgaW4tcHJvZ3Jlc3MKKHBhcnQgb2YgYSBwb3N0ZWQgb3IgdW5wb3N0 ZWQgc2VyaWVzKSBvciB5ZXQgdG8gYmUgc3RhcnRlZC4gQ291bGQgeW91Cmd1eXMgaGF2ZSBhIHF1 aWNrIGxvb2sgdGhyb3VnaCBhbmQgbGV0IG1lIGtub3c/CgpBbHNvLCBpcyBpdCB3b3J0aCB0cnlp bmcgdG8gZmluZCBzb21lIG90aGVyIGhlYWRzIHRvIHRha2Ugb3ZlciBzb21lIG9mCnRoZSBzbWFs bGVyIHNpZGUsIG5vbi1kZXBlbmRlbnQgaXNzdWVzIHRvIGNsZWFyIHlvdXIgcGF0aCAoSWFuSiBp bgpwYXJ0aWN1bGFyKT8KIAo+IHRvb2xzLCBibG9ja2VyczoKPiAgICAgICAqIGxpYnhsIHN0YWJs ZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+ICAgICAg ICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4g QXNwZWN0cyBvZgo+ICAgICAgICAgdGhpcyBhcmU6Cj4gICAgICAgICAgICAgICAqIFNhZmUgZm9y ayB2cy4gZmQgaGFuZGxpbmcgaG9va3MuIEludm9sdmVzIEFQSSBjaGFuZ2VzCj4gICAgICAgICAg ICAgICAgIChJYW4gSiwgcGF0Y2hlcyBwb3N0ZWQpCj4gICAgICAgICAgICAgICAqIGxpYnhsX3dh aXRfZm9yX2ZyZWVfbWVtb3J5L2xpYnhsX3dhaXRfZm9yX21lbW9yeV90YXJnZXQuCj4gICAgICAg ICAgICAgICAgIEludGVyZmFjZSBuZWVkcyBhbiBvdmVyaGF1bCwgcmVsYXRlZCB0bwo+ICAgICAg ICAgICAgICAgICBsb2NraW5nL3NlcmlhbGl6YXRpb24gb3ZlciBkb21haW4gY3JlYXRlIChkZWZl cnJlZCB0bwo+ICAgICAgICAgICAgICAgICA0LjMpLiBJYW5KIHRvIGFkZCBub3RlIGFib3V0IHRo aXMgaW50ZXJmYWNlIGJlaW5nCj4gICAgICAgICAgICAgICAgIHN1YnN0YW5kYXJkIGJ1dCBvdGhl cndpc2UgZGVmZXIgdG8gNC4zLgo+ICAgICAgICAgICAgICAgKiBsaWJ4bF8qX3BhdGguIE1ham9y aXR5IG1hZGUgaW50ZXJuYWwsIG9ubHkgY29uZmlnZGlyIGFuZAo+ICAgICAgICAgICAgICAgICBs b2NrZGlyIHJlbWFpbiBwdWJsaWMgKHVzZWQgYnkgeGwpLiBHb29kIGVub3VnaD8KPiAgICAgICAg ICAgICAgICogSW50ZXJmYWNlcyB3aGljaCBtYXkgbmVlZCB0byBiZSBhc3luYzoKPiAgICAgICAg ICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fc3VzcGVuZC4gUHJvYmFibHkgbmVlZCB0byBt b3ZlCj4gICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluX3NhdmUgaW50byBhIHNlcGFy YXRlIHByb2Nlc3MsIGFzIHBlcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIDwyMDM2Ni40MDE4 My40MTAzODguNDQ3NjMwQG1hcmluZXIudWsueGVuc291cmNlLmNvbT4uIExpa2VseSBuZWVkIHRv IGRvIHRoZSBzYW1lIGZvciB4Y19kb21haW5fcmVzdG9yZSB0b28uIEknbSBub3Qgc3VyZSBpZiBJ YW5KIGlzIHdvcmtpbmcgKG9yIHBsYW5uaW5nIHRvIHdvcmsgb24pIHRoaXMuCj4gICAgICAgICAg ICAgICAgICAgICAgICogbGlieGxfZG9tYWluX2NyZWF0ZV97bmV3LHJlc3RvcmV9IC0tIElhbkog aGFzCj4gICAgICAgICAgICAgICAgICAgICAgICAgcGF0Y2hlcyBhcyBwYXJ0IG9mIGV2ZW50IHNl cmllcy4KPiAgICAgICAgICAgICAgICAgICAgICAgKiBsaWJ4bF9kb21haW5fY29yZV9kdW1wLiBD YW4gdGFrZSBhIGR1bW15IGFvX2hvdwo+ICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCByZW1h aW4gc3luY2hyb25vdXMgaW50ZXJuYWxseS4gKElhbkMsIHBhdGNoCj4gICAgICAgICAgICAgICAg ICAgICAgICAgcG9zdGVkKQo+ICAgICAgICAgICAgICAgICAgICAgICAqIGxpYnhsX2RldmljZV97 ZGlzayxuaWMsdmtiLGFkZH1fYWRkIChhbmQKPiAgICAgICAgICAgICAgICAgICAgICAgICByZW1v dmU/KS4gUm9nZXIgUGF1IE1vbm7DqSBmaXhlcyBkaXNrIGFzIHBhcnQgb2YKPiAgICAgICAgICAg ICAgICAgICAgICAgICBob3RwbHVnIHNjcmlwdCBzZXJpZXMgYW5kIGFkZHMgaW5mcmFzdHJ1Y3R1 cmUKPiAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBzaG91bGQgbWFrZSB0aGUgb3RoZXJz IHRyaXZpYWwuIChSb2dlcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGludmVzdGlnYXRpbmcp Cj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfY2Ryb21faW5zZXJ0LiBTaG91bGQgYmUg ZWFzeSBvbmNlCj4gICAgICAgICAgICAgICAgICAgICAgICAgZGlza197YWRkLHJlbW92ZX0gZG9u ZSwgSWFuSiB0byBsb29rIGF0IChvcgo+ICAgICAgICAgICAgICAgICAgICAgICAgIGRvaW5nIHNv PykuCj4gICAgICAgICAgICAgICAgICAgICAgICogbGlieGxfZGV2aWNlX2Rpc2tfbG9jYWxfe2F0 dGFjaCxkZXRhY2h9LiBCZWNvbWUKPiAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcm5hbCBh cyBwYXJ0IG9mIFN0ZWZhbm8ncyBkb21haW4gMCBkaXNrCj4gICAgICAgICAgICAgICAgICAgICAg ICAgYXR0YWNoIHNlcmllcyAocGF0Y2hlcyBwb3N0ZWQpCj4gICAgICAgICAgICAgICAgICAgICAg ICogbGlieGxfZGV2aWNlX3BjaV97YWRkLHJlbW92ZX0uIFJvZ2VyCj4gICAgICAgICAgICAgICAg ICAgICAgICAgaW52ZXN0aWdhdGluZyBhbG9uZyB3aXRoIG90aGVyIGFkZCxyZW1vdmUKPiAgICAg ICAgICAgICAgICAgICAgICAgICBmdW5jdGlvbnMuCj4gICAgICAgICAgICAgICAgICAgICAgICog bGlieGxfeGVuX3RtZW1fKi4gQWxsIGZ1bmN0aW9ucyBhcmUgImZhc3QiIGFuZAo+ICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZXJlZm9yZSBubyBhc3luYyBuZWVkZWQuIEV4Y2VwdGlvbiBpcwo+ ICAgICAgICAgICAgICAgICAgICAgICAgIHRtZW1fZGVzdHJveSB3aGljaCBEYW4gTWFnZW5oZWlt ZXIgc2F5cyBpcwo+ICAgICAgICAgICAgICAgICAgICAgICAgIG9ic29sZXRlIGFuZCBjYW4ganVz dCBiZSByZW1vdmVkLiAoSWFuIEMsIHBhdGNoCj4gICAgICAgICAgICAgICAgICAgICAgICAgdG8g cmVtb3ZlIHRtZW1fZGVzdHJveSBpbmNsdWRlZCwgRE9ORSkKPiAgICAgICAgICAgICAgICAgICAg ICAgKiBsaWJ4bF9mb3JrIC0tIElhbkoncyBldmVudCBzZXJpZXMgd2lsbCByZW1vdmUKPiAgICAg ICAgICAgICAgICAgICAgICAgICBhbGwgdXNlcnMgb2YgdGhpcy4KCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 10:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRht2-0006hf-Nt; Tue, 08 May 2012 10:43:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRht1-0006hT-8U for xen-devel@lists.xen.org; Tue, 08 May 2012 10:43:19 +0000 Received: from [85.158.143.35:54270] by server-3.bemta-4.messagelabs.com id 8D/37-05853-6C8F8AF4; Tue, 08 May 2012 10:43:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336473797!11914765!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 567 invoked from network); 8 May 2012 10:43:18 -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; 8 May 2012 10:43:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350380" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:43:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:43:17 +0100 Message-ID: <1336473796.14542.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 8 May 2012 11:43:16 +0100 In-Reply-To: <4FA8F7E8.9030204@eu.citrix.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473160.14542.47.camel@zakaz.uk.xensource.com> <4FA8F7E8.9030204@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 11:39 +0100, George Dunlap wrote: > On 08/05/12 11:32, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > >> * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with > >> "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get > >> memory info from /local/domain/0/memory/static-max: No such file > >> or directory". This might be suitable for an enthusiastic > >> on-looker. (George Dunlap, in the absence of said onlooker) > > I just tried this and it appeared to work, has it been sneakily fixed? > Seems to work for me too -- I do vaguely recall someone (perhaps > Goncalo?) volunteering to fix it. At any rate, I'm happy taking it off > the list. Thanks for checking. Great, I'll mark it DONE next week. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRht2-0006hf-Nt; Tue, 08 May 2012 10:43:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRht1-0006hT-8U for xen-devel@lists.xen.org; Tue, 08 May 2012 10:43:19 +0000 Received: from [85.158.143.35:54270] by server-3.bemta-4.messagelabs.com id 8D/37-05853-6C8F8AF4; Tue, 08 May 2012 10:43:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336473797!11914765!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 567 invoked from network); 8 May 2012 10:43:18 -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; 8 May 2012 10:43:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350380" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:43:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:43:17 +0100 Message-ID: <1336473796.14542.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 8 May 2012 11:43:16 +0100 In-Reply-To: <4FA8F7E8.9030204@eu.citrix.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473160.14542.47.camel@zakaz.uk.xensource.com> <4FA8F7E8.9030204@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 11:39 +0100, George Dunlap wrote: > On 08/05/12 11:32, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > >> * [BUG] Manually ballooning dom0. xl mem-set 0 [foo] fails with > >> "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get > >> memory info from /local/domain/0/memory/static-max: No such file > >> or directory". This might be suitable for an enthusiastic > >> on-looker. (George Dunlap, in the absence of said onlooker) > > I just tried this and it appeared to work, has it been sneakily fixed? > Seems to work for me too -- I do vaguely recall someone (perhaps > Goncalo?) volunteering to fix it. At any rate, I'm happy taking it off > the list. Thanks for checking. Great, I'll mark it DONE next week. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:45:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhvM-0006xT-Px; Tue, 08 May 2012 10:45:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhvL-0006xF-Lv for xen-devel@lists.xen.org; Tue, 08 May 2012 10:45:43 +0000 Received: from [85.158.139.83:38507] by server-12.bemta-5.messagelabs.com id 24/73-01344-459F8AF4; Tue, 08 May 2012 10:45:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336473939!20030892!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21346 invoked from network); 8 May 2012 10:45:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:45:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350448" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:45:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:45:39 +0100 Message-ID: <1336473938.14542.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:45:38 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Dario Faggioli , Dieter Bloms Subject: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > * xl compatibility with xm: > [...] > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter's patch has been accepted. (DONE, However see > next bug...) > * [BUG] Spurious CPU params error message when starting a > domain, e.g. "Cpu weight out of range, valid values are > within range from 1 to 65535". This is an issue with > Dieter Bloms' patch to honour scheduler params. Is anyone looking into this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:45:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhvM-0006xT-Px; Tue, 08 May 2012 10:45:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhvL-0006xF-Lv for xen-devel@lists.xen.org; Tue, 08 May 2012 10:45:43 +0000 Received: from [85.158.139.83:38507] by server-12.bemta-5.messagelabs.com id 24/73-01344-459F8AF4; Tue, 08 May 2012 10:45:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336473939!20030892!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21346 invoked from network); 8 May 2012 10:45:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 10:45:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350448" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:45:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:45:39 +0100 Message-ID: <1336473938.14542.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:45:38 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Dario Faggioli , Dieter Bloms Subject: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > * xl compatibility with xm: > [...] > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter's patch has been accepted. (DONE, However see > next bug...) > * [BUG] Spurious CPU params error message when starting a > domain, e.g. "Cpu weight out of range, valid values are > within range from 1 to 65535". This is an issue with > Dieter Bloms' patch to honour scheduler params. Is anyone looking into this? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:48:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhxS-000795-AZ; Tue, 08 May 2012 10:47:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhxR-00078x-B0 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:47:53 +0000 Received: from [85.158.139.83:41251] by server-2.bemta-5.messagelabs.com id DF/54-17016-8D9F8AF4; Tue, 08 May 2012 10:47:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336474070!19910967!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7444 invoked from network); 8 May 2012 10:47:51 -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; 8 May 2012 10:47:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350511" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:47: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, 8 May 2012 11:47:49 +0100 Message-ID: <1336474068.14542.57.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:47:48 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu Subject: [Xen-devel] Volunteer wanted: xl and empty HVM CD ROM drives (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > [...] * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it> I don't think anyone is currently working on this. Any volunteers? I think this should be a relatively easy thing, suitable for a beginner (e..g someone who is interested in making a start at toolstack hacking.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:48:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRhxS-000795-AZ; Tue, 08 May 2012 10:47:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhxR-00078x-B0 for xen-devel@lists.xen.org; Tue, 08 May 2012 10:47:53 +0000 Received: from [85.158.139.83:41251] by server-2.bemta-5.messagelabs.com id DF/54-17016-8D9F8AF4; Tue, 08 May 2012 10:47:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336474070!19910967!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7444 invoked from network); 8 May 2012 10:47:51 -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; 8 May 2012 10:47:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350511" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:47: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, 8 May 2012 11:47:49 +0100 Message-ID: <1336474068.14542.57.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:47:48 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Fantu Subject: [Xen-devel] Volunteer wanted: xl and empty HVM CD ROM drives (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > [...] * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it> I don't think anyone is currently working on this. Any volunteers? I think this should be a relatively easy thing, suitable for a beginner (e..g someone who is interested in making a start at toolstack hacking.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:52:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRi1q-0007Kb-0G; Tue, 08 May 2012 10:52:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi1o-0007KT-Sb for xen-devel@lists.xen.org; Tue, 08 May 2012 10:52:25 +0000 Received: from [85.158.143.35:41965] by server-2.bemta-4.messagelabs.com id E6/A0-17550-8EAF8AF4; Tue, 08 May 2012 10:52:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336474342!4736454!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25367 invoked from network); 8 May 2012 10:52:23 -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; 8 May 2012 10:52:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350693" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:52:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:52:03 +0100 Message-ID: <1336474322.14542.61.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:52:02 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Stefano Stabellini , Ian Jackson Subject: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org V2hlcmUgYXJlIHdlIHdpdGggdGhlIGZvbGxvd2luZz8KCkkndmUgbm90IHNlZW4gYW55dGhpbmcg cmVjZW50bHkgYWJvdXQgUENJIHBhc3N0aHJvdWdoLgoKSXMgaXQgc3RpbGwgdGhlIGNhc2UgdGhh dCBzYXZlL3Jlc3RvcmUgaXMgd2FpdGluZyBvbiBsaWJ7YyxsfSBwYXRjaGVzCmFuZCBSZW11cyBp cyB3YWl0aW5nIGZvciB0aG9zZT8gV2hhdCdzIHRoZSBob2xkIHVwIHRoZXJlPwoKT24gVHVlLCAy MDEyLTA1LTA4IGF0IDEwOjM0ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gdG9vbHMsIG5p Y2UgdG8gaGF2ZToKPiAgICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+ICAg ICAgICAgICAgICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRo b255IFBlcmFyZCwKPiAgICAgICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQo+ICAgICAgICAgICAg ICAgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8K PiAgICAgICAgICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRp bmcgZm9yIGxpYnhsIGV0Ywo+ICAgICAgICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJl Y2VudGx5IHJlcG9zdGVkKQo+ICAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAo bWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+ICAgICAgICAgKFNocmlyYW0sIHdhaXRp bmcgb24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKPiAgICAgICAq IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiAgICAgICAgICAgICAgICogeGwgc3VwcG9ydCBm b3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPiAgICAgICAgICAgICAg ICAgb3RoZXJ3aXNlKSAoR29uY2FsbyBHb21lcywgbmV3IHZlcnNpb24gb2YgcGF0Y2ggcG9zdGVk Cj4gICAgICAgICAgICAgICAgIHJlY2VudGx5KQo+ICAgICAgICAgICAgICAgKiBzdXBwb3J0IGZv ciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGFsbCBub3cKPiAgICAgICAg ICAgICAgICAgYXBwbGllZCwgRE9ORSkKPiAKPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJj aGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDg4My5odG1sCj4gCj4gCj4gCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwg bWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 10:52:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRi1q-0007Kb-0G; Tue, 08 May 2012 10:52:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi1o-0007KT-Sb for xen-devel@lists.xen.org; Tue, 08 May 2012 10:52:25 +0000 Received: from [85.158.143.35:41965] by server-2.bemta-4.messagelabs.com id E6/A0-17550-8EAF8AF4; Tue, 08 May 2012 10:52:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336474342!4736454!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzQ0Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25367 invoked from network); 8 May 2012 10:52:23 -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; 8 May 2012 10:52:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12350693" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:52:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:52:03 +0100 Message-ID: <1336474322.14542.61.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Tue, 8 May 2012 11:52:02 +0100 In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Stefano Stabellini , Ian Jackson Subject: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org V2hlcmUgYXJlIHdlIHdpdGggdGhlIGZvbGxvd2luZz8KCkkndmUgbm90IHNlZW4gYW55dGhpbmcg cmVjZW50bHkgYWJvdXQgUENJIHBhc3N0aHJvdWdoLgoKSXMgaXQgc3RpbGwgdGhlIGNhc2UgdGhh dCBzYXZlL3Jlc3RvcmUgaXMgd2FpdGluZyBvbiBsaWJ7YyxsfSBwYXRjaGVzCmFuZCBSZW11cyBp cyB3YWl0aW5nIGZvciB0aG9zZT8gV2hhdCdzIHRoZSBob2xkIHVwIHRoZXJlPwoKT24gVHVlLCAy MDEyLTA1LTA4IGF0IDEwOjM0ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gdG9vbHMsIG5p Y2UgdG8gaGF2ZToKPiAgICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+ICAg ICAgICAgICAgICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRo b255IFBlcmFyZCwKPiAgICAgICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQo+ICAgICAgICAgICAg ICAgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8K PiAgICAgICAgICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRp bmcgZm9yIGxpYnhsIGV0Ywo+ICAgICAgICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJl Y2VudGx5IHJlcG9zdGVkKQo+ICAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAo bWVtb3J5IGNoZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+ICAgICAgICAgKFNocmlyYW0sIHdhaXRp bmcgb24gbGlieGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKPiAgICAgICAq IHhsIGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiAgICAgICAgICAgICAgICogeGwgc3VwcG9ydCBm b3IgYXV0b3NwYXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPiAgICAgICAgICAgICAg ICAgb3RoZXJ3aXNlKSAoR29uY2FsbyBHb21lcywgbmV3IHZlcnNpb24gb2YgcGF0Y2ggcG9zdGVk Cj4gICAgICAgICAgICAgICAgIHJlY2VudGx5KQo+ICAgICAgICAgICAgICAgKiBzdXBwb3J0IGZv ciB2aWYgInJhdGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGFsbCBub3cKPiAgICAgICAg ICAgICAgICAgYXBwbGllZCwgRE9ORSkKPiAKPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJj aGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wMy9tc2cwMDg4My5odG1sCj4gCj4gCj4gCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwg bWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 10:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRi4j-0007Rs-JZ; Tue, 08 May 2012 10:55:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi4h-0007Rc-W9 for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:55:24 +0000 Received: from [85.158.138.51:10940] by server-7.bemta-3.messagelabs.com id C3/B2-03078-89BF8AF4; Tue, 08 May 2012 10:55:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336474518!16929387!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21994 invoked from network); 8 May 2012 10:55: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; 8 May 2012 10:55:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12351048" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:55:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:55:15 +0100 Message-ID: <1336474514.14542.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:55:14 +0100 In-Reply-To: <20120506212337.GA15262@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> <20120506212337.GA15262@eire.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 2012-05-06 at 22:23 +0100, Goncalo Gomes wrote: > On Sun, 06 May 2012, Ian Campbell wrote: > > > I've tried reproducing using your config file with the patch applied and > > I can't. > > > > > [...] > > > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > > > which gets triggered from an erroneous b_info->type with a bogus value > > > of 0x84 (which is neither PV nor HVM.) > > > > I think it might be useful to sprinkle prints of b_info->type everywhere > > from the call to libxl_domain_build_info_init_type up until this switch > > statement to see if you can identify the line which is overwriting this > > field. I couldn't spot it by eye but something in there is presumably > > blowing off the end of a buffer or something similar. > > > > You should probably also validate the initial value, which comes from > > c_info->type, and if that is wrong trace it back to the place which sets > > that initial value. > > Running 'make install' after various attempts seems to have done it. > > I was all along under the impression that the dynamic linker would > pick the libxenlight in the current dir, which is why I hadn't run > 'make install' every so often, but did instead occasionally run 'make > clean all' Coming to think of it, if the DLD was to pick the library > from the current directory, a world of security bugs and pain would > ensue, but for some reason I kept expecting the behaviour to be that. Yeah, "." is not normally in the default library lookup path for a variety of security etc issues as you suspected.You can either use LD_LIBRARY_PATH=stuff:other-stuff or just run make install. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10: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 ) id 1SRi4j-0007Rs-JZ; Tue, 08 May 2012 10:55:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi4h-0007Rc-W9 for xen-devel@lists.xensource.com; Tue, 08 May 2012 10:55:24 +0000 Received: from [85.158.138.51:10940] by server-7.bemta-3.messagelabs.com id C3/B2-03078-89BF8AF4; Tue, 08 May 2012 10:55:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336474518!16929387!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21994 invoked from network); 8 May 2012 10:55: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; 8 May 2012 10:55:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,549,1330905600"; d="scan'208";a="12351048" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:55:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:55:15 +0100 Message-ID: <1336474514.14542.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Goncalo Gomes Date: Tue, 8 May 2012 11:55:14 +0100 In-Reply-To: <20120506212337.GA15262@eire.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> <20120506212337.GA15262@eire.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 2012-05-06 at 22:23 +0100, Goncalo Gomes wrote: > On Sun, 06 May 2012, Ian Campbell wrote: > > > I've tried reproducing using your config file with the patch applied and > > I can't. > > > > > [...] > > > This abort is the `default` case in the switch at xl_cmdimpl.c:736, > > > which gets triggered from an erroneous b_info->type with a bogus value > > > of 0x84 (which is neither PV nor HVM.) > > > > I think it might be useful to sprinkle prints of b_info->type everywhere > > from the call to libxl_domain_build_info_init_type up until this switch > > statement to see if you can identify the line which is overwriting this > > field. I couldn't spot it by eye but something in there is presumably > > blowing off the end of a buffer or something similar. > > > > You should probably also validate the initial value, which comes from > > c_info->type, and if that is wrong trace it back to the place which sets > > that initial value. > > Running 'make install' after various attempts seems to have done it. > > I was all along under the impression that the dynamic linker would > pick the libxenlight in the current dir, which is why I hadn't run > 'make install' every so often, but did instead occasionally run 'make > clean all' Coming to think of it, if the DLD was to pick the library > from the current directory, a world of security bugs and pain would > ensue, but for some reason I kept expecting the behaviour to be that. Yeah, "." is not normally in the default library lookup path for a variety of security etc issues as you suspected.You can either use LD_LIBRARY_PATH=stuff:other-stuff or just run make install. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:56:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:56:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi5b-0007W9-1P; Tue, 08 May 2012 10:56:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi5Z-0007Vy-7D for xen-devel@lists.xen.org; Tue, 08 May 2012 10:56:18 +0000 Received: from [85.158.143.35:20656] by server-2.bemta-4.messagelabs.com id F9/A6-17550-0DBF8AF4; Tue, 08 May 2012 10:56:16 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-13.tower-21.messagelabs.com!1336474574!13223782!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30841 invoked from network); 8 May 2012 10:56:15 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 10:56:15 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 5A7C51C14021; Tue, 8 May 2012 12:56:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=T0stLLKeRh87y2Xs7jtQARV4dec=; b=16 43zPIh65ksXJSdXHc2OG+bc1DTfRHXLbBy8NyO0XEX/FZ6Hvz5ybPiCxdX6hUej6 6Q9Obbr7uWRoqKCgoU/znWUPlLk/9a1eDhUiUOx82ZTUxTT+Jn+62QSdXmAJNaci wzOfKlIcGmZmibeGlG2vThfuxCYu4W3EamH8NBjeKzbytqfpvuQhMwqjrP9U/OOM Cy2ksvu2NUQpytyydkLOd3Qd28bbleNFKBkKc1b6LXrgZKPot5aKDfmSnRAUfKNJ ae3hkiuaPoLTwuG2zFeRdlY84df43yJXGuymzIinwiA0ATJB4yJ/PsbCJ4YPs7Zi 2uOxMvBmh9XP12h4di/O2MtpmBJqoBkmC+wmgKJ7W9lhAzYPzustmPg+QQWxDwtY QoXia5XzslUqGUPM0mwP35PVWhOlgscnQETNFbGtsYtUNwyFBnDTI+4QyhUOwZLD 5mhvhFWs7+1BbYu7JG6xo/KBw3CHsvPWMX49NWxiPPlSqZCGRdupt2htKPr078jf NZoyQdZmUsa3bB1hfgTCRGeNFMkIU4tc7EQ5o+9LfiC3ooIUtaplo8qJxi3JbNMR zJ1v7O05qd0VZo7Xiln3ULekxvY0J3pUZr/5qK3cHUYYUnOKVxgdJeJbvr66IeW/ qpGjp5Rdb0BYCAenlLQ7AklJ/YB6oSDou1KaB0yQw= Received: by smtp.bloms.de (Postfix, from userid 1000) id E19AD1C14022; Tue, 8 May 2012 12:56:12 +0200 (CEST) Date: Tue, 8 May 2012 12:56:12 +0200 From: Dieter Bloms To: Ian Campbell Message-ID: <20120508105612.GA1341@bloms.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336473938.14542.55.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Dario Faggioli , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, On Tue, May 08, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > > * xl compatibility with xm: > > [...] > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter's patch has been accepted. (DONE, However see > > next bug...) > > * [BUG] Spurious CPU params error message when starting a > > domain, e.g. "Cpu weight out of range, valid values are > > within range from 1 to 65535". This is an issue with > > Dieter Bloms' patch to honour scheduler params. > > Is anyone looking into this? I've made a little patch to set this value to 256 when it wasn't defined in the configfile, but George Dunlap didn't like it (rightly). I'm sorry, my skill is not enough to implement a reasonable solution for this issue :( Maybe we should revert my patch as long as there isn't a fix. -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 10:56:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 10:56:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi5b-0007W9-1P; Tue, 08 May 2012 10:56:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRi5Z-0007Vy-7D for xen-devel@lists.xen.org; Tue, 08 May 2012 10:56:18 +0000 Received: from [85.158.143.35:20656] by server-2.bemta-4.messagelabs.com id F9/A6-17550-0DBF8AF4; Tue, 08 May 2012 10:56:16 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-13.tower-21.messagelabs.com!1336474574!13223782!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30841 invoked from network); 8 May 2012 10:56:15 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 10:56:15 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 5A7C51C14021; Tue, 8 May 2012 12:56:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=T0stLLKeRh87y2Xs7jtQARV4dec=; b=16 43zPIh65ksXJSdXHc2OG+bc1DTfRHXLbBy8NyO0XEX/FZ6Hvz5ybPiCxdX6hUej6 6Q9Obbr7uWRoqKCgoU/znWUPlLk/9a1eDhUiUOx82ZTUxTT+Jn+62QSdXmAJNaci wzOfKlIcGmZmibeGlG2vThfuxCYu4W3EamH8NBjeKzbytqfpvuQhMwqjrP9U/OOM Cy2ksvu2NUQpytyydkLOd3Qd28bbleNFKBkKc1b6LXrgZKPot5aKDfmSnRAUfKNJ ae3hkiuaPoLTwuG2zFeRdlY84df43yJXGuymzIinwiA0ATJB4yJ/PsbCJ4YPs7Zi 2uOxMvBmh9XP12h4di/O2MtpmBJqoBkmC+wmgKJ7W9lhAzYPzustmPg+QQWxDwtY QoXia5XzslUqGUPM0mwP35PVWhOlgscnQETNFbGtsYtUNwyFBnDTI+4QyhUOwZLD 5mhvhFWs7+1BbYu7JG6xo/KBw3CHsvPWMX49NWxiPPlSqZCGRdupt2htKPr078jf NZoyQdZmUsa3bB1hfgTCRGeNFMkIU4tc7EQ5o+9LfiC3ooIUtaplo8qJxi3JbNMR zJ1v7O05qd0VZo7Xiln3ULekxvY0J3pUZr/5qK3cHUYYUnOKVxgdJeJbvr66IeW/ qpGjp5Rdb0BYCAenlLQ7AklJ/YB6oSDou1KaB0yQw= Received: by smtp.bloms.de (Postfix, from userid 1000) id E19AD1C14022; Tue, 8 May 2012 12:56:12 +0200 (CEST) Date: Tue, 8 May 2012 12:56:12 +0200 From: Dieter Bloms To: Ian Campbell Message-ID: <20120508105612.GA1341@bloms.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336473938.14542.55.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Dario Faggioli , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, On Tue, May 08, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > > * xl compatibility with xm: > > [...] > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter's patch has been accepted. (DONE, However see > > next bug...) > > * [BUG] Spurious CPU params error message when starting a > > domain, e.g. "Cpu weight out of range, valid values are > > within range from 1 to 65535". This is an issue with > > Dieter Bloms' patch to honour scheduler params. > > Is anyone looking into this? I've made a little patch to set this value to 256 when it wasn't defined in the configfile, but George Dunlap didn't like it (rightly). I'm sorry, my skill is not enough to implement a reasonable solution for this issue :( Maybe we should revert my patch as long as there isn't a fix. -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 11:13:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 11: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 ) id 1SRiLZ-0007rx-Dn; Tue, 08 May 2012 11:12:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRiLY-0007rm-DE for xen-devel@lists.xen.org; Tue, 08 May 2012 11:12:48 +0000 Received: from [85.158.143.99:31048] by server-3.bemta-4.messagelabs.com id 74/89-05853-FAFF8AF4; Tue, 08 May 2012 11:12:47 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-216.messagelabs.com!1336475566!19453147!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4386 invoked from network); 8 May 2012 11:12:46 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-216.messagelabs.com with SMTP; 8 May 2012 11:12:46 -0000 Received: (qmail 10088 invoked from network); 8 May 2012 13:12:44 +0200 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; 8 May 2012 13:12:44 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Tue, 8 May 2012 13:12:39 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> <20120507230707.GA28744@phenom.dumpdata.com> In-Reply-To: <20120507230707.GA28744@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205081312.39927.pavel@netsafe.cz> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue 8. of May 2012 01:07:07 Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 01:10:32AM +0200, Pavel Mateja wrote: > > > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: > > >> Hi, > > >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest > > >> kernel. > > >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x > > >> xenified > > >> kernel. See attached log. > > >> = > > >> So I tried just to update and patch xen and kernel, but I had no luck > > >> so far. > > >> = > > >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang > > >> recently. > > >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html > > >> = > > >> I tried two kernels > > >> testing-3.5-with-extra and xen/next-3.2 from > > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > >> and > > >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > > >> Both with ioperm opcode patch which is required by the ATI patch. See > > >> attachement. > > >> = > > >> The xen/next-3.2 branch kernel was able to start booting windows. > > >> With Catalyst driver installed I just saw bluescreen during Windows > > >> boot. > > >> Without Catalyst driver Windows were able to boot but Windows ended > > >> frozen or > > >> USB was not working. It was hard to tell because input devices had no > > >> response > > >> at all. > > >> = > > >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 > > >> kernel > > >> during Windows boot. I guess I have to rework the io_bitmap patch > > >> somehow. > > > = > > > When you say 'io_bitmap' patch are you referring to these ones: > > > = > > > 70a357d xen: implement IO permission bitmap > > > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > > > 93b7a2a x86: demacro set_iopl_mask() > > > = > > > ? I don't think those are in that tag. They are in the kitchensink - > > > #testing > > > - does it work with that branch? > > > = > > > The next-3.2 is a bit old. I should actually delete it. > > = > > Hi, > > I mean this patch below. > > I think it was originally here: > > http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg011= 39 > > .html Then I was told by you to use devel/ioperm branch which I think > > doesn't exist anymore: > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg012= 13 > > .html > = > It certainly does :-) > = > > I'm too tired to test #testing branch now. I'll try it tomorrow after > > some sleep. > = > OK, take your time. Hi again! I did first tests with xen-unstable and the #testing kernel. Windows showed blue screen during boot with xm toolstack. But I had luck with xl. Windows booted succesfully so I ran the experience = index tests: kernel: 2.6.32.57 #testing CPU 7,4 7,4 RAM 7,4 5,5 Aero 7,1 7,1 Gr.card 7,1 7,1 Disk 7,3 7,5 I tried to run some games as well but the feeling is much worse compared to = older configuration. Like lags.. Are there some older branches which are supposed to work? I tried xen-4.1.3-rc1 with #testing kernel but it just freezes after while = even with Dom0 running. Only sys-rq worked. I have second slightly newer system too so I'll retest that one later. -- = Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 11:13:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 11: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 ) id 1SRiLZ-0007rx-Dn; Tue, 08 May 2012 11:12:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRiLY-0007rm-DE for xen-devel@lists.xen.org; Tue, 08 May 2012 11:12:48 +0000 Received: from [85.158.143.99:31048] by server-3.bemta-4.messagelabs.com id 74/89-05853-FAFF8AF4; Tue, 08 May 2012 11:12:47 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-216.messagelabs.com!1336475566!19453147!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4386 invoked from network); 8 May 2012 11:12:46 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-216.messagelabs.com with SMTP; 8 May 2012 11:12:46 -0000 Received: (qmail 10088 invoked from network); 8 May 2012 13:12:44 +0200 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; 8 May 2012 13:12:44 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Tue, 8 May 2012 13:12:39 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> <20120507230707.GA28744@phenom.dumpdata.com> In-Reply-To: <20120507230707.GA28744@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205081312.39927.pavel@netsafe.cz> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue 8. of May 2012 01:07:07 Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 01:10:32AM +0200, Pavel Mateja wrote: > > > On Mon, May 07, 2012 at 01:45:23PM +0200, Pavel Mat=C4=9Bja wrote: > > >> Hi, > > >> I'm trying to run AMD VGA passthru on latest XEN unstable with latest > > >> kernel. > > >> I already have working setup with ancient xen-devel 4.2 and 2.6.32.x > > >> xenified > > >> kernel. See attached log. > > >> = > > >> So I tried just to update and patch xen and kernel, but I had no luck > > >> so far. > > >> = > > >> Xen has ati_vbios_patch_respin.txt sent to xen-devel by Wei Huang > > >> recently. > > >> http://lists.xen.org/archives/html/xen-devel/2012-04/msg00291.html > > >> = > > >> I tried two kernels > > >> testing-3.5-with-extra and xen/next-3.2 from > > >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > >> and > > >> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git > > >> Both with ioperm opcode patch which is required by the ATI patch. See > > >> attachement. > > >> = > > >> The xen/next-3.2 branch kernel was able to start booting windows. > > >> With Catalyst driver installed I just saw bluescreen during Windows > > >> boot. > > >> Without Catalyst driver Windows were able to boot but Windows ended > > >> frozen or > > >> USB was not working. It was hard to tell because input devices had no > > >> response > > >> at all. > > >> = > > >> The testing-3.5-with-extra (reported as 3.4.0-rc4) just crashed dom0 > > >> kernel > > >> during Windows boot. I guess I have to rework the io_bitmap patch > > >> somehow. > > > = > > > When you say 'io_bitmap' patch are you referring to these ones: > > > = > > > 70a357d xen: implement IO permission bitmap > > > 0c596c5 x86/paravirt: paravirtualize IO permission bitmap > > > 93b7a2a x86: demacro set_iopl_mask() > > > = > > > ? I don't think those are in that tag. They are in the kitchensink - > > > #testing > > > - does it work with that branch? > > > = > > > The next-3.2 is a bit old. I should actually delete it. > > = > > Hi, > > I mean this patch below. > > I think it was originally here: > > http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/msg011= 39 > > .html Then I was told by you to use devel/ioperm branch which I think > > doesn't exist anymore: > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-11/msg012= 13 > > .html > = > It certainly does :-) > = > > I'm too tired to test #testing branch now. I'll try it tomorrow after > > some sleep. > = > OK, take your time. Hi again! I did first tests with xen-unstable and the #testing kernel. Windows showed blue screen during boot with xm toolstack. But I had luck with xl. Windows booted succesfully so I ran the experience = index tests: kernel: 2.6.32.57 #testing CPU 7,4 7,4 RAM 7,4 5,5 Aero 7,1 7,1 Gr.card 7,1 7,1 Disk 7,3 7,5 I tried to run some games as well but the feeling is much worse compared to = older configuration. Like lags.. Are there some older branches which are supposed to work? I tried xen-4.1.3-rc1 with #testing kernel but it just freezes after while = even with Dom0 running. Only sys-rq worked. I have second slightly newer system too so I'll retest that one later. -- = Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:36:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRje7-0000nF-1q; Tue, 08 May 2012 12:36:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRje6-0000n9-30 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:36:02 +0000 Received: from [85.158.143.35:65467] by server-2.bemta-4.messagelabs.com id 2E/42-17550-13319AF4; Tue, 08 May 2012 12:36:01 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336480558!11957567!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12268 invoked from network); 8 May 2012 12:36:00 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:36:00 -0000 Received: by qcsc20 with SMTP id c20so2365904qcs.32 for ; Tue, 08 May 2012 05:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yItEtelLX0GKbTY7+V0BGNkzY+uwkyGd3Urgw0def+k=; b=fZVTZHla0AZ08zQAlc2ovygvNF8VUPsYSwwahb7zO4MbyDBIog6aMmHKsP/h0TPQgz mUL2yxrKmlHvju+WsG/GGftIwX7KxcX4Qfn9AvUyxfqI8JQPcbsjPPpbTF6VsL6NCQc4 99s+ClJK2l2fpd4V2dn0VpZAV04uTEPlw3RnkrBgbgoyAx1DXjfvTRlsqBIwaJxxd1MN pAmlv7LP8FG0c5BJ6yO7PTT9dFhBVZfVNYf+qGzNya8uO1Zi6M2i+U2OVUV7i++tJFki 1+tD8QbTs+G/LwTMW7VNz9UR5DP3xFADglw9kpqEWEAyeVIUMHzrTiSsdQX4usWbLMyl ZgoQ== MIME-Version: 1.0 Received: by 10.224.1.68 with SMTP id 4mr31063142qae.6.1336480558495; Tue, 08 May 2012 05:35:58 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Tue, 8 May 2012 05:35:58 -0700 (PDT) In-Reply-To: <20120508105612.GA1341@bloms.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> <20120508105612.GA1341@bloms.de> Date: Tue, 8 May 2012 13:35:58 +0100 X-Google-Sender-Auth: 4UU3cZca36nhHt6BWHcRsVA_S1s Message-ID: From: George Dunlap To: Dieter Bloms Cc: Dario Faggioli , Ian Campbell , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms wrote: >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 * [BUG] Spurious CPU params error message = when starting a >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domain, e.g. "Cpu weight out of range,= valid values are >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 within range from 1 to 65535". This is= an issue with >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dieter Bloms' patch to honour schedule= r params. >> >> Is anyone looking into this? > > I've made a little patch to set this value to 256 when it wasn't defined > in the configfile, but George Dunlap didn't like it (rightly). > I'm sorry, my skill is not enough to implement a reasonable solution for > this issue :( > Maybe we should revert my patch as long as there isn't a fix. No, I think having the ability to set it is important. You can mark this "George will do it if no one else steps up". :-) Thanks for your help, Dieter. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:36:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRje7-0000nF-1q; Tue, 08 May 2012 12:36:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRje6-0000n9-30 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:36:02 +0000 Received: from [85.158.143.35:65467] by server-2.bemta-4.messagelabs.com id 2E/42-17550-13319AF4; Tue, 08 May 2012 12:36:01 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336480558!11957567!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12268 invoked from network); 8 May 2012 12:36:00 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:36:00 -0000 Received: by qcsc20 with SMTP id c20so2365904qcs.32 for ; Tue, 08 May 2012 05:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yItEtelLX0GKbTY7+V0BGNkzY+uwkyGd3Urgw0def+k=; b=fZVTZHla0AZ08zQAlc2ovygvNF8VUPsYSwwahb7zO4MbyDBIog6aMmHKsP/h0TPQgz mUL2yxrKmlHvju+WsG/GGftIwX7KxcX4Qfn9AvUyxfqI8JQPcbsjPPpbTF6VsL6NCQc4 99s+ClJK2l2fpd4V2dn0VpZAV04uTEPlw3RnkrBgbgoyAx1DXjfvTRlsqBIwaJxxd1MN pAmlv7LP8FG0c5BJ6yO7PTT9dFhBVZfVNYf+qGzNya8uO1Zi6M2i+U2OVUV7i++tJFki 1+tD8QbTs+G/LwTMW7VNz9UR5DP3xFADglw9kpqEWEAyeVIUMHzrTiSsdQX4usWbLMyl ZgoQ== MIME-Version: 1.0 Received: by 10.224.1.68 with SMTP id 4mr31063142qae.6.1336480558495; Tue, 08 May 2012 05:35:58 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Tue, 8 May 2012 05:35:58 -0700 (PDT) In-Reply-To: <20120508105612.GA1341@bloms.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> <20120508105612.GA1341@bloms.de> Date: Tue, 8 May 2012 13:35:58 +0100 X-Google-Sender-Auth: 4UU3cZca36nhHt6BWHcRsVA_S1s Message-ID: From: George Dunlap To: Dieter Bloms Cc: Dario Faggioli , Ian Campbell , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms wrote: >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 * [BUG] Spurious CPU params error message = when starting a >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domain, e.g. "Cpu weight out of range,= valid values are >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 within range from 1 to 65535". This is= an issue with >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dieter Bloms' patch to honour schedule= r params. >> >> Is anyone looking into this? > > I've made a little patch to set this value to 256 when it wasn't defined > in the configfile, but George Dunlap didn't like it (rightly). > I'm sorry, my skill is not enough to implement a reasonable solution for > this issue :( > Maybe we should revert my patch as long as there isn't a fix. No, I think having the ability to set it is important. You can mark this "George will do it if no one else steps up". :-) Thanks for your help, Dieter. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:38:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:38:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjfb-0000sP-HE; Tue, 08 May 2012 12:37:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjfa-0000sI-Bv for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:37:34 +0000 Received: from [193.109.254.147:13695] by server-5.bemta-14.messagelabs.com id 73/40-30733-D8319AF4; Tue, 08 May 2012 12:37:33 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336480652!8175374!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30707 invoked from network); 8 May 2012 12:37:33 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:37:33 -0000 Received: by qady23 with SMTP id y23so568297qad.7 for ; Tue, 08 May 2012 05:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u8lc3pinpSYEM3xC6aAHttnYaZ36DAbfm/nQYID5MMg=; b=thcPtgISdb7IFG2SEq2tjFcDmjDPBBY1tfy5pYO6b6y6PiJI3bh0ikKjruc6XVuM3S EgwT8/6m3opy8venR5WgYJZ1UdgMpF4T+OD0sFdq380KRAB81UWSNSkb7NgweL3rM9Yk 3Gg1MV7C1mcjibh8zARr7qCCj+Mcz+GJVNivAuW9Ac9EgJDgdkaSZHZj3f0DfxDuhP1V QvwKGZ6UAL6G2ALlMl70ZMh3I8B7t+4kE5FG5qJsyq59cfLHNtUMp4QF8OIS2tuiRJQn POu8n62LEJBczubg6lhAEJ+8qcuJ1pyorI0UY5oPqckbbgmi/51pyaPI0gaKIXVfNkic TfFQ== MIME-Version: 1.0 Received: by 10.224.212.5 with SMTP id gq5mr12000814qab.1.1336480651740; Tue, 08 May 2012 05:37:31 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Tue, 8 May 2012 05:37:31 -0700 (PDT) In-Reply-To: <1336474514.14542.64.camel@zakaz.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> <20120506212337.GA15262@eire.uk.xensource.com> <1336474514.14542.64.camel@zakaz.uk.xensource.com> Date: Tue, 8 May 2012 13:37:31 +0100 X-Google-Sender-Auth: ZUijo1fhY0s5LbaGfRYftChiBo0 Message-ID: From: George Dunlap To: Ian Campbell Cc: Goncalo Gomes , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 8, 2012 at 11:55 AM, Ian Campbell wrote: > Yeah, "." is not normally in the default library lookup path for a > variety of security etc issues as you suspected.You can either use > LD_LIBRARY_PATH=stuff:other-stuff or just run make install. ...or if you're on a .deb-based system, "make deb && dpkg -i dist/xen-*.deb". That makes a nice easy way to un-install as well. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:38:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:38:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjfb-0000sP-HE; Tue, 08 May 2012 12:37:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjfa-0000sI-Bv for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:37:34 +0000 Received: from [193.109.254.147:13695] by server-5.bemta-14.messagelabs.com id 73/40-30733-D8319AF4; Tue, 08 May 2012 12:37:33 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336480652!8175374!1 X-Originating-IP: [209.85.216.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30707 invoked from network); 8 May 2012 12:37:33 -0000 Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:37:33 -0000 Received: by qady23 with SMTP id y23so568297qad.7 for ; Tue, 08 May 2012 05:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u8lc3pinpSYEM3xC6aAHttnYaZ36DAbfm/nQYID5MMg=; b=thcPtgISdb7IFG2SEq2tjFcDmjDPBBY1tfy5pYO6b6y6PiJI3bh0ikKjruc6XVuM3S EgwT8/6m3opy8venR5WgYJZ1UdgMpF4T+OD0sFdq380KRAB81UWSNSkb7NgweL3rM9Yk 3Gg1MV7C1mcjibh8zARr7qCCj+Mcz+GJVNivAuW9Ac9EgJDgdkaSZHZj3f0DfxDuhP1V QvwKGZ6UAL6G2ALlMl70ZMh3I8B7t+4kE5FG5qJsyq59cfLHNtUMp4QF8OIS2tuiRJQn POu8n62LEJBczubg6lhAEJ+8qcuJ1pyorI0UY5oPqckbbgmi/51pyaPI0gaKIXVfNkic TfFQ== MIME-Version: 1.0 Received: by 10.224.212.5 with SMTP id gq5mr12000814qab.1.1336480651740; Tue, 08 May 2012 05:37:31 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Tue, 8 May 2012 05:37:31 -0700 (PDT) In-Reply-To: <1336474514.14542.64.camel@zakaz.uk.xensource.com> References: <20120505231926.GA8059@eire.uk.xensource.com> <1336296147.5933.5.camel@cthulhu.hellion.org.uk> <20120506212337.GA15262@eire.uk.xensource.com> <1336474514.14542.64.camel@zakaz.uk.xensource.com> Date: Tue, 8 May 2012 13:37:31 +0100 X-Google-Sender-Auth: ZUijo1fhY0s5LbaGfRYftChiBo0 Message-ID: From: George Dunlap To: Ian Campbell Cc: Goncalo Gomes , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] libxl parser question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 8, 2012 at 11:55 AM, Ian Campbell wrote: > Yeah, "." is not normally in the default library lookup path for a > variety of security etc issues as you suspected.You can either use > LD_LIBRARY_PATH=stuff:other-stuff or just run make install. ...or if you're on a .deb-based system, "make deb && dpkg -i dist/xen-*.deb". That makes a nice easy way to un-install as well. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:38:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:38:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjgL-0000wP-Ur; Tue, 08 May 2012 12:38:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjgK-0000wC-9M for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:38:20 +0000 Received: from [85.158.138.51:58752] by server-10.bemta-3.messagelabs.com id 2D/A4-29478-BB319AF4; Tue, 08 May 2012 12:38:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336480698!14895673!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5817 invoked from network); 8 May 2012 12:38:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:38:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354676" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:38:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 13:38:14 +0100 Message-ID: <1336480693.14542.71.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 13:38:13 +0100 In-Reply-To: <1336399932385-5691153.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 15:12 +0100, Fantu wrote: > Dom0: > Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version > 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and > usb redirection. > ------------------------- > /etc/modules > ------------ > loop max_loop=64 > xenfs > xen-evtchn > blktap > ------------------------- > hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is > 25259:0f53540494f7) > vi Makefile # removed dist-kernel to not compile kernel This should not be necessary at all. No kernel will be built, if you are seeing kernels getting built in the default configuration then please let me know. > vi Config.mk # test seabios unstable I don't think this will have any impact on any of the issues you relate below. But also note that results with SeaBIOS other than the one referenced by the tree would not be considered problems for Xen 4.2. > PYTHON_PREFIX_ARG = > QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit > 8f473dd104f0937ce98523fa6f9de0bd845aebbe > SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit > 74f96123e7e37c219403b50e39dabc8e8c450948 > SEABIOS_UPSTREAM_TAG ?= master > ------------------------- > Added some patches: > - autoconf: add variable for pass arbitrary options to qemu upstream v3 > - tools: Improve make deb > ------------------------- > ./configure --enable-qemuu-spice --enable-qemuu-usbredir > --enable-qemuu-debug > ------------------------- > make deb > > ------------------------- > Recent regression: > ------------- > - CRITICAL - PV domU unable to start: > With pygrub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 > With pv-grub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > Daemon running with PID 6136 > Same error also with other linux pv domU. When we went through this on you last posting this seemed to be related to the python path stuff on Ubuntu/Debian. However you don't mention tweaking that in your setup -- are you sure you have corrected this issue? If this isn't the issue then please can you provide (separately) full logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > ------------------------- > > ------------------------- > Old issue: > - Save/restore not working with qemu-xen This is expected -- this support is not yet added to the tree. > ------------- > - Unable to get QXL vga working correctly and with full videoram I think we have now established that this is not currently a feature of Xen. If you or Zhou Peng are interested in doing the development work for then this is something we would likely accept as a new feature for Xen 4.3. It's not 4.2 material though. > ------------- > - On hvm domU start, domU work also this output on xl create: > libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of > range, valid values are within range from 1 to 65535 I have added this one to the TODO list as a bug, hopefully someone is looking into it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:38:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:38:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjgL-0000wP-Ur; Tue, 08 May 2012 12:38:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjgK-0000wC-9M for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:38:20 +0000 Received: from [85.158.138.51:58752] by server-10.bemta-3.messagelabs.com id 2D/A4-29478-BB319AF4; Tue, 08 May 2012 12:38:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336480698!14895673!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5817 invoked from network); 8 May 2012 12:38:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:38:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354676" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:38:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 13:38:14 +0100 Message-ID: <1336480693.14542.71.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 13:38:13 +0100 In-Reply-To: <1336399932385-5691153.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 15:12 +0100, Fantu wrote: > Dom0: > Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version > 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and > usb redirection. > ------------------------- > /etc/modules > ------------ > loop max_loop=64 > xenfs > xen-evtchn > blktap > ------------------------- > hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is > 25259:0f53540494f7) > vi Makefile # removed dist-kernel to not compile kernel This should not be necessary at all. No kernel will be built, if you are seeing kernels getting built in the default configuration then please let me know. > vi Config.mk # test seabios unstable I don't think this will have any impact on any of the issues you relate below. But also note that results with SeaBIOS other than the one referenced by the tree would not be considered problems for Xen 4.2. > PYTHON_PREFIX_ARG = > QEMU_UPSTREAM_URL ?= git://git.qemu.org/qemu.git #commit > 8f473dd104f0937ce98523fa6f9de0bd845aebbe > SEABIOS_UPSTREAM_URL ?= git://git.seabios.org/seabios.git #commit > 74f96123e7e37c219403b50e39dabc8e8c450948 > SEABIOS_UPSTREAM_TAG ?= master > ------------------------- > Added some patches: > - autoconf: add variable for pass arbitrary options to qemu upstream v3 > - tools: Improve make deb > ------------------------- > ./configure --enable-qemuu-spice --enable-qemuu-usbredir > --enable-qemuu-debug > ------------------------- > make deb > > ------------------------- > Recent regression: > ------------- > - CRITICAL - PV domU unable to start: > With pygrub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 > With pv-grub: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > Daemon running with PID 6136 > Same error also with other linux pv domU. When we went through this on you last posting this seemed to be related to the python path stuff on Ubuntu/Debian. However you don't mention tweaking that in your setup -- are you sure you have corrected this issue? If this isn't the issue then please can you provide (separately) full logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > ------------------------- > > ------------------------- > Old issue: > - Save/restore not working with qemu-xen This is expected -- this support is not yet added to the tree. > ------------- > - Unable to get QXL vga working correctly and with full videoram I think we have now established that this is not currently a feature of Xen. If you or Zhou Peng are interested in doing the development work for then this is something we would likely accept as a new feature for Xen 4.3. It's not 4.2 material though. > ------------- > - On hvm domU start, domU work also this output on xl create: > libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of > range, valid values are within range from 1 to 65535 I have added this one to the TODO list as a bug, hopefully someone is looking into it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:39:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRjhQ-00013X-D1; Tue, 08 May 2012 12:39:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjhP-00013E-6G for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:39:27 +0000 Received: from [85.158.139.83:23831] by server-2.bemta-5.messagelabs.com id BC/EB-17016-EF319AF4; Tue, 08 May 2012 12:39:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336480764!20052391!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8131 invoked from network); 8 May 2012 12:39:24 -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; 8 May 2012 12:39:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354707" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12: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, 8 May 2012 13:39:23 +0100 Message-ID: <1336480761.14542.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Tue, 8 May 2012 13:39:21 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 16:54 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336406048 -7200 > # Node ID aa4a499106c37c60f955662da81000db559ab5be > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > xl.cfg: fix typo in opengl section > > Add missing i to qemu-xen-traditonal > > Signed-off-by: Olaf Hering Acked-by: Ian Campbell > > diff -r 0f53540494f7 -r aa4a499106c3 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -278,7 +278,7 @@ Simple DirectMedia Layer). The default i > =item C > > Enable OpenGL acceleration of the SDL display. Only effects machines > -using C and only if the > +using C and only if the > device-model was compiled with OpenGL support. Disabled by default. > > =item C > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:39:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRjhQ-00013X-D1; Tue, 08 May 2012 12:39:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjhP-00013E-6G for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:39:27 +0000 Received: from [85.158.139.83:23831] by server-2.bemta-5.messagelabs.com id BC/EB-17016-EF319AF4; Tue, 08 May 2012 12:39:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336480764!20052391!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8131 invoked from network); 8 May 2012 12:39:24 -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; 8 May 2012 12:39:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354707" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12: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, 8 May 2012 13:39:23 +0100 Message-ID: <1336480761.14542.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Tue, 8 May 2012 13:39:21 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 16:54 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336406048 -7200 > # Node ID aa4a499106c37c60f955662da81000db559ab5be > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > xl.cfg: fix typo in opengl section > > Add missing i to qemu-xen-traditonal > > Signed-off-by: Olaf Hering Acked-by: Ian Campbell > > diff -r 0f53540494f7 -r aa4a499106c3 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -278,7 +278,7 @@ Simple DirectMedia Layer). The default i > =item C > > Enable OpenGL acceleration of the SDL display. Only effects machines > -using C and only if the > +using C and only if the > device-model was compiled with OpenGL support. Disabled by default. > > =item C > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:41:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRjj8-0001GG-15; Tue, 08 May 2012 12:41:14 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjj7-0001Fq-24 for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:41:13 +0000 Received: from [85.158.138.51:50649] by server-9.bemta-3.messagelabs.com id 44/69-26691-86419AF4; Tue, 08 May 2012 12:41:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336480871!14896385!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18618 invoked from network); 8 May 2012 12:41:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:41:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354749" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:41: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, 8 May 2012 13:41:11 +0100 Message-ID: <1336480869.14542.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dan Magenheimer Date: Tue, 8 May 2012 13:41:09 +0100 In-Reply-To: References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 17:37 +0100, Dan Magenheimer wrote: > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > Sent: Sunday, May 06, 2012 3:36 AM > > To: Olaf Hering > > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > > # HG changeset patch > > > > > # User Olaf Hering > > > > > # Date 1336159720 -7200 > > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > > xl.cfg: document the maxmem= option > > > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > > --- a/docs/man/xl.cfg.pod.5 > > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > > mode) and your guest workload consists of a a very large number of > > > > > similar processes then increasing this value may improve performance. > > > > > > > > > > +=item B > > > > > + > > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > can _ever_ see... > > What about guest OS's that support hotplug memory? Does the toolstack (need to) expose the capability to drive that as a host admin? I don't think xl does... In which case this wording can be tweaked when that feature is added? > Also, a subtle point, but is this the maximum physical address that > will contain read/write pages or the maximum amount of RAM that the > guest OS should be prepared to map as read/writeable (e.g. after > subtracting off reserved e820 ranges) or ??? I think it is total number of memory pages, not the maximum PFN. e.g. the maximum address might be 4.5GB on a 4GB machine with a PCI hole. I *think*... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:41:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12: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 ) id 1SRjj8-0001GG-15; Tue, 08 May 2012 12:41:14 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjj7-0001Fq-24 for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:41:13 +0000 Received: from [85.158.138.51:50649] by server-9.bemta-3.messagelabs.com id 44/69-26691-86419AF4; Tue, 08 May 2012 12:41:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336480871!14896385!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18618 invoked from network); 8 May 2012 12:41:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:41:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354749" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:41: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, 8 May 2012 13:41:11 +0100 Message-ID: <1336480869.14542.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dan Magenheimer Date: Tue, 8 May 2012 13:41:09 +0100 In-Reply-To: References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-07 at 17:37 +0100, Dan Magenheimer wrote: > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > Sent: Sunday, May 06, 2012 3:36 AM > > To: Olaf Hering > > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > > # HG changeset patch > > > > > # User Olaf Hering > > > > > # Date 1336159720 -7200 > > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > > xl.cfg: document the maxmem= option > > > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > > --- a/docs/man/xl.cfg.pod.5 > > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > > mode) and your guest workload consists of a a very large number of > > > > > similar processes then increasing this value may improve performance. > > > > > > > > > > +=item B > > > > > + > > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > can _ever_ see... > > What about guest OS's that support hotplug memory? Does the toolstack (need to) expose the capability to drive that as a host admin? I don't think xl does... In which case this wording can be tweaked when that feature is added? > Also, a subtle point, but is this the maximum physical address that > will contain read/write pages or the maximum amount of RAM that the > guest OS should be prepared to map as read/writeable (e.g. after > subtracting off reserved e820 ranges) or ??? I think it is total number of memory pages, not the maximum PFN. e.g. the maximum address might be 4.5GB on a 4GB machine with a PCI hole. I *think*... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:45:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjmi-0001ak-LE; Tue, 08 May 2012 12:44:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjmg-0001aR-I2 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:44:54 +0000 Received: from [85.158.138.51:51467] by server-11.bemta-3.messagelabs.com id 9A/02-18894-54519AF4; Tue, 08 May 2012 12:44:53 +0000 X-Env-Sender: rshriram@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336481091!16956656!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16812 invoked from network); 8 May 2012 12:44:53 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:44:53 -0000 Received: by yenm4 with SMTP id m4so3024693yen.32 for ; Tue, 08 May 2012 05:44:51 -0700 (PDT) Received: by 10.50.157.138 with SMTP id wm10mr5562705igb.65.1336481091407; Tue, 08 May 2012 05:44:51 -0700 (PDT) Received: from [192.168.2.2] (c-24-14-60-133.hsd1.il.comcast.net. [24.14.60.133]) by mx.google.com with ESMTPS id ew6sm8436826igc.6.2012.05.08.05.44.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 05:44:49 -0700 (PDT) References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> In-Reply-To: <1336474322.14542.61.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPhone Mail (9B176) From: Shriram Rajagopalan Date: Tue, 8 May 2012 07:45:47 -0500 To: Ian Campbell Cc: Anthony Perard , IanJackson , Stefano Stabellini , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gMjAxMi0wNS0wOCwgYXQgNTo1MiBBTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0 cml4LmNvbT4gd3JvdGU6Cgo+IFdoZXJlIGFyZSB3ZSB3aXRoIHRoZSBmb2xsb3dpbmc/Cj4gCj4g SSd2ZSBub3Qgc2VlbiBhbnl0aGluZyByZWNlbnRseSBhYm91dCBQQ0kgcGFzc3Rocm91Z2guCj4g Cj4gSXMgaXQgc3RpbGwgdGhlIGNhc2UgdGhhdCBzYXZlL3Jlc3RvcmUgaXMgd2FpdGluZyBvbiBs aWJ7YyxsfSBwYXRjaGVzCj4gYW5kIFJlbXVzIGlzIHdhaXRpbmcgZm9yIHRob3NlPyBXaGF0J3Mg dGhlIGhvbGQgdXAgdGhlcmU/CgpUaGUgbGFzdCBJIHJlbWVtYmVyLCBTdGVmYW5vIHJlcG9zdGVk IHRoZSBwYXRjaGVzIGZvciB0aGUgTnRoIHRpbWUgCmJ1dCB1bmZvcnR1bmF0ZWx5IGZvcmdvdCB0 byBhZGQgdGhlIGFja2VkLWJ5IGZyb20gc29tZW9uZS4KCkkgc3RvcHBlZCByZXBvc3RpbmcgbXkg cGF0Y2hlcyBldmVyeSB0aW1lIFN0ZWZhbm8gcmVwb3N0ZWQgaGlzLCAKbGVzdCBJIHNwYW0gdGhl IGxpc3QuCgpJIGFtIGp1c3Qgd2FpdGluZyBmb3IgaGlzIHBhdGNoZXMgdG8gZ28gaW4gYmVmb3Jl IEkgcmViYXNlL3JlcG9zdCBtaW5lLgoKU2hyaXJhbQoKPiAKPiBPbiBUdWUsIDIwMTItMDUtMDgg YXQgMTA6MzQgKzAxMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gdG9vbHMsIG5pY2UgdG8gaGF2 ZToKPj4gICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+PiAgICAgICAgICAg ICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFy ZCwKPj4gICAgICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQo+PiAgICAgICAgICAgICAgKiBVcHN0 cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KPj4gICAgICAg ICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRpbmcgZm9yIGxp YnhsIGV0Ywo+PiAgICAgICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJlY2VudGx5IHJl cG9zdGVkKQo+PiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNo ZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+PiAgICAgICAgKFNocmlyYW0sIHdhaXRpbmcgb24gbGli eGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKPj4gICAgICAqIHhsIGNvbXBh dGliaWxpdHkgd2l0aCB4bToKPj4gICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3Nw YXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPj4gICAgICAgICAgICAgICAgb3RoZXJ3 aXNlKSAoR29uY2FsbyBHb21lcywgbmV3IHZlcnNpb24gb2YgcGF0Y2ggcG9zdGVkCj4+ICAgICAg ICAgICAgICAgIHJlY2VudGx5KQo+PiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJh dGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGFsbCBub3cKPj4gICAgICAgICAgICAgICAg YXBwbGllZCwgRE9ORSkKPj4gCj4+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9o dG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwODgzLmh0bWwKPj4gCj4+IAo+PiAKPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1h aWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwKPiAKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlz dHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 12:45:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjmi-0001ak-LE; Tue, 08 May 2012 12:44:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjmg-0001aR-I2 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:44:54 +0000 Received: from [85.158.138.51:51467] by server-11.bemta-3.messagelabs.com id 9A/02-18894-54519AF4; Tue, 08 May 2012 12:44:53 +0000 X-Env-Sender: rshriram@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336481091!16956656!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16812 invoked from network); 8 May 2012 12:44:53 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:44:53 -0000 Received: by yenm4 with SMTP id m4so3024693yen.32 for ; Tue, 08 May 2012 05:44:51 -0700 (PDT) Received: by 10.50.157.138 with SMTP id wm10mr5562705igb.65.1336481091407; Tue, 08 May 2012 05:44:51 -0700 (PDT) Received: from [192.168.2.2] (c-24-14-60-133.hsd1.il.comcast.net. [24.14.60.133]) by mx.google.com with ESMTPS id ew6sm8436826igc.6.2012.05.08.05.44.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 05:44:49 -0700 (PDT) References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> In-Reply-To: <1336474322.14542.61.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPhone Mail (9B176) From: Shriram Rajagopalan Date: Tue, 8 May 2012 07:45:47 -0500 To: Ian Campbell Cc: Anthony Perard , IanJackson , Stefano Stabellini , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gMjAxMi0wNS0wOCwgYXQgNTo1MiBBTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0 cml4LmNvbT4gd3JvdGU6Cgo+IFdoZXJlIGFyZSB3ZSB3aXRoIHRoZSBmb2xsb3dpbmc/Cj4gCj4g SSd2ZSBub3Qgc2VlbiBhbnl0aGluZyByZWNlbnRseSBhYm91dCBQQ0kgcGFzc3Rocm91Z2guCj4g Cj4gSXMgaXQgc3RpbGwgdGhlIGNhc2UgdGhhdCBzYXZlL3Jlc3RvcmUgaXMgd2FpdGluZyBvbiBs aWJ7YyxsfSBwYXRjaGVzCj4gYW5kIFJlbXVzIGlzIHdhaXRpbmcgZm9yIHRob3NlPyBXaGF0J3Mg dGhlIGhvbGQgdXAgdGhlcmU/CgpUaGUgbGFzdCBJIHJlbWVtYmVyLCBTdGVmYW5vIHJlcG9zdGVk IHRoZSBwYXRjaGVzIGZvciB0aGUgTnRoIHRpbWUgCmJ1dCB1bmZvcnR1bmF0ZWx5IGZvcmdvdCB0 byBhZGQgdGhlIGFja2VkLWJ5IGZyb20gc29tZW9uZS4KCkkgc3RvcHBlZCByZXBvc3RpbmcgbXkg cGF0Y2hlcyBldmVyeSB0aW1lIFN0ZWZhbm8gcmVwb3N0ZWQgaGlzLCAKbGVzdCBJIHNwYW0gdGhl IGxpc3QuCgpJIGFtIGp1c3Qgd2FpdGluZyBmb3IgaGlzIHBhdGNoZXMgdG8gZ28gaW4gYmVmb3Jl IEkgcmViYXNlL3JlcG9zdCBtaW5lLgoKU2hyaXJhbQoKPiAKPiBPbiBUdWUsIDIwMTItMDUtMDgg YXQgMTA6MzQgKzAxMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gdG9vbHMsIG5pY2UgdG8gaGF2 ZToKPj4gICAgICAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+PiAgICAgICAgICAg ICAgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFy ZCwKPj4gICAgICAgICAgICAgICAgcGF0Y2hlcyBzZW50KQo+PiAgICAgICAgICAgICAgKiBVcHN0 cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQsIFN0ZWZhbm8KPj4gICAgICAg ICAgICAgICAgU3RhYmVsbGluaSwgcWVtdSBwYXRjaGVzIGFwcGxpZWQsIHdhaXRpbmcgZm9yIGxp YnhsIGV0Ywo+PiAgICAgICAgICAgICAgICBzaWRlIHdoaWNoIGhhcyBiZWVuIHJlY2VudGx5IHJl cG9zdGVkKQo+PiAgICAgICogSW5pdGlhbCB4bCBzdXBwb3J0IGZvciBSZW11cyAobWVtb3J5IGNo ZWNrcG9pbnQsIGJsYWNraG9saW5nKQo+PiAgICAgICAgKFNocmlyYW0sIHdhaXRpbmcgb24gbGli eGwgc2lkZSBvZiBxZW11IHVwc3RyZWFtIHNhdmUvcmVzdG9yZSkKPj4gICAgICAqIHhsIGNvbXBh dGliaWxpdHkgd2l0aCB4bToKPj4gICAgICAgICAgICAgICogeGwgc3VwcG9ydCBmb3IgYXV0b3Nw YXduaW5nIHZuY3ZpZXdlciAodm5jdmlld2VyPTEgb3IKPj4gICAgICAgICAgICAgICAgb3RoZXJ3 aXNlKSAoR29uY2FsbyBHb21lcywgbmV3IHZlcnNpb24gb2YgcGF0Y2ggcG9zdGVkCj4+ICAgICAg ICAgICAgICAgIHJlY2VudGx5KQo+PiAgICAgICAgICAgICAgKiBzdXBwb3J0IGZvciB2aWYgInJh dGUiIHBhcmFtZXRlciAoTWF0aGlldSBHYWduw6ksIGFsbCBub3cKPj4gICAgICAgICAgICAgICAg YXBwbGllZCwgRE9ORSkKPj4gCj4+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9o dG1sL3hlbi1kZXZlbC8yMDEyLTAzL21zZzAwODgzLmh0bWwKPj4gCj4+IAo+PiAKPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1h aWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+PiBodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwKPiAKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlz dHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue May 08 12:50:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRjsB-0001lS-DV; Tue, 08 May 2012 12:50:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjsA-0001lN-Q6 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:50:35 +0000 Received: from [85.158.139.83:33174] by server-10.bemta-5.messagelabs.com id 9F/F1-08260-A9619AF4; Tue, 08 May 2012 12:50:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336481432!27201396!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22972 invoked from network); 8 May 2012 12:50:33 -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; 8 May 2012 12:50:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354933" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:50: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, 8 May 2012 13:50:32 +0100 Message-ID: <1336481430.14542.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 8 May 2012 13:50:30 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> <20120508105612.GA1341@bloms.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Dario Faggioli , Dieter Bloms , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 13:35 +0100, George Dunlap wrote: > On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms wrote: > >> > * [BUG] Spurious CPU params error message when starting a > >> > domain, e.g. "Cpu weight out of range, valid values are > >> > within range from 1 to 65535". This is an issue with > >> > Dieter Bloms' patch to honour scheduler params. > >> > >> Is anyone looking into this? > > > > I've made a little patch to set this value to 256 when it wasn't defined > > in the configfile, but George Dunlap didn't like it (rightly). > > I'm sorry, my skill is not enough to implement a reasonable solution for > > this issue :( > > Maybe we should revert my patch as long as there isn't a fix. > > No, I think having the ability to set it is important. You can mark > this "George will do it if no one else steps up". :-) You've got yerself a deal ;-) > Thanks for your help, Dieter. Yes, thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:50:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRjsB-0001lS-DV; Tue, 08 May 2012 12:50:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjsA-0001lN-Q6 for xen-devel@lists.xen.org; Tue, 08 May 2012 12:50:35 +0000 Received: from [85.158.139.83:33174] by server-10.bemta-5.messagelabs.com id 9F/F1-08260-A9619AF4; Tue, 08 May 2012 12:50:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336481432!27201396!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22972 invoked from network); 8 May 2012 12:50:33 -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; 8 May 2012 12:50:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12354933" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:50: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, 8 May 2012 13:50:32 +0100 Message-ID: <1336481430.14542.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 8 May 2012 13:50:30 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336473938.14542.55.camel@zakaz.uk.xensource.com> <20120508105612.GA1341@bloms.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Dario Faggioli , Dieter Bloms , xen-devel Subject: Re: [Xen-devel] sched params spurious error message (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 13:35 +0100, George Dunlap wrote: > On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms wrote: > >> > * [BUG] Spurious CPU params error message when starting a > >> > domain, e.g. "Cpu weight out of range, valid values are > >> > within range from 1 to 65535". This is an issue with > >> > Dieter Bloms' patch to honour scheduler params. > >> > >> Is anyone looking into this? > > > > I've made a little patch to set this value to 256 when it wasn't defined > > in the configfile, but George Dunlap didn't like it (rightly). > > I'm sorry, my skill is not enough to implement a reasonable solution for > > this issue :( > > Maybe we should revert my patch as long as there isn't a fix. > > No, I think having the ability to set it is important. You can mark > this "George will do it if no one else steps up". :-) You've got yerself a deal ;-) > Thanks for your help, Dieter. Yes, thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:58:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjzj-0001uy-Ea; Tue, 08 May 2012 12:58:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjzi-0001ut-MY for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:58:23 +0000 Received: from [85.158.139.83:14137] by server-8.bemta-5.messagelabs.com id A8/1D-26964-D6819AF4; Tue, 08 May 2012 12:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336481898!23330448!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7924 invoked from network); 8 May 2012 12:58:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355144" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:58: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, 8 May 2012 13:58:17 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRjzc-0008Ec-Uo; Tue, 08 May 2012 12:58:16 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRjzc-0002KB-RY; Tue, 08 May 2012 13:58:16 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 13:58:16 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12801: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12801 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12801/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 12:58:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 12:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjzj-0001uy-Ea; Tue, 08 May 2012 12:58:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRjzi-0001ut-MY for xen-devel@lists.xensource.com; Tue, 08 May 2012 12:58:23 +0000 Received: from [85.158.139.83:14137] by server-8.bemta-5.messagelabs.com id A8/1D-26964-D6819AF4; Tue, 08 May 2012 12:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336481898!23330448!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7924 invoked from network); 8 May 2012 12:58:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 12:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355144" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 12:58: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, 8 May 2012 13:58:17 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRjzc-0008Ec-Uo; Tue, 08 May 2012 12:58:16 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRjzc-0002KB-RY; Tue, 08 May 2012 13:58:16 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 13:58:16 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12801: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12801 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12801/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:10:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkAq-0002OP-E3; Tue, 08 May 2012 13:09:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkAo-0002OJ-GR for xen-devel@lists.xen.org; Tue, 08 May 2012 13:09:50 +0000 Received: from [85.158.143.99:31149] by server-3.bemta-4.messagelabs.com id 79/28-05853-D1B19AF4; Tue, 08 May 2012 13:09:49 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336482588!21684303!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32728 invoked from network); 8 May 2012 13:09:49 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 13:09:49 -0000 Received: by eekc4 with SMTP id c4so1353986eek.32 for ; Tue, 08 May 2012 06:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MfKuTNyyXXvTIV/z9Td3gVUqK+L28SoffeBaSbG/ORg=; b=d4elzIC2xI0m3cNmMR/grRlJuuWf7btCWAk8ztM8VaPErjoVzitc9nYpriZMvV8O0l 8wOpzSmTJEDTJL+m4UdVwpYiJ9NTzyIdtHMY+fKEXOtDxOMZFWqpDGY71LZDqTc6xs55 TG7/MPbvecPcV6rPskKrKSJ4FqkBbWnM1NoGuHEVW+S2nNnIiIlOzqQmsuNxFo3bYlQK btZdrJT6duaFaeQsWaf4/ZFP9z4tw5fHGn5nOApNuhyF6j4jv441DI5N1CpJ2aDGI7hm N2NCy+DuGurdKYlaN/sadRb91hU6EmUOjTOA/9iTMrzZcYU10ChaH7BEemSmCzuktKMZ kgWw== Received: by 10.213.152.1 with SMTP id e1mr3410205ebw.125.1336482588354; Tue, 08 May 2012 06:09:48 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id d18sm102255626eeb.7.2012.05.08.06.09.47 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 06:09:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 08 May 2012 14:09:41 +0100 From: Keir Fraser To: Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich Message-ID: Thread-Topic: x86_64: fix naming of rflags in elf regset structure Thread-Index: Ac0tG9QiYCvkjAS7jEC6tuaW61j0NA== In-Reply-To: <4FA8EC95.8020508@citrix.com> Mime-version: 1.0 Subject: Re: [Xen-devel] x86_64: fix naming of rflags in elf regset structure X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 08/05/2012 10:51, "Andrew Cooper" wrote: > This is a trivial, non-functional, change so should be considered for > 4.2, and backported to 4.1 and 4.0 release candidates. Since this doesn't fix anything, apart from a source-code name, this would be pointless to backport. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:10:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkAq-0002OP-E3; Tue, 08 May 2012 13:09:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkAo-0002OJ-GR for xen-devel@lists.xen.org; Tue, 08 May 2012 13:09:50 +0000 Received: from [85.158.143.99:31149] by server-3.bemta-4.messagelabs.com id 79/28-05853-D1B19AF4; Tue, 08 May 2012 13:09:49 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336482588!21684303!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32728 invoked from network); 8 May 2012 13:09:49 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 13:09:49 -0000 Received: by eekc4 with SMTP id c4so1353986eek.32 for ; Tue, 08 May 2012 06:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MfKuTNyyXXvTIV/z9Td3gVUqK+L28SoffeBaSbG/ORg=; b=d4elzIC2xI0m3cNmMR/grRlJuuWf7btCWAk8ztM8VaPErjoVzitc9nYpriZMvV8O0l 8wOpzSmTJEDTJL+m4UdVwpYiJ9NTzyIdtHMY+fKEXOtDxOMZFWqpDGY71LZDqTc6xs55 TG7/MPbvecPcV6rPskKrKSJ4FqkBbWnM1NoGuHEVW+S2nNnIiIlOzqQmsuNxFo3bYlQK btZdrJT6duaFaeQsWaf4/ZFP9z4tw5fHGn5nOApNuhyF6j4jv441DI5N1CpJ2aDGI7hm N2NCy+DuGurdKYlaN/sadRb91hU6EmUOjTOA/9iTMrzZcYU10ChaH7BEemSmCzuktKMZ kgWw== Received: by 10.213.152.1 with SMTP id e1mr3410205ebw.125.1336482588354; Tue, 08 May 2012 06:09:48 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id d18sm102255626eeb.7.2012.05.08.06.09.47 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 06:09:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 08 May 2012 14:09:41 +0100 From: Keir Fraser To: Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich Message-ID: Thread-Topic: x86_64: fix naming of rflags in elf regset structure Thread-Index: Ac0tG9QiYCvkjAS7jEC6tuaW61j0NA== In-Reply-To: <4FA8EC95.8020508@citrix.com> Mime-version: 1.0 Subject: Re: [Xen-devel] x86_64: fix naming of rflags in elf regset structure X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 08/05/2012 10:51, "Andrew Cooper" wrote: > This is a trivial, non-functional, change so should be considered for > 4.2, and backported to 4.1 and 4.0 release candidates. Since this doesn't fix anything, apart from a source-code name, this would be pointless to backport. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:23:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkNZ-0002e6-PP; Tue, 08 May 2012 13:23:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkNY-0002e1-9k for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:23:00 +0000 Received: from [85.158.143.35:9910] by server-3.bemta-4.messagelabs.com id F9/BF-05853-33E19AF4; Tue, 08 May 2012 13:22:59 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-21.messagelabs.com!1336483376!15837279!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10115 invoked from network); 8 May 2012 13:22:58 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:22:58 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRkNU-0004LQ-1Y for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:22:56 -0700 Date: Tue, 8 May 2012 06:22:56 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336483376041-5694297.post@n5.nabble.com> In-Reply-To: <1336480693.14542.71.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > When we went through this on you last posting this seemed to be related > to the python path stuff on Ubuntu/Debian. However you don't mention > tweaking that in your setup -- are you sure you have corrected this > issue? > > If this isn't the issue then please can you provide (separately) full > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not domU pv boot error. -------------------------------------- lucid.cfg -------- name="lucid" vcpus=2 memory=512 disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] vif=['bridge=xenbr0'] vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] bootloader = '/usr/bin/pygrub' #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra = "(hd0,0)/grub/grub.cfg" -------------------------------------- With pygrub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 xc: debug: hypercall buffer: total allocations:13 total releases:13 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:10 misses:2 toobig:1 ------------------------------- xl-lucid.log seems not to be created during this xl create -------------------------------------- With pv-grub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14277 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4ac6 -> 0xdf17c6 domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7f6a04b45000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f6a04b45000 -> 0x0x7f6a054e3f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7f6a04a45000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7f6a04a3c000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 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 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x33f1c8 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x33f1c9 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7f6a04a3b000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15368 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbf111 domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x33f1c7 domainbuilder: detail: launch_vm: called, ctxt=0x7fff4b0bd640 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 21 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-21,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-21 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 9230 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 ------------------------------- /var/log/xen/xl-lucid.log ----------------------- Waiting for domain lucid (domid 21) to die [pid 9231] libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=21 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=0 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=-1 libxl: debug: libxl.c:761:domain_death_occurred: empty list libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done Domain 21 has been destroyed. -------------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694297.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:23:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkNZ-0002e6-PP; Tue, 08 May 2012 13:23:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkNY-0002e1-9k for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:23:00 +0000 Received: from [85.158.143.35:9910] by server-3.bemta-4.messagelabs.com id F9/BF-05853-33E19AF4; Tue, 08 May 2012 13:22:59 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-21.messagelabs.com!1336483376!15837279!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10115 invoked from network); 8 May 2012 13:22:58 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:22:58 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRkNU-0004LQ-1Y for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:22:56 -0700 Date: Tue, 8 May 2012 06:22:56 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336483376041-5694297.post@n5.nabble.com> In-Reply-To: <1336480693.14542.71.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > When we went through this on you last posting this seemed to be related > to the python path stuff on Ubuntu/Debian. However you don't mention > tweaking that in your setup -- are you sure you have corrected this > issue? > > If this isn't the issue then please can you provide (separately) full > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not domU pv boot error. -------------------------------------- lucid.cfg -------- name="lucid" vcpus=2 memory=512 disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] vif=['bridge=xenbr0'] vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] bootloader = '/usr/bin/pygrub' #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra = "(hd0,0)/grub/grub.cfg" -------------------------------------- With pygrub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: -3 xc: debug: hypercall buffer: total allocations:13 total releases:13 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:10 misses:2 toobig:1 ------------------------------- xl-lucid.log seems not to be created during this xl create -------------------------------------- With pv-grub: -------------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14277 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4ac6 -> 0xdf17c6 domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7f6a04b45000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f6a04b45000 -> 0x0x7f6a054e3f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7f6a04a45000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7f6a04a3c000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 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 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x33f1c8 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x33f1c9 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7f6a04a3b000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15368 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xbf111 domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x33f1c7 domainbuilder: detail: launch_vm: called, ctxt=0x7fff4b0bd640 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 21 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-21,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-21 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 9230 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 ------------------------------- /var/log/xen/xl-lucid.log ----------------------- Waiting for domain lucid (domid 21) to die [pid 9231] libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=21 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x1bd0818 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x1bcd920:21] from domid=21 nentries=1 rc=0 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x1bcd920:21] got=domaininfos[0] got->domain=-1 libxl: debug: libxl.c:761:domain_death_occurred: empty list libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done Domain 21 has been destroyed. -------------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694297.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:28:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:28:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkSU-0002nJ-Ga; Tue, 08 May 2012 13:28:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkSS-0002nD-Mt for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:28:05 +0000 Received: from [193.109.254.147:49306] by server-2.bemta-14.messagelabs.com id 45/14-19409-46F19AF4; Tue, 08 May 2012 13:28:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336483683!8214602!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20690 invoked from network); 8 May 2012 13:28:03 -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; 8 May 2012 13:28:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355933" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:27: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, 8 May 2012 14:27:00 +0100 Message-ID: <1336483619.14542.86.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen.org Date: Tue, 8 May 2012 14:26:59 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:25 +0100, xen.org wrote: > flight 12800 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/ > > Failures :-/ but no regressions. > > Tests which are failing intermittently (not blocking): > test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12797 2012-05-08 07:11:44 Z executing ssh ... root@10.80.249.57 xl create /etc/xen/redhat.guest.osstest.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->000000000019bca4 TOTAL: 0000000000000000->000000002f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x000000000000017b 1GB PAGES: 0x0000000000000000 libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 libxl: error: libxl_create.c:628:do_domain_create: cannot add disk 1 to domain: -3 libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory libxl: error: libxl.c:1094:libxl_domain_destroy: libxl__destroy_device_model failed for 2 Parsing config file /etc/xen/redhat.guest.osstest.cfg -3 is ERROR_FAIL from libxl_device_disk_add() and I don't see anything else in the logs. Weird thing is I don't see any logs from libxl__device_disk_set_backend which is unconditionally the first thing libxl_device_disk_add calls and which always logs something with at least LIBXL__LOG_DEBUG -- which I expected would go to /var/log/xen/xl-NAME.log but http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/test-amd64-i386-rhel6hvm-amd/potato-beetle---var-log-xen-xl-redhat.guest.osstest.log doesn't have anything. However I suspect that is the log of the previous boot of the guest -- in which case where is the log from this one? Ignoring the missing logs, the only place I can see an ERROR_FAIL from libxl_device_disk_add is the call to libxl__blktap_devpath, which is unlogged (patch below). Both 12797 (previous pass) and 12800 (this fail) seem to be testing the same Xen version (8f1e0cc4a507), so I'm not sure what changed. Ian. 8<-------------------------------------- # HG changeset patch # User Ian Campbell # Date 1336483471 -3600 # Node ID 662621bcecd59b34acfda54a4c8d360389a40536 # Parent 5f72f4fd7f048c2e325c5070bb7adcc216b5772f libxl: log failure from libxl__blktap_devpath in libxl_device_disk_add Signed-off-by: Ian Campbell diff -r 5f72f4fd7f04 -r 662621bcecd5 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Sun May 06 10:12:04 2012 +0100 +++ b/tools/libxl/libxl.c Tue May 08 14:24:31 2012 +0100 @@ -1351,6 +1351,8 @@ int libxl_device_disk_add(libxl_ctx *ctx case LIBXL_DISK_BACKEND_TAP: dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); if (!dev) { + LOG(ERROR, "failed to get blktap devpath for %p\n", + disk->pdev_path); rc = ERROR_FAIL; goto out_free; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:28:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:28:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkSU-0002nJ-Ga; Tue, 08 May 2012 13:28:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkSS-0002nD-Mt for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:28:05 +0000 Received: from [193.109.254.147:49306] by server-2.bemta-14.messagelabs.com id 45/14-19409-46F19AF4; Tue, 08 May 2012 13:28:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336483683!8214602!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20690 invoked from network); 8 May 2012 13:28:03 -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; 8 May 2012 13:28:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355933" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:27: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, 8 May 2012 14:27:00 +0100 Message-ID: <1336483619.14542.86.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen.org Date: Tue, 8 May 2012 14:26:59 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:25 +0100, xen.org wrote: > flight 12800 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/ > > Failures :-/ but no regressions. > > Tests which are failing intermittently (not blocking): > test-amd64-i386-rhel6hvm-amd 7 redhat-install fail pass in 12797 2012-05-08 07:11:44 Z executing ssh ... root@10.80.249.57 xl create /etc/xen/redhat.guest.osstest.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->000000000019bca4 TOTAL: 0000000000000000->000000002f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x000000000000017b 1GB PAGES: 0x0000000000000000 libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 libxl: error: libxl_create.c:628:do_domain_create: cannot add disk 1 to domain: -3 libxl: error: libxl_dm.c:1045:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory libxl: error: libxl.c:1094:libxl_domain_destroy: libxl__destroy_device_model failed for 2 Parsing config file /etc/xen/redhat.guest.osstest.cfg -3 is ERROR_FAIL from libxl_device_disk_add() and I don't see anything else in the logs. Weird thing is I don't see any logs from libxl__device_disk_set_backend which is unconditionally the first thing libxl_device_disk_add calls and which always logs something with at least LIBXL__LOG_DEBUG -- which I expected would go to /var/log/xen/xl-NAME.log but http://www.chiark.greenend.org.uk/~xensrcts/logs/12800/test-amd64-i386-rhel6hvm-amd/potato-beetle---var-log-xen-xl-redhat.guest.osstest.log doesn't have anything. However I suspect that is the log of the previous boot of the guest -- in which case where is the log from this one? Ignoring the missing logs, the only place I can see an ERROR_FAIL from libxl_device_disk_add is the call to libxl__blktap_devpath, which is unlogged (patch below). Both 12797 (previous pass) and 12800 (this fail) seem to be testing the same Xen version (8f1e0cc4a507), so I'm not sure what changed. Ian. 8<-------------------------------------- # HG changeset patch # User Ian Campbell # Date 1336483471 -3600 # Node ID 662621bcecd59b34acfda54a4c8d360389a40536 # Parent 5f72f4fd7f048c2e325c5070bb7adcc216b5772f libxl: log failure from libxl__blktap_devpath in libxl_device_disk_add Signed-off-by: Ian Campbell diff -r 5f72f4fd7f04 -r 662621bcecd5 tools/libxl/libxl.c --- a/tools/libxl/libxl.c Sun May 06 10:12:04 2012 +0100 +++ b/tools/libxl/libxl.c Tue May 08 14:24:31 2012 +0100 @@ -1351,6 +1351,8 @@ int libxl_device_disk_add(libxl_ctx *ctx case LIBXL_DISK_BACKEND_TAP: dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); if (!dev) { + LOG(ERROR, "failed to get blktap devpath for %p\n", + disk->pdev_path); rc = ERROR_FAIL; goto out_free; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:31:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRkVQ-0002tf-3R; Tue, 08 May 2012 13:31:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkVO-0002tY-JI for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:31:06 +0000 Received: from [85.158.139.83:16700] by server-9.bemta-5.messagelabs.com id 4E/A4-09826-91029AF4; Tue, 08 May 2012 13:31:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336483864!19944906!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9347 invoked from network); 8 May 2012 13:31:04 -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; 8 May 2012 13:31:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:30: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, 8 May 2012 14:30:01 +0100 Message-ID: <1336483800.14542.88.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 14:30:00 +0100 In-Reply-To: <1336483376041-5694297.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > > When we went through this on you last posting this seemed to be related > > to the python path stuff on Ubuntu/Debian. However you don't mention > > tweaking that in your setup -- are you sure you have corrected this > > issue? > > > > If this isn't the issue then please can you provide (separately) full > > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > > > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not > domU pv boot error. Your logs seem to show the opposite -- pygrub still fails by pvgrub works ok. > -------------------------------------- > lucid.cfg > -------- > name="lucid" > vcpus=2 > memory=512 > disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', > '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] > vif=['bridge=xenbr0'] > vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] > bootloader = '/usr/bin/pygrub' > #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > #extra = "(hd0,0)/grub/grub.cfg" > -------------------------------------- > > With pygrub: > -------------------------------------- > xl -vvv create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching > tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 Do you still get the same error about xen.lowlevel.xc as before if you run pygrub /mnt/vm/disks/lucid.disk1.xm by hand? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:31:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 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 ) id 1SRkVQ-0002tf-3R; Tue, 08 May 2012 13:31:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkVO-0002tY-JI for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:31:06 +0000 Received: from [85.158.139.83:16700] by server-9.bemta-5.messagelabs.com id 4E/A4-09826-91029AF4; Tue, 08 May 2012 13:31:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336483864!19944906!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9347 invoked from network); 8 May 2012 13:31:04 -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; 8 May 2012 13:31:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12355996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:30: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, 8 May 2012 14:30:01 +0100 Message-ID: <1336483800.14542.88.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 14:30:00 +0100 In-Reply-To: <1336483376041-5694297.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > > When we went through this on you last posting this seemed to be related > > to the python path stuff on Ubuntu/Debian. However you don't mention > > tweaking that in your setup -- are you sure you have corrected this > > issue? > > > > If this isn't the issue then please can you provide (separately) full > > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. > > > "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not > domU pv boot error. Your logs seem to show the opposite -- pygrub still fails by pvgrub works ok. > -------------------------------------- > lucid.cfg > -------- > name="lucid" > vcpus=2 > memory=512 > disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', > '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] > vif=['bridge=xenbr0'] > vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] > bootloader = '/usr/bin/pygrub' > #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > #extra = "(hd0,0)/grub/grub.cfg" > -------------------------------------- > > With pygrub: > -------------------------------------- > xl -vvv create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching > tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 Do you still get the same error about xen.lowlevel.xc as before if you run pygrub /mnt/vm/disks/lucid.disk1.xm by hand? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:38:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkcF-000381-VQ; Tue, 08 May 2012 13:38:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkcE-00037w-Pd for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:38:10 +0000 Received: from [193.109.254.147:40270] by server-10.bemta-14.messagelabs.com id A6/12-05847-2C129AF4; Tue, 08 May 2012 13:38:10 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-8.tower-27.messagelabs.com!1336484288!8230853!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4347 invoked from network); 8 May 2012 13:38:09 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:38:09 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRkcB-00066W-B7 for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:38:07 -0700 Date: Tue, 8 May 2012 06:38:07 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336484287336-5694426.post@n5.nabble.com> In-Reply-To: <1336483800.14542.88.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> > When we went through this on you last posting this seemed to be related >> > to the python path stuff on Ubuntu/Debian. However you don't mention >> > tweaking that in your setup -- are you sure you have corrected this >> > issue? >> > >> > If this isn't the issue then please can you provide (separately) full >> > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. >> > >> "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not >> domU pv boot error. > > Your logs seem to show the opposite -- pygrub still fails by pvgrub > works ok. > >> -------------------------------------- >> lucid.cfg >> -------- >> name="lucid" >> vcpus=2 >> memory=512 >> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', >> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] >> vif=['bridge=xenbr0'] >> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] >> bootloader = '/usr/bin/pygrub' >> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" >> #extra = "(hd0,0)/grub/grub.cfg" >> -------------------------------------- >> >> With pygrub: >> -------------------------------------- >> xl -vvv create /etc/xen/lucid.cfg >> Parsing config file /etc/xen/lucid.cfg >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda1, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda2 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda2, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=tap >> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally >> attaching >> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) >> libxl: error: libxl_create.c:603:do_domain_create: failed to run >> bootloader: >> -3 > > Do you still get the same error about xen.lowlevel.xc as before if you > run > pygrub /mnt/vm/disks/lucid.disk1.xm > by hand? > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > --------------------------------------------- pygrub /mnt/vm/disks/lucid.disk1.xm Traceback (most recent call last): File "/usr/local/bin/pygrub", line 822, in raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel --------------------------------------------- About pv-grub I think it fails with: ... (from xl create...) xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel ... And after seems start as hvm domU but is not working and I must destroy it. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694426.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:38:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkcF-000381-VQ; Tue, 08 May 2012 13:38:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkcE-00037w-Pd for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:38:10 +0000 Received: from [193.109.254.147:40270] by server-10.bemta-14.messagelabs.com id A6/12-05847-2C129AF4; Tue, 08 May 2012 13:38:10 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-8.tower-27.messagelabs.com!1336484288!8230853!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4347 invoked from network); 8 May 2012 13:38:09 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:38:09 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRkcB-00066W-B7 for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:38:07 -0700 Date: Tue, 8 May 2012 06:38:07 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336484287336-5694426.post@n5.nabble.com> In-Reply-To: <1336483800.14542.88.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > On Tue, 2012-05-08 at 14:22 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> > When we went through this on you last posting this seemed to be related >> > to the python path stuff on Ubuntu/Debian. However you don't mention >> > tweaking that in your setup -- are you sure you have corrected this >> > issue? >> > >> > If this isn't the issue then please can you provide (separately) full >> > logs (xl cr -vvv & /var/log/xen/foo, etc) for both these cases. >> > >> "PYTHON_PREFIX_ARG =" in Config.mk solves python error on pygrub but not >> domU pv boot error. > > Your logs seem to show the opposite -- pygrub still fails by pvgrub > works ok. > >> -------------------------------------- >> lucid.cfg >> -------- >> name="lucid" >> vcpus=2 >> memory=512 >> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw', >> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw'] >> vif=['bridge=xenbr0'] >> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] >> bootloader = '/usr/bin/pygrub' >> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" >> #extra = "(hd0,0)/grub/grub.cfg" >> -------------------------------------- >> >> With pygrub: >> -------------------------------------- >> xl -vvv create /etc/xen/lucid.cfg >> Parsing config file /etc/xen/lucid.cfg >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda1, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda2 spec.backend=unknown >> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, >> backend >> phy unsuitable as phys path not a block device >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk >> vdev=xvda2, using backend tap >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk >> vdev=xvda1 spec.backend=tap >> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally >> attaching >> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) >> libxl: error: libxl_create.c:603:do_domain_create: failed to run >> bootloader: >> -3 > > Do you still get the same error about xen.lowlevel.xc as before if you > run > pygrub /mnt/vm/disks/lucid.disk1.xm > by hand? > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > --------------------------------------------- pygrub /mnt/vm/disks/lucid.disk1.xm Traceback (most recent call last): File "/usr/local/bin/pygrub", line 822, in raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel --------------------------------------------- About pv-grub I think it fails with: ... (from xl create...) xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel ... And after seems start as hvm domU but is not working and I must destroy it. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694426.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkjt-0003Iy-4S; Tue, 08 May 2012 13:46:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkjr-0003It-GK for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:46:03 +0000 Received: from [85.158.143.35:34063] by server-2.bemta-4.messagelabs.com id 61/47-17550-A9329AF4; Tue, 08 May 2012 13:46:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336484760!13667569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15030 invoked from network); 8 May 2012 13:46:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 13:46:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12356372" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:46: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, 8 May 2012 14:46:00 +0100 Message-ID: <1336484759.14542.91.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 14:45:59 +0100 In-Reply-To: <1336484287336-5694426.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 14:38 +0100, Fantu wrote: > --------------------------------------------- > pygrub /mnt/vm/disks/lucid.disk1.xm > Traceback (most recent call last): > File "/usr/local/bin/pygrub", line 822, in > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel /usr/local/bin? Are you sure this is the pygrub you built and installed just now and not some other cruft? Are you able to identify when it last worked and run a bisect? You don't need to do a full boot of the guest, just run pygrub manually at each stage. > --------------------------------------------- > > About pv-grub I think it fails with: > ... (from xl create...) > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > ... > And after seems start as hvm domU but is not working and I must destroy it. I think this is just a warning (which needs to be toned down), since the pvgrub kernel isn't a bzImage, it's a simple elf file. Your logs show it building a Mini-OS domain, not an HVM one: domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff I think if you investigate more closely you would find it is working, at least as far as building an running something.. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkjt-0003Iy-4S; Tue, 08 May 2012 13:46:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkjr-0003It-GK for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:46:03 +0000 Received: from [85.158.143.35:34063] by server-2.bemta-4.messagelabs.com id 61/47-17550-A9329AF4; Tue, 08 May 2012 13:46:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336484760!13667569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15030 invoked from network); 8 May 2012 13:46:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 13:46:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12356372" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 13:46: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, 8 May 2012 14:46:00 +0100 Message-ID: <1336484759.14542.91.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 14:45:59 +0100 In-Reply-To: <1336484287336-5694426.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 14:38 +0100, Fantu wrote: > --------------------------------------------- > pygrub /mnt/vm/disks/lucid.disk1.xm > Traceback (most recent call last): > File "/usr/local/bin/pygrub", line 822, in > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel /usr/local/bin? Are you sure this is the pygrub you built and installed just now and not some other cruft? Are you able to identify when it last worked and run a bisect? You don't need to do a full boot of the guest, just run pygrub manually at each stage. > --------------------------------------------- > > About pv-grub I think it fails with: > ... (from xl create...) > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > kernel is not a bzImage: Invalid kernel > ... > And after seems start as hvm domU but is not working and I must destroy it. I think this is just a warning (which needs to be toned down), since the pvgrub kernel isn't a bzImage, it's a simple elf file. Your logs show it building a Mini-OS domain, not an HVM one: domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff I think if you investigate more closely you would find it is working, at least as far as building an running something.. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRksP-0003Sh-AV; Tue, 08 May 2012 13:54:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRksM-0003Sc-VM for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:54:51 +0000 Received: from [85.158.143.99:26055] by server-1.bemta-4.messagelabs.com id DC/2B-20925-AA529AF4; Tue, 08 May 2012 13:54:50 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-9.tower-216.messagelabs.com!1336485288!27036084!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10594 invoked from network); 8 May 2012 13:54:49 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:54:49 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRksK-0008BX-8l for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:54:48 -0700 Date: Tue, 8 May 2012 06:54:48 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336485288265-5694597.post@n5.nabble.com> In-Reply-To: <1336484759.14542.91.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > Your logs show it building a Mini-OS domain, not an HVM one: > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic > loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > > I think if you investigate more closely you would find it is working, at > least as far as building an running something.. > Please try to see further in the xl create output on pv-grub test... ... libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 ... Is it right? -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694597.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRksP-0003Sh-AV; Tue, 08 May 2012 13:54:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRksM-0003Sc-VM for xen-devel@lists.xensource.com; Tue, 08 May 2012 13:54:51 +0000 Received: from [85.158.143.99:26055] by server-1.bemta-4.messagelabs.com id DC/2B-20925-AA529AF4; Tue, 08 May 2012 13:54:50 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-9.tower-216.messagelabs.com!1336485288!27036084!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10594 invoked from network); 8 May 2012 13:54:49 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 8 May 2012 13:54:49 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SRksK-0008BX-8l for xen-devel@lists.xensource.com; Tue, 08 May 2012 06:54:48 -0700 Date: Tue, 8 May 2012 06:54:48 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336485288265-5694597.post@n5.nabble.com> In-Reply-To: <1336484759.14542.91.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > Your logs show it building a Mini-OS domain, not an HVM one: > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic > loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > > I think if you investigate more closely you would find it is working, at > least as far as building an running something.. > Please try to see further in the xl create output on pv-grub test... ... libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 ... Is it right? -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5694597.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:59:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkwE-0003aF-Uw; Tue, 08 May 2012 13:58:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkwD-0003a7-GU for xen-devel@lists.xen.org; Tue, 08 May 2012 13:58:49 +0000 Received: from [85.158.138.51:57598] by server-6.bemta-3.messagelabs.com id FF/51-05145-89629AF4; Tue, 08 May 2012 13:58:48 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336485526!16976511!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2540 invoked from network); 8 May 2012 13:58:47 -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; 8 May 2012 13:58:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193855837" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:58:45 -0400 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, 8 May 2012 09:58:45 -0400 Message-ID: <4FA92694.4000204@citrix.com> Date: Tue, 8 May 2012 14:58:44 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> <4FA41D83.2010809@citrix.com> <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> In-Reply-To: <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/12 09:19, Jan Beulich wrote: >> Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible >> >> The dom0_max_vcpus command line option only allows the exact number of >> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >> but no more than the number physically present." >> >> Allow a range for the option to set a minimum number of VCPUs, and a >> maximum which does not exceed the number of PCPUs. >> >> For example, with "dom0_max_vcpus=4-8": >> >> PCPUs Dom0 VCPUs >> 2 4 >> 4 4 >> 6 6 >> 8 8 >> 10 8 >> >> Existing command lines with "dom0_max_vcpus=N" still work as before. >> >> Signed-off-by: David Vrabel > > Acked-by: Jan Beulich > > But I'm not sure whether this qualifies for going in for 4.2... I don't think it's a 4.2 candidate. I posted it now we need this functionality in XenServer and I didn't want to change the command line in a way that would be incompatible with upstream. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 13:59:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 13: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 ) id 1SRkwE-0003aF-Uw; Tue, 08 May 2012 13:58:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkwD-0003a7-GU for xen-devel@lists.xen.org; Tue, 08 May 2012 13:58:49 +0000 Received: from [85.158.138.51:57598] by server-6.bemta-3.messagelabs.com id FF/51-05145-89629AF4; Tue, 08 May 2012 13:58:48 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336485526!16976511!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2540 invoked from network); 8 May 2012 13:58:47 -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; 8 May 2012 13:58:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193855837" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 09:58:45 -0400 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, 8 May 2012 09:58:45 -0400 Message-ID: <4FA92694.4000204@citrix.com> Date: Tue, 8 May 2012 14:58:44 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1336147301-12681-1-git-send-email-david.vrabel@citrix.com> <4FA41BF20200007800081BFE@nat28.tlf.novell.com> <4FA40321.3080201@citrix.com> <4FA41D83.2010809@citrix.com> <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> In-Reply-To: <4FA7A1AB0200007800081F71@nat28.tlf.novell.com> Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more flexible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/12 09:19, Jan Beulich wrote: >> Subject: [PATCH] x86: make the dom0_max_vcpus option more flexible >> >> The dom0_max_vcpus command line option only allows the exact number of >> VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs >> but no more than the number physically present." >> >> Allow a range for the option to set a minimum number of VCPUs, and a >> maximum which does not exceed the number of PCPUs. >> >> For example, with "dom0_max_vcpus=4-8": >> >> PCPUs Dom0 VCPUs >> 2 4 >> 4 4 >> 6 6 >> 8 8 >> 10 8 >> >> Existing command lines with "dom0_max_vcpus=N" still work as before. >> >> Signed-off-by: David Vrabel > > Acked-by: Jan Beulich > > But I'm not sure whether this qualifies for going in for 4.2... I don't think it's a 4.2 candidate. I posted it now we need this functionality in XenServer and I didn't want to change the command line in a way that would be incompatible with upstream. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:01:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14: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 ) id 1SRkyZ-0003l2-GD; Tue, 08 May 2012 14:01:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkyY-0003ks-9Z for xen-devel@lists.xensource.com; Tue, 08 May 2012 14:01:14 +0000 Received: from [85.158.139.83:42510] by server-10.bemta-5.messagelabs.com id 67/B7-08260-92729AF4; Tue, 08 May 2012 14:01:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336485672!26613300!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15393 invoked from network); 8 May 2012 14:01:13 -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; 8 May 2012 14:01:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12356791" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:01:12 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 15:01:12 +0100 Message-ID: <1336485670.14542.92.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu , Ian Jackson Date: Tue, 8 May 2012 15:01:10 +0100 In-Reply-To: <1336484759.14542.91.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > About pv-grub I think it fails with: > > ... (from xl create...) > > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > > kernel is not a bzImage: Invalid kernel > > ... > > And after seems start as hvm domU but is not working and I must destroy it. > > I think this is just a warning (which needs to be toned down), since the > pvgrub kernel isn't a bzImage, it's a simple elf file. # HG changeset patch # User Ian Campbell # Date 1336485612 -3600 # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 libxc: do not "panic" if a kernel is not a bzImage. Up untul the point where we think this is a bzImage there is no point in printing panicy messages -- some other loader will have a go (probably the compressed ELF one) Signed-off-by: Ian Campbell diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( dom->kernel_size < sizeof(struct setup_header) ) { - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, - "%s: kernel image too small", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__); return -EINVAL; } @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) { - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, - "%s: kernel is not a bzImage", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__); return -EINVAL; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:01:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14: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 ) id 1SRkyZ-0003l2-GD; Tue, 08 May 2012 14:01:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRkyY-0003ks-9Z for xen-devel@lists.xensource.com; Tue, 08 May 2012 14:01:14 +0000 Received: from [85.158.139.83:42510] by server-10.bemta-5.messagelabs.com id 67/B7-08260-92729AF4; Tue, 08 May 2012 14:01:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336485672!26613300!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15393 invoked from network); 8 May 2012 14:01:13 -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; 8 May 2012 14:01:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12356791" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:01:12 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 15:01:12 +0100 Message-ID: <1336485670.14542.92.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu , Ian Jackson Date: Tue, 8 May 2012 15:01:10 +0100 In-Reply-To: <1336484759.14542.91.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > About pv-grub I think it fails with: > > ... (from xl create...) > > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: > > kernel is not a bzImage: Invalid kernel > > ... > > And after seems start as hvm domU but is not working and I must destroy it. > > I think this is just a warning (which needs to be toned down), since the > pvgrub kernel isn't a bzImage, it's a simple elf file. # HG changeset patch # User Ian Campbell # Date 1336485612 -3600 # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 libxc: do not "panic" if a kernel is not a bzImage. Up untul the point where we think this is a bzImage there is no point in printing panicy messages -- some other loader will have a go (probably the compressed ELF one) Signed-off-by: Ian Campbell diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( dom->kernel_size < sizeof(struct setup_header) ) { - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, - "%s: kernel image too small", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__); return -EINVAL; } @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) { - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, - "%s: kernel is not a bzImage", __FUNCTION__); + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__); return -EINVAL; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:03:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:03:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl0D-0003ri-87; Tue, 08 May 2012 14:02:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl0C-0003rZ-1W for xen-devel@lists.xen.org; Tue, 08 May 2012 14:02:56 +0000 Received: from [85.158.139.83:38498] by server-5.bemta-5.messagelabs.com id 2A/C3-13566-F8729AF4; Tue, 08 May 2012 14:02:55 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-182.messagelabs.com!1336485773!23423419!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3198 invoked from network); 8 May 2012 14:02:54 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-6.tower-182.messagelabs.com with SMTP; 8 May 2012 14:02:54 -0000 X-TM-IMSS-Message-ID: <2e008ee9000b92bf@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2e008ee9000b92bf ; Tue, 8 May 2012 09:48:28 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q48DmASc032587; Tue, 8 May 2012 09:48:10 -0400 From: Daniel De Graaf To: konrad.wilk@oracle.com Date: Tue, 8 May 2012 09:46:57 -0400 Message-Id: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 Cc: Daniel De Graaf , JBeulich@suse.com, xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus backend to be started after the kernel has booted. This allows xenstore to run in a different domain from the dom0. Signed-off-by: Daniel De Graaf --- 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 #include +#include #include +#include +#include +#include #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 +#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.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:03:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:03:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl0D-0003ri-87; Tue, 08 May 2012 14:02:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl0C-0003rZ-1W for xen-devel@lists.xen.org; Tue, 08 May 2012 14:02:56 +0000 Received: from [85.158.139.83:38498] by server-5.bemta-5.messagelabs.com id 2A/C3-13566-F8729AF4; Tue, 08 May 2012 14:02:55 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-182.messagelabs.com!1336485773!23423419!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3198 invoked from network); 8 May 2012 14:02:54 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-6.tower-182.messagelabs.com with SMTP; 8 May 2012 14:02:54 -0000 X-TM-IMSS-Message-ID: <2e008ee9000b92bf@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2e008ee9000b92bf ; Tue, 8 May 2012 09:48:28 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q48DmASc032587; Tue, 8 May 2012 09:48:10 -0400 From: Daniel De Graaf To: konrad.wilk@oracle.com Date: Tue, 8 May 2012 09:46:57 -0400 Message-Id: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 Cc: Daniel De Graaf , JBeulich@suse.com, xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus backend to be started after the kernel has booted. This allows xenstore to run in a different domain from the dom0. Signed-off-by: Daniel De Graaf --- 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 #include +#include #include +#include +#include +#include #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 +#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.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:10:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:10:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl6l-00047r-3R; Tue, 08 May 2012 14:09:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl6j-00047m-GJ for xen-devel@lists.xen.org; Tue, 08 May 2012 14:09:41 +0000 Received: from [85.158.143.99:24110] by server-2.bemta-4.messagelabs.com id 6D/5E-17550-42929AF4; Tue, 08 May 2012 14:09:40 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1336486178!19977032!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31399 invoked from network); 8 May 2012 14:09:39 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 14:09:39 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id D99EF541C6; Tue, 8 May 2012 16:09:36 +0200 (CEST) Date: Tue, 8 May 2012 16:09:36 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120508140936.GA25033@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , xen-devel References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote: > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. For the beginning, I have the following points: * xs.h -> xenstore.h * Directory usage in libxl - dumps in /var/xen: wtf? - user data files in /var/lib/xen: What are the guarantees given for this files? - /var/run/libxl for temporary files Bastian -- Deflector shields just came on, Captain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:10:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:10:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl6l-00047r-3R; Tue, 08 May 2012 14:09:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRl6j-00047m-GJ for xen-devel@lists.xen.org; Tue, 08 May 2012 14:09:41 +0000 Received: from [85.158.143.99:24110] by server-2.bemta-4.messagelabs.com id 6D/5E-17550-42929AF4; Tue, 08 May 2012 14:09:40 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-6.tower-216.messagelabs.com!1336486178!19977032!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31399 invoked from network); 8 May 2012 14:09:39 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 14:09:39 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id D99EF541C6; Tue, 8 May 2012 16:09:36 +0200 (CEST) Date: Tue, 8 May 2012 16:09:36 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120508140936.GA25033@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , xen-devel References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote: > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. For the beginning, I have the following points: * xs.h -> xenstore.h * Directory usage in libxl - dumps in /var/xen: wtf? - user data files in /var/lib/xen: What are the guarantees given for this files? - /var/run/libxl for temporary files Bastian -- Deflector shields just came on, Captain. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:22:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlIn-0004Hx-BO; Tue, 08 May 2012 14:22:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlIm-0004Hs-DD for xen-devel@lists.xensource.com; Tue, 08 May 2012 14:22:08 +0000 Received: from [85.158.143.35:45419] by server-2.bemta-4.messagelabs.com id 0D/D2-17550-F0C29AF4; Tue, 08 May 2012 14:22:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336486925!14484907!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25207 invoked from network); 8 May 2012 14:22:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:22:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193861051" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:21:50 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:21:49 -0400 Message-ID: <1336486906.13218.0.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 15:21:46 +0100 In-Reply-To: <1336485288265-5694597.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485288265-5694597.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org [...] > Please try to see further in the xl create output on pv-grub test... > ... > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > ... > Is it right? It's not inherently wrong. A PV guest can end up with a qemu service process to provide backends, like disk or VNC etc. So the presence of a qemu does not necessarily imply an HVM guest. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:22:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlIn-0004Hx-BO; Tue, 08 May 2012 14:22:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlIm-0004Hs-DD for xen-devel@lists.xensource.com; Tue, 08 May 2012 14:22:08 +0000 Received: from [85.158.143.35:45419] by server-2.bemta-4.messagelabs.com id 0D/D2-17550-F0C29AF4; Tue, 08 May 2012 14:22:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336486925!14484907!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25207 invoked from network); 8 May 2012 14:22:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:22:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193861051" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:21:50 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:21:49 -0400 Message-ID: <1336486906.13218.0.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Fantu Date: Tue, 8 May 2012 15:21:46 +0100 In-Reply-To: <1336485288265-5694597.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485288265-5694597.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org [...] > Please try to see further in the xl create output on pv-grub test... > ... > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > ... > Is it right? It's not inherently wrong. A PV guest can end up with a qemu service process to provide backends, like disk or VNC etc. So the presence of a qemu does not necessarily imply an HVM guest. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:39:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14: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 ) id 1SRlZD-0004T9-Sm; Tue, 08 May 2012 14:39:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlZB-0004T4-PB for xen-devel@lists.xen.org; Tue, 08 May 2012 14:39:05 +0000 Received: from [85.158.143.99:42733] by server-1.bemta-4.messagelabs.com id BA/D4-20925-90039AF4; Tue, 08 May 2012 14:39:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336487942!21740351!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24024 invoked from network); 8 May 2012 14:39:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:39:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193864790" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:38:52 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:38:52 -0400 Message-ID: <1336487933.13218.9.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Bastian Blank Date: Tue, 8 May 2012 15:38:53 +0100 In-Reply-To: <20120508140936.GA25033@wavehammer.waldi.eu.org> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian.Jackson@citrix.com, xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote: > > The updated TODO list follows. Per the release plan a strong case will > > now have to be made as to why new items should be added to the list, > > especially as a blocker, rather than deferred to 4.3. > > For the beginning, I have the following points: > > * xs.h -> xenstore.h I think there was general agreement that this should be done for 4.2. > * Directory usage in libxl > - dumps in /var/xen: wtf? This is the same location as xend uses, so in that sense it is compatible. However I don't think this is somewhere that xl (nb: this is a property of xl, not libxl) needs to slavishly follow what xend did. What would the correct FHS location for these dumps be? > - user data files in /var/lib/xen: > What are the guarantees given for this files? I suppose you are asking for /var/lib vs /var/run (or /run) reasons? One of the keys by which you lookup this userdata is domid. Which means that the lifetime of this data is bounded by the life of a domain. Which means that it need not persist over reboot (which I think argues for (/var)?/run) I suppose the other interesting facet is allowable size. The description of the interface doesn't have anything to say about size. Ian J -- any thoughts? > - /var/run/libxl for temporary files Are you suggesting that this is being wrongly used by libxl, or that libxl should use this location for more things than it currently does? Perhaps some stuff should instead be in /tmp or $TMPDIR? Other than the xs.h naming issue I don't see anything here which I think is a blocker for 4.2, I'd say they are mostly "nice to have". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:39:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14: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 ) id 1SRlZD-0004T9-Sm; Tue, 08 May 2012 14:39:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlZB-0004T4-PB for xen-devel@lists.xen.org; Tue, 08 May 2012 14:39:05 +0000 Received: from [85.158.143.99:42733] by server-1.bemta-4.messagelabs.com id BA/D4-20925-90039AF4; Tue, 08 May 2012 14:39:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336487942!21740351!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24024 invoked from network); 8 May 2012 14:39:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:39:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193864790" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:38:52 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:38:52 -0400 Message-ID: <1336487933.13218.9.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Bastian Blank Date: Tue, 8 May 2012 15:38:53 +0100 In-Reply-To: <20120508140936.GA25033@wavehammer.waldi.eu.org> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian.Jackson@citrix.com, xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote: > > The updated TODO list follows. Per the release plan a strong case will > > now have to be made as to why new items should be added to the list, > > especially as a blocker, rather than deferred to 4.3. > > For the beginning, I have the following points: > > * xs.h -> xenstore.h I think there was general agreement that this should be done for 4.2. > * Directory usage in libxl > - dumps in /var/xen: wtf? This is the same location as xend uses, so in that sense it is compatible. However I don't think this is somewhere that xl (nb: this is a property of xl, not libxl) needs to slavishly follow what xend did. What would the correct FHS location for these dumps be? > - user data files in /var/lib/xen: > What are the guarantees given for this files? I suppose you are asking for /var/lib vs /var/run (or /run) reasons? One of the keys by which you lookup this userdata is domid. Which means that the lifetime of this data is bounded by the life of a domain. Which means that it need not persist over reboot (which I think argues for (/var)?/run) I suppose the other interesting facet is allowable size. The description of the interface doesn't have anything to say about size. Ian J -- any thoughts? > - /var/run/libxl for temporary files Are you suggesting that this is being wrongly used by libxl, or that libxl should use this location for more things than it currently does? Perhaps some stuff should instead be in /tmp or $TMPDIR? Other than the xs.h naming issue I don't see anything here which I think is a blocker for 4.2, I'd say they are mostly "nice to have". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:55:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRloa-0004eq-P2; Tue, 08 May 2012 14:55:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRloZ-0004el-Ge for xen-devel@lists.xen.org; Tue, 08 May 2012 14:54:59 +0000 Received: from [85.158.139.83:8353] by server-5.bemta-5.messagelabs.com id 01/12-13566-2C339AF4; Tue, 08 May 2012 14:54:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336488898!27305484!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8781 invoked from network); 8 May 2012 14:54:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:54:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12358310" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:54: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; Tue, 8 May 2012 15:54:56 +0100 Date: Tue, 8 May 2012 15:54:24 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1336474322.14542.61.camel@zakaz.uk.xensource.com> Message-ID: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Stefano Stabellini , Ian Jackson , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 8 May 2012, Ian Campbell wrote: > Where are we with the following? > > I've not seen anything recently about PCI passthrough. The last patch series that was sent is: http://marc.info/?l=qemu-devel&m=133346733411606&w=2 it is still stuck waiting for reviews. Given that QEMU is in freeze for the next release release now, I don't think anything is going to happen in the next few weeks. I could backport the patch series to the upstream QEMU tree that we use with xen-unstable, but considering that we are in freeze ourselves and that upstream QEMU is not used by default with HVM guests we might as well wait for the beginning of the next release cycle. > Is it still the case that save/restore is waiting on lib{c,l} patches > and Remus is waiting for those? What's the hold up there? The libxl save/restore patches haven't been applied yet. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 14:55:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 14:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRloa-0004eq-P2; Tue, 08 May 2012 14:55:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRloZ-0004el-Ge for xen-devel@lists.xen.org; Tue, 08 May 2012 14:54:59 +0000 Received: from [85.158.139.83:8353] by server-5.bemta-5.messagelabs.com id 01/12-13566-2C339AF4; Tue, 08 May 2012 14:54:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336488898!27305484!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8781 invoked from network); 8 May 2012 14:54:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 14:54:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="12358310" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:54: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; Tue, 8 May 2012 15:54:56 +0100 Date: Tue, 8 May 2012 15:54:24 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1336474322.14542.61.camel@zakaz.uk.xensource.com> Message-ID: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Stefano Stabellini , Ian Jackson , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 8 May 2012, Ian Campbell wrote: > Where are we with the following? > > I've not seen anything recently about PCI passthrough. The last patch series that was sent is: http://marc.info/?l=qemu-devel&m=133346733411606&w=2 it is still stuck waiting for reviews. Given that QEMU is in freeze for the next release release now, I don't think anything is going to happen in the next few weeks. I could backport the patch series to the upstream QEMU tree that we use with xen-unstable, but considering that we are in freeze ourselves and that upstream QEMU is not used by default with HVM guests we might as well wait for the beginning of the next release cycle. > Is it still the case that save/restore is waiting on lib{c,l} patches > and Remus is waiting for those? What's the hold up there? The libxl save/restore patches haven't been applied yet. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:00:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:00:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRltj-0004oi-H5; Tue, 08 May 2012 15:00:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlti-0004ob-5T for xen-devel@lists.xen.org; Tue, 08 May 2012 15:00:18 +0000 Received: from [85.158.143.35:50192] by server-3.bemta-4.messagelabs.com id AD/36-05853-00539AF4; Tue, 08 May 2012 15:00:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336489212!10130759!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20207 invoked from network); 8 May 2012 15:00:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 15:00:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193869487" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:59:33 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:59:33 -0400 Message-ID: <1336489170.13218.11.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Stefano Stabellini Date: Tue, 8 May 2012 15:59:30 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Ian Jackson , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > On Tue, 8 May 2012, Ian Campbell wrote: > > Where are we with the following? > > > > I've not seen anything recently about PCI passthrough. > > The last patch series that was sent is: > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > the next release release now, I don't think anything is going to happen > in the next few weeks. > I could backport the patch series to the upstream QEMU tree that we use > with xen-unstable, but considering that we are in freeze ourselves and > that upstream QEMU is not used by default with HVM guests we > might as well wait for the beginning of the next release cycle. Thanks. I will mark these as "deferred to 4.3" and remove from the list. If they do go into upstream we can revisit whether we backport. > > Is it still the case that save/restore is waiting on lib{c,l} patches > > and Remus is waiting for those? What's the hold up there? > > The libxl save/restore patches haven't been applied yet. Ian J -- have you dropped these or are you waiting for something? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:00:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:00:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRltj-0004oi-H5; Tue, 08 May 2012 15:00:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRlti-0004ob-5T for xen-devel@lists.xen.org; Tue, 08 May 2012 15:00:18 +0000 Received: from [85.158.143.35:50192] by server-3.bemta-4.messagelabs.com id AD/36-05853-00539AF4; Tue, 08 May 2012 15:00:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336489212!10130759!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20207 invoked from network); 8 May 2012 15:00:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 15:00:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,551,1330923600"; d="scan'208";a="193869487" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 10:59:33 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 10:59:33 -0400 Message-ID: <1336489170.13218.11.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Stefano Stabellini Date: Tue, 8 May 2012 15:59:30 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , Shriram Rajagopalan , Ian Jackson , xen-devel Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > On Tue, 8 May 2012, Ian Campbell wrote: > > Where are we with the following? > > > > I've not seen anything recently about PCI passthrough. > > The last patch series that was sent is: > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > the next release release now, I don't think anything is going to happen > in the next few weeks. > I could backport the patch series to the upstream QEMU tree that we use > with xen-unstable, but considering that we are in freeze ourselves and > that upstream QEMU is not used by default with HVM guests we > might as well wait for the beginning of the next release cycle. Thanks. I will mark these as "deferred to 4.3" and remove from the list. If they do go into upstream we can revisit whether we backport. > > Is it still the case that save/restore is waiting on lib{c,l} patches > > and Remus is waiting for those? What's the hold up there? > > The libxl save/restore patches haven't been applied yet. Ian J -- have you dropped these or are you waiting for something? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:07:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm0i-00050Y-Dp; Tue, 08 May 2012 15:07:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm0h-00050T-UK for xen-devel@lists.xen.org; Tue, 08 May 2012 15:07:32 +0000 Received: from [85.158.143.35:37216] by server-1.bemta-4.messagelabs.com id 49/73-20925-3B639AF4; Tue, 08 May 2012 15:07:31 +0000 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-8.tower-21.messagelabs.com!1336489648!11321897!1 X-Originating-IP: [142.103.6.52] X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE, INFO_TLD,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3695 invoked from network); 8 May 2012 15:07:30 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:07:30 -0000 Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q48F7CpC025282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 8 May 2012 08:07:13 -0700 Received: by bkwj10 with SMTP id j10so5434516bkw.32 for ; Tue, 08 May 2012 08:07:10 -0700 (PDT) Received: by 10.204.148.83 with SMTP id o19mr7062232bkv.96.1336489630660; Tue, 08 May 2012 08:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.53.198 with HTTP; Tue, 8 May 2012 08:06:30 -0700 (PDT) In-Reply-To: <1336489170.13218.11.camel@cthulhu.hellion.org.uk> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> From: Shriram Rajagopalan Date: Tue, 8 May 2012 10:06:30 -0500 Message-ID: To: Ian Campbell Cc: Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3403722634409047213==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3403722634409047213== Content-Type: multipart/alternative; boundary=0015175cdc56ae79d104bf87bdcd --0015175cdc56ae79d104bf87bdcd Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 8, 2012 at 9:59 AM, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I've not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > > the next release release now, I don't think anything is going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree that we use > > with xen-unstable, but considering that we are in freeze ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release cycle. > > Thanks. I will mark these as "deferred to 4.3" and remove from the list. > If they do go into upstream we can revisit whether we backport. > > > > Is it still the case that save/restore is waiting on lib{c,l} patches > > > and Remus is waiting for those? What's the hold up there? > > > > The libxl save/restore patches haven't been applied yet. > > Ian J -- have you dropped these or are you waiting for something? > > > Ian J, also note that the remus libxl patches may not apply cleanly after applying stefano's patches (even these might require some re-basing), given that a lot of patches that came in later (the event based stuff, Ian C's refactorings,etc) went in. If you could just let me know when they have been committed, I can certainly rebase mine and post them. thanks shriram --0015175cdc56ae79d104bf87bdcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 8, 2012 at 9:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wro= te:
> On Tue, 8 May 2012, Ian Campbell wrote:
> > Where are we with the following?
> >
> > I've not seen anything recently about PCI passthrough.
>
> The last patch series that was sent is:
>
> http://marc.info/?l=3Dqemu-devel&m=3D1333467= 33411606&w=3D2
>
> it is still stuck waiting for reviews. Given that QEMU is in freeze fo= r
> the next release release now, I don't think anything is going to h= appen
> in the next few weeks.
> I could backport the patch series to the upstream QEMU tree that we us= e
> with xen-unstable, but considering that we are in freeze ourselves and=
> that upstream QEMU is not used by default with HVM guests we
> might as well wait for the beginning of the next release cycle.

Thanks. I will mark these as "deferred to 4.3" and remove f= rom the list.
If they do go into upstream we can revisit whether we backport.

> > Is it still the case that save/restore is waiting on lib{c,l} pat= ches
> > and Remus is waiting for those? What's the hold up there?
>
> The libxl save/restore patches haven't been applied yet.

Ian J -- have you dropped these or are you waiting for something?<= br>

=A0

=A0
Ian J, also note that t= he remus libxl patches may not apply cleanly after
applying stefa= no's patches (even these might require some re-basing),
given= that a lot of patches that came in later=A0(the event based stuff, Ian C&#= 39;s refactorings,etc)
went in.
If you could just let me know when they have be= en committed, I can certainly
rebase mine and post them.
=A0
thanks
shriram
--0015175cdc56ae79d104bf87bdcd-- --===============3403722634409047213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3403722634409047213==-- From xen-devel-bounces@lists.xen.org Tue May 08 15:07:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm0i-00050Y-Dp; Tue, 08 May 2012 15:07:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm0h-00050T-UK for xen-devel@lists.xen.org; Tue, 08 May 2012 15:07:32 +0000 Received: from [85.158.143.35:37216] by server-1.bemta-4.messagelabs.com id 49/73-20925-3B639AF4; Tue, 08 May 2012 15:07:31 +0000 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-8.tower-21.messagelabs.com!1336489648!11321897!1 X-Originating-IP: [142.103.6.52] X-SpamReason: No, hits=1.8 required=7.0 tests=HTML_30_40,HTML_MESSAGE, INFO_TLD,RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3695 invoked from network); 8 May 2012 15:07:30 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:07:30 -0000 Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q48F7CpC025282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 8 May 2012 08:07:13 -0700 Received: by bkwj10 with SMTP id j10so5434516bkw.32 for ; Tue, 08 May 2012 08:07:10 -0700 (PDT) Received: by 10.204.148.83 with SMTP id o19mr7062232bkv.96.1336489630660; Tue, 08 May 2012 08:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.53.198 with HTTP; Tue, 8 May 2012 08:06:30 -0700 (PDT) In-Reply-To: <1336489170.13218.11.camel@cthulhu.hellion.org.uk> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> From: Shriram Rajagopalan Date: Tue, 8 May 2012 10:06:30 -0500 Message-ID: To: Ian Campbell Cc: Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3403722634409047213==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3403722634409047213== Content-Type: multipart/alternative; boundary=0015175cdc56ae79d104bf87bdcd --0015175cdc56ae79d104bf87bdcd Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 8, 2012 at 9:59 AM, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I've not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > > the next release release now, I don't think anything is going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree that we use > > with xen-unstable, but considering that we are in freeze ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release cycle. > > Thanks. I will mark these as "deferred to 4.3" and remove from the list. > If they do go into upstream we can revisit whether we backport. > > > > Is it still the case that save/restore is waiting on lib{c,l} patches > > > and Remus is waiting for those? What's the hold up there? > > > > The libxl save/restore patches haven't been applied yet. > > Ian J -- have you dropped these or are you waiting for something? > > > Ian J, also note that the remus libxl patches may not apply cleanly after applying stefano's patches (even these might require some re-basing), given that a lot of patches that came in later (the event based stuff, Ian C's refactorings,etc) went in. If you could just let me know when they have been committed, I can certainly rebase mine and post them. thanks shriram --0015175cdc56ae79d104bf87bdcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 8, 2012 at 9:59 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wro= te:
> On Tue, 8 May 2012, Ian Campbell wrote:
> > Where are we with the following?
> >
> > I've not seen anything recently about PCI passthrough.
>
> The last patch series that was sent is:
>
> http://marc.info/?l=3Dqemu-devel&m=3D1333467= 33411606&w=3D2
>
> it is still stuck waiting for reviews. Given that QEMU is in freeze fo= r
> the next release release now, I don't think anything is going to h= appen
> in the next few weeks.
> I could backport the patch series to the upstream QEMU tree that we us= e
> with xen-unstable, but considering that we are in freeze ourselves and=
> that upstream QEMU is not used by default with HVM guests we
> might as well wait for the beginning of the next release cycle.

Thanks. I will mark these as "deferred to 4.3" and remove f= rom the list.
If they do go into upstream we can revisit whether we backport.

> > Is it still the case that save/restore is waiting on lib{c,l} pat= ches
> > and Remus is waiting for those? What's the hold up there?
>
> The libxl save/restore patches haven't been applied yet.

Ian J -- have you dropped these or are you waiting for something?<= br>

=A0

=A0
Ian J, also note that t= he remus libxl patches may not apply cleanly after
applying stefa= no's patches (even these might require some re-basing),
given= that a lot of patches that came in later=A0(the event based stuff, Ian C&#= 39;s refactorings,etc)
went in.
If you could just let me know when they have be= en committed, I can certainly
rebase mine and post them.
=A0
thanks
shriram
--0015175cdc56ae79d104bf87bdcd-- --===============3403722634409047213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3403722634409047213==-- From xen-devel-bounces@lists.xen.org Tue May 08 15:12:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:12:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm4o-00057z-44; Tue, 08 May 2012 15:11:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm4n-00057t-4g for xen-devel@lists.xen.org; Tue, 08 May 2012 15:11:45 +0000 Received: from [193.109.254.147:19225] by server-12.bemta-14.messagelabs.com id CF/11-05898-0B739AF4; Tue, 08 May 2012 15:11:44 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336489902!1355301!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19280 invoked from network); 8 May 2012 15:11:43 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:11:43 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id E131D541C6; Tue, 8 May 2012 17:11:40 +0200 (CEST) Date: Tue, 8 May 2012 17:11:40 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120508151140.GA26382@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , xen-devel , Ian.Jackson@citrix.com References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> <1336487933.13218.9.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336487933.13218.9.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ian.Jackson@citrix.com, xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > * Directory usage in libxl > > - dumps in /var/xen: wtf? > However I don't think this is somewhere that xl (nb: this is a property > of xl, not libxl) needs to slavishly follow what xend did. > What would the correct FHS location for these dumps be? Unsure. The FHS defines /var/crash for system crash dumps, but it is not used everywhere. So I would use /var/lib/xen/dump or so. > > - user data files in /var/lib/xen: > > What are the guarantees given for this files? > I suppose you are asking for /var/lib vs /var/run (or /run) reasons? Exactly. > One of the keys by which you lookup this userdata is domid. Which means > that the lifetime of this data is bounded by the life of a domain. Which > means that it need not persist over reboot (which I think argues for > (/var)?/run) I don't think rebooting the control domain without rebooting Xen will work right now. So /var/run is the correct location. On further thoughts: Why not push them into xenstore? > > - /var/run/libxl for temporary files > Are you suggesting that this is being wrongly used by libxl, or that > libxl should use this location for more things than it currently does? > Perhaps some stuff should instead be in /tmp or $TMPDIR? $TMPDIR or the fallback /tmp is the correct location. > Other than the xs.h naming issue I don't see anything here which I think > is a blocker for 4.2, I'd say they are mostly "nice to have". I'm just collecting changes for the Debian packages. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:12:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:12:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm4o-00057z-44; Tue, 08 May 2012 15:11:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm4n-00057t-4g for xen-devel@lists.xen.org; Tue, 08 May 2012 15:11:45 +0000 Received: from [193.109.254.147:19225] by server-12.bemta-14.messagelabs.com id CF/11-05898-0B739AF4; Tue, 08 May 2012 15:11:44 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336489902!1355301!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19280 invoked from network); 8 May 2012 15:11:43 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:11:43 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id E131D541C6; Tue, 8 May 2012 17:11:40 +0200 (CEST) Date: Tue, 8 May 2012 17:11:40 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120508151140.GA26382@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , xen-devel , Ian.Jackson@citrix.com References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> <1336487933.13218.9.camel@cthulhu.hellion.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336487933.13218.9.camel@cthulhu.hellion.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ian.Jackson@citrix.com, xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote: > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > * Directory usage in libxl > > - dumps in /var/xen: wtf? > However I don't think this is somewhere that xl (nb: this is a property > of xl, not libxl) needs to slavishly follow what xend did. > What would the correct FHS location for these dumps be? Unsure. The FHS defines /var/crash for system crash dumps, but it is not used everywhere. So I would use /var/lib/xen/dump or so. > > - user data files in /var/lib/xen: > > What are the guarantees given for this files? > I suppose you are asking for /var/lib vs /var/run (or /run) reasons? Exactly. > One of the keys by which you lookup this userdata is domid. Which means > that the lifetime of this data is bounded by the life of a domain. Which > means that it need not persist over reboot (which I think argues for > (/var)?/run) I don't think rebooting the control domain without rebooting Xen will work right now. So /var/run is the correct location. On further thoughts: Why not push them into xenstore? > > - /var/run/libxl for temporary files > Are you suggesting that this is being wrongly used by libxl, or that > libxl should use this location for more things than it currently does? > Perhaps some stuff should instead be in /tmp or $TMPDIR? $TMPDIR or the fallback /tmp is the correct location. > Other than the xs.h naming issue I don't see anything here which I think > is a blocker for 4.2, I'd say they are mostly "nice to have". I'm just collecting changes for the Debian packages. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:16:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm9V-0005HH-Qb; Tue, 08 May 2012 15:16:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm9U-0005HC-1d for xen-devel@lists.xen.org; Tue, 08 May 2012 15:16:36 +0000 Received: from [85.158.139.83:62658] by server-10.bemta-5.messagelabs.com id 79/F8-08260-0D839AF4; Tue, 08 May 2012 15:16:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-182.messagelabs.com!1336490190!23438279!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTAyNDg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTAyNDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17345 invoked from network); 8 May 2012 15:16:31 -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 DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:16:31 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGji0NGuc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-080-039.pools.arcor-ip.net [88.65.80.39]) by smtp.strato.de (jored mo7) (RZmta 29.6 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602ef6o48EPciV ; Tue, 8 May 2012 17:16:30 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 5B44218637; Tue, 8 May 2012 17:16:29 +0200 (CEST) Date: Tue, 8 May 2012 17:16:29 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120508151629.GA14353@aepfle.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, Ian Campbell wrote: > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html > > The time line is as follows: > > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > Mid/Late May -- First release candidate > Weekly -- RCN+1 until it is ready > > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. Please consider "tools/configure: add options to pass EXTRA_CFLAGS" http://lists.xen.org/archives/html/xen-devel/2012-04/msg00537.html Since qemu-upstream was imported, building tools with RPM_OPT_FLAGS will not work anymore. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:16:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm9V-0005HH-Qb; Tue, 08 May 2012 15:16:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRm9U-0005HC-1d for xen-devel@lists.xen.org; Tue, 08 May 2012 15:16:36 +0000 Received: from [85.158.139.83:62658] by server-10.bemta-5.messagelabs.com id 79/F8-08260-0D839AF4; Tue, 08 May 2012 15:16:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-182.messagelabs.com!1336490190!23438279!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTAyNDg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTAyNDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17345 invoked from network); 8 May 2012 15:16:31 -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 DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 15:16:31 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGji0NGuc= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-080-039.pools.arcor-ip.net [88.65.80.39]) by smtp.strato.de (jored mo7) (RZmta 29.6 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602ef6o48EPciV ; Tue, 8 May 2012 17:16:30 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 5B44218637; Tue, 8 May 2012 17:16:29 +0200 (CEST) Date: Tue, 8 May 2012 17:16:29 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120508151629.GA14353@aepfle.de> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336469655.14542.21.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, Ian Campbell wrote: > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html > > The time line is as follows: > > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > Mid/Late May -- First release candidate > Weekly -- RCN+1 until it is ready > > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. Please consider "tools/configure: add options to pass EXTRA_CFLAGS" http://lists.xen.org/archives/html/xen-devel/2012-04/msg00537.html Since qemu-upstream was imported, building tools with RPM_OPT_FLAGS will not work anymore. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:24:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:24:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmGi-0005nj-Uy; Tue, 08 May 2012 15:24:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmGh-0005nZ-LC for xen-devel@lists.xen.org; Tue, 08 May 2012 15:24:03 +0000 Received: from [193.109.254.147:43333] by server-9.bemta-14.messagelabs.com id D7/29-05787-29A39AF4; Tue, 08 May 2012 15:24:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336490640!529579!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30895 invoked from network); 8 May 2012 15:24:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 15:24:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330923600"; d="scan'208";a="193875241" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 11:23:45 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:23:45 -0400 Message-ID: <1336490625.13218.17.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Bastian Blank Date: Tue, 8 May 2012 16:23:45 +0100 In-Reply-To: <20120508151140.GA26382@wavehammer.waldi.eu.org> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> <1336487933.13218.9.camel@cthulhu.hellion.org.uk> <20120508151140.GA26382@wavehammer.waldi.eu.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 11:11 -0400, Bastian Blank wrote: > On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > > * Directory usage in libxl > > > - dumps in /var/xen: wtf? > > However I don't think this is somewhere that xl (nb: this is a property > > of xl, not libxl) needs to slavishly follow what xend did. > > What would the correct FHS location for these dumps be? > > Unsure. The FHS defines /var/crash for system crash dumps, but it is not > used everywhere. So I would use /var/lib/xen/dump or so. OK. Do you have that patch to hand? > > > - user data files in /var/lib/xen: > > > What are the guarantees given for this files? > > I suppose you are asking for /var/lib vs /var/run (or /run) reasons? > > Exactly. Do you have that patch to hand too? > > One of the keys by which you lookup this userdata is domid. Which means > > that the lifetime of this data is bounded by the life of a domain. Which > > means that it need not persist over reboot (which I think argues for > > (/var)?/run) > > I don't think rebooting the control domain without rebooting Xen will > work right now. So /var/run is the correct location. Right. (Can you guess my next question...) Do you have that patch to hand too? ( ;-) ) > On further thoughts: Why not push them into xenstore? AIUI the userdata facility is provided specifically for data which is unsuitable for xenstore, due to size or whatever (XS has various limits, to avoid abuse, which are relatively low). > > > - /var/run/libxl for temporary files > > Are you suggesting that this is being wrongly used by libxl, or that > > libxl should use this location for more things than it currently does? > > Perhaps some stuff should instead be in /tmp or $TMPDIR? > > $TMPDIR or the fallback /tmp is the correct location. > > > Other than the xs.h naming issue I don't see anything here which I think > > is a blocker for 4.2, I'd say they are mostly "nice to have". > > I'm just collecting changes for the Debian packages. Sure. I guess you will send out those patches as and when you are happy with them? Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:24:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:24:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmGi-0005nj-Uy; Tue, 08 May 2012 15:24:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmGh-0005nZ-LC for xen-devel@lists.xen.org; Tue, 08 May 2012 15:24:03 +0000 Received: from [193.109.254.147:43333] by server-9.bemta-14.messagelabs.com id D7/29-05787-29A39AF4; Tue, 08 May 2012 15:24:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336490640!529579!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTA4MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30895 invoked from network); 8 May 2012 15:24:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 15:24:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330923600"; d="scan'208";a="193875241" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 11:23:45 -0400 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 11:23:45 -0400 Message-ID: <1336490625.13218.17.camel@cthulhu.hellion.org.uk> From: Ian Campbell To: Bastian Blank Date: Tue, 8 May 2012 16:23:45 +0100 In-Reply-To: <20120508151140.GA26382@wavehammer.waldi.eu.org> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <20120508140936.GA25033@wavehammer.waldi.eu.org> <1336487933.13218.9.camel@cthulhu.hellion.org.uk> <20120508151140.GA26382@wavehammer.waldi.eu.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , xen-devel Subject: Re: [Xen-devel] 4.2 TODO / Release Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 11:11 -0400, Bastian Blank wrote: > On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > > * Directory usage in libxl > > > - dumps in /var/xen: wtf? > > However I don't think this is somewhere that xl (nb: this is a property > > of xl, not libxl) needs to slavishly follow what xend did. > > What would the correct FHS location for these dumps be? > > Unsure. The FHS defines /var/crash for system crash dumps, but it is not > used everywhere. So I would use /var/lib/xen/dump or so. OK. Do you have that patch to hand? > > > - user data files in /var/lib/xen: > > > What are the guarantees given for this files? > > I suppose you are asking for /var/lib vs /var/run (or /run) reasons? > > Exactly. Do you have that patch to hand too? > > One of the keys by which you lookup this userdata is domid. Which means > > that the lifetime of this data is bounded by the life of a domain. Which > > means that it need not persist over reboot (which I think argues for > > (/var)?/run) > > I don't think rebooting the control domain without rebooting Xen will > work right now. So /var/run is the correct location. Right. (Can you guess my next question...) Do you have that patch to hand too? ( ;-) ) > On further thoughts: Why not push them into xenstore? AIUI the userdata facility is provided specifically for data which is unsuitable for xenstore, due to size or whatever (XS has various limits, to avoid abuse, which are relatively low). > > > - /var/run/libxl for temporary files > > Are you suggesting that this is being wrongly used by libxl, or that > > libxl should use this location for more things than it currently does? > > Perhaps some stuff should instead be in /tmp or $TMPDIR? > > $TMPDIR or the fallback /tmp is the correct location. > > > Other than the xs.h naming issue I don't see anything here which I think > > is a blocker for 4.2, I'd say they are mostly "nice to have". > > I'm just collecting changes for the Debian packages. Sure. I guess you will send out those patches as and when you are happy with them? Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:42:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmXg-0006GT-Q0; Tue, 08 May 2012 15:41:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmXf-0006GO-6j for xen-devel@lists.xensource.com; Tue, 08 May 2012 15:41:35 +0000 Received: from [193.109.254.147:7784] by server-10.bemta-14.messagelabs.com id F4/7A-05847-EAE39AF4; Tue, 08 May 2012 15:41:34 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336491677!8218832!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14060 invoked from network); 8 May 2012 15:41:18 -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; 8 May 2012 15:41:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48FfAcI000810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 15:41:10 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 q48Ff9t7003385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 15:41:09 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 q48Ff8Bh016109; Tue, 8 May 2012 10:41:08 -0500 MIME-Version: 1.0 Message-ID: <96f33541-2f55-4a5b-8815-1c41a0fbd592@default> Date: Tue, 8 May 2012 08:40:51 -0700 (PDT) From: Dan Magenheimer To: Ian Campbell References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> <1336480869.14542.74.camel@zakaz.uk.xensource.com> In-Reply-To: <1336480869.14542.74.camel@zakaz.uk.xensource.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Tuesday, May 08, 2012 6:41 AM > To: Dan Magenheimer > Cc: Olaf Hering; xen-devel@lists.xensource.com; Konrad Wilk > Subject: RE: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > On Mon, 2012-05-07 at 17:37 +0100, Dan Magenheimer wrote: > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > > Sent: Sunday, May 06, 2012 3:36 AM > > > To: Olaf Hering > > > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > > > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > > > > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > > > # HG changeset patch > > > > > > # User Olaf Hering > > > > > > # Date 1336159720 -7200 > > > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > > > xl.cfg: document the maxmem= option > > > > > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > > > --- a/docs/man/xl.cfg.pod.5 > > > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > > > mode) and your guest workload consists of a a very large number of > > > > > > similar processes then increasing this value may improve performance. > > > > > > > > > > > > +=item B > > > > > > + > > > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > can _ever_ see... > > > > What about guest OS's that support hotplug memory? > > Does the toolstack (need to) expose the capability to drive that as a > host admin? I don't think xl does... In which case this wording can be > tweaked when that feature is added? I don't know if the matching support ever was implemented in xl, but hotplug memory support for Xen is in upstream Linux. http://lists.xen.org/archives/html/xen-devel/2011-05/msg01060.html If it _is_ in xl, "can ever see" seems a bit too strong... maybe something like "memory the HVM guest can see unless changed later via 'xl mem-max'" or "memory the HVM guest can see when it boots" would be better. But this is a nit. It's impossible to both be precise and brief in descriptions such as these. > > Also, a subtle point, but is this the maximum physical address that > > will contain read/write pages or the maximum amount of RAM that the > > guest OS should be prepared to map as read/writeable (e.g. after > > subtracting off reserved e820 ranges) or ??? > > I think it is total number of memory pages, not the maximum PFN. e.g. > the maximum address might be 4.5GB on a 4GB machine with a PCI hole. > > I *think*... OK. If so, then the proposed wording is fine, though maybe adding one word "maximum amount of _usable_ memory" might help. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 15:42:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 15:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmXg-0006GT-Q0; Tue, 08 May 2012 15:41:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRmXf-0006GO-6j for xen-devel@lists.xensource.com; Tue, 08 May 2012 15:41:35 +0000 Received: from [193.109.254.147:7784] by server-10.bemta-14.messagelabs.com id F4/7A-05847-EAE39AF4; Tue, 08 May 2012 15:41:34 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336491677!8218832!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14060 invoked from network); 8 May 2012 15:41:18 -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; 8 May 2012 15:41:18 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48FfAcI000810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 15:41:10 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 q48Ff9t7003385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 15:41:09 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 q48Ff8Bh016109; Tue, 8 May 2012 10:41:08 -0500 MIME-Version: 1.0 Message-ID: <96f33541-2f55-4a5b-8815-1c41a0fbd592@default> Date: Tue, 8 May 2012 08:40:51 -0700 (PDT) From: Dan Magenheimer To: Ian Campbell References: <20120504194222.GA28634@phenom.dumpdata.com> <20120504201802.GA16466@aepfle.de> <1336296932.5933.9.camel@cthulhu.hellion.org.uk> <1336480869.14542.74.camel@zakaz.uk.xensource.com> In-Reply-To: <1336480869.14542.74.camel@zakaz.uk.xensource.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.6 (510070) [OL 12.0.6607.1000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , xen-devel@lists.xensource.com, Konrad Wilk Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Tuesday, May 08, 2012 6:41 AM > To: Dan Magenheimer > Cc: Olaf Hering; xen-devel@lists.xensource.com; Konrad Wilk > Subject: RE: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > On Mon, 2012-05-07 at 17:37 +0100, Dan Magenheimer wrote: > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > > Sent: Sunday, May 06, 2012 3:36 AM > > > To: Olaf Hering > > > Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk > > > Subject: Re: [Xen-devel] [PATCH] xl.cfg: document the maxmem= option > > > > > > On Fri, 2012-05-04 at 16:18 -0400, Olaf Hering wrote: > > > > On Fri, May 04, Konrad Rzeszutek Wilk wrote: > > > > > > > > > On Fri, May 04, 2012 at 09:31:42PM +0200, Olaf Hering wrote: > > > > > > # HG changeset patch > > > > > > # User Olaf Hering > > > > > > # Date 1336159720 -7200 > > > > > > # Node ID c414728d0d12f1c3e416e40cceefca2f0b00578e > > > > > > # Parent 8f556a70ae0bef47e242f9e7be0a054769fc8277 > > > > > > xl.cfg: document the maxmem= option > > > > > > > > > > > > Signed-off-by: Olaf Hering > > > > > > > > > > > > diff -r 8f556a70ae0b -r c414728d0d12 docs/man/xl.cfg.pod.5 > > > > > > --- a/docs/man/xl.cfg.pod.5 > > > > > > +++ b/docs/man/xl.cfg.pod.5 > > > > > > @@ -484,6 +484,14 @@ are not using hardware assisted paging ( > > > > > > mode) and your guest workload consists of a a very large number of > > > > > > similar processes then increasing this value may improve performance. > > > > > > > > > > > > +=item B > > > > > > + > > > > > > +Specifies the maximum amount of memory the HVM guest can ever see. > > > > can _ever_ see... > > > > What about guest OS's that support hotplug memory? > > Does the toolstack (need to) expose the capability to drive that as a > host admin? I don't think xl does... In which case this wording can be > tweaked when that feature is added? I don't know if the matching support ever was implemented in xl, but hotplug memory support for Xen is in upstream Linux. http://lists.xen.org/archives/html/xen-devel/2011-05/msg01060.html If it _is_ in xl, "can ever see" seems a bit too strong... maybe something like "memory the HVM guest can see unless changed later via 'xl mem-max'" or "memory the HVM guest can see when it boots" would be better. But this is a nit. It's impossible to both be precise and brief in descriptions such as these. > > Also, a subtle point, but is this the maximum physical address that > > will contain read/write pages or the maximum amount of RAM that the > > guest OS should be prepared to map as read/writeable (e.g. after > > subtracting off reserved e820 ranges) or ??? > > I think it is total number of memory pages, not the maximum PFN. e.g. > the maximum address might be 4.5GB on a 4GB machine with a PCI hole. > > I *think*... OK. If so, then the proposed wording is fine, though maybe adding one word "maximum amount of _usable_ memory" might help. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:25:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16:25:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnDD-0006y6-G0; Tue, 08 May 2012 16:24:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnDB-0006y1-Vb for xen-devel@lists.xensource.com; Tue, 08 May 2012 16:24:30 +0000 Received: from [193.109.254.147:55666] by server-8.bemta-14.messagelabs.com id 75/A9-23244-DB849AF4; Tue, 08 May 2012 16:24:29 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-27.messagelabs.com!1336494268!8248994!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Mzk4NjI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10566 invoked from network); 8 May 2012 16:24:28 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 16:24:28 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 122691766; Tue, 8 May 2012 19:24:26 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D01872005D; Tue, 8 May 2012 19:24:26 +0300 (EEST) Date: Tue, 8 May 2012 19:24:26 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20120508162426.GD2058@reaktio.net> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336131139.2361.60.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Anthony PERARD , "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 12:32:19PM +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > > Anthony -- any idea why the videoram setting doesn't work with upstream > > > qemu? > > > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > > then, it seams you have to have this value of at least 32MB, otherwise > > the value is increase in qemu. > > > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > > size in qemu is fixed to 8MB. > > OK, so this is simply a feature which upstream qemu doesn't have. That's > fine. > Is this something that should be forward-ported from qemu-xen-traditional to upstream qemu ? > I guess xl.cfg(5) needs updating to make it clear that this option only > applies to qemu-xen-traditional. > > The docs also currently say that for stdvga the default is 8MB and for > not stdvga (by which I guess it means Cirrus) the default if 4MB. So I > guess even this is inaccurate for qemu-xen-upstream? > > Can someone send a patch please? > For the documentation patch maybe add this to the 4.2 status todo list as a reminder :) -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:25:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16:25:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnDD-0006y6-G0; Tue, 08 May 2012 16:24:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnDB-0006y1-Vb for xen-devel@lists.xensource.com; Tue, 08 May 2012 16:24:30 +0000 Received: from [193.109.254.147:55666] by server-8.bemta-14.messagelabs.com id 75/A9-23244-DB849AF4; Tue, 08 May 2012 16:24:29 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-27.messagelabs.com!1336494268!8248994!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Mzk4NjI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10566 invoked from network); 8 May 2012 16:24:28 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2012 16:24:28 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 122691766; Tue, 8 May 2012 19:24:26 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D01872005D; Tue, 8 May 2012 19:24:26 +0300 (EEST) Date: Tue, 8 May 2012 19:24:26 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20120508162426.GD2058@reaktio.net> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336131139.2361.60.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Anthony PERARD , "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 04, 2012 at 12:32:19PM +0100, Ian Campbell wrote: > On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > > Anthony -- any idea why the videoram setting doesn't work with upstream > > > qemu? > > > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > > then, it seams you have to have this value of at least 32MB, otherwise > > the value is increase in qemu. > > > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > > size in qemu is fixed to 8MB. > > OK, so this is simply a feature which upstream qemu doesn't have. That's > fine. > Is this something that should be forward-ported from qemu-xen-traditional to upstream qemu ? > I guess xl.cfg(5) needs updating to make it clear that this option only > applies to qemu-xen-traditional. > > The docs also currently say that for stdvga the default is 8MB and for > not stdvga (by which I guess it means Cirrus) the default if 4MB. So I > guess even this is inaccurate for qemu-xen-upstream? > > Can someone send a patch please? > For the documentation patch maybe add this to the 4.2 status todo list as a reminder :) -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:40:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16: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 ) id 1SRnSD-00079r-Vr; Tue, 08 May 2012 16:40:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnSB-00079i-W5 for xen-devel@lists.xen.org; Tue, 08 May 2012 16:40:00 +0000 Received: from [85.158.143.35:3873] by server-1.bemta-4.messagelabs.com id AB/54-20925-F5C49AF4; Tue, 08 May 2012 16:39:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336495197!13276027!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9128 invoked from network); 8 May 2012 16:39:58 -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; 8 May 2012 16:39:58 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48GdscR008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 16:39:55 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q48Gdsne013214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 16:39:54 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 q48GdriQ007008; Tue, 8 May 2012 11:39:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 09:39:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B90C14031D; Tue, 8 May 2012 12:34:02 -0400 (EDT) Date: Tue, 8 May 2012 12:34:02 -0400 From: Konrad Rzeszutek Wilk To: Daniel De Graaf Message-ID: <20120508163402.GA6184@phenom.dumpdata.com> References: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: JBeulich@suse.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 09:46:57AM -0400, Daniel De Graaf wrote: > Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus > backend to be started after the kernel has booted. This allows xenstore > to run in a different domain from the dom0. > > Signed-off-by: Daniel De Graaf > --- > 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 > #include > +#include > #include > +#include > +#include > +#include > > #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; If I specify as domid = DOMID_SELF what will happen? Should we filter some of the obvious no-no values? Like DOMID_IO, DOMID_SELF? > + > + 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 > > +#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.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:40:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16: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 ) id 1SRnSD-00079r-Vr; Tue, 08 May 2012 16:40:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnSB-00079i-W5 for xen-devel@lists.xen.org; Tue, 08 May 2012 16:40:00 +0000 Received: from [85.158.143.35:3873] by server-1.bemta-4.messagelabs.com id AB/54-20925-F5C49AF4; Tue, 08 May 2012 16:39:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336495197!13276027!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9128 invoked from network); 8 May 2012 16:39:58 -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; 8 May 2012 16:39:58 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48GdscR008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 16:39:55 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q48Gdsne013214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 16:39:54 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 q48GdriQ007008; Tue, 8 May 2012 11:39:53 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 09:39:53 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B90C14031D; Tue, 8 May 2012 12:34:02 -0400 (EDT) Date: Tue, 8 May 2012 12:34:02 -0400 From: Konrad Rzeszutek Wilk To: Daniel De Graaf Message-ID: <20120508163402.GA6184@phenom.dumpdata.com> References: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: JBeulich@suse.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 09:46:57AM -0400, Daniel De Graaf wrote: > Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus > backend to be started after the kernel has booted. This allows xenstore > to run in a different domain from the dom0. > > Signed-off-by: Daniel De Graaf > --- > 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 > #include > +#include > #include > +#include > +#include > +#include > > #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; If I specify as domid = DOMID_SELF what will happen? Should we filter some of the obvious no-no values? Like DOMID_IO, DOMID_SELF? > + > + 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 > > +#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.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:46:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16: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 ) id 1SRnY0-0007I4-OI; Tue, 08 May 2012 16:46:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnXz-0007Hy-LU for xen-devel@lists.xen.org; Tue, 08 May 2012 16:45:59 +0000 Received: from [193.109.254.147:4923] by server-9.bemta-14.messagelabs.com id 04/83-05787-6CD49AF4; Tue, 08 May 2012 16:45:58 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336495556!5805168!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE2NDQz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32735 invoked from network); 8 May 2012 16:45:58 -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; 8 May 2012 16:45:58 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48GjmQq008162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 16:45:49 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 q48GjllI027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 16:45:47 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 q48GjkTx012163; Tue, 8 May 2012 11:45:46 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 09:45:46 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 321984031D; Tue, 8 May 2012 12:39:57 -0400 (EDT) Date: Tue, 8 May 2012 12:39:57 -0400 From: Konrad Rzeszutek Wilk To: AP , msw@amazon.com, snoonan@amazon.com Message-ID: <20120508163957.GB6319@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > (i.e. the outcome of the above printing you added) the problem in > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > attempting XSETBV). What your patch efectively does is take away > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > following message: > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > 00002660 > > > > > > > > ... which is what this message is telling you. > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > xsave=1. > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > added, > > > > to find out why the CR4 write supposedly happening immediately > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > Where did you see that code? Looking at the Linus's tree this is what I > > see > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > So who added that code? I am not seeing it in v3.0 either? > > This is in the Ubuntu 11.10 kernel: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Which seems to say that Amazon's HV is advertising the OXSAVE bit? Lets ping them and see if they have some recomendations. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 16:46:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 16: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 ) id 1SRnY0-0007I4-OI; Tue, 08 May 2012 16:46:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnXz-0007Hy-LU for xen-devel@lists.xen.org; Tue, 08 May 2012 16:45:59 +0000 Received: from [193.109.254.147:4923] by server-9.bemta-14.messagelabs.com id 04/83-05787-6CD49AF4; Tue, 08 May 2012 16:45:58 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336495556!5805168!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE2NDQz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32735 invoked from network); 8 May 2012 16:45:58 -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; 8 May 2012 16:45:58 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48GjmQq008162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 16:45:49 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 q48GjllI027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 16:45:47 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 q48GjkTx012163; Tue, 8 May 2012 11:45:46 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 09:45:46 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 321984031D; Tue, 8 May 2012 12:39:57 -0400 (EDT) Date: Tue, 8 May 2012 12:39:57 -0400 From: Konrad Rzeszutek Wilk To: AP , msw@amazon.com, snoonan@amazon.com Message-ID: <20120508163957.GB6319@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > (i.e. the outcome of the above printing you added) the problem in > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > attempting XSETBV). What your patch efectively does is take away > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > following message: > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > 00002660 > > > > > > > > ... which is what this message is telling you. > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > xsave=1. > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > added, > > > > to find out why the CR4 write supposedly happening immediately > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > Where did you see that code? Looking at the Linus's tree this is what I > > see > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > So who added that code? I am not seeing it in v3.0 either? > > This is in the Ubuntu 11.10 kernel: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Which seems to say that Amazon's HV is advertising the OXSAVE bit? Lets ping them and see if they have some recomendations. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:02:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17:02:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnnv-0007iI-Sv; Tue, 08 May 2012 17:02:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnnt-0007iD-TR for xen-devel@lists.xen.org; Tue, 08 May 2012 17:02:26 +0000 Received: from [85.158.143.99:41745] by server-2.bemta-4.messagelabs.com id 17/3D-17550-1A159AF4; Tue, 08 May 2012 17:02:25 +0000 X-Env-Sender: msw@amazon.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336496542!20658022!1 X-Originating-IP: [207.171.178.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNDY2MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3703 invoked from network); 8 May 2012 17:02:24 -0000 Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com) (207.171.178.25) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 17:02:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="230177894" Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2012 17:01:40 +0000 Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.116.180]) by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with SMTP id q48H2ENm003214; Tue, 8 May 2012 17:02:15 GMT Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 08 May 2012 10:02:09 -0700 Date: Tue, 8 May 2012 10:02:09 -0700 From: Matt Wilson To: Konrad Rzeszutek Wilk Message-ID: <20120508170209.GA5684@US-SEA-R8XVZTX> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120508163957.GB6319@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120508163957.GB6319@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: Jeremy Fitzhardinge , "Noonan, Steven" , "Tim.Deegan@citrix.com" , "weidong.han@intel.com" , "stefan.bader@canonical.com" , xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 09:39:57AM -0700, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > konrad.wilk@oracle.com> wrote: > > > > This is in the Ubuntu 11.10 kernel: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > Which seems to say that Amazon's HV is advertising the OXSAVE bit? > > Lets ping them and see if they have some recomendations. Hi, The kernel requirements for EC2 are documented in our User Guide here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/UserProvidedkernels.html#PVGRUB_compatible_kernels Specifically, there's a callout regarding XSAVE: "Kernels that disable the pv-ops XSAVE hypercall are known to work on all instance types, whereas those that enable this hypercall will fail to launch in some cases. Similarly, non-pv-ops kernels that do not adhere to the Xen 3.0.2 interface might fail to launch in some cases." Apologies for the miswording of the note, it should say something like "kernels that disable the XSAVE capability" instead. Cheers, Matt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:02:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17:02:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnnv-0007iI-Sv; Tue, 08 May 2012 17:02:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnnt-0007iD-TR for xen-devel@lists.xen.org; Tue, 08 May 2012 17:02:26 +0000 Received: from [85.158.143.99:41745] by server-2.bemta-4.messagelabs.com id 17/3D-17550-1A159AF4; Tue, 08 May 2012 17:02:25 +0000 X-Env-Sender: msw@amazon.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336496542!20658022!1 X-Originating-IP: [207.171.178.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNDY2MDQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3703 invoked from network); 8 May 2012 17:02:24 -0000 Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com) (207.171.178.25) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 17:02:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,544,1330905600"; d="scan'208";a="230177894" Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2012 17:01:40 +0000 Received: from US-SEA-R8XVZTX (us-sea-r8xvztx.ant.amazon.com [10.61.116.180]) by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with SMTP id q48H2ENm003214; Tue, 8 May 2012 17:02:15 GMT Received: by US-SEA-R8XVZTX (sSMTP sendmail emulation); Tue, 08 May 2012 10:02:09 -0700 Date: Tue, 8 May 2012 10:02:09 -0700 From: Matt Wilson To: Konrad Rzeszutek Wilk Message-ID: <20120508170209.GA5684@US-SEA-R8XVZTX> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120508163957.GB6319@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120508163957.GB6319@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: Jeremy Fitzhardinge , "Noonan, Steven" , "Tim.Deegan@citrix.com" , "weidong.han@intel.com" , "stefan.bader@canonical.com" , xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 09:39:57AM -0700, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > konrad.wilk@oracle.com> wrote: > > > > This is in the Ubuntu 11.10 kernel: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > Which seems to say that Amazon's HV is advertising the OXSAVE bit? > > Lets ping them and see if they have some recomendations. Hi, The kernel requirements for EC2 are documented in our User Guide here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/UserProvidedkernels.html#PVGRUB_compatible_kernels Specifically, there's a callout regarding XSAVE: "Kernels that disable the pv-ops XSAVE hypercall are known to work on all instance types, whereas those that enable this hypercall will fail to launch in some cases. Similarly, non-pv-ops kernels that do not adhere to the Xen 3.0.2 interface might fail to launch in some cases." Apologies for the miswording of the note, it should say something like "kernels that disable the XSAVE capability" instead. Cheers, Matt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17: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 ) id 1SRoA1-00084C-1U; Tue, 08 May 2012 17:25:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRo9z-000847-Qm for xen-devel@lists.xensource.com; Tue, 08 May 2012 17:25:16 +0000 Received: from [85.158.143.99:11908] by server-3.bemta-4.messagelabs.com id 7D/CD-05853-BF659AF4; Tue, 08 May 2012 17:25:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336497912!27069686!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25414 invoked from network); 8 May 2012 17:25: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; 8 May 2012 17:25:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="12362212" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 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, 8 May 2012 18:25:10 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRo9u-0001Jx-PB; Tue, 08 May 2012 17:25:10 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRo9u-0007LU-IK; Tue, 08 May 2012 18:25:10 +0100 To: Message-ID: From: xen.org Date: Tue, 8 May 2012 18:25:10 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12802: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12802 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12802/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12787 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux bea37381fd9a34c6660e5195d31beea86aa3dda3 baseline version: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17: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 ) id 1SRoA1-00084C-1U; Tue, 08 May 2012 17:25:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRo9z-000847-Qm for xen-devel@lists.xensource.com; Tue, 08 May 2012 17:25:16 +0000 Received: from [85.158.143.99:11908] by server-3.bemta-4.messagelabs.com id 7D/CD-05853-BF659AF4; Tue, 08 May 2012 17:25:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336497912!27069686!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25414 invoked from network); 8 May 2012 17:25: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; 8 May 2012 17:25:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="12362212" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 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, 8 May 2012 18:25:10 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRo9u-0001Jx-PB; Tue, 08 May 2012 17:25:10 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRo9u-0007LU-IK; Tue, 08 May 2012 18:25:10 +0100 To: Message-ID: From: xen.org Date: Tue, 8 May 2012 18:25:10 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12802: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12802 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12802/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12787 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-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-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux bea37381fd9a34c6660e5195d31beea86aa3dda3 baseline version: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:30:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17: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 ) id 1SRoER-0008C4-Pj; Tue, 08 May 2012 17:29:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoEQ-0008Bx-Pf for xen-devel@lists.xensource.com; Tue, 08 May 2012 17:29:50 +0000 Received: from [193.109.254.147:52051] by server-4.bemta-14.messagelabs.com id 30/01-11570-E0859AF4; Tue, 08 May 2012 17:29:50 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336498189!2579371!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12301 invoked from network); 8 May 2012 17:29: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; 8 May 2012 17:29:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="12362280" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 17:29:49 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 18:29:48 +0100 Date: Tue, 8 May 2012 18:29:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20120507212536.GA24344@andromeda.dapyr.net> Message-ID: References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 7 May 2012, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > > domain. Then when blkfront un-share them, also removes the > > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > > > We do it so that when the source and the destination domain are the same > > > > (blkfront connected to blkback in the same domain) we can more easily > > So I've been testing it with my mini config and it worked great. But > when I started using a distro .config it blew up. I am not really > sure why it does that, but here is the dmesg and .config. > > Nothing fancy with the guest config: > > cat /crash.xm | grep -v \# > memory = 4096 > name = "OL6_X86_64_PVHVM" > vcpus=12 > vif = [ 'mac=00:0f:4b:00:00:72,bridge=switch' ] > disk= ['phy:/dev/guests/OL6_X86_64_PVHVM,hda,w'] > vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] > vnc=1 > vnclisten="0.0.0.0" > hvm_loader="/usr/bin/pygrub" > > > This is the #testing branch, but just using my #linux-next along > with stable/for-jens-3.5 should reproduce this. > > I added a bit of debug statement and found that 0xffffffffffffffff > was passed in as a PFN in the set_phys_to_machine. I have been unable to reproduce this problem (I haven't given up yet) but I bet that the following patch fixes it: diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index e3a9945..88e9304 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) buffer_mfn, rq_data_dir(req)); - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); + info->shadow[id].frame[i] = buffer_pfn; ring_req->u.rw.seg[i] = (struct blkif_request_segment) { .gref = ref, The idea is that the request contains a page for which pfn->mfn->pfn == 0xffffffffffffffff I am not sure exactly how it could be possible to get into this state in blkfront, I hope that some more tracing and code reading will be able to shed some lights on the issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:30:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17: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 ) id 1SRoER-0008C4-Pj; Tue, 08 May 2012 17:29:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoEQ-0008Bx-Pf for xen-devel@lists.xensource.com; Tue, 08 May 2012 17:29:50 +0000 Received: from [193.109.254.147:52051] by server-4.bemta-14.messagelabs.com id 30/01-11570-E0859AF4; Tue, 08 May 2012 17:29:50 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336498189!2579371!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12301 invoked from network); 8 May 2012 17:29: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; 8 May 2012 17:29:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="12362280" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 17:29:49 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 8 May 2012 18:29:48 +0100 Date: Tue, 8 May 2012 18:29:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20120507212536.GA24344@andromeda.dapyr.net> Message-ID: References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 7 May 2012, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 17, 2012 at 11:58:58AM +0100, Stefano Stabellini wrote: > > On Mon, 16 Apr 2012, Konrad Rzeszutek Wilk wrote: > > > On Tue, Apr 10, 2012 at 05:25:19PM +0100, Stefano Stabellini wrote: > > > > Set pages as FOREIGN_FRAME whenever blkfront shares them with another > > > > domain. Then when blkfront un-share them, also removes the > > > > FOREIGN_FRAME_BIT from the p2m. > > > > > > > > We do it so that when the source and the destination domain are the same > > > > (blkfront connected to blkback in the same domain) we can more easily > > So I've been testing it with my mini config and it worked great. But > when I started using a distro .config it blew up. I am not really > sure why it does that, but here is the dmesg and .config. > > Nothing fancy with the guest config: > > cat /crash.xm | grep -v \# > memory = 4096 > name = "OL6_X86_64_PVHVM" > vcpus=12 > vif = [ 'mac=00:0f:4b:00:00:72,bridge=switch' ] > disk= ['phy:/dev/guests/OL6_X86_64_PVHVM,hda,w'] > vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] > vnc=1 > vnclisten="0.0.0.0" > hvm_loader="/usr/bin/pygrub" > > > This is the #testing branch, but just using my #linux-next along > with stable/for-jens-3.5 should reproduce this. > > I added a bit of debug statement and found that 0xffffffffffffffff > was passed in as a PFN in the set_phys_to_machine. I have been unable to reproduce this problem (I haven't given up yet) but I bet that the following patch fixes it: diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index e3a9945..88e9304 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) buffer_mfn, rq_data_dir(req)); - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); + info->shadow[id].frame[i] = buffer_pfn; ring_req->u.rw.seg[i] = (struct blkif_request_segment) { .gref = ref, The idea is that the request contains a page for which pfn->mfn->pfn == 0xffffffffffffffff I am not sure exactly how it could be possible to get into this state in blkfront, I hope that some more tracing and code reading will be able to shed some lights on the issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:33:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17:33:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoHg-0008MV-JJ; Tue, 08 May 2012 17:33:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoHe-0008MM-Kd for xen-devel@lists.xen.org; Tue, 08 May 2012 17:33:10 +0000 Received: from [193.109.254.147:33658] by server-2.bemta-14.messagelabs.com id 74/3D-19409-5D859AF4; Tue, 08 May 2012 17:33:09 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-4.tower-27.messagelabs.com!1336498388!8246209!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13598 invoked from network); 8 May 2012 17:33:09 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-4.tower-27.messagelabs.com with SMTP; 8 May 2012 17:33:09 -0000 X-TM-IMSS-Message-ID: <2ece56fc000be20a@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2ece56fc000be20a ; Tue, 8 May 2012 13:33:14 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q48HWvZw013911; Tue, 8 May 2012 13:32:57 -0400 Message-ID: <4FA95884.8020105@tycho.nsa.gov> Date: Tue, 08 May 2012 13:31:48 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> <20120508163402.GA6184@phenom.dumpdata.com> In-Reply-To: <20120508163402.GA6184@phenom.dumpdata.com> Cc: JBeulich@suse.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/08/2012 12:34 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 09:46:57AM -0400, Daniel De Graaf wrote: >> Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus >> backend to be started after the kernel has booted. This allows xenstore >> to run in a different domain from the dom0. >> >> Signed-off-by: Daniel De Graaf >> --- >> 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 >> #include >> +#include >> #include >> +#include >> +#include >> +#include >> >> #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; > > If I specify as domid = DOMID_SELF what will happen? Should we filter some > of the obvious no-no values? Like DOMID_IO, DOMID_SELF? For DOMID_SELF, this will just be a convoluted way of getting a xenstore event channel bound locally - the same as from the existing ioctl. This ends up being a useless re-allocation of the event channel since it closes the existing one. Specifying an invalid domain ID will leave xenstore in the uninitialized state because no domain will ever connect and send the notify to make xenstored_ready nonzero. Until this happens, you can call the ioctl again, so there's no need to filter out the invalid values. >> + >> + 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 >> >> +#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.6 -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 17:33:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 17:33:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoHg-0008MV-JJ; Tue, 08 May 2012 17:33:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoHe-0008MM-Kd for xen-devel@lists.xen.org; Tue, 08 May 2012 17:33:10 +0000 Received: from [193.109.254.147:33658] by server-2.bemta-14.messagelabs.com id 74/3D-19409-5D859AF4; Tue, 08 May 2012 17:33:09 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-4.tower-27.messagelabs.com!1336498388!8246209!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13598 invoked from network); 8 May 2012 17:33:09 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-4.tower-27.messagelabs.com with SMTP; 8 May 2012 17:33:09 -0000 X-TM-IMSS-Message-ID: <2ece56fc000be20a@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2ece56fc000be20a ; Tue, 8 May 2012 13:33:14 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q48HWvZw013911; Tue, 8 May 2012 13:32:57 -0400 Message-ID: <4FA95884.8020105@tycho.nsa.gov> Date: Tue, 08 May 2012 13:31:48 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1336484817-12105-1-git-send-email-dgdegra@tycho.nsa.gov> <20120508163402.GA6184@phenom.dumpdata.com> In-Reply-To: <20120508163402.GA6184@phenom.dumpdata.com> Cc: JBeulich@suse.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RESEND] xenbus: Add support for xenbus backend in stub domain X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/08/2012 12:34 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 09:46:57AM -0400, Daniel De Graaf wrote: >> Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus >> backend to be started after the kernel has booted. This allows xenstore >> to run in a different domain from the dom0. >> >> Signed-off-by: Daniel De Graaf >> --- >> 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 >> #include >> +#include >> #include >> +#include >> +#include >> +#include >> >> #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; > > If I specify as domid = DOMID_SELF what will happen? Should we filter some > of the obvious no-no values? Like DOMID_IO, DOMID_SELF? For DOMID_SELF, this will just be a convoluted way of getting a xenstore event channel bound locally - the same as from the existing ioctl. This ends up being a useless re-allocation of the event channel since it closes the existing one. Specifying an invalid domain ID will leave xenstore in the uninitialized state because no domain will ever connect and send the notify to make xenstored_ready nonzero. Until this happens, you can call the ioctl again, so there's no need to filter out the invalid values. >> + >> + 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 >> >> +#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.6 -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 18:12:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 18:12:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRotf-0000Zf-U7; Tue, 08 May 2012 18:12:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRote-0000Za-O5 for xen-devel@lists.xensource.com; Tue, 08 May 2012 18:12:26 +0000 Received: from [85.158.143.35:19419] by server-1.bemta-4.messagelabs.com id 56/EA-20925-A0269AF4; Tue, 08 May 2012 18:12:26 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336500741!13697804!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23857 invoked from network); 8 May 2012 18:12:23 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 18:12:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330923600"; d="scan'208";a="24990131" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:12:20 -0400 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, 8 May 2012 14:12:20 -0400 Message-ID: <4FA96202.9010503@citrix.com> Date: Tue, 8 May 2012 19:12:18 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> <20120507184808.GA7249@phenom.dumpdata.com> In-Reply-To: <20120507184808.GA7249@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , David Vrabel , "JBeulich@suse.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/12 19:48, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: >> On 03/05/12 16:15, David Vrabel wrote: >>> >>> xen: update VA mapping when releasing memory during setup >>> >>> In xen_memory_setup(), if a page that is being released has a VA >>> mapping this must also be updated. Otherwise, the page will be not >>> released completely -- it will still be referenced in Xen and won't be >>> freed util the mapping is removed and this prevents it from being >>> reallocated at a different PFN. >>> >>> This was already being done for the ISA memory region in >>> xen_ident_map_ISA() but on many systems this was omitting a few pages >>> as many systems marked a few pages below the ISA memory region as >>> reserved in the e820 map. >>> >>> Signed-off-by: David Vrabel >>> --- >> [...] >>> --- a/arch/x86/xen/mmu.c >>> +++ b/arch/x86/xen/mmu.c >>> @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) >>> #endif >>> } >>> >>> -void __init xen_ident_map_ISA(void) >>> -{ >>> - unsigned long pa; >>> - >>> - /* >>> - * If we're dom0, then linear map the ISA machine addresses into >>> - * the kernel's address space. >>> - */ >>> - if (!xen_initial_domain()) >>> - return; >> >> It might look like this test has gone, however the new code which >> updates the VA mapping uses the e820 map and for a domU its map will not >> have a ISA region so there's no mapping to be updated. > > What if you use e820_hole=1 and the pci=xx in the guest? Are these xl configuration options? I'm not familiar with xl. The PCI memory hole should be above 3 GiB so this hole will be will above the memory that will be initially mapped at boot. I've not managed to persuade my test box to passthrough a PCI device to a guest (using xapi as the toolstack) to confirm, though. I'll have another go tomorrow. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 18:12:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 18:12:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRotf-0000Zf-U7; Tue, 08 May 2012 18:12:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRote-0000Za-O5 for xen-devel@lists.xensource.com; Tue, 08 May 2012 18:12:26 +0000 Received: from [85.158.143.35:19419] by server-1.bemta-4.messagelabs.com id 56/EA-20925-A0269AF4; Tue, 08 May 2012 18:12:26 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336500741!13697804!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM0ODQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23857 invoked from network); 8 May 2012 18:12:23 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 May 2012 18:12:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,552,1330923600"; d="scan'208";a="24990131" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 14:12:20 -0400 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, 8 May 2012 14:12:20 -0400 Message-ID: <4FA96202.9010503@citrix.com> Date: Tue, 8 May 2012 19:12:18 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> <20120507184808.GA7249@phenom.dumpdata.com> In-Reply-To: <20120507184808.GA7249@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , David Vrabel , "JBeulich@suse.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 07/05/12 19:48, Konrad Rzeszutek Wilk wrote: > On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: >> On 03/05/12 16:15, David Vrabel wrote: >>> >>> xen: update VA mapping when releasing memory during setup >>> >>> In xen_memory_setup(), if a page that is being released has a VA >>> mapping this must also be updated. Otherwise, the page will be not >>> released completely -- it will still be referenced in Xen and won't be >>> freed util the mapping is removed and this prevents it from being >>> reallocated at a different PFN. >>> >>> This was already being done for the ISA memory region in >>> xen_ident_map_ISA() but on many systems this was omitting a few pages >>> as many systems marked a few pages below the ISA memory region as >>> reserved in the e820 map. >>> >>> Signed-off-by: David Vrabel >>> --- >> [...] >>> --- a/arch/x86/xen/mmu.c >>> +++ b/arch/x86/xen/mmu.c >>> @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) >>> #endif >>> } >>> >>> -void __init xen_ident_map_ISA(void) >>> -{ >>> - unsigned long pa; >>> - >>> - /* >>> - * If we're dom0, then linear map the ISA machine addresses into >>> - * the kernel's address space. >>> - */ >>> - if (!xen_initial_domain()) >>> - return; >> >> It might look like this test has gone, however the new code which >> updates the VA mapping uses the e820 map and for a domU its map will not >> have a ISA region so there's no mapping to be updated. > > What if you use e820_hole=1 and the pci=xx in the guest? Are these xl configuration options? I'm not familiar with xl. The PCI memory hole should be above 3 GiB so this hole will be will above the memory that will be initially mapped at boot. I've not managed to persuade my test box to passthrough a PCI device to a guest (using xapi as the toolstack) to confirm, though. I'll have another go tomorrow. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 18:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 18:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpAz-0000jf-JI; Tue, 08 May 2012 18:30:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpAx-0000ja-QV for xen-devel@lists.xensource.com; Tue, 08 May 2012 18:30:20 +0000 Received: from [193.109.254.147:32030] by server-4.bemta-14.messagelabs.com id EE/32-11570-B3669AF4; Tue, 08 May 2012 18:30:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336501814!1428334!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE2NDQz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11309 invoked from network); 8 May 2012 18:30:16 -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; 8 May 2012 18:30:16 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48IUA3V025702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 18:30:11 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 q48IU9UL007362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 18:30:09 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 q48IU8fi027481; Tue, 8 May 2012 13:30:08 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 11:30:08 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 892EC4031D; Tue, 8 May 2012 14:24:19 -0400 (EDT) Date: Tue, 8 May 2012 14:24:19 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120508182419.GA9888@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> <20120507184808.GA7249@phenom.dumpdata.com> <4FA96202.9010503@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA96202.9010503@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 07:12:18PM +0100, David Vrabel wrote: > On 07/05/12 19:48, Konrad Rzeszutek Wilk wrote: > > On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: > >> On 03/05/12 16:15, David Vrabel wrote: > >>> > >>> xen: update VA mapping when releasing memory during setup > >>> > >>> In xen_memory_setup(), if a page that is being released has a VA > >>> mapping this must also be updated. Otherwise, the page will be not > >>> released completely -- it will still be referenced in Xen and won't be > >>> freed util the mapping is removed and this prevents it from being > >>> reallocated at a different PFN. > >>> > >>> This was already being done for the ISA memory region in > >>> xen_ident_map_ISA() but on many systems this was omitting a few pages > >>> as many systems marked a few pages below the ISA memory region as > >>> reserved in the e820 map. > >>> > >>> Signed-off-by: David Vrabel > >>> --- > >> [...] > >>> --- a/arch/x86/xen/mmu.c > >>> +++ b/arch/x86/xen/mmu.c > >>> @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > >>> #endif > >>> } > >>> > >>> -void __init xen_ident_map_ISA(void) > >>> -{ > >>> - unsigned long pa; > >>> - > >>> - /* > >>> - * If we're dom0, then linear map the ISA machine addresses into > >>> - * the kernel's address space. > >>> - */ > >>> - if (!xen_initial_domain()) > >>> - return; > >> > >> It might look like this test has gone, however the new code which > >> updates the VA mapping uses the e820 map and for a domU its map will not > >> have a ISA region so there's no mapping to be updated. > > > > What if you use e820_hole=1 and the pci=xx in the guest? > > Are these xl configuration options? I'm not familiar with xl. Yeah. Just have this in your guest config: e820_hole=1 pci=["01:00.0"] (And do the PCI bind/unbind to the xen-pciback module) but looking at the source there is this comment: /* Weed out anything under 1MB */ so I think we are fine. > > The PCI memory hole should be above 3 GiB so this hole will be will > above the memory that will be initially mapped at boot. > > I've not managed to persuade my test box to passthrough a PCI device to > a guest (using xapi as the toolstack) to confirm, though. I'll have > another go tomorrow. > > David > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 18:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 18:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpAz-0000jf-JI; Tue, 08 May 2012 18:30:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpAx-0000ja-QV for xen-devel@lists.xensource.com; Tue, 08 May 2012 18:30:20 +0000 Received: from [193.109.254.147:32030] by server-4.bemta-14.messagelabs.com id EE/32-11570-B3669AF4; Tue, 08 May 2012 18:30:19 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336501814!1428334!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE2NDQz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11309 invoked from network); 8 May 2012 18:30:16 -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; 8 May 2012 18:30:16 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48IUA3V025702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 18:30:11 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 q48IU9UL007362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 18:30:09 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 q48IU8fi027481; Tue, 8 May 2012 13:30:08 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 11:30:08 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 892EC4031D; Tue, 8 May 2012 14:24:19 -0400 (EDT) Date: Tue, 8 May 2012 14:24:19 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20120508182419.GA9888@phenom.dumpdata.com> References: <1334596539-18172-1-git-send-email-konrad.wilk@oracle.com> <20120501163707.GA8741@phenom.dumpdata.com> <4FA27084.4030005@citrix.com> <4FA2A11E.1060907@cantab.net> <4FA2B1EF.8080900@citrix.com> <20120507184808.GA7249@phenom.dumpdata.com> <4FA96202.9010503@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA96202.9010503@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH] auto balloon initial domain and fix dom0_mem=X inconsistencies (v5). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 07:12:18PM +0100, David Vrabel wrote: > On 07/05/12 19:48, Konrad Rzeszutek Wilk wrote: > > On Thu, May 03, 2012 at 05:27:27PM +0100, David Vrabel wrote: > >> On 03/05/12 16:15, David Vrabel wrote: > >>> > >>> xen: update VA mapping when releasing memory during setup > >>> > >>> In xen_memory_setup(), if a page that is being released has a VA > >>> mapping this must also be updated. Otherwise, the page will be not > >>> released completely -- it will still be referenced in Xen and won't be > >>> freed util the mapping is removed and this prevents it from being > >>> reallocated at a different PFN. > >>> > >>> This was already being done for the ISA memory region in > >>> xen_ident_map_ISA() but on many systems this was omitting a few pages > >>> as many systems marked a few pages below the ISA memory region as > >>> reserved in the e820 map. > >>> > >>> Signed-off-by: David Vrabel > >>> --- > >> [...] > >>> --- a/arch/x86/xen/mmu.c > >>> +++ b/arch/x86/xen/mmu.c > >>> @@ -1929,29 +1929,6 @@ static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot) > >>> #endif > >>> } > >>> > >>> -void __init xen_ident_map_ISA(void) > >>> -{ > >>> - unsigned long pa; > >>> - > >>> - /* > >>> - * If we're dom0, then linear map the ISA machine addresses into > >>> - * the kernel's address space. > >>> - */ > >>> - if (!xen_initial_domain()) > >>> - return; > >> > >> It might look like this test has gone, however the new code which > >> updates the VA mapping uses the e820 map and for a domU its map will not > >> have a ISA region so there's no mapping to be updated. > > > > What if you use e820_hole=1 and the pci=xx in the guest? > > Are these xl configuration options? I'm not familiar with xl. Yeah. Just have this in your guest config: e820_hole=1 pci=["01:00.0"] (And do the PCI bind/unbind to the xen-pciback module) but looking at the source there is this comment: /* Weed out anything under 1MB */ so I think we are fine. > > The PCI memory hole should be above 3 GiB so this hole will be will > above the memory that will be initially mapped at boot. > > I've not managed to persuade my test box to passthrough a PCI device to > a guest (using xapi as the toolstack) to confirm, though. I'll have > another go tomorrow. > > David > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 19:16:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 19:16:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRptA-0000zL-8j; Tue, 08 May 2012 19:16:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpt8-0000zG-9m for xen-devel@lists.xensource.com; Tue, 08 May 2012 19:15:58 +0000 Received: from [85.158.143.35:38230] by server-3.bemta-4.messagelabs.com id 34/47-05853-DE079AF4; Tue, 08 May 2012 19:15:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336504556!13289327!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11450 invoked from network); 8 May 2012 19:15:56 -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; 8 May 2012 19:15:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="12363638" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 19:15: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; Tue, 8 May 2012 20:15:55 +0100 Message-ID: <1336504555.4350.22.camel@dagon.hellion.org.uk> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Tue, 8 May 2012 20:15:55 +0100 In-Reply-To: <20120508162426.GD2058@reaktio.net> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 17:24 +0100, Pasi K=E4rkk=E4inen wrote: > On Fri, May 04, 2012 at 12:32:19PM +0100, Ian Campbell wrote: > > On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > > > Anthony -- any idea why the videoram setting doesn't work with upst= ream > > > > qemu? > > > = > > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > > > then, it seams you have to have this value of at least 32MB, otherwise > > > the value is increase in qemu. > > > = > > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > > > size in qemu is fixed to 8MB. > > = > > OK, so this is simply a feature which upstream qemu doesn't have. That's > > fine. > > = > = > Is this something that should be forward-ported from qemu-xen-traditional > to upstream qemu ? If there are reasons why this should be configurable, then I guess so. Are you going to look into that? This doesn't seem like 4.2 material to me though. > > I guess xl.cfg(5) needs updating to make it clear that this option only > > applies to qemu-xen-traditional. > > = > > The docs also currently say that for stdvga the default is 8MB and for > > not stdvga (by which I guess it means Cirrus) the default if 4MB. So I > > guess even this is inaccurate for qemu-xen-upstream? > > = > > Can someone send a patch please? > > = > = > For the documentation patch maybe add this to the 4.2 status todo list > as a reminder :) = Please make requests for additions to the TODO list in the most recent TODO list thread, with a link to the relevant thread. Otherwise the chances are I won't remember when I update the list, since I only look at replies in the TODO threads. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 19:16:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 19:16:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRptA-0000zL-8j; Tue, 08 May 2012 19:16:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRpt8-0000zG-9m for xen-devel@lists.xensource.com; Tue, 08 May 2012 19:15:58 +0000 Received: from [85.158.143.35:38230] by server-3.bemta-4.messagelabs.com id 34/47-05853-DE079AF4; Tue, 08 May 2012 19:15:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336504556!13289327!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11450 invoked from network); 8 May 2012 19:15:56 -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; 8 May 2012 19:15:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="12363638" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 19:15: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; Tue, 8 May 2012 20:15:55 +0100 Message-ID: <1336504555.4350.22.camel@dagon.hellion.org.uk> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Tue, 8 May 2012 20:15:55 +0100 In-Reply-To: <20120508162426.GD2058@reaktio.net> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" , Fantu Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 17:24 +0100, Pasi K=E4rkk=E4inen wrote: > On Fri, May 04, 2012 at 12:32:19PM +0100, Ian Campbell wrote: > > On Fri, 2012-05-04 at 12:21 +0100, Anthony PERARD wrote: > > > On Fri, May 4, 2012 at 9:28 AM, Ian Campbell wrote: > > > > Anthony -- any idea why the videoram setting doesn't work with upst= ream > > > > qemu? > > > = > > > Well, the parameter could be pass to qemu qxl, but it's not yet. But > > > then, it seams you have to have this value of at least 32MB, otherwise > > > the value is increase in qemu. > > > = > > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > > > size in qemu is fixed to 8MB. > > = > > OK, so this is simply a feature which upstream qemu doesn't have. That's > > fine. > > = > = > Is this something that should be forward-ported from qemu-xen-traditional > to upstream qemu ? If there are reasons why this should be configurable, then I guess so. Are you going to look into that? This doesn't seem like 4.2 material to me though. > > I guess xl.cfg(5) needs updating to make it clear that this option only > > applies to qemu-xen-traditional. > > = > > The docs also currently say that for stdvga the default is 8MB and for > > not stdvga (by which I guess it means Cirrus) the default if 4MB. So I > > guess even this is inaccurate for qemu-xen-upstream? > > = > > Can someone send a patch please? > > = > = > For the documentation patch maybe add this to the 4.2 status todo list > as a reminder :) = Please make requests for additions to the TODO list in the most recent TODO list thread, with a link to the relevant thread. Otherwise the chances are I won't remember when I update the list, since I only look at replies in the TODO threads. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 20:42:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 20: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 ) id 1SRrDn-00033W-4J; Tue, 08 May 2012 20:41:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrDl-00033R-5h for xen-devel@lists.xensource.com; Tue, 08 May 2012 20:41:21 +0000 Received: from [85.158.139.83:18227] by server-8.bemta-5.messagelabs.com id 73/A1-26964-0F489AF4; Tue, 08 May 2012 20:41:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336509679!23476638!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24791 invoked from network); 8 May 2012 20:41:19 -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; 8 May 2012 20:41:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="12364286" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 20:41: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, 8 May 2012 21:41:19 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRrDi-0002OD-Tq; Tue, 08 May 2012 20:41:18 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRrDi-0005kX-TH; Tue, 08 May 2012 21:41:18 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 21:41:18 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12806: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12806 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12806/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 9 guest-start fail REGR. vs. 12800 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12800 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail REGR. vs. 12800 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv 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-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue May 08 20:42:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 May 2012 20: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 ) id 1SRrDn-00033W-4J; Tue, 08 May 2012 20:41:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrDl-00033R-5h for xen-devel@lists.xensource.com; Tue, 08 May 2012 20:41:21 +0000 Received: from [85.158.139.83:18227] by server-8.bemta-5.messagelabs.com id 73/A1-26964-0F489AF4; Tue, 08 May 2012 20:41:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336509679!23476638!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzU0OA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24791 invoked from network); 8 May 2012 20:41:19 -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; 8 May 2012 20:41:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="12364286" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 May 2012 20:41: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, 8 May 2012 21:41:19 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SRrDi-0002OD-Tq; Tue, 08 May 2012 20:41:18 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SRrDi-0005kX-TH; Tue, 08 May 2012 21:41:18 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 8 May 2012 21:41:18 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12806: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12806 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12806/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pv 9 guest-start fail REGR. vs. 12800 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12800 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail REGR. vs. 12800 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv 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-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 00:42:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 00:42:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRuy9-0004Ur-CL; Wed, 09 May 2012 00:41:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRuy7-0004Um-OH for xen-devel@lists.xen.org; Wed, 09 May 2012 00:41:27 +0000 Received: from [193.109.254.147:12428] by server-4.bemta-14.messagelabs.com id CB/9C-11570-73DB9AF4; Wed, 09 May 2012 00:41:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336524084!8347376!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMDE4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13977 invoked from network); 9 May 2012 00:41:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 00:41:26 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q490fGp7009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 00:41:17 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 q490fFd6015381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 00:41:15 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 q490fDrr019475; Tue, 8 May 2012 19:41:13 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 17:41:13 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 3054C4031D; Tue, 8 May 2012 20:35:11 -0400 (EDT) Date: Tue, 8 May 2012 20:35:11 -0400 From: Konrad Rzeszutek Wilk To: AP Message-ID: <20120509003510.GA19643@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > (i.e. the outcome of the above printing you added) the problem in > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > attempting XSETBV). What your patch efectively does is take away > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > following message: > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > 00002660 > > > > > > > > ... which is what this message is telling you. > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > xsave=1. > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > added, > > > > to find out why the CR4 write supposedly happening immediately > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > Where did you see that code? Looking at the Linus's tree this is what I > > see > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > So who added that code? I am not seeing it in v3.0 either? > > This is in the Ubuntu 11.10 kernel: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 00:42:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 00:42:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRuy9-0004Ur-CL; Wed, 09 May 2012 00:41:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRuy7-0004Um-OH for xen-devel@lists.xen.org; Wed, 09 May 2012 00:41:27 +0000 Received: from [193.109.254.147:12428] by server-4.bemta-14.messagelabs.com id CB/9C-11570-73DB9AF4; Wed, 09 May 2012 00:41:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336524084!8347376!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyMDE4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13977 invoked from network); 9 May 2012 00:41:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 00:41:26 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q490fGp7009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 00:41:17 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 q490fFd6015381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 00:41:15 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 q490fDrr019475; Tue, 8 May 2012 19:41:13 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 17:41:13 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 3054C4031D; Tue, 8 May 2012 20:35:11 -0400 (EDT) Date: Tue, 8 May 2012 20:35:11 -0400 From: Konrad Rzeszutek Wilk To: AP Message-ID: <20120509003510.GA19643@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > (i.e. the outcome of the above printing you added) the problem in > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > attempting XSETBV). What your patch efectively does is take away > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > following message: > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > 00002660 > > > > > > > > ... which is what this message is telling you. > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > xsave=1. > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > added, > > > > to find out why the CR4 write supposedly happening immediately > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > Where did you see that code? Looking at the Linus's tree this is what I > > see > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > So who added that code? I am not seeing it in v3.0 either? > > This is in the Ubuntu 11.10 kernel: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 05:26:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 05:26:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRzPP-0001o4-6e; Wed, 09 May 2012 05:25:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRzPO-0001nz-48 for xen-devel@lists.xen.org; Wed, 09 May 2012 05:25:54 +0000 Received: from [193.109.254.147:45092] by server-9.bemta-14.messagelabs.com id 23/21-05787-1EFF9AF4; Wed, 09 May 2012 05:25:53 +0000 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336541151!8268126!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8627 invoked from network); 9 May 2012 05:25:52 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 05:25:52 -0000 Received: by vbbfn1 with SMTP id fn1so1663791vbb.32 for ; Tue, 08 May 2012 22:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7c400S3h9BjyM/uglAoitLDXEq9UAl9DtwgahUq/UK0=; b=ShLkF+rUBGZcwX08Jnea5GnW95o25viIWJ0C7jh0NC9kIVg+74fa3Z05knO5Lu+Y61 K8w9q/HY1JvPNSiVFS6mpJ1g/fWI8oFh4RNVAJ+Iu1fn/kgzD4hNa/+w3x87sDUpHlwG 7szDO6KJ+u/T6VeiZZv8YA0CfR1VjcgBLpb0+djLMWdvmK+lyY824R72Z2Ll1S494707 ncHQTNUAZ00Q7RsgoNGTjpUezU0yRN2leQNyOaozl7LNe68+4Q/aX8Rz97HGWbMSlwM7 fbTeViv1cEYdReyba2sRS+C1ypoQR4SHKvcdn4aLSRmLLd7+UfgvyKrdbY/l+PYHl/x2 NvrA== MIME-Version: 1.0 Received: by 10.220.154.2 with SMTP id m2mr13962686vcw.55.1336541150780; Tue, 08 May 2012 22:25:50 -0700 (PDT) Received: by 10.220.35.142 with HTTP; Tue, 8 May 2012 22:25:50 -0700 (PDT) In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> Date: Wed, 9 May 2012 14:25:50 +0900 Message-ID: From: Daniel Castro To: James Harper Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I am writing the PV Driver front end in Seabios. Could you explain your method in a little more detail please? Thanks, Daniel On Mon, May 7, 2012 at 5:53 PM, James Harper wrote: >> > >> > >>> On 07.05.12 at 08:23, Daniel Castro wrote: >> > > Hello List, >> > > >> > > I have a small problem with the ring when transferring blocks the id >> > > on the response is different from the request. >> > > This is the boot up read, count 0. >> > > The guest requests block 0, it has to be located at 7c00. >> > > >> > > I go ahead and create a REQUEST with this data: >> > > ring_req =3D RING_GET_REQUEST(priv,priv->req_prod_pvt); >> > > ring_req->id =3D 9; >> > > ring_req->nr_segments=3D1; >> > > ring_req->operation =3D BLKIF_OP_READ; ring_req->sector_number =3D >> > > (int)op->lba; //sector to be read ring_req->seg[0].gref =3D >> > > (bi->buffer_gref); //this should be get_free_gref(); >> > > ring_req->seg[0].first_sect =3D 0;//op->lba; >> > > ring_req->seg[0].last_sect =3D 7;//op->lba + op->count; >> > > >> > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); =A0//return >> > notify=3D0 >> > > if(notify){ >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"Start notify procedure\n"); >> > > =A0 =A0 =A0 =A0 =A0 evtchn_send_t send; >> > > =A0 =A0 =A0 =A0 =A0 send.port =3D (bi->port); >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"In notify before hypercall port is %d= \n",send.port); >> > > =A0 =A0 =A0 =A0 =A0 //hypercall_event_channel_op(EVTCHNOP_send, &sen= d); >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"HYPERCALL read operation notify res %= d\n", >> > > hypercall_event_channel_op(EVTCHNOP_send,&send)); >> > > } >> > > ring_res =3D RING_GET_RESPONSE((priv),(temp->rsp_prod)); >> > > Then I get: >> > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is >> > > the line: >> > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", >> > > ring_res,ring_res->id,ring_res->status,ring_res->operation); >> > > >> > > >> > > The id should be the same on both the request and response, there >> > > are bi ither requests on the fly. >> > > >> > > Any clue?=3D >> > >> > With status happening to be 9 when id should be, is this perhaps a >> > broken response structure definition? >> > >> >> That would be my guess too. The structure aligns differently under 64 an= d 32 >> bits so I'd guess the OP is talking between the two. >> > > Further to this, Dom0 sets the "protocol" entry in the frontend xenstore = (/local/domain//device/vbd//protocol) to tell it what alig= nment it is using. I wrote GPLPV before this setting existed so I solved th= e problem by sending 2 invalid requests down the ring and checking the resp= onse. If the fields have shifted around I assume that dom0 is not the same = bit width as the domu and switch structure definitions on the fly. > > Are you writing a new frontend driver? > > James > -- = +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 05:26:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 05:26:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRzPP-0001o4-6e; Wed, 09 May 2012 05:25:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SRzPO-0001nz-48 for xen-devel@lists.xen.org; Wed, 09 May 2012 05:25:54 +0000 Received: from [193.109.254.147:45092] by server-9.bemta-14.messagelabs.com id 23/21-05787-1EFF9AF4; Wed, 09 May 2012 05:25:53 +0000 X-Env-Sender: evil.dani@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1336541151!8268126!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8627 invoked from network); 9 May 2012 05:25:52 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 05:25:52 -0000 Received: by vbbfn1 with SMTP id fn1so1663791vbb.32 for ; Tue, 08 May 2012 22:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7c400S3h9BjyM/uglAoitLDXEq9UAl9DtwgahUq/UK0=; b=ShLkF+rUBGZcwX08Jnea5GnW95o25viIWJ0C7jh0NC9kIVg+74fa3Z05knO5Lu+Y61 K8w9q/HY1JvPNSiVFS6mpJ1g/fWI8oFh4RNVAJ+Iu1fn/kgzD4hNa/+w3x87sDUpHlwG 7szDO6KJ+u/T6VeiZZv8YA0CfR1VjcgBLpb0+djLMWdvmK+lyY824R72Z2Ll1S494707 ncHQTNUAZ00Q7RsgoNGTjpUezU0yRN2leQNyOaozl7LNe68+4Q/aX8Rz97HGWbMSlwM7 fbTeViv1cEYdReyba2sRS+C1ypoQR4SHKvcdn4aLSRmLLd7+UfgvyKrdbY/l+PYHl/x2 NvrA== MIME-Version: 1.0 Received: by 10.220.154.2 with SMTP id m2mr13962686vcw.55.1336541150780; Tue, 08 May 2012 22:25:50 -0700 (PDT) Received: by 10.220.35.142 with HTTP; Tue, 8 May 2012 22:25:50 -0700 (PDT) In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> Date: Wed, 9 May 2012 14:25:50 +0900 Message-ID: From: Daniel Castro To: James Harper Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I am writing the PV Driver front end in Seabios. Could you explain your method in a little more detail please? Thanks, Daniel On Mon, May 7, 2012 at 5:53 PM, James Harper wrote: >> > >> > >>> On 07.05.12 at 08:23, Daniel Castro wrote: >> > > Hello List, >> > > >> > > I have a small problem with the ring when transferring blocks the id >> > > on the response is different from the request. >> > > This is the boot up read, count 0. >> > > The guest requests block 0, it has to be located at 7c00. >> > > >> > > I go ahead and create a REQUEST with this data: >> > > ring_req =3D RING_GET_REQUEST(priv,priv->req_prod_pvt); >> > > ring_req->id =3D 9; >> > > ring_req->nr_segments=3D1; >> > > ring_req->operation =3D BLKIF_OP_READ; ring_req->sector_number =3D >> > > (int)op->lba; //sector to be read ring_req->seg[0].gref =3D >> > > (bi->buffer_gref); //this should be get_free_gref(); >> > > ring_req->seg[0].first_sect =3D 0;//op->lba; >> > > ring_req->seg[0].last_sect =3D 7;//op->lba + op->count; >> > > >> > > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY((priv),notify); =A0//return >> > notify=3D0 >> > > if(notify){ >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"Start notify procedure\n"); >> > > =A0 =A0 =A0 =A0 =A0 evtchn_send_t send; >> > > =A0 =A0 =A0 =A0 =A0 send.port =3D (bi->port); >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"In notify before hypercall port is %d= \n",send.port); >> > > =A0 =A0 =A0 =A0 =A0 //hypercall_event_channel_op(EVTCHNOP_send, &sen= d); >> > > =A0 =A0 =A0 =A0 =A0 dprintf(1,"HYPERCALL read operation notify res %= d\n", >> > > hypercall_event_channel_op(EVTCHNOP_send,&send)); >> > > } >> > > ring_res =3D RING_GET_RESPONSE((priv),(temp->rsp_prod)); >> > > Then I get: >> > > FAIL RING RESPONSE 0x0009a040 id:256 status:9 operation 0 this is >> > > the line: >> > > dprintf(1,"FAIL RING RESPONSE %p id:%d status:%d operation %d\n", >> > > ring_res,ring_res->id,ring_res->status,ring_res->operation); >> > > >> > > >> > > The id should be the same on both the request and response, there >> > > are bi ither requests on the fly. >> > > >> > > Any clue?=3D >> > >> > With status happening to be 9 when id should be, is this perhaps a >> > broken response structure definition? >> > >> >> That would be my guess too. The structure aligns differently under 64 an= d 32 >> bits so I'd guess the OP is talking between the two. >> > > Further to this, Dom0 sets the "protocol" entry in the frontend xenstore = (/local/domain//device/vbd//protocol) to tell it what alig= nment it is using. I wrote GPLPV before this setting existed so I solved th= e problem by sending 2 invalid requests down the ring and checking the resp= onse. If the fields have shifted around I assume that dom0 is not the same = bit width as the domu and switch structure definitions on the fly. > > Are you writing a new frontend driver? > > James > -- = +-=3D=3D=3D=3D=3D---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | |=A0=A0 | Consultant/Programmer.| | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 06:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 06: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 ) id 1SS0Eg-0002SU-BU; Wed, 09 May 2012 06:18:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS0Ef-0002SO-5D for xen-devel@lists.xensource.com; Wed, 09 May 2012 06:18:53 +0000 Received: from [85.158.138.51:48220] by server-4.bemta-3.messagelabs.com id 2B/E3-15341-C4C0AAF4; Wed, 09 May 2012 06:18:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336544331!19652855!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Nzc4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 968 invoked from network); 9 May 2012 06:18: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; 9 May 2012 06:18:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,556,1330905600"; d="scan'208";a="12368158" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:18:50 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:18:50 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS0Ec-0005SJ-B1; Wed, 09 May 2012 06:18:50 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS0Ec-0005sA-9A; Wed, 09 May 2012 07:18:50 +0100 To: Message-ID: From: xen.org Date: Wed, 9 May 2012 07:18:50 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12822: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12822 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12822/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 06:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 06: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 ) id 1SS0Eg-0002SU-BU; Wed, 09 May 2012 06:18:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS0Ef-0002SO-5D for xen-devel@lists.xensource.com; Wed, 09 May 2012 06:18:53 +0000 Received: from [85.158.138.51:48220] by server-4.bemta-3.messagelabs.com id 2B/E3-15341-C4C0AAF4; Wed, 09 May 2012 06:18:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336544331!19652855!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Nzc4NA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 968 invoked from network); 9 May 2012 06:18: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; 9 May 2012 06:18:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,556,1330905600"; d="scan'208";a="12368158" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:18:50 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:18:50 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS0Ec-0005SJ-B1; Wed, 09 May 2012 06:18:50 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS0Ec-0005sA-9A; Wed, 09 May 2012 07:18:50 +0100 To: Message-ID: From: xen.org Date: Wed, 9 May 2012 07:18:50 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12822: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12822 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12822/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12785 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 06:26:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 06: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 ) id 1SS0LP-0002cq-6L; Wed, 09 May 2012 06:25:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS0LN-0002ck-RJ for xen-devel@lists.xen.org; Wed, 09 May 2012 06:25:50 +0000 Received: from [193.109.254.147:42465] by server-2.bemta-14.messagelabs.com id CC/8D-19409-CED0AAF4; Wed, 09 May 2012 06:25:48 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336544747!8294182!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMxODM5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11641 invoked from network); 9 May 2012 06:25:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-16.tower-27.messagelabs.com with SMTP; 9 May 2012 06:25:48 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 08 May 2012 23:25:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97969684" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 08 May 2012 23:25:46 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 May 2012 23:25:46 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Wed, 9 May 2012 14:25:44 +0800 From: "Hao, Xudong" To: Jan Beulich , Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnCACAk9AP/+QLfwgAMLFgD//iScoA== Date: Wed, 9 May 2012 06:25:43 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC005B@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> <4FA906780200007800082364@nat28.tlf.novell.com> In-Reply-To: <4FA906780200007800082364@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: "Zhang, Xiantao" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, May 08, 2012 5:42 PM > To: Hao, Xudong; Konrad Rzeszutek Wilk > Cc: xen-devel > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 08.05.12 at 11:05, "Hao, Xudong" wrote: > >> -----Original Message----- > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> > > Don't you need to disable this when the device is un-assigned from the > >> guest? > >> > > > >> > > >> > I don't think this need to be disabled when device is un-assigned from > > guest. > >> If host want to use device again, the host device driver need re-load, so > >> whether disabling ltr/obff is up to host device driver. > >> > >> What if the driver isn't doing that? > > > > Make it clear, here host side do not be considered, host has its own driver. > > The only thing is to make sure ltr/obff is enabled before assigning guest, so > > that benefit on power. > > > > Since device is owned by pciback again when it un-assigned from guest, we > > need not disable explicitly. > > As you didn't answer my respective earlier question - _if_ this is a > feature needing enabling (and parameter tweaking), I'd imply there > are possible incompatibilities (i.e. reasons for not enabling this > always), and hence this shouldn't be done universally (and with > fixed values for the parameters) _and_ should be properly reset. > Only Xen administrator can hide a device by pciback, and can assign a device to guest. These power feature such as ltr and obff should be enabled by a sys-admin, I do not know which situation is a possible disabling these features, and why sys-admin want to disable them? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 06:26:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 06: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 ) id 1SS0LP-0002cq-6L; Wed, 09 May 2012 06:25:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS0LN-0002ck-RJ for xen-devel@lists.xen.org; Wed, 09 May 2012 06:25:50 +0000 Received: from [193.109.254.147:42465] by server-2.bemta-14.messagelabs.com id CC/8D-19409-CED0AAF4; Wed, 09 May 2012 06:25:48 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336544747!8294182!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMxODM5\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11641 invoked from network); 9 May 2012 06:25:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-16.tower-27.messagelabs.com with SMTP; 9 May 2012 06:25:48 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 08 May 2012 23:25:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="97969684" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 08 May 2012 23:25:46 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 May 2012 23:25:46 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Wed, 9 May 2012 14:25:44 +0800 From: "Hao, Xudong" To: Jan Beulich , Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Thread-Index: Ac0pyagkwt+FJVzZS0ux0suhpxgVSf//2AEA//y3FnCACAk9AP/+QLfwgAMLFgD//iScoA== Date: Wed, 9 May 2012 06:25:43 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC005B@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDAD88C@SHSMSX102.ccr.corp.intel.com> <20120504132046.GD26418@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDADF10@SHSMSX102.ccr.corp.intel.com> <20120507135410.GD361@phenom.dumpdata.com> <403610A45A2B5242BD291EDAE8B37D300FDBDA79@SHSMSX102.ccr.corp.intel.com> <4FA906780200007800082364@nat28.tlf.novell.com> In-Reply-To: <4FA906780200007800082364@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: "Zhang, Xiantao" , xen-devel Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, May 08, 2012 5:42 PM > To: Hao, Xudong; Konrad Rzeszutek Wilk > Cc: xen-devel > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is owned > by pciback > > >>> On 08.05.12 at 11:05, "Hao, Xudong" wrote: > >> -----Original Message----- > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> On Sun, May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote: > >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > >> > > Don't you need to disable this when the device is un-assigned from the > >> guest? > >> > > > >> > > >> > I don't think this need to be disabled when device is un-assigned from > > guest. > >> If host want to use device again, the host device driver need re-load, so > >> whether disabling ltr/obff is up to host device driver. > >> > >> What if the driver isn't doing that? > > > > Make it clear, here host side do not be considered, host has its own driver. > > The only thing is to make sure ltr/obff is enabled before assigning guest, so > > that benefit on power. > > > > Since device is owned by pciback again when it un-assigned from guest, we > > need not disable explicitly. > > As you didn't answer my respective earlier question - _if_ this is a > feature needing enabling (and parameter tweaking), I'd imply there > are possible incompatibilities (i.e. reasons for not enabling this > always), and hence this shouldn't be done universally (and with > fixed values for the parameters) _and_ should be properly reset. > Only Xen administrator can hide a device by pciback, and can assign a device to guest. These power feature such as ltr and obff should be enabled by a sys-admin, I do not know which situation is a possible disabling these features, and why sys-admin want to disable them? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 07:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 07: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 ) id 1SS1jP-00034f-Qw; Wed, 09 May 2012 07:54:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS1jN-00034a-NR for xen-devel@lists.xen.org; Wed, 09 May 2012 07:54:41 +0000 Received: from [85.158.143.99:3329] by server-1.bemta-4.messagelabs.com id 81/28-20925-1C22AAF4; Wed, 09 May 2012 07:54:41 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-16.tower-216.messagelabs.com!1336550077!15921150!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13176 invoked from network); 9 May 2012 07:54:40 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 07:54:40 -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 ) id 1SS1jD-00006i-84; Wed, 09 May 2012 17:54:31 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 17:54:31 +1000 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, 9 May 2012 17:54:30 +1000 From: James Harper To: Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DCAAAKHAIACRCsAgADOceA= Date: Wed, 9 May 2012 07:54:29 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> In-Reply-To: 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 May 2012 07:54:31.0062 (UTC) FILETIME=[F7588B60:01CD2DB8] X-Really-From-Bendigo-IT: magichashvalue Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > I am writing the PV Driver front end in Seabios. > > Could you explain your method in a little more detail please? > I'm not sure that my way is the best way. The existing linux pv drivers should do what you want - have a look at the source. If you really want to look at my code you can get it from hg and have a look. It's in the xenvbd driver. And I think I got it backwards in a previous email. It seems that the frontend writes the protocol into the xenstore, eg "x86_64-abi" for 64 bit. You should probably just make sure your structures are correctly laid out for a 32 bit system and then write the correct protocol string into the frontend when you set up communications and that should ensure that it will work on all but the most ancient Xen implementations. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 07:55:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 07: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 ) id 1SS1jP-00034f-Qw; Wed, 09 May 2012 07:54:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS1jN-00034a-NR for xen-devel@lists.xen.org; Wed, 09 May 2012 07:54:41 +0000 Received: from [85.158.143.99:3329] by server-1.bemta-4.messagelabs.com id 81/28-20925-1C22AAF4; Wed, 09 May 2012 07:54:41 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-16.tower-216.messagelabs.com!1336550077!15921150!1 X-Originating-IP: [203.16.224.4] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13176 invoked from network); 9 May 2012 07:54:40 -0000 Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au) (203.16.224.4) by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 07:54:40 -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 ) id 1SS1jD-00006i-84; Wed, 09 May 2012 17:54:31 +1000 Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 17:54:31 +1000 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, 9 May 2012 17:54:30 +1000 From: James Harper To: Daniel Castro Thread-Topic: [Xen-devel] Little help with blk ring Thread-Index: AQHNLBr5hYy2wnYk20yOkqACgRrWVJa9VeyAgACr7DCAAAKHAIACRCsAgADOceA= Date: Wed, 9 May 2012 07:54:29 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> In-Reply-To: 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 May 2012 07:54:31.0062 (UTC) FILETIME=[F7588B60:01CD2DB8] X-Really-From-Bendigo-IT: magichashvalue Cc: Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > I am writing the PV Driver front end in Seabios. > > Could you explain your method in a little more detail please? > I'm not sure that my way is the best way. The existing linux pv drivers should do what you want - have a look at the source. If you really want to look at my code you can get it from hg and have a look. It's in the xenvbd driver. And I think I got it backwards in a previous email. It seems that the frontend writes the protocol into the xenstore, eg "x86_64-abi" for 64 bit. You should probably just make sure your structures are correctly laid out for a 32 bit system and then write the correct protocol string into the frontend when you set up communications and that should ensure that it will work on all but the most ancient Xen implementations. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:19:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08: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 ) id 1SS26w-0003in-4P; Wed, 09 May 2012 08:19:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS26u-0003ii-Gx for xen-devel@lists.xen.org; Wed, 09 May 2012 08:19:00 +0000 Received: from [85.158.139.83:17873] by server-9.bemta-5.messagelabs.com id 14/79-09826-3782AAF4; Wed, 09 May 2012 08:18:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336551539!20070352!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Nzc4NA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13292 invoked from network); 9 May 2012 08:18:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 08:18:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12370860" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:18: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, 9 May 2012 09:18:58 +0100 Message-ID: <1336551537.25514.5.camel@zakaz.uk.xensource.com> From: Ian Campbell To: James Harper Date: Wed, 9 May 2012 09:18:57 +0100 In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Daniel Castro , Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 08:54 +0100, James Harper wrote: > > > > I am writing the PV Driver front end in Seabios. > > > > Could you explain your method in a little more detail please? > > > > I'm not sure that my way is the best way. The existing linux pv > drivers should do what you want - have a look at the source. If you > really want to look at my code you can get it from hg and have a look. > It's in the xenvbd driver. > > And I think I got it backwards in a previous email. It seems that the > frontend writes the protocol into the xenstore, eg "x86_64-abi" for 64 > bit. That's right, xen/include/public/io/protocols.h defines the valid protocols, your frontend should publish the one it implements (probably x86_32-abi for a SeaBIOS driver). > You should probably just make sure your structures are correctly laid > out for a 32 bit system and then write the correct protocol string > into the frontend when you set up communications and that should > ensure that it will work on all but the most ancient Xen > implementations. > > James > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:19:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08: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 ) id 1SS26w-0003in-4P; Wed, 09 May 2012 08:19:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS26u-0003ii-Gx for xen-devel@lists.xen.org; Wed, 09 May 2012 08:19:00 +0000 Received: from [85.158.139.83:17873] by server-9.bemta-5.messagelabs.com id 14/79-09826-3782AAF4; Wed, 09 May 2012 08:18:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336551539!20070352!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5Nzc4NA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13292 invoked from network); 9 May 2012 08:18:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 08:18:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12370860" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:18: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, 9 May 2012 09:18:58 +0100 Message-ID: <1336551537.25514.5.camel@zakaz.uk.xensource.com> From: Ian Campbell To: James Harper Date: Wed, 9 May 2012 09:18:57 +0100 In-Reply-To: <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> References: <4FA7A2F90200007800081F7F@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B1AFB73E8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFB7482@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B1AFDBE11@BITCOM1.int.sbss.com.au> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Daniel Castro , Jan Beulich , xen-devel Subject: Re: [Xen-devel] Little help with blk ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 08:54 +0100, James Harper wrote: > > > > I am writing the PV Driver front end in Seabios. > > > > Could you explain your method in a little more detail please? > > > > I'm not sure that my way is the best way. The existing linux pv > drivers should do what you want - have a look at the source. If you > really want to look at my code you can get it from hg and have a look. > It's in the xenvbd driver. > > And I think I got it backwards in a previous email. It seems that the > frontend writes the protocol into the xenstore, eg "x86_64-abi" for 64 > bit. That's right, xen/include/public/io/protocols.h defines the valid protocols, your frontend should publish the one it implements (probably x86_32-abi for a SeaBIOS driver). > You should probably just make sure your structures are correctly laid > out for a 32 bit system and then write the correct protocol string > into the frontend when you set up communications and that should > ensure that it will work on all but the most ancient Xen > implementations. > > James > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:33:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08:33:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Kj-0004Bj-IJ; Wed, 09 May 2012 08:33:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Ki-0004Be-3h for xen-devel@lists.xen.org; Wed, 09 May 2012 08:33:16 +0000 Received: from [85.158.138.51:17052] by server-10.bemta-3.messagelabs.com id C3/64-29478-BCB2AAF4; Wed, 09 May 2012 08:33:15 +0000 X-Env-Sender: yongjie.ren@intel.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336552392!17121883!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc2NjQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23010 invoked from network); 9 May 2012 08:33:14 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-174.messagelabs.com with SMTP; 9 May 2012 08:33:14 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 09 May 2012 01:33:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98006581" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 09 May 2012 01:33:11 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 May 2012 01:33:11 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Wed, 9 May 2012 16:33:09 +0800 From: "Ren, Yongjie" To: Konrad Rzeszutek Wilk , "Wu, GabrielX" Thread-Topic: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKfeXJsb0jMTM1kmo0tMgmN2cyJbAsTkQ Date: Wed, 9 May 2012 08:33:09 +0000 Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> In-Reply-To: <20120504131244.GA26418@phenom.dumpdata.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek > Wilk > Sent: Friday, May 04, 2012 9:13 PM > To: Wu, GabrielX > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... > > On Fri, May 04, 2012 at 10:06:26AM +0000, Wu, GabrielX wrote: > > Hi all, > > > > This is the test report of xen-unstable tree. There are one bug found. > > > > Version Info: > > > ============================================================ > ===== > > xen-changeset: 25256 > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > Please update your dom0. I think we can use 3.4-RCx kernel as dom0 when sending the report next time. > > > ============================================================ > ===== > > > > New issue(1) > > ============== > > 1. cpu weight out of range error when create hvm domU > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > And what is the guest config? Does it have any cpu weights? Added the config in the BZ. It doesn't have any cpu weight in config. Some other person also reported this issue in the mailing list several days ago. > > > > Fixed issue(0) > > ============== > > > > Old issues(8) > > ============== > > 1. [ACPI] System cann't resume after do suspend > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 > > That shouldn't be a surprise. The patches for that are not yet > in the mainline. > OK. Leave it here as a tracking. > > 2. [XL]"xl vcpu-set" causes dom0 crash or panic > > This should be fixed with 3.4-rc5. > Will update this status in next report based on 3.4-RCx. > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > 3. [VT-D]fail to detach NIC from guest > > Hmm, the last update is from a year ago. Are you sure this > is an issue? > Yeah, it still exist. It may be a similar issue with BZ# 1812. According to our recent testing, it something about VNC console. Also added some latest info in the BZ. > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > the bug talks about 2.6.32. Can you update it to include the > 3.4 (or 3.3) dmesg output? > This is about 32bit Xen. As we don't test 32bit Xen for a long time, we may update it when we're free. > > 5. [VT-D] device reset fail when create/destroy guest > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > Does this happen if you manually echo 1 > ../reset? And is this > an issue with the kernel if you upgrade it to 3.4-rc5? > When doing 'echo 1 >../reset', I get the same error as list in the BZ. "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". This bug only exists when we use 'pcistub' to hide a device. If using 'pciback' to hide the device, it doesn't show any error info. If Xen will support both 'pcisback' and 'pcistub' to hide a device, I'll leave the bug open in BZ. > > 6. when detaching a VF from hvm guest, "xl dmesg" will show some > warning information > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 > > .. Not sure about that. > Oh, it has been fixed by Jan. Marked as verified. > > 7. RHEL6.2/6.1 guest runs quite slow > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 > > Is the issue present when using an LVM disk? > Not sure about this, because we don't use LVM in our testing. We're still testing this bug. If any update, we'll add it in the BZ. > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > Where does it slow down? When bringing the NIC down or in specific > cases? > Is this an issue with if you are using a different guest (say Fedora Core 16?) > We found it is related to 'stdgva' option in guest config file. If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. Also updated BZ, you can get detailed info in BZ. > > > > Thanks, > > Wu Ronghui(Gabriel) > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:33:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08:33:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Kj-0004Bj-IJ; Wed, 09 May 2012 08:33:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Ki-0004Be-3h for xen-devel@lists.xen.org; Wed, 09 May 2012 08:33:16 +0000 Received: from [85.158.138.51:17052] by server-10.bemta-3.messagelabs.com id C3/64-29478-BCB2AAF4; Wed, 09 May 2012 08:33:15 +0000 X-Env-Sender: yongjie.ren@intel.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336552392!17121883!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc2NjQ2\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23010 invoked from network); 9 May 2012 08:33:14 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-174.messagelabs.com with SMTP; 9 May 2012 08:33:14 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 09 May 2012 01:33:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98006581" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 09 May 2012 01:33:11 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 May 2012 01:33:11 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Wed, 9 May 2012 16:33:09 +0800 From: "Ren, Yongjie" To: Konrad Rzeszutek Wilk , "Wu, GabrielX" Thread-Topic: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... Thread-Index: AQHNKfeXJsb0jMTM1kmo0tMgmN2cyJbAsTkQ Date: Wed, 9 May 2012 08:33:09 +0000 Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> In-Reply-To: <20120504131244.GA26418@phenom.dumpdata.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek > Wilk > Sent: Friday, May 04, 2012 9:13 PM > To: Wu, GabrielX > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... > > On Fri, May 04, 2012 at 10:06:26AM +0000, Wu, GabrielX wrote: > > Hi all, > > > > This is the test report of xen-unstable tree. There are one bug found. > > > > Version Info: > > > ============================================================ > ===== > > xen-changeset: 25256 > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > Please update your dom0. I think we can use 3.4-RCx kernel as dom0 when sending the report next time. > > > ============================================================ > ===== > > > > New issue(1) > > ============== > > 1. cpu weight out of range error when create hvm domU > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > And what is the guest config? Does it have any cpu weights? Added the config in the BZ. It doesn't have any cpu weight in config. Some other person also reported this issue in the mailing list several days ago. > > > > Fixed issue(0) > > ============== > > > > Old issues(8) > > ============== > > 1. [ACPI] System cann't resume after do suspend > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707 > > That shouldn't be a surprise. The patches for that are not yet > in the mainline. > OK. Leave it here as a tracking. > > 2. [XL]"xl vcpu-set" causes dom0 crash or panic > > This should be fixed with 3.4-rc5. > Will update this status in next report based on 3.4-RCx. > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > 3. [VT-D]fail to detach NIC from guest > > Hmm, the last update is from a year ago. Are you sure this > is an issue? > Yeah, it still exist. It may be a similar issue with BZ# 1812. According to our recent testing, it something about VNC console. Also added some latest info in the BZ. > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > the bug talks about 2.6.32. Can you update it to include the > 3.4 (or 3.3) dmesg output? > This is about 32bit Xen. As we don't test 32bit Xen for a long time, we may update it when we're free. > > 5. [VT-D] device reset fail when create/destroy guest > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > Does this happen if you manually echo 1 > ../reset? And is this > an issue with the kernel if you upgrade it to 3.4-rc5? > When doing 'echo 1 >../reset', I get the same error as list in the BZ. "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". This bug only exists when we use 'pcistub' to hide a device. If using 'pciback' to hide the device, it doesn't show any error info. If Xen will support both 'pcisback' and 'pcistub' to hide a device, I'll leave the bug open in BZ. > > 6. when detaching a VF from hvm guest, "xl dmesg" will show some > warning information > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1809 > > .. Not sure about that. > Oh, it has been fixed by Jan. Marked as verified. > > 7. RHEL6.2/6.1 guest runs quite slow > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811 > > Is the issue present when using an LVM disk? > Not sure about this, because we don't use LVM in our testing. We're still testing this bug. If any update, we'll add it in the BZ. > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > Where does it slow down? When bringing the NIC down or in specific > cases? > Is this an issue with if you are using a different guest (say Fedora Core 16?) > We found it is related to 'stdgva' option in guest config file. If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. Also updated BZ, you can get detailed info in BZ. > > > > Thanks, > > Wu Ronghui(Gabriel) > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:47:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08:47:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2YC-0004XY-J2; Wed, 09 May 2012 08:47:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2YB-0004XJ-2m for xen-devel@lists.xen.org; Wed, 09 May 2012 08:47:11 +0000 Received: from [85.158.143.35:20383] by server-1.bemta-4.messagelabs.com id D3/E8-20925-E0F2AAF4; Wed, 09 May 2012 08:47:10 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336553213!15271421!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM1OTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31933 invoked from network); 9 May 2012 08:46:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 08:46:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25009910" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 04:46:52 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 04:46:52 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS2Xr-0003ea-Qg for xen-devel@lists.xen.org; Wed, 09 May 2012 09:46:51 +0100 Message-ID: <4FAA2EFC.3030609@citrix.com> Date: Wed, 9 May 2012 09:46:52 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: "xen-devel@lists.xen.org" References: <1334592052-7995-1-git-send-email-roger.pau@citrix.com> In-Reply-To: <1334592052-7995-1-git-send-email-roger.pau@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: make libxl_device_{vkb, vfb}_add take a dummy ao X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne escribi=F3: > Add a dummy ao parameter to both functions, since they may become slow in= the > future. > > Signed-off-by: Roger Pau Monne This is completely wrong, please don't even review it. > --- > > Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used" > > tools/libxl/libxl.c | 20 ++++++++++++-------- > tools/libxl/libxl.h | 6 ++++-- > tools/libxl/libxl_create.c | 6 +++--- > tools/libxl/libxl_dm.c | 4 ++-- > 4 files changed, 21 insertions(+), 15 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 44a54cb..3fd8d5b 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -2208,9 +2208,10 @@ static int libxl__device_from_vkb(libxl__gc *gc, u= int32_t domid, > return 0; > } > > -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb) > +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb, > + const libxl_asyncop_how *ao_how) > { > - GC_INIT(ctx); > + AO_CREATE(ctx, domid, ao_how); > flexarray_t *front; > flexarray_t *back; > libxl__device device; > @@ -2255,8 +2256,9 @@ out_free: > flexarray_free(back); > flexarray_free(front); > out: > - GC_FREE; > - return rc; > + /* Dummy ao */ > + libxl__ao_complete(egc, ao, rc); > + return AO_INPROGRESS; > } > > int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, > @@ -2339,9 +2341,10 @@ static int libxl__device_from_vfb(libxl__gc *gc, u= int32_t domid, > return 0; > } > > -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb) > +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb, > + const libxl_asyncop_how *ao_how) > { > - GC_INIT(ctx); > + AO_CREATE(ctx, domid, ao_how); > flexarray_t *front; > flexarray_t *back; > libxl__device device; > @@ -2399,8 +2402,9 @@ out_free: > flexarray_free(front); > flexarray_free(back); > out: > - GC_FREE; > - return rc; > + /* Dummy ao */ > + libxl__ao_complete(egc, ao, rc); > + return AO_INPROGRESS; > } > > int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h > index 6da6107..ce89b31 100644 > --- a/tools/libxl/libxl.h > +++ b/tools/libxl/libxl.h > @@ -563,14 +563,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32= _t domid, > libxl_device_nic *nic, libxl_nicinfo *nic= info); > > /* Keyboard */ > -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb); > +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb, > + const libxl_asyncop_how *ao_how); > 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_devi= ce_vkb *vkb); > > /* Framebuffer */ > -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb); > +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb, > + const libxl_asyncop_how *ao_how); > int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, > libxl_device_vfb *vfb, > const libxl_asyncop_how *ao_how); > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index a1f5731..39e9257 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_doma= in_config *d_config, > libxl__device_console_dispose(&console); > > libxl_device_vkb_init(&vkb); > - libxl_device_vkb_add(ctx, domid,&vkb); > + libxl_device_vkb_add(ctx, domid,&vkb, 0); > libxl_device_vkb_dispose(&vkb); > > ret =3D libxl__create_device_model(gc, domid, d_config, > @@ -646,8 +646,8 @@ static int do_domain_create(libxl__gc *gc, libxl_doma= in_config *d_config, > libxl__device_console console; > > for (i =3D 0; i< d_config->num_vfbs; i++) { > - libxl_device_vfb_add(ctx, domid,&d_config->vfbs[i]); > - libxl_device_vkb_add(ctx, domid,&d_config->vkbs[i]); > + libxl_device_vfb_add(ctx, domid,&d_config->vfbs[i], 0); > + libxl_device_vkb_add(ctx, domid,&d_config->vkbs[i], 0); > } > > ret =3D init_console_info(&console, 0); > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 8dc588d..4a2b5c1 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -804,10 +804,10 @@ retry_transaction: > if (ret) > goto out_free; > } > - ret =3D libxl_device_vfb_add(ctx, dm_domid,&dm_config.vfbs[0]); > + ret =3D libxl_device_vfb_add(ctx, dm_domid,&dm_config.vfbs[0], 0); > if (ret) > goto out_free; > - ret =3D libxl_device_vkb_add(ctx, dm_domid,&dm_config.vkbs[0]); > + ret =3D libxl_device_vkb_add(ctx, dm_domid,&dm_config.vkbs[0], 0); > if (ret) > goto out_free; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 08:47:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 08:47:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2YC-0004XY-J2; Wed, 09 May 2012 08:47:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2YB-0004XJ-2m for xen-devel@lists.xen.org; Wed, 09 May 2012 08:47:11 +0000 Received: from [85.158.143.35:20383] by server-1.bemta-4.messagelabs.com id D3/E8-20925-E0F2AAF4; Wed, 09 May 2012 08:47:10 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336553213!15271421!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM1OTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31933 invoked from network); 9 May 2012 08:46:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 08:46:54 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25009910" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 04:46:52 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 04:46:52 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS2Xr-0003ea-Qg for xen-devel@lists.xen.org; Wed, 09 May 2012 09:46:51 +0100 Message-ID: <4FAA2EFC.3030609@citrix.com> Date: Wed, 9 May 2012 09:46:52 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: "xen-devel@lists.xen.org" References: <1334592052-7995-1-git-send-email-roger.pau@citrix.com> In-Reply-To: <1334592052-7995-1-git-send-email-roger.pau@citrix.com> Subject: Re: [Xen-devel] [PATCH] libxl: make libxl_device_{vkb, vfb}_add take a dummy ao X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne escribi=F3: > Add a dummy ao parameter to both functions, since they may become slow in= the > future. > > Signed-off-by: Roger Pau Monne This is completely wrong, please don't even review it. > --- > > Requires Ian Jackson's "libxl: Allow AO_GC and EGC_GC even if not used" > > tools/libxl/libxl.c | 20 ++++++++++++-------- > tools/libxl/libxl.h | 6 ++++-- > tools/libxl/libxl_create.c | 6 +++--- > tools/libxl/libxl_dm.c | 4 ++-- > 4 files changed, 21 insertions(+), 15 deletions(-) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 44a54cb..3fd8d5b 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -2208,9 +2208,10 @@ static int libxl__device_from_vkb(libxl__gc *gc, u= int32_t domid, > return 0; > } > > -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb) > +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb, > + const libxl_asyncop_how *ao_how) > { > - GC_INIT(ctx); > + AO_CREATE(ctx, domid, ao_how); > flexarray_t *front; > flexarray_t *back; > libxl__device device; > @@ -2255,8 +2256,9 @@ out_free: > flexarray_free(back); > flexarray_free(front); > out: > - GC_FREE; > - return rc; > + /* Dummy ao */ > + libxl__ao_complete(egc, ao, rc); > + return AO_INPROGRESS; > } > > int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, > @@ -2339,9 +2341,10 @@ static int libxl__device_from_vfb(libxl__gc *gc, u= int32_t domid, > return 0; > } > > -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb) > +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb, > + const libxl_asyncop_how *ao_how) > { > - GC_INIT(ctx); > + AO_CREATE(ctx, domid, ao_how); > flexarray_t *front; > flexarray_t *back; > libxl__device device; > @@ -2399,8 +2402,9 @@ out_free: > flexarray_free(front); > flexarray_free(back); > out: > - GC_FREE; > - return rc; > + /* Dummy ao */ > + libxl__ao_complete(egc, ao, rc); > + return AO_INPROGRESS; > } > > int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h > index 6da6107..ce89b31 100644 > --- a/tools/libxl/libxl.h > +++ b/tools/libxl/libxl.h > @@ -563,14 +563,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32= _t domid, > libxl_device_nic *nic, libxl_nicinfo *nic= info); > > /* Keyboard */ > -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb); > +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk= b *vkb, > + const libxl_asyncop_how *ao_how); > 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_devi= ce_vkb *vkb); > > /* Framebuffer */ > -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb); > +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vf= b *vfb, > + const libxl_asyncop_how *ao_how); > int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, > libxl_device_vfb *vfb, > const libxl_asyncop_how *ao_how); > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index a1f5731..39e9257 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -628,7 +628,7 @@ static int do_domain_create(libxl__gc *gc, libxl_doma= in_config *d_config, > libxl__device_console_dispose(&console); > > libxl_device_vkb_init(&vkb); > - libxl_device_vkb_add(ctx, domid,&vkb); > + libxl_device_vkb_add(ctx, domid,&vkb, 0); > libxl_device_vkb_dispose(&vkb); > > ret =3D libxl__create_device_model(gc, domid, d_config, > @@ -646,8 +646,8 @@ static int do_domain_create(libxl__gc *gc, libxl_doma= in_config *d_config, > libxl__device_console console; > > for (i =3D 0; i< d_config->num_vfbs; i++) { > - libxl_device_vfb_add(ctx, domid,&d_config->vfbs[i]); > - libxl_device_vkb_add(ctx, domid,&d_config->vkbs[i]); > + libxl_device_vfb_add(ctx, domid,&d_config->vfbs[i], 0); > + libxl_device_vkb_add(ctx, domid,&d_config->vkbs[i], 0); > } > > ret =3D init_console_info(&console, 0); > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 8dc588d..4a2b5c1 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -804,10 +804,10 @@ retry_transaction: > if (ret) > goto out_free; > } > - ret =3D libxl_device_vfb_add(ctx, dm_domid,&dm_config.vfbs[0]); > + ret =3D libxl_device_vfb_add(ctx, dm_domid,&dm_config.vfbs[0], 0); > if (ret) > goto out_free; > - ret =3D libxl_device_vkb_add(ctx, dm_domid,&dm_config.vkbs[0]); > + ret =3D libxl_device_vkb_add(ctx, dm_domid,&dm_config.vkbs[0], 0); > if (ret) > goto out_free; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:21:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS350-0005sv-Dp; Wed, 09 May 2012 09:21:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS34z-0005sq-68 for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:21:05 +0000 Received: from [85.158.138.51:15912] by server-2.bemta-3.messagelabs.com id D0/F1-09269-0073AAF4; Wed, 09 May 2012 09:21:04 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-11.tower-174.messagelabs.com!1336555261!26040664!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18756 invoked from network); 9 May 2012 09:21:02 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 09:21:02 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS34u-0004OV-4B for xen-devel@lists.xensource.com; Wed, 09 May 2012 02:21:00 -0700 Date: Wed, 9 May 2012 02:21:00 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336555260123-5696877.post@n5.nabble.com> In-Reply-To: <1336485670.14542.92.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > >> > About pv-grub I think it fails with: >> > ... (from xl create...) >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> xc_dom_probe_bzimage_kernel: >> > kernel is not a bzImage: Invalid kernel >> > ... >> > And after seems start as hvm domU but is not working and I must destroy >> it. >> >> I think this is just a warning (which needs to be toned down), since the >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > # HG changeset patch > # User Ian Campbell <ian.campbell@> > # Date 1336485612 -3600 > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell <ian.campbell@> > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( dom->kernel_size < sizeof(struct setup_header) ) > { > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > - "%s: kernel image too small", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel image too small", > __FUNCTION__); > return -EINVAL; > } > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > { > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > - "%s: kernel is not a bzImage", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > __FUNCTION__); > return -EINVAL; > } > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > I rebuilt with this patch and on fully clean install on test server. With pygrub same result. With pv-grub: Vnc seems not to work (black screen), possible regression with qemu-xen as default for PV guest? Should I try to revert this (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next build to make sure there aren't any bugs left on qemu-xen? With xl console I get the pv-grub "recovery mode", possible regression about disks? ----------------------------------- xl -vvv create /etc/xenlucid.cfg Parsing config file lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14274 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7fcf39dc4000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7fcf39cc4000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7fcf39cbb000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 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 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7fcf39cba000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15364 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xcedda domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 2616 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 -------------------------- xl-lucid.log ----------- libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] from domid=4 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] got=domaininfos[0] got->domain=4 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done ----------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:21:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS350-0005sv-Dp; Wed, 09 May 2012 09:21:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS34z-0005sq-68 for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:21:05 +0000 Received: from [85.158.138.51:15912] by server-2.bemta-3.messagelabs.com id D0/F1-09269-0073AAF4; Wed, 09 May 2012 09:21:04 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-11.tower-174.messagelabs.com!1336555261!26040664!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18756 invoked from network); 9 May 2012 09:21:02 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 09:21:02 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS34u-0004OV-4B for xen-devel@lists.xensource.com; Wed, 09 May 2012 02:21:00 -0700 Date: Wed, 9 May 2012 02:21:00 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336555260123-5696877.post@n5.nabble.com> In-Reply-To: <1336485670.14542.92.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > >> > About pv-grub I think it fails with: >> > ... (from xl create...) >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> xc_dom_probe_bzimage_kernel: >> > kernel is not a bzImage: Invalid kernel >> > ... >> > And after seems start as hvm domU but is not working and I must destroy >> it. >> >> I think this is just a warning (which needs to be toned down), since the >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > # HG changeset patch > # User Ian Campbell <ian.campbell@> > # Date 1336485612 -3600 > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell <ian.campbell@> > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( dom->kernel_size < sizeof(struct setup_header) ) > { > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > - "%s: kernel image too small", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel image too small", > __FUNCTION__); > return -EINVAL; > } > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > { > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > - "%s: kernel is not a bzImage", __FUNCTION__); > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > __FUNCTION__); > return -EINVAL; > } > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel > I rebuilt with this patch and on fully clean install on test server. With pygrub same result. With pv-grub: Vnc seems not to work (black screen), possible regression with qemu-xen as default for PV guest? Should I try to revert this (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next build to make sure there aren't any bugs left on qemu-xen? With xl console I get the pv-grub "recovery mode", possible regression about disks? ----------------------------------- xl -vvv create /etc/xenlucid.cfg Parsing config file lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", features="(null)" domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" domainbuilder: detail: xc_dom_malloc_filemap : 978 kB domainbuilder: detail: xc_dom_malloc : 14274 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 xc: detail: elf_xen_parse: __xen_guest: "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0x0 xc: detail: elf_paddr_offset = 0x0 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0x0 xc: detail: virt_kend = 0x99ef00 xc: detail: virt_entry = 0x0 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> 0x99ef00 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> 0x99f000 (pfn 0x0 + 0x99f pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at 0x7fcf39dc4000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> 0xa9f000 (pfn 0x99f + 0x100 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at 0x7fcf39cc4000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn 0xa9f) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn 0xaa0) domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn 0xaa1) domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> 0xaab000 (pfn 0xaa2 + 0x9 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at 0x7fcf39cbb000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn 0xaab) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 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 0x20000 domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at 0x7fcf39cba000 domainbuilder: detail: start_info_x86_64: called domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 15364 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 978 kB domainbuilder: detail: domU mmap : 10916 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xcedda domainbuilder: detail: shared_info_x86_64: called domainbuilder: detail: vcpu_x86_64: called domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=tap libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: libxl: debug: libxl_dm.c:989:libxl__create_device_model: /usr/lib/xen/bin/qemu-system-i386 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev libxl: debug: libxl_dm.c:989:libxl__create_device_model: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon libxl: debug: libxl_dm.c:989:libxl__create_device_model: chardev=libxl-cmd,mode=control libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k libxl: debug: libxl_dm.c:989:libxl__create_device_model: it libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-4 libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"qmp_capabilities","id":1}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-chardev","id":2}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: '{"execute":"query-vnc","id":3}' libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return Daemon running with PID 2616 xc: debug: hypercall buffer: total allocations:154 total releases:154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 -------------------------- xl-lucid.log ----------- libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] from domid=4 nentries=1 rc=1 libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] got=domaininfos[0] got->domain=4 libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0020 libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search done ----------------------------------- -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:33:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3GV-00064s-Ur; Wed, 09 May 2012 09:32:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3GT-00064m-NS for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:32:58 +0000 Received: from [85.158.143.99:4816] by server-1.bemta-4.messagelabs.com id 90/FF-20925-8C93AAF4; Wed, 09 May 2012 09:32:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336555976!26811575!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15394 invoked from network); 9 May 2012 09:32:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 09:32:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12373107" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:32: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, 9 May 2012 10:32:44 +0100 Message-ID: <1336555963.25514.43.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu , Stefano Stabellini Date: Wed, 9 May 2012 10:32:43 +0100 In-Reply-To: <1336555260123-5696877.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> <1336555260123-5696877.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > >> > About pv-grub I think it fails with: > >> > ... (from xl create...) > >> > xc: error: panic: xc_dom_bzimageloader.c:588: > >> xc_dom_probe_bzimage_kernel: > >> > kernel is not a bzImage: Invalid kernel > >> > ... > >> > And after seems start as hvm domU but is not working and I must destroy > >> it. > >> > >> I think this is just a warning (which needs to be toned down), since the > >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > > > # HG changeset patch > > # User Ian Campbell <ian.campbell@> > > # Date 1336485612 -3600 > > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > > libxc: do not "panic" if a kernel is not a bzImage. > > > > Up untul the point where we think this is a bzImage there is no point in > > printing panicy messages -- some other loader will have a go (probably the > > compressed ELF one) > > > > Signed-off-by: Ian Campbell <ian.campbell@> > > > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( dom->kernel_size < sizeof(struct setup_header) ) > > { > > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > > - "%s: kernel image too small", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel image too small", > > __FUNCTION__); > > return -EINVAL; > > } > > > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > > { > > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > > - "%s: kernel is not a bzImage", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > > __FUNCTION__); > > return -EINVAL; > > } > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > > I rebuilt with this patch and on fully clean install on test server. > > With pygrub same result. Can you bisect this please. > With pv-grub: > Vnc seems not to work (black screen), possible regression with qemu-xen as > default for PV guest? Should I try to revert this > (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next > build to make sure there aren't any bugs left on qemu-xen? Yes please. Also setting "device_model_version" to qemu-xen-traditional should have the same overall effect as reverting. > With xl console I get the pv-grub "recovery mode", possible regression about > disks? > > ----------------------------------- > xl -vvv create /etc/xenlucid.cfg > Parsing config file lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", > features="(null)" > domainbuilder: detail: xc_dom_kernel_file: > filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" > domainbuilder: detail: xc_dom_malloc_filemap : 978 kB > domainbuilder: detail: xc_dom_malloc : 14274 kB > domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader > ... > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... > domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> > 0x99ef00 > domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k > each > domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB > domainbuilder: detail: xc_dom_build_image: called > domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> > 0x99f000 (pfn 0x0 + 0x99f pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at > 0x7fcf39dc4000 > xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 > domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> > 0xa9f000 (pfn 0x99f + 0x100 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at > 0x7fcf39cc4000 > domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn > 0xa9f) > domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn > 0xaa0) > domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn > 0xaa1) > domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: > 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: > 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: > 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: > 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) > domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> > 0xaab000 (pfn 0xaa2 + 0x9 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at > 0x7fcf39cbb000 > domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn > 0xaab) > domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 > domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 > 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 0x20000 > domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 > domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at > 0x7fcf39cba000 > domainbuilder: detail: start_info_x86_64: called > domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 > domainbuilder: detail: domain builder memory footprint > domainbuilder: detail: allocated > domainbuilder: detail: malloc : 15364 kB > domainbuilder: detail: anon mmap : 0 bytes > domainbuilder: detail: mapped > domainbuilder: detail: file mmap : 978 kB > domainbuilder: detail: domU mmap : 10916 kB > domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn > 0xcedda > domainbuilder: detail: shared_info_x86_64: called > domainbuilder: detail: vcpu_x86_64: called > domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf > domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 > domainbuilder: detail: xc_dom_release: called > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=tap > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > chardev=libxl-cmd,mode=control > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name > libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k > libxl: debug: libxl_dm.c:989:libxl__create_device_model: it > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M > libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 > libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to > /var/run/xen/qmp-libxl-4 > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"qmp_capabilities","id":1}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-chardev","id":2}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-vnc","id":3}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > Daemon running with PID 2616 > xc: debug: hypercall buffer: total allocations:154 total releases:154 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:2 > xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 > -------------------------- > xl-lucid.log > ----------- > libxl: debug: libxl_event.c:406:watchfd_callback: watch event: > epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 > libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] > from domid=4 nentries=1 rc=1 > libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] > got=domaininfos[0] got->domain=4 > libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists > shutdown_reported=0 dominf.flags=ffff0020 > libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all > reported > libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search > done > ----------------------------------- > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:33:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3GV-00064s-Ur; Wed, 09 May 2012 09:32:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3GT-00064m-NS for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:32:58 +0000 Received: from [85.158.143.99:4816] by server-1.bemta-4.messagelabs.com id 90/FF-20925-8C93AAF4; Wed, 09 May 2012 09:32:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336555976!26811575!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15394 invoked from network); 9 May 2012 09:32:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 09:32:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12373107" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:32: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, 9 May 2012 10:32:44 +0100 Message-ID: <1336555963.25514.43.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Fantu , Stefano Stabellini Date: Wed, 9 May 2012 10:32:43 +0100 In-Reply-To: <1336555260123-5696877.post@n5.nabble.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> <1336555260123-5696877.post@n5.nabble.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: > Ian Campbell-10 wrote > > > >> > About pv-grub I think it fails with: > >> > ... (from xl create...) > >> > xc: error: panic: xc_dom_bzimageloader.c:588: > >> xc_dom_probe_bzimage_kernel: > >> > kernel is not a bzImage: Invalid kernel > >> > ... > >> > And after seems start as hvm domU but is not working and I must destroy > >> it. > >> > >> I think this is just a warning (which needs to be toned down), since the > >> pvgrub kernel isn't a bzImage, it's a simple elf file. > > > > # HG changeset patch > > # User Ian Campbell <ian.campbell@> > > # Date 1336485612 -3600 > > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b > > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 > > libxc: do not "panic" if a kernel is not a bzImage. > > > > Up untul the point where we think this is a bzImage there is no point in > > printing panicy messages -- some other loader will have a go (probably the > > compressed ELF one) > > > > Signed-off-by: Ian Campbell <ian.campbell@> > > > > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c > > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 +0100 > > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 +0100 > > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( dom->kernel_size < sizeof(struct setup_header) ) > > { > > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > > - "%s: kernel image too small", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel image too small", > > __FUNCTION__); > > return -EINVAL; > > } > > > > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s > > > > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) > > { > > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, > > - "%s: kernel is not a bzImage", __FUNCTION__); > > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", > > __FUNCTION__); > > return -EINVAL; > > } > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@.xen > > http://lists.xen.org/xen-devel > > > I rebuilt with this patch and on fully clean install on test server. > > With pygrub same result. Can you bisect this please. > With pv-grub: > Vnc seems not to work (black screen), possible regression with qemu-xen as > default for PV guest? Should I try to revert this > (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on next > build to make sure there aren't any bugs left on qemu-xen? Yes please. Also setting "device_model_version" to qemu-xen-traditional should have the same overall effect as reverting. > With xl console I get the pv-grub "recovery mode", possible regression about > disks? > > ----------------------------------- > xl -vvv create /etc/xenlucid.cfg > Parsing config file lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > domainbuilder: detail: xc_dom_allocate: cmdline="(hd0,0)/grub/grub.cfg", > features="(null)" > domainbuilder: detail: xc_dom_kernel_file: > filename="/usr/lib/xen/boot/pv-grub-x86_64.gz" > domainbuilder: detail: xc_dom_malloc_filemap : 978 kB > domainbuilder: detail: xc_dom_malloc : 14274 kB > domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xf4abe -> 0xdf08ce > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 multiboot-binary loader > ... > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... > domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x0 memsz=0x99ef00 > xc: detail: elf_parse_binary: memory: 0x0 -> 0x99ef00 > xc: detail: elf_xen_parse: __xen_guest: > "GUEST_OS=Mini-OS,XEN_VER=xen-3.0,VIRT_BASE=0x0,ELF_PADDR_OFFSET=0x0,HYPERCALL_PAGE=0x2,LOADER=generic" > xc: detail: elf_xen_parse_guest_info: GUEST_OS="Mini-OS" > xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" > xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x0" > xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x0" > xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x2" > xc: detail: elf_xen_parse_guest_info: LOADER="generic" > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0x0 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0x0 > xc: detail: virt_kstart = 0x0 > xc: detail: virt_kend = 0x99ef00 > xc: detail: virt_entry = 0x0 > xc: detail: p2m_base = 0xffffffffffffffff > domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0x0 -> > 0x99ef00 > domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k > each > domainbuilder: detail: xc_dom_mem_init: 0x20000 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 : 1024 kB > domainbuilder: detail: xc_dom_build_image: called > domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x0 -> > 0x99f000 (pfn 0x0 + 0x99f pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x99f at > 0x7fcf39dc4000 > xc: detail: elf_load_binary: phdr 0 at 0x0x7fcf39dc4000 -> 0x0x7fcf3a762f00 > domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0x99f000 -> > 0xa9f000 (pfn 0x99f + 0x100 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x99f+0x100 at > 0x7fcf39cc4000 > domainbuilder: detail: xc_dom_alloc_page : start info : 0xa9f000 (pfn > 0xa9f) > domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xaa0000 (pfn > 0xaa0) > domainbuilder: detail: xc_dom_alloc_page : console : 0xaa1000 (pfn > 0xaa1) > domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: > 0x0000000000000000 -> 0x0000ffffffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: > 0x0000000000000000 -> 0x0000007fffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: > 0x0000000000000000 -> 0x000000003fffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: > 0x0000000000000000 -> 0x0000000000bfffff, 6 table(s) > domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xaa2000 -> > 0xaab000 (pfn 0xaa2 + 0x9 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xaa2+0x9 at > 0x7fcf39cbb000 > domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xaab000 (pfn > 0xaab) > domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xaac000 > domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc00000 > 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 0x20000 > domainbuilder: detail: clear_page: pfn 0xaa1, mfn 0x41b9d0 > domainbuilder: detail: clear_page: pfn 0xaa0, mfn 0x41b9d1 > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa9f+0x1 at > 0x7fcf39cba000 > domainbuilder: detail: start_info_x86_64: called > domainbuilder: detail: setup_hypercall_page: vaddr=0x2000 pfn=0x2 > domainbuilder: detail: domain builder memory footprint > domainbuilder: detail: allocated > domainbuilder: detail: malloc : 15364 kB > domainbuilder: detail: anon mmap : 0 bytes > domainbuilder: detail: mapped > domainbuilder: detail: file mmap : 978 kB > domainbuilder: detail: domU mmap : 10916 kB > domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn > 0xcedda > domainbuilder: detail: shared_info_x86_64: called > domainbuilder: detail: vcpu_x86_64: called > domainbuilder: detail: vcpu_x86_64: cr3: pfn 0xaa2 mfn 0x41b9cf > domainbuilder: detail: launch_vm: called, ctxt=0x7fffd27bcdf0 > domainbuilder: detail: xc_dom_release: called > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=tap > libxl: debug: libxl_dm.c:987:libxl__create_device_model: Spawning > device-model /usr/lib/xen/bin/qemu-system-i386 with arguments: > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > /usr/lib/xen/bin/qemu-system-i386 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-domid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 4 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -chardev > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-4,server,nowait > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -mon > libxl: debug: libxl_dm.c:989:libxl__create_device_model: > chardev=libxl-cmd,mode=control > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -xen-attach > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -name > libxl: debug: libxl_dm.c:989:libxl__create_device_model: lucid > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -vnc > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 0.0.0.0:0,to=99 > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -k > libxl: debug: libxl_dm.c:989:libxl__create_device_model: it > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -M > libxl: debug: libxl_dm.c:989:libxl__create_device_model: xenpv > libxl: debug: libxl_dm.c:989:libxl__create_device_model: -m > libxl: debug: libxl_dm.c:989:libxl__create_device_model: 513 > libxl: debug: libxl_qmp.c:692:libxl__qmp_initialize: connected to > /var/run/xen/qmp-libxl-4 > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: qmp > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"qmp_capabilities","id":1}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-chardev","id":2}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > libxl: debug: libxl_qmp.c:555:qmp_send_prepare: next qmp command: > '{"execute":"query-vnc","id":3}' > libxl: debug: libxl_qmp.c:298:qmp_handle_response: message type: return > Daemon running with PID 2616 > xc: debug: hypercall buffer: total allocations:154 total releases:154 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:2 > xc: debug: hypercall buffer: cache hits:149 misses:2 toobig:3 > -------------------------- > xl-lucid.log > ----------- > libxl: debug: libxl_event.c:406:watchfd_callback: watch event: > epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x7002a8 > libxl: debug: libxl.c:806:domain_death_xswatch_callback: [evg=0x6fbc90:4] > from domid=4 nentries=1 rc=1 > libxl: debug: libxl.c:817:domain_death_xswatch_callback: [evg=0x6fbc90:4] > got=domaininfos[0] got->domain=4 > libxl: debug: libxl.c:844:domain_death_xswatch_callback: exists > shutdown_reported=0 dominf.flags=ffff0020 > libxl: debug: libxl.c:810:domain_death_xswatch_callback: [evg=0] all > reported > libxl: debug: libxl.c:874:domain_death_xswatch_callback: domain death search > done > ----------------------------------- > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696877.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:37:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3KG-0006D2-LE; Wed, 09 May 2012 09:36:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3KF-0006Ct-SJ for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:36:52 +0000 Received: from [85.158.143.99:55947] by server-3.bemta-4.messagelabs.com id 59/89-05853-3BA3AAF4; Wed, 09 May 2012 09:36:51 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336556210!19616376!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27882 invoked from network); 9 May 2012 09:36:50 -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; 9 May 2012 09:36:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12373220" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:36:50 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:36:49 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS3KD-0006Wi-Gb; Wed, 09 May 2012 09:36:49 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS3KD-00027r-89; Wed, 09 May 2012 10:36:49 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 9 May 2012 10:36:49 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12823: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12823 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12823/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12800 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8a86d841e6d4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8a86d841e6d4 + branch=xen-unstable + revision=8a86d841e6d4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8a86d841e6d4 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:37:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3KG-0006D2-LE; Wed, 09 May 2012 09:36:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3KF-0006Ct-SJ for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:36:52 +0000 Received: from [85.158.143.99:55947] by server-3.bemta-4.messagelabs.com id 59/89-05853-3BA3AAF4; Wed, 09 May 2012 09:36:51 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336556210!19616376!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27882 invoked from network); 9 May 2012 09:36:50 -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; 9 May 2012 09:36:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12373220" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:36:50 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:36:49 +0100 Received: from [10.80.248.135] (helo=woking.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS3KD-0006Wi-Gb; Wed, 09 May 2012 09:36:49 +0000 Received: from osstest by woking.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS3KD-00027r-89; Wed, 09 May 2012 10:36:49 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 9 May 2012 10:36:49 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12823: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12823 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12823/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12800 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8f1e0cc4a507 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=8a86d841e6d4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 8a86d841e6d4 + branch=xen-unstable + revision=8a86d841e6d4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 8a86d841e6d4 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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:52:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3Yu-0006iv-4n; Wed, 09 May 2012 09:52:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3Yt-0006iq-5x for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:51:59 +0000 Received: from [193.109.254.147:2921] by server-9.bemta-14.messagelabs.com id 40/BB-05787-E3E3AAF4; Wed, 09 May 2012 09:51:58 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-10.tower-27.messagelabs.com!1336557116!3193655!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 732 invoked from network); 9 May 2012 09:51:57 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 09:51:57 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS3Yp-0007C9-JM for xen-devel@lists.xensource.com; Wed, 09 May 2012 02:51:55 -0700 Date: Wed, 9 May 2012 02:51:55 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336557115594-5696949.post@n5.nabble.com> In-Reply-To: <1336555963.25514.43.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> <1336555260123-5696877.post@n5.nabble.com> <1336555963.25514.43.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> >> > About pv-grub I think it fails with: >> >> > ... (from xl create...) >> >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> >> xc_dom_probe_bzimage_kernel: >> >> > kernel is not a bzImage: Invalid kernel >> >> > ... >> >> > And after seems start as hvm domU but is not working and I must >> destroy >> >> it. >> >> >> >> I think this is just a warning (which needs to be toned down), since >> the >> >> pvgrub kernel isn't a bzImage, it's a simple elf file. >> > >> > # HG changeset patch >> > # User Ian Campbell <ian.campbell@> >> > # Date 1336485612 -3600 >> > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b >> > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 >> > libxc: do not "panic" if a kernel is not a bzImage. >> > >> > Up untul the point where we think this is a bzImage there is no point >> in >> > printing panicy messages -- some other loader will have a go (probably >> the >> > compressed ELF one) >> > >> > Signed-off-by: Ian Campbell <ian.campbell@> >> > >> > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c >> > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 >> +0100 >> > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 >> +0100 >> > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( dom->kernel_size < sizeof(struct setup_header) ) >> > { >> > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, >> > - "%s: kernel image too small", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel image too small", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) >> > { >> > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, >> > - "%s: kernel is not a bzImage", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@.xen >> > http://lists.xen.org/xen-devel >> > >> I rebuilt with this patch and on fully clean install on test server. >> >> With pygrub same result. > > Can you bisect this please. > >> With pv-grub: >> Vnc seems not to work (black screen), possible regression with qemu-xen >> as >> default for PV guest? Should I try to revert this >> (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on >> next >> build to make sure there aren't any bugs left on qemu-xen? > > Yes please. > > Also setting "device_model_version" to qemu-xen-traditional should have > the same overall effect as reverting. > About bisect, I will do it. About qemu devices on pv I tried device_model_version="qemu-xen-traditional" but same problem on pygrub and pv-grub, it seems the problem is not about qemu-xen. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696949.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 09:52:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 09: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 ) id 1SS3Yu-0006iv-4n; Wed, 09 May 2012 09:52:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS3Yt-0006iq-5x for xen-devel@lists.xensource.com; Wed, 09 May 2012 09:51:59 +0000 Received: from [193.109.254.147:2921] by server-9.bemta-14.messagelabs.com id 40/BB-05787-E3E3AAF4; Wed, 09 May 2012 09:51:58 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-10.tower-27.messagelabs.com!1336557116!3193655!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 732 invoked from network); 9 May 2012 09:51:57 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 9 May 2012 09:51:57 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS3Yp-0007C9-JM for xen-devel@lists.xensource.com; Wed, 09 May 2012 02:51:55 -0700 Date: Wed, 9 May 2012 02:51:55 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336557115594-5696949.post@n5.nabble.com> In-Reply-To: <1336555963.25514.43.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.camel@zakaz.uk.xensource.com> <1336555260123-5696877.post@n5.nabble.com> <1336555963.25514.43.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell-10 wrote > > On Wed, 2012-05-09 at 10:21 +0100, Fantu wrote: >> Ian Campbell-10 wrote >> > >> >> > About pv-grub I think it fails with: >> >> > ... (from xl create...) >> >> > xc: error: panic: xc_dom_bzimageloader.c:588: >> >> xc_dom_probe_bzimage_kernel: >> >> > kernel is not a bzImage: Invalid kernel >> >> > ... >> >> > And after seems start as hvm domU but is not working and I must >> destroy >> >> it. >> >> >> >> I think this is just a warning (which needs to be toned down), since >> the >> >> pvgrub kernel isn't a bzImage, it's a simple elf file. >> > >> > # HG changeset patch >> > # User Ian Campbell <ian.campbell@> >> > # Date 1336485612 -3600 >> > # Node ID 8aba3396a61a2224b7cb36046ce06bad053e956b >> > # Parent 2fe12fc7bf1f863487920e06589641904b3d9466 >> > libxc: do not "panic" if a kernel is not a bzImage. >> > >> > Up untul the point where we think this is a bzImage there is no point >> in >> > printing panicy messages -- some other loader will have a go (probably >> the >> > compressed ELF one) >> > >> > Signed-off-by: Ian Campbell <ian.campbell@> >> > >> > diff -r 2fe12fc7bf1f -r 8aba3396a61a tools/libxc/xc_dom_bzimageloader.c >> > --- a/tools/libxc/xc_dom_bzimageloader.c Tue May 08 14:25:27 2012 >> +0100 >> > +++ b/tools/libxc/xc_dom_bzimageloader.c Tue May 08 15:00:12 2012 >> +0100 >> > @@ -575,8 +575,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( dom->kernel_size < sizeof(struct setup_header) ) >> > { >> > - xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, >> > - "%s: kernel image too small", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel image too small", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > @@ -584,8 +583,7 @@ static int xc_dom_probe_bzimage_kernel(s >> > >> > if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 ) >> > { >> > - xc_dom_panic(dom->xch, XC_INVALID_KERNEL, >> > - "%s: kernel is not a bzImage", __FUNCTION__); >> > + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", >> > __FUNCTION__); >> > return -EINVAL; >> > } >> > >> > >> > >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@.xen >> > http://lists.xen.org/xen-devel >> > >> I rebuilt with this patch and on fully clean install on test server. >> >> With pygrub same result. > > Can you bisect this please. > >> With pv-grub: >> Vnc seems not to work (black screen), possible regression with qemu-xen >> as >> default for PV guest? Should I try to revert this >> (http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a095e157f280) on >> next >> build to make sure there aren't any bugs left on qemu-xen? > > Yes please. > > Also setting "device_model_version" to qemu-xen-traditional should have > the same overall effect as reverting. > About bisect, I will do it. About qemu devices on pv I tried device_model_version="qemu-xen-traditional" but same problem on pygrub and pv-grub, it seems the problem is not about qemu-xen. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25259-tp5691153p5696949.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:22:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS42E-0007RU-SH; Wed, 09 May 2012 10:22:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS42D-0007RP-N4 for xen-devel@lists.xen.org; Wed, 09 May 2012 10:22:17 +0000 Received: from [85.158.143.35:8135] by server-1.bemta-4.messagelabs.com id 93/56-20925-8554AAF4; Wed, 09 May 2012 10:22:16 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336558934!3870526!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 9 May 2012 10:22:16 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194010064" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:22:14 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:22:13 -0400 Message-ID: <4FAA4554.3080005@citrix.com> Date: Wed, 9 May 2012 11:22:12 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Keir Fraser , Jan Beulich X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------000003060208070400050109" Subject: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------000003060208070400050109 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This affects every version of Xen at least as back as 3.4 -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------000003060208070400050109 Content-Type: text/x-patch; name="x86_64-ist-off-by-one-error.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86_64-ist-off-by-one-error.patch" # HG changeset patch # Parent 8f1e0cc4a507a52a49a2eb7832a57ecc7e032dce x86_64: Fix off-by-one error setting up the Interrupt Stack Tables The Interrupt Stack Table entries in a 64bit TSS are a 1 based data structure as far as hardware is concerned. As a result, the code setting up stacks in subarch_percpu_traps_init() fills in the wrong IST entries. The result is that the MCE handler executes on the stack set up for NMIs; the NMI handler executes on a stack set up for Double Faults, and Double Faults are executed with a stack pointer set to 0. Once the #DF handler starts to execute, it will usually take a page fault looking up the address at 0xfffffffffffffff8, which will cause a triple fault. If a guest has mapped a page in that location, then it will have some state overwritten, but as the #DF handler always calls panic(), this is not a problem the guest will have time to care about. Signed-off-by: Andrew Cooper diff -r 8f1e0cc4a507 xen/arch/x86/x86_64/traps.c --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -386,13 +386,13 @@ void __devinit subarch_percpu_traps_init BUILD_BUG_ON((IST_MAX + 2) * PAGE_SIZE + PRIMARY_STACK_SIZE > STACK_SIZE); /* Machine Check handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_MCE] = (unsigned long)&stack[IST_MCE * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_MCE-1] = (unsigned long)&stack[IST_MCE * PAGE_SIZE]; /* Double-fault handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_DF] = (unsigned long)&stack[IST_DF * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_DF-1] = (unsigned long)&stack[IST_DF * PAGE_SIZE]; /* NMI handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_NMI] = (unsigned long)&stack[IST_NMI * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_NMI-1] = (unsigned long)&stack[IST_NMI * PAGE_SIZE]; /* Trampoline for SYSCALL entry from long mode. */ stack = &stack[IST_MAX * PAGE_SIZE]; /* Skip the IST stacks. */ diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -424,7 +424,9 @@ struct tss_struct { union { u64 rsp1, esp1; }; union { u64 rsp2, esp2; }; u64 reserved1; - u64 ist[7]; + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] + * corresponds to an IST value of 1 in an Interrupt + * Descriptor */ u64 reserved2; u16 reserved3; #else --------------000003060208070400050109 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000003060208070400050109-- From xen-devel-bounces@lists.xen.org Wed May 09 10:22:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS42E-0007RU-SH; Wed, 09 May 2012 10:22:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS42D-0007RP-N4 for xen-devel@lists.xen.org; Wed, 09 May 2012 10:22:17 +0000 Received: from [85.158.143.35:8135] by server-1.bemta-4.messagelabs.com id 93/56-20925-8554AAF4; Wed, 09 May 2012 10:22:16 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336558934!3870526!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 9 May 2012 10:22:16 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194010064" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:22:14 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:22:13 -0400 Message-ID: <4FAA4554.3080005@citrix.com> Date: Wed, 9 May 2012 11:22:12 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Keir Fraser , Jan Beulich X-Enigmail-Version: 1.4.1 Content-Type: multipart/mixed; boundary="------------000003060208070400050109" Subject: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------000003060208070400050109 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This affects every version of Xen at least as back as 3.4 -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------000003060208070400050109 Content-Type: text/x-patch; name="x86_64-ist-off-by-one-error.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86_64-ist-off-by-one-error.patch" # HG changeset patch # Parent 8f1e0cc4a507a52a49a2eb7832a57ecc7e032dce x86_64: Fix off-by-one error setting up the Interrupt Stack Tables The Interrupt Stack Table entries in a 64bit TSS are a 1 based data structure as far as hardware is concerned. As a result, the code setting up stacks in subarch_percpu_traps_init() fills in the wrong IST entries. The result is that the MCE handler executes on the stack set up for NMIs; the NMI handler executes on a stack set up for Double Faults, and Double Faults are executed with a stack pointer set to 0. Once the #DF handler starts to execute, it will usually take a page fault looking up the address at 0xfffffffffffffff8, which will cause a triple fault. If a guest has mapped a page in that location, then it will have some state overwritten, but as the #DF handler always calls panic(), this is not a problem the guest will have time to care about. Signed-off-by: Andrew Cooper diff -r 8f1e0cc4a507 xen/arch/x86/x86_64/traps.c --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -386,13 +386,13 @@ void __devinit subarch_percpu_traps_init BUILD_BUG_ON((IST_MAX + 2) * PAGE_SIZE + PRIMARY_STACK_SIZE > STACK_SIZE); /* Machine Check handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_MCE] = (unsigned long)&stack[IST_MCE * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_MCE-1] = (unsigned long)&stack[IST_MCE * PAGE_SIZE]; /* Double-fault handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_DF] = (unsigned long)&stack[IST_DF * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_DF-1] = (unsigned long)&stack[IST_DF * PAGE_SIZE]; /* NMI handler has its own per-CPU 4kB stack. */ - this_cpu(init_tss).ist[IST_NMI] = (unsigned long)&stack[IST_NMI * PAGE_SIZE]; + this_cpu(init_tss).ist[IST_NMI-1] = (unsigned long)&stack[IST_NMI * PAGE_SIZE]; /* Trampoline for SYSCALL entry from long mode. */ stack = &stack[IST_MAX * PAGE_SIZE]; /* Skip the IST stacks. */ diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -424,7 +424,9 @@ struct tss_struct { union { u64 rsp1, esp1; }; union { u64 rsp2, esp2; }; u64 reserved1; - u64 ist[7]; + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] + * corresponds to an IST value of 1 in an Interrupt + * Descriptor */ u64 reserved2; u16 reserved3; #else --------------000003060208070400050109 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000003060208070400050109-- From xen-devel-bounces@lists.xen.org Wed May 09 10:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B6-0007bb-5b; Wed, 09 May 2012 10:31:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B4-0007av-8H for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:26 +0000 Received: from [193.109.254.147:41234] by server-12.bemta-14.messagelabs.com id E9/15-05898-D774AAF4; Wed, 09 May 2012 10:31:25 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336559483!1540634!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21586 invoked from network); 9 May 2012 10:31:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:31:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011027" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-F2; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5b5070d487d948ff654c70e9d08c5a130b07ac98 Message-ID: <5b5070d487d948ff654c.1336559322@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:42 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ...to prepare for a consistent "pci_assignable_*" naming scheme. Also move the man page entry into the PCI PASS-THROUGH section, rather than the XEN HOST section. No functional changes. Signed-off-by: George Dunlap diff -r 0772f1d07d1c -r 5b5070d487d9 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Tue May 08 17:18:31 2012 +0100 +++ b/docs/man/xl.pod.1 Wed May 09 11:21:19 2012 +0100 @@ -687,13 +687,6 @@ explanatory. Prints the current uptime of the domains running. -=item B - -List all the assignable PCI devices. -These are devices in the system which are configured to be -available for passthrough and are bound to a suitable PCI -backend driver in domain 0 rather than a real driver. - =back =head1 SCHEDULER SUBCOMMANDS @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do =over 4 +=item B + +List all the assignable PCI devices. +These are devices in the system which are configured to be +available for passthrough and are bound to a suitable PCI +backend driver in domain 0 rather than a real driver. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( * could be assigned to a domain (i.e. are bound to the backend * driver) but are not currently. */ -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc return 0; } -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) { GC_INIT(ctx); libxl_device_pci *pcidevs = NULL, *new, *assigned; @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl libxl_device_pci *pcidevs; int num, i; - pcidevs = libxl_device_pci_list_assignable(ctx, &num); + pcidevs = libxl_device_pci_assignable_list(ctx, &num); for (i = 0; i < num; i++) { if (pcidevs[i].domain == pcidev->domain && pcidevs[i].bus == pcidev->bus && diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl.h --- a/tools/libxl/xl.h Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl.h Wed May 09 11:21:19 2012 +0100 @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv int main_console(int argc, char **argv); int main_vncviewer(int argc, char **argv); int main_pcilist(int argc, char **argv); -int main_pcilist_assignable(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:19 2012 +0100 @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv return 0; } -static void pcilist_assignable(void) -{ - libxl_device_pci *pcidevs; - int num, i; - - pcidevs = libxl_device_pci_list_assignable(ctx, &num); - - if ( pcidevs == NULL ) - return; - for (i = 0; i < num; i++) { - printf("%04x:%02x:%02x.%01x\n", - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); - libxl_device_pci_dispose(&pcidevs[i]); - } - free(pcidevs); -} - -int main_pcilist_assignable(int argc, char **argv) -{ - int opt; - - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) - return opt; - - pcilist_assignable(); - return 0; -} - static void pcilist(const char *dom) { libxl_device_pci *pcidevs; @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv return 0; } +static void pciassignable_list(void) +{ + libxl_device_pci *pcidevs; + int num, i; + + pcidevs = libxl_device_pci_assignable_list(ctx, &num); + + if ( pcidevs == NULL ) + return; + for (i = 0; i < num; i++) { + printf("%04x:%02x:%02x.%01x\n", + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + libxl_device_pci_dispose(&pcidevs[i]); + } + free(pcidevs); +} + +int main_pciassignable_list(int argc, char **argv) +{ + int opt; + + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) + return opt; + + pciassignable_list(); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:21:19 2012 +0100 @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, - { "pci-list-assignable-devices", - &main_pcilist_assignable, 0, + { "pci-assignable-list", + &main_pciassignable_list, 0, "List all the assignable pci devices", "", }, diff -r 0772f1d07d1c -r 5b5070d487d9 tools/python/xen/lowlevel/xl/xl.c --- a/tools/python/xen/lowlevel/xl/xl.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/python/xen/lowlevel/xl/xl.c Wed May 09 11:21:19 2012 +0100 @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject return (PyObject *)pci; } -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) { libxl_device_pci *dev; PyObject *list; int nr_dev, i; - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { "Parse pass-through PCI device spec (BDF)"}, {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, "List PCI devices assigned to a domain"}, - {"device_pci_list_assignable", - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, + {"device_pci_assignable_list", + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, "List assignable PCI devices"}, { NULL, NULL, 0, NULL } }; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B6-0007bb-5b; Wed, 09 May 2012 10:31:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B4-0007av-8H for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:26 +0000 Received: from [193.109.254.147:41234] by server-12.bemta-14.messagelabs.com id E9/15-05898-D774AAF4; Wed, 09 May 2012 10:31:25 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336559483!1540634!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21586 invoked from network); 9 May 2012 10:31:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:31:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011027" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-F2; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5b5070d487d948ff654c70e9d08c5a130b07ac98 Message-ID: <5b5070d487d948ff654c.1336559322@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:42 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ...to prepare for a consistent "pci_assignable_*" naming scheme. Also move the man page entry into the PCI PASS-THROUGH section, rather than the XEN HOST section. No functional changes. Signed-off-by: George Dunlap diff -r 0772f1d07d1c -r 5b5070d487d9 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Tue May 08 17:18:31 2012 +0100 +++ b/docs/man/xl.pod.1 Wed May 09 11:21:19 2012 +0100 @@ -687,13 +687,6 @@ explanatory. Prints the current uptime of the domains running. -=item B - -List all the assignable PCI devices. -These are devices in the system which are configured to be -available for passthrough and are bound to a suitable PCI -backend driver in domain 0 rather than a real driver. - =back =head1 SCHEDULER SUBCOMMANDS @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do =over 4 +=item B + +List all the assignable PCI devices. +These are devices in the system which are configured to be +available for passthrough and are bound to a suitable PCI +backend driver in domain 0 rather than a real driver. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( * could be assigned to a domain (i.e. are bound to the backend * driver) but are not currently. */ -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc return 0; } -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) { GC_INIT(ctx); libxl_device_pci *pcidevs = NULL, *new, *assigned; @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl libxl_device_pci *pcidevs; int num, i; - pcidevs = libxl_device_pci_list_assignable(ctx, &num); + pcidevs = libxl_device_pci_assignable_list(ctx, &num); for (i = 0; i < num; i++) { if (pcidevs[i].domain == pcidev->domain && pcidevs[i].bus == pcidev->bus && diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl.h --- a/tools/libxl/xl.h Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl.h Wed May 09 11:21:19 2012 +0100 @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv int main_console(int argc, char **argv); int main_vncviewer(int argc, char **argv); int main_pcilist(int argc, char **argv); -int main_pcilist_assignable(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:19 2012 +0100 @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv return 0; } -static void pcilist_assignable(void) -{ - libxl_device_pci *pcidevs; - int num, i; - - pcidevs = libxl_device_pci_list_assignable(ctx, &num); - - if ( pcidevs == NULL ) - return; - for (i = 0; i < num; i++) { - printf("%04x:%02x:%02x.%01x\n", - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); - libxl_device_pci_dispose(&pcidevs[i]); - } - free(pcidevs); -} - -int main_pcilist_assignable(int argc, char **argv) -{ - int opt; - - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) - return opt; - - pcilist_assignable(); - return 0; -} - static void pcilist(const char *dom) { libxl_device_pci *pcidevs; @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv return 0; } +static void pciassignable_list(void) +{ + libxl_device_pci *pcidevs; + int num, i; + + pcidevs = libxl_device_pci_assignable_list(ctx, &num); + + if ( pcidevs == NULL ) + return; + for (i = 0; i < num; i++) { + printf("%04x:%02x:%02x.%01x\n", + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + libxl_device_pci_dispose(&pcidevs[i]); + } + free(pcidevs); +} + +int main_pciassignable_list(int argc, char **argv) +{ + int opt; + + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) + return opt; + + pciassignable_list(); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:21:19 2012 +0100 @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, - { "pci-list-assignable-devices", - &main_pcilist_assignable, 0, + { "pci-assignable-list", + &main_pciassignable_list, 0, "List all the assignable pci devices", "", }, diff -r 0772f1d07d1c -r 5b5070d487d9 tools/python/xen/lowlevel/xl/xl.c --- a/tools/python/xen/lowlevel/xl/xl.c Tue May 08 17:18:31 2012 +0100 +++ b/tools/python/xen/lowlevel/xl/xl.c Wed May 09 11:21:19 2012 +0100 @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject return (PyObject *)pci; } -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) { libxl_device_pci *dev; PyObject *list; int nr_dev, i; - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { "Parse pass-through PCI device spec (BDF)"}, {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, "List PCI devices assigned to a domain"}, - {"device_pci_list_assignable", - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, + {"device_pci_assignable_list", + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, "List assignable PCI devices"}, { NULL, NULL, 0, NULL } }; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bI-Bi; Wed, 09 May 2012 10:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007at-E5 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:25 +0000 Received: from [85.158.139.83:9046] by server-10.bemta-5.messagelabs.com id 0D/C4-08260-C774AAF4; Wed, 09 May 2012 10:31:24 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26189 invoked from network); 9 May 2012 10:31:23 -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; 9 May 2012 10:31:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011025" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-EY; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 0772f1d07d1c0b91fc376ae7a0d169488461efd5 Message-ID: <0772f1d07d1c0b91fc37.1336559321@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:41 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 4] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This functionality will be used several times in subsequent patches. Signed-off-by: George Dunlap diff -r d5268710a5ca -r 0772f1d07d1c tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 04 10:46:23 2012 +0100 +++ b/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi return 0; } +/* Write the standard BDF into the sysfs path given by sysfs_path. */ +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc, fd; + char *buf; + + fd = open(sysfs_path, O_WRONLY); + if (fd < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + sysfs_path); + return ERROR_FAIL; + } + + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = write(fd, buf, strlen(buf)); + /* Annoying to have two if's, but we need the errno */ + if (rc < 0) + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "write to %s returned %d", sysfs_path, rc); + close(fd); + + if (rc < 0) + return ERROR_FAIL; + + return 0; +} + libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) { GC_INIT(ctx); @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin /* Don't restrict writes to the PCI config space from this VM */ if (pcidev->permissive) { - int fd; - char *buf; - - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); - fd = open(sysfs_path, O_WRONLY); - if (fd < 0) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", - sysfs_path); + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Setting permissive for device"); return ERROR_FAIL; } - - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, - pcidev->dev, pcidev->func); - rc = write(fd, buf, strlen(buf)); - /* Annoying to have two if's, but we need the errno */ - if (rc < 0) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "write to %s returned %d", sysfs_path, rc); - close(fd); - if (rc < 0) - return ERROR_FAIL; } break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bI-Bi; Wed, 09 May 2012 10:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007at-E5 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:25 +0000 Received: from [85.158.139.83:9046] by server-10.bemta-5.messagelabs.com id 0D/C4-08260-C774AAF4; Wed, 09 May 2012 10:31:24 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26189 invoked from network); 9 May 2012 10:31:23 -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; 9 May 2012 10:31:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011025" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-EY; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 0772f1d07d1c0b91fc376ae7a0d169488461efd5 Message-ID: <0772f1d07d1c0b91fc37.1336559321@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:41 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 4] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This functionality will be used several times in subsequent patches. Signed-off-by: George Dunlap diff -r d5268710a5ca -r 0772f1d07d1c tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 04 10:46:23 2012 +0100 +++ b/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi return 0; } +/* Write the standard BDF into the sysfs path given by sysfs_path. */ +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc, fd; + char *buf; + + fd = open(sysfs_path, O_WRONLY); + if (fd < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + sysfs_path); + return ERROR_FAIL; + } + + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = write(fd, buf, strlen(buf)); + /* Annoying to have two if's, but we need the errno */ + if (rc < 0) + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "write to %s returned %d", sysfs_path, rc); + close(fd); + + if (rc < 0) + return ERROR_FAIL; + + return 0; +} + libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) { GC_INIT(ctx); @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin /* Don't restrict writes to the PCI config space from this VM */ if (pcidev->permissive) { - int fd; - char *buf; - - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); - fd = open(sysfs_path, O_WRONLY); - if (fd < 0) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", - sysfs_path); + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Setting permissive for device"); return ERROR_FAIL; } - - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, - pcidev->dev, pcidev->func); - rc = write(fd, buf, strlen(buf)); - /* Annoying to have two if's, but we need the errno */ - if (rc < 0) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "write to %s returned %d", sysfs_path, rc); - close(fd); - if (rc < 0) - return ERROR_FAIL; } break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007b0-Uk; Wed, 09 May 2012 10:31:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B2-0007ao-CF for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:24 +0000 Received: from [85.158.139.83:43068] by server-8.bemta-5.messagelabs.com id 19/80-26964-B774AAF4; Wed, 09 May 2012 10:31:23 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26133 invoked from network); 9 May 2012 10:31:22 -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; 9 May 2012 10:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011024" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-Dx; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:40 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The current method for passing through devices requires users to either modify cryptic Linux boot parameters and reboot, or do a lot of manual reads and writes into sysfs nodes. This set of patches introduces commands to make this easier. It expands on the concept of "assignable" (from the list_assignable_devices command). The new xl commands are: pci_assignable_add: Make a device assignable to guests. This involves unbinding the device from its old driver, creating a slot for it in pciback (if necessary), and binding it to pciback. pci_assignable_list: List devices assignable to guests. Just renamed from pci_list_assignable. pci_assignable_remove: Make the device no longer assignable to guests. This involves unbinding the device from pciback and removing the slot. It optionally involves rebinding the device to the driver from which we stole it. Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007b0-Uk; Wed, 09 May 2012 10:31:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B2-0007ao-CF for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:24 +0000 Received: from [85.158.139.83:43068] by server-8.bemta-5.messagelabs.com id 19/80-26964-B774AAF4; Wed, 09 May 2012 10:31:23 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26133 invoked from network); 9 May 2012 10:31:22 -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; 9 May 2012 10:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011024" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-Dx; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:40 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The current method for passing through devices requires users to either modify cryptic Linux boot parameters and reboot, or do a lot of manual reads and writes into sysfs nodes. This set of patches introduces commands to make this easier. It expands on the concept of "assignable" (from the list_assignable_devices command). The new xl commands are: pci_assignable_add: Make a device assignable to guests. This involves unbinding the device from its old driver, creating a slot for it in pciback (if necessary), and binding it to pciback. pci_assignable_list: List devices assignable to guests. Just renamed from pci_list_assignable. pci_assignable_remove: Make the device no longer assignable to guests. This involves unbinding the device from pciback and removing the slot. It optionally involves rebinding the device to the driver from which we stole it. Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bQ-Q0; Wed, 09 May 2012 10:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007au-VS for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:26 +0000 Received: from [85.158.139.83:9109] by server-12.bemta-5.messagelabs.com id 21/64-01344-D774AAF4; Wed, 09 May 2012 10:31:25 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26266 invoked from network); 9 May 2012 10:31:23 -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; 9 May 2012 10:31:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011026" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-G8; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: a1c3578537355b988d5e650afa3117674303fc3c Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:44 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pci-assignable-add will always store the driver rebind path, but pci-assignable-remove will only actually rebind if asked to do so. Signed-off-by: George Dunlap diff -r 17a5b562d1e7 -r a1c357853735 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Wed May 09 11:21:28 2012 +0100 +++ b/docs/man/xl.pod.1 Wed May 09 11:24:01 2012 +0100 @@ -1026,6 +1026,26 @@ These are devices in the system which ar available for passthrough and are bound to a suitable PCI backend driver in domain 0 rather than a real driver. +=item B I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will bind the device to the pciback driver. If it is already bound to a +driver, it will first be unbound, and the original driver stored so that it +can be re-bound to the same driver later if desired. + +CAUTION: This will make the device unusable by Domain 0 until it is +returned with pci-assignable-remove. Care should therefore be taken +not to do this on a device critical to domain 0's operation, such as +storage controllers, network interfaces, or GPUs that are currently +being used. + +=item B [I<-r>] I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will at least unbind the device from pciback. If the -r option is specified, +it will also attempt to re-bind the device to its original driver, making it +usable by Domain 0 again. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl.h --- a/tools/libxl/xl.h Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl.h Wed May 09 11:24:01 2012 +0100 @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv int main_pcilist(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_add(int argc, char **argv); +int main_pciassignable_remove(int argc, char **argv); int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:24:01 2012 +0100 @@ -2368,6 +2368,82 @@ int main_pciassignable_list(int argc, ch return 0; } +static void pciassignable_add(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + memset(&pcidev, 0x00, sizeof(pcidev)); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); + libxl_device_pci_dispose(&pcidev); +} + +int main_pciassignable_add(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + } + } + + bdf = argv[optind]; + + pciassignable_add(bdf, 1); + return 0; +} + +static void pciassignable_remove(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + memset(&pcidev, 0x00, sizeof(pcidev)); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); + libxl_device_pci_dispose(&pcidev); +} + +int main_pciassignable_remove(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + int rebind = 0; + + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + case 'r': + rebind=1; + break; + } + } + + bdf = argv[optind]; + + pciassignable_remove(bdf, rebind); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:24:01 2012 +0100 @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, + { "pci-assignable-add", + &main_pciassignable_add, 0, + "Make a device assignable for pci-passthru", + "", + "-h Print this help.\n" + }, + { "pci-assignable-remove", + &main_pciassignable_remove, 0, + "Remove a device from being assignable", + "[options] ", + "-h Print this help.\n" + "-r Attempt to re-assign the device to the\n" + " original driver" + }, { "pci-assignable-list", &main_pciassignable_list, 0, "List all the assignable pci devices", _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bQ-Q0; Wed, 09 May 2012 10:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B3-0007au-VS for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:31:26 +0000 Received: from [85.158.139.83:9109] by server-12.bemta-5.messagelabs.com id 21/64-01344-D774AAF4; Wed, 09 May 2012 10:31:25 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336559480!26762909!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26266 invoked from network); 9 May 2012 10:31:23 -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; 9 May 2012 10:31:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194011026" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-G8; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: a1c3578537355b988d5e650afa3117674303fc3c Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:44 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pci-assignable-add will always store the driver rebind path, but pci-assignable-remove will only actually rebind if asked to do so. Signed-off-by: George Dunlap diff -r 17a5b562d1e7 -r a1c357853735 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Wed May 09 11:21:28 2012 +0100 +++ b/docs/man/xl.pod.1 Wed May 09 11:24:01 2012 +0100 @@ -1026,6 +1026,26 @@ These are devices in the system which ar available for passthrough and are bound to a suitable PCI backend driver in domain 0 rather than a real driver. +=item B I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will bind the device to the pciback driver. If it is already bound to a +driver, it will first be unbound, and the original driver stored so that it +can be re-bound to the same driver later if desired. + +CAUTION: This will make the device unusable by Domain 0 until it is +returned with pci-assignable-remove. Care should therefore be taken +not to do this on a device critical to domain 0's operation, such as +storage controllers, network interfaces, or GPUs that are currently +being used. + +=item B [I<-r>] I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will at least unbind the device from pciback. If the -r option is specified, +it will also attempt to re-bind the device to its original driver, making it +usable by Domain 0 again. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl.h --- a/tools/libxl/xl.h Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl.h Wed May 09 11:24:01 2012 +0100 @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv int main_pcilist(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_add(int argc, char **argv); +int main_pciassignable_remove(int argc, char **argv); int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:24:01 2012 +0100 @@ -2368,6 +2368,82 @@ int main_pciassignable_list(int argc, ch return 0; } +static void pciassignable_add(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + memset(&pcidev, 0x00, sizeof(pcidev)); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); + libxl_device_pci_dispose(&pcidev); +} + +int main_pciassignable_add(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + } + } + + bdf = argv[optind]; + + pciassignable_add(bdf, 1); + return 0; +} + +static void pciassignable_remove(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + memset(&pcidev, 0x00, sizeof(pcidev)); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); + libxl_device_pci_dispose(&pcidev); +} + +int main_pciassignable_remove(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + int rebind = 0; + + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + case 'r': + rebind=1; + break; + } + } + + bdf = argv[optind]; + + pciassignable_remove(bdf, rebind); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Wed May 09 11:21:28 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:24:01 2012 +0100 @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, + { "pci-assignable-add", + &main_pciassignable_add, 0, + "Make a device assignable for pci-passthru", + "", + "-h Print this help.\n" + }, + { "pci-assignable-remove", + &main_pciassignable_remove, 0, + "Remove a device from being assignable", + "[options] ", + "-h Print this help.\n" + "-r Attempt to re-assign the device to the\n" + " original driver" + }, { "pci-assignable-list", &main_pciassignable_list, 0, "List all the assignable pci devices", _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B6-0007bv-Mt; Wed, 09 May 2012 10:31:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bH-NZ for xen-devel@lists.xen.org; Wed, 09 May 2012 10:31:27 +0000 Received: from [85.158.138.51:26443] by server-8.bemta-3.messagelabs.com id BC/7E-24428-E774AAF4; Wed, 09 May 2012 10:31:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336559480!26099388!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6496 invoked from network); 9 May 2012 10:31:20 -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; 9 May 2012 10:31:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12374595" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:31: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, 9 May 2012 11:31:14 +0100 Message-ID: <1336559473.25514.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andrew Cooper Date: Wed, 9 May 2012 11:31:13 +0100 In-Reply-To: <4FAA4554.3080005@citrix.com> References: <4FAA4554.3080005@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: > diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h > --- a/xen/include/asm-x86/processor.h > +++ b/xen/include/asm-x86/processor.h > @@ -424,7 +424,9 @@ struct tss_struct { > union { u64 rsp1, esp1; }; > union { u64 rsp2, esp2; }; > u64 reserved1; > - u64 ist[7]; > + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] > + * corresponds to an IST value of 1 in an Interrupt > + * Descriptor */ Would it be too sneaky to drop "reserved1" and make ist be 8 elements? then ist[1] would actually be the slot corresponding to a value of 1 in an IDT entry. > u64 reserved2; > u16 reserved3; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:31:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:31:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B6-0007bv-Mt; Wed, 09 May 2012 10:31:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4B5-0007bH-NZ for xen-devel@lists.xen.org; Wed, 09 May 2012 10:31:27 +0000 Received: from [85.158.138.51:26443] by server-8.bemta-3.messagelabs.com id BC/7E-24428-E774AAF4; Wed, 09 May 2012 10:31:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336559480!26099388!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6496 invoked from network); 9 May 2012 10:31:20 -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; 9 May 2012 10:31:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12374595" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:31: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, 9 May 2012 11:31:14 +0100 Message-ID: <1336559473.25514.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andrew Cooper Date: Wed, 9 May 2012 11:31:13 +0100 In-Reply-To: <4FAA4554.3080005@citrix.com> References: <4FAA4554.3080005@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: > diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h > --- a/xen/include/asm-x86/processor.h > +++ b/xen/include/asm-x86/processor.h > @@ -424,7 +424,9 @@ struct tss_struct { > union { u64 rsp1, esp1; }; > union { u64 rsp2, esp2; }; > u64 reserved1; > - u64 ist[7]; > + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] > + * corresponds to an IST value of 1 in an Interrupt > + * Descriptor */ Would it be too sneaky to drop "reserved1" and make ist be 8 elements? then ist[1] would actually be the slot corresponding to a value of 1 in an IDT entry. > u64 reserved2; > u16 reserved3; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:32:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4C6-0007sH-68; Wed, 09 May 2012 10:32:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4C4-0007rS-A5 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:32:29 +0000 Received: from [193.109.254.147:55958] by server-5.bemta-14.messagelabs.com id 09/93-30733-BB74AAF4; Wed, 09 May 2012 10:32:27 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336559545!3202150!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21620 invoked from network); 9 May 2012 10:32:26 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:32:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25012290" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-FY; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 17a5b562d1e79d094c58f5640af7809e0cfdd252 Message-ID: <17a5b562d1e79d094c58.1336559323@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:43 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl helper functions to prepare devices to be passed through to guests. This is meant to replace of all the manual sysfs commands which are currently required. pci_assignable_add accepts a BDF for a device and will: * Unbind a device from its current driver, if any * If "rebind" is set, it will store the path of the driver from which we unplugged it in /libxl/pciback/$BDF/driver_path * If necessary, create a slot for it in pciback * Bind the device to pciback At this point it will show up in pci_assignable_list, and is ready to be passed through to a guest. pci_assignable_remove accepts a BDF for a device and will: * Unbind the device from pciback * Remove the slot from pciback * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will attempt to rebind the device to its original driver. NB that "$BDF" in this case uses dashes instead of : and ., because : and . are illegal characters in xenstore paths. Signed-off-by: George Dunlap diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 +++ b/tools/libxl/libxl.h Wed May 09 11:21:28 2012 +0100 @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); /* - * Similar to libxl_device_pci_list but returns all devices which - * could be assigned to a domain (i.e. are bound to the backend - * driver) but are not currently. + * Functions related to making devices assignable -- that is, bound to + * the pciback driver, ready to be given to a guest via + * libxl_pci_device_add. + * + * - ..._add() will unbind the device from its current driver (if + * already bound) and re-bind it to pciback; at that point it will be + * ready to be assigned to a VM. If rebind is set, it will store the + * path to the old driver in xenstore so that it can be handed back to + * dom0 on restore. + * + * - ..._remove() will unbind the device from pciback, and if + * rebind is non-zero, attempt to assign it back to the driver + * from whence it came. + * + * - ..._list() will return a list of the PCI devices available to be + * assigned. */ +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:28 2012 +0100 @@ -21,6 +21,7 @@ #define PCI_BDF "%04x:%02x:%02x.%01x" #define PCI_BDF_SHORT "%02x:%02x.%01x" #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) { @@ -408,6 +409,347 @@ out: return pcidevs; } +/* Unbind device from its current driver, if any. If driver_path is non-NULL, + * store the path to the original driver in it. */ +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, char **driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath, *_dp, **dp; + struct stat st; + + if ( driver_path ) + dp = driver_path; + else + dp = &_dp; + + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( !lstat(spath, &st) ) { + /* Find the canonical path to the driver. */ + *dp = libxl__zalloc(gc, PATH_MAX); + *dp = realpath(spath, *dp); + if ( !*dp ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); + return -1; + } + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", + *dp); + + /* Unbind from the old driver */ + spath = libxl__sprintf(gc, "%s/unbind", *dp); + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); + return -1; + } + } + return 0; +} + +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + FILE *f; + int rc = 0; + unsigned bus, dev, func; + + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); + + if (f == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + SYSFS_PCIBACK_DRIVER"/slots"); + return ERROR_FAIL; + } + + while(fscanf(f, "0000:%x:%x.%x\n", &bus, &dev, &func)==3) { + if(bus == pcidev->bus + && dev == pcidev->dev + && func == pcidev->func) { + rc = 1; + goto out; + } + } +out: + fclose(f); + return rc; +} + +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath; + int rc; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, + pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = lstat(spath, &st); + + if( rc == 0 ) + return 1; + if ( rc < 0 && errno == ENOENT ) + return 0; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); + return -1; +} + +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Error checking for pciback slot"); + return ERROR_FAIL; + } else if (rc == 0) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + } + + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + return 0; +} + +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove from pciback */ + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); + return ERROR_FAIL; + } + + /* Remove slot if necessary */ + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't remove pciback slot"); + return ERROR_FAIL; + } + } + return 0; +} + +/* FIXME */ +#define PCIBACK_INFO_PATH "/libxl/pciback" + +static void pci_assignable_driver_path_write(libxl__gc *gc, + libxl_device_pci *pcidev, + char *driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *path; + xs_transaction_t t = 0; + struct xs_permissions perm[1]; + + perm[0].id = 0; + perm[0].perms = XS_PERM_NONE; + +retry: + t = xs_transaction_start(ctx->xsh); + + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + xs_rm(ctx->xsh, t, path); + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Write of %s to node %s failed", + driver_path, path); + } + + if (!xs_transaction_end(ctx->xsh, t, 0)) { + if (errno == EAGAIN) { + t = 0; + goto retry; + } + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "xenstore transaction commit failed; device " + " will not be rebound to original driver."); + } +} + +static char * pci_assignable_driver_path_read(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + return libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func)); +} + +static void pci_assignable_driver_path_remove(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * path; + xs_transaction_t t; + + /* Remove the xenstore entry */ +retry: + t = xs_transaction_start(ctx->xsh); + path = libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + xs_rm(ctx->xsh, t, path); + if (!xs_transaction_end(ctx->xsh, t, 0)) { + if (errno == EAGAIN) + goto retry; + else + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to remove xenstore entry"); + } +} + +static int libxl__device_pci_assignable_add(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned dom, bus, dev, func; + char *spath, *driver_path = NULL; + struct stat st; + + /* Local copy for convenience */ + dom = pcidev->domain; + bus = pcidev->bus; + dev = pcidev->dev; + func = pcidev->func; + + /* See if the device exists */ + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); + if ( lstat(spath, &st) ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); + return ERROR_FAIL; + } + + /* Check to see if it's already assigned to pciback */ + if ( pciback_dev_is_assigned(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", + dom, bus, dev, func); + return 0; + } + + /* Check to see if there's already a driver that we need to unbind from */ + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind "PCI_BDF" from driver", + dom, bus, dev, func); + return ERROR_FAIL; + } + + /* Store driver_path for rebinding to dom0 */ + if ( rebind ) { + if ( driver_path ) { + pci_assignable_driver_path_write(gc, pcidev, driver_path); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + PCI_BDF" not bound to a driver, will not be rebound.", + dom, bus, dev, func); + } + } + + if ( pciback_dev_assign(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + + return 0; +} + +static int libxl__device_pci_assignable_remove(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + char *driver_path; + + /* Unbind from pciback */ + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); + return ERROR_FAIL; + } else if ( rc ) { + pciback_dev_unassign(gc, pcidev); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Not bound to pciback"); + } + + /* Rebind if necessary */ + driver_path = pci_assignable_driver_path_read(gc, pcidev); + + if ( driver_path ) { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", + driver_path); + + if ( sysfs_write_bdf(gc, + libxl__sprintf(gc, "%s/bind", driver_path), + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to %s", driver_path); + return -1; + } + } + + pci_assignable_driver_path_remove(gc, pcidev); + } else { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Couldn't find path for original driver; not rebinding"); + } + } + + return 0; +} + +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + + +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + /* * This function checks that all functions of a device are bound to pciback * driver. It also initialises a bit-mask of which function numbers are present _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:32:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4C6-0007sH-68; Wed, 09 May 2012 10:32:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4C4-0007rS-A5 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:32:29 +0000 Received: from [193.109.254.147:55958] by server-5.bemta-14.messagelabs.com id 09/93-30733-BB74AAF4; Wed, 09 May 2012 10:32:27 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336559545!3202150!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21620 invoked from network); 9 May 2012 10:32:26 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:32:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25012290" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:31:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:31:19 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ax-0005Rz-FY; Wed, 09 May 2012 11:31:19 +0100 MIME-Version: 1.0 X-Mercurial-Node: 17a5b562d1e79d094c58f5640af7809e0cfdd252 Message-ID: <17a5b562d1e79d094c58.1336559323@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:28:43 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl helper functions to prepare devices to be passed through to guests. This is meant to replace of all the manual sysfs commands which are currently required. pci_assignable_add accepts a BDF for a device and will: * Unbind a device from its current driver, if any * If "rebind" is set, it will store the path of the driver from which we unplugged it in /libxl/pciback/$BDF/driver_path * If necessary, create a slot for it in pciback * Bind the device to pciback At this point it will show up in pci_assignable_list, and is ready to be passed through to a guest. pci_assignable_remove accepts a BDF for a device and will: * Unbind the device from pciback * Remove the slot from pciback * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will attempt to rebind the device to its original driver. NB that "$BDF" in this case uses dashes instead of : and ., because : and . are illegal characters in xenstore paths. Signed-off-by: George Dunlap diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 +++ b/tools/libxl/libxl.h Wed May 09 11:21:28 2012 +0100 @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); /* - * Similar to libxl_device_pci_list but returns all devices which - * could be assigned to a domain (i.e. are bound to the backend - * driver) but are not currently. + * Functions related to making devices assignable -- that is, bound to + * the pciback driver, ready to be given to a guest via + * libxl_pci_device_add. + * + * - ..._add() will unbind the device from its current driver (if + * already bound) and re-bind it to pciback; at that point it will be + * ready to be assigned to a VM. If rebind is set, it will store the + * path to the old driver in xenstore so that it can be handed back to + * dom0 on restore. + * + * - ..._remove() will unbind the device from pciback, and if + * rebind is non-zero, attempt to assign it back to the driver + * from whence it came. + * + * - ..._list() will return a list of the PCI devices available to be + * assigned. */ +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:28 2012 +0100 @@ -21,6 +21,7 @@ #define PCI_BDF "%04x:%02x:%02x.%01x" #define PCI_BDF_SHORT "%02x:%02x.%01x" #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) { @@ -408,6 +409,347 @@ out: return pcidevs; } +/* Unbind device from its current driver, if any. If driver_path is non-NULL, + * store the path to the original driver in it. */ +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, char **driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath, *_dp, **dp; + struct stat st; + + if ( driver_path ) + dp = driver_path; + else + dp = &_dp; + + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( !lstat(spath, &st) ) { + /* Find the canonical path to the driver. */ + *dp = libxl__zalloc(gc, PATH_MAX); + *dp = realpath(spath, *dp); + if ( !*dp ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); + return -1; + } + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", + *dp); + + /* Unbind from the old driver */ + spath = libxl__sprintf(gc, "%s/unbind", *dp); + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); + return -1; + } + } + return 0; +} + +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + FILE *f; + int rc = 0; + unsigned bus, dev, func; + + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); + + if (f == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + SYSFS_PCIBACK_DRIVER"/slots"); + return ERROR_FAIL; + } + + while(fscanf(f, "0000:%x:%x.%x\n", &bus, &dev, &func)==3) { + if(bus == pcidev->bus + && dev == pcidev->dev + && func == pcidev->func) { + rc = 1; + goto out; + } + } +out: + fclose(f); + return rc; +} + +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath; + int rc; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, + pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = lstat(spath, &st); + + if( rc == 0 ) + return 1; + if ( rc < 0 && errno == ENOENT ) + return 0; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); + return -1; +} + +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Error checking for pciback slot"); + return ERROR_FAIL; + } else if (rc == 0) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + } + + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + return 0; +} + +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove from pciback */ + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); + return ERROR_FAIL; + } + + /* Remove slot if necessary */ + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't remove pciback slot"); + return ERROR_FAIL; + } + } + return 0; +} + +/* FIXME */ +#define PCIBACK_INFO_PATH "/libxl/pciback" + +static void pci_assignable_driver_path_write(libxl__gc *gc, + libxl_device_pci *pcidev, + char *driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *path; + xs_transaction_t t = 0; + struct xs_permissions perm[1]; + + perm[0].id = 0; + perm[0].perms = XS_PERM_NONE; + +retry: + t = xs_transaction_start(ctx->xsh); + + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + xs_rm(ctx->xsh, t, path); + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Write of %s to node %s failed", + driver_path, path); + } + + if (!xs_transaction_end(ctx->xsh, t, 0)) { + if (errno == EAGAIN) { + t = 0; + goto retry; + } + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "xenstore transaction commit failed; device " + " will not be rebound to original driver."); + } +} + +static char * pci_assignable_driver_path_read(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + return libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func)); +} + +static void pci_assignable_driver_path_remove(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * path; + xs_transaction_t t; + + /* Remove the xenstore entry */ +retry: + t = xs_transaction_start(ctx->xsh); + path = libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + xs_rm(ctx->xsh, t, path); + if (!xs_transaction_end(ctx->xsh, t, 0)) { + if (errno == EAGAIN) + goto retry; + else + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Failed to remove xenstore entry"); + } +} + +static int libxl__device_pci_assignable_add(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned dom, bus, dev, func; + char *spath, *driver_path = NULL; + struct stat st; + + /* Local copy for convenience */ + dom = pcidev->domain; + bus = pcidev->bus; + dev = pcidev->dev; + func = pcidev->func; + + /* See if the device exists */ + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); + if ( lstat(spath, &st) ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); + return ERROR_FAIL; + } + + /* Check to see if it's already assigned to pciback */ + if ( pciback_dev_is_assigned(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", + dom, bus, dev, func); + return 0; + } + + /* Check to see if there's already a driver that we need to unbind from */ + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind "PCI_BDF" from driver", + dom, bus, dev, func); + return ERROR_FAIL; + } + + /* Store driver_path for rebinding to dom0 */ + if ( rebind ) { + if ( driver_path ) { + pci_assignable_driver_path_write(gc, pcidev, driver_path); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + PCI_BDF" not bound to a driver, will not be rebound.", + dom, bus, dev, func); + } + } + + if ( pciback_dev_assign(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + + return 0; +} + +static int libxl__device_pci_assignable_remove(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + char *driver_path; + + /* Unbind from pciback */ + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); + return ERROR_FAIL; + } else if ( rc ) { + pciback_dev_unassign(gc, pcidev); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Not bound to pciback"); + } + + /* Rebind if necessary */ + driver_path = pci_assignable_driver_path_read(gc, pcidev); + + if ( driver_path ) { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", + driver_path); + + if ( sysfs_write_bdf(gc, + libxl__sprintf(gc, "%s/bind", driver_path), + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to %s", driver_path); + return -1; + } + } + + pci_assignable_driver_path_remove(gc, pcidev); + } else { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Couldn't find path for original driver; not rebinding"); + } + } + + return 0; +} + +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + + +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + /* * This function checks that all functions of a device are bound to pciback * driver. It also initialises a bit-mask of which function numbers are present _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:49:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4SD-0008UE-Sp; Wed, 09 May 2012 10:49:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4SC-0008U9-Ix for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:49:08 +0000 Received: from [85.158.139.83:22430] by server-5.bemta-5.messagelabs.com id AD/6C-13566-3AB4AAF4; Wed, 09 May 2012 10:49:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336560545!23179121!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26295 invoked from network); 9 May 2012 10:49:06 -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 May 2012 10:49:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12375094" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:49: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, 9 May 2012 11:49:04 +0100 Message-ID: <1336560543.25514.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 11:49:03 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > The current method for passing through devices requires users to > either modify cryptic Linux boot parameters and reboot, or do a lot of > manual reads and writes into sysfs nodes. > > This set of patches introduces commands to make this easier. Is this intended for 4.2 or an RFC for 4.3? > It expands > on the concept of "assignable" (from the list_assignable_devices command). > > The new xl commands are: > > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. > > pci_assignable_remove: Make the device no longer assignable to guests. > This involves unbinding the device from pciback and removing the slot. It > optionally involves rebinding the device to the driver from which we stole > it. > > Signed-off-by: George Dunlap > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:49:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4SD-0008UE-Sp; Wed, 09 May 2012 10:49:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4SC-0008U9-Ix for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:49:08 +0000 Received: from [85.158.139.83:22430] by server-5.bemta-5.messagelabs.com id AD/6C-13566-3AB4AAF4; Wed, 09 May 2012 10:49:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336560545!23179121!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26295 invoked from network); 9 May 2012 10:49:06 -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 May 2012 10:49:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12375094" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:49: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, 9 May 2012 11:49:04 +0100 Message-ID: <1336560543.25514.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 11:49:03 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > The current method for passing through devices requires users to > either modify cryptic Linux boot parameters and reboot, or do a lot of > manual reads and writes into sysfs nodes. > > This set of patches introduces commands to make this easier. Is this intended for 4.2 or an RFC for 4.3? > It expands > on the concept of "assignable" (from the list_assignable_devices command). > > The new xl commands are: > > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. > > pci_assignable_remove: Make the device no longer assignable to guests. > This involves unbinding the device from pciback and removing the slot. It > optionally involves rebinding the device to the driver from which we stole > it. > > Signed-off-by: George Dunlap > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:53:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4WZ-0000AF-Ie; Wed, 09 May 2012 10:53:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4WX-0000A9-Dx for xen-devel@lists.xen.org; Wed, 09 May 2012 10:53:37 +0000 Received: from [193.109.254.147:35725] by server-10.bemta-14.messagelabs.com id 50/16-05847-0BC4AAF4; Wed, 09 May 2012 10:53:36 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336560814!8433247!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15362 invoked from network); 9 May 2012 10:53:36 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:53:36 -0000 Received: by yhoo21 with SMTP id o21so138446yho.32 for ; Wed, 09 May 2012 03:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p/cl3X83usCPGFbVAjePJzld99texXqC2azyyx+hZr4=; b=iBtAInWGoO6zYvv+NbHxLOBtzL6Ys4BBA4UIJaGatQgtm6jlnEljnW7NVYBdqJBWZx nTQBOY48xhKWPH8jt/+MdMUALfsKwd00o+xb5KsE1oKy7qzali7scT3v5sp8oN2h0ISw AQ8D2MXnD7iB+IaqQy9YQbwqG+Jh630lsSgXHeJR53BVudih3nYSXqYCr9UjhZPw2zBy R8OoduT+0d4908HKSnHI8vG758kYuSVByUKb32sdNlRb1nSE9IfEYpR5r2Y+psHPZZx7 DQCtwcDkIQSX7r+SfPDbu5sC/kSRogJeWQ0vZ+KX375uHq03p8aAJg8fQu+8dd8zqdxq dzxw== Received: by 10.236.76.41 with SMTP id a29mr28395569yhe.117.1336560814703; Wed, 09 May 2012 03:53:34 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id c11sm3583430ank.12.2012.05.09.03.53.31 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 03:53:33 -0700 (PDT) Message-ID: <4FAA4CA9.6080702@cantab.net> Date: Wed, 09 May 2012 11:53:29 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Ian Campbell References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> Cc: Andrew Cooper , "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. We did discuss this briefly internally and I thought it would be too sneaky. But perhaps it is ok if there is also #define IST_RESERVED 0 and a comment. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:53:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4WZ-0000AF-Ie; Wed, 09 May 2012 10:53:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4WX-0000A9-Dx for xen-devel@lists.xen.org; Wed, 09 May 2012 10:53:37 +0000 Received: from [193.109.254.147:35725] by server-10.bemta-14.messagelabs.com id 50/16-05847-0BC4AAF4; Wed, 09 May 2012 10:53:36 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336560814!8433247!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15362 invoked from network); 9 May 2012 10:53:36 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:53:36 -0000 Received: by yhoo21 with SMTP id o21so138446yho.32 for ; Wed, 09 May 2012 03:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p/cl3X83usCPGFbVAjePJzld99texXqC2azyyx+hZr4=; b=iBtAInWGoO6zYvv+NbHxLOBtzL6Ys4BBA4UIJaGatQgtm6jlnEljnW7NVYBdqJBWZx nTQBOY48xhKWPH8jt/+MdMUALfsKwd00o+xb5KsE1oKy7qzali7scT3v5sp8oN2h0ISw AQ8D2MXnD7iB+IaqQy9YQbwqG+Jh630lsSgXHeJR53BVudih3nYSXqYCr9UjhZPw2zBy R8OoduT+0d4908HKSnHI8vG758kYuSVByUKb32sdNlRb1nSE9IfEYpR5r2Y+psHPZZx7 DQCtwcDkIQSX7r+SfPDbu5sC/kSRogJeWQ0vZ+KX375uHq03p8aAJg8fQu+8dd8zqdxq dzxw== Received: by 10.236.76.41 with SMTP id a29mr28395569yhe.117.1336560814703; Wed, 09 May 2012 03:53:34 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id c11sm3583430ank.12.2012.05.09.03.53.31 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 03:53:33 -0700 (PDT) Message-ID: <4FAA4CA9.6080702@cantab.net> Date: Wed, 09 May 2012 11:53:29 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: Ian Campbell References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> Cc: Andrew Cooper , "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. We did discuss this briefly internally and I thought it would be too sneaky. But perhaps it is ok if there is also #define IST_RESERVED 0 and a comment. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wh-0000At-Uz; Wed, 09 May 2012 10:53:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wg-0000Ai-So for xen-devel@lists.xen.org; Wed, 09 May 2012 10:53:47 +0000 Received: from [85.158.143.99:9402] by server-3.bemta-4.messagelabs.com id 96/9F-05853-ABC4AAF4; Wed, 09 May 2012 10:53:46 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336560824!23789891!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29046 invoked from network); 9 May 2012 10:53:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:53:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25012706" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:43 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:43 -0400 Message-ID: <4FAA4CB6.2060107@citrix.com> Date: Wed, 9 May 2012 11:53:42 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.1 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. I considered that, but given no particular preference, I went with the visibly safer fix. I can change it if general opinion is that it would be clearer that way. ~Andrew > >> u64 reserved2; >> u16 reserved3; -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wh-0000At-Uz; Wed, 09 May 2012 10:53:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wg-0000Ai-So for xen-devel@lists.xen.org; Wed, 09 May 2012 10:53:47 +0000 Received: from [85.158.143.99:9402] by server-3.bemta-4.messagelabs.com id 96/9F-05853-ABC4AAF4; Wed, 09 May 2012 10:53:46 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336560824!23789891!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29046 invoked from network); 9 May 2012 10:53:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 10:53:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25012706" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:43 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:43 -0400 Message-ID: <4FAA4CB6.2060107@citrix.com> Date: Wed, 9 May 2012 11:53:42 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.1 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. I considered that, but given no particular preference, I went with the visibly safer fix. I can change it if general opinion is that it would be clearer that way. ~Andrew > >> u64 reserved2; >> u16 reserved3; -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wy-0000E8-HH; Wed, 09 May 2012 10:54:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Ww-0000DO-T1 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:03 +0000 Received: from [85.158.143.35:56112] by server-3.bemta-4.messagelabs.com id 12/10-05853-ACC4AAF4; Wed, 09 May 2012 10:54:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1532 invoked from network); 9 May 2012 10:54:01 -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; 9 May 2012 10:54:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013110" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Np; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: 794778a6e9fa761bd38820c6166aa4e2e8998143 Message-ID: <794778a6e9fa761bd388.1336560666@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:06 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 @@ -15,6 +15,7 @@ #include "libxl_osdeps.h" /* must come before any other headers */ #include +#include #include "libxl_internal.h" @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "WARNING: bootloader='/usr/bin/pygrub' " \ + "is deprecated; use bootloader='pygrub' instead"); + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, libxl__libexec_path()); if ( bootloader == NULL ) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wy-0000E8-HH; Wed, 09 May 2012 10:54:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Ww-0000DO-T1 for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:03 +0000 Received: from [85.158.143.35:56112] by server-3.bemta-4.messagelabs.com id 12/10-05853-ACC4AAF4; Wed, 09 May 2012 10:54:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1532 invoked from network); 9 May 2012 10:54:01 -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; 9 May 2012 10:54:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013110" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Np; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: 794778a6e9fa761bd38820c6166aa4e2e8998143 Message-ID: <794778a6e9fa761bd388.1336560666@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:06 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 @@ -15,6 +15,7 @@ #include "libxl_osdeps.h" /* must come before any other headers */ #include +#include #include "libxl_internal.h" @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "WARNING: bootloader='/usr/bin/pygrub' " \ + "is deprecated; use bootloader='pygrub' instead"); + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, libxl__libexec_path()); if ( bootloader == NULL ) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wz-0000Ec-A0; Wed, 09 May 2012 10:54:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wx-0000DO-TN for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:04 +0000 Received: from [85.158.143.35:51942] by server-3.bemta-4.messagelabs.com id CA/10-05853-BCC4AAF4; Wed, 09 May 2012 10:54:03 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1966 invoked from network); 9 May 2012 10:54:02 -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; 9 May 2012 10:54:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013112" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Mt; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: e43157a8693305e5627061c4a198bcbe70e06003 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:04 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the full path for a bootloader (such as pygrub or xenpvnetboot) is not given, look for it in the libexec path. Signed-off-by: George Dunlap diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; char *tempdir; + const char *bootloader = NULL; char *dom_console_xs_path; char dom_console_slave_tty_path[PATH_MAX]; @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, + libxl__libexec_path()); + if ( bootloader == NULL ) { + rc = ERROR_NOMEM; + goto out_close; + } + /* * We need to present the bootloader's tty as a pty slave that xenconsole * can access. Since the bootloader itself needs a pty slave, @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); if (pid < 0) { goto out_close; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:54:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wz-0000Ec-A0; Wed, 09 May 2012 10:54:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wx-0000DO-TN for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:04 +0000 Received: from [85.158.143.35:51942] by server-3.bemta-4.messagelabs.com id CA/10-05853-BCC4AAF4; Wed, 09 May 2012 10:54:03 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1966 invoked from network); 9 May 2012 10:54:02 -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; 9 May 2012 10:54:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013112" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Mt; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: e43157a8693305e5627061c4a198bcbe70e06003 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:04 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the full path for a bootloader (such as pygrub or xenpvnetboot) is not given, look for it in the libexec path. Signed-off-by: George Dunlap diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; char *tempdir; + const char *bootloader = NULL; char *dom_console_xs_path; char dom_console_slave_tty_path[PATH_MAX]; @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, goto out_close; } + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, + libxl__libexec_path()); + if ( bootloader == NULL ) { + rc = ERROR_NOMEM; + goto out_close; + } + /* * We need to present the bootloader's tty as a pty slave that xenconsole * can access. Since the bootloader itself needs a pty slave, @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); if (pid < 0) { goto out_close; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4Wy-0000EN-T4; Wed, 09 May 2012 10:54:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wx-0000DT-CH for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:03 +0000 Received: from [85.158.143.35:51882] by server-2.bemta-4.messagelabs.com id BE/7A-17550-ACC4AAF4; Wed, 09 May 2012 10:54:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1605 invoked from network); 9 May 2012 10:54:01 -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; 9 May 2012 10:54:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013111" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Lk; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:03 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 3 RESEND] tools: Move bootloaders to libexec directory X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pygrub and xenpvnetboot are meant to be run by tools, and not by the user, and thus should be in /usr/lib/xen/bin rather than /usr/bin. This patch series: * Causes libxl to look in the libexec dir if a full path is not specified * Moves pygrub and xenpvnetboot into the libexec dir * For compatibility with existing configs, puts a link to pygrub in /usr/bin * Warns the user that /usr/bin/pygrub is deprecated _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4Wy-0000EN-T4; Wed, 09 May 2012 10:54:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wx-0000DT-CH for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:03 +0000 Received: from [85.158.143.35:51882] by server-2.bemta-4.messagelabs.com id BE/7A-17550-ACC4AAF4; Wed, 09 May 2012 10:54:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1605 invoked from network); 9 May 2012 10:54:01 -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; 9 May 2012 10:54:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013111" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-Lk; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:03 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 3 RESEND] tools: Move bootloaders to libexec directory X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pygrub and xenpvnetboot are meant to be run by tools, and not by the user, and thus should be in /usr/lib/xen/bin rather than /usr/bin. This patch series: * Causes libxl to look in the libexec dir if a full path is not specified * Moves pygrub and xenpvnetboot into the libexec dir * For compatibility with existing configs, puts a link to pygrub in /usr/bin * Warns the user that /usr/bin/pygrub is deprecated _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4Wz-0000Ep-Li; Wed, 09 May 2012 10:54:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wy-0000DT-DU for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:04 +0000 Received: from [85.158.143.35:51971] by server-2.bemta-4.messagelabs.com id C8/8A-17550-CCC4AAF4; Wed, 09 May 2012 10:54:04 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2042 invoked from network); 9 May 2012 10:54:03 -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; 9 May 2012 10:54:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013113" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-NN; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: 52f45b258cccd8bb49230551336b760dc1ca7a5e Message-ID: <52f45b258cccd8bb4923.1336560665@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:05 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 3 RESEND] tools: Install pv bootloaders in libexec rather than /usr/bin X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pygrub and xenpvnetboot are meant to be run by tools, and not by the user, and thus should be in /usr/lib/xen/bin rather than /usr/bin. Because most config files will still have an absolute path pointing to /usr/bin/pygrub, make a symbolic link that we will deprecate. diff -r e43157a86933 -r 52f45b258ccc tools/misc/Makefile --- a/tools/misc/Makefile Wed May 09 11:38:50 2012 +0100 +++ b/tools/misc/Makefile Wed May 09 11:39:43 2012 +0100 @@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount SUBDIRS-$(CONFIG_MINITERM) += miniterm SUBDIRS := $(SUBDIRS-y) -INSTALL_BIN-y := xencons xenpvnetboot +INSTALL_BIN-y := xencons INSTALL_BIN-$(CONFIG_X86) += xen-detect INSTALL_BIN := $(INSTALL_BIN-y) @@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool INSTALL_SBIN := $(INSTALL_SBIN-y) +INSTALL_PRIVBIN-y := xenpvnetboot +INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y) + # Include configure output (config.h) to headers search path CFLAGS += -I$(XEN_ROOT)/tools @@ -41,8 +44,10 @@ build: $(TARGETS) install: build $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) + $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR) $(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR) $(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR) + $(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR) set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done .PHONY: clean diff -r e43157a86933 -r 52f45b258ccc tools/pygrub/Makefile --- a/tools/pygrub/Makefile Wed May 09 11:38:50 2012 +0100 +++ b/tools/pygrub/Makefile Wed May 09 11:39:43 2012 +0100 @@ -11,9 +11,11 @@ build: .PHONY: install install: all CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \ - $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force - $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub + $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \ + --install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force + $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub $(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot + ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR) .PHONY: clean clean: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:54:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10: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 ) id 1SS4Wz-0000Ep-Li; Wed, 09 May 2012 10:54:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Wy-0000DT-DU for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:54:04 +0000 Received: from [85.158.143.35:51971] by server-2.bemta-4.messagelabs.com id C8/8A-17550-CCC4AAF4; Wed, 09 May 2012 10:54:04 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336560839!10249438!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2042 invoked from network); 9 May 2012 10:54:03 -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; 9 May 2012 10:54:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194013113" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 06:53:59 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 06:53:59 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4Ws-0005nR-NN; Wed, 09 May 2012 11:53:58 +0100 MIME-Version: 1.0 X-Mercurial-Node: 52f45b258cccd8bb49230551336b760dc1ca7a5e Message-ID: <52f45b258cccd8bb4923.1336560665@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 9 May 2012 11:51:05 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 3 RESEND] tools: Install pv bootloaders in libexec rather than /usr/bin X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pygrub and xenpvnetboot are meant to be run by tools, and not by the user, and thus should be in /usr/lib/xen/bin rather than /usr/bin. Because most config files will still have an absolute path pointing to /usr/bin/pygrub, make a symbolic link that we will deprecate. diff -r e43157a86933 -r 52f45b258ccc tools/misc/Makefile --- a/tools/misc/Makefile Wed May 09 11:38:50 2012 +0100 +++ b/tools/misc/Makefile Wed May 09 11:39:43 2012 +0100 @@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount SUBDIRS-$(CONFIG_MINITERM) += miniterm SUBDIRS := $(SUBDIRS-y) -INSTALL_BIN-y := xencons xenpvnetboot +INSTALL_BIN-y := xencons INSTALL_BIN-$(CONFIG_X86) += xen-detect INSTALL_BIN := $(INSTALL_BIN-y) @@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool INSTALL_SBIN := $(INSTALL_SBIN-y) +INSTALL_PRIVBIN-y := xenpvnetboot +INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y) + # Include configure output (config.h) to headers search path CFLAGS += -I$(XEN_ROOT)/tools @@ -41,8 +44,10 @@ build: $(TARGETS) install: build $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) + $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR) $(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR) $(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR) + $(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR) set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done .PHONY: clean diff -r e43157a86933 -r 52f45b258ccc tools/pygrub/Makefile --- a/tools/pygrub/Makefile Wed May 09 11:38:50 2012 +0100 +++ b/tools/pygrub/Makefile Wed May 09 11:39:43 2012 +0100 @@ -11,9 +11,11 @@ build: .PHONY: install install: all CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \ - $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force - $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub + $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \ + --install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force + $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub $(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot + ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR) .PHONY: clean clean: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:55:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:55:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Xp-0000Wv-2u; Wed, 09 May 2012 10:54:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Xn-0000WR-Bq for xen-devel@lists.xen.org; Wed, 09 May 2012 10:54:55 +0000 Received: from [85.158.138.51:4310] by server-5.bemta-3.messagelabs.com id 99/6F-17113-EFC4AAF4; Wed, 09 May 2012 10:54:54 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336560893!26097378!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13887 invoked from network); 9 May 2012 10:54:53 -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; 9 May 2012 10:54:53 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 09 May 2012 11:54:52 +0100 Message-Id: <4FAA693102000078000827D0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 09 May 2012 11:55:13 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Ian Campbell" References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 09.05.12 at 12:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. While appealing at a first glance, I wouldn't recommend doing so: Documentation specifies it the way it's defined currently, and Linux also uses the same definition, so we'd only call for future bugs if we did it differently in our code. Jan >> u64 reserved2; >> u16 reserved3; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:55:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:55:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Xp-0000Wv-2u; Wed, 09 May 2012 10:54:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4Xn-0000WR-Bq for xen-devel@lists.xen.org; Wed, 09 May 2012 10:54:55 +0000 Received: from [85.158.138.51:4310] by server-5.bemta-3.messagelabs.com id 99/6F-17113-EFC4AAF4; Wed, 09 May 2012 10:54:54 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1336560893!26097378!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13887 invoked from network); 9 May 2012 10:54:53 -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; 9 May 2012 10:54:53 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 09 May 2012 11:54:52 +0100 Message-Id: <4FAA693102000078000827D0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 09 May 2012 11:55:13 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Ian Campbell" References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> In-Reply-To: <1336559473.25514.64.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 09.05.12 at 12:31, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h >> --- a/xen/include/asm-x86/processor.h >> +++ b/xen/include/asm-x86/processor.h >> @@ -424,7 +424,9 @@ struct tss_struct { >> union { u64 rsp1, esp1; }; >> union { u64 rsp2, esp2; }; >> u64 reserved1; >> - u64 ist[7]; >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] >> + * corresponds to an IST value of 1 in an Interrupt >> + * Descriptor */ > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > then ist[1] would actually be the slot corresponding to a value of 1 in > an IDT entry. While appealing at a first glance, I wouldn't recommend doing so: Documentation specifies it the way it's defined currently, and Linux also uses the same definition, so we'd only call for future bugs if we did it differently in our code. Jan >> u64 reserved2; >> u16 reserved3; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:56:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:56:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ZB-0000oV-HO; Wed, 09 May 2012 10:56:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ZA-0000oE-Af for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:56:20 +0000 Received: from [85.158.139.83:4437] by server-11.bemta-5.messagelabs.com id 0A/3C-12959-35D4AAF4; Wed, 09 May 2012 10:56:19 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336560977!27442016!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3847 invoked from network); 9 May 2012 10:56:18 -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; 9 May 2012 10:56:18 -0000 Received: by yhkk6 with SMTP id k6so160656yhk.30 for ; Wed, 09 May 2012 03:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Pb19050vkzYOmd72M4rBbi9GmDxv5/PDTkxzuVVSFQ=; b=UvynL0Vw4jPtBeHHW/rNJIuxsCEHBLe4ye55HgpBgCZBoPhuNMmVrmoql76KCkj+TO sB1+lcKYmGnyFR5EhutPqDmk0Nc6wT21wAamy+hA8/4OgTNxPQr1BJwzwVtCoCfVXzYP lfJbBgj6O6u8hd3dzUAp1knPxSahSsBStRbP2xNtc1SAaj8N6TpkZgLUxvDUAYw4S5ZL GU1YJpVKb3V7YY3sWgsC22HbiZnHIz/ElfSmd1jT8o8MtamUhDykwVUXybfTfrHC+k46 vWZxO/YNdi86HqJBV+wtxYKZiQg9lwSCAzLSeeL4CJx8kfp6KmvHcz9wT3WbhyOUPVnD oa9A== Received: by 10.236.78.5 with SMTP id f5mr22652816yhe.14.1336560977327; Wed, 09 May 2012 03:56:17 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id n14sm3592980anl.11.2012.05.09.03.56.16 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 03:56:16 -0700 (PDT) Message-ID: <4FAA4D4F.9070804@cantab.net> Date: Wed, 09 May 2012 11:56:15 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:28, George Dunlap wrote: > The current method for passing through devices requires users to > either modify cryptic Linux boot parameters and reboot, or do a lot of > manual reads and writes into sysfs nodes. > > This set of patches introduces commands to make this easier. It expands > on the concept of "assignable" (from the list_assignable_devices command). > > The new xl commands are: > > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. You use underscores here (and elsewhere in the commit message) but the code uses dashes. Suggest updating the commit messages with the format for the commands. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 10:56:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 10:56:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ZB-0000oV-HO; Wed, 09 May 2012 10:56:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4ZA-0000oE-Af for xen-devel@lists.xensource.com; Wed, 09 May 2012 10:56:20 +0000 Received: from [85.158.139.83:4437] by server-11.bemta-5.messagelabs.com id 0A/3C-12959-35D4AAF4; Wed, 09 May 2012 10:56:19 +0000 X-Env-Sender: d.vrabel.98@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336560977!27442016!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3847 invoked from network); 9 May 2012 10:56:18 -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; 9 May 2012 10:56:18 -0000 Received: by yhkk6 with SMTP id k6so160656yhk.30 for ; Wed, 09 May 2012 03:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Pb19050vkzYOmd72M4rBbi9GmDxv5/PDTkxzuVVSFQ=; b=UvynL0Vw4jPtBeHHW/rNJIuxsCEHBLe4ye55HgpBgCZBoPhuNMmVrmoql76KCkj+TO sB1+lcKYmGnyFR5EhutPqDmk0Nc6wT21wAamy+hA8/4OgTNxPQr1BJwzwVtCoCfVXzYP lfJbBgj6O6u8hd3dzUAp1knPxSahSsBStRbP2xNtc1SAaj8N6TpkZgLUxvDUAYw4S5ZL GU1YJpVKb3V7YY3sWgsC22HbiZnHIz/ElfSmd1jT8o8MtamUhDykwVUXybfTfrHC+k46 vWZxO/YNdi86HqJBV+wtxYKZiQg9lwSCAzLSeeL4CJx8kfp6KmvHcz9wT3WbhyOUPVnD oa9A== Received: by 10.236.78.5 with SMTP id f5mr22652816yhe.14.1336560977327; Wed, 09 May 2012 03:56:17 -0700 (PDT) Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id n14sm3592980anl.11.2012.05.09.03.56.16 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 03:56:16 -0700 (PDT) Message-ID: <4FAA4D4F.9070804@cantab.net> Date: Wed, 09 May 2012 11:56:15 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:28, George Dunlap wrote: > The current method for passing through devices requires users to > either modify cryptic Linux boot parameters and reboot, or do a lot of > manual reads and writes into sysfs nodes. > > This set of patches introduces commands to make this easier. It expands > on the concept of "assignable" (from the list_assignable_devices command). > > The new xl commands are: > > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. You use underscores here (and elsewhere in the commit message) but the code uses dashes. Suggest updating the commit messages with the format for the commands. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:00:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:00:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4cn-0001J4-7z; Wed, 09 May 2012 11:00:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4cl-0001Iw-HO for xen-devel@lists.xen.org; Wed, 09 May 2012 11:00:03 +0000 Received: from [85.158.139.83:2027] by server-2.bemta-5.messagelabs.com id B3/DB-17016-23E4AAF4; Wed, 09 May 2012 11:00:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336561202!23181500!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23569 invoked from network); 9 May 2012 11:00:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:00:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12375365" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 11:00:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 12:00:01 +0100 Message-ID: <1336561200.25514.81.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Wed, 9 May 2012 12:00:00 +0100 In-Reply-To: <4FAA693102000078000827D0@nat28.tlf.novell.com> References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> <4FAA693102000078000827D0@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andrew Cooper , "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:55 +0100, Jan Beulich wrote: > >>> On 09.05.12 at 12:31, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: > >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h > >> --- a/xen/include/asm-x86/processor.h > >> +++ b/xen/include/asm-x86/processor.h > >> @@ -424,7 +424,9 @@ struct tss_struct { > >> union { u64 rsp1, esp1; }; > >> union { u64 rsp2, esp2; }; > >> u64 reserved1; > >> - u64 ist[7]; > >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] > >> + * corresponds to an IST value of 1 in an Interrupt > >> + * Descriptor */ > > > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > > then ist[1] would actually be the slot corresponding to a value of 1 in > > an IDT entry. > > While appealing at a first glance, I wouldn't recommend doing so: > Documentation specifies it the way it's defined currently, and Linux > also uses the same definition, so we'd only call for future bugs if > we did it differently in our code. I thought someone would say something like that ;-) OK then. > > Jan > > >> u64 reserved2; > >> u16 reserved3; > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:00:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:00:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4cn-0001J4-7z; Wed, 09 May 2012 11:00:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4cl-0001Iw-HO for xen-devel@lists.xen.org; Wed, 09 May 2012 11:00:03 +0000 Received: from [85.158.139.83:2027] by server-2.bemta-5.messagelabs.com id B3/DB-17016-23E4AAF4; Wed, 09 May 2012 11:00:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1336561202!23181500!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23569 invoked from network); 9 May 2012 11:00:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:00:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12375365" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 11:00:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 12:00:01 +0100 Message-ID: <1336561200.25514.81.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Wed, 9 May 2012 12:00:00 +0100 In-Reply-To: <4FAA693102000078000827D0@nat28.tlf.novell.com> References: <4FAA4554.3080005@citrix.com> <1336559473.25514.64.camel@zakaz.uk.xensource.com> <4FAA693102000078000827D0@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andrew Cooper , "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] x86_64: Fix off-by-one error setting up the Interrupt Stack Tables X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:55 +0100, Jan Beulich wrote: > >>> On 09.05.12 at 12:31, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:22 +0100, Andrew Cooper wrote: > >> diff -r 8f1e0cc4a507 xen/include/asm-x86/processor.h > >> --- a/xen/include/asm-x86/processor.h > >> +++ b/xen/include/asm-x86/processor.h > >> @@ -424,7 +424,9 @@ struct tss_struct { > >> union { u64 rsp1, esp1; }; > >> union { u64 rsp2, esp2; }; > >> u64 reserved1; > >> - u64 ist[7]; > >> + u64 ist[7]; /* Interrupt Stack Table is 1-based so tss->ist[0] > >> + * corresponds to an IST value of 1 in an Interrupt > >> + * Descriptor */ > > > > Would it be too sneaky to drop "reserved1" and make ist be 8 elements? > > then ist[1] would actually be the slot corresponding to a value of 1 in > > an IDT entry. > > While appealing at a first glance, I wouldn't recommend doing so: > Documentation specifies it the way it's defined currently, and Linux > also uses the same definition, so we'd only call for future bugs if > we did it differently in our code. I thought someone would say something like that ;-) OK then. > > Jan > > >> u64 reserved2; > >> u16 reserved3; > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:04:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11: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 ) id 1SS4ge-0001TT-17; Wed, 09 May 2012 11:04:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4gc-0001TO-Ng for xen-devel@lists.xen.org; Wed, 09 May 2012 11:04:02 +0000 Received: from [85.158.143.35:46579] by server-3.bemta-4.messagelabs.com id 82/02-05853-22F4AAF4; Wed, 09 May 2012 11:04:02 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336561441!8099927!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22911 invoked from network); 9 May 2012 11:04:01 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:04:01 -0000 Received: by eekc4 with SMTP id c4so65315eek.32 for ; Wed, 09 May 2012 04:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=OH0HKOOakLtmuLYOZYckQpJI89xJJmRJSSt3gH9LnHw=; b=fSQz23k1O/3WO5g8q/1PqXNd+JwHhRKY/VuB+jFBe0Qzm2NTFC5rmKOimjA8wIcjYz 9OXyFKcYpFPD4k6i7YVjmzwAvJCncqAz0lCvZ0XkSOC2XWLxvyl6TWkF7mYXY4oiDFv4 vjw/toeS7p6dFUh0jA9PUTTm5Y/bcHCM0arCRZfqQKqhlp5RBvMZQRS0z5Tib+qoAmET 1boAST6hrMwuOIeRoLgyn78PnirUu+T5K00Tt/CpbXRHWs0xfaHum2XKbrLW9jxBNMt+ 66b/h+7hnA/QEVVJusFib/1I2zcNk0PhpEkM/zRmfAC7zvoXu7Se0fKn94MDZPiCgeRD bDqA== Received: by 10.14.101.132 with SMTP id b4mr3959643eeg.33.1336561441129; Wed, 09 May 2012 04:04:01 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id f16sm11089887eec.2.2012.05.09.04.03.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 04:03:59 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 420c8861a2d2a61a7e806b4519a6e90ca58d7ff9 Message-Id: <420c8861a2d2a61a7e80.1336561430@Solace> User-Agent: Mercurial-patchbomb/2.2 Date: Wed, 09 May 2012 13:03:50 +0200 From: Darrio Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor supports to be valid topology entries might lead to misleading and incorrect behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: ... cpu_topology : cpu: core socket node 0: 0 1 0 1: 0 1 0 2: 1 1 0 3: 1 1 0 4: 9 1 0 5: 9 1 0 6: 10 1 0 7: 10 1 0 8: 0 0 1 9: 0 0 1 10: 1 0 1 11: 1 0 1 12: 9 0 1 13: 9 0 1 14: 10 0 1 15: 10 0 1 16: 0 0 0 17: 0 0 0 18: 0 0 0 19: 0 0 0 20: 0 0 0 ... ... 62: 0 0 0 63: 0 0 0 However, xc_topologyinfo() tells us (in max_cpu_index) how many entries arrays it returns corresponds to actually valid CPUs, so let's use that information. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog } for (i = 0; i < max_cpus; i++) { -#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \ +#define V(map, i) (i > tinfo.max_cpu_index || \ + map[i] == INVALID_TOPOLOGY_ID) ? \ LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i] ret[i].core = V(coremap, i); ret[i].socket = V(socketmap, i); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:04:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11: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 ) id 1SS4ge-0001TT-17; Wed, 09 May 2012 11:04:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4gc-0001TO-Ng for xen-devel@lists.xen.org; Wed, 09 May 2012 11:04:02 +0000 Received: from [85.158.143.35:46579] by server-3.bemta-4.messagelabs.com id 82/02-05853-22F4AAF4; Wed, 09 May 2012 11:04:02 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336561441!8099927!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22911 invoked from network); 9 May 2012 11:04:01 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:04:01 -0000 Received: by eekc4 with SMTP id c4so65315eek.32 for ; Wed, 09 May 2012 04:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=OH0HKOOakLtmuLYOZYckQpJI89xJJmRJSSt3gH9LnHw=; b=fSQz23k1O/3WO5g8q/1PqXNd+JwHhRKY/VuB+jFBe0Qzm2NTFC5rmKOimjA8wIcjYz 9OXyFKcYpFPD4k6i7YVjmzwAvJCncqAz0lCvZ0XkSOC2XWLxvyl6TWkF7mYXY4oiDFv4 vjw/toeS7p6dFUh0jA9PUTTm5Y/bcHCM0arCRZfqQKqhlp5RBvMZQRS0z5Tib+qoAmET 1boAST6hrMwuOIeRoLgyn78PnirUu+T5K00Tt/CpbXRHWs0xfaHum2XKbrLW9jxBNMt+ 66b/h+7hnA/QEVVJusFib/1I2zcNk0PhpEkM/zRmfAC7zvoXu7Se0fKn94MDZPiCgeRD bDqA== Received: by 10.14.101.132 with SMTP id b4mr3959643eeg.33.1336561441129; Wed, 09 May 2012 04:04:01 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id f16sm11089887eec.2.2012.05.09.04.03.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 04:03:59 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 420c8861a2d2a61a7e806b4519a6e90ca58d7ff9 Message-Id: <420c8861a2d2a61a7e80.1336561430@Solace> User-Agent: Mercurial-patchbomb/2.2 Date: Wed, 09 May 2012 13:03:50 +0200 From: Darrio Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor supports to be valid topology entries might lead to misleading and incorrect behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: ... cpu_topology : cpu: core socket node 0: 0 1 0 1: 0 1 0 2: 1 1 0 3: 1 1 0 4: 9 1 0 5: 9 1 0 6: 10 1 0 7: 10 1 0 8: 0 0 1 9: 0 0 1 10: 1 0 1 11: 1 0 1 12: 9 0 1 13: 9 0 1 14: 10 0 1 15: 10 0 1 16: 0 0 0 17: 0 0 0 18: 0 0 0 19: 0 0 0 20: 0 0 0 ... ... 62: 0 0 0 63: 0 0 0 However, xc_topologyinfo() tells us (in max_cpu_index) how many entries arrays it returns corresponds to actually valid CPUs, so let's use that information. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog } for (i = 0; i < max_cpus; i++) { -#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \ +#define V(map, i) (i > tinfo.max_cpu_index || \ + map[i] == INVALID_TOPOLOGY_ID) ? \ LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i] ret[i].core = V(coremap, i); ret[i].socket = V(socketmap, i); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:04:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:04:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4hM-0001YI-N7; Wed, 09 May 2012 11:04:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4hK-0001Y0-UU for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:04:47 +0000 Received: from [85.158.138.51:42045] by server-4.bemta-3.messagelabs.com id B3/33-15341-E4F4AAF4; Wed, 09 May 2012 11:04:46 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336561482!26067503!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30536 invoked from network); 9 May 2012 11:04:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:04:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194014341" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 07:04:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:04:41 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4hF-0005yQ-C0; Wed, 09 May 2012 12:04:41 +0100 Message-ID: <4FAA4F03.600@eu.citrix.com> Date: Wed, 9 May 2012 12:03:31 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> In-Reply-To: <1336560543.25514.74.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:49, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: >> The current method for passing through devices requires users to >> either modify cryptic Linux boot parameters and reboot, or do a lot of >> manual reads and writes into sysfs nodes. >> >> This set of patches introduces commands to make this easier. > Is this intended for 4.2 or an RFC for 4.3? Well, I would really like it to go in to 4.2 -- it's been on my to-do list for a month at least, and it will make doing pci pass-through, and thus driver domains, a lot more straightforward. -George > >> It expands >> on the concept of "assignable" (from the list_assignable_devices command). >> >> The new xl commands are: >> >> pci_assignable_add: Make a device assignable to guests. This involves >> unbinding the device from its old driver, creating a slot for it in >> pciback (if necessary), and binding it to pciback. >> >> pci_assignable_list: List devices assignable to guests. Just renamed >> from pci_list_assignable. >> >> pci_assignable_remove: Make the device no longer assignable to guests. >> This involves unbinding the device from pciback and removing the slot. It >> optionally involves rebinding the device to the driver from which we stole >> it. >> >> Signed-off-by: George Dunlap >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:04:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:04:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4hM-0001YI-N7; Wed, 09 May 2012 11:04:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4hK-0001Y0-UU for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:04:47 +0000 Received: from [85.158.138.51:42045] by server-4.bemta-3.messagelabs.com id B3/33-15341-E4F4AAF4; Wed, 09 May 2012 11:04:46 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336561482!26067503!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30536 invoked from network); 9 May 2012 11:04:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:04:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194014341" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 07:04:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:04:41 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4hF-0005yQ-C0; Wed, 09 May 2012 12:04:41 +0100 Message-ID: <4FAA4F03.600@eu.citrix.com> Date: Wed, 9 May 2012 12:03:31 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> In-Reply-To: <1336560543.25514.74.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:49, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: >> The current method for passing through devices requires users to >> either modify cryptic Linux boot parameters and reboot, or do a lot of >> manual reads and writes into sysfs nodes. >> >> This set of patches introduces commands to make this easier. > Is this intended for 4.2 or an RFC for 4.3? Well, I would really like it to go in to 4.2 -- it's been on my to-do list for a month at least, and it will make doing pci pass-through, and thus driver domains, a lot more straightforward. -George > >> It expands >> on the concept of "assignable" (from the list_assignable_devices command). >> >> The new xl commands are: >> >> pci_assignable_add: Make a device assignable to guests. This involves >> unbinding the device from its old driver, creating a slot for it in >> pciback (if necessary), and binding it to pciback. >> >> pci_assignable_list: List devices assignable to guests. Just renamed >> from pci_list_assignable. >> >> pci_assignable_remove: Make the device no longer assignable to guests. >> This involves unbinding the device from pciback and removing the slot. It >> optionally involves rebinding the device to the driver from which we stole >> it. >> >> Signed-off-by: George Dunlap >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:12:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:12:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4oB-0001qS-Oq; Wed, 09 May 2012 11:11:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4oA-0001qN-Rx for xen-devel@lists.xen.org; Wed, 09 May 2012 11:11:51 +0000 Received: from [85.158.143.99:20570] by server-1.bemta-4.messagelabs.com id 1F/97-20925-6F05AAF4; Wed, 09 May 2012 11:11:50 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-216.messagelabs.com!1336561909!23793251!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14595 invoked from network); 9 May 2012 11:11:49 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-216.messagelabs.com with SMTP; 9 May 2012 11:11:49 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77729385; Wed, 09 May 2012 13:11:48 +0200 Message-ID: <1336561898.2621.4.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Wed, 09 May 2012 13:11:38 +0200 In-Reply-To: <420c8861a2d2a61a7e80.1336561430@Solace> References: <420c8861a2d2a61a7e80.1336561430@Solace> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6894980105098005633==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6894980105098005633== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-f2O9odqswB6uANpHDu+T" --=-f2O9odqswB6uANpHDu+T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 13:03 +0200, Darrio Faggioli wrote:=20 > Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor > supports to be valid topology entries might lead to misleading and incorr= ect > behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: > ... > >=20 > However, xc_topologyinfo() tells us (in max_cpu_index) how many entries > arrays it returns corresponds to actually valid CPUs, so let's use that > information. >=20 > Signed-off-by: Dario Faggioli >=20 And, as it is an actual bugfix and very very small in size, not to forget that I'd need that for the NUMA placement series, I'm proposing this for 4.2... Does it make sense? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-f2O9odqswB6uANpHDu+T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+qUOoACgkQk4XaBE3IOsQN4ACfdpTC75rh8EY19S5jD95LadQU oBEAnRfsCl2YfqilaTpVT3gPIOIN43sb =yHgc -----END PGP SIGNATURE----- --=-f2O9odqswB6uANpHDu+T-- --===============6894980105098005633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6894980105098005633==-- From xen-devel-bounces@lists.xen.org Wed May 09 11:12:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:12:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4oB-0001qS-Oq; Wed, 09 May 2012 11:11:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4oA-0001qN-Rx for xen-devel@lists.xen.org; Wed, 09 May 2012 11:11:51 +0000 Received: from [85.158.143.99:20570] by server-1.bemta-4.messagelabs.com id 1F/97-20925-6F05AAF4; Wed, 09 May 2012 11:11:50 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-216.messagelabs.com!1336561909!23793251!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14595 invoked from network); 9 May 2012 11:11:49 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-216.messagelabs.com with SMTP; 9 May 2012 11:11:49 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77729385; Wed, 09 May 2012 13:11:48 +0200 Message-ID: <1336561898.2621.4.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Wed, 09 May 2012 13:11:38 +0200 In-Reply-To: <420c8861a2d2a61a7e80.1336561430@Solace> References: <420c8861a2d2a61a7e80.1336561430@Solace> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6894980105098005633==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6894980105098005633== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-f2O9odqswB6uANpHDu+T" --=-f2O9odqswB6uANpHDu+T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 13:03 +0200, Darrio Faggioli wrote:=20 > Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor > supports to be valid topology entries might lead to misleading and incorr= ect > behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: > ... > >=20 > However, xc_topologyinfo() tells us (in max_cpu_index) how many entries > arrays it returns corresponds to actually valid CPUs, so let's use that > information. >=20 > Signed-off-by: Dario Faggioli >=20 And, as it is an actual bugfix and very very small in size, not to forget that I'd need that for the NUMA placement series, I'm proposing this for 4.2... Does it make sense? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-f2O9odqswB6uANpHDu+T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+qUOoACgkQk4XaBE3IOsQN4ACfdpTC75rh8EY19S5jD95LadQU oBEAnRfsCl2YfqilaTpVT3gPIOIN43sb =yHgc -----END PGP SIGNATURE----- --=-f2O9odqswB6uANpHDu+T-- --===============6894980105098005633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6894980105098005633==-- From xen-devel-bounces@lists.xen.org Wed May 09 11:13:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4pc-0001uf-8a; Wed, 09 May 2012 11:13:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4pa-0001ua-N7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:13:18 +0000 Received: from [85.158.139.83:12220] by server-5.bemta-5.messagelabs.com id 7C/F4-13566-D415AAF4; Wed, 09 May 2012 11:13:17 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336561994!27446135!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1119 invoked from network); 9 May 2012 11:13:16 -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 May 2012 11:13:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25013126" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 07:13:06 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:13:06 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4pO-00065X-5e; Wed, 09 May 2012 12:13:06 +0100 Message-ID: <4FAA50FC.60105@eu.citrix.com> Date: Wed, 9 May 2012 12:11:56 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Vrabel References: <4FAA4D4F.9070804@cantab.net> In-Reply-To: <4FAA4D4F.9070804@cantab.net> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:56, David Vrabel wrote: > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. > You use underscores here (and elsewhere in the commit message) but the > code uses dashes. Suggest updating the commit messages with the format > for the commands. I used underscores in the patch to libxl, because the libxl functions have undescores, and dashes in the xl patch, because the xl commands use dashes. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 11:13:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 11:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4pc-0001uf-8a; Wed, 09 May 2012 11:13:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS4pa-0001ua-N7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:13:18 +0000 Received: from [85.158.139.83:12220] by server-5.bemta-5.messagelabs.com id 7C/F4-13566-D415AAF4; Wed, 09 May 2012 11:13:17 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336561994!27446135!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1119 invoked from network); 9 May 2012 11:13:16 -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 May 2012 11:13:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25013126" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 07:13:06 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 07:13:06 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS4pO-00065X-5e; Wed, 09 May 2012 12:13:06 +0100 Message-ID: <4FAA50FC.60105@eu.citrix.com> Date: Wed, 9 May 2012 12:11:56 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Vrabel References: <4FAA4D4F.9070804@cantab.net> In-Reply-To: <4FAA4D4F.9070804@cantab.net> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 11:56, David Vrabel wrote: > pci_assignable_add: Make a device assignable to guests. This involves > unbinding the device from its old driver, creating a slot for it in > pciback (if necessary), and binding it to pciback. > > pci_assignable_list: List devices assignable to guests. Just renamed > from pci_list_assignable. > You use underscores here (and elsewhere in the commit message) but the > code uses dashes. Suggest updating the commit messages with the format > for the commands. I used underscores in the patch to libxl, because the libxl functions have undescores, and dashes in the xl patch, because the xl commands use dashes. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:00:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:00:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5YR-00038U-Tw; Wed, 09 May 2012 11:59:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5YQ-00038P-Fh for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:59:38 +0000 Received: from [85.158.143.35:47131] by server-2.bemta-4.messagelabs.com id A6/07-17550-92C5AAF4; Wed, 09 May 2012 11:59:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336564776!14715495!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32537 invoked from network); 9 May 2012 11:59:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:59:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12376596" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 11:59: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, 9 May 2012 12:59:35 +0100 Message-ID: <1336564773.25514.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 12:59:33 +0100 In-Reply-To: <4FAA4F03.600@eu.citrix.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 12:03 +0100, George Dunlap wrote: > On 09/05/12 11:49, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > >> The current method for passing through devices requires users to > >> either modify cryptic Linux boot parameters and reboot, or do a lot of > >> manual reads and writes into sysfs nodes. > >> > >> This set of patches introduces commands to make this easier. > > Is this intended for 4.2 or an RFC for 4.3? > Well, I would really like it to go in to 4.2 -- it's been on my to-do > list for a month at least, and it will make doing pci pass-through, and > thus driver domains, a lot more straightforward. Right, however it is strictly speaking a new feature which is not mentioned on the TODO list and has not previously been posted (AFAIK, please correct me if not) and we are currently supposed to be in feature freeze (and have been for several weeks, if not a month). IIRC this functionality was mooted when the pci permissive patch was being done as something which would be a 4.3 feature. We need to decide if we want to make an exception for this new feature or not. Although I'm sure this feature is very nice and handy, we've lived without it for years and people seem to be able to use the existing scheme. Ian. > > -George > > > > > >> It expands > >> on the concept of "assignable" (from the list_assignable_devices command). > >> > >> The new xl commands are: > >> > >> pci_assignable_add: Make a device assignable to guests. This involves > >> unbinding the device from its old driver, creating a slot for it in > >> pciback (if necessary), and binding it to pciback. > >> > >> pci_assignable_list: List devices assignable to guests. Just renamed > >> from pci_list_assignable. > >> > >> pci_assignable_remove: Make the device no longer assignable to guests. > >> This involves unbinding the device from pciback and removing the slot. It > >> optionally involves rebinding the device to the driver from which we stole > >> it. > >> > >> Signed-off-by: George Dunlap > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:00:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:00:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5YR-00038U-Tw; Wed, 09 May 2012 11:59:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5YQ-00038P-Fh for xen-devel@lists.xensource.com; Wed, 09 May 2012 11:59:38 +0000 Received: from [85.158.143.35:47131] by server-2.bemta-4.messagelabs.com id A6/07-17550-92C5AAF4; Wed, 09 May 2012 11:59:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336564776!14715495!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32537 invoked from network); 9 May 2012 11:59:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 11:59:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12376596" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 11:59: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, 9 May 2012 12:59:35 +0100 Message-ID: <1336564773.25514.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 12:59:33 +0100 In-Reply-To: <4FAA4F03.600@eu.citrix.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 12:03 +0100, George Dunlap wrote: > On 09/05/12 11:49, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > >> The current method for passing through devices requires users to > >> either modify cryptic Linux boot parameters and reboot, or do a lot of > >> manual reads and writes into sysfs nodes. > >> > >> This set of patches introduces commands to make this easier. > > Is this intended for 4.2 or an RFC for 4.3? > Well, I would really like it to go in to 4.2 -- it's been on my to-do > list for a month at least, and it will make doing pci pass-through, and > thus driver domains, a lot more straightforward. Right, however it is strictly speaking a new feature which is not mentioned on the TODO list and has not previously been posted (AFAIK, please correct me if not) and we are currently supposed to be in feature freeze (and have been for several weeks, if not a month). IIRC this functionality was mooted when the pci permissive patch was being done as something which would be a 4.3 feature. We need to decide if we want to make an exception for this new feature or not. Although I'm sure this feature is very nice and handy, we've lived without it for years and people seem to be able to use the existing scheme. Ian. > > -George > > > > > >> It expands > >> on the concept of "assignable" (from the list_assignable_devices command). > >> > >> The new xl commands are: > >> > >> pci_assignable_add: Make a device assignable to guests. This involves > >> unbinding the device from its old driver, creating a slot for it in > >> pciback (if necessary), and binding it to pciback. > >> > >> pci_assignable_list: List devices assignable to guests. Just renamed > >> from pci_list_assignable. > >> > >> pci_assignable_remove: Make the device no longer assignable to guests. > >> This involves unbinding the device from pciback and removing the slot. It > >> optionally involves rebinding the device to the driver from which we stole > >> it. > >> > >> Signed-off-by: George Dunlap > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:05:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5dW-0003VR-AY; Wed, 09 May 2012 12:04:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5dV-0003VF-O6 for xen-devel@lists.xen.org; Wed, 09 May 2012 12:04:53 +0000 Received: from [193.109.254.147:5264] by server-1.bemta-14.messagelabs.com id 78/4A-29372-46D5AAF4; Wed, 09 May 2012 12:04:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336565076!1546913!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14061 invoked from network); 9 May 2012 12:04: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; 9 May 2012 12:04:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12376715" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:04: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, 9 May 2012 13:04:35 +0100 Message-ID: <1336565074.25514.104.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Darrio Faggioli Date: Wed, 9 May 2012 13:04:34 +0100 In-Reply-To: <420c8861a2d2a61a7e80.1336561430@Solace> References: <420c8861a2d2a61a7e80.1336561430@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 12:03 +0100, Darrio Faggioli wrote: > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog > } > > for (i = 0; i < max_cpus; i++) { > -#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \ > +#define V(map, i) (i > tinfo.max_cpu_index || \ > + map[i] == INVALID_TOPOLOGY_ID) ? \ This ensures that cpus entries above max_cpu_index are INVALID_TOPOLOGY_ID but do you also want to size the return array using tinfo.max_cpu_index too? And also return that in *nr instead of? (I don't know the answer, either of max-possible- and max-online-cpus is a reasonable size for this array) > LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i] > ret[i].core = V(coremap, i); > ret[i].socket = V(socketmap, i); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:05:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5dW-0003VR-AY; Wed, 09 May 2012 12:04:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS5dV-0003VF-O6 for xen-devel@lists.xen.org; Wed, 09 May 2012 12:04:53 +0000 Received: from [193.109.254.147:5264] by server-1.bemta-14.messagelabs.com id 78/4A-29372-46D5AAF4; Wed, 09 May 2012 12:04:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336565076!1546913!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14061 invoked from network); 9 May 2012 12:04: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; 9 May 2012 12:04:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12376715" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:04: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, 9 May 2012 13:04:35 +0100 Message-ID: <1336565074.25514.104.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Darrio Faggioli Date: Wed, 9 May 2012 13:04:34 +0100 In-Reply-To: <420c8861a2d2a61a7e80.1336561430@Solace> References: <420c8861a2d2a61a7e80.1336561430@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 12:03 +0100, Darrio Faggioli wrote: > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog > } > > for (i = 0; i < max_cpus; i++) { > -#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \ > +#define V(map, i) (i > tinfo.max_cpu_index || \ > + map[i] == INVALID_TOPOLOGY_ID) ? \ This ensures that cpus entries above max_cpu_index are INVALID_TOPOLOGY_ID but do you also want to size the return array using tinfo.max_cpu_index too? And also return that in *nr instead of? (I don't know the answer, either of max-possible- and max-online-cpus is a reasonable size for this array) > LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i] > ret[i].core = V(coremap, i); > ret[i].socket = V(socketmap, i); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ex-0003mE-1S; Wed, 09 May 2012 12:43:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ev-0003ly-KB for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:43:33 +0000 Received: from [85.158.138.51:23904] by server-9.bemta-3.messagelabs.com id 71/13-26691-4766AAF4; Wed, 09 May 2012 12:43:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336567410!26048124!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7797 invoked from network); 9 May 2012 12:43:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12377597" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:43: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, 9 May 2012 13:43:25 +0100 Date: Wed, 9 May 2012 13:43:10 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1] rebase xen patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, this patch series is a collection of the outstanding Xen patches for QEMU 1.1: all of them have been sent to qemu-devel at least once already, some of them as many as 6 times. Patch 1 and 2 remove unneeded devices and timers when Xen is enabled, patch 3 and 4 are improvements for xen_disk.c. Stefano Stabellini (4): xen: do not initialize the interval timer and PCSPK emulator xen: disable rtc_clock xen_disk: remove syncwrite option xen_disk: use bdrv_aio_flush instead of bdrv_flush hw/pc.c | 23 +++++++++++++---------- hw/xen_disk.c | 30 +++++++++++++++++++----------- xen-all.c | 4 ++++ 3 files changed, 36 insertions(+), 21 deletions(-) git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_1.1 Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ex-0003mE-1S; Wed, 09 May 2012 12:43:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ev-0003ly-KB for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:43:33 +0000 Received: from [85.158.138.51:23904] by server-9.bemta-3.messagelabs.com id 71/13-26691-4766AAF4; Wed, 09 May 2012 12:43:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336567410!26048124!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7797 invoked from network); 9 May 2012 12:43:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12377597" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:43: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, 9 May 2012 13:43:25 +0100 Date: Wed, 9 May 2012 13:43:10 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1] rebase xen patches X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi all, this patch series is a collection of the outstanding Xen patches for QEMU 1.1: all of them have been sent to qemu-devel at least once already, some of them as many as 6 times. Patch 1 and 2 remove unneeded devices and timers when Xen is enabled, patch 3 and 4 are improvements for xen_disk.c. Stefano Stabellini (4): xen: do not initialize the interval timer and PCSPK emulator xen: disable rtc_clock xen_disk: remove syncwrite option xen_disk: use bdrv_aio_flush instead of bdrv_flush hw/pc.c | 23 +++++++++++++---------- hw/xen_disk.c | 30 +++++++++++++++++++----------- xen-all.c | 4 ++++ 3 files changed, 36 insertions(+), 21 deletions(-) git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_1.1 Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ew-0003m7-MS; Wed, 09 May 2012 12:43:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ev-0003lx-3M for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:43:33 +0000 Received: from [85.158.138.51:23845] by server-5.bemta-3.messagelabs.com id FA/74-17113-4766AAF4; Wed, 09 May 2012 12:43:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336567410!26048124!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7771 invoked from network); 9 May 2012 12:43:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12377587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:42: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, 9 May 2012 13:42:57 +0100 Date: Wed, 9 May 2012 13:42:41 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20120426154101.GD26830@phenom.dumpdata.com> Message-ID: References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120425084524.GA17537@lst.de> <1335344565.28015.7.camel@zakaz.uk.xensource.com> <20120425102024.GA19800@lst.de> <20120425112335.GA20868@lst.de> <20120426154101.GD26830@phenom.dumpdata.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "kwolf@redhat.com" , "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , "qemu-devel@nongnu.org" , Christoph Hellwig Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 26 Apr 2012, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 25, 2012 at 01:23:35PM +0200, Christoph Hellwig wrote: > > On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote: > > > That is true, in fact I couldn't figure out what I had to implement just > > > reading the comment. So I went through the blkback code and tried to > > > understand what I had to do, but I got it wrong. > > > > > > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE > > > is supposed to have the same semantics as REQ_FLUSH, that implies a > > > preflush if nr_segments > 0, not a postflush like I did. > > > > It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA > > into BLKIF_OP_FLUSH_DISKCACHE. > > I think that is what remained of the BARRIER request. > > > > REQ_FLUSH either is a pre flush or a pure flush without a data transfer, > > and REQ_FUA is a post flush. So to get the proper semantics you'll have > > to do both, _and_ sequence it so that no operation starts before the > > previous one finished. > > If I were to emulate the SCSI SYNC command which one would it be? > > I think REQ_FLUSH? In which I would think that the blkfront needs to > get rid of the REQ_FUA part? > ping? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ew-0003m7-MS; Wed, 09 May 2012 12:43:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ev-0003lx-3M for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:43:33 +0000 Received: from [85.158.138.51:23845] by server-5.bemta-3.messagelabs.com id FA/74-17113-4766AAF4; Wed, 09 May 2012 12:43:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336567410!26048124!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7771 invoked from network); 9 May 2012 12:43:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12377587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 12:42: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, 9 May 2012 13:42:57 +0100 Date: Wed, 9 May 2012 13:42:41 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Konrad Rzeszutek Wilk In-Reply-To: <20120426154101.GD26830@phenom.dumpdata.com> Message-ID: References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120425084524.GA17537@lst.de> <1335344565.28015.7.camel@zakaz.uk.xensource.com> <20120425102024.GA19800@lst.de> <20120425112335.GA20868@lst.de> <20120426154101.GD26830@phenom.dumpdata.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "kwolf@redhat.com" , "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , "qemu-devel@nongnu.org" , Christoph Hellwig Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 26 Apr 2012, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 25, 2012 at 01:23:35PM +0200, Christoph Hellwig wrote: > > On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote: > > > That is true, in fact I couldn't figure out what I had to implement just > > > reading the comment. So I went through the blkback code and tried to > > > understand what I had to do, but I got it wrong. > > > > > > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE > > > is supposed to have the same semantics as REQ_FLUSH, that implies a > > > preflush if nr_segments > 0, not a postflush like I did. > > > > It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA > > into BLKIF_OP_FLUSH_DISKCACHE. > > I think that is what remained of the BARRIER request. > > > > REQ_FLUSH either is a pre flush or a pure flush without a data transfer, > > and REQ_FUA is a post flush. So to get the proper semantics you'll have > > to do both, _and_ sequence it so that no operation starts before the > > previous one finished. > > If I were to emulate the SCSI SYNC command which one would it be? > > I think REQ_FLUSH? In which I would think that the blkfront needs to > get rid of the REQ_FUA part? > ping? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003r1-Eq; Wed, 09 May 2012 12:44:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fo-0003qi-3E for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:28 +0000 Received: from [193.109.254.147:30528] by server-4.bemta-14.messagelabs.com id 11/12-11570-BA66AAF4; Wed, 09 May 2012 12:44:27 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22045 invoked from network); 9 May 2012 12:44:25 -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; 9 May 2012 12:44:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015419" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:23 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-6v; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:15 +0100 Message-ID: <1336567456-20202-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 3/4] xen_disk: remove syncwrite option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch removes a dead option. The same can be achieved removing BDRV_O_NOCACHE and BDRV_O_CACHE_WB from the flags passed to bdrv_open. Signed-off-by: Stefano Stabellini --- hw/xen_disk.c | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 22dbd10..49e53b7 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -48,7 +48,6 @@ /* ------------------------------------------------------------- */ -static int syncwrite = 0; static int batch_maps = 0; static int max_requests = 32; @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->presync = 1; return 0; } - if (!syncwrite) { - ioreq->presync = ioreq->postsync = 1; - } + ioreq->presync = ioreq->postsync = 1; /* fall through */ case BLKIF_OP_WRITE: ioreq->prot = PROT_READ; /* from memory */ - if (syncwrite) { - ioreq->postsync = 1; - } break; default: xen_be_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n", -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003r1-Eq; Wed, 09 May 2012 12:44:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fo-0003qi-3E for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:28 +0000 Received: from [193.109.254.147:30528] by server-4.bemta-14.messagelabs.com id 11/12-11570-BA66AAF4; Wed, 09 May 2012 12:44:27 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22045 invoked from network); 9 May 2012 12:44:25 -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; 9 May 2012 12:44:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015419" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:23 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-6v; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:15 +0100 Message-ID: <1336567456-20202-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 3/4] xen_disk: remove syncwrite option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch removes a dead option. The same can be achieved removing BDRV_O_NOCACHE and BDRV_O_CACHE_WB from the flags passed to bdrv_open. Signed-off-by: Stefano Stabellini --- hw/xen_disk.c | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 22dbd10..49e53b7 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -48,7 +48,6 @@ /* ------------------------------------------------------------- */ -static int syncwrite = 0; static int batch_maps = 0; static int max_requests = 32; @@ -189,15 +188,10 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->presync = 1; return 0; } - if (!syncwrite) { - ioreq->presync = ioreq->postsync = 1; - } + ioreq->presync = ioreq->postsync = 1; /* fall through */ case BLKIF_OP_WRITE: ioreq->prot = PROT_READ; /* from memory */ - if (syncwrite) { - ioreq->postsync = 1; - } break; default: xen_be_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n", -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fq-0003rS-RJ; Wed, 09 May 2012 12:44:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003qx-KL for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:29 +0000 Received: from [85.158.143.99:49518] by server-1.bemta-4.messagelabs.com id 15/3C-20925-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336567466!26277943!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23311 invoked from network); 9 May 2012 12:44:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:44:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015422" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-5D; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:14 +0100 Message-ID: <1336567456-20202-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 2/4] xen: disable rtc_clock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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 --- xen-all.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xen-all.c b/xen-all.c index bdf9c0f..b88ad5d 100644 --- a/xen-all.c +++ b/xen-all.c @@ -603,6 +603,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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12:44:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fq-0003rS-RJ; Wed, 09 May 2012 12:44:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003qx-KL for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:29 +0000 Received: from [85.158.143.99:49518] by server-1.bemta-4.messagelabs.com id 15/3C-20925-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336567466!26277943!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23311 invoked from network); 9 May 2012 12:44:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:44:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015422" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-5D; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:14 +0100 Message-ID: <1336567456-20202-2-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 2/4] xen: disable rtc_clock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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 --- xen-all.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xen-all.c b/xen-all.c index bdf9c0f..b88ad5d 100644 --- a/xen-all.c +++ b/xen-all.c @@ -603,6 +603,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.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Fr-0003rp-Lt; Wed, 09 May 2012 12:44:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fq-0003r7-CI for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:30 +0000 Received: from [193.109.254.147:30652] by server-10.bemta-14.messagelabs.com id 0D/D3-05847-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22163 invoked from network); 9 May 2012 12:44:26 -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; 9 May 2012 12:44:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015420" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-4a; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:13 +0100 Message-ID: <1336567456-20202-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 1/4] xen: do not initialize the interval timer and PCSPK emulator X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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 --- hw/pc.c | 23 +++++++++++++---------- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/hw/pc.c b/hw/pc.c index 4d34a33..c52caf6 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -47,6 +47,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 @@ -1097,7 +1098,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, qemu_irq pit_alt_irq = NULL; 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); @@ -1126,16 +1127,18 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, qemu_register_boot_set(pc_boot_set, *rtc_state); - if (kvm_irqchip_in_kernel()) { - pit = kvm_pit_init(isa_bus, 0x40); - } else { - pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq); - } - if (hpet) { - /* connect PIT to output control line of the HPET */ - qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0)); + if (!xen_available()) { + if (kvm_irqchip_in_kernel()) { + pit = kvm_pit_init(isa_bus, 0x40); + } else { + pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq); + } + if (hpet) { + /* connect PIT to output control line of the HPET */ + qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0)); + } + pcspk_init(isa_bus, pit); } - pcspk_init(isa_bus, pit); for(i = 0; i < MAX_SERIAL_PORTS; i++) { if (serial_hds[i]) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Fr-0003rp-Lt; Wed, 09 May 2012 12:44:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fq-0003r7-CI for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:30 +0000 Received: from [193.109.254.147:30652] by server-10.bemta-14.messagelabs.com id 0D/D3-05847-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22163 invoked from network); 9 May 2012 12:44:26 -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; 9 May 2012 12:44:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015420" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-4a; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:13 +0100 Message-ID: <1336567456-20202-1-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 1/4] xen: do not initialize the interval timer and PCSPK emulator X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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 --- hw/pc.c | 23 +++++++++++++---------- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/hw/pc.c b/hw/pc.c index 4d34a33..c52caf6 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -47,6 +47,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 @@ -1097,7 +1098,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, qemu_irq pit_alt_irq = NULL; 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); @@ -1126,16 +1127,18 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi, qemu_register_boot_set(pc_boot_set, *rtc_state); - if (kvm_irqchip_in_kernel()) { - pit = kvm_pit_init(isa_bus, 0x40); - } else { - pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq); - } - if (hpet) { - /* connect PIT to output control line of the HPET */ - qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0)); + if (!xen_available()) { + if (kvm_irqchip_in_kernel()) { + pit = kvm_pit_init(isa_bus, 0x40); + } else { + pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq); + } + if (hpet) { + /* connect PIT to output control line of the HPET */ + qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(&pit->qdev, 0)); + } + pcspk_init(isa_bus, pit); } - pcspk_init(isa_bus, pit); for(i = 0; i < MAX_SERIAL_PORTS; i++) { if (serial_hds[i]) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Fr-0003rb-7h; Wed, 09 May 2012 12:44:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003qv-GW for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:29 +0000 Received: from [193.109.254.147:34165] by server-7.bemta-14.messagelabs.com id 4A/58-01627-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22221 invoked from network); 9 May 2012 12:44:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:44:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015421" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-88; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:16 +0100 Message-ID: <1336567456-20202-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 4/4] xen_disk: use bdrv_aio_flush instead of bdrv_flush X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Use bdrv_aio_flush instead of bdrv_flush. Make sure to call bdrv_aio_writev/readv after the presync bdrv_aio_flush is fully completed and make sure to call the postsync bdrv_aio_flush after bdrv_aio_writev/readv is fully completed. Signed-off-by: Stefano Stabellini --- hw/xen_disk.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 49e53b7..cf06243 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -66,6 +66,7 @@ struct ioreq { QEMUIOVector v; int presync; int postsync; + uint8_t mapped; /* grant mapping */ uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -242,7 +243,7 @@ static void ioreq_unmap(struct ioreq *ioreq) XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev; int i; - if (ioreq->v.niov == 0) { + if (ioreq->v.niov == 0 || ioreq->mapped == 0) { return; } if (batch_maps) { @@ -268,6 +269,7 @@ static void ioreq_unmap(struct ioreq *ioreq) ioreq->page[i] = NULL; } } + ioreq->mapped = 0; } static int ioreq_map(struct ioreq *ioreq) @@ -275,7 +277,7 @@ static int ioreq_map(struct ioreq *ioreq) XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev; int i; - if (ioreq->v.niov == 0) { + if (ioreq->v.niov == 0 || ioreq->mapped == 1) { return 0; } if (batch_maps) { @@ -307,9 +309,12 @@ static int ioreq_map(struct ioreq *ioreq) ioreq->blkdev->cnt_map++; } } + ioreq->mapped = 1; return 0; } +static int ioreq_runio_qemu_aio(struct ioreq *ioreq); + static void qemu_aio_complete(void *opaque, int ret) { struct ioreq *ioreq = opaque; @@ -321,11 +326,19 @@ static void qemu_aio_complete(void *opaque, int ret) } ioreq->aio_inflight--; + if (ioreq->presync) { + ioreq->presync = 0; + ioreq_runio_qemu_aio(ioreq); + return; + } if (ioreq->aio_inflight > 0) { return; } if (ioreq->postsync) { - bdrv_flush(ioreq->blkdev->bs); + ioreq->postsync = 0; + ioreq->aio_inflight++; + bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq); + return; } ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY; @@ -345,7 +358,8 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) ioreq->aio_inflight++; if (ioreq->presync) { - bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */ + bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq); + return 0; } switch (ioreq->req.operation) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:44:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Fr-0003rb-7h; Wed, 09 May 2012 12:44:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Fp-0003qv-GW for xen-devel@lists.xensource.com; Wed, 09 May 2012 12:44:29 +0000 Received: from [193.109.254.147:34165] by server-7.bemta-14.messagelabs.com id 4A/58-01627-CA66AAF4; Wed, 09 May 2012 12:44:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336567464!8457491!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22221 invoked from network); 9 May 2012 12:44:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:44:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25015421" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 08:44:24 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 08:44:23 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS6Fe-0007ez-88; Wed, 09 May 2012 13:44:18 +0100 From: Stefano Stabellini To: qemu-devel@nongnu.org Date: Wed, 9 May 2012 13:44:16 +0100 Message-ID: <1336567456-20202-4-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.0.4 In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Stefano Stabellini Subject: [Xen-devel] [PATCH 1.1 4/4] xen_disk: use bdrv_aio_flush instead of bdrv_flush X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Use bdrv_aio_flush instead of bdrv_flush. Make sure to call bdrv_aio_writev/readv after the presync bdrv_aio_flush is fully completed and make sure to call the postsync bdrv_aio_flush after bdrv_aio_writev/readv is fully completed. Signed-off-by: Stefano Stabellini --- hw/xen_disk.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/hw/xen_disk.c b/hw/xen_disk.c index 49e53b7..cf06243 100644 --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -66,6 +66,7 @@ struct ioreq { QEMUIOVector v; int presync; int postsync; + uint8_t mapped; /* grant mapping */ uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -242,7 +243,7 @@ static void ioreq_unmap(struct ioreq *ioreq) XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev; int i; - if (ioreq->v.niov == 0) { + if (ioreq->v.niov == 0 || ioreq->mapped == 0) { return; } if (batch_maps) { @@ -268,6 +269,7 @@ static void ioreq_unmap(struct ioreq *ioreq) ioreq->page[i] = NULL; } } + ioreq->mapped = 0; } static int ioreq_map(struct ioreq *ioreq) @@ -275,7 +277,7 @@ static int ioreq_map(struct ioreq *ioreq) XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev; int i; - if (ioreq->v.niov == 0) { + if (ioreq->v.niov == 0 || ioreq->mapped == 1) { return 0; } if (batch_maps) { @@ -307,9 +309,12 @@ static int ioreq_map(struct ioreq *ioreq) ioreq->blkdev->cnt_map++; } } + ioreq->mapped = 1; return 0; } +static int ioreq_runio_qemu_aio(struct ioreq *ioreq); + static void qemu_aio_complete(void *opaque, int ret) { struct ioreq *ioreq = opaque; @@ -321,11 +326,19 @@ static void qemu_aio_complete(void *opaque, int ret) } ioreq->aio_inflight--; + if (ioreq->presync) { + ioreq->presync = 0; + ioreq_runio_qemu_aio(ioreq); + return; + } if (ioreq->aio_inflight > 0) { return; } if (ioreq->postsync) { - bdrv_flush(ioreq->blkdev->bs); + ioreq->postsync = 0; + ioreq->aio_inflight++; + bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq); + return; } ioreq->status = ioreq->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY; @@ -345,7 +358,8 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) ioreq->aio_inflight++; if (ioreq->presync) { - bdrv_flush(blkdev->bs); /* FIXME: aio_flush() ??? */ + bdrv_aio_flush(ioreq->blkdev->bs, qemu_aio_complete, ioreq); + return 0; } switch (ioreq->req.operation) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:45:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 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 ) id 1SS6Gq-00046u-5R; Wed, 09 May 2012 12:45:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Go-00046N-Gv for xen-devel@lists.xen.org; Wed, 09 May 2012 12:45:30 +0000 Received: from [85.158.143.35:49278] by server-2.bemta-4.messagelabs.com id 6F/5E-17550-9E66AAF4; Wed, 09 May 2012 12:45:29 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-21.messagelabs.com!1336567527!15311289!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 338 invoked from network); 9 May 2012 12:45:27 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-21.messagelabs.com with SMTP; 9 May 2012 12:45:27 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77731675; Wed, 09 May 2012 14:45:25 +0200 Message-ID: <1336567524.2621.16.camel@Abyss> From: Dario Faggioli To: Ian Campbell Date: Wed, 09 May 2012 14:45:24 +0200 In-Reply-To: <1336565074.25514.104.camel@zakaz.uk.xensource.com> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336565074.25514.104.camel@zakaz.uk.xensource.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106433101483885304==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2106433101483885304== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Zt+sEP/VIgQbIUIvPJLC" --=-Zt+sEP/VIgQbIUIvPJLC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 13:04 +0100, Ian Campbell wrote:=20 > On Wed, 2012-05-09 at 12:03 +0100, Darrio Faggioli wrote: > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > > --- a/tools/libxl/libxl.c > > +++ b/tools/libxl/libxl.c > > @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog > > } > > =20 > > for (i =3D 0; i < max_cpus; i++) { > > -#define V(map, i) (map[i] =3D=3D INVALID_TOPOLOGY_ID) ? \ > > +#define V(map, i) (i > tinfo.max_cpu_index || \ > > + map[i] =3D=3D INVALID_TOPOLOGY_ID) ? \ >=20 > This ensures that cpus entries above max_cpu_index are > INVALID_TOPOLOGY_ID=20 > Yep, thus giving consumers of this call the chance to figure out what the valid entries are. It looked the most natural way of doing this, given output_topology (for instance) already check for LIBXL_CPUTOPOLOGY_INVALID_ENTRY entries and skip them. Also, the get-cpu-topology command in xenpm, which always worked properly on my testbox, does exactly that. > but do you also want to size the return array using > tinfo.max_cpu_index too? And also return that in *nr instead of? >=20 > (I don't know the answer, either of max-possible- and max-online-cpus is > a reasonable size for this array) >=20 Well, I really don't know either. This is the minimum impact working version. For sure, I'd like very much to return that value via *nr, as it will give me something more sensible to work with... You know what, I'm sending a patch doing exactly that, as I think what you're suggesting is actually better. Thanks, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Zt+sEP/VIgQbIUIvPJLC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+qZuQACgkQk4XaBE3IOsQsGwCfUVKyiupQ+mx/Q90zSwXfaQEi omgAnjc2eoVK8jUNPLiCgnAL18yUgeqb =fjnn -----END PGP SIGNATURE----- --=-Zt+sEP/VIgQbIUIvPJLC-- --===============2106433101483885304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2106433101483885304==-- From xen-devel-bounces@lists.xen.org Wed May 09 12:45:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 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 ) id 1SS6Gq-00046u-5R; Wed, 09 May 2012 12:45:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Go-00046N-Gv for xen-devel@lists.xen.org; Wed, 09 May 2012 12:45:30 +0000 Received: from [85.158.143.35:49278] by server-2.bemta-4.messagelabs.com id 6F/5E-17550-9E66AAF4; Wed, 09 May 2012 12:45:29 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-7.tower-21.messagelabs.com!1336567527!15311289!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 338 invoked from network); 9 May 2012 12:45:27 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-7.tower-21.messagelabs.com with SMTP; 9 May 2012 12:45:27 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77731675; Wed, 09 May 2012 14:45:25 +0200 Message-ID: <1336567524.2621.16.camel@Abyss> From: Dario Faggioli To: Ian Campbell Date: Wed, 09 May 2012 14:45:24 +0200 In-Reply-To: <1336565074.25514.104.camel@zakaz.uk.xensource.com> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336565074.25514.104.camel@zakaz.uk.xensource.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106433101483885304==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2106433101483885304== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Zt+sEP/VIgQbIUIvPJLC" --=-Zt+sEP/VIgQbIUIvPJLC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 13:04 +0100, Ian Campbell wrote:=20 > On Wed, 2012-05-09 at 12:03 +0100, Darrio Faggioli wrote: > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > > --- a/tools/libxl/libxl.c > > +++ b/tools/libxl/libxl.c > > @@ -2903,7 +2903,8 @@ libxl_cputopology *libxl_get_cpu_topolog > > } > > =20 > > for (i =3D 0; i < max_cpus; i++) { > > -#define V(map, i) (map[i] =3D=3D INVALID_TOPOLOGY_ID) ? \ > > +#define V(map, i) (i > tinfo.max_cpu_index || \ > > + map[i] =3D=3D INVALID_TOPOLOGY_ID) ? \ >=20 > This ensures that cpus entries above max_cpu_index are > INVALID_TOPOLOGY_ID=20 > Yep, thus giving consumers of this call the chance to figure out what the valid entries are. It looked the most natural way of doing this, given output_topology (for instance) already check for LIBXL_CPUTOPOLOGY_INVALID_ENTRY entries and skip them. Also, the get-cpu-topology command in xenpm, which always worked properly on my testbox, does exactly that. > but do you also want to size the return array using > tinfo.max_cpu_index too? And also return that in *nr instead of? >=20 > (I don't know the answer, either of max-possible- and max-online-cpus is > a reasonable size for this array) >=20 Well, I really don't know either. This is the minimum impact working version. For sure, I'd like very much to return that value via *nr, as it will give me something more sensible to work with... You know what, I'm sending a patch doing exactly that, as I think what you're suggesting is actually better. Thanks, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Zt+sEP/VIgQbIUIvPJLC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+qZuQACgkQk4XaBE3IOsQsGwCfUVKyiupQ+mx/Q90zSwXfaQEi omgAnjc2eoVK8jUNPLiCgnAL18yUgeqb =fjnn -----END PGP SIGNATURE----- --=-Zt+sEP/VIgQbIUIvPJLC-- --===============2106433101483885304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2106433101483885304==-- From xen-devel-bounces@lists.xen.org Wed May 09 12:46:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Hq-0004KZ-R5; Wed, 09 May 2012 12:46:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ho-0004Jx-PV for xen-devel@lists.xen.org; Wed, 09 May 2012 12:46:33 +0000 Received: from [85.158.138.51:57567] by server-6.bemta-3.messagelabs.com id 08/60-05145-7276AAF4; Wed, 09 May 2012 12:46:31 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336567590!18150883!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28039 invoked from network); 9 May 2012 12:46:30 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:46:30 -0000 Received: by eaak12 with SMTP id k12so106023eaa.32 for ; Wed, 09 May 2012 05:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=JRzYrdHsZUPf+4I10ByIVSrfsUpEMCcq7bf5cAzylh8=; b=AN/zRay9a9K5uonolqb2loW03/tEBdSh9MuWooVxfie/f/Vi0eq5Ut3Tgryz/U47nR QEaWRhZ68Q/Gy7UnR8xvUns64rAQTKr6goFFUS0WfoERfqDAbJ39kwy7o+YZsxEASTZW RCVdA1d0SgRaI0kPzlWr7bTL/L3IjW2KuiF1GRQGOLFYkH7q9wa+6vsoBeFuJ4cnxRcy LZ6zThRywJsTDAorRpbxvkhi+qs/2sxQgEwRuqkhs+J5UuSGOaV7QHdqaRXnhnFw5o/G O/j9tuY9KOa6dl4qk2wLsswQYzoyZdq6+rSoQnuO7hrxCGlu6cP1udTxlmKtJxqJseQ4 88lQ== Received: by 10.213.4.200 with SMTP id 8mr565715ebs.27.1336567590222; Wed, 09 May 2012 05:46:30 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id p57sm12291093eei.8.2012.05.09.05.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 05:46:29 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 95f7eacc32f0bf7ba2819014ebc1ba2293f16782 Message-Id: <95f7eacc32f0bf7ba281.1336567580@Solace> User-Agent: Mercurial-patchbomb/2.2 Date: Wed, 09 May 2012 14:46:20 +0200 From: Darrio Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor supports to be valid topology entries might lead to misleading and incorrect behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: ... cpu_topology : cpu: core socket node 0: 0 1 0 1: 0 1 0 2: 1 1 0 3: 1 1 0 4: 9 1 0 5: 9 1 0 6: 10 1 0 7: 10 1 0 8: 0 0 1 9: 0 0 1 10: 1 0 1 11: 1 0 1 12: 9 0 1 13: 9 0 1 14: 10 0 1 15: 10 0 1 16: 0 0 0 17: 0 0 0 18: 0 0 0 19: 0 0 0 20: 0 0 0 ... ... 62: 0 0 0 63: 0 0 0 However, xc_topologyinfo() tells us (in max_cpu_index) how many entries arrays it returns corresponds to actually valid CPUs, so let's use that information. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2895,6 +2895,9 @@ libxl_cputopology *libxl_get_cpu_topolog goto fail; } + if (tinfo.max_cpu_index < max_cpus - 1) + max_cpus = tinfo.max_cpu_index + 1; + ret = malloc(sizeof(libxl_cputopology) * max_cpus); if (ret == NULL) { LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 12:46:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 12: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 ) id 1SS6Hq-0004KZ-R5; Wed, 09 May 2012 12:46:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6Ho-0004Jx-PV for xen-devel@lists.xen.org; Wed, 09 May 2012 12:46:33 +0000 Received: from [85.158.138.51:57567] by server-6.bemta-3.messagelabs.com id 08/60-05145-7276AAF4; Wed, 09 May 2012 12:46:31 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336567590!18150883!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28039 invoked from network); 9 May 2012 12:46:30 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 12:46:30 -0000 Received: by eaak12 with SMTP id k12so106023eaa.32 for ; Wed, 09 May 2012 05:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=JRzYrdHsZUPf+4I10ByIVSrfsUpEMCcq7bf5cAzylh8=; b=AN/zRay9a9K5uonolqb2loW03/tEBdSh9MuWooVxfie/f/Vi0eq5Ut3Tgryz/U47nR QEaWRhZ68Q/Gy7UnR8xvUns64rAQTKr6goFFUS0WfoERfqDAbJ39kwy7o+YZsxEASTZW RCVdA1d0SgRaI0kPzlWr7bTL/L3IjW2KuiF1GRQGOLFYkH7q9wa+6vsoBeFuJ4cnxRcy LZ6zThRywJsTDAorRpbxvkhi+qs/2sxQgEwRuqkhs+J5UuSGOaV7QHdqaRXnhnFw5o/G O/j9tuY9KOa6dl4qk2wLsswQYzoyZdq6+rSoQnuO7hrxCGlu6cP1udTxlmKtJxqJseQ4 88lQ== Received: by 10.213.4.200 with SMTP id 8mr565715ebs.27.1336567590222; Wed, 09 May 2012 05:46:30 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id p57sm12291093eei.8.2012.05.09.05.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 05:46:29 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 95f7eacc32f0bf7ba2819014ebc1ba2293f16782 Message-Id: <95f7eacc32f0bf7ba281.1336567580@Solace> User-Agent: Mercurial-patchbomb/2.2 Date: Wed, 09 May 2012 14:46:20 +0200 From: Darrio Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: George Dunlap , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor supports to be valid topology entries might lead to misleading and incorrect behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: ... cpu_topology : cpu: core socket node 0: 0 1 0 1: 0 1 0 2: 1 1 0 3: 1 1 0 4: 9 1 0 5: 9 1 0 6: 10 1 0 7: 10 1 0 8: 0 0 1 9: 0 0 1 10: 1 0 1 11: 1 0 1 12: 9 0 1 13: 9 0 1 14: 10 0 1 15: 10 0 1 16: 0 0 0 17: 0 0 0 18: 0 0 0 19: 0 0 0 20: 0 0 0 ... ... 62: 0 0 0 63: 0 0 0 However, xc_topologyinfo() tells us (in max_cpu_index) how many entries arrays it returns corresponds to actually valid CPUs, so let's use that information. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2895,6 +2895,9 @@ libxl_cputopology *libxl_get_cpu_topolog goto fail; } + if (tinfo.max_cpu_index < max_cpus - 1) + max_cpus = tinfo.max_cpu_index + 1; + ret = malloc(sizeof(libxl_cputopology) * max_cpus); if (ret == NULL) { LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:12:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS6gl-0004zr-1Y; Wed, 09 May 2012 13:12:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6gk-0004zm-8D for xen-devel@lists.xen.org; Wed, 09 May 2012 13:12:18 +0000 Received: from [193.109.254.147:60648] by server-1.bemta-14.messagelabs.com id D2/D6-29372-13D6AAF4; Wed, 09 May 2012 13:12:17 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336569134!1530297!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27103 invoked from network); 9 May 2012 13:12:15 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 13:12: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 q49DBxTp014100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2012 09:11:59 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q49DBsaP014089; Wed, 9 May 2012 09:11:54 -0400 Date: Wed, 9 May 2012 09:11:54 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk , haitao.shan@intel.com Message-ID: <20120509131153.GA13956@andromeda.dapyr.net> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120509003510.GA19643@phenom.dumpdata.com> User-Agent: Mutt/1.5.9i Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > konrad.wilk@oracle.com> wrote: > > > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > > (i.e. the outcome of the above printing you added) the problem in > > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > > attempting XSETBV). What your patch efectively does is take away > > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > > following message: > > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > > 00002660 > > > > > > > > > > ... which is what this message is telling you. > > > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > > xsave=1. > > > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > > added, > > > > > to find out why the CR4 write supposedly happening immediately > > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > > > Where did you see that code? Looking at the Linus's tree this is what I > > > see > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > > > So who added that code? I am not seeing it in v3.0 either? > > > > This is in the Ubuntu 11.10 kernel: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > > Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > CC-ing Intel. It seems that the userspace programs are crashingon Sandybridge machines even if 'xsave=0' is provided on the command line. Any advice? > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:12:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS6gl-0004zr-1Y; Wed, 09 May 2012 13:12:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6gk-0004zm-8D for xen-devel@lists.xen.org; Wed, 09 May 2012 13:12:18 +0000 Received: from [193.109.254.147:60648] by server-1.bemta-14.messagelabs.com id D2/D6-29372-13D6AAF4; Wed, 09 May 2012 13:12:17 +0000 X-Env-Sender: darnok@68k.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1336569134!1530297!1 X-Originating-IP: [206.212.254.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27103 invoked from network); 9 May 2012 13:12:15 -0000 Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 13:12: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 q49DBxTp014100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2012 09:11:59 -0400 Received: (from darnok@localhost) by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q49DBsaP014089; Wed, 9 May 2012 09:11:54 -0400 Date: Wed, 9 May 2012 09:11:54 -0400 From: Konrad Rzeszutek Wilk To: Konrad Rzeszutek Wilk , haitao.shan@intel.com Message-ID: <20120509131153.GA13956@andromeda.dapyr.net> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120509003510.GA19643@phenom.dumpdata.com> User-Agent: Mutt/1.5.9i Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > konrad.wilk@oracle.com> wrote: > > > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > > (i.e. the outcome of the above printing you added) the problem in > > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > > attempting XSETBV). What your patch efectively does is take away > > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > > following message: > > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > > 00002660 > > > > > > > > > > ... which is what this message is telling you. > > > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > > xsave=1. > > > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > > added, > > > > > to find out why the CR4 write supposedly happening immediately > > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > > > Where did you see that code? Looking at the Linus's tree this is what I > > > see > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > > > So who added that code? I am not seeing it in v3.0 either? > > > > This is in the Ubuntu 11.10 kernel: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > > Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > CC-ing Intel. It seems that the userspace programs are crashingon Sandybridge machines even if 'xsave=0' is provided on the command line. Any advice? > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:19:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS6nV-00058j-Sw; Wed, 09 May 2012 13:19:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6nU-00058e-1Y for xen-devel@lists.xen.org; Wed, 09 May 2012 13:19:16 +0000 Received: from [193.109.254.147:24702] by server-11.bemta-14.messagelabs.com id 97/EA-05858-3DE6AAF4; Wed, 09 May 2012 13:19:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336569554!1562651!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15286 invoked from network); 9 May 2012 13:19:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:19:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12378729" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:19:14 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:19:14 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS6nS-0007pu-2h; Wed, 09 May 2012 13:19:14 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS6nR-0003Gm-Uj; Wed, 09 May 2012 14:19:14 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.28369.936242.527916@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:19:13 +0100 To: Daniel De Graaf In-Reply-To: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Change the macro to a statement including the > return variable to fix this. Well spotted, thanks. But I think it would be better to use the GCC statement expression syntax to avoid changing the call sites ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:19:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS6nV-00058j-Sw; Wed, 09 May 2012 13:19:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6nU-00058e-1Y for xen-devel@lists.xen.org; Wed, 09 May 2012 13:19:16 +0000 Received: from [193.109.254.147:24702] by server-11.bemta-14.messagelabs.com id 97/EA-05858-3DE6AAF4; Wed, 09 May 2012 13:19:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336569554!1562651!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15286 invoked from network); 9 May 2012 13:19:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:19:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12378729" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:19:14 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:19:14 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS6nS-0007pu-2h; Wed, 09 May 2012 13:19:14 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS6nR-0003Gm-Uj; Wed, 09 May 2012 14:19:14 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.28369.936242.527916@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:19:13 +0100 To: Daniel De Graaf In-Reply-To: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Change the macro to a statement including the > return variable to fix this. Well spotted, thanks. But I think it would be better to use the GCC statement expression syntax to avoid changing the call sites ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:20:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:20:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6oZ-0005Ba-BU; Wed, 09 May 2012 13:20:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6oX-0005BQ-CG for xen-devel@lists.xen.org; Wed, 09 May 2012 13:20:21 +0000 Received: from [85.158.143.99:13060] by server-1.bemta-4.messagelabs.com id 4D/FD-20925-41F6AAF4; Wed, 09 May 2012 13:20:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336569619!26286578!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19085 invoked from network); 9 May 2012 13:20:19 -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 May 2012 13:20:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12378757" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13: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; Wed, 9 May 2012 14:20:18 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS6oU-0007qO-1H; Wed, 09 May 2012 13:20:18 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS6oU-0003I7-07; Wed, 09 May 2012 14:20:18 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.28433.983986.883494@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:20:17 +0100 To: Daniel De Graaf In-Reply-To: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Change the macro to a statement including the > return variable to fix this. Also, does this mean that you're using this in anger, or did you just happen to spot it while perusing the code ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:20:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:20:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6oZ-0005Ba-BU; Wed, 09 May 2012 13:20:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6oX-0005BQ-CG for xen-devel@lists.xen.org; Wed, 09 May 2012 13:20:21 +0000 Received: from [85.158.143.99:13060] by server-1.bemta-4.messagelabs.com id 4D/FD-20925-41F6AAF4; Wed, 09 May 2012 13:20:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336569619!26286578!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19085 invoked from network); 9 May 2012 13:20:19 -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 May 2012 13:20:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12378757" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13: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; Wed, 9 May 2012 14:20:18 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS6oU-0007qO-1H; Wed, 09 May 2012 13:20:18 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS6oU-0003I7-07; Wed, 09 May 2012 14:20:18 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.28433.983986.883494@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:20:17 +0100 To: Daniel De Graaf In-Reply-To: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Change the macro to a statement including the > return variable to fix this. Also, does this mean that you're using this in anger, or did you just happen to spot it while perusing the code ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:30:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:30:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6y1-0005Qk-Gu; Wed, 09 May 2012 13:30:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6y0-0005Qf-AX for xen-devel@lists.xen.org; Wed, 09 May 2012 13:30:08 +0000 Received: from [85.158.143.35:29162] by server-2.bemta-4.messagelabs.com id 81/50-17550-F517AAF4; Wed, 09 May 2012 13:30:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336570204!3901035!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10898 invoked from network); 9 May 2012 13:30:05 -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; 9 May 2012 13:30:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379068" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:30: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, 9 May 2012 14:30:04 +0100 Message-ID: <1336570202.25514.112.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Wed, 9 May 2012 14:30:02 +0100 In-Reply-To: <20120509131153.GA13956@andromeda.dapyr.net> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "Tim Deegan \(3P\)" , Konrad Rzeszutek Wilk , "haitao.shan@intel.com" , "weidong.han@intel.com" , "stefan.bader@canonical.com" , xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 14:11 +0100, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > > konrad.wilk@oracle.com> wrote: > > > > > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > > > (i.e. the outcome of the above printing you added) the problem in > > > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > > > attempting XSETBV). What your patch efectively does is take away > > > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > > > following message: > > > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > > > 00002660 > > > > > > > > > > > > ... which is what this message is telling you. > > > > > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > > > xsave=1. > > > > > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > > > added, > > > > > > to find out why the CR4 write supposedly happening immediately > > > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > > > > > Where did you see that code? Looking at the Linus's tree this is what I > > > > see > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > > > > > So who added that code? I am not seeing it in v3.0 either? > > > > > > This is in the Ubuntu 11.10 kernel: > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > > > > > Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > > > > CC-ing Intel. It seems that the userspace programs are crashingon > Sandybridge machines even if 'xsave=0' is provided on the command line. Is this related to the glibc bug which uses xsave/avx without properly following the defined procedure to detect if it is available, as described in http://marc.info/?l=xen-devel&m=133612371602480 ? That bug has come up a couple of times recently, I'm not sure if this is the same one though. Ian. > Any advice? > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:30:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:30:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6y1-0005Qk-Gu; Wed, 09 May 2012 13:30:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS6y0-0005Qf-AX for xen-devel@lists.xen.org; Wed, 09 May 2012 13:30:08 +0000 Received: from [85.158.143.35:29162] by server-2.bemta-4.messagelabs.com id 81/50-17550-F517AAF4; Wed, 09 May 2012 13:30:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336570204!3901035!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10898 invoked from network); 9 May 2012 13:30:05 -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; 9 May 2012 13:30:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379068" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:30: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, 9 May 2012 14:30:04 +0100 Message-ID: <1336570202.25514.112.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Wed, 9 May 2012 14:30:02 +0100 In-Reply-To: <20120509131153.GA13956@andromeda.dapyr.net> References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Jeremy Fitzhardinge , "Tim Deegan \(3P\)" , Konrad Rzeszutek Wilk , "haitao.shan@intel.com" , "weidong.han@intel.com" , "stefan.bader@canonical.com" , xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 14:11 +0100, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > > > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > > > konrad.wilk@oracle.com> wrote: > > > > > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > > > (i.e. the outcome of the above printing you added) the problem in > > > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > > > attempting XSETBV). What your patch efectively does is take away > > > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > > > following message: > > > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > > > 00002660 > > > > > > > > > > > > ... which is what this message is telling you. > > > > > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > > > xsave=1. > > > > > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > > > added, > > > > > > to find out why the CR4 write supposedly happening immediately > > > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > > > > > Where did you see that code? Looking at the Linus's tree this is what I > > > > see > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > > > > > So who added that code? I am not seeing it in v3.0 either? > > > > > > This is in the Ubuntu 11.10 kernel: > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > > > > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b > > > > > > Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > > > > CC-ing Intel. It seems that the userspace programs are crashingon > Sandybridge machines even if 'xsave=0' is provided on the command line. Is this related to the glibc bug which uses xsave/avx without properly following the defined procedure to detect if it is available, as described in http://marc.info/?l=xen-devel&m=133612371602480 ? That bug has come up a couple of times recently, I'm not sure if this is the same one though. Ian. > Any advice? > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:34:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:34:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS72G-0005bC-9A; Wed, 09 May 2012 13:34:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS72E-0005b6-N2 for xen-devel@lists.xen.org; Wed, 09 May 2012 13:34:30 +0000 Received: from [85.158.139.83:8199] by server-4.bemta-5.messagelabs.com id 74/8F-10788-5627AAF4; Wed, 09 May 2012 13:34:29 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336570467!27476007!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13422 invoked from network); 9 May 2012 13:34:28 -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; 9 May 2012 13:34:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 09 May 2012 14:34:26 +0100 Message-Id: <4FAA8E96020000780008288F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 09 May 2012 14:34:46 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" , , "Konrad Rzeszutek Wilk" References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> In-Reply-To: <20120509131153.GA13956@andromeda.dapyr.net> Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 09.05.12 at 15:11, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: >> On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: >> > After some digging around, it looks like this is an Ubuntu 11.10 only > patch: >> > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fb > a59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b82416 > 0b >> >> >> Ugh. There are looks to be a bug in Fedora as well: > https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. >> > > CC-ing Intel. It seems that the userspace programs are crashingon > Sandybridge machines even if 'xsave=0' is provided on the command line. > Any advice? Going through the bug, all I can see are bogus attempts to pass "xsave=" (with value 0 or 1) to the kernel. That's a hypervisor option though, and the only kernel option that's relevant here is "noxsave" afaik. Further, when the hypervisor has xsave support enabled, there's (in the pv case) nothing the kernel can do to hide the functionality from applications, as the hardware's CR4.OSXSAVE will be set, and hence CPUID.OSXSAVE will be too. So "noxsave" on the kernel command line when "xsave=1" (or xsave enabled by default as in 4.2) just doesn't make any sense. And finally one always has to keep in mind that there is this nice glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE when trying to determine whether AVX or FMA is available. Jan Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:34:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:34:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS72G-0005bC-9A; Wed, 09 May 2012 13:34:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS72E-0005b6-N2 for xen-devel@lists.xen.org; Wed, 09 May 2012 13:34:30 +0000 Received: from [85.158.139.83:8199] by server-4.bemta-5.messagelabs.com id 74/8F-10788-5627AAF4; Wed, 09 May 2012 13:34:29 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336570467!27476007!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13422 invoked from network); 9 May 2012 13:34:28 -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; 9 May 2012 13:34:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 09 May 2012 14:34:26 +0100 Message-Id: <4FAA8E96020000780008288F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 09 May 2012 14:34:46 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" , , "Konrad Rzeszutek Wilk" References: <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> In-Reply-To: <20120509131153.GA13956@andromeda.dapyr.net> Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 09.05.12 at 15:11, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: >> On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: >> > After some digging around, it looks like this is an Ubuntu 11.10 only > patch: >> > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fb > a59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b82416 > 0b >> >> >> Ugh. There are looks to be a bug in Fedora as well: > https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. >> > > CC-ing Intel. It seems that the userspace programs are crashingon > Sandybridge machines even if 'xsave=0' is provided on the command line. > Any advice? Going through the bug, all I can see are bogus attempts to pass "xsave=" (with value 0 or 1) to the kernel. That's a hypervisor option though, and the only kernel option that's relevant here is "noxsave" afaik. Further, when the hypervisor has xsave support enabled, there's (in the pv case) nothing the kernel can do to hide the functionality from applications, as the hardware's CR4.OSXSAVE will be set, and hence CPUID.OSXSAVE will be too. So "noxsave" on the kernel command line when "xsave=1" (or xsave enabled by default as in 4.2) just doesn't make any sense. And finally one always has to keep in mind that there is this nice glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE when trying to determine whether AVX or FMA is available. Jan Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:35:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS73D-0005ep-Nr; Wed, 09 May 2012 13:35:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS73C-0005ed-Ft for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:35:30 +0000 Received: from [85.158.143.35:27623] by server-2.bemta-4.messagelabs.com id A1/4A-17550-1A27AAF4; Wed, 09 May 2012 13:35:29 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336570527!15321371!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5670 invoked from network); 9 May 2012 13:35:28 -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 May 2012 13:35:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379418" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:35:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:35:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS738-0007vK-On; Wed, 09 May 2012 13:35:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS738-0003Yp-NZ; Wed, 09 May 2012 14:35:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.29342.710868.71635@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:35:26 +0100 To: Ian Campbell In-Reply-To: <1336485670.14542.92.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.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" , Fantu Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Test result of xen-unstable changeset 25259"): > > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell Looks plausible. Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:35:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS73D-0005ep-Nr; Wed, 09 May 2012 13:35:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS73C-0005ed-Ft for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:35:30 +0000 Received: from [85.158.143.35:27623] by server-2.bemta-4.messagelabs.com id A1/4A-17550-1A27AAF4; Wed, 09 May 2012 13:35:29 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336570527!15321371!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5670 invoked from network); 9 May 2012 13:35:28 -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 May 2012 13:35:28 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379418" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:35:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:35:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS738-0007vK-On; Wed, 09 May 2012 13:35:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS738-0003Yp-NZ; Wed, 09 May 2012 14:35:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.29342.710868.71635@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:35:26 +0100 To: Ian Campbell In-Reply-To: <1336485670.14542.92.camel@zakaz.uk.xensource.com> References: <1336399932385-5691153.post@n5.nabble.com> <1336480693.14542.71.camel@zakaz.uk.xensource.com> <1336483376041-5694297.post@n5.nabble.com> <1336483800.14542.88.camel@zakaz.uk.xensource.com> <1336484287336-5694426.post@n5.nabble.com> <1336484759.14542.91.camel@zakaz.uk.xensource.com> <1336485670.14542.92.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" , Fantu Subject: Re: [Xen-devel] Test result of xen-unstable changeset 25259 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Test result of xen-unstable changeset 25259"): > > libxc: do not "panic" if a kernel is not a bzImage. > > Up untul the point where we think this is a bzImage there is no point in > printing panicy messages -- some other loader will have a go (probably the > compressed ELF one) > > Signed-off-by: Ian Campbell Looks plausible. Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:40:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS77L-0005uN-Ib; Wed, 09 May 2012 13:39:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS77K-0005uF-Do for xen-devel@lists.xen.org; Wed, 09 May 2012 13:39:46 +0000 Received: from [85.158.139.83:59588] by server-11.bemta-5.messagelabs.com id 80/A9-12959-1A37AAF4; Wed, 09 May 2012 13:39:45 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-2.tower-182.messagelabs.com!1336570784!27472712!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9614 invoked from network); 9 May 2012 13:39:44 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-2.tower-182.messagelabs.com with SMTP; 9 May 2012 13:39:44 -0000 X-TM-IMSS-Message-ID: <331f1091000c4fcb@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 331f1091000c4fcb ; Wed, 9 May 2012 09:39:54 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49DdcB9005551; Wed, 9 May 2012 09:39:38 -0400 Message-ID: <4FAA7354.5070802@tycho.nsa.gov> Date: Wed, 09 May 2012 09:38:28 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> In-Reply-To: <20394.28369.936242.527916@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 09:19 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the >> expression CTX->osevent_in_hook-- (usually 1) instead of the value of >> the function call it made. Change the macro to a statement including the >> return variable to fix this. > > Well spotted, thanks. But I think it would be better to use the GCC > statement expression syntax to avoid changing the call sites ? > > Ian. > Agreed, using the statement expression syntax seems cleaner here. ------8<------------------------------ The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Fix the macro to return the proper value. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 31 +++++++++++++++++++------------ 1 files changed, 19 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..bee0e27 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,25 @@ * 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__) +#define OSEVENT_HOOK(hookname,...) ({ \ + int rc; \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } else { \ + rc = 0; \ + } \ + rc; \ +}) + +#define OSEVENT_HOOK_VOID(hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) /* * fd events _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:40:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS77L-0005uN-Ib; Wed, 09 May 2012 13:39:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS77K-0005uF-Do for xen-devel@lists.xen.org; Wed, 09 May 2012 13:39:46 +0000 Received: from [85.158.139.83:59588] by server-11.bemta-5.messagelabs.com id 80/A9-12959-1A37AAF4; Wed, 09 May 2012 13:39:45 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-2.tower-182.messagelabs.com!1336570784!27472712!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9614 invoked from network); 9 May 2012 13:39:44 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-2.tower-182.messagelabs.com with SMTP; 9 May 2012 13:39:44 -0000 X-TM-IMSS-Message-ID: <331f1091000c4fcb@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 331f1091000c4fcb ; Wed, 9 May 2012 09:39:54 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49DdcB9005551; Wed, 9 May 2012 09:39:38 -0400 Message-ID: <4FAA7354.5070802@tycho.nsa.gov> Date: Wed, 09 May 2012 09:38:28 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> In-Reply-To: <20394.28369.936242.527916@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 09:19 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the >> expression CTX->osevent_in_hook-- (usually 1) instead of the value of >> the function call it made. Change the macro to a statement including the >> return variable to fix this. > > Well spotted, thanks. But I think it would be better to use the GCC > statement expression syntax to avoid changing the call sites ? > > Ian. > Agreed, using the statement expression syntax seems cleaner here. ------8<------------------------------ The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Fix the macro to return the proper value. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 31 +++++++++++++++++++------------ 1 files changed, 19 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..bee0e27 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,25 @@ * 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__) +#define OSEVENT_HOOK(hookname,...) ({ \ + int rc; \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } else { \ + rc = 0; \ + } \ + rc; \ +}) + +#define OSEVENT_HOOK_VOID(hookname,...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) /* * fd events _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:40:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS77S-0005uu-VP; Wed, 09 May 2012 13:39:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS77R-0005uo-PJ for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:39:54 +0000 Received: from [193.109.254.147:36951] by server-10.bemta-14.messagelabs.com id 3B/0F-05847-8A37AAF4; Wed, 09 May 2012 13:39:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336570789!8370696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32306 invoked from network); 9 May 2012 13:39:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:39:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379558" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:39: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, 9 May 2012 14:39:49 +0100 Message-ID: <1336570788.25514.117.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:39:48 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > If the full path for a bootloader (such as pygrub or xenpvnetboot) is not > given, look for it in the libexec path. xend used to do something similar, see tools/python/xen/util/auxbin.py where it searches in: SEARCHDIRS = [ BINDIR, SBINDIR, LIBEXEC, PRIVATE_BINDIR, XENFIRMWAREDIR ] where: SBINDIR="/usr/sbin" BINDIR="/usr/bin" LIBEXEC="/usr/lib/xen/bin" PRIVATE_BINDIR="/usr/lib/xen/bin" XENFIRMWAREDIR="/usr/lib/xen/boot" I think since libxl uses execvp the first two are handled by path expansion, the next two are what you are adding (so has priority over $PATH in your patch, which I think is OK) and the last one is irrelevant in this context (xend uses the same function for other contexts). However in order to not differ on the first two execvp needs to be given the opportunity to search the path, which means that you need to check of your newly constructed bootloader exists, and if it doesn't then try and continue with the relative path not the absolute one. Also since this patch comes before the rename+symlink patch as it stands this patch will temporarily break people who just have "pygrub" without a path in their config. Ian. > Signed-off-by: George Dunlap > > diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c > --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 > +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 > @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > > char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; > char *tempdir; > + const char *bootloader = NULL; > > char *dom_console_xs_path; > char dom_console_slave_tty_path[PATH_MAX]; > @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, > + libxl__libexec_path()); > + if ( bootloader == NULL ) { > + rc = ERROR_NOMEM; > + goto out_close; > + } > + > /* > * We need to present the bootloader's tty as a pty slave that xenconsole > * can access. Since the bootloader itself needs a pty slave, > @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); > libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); > > - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); > + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); > if (pid < 0) { > goto out_close; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:40:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS77S-0005uu-VP; Wed, 09 May 2012 13:39:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS77R-0005uo-PJ for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:39:54 +0000 Received: from [193.109.254.147:36951] by server-10.bemta-14.messagelabs.com id 3B/0F-05847-8A37AAF4; Wed, 09 May 2012 13:39:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336570789!8370696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32306 invoked from network); 9 May 2012 13:39:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:39:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379558" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:39: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, 9 May 2012 14:39:49 +0100 Message-ID: <1336570788.25514.117.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:39:48 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > If the full path for a bootloader (such as pygrub or xenpvnetboot) is not > given, look for it in the libexec path. xend used to do something similar, see tools/python/xen/util/auxbin.py where it searches in: SEARCHDIRS = [ BINDIR, SBINDIR, LIBEXEC, PRIVATE_BINDIR, XENFIRMWAREDIR ] where: SBINDIR="/usr/sbin" BINDIR="/usr/bin" LIBEXEC="/usr/lib/xen/bin" PRIVATE_BINDIR="/usr/lib/xen/bin" XENFIRMWAREDIR="/usr/lib/xen/boot" I think since libxl uses execvp the first two are handled by path expansion, the next two are what you are adding (so has priority over $PATH in your patch, which I think is OK) and the last one is irrelevant in this context (xend uses the same function for other contexts). However in order to not differ on the first two execvp needs to be given the opportunity to search the path, which means that you need to check of your newly constructed bootloader exists, and if it doesn't then try and continue with the relative path not the absolute one. Also since this patch comes before the rename+symlink patch as it stands this patch will temporarily break people who just have "pygrub" without a path in their config. Ian. > Signed-off-by: George Dunlap > > diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c > --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 > +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 > @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > > char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; > char *tempdir; > + const char *bootloader = NULL; > > char *dom_console_xs_path; > char dom_console_slave_tty_path[PATH_MAX]; > @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, > + libxl__libexec_path()); > + if ( bootloader == NULL ) { > + rc = ERROR_NOMEM; > + goto out_close; > + } > + > /* > * We need to present the bootloader's tty as a pty slave that xenconsole > * can access. Since the bootloader itself needs a pty slave, > @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, > dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); > libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); > > - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); > + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); > if (pid < 0) { > goto out_close; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:42:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:42:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79b-00065S-GM; Wed, 09 May 2012 13:42:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79Z-00065G-Ii for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:42:05 +0000 Received: from [85.158.143.99:44551] by server-3.bemta-4.messagelabs.com id B7/85-05853-C247AAF4; Wed, 09 May 2012 13:42:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336570920!21872615!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4755 invoked from network); 9 May 2012 13:42:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:42:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379648" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:41:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:41:58 +0100 Message-ID: <1336570917.25514.119.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:41:57 +0100 In-Reply-To: <52f45b258cccd8bb4923.1336560665@kodo2> References: <52f45b258cccd8bb4923.1336560665@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 3 RESEND] tools: Install pv bootloaders in libexec rather than /usr/bin X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > pygrub and xenpvnetboot are meant to be run by tools, and not by the user, > and thus should be in /usr/lib/xen/bin rather than /usr/bin. > > Because most config files will still have an absolute path pointing to > /usr/bin/pygrub, make a symbolic link that we will deprecate. You forgot your S-o-b. I think that moving xenpvnetboot out of $PATH before 4.2 is a good idea, so we don't have to worry about compatibility concerns since we never previously released with xenpvnetboot. I think this patch should go in before 1 of 3 to minimise the window of breakage (see my comment on that patch). Acked-by: Ian Campbell > > diff -r e43157a86933 -r 52f45b258ccc tools/misc/Makefile > --- a/tools/misc/Makefile Wed May 09 11:38:50 2012 +0100 > +++ b/tools/misc/Makefile Wed May 09 11:39:43 2012 +0100 > @@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount > SUBDIRS-$(CONFIG_MINITERM) += miniterm > SUBDIRS := $(SUBDIRS-y) > > -INSTALL_BIN-y := xencons xenpvnetboot > +INSTALL_BIN-y := xencons > INSTALL_BIN-$(CONFIG_X86) += xen-detect > INSTALL_BIN := $(INSTALL_BIN-y) > > @@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx > INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool > INSTALL_SBIN := $(INSTALL_SBIN-y) > > +INSTALL_PRIVBIN-y := xenpvnetboot > +INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y) > + > # Include configure output (config.h) to headers search path > CFLAGS += -I$(XEN_ROOT)/tools > > @@ -41,8 +44,10 @@ build: $(TARGETS) > install: build > $(INSTALL_DIR) $(DESTDIR)$(BINDIR) > $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) > + $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR) > $(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR) > $(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR) > + $(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR) > set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done > > .PHONY: clean > diff -r e43157a86933 -r 52f45b258ccc tools/pygrub/Makefile > --- a/tools/pygrub/Makefile Wed May 09 11:38:50 2012 +0100 > +++ b/tools/pygrub/Makefile Wed May 09 11:39:43 2012 +0100 > @@ -11,9 +11,11 @@ build: > .PHONY: install > install: all > CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \ > - $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force > - $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub > + $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \ > + --install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force > + $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub > $(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot > + ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR) > > .PHONY: clean > clean: > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:42:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:42:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79b-00065S-GM; Wed, 09 May 2012 13:42:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79Z-00065G-Ii for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:42:05 +0000 Received: from [85.158.143.99:44551] by server-3.bemta-4.messagelabs.com id B7/85-05853-C247AAF4; Wed, 09 May 2012 13:42:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336570920!21872615!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4755 invoked from network); 9 May 2012 13:42:03 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:42:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379648" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:41:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:41:58 +0100 Message-ID: <1336570917.25514.119.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:41:57 +0100 In-Reply-To: <52f45b258cccd8bb4923.1336560665@kodo2> References: <52f45b258cccd8bb4923.1336560665@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 3 RESEND] tools: Install pv bootloaders in libexec rather than /usr/bin X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > pygrub and xenpvnetboot are meant to be run by tools, and not by the user, > and thus should be in /usr/lib/xen/bin rather than /usr/bin. > > Because most config files will still have an absolute path pointing to > /usr/bin/pygrub, make a symbolic link that we will deprecate. You forgot your S-o-b. I think that moving xenpvnetboot out of $PATH before 4.2 is a good idea, so we don't have to worry about compatibility concerns since we never previously released with xenpvnetboot. I think this patch should go in before 1 of 3 to minimise the window of breakage (see my comment on that patch). Acked-by: Ian Campbell > > diff -r e43157a86933 -r 52f45b258ccc tools/misc/Makefile > --- a/tools/misc/Makefile Wed May 09 11:38:50 2012 +0100 > +++ b/tools/misc/Makefile Wed May 09 11:39:43 2012 +0100 > @@ -18,7 +18,7 @@ SUBDIRS-$(CONFIG_LOMOUNT) += lomount > SUBDIRS-$(CONFIG_MINITERM) += miniterm > SUBDIRS := $(SUBDIRS-y) > > -INSTALL_BIN-y := xencons xenpvnetboot > +INSTALL_BIN-y := xencons > INSTALL_BIN-$(CONFIG_X86) += xen-detect > INSTALL_BIN := $(INSTALL_BIN-y) > > @@ -27,6 +27,9 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx > INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool > INSTALL_SBIN := $(INSTALL_SBIN-y) > > +INSTALL_PRIVBIN-y := xenpvnetboot > +INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y) > + > # Include configure output (config.h) to headers search path > CFLAGS += -I$(XEN_ROOT)/tools > > @@ -41,8 +44,10 @@ build: $(TARGETS) > install: build > $(INSTALL_DIR) $(DESTDIR)$(BINDIR) > $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) > + $(INSTALL_DIR) $(DESTDIR)$(PRIVATE_BINDIR) > $(INSTALL_PYTHON_PROG) $(INSTALL_BIN) $(DESTDIR)$(BINDIR) > $(INSTALL_PYTHON_PROG) $(INSTALL_SBIN) $(DESTDIR)$(SBINDIR) > + $(INSTALL_PYTHON_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(PRIVATE_BINDIR) > set -e; for d in $(SUBDIRS); do $(MAKE) -C $$d install-recurse; done > > .PHONY: clean > diff -r e43157a86933 -r 52f45b258ccc tools/pygrub/Makefile > --- a/tools/pygrub/Makefile Wed May 09 11:38:50 2012 +0100 > +++ b/tools/pygrub/Makefile Wed May 09 11:39:43 2012 +0100 > @@ -11,9 +11,11 @@ build: > .PHONY: install > install: all > CC="$(CC)" CFLAGS="$(CFLAGS)" $(PYTHON) setup.py install \ > - $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force > - $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(BINDIR)/pygrub > + $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \ > + --install-scripts=$(DESTDIR)/$(PRIVATE_BINDIR) --force > + $(INSTALL_PYTHON_PROG) src/pygrub $(DESTDIR)/$(PRIVATE_BINDIR)/pygrub > $(INSTALL_DIR) $(DESTDIR)/var/run/xend/boot > + ln -sf $(PRIVATE_BINDIR)/pygrub $(DESTDIR)/$(BINDIR) > > .PHONY: clean > clean: > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:42:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:42:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79i-000668-RS; Wed, 09 May 2012 13:42:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79h-00065s-MP for xen-devel@lists.xen.org; Wed, 09 May 2012 13:42:13 +0000 Received: from [193.109.254.147:14367] by server-4.bemta-14.messagelabs.com id 67/56-11570-4347AAF4; Wed, 09 May 2012 13:42:12 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336570932!1537263!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19973 invoked from network); 9 May 2012 13:42:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:42:12 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379669" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:42:12 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:42:12 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS79f-0007xO-RI; Wed, 09 May 2012 13:42:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS79f-0003gT-Q2; Wed, 09 May 2012 14:42:11 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.29747.791679.439889@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:42:11 +0100 To: "rshriram@cs.ubc.ca" In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Anthony Perard , xen-devel , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Shriram Rajagopalan writes ("Re: Upstream Qemu Status (Was: Re: [Xen-devel] 4.2 TODO / Release Status)"): > On Tue, May 8, 2012 at 9:59 AM, Ian Campbell > wrote: > > The libxl save/restore patches haven't been applied yet. > > Ian J -- have you dropped these or are you waiting for something? I have an enormous patch backlog. Apologies to everyone. We have been dealing with an unrelated crisis here. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:42:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:42:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79i-000668-RS; Wed, 09 May 2012 13:42:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS79h-00065s-MP for xen-devel@lists.xen.org; Wed, 09 May 2012 13:42:13 +0000 Received: from [193.109.254.147:14367] by server-4.bemta-14.messagelabs.com id 67/56-11570-4347AAF4; Wed, 09 May 2012 13:42:12 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336570932!1537263!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19973 invoked from network); 9 May 2012 13:42:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:42:12 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379669" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:42:12 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:42:12 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS79f-0007xO-RI; Wed, 09 May 2012 13:42:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS79f-0003gT-Q2; Wed, 09 May 2012 14:42:11 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.29747.791679.439889@mariner.uk.xensource.com> Date: Wed, 9 May 2012 14:42:11 +0100 To: "rshriram@cs.ubc.ca" In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Anthony Perard , xen-devel , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Shriram Rajagopalan writes ("Re: Upstream Qemu Status (Was: Re: [Xen-devel] 4.2 TODO / Release Status)"): > On Tue, May 8, 2012 at 9:59 AM, Ian Campbell > wrote: > > The libxl save/restore patches haven't been applied yet. > > Ian J -- have you dropped these or are you waiting for something? I have an enormous patch backlog. Apologies to everyone. We have been dealing with an unrelated crisis here. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:43:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7AZ-0006Do-AR; Wed, 09 May 2012 13:43:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7AX-0006DZ-R7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:43:05 +0000 Received: from [85.158.139.83:30875] by server-11.bemta-5.messagelabs.com id E7/A5-12959-9647AAF4; Wed, 09 May 2012 13:43:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336570984!20258769!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31368 invoked from network); 9 May 2012 13:43:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:43:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379730" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:43:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:43:03 +0100 Message-ID: <1336570982.25514.120.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:43:02 +0100 In-Reply-To: <794778a6e9fa761bd388.1336560666@kodo2> References: <794778a6e9fa761bd388.1336560666@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > Signed-off-by: George Dunlap > > diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c > --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 > +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 > @@ -15,6 +15,7 @@ > #include "libxl_osdeps.h" /* must come before any other headers */ > > #include > +#include > > #include "libxl_internal.h" > > @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) Why strncmp and not just strcmp? And why 20? AFAIK strlen("/usr/bin/pygrub") == 15 or 16 or so... Ian. > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "WARNING: bootloader='/usr/bin/pygrub' " \ > + "is deprecated; use bootloader='pygrub' instead"); > + > bootloader = libxl__abs_path(gc, info->u.pv.bootloader, > libxl__libexec_path()); > if ( bootloader == NULL ) { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:43:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7AZ-0006Do-AR; Wed, 09 May 2012 13:43:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7AX-0006DZ-R7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 13:43:05 +0000 Received: from [85.158.139.83:30875] by server-11.bemta-5.messagelabs.com id E7/A5-12959-9647AAF4; Wed, 09 May 2012 13:43:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336570984!20258769!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31368 invoked from network); 9 May 2012 13:43:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:43:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12379730" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 13:43:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 14:43:03 +0100 Message-ID: <1336570982.25514.120.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Wed, 9 May 2012 14:43:02 +0100 In-Reply-To: <794778a6e9fa761bd388.1336560666@kodo2> References: <794778a6e9fa761bd388.1336560666@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > Signed-off-by: George Dunlap > > diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c > --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 > +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 > @@ -15,6 +15,7 @@ > #include "libxl_osdeps.h" /* must come before any other headers */ > > #include > +#include > > #include "libxl_internal.h" > > @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, > goto out_close; > } > > + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) Why strncmp and not just strcmp? And why 20? AFAIK strlen("/usr/bin/pygrub") == 15 or 16 or so... Ian. > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "WARNING: bootloader='/usr/bin/pygrub' " \ > + "is deprecated; use bootloader='pygrub' instead"); > + > bootloader = libxl__abs_path(gc, info->u.pv.bootloader, > libxl__libexec_path()); > if ( bootloader == NULL ) { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:50:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS7HM-0006bv-8O; Wed, 09 May 2012 13:50:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7HK-0006bq-RM for xen-devel@lists.xen.org; Wed, 09 May 2012 13:50:07 +0000 Received: from [193.109.254.147:27785] by server-9.bemta-14.messagelabs.com id 43/C4-05787-E067AAF4; Wed, 09 May 2012 13:50:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336571403!8420196!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25208 invoked from network); 9 May 2012 13:50:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:50:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194042417" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:46:50 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 09:46:50 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS7EA-0000O5-4V; Wed, 09 May 2012 14:46:50 +0100 Message-ID: <4FAA7504.5030103@eu.citrix.com> Date: Wed, 9 May 2012 14:45:40 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell , "xen-devel@lists.xen.org" References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> In-Reply-To: <1336564773.25514.101.camel@zakaz.uk.xensource.com> Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 12:59, Ian Campbell wrote: > Right, however it is strictly speaking a new feature which is not > mentioned on the TODO list and has not previously been posted (AFAIK, > please correct me if not) and we are currently supposed to be in feature > freeze (and have been for several weeks, if not a month). > > IIRC this functionality was mooted when the pci permissive patch was > being done as something which would be a 4.3 feature. > We need to decide if we want to make an exception for this new feature > or not. Although I'm sure this feature is very nice and handy, we've > lived without it for years and people seem to be able to use the > existing scheme. My recollection was that I did "moot" the functionailty basically a day or two after the official feature freeze; my impression from those discussions was that we wouldn't add the feature to the list, but that it was reasonable to ask for an exception at such time as I actually had the patches. (Quite possible that my understanding is wrong there.) Unfortunately due to other priorities, I didn't manage to actually start working on them until the end of last week. Maybe part of the issue is how they're being presented. My original plan was to add options to libxl_pci_{add,remove} do the rebinding, which would have looked less like a new feature and more like an improvement. This version actually introduces new functions, so it looks much more like a "new feature", even though the functionality is the same, and arguably having a separate step is less of a risk of someone tripping over something. Of course everyone thinks their pet feature is incredibly important. :-) But we are planning on making a public push on some of the security features of Xen this summer, which will hopefully mean a lot of people investigate the idea of using pci pass-through functionality for network driver domains. The problem with saying "people seem to be able to use the existing scheme" is that you only see those who have gone through it and succeeded; you don't see how many took at look at the instructions and said, "That sounds too complicated/dangerous for me." It would be a shame if we tooted Xen's horn about security, got an extra several thousand people to look into it, and then had half of them go away because of something simple like this. I think that's my main concern. We could of course make the HOWTOs easier to follow even without including this functionality; including Anthony's (very useful) rebinding script would certainly be a lot better than having everyone manually doing the sysfs stuff. But not nearly as good as having the commands in-tree. If we decide not to take the new functions, can I propose that we at least take the one that renames "pci-device-list-assignable", so we won't have to rename it / deal with compatibility issues when these are implemented for 4.3? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:50:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13: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 ) id 1SS7HM-0006bv-8O; Wed, 09 May 2012 13:50:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7HK-0006bq-RM for xen-devel@lists.xen.org; Wed, 09 May 2012 13:50:07 +0000 Received: from [193.109.254.147:27785] by server-9.bemta-14.messagelabs.com id 43/C4-05787-E067AAF4; Wed, 09 May 2012 13:50:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336571403!8420196!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25208 invoked from network); 9 May 2012 13:50:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 13:50:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194042417" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 09:46:50 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 09:46:50 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS7EA-0000O5-4V; Wed, 09 May 2012 14:46:50 +0100 Message-ID: <4FAA7504.5030103@eu.citrix.com> Date: Wed, 9 May 2012 14:45:40 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell , "xen-devel@lists.xen.org" References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> In-Reply-To: <1336564773.25514.101.camel@zakaz.uk.xensource.com> Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 12:59, Ian Campbell wrote: > Right, however it is strictly speaking a new feature which is not > mentioned on the TODO list and has not previously been posted (AFAIK, > please correct me if not) and we are currently supposed to be in feature > freeze (and have been for several weeks, if not a month). > > IIRC this functionality was mooted when the pci permissive patch was > being done as something which would be a 4.3 feature. > We need to decide if we want to make an exception for this new feature > or not. Although I'm sure this feature is very nice and handy, we've > lived without it for years and people seem to be able to use the > existing scheme. My recollection was that I did "moot" the functionailty basically a day or two after the official feature freeze; my impression from those discussions was that we wouldn't add the feature to the list, but that it was reasonable to ask for an exception at such time as I actually had the patches. (Quite possible that my understanding is wrong there.) Unfortunately due to other priorities, I didn't manage to actually start working on them until the end of last week. Maybe part of the issue is how they're being presented. My original plan was to add options to libxl_pci_{add,remove} do the rebinding, which would have looked less like a new feature and more like an improvement. This version actually introduces new functions, so it looks much more like a "new feature", even though the functionality is the same, and arguably having a separate step is less of a risk of someone tripping over something. Of course everyone thinks their pet feature is incredibly important. :-) But we are planning on making a public push on some of the security features of Xen this summer, which will hopefully mean a lot of people investigate the idea of using pci pass-through functionality for network driver domains. The problem with saying "people seem to be able to use the existing scheme" is that you only see those who have gone through it and succeeded; you don't see how many took at look at the instructions and said, "That sounds too complicated/dangerous for me." It would be a shame if we tooted Xen's horn about security, got an extra several thousand people to look into it, and then had half of them go away because of something simple like this. I think that's my main concern. We could of course make the HOWTOs easier to follow even without including this functionality; including Anthony's (very useful) rebinding script would certainly be a lot better than having everyone manually doing the sysfs stuff. But not nearly as good as having the commands in-tree. If we decide not to take the new functions, can I propose that we at least take the one that renames "pci-device-list-assignable", so we won't have to rename it / deal with compatibility issues when these are implemented for 4.3? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:52:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:52:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7J5-0006ff-OQ; Wed, 09 May 2012 13:51:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7J3-0006fX-J7 for xen-devel@lists.xen.org; Wed, 09 May 2012 13:51:53 +0000 Received: from [85.158.139.83:53267] by server-1.bemta-5.messagelabs.com id 5C/47-28458-8767AAF4; Wed, 09 May 2012 13:51:52 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-4.tower-182.messagelabs.com!1336571511!24773081!1 X-Originating-IP: [63.239.67.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3249 invoked from network); 9 May 2012 13:51:51 -0000 Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10) by server-4.tower-182.messagelabs.com with SMTP; 9 May 2012 13:51:51 -0000 X-TM-IMSS-Message-ID: <56e20400000c95ac@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 56e20400000c95ac ; Wed, 9 May 2012 09:53:36 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49Dpfnb006365; Wed, 9 May 2012 09:51:41 -0400 Message-ID: <4FAA7627.4010003@tycho.nsa.gov> Date: Wed, 09 May 2012 09:50:31 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28433.983986.883494@mariner.uk.xensource.com> In-Reply-To: <20394.28433.983986.883494@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 09:20 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the >> expression CTX->osevent_in_hook-- (usually 1) instead of the value of >> the function call it made. Change the macro to a statement including the >> return variable to fix this. > > Also, does this mean that you're using this in anger, or did you just > happen to spot it while perusing the code ? > > Thanks, > Ian. > I am using this functionality in a locally-patched libvirt where I have replaced libxl 4.1 support with 4.2. I don't think the changes I made are suitable for upstream as I assume libvirt will want to continue to support libxl 4.1 in addition to 4.2 (and my patch discards the 4.1 support). -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 13:52:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 13:52:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7J5-0006ff-OQ; Wed, 09 May 2012 13:51:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7J3-0006fX-J7 for xen-devel@lists.xen.org; Wed, 09 May 2012 13:51:53 +0000 Received: from [85.158.139.83:53267] by server-1.bemta-5.messagelabs.com id 5C/47-28458-8767AAF4; Wed, 09 May 2012 13:51:52 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-4.tower-182.messagelabs.com!1336571511!24773081!1 X-Originating-IP: [63.239.67.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3249 invoked from network); 9 May 2012 13:51:51 -0000 Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10) by server-4.tower-182.messagelabs.com with SMTP; 9 May 2012 13:51:51 -0000 X-TM-IMSS-Message-ID: <56e20400000c95ac@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 56e20400000c95ac ; Wed, 9 May 2012 09:53:36 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49Dpfnb006365; Wed, 9 May 2012 09:51:41 -0400 Message-ID: <4FAA7627.4010003@tycho.nsa.gov> Date: Wed, 09 May 2012 09:50:31 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28433.983986.883494@mariner.uk.xensource.com> In-Reply-To: <20394.28433.983986.883494@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 09:20 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the >> expression CTX->osevent_in_hook-- (usually 1) instead of the value of >> the function call it made. Change the macro to a statement including the >> return variable to fix this. > > Also, does this mean that you're using this in anger, or did you just > happen to spot it while perusing the code ? > > Thanks, > Ian. > I am using this functionality in a locally-patched libvirt where I have replaced libxl 4.1 support with 4.2. I don't think the changes I made are suitable for upstream as I assume libvirt will want to continue to support libxl 4.1 in addition to 4.2 (and my patch discards the 4.1 support). -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 14:07:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14: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 ) id 1SS7Xs-0007Hh-0c; Wed, 09 May 2012 14:07:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7Xq-0007HQ-1h for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:07:10 +0000 Received: from [85.158.138.51:17248] by server-8.bemta-3.messagelabs.com id 57/29-24428-D0A7AAF4; Wed, 09 May 2012 14:07:09 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-174.messagelabs.com!1336572426!26021123!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6098 invoked from network); 9 May 2012 14:07:08 -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; 9 May 2012 14:07:08 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS7Xm-0000Xf-9Z for xen-devel@lists.xensource.com; Wed, 09 May 2012 07:07:06 -0700 Date: Wed, 9 May 2012 07:07:06 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336572426286-5697470.post@n5.nabble.com> In-Reply-To: <1336504555.4350.22.camel@dagon.hellion.org.uk> References: <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> <1336504555.4350.22.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IE9uIFR1ZSwgMjAxMi0wNS0wOCBhdCAxNzoyNCAr MDEwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIEZyaSwgTWF5IDA0LCAyMDEyIGF0 IDEyOjMyOjE5UE0gKzAxMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gPiBPbiBGcmksIDIwMTIt MDUtMDQgYXQgMTI6MjEgKzAxMDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiA+ID4gT24gRnJp LCBNYXkgNCwgMjAxMiBhdCA5OjI4IEFNLCBJYW4gQ2FtcGJlbGwgJmx0O0lhbi5DYW1wYmVsbEAm Z3Q7Cj4+IHdyb3RlOgo+PiA+ID4gPiBBbnRob255IC0tIGFueSBpZGVhIHdoeSB0aGUgdmlkZW9y YW0gc2V0dGluZyBkb2Vzbid0IHdvcmsgd2l0aAo+PiB1cHN0cmVhbQo+PiA+ID4gPiBxZW11Pwo+ PiA+ID4gCj4+ID4gPiBXZWxsLCB0aGUgcGFyYW1ldGVyIGNvdWxkIGJlIHBhc3MgdG8gcWVtdSBx eGwsIGJ1dCBpdCdzIG5vdCB5ZXQuIEJ1dAo+PiA+ID4gdGhlbiwgaXQgc2VhbXMgeW91IGhhdmUg dG8gaGF2ZSB0aGlzIHZhbHVlIG9mIGF0IGxlYXN0IDMyTUIsCj4+IG90aGVyd2lzZQo+PiA+ID4g dGhlIHZhbHVlIGlzIGluY3JlYXNlIGluIHFlbXUuCj4+ID4gPiAKPj4gPiA+IEZvciBjaXJydXMv c3RkdmdhLCB0aGVyZSBpcyBubyB3YXkgdG8gcGFzcyB0aGUgcGFyYW1ldGVyIHRvIHFlbXUsIHRo ZQo+PiA+ID4gc2l6ZSBpbiBxZW11IGlzIGZpeGVkIHRvIDhNQi4KPj4gPiAKPj4gPiBPSywgc28g dGhpcyBpcyBzaW1wbHkgYSBmZWF0dXJlIHdoaWNoIHVwc3RyZWFtIHFlbXUgZG9lc24ndCBoYXZl Lgo+PiBUaGF0J3MKPj4gPiBmaW5lLgo+PiA+IAo+PiAKPj4gSXMgdGhpcyBzb21ldGhpbmcgdGhh dCBzaG91bGQgYmUgZm9yd2FyZC1wb3J0ZWQgZnJvbSBxZW11LXhlbi10cmFkaXRpb25hbAo+PiB0 byB1cHN0cmVhbSBxZW11ID8KPiAKPiBJZiB0aGVyZSBhcmUgcmVhc29ucyB3aHkgdGhpcyBzaG91 bGQgYmUgY29uZmlndXJhYmxlLCB0aGVuIEkgZ3Vlc3Mgc28uCj4gQXJlIHlvdSBnb2luZyB0byBs b29rIGludG8gdGhhdD8KPiAKPiBUaGlzIGRvZXNuJ3Qgc2VlbSBsaWtlIDQuMiBtYXRlcmlhbCB0 byBtZSB0aG91Z2guCj4gCj4+ID4gSSBndWVzcyB4bC5jZmcoNSkgbmVlZHMgdXBkYXRpbmcgdG8g bWFrZSBpdCBjbGVhciB0aGF0IHRoaXMgb3B0aW9uIG9ubHkKPj4gPiBhcHBsaWVzIHRvIHFlbXUt eGVuLXRyYWRpdGlvbmFsLgo+PiA+IAo+PiA+IFRoZSBkb2NzIGFsc28gY3VycmVudGx5IHNheSB0 aGF0IGZvciBzdGR2Z2EgdGhlIGRlZmF1bHQgaXMgOE1CIGFuZCBmb3IKPj4gPiBub3Qgc3Rkdmdh IChieSB3aGljaCBJIGd1ZXNzIGl0IG1lYW5zIENpcnJ1cykgdGhlIGRlZmF1bHQgaWYgNE1CLiBT byBJCj4+ID4gZ3Vlc3MgZXZlbiB0aGlzIGlzIGluYWNjdXJhdGUgZm9yIHFlbXUteGVuLXVwc3Ry ZWFtPwo+PiA+IAo+PiA+IENhbiBzb21lb25lIHNlbmQgYSBwYXRjaCBwbGVhc2U/Cj4+ID4gCj4+ IAo+PiBGb3IgdGhlIGRvY3VtZW50YXRpb24gcGF0Y2ggbWF5YmUgYWRkIHRoaXMgdG8gdGhlIDQu MiBzdGF0dXMgdG9kbyBsaXN0Cj4+IGFzIGEgcmVtaW5kZXIgOikgCj4gCj4gUGxlYXNlIG1ha2Ug cmVxdWVzdHMgZm9yIGFkZGl0aW9ucyB0byB0aGUgVE9ETyBsaXN0IGluIHRoZSBtb3N0IHJlY2Vu dAo+IFRPRE8gbGlzdCB0aHJlYWQsIHdpdGggYSBsaW5rIHRvIHRoZSByZWxldmFudCB0aHJlYWQu IE90aGVyd2lzZSB0aGUKPiBjaGFuY2VzIGFyZSBJIHdvbid0IHJlbWVtYmVyIHdoZW4gSSB1cGRh dGUgdGhlIGxpc3QsIHNpbmNlIEkgb25seSBsb29rCj4gYXQgcmVwbGllcyBpbiB0aGUgVE9ETyB0 aHJlYWRzLgo+IAo+IElhbi4KPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxALnhl bgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IApJIG1heSBoYXZlIGZvdW5kIHNv bWV0aGluZyB0aGF0IG1ha2VzIHRoZSBwcm9ibGVtIGNsZWFyZXIuCldpdGggUHJlY2lzZSBodm0g ZG9tVSB3aXRoIHNwaWNlIGFuZCBjaXJydXMgKGRlZmF1bHQgdmdhKSBvbiBxZW11LXhlbiBsc3Bj aQpzaG93IDMyIG1iIGJ1dCBYb3JnIG9ubHkgc2VlcyA0IG1iLgoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpsc3BjaSAtdnZ2Ci4uLgowMDowMi4w IFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXI6IENpcnJ1cyBMb2dpYyBHRCA1NDQ2IChwcm9nLWlm IDAwIFtWR0EKY29udHJvbGxlcl0pCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBEZXZpY2UgMTEw MAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLQpTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czog Q2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU QWJvcnQtCjxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCVJlZ2lvbiAw OiBNZW1vcnkgYXQgZjAwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0mbHQ7Yj4z Mk0qXQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMzAyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh YmxlKSBbc2l6ZT00S10KCUV4cGFuc2lvbiBST00gYXQgZjMwMDAwMDAgW2Rpc2FibGVkXSBbc2l6 ZT02NEtdCglLZXJuZWwgbW9kdWxlczogY2lycnVzZmIKLi4uCi0tLS0tLS0tLS0tLS0tLS0tClhv cmcuMC5sb2cKLS0tLS0tLS0tLS0tLS0tCi4uLgpbICAgICA2LjQ0M10gKC0tKSBDSVJSVVMoMCk6 IFZpZGVvUkFNOiA0MDk2IGtCeXRlCi4uLgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpJZiB5b3UgbmVlZCBtb3JlIGluZm9ybWF0aW9uIEknbGwg cG9zdCBpdC4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0 NTcxMi5uNS5uYWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2Nzkx OXA1Njk3NDcwLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hp dmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed May 09 14:07:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14: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 ) id 1SS7Xs-0007Hh-0c; Wed, 09 May 2012 14:07:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7Xq-0007HQ-1h for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:07:10 +0000 Received: from [85.158.138.51:17248] by server-8.bemta-3.messagelabs.com id 57/29-24428-D0A7AAF4; Wed, 09 May 2012 14:07:09 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-174.messagelabs.com!1336572426!26021123!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6098 invoked from network); 9 May 2012 14:07:08 -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; 9 May 2012 14:07:08 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SS7Xm-0000Xf-9Z for xen-devel@lists.xensource.com; Wed, 09 May 2012 07:07:06 -0700 Date: Wed, 9 May 2012 07:07:06 -0700 (PDT) From: Fantu To: xen-devel@lists.xensource.com Message-ID: <1336572426286-5697470.post@n5.nabble.com> In-Reply-To: <1336504555.4350.22.camel@dagon.hellion.org.uk> References: <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> <1336504555.4350.22.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org CklhbiBDYW1wYmVsbC0xMCB3cm90ZQo+IAo+IE9uIFR1ZSwgMjAxMi0wNS0wOCBhdCAxNzoyNCAr MDEwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIEZyaSwgTWF5IDA0LCAyMDEyIGF0 IDEyOjMyOjE5UE0gKzAxMDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4gPiBPbiBGcmksIDIwMTIt MDUtMDQgYXQgMTI6MjEgKzAxMDAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOgo+PiA+ID4gT24gRnJp LCBNYXkgNCwgMjAxMiBhdCA5OjI4IEFNLCBJYW4gQ2FtcGJlbGwgJmx0O0lhbi5DYW1wYmVsbEAm Z3Q7Cj4+IHdyb3RlOgo+PiA+ID4gPiBBbnRob255IC0tIGFueSBpZGVhIHdoeSB0aGUgdmlkZW9y YW0gc2V0dGluZyBkb2Vzbid0IHdvcmsgd2l0aAo+PiB1cHN0cmVhbQo+PiA+ID4gPiBxZW11Pwo+ PiA+ID4gCj4+ID4gPiBXZWxsLCB0aGUgcGFyYW1ldGVyIGNvdWxkIGJlIHBhc3MgdG8gcWVtdSBx eGwsIGJ1dCBpdCdzIG5vdCB5ZXQuIEJ1dAo+PiA+ID4gdGhlbiwgaXQgc2VhbXMgeW91IGhhdmUg dG8gaGF2ZSB0aGlzIHZhbHVlIG9mIGF0IGxlYXN0IDMyTUIsCj4+IG90aGVyd2lzZQo+PiA+ID4g dGhlIHZhbHVlIGlzIGluY3JlYXNlIGluIHFlbXUuCj4+ID4gPiAKPj4gPiA+IEZvciBjaXJydXMv c3RkdmdhLCB0aGVyZSBpcyBubyB3YXkgdG8gcGFzcyB0aGUgcGFyYW1ldGVyIHRvIHFlbXUsIHRo ZQo+PiA+ID4gc2l6ZSBpbiBxZW11IGlzIGZpeGVkIHRvIDhNQi4KPj4gPiAKPj4gPiBPSywgc28g dGhpcyBpcyBzaW1wbHkgYSBmZWF0dXJlIHdoaWNoIHVwc3RyZWFtIHFlbXUgZG9lc24ndCBoYXZl Lgo+PiBUaGF0J3MKPj4gPiBmaW5lLgo+PiA+IAo+PiAKPj4gSXMgdGhpcyBzb21ldGhpbmcgdGhh dCBzaG91bGQgYmUgZm9yd2FyZC1wb3J0ZWQgZnJvbSBxZW11LXhlbi10cmFkaXRpb25hbAo+PiB0 byB1cHN0cmVhbSBxZW11ID8KPiAKPiBJZiB0aGVyZSBhcmUgcmVhc29ucyB3aHkgdGhpcyBzaG91 bGQgYmUgY29uZmlndXJhYmxlLCB0aGVuIEkgZ3Vlc3Mgc28uCj4gQXJlIHlvdSBnb2luZyB0byBs b29rIGludG8gdGhhdD8KPiAKPiBUaGlzIGRvZXNuJ3Qgc2VlbSBsaWtlIDQuMiBtYXRlcmlhbCB0 byBtZSB0aG91Z2guCj4gCj4+ID4gSSBndWVzcyB4bC5jZmcoNSkgbmVlZHMgdXBkYXRpbmcgdG8g bWFrZSBpdCBjbGVhciB0aGF0IHRoaXMgb3B0aW9uIG9ubHkKPj4gPiBhcHBsaWVzIHRvIHFlbXUt eGVuLXRyYWRpdGlvbmFsLgo+PiA+IAo+PiA+IFRoZSBkb2NzIGFsc28gY3VycmVudGx5IHNheSB0 aGF0IGZvciBzdGR2Z2EgdGhlIGRlZmF1bHQgaXMgOE1CIGFuZCBmb3IKPj4gPiBub3Qgc3Rkdmdh IChieSB3aGljaCBJIGd1ZXNzIGl0IG1lYW5zIENpcnJ1cykgdGhlIGRlZmF1bHQgaWYgNE1CLiBT byBJCj4+ID4gZ3Vlc3MgZXZlbiB0aGlzIGlzIGluYWNjdXJhdGUgZm9yIHFlbXUteGVuLXVwc3Ry ZWFtPwo+PiA+IAo+PiA+IENhbiBzb21lb25lIHNlbmQgYSBwYXRjaCBwbGVhc2U/Cj4+ID4gCj4+ IAo+PiBGb3IgdGhlIGRvY3VtZW50YXRpb24gcGF0Y2ggbWF5YmUgYWRkIHRoaXMgdG8gdGhlIDQu MiBzdGF0dXMgdG9kbyBsaXN0Cj4+IGFzIGEgcmVtaW5kZXIgOikgCj4gCj4gUGxlYXNlIG1ha2Ug cmVxdWVzdHMgZm9yIGFkZGl0aW9ucyB0byB0aGUgVE9ETyBsaXN0IGluIHRoZSBtb3N0IHJlY2Vu dAo+IFRPRE8gbGlzdCB0aHJlYWQsIHdpdGggYSBsaW5rIHRvIHRoZSByZWxldmFudCB0aHJlYWQu IE90aGVyd2lzZSB0aGUKPiBjaGFuY2VzIGFyZSBJIHdvbid0IHJlbWVtYmVyIHdoZW4gSSB1cGRh dGUgdGhlIGxpc3QsIHNpbmNlIEkgb25seSBsb29rCj4gYXQgcmVwbGllcyBpbiB0aGUgVE9ETyB0 aHJlYWRzLgo+IAo+IElhbi4KPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxALnhl bgo+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo+IApJIG1heSBoYXZlIGZvdW5kIHNv bWV0aGluZyB0aGF0IG1ha2VzIHRoZSBwcm9ibGVtIGNsZWFyZXIuCldpdGggUHJlY2lzZSBodm0g ZG9tVSB3aXRoIHNwaWNlIGFuZCBjaXJydXMgKGRlZmF1bHQgdmdhKSBvbiBxZW11LXhlbiBsc3Bj aQpzaG93IDMyIG1iIGJ1dCBYb3JnIG9ubHkgc2VlcyA0IG1iLgoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpsc3BjaSAtdnZ2Ci4uLgowMDowMi4w IFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXI6IENpcnJ1cyBMb2dpYyBHRCA1NDQ2IChwcm9nLWlm IDAwIFtWR0EKY29udHJvbGxlcl0pCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBEZXZpY2UgMTEw MAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLQpTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czog Q2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU QWJvcnQtCjxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCVJlZ2lvbiAw OiBNZW1vcnkgYXQgZjAwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0mbHQ7Yj4z Mk0qXQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMzAyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh YmxlKSBbc2l6ZT00S10KCUV4cGFuc2lvbiBST00gYXQgZjMwMDAwMDAgW2Rpc2FibGVkXSBbc2l6 ZT02NEtdCglLZXJuZWwgbW9kdWxlczogY2lycnVzZmIKLi4uCi0tLS0tLS0tLS0tLS0tLS0tClhv cmcuMC5sb2cKLS0tLS0tLS0tLS0tLS0tCi4uLgpbICAgICA2LjQ0M10gKC0tKSBDSVJSVVMoMCk6 IFZpZGVvUkFNOiA0MDk2IGtCeXRlCi4uLgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpJZiB5b3UgbmVlZCBtb3JlIGluZm9ybWF0aW9uIEknbGwg cG9zdCBpdC4KCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4uMTA0 NTcxMi5uNS5uYWJibGUuY29tL1VuYWJsZS10by1nZXQtUVhMLXZnYS13b3JraW5nLXRwNTY2Nzkx OXA1Njk3NDcwLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hp dmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed May 09 14:13:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14:13:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7e6-0007Wr-Qw; Wed, 09 May 2012 14:13:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7e4-0007Wi-I7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:13:36 +0000 Received: from [85.158.143.35:37425] by server-3.bemta-4.messagelabs.com id 58/ED-05853-F8B7AAF4; Wed, 09 May 2012 14:13:35 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336572813!14636726!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11408 invoked from network); 9 May 2012 14:13:34 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 14:13:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194049072" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:06:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:06:41 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS7T1-0000fE-6H; Wed, 09 May 2012 15:02:11 +0100 Message-ID: <4FAA789D.4080905@eu.citrix.com> Date: Wed, 9 May 2012 15:01:01 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336570788.25514.117.camel@zakaz.uk.xensource.com> In-Reply-To: <1336570788.25514.117.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 14:39, Ian Campbell wrote: > I think since libxl uses execvp the first two are handled by path > expansion, the next two are what you are adding (so has priority over > $PATH in your patch, which I think is OK) and the last one is irrelevant > in this context (xend uses the same function for other contexts). > > However in order to not differ on the first two execvp needs to be given > the opportunity to search the path, which means that you need to check > of your newly constructed bootloader exists, and if it doesn't then try > and continue with the relative path not the absolute one. > > Also since this patch comes before the rename+symlink patch as it stands > this patch will temporarily break people who just have "pygrub" without > a path in their config. Ah, I didn't realize that xl would already search the path (via execvp). I think it should be pretty straightforward to add a check for existence, and if not fall back to letting execvp search the path. If I do that, arguably this patch would still come first in the series? Not that it matters much, really. -George > > Ian. > >> Signed-off-by: George Dunlap >> >> diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c >> --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 >> +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 >> @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> >> char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; >> char *tempdir; >> + const char *bootloader = NULL; >> >> char *dom_console_xs_path; >> char dom_console_slave_tty_path[PATH_MAX]; >> @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> goto out_close; >> } >> >> + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, >> + libxl__libexec_path()); >> + if ( bootloader == NULL ) { >> + rc = ERROR_NOMEM; >> + goto out_close; >> + } >> + >> /* >> * We need to present the bootloader's tty as a pty slave that xenconsole >> * can access. Since the bootloader itself needs a pty slave, >> @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); >> libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); >> >> - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); >> + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); >> if (pid< 0) { >> goto out_close; >> } >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 14:13:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14:13:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7e6-0007Wr-Qw; Wed, 09 May 2012 14:13:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS7e4-0007Wi-I7 for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:13:36 +0000 Received: from [85.158.143.35:37425] by server-3.bemta-4.messagelabs.com id 58/ED-05853-F8B7AAF4; Wed, 09 May 2012 14:13:35 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336572813!14636726!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTEwNzE=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11408 invoked from network); 9 May 2012 14:13:34 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 14:13:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="194049072" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:06:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:06:41 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS7T1-0000fE-6H; Wed, 09 May 2012 15:02:11 +0100 Message-ID: <4FAA789D.4080905@eu.citrix.com> Date: Wed, 9 May 2012 15:01:01 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336570788.25514.117.camel@zakaz.uk.xensource.com> In-Reply-To: <1336570788.25514.117.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 3 RESEND] libxl: Look for bootloader in libexec path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 14:39, Ian Campbell wrote: > I think since libxl uses execvp the first two are handled by path > expansion, the next two are what you are adding (so has priority over > $PATH in your patch, which I think is OK) and the last one is irrelevant > in this context (xend uses the same function for other contexts). > > However in order to not differ on the first two execvp needs to be given > the opportunity to search the path, which means that you need to check > of your newly constructed bootloader exists, and if it doesn't then try > and continue with the relative path not the absolute one. > > Also since this patch comes before the rename+symlink patch as it stands > this patch will temporarily break people who just have "pygrub" without > a path in their config. Ah, I didn't realize that xl would already search the path (via execvp). I think it should be pretty straightforward to add a check for existence, and if not fall back to letting execvp search the path. If I do that, arguably this patch would still come first in the series? Not that it matters much, really. -George > > Ian. > >> Signed-off-by: George Dunlap >> >> diff -r 8a86d841e6d4 -r e43157a86933 tools/libxl/libxl_bootloader.c >> --- a/tools/libxl/libxl_bootloader.c Tue May 08 13:36:24 2012 +0200 >> +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:38:50 2012 +0100 >> @@ -333,6 +333,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> >> char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; >> char *tempdir; >> + const char *bootloader = NULL; >> >> char *dom_console_xs_path; >> char dom_console_slave_tty_path[PATH_MAX]; >> @@ -397,6 +398,13 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> goto out_close; >> } >> >> + bootloader = libxl__abs_path(gc, info->u.pv.bootloader, >> + libxl__libexec_path()); >> + if ( bootloader == NULL ) { >> + rc = ERROR_NOMEM; >> + goto out_close; >> + } >> + >> /* >> * We need to present the bootloader's tty as a pty slave that xenconsole >> * can access. Since the bootloader itself needs a pty slave, >> @@ -417,7 +425,7 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); >> libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); >> >> - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); >> + pid = fork_exec_bootloader(&bootloader_fd, bootloader, args); >> if (pid< 0) { >> goto out_close; >> } >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 14:49:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14: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 ) id 1SS8Ci-0007os-QF; Wed, 09 May 2012 14:49:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8Ch-0007on-Gv for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:49:23 +0000 Received: from [85.158.143.35:4848] by server-3.bemta-4.messagelabs.com id 45/C7-05853-2F38AAF4; Wed, 09 May 2012 14:49:22 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336574960!15333459!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16860 invoked from network); 9 May 2012 14:49:21 -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; 9 May 2012 14:49:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25025098" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:49:19 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:49:18 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS8Cc-0001cE-F9; Wed, 09 May 2012 15:49:18 +0100 Message-ID: <4FAA83A8.8070804@eu.citrix.com> Date: Wed, 9 May 2012 15:48:08 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> In-Reply-To: <1336570982.25514.120.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 14:43, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >> Signed-off-by: George Dunlap >> >> diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c >> --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 >> +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 >> @@ -15,6 +15,7 @@ >> #include "libxl_osdeps.h" /* must come before any other headers */ >> >> #include >> +#include >> >> #include "libxl_internal.h" >> >> @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> goto out_close; >> } >> >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > Why strncmp and not just strcmp? And why 20? AFAIK > strlen("/usr/bin/pygrub") == 15 or 16 or so... ISTR in the past build processes throwing warnings that strcmp() is unsafe, and since warnings turn to errors, pre-emptively used the "safe" version instead. Let me give it a try; it should be perfectly safe for us, and will remove the issue with manually syncronizing string with its size. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 14:49:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 14: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 ) id 1SS8Ci-0007os-QF; Wed, 09 May 2012 14:49:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8Ch-0007on-Gv for xen-devel@lists.xensource.com; Wed, 09 May 2012 14:49:23 +0000 Received: from [85.158.143.35:4848] by server-3.bemta-4.messagelabs.com id 45/C7-05853-2F38AAF4; Wed, 09 May 2012 14:49:22 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336574960!15333459!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16860 invoked from network); 9 May 2012 14:49:21 -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; 9 May 2012 14:49:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330923600"; d="scan'208";a="25025098" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 10:49:19 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 10:49:18 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SS8Cc-0001cE-F9; Wed, 09 May 2012 15:49:18 +0100 Message-ID: <4FAA83A8.8070804@eu.citrix.com> Date: Wed, 9 May 2012 15:48:08 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> In-Reply-To: <1336570982.25514.120.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 14:43, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >> Signed-off-by: George Dunlap >> >> diff -r 52f45b258ccc -r 794778a6e9fa tools/libxl/libxl_bootloader.c >> --- a/tools/libxl/libxl_bootloader.c Wed May 09 11:39:43 2012 +0100 >> +++ b/tools/libxl/libxl_bootloader.c Wed May 09 11:42:19 2012 +0100 >> @@ -15,6 +15,7 @@ >> #include "libxl_osdeps.h" /* must come before any other headers */ >> >> #include >> +#include >> >> #include "libxl_internal.h" >> >> @@ -398,6 +399,11 @@ int libxl_run_bootloader(libxl_ctx *ctx, >> goto out_close; >> } >> >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > Why strncmp and not just strcmp? And why 20? AFAIK > strlen("/usr/bin/pygrub") == 15 or 16 or so... ISTR in the past build processes throwing warnings that strcmp() is unsafe, and since warnings turn to errors, pre-emptively used the "safe" version instead. Let me give it a try; it should be perfectly safe for us, and will remove the issue with manually syncronizing string with its size. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:24:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15:24:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8ja-00085b-JY; Wed, 09 May 2012 15:23:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8jY-00085W-SM for xen-devel@lists.xen.org; Wed, 09 May 2012 15:23:21 +0000 Received: from [85.158.138.51:57250] by server-9.bemta-3.messagelabs.com id 0B/B9-26691-8EB8AAF4; Wed, 09 May 2012 15:23:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336576999!17225602!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9778 invoked from network); 9 May 2012 15:23:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:23:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383443" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:23:18 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 16:23:18 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8jV-000050-Su; Wed, 09 May 2012 15:23:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8jV-0005TR-Rr; Wed, 09 May 2012 16:23:17 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.35813.845562.695653@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:23:17 +0100 To: Dario Faggioli In-Reply-To: <1336561898.2621.4.camel@Abyss> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336561898.2621.4.camel@Abyss> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("Re: [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have"): > And, as it is an actual bugfix and very very small in size, not to > forget that I'd need that for the NUMA placement series, I'm proposing > this for 4.2... Does it make sense? It seems to to me that this is indeed 4.2 material. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:24:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15:24:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8ja-00085b-JY; Wed, 09 May 2012 15:23:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8jY-00085W-SM for xen-devel@lists.xen.org; Wed, 09 May 2012 15:23:21 +0000 Received: from [85.158.138.51:57250] by server-9.bemta-3.messagelabs.com id 0B/B9-26691-8EB8AAF4; Wed, 09 May 2012 15:23:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336576999!17225602!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9778 invoked from network); 9 May 2012 15:23:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:23:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383443" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:23:18 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 16:23:18 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8jV-000050-Su; Wed, 09 May 2012 15:23:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8jV-0005TR-Rr; Wed, 09 May 2012 16:23:17 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.35813.845562.695653@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:23:17 +0100 To: Dario Faggioli In-Reply-To: <1336561898.2621.4.camel@Abyss> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336561898.2621.4.camel@Abyss> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("Re: [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have"): > And, as it is an actual bugfix and very very small in size, not to > forget that I'd need that for the NUMA placement series, I'm proposing > this for 4.2... Does it make sense? It seems to to me that this is indeed 4.2 material. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:33:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15:33:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8sr-0008HK-LV; Wed, 09 May 2012 15:32:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8sp-0008Fi-Uz for xen-devel@lists.xen.org; Wed, 09 May 2012 15:32:56 +0000 Received: from [85.158.138.51:28731] by server-6.bemta-3.messagelabs.com id EF/27-05145-42E8AAF4; Wed, 09 May 2012 15:32:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336577571!18190903!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3669 invoked from network); 9 May 2012 15:32:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:32:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383644" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:32:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 16:32:51 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8sl-00007w-2w; Wed, 09 May 2012 15:32:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8sl-0005eU-23; Wed, 09 May 2012 16:32:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.36387.49258.141494@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:32:51 +0100 To: Daniel De Graaf In-Reply-To: <4FAA7354.5070802@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > Agreed, using the statement expression syntax seems cleaner here. ... > +#define OSEVENT_HOOK(hookname,...) ({ \ > + int rc; \ > + if (CTX->osevent_hooks) { \ > + CTX->osevent_in_hook++; \ > + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ > + CTX->osevent_in_hook--; \ > + } else { \ > + rc = 0; \ > + } \ > + rc; \ > +}) Thanks. However, you need to use a different variable name to "rc". "rc" might theoretically be present int __VA_ARGS__ in which case this will go wrong. Also if we ever enable -Wshadow, this construction will cause a warning. I suggest int osevent_hook_rc; You could preserve the unification of the two macros by having #define OSEVENT_HOOK(hookname,...) \ OSEVENT_HOOK_INTERN(osevent_hook_rc =, /*empty*/, hookname, __VA_ARGS__) #define OSEVENT_HOOK_VOID(hookname,...) \ OSEVENT_HOOK_INTERN(/*empty*/, (void), hookname, __VA_ARGS__) or some such. I don't know whether you like that idea; if you do please go ahead and do it. If not then I'm happy to take the patch which duplicates the macro. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:33:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15:33:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8sr-0008HK-LV; Wed, 09 May 2012 15:32:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8sp-0008Fi-Uz for xen-devel@lists.xen.org; Wed, 09 May 2012 15:32:56 +0000 Received: from [85.158.138.51:28731] by server-6.bemta-3.messagelabs.com id EF/27-05145-42E8AAF4; Wed, 09 May 2012 15:32:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336577571!18190903!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3669 invoked from network); 9 May 2012 15:32:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:32:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383644" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:32:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 16:32:51 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8sl-00007w-2w; Wed, 09 May 2012 15:32:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8sl-0005eU-23; Wed, 09 May 2012 16:32:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.36387.49258.141494@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:32:51 +0100 To: Daniel De Graaf In-Reply-To: <4FAA7354.5070802@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("[PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > Agreed, using the statement expression syntax seems cleaner here. ... > +#define OSEVENT_HOOK(hookname,...) ({ \ > + int rc; \ > + if (CTX->osevent_hooks) { \ > + CTX->osevent_in_hook++; \ > + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ > + CTX->osevent_in_hook--; \ > + } else { \ > + rc = 0; \ > + } \ > + rc; \ > +}) Thanks. However, you need to use a different variable name to "rc". "rc" might theoretically be present int __VA_ARGS__ in which case this will go wrong. Also if we ever enable -Wshadow, this construction will cause a warning. I suggest int osevent_hook_rc; You could preserve the unification of the two macros by having #define OSEVENT_HOOK(hookname,...) \ OSEVENT_HOOK_INTERN(osevent_hook_rc =, /*empty*/, hookname, __VA_ARGS__) #define OSEVENT_HOOK_VOID(hookname,...) \ OSEVENT_HOOK_INTERN(/*empty*/, (void), hookname, __VA_ARGS__) or some such. I don't know whether you like that idea; if you do please go ahead and do it. If not then I'm happy to take the patch which duplicates the macro. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:34:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15: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 ) id 1SS8uN-0008Kq-4l; Wed, 09 May 2012 15:34:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8uM-0008Ki-GL for xen-devel@lists.xen.org; Wed, 09 May 2012 15:34:30 +0000 Received: from [85.158.143.35:40909] by server-2.bemta-4.messagelabs.com id F0/F6-17550-58E8AAF4; Wed, 09 May 2012 15:34:29 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336577667!10260330!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1394 invoked from network); 9 May 2012 15:34:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:34:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383673" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:33: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; Wed, 9 May 2012 16:33:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8tg-00008T-QF; Wed, 09 May 2012 15:33:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8tg-0005fh-PA; Wed, 09 May 2012 16:33:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.36444.760368.974206@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:33:48 +0100 To: Daniel De Graaf In-Reply-To: <4FAA7627.4010003@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28433.983986.883494@mariner.uk.xensource.com> <4FAA7627.4010003@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("Re: [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > I am using this functionality in a locally-patched libvirt where I have > replaced libxl 4.1 support with 4.2. I don't think the changes I made are > suitable for upstream as I assume libvirt will want to continue to support > libxl 4.1 in addition to 4.2 (and my patch discards the 4.1 support). Right. But we might like to see them anyway; they might provide a basis for a more-compatibility-respecting 4.2 port. Thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 15:34:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 15: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 ) id 1SS8uN-0008Kq-4l; Wed, 09 May 2012 15:34:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS8uM-0008Ki-GL for xen-devel@lists.xen.org; Wed, 09 May 2012 15:34:30 +0000 Received: from [85.158.143.35:40909] by server-2.bemta-4.messagelabs.com id F0/F6-17550-58E8AAF4; Wed, 09 May 2012 15:34:29 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336577667!10260330!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1394 invoked from network); 9 May 2012 15:34:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 15:34:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12383673" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:33: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; Wed, 9 May 2012 16:33:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS8tg-00008T-QF; Wed, 09 May 2012 15:33:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SS8tg-0005fh-PA; Wed, 09 May 2012 16:33:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20394.36444.760368.974206@mariner.uk.xensource.com> Date: Wed, 9 May 2012 16:33:48 +0100 To: Daniel De Graaf In-Reply-To: <4FAA7627.4010003@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28433.983986.883494@mariner.uk.xensource.com> <4FAA7627.4010003@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("Re: [PATCH] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > I am using this functionality in a locally-patched libvirt where I have > replaced libxl 4.1 support with 4.2. I don't think the changes I made are > suitable for upstream as I assume libvirt will want to continue to support > libxl 4.1 in addition to 4.2 (and my patch discards the 4.1 support). Right. But we might like to see them anyway; they might provide a basis for a more-compatibility-respecting 4.2 port. Thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 16:07:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9Po-0000tc-EY; Wed, 09 May 2012 16:07:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9Pn-0000tW-0O for xen-devel@lists.xensource.com; Wed, 09 May 2012 16:06:59 +0000 Received: from [85.158.143.99:32117] by server-1.bemta-4.messagelabs.com id 65/52-20925-2269AAF4; Wed, 09 May 2012 16:06:58 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336579617!17448181!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1179 invoked from network); 9 May 2012 16:06:57 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 16:06:57 -0000 Received: by wibhj13 with SMTP id hj13so471799wib.6 for ; Wed, 09 May 2012 09:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yvI4zc0tHXFtB3bfbgf4L51O9cxNj8E8NPZwPi5IKSE=; b=yfxCzJlVy5lyAhLGGsch6aqd4ZHpL89cr6IXD5fIM9DeChniTuZDgGmjFTazpTRaGI 5RCUONcW41yMBDy053nIQnLG372efgTcwkFfUzbp8BLWP+7d40O1h2m72dvy8fZZJzhv iPzll2elN8Evk8N4X5wg0fl1nWlNGw1TAjXlWUb8IofLeP/i0sOfArysQ52YRBfTTfGT gyr/MmjX4MhwhDE2nwBi9iWWqAz/AUXByiXJgcCZynGnVJcz1wbdYQDfBP3xla+2WqGP JjR0cL7XJHRFz7sIf03jVpNWlx9JvXInCFsSWJMcI8bBh0LhJjET3FyFjPABvunncKcp T7dw== Received: by 10.50.149.134 with SMTP id ua6mr1855645igb.11.1336579291706; Wed, 09 May 2012 09:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Wed, 9 May 2012 09:01:01 -0700 (PDT) In-Reply-To: <1336572426286-5697470.post@n5.nabble.com> References: <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> <1336504555.4350.22.camel@dagon.hellion.org.uk> <1336572426286-5697470.post@n5.nabble.com> From: Anthony PERARD Date: Wed, 9 May 2012 17:01:01 +0100 Message-ID: To: Fantu Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PiBJIG1heSBoYXZlIGZvdW5kIHNvbWV0aGluZyB0aGF0IG1ha2VzIHRoZSBwcm9ibGVtIGNsZWFy ZXIuCj4gV2l0aCBQcmVjaXNlIGh2bSBkb21VIHdpdGggc3BpY2UgYW5kIGNpcnJ1cyAoZGVmYXVs dCB2Z2EpIG9uIHFlbXUteGVuIGxzcGNpCj4gc2hvdyAzMiBtYiBidXQgWG9yZyBvbmx5IHNlZXMg NCBtYi4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KPiBsc3BjaSAtdnZ2Cj4gLi4uCj4gMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBjb250cm9s bGVyOiBDaXJydXMgTG9naWMgR0QgNTQ0NiAocHJvZy1pZiAwMCBbVkdBCj4gY29udHJvbGxlcl0p Cj4gwqAgwqAgwqAgwqBTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBEZXZpY2UgMTEwMAo+IMKgIMKg IMKgIMKgQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW R0FTbm9vcC0gUGFyRXJyLQo+IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQo+IMKg IMKgIMKgIMKgU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0KPiA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCj4g wqAgwqAgwqAgwqBMYXRlbmN5OiAwCj4gwqAgwqAgwqAgwqBSZWdpb24gMDogTWVtb3J5IGF0IGYw MDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9Jmx0O2I+MzJNKl0KPiDCoCDCoCDC oCDCoFJlZ2lvbiAxOiBNZW1vcnkgYXQgZjMwMjAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs ZSkgW3NpemU9NEtdCj4gwqAgwqAgwqAgwqBFeHBhbnNpb24gUk9NIGF0IGYzMDAwMDAwIFtkaXNh YmxlZF0gW3NpemU9NjRLXQo+IMKgIMKgIMKgIMKgS2VybmVsIG1vZHVsZXM6IGNpcnJ1c2ZiCj4g Li4uCj4gLS0tLS0tLS0tLS0tLS0tLS0KPiBYb3JnLjAubG9nCj4gLS0tLS0tLS0tLS0tLS0tCj4g Li4uCj4gWyDCoCDCoCA2LjQ0M10gKC0tKSBDSVJSVVMoMCk6IFZpZGVvUkFNOiA0MDk2IGtCeXRl Cj4gLi4uCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+Cj4gSWYgeW91IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiBJJ2xsIHBvc3QgaXQuCgpUaGlz IGlzIHByb2JhYmx5IG5vdCByZWxhdGVkLgoKSSB0cnkgdG8gcnVuIHF4bCwgYW5kIGZvdW5kIHRo ZSBzYW1lIGlzc3VlIGFzIHlvdSwgWG9yZy1zZXJ2ZXIKc2VnZmF1bHQuIEJ1dCBJIHNlZSB0aGF0 IFhlbiBnaXZlIGFuIGVycm9yIG1lc3NhZ2U6CihYRU4pIGVtdWxhdGUuYzo5NzpkMjQgYmFkIG1t aW8gc2l6ZSAxNgooWEVOKSBpby5jOjE5OTpkMjQgTU1JTyBlbXVsYXRpb24gZmFpbGVkIEAgMDAz Mzo3ZmY1ZGQ4ZDc5Mzg6IGYzIDBmIDZmCjE5IGYzIDBmIDZmIDUxIDEwIGYzCgpUaGF0IHByb2Jh Ymx5IHdoeSBxeGwgZG9lcyBub3Qgd29yayB3aXRoIFhlbi4KCi0tIApBbnRob255IFBFUkFSRAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Wed May 09 16:07:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9Po-0000tc-EY; Wed, 09 May 2012 16:07:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9Pn-0000tW-0O for xen-devel@lists.xensource.com; Wed, 09 May 2012 16:06:59 +0000 Received: from [85.158.143.99:32117] by server-1.bemta-4.messagelabs.com id 65/52-20925-2269AAF4; Wed, 09 May 2012 16:06:58 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336579617!17448181!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1179 invoked from network); 9 May 2012 16:06:57 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 16:06:57 -0000 Received: by wibhj13 with SMTP id hj13so471799wib.6 for ; Wed, 09 May 2012 09:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yvI4zc0tHXFtB3bfbgf4L51O9cxNj8E8NPZwPi5IKSE=; b=yfxCzJlVy5lyAhLGGsch6aqd4ZHpL89cr6IXD5fIM9DeChniTuZDgGmjFTazpTRaGI 5RCUONcW41yMBDy053nIQnLG372efgTcwkFfUzbp8BLWP+7d40O1h2m72dvy8fZZJzhv iPzll2elN8Evk8N4X5wg0fl1nWlNGw1TAjXlWUb8IofLeP/i0sOfArysQ52YRBfTTfGT gyr/MmjX4MhwhDE2nwBi9iWWqAz/AUXByiXJgcCZynGnVJcz1wbdYQDfBP3xla+2WqGP JjR0cL7XJHRFz7sIf03jVpNWlx9JvXInCFsSWJMcI8bBh0LhJjET3FyFjPABvunncKcp T7dw== Received: by 10.50.149.134 with SMTP id ua6mr1855645igb.11.1336579291706; Wed, 09 May 2012 09:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Wed, 9 May 2012 09:01:01 -0700 (PDT) In-Reply-To: <1336572426286-5697470.post@n5.nabble.com> References: <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336131139.2361.60.camel@zakaz.uk.xensource.com> <20120508162426.GD2058@reaktio.net> <1336504555.4350.22.camel@dagon.hellion.org.uk> <1336572426286-5697470.post@n5.nabble.com> From: Anthony PERARD Date: Wed, 9 May 2012 17:01:01 +0100 Message-ID: To: Fantu Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PiBJIG1heSBoYXZlIGZvdW5kIHNvbWV0aGluZyB0aGF0IG1ha2VzIHRoZSBwcm9ibGVtIGNsZWFy ZXIuCj4gV2l0aCBQcmVjaXNlIGh2bSBkb21VIHdpdGggc3BpY2UgYW5kIGNpcnJ1cyAoZGVmYXVs dCB2Z2EpIG9uIHFlbXUteGVuIGxzcGNpCj4gc2hvdyAzMiBtYiBidXQgWG9yZyBvbmx5IHNlZXMg NCBtYi4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KPiBsc3BjaSAtdnZ2Cj4gLi4uCj4gMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBjb250cm9s bGVyOiBDaXJydXMgTG9naWMgR0QgNTQ0NiAocHJvZy1pZiAwMCBbVkdBCj4gY29udHJvbGxlcl0p Cj4gwqAgwqAgwqAgwqBTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBEZXZpY2UgMTEwMAo+IMKgIMKg IMKgIMKgQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW R0FTbm9vcC0gUGFyRXJyLQo+IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQo+IMKg IMKgIMKgIMKgU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0KPiA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCj4g wqAgwqAgwqAgwqBMYXRlbmN5OiAwCj4gwqAgwqAgwqAgwqBSZWdpb24gMDogTWVtb3J5IGF0IGYw MDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9Jmx0O2I+MzJNKl0KPiDCoCDCoCDC oCDCoFJlZ2lvbiAxOiBNZW1vcnkgYXQgZjMwMjAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs ZSkgW3NpemU9NEtdCj4gwqAgwqAgwqAgwqBFeHBhbnNpb24gUk9NIGF0IGYzMDAwMDAwIFtkaXNh YmxlZF0gW3NpemU9NjRLXQo+IMKgIMKgIMKgIMKgS2VybmVsIG1vZHVsZXM6IGNpcnJ1c2ZiCj4g Li4uCj4gLS0tLS0tLS0tLS0tLS0tLS0KPiBYb3JnLjAubG9nCj4gLS0tLS0tLS0tLS0tLS0tCj4g Li4uCj4gWyDCoCDCoCA2LjQ0M10gKC0tKSBDSVJSVVMoMCk6IFZpZGVvUkFNOiA0MDk2IGtCeXRl Cj4gLi4uCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+Cj4gSWYgeW91IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiBJJ2xsIHBvc3QgaXQuCgpUaGlz IGlzIHByb2JhYmx5IG5vdCByZWxhdGVkLgoKSSB0cnkgdG8gcnVuIHF4bCwgYW5kIGZvdW5kIHRo ZSBzYW1lIGlzc3VlIGFzIHlvdSwgWG9yZy1zZXJ2ZXIKc2VnZmF1bHQuIEJ1dCBJIHNlZSB0aGF0 IFhlbiBnaXZlIGFuIGVycm9yIG1lc3NhZ2U6CihYRU4pIGVtdWxhdGUuYzo5NzpkMjQgYmFkIG1t aW8gc2l6ZSAxNgooWEVOKSBpby5jOjE5OTpkMjQgTU1JTyBlbXVsYXRpb24gZmFpbGVkIEAgMDAz Mzo3ZmY1ZGQ4ZDc5Mzg6IGYzIDBmIDZmCjE5IGYzIDBmIDZmIDUxIDEwIGYzCgpUaGF0IHByb2Jh Ymx5IHdoeSBxeGwgZG9lcyBub3Qgd29yayB3aXRoIFhlbi4KCi0tIApBbnRob255IFBFUkFSRAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Wed May 09 16:37:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9sP-0001Am-5I; Wed, 09 May 2012 16:36:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9sO-0001Ah-4s for xen-devel@lists.xensource.com; Wed, 09 May 2012 16:36:32 +0000 Received: from [85.158.138.51:29180] by server-5.bemta-3.messagelabs.com id F3/59-17113-F0D9AAF4; Wed, 09 May 2012 16:36:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336581390!17239862!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3438 invoked from network); 9 May 2012 16:36: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; 9 May 2012 16:36:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12385533" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 16: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; Wed, 9 May 2012 17:36:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS9sL-0000Wy-Eu; Wed, 09 May 2012 16:36:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS9sL-0003dT-Al; Wed, 09 May 2012 17:36:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 9 May 2012 17:36:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12825: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12825 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12825/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 9 guest-start fail pass in 12822 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12822 pass in 12825 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-qemuu-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 version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=513ca342fd86 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 513ca342fd86 + branch=xen-4.1-testing + revision=513ca342fd86 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 513ca342fd86 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 3 changesets with 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 16:37:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9sP-0001Am-5I; Wed, 09 May 2012 16:36:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9sO-0001Ah-4s for xen-devel@lists.xensource.com; Wed, 09 May 2012 16:36:32 +0000 Received: from [85.158.138.51:29180] by server-5.bemta-3.messagelabs.com id F3/59-17113-F0D9AAF4; Wed, 09 May 2012 16:36:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336581390!17239862!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3438 invoked from network); 9 May 2012 16:36: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; 9 May 2012 16:36:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="12385533" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 16: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; Wed, 9 May 2012 17:36:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SS9sL-0000Wy-Eu; Wed, 09 May 2012 16:36:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SS9sL-0003dT-Al; Wed, 09 May 2012 17:36:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 9 May 2012 17:36:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 12825: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12825 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12825/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 9 guest-start fail pass in 12822 test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail in 12822 pass in 12825 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 12785 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-i386-i386-xl-qemuu-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 version targeted for testing: xen 513ca342fd86 baseline version: xen a21938b58fc4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=513ca342fd86 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 513ca342fd86 + branch=xen-4.1-testing + revision=513ca342fd86 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r 513ca342fd86 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 3 changesets with 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 16:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9zj-0001Nb-2B; Wed, 09 May 2012 16:44:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9zh-0001NU-V5 for xen-devel@lists.xen.org; Wed, 09 May 2012 16:44:06 +0000 Received: from [85.158.139.83:8792] by server-7.bemta-5.messagelabs.com id 1D/D6-16195-5DE9AAF4; Wed, 09 May 2012 16:44:05 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-2.tower-182.messagelabs.com!1336581843!27508099!1 X-Originating-IP: [63.239.67.10] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13383 invoked from network); 9 May 2012 16:44:04 -0000 Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10) by server-2.tower-182.messagelabs.com with SMTP; 9 May 2012 16:44:04 -0000 X-TM-IMSS-Message-ID: <577faf9d000cd295@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 577faf9d000cd295 ; Wed, 9 May 2012 12:45:49 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49GhtIq016292; Wed, 9 May 2012 12:43:55 -0400 Message-ID: <4FAA9E85.9010007@tycho.nsa.gov> Date: Wed, 09 May 2012 12:42:45 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> <20394.36387.49258.141494@mariner.uk.xensource.com> In-Reply-To: <20394.36387.49258.141494@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 11:32 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> Agreed, using the statement expression syntax seems cleaner here. > ... >> +#define OSEVENT_HOOK(hookname,...) ({ \ >> + int rc; \ >> + if (CTX->osevent_hooks) { \ >> + CTX->osevent_in_hook++; \ >> + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ >> + CTX->osevent_in_hook--; \ >> + } else { \ >> + rc = 0; \ >> + } \ >> + rc; \ >> +}) > > Thanks. However, you need to use a different variable name to "rc". > "rc" might theoretically be present int __VA_ARGS__ in which case this > will go wrong. Also if we ever enable -Wshadow, this construction > will cause a warning. I suggest int osevent_hook_rc; > > You could preserve the unification of the two macros by having > > #define OSEVENT_HOOK(hookname,...) \ > OSEVENT_HOOK_INTERN(osevent_hook_rc =, /*empty*/, hookname, __VA_ARGS__) > > #define OSEVENT_HOOK_VOID(hookname,...) \ > OSEVENT_HOOK_INTERN(/*empty*/, (void), hookname, __VA_ARGS__) > > or some such. I don't know whether you like that idea; if you do > please go ahead and do it. If not then I'm happy to take the patch > which duplicates the macro. > > Ian. > I like that method (or this slight tweak to it): -----------8<------------------------- The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Fix the macro to return the proper value. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..a31aec7 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,22 @@ * 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__) +#define OSEVENT_HOOK_INTERN(retval, hookname, ...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + retval CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) + +#define OSEVENT_HOOK(hookname, ...) ({ \ + int osevent_hook_rc = 0; \ + OSEVENT_HOOK_INTERN(osevent_hook_rc = , hookname, __VA_ARGS__); \ + osevent_hook_rc; \ +}) + +#define OSEVENT_HOOK_VOID(hookname, ...) \ + OSEVENT_HOOK_INTERN(/* void */, hookname, __VA_ARGS__) /* * fd events _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 16:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 16: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 ) id 1SS9zj-0001Nb-2B; Wed, 09 May 2012 16:44:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SS9zh-0001NU-V5 for xen-devel@lists.xen.org; Wed, 09 May 2012 16:44:06 +0000 Received: from [85.158.139.83:8792] by server-7.bemta-5.messagelabs.com id 1D/D6-16195-5DE9AAF4; Wed, 09 May 2012 16:44:05 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-2.tower-182.messagelabs.com!1336581843!27508099!1 X-Originating-IP: [63.239.67.10] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13383 invoked from network); 9 May 2012 16:44:04 -0000 Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10) by server-2.tower-182.messagelabs.com with SMTP; 9 May 2012 16:44:04 -0000 X-TM-IMSS-Message-ID: <577faf9d000cd295@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 577faf9d000cd295 ; Wed, 9 May 2012 12:45:49 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49GhtIq016292; Wed, 9 May 2012 12:43:55 -0400 Message-ID: <4FAA9E85.9010007@tycho.nsa.gov> Date: Wed, 09 May 2012 12:42:45 -0400 From: Daniel De Graaf Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> <20394.36387.49258.141494@mariner.uk.xensource.com> In-Reply-To: <20394.36387.49258.141494@mariner.uk.xensource.com> Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/09/2012 11:32 AM, Ian Jackson wrote: > Daniel De Graaf writes ("[PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): >> Agreed, using the statement expression syntax seems cleaner here. > ... >> +#define OSEVENT_HOOK(hookname,...) ({ \ >> + int rc; \ >> + if (CTX->osevent_hooks) { \ >> + CTX->osevent_in_hook++; \ >> + rc = CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ >> + CTX->osevent_in_hook--; \ >> + } else { \ >> + rc = 0; \ >> + } \ >> + rc; \ >> +}) > > Thanks. However, you need to use a different variable name to "rc". > "rc" might theoretically be present int __VA_ARGS__ in which case this > will go wrong. Also if we ever enable -Wshadow, this construction > will cause a warning. I suggest int osevent_hook_rc; > > You could preserve the unification of the two macros by having > > #define OSEVENT_HOOK(hookname,...) \ > OSEVENT_HOOK_INTERN(osevent_hook_rc =, /*empty*/, hookname, __VA_ARGS__) > > #define OSEVENT_HOOK_VOID(hookname,...) \ > OSEVENT_HOOK_INTERN(/*empty*/, (void), hookname, __VA_ARGS__) > > or some such. I don't know whether you like that idea; if you do > please go ahead and do it. If not then I'm happy to take the patch > which duplicates the macro. > > Ian. > I like that method (or this slight tweak to it): -----------8<------------------------- The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the expression CTX->osevent_in_hook-- (usually 1) instead of the value of the function call it made. Fix the macro to return the proper value. Signed-off-by: Daniel De Graaf --- tools/libxl/libxl_event.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 638b9ab..a31aec7 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -27,18 +27,22 @@ * 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__) +#define OSEVENT_HOOK_INTERN(retval, hookname, ...) do { \ + if (CTX->osevent_hooks) { \ + CTX->osevent_in_hook++; \ + retval CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__); \ + CTX->osevent_in_hook--; \ + } \ +} while (0) + +#define OSEVENT_HOOK(hookname, ...) ({ \ + int osevent_hook_rc = 0; \ + OSEVENT_HOOK_INTERN(osevent_hook_rc = , hookname, __VA_ARGS__); \ + osevent_hook_rc; \ +}) + +#define OSEVENT_HOOK_VOID(hookname, ...) \ + OSEVENT_HOOK_INTERN(/* void */, hookname, __VA_ARGS__) /* * fd events _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 17:16:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17: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 ) id 1SSAU4-0001bM-Mm; Wed, 09 May 2012 17:15:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAU1-0001bH-Pu for xen-devel@lists.xen.org; Wed, 09 May 2012 17:15:26 +0000 Received: from [193.109.254.147:34677] by server-12.bemta-14.messagelabs.com id 3F/E0-05898-C26AAAF4; Wed, 09 May 2012 17:15:24 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-27.messagelabs.com!1336583716!2776811!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6072 invoked from network); 9 May 2012 17:15:17 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-6.tower-27.messagelabs.com with SMTP; 9 May 2012 17:15:17 -0000 X-TM-IMSS-Message-ID: <33e4363e000c79df@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 33e4363e000c79df ; Wed, 9 May 2012 13:15:14 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49HEwwU017964; Wed, 9 May 2012 13:14:58 -0400 From: Daniel De Graaf To: Ian Jackson , Bamvor Jian Zhang Date: Wed, 9 May 2012 13:13:23 -0400 Message-Id: <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 In-Reply-To: <20394.36444.760368.974206@mariner.uk.xensource.com> References: <20394.36444.760368.974206@mariner.uk.xensource.com> Cc: libvir-list@redhat.com, Daniel De Graaf , Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch changes libxl to use the interface in Xen 4.2. It is provided as an example, not intended to go in to libvirt as-is since it removes all support for libxl from Xen 4.1. It also still has some cruft (extra void casts on parameters) and the device model info population is not written. It has been tested with simple domain create/destroy. --- src/libxl/libxl_conf.c | 134 +++++++++------ src/libxl/libxl_conf.h | 8 +- src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- 3 files changed, 326 insertions(+), 246 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 62621f1..c5b5561 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -41,7 +41,7 @@ #include "capabilities.h" #include "libxl_driver.h" #include "libxl_conf.h" - +#include "libxl_utils.h" #define VIR_FROM_THIS VIR_FROM_LIBXL @@ -358,18 +358,29 @@ libxlMakeCapabilitiesInternal(const char *hostmachine, } static int -libxlMakeDomCreateInfo(virDomainDefPtr def, libxl_domain_create_info *c_info) +libxlMakeDomCreateInfo(libxlDriverPrivatePtr driver, virDomainDefPtr def, libxl_domain_create_info *c_info) { char uuidstr[VIR_UUID_STRING_BUFLEN]; - libxl_init_create_info(c_info); + libxl_domain_create_info_init(c_info); + + if (STREQ(def->os.type, "hvm")) + c_info->type = LIBXL_DOMAIN_TYPE_HVM; + else + c_info->type = LIBXL_DOMAIN_TYPE_PV; - c_info->hvm = STREQ(def->os.type, "hvm"); if ((c_info->name = strdup(def->name)) == NULL) { virReportOOMError(); goto error; } + if (def->seclabel.type == VIR_DOMAIN_SECLABEL_STATIC) { + if (libxl_flask_context_to_sid(driver->ctx, def->seclabel.label, strlen(def->seclabel.label), &c_info->ssidref)) { + libxlError(VIR_ERR_INTERNAL_ERROR, + _("libxenlight failed to resolve security label '%s'"), def->seclabel.label); + } + } + virUUIDFormat(def->uuid, uuidstr); if (libxl_uuid_from_string(&c_info->uuid, uuidstr) ) { libxlError(VIR_ERR_INTERNAL_ERROR, @@ -380,7 +391,7 @@ libxlMakeDomCreateInfo(virDomainDefPtr def, libxl_domain_create_info *c_info) return 0; error: - libxl_domain_create_info_destroy(c_info); + libxl_domain_create_info_dispose(c_info); return -1; } @@ -403,9 +414,9 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) return -1; } - libxl_init_build_info(b_info, &d_config->c_info); + libxl_domain_build_info_init(b_info); - b_info->hvm = hvm; + b_info->type = hvm ? LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV; b_info->max_vcpus = def->maxvcpus; if (def->vcpus == 32) b_info->cur_vcpus = (uint32_t) -1; @@ -424,16 +435,17 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) b_info->tsc_mode = 1; } } + b_info->sched_params.weight = 1000; b_info->max_memkb = def->mem.max_balloon; b_info->target_memkb = def->mem.cur_balloon; if (hvm) { - b_info->u.hvm.pae = def->features & (1 << VIR_DOMAIN_FEATURE_PAE); - b_info->u.hvm.apic = def->features & (1 << VIR_DOMAIN_FEATURE_APIC); - b_info->u.hvm.acpi = def->features & (1 << VIR_DOMAIN_FEATURE_ACPI); + libxl_defbool_set(&b_info->u.hvm.pae, def->features & (1 << VIR_DOMAIN_FEATURE_PAE)); + libxl_defbool_set(&b_info->u.hvm.apic, def->features & (1 << VIR_DOMAIN_FEATURE_APIC)); + libxl_defbool_set(&b_info->u.hvm.acpi, def->features & (1 << VIR_DOMAIN_FEATURE_ACPI)); for (i = 0; i < def->clock.ntimers; i++) { if (def->clock.timers[i]->name == VIR_DOMAIN_TIMER_NAME_HPET && def->clock.timers[i]->present == 1) { - b_info->u.hvm.hpet = 1; + libxl_defbool_set(&b_info->u.hvm.hpet, 1); } } @@ -454,7 +466,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) } } if (def->os.bootloaderArgs) { - if ((b_info->u.pv.bootloader_args = strdup(def->os.bootloaderArgs)) == NULL) { + // XXX may need to split these arguments on a delimiter + b_info->u.pv.bootloader_args = malloc(sizeof(char*)); + if (b_info->u.pv.bootloader_args == NULL) { + virReportOOMError(); + goto error; + } + b_info->u.pv.bootloader_args[0] = strdup(def->os.bootloaderArgs); + if (b_info->u.pv.bootloader_args[0] == NULL) { virReportOOMError(); goto error; } @@ -467,8 +486,8 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) } if (def->os.kernel) { /* libxl_init_build_info() sets kernel.path = strdup("hvmloader") */ - VIR_FREE(b_info->kernel.path); - if ((b_info->kernel.path = strdup(def->os.kernel)) == NULL) { + VIR_FREE(b_info->u.pv.kernel.path); + if ((b_info->u.pv.kernel.path = strdup(def->os.kernel)) == NULL) { virReportOOMError(); goto error; } @@ -484,7 +503,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) return 0; error: - libxl_domain_build_info_destroy(b_info); + libxl_domain_build_info_dispose(b_info); return -1; } @@ -507,30 +526,30 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, STREQ(l_disk->driverName, "tap2")) { if (l_disk->driverType) { if (STREQ(l_disk->driverType, "qcow")) { - x_disk->format = DISK_FORMAT_QCOW; - x_disk->backend = DISK_BACKEND_QDISK; + x_disk->format = LIBXL_DISK_FORMAT_QCOW; + x_disk->backend = LIBXL_DISK_BACKEND_QDISK; } else if (STREQ(l_disk->driverType, "qcow2")) { - x_disk->format = DISK_FORMAT_QCOW2; - x_disk->backend = DISK_BACKEND_QDISK; + x_disk->format = LIBXL_DISK_FORMAT_QCOW2; + x_disk->backend = LIBXL_DISK_BACKEND_QDISK; } else if (STREQ(l_disk->driverType, "vhd")) { - x_disk->format = DISK_FORMAT_VHD; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_VHD; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } else if (STREQ(l_disk->driverType, "aio") || STREQ(l_disk->driverType, "raw")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } } else { /* No subtype specified, default to raw/tap */ - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } } else if (STREQ(l_disk->driverName, "file")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } else if (STREQ(l_disk->driverName, "phy")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_PHY; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_PHY; } else { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight does not support disk driver %s"), @@ -538,13 +557,14 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, return -1; } } else { - /* No driverName - default to raw/tap?? */ - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + + /* No driverName - default to raw/phy?? */ + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_PHY; } - /* How to set unpluggable? */ - x_disk->unpluggable = 1; + /* XXX is this right? */ + x_disk->removable = 1; x_disk->readwrite = !l_disk->readonly; x_disk->is_cdrom = l_disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM ? 1 : 0; if (l_disk->transient) { @@ -553,7 +573,7 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, return -1; } - x_disk->domid = def->id; + (void)def->id; return 0; } @@ -583,7 +603,7 @@ libxlMakeDiskList(virDomainDefPtr def, libxl_domain_config *d_config) error: for (i = 0; i < ndisks; i++) - libxl_device_disk_destroy(&x_disks[i]); + libxl_device_disk_dispose(&x_disks[i]); VIR_FREE(x_disks); return -1; } @@ -595,7 +615,7 @@ libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, // TODO: Where is mtu stored? //x_nics[i].mtu = 1492; - x_nic->domid = def->id; + (void)def->id; memcpy(x_nic->mac, l_nic->mac, sizeof(libxl_mac)); if (l_nic->model && !STREQ(l_nic->model, "netfront")) { @@ -603,9 +623,9 @@ libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, virReportOOMError(); return -1; } - x_nic->nictype = NICTYPE_IOEMU; + x_nic->nictype = LIBXL_NIC_TYPE_IOEMU; } else { - x_nic->nictype = NICTYPE_VIF; + x_nic->nictype = LIBXL_NIC_TYPE_VIF; } if (l_nic->ifname && (x_nic->ifname = strdup(l_nic->ifname)) == NULL) { @@ -663,7 +683,7 @@ libxlMakeNicList(virDomainDefPtr def, libxl_domain_config *d_config) error: for (i = 0; i < nnics; i++) - libxl_device_nic_destroy(&x_nics[i]); + libxl_device_nic_dispose(&x_nics[i]); VIR_FREE(x_nics); return -1; } @@ -677,23 +697,23 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, switch (l_vfb->type) { case VIR_DOMAIN_GRAPHICS_TYPE_SDL: - x_vfb->sdl = 1; + libxl_defbool_set(&x_vfb->sdl.enable, 1); if (l_vfb->data.sdl.display && - (x_vfb->display = strdup(l_vfb->data.sdl.display)) == NULL) { + (x_vfb->sdl.display = strdup(l_vfb->data.sdl.display)) == NULL) { virReportOOMError(); return -1; } if (l_vfb->data.sdl.xauth && - (x_vfb->xauthority = + (x_vfb->sdl.xauthority = strdup(l_vfb->data.sdl.xauth)) == NULL) { virReportOOMError(); return -1; } break; case VIR_DOMAIN_GRAPHICS_TYPE_VNC: - x_vfb->vnc = 1; + libxl_defbool_set(&x_vfb->vnc.enable, 1); /* driver handles selection of free port */ - x_vfb->vncunused = 0; + libxl_defbool_set(&x_vfb->vnc.findunused, 0); if (l_vfb->data.vnc.autoport) { port = libxlNextFreeVncPort(driver, LIBXL_VNC_PORT_MIN); if (port < 0) { @@ -703,13 +723,13 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, } l_vfb->data.vnc.port = port; } - x_vfb->vncdisplay = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN; + x_vfb->vnc.display = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN; listenAddr = virDomainGraphicsListenGetAddress(l_vfb, 0); if (listenAddr) { /* libxl_device_vfb_init() does strdup("127.0.0.1") */ - VIR_FREE(x_vfb->vnclisten); - if ((x_vfb->vnclisten = strdup(listenAddr)) == NULL) { + VIR_FREE(x_vfb->vnc.listen); + if ((x_vfb->vnc.listen = strdup(listenAddr)) == NULL) { virReportOOMError(); return -1; } @@ -722,7 +742,7 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, } break; } - x_vfb->domid = def->id; + (void) def->id; return 0; } @@ -750,8 +770,8 @@ libxlMakeVfbList(libxlDriverPrivatePtr driver, } for (i = 0; i < nvfbs; i++) { - libxl_device_vfb_init(&x_vfbs[i], i); - libxl_device_vkb_init(&x_vkbs[i], i); + libxl_device_vfb_init(&x_vfbs[i]); + libxl_device_vkb_init(&x_vkbs[i]); if (libxlMakeVfb(driver, def, l_vfbs[i], &x_vfbs[i]) < 0) goto error; @@ -765,14 +785,15 @@ libxlMakeVfbList(libxlDriverPrivatePtr driver, error: for (i = 0; i < nvfbs; i++) { - libxl_device_vfb_destroy(&x_vfbs[i]); - libxl_device_vkb_destroy(&x_vkbs[i]); + libxl_device_vfb_dispose(&x_vfbs[i]); + libxl_device_vkb_dispose(&x_vkbs[i]); } VIR_FREE(x_vfbs); VIR_FREE(x_vkbs); return -1; } +#if 0 static int libxlMakeChrdevStr(virDomainChrDefPtr def, char **buf) { @@ -906,6 +927,7 @@ error: libxl_device_model_info_destroy(dm_info); return -1; } +#endif virCapsPtr libxlMakeCapabilities(libxl_ctx *ctx) @@ -940,7 +962,7 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, virDomainDefPtr def, libxl_domain_config *d_config) { - if (libxlMakeDomCreateInfo(def, &d_config->c_info) < 0) + if (libxlMakeDomCreateInfo(driver, def, &d_config->c_info) < 0) return -1; if (libxlMakeDomBuildInfo(def, d_config) < 0) { @@ -959,9 +981,11 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, goto error; } +#if 0 if (libxlMakeDeviceModelInfo(def, d_config) < 0) { goto error; } +#endif d_config->on_reboot = def->onReboot; d_config->on_poweroff = def->onPoweroff; @@ -970,6 +994,6 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, return 0; error: - libxl_domain_config_destroy(d_config); + libxl_domain_config_dispose(d_config); return -1; } diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 2820afb..73ab733 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -58,7 +58,7 @@ struct _libxlDriverPrivate { FILE *logger_file; xentoollog_logger *logger; /* libxl ctx for driver wide ops; getVersion, getNodeInfo, ... */ - libxl_ctx ctx; + libxl_ctx *ctx; virBitmapPtr reservedVNCPorts; virDomainObjList domains; @@ -77,10 +77,8 @@ typedef struct _libxlDomainObjPrivate libxlDomainObjPrivate; typedef libxlDomainObjPrivate *libxlDomainObjPrivatePtr; struct _libxlDomainObjPrivate { /* per domain libxl ctx */ - libxl_ctx ctx; - libxl_waiter *dWaiter; - int waiterFD; - int eventHdl; + libxl_ctx *ctx; + libxl_evgen_domain_death *deathW; }; # define LIBXL_SAVE_MAGIC "libvirt-xml\n \0 \r" diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 45bf1f8..8656f35 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -40,6 +40,7 @@ #include "memory.h" #include "uuid.h" #include "command.h" +#include "libxl.h" #include "libxl_driver.h" #include "libxl_conf.h" #include "xen_xm.h" @@ -79,6 +80,138 @@ libxlDriverUnlock(libxlDriverPrivatePtr driver) virMutexUnlock(&driver->lock); } +struct libxl_osevent_hook_fdinfo { + libxlDomainObjPrivatePtr priv; + void *xl_priv; + int watch; +}; + +static void cb_fd_event(int watch, int fd, int vir_events, void *fdinfo) +{ + struct libxl_osevent_hook_fdinfo *info = fdinfo; + int events = 0; + (void)watch; (void)fd; + if (vir_events & VIR_EVENT_HANDLE_READABLE) + events |= POLLIN; + if (vir_events & VIR_EVENT_HANDLE_WRITABLE) + events |= POLLOUT; + if (vir_events & VIR_EVENT_HANDLE_ERROR) + events |= POLLERR; + if (vir_events & VIR_EVENT_HANDLE_HANGUP) + events |= POLLHUP; + libxl_osevent_occurred_fd(info->priv->ctx, info->xl_priv, fd, 0, events); +} + +static void free_fdinfo(void *opaque) +{ + free(opaque); +} + +static int evhook_fd_register(void *priv, int fd, void **hndp, short events, void *xl_priv) +{ + int vir_events = VIR_EVENT_HANDLE_ERROR; + struct libxl_osevent_hook_fdinfo *fdinfo; + fdinfo = malloc(sizeof(fdinfo)); + fdinfo->priv = priv; + fdinfo->xl_priv = xl_priv; + *hndp = fdinfo; + + if (events & POLLIN) + vir_events |= VIR_EVENT_HANDLE_READABLE; + if (events & POLLOUT) + vir_events |= VIR_EVENT_HANDLE_WRITABLE; + fdinfo->watch = virEventAddHandle(fd, vir_events, cb_fd_event, fdinfo, free_fdinfo); + if (fdinfo->watch < 0) + return fdinfo->watch; + return 0; +} + +static int evhook_fd_modify(void *priv, int fd, void **hndp, short events) +{ + struct libxl_osevent_hook_fdinfo *fdinfo = *hndp; + (void)fd; (void)priv; + int vir_events = VIR_EVENT_HANDLE_ERROR; + if (events & POLLIN) + vir_events |= VIR_EVENT_HANDLE_READABLE; + if (events & POLLOUT) + vir_events |= VIR_EVENT_HANDLE_WRITABLE; + virEventUpdateHandle(fdinfo->watch, vir_events); + return 0; +} + +static void evhook_fd_deregister(void *priv, int fd, void *hnd) +{ + struct libxl_osevent_hook_fdinfo *fdinfo = hnd; + (void)priv; (void)fd; + virEventRemoveHandle(fdinfo->watch); +} + +struct libxl_osevent_hook_timerinfo { + libxlDomainObjPrivatePtr priv; + void *xl_priv; + int id; +}; + + +static void cb_timer(int timer, void *timer_v) +{ + struct libxl_osevent_hook_timerinfo *timer_info = timer_v; + (void)timer; + libxl_osevent_occurred_timeout(timer_info->priv->ctx, timer_info->xl_priv); +} + +static void timer_info_free(void* obj) +{ + free(obj); +} + +static int evhook_timeout_register(void *priv, void **hndp, struct timeval abs_t, void *for_libxl) +{ + struct timeval now; + struct libxl_osevent_hook_timerinfo *timer_info; + int timeout, timer_id; + timer_info = malloc(sizeof(*timer_info)); + gettimeofday(&now, NULL); + timeout = (abs_t.tv_usec - now.tv_usec) / 1000; + timeout += (abs_t.tv_sec - now.tv_sec) * 1000; + timer_id = virEventAddTimeout(timeout, cb_timer, timer_info, timer_info_free); + if (timer_id < 0) + return timer_id; + timer_info->priv = priv; + timer_info->xl_priv = for_libxl; + timer_info->id = timer_id; + *hndp = timer_info; + return 0; +} + +static int evhook_timeout_modify(void *priv, void **hndp, struct timeval abs_t) +{ + struct timeval now; + int timeout; + struct libxl_osevent_hook_timerinfo *timer_info = *hndp; + (void)priv; + gettimeofday(&now, NULL); + timeout = (abs_t.tv_usec - now.tv_usec) / 1000; + timeout += (abs_t.tv_sec - now.tv_sec) * 1000; + virEventUpdateTimeout(timer_info->id, timeout); + return 0; +} + +static void evhook_timeout_deregister(void *priv, void *hnd) { + struct libxl_osevent_hook_timerinfo *timer_info = hnd; + virEventRemoveTimeout(timer_info->id); + (void)priv; +} + +static const libxl_osevent_hooks event_callbacks = { + .fd_register = evhook_fd_register, + .fd_modify = evhook_fd_modify, + .fd_deregister = evhook_fd_deregister, + .timeout_register = evhook_timeout_register, + .timeout_modify = evhook_timeout_modify, + .timeout_deregister = evhook_timeout_deregister, +}; + static void * libxlDomainObjPrivateAlloc(void) { @@ -87,9 +220,9 @@ libxlDomainObjPrivateAlloc(void) if (VIR_ALLOC(priv) < 0) return NULL; - libxl_ctx_init(&priv->ctx, LIBXL_VERSION, libxl_driver->logger); - priv->waiterFD = -1; - priv->eventHdl = -1; + libxl_ctx_alloc(&priv->ctx, LIBXL_VERSION, 0, libxl_driver->logger); + priv->deathW = NULL; + libxl_osevent_register_hooks(priv->ctx, &event_callbacks, priv); return priv; } @@ -99,16 +232,12 @@ libxlDomainObjPrivateFree(void *data) { libxlDomainObjPrivatePtr priv = data; - if (priv->eventHdl >= 0) - virEventRemoveHandle(priv->eventHdl); - - if (priv->dWaiter) { - libxl_stop_waiting(&priv->ctx, priv->dWaiter); - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); + if (priv->deathW) { + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + VIR_FREE(priv->deathW); } - libxl_ctx_free(&priv->ctx); + libxl_ctx_free(priv->ctx); VIR_FREE(priv); } @@ -120,17 +249,6 @@ libxlDomainEventQueue(libxlDriverPrivatePtr driver, virDomainEventPtr event) virDomainEventStateQueue(driver->domainEventState, event); } -/* - * Remove reference to domain object. - */ -static void -libxlDomainObjUnref(void *data) -{ - virDomainObjPtr vm = data; - - ignore_value(virDomainObjUnref(vm)); -} - static void libxlAutostartDomain(void *payload, const void *name ATTRIBUTE_UNUSED, void *opaque) @@ -161,13 +279,13 @@ libxlDoNodeGetInfo(libxlDriverPrivatePtr driver, virNodeInfoPtr info) const libxl_version_info* ver_info; struct utsname utsname; - if (libxl_get_physinfo(&driver->ctx, &phy_info)) { + if (libxl_get_physinfo(driver->ctx, &phy_info)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_physinfo_info failed")); return -1; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_version_info failed")); return -1; @@ -291,15 +409,9 @@ libxlVmCleanup(libxlDriverPrivatePtr driver, char *file; int i; - if (priv->eventHdl >= 0) { - virEventRemoveHandle(priv->eventHdl); - priv->eventHdl = -1; - } - - if (priv->dWaiter) { - libxl_stop_waiting(&priv->ctx, priv->dWaiter); - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); + if (priv->deathW) { + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + priv->deathW = NULL; } if (vm->persistent) { @@ -350,12 +462,11 @@ libxlVmCleanup(libxlDriverPrivatePtr driver, static int libxlVmReap(libxlDriverPrivatePtr driver, virDomainObjPtr vm, - int force, virDomainShutoffReason reason) { libxlDomainObjPrivatePtr priv = vm->privateData; - if (libxl_domain_destroy(&priv->ctx, vm->def->id, force) < 0) { + if (libxl_domain_destroy(priv->ctx, vm->def->id) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Unable to cleanup domain %d"), vm->def->id); return -1; @@ -368,56 +479,26 @@ libxlVmReap(libxlDriverPrivatePtr driver, /* * Handle previously registered event notification from libxenlight */ -static void libxlEventHandler(int watch, - int fd, - int events, - void *data) +static void libxlEventHandler(void *data, const libxl_event *event) { libxlDriverPrivatePtr driver = libxl_driver; virDomainObjPtr vm = data; - libxlDomainObjPrivatePtr priv; virDomainEventPtr dom_event = NULL; - libxl_event event; - libxl_dominfo info; libxlDriverLock(driver); virDomainObjLock(vm); libxlDriverUnlock(driver); - priv = vm->privateData; - - memset(&event, 0, sizeof(event)); - memset(&info, 0, sizeof(info)); - - if (priv->waiterFD != fd || priv->eventHdl != watch) { - virEventRemoveHandle(watch); - priv->eventHdl = -1; - goto cleanup; - } - - if (!(events & VIR_EVENT_HANDLE_READABLE)) - goto cleanup; - - if (libxl_get_event(&priv->ctx, &event)) - goto cleanup; - - if (event.type == LIBXL_EVENT_DOMAIN_DEATH) { + if (event->type == LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN) { virDomainShutoffReason reason; - /* libxl_event_get_domain_death_info returns 1 if death - * event was for this domid */ - if (libxl_event_get_domain_death_info(&priv->ctx, - vm->def->id, - &event, - &info) != 1) + if (event->domid != vm->def->id) goto cleanup; - virEventRemoveHandle(watch); - priv->eventHdl = -1; - switch (info.shutdown_reason) { - case SHUTDOWN_poweroff: - case SHUTDOWN_crash: - if (info.shutdown_reason == SHUTDOWN_crash) { + switch (event->u.domain_shutdown.shutdown_reason) { + case LIBXL_SHUTDOWN_REASON_POWEROFF: + case LIBXL_SHUTDOWN_REASON_CRASH: + if (event->u.domain_shutdown.shutdown_reason == LIBXL_SHUTDOWN_REASON_CRASH) { dom_event = virDomainEventNewFromObj(vm, VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_CRASHED); @@ -425,18 +506,18 @@ static void libxlEventHandler(int watch, } else { reason = VIR_DOMAIN_SHUTOFF_SHUTDOWN; } - libxlVmReap(driver, vm, 0, reason); + libxlVmReap(driver, vm, reason); if (!vm->persistent) { virDomainRemoveInactive(&driver->domains, vm); vm = NULL; } break; - case SHUTDOWN_reboot: - libxlVmReap(driver, vm, 0, VIR_DOMAIN_SHUTOFF_SHUTDOWN); + case LIBXL_SHUTDOWN_REASON_REBOOT: + libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN); libxlVmStart(driver, vm, 0, -1); break; default: - VIR_INFO("Unhandled shutdown_reason %d", info.shutdown_reason); + VIR_INFO("Unhandled shutdown_reason %d", event->u.domain_shutdown.shutdown_reason); break; } } @@ -449,9 +530,14 @@ cleanup: libxlDomainEventQueue(driver, dom_event); libxlDriverUnlock(driver); } - libxl_free_event(&event); } +static const struct libxl_event_hooks ev_hooks = { + .event_occurs_mask = LIBXL_EVENTMASK_ALL, + .event_occurs = libxlEventHandler, + .disaster = NULL, +}; + /* * Register domain events with libxenlight and insert event handles * in libvirt's event loop. @@ -460,40 +546,18 @@ static int libxlCreateDomEvents(virDomainObjPtr vm) { libxlDomainObjPrivatePtr priv = vm->privateData; - int fd; - - if (VIR_ALLOC(priv->dWaiter) < 0) { - virReportOOMError(); - return -1; - } - if (libxl_wait_for_domain_death(&priv->ctx, vm->def->id, priv->dWaiter)) - goto error; + libxl_event_register_callbacks(priv->ctx, &ev_hooks, vm); - libxl_get_wait_fd(&priv->ctx, &fd); - if (fd < 0) + if (libxl_evenable_domain_death(priv->ctx, vm->def->id, 0, &priv->deathW)) goto error; - priv->waiterFD = fd; - /* Add a reference to the domain object while it is injected in - * the event loop. - */ - virDomainObjRef(vm); - if ((priv->eventHdl = virEventAddHandle( - fd, - VIR_EVENT_HANDLE_READABLE | VIR_EVENT_HANDLE_ERROR, - libxlEventHandler, - vm, libxlDomainObjUnref)) < 0) { - ignore_value(virDomainObjUnref(vm)); - goto error; - } - return 0; error: - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); - priv->eventHdl = -1; + if (priv->deathW) + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + free(priv->deathW); return -1; } @@ -534,7 +598,7 @@ libxlDomainSetVcpuAffinites(libxlDriverPrivatePtr driver, virDomainObjPtr vm) map.size = cpumaplen; map.map = cpumap; - if (libxl_set_vcpuaffinity(&priv->ctx, def->id, vcpu, &map) != 0) { + if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to pin vcpu '%d' with libxenlight"), vcpu); goto cleanup; @@ -560,11 +624,10 @@ libxlFreeMem(libxlDomainObjPrivatePtr priv, libxl_domain_config *d_config) int tries = 3; int wait_secs = 10; - if ((ret = libxl_domain_need_memory(&priv->ctx, &d_config->b_info, - &d_config->dm_info, + if ((ret = libxl_domain_need_memory(priv->ctx, &d_config->b_info, &needed_mem)) >= 0) { for (i = 0; i < tries; ++i) { - if ((ret = libxl_get_free_memory(&priv->ctx, &free_mem)) < 0) + if ((ret = libxl_get_free_memory(priv->ctx, &free_mem)) < 0) break; if (free_mem >= needed_mem) { @@ -572,17 +635,17 @@ libxlFreeMem(libxlDomainObjPrivatePtr priv, libxl_domain_config *d_config) break; } - if ((ret = libxl_set_memory_target(&priv->ctx, 0, + if ((ret = libxl_set_memory_target(priv->ctx, 0, free_mem - needed_mem, /* relative */ 1, 0)) < 0) break; - ret = libxl_wait_for_free_memory(&priv->ctx, 0, needed_mem, + ret = libxl_wait_for_free_memory(priv->ctx, 0, needed_mem, wait_secs); if (ret == 0 || ret != ERROR_NOMEM) break; - if ((ret = libxl_wait_for_memory_target(&priv->ctx, 0, 1)) < 0) + if ((ret = libxl_wait_for_memory_target(priv->ctx, 0, 1)) < 0) break; } } @@ -651,7 +714,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, VIR_FREE(managed_save_path); } - memset(&d_config, 0, sizeof(d_config)); + libxl_domain_config_init(&d_config); if (libxlBuildDomainConfig(driver, vm->def, &d_config) < 0 ) return -1; @@ -664,10 +727,10 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, } if (restore_fd < 0) - ret = libxl_domain_create_new(&priv->ctx, &d_config, + ret = libxl_domain_create_new(priv->ctx, &d_config, NULL, &child_console_pid, &domid); else - ret = libxl_domain_create_restore(&priv->ctx, &d_config, NULL, + ret = libxl_domain_create_restore(priv->ctx, &d_config, NULL, &child_console_pid, &domid, restore_fd); @@ -687,7 +750,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, if ((dom_xml = virDomainDefFormat(vm->def, 0)) == NULL) goto error; - if (libxl_userdata_store(&priv->ctx, domid, "libvirt-xml", + if (libxl_userdata_store(priv->ctx, domid, "libvirt-xml", (uint8_t *)dom_xml, strlen(dom_xml) + 1)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to store userdata")); @@ -701,7 +764,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, goto error; if (!start_paused) { - libxl_domain_unpause(&priv->ctx, domid); + libxl_domain_unpause(priv->ctx, domid); virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED); } else { virDomainObjSetState(vm, VIR_DOMAIN_PAUSED, VIR_DOMAIN_PAUSED_USER); @@ -717,18 +780,18 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, VIR_DOMAIN_EVENT_STARTED_RESTORED); libxlDomainEventQueue(driver, event); - libxl_domain_config_destroy(&d_config); + libxl_domain_config_dispose(&d_config); VIR_FREE(dom_xml); VIR_FORCE_CLOSE(managed_save_fd); return 0; error: if (domid > 0) { - libxl_domain_destroy(&priv->ctx, domid, 0); + libxl_domain_destroy(priv->ctx, domid); vm->def->id = -1; virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, VIR_DOMAIN_SHUTOFF_FAILED); } - libxl_domain_config_destroy(&d_config); + libxl_domain_config_dispose(&d_config); VIR_FREE(dom_xml); VIR_FREE(managed_save_path); virDomainDefFree(def); @@ -756,7 +819,7 @@ libxlReconnectDomain(void *payload, virDomainObjLock(vm); /* Does domain still exist? */ - rc = libxl_domain_info(&driver->ctx, &d_info, vm->def->id); + rc = libxl_domain_info(driver->ctx, &d_info, vm->def->id); if (rc == ERROR_INVAL) { goto out; } else if (rc != 0) { @@ -766,7 +829,7 @@ libxlReconnectDomain(void *payload, } /* Is this a domain that was under libvirt control? */ - if (libxl_userdata_retrieve(&driver->ctx, vm->def->id, + if (libxl_userdata_retrieve(driver->ctx, vm->def->id, "libvirt-xml", &data, &len)) { VIR_DEBUG("libxl_userdata_retrieve failed, ignoring domain %d", vm->def->id); goto out; @@ -804,7 +867,7 @@ libxlShutdown(void) libxlDriverLock(libxl_driver); virCapabilitiesFree(libxl_driver->caps); virDomainObjListDeinit(&libxl_driver->domains); - libxl_ctx_free(&libxl_driver->ctx); + libxl_ctx_free(libxl_driver->ctx); xtl_logger_destroy(libxl_driver->logger); if (libxl_driver->logger_file) VIR_FORCE_FCLOSE(libxl_driver->logger_file); @@ -937,14 +1000,14 @@ libxlStartup(int privileged) { goto fail; } - if (libxl_ctx_init(&libxl_driver->ctx, - LIBXL_VERSION, + if (libxl_ctx_alloc(&libxl_driver->ctx, + LIBXL_VERSION, 0, libxl_driver->logger)) { VIR_INFO("cannot initialize libxenlight context, probably not running in a Xen Dom0, disabling driver"); goto fail; } - if ((ver_info = libxl_get_version_info(&libxl_driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(libxl_driver->ctx)) == NULL) { VIR_INFO("cannot version information from libxenlight, disabling driver"); goto fail; } @@ -952,7 +1015,7 @@ libxlStartup(int privileged) { (ver_info->xen_version_minor * 1000); if ((libxl_driver->caps = - libxlMakeCapabilities(&libxl_driver->ctx)) == NULL) { + libxlMakeCapabilities(libxl_driver->ctx)) == NULL) { VIR_ERROR(_("cannot create capabilities for libxenlight")); goto error; } @@ -1112,7 +1175,7 @@ libxlGetMaxVcpus(virConnectPtr conn, const char *type ATTRIBUTE_UNUSED) int ret; libxlDriverPrivatePtr driver = conn->privateData; - ret = libxl_get_max_cpus(&driver->ctx); + ret = libxl_get_max_cpus(driver->ctx); /* libxl_get_max_cpus() will return 0 if there were any failures, e.g. xc_physinfo() failing */ if (ret == 0) @@ -1317,7 +1380,7 @@ libxlDomainSuspend(virDomainPtr dom) priv = vm->privateData; if (virDomainObjGetState(vm, NULL) != VIR_DOMAIN_PAUSED) { - if (libxl_domain_pause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_pause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to suspend domain '%d' with libxenlight"), dom->id); @@ -1376,7 +1439,7 @@ libxlDomainResume(virDomainPtr dom) priv = vm->privateData; if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_PAUSED) { - if (libxl_domain_unpause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_unpause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to resume domain '%d' with libxenlight"), dom->id); @@ -1433,7 +1496,7 @@ libxlDomainShutdownFlags(virDomainPtr dom, unsigned int flags) } priv = vm->privateData; - if (libxl_domain_shutdown(&priv->ctx, dom->id, LIBXL_DOM_REQ_POWEROFF) != 0) { + if (libxl_domain_shutdown(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to shutdown domain '%d' with libxenlight"), dom->id); @@ -1486,7 +1549,7 @@ libxlDomainReboot(virDomainPtr dom, unsigned int flags) } priv = vm->privateData; - if (libxl_domain_shutdown(&priv->ctx, dom->id, LIBXL_DOM_REQ_REBOOT) != 0) { + if (libxl_domain_reboot(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to reboot domain '%d' with libxenlight"), dom->id); @@ -1531,7 +1594,7 @@ libxlDomainDestroyFlags(virDomainPtr dom, event = virDomainEventNewFromObj(vm,VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_DESTROYED); - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_DESTROYED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_DESTROYED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), dom->id); goto cleanup; @@ -1669,7 +1732,7 @@ libxlDomainSetMemoryFlags(virDomainPtr dom, unsigned long newmem, if (flags & VIR_DOMAIN_MEM_LIVE) { priv = vm->privateData; - if (libxl_domain_setmaxmem(&priv->ctx, dom->id, newmem) < 0) { + if (libxl_domain_setmaxmem(priv->ctx, dom->id, newmem) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set maximum memory for domain '%d'" " with libxenlight"), dom->id); @@ -1698,7 +1761,7 @@ libxlDomainSetMemoryFlags(virDomainPtr dom, unsigned long newmem, if (flags & VIR_DOMAIN_MEM_LIVE) { priv = vm->privateData; - if (libxl_set_memory_target(&priv->ctx, dom->id, newmem, 0, + if (libxl_set_memory_target(priv->ctx, dom->id, newmem, 0, /* force */ 1) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set memory for domain '%d'" @@ -1758,7 +1821,7 @@ libxlDomainGetInfo(virDomainPtr dom, virDomainInfoPtr info) info->memory = vm->def->mem.cur_balloon; info->maxMem = vm->def->mem.max_balloon; } else { - if (libxl_domain_info(&driver->ctx, &d_info, dom->id) != 0) { + if (libxl_domain_info(driver->ctx, &d_info, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_domain_info failed for domain '%d'"), dom->id); goto cleanup; @@ -1858,7 +1921,7 @@ libxlDoDomainSave(libxlDriverPrivatePtr driver, virDomainObjPtr vm, goto cleanup; } - if (libxl_domain_suspend(&priv->ctx, NULL, vm->def->id, fd) != 0) { + if (libxl_domain_suspend(priv->ctx, NULL, vm->def->id, fd) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to save domain '%d' with libxenlight"), vm->def->id); @@ -1868,7 +1931,7 @@ libxlDoDomainSave(libxlDriverPrivatePtr driver, virDomainObjPtr vm, event = virDomainEventNewFromObj(vm, VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_SAVED); - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_SAVED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_SAVED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), vm->def->id); goto cleanup; @@ -2023,7 +2086,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) if (!(flags & VIR_DUMP_LIVE) && virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) { - if (libxl_domain_pause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_pause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Before dumping core, failed to suspend domain '%d'" " with libxenlight"), @@ -2034,7 +2097,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) paused = true; } - if (libxl_domain_core_dump(&priv->ctx, dom->id, to) != 0) { + if (libxl_domain_core_dump(priv->ctx, dom->id, to) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to dump core of domain '%d' with libxenlight"), dom->id); @@ -2043,7 +2106,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) libxlDriverLock(driver); if (flags & VIR_DUMP_CRASH) { - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_CRASHED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_CRASHED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), dom->id); goto cleanup_unlock; @@ -2064,7 +2127,7 @@ cleanup_unlock: libxlDriverUnlock(driver); cleanup_unpause: if (virDomainObjIsActive(vm) && paused) { - if (libxl_domain_unpause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_unpause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("After dumping core, failed to resume domain '%d' with" " libxenlight"), dom->id); @@ -2301,7 +2364,7 @@ libxlDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, break; case VIR_DOMAIN_VCPU_LIVE: - if (libxl_set_vcpuonline(&priv->ctx, dom->id, &map) != 0) { + if (libxl_set_vcpuonline(priv->ctx, dom->id, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set vcpus for domain '%d'" " with libxenlight"), dom->id); @@ -2310,7 +2373,7 @@ libxlDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, break; case VIR_DOMAIN_VCPU_LIVE | VIR_DOMAIN_VCPU_CONFIG: - if (libxl_set_vcpuonline(&priv->ctx, dom->id, &map) != 0) { + if (libxl_set_vcpuonline(priv->ctx, dom->id, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set vcpus for domain '%d'" " with libxenlight"), dom->id); @@ -2427,7 +2490,7 @@ libxlDomainPinVcpu(virDomainPtr dom, unsigned int vcpu, unsigned char *cpumap, map.size = maplen; map.map = cpumap; - if (libxl_set_vcpuaffinity(&priv->ctx, dom->id, vcpu, &map) != 0) { + if (libxl_set_vcpuaffinity(priv->ctx, dom->id, vcpu, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to pin vcpu '%d' with libxenlight"), vcpu); goto cleanup; @@ -2479,7 +2542,7 @@ libxlDomainGetVcpus(virDomainPtr dom, virVcpuInfoPtr info, int maxinfo, } priv = vm->privateData; - if ((vcpuinfo = libxl_list_vcpu(&priv->ctx, dom->id, &maxcpu, + if ((vcpuinfo = libxl_list_vcpu(priv->ctx, dom->id, &maxcpu, &hostcpus)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to list vcpus for domain '%d' with libxenlight"), @@ -2506,7 +2569,7 @@ libxlDomainGetVcpus(virDomainPtr dom, virVcpuInfoPtr info, int maxinfo, MIN(maplen, vcpuinfo[i].cpumap.size)); } - libxl_vcpuinfo_destroy(&vcpuinfo[i]); + libxl_vcpuinfo_dispose(&vcpuinfo[i]); } VIR_FREE(vcpuinfo); @@ -2564,7 +2627,7 @@ libxlDomainXMLFromNative(virConnectPtr conn, const char * nativeFormat, goto cleanup; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { VIR_ERROR(_("cannot get version information from libxenlight")); goto cleanup; } @@ -2607,7 +2670,7 @@ libxlDomainXMLToNative(virConnectPtr conn, const char * nativeFormat, goto cleanup; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { VIR_ERROR(_("cannot get version information from libxenlight")); goto cleanup; } @@ -2870,7 +2933,7 @@ libxlDomainChangeEjectableMedia(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_cdrom_insert(&priv->ctx, vm->def->id, &x_disk)) < 0) { + if ((ret = libxl_cdrom_insert(priv->ctx, vm->def->id, &x_disk)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to change media for disk '%s'"), disk->dst); @@ -2925,7 +2988,7 @@ libxlDomainAttachDeviceDiskLive(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, l_disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_device_disk_add(&priv->ctx, vm->def->id, + if ((ret = libxl_device_disk_add(priv->ctx, vm->def->id, &x_disk)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to attach disk '%s'"), @@ -2959,7 +3022,6 @@ libxlDomainDetachDeviceDiskLive(libxlDomainObjPrivatePtr priv, virDomainDiskDefPtr l_disk = NULL; libxl_device_disk x_disk; int i; - int wait_secs = 2; int ret = -1; switch (dev->data.disk->device) { @@ -2979,8 +3041,7 @@ libxlDomainDetachDeviceDiskLive(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, l_disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_device_disk_del(&priv->ctx, &x_disk, - wait_secs)) < 0) { + if ((ret = libxl_device_disk_remove(priv->ctx, vm->def->id, &x_disk, NULL)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to detach disk '%s'"), l_disk->dst); @@ -3355,12 +3416,12 @@ libxlNodeGetFreeMemory(virConnectPtr conn) const libxl_version_info* ver_info; libxlDriverPrivatePtr driver = conn->privateData; - if (libxl_get_physinfo(&driver->ctx, &phy_info)) { + if (libxl_get_physinfo(driver->ctx, &phy_info)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_physinfo_info failed")); return 0; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_version_info failed")); return 0; } @@ -3506,7 +3567,7 @@ libxlDomainGetSchedulerType(virDomainPtr dom, int *nparams) libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; char * ret = NULL; - int sched_id; + libxl_scheduler sched_id; libxlDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, dom->uuid); @@ -3523,31 +3584,29 @@ libxlDomainGetSchedulerType(virDomainPtr dom, int *nparams) } priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); if (nparams) *nparams = 0; switch(sched_id) { - case XEN_SCHEDULER_SEDF: + case LIBXL_SCHEDULER_SEDF: ret = strdup("sedf"); break; - case XEN_SCHEDULER_CREDIT: + case LIBXL_SCHEDULER_CREDIT: ret = strdup("credit"); if (nparams) *nparams = XEN_SCHED_CREDIT_NPARAM; break; - case XEN_SCHEDULER_CREDIT2: + case LIBXL_SCHEDULER_CREDIT2: ret = strdup("credit2"); break; - case XEN_SCHEDULER_ARINC653: + case LIBXL_SCHEDULER_ARINC653: ret = strdup("arinc653"); break; default: + libxlError(VIR_ERR_INTERNAL_ERROR, + _("Failed to get scheduler id for domain '%d'" + " with libxenlight"), dom->id); goto cleanup; } @@ -3566,11 +3625,16 @@ libxlDomainGetSchedulerParametersFlags(virDomainPtr dom, int *nparams, unsigned int flags) { + (void)dom; + (void)params; + (void)nparams; + (void)flags; + libxlDriverPrivatePtr driver = dom->conn->privateData; libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; - libxl_sched_credit sc_info; - int sched_id; + libxl_sched_credit_domain sc_info; + libxl_scheduler sched_id; int ret = -1; virCheckFlags(0, -1); @@ -3591,20 +3655,15 @@ libxlDomainGetSchedulerParametersFlags(virDomainPtr dom, priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); - if (sched_id != XEN_SCHEDULER_CREDIT) { + if (sched_id != LIBXL_SCHEDULER_CREDIT) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Only 'credit' scheduler is supported")); goto cleanup; } - if (libxl_sched_credit_domain_get(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_get(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to get scheduler parameters for domain '%d'" " with libxenlight"), dom->id); @@ -3644,10 +3703,14 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, int nparams, unsigned int flags) { + (void)dom; + (void)params; + (void)nparams; + (void)flags; libxlDriverPrivatePtr driver = dom->conn->privateData; libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; - libxl_sched_credit sc_info; + libxl_sched_credit_domain sc_info; int sched_id; int i; int ret = -1; @@ -3677,20 +3740,15 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); - if (sched_id != XEN_SCHEDULER_CREDIT) { + if (sched_id != LIBXL_SCHEDULER_CREDIT) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Only 'credit' scheduler is supported")); goto cleanup; } - if (libxl_sched_credit_domain_get(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_get(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to get scheduler parameters for domain '%d'" " with libxenlight"), dom->id); @@ -3707,7 +3765,7 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, } } - if (libxl_sched_credit_domain_set(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_set(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set scheduler parameters for domain '%d'" " with libxenlight"), dom->id); -- 1.7.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 17:16:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17: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 ) id 1SSAU4-0001bM-Mm; Wed, 09 May 2012 17:15:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAU1-0001bH-Pu for xen-devel@lists.xen.org; Wed, 09 May 2012 17:15:26 +0000 Received: from [193.109.254.147:34677] by server-12.bemta-14.messagelabs.com id 3F/E0-05898-C26AAAF4; Wed, 09 May 2012 17:15:24 +0000 X-Env-Sender: dgdegra@tycho.nsa.gov X-Msg-Ref: server-6.tower-27.messagelabs.com!1336583716!2776811!1 X-Originating-IP: [63.239.67.9] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6072 invoked from network); 9 May 2012 17:15:17 -0000 Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9) by server-6.tower-27.messagelabs.com with SMTP; 9 May 2012 17:15:17 -0000 X-TM-IMSS-Message-ID: <33e4363e000c79df@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 33e4363e000c79df ; Wed, 9 May 2012 13:15:14 -0400 Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q49HEwwU017964; Wed, 9 May 2012 13:14:58 -0400 From: Daniel De Graaf To: Ian Jackson , Bamvor Jian Zhang Date: Wed, 9 May 2012 13:13:23 -0400 Message-Id: <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> X-Mailer: git-send-email 1.7.7.6 In-Reply-To: <20394.36444.760368.974206@mariner.uk.xensource.com> References: <20394.36444.760368.974206@mariner.uk.xensource.com> Cc: libvir-list@redhat.com, Daniel De Graaf , Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch changes libxl to use the interface in Xen 4.2. It is provided as an example, not intended to go in to libvirt as-is since it removes all support for libxl from Xen 4.1. It also still has some cruft (extra void casts on parameters) and the device model info population is not written. It has been tested with simple domain create/destroy. --- src/libxl/libxl_conf.c | 134 +++++++++------ src/libxl/libxl_conf.h | 8 +- src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- 3 files changed, 326 insertions(+), 246 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 62621f1..c5b5561 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -41,7 +41,7 @@ #include "capabilities.h" #include "libxl_driver.h" #include "libxl_conf.h" - +#include "libxl_utils.h" #define VIR_FROM_THIS VIR_FROM_LIBXL @@ -358,18 +358,29 @@ libxlMakeCapabilitiesInternal(const char *hostmachine, } static int -libxlMakeDomCreateInfo(virDomainDefPtr def, libxl_domain_create_info *c_info) +libxlMakeDomCreateInfo(libxlDriverPrivatePtr driver, virDomainDefPtr def, libxl_domain_create_info *c_info) { char uuidstr[VIR_UUID_STRING_BUFLEN]; - libxl_init_create_info(c_info); + libxl_domain_create_info_init(c_info); + + if (STREQ(def->os.type, "hvm")) + c_info->type = LIBXL_DOMAIN_TYPE_HVM; + else + c_info->type = LIBXL_DOMAIN_TYPE_PV; - c_info->hvm = STREQ(def->os.type, "hvm"); if ((c_info->name = strdup(def->name)) == NULL) { virReportOOMError(); goto error; } + if (def->seclabel.type == VIR_DOMAIN_SECLABEL_STATIC) { + if (libxl_flask_context_to_sid(driver->ctx, def->seclabel.label, strlen(def->seclabel.label), &c_info->ssidref)) { + libxlError(VIR_ERR_INTERNAL_ERROR, + _("libxenlight failed to resolve security label '%s'"), def->seclabel.label); + } + } + virUUIDFormat(def->uuid, uuidstr); if (libxl_uuid_from_string(&c_info->uuid, uuidstr) ) { libxlError(VIR_ERR_INTERNAL_ERROR, @@ -380,7 +391,7 @@ libxlMakeDomCreateInfo(virDomainDefPtr def, libxl_domain_create_info *c_info) return 0; error: - libxl_domain_create_info_destroy(c_info); + libxl_domain_create_info_dispose(c_info); return -1; } @@ -403,9 +414,9 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) return -1; } - libxl_init_build_info(b_info, &d_config->c_info); + libxl_domain_build_info_init(b_info); - b_info->hvm = hvm; + b_info->type = hvm ? LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV; b_info->max_vcpus = def->maxvcpus; if (def->vcpus == 32) b_info->cur_vcpus = (uint32_t) -1; @@ -424,16 +435,17 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) b_info->tsc_mode = 1; } } + b_info->sched_params.weight = 1000; b_info->max_memkb = def->mem.max_balloon; b_info->target_memkb = def->mem.cur_balloon; if (hvm) { - b_info->u.hvm.pae = def->features & (1 << VIR_DOMAIN_FEATURE_PAE); - b_info->u.hvm.apic = def->features & (1 << VIR_DOMAIN_FEATURE_APIC); - b_info->u.hvm.acpi = def->features & (1 << VIR_DOMAIN_FEATURE_ACPI); + libxl_defbool_set(&b_info->u.hvm.pae, def->features & (1 << VIR_DOMAIN_FEATURE_PAE)); + libxl_defbool_set(&b_info->u.hvm.apic, def->features & (1 << VIR_DOMAIN_FEATURE_APIC)); + libxl_defbool_set(&b_info->u.hvm.acpi, def->features & (1 << VIR_DOMAIN_FEATURE_ACPI)); for (i = 0; i < def->clock.ntimers; i++) { if (def->clock.timers[i]->name == VIR_DOMAIN_TIMER_NAME_HPET && def->clock.timers[i]->present == 1) { - b_info->u.hvm.hpet = 1; + libxl_defbool_set(&b_info->u.hvm.hpet, 1); } } @@ -454,7 +466,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) } } if (def->os.bootloaderArgs) { - if ((b_info->u.pv.bootloader_args = strdup(def->os.bootloaderArgs)) == NULL) { + // XXX may need to split these arguments on a delimiter + b_info->u.pv.bootloader_args = malloc(sizeof(char*)); + if (b_info->u.pv.bootloader_args == NULL) { + virReportOOMError(); + goto error; + } + b_info->u.pv.bootloader_args[0] = strdup(def->os.bootloaderArgs); + if (b_info->u.pv.bootloader_args[0] == NULL) { virReportOOMError(); goto error; } @@ -467,8 +486,8 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) } if (def->os.kernel) { /* libxl_init_build_info() sets kernel.path = strdup("hvmloader") */ - VIR_FREE(b_info->kernel.path); - if ((b_info->kernel.path = strdup(def->os.kernel)) == NULL) { + VIR_FREE(b_info->u.pv.kernel.path); + if ((b_info->u.pv.kernel.path = strdup(def->os.kernel)) == NULL) { virReportOOMError(); goto error; } @@ -484,7 +503,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) return 0; error: - libxl_domain_build_info_destroy(b_info); + libxl_domain_build_info_dispose(b_info); return -1; } @@ -507,30 +526,30 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, STREQ(l_disk->driverName, "tap2")) { if (l_disk->driverType) { if (STREQ(l_disk->driverType, "qcow")) { - x_disk->format = DISK_FORMAT_QCOW; - x_disk->backend = DISK_BACKEND_QDISK; + x_disk->format = LIBXL_DISK_FORMAT_QCOW; + x_disk->backend = LIBXL_DISK_BACKEND_QDISK; } else if (STREQ(l_disk->driverType, "qcow2")) { - x_disk->format = DISK_FORMAT_QCOW2; - x_disk->backend = DISK_BACKEND_QDISK; + x_disk->format = LIBXL_DISK_FORMAT_QCOW2; + x_disk->backend = LIBXL_DISK_BACKEND_QDISK; } else if (STREQ(l_disk->driverType, "vhd")) { - x_disk->format = DISK_FORMAT_VHD; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_VHD; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } else if (STREQ(l_disk->driverType, "aio") || STREQ(l_disk->driverType, "raw")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } } else { /* No subtype specified, default to raw/tap */ - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } } else if (STREQ(l_disk->driverName, "file")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_TAP; } else if (STREQ(l_disk->driverName, "phy")) { - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_PHY; + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_PHY; } else { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight does not support disk driver %s"), @@ -538,13 +557,14 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, return -1; } } else { - /* No driverName - default to raw/tap?? */ - x_disk->format = DISK_FORMAT_RAW; - x_disk->backend = DISK_BACKEND_TAP; + + /* No driverName - default to raw/phy?? */ + x_disk->format = LIBXL_DISK_FORMAT_RAW; + x_disk->backend = LIBXL_DISK_BACKEND_PHY; } - /* How to set unpluggable? */ - x_disk->unpluggable = 1; + /* XXX is this right? */ + x_disk->removable = 1; x_disk->readwrite = !l_disk->readonly; x_disk->is_cdrom = l_disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM ? 1 : 0; if (l_disk->transient) { @@ -553,7 +573,7 @@ libxlMakeDisk(virDomainDefPtr def, virDomainDiskDefPtr l_disk, return -1; } - x_disk->domid = def->id; + (void)def->id; return 0; } @@ -583,7 +603,7 @@ libxlMakeDiskList(virDomainDefPtr def, libxl_domain_config *d_config) error: for (i = 0; i < ndisks; i++) - libxl_device_disk_destroy(&x_disks[i]); + libxl_device_disk_dispose(&x_disks[i]); VIR_FREE(x_disks); return -1; } @@ -595,7 +615,7 @@ libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, // TODO: Where is mtu stored? //x_nics[i].mtu = 1492; - x_nic->domid = def->id; + (void)def->id; memcpy(x_nic->mac, l_nic->mac, sizeof(libxl_mac)); if (l_nic->model && !STREQ(l_nic->model, "netfront")) { @@ -603,9 +623,9 @@ libxlMakeNic(virDomainDefPtr def, virDomainNetDefPtr l_nic, virReportOOMError(); return -1; } - x_nic->nictype = NICTYPE_IOEMU; + x_nic->nictype = LIBXL_NIC_TYPE_IOEMU; } else { - x_nic->nictype = NICTYPE_VIF; + x_nic->nictype = LIBXL_NIC_TYPE_VIF; } if (l_nic->ifname && (x_nic->ifname = strdup(l_nic->ifname)) == NULL) { @@ -663,7 +683,7 @@ libxlMakeNicList(virDomainDefPtr def, libxl_domain_config *d_config) error: for (i = 0; i < nnics; i++) - libxl_device_nic_destroy(&x_nics[i]); + libxl_device_nic_dispose(&x_nics[i]); VIR_FREE(x_nics); return -1; } @@ -677,23 +697,23 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, switch (l_vfb->type) { case VIR_DOMAIN_GRAPHICS_TYPE_SDL: - x_vfb->sdl = 1; + libxl_defbool_set(&x_vfb->sdl.enable, 1); if (l_vfb->data.sdl.display && - (x_vfb->display = strdup(l_vfb->data.sdl.display)) == NULL) { + (x_vfb->sdl.display = strdup(l_vfb->data.sdl.display)) == NULL) { virReportOOMError(); return -1; } if (l_vfb->data.sdl.xauth && - (x_vfb->xauthority = + (x_vfb->sdl.xauthority = strdup(l_vfb->data.sdl.xauth)) == NULL) { virReportOOMError(); return -1; } break; case VIR_DOMAIN_GRAPHICS_TYPE_VNC: - x_vfb->vnc = 1; + libxl_defbool_set(&x_vfb->vnc.enable, 1); /* driver handles selection of free port */ - x_vfb->vncunused = 0; + libxl_defbool_set(&x_vfb->vnc.findunused, 0); if (l_vfb->data.vnc.autoport) { port = libxlNextFreeVncPort(driver, LIBXL_VNC_PORT_MIN); if (port < 0) { @@ -703,13 +723,13 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, } l_vfb->data.vnc.port = port; } - x_vfb->vncdisplay = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN; + x_vfb->vnc.display = l_vfb->data.vnc.port - LIBXL_VNC_PORT_MIN; listenAddr = virDomainGraphicsListenGetAddress(l_vfb, 0); if (listenAddr) { /* libxl_device_vfb_init() does strdup("127.0.0.1") */ - VIR_FREE(x_vfb->vnclisten); - if ((x_vfb->vnclisten = strdup(listenAddr)) == NULL) { + VIR_FREE(x_vfb->vnc.listen); + if ((x_vfb->vnc.listen = strdup(listenAddr)) == NULL) { virReportOOMError(); return -1; } @@ -722,7 +742,7 @@ libxlMakeVfb(libxlDriverPrivatePtr driver, virDomainDefPtr def, } break; } - x_vfb->domid = def->id; + (void) def->id; return 0; } @@ -750,8 +770,8 @@ libxlMakeVfbList(libxlDriverPrivatePtr driver, } for (i = 0; i < nvfbs; i++) { - libxl_device_vfb_init(&x_vfbs[i], i); - libxl_device_vkb_init(&x_vkbs[i], i); + libxl_device_vfb_init(&x_vfbs[i]); + libxl_device_vkb_init(&x_vkbs[i]); if (libxlMakeVfb(driver, def, l_vfbs[i], &x_vfbs[i]) < 0) goto error; @@ -765,14 +785,15 @@ libxlMakeVfbList(libxlDriverPrivatePtr driver, error: for (i = 0; i < nvfbs; i++) { - libxl_device_vfb_destroy(&x_vfbs[i]); - libxl_device_vkb_destroy(&x_vkbs[i]); + libxl_device_vfb_dispose(&x_vfbs[i]); + libxl_device_vkb_dispose(&x_vkbs[i]); } VIR_FREE(x_vfbs); VIR_FREE(x_vkbs); return -1; } +#if 0 static int libxlMakeChrdevStr(virDomainChrDefPtr def, char **buf) { @@ -906,6 +927,7 @@ error: libxl_device_model_info_destroy(dm_info); return -1; } +#endif virCapsPtr libxlMakeCapabilities(libxl_ctx *ctx) @@ -940,7 +962,7 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, virDomainDefPtr def, libxl_domain_config *d_config) { - if (libxlMakeDomCreateInfo(def, &d_config->c_info) < 0) + if (libxlMakeDomCreateInfo(driver, def, &d_config->c_info) < 0) return -1; if (libxlMakeDomBuildInfo(def, d_config) < 0) { @@ -959,9 +981,11 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, goto error; } +#if 0 if (libxlMakeDeviceModelInfo(def, d_config) < 0) { goto error; } +#endif d_config->on_reboot = def->onReboot; d_config->on_poweroff = def->onPoweroff; @@ -970,6 +994,6 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver, return 0; error: - libxl_domain_config_destroy(d_config); + libxl_domain_config_dispose(d_config); return -1; } diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 2820afb..73ab733 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -58,7 +58,7 @@ struct _libxlDriverPrivate { FILE *logger_file; xentoollog_logger *logger; /* libxl ctx for driver wide ops; getVersion, getNodeInfo, ... */ - libxl_ctx ctx; + libxl_ctx *ctx; virBitmapPtr reservedVNCPorts; virDomainObjList domains; @@ -77,10 +77,8 @@ typedef struct _libxlDomainObjPrivate libxlDomainObjPrivate; typedef libxlDomainObjPrivate *libxlDomainObjPrivatePtr; struct _libxlDomainObjPrivate { /* per domain libxl ctx */ - libxl_ctx ctx; - libxl_waiter *dWaiter; - int waiterFD; - int eventHdl; + libxl_ctx *ctx; + libxl_evgen_domain_death *deathW; }; # define LIBXL_SAVE_MAGIC "libvirt-xml\n \0 \r" diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 45bf1f8..8656f35 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -40,6 +40,7 @@ #include "memory.h" #include "uuid.h" #include "command.h" +#include "libxl.h" #include "libxl_driver.h" #include "libxl_conf.h" #include "xen_xm.h" @@ -79,6 +80,138 @@ libxlDriverUnlock(libxlDriverPrivatePtr driver) virMutexUnlock(&driver->lock); } +struct libxl_osevent_hook_fdinfo { + libxlDomainObjPrivatePtr priv; + void *xl_priv; + int watch; +}; + +static void cb_fd_event(int watch, int fd, int vir_events, void *fdinfo) +{ + struct libxl_osevent_hook_fdinfo *info = fdinfo; + int events = 0; + (void)watch; (void)fd; + if (vir_events & VIR_EVENT_HANDLE_READABLE) + events |= POLLIN; + if (vir_events & VIR_EVENT_HANDLE_WRITABLE) + events |= POLLOUT; + if (vir_events & VIR_EVENT_HANDLE_ERROR) + events |= POLLERR; + if (vir_events & VIR_EVENT_HANDLE_HANGUP) + events |= POLLHUP; + libxl_osevent_occurred_fd(info->priv->ctx, info->xl_priv, fd, 0, events); +} + +static void free_fdinfo(void *opaque) +{ + free(opaque); +} + +static int evhook_fd_register(void *priv, int fd, void **hndp, short events, void *xl_priv) +{ + int vir_events = VIR_EVENT_HANDLE_ERROR; + struct libxl_osevent_hook_fdinfo *fdinfo; + fdinfo = malloc(sizeof(fdinfo)); + fdinfo->priv = priv; + fdinfo->xl_priv = xl_priv; + *hndp = fdinfo; + + if (events & POLLIN) + vir_events |= VIR_EVENT_HANDLE_READABLE; + if (events & POLLOUT) + vir_events |= VIR_EVENT_HANDLE_WRITABLE; + fdinfo->watch = virEventAddHandle(fd, vir_events, cb_fd_event, fdinfo, free_fdinfo); + if (fdinfo->watch < 0) + return fdinfo->watch; + return 0; +} + +static int evhook_fd_modify(void *priv, int fd, void **hndp, short events) +{ + struct libxl_osevent_hook_fdinfo *fdinfo = *hndp; + (void)fd; (void)priv; + int vir_events = VIR_EVENT_HANDLE_ERROR; + if (events & POLLIN) + vir_events |= VIR_EVENT_HANDLE_READABLE; + if (events & POLLOUT) + vir_events |= VIR_EVENT_HANDLE_WRITABLE; + virEventUpdateHandle(fdinfo->watch, vir_events); + return 0; +} + +static void evhook_fd_deregister(void *priv, int fd, void *hnd) +{ + struct libxl_osevent_hook_fdinfo *fdinfo = hnd; + (void)priv; (void)fd; + virEventRemoveHandle(fdinfo->watch); +} + +struct libxl_osevent_hook_timerinfo { + libxlDomainObjPrivatePtr priv; + void *xl_priv; + int id; +}; + + +static void cb_timer(int timer, void *timer_v) +{ + struct libxl_osevent_hook_timerinfo *timer_info = timer_v; + (void)timer; + libxl_osevent_occurred_timeout(timer_info->priv->ctx, timer_info->xl_priv); +} + +static void timer_info_free(void* obj) +{ + free(obj); +} + +static int evhook_timeout_register(void *priv, void **hndp, struct timeval abs_t, void *for_libxl) +{ + struct timeval now; + struct libxl_osevent_hook_timerinfo *timer_info; + int timeout, timer_id; + timer_info = malloc(sizeof(*timer_info)); + gettimeofday(&now, NULL); + timeout = (abs_t.tv_usec - now.tv_usec) / 1000; + timeout += (abs_t.tv_sec - now.tv_sec) * 1000; + timer_id = virEventAddTimeout(timeout, cb_timer, timer_info, timer_info_free); + if (timer_id < 0) + return timer_id; + timer_info->priv = priv; + timer_info->xl_priv = for_libxl; + timer_info->id = timer_id; + *hndp = timer_info; + return 0; +} + +static int evhook_timeout_modify(void *priv, void **hndp, struct timeval abs_t) +{ + struct timeval now; + int timeout; + struct libxl_osevent_hook_timerinfo *timer_info = *hndp; + (void)priv; + gettimeofday(&now, NULL); + timeout = (abs_t.tv_usec - now.tv_usec) / 1000; + timeout += (abs_t.tv_sec - now.tv_sec) * 1000; + virEventUpdateTimeout(timer_info->id, timeout); + return 0; +} + +static void evhook_timeout_deregister(void *priv, void *hnd) { + struct libxl_osevent_hook_timerinfo *timer_info = hnd; + virEventRemoveTimeout(timer_info->id); + (void)priv; +} + +static const libxl_osevent_hooks event_callbacks = { + .fd_register = evhook_fd_register, + .fd_modify = evhook_fd_modify, + .fd_deregister = evhook_fd_deregister, + .timeout_register = evhook_timeout_register, + .timeout_modify = evhook_timeout_modify, + .timeout_deregister = evhook_timeout_deregister, +}; + static void * libxlDomainObjPrivateAlloc(void) { @@ -87,9 +220,9 @@ libxlDomainObjPrivateAlloc(void) if (VIR_ALLOC(priv) < 0) return NULL; - libxl_ctx_init(&priv->ctx, LIBXL_VERSION, libxl_driver->logger); - priv->waiterFD = -1; - priv->eventHdl = -1; + libxl_ctx_alloc(&priv->ctx, LIBXL_VERSION, 0, libxl_driver->logger); + priv->deathW = NULL; + libxl_osevent_register_hooks(priv->ctx, &event_callbacks, priv); return priv; } @@ -99,16 +232,12 @@ libxlDomainObjPrivateFree(void *data) { libxlDomainObjPrivatePtr priv = data; - if (priv->eventHdl >= 0) - virEventRemoveHandle(priv->eventHdl); - - if (priv->dWaiter) { - libxl_stop_waiting(&priv->ctx, priv->dWaiter); - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); + if (priv->deathW) { + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + VIR_FREE(priv->deathW); } - libxl_ctx_free(&priv->ctx); + libxl_ctx_free(priv->ctx); VIR_FREE(priv); } @@ -120,17 +249,6 @@ libxlDomainEventQueue(libxlDriverPrivatePtr driver, virDomainEventPtr event) virDomainEventStateQueue(driver->domainEventState, event); } -/* - * Remove reference to domain object. - */ -static void -libxlDomainObjUnref(void *data) -{ - virDomainObjPtr vm = data; - - ignore_value(virDomainObjUnref(vm)); -} - static void libxlAutostartDomain(void *payload, const void *name ATTRIBUTE_UNUSED, void *opaque) @@ -161,13 +279,13 @@ libxlDoNodeGetInfo(libxlDriverPrivatePtr driver, virNodeInfoPtr info) const libxl_version_info* ver_info; struct utsname utsname; - if (libxl_get_physinfo(&driver->ctx, &phy_info)) { + if (libxl_get_physinfo(driver->ctx, &phy_info)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_physinfo_info failed")); return -1; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_version_info failed")); return -1; @@ -291,15 +409,9 @@ libxlVmCleanup(libxlDriverPrivatePtr driver, char *file; int i; - if (priv->eventHdl >= 0) { - virEventRemoveHandle(priv->eventHdl); - priv->eventHdl = -1; - } - - if (priv->dWaiter) { - libxl_stop_waiting(&priv->ctx, priv->dWaiter); - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); + if (priv->deathW) { + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + priv->deathW = NULL; } if (vm->persistent) { @@ -350,12 +462,11 @@ libxlVmCleanup(libxlDriverPrivatePtr driver, static int libxlVmReap(libxlDriverPrivatePtr driver, virDomainObjPtr vm, - int force, virDomainShutoffReason reason) { libxlDomainObjPrivatePtr priv = vm->privateData; - if (libxl_domain_destroy(&priv->ctx, vm->def->id, force) < 0) { + if (libxl_domain_destroy(priv->ctx, vm->def->id) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Unable to cleanup domain %d"), vm->def->id); return -1; @@ -368,56 +479,26 @@ libxlVmReap(libxlDriverPrivatePtr driver, /* * Handle previously registered event notification from libxenlight */ -static void libxlEventHandler(int watch, - int fd, - int events, - void *data) +static void libxlEventHandler(void *data, const libxl_event *event) { libxlDriverPrivatePtr driver = libxl_driver; virDomainObjPtr vm = data; - libxlDomainObjPrivatePtr priv; virDomainEventPtr dom_event = NULL; - libxl_event event; - libxl_dominfo info; libxlDriverLock(driver); virDomainObjLock(vm); libxlDriverUnlock(driver); - priv = vm->privateData; - - memset(&event, 0, sizeof(event)); - memset(&info, 0, sizeof(info)); - - if (priv->waiterFD != fd || priv->eventHdl != watch) { - virEventRemoveHandle(watch); - priv->eventHdl = -1; - goto cleanup; - } - - if (!(events & VIR_EVENT_HANDLE_READABLE)) - goto cleanup; - - if (libxl_get_event(&priv->ctx, &event)) - goto cleanup; - - if (event.type == LIBXL_EVENT_DOMAIN_DEATH) { + if (event->type == LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN) { virDomainShutoffReason reason; - /* libxl_event_get_domain_death_info returns 1 if death - * event was for this domid */ - if (libxl_event_get_domain_death_info(&priv->ctx, - vm->def->id, - &event, - &info) != 1) + if (event->domid != vm->def->id) goto cleanup; - virEventRemoveHandle(watch); - priv->eventHdl = -1; - switch (info.shutdown_reason) { - case SHUTDOWN_poweroff: - case SHUTDOWN_crash: - if (info.shutdown_reason == SHUTDOWN_crash) { + switch (event->u.domain_shutdown.shutdown_reason) { + case LIBXL_SHUTDOWN_REASON_POWEROFF: + case LIBXL_SHUTDOWN_REASON_CRASH: + if (event->u.domain_shutdown.shutdown_reason == LIBXL_SHUTDOWN_REASON_CRASH) { dom_event = virDomainEventNewFromObj(vm, VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_CRASHED); @@ -425,18 +506,18 @@ static void libxlEventHandler(int watch, } else { reason = VIR_DOMAIN_SHUTOFF_SHUTDOWN; } - libxlVmReap(driver, vm, 0, reason); + libxlVmReap(driver, vm, reason); if (!vm->persistent) { virDomainRemoveInactive(&driver->domains, vm); vm = NULL; } break; - case SHUTDOWN_reboot: - libxlVmReap(driver, vm, 0, VIR_DOMAIN_SHUTOFF_SHUTDOWN); + case LIBXL_SHUTDOWN_REASON_REBOOT: + libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN); libxlVmStart(driver, vm, 0, -1); break; default: - VIR_INFO("Unhandled shutdown_reason %d", info.shutdown_reason); + VIR_INFO("Unhandled shutdown_reason %d", event->u.domain_shutdown.shutdown_reason); break; } } @@ -449,9 +530,14 @@ cleanup: libxlDomainEventQueue(driver, dom_event); libxlDriverUnlock(driver); } - libxl_free_event(&event); } +static const struct libxl_event_hooks ev_hooks = { + .event_occurs_mask = LIBXL_EVENTMASK_ALL, + .event_occurs = libxlEventHandler, + .disaster = NULL, +}; + /* * Register domain events with libxenlight and insert event handles * in libvirt's event loop. @@ -460,40 +546,18 @@ static int libxlCreateDomEvents(virDomainObjPtr vm) { libxlDomainObjPrivatePtr priv = vm->privateData; - int fd; - - if (VIR_ALLOC(priv->dWaiter) < 0) { - virReportOOMError(); - return -1; - } - if (libxl_wait_for_domain_death(&priv->ctx, vm->def->id, priv->dWaiter)) - goto error; + libxl_event_register_callbacks(priv->ctx, &ev_hooks, vm); - libxl_get_wait_fd(&priv->ctx, &fd); - if (fd < 0) + if (libxl_evenable_domain_death(priv->ctx, vm->def->id, 0, &priv->deathW)) goto error; - priv->waiterFD = fd; - /* Add a reference to the domain object while it is injected in - * the event loop. - */ - virDomainObjRef(vm); - if ((priv->eventHdl = virEventAddHandle( - fd, - VIR_EVENT_HANDLE_READABLE | VIR_EVENT_HANDLE_ERROR, - libxlEventHandler, - vm, libxlDomainObjUnref)) < 0) { - ignore_value(virDomainObjUnref(vm)); - goto error; - } - return 0; error: - libxl_free_waiter(priv->dWaiter); - VIR_FREE(priv->dWaiter); - priv->eventHdl = -1; + if (priv->deathW) + libxl_evdisable_domain_death(priv->ctx, priv->deathW); + free(priv->deathW); return -1; } @@ -534,7 +598,7 @@ libxlDomainSetVcpuAffinites(libxlDriverPrivatePtr driver, virDomainObjPtr vm) map.size = cpumaplen; map.map = cpumap; - if (libxl_set_vcpuaffinity(&priv->ctx, def->id, vcpu, &map) != 0) { + if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to pin vcpu '%d' with libxenlight"), vcpu); goto cleanup; @@ -560,11 +624,10 @@ libxlFreeMem(libxlDomainObjPrivatePtr priv, libxl_domain_config *d_config) int tries = 3; int wait_secs = 10; - if ((ret = libxl_domain_need_memory(&priv->ctx, &d_config->b_info, - &d_config->dm_info, + if ((ret = libxl_domain_need_memory(priv->ctx, &d_config->b_info, &needed_mem)) >= 0) { for (i = 0; i < tries; ++i) { - if ((ret = libxl_get_free_memory(&priv->ctx, &free_mem)) < 0) + if ((ret = libxl_get_free_memory(priv->ctx, &free_mem)) < 0) break; if (free_mem >= needed_mem) { @@ -572,17 +635,17 @@ libxlFreeMem(libxlDomainObjPrivatePtr priv, libxl_domain_config *d_config) break; } - if ((ret = libxl_set_memory_target(&priv->ctx, 0, + if ((ret = libxl_set_memory_target(priv->ctx, 0, free_mem - needed_mem, /* relative */ 1, 0)) < 0) break; - ret = libxl_wait_for_free_memory(&priv->ctx, 0, needed_mem, + ret = libxl_wait_for_free_memory(priv->ctx, 0, needed_mem, wait_secs); if (ret == 0 || ret != ERROR_NOMEM) break; - if ((ret = libxl_wait_for_memory_target(&priv->ctx, 0, 1)) < 0) + if ((ret = libxl_wait_for_memory_target(priv->ctx, 0, 1)) < 0) break; } } @@ -651,7 +714,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, VIR_FREE(managed_save_path); } - memset(&d_config, 0, sizeof(d_config)); + libxl_domain_config_init(&d_config); if (libxlBuildDomainConfig(driver, vm->def, &d_config) < 0 ) return -1; @@ -664,10 +727,10 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, } if (restore_fd < 0) - ret = libxl_domain_create_new(&priv->ctx, &d_config, + ret = libxl_domain_create_new(priv->ctx, &d_config, NULL, &child_console_pid, &domid); else - ret = libxl_domain_create_restore(&priv->ctx, &d_config, NULL, + ret = libxl_domain_create_restore(priv->ctx, &d_config, NULL, &child_console_pid, &domid, restore_fd); @@ -687,7 +750,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, if ((dom_xml = virDomainDefFormat(vm->def, 0)) == NULL) goto error; - if (libxl_userdata_store(&priv->ctx, domid, "libvirt-xml", + if (libxl_userdata_store(priv->ctx, domid, "libvirt-xml", (uint8_t *)dom_xml, strlen(dom_xml) + 1)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to store userdata")); @@ -701,7 +764,7 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, goto error; if (!start_paused) { - libxl_domain_unpause(&priv->ctx, domid); + libxl_domain_unpause(priv->ctx, domid); virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, VIR_DOMAIN_RUNNING_BOOTED); } else { virDomainObjSetState(vm, VIR_DOMAIN_PAUSED, VIR_DOMAIN_PAUSED_USER); @@ -717,18 +780,18 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, VIR_DOMAIN_EVENT_STARTED_RESTORED); libxlDomainEventQueue(driver, event); - libxl_domain_config_destroy(&d_config); + libxl_domain_config_dispose(&d_config); VIR_FREE(dom_xml); VIR_FORCE_CLOSE(managed_save_fd); return 0; error: if (domid > 0) { - libxl_domain_destroy(&priv->ctx, domid, 0); + libxl_domain_destroy(priv->ctx, domid); vm->def->id = -1; virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, VIR_DOMAIN_SHUTOFF_FAILED); } - libxl_domain_config_destroy(&d_config); + libxl_domain_config_dispose(&d_config); VIR_FREE(dom_xml); VIR_FREE(managed_save_path); virDomainDefFree(def); @@ -756,7 +819,7 @@ libxlReconnectDomain(void *payload, virDomainObjLock(vm); /* Does domain still exist? */ - rc = libxl_domain_info(&driver->ctx, &d_info, vm->def->id); + rc = libxl_domain_info(driver->ctx, &d_info, vm->def->id); if (rc == ERROR_INVAL) { goto out; } else if (rc != 0) { @@ -766,7 +829,7 @@ libxlReconnectDomain(void *payload, } /* Is this a domain that was under libvirt control? */ - if (libxl_userdata_retrieve(&driver->ctx, vm->def->id, + if (libxl_userdata_retrieve(driver->ctx, vm->def->id, "libvirt-xml", &data, &len)) { VIR_DEBUG("libxl_userdata_retrieve failed, ignoring domain %d", vm->def->id); goto out; @@ -804,7 +867,7 @@ libxlShutdown(void) libxlDriverLock(libxl_driver); virCapabilitiesFree(libxl_driver->caps); virDomainObjListDeinit(&libxl_driver->domains); - libxl_ctx_free(&libxl_driver->ctx); + libxl_ctx_free(libxl_driver->ctx); xtl_logger_destroy(libxl_driver->logger); if (libxl_driver->logger_file) VIR_FORCE_FCLOSE(libxl_driver->logger_file); @@ -937,14 +1000,14 @@ libxlStartup(int privileged) { goto fail; } - if (libxl_ctx_init(&libxl_driver->ctx, - LIBXL_VERSION, + if (libxl_ctx_alloc(&libxl_driver->ctx, + LIBXL_VERSION, 0, libxl_driver->logger)) { VIR_INFO("cannot initialize libxenlight context, probably not running in a Xen Dom0, disabling driver"); goto fail; } - if ((ver_info = libxl_get_version_info(&libxl_driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(libxl_driver->ctx)) == NULL) { VIR_INFO("cannot version information from libxenlight, disabling driver"); goto fail; } @@ -952,7 +1015,7 @@ libxlStartup(int privileged) { (ver_info->xen_version_minor * 1000); if ((libxl_driver->caps = - libxlMakeCapabilities(&libxl_driver->ctx)) == NULL) { + libxlMakeCapabilities(libxl_driver->ctx)) == NULL) { VIR_ERROR(_("cannot create capabilities for libxenlight")); goto error; } @@ -1112,7 +1175,7 @@ libxlGetMaxVcpus(virConnectPtr conn, const char *type ATTRIBUTE_UNUSED) int ret; libxlDriverPrivatePtr driver = conn->privateData; - ret = libxl_get_max_cpus(&driver->ctx); + ret = libxl_get_max_cpus(driver->ctx); /* libxl_get_max_cpus() will return 0 if there were any failures, e.g. xc_physinfo() failing */ if (ret == 0) @@ -1317,7 +1380,7 @@ libxlDomainSuspend(virDomainPtr dom) priv = vm->privateData; if (virDomainObjGetState(vm, NULL) != VIR_DOMAIN_PAUSED) { - if (libxl_domain_pause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_pause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to suspend domain '%d' with libxenlight"), dom->id); @@ -1376,7 +1439,7 @@ libxlDomainResume(virDomainPtr dom) priv = vm->privateData; if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_PAUSED) { - if (libxl_domain_unpause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_unpause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to resume domain '%d' with libxenlight"), dom->id); @@ -1433,7 +1496,7 @@ libxlDomainShutdownFlags(virDomainPtr dom, unsigned int flags) } priv = vm->privateData; - if (libxl_domain_shutdown(&priv->ctx, dom->id, LIBXL_DOM_REQ_POWEROFF) != 0) { + if (libxl_domain_shutdown(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to shutdown domain '%d' with libxenlight"), dom->id); @@ -1486,7 +1549,7 @@ libxlDomainReboot(virDomainPtr dom, unsigned int flags) } priv = vm->privateData; - if (libxl_domain_shutdown(&priv->ctx, dom->id, LIBXL_DOM_REQ_REBOOT) != 0) { + if (libxl_domain_reboot(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to reboot domain '%d' with libxenlight"), dom->id); @@ -1531,7 +1594,7 @@ libxlDomainDestroyFlags(virDomainPtr dom, event = virDomainEventNewFromObj(vm,VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_DESTROYED); - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_DESTROYED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_DESTROYED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), dom->id); goto cleanup; @@ -1669,7 +1732,7 @@ libxlDomainSetMemoryFlags(virDomainPtr dom, unsigned long newmem, if (flags & VIR_DOMAIN_MEM_LIVE) { priv = vm->privateData; - if (libxl_domain_setmaxmem(&priv->ctx, dom->id, newmem) < 0) { + if (libxl_domain_setmaxmem(priv->ctx, dom->id, newmem) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set maximum memory for domain '%d'" " with libxenlight"), dom->id); @@ -1698,7 +1761,7 @@ libxlDomainSetMemoryFlags(virDomainPtr dom, unsigned long newmem, if (flags & VIR_DOMAIN_MEM_LIVE) { priv = vm->privateData; - if (libxl_set_memory_target(&priv->ctx, dom->id, newmem, 0, + if (libxl_set_memory_target(priv->ctx, dom->id, newmem, 0, /* force */ 1) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set memory for domain '%d'" @@ -1758,7 +1821,7 @@ libxlDomainGetInfo(virDomainPtr dom, virDomainInfoPtr info) info->memory = vm->def->mem.cur_balloon; info->maxMem = vm->def->mem.max_balloon; } else { - if (libxl_domain_info(&driver->ctx, &d_info, dom->id) != 0) { + if (libxl_domain_info(driver->ctx, &d_info, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_domain_info failed for domain '%d'"), dom->id); goto cleanup; @@ -1858,7 +1921,7 @@ libxlDoDomainSave(libxlDriverPrivatePtr driver, virDomainObjPtr vm, goto cleanup; } - if (libxl_domain_suspend(&priv->ctx, NULL, vm->def->id, fd) != 0) { + if (libxl_domain_suspend(priv->ctx, NULL, vm->def->id, fd) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to save domain '%d' with libxenlight"), vm->def->id); @@ -1868,7 +1931,7 @@ libxlDoDomainSave(libxlDriverPrivatePtr driver, virDomainObjPtr vm, event = virDomainEventNewFromObj(vm, VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_SAVED); - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_SAVED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_SAVED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), vm->def->id); goto cleanup; @@ -2023,7 +2086,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) if (!(flags & VIR_DUMP_LIVE) && virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) { - if (libxl_domain_pause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_pause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Before dumping core, failed to suspend domain '%d'" " with libxenlight"), @@ -2034,7 +2097,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) paused = true; } - if (libxl_domain_core_dump(&priv->ctx, dom->id, to) != 0) { + if (libxl_domain_core_dump(priv->ctx, dom->id, to) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to dump core of domain '%d' with libxenlight"), dom->id); @@ -2043,7 +2106,7 @@ libxlDomainCoreDump(virDomainPtr dom, const char *to, unsigned int flags) libxlDriverLock(driver); if (flags & VIR_DUMP_CRASH) { - if (libxlVmReap(driver, vm, 1, VIR_DOMAIN_SHUTOFF_CRASHED) != 0) { + if (libxlVmReap(driver, vm, VIR_DOMAIN_SHUTOFF_CRASHED) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to destroy domain '%d'"), dom->id); goto cleanup_unlock; @@ -2064,7 +2127,7 @@ cleanup_unlock: libxlDriverUnlock(driver); cleanup_unpause: if (virDomainObjIsActive(vm) && paused) { - if (libxl_domain_unpause(&priv->ctx, dom->id) != 0) { + if (libxl_domain_unpause(priv->ctx, dom->id) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("After dumping core, failed to resume domain '%d' with" " libxenlight"), dom->id); @@ -2301,7 +2364,7 @@ libxlDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, break; case VIR_DOMAIN_VCPU_LIVE: - if (libxl_set_vcpuonline(&priv->ctx, dom->id, &map) != 0) { + if (libxl_set_vcpuonline(priv->ctx, dom->id, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set vcpus for domain '%d'" " with libxenlight"), dom->id); @@ -2310,7 +2373,7 @@ libxlDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, break; case VIR_DOMAIN_VCPU_LIVE | VIR_DOMAIN_VCPU_CONFIG: - if (libxl_set_vcpuonline(&priv->ctx, dom->id, &map) != 0) { + if (libxl_set_vcpuonline(priv->ctx, dom->id, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set vcpus for domain '%d'" " with libxenlight"), dom->id); @@ -2427,7 +2490,7 @@ libxlDomainPinVcpu(virDomainPtr dom, unsigned int vcpu, unsigned char *cpumap, map.size = maplen; map.map = cpumap; - if (libxl_set_vcpuaffinity(&priv->ctx, dom->id, vcpu, &map) != 0) { + if (libxl_set_vcpuaffinity(priv->ctx, dom->id, vcpu, &map) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to pin vcpu '%d' with libxenlight"), vcpu); goto cleanup; @@ -2479,7 +2542,7 @@ libxlDomainGetVcpus(virDomainPtr dom, virVcpuInfoPtr info, int maxinfo, } priv = vm->privateData; - if ((vcpuinfo = libxl_list_vcpu(&priv->ctx, dom->id, &maxcpu, + if ((vcpuinfo = libxl_list_vcpu(priv->ctx, dom->id, &maxcpu, &hostcpus)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to list vcpus for domain '%d' with libxenlight"), @@ -2506,7 +2569,7 @@ libxlDomainGetVcpus(virDomainPtr dom, virVcpuInfoPtr info, int maxinfo, MIN(maplen, vcpuinfo[i].cpumap.size)); } - libxl_vcpuinfo_destroy(&vcpuinfo[i]); + libxl_vcpuinfo_dispose(&vcpuinfo[i]); } VIR_FREE(vcpuinfo); @@ -2564,7 +2627,7 @@ libxlDomainXMLFromNative(virConnectPtr conn, const char * nativeFormat, goto cleanup; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { VIR_ERROR(_("cannot get version information from libxenlight")); goto cleanup; } @@ -2607,7 +2670,7 @@ libxlDomainXMLToNative(virConnectPtr conn, const char * nativeFormat, goto cleanup; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { VIR_ERROR(_("cannot get version information from libxenlight")); goto cleanup; } @@ -2870,7 +2933,7 @@ libxlDomainChangeEjectableMedia(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_cdrom_insert(&priv->ctx, vm->def->id, &x_disk)) < 0) { + if ((ret = libxl_cdrom_insert(priv->ctx, vm->def->id, &x_disk)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to change media for disk '%s'"), disk->dst); @@ -2925,7 +2988,7 @@ libxlDomainAttachDeviceDiskLive(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, l_disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_device_disk_add(&priv->ctx, vm->def->id, + if ((ret = libxl_device_disk_add(priv->ctx, vm->def->id, &x_disk)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to attach disk '%s'"), @@ -2959,7 +3022,6 @@ libxlDomainDetachDeviceDiskLive(libxlDomainObjPrivatePtr priv, virDomainDiskDefPtr l_disk = NULL; libxl_device_disk x_disk; int i; - int wait_secs = 2; int ret = -1; switch (dev->data.disk->device) { @@ -2979,8 +3041,7 @@ libxlDomainDetachDeviceDiskLive(libxlDomainObjPrivatePtr priv, if (libxlMakeDisk(vm->def, l_disk, &x_disk) < 0) goto cleanup; - if ((ret = libxl_device_disk_del(&priv->ctx, &x_disk, - wait_secs)) < 0) { + if ((ret = libxl_device_disk_remove(priv->ctx, vm->def->id, &x_disk, NULL)) < 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxenlight failed to detach disk '%s'"), l_disk->dst); @@ -3355,12 +3416,12 @@ libxlNodeGetFreeMemory(virConnectPtr conn) const libxl_version_info* ver_info; libxlDriverPrivatePtr driver = conn->privateData; - if (libxl_get_physinfo(&driver->ctx, &phy_info)) { + if (libxl_get_physinfo(driver->ctx, &phy_info)) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_physinfo_info failed")); return 0; } - if ((ver_info = libxl_get_version_info(&driver->ctx)) == NULL) { + if ((ver_info = libxl_get_version_info(driver->ctx)) == NULL) { libxlError(VIR_ERR_INTERNAL_ERROR, _("libxl_get_version_info failed")); return 0; } @@ -3506,7 +3567,7 @@ libxlDomainGetSchedulerType(virDomainPtr dom, int *nparams) libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; char * ret = NULL; - int sched_id; + libxl_scheduler sched_id; libxlDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, dom->uuid); @@ -3523,31 +3584,29 @@ libxlDomainGetSchedulerType(virDomainPtr dom, int *nparams) } priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); if (nparams) *nparams = 0; switch(sched_id) { - case XEN_SCHEDULER_SEDF: + case LIBXL_SCHEDULER_SEDF: ret = strdup("sedf"); break; - case XEN_SCHEDULER_CREDIT: + case LIBXL_SCHEDULER_CREDIT: ret = strdup("credit"); if (nparams) *nparams = XEN_SCHED_CREDIT_NPARAM; break; - case XEN_SCHEDULER_CREDIT2: + case LIBXL_SCHEDULER_CREDIT2: ret = strdup("credit2"); break; - case XEN_SCHEDULER_ARINC653: + case LIBXL_SCHEDULER_ARINC653: ret = strdup("arinc653"); break; default: + libxlError(VIR_ERR_INTERNAL_ERROR, + _("Failed to get scheduler id for domain '%d'" + " with libxenlight"), dom->id); goto cleanup; } @@ -3566,11 +3625,16 @@ libxlDomainGetSchedulerParametersFlags(virDomainPtr dom, int *nparams, unsigned int flags) { + (void)dom; + (void)params; + (void)nparams; + (void)flags; + libxlDriverPrivatePtr driver = dom->conn->privateData; libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; - libxl_sched_credit sc_info; - int sched_id; + libxl_sched_credit_domain sc_info; + libxl_scheduler sched_id; int ret = -1; virCheckFlags(0, -1); @@ -3591,20 +3655,15 @@ libxlDomainGetSchedulerParametersFlags(virDomainPtr dom, priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); - if (sched_id != XEN_SCHEDULER_CREDIT) { + if (sched_id != LIBXL_SCHEDULER_CREDIT) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Only 'credit' scheduler is supported")); goto cleanup; } - if (libxl_sched_credit_domain_get(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_get(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to get scheduler parameters for domain '%d'" " with libxenlight"), dom->id); @@ -3644,10 +3703,14 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, int nparams, unsigned int flags) { + (void)dom; + (void)params; + (void)nparams; + (void)flags; libxlDriverPrivatePtr driver = dom->conn->privateData; libxlDomainObjPrivatePtr priv; virDomainObjPtr vm; - libxl_sched_credit sc_info; + libxl_sched_credit_domain sc_info; int sched_id; int i; int ret = -1; @@ -3677,20 +3740,15 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, priv = vm->privateData; - if ((sched_id = libxl_get_sched_id(&priv->ctx)) < 0) { - libxlError(VIR_ERR_INTERNAL_ERROR, - _("Failed to get scheduler id for domain '%d'" - " with libxenlight"), dom->id); - goto cleanup; - } + sched_id = libxl_get_scheduler(priv->ctx); - if (sched_id != XEN_SCHEDULER_CREDIT) { + if (sched_id != LIBXL_SCHEDULER_CREDIT) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Only 'credit' scheduler is supported")); goto cleanup; } - if (libxl_sched_credit_domain_get(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_get(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to get scheduler parameters for domain '%d'" " with libxenlight"), dom->id); @@ -3707,7 +3765,7 @@ libxlDomainSetSchedulerParametersFlags(virDomainPtr dom, } } - if (libxl_sched_credit_domain_set(&priv->ctx, dom->id, &sc_info) != 0) { + if (libxl_sched_credit_domain_set(priv->ctx, dom->id, &sc_info) != 0) { libxlError(VIR_ERR_INTERNAL_ERROR, _("Failed to set scheduler parameters for domain '%d'" " with libxenlight"), dom->id); -- 1.7.7.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 17:45:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17: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 ) id 1SSAx6-0001pH-K6; Wed, 09 May 2012 17:45:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAx5-0001pC-2A for xen-devel@lists.xen.org; Wed, 09 May 2012 17:45:27 +0000 Received: from [85.158.139.83:22243] by server-10.bemta-5.messagelabs.com id 10/56-08260-63DAAAF4; Wed, 09 May 2012 17:45:26 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336585523!27441986!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE5MzAw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21621 invoked from network); 9 May 2012 17:45:25 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 17:45:25 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q49HiUxb024230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 17:44:31 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 q49HiTYi006111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:44:29 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 q49HiPGh016264; Wed, 9 May 2012 12:44:27 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 May 2012 10:44:25 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 582B64031D; Wed, 9 May 2012 13:38:36 -0400 (EDT) Date: Wed, 9 May 2012 13:38:36 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich , law@redhat.com Message-ID: <20120509173836.GB9094@phenom.dumpdata.com> References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAA8E96020000780008288F@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, haitao.shan@intel.com, stefan.bader@canonical.com, xen-devel , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, 2012 at 02:34:46PM +0100, Jan Beulich wrote: > >>> On 09.05.12 at 15:11, Konrad Rzeszutek Wilk wrote: > > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > >> On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > >> > After some digging around, it looks like this is an Ubuntu 11.10 only > > patch: > >> > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fb > > a59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b82416 > > 0b > >> > >> > >> Ugh. There are looks to be a bug in Fedora as well: > > https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > >> > > > > CC-ing Intel. It seems that the userspace programs are crashingon > > Sandybridge machines even if 'xsave=0' is provided on the command line. > > Any advice? > > Going through the bug, all I can see are bogus attempts to pass > "xsave=" (with value 0 or 1) to the kernel. That's a hypervisor > option though, and the only kernel option that's relevant here > is "noxsave" afaik. > > Further, when the hypervisor has xsave support enabled, there's > (in the pv case) nothing the kernel can do to hide the functionality > from applications, as the hardware's CR4.OSXSAVE will be set, and > hence CPUID.OSXSAVE will be too. So "noxsave" on the kernel > command line when "xsave=1" (or xsave enabled by default as in > 4.2) just doesn't make any sense. > > And finally one always has to keep in mind that there is this nice > glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE > when trying to determine whether AVX or FMA is available. It has this: 146 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) 148 { 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSXSAVE) != 0 151 && ({ unsigned int xcrlow; 152 unsigned int xcrhigh; 153 asm ("xgetbv" 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); 155 (xcrlow & 6) == 6; })) 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; 157 } And when I ran a little silly C program (attached) to probe the CPUID flags, I got: /root/test-xsave SSE3 CMOV AVX XSAVE Trying XGETBV Illegal instruction (core dumped) Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV guest still crashes on that machine) - which means that in multi-lib the bit_YMM_Usable is _not_ set. But then looking at the sources I see: # ifdef USE_AS_STRCASECMP_L 102 ENTRY(__strcasecmp) 103 .type __strcasecmp, @gnu_indirect_function 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) 105 jne 1f 106 call __init_cpu_features 107 1: 108 # ifdef HAVE_AVX_SUPPORT 109 leaq __strcasecmp_avx(%rip), %rax 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) 111 jnz 2f 112 # endif which would imply that the AVX bit is sampled here instead of the YMM one. Perhaps this is needed: --- glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c.orig 2012-05-09 13:32:10.832000122 -0400 +++ glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c 2012-05-09 13:33:31.043000138 -0400 @@ -154,6 +154,8 @@ __init_cpu_features (void) : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); (xcrlow & 6) == 6; })) __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; + else + __cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ~bit_AVX; } __cpu_features.family = family; ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 17:45:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17: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 ) id 1SSAx6-0001pH-K6; Wed, 09 May 2012 17:45:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAx5-0001pC-2A for xen-devel@lists.xen.org; Wed, 09 May 2012 17:45:27 +0000 Received: from [85.158.139.83:22243] by server-10.bemta-5.messagelabs.com id 10/56-08260-63DAAAF4; Wed, 09 May 2012 17:45:26 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336585523!27441986!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE5MzAw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21621 invoked from network); 9 May 2012 17:45:25 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 17:45:25 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q49HiUxb024230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 17:44:31 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 q49HiTYi006111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:44:29 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 q49HiPGh016264; Wed, 9 May 2012 12:44:27 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 May 2012 10:44:25 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 582B64031D; Wed, 9 May 2012 13:38:36 -0400 (EDT) Date: Wed, 9 May 2012 13:38:36 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich , law@redhat.com Message-ID: <20120509173836.GB9094@phenom.dumpdata.com> References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAA8E96020000780008288F@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, haitao.shan@intel.com, stefan.bader@canonical.com, xen-devel , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, 2012 at 02:34:46PM +0100, Jan Beulich wrote: > >>> On 09.05.12 at 15:11, Konrad Rzeszutek Wilk wrote: > > On Tue, May 08, 2012 at 08:35:11PM -0400, Konrad Rzeszutek Wilk wrote: > >> On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > >> > After some digging around, it looks like this is an Ubuntu 11.10 only > > patch: > >> > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fb > > a59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b82416 > > 0b > >> > >> > >> Ugh. There are looks to be a bug in Fedora as well: > > https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this. > >> > > > > CC-ing Intel. It seems that the userspace programs are crashingon > > Sandybridge machines even if 'xsave=0' is provided on the command line. > > Any advice? > > Going through the bug, all I can see are bogus attempts to pass > "xsave=" (with value 0 or 1) to the kernel. That's a hypervisor > option though, and the only kernel option that's relevant here > is "noxsave" afaik. > > Further, when the hypervisor has xsave support enabled, there's > (in the pv case) nothing the kernel can do to hide the functionality > from applications, as the hardware's CR4.OSXSAVE will be set, and > hence CPUID.OSXSAVE will be too. So "noxsave" on the kernel > command line when "xsave=1" (or xsave enabled by default as in > 4.2) just doesn't make any sense. > > And finally one always has to keep in mind that there is this nice > glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE > when trying to determine whether AVX or FMA is available. It has this: 146 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) 148 { 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSXSAVE) != 0 151 && ({ unsigned int xcrlow; 152 unsigned int xcrhigh; 153 asm ("xgetbv" 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); 155 (xcrlow & 6) == 6; })) 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; 157 } And when I ran a little silly C program (attached) to probe the CPUID flags, I got: /root/test-xsave SSE3 CMOV AVX XSAVE Trying XGETBV Illegal instruction (core dumped) Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV guest still crashes on that machine) - which means that in multi-lib the bit_YMM_Usable is _not_ set. But then looking at the sources I see: # ifdef USE_AS_STRCASECMP_L 102 ENTRY(__strcasecmp) 103 .type __strcasecmp, @gnu_indirect_function 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) 105 jne 1f 106 call __init_cpu_features 107 1: 108 # ifdef HAVE_AVX_SUPPORT 109 leaq __strcasecmp_avx(%rip), %rax 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) 111 jnz 2f 112 # endif which would imply that the AVX bit is sampled here instead of the YMM one. Perhaps this is needed: --- glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c.orig 2012-05-09 13:32:10.832000122 -0400 +++ glibc-2.15-a316c1f/sysdeps/x86_64/multiarch/init-arch.c 2012-05-09 13:33:31.043000138 -0400 @@ -154,6 +154,8 @@ __init_cpu_features (void) : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); (xcrlow & 6) == 6; })) __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; + else + __cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ~bit_AVX; } __cpu_features.family = family; ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 17:51:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17:51:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSB1u-0001wV-Bc; Wed, 09 May 2012 17:50:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSB1s-0001wP-E0 for xen-devel@lists.xen.org; Wed, 09 May 2012 17:50:24 +0000 Received: from [193.109.254.147:54119] by server-9.bemta-14.messagelabs.com id F8/F2-05787-F5EAAAF4; Wed, 09 May 2012 17:50:23 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336585818!1610429!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE5MzAw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6271 invoked from network); 9 May 2012 17:50:19 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 17:50:19 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q49HoGs4030396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 17:50:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q49HoFhw013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:50:16 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q49HoENh027747; Wed, 9 May 2012 12:50:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 May 2012 10:50:14 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 66C824031D; Wed, 9 May 2012 13:44:26 -0400 (EDT) Date: Wed, 9 May 2012 13:44:26 -0400 From: Konrad Rzeszutek Wilk To: Pavel =?utf-8?Q?Mat=C4=9Bja?= Message-ID: <20120509174426.GD9094@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> <20120507230707.GA28744@phenom.dumpdata.com> <201205081312.39927.pavel@netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201205081312.39927.pavel@netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCBNYXkgMDgsIDIwMTIgYXQgMDE6MTI6MzlQTSArMDIwMCwgUGF2ZWwgTWF0xJtqYSB3 cm90ZToKPiBPbiBUdWUgOC4gb2YgTWF5IDIwMTIgMDE6MDc6MDcgS29ucmFkIFJ6ZXN6dXRlayBX aWxrIHdyb3RlOgo+ID4gT24gVHVlLCBNYXkgMDgsIDIwMTIgYXQgMDE6MTA6MzJBTSArMDIwMCwg UGF2ZWwgTWF0ZWphIHdyb3RlOgo+ID4gPiA+IE9uIE1vbiwgTWF5IDA3LCAyMDEyIGF0IDAxOjQ1 OjIzUE0gKzAyMDAsIFBhdmVsIE1hdMOEwptqYSB3cm90ZToKPiA+ID4gPj4gSGksCj4gPiA+ID4+ IEknbSB0cnlpbmcgdG8gcnVuIEFNRCBWR0EgcGFzc3RocnUgb24gbGF0ZXN0IFhFTiB1bnN0YWJs ZSB3aXRoIGxhdGVzdAo+ID4gPiA+PiBrZXJuZWwuCj4gPiA+ID4+IEkgYWxyZWFkeSBoYXZlIHdv cmtpbmcgc2V0dXAgd2l0aCBhbmNpZW50IHhlbi1kZXZlbCA0LjIgYW5kIDIuNi4zMi54Cj4gPiA+ ID4+IHhlbmlmaWVkCj4gPiA+ID4+IGtlcm5lbC4gU2VlIGF0dGFjaGVkIGxvZy4KPiA+ID4gPj4g Cj4gPiA+ID4+IFNvIEkgdHJpZWQganVzdCB0byB1cGRhdGUgYW5kIHBhdGNoIHhlbiBhbmQga2Vy bmVsLCBidXQgSSBoYWQgbm8gbHVjawo+ID4gPiA+PiBzbyBmYXIuCj4gPiA+ID4+IAo+ID4gPiA+ PiBYZW4gaGFzIGF0aV92Ymlvc19wYXRjaF9yZXNwaW4udHh0IHNlbnQgdG8geGVuLWRldmVsIGJ5 IFdlaSBIdWFuZwo+ID4gPiA+PiByZWNlbnRseS4KPiA+ID4gPj4gaHR0cDovL2xpc3RzLnhlbi5v cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wNC9tc2cwMDI5MS5odG1sCj4gPiA+ID4+ IAo+ID4gPiA+PiBJIHRyaWVkIHR3byBrZXJuZWxzCj4gPiA+ID4+IHRlc3RpbmctMy41LXdpdGgt ZXh0cmEgYW5kIHhlbi9uZXh0LTMuMiBmcm9tCj4gPiA+ID4+IGdpdDovL2dpdC5rZXJuZWwub3Jn L3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9rb25yYWQveGVuLmdpdAo+ID4gPiA+PiBhbmQKPiA+ ID4gPj4gZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2plcmVt eS94ZW4uZ2l0Cj4gPiA+ID4+IEJvdGggd2l0aCBpb3Blcm0gb3Bjb2RlIHBhdGNoIHdoaWNoIGlz IHJlcXVpcmVkIGJ5IHRoZSBBVEkgcGF0Y2guIFNlZQo+ID4gPiA+PiBhdHRhY2hlbWVudC4KPiA+ ID4gPj4gCj4gPiA+ID4+IFRoZSB4ZW4vbmV4dC0zLjIgYnJhbmNoIGtlcm5lbCB3YXMgYWJsZSB0 byBzdGFydCBib290aW5nIHdpbmRvd3MuCj4gPiA+ID4+IFdpdGggQ2F0YWx5c3QgZHJpdmVyIGlu c3RhbGxlZCBJIGp1c3Qgc2F3IGJsdWVzY3JlZW4gZHVyaW5nIFdpbmRvd3MKPiA+ID4gPj4gYm9v dC4KPiA+ID4gPj4gV2l0aG91dCBDYXRhbHlzdCBkcml2ZXIgV2luZG93cyB3ZXJlIGFibGUgdG8g Ym9vdCBidXQgV2luZG93cyBlbmRlZAo+ID4gPiA+PiBmcm96ZW4gb3IKPiA+ID4gPj4gVVNCIHdh cyBub3Qgd29ya2luZy4gSXQgd2FzIGhhcmQgdG8gdGVsbCBiZWNhdXNlIGlucHV0IGRldmljZXMg aGFkIG5vCj4gPiA+ID4+IHJlc3BvbnNlCj4gPiA+ID4+IGF0IGFsbC4KPiA+ID4gPj4gCj4gPiA+ ID4+IFRoZSB0ZXN0aW5nLTMuNS13aXRoLWV4dHJhIChyZXBvcnRlZCBhcyAzLjQuMC1yYzQpIGp1 c3QgY3Jhc2hlZCBkb20wCj4gPiA+ID4+IGtlcm5lbAo+ID4gPiA+PiBkdXJpbmcgV2luZG93cyBi b290LiBJIGd1ZXNzIEkgaGF2ZSB0byByZXdvcmsgdGhlIGlvX2JpdG1hcCBwYXRjaAo+ID4gPiA+ PiBzb21laG93Lgo+ID4gPiA+IAo+ID4gPiA+IFdoZW4geW91IHNheSAnaW9fYml0bWFwJyBwYXRj aCBhcmUgeW91IHJlZmVycmluZyB0byB0aGVzZSBvbmVzOgo+ID4gPiA+IAo+ID4gPiA+IDcwYTM1 N2QgeGVuOiBpbXBsZW1lbnQgSU8gcGVybWlzc2lvbiBiaXRtYXAKPiA+ID4gPiAwYzU5NmM1IHg4 Ni9wYXJhdmlydDogcGFyYXZpcnR1YWxpemUgSU8gcGVybWlzc2lvbiBiaXRtYXAKPiA+ID4gPiA5 M2I3YTJhIHg4NjogZGVtYWNybyBzZXRfaW9wbF9tYXNrKCkKPiA+ID4gPiAKPiA+ID4gPiA/IEkg ZG9uJ3QgdGhpbmsgdGhvc2UgYXJlIGluIHRoYXQgdGFnLiBUaGV5IGFyZSBpbiB0aGUga2l0Y2hl bnNpbmsgLQo+ID4gPiA+ICN0ZXN0aW5nCj4gPiA+ID4gLSBkb2VzIGl0IHdvcmsgd2l0aCB0aGF0 IGJyYW5jaD8KPiA+ID4gPiAKPiA+ID4gPiBUaGUgbmV4dC0zLjIgaXMgYSBiaXQgb2xkLiBJIHNo b3VsZCBhY3R1YWxseSBkZWxldGUgaXQuCj4gPiA+IAo+ID4gPiBIaSwKPiA+ID4gSSBtZWFuIHRo aXMgcGF0Y2ggYmVsb3cuCj4gPiA+IEkgdGhpbmsgaXQgd2FzIG9yaWdpbmFsbHkgaGVyZToKPiA+ ID4gaHR0cDovL29sZC1saXN0LWFyY2hpdmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2 ZWwvMjAwOS0wNS9tc2cwMTEzOQo+ID4gPiAuaHRtbCBUaGVuIEkgd2FzIHRvbGQgYnkgeW91IHRv IHVzZSBkZXZlbC9pb3Blcm0gYnJhbmNoIHdoaWNoIEkgdGhpbmsKPiA+ID4gZG9lc24ndCBleGlz dCBhbnltb3JlOgo+ID4gPiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9yZy9hcmNoaXZl cy9odG1sL3hlbi1kZXZlbC8yMDExLTExL21zZzAxMjEzCj4gPiA+IC5odG1sCj4gPiAKPiA+IEl0 IGNlcnRhaW5seSBkb2VzIDotKQo+ID4gCj4gPiA+IEknbSB0b28gdGlyZWQgdG8gdGVzdCAjdGVz dGluZyBicmFuY2ggbm93LiBJJ2xsIHRyeSBpdCB0b21vcnJvdyBhZnRlcgo+ID4gPiBzb21lIHNs ZWVwLgo+ID4gCj4gPiBPSywgdGFrZSB5b3VyIHRpbWUuCj4gCj4gSGkgYWdhaW4hCj4gSSBkaWQg Zmlyc3QgdGVzdHMgd2l0aCB4ZW4tdW5zdGFibGUgYW5kIHRoZSAjdGVzdGluZyBrZXJuZWwuCj4g Cj4gV2luZG93cyBzaG93ZWQgYmx1ZSBzY3JlZW4gZHVyaW5nIGJvb3Qgd2l0aCB4bSB0b29sc3Rh Y2suCj4gCj4gQnV0IEkgaGFkIGx1Y2sgd2l0aCB4bC4gV2luZG93cyBib290ZWQgc3VjY2VzZnVs bHkgc28gSSByYW4gdGhlIGV4cGVyaWVuY2UgCj4gaW5kZXggdGVzdHM6Cgo+IGtlcm5lbDoJMi42 LjMyLjU3CSN0ZXN0aW5nCj4gQ1BVCQk3LDQJCTcsNAo+IFJBTQkJNyw0CQk1LDUKPiBBZXJvCQk3 LDEJCTcsMQo+IEdyLmNhcmQJNywxCQk3LDEKPiBEaXNrCQk3LDMJCTcsNQoKU28gdGhlIGlzc3Vl IHdhcyB0aGF0ICd4bScgZGlkbid0IHdvcmsgYnV0ICd4bCcgZGlkPwoKPiBJIHRyaWVkIHRvIHJ1 biBzb21lIGdhbWVzIGFzIHdlbGwgYnV0IHRoZSBmZWVsaW5nIGlzIG11Y2ggd29yc2UgY29tcGFy ZWQgdG8gCj4gb2xkZXIgY29uZmlndXJhdGlvbi4gTGlrZSBsYWdzLi4KCkRvIHRoZSBsYWdzIGRp c2FwcGVhciBpZiB5b3UgcGluIHRoZSB2Q1BVcz8KPiAKPiBBcmUgdGhlcmUgc29tZSBvbGRlciBi cmFuY2hlcyB3aGljaCBhcmUgc3VwcG9zZWQgdG8gd29yaz8KClRoZXJlIGlzIG5vdCBhIHNwZWNp ZmljIGJyYW5jaCBwZXIgc2F5LiBUaGVyZSBhcmUgc29tZSBhdXhpbGxhcnkgYnJhbmNoZXMKd2l0 aCBwYXRjaGVzIHRoYXQgZW5hYmxlIHRoaXMgYW5kIHRoYXQuIFNvIHdoYXQgbWlnaHQgd29yayBp cwp0byB1c2UgbXkgI2xpbnV4LW5leHQgYnJhbmNoIGFuZCBtZXJnZSBib3RoIGRldmVsL21pc2Mg YW5kIGRldmVsL2lvcGVybQppbiBhbmQgc2VlIHdoYXQgaGFwcGVucy4gSWYgSSBnZXQgc29tZSB0 aW1lIHRvZGF5IEkgd2lsbCB0cnkgdGhhdCBhbmQKc3RpY2sgaXQgYXMgdGFnLgoKPiAKPiBJIHRy aWVkIHhlbi00LjEuMy1yYzEgd2l0aCAjdGVzdGluZyBrZXJuZWwgYnV0IGl0IGp1c3QgZnJlZXpl cyBhZnRlciB3aGlsZSAKPiBldmVuIHdpdGggRG9tMCBydW5uaW5nLiBPbmx5IHN5cy1ycSB3b3Jr ZWQuCgpPaCBubyEKPiAKPiBJIGhhdmUgc2Vjb25kIHNsaWdodGx5IG5ld2VyIHN5c3RlbSB0b28g c28gSSdsbCByZXRlc3QgdGhhdCBvbmUgbGF0ZXIuCj4gLS0gCj4gUGF2ZWwgTWF0ZWphCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2 ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMu eGVuLm9yZy94ZW4tZGV2ZWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed May 09 17:51:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 17:51:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSB1u-0001wV-Bc; Wed, 09 May 2012 17:50:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSB1s-0001wP-E0 for xen-devel@lists.xen.org; Wed, 09 May 2012 17:50:24 +0000 Received: from [193.109.254.147:54119] by server-9.bemta-14.messagelabs.com id F8/F2-05787-F5EAAAF4; Wed, 09 May 2012 17:50:23 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336585818!1610429!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE5MzAw\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6271 invoked from network); 9 May 2012 17:50:19 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 17:50:19 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q49HoGs4030396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 17:50:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q49HoFhw013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:50:16 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q49HoENh027747; Wed, 9 May 2012 12:50:15 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 May 2012 10:50:14 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 66C824031D; Wed, 9 May 2012 13:44:26 -0400 (EDT) Date: Wed, 9 May 2012 13:44:26 -0400 From: Konrad Rzeszutek Wilk To: Pavel =?utf-8?Q?Mat=C4=9Bja?= Message-ID: <20120509174426.GD9094@phenom.dumpdata.com> References: <201205071345.23619.pavel@netsafe.cz> <0f6f2245ebbaab7e505b7cca86bdeefe.squirrel@mail.netsafe.cz> <20120507230707.GA28744@phenom.dumpdata.com> <201205081312.39927.pavel@netsafe.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201205081312.39927.pavel@netsafe.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCBNYXkgMDgsIDIwMTIgYXQgMDE6MTI6MzlQTSArMDIwMCwgUGF2ZWwgTWF0xJtqYSB3 cm90ZToKPiBPbiBUdWUgOC4gb2YgTWF5IDIwMTIgMDE6MDc6MDcgS29ucmFkIFJ6ZXN6dXRlayBX aWxrIHdyb3RlOgo+ID4gT24gVHVlLCBNYXkgMDgsIDIwMTIgYXQgMDE6MTA6MzJBTSArMDIwMCwg UGF2ZWwgTWF0ZWphIHdyb3RlOgo+ID4gPiA+IE9uIE1vbiwgTWF5IDA3LCAyMDEyIGF0IDAxOjQ1 OjIzUE0gKzAyMDAsIFBhdmVsIE1hdMOEwptqYSB3cm90ZToKPiA+ID4gPj4gSGksCj4gPiA+ID4+ IEknbSB0cnlpbmcgdG8gcnVuIEFNRCBWR0EgcGFzc3RocnUgb24gbGF0ZXN0IFhFTiB1bnN0YWJs ZSB3aXRoIGxhdGVzdAo+ID4gPiA+PiBrZXJuZWwuCj4gPiA+ID4+IEkgYWxyZWFkeSBoYXZlIHdv cmtpbmcgc2V0dXAgd2l0aCBhbmNpZW50IHhlbi1kZXZlbCA0LjIgYW5kIDIuNi4zMi54Cj4gPiA+ ID4+IHhlbmlmaWVkCj4gPiA+ID4+IGtlcm5lbC4gU2VlIGF0dGFjaGVkIGxvZy4KPiA+ID4gPj4g Cj4gPiA+ID4+IFNvIEkgdHJpZWQganVzdCB0byB1cGRhdGUgYW5kIHBhdGNoIHhlbiBhbmQga2Vy bmVsLCBidXQgSSBoYWQgbm8gbHVjawo+ID4gPiA+PiBzbyBmYXIuCj4gPiA+ID4+IAo+ID4gPiA+ PiBYZW4gaGFzIGF0aV92Ymlvc19wYXRjaF9yZXNwaW4udHh0IHNlbnQgdG8geGVuLWRldmVsIGJ5 IFdlaSBIdWFuZwo+ID4gPiA+PiByZWNlbnRseS4KPiA+ID4gPj4gaHR0cDovL2xpc3RzLnhlbi5v cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wNC9tc2cwMDI5MS5odG1sCj4gPiA+ID4+ IAo+ID4gPiA+PiBJIHRyaWVkIHR3byBrZXJuZWxzCj4gPiA+ID4+IHRlc3RpbmctMy41LXdpdGgt ZXh0cmEgYW5kIHhlbi9uZXh0LTMuMiBmcm9tCj4gPiA+ID4+IGdpdDovL2dpdC5rZXJuZWwub3Jn L3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9rb25yYWQveGVuLmdpdAo+ID4gPiA+PiBhbmQKPiA+ ID4gPj4gZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2plcmVt eS94ZW4uZ2l0Cj4gPiA+ID4+IEJvdGggd2l0aCBpb3Blcm0gb3Bjb2RlIHBhdGNoIHdoaWNoIGlz IHJlcXVpcmVkIGJ5IHRoZSBBVEkgcGF0Y2guIFNlZQo+ID4gPiA+PiBhdHRhY2hlbWVudC4KPiA+ ID4gPj4gCj4gPiA+ID4+IFRoZSB4ZW4vbmV4dC0zLjIgYnJhbmNoIGtlcm5lbCB3YXMgYWJsZSB0 byBzdGFydCBib290aW5nIHdpbmRvd3MuCj4gPiA+ID4+IFdpdGggQ2F0YWx5c3QgZHJpdmVyIGlu c3RhbGxlZCBJIGp1c3Qgc2F3IGJsdWVzY3JlZW4gZHVyaW5nIFdpbmRvd3MKPiA+ID4gPj4gYm9v dC4KPiA+ID4gPj4gV2l0aG91dCBDYXRhbHlzdCBkcml2ZXIgV2luZG93cyB3ZXJlIGFibGUgdG8g Ym9vdCBidXQgV2luZG93cyBlbmRlZAo+ID4gPiA+PiBmcm96ZW4gb3IKPiA+ID4gPj4gVVNCIHdh cyBub3Qgd29ya2luZy4gSXQgd2FzIGhhcmQgdG8gdGVsbCBiZWNhdXNlIGlucHV0IGRldmljZXMg aGFkIG5vCj4gPiA+ID4+IHJlc3BvbnNlCj4gPiA+ID4+IGF0IGFsbC4KPiA+ID4gPj4gCj4gPiA+ ID4+IFRoZSB0ZXN0aW5nLTMuNS13aXRoLWV4dHJhIChyZXBvcnRlZCBhcyAzLjQuMC1yYzQpIGp1 c3QgY3Jhc2hlZCBkb20wCj4gPiA+ID4+IGtlcm5lbAo+ID4gPiA+PiBkdXJpbmcgV2luZG93cyBi b290LiBJIGd1ZXNzIEkgaGF2ZSB0byByZXdvcmsgdGhlIGlvX2JpdG1hcCBwYXRjaAo+ID4gPiA+ PiBzb21laG93Lgo+ID4gPiA+IAo+ID4gPiA+IFdoZW4geW91IHNheSAnaW9fYml0bWFwJyBwYXRj aCBhcmUgeW91IHJlZmVycmluZyB0byB0aGVzZSBvbmVzOgo+ID4gPiA+IAo+ID4gPiA+IDcwYTM1 N2QgeGVuOiBpbXBsZW1lbnQgSU8gcGVybWlzc2lvbiBiaXRtYXAKPiA+ID4gPiAwYzU5NmM1IHg4 Ni9wYXJhdmlydDogcGFyYXZpcnR1YWxpemUgSU8gcGVybWlzc2lvbiBiaXRtYXAKPiA+ID4gPiA5 M2I3YTJhIHg4NjogZGVtYWNybyBzZXRfaW9wbF9tYXNrKCkKPiA+ID4gPiAKPiA+ID4gPiA/IEkg ZG9uJ3QgdGhpbmsgdGhvc2UgYXJlIGluIHRoYXQgdGFnLiBUaGV5IGFyZSBpbiB0aGUga2l0Y2hl bnNpbmsgLQo+ID4gPiA+ICN0ZXN0aW5nCj4gPiA+ID4gLSBkb2VzIGl0IHdvcmsgd2l0aCB0aGF0 IGJyYW5jaD8KPiA+ID4gPiAKPiA+ID4gPiBUaGUgbmV4dC0zLjIgaXMgYSBiaXQgb2xkLiBJIHNo b3VsZCBhY3R1YWxseSBkZWxldGUgaXQuCj4gPiA+IAo+ID4gPiBIaSwKPiA+ID4gSSBtZWFuIHRo aXMgcGF0Y2ggYmVsb3cuCj4gPiA+IEkgdGhpbmsgaXQgd2FzIG9yaWdpbmFsbHkgaGVyZToKPiA+ ID4gaHR0cDovL29sZC1saXN0LWFyY2hpdmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2 ZWwvMjAwOS0wNS9tc2cwMTEzOQo+ID4gPiAuaHRtbCBUaGVuIEkgd2FzIHRvbGQgYnkgeW91IHRv IHVzZSBkZXZlbC9pb3Blcm0gYnJhbmNoIHdoaWNoIEkgdGhpbmsKPiA+ID4gZG9lc24ndCBleGlz dCBhbnltb3JlOgo+ID4gPiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9yZy9hcmNoaXZl cy9odG1sL3hlbi1kZXZlbC8yMDExLTExL21zZzAxMjEzCj4gPiA+IC5odG1sCj4gPiAKPiA+IEl0 IGNlcnRhaW5seSBkb2VzIDotKQo+ID4gCj4gPiA+IEknbSB0b28gdGlyZWQgdG8gdGVzdCAjdGVz dGluZyBicmFuY2ggbm93LiBJJ2xsIHRyeSBpdCB0b21vcnJvdyBhZnRlcgo+ID4gPiBzb21lIHNs ZWVwLgo+ID4gCj4gPiBPSywgdGFrZSB5b3VyIHRpbWUuCj4gCj4gSGkgYWdhaW4hCj4gSSBkaWQg Zmlyc3QgdGVzdHMgd2l0aCB4ZW4tdW5zdGFibGUgYW5kIHRoZSAjdGVzdGluZyBrZXJuZWwuCj4g Cj4gV2luZG93cyBzaG93ZWQgYmx1ZSBzY3JlZW4gZHVyaW5nIGJvb3Qgd2l0aCB4bSB0b29sc3Rh Y2suCj4gCj4gQnV0IEkgaGFkIGx1Y2sgd2l0aCB4bC4gV2luZG93cyBib290ZWQgc3VjY2VzZnVs bHkgc28gSSByYW4gdGhlIGV4cGVyaWVuY2UgCj4gaW5kZXggdGVzdHM6Cgo+IGtlcm5lbDoJMi42 LjMyLjU3CSN0ZXN0aW5nCj4gQ1BVCQk3LDQJCTcsNAo+IFJBTQkJNyw0CQk1LDUKPiBBZXJvCQk3 LDEJCTcsMQo+IEdyLmNhcmQJNywxCQk3LDEKPiBEaXNrCQk3LDMJCTcsNQoKU28gdGhlIGlzc3Vl IHdhcyB0aGF0ICd4bScgZGlkbid0IHdvcmsgYnV0ICd4bCcgZGlkPwoKPiBJIHRyaWVkIHRvIHJ1 biBzb21lIGdhbWVzIGFzIHdlbGwgYnV0IHRoZSBmZWVsaW5nIGlzIG11Y2ggd29yc2UgY29tcGFy ZWQgdG8gCj4gb2xkZXIgY29uZmlndXJhdGlvbi4gTGlrZSBsYWdzLi4KCkRvIHRoZSBsYWdzIGRp c2FwcGVhciBpZiB5b3UgcGluIHRoZSB2Q1BVcz8KPiAKPiBBcmUgdGhlcmUgc29tZSBvbGRlciBi cmFuY2hlcyB3aGljaCBhcmUgc3VwcG9zZWQgdG8gd29yaz8KClRoZXJlIGlzIG5vdCBhIHNwZWNp ZmljIGJyYW5jaCBwZXIgc2F5LiBUaGVyZSBhcmUgc29tZSBhdXhpbGxhcnkgYnJhbmNoZXMKd2l0 aCBwYXRjaGVzIHRoYXQgZW5hYmxlIHRoaXMgYW5kIHRoYXQuIFNvIHdoYXQgbWlnaHQgd29yayBp cwp0byB1c2UgbXkgI2xpbnV4LW5leHQgYnJhbmNoIGFuZCBtZXJnZSBib3RoIGRldmVsL21pc2Mg YW5kIGRldmVsL2lvcGVybQppbiBhbmQgc2VlIHdoYXQgaGFwcGVucy4gSWYgSSBnZXQgc29tZSB0 aW1lIHRvZGF5IEkgd2lsbCB0cnkgdGhhdCBhbmQKc3RpY2sgaXQgYXMgdGFnLgoKPiAKPiBJIHRy aWVkIHhlbi00LjEuMy1yYzEgd2l0aCAjdGVzdGluZyBrZXJuZWwgYnV0IGl0IGp1c3QgZnJlZXpl cyBhZnRlciB3aGlsZSAKPiBldmVuIHdpdGggRG9tMCBydW5uaW5nLiBPbmx5IHN5cy1ycSB3b3Jr ZWQuCgpPaCBubyEKPiAKPiBJIGhhdmUgc2Vjb25kIHNsaWdodGx5IG5ld2VyIHN5c3RlbSB0b28g c28gSSdsbCByZXRlc3QgdGhhdCBvbmUgbGF0ZXIuCj4gLS0gCj4gUGF2ZWwgTWF0ZWphCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2 ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMu eGVuLm9yZy94ZW4tZGV2ZWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed May 09 18:26:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSBaP-0002HR-Fo; Wed, 09 May 2012 18:26:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSBaO-0002HM-1a for xen-devel@lists.xen.org; Wed, 09 May 2012 18:26:04 +0000 Received: from [193.109.254.147:51253] by server-11.bemta-14.messagelabs.com id 25/D1-05858-BB6BAAF4; Wed, 09 May 2012 18:26:03 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-27.messagelabs.com!1336587961!1629005!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9769 invoked from network); 9 May 2012 18:26:02 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-27.messagelabs.com with SMTP; 9 May 2012 18:26:02 -0000 Received: (qmail 23310 invoked from network); 9 May 2012 20:26:00 +0200 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; 9 May 2012 20:26:00 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: Konrad Rzeszutek Wilk Date: Wed, 9 May 2012 20:25:56 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <201205081312.39927.pavel@netsafe.cz> <20120509174426.GD9094@phenom.dumpdata.com> In-Reply-To: <20120509174426.GD9094@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205092025.57037.pavel@netsafe.cz> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed 9. of May 2012 19:44:26 you wrote: > > Hi again! > > I did first tests with xen-unstable and the #testing kernel. > > > > Windows showed blue screen during boot with xm toolstack. > > > > But I had luck with xl. Windows booted succesfully so I ran the > > experience index tests: > > > > kernel: 2.6.32.57 #testing > > CPU 7,4 7,4 > > RAM 7,4 5,5 > > Aero 7,1 7,1 > > Gr.card 7,1 7,1 > > Disk 7,3 7,5 > > So the issue was that 'xm' didn't work but 'xl' did? In fact it's: 2.6.32.57 and old xen-unstable build (May 2011) with xm toolstack, #testing and latest xen-unstable with xl toolstack. No other combinations are working. > > I tried to run some games as well but the feeling is much worse compared > > to older configuration. Like lags.. > > Do the lags disappear if you pin the vCPUs? Do you mean for Dom0 or DomU? I already pin all vCPUs for DomUs. I can try to dedicate one to xen and rest to Windows. But current config (Phenom II X6) was able to run 3 cores for first Windows, other 3 cores for second Windows and Dom0 had 2 unpinned cores. All was smooth. Even 2 cores per instance fro three Windows instances were just fine. Right now I'm trying just one Windows instance with all cores pinned. > > Are there some older branches which are supposed to work? > > There is not a specific branch per say. There are some auxillary branches > with patches that enable this and that. So what might work is > to use my #linux-next branch and merge both devel/misc and devel/ioperm > in and see what happens. If I get some time today I will try that and > stick it as tag. > > > I tried xen-4.1.3-rc1 with #testing kernel but it just freezes after > > while even with Dom0 running. Only sys-rq worked. > > Oh no! On no to my english. ;) It should be: system freezes after while even when only Dom0 is running. How can I debug this? All I can do is reading sysrq messages but I see no real dumps in serial console. Like: .. SysRq : Show Regs SysRq : Show Blocked State SysRq : Show clockevent devices & pending hrtimers (no others) .. > > I have second slightly newer system too so I'll retest that one later. Sorry, no time yet. I just tried same thing I did on old system and result is instant reboot somewhere after NIC detection. Maybe the fs is gone somehow.. I have to switch the serial card to debug that one. -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 18:26:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSBaP-0002HR-Fo; Wed, 09 May 2012 18:26:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSBaO-0002HM-1a for xen-devel@lists.xen.org; Wed, 09 May 2012 18:26:04 +0000 Received: from [193.109.254.147:51253] by server-11.bemta-14.messagelabs.com id 25/D1-05858-BB6BAAF4; Wed, 09 May 2012 18:26:03 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-27.messagelabs.com!1336587961!1629005!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9769 invoked from network); 9 May 2012 18:26:02 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-27.messagelabs.com with SMTP; 9 May 2012 18:26:02 -0000 Received: (qmail 23310 invoked from network); 9 May 2012 20:26:00 +0200 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; 9 May 2012 20:26:00 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: Konrad Rzeszutek Wilk Date: Wed, 9 May 2012 20:25:56 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <201205081312.39927.pavel@netsafe.cz> <20120509174426.GD9094@phenom.dumpdata.com> In-Reply-To: <20120509174426.GD9094@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205092025.57037.pavel@netsafe.cz> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed 9. of May 2012 19:44:26 you wrote: > > Hi again! > > I did first tests with xen-unstable and the #testing kernel. > > > > Windows showed blue screen during boot with xm toolstack. > > > > But I had luck with xl. Windows booted succesfully so I ran the > > experience index tests: > > > > kernel: 2.6.32.57 #testing > > CPU 7,4 7,4 > > RAM 7,4 5,5 > > Aero 7,1 7,1 > > Gr.card 7,1 7,1 > > Disk 7,3 7,5 > > So the issue was that 'xm' didn't work but 'xl' did? In fact it's: 2.6.32.57 and old xen-unstable build (May 2011) with xm toolstack, #testing and latest xen-unstable with xl toolstack. No other combinations are working. > > I tried to run some games as well but the feeling is much worse compared > > to older configuration. Like lags.. > > Do the lags disappear if you pin the vCPUs? Do you mean for Dom0 or DomU? I already pin all vCPUs for DomUs. I can try to dedicate one to xen and rest to Windows. But current config (Phenom II X6) was able to run 3 cores for first Windows, other 3 cores for second Windows and Dom0 had 2 unpinned cores. All was smooth. Even 2 cores per instance fro three Windows instances were just fine. Right now I'm trying just one Windows instance with all cores pinned. > > Are there some older branches which are supposed to work? > > There is not a specific branch per say. There are some auxillary branches > with patches that enable this and that. So what might work is > to use my #linux-next branch and merge both devel/misc and devel/ioperm > in and see what happens. If I get some time today I will try that and > stick it as tag. > > > I tried xen-4.1.3-rc1 with #testing kernel but it just freezes after > > while even with Dom0 running. Only sys-rq worked. > > Oh no! On no to my english. ;) It should be: system freezes after while even when only Dom0 is running. How can I debug this? All I can do is reading sysrq messages but I see no real dumps in serial console. Like: .. SysRq : Show Regs SysRq : Show Blocked State SysRq : Show clockevent devices & pending hrtimers (no others) .. > > I have second slightly newer system too so I'll retest that one later. Sorry, no time yet. I just tried same thing I did on old system and result is instant reboot somewhere after NIC detection. Maybe the fs is gone somehow.. I have to switch the serial card to debug that one. -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 18:43:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSBqg-0002Rf-2q; Wed, 09 May 2012 18:42:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSBqe-0002Ra-BA for xen-devel@lists.xensource.com; Wed, 09 May 2012 18:42:52 +0000 Received: from [193.109.254.147:44823] by server-9.bemta-14.messagelabs.com id E4/9E-05787-BAABAAF4; Wed, 09 May 2012 18:42:51 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336588970!755439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26077 invoked from network); 9 May 2012 18:42:50 -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; 9 May 2012 18:42:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="12387349" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 18:42:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 19:42:49 +0100 Date: Wed, 9 May 2012 19:42:33 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefano Stabellini In-Reply-To: Message-ID: References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 8 May 2012, Stefano Stabellini wrote: > I have been unable to reproduce this problem (I haven't given up yet) > but I bet that the following patch fixes it: > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index e3a9945..88e9304 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) > buffer_mfn, > rq_data_dir(req)); > > - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > + info->shadow[id].frame[i] = buffer_pfn; > ring_req->u.rw.seg[i] = > (struct blkif_request_segment) { > .gref = ref, > > > The idea is that the request contains a page for which > > pfn->mfn->pfn == 0xffffffffffffffff > > I am not sure exactly how it could be possible to get into this state in > blkfront, I hope that some more tracing and code reading will be able to > shed some lights on the issue. The one line patch fixes the issue: when using LVM in the guest the same page can be used in two different requests (in blkif_queue_request) before being unmapped. The second time mfn_to_pfn is going to return ~0 because buffer_mfn has the FOREIGN_FRAME_BIT set. But actually we don't need to call mfn_to_pfn at all because we already know the pfn value, that is stored in buffer_pfn. However the real problem remains at the time of blkif_completion: we will remove the FOREIGN_FRAME_BIT before the other requests have been completed. If sharing the same page twice (or more) is a normal condition then I might have to revisit this patch completely and choose another strategy... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 18:43:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSBqg-0002Rf-2q; Wed, 09 May 2012 18:42:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSBqe-0002Ra-BA for xen-devel@lists.xensource.com; Wed, 09 May 2012 18:42:52 +0000 Received: from [193.109.254.147:44823] by server-9.bemta-14.messagelabs.com id E4/9E-05787-BAABAAF4; Wed, 09 May 2012 18:42:51 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336588970!755439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26077 invoked from network); 9 May 2012 18:42:50 -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; 9 May 2012 18:42:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="12387349" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 18:42:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 19:42:49 +0100 Date: Wed, 9 May 2012 19:42:33 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Stefano Stabellini In-Reply-To: Message-ID: References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 8 May 2012, Stefano Stabellini wrote: > I have been unable to reproduce this problem (I haven't given up yet) > but I bet that the following patch fixes it: > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index e3a9945..88e9304 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) > buffer_mfn, > rq_data_dir(req)); > > - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > + info->shadow[id].frame[i] = buffer_pfn; > ring_req->u.rw.seg[i] = > (struct blkif_request_segment) { > .gref = ref, > > > The idea is that the request contains a page for which > > pfn->mfn->pfn == 0xffffffffffffffff > > I am not sure exactly how it could be possible to get into this state in > blkfront, I hope that some more tracing and code reading will be able to > shed some lights on the issue. The one line patch fixes the issue: when using LVM in the guest the same page can be used in two different requests (in blkif_queue_request) before being unmapped. The second time mfn_to_pfn is going to return ~0 because buffer_mfn has the FOREIGN_FRAME_BIT set. But actually we don't need to call mfn_to_pfn at all because we already know the pfn value, that is stored in buffer_pfn. However the real problem remains at the time of blkif_completion: we will remove the FOREIGN_FRAME_BIT before the other requests have been completed. If sharing the same page twice (or more) is a normal condition then I might have to revisit this patch completely and choose another strategy... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 18:59:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSC6f-0002bX-L6; Wed, 09 May 2012 18:59:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSC6e-0002bS-My for xen-devel@lists.xen.org; Wed, 09 May 2012 18:59:24 +0000 Received: from [85.158.139.83:52925] by server-9.bemta-5.messagelabs.com id 31/8C-09826-B8EBAAF4; Wed, 09 May 2012 18:59:23 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-182.messagelabs.com!1336589962!20306611!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24311 invoked from network); 9 May 2012 18:59:23 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-182.messagelabs.com with SMTP; 9 May 2012 18:59:23 -0000 Received: (qmail 25646 invoked from network); 9 May 2012 20:59:21 +0200 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; 9 May 2012 20:59:21 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Wed, 9 May 2012 20:59:17 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <201205081312.39927.pavel@netsafe.cz> <20120509174426.GD9094@phenom.dumpdata.com> In-Reply-To: <20120509174426.GD9094@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205092059.17957.pavel@netsafe.cz> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed 9. of May 2012 19:44:26 Konrad Rzeszutek Wilk wrote: > > I tried to run some games as well but the feeling is much worse compared > > to older configuration. Like lags.. > > Do the lags disappear if you pin the vCPUs? One stupid question: I tried: xl vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 3 -b- 74.8 any cpu Domain-0 0 1 2 -b- 7.7 any cpu Domain-0 0 2 5 -b- 7.4 any cpu Domain-0 0 3 2 -b- 8.2 any cpu Domain-0 0 4 0 r-- 8.4 any cpu Domain-0 0 5 1 -b- 7.4 any cpu windows 2 0 3 -b- 27.8 1-5 windows 2 1 4 -b- 23.5 1-5 windows 2 2 5 -b- 24.9 1-5 windows 2 3 1 -b- 27.3 1-5 windows 2 4 1 -b- 25.2 1-5 Do the last two lines mean that two vCPUs in winows are running on one real? The output changes and mostly is real - virtual cpu mapped one to one. I have to study the pinning more. I guess I was wrong when I wrote I already have it. -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 18:59:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 18: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 ) id 1SSC6f-0002bX-L6; Wed, 09 May 2012 18:59:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSC6e-0002bS-My for xen-devel@lists.xen.org; Wed, 09 May 2012 18:59:24 +0000 Received: from [85.158.139.83:52925] by server-9.bemta-5.messagelabs.com id 31/8C-09826-B8EBAAF4; Wed, 09 May 2012 18:59:23 +0000 X-Env-Sender: pavel@netsafe.cz X-Msg-Ref: server-11.tower-182.messagelabs.com!1336589962!20306611!1 X-Originating-IP: [83.223.49.132] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24311 invoked from network); 9 May 2012 18:59:23 -0000 Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132) by server-11.tower-182.messagelabs.com with SMTP; 9 May 2012 18:59:23 -0000 Received: (qmail 25646 invoked from network); 9 May 2012 20:59:21 +0200 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; 9 May 2012 20:59:21 +0200 From: Pavel =?utf-8?q?Mat=C4=9Bja?= Organization: Netsafe Solutions s.r.o. To: xen-devel@lists.xen.org Date: Wed, 9 May 2012 20:59:17 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.4; KDE/4.7.4; x86_64; ; ) References: <201205071345.23619.pavel@netsafe.cz> <201205081312.39927.pavel@netsafe.cz> <20120509174426.GD9094@phenom.dumpdata.com> In-Reply-To: <20120509174426.GD9094@phenom.dumpdata.com> MIME-Version: 1.0 Message-Id: <201205092059.17957.pavel@netsafe.cz> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed 9. of May 2012 19:44:26 Konrad Rzeszutek Wilk wrote: > > I tried to run some games as well but the feeling is much worse compared > > to older configuration. Like lags.. > > Do the lags disappear if you pin the vCPUs? One stupid question: I tried: xl vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 3 -b- 74.8 any cpu Domain-0 0 1 2 -b- 7.7 any cpu Domain-0 0 2 5 -b- 7.4 any cpu Domain-0 0 3 2 -b- 8.2 any cpu Domain-0 0 4 0 r-- 8.4 any cpu Domain-0 0 5 1 -b- 7.4 any cpu windows 2 0 3 -b- 27.8 1-5 windows 2 1 4 -b- 23.5 1-5 windows 2 2 5 -b- 24.9 1-5 windows 2 3 1 -b- 27.3 1-5 windows 2 4 1 -b- 25.2 1-5 Do the last two lines mean that two vCPUs in winows are running on one real? The output changes and mostly is real - virtual cpu mapped one to one. I have to study the pinning more. I guess I was wrong when I wrote I already have it. -- Pavel Mateja _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:04:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCB8-0002kt-BT; Wed, 09 May 2012 19:04:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCB7-0002kn-1R for xen-devel@lists.xen.org; Wed, 09 May 2012 19:04:01 +0000 Received: from [193.109.254.147:51920] by server-6.bemta-14.messagelabs.com id 59/C9-04960-F9FBAAF4; Wed, 09 May 2012 19:03:59 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-12.tower-27.messagelabs.com!1336590236!8468318!1 X-Originating-IP: [129.234.248.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzOTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32674 invoked from network); 9 May 2012 19:03:59 -0000 Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 19:03:59 -0000 Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q49J3Usr014649; Wed, 9 May 2012 20:03:34 +0100 Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135]) by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q49J3GQT023062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 20:03:16 +0100 Received: from vega-c.dur.ac.uk (localhost [127.0.0.1]) by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q49J3FPc017342; Wed, 9 May 2012 20:03:15 +0100 Received: from localhost (dcl0may@localhost) by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q49J3Fk2017337; Wed, 9 May 2012 20:03:15 +0100 Date: Wed, 9 May 2012 20:03:15 +0100 (BST) From: M A Young To: Keir Fraser In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1587021364-1336590195=:14172" X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q49J3Usr014649 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1587021364-1336590195=:14172 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 8 May 2012, Keir Fraser wrote: > Thanks. The same appears to be true in xen-unstable also. Is the solution to > simply remove -O0 from the command line? We can test that out in > xen-unstable if so, and backport if it causes no problems. I got it to build with the attached patch - http://koji.fedoraproject.org/koji/taskinfo?taskID=4063767 . It seems the -O0 option was masking some other compile issues so I had to add -Wno-error=unused-result -Wno-error=array-bounds as well though I imagine the right solution would be to fix the code so it doesn't give warnings (if they haven't already been fixed in xen-unstable). Michael Young --8323329-1587021364-1336590195=:14172 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=f17buildfix.patch Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename=f17buildfix.patch LS0tIHhlbi00LjEuMy90b29scy9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUu b3JpZwkyMDEyLTA1LTA3IDE3OjMyOjMxLjAwMDAwMDAwMCArMDEwMA0KKysr IHhlbi00LjEuMy90b29scy9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUJMjAx Mi0wNS0wOCAyMTozMjo0OC45NzU4Njg5MTMgKzAxMDANCkBAIC05LDcgKzks NyBAQA0KIExPQ0tfVVRJTCAgPSBsb2NrLXV0aWwNCiBJTlNUX0RJUiAgID0g JChTQklORElSKQ0KIA0KLUNGTEFHUyAgICArPSAtV2Vycm9yIC1nIC1PMA0K K0NGTEFHUyAgICArPSAtV2Vycm9yIC1nIC1Xbm8tZXJyb3I9dW51c2VkLXJl c3VsdCAtV25vLWVycm9yPWFycmF5LWJvdW5kcw0KIENGTEFHUyAgICArPSAt V25vLXVudXNlZA0KIENGTEFHUyAgICArPSAtZm5vLXN0cmljdC1hbGlhc2lu Zw0KIENGTEFHUyAgICArPSAtSSQoQkxLVEFQX1JPT1QpL2luY2x1ZGUgLUkk KEJMS1RBUF9ST09UKS9kcml2ZXJzDQotLS0geGVuLTQuMS4zL3Rvb2xzL3Nl Y3VyaXR5L01ha2VmaWxlLm9yaWcJMjAxMi0wNS0wNyAxNzozMjozMi4wMDAw MDAwMDAgKzAxMDANCisrKyB4ZW4tNC4xLjMvdG9vbHMvc2VjdXJpdHkvTWFr ZWZpbGUJMjAxMi0wNS0wOCAyMTozNDozNS40Nzk1Mzc0MzUgKzAxMDANCkBA IC03Niw3ICs3Niw3IEBADQogCWNobW9kIDcwMCAkKEFDTV9TQ1JJUFRTKQ0K IA0KIHhlbnNlY190b29sOiAkKE9CSlNfVE9PTCkNCi0JJChDQykgLWcgJChD RkxBR1MpICQoTERGTEFHUykgLU8wIC1vICRAICReICQoTERMSUJTX2xpYnhl bmN0cmwpDQorCSQoQ0MpIC1nICQoQ0ZMQUdTKSAkKExERkxBR1MpIC1vICRA ICReICQoTERMSUJTX2xpYnhlbmN0cmwpDQogDQogeGVuc2VjX2dlbjogeGVu c2VjX2dlbi5weQ0KIAljcCAtZiAkXiAkQA0K --8323329-1587021364-1336590195=:14172 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --8323329-1587021364-1336590195=:14172-- From xen-devel-bounces@lists.xen.org Wed May 09 19:04:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCB8-0002kt-BT; Wed, 09 May 2012 19:04:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCB7-0002kn-1R for xen-devel@lists.xen.org; Wed, 09 May 2012 19:04:01 +0000 Received: from [193.109.254.147:51920] by server-6.bemta-14.messagelabs.com id 59/C9-04960-F9FBAAF4; Wed, 09 May 2012 19:03:59 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-12.tower-27.messagelabs.com!1336590236!8468318!1 X-Originating-IP: [129.234.248.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzOTM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32674 invoked from network); 9 May 2012 19:03:59 -0000 Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 19:03:59 -0000 Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q49J3Usr014649; Wed, 9 May 2012 20:03:34 +0100 Received: from vega-c.dur.ac.uk (vega-c.dur.ac.uk [129.234.250.135]) by smtphost4.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q49J3GQT023062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 20:03:16 +0100 Received: from vega-c.dur.ac.uk (localhost [127.0.0.1]) by vega-c.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q49J3FPc017342; Wed, 9 May 2012 20:03:15 +0100 Received: from localhost (dcl0may@localhost) by vega-c.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q49J3Fk2017337; Wed, 9 May 2012 20:03:15 +0100 Date: Wed, 9 May 2012 20:03:15 +0100 (BST) From: M A Young To: Keir Fraser In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1587021364-1336590195=:14172" X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q49J3Usr014649 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1587021364-1336590195=:14172 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 8 May 2012, Keir Fraser wrote: > Thanks. The same appears to be true in xen-unstable also. Is the solution to > simply remove -O0 from the command line? We can test that out in > xen-unstable if so, and backport if it causes no problems. I got it to build with the attached patch - http://koji.fedoraproject.org/koji/taskinfo?taskID=4063767 . It seems the -O0 option was masking some other compile issues so I had to add -Wno-error=unused-result -Wno-error=array-bounds as well though I imagine the right solution would be to fix the code so it doesn't give warnings (if they haven't already been fixed in xen-unstable). Michael Young --8323329-1587021364-1336590195=:14172 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=f17buildfix.patch Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename=f17buildfix.patch LS0tIHhlbi00LjEuMy90b29scy9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUu b3JpZwkyMDEyLTA1LTA3IDE3OjMyOjMxLjAwMDAwMDAwMCArMDEwMA0KKysr IHhlbi00LjEuMy90b29scy9ibGt0YXAyL2RyaXZlcnMvTWFrZWZpbGUJMjAx Mi0wNS0wOCAyMTozMjo0OC45NzU4Njg5MTMgKzAxMDANCkBAIC05LDcgKzks NyBAQA0KIExPQ0tfVVRJTCAgPSBsb2NrLXV0aWwNCiBJTlNUX0RJUiAgID0g JChTQklORElSKQ0KIA0KLUNGTEFHUyAgICArPSAtV2Vycm9yIC1nIC1PMA0K K0NGTEFHUyAgICArPSAtV2Vycm9yIC1nIC1Xbm8tZXJyb3I9dW51c2VkLXJl c3VsdCAtV25vLWVycm9yPWFycmF5LWJvdW5kcw0KIENGTEFHUyAgICArPSAt V25vLXVudXNlZA0KIENGTEFHUyAgICArPSAtZm5vLXN0cmljdC1hbGlhc2lu Zw0KIENGTEFHUyAgICArPSAtSSQoQkxLVEFQX1JPT1QpL2luY2x1ZGUgLUkk KEJMS1RBUF9ST09UKS9kcml2ZXJzDQotLS0geGVuLTQuMS4zL3Rvb2xzL3Nl Y3VyaXR5L01ha2VmaWxlLm9yaWcJMjAxMi0wNS0wNyAxNzozMjozMi4wMDAw MDAwMDAgKzAxMDANCisrKyB4ZW4tNC4xLjMvdG9vbHMvc2VjdXJpdHkvTWFr ZWZpbGUJMjAxMi0wNS0wOCAyMTozNDozNS40Nzk1Mzc0MzUgKzAxMDANCkBA IC03Niw3ICs3Niw3IEBADQogCWNobW9kIDcwMCAkKEFDTV9TQ1JJUFRTKQ0K IA0KIHhlbnNlY190b29sOiAkKE9CSlNfVE9PTCkNCi0JJChDQykgLWcgJChD RkxBR1MpICQoTERGTEFHUykgLU8wIC1vICRAICReICQoTERMSUJTX2xpYnhl bmN0cmwpDQorCSQoQ0MpIC1nICQoQ0ZMQUdTKSAkKExERkxBR1MpIC1vICRA ICReICQoTERMSUJTX2xpYnhlbmN0cmwpDQogDQogeGVuc2VjX2dlbjogeGVu c2VjX2dlbi5weQ0KIAljcCAtZiAkXiAkQA0K --8323329-1587021364-1336590195=:14172 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --8323329-1587021364-1336590195=:14172-- From xen-devel-bounces@lists.xen.org Wed May 09 19:11:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCHd-0002x3-Bn; Wed, 09 May 2012 19:10:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCHc-0002wy-4N for xen-devel@lists.xen.org; Wed, 09 May 2012 19:10:44 +0000 Received: from [85.158.143.99:55208] by server-1.bemta-4.messagelabs.com id F5/AA-20925-331CAAF4; Wed, 09 May 2012 19:10:43 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336590641!27261730!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2585 invoked from network); 9 May 2012 19:10:42 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 19:10:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330923600"; d="scan'208";a="25036513" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:10:41 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 15:10:40 -0400 Message-ID: <4FAAC12F.8010507@citrix.com> Date: Wed, 9 May 2012 20:10:39 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.4.1 Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 20:03, M A Young wrote: > On Tue, 8 May 2012, Keir Fraser wrote: > >> Thanks. The same appears to be true in xen-unstable also. Is the solution to >> simply remove -O0 from the command line? We can test that out in >> xen-unstable if so, and backport if it causes no problems. > I got it to build with the attached patch - > http://koji.fedoraproject.org/koji/taskinfo?taskID=4063767 . > > It seems the -O0 option was masking some other compile issues so I had to > add -Wno-error=unused-result -Wno-error=array-bounds as well though I > imagine the right solution would be to fix the code so it doesn't give > warnings (if they haven't already been fixed in xen-unstable). > > Michael Young If it is failing -Warray-bounds then the source code probably needs fixing. Do you have a log of the failures caused by -Warray-bounds ? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:11:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCHd-0002x3-Bn; Wed, 09 May 2012 19:10:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCHc-0002wy-4N for xen-devel@lists.xen.org; Wed, 09 May 2012 19:10:44 +0000 Received: from [85.158.143.99:55208] by server-1.bemta-4.messagelabs.com id F5/AA-20925-331CAAF4; Wed, 09 May 2012 19:10:43 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336590641!27261730!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDM3ODM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2585 invoked from network); 9 May 2012 19:10:42 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 9 May 2012 19:10:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330923600"; d="scan'208";a="25036513" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 15:10:41 -0400 Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 15:10:40 -0400 Message-ID: <4FAAC12F.8010507@citrix.com> Date: Wed, 9 May 2012 20:10:39 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.4.1 Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/05/12 20:03, M A Young wrote: > On Tue, 8 May 2012, Keir Fraser wrote: > >> Thanks. The same appears to be true in xen-unstable also. Is the solution to >> simply remove -O0 from the command line? We can test that out in >> xen-unstable if so, and backport if it causes no problems. > I got it to build with the attached patch - > http://koji.fedoraproject.org/koji/taskinfo?taskID=4063767 . > > It seems the -O0 option was masking some other compile issues so I had to > add -Wno-error=unused-result -Wno-error=array-bounds as well though I > imagine the right solution would be to fix the code so it doesn't give > warnings (if they haven't already been fixed in xen-unstable). > > Michael Young If it is failing -Warray-bounds then the source code probably needs fixing. Do you have a log of the failures caused by -Warray-bounds ? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:19:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19: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 ) id 1SSCPB-00036G-Au; Wed, 09 May 2012 19:18:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCPA-00036B-Dh for xen-devel@lists.xen.org; Wed, 09 May 2012 19:18:32 +0000 Received: from [85.158.139.83:7629] by server-3.bemta-5.messagelabs.com id 4C/63-25237-703CAAF4; Wed, 09 May 2012 19:18:31 +0000 X-Env-Sender: djmagee@mageenet.net X-Msg-Ref: server-11.tower-182.messagelabs.com!1336591109!20308431!1 X-Originating-IP: [64.78.148.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 599 invoked from network); 9 May 2012 19:18:30 -0000 Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 19:18:30 -0000 Received: from mnetexch2.adamapps.host ([172.23.68.3]) by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q49JISHm030402; Wed, 9 May 2012 15:18:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 9 May 2012 15:18:46 -0400 Message-ID: In-Reply-To: <201205092059.17957.pavel@netsafe.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] ATI/AMD VGA passthru report Thread-Index: Ac0uFrb3v3NhzMjWTv6Nzn+QUHKtuAAANrSA References: <201205071345.23619.pavel@netsafe.cz><201205081312.39927.pavel@netsafe.cz><20120509174426.GD9094@phenom.dumpdata.com> <201205092059.17957.pavel@netsafe.cz> From: To: =?UTF-8?B?UGF2ZWwgTWF0xJtqYQ==?= , X-Spam-Score: undef - spam scanning disabled X-CanItPRO-Stream: internal X-Canit-Stats-ID: Bayes signature not available Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Pavel Mateja > Sent: Wednesday, May 09, 2012 2:59 PM > To: xen-devel@lists.xen.org > Cc: Konrad Rzeszutek Wilk > Subject: Re: [Xen-devel] ATI/AMD VGA passthru report > > On Wed 9. of May 2012 19:44:26 Konrad Rzeszutek Wilk wrote: > > > I tried to run some games as well but the feeling is much worse > > > compared to older configuration. Like lags.. > > > > Do the lags disappear if you pin the vCPUs? > > One stupid question: > I tried: > xl vcpu-list > Name ID VCPU CPU State Time(s) CPU > Affinity > Domain-0 0 0 3 -b- 74.8 any > cpu > Domain-0 0 1 2 -b- 7.7 any > cpu > Domain-0 0 2 5 -b- 7.4 any > cpu > Domain-0 0 3 2 -b- 8.2 any > cpu > Domain-0 0 4 0 r-- 8.4 any > cpu > Domain-0 0 5 1 -b- 7.4 any > cpu > windows 2 0 3 -b- 27.8 1-5 > windows 2 1 4 -b- 23.5 1-5 > windows 2 2 5 -b- 24.9 1-5 > windows 2 3 1 -b- 27.3 1-5 > windows 2 4 1 -b- 25.2 1-5 > > Do the last two lines mean that two vCPUs in winows are running on one > real? > The output changes and mostly is real - virtual cpu mapped one to one. > I have to study the pinning more. I guess I was wrong when I wrote I > already have it. In my experience passing through video and sound devices, performance in the guest is noticeably better if you pin the domU vCpus 1:1 with pCpus. As an example, on a 4 core machine, I'll pin the dom0 cpus 1:1 using the dom0_vcpu_pin boot line argument, and restrict dom0 to 1 or 2 cpus. Then, for a 2 vcpu domu, after I start the guest, I'll do 'xl vcpu-pin 1 0 2; xl vcpu-pin 1 1 3'. This way guest cpu 0 is always running on physical cpu 2 and guest 1 on physical 3. I don't think there's currently a way in xl config to do this on xl create, which is why I pin after I create the domain. That is, I think you can only set the affinity for all vcpus in the config file, and not per-vcpu. > -- > Pavel Mateja > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:19:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19: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 ) id 1SSCPB-00036G-Au; Wed, 09 May 2012 19:18:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCPA-00036B-Dh for xen-devel@lists.xen.org; Wed, 09 May 2012 19:18:32 +0000 Received: from [85.158.139.83:7629] by server-3.bemta-5.messagelabs.com id 4C/63-25237-703CAAF4; Wed, 09 May 2012 19:18:31 +0000 X-Env-Sender: djmagee@mageenet.net X-Msg-Ref: server-11.tower-182.messagelabs.com!1336591109!20308431!1 X-Originating-IP: [64.78.148.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 599 invoked from network); 9 May 2012 19:18:30 -0000 Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 19:18:30 -0000 Received: from mnetexch2.adamapps.host ([172.23.68.3]) by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q49JISHm030402; Wed, 9 May 2012 15:18:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 9 May 2012 15:18:46 -0400 Message-ID: In-Reply-To: <201205092059.17957.pavel@netsafe.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Xen-devel] ATI/AMD VGA passthru report Thread-Index: Ac0uFrb3v3NhzMjWTv6Nzn+QUHKtuAAANrSA References: <201205071345.23619.pavel@netsafe.cz><201205081312.39927.pavel@netsafe.cz><20120509174426.GD9094@phenom.dumpdata.com> <201205092059.17957.pavel@netsafe.cz> From: To: =?UTF-8?B?UGF2ZWwgTWF0xJtqYQ==?= , X-Spam-Score: undef - spam scanning disabled X-CanItPRO-Stream: internal X-Canit-Stats-ID: Bayes signature not available Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] ATI/AMD VGA passthru report X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Pavel Mateja > Sent: Wednesday, May 09, 2012 2:59 PM > To: xen-devel@lists.xen.org > Cc: Konrad Rzeszutek Wilk > Subject: Re: [Xen-devel] ATI/AMD VGA passthru report > > On Wed 9. of May 2012 19:44:26 Konrad Rzeszutek Wilk wrote: > > > I tried to run some games as well but the feeling is much worse > > > compared to older configuration. Like lags.. > > > > Do the lags disappear if you pin the vCPUs? > > One stupid question: > I tried: > xl vcpu-list > Name ID VCPU CPU State Time(s) CPU > Affinity > Domain-0 0 0 3 -b- 74.8 any > cpu > Domain-0 0 1 2 -b- 7.7 any > cpu > Domain-0 0 2 5 -b- 7.4 any > cpu > Domain-0 0 3 2 -b- 8.2 any > cpu > Domain-0 0 4 0 r-- 8.4 any > cpu > Domain-0 0 5 1 -b- 7.4 any > cpu > windows 2 0 3 -b- 27.8 1-5 > windows 2 1 4 -b- 23.5 1-5 > windows 2 2 5 -b- 24.9 1-5 > windows 2 3 1 -b- 27.3 1-5 > windows 2 4 1 -b- 25.2 1-5 > > Do the last two lines mean that two vCPUs in winows are running on one > real? > The output changes and mostly is real - virtual cpu mapped one to one. > I have to study the pinning more. I guess I was wrong when I wrote I > already have it. In my experience passing through video and sound devices, performance in the guest is noticeably better if you pin the domU vCpus 1:1 with pCpus. As an example, on a 4 core machine, I'll pin the dom0 cpus 1:1 using the dom0_vcpu_pin boot line argument, and restrict dom0 to 1 or 2 cpus. Then, for a 2 vcpu domu, after I start the guest, I'll do 'xl vcpu-pin 1 0 2; xl vcpu-pin 1 1 3'. This way guest cpu 0 is always running on physical cpu 2 and guest 1 on physical 3. I don't think there's currently a way in xl config to do this on xl create, which is why I pin after I create the domain. That is, I think you can only set the affinity for all vcpus in the config file, and not per-vcpu. > -- > Pavel Mateja > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:44:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:44:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCnP-0003Mn-7d; Wed, 09 May 2012 19:43:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCnM-0003Mi-VM for xen-devel@lists.xensource.com; Wed, 09 May 2012 19:43:33 +0000 Received: from [193.109.254.147:55614] by server-12.bemta-14.messagelabs.com id B4/00-05898-4E8CAAF4; Wed, 09 May 2012 19:43:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336592610!8448201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13263 invoked from network); 9 May 2012 19:43: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; 9 May 2012 19:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="12388475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 19:43: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, 9 May 2012 20:43:30 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSCnJ-0001ba-Rw; Wed, 09 May 2012 19:43:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSCnJ-0007Ml-Qb; Wed, 09 May 2012 20:43:29 +0100 To: Message-ID: From: xen.org Date: Wed, 9 May 2012 20:43:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12826: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12826 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12826/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-qemuu-winxpsp3 8 guest-saverestore 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-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux bea37381fd9a34c6660e5195d31beea86aa3dda3 baseline version: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=bea37381fd9a34c6660e5195d31beea86aa3dda3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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-3.0 bea37381fd9a34c6660e5195d31beea86aa3dda3 + branch=linux-3.0 + revision=bea37381fd9a34c6660e5195d31beea86aa3dda3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git bea37381fd9a34c6660e5195d31beea86aa3dda3:tested/linux-3.0 Counting objects: 1 Counting objects: 403, done. Compressing objects: 1% (1/51) Compressing objects: 3% (2/51) Compressing objects: 5% (3/51) Compressing objects: 7% (4/51) Compressing objects: 9% (5/51) Compressing objects: 11% (6/51) Compressing objects: 13% (7/51) Compressing objects: 15% (8/51) Compressing objects: 17% (9/51) Compressing objects: 19% (10/51) Compressing objects: 21% (11/51) Compressing objects: 23% (12/51) Compressing objects: 25% (13/51) Compressing objects: 27% (14/51) Compressing objects: 29% (15/51) Compressing objects: 31% (16/51) Compressing objects: 33% (17/51) Compressing objects: 35% (18/51) Compressing objects: 37% (19/51) Compressing objects: 39% (20/51) Compressing objects: 41% (21/51) Compressing objects: 43% (22/51) Compressing objects: 45% (23/51) Compressing objects: 47% (24/51) Compressing objects: 49% (25/51) Compressing objects: 50% (26/51) Compressing objects: 52% (27/51) Compressing objects: 54% (28/51) Compressing objects: 56% (29/51) Compressing objects: 58% (30/51) Compressing objects: 60% (31/51) Compressing objects: 62% (32/51) Compressing objects: 64% (33/51) Compressing objects: 66% (34/51) Compressing objects: 68% (35/51) Compressing objects: 70% (36/51) Compressing objects: 72% (37/51) Compressing objects: 74% (38/51) Compressing objects: 76% (39/51) Compressing objects: 78% (40/51) Compressing objects: 80% (41/51) Compressing objects: 82% (42/51) Compressing objects: 84% (43/51) Compressing objects: 86% (44/51) Compressing objects: 88% (45/51) Compressing objects: 90% (46/51) Compressing objects: 92% (47/51) Compressing objects: 94% (48/51) Compressing objects: 96% (49/51) Compressing objects: 98% (50/51) Compressing objects: 100% (51/51) Compressing objects: 100% (51/51), done. Writing objects: 0% (1/296) Writing objects: 1% (3/296) Writing objects: 2% (6/296) Writing objects: 3% (9/296) Writing objects: 4% (12/296) Writing objects: 5% (15/296) Writing objects: 6% (18/296) Writing objects: 7% (21/296) Writing objects: 8% (24/296) Writing objects: 9% (27/296) Writing objects: 10% (30/296) Writing objects: 11% (33/296) Writing objects: 12% (37/296) Writing objects: 13% (39/296) Writing objects: 14% (42/296) Writing objects: 15% (45/296) Writing objects: 16% (48/296) Writing objects: 17% (51/296) Writing objects: 18% (54/296) Writing objects: 19% (57/296) Writing objects: 20% (60/296) Writing objects: 21% (63/296) Writing objects: 22% (66/296) Writing objects: 23% (69/296) Writing objects: 24% (72/296) Writing objects: 25% (74/296) Writing objects: 26% (77/296) Writing objects: 27% (80/296) Writing objects: 28% (83/296) Writing objects: 29% (86/296) Writing objects: 30% (89/296) Writing objects: 31% (92/296) Writing objects: 32% (95/296) Writing objects: 33% (98/296) Writing objects: 34% (101/296) Writing objects: 35% (104/296) Writing objects: 36% (107/296) Writing objects: 37% (110/296) Writing objects: 38% (113/296) Writing objects: 39% (116/296) Writing objects: 40% (119/296) Writing objects: 41% (122/296) Writing objects: 42% (125/296) Writing objects: 43% (128/296) Writing objects: 44% (131/296) Writing objects: 45% (134/296) Writing objects: 46% (137/296) Writing objects: 47% (140/296) Writing objects: 48% (143/296) Writing objects: 49% (146/296) Writing objects: 50% (148/296) Writing objects: 51% (151/296) Writing objects: 52% (154/296) Writing objects: 53% (157/296) Writing objects: 54% (160/296) Writing objects: 55% (163/296) Writing objects: 56% (166/296) Writing objects: 57% (169/296) Writing objects: 58% (172/296) Writing objects: 59% (175/296) Writing objects: 60% (178/296) Writing objects: 61% (181/296) Writing objects: 62% (184/296) Writing objects: 63% (187/296) Writing objects: 64% (190/296) Writing objects: 65% (193/296) Writing objects: 66% (196/296) Writing objects: 67% (199/296) Writing objects: 68% (202/296) Writing objects: 69% (205/296) Writing objects: 70% (208/296) Writing objects: 71% (211/296) Writing objects: 72% (214/296) Writing objects: 73% (217/296) Writing objects: 74% (220/296) Writing objects: 75% (222/296) Writing objects: 76% (225/296) Writing objects: 77% (228/296) Writing objects: 78% (231/296) Writing objects: 79% (234/296) Writing objects: 80% (237/296) Writing objects: 81% (240/296) Writing objects: 82% (243/296) Writing objects: 83% (246/296) Writing objects: 84% (249/296) Writing objects: 85% (252/296) Writing objects: 86% (255/296) Writing objects: 87% (258/296) Writing objects: 88% (261/296) Writing objects: 89% (264/296) Writing objects: 90% (267/296) Writing objects: 91% (270/296) Writing objects: 92% (273/296) Writing objects: 93% (276/296) Writing objects: 94% (279/296) Writing objects: 95% (282/296) Writing objects: 96% (285/296) Writing objects: 97% (288/296) Writing objects: 98% (291/296) Writing objects: 99% (294/296) Writing objects: 100% (296/296) Writing objects: 100% (296/296), 55.09 KiB, done. Total 296 (delta 243), reused 296 (delta 243) To xen@xenbits.xensource.com:git/linux-pvops.git f1c84a5..bea3738 bea37381fd9a34c6660e5195d31beea86aa3dda3 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 19:44:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 19:44:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCnP-0003Mn-7d; Wed, 09 May 2012 19:43:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSCnM-0003Mi-VM for xen-devel@lists.xensource.com; Wed, 09 May 2012 19:43:33 +0000 Received: from [193.109.254.147:55614] by server-12.bemta-14.messagelabs.com id B4/00-05898-4E8CAAF4; Wed, 09 May 2012 19:43:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1336592610!8448201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5NzkzMQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13263 invoked from network); 9 May 2012 19:43: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; 9 May 2012 19:43:31 -0000 X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="12388475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 May 2012 19:43: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, 9 May 2012 20:43:30 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSCnJ-0001ba-Rw; Wed, 09 May 2012 19:43:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSCnJ-0007Ml-Qb; Wed, 09 May 2012 20:43:29 +0100 To: Message-ID: From: xen.org Date: Wed, 9 May 2012 20:43:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 12826: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12826 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12826/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore 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-qemuu-winxpsp3 8 guest-saverestore 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-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: linux bea37381fd9a34c6660e5195d31beea86aa3dda3 baseline version: linux f1c84a5cb52ee2915457b481c756fcc1dfe6a471 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 pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=bea37381fd9a34c6660e5195d31beea86aa3dda3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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-3.0 bea37381fd9a34c6660e5195d31beea86aa3dda3 + branch=linux-3.0 + revision=bea37381fd9a34c6660e5195d31beea86aa3dda3 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git bea37381fd9a34c6660e5195d31beea86aa3dda3:tested/linux-3.0 Counting objects: 1 Counting objects: 403, done. Compressing objects: 1% (1/51) Compressing objects: 3% (2/51) Compressing objects: 5% (3/51) Compressing objects: 7% (4/51) Compressing objects: 9% (5/51) Compressing objects: 11% (6/51) Compressing objects: 13% (7/51) Compressing objects: 15% (8/51) Compressing objects: 17% (9/51) Compressing objects: 19% (10/51) Compressing objects: 21% (11/51) Compressing objects: 23% (12/51) Compressing objects: 25% (13/51) Compressing objects: 27% (14/51) Compressing objects: 29% (15/51) Compressing objects: 31% (16/51) Compressing objects: 33% (17/51) Compressing objects: 35% (18/51) Compressing objects: 37% (19/51) Compressing objects: 39% (20/51) Compressing objects: 41% (21/51) Compressing objects: 43% (22/51) Compressing objects: 45% (23/51) Compressing objects: 47% (24/51) Compressing objects: 49% (25/51) Compressing objects: 50% (26/51) Compressing objects: 52% (27/51) Compressing objects: 54% (28/51) Compressing objects: 56% (29/51) Compressing objects: 58% (30/51) Compressing objects: 60% (31/51) Compressing objects: 62% (32/51) Compressing objects: 64% (33/51) Compressing objects: 66% (34/51) Compressing objects: 68% (35/51) Compressing objects: 70% (36/51) Compressing objects: 72% (37/51) Compressing objects: 74% (38/51) Compressing objects: 76% (39/51) Compressing objects: 78% (40/51) Compressing objects: 80% (41/51) Compressing objects: 82% (42/51) Compressing objects: 84% (43/51) Compressing objects: 86% (44/51) Compressing objects: 88% (45/51) Compressing objects: 90% (46/51) Compressing objects: 92% (47/51) Compressing objects: 94% (48/51) Compressing objects: 96% (49/51) Compressing objects: 98% (50/51) Compressing objects: 100% (51/51) Compressing objects: 100% (51/51), done. Writing objects: 0% (1/296) Writing objects: 1% (3/296) Writing objects: 2% (6/296) Writing objects: 3% (9/296) Writing objects: 4% (12/296) Writing objects: 5% (15/296) Writing objects: 6% (18/296) Writing objects: 7% (21/296) Writing objects: 8% (24/296) Writing objects: 9% (27/296) Writing objects: 10% (30/296) Writing objects: 11% (33/296) Writing objects: 12% (37/296) Writing objects: 13% (39/296) Writing objects: 14% (42/296) Writing objects: 15% (45/296) Writing objects: 16% (48/296) Writing objects: 17% (51/296) Writing objects: 18% (54/296) Writing objects: 19% (57/296) Writing objects: 20% (60/296) Writing objects: 21% (63/296) Writing objects: 22% (66/296) Writing objects: 23% (69/296) Writing objects: 24% (72/296) Writing objects: 25% (74/296) Writing objects: 26% (77/296) Writing objects: 27% (80/296) Writing objects: 28% (83/296) Writing objects: 29% (86/296) Writing objects: 30% (89/296) Writing objects: 31% (92/296) Writing objects: 32% (95/296) Writing objects: 33% (98/296) Writing objects: 34% (101/296) Writing objects: 35% (104/296) Writing objects: 36% (107/296) Writing objects: 37% (110/296) Writing objects: 38% (113/296) Writing objects: 39% (116/296) Writing objects: 40% (119/296) Writing objects: 41% (122/296) Writing objects: 42% (125/296) Writing objects: 43% (128/296) Writing objects: 44% (131/296) Writing objects: 45% (134/296) Writing objects: 46% (137/296) Writing objects: 47% (140/296) Writing objects: 48% (143/296) Writing objects: 49% (146/296) Writing objects: 50% (148/296) Writing objects: 51% (151/296) Writing objects: 52% (154/296) Writing objects: 53% (157/296) Writing objects: 54% (160/296) Writing objects: 55% (163/296) Writing objects: 56% (166/296) Writing objects: 57% (169/296) Writing objects: 58% (172/296) Writing objects: 59% (175/296) Writing objects: 60% (178/296) Writing objects: 61% (181/296) Writing objects: 62% (184/296) Writing objects: 63% (187/296) Writing objects: 64% (190/296) Writing objects: 65% (193/296) Writing objects: 66% (196/296) Writing objects: 67% (199/296) Writing objects: 68% (202/296) Writing objects: 69% (205/296) Writing objects: 70% (208/296) Writing objects: 71% (211/296) Writing objects: 72% (214/296) Writing objects: 73% (217/296) Writing objects: 74% (220/296) Writing objects: 75% (222/296) Writing objects: 76% (225/296) Writing objects: 77% (228/296) Writing objects: 78% (231/296) Writing objects: 79% (234/296) Writing objects: 80% (237/296) Writing objects: 81% (240/296) Writing objects: 82% (243/296) Writing objects: 83% (246/296) Writing objects: 84% (249/296) Writing objects: 85% (252/296) Writing objects: 86% (255/296) Writing objects: 87% (258/296) Writing objects: 88% (261/296) Writing objects: 89% (264/296) Writing objects: 90% (267/296) Writing objects: 91% (270/296) Writing objects: 92% (273/296) Writing objects: 93% (276/296) Writing objects: 94% (279/296) Writing objects: 95% (282/296) Writing objects: 96% (285/296) Writing objects: 97% (288/296) Writing objects: 98% (291/296) Writing objects: 99% (294/296) Writing objects: 100% (296/296) Writing objects: 100% (296/296), 55.09 KiB, done. Total 296 (delta 243), reused 296 (delta 243) To xen@xenbits.xensource.com:git/linux-pvops.git f1c84a5..bea3738 bea37381fd9a34c6660e5195d31beea86aa3dda3 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 20:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 20: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 ) id 1SSDXK-0003i4-AD; Wed, 09 May 2012 20:31:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSDXI-0003hz-SO for xen-devel@lists.xen.org; Wed, 09 May 2012 20:31:00 +0000 Received: from [85.158.139.83:37485] by server-8.bemta-5.messagelabs.com id A0/CB-26964-304DAAF4; Wed, 09 May 2012 20:30:59 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-182.messagelabs.com!1336595458!23593860!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzczMjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzczMjg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29356 invoked from network); 9 May 2012 20:30:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 20:30:59 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0HECo= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-084-093.pools.arcor-ip.net [88.65.84.93]) by smtp.strato.de (jorabe mo38) (RZmta 29.6 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j07867o49JrFhH ; Wed, 9 May 2012 22:30:58 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A34EF18637; Wed, 9 May 2012 22:30:57 +0200 (CEST) Date: Wed, 9 May 2012 22:30:57 +0200 From: Olaf Hering To: Andrew Cooper Message-ID: <20120509203057.GA19370@aepfle.de> References: <4FAAC12F.8010507@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAAC12F.8010507@citrix.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, Andrew Cooper wrote: > If it is failing -Warray-bounds then the source code probably needs fixing. > > Do you have a log of the failures caused by -Warray-bounds ? http://lists.xen.org/archives/html/xen-devel/2012-03/msg02583.html Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed May 09 20:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 May 2012 20: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 ) id 1SSDXK-0003i4-AD; Wed, 09 May 2012 20:31:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSDXI-0003hz-SO for xen-devel@lists.xen.org; Wed, 09 May 2012 20:31:00 +0000 Received: from [85.158.139.83:37485] by server-8.bemta-5.messagelabs.com id A0/CB-26964-304DAAF4; Wed, 09 May 2012 20:30:59 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-182.messagelabs.com!1336595458!23593860!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzczMjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzczMjg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29356 invoked from network); 9 May 2012 20:30:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2012 20:30:59 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0HECo= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-084-093.pools.arcor-ip.net [88.65.84.93]) by smtp.strato.de (jorabe mo38) (RZmta 29.6 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j07867o49JrFhH ; Wed, 9 May 2012 22:30:58 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A34EF18637; Wed, 9 May 2012 22:30:57 +0200 (CEST) Date: Wed, 9 May 2012 22:30:57 +0200 From: Olaf Hering To: Andrew Cooper Message-ID: <20120509203057.GA19370@aepfle.de> References: <4FAAC12F.8010507@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAAC12F.8010507@citrix.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, Andrew Cooper wrote: > If it is failing -Warray-bounds then the source code probably needs fixing. > > Do you have a log of the failures caused by -Warray-bounds ? http://lists.xen.org/archives/html/xen-devel/2012-03/msg02583.html Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 07:14:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 07:14:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSNZW-0002F4-DU; Thu, 10 May 2012 07:13:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSNZU-0002Ez-Ll for xen-devel@lists.xensource.com; Thu, 10 May 2012 07:13:57 +0000 Received: from [193.109.254.147:64111] by server-5.bemta-14.messagelabs.com id 7E/5F-30733-3BA6BAF4; Thu, 10 May 2012 07:13:55 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336634034!3356904!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODAzMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27650 invoked from network); 10 May 2012 07:13:55 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 07:13:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,563,1330905600"; d="scan'208";a="12393980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:13: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, 10 May 2012 08:13:54 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSNZS-0005Gb-6K; Thu, 10 May 2012 07:13:54 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSNZS-00056K-0l; Thu, 10 May 2012 08:13:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 10 May 2012 08:13:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12827: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12827 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12827/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12823 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 12806 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 07:14:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 07:14:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSNZW-0002F4-DU; Thu, 10 May 2012 07:13:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSNZU-0002Ez-Ll for xen-devel@lists.xensource.com; Thu, 10 May 2012 07:13:57 +0000 Received: from [193.109.254.147:64111] by server-5.bemta-14.messagelabs.com id 7E/5F-30733-3BA6BAF4; Thu, 10 May 2012 07:13:55 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336634034!3356904!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODAzMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27650 invoked from network); 10 May 2012 07:13:55 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 07:13:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,563,1330905600"; d="scan'208";a="12393980" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:13: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, 10 May 2012 08:13:54 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSNZS-0005Gb-6K; Thu, 10 May 2012 07:13:54 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSNZS-00056K-0l; Thu, 10 May 2012 08:13:54 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 10 May 2012 08:13:54 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12827: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12827 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12827/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12823 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 12806 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 8a86d841e6d4 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 07:49:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 07: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 ) id 1SSO7R-0002Tb-N5; Thu, 10 May 2012 07:49:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSO7P-0002TW-Uo for xen-devel@lists.xen.org; Thu, 10 May 2012 07:49:00 +0000 Received: from [85.158.143.99:49440] by server-2.bemta-4.messagelabs.com id 2A/0A-17550-AE27BAF4; Thu, 10 May 2012 07:48:58 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336636136!20268223!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30307 invoked from network); 10 May 2012 07:48:57 -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; 10 May 2012 07:48:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 08:48:55 +0100 Message-Id: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 08:49:17 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] qemu xen_disk mis-accounting? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ioreq_release() gets called from two places, yet only in the blk_send_response_all() case does it appear appropriate to decrement blkdev->requests_finished. In the error handling path of blk_handle_requests() I would think it should decrement blkdev->requests_inflight instead. While blkdev->requests_finished isn't being used anywhere, blkdev->requests_inflight serves blk_handle_requests() to tell whether to call qemu_bh_schedule(), so this isn't a purely cosmetic mistake afaics (and the error path in question is actually being consistently exercised by our frontends probing for the packet command extension - yes, it should have been implemented via xenstore node presence, but the author failed to do so back then). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 07:49:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 07: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 ) id 1SSO7R-0002Tb-N5; Thu, 10 May 2012 07:49:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSO7P-0002TW-Uo for xen-devel@lists.xen.org; Thu, 10 May 2012 07:49:00 +0000 Received: from [85.158.143.99:49440] by server-2.bemta-4.messagelabs.com id 2A/0A-17550-AE27BAF4; Thu, 10 May 2012 07:48:58 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336636136!20268223!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30307 invoked from network); 10 May 2012 07:48:57 -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; 10 May 2012 07:48:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 08:48:55 +0100 Message-Id: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 08:49:17 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] qemu xen_disk mis-accounting? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ioreq_release() gets called from two places, yet only in the blk_send_response_all() case does it appear appropriate to decrement blkdev->requests_finished. In the error handling path of blk_handle_requests() I would think it should decrement blkdev->requests_inflight instead. While blkdev->requests_finished isn't being used anywhere, blkdev->requests_inflight serves blk_handle_requests() to tell whether to call qemu_bh_schedule(), so this isn't a purely cosmetic mistake afaics (and the error path in question is actually being consistently exercised by our frontends probing for the packet command extension - yes, it should have been implemented via xenstore node presence, but the author failed to do so back then). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:21:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPYJ-0003bp-0t; Thu, 10 May 2012 09:20:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPYH-0003bj-9w for xen-devel@lists.xen.org; Thu, 10 May 2012 09:20:49 +0000 Received: from [85.158.143.99:4001] by server-1.bemta-4.messagelabs.com id 48/D8-20925-F688BAF4; Thu, 10 May 2012 09:20:47 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336641644!20287345!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4827 invoked from network); 10 May 2012 09:20:45 -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; 10 May 2012 09:20:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 10:20:44 +0100 Message-Id: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 10:21:05 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part95BB7C91.1__=" Cc: andrew.cooper3@citrix.com Subject: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part95BB7C91.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Without this, dump_irqs() may try to acquire the lock the caller is currently holding. Signed-off-by: Jan Beulich --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -668,6 +668,7 @@ void irq_move_cleanup_interrupt(struct c { if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) = ) { + spin_unlock(&desc->lock); bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch), desc->arch.used_vectors->_bits, --=__Part95BB7C91.1__= Content-Type: text/plain; name="x86-24707-locking.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-24707-locking.patch" x86/irq: fix locking for c/s 24707:96987c324a4f debugging code=0A=0AWithout= this, dump_irqs() may try to acquire the lock the caller is=0Acurrently = holding.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -668,6 +668,7 @@ void = irq_move_cleanup_interrupt(struct c=0A {=0A if = ( unlikely(!test_bit(vector, desc->arch.used_vectors)) )=0A = {=0A+ spin_unlock(&desc->lock);=0A = bitmap_scnlistprintf(keyhandler_scratch,=0A = sizeof(keyhandler_scratch),=0A = desc->arch.used_vectors->_bits,=0A --=__Part95BB7C91.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part95BB7C91.1__=-- From xen-devel-bounces@lists.xen.org Thu May 10 09:21:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPYJ-0003bp-0t; Thu, 10 May 2012 09:20:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPYH-0003bj-9w for xen-devel@lists.xen.org; Thu, 10 May 2012 09:20:49 +0000 Received: from [85.158.143.99:4001] by server-1.bemta-4.messagelabs.com id 48/D8-20925-F688BAF4; Thu, 10 May 2012 09:20:47 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336641644!20287345!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4827 invoked from network); 10 May 2012 09:20:45 -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; 10 May 2012 09:20:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 10:20:44 +0100 Message-Id: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 10:21:05 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part95BB7C91.1__=" Cc: andrew.cooper3@citrix.com Subject: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part95BB7C91.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Without this, dump_irqs() may try to acquire the lock the caller is currently holding. Signed-off-by: Jan Beulich --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -668,6 +668,7 @@ void irq_move_cleanup_interrupt(struct c { if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) = ) { + spin_unlock(&desc->lock); bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch), desc->arch.used_vectors->_bits, --=__Part95BB7C91.1__= Content-Type: text/plain; name="x86-24707-locking.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-24707-locking.patch" x86/irq: fix locking for c/s 24707:96987c324a4f debugging code=0A=0AWithout= this, dump_irqs() may try to acquire the lock the caller is=0Acurrently = holding.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -668,6 +668,7 @@ void = irq_move_cleanup_interrupt(struct c=0A {=0A if = ( unlikely(!test_bit(vector, desc->arch.used_vectors)) )=0A = {=0A+ spin_unlock(&desc->lock);=0A = bitmap_scnlistprintf(keyhandler_scratch,=0A = sizeof(keyhandler_scratch),=0A = desc->arch.used_vectors->_bits,=0A --=__Part95BB7C91.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part95BB7C91.1__=-- From xen-devel-bounces@lists.xen.org Thu May 10 09:27:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPe0-0003jj-Tw; Thu, 10 May 2012 09:26:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPdz-0003jd-BJ for xen-devel@lists.xen.org; Thu, 10 May 2012 09:26:43 +0000 Received: from [85.158.143.35:42733] by server-1.bemta-4.messagelabs.com id 00/E3-20925-2D98BAF4; Thu, 10 May 2012 09:26:42 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336641999!12238842!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6438 invoked from network); 10 May 2012 09:26:41 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:26:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194220151" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 05:26:26 -0400 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, 10 May 2012 05:26:26 -0400 Message-ID: <4FAB89C1.6040702@citrix.com> Date: Thu, 10 May 2012 10:26:25 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> In-Reply-To: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 10:21, Jan Beulich wrote: > Without this, dump_irqs() may try to acquire the lock the caller is > currently holding. > > Signed-off-by: Jan Beulich With the proviso that this is patch will disappear when all (3 so far) of these debugging patches disappear. Acked-by: Andrew Cooper > > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -668,6 +668,7 @@ void irq_move_cleanup_interrupt(struct c > { > if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) ) > { > + spin_unlock(&desc->lock); > bitmap_scnlistprintf(keyhandler_scratch, > sizeof(keyhandler_scratch), > desc->arch.used_vectors->_bits, > > > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:27:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPe0-0003jj-Tw; Thu, 10 May 2012 09:26:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPdz-0003jd-BJ for xen-devel@lists.xen.org; Thu, 10 May 2012 09:26:43 +0000 Received: from [85.158.143.35:42733] by server-1.bemta-4.messagelabs.com id 00/E3-20925-2D98BAF4; Thu, 10 May 2012 09:26:42 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336641999!12238842!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6438 invoked from network); 10 May 2012 09:26:41 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:26:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194220151" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 05:26:26 -0400 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, 10 May 2012 05:26:26 -0400 Message-ID: <4FAB89C1.6040702@citrix.com> Date: Thu, 10 May 2012 10:26:25 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Beulich References: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> In-Reply-To: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.1 Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 10:21, Jan Beulich wrote: > Without this, dump_irqs() may try to acquire the lock the caller is > currently holding. > > Signed-off-by: Jan Beulich With the proviso that this is patch will disappear when all (3 so far) of these debugging patches disappear. Acked-by: Andrew Cooper > > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -668,6 +668,7 @@ void irq_move_cleanup_interrupt(struct c > { > if ( unlikely(!test_bit(vector, desc->arch.used_vectors)) ) > { > + spin_unlock(&desc->lock); > bitmap_scnlistprintf(keyhandler_scratch, > sizeof(keyhandler_scratch), > desc->arch.used_vectors->_bits, > > > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:27:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:27:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPeC-0003kQ-A9; Thu, 10 May 2012 09:26:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPeA-0003kF-UM for xen-devel@lists.xen.org; Thu, 10 May 2012 09:26:55 +0000 Received: from [85.158.143.35:56716] by server-2.bemta-4.messagelabs.com id D7/B2-17550-ED98BAF4; Thu, 10 May 2012 09:26:54 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-15.tower-21.messagelabs.com!1336642012!13922086!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2633 invoked from network); 10 May 2012 09:26:52 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-15.tower-21.messagelabs.com with SMTP; 10 May 2012 09:26:52 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77761230; Thu, 10 May 2012 11:26:51 +0200 Message-ID: <1336642009.3376.16.camel@Abyss> From: Dario Faggioli To: Ian Jackson Date: Thu, 10 May 2012 11:26:49 +0200 In-Reply-To: <20394.35813.845562.695653@mariner.uk.xensource.com> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336561898.2621.4.camel@Abyss> <20394.35813.845562.695653@mariner.uk.xensource.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1737679525413951273==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1737679525413951273== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yz3/024UA61m0ObOfe57" --=-yz3/024UA61m0ObOfe57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 16:23 +0100, Ian Jackson wrote:=20 > Dario Faggioli writes ("Re: [PATCH] libxl: use xc_topologyinfo to figure = out how many CPUs we actually have"): > > And, as it is an actual bugfix and very very small in size, not to > > forget that I'd need that for the NUMA placement series, I'm proposing > > this for 4.2... Does it make sense? >=20 > It seems to to me that this is indeed 4.2 material. >=20 Cool. :-) Aside from that, any comments (better if on the v2 here http://permalink.gmane.org/gmane.comp.emulators.xen.devel/130218) ? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-yz3/024UA61m0ObOfe57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+ridkACgkQk4XaBE3IOsSp8ACfWy1WL4wMQ2GOe/H4rAd8UTV3 W+IAn3ugXid79Rh8orpTD2v58UcnZNX8 =Ce2K -----END PGP SIGNATURE----- --=-yz3/024UA61m0ObOfe57-- --===============1737679525413951273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1737679525413951273==-- From xen-devel-bounces@lists.xen.org Thu May 10 09:27:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:27:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPeC-0003kQ-A9; Thu, 10 May 2012 09:26:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPeA-0003kF-UM for xen-devel@lists.xen.org; Thu, 10 May 2012 09:26:55 +0000 Received: from [85.158.143.35:56716] by server-2.bemta-4.messagelabs.com id D7/B2-17550-ED98BAF4; Thu, 10 May 2012 09:26:54 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-15.tower-21.messagelabs.com!1336642012!13922086!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2633 invoked from network); 10 May 2012 09:26:52 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-15.tower-21.messagelabs.com with SMTP; 10 May 2012 09:26:52 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77761230; Thu, 10 May 2012 11:26:51 +0200 Message-ID: <1336642009.3376.16.camel@Abyss> From: Dario Faggioli To: Ian Jackson Date: Thu, 10 May 2012 11:26:49 +0200 In-Reply-To: <20394.35813.845562.695653@mariner.uk.xensource.com> References: <420c8861a2d2a61a7e80.1336561430@Solace> <1336561898.2621.4.camel@Abyss> <20394.35813.845562.695653@mariner.uk.xensource.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: George Dunlap , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1737679525413951273==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1737679525413951273== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yz3/024UA61m0ObOfe57" --=-yz3/024UA61m0ObOfe57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-09 at 16:23 +0100, Ian Jackson wrote:=20 > Dario Faggioli writes ("Re: [PATCH] libxl: use xc_topologyinfo to figure = out how many CPUs we actually have"): > > And, as it is an actual bugfix and very very small in size, not to > > forget that I'd need that for the NUMA placement series, I'm proposing > > this for 4.2... Does it make sense? >=20 > It seems to to me that this is indeed 4.2 material. >=20 Cool. :-) Aside from that, any comments (better if on the v2 here http://permalink.gmane.org/gmane.comp.emulators.xen.devel/130218) ? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-yz3/024UA61m0ObOfe57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+ridkACgkQk4XaBE3IOsSp8ACfWy1WL4wMQ2GOe/H4rAd8UTV3 W+IAn3ugXid79Rh8orpTD2v58UcnZNX8 =Ce2K -----END PGP SIGNATURE----- --=-yz3/024UA61m0ObOfe57-- --===============1737679525413951273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1737679525413951273==-- From xen-devel-bounces@lists.xen.org Thu May 10 09:33:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPkY-000427-6C; Thu, 10 May 2012 09:33:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPkW-00041u-1C for xen-devel@lists.xen.org; Thu, 10 May 2012 09:33:28 +0000 Received: from [85.158.138.51:33334] by server-12.bemta-3.messagelabs.com id 80/35-29760-46B8BAF4; Thu, 10 May 2012 09:33:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336642403!19927937!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23613 invoked from network); 10 May 2012 09:33:24 -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 May 2012 09:33:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 10:33:23 +0100 Message-Id: <4FABA7980200007800082AB9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 10:33:44 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> <4FAB89C1.6040702@citrix.com> In-Reply-To: <4FAB89C1.6040702@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 11:26, Andrew Cooper wrote: > On 10/05/12 10:21, Jan Beulich wrote: >> Without this, dump_irqs() may try to acquire the lock the caller is >> currently holding. >> >> Signed-off-by: Jan Beulich > > With the proviso that this is patch will disappear when all (3 so far) > of these debugging patches disappear. That must be the goal, sure. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:33:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPkY-000427-6C; Thu, 10 May 2012 09:33:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPkW-00041u-1C for xen-devel@lists.xen.org; Thu, 10 May 2012 09:33:28 +0000 Received: from [85.158.138.51:33334] by server-12.bemta-3.messagelabs.com id 80/35-29760-46B8BAF4; Thu, 10 May 2012 09:33:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1336642403!19927937!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23613 invoked from network); 10 May 2012 09:33:24 -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 May 2012 09:33:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 10:33:23 +0100 Message-Id: <4FABA7980200007800082AB9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 10:33:44 +0100 From: "Jan Beulich" To: "Andrew Cooper" References: <4FABA4A10200007800082A9B@nat28.tlf.novell.com> <4FAB89C1.6040702@citrix.com> In-Reply-To: <4FAB89C1.6040702@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] x86/irq: fix locking for c/s 24707:96987c324a4f debugging code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 11:26, Andrew Cooper wrote: > On 10/05/12 10:21, Jan Beulich wrote: >> Without this, dump_irqs() may try to acquire the lock the caller is >> currently holding. >> >> Signed-off-by: Jan Beulich > > With the proviso that this is patch will disappear when all (3 so far) > of these debugging patches disappear. That must be the goal, sure. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:44:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPua-0004BT-9I; Thu, 10 May 2012 09:43:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPuZ-0004BO-2h for xen-devel@lists.xensource.com; Thu, 10 May 2012 09:43:51 +0000 Received: from [193.109.254.147:30908] by server-9.bemta-14.messagelabs.com id 5D/85-05787-6DD8BAF4; Thu, 10 May 2012 09:43:50 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336643027!1715251!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9427 invoked from network); 10 May 2012 09:43:48 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:43:48 -0000 Received: by vbbfq11 with SMTP id fq11so1691258vbb.30 for ; Thu, 10 May 2012 02:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=bHW1xk9b4nRJZn5baZ9bekilQ90bFk+otnDe4mWVv1g=; b=BFiEHb0HE9/V/LnYU+W2fTT0+hjSU9BKlIpKwSQq2LfLBh9499GBfa5IFAxeXvhdiK njETnJD0NUP+LbW9fTHx4cOVw2T7M6X4B/MpSckVZGjgG9zPW5k98A0/TkJVVVOrTPmE BLEL4jm5/izWk8DbgE0N+RXrqrh1RgDaxBpxD75cccLuhS2KlZntgaABa7d/rIYbsClS GV42Zeay0VkuHs5B5Wwx9gl+V4+cC0SZTkB5V0gEkVNv5/UsH6YfcS8UVf9XocUQYSgB hySgq/zclVest1RohugZl/d1v5BbNXySoe2lcEdGYh7ruAAvEk+KStC2LIOHoU6Erme2 np5g== Received: by 10.52.72.137 with SMTP id d9mr1656030vdv.122.1336643027062; Thu, 10 May 2012 02:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:43:26 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:43:26 +0100 Message-ID: To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=bcaec5016301d1cef604bfab7425 Subject: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --bcaec5016301d1cef604bfab7425 Content-Type: text/plain; charset=ISO-8859-1 Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. The default behaviour remains the same (log into plain files) Signed-off-by: Jean Guyader --bcaec5016301d1cef604bfab7425 Content-Type: text/x-patch; charset=US-ASCII; name="xenconsoled-syslog.patch" Content-Disposition: attachment; filename="xenconsoled-syslog.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21mn1zq1 ZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL2lvLmMgYi90b29scy9jb25zb2xlL2Rh ZW1vbi9pby5jCmluZGV4IGI2ZDQxZGUuLmIxOGJlM2UgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbnNv bGUvZGFlbW9uL2lvLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vaW8uYwpAQCAtNzMsMTMg KzczLDE0IEBAIHN0YXRpYyB4Y19ldnRjaG4gKnhjZV9oYW5kbGUgPSBOVUxMOwogc3RydWN0IGJ1 ZmZlciB7CiAJY2hhciAqZGF0YTsKIAlzaXplX3QgY29uc3VtZWQ7Ci0Jc2l6ZV90IHNpemU7Ci0J c2l6ZV90IGNhcGFjaXR5OworCXNpemVfdCBzaXplOyAgICAgICAgIC8qIEFtb3VudCBvZiBkYXRh IGN1cnJlbnRseSBpbiB0aGUgYnVmZmVyICovCisJc2l6ZV90IGNhcGFjaXR5OyAgICAgLyogQW1v dW50IG9mIGFsbG9jYXRlZCBkYXRhIGZvciB0aGUgYnVmZmVyICovCiAJc2l6ZV90IG1heF9jYXBh Y2l0eTsKIH07CiAKIHN0cnVjdCBkb21haW4gewogCWludCBkb21pZDsKKwljaGFyICpuYW1lOwog CWludCBtYXN0ZXJfZmQ7CiAJaW50IHNsYXZlX2ZkOwogCWludCBsb2dfZmQ7CkBAIC0xNDcsNiAr MTQ4LDcgQEAgc3RhdGljIGludCB3cml0ZV93aXRoX3RpbWVzdGFtcChpbnQgZmQsIGNvbnN0IGNo YXIgKmRhdGEsIHNpemVfdCBzeiwKIHN0YXRpYyB2b2lkIGJ1ZmZlcl9hcHBlbmQoc3RydWN0IGRv bWFpbiAqZG9tKQogewogCXN0cnVjdCBidWZmZXIgKmJ1ZmZlciA9ICZkb20tPmJ1ZmZlcjsKKwlz dHJ1Y3QgYnVmZmVyIHNsYnVmID0geyAwIH07CiAJWEVOQ09OU19SSU5HX0lEWCBjb25zLCBwcm9k LCBzaXplOwogCXN0cnVjdCB4ZW5jb25zX2ludGVyZmFjZSAqaW50ZiA9IGRvbS0+aW50ZXJmYWNl OwogCkBAIC0xNTgsNyArMTYwLDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3Qg ZG9tYWluICpkb20pCiAJaWYgKChzaXplID09IDApIHx8IChzaXplID4gc2l6ZW9mKGludGYtPm91 dCkpKQogCQlyZXR1cm47CiAKLQlpZiAoKGJ1ZmZlci0+Y2FwYWNpdHkgLSBidWZmZXItPnNpemUp IDwgc2l6ZSkgeworCWlmICgoYnVmZmVyLT5jYXBhY2l0eSAtIGJ1ZmZlci0+c2l6ZSkgPCBzaXpl ICsgMSkgewogCQlidWZmZXItPmNhcGFjaXR5ICs9IChzaXplICsgMTAyNCk7CiAJCWJ1ZmZlci0+ ZGF0YSA9IHJlYWxsb2MoYnVmZmVyLT5kYXRhLCBidWZmZXItPmNhcGFjaXR5KTsKIAkJaWYgKGJ1 ZmZlci0+ZGF0YSA9PSBOVUxMKSB7CkBAIC0xNjYsMTAgKzE2OCwzMSBAQCBzdGF0aWMgdm9pZCBi dWZmZXJfYXBwZW5kKHN0cnVjdCBkb21haW4gKmRvbSkKIAkJCWV4aXQoRU5PTUVNKTsKIAkJfQog CX0KKwlzbGJ1Zi5jYXBhY2l0eSA9IGJ1ZmZlci0+Y2FwYWNpdHk7CisJc2xidWYubWF4X2NhcGFj aXR5ID0gYnVmZmVyLT5tYXhfY2FwYWNpdHk7CisJc2xidWYuZGF0YSA9IG1hbGxvYyhzbGJ1Zi5j YXBhY2l0eSk7CisJaWYgKCFzbGJ1Zi5kYXRhKSB7CisJCWRvbG9nKExPR19FUlIsICJNZW1vcnkg YWxsb2NhdGlvbiBmYWlsZWQiKTsKKwkJZXhpdChFTk9NRU0pOworCX0KIAotCXdoaWxlIChjb25z ICE9IHByb2QpCi0JCWJ1ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBpbnRmLT5vdXRbCi0J CQlNQVNLX1hFTkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJZm9yICg7IGNvbnMgIT0g cHJvZDsgKytjb25zKSB7CisJCWNoYXIgY2ggPSBpbnRmLT5vdXRbTUFTS19YRU5DT05TX0lEWChj b25zLCBpbnRmLT5vdXQpXTsKKwkJc2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCWJ1 ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBjaDsKKwkJaWYgIChjaCA9PSAnXHInIHx8IGNo ID09ICdcbicpIHsKKwkJCXNsYnVmLmRhdGFbc2xidWYuc2l6ZSAtIDFdID0gJ1wwJzsKKwkJCSsr Y29uczsKKwkJCWlmIChjb25zICE9IHByb2QpIHsKKwkJCQljaCA9IGludGYtPm91dFtNQVNLX1hF TkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJCQkJYnVmZmVyLT5kYXRhW2J1ZmZlci0+ c2l6ZSsrXSA9IGNoOworCQkJCWlmIChjaCAhPSAnXHInICYmIGNoICE9ICdcbicpIHsKKwkJCQkJ c2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJ CX0KKwl9CiAKIAl4ZW5fbWIoKTsKIAlpbnRmLT5vdXRfY29ucyA9IGNvbnM7CkBAIC0xOTYsNiAr MjE5LDkgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpkb20pCiAJ CQlkb2xvZyhMT0dfRVJSLCAiV3JpdGUgdG8gbG9nIGZhaWxlZCAiCiAJCQkgICAgICAib24gZG9t YWluICVkOiAlZCAoJXMpXG4iLAogCQkJICAgICAgZG9tLT5kb21pZCwgZXJybm8sIHN0cmVycm9y KGVycm5vKSk7CisJfSBlbHNlIHsKKwkJLyogRmFsbHMgYmFjayB0byBzeXNsb2cgaXMgdGhlIGRv bWFpbiBkb2Vzbid0IGhhdmUgYSBsb2cgZmlsZSAqLworCQlzeXNsb2coTE9HX0lORk8sICIlcyAo JWkpOiAlcyIsIGRvbS0+bmFtZSwgZG9tLT5kb21pZCwgc2xidWYuZGF0YSk7CiAJfQogCiAJaWYg KGRpc2NhcmRfb3ZlcmZsb3dlZF9kYXRhICYmIGJ1ZmZlci0+bWF4X2NhcGFjaXR5ICYmCkBAIC0y MTksNiArMjQ1LDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpk b20pCiAJCQlidWZmZXItPnNpemUgPSBidWZmZXItPm1heF9jYXBhY2l0eSAvIDIgKyBvdmVyOwog CQl9CiAJfQorCWZyZWUoc2xidWYuZGF0YSk7CiB9CiAKIHN0YXRpYyBib29sIGJ1ZmZlcl9lbXB0 eShzdHJ1Y3QgYnVmZmVyICpidWZmZXIpCkBAIC0yNTUsNiArMjgyLDEwIEBAIHN0YXRpYyBpbnQg Y3JlYXRlX2h2X2xvZyh2b2lkKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07CiAJaW50IGZk OworCisJaWYgKCFsb2dfZGlyKQorCQlyZXR1cm4gLTE7CisKIAlzbnByaW50Zihsb2dmaWxlLCBQ QVRIX01BWC0xLCAiJXMvaHlwZXJ2aXNvci5sb2ciLCBsb2dfZGlyKTsKIAlsb2dmaWxlW1BBVEhf TUFYLTFdID0gJ1wwJzsKIApAQCAtMjc1LDMyICszMDYsNTYgQEAgc3RhdGljIGludCBjcmVhdGVf aHZfbG9nKHZvaWQpCiAJcmV0dXJuIGZkOwogfQogCitzdGF0aWMgY2hhciAqc2FmZV94c19yZWFk KGNvbnN0IGNoYXIgKmtleSwgaW50IHRyaWVzKQoreworCWNoYXIgKmRhdGEgPSBOVUxMOworCXVu c2lnbmVkIGludCBsZW47CisJc3RydWN0IHRpbWVzcGVjIHJlcSA9IHsgLnR2X3NlYyA9IDAsIC50 dl9uc2VjID0gMTAwMDAwMDAwIH07IC8qIDEwMCBtcyAqLworCWludCBpOworCisJZm9yIChpID0g MDsgaSA8IHRyaWVzOyBpKyspIHsKKwkJZGF0YSA9IHhzX3JlYWQoeHMsIFhCVF9OVUxMLCBrZXks ICZsZW4pOworCQlpZiAoZGF0YSAmJiBsZW4gPiAwKQorCQkJYnJlYWs7CisJCWZyZWUoZGF0YSk7 CisJCW5hbm9zbGVlcCgmcmVxLCBOVUxMKTsKKwl9CisJcmV0dXJuIGRhdGE7Cit9CisKK3N0YXRp YyBjaGFyICpuYW1lX2Zyb21fZG9tcGF0aChjb25zdCBjaGFyICpwYXRoKQoreworCWNoYXIgbmFt ZXBhdGhbNjRdID0geyAwIH0sICpuYW1lOworCXN0cm5jYXQoIG5hbWVwYXRoLCBwYXRoICwgc2l6 ZW9mKG5hbWVwYXRoKSApOworCXN0cm5jYXQoIG5hbWVwYXRoLCAiL25hbWUiLCBzaXplb2YobmFt ZXBhdGgpIC0gc3RybGVuKG5hbWVwYXRoKSApOworCisJbmFtZSA9IHNhZmVfeHNfcmVhZChuYW1l cGF0aCwgMSk7CisJLyogd2l0aG91dCBhbnkgbmFtZSBhZnRlciAxMDAgdHJpZXMsIGp1c3QgZGVm YXVsdCB0byB1bm5hbWVkICovCisJaWYgKCFuYW1lKQorCQluYW1lID0gc3RyZHVwKCJ1bm5hbWVk Iik7CisJcmV0dXJuIG5hbWU7Cit9CisKIHN0YXRpYyBpbnQgY3JlYXRlX2RvbWFpbl9sb2coc3Ry dWN0IGRvbWFpbiAqZG9tKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07Ci0JY2hhciAqbmFt ZXBhdGgsICpkYXRhLCAqczsKKwljaGFyICpuYW1lcGF0aDsKIAlpbnQgZmQ7Ci0JdW5zaWduZWQg aW50IGxlbjsKIAogCW5hbWVwYXRoID0geHNfZ2V0X2RvbWFpbl9wYXRoKHhzLCBkb20tPmRvbWlk KTsKLQlzID0gcmVhbGxvYyhuYW1lcGF0aCwgc3RybGVuKG5hbWVwYXRoKSArIDYpOwotCWlmIChz ID09IE5VTEwpIHsKKwlpZiAobmFtZXBhdGggPT0gTlVMTCkgewogCQlmcmVlKG5hbWVwYXRoKTsK IAkJcmV0dXJuIC0xOwogCX0KLQluYW1lcGF0aCA9IHM7Ci0Jc3RyY2F0KG5hbWVwYXRoLCAiL25h bWUiKTsKLQlkYXRhID0geHNfcmVhZCh4cywgWEJUX05VTEwsIG5hbWVwYXRoLCAmbGVuKTsKKwlk b20tPm5hbWUgPSBuYW1lX2Zyb21fZG9tcGF0aChuYW1lcGF0aCk7CiAJZnJlZShuYW1lcGF0aCk7 Ci0JaWYgKCFkYXRhKQorCWlmICghZG9tLT5uYW1lKSB7CiAJCXJldHVybiAtMTsKLQlpZiAoIWxl bikgewotCQlmcmVlKGRhdGEpOworCX0KKwlpZiAoIWxvZ19kaXIpIHsKIAkJcmV0dXJuIC0xOwog CX0KLQotCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFYLTEsICIlcy9ndWVzdC0lcy5sb2ciLCBs b2dfZGlyLCBkYXRhKTsKLQlmcmVlKGRhdGEpOworCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFY IC0gMSwgIiVzLyVzLmxvZyIsIGxvZ19kaXIsIGRvbS0+bmFtZSk7CiAJbG9nZmlsZVtQQVRIX01B WC0xXSA9ICdcMCc7CiAKIAlmZCA9IG9wZW4obG9nZmlsZSwgT19XUk9OTFl8T19DUkVBVHxPX0FQ UEVORCwgMDY0NCk7CkBAIC02NTYsNiArNzExLDcgQEAgc3RhdGljIHN0cnVjdCBkb21haW4gKmNy ZWF0ZV9kb21haW4oaW50IGRvbWlkKQogCWRvbS0+cmVtb3RlX3BvcnQgPSAtMTsKIAlkb20tPmlu dGVyZmFjZSA9IE5VTEw7CiAJZG9tLT54Y2VfaGFuZGxlID0gTlVMTDsKKwlkb20tPm5hbWUgPSBO VUxMOwogCiAJaWYgKCF3YXRjaF9kb21haW4oZG9tLCB0cnVlKSkKIAkJZ290byBvdXQ7CkBAIC03 MTIsNiArNzY4LDExIEBAIHN0YXRpYyB2b2lkIGNsZWFudXBfZG9tYWluKHN0cnVjdCBkb21haW4g KmQpCiAJZnJlZShkLT5jb25zcGF0aCk7CiAJZC0+Y29uc3BhdGggPSBOVUxMOwogCisgICAgICAg IGlmIChkLT5uYW1lKSB7CisJICAgIGZyZWUoZC0+bmFtZSk7CisJICAgIGQtPm5hbWUgPSBOVUxM OworICAgICAgICB9CisKIAlyZW1vdmVfZG9tYWluKGQpOwogfQogCkBAIC04NzgsNyArOTM5LDEw IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV94cyh2b2lkKQogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHZf bG9ncyh2b2lkKQogewotCWNoYXIgYnVmZmVyWzEwMjQqMTZdOworCWNoYXIgYnVmZmVyWzEwMjQq MTYgKyAxXTsKKwlzdGF0aWMgY2hhciBsYnVmWzEwMjQqMTYgKyAxXTsKKwlzdGF0aWMgaW50IGxv ZmYgPSAwOworCWludCBpID0gMDsKIAljaGFyICpidWZwdHIgPSBidWZmZXI7CiAJdW5zaWduZWQg aW50IHNpemUgPSBzaXplb2YoYnVmZmVyKTsKIAlzdGF0aWMgdWludDMyX3QgaW5kZXggPSAwOwpA QCAtODg4LDE3ICs5NTIsMzYgQEAgc3RhdGljIHZvaWQgaGFuZGxlX2h2X2xvZ3Modm9pZCkKIAkJ cmV0dXJuOwogCiAJaWYgKHhjX3JlYWRjb25zb2xlcmluZyh4Y2gsIGJ1ZnB0ciwgJnNpemUsIDAs IDEsICZpbmRleCkgPT0gMCAmJiBzaXplID4gMCkgewotCQlpbnQgbG9ncmV0OwotCQlpZiAobG9n X3RpbWVfaHYpCi0JCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKLQkJCQkJCSAgICAgICZsb2dfdGltZV9odl9uZWVkdHMpOwotCQllbHNlCi0J CQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOwotCi0JCWlmIChs b2dyZXQgPCAwKQotCQkJZG9sb2coTE9HX0VSUiwgIkZhaWxlZCB0byB3cml0ZSBoeXBlcnZpc29y IGxvZzogIgotCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJubykpOwot CX0KKwkJaWYgKGxvZ19odl9mZCAhPSAtMSkgeworCQkJaW50IGxvZ3JldDsKKwkJCWlmIChsb2df dGltZV9odikKKwkJCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKKwkJCQkJCQkgICAgICAmbG9nX3RpbWVfaHZfbmVlZHRzKTsKKwkJCWVsc2UK KwkJCQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOworCisJCQlp ZiAobG9ncmV0IDwgMCkKKwkJCQlkb2xvZyhMT0dfRVJSLCAiRmFpbGVkIHRvIHdyaXRlIGh5cGVy dmlzb3IgbG9nOiAiCisJCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJu bykpOworCQl9IGVsc2UgeworCQkJd2hpbGUgKGkgPCBzaXplKSB7CisJCQkJd2hpbGUgKChpIDwg c2l6ZSkgJiYKKwkJCQkgICAgICAgKGJ1ZmZlcltpXSAhPSAnXG4nKSAmJiAoYnVmZmVyW2ldICE9 ICdccicpKSB7CisJCQkJCWxidWZbbG9mZisrXSA9IGJ1ZmZlcltpKytdOworCQkJCX0KKwkJCQlp ZiAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSB7CisJCQkJCWxi dWZbbG9mZl0gPSAnXDAnOworCQkJCQkrK2k7CisJCQkJCWlmICgoaSA8IHNpemUpICYmCisJCQkJ CSAgICAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSkgeworCQkJ CQkJKytpOworCQkJCQl9CisJCQkJCXN5c2xvZyhMT0dfSU5GTywgImh5cGVydmlzb3I6ICVzIiwg bGJ1Zik7CisJCQkJCWxvZmYgPSAwOworCQkJCX0KKwkJCX0KKwkJfQorICAgICAgICB9CiAKIAko dm9pZCl4Y19ldnRjaG5fdW5tYXNrKHhjZV9oYW5kbGUsIHBvcnQpOwogfQpAQCAtOTQwLDggKzEw MjMsNiBAQCB2b2lkIGhhbmRsZV9pbyh2b2lkKQogCQkJZ290byBvdXQ7CiAJCX0KIAkJbG9nX2h2 X2ZkID0gY3JlYXRlX2h2X2xvZygpOwotCQlpZiAobG9nX2h2X2ZkID09IC0xKQotCQkJZ290byBv dXQ7CiAJCWxvZ19odl9ldnRjaG4gPSB4Y19ldnRjaG5fYmluZF92aXJxKHhjZV9oYW5kbGUsIFZJ UlFfQ09OX1JJTkcpOwogCQlpZiAobG9nX2h2X2V2dGNobiA9PSAtMSkgewogCQkJZG9sb2coTE9H X0VSUiwgIkZhaWxlZCB0byBiaW5kIHRvIFZJUlFfQ09OX1JJTkc6ICIKZGlmZiAtLWdpdCBhL3Rv b2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYyBiL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYwpp bmRleCA3ODliYWE2Li45MTljODZlIDEwMDY0NAotLS0gYS90b29scy9jb25zb2xlL2RhZW1vbi9t YWluLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vbWFpbi5jCkBAIC0zOSw2ICszOSw3IEBA IGludCBsb2dfdGltZV9odiA9IDA7CiBpbnQgbG9nX3RpbWVfZ3Vlc3QgPSAwOwogY2hhciAqbG9n X2RpciA9IE5VTEw7CiBpbnQgZGlzY2FyZF9vdmVyZmxvd2VkX2RhdGEgPSAxOworaW50IHVzZV9z eXNsb2cgPSAwOwogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHVwKGludCBzaWcpCiB7CkBAIC00Nyw3 ICs0OCw3IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV9odXAoaW50IHNpZykKIAogc3RhdGljIHZvaWQg dXNhZ2UoY2hhciAqbmFtZSkKIHsKLQlwcmludGYoIlVzYWdlOiAlcyBbLWhdIFstVl0gWy12XSBb LWldIFstLWxvZz1ub25lfGd1ZXN0fGh2fGFsbF0gWy0tbG9nLWRpcj1ESVJdIFstLXBpZC1maWxl PVBBVEhdIFstdCwgLS10aW1lc3RhbXA9bm9uZXxndWVzdHxodnxhbGxdIFstbywgLS1vdmVyZmxv dy1kYXRhPWRpc2NhcmR8a2VlcF1cbiIsIG5hbWUpOworCXByaW50ZigiVXNhZ2U6ICVzIFstaF0g Wy1WXSBbLXZdIFstaV0gWy0tbG9nPW5vbmV8Z3Vlc3R8aHZ8YWxsXSBbLS1zeXNsb2ddIFstLWxv Zy1kaXI9RElSXSBbLS1waWQtZmlsZT1QQVRIXSBbLXQsIC0tdGltZXN0YW1wPW5vbmV8Z3Vlc3R8 aHZ8YWxsXSBbLW8sIC0tb3ZlcmZsb3ctZGF0YT1kaXNjYXJkfGtlZXBdXG4iLCBuYW1lKTsKIH0K IAogc3RhdGljIHZvaWQgdmVyc2lvbihjaGFyICpuYW1lKQpAQCAtNjgsNiArNjksNyBAQCBpbnQg bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAJCXsgInBpZC1maWxlIiwgMSwgMCwgJ3AnIH0s CiAJCXsgInRpbWVzdGFtcCIsIDEsIDAsICd0JyB9LAogCQl7ICJvdmVyZmxvdy1kYXRhIiwgMSwg MCwgJ28nfSwKKwkJeyAic3lzbG9nIiwgMCwgMCwgJ3MnIH0sCiAJCXsgMCB9LAogCX07CiAJYm9v bCBpc19pbnRlcmFjdGl2ZSA9IGZhbHNlOwpAQCAtMTA2LDYgKzEwOCw5IEBAIGludCBtYWluKGlu dCBhcmdjLCBjaGFyICoqYXJndikKIAkJCSAgICAgIGxvZ19ndWVzdCA9IDE7CiAJCQl9CiAJCQli cmVhazsKKwkJY2FzZSAncyc6CisJCQl1c2Vfc3lzbG9nID0gMTsKKyAgICAgICAgICAgICAgICAg ICAgICAgIGJyZWFrOwogCQljYXNlICdyJzoKIAkJICAgICAgICBsb2dfZGlyID0gc3RyZHVwKG9w dGFyZyk7CiAJCQlicmVhazsKQEAgLTE0MCw3ICsxNDUsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCiAJCX0KIAl9CiAKLQlpZiAoIWxvZ19kaXIpIHsKKwlpZiAoIWxvZ19kaXIg JiYgIXVzZV9zeXNsb2cpIHsKIAkJbG9nX2RpciA9IHN0cmR1cCgiL3Zhci9sb2cveGVuL2NvbnNv bGUiKTsKIAl9CiAK --bcaec5016301d1cef604bfab7425 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --bcaec5016301d1cef604bfab7425-- From xen-devel-bounces@lists.xen.org Thu May 10 09:44:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09: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 ) id 1SSPua-0004BT-9I; Thu, 10 May 2012 09:43:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSPuZ-0004BO-2h for xen-devel@lists.xensource.com; Thu, 10 May 2012 09:43:51 +0000 Received: from [193.109.254.147:30908] by server-9.bemta-14.messagelabs.com id 5D/85-05787-6DD8BAF4; Thu, 10 May 2012 09:43:50 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336643027!1715251!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9427 invoked from network); 10 May 2012 09:43:48 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:43:48 -0000 Received: by vbbfq11 with SMTP id fq11so1691258vbb.30 for ; Thu, 10 May 2012 02:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=bHW1xk9b4nRJZn5baZ9bekilQ90bFk+otnDe4mWVv1g=; b=BFiEHb0HE9/V/LnYU+W2fTT0+hjSU9BKlIpKwSQq2LfLBh9499GBfa5IFAxeXvhdiK njETnJD0NUP+LbW9fTHx4cOVw2T7M6X4B/MpSckVZGjgG9zPW5k98A0/TkJVVVOrTPmE BLEL4jm5/izWk8DbgE0N+RXrqrh1RgDaxBpxD75cccLuhS2KlZntgaABa7d/rIYbsClS GV42Zeay0VkuHs5B5Wwx9gl+V4+cC0SZTkB5V0gEkVNv5/UsH6YfcS8UVf9XocUQYSgB hySgq/zclVest1RohugZl/d1v5BbNXySoe2lcEdGYh7ruAAvEk+KStC2LIOHoU6Erme2 np5g== Received: by 10.52.72.137 with SMTP id d9mr1656030vdv.122.1336643027062; Thu, 10 May 2012 02:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:43:26 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:43:26 +0100 Message-ID: To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=bcaec5016301d1cef604bfab7425 Subject: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --bcaec5016301d1cef604bfab7425 Content-Type: text/plain; charset=ISO-8859-1 Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. The default behaviour remains the same (log into plain files) Signed-off-by: Jean Guyader --bcaec5016301d1cef604bfab7425 Content-Type: text/x-patch; charset=US-ASCII; name="xenconsoled-syslog.patch" Content-Disposition: attachment; filename="xenconsoled-syslog.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21mn1zq1 ZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL2lvLmMgYi90b29scy9jb25zb2xlL2Rh ZW1vbi9pby5jCmluZGV4IGI2ZDQxZGUuLmIxOGJlM2UgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbnNv bGUvZGFlbW9uL2lvLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vaW8uYwpAQCAtNzMsMTMg KzczLDE0IEBAIHN0YXRpYyB4Y19ldnRjaG4gKnhjZV9oYW5kbGUgPSBOVUxMOwogc3RydWN0IGJ1 ZmZlciB7CiAJY2hhciAqZGF0YTsKIAlzaXplX3QgY29uc3VtZWQ7Ci0Jc2l6ZV90IHNpemU7Ci0J c2l6ZV90IGNhcGFjaXR5OworCXNpemVfdCBzaXplOyAgICAgICAgIC8qIEFtb3VudCBvZiBkYXRh IGN1cnJlbnRseSBpbiB0aGUgYnVmZmVyICovCisJc2l6ZV90IGNhcGFjaXR5OyAgICAgLyogQW1v dW50IG9mIGFsbG9jYXRlZCBkYXRhIGZvciB0aGUgYnVmZmVyICovCiAJc2l6ZV90IG1heF9jYXBh Y2l0eTsKIH07CiAKIHN0cnVjdCBkb21haW4gewogCWludCBkb21pZDsKKwljaGFyICpuYW1lOwog CWludCBtYXN0ZXJfZmQ7CiAJaW50IHNsYXZlX2ZkOwogCWludCBsb2dfZmQ7CkBAIC0xNDcsNiAr MTQ4LDcgQEAgc3RhdGljIGludCB3cml0ZV93aXRoX3RpbWVzdGFtcChpbnQgZmQsIGNvbnN0IGNo YXIgKmRhdGEsIHNpemVfdCBzeiwKIHN0YXRpYyB2b2lkIGJ1ZmZlcl9hcHBlbmQoc3RydWN0IGRv bWFpbiAqZG9tKQogewogCXN0cnVjdCBidWZmZXIgKmJ1ZmZlciA9ICZkb20tPmJ1ZmZlcjsKKwlz dHJ1Y3QgYnVmZmVyIHNsYnVmID0geyAwIH07CiAJWEVOQ09OU19SSU5HX0lEWCBjb25zLCBwcm9k LCBzaXplOwogCXN0cnVjdCB4ZW5jb25zX2ludGVyZmFjZSAqaW50ZiA9IGRvbS0+aW50ZXJmYWNl OwogCkBAIC0xNTgsNyArMTYwLDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3Qg ZG9tYWluICpkb20pCiAJaWYgKChzaXplID09IDApIHx8IChzaXplID4gc2l6ZW9mKGludGYtPm91 dCkpKQogCQlyZXR1cm47CiAKLQlpZiAoKGJ1ZmZlci0+Y2FwYWNpdHkgLSBidWZmZXItPnNpemUp IDwgc2l6ZSkgeworCWlmICgoYnVmZmVyLT5jYXBhY2l0eSAtIGJ1ZmZlci0+c2l6ZSkgPCBzaXpl ICsgMSkgewogCQlidWZmZXItPmNhcGFjaXR5ICs9IChzaXplICsgMTAyNCk7CiAJCWJ1ZmZlci0+ ZGF0YSA9IHJlYWxsb2MoYnVmZmVyLT5kYXRhLCBidWZmZXItPmNhcGFjaXR5KTsKIAkJaWYgKGJ1 ZmZlci0+ZGF0YSA9PSBOVUxMKSB7CkBAIC0xNjYsMTAgKzE2OCwzMSBAQCBzdGF0aWMgdm9pZCBi dWZmZXJfYXBwZW5kKHN0cnVjdCBkb21haW4gKmRvbSkKIAkJCWV4aXQoRU5PTUVNKTsKIAkJfQog CX0KKwlzbGJ1Zi5jYXBhY2l0eSA9IGJ1ZmZlci0+Y2FwYWNpdHk7CisJc2xidWYubWF4X2NhcGFj aXR5ID0gYnVmZmVyLT5tYXhfY2FwYWNpdHk7CisJc2xidWYuZGF0YSA9IG1hbGxvYyhzbGJ1Zi5j YXBhY2l0eSk7CisJaWYgKCFzbGJ1Zi5kYXRhKSB7CisJCWRvbG9nKExPR19FUlIsICJNZW1vcnkg YWxsb2NhdGlvbiBmYWlsZWQiKTsKKwkJZXhpdChFTk9NRU0pOworCX0KIAotCXdoaWxlIChjb25z ICE9IHByb2QpCi0JCWJ1ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBpbnRmLT5vdXRbCi0J CQlNQVNLX1hFTkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJZm9yICg7IGNvbnMgIT0g cHJvZDsgKytjb25zKSB7CisJCWNoYXIgY2ggPSBpbnRmLT5vdXRbTUFTS19YRU5DT05TX0lEWChj b25zLCBpbnRmLT5vdXQpXTsKKwkJc2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCWJ1 ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBjaDsKKwkJaWYgIChjaCA9PSAnXHInIHx8IGNo ID09ICdcbicpIHsKKwkJCXNsYnVmLmRhdGFbc2xidWYuc2l6ZSAtIDFdID0gJ1wwJzsKKwkJCSsr Y29uczsKKwkJCWlmIChjb25zICE9IHByb2QpIHsKKwkJCQljaCA9IGludGYtPm91dFtNQVNLX1hF TkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJCQkJYnVmZmVyLT5kYXRhW2J1ZmZlci0+ c2l6ZSsrXSA9IGNoOworCQkJCWlmIChjaCAhPSAnXHInICYmIGNoICE9ICdcbicpIHsKKwkJCQkJ c2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJ CX0KKwl9CiAKIAl4ZW5fbWIoKTsKIAlpbnRmLT5vdXRfY29ucyA9IGNvbnM7CkBAIC0xOTYsNiAr MjE5LDkgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpkb20pCiAJ CQlkb2xvZyhMT0dfRVJSLCAiV3JpdGUgdG8gbG9nIGZhaWxlZCAiCiAJCQkgICAgICAib24gZG9t YWluICVkOiAlZCAoJXMpXG4iLAogCQkJICAgICAgZG9tLT5kb21pZCwgZXJybm8sIHN0cmVycm9y KGVycm5vKSk7CisJfSBlbHNlIHsKKwkJLyogRmFsbHMgYmFjayB0byBzeXNsb2cgaXMgdGhlIGRv bWFpbiBkb2Vzbid0IGhhdmUgYSBsb2cgZmlsZSAqLworCQlzeXNsb2coTE9HX0lORk8sICIlcyAo JWkpOiAlcyIsIGRvbS0+bmFtZSwgZG9tLT5kb21pZCwgc2xidWYuZGF0YSk7CiAJfQogCiAJaWYg KGRpc2NhcmRfb3ZlcmZsb3dlZF9kYXRhICYmIGJ1ZmZlci0+bWF4X2NhcGFjaXR5ICYmCkBAIC0y MTksNiArMjQ1LDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpk b20pCiAJCQlidWZmZXItPnNpemUgPSBidWZmZXItPm1heF9jYXBhY2l0eSAvIDIgKyBvdmVyOwog CQl9CiAJfQorCWZyZWUoc2xidWYuZGF0YSk7CiB9CiAKIHN0YXRpYyBib29sIGJ1ZmZlcl9lbXB0 eShzdHJ1Y3QgYnVmZmVyICpidWZmZXIpCkBAIC0yNTUsNiArMjgyLDEwIEBAIHN0YXRpYyBpbnQg Y3JlYXRlX2h2X2xvZyh2b2lkKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07CiAJaW50IGZk OworCisJaWYgKCFsb2dfZGlyKQorCQlyZXR1cm4gLTE7CisKIAlzbnByaW50Zihsb2dmaWxlLCBQ QVRIX01BWC0xLCAiJXMvaHlwZXJ2aXNvci5sb2ciLCBsb2dfZGlyKTsKIAlsb2dmaWxlW1BBVEhf TUFYLTFdID0gJ1wwJzsKIApAQCAtMjc1LDMyICszMDYsNTYgQEAgc3RhdGljIGludCBjcmVhdGVf aHZfbG9nKHZvaWQpCiAJcmV0dXJuIGZkOwogfQogCitzdGF0aWMgY2hhciAqc2FmZV94c19yZWFk KGNvbnN0IGNoYXIgKmtleSwgaW50IHRyaWVzKQoreworCWNoYXIgKmRhdGEgPSBOVUxMOworCXVu c2lnbmVkIGludCBsZW47CisJc3RydWN0IHRpbWVzcGVjIHJlcSA9IHsgLnR2X3NlYyA9IDAsIC50 dl9uc2VjID0gMTAwMDAwMDAwIH07IC8qIDEwMCBtcyAqLworCWludCBpOworCisJZm9yIChpID0g MDsgaSA8IHRyaWVzOyBpKyspIHsKKwkJZGF0YSA9IHhzX3JlYWQoeHMsIFhCVF9OVUxMLCBrZXks ICZsZW4pOworCQlpZiAoZGF0YSAmJiBsZW4gPiAwKQorCQkJYnJlYWs7CisJCWZyZWUoZGF0YSk7 CisJCW5hbm9zbGVlcCgmcmVxLCBOVUxMKTsKKwl9CisJcmV0dXJuIGRhdGE7Cit9CisKK3N0YXRp YyBjaGFyICpuYW1lX2Zyb21fZG9tcGF0aChjb25zdCBjaGFyICpwYXRoKQoreworCWNoYXIgbmFt ZXBhdGhbNjRdID0geyAwIH0sICpuYW1lOworCXN0cm5jYXQoIG5hbWVwYXRoLCBwYXRoICwgc2l6 ZW9mKG5hbWVwYXRoKSApOworCXN0cm5jYXQoIG5hbWVwYXRoLCAiL25hbWUiLCBzaXplb2YobmFt ZXBhdGgpIC0gc3RybGVuKG5hbWVwYXRoKSApOworCisJbmFtZSA9IHNhZmVfeHNfcmVhZChuYW1l cGF0aCwgMSk7CisJLyogd2l0aG91dCBhbnkgbmFtZSBhZnRlciAxMDAgdHJpZXMsIGp1c3QgZGVm YXVsdCB0byB1bm5hbWVkICovCisJaWYgKCFuYW1lKQorCQluYW1lID0gc3RyZHVwKCJ1bm5hbWVk Iik7CisJcmV0dXJuIG5hbWU7Cit9CisKIHN0YXRpYyBpbnQgY3JlYXRlX2RvbWFpbl9sb2coc3Ry dWN0IGRvbWFpbiAqZG9tKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07Ci0JY2hhciAqbmFt ZXBhdGgsICpkYXRhLCAqczsKKwljaGFyICpuYW1lcGF0aDsKIAlpbnQgZmQ7Ci0JdW5zaWduZWQg aW50IGxlbjsKIAogCW5hbWVwYXRoID0geHNfZ2V0X2RvbWFpbl9wYXRoKHhzLCBkb20tPmRvbWlk KTsKLQlzID0gcmVhbGxvYyhuYW1lcGF0aCwgc3RybGVuKG5hbWVwYXRoKSArIDYpOwotCWlmIChz ID09IE5VTEwpIHsKKwlpZiAobmFtZXBhdGggPT0gTlVMTCkgewogCQlmcmVlKG5hbWVwYXRoKTsK IAkJcmV0dXJuIC0xOwogCX0KLQluYW1lcGF0aCA9IHM7Ci0Jc3RyY2F0KG5hbWVwYXRoLCAiL25h bWUiKTsKLQlkYXRhID0geHNfcmVhZCh4cywgWEJUX05VTEwsIG5hbWVwYXRoLCAmbGVuKTsKKwlk b20tPm5hbWUgPSBuYW1lX2Zyb21fZG9tcGF0aChuYW1lcGF0aCk7CiAJZnJlZShuYW1lcGF0aCk7 Ci0JaWYgKCFkYXRhKQorCWlmICghZG9tLT5uYW1lKSB7CiAJCXJldHVybiAtMTsKLQlpZiAoIWxl bikgewotCQlmcmVlKGRhdGEpOworCX0KKwlpZiAoIWxvZ19kaXIpIHsKIAkJcmV0dXJuIC0xOwog CX0KLQotCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFYLTEsICIlcy9ndWVzdC0lcy5sb2ciLCBs b2dfZGlyLCBkYXRhKTsKLQlmcmVlKGRhdGEpOworCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFY IC0gMSwgIiVzLyVzLmxvZyIsIGxvZ19kaXIsIGRvbS0+bmFtZSk7CiAJbG9nZmlsZVtQQVRIX01B WC0xXSA9ICdcMCc7CiAKIAlmZCA9IG9wZW4obG9nZmlsZSwgT19XUk9OTFl8T19DUkVBVHxPX0FQ UEVORCwgMDY0NCk7CkBAIC02NTYsNiArNzExLDcgQEAgc3RhdGljIHN0cnVjdCBkb21haW4gKmNy ZWF0ZV9kb21haW4oaW50IGRvbWlkKQogCWRvbS0+cmVtb3RlX3BvcnQgPSAtMTsKIAlkb20tPmlu dGVyZmFjZSA9IE5VTEw7CiAJZG9tLT54Y2VfaGFuZGxlID0gTlVMTDsKKwlkb20tPm5hbWUgPSBO VUxMOwogCiAJaWYgKCF3YXRjaF9kb21haW4oZG9tLCB0cnVlKSkKIAkJZ290byBvdXQ7CkBAIC03 MTIsNiArNzY4LDExIEBAIHN0YXRpYyB2b2lkIGNsZWFudXBfZG9tYWluKHN0cnVjdCBkb21haW4g KmQpCiAJZnJlZShkLT5jb25zcGF0aCk7CiAJZC0+Y29uc3BhdGggPSBOVUxMOwogCisgICAgICAg IGlmIChkLT5uYW1lKSB7CisJICAgIGZyZWUoZC0+bmFtZSk7CisJICAgIGQtPm5hbWUgPSBOVUxM OworICAgICAgICB9CisKIAlyZW1vdmVfZG9tYWluKGQpOwogfQogCkBAIC04NzgsNyArOTM5LDEw IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV94cyh2b2lkKQogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHZf bG9ncyh2b2lkKQogewotCWNoYXIgYnVmZmVyWzEwMjQqMTZdOworCWNoYXIgYnVmZmVyWzEwMjQq MTYgKyAxXTsKKwlzdGF0aWMgY2hhciBsYnVmWzEwMjQqMTYgKyAxXTsKKwlzdGF0aWMgaW50IGxv ZmYgPSAwOworCWludCBpID0gMDsKIAljaGFyICpidWZwdHIgPSBidWZmZXI7CiAJdW5zaWduZWQg aW50IHNpemUgPSBzaXplb2YoYnVmZmVyKTsKIAlzdGF0aWMgdWludDMyX3QgaW5kZXggPSAwOwpA QCAtODg4LDE3ICs5NTIsMzYgQEAgc3RhdGljIHZvaWQgaGFuZGxlX2h2X2xvZ3Modm9pZCkKIAkJ cmV0dXJuOwogCiAJaWYgKHhjX3JlYWRjb25zb2xlcmluZyh4Y2gsIGJ1ZnB0ciwgJnNpemUsIDAs IDEsICZpbmRleCkgPT0gMCAmJiBzaXplID4gMCkgewotCQlpbnQgbG9ncmV0OwotCQlpZiAobG9n X3RpbWVfaHYpCi0JCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKLQkJCQkJCSAgICAgICZsb2dfdGltZV9odl9uZWVkdHMpOwotCQllbHNlCi0J CQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOwotCi0JCWlmIChs b2dyZXQgPCAwKQotCQkJZG9sb2coTE9HX0VSUiwgIkZhaWxlZCB0byB3cml0ZSBoeXBlcnZpc29y IGxvZzogIgotCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJubykpOwot CX0KKwkJaWYgKGxvZ19odl9mZCAhPSAtMSkgeworCQkJaW50IGxvZ3JldDsKKwkJCWlmIChsb2df dGltZV9odikKKwkJCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKKwkJCQkJCQkgICAgICAmbG9nX3RpbWVfaHZfbmVlZHRzKTsKKwkJCWVsc2UK KwkJCQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOworCisJCQlp ZiAobG9ncmV0IDwgMCkKKwkJCQlkb2xvZyhMT0dfRVJSLCAiRmFpbGVkIHRvIHdyaXRlIGh5cGVy dmlzb3IgbG9nOiAiCisJCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJu bykpOworCQl9IGVsc2UgeworCQkJd2hpbGUgKGkgPCBzaXplKSB7CisJCQkJd2hpbGUgKChpIDwg c2l6ZSkgJiYKKwkJCQkgICAgICAgKGJ1ZmZlcltpXSAhPSAnXG4nKSAmJiAoYnVmZmVyW2ldICE9 ICdccicpKSB7CisJCQkJCWxidWZbbG9mZisrXSA9IGJ1ZmZlcltpKytdOworCQkJCX0KKwkJCQlp ZiAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSB7CisJCQkJCWxi dWZbbG9mZl0gPSAnXDAnOworCQkJCQkrK2k7CisJCQkJCWlmICgoaSA8IHNpemUpICYmCisJCQkJ CSAgICAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSkgeworCQkJ CQkJKytpOworCQkJCQl9CisJCQkJCXN5c2xvZyhMT0dfSU5GTywgImh5cGVydmlzb3I6ICVzIiwg bGJ1Zik7CisJCQkJCWxvZmYgPSAwOworCQkJCX0KKwkJCX0KKwkJfQorICAgICAgICB9CiAKIAko dm9pZCl4Y19ldnRjaG5fdW5tYXNrKHhjZV9oYW5kbGUsIHBvcnQpOwogfQpAQCAtOTQwLDggKzEw MjMsNiBAQCB2b2lkIGhhbmRsZV9pbyh2b2lkKQogCQkJZ290byBvdXQ7CiAJCX0KIAkJbG9nX2h2 X2ZkID0gY3JlYXRlX2h2X2xvZygpOwotCQlpZiAobG9nX2h2X2ZkID09IC0xKQotCQkJZ290byBv dXQ7CiAJCWxvZ19odl9ldnRjaG4gPSB4Y19ldnRjaG5fYmluZF92aXJxKHhjZV9oYW5kbGUsIFZJ UlFfQ09OX1JJTkcpOwogCQlpZiAobG9nX2h2X2V2dGNobiA9PSAtMSkgewogCQkJZG9sb2coTE9H X0VSUiwgIkZhaWxlZCB0byBiaW5kIHRvIFZJUlFfQ09OX1JJTkc6ICIKZGlmZiAtLWdpdCBhL3Rv b2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYyBiL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYwpp bmRleCA3ODliYWE2Li45MTljODZlIDEwMDY0NAotLS0gYS90b29scy9jb25zb2xlL2RhZW1vbi9t YWluLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vbWFpbi5jCkBAIC0zOSw2ICszOSw3IEBA IGludCBsb2dfdGltZV9odiA9IDA7CiBpbnQgbG9nX3RpbWVfZ3Vlc3QgPSAwOwogY2hhciAqbG9n X2RpciA9IE5VTEw7CiBpbnQgZGlzY2FyZF9vdmVyZmxvd2VkX2RhdGEgPSAxOworaW50IHVzZV9z eXNsb2cgPSAwOwogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHVwKGludCBzaWcpCiB7CkBAIC00Nyw3 ICs0OCw3IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV9odXAoaW50IHNpZykKIAogc3RhdGljIHZvaWQg dXNhZ2UoY2hhciAqbmFtZSkKIHsKLQlwcmludGYoIlVzYWdlOiAlcyBbLWhdIFstVl0gWy12XSBb LWldIFstLWxvZz1ub25lfGd1ZXN0fGh2fGFsbF0gWy0tbG9nLWRpcj1ESVJdIFstLXBpZC1maWxl PVBBVEhdIFstdCwgLS10aW1lc3RhbXA9bm9uZXxndWVzdHxodnxhbGxdIFstbywgLS1vdmVyZmxv dy1kYXRhPWRpc2NhcmR8a2VlcF1cbiIsIG5hbWUpOworCXByaW50ZigiVXNhZ2U6ICVzIFstaF0g Wy1WXSBbLXZdIFstaV0gWy0tbG9nPW5vbmV8Z3Vlc3R8aHZ8YWxsXSBbLS1zeXNsb2ddIFstLWxv Zy1kaXI9RElSXSBbLS1waWQtZmlsZT1QQVRIXSBbLXQsIC0tdGltZXN0YW1wPW5vbmV8Z3Vlc3R8 aHZ8YWxsXSBbLW8sIC0tb3ZlcmZsb3ctZGF0YT1kaXNjYXJkfGtlZXBdXG4iLCBuYW1lKTsKIH0K IAogc3RhdGljIHZvaWQgdmVyc2lvbihjaGFyICpuYW1lKQpAQCAtNjgsNiArNjksNyBAQCBpbnQg bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAJCXsgInBpZC1maWxlIiwgMSwgMCwgJ3AnIH0s CiAJCXsgInRpbWVzdGFtcCIsIDEsIDAsICd0JyB9LAogCQl7ICJvdmVyZmxvdy1kYXRhIiwgMSwg MCwgJ28nfSwKKwkJeyAic3lzbG9nIiwgMCwgMCwgJ3MnIH0sCiAJCXsgMCB9LAogCX07CiAJYm9v bCBpc19pbnRlcmFjdGl2ZSA9IGZhbHNlOwpAQCAtMTA2LDYgKzEwOCw5IEBAIGludCBtYWluKGlu dCBhcmdjLCBjaGFyICoqYXJndikKIAkJCSAgICAgIGxvZ19ndWVzdCA9IDE7CiAJCQl9CiAJCQli cmVhazsKKwkJY2FzZSAncyc6CisJCQl1c2Vfc3lzbG9nID0gMTsKKyAgICAgICAgICAgICAgICAg ICAgICAgIGJyZWFrOwogCQljYXNlICdyJzoKIAkJICAgICAgICBsb2dfZGlyID0gc3RyZHVwKG9w dGFyZyk7CiAJCQlicmVhazsKQEAgLTE0MCw3ICsxNDUsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCiAJCX0KIAl9CiAKLQlpZiAoIWxvZ19kaXIpIHsKKwlpZiAoIWxvZ19kaXIg JiYgIXVzZV9zeXNsb2cpIHsKIAkJbG9nX2RpciA9IHN0cmR1cCgiL3Zhci9sb2cveGVuL2NvbnNv bGUiKTsKIAl9CiAK --bcaec5016301d1cef604bfab7425 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --bcaec5016301d1cef604bfab7425-- From xen-devel-bounces@lists.xen.org Thu May 10 09:51:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:51:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ1x-0004MC-Bq; Thu, 10 May 2012 09:51:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ1w-0004M7-0t for xen-devel@lists.xensource.com; Thu, 10 May 2012 09:51:28 +0000 Received: from [85.158.139.83:6122] by server-1.bemta-5.messagelabs.com id CF/9D-28458-E9F8BAF4; Thu, 10 May 2012 09:51:26 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336643484!27943697!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25897 invoked from network); 10 May 2012 09:51:25 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:51:25 -0000 Received: by vbbfq11 with SMTP id fq11so1699725vbb.30 for ; Thu, 10 May 2012 02:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=asWQItcK1RwmaeDcCuhFWpqG25y8dZ5p1O0VzlNqi7g=; b=X4r+Ks2JQgRGHG1ct4n4zKgq7gupDWhfHcWnbY4MGVECOO+JKvL6r4FDcWrVXKtHJ2 3LYOPCS4SkETSY6RGPOifpu41ldm1znqpOBekAdalwjcLThvfOaNVfKQadHhPvwYDs5P kW5h2+dB1C3yMh6Av4hxuOmjO4mfWkRrTIo54gHD7bzjghPwvjscWxQF0s6NcU7B5WID EKUs0/fD7v9FS1eBgjeLZi4YqOgcK3Y1yq2cq7zjHGlkngkYRNK+KT78u/Y2HFVJzlvz WQvpbpveTGtH+Buf3G3tA12+TKepQDF8+Wco+EpwPC9yuPaYMPGH4B/JnzMb+v0/FcM/ vBgA== Received: by 10.220.63.9 with SMTP id z9mr2207780vch.64.1336643484615; Thu, 10 May 2012 02:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:51:04 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:51:04 +0100 Message-ID: To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=e0cb4e88751717840804bfab9019 Subject: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --e0cb4e88751717840804bfab9019 Content-Type: text/plain; charset=ISO-8859-1 Add a new xc function to destroy the shadow pages table for a given guest. Signed-off-by: Jean Guyader --e0cb4e88751717840804bfab9019 Content-Type: text/x-patch; charset=US-ASCII; name="shadow-blow-tables.patch" Content-Disposition: attachment; filename="shadow-blow-tables.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n1dt80 ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jIGIvdG9vbHMvbGlieGMveGNfZG9t YWluLmMKaW5kZXggZDk4ZTY4Yi4uMmJhZWFlNyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNf ZG9tYWluLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMKQEAgLTQxNiw2ICs0MTYsMTcg QEAgaW50IHhjX3dhdGNoZG9nKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiByZXQ7CiB9 CiAKK2ludCB4Y19zaGFkb3dfYmxvd190YWJsZXMoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKQoreworICAgIERFQ0xBUkVfRE9NQ1RM OworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3NoYWRvd19vcDsKKyAgICBkb21jdGwuZG9t YWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2hhZG93X29wLm9wICAgICA9IFhF Tl9ET01DVExfU0hBRE9XX09QX0JMT1dfVEFCTEVTOworICAgIGRvbWN0bC51LnNoYWRvd19vcC5k b21pZCAgPSAoZG9taWRfdClkb21pZDsKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0 bCk7Cit9CisKIAogaW50IHhjX3NoYWRvd19jb250cm9sKHhjX2ludGVyZmFjZSAqeGNoLAogICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC0tZ2l0IGEvdG9vbHMvbGli eGMveGVuY3RybC5oIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCmluZGV4IDNiYmM4MjcuLmIyM2Nj YmUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAorKysgYi90b29scy9saWJ4Yy94 ZW5jdHJsLmgKQEAgLTY1Miw2ICs2NTIsNyBAQCBpbnQgeGNfc2hhZG93X2NvbnRyb2woeGNfaW50 ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyAqbWIsCiAg ICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbW9kZSwKICAgICAgICAgICAgICAgICAgICAg ICB4Y19zaGFkb3dfb3Bfc3RhdHNfdCAqc3RhdHMpOworaW50IHhjX3NoYWRvd19ibG93X3RhYmxl cyh4Y19pbnRlcmZhY2UgKnhjaCwgdWludDMyX3QgZG9taWQpOwogCiBpbnQgeGNfc2VkZl9kb21h aW5fc2V0KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf dCBkb21pZCwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMgYi94 ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCmluZGV4IDU5YmU5OTMuLjdkMzE2MzYgMTAw NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMKKysrIGIveGVuL2FyY2gv eDg2L21tL3NoYWRvdy9jb21tb24uYwpAQCAtMzc4OSw2ICszNzg5LDcgQEAgaW50IHNoYWRvd19k b21jdGwoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5E TEUodm9pZCkgdV9kb21jdGwpCiB7CiAgICAgaW50IHJjLCBwcmVlbXB0ZWQgPSAwOworICAgIHN0 cnVjdCBkb21haW4gKmRvbTsKIAogICAgIHN3aXRjaCAoIHNjLT5vcCApCiAgICAgewpAQCAtMzgz Myw2ICszODM0LDEzIEBAIGludCBzaGFkb3dfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsCiAgICAg ICAgICAgICBzYy0+bWIgPSBzaGFkb3dfZ2V0X2FsbG9jYXRpb24oZCk7CiAgICAgICAgIHJldHVy biByYzsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfQkxPV19UQUJMRVM6CisgICAg ICAgIGRvbSA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzYy0+ZG9taWQpOworICAgICAgICBzaGFk b3dfYmxvd190YWJsZXNfcGVyX2RvbWFpbihkb20pOworICAgICAgICByY3VfdW5sb2NrX2RvbWFp bihkb20pOworCisgICAgICAgIHJldHVybiAwOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgU0hB RE9XX0VSUk9SKCJCYWQgc2hhZG93IG9wICV1XG4iLCBzYy0+b3ApOwogICAgICAgICByZXR1cm4g LUVJTlZBTDsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCBiL3hlbi9p bmNsdWRlL3B1YmxpYy9kb21jdGwuaAppbmRleCAyNDBjZWI5Li44MTY5OTc1IDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Rv bWN0bC5oCkBAIC0xODksNiArMTg5LDggQEAgc3RydWN0IHhlbl9kb21jdGxfZ2V0cGFnZWZyYW1l aW5mbzMgewogI2RlZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9HRVRfQUxMT0NBVElPTiAgIDMw CiAjZGVmaW5lIFhFTl9ET01DVExfU0hBRE9XX09QX1NFVF9BTExPQ0FUSU9OICAgMzEKIAorI2Rl ZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9CTE9XX1RBQkxFUyAgICAgIDMzCisKIC8qIExlZ2Fj eSBlbmFibGUgb3BlcmF0aW9ucy4gKi8KICAvKiBFcXVpdi4gdG8gRU5BQkxFIHdpdGggbm8gbW9k ZSBmbGFncy4gKi8KICNkZWZpbmUgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX1RFU1QgICAg ICAgMQpAQCAtMjM5LDYgKzI0MSw5IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX3NoYWRvd19vcCB7CiAg ICAgWEVOX0dVRVNUX0hBTkRMRV82NCh1aW50OCkgZGlydHlfYml0bWFwOwogICAgIHVpbnQ2NF9h bGlnbmVkX3QgcGFnZXM7IC8qIFNpemUgb2YgYnVmZmVyLiBVcGRhdGVkIHdpdGggYWN0dWFsIHNp emUuICovCiAgICAgc3RydWN0IHhlbl9kb21jdGxfc2hhZG93X29wX3N0YXRzIHN0YXRzOworCisg ICAgLyogT1BfQkxPV19UQUJMRSAqLworICAgIGRvbWlkX3QgICAgICAgZG9taWQ7CiB9OwogdHlw ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zaGFkb3dfb3AgeGVuX2RvbWN0bF9zaGFkb3dfb3BfdDsK IERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2hhZG93X29wX3QpOwpkaWZmIC0t Z2l0IGEveGVuL3hzbS9mbGFzay9ob29rcy5jIGIveGVuL3hzbS9mbGFzay9ob29rcy5jCmluZGV4 IGM5M2I4ZDAuLjY0NzZjNmMgMTAwNjQ0Ci0tLSBhL3hlbi94c20vZmxhc2svaG9va3MuYworKysg Yi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMKQEAgLTEwMzUsNiArMTAzNSw3IEBAIHN0YXRpYyBpbnQg Zmxhc2tfc2hhZG93X2NvbnRyb2woc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3Qgb3ApCiAgICAg Y2FzZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9FTkFCTEVfVFJBTlNMQVRFOgogICAgIGNhc2UgWEVO X0RPTUNUTF9TSEFET1dfT1BfR0VUX0FMTE9DQVRJT046CiAgICAgY2FzZSBYRU5fRE9NQ1RMX1NI QURPV19PUF9TRVRfQUxMT0NBVElPTjoKKyAgICBjYXNlIFhFTl9ET01DVExfU0hBRE9XX09QX0JM T1dfVEFCTEVTOgogICAgICAgICBwZXJtID0gU0hBRE9XX19FTkFCTEU7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX0xPR0RJUlRZOgo= --e0cb4e88751717840804bfab9019 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --e0cb4e88751717840804bfab9019-- From xen-devel-bounces@lists.xen.org Thu May 10 09:51:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:51:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ1x-0004MC-Bq; Thu, 10 May 2012 09:51:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ1w-0004M7-0t for xen-devel@lists.xensource.com; Thu, 10 May 2012 09:51:28 +0000 Received: from [85.158.139.83:6122] by server-1.bemta-5.messagelabs.com id CF/9D-28458-E9F8BAF4; Thu, 10 May 2012 09:51:26 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336643484!27943697!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25897 invoked from network); 10 May 2012 09:51:25 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:51:25 -0000 Received: by vbbfq11 with SMTP id fq11so1699725vbb.30 for ; Thu, 10 May 2012 02:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=asWQItcK1RwmaeDcCuhFWpqG25y8dZ5p1O0VzlNqi7g=; b=X4r+Ks2JQgRGHG1ct4n4zKgq7gupDWhfHcWnbY4MGVECOO+JKvL6r4FDcWrVXKtHJ2 3LYOPCS4SkETSY6RGPOifpu41ldm1znqpOBekAdalwjcLThvfOaNVfKQadHhPvwYDs5P kW5h2+dB1C3yMh6Av4hxuOmjO4mfWkRrTIo54gHD7bzjghPwvjscWxQF0s6NcU7B5WID EKUs0/fD7v9FS1eBgjeLZi4YqOgcK3Y1yq2cq7zjHGlkngkYRNK+KT78u/Y2HFVJzlvz WQvpbpveTGtH+Buf3G3tA12+TKepQDF8+Wco+EpwPC9yuPaYMPGH4B/JnzMb+v0/FcM/ vBgA== Received: by 10.220.63.9 with SMTP id z9mr2207780vch.64.1336643484615; Thu, 10 May 2012 02:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:51:04 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:51:04 +0100 Message-ID: To: xen-devel@lists.xensource.com Content-Type: multipart/mixed; boundary=e0cb4e88751717840804bfab9019 Subject: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --e0cb4e88751717840804bfab9019 Content-Type: text/plain; charset=ISO-8859-1 Add a new xc function to destroy the shadow pages table for a given guest. Signed-off-by: Jean Guyader --e0cb4e88751717840804bfab9019 Content-Type: text/x-patch; charset=US-ASCII; name="shadow-blow-tables.patch" Content-Disposition: attachment; filename="shadow-blow-tables.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n1dt80 ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jIGIvdG9vbHMvbGlieGMveGNfZG9t YWluLmMKaW5kZXggZDk4ZTY4Yi4uMmJhZWFlNyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNf ZG9tYWluLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMKQEAgLTQxNiw2ICs0MTYsMTcg QEAgaW50IHhjX3dhdGNoZG9nKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiByZXQ7CiB9 CiAKK2ludCB4Y19zaGFkb3dfYmxvd190YWJsZXMoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKQoreworICAgIERFQ0xBUkVfRE9NQ1RM OworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3NoYWRvd19vcDsKKyAgICBkb21jdGwuZG9t YWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2hhZG93X29wLm9wICAgICA9IFhF Tl9ET01DVExfU0hBRE9XX09QX0JMT1dfVEFCTEVTOworICAgIGRvbWN0bC51LnNoYWRvd19vcC5k b21pZCAgPSAoZG9taWRfdClkb21pZDsKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0 bCk7Cit9CisKIAogaW50IHhjX3NoYWRvd19jb250cm9sKHhjX2ludGVyZmFjZSAqeGNoLAogICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC0tZ2l0IGEvdG9vbHMvbGli eGMveGVuY3RybC5oIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCmluZGV4IDNiYmM4MjcuLmIyM2Nj YmUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAorKysgYi90b29scy9saWJ4Yy94 ZW5jdHJsLmgKQEAgLTY1Miw2ICs2NTIsNyBAQCBpbnQgeGNfc2hhZG93X2NvbnRyb2woeGNfaW50 ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyAqbWIsCiAg ICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbW9kZSwKICAgICAgICAgICAgICAgICAgICAg ICB4Y19zaGFkb3dfb3Bfc3RhdHNfdCAqc3RhdHMpOworaW50IHhjX3NoYWRvd19ibG93X3RhYmxl cyh4Y19pbnRlcmZhY2UgKnhjaCwgdWludDMyX3QgZG9taWQpOwogCiBpbnQgeGNfc2VkZl9kb21h aW5fc2V0KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf dCBkb21pZCwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMgYi94 ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCmluZGV4IDU5YmU5OTMuLjdkMzE2MzYgMTAw NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMKKysrIGIveGVuL2FyY2gv eDg2L21tL3NoYWRvdy9jb21tb24uYwpAQCAtMzc4OSw2ICszNzg5LDcgQEAgaW50IHNoYWRvd19k b21jdGwoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5E TEUodm9pZCkgdV9kb21jdGwpCiB7CiAgICAgaW50IHJjLCBwcmVlbXB0ZWQgPSAwOworICAgIHN0 cnVjdCBkb21haW4gKmRvbTsKIAogICAgIHN3aXRjaCAoIHNjLT5vcCApCiAgICAgewpAQCAtMzgz Myw2ICszODM0LDEzIEBAIGludCBzaGFkb3dfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsCiAgICAg ICAgICAgICBzYy0+bWIgPSBzaGFkb3dfZ2V0X2FsbG9jYXRpb24oZCk7CiAgICAgICAgIHJldHVy biByYzsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfQkxPV19UQUJMRVM6CisgICAg ICAgIGRvbSA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzYy0+ZG9taWQpOworICAgICAgICBzaGFk b3dfYmxvd190YWJsZXNfcGVyX2RvbWFpbihkb20pOworICAgICAgICByY3VfdW5sb2NrX2RvbWFp bihkb20pOworCisgICAgICAgIHJldHVybiAwOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgU0hB RE9XX0VSUk9SKCJCYWQgc2hhZG93IG9wICV1XG4iLCBzYy0+b3ApOwogICAgICAgICByZXR1cm4g LUVJTlZBTDsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCBiL3hlbi9p bmNsdWRlL3B1YmxpYy9kb21jdGwuaAppbmRleCAyNDBjZWI5Li44MTY5OTc1IDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Rv bWN0bC5oCkBAIC0xODksNiArMTg5LDggQEAgc3RydWN0IHhlbl9kb21jdGxfZ2V0cGFnZWZyYW1l aW5mbzMgewogI2RlZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9HRVRfQUxMT0NBVElPTiAgIDMw CiAjZGVmaW5lIFhFTl9ET01DVExfU0hBRE9XX09QX1NFVF9BTExPQ0FUSU9OICAgMzEKIAorI2Rl ZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9CTE9XX1RBQkxFUyAgICAgIDMzCisKIC8qIExlZ2Fj eSBlbmFibGUgb3BlcmF0aW9ucy4gKi8KICAvKiBFcXVpdi4gdG8gRU5BQkxFIHdpdGggbm8gbW9k ZSBmbGFncy4gKi8KICNkZWZpbmUgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX1RFU1QgICAg ICAgMQpAQCAtMjM5LDYgKzI0MSw5IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX3NoYWRvd19vcCB7CiAg ICAgWEVOX0dVRVNUX0hBTkRMRV82NCh1aW50OCkgZGlydHlfYml0bWFwOwogICAgIHVpbnQ2NF9h bGlnbmVkX3QgcGFnZXM7IC8qIFNpemUgb2YgYnVmZmVyLiBVcGRhdGVkIHdpdGggYWN0dWFsIHNp emUuICovCiAgICAgc3RydWN0IHhlbl9kb21jdGxfc2hhZG93X29wX3N0YXRzIHN0YXRzOworCisg ICAgLyogT1BfQkxPV19UQUJMRSAqLworICAgIGRvbWlkX3QgICAgICAgZG9taWQ7CiB9OwogdHlw ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zaGFkb3dfb3AgeGVuX2RvbWN0bF9zaGFkb3dfb3BfdDsK IERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2hhZG93X29wX3QpOwpkaWZmIC0t Z2l0IGEveGVuL3hzbS9mbGFzay9ob29rcy5jIGIveGVuL3hzbS9mbGFzay9ob29rcy5jCmluZGV4 IGM5M2I4ZDAuLjY0NzZjNmMgMTAwNjQ0Ci0tLSBhL3hlbi94c20vZmxhc2svaG9va3MuYworKysg Yi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMKQEAgLTEwMzUsNiArMTAzNSw3IEBAIHN0YXRpYyBpbnQg Zmxhc2tfc2hhZG93X2NvbnRyb2woc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3Qgb3ApCiAgICAg Y2FzZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9FTkFCTEVfVFJBTlNMQVRFOgogICAgIGNhc2UgWEVO X0RPTUNUTF9TSEFET1dfT1BfR0VUX0FMTE9DQVRJT046CiAgICAgY2FzZSBYRU5fRE9NQ1RMX1NI QURPV19PUF9TRVRfQUxMT0NBVElPTjoKKyAgICBjYXNlIFhFTl9ET01DVExfU0hBRE9XX09QX0JM T1dfVEFCTEVTOgogICAgICAgICBwZXJtID0gU0hBRE9XX19FTkFCTEU7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX0xPR0RJUlRZOgo= --e0cb4e88751717840804bfab9019 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --e0cb4e88751717840804bfab9019-- From xen-devel-bounces@lists.xen.org Thu May 10 09:56:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:56:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ6a-0004U6-2A; Thu, 10 May 2012 09:56:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ6Y-0004U0-6y for xen-devel@lists.xen.org; Thu, 10 May 2012 09:56:14 +0000 Received: from [85.158.139.83:32533] by server-6.bemta-5.messagelabs.com id D2/82-13222-DB09BAF4; Thu, 10 May 2012 09:56:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336643771!27631084!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29258 invoked from network); 10 May 2012 09:56:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:56:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12400923" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 09:56: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, 10 May 2012 10:56:08 +0100 Message-ID: <1336643766.7098.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Daniel De Graaf Date: Thu, 10 May 2012 10:56:06 +0100 In-Reply-To: <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "libvir-list@redhat.com" , "xen-devel@lists.xen.org" , Ian Jackson , Bamvor Jian Zhang Subject: Re: [Xen-devel] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: > This patch changes libxl to use the interface in Xen 4.2. It is provided > as an example, not intended to go in to libvirt as-is since it removes > all support for libxl from Xen 4.1. It also still has some cruft (extra > void casts on parameters) and the device model info population is not > written. It has been tested with simple domain create/destroy. > --- > src/libxl/libxl_conf.c | 134 +++++++++------ > src/libxl/libxl_conf.h | 8 +- > src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- > 3 files changed, 326 insertions(+), 246 deletions(-) Thanks Daniel, interesting to see. It doesn't seem as invasive as I expected given the number of changes to libxl's interfaces between 4.1 and 4.2. I suppose it is worth mentioning in this context that we are intending to maintain the 4.2 libxl API in a stable manner going forward, as described near the top of: http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h Since libvirt is one of the main reasons we are doing this it would be useful to check that this actually meets the needs from that side. That doesn't really help with support 4.1 and 4.2+. A large portion of the below looks like it would be reasonably easy to abstract away with a header full of compat defines for naming changes etc, other bits don't look so simple to deal with. > @@ -403,9 +414,9 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) > return -1; > } > > - libxl_init_build_info(b_info, &d_config->c_info); > + libxl_domain_build_info_init(b_info); > > - b_info->hvm = hvm; > + b_info->type = hvm ? LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV; I'm not sure what version of "4.2" you are currently using but this should become libxl_domain_build_info_init_type(b_info, hvm ? LIBXL...) at some point. > b_info->max_vcpus = def->maxvcpus; > if (def->vcpus == 32) > b_info->cur_vcpus = (uint32_t) -1; [...] > @@ -454,7 +466,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) > } > } > if (def->os.bootloaderArgs) { > - if ((b_info->u.pv.bootloader_args = strdup(def->os.bootloaderArgs)) == NULL) { > + // XXX may need to split these arguments on a delimiter I think you do. We could consider moving split_string_into_string_list from xl into the xlu(tility) library if libvirt doesn't have an existing helper for that, or you can just copy it (I'm the sole author of that function, I'd be happy to ack any reasonable license for use in libvirt, some variant of (L)GPL I presume?) [...] > +static const libxl_osevent_hooks event_callbacks = { > + .fd_register = evhook_fd_register, > + .fd_modify = evhook_fd_modify, > + .fd_deregister = evhook_fd_deregister, > + .timeout_register = evhook_timeout_register, > + .timeout_modify = evhook_timeout_modify, > + .timeout_deregister = evhook_timeout_deregister, > +}; Glad to see that this interface seems to fit in well with libvirt's infrastructure -- that was the point of it after all ;-) > +static const struct libxl_event_hooks ev_hooks = { > + .event_occurs_mask = LIBXL_EVENTMASK_ALL, > + .event_occurs = libxlEventHandler, > + .disaster = NULL, > +}; Same for this interface. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:56:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:56:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ6a-0004U6-2A; Thu, 10 May 2012 09:56:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ6Y-0004U0-6y for xen-devel@lists.xen.org; Thu, 10 May 2012 09:56:14 +0000 Received: from [85.158.139.83:32533] by server-6.bemta-5.messagelabs.com id D2/82-13222-DB09BAF4; Thu, 10 May 2012 09:56:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336643771!27631084!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29258 invoked from network); 10 May 2012 09:56:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:56:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12400923" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 09:56: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, 10 May 2012 10:56:08 +0100 Message-ID: <1336643766.7098.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Daniel De Graaf Date: Thu, 10 May 2012 10:56:06 +0100 In-Reply-To: <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "libvir-list@redhat.com" , "xen-devel@lists.xen.org" , Ian Jackson , Bamvor Jian Zhang Subject: Re: [Xen-devel] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: > This patch changes libxl to use the interface in Xen 4.2. It is provided > as an example, not intended to go in to libvirt as-is since it removes > all support for libxl from Xen 4.1. It also still has some cruft (extra > void casts on parameters) and the device model info population is not > written. It has been tested with simple domain create/destroy. > --- > src/libxl/libxl_conf.c | 134 +++++++++------ > src/libxl/libxl_conf.h | 8 +- > src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- > 3 files changed, 326 insertions(+), 246 deletions(-) Thanks Daniel, interesting to see. It doesn't seem as invasive as I expected given the number of changes to libxl's interfaces between 4.1 and 4.2. I suppose it is worth mentioning in this context that we are intending to maintain the 4.2 libxl API in a stable manner going forward, as described near the top of: http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h Since libvirt is one of the main reasons we are doing this it would be useful to check that this actually meets the needs from that side. That doesn't really help with support 4.1 and 4.2+. A large portion of the below looks like it would be reasonably easy to abstract away with a header full of compat defines for naming changes etc, other bits don't look so simple to deal with. > @@ -403,9 +414,9 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) > return -1; > } > > - libxl_init_build_info(b_info, &d_config->c_info); > + libxl_domain_build_info_init(b_info); > > - b_info->hvm = hvm; > + b_info->type = hvm ? LIBXL_DOMAIN_TYPE_HVM : LIBXL_DOMAIN_TYPE_PV; I'm not sure what version of "4.2" you are currently using but this should become libxl_domain_build_info_init_type(b_info, hvm ? LIBXL...) at some point. > b_info->max_vcpus = def->maxvcpus; > if (def->vcpus == 32) > b_info->cur_vcpus = (uint32_t) -1; [...] > @@ -454,7 +466,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) > } > } > if (def->os.bootloaderArgs) { > - if ((b_info->u.pv.bootloader_args = strdup(def->os.bootloaderArgs)) == NULL) { > + // XXX may need to split these arguments on a delimiter I think you do. We could consider moving split_string_into_string_list from xl into the xlu(tility) library if libvirt doesn't have an existing helper for that, or you can just copy it (I'm the sole author of that function, I'd be happy to ack any reasonable license for use in libvirt, some variant of (L)GPL I presume?) [...] > +static const libxl_osevent_hooks event_callbacks = { > + .fd_register = evhook_fd_register, > + .fd_modify = evhook_fd_modify, > + .fd_deregister = evhook_fd_deregister, > + .timeout_register = evhook_timeout_register, > + .timeout_modify = evhook_timeout_modify, > + .timeout_deregister = evhook_timeout_deregister, > +}; Glad to see that this interface seems to fit in well with libvirt's infrastructure -- that was the point of it after all ;-) > +static const struct libxl_event_hooks ev_hooks = { > + .event_occurs_mask = LIBXL_EVENTMASK_ALL, > + .event_occurs = libxlEventHandler, > + .disaster = NULL, > +}; Same for this interface. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 09:57:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:57:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ7E-0004Wi-FO; Thu, 10 May 2012 09:56:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ7D-0004WW-2B for xen-devel@lists.xen.org; Thu, 10 May 2012 09:56:55 +0000 Received: from [85.158.143.99:21992] by server-3.bemta-4.messagelabs.com id B9/4A-05853-6E09BAF4; Thu, 10 May 2012 09:56:54 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336643812!26767428!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6417 invoked from network); 10 May 2012 09:56:53 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:56:53 -0000 Received: by vbbfn1 with SMTP id fn1so247387vbb.32 for ; Thu, 10 May 2012 02:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=D8LRAK5niO9PKVZ7Tku9JFvDiQyOuEP+f2N8JEJmkHQ=; b=Jo/tt11woC86GSq+o2j+JTevXmFDesMaRVXbNcVyORZewDzGqqMGXydTy//vqglFWU THA3eeMvHPQYKECbQci/BNOsA3BDMKZxk6I6qsbuH9bT0KABQaWyCxdfYts3tqakOcow dvPxj7j74bWPsMcDJQ0QqyX1KOhwOELMxWmp3D9VcHyOAzBUTJSlpcC6qz32YqyYljAE 7UmUUamRrIdXwrL565Tw4TD2EEwaRGe1pazROtgSf+cBPJJ3YnxacCGPHVLyJNEwHN+t fZX396WNT4DpTfgOOd00ljox8LtiwzMj7rhJpQNWDb9Spsr7APjBr0QsfCF5FsPyX2ML Lzeg== Received: by 10.52.100.67 with SMTP id ew3mr1795360vdb.36.1336643811772; Thu, 10 May 2012 02:56:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:56:31 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:56:31 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=20cf307f349a9789f204bfaba3c2 Cc: Tomasz Wroblewski Subject: [Xen-devel] [PATCH] xen: evtchn_set_pending for guest in S3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf307f349a9789f204bfaba3c2 Content-Type: text/plain; charset=ISO-8859-1 If domain is in S3 it will miss the notification so returns an error. From: Tomasz Wroblewski Signed-off-by: Jean Guyader --20cf307f349a9789f204bfaba3c2 Content-Type: text/x-patch; charset=US-ASCII; name="evtchn-do-not-set-pending-if-s3.patch" Content-Disposition: attachment; filename="evtchn-do-not-set-pending-if-s3.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n81xm0 Y29tbWl0IGQ2NTM3ZTg1ZWUzZGM0YTg1YzhiNjk5YzE1ZDEwZGI3ZjA3YzM3NDUKQXV0aG9yOiBK ZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29tPgpEYXRlOiAgIFRodSBNYXkg MyAxMDoxODo1MiAyMDEyICswMTAwCgogICAgcGF0Y2ggZXZ0Y2huLWRvLW5vdC1zZXQtcGVuZGlu Zy1pZi1zMwoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jIGIveGVuL2Nv bW1vbi9ldmVudF9jaGFubmVsLmMKaW5kZXggZmVlOWE3YS4uZDZkYTVhZiAxMDA2NDQKLS0tIGEv eGVuL2NvbW1vbi9ldmVudF9jaGFubmVsLmMKKysrIGIveGVuL2NvbW1vbi9ldmVudF9jaGFubmVs LmMKQEAgLTU3Myw2ICs1NzMsMTEgQEAgc3RhdGljIGludCBldnRjaG5fc2V0X3BlbmRpbmcoc3Ry dWN0IHZjcHUgKnYsIGludCBwb3J0KQogICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47 CiAgICAgaW50IHZjcHVpZDsKIAorICAgIC8qIGlmIGRvbWFpbiBpcyBpbiBTMyBpdCB3aWxsIG1p c3MgdGhlIG5vdGlmaWNhdGlvbiwgc28gY2hlY2sgaGVyZSAqLworICAgIGlmIChkLT5hcmNoLmh2 bV9kb21haW4uaXNfczNfc3VzcGVuZGVkKSB7CisgICAgICAgIHJldHVybiAtRUZBVUxUOworICAg IH0KKwogICAgIC8qCiAgICAgICogVGhlIGZvbGxvd2luZyBiaXQgb3BlcmF0aW9ucyBtdXN0IGhh cHBlbiBpbiBzdHJpY3Qgb3JkZXIuCiAgICAgICogTkIuIE9uIHg4NiwgdGhlIGF0b21pYyBiaXQg b3BlcmF0aW9ucyBhbHNvIGFjdCBhcyBtZW1vcnkgYmFycmllcnMuCg== --20cf307f349a9789f204bfaba3c2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf307f349a9789f204bfaba3c2-- From xen-devel-bounces@lists.xen.org Thu May 10 09:57:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:57:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ7E-0004Wi-FO; Thu, 10 May 2012 09:56:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ7D-0004WW-2B for xen-devel@lists.xen.org; Thu, 10 May 2012 09:56:55 +0000 Received: from [85.158.143.99:21992] by server-3.bemta-4.messagelabs.com id B9/4A-05853-6E09BAF4; Thu, 10 May 2012 09:56:54 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336643812!26767428!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6417 invoked from network); 10 May 2012 09:56:53 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:56:53 -0000 Received: by vbbfn1 with SMTP id fn1so247387vbb.32 for ; Thu, 10 May 2012 02:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=D8LRAK5niO9PKVZ7Tku9JFvDiQyOuEP+f2N8JEJmkHQ=; b=Jo/tt11woC86GSq+o2j+JTevXmFDesMaRVXbNcVyORZewDzGqqMGXydTy//vqglFWU THA3eeMvHPQYKECbQci/BNOsA3BDMKZxk6I6qsbuH9bT0KABQaWyCxdfYts3tqakOcow dvPxj7j74bWPsMcDJQ0QqyX1KOhwOELMxWmp3D9VcHyOAzBUTJSlpcC6qz32YqyYljAE 7UmUUamRrIdXwrL565Tw4TD2EEwaRGe1pazROtgSf+cBPJJ3YnxacCGPHVLyJNEwHN+t fZX396WNT4DpTfgOOd00ljox8LtiwzMj7rhJpQNWDb9Spsr7APjBr0QsfCF5FsPyX2ML Lzeg== Received: by 10.52.100.67 with SMTP id ew3mr1795360vdb.36.1336643811772; Thu, 10 May 2012 02:56:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:56:31 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 10:56:31 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=20cf307f349a9789f204bfaba3c2 Cc: Tomasz Wroblewski Subject: [Xen-devel] [PATCH] xen: evtchn_set_pending for guest in S3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf307f349a9789f204bfaba3c2 Content-Type: text/plain; charset=ISO-8859-1 If domain is in S3 it will miss the notification so returns an error. From: Tomasz Wroblewski Signed-off-by: Jean Guyader --20cf307f349a9789f204bfaba3c2 Content-Type: text/x-patch; charset=US-ASCII; name="evtchn-do-not-set-pending-if-s3.patch" Content-Disposition: attachment; filename="evtchn-do-not-set-pending-if-s3.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n81xm0 Y29tbWl0IGQ2NTM3ZTg1ZWUzZGM0YTg1YzhiNjk5YzE1ZDEwZGI3ZjA3YzM3NDUKQXV0aG9yOiBK ZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29tPgpEYXRlOiAgIFRodSBNYXkg MyAxMDoxODo1MiAyMDEyICswMTAwCgogICAgcGF0Y2ggZXZ0Y2huLWRvLW5vdC1zZXQtcGVuZGlu Zy1pZi1zMwoKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jIGIveGVuL2Nv bW1vbi9ldmVudF9jaGFubmVsLmMKaW5kZXggZmVlOWE3YS4uZDZkYTVhZiAxMDA2NDQKLS0tIGEv eGVuL2NvbW1vbi9ldmVudF9jaGFubmVsLmMKKysrIGIveGVuL2NvbW1vbi9ldmVudF9jaGFubmVs LmMKQEAgLTU3Myw2ICs1NzMsMTEgQEAgc3RhdGljIGludCBldnRjaG5fc2V0X3BlbmRpbmcoc3Ry dWN0IHZjcHUgKnYsIGludCBwb3J0KQogICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47 CiAgICAgaW50IHZjcHVpZDsKIAorICAgIC8qIGlmIGRvbWFpbiBpcyBpbiBTMyBpdCB3aWxsIG1p c3MgdGhlIG5vdGlmaWNhdGlvbiwgc28gY2hlY2sgaGVyZSAqLworICAgIGlmIChkLT5hcmNoLmh2 bV9kb21haW4uaXNfczNfc3VzcGVuZGVkKSB7CisgICAgICAgIHJldHVybiAtRUZBVUxUOworICAg IH0KKwogICAgIC8qCiAgICAgICogVGhlIGZvbGxvd2luZyBiaXQgb3BlcmF0aW9ucyBtdXN0IGhh cHBlbiBpbiBzdHJpY3Qgb3JkZXIuCiAgICAgICogTkIuIE9uIHg4NiwgdGhlIGF0b21pYyBiaXQg b3BlcmF0aW9ucyBhbHNvIGFjdCBhcyBtZW1vcnkgYmFycmllcnMuCg== --20cf307f349a9789f204bfaba3c2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf307f349a9789f204bfaba3c2-- From xen-devel-bounces@lists.xen.org Thu May 10 09:58:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ8H-0004cG-Tw; Thu, 10 May 2012 09:58:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ8G-0004c7-MK for xen-devel@lists.xen.org; Thu, 10 May 2012 09:58:01 +0000 Received: from [193.109.254.147:65302] by server-11.bemta-14.messagelabs.com id 51/94-05858-7219BAF4; Thu, 10 May 2012 09:57:59 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336643877!8359335!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13421 invoked from network); 10 May 2012 09:57:58 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:57:58 -0000 Received: by vbbfn1 with SMTP id fn1so248785vbb.32 for ; Thu, 10 May 2012 02:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nq26jWqtKottA+lQ7ZCxk4+J2LnWawYgr6aA+JkvUiw=; b=yVJEB4ZfIvAlpy3Fd7NNFAwPwO8xXFOdoD2/cjmxSCDahR1Qsy8ikKESNuxWpVMMgl OjZ7lT8vx1NX/DQeLtwrAT8FHF102VJi2tEtD20kQuGJOGwaxQJ29MMJufawmfJ332yw S2VOMRU2ANqtqK8bf4M7UaxDlXwE7GiGuD40j+XofhHN91sTuH6GJWbFBVhjrRYYmROI yCgEWNLk1wQ00k3IxpRFd+qqW4OsGd6iB/3F4bfkXwDqLcqNnJHqjUPRxYrHVFZx8wZe PXIAjeQEVZrL6+HVEtwqYkTtuRMJ1yXe5+LWqc5iFIuhjhPvsrzquShQ1MLF8FwikrSO mVMQ== Received: by 10.52.32.34 with SMTP id f2mr1739437vdi.76.1336643877056; Thu, 10 May 2012 02:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:57:36 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 10:57:36 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=bcaec51d2b807baf1104bfaba79c Cc: tim@xen.org Subject: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --bcaec51d2b807baf1104bfaba79c Content-Type: text/plain; charset=ISO-8859-1 Add a new xc function to destroy the shadow pages table for a given guest from userspace. Signed-off-by: Jean Guyader --bcaec51d2b807baf1104bfaba79c Content-Type: text/x-patch; charset=US-ASCII; name="shadow-blow-tables.patch" Content-Disposition: attachment; filename="shadow-blow-tables.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n1dt80 ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jIGIvdG9vbHMvbGlieGMveGNfZG9t YWluLmMKaW5kZXggZDk4ZTY4Yi4uMmJhZWFlNyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNf ZG9tYWluLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMKQEAgLTQxNiw2ICs0MTYsMTcg QEAgaW50IHhjX3dhdGNoZG9nKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiByZXQ7CiB9 CiAKK2ludCB4Y19zaGFkb3dfYmxvd190YWJsZXMoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKQoreworICAgIERFQ0xBUkVfRE9NQ1RM OworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3NoYWRvd19vcDsKKyAgICBkb21jdGwuZG9t YWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2hhZG93X29wLm9wICAgICA9IFhF Tl9ET01DVExfU0hBRE9XX09QX0JMT1dfVEFCTEVTOworICAgIGRvbWN0bC51LnNoYWRvd19vcC5k b21pZCAgPSAoZG9taWRfdClkb21pZDsKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0 bCk7Cit9CisKIAogaW50IHhjX3NoYWRvd19jb250cm9sKHhjX2ludGVyZmFjZSAqeGNoLAogICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC0tZ2l0IGEvdG9vbHMvbGli eGMveGVuY3RybC5oIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCmluZGV4IDNiYmM4MjcuLmIyM2Nj YmUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAorKysgYi90b29scy9saWJ4Yy94 ZW5jdHJsLmgKQEAgLTY1Miw2ICs2NTIsNyBAQCBpbnQgeGNfc2hhZG93X2NvbnRyb2woeGNfaW50 ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyAqbWIsCiAg ICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbW9kZSwKICAgICAgICAgICAgICAgICAgICAg ICB4Y19zaGFkb3dfb3Bfc3RhdHNfdCAqc3RhdHMpOworaW50IHhjX3NoYWRvd19ibG93X3RhYmxl cyh4Y19pbnRlcmZhY2UgKnhjaCwgdWludDMyX3QgZG9taWQpOwogCiBpbnQgeGNfc2VkZl9kb21h aW5fc2V0KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf dCBkb21pZCwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMgYi94 ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCmluZGV4IDU5YmU5OTMuLjdkMzE2MzYgMTAw NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMKKysrIGIveGVuL2FyY2gv eDg2L21tL3NoYWRvdy9jb21tb24uYwpAQCAtMzc4OSw2ICszNzg5LDcgQEAgaW50IHNoYWRvd19k b21jdGwoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5E TEUodm9pZCkgdV9kb21jdGwpCiB7CiAgICAgaW50IHJjLCBwcmVlbXB0ZWQgPSAwOworICAgIHN0 cnVjdCBkb21haW4gKmRvbTsKIAogICAgIHN3aXRjaCAoIHNjLT5vcCApCiAgICAgewpAQCAtMzgz Myw2ICszODM0LDEzIEBAIGludCBzaGFkb3dfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsCiAgICAg ICAgICAgICBzYy0+bWIgPSBzaGFkb3dfZ2V0X2FsbG9jYXRpb24oZCk7CiAgICAgICAgIHJldHVy biByYzsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfQkxPV19UQUJMRVM6CisgICAg ICAgIGRvbSA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzYy0+ZG9taWQpOworICAgICAgICBzaGFk b3dfYmxvd190YWJsZXNfcGVyX2RvbWFpbihkb20pOworICAgICAgICByY3VfdW5sb2NrX2RvbWFp bihkb20pOworCisgICAgICAgIHJldHVybiAwOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgU0hB RE9XX0VSUk9SKCJCYWQgc2hhZG93IG9wICV1XG4iLCBzYy0+b3ApOwogICAgICAgICByZXR1cm4g LUVJTlZBTDsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCBiL3hlbi9p bmNsdWRlL3B1YmxpYy9kb21jdGwuaAppbmRleCAyNDBjZWI5Li44MTY5OTc1IDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Rv bWN0bC5oCkBAIC0xODksNiArMTg5LDggQEAgc3RydWN0IHhlbl9kb21jdGxfZ2V0cGFnZWZyYW1l aW5mbzMgewogI2RlZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9HRVRfQUxMT0NBVElPTiAgIDMw CiAjZGVmaW5lIFhFTl9ET01DVExfU0hBRE9XX09QX1NFVF9BTExPQ0FUSU9OICAgMzEKIAorI2Rl ZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9CTE9XX1RBQkxFUyAgICAgIDMzCisKIC8qIExlZ2Fj eSBlbmFibGUgb3BlcmF0aW9ucy4gKi8KICAvKiBFcXVpdi4gdG8gRU5BQkxFIHdpdGggbm8gbW9k ZSBmbGFncy4gKi8KICNkZWZpbmUgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX1RFU1QgICAg ICAgMQpAQCAtMjM5LDYgKzI0MSw5IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX3NoYWRvd19vcCB7CiAg ICAgWEVOX0dVRVNUX0hBTkRMRV82NCh1aW50OCkgZGlydHlfYml0bWFwOwogICAgIHVpbnQ2NF9h bGlnbmVkX3QgcGFnZXM7IC8qIFNpemUgb2YgYnVmZmVyLiBVcGRhdGVkIHdpdGggYWN0dWFsIHNp emUuICovCiAgICAgc3RydWN0IHhlbl9kb21jdGxfc2hhZG93X29wX3N0YXRzIHN0YXRzOworCisg ICAgLyogT1BfQkxPV19UQUJMRSAqLworICAgIGRvbWlkX3QgICAgICAgZG9taWQ7CiB9OwogdHlw ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zaGFkb3dfb3AgeGVuX2RvbWN0bF9zaGFkb3dfb3BfdDsK IERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2hhZG93X29wX3QpOwpkaWZmIC0t Z2l0IGEveGVuL3hzbS9mbGFzay9ob29rcy5jIGIveGVuL3hzbS9mbGFzay9ob29rcy5jCmluZGV4 IGM5M2I4ZDAuLjY0NzZjNmMgMTAwNjQ0Ci0tLSBhL3hlbi94c20vZmxhc2svaG9va3MuYworKysg Yi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMKQEAgLTEwMzUsNiArMTAzNSw3IEBAIHN0YXRpYyBpbnQg Zmxhc2tfc2hhZG93X2NvbnRyb2woc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3Qgb3ApCiAgICAg Y2FzZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9FTkFCTEVfVFJBTlNMQVRFOgogICAgIGNhc2UgWEVO X0RPTUNUTF9TSEFET1dfT1BfR0VUX0FMTE9DQVRJT046CiAgICAgY2FzZSBYRU5fRE9NQ1RMX1NI QURPV19PUF9TRVRfQUxMT0NBVElPTjoKKyAgICBjYXNlIFhFTl9ET01DVExfU0hBRE9XX09QX0JM T1dfVEFCTEVTOgogICAgICAgICBwZXJtID0gU0hBRE9XX19FTkFCTEU7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX0xPR0RJUlRZOgo= --bcaec51d2b807baf1104bfaba79c Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --bcaec51d2b807baf1104bfaba79c-- From xen-devel-bounces@lists.xen.org Thu May 10 09:58:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ8H-0004cG-Tw; Thu, 10 May 2012 09:58:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ8G-0004c7-MK for xen-devel@lists.xen.org; Thu, 10 May 2012 09:58:01 +0000 Received: from [193.109.254.147:65302] by server-11.bemta-14.messagelabs.com id 51/94-05858-7219BAF4; Thu, 10 May 2012 09:57:59 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336643877!8359335!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13421 invoked from network); 10 May 2012 09:57:58 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:57:58 -0000 Received: by vbbfn1 with SMTP id fn1so248785vbb.32 for ; Thu, 10 May 2012 02:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nq26jWqtKottA+lQ7ZCxk4+J2LnWawYgr6aA+JkvUiw=; b=yVJEB4ZfIvAlpy3Fd7NNFAwPwO8xXFOdoD2/cjmxSCDahR1Qsy8ikKESNuxWpVMMgl OjZ7lT8vx1NX/DQeLtwrAT8FHF102VJi2tEtD20kQuGJOGwaxQJ29MMJufawmfJ332yw S2VOMRU2ANqtqK8bf4M7UaxDlXwE7GiGuD40j+XofhHN91sTuH6GJWbFBVhjrRYYmROI yCgEWNLk1wQ00k3IxpRFd+qqW4OsGd6iB/3F4bfkXwDqLcqNnJHqjUPRxYrHVFZx8wZe PXIAjeQEVZrL6+HVEtwqYkTtuRMJ1yXe5+LWqc5iFIuhjhPvsrzquShQ1MLF8FwikrSO mVMQ== Received: by 10.52.32.34 with SMTP id f2mr1739437vdi.76.1336643877056; Thu, 10 May 2012 02:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:57:36 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 10:57:36 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=bcaec51d2b807baf1104bfaba79c Cc: tim@xen.org Subject: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --bcaec51d2b807baf1104bfaba79c Content-Type: text/plain; charset=ISO-8859-1 Add a new xc function to destroy the shadow pages table for a given guest from userspace. Signed-off-by: Jean Guyader --bcaec51d2b807baf1104bfaba79c Content-Type: text/x-patch; charset=US-ASCII; name="shadow-blow-tables.patch" Content-Disposition: attachment; filename="shadow-blow-tables.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21n1dt80 ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jIGIvdG9vbHMvbGlieGMveGNfZG9t YWluLmMKaW5kZXggZDk4ZTY4Yi4uMmJhZWFlNyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNf ZG9tYWluLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMKQEAgLTQxNiw2ICs0MTYsMTcg QEAgaW50IHhjX3dhdGNoZG9nKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiByZXQ7CiB9 CiAKK2ludCB4Y19zaGFkb3dfYmxvd190YWJsZXMoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKQoreworICAgIERFQ0xBUkVfRE9NQ1RM OworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3NoYWRvd19vcDsKKyAgICBkb21jdGwuZG9t YWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2hhZG93X29wLm9wICAgICA9IFhF Tl9ET01DVExfU0hBRE9XX09QX0JMT1dfVEFCTEVTOworICAgIGRvbWN0bC51LnNoYWRvd19vcC5k b21pZCAgPSAoZG9taWRfdClkb21pZDsKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0 bCk7Cit9CisKIAogaW50IHhjX3NoYWRvd19jb250cm9sKHhjX2ludGVyZmFjZSAqeGNoLAogICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC0tZ2l0IGEvdG9vbHMvbGli eGMveGVuY3RybC5oIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCmluZGV4IDNiYmM4MjcuLmIyM2Nj YmUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAorKysgYi90b29scy9saWJ4Yy94 ZW5jdHJsLmgKQEAgLTY1Miw2ICs2NTIsNyBAQCBpbnQgeGNfc2hhZG93X2NvbnRyb2woeGNfaW50 ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyAqbWIsCiAg ICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbW9kZSwKICAgICAgICAgICAgICAgICAgICAg ICB4Y19zaGFkb3dfb3Bfc3RhdHNfdCAqc3RhdHMpOworaW50IHhjX3NoYWRvd19ibG93X3RhYmxl cyh4Y19pbnRlcmZhY2UgKnhjaCwgdWludDMyX3QgZG9taWQpOwogCiBpbnQgeGNfc2VkZl9kb21h aW5fc2V0KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf dCBkb21pZCwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMgYi94 ZW4vYXJjaC94ODYvbW0vc2hhZG93L2NvbW1vbi5jCmluZGV4IDU5YmU5OTMuLjdkMzE2MzYgMTAw NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvY29tbW9uLmMKKysrIGIveGVuL2FyY2gv eDg2L21tL3NoYWRvdy9jb21tb24uYwpAQCAtMzc4OSw2ICszNzg5LDcgQEAgaW50IHNoYWRvd19k b21jdGwoc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5E TEUodm9pZCkgdV9kb21jdGwpCiB7CiAgICAgaW50IHJjLCBwcmVlbXB0ZWQgPSAwOworICAgIHN0 cnVjdCBkb21haW4gKmRvbTsKIAogICAgIHN3aXRjaCAoIHNjLT5vcCApCiAgICAgewpAQCAtMzgz Myw2ICszODM0LDEzIEBAIGludCBzaGFkb3dfZG9tY3RsKHN0cnVjdCBkb21haW4gKmQsCiAgICAg ICAgICAgICBzYy0+bWIgPSBzaGFkb3dfZ2V0X2FsbG9jYXRpb24oZCk7CiAgICAgICAgIHJldHVy biByYzsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfQkxPV19UQUJMRVM6CisgICAg ICAgIGRvbSA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzYy0+ZG9taWQpOworICAgICAgICBzaGFk b3dfYmxvd190YWJsZXNfcGVyX2RvbWFpbihkb20pOworICAgICAgICByY3VfdW5sb2NrX2RvbWFp bihkb20pOworCisgICAgICAgIHJldHVybiAwOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgU0hB RE9XX0VSUk9SKCJCYWQgc2hhZG93IG9wICV1XG4iLCBzYy0+b3ApOwogICAgICAgICByZXR1cm4g LUVJTlZBTDsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCBiL3hlbi9p bmNsdWRlL3B1YmxpYy9kb21jdGwuaAppbmRleCAyNDBjZWI5Li44MTY5OTc1IDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Rv bWN0bC5oCkBAIC0xODksNiArMTg5LDggQEAgc3RydWN0IHhlbl9kb21jdGxfZ2V0cGFnZWZyYW1l aW5mbzMgewogI2RlZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9HRVRfQUxMT0NBVElPTiAgIDMw CiAjZGVmaW5lIFhFTl9ET01DVExfU0hBRE9XX09QX1NFVF9BTExPQ0FUSU9OICAgMzEKIAorI2Rl ZmluZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9CTE9XX1RBQkxFUyAgICAgIDMzCisKIC8qIExlZ2Fj eSBlbmFibGUgb3BlcmF0aW9ucy4gKi8KICAvKiBFcXVpdi4gdG8gRU5BQkxFIHdpdGggbm8gbW9k ZSBmbGFncy4gKi8KICNkZWZpbmUgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX1RFU1QgICAg ICAgMQpAQCAtMjM5LDYgKzI0MSw5IEBAIHN0cnVjdCB4ZW5fZG9tY3RsX3NoYWRvd19vcCB7CiAg ICAgWEVOX0dVRVNUX0hBTkRMRV82NCh1aW50OCkgZGlydHlfYml0bWFwOwogICAgIHVpbnQ2NF9h bGlnbmVkX3QgcGFnZXM7IC8qIFNpemUgb2YgYnVmZmVyLiBVcGRhdGVkIHdpdGggYWN0dWFsIHNp emUuICovCiAgICAgc3RydWN0IHhlbl9kb21jdGxfc2hhZG93X29wX3N0YXRzIHN0YXRzOworCisg ICAgLyogT1BfQkxPV19UQUJMRSAqLworICAgIGRvbWlkX3QgICAgICAgZG9taWQ7CiB9OwogdHlw ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zaGFkb3dfb3AgeGVuX2RvbWN0bF9zaGFkb3dfb3BfdDsK IERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2hhZG93X29wX3QpOwpkaWZmIC0t Z2l0IGEveGVuL3hzbS9mbGFzay9ob29rcy5jIGIveGVuL3hzbS9mbGFzay9ob29rcy5jCmluZGV4 IGM5M2I4ZDAuLjY0NzZjNmMgMTAwNjQ0Ci0tLSBhL3hlbi94c20vZmxhc2svaG9va3MuYworKysg Yi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMKQEAgLTEwMzUsNiArMTAzNSw3IEBAIHN0YXRpYyBpbnQg Zmxhc2tfc2hhZG93X2NvbnRyb2woc3RydWN0IGRvbWFpbiAqZCwgdWludDMyX3Qgb3ApCiAgICAg Y2FzZSBYRU5fRE9NQ1RMX1NIQURPV19PUF9FTkFCTEVfVFJBTlNMQVRFOgogICAgIGNhc2UgWEVO X0RPTUNUTF9TSEFET1dfT1BfR0VUX0FMTE9DQVRJT046CiAgICAgY2FzZSBYRU5fRE9NQ1RMX1NI QURPV19PUF9TRVRfQUxMT0NBVElPTjoKKyAgICBjYXNlIFhFTl9ET01DVExfU0hBRE9XX09QX0JM T1dfVEFCTEVTOgogICAgICAgICBwZXJtID0gU0hBRE9XX19FTkFCTEU7CiAgICAgICAgIGJyZWFr OwogICAgIGNhc2UgWEVOX0RPTUNUTF9TSEFET1dfT1BfRU5BQkxFX0xPR0RJUlRZOgo= --bcaec51d2b807baf1104bfaba79c Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --bcaec51d2b807baf1104bfaba79c-- From xen-devel-bounces@lists.xen.org Thu May 10 09:59:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:59:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ9F-0004ik-CM; Thu, 10 May 2012 09:59:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ9D-0004iR-Os for xen-devel@lists.xen.org; Thu, 10 May 2012 09:59:00 +0000 Received: from [85.158.143.99:36228] by server-3.bemta-4.messagelabs.com id 35/2E-05853-2619BAF4; Thu, 10 May 2012 09:58:58 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336643936!16132435!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28886 invoked from network); 10 May 2012 09:58:57 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:58:57 -0000 Received: by vbbfn1 with SMTP id fn1so249971vbb.32 for ; Thu, 10 May 2012 02:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xIfub88OwXh4HGATw152y5+U3E/E5LF5X+aXl1Buz0k=; b=unkBQs550bKKNg6VUYvWEkfBDFYWdlmKerJZ0BsiwkUNjofhUnW1aeCQfejPDE8KMH t5pEf7jnA5CAEY3yk/sOPHaZX8dOPYzZi7zbcBw7o+aLYEblVLKx0EjkQMU/c9RFsV6W RAA1BGoxojygoYe/WXMmTrTCI9F1+ZVH1YTRuKP8bt8tcSSIYTOj2V7lc+H3+9OIgQww ACxr5dRuSt49UZG46uhNGLV8S9J+mwbQXbCAsRxwc56p8xPWpn/gqB7sCTCgiF+Qdx/k lcyPxWgrIFmtbcdJJOKYVZbhRi9oPChoSvmilk9HYwqixsjT1/hvETV/iJJNX915ho1y wEYQ== Received: by 10.52.97.41 with SMTP id dx9mr1700695vdb.89.1336643936339; Thu, 10 May 2012 02:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:58:36 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 10:58:36 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=20cf307f38060445a804bfabab62 Cc: Eric Chanudet Subject: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf307f38060445a804bfabab62 Content-Type: text/plain; charset=ISO-8859-1 Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. The default behaviour remains the same (log into plain files) From: Eric Chanudet Signed-off-by: Jean Guyader --20cf307f38060445a804bfabab62 Content-Type: text/x-patch; charset=US-ASCII; name="xenconsoled-syslog.patch" Content-Disposition: attachment; filename="xenconsoled-syslog.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21mn1zq1 ZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL2lvLmMgYi90b29scy9jb25zb2xlL2Rh ZW1vbi9pby5jCmluZGV4IGI2ZDQxZGUuLmIxOGJlM2UgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbnNv bGUvZGFlbW9uL2lvLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vaW8uYwpAQCAtNzMsMTMg KzczLDE0IEBAIHN0YXRpYyB4Y19ldnRjaG4gKnhjZV9oYW5kbGUgPSBOVUxMOwogc3RydWN0IGJ1 ZmZlciB7CiAJY2hhciAqZGF0YTsKIAlzaXplX3QgY29uc3VtZWQ7Ci0Jc2l6ZV90IHNpemU7Ci0J c2l6ZV90IGNhcGFjaXR5OworCXNpemVfdCBzaXplOyAgICAgICAgIC8qIEFtb3VudCBvZiBkYXRh IGN1cnJlbnRseSBpbiB0aGUgYnVmZmVyICovCisJc2l6ZV90IGNhcGFjaXR5OyAgICAgLyogQW1v dW50IG9mIGFsbG9jYXRlZCBkYXRhIGZvciB0aGUgYnVmZmVyICovCiAJc2l6ZV90IG1heF9jYXBh Y2l0eTsKIH07CiAKIHN0cnVjdCBkb21haW4gewogCWludCBkb21pZDsKKwljaGFyICpuYW1lOwog CWludCBtYXN0ZXJfZmQ7CiAJaW50IHNsYXZlX2ZkOwogCWludCBsb2dfZmQ7CkBAIC0xNDcsNiAr MTQ4LDcgQEAgc3RhdGljIGludCB3cml0ZV93aXRoX3RpbWVzdGFtcChpbnQgZmQsIGNvbnN0IGNo YXIgKmRhdGEsIHNpemVfdCBzeiwKIHN0YXRpYyB2b2lkIGJ1ZmZlcl9hcHBlbmQoc3RydWN0IGRv bWFpbiAqZG9tKQogewogCXN0cnVjdCBidWZmZXIgKmJ1ZmZlciA9ICZkb20tPmJ1ZmZlcjsKKwlz dHJ1Y3QgYnVmZmVyIHNsYnVmID0geyAwIH07CiAJWEVOQ09OU19SSU5HX0lEWCBjb25zLCBwcm9k LCBzaXplOwogCXN0cnVjdCB4ZW5jb25zX2ludGVyZmFjZSAqaW50ZiA9IGRvbS0+aW50ZXJmYWNl OwogCkBAIC0xNTgsNyArMTYwLDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3Qg ZG9tYWluICpkb20pCiAJaWYgKChzaXplID09IDApIHx8IChzaXplID4gc2l6ZW9mKGludGYtPm91 dCkpKQogCQlyZXR1cm47CiAKLQlpZiAoKGJ1ZmZlci0+Y2FwYWNpdHkgLSBidWZmZXItPnNpemUp IDwgc2l6ZSkgeworCWlmICgoYnVmZmVyLT5jYXBhY2l0eSAtIGJ1ZmZlci0+c2l6ZSkgPCBzaXpl ICsgMSkgewogCQlidWZmZXItPmNhcGFjaXR5ICs9IChzaXplICsgMTAyNCk7CiAJCWJ1ZmZlci0+ ZGF0YSA9IHJlYWxsb2MoYnVmZmVyLT5kYXRhLCBidWZmZXItPmNhcGFjaXR5KTsKIAkJaWYgKGJ1 ZmZlci0+ZGF0YSA9PSBOVUxMKSB7CkBAIC0xNjYsMTAgKzE2OCwzMSBAQCBzdGF0aWMgdm9pZCBi dWZmZXJfYXBwZW5kKHN0cnVjdCBkb21haW4gKmRvbSkKIAkJCWV4aXQoRU5PTUVNKTsKIAkJfQog CX0KKwlzbGJ1Zi5jYXBhY2l0eSA9IGJ1ZmZlci0+Y2FwYWNpdHk7CisJc2xidWYubWF4X2NhcGFj aXR5ID0gYnVmZmVyLT5tYXhfY2FwYWNpdHk7CisJc2xidWYuZGF0YSA9IG1hbGxvYyhzbGJ1Zi5j YXBhY2l0eSk7CisJaWYgKCFzbGJ1Zi5kYXRhKSB7CisJCWRvbG9nKExPR19FUlIsICJNZW1vcnkg YWxsb2NhdGlvbiBmYWlsZWQiKTsKKwkJZXhpdChFTk9NRU0pOworCX0KIAotCXdoaWxlIChjb25z ICE9IHByb2QpCi0JCWJ1ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBpbnRmLT5vdXRbCi0J CQlNQVNLX1hFTkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJZm9yICg7IGNvbnMgIT0g cHJvZDsgKytjb25zKSB7CisJCWNoYXIgY2ggPSBpbnRmLT5vdXRbTUFTS19YRU5DT05TX0lEWChj b25zLCBpbnRmLT5vdXQpXTsKKwkJc2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCWJ1 ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBjaDsKKwkJaWYgIChjaCA9PSAnXHInIHx8IGNo ID09ICdcbicpIHsKKwkJCXNsYnVmLmRhdGFbc2xidWYuc2l6ZSAtIDFdID0gJ1wwJzsKKwkJCSsr Y29uczsKKwkJCWlmIChjb25zICE9IHByb2QpIHsKKwkJCQljaCA9IGludGYtPm91dFtNQVNLX1hF TkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJCQkJYnVmZmVyLT5kYXRhW2J1ZmZlci0+ c2l6ZSsrXSA9IGNoOworCQkJCWlmIChjaCAhPSAnXHInICYmIGNoICE9ICdcbicpIHsKKwkJCQkJ c2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJ CX0KKwl9CiAKIAl4ZW5fbWIoKTsKIAlpbnRmLT5vdXRfY29ucyA9IGNvbnM7CkBAIC0xOTYsNiAr MjE5LDkgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpkb20pCiAJ CQlkb2xvZyhMT0dfRVJSLCAiV3JpdGUgdG8gbG9nIGZhaWxlZCAiCiAJCQkgICAgICAib24gZG9t YWluICVkOiAlZCAoJXMpXG4iLAogCQkJICAgICAgZG9tLT5kb21pZCwgZXJybm8sIHN0cmVycm9y KGVycm5vKSk7CisJfSBlbHNlIHsKKwkJLyogRmFsbHMgYmFjayB0byBzeXNsb2cgaXMgdGhlIGRv bWFpbiBkb2Vzbid0IGhhdmUgYSBsb2cgZmlsZSAqLworCQlzeXNsb2coTE9HX0lORk8sICIlcyAo JWkpOiAlcyIsIGRvbS0+bmFtZSwgZG9tLT5kb21pZCwgc2xidWYuZGF0YSk7CiAJfQogCiAJaWYg KGRpc2NhcmRfb3ZlcmZsb3dlZF9kYXRhICYmIGJ1ZmZlci0+bWF4X2NhcGFjaXR5ICYmCkBAIC0y MTksNiArMjQ1LDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpk b20pCiAJCQlidWZmZXItPnNpemUgPSBidWZmZXItPm1heF9jYXBhY2l0eSAvIDIgKyBvdmVyOwog CQl9CiAJfQorCWZyZWUoc2xidWYuZGF0YSk7CiB9CiAKIHN0YXRpYyBib29sIGJ1ZmZlcl9lbXB0 eShzdHJ1Y3QgYnVmZmVyICpidWZmZXIpCkBAIC0yNTUsNiArMjgyLDEwIEBAIHN0YXRpYyBpbnQg Y3JlYXRlX2h2X2xvZyh2b2lkKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07CiAJaW50IGZk OworCisJaWYgKCFsb2dfZGlyKQorCQlyZXR1cm4gLTE7CisKIAlzbnByaW50Zihsb2dmaWxlLCBQ QVRIX01BWC0xLCAiJXMvaHlwZXJ2aXNvci5sb2ciLCBsb2dfZGlyKTsKIAlsb2dmaWxlW1BBVEhf TUFYLTFdID0gJ1wwJzsKIApAQCAtMjc1LDMyICszMDYsNTYgQEAgc3RhdGljIGludCBjcmVhdGVf aHZfbG9nKHZvaWQpCiAJcmV0dXJuIGZkOwogfQogCitzdGF0aWMgY2hhciAqc2FmZV94c19yZWFk KGNvbnN0IGNoYXIgKmtleSwgaW50IHRyaWVzKQoreworCWNoYXIgKmRhdGEgPSBOVUxMOworCXVu c2lnbmVkIGludCBsZW47CisJc3RydWN0IHRpbWVzcGVjIHJlcSA9IHsgLnR2X3NlYyA9IDAsIC50 dl9uc2VjID0gMTAwMDAwMDAwIH07IC8qIDEwMCBtcyAqLworCWludCBpOworCisJZm9yIChpID0g MDsgaSA8IHRyaWVzOyBpKyspIHsKKwkJZGF0YSA9IHhzX3JlYWQoeHMsIFhCVF9OVUxMLCBrZXks ICZsZW4pOworCQlpZiAoZGF0YSAmJiBsZW4gPiAwKQorCQkJYnJlYWs7CisJCWZyZWUoZGF0YSk7 CisJCW5hbm9zbGVlcCgmcmVxLCBOVUxMKTsKKwl9CisJcmV0dXJuIGRhdGE7Cit9CisKK3N0YXRp YyBjaGFyICpuYW1lX2Zyb21fZG9tcGF0aChjb25zdCBjaGFyICpwYXRoKQoreworCWNoYXIgbmFt ZXBhdGhbNjRdID0geyAwIH0sICpuYW1lOworCXN0cm5jYXQoIG5hbWVwYXRoLCBwYXRoICwgc2l6 ZW9mKG5hbWVwYXRoKSApOworCXN0cm5jYXQoIG5hbWVwYXRoLCAiL25hbWUiLCBzaXplb2YobmFt ZXBhdGgpIC0gc3RybGVuKG5hbWVwYXRoKSApOworCisJbmFtZSA9IHNhZmVfeHNfcmVhZChuYW1l cGF0aCwgMSk7CisJLyogd2l0aG91dCBhbnkgbmFtZSBhZnRlciAxMDAgdHJpZXMsIGp1c3QgZGVm YXVsdCB0byB1bm5hbWVkICovCisJaWYgKCFuYW1lKQorCQluYW1lID0gc3RyZHVwKCJ1bm5hbWVk Iik7CisJcmV0dXJuIG5hbWU7Cit9CisKIHN0YXRpYyBpbnQgY3JlYXRlX2RvbWFpbl9sb2coc3Ry dWN0IGRvbWFpbiAqZG9tKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07Ci0JY2hhciAqbmFt ZXBhdGgsICpkYXRhLCAqczsKKwljaGFyICpuYW1lcGF0aDsKIAlpbnQgZmQ7Ci0JdW5zaWduZWQg aW50IGxlbjsKIAogCW5hbWVwYXRoID0geHNfZ2V0X2RvbWFpbl9wYXRoKHhzLCBkb20tPmRvbWlk KTsKLQlzID0gcmVhbGxvYyhuYW1lcGF0aCwgc3RybGVuKG5hbWVwYXRoKSArIDYpOwotCWlmIChz ID09IE5VTEwpIHsKKwlpZiAobmFtZXBhdGggPT0gTlVMTCkgewogCQlmcmVlKG5hbWVwYXRoKTsK IAkJcmV0dXJuIC0xOwogCX0KLQluYW1lcGF0aCA9IHM7Ci0Jc3RyY2F0KG5hbWVwYXRoLCAiL25h bWUiKTsKLQlkYXRhID0geHNfcmVhZCh4cywgWEJUX05VTEwsIG5hbWVwYXRoLCAmbGVuKTsKKwlk b20tPm5hbWUgPSBuYW1lX2Zyb21fZG9tcGF0aChuYW1lcGF0aCk7CiAJZnJlZShuYW1lcGF0aCk7 Ci0JaWYgKCFkYXRhKQorCWlmICghZG9tLT5uYW1lKSB7CiAJCXJldHVybiAtMTsKLQlpZiAoIWxl bikgewotCQlmcmVlKGRhdGEpOworCX0KKwlpZiAoIWxvZ19kaXIpIHsKIAkJcmV0dXJuIC0xOwog CX0KLQotCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFYLTEsICIlcy9ndWVzdC0lcy5sb2ciLCBs b2dfZGlyLCBkYXRhKTsKLQlmcmVlKGRhdGEpOworCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFY IC0gMSwgIiVzLyVzLmxvZyIsIGxvZ19kaXIsIGRvbS0+bmFtZSk7CiAJbG9nZmlsZVtQQVRIX01B WC0xXSA9ICdcMCc7CiAKIAlmZCA9IG9wZW4obG9nZmlsZSwgT19XUk9OTFl8T19DUkVBVHxPX0FQ UEVORCwgMDY0NCk7CkBAIC02NTYsNiArNzExLDcgQEAgc3RhdGljIHN0cnVjdCBkb21haW4gKmNy ZWF0ZV9kb21haW4oaW50IGRvbWlkKQogCWRvbS0+cmVtb3RlX3BvcnQgPSAtMTsKIAlkb20tPmlu dGVyZmFjZSA9IE5VTEw7CiAJZG9tLT54Y2VfaGFuZGxlID0gTlVMTDsKKwlkb20tPm5hbWUgPSBO VUxMOwogCiAJaWYgKCF3YXRjaF9kb21haW4oZG9tLCB0cnVlKSkKIAkJZ290byBvdXQ7CkBAIC03 MTIsNiArNzY4LDExIEBAIHN0YXRpYyB2b2lkIGNsZWFudXBfZG9tYWluKHN0cnVjdCBkb21haW4g KmQpCiAJZnJlZShkLT5jb25zcGF0aCk7CiAJZC0+Y29uc3BhdGggPSBOVUxMOwogCisgICAgICAg IGlmIChkLT5uYW1lKSB7CisJICAgIGZyZWUoZC0+bmFtZSk7CisJICAgIGQtPm5hbWUgPSBOVUxM OworICAgICAgICB9CisKIAlyZW1vdmVfZG9tYWluKGQpOwogfQogCkBAIC04NzgsNyArOTM5LDEw IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV94cyh2b2lkKQogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHZf bG9ncyh2b2lkKQogewotCWNoYXIgYnVmZmVyWzEwMjQqMTZdOworCWNoYXIgYnVmZmVyWzEwMjQq MTYgKyAxXTsKKwlzdGF0aWMgY2hhciBsYnVmWzEwMjQqMTYgKyAxXTsKKwlzdGF0aWMgaW50IGxv ZmYgPSAwOworCWludCBpID0gMDsKIAljaGFyICpidWZwdHIgPSBidWZmZXI7CiAJdW5zaWduZWQg aW50IHNpemUgPSBzaXplb2YoYnVmZmVyKTsKIAlzdGF0aWMgdWludDMyX3QgaW5kZXggPSAwOwpA QCAtODg4LDE3ICs5NTIsMzYgQEAgc3RhdGljIHZvaWQgaGFuZGxlX2h2X2xvZ3Modm9pZCkKIAkJ cmV0dXJuOwogCiAJaWYgKHhjX3JlYWRjb25zb2xlcmluZyh4Y2gsIGJ1ZnB0ciwgJnNpemUsIDAs IDEsICZpbmRleCkgPT0gMCAmJiBzaXplID4gMCkgewotCQlpbnQgbG9ncmV0OwotCQlpZiAobG9n X3RpbWVfaHYpCi0JCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKLQkJCQkJCSAgICAgICZsb2dfdGltZV9odl9uZWVkdHMpOwotCQllbHNlCi0J CQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOwotCi0JCWlmIChs b2dyZXQgPCAwKQotCQkJZG9sb2coTE9HX0VSUiwgIkZhaWxlZCB0byB3cml0ZSBoeXBlcnZpc29y IGxvZzogIgotCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJubykpOwot CX0KKwkJaWYgKGxvZ19odl9mZCAhPSAtMSkgeworCQkJaW50IGxvZ3JldDsKKwkJCWlmIChsb2df dGltZV9odikKKwkJCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKKwkJCQkJCQkgICAgICAmbG9nX3RpbWVfaHZfbmVlZHRzKTsKKwkJCWVsc2UK KwkJCQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOworCisJCQlp ZiAobG9ncmV0IDwgMCkKKwkJCQlkb2xvZyhMT0dfRVJSLCAiRmFpbGVkIHRvIHdyaXRlIGh5cGVy dmlzb3IgbG9nOiAiCisJCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJu bykpOworCQl9IGVsc2UgeworCQkJd2hpbGUgKGkgPCBzaXplKSB7CisJCQkJd2hpbGUgKChpIDwg c2l6ZSkgJiYKKwkJCQkgICAgICAgKGJ1ZmZlcltpXSAhPSAnXG4nKSAmJiAoYnVmZmVyW2ldICE9 ICdccicpKSB7CisJCQkJCWxidWZbbG9mZisrXSA9IGJ1ZmZlcltpKytdOworCQkJCX0KKwkJCQlp ZiAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSB7CisJCQkJCWxi dWZbbG9mZl0gPSAnXDAnOworCQkJCQkrK2k7CisJCQkJCWlmICgoaSA8IHNpemUpICYmCisJCQkJ CSAgICAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSkgeworCQkJ CQkJKytpOworCQkJCQl9CisJCQkJCXN5c2xvZyhMT0dfSU5GTywgImh5cGVydmlzb3I6ICVzIiwg bGJ1Zik7CisJCQkJCWxvZmYgPSAwOworCQkJCX0KKwkJCX0KKwkJfQorICAgICAgICB9CiAKIAko dm9pZCl4Y19ldnRjaG5fdW5tYXNrKHhjZV9oYW5kbGUsIHBvcnQpOwogfQpAQCAtOTQwLDggKzEw MjMsNiBAQCB2b2lkIGhhbmRsZV9pbyh2b2lkKQogCQkJZ290byBvdXQ7CiAJCX0KIAkJbG9nX2h2 X2ZkID0gY3JlYXRlX2h2X2xvZygpOwotCQlpZiAobG9nX2h2X2ZkID09IC0xKQotCQkJZ290byBv dXQ7CiAJCWxvZ19odl9ldnRjaG4gPSB4Y19ldnRjaG5fYmluZF92aXJxKHhjZV9oYW5kbGUsIFZJ UlFfQ09OX1JJTkcpOwogCQlpZiAobG9nX2h2X2V2dGNobiA9PSAtMSkgewogCQkJZG9sb2coTE9H X0VSUiwgIkZhaWxlZCB0byBiaW5kIHRvIFZJUlFfQ09OX1JJTkc6ICIKZGlmZiAtLWdpdCBhL3Rv b2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYyBiL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYwpp bmRleCA3ODliYWE2Li45MTljODZlIDEwMDY0NAotLS0gYS90b29scy9jb25zb2xlL2RhZW1vbi9t YWluLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vbWFpbi5jCkBAIC0zOSw2ICszOSw3IEBA IGludCBsb2dfdGltZV9odiA9IDA7CiBpbnQgbG9nX3RpbWVfZ3Vlc3QgPSAwOwogY2hhciAqbG9n X2RpciA9IE5VTEw7CiBpbnQgZGlzY2FyZF9vdmVyZmxvd2VkX2RhdGEgPSAxOworaW50IHVzZV9z eXNsb2cgPSAwOwogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHVwKGludCBzaWcpCiB7CkBAIC00Nyw3 ICs0OCw3IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV9odXAoaW50IHNpZykKIAogc3RhdGljIHZvaWQg dXNhZ2UoY2hhciAqbmFtZSkKIHsKLQlwcmludGYoIlVzYWdlOiAlcyBbLWhdIFstVl0gWy12XSBb LWldIFstLWxvZz1ub25lfGd1ZXN0fGh2fGFsbF0gWy0tbG9nLWRpcj1ESVJdIFstLXBpZC1maWxl PVBBVEhdIFstdCwgLS10aW1lc3RhbXA9bm9uZXxndWVzdHxodnxhbGxdIFstbywgLS1vdmVyZmxv dy1kYXRhPWRpc2NhcmR8a2VlcF1cbiIsIG5hbWUpOworCXByaW50ZigiVXNhZ2U6ICVzIFstaF0g Wy1WXSBbLXZdIFstaV0gWy0tbG9nPW5vbmV8Z3Vlc3R8aHZ8YWxsXSBbLS1zeXNsb2ddIFstLWxv Zy1kaXI9RElSXSBbLS1waWQtZmlsZT1QQVRIXSBbLXQsIC0tdGltZXN0YW1wPW5vbmV8Z3Vlc3R8 aHZ8YWxsXSBbLW8sIC0tb3ZlcmZsb3ctZGF0YT1kaXNjYXJkfGtlZXBdXG4iLCBuYW1lKTsKIH0K IAogc3RhdGljIHZvaWQgdmVyc2lvbihjaGFyICpuYW1lKQpAQCAtNjgsNiArNjksNyBAQCBpbnQg bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAJCXsgInBpZC1maWxlIiwgMSwgMCwgJ3AnIH0s CiAJCXsgInRpbWVzdGFtcCIsIDEsIDAsICd0JyB9LAogCQl7ICJvdmVyZmxvdy1kYXRhIiwgMSwg MCwgJ28nfSwKKwkJeyAic3lzbG9nIiwgMCwgMCwgJ3MnIH0sCiAJCXsgMCB9LAogCX07CiAJYm9v bCBpc19pbnRlcmFjdGl2ZSA9IGZhbHNlOwpAQCAtMTA2LDYgKzEwOCw5IEBAIGludCBtYWluKGlu dCBhcmdjLCBjaGFyICoqYXJndikKIAkJCSAgICAgIGxvZ19ndWVzdCA9IDE7CiAJCQl9CiAJCQli cmVhazsKKwkJY2FzZSAncyc6CisJCQl1c2Vfc3lzbG9nID0gMTsKKyAgICAgICAgICAgICAgICAg ICAgICAgIGJyZWFrOwogCQljYXNlICdyJzoKIAkJICAgICAgICBsb2dfZGlyID0gc3RyZHVwKG9w dGFyZyk7CiAJCQlicmVhazsKQEAgLTE0MCw3ICsxNDUsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCiAJCX0KIAl9CiAKLQlpZiAoIWxvZ19kaXIpIHsKKwlpZiAoIWxvZ19kaXIg JiYgIXVzZV9zeXNsb2cpIHsKIAkJbG9nX2RpciA9IHN0cmR1cCgiL3Zhci9sb2cveGVuL2NvbnNv bGUiKTsKIAl9CiAK --20cf307f38060445a804bfabab62 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf307f38060445a804bfabab62-- From xen-devel-bounces@lists.xen.org Thu May 10 09:59:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 09:59:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ9F-0004ik-CM; Thu, 10 May 2012 09:59:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQ9D-0004iR-Os for xen-devel@lists.xen.org; Thu, 10 May 2012 09:59:00 +0000 Received: from [85.158.143.99:36228] by server-3.bemta-4.messagelabs.com id 35/2E-05853-2619BAF4; Thu, 10 May 2012 09:58:58 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336643936!16132435!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28886 invoked from network); 10 May 2012 09:58:57 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 09:58:57 -0000 Received: by vbbfn1 with SMTP id fn1so249971vbb.32 for ; Thu, 10 May 2012 02:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xIfub88OwXh4HGATw152y5+U3E/E5LF5X+aXl1Buz0k=; b=unkBQs550bKKNg6VUYvWEkfBDFYWdlmKerJZ0BsiwkUNjofhUnW1aeCQfejPDE8KMH t5pEf7jnA5CAEY3yk/sOPHaZX8dOPYzZi7zbcBw7o+aLYEblVLKx0EjkQMU/c9RFsV6W RAA1BGoxojygoYe/WXMmTrTCI9F1+ZVH1YTRuKP8bt8tcSSIYTOj2V7lc+H3+9OIgQww ACxr5dRuSt49UZG46uhNGLV8S9J+mwbQXbCAsRxwc56p8xPWpn/gqB7sCTCgiF+Qdx/k lcyPxWgrIFmtbcdJJOKYVZbhRi9oPChoSvmilk9HYwqixsjT1/hvETV/iJJNX915ho1y wEYQ== Received: by 10.52.97.41 with SMTP id dx9mr1700695vdb.89.1336643936339; Thu, 10 May 2012 02:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 02:58:36 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 10:58:36 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=20cf307f38060445a804bfabab62 Cc: Eric Chanudet Subject: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf307f38060445a804bfabab62 Content-Type: text/plain; charset=ISO-8859-1 Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. The default behaviour remains the same (log into plain files) From: Eric Chanudet Signed-off-by: Jean Guyader --20cf307f38060445a804bfabab62 Content-Type: text/x-patch; charset=US-ASCII; name="xenconsoled-syslog.patch" Content-Disposition: attachment; filename="xenconsoled-syslog.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21mn1zq1 ZGlmZiAtLWdpdCBhL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL2lvLmMgYi90b29scy9jb25zb2xlL2Rh ZW1vbi9pby5jCmluZGV4IGI2ZDQxZGUuLmIxOGJlM2UgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbnNv bGUvZGFlbW9uL2lvLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vaW8uYwpAQCAtNzMsMTMg KzczLDE0IEBAIHN0YXRpYyB4Y19ldnRjaG4gKnhjZV9oYW5kbGUgPSBOVUxMOwogc3RydWN0IGJ1 ZmZlciB7CiAJY2hhciAqZGF0YTsKIAlzaXplX3QgY29uc3VtZWQ7Ci0Jc2l6ZV90IHNpemU7Ci0J c2l6ZV90IGNhcGFjaXR5OworCXNpemVfdCBzaXplOyAgICAgICAgIC8qIEFtb3VudCBvZiBkYXRh IGN1cnJlbnRseSBpbiB0aGUgYnVmZmVyICovCisJc2l6ZV90IGNhcGFjaXR5OyAgICAgLyogQW1v dW50IG9mIGFsbG9jYXRlZCBkYXRhIGZvciB0aGUgYnVmZmVyICovCiAJc2l6ZV90IG1heF9jYXBh Y2l0eTsKIH07CiAKIHN0cnVjdCBkb21haW4gewogCWludCBkb21pZDsKKwljaGFyICpuYW1lOwog CWludCBtYXN0ZXJfZmQ7CiAJaW50IHNsYXZlX2ZkOwogCWludCBsb2dfZmQ7CkBAIC0xNDcsNiAr MTQ4LDcgQEAgc3RhdGljIGludCB3cml0ZV93aXRoX3RpbWVzdGFtcChpbnQgZmQsIGNvbnN0IGNo YXIgKmRhdGEsIHNpemVfdCBzeiwKIHN0YXRpYyB2b2lkIGJ1ZmZlcl9hcHBlbmQoc3RydWN0IGRv bWFpbiAqZG9tKQogewogCXN0cnVjdCBidWZmZXIgKmJ1ZmZlciA9ICZkb20tPmJ1ZmZlcjsKKwlz dHJ1Y3QgYnVmZmVyIHNsYnVmID0geyAwIH07CiAJWEVOQ09OU19SSU5HX0lEWCBjb25zLCBwcm9k LCBzaXplOwogCXN0cnVjdCB4ZW5jb25zX2ludGVyZmFjZSAqaW50ZiA9IGRvbS0+aW50ZXJmYWNl OwogCkBAIC0xNTgsNyArMTYwLDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3Qg ZG9tYWluICpkb20pCiAJaWYgKChzaXplID09IDApIHx8IChzaXplID4gc2l6ZW9mKGludGYtPm91 dCkpKQogCQlyZXR1cm47CiAKLQlpZiAoKGJ1ZmZlci0+Y2FwYWNpdHkgLSBidWZmZXItPnNpemUp IDwgc2l6ZSkgeworCWlmICgoYnVmZmVyLT5jYXBhY2l0eSAtIGJ1ZmZlci0+c2l6ZSkgPCBzaXpl ICsgMSkgewogCQlidWZmZXItPmNhcGFjaXR5ICs9IChzaXplICsgMTAyNCk7CiAJCWJ1ZmZlci0+ ZGF0YSA9IHJlYWxsb2MoYnVmZmVyLT5kYXRhLCBidWZmZXItPmNhcGFjaXR5KTsKIAkJaWYgKGJ1 ZmZlci0+ZGF0YSA9PSBOVUxMKSB7CkBAIC0xNjYsMTAgKzE2OCwzMSBAQCBzdGF0aWMgdm9pZCBi dWZmZXJfYXBwZW5kKHN0cnVjdCBkb21haW4gKmRvbSkKIAkJCWV4aXQoRU5PTUVNKTsKIAkJfQog CX0KKwlzbGJ1Zi5jYXBhY2l0eSA9IGJ1ZmZlci0+Y2FwYWNpdHk7CisJc2xidWYubWF4X2NhcGFj aXR5ID0gYnVmZmVyLT5tYXhfY2FwYWNpdHk7CisJc2xidWYuZGF0YSA9IG1hbGxvYyhzbGJ1Zi5j YXBhY2l0eSk7CisJaWYgKCFzbGJ1Zi5kYXRhKSB7CisJCWRvbG9nKExPR19FUlIsICJNZW1vcnkg YWxsb2NhdGlvbiBmYWlsZWQiKTsKKwkJZXhpdChFTk9NRU0pOworCX0KIAotCXdoaWxlIChjb25z ICE9IHByb2QpCi0JCWJ1ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBpbnRmLT5vdXRbCi0J CQlNQVNLX1hFTkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJZm9yICg7IGNvbnMgIT0g cHJvZDsgKytjb25zKSB7CisJCWNoYXIgY2ggPSBpbnRmLT5vdXRbTUFTS19YRU5DT05TX0lEWChj b25zLCBpbnRmLT5vdXQpXTsKKwkJc2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCWJ1 ZmZlci0+ZGF0YVtidWZmZXItPnNpemUrK10gPSBjaDsKKwkJaWYgIChjaCA9PSAnXHInIHx8IGNo ID09ICdcbicpIHsKKwkJCXNsYnVmLmRhdGFbc2xidWYuc2l6ZSAtIDFdID0gJ1wwJzsKKwkJCSsr Y29uczsKKwkJCWlmIChjb25zICE9IHByb2QpIHsKKwkJCQljaCA9IGludGYtPm91dFtNQVNLX1hF TkNPTlNfSURYKGNvbnMrKywgaW50Zi0+b3V0KV07CisJCQkJYnVmZmVyLT5kYXRhW2J1ZmZlci0+ c2l6ZSsrXSA9IGNoOworCQkJCWlmIChjaCAhPSAnXHInICYmIGNoICE9ICdcbicpIHsKKwkJCQkJ c2xidWYuZGF0YVtzbGJ1Zi5zaXplKytdID0gY2g7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisJ CX0KKwl9CiAKIAl4ZW5fbWIoKTsKIAlpbnRmLT5vdXRfY29ucyA9IGNvbnM7CkBAIC0xOTYsNiAr MjE5LDkgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpkb20pCiAJ CQlkb2xvZyhMT0dfRVJSLCAiV3JpdGUgdG8gbG9nIGZhaWxlZCAiCiAJCQkgICAgICAib24gZG9t YWluICVkOiAlZCAoJXMpXG4iLAogCQkJICAgICAgZG9tLT5kb21pZCwgZXJybm8sIHN0cmVycm9y KGVycm5vKSk7CisJfSBlbHNlIHsKKwkJLyogRmFsbHMgYmFjayB0byBzeXNsb2cgaXMgdGhlIGRv bWFpbiBkb2Vzbid0IGhhdmUgYSBsb2cgZmlsZSAqLworCQlzeXNsb2coTE9HX0lORk8sICIlcyAo JWkpOiAlcyIsIGRvbS0+bmFtZSwgZG9tLT5kb21pZCwgc2xidWYuZGF0YSk7CiAJfQogCiAJaWYg KGRpc2NhcmRfb3ZlcmZsb3dlZF9kYXRhICYmIGJ1ZmZlci0+bWF4X2NhcGFjaXR5ICYmCkBAIC0y MTksNiArMjQ1LDcgQEAgc3RhdGljIHZvaWQgYnVmZmVyX2FwcGVuZChzdHJ1Y3QgZG9tYWluICpk b20pCiAJCQlidWZmZXItPnNpemUgPSBidWZmZXItPm1heF9jYXBhY2l0eSAvIDIgKyBvdmVyOwog CQl9CiAJfQorCWZyZWUoc2xidWYuZGF0YSk7CiB9CiAKIHN0YXRpYyBib29sIGJ1ZmZlcl9lbXB0 eShzdHJ1Y3QgYnVmZmVyICpidWZmZXIpCkBAIC0yNTUsNiArMjgyLDEwIEBAIHN0YXRpYyBpbnQg Y3JlYXRlX2h2X2xvZyh2b2lkKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07CiAJaW50IGZk OworCisJaWYgKCFsb2dfZGlyKQorCQlyZXR1cm4gLTE7CisKIAlzbnByaW50Zihsb2dmaWxlLCBQ QVRIX01BWC0xLCAiJXMvaHlwZXJ2aXNvci5sb2ciLCBsb2dfZGlyKTsKIAlsb2dmaWxlW1BBVEhf TUFYLTFdID0gJ1wwJzsKIApAQCAtMjc1LDMyICszMDYsNTYgQEAgc3RhdGljIGludCBjcmVhdGVf aHZfbG9nKHZvaWQpCiAJcmV0dXJuIGZkOwogfQogCitzdGF0aWMgY2hhciAqc2FmZV94c19yZWFk KGNvbnN0IGNoYXIgKmtleSwgaW50IHRyaWVzKQoreworCWNoYXIgKmRhdGEgPSBOVUxMOworCXVu c2lnbmVkIGludCBsZW47CisJc3RydWN0IHRpbWVzcGVjIHJlcSA9IHsgLnR2X3NlYyA9IDAsIC50 dl9uc2VjID0gMTAwMDAwMDAwIH07IC8qIDEwMCBtcyAqLworCWludCBpOworCisJZm9yIChpID0g MDsgaSA8IHRyaWVzOyBpKyspIHsKKwkJZGF0YSA9IHhzX3JlYWQoeHMsIFhCVF9OVUxMLCBrZXks ICZsZW4pOworCQlpZiAoZGF0YSAmJiBsZW4gPiAwKQorCQkJYnJlYWs7CisJCWZyZWUoZGF0YSk7 CisJCW5hbm9zbGVlcCgmcmVxLCBOVUxMKTsKKwl9CisJcmV0dXJuIGRhdGE7Cit9CisKK3N0YXRp YyBjaGFyICpuYW1lX2Zyb21fZG9tcGF0aChjb25zdCBjaGFyICpwYXRoKQoreworCWNoYXIgbmFt ZXBhdGhbNjRdID0geyAwIH0sICpuYW1lOworCXN0cm5jYXQoIG5hbWVwYXRoLCBwYXRoICwgc2l6 ZW9mKG5hbWVwYXRoKSApOworCXN0cm5jYXQoIG5hbWVwYXRoLCAiL25hbWUiLCBzaXplb2YobmFt ZXBhdGgpIC0gc3RybGVuKG5hbWVwYXRoKSApOworCisJbmFtZSA9IHNhZmVfeHNfcmVhZChuYW1l cGF0aCwgMSk7CisJLyogd2l0aG91dCBhbnkgbmFtZSBhZnRlciAxMDAgdHJpZXMsIGp1c3QgZGVm YXVsdCB0byB1bm5hbWVkICovCisJaWYgKCFuYW1lKQorCQluYW1lID0gc3RyZHVwKCJ1bm5hbWVk Iik7CisJcmV0dXJuIG5hbWU7Cit9CisKIHN0YXRpYyBpbnQgY3JlYXRlX2RvbWFpbl9sb2coc3Ry dWN0IGRvbWFpbiAqZG9tKQogewogCWNoYXIgbG9nZmlsZVtQQVRIX01BWF07Ci0JY2hhciAqbmFt ZXBhdGgsICpkYXRhLCAqczsKKwljaGFyICpuYW1lcGF0aDsKIAlpbnQgZmQ7Ci0JdW5zaWduZWQg aW50IGxlbjsKIAogCW5hbWVwYXRoID0geHNfZ2V0X2RvbWFpbl9wYXRoKHhzLCBkb20tPmRvbWlk KTsKLQlzID0gcmVhbGxvYyhuYW1lcGF0aCwgc3RybGVuKG5hbWVwYXRoKSArIDYpOwotCWlmIChz ID09IE5VTEwpIHsKKwlpZiAobmFtZXBhdGggPT0gTlVMTCkgewogCQlmcmVlKG5hbWVwYXRoKTsK IAkJcmV0dXJuIC0xOwogCX0KLQluYW1lcGF0aCA9IHM7Ci0Jc3RyY2F0KG5hbWVwYXRoLCAiL25h bWUiKTsKLQlkYXRhID0geHNfcmVhZCh4cywgWEJUX05VTEwsIG5hbWVwYXRoLCAmbGVuKTsKKwlk b20tPm5hbWUgPSBuYW1lX2Zyb21fZG9tcGF0aChuYW1lcGF0aCk7CiAJZnJlZShuYW1lcGF0aCk7 Ci0JaWYgKCFkYXRhKQorCWlmICghZG9tLT5uYW1lKSB7CiAJCXJldHVybiAtMTsKLQlpZiAoIWxl bikgewotCQlmcmVlKGRhdGEpOworCX0KKwlpZiAoIWxvZ19kaXIpIHsKIAkJcmV0dXJuIC0xOwog CX0KLQotCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFYLTEsICIlcy9ndWVzdC0lcy5sb2ciLCBs b2dfZGlyLCBkYXRhKTsKLQlmcmVlKGRhdGEpOworCXNucHJpbnRmKGxvZ2ZpbGUsIFBBVEhfTUFY IC0gMSwgIiVzLyVzLmxvZyIsIGxvZ19kaXIsIGRvbS0+bmFtZSk7CiAJbG9nZmlsZVtQQVRIX01B WC0xXSA9ICdcMCc7CiAKIAlmZCA9IG9wZW4obG9nZmlsZSwgT19XUk9OTFl8T19DUkVBVHxPX0FQ UEVORCwgMDY0NCk7CkBAIC02NTYsNiArNzExLDcgQEAgc3RhdGljIHN0cnVjdCBkb21haW4gKmNy ZWF0ZV9kb21haW4oaW50IGRvbWlkKQogCWRvbS0+cmVtb3RlX3BvcnQgPSAtMTsKIAlkb20tPmlu dGVyZmFjZSA9IE5VTEw7CiAJZG9tLT54Y2VfaGFuZGxlID0gTlVMTDsKKwlkb20tPm5hbWUgPSBO VUxMOwogCiAJaWYgKCF3YXRjaF9kb21haW4oZG9tLCB0cnVlKSkKIAkJZ290byBvdXQ7CkBAIC03 MTIsNiArNzY4LDExIEBAIHN0YXRpYyB2b2lkIGNsZWFudXBfZG9tYWluKHN0cnVjdCBkb21haW4g KmQpCiAJZnJlZShkLT5jb25zcGF0aCk7CiAJZC0+Y29uc3BhdGggPSBOVUxMOwogCisgICAgICAg IGlmIChkLT5uYW1lKSB7CisJICAgIGZyZWUoZC0+bmFtZSk7CisJICAgIGQtPm5hbWUgPSBOVUxM OworICAgICAgICB9CisKIAlyZW1vdmVfZG9tYWluKGQpOwogfQogCkBAIC04NzgsNyArOTM5LDEw IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV94cyh2b2lkKQogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHZf bG9ncyh2b2lkKQogewotCWNoYXIgYnVmZmVyWzEwMjQqMTZdOworCWNoYXIgYnVmZmVyWzEwMjQq MTYgKyAxXTsKKwlzdGF0aWMgY2hhciBsYnVmWzEwMjQqMTYgKyAxXTsKKwlzdGF0aWMgaW50IGxv ZmYgPSAwOworCWludCBpID0gMDsKIAljaGFyICpidWZwdHIgPSBidWZmZXI7CiAJdW5zaWduZWQg aW50IHNpemUgPSBzaXplb2YoYnVmZmVyKTsKIAlzdGF0aWMgdWludDMyX3QgaW5kZXggPSAwOwpA QCAtODg4LDE3ICs5NTIsMzYgQEAgc3RhdGljIHZvaWQgaGFuZGxlX2h2X2xvZ3Modm9pZCkKIAkJ cmV0dXJuOwogCiAJaWYgKHhjX3JlYWRjb25zb2xlcmluZyh4Y2gsIGJ1ZnB0ciwgJnNpemUsIDAs IDEsICZpbmRleCkgPT0gMCAmJiBzaXplID4gMCkgewotCQlpbnQgbG9ncmV0OwotCQlpZiAobG9n X3RpbWVfaHYpCi0JCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKLQkJCQkJCSAgICAgICZsb2dfdGltZV9odl9uZWVkdHMpOwotCQllbHNlCi0J CQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOwotCi0JCWlmIChs b2dyZXQgPCAwKQotCQkJZG9sb2coTE9HX0VSUiwgIkZhaWxlZCB0byB3cml0ZSBoeXBlcnZpc29y IGxvZzogIgotCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJubykpOwot CX0KKwkJaWYgKGxvZ19odl9mZCAhPSAtMSkgeworCQkJaW50IGxvZ3JldDsKKwkJCWlmIChsb2df dGltZV9odikKKwkJCQlsb2dyZXQgPSB3cml0ZV93aXRoX3RpbWVzdGFtcChsb2dfaHZfZmQsIGJ1 ZmZlciwgc2l6ZSwKKwkJCQkJCQkgICAgICAmbG9nX3RpbWVfaHZfbmVlZHRzKTsKKwkJCWVsc2UK KwkJCQlsb2dyZXQgPSB3cml0ZV9hbGwobG9nX2h2X2ZkLCBidWZmZXIsIHNpemUpOworCisJCQlp ZiAobG9ncmV0IDwgMCkKKwkJCQlkb2xvZyhMT0dfRVJSLCAiRmFpbGVkIHRvIHdyaXRlIGh5cGVy dmlzb3IgbG9nOiAiCisJCQkJCSAgICAgICAiJWQgKCVzKSIsIGVycm5vLCBzdHJlcnJvcihlcnJu bykpOworCQl9IGVsc2UgeworCQkJd2hpbGUgKGkgPCBzaXplKSB7CisJCQkJd2hpbGUgKChpIDwg c2l6ZSkgJiYKKwkJCQkgICAgICAgKGJ1ZmZlcltpXSAhPSAnXG4nKSAmJiAoYnVmZmVyW2ldICE9 ICdccicpKSB7CisJCQkJCWxidWZbbG9mZisrXSA9IGJ1ZmZlcltpKytdOworCQkJCX0KKwkJCQlp ZiAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSB7CisJCQkJCWxi dWZbbG9mZl0gPSAnXDAnOworCQkJCQkrK2k7CisJCQkJCWlmICgoaSA8IHNpemUpICYmCisJCQkJ CSAgICAoKGJ1ZmZlcltpXSA9PSAnXG4nKSB8fCAoYnVmZmVyW2ldID09ICdccicpKSkgeworCQkJ CQkJKytpOworCQkJCQl9CisJCQkJCXN5c2xvZyhMT0dfSU5GTywgImh5cGVydmlzb3I6ICVzIiwg bGJ1Zik7CisJCQkJCWxvZmYgPSAwOworCQkJCX0KKwkJCX0KKwkJfQorICAgICAgICB9CiAKIAko dm9pZCl4Y19ldnRjaG5fdW5tYXNrKHhjZV9oYW5kbGUsIHBvcnQpOwogfQpAQCAtOTQwLDggKzEw MjMsNiBAQCB2b2lkIGhhbmRsZV9pbyh2b2lkKQogCQkJZ290byBvdXQ7CiAJCX0KIAkJbG9nX2h2 X2ZkID0gY3JlYXRlX2h2X2xvZygpOwotCQlpZiAobG9nX2h2X2ZkID09IC0xKQotCQkJZ290byBv dXQ7CiAJCWxvZ19odl9ldnRjaG4gPSB4Y19ldnRjaG5fYmluZF92aXJxKHhjZV9oYW5kbGUsIFZJ UlFfQ09OX1JJTkcpOwogCQlpZiAobG9nX2h2X2V2dGNobiA9PSAtMSkgewogCQkJZG9sb2coTE9H X0VSUiwgIkZhaWxlZCB0byBiaW5kIHRvIFZJUlFfQ09OX1JJTkc6ICIKZGlmZiAtLWdpdCBhL3Rv b2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYyBiL3Rvb2xzL2NvbnNvbGUvZGFlbW9uL21haW4uYwpp bmRleCA3ODliYWE2Li45MTljODZlIDEwMDY0NAotLS0gYS90b29scy9jb25zb2xlL2RhZW1vbi9t YWluLmMKKysrIGIvdG9vbHMvY29uc29sZS9kYWVtb24vbWFpbi5jCkBAIC0zOSw2ICszOSw3IEBA IGludCBsb2dfdGltZV9odiA9IDA7CiBpbnQgbG9nX3RpbWVfZ3Vlc3QgPSAwOwogY2hhciAqbG9n X2RpciA9IE5VTEw7CiBpbnQgZGlzY2FyZF9vdmVyZmxvd2VkX2RhdGEgPSAxOworaW50IHVzZV9z eXNsb2cgPSAwOwogCiBzdGF0aWMgdm9pZCBoYW5kbGVfaHVwKGludCBzaWcpCiB7CkBAIC00Nyw3 ICs0OCw3IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV9odXAoaW50IHNpZykKIAogc3RhdGljIHZvaWQg dXNhZ2UoY2hhciAqbmFtZSkKIHsKLQlwcmludGYoIlVzYWdlOiAlcyBbLWhdIFstVl0gWy12XSBb LWldIFstLWxvZz1ub25lfGd1ZXN0fGh2fGFsbF0gWy0tbG9nLWRpcj1ESVJdIFstLXBpZC1maWxl PVBBVEhdIFstdCwgLS10aW1lc3RhbXA9bm9uZXxndWVzdHxodnxhbGxdIFstbywgLS1vdmVyZmxv dy1kYXRhPWRpc2NhcmR8a2VlcF1cbiIsIG5hbWUpOworCXByaW50ZigiVXNhZ2U6ICVzIFstaF0g Wy1WXSBbLXZdIFstaV0gWy0tbG9nPW5vbmV8Z3Vlc3R8aHZ8YWxsXSBbLS1zeXNsb2ddIFstLWxv Zy1kaXI9RElSXSBbLS1waWQtZmlsZT1QQVRIXSBbLXQsIC0tdGltZXN0YW1wPW5vbmV8Z3Vlc3R8 aHZ8YWxsXSBbLW8sIC0tb3ZlcmZsb3ctZGF0YT1kaXNjYXJkfGtlZXBdXG4iLCBuYW1lKTsKIH0K IAogc3RhdGljIHZvaWQgdmVyc2lvbihjaGFyICpuYW1lKQpAQCAtNjgsNiArNjksNyBAQCBpbnQg bWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAJCXsgInBpZC1maWxlIiwgMSwgMCwgJ3AnIH0s CiAJCXsgInRpbWVzdGFtcCIsIDEsIDAsICd0JyB9LAogCQl7ICJvdmVyZmxvdy1kYXRhIiwgMSwg MCwgJ28nfSwKKwkJeyAic3lzbG9nIiwgMCwgMCwgJ3MnIH0sCiAJCXsgMCB9LAogCX07CiAJYm9v bCBpc19pbnRlcmFjdGl2ZSA9IGZhbHNlOwpAQCAtMTA2LDYgKzEwOCw5IEBAIGludCBtYWluKGlu dCBhcmdjLCBjaGFyICoqYXJndikKIAkJCSAgICAgIGxvZ19ndWVzdCA9IDE7CiAJCQl9CiAJCQli cmVhazsKKwkJY2FzZSAncyc6CisJCQl1c2Vfc3lzbG9nID0gMTsKKyAgICAgICAgICAgICAgICAg ICAgICAgIGJyZWFrOwogCQljYXNlICdyJzoKIAkJICAgICAgICBsb2dfZGlyID0gc3RyZHVwKG9w dGFyZyk7CiAJCQlicmVhazsKQEAgLTE0MCw3ICsxNDUsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCiAJCX0KIAl9CiAKLQlpZiAoIWxvZ19kaXIpIHsKKwlpZiAoIWxvZ19kaXIg JiYgIXVzZV9zeXNsb2cpIHsKIAkJbG9nX2RpciA9IHN0cmR1cCgiL3Zhci9sb2cveGVuL2NvbnNv bGUiKTsKIAl9CiAK --20cf307f38060445a804bfabab62 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf307f38060445a804bfabab62-- From xen-devel-bounces@lists.xen.org Thu May 10 10:11:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:11:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQKt-0005Ap-Q6; Thu, 10 May 2012 10:11:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQKs-0005Ak-IR for xen-devel@lists.xen.org; Thu, 10 May 2012 10:11:02 +0000 Received: from [193.109.254.147:8778] by server-9.bemta-14.messagelabs.com id 88/05-05787-4349BAF4; Thu, 10 May 2012 10:11:00 +0000 X-Env-Sender: berrange@redhat.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336644657!862412!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MjA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15264 invoked from network); 10 May 2012 10:10:58 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-7.tower-27.messagelabs.com with SMTP; 10 May 2012 10:10:58 -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 q4AAArXn020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 06:10:53 -0400 Received: from redhat.com (vpn1-4-177.ams2.redhat.com [10.36.4.177]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4AAAhgI031164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 06:10:46 -0400 Date: Thu, 10 May 2012 11:10:43 +0100 From: "Daniel P. Berrange" To: Ian Campbell Message-ID: <20120510101043.GH1223@redhat.com> References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> <1336643766.7098.40.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336643766.7098.40.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: "libvir-list@redhat.com" , Daniel De Graaf , Bamvor Jian Zhang , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [libvirt] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: "Daniel P. Berrange" List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 10:56:06AM +0100, Ian Campbell wrote: > On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: > > This patch changes libxl to use the interface in Xen 4.2. It is provided > > as an example, not intended to go in to libvirt as-is since it removes > > all support for libxl from Xen 4.1. It also still has some cruft (extra > > void casts on parameters) and the device model info population is not > > written. It has been tested with simple domain create/destroy. > > --- > > src/libxl/libxl_conf.c | 134 +++++++++------ > > src/libxl/libxl_conf.h | 8 +- > > src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- > > 3 files changed, 326 insertions(+), 246 deletions(-) > > Thanks Daniel, interesting to see. It doesn't seem as invasive as I > expected given the number of changes to libxl's interfaces between 4.1 > and 4.2. > > I suppose it is worth mentioning in this context that we are intending > to maintain the 4.2 libxl API in a stable manner going forward, as > described near the top of: > http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h > > Since libvirt is one of the main reasons we are doing this it would be > useful to check that this actually meets the needs from that side. Having a long term stable API for libxl certainly gets our vote. WRT the use of LIBXL_API_VERSION to control API version. Libvirt generally aims to support all possible API versions, so I expect we would not want to define LIBXL_API_VERSION. Instead the libvirt code would #ifdef various bits according to the libxl version it detects. > That doesn't really help with support 4.1 and 4.2+. A large portion of > the below looks like it would be reasonably easy to abstract away with a > header full of compat defines for naming changes etc, other bits don't > look so simple to deal with. Personally I would prefer to keep support for all 4.x versions, but I'll defer to Suse developers to decide upon this since they are the primary maintainers & users of the libxl driver. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:11:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:11:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQKt-0005Ap-Q6; Thu, 10 May 2012 10:11:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQKs-0005Ak-IR for xen-devel@lists.xen.org; Thu, 10 May 2012 10:11:02 +0000 Received: from [193.109.254.147:8778] by server-9.bemta-14.messagelabs.com id 88/05-05787-4349BAF4; Thu, 10 May 2012 10:11:00 +0000 X-Env-Sender: berrange@redhat.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336644657!862412!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MjA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15264 invoked from network); 10 May 2012 10:10:58 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-7.tower-27.messagelabs.com with SMTP; 10 May 2012 10:10:58 -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 q4AAArXn020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 06:10:53 -0400 Received: from redhat.com (vpn1-4-177.ams2.redhat.com [10.36.4.177]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4AAAhgI031164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 06:10:46 -0400 Date: Thu, 10 May 2012 11:10:43 +0100 From: "Daniel P. Berrange" To: Ian Campbell Message-ID: <20120510101043.GH1223@redhat.com> References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> <1336643766.7098.40.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336643766.7098.40.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: "libvir-list@redhat.com" , Daniel De Graaf , Bamvor Jian Zhang , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [libvirt] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: "Daniel P. Berrange" List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 10:56:06AM +0100, Ian Campbell wrote: > On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: > > This patch changes libxl to use the interface in Xen 4.2. It is provided > > as an example, not intended to go in to libvirt as-is since it removes > > all support for libxl from Xen 4.1. It also still has some cruft (extra > > void casts on parameters) and the device model info population is not > > written. It has been tested with simple domain create/destroy. > > --- > > src/libxl/libxl_conf.c | 134 +++++++++------ > > src/libxl/libxl_conf.h | 8 +- > > src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- > > 3 files changed, 326 insertions(+), 246 deletions(-) > > Thanks Daniel, interesting to see. It doesn't seem as invasive as I > expected given the number of changes to libxl's interfaces between 4.1 > and 4.2. > > I suppose it is worth mentioning in this context that we are intending > to maintain the 4.2 libxl API in a stable manner going forward, as > described near the top of: > http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h > > Since libvirt is one of the main reasons we are doing this it would be > useful to check that this actually meets the needs from that side. Having a long term stable API for libxl certainly gets our vote. WRT the use of LIBXL_API_VERSION to control API version. Libvirt generally aims to support all possible API versions, so I expect we would not want to define LIBXL_API_VERSION. Instead the libvirt code would #ifdef various bits according to the libxl version it detects. > That doesn't really help with support 4.1 and 4.2+. A large portion of > the below looks like it would be reasonably easy to abstract away with a > header full of compat defines for naming changes etc, other bits don't > look so simple to deal with. Personally I would prefer to keep support for all 4.x versions, but I'll defer to Suse developers to decide upon this since they are the primary maintainers & users of the libxl driver. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:17:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQQu-0005Jd-LZ; Thu, 10 May 2012 10:17:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQQs-0005JY-V0 for xen-devel@lists.xen.org; Thu, 10 May 2012 10:17:15 +0000 Received: from [85.158.143.35:15632] by server-1.bemta-4.messagelabs.com id 50/DF-20925-AA59BAF4; Thu, 10 May 2012 10:17:14 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336645028!11587670!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12277 invoked from network); 10 May 2012 10:17:09 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:17:09 -0000 Received: by qcsc20 with SMTP id c20so1198957qcs.32 for ; Thu, 10 May 2012 03:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8A77/6oXC/MfJVn0DmTgpNYzeYIx6RjA95m3coL2dDM=; b=MTMf2xbk/BR2MC5AKjAOefWxeSlrEGiQH2iO17d9/cSGNlJRES19u4TQBUkLSqCQQD ylutj3TlRp1OJo1O5Otu+wDPgpSX4IGRl/ysQre2JIb4KG5QE8joYI5hTuU09UtBA4/G spJwEbQA+EHSoyaIwTFWX4dKIYrIKjNnwZppQ4B7byOlvrYaHa3ivN/L4VLfTS0JzqZe j/6rXaGe9mp1dHK3scPwHAl8aF3Wrml09MEK/aYZrcVCpMPCgT3SiZaMjP5dNWNq/8z+ Izo9h+v3xvUmu4ccUZnCWdnGfda+0iAY4I8FOacur/9rPAsvundnASW3ddicWp1rsFDq Pc+A== MIME-Version: 1.0 Received: by 10.224.212.5 with SMTP id gq5mr10847186qab.1.1336645028384; Thu, 10 May 2012 03:17:08 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Thu, 10 May 2012 03:17:08 -0700 (PDT) In-Reply-To: <4FAA7504.5030103@eu.citrix.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> Date: Thu, 10 May 2012 11:17:08 +0100 X-Google-Sender-Auth: --atiUqCjTmzcbAXuPSV-YV1XPY Message-ID: From: George Dunlap To: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 9, 2012 at 2:45 PM, George Dunlap wrote: > On 09/05/12 12:59, Ian Campbell wrote: >> >> Right, however it is strictly speaking a new feature which is not >> mentioned on the TODO list and has not previously been posted (AFAIK, >> please correct me if not) and we are currently supposed to be in feature >> freeze (and have been for several weeks, if not a month). >> >> IIRC this functionality was mooted when the pci permissive patch was >> being done as something which would be a 4.3 feature. >> We need to decide if we want to make an exception for this new feature >> or not. Although I'm sure this feature is very nice and handy, we've >> lived without it for years and people seem to be able to use the >> existing scheme. And, I realize that at some point all of the deadlines are going to be arbitrary; but I have always felt this is important enough to get an exception. I consider having to muck about with sysfs to be basically a UI bug that really needs fixing. I have a lot of other things that I would like to get done for the 4.2 release; but I thought this was important enough to get priority (above the PoD patch series, for instance). NB I'm not saying that you should accept it because I worked on it; I only bring it up to demonstrate how important I think the feature is. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:17:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQQu-0005Jd-LZ; Thu, 10 May 2012 10:17:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQQs-0005JY-V0 for xen-devel@lists.xen.org; Thu, 10 May 2012 10:17:15 +0000 Received: from [85.158.143.35:15632] by server-1.bemta-4.messagelabs.com id 50/DF-20925-AA59BAF4; Thu, 10 May 2012 10:17:14 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336645028!11587670!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12277 invoked from network); 10 May 2012 10:17:09 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:17:09 -0000 Received: by qcsc20 with SMTP id c20so1198957qcs.32 for ; Thu, 10 May 2012 03:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8A77/6oXC/MfJVn0DmTgpNYzeYIx6RjA95m3coL2dDM=; b=MTMf2xbk/BR2MC5AKjAOefWxeSlrEGiQH2iO17d9/cSGNlJRES19u4TQBUkLSqCQQD ylutj3TlRp1OJo1O5Otu+wDPgpSX4IGRl/ysQre2JIb4KG5QE8joYI5hTuU09UtBA4/G spJwEbQA+EHSoyaIwTFWX4dKIYrIKjNnwZppQ4B7byOlvrYaHa3ivN/L4VLfTS0JzqZe j/6rXaGe9mp1dHK3scPwHAl8aF3Wrml09MEK/aYZrcVCpMPCgT3SiZaMjP5dNWNq/8z+ Izo9h+v3xvUmu4ccUZnCWdnGfda+0iAY4I8FOacur/9rPAsvundnASW3ddicWp1rsFDq Pc+A== MIME-Version: 1.0 Received: by 10.224.212.5 with SMTP id gq5mr10847186qab.1.1336645028384; Thu, 10 May 2012 03:17:08 -0700 (PDT) Received: by 10.229.188.195 with HTTP; Thu, 10 May 2012 03:17:08 -0700 (PDT) In-Reply-To: <4FAA7504.5030103@eu.citrix.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> Date: Thu, 10 May 2012 11:17:08 +0100 X-Google-Sender-Auth: --atiUqCjTmzcbAXuPSV-YV1XPY Message-ID: From: George Dunlap To: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 9, 2012 at 2:45 PM, George Dunlap wrote: > On 09/05/12 12:59, Ian Campbell wrote: >> >> Right, however it is strictly speaking a new feature which is not >> mentioned on the TODO list and has not previously been posted (AFAIK, >> please correct me if not) and we are currently supposed to be in feature >> freeze (and have been for several weeks, if not a month). >> >> IIRC this functionality was mooted when the pci permissive patch was >> being done as something which would be a 4.3 feature. >> We need to decide if we want to make an exception for this new feature >> or not. Although I'm sure this feature is very nice and handy, we've >> lived without it for years and people seem to be able to use the >> existing scheme. And, I realize that at some point all of the deadlines are going to be arbitrary; but I have always felt this is important enough to get an exception. I consider having to muck about with sysfs to be basically a UI bug that really needs fixing. I have a lot of other things that I would like to get done for the 4.2 release; but I thought this was important enough to get priority (above the PoD patch series, for instance). NB I'm not saying that you should accept it because I worked on it; I only bring it up to demonstrate how important I think the feature is. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:20:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQTd-0005PX-6w; Thu, 10 May 2012 10:20:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQTb-0005PP-2o for xen-devel@lists.xen.org; Thu, 10 May 2012 10:20:03 +0000 Received: from [85.158.143.99:10130] by server-1.bemta-4.messagelabs.com id 2B/E3-20925-2569BAF4; Thu, 10 May 2012 10:20:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336645201!20951858!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11412 invoked from network); 10 May 2012 10:20: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; 10 May 2012 10:20:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12401517" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:18:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:18:40 +0100 Message-ID: <1336645119.7098.49.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 11:18:39 +0100 In-Reply-To: <20394.29747.791679.439889@mariner.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "rshriram@cs.ubc.ca" , Anthony Perard , xen-devel , Stefano Stabellini Subject: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote: > I have an enormous patch backlog. Apologies to everyone. I think it would be useful to have another committer to help keep the turnaround time for libxl patches (one of our most actively developed components) down. I've been reviewing many of the patches anyway so how about I volunteer for that role. I'm not actually a libxl MAINTAINER so I suppose I should also nominate myself for that too. We don't seem to have a separate libxl entry in MAINTAINERS, just the top level "tools". We could split it out explicitly (which I think might be a good idea anyway) or just go with: 8<---------------------------------------------------- MAINTAINERS: add myself as a tools maintainer Signed-off-by: Ian Campbell diff -r 8aba3396a61a MAINTAINERS --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 @@ -217,6 +217,7 @@ F: stubdom/ TOOLSTACK M: Ian Jackson M: Stefano Stabellini +M: Ian Campbell S: Supported F: tools/ Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:20:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQTd-0005PX-6w; Thu, 10 May 2012 10:20:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQTb-0005PP-2o for xen-devel@lists.xen.org; Thu, 10 May 2012 10:20:03 +0000 Received: from [85.158.143.99:10130] by server-1.bemta-4.messagelabs.com id 2B/E3-20925-2569BAF4; Thu, 10 May 2012 10:20:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336645201!20951858!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11412 invoked from network); 10 May 2012 10:20: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; 10 May 2012 10:20:01 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12401517" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:18:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:18:40 +0100 Message-ID: <1336645119.7098.49.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 11:18:39 +0100 In-Reply-To: <20394.29747.791679.439889@mariner.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "rshriram@cs.ubc.ca" , Anthony Perard , xen-devel , Stefano Stabellini Subject: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote: > I have an enormous patch backlog. Apologies to everyone. I think it would be useful to have another committer to help keep the turnaround time for libxl patches (one of our most actively developed components) down. I've been reviewing many of the patches anyway so how about I volunteer for that role. I'm not actually a libxl MAINTAINER so I suppose I should also nominate myself for that too. We don't seem to have a separate libxl entry in MAINTAINERS, just the top level "tools". We could split it out explicitly (which I think might be a good idea anyway) or just go with: 8<---------------------------------------------------- MAINTAINERS: add myself as a tools maintainer Signed-off-by: Ian Campbell diff -r 8aba3396a61a MAINTAINERS --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 @@ -217,6 +217,7 @@ F: stubdom/ TOOLSTACK M: Ian Jackson M: Stefano Stabellini +M: Ian Campbell S: Supported F: tools/ Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:38:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:38:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQke-0005e0-Sc; Thu, 10 May 2012 10:37:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQke-0005dv-4z for xen-devel@lists.xen.org; Thu, 10 May 2012 10:37:40 +0000 Received: from [193.109.254.147:58449] by server-1.bemta-14.messagelabs.com id 43/6B-29372-27A9BAF4; Thu, 10 May 2012 10:37:38 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1336646257!8531585!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1608 invoked from network); 10 May 2012 10:37:38 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 10:37:38 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSQka-000KUy-TE; Thu, 10 May 2012 10:37:36 +0000 Date: Thu, 10 May 2012 11:37:36 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20120510103736.GA73773@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote: > Add a new xc function to destroy the shadow pages table for a given > guest from userspace. Looks OK, but what will it be used for? There might be some more appropriate semantics at the hypercall interface than exposing the shadow internals as such. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:38:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:38:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQke-0005e0-Sc; Thu, 10 May 2012 10:37:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQke-0005dv-4z for xen-devel@lists.xen.org; Thu, 10 May 2012 10:37:40 +0000 Received: from [193.109.254.147:58449] by server-1.bemta-14.messagelabs.com id 43/6B-29372-27A9BAF4; Thu, 10 May 2012 10:37:38 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1336646257!8531585!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1608 invoked from network); 10 May 2012 10:37:38 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 10:37:38 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSQka-000KUy-TE; Thu, 10 May 2012 10:37:36 +0000 Date: Thu, 10 May 2012 11:37:36 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20120510103736.GA73773@ocelot.phlegethon.org> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote: > Add a new xc function to destroy the shadow pages table for a given > guest from userspace. Looks OK, but what will it be used for? There might be some more appropriate semantics at the hypercall interface than exposing the shadow internals as such. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:39:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQm2-0005iv-VC; Thu, 10 May 2012 10:39:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQm0-0005ie-Ta for xen-devel@lists.xen.org; Thu, 10 May 2012 10:39:05 +0000 Received: from [85.158.139.83:4602] by server-10.bemta-5.messagelabs.com id CD/9B-08260-7CA9BAF4; Thu, 10 May 2012 10:39:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336646343!27641666!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25854 invoked from network); 10 May 2012 10:39:03 -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; 10 May 2012 10:39:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402088" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:38:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:38:41 +0100 Message-ID: <1336646320.7098.62.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:38:40 +0100 In-Reply-To: References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: > On Wed, May 9, 2012 at 2:45 PM, George Dunlap > wrote: > > On 09/05/12 12:59, Ian Campbell wrote: > >> > >> Right, however it is strictly speaking a new feature which is not > >> mentioned on the TODO list and has not previously been posted (AFAIK, > >> please correct me if not) and we are currently supposed to be in feature > >> freeze (and have been for several weeks, if not a month). > >> > >> IIRC this functionality was mooted when the pci permissive patch was > >> being done as something which would be a 4.3 feature. > >> We need to decide if we want to make an exception for this new feature > >> or not. Although I'm sure this feature is very nice and handy, we've > >> lived without it for years and people seem to be able to use the > >> existing scheme. > > And, I realize that at some point all of the deadlines are going to be > arbitrary; but I have always felt this is important enough to get an > exception. I consider having to muck about with sysfs to be basically > a UI bug that really needs fixing. I have a lot of other things that > I would like to get done for the 4.2 release; but I thought this was > important enough to get priority (above the PoD patch series, for > instance). NB I'm not saying that you should accept it because I > worked on it; I only bring it up to demonstrate how important I think > the feature is. OK, given that the code is basically self contained and shouldn't effect anything unless a user "opts-in" to using it I think you've convinced me. Lets take this (I'll review the actual patches shortly). BTW, IMHO it is preferable for actual deployments to use the kernel command line options to hide devices rather than either this feature or sysfs. Fully hiding the device from dom0 drivers generally seems like it is always better. That way the first driver to try and touch the hardware is the one inside the domU. This avoids issues with dom0 drivers setting stuff up but not tearing it down in a way that domU can cope with and makes the use of hardware which doesn't support FLR more reliable etc. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:39:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQm2-0005iv-VC; Thu, 10 May 2012 10:39:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQm0-0005ie-Ta for xen-devel@lists.xen.org; Thu, 10 May 2012 10:39:05 +0000 Received: from [85.158.139.83:4602] by server-10.bemta-5.messagelabs.com id CD/9B-08260-7CA9BAF4; Thu, 10 May 2012 10:39:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336646343!27641666!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25854 invoked from network); 10 May 2012 10:39:03 -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; 10 May 2012 10:39:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402088" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:38:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:38:41 +0100 Message-ID: <1336646320.7098.62.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:38:40 +0100 In-Reply-To: References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: > On Wed, May 9, 2012 at 2:45 PM, George Dunlap > wrote: > > On 09/05/12 12:59, Ian Campbell wrote: > >> > >> Right, however it is strictly speaking a new feature which is not > >> mentioned on the TODO list and has not previously been posted (AFAIK, > >> please correct me if not) and we are currently supposed to be in feature > >> freeze (and have been for several weeks, if not a month). > >> > >> IIRC this functionality was mooted when the pci permissive patch was > >> being done as something which would be a 4.3 feature. > >> We need to decide if we want to make an exception for this new feature > >> or not. Although I'm sure this feature is very nice and handy, we've > >> lived without it for years and people seem to be able to use the > >> existing scheme. > > And, I realize that at some point all of the deadlines are going to be > arbitrary; but I have always felt this is important enough to get an > exception. I consider having to muck about with sysfs to be basically > a UI bug that really needs fixing. I have a lot of other things that > I would like to get done for the 4.2 release; but I thought this was > important enough to get priority (above the PoD patch series, for > instance). NB I'm not saying that you should accept it because I > worked on it; I only bring it up to demonstrate how important I think > the feature is. OK, given that the code is basically self contained and shouldn't effect anything unless a user "opts-in" to using it I think you've convinced me. Lets take this (I'll review the actual patches shortly). BTW, IMHO it is preferable for actual deployments to use the kernel command line options to hide devices rather than either this feature or sysfs. Fully hiding the device from dom0 drivers generally seems like it is always better. That way the first driver to try and touch the hardware is the one inside the domU. This avoids issues with dom0 drivers setting stuff up but not tearing it down in a way that domU can cope with and makes the use of hardware which doesn't support FLR more reliable etc. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:41:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSQnt-0005v8-Ie; Thu, 10 May 2012 10:41:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQnr-0005up-M7 for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:40:59 +0000 Received: from [85.158.143.99:31273] by server-1.bemta-4.messagelabs.com id AD/B6-20925-A3B9BAF4; Thu, 10 May 2012 10:40:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336646456!16141391!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8391 invoked from network); 10 May 2012 10:40:57 -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 May 2012 10:40:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402142" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:40: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, 10 May 2012 11:40:55 +0100 Message-ID: <1336646454.7098.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:40:54 +0100 In-Reply-To: <0772f1d07d1c0b91fc37.1336559321@kodo2> References: <0772f1d07d1c0b91fc37.1336559321@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 4] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > This functionality will be used several times in subsequent patches. > > Signed-off-by: George Dunlap Acked-by: Ian Campbell > diff -r d5268710a5ca -r 0772f1d07d1c tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Fri May 04 10:46:23 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 > @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi > return 0; > } > > +/* Write the standard BDF into the sysfs path given by sysfs_path. */ > +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, > + libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc, fd; > + char *buf; > + > + fd = open(sysfs_path, O_WRONLY); > + if (fd < 0) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + sysfs_path); > + return ERROR_FAIL; > + } > + > + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, > + pcidev->dev, pcidev->func); > + rc = write(fd, buf, strlen(buf)); > + /* Annoying to have two if's, but we need the errno */ > + if (rc < 0) > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "write to %s returned %d", sysfs_path, rc); > + close(fd); > + > + if (rc < 0) > + return ERROR_FAIL; > + > + return 0; > +} > + > libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) > { > GC_INIT(ctx); > @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin > > /* Don't restrict writes to the PCI config space from this VM */ > if (pcidev->permissive) { > - int fd; > - char *buf; > - > - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); > - fd = open(sysfs_path, O_WRONLY); > - if (fd < 0) { > - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > - sysfs_path); > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Setting permissive for device"); > return ERROR_FAIL; > } > - > - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, > - pcidev->dev, pcidev->func); > - rc = write(fd, buf, strlen(buf)); > - /* Annoying to have two if's, but we need the errno */ > - if (rc < 0) > - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > - "write to %s returned %d", sysfs_path, rc); > - close(fd); > - if (rc < 0) > - return ERROR_FAIL; > } > break; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:41:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSQnt-0005v8-Ie; Thu, 10 May 2012 10:41:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQnr-0005up-M7 for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:40:59 +0000 Received: from [85.158.143.99:31273] by server-1.bemta-4.messagelabs.com id AD/B6-20925-A3B9BAF4; Thu, 10 May 2012 10:40:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336646456!16141391!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8391 invoked from network); 10 May 2012 10:40:57 -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 May 2012 10:40:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402142" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:40: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, 10 May 2012 11:40:55 +0100 Message-ID: <1336646454.7098.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:40:54 +0100 In-Reply-To: <0772f1d07d1c0b91fc37.1336559321@kodo2> References: <0772f1d07d1c0b91fc37.1336559321@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 4] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > This functionality will be used several times in subsequent patches. > > Signed-off-by: George Dunlap Acked-by: Ian Campbell > diff -r d5268710a5ca -r 0772f1d07d1c tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Fri May 04 10:46:23 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 > @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi > return 0; > } > > +/* Write the standard BDF into the sysfs path given by sysfs_path. */ > +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, > + libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc, fd; > + char *buf; > + > + fd = open(sysfs_path, O_WRONLY); > + if (fd < 0) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + sysfs_path); > + return ERROR_FAIL; > + } > + > + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, > + pcidev->dev, pcidev->func); > + rc = write(fd, buf, strlen(buf)); > + /* Annoying to have two if's, but we need the errno */ > + if (rc < 0) > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "write to %s returned %d", sysfs_path, rc); > + close(fd); > + > + if (rc < 0) > + return ERROR_FAIL; > + > + return 0; > +} > + > libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) > { > GC_INIT(ctx); > @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin > > /* Don't restrict writes to the PCI config space from this VM */ > if (pcidev->permissive) { > - int fd; > - char *buf; > - > - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); > - fd = open(sysfs_path, O_WRONLY); > - if (fd < 0) { > - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > - sysfs_path); > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Setting permissive for device"); > return ERROR_FAIL; > } > - > - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, > - pcidev->dev, pcidev->func); > - rc = write(fd, buf, strlen(buf)); > - /* Annoying to have two if's, but we need the errno */ > - if (rc < 0) > - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > - "write to %s returned %d", sysfs_path, rc); > - close(fd); > - if (rc < 0) > - return ERROR_FAIL; > } > break; > } > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:44:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:44:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQr8-0006EN-6f; Thu, 10 May 2012 10:44:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQr6-0006ED-QT for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:44:21 +0000 Received: from [193.109.254.147:16606] by server-11.bemta-14.messagelabs.com id 2B/A8-05858-30C9BAF4; Thu, 10 May 2012 10:44:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336646650!3406954!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9902 invoked from network); 10 May 2012 10:44:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:44:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402204" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:43:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:43:41 +0100 Message-ID: <1336646620.7098.66.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:43:40 +0100 In-Reply-To: <5b5070d487d948ff654c.1336559322@kodo2> References: <5b5070d487d948ff654c.1336559322@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > ...to prepare for a consistent "pci_assignable_*" naming scheme. > > Also move the man page entry into the PCI PASS-THROUGH section, rather > than the XEN HOST section. > > No functional changes. > > Signed-off-by: George Dunlap Acked-by: Ian Campbell (moving the definition of pcilist_assignable et al seems superfluous, but I suppose it serves some purpose later in the series and the function is small enough to review the changes + code motion by eye) > > diff -r 0772f1d07d1c -r 5b5070d487d9 docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Tue May 08 17:18:31 2012 +0100 > +++ b/docs/man/xl.pod.1 Wed May 09 11:21:19 2012 +0100 > @@ -687,13 +687,6 @@ explanatory. > > Prints the current uptime of the domains running. > > -=item B > - > -List all the assignable PCI devices. > -These are devices in the system which are configured to be > -available for passthrough and are bound to a suitable PCI > -backend driver in domain 0 rather than a real driver. > - > =back > > =head1 SCHEDULER SUBCOMMANDS > @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do > > =over 4 > > +=item B > + > +List all the assignable PCI devices. > +These are devices in the system which are configured to be > +available for passthrough and are bound to a suitable PCI > +backend driver in domain 0 rather than a real driver. > + > =item B I I > > Hot-plug a new pass-through pci device to the specified domain. > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl.h > --- a/tools/libxl/libxl.h Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 > @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( > * could be assigned to a domain (i.e. are bound to the backend > * driver) but are not currently. > */ > -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); > +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); > > /* CPUID handling */ > int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 > @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc > return 0; > } > > -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) > +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) > { > GC_INIT(ctx); > libxl_device_pci *pcidevs = NULL, *new, *assigned; > @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl > libxl_device_pci *pcidevs; > int num, i; > > - pcidevs = libxl_device_pci_list_assignable(ctx, &num); > + pcidevs = libxl_device_pci_assignable_list(ctx, &num); > for (i = 0; i < num; i++) { > if (pcidevs[i].domain == pcidev->domain && > pcidevs[i].bus == pcidev->bus && > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl.h > --- a/tools/libxl/xl.h Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl.h Wed May 09 11:21:19 2012 +0100 > @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv > int main_console(int argc, char **argv); > int main_vncviewer(int argc, char **argv); > int main_pcilist(int argc, char **argv); > -int main_pcilist_assignable(int argc, char **argv); > int main_pcidetach(int argc, char **argv); > int main_pciattach(int argc, char **argv); > +int main_pciassignable_list(int argc, char **argv); > int main_restore(int argc, char **argv); > int main_migrate_receive(int argc, char **argv); > int main_save(int argc, char **argv); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:19 2012 +0100 > @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv > return 0; > } > > -static void pcilist_assignable(void) > -{ > - libxl_device_pci *pcidevs; > - int num, i; > - > - pcidevs = libxl_device_pci_list_assignable(ctx, &num); > - > - if ( pcidevs == NULL ) > - return; > - for (i = 0; i < num; i++) { > - printf("%04x:%02x:%02x.%01x\n", > - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); > - libxl_device_pci_dispose(&pcidevs[i]); > - } > - free(pcidevs); > -} > - > -int main_pcilist_assignable(int argc, char **argv) > -{ > - int opt; > - > - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) > - return opt; > - > - pcilist_assignable(); > - return 0; > -} > - > static void pcilist(const char *dom) > { > libxl_device_pci *pcidevs; > @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv > return 0; > } > > +static void pciassignable_list(void) > +{ > + libxl_device_pci *pcidevs; > + int num, i; > + > + pcidevs = libxl_device_pci_assignable_list(ctx, &num); > + > + if ( pcidevs == NULL ) > + return; > + for (i = 0; i < num; i++) { > + printf("%04x:%02x:%02x.%01x\n", > + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); > + libxl_device_pci_dispose(&pcidevs[i]); > + } > + free(pcidevs); > +} > + > +int main_pciassignable_list(int argc, char **argv) > +{ > + int opt; > + > + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) > + return opt; > + > + pciassignable_list(); > + return 0; > +} > + > static void pause_domain(const char *p) > { > find_domain(p); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdtable.c > --- a/tools/libxl/xl_cmdtable.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:21:19 2012 +0100 > @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { > "List pass-through pci devices for a domain", > "", > }, > - { "pci-list-assignable-devices", > - &main_pcilist_assignable, 0, > + { "pci-assignable-list", > + &main_pciassignable_list, 0, > "List all the assignable pci devices", > "", > }, > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/python/xen/lowlevel/xl/xl.c > --- a/tools/python/xen/lowlevel/xl/xl.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/python/xen/lowlevel/xl/xl.c Wed May 09 11:21:19 2012 +0100 > @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject > return (PyObject *)pci; > } > > -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) > +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) > { > libxl_device_pci *dev; > PyObject *list; > int nr_dev, i; > > - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); > + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); > if ( dev == NULL ) { > PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); > return NULL; > @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { > "Parse pass-through PCI device spec (BDF)"}, > {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, > "List PCI devices assigned to a domain"}, > - {"device_pci_list_assignable", > - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, > + {"device_pci_assignable_list", > + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, > "List assignable PCI devices"}, > { NULL, NULL, 0, NULL } > }; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:44:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:44:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQr8-0006EN-6f; Thu, 10 May 2012 10:44:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQr6-0006ED-QT for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:44:21 +0000 Received: from [193.109.254.147:16606] by server-11.bemta-14.messagelabs.com id 2B/A8-05858-30C9BAF4; Thu, 10 May 2012 10:44:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336646650!3406954!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9902 invoked from network); 10 May 2012 10:44:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:44:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402204" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:43:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:43:41 +0100 Message-ID: <1336646620.7098.66.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 11:43:40 +0100 In-Reply-To: <5b5070d487d948ff654c.1336559322@kodo2> References: <5b5070d487d948ff654c.1336559322@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > ...to prepare for a consistent "pci_assignable_*" naming scheme. > > Also move the man page entry into the PCI PASS-THROUGH section, rather > than the XEN HOST section. > > No functional changes. > > Signed-off-by: George Dunlap Acked-by: Ian Campbell (moving the definition of pcilist_assignable et al seems superfluous, but I suppose it serves some purpose later in the series and the function is small enough to review the changes + code motion by eye) > > diff -r 0772f1d07d1c -r 5b5070d487d9 docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Tue May 08 17:18:31 2012 +0100 > +++ b/docs/man/xl.pod.1 Wed May 09 11:21:19 2012 +0100 > @@ -687,13 +687,6 @@ explanatory. > > Prints the current uptime of the domains running. > > -=item B > - > -List all the assignable PCI devices. > -These are devices in the system which are configured to be > -available for passthrough and are bound to a suitable PCI > -backend driver in domain 0 rather than a real driver. > - > =back > > =head1 SCHEDULER SUBCOMMANDS > @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do > > =over 4 > > +=item B > + > +List all the assignable PCI devices. > +These are devices in the system which are configured to be > +available for passthrough and are bound to a suitable PCI > +backend driver in domain 0 rather than a real driver. > + > =item B I I > > Hot-plug a new pass-through pci device to the specified domain. > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl.h > --- a/tools/libxl/libxl.h Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 > @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( > * could be assigned to a domain (i.e. are bound to the backend > * driver) but are not currently. > */ > -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); > +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); > > /* CPUID handling */ > int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 > @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc > return 0; > } > > -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) > +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) > { > GC_INIT(ctx); > libxl_device_pci *pcidevs = NULL, *new, *assigned; > @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl > libxl_device_pci *pcidevs; > int num, i; > > - pcidevs = libxl_device_pci_list_assignable(ctx, &num); > + pcidevs = libxl_device_pci_assignable_list(ctx, &num); > for (i = 0; i < num; i++) { > if (pcidevs[i].domain == pcidev->domain && > pcidevs[i].bus == pcidev->bus && > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl.h > --- a/tools/libxl/xl.h Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl.h Wed May 09 11:21:19 2012 +0100 > @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv > int main_console(int argc, char **argv); > int main_vncviewer(int argc, char **argv); > int main_pcilist(int argc, char **argv); > -int main_pcilist_assignable(int argc, char **argv); > int main_pcidetach(int argc, char **argv); > int main_pciattach(int argc, char **argv); > +int main_pciassignable_list(int argc, char **argv); > int main_restore(int argc, char **argv); > int main_migrate_receive(int argc, char **argv); > int main_save(int argc, char **argv); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:19 2012 +0100 > @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv > return 0; > } > > -static void pcilist_assignable(void) > -{ > - libxl_device_pci *pcidevs; > - int num, i; > - > - pcidevs = libxl_device_pci_list_assignable(ctx, &num); > - > - if ( pcidevs == NULL ) > - return; > - for (i = 0; i < num; i++) { > - printf("%04x:%02x:%02x.%01x\n", > - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); > - libxl_device_pci_dispose(&pcidevs[i]); > - } > - free(pcidevs); > -} > - > -int main_pcilist_assignable(int argc, char **argv) > -{ > - int opt; > - > - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) > - return opt; > - > - pcilist_assignable(); > - return 0; > -} > - > static void pcilist(const char *dom) > { > libxl_device_pci *pcidevs; > @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv > return 0; > } > > +static void pciassignable_list(void) > +{ > + libxl_device_pci *pcidevs; > + int num, i; > + > + pcidevs = libxl_device_pci_assignable_list(ctx, &num); > + > + if ( pcidevs == NULL ) > + return; > + for (i = 0; i < num; i++) { > + printf("%04x:%02x:%02x.%01x\n", > + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); > + libxl_device_pci_dispose(&pcidevs[i]); > + } > + free(pcidevs); > +} > + > +int main_pciassignable_list(int argc, char **argv) > +{ > + int opt; > + > + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) > + return opt; > + > + pciassignable_list(); > + return 0; > +} > + > static void pause_domain(const char *p) > { > find_domain(p); > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/libxl/xl_cmdtable.c > --- a/tools/libxl/xl_cmdtable.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:21:19 2012 +0100 > @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { > "List pass-through pci devices for a domain", > "", > }, > - { "pci-list-assignable-devices", > - &main_pcilist_assignable, 0, > + { "pci-assignable-list", > + &main_pciassignable_list, 0, > "List all the assignable pci devices", > "", > }, > diff -r 0772f1d07d1c -r 5b5070d487d9 tools/python/xen/lowlevel/xl/xl.c > --- a/tools/python/xen/lowlevel/xl/xl.c Tue May 08 17:18:31 2012 +0100 > +++ b/tools/python/xen/lowlevel/xl/xl.c Wed May 09 11:21:19 2012 +0100 > @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject > return (PyObject *)pci; > } > > -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) > +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) > { > libxl_device_pci *dev; > PyObject *list; > int nr_dev, i; > > - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); > + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); > if ( dev == NULL ) { > PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); > return NULL; > @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { > "Parse pass-through PCI device spec (BDF)"}, > {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, > "List PCI devices assigned to a domain"}, > - {"device_pci_list_assignable", > - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, > + {"device_pci_assignable_list", > + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, > "List assignable PCI devices"}, > { NULL, NULL, 0, NULL } > }; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:46:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:46:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQtG-0006OC-T1; Thu, 10 May 2012 10:46:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQtF-0006O4-HG for xen-devel@lists.xen.org; Thu, 10 May 2012 10:46:33 +0000 Received: from [85.158.143.99:10299] by server-3.bemta-4.messagelabs.com id 78/71-05853-88C9BAF4; Thu, 10 May 2012 10:46:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336646791!23970012!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12486 invoked from network); 10 May 2012 10:46:32 -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; 10 May 2012 10:46:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:46:30 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:46:30 +0100 Date: Thu, 10 May 2012 11:46:15 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1336645119.7098.49.camel@zakaz.uk.xensource.com> Message-ID: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> <1336645119.7098.49.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "rshriram@cs.ubc.ca" , Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Ian Campbell wrote: > On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote: > > I have an enormous patch backlog. Apologies to everyone. > > I think it would be useful to have another committer to help keep the > turnaround time for libxl patches (one of our most actively developed > components) down. > > I've been reviewing many of the patches anyway so how about I volunteer > for that role. > > I'm not actually a libxl MAINTAINER so I suppose I should also nominate > myself for that too. We don't seem to have a separate libxl entry in > MAINTAINERS, just the top level "tools". We could split it out > explicitly (which I think might be a good idea anyway) or just go with: > > 8<---------------------------------------------------- > > MAINTAINERS: add myself as a tools maintainer > > Signed-off-by: Ian Campbell > > diff -r 8aba3396a61a MAINTAINERS > --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 > +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 > @@ -217,6 +217,7 @@ F: stubdom/ > TOOLSTACK > M: Ian Jackson > M: Stefano Stabellini > +M: Ian Campbell > S: Supported > F: tools/ > Acked-by: Stefano Stabellini _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:46:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:46:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQtG-0006OC-T1; Thu, 10 May 2012 10:46:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQtF-0006O4-HG for xen-devel@lists.xen.org; Thu, 10 May 2012 10:46:33 +0000 Received: from [85.158.143.99:10299] by server-3.bemta-4.messagelabs.com id 78/71-05853-88C9BAF4; Thu, 10 May 2012 10:46:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336646791!23970012!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12486 invoked from network); 10 May 2012 10:46:32 -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; 10 May 2012 10:46:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12402322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:46:30 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:46:30 +0100 Date: Thu, 10 May 2012 11:46:15 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Ian Campbell In-Reply-To: <1336645119.7098.49.camel@zakaz.uk.xensource.com> Message-ID: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> <1336645119.7098.49.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: "rshriram@cs.ubc.ca" , Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Ian Campbell wrote: > On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote: > > I have an enormous patch backlog. Apologies to everyone. > > I think it would be useful to have another committer to help keep the > turnaround time for libxl patches (one of our most actively developed > components) down. > > I've been reviewing many of the patches anyway so how about I volunteer > for that role. > > I'm not actually a libxl MAINTAINER so I suppose I should also nominate > myself for that too. We don't seem to have a separate libxl entry in > MAINTAINERS, just the top level "tools". We could split it out > explicitly (which I think might be a good idea anyway) or just go with: > > 8<---------------------------------------------------- > > MAINTAINERS: add myself as a tools maintainer > > Signed-off-by: Ian Campbell > > diff -r 8aba3396a61a MAINTAINERS > --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 > +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 > @@ -217,6 +217,7 @@ F: stubdom/ > TOOLSTACK > M: Ian Jackson > M: Stefano Stabellini > +M: Ian Campbell > S: Supported > F: tools/ > Acked-by: Stefano Stabellini _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:49:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQwC-0006YX-F3; Thu, 10 May 2012 10:49:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQwA-0006YG-KS for xen-devel@lists.xen.org; Thu, 10 May 2012 10:49:34 +0000 Received: from [85.158.138.51:12998] by server-4.bemta-3.messagelabs.com id 28/5E-15341-B3D9BAF4; Thu, 10 May 2012 10:49:31 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336646970!17391873!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13129 invoked from network); 10 May 2012 10:49:31 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:49:31 -0000 Received: by vbbfn1 with SMTP id fn1so309898vbb.32 for ; Thu, 10 May 2012 03:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ogiNfnBZyB+XUfnjdqcSJQDc2UhYdYZN6Y4lqtJppgY=; b=iOl/oOtyt2MgAriUC70TrN7qnxU1xG6gBgHdlXMeDNe+ghploYMxU2TSSpICdba+0Y LvOM0CD1TW6o5Me7E24hLCl9AuvJ0yzTr+eOcF3Tz8qDwnV2la3wpuXFof4sAXa2q+cW BeCDRn9Ij3u24EsCjs8Brg4szthsLmqHNVwNZdkzdIv3qBbMysfZnJzeiABYdgIZHd7u 0q+AfEESP6vNk46TyJNMEcAezmsAJqbzoc5HHXzrFQHD0sdGqKmPnEnaxEjZXOk754dU UStpegYp+SK7G7Ue9+feD43rRIRvEUqTms27q8J8qCY54wP73Dn+GuMPoWOYnOZrlZGe FcWA== Received: by 10.52.21.51 with SMTP id s19mr1861652vde.35.1336646969854; Thu, 10 May 2012 03:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 03:49:09 -0700 (PDT) In-Reply-To: <20120510103736.GA73773@ocelot.phlegethon.org> References: <20120510103736.GA73773@ocelot.phlegethon.org> From: Jean Guyader Date: Thu, 10 May 2012 11:49:09 +0100 Message-ID: To: Tim Deegan Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10 May 2012 11:37, Tim Deegan wrote: > At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote: >> Add a new xc function to destroy the shadow pages table for a given >> guest from userspace. > > Looks OK, but what will it be used for? =A0There might be some more > appropriate semantics at the hypercall interface than exposing the > shadow internals as such. > It's related to the use of hvm_set_mem_pinned_cacheattr to set the default caching policy when a guest starts to use a given gfn. If this function is called after the guest has mapped the gfn it won't have any affect. The easy and surely not the best way to fix this is to destroy all the shadow page tables for this domain. Maybe the ideal thing to do would be to make the cacheattr code aware of the shadow page table and only clear the relevant set of shadow pages. Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:49:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10: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 ) id 1SSQwC-0006YX-F3; Thu, 10 May 2012 10:49:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSQwA-0006YG-KS for xen-devel@lists.xen.org; Thu, 10 May 2012 10:49:34 +0000 Received: from [85.158.138.51:12998] by server-4.bemta-3.messagelabs.com id 28/5E-15341-B3D9BAF4; Thu, 10 May 2012 10:49:31 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336646970!17391873!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13129 invoked from network); 10 May 2012 10:49:31 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:49:31 -0000 Received: by vbbfn1 with SMTP id fn1so309898vbb.32 for ; Thu, 10 May 2012 03:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ogiNfnBZyB+XUfnjdqcSJQDc2UhYdYZN6Y4lqtJppgY=; b=iOl/oOtyt2MgAriUC70TrN7qnxU1xG6gBgHdlXMeDNe+ghploYMxU2TSSpICdba+0Y LvOM0CD1TW6o5Me7E24hLCl9AuvJ0yzTr+eOcF3Tz8qDwnV2la3wpuXFof4sAXa2q+cW BeCDRn9Ij3u24EsCjs8Brg4szthsLmqHNVwNZdkzdIv3qBbMysfZnJzeiABYdgIZHd7u 0q+AfEESP6vNk46TyJNMEcAezmsAJqbzoc5HHXzrFQHD0sdGqKmPnEnaxEjZXOk754dU UStpegYp+SK7G7Ue9+feD43rRIRvEUqTms27q8J8qCY54wP73Dn+GuMPoWOYnOZrlZGe FcWA== Received: by 10.52.21.51 with SMTP id s19mr1861652vde.35.1336646969854; Thu, 10 May 2012 03:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 03:49:09 -0700 (PDT) In-Reply-To: <20120510103736.GA73773@ocelot.phlegethon.org> References: <20120510103736.GA73773@ocelot.phlegethon.org> From: Jean Guyader Date: Thu, 10 May 2012 11:49:09 +0100 Message-ID: To: Tim Deegan Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10 May 2012 11:37, Tim Deegan wrote: > At 10:57 +0100 on 10 May (1336647456), Jean Guyader wrote: >> Add a new xc function to destroy the shadow pages table for a given >> guest from userspace. > > Looks OK, but what will it be used for? =A0There might be some more > appropriate semantics at the hypercall interface than exposing the > shadow internals as such. > It's related to the use of hvm_set_mem_pinned_cacheattr to set the default caching policy when a guest starts to use a given gfn. If this function is called after the guest has mapped the gfn it won't have any affect. The easy and surely not the best way to fix this is to destroy all the shadow page tables for this domain. Maybe the ideal thing to do would be to make the cacheattr code aware of the shadow page table and only clear the relevant set of shadow pages. Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:55:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:55:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR1P-0006ms-7A; Thu, 10 May 2012 10:54:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR1N-0006mk-JP for xen-devel@lists.xen.org; Thu, 10 May 2012 10:54:58 +0000 Received: from [85.158.139.83:64200] by server-5.bemta-5.messagelabs.com id 95/8C-13566-08E9BAF4; Thu, 10 May 2012 10:54:56 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336647293!27678582!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21257 invoked from network); 10 May 2012 10:54:54 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:54:54 -0000 Received: by vbbfn1 with SMTP id fn1so315927vbb.32 for ; Thu, 10 May 2012 03:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lcn6rP/C4B2Ij7YyzURIbMS/EiayEwHXqdT/IlWe0/o=; b=xmm5K4Qx+LouxvB430NobhxIpB2HD5MIkcqwQGOJp42m04g2AVvKU96V2VM1EaFwnr tTMmFGLgucI50qWCgHH4tCsKBuAMeGBoG2BsivHQfpRHoGuiXBFAAhJ6ZzfbVTw9CdwR Zfq8zK5xM7tEFKG5FmkUPVVpU6ctqgSDci4XLlFDfFm+9h6SiYRs8dU/BFgJyxovkOwc EnNgTjahKSphueKgY/wg+8FRIJcIUZDr6ZYkHxT4X+6ZzusLYFnaO4b0NQH0HsKN9AKt mTVSL5MyPkm87X3cjYBhqjm0RjTKGKLwO+mho7BXjFeIOkLcUxviOLGavoNKRv/VTuPq ktUw== Received: by 10.52.72.137 with SMTP id d9mr1795300vdv.122.1336647293146; Thu, 10 May 2012 03:54:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 03:54:32 -0700 (PDT) In-Reply-To: <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> <20120117162414.GA25281@spongy.cam.xci-test.com> <20120131145142.GB23556@spongy.cam.xci-test.com> From: Jean Guyader Date: Thu, 10 May 2012 11:54:32 +0100 Message-ID: To: xen-devel@lists.xen.org Cc: Ian Jackson , "konrad@darnok.org" , "allen.m.kay@intel.com" , Jean Guyader , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 31 January 2012 14:51, Jean Guyader wrote: > 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 >> > > > 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 >> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 >> > > > >> Author: Jean Guyader >> > > > >> 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 On 31 January 2012 14:51, Jean Guyader wrote: > > 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 > > > > > 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 > > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 > > > > > >> Author: Jean Guyader > > > > > >> 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? > Hi Ian, I was going through my email and it seems that this patch didn't make it into qemu-xen-unstable. Signed-off-by: Jean Guyader Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:55:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:55:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR1P-0006ms-7A; Thu, 10 May 2012 10:54:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR1N-0006mk-JP for xen-devel@lists.xen.org; Thu, 10 May 2012 10:54:58 +0000 Received: from [85.158.139.83:64200] by server-5.bemta-5.messagelabs.com id 95/8C-13566-08E9BAF4; Thu, 10 May 2012 10:54:56 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336647293!27678582!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21257 invoked from network); 10 May 2012 10:54:54 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:54:54 -0000 Received: by vbbfn1 with SMTP id fn1so315927vbb.32 for ; Thu, 10 May 2012 03:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lcn6rP/C4B2Ij7YyzURIbMS/EiayEwHXqdT/IlWe0/o=; b=xmm5K4Qx+LouxvB430NobhxIpB2HD5MIkcqwQGOJp42m04g2AVvKU96V2VM1EaFwnr tTMmFGLgucI50qWCgHH4tCsKBuAMeGBoG2BsivHQfpRHoGuiXBFAAhJ6ZzfbVTw9CdwR Zfq8zK5xM7tEFKG5FmkUPVVpU6ctqgSDci4XLlFDfFm+9h6SiYRs8dU/BFgJyxovkOwc EnNgTjahKSphueKgY/wg+8FRIJcIUZDr6ZYkHxT4X+6ZzusLYFnaO4b0NQH0HsKN9AKt mTVSL5MyPkm87X3cjYBhqjm0RjTKGKLwO+mho7BXjFeIOkLcUxviOLGavoNKRv/VTuPq ktUw== Received: by 10.52.72.137 with SMTP id d9mr1795300vdv.122.1336647293146; Thu, 10 May 2012 03:54:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 03:54:32 -0700 (PDT) In-Reply-To: <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> <20120117162414.GA25281@spongy.cam.xci-test.com> <20120131145142.GB23556@spongy.cam.xci-test.com> From: Jean Guyader Date: Thu, 10 May 2012 11:54:32 +0100 Message-ID: To: xen-devel@lists.xen.org Cc: Ian Jackson , "konrad@darnok.org" , "allen.m.kay@intel.com" , Jean Guyader , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 31 January 2012 14:51, Jean Guyader wrote: > 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 >> > > > 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 >> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 >> > > > >> Author: Jean Guyader >> > > > >> 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 On 31 January 2012 14:51, Jean Guyader wrote: > > 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 > > > > > 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 > > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3 > > > > > >> Author: Jean Guyader > > > > > >> 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? > Hi Ian, I was going through my email and it seems that this patch didn't make it into qemu-xen-unstable. Signed-off-by: Jean Guyader Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:56:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:56:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR2b-0006rp-M8; Thu, 10 May 2012 10:56:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR2a-0006rc-1M for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:56:12 +0000 Received: from [85.158.139.83:21238] by server-10.bemta-5.messagelabs.com id 1A/F2-08260-BCE9BAF4; Thu, 10 May 2012 10:56:11 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336647368!27678954!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31890 invoked from network); 10 May 2012 10:56:10 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:56:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058136" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 06:56:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 06:56:07 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSR2V-0003So-Jm; Thu, 10 May 2012 11:56:07 +0100 Message-ID: <4FAB9E80.9040308@eu.citrix.com> Date: Thu, 10 May 2012 11:54:56 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <5b5070d487d948ff654c.1336559322@kodo2> <1336646620.7098.66.camel@zakaz.uk.xensource.com> In-Reply-To: <1336646620.7098.66.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 11:43, Ian Campbell wrote: > Acked-by: Ian Campbell > > (moving the definition of pcilist_assignable et al seems superfluous, > but I suppose it serves some purpose later in the series and the > function is small enough to review the changes + code motion by eye) Ah, right -- I didn't think about that. I'll try to avoid motion + changes in the future. You're right, the code motion is because we're changing the function from being mainly a "pcilist" thing (thus grouped with the other pci-list command) to mainly being an "assignable" thing (and thus grouped with other "assignable" commands). -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 10:56:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 10:56:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR2b-0006rp-M8; Thu, 10 May 2012 10:56:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR2a-0006rc-1M for xen-devel@lists.xensource.com; Thu, 10 May 2012 10:56:12 +0000 Received: from [85.158.139.83:21238] by server-10.bemta-5.messagelabs.com id 1A/F2-08260-BCE9BAF4; Thu, 10 May 2012 10:56:11 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336647368!27678954!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31890 invoked from network); 10 May 2012 10:56:10 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 10:56:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058136" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 06:56:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 06:56:07 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSR2V-0003So-Jm; Thu, 10 May 2012 11:56:07 +0100 Message-ID: <4FAB9E80.9040308@eu.citrix.com> Date: Thu, 10 May 2012 11:54:56 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <5b5070d487d948ff654c.1336559322@kodo2> <1336646620.7098.66.camel@zakaz.uk.xensource.com> In-Reply-To: <1336646620.7098.66.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2 of 4] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 11:43, Ian Campbell wrote: > Acked-by: Ian Campbell > > (moving the definition of pcilist_assignable et al seems superfluous, > but I suppose it serves some purpose later in the series and the > function is small enough to review the changes + code motion by eye) Ah, right -- I didn't think about that. I'll try to avoid motion + changes in the future. You're right, the code motion is because we're changing the function from being mainly a "pcilist" thing (thus grouped with the other pci-list command) to mainly being an "assignable" thing (and thus grouped with other "assignable" commands). -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSR77-000778-DA; Thu, 10 May 2012 11:00:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR75-000772-Pq for xen-devel@lists.xen.org; Thu, 10 May 2012 11:00:51 +0000 Received: from [85.158.143.35:19969] by server-2.bemta-4.messagelabs.com id A1/59-17550-2EF9BAF4; Thu, 10 May 2012 11:00:50 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1336647649!11605142!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13799 invoked from network); 10 May 2012 11:00:49 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 11:00:49 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSR72-000KmB-5n; Thu, 10 May 2012 11:00:48 +0000 Date: Thu, 10 May 2012 12:00:48 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20120510110048.GB73773@ocelot.phlegethon.org> References: <20120510103736.GA73773@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 11:49 +0100 on 10 May (1336650549), Jean Guyader wrote: > On 10 May 2012 11:37, Tim Deegan wrote: > > Looks OK, but what will it be used for? =A0There might be some more > > appropriate semantics at the hypercall interface than exposing the > > shadow internals as such. > = > It's related to the use of hvm_set_mem_pinned_cacheattr to set the default > caching policy when a guest starts to use a given gfn. > = > If this function is called after the guest has mapped the gfn it won't > have any affect. > The easy and surely not the best way to fix this is to destroy all the > shadow page > tables for this domain. > = > Maybe the ideal thing to do would be to make the cacheattr code aware > of the shadow page table and only clear the relevant set of shadow pages. Yes, I think that would be much better. That way we don't rely on the tools to maintain cache-attribute consistency within the hypervisor. You could use sh_remove_shadows() to unmap just the frames you want, but that will only make sense if the number of frames is small, since it may end up walking all the shadows searching for mappings each time. So if the hvm_set_mem_pinned_cacheattr() isn't going to be called very often, it would be OK just to call shadow_blow_tables_per_domain(). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSR77-000778-DA; Thu, 10 May 2012 11:00:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSR75-000772-Pq for xen-devel@lists.xen.org; Thu, 10 May 2012 11:00:51 +0000 Received: from [85.158.143.35:19969] by server-2.bemta-4.messagelabs.com id A1/59-17550-2EF9BAF4; Thu, 10 May 2012 11:00:50 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1336647649!11605142!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13799 invoked from network); 10 May 2012 11:00:49 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 11:00:49 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSR72-000KmB-5n; Thu, 10 May 2012 11:00:48 +0000 Date: Thu, 10 May 2012 12:00:48 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20120510110048.GB73773@ocelot.phlegethon.org> References: <20120510103736.GA73773@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: expose shadow_blow_tables to userspace X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 11:49 +0100 on 10 May (1336650549), Jean Guyader wrote: > On 10 May 2012 11:37, Tim Deegan wrote: > > Looks OK, but what will it be used for? =A0There might be some more > > appropriate semantics at the hypercall interface than exposing the > > shadow internals as such. > = > It's related to the use of hvm_set_mem_pinned_cacheattr to set the default > caching policy when a guest starts to use a given gfn. > = > If this function is called after the guest has mapped the gfn it won't > have any affect. > The easy and surely not the best way to fix this is to destroy all the > shadow page > tables for this domain. > = > Maybe the ideal thing to do would be to make the cacheattr code aware > of the shadow page table and only clear the relevant set of shadow pages. Yes, I think that would be much better. That way we don't rely on the tools to maintain cache-attribute consistency within the hypervisor. You could use sh_remove_shadows() to unmap just the frames you want, but that will only make sense if the number of frames is small, since it may end up walking all the shadows searching for mappings each time. So if the hvm_set_mem_pinned_cacheattr() isn't going to be called very often, it would be OK just to call shadow_blow_tables_per_domain(). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:12:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRHp-0007KF-Ni; Thu, 10 May 2012 11:11:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRHo-0007KA-JK for xen-devel@lists.xen.org; Thu, 10 May 2012 11:11:56 +0000 Received: from [193.109.254.147:31834] by server-9.bemta-14.messagelabs.com id EA/B8-05787-B72ABAF4; Thu, 10 May 2012 11:11:55 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336648313!1708579!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7627 invoked from network); 10 May 2012 11:11:54 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:11:54 -0000 Received: by vbbfn1 with SMTP id fn1so337629vbb.32 for ; Thu, 10 May 2012 04:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=DwN4JKVGQllCHUpXwkupvJpbWER2lJ69REPkdMZwM94=; b=zq+yHm5zmdB5xm4KphVRGZblYrD0rYh1O8ume2oDQ5ZnjYmeZs2rueIPcjNIhkpcEz hHj9uo8LCnI8V15h50TmeCz2fAREIQ0z+XzUwWc6C1KPhBf9n3E+JRQsLn3GY+DaldUf ikyrVbG7TjpMhwApi+w5OTIzKtB8JxQ86jYYSj4M39eR2FC8THzaov+mmWkZLolsONhh QrxZy+9arY5vLNkARp1k1ZOG+g/Pj9qWQHeDJTO3Bzq2Z0K3+TeN/eHTPEQg+J/D1b1q J/e/GB5js505QDN9uwgOBXMuZEHYBsaeyC4LGsId72L0s4iN2imrW4RkWv+pqkTl+GPF jXMQ== Received: by 10.220.150.12 with SMTP id w12mr2410393vcv.39.1336648313590; Thu, 10 May 2012 04:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 04:11:33 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 12:11:33 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=f46d04389097ebd44804bfacaf14 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --f46d04389097ebd44804bfacaf14 Content-Type: text/plain; charset=ISO-8859-1 After a host sleep MSI will be off on the host but qemu still thinks it's on because of some state that have been set previously. If qemu thinks that the device has been configure already and the host MSI are disabled tell Xen to reconfigure the MSI. Signed-off-by: Jean Guyader --f46d04389097ebd44804bfacaf14 Content-Type: text/x-patch; charset=US-ASCII; name="msi-after-sleep.patch" Content-Disposition: attachment; filename="msi-after-sleep.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21pw1xk0 ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5kZXgg ZjgzMmM1YS4uNWMzMmEyZSAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysrIGIvaHcv cGFzcy10aHJvdWdoLmMKQEAgLTM3NzIsNiArMzc3MiwyMSBAQCBzdGF0aWMgaW50IHB0X3BtY3Ny X3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gMDsKIH0KIAorc3Rh dGljIGludCBtc2lfaXNfZW5hYmxlKHN0cnVjdCBwdF9kZXYgKmRldikKK3sKKyAgICB1aW50MTZf dCB2YWwgPSAwOworICAgIHVpbnQzMl90IGFkZHJlc3MgPSAwOworICAgIGlmICghZGV2LT5tc2kp CisgICAgICAgIHJldHVybiAwOworCisgICAgYWRkcmVzcyA9IGRldi0+bXNpLT5jdHJsX29mZnNl dDsKKyAgICBpZiAoIWFkZHJlc3MpCisgICAgICAgIHJldHVybiAwOworCisgICAgdmFsID0gcGNp X3JlYWRfd29yZChkZXYtPnBjaV9kZXYsIGFkZHJlc3MpOworICAgIHJldHVybiB2YWwgJiBQQ0lf TVNJX0ZMQUdTX0VOQUJMRTsKK30KKwogLyogd3JpdGUgTWVzc2FnZSBDb250cm9sIHJlZ2lzdGVy ICovCiBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2 LAogICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCkBAIC0zODM1LDYgKzM4NTAsMTQg QEAgc3RhdGljIGludCBwdF9tc2djdHJsX3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwK ICAgICAgICAgICAgIHB0ZGV2LT5tc2ktPmZsYWdzICY9IH5NU0lfRkxBR19VTklOSVQ7CiAgICAg ICAgICAgICBwdGRldi0+bXNpLT5mbGFncyB8PSBQVF9NU0lfTUFQUEVEOwogICAgICAgICB9Cisg ICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCFtc2lfaXNfZW5hYmxlKHB0 ZGV2KSkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBwdF9tc2lfc2V0dXAocHRkZXYp OworICAgICAgICAgICAgICAgIHB0X21zaV91cGRhdGUocHRkZXYpOworICAgICAgICAgICAgfQor ICAgICAgICB9CiAgICAgICAgIHB0ZGV2LT5tc2ktPmZsYWdzIHw9IFBDSV9NU0lfRkxBR1NfRU5B QkxFOwogICAgIH0KICAgICBlbHNlCmRpZmYgLS1naXQgYS9ody9wdC1tc2kuYyBiL2h3L3B0LW1z aS5jCmluZGV4IDcwYzQwMjMuLjk5ZjlhZmQgMTAwNjQ0Ci0tLSBhL2h3L3B0LW1zaS5jCisrKyBi L2h3L3B0LW1zaS5jCkBAIC02NywxMiArNjcsNiBAQCBpbnQgcHRfbXNpX3NldHVwKHN0cnVjdCBw dF9kZXYgKmRldikKICAgICBpbnQgcGlycSA9IC0xOwogICAgIHVpbnQ4X3QgZ3ZlYyA9IDA7CiAK LSAgICBpZiAoICEoZGV2LT5tc2ktPmZsYWdzICYgTVNJX0ZMQUdfVU5JTklUKSApCi0gICAgewot ICAgICAgICBQVF9MT0coIkVycm9yOiBzZXR1cCBwaHlzaWNhbCBhZnRlciBpbml0aWFsaXplZD8/ IFxuIik7Ci0gICAgICAgIHJldHVybiAtMTsKLSAgICB9Ci0KICAgICBndmVjID0gZGV2LT5tc2kt PmRhdGEgJiAweEZGOwogICAgIGlmICghZ3ZlYykgewogICAgICAgICAvKiBpZiBndmVjIGlzIDAs IHRoZSBndWVzdCBpcyBhc2tpbmcgZm9yIGEgcGFydGljdWxhciBwaXJxIHRoYXQK --f46d04389097ebd44804bfacaf14 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --f46d04389097ebd44804bfacaf14-- From xen-devel-bounces@lists.xen.org Thu May 10 11:12:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRHp-0007KF-Ni; Thu, 10 May 2012 11:11:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRHo-0007KA-JK for xen-devel@lists.xen.org; Thu, 10 May 2012 11:11:56 +0000 Received: from [193.109.254.147:31834] by server-9.bemta-14.messagelabs.com id EA/B8-05787-B72ABAF4; Thu, 10 May 2012 11:11:55 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336648313!1708579!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7627 invoked from network); 10 May 2012 11:11:54 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:11:54 -0000 Received: by vbbfn1 with SMTP id fn1so337629vbb.32 for ; Thu, 10 May 2012 04:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=DwN4JKVGQllCHUpXwkupvJpbWER2lJ69REPkdMZwM94=; b=zq+yHm5zmdB5xm4KphVRGZblYrD0rYh1O8ume2oDQ5ZnjYmeZs2rueIPcjNIhkpcEz hHj9uo8LCnI8V15h50TmeCz2fAREIQ0z+XzUwWc6C1KPhBf9n3E+JRQsLn3GY+DaldUf ikyrVbG7TjpMhwApi+w5OTIzKtB8JxQ86jYYSj4M39eR2FC8THzaov+mmWkZLolsONhh QrxZy+9arY5vLNkARp1k1ZOG+g/Pj9qWQHeDJTO3Bzq2Z0K3+TeN/eHTPEQg+J/D1b1q J/e/GB5js505QDN9uwgOBXMuZEHYBsaeyC4LGsId72L0s4iN2imrW4RkWv+pqkTl+GPF jXMQ== Received: by 10.220.150.12 with SMTP id w12mr2410393vcv.39.1336648313590; Thu, 10 May 2012 04:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 04:11:33 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 12:11:33 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=f46d04389097ebd44804bfacaf14 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --f46d04389097ebd44804bfacaf14 Content-Type: text/plain; charset=ISO-8859-1 After a host sleep MSI will be off on the host but qemu still thinks it's on because of some state that have been set previously. If qemu thinks that the device has been configure already and the host MSI are disabled tell Xen to reconfigure the MSI. Signed-off-by: Jean Guyader --f46d04389097ebd44804bfacaf14 Content-Type: text/x-patch; charset=US-ASCII; name="msi-after-sleep.patch" Content-Disposition: attachment; filename="msi-after-sleep.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h21pw1xk0 ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5kZXgg ZjgzMmM1YS4uNWMzMmEyZSAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysrIGIvaHcv cGFzcy10aHJvdWdoLmMKQEAgLTM3NzIsNiArMzc3MiwyMSBAQCBzdGF0aWMgaW50IHB0X3BtY3Ny X3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gMDsKIH0KIAorc3Rh dGljIGludCBtc2lfaXNfZW5hYmxlKHN0cnVjdCBwdF9kZXYgKmRldikKK3sKKyAgICB1aW50MTZf dCB2YWwgPSAwOworICAgIHVpbnQzMl90IGFkZHJlc3MgPSAwOworICAgIGlmICghZGV2LT5tc2kp CisgICAgICAgIHJldHVybiAwOworCisgICAgYWRkcmVzcyA9IGRldi0+bXNpLT5jdHJsX29mZnNl dDsKKyAgICBpZiAoIWFkZHJlc3MpCisgICAgICAgIHJldHVybiAwOworCisgICAgdmFsID0gcGNp X3JlYWRfd29yZChkZXYtPnBjaV9kZXYsIGFkZHJlc3MpOworICAgIHJldHVybiB2YWwgJiBQQ0lf TVNJX0ZMQUdTX0VOQUJMRTsKK30KKwogLyogd3JpdGUgTWVzc2FnZSBDb250cm9sIHJlZ2lzdGVy ICovCiBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2 LAogICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCkBAIC0zODM1LDYgKzM4NTAsMTQg QEAgc3RhdGljIGludCBwdF9tc2djdHJsX3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwK ICAgICAgICAgICAgIHB0ZGV2LT5tc2ktPmZsYWdzICY9IH5NU0lfRkxBR19VTklOSVQ7CiAgICAg ICAgICAgICBwdGRldi0+bXNpLT5mbGFncyB8PSBQVF9NU0lfTUFQUEVEOwogICAgICAgICB9Cisg ICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCFtc2lfaXNfZW5hYmxlKHB0 ZGV2KSkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBwdF9tc2lfc2V0dXAocHRkZXYp OworICAgICAgICAgICAgICAgIHB0X21zaV91cGRhdGUocHRkZXYpOworICAgICAgICAgICAgfQor ICAgICAgICB9CiAgICAgICAgIHB0ZGV2LT5tc2ktPmZsYWdzIHw9IFBDSV9NU0lfRkxBR1NfRU5B QkxFOwogICAgIH0KICAgICBlbHNlCmRpZmYgLS1naXQgYS9ody9wdC1tc2kuYyBiL2h3L3B0LW1z aS5jCmluZGV4IDcwYzQwMjMuLjk5ZjlhZmQgMTAwNjQ0Ci0tLSBhL2h3L3B0LW1zaS5jCisrKyBi L2h3L3B0LW1zaS5jCkBAIC02NywxMiArNjcsNiBAQCBpbnQgcHRfbXNpX3NldHVwKHN0cnVjdCBw dF9kZXYgKmRldikKICAgICBpbnQgcGlycSA9IC0xOwogICAgIHVpbnQ4X3QgZ3ZlYyA9IDA7CiAK LSAgICBpZiAoICEoZGV2LT5tc2ktPmZsYWdzICYgTVNJX0ZMQUdfVU5JTklUKSApCi0gICAgewot ICAgICAgICBQVF9MT0coIkVycm9yOiBzZXR1cCBwaHlzaWNhbCBhZnRlciBpbml0aWFsaXplZD8/ IFxuIik7Ci0gICAgICAgIHJldHVybiAtMTsKLSAgICB9Ci0KICAgICBndmVjID0gZGV2LT5tc2kt PmRhdGEgJiAweEZGOwogICAgIGlmICghZ3ZlYykgewogICAgICAgICAvKiBpZiBndmVjIGlzIDAs IHRoZSBndWVzdCBpcyBhc2tpbmcgZm9yIGEgcGFydGljdWxhciBwaXJxIHRoYXQK --f46d04389097ebd44804bfacaf14 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --f46d04389097ebd44804bfacaf14-- From xen-devel-bounces@lists.xen.org Thu May 10 11:20:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:20:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPT-0007UP-QQ; Thu, 10 May 2012 11:19:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPS-0007UJ-8t for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:19:50 +0000 Received: from [193.109.254.147:33166] by server-10.bemta-14.messagelabs.com id 99/E6-05847-554ABAF4; Thu, 10 May 2012 11:19:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336648788!8601748!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6048 invoked from network); 10 May 2012 11:19:48 -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; 10 May 2012 11:19:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403240" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:19: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, 10 May 2012 12:19:47 +0100 Message-ID: <1336648786.7098.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 12:19:46 +0100 In-Reply-To: <17a5b562d1e79d094c58.1336559323@kodo2> References: <17a5b562d1e79d094c58.1336559323@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > Introduce libxl helper functions to prepare devices to be passed through to > guests. This is meant to replace of all the manual sysfs commands which > are currently required. > > pci_assignable_add accepts a BDF for a device and will: > * Unbind a device from its current driver, if any > * If "rebind" is set, it will store the path of the driver from which we > unplugged it in /libxl/pciback/$BDF/driver_path Since you don't know whether the user is going to pass -r to assignable_remove why not always store this? > * If necessary, create a slot for it in pciback I must confess I'm a bit fuzzy on the relationship between slots and bindings, where does the "if necessary" come into it? I was wondering while reading the patch if unconditionally adding a removing the slot might simplify a bunch of stuff, but I suspect I just don't appreciate some particular aspect of how pciback works... > * Bind the device to pciback > > At this point it will show up in pci_assignable_list, and is ready to be passed > through to a guest. > > pci_assignable_remove accepts a BDF for a device and will: > * Unbind the device from pciback > * Remove the slot from pciback > * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will > attempt to rebind the device to its original driver. > > NB that "$BDF" in this case uses dashes instead of : and ., because : and . are > illegal characters in xenstore paths. > > Signed-off-by: George Dunlap > > diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl.h > --- a/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 > +++ b/tools/libxl/libxl.h Wed May 09 11:21:28 2012 +0100 > @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * > libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); > > /* > - * Similar to libxl_device_pci_list but returns all devices which > - * could be assigned to a domain (i.e. are bound to the backend > - * driver) but are not currently. > + * Functions related to making devices assignable -- that is, bound to > + * the pciback driver, ready to be given to a guest via > + * libxl_pci_device_add. > + * > + * - ..._add() will unbind the device from its current driver (if > + * already bound) and re-bind it to pciback; at that point it will be > + * ready to be assigned to a VM. If rebind is set, it will store the > + * path to the old driver in xenstore so that it can be handed back to > + * dom0 on restore. > + * > + * - ..._remove() will unbind the device from pciback, and if > + * rebind is non-zero, attempt to assign it back to the driver > + * from whence it came. > + * > + * - ..._list() will return a list of the PCI devices available to be > + * assigned. > */ > +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); > +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); > libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); > > /* CPUID handling */ > diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:28 2012 +0100 > @@ -21,6 +21,7 @@ > #define PCI_BDF "%04x:%02x:%02x.%01x" > #define PCI_BDF_SHORT "%02x:%02x.%01x" > #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" > +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" > > static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) > { > @@ -408,6 +409,347 @@ out: > return pcidevs; > } > > +/* Unbind device from its current driver, if any. If driver_path is non-NULL, > + * store the path to the original driver in it. */ > +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, char **driver_path) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * spath, *_dp, **dp; > + struct stat st; > + > + if ( driver_path ) > + dp = driver_path; > + else > + dp = &_dp; > + > + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + if ( !lstat(spath, &st) ) { > + /* Find the canonical path to the driver. */ > + *dp = libxl__zalloc(gc, PATH_MAX); Should we be actually using fpathconf / sysconf here? > + *dp = realpath(spath, *dp); > + if ( !*dp ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); Since errno is meaningful you want LIBXL__LOGERRNO here. Or the short form LOGE(). Where you have pointer output params (like driver_path here) in general I think it is preferable to do everything with a local (single indirection) pointer and only update the output parameter on success. This means you avoid leaking/exposing a partial result on error but also means you can drop a lot of "*" from around the function. Maybe the gc makes this moot, but the "if ( driver_path )" stuff at the top of the fn took me several seconds to work out also ;-). > + return -1; > + } > + > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", > + *dp); > + > + /* Unbind from the old driver */ > + spath = libxl__sprintf(gc, "%s/unbind", *dp); > + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); Not sure what errno is like here, worth printing it. Looking back at patch #1 I suspect sysfs_write_bdf should preserve errno over the call to close, so that suitable reporting can happen in the caller. > + return -1; > + } > + } > + return 0; > +} > + > +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ > +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) Is the concept of "having a slot" distinct from being bound to pciback? > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + FILE *f; > + int rc = 0; > + unsigned bus, dev, func; > + > + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); > + > + if (f == NULL) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + SYSFS_PCIBACK_DRIVER"/slots"); > + return ERROR_FAIL; > + } > + > + while(fscanf(f, "0000:%x:%x.%x\n", &bus, &dev, &func)==3) { Jan recently added support for PCI domains, does that have any impact on the hardcoded 0000 here? I suppose that would require PCI domains support in the dom0 kernel -- but that seems likely to already be there (or be imminent) I think the 0000 should be %x into domain compared with pcidev->domain. > + if(bus == pcidev->bus > + && dev == pcidev->dev > + && func == pcidev->func) { > + rc = 1; > + goto out; > + } > + } > +out: > + fclose(f); > + return rc; > +} > + > +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * spath; > + int rc; > + struct stat st; > + > + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, > + pcidev->domain, pcidev->bus, > + pcidev->dev, pcidev->func); > + rc = lstat(spath, &st); > + > + if( rc == 0 ) > + return 1; > + if ( rc < 0 && errno == ENOENT ) > + return 0; > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); > + return -1; > +} > + > +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc; > + > + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Error checking for pciback slot"); Log errno? Also pciback_dev_has_slot itself always logs on error, you probably don't need both. > + return ERROR_FAIL; > + } else if (rc == 0) { > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't bind device to pciback!"); ERRNO here too. > + return ERROR_FAIL; > + } > + } > + > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); ERRNO here too. Or since there are loads of these perhaps sysfs_write_bf should log on failure, either just the fact of the failed write to a path (which implies the underlying failure was to bind/unbind) or you could add a "const char *what" param to use in logging. > + return ERROR_FAIL; > + } > + return 0; > +} > + > +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + > + /* Remove from pciback */ > + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); > + return ERROR_FAIL; > + } > + > + /* Remove slot if necessary */ > + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't remove pciback slot"); ERRNO > + return ERROR_FAIL; > + } > + } > + return 0; > +} > + > +/* FIXME */ Leftover? > +#define PCIBACK_INFO_PATH "/libxl/pciback" > + > +static void pci_assignable_driver_path_write(libxl__gc *gc, > + libxl_device_pci *pcidev, > + char *driver_path) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char *path; > + xs_transaction_t t = 0; > + struct xs_permissions perm[1]; > + > + perm[0].id = 0; > + perm[0].perms = XS_PERM_NONE; > + > +retry: > + t = xs_transaction_start(ctx->xsh); > + > + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + xs_rm(ctx->xsh, t, path); Why do you need to rm first? Won't the write just replace whatever it is (and that means the need for a transaction goes away too) In any case you should create path outside the retry loop instead of needlessly recreating it each time around. > + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Write of %s to node %s failed", > + driver_path, path); > + } > + > + if (!xs_transaction_end(ctx->xsh, t, 0)) { > + if (errno == EAGAIN) { > + t = 0; > + goto retry; > + } > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "xenstore transaction commit failed; device " > + " will not be rebound to original driver."); > + } > +} > + > +static char * pci_assignable_driver_path_read(libxl__gc *gc, > + libxl_device_pci *pcidev) > +{ > + return libxl__xs_read(gc, XBT_NULL, > + libxl__sprintf(gc, > + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func)); > +} > + > +static void pci_assignable_driver_path_remove(libxl__gc *gc, > + libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * path; > + xs_transaction_t t; > + > + /* Remove the xenstore entry */ > +retry: > + t = xs_transaction_start(ctx->xsh); > + path = libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + xs_rm(ctx->xsh, t, path); You don't need a transaction for a single operation. (and if you did then "path = ..." could have been hoisted out) > + if (!xs_transaction_end(ctx->xsh, t, 0)) { > + if (errno == EAGAIN) > + goto retry; > + else > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Failed to remove xenstore entry"); > + } > +} > + > +static int libxl__device_pci_assignable_add(libxl__gc *gc, > + libxl_device_pci *pcidev, > + int rebind) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + unsigned dom, bus, dev, func; > + char *spath, *driver_path = NULL; > + struct stat st; > + > + /* Local copy for convenience */ > + dom = pcidev->domain; > + bus = pcidev->bus; > + dev = pcidev->dev; > + func = pcidev->func; > + > + /* See if the device exists */ > + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); > + if ( lstat(spath, &st) ) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); > + return ERROR_FAIL; > + } > + > + /* Check to see if it's already assigned to pciback */ > + if ( pciback_dev_is_assigned(gc, pcidev) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", > + dom, bus, dev, func); > + return 0; > + } > + > + /* Check to see if there's already a driver that we need to unbind from */ > + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind "PCI_BDF" from driver", > + dom, bus, dev, func); > + return ERROR_FAIL; > + } > + > + /* Store driver_path for rebinding to dom0 */ > + if ( rebind ) { > + if ( driver_path ) { > + pci_assignable_driver_path_write(gc, pcidev, driver_path); > + } else { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + PCI_BDF" not bound to a driver, will not be rebound.", > + dom, bus, dev, func); > + } > + } > + > + if ( pciback_dev_assign(gc, pcidev) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); > + return ERROR_FAIL; > + } > + > + return 0; > +} > + > +static int libxl__device_pci_assignable_remove(libxl__gc *gc, > + libxl_device_pci *pcidev, > + int rebind) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc; > + char *driver_path; > + > + /* Unbind from pciback */ > + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); > + return ERROR_FAIL; > + } else if ( rc ) { > + pciback_dev_unassign(gc, pcidev); > + } else { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "Not bound to pciback"); > + } > + > + /* Rebind if necessary */ > + driver_path = pci_assignable_driver_path_read(gc, pcidev); > + > + if ( driver_path ) { > + if ( rebind ) { > + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", > + driver_path); > + > + if ( sysfs_write_bdf(gc, > + libxl__sprintf(gc, "%s/bind", driver_path), > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't bind device to %s", driver_path); > + return -1; > + } > + } > + > + pci_assignable_driver_path_remove(gc, pcidev); > + } else { > + if ( rebind ) { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "Couldn't find path for original driver; not rebinding"); > + } > + } > + > + return 0; > +} > + > +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, > + int rebind) > +{ > + GC_INIT(ctx); > + int rc; > + > + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); > + > + GC_FREE; > + return rc; > +} Are there internal callers of libxl__device_pci_assignable_add/remove? If not then there's no reason to split into internal/external functions. Doesn't matter much I guess. > + > + > +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, > + int rebind) > +{ > + GC_INIT(ctx); > + int rc; > + > + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); > + > + GC_FREE; > + return rc; > +} > + > /* > * This function checks that all functions of a device are bound to pciback > * driver. It also initialises a bit-mask of which function numbers are present > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:20:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPT-0007UP-QQ; Thu, 10 May 2012 11:19:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPS-0007UJ-8t for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:19:50 +0000 Received: from [193.109.254.147:33166] by server-10.bemta-14.messagelabs.com id 99/E6-05847-554ABAF4; Thu, 10 May 2012 11:19:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336648788!8601748!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6048 invoked from network); 10 May 2012 11:19:48 -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; 10 May 2012 11:19:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403240" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:19: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, 10 May 2012 12:19:47 +0100 Message-ID: <1336648786.7098.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 12:19:46 +0100 In-Reply-To: <17a5b562d1e79d094c58.1336559323@kodo2> References: <17a5b562d1e79d094c58.1336559323@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > Introduce libxl helper functions to prepare devices to be passed through to > guests. This is meant to replace of all the manual sysfs commands which > are currently required. > > pci_assignable_add accepts a BDF for a device and will: > * Unbind a device from its current driver, if any > * If "rebind" is set, it will store the path of the driver from which we > unplugged it in /libxl/pciback/$BDF/driver_path Since you don't know whether the user is going to pass -r to assignable_remove why not always store this? > * If necessary, create a slot for it in pciback I must confess I'm a bit fuzzy on the relationship between slots and bindings, where does the "if necessary" come into it? I was wondering while reading the patch if unconditionally adding a removing the slot might simplify a bunch of stuff, but I suspect I just don't appreciate some particular aspect of how pciback works... > * Bind the device to pciback > > At this point it will show up in pci_assignable_list, and is ready to be passed > through to a guest. > > pci_assignable_remove accepts a BDF for a device and will: > * Unbind the device from pciback > * Remove the slot from pciback > * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will > attempt to rebind the device to its original driver. > > NB that "$BDF" in this case uses dashes instead of : and ., because : and . are > illegal characters in xenstore paths. > > Signed-off-by: George Dunlap > > diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl.h > --- a/tools/libxl/libxl.h Wed May 09 11:21:19 2012 +0100 > +++ b/tools/libxl/libxl.h Wed May 09 11:21:28 2012 +0100 > @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * > libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); > > /* > - * Similar to libxl_device_pci_list but returns all devices which > - * could be assigned to a domain (i.e. are bound to the backend > - * driver) but are not currently. > + * Functions related to making devices assignable -- that is, bound to > + * the pciback driver, ready to be given to a guest via > + * libxl_pci_device_add. > + * > + * - ..._add() will unbind the device from its current driver (if > + * already bound) and re-bind it to pciback; at that point it will be > + * ready to be assigned to a VM. If rebind is set, it will store the > + * path to the old driver in xenstore so that it can be handed back to > + * dom0 on restore. > + * > + * - ..._remove() will unbind the device from pciback, and if > + * rebind is non-zero, attempt to assign it back to the driver > + * from whence it came. > + * > + * - ..._list() will return a list of the PCI devices available to be > + * assigned. > */ > +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); > +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); > libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); > > /* CPUID handling */ > diff -r 5b5070d487d9 -r 17a5b562d1e7 tools/libxl/libxl_pci.c > --- a/tools/libxl/libxl_pci.c Wed May 09 11:21:19 2012 +0100 > +++ b/tools/libxl/libxl_pci.c Wed May 09 11:21:28 2012 +0100 > @@ -21,6 +21,7 @@ > #define PCI_BDF "%04x:%02x:%02x.%01x" > #define PCI_BDF_SHORT "%02x:%02x.%01x" > #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" > +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" > > static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) > { > @@ -408,6 +409,347 @@ out: > return pcidevs; > } > > +/* Unbind device from its current driver, if any. If driver_path is non-NULL, > + * store the path to the original driver in it. */ > +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, char **driver_path) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * spath, *_dp, **dp; > + struct stat st; > + > + if ( driver_path ) > + dp = driver_path; > + else > + dp = &_dp; > + > + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + if ( !lstat(spath, &st) ) { > + /* Find the canonical path to the driver. */ > + *dp = libxl__zalloc(gc, PATH_MAX); Should we be actually using fpathconf / sysconf here? > + *dp = realpath(spath, *dp); > + if ( !*dp ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); Since errno is meaningful you want LIBXL__LOGERRNO here. Or the short form LOGE(). Where you have pointer output params (like driver_path here) in general I think it is preferable to do everything with a local (single indirection) pointer and only update the output parameter on success. This means you avoid leaking/exposing a partial result on error but also means you can drop a lot of "*" from around the function. Maybe the gc makes this moot, but the "if ( driver_path )" stuff at the top of the fn took me several seconds to work out also ;-). > + return -1; > + } > + > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", > + *dp); > + > + /* Unbind from the old driver */ > + spath = libxl__sprintf(gc, "%s/unbind", *dp); > + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); Not sure what errno is like here, worth printing it. Looking back at patch #1 I suspect sysfs_write_bdf should preserve errno over the call to close, so that suitable reporting can happen in the caller. > + return -1; > + } > + } > + return 0; > +} > + > +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ > +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) Is the concept of "having a slot" distinct from being bound to pciback? > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + FILE *f; > + int rc = 0; > + unsigned bus, dev, func; > + > + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); > + > + if (f == NULL) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + SYSFS_PCIBACK_DRIVER"/slots"); > + return ERROR_FAIL; > + } > + > + while(fscanf(f, "0000:%x:%x.%x\n", &bus, &dev, &func)==3) { Jan recently added support for PCI domains, does that have any impact on the hardcoded 0000 here? I suppose that would require PCI domains support in the dom0 kernel -- but that seems likely to already be there (or be imminent) I think the 0000 should be %x into domain compared with pcidev->domain. > + if(bus == pcidev->bus > + && dev == pcidev->dev > + && func == pcidev->func) { > + rc = 1; > + goto out; > + } > + } > +out: > + fclose(f); > + return rc; > +} > + > +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * spath; > + int rc; > + struct stat st; > + > + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, > + pcidev->domain, pcidev->bus, > + pcidev->dev, pcidev->func); > + rc = lstat(spath, &st); > + > + if( rc == 0 ) > + return 1; > + if ( rc < 0 && errno == ENOENT ) > + return 0; > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); > + return -1; > +} > + > +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc; > + > + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Error checking for pciback slot"); Log errno? Also pciback_dev_has_slot itself always logs on error, you probably don't need both. > + return ERROR_FAIL; > + } else if (rc == 0) { > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't bind device to pciback!"); ERRNO here too. > + return ERROR_FAIL; > + } > + } > + > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); ERRNO here too. Or since there are loads of these perhaps sysfs_write_bf should log on failure, either just the fact of the failed write to a path (which implies the underlying failure was to bind/unbind) or you could add a "const char *what" param to use in logging. > + return ERROR_FAIL; > + } > + return 0; > +} > + > +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + > + /* Remove from pciback */ > + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); > + return ERROR_FAIL; > + } > + > + /* Remove slot if necessary */ > + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { > + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't remove pciback slot"); ERRNO > + return ERROR_FAIL; > + } > + } > + return 0; > +} > + > +/* FIXME */ Leftover? > +#define PCIBACK_INFO_PATH "/libxl/pciback" > + > +static void pci_assignable_driver_path_write(libxl__gc *gc, > + libxl_device_pci *pcidev, > + char *driver_path) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char *path; > + xs_transaction_t t = 0; > + struct xs_permissions perm[1]; > + > + perm[0].id = 0; > + perm[0].perms = XS_PERM_NONE; > + > +retry: > + t = xs_transaction_start(ctx->xsh); > + > + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + xs_rm(ctx->xsh, t, path); Why do you need to rm first? Won't the write just replace whatever it is (and that means the need for a transaction goes away too) In any case you should create path outside the retry loop instead of needlessly recreating it each time around. > + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Write of %s to node %s failed", > + driver_path, path); > + } > + > + if (!xs_transaction_end(ctx->xsh, t, 0)) { > + if (errno == EAGAIN) { > + t = 0; > + goto retry; > + } > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "xenstore transaction commit failed; device " > + " will not be rebound to original driver."); > + } > +} > + > +static char * pci_assignable_driver_path_read(libxl__gc *gc, > + libxl_device_pci *pcidev) > +{ > + return libxl__xs_read(gc, XBT_NULL, > + libxl__sprintf(gc, > + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func)); > +} > + > +static void pci_assignable_driver_path_remove(libxl__gc *gc, > + libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + char * path; > + xs_transaction_t t; > + > + /* Remove the xenstore entry */ > +retry: > + t = xs_transaction_start(ctx->xsh); > + path = libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, > + pcidev->domain, > + pcidev->bus, > + pcidev->dev, > + pcidev->func); > + xs_rm(ctx->xsh, t, path); You don't need a transaction for a single operation. (and if you did then "path = ..." could have been hoisted out) > + if (!xs_transaction_end(ctx->xsh, t, 0)) { > + if (errno == EAGAIN) > + goto retry; > + else > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, > + "Failed to remove xenstore entry"); > + } > +} > + > +static int libxl__device_pci_assignable_add(libxl__gc *gc, > + libxl_device_pci *pcidev, > + int rebind) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + unsigned dom, bus, dev, func; > + char *spath, *driver_path = NULL; > + struct stat st; > + > + /* Local copy for convenience */ > + dom = pcidev->domain; > + bus = pcidev->bus; > + dev = pcidev->dev; > + func = pcidev->func; > + > + /* See if the device exists */ > + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); > + if ( lstat(spath, &st) ) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); > + return ERROR_FAIL; > + } > + > + /* Check to see if it's already assigned to pciback */ > + if ( pciback_dev_is_assigned(gc, pcidev) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", > + dom, bus, dev, func); > + return 0; > + } > + > + /* Check to see if there's already a driver that we need to unbind from */ > + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind "PCI_BDF" from driver", > + dom, bus, dev, func); > + return ERROR_FAIL; > + } > + > + /* Store driver_path for rebinding to dom0 */ > + if ( rebind ) { > + if ( driver_path ) { > + pci_assignable_driver_path_write(gc, pcidev, driver_path); > + } else { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + PCI_BDF" not bound to a driver, will not be rebound.", > + dom, bus, dev, func); > + } > + } > + > + if ( pciback_dev_assign(gc, pcidev) ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); > + return ERROR_FAIL; > + } > + > + return 0; > +} > + > +static int libxl__device_pci_assignable_remove(libxl__gc *gc, > + libxl_device_pci *pcidev, > + int rebind) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + int rc; > + char *driver_path; > + > + /* Unbind from pciback */ > + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); > + return ERROR_FAIL; > + } else if ( rc ) { > + pciback_dev_unassign(gc, pcidev); > + } else { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "Not bound to pciback"); > + } > + > + /* Rebind if necessary */ > + driver_path = pci_assignable_driver_path_read(gc, pcidev); > + > + if ( driver_path ) { > + if ( rebind ) { > + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", > + driver_path); > + > + if ( sysfs_write_bdf(gc, > + libxl__sprintf(gc, "%s/bind", driver_path), > + pcidev) < 0 ) { > + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > + "Couldn't bind device to %s", driver_path); > + return -1; > + } > + } > + > + pci_assignable_driver_path_remove(gc, pcidev); > + } else { > + if ( rebind ) { > + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, > + "Couldn't find path for original driver; not rebinding"); > + } > + } > + > + return 0; > +} > + > +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, > + int rebind) > +{ > + GC_INIT(ctx); > + int rc; > + > + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); > + > + GC_FREE; > + return rc; > +} Are there internal callers of libxl__device_pci_assignable_add/remove? If not then there's no reason to split into internal/external functions. Doesn't matter much I guess. > + > + > +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, > + int rebind) > +{ > + GC_INIT(ctx); > + int rc; > + > + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); > + > + GC_FREE; > + return rc; > +} > + > /* > * This function checks that all functions of a device are bound to pciback > * driver. It also initialises a bit-mask of which function numbers are present > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRPj-0007V9-6x; Thu, 10 May 2012 11:20:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPh-0007Ux-Ed for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:20:05 +0000 Received: from [85.158.143.35:7689] by server-1.bemta-4.messagelabs.com id 7E/A9-20925-464ABAF4; Thu, 10 May 2012 11:20:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336648802!8255367!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9531 invoked from network); 10 May 2012 11:20:03 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:20:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403246" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:01 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRPd-0006ep-4g; Thu, 10 May 2012 11:20:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRPd-0004o0-2O; Thu, 10 May 2012 12:20:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42080.935833.873461@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:00 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: fix typo in opengl section"): > xl.cfg: fix typo in opengl section Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRPj-0007V9-6x; Thu, 10 May 2012 11:20:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPh-0007Ux-Ed for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:20:05 +0000 Received: from [85.158.143.35:7689] by server-1.bemta-4.messagelabs.com id 7E/A9-20925-464ABAF4; Thu, 10 May 2012 11:20:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336648802!8255367!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9531 invoked from network); 10 May 2012 11:20:03 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:20:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403246" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:01 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRPd-0006ep-4g; Thu, 10 May 2012 11:20:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRPd-0004o0-2O; Thu, 10 May 2012 12:20:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42080.935833.873461@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:00 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xl.cfg: fix typo in opengl section X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] xl.cfg: fix typo in opengl section"): > xl.cfg: fix typo in opengl section Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRQ1-0007XZ-Ja; Thu, 10 May 2012 11:20:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPz-0007X9-I3 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:20:23 +0000 Received: from [85.158.138.51:19999] by server-7.bemta-3.messagelabs.com id CD/23-03078-674ABAF4; Thu, 10 May 2012 11:20:22 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336648821!18364405!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26968 invoked from network); 10 May 2012 11:20: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; 10 May 2012 11:20:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403257" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:20 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRPw-0006f4-Cs; Thu, 10 May 2012 11:20:20 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRPw-0004o6-Bw; Thu, 10 May 2012 12:20:20 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42099.431647.59015@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:19 +0100 To: Daniel De Graaf Newsgroups: chiark.mail.xen.devel In-Reply-To: <4FAA9E85.9010007@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> <20394.36387.49258.141494@mariner.uk.xensource.com> <4FAA9E85.9010007@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > I like that method (or this slight tweak to it): > > -----------8<------------------------- > > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Fix the macro to return the proper value. Excellent, thanks. Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRQ1-0007XZ-Ja; Thu, 10 May 2012 11:20:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRPz-0007X9-I3 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:20:23 +0000 Received: from [85.158.138.51:19999] by server-7.bemta-3.messagelabs.com id CD/23-03078-674ABAF4; Thu, 10 May 2012 11:20:22 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336648821!18364405!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26968 invoked from network); 10 May 2012 11:20: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; 10 May 2012 11:20:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403257" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:20 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRPw-0006f4-Cs; Thu, 10 May 2012 11:20:20 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRPw-0004o6-Bw; Thu, 10 May 2012 12:20:20 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42099.431647.59015@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:19 +0100 To: Daniel De Graaf Newsgroups: chiark.mail.xen.devel In-Reply-To: <4FAA9E85.9010007@tycho.nsa.gov> References: <1336418109-6335-1-git-send-email-dgdegra@tycho.nsa.gov> <20394.28369.936242.527916@mariner.uk.xensource.com> <4FAA7354.5070802@tycho.nsa.gov> <20394.36387.49258.141494@mariner.uk.xensource.com> <4FAA9E85.9010007@tycho.nsa.gov> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v2] libxl: Fix incorrect return of OSEVENT_HOOK macro"): > I like that method (or this slight tweak to it): > > -----------8<------------------------- > > The OSEVENT_HOOK_INTERN macro incorrectly returned the value of the > expression CTX->osevent_in_hook-- (usually 1) instead of the value of > the function call it made. Fix the macro to return the proper value. Excellent, thanks. Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRQF-0007Zq-6d; Thu, 10 May 2012 11:20:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRQD-0007ZQ-I8 for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:20:37 +0000 Received: from [85.158.143.99:51445] by server-2.bemta-4.messagelabs.com id 01/9B-17550-484ABAF4; Thu, 10 May 2012 11:20:36 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336648834!27324208!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1639 invoked from network); 10 May 2012 11:20:35 -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; 10 May 2012 11:20:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403261" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:20:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRQ8-0006f8-St; Thu, 10 May 2012 11:20:32 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRQ8-0004oA-S2; Thu, 10 May 2012 12:20:32 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42112.751343.783836@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:32 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336483619.14542.86.camel@zakaz.uk.xensource.com> References: <1336483619.14542.86.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.org" Subject: Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL"): > libxl: log failure from libxl__blktap_devpath in libxl_device_disk_add Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:20:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRQF-0007Zq-6d; Thu, 10 May 2012 11:20:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRQD-0007ZQ-I8 for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:20:37 +0000 Received: from [85.158.143.99:51445] by server-2.bemta-4.messagelabs.com id 01/9B-17550-484ABAF4; Thu, 10 May 2012 11:20:36 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336648834!27324208!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1639 invoked from network); 10 May 2012 11:20:35 -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; 10 May 2012 11:20:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403261" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:20:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRQ8-0006f8-St; Thu, 10 May 2012 11:20:32 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRQ8-0004oA-S2; Thu, 10 May 2012 12:20:32 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42112.751343.783836@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:32 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336483619.14542.86.camel@zakaz.uk.xensource.com> References: <1336483619.14542.86.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.org" Subject: Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12800: tolerable FAIL"): > libxl: log failure from libxl__blktap_devpath in libxl_device_disk_add Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:27:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRWX-00083X-1X; Thu, 10 May 2012 11:27:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRWV-00083S-Af for xen-devel@lists.xen.org; Thu, 10 May 2012 11:27:07 +0000 Received: from [193.109.254.147:38762] by server-3.bemta-14.messagelabs.com id E4/6B-23274-A06ABAF4; Thu, 10 May 2012 11:27:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336648845!1738464!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15219 invoked from network); 10 May 2012 11:20:46 -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 May 2012 11:20:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403267" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:45 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRQK-0006fE-TE; Thu, 10 May 2012 11:20:44 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRQK-0004oJ-SL; Thu, 10 May 2012 12:20:44 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42124.863218.895547@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:44 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336645119.7098.49.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> <1336645119.7098.49.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "rshriram@cs.ubc.ca" , Anthony Perard , Stefano Stabellini , xen-devel Subject: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status))"): > MAINTAINERS: add myself as a tools maintainer > > Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:27:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRWX-00083X-1X; Thu, 10 May 2012 11:27:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRWV-00083S-Af for xen-devel@lists.xen.org; Thu, 10 May 2012 11:27:07 +0000 Received: from [193.109.254.147:38762] by server-3.bemta-14.messagelabs.com id E4/6B-23274-A06ABAF4; Thu, 10 May 2012 11:27:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336648845!1738464!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15219 invoked from network); 10 May 2012 11:20:46 -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 May 2012 11:20:46 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403267" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:20: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, 10 May 2012 12:20:45 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRQK-0006fE-TE; Thu, 10 May 2012 11:20:44 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRQK-0004oJ-SL; Thu, 10 May 2012 12:20:44 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.42124.863218.895547@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:20:44 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336645119.7098.49.camel@zakaz.uk.xensource.com> References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> <20394.29747.791679.439889@mariner.uk.xensource.com> <1336645119.7098.49.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "rshriram@cs.ubc.ca" , Anthony Perard , Stefano Stabellini , xen-devel Subject: [Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status))"): > MAINTAINERS: add myself as a tools maintainer > > Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY5-00087p-EG; Thu, 10 May 2012 11:28:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY4-00086z-8a for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:44 +0000 Received: from [85.158.143.99:13321] by server-3.bemta-4.messagelabs.com id 5A/5C-05853-A66ABAF4; Thu, 10 May 2012 11:28:42 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2206 invoked from network); 10 May 2012 11:28:40 -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; 10 May 2012 11:28:40 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234742" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-MN; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:29 +0100 Message-ID: <1336649312-11198-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add another parameter to libxl__exec call that contains the environment variables to use when performing the execvp call. Changes since v3: * Use CTX instead of defining libxl_ctx *ctx. * Error checking on setenv. * Better comment on header for libxl__exec function. * Added some const-correctness. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/libxl/libxl.c | 2 +- tools/libxl/libxl_bootloader.c | 4 ++-- tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_exec.c | 20 ++++++++++++++++++-- tools/libxl/libxl_internal.h | 20 ++++++++++++++++++-- 5 files changed, 40 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 8f63941..79d7708 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1251,7 +1251,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass) args[2] = "-autopass"; } - libxl__exec(autopass_fd, -1, -1, args[0], args); + libxl__exec(gc, autopass_fd, -1, -1, args[0], args, NULL); abort(); x_fail: diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index fb1302b..0021a7b 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -359,6 +359,7 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty); STATE_AO_GC(bl->ao); int rc, r; + char *const env[] = { "TERM", "vt100", NULL }; if (bl->openpty.rc) { rc = bl->openpty.rc; @@ -452,8 +453,7 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) /* child */ r = login_tty(libxl__carefd_fd(bl->ptys[0].slave)); if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); } - setenv("TERM", "vt100", 1); - libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args); + libxl__exec(gc, -1, -1, -1, bl->args[0], (char **) bl->args, env); exit(-1); } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index b2bae68..5de3aef 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1006,7 +1006,7 @@ retry_transaction: goto out_close; if (!rc) { /* inner child */ setsid(); - libxl__exec(null, logfile_w, logfile_w, dm, args); + libxl__exec(gc, null, logfile_w, logfile_w, dm, args, NULL); } rc = 0; diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index b46b893..fba4cb4 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -66,8 +66,8 @@ static void check_open_fds(const char *what) if (badness) abort(); } -void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, - char **args) +void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd, int stderrfd, + const char *arg0, char *const args[], char *const env[]) /* call this in the child */ { if (stdinfd != -1) @@ -90,8 +90,24 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, /* 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) { + if (setenv(env[i], env[i+1], 1) < 0) { + switch (errno) { + case EINVAL: + LOGEV(ERROR, errno, "invalid env variables (%s = %s)", + env[i], env[i+1]); + break; + case ENOMEM: + libxl__alloc_failed(CTX, __func__, 0, 0); + } + goto out; + } + } + } execvp(arg0, args); +out: fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno)); _exit(-1); } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 8a90622..9ab76f8 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1138,8 +1138,24 @@ _hidden int libxl__wait_for_offspring(libxl__gc *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 +/* + * env should be passed using the following format, + * + * env[0]: name of env variable + * env[1]: value of env variable + * env[n]: ... + * + * So it efectively becomes something like: + * export env[n]=env[n+1] + * (where n%2 = 0) + * + * The last entry of the array always has to be NULL. + * + * Logs errors, never returns. + */ +_hidden void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd, + int stderrfd, const char *arg0, char *const args[], + char *const env[]); /* from xl_create */ _hidden int libxl__domain_make(libxl__gc *gc, -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY5-00087p-EG; Thu, 10 May 2012 11:28:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY4-00086z-8a for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:44 +0000 Received: from [85.158.143.99:13321] by server-3.bemta-4.messagelabs.com id 5A/5C-05853-A66ABAF4; Thu, 10 May 2012 11:28:42 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2206 invoked from network); 10 May 2012 11:28:40 -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; 10 May 2012 11:28:40 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234742" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-MN; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:29 +0100 Message-ID: <1336649312-11198-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add another parameter to libxl__exec call that contains the environment variables to use when performing the execvp call. Changes since v3: * Use CTX instead of defining libxl_ctx *ctx. * Error checking on setenv. * Better comment on header for libxl__exec function. * Added some const-correctness. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/libxl/libxl.c | 2 +- tools/libxl/libxl_bootloader.c | 4 ++-- tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_exec.c | 20 ++++++++++++++++++-- tools/libxl/libxl_internal.h | 20 ++++++++++++++++++-- 5 files changed, 40 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 8f63941..79d7708 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1251,7 +1251,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass) args[2] = "-autopass"; } - libxl__exec(autopass_fd, -1, -1, args[0], args); + libxl__exec(gc, autopass_fd, -1, -1, args[0], args, NULL); abort(); x_fail: diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index fb1302b..0021a7b 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -359,6 +359,7 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty); STATE_AO_GC(bl->ao); int rc, r; + char *const env[] = { "TERM", "vt100", NULL }; if (bl->openpty.rc) { rc = bl->openpty.rc; @@ -452,8 +453,7 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) /* child */ r = login_tty(libxl__carefd_fd(bl->ptys[0].slave)); if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); } - setenv("TERM", "vt100", 1); - libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args); + libxl__exec(gc, -1, -1, -1, bl->args[0], (char **) bl->args, env); exit(-1); } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index b2bae68..5de3aef 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1006,7 +1006,7 @@ retry_transaction: goto out_close; if (!rc) { /* inner child */ setsid(); - libxl__exec(null, logfile_w, logfile_w, dm, args); + libxl__exec(gc, null, logfile_w, logfile_w, dm, args, NULL); } rc = 0; diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index b46b893..fba4cb4 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -66,8 +66,8 @@ static void check_open_fds(const char *what) if (badness) abort(); } -void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, - char **args) +void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd, int stderrfd, + const char *arg0, char *const args[], char *const env[]) /* call this in the child */ { if (stdinfd != -1) @@ -90,8 +90,24 @@ void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, /* 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) { + if (setenv(env[i], env[i+1], 1) < 0) { + switch (errno) { + case EINVAL: + LOGEV(ERROR, errno, "invalid env variables (%s = %s)", + env[i], env[i+1]); + break; + case ENOMEM: + libxl__alloc_failed(CTX, __func__, 0, 0); + } + goto out; + } + } + } execvp(arg0, args); +out: fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno)); _exit(-1); } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 8a90622..9ab76f8 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1138,8 +1138,24 @@ _hidden int libxl__wait_for_offspring(libxl__gc *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 +/* + * env should be passed using the following format, + * + * env[0]: name of env variable + * env[1]: value of env variable + * env[n]: ... + * + * So it efectively becomes something like: + * export env[n]=env[n+1] + * (where n%2 = 0) + * + * The last entry of the array always has to be NULL. + * + * Logs errors, never returns. + */ +_hidden void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd, + int stderrfd, const char *arg0, char *const args[], + char *const env[]); /* from xl_create */ _hidden int libxl__domain_make(libxl__gc *gc, -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY3-000872-Gp; Thu, 10 May 2012 11:28:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY1-00086s-L7 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:42 +0000 Received: from [193.109.254.147:17925] by server-7.bemta-14.messagelabs.com id E9/6F-01627-866ABAF4; Thu, 10 May 2012 11:28:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336649318!6144586!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20534 invoked from network); 10 May 2012 11:28:39 -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; 10 May 2012 11:28:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058753" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-Pt; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:32 +0100 Message-ID: <1336649312-11198-5-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 4/4] libxl: call hotplug scripts from libxl for vif X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org As the previous change already introduces most of needed machinery to call hotplug scripts from libxl, this only adds the necessary bits to call this scripts for vif interfaces also. libxl_device_nic_add has been changed to make use of the new event functionality, and the necessary vif hotplug code has been added. No changes where needed in the teardown part, since it uses exactly the same code introduced for vbd. Network devices are added after the domain model has launched, since we need the tap inteface to be present when the hotplug script is executed. PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is LIBXL_NIC_TYPE_IOEMU regardless of the guest type. Changes since v3: * Entangle network device addition with the new AO domain creation, assute that network interfaces are always added after device model creation. Make sure the same happens for stubdomain network interfaces. * Make use of the new functions LOG, LOGE, GCNEW_ARRAY... * Remove disable_xl_vif_scripts, since now it's a global option that affects both vifs and disks hotplug scripts. * Added proper handling of IOEMU type of nics, we need to execute two different hotplug scripts. Now both scripts are chained, and one is executed after the other has finished (we call the next script from the callback of the previous one). Previously we used to launch both scripts simultaneously. Changes since v2: * Added fancy functions to fetch tap and vif names, now the prefix of the tap device has been saved in a constant, called TAP_DEVICE_PREFIX. * Wait for timeout before nuking frontend xenstore entries. * Changed disable_vif_scripts to disable_xl_vif_scripts, it's easier to understand. * Default nic type set by libxl__device_nic_setdefault is VIF now (was IOEMU). * Save nic type and udev script exection inside /libxl/devices//nic// instead of saving it in the backend path. Changes since v1: * Propagated changes from previous patch (disable_udev and libxl_device_nic_add switch). * Modified udev rules to add the new env variable. * Added support for named interfaces. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/hotplug/Linux/xen-backend.rules | 6 +- tools/libxl/libxl.c | 122 ++++--------------------------- tools/libxl/libxl.h | 3 +- tools/libxl/libxl_create.c | 78 ++++++++++++++++++-- tools/libxl/libxl_device.c | 122 +++++++++++++++++++++++++++++++ tools/libxl/libxl_dm.c | 64 +++++++++++++++- tools/libxl/libxl_internal.h | 9 ++ tools/libxl/libxl_linux.c | 130 ++++++++++++++++++++++++++++++++- tools/libxl/xl_cmdimpl.c | 2 +- 9 files changed, 412 insertions(+), 124 deletions(-) diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index d55ff11..c591a3f 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scr SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", 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-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif" +SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", 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", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup" KERNEL=="evtchn", NAME="xen/%k" @@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600" KERNEL=="gntdev", NAME="xen/%k", MODE="0600" KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" -SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index b438fbf..5a681b1 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1634,123 +1634,29 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) libxl__xen_script_dir_path()) < 0 ) return ERROR_FAIL; if (!nic->nictype) - nic->nictype = LIBXL_NIC_TYPE_IOEMU; + nic->nictype = LIBXL_NIC_TYPE_VIF; return 0; } -static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, - libxl_device_nic *nic, - libxl__device *device) -{ - device->backend_devid = nic->devid; - device->backend_domid = nic->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VIF; - device->devid = nic->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VIF; - - return 0; -} - -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; - char *dompath, **l; - unsigned int nb, rc; - - rc = libxl__device_nic_setdefault(gc, nic); - if (rc) goto out; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; + int rc; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_nic_add(egc, domid, nic, device); + if (rc) { + LOGE(ERROR, "unable to add nic %s", nic->ifname); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (nic->devid == -1) { - if (!(dompath = libxl__xs_get_dompath(gc, domid))) { - rc = ERROR_FAIL; - goto out_free; - } - if (!(l = libxl__xs_directory(gc, XBT_NULL, - libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { - nic->devid = 0; - } else { - nic->devid = strtoul(l[nb - 1], NULL, 10) + 1; - } - } - - rc = libxl__device_from_nic(gc, domid, nic, &device); - if ( rc != 0 ) goto out_free; - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - if (nic->script) { - flexarray_append(back, "script"); - flexarray_append(back, nic->script[0]=='/' ? nic->script - : libxl__sprintf(gc, "%s/%s", - libxl__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))); - if (nic->ip) { - flexarray_append(back, "ip"); - flexarray_append(back, libxl__strdup(gc, nic->ip)); - } - - if (nic->rate_interval_usecs > 0) { - flexarray_append(back, "rate"); - flexarray_append(back, libxl__sprintf(gc, "%"PRIu64",%"PRIu32"", - nic->rate_bytes_per_interval, - nic->rate_interval_usecs)); - } - flexarray_append(back, "bridge"); - flexarray_append(back, libxl__strdup(gc, nic->bridge)); - flexarray_append(back, "handle"); - flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid)); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "handle"); - flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid)); - flexarray_append(front, "mac"); - flexarray_append(front, libxl__sprintf(gc, - LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - - /* FIXME: wait for plug */ - rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 0ab1531..6689baf 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -688,7 +688,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); /* Network Interfaces */ -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, + const libxl_asyncop_how *ao_how); int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index db58fd0..69f4e4d 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -605,6 +605,11 @@ static void domcreate_disk_connected(libxl__egc *egc, static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); +static void domcreate_nics_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void domcreate_attach_pci(libxl__egc *egc, + libxl__domain_create_state *dcs); + /* Our own function to clean up and call the user's callback. * The final call in the sequence if domain creation is successful. */ static void domcreate_complete(libxl__egc *egc, @@ -747,13 +752,11 @@ static void domcreate_bootloader_done(libxl__egc *egc, } } for (i = 0; i < d_config->num_vifs; i++) { - ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]); - if (ret) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "cannot add nic %d to domain: %d", i, ret); - ret = ERROR_FAIL; - goto error_out; - } + /* We have to init the nic here, because we still haven't + * called libxl_device_nic_add at this point, but qemu needs + * the nic information to be complete. + */ + libxl__device_nic_setdefault(gc, &d_config->vifs[i]); } return; @@ -885,6 +888,67 @@ static void domcreate_devmodel_started(libxl__egc *egc, } } + /* Plug nic interfaces */ + if (!ret && d_config->num_vifs > 0) { + /* Attach nics */ + GCNEW_ARRAY(dcs->devices, d_config->num_vifs); + dcs->num_devices = d_config->num_vifs; + for (i = 0; i < d_config->num_vifs; i++) { + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_nics_connected; + ret = libxl__device_nic_add(egc, domid, &d_config->vifs[i], + &dcs->devices[i]); + if (ret) { + LOGE(ERROR, "cannot add nic %d to domain: %d", i, domid); + ret = ERROR_FAIL; + goto error_out; + } + } + return; + } + + domcreate_attach_pci(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_nics_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int last, ret = 0; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting nics devices"); + goto error_out; + } + + domcreate_attach_pci(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_attach_pci(libxl__egc *egc, + libxl__domain_create_state *dcs) +{ + STATE_AO_GC(dcs->ao); + int i, ret = 0; + libxl_ctx *ctx = CTX; + int domid = dcs->guest_domid; + + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + for (i = 0; i < d_config->num_pcidevs; i++) libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1); diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 275ab43..6b431a2 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -191,6 +191,20 @@ int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, return 0; } +int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, + libxl_device_nic *nic, + libxl__device *device) +{ + device->backend_devid = nic->devid; + device->backend_domid = nic->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VIF; + device->devid = nic->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VIF; + + return 0; +} + int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm) @@ -324,6 +338,114 @@ out: return rc; } +int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, + libxl_device_nic *nic, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_nic_setdefault(gc, nic); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(18, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (nic->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + if (!(l = libxl__xs_directory(gc, XBT_NULL, GCSPRINTF("%s/device/vif", + dompath), &nb))) { + nic->devid = 0; + } else { + nic->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_nic(gc, domid, nic, device); + if (rc != 0) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + if (nic->script) { + flexarray_append(back, "script"); + flexarray_append(back, nic->script[0] == '/' ? + nic->script : + GCSPRINTF("%s/%s", 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, GCSPRINTF(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); + if (nic->ip) { + flexarray_append(back, "ip"); + flexarray_append(back, libxl__strdup(gc, nic->ip)); + } + + if (nic->rate_interval_usecs > 0) { + flexarray_append(back, "rate"); + flexarray_append(back, GCSPRINTF("%"PRIu64",%"PRIu32"", + nic->rate_bytes_per_interval, + nic->rate_interval_usecs)); + } + + flexarray_append(back, "bridge"); + flexarray_append(back, libxl__strdup(gc, nic->bridge)); + flexarray_append(back, "handle"); + flexarray_append(back, GCSPRINTF("%d", nic->devid)); + flexarray_append(back, "type"); + flexarray_append(back, GCSPRINTF("%s", + libxl_nic_type_to_string(nic->nictype))); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", nic->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, GCSPRINTF("%d", nic->devid)); + flexarray_append(front, "mac"); + flexarray_append(front, GCSPRINTF(LIBXL_MAC_FMT, + LIBXL_MAC_BYTES(nic->mac))); + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aorm->dev = device; + aorm->action = DEVICE_CONNECT; + libxl__initiate_device_add(egc, aorm); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + + typedef struct { libxl__gc *gc; libxl_device_disk *disk; diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index b2622ee..ff5f8ad 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -666,6 +666,12 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, libxl__dm_spawn_state *stubdom_dmss, int rc); +static void stubdom_nics_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc); + void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { STATE_AO_GC(sdss->dm.spawn.ao); @@ -838,9 +844,11 @@ static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) } for (i = 0; i < dm_config->num_vifs; i++) { - ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]); - if (ret) - goto out; + /* We have to init the nic here, because we still haven't + * called libxl_device_nic_add at this point, but qemu needs + * the nic information to be complete. + */ + libxl__device_nic_setdefault(gc, &dm_config->vifs[i]); } ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); if (ret) @@ -915,9 +923,59 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); STATE_AO_GC(sdss->dm.spawn.ao); uint32_t dm_domid = sdss->pvqemu.guest_domid; + libxl_domain_config *d_config = stubdom_dmss->guest_config; + int ret2, i; if (rc) goto out; + if (!rc && d_config->num_vifs > 0) { + GCNEW_ARRAY(stubdom_dmss->devices, d_config->num_vifs); + stubdom_dmss->num_devices = d_config->num_vifs; + for (i = 0; i < d_config->num_vifs; i++) { + libxl__init_ao_device(&stubdom_dmss->devices[i], ao, + &stubdom_dmss->devices); + stubdom_dmss->devices[i].callback = stubdom_nics_connected; + ret2 = libxl__device_nic_add(egc, dm_domid, &d_config->vifs[i], + &stubdom_dmss->devices[i]); + if (ret2) { + LOGE(ERROR, "cannot add nic %d to domain: %d", i, dm_domid); + rc = ERROR_FAIL; + goto out; + } + } + return; + } + +out: + stubdom_pvqemu_cb(egc, stubdom_dmss, rc); +} + +static void stubdom_nics_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__dm_spawn_state *dmss = CONTAINER_OF(aorm->base, *dmss, devices); + int last, ret = 0; + + ret = libxl__ao_device_check_last(gc, aorm, dmss->devices, + dmss->num_devices, &last); + + if (!last) return; + if (last && ret) + LOGE(ERROR, "error connecting nics devices"); + + stubdom_pvqemu_cb(egc, dmss, ret); + return; +} + +static void stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc) +{ + libxl__stub_dm_spawn_state *sdss = + CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); + STATE_AO_GC(sdss->dm.spawn.ao); + uint32_t dm_domid = sdss->pvqemu.guest_domid; + rc = libxl_domain_unpause(CTX, dm_domid); if (rc) goto out; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index faeb965..91eba63 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -782,6 +782,9 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); +_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, + libxl_device_nic *nic, + libxl__device *device); _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, libxl_device_disk *disk, libxl__device *device); @@ -965,6 +968,7 @@ struct libxl__ao_device { libxl__device_callback *callback; /* private for implementation */ int rc; + int vif_executed; libxl__ev_time ev; libxl__ev_child child; libxl__ev_devstate ds; @@ -974,6 +978,9 @@ struct libxl__ao_device { _hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm); +_hidden int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, + libxl_device_nic *nic, + libxl__ao_device *aorm); /* *----- spawn ----- @@ -1147,6 +1154,8 @@ struct libxl__dm_spawn_state { libxl_domain_config *guest_config; libxl__domain_build_state *build_state; /* relates to guest_domid */ libxl__dm_spawn_cb *callback; + libxl__ao_device *devices; + int num_devices; }; _hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*); diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 315ce15..6e752bd 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -28,6 +28,26 @@ int libxl__try_phy_backend(mode_t st_mode) /* Hotplug scripts helpers */ +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev) +{ + char *snictype, *be_path; + libxl_nic_type nictype; + + be_path = libxl__device_backend_path(gc, dev); + snictype = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "type")); + if (!snictype) { + LOGE(ERROR, "unable to read nictype from %s", be_path); + return -1; + } + if (libxl_nic_type_from_string(snictype, &nictype) < 0) { + LOGE(ERROR, "unable to parse nictype from %s", be_path); + return -1; + } + + return nictype; +} + static void cleanup(libxl__gc *gc, libxl__ao_device *aorm) { if (!aorm) return; @@ -47,7 +67,18 @@ static void callback(libxl__egc *egc, libxl__ev_child *child, : LIBXL__LOG_WARNING, aorm->what, pid, status); aorm->rc = ERROR_FAIL; + goto out; + } + + if (aorm->dev->backend_kind == LIBXL__DEVICE_KIND_VIF && + get_nic_type(gc, aorm->dev) == LIBXL_NIC_TYPE_IOEMU && + !aorm->vif_executed) { + aorm->vif_executed = 1; + libxl__device_hotplug(egc, aorm); + return; } + +out: aorm->callback(egc, aorm); } @@ -66,7 +97,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) return NULL; } - GCNEW_ARRAY(env, 9); + GCNEW_ARRAY(env, 13); env[nr++] = "script"; env[nr++] = script; env[nr++] = "XENBUS_TYPE"; @@ -75,6 +106,24 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid); env[nr++] = "XENBUS_BASE_PATH"; env[nr++] = "backend"; + if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) { + switch (get_nic_type(gc, dev)) { + case LIBXL_NIC_TYPE_IOEMU: + env[nr++] = "INTERFACE"; + env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc, + dev->domid, dev->devid, + LIBXL_NIC_TYPE_IOEMU)); + case LIBXL_NIC_TYPE_VIF: + env[nr++] = "vif"; + env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc, + dev->domid, dev->devid, + LIBXL_NIC_TYPE_VIF)); + break; + default: + return NULL; + } + } + env[nr++] = NULL; return env; @@ -119,6 +168,81 @@ out_free: return rc; } +static int libxl__hotplug_nic(libxl__gc *gc, libxl__ao_device *aorm) +{ + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *what, *script; + char **args, **env; + int nr = 0, rc = 0; + libxl_nic_type nictype; + + script = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/%s", be_path, + "script")); + if (!script) { + LOGE(ERROR, "unable to read script from %s", be_path); + return -1; + } + + nictype = get_nic_type(gc, aorm->dev); + if (nictype < 0) { + LOGE(ERROR, "error when fetching nic type"); + return -1; + } + + env = get_hotplug_env(gc, aorm->dev); + if (!env) + return -1; + + GCNEW_ARRAY(args, 4); + + switch (nictype) { + case LIBXL_NIC_TYPE_IOEMU: + if (!aorm->vif_executed) goto execute_vif; + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "add" : "remove"; + args[nr++] = libxl__strdup(gc, "type_if=tap"); + args[nr++] = NULL; + what = GCSPRINTF("%s %s", args[0], aorm->action == DEVICE_CONNECT ? + "connect" : "disconnect"); + LOG(DEBUG, "Calling hotplug script: %s %s %s", + args[0], args[1], args[2]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + LOGE(ERROR, "unable execute hotplug scripts for vif device %"PRIu32, + aorm->dev->devid); + goto out; + } + break; + case LIBXL_NIC_TYPE_VIF: +execute_vif: + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "online" : "offline"; + args[nr++] = libxl__strdup(gc, "type_if=vif"); + args[nr++] = NULL; + what = GCSPRINTF("%s %s", args[0], aorm->action == DEVICE_CONNECT ? + "connect" : "disconnect"); + LOG(DEBUG, "Calling hotplug script: %s %s %s", + args[0], args[1], args[2]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + LOGE(ERROR, "unable execute hotplug scripts for vif device %"PRIu32, + aorm->dev->devid); + goto out; + } + break; + default: + /* Unknown network type */ + LOG(DEBUG, "unknown network card type with id %"PRIu32, + aorm->dev->devid); + return 0; + } + + rc = 0; + +out: + return rc; +} + void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) { STATE_AO_GC(aorm->ao); @@ -132,6 +256,10 @@ void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) aorm->rc = libxl__hotplug_disk(gc, aorm); if (aorm->rc) goto error; break; + case LIBXL__DEVICE_KIND_VIF: + aorm->rc = libxl__hotplug_nic(gc, aorm); + if (aorm->rc) goto error; + break; default: /* If no need to execute any hotplug scripts, * call the callback manually diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 3f1bbf6..162bb82 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -4967,7 +4967,7 @@ int main_networkattach(int argc, char **argv) return 0; } - if (libxl_device_nic_add(ctx, domid, &nic)) { + if (libxl_device_nic_add(ctx, domid, &nic, 0)) { fprintf(stderr, "libxl_device_nic_add failed.\n"); return 1; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY3-000872-Gp; Thu, 10 May 2012 11:28:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY1-00086s-L7 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:42 +0000 Received: from [193.109.254.147:17925] by server-7.bemta-14.messagelabs.com id E9/6F-01627-866ABAF4; Thu, 10 May 2012 11:28:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336649318!6144586!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20534 invoked from network); 10 May 2012 11:28:39 -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; 10 May 2012 11:28:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058753" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-Pt; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:32 +0100 Message-ID: <1336649312-11198-5-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 4/4] libxl: call hotplug scripts from libxl for vif X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org As the previous change already introduces most of needed machinery to call hotplug scripts from libxl, this only adds the necessary bits to call this scripts for vif interfaces also. libxl_device_nic_add has been changed to make use of the new event functionality, and the necessary vif hotplug code has been added. No changes where needed in the teardown part, since it uses exactly the same code introduced for vbd. Network devices are added after the domain model has launched, since we need the tap inteface to be present when the hotplug script is executed. PV nic devices are set to LIBXL_NIC_TYPE_VIF, since the default value is LIBXL_NIC_TYPE_IOEMU regardless of the guest type. Changes since v3: * Entangle network device addition with the new AO domain creation, assute that network interfaces are always added after device model creation. Make sure the same happens for stubdomain network interfaces. * Make use of the new functions LOG, LOGE, GCNEW_ARRAY... * Remove disable_xl_vif_scripts, since now it's a global option that affects both vifs and disks hotplug scripts. * Added proper handling of IOEMU type of nics, we need to execute two different hotplug scripts. Now both scripts are chained, and one is executed after the other has finished (we call the next script from the callback of the previous one). Previously we used to launch both scripts simultaneously. Changes since v2: * Added fancy functions to fetch tap and vif names, now the prefix of the tap device has been saved in a constant, called TAP_DEVICE_PREFIX. * Wait for timeout before nuking frontend xenstore entries. * Changed disable_vif_scripts to disable_xl_vif_scripts, it's easier to understand. * Default nic type set by libxl__device_nic_setdefault is VIF now (was IOEMU). * Save nic type and udev script exection inside /libxl/devices//nic// instead of saving it in the backend path. Changes since v1: * Propagated changes from previous patch (disable_udev and libxl_device_nic_add switch). * Modified udev rules to add the new env variable. * Added support for named interfaces. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/hotplug/Linux/xen-backend.rules | 6 +- tools/libxl/libxl.c | 122 ++++--------------------------- tools/libxl/libxl.h | 3 +- tools/libxl/libxl_create.c | 78 ++++++++++++++++++-- tools/libxl/libxl_device.c | 122 +++++++++++++++++++++++++++++++ tools/libxl/libxl_dm.c | 64 +++++++++++++++- tools/libxl/libxl_internal.h | 9 ++ tools/libxl/libxl_linux.c | 130 ++++++++++++++++++++++++++++++++- tools/libxl/xl_cmdimpl.c | 2 +- 9 files changed, 412 insertions(+), 124 deletions(-) diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index d55ff11..c591a3f 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -2,8 +2,8 @@ SUBSYSTEM=="xen-backend", KERNEL=="tap*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scr SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", 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-*", ENV{UDEV_CALL}="1", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif" +SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ENV{UDEV_CALL}="1", 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", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/xen-hotplug-cleanup" KERNEL=="evtchn", NAME="xen/%k" @@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600" KERNEL=="gntdev", NAME="xen/%k", MODE="0600" KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" -SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index b438fbf..5a681b1 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1634,123 +1634,29 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic) libxl__xen_script_dir_path()) < 0 ) return ERROR_FAIL; if (!nic->nictype) - nic->nictype = LIBXL_NIC_TYPE_IOEMU; + nic->nictype = LIBXL_NIC_TYPE_VIF; return 0; } -static int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, - libxl_device_nic *nic, - libxl__device *device) -{ - device->backend_devid = nic->devid; - device->backend_domid = nic->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VIF; - device->devid = nic->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VIF; - - return 0; -} - -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic) +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; - char *dompath, **l; - unsigned int nb, rc; - - rc = libxl__device_nic_setdefault(gc, nic); - if (rc) goto out; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; + int rc; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_nic_add(egc, domid, nic, device); + if (rc) { + LOGE(ERROR, "unable to add nic %s", nic->ifname); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (nic->devid == -1) { - if (!(dompath = libxl__xs_get_dompath(gc, domid))) { - rc = ERROR_FAIL; - goto out_free; - } - if (!(l = libxl__xs_directory(gc, XBT_NULL, - libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { - nic->devid = 0; - } else { - nic->devid = strtoul(l[nb - 1], NULL, 10) + 1; - } - } - - rc = libxl__device_from_nic(gc, domid, nic, &device); - if ( rc != 0 ) goto out_free; - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - if (nic->script) { - flexarray_append(back, "script"); - flexarray_append(back, nic->script[0]=='/' ? nic->script - : libxl__sprintf(gc, "%s/%s", - libxl__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))); - if (nic->ip) { - flexarray_append(back, "ip"); - flexarray_append(back, libxl__strdup(gc, nic->ip)); - } - - if (nic->rate_interval_usecs > 0) { - flexarray_append(back, "rate"); - flexarray_append(back, libxl__sprintf(gc, "%"PRIu64",%"PRIu32"", - nic->rate_bytes_per_interval, - nic->rate_interval_usecs)); - } - flexarray_append(back, "bridge"); - flexarray_append(back, libxl__strdup(gc, nic->bridge)); - flexarray_append(back, "handle"); - flexarray_append(back, libxl__sprintf(gc, "%d", nic->devid)); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", nic->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "handle"); - flexarray_append(front, libxl__sprintf(gc, "%d", nic->devid)); - flexarray_append(front, "mac"); - flexarray_append(front, libxl__sprintf(gc, - LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - - /* FIXME: wait for plug */ - rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 0ab1531..6689baf 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -688,7 +688,8 @@ char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk *disk); int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk); /* Network Interfaces */ -int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic); +int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, + const libxl_asyncop_how *ao_how); int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index db58fd0..69f4e4d 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -605,6 +605,11 @@ static void domcreate_disk_connected(libxl__egc *egc, static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); +static void domcreate_nics_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void domcreate_attach_pci(libxl__egc *egc, + libxl__domain_create_state *dcs); + /* Our own function to clean up and call the user's callback. * The final call in the sequence if domain creation is successful. */ static void domcreate_complete(libxl__egc *egc, @@ -747,13 +752,11 @@ static void domcreate_bootloader_done(libxl__egc *egc, } } for (i = 0; i < d_config->num_vifs; i++) { - ret = libxl_device_nic_add(ctx, domid, &d_config->vifs[i]); - if (ret) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "cannot add nic %d to domain: %d", i, ret); - ret = ERROR_FAIL; - goto error_out; - } + /* We have to init the nic here, because we still haven't + * called libxl_device_nic_add at this point, but qemu needs + * the nic information to be complete. + */ + libxl__device_nic_setdefault(gc, &d_config->vifs[i]); } return; @@ -885,6 +888,67 @@ static void domcreate_devmodel_started(libxl__egc *egc, } } + /* Plug nic interfaces */ + if (!ret && d_config->num_vifs > 0) { + /* Attach nics */ + GCNEW_ARRAY(dcs->devices, d_config->num_vifs); + dcs->num_devices = d_config->num_vifs; + for (i = 0; i < d_config->num_vifs; i++) { + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_nics_connected; + ret = libxl__device_nic_add(egc, domid, &d_config->vifs[i], + &dcs->devices[i]); + if (ret) { + LOGE(ERROR, "cannot add nic %d to domain: %d", i, domid); + ret = ERROR_FAIL; + goto error_out; + } + } + return; + } + + domcreate_attach_pci(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_nics_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int last, ret = 0; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting nics devices"); + goto error_out; + } + + domcreate_attach_pci(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_attach_pci(libxl__egc *egc, + libxl__domain_create_state *dcs) +{ + STATE_AO_GC(dcs->ao); + int i, ret = 0; + libxl_ctx *ctx = CTX; + int domid = dcs->guest_domid; + + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + for (i = 0; i < d_config->num_pcidevs; i++) libxl__device_pci_add(gc, domid, &d_config->pcidevs[i], 1); diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 275ab43..6b431a2 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -191,6 +191,20 @@ int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, return 0; } +int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, + libxl_device_nic *nic, + libxl__device *device) +{ + device->backend_devid = nic->devid; + device->backend_domid = nic->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VIF; + device->devid = nic->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VIF; + + return 0; +} + int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm) @@ -324,6 +338,114 @@ out: return rc; } +int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, + libxl_device_nic *nic, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_nic_setdefault(gc, nic); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(18, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (nic->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + if (!(l = libxl__xs_directory(gc, XBT_NULL, GCSPRINTF("%s/device/vif", + dompath), &nb))) { + nic->devid = 0; + } else { + nic->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_nic(gc, domid, nic, device); + if (rc != 0) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + if (nic->script) { + flexarray_append(back, "script"); + flexarray_append(back, nic->script[0] == '/' ? + nic->script : + GCSPRINTF("%s/%s", 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, GCSPRINTF(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac))); + if (nic->ip) { + flexarray_append(back, "ip"); + flexarray_append(back, libxl__strdup(gc, nic->ip)); + } + + if (nic->rate_interval_usecs > 0) { + flexarray_append(back, "rate"); + flexarray_append(back, GCSPRINTF("%"PRIu64",%"PRIu32"", + nic->rate_bytes_per_interval, + nic->rate_interval_usecs)); + } + + flexarray_append(back, "bridge"); + flexarray_append(back, libxl__strdup(gc, nic->bridge)); + flexarray_append(back, "handle"); + flexarray_append(back, GCSPRINTF("%d", nic->devid)); + flexarray_append(back, "type"); + flexarray_append(back, GCSPRINTF("%s", + libxl_nic_type_to_string(nic->nictype))); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", nic->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, GCSPRINTF("%d", nic->devid)); + flexarray_append(front, "mac"); + flexarray_append(front, GCSPRINTF(LIBXL_MAC_FMT, + LIBXL_MAC_BYTES(nic->mac))); + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aorm->dev = device; + aorm->action = DEVICE_CONNECT; + libxl__initiate_device_add(egc, aorm); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + + typedef struct { libxl__gc *gc; libxl_device_disk *disk; diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index b2622ee..ff5f8ad 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -666,6 +666,12 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, libxl__dm_spawn_state *stubdom_dmss, int rc); +static void stubdom_nics_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc); + void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { STATE_AO_GC(sdss->dm.spawn.ao); @@ -838,9 +844,11 @@ static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) } for (i = 0; i < dm_config->num_vifs; i++) { - ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]); - if (ret) - goto out; + /* We have to init the nic here, because we still haven't + * called libxl_device_nic_add at this point, but qemu needs + * the nic information to be complete. + */ + libxl__device_nic_setdefault(gc, &dm_config->vifs[i]); } ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); if (ret) @@ -915,9 +923,59 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); STATE_AO_GC(sdss->dm.spawn.ao); uint32_t dm_domid = sdss->pvqemu.guest_domid; + libxl_domain_config *d_config = stubdom_dmss->guest_config; + int ret2, i; if (rc) goto out; + if (!rc && d_config->num_vifs > 0) { + GCNEW_ARRAY(stubdom_dmss->devices, d_config->num_vifs); + stubdom_dmss->num_devices = d_config->num_vifs; + for (i = 0; i < d_config->num_vifs; i++) { + libxl__init_ao_device(&stubdom_dmss->devices[i], ao, + &stubdom_dmss->devices); + stubdom_dmss->devices[i].callback = stubdom_nics_connected; + ret2 = libxl__device_nic_add(egc, dm_domid, &d_config->vifs[i], + &stubdom_dmss->devices[i]); + if (ret2) { + LOGE(ERROR, "cannot add nic %d to domain: %d", i, dm_domid); + rc = ERROR_FAIL; + goto out; + } + } + return; + } + +out: + stubdom_pvqemu_cb(egc, stubdom_dmss, rc); +} + +static void stubdom_nics_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__dm_spawn_state *dmss = CONTAINER_OF(aorm->base, *dmss, devices); + int last, ret = 0; + + ret = libxl__ao_device_check_last(gc, aorm, dmss->devices, + dmss->num_devices, &last); + + if (!last) return; + if (last && ret) + LOGE(ERROR, "error connecting nics devices"); + + stubdom_pvqemu_cb(egc, dmss, ret); + return; +} + +static void stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc) +{ + libxl__stub_dm_spawn_state *sdss = + CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); + STATE_AO_GC(sdss->dm.spawn.ao); + uint32_t dm_domid = sdss->pvqemu.guest_domid; + rc = libxl_domain_unpause(CTX, dm_domid); if (rc) goto out; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index faeb965..91eba63 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -782,6 +782,9 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); +_hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, + libxl_device_nic *nic, + libxl__device *device); _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, libxl_device_disk *disk, libxl__device *device); @@ -965,6 +968,7 @@ struct libxl__ao_device { libxl__device_callback *callback; /* private for implementation */ int rc; + int vif_executed; libxl__ev_time ev; libxl__ev_child child; libxl__ev_devstate ds; @@ -974,6 +978,9 @@ struct libxl__ao_device { _hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm); +_hidden int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, + libxl_device_nic *nic, + libxl__ao_device *aorm); /* *----- spawn ----- @@ -1147,6 +1154,8 @@ struct libxl__dm_spawn_state { libxl_domain_config *guest_config; libxl__domain_build_state *build_state; /* relates to guest_domid */ libxl__dm_spawn_cb *callback; + libxl__ao_device *devices; + int num_devices; }; _hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*); diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 315ce15..6e752bd 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -28,6 +28,26 @@ int libxl__try_phy_backend(mode_t st_mode) /* Hotplug scripts helpers */ +static libxl_nic_type get_nic_type(libxl__gc *gc, libxl__device *dev) +{ + char *snictype, *be_path; + libxl_nic_type nictype; + + be_path = libxl__device_backend_path(gc, dev); + snictype = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "type")); + if (!snictype) { + LOGE(ERROR, "unable to read nictype from %s", be_path); + return -1; + } + if (libxl_nic_type_from_string(snictype, &nictype) < 0) { + LOGE(ERROR, "unable to parse nictype from %s", be_path); + return -1; + } + + return nictype; +} + static void cleanup(libxl__gc *gc, libxl__ao_device *aorm) { if (!aorm) return; @@ -47,7 +67,18 @@ static void callback(libxl__egc *egc, libxl__ev_child *child, : LIBXL__LOG_WARNING, aorm->what, pid, status); aorm->rc = ERROR_FAIL; + goto out; + } + + if (aorm->dev->backend_kind == LIBXL__DEVICE_KIND_VIF && + get_nic_type(gc, aorm->dev) == LIBXL_NIC_TYPE_IOEMU && + !aorm->vif_executed) { + aorm->vif_executed = 1; + libxl__device_hotplug(egc, aorm); + return; } + +out: aorm->callback(egc, aorm); } @@ -66,7 +97,7 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) return NULL; } - GCNEW_ARRAY(env, 9); + GCNEW_ARRAY(env, 13); env[nr++] = "script"; env[nr++] = script; env[nr++] = "XENBUS_TYPE"; @@ -75,6 +106,24 @@ static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid); env[nr++] = "XENBUS_BASE_PATH"; env[nr++] = "backend"; + if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) { + switch (get_nic_type(gc, dev)) { + case LIBXL_NIC_TYPE_IOEMU: + env[nr++] = "INTERFACE"; + env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc, + dev->domid, dev->devid, + LIBXL_NIC_TYPE_IOEMU)); + case LIBXL_NIC_TYPE_VIF: + env[nr++] = "vif"; + env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc, + dev->domid, dev->devid, + LIBXL_NIC_TYPE_VIF)); + break; + default: + return NULL; + } + } + env[nr++] = NULL; return env; @@ -119,6 +168,81 @@ out_free: return rc; } +static int libxl__hotplug_nic(libxl__gc *gc, libxl__ao_device *aorm) +{ + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *what, *script; + char **args, **env; + int nr = 0, rc = 0; + libxl_nic_type nictype; + + script = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/%s", be_path, + "script")); + if (!script) { + LOGE(ERROR, "unable to read script from %s", be_path); + return -1; + } + + nictype = get_nic_type(gc, aorm->dev); + if (nictype < 0) { + LOGE(ERROR, "error when fetching nic type"); + return -1; + } + + env = get_hotplug_env(gc, aorm->dev); + if (!env) + return -1; + + GCNEW_ARRAY(args, 4); + + switch (nictype) { + case LIBXL_NIC_TYPE_IOEMU: + if (!aorm->vif_executed) goto execute_vif; + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "add" : "remove"; + args[nr++] = libxl__strdup(gc, "type_if=tap"); + args[nr++] = NULL; + what = GCSPRINTF("%s %s", args[0], aorm->action == DEVICE_CONNECT ? + "connect" : "disconnect"); + LOG(DEBUG, "Calling hotplug script: %s %s %s", + args[0], args[1], args[2]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + LOGE(ERROR, "unable execute hotplug scripts for vif device %"PRIu32, + aorm->dev->devid); + goto out; + } + break; + case LIBXL_NIC_TYPE_VIF: +execute_vif: + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "online" : "offline"; + args[nr++] = libxl__strdup(gc, "type_if=vif"); + args[nr++] = NULL; + what = GCSPRINTF("%s %s", args[0], aorm->action == DEVICE_CONNECT ? + "connect" : "disconnect"); + LOG(DEBUG, "Calling hotplug script: %s %s %s", + args[0], args[1], args[2]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + LOGE(ERROR, "unable execute hotplug scripts for vif device %"PRIu32, + aorm->dev->devid); + goto out; + } + break; + default: + /* Unknown network type */ + LOG(DEBUG, "unknown network card type with id %"PRIu32, + aorm->dev->devid); + return 0; + } + + rc = 0; + +out: + return rc; +} + void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) { STATE_AO_GC(aorm->ao); @@ -132,6 +256,10 @@ void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) aorm->rc = libxl__hotplug_disk(gc, aorm); if (aorm->rc) goto error; break; + case LIBXL__DEVICE_KIND_VIF: + aorm->rc = libxl__hotplug_nic(gc, aorm); + if (aorm->rc) goto error; + break; default: /* If no need to execute any hotplug scripts, * call the callback manually diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 3f1bbf6..162bb82 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -4967,7 +4967,7 @@ int main_networkattach(int argc, char **argv) return 0; } - if (libxl_device_nic_add(ctx, domid, &nic)) { + if (libxl_device_nic_add(ctx, domid, &nic, 0)) { fprintf(stderr, "libxl_device_nic_add failed.\n"); return 1; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY6-00088G-R7; Thu, 10 May 2012 11:28:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY4-00086z-Ui for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:45 +0000 Received: from [85.158.143.99:13353] by server-3.bemta-4.messagelabs.com id 4E/5C-05853-B66ABAF4; Thu, 10 May 2012 11:28:43 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2315 invoked from network); 10 May 2012 11:28:41 -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; 10 May 2012 11:28:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234743" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-Mw; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:30 +0100 Message-ID: <1336649312-11198-3-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add a function which behaves like "xenstore-rm -t", and which will be used to clean xenstore after unplug since we will be no longer executing xen-hotplug-cleanup script, that used to do that for us. Changes since v3: * Better error checking and function description. Changes since v2: * Moved the function to libxl_xshelp.c and added the prototype to libxl_internal.h. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_internal.h | 7 +++++++ tools/libxl/libxl_xshelp.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9ab76f8..fc2024d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -494,6 +494,13 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid); +/* + * This is a recursive delete, from top to bottom. What this function does + * is remove empty folders that contained the deleted entry. + * + * It mimics xenstore-rm -t behaviour. + */ +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *user_path); /* * Event generation functions provided by the libxl event core to the diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c index 3ea8d08..7339236 100644 --- a/tools/libxl/libxl_xshelp.c +++ b/tools/libxl/libxl_xshelp.c @@ -135,6 +135,36 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid) return s; } +int libxl__xs_path_cleanup(libxl__gc *gc, char *user_path) +{ + unsigned int nb = 0; + char *path, *last; + + if (!user_path) { + LOGE(ERROR, "null path provided"); + return ERROR_FAIL; + } + + path = libxl__strdup(gc, user_path); + xs_rm(CTX->xsh, XBT_NULL, path); + + for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) { + *last = '\0'; + + if (!strlen(path)) break; + + if (!libxl__xs_directory(gc, XBT_NULL, path, &nb)) { + LOG(DEBUG, "failed to read directory contents of %s", path); + return ERROR_FAIL; + } + + if (nb == 0) { + xs_rm(CTX->xsh, XBT_NULL, path); + } + } + return 0; +} + /* * Local variables: * mode: C -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY5-00087a-2q; Thu, 10 May 2012 11:28:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY3-00086z-N6 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:43 +0000 Received: from [85.158.143.99:21594] by server-3.bemta-4.messagelabs.com id 0A/5C-05853-A66ABAF4; Thu, 10 May 2012 11:28:42 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2137 invoked from network); 10 May 2012 11:28:39 -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; 10 May 2012 11:28:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234741" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-KH for xen-devel@lists.xen.org; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:28 +0100 Message-ID: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v4 0/4] libxl: call hotplug scripts from libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series removes the use of udev rules to call hotplug scripts when using libxl. Scripts are directly called from the toolstack at the necessary points, making use of the new event library and it's fork support. They should be applied after IanJ v8 "libxl: subprocess handling" and IanC "libxl/xend: name tap devices vifX.Y-emu". This version (v4) introduces many changes, and makes proper use of the event library. It entangles device addition with domain creation, following IanJ changes to domain creation, and also introduces AO operations to domain destruction and specifically to device teardown. Many changes are introduced, and also a lot of code motion, since libxl_device_{disk,nic}_add are now mere wrappers arround their respective libxl__device_{disk,nic}_add counterparts, which can be called within an already running AO operation, and perform all the work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY6-00088G-R7; Thu, 10 May 2012 11:28:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY4-00086z-Ui for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:45 +0000 Received: from [85.158.143.99:13353] by server-3.bemta-4.messagelabs.com id 4E/5C-05853-B66ABAF4; Thu, 10 May 2012 11:28:43 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2315 invoked from network); 10 May 2012 11:28:41 -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; 10 May 2012 11:28:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234743" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-Mw; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:30 +0100 Message-ID: <1336649312-11198-3-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add a function which behaves like "xenstore-rm -t", and which will be used to clean xenstore after unplug since we will be no longer executing xen-hotplug-cleanup script, that used to do that for us. Changes since v3: * Better error checking and function description. Changes since v2: * Moved the function to libxl_xshelp.c and added the prototype to libxl_internal.h. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_internal.h | 7 +++++++ tools/libxl/libxl_xshelp.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9ab76f8..fc2024d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -494,6 +494,13 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid); +/* + * This is a recursive delete, from top to bottom. What this function does + * is remove empty folders that contained the deleted entry. + * + * It mimics xenstore-rm -t behaviour. + */ +_hidden int libxl__xs_path_cleanup(libxl__gc *gc, char *user_path); /* * Event generation functions provided by the libxl event core to the diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c index 3ea8d08..7339236 100644 --- a/tools/libxl/libxl_xshelp.c +++ b/tools/libxl/libxl_xshelp.c @@ -135,6 +135,36 @@ char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid) return s; } +int libxl__xs_path_cleanup(libxl__gc *gc, char *user_path) +{ + unsigned int nb = 0; + char *path, *last; + + if (!user_path) { + LOGE(ERROR, "null path provided"); + return ERROR_FAIL; + } + + path = libxl__strdup(gc, user_path); + xs_rm(CTX->xsh, XBT_NULL, path); + + for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) { + *last = '\0'; + + if (!strlen(path)) break; + + if (!libxl__xs_directory(gc, XBT_NULL, path, &nb)) { + LOG(DEBUG, "failed to read directory contents of %s", path); + return ERROR_FAIL; + } + + if (nb == 0) { + xs_rm(CTX->xsh, XBT_NULL, path); + } + } + return 0; +} + /* * Local variables: * mode: C -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRY5-00087a-2q; Thu, 10 May 2012 11:28:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY3-00086z-N6 for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:43 +0000 Received: from [85.158.143.99:21594] by server-3.bemta-4.messagelabs.com id 0A/5C-05853-A66ABAF4; Thu, 10 May 2012 11:28:42 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336649317!26447743!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2137 invoked from network); 10 May 2012 11:28:39 -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; 10 May 2012 11:28:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234741" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-KH for xen-devel@lists.xen.org; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:28 +0100 Message-ID: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v4 0/4] libxl: call hotplug scripts from libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series removes the use of udev rules to call hotplug scripts when using libxl. Scripts are directly called from the toolstack at the necessary points, making use of the new event library and it's fork support. They should be applied after IanJ v8 "libxl: subprocess handling" and IanC "libxl/xend: name tap devices vifX.Y-emu". This version (v4) introduces many changes, and makes proper use of the event library. It entangles device addition with domain creation, following IanJ changes to domain creation, and also introduces AO operations to domain destruction and specifically to device teardown. Many changes are introduced, and also a lot of code motion, since libxl_device_{disk,nic}_add are now mere wrappers arround their respective libxl__device_{disk,nic}_add counterparts, which can be called within an already running AO operation, and perform all the work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:28:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY8-00088h-9J; Thu, 10 May 2012 11:28:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY5-00087k-Tw for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:46 +0000 Received: from [85.158.143.35:53320] by server-1.bemta-4.messagelabs.com id 16/F8-20925-D66ABAF4; Thu, 10 May 2012 11:28:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336649320!11599598!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17354 invoked from network); 10 May 2012 11:28:42 -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 May 2012 11:28:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234744" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:38 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-On; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:31 +0100 Message-ID: <1336649312-11198-4-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a rather big change, that adds the necessary machinery to perform hotplug script calling from libxl for Linux. This patch launches the necessary scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug scripts). Here's a list of the major changes introduced: * libxl_device_disk_add makes use of the new event library and takes the optional parameter libxl_asyncop_how, to choose how the operation has to be issued (sync or async). * Disk addition waits for backend to switch to state 2 (XenbusInitWait) and then launches the hotplug script. * Created and internal function (libxl__device_disk_add), that can be called within an already running AO, and that will plug the requested disk and execute the callback afterward. libxl_device_disk_add is a user of this newly created function. * libxl__devices_destroy no longer calls libxl__device_destroy, and instead calls libxl__initiate_device_remove, so we can disconnect the device and execute the necessary hotplug scripts instead of just deleting the backend entries. So libxl__devices_destroy now uses the event library, and so does libxl_domain_destroy, that has been converted to an AO operation function * The internal API for hotplug scripts has been added, which consists of one function; libxl__device_hotplug that takes the device and a struct with the necessary info about the action to execute. * Linux hotplug scripts are called by setting the necessary env variables to emulate udev rules, so there's no need to change them (although a rework to pass this as parameters insted of env variables would be suitable, so both NetBSD and Linux hotplug scripts take the same parameters). * Added a check in xen-hotplug-common.sh, so scripts are only executed from udev when using xend. xl adds a disable_udev=1 to xenstore libxl local directory and with the modification of the udev rules every call from udev gets UDEV_CALL passed, that points to disable_udev. If UDEV_CALL is passed and points to a value, the hotplug script is not executed. Changes since v3 (changes based on IanJ review): * Store disable_udev in libxl/disable_udev, which now is not device dependant, but backend domain dependant. * Added a global callback to device addition/destruction, that is now called when we have finished all the oprtations and handles the call to ao_complete if no other operations are pending. * Unified both device creation/destruction flows, so now all of them use the same data structure and callbacks. * Used the event interface in a proper way, and merged disk addition with the new async flow of the domain creation. * Make use of the new functions LOG, LOGE, GCNEW_ARRAY... * Passed NULL as ao_how in Python bindings. Changes since v1: * Replaced the hotplug snippet that prevents execution from udev when necessary, and now we set the env var from udev rules instead of libxl. * Replaced the libxl_device_disk_add "if" with a "switch". * Removed libxl__xs_path_cleanup (replaced with xs_rm). * Fixed several spelling mistakes. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- docs/man/xl.conf.pod.5 | 8 + tools/examples/xl.conf | 5 + tools/hotplug/Linux/xen-backend.rules | 6 +- tools/hotplug/Linux/xen-hotplug-common.sh | 6 + tools/libxl/Makefile | 3 +- tools/libxl/libxl.c | 351 +++++++-------------- tools/libxl/libxl.h | 7 +- tools/libxl/libxl_create.c | 102 ++++++- tools/libxl/libxl_device.c | 497 +++++++++++++++++++++++++---- tools/libxl/libxl_dm.c | 136 +++++---- tools/libxl/libxl_dom.c | 170 ++++++++++ tools/libxl/libxl_hotplug.c | 84 +++++ tools/libxl/libxl_internal.h | 170 ++++++++++- tools/libxl/libxl_linux.c | 126 ++++++++ tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 4 + tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 15 +- tools/python/xen/lowlevel/xl/xl.c | 2 +- 19 files changed, 1291 insertions(+), 403 deletions(-) create mode 100644 tools/libxl/libxl_hotplug.c diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5 index 8bd45ea..72825a0 100644 --- a/docs/man/xl.conf.pod.5 +++ b/docs/man/xl.conf.pod.5 @@ -55,6 +55,14 @@ default. Default: C<1> +=item B + +If disabled hotplug scripts will be called from udev, as it used to +be in the previous releases. With the default option, hotplug scripts +will be launched by xl directly. + +Default: C<1> + =item B Sets the path to the lock file used by xl to serialise certain diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf index 56d3b3b..75b00e0 100644 --- a/tools/examples/xl.conf +++ b/tools/examples/xl.conf @@ -12,3 +12,8 @@ # default output format used by "xl list -l" #output_format="json" + +# default option to run hotplug scripts from xl +# if disabled the old behaviour will be used, and hotplug scripts will be +# launched by udev. +#run_hotplug_scripts=1 diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index 405387f..d55ff11 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -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*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}" +SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif" SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif" SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}" -SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup" +SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", 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 --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh index 8f6557d..6443a63 100644 --- a/tools/hotplug/Linux/xen-hotplug-common.sh +++ b/tools/hotplug/Linux/xen-hotplug-common.sh @@ -15,6 +15,12 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # +# Hack to prevent the execution of hotplug scripts from udev if the domain +# has been launched from libxl +if [ -n "${UDEV_CALL}" ] && \ + `xenstore-read "libxl/disable_udev" >/dev/null 2>&1`; then + exit 0 +fi dir=$(dirname "$0") . "$dir/hotplugpath.sh" diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 5d9227e..9abadff 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -66,7 +66,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o \ libxl_json.o libxl_aoutils.o \ - libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) + libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.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) -include $(XEN_ROOT)/tools/config.h diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 79d7708..b438fbf 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1058,82 +1058,36 @@ 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); - char *dom_path; - char *vm_path; - char *pid; - int rc, dm_present; +/* Callback for domain destruction */ - rc = libxl_domain_info(ctx, NULL, domid); - switch(rc) { - case 0: - break; - case ERROR_INVAL: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid); - default: - return rc; - } +static void domain_destroy_cb(libxl__egc *, libxl__domain_destroy_state *, int); - switch (libxl__domain_type(gc, domid)) { - case LIBXL_DOMAIN_TYPE_HVM: - dm_present = 1; - break; - case LIBXL_DOMAIN_TYPE_PV: - pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); - dm_present = (pid != NULL); - break; - default: - abort(); - } - - dom_path = libxl__xs_get_dompath(gc, domid); - if (!dom_path) { - rc = ERROR_FAIL; - goto out; - } - - if (libxl__device_pci_destroy_all(gc, domid) < 0) - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid); - rc = xc_domain_pause(ctx->xch, domid); - if (rc < 0) { - LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid); - } - if (dm_present) { - if (libxl__destroy_device_model(gc, domid) < 0) - 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); +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, + const libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx, domid, ao_how); + libxl__domain_destroy_state *dds; - vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path)); - if (vm_path) - if (!xs_rm(ctx->xsh, XBT_NULL, vm_path)) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path); + GCNEW(dds); + dds->ao = ao; + dds->domid = domid; + dds->callback = domain_destroy_cb; + libxl__domain_destroy(egc, dds); - if (!xs_rm(ctx->xsh, XBT_NULL, dom_path)) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path); + return AO_INPROGRESS; +} - xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid)); +static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds, + int rc) +{ + STATE_AO_GC(dds->ao); - libxl__userdata_destroyall(gc, domid); + if (rc) + LOGE(ERROR, "destruction of domain %u failed", dds->domid); - rc = xc_domain_destroy(ctx->xch, domid); - if (rc < 0) { - LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid); - rc = ERROR_FAIL; - goto out; - } - rc = 0; -out: - GC_FREE; - return rc; + libxl__ao_complete(egc, ao, rc); } int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type) @@ -1261,171 +1215,56 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass) /******************************************************************************/ -int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) +/* generic callback for devices that only need to set ao_complete */ +static void libxl__device_cb(libxl__egc *egc, libxl__ao_device *aorm) { - int rc; + STATE_AO_GC(aorm->ao); - rc = libxl__device_disk_set_backend(gc, disk); - if (rc) return rc; + if (aorm->rc) { + LOGE(ERROR, "unable to %s %s with id %u", + aorm->action == DEVICE_CONNECT ? "add" : "remove", + libxl__device_kind_to_string(aorm->dev->kind), + aorm->dev->devid); + goto out; + } - return rc; +out: + libxl__ao_complete(egc, ao, aorm->rc); + return; } -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, - libxl_device_disk *disk, - libxl__device *device) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - int devid; - - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - if (devid==-1) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - return ERROR_INVAL; - } - - device->backend_domid = disk->backend_domid; - device->backend_devid = devid; +/******************************************************************************/ - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_TAP: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_QDISK: - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", - disk->backend); - return ERROR_INVAL; - } +int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) +{ + int rc; - device->domid = domid; - device->devid = devid; - device->kind = LIBXL__DEVICE_KIND_VBD; + rc = libxl__device_disk_set_backend(gc, disk); + if (rc) return rc; - return 0; + return rc; } -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - char *dev; - libxl__device device; - int major, minor, rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; + int rc; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_disk_add(egc, domid, disk, device); + if (rc) { + LOGE(ERROR, "unable to add disk %s", disk->pdev_path); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (disk->script) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" - " not yet supported, sorry"); - rc = ERROR_INVAL; - goto out_free; - } - - rc = libxl__device_from_disk(gc, domid, disk, &device); - if (rc != 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - goto out_free; - } - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - dev = disk->pdev_path; - do_backend_phy: - libxl__device_physdisk_major_minor(dev, &major, &minor); - flexarray_append(back, "physical-device"); - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); - - flexarray_append(back, "params"); - flexarray_append(back, dev); - - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); - break; - case LIBXL_DISK_BACKEND_TAP: - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); - if (!dev) { - rc = ERROR_FAIL; - goto out_free; - } - flexarray_append(back, "tapdisk-params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), - disk->pdev_path)); - - /* now create a phy device to export the device to the guest */ - goto do_backend_phy; - case LIBXL_DISK_BACKEND_QDISK: - flexarray_append(back, "params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); - rc = ERROR_INVAL; - goto out_free; - } - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "removable"); - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); - flexarray_append(back, "bootable"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "dev"); - flexarray_append(back, disk->vdev); - flexarray_append(back, "type"); - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); - flexarray_append(back, "mode"); - flexarray_append(back, disk->readwrite ? "w" : "r"); - flexarray_append(back, "device-type"); - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "virtual-device"); - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); - flexarray_append(front, "device-type"); - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; - -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, @@ -1433,19 +1272,25 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_disk(gc, domid, disk, &device); + GCNEW(device); + rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid, @@ -1663,12 +1508,14 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) ret = 0; + /* fixme-ao */ libxl_device_disk_remove(ctx, domid, disks + i, 0); - libxl_device_disk_add(ctx, domid, disk); + libxl_device_disk_add(ctx, domid, disk, 0); stubdomid = libxl_get_stubdom_id(ctx, domid); if (stubdomid) { + /* fixme-ao */ libxl_device_disk_remove(ctx, stubdomid, disks + i, 0); - libxl_device_disk_add(ctx, stubdomid, disk); + libxl_device_disk_add(ctx, stubdomid, disk, 0); } out: for (i = 0; i < num; i++) @@ -1911,19 +1758,25 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_nic(gc, domid, nic, &device); + GCNEW(device); + rc = libxl__device_from_nic(gc, domid, nic, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, @@ -2273,19 +2126,25 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_vkb(gc, domid, vkb, &device); + GCNEW(device); + rc = libxl__device_from_vkb(gc, domid, vkb, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, @@ -2406,19 +2265,25 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_vfb(gc, domid, vfb, &device); + GCNEW(device); + rc = libxl__device_from_vfb(gc, domid, vfb, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 0ff4a83..0ab1531 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -530,7 +530,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info, int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid); int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid); int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid); -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid); +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, + const libxl_asyncop_how *ao_how); int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid); /* get max. number of cpus supported by hypervisor */ @@ -660,7 +661,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr); */ /* Disks */ -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk, + const libxl_asyncop_how *ao_how); int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 788e553..db58fd0 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -400,7 +400,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); - int flags, ret, rc; + int flags, ret, rc, nb_vm; char *uuid_string; char *dom_path, *vm_path, *libxl_path; struct xs_permissions roperm[2]; @@ -521,6 +521,28 @@ retry_transaction: libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path), rwperm, ARRAY_SIZE(rwperm)); + if (libxl_list_vm(ctx, &nb_vm) < 0) { + LOGE(ERROR, "cannot get number of running guests"); + rc = ERROR_FAIL; + goto out; + } + if (libxl_defbool_val(info->run_hotplug_scripts)) { + if (!libxl__xs_read(gc, t, DISABLE_UDEV_PATH) && (nb_vm - 1)) { + LOGE(ERROR, "cannot change hotplug execution option once set, " + "please shutdown all guests before changing it"); + rc = ERROR_FAIL; + goto out; + } + libxl__xs_write(gc, t, DISABLE_UDEV_PATH, "1"); + } else { + if (libxl__xs_read(gc, t, DISABLE_UDEV_PATH) && (nb_vm - 1)) { + LOGE(ERROR, "cannot change hotplug execution option once set, " + "please shutdown all guests before changing it"); + rc = ERROR_FAIL; + goto out; + } + xs_rm(ctx->xsh, t, DISABLE_UDEV_PATH); + } 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)); @@ -577,15 +599,25 @@ static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int rc); +static void domcreate_disk_connected(libxl__egc *egc, + libxl__ao_device *aorm); + static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); /* Our own function to clean up and call the user's callback. - * The final call in the sequence. */ + * The final call in the sequence if domain creation is successful. */ static void domcreate_complete(libxl__egc *egc, libxl__domain_create_state *dcs, int rc); +/* If creation is not successful, this callback will be executed + * when domain destruction is finished */ + +static void domcreate_destruction_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc); + static void initiate_domain_create(libxl__egc *egc, libxl__domain_create_state *dcs) { @@ -700,8 +732,13 @@ static void domcreate_bootloader_done(libxl__egc *egc, store_libxl_entry(gc, domid, &d_config->b_info); + GCNEW_ARRAY(dcs->devices, d_config->num_disks); + dcs->num_devices = d_config->num_disks; for (i = 0; i < d_config->num_disks; i++) { - ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]); + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_disk_connected; + ret = libxl__device_disk_add(egc, domid, &d_config->disks[i], + &dcs->devices[i]); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot add disk %d to domain: %d", i, ret); @@ -718,6 +755,42 @@ static void domcreate_bootloader_done(libxl__egc *egc, goto error_out; } } + return; + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int i, last, ret = 0; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + libxl__domain_build_state *const state = &dcs->build_state; + libxl_ctx *const ctx = CTX; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting disk devices"); + goto error_out; + } + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; + switch (d_config->c_info.type) { case LIBXL_DOMAIN_TYPE_HVM: { @@ -853,16 +926,31 @@ static void domcreate_complete(libxl__egc *egc, if (rc) { if (dcs->guest_domid) { - int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid); - if (rc2) - LOG(ERROR, "unable to destroy domain %d following" - " failed creation", dcs->guest_domid); + dcs->dds.ao = ao; + dcs->dds.domid = dcs->guest_domid; + dcs->dds.callback = domcreate_destruction_cb; + libxl__domain_destroy(egc, &dcs->dds); + return; } dcs->guest_domid = -1; } dcs->callback(egc, dcs, rc, dcs->guest_domid); } +static void domcreate_destruction_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc) +{ + STATE_AO_GC(dds->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(dds, *dcs, dds); + + if (rc) + LOG(ERROR, "unable to destroy domain %u following failed creation", + dds->domid); + + dcs->callback(egc, dcs, rc, dcs->guest_domid); +} + /*----- application-facing domain creation interface -----*/ typedef struct { diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c7e057d..275ab43 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -58,6 +58,48 @@ int libxl__parse_backend_path(libxl__gc *gc, return libxl__device_kind_from_string(strkind, &dev->backend_kind); } +static int libxl__num_devices(libxl__gc *gc, uint32_t domid) +{ + char *path; + unsigned int num_kinds, num_devs; + char **kinds = NULL, **devs = NULL; + int i, j, rc = 0; + libxl__device dev; + libxl__device_kind kind; + int numdevs = 0; + + path = GCSPRINTF("/local/domain/%d/device", domid); + kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds); + if (!kinds) { + if (errno != ENOENT) { + LOGE(ERROR, "unable to get xenstore device listing %s", path); + rc = ERROR_FAIL; + goto out; + } + num_kinds = 0; + } + for (i = 0; i < num_kinds; i++) { + if (libxl__device_kind_from_string(kinds[i], &kind)) + continue; + + path = GCSPRINTF("/local/domain/%d/device/%s", domid, kinds[i]); + devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs); + if (!devs) + continue; + for (j = 0; j < num_devs; j++) { + path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend", + domid, kinds[i], devs[j]); + path = libxl__xs_read(gc, XBT_NULL, path); + if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { + numdevs++; + } + } + } +out: + if (rc) return rc; + return numdevs; +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -110,6 +152,178 @@ retry_transaction: return 0; } +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int devid; + + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + if (devid == -1) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + return ERROR_INVAL; + } + + device->backend_domid = disk->backend_domid; + device->backend_devid = devid; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_TAP: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_QDISK: + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; + break; + default: + LOGE(ERROR, "unrecognized disk backend type: %d", disk->backend); + return ERROR_INVAL; + } + + device->domid = domid; + device->devid = devid; + device->kind = LIBXL__DEVICE_KIND_VBD; + + return 0; +} + +int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, + libxl_device_disk *disk, + libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front = NULL; + flexarray_t *back = NULL; + char *dev; + libxl__device *device; + int major, minor, rc; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(20, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (disk->script) { + LOGE(ERROR, "External block scripts not yet supported, sorry"); + rc = ERROR_INVAL; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_disk(gc, domid, disk, device); + if (rc != 0) { + LOGE(ERROR, "Invalid or unsupported virtual disk identifier %s", + disk->vdev); + goto out; + } + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + dev = disk->pdev_path; + do_backend_phy: + libxl__device_physdisk_major_minor(dev, &major, &minor); + flexarray_append(back, "physical-device"); + flexarray_append(back, GCSPRINTF("%x:%x", major, minor)); + + flexarray_append(back, "params"); + flexarray_append(back, dev); + + flexarray_append(back, "script"); + flexarray_append(back, GCSPRINTF("%s/%s", + libxl__xen_script_dir_path(), + "block")); + + assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD); + break; + case LIBXL_DISK_BACKEND_TAP: + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); + if (!dev) { + rc = ERROR_FAIL; + goto out_free; + } + flexarray_append(back, "tapdisk-params"); + flexarray_append(back, GCSPRINTF("%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + + flexarray_append(back, "script"); + flexarray_append(back, GCSPRINTF("%s/%s", + libxl__xen_script_dir_path(), + "blktap")); + + /* now create a phy device to export the device to the guest */ + goto do_backend_phy; + case LIBXL_DISK_BACKEND_QDISK: + flexarray_append(back, "params"); + flexarray_append(back, GCSPRINTF("%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + assert(device->backend_kind == LIBXL__DEVICE_KIND_QDISK); + break; + default: + LOGE(ERROR, "unrecognized disk backend type: %d", disk->backend); + rc = ERROR_INVAL; + goto out_free; + } + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "removable"); + flexarray_append(back, GCSPRINTF("%d", (disk->removable) ? 1 : 0)); + flexarray_append(back, "bootable"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "dev"); + flexarray_append(back, disk->vdev); + flexarray_append(back, "type"); + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); + flexarray_append(back, "mode"); + flexarray_append(back, disk->readwrite ? "w" : "r"); + flexarray_append(back, "device-type"); + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", disk->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + flexarray_append(front, "virtual-device"); + flexarray_append(front, GCSPRINTF("%d", device->devid)); + flexarray_append(front, "device-type"); + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aorm->dev = device; + aorm->action = DEVICE_CONNECT; + libxl__initiate_device_add(egc, aorm); + + rc = 0; + +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + typedef struct { libxl__gc *gc; libxl_device_disk *disk; @@ -356,49 +570,116 @@ 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) { +static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *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); +void libxl__init_ao_device(libxl__ao_device *aorm, libxl__ao *ao, + libxl__ao_device **base) +{ + aorm->ao = ao; + aorm->state = DEVICE_ACTIVE; + aorm->rc = 0; + aorm->base = base; } -int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao, - libxl__device *dev) +int libxl__ao_device_check_last(libxl__gc *gc, libxl__ao_device *device, + libxl__ao_device *list, int num, int *last) { - AO_GC; - libxl_ctx *ctx = libxl__gc_owner(gc); - xs_transaction_t t; - char *be_path = libxl__device_backend_path(gc, dev); + int i, ret = 0; + + device->state = DEVICE_FINISHED; + *last = 1; + for (i = 0; i < num; i++) { + if (list[i].state != DEVICE_FINISHED && *last) { + *last = 0; + if (!device->rc) break; + } + if (device->rc && device->action == DEVICE_CONNECT) { + /* Cancel pending events */ + if (list[i].pid) { + libxl__ev_time_deregister(gc, &list[i].ev); + kill(list[i].pid, SIGKILL); + } else { + libxl__ev_devstate_cancel(gc, &list[i].ds); + } + ret = list[i].rc; + } + } + return ret; +} + +/* Common callbacks for device add/remove */ + +static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds, + int rc); + +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + char *be_path = libxl__device_backend_path(gc, aorm->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 (aorm->dev->backend_kind == LIBXL__DEVICE_KIND_QDISK) { + aorm->callback(egc, aorm); + return; + } + + if (atoi(state) == XenbusStateInitWait) + goto out_ok; + + libxl__ev_devstate_init(&aorm->ds); + rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_backend_callback, + state_path, XenbusStateInitWait, + LIBXL_INIT_TIMEOUT * 1000); + if (rc) { + LOGE(ERROR, "unable to initialize device %s", be_path); + goto out_fail; + } + + return; + +out_fail: + assert(rc); + aorm->rc = rc; + aorm->callback(egc, aorm); + return; + +out_ok: + libxl__device_hotplug(egc, aorm); + return; +} + +void libxl__initiate_device_remove(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl_ctx *ctx = libxl__gc_owner(gc); + xs_transaction_t t = 0; + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *state; + int rc = 0; + + if (aorm->force) + libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev)); + /* Remove frontend xs paths to force backend disconnection */ + +retry_transaction: + t = xs_transaction_start(ctx->xsh); + state = libxl__xs_read(gc, t, state_path); if (!state) goto out_ok; - if (atoi(state) != 4) { + if (atoi(state) != XenbusStateConnected && + atoi(state) != XenbusStateClosing) { libxl__device_destroy_tapdisk(gc, be_path); - xs_rm(ctx->xsh, XBT_NULL, be_path); goto out_ok; } -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, GCSPRINTF("%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) @@ -408,60 +689,67 @@ retry_transaction: goto out_fail; } } + /* mark transaction as ended, to prevent double closing it on out_ok */ + t = 0; 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, + rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_backend_callback, state_path, XenbusStateClosed, LIBXL_DESTROY_TIMEOUT * 1000); - if (rc) goto out_fail; + if (rc) { + LOGE(ERROR, "unable to remove device %s", be_path); + goto out_fail; + } - return 0; + return; out_fail: assert(rc); - device_remove_cleanup(gc, aorm); - return rc; + aorm->rc = rc; + aorm->callback(egc, aorm); + return; out_ok: - libxl__ao_complete(egc, ao, 0); - return 0; + if (t) xs_transaction_end(ctx->xsh, t, 0); + libxl__device_hotplug(egc, aorm); + return; } -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - char *be_path = libxl__device_backend_path(gc, dev); - char *fe_path = libxl__device_frontend_path(gc, dev); - - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); - - libxl__device_destroy_tapdisk(gc, be_path); +/* Callback for device destruction */ - return 0; -} +static void device_remove_callback(libxl__egc *egc, libxl__ao_device *aorm); -int libxl__devices_destroy(libxl__gc *gc, uint32_t domid) +void libxl__devices_destroy(libxl__egc *egc, libxl__devices_remove_state *drs) { - libxl_ctx *ctx = libxl__gc_owner(gc); + STATE_AO_GC(drs->ao); char *path; unsigned int num_kinds, num_devs; char **kinds = NULL, **devs = NULL; - int i, j; - libxl__device dev; + int i, j, rc = 0, numdev = 0; + libxl__device *dev; libxl__device_kind kind; - path = libxl__sprintf(gc, "/local/domain/%d/device", domid); + drs->num_devices = libxl__num_devices(gc, drs->domid); + if (drs->num_devices < 0) { + LOGE(ERROR, "unable to get number of devices for domain %u", + drs->domid); + rc = ERROR_FAIL; + goto out; + } + + GCNEW_ARRAY(drs->aorm, drs->num_devices); + for (i = 0; i < drs->num_devices; i++) { + libxl__init_ao_device(&drs->aorm[i], drs->ao, &drs->aorm); + } + + path = GCSPRINTF("/local/domain/%d/device", drs->domid); kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds); if (!kinds) { if (errno != ENOENT) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get xenstore" - " device listing %s", path); + LOGE(ERROR, "unable to get xenstore device listing %s", path); + rc = ERROR_FAIL; goto out; } num_kinds = 0; @@ -470,37 +758,106 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid) if (libxl__device_kind_from_string(kinds[i], &kind)) continue; - path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, kinds[i]); + path = GCSPRINTF("/local/domain/%d/device/%s", drs->domid, kinds[i]); devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs); if (!devs) continue; for (j = 0; j < num_devs; j++) { - path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend", - domid, kinds[i], devs[j]); + path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend", + drs->domid, kinds[i], devs[j]); path = libxl__xs_read(gc, XBT_NULL, path); - if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { - dev.domid = domid; - dev.kind = kind; - dev.devid = atoi(devs[j]); - - libxl__device_destroy(gc, &dev); + GCNEW(dev); + if (path && libxl__parse_backend_path(gc, path, dev) == 0) { + dev->domid = drs->domid; + dev->kind = kind; + dev->devid = atoi(devs[j]); + drs->aorm[numdev].action = DEVICE_DISCONNECT; + drs->aorm[numdev].dev = dev; + drs->aorm[numdev].callback = device_remove_callback; + libxl__initiate_device_remove(egc, &drs->aorm[numdev]); + numdev++; } } } /* console 0 frontend directory is not under /local/domain//device */ - path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid); + path = GCSPRINTF("/local/domain/%d/console/backend", drs->domid); path = libxl__xs_read(gc, XBT_NULL, path); + GCNEW(dev); if (path && strcmp(path, "") && - libxl__parse_backend_path(gc, path, &dev) == 0) { - dev.domid = domid; - dev.kind = LIBXL__DEVICE_KIND_CONSOLE; - dev.devid = 0; + libxl__parse_backend_path(gc, path, dev) == 0) { + dev->domid = drs->domid; + dev->kind = LIBXL__DEVICE_KIND_CONSOLE; + dev->devid = 0; - libxl__device_destroy(gc, &dev); + libxl__device_destroy(gc, dev); } out: + if (!numdev) drs->callback(egc, drs, rc); + return; +} + +static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds, + int rc) +{ + libxl__ao_device *aorm = CONTAINER_OF(ds, *aorm, ds); + STATE_AO_GC(aorm->ao); + + device_backend_cleanup(gc, aorm); + + if (rc == ERROR_TIMEDOUT && aorm->action == DEVICE_DISCONNECT && + !aorm->force) { + aorm->force = 1; + libxl__initiate_device_remove(egc, aorm); + return; + } + + if (rc) { + LOGE(ERROR, "unable to %s device with path %s", + aorm->action == DEVICE_DISCONNECT ? "disconnect" : + "connect", + libxl__device_backend_path(gc, aorm->dev)); + goto error; + } + + libxl__device_hotplug(egc, aorm); + return; + +error: + aorm->rc = rc; + aorm->callback(egc, aorm); + return; +} + +static void device_remove_callback(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__devices_remove_state *drs = CONTAINER_OF(aorm->base, *drs, aorm); + int rc = 0, last; + + if (aorm->action == DEVICE_DISCONNECT) { + libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev)); + libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev)); + } + + rc = libxl__ao_device_check_last(gc, aorm, drs->aorm, + drs->num_devices, &last); + + if (last) + drs->callback(egc, drs, rc); + return; +} + +int libxl__device_destroy(libxl__gc *gc, libxl__device *dev) +{ + char *be_path = libxl__device_backend_path(gc, dev); + char *fe_path = libxl__device_frontend_path(gc, dev); + + libxl__xs_path_cleanup(gc, be_path); + libxl__xs_path_cleanup(gc, fe_path); + + libxl__device_destroy_tapdisk(gc, be_path); return 0; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 5de3aef..b2622ee 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -660,6 +660,8 @@ retry_transaction: return 0; } +static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm); + static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, libxl__dm_spawn_state *stubdom_dmss, int rc); @@ -668,8 +670,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { STATE_AO_GC(sdss->dm.spawn.ao); libxl_ctx *ctx = libxl__gc_owner(gc); - int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret; - libxl__device_console *console; + int i, ret; libxl_device_vfb vfb; libxl_device_vkb vkb; char **args; @@ -787,22 +788,66 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; + GCNEW_ARRAY(sdss->devices, dm_config->num_disks); + sdss->num_devices = dm_config->num_disks; for (i = 0; i < dm_config->num_disks; i++) { - ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]); - if (ret) + libxl__init_ao_device(&sdss->devices[i], ao, &sdss->devices); + sdss->devices[i].callback = spawn_stub_disk_connected; + ret = libxl__device_disk_add(egc, dm_domid, &dm_config->disks[i], + &sdss->devices[i]); + if (ret) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "cannot add disk %d to domain: %d", i, ret); + ret = ERROR_FAIL; goto out_free; + } + } + + free(args); + return; + +out_free: + free(args); +out: + assert(ret); + spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); +} + +static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl_ctx *ctx = libxl__gc_owner(gc); + libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aorm->base, *sdss, devices); + int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret = 0, last; + libxl__device_console *console; + + /* convenience aliases */ + libxl_domain_config *const dm_config = &sdss->dm_config; + libxl_domain_config *const guest_config = sdss->dm.guest_config; + const int guest_domid = sdss->dm.guest_domid; + libxl__domain_build_state *const d_state = sdss->dm.build_state; + libxl__domain_build_state *const stubdom_state = &sdss->dm_state; + uint32_t dm_domid = sdss->pvqemu.guest_domid; + + ret = libxl__ao_device_check_last(gc, aorm, sdss->devices, + sdss->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting disk devices"); + goto out; } + for (i = 0; i < dm_config->num_vifs; i++) { ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]); if (ret) - goto out_free; + goto out; } ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); if (ret) - goto out_free; + goto out; ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); if (ret) - goto out_free; + goto out; if (guest_config->b_info.u.hvm.serial) num_console++; @@ -810,7 +855,7 @@ retry_transaction: console = libxl__calloc(gc, num_console, sizeof(libxl__device_console)); if (!console) { ret = ERROR_NOMEM; - goto out_free; + goto out; } for (i = 0; i < num_console; i++) { @@ -846,7 +891,7 @@ retry_transaction: ret = libxl__device_console_add(gc, dm_domid, &console[i], i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL); if (ret) - goto out_free; + goto out; } sdss->pvqemu.guest_domid = dm_domid; @@ -856,13 +901,9 @@ retry_transaction: libxl__spawn_local_dm(egc, &sdss->pvqemu); - free(args); return; -out_free: - free(args); out: - assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); } @@ -883,7 +924,7 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, out: if (rc) { if (dm_domid) - libxl_domain_destroy(CTX, dm_domid); + libxl_domain_destroy(CTX, dm_domid, 0); } sdss->callback(egc, &sdss->dm, rc); } @@ -1075,62 +1116,35 @@ static void device_model_spawn_outcome(libxl__egc *egc, int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) { - libxl_ctx *ctx = libxl__gc_owner(gc); char *pid; int ret; - pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); - if (!pid) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); - ret = ERROR_INVAL; - goto out; - } - if (!atoi(pid)) { - int stubdomid = libxl_get_stubdom_id(ctx, domid); - const char *savefile; - - if (!stubdomid) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); + pid = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("/local/domain/%d/image/device-model-pid", + domid)); + if (!pid || !atoi(pid)) { + LOGE(ERROR, "Couldn't find device model's pid"); ret = ERROR_INVAL; goto out; - } - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid); - ret = libxl_domain_destroy(ctx, stubdomid); - if (ret) - goto out; - - savefile = libxl__device_model_savefile(gc, domid); - ret = unlink(savefile); - /* - * On suspend libxl__domain_save_device_model will have already - * unlinked the save file. - */ - if (ret && errno == ENOENT) ret = 0; - if (ret) { - LIBXL__LOG_ERRNO(ctx, XTL_ERROR, - "failed to remove device-model savefile %s\n", - savefile); - goto out; - } + } + ret = kill(atoi(pid), SIGHUP); + if (ret < 0 && errno == ESRCH) { + LOG(DEBUG, "Device Model already exited"); + ret = 0; + } else if (ret == 0) { + LOG(DEBUG, "Device Model signaled"); + ret = 0; } else { - ret = kill(atoi(pid), SIGHUP); - if (ret < 0 && errno == ESRCH) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model already exited"); - ret = 0; - } else if (ret == 0) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model signaled"); - ret = 0; - } else { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to kill Device Model [%d]", - atoi(pid)); - ret = ERROR_FAIL; - goto out; - } + LOGEV(ERROR, errno, "failed to kill Device Model [%d]", atoi(pid)); + ret = ERROR_FAIL; + goto out; } out: - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); + xs_rm(CTX->xsh, XBT_NULL, GCSPRINTF("/local/domain/0/device-model/%d", + domid)); + xs_rm(CTX->xsh, XBT_NULL, GCSPRINTF("/local/domain/%d/hvmloader", + domid)); return ret; } diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index c246211..9b016e8 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -973,6 +973,176 @@ out: return rc; } +/* Callbacks for libxl__domain_destroy */ +static void stubdom_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc); +static void domain_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc); + +void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds) +{ + STATE_AO_GC(dds->ao); + uint32_t stubdomid = libxl_get_stubdom_id(CTX, dds->domid); + + if (stubdomid) { + dds->stubdom.ao = ao; + dds->stubdom.domid = stubdomid; + dds->stubdom.callback = stubdom_callback; + libxl__destroy_domid(egc, &dds->stubdom); + } else { + dds->stubdom_finished = 1; + } + + dds->domain.ao = ao; + dds->domain.domid = dds->domid; + dds->domain.callback = domain_callback; + libxl__destroy_domid(egc, &dds->domain); +} + +static void stubdom_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc) +{ + STATE_AO_GC(dis->ao); + libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, stubdom); + const char *savefile; + + if (rc) + LOGE(ERROR, "unable to destroy stubdom with domid %u", dis->domid); + + dds->stubdom_finished = 1; + savefile = libxl__device_model_savefile(gc, dis->domid); + rc = unlink(savefile); + /* + * On suspend libxl__domain_save_device_model will have already + * unlinked the save file. + */ + if (rc && errno == ENOENT) rc = 0; + if (rc) { + LOGEV(ERROR, errno, "failed to remove device-model savefile %s", + savefile); + } + + if (dds->domain_finished) + dds->callback(egc, dds, rc); +} + +static void domain_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc) +{ + STATE_AO_GC(dis->ao); + libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain); + + if (rc) + LOGE(ERROR, "unable to destroy guest with domid %u", dis->domid); + + dds->domain_finished = 1; + if (dds->stubdom_finished) + dds->callback(egc, dds, rc); +} + +/* Callbacks for libxl__domain_clean */ + +/* Device destruction callback */ +static void devices_destroy_cb(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc); + +void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis) +{ + STATE_AO_GC(dis->ao); + int rc; + + rc = libxl_domain_info(CTX, NULL, dis->domid); + switch (rc) { + case 0: + break; + case ERROR_INVAL: + LOGE(ERROR, "non-existant domain %d", dis->domid); + default: + goto out; + } + + switch (libxl__domain_type(gc, dis->domid)) { + case LIBXL_DOMAIN_TYPE_HVM: + dis->dm_present = 1; + break; + case LIBXL_DOMAIN_TYPE_PV: + dis->pid = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("/local/domain/%d/image/device-model-pid", + dis->domid)); + dis->dm_present = (dis->pid != NULL); + break; + default: + abort(); + } + + dis->dom_path = libxl__xs_get_dompath(gc, dis->domid); + if (!dis->dom_path) { + rc = ERROR_FAIL; + goto out; + } + + if (libxl__device_pci_destroy_all(gc, dis->domid) < 0) + LOGE(ERROR, "pci shutdown failed for domid %d", dis->domid); + rc = xc_domain_pause(CTX->xch, dis->domid); + if (rc < 0) { + LOGEV(ERROR, rc, "xc_domain_pause failed for %d", dis->domid); + } + if (dis->dm_present) { + rc = libxl__destroy_device_model(gc, dis->domid); + if (rc < 0) + LOGE(ERROR, "libxl__destroy_device_model failed for %d", + dis->domid); + libxl__qmp_cleanup(gc, dis->domid); + } + dis->drs.ao = ao; + dis->drs.domid = dis->domid; + dis->drs.callback = devices_destroy_cb; + libxl__devices_destroy(egc, &dis->drs); + return; + +out: + assert(rc); + dis->callback(egc, dis, rc); + return; +} + +static void devices_destroy_cb(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc) +{ + STATE_AO_GC(drs->ao); + libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs); + + if (rc < 0) + LOGE(ERROR, "libxl__devices_destroy failed for %d", dis->domid); + + dis->vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", + dis->dom_path)); + if (dis->vm_path) + if (!xs_rm(CTX->xsh, XBT_NULL, dis->vm_path)) + LOGE(ERROR, "xs_rm failed for %s", dis->vm_path); + + if (!xs_rm(CTX->xsh, XBT_NULL, dis->dom_path)) + LOGE(ERROR, "xs_rm failed for %s", dis->dom_path); + + xs_rm(CTX->xsh, XBT_NULL, libxl__xs_libxl_path(gc, dis->domid)); + + libxl__userdata_destroyall(gc, dis->domid); + + rc = xc_domain_destroy(CTX->xch, dis->domid); + if (rc < 0) { + LOGEV(ERROR, rc, "xc_domain_destroy failed for %d", dis->domid); + rc = ERROR_FAIL; + goto out; + } + rc = 0; + +out: + dis->callback(egc, dis, rc); + return; +} + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c new file mode 100644 index 0000000..686a38d --- /dev/null +++ b/tools/libxl/libxl_hotplug.c @@ -0,0 +1,84 @@ +/* + * Copyright (C) 2012 + * Author Roger Pau Monne + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include "libxl_osdeps.h" /* must come before any other headers */ + +#include "libxl_internal.h" + +/* + * Generic hotplug helpers + * + * This helpers are both used by Linux and NetBSD hotplug script + * dispatcher functions. + */ + +static void device_hotplug_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs) +{ + libxl__ao_device *aorm = CONTAINER_OF(ev, *aorm, ev); + STATE_AO_GC(aorm->ao); + + if (!aorm) return; + if (libxl__ev_child_inuse(&aorm->child)) { + if (kill(aorm->pid, SIGKILL)) { + LOGEV(ERROR, errno, "unable to kill hotplug script %s [%ld]", + aorm->what, (unsigned long)aorm->pid); + goto out; + } + } + +out: + libxl__ev_time_deregister(gc, &aorm->ev); + return; +} + +int libxl__hotplug_launch(libxl__gc *gc, libxl__ao_device *aorm, + const char *arg0, char *const args[], + char *const env[], libxl__ev_child_callback *death) +{ + int rc = 0; + pid_t pid = -1; + + libxl__ev_time_init(&aorm->ev); + libxl__ev_child_init(&aorm->child); + + rc = libxl__ev_time_register_rel(gc, &aorm->ev, device_hotplug_timeout, + LIBXL_HOTPLUG_TIMEOUT * 1000); + if (rc) { + LOGE(ERROR, "unable to register timeout for hotplug script %s", arg0); + goto out; + } + + pid = libxl__ev_child_fork(gc, &aorm->child, death); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; + } + if (!pid) { + /* child */ + libxl__exec(gc, -1, -1, -1, arg0, args, env); + LOGE(ERROR, "unable execute hotplug scripts for device %"PRIu32 " on " + "dom %"PRIu32, aorm->dev->devid, aorm->dev->backend_domid); + abort(); + } +out: + if (libxl__ev_child_inuse(&aorm->child)) { + aorm->pid = pid; + /* we will get a callback when the child dies */ + return 0; + } + libxl__ev_time_deregister(gc, &aorm->ev); + return rc; +} diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index fc2024d..faeb965 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -71,6 +71,8 @@ #include "_libxl_types_internal_json.h" #define LIBXL_DESTROY_TIMEOUT 10 +#define LIBXL_INIT_TIMEOUT 10 +#define LIBXL_HOTPLUG_TIMEOUT 10 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 #define LIBXL_XENCONSOLE_LIMIT 1048576 #define LIBXL_XENCONSOLE_PROTOCOL "vt100" @@ -85,6 +87,7 @@ #define STUBDOM_CONSOLE_SERIAL 3 #define STUBDOM_SPECIAL_CONSOLES 3 #define TAP_DEVICE_SUFFIX "-emu" +#define DISABLE_UDEV_PATH "libxl/disable_udev" #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) @@ -779,6 +782,9 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device); _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor); _hidden int libxl__device_disk_dev_number(const char *virtpath, @@ -795,7 +801,6 @@ _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_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); /* @@ -826,13 +831,6 @@ _hidden const char *libxl__device_nic_devname(libxl__gc *gc, uint32_t devid, libxl_nic_type type); -/* 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__egc*, libxl__ao*, - libxl__device *dev); - /* * libxl__ev_devstate - waits a given time for a device to * reach a given state. Follows the libxl_ev_* conventions. @@ -918,6 +916,65 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int num); _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid); +/*----- device addition/removal -----*/ + +/* During the init/destruction process, the device can be in several states: + * + * DEVICE_UNKNOWN: device in unknown state (default value when struct is + * initialized). + * + * DEVICE_WAIT_BACKEND: waiting for the backend to switch to XenbusStateInit or + * XenbusStateClosed. + * + * DEVICE_WAIT_HOTPLUG: waiting for hotplug script to finish execution. + * + * DEVICE_FINISHED: device is connected/disconnected. + */ +typedef enum { + DEVICE_ACTIVE, + DEVICE_FINISHED +} libxl__device_state; + +/* Action to perform (either connect or disconnect) */ +typedef enum { + DEVICE_CONNECT, + DEVICE_DISCONNECT +} libxl__device_action; + +typedef struct libxl__ao_device libxl__ao_device; +typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*); + +_hidden void libxl__init_ao_device(libxl__ao_device *aorm, libxl__ao *ao, + libxl__ao_device **base); +_hidden int libxl__ao_device_check_last(libxl__gc *gc, libxl__ao_device *device, + libxl__ao_device *list, + int num, int *last); + +struct libxl__ao_device { + libxl__ao *ao; + /* State in which the device is */ + libxl__device_state state; + /* action being performed */ + libxl__device_action action; + /* device teardown (back for xenstore backend to connect/disconnect) */ + libxl__device *dev; + int force; + /* device hotplug execution */ + pid_t pid; + char *what; + libxl__device_callback *callback; + /* private for implementation */ + int rc; + libxl__ev_time ev; + libxl__ev_child child; + libxl__ev_devstate ds; + void *base; +}; + +_hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, + libxl_device_disk *disk, + libxl__ao_device *aorm); + /* *----- spawn ----- * @@ -1106,6 +1163,8 @@ typedef struct { libxl_domain_config dm_config; libxl__domain_build_state dm_state; libxl__dm_spawn_state pvqemu; + libxl__ao_device *devices; + int num_devices; } libxl__stub_dm_spawn_state; _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*); @@ -1797,6 +1856,98 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); * If callback is passed rc==0, will have updated st->info appropriately */ _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); +/* + * libxl__hotplug_launch is an internal function that should not be used + * directly, all hotplug script calls have to implement and use + * libxl__device_hotplug. + */ +_hidden void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm); +_hidden int libxl__hotplug_launch(libxl__gc *gc, libxl__ao_device *aorm, + const char *arg0, char *const args[], + char *const env[], + libxl__ev_child_callback *death); + +/* Arranges that dev will be added to the guest, and the + * hotplug scripts will be executed (if necessary). When + * this is done (or an error happens), the callback in + * aorm->callback will be called. + */ +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aorm); + +/* Arranges that dev will be removed to the guest, and the + * hotplug scripts will be executed (if necessary). When + * this is done (or an error happens), the callback in + * aorm->callback will be called. + */ +_hidden void libxl__initiate_device_remove(libxl__egc *egc, + libxl__ao_device *aorm); + +/*----- Domain destruction -----*/ + +typedef struct libxl__domain_destroy_state libxl__domain_destroy_state; +typedef struct libxl__destroy_domid_state libxl__destroy_domid_state; +typedef struct libxl__devices_remove_state libxl__devices_remove_state; + +typedef void libxl__domain_destroy_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc); + +typedef void libxl__domain_clean_cb(libxl__egc *egc, + libxl__destroy_domid_state *dis, + int rc); + +typedef void libxl__devices_remove_callback(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc); + +struct libxl__devices_remove_state { + /* set by user */ + libxl__ao *ao; + uint32_t domid; + libxl__devices_remove_callback *callback; + /* private */ + libxl__ao_device *aorm; + int num_devices; +}; + +struct libxl__destroy_domid_state { + /* filled in by user */ + libxl__ao *ao; + uint32_t domid; + libxl__domain_clean_cb *callback; + /* private to implementation */ + libxl__devices_remove_state drs; + char *dom_path; + char *vm_path; + char *pid; + int dm_present; +}; + +struct libxl__domain_destroy_state { + /* filled by the user */ + libxl__ao *ao; + uint32_t domid; + libxl__domain_destroy_cb *callback; + /* Private */ + uint32_t stubdomid; + libxl__destroy_domid_state stubdom; + int stubdom_finished; + libxl__destroy_domid_state domain; + int domain_finished; +}; + +/* Entry point for domain destruction */ +_hidden void libxl__domain_destroy(libxl__egc *egc, + libxl__domain_destroy_state *dds); + +/* Used to destroy a domain with the passed id (it doesn't check for stubs) */ +_hidden void libxl__destroy_domid(libxl__egc *egc, + libxl__destroy_domid_state *dis); + +/* Entry point for devices destruction */ +_hidden void libxl__devices_destroy(libxl__egc *egc, + libxl__devices_remove_state *drs); + /*----- Domain creation -----*/ typedef struct libxl__domain_create_state libxl__domain_create_state; @@ -1816,6 +1967,9 @@ struct libxl__domain_create_state { int guest_domid; libxl__domain_build_state build_state; libxl__bootloader_state bl; + libxl__ao_device *devices; + int num_devices; + libxl__domain_destroy_state dds; libxl__stub_dm_spawn_state dmss; /* If we're not doing stubdom, we use only dmss.dm, * for the non-stubdom device model. */ diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 925248b..315ce15 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -25,3 +25,129 @@ int libxl__try_phy_backend(mode_t st_mode) return 1; } + +/* Hotplug scripts helpers */ + +static void cleanup(libxl__gc *gc, libxl__ao_device *aorm) +{ + if (!aorm) return; + libxl__ev_time_deregister(gc, &aorm->ev); +} + +static void callback(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) +{ + libxl__ao_device *aorm = CONTAINER_OF(child, *aorm, child); + STATE_AO_GC(aorm->ao); + + cleanup(gc, aorm); + + if (status) { + libxl_report_child_exitstatus(CTX, aorm->rc ? LIBXL__LOG_ERROR + : LIBXL__LOG_WARNING, + aorm->what, pid, status); + aorm->rc = ERROR_FAIL; + } + aorm->callback(egc, aorm); +} + +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) +{ + char *be_path = libxl__device_backend_path(gc, dev); + char *script; + const char *type = libxl__device_kind_to_string(dev->backend_kind); + char **env; + int nr = 0; + + script = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "script")); + if (!script) { + LOGEV(ERROR, errno, "unable to read script from %s", be_path); + return NULL; + } + + GCNEW_ARRAY(env, 9); + env[nr++] = "script"; + env[nr++] = script; + env[nr++] = "XENBUS_TYPE"; + env[nr++] = libxl__strdup(gc, type); + env[nr++] = "XENBUS_PATH"; + env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid); + env[nr++] = "XENBUS_BASE_PATH"; + env[nr++] = "backend"; + env[nr++] = NULL; + + return env; +} + +/* Hotplug scripts caller functions */ + +static int libxl__hotplug_disk(libxl__gc *gc, libxl__ao_device *aorm) +{ + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *script; + char **args, **env; + int nr = 0, rc = 0; + + script = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "script")); + if (!script) { + LOGEV(ERROR, errno, "unable to read script from %s", be_path); + return ERROR_FAIL; + } + + env = get_hotplug_env(gc, aorm->dev); + if (!env) + return ERROR_FAIL; + + GCNEW_ARRAY(args, 3); + + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "add" : "remove"; + args[nr++] = NULL; + + aorm->what = GCSPRINTF("%s %s", args[0], args[1]); + LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + goto out_free; + } + + rc = 0; + +out_free: + return rc; +} + +void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH); + + /* Check if we have to run hotplug scripts */ + if (!disable_udev) goto out; + + switch (aorm->dev->backend_kind) { + case LIBXL__DEVICE_KIND_VBD: + aorm->rc = libxl__hotplug_disk(gc, aorm); + if (aorm->rc) goto error; + break; + default: + /* If no need to execute any hotplug scripts, + * call the callback manually + */ + aorm->rc = 0; + aorm->callback(egc, aorm); + break; + } + + return; + +error: + assert(aorm->rc); + LOGE(ERROR, "unable to queue execution of hotplug script for device " + "with path %s", libxl__device_backend_path(gc, aorm->dev)); +out: + aorm->callback(egc, aorm); + return; +} diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 551e367..b1351de 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -220,6 +220,7 @@ libxl_domain_create_info = Struct("domain_create_info",[ ("xsdata", libxl_key_value_list), ("platformdata", libxl_key_value_list), ("poolid", uint32), + ("run_hotplug_scripts",libxl_defbool), ], dir=DIR_IN) MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT") diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index d4db1f8..d992c32 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -35,6 +35,7 @@ xentoollog_logger_stdiostream *logger; int dryrun_only; int autoballoon = 1; +libxl_defbool run_hotplug_scripts; char *lockfile; char *default_vifscript = NULL; char *default_bridge = NULL; @@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile, if (!xlu_cfg_get_long (config, "autoballoon", &l, 0)) autoballoon = l; + libxl_defbool_setdefault(&run_hotplug_scripts, true); + xlu_cfg_get_defbool(config, "run_hotplug_scripts", &run_hotplug_scripts, 0); + if (!xlu_cfg_get_string (config, "lockfile", &buf, 0)) lockfile = strdup(buf); else { diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index 2b6714a..43d727a 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -109,6 +109,7 @@ void postfork(void); /* global options */ extern int autoballoon; +extern libxl_defbool run_hotplug_scripts; extern int dryrun_only; extern char *lockfile; extern char *default_vifscript; diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 8908581..3f1bbf6 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -562,6 +562,7 @@ static void parse_config_data(const char *configfile_filename_report, } } + c_info->run_hotplug_scripts = run_hotplug_scripts; c_info->type = LIBXL_DOMAIN_TYPE_PV; if (!xlu_cfg_get_string (config, "builder", &buf, 0) && !strncmp(buf, "hvm", strlen(buf))) @@ -1333,7 +1334,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, /* fall-through */ case LIBXL_ACTION_ON_SHUTDOWN_DESTROY: LOG("Domain %d needs to be cleaned up: destroying the domain", domid); - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); break; case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY: @@ -1899,7 +1900,7 @@ start: error_out: release_lock(); if (libxl_domid_valid_guest(domid)) - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); out: if (logfile != 2) @@ -2386,7 +2387,7 @@ static void destroy_domain(const char *p) fprintf(stderr, "Cannot destroy privileged domain 0.\n\n"); exit(-1); } - rc = libxl_domain_destroy(ctx, domid); + rc = libxl_domain_destroy(ctx, domid, 0); if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); } } @@ -2660,7 +2661,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint, if (checkpoint) libxl_domain_unpause(ctx, domid); else - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); exit(0); } @@ -2892,7 +2893,7 @@ static void migrate_domain(const char *domain_spec, const char *rune, } fprintf(stderr, "migration sender: Target reports successful startup.\n"); - libxl_domain_destroy(ctx, domid); /* bang! */ + libxl_domain_destroy(ctx, domid, 0); /* bang! */ fprintf(stderr, "Migration successful.\n"); exit(0); @@ -3010,7 +3011,7 @@ static void migrate_receive(int debug, int daemonize, int monitor) if (rc) { fprintf(stderr, "migration target: Failure, destroying our copy.\n"); - rc2 = libxl_domain_destroy(ctx, domid); + rc2 = libxl_domain_destroy(ctx, domid, 0); if (rc2) { fprintf(stderr, "migration target: Failed to destroy our copy" " (code %d).\n", rc2); @@ -5077,7 +5078,7 @@ int main_blockattach(int argc, char **argv) return 0; } - if (libxl_device_disk_add(ctx, fe_domid, &disk)) { + if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) { fprintf(stderr, "libxl_device_disk_add failed.\n"); } return 0; diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c index c4f7c52..ce7a2b2 100644 --- a/tools/python/xen/lowlevel/xl/xl.c +++ b/tools/python/xen/lowlevel/xl/xl.c @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args) int domid; if ( !PyArg_ParseTuple(args, "i", &domid) ) return NULL; - if ( libxl_domain_destroy(self->ctx, domid) ) { + if ( libxl_domain_destroy(self->ctx, domid, NULL) ) { PyErr_SetString(xl_error_obj, "cannot destroy domain"); return NULL; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:28:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:28:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY8-00088h-9J; Thu, 10 May 2012 11:28:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRY5-00087k-Tw for xen-devel@lists.xen.org; Thu, 10 May 2012 11:28:46 +0000 Received: from [85.158.143.35:53320] by server-1.bemta-4.messagelabs.com id 16/F8-20925-D66ABAF4; Thu, 10 May 2012 11:28:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336649320!11599598!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17354 invoked from network); 10 May 2012 11:28:42 -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 May 2012 11:28:42 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194234744" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:28:38 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:28:37 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRXw-0003yv-On; Thu, 10 May 2012 12:28:36 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 12:28:31 +0100 Message-ID: <1336649312-11198-4-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a rather big change, that adds the necessary machinery to perform hotplug script calling from libxl for Linux. This patch launches the necessary scripts to attach and detach PHY and TAP backend types (Qemu doesn't use hotplug scripts). Here's a list of the major changes introduced: * libxl_device_disk_add makes use of the new event library and takes the optional parameter libxl_asyncop_how, to choose how the operation has to be issued (sync or async). * Disk addition waits for backend to switch to state 2 (XenbusInitWait) and then launches the hotplug script. * Created and internal function (libxl__device_disk_add), that can be called within an already running AO, and that will plug the requested disk and execute the callback afterward. libxl_device_disk_add is a user of this newly created function. * libxl__devices_destroy no longer calls libxl__device_destroy, and instead calls libxl__initiate_device_remove, so we can disconnect the device and execute the necessary hotplug scripts instead of just deleting the backend entries. So libxl__devices_destroy now uses the event library, and so does libxl_domain_destroy, that has been converted to an AO operation function * The internal API for hotplug scripts has been added, which consists of one function; libxl__device_hotplug that takes the device and a struct with the necessary info about the action to execute. * Linux hotplug scripts are called by setting the necessary env variables to emulate udev rules, so there's no need to change them (although a rework to pass this as parameters insted of env variables would be suitable, so both NetBSD and Linux hotplug scripts take the same parameters). * Added a check in xen-hotplug-common.sh, so scripts are only executed from udev when using xend. xl adds a disable_udev=1 to xenstore libxl local directory and with the modification of the udev rules every call from udev gets UDEV_CALL passed, that points to disable_udev. If UDEV_CALL is passed and points to a value, the hotplug script is not executed. Changes since v3 (changes based on IanJ review): * Store disable_udev in libxl/disable_udev, which now is not device dependant, but backend domain dependant. * Added a global callback to device addition/destruction, that is now called when we have finished all the oprtations and handles the call to ao_complete if no other operations are pending. * Unified both device creation/destruction flows, so now all of them use the same data structure and callbacks. * Used the event interface in a proper way, and merged disk addition with the new async flow of the domain creation. * Make use of the new functions LOG, LOGE, GCNEW_ARRAY... * Passed NULL as ao_how in Python bindings. Changes since v1: * Replaced the hotplug snippet that prevents execution from udev when necessary, and now we set the env var from udev rules instead of libxl. * Replaced the libxl_device_disk_add "if" with a "switch". * Removed libxl__xs_path_cleanup (replaced with xs_rm). * Fixed several spelling mistakes. Cc: Ian Jackson Signed-off-by: Roger Pau Monne --- docs/man/xl.conf.pod.5 | 8 + tools/examples/xl.conf | 5 + tools/hotplug/Linux/xen-backend.rules | 6 +- tools/hotplug/Linux/xen-hotplug-common.sh | 6 + tools/libxl/Makefile | 3 +- tools/libxl/libxl.c | 351 +++++++-------------- tools/libxl/libxl.h | 7 +- tools/libxl/libxl_create.c | 102 ++++++- tools/libxl/libxl_device.c | 497 +++++++++++++++++++++++++---- tools/libxl/libxl_dm.c | 136 +++++---- tools/libxl/libxl_dom.c | 170 ++++++++++ tools/libxl/libxl_hotplug.c | 84 +++++ tools/libxl/libxl_internal.h | 170 ++++++++++- tools/libxl/libxl_linux.c | 126 ++++++++ tools/libxl/libxl_types.idl | 1 + tools/libxl/xl.c | 4 + tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 15 +- tools/python/xen/lowlevel/xl/xl.c | 2 +- 19 files changed, 1291 insertions(+), 403 deletions(-) create mode 100644 tools/libxl/libxl_hotplug.c diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5 index 8bd45ea..72825a0 100644 --- a/docs/man/xl.conf.pod.5 +++ b/docs/man/xl.conf.pod.5 @@ -55,6 +55,14 @@ default. Default: C<1> +=item B + +If disabled hotplug scripts will be called from udev, as it used to +be in the previous releases. With the default option, hotplug scripts +will be launched by xl directly. + +Default: C<1> + =item B Sets the path to the lock file used by xl to serialise certain diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf index 56d3b3b..75b00e0 100644 --- a/tools/examples/xl.conf +++ b/tools/examples/xl.conf @@ -12,3 +12,8 @@ # default output format used by "xl list -l" #output_format="json" + +# default option to run hotplug scripts from xl +# if disabled the old behaviour will be used, and hotplug scripts will be +# launched by udev. +#run_hotplug_scripts=1 diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index 405387f..d55ff11 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -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*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}" +SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}" SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif" SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif" SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}" -SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup" +SUBSYSTEM=="xen-backend", ACTION=="remove", ENV{UDEV_CALL}="1", 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 --git a/tools/hotplug/Linux/xen-hotplug-common.sh b/tools/hotplug/Linux/xen-hotplug-common.sh index 8f6557d..6443a63 100644 --- a/tools/hotplug/Linux/xen-hotplug-common.sh +++ b/tools/hotplug/Linux/xen-hotplug-common.sh @@ -15,6 +15,12 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # +# Hack to prevent the execution of hotplug scripts from udev if the domain +# has been launched from libxl +if [ -n "${UDEV_CALL}" ] && \ + `xenstore-read "libxl/disable_udev" >/dev/null 2>&1`; then + exit 0 +fi dir=$(dirname "$0") . "$dir/hotplugpath.sh" diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 5d9227e..9abadff 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -66,7 +66,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \ libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \ libxl_internal.o libxl_utils.o libxl_uuid.o \ libxl_json.o libxl_aoutils.o \ - libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) + libxl_qmp.o libxl_event.o libxl_fork.o libxl_hotplug.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) -include $(XEN_ROOT)/tools/config.h diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 79d7708..b438fbf 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1058,82 +1058,36 @@ 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); - char *dom_path; - char *vm_path; - char *pid; - int rc, dm_present; +/* Callback for domain destruction */ - rc = libxl_domain_info(ctx, NULL, domid); - switch(rc) { - case 0: - break; - case ERROR_INVAL: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "non-existant domain %d", domid); - default: - return rc; - } +static void domain_destroy_cb(libxl__egc *, libxl__domain_destroy_state *, int); - switch (libxl__domain_type(gc, domid)) { - case LIBXL_DOMAIN_TYPE_HVM: - dm_present = 1; - break; - case LIBXL_DOMAIN_TYPE_PV: - pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); - dm_present = (pid != NULL); - break; - default: - abort(); - } - - dom_path = libxl__xs_get_dompath(gc, domid); - if (!dom_path) { - rc = ERROR_FAIL; - goto out; - } - - if (libxl__device_pci_destroy_all(gc, domid) < 0) - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "pci shutdown failed for domid %d", domid); - rc = xc_domain_pause(ctx->xch, domid); - if (rc < 0) { - LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid); - } - if (dm_present) { - if (libxl__destroy_device_model(gc, domid) < 0) - 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); +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, + const libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx, domid, ao_how); + libxl__domain_destroy_state *dds; - vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path)); - if (vm_path) - if (!xs_rm(ctx->xsh, XBT_NULL, vm_path)) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", vm_path); + GCNEW(dds); + dds->ao = ao; + dds->domid = domid; + dds->callback = domain_destroy_cb; + libxl__domain_destroy(egc, dds); - if (!xs_rm(ctx->xsh, XBT_NULL, dom_path)) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xs_rm failed for %s", dom_path); + return AO_INPROGRESS; +} - xs_rm(ctx->xsh, XBT_NULL, libxl__xs_libxl_path(gc, domid)); +static void domain_destroy_cb(libxl__egc *egc, libxl__domain_destroy_state *dds, + int rc) +{ + STATE_AO_GC(dds->ao); - libxl__userdata_destroyall(gc, domid); + if (rc) + LOGE(ERROR, "destruction of domain %u failed", dds->domid); - rc = xc_domain_destroy(ctx->xch, domid); - if (rc < 0) { - LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy failed for %d", domid); - rc = ERROR_FAIL; - goto out; - } - rc = 0; -out: - GC_FREE; - return rc; + libxl__ao_complete(egc, ao, rc); } int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, libxl_console_type type) @@ -1261,171 +1215,56 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass) /******************************************************************************/ -int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) +/* generic callback for devices that only need to set ao_complete */ +static void libxl__device_cb(libxl__egc *egc, libxl__ao_device *aorm) { - int rc; + STATE_AO_GC(aorm->ao); - rc = libxl__device_disk_set_backend(gc, disk); - if (rc) return rc; + if (aorm->rc) { + LOGE(ERROR, "unable to %s %s with id %u", + aorm->action == DEVICE_CONNECT ? "add" : "remove", + libxl__device_kind_to_string(aorm->dev->kind), + aorm->dev->devid); + goto out; + } - return rc; +out: + libxl__ao_complete(egc, ao, aorm->rc); + return; } -static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, - libxl_device_disk *disk, - libxl__device *device) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - int devid; - - devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); - if (devid==-1) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - return ERROR_INVAL; - } - - device->backend_domid = disk->backend_domid; - device->backend_devid = devid; +/******************************************************************************/ - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_TAP: - device->backend_kind = LIBXL__DEVICE_KIND_VBD; - break; - case LIBXL_DISK_BACKEND_QDISK: - device->backend_kind = LIBXL__DEVICE_KIND_QDISK; - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", - disk->backend); - return ERROR_INVAL; - } +int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk) +{ + int rc; - device->domid = domid; - device->devid = devid; - device->kind = LIBXL__DEVICE_KIND_VBD; + rc = libxl__device_disk_set_backend(gc, disk); + if (rc) return rc; - return 0; + return rc; } -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - char *dev; - libxl__device device; - int major, minor, rc; - - rc = libxl__device_disk_setdefault(gc, disk); - if (rc) goto out; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; + int rc; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_disk_add(egc, domid, disk, device); + if (rc) { + LOGE(ERROR, "unable to add disk %s", disk->pdev_path); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - if (disk->script) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts" - " not yet supported, sorry"); - rc = ERROR_INVAL; - goto out_free; - } - - rc = libxl__device_from_disk(gc, domid, disk, &device); - if (rc != 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" - " virtual disk identifier %s", disk->vdev); - goto out_free; - } - - switch (disk->backend) { - case LIBXL_DISK_BACKEND_PHY: - dev = disk->pdev_path; - do_backend_phy: - libxl__device_physdisk_major_minor(dev, &major, &minor); - flexarray_append(back, "physical-device"); - flexarray_append(back, libxl__sprintf(gc, "%x:%x", major, minor)); - - flexarray_append(back, "params"); - flexarray_append(back, dev); - - assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD); - break; - case LIBXL_DISK_BACKEND_TAP: - dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); - if (!dev) { - rc = ERROR_FAIL; - goto out_free; - } - flexarray_append(back, "tapdisk-params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), - disk->pdev_path)); - - /* now create a phy device to export the device to the guest */ - goto do_backend_phy; - case LIBXL_DISK_BACKEND_QDISK: - flexarray_append(back, "params"); - flexarray_append(back, libxl__sprintf(gc, "%s:%s", - libxl__device_disk_string_of_format(disk->format), disk->pdev_path)); - assert(device.backend_kind == LIBXL__DEVICE_KIND_QDISK); - break; - default: - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); - rc = ERROR_INVAL; - goto out_free; - } - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "removable"); - flexarray_append(back, libxl__sprintf(gc, "%d", (disk->removable) ? 1 : 0)); - flexarray_append(back, "bootable"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "dev"); - flexarray_append(back, disk->vdev); - flexarray_append(back, "type"); - flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); - flexarray_append(back, "mode"); - flexarray_append(back, disk->readwrite ? "w" : "r"); - flexarray_append(back, "device-type"); - flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - flexarray_append(front, "virtual-device"); - flexarray_append(front, libxl__sprintf(gc, "%d", device.devid)); - flexarray_append(front, "device-type"); - flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); - - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; - -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, @@ -1433,19 +1272,25 @@ int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_disk(gc, domid, disk, &device); + GCNEW(device); + rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid, @@ -1663,12 +1508,14 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk) ret = 0; + /* fixme-ao */ libxl_device_disk_remove(ctx, domid, disks + i, 0); - libxl_device_disk_add(ctx, domid, disk); + libxl_device_disk_add(ctx, domid, disk, 0); stubdomid = libxl_get_stubdom_id(ctx, domid); if (stubdomid) { + /* fixme-ao */ libxl_device_disk_remove(ctx, stubdomid, disks + i, 0); - libxl_device_disk_add(ctx, stubdomid, disk); + libxl_device_disk_add(ctx, stubdomid, disk, 0); } out: for (i = 0; i < num; i++) @@ -1911,19 +1758,25 @@ int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_nic(gc, domid, nic, &device); + GCNEW(device); + rc = libxl__device_from_nic(gc, domid, nic, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, @@ -2273,19 +2126,25 @@ int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_vkb(gc, domid, vkb, &device); + GCNEW(device); + rc = libxl__device_from_vkb(gc, domid, vkb, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, @@ -2406,19 +2265,25 @@ int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, const libxl_asyncop_how *ao_how) { AO_CREATE(ctx, domid, ao_how); - libxl__device device; + libxl__device *device; + libxl__ao_device *aorm = 0; int rc; - rc = libxl__device_from_vfb(gc, domid, vfb, &device); + GCNEW(device); + rc = libxl__device_from_vfb(gc, domid, vfb, device); if (rc != 0) goto out; - rc = libxl__initiate_device_remove(egc, ao, &device); - if (rc) goto out; + GCNEW(aorm); + libxl__init_ao_device(aorm, ao, NULL); + aorm->action = DEVICE_DISCONNECT; + aorm->dev = device; + aorm->callback = libxl__device_cb; - return AO_INPROGRESS; + libxl__initiate_device_remove(egc, aorm); out: - return AO_ABORT(rc); + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 0ff4a83..0ab1531 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -530,7 +530,8 @@ int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info, int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid); int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid); int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid); -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid); +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, + const libxl_asyncop_how *ao_how); int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid, libxl_domain_create_info *info, const char *name_suffix, libxl_uuid new_uuid); /* get max. number of cpus supported by hypervisor */ @@ -660,7 +661,9 @@ void libxl_vminfo_list_free(libxl_vminfo *list, int nr); */ /* Disks */ -int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk); +int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, + libxl_device_disk *disk, + const libxl_asyncop_how *ao_how); int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 788e553..db58fd0 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -400,7 +400,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); - int flags, ret, rc; + int flags, ret, rc, nb_vm; char *uuid_string; char *dom_path, *vm_path, *libxl_path; struct xs_permissions roperm[2]; @@ -521,6 +521,28 @@ retry_transaction: libxl__sprintf(gc, "%s/hvmloader/generation-id-address", dom_path), rwperm, ARRAY_SIZE(rwperm)); + if (libxl_list_vm(ctx, &nb_vm) < 0) { + LOGE(ERROR, "cannot get number of running guests"); + rc = ERROR_FAIL; + goto out; + } + if (libxl_defbool_val(info->run_hotplug_scripts)) { + if (!libxl__xs_read(gc, t, DISABLE_UDEV_PATH) && (nb_vm - 1)) { + LOGE(ERROR, "cannot change hotplug execution option once set, " + "please shutdown all guests before changing it"); + rc = ERROR_FAIL; + goto out; + } + libxl__xs_write(gc, t, DISABLE_UDEV_PATH, "1"); + } else { + if (libxl__xs_read(gc, t, DISABLE_UDEV_PATH) && (nb_vm - 1)) { + LOGE(ERROR, "cannot change hotplug execution option once set, " + "please shutdown all guests before changing it"); + rc = ERROR_FAIL; + goto out; + } + xs_rm(ctx->xsh, t, DISABLE_UDEV_PATH); + } 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)); @@ -577,15 +599,25 @@ static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int rc); +static void domcreate_disk_connected(libxl__egc *egc, + libxl__ao_device *aorm); + static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); /* Our own function to clean up and call the user's callback. - * The final call in the sequence. */ + * The final call in the sequence if domain creation is successful. */ static void domcreate_complete(libxl__egc *egc, libxl__domain_create_state *dcs, int rc); +/* If creation is not successful, this callback will be executed + * when domain destruction is finished */ + +static void domcreate_destruction_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc); + static void initiate_domain_create(libxl__egc *egc, libxl__domain_create_state *dcs) { @@ -700,8 +732,13 @@ static void domcreate_bootloader_done(libxl__egc *egc, store_libxl_entry(gc, domid, &d_config->b_info); + GCNEW_ARRAY(dcs->devices, d_config->num_disks); + dcs->num_devices = d_config->num_disks; for (i = 0; i < d_config->num_disks; i++) { - ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]); + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_disk_connected; + ret = libxl__device_disk_add(egc, domid, &d_config->disks[i], + &dcs->devices[i]); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot add disk %d to domain: %d", i, ret); @@ -718,6 +755,42 @@ static void domcreate_bootloader_done(libxl__egc *egc, goto error_out; } } + return; + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int i, last, ret = 0; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + libxl__domain_build_state *const state = &dcs->build_state; + libxl_ctx *const ctx = CTX; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting disk devices"); + goto error_out; + } + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; + switch (d_config->c_info.type) { case LIBXL_DOMAIN_TYPE_HVM: { @@ -853,16 +926,31 @@ static void domcreate_complete(libxl__egc *egc, if (rc) { if (dcs->guest_domid) { - int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid); - if (rc2) - LOG(ERROR, "unable to destroy domain %d following" - " failed creation", dcs->guest_domid); + dcs->dds.ao = ao; + dcs->dds.domid = dcs->guest_domid; + dcs->dds.callback = domcreate_destruction_cb; + libxl__domain_destroy(egc, &dcs->dds); + return; } dcs->guest_domid = -1; } dcs->callback(egc, dcs, rc, dcs->guest_domid); } +static void domcreate_destruction_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc) +{ + STATE_AO_GC(dds->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(dds, *dcs, dds); + + if (rc) + LOG(ERROR, "unable to destroy domain %u following failed creation", + dds->domid); + + dcs->callback(egc, dcs, rc, dcs->guest_domid); +} + /*----- application-facing domain creation interface -----*/ typedef struct { diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c7e057d..275ab43 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -58,6 +58,48 @@ int libxl__parse_backend_path(libxl__gc *gc, return libxl__device_kind_from_string(strkind, &dev->backend_kind); } +static int libxl__num_devices(libxl__gc *gc, uint32_t domid) +{ + char *path; + unsigned int num_kinds, num_devs; + char **kinds = NULL, **devs = NULL; + int i, j, rc = 0; + libxl__device dev; + libxl__device_kind kind; + int numdevs = 0; + + path = GCSPRINTF("/local/domain/%d/device", domid); + kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds); + if (!kinds) { + if (errno != ENOENT) { + LOGE(ERROR, "unable to get xenstore device listing %s", path); + rc = ERROR_FAIL; + goto out; + } + num_kinds = 0; + } + for (i = 0; i < num_kinds; i++) { + if (libxl__device_kind_from_string(kinds[i], &kind)) + continue; + + path = GCSPRINTF("/local/domain/%d/device/%s", domid, kinds[i]); + devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs); + if (!devs) + continue; + for (j = 0; j < num_devs; j++) { + path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend", + domid, kinds[i], devs[j]); + path = libxl__xs_read(gc, XBT_NULL, path); + if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { + numdevs++; + } + } + } +out: + if (rc) return rc; + return numdevs; +} + int libxl__device_generic_add(libxl__gc *gc, libxl__device *device, char **bents, char **fents) { @@ -110,6 +152,178 @@ retry_transaction: return 0; } +int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int devid; + + devid = libxl__device_disk_dev_number(disk->vdev, NULL, NULL); + if (devid == -1) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" + " virtual disk identifier %s", disk->vdev); + return ERROR_INVAL; + } + + device->backend_domid = disk->backend_domid; + device->backend_devid = devid; + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_TAP: + device->backend_kind = LIBXL__DEVICE_KIND_VBD; + break; + case LIBXL_DISK_BACKEND_QDISK: + device->backend_kind = LIBXL__DEVICE_KIND_QDISK; + break; + default: + LOGE(ERROR, "unrecognized disk backend type: %d", disk->backend); + return ERROR_INVAL; + } + + device->domid = domid; + device->devid = devid; + device->kind = LIBXL__DEVICE_KIND_VBD; + + return 0; +} + +int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, + libxl_device_disk *disk, + libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front = NULL; + flexarray_t *back = NULL; + char *dev; + libxl__device *device; + int major, minor, rc; + + rc = libxl__device_disk_setdefault(gc, disk); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(20, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + if (disk->script) { + LOGE(ERROR, "External block scripts not yet supported, sorry"); + rc = ERROR_INVAL; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_disk(gc, domid, disk, device); + if (rc != 0) { + LOGE(ERROR, "Invalid or unsupported virtual disk identifier %s", + disk->vdev); + goto out; + } + + switch (disk->backend) { + case LIBXL_DISK_BACKEND_PHY: + dev = disk->pdev_path; + do_backend_phy: + libxl__device_physdisk_major_minor(dev, &major, &minor); + flexarray_append(back, "physical-device"); + flexarray_append(back, GCSPRINTF("%x:%x", major, minor)); + + flexarray_append(back, "params"); + flexarray_append(back, dev); + + flexarray_append(back, "script"); + flexarray_append(back, GCSPRINTF("%s/%s", + libxl__xen_script_dir_path(), + "block")); + + assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD); + break; + case LIBXL_DISK_BACKEND_TAP: + dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format); + if (!dev) { + rc = ERROR_FAIL; + goto out_free; + } + flexarray_append(back, "tapdisk-params"); + flexarray_append(back, GCSPRINTF("%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + + flexarray_append(back, "script"); + flexarray_append(back, GCSPRINTF("%s/%s", + libxl__xen_script_dir_path(), + "blktap")); + + /* now create a phy device to export the device to the guest */ + goto do_backend_phy; + case LIBXL_DISK_BACKEND_QDISK: + flexarray_append(back, "params"); + flexarray_append(back, GCSPRINTF("%s:%s", + libxl__device_disk_string_of_format(disk->format), + disk->pdev_path)); + assert(device->backend_kind == LIBXL__DEVICE_KIND_QDISK); + break; + default: + LOGE(ERROR, "unrecognized disk backend type: %d", disk->backend); + rc = ERROR_INVAL; + goto out_free; + } + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "removable"); + flexarray_append(back, GCSPRINTF("%d", (disk->removable) ? 1 : 0)); + flexarray_append(back, "bootable"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "dev"); + flexarray_append(back, disk->vdev); + flexarray_append(back, "type"); + flexarray_append(back, libxl__device_disk_string_of_backend(disk->backend)); + flexarray_append(back, "mode"); + flexarray_append(back, disk->readwrite ? "w" : "r"); + flexarray_append(back, "device-type"); + flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", disk->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + flexarray_append(front, "virtual-device"); + flexarray_append(front, GCSPRINTF("%d", device->devid)); + flexarray_append(front, "device-type"); + flexarray_append(front, disk->is_cdrom ? "cdrom" : "disk"); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aorm->dev = device; + aorm->action = DEVICE_CONNECT; + libxl__initiate_device_add(egc, aorm); + + rc = 0; + +out_free: + flexarray_free(back); + flexarray_free(front); +out: + return rc; +} + typedef struct { libxl__gc *gc; libxl_device_disk *disk; @@ -356,49 +570,116 @@ 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) { +static void device_backend_cleanup(libxl__gc *gc, libxl__ao_device *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); +void libxl__init_ao_device(libxl__ao_device *aorm, libxl__ao *ao, + libxl__ao_device **base) +{ + aorm->ao = ao; + aorm->state = DEVICE_ACTIVE; + aorm->rc = 0; + aorm->base = base; } -int libxl__initiate_device_remove(libxl__egc *egc, libxl__ao *ao, - libxl__device *dev) +int libxl__ao_device_check_last(libxl__gc *gc, libxl__ao_device *device, + libxl__ao_device *list, int num, int *last) { - AO_GC; - libxl_ctx *ctx = libxl__gc_owner(gc); - xs_transaction_t t; - char *be_path = libxl__device_backend_path(gc, dev); + int i, ret = 0; + + device->state = DEVICE_FINISHED; + *last = 1; + for (i = 0; i < num; i++) { + if (list[i].state != DEVICE_FINISHED && *last) { + *last = 0; + if (!device->rc) break; + } + if (device->rc && device->action == DEVICE_CONNECT) { + /* Cancel pending events */ + if (list[i].pid) { + libxl__ev_time_deregister(gc, &list[i].ev); + kill(list[i].pid, SIGKILL); + } else { + libxl__ev_devstate_cancel(gc, &list[i].ds); + } + ret = list[i].rc; + } + } + return ret; +} + +/* Common callbacks for device add/remove */ + +static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds, + int rc); + +void libxl__initiate_device_add(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + char *be_path = libxl__device_backend_path(gc, aorm->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 (aorm->dev->backend_kind == LIBXL__DEVICE_KIND_QDISK) { + aorm->callback(egc, aorm); + return; + } + + if (atoi(state) == XenbusStateInitWait) + goto out_ok; + + libxl__ev_devstate_init(&aorm->ds); + rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_backend_callback, + state_path, XenbusStateInitWait, + LIBXL_INIT_TIMEOUT * 1000); + if (rc) { + LOGE(ERROR, "unable to initialize device %s", be_path); + goto out_fail; + } + + return; + +out_fail: + assert(rc); + aorm->rc = rc; + aorm->callback(egc, aorm); + return; + +out_ok: + libxl__device_hotplug(egc, aorm); + return; +} + +void libxl__initiate_device_remove(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl_ctx *ctx = libxl__gc_owner(gc); + xs_transaction_t t = 0; + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *state_path = libxl__sprintf(gc, "%s/state", be_path); + char *state; + int rc = 0; + + if (aorm->force) + libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev)); + /* Remove frontend xs paths to force backend disconnection */ + +retry_transaction: + t = xs_transaction_start(ctx->xsh); + state = libxl__xs_read(gc, t, state_path); if (!state) goto out_ok; - if (atoi(state) != 4) { + if (atoi(state) != XenbusStateConnected && + atoi(state) != XenbusStateClosing) { libxl__device_destroy_tapdisk(gc, be_path); - xs_rm(ctx->xsh, XBT_NULL, be_path); goto out_ok; } -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, GCSPRINTF("%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) @@ -408,60 +689,67 @@ retry_transaction: goto out_fail; } } + /* mark transaction as ended, to prevent double closing it on out_ok */ + t = 0; 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, + rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_backend_callback, state_path, XenbusStateClosed, LIBXL_DESTROY_TIMEOUT * 1000); - if (rc) goto out_fail; + if (rc) { + LOGE(ERROR, "unable to remove device %s", be_path); + goto out_fail; + } - return 0; + return; out_fail: assert(rc); - device_remove_cleanup(gc, aorm); - return rc; + aorm->rc = rc; + aorm->callback(egc, aorm); + return; out_ok: - libxl__ao_complete(egc, ao, 0); - return 0; + if (t) xs_transaction_end(ctx->xsh, t, 0); + libxl__device_hotplug(egc, aorm); + return; } -int libxl__device_destroy(libxl__gc *gc, libxl__device *dev) -{ - libxl_ctx *ctx = libxl__gc_owner(gc); - char *be_path = libxl__device_backend_path(gc, dev); - char *fe_path = libxl__device_frontend_path(gc, dev); - - xs_rm(ctx->xsh, XBT_NULL, be_path); - xs_rm(ctx->xsh, XBT_NULL, fe_path); - - libxl__device_destroy_tapdisk(gc, be_path); +/* Callback for device destruction */ - return 0; -} +static void device_remove_callback(libxl__egc *egc, libxl__ao_device *aorm); -int libxl__devices_destroy(libxl__gc *gc, uint32_t domid) +void libxl__devices_destroy(libxl__egc *egc, libxl__devices_remove_state *drs) { - libxl_ctx *ctx = libxl__gc_owner(gc); + STATE_AO_GC(drs->ao); char *path; unsigned int num_kinds, num_devs; char **kinds = NULL, **devs = NULL; - int i, j; - libxl__device dev; + int i, j, rc = 0, numdev = 0; + libxl__device *dev; libxl__device_kind kind; - path = libxl__sprintf(gc, "/local/domain/%d/device", domid); + drs->num_devices = libxl__num_devices(gc, drs->domid); + if (drs->num_devices < 0) { + LOGE(ERROR, "unable to get number of devices for domain %u", + drs->domid); + rc = ERROR_FAIL; + goto out; + } + + GCNEW_ARRAY(drs->aorm, drs->num_devices); + for (i = 0; i < drs->num_devices; i++) { + libxl__init_ao_device(&drs->aorm[i], drs->ao, &drs->aorm); + } + + path = GCSPRINTF("/local/domain/%d/device", drs->domid); kinds = libxl__xs_directory(gc, XBT_NULL, path, &num_kinds); if (!kinds) { if (errno != ENOENT) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to get xenstore" - " device listing %s", path); + LOGE(ERROR, "unable to get xenstore device listing %s", path); + rc = ERROR_FAIL; goto out; } num_kinds = 0; @@ -470,37 +758,106 @@ int libxl__devices_destroy(libxl__gc *gc, uint32_t domid) if (libxl__device_kind_from_string(kinds[i], &kind)) continue; - path = libxl__sprintf(gc, "/local/domain/%d/device/%s", domid, kinds[i]); + path = GCSPRINTF("/local/domain/%d/device/%s", drs->domid, kinds[i]); devs = libxl__xs_directory(gc, XBT_NULL, path, &num_devs); if (!devs) continue; for (j = 0; j < num_devs; j++) { - path = libxl__sprintf(gc, "/local/domain/%d/device/%s/%s/backend", - domid, kinds[i], devs[j]); + path = GCSPRINTF("/local/domain/%d/device/%s/%s/backend", + drs->domid, kinds[i], devs[j]); path = libxl__xs_read(gc, XBT_NULL, path); - if (path && libxl__parse_backend_path(gc, path, &dev) == 0) { - dev.domid = domid; - dev.kind = kind; - dev.devid = atoi(devs[j]); - - libxl__device_destroy(gc, &dev); + GCNEW(dev); + if (path && libxl__parse_backend_path(gc, path, dev) == 0) { + dev->domid = drs->domid; + dev->kind = kind; + dev->devid = atoi(devs[j]); + drs->aorm[numdev].action = DEVICE_DISCONNECT; + drs->aorm[numdev].dev = dev; + drs->aorm[numdev].callback = device_remove_callback; + libxl__initiate_device_remove(egc, &drs->aorm[numdev]); + numdev++; } } } /* console 0 frontend directory is not under /local/domain//device */ - path = libxl__sprintf(gc, "/local/domain/%d/console/backend", domid); + path = GCSPRINTF("/local/domain/%d/console/backend", drs->domid); path = libxl__xs_read(gc, XBT_NULL, path); + GCNEW(dev); if (path && strcmp(path, "") && - libxl__parse_backend_path(gc, path, &dev) == 0) { - dev.domid = domid; - dev.kind = LIBXL__DEVICE_KIND_CONSOLE; - dev.devid = 0; + libxl__parse_backend_path(gc, path, dev) == 0) { + dev->domid = drs->domid; + dev->kind = LIBXL__DEVICE_KIND_CONSOLE; + dev->devid = 0; - libxl__device_destroy(gc, &dev); + libxl__device_destroy(gc, dev); } out: + if (!numdev) drs->callback(egc, drs, rc); + return; +} + +static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds, + int rc) +{ + libxl__ao_device *aorm = CONTAINER_OF(ds, *aorm, ds); + STATE_AO_GC(aorm->ao); + + device_backend_cleanup(gc, aorm); + + if (rc == ERROR_TIMEDOUT && aorm->action == DEVICE_DISCONNECT && + !aorm->force) { + aorm->force = 1; + libxl__initiate_device_remove(egc, aorm); + return; + } + + if (rc) { + LOGE(ERROR, "unable to %s device with path %s", + aorm->action == DEVICE_DISCONNECT ? "disconnect" : + "connect", + libxl__device_backend_path(gc, aorm->dev)); + goto error; + } + + libxl__device_hotplug(egc, aorm); + return; + +error: + aorm->rc = rc; + aorm->callback(egc, aorm); + return; +} + +static void device_remove_callback(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__devices_remove_state *drs = CONTAINER_OF(aorm->base, *drs, aorm); + int rc = 0, last; + + if (aorm->action == DEVICE_DISCONNECT) { + libxl__xs_path_cleanup(gc, libxl__device_frontend_path(gc, aorm->dev)); + libxl__xs_path_cleanup(gc, libxl__device_backend_path(gc, aorm->dev)); + } + + rc = libxl__ao_device_check_last(gc, aorm, drs->aorm, + drs->num_devices, &last); + + if (last) + drs->callback(egc, drs, rc); + return; +} + +int libxl__device_destroy(libxl__gc *gc, libxl__device *dev) +{ + char *be_path = libxl__device_backend_path(gc, dev); + char *fe_path = libxl__device_frontend_path(gc, dev); + + libxl__xs_path_cleanup(gc, be_path); + libxl__xs_path_cleanup(gc, fe_path); + + libxl__device_destroy_tapdisk(gc, be_path); return 0; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 5de3aef..b2622ee 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -660,6 +660,8 @@ retry_transaction: return 0; } +static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm); + static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, libxl__dm_spawn_state *stubdom_dmss, int rc); @@ -668,8 +670,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { STATE_AO_GC(sdss->dm.spawn.ao); libxl_ctx *ctx = libxl__gc_owner(gc); - int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret; - libxl__device_console *console; + int i, ret; libxl_device_vfb vfb; libxl_device_vkb vkb; char **args; @@ -787,22 +788,66 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; + GCNEW_ARRAY(sdss->devices, dm_config->num_disks); + sdss->num_devices = dm_config->num_disks; for (i = 0; i < dm_config->num_disks; i++) { - ret = libxl_device_disk_add(ctx, dm_domid, &dm_config->disks[i]); - if (ret) + libxl__init_ao_device(&sdss->devices[i], ao, &sdss->devices); + sdss->devices[i].callback = spawn_stub_disk_connected; + ret = libxl__device_disk_add(egc, dm_domid, &dm_config->disks[i], + &sdss->devices[i]); + if (ret) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "cannot add disk %d to domain: %d", i, ret); + ret = ERROR_FAIL; goto out_free; + } + } + + free(args); + return; + +out_free: + free(args); +out: + assert(ret); + spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); +} + +static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl_ctx *ctx = libxl__gc_owner(gc); + libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(aorm->base, *sdss, devices); + int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret = 0, last; + libxl__device_console *console; + + /* convenience aliases */ + libxl_domain_config *const dm_config = &sdss->dm_config; + libxl_domain_config *const guest_config = sdss->dm.guest_config; + const int guest_domid = sdss->dm.guest_domid; + libxl__domain_build_state *const d_state = sdss->dm.build_state; + libxl__domain_build_state *const stubdom_state = &sdss->dm_state; + uint32_t dm_domid = sdss->pvqemu.guest_domid; + + ret = libxl__ao_device_check_last(gc, aorm, sdss->devices, + sdss->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting disk devices"); + goto out; } + for (i = 0; i < dm_config->num_vifs; i++) { ret = libxl_device_nic_add(ctx, dm_domid, &dm_config->vifs[i]); if (ret) - goto out_free; + goto out; } ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); if (ret) - goto out_free; + goto out; ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); if (ret) - goto out_free; + goto out; if (guest_config->b_info.u.hvm.serial) num_console++; @@ -810,7 +855,7 @@ retry_transaction: console = libxl__calloc(gc, num_console, sizeof(libxl__device_console)); if (!console) { ret = ERROR_NOMEM; - goto out_free; + goto out; } for (i = 0; i < num_console; i++) { @@ -846,7 +891,7 @@ retry_transaction: ret = libxl__device_console_add(gc, dm_domid, &console[i], i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL); if (ret) - goto out_free; + goto out; } sdss->pvqemu.guest_domid = dm_domid; @@ -856,13 +901,9 @@ retry_transaction: libxl__spawn_local_dm(egc, &sdss->pvqemu); - free(args); return; -out_free: - free(args); out: - assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); } @@ -883,7 +924,7 @@ static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, out: if (rc) { if (dm_domid) - libxl_domain_destroy(CTX, dm_domid); + libxl_domain_destroy(CTX, dm_domid, 0); } sdss->callback(egc, &sdss->dm, rc); } @@ -1075,62 +1116,35 @@ static void device_model_spawn_outcome(libxl__egc *egc, int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) { - libxl_ctx *ctx = libxl__gc_owner(gc); char *pid; int ret; - pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/image/device-model-pid", domid)); - if (!pid) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); - ret = ERROR_INVAL; - goto out; - } - if (!atoi(pid)) { - int stubdomid = libxl_get_stubdom_id(ctx, domid); - const char *savefile; - - if (!stubdomid) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't find device model's pid"); + pid = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("/local/domain/%d/image/device-model-pid", + domid)); + if (!pid || !atoi(pid)) { + LOGE(ERROR, "Couldn't find device model's pid"); ret = ERROR_INVAL; goto out; - } - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device model is a stubdom, domid=%d", stubdomid); - ret = libxl_domain_destroy(ctx, stubdomid); - if (ret) - goto out; - - savefile = libxl__device_model_savefile(gc, domid); - ret = unlink(savefile); - /* - * On suspend libxl__domain_save_device_model will have already - * unlinked the save file. - */ - if (ret && errno == ENOENT) ret = 0; - if (ret) { - LIBXL__LOG_ERRNO(ctx, XTL_ERROR, - "failed to remove device-model savefile %s\n", - savefile); - goto out; - } + } + ret = kill(atoi(pid), SIGHUP); + if (ret < 0 && errno == ESRCH) { + LOG(DEBUG, "Device Model already exited"); + ret = 0; + } else if (ret == 0) { + LOG(DEBUG, "Device Model signaled"); + ret = 0; } else { - ret = kill(atoi(pid), SIGHUP); - if (ret < 0 && errno == ESRCH) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model already exited"); - ret = 0; - } else if (ret == 0) { - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Device Model signaled"); - ret = 0; - } else { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to kill Device Model [%d]", - atoi(pid)); - ret = ERROR_FAIL; - goto out; - } + LOGEV(ERROR, errno, "failed to kill Device Model [%d]", atoi(pid)); + ret = ERROR_FAIL; + goto out; } out: - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid)); - xs_rm(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid)); + xs_rm(CTX->xsh, XBT_NULL, GCSPRINTF("/local/domain/0/device-model/%d", + domid)); + xs_rm(CTX->xsh, XBT_NULL, GCSPRINTF("/local/domain/%d/hvmloader", + domid)); return ret; } diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index c246211..9b016e8 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -973,6 +973,176 @@ out: return rc; } +/* Callbacks for libxl__domain_destroy */ +static void stubdom_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc); +static void domain_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc); + +void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds) +{ + STATE_AO_GC(dds->ao); + uint32_t stubdomid = libxl_get_stubdom_id(CTX, dds->domid); + + if (stubdomid) { + dds->stubdom.ao = ao; + dds->stubdom.domid = stubdomid; + dds->stubdom.callback = stubdom_callback; + libxl__destroy_domid(egc, &dds->stubdom); + } else { + dds->stubdom_finished = 1; + } + + dds->domain.ao = ao; + dds->domain.domid = dds->domid; + dds->domain.callback = domain_callback; + libxl__destroy_domid(egc, &dds->domain); +} + +static void stubdom_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc) +{ + STATE_AO_GC(dis->ao); + libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, stubdom); + const char *savefile; + + if (rc) + LOGE(ERROR, "unable to destroy stubdom with domid %u", dis->domid); + + dds->stubdom_finished = 1; + savefile = libxl__device_model_savefile(gc, dis->domid); + rc = unlink(savefile); + /* + * On suspend libxl__domain_save_device_model will have already + * unlinked the save file. + */ + if (rc && errno == ENOENT) rc = 0; + if (rc) { + LOGEV(ERROR, errno, "failed to remove device-model savefile %s", + savefile); + } + + if (dds->domain_finished) + dds->callback(egc, dds, rc); +} + +static void domain_callback(libxl__egc *egc, libxl__destroy_domid_state *dis, + int rc) +{ + STATE_AO_GC(dis->ao); + libxl__domain_destroy_state *dds = CONTAINER_OF(dis, *dds, domain); + + if (rc) + LOGE(ERROR, "unable to destroy guest with domid %u", dis->domid); + + dds->domain_finished = 1; + if (dds->stubdom_finished) + dds->callback(egc, dds, rc); +} + +/* Callbacks for libxl__domain_clean */ + +/* Device destruction callback */ +static void devices_destroy_cb(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc); + +void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis) +{ + STATE_AO_GC(dis->ao); + int rc; + + rc = libxl_domain_info(CTX, NULL, dis->domid); + switch (rc) { + case 0: + break; + case ERROR_INVAL: + LOGE(ERROR, "non-existant domain %d", dis->domid); + default: + goto out; + } + + switch (libxl__domain_type(gc, dis->domid)) { + case LIBXL_DOMAIN_TYPE_HVM: + dis->dm_present = 1; + break; + case LIBXL_DOMAIN_TYPE_PV: + dis->pid = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("/local/domain/%d/image/device-model-pid", + dis->domid)); + dis->dm_present = (dis->pid != NULL); + break; + default: + abort(); + } + + dis->dom_path = libxl__xs_get_dompath(gc, dis->domid); + if (!dis->dom_path) { + rc = ERROR_FAIL; + goto out; + } + + if (libxl__device_pci_destroy_all(gc, dis->domid) < 0) + LOGE(ERROR, "pci shutdown failed for domid %d", dis->domid); + rc = xc_domain_pause(CTX->xch, dis->domid); + if (rc < 0) { + LOGEV(ERROR, rc, "xc_domain_pause failed for %d", dis->domid); + } + if (dis->dm_present) { + rc = libxl__destroy_device_model(gc, dis->domid); + if (rc < 0) + LOGE(ERROR, "libxl__destroy_device_model failed for %d", + dis->domid); + libxl__qmp_cleanup(gc, dis->domid); + } + dis->drs.ao = ao; + dis->drs.domid = dis->domid; + dis->drs.callback = devices_destroy_cb; + libxl__devices_destroy(egc, &dis->drs); + return; + +out: + assert(rc); + dis->callback(egc, dis, rc); + return; +} + +static void devices_destroy_cb(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc) +{ + STATE_AO_GC(drs->ao); + libxl__destroy_domid_state *dis = CONTAINER_OF(drs, *dis, drs); + + if (rc < 0) + LOGE(ERROR, "libxl__devices_destroy failed for %d", dis->domid); + + dis->vm_path = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/vm", + dis->dom_path)); + if (dis->vm_path) + if (!xs_rm(CTX->xsh, XBT_NULL, dis->vm_path)) + LOGE(ERROR, "xs_rm failed for %s", dis->vm_path); + + if (!xs_rm(CTX->xsh, XBT_NULL, dis->dom_path)) + LOGE(ERROR, "xs_rm failed for %s", dis->dom_path); + + xs_rm(CTX->xsh, XBT_NULL, libxl__xs_libxl_path(gc, dis->domid)); + + libxl__userdata_destroyall(gc, dis->domid); + + rc = xc_domain_destroy(CTX->xch, dis->domid); + if (rc < 0) { + LOGEV(ERROR, rc, "xc_domain_destroy failed for %d", dis->domid); + rc = ERROR_FAIL; + goto out; + } + rc = 0; + +out: + dis->callback(egc, dis, rc); + return; +} + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_hotplug.c b/tools/libxl/libxl_hotplug.c new file mode 100644 index 0000000..686a38d --- /dev/null +++ b/tools/libxl/libxl_hotplug.c @@ -0,0 +1,84 @@ +/* + * Copyright (C) 2012 + * Author Roger Pau Monne + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include "libxl_osdeps.h" /* must come before any other headers */ + +#include "libxl_internal.h" + +/* + * Generic hotplug helpers + * + * This helpers are both used by Linux and NetBSD hotplug script + * dispatcher functions. + */ + +static void device_hotplug_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs) +{ + libxl__ao_device *aorm = CONTAINER_OF(ev, *aorm, ev); + STATE_AO_GC(aorm->ao); + + if (!aorm) return; + if (libxl__ev_child_inuse(&aorm->child)) { + if (kill(aorm->pid, SIGKILL)) { + LOGEV(ERROR, errno, "unable to kill hotplug script %s [%ld]", + aorm->what, (unsigned long)aorm->pid); + goto out; + } + } + +out: + libxl__ev_time_deregister(gc, &aorm->ev); + return; +} + +int libxl__hotplug_launch(libxl__gc *gc, libxl__ao_device *aorm, + const char *arg0, char *const args[], + char *const env[], libxl__ev_child_callback *death) +{ + int rc = 0; + pid_t pid = -1; + + libxl__ev_time_init(&aorm->ev); + libxl__ev_child_init(&aorm->child); + + rc = libxl__ev_time_register_rel(gc, &aorm->ev, device_hotplug_timeout, + LIBXL_HOTPLUG_TIMEOUT * 1000); + if (rc) { + LOGE(ERROR, "unable to register timeout for hotplug script %s", arg0); + goto out; + } + + pid = libxl__ev_child_fork(gc, &aorm->child, death); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; + } + if (!pid) { + /* child */ + libxl__exec(gc, -1, -1, -1, arg0, args, env); + LOGE(ERROR, "unable execute hotplug scripts for device %"PRIu32 " on " + "dom %"PRIu32, aorm->dev->devid, aorm->dev->backend_domid); + abort(); + } +out: + if (libxl__ev_child_inuse(&aorm->child)) { + aorm->pid = pid; + /* we will get a callback when the child dies */ + return 0; + } + libxl__ev_time_deregister(gc, &aorm->ev); + return rc; +} diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index fc2024d..faeb965 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -71,6 +71,8 @@ #include "_libxl_types_internal_json.h" #define LIBXL_DESTROY_TIMEOUT 10 +#define LIBXL_INIT_TIMEOUT 10 +#define LIBXL_HOTPLUG_TIMEOUT 10 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10 #define LIBXL_XENCONSOLE_LIMIT 1048576 #define LIBXL_XENCONSOLE_PROTOCOL "vt100" @@ -85,6 +87,7 @@ #define STUBDOM_CONSOLE_SERIAL 3 #define STUBDOM_SPECIAL_CONSOLES 3 #define TAP_DEVICE_SUFFIX "-emu" +#define DISABLE_UDEV_PATH "libxl/disable_udev" #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) @@ -779,6 +782,9 @@ _hidden int libxl__domain_pvcontrol_write(libxl__gc *gc, xs_transaction_t t, _hidden char *libxl__device_disk_string_of_backend(libxl_disk_backend backend); _hidden char *libxl__device_disk_string_of_format(libxl_disk_format format); _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*); +_hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, + libxl_device_disk *disk, + libxl__device *device); _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor); _hidden int libxl__device_disk_dev_number(const char *virtpath, @@ -795,7 +801,6 @@ _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_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); /* @@ -826,13 +831,6 @@ _hidden const char *libxl__device_nic_devname(libxl__gc *gc, uint32_t devid, libxl_nic_type type); -/* 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__egc*, libxl__ao*, - libxl__device *dev); - /* * libxl__ev_devstate - waits a given time for a device to * reach a given state. Follows the libxl_ev_* conventions. @@ -918,6 +916,65 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int num); _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid); +/*----- device addition/removal -----*/ + +/* During the init/destruction process, the device can be in several states: + * + * DEVICE_UNKNOWN: device in unknown state (default value when struct is + * initialized). + * + * DEVICE_WAIT_BACKEND: waiting for the backend to switch to XenbusStateInit or + * XenbusStateClosed. + * + * DEVICE_WAIT_HOTPLUG: waiting for hotplug script to finish execution. + * + * DEVICE_FINISHED: device is connected/disconnected. + */ +typedef enum { + DEVICE_ACTIVE, + DEVICE_FINISHED +} libxl__device_state; + +/* Action to perform (either connect or disconnect) */ +typedef enum { + DEVICE_CONNECT, + DEVICE_DISCONNECT +} libxl__device_action; + +typedef struct libxl__ao_device libxl__ao_device; +typedef void libxl__device_callback(libxl__egc*, libxl__ao_device*); + +_hidden void libxl__init_ao_device(libxl__ao_device *aorm, libxl__ao *ao, + libxl__ao_device **base); +_hidden int libxl__ao_device_check_last(libxl__gc *gc, libxl__ao_device *device, + libxl__ao_device *list, + int num, int *last); + +struct libxl__ao_device { + libxl__ao *ao; + /* State in which the device is */ + libxl__device_state state; + /* action being performed */ + libxl__device_action action; + /* device teardown (back for xenstore backend to connect/disconnect) */ + libxl__device *dev; + int force; + /* device hotplug execution */ + pid_t pid; + char *what; + libxl__device_callback *callback; + /* private for implementation */ + int rc; + libxl__ev_time ev; + libxl__ev_child child; + libxl__ev_devstate ds; + void *base; +}; + +_hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, + libxl_device_disk *disk, + libxl__ao_device *aorm); + /* *----- spawn ----- * @@ -1106,6 +1163,8 @@ typedef struct { libxl_domain_config dm_config; libxl__domain_build_state dm_state; libxl__dm_spawn_state pvqemu; + libxl__ao_device *devices; + int num_devices; } libxl__stub_dm_spawn_state; _hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*); @@ -1797,6 +1856,98 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); * If callback is passed rc==0, will have updated st->info appropriately */ _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); +/* + * libxl__hotplug_launch is an internal function that should not be used + * directly, all hotplug script calls have to implement and use + * libxl__device_hotplug. + */ +_hidden void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm); +_hidden int libxl__hotplug_launch(libxl__gc *gc, libxl__ao_device *aorm, + const char *arg0, char *const args[], + char *const env[], + libxl__ev_child_callback *death); + +/* Arranges that dev will be added to the guest, and the + * hotplug scripts will be executed (if necessary). When + * this is done (or an error happens), the callback in + * aorm->callback will be called. + */ +_hidden void libxl__initiate_device_add(libxl__egc*, libxl__ao_device *aorm); + +/* Arranges that dev will be removed to the guest, and the + * hotplug scripts will be executed (if necessary). When + * this is done (or an error happens), the callback in + * aorm->callback will be called. + */ +_hidden void libxl__initiate_device_remove(libxl__egc *egc, + libxl__ao_device *aorm); + +/*----- Domain destruction -----*/ + +typedef struct libxl__domain_destroy_state libxl__domain_destroy_state; +typedef struct libxl__destroy_domid_state libxl__destroy_domid_state; +typedef struct libxl__devices_remove_state libxl__devices_remove_state; + +typedef void libxl__domain_destroy_cb(libxl__egc *egc, + libxl__domain_destroy_state *dds, + int rc); + +typedef void libxl__domain_clean_cb(libxl__egc *egc, + libxl__destroy_domid_state *dis, + int rc); + +typedef void libxl__devices_remove_callback(libxl__egc *egc, + libxl__devices_remove_state *drs, + int rc); + +struct libxl__devices_remove_state { + /* set by user */ + libxl__ao *ao; + uint32_t domid; + libxl__devices_remove_callback *callback; + /* private */ + libxl__ao_device *aorm; + int num_devices; +}; + +struct libxl__destroy_domid_state { + /* filled in by user */ + libxl__ao *ao; + uint32_t domid; + libxl__domain_clean_cb *callback; + /* private to implementation */ + libxl__devices_remove_state drs; + char *dom_path; + char *vm_path; + char *pid; + int dm_present; +}; + +struct libxl__domain_destroy_state { + /* filled by the user */ + libxl__ao *ao; + uint32_t domid; + libxl__domain_destroy_cb *callback; + /* Private */ + uint32_t stubdomid; + libxl__destroy_domid_state stubdom; + int stubdom_finished; + libxl__destroy_domid_state domain; + int domain_finished; +}; + +/* Entry point for domain destruction */ +_hidden void libxl__domain_destroy(libxl__egc *egc, + libxl__domain_destroy_state *dds); + +/* Used to destroy a domain with the passed id (it doesn't check for stubs) */ +_hidden void libxl__destroy_domid(libxl__egc *egc, + libxl__destroy_domid_state *dis); + +/* Entry point for devices destruction */ +_hidden void libxl__devices_destroy(libxl__egc *egc, + libxl__devices_remove_state *drs); + /*----- Domain creation -----*/ typedef struct libxl__domain_create_state libxl__domain_create_state; @@ -1816,6 +1967,9 @@ struct libxl__domain_create_state { int guest_domid; libxl__domain_build_state build_state; libxl__bootloader_state bl; + libxl__ao_device *devices; + int num_devices; + libxl__domain_destroy_state dds; libxl__stub_dm_spawn_state dmss; /* If we're not doing stubdom, we use only dmss.dm, * for the non-stubdom device model. */ diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c index 925248b..315ce15 100644 --- a/tools/libxl/libxl_linux.c +++ b/tools/libxl/libxl_linux.c @@ -25,3 +25,129 @@ int libxl__try_phy_backend(mode_t st_mode) return 1; } + +/* Hotplug scripts helpers */ + +static void cleanup(libxl__gc *gc, libxl__ao_device *aorm) +{ + if (!aorm) return; + libxl__ev_time_deregister(gc, &aorm->ev); +} + +static void callback(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) +{ + libxl__ao_device *aorm = CONTAINER_OF(child, *aorm, child); + STATE_AO_GC(aorm->ao); + + cleanup(gc, aorm); + + if (status) { + libxl_report_child_exitstatus(CTX, aorm->rc ? LIBXL__LOG_ERROR + : LIBXL__LOG_WARNING, + aorm->what, pid, status); + aorm->rc = ERROR_FAIL; + } + aorm->callback(egc, aorm); +} + +static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev) +{ + char *be_path = libxl__device_backend_path(gc, dev); + char *script; + const char *type = libxl__device_kind_to_string(dev->backend_kind); + char **env; + int nr = 0; + + script = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "script")); + if (!script) { + LOGEV(ERROR, errno, "unable to read script from %s", be_path); + return NULL; + } + + GCNEW_ARRAY(env, 9); + env[nr++] = "script"; + env[nr++] = script; + env[nr++] = "XENBUS_TYPE"; + env[nr++] = libxl__strdup(gc, type); + env[nr++] = "XENBUS_PATH"; + env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid); + env[nr++] = "XENBUS_BASE_PATH"; + env[nr++] = "backend"; + env[nr++] = NULL; + + return env; +} + +/* Hotplug scripts caller functions */ + +static int libxl__hotplug_disk(libxl__gc *gc, libxl__ao_device *aorm) +{ + char *be_path = libxl__device_backend_path(gc, aorm->dev); + char *script; + char **args, **env; + int nr = 0, rc = 0; + + script = libxl__xs_read(gc, XBT_NULL, + GCSPRINTF("%s/%s", be_path, "script")); + if (!script) { + LOGEV(ERROR, errno, "unable to read script from %s", be_path); + return ERROR_FAIL; + } + + env = get_hotplug_env(gc, aorm->dev); + if (!env) + return ERROR_FAIL; + + GCNEW_ARRAY(args, 3); + + args[nr++] = script; + args[nr++] = aorm->action == DEVICE_CONNECT ? "add" : "remove"; + args[nr++] = NULL; + + aorm->what = GCSPRINTF("%s %s", args[0], args[1]); + LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]); + rc = libxl__hotplug_launch(gc, aorm, args[0], args, env, callback); + if (rc) { + goto out_free; + } + + rc = 0; + +out_free: + return rc; +} + +void libxl__device_hotplug(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + char *disable_udev = libxl__xs_read(gc, XBT_NULL, DISABLE_UDEV_PATH); + + /* Check if we have to run hotplug scripts */ + if (!disable_udev) goto out; + + switch (aorm->dev->backend_kind) { + case LIBXL__DEVICE_KIND_VBD: + aorm->rc = libxl__hotplug_disk(gc, aorm); + if (aorm->rc) goto error; + break; + default: + /* If no need to execute any hotplug scripts, + * call the callback manually + */ + aorm->rc = 0; + aorm->callback(egc, aorm); + break; + } + + return; + +error: + assert(aorm->rc); + LOGE(ERROR, "unable to queue execution of hotplug script for device " + "with path %s", libxl__device_backend_path(gc, aorm->dev)); +out: + aorm->callback(egc, aorm); + return; +} diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 551e367..b1351de 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -220,6 +220,7 @@ libxl_domain_create_info = Struct("domain_create_info",[ ("xsdata", libxl_key_value_list), ("platformdata", libxl_key_value_list), ("poolid", uint32), + ("run_hotplug_scripts",libxl_defbool), ], dir=DIR_IN) MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT") diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index d4db1f8..d992c32 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -35,6 +35,7 @@ xentoollog_logger_stdiostream *logger; int dryrun_only; int autoballoon = 1; +libxl_defbool run_hotplug_scripts; char *lockfile; char *default_vifscript = NULL; char *default_bridge = NULL; @@ -66,6 +67,9 @@ static void parse_global_config(const char *configfile, if (!xlu_cfg_get_long (config, "autoballoon", &l, 0)) autoballoon = l; + libxl_defbool_setdefault(&run_hotplug_scripts, true); + xlu_cfg_get_defbool(config, "run_hotplug_scripts", &run_hotplug_scripts, 0); + if (!xlu_cfg_get_string (config, "lockfile", &buf, 0)) lockfile = strdup(buf); else { diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index 2b6714a..43d727a 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -109,6 +109,7 @@ void postfork(void); /* global options */ extern int autoballoon; +extern libxl_defbool run_hotplug_scripts; extern int dryrun_only; extern char *lockfile; extern char *default_vifscript; diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 8908581..3f1bbf6 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -562,6 +562,7 @@ static void parse_config_data(const char *configfile_filename_report, } } + c_info->run_hotplug_scripts = run_hotplug_scripts; c_info->type = LIBXL_DOMAIN_TYPE_PV; if (!xlu_cfg_get_string (config, "builder", &buf, 0) && !strncmp(buf, "hvm", strlen(buf))) @@ -1333,7 +1334,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, /* fall-through */ case LIBXL_ACTION_ON_SHUTDOWN_DESTROY: LOG("Domain %d needs to be cleaned up: destroying the domain", domid); - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); break; case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY: @@ -1899,7 +1900,7 @@ start: error_out: release_lock(); if (libxl_domid_valid_guest(domid)) - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); out: if (logfile != 2) @@ -2386,7 +2387,7 @@ static void destroy_domain(const char *p) fprintf(stderr, "Cannot destroy privileged domain 0.\n\n"); exit(-1); } - rc = libxl_domain_destroy(ctx, domid); + rc = libxl_domain_destroy(ctx, domid, 0); if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); } } @@ -2660,7 +2661,7 @@ static int save_domain(const char *p, const char *filename, int checkpoint, if (checkpoint) libxl_domain_unpause(ctx, domid); else - libxl_domain_destroy(ctx, domid); + libxl_domain_destroy(ctx, domid, 0); exit(0); } @@ -2892,7 +2893,7 @@ static void migrate_domain(const char *domain_spec, const char *rune, } fprintf(stderr, "migration sender: Target reports successful startup.\n"); - libxl_domain_destroy(ctx, domid); /* bang! */ + libxl_domain_destroy(ctx, domid, 0); /* bang! */ fprintf(stderr, "Migration successful.\n"); exit(0); @@ -3010,7 +3011,7 @@ static void migrate_receive(int debug, int daemonize, int monitor) if (rc) { fprintf(stderr, "migration target: Failure, destroying our copy.\n"); - rc2 = libxl_domain_destroy(ctx, domid); + rc2 = libxl_domain_destroy(ctx, domid, 0); if (rc2) { fprintf(stderr, "migration target: Failed to destroy our copy" " (code %d).\n", rc2); @@ -5077,7 +5078,7 @@ int main_blockattach(int argc, char **argv) return 0; } - if (libxl_device_disk_add(ctx, fe_domid, &disk)) { + if (libxl_device_disk_add(ctx, fe_domid, &disk, 0)) { fprintf(stderr, "libxl_device_disk_add failed.\n"); } return 0; diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c index c4f7c52..ce7a2b2 100644 --- a/tools/python/xen/lowlevel/xl/xl.c +++ b/tools/python/xen/lowlevel/xl/xl.c @@ -447,7 +447,7 @@ static PyObject *pyxl_domain_destroy(XlObject *self, PyObject *args) int domid; if ( !PyArg_ParseTuple(args, "i", &domid) ) return NULL; - if ( libxl_domain_destroy(self->ctx, domid) ) { + if ( libxl_domain_destroy(self->ctx, domid, NULL) ) { PyErr_SetString(xl_error_obj, "cannot destroy domain"); return NULL; } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:32:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:32:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRb7-0000Ha-6N; Thu, 10 May 2012 11:31:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRb5-0000H3-Ci for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:31:51 +0000 Received: from [85.158.139.83:57218] by server-11.bemta-5.messagelabs.com id 05/07-12959-627ABAF4; Thu, 10 May 2012 11:31:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336649509!24935946!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22920 invoked from network); 10 May 2012 11:31:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:31:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403486" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:31:49 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:31:49 +0100 Message-ID: <1336649508.7098.97.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 12:31:48 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > pci-assignable-add will always store the driver rebind path, but > pci-assignable-remove will only actually rebind if asked to do so. > > Signed-off-by: George Dunlap > > diff -r 17a5b562d1e7 -r a1c357853735 docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Wed May 09 11:21:28 2012 +0100 > +++ b/docs/man/xl.pod.1 Wed May 09 11:24:01 2012 +0100 > @@ -1026,6 +1026,26 @@ These are devices in the system which ar > available for passthrough and are bound to a suitable PCI > backend driver in domain 0 rather than a real driver. > > +=item B I > + > +Make the device at PCI Bus/Device/Function BDF assignable to guests. This > +will bind the device to the pciback driver. If it is already bound to a > +driver, it will first be unbound, and the original driver stored so that it > +can be re-bound to the same driver later if desired. > + > +CAUTION: This will make the device unusable by Domain 0 until it is > +returned with pci-assignable-remove. Care should therefore be taken > +not to do this on a device critical to domain 0's operation, such as > +storage controllers, network interfaces, or GPUs that are currently > +being used. > + > +=item B [I<-r>] I > + > +Make the device at PCI Bus/Device/Function BDF assignable to guests. This > +will at least unbind the device from pciback. If the -r option is specified, > +it will also attempt to re-bind the device to its original driver, making it > +usable by Domain 0 again. > + > =item B I I > > Hot-plug a new pass-through pci device to the specified domain. > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl.h > --- a/tools/libxl/xl.h Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl.h Wed May 09 11:24:01 2012 +0100 > @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv > int main_pcilist(int argc, char **argv); > int main_pcidetach(int argc, char **argv); > int main_pciattach(int argc, char **argv); > +int main_pciassignable_add(int argc, char **argv); > +int main_pciassignable_remove(int argc, char **argv); > int main_pciassignable_list(int argc, char **argv); > int main_restore(int argc, char **argv); > int main_migrate_receive(int argc, char **argv); > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:24:01 2012 +0100 > @@ -2368,6 +2368,82 @@ int main_pciassignable_list(int argc, ch > return 0; > } > > +static void pciassignable_add(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + memset(&pcidev, 0x00, sizeof(pcidev)); libxl_device_pci_init please. > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } > + > + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { > + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); > + exit(2); > + } > + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); > + libxl_device_pci_dispose(&pcidev); > +} > + > +int main_pciassignable_add(int argc, char **argv) > +{ > + int opt; > + const char *bdf = NULL; > + > + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { > + switch (opt) { > + case 0: case 2: > + return opt; > + } > + } > + > + bdf = argv[optind]; > + > + pciassignable_add(bdf, 1); > + return 0; > +} > + > +static void pciassignable_remove(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + memset(&pcidev, 0x00, sizeof(pcidev)); libxl_device_pci_init also. You are also missing the xlu_cfg_destroy both here and in the add fn. (it's a bit annoying that an XLU_COnfig is needed for these simple helper functions, I suppose it's for logging, but maybe they could log to stderr if cfg==NULL. Anyway, lets not fix that here) > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } > + > + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { > + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); > + exit(2); > + } > + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); > + libxl_device_pci_dispose(&pcidev); > +} > + > +int main_pciassignable_remove(int argc, char **argv) > +{ > + int opt; > + const char *bdf = NULL; > + int rebind = 0; > + > + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { > + switch (opt) { > + case 0: case 2: > + return opt; > + case 'r': > + rebind=1; > + break; > + } > + } > + > + bdf = argv[optind]; > + > + pciassignable_remove(bdf, rebind); > + return 0; > +} > + > static void pause_domain(const char *p) > { > find_domain(p); > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdtable.c > --- a/tools/libxl/xl_cmdtable.c Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:24:01 2012 +0100 > @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { > "List pass-through pci devices for a domain", > "", > }, > + { "pci-assignable-add", > + &main_pciassignable_add, 0, > + "Make a device assignable for pci-passthru", > + "", > + "-h Print this help.\n" > + }, > + { "pci-assignable-remove", > + &main_pciassignable_remove, 0, > + "Remove a device from being assignable", > + "[options] ", > + "-h Print this help.\n" > + "-r Attempt to re-assign the device to the\n" > + " original driver" > + }, > { "pci-assignable-list", > &main_pciassignable_list, 0, > "List all the assignable pci devices", > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:32:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:32:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRb7-0000Ha-6N; Thu, 10 May 2012 11:31:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRb5-0000H3-Ci for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:31:51 +0000 Received: from [85.158.139.83:57218] by server-11.bemta-5.messagelabs.com id 05/07-12959-627ABAF4; Thu, 10 May 2012 11:31:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336649509!24935946!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22920 invoked from network); 10 May 2012 11:31:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:31:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403486" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:31:49 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:31:49 +0100 Message-ID: <1336649508.7098.97.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 12:31:48 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > pci-assignable-add will always store the driver rebind path, but > pci-assignable-remove will only actually rebind if asked to do so. > > Signed-off-by: George Dunlap > > diff -r 17a5b562d1e7 -r a1c357853735 docs/man/xl.pod.1 > --- a/docs/man/xl.pod.1 Wed May 09 11:21:28 2012 +0100 > +++ b/docs/man/xl.pod.1 Wed May 09 11:24:01 2012 +0100 > @@ -1026,6 +1026,26 @@ These are devices in the system which ar > available for passthrough and are bound to a suitable PCI > backend driver in domain 0 rather than a real driver. > > +=item B I > + > +Make the device at PCI Bus/Device/Function BDF assignable to guests. This > +will bind the device to the pciback driver. If it is already bound to a > +driver, it will first be unbound, and the original driver stored so that it > +can be re-bound to the same driver later if desired. > + > +CAUTION: This will make the device unusable by Domain 0 until it is > +returned with pci-assignable-remove. Care should therefore be taken > +not to do this on a device critical to domain 0's operation, such as > +storage controllers, network interfaces, or GPUs that are currently > +being used. > + > +=item B [I<-r>] I > + > +Make the device at PCI Bus/Device/Function BDF assignable to guests. This > +will at least unbind the device from pciback. If the -r option is specified, > +it will also attempt to re-bind the device to its original driver, making it > +usable by Domain 0 again. > + > =item B I I > > Hot-plug a new pass-through pci device to the specified domain. > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl.h > --- a/tools/libxl/xl.h Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl.h Wed May 09 11:24:01 2012 +0100 > @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv > int main_pcilist(int argc, char **argv); > int main_pcidetach(int argc, char **argv); > int main_pciattach(int argc, char **argv); > +int main_pciassignable_add(int argc, char **argv); > +int main_pciassignable_remove(int argc, char **argv); > int main_pciassignable_list(int argc, char **argv); > int main_restore(int argc, char **argv); > int main_migrate_receive(int argc, char **argv); > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Wed May 09 11:24:01 2012 +0100 > @@ -2368,6 +2368,82 @@ int main_pciassignable_list(int argc, ch > return 0; > } > > +static void pciassignable_add(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + memset(&pcidev, 0x00, sizeof(pcidev)); libxl_device_pci_init please. > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } > + > + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { > + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); > + exit(2); > + } > + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); > + libxl_device_pci_dispose(&pcidev); > +} > + > +int main_pciassignable_add(int argc, char **argv) > +{ > + int opt; > + const char *bdf = NULL; > + > + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { > + switch (opt) { > + case 0: case 2: > + return opt; > + } > + } > + > + bdf = argv[optind]; > + > + pciassignable_add(bdf, 1); > + return 0; > +} > + > +static void pciassignable_remove(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + memset(&pcidev, 0x00, sizeof(pcidev)); libxl_device_pci_init also. You are also missing the xlu_cfg_destroy both here and in the add fn. (it's a bit annoying that an XLU_COnfig is needed for these simple helper functions, I suppose it's for logging, but maybe they could log to stderr if cfg==NULL. Anyway, lets not fix that here) > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } > + > + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { > + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); > + exit(2); > + } > + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); > + libxl_device_pci_dispose(&pcidev); > +} > + > +int main_pciassignable_remove(int argc, char **argv) > +{ > + int opt; > + const char *bdf = NULL; > + int rebind = 0; > + > + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { > + switch (opt) { > + case 0: case 2: > + return opt; > + case 'r': > + rebind=1; > + break; > + } > + } > + > + bdf = argv[optind]; > + > + pciassignable_remove(bdf, rebind); > + return 0; > +} > + > static void pause_domain(const char *p) > { > find_domain(p); > diff -r 17a5b562d1e7 -r a1c357853735 tools/libxl/xl_cmdtable.c > --- a/tools/libxl/xl_cmdtable.c Wed May 09 11:21:28 2012 +0100 > +++ b/tools/libxl/xl_cmdtable.c Wed May 09 11:24:01 2012 +0100 > @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { > "List pass-through pci devices for a domain", > "", > }, > + { "pci-assignable-add", > + &main_pciassignable_add, 0, > + "Make a device assignable for pci-passthru", > + "", > + "-h Print this help.\n" > + }, > + { "pci-assignable-remove", > + &main_pciassignable_remove, 0, > + "Remove a device from being assignable", > + "[options] ", > + "-h Print this help.\n" > + "-r Attempt to re-assign the device to the\n" > + " original driver" > + }, > { "pci-assignable-list", > &main_pciassignable_list, 0, > "List all the assignable pci devices", > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:36:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRfk-0000dY-UZ; Thu, 10 May 2012 11:36:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRfj-0000dR-T2 for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:36:40 +0000 Received: from [85.158.143.35:35284] by server-3.bemta-4.messagelabs.com id 85/0B-05853-748ABAF4; Thu, 10 May 2012 11:36:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336649797!10374559!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15900 invoked from network); 10 May 2012 11:36:37 -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; 10 May 2012 11:36:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:36: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, 10 May 2012 12:36:35 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRff-0006lJ-Is; Thu, 10 May 2012 11:36:35 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRff-0004qA-Ho; Thu, 10 May 2012 12:36:35 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.43075.534483.485017@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:36:35 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: <4FAA83A8.8070804@eu.citrix.com> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > On 09/05/12 14:43, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > > Why strncmp and not just strcmp? And why 20? AFAIK > > strlen("/usr/bin/pygrub") == 15 or 16 or so... > > ISTR in the past build processes throwing warnings that strcmp() is > unsafe, and since warnings turn to errors, pre-emptively used the "safe" > version instead. Boggle. Any such build processes need to be taken out and shot. There is nothing wrong with strcmp. Are you sure you're not thinking of strcat or sprintf ? > Let me give it a try; it should be perfectly safe for > us, and will remove the issue with manually syncronizing string with its > size. Right, yes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:36:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRfk-0000dY-UZ; Thu, 10 May 2012 11:36:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRfj-0000dR-T2 for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:36:40 +0000 Received: from [85.158.143.35:35284] by server-3.bemta-4.messagelabs.com id 85/0B-05853-748ABAF4; Thu, 10 May 2012 11:36:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336649797!10374559!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15900 invoked from network); 10 May 2012 11:36:37 -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; 10 May 2012 11:36:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="12403587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:36: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, 10 May 2012 12:36:35 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSRff-0006lJ-Is; Thu, 10 May 2012 11:36:35 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSRff-0004qA-Ho; Thu, 10 May 2012 12:36:35 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.43075.534483.485017@mariner.uk.xensource.com> Date: Thu, 10 May 2012 12:36:35 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: <4FAA83A8.8070804@eu.citrix.com> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > On 09/05/12 14:43, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > > Why strncmp and not just strcmp? And why 20? AFAIK > > strlen("/usr/bin/pygrub") == 15 or 16 or so... > > ISTR in the past build processes throwing warnings that strcmp() is > unsafe, and since warnings turn to errors, pre-emptively used the "safe" > version instead. Boggle. Any such build processes need to be taken out and shot. There is nothing wrong with strcmp. Are you sure you're not thinking of strcat or sprintf ? > Let me give it a try; it should be perfectly safe for > us, and will remove the issue with manually syncronizing string with its > size. Right, yes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:38:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRhV-0000ie-E6; Thu, 10 May 2012 11:38:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRhU-0000iY-KK for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:38:28 +0000 Received: from [85.158.143.35:43213] by server-3.bemta-4.messagelabs.com id AE/5E-05853-3B8ABAF4; Thu, 10 May 2012 11:38:27 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336649903!14765785!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28375 invoked from network); 10 May 2012 11:38:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:38:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058969" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:38:23 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:38:22 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRhO-000483-Dp; Thu, 10 May 2012 12:38:22 +0100 Message-ID: <4FABA867.2050000@eu.citrix.com> Date: Thu, 10 May 2012 12:37:11 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Jackson References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> In-Reply-To: <20395.43075.534483.485017@mariner.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:36, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): >> On 09/05/12 14:43, Ian Campbell wrote: >>> On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >>>> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) >>> Why strncmp and not just strcmp? And why 20? AFAIK >>> strlen("/usr/bin/pygrub") == 15 or 16 or so... >> ISTR in the past build processes throwing warnings that strcmp() is >> unsafe, and since warnings turn to errors, pre-emptively used the "safe" >> version instead. > Boggle. Any such build processes need to be taken out and shot. > There is nothing wrong with strcmp. Are you sure you're not thinking > of strcat or sprintf ? Perhaps, or strcpy. At any rate, it compiles just fine with strcmp(), so I'll include that in the next post. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:38:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRhV-0000ie-E6; Thu, 10 May 2012 11:38:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRhU-0000iY-KK for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:38:28 +0000 Received: from [85.158.143.35:43213] by server-3.bemta-4.messagelabs.com id AE/5E-05853-3B8ABAF4; Thu, 10 May 2012 11:38:27 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336649903!14765785!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28375 invoked from network); 10 May 2012 11:38:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:38:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="25058969" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:38:23 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:38:22 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRhO-000483-Dp; Thu, 10 May 2012 12:38:22 +0100 Message-ID: <4FABA867.2050000@eu.citrix.com> Date: Thu, 10 May 2012 12:37:11 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Jackson References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> In-Reply-To: <20395.43075.534483.485017@mariner.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:36, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): >> On 09/05/12 14:43, Ian Campbell wrote: >>> On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >>>> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) >>> Why strncmp and not just strcmp? And why 20? AFAIK >>> strlen("/usr/bin/pygrub") == 15 or 16 or so... >> ISTR in the past build processes throwing warnings that strcmp() is >> unsafe, and since warnings turn to errors, pre-emptively used the "safe" >> version instead. > Boggle. Any such build processes need to be taken out and shot. > There is nothing wrong with strcmp. Are you sure you're not thinking > of strcat or sprintf ? Perhaps, or strcpy. At any rate, it compiles just fine with strcmp(), so I'll include that in the next post. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRnA-0000vC-71; Thu, 10 May 2012 11:44:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRn8-0000v7-IS for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:44:18 +0000 Received: from [85.158.143.99:20982] by server-1.bemta-4.messagelabs.com id 64/C4-20925-11AABAF4; Thu, 10 May 2012 11:44:17 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-216.messagelabs.com!1336650256!27375238!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12452 invoked from network); 10 May 2012 11:44:17 -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; 10 May 2012 11:44:17 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSRn4-000LIT-5u; Thu, 10 May 2012 11:44:14 +0000 Date: Thu, 10 May 2012 12:44:14 +0100 From: Tim Deegan To: Ian Jackson Message-ID: <20120510114414.GC73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20395.43075.534483.485017@mariner.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > > On 09/05/12 14:43, Ian Campbell wrote: > > > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > > >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > > > Why strncmp and not just strcmp? And why 20? AFAIK > > > strlen("/usr/bin/pygrub") == 15 or 16 or so... > > > > ISTR in the past build processes throwing warnings that strcmp() is > > unsafe, and since warnings turn to errors, pre-emptively used the "safe" > > version instead. > > Boggle. Any such build processes need to be taken out and shot. > There is nothing wrong with strcmp. Are you sure you're not thinking > of strcat or sprintf ? If the user controlled both the length and contents of info->u.pv.bootloader, it could cause this to overrun that buffer and cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list for many people. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:44:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11: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 ) id 1SSRnA-0000vC-71; Thu, 10 May 2012 11:44:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRn8-0000v7-IS for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:44:18 +0000 Received: from [85.158.143.99:20982] by server-1.bemta-4.messagelabs.com id 64/C4-20925-11AABAF4; Thu, 10 May 2012 11:44:17 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-216.messagelabs.com!1336650256!27375238!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12452 invoked from network); 10 May 2012 11:44:17 -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; 10 May 2012 11:44:17 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSRn4-000LIT-5u; Thu, 10 May 2012 11:44:14 +0000 Date: Thu, 10 May 2012 12:44:14 +0100 From: Tim Deegan To: Ian Jackson Message-ID: <20120510114414.GC73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20395.43075.534483.485017@mariner.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > > On 09/05/12 14:43, Ian Campbell wrote: > > > On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: > > >> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) > > > Why strncmp and not just strcmp? And why 20? AFAIK > > > strlen("/usr/bin/pygrub") == 15 or 16 or so... > > > > ISTR in the past build processes throwing warnings that strcmp() is > > unsafe, and since warnings turn to errors, pre-emptively used the "safe" > > version instead. > > Boggle. Any such build processes need to be taken out and shot. > There is nothing wrong with strcmp. Are you sure you're not thinking > of strcat or sprintf ? If the user controlled both the length and contents of info->u.pv.bootloader, it could cause this to overrun that buffer and cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list for many people. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:48:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRrR-00012o-TK; Thu, 10 May 2012 11:48:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRrQ-00012g-8n for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:48:44 +0000 Received: from [85.158.143.35:39793] by server-1.bemta-4.messagelabs.com id 87/FA-20925-B1BABAF4; Thu, 10 May 2012 11:48:43 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336650517!11612786!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4928 invoked from network); 10 May 2012 11:48:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:48:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194236760" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:48:36 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:48:36 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRrH-0004IV-MI; Thu, 10 May 2012 12:48:35 +0100 Message-ID: <4FABAACC.9000301@eu.citrix.com> Date: Thu, 10 May 2012 12:47:24 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tim Deegan References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> In-Reply-To: <20120510114414.GC73773@ocelot.phlegethon.org> Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:44, Tim Deegan wrote: > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: >> George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): >>> On 09/05/12 14:43, Ian Campbell wrote: >>>> On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >>>>> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) >>>> Why strncmp and not just strcmp? And why 20? AFAIK >>>> strlen("/usr/bin/pygrub") == 15 or 16 or so... >>> ISTR in the past build processes throwing warnings that strcmp() is >>> unsafe, and since warnings turn to errors, pre-emptively used the "safe" >>> version instead. >> Boggle. Any such build processes need to be taken out and shot. >> There is nothing wrong with strcmp. Are you sure you're not thinking >> of strcat or sprintf ? > If the user controlled both the length and contents of > info->u.pv.bootloader, it could cause this to overrun that buffer and > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > for many people. Hmm, yes, I suppose it's *technically* possible that even when comparing to a static string, if info->u.pv.bootloader contains a short, non-null-terminated string, and were close to the edge of a page, it could cause a SEGV. But using strncmp wouldn't solve that, would it? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:48:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRrR-00012o-TK; Thu, 10 May 2012 11:48:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRrQ-00012g-8n for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:48:44 +0000 Received: from [85.158.143.35:39793] by server-1.bemta-4.messagelabs.com id 87/FA-20925-B1BABAF4; Thu, 10 May 2012 11:48:43 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336650517!11612786!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4928 invoked from network); 10 May 2012 11:48:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 11:48:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="194236760" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 07:48:36 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 07:48:36 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSRrH-0004IV-MI; Thu, 10 May 2012 12:48:35 +0100 Message-ID: <4FABAACC.9000301@eu.citrix.com> Date: Thu, 10 May 2012 12:47:24 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tim Deegan References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> In-Reply-To: <20120510114414.GC73773@ocelot.phlegethon.org> Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:44, Tim Deegan wrote: > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: >> George Dunlap writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): >>> On 09/05/12 14:43, Ian Campbell wrote: >>>> On Wed, 2012-05-09 at 11:51 +0100, George Dunlap wrote: >>>>> + if ( !strncmp(info->u.pv.bootloader, "/usr/bin/pygrub", 20) ) >>>> Why strncmp and not just strcmp? And why 20? AFAIK >>>> strlen("/usr/bin/pygrub") == 15 or 16 or so... >>> ISTR in the past build processes throwing warnings that strcmp() is >>> unsafe, and since warnings turn to errors, pre-emptively used the "safe" >>> version instead. >> Boggle. Any such build processes need to be taken out and shot. >> There is nothing wrong with strcmp. Are you sure you're not thinking >> of strcat or sprintf ? > If the user controlled both the length and contents of > info->u.pv.bootloader, it could cause this to overrun that buffer and > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > for many people. Hmm, yes, I suppose it's *technically* possible that even when comparing to a static string, if info->u.pv.bootloader contains a short, non-null-terminated string, and were close to the edge of a page, it could cause a SEGV. But using strncmp wouldn't solve that, would it? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:58:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:58:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS0q-0001Ef-0X; Thu, 10 May 2012 11:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS0o-0001Ea-9j for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:58:26 +0000 Received: from [85.158.143.99:40763] by server-2.bemta-4.messagelabs.com id E6/5A-17550-16DABAF4; Thu, 10 May 2012 11:58:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336651103!22036758!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21079 invoked from network); 10 May 2012 11:58:23 -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 May 2012 11:58:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12404070" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:58:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:58:22 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSS0k-0006th-AU; Thu, 10 May 2012 11:58:22 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSS0k-00078S-9Z; Thu, 10 May 2012 12:58:22 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 10 May 2012 12:58:22 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12828 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 4 xen-build fail REGR. vs. 12827 build-i386-oldkern 4 xen-build fail REGR. vs. 12827 build-amd64-oldkern 4 xen-build fail REGR. vs. 12827 build-amd64 4 xen-build fail REGR. vs. 12827 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-pv 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-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 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 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 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-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 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-pair 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 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-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 27d63b9f111a baseline version: xen 8a86d841e6d4 jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 11:58:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 11:58:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS0q-0001Ef-0X; Thu, 10 May 2012 11:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS0o-0001Ea-9j for xen-devel@lists.xensource.com; Thu, 10 May 2012 11:58:26 +0000 Received: from [85.158.143.99:40763] by server-2.bemta-4.messagelabs.com id E6/5A-17550-16DABAF4; Thu, 10 May 2012 11:58:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336651103!22036758!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21079 invoked from network); 10 May 2012 11:58:23 -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 May 2012 11:58:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12404070" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:58:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:58:22 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSS0k-0006th-AU; Thu, 10 May 2012 11:58:22 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSS0k-00078S-9Z; Thu, 10 May 2012 12:58:22 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 10 May 2012 12:58:22 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12828 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 4 xen-build fail REGR. vs. 12827 build-i386-oldkern 4 xen-build fail REGR. vs. 12827 build-amd64-oldkern 4 xen-build fail REGR. vs. 12827 build-amd64 4 xen-build fail REGR. vs. 12827 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-pv 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-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 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 1 xen-build-check(1) blocked n/a test-amd64-amd64-win 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-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 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-pair 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 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-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a test-i386-i386-win 1 xen-build-check(1) blocked n/a version targeted for testing: xen 27d63b9f111a baseline version: xen 8a86d841e6d4 jobs: build-amd64 fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win blocked test-amd64-i386-win blocked test-i386-i386-win blocked test-amd64-amd64-xl-win blocked test-i386-i386-xl-win blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:03:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSS5Q-0001WR-Dk; Thu, 10 May 2012 12:03:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS5N-0001WG-Sg for xen-devel@lists.xen.org; Thu, 10 May 2012 12:03:10 +0000 Received: from [85.158.138.51:20450] by server-10.bemta-3.messagelabs.com id C2/F4-29478-C7EABAF4; Thu, 10 May 2012 12:03:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336651387!7626491!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10150 invoked from network); 10 May 2012 12:03:08 -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 May 2012 12:03:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12404177" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:03:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 13:03:07 +0100 Message-ID: <1336651386.7098.113.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jean Guyader Date: Thu, 10 May 2012 13:03:06 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Eric Chanudet , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 10:58 +0100, Jean Guyader wrote: > @@ -158,7 +160,7 @@ static void buffer_append(struct domain *dom) > if ((size == 0) || (size > sizeof(intf->out))) > return; > > - if ((buffer->capacity - buffer->size) < size) { > + if ((buffer->capacity - buffer->size) < size + 1) { What's this? > buffer->capacity += (size + 1024); > buffer->data = realloc(buffer->data, > buffer->capacity); > if (buffer->data == NULL) { > @@ -166,10 +168,31 @@ static void buffer_append(struct domain *dom) > exit(ENOMEM); > } > } > + slbuf.capacity = buffer->capacity; > + slbuf.max_capacity = buffer->max_capacity; > + slbuf.data = malloc(slbuf.capacity); > + if (!slbuf.data) { > + dolog(LOG_ERR, "Memory allocation failed"); > + exit(ENOMEM); > + } > > - while (cons != prod) > - buffer->data[buffer->size++] = intf->out[ > - MASK_XENCONS_IDX(cons++, intf->out)]; > + for (; cons != prod; ++cons) { > + char ch = intf->out[MASK_XENCONS_IDX(cons, > intf->out)]; > + slbuf.data[slbuf.size++] = ch; > + buffer->data[buffer->size++] = ch; > + if (ch == '\r' || ch == '\n') { > + slbuf.data[slbuf.size - 1] = '\0'; > + ++cons; > + if (cons != prod) { > + ch = intf->out[MASK_XENCONS_IDX(cons > ++, intf->out)]; > + buffer->data[buffer->size++] = ch; > + if (ch != '\r' && ch != '\n') { > + slbuf.data[slbuf.size++] = ch; > + } > + } This is chomping \r\n or \n\r into a \0 for the syslog buffer only? It's a bit fiddly, worth a comment I would say.. > + break; > + } > + } > > xen_mb(); > intf->out_cons = cons; > @@ -196,6 +219,9 @@ static void buffer_append(struct domain *dom) > dolog(LOG_ERR, "Write to log failed " > "on domain %d: %d (%s)\n", > dom->domid, errno, strerror(errno)); > + } else { > + /* Falls back to syslog is the domain doesn't have a > log file */ Isn't that the same as logging to syslog by default? Shouldn't there be a check for if (use_syslog) in here somewhere? > + syslog(LOG_INFO, "%s (%i): %s", dom->name, dom->domid, > slbuf.data); > } > > if (discard_overflowed_data && buffer->max_capacity && > @@ -219,6 +245,7 @@ static void buffer_append(struct domain *dom) > buffer->size = buffer->max_capacity / 2 + > over; > } > } > + free(slbuf.data); > } > > static bool buffer_empty(struct buffer *buffer) > @@ -255,6 +282,10 @@ static int create_hv_log(void) > { > char logfile[PATH_MAX]; > int fd; > + > + if (!log_dir) > + return -1; > + > snprintf(logfile, PATH_MAX-1, "%s/hypervisor.log", log_dir); > logfile[PATH_MAX-1] = '\0'; > > @@ -275,32 +306,56 @@ static int create_hv_log(void) > return fd; > } > > +static char *safe_xs_read(const char *key, int tries) > +{ > + char *data = NULL; > + unsigned int len; > + struct timespec req = { .tv_sec = 0, .tv_nsec = > 100000000 }; /* 100 ms */ > + int i; > + > + for (i = 0; i < tries; i++) { > + data = xs_read(xs, XBT_NULL, key, &len); > + if (data && len > 0) > + break; > + free(data); > + nanosleep(&req, NULL); > + } > + return data; > +} > + > +static char *name_from_dompath(const char *path) > +{ > + char namepath[64] = { 0 }, *name; I suppose 64 is enough, but you could use strlen + N here... > + strncat( namepath, path , sizeof(namepath) ); > + strncat( namepath, "/name", sizeof(namepath) - > strlen(namepath) ); > + > + name = safe_xs_read(namepath, 1); > + /* without any name after 100 tries, just default to unnamed > */ Does this ever happen in practice? What sort of failure mode does it indicate? You do this for both the logfile and the sysfs name, so I guess this is strictly speaking an unrelated fix? > + if (!name) > + name = strdup("unnamed"); > + return name; > +} > + > static int create_domain_log(struct domain *dom) > { > char logfile[PATH_MAX]; > - char *namepath, *data, *s; > + char *namepath; > int fd; > - unsigned int len; > > namepath = xs_get_domain_path(xs, dom->domid); > - s = realloc(namepath, strlen(namepath) + 6); > - if (s == NULL) { > + if (namepath == NULL) { > free(namepath); > return -1; > } > - namepath = s; > - strcat(namepath, "/name"); > - data = xs_read(xs, XBT_NULL, namepath, &len); > + dom->name = name_from_dompath(namepath); > free(namepath); > - if (!data) > + if (!dom->name) { > return -1; > - if (!len) { > - free(data); > + } > + if (!log_dir) { > return -1; > } > - > - snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, > data); > - free(data); > + snprintf(logfile, PATH_MAX - 1, "%s/%s.log", log_dir, > dom->name); Have you just changed the name of the logfile or does the "guest-" prefix come from somewhere else? I think the guest namespace is important to avoid clobbering the hypervisor.log (ok, so naming a guest "hypervisor" is dumb, but still). More plausibly someone could name a domain "smtp" which would be confusing when seen in syslog next to the dom0 MTA logging, perhaps. > logfile[PATH_MAX-1] = '\0'; > > fd = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644); > @@ -878,7 +939,10 @@ static void handle_xs(void) > > static void handle_hv_logs(void) > { > - char buffer[1024*16]; > + char buffer[1024*16 + 1]; > + static char lbuf[1024*16 + 1]; > + static int loff = 0; > + int i = 0; > char *bufptr = buffer; > unsigned int size = sizeof(buffer); > static uint32_t index = 0; > @@ -888,17 +952,36 @@ static void handle_hv_logs(void) > return; > > if (xc_readconsolering(xch, bufptr, &size, 0, 1, &index) == 0 > && size > 0) { > - int logret; > - if (log_time_hv) > - logret = write_with_timestamp(log_hv_fd, > buffer, size, > - > &log_time_hv_needts); > - else > - logret = write_all(log_hv_fd, buffer, size); > - > - if (logret < 0) > - dolog(LOG_ERR, "Failed to write hypervisor > log: " > - "%d (%s)", errno, > strerror(errno)); > - } > + if (log_hv_fd != -1) { > + int logret; > + if (log_time_hv) > + logret = > write_with_timestamp(log_hv_fd, buffer, size, > + > &log_time_hv_needts); > + else > + logret = write_all(log_hv_fd, buffer, > size); > + > + if (logret < 0) > + dolog(LOG_ERR, "Failed to write > hypervisor log: " > + "%d (%s)", errno, > strerror(errno)); > + } else { > + while (i < size) { > + while ((i < size) && > + (buffer[i] != '\n') && > (buffer[i] != '\r')) { > + lbuf[loff++] = buffer[i++]; > + } > + if ((buffer[i] == '\n') || (buffer[i] > == '\r')) { Is this now the second time we have done this \n\r conversion? FWIW this seems like the better location for it to me, since it made the code at the other location hard to follow whereas it looks more natural to skip char here. Also, can't you do this inplace in buffer[] and therefore avoid copying all the bytes plus the overhead of a second buffer? And could you also avoid the whole separate "struct buffer slbuf"? The need for that did make me pause earlier... > + lbuf[loff] = '\0'; > + ++i; > + if ((i < size) && > + ((buffer[i] == '\n') || > (buffer[i] == '\r'))) { > + ++i; > + } > + syslog(LOG_INFO, "hypervisor: > %s", lbuf); > + loff = 0; > + } > + } > + } > + } > > (void)xc_evtchn_unmask(xce_handle, port); > } > @@ -940,8 +1023,6 @@ void handle_io(void) > goto out; > } > log_hv_fd = create_hv_log(); > - if (log_hv_fd == -1) > - goto out; > log_hv_evtchn = xc_evtchn_bind_virq(xce_handle, > VIRQ_CON_RING); > if (log_hv_evtchn == -1) { > dolog(LOG_ERR, "Failed to bind to > VIRQ_CON_RING: " > diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:03:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSS5Q-0001WR-Dk; Thu, 10 May 2012 12:03:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSS5N-0001WG-Sg for xen-devel@lists.xen.org; Thu, 10 May 2012 12:03:10 +0000 Received: from [85.158.138.51:20450] by server-10.bemta-3.messagelabs.com id C2/F4-29478-C7EABAF4; Thu, 10 May 2012 12:03:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336651387!7626491!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10150 invoked from network); 10 May 2012 12:03:08 -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 May 2012 12:03:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12404177" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:03:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 13:03:07 +0100 Message-ID: <1336651386.7098.113.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jean Guyader Date: Thu, 10 May 2012 13:03:06 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Eric Chanudet , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 10:58 +0100, Jean Guyader wrote: > @@ -158,7 +160,7 @@ static void buffer_append(struct domain *dom) > if ((size == 0) || (size > sizeof(intf->out))) > return; > > - if ((buffer->capacity - buffer->size) < size) { > + if ((buffer->capacity - buffer->size) < size + 1) { What's this? > buffer->capacity += (size + 1024); > buffer->data = realloc(buffer->data, > buffer->capacity); > if (buffer->data == NULL) { > @@ -166,10 +168,31 @@ static void buffer_append(struct domain *dom) > exit(ENOMEM); > } > } > + slbuf.capacity = buffer->capacity; > + slbuf.max_capacity = buffer->max_capacity; > + slbuf.data = malloc(slbuf.capacity); > + if (!slbuf.data) { > + dolog(LOG_ERR, "Memory allocation failed"); > + exit(ENOMEM); > + } > > - while (cons != prod) > - buffer->data[buffer->size++] = intf->out[ > - MASK_XENCONS_IDX(cons++, intf->out)]; > + for (; cons != prod; ++cons) { > + char ch = intf->out[MASK_XENCONS_IDX(cons, > intf->out)]; > + slbuf.data[slbuf.size++] = ch; > + buffer->data[buffer->size++] = ch; > + if (ch == '\r' || ch == '\n') { > + slbuf.data[slbuf.size - 1] = '\0'; > + ++cons; > + if (cons != prod) { > + ch = intf->out[MASK_XENCONS_IDX(cons > ++, intf->out)]; > + buffer->data[buffer->size++] = ch; > + if (ch != '\r' && ch != '\n') { > + slbuf.data[slbuf.size++] = ch; > + } > + } This is chomping \r\n or \n\r into a \0 for the syslog buffer only? It's a bit fiddly, worth a comment I would say.. > + break; > + } > + } > > xen_mb(); > intf->out_cons = cons; > @@ -196,6 +219,9 @@ static void buffer_append(struct domain *dom) > dolog(LOG_ERR, "Write to log failed " > "on domain %d: %d (%s)\n", > dom->domid, errno, strerror(errno)); > + } else { > + /* Falls back to syslog is the domain doesn't have a > log file */ Isn't that the same as logging to syslog by default? Shouldn't there be a check for if (use_syslog) in here somewhere? > + syslog(LOG_INFO, "%s (%i): %s", dom->name, dom->domid, > slbuf.data); > } > > if (discard_overflowed_data && buffer->max_capacity && > @@ -219,6 +245,7 @@ static void buffer_append(struct domain *dom) > buffer->size = buffer->max_capacity / 2 + > over; > } > } > + free(slbuf.data); > } > > static bool buffer_empty(struct buffer *buffer) > @@ -255,6 +282,10 @@ static int create_hv_log(void) > { > char logfile[PATH_MAX]; > int fd; > + > + if (!log_dir) > + return -1; > + > snprintf(logfile, PATH_MAX-1, "%s/hypervisor.log", log_dir); > logfile[PATH_MAX-1] = '\0'; > > @@ -275,32 +306,56 @@ static int create_hv_log(void) > return fd; > } > > +static char *safe_xs_read(const char *key, int tries) > +{ > + char *data = NULL; > + unsigned int len; > + struct timespec req = { .tv_sec = 0, .tv_nsec = > 100000000 }; /* 100 ms */ > + int i; > + > + for (i = 0; i < tries; i++) { > + data = xs_read(xs, XBT_NULL, key, &len); > + if (data && len > 0) > + break; > + free(data); > + nanosleep(&req, NULL); > + } > + return data; > +} > + > +static char *name_from_dompath(const char *path) > +{ > + char namepath[64] = { 0 }, *name; I suppose 64 is enough, but you could use strlen + N here... > + strncat( namepath, path , sizeof(namepath) ); > + strncat( namepath, "/name", sizeof(namepath) - > strlen(namepath) ); > + > + name = safe_xs_read(namepath, 1); > + /* without any name after 100 tries, just default to unnamed > */ Does this ever happen in practice? What sort of failure mode does it indicate? You do this for both the logfile and the sysfs name, so I guess this is strictly speaking an unrelated fix? > + if (!name) > + name = strdup("unnamed"); > + return name; > +} > + > static int create_domain_log(struct domain *dom) > { > char logfile[PATH_MAX]; > - char *namepath, *data, *s; > + char *namepath; > int fd; > - unsigned int len; > > namepath = xs_get_domain_path(xs, dom->domid); > - s = realloc(namepath, strlen(namepath) + 6); > - if (s == NULL) { > + if (namepath == NULL) { > free(namepath); > return -1; > } > - namepath = s; > - strcat(namepath, "/name"); > - data = xs_read(xs, XBT_NULL, namepath, &len); > + dom->name = name_from_dompath(namepath); > free(namepath); > - if (!data) > + if (!dom->name) { > return -1; > - if (!len) { > - free(data); > + } > + if (!log_dir) { > return -1; > } > - > - snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, > data); > - free(data); > + snprintf(logfile, PATH_MAX - 1, "%s/%s.log", log_dir, > dom->name); Have you just changed the name of the logfile or does the "guest-" prefix come from somewhere else? I think the guest namespace is important to avoid clobbering the hypervisor.log (ok, so naming a guest "hypervisor" is dumb, but still). More plausibly someone could name a domain "smtp" which would be confusing when seen in syslog next to the dom0 MTA logging, perhaps. > logfile[PATH_MAX-1] = '\0'; > > fd = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644); > @@ -878,7 +939,10 @@ static void handle_xs(void) > > static void handle_hv_logs(void) > { > - char buffer[1024*16]; > + char buffer[1024*16 + 1]; > + static char lbuf[1024*16 + 1]; > + static int loff = 0; > + int i = 0; > char *bufptr = buffer; > unsigned int size = sizeof(buffer); > static uint32_t index = 0; > @@ -888,17 +952,36 @@ static void handle_hv_logs(void) > return; > > if (xc_readconsolering(xch, bufptr, &size, 0, 1, &index) == 0 > && size > 0) { > - int logret; > - if (log_time_hv) > - logret = write_with_timestamp(log_hv_fd, > buffer, size, > - > &log_time_hv_needts); > - else > - logret = write_all(log_hv_fd, buffer, size); > - > - if (logret < 0) > - dolog(LOG_ERR, "Failed to write hypervisor > log: " > - "%d (%s)", errno, > strerror(errno)); > - } > + if (log_hv_fd != -1) { > + int logret; > + if (log_time_hv) > + logret = > write_with_timestamp(log_hv_fd, buffer, size, > + > &log_time_hv_needts); > + else > + logret = write_all(log_hv_fd, buffer, > size); > + > + if (logret < 0) > + dolog(LOG_ERR, "Failed to write > hypervisor log: " > + "%d (%s)", errno, > strerror(errno)); > + } else { > + while (i < size) { > + while ((i < size) && > + (buffer[i] != '\n') && > (buffer[i] != '\r')) { > + lbuf[loff++] = buffer[i++]; > + } > + if ((buffer[i] == '\n') || (buffer[i] > == '\r')) { Is this now the second time we have done this \n\r conversion? FWIW this seems like the better location for it to me, since it made the code at the other location hard to follow whereas it looks more natural to skip char here. Also, can't you do this inplace in buffer[] and therefore avoid copying all the bytes plus the overhead of a second buffer? And could you also avoid the whole separate "struct buffer slbuf"? The need for that did make me pause earlier... > + lbuf[loff] = '\0'; > + ++i; > + if ((i < size) && > + ((buffer[i] == '\n') || > (buffer[i] == '\r'))) { > + ++i; > + } > + syslog(LOG_INFO, "hypervisor: > %s", lbuf); > + loff = 0; > + } > + } > + } > + } > > (void)xc_evtchn_unmask(xce_handle, port); > } > @@ -940,8 +1023,6 @@ void handle_io(void) > goto out; > } > log_hv_fd = create_hv_log(); > - if (log_hv_fd == -1) > - goto out; > log_hv_evtchn = xc_evtchn_bind_virq(xce_handle, > VIRQ_CON_RING); > if (log_hv_evtchn == -1) { > dolog(LOG_ERR, "Failed to bind to > VIRQ_CON_RING: " > diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:10:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSCD-0001ja-Bp; Thu, 10 May 2012 12:10:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSCC-0001jS-7b for xen-devel@lists.xensource.com; Thu, 10 May 2012 12:10:12 +0000 Received: from [85.158.143.99:6452] by server-2.bemta-4.messagelabs.com id E2/CD-17550-320BBAF4; Thu, 10 May 2012 12:10:11 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-216.messagelabs.com!1336651809!16158630!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8743 invoked from network); 10 May 2012 12:10:10 -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; 10 May 2012 12:10:10 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSSC7-000Lbz-GC; Thu, 10 May 2012 12:10:07 +0000 Date: Thu, 10 May 2012 13:10:07 +0100 From: Tim Deegan To: George Dunlap Message-ID: <20120510121007.GD73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> <4FABAACC.9000301@eu.citrix.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FABAACC.9000301@eu.citrix.com> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:47 +0100 on 10 May (1336654044), George Dunlap wrote: > On 10/05/12 12:44, Tim Deegan wrote: > >If the user controlled both the length and contents of > >info->u.pv.bootloader, it could cause this to overrun that buffer and > >cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > >for many people. > > Hmm, yes, I suppose it's *technically* possible that even when comparing > to a static string, if info->u.pv.bootloader contains a short, > non-null-terminated string, and were close to the edge of a page, it > could cause a SEGV. But using strncmp wouldn't solve that, would it? Yes - you give it the length of the info->u.pv.bootloader buffer and it guards against from exactly this problem. That's assuming you allocated it yourself and filled it with user-supplied bytes. If the user supplied the buffer, of course, you're forced to trust them and strncmp() doesn't buy you anything. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:10:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSCD-0001ja-Bp; Thu, 10 May 2012 12:10:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSCC-0001jS-7b for xen-devel@lists.xensource.com; Thu, 10 May 2012 12:10:12 +0000 Received: from [85.158.143.99:6452] by server-2.bemta-4.messagelabs.com id E2/CD-17550-320BBAF4; Thu, 10 May 2012 12:10:11 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-216.messagelabs.com!1336651809!16158630!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8743 invoked from network); 10 May 2012 12:10:10 -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; 10 May 2012 12:10:10 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSSC7-000Lbz-GC; Thu, 10 May 2012 12:10:07 +0000 Date: Thu, 10 May 2012 13:10:07 +0100 From: Tim Deegan To: George Dunlap Message-ID: <20120510121007.GD73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> <4FABAACC.9000301@eu.citrix.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FABAACC.9000301@eu.citrix.com> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:47 +0100 on 10 May (1336654044), George Dunlap wrote: > On 10/05/12 12:44, Tim Deegan wrote: > >If the user controlled both the length and contents of > >info->u.pv.bootloader, it could cause this to overrun that buffer and > >cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > >for many people. > > Hmm, yes, I suppose it's *technically* possible that even when comparing > to a static string, if info->u.pv.bootloader contains a short, > non-null-terminated string, and were close to the edge of a page, it > could cause a SEGV. But using strncmp wouldn't solve that, would it? Yes - you give it the length of the info->u.pv.bootloader buffer and it guards against from exactly this problem. That's assuming you allocated it yourself and filled it with user-supplied bytes. If the user supplied the buffer, of course, you're forced to trust them and strncmp() doesn't buy you anything. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSKw-0001sv-CD; Thu, 10 May 2012 12:19:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSKu-0001sk-HY for xen-devel@lists.xen.org; Thu, 10 May 2012 12:19:12 +0000 Received: from [193.109.254.147:48850] by server-12.bemta-14.messagelabs.com id BF/C5-05898-F32BBAF4; Thu, 10 May 2012 12:19:11 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336652349!1749703!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28723 invoked from network); 10 May 2012 12:19:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:19:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194240786" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:19:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:19:07 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSKp-0004n2-Eh; Thu, 10 May 2012 13:19:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:19:03 +0100 Message-ID: <1336652343-12279-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> References: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 2/2] libxl: fix indentation in libxl_dm.c for qemu X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fixed indentation on Qemu argument construction for network devices. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 0d7524c..c0d7ca1 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -213,8 +213,10 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, domid, vifs[i].devid, LIBXL_NIC_TYPE_IOEMU); flexarray_vappend(dm_args, - "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", - vifs[i].devid, smac, vifs[i].model), + "-net", + GCSPRINTF( + "nic,vlan=%d,macaddr=%s,model=%s", + vifs[i].devid, smac, vifs[i].model), "-net", GCSPRINTF( "tap,vlan=%d,ifname=%s,bridge=%s," -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSKw-0001sv-CD; Thu, 10 May 2012 12:19:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSKu-0001sk-HY for xen-devel@lists.xen.org; Thu, 10 May 2012 12:19:12 +0000 Received: from [193.109.254.147:48850] by server-12.bemta-14.messagelabs.com id BF/C5-05898-F32BBAF4; Thu, 10 May 2012 12:19:11 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336652349!1749703!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28723 invoked from network); 10 May 2012 12:19:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:19:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194240786" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:19:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:19:07 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSKp-0004n2-Eh; Thu, 10 May 2012 13:19:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:19:03 +0100 Message-ID: <1336652343-12279-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> References: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 2/2] libxl: fix indentation in libxl_dm.c for qemu X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fixed indentation on Qemu argument construction for network devices. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 0d7524c..c0d7ca1 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -213,8 +213,10 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, domid, vifs[i].devid, LIBXL_NIC_TYPE_IOEMU); flexarray_vappend(dm_args, - "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", - vifs[i].devid, smac, vifs[i].model), + "-net", + GCSPRINTF( + "nic,vlan=%d,macaddr=%s,model=%s", + vifs[i].devid, smac, vifs[i].model), "-net", GCSPRINTF( "tap,vlan=%d,ifname=%s,bridge=%s," -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSKw-0001t2-NJ; Thu, 10 May 2012 12:19:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSKv-0001sl-4E for xen-devel@lists.xen.org; Thu, 10 May 2012 12:19:13 +0000 Received: from [193.109.254.147:48910] by server-6.bemta-14.messagelabs.com id B5/31-04960-042BBAF4; Thu, 10 May 2012 12:19:12 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336652349!1749703!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28742 invoked from network); 10 May 2012 12:19:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:19:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194240787" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:19:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:19:07 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSKp-0004n2-E5; Thu, 10 May 2012 13:19:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:19:02 +0100 Message-ID: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Currently we only pass script=no to Qemu, to avoid calling any scripts when attaching a tap interface, but we should also pass downscript=no to avoid Qemu trying to execute a script when disconnecting the interface. This prevents the following harmless error message: /etc/qemu-ifdown: could not launch network script Changes since v2: * Remove non related indentation changes. Changes since v1: * Indentation fixes. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index ff5f8ad..0d7524c 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -215,9 +215,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, flexarray_vappend(dm_args, "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model), - "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s", - vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)), - NULL); + "-net", + GCSPRINTF( + "tap,vlan=%d,ifname=%s,bridge=%s," + "script=%s,downscript=%s", + vifs[i].devid, ifname, vifs[i].bridge, + libxl_tapif_script(gc), + libxl_tapif_script(gc)), + NULL); ioemu_vifs++; } } @@ -455,10 +460,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, vifs[i].model, vifs[i].devid, vifs[i].devid, smac)); flexarray_append(dm_args, "-netdev"); - flexarray_append(dm_args, - libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s", - vifs[i].devid, ifname, - libxl_tapif_script(gc))); + flexarray_append(dm_args, GCSPRINTF( + "type=tap,id=net%d,ifname=%s," + "script=%s,downscript=%s", + vifs[i].devid, ifname, + libxl_tapif_script(gc), + libxl_tapif_script(gc))); ioemu_vifs++; } } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:19:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSKw-0001t2-NJ; Thu, 10 May 2012 12:19:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSKv-0001sl-4E for xen-devel@lists.xen.org; Thu, 10 May 2012 12:19:13 +0000 Received: from [193.109.254.147:48910] by server-6.bemta-14.messagelabs.com id B5/31-04960-042BBAF4; Thu, 10 May 2012 12:19:12 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336652349!1749703!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28742 invoked from network); 10 May 2012 12:19:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:19:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194240787" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:19:08 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:19:07 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSKp-0004n2-E5; Thu, 10 May 2012 13:19:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:19:02 +0100 Message-ID: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Currently we only pass script=no to Qemu, to avoid calling any scripts when attaching a tap interface, but we should also pass downscript=no to avoid Qemu trying to execute a script when disconnecting the interface. This prevents the following harmless error message: /etc/qemu-ifdown: could not launch network script Changes since v2: * Remove non related indentation changes. Changes since v1: * Indentation fixes. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl_dm.c | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index ff5f8ad..0d7524c 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -215,9 +215,14 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, flexarray_vappend(dm_args, "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model), - "-net", libxl__sprintf(gc, "tap,vlan=%d,ifname=%s,bridge=%s,script=%s", - vifs[i].devid, ifname, vifs[i].bridge, libxl_tapif_script(gc)), - NULL); + "-net", + GCSPRINTF( + "tap,vlan=%d,ifname=%s,bridge=%s," + "script=%s,downscript=%s", + vifs[i].devid, ifname, vifs[i].bridge, + libxl_tapif_script(gc), + libxl_tapif_script(gc)), + NULL); ioemu_vifs++; } } @@ -455,10 +460,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, vifs[i].model, vifs[i].devid, vifs[i].devid, smac)); flexarray_append(dm_args, "-netdev"); - flexarray_append(dm_args, - libxl__sprintf(gc, "type=tap,id=net%d,ifname=%s,script=%s", - vifs[i].devid, ifname, - libxl_tapif_script(gc))); + flexarray_append(dm_args, GCSPRINTF( + "type=tap,id=net%d,ifname=%s," + "script=%s,downscript=%s", + vifs[i].devid, ifname, + libxl_tapif_script(gc), + libxl_tapif_script(gc))); ioemu_vifs++; } } -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:29:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12:29:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSUG-0002PZ-8a; Thu, 10 May 2012 12:28:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSUE-0002PS-1I for xen-devel@lists.xen.org; Thu, 10 May 2012 12:28:50 +0000 Received: from [85.158.143.99:18974] by server-3.bemta-4.messagelabs.com id 31/85-05853-184BBAF4; Thu, 10 May 2012 12:28:49 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336652925!22043002!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10296 invoked from network); 10 May 2012 12:28:47 -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; 10 May 2012 12:28:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25060537" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:28:44 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:28:43 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSU7-0004vP-Cz; Thu, 10 May 2012 13:28:43 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:28:40 +0100 Message-ID: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add an ao parameter to both functions, since they may become slow in the future. Also move the functions to libxl_device.c, as done with disk and nic add fuctions, so libxl_device_{vkb,vfb}_add are mere wrappers arround libxl__device_{vkb,vfb}_add, that can be called from a running AO operation. Quite a lot of code motion here also, and integration with the new AO domain creation. This should be applied after my "libxl: call hotplug scripts from libxl for vif" series. Changes since v1: * Everything as far as I can tell. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl.c | 148 +++++++----------------------------------- tools/libxl/libxl.h | 6 +- tools/libxl/libxl_create.c | 100 ++++++++++++++++++++++++++-- tools/libxl/libxl_device.c | 147 +++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_dm.c | 4 +- tools/libxl/libxl_internal.h | 13 ++++- 6 files changed, 281 insertions(+), 137 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 5a681b1..f50ecaf 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1962,69 +1962,25 @@ int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb) return 0; } -static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, - libxl_device_vkb *vkb, - libxl__device *device) -{ - device->backend_devid = vkb->devid; - device->backend_domid = vkb->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VKBD; - device->devid = vkb->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VKBD; - - return 0; -} - -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; int rc; - rc = libxl__device_vkb_setdefault(gc, vkb); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_vkb_add(egc, domid, vkb, device); + if (rc) { + LOGE(ERROR, "unable to add vkb %d", vkb->devid); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "domain"); - flexarray_append(back, libxl__domid_to_name(gc, domid)); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, @@ -2089,81 +2045,25 @@ int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb) return 0; } -static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, - libxl_device_vfb *vfb, - libxl__device *device) -{ - device->backend_devid = vfb->devid; - device->backend_domid = vfb->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VFB; - device->devid = vfb->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VFB; - return 0; -} - -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; int rc; - rc = libxl__device_vfb_setdefault(gc, vfb); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_vfb_add(egc, domid, vfb, device); + if (rc) { + LOGE(ERROR, "unable to add vfb %d", vfb->devid); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; - - flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); - flexarray_append_pair(back, "online", "1"); - flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1)); - flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid)); - flexarray_append_pair(back, "vnc", - libxl_defbool_val(vfb->vnc.enable) ? "1" : "0"); - flexarray_append_pair(back, "vnclisten", vfb->vnc.listen); - 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_defbool_val(vfb->vnc.findunused) ? "1" : "0"); - flexarray_append_pair(back, "sdl", - libxl_defbool_val(vfb->sdl.enable) ? "1" : "0"); - flexarray_append_pair(back, "opengl", - libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0"); - if (vfb->sdl.xauthority) { - flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority); - } - 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, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 6689baf..0497175 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -700,14 +700,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, libxl_nicinfo *nicinfo); /* Keyboard */ -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb, + const libxl_asyncop_how *ao_how); 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_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, + const libxl_asyncop_how *ao_how); int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 69f4e4d..974ed89 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -602,6 +602,11 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm); +static void domcreate_misc_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void domcreate_start_devmodel(libxl__egc *egc, + libxl__domain_create_state *dcs); + static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); @@ -775,7 +780,6 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) const uint32_t domid = dcs->guest_domid; libxl_domain_config *const d_config = dcs->guest_config; libxl__domain_build_state *const state = &dcs->build_state; - libxl_ctx *const ctx = CTX; ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, dcs->num_devices, &last); @@ -797,8 +801,8 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) switch (d_config->c_info.type) { case LIBXL_DOMAIN_TYPE_HVM: { - libxl__device_console console; libxl_device_vkb vkb; + libxl__device_console console; ret = init_console_info(&console, 0); if ( ret ) @@ -806,10 +810,94 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); + GCNEW_ARRAY(dcs->devices, 1); + dcs->num_devices = 1; + libxl__init_ao_device(&dcs->devices[0], ao, &dcs->devices); + dcs->devices[0].callback = domcreate_misc_connected; libxl_device_vkb_init(&vkb); - libxl_device_vkb_add(ctx, domid, &vkb); + libxl__device_vkb_add(egc, domid, &vkb, &dcs->devices[0]); libxl_device_vkb_dispose(&vkb); + return; + } + case LIBXL_DOMAIN_TYPE_PV: + { + GCNEW_ARRAY(dcs->devices, d_config->num_vfbs*2); + dcs->num_devices = d_config->num_vfbs*2; + for (i = 0; i < d_config->num_vfbs; i++) { + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_misc_connected; + libxl__init_ao_device(&dcs->devices[i+1], ao, &dcs->devices); + dcs->devices[i+1].callback = domcreate_misc_connected; + libxl__device_vfb_add(egc, domid, &d_config->vfbs[i], + &dcs->devices[i]); + libxl__device_vkb_add(egc, domid, &d_config->vkbs[i], + &dcs->devices[i+1]); + } + + if (!dcs->num_devices) + domcreate_start_devmodel(egc, dcs); + + return; + } + default: + ret = ERROR_INVAL; + goto error_out; + } + abort(); /* not reached */ + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_misc_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int last, ret = 0; + + aorm->state = DEVICE_FINISHED; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting misc devices"); + goto error_out; + } + + domcreate_start_devmodel(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_start_devmodel(libxl__egc *egc, + libxl__domain_create_state *dcs) +{ + STATE_AO_GC(dcs->ao); + int ret; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + libxl__domain_build_state *const state = &dcs->build_state; + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; + + switch (d_config->c_info.type) { + case LIBXL_DOMAIN_TYPE_HVM: + { dcs->dmss.dm.guest_domid = domid; if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) libxl__spawn_stub_dm(egc, &dcs->dmss); @@ -822,11 +910,6 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) int need_qemu = 0; libxl__device_console console; - for (i = 0; i < d_config->num_vfbs; i++) { - libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]); - libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i]); - } - ret = init_console_info(&console, 0); if ( ret ) goto error_out; @@ -862,6 +945,7 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) domcreate_complete(egc, dcs, ret); } + static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int ret) diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 6b431a2..f2c4d50 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -205,6 +205,33 @@ int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, return 0; } +int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__device *device) +{ + device->backend_devid = vkb->devid; + device->backend_domid = vkb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VKBD; + device->devid = vkb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VKBD; + + return 0; +} + +int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__device *device) +{ + device->backend_devid = vfb->devid; + device->backend_domid = vfb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VFB; + device->devid = vfb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VFB; + return 0; +} + int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm) @@ -445,6 +472,126 @@ out: return rc; } +int libxl__device_vkb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vkb *vkb, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + int rc; + + rc = libxl__device_vkb_setdefault(gc, vkb); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_vkb(gc, domid, vkb, device); + if (rc != 0) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "domain"); + flexarray_append(back, libxl__domid_to_name(gc, domid)); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", vkb->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aorm->rc = rc; + aorm->callback(egc, aorm); + return rc; +} + +int libxl__device_vfb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vfb *vfb, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + int rc; + + rc = libxl__device_vfb_setdefault(gc, vfb); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_vfb(gc, domid, vfb, device); + if (rc != 0) goto out_free; + + flexarray_append_pair(back, "frontend-id", GCSPRINTF("%d", domid)); + flexarray_append_pair(back, "online", "1"); + flexarray_append_pair(back, "state", GCSPRINTF("%d", 1)); + flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid)); + flexarray_append_pair(back, "vnc", + libxl_defbool_val(vfb->vnc.enable) ? "1" : "0"); + flexarray_append_pair(back, "vnclisten", vfb->vnc.listen); + flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd); + flexarray_append_pair(back, "vncdisplay", + GCSPRINTF("%d", vfb->vnc.display)); + flexarray_append_pair(back, "vncunused", + libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0"); + flexarray_append_pair(back, "sdl", + libxl_defbool_val(vfb->sdl.enable) ? "1" : "0"); + flexarray_append_pair(back, "opengl", + libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0"); + if (vfb->sdl.xauthority) { + flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority); + } + if (vfb->sdl.display) { + flexarray_append_pair(back, "display", vfb->sdl.display); + } + + flexarray_append_pair(front, "backend-id", + GCSPRINTF("%d", vfb->backend_domid)); + flexarray_append_pair(front, "state", GCSPRINTF("%d", 1)); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + rc = 0; +out_free: + flexarray_free(front); + flexarray_free(back); +out: + aorm->rc = rc; + aorm->callback(egc, aorm); + return rc; +} typedef struct { libxl__gc *gc; diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index c0d7ca1..ed3aae4 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -859,10 +859,10 @@ static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) */ libxl__device_nic_setdefault(gc, &dm_config->vifs[i]); } - ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); + ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0], 0); if (ret) goto out; - ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); + ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0], 0); if (ret) goto out; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 91eba63..d57200f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -788,6 +788,12 @@ _hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, libxl_device_disk *disk, libxl__device *device); +_hidden int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__device *device); +_hidden int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__device *device); _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor); _hidden int libxl__device_disk_dev_number(const char *virtpath, @@ -981,7 +987,12 @@ _hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, _hidden int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aorm); - +_hidden int libxl__device_vkb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__ao_device *aorm); +_hidden int libxl__device_vfb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__ao_device *aorm); /* *----- spawn ----- * -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:29:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12:29:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSUG-0002PZ-8a; Thu, 10 May 2012 12:28:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSUE-0002PS-1I for xen-devel@lists.xen.org; Thu, 10 May 2012 12:28:50 +0000 Received: from [85.158.143.99:18974] by server-3.bemta-4.messagelabs.com id 31/85-05853-184BBAF4; Thu, 10 May 2012 12:28:49 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336652925!22043002!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10296 invoked from network); 10 May 2012 12:28:47 -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; 10 May 2012 12:28:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25060537" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:28:44 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:28:43 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSU7-0004vP-Cz; Thu, 10 May 2012 13:28:43 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:28:40 +0100 Message-ID: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add an ao parameter to both functions, since they may become slow in the future. Also move the functions to libxl_device.c, as done with disk and nic add fuctions, so libxl_device_{vkb,vfb}_add are mere wrappers arround libxl__device_{vkb,vfb}_add, that can be called from a running AO operation. Quite a lot of code motion here also, and integration with the new AO domain creation. This should be applied after my "libxl: call hotplug scripts from libxl for vif" series. Changes since v1: * Everything as far as I can tell. Signed-off-by: Roger Pau Monne --- tools/libxl/libxl.c | 148 +++++++----------------------------------- tools/libxl/libxl.h | 6 +- tools/libxl/libxl_create.c | 100 ++++++++++++++++++++++++++-- tools/libxl/libxl_device.c | 147 +++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_dm.c | 4 +- tools/libxl/libxl_internal.h | 13 ++++- 6 files changed, 281 insertions(+), 137 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 5a681b1..f50ecaf 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1962,69 +1962,25 @@ int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb) return 0; } -static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, - libxl_device_vkb *vkb, - libxl__device *device) -{ - device->backend_devid = vkb->devid; - device->backend_domid = vkb->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VKBD; - device->devid = vkb->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VKBD; - - return 0; -} - -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb) +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; int rc; - rc = libxl__device_vkb_setdefault(gc, vkb); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_vkb_add(egc, domid, vkb, device); + if (rc) { + LOGE(ERROR, "unable to add vkb %d", vkb->devid); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; - - flexarray_append(back, "frontend-id"); - flexarray_append(back, libxl__sprintf(gc, "%d", domid)); - flexarray_append(back, "online"); - flexarray_append(back, "1"); - flexarray_append(back, "state"); - flexarray_append(back, libxl__sprintf(gc, "%d", 1)); - flexarray_append(back, "domain"); - flexarray_append(back, libxl__domid_to_name(gc, domid)); - - flexarray_append(front, "backend-id"); - flexarray_append(front, libxl__sprintf(gc, "%d", vkb->backend_domid)); - flexarray_append(front, "state"); - flexarray_append(front, libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, @@ -2089,81 +2045,25 @@ int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb) return 0; } -static int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, - libxl_device_vfb *vfb, - libxl__device *device) -{ - device->backend_devid = vfb->devid; - device->backend_domid = vfb->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VFB; - device->devid = vfb->devid; - device->domid = domid; - device->kind = LIBXL__DEVICE_KIND_VFB; - return 0; -} - -int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb) +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - flexarray_t *front; - flexarray_t *back; - libxl__device device; + AO_CREATE(ctx, domid, ao_how); + libxl__ao_device *device; int rc; - rc = libxl__device_vfb_setdefault(gc, vfb); - if (rc) goto out; - - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; + GCNEW(device); + libxl__init_ao_device(device, ao, NULL); + device->callback = libxl__device_cb; + rc = libxl__device_vfb_add(egc, domid, vfb, device); + if (rc) { + LOGE(ERROR, "unable to add vfb %d", vfb->devid); goto out; } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } - - rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; - - flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); - flexarray_append_pair(back, "online", "1"); - flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1)); - flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid)); - flexarray_append_pair(back, "vnc", - libxl_defbool_val(vfb->vnc.enable) ? "1" : "0"); - flexarray_append_pair(back, "vnclisten", vfb->vnc.listen); - 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_defbool_val(vfb->vnc.findunused) ? "1" : "0"); - flexarray_append_pair(back, "sdl", - libxl_defbool_val(vfb->sdl.enable) ? "1" : "0"); - flexarray_append_pair(back, "opengl", - libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0"); - if (vfb->sdl.xauthority) { - flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority); - } - 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, "state", libxl__sprintf(gc, "%d", 1)); - libxl__device_generic_add(gc, &device, - libxl__xs_kvs_of_flexarray(gc, back, back->count), - libxl__xs_kvs_of_flexarray(gc, front, front->count)); - rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: - GC_FREE; - return rc; + if (rc) return AO_ABORT(rc); + return AO_INPROGRESS; } int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 6689baf..0497175 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -700,14 +700,16 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic, libxl_nicinfo *nicinfo); /* Keyboard */ -int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb); +int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb, + const libxl_asyncop_how *ao_how); 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_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb); +int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, + const libxl_asyncop_how *ao_how); int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb, const libxl_asyncop_how *ao_how); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 69f4e4d..974ed89 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -602,6 +602,11 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm); +static void domcreate_misc_connected(libxl__egc *egc, libxl__ao_device *aorm); + +static void domcreate_start_devmodel(libxl__egc *egc, + libxl__domain_create_state *dcs); + static void domcreate_console_available(libxl__egc *egc, libxl__domain_create_state *dcs); @@ -775,7 +780,6 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) const uint32_t domid = dcs->guest_domid; libxl_domain_config *const d_config = dcs->guest_config; libxl__domain_build_state *const state = &dcs->build_state; - libxl_ctx *const ctx = CTX; ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, dcs->num_devices, &last); @@ -797,8 +801,8 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) switch (d_config->c_info.type) { case LIBXL_DOMAIN_TYPE_HVM: { - libxl__device_console console; libxl_device_vkb vkb; + libxl__device_console console; ret = init_console_info(&console, 0); if ( ret ) @@ -806,10 +810,94 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); + GCNEW_ARRAY(dcs->devices, 1); + dcs->num_devices = 1; + libxl__init_ao_device(&dcs->devices[0], ao, &dcs->devices); + dcs->devices[0].callback = domcreate_misc_connected; libxl_device_vkb_init(&vkb); - libxl_device_vkb_add(ctx, domid, &vkb); + libxl__device_vkb_add(egc, domid, &vkb, &dcs->devices[0]); libxl_device_vkb_dispose(&vkb); + return; + } + case LIBXL_DOMAIN_TYPE_PV: + { + GCNEW_ARRAY(dcs->devices, d_config->num_vfbs*2); + dcs->num_devices = d_config->num_vfbs*2; + for (i = 0; i < d_config->num_vfbs; i++) { + libxl__init_ao_device(&dcs->devices[i], ao, &dcs->devices); + dcs->devices[i].callback = domcreate_misc_connected; + libxl__init_ao_device(&dcs->devices[i+1], ao, &dcs->devices); + dcs->devices[i+1].callback = domcreate_misc_connected; + libxl__device_vfb_add(egc, domid, &d_config->vfbs[i], + &dcs->devices[i]); + libxl__device_vkb_add(egc, domid, &d_config->vkbs[i], + &dcs->devices[i+1]); + } + + if (!dcs->num_devices) + domcreate_start_devmodel(egc, dcs); + + return; + } + default: + ret = ERROR_INVAL; + goto error_out; + } + abort(); /* not reached */ + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_misc_connected(libxl__egc *egc, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + libxl__domain_create_state *dcs = CONTAINER_OF(aorm->base, *dcs, devices); + int last, ret = 0; + + aorm->state = DEVICE_FINISHED; + + ret = libxl__ao_device_check_last(gc, aorm, dcs->devices, + dcs->num_devices, &last); + if (!last) return; + if (last && ret) { + LOGE(ERROR, "error connecting misc devices"); + goto error_out; + } + + domcreate_start_devmodel(egc, dcs); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_start_devmodel(libxl__egc *egc, + libxl__domain_create_state *dcs) +{ + STATE_AO_GC(dcs->ao); + int ret; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + libxl__domain_build_state *const state = &dcs->build_state; + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; + + switch (d_config->c_info.type) { + case LIBXL_DOMAIN_TYPE_HVM: + { dcs->dmss.dm.guest_domid = domid; if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) libxl__spawn_stub_dm(egc, &dcs->dmss); @@ -822,11 +910,6 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) int need_qemu = 0; libxl__device_console console; - for (i = 0; i < d_config->num_vfbs; i++) { - libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]); - libxl_device_vkb_add(ctx, domid, &d_config->vkbs[i]); - } - ret = init_console_info(&console, 0); if ( ret ) goto error_out; @@ -862,6 +945,7 @@ static void domcreate_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) domcreate_complete(egc, dcs, ret); } + static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int ret) diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 6b431a2..f2c4d50 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -205,6 +205,33 @@ int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, return 0; } +int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__device *device) +{ + device->backend_devid = vkb->devid; + device->backend_domid = vkb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VKBD; + device->devid = vkb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VKBD; + + return 0; +} + +int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__device *device) +{ + device->backend_devid = vfb->devid; + device->backend_domid = vfb->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VFB; + device->devid = vfb->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VFB; + return 0; +} + int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, libxl_device_disk *disk, libxl__ao_device *aorm) @@ -445,6 +472,126 @@ out: return rc; } +int libxl__device_vkb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vkb *vkb, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + int rc; + + rc = libxl__device_vkb_setdefault(gc, vkb); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_vkb(gc, domid, vkb, device); + if (rc != 0) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, GCSPRINTF("%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, GCSPRINTF("%d", 1)); + flexarray_append(back, "domain"); + flexarray_append(back, libxl__domid_to_name(gc, domid)); + + flexarray_append(front, "backend-id"); + flexarray_append(front, GCSPRINTF("%d", vkb->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, GCSPRINTF("%d", 1)); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aorm->rc = rc; + aorm->callback(egc, aorm); + return rc; +} + +int libxl__device_vfb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vfb *vfb, libxl__ao_device *aorm) +{ + STATE_AO_GC(aorm->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + int rc; + + rc = libxl__device_vfb_setdefault(gc, vfb); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out_free; + } + + GCNEW(device); + rc = libxl__device_from_vfb(gc, domid, vfb, device); + if (rc != 0) goto out_free; + + flexarray_append_pair(back, "frontend-id", GCSPRINTF("%d", domid)); + flexarray_append_pair(back, "online", "1"); + flexarray_append_pair(back, "state", GCSPRINTF("%d", 1)); + flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid)); + flexarray_append_pair(back, "vnc", + libxl_defbool_val(vfb->vnc.enable) ? "1" : "0"); + flexarray_append_pair(back, "vnclisten", vfb->vnc.listen); + flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd); + flexarray_append_pair(back, "vncdisplay", + GCSPRINTF("%d", vfb->vnc.display)); + flexarray_append_pair(back, "vncunused", + libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0"); + flexarray_append_pair(back, "sdl", + libxl_defbool_val(vfb->sdl.enable) ? "1" : "0"); + flexarray_append_pair(back, "opengl", + libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0"); + if (vfb->sdl.xauthority) { + flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority); + } + if (vfb->sdl.display) { + flexarray_append_pair(back, "display", vfb->sdl.display); + } + + flexarray_append_pair(front, "backend-id", + GCSPRINTF("%d", vfb->backend_domid)); + flexarray_append_pair(front, "state", GCSPRINTF("%d", 1)); + + libxl__device_generic_add(gc, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + rc = 0; +out_free: + flexarray_free(front); + flexarray_free(back); +out: + aorm->rc = rc; + aorm->callback(egc, aorm); + return rc; +} typedef struct { libxl__gc *gc; diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index c0d7ca1..ed3aae4 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -859,10 +859,10 @@ static void spawn_stub_disk_connected(libxl__egc *egc, libxl__ao_device *aorm) */ libxl__device_nic_setdefault(gc, &dm_config->vifs[i]); } - ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]); + ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0], 0); if (ret) goto out; - ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); + ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0], 0); if (ret) goto out; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 91eba63..d57200f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -788,6 +788,12 @@ _hidden int libxl__device_from_nic(libxl__gc *gc, uint32_t domid, _hidden int libxl__device_from_disk(libxl__gc *gc, uint32_t domid, libxl_device_disk *disk, libxl__device *device); +_hidden int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__device *device); +_hidden int libxl__device_from_vfb(libxl__gc *gc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__device *device); _hidden int libxl__device_physdisk_major_minor(const char *physpath, int *major, int *minor); _hidden int libxl__device_disk_dev_number(const char *virtpath, @@ -981,7 +987,12 @@ _hidden int libxl__device_disk_add(libxl__egc *egc, uint32_t domid, _hidden int libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aorm); - +_hidden int libxl__device_vkb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vkb *vkb, + libxl__ao_device *aorm); +_hidden int libxl__device_vfb_add(libxl__egc *egc, uint32_t domid, + libxl_device_vfb *vfb, + libxl__ao_device *aorm); /* *----- spawn ----- * -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSnL-0002jP-IA; Thu, 10 May 2012 12:48:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSnJ-0002jK-77 for xen-devel@lists.xen.org; Thu, 10 May 2012 12:48:34 +0000 Received: from [193.109.254.147:28799] by server-9.bemta-14.messagelabs.com id 3C/7B-05787-029BBAF4; Thu, 10 May 2012 12:48:32 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336654108!1756098!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15694 invoked from network); 10 May 2012 12:48:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:48:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194246401" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:47:09 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:47:08 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSlv-0005Db-R3; Thu, 10 May 2012 13:47:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:46:53 +0100 Message-ID: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This script is a copy from the QEMU one, wich is itself a copy from the Linux kernel one (as far as I can tell). This script will only check for parts of the patches that touch libxl files, and I've adapted it to match our CODING_STYLE a little bit, major differences include the following: * Allow if (...) do_something(....); * Allow if (...) do_something(...); * Allow declarations like: libxl_type *var; * Checks for the use of the following functions, and complains if found: libxl__sprintf, LIBXL__LOG_*, libxl__gc_owner, printing a nice error message about how to replace them. * Print error message when "libxl_ctx *ctx =" is used, telling the user to use CTX directly instead. To use it, simply go to the root of the repository and use: $ scripts/checkpatch.pl xxxx.patch Signed-off-by: Roger Pau Monne --- scripts/checkpatch.pl | 2906 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 2906 insertions(+), 0 deletions(-) create mode 100755 scripts/checkpatch.pl diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl new file mode 100755 index 0000000..7e82fab --- /dev/null +++ b/scripts/checkpatch.pl @@ -0,0 +1,2906 @@ +#!/usr/bin/perl -w +# (c) 2001, Dave Jones. (the file handling bit) +# (c) 2005, Joel Schopp (the ugly bit) +# (c) 2007,2008, Andy Whitcroft (new conditions, test suite) +# (c) 2008-2010 Andy Whitcroft +# Licensed under the terms of the GNU GPL License version 2 + +use strict; + +my $P = $0; +$P =~ s@.*/@@g; + +my $V = '0.31'; + +use Getopt::Long qw(:config no_auto_abbrev); + +my $quiet = 0; +my $tree = 1; +my $chk_signoff = 1; +my $chk_patch = 1; +my $tst_only; +my $emacs = 0; +my $terse = 0; +my $file = 0; +my $check = 0; +my $summary = 1; +my $mailback = 0; +my $summary_file = 0; +my $root; +my %debug; +my $help = 0; + +sub help { + my ($exitcode) = @_; + + print << "EOM"; +Usage: $P [OPTION]... [FILE]... +Version: $V + +Options: + -q, --quiet quiet + --no-tree run without a kernel tree + --no-signoff do not check for 'Signed-off-by' line + --patch treat FILE as patchfile (default) + --emacs emacs compile window format + --terse one line per report + -f, --file treat FILE as regular source file + --subjective, --strict enable more subjective tests + --root=PATH PATH to the kernel tree root + --no-summary suppress the per-file summary + --mailback only produce a report in case of warnings/errors + --summary-file include the filename in summary + --debug KEY=[0|1] turn on/off debugging of KEY, where KEY is one of + 'values', 'possible', 'type', and 'attr' (default + is all off) + --test-only=WORD report only warnings/errors containing WORD + literally + -h, --help, --version display this help and exit + +When FILE is - read standard input. +EOM + + exit($exitcode); +} + +GetOptions( + 'q|quiet+' => \$quiet, + 'tree!' => \$tree, + 'signoff!' => \$chk_signoff, + 'patch!' => \$chk_patch, + 'emacs!' => \$emacs, + 'terse!' => \$terse, + 'f|file!' => \$file, + 'subjective!' => \$check, + 'strict!' => \$check, + 'root=s' => \$root, + 'summary!' => \$summary, + 'mailback!' => \$mailback, + 'summary-file!' => \$summary_file, + + 'debug=s' => \%debug, + 'test-only=s' => \$tst_only, + 'h|help' => \$help, + 'version' => \$help +) or help(1); + +help(0) if ($help); + +my $exit = 0; + +if ($#ARGV < 0) { + print "$P: no input files\n"; + exit(1); +} + +my $dbg_values = 0; +my $dbg_possible = 0; +my $dbg_type = 0; +my $dbg_attr = 0; +for my $key (keys %debug) { + ## no critic + eval "\${dbg_$key} = '$debug{$key}';"; + die "$@" if ($@); +} + +my $rpt_cleaners = 0; + +if ($terse) { + $emacs = 1; + $quiet++; +} + +if ($tree) { + if (defined $root) { + if (!top_of_kernel_tree($root)) { + die "$P: $root: --root does not point at a valid tree\n"; + } + } else { + if (top_of_kernel_tree('.')) { + $root = '.'; + } elsif ($0 =~ m@(.*)/scripts/[^/]*$@ && + top_of_kernel_tree($1)) { + $root = $1; + } + } + + if (!defined $root) { + print "Must be run from the top-level dir. of a kernel tree\n"; + exit(2); + } +} + +my $emitted_corrupt = 0; + +our $Ident = qr{ + [A-Za-z_][A-Za-z\d_]* + (?:\s*\#\#\s*[A-Za-z_][A-Za-z\d_]*)* + }x; +our $Storage = qr{extern|static|asmlinkage}; +our $Sparse = qr{ + __user| + __kernel| + __force| + __iomem| + __must_check| + __init_refok| + __kprobes| + __ref + }x; + +# Notes to $Attribute: +# We need \b after 'init' otherwise 'initconst' will cause a false positive in a check +our $Attribute = qr{ + const| + __percpu| + __nocast| + __safe| + __bitwise__| + __packed__| + __packed2__| + __naked| + __maybe_unused| + __always_unused| + __noreturn| + __used| + __cold| + __noclone| + __deprecated| + __read_mostly| + __kprobes| + __(?:mem|cpu|dev|)(?:initdata|initconst|init\b)| + ____cacheline_aligned| + ____cacheline_aligned_in_smp| + ____cacheline_internodealigned_in_smp| + __weak + }x; +our $Modifier; +our $Inline = qr{inline|__always_inline|noinline}; +our $Member = qr{->$Ident|\.$Ident|\[[^]]*\]}; +our $Lval = qr{$Ident(?:$Member)*}; + +our $Constant = qr{(?:[0-9]+|0x[0-9a-fA-F]+)[UL]*}; +our $Assignment = qr{(?:\*\=|/=|%=|\+=|-=|<<=|>>=|&=|\^=|\|=|=)}; +our $Compare = qr{<=|>=|==|!=|<|>}; +our $Operators = qr{ + <=|>=|==|!=| + =>|->|<<|>>|<|>|!|~| + &&|\|\||,|\^|\+\+|--|&|\||\+|-|\*|\/|% + }x; + +our $NonptrType; +our $Type; +our $Declare; + +our $UTF8 = qr { + [\x09\x0A\x0D\x20-\x7E] # ASCII + | [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte + | \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs + | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte + | \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates + | \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3 + | [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15 + | \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16 +}x; + +our $typeTypedefs = qr{(?x: + (?:__)?(?:u|s|be|le)(?:8|16|32|64)| + atomic_t +)}; + +our $logFunctions = qr{(?x: + printk| + pr_(debug|dbg|vdbg|devel|info|warning|err|notice|alert|crit|emerg|cont)| + (dev|netdev|netif)_(printk|dbg|vdbg|info|warn|err|notice|alert|crit|emerg|WARN)| + WARN| + panic +)}; + +our @typeList = ( + qr{void}, + qr{(?:unsigned\s+)?char}, + qr{(?:unsigned\s+)?short}, + qr{(?:unsigned\s+)?int}, + qr{(?:unsigned\s+)?long}, + qr{(?:unsigned\s+)?long\s+int}, + qr{(?:unsigned\s+)?long\s+long}, + qr{(?:unsigned\s+)?long\s+long\s+int}, + qr{unsigned}, + qr{float}, + qr{double}, + qr{bool}, + qr{struct\s+$Ident}, + qr{union\s+$Ident}, + qr{enum\s+$Ident}, + qr{${Ident}_t}, + qr{${Ident}_handler}, + qr{${Ident}_handler_fn}, +); +our @modifierList = ( + qr{fastcall}, +); + +our $allowed_asm_includes = qr{(?x: + irq| + memory +)}; +# memory.h: ARM has a custom one + +sub build_types { + my $mods = "(?x: \n" . join("|\n ", @modifierList) . "\n)"; + my $all = "(?x: \n" . join("|\n ", @typeList) . "\n)"; + $Modifier = qr{(?:$Attribute|$Sparse|$mods)}; + $NonptrType = qr{ + (?:$Modifier\s+|const\s+)* + (?: + (?:typeof|__typeof__)\s*\(\s*\**\s*$Ident\s*\)| + (?:$typeTypedefs\b)| + (?:${all}\b) + ) + (?:\s+$Modifier|\s+const)* + }x; + $Type = qr{ + $NonptrType + (?:[\s\*]+\s*const|[\s\*]+|(?:\s*\[\s*\])+)? + (?:\s+$Inline|\s+$Modifier)* + }x; + $Declare = qr{(?:$Storage\s+)?$Type}; +} +build_types(); + +$chk_signoff = 0 if ($file); + +my @dep_includes = (); +my @dep_functions = (); +my $removal = "Documentation/feature-removal-schedule.txt"; +if ($tree && -f "$root/$removal") { + open(my $REMOVE, '<', "$root/$removal") || + die "$P: $removal: open failed - $!\n"; + while (<$REMOVE>) { + if (/^Check:\s+(.*\S)/) { + for my $entry (split(/[, ]+/, $1)) { + if ($entry =~ m@include/(.*)@) { + push(@dep_includes, $1); + + } elsif ($entry !~ m@/@) { + push(@dep_functions, $entry); + } + } + } + } + close($REMOVE); +} + +my @rawlines = (); +my @lines = (); +my $vname; +for my $filename (@ARGV) { + my $FILE; + if ($file) { + open($FILE, '-|', "diff -u /dev/null $filename") || + die "$P: $filename: diff failed - $!\n"; + } elsif ($filename eq '-') { + open($FILE, '<&STDIN'); + } else { + open($FILE, '<', "$filename") || + die "$P: $filename: open failed - $!\n"; + } + if ($filename eq '-') { + $vname = 'Your patch'; + } else { + $vname = $filename; + } + while (<$FILE>) { + chomp; + push(@rawlines, $_); + } + close($FILE); + if (!process($filename)) { + $exit = 1; + } + @rawlines = (); + @lines = (); +} + +exit($exit); + +sub top_of_kernel_tree { + my ($root) = @_; + + my @tree_check = ( + "COPYING", "MAINTAINERS", "Makefile", + "README", "docs" + ); + + foreach my $check (@tree_check) { + if (! -e $root . '/' . $check) { + return 0; + } + } + return 1; +} + +sub expand_tabs { + my ($str) = @_; + + my $res = ''; + my $n = 0; + for my $c (split(//, $str)) { + if ($c eq "\t") { + $res .= ' '; + $n++; + for (; ($n % 8) != 0; $n++) { + $res .= ' '; + } + next; + } + $res .= $c; + $n++; + } + + return $res; +} +sub copy_spacing { + (my $res = shift) =~ tr/\t/ /c; + return $res; +} + +sub line_stats { + my ($line) = @_; + + # Drop the diff line leader and expand tabs + $line =~ s/^.//; + $line = expand_tabs($line); + + # Pick the indent from the front of the line. + my ($white) = ($line =~ /^(\s*)/); + + return (length($line), length($white)); +} + +my $sanitise_quote = ''; + +sub sanitise_line_reset { + my ($in_comment) = @_; + + if ($in_comment) { + $sanitise_quote = '*/'; + } else { + $sanitise_quote = ''; + } +} +sub sanitise_line { + my ($line) = @_; + + my $res = ''; + my $l = ''; + + my $qlen = 0; + my $off = 0; + my $c; + + # Always copy over the diff marker. + $res = substr($line, 0, 1); + + for ($off = 1; $off < length($line); $off++) { + $c = substr($line, $off, 1); + + # Comments we are wacking completly including the begin + # and end, all to $;. + if ($sanitise_quote eq '' && substr($line, $off, 2) eq '/*') { + $sanitise_quote = '*/'; + + substr($res, $off, 2, "$;$;"); + $off++; + next; + } + if ($sanitise_quote eq '*/' && substr($line, $off, 2) eq '*/') { + $sanitise_quote = ''; + substr($res, $off, 2, "$;$;"); + $off++; + next; + } + if ($sanitise_quote eq '' && substr($line, $off, 2) eq '//') { + $sanitise_quote = '//'; + + substr($res, $off, 2, $sanitise_quote); + $off++; + next; + } + + # A \ in a string means ignore the next character. + if (($sanitise_quote eq "'" || $sanitise_quote eq '"') && + $c eq "\\") { + substr($res, $off, 2, 'XX'); + $off++; + next; + } + # Regular quotes. + if ($c eq "'" || $c eq '"') { + if ($sanitise_quote eq '') { + $sanitise_quote = $c; + + substr($res, $off, 1, $c); + next; + } elsif ($sanitise_quote eq $c) { + $sanitise_quote = ''; + } + } + + #print "c<$c> SQ<$sanitise_quote>\n"; + if ($off != 0 && $sanitise_quote eq '*/' && $c ne "\t") { + substr($res, $off, 1, $;); + } elsif ($off != 0 && $sanitise_quote eq '//' && $c ne "\t") { + substr($res, $off, 1, $;); + } elsif ($off != 0 && $sanitise_quote && $c ne "\t") { + substr($res, $off, 1, 'X'); + } else { + substr($res, $off, 1, $c); + } + } + + if ($sanitise_quote eq '//') { + $sanitise_quote = ''; + } + + # The pathname on a #include may be surrounded by '<' and '>'. + if ($res =~ /^.\s*\#\s*include\s+\<(.*)\>/) { + my $clean = 'X' x length($1); + $res =~ s@\<.*\>@<$clean>@; + + # The whole of a #error is a string. + } elsif ($res =~ /^.\s*\#\s*(?:error|warning)\s+(.*)\b/) { + my $clean = 'X' x length($1); + $res =~ s@(\#\s*(?:error|warning)\s+).*@$1$clean@; + } + + return $res; +} + +sub ctx_statement_block { + my ($linenr, $remain, $off) = @_; + my $line = $linenr - 1; + my $blk = ''; + my $soff = $off; + my $coff = $off - 1; + my $coff_set = 0; + + my $loff = 0; + + my $type = ''; + my $level = 0; + my @stack = (); + my $p; + my $c; + my $len = 0; + + my $remainder; + while (1) { + @stack = (['', 0]) if ($#stack == -1); + + #warn "CSB: blk<$blk> remain<$remain>\n"; + # If we are about to drop off the end, pull in more + # context. + if ($off >= $len) { + for (; $remain > 0; $line++) { + last if (!defined $lines[$line]); + next if ($lines[$line] =~ /^-/); + $remain--; + $loff = $len; + $blk .= $lines[$line] . "\n"; + $len = length($blk); + $line++; + last; + } + # Bail if there is no further context. + #warn "CSB: blk<$blk> off<$off> len<$len>\n"; + if ($off >= $len) { + last; + } + } + $p = $c; + $c = substr($blk, $off, 1); + $remainder = substr($blk, $off); + + #warn "CSB: c<$c> type<$type> level<$level> remainder<$remainder> coff_set<$coff_set>\n"; + + # Handle nested #if/#else. + if ($remainder =~ /^#\s*(?:ifndef|ifdef|if)\s/) { + push(@stack, [ $type, $level ]); + } elsif ($remainder =~ /^#\s*(?:else|elif)\b/) { + ($type, $level) = @{$stack[$#stack - 1]}; + } elsif ($remainder =~ /^#\s*endif\b/) { + ($type, $level) = @{pop(@stack)}; + } + + # Statement ends at the ';' or a close '}' at the + # outermost level. + if ($level == 0 && $c eq ';') { + last; + } + + # An else is really a conditional as long as its not else if + if ($level == 0 && $coff_set == 0 && + (!defined($p) || $p =~ /(?:\s|\}|\+)/) && + $remainder =~ /^(else)(?:\s|{)/ && + $remainder !~ /^else\s+if\b/) { + $coff = $off + length($1) - 1; + $coff_set = 1; + #warn "CSB: mark coff<$coff> soff<$soff> 1<$1>\n"; + #warn "[" . substr($blk, $soff, $coff - $soff + 1) . "]\n"; + } + + if (($type eq '' || $type eq '(') && $c eq '(') { + $level++; + $type = '('; + } + if ($type eq '(' && $c eq ')') { + $level--; + $type = ($level != 0)? '(' : ''; + + if ($level == 0 && $coff < $soff) { + $coff = $off; + $coff_set = 1; + #warn "CSB: mark coff<$coff>\n"; + } + } + if (($type eq '' || $type eq '{') && $c eq '{') { + $level++; + $type = '{'; + } + if ($type eq '{' && $c eq '}') { + $level--; + $type = ($level != 0)? '{' : ''; + + if ($level == 0) { + if (substr($blk, $off + 1, 1) eq ';') { + $off++; + } + last; + } + } + $off++; + } + # We are truly at the end, so shuffle to the next line. + if ($off == $len) { + $loff = $len + 1; + $line++; + $remain--; + } + + my $statement = substr($blk, $soff, $off - $soff + 1); + my $condition = substr($blk, $soff, $coff - $soff + 1); + + #warn "STATEMENT<$statement>\n"; + #warn "CONDITION<$condition>\n"; + + #print "coff<$coff> soff<$off> loff<$loff>\n"; + + return ($statement, $condition, + $line, $remain + 1, $off - $loff + 1, $level); +} + +sub statement_lines { + my ($stmt) = @_; + + # Strip the diff line prefixes and rip blank lines at start and end. + $stmt =~ s/(^|\n)./$1/g; + $stmt =~ s/^\s*//; + $stmt =~ s/\s*$//; + + my @stmt_lines = ($stmt =~ /\n/g); + + return $#stmt_lines + 2; +} + +sub statement_rawlines { + my ($stmt) = @_; + + my @stmt_lines = ($stmt =~ /\n/g); + + return $#stmt_lines + 2; +} + +sub statement_block_size { + my ($stmt) = @_; + + $stmt =~ s/(^|\n)./$1/g; + $stmt =~ s/^\s*{//; + $stmt =~ s/}\s*$//; + $stmt =~ s/^\s*//; + $stmt =~ s/\s*$//; + + my @stmt_lines = ($stmt =~ /\n/g); + my @stmt_statements = ($stmt =~ /;/g); + + my $stmt_lines = $#stmt_lines + 2; + my $stmt_statements = $#stmt_statements + 1; + + if ($stmt_lines > $stmt_statements) { + return $stmt_lines; + } else { + return $stmt_statements; + } +} + +sub ctx_statement_full { + my ($linenr, $remain, $off) = @_; + my ($statement, $condition, $level); + + my (@chunks); + + # Grab the first conditional/block pair. + ($statement, $condition, $linenr, $remain, $off, $level) = + ctx_statement_block($linenr, $remain, $off); + #print "F: c<$condition> s<$statement> remain<$remain>\n"; + push(@chunks, [ $condition, $statement ]); + if (!($remain > 0 && $condition =~ /^\s*(?:\n[+-])?\s*(?:if|else|do)\b/s)) { + return ($level, $linenr, @chunks); + } + + # Pull in the following conditional/block pairs and see if they + # could continue the statement. + for (;;) { + ($statement, $condition, $linenr, $remain, $off, $level) = + ctx_statement_block($linenr, $remain, $off); + #print "C: c<$condition> s<$statement> remain<$remain>\n"; + last if (!($remain > 0 && $condition =~ /^(?:\s*\n[+-])*\s*(?:else|do)\b/s)); + #print "C: push\n"; + push(@chunks, [ $condition, $statement ]); + } + + return ($level, $linenr, @chunks); +} + +sub ctx_block_get { + my ($linenr, $remain, $outer, $open, $close, $off) = @_; + my $line; + my $start = $linenr - 1; + my $blk = ''; + my @o; + my @c; + my @res = (); + + my $level = 0; + my @stack = ($level); + for ($line = $start; $remain > 0; $line++) { + next if ($rawlines[$line] =~ /^-/); + $remain--; + + $blk .= $rawlines[$line]; + + # Handle nested #if/#else. + if ($lines[$line] =~ /^.\s*#\s*(?:ifndef|ifdef|if)\s/) { + push(@stack, $level); + } elsif ($lines[$line] =~ /^.\s*#\s*(?:else|elif)\b/) { + $level = $stack[$#stack - 1]; + } elsif ($lines[$line] =~ /^.\s*#\s*endif\b/) { + $level = pop(@stack); + } + + foreach my $c (split(//, $lines[$line])) { + ##print "C<$c>L<$level><$open$close>O<$off>\n"; + if ($off > 0) { + $off--; + next; + } + + if ($c eq $close && $level > 0) { + $level--; + last if ($level == 0); + } elsif ($c eq $open) { + $level++; + } + } + + if (!$outer || $level <= 1) { + push(@res, $rawlines[$line]); + } + + last if ($level == 0); + } + + return ($level, @res); +} +sub ctx_block_outer { + my ($linenr, $remain) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 1, '{', '}', 0); + return @r; +} +sub ctx_block { + my ($linenr, $remain) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 0, '{', '}', 0); + return @r; +} +sub ctx_statement { + my ($linenr, $remain, $off) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 0, '(', ')', $off); + return @r; +} +sub ctx_block_level { + my ($linenr, $remain) = @_; + + return ctx_block_get($linenr, $remain, 0, '{', '}', 0); +} +sub ctx_statement_level { + my ($linenr, $remain, $off) = @_; + + return ctx_block_get($linenr, $remain, 0, '(', ')', $off); +} + +sub ctx_locate_comment { + my ($first_line, $end_line) = @_; + + # Catch a comment on the end of the line itself. + my ($current_comment) = ($rawlines[$end_line - 1] =~ m@.*(/\*.*\*/)\s*(?:\\\s*)?$@); + return $current_comment if (defined $current_comment); + + # Look through the context and try and figure out if there is a + # comment. + my $in_comment = 0; + $current_comment = ''; + for (my $linenr = $first_line; $linenr < $end_line; $linenr++) { + my $line = $rawlines[$linenr - 1]; + #warn " $line\n"; + if ($linenr == $first_line and $line =~ m@^.\s*\*@) { + $in_comment = 1; + } + if ($line =~ m@/\*@) { + $in_comment = 1; + } + if (!$in_comment && $current_comment ne '') { + $current_comment = ''; + } + $current_comment .= $line . "\n" if ($in_comment); + if ($line =~ m@\*/@) { + $in_comment = 0; + } + } + + chomp($current_comment); + return($current_comment); +} +sub ctx_has_comment { + my ($first_line, $end_line) = @_; + my $cmt = ctx_locate_comment($first_line, $end_line); + + ##print "LINE: $rawlines[$end_line - 1 ]\n"; + ##print "CMMT: $cmt\n"; + + return ($cmt ne ''); +} + +sub raw_line { + my ($linenr, $cnt) = @_; + + my $offset = $linenr - 1; + $cnt++; + + my $line; + while ($cnt) { + $line = $rawlines[$offset++]; + next if (defined($line) && $line =~ /^-/); + $cnt--; + } + + return $line; +} + +sub cat_vet { + my ($vet) = @_; + my ($res, $coded); + + $res = ''; + while ($vet =~ /([^[:cntrl:]]*)([[:cntrl:]]|$)/g) { + $res .= $1; + if ($2 ne '') { + $coded = sprintf("^%c", unpack('C', $2) + 64); + $res .= $coded; + } + } + $res =~ s/$/\$/; + + return $res; +} + +my $av_preprocessor = 0; +my $av_pending; +my @av_paren_type; +my $av_pend_colon; + +sub annotate_reset { + $av_preprocessor = 0; + $av_pending = '_'; + @av_paren_type = ('E'); + $av_pend_colon = 'O'; +} + +sub annotate_values { + my ($stream, $type) = @_; + + my $res; + my $var = '_' x length($stream); + my $cur = $stream; + + print "$stream\n" if ($dbg_values > 1); + + while (length($cur)) { + @av_paren_type = ('E') if ($#av_paren_type < 0); + print " <" . join('', @av_paren_type) . + "> <$type> <$av_pending>" if ($dbg_values > 1); + if ($cur =~ /^(\s+)/o) { + print "WS($1)\n" if ($dbg_values > 1); + if ($1 =~ /\n/ && $av_preprocessor) { + $type = pop(@av_paren_type); + $av_preprocessor = 0; + } + + } elsif ($cur =~ /^(\(\s*$Type\s*)\)/ && $av_pending eq '_') { + print "CAST($1)\n" if ($dbg_values > 1); + push(@av_paren_type, $type); + $type = 'C'; + + } elsif ($cur =~ /^($Type)\s*(?:$Ident|,|\)|\(|\s*$)/) { + print "DECLARE($1)\n" if ($dbg_values > 1); + $type = 'T'; + + } elsif ($cur =~ /^($Modifier)\s*/) { + print "MODIFIER($1)\n" if ($dbg_values > 1); + $type = 'T'; + + } elsif ($cur =~ /^(\#\s*define\s*$Ident)(\(?)/o) { + print "DEFINE($1,$2)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + push(@av_paren_type, $type); + if ($2 ne '') { + $av_pending = 'N'; + } + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:undef\s*$Ident|include\b))/o) { + print "UNDEF($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + push(@av_paren_type, $type); + + } elsif ($cur =~ /^(\#\s*(?:ifdef|ifndef|if))/o) { + print "PRE_START($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + + push(@av_paren_type, $type); + push(@av_paren_type, $type); + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:else|elif))/o) { + print "PRE_RESTART($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + + push(@av_paren_type, $av_paren_type[$#av_paren_type]); + + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:endif))/o) { + print "PRE_END($1)\n" if ($dbg_values > 1); + + $av_preprocessor = 1; + + # Assume all arms of the conditional end as this + # one does, and continue as if the #endif was not here. + pop(@av_paren_type); + push(@av_paren_type, $type); + $type = 'E'; + + } elsif ($cur =~ /^(\\\n)/o) { + print "PRECONT($1)\n" if ($dbg_values > 1); + + } elsif ($cur =~ /^(__attribute__)\s*\(?/o) { + print "ATTR($1)\n" if ($dbg_values > 1); + $av_pending = $type; + $type = 'N'; + + } elsif ($cur =~ /^(sizeof)\s*(\()?/o) { + print "SIZEOF($1)\n" if ($dbg_values > 1); + if (defined $2) { + $av_pending = 'V'; + } + $type = 'N'; + + } elsif ($cur =~ /^(if|while|for)\b/o) { + print "COND($1)\n" if ($dbg_values > 1); + $av_pending = 'E'; + $type = 'N'; + + } elsif ($cur =~/^(case)/o) { + print "CASE($1)\n" if ($dbg_values > 1); + $av_pend_colon = 'C'; + $type = 'N'; + + } elsif ($cur =~/^(return|else|goto|typeof|__typeof__)\b/o) { + print "KEYWORD($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(\()/o) { + print "PAREN('$1')\n" if ($dbg_values > 1); + push(@av_paren_type, $av_pending); + $av_pending = '_'; + $type = 'N'; + + } elsif ($cur =~ /^(\))/o) { + my $new_type = pop(@av_paren_type); + if ($new_type ne '_') { + $type = $new_type; + print "PAREN('$1') -> $type\n" + if ($dbg_values > 1); + } else { + print "PAREN('$1')\n" if ($dbg_values > 1); + } + + } elsif ($cur =~ /^($Ident)\s*\(/o) { + print "FUNC($1)\n" if ($dbg_values > 1); + $type = 'V'; + $av_pending = 'V'; + + } elsif ($cur =~ /^($Ident\s*):(?:\s*\d+\s*(,|=|;))?/) { + if (defined $2 && $type eq 'C' || $type eq 'T') { + $av_pend_colon = 'B'; + } elsif ($type eq 'E') { + $av_pend_colon = 'L'; + } + print "IDENT_COLON($1,$type>$av_pend_colon)\n" if ($dbg_values > 1); + $type = 'V'; + + } elsif ($cur =~ /^($Ident|$Constant)/o) { + print "IDENT($1)\n" if ($dbg_values > 1); + $type = 'V'; + + } elsif ($cur =~ /^($Assignment)/o) { + print "ASSIGN($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~/^(;|{|})/) { + print "END($1)\n" if ($dbg_values > 1); + $type = 'E'; + $av_pend_colon = 'O'; + + } elsif ($cur =~/^(,)/) { + print "COMMA($1)\n" if ($dbg_values > 1); + $type = 'C'; + + } elsif ($cur =~ /^(\?)/o) { + print "QUESTION($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(:)/o) { + print "COLON($1,$av_pend_colon)\n" if ($dbg_values > 1); + + substr($var, length($res), 1, $av_pend_colon); + if ($av_pend_colon eq 'C' || $av_pend_colon eq 'L') { + $type = 'E'; + } else { + $type = 'N'; + } + $av_pend_colon = 'O'; + + } elsif ($cur =~ /^(\[)/o) { + print "CLOSE($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(-(?![->])|\+(?!\+)|\*|\&\&|\&)/o) { + my $variant; + + print "OPV($1)\n" if ($dbg_values > 1); + if ($type eq 'V') { + $variant = 'B'; + } else { + $variant = 'U'; + } + + substr($var, length($res), 1, $variant); + $type = 'N'; + + } elsif ($cur =~ /^($Operators)/o) { + print "OP($1)\n" if ($dbg_values > 1); + if ($1 ne '++' && $1 ne '--') { + $type = 'N'; + } + + } elsif ($cur =~ /(^.)/o) { + print "C($1)\n" if ($dbg_values > 1); + } + if (defined $1) { + $cur = substr($cur, length($1)); + $res .= $type x length($1); + } + } + + return ($res, $var); +} + +sub possible { + my ($possible, $line) = @_; + my $notPermitted = qr{(?: + ^(?: + $Modifier| + $Storage| + $Type| + DEFINE_\S+ + )$| + ^(?: + goto| + return| + case| + else| + asm|__asm__| + do + )(?:\s|$)| + ^(?:typedef|struct|enum)\b + )}x; + warn "CHECK<$possible> ($line)\n" if ($dbg_possible > 2); + if ($possible !~ $notPermitted) { + # Check for modifiers. + $possible =~ s/\s*$Storage\s*//g; + $possible =~ s/\s*$Sparse\s*//g; + if ($possible =~ /^\s*$/) { + + } elsif ($possible =~ /\s/) { + $possible =~ s/\s*$Type\s*//g; + for my $modifier (split(' ', $possible)) { + if ($modifier !~ $notPermitted) { + warn "MODIFIER: $modifier ($possible) ($line)\n" if ($dbg_possible); + push(@modifierList, $modifier); + } + } + + } else { + warn "POSSIBLE: $possible ($line)\n" if ($dbg_possible); + push(@typeList, $possible); + } + build_types(); + } else { + warn "NOTPOSS: $possible ($line)\n" if ($dbg_possible > 1); + } +} + +my $prefix = ''; + +sub report { + if (defined $tst_only && $_[0] !~ /\Q$tst_only\E/) { + return 0; + } + my $line = $prefix . $_[0]; + + $line = (split('\n', $line))[0] . "\n" if ($terse); + + push(our @report, $line); + + return 1; +} +sub report_dump { + our @report; +} +sub ERROR { + if (report("ERROR: $_[0]\n")) { + our $clean = 0; + our $cnt_error++; + } +} +sub WARN { + if (report("WARNING: $_[0]\n")) { + our $clean = 0; + our $cnt_warn++; + } +} +sub CHK { + if ($check && report("CHECK: $_[0]\n")) { + our $clean = 0; + our $cnt_chk++; + } +} + +sub check_absolute_file { + my ($absolute, $herecurr) = @_; + my $file = $absolute; + + ##print "absolute<$absolute>\n"; + + # See if any suffix of this path is a path within the tree. + while ($file =~ s@^[^/]*/@@) { + if (-f "$root/$file") { + ##print "file<$file>\n"; + last; + } + } + if (! -f _) { + return 0; + } + + # It is, so see if the prefix is acceptable. + my $prefix = $absolute; + substr($prefix, -length($file)) = ''; + + ##print "prefix<$prefix>\n"; + if ($prefix ne ".../") { + WARN("use relative pathname instead of absolute in changelog text\n" . $herecurr); + } +} + +sub process { + my $filename = shift; + + my $linenr=0; + my $prevline=""; + my $prevrawline=""; + my $stashline=""; + my $stashrawline=""; + + my $length; + my $indent; + my $previndent=0; + my $stashindent=0; + + our $clean = 1; + my $signoff = 0; + my $is_patch = 0; + + our @report = (); + our $cnt_lines = 0; + our $cnt_error = 0; + our $cnt_warn = 0; + our $cnt_chk = 0; + + # Trace the real file/line as we go. + my $realfile = ''; + my $realline = 0; + my $realcnt = 0; + my $here = ''; + my $in_comment = 0; + my $comment_edge = 0; + my $first_line = 0; + my $p1_prefix = ''; + + my $prev_values = 'E'; + + # suppression flags + my %suppress_ifbraces; + my %suppress_whiletrailers; + my %suppress_export; + + # Pre-scan the patch sanitizing the lines. + # Pre-scan the patch looking for any __setup documentation. + # + my @setup_docs = (); + my $setup_docs = 0; + + sanitise_line_reset(); + my $line; + foreach my $rawline (@rawlines) { + $linenr++; + $line = $rawline; + + if ($rawline=~/^\+\+\+\s+(\S+)/) { + $setup_docs = 0; + if ($1 =~ m@Documentation/kernel-parameters.txt$@) { + $setup_docs = 1; + } + #next; + } + if ($rawline=~/^\@\@ -\d+(?:,\d+)? \+(\d+)(,(\d+))? \@\@/) { + $realline=$1-1; + if (defined $2) { + $realcnt=$3+1; + } else { + $realcnt=1+1; + } + $in_comment = 0; + + # Guestimate if this is a continuing comment. Run + # the context looking for a comment "edge". If this + # edge is a close comment then we must be in a comment + # at context start. + my $edge; + my $cnt = $realcnt; + for (my $ln = $linenr + 1; $cnt > 0; $ln++) { + next if (defined $rawlines[$ln - 1] && + $rawlines[$ln - 1] =~ /^-/); + $cnt--; + #print "RAW<$rawlines[$ln - 1]>\n"; + last if (!defined $rawlines[$ln - 1]); + if ($rawlines[$ln - 1] =~ m@(/\*|\*/)@ && + $rawlines[$ln - 1] !~ m@"[^"]*(?:/\*|\*/)[^"]*"@) { + ($edge) = $1; + last; + } + } + if (defined $edge && $edge eq '*/') { + $in_comment = 1; + } + + # Guestimate if this is a continuing comment. If this + # is the start of a diff block and this line starts + # ' *' then it is very likely a comment. + if (!defined $edge && + $rawlines[$linenr] =~ m@^.\s*(?:\*\*+| \*)(?:\s|$)@) + { + $in_comment = 1; + } + + ##print "COMMENT:$in_comment edge<$edge> $rawline\n"; + sanitise_line_reset($in_comment); + + } elsif ($realcnt && $rawline =~ /^(?:\+| |$)/) { + # Standardise the strings and chars within the input to + # simplify matching -- only bother with positive lines. + $line = sanitise_line($rawline); + } + push(@lines, $line); + + if ($realcnt > 1) { + $realcnt-- if ($line =~ /^(?:\+| |$)/); + } else { + $realcnt = 0; + } + + #print "==>$rawline\n"; + #print "-->$line\n"; + + if ($setup_docs && $line =~ /^\+/) { + push(@setup_docs, $line); + } + } + + $prefix = ''; + + $realcnt = 0; + $linenr = 0; + foreach my $line (@lines) { + $linenr++; + + my $rawline = $rawlines[$linenr - 1]; + +#extract the line range in the file after the patch is applied + if ($line=~/^\@\@ -\d+(?:,\d+)? \+(\d+)(,(\d+))? \@\@/) { + $is_patch = 1; + $first_line = $linenr + 1; + $realline=$1-1; + if (defined $2) { + $realcnt=$3+1; + } else { + $realcnt=1+1; + } + annotate_reset(); + $prev_values = 'E'; + + %suppress_ifbraces = (); + %suppress_whiletrailers = (); + %suppress_export = (); + next; + +# track the line number as we move through the hunk, note that +# new versions of GNU diff omit the leading space on completely +# blank context lines so we need to count that too. + } elsif ($line =~ /^( |\+|$)/) { + $realline++; + $realcnt-- if ($realcnt != 0); + + # Measure the line length and indent. + ($length, $indent) = line_stats($rawline); + + # Track the previous line. + ($prevline, $stashline) = ($stashline, $line); + ($previndent, $stashindent) = ($stashindent, $indent); + ($prevrawline, $stashrawline) = ($stashrawline, $rawline); + + #warn "line<$line>\n"; + + } elsif ($realcnt == 1) { + $realcnt--; + } + + my $hunk_line = ($realcnt != 0); + +#make up the handle for any error we report on this line + $prefix = "$filename:$realline: " if ($emacs && $file); + $prefix = "$filename:$linenr: " if ($emacs && !$file); + + $here = "#$linenr: " if (!$file); + $here = "#$realline: " if ($file); + + # extract the filename as it passes + if ($line =~ /^diff --git.*?(\S+)$/) { + $realfile = $1; + $realfile =~ s@^([^/]*)/@@; + + } elsif ($line =~ /^\+\+\+\s+(\S+)/) { + $realfile = $1; + $realfile =~ s@^([^/]*)/@@; + + $p1_prefix = $1; + if (!$file && $tree && $p1_prefix ne '' && + -e "$root/$p1_prefix") { + WARN("patch prefix '$p1_prefix' exists, appears to be a -p0 patch\n"); + } + + if ($realfile =~ m@^include/asm/@) { + ERROR("do not modify files in include/asm, change architecture specific files in include/asm-\n" . "$here$rawline\n"); + } + next; + } + + $here .= "FILE: $realfile:$realline:" if ($realcnt != 0); + + my $hereline = "$here\n$rawline\n"; + my $herecurr = "$here\n$rawline\n"; + my $hereprev = "$here\n$prevrawline\n$rawline\n"; + + $cnt_lines++ if ($realcnt != 0); + +# Check for incorrect file permissions + if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) { + my $permhere = $here . "FILE: $realfile\n"; + if ($realfile =~ /(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) { + ERROR("do not set execute permissions for source files\n" . $permhere); + } + } + +#check the patch for a signoff: + if ($line =~ /^\s*signed-off-by:/i) { + # This is a signoff, if ugly, so do not double report. + $signoff++; + if (!($line =~ /^\s*Signed-off-by:/)) { + WARN("Signed-off-by: is the preferred form\n" . + $herecurr); + } + if ($line =~ /^\s*signed-off-by:\S/i) { + WARN("space required after Signed-off-by:\n" . + $herecurr); + } + } + +# Check for wrappage within a valid hunk of the file + if ($realcnt != 0 && $line !~ m{^(?:\+|-| |\\ No newline|$)}) { + ERROR("patch seems to be corrupt (line wrapped?)\n" . + $herecurr) if (!$emitted_corrupt++); + } + +# Check for absolute kernel paths. + if ($tree) { + while ($line =~ m{(?:^|\s)(/\S*)}g) { + my $file = $1; + + if ($file =~ m{^(.*?)(?::\d+)+:?$} && + check_absolute_file($1, $herecurr)) { + # + } else { + check_absolute_file($file, $herecurr); + } + } + } + +# UTF-8 regex found at http://www.w3.org/International/questions/qa-forms-utf-8.en.php + if (($realfile =~ /^$/ || $line =~ /^\+/) && + $rawline !~ m/^$UTF8*$/) { + my ($utf8_prefix) = ($rawline =~ /^($UTF8*)/); + + my $blank = copy_spacing($rawline); + my $ptr = substr($blank, 0, length($utf8_prefix)) . "^"; + my $hereptr = "$hereline$ptr\n"; + + ERROR("Invalid UTF-8, patch and commit message should be encoded in UTF-8\n" . $hereptr); + } + +# ignore non-hunk lines and lines being removed + next if (!$hunk_line || $line =~ /^-/); + +#trailing whitespace + if ($line =~ /^\+.*\015/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("DOS line endings\n" . $herevet); + + } elsif ($rawline =~ /^\+.*\S\s+$/ || $rawline =~ /^\+\s+$/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("trailing whitespace\n" . $herevet); + $rpt_cleaners = 1; + } + +# check for Kconfig help text having a real description +# Only applies when adding the entry originally, after that we do not have +# sufficient context to determine whether it is indeed long enough. + if ($realfile =~ /Kconfig/ && + $line =~ /\+\s*(?:---)?help(?:---)?$/) { + my $length = 0; + my $cnt = $realcnt; + my $ln = $linenr + 1; + my $f; + my $is_end = 0; + while ($cnt > 0 && defined $lines[$ln - 1]) { + $f = $lines[$ln - 1]; + $cnt-- if ($lines[$ln - 1] !~ /^-/); + $is_end = $lines[$ln - 1] =~ /^\+/; + $ln++; + + next if ($f =~ /^-/); + $f =~ s/^.//; + $f =~ s/#.*//; + $f =~ s/^\s+//; + next if ($f =~ /^$/); + if ($f =~ /^\s*config\s/) { + $is_end = 1; + last; + } + $length++; + } + WARN("please write a paragraph that describes the config symbol fully\n" . $herecurr) if ($is_end && $length < 4); + #print "is_end<$is_end> length<$length>\n"; + } + +# check we are in a valid source file if not then ignore this hunk +# only chek files in tools/libxl/ + next if ($realfile !~ /^tools\/libxl\/.*\.(h|c|s|S|pl|sh)$/); + +#80 column limit + if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ && + $rawline !~ /^.\s*\*\s*\@$Ident\s/ && + !($line =~ /^\+\s*$logFunctions\s*\(\s*(?:(KERN_\S+\s*|[^"]*))?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ || + $line =~ /^\+\s*"[^"]*"\s*(?:\s*|,|\)\s*;)\s*$/) && + $length > 80) + { + WARN("line over 80 characters\n" . $herecurr); + } + +# check for spaces before a quoted newline + if ($rawline =~ /^.*\".*\s\\n/) { + WARN("unnecessary whitespace before a quoted newline\n" . $herecurr); + } + +# check for adding lines without a newline. + if ($line =~ /^\+/ && defined $lines[$linenr] && $lines[$linenr] =~ /^\\ No newline at end of file/) { + WARN("adding a line without newline at end of file\n" . $herecurr); + } + + +# check we are in a valid source file C or perl if not then ignore this hunk + next if ($realfile !~ /\.(h|c|pl)$/); + +# in QEMU, no tabs are allowed + if ($rawline =~ /^\+.*\t/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("code indent should never use tabs\n" . $herevet); + $rpt_cleaners = 1; + } + +# check we are in a valid C source file if not then ignore this hunk + next if ($realfile !~ /\.(h|c)$/); + +# check for RCS/CVS revision markers + if ($rawline =~ /^\+.*\$(Revision|Log|Id)(?:\$|)/) { + WARN("CVS style keyword markers, these will _not_ be updated\n". $herecurr); + } + +# Check for libxl__sprintf + if ($line =~ /^\+.*libxl__sprintf/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the GCSPRINTF macro instead of libxl__sprintf\n" . $herevet); + } +# Check for old log functions + if ($line =~ /^\+.*LIBXL__LOG_/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the new set of logging functions, LOG, LOGE and LOGEV\n" . $herevet); + } +# Check for definitions of ctx + if ($line =~ /^\+.*libxl_ctx *ctx =/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the CTX macro directly instead of a variable\n" . $herevet); + } +# Check for use of libxl__gc_owner + if ($line =~ /^\+.*libxl__gc_owner/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the CTX macro\n" . $herevet); + } + +# Check for potential 'bare' types + my ($stat, $cond, $line_nr_next, $remain_next, $off_next, + $realline_next); + if ($realcnt && $line =~ /.\s*\S/) { + ($stat, $cond, $line_nr_next, $remain_next, $off_next) = + ctx_statement_block($linenr, $realcnt, 0); + $stat =~ s/\n./\n /g; + $cond =~ s/\n./\n /g; + + # Find the real next line. + $realline_next = $line_nr_next; + if (defined $realline_next && + (!defined $lines[$realline_next - 1] || + substr($lines[$realline_next - 1], $off_next) =~ /^\s*$/)) { + $realline_next++; + } + + my $s = $stat; + $s =~ s/{.*$//s; + + # Ignore goto labels. + if ($s =~ /$Ident:\*$/s) { + + # Ignore functions being called + } elsif ($s =~ /^.\s*$Ident\s*\(/s) { + + } elsif ($s =~ /^.\s*else\b/s) { + + # declarations always start with types + } elsif ($prev_values eq 'E' && $s =~ /^.\s*(?:$Storage\s+)?(?:$Inline\s+)?(?:const\s+)?((?:\s*$Ident)+?)\b(?:\s+$Sparse)?\s*\**\s*(?:$Ident|\(\*[^\)]*\))(?:\s*$Modifier)?\s*(?:;|=|,|\()/s) { + my $type = $1; + $type =~ s/\s+/ /g; + possible($type, "A:" . $s); + + # definitions in global scope can only start with types + } elsif ($s =~ /^.(?:$Storage\s+)?(?:$Inline\s+)?(?:const\s+)?($Ident)\b\s*(?!:)/s) { + possible($1, "B:" . $s); + } + + # any (foo ... *) is a pointer cast, and foo is a type + while ($s =~ /\(($Ident)(?:\s+$Sparse)*[\s\*]+\s*\)/sg) { + possible($1, "C:" . $s); + } + + # Check for any sort of function declaration. + # int foo(something bar, other baz); + # void (*store_gdt)(x86_descr_ptr *); + if ($prev_values eq 'E' && $s =~ /^(.(?:typedef\s*)?(?:(?:$Storage|$Inline)\s*)*\s*$Type\s*(?:\b$Ident|\(\*\s*$Ident\))\s*)\(/s) { + my ($name_len) = length($1); + + my $ctx = $s; + substr($ctx, 0, $name_len + 1, ''); + $ctx =~ s/\)[^\)]*$//; + + for my $arg (split(/\s*,\s*/, $ctx)) { + if ($arg =~ /^(?:const\s+)?($Ident)(?:\s+$Sparse)*\s*\**\s*(:?\b$Ident)?$/s || $arg =~ /^($Ident)$/s) { + + possible($1, "D:" . $s); + } + } + } + + } + +# +# Checks which may be anchored in the context. +# + +# Check for switch () and associated case and default +# statements should be at the same indent. + if ($line=~/\bswitch\s*\(.*\)/) { + my $err = ''; + my $sep = ''; + my @ctx = ctx_block_outer($linenr, $realcnt); + shift(@ctx); + for my $ctx (@ctx) { + my ($clen, $cindent) = line_stats($ctx); + if ($ctx =~ /^\+\s*(case\s+|default:)/ && + $indent != $cindent) { + $err .= "$sep$ctx\n"; + $sep = ''; + } else { + $sep = "[...]\n"; + } + } + if ($err ne '') { + ERROR("switch and case should be at the same indent\n$hereline$err"); + } + } + +# if/while/etc brace do not go on next line, unless defining a do while loop, +# or if that brace on the next line is for something else + if ($line =~ /(.*)\b((?:if|while|for|switch)\s*\(|do\b|else\b)/ && $line !~ /^.\s*\#/) { + my $pre_ctx = "$1$2"; + + my ($level, @ctx) = ctx_statement_level($linenr, $realcnt, 0); + my $ctx_cnt = $realcnt - $#ctx - 1; + my $ctx = join("\n", @ctx); + + my $ctx_ln = $linenr; + my $ctx_skip = $realcnt; + + while ($ctx_skip > $ctx_cnt || ($ctx_skip == $ctx_cnt && + defined $lines[$ctx_ln - 1] && + $lines[$ctx_ln - 1] =~ /^-/)) { + ##print "SKIP<$ctx_skip> CNT<$ctx_cnt>\n"; + $ctx_skip-- if (!defined $lines[$ctx_ln - 1] || $lines[$ctx_ln - 1] !~ /^-/); + $ctx_ln++; + } + + #print "realcnt<$realcnt> ctx_cnt<$ctx_cnt>\n"; + #print "pre<$pre_ctx>\nline<$line>\nctx<$ctx>\nnext<$lines[$ctx_ln - 1]>\n"; + + if ($ctx !~ /{\s*/ && defined($lines[$ctx_ln -1]) && $lines[$ctx_ln - 1] =~ /^\+\s*{/) { + ERROR("that open brace { should be on the previous line\n" . + "$here\n$ctx\n$rawlines[$ctx_ln - 1]\n"); + } + if ($level == 0 && $pre_ctx !~ /}\s*while\s*\($/ && + $ctx =~ /\)\s*\;\s*$/ && + defined $lines[$ctx_ln - 1]) + { + my ($nlength, $nindent) = line_stats($lines[$ctx_ln - 1]); + if ($nindent > $indent) { + WARN("trailing semicolon indicates no statements, indent implies otherwise\n" . + "$here\n$ctx\n$rawlines[$ctx_ln - 1]\n"); + } + } + } + +# Check relative indent for conditionals and blocks. + if ($line =~ /\b(?:(?:if|while|for)\s*\(|do\b)/ && $line !~ /^.\s*#/ && $line !~ /\}\s*while\s*/) { + my ($s, $c) = ($stat, $cond); + + substr($s, 0, length($c), ''); + + # Make sure we remove the line prefixes as we have + # none on the first line, and are going to readd them + # where necessary. + $s =~ s/\n./\n/gs; + + # Find out how long the conditional actually is. + my @newlines = ($c =~ /\n/gs); + my $cond_lines = 1 + $#newlines; + + # We want to check the first line inside the block + # starting at the end of the conditional, so remove: + # 1) any blank line termination + # 2) any opening brace { on end of the line + # 3) any do (...) { + my $continuation = 0; + my $check = 0; + $s =~ s/^.*\bdo\b//; + $s =~ s/^\s*{//; + if ($s =~ s/^\s*\\//) { + $continuation = 1; + } + if ($s =~ s/^\s*?\n//) { + $check = 1; + $cond_lines++; + } + + # Also ignore a loop construct at the end of a + # preprocessor statement. + if (($prevline =~ /^.\s*#\s*define\s/ || + $prevline =~ /\\\s*$/) && $continuation == 0) { + $check = 0; + } + + my $cond_ptr = -1; + $continuation = 0; + while ($cond_ptr != $cond_lines) { + $cond_ptr = $cond_lines; + + # If we see an #else/#elif then the code + # is not linear. + if ($s =~ /^\s*\#\s*(?:else|elif)/) { + $check = 0; + } + + # Ignore: + # 1) blank lines, they should be at 0, + # 2) preprocessor lines, and + # 3) labels. + if ($continuation || + $s =~ /^\s*?\n/ || + $s =~ /^\s*#\s*?/ || + $s =~ /^\s*$Ident\s*:/) { + $continuation = ($s =~ /^.*?\\\n/) ? 1 : 0; + if ($s =~ s/^.*?\n//) { + $cond_lines++; + } + } + } + + my (undef, $sindent) = line_stats("+" . $s); + my $stat_real = raw_line($linenr, $cond_lines); + + # Check if either of these lines are modified, else + # this is not this patch's fault. + if (!defined($stat_real) || + $stat !~ /^\+/ && $stat_real !~ /^\+/) { + $check = 0; + } + if (defined($stat_real) && $cond_lines > 1) { + $stat_real = "[...]\n$stat_real"; + } + + #print "line<$line> prevline<$prevline> indent<$indent> sindent<$sindent> check<$check> continuation<$continuation> s<$s> cond_lines<$cond_lines> stat_real<$stat_real> stat<$stat>\n"; + + if ($check && (($sindent % 4) != 0 || + ($sindent <= $indent && $s ne ''))) { + WARN("suspect code indent for conditional statements ($indent, $sindent)\n" . $herecurr . "$stat_real\n"); + } + } + + # Track the 'values' across context and added lines. + my $opline = $line; $opline =~ s/^./ /; + my ($curr_values, $curr_vars) = + annotate_values($opline . "\n", $prev_values); + $curr_values = $prev_values . $curr_values; + if ($dbg_values) { + my $outline = $opline; $outline =~ s/\t/ /g; + print "$linenr > .$outline\n"; + print "$linenr > $curr_values\n"; + print "$linenr > $curr_vars\n"; + } + $prev_values = substr($curr_values, -1); + +#ignore lines not being added + if ($line=~/^[^\+]/) {next;} + +# TEST: allow direct testing of the type matcher. + if ($dbg_type) { + if ($line =~ /^.\s*$Declare\s*$/) { + ERROR("TEST: is type\n" . $herecurr); + } elsif ($dbg_type > 1 && $line =~ /^.+($Declare)/) { + ERROR("TEST: is not type ($1 is)\n". $herecurr); + } + next; + } +# TEST: allow direct testing of the attribute matcher. + if ($dbg_attr) { + if ($line =~ /^.\s*$Modifier\s*$/) { + ERROR("TEST: is attr\n" . $herecurr); + } elsif ($dbg_attr > 1 && $line =~ /^.+($Modifier)/) { + ERROR("TEST: is not attr ($1 is)\n". $herecurr); + } + next; + } + +# check for initialisation to aggregates open brace on the next line + if ($line =~ /^.\s*{/ && + $prevline =~ /(?:^|[^=])=\s*$/) { + ERROR("that open brace { should be on the previous line\n" . $hereprev); + } + +# +# Checks which are anchored on the added line. +# + +# check for malformed paths in #include statements (uses RAW line) + if ($rawline =~ m{^.\s*\#\s*include\s+[<"](.*)[">]}) { + my $path = $1; + if ($path =~ m{//}) { + ERROR("malformed #include filename\n" . + $herecurr); + } + } + +# no C99 // comments + if ($line =~ m{//}) { + ERROR("do not use C99 // comments\n" . $herecurr); + } + # Remove C99 comments. + $line =~ s@//.*@@; + $opline =~ s@//.*@@; + +# EXPORT_SYMBOL should immediately follow the thing it is exporting, consider +# the whole statement. +#print "APW <$lines[$realline_next - 1]>\n"; + if (defined $realline_next && + exists $lines[$realline_next - 1] && + !defined $suppress_export{$realline_next} && + ($lines[$realline_next - 1] =~ /EXPORT_SYMBOL.*\((.*)\)/ || + $lines[$realline_next - 1] =~ /EXPORT_UNUSED_SYMBOL.*\((.*)\)/)) { + # Handle definitions which produce identifiers with + # a prefix: + # XXX(foo); + # EXPORT_SYMBOL(something_foo); + my $name = $1; + if ($stat =~ /^.([A-Z_]+)\s*\(\s*($Ident)/ && + $name =~ /^${Ident}_$2/) { +#print "FOO C name<$name>\n"; + $suppress_export{$realline_next} = 1; + + } elsif ($stat !~ /(?: + \n.}\s*$| + ^.DEFINE_$Ident\(\Q$name\E\)| + ^.DECLARE_$Ident\(\Q$name\E\)| + ^.LIST_HEAD\(\Q$name\E\)| + ^.(?:$Storage\s+)?$Type\s*\(\s*\*\s*\Q$name\E\s*\)\s*\(| + \b\Q$name\E(?:\s+$Attribute)*\s*(?:;|=|\[|\() + )/x) { +#print "FOO A<$lines[$realline_next - 1]> stat<$stat> name<$name>\n"; + $suppress_export{$realline_next} = 2; + } else { + $suppress_export{$realline_next} = 1; + } + } + if (!defined $suppress_export{$linenr} && + $prevline =~ /^.\s*$/ && + ($line =~ /EXPORT_SYMBOL.*\((.*)\)/ || + $line =~ /EXPORT_UNUSED_SYMBOL.*\((.*)\)/)) { +#print "FOO B <$lines[$linenr - 1]>\n"; + $suppress_export{$linenr} = 2; + } + if (defined $suppress_export{$linenr} && + $suppress_export{$linenr} == 2) { + WARN("EXPORT_SYMBOL(foo); should immediately follow its function/variable\n" . $herecurr); + } + +# check for global initialisers. + if ($line =~ /^.$Type\s*$Ident\s*(?:\s+$Modifier)*\s*=\s*(0|NULL|false)\s*;/) { + ERROR("do not initialise globals to 0 or NULL\n" . + $herecurr); + } +# check for static initialisers. + if ($line =~ /\bstatic\s.*=\s*(0|NULL|false)\s*;/) { + ERROR("do not initialise statics to 0 or NULL\n" . + $herecurr); + } + +# * goes on variable not on type + # (char*[ const]) + if ($line =~ m{\($NonptrType(\s*(?:$Modifier\b\s*|\*\s*)+)\)}) { + my ($from, $to) = ($1, $1); + + # Should start with a space. + $to =~ s/^(\S)/ $1/; + # Should not end with a space. + $to =~ s/\s+$//; + # '*'s should not have spaces between. + while ($to =~ s/\*\s+\*/\*\*/) { + } + + #print "from<$from> to<$to>\n"; + if ($from ne $to) { + ERROR("\"(foo$from)\" should be \"(foo$to)\"\n" . $herecurr); + } + } elsif ($line =~ m{\b$NonptrType(\s*(?:$Modifier\b\s*|\*\s*)+)($Ident)}) { + my ($from, $to, $ident) = ($1, $1, $2); + + # Should start with a space. + $to =~ s/^(\S)/ $1/; + # Should not end with a space. + $to =~ s/\s+$//; + # '*'s should not have spaces between. + while ($to =~ s/\*\s+\*/\*\*/) { + } + # Modifiers should have spaces. + $to =~ s/(\b$Modifier$)/$1 /; + + #print "from<$from> to<$to> ident<$ident>\n"; + if ($from ne $to && $ident !~ /^$Modifier$/) { + ERROR("\"foo${from}bar\" should be \"foo${to}bar\"\n" . $herecurr); + } + } + +# # no BUG() or BUG_ON() +# if ($line =~ /\b(BUG|BUG_ON)\b/) { +# print "Try to use WARN_ON & Recovery code rather than BUG() or BUG_ON()\n"; +# print "$herecurr"; +# $clean = 0; +# } + + if ($line =~ /\bLINUX_VERSION_CODE\b/) { + WARN("LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged\n" . $herecurr); + } + +# printk should use KERN_* levels. Note that follow on printk's on the +# same line do not need a level, so we use the current block context +# to try and find and validate the current printk. In summary the current +# printk includes all preceding printk's which have no newline on the end. +# we assume the first bad printk is the one to report. + if ($line =~ /\bprintk\((?!KERN_)\s*"/) { + my $ok = 0; + for (my $ln = $linenr - 1; $ln >= $first_line; $ln--) { + #print "CHECK<$lines[$ln - 1]\n"; + # we have a preceding printk if it ends + # with "\n" ignore it, else it is to blame + if ($lines[$ln - 1] =~ m{\bprintk\(}) { + if ($rawlines[$ln - 1] !~ m{\\n"}) { + $ok = 1; + } + last; + } + } + if ($ok == 0) { + WARN("printk() should include KERN_ facility level\n" . $herecurr); + } + } + +# function brace can't be on same line, except for #defines of do while, +# or if closed on same line + if (($line=~/$Type\s*$Ident\(.*\).*\s{/) and + !($line=~/\#\s*define.*do\s{/) and !($line=~/}/)) { + ERROR("open brace '{' following function declarations go on the next line\n" . $herecurr); + } + +# open braces for enum, union and struct go on the same line. + if ($line =~ /^.\s*{/ && + $prevline =~ /^.\s*(?:typedef\s+)?(enum|union|struct)(?:\s+$Ident)?\s*$/) { + ERROR("open brace '{' following $1 go on the same line\n" . $hereprev); + } + +# missing space after union, struct or enum definition + if ($line =~ /^.\s*(?:typedef\s+)?(enum|union|struct)(?:\s+$Ident)?(?:\s+$Ident)?[=\{]/) { + WARN("missing space after $1 definition\n" . $herecurr); + } + +# check for spacing round square brackets; allowed: +# 1. with a type on the left -- int [] a; +# 2. at the beginning of a line for slice initialisers -- [0...10] = 5, +# 3. inside a curly brace -- = { [0...10] = 5 } + while ($line =~ /(.*?\s)\[/g) { + my ($where, $prefix) = ($-[1], $1); + if ($prefix !~ /$Type\s+$/ && + ($where != 0 || $prefix !~ /^.\s+$/) && + $prefix !~ /{\s+$/) { + ERROR("space prohibited before open square bracket '['\n" . $herecurr); + } + } + +# check for spaces between functions and their parentheses. + while ($line =~ /($Ident)\s+\(/g) { + my $name = $1; + my $ctx_before = substr($line, 0, $-[1]); + my $ctx = "$ctx_before$name"; + + # Ignore those directives where spaces _are_ permitted. + if ($name =~ /^(?: + if|for|while|switch|return|case| + volatile|__volatile__| + __attribute__|format|__extension__| + asm|__asm__)$/x) + { + + # cpp #define statements have non-optional spaces, ie + # if there is a space between the name and the open + # parenthesis it is simply not a parameter group. + } elsif ($ctx_before =~ /^.\s*\#\s*define\s*$/) { + + # cpp #elif statement condition may start with a ( + } elsif ($ctx =~ /^.\s*\#\s*elif\s*$/) { + + # If this whole things ends with a type its most + # likely a typedef for a function. + } elsif ($ctx =~ /$Type$/) { + + } else { + WARN("space prohibited between function name and open parenthesis '('\n" . $herecurr); + } + } +# Check operator spacing. + if (!($line=~/\#\s*include/)) { + my $ops = qr{ + <<=|>>=|<=|>=|==|!=| + \+=|-=|\*=|\/=|%=|\^=|\|=|&=| + =>|->|<<|>>|<|>|=|!|~| + &&|\|\||,|\^|\+\+|--|&|\||\+|-|\*|\/|%| + \?|: + }x; + my @elements = split(/($ops|;)/, $opline); + my $off = 0; + + my $blank = copy_spacing($opline); + + for (my $n = 0; $n < $#elements; $n += 2) { + $off += length($elements[$n]); + + # Pick up the preceding and succeeding characters. + my $ca = substr($opline, 0, $off); + my $cc = ''; + if (length($opline) >= ($off + length($elements[$n + 1]))) { + $cc = substr($opline, $off + length($elements[$n + 1])); + } + my $cb = "$ca$;$cc"; + + my $a = ''; + $a = 'V' if ($elements[$n] ne ''); + $a = 'W' if ($elements[$n] =~ /\s$/); + $a = 'C' if ($elements[$n] =~ /$;$/); + $a = 'B' if ($elements[$n] =~ /(\[|\()$/); + $a = 'O' if ($elements[$n] eq ''); + $a = 'E' if ($ca =~ /^\s*$/); + + my $op = $elements[$n + 1]; + + my $c = ''; + if (defined $elements[$n + 2]) { + $c = 'V' if ($elements[$n + 2] ne ''); + $c = 'W' if ($elements[$n + 2] =~ /^\s/); + $c = 'C' if ($elements[$n + 2] =~ /^$;/); + $c = 'B' if ($elements[$n + 2] =~ /^(\)|\]|;)/); + $c = 'O' if ($elements[$n + 2] eq ''); + $c = 'E' if ($elements[$n + 2] =~ /^\s*\\$/); + } else { + $c = 'E'; + } + + my $ctx = "${a}x${c}"; + + my $at = "(ctx:$ctx)"; + + my $ptr = substr($blank, 0, $off) . "^"; + my $hereptr = "$hereline$ptr\n"; + + # Pull out the value of this operator. + my $op_type = substr($curr_values, $off + 1, 1); + + # Get the full operator variant. + my $opv = $op . substr($curr_vars, $off, 1); + + # Ignore operators passed as parameters. + if ($op_type ne 'V' && + $ca =~ /\s$/ && $cc =~ /^\s*,/) { + +# # Ignore comments +# } elsif ($op =~ /^$;+$/) { + + # ; should have either the end of line or a space or \ after it + } elsif ($op eq ';') { + if ($ctx !~ /.x[WEBC]/ && + $cc !~ /^\\/ && $cc !~ /^;/) { + ERROR("space required after that '$op' $at\n" . $hereptr); + } + + # // is a comment + } elsif ($op eq '//') { + + # No spaces for: + # -> + # : when part of a bitfield + } elsif ($op eq '->' || $opv eq ':B') { + if ($ctx =~ /Wx.|.xW/) { + ERROR("spaces prohibited around that '$op' $at\n" . $hereptr); + } + + # , must have a space on the right. + # not required when having a single },{ on one line + } elsif ($op eq ',') { + if ($ctx !~ /.x[WEC]/ && $cc !~ /^}/ && + ($elements[$n] . $elements[$n + 2]) !~ " *}{") { + ERROR("space required after that '$op' $at\n" . $hereptr); + } + + # '*' as part of a type definition -- reported already. + } elsif ($opv eq '*_') { + #warn "'*' is part of type\n"; + + # unary operators should have a space before and + # none after. May be left adjacent to another + # unary operator, or a cast + } elsif ($op eq '!' || $op eq '~' || + $opv eq '*U' || $opv eq '-U' || + $opv eq '&U' || $opv eq '&&U') { + if ($ctx !~ /[WEBC]x./ && $ca !~ /(?:\)|!|~|\*|-|\&|\||\+\+|\-\-|\{)$/) { + ERROR("space required before that '$op' $at\n" . $hereptr); + } + if ($op eq '*' && $cc =~/\s*$Modifier\b/) { + # A unary '*' may be const + + } elsif ($ctx =~ /.xW/) { + ERROR("space prohibited after that '$op' $at\n" . $hereptr); + } + + # unary ++ and unary -- are allowed no space on one side. + } elsif ($op eq '++' or $op eq '--') { + if ($ctx !~ /[WEOBC]x[^W]/ && $ctx !~ /[^W]x[WOBEC]/) { + ERROR("space required one side of that '$op' $at\n" . $hereptr); + } + if ($ctx =~ /Wx[BE]/ || + ($ctx =~ /Wx./ && $cc =~ /^;/)) { + ERROR("space prohibited before that '$op' $at\n" . $hereptr); + } + if ($ctx =~ /ExW/) { + ERROR("space prohibited after that '$op' $at\n" . $hereptr); + } + + + # << and >> may either have or not have spaces both sides + } elsif ($op eq '<<' or $op eq '>>' or + $op eq '&' or $op eq '^' or $op eq '|' or + $op eq '+' or $op eq '-' or + $op eq '/' or $op eq '%') + { + if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) { + ERROR("need consistent spacing around '$op' $at\n" . + $hereptr); + } + + # A colon needs no spaces before when it is + # terminating a case value or a label. + } elsif ($opv eq ':C' || $opv eq ':L') { + if ($ctx =~ /Wx./) { + ERROR("space prohibited before that '$op' $at\n" . $hereptr); + } + + # All the others need spaces both sides. + } elsif ($ctx !~ /[EWC]x[CWE]/ && $opv ne '*B') { + my $ok = 0; + + # Ignore email addresses + if (($op eq '<' && + $cc =~ /^\S+\@\S+>/) || + ($op eq '>' && + $ca =~ /<\S+\@\S+$/)) + { + $ok = 1; + } + + # Ignore ?: + if (($opv eq ':O' && $ca =~ /\?$/) || + ($op eq '?' && $cc =~ /^:/)) { + $ok = 1; + } + + if ($ok == 0) { + ERROR("spaces required around that '$op' $at\n" . $hereptr); + } + } + $off += length($elements[$n + 1]); + } + } + +# check for multiple assignments + if ($line =~ /^.\s*$Lval\s*=\s*$Lval\s*=(?!=)/) { + CHK("multiple assignments should be avoided\n" . $herecurr); + } + +## # check for multiple declarations, allowing for a function declaration +## # continuation. +## if ($line =~ /^.\s*$Type\s+$Ident(?:\s*=[^,{]*)?\s*,\s*$Ident.*/ && +## $line !~ /^.\s*$Type\s+$Ident(?:\s*=[^,{]*)?\s*,\s*$Type\s*$Ident.*/) { +## +## # Remove any bracketed sections to ensure we do not +## # falsly report the parameters of functions. +## my $ln = $line; +## while ($ln =~ s/\([^\(\)]*\)//g) { +## } +## if ($ln =~ /,/) { +## WARN("declaring multiple variables together should be avoided\n" . $herecurr); +## } +## } + +#need space before brace following if, while, etc + if (($line =~ /\(.*\){/ && $line !~ /\($Type\){/) || + $line =~ /do{/) { + ERROR("space required before the open brace '{'\n" . $herecurr); + } + +# closing brace should have a space following it when it has anything +# on the line + if ($line =~ /}(?!(?:,|;|\)))\S/) { + ERROR("space required after that close brace '}'\n" . $herecurr); + } + +# check spacing on square brackets + if ($line =~ /\[\s/ && $line !~ /\[\s*$/) { + ERROR("space prohibited after that open square bracket '['\n" . $herecurr); + } + if ($line =~ /\s\]/) { + ERROR("space prohibited before that close square bracket ']'\n" . $herecurr); + } + +# check spacing on parentheses + if ($line =~ /\(\s/ && $line !~ /\(\s*(?:\\)?$/ && + $line !~ /for\s*\(\s+;/) { + ERROR("space prohibited after that open parenthesis '('\n" . $herecurr); + } + if ($line =~ /(\s+)\)/ && $line !~ /^.\s*\)/ && + $line !~ /for\s*\(.*;\s+\)/ && + $line !~ /:\s+\)/) { + ERROR("space prohibited before that close parenthesis ')'\n" . $herecurr); + } + +# Return is not a function. + if (defined($stat) && $stat =~ /^.\s*return(\s*)(\(.*);/s) { + my $spacing = $1; + my $value = $2; + + # Flatten any parentheses + $value =~ s/\(/ \(/g; + $value =~ s/\)/\) /g; + while ($value =~ s/\[[^\{\}]*\]/1/ || + $value !~ /(?:$Ident|-?$Constant)\s* + $Compare\s* + (?:$Ident|-?$Constant)/x && + $value =~ s/\([^\(\)]*\)/1/) { + } +#print "value<$value>\n"; + if ($value =~ /^\s*(?:$Ident|-?$Constant)\s*$/) { + ERROR("return is not a function, parentheses are not required\n" . $herecurr); + + } elsif ($spacing !~ /\s+/) { + ERROR("space required before the open parenthesis '('\n" . $herecurr); + } + } +# Return of what appears to be an errno should normally be -'ve + if ($line =~ /^.\s*return\s*(E[A-Z]*)\s*;/) { + my $name = $1; + if ($name ne 'EOF' && $name ne 'ERROR') { + CHK("return of an errno should typically be -ve (return -$1)\n" . $herecurr); + } + } + +# Need a space before open parenthesis after if, while etc + if ($line=~/\b(if|while|for|switch)\(/) { + ERROR("space required before the open parenthesis '('\n" . $herecurr); + } + +# Check for illegal assignment in if conditional -- and check for trailing +# statements after the conditional. + if ($line =~ /do\s*(?!{)/) { + my ($stat_next) = ctx_statement_block($line_nr_next, + $remain_next, $off_next); + $stat_next =~ s/\n./\n /g; + ##print "stat<$stat> stat_next<$stat_next>\n"; + + if ($stat_next =~ /^\s*while\b/) { + # If the statement carries leading newlines, + # then count those as offsets. + my ($whitespace) = + ($stat_next =~ /^((?:\s*\n[+-])*\s*)/s); + my $offset = + statement_rawlines($whitespace) - 1; + + $suppress_whiletrailers{$line_nr_next + + $offset} = 1; + } + } + if (!defined $suppress_whiletrailers{$linenr} && + $line =~ /\b(?:if|while|for)\s*\(/ && $line !~ /^.\s*#/) { + my ($s, $c) = ($stat, $cond); + + if ($c =~ /\bif\s*\(.*[^<>!=]=[^=].*/s) { + ERROR("do not use assignment in if condition\n" . $herecurr); + } + + # Find out what is on the end of the line after the + # conditional. + substr($s, 0, length($c), ''); + $s =~ s/\n.*//g; + $s =~ s/$;//g; # Remove any comments + if (length($c) && $s !~ /^\s*{?\s*\\*\s*$/ && + $c !~ /}\s*while\s*/ && length($s) == 1) + { + # Find out how long the conditional actually is. + my @newlines = ($c =~ /\n/gs); + my $cond_lines = 1 + $#newlines; + my $stat_real = ''; + + $stat_real = raw_line($linenr, $cond_lines) + . "\n" if ($cond_lines); + if (defined($stat_real) && $cond_lines > 1) { + $stat_real = "[...]\n$stat_real"; + } + + ERROR("trailing statements should be on next line\n" . $herecurr . $stat_real); + } + } + +# Check for bitwise tests written as boolean + if ($line =~ / + (?: + (?:\[|\(|\&\&|\|\|) + \s*0[xX][0-9]+\s* + (?:\&\&|\|\|) + | + (?:\&\&|\|\|) + \s*0[xX][0-9]+\s* + (?:\&\&|\|\||\)|\]) + )/x) + { + WARN("boolean test with hexadecimal, perhaps just 1 \& or \|?\n" . $herecurr); + } + +# if and else should not have general statements after it + if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/) { + my $s = $1; + $s =~ s/$;//g; # Remove any comments + if ($s !~ /^\s*(?:\sif|(?:{|)\s*\\?\s*$)/) { + ERROR("trailing statements should be on next line\n" . $herecurr); + } + } +# if should not continue a brace + if ($line =~ /}\s*if\b/) { + ERROR("trailing statements should be on next line\n" . + $herecurr); + } +# case and default should not have general statements after them + if ($line =~ /^.\s*(?:case\s*.*|default\s*):/g && + $line !~ /\G(?: + (?:\s*$;*)(?:\s*{)?(?:\s*$;*)(?:\s*\\)?\s*$| + \s*return\s+ + )/xg) + { + ERROR("trailing statements should be on next line\n" . $herecurr); + } + + # Check for }else {, these must be at the same + # indent level to be relevant to each other. + if ($prevline=~/}\s*$/ and $line=~/^.\s*else\s*/ and + $previndent == $indent) { + ERROR("else should follow close brace '}'\n" . $hereprev); + } + + if ($prevline=~/}\s*$/ and $line=~/^.\s*while\s*/ and + $previndent == $indent) { + my ($s, $c) = ctx_statement_block($linenr, $realcnt, 0); + + # Find out what is on the end of the line after the + # conditional. + substr($s, 0, length($c), ''); + $s =~ s/\n.*//g; + + if ($s =~ /^\s*;/) { + ERROR("while should follow close brace '}'\n" . $hereprev); + } + } + +#studly caps, commented out until figure out how to distinguish between use of existing and adding new +# if (($line=~/[\w_][a-z\d]+[A-Z]/) and !($line=~/print/)) { +# print "No studly caps, use _\n"; +# print "$herecurr"; +# $clean = 0; +# } + +#no spaces allowed after \ in define + if ($line=~/\#\s*define.*\\\s$/) { + WARN("Whitepspace after \\ makes next lines useless\n" . $herecurr); + } + +#warn if is #included and is available (uses RAW line) + if ($tree && $rawline =~ m{^.\s*\#\s*include\s*\}) { + my $file = "$1.h"; + my $checkfile = "include/linux/$file"; + if (-f "$root/$checkfile" && + $realfile ne $checkfile && + $1 !~ /$allowed_asm_includes/) + { + if ($realfile =~ m{^arch/}) { + CHK("Consider using #include instead of \n" . $herecurr); + } else { + WARN("Use #include instead of \n" . $herecurr); + } + } + } + +# multi-statement macros should be enclosed in a do while loop, grab the +# first statement and ensure its the whole macro if its not enclosed +# in a known good container + if ($realfile !~ m@/vmlinux.lds.h$@ && + $line =~ /^.\s*\#\s*define\s*$Ident(\()?/) { + my $ln = $linenr; + my $cnt = $realcnt; + my ($off, $dstat, $dcond, $rest); + my $ctx = ''; + + my $args = defined($1); + + # Find the end of the macro and limit our statement + # search to that. + while ($cnt > 0 && defined $lines[$ln - 1] && + $lines[$ln - 1] =~ /^(?:-|..*\\$)/) + { + $ctx .= $rawlines[$ln - 1] . "\n"; + $cnt-- if ($lines[$ln - 1] !~ /^-/); + $ln++; + } + $ctx .= $rawlines[$ln - 1]; + + ($dstat, $dcond, $ln, $cnt, $off) = + ctx_statement_block($linenr, $ln - $linenr + 1, 0); + #print "dstat<$dstat> dcond<$dcond> cnt<$cnt> off<$off>\n"; + #print "LINE<$lines[$ln-1]> len<" . length($lines[$ln-1]) . "\n"; + + # Extract the remainder of the define (if any) and + # rip off surrounding spaces, and trailing \'s. + $rest = ''; + while ($off != 0 || ($cnt > 0 && $rest =~ /\\\s*$/)) { + #print "ADDING cnt<$cnt> $off <" . substr($lines[$ln - 1], $off) . "> rest<$rest>\n"; + if ($off != 0 || $lines[$ln - 1] !~ /^-/) { + $rest .= substr($lines[$ln - 1], $off) . "\n"; + $cnt--; + } + $ln++; + $off = 0; + } + $rest =~ s/\\\n.//g; + $rest =~ s/^\s*//s; + $rest =~ s/\s*$//s; + + # Clean up the original statement. + if ($args) { + substr($dstat, 0, length($dcond), ''); + } else { + $dstat =~ s/^.\s*\#\s*define\s+$Ident\s*//; + } + $dstat =~ s/$;//g; + $dstat =~ s/\\\n.//g; + $dstat =~ s/^\s*//s; + $dstat =~ s/\s*$//s; + + # Flatten any parentheses and braces + while ($dstat =~ s/\([^\(\)]*\)/1/ || + $dstat =~ s/\{[^\{\}]*\}/1/ || + $dstat =~ s/\[[^\{\}]*\]/1/) + { + } + + my $exceptions = qr{ + $Declare| + module_param_named| + MODULE_PARAM_DESC| + DECLARE_PER_CPU| + DEFINE_PER_CPU| + __typeof__\(| + union| + struct| + \.$Ident\s*=\s*| + ^\"|\"$ + }x; + #print "REST<$rest> dstat<$dstat> ctx<$ctx>\n"; + if ($rest ne '' && $rest ne ',') { + if ($rest !~ /while\s*\(/ && + $dstat !~ /$exceptions/) + { + ERROR("Macros with multiple statements should be enclosed in a do - while loop\n" . "$here\n$ctx\n"); + } + + } elsif ($ctx !~ /;/) { + if ($dstat ne '' && + $dstat !~ /^(?:$Ident|-?$Constant)$/ && + $dstat !~ /$exceptions/ && + $dstat !~ /^\.$Ident\s*=/ && + $dstat =~ /$Operators/) + { + ERROR("Macros with complex values should be enclosed in parenthesis\n" . "$here\n$ctx\n"); + } + } + } + +# make sure symbols are always wrapped with VMLINUX_SYMBOL() ... +# all assignments may have only one of the following with an assignment: +# . +# ALIGN(...) +# VMLINUX_SYMBOL(...) + if ($realfile eq 'vmlinux.lds.h' && $line =~ /(?:(?:^|\s)$Ident\s*=|=\s*$Ident(?:\s|$))/) { + WARN("vmlinux.lds.h needs VMLINUX_SYMBOL() around C-visible symbols\n" . $herecurr); + } + +# check for missing bracing round if etc + if ($line =~ /(^.*)\bif\b/ && $line !~ /\#\s*if/) { + my ($level, $endln, @chunks) = + ctx_statement_full($linenr, $realcnt, 1); + #print "chunks<$#chunks> linenr<$linenr> endln<$endln> level<$level>\n"; + #print "APW: <<$chunks[1][0]>><<$chunks[1][1]>>\n"; + if ($#chunks >= 0 && $level == 0) { + my $allowed = 0; + my $seen = 0; + my $herectx = $here . "\n"; + my $ln = $linenr - 1; + for my $chunk (@chunks) { + my ($cond, $block) = @{$chunk}; + + # If the condition carries leading newlines, then count those as offsets. + my ($whitespace) = ($cond =~ /^((?:\s*\n[+-])*\s*)/s); + my $offset = statement_rawlines($whitespace) - 1; + + #print "COND<$cond> whitespace<$whitespace> offset<$offset>\n"; + + # We have looked at and allowed this specific line. + $suppress_ifbraces{$ln + $offset} = 1; + + $herectx .= "$rawlines[$ln + $offset]\n[...]\n"; + $ln += statement_rawlines($block) - 1; + + substr($block, 0, length($cond), ''); + $seen++ if ($block =~ /^\s*{/ || $block =~ /;{1,1}/); + + #print "cond<$cond> block<$block> allowed<$allowed>\n"; + if (statement_lines($cond) > 1) { + #print "APW: ALLOWED: cond<$cond>\n"; + $allowed = 1; + } + if ($block =~/\b(?:if|for|while)\b/) { + #print "APW: ALLOWED: block<$block>\n"; + $allowed = 1; + } + if (statement_block_size($block) > 1) { + #print "APW: ALLOWED: lines block<$block>\n"; + $allowed = 1; + } + } + #print "seen: $seen\nchunks: $#chunks\nln: $ln\nlinenr: $linenr\n"; + if ($seen != ($#chunks + 1)) { + WARN("braces {} are necessary for all arms of this statement\n" . $herectx); + } + } + } + if (!defined $suppress_ifbraces{$linenr - 1} && + $line =~ /\b(if|while|for|else)\b/ && + $line !~ /\#\s*if/ && + $line !~ /\#\s*else/) { + my $allowed = 0; + + # Check the pre-context. + if (substr($line, 0, $-[0]) =~ /(\}\s*)$/) { + #print "APW: ALLOWED: pre<$1>\n"; + $allowed = 1; + } + + my ($level, $endln, @chunks) = + ctx_statement_full($linenr, $realcnt, $-[0]); + + # Check the condition. + my ($cond, $block) = @{$chunks[0]}; + #print "CHECKING<$linenr> cond<$cond> block<$block>\n"; + if (defined $cond) { + substr($block, 0, length($cond), ''); + } + if (statement_lines($cond) > 1) { + #print "APW: ALLOWED: cond<$cond>\n"; + $allowed = 1; + } + if ($block =~/\b(?:if|for|while)\b/) { + #print "APW: ALLOWED: block<$block>\n"; + $allowed = 1; + } + if (statement_block_size($block) > 1) { + #print "APW: ALLOWED: lines block<$block>\n"; + $allowed = 1; + } + # Check the post-context. + if (defined $chunks[1]) { + my ($cond, $block) = @{$chunks[1]}; + if (defined $cond) { + substr($block, 0, length($cond), ''); + } + if ($block =~ /^\s*\{/) { + #print "APW: ALLOWED: chunk-1 block<$block>\n"; + $allowed = 1; + } + } + if ($level == 0 && $block !~ /^\s*\{/ && !$allowed) { + my $herectx = $here . "\n";; + my $cnt = statement_rawlines($block); + + for (my $n = 0; $n < $cnt; $n++) { + $herectx .= raw_line($linenr, $n) . "\n";; + } + + WARN("braces {} are necessary even for single statement blocks\n" . $herectx); + } + } + +# don't include deprecated include files (uses RAW line) + for my $inc (@dep_includes) { + if ($rawline =~ m@^.\s*\#\s*include\s*\<$inc>@) { + ERROR("Don't use <$inc>: see Documentation/feature-removal-schedule.txt\n" . $herecurr); + } + } + +# don't use deprecated functions + for my $func (@dep_functions) { + if ($line =~ /\b$func\b/) { + ERROR("Don't use $func(): see Documentation/feature-removal-schedule.txt\n" . $herecurr); + } + } + +# no volatiles please + my $asm_volatile = qr{\b(__asm__|asm)\s+(__volatile__|volatile)\b}; + if ($line =~ /\bvolatile\b/ && $line !~ /$asm_volatile/) { + WARN("Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt\n" . $herecurr); + } + +# SPIN_LOCK_UNLOCKED & RW_LOCK_UNLOCKED are deprecated + if ($line =~ /\b(SPIN_LOCK_UNLOCKED|RW_LOCK_UNLOCKED)/) { + ERROR("Use of $1 is deprecated: see Documentation/spinlocks.txt\n" . $herecurr); + } + +# warn about #if 0 + if ($line =~ /^.\s*\#\s*if\s+0\b/) { + CHK("if this code is redundant consider removing it\n" . + $herecurr); + } + +# check for needless kfree() checks + if ($prevline =~ /\bif\s*\(([^\)]*)\)/) { + my $expr = $1; + if ($line =~ /\bkfree\(\Q$expr\E\);/) { + WARN("kfree(NULL) is safe this check is probably not required\n" . $hereprev); + } + } +# check for needless usb_free_urb() checks + if ($prevline =~ /\bif\s*\(([^\)]*)\)/) { + my $expr = $1; + if ($line =~ /\busb_free_urb\(\Q$expr\E\);/) { + WARN("usb_free_urb(NULL) is safe this check is probably not required\n" . $hereprev); + } + } + +# prefer usleep_range over udelay + if ($line =~ /\budelay\s*\(\s*(\w+)\s*\)/) { + # ignore udelay's < 10, however + if (! (($1 =~ /(\d+)/) && ($1 < 10)) ) { + CHK("usleep_range is preferred over udelay; see Documentation/timers/timers-howto.txt\n" . $line); + } + } + +# warn about unexpectedly long msleep's + if ($line =~ /\bmsleep\s*\((\d+)\);/) { + if ($1 < 20) { + WARN("msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt\n" . $line); + } + } + +# warn about #ifdefs in C files +# if ($line =~ /^.\s*\#\s*if(|n)def/ && ($realfile =~ /\.c$/)) { +# print "#ifdef in C files should be avoided\n"; +# print "$herecurr"; +# $clean = 0; +# } + +# warn about spacing in #ifdefs + if ($line =~ /^.\s*\#\s*(ifdef|ifndef|elif)\s\s+/) { + ERROR("exactly one space required after that #$1\n" . $herecurr); + } + +# check for spinlock_t definitions without a comment. + if ($line =~ /^.\s*(struct\s+mutex|spinlock_t)\s+\S+;/ || + $line =~ /^.\s*(DEFINE_MUTEX)\s*\(/) { + my $which = $1; + if (!ctx_has_comment($first_line, $linenr)) { + CHK("$1 definition without comment\n" . $herecurr); + } + } +# check for memory barriers without a comment. + if ($line =~ /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/) { + if (!ctx_has_comment($first_line, $linenr)) { + CHK("memory barrier without comment\n" . $herecurr); + } + } +# check of hardware specific defines + if ($line =~ m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ m@include/asm-@) { + CHK("architecture specific defines should be avoided\n" . $herecurr); + } + +# Check that the storage class is at the beginning of a declaration + if ($line =~ /\b$Storage\b/ && $line !~ /^.\s*$Storage\b/) { + WARN("storage class should be at the beginning of the declaration\n" . $herecurr) + } + +# check the location of the inline attribute, that it is between +# storage class and type. + if ($line =~ /\b$Type\s+$Inline\b/ || + $line =~ /\b$Inline\s+$Storage\b/) { + ERROR("inline keyword should sit between storage class and type\n" . $herecurr); + } + +# Check for __inline__ and __inline, prefer inline + if ($line =~ /\b(__inline__|__inline)\b/) { + WARN("plain inline is preferred over $1\n" . $herecurr); + } + +# check for sizeof(&) + if ($line =~ /\bsizeof\s*\(\s*\&/) { + WARN("sizeof(& should be avoided\n" . $herecurr); + } + +# check for new externs in .c files. + if ($realfile =~ /\.c$/ && defined $stat && + $stat =~ /^.\s*(?:extern\s+)?$Type\s+($Ident)(\s*)\(/s) + { + my $function_name = $1; + my $paren_space = $2; + + my $s = $stat; + if (defined $cond) { + substr($s, 0, length($cond), ''); + } + if ($s =~ /^\s*;/ && + $function_name ne 'uninitialized_var') + { + WARN("externs should be avoided in .c files\n" . $herecurr); + } + + if ($paren_space =~ /\n/) { + WARN("arguments for function declarations should follow identifier\n" . $herecurr); + } + + } elsif ($realfile =~ /\.c$/ && defined $stat && + $stat =~ /^.\s*extern\s+/) + { + WARN("externs should be avoided in .c files\n" . $herecurr); + } + +# checks for new __setup's + if ($rawline =~ /\b__setup\("([^"]*)"/) { + my $name = $1; + + if (!grep(/$name/, @setup_docs)) { + CHK("__setup appears un-documented -- check Documentation/kernel-parameters.txt\n" . $herecurr); + } + } + +# check for pointless casting of kmalloc return + if ($line =~ /\*\s*\)\s*k[czm]alloc\b/) { + WARN("unnecessary cast may hide bugs, see http://c-faq.com/malloc/mallocnocast.html\n" . $herecurr); + } + +# check for gcc specific __FUNCTION__ + if ($line =~ /__FUNCTION__/) { + WARN("__func__ should be used instead of gcc specific __FUNCTION__\n" . $herecurr); + } + +# check for semaphores used as mutexes + if ($line =~ /^.\s*(DECLARE_MUTEX|init_MUTEX)\s*\(/) { + WARN("mutexes are preferred for single holder semaphores\n" . $herecurr); + } +# check for semaphores used as mutexes + if ($line =~ /^.\s*init_MUTEX_LOCKED\s*\(/) { + WARN("consider using a completion\n" . $herecurr); + + } +# recommend strict_strto* over simple_strto* + if ($line =~ /\bsimple_(strto.*?)\s*\(/) { + WARN("consider using strict_$1 in preference to simple_$1\n" . $herecurr); + } +# check for __initcall(), use device_initcall() explicitly please + if ($line =~ /^.\s*__initcall\s*\(/) { + WARN("please use device_initcall() instead of __initcall()\n" . $herecurr); + } +# check for various ops structs, ensure they are const. + my $struct_ops = qr{acpi_dock_ops| + address_space_operations| + backlight_ops| + block_device_operations| + dentry_operations| + dev_pm_ops| + dma_map_ops| + extent_io_ops| + file_lock_operations| + file_operations| + hv_ops| + ide_dma_ops| + intel_dvo_dev_ops| + item_operations| + iwl_ops| + kgdb_arch| + kgdb_io| + kset_uevent_ops| + lock_manager_operations| + microcode_ops| + mtrr_ops| + neigh_ops| + nlmsvc_binding| + pci_raw_ops| + pipe_buf_operations| + platform_hibernation_ops| + platform_suspend_ops| + proto_ops| + rpc_pipe_ops| + seq_operations| + snd_ac97_build_ops| + soc_pcmcia_socket_ops| + stacktrace_ops| + sysfs_ops| + tty_operations| + usb_mon_operations| + wd_ops}x; + if ($line !~ /\bconst\b/ && + $line =~ /\bstruct\s+($struct_ops)\b/) { + WARN("struct $1 should normally be const\n" . + $herecurr); + } + +# use of NR_CPUS is usually wrong +# ignore definitions of NR_CPUS and usage to define arrays as likely right + if ($line =~ /\bNR_CPUS\b/ && + $line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ && + $line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ && + $line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ && + $line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ && + $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/) + { + WARN("usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr); + } + +# check for %L{u,d,i} in strings + my $string; + while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) { + $string = substr($rawline, $-[1], $+[1] - $-[1]); + $string =~ s/%%/__/g; + if ($string =~ /(?mutex.\n" . $herecurr); + } + } + } + + # If we have no input at all, then there is nothing to report on + # so just keep quiet. + if ($#rawlines == -1) { + exit(0); + } + + # In mailback mode only produce a report in the negative, for + # things that appear to be patches. + if ($mailback && ($clean == 1 || !$is_patch)) { + exit(0); + } + + # This is not a patch, and we are are in 'no-patch' mode so + # just keep quiet. + if (!$chk_patch && !$is_patch) { + exit(0); + } + + if (!$is_patch) { + ERROR("Does not appear to be a unified-diff format patch\n"); + } + if ($is_patch && $chk_signoff && $signoff == 0) { + ERROR("Missing Signed-off-by: line(s)\n"); + } + + print report_dump(); + if ($summary && !($clean == 1 && $quiet == 1)) { + print "$filename " if ($summary_file); + print "total: $cnt_error errors, $cnt_warn warnings, " . + (($check)? "$cnt_chk checks, " : "") . + "$cnt_lines lines checked\n"; + print "\n" if ($quiet == 0); + } + + if ($quiet == 0) { + # If there were whitespace errors which cleanpatch can fix + # then suggest that. +# if ($rpt_cleaners) { +# print "NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or\n"; +# print " scripts/cleanfile\n\n"; +# } + } + + if ($clean == 1 && $quiet == 0) { + print "$vname has no obvious style problems and is ready for submission.\n" + } + if ($clean == 0 && $quiet == 0) { + print "$vname has style problems, please review. If any of these errors\n"; + print "are false positives report them to the maintainer, see\n"; + print "CHECKPATCH in MAINTAINERS.\n"; + } + + return $clean; +} -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:48:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSnL-0002jP-IA; Thu, 10 May 2012 12:48:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSnJ-0002jK-77 for xen-devel@lists.xen.org; Thu, 10 May 2012 12:48:34 +0000 Received: from [193.109.254.147:28799] by server-9.bemta-14.messagelabs.com id 3C/7B-05787-029BBAF4; Thu, 10 May 2012 12:48:32 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336654108!1756098!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15694 invoked from network); 10 May 2012 12:48:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 12:48:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194246401" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 08:47:09 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 08:47:08 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSSlv-0005Db-R3; Thu, 10 May 2012 13:47:07 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Thu, 10 May 2012 13:46:53 +0100 Message-ID: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This script is a copy from the QEMU one, wich is itself a copy from the Linux kernel one (as far as I can tell). This script will only check for parts of the patches that touch libxl files, and I've adapted it to match our CODING_STYLE a little bit, major differences include the following: * Allow if (...) do_something(....); * Allow if (...) do_something(...); * Allow declarations like: libxl_type *var; * Checks for the use of the following functions, and complains if found: libxl__sprintf, LIBXL__LOG_*, libxl__gc_owner, printing a nice error message about how to replace them. * Print error message when "libxl_ctx *ctx =" is used, telling the user to use CTX directly instead. To use it, simply go to the root of the repository and use: $ scripts/checkpatch.pl xxxx.patch Signed-off-by: Roger Pau Monne --- scripts/checkpatch.pl | 2906 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 2906 insertions(+), 0 deletions(-) create mode 100755 scripts/checkpatch.pl diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl new file mode 100755 index 0000000..7e82fab --- /dev/null +++ b/scripts/checkpatch.pl @@ -0,0 +1,2906 @@ +#!/usr/bin/perl -w +# (c) 2001, Dave Jones. (the file handling bit) +# (c) 2005, Joel Schopp (the ugly bit) +# (c) 2007,2008, Andy Whitcroft (new conditions, test suite) +# (c) 2008-2010 Andy Whitcroft +# Licensed under the terms of the GNU GPL License version 2 + +use strict; + +my $P = $0; +$P =~ s@.*/@@g; + +my $V = '0.31'; + +use Getopt::Long qw(:config no_auto_abbrev); + +my $quiet = 0; +my $tree = 1; +my $chk_signoff = 1; +my $chk_patch = 1; +my $tst_only; +my $emacs = 0; +my $terse = 0; +my $file = 0; +my $check = 0; +my $summary = 1; +my $mailback = 0; +my $summary_file = 0; +my $root; +my %debug; +my $help = 0; + +sub help { + my ($exitcode) = @_; + + print << "EOM"; +Usage: $P [OPTION]... [FILE]... +Version: $V + +Options: + -q, --quiet quiet + --no-tree run without a kernel tree + --no-signoff do not check for 'Signed-off-by' line + --patch treat FILE as patchfile (default) + --emacs emacs compile window format + --terse one line per report + -f, --file treat FILE as regular source file + --subjective, --strict enable more subjective tests + --root=PATH PATH to the kernel tree root + --no-summary suppress the per-file summary + --mailback only produce a report in case of warnings/errors + --summary-file include the filename in summary + --debug KEY=[0|1] turn on/off debugging of KEY, where KEY is one of + 'values', 'possible', 'type', and 'attr' (default + is all off) + --test-only=WORD report only warnings/errors containing WORD + literally + -h, --help, --version display this help and exit + +When FILE is - read standard input. +EOM + + exit($exitcode); +} + +GetOptions( + 'q|quiet+' => \$quiet, + 'tree!' => \$tree, + 'signoff!' => \$chk_signoff, + 'patch!' => \$chk_patch, + 'emacs!' => \$emacs, + 'terse!' => \$terse, + 'f|file!' => \$file, + 'subjective!' => \$check, + 'strict!' => \$check, + 'root=s' => \$root, + 'summary!' => \$summary, + 'mailback!' => \$mailback, + 'summary-file!' => \$summary_file, + + 'debug=s' => \%debug, + 'test-only=s' => \$tst_only, + 'h|help' => \$help, + 'version' => \$help +) or help(1); + +help(0) if ($help); + +my $exit = 0; + +if ($#ARGV < 0) { + print "$P: no input files\n"; + exit(1); +} + +my $dbg_values = 0; +my $dbg_possible = 0; +my $dbg_type = 0; +my $dbg_attr = 0; +for my $key (keys %debug) { + ## no critic + eval "\${dbg_$key} = '$debug{$key}';"; + die "$@" if ($@); +} + +my $rpt_cleaners = 0; + +if ($terse) { + $emacs = 1; + $quiet++; +} + +if ($tree) { + if (defined $root) { + if (!top_of_kernel_tree($root)) { + die "$P: $root: --root does not point at a valid tree\n"; + } + } else { + if (top_of_kernel_tree('.')) { + $root = '.'; + } elsif ($0 =~ m@(.*)/scripts/[^/]*$@ && + top_of_kernel_tree($1)) { + $root = $1; + } + } + + if (!defined $root) { + print "Must be run from the top-level dir. of a kernel tree\n"; + exit(2); + } +} + +my $emitted_corrupt = 0; + +our $Ident = qr{ + [A-Za-z_][A-Za-z\d_]* + (?:\s*\#\#\s*[A-Za-z_][A-Za-z\d_]*)* + }x; +our $Storage = qr{extern|static|asmlinkage}; +our $Sparse = qr{ + __user| + __kernel| + __force| + __iomem| + __must_check| + __init_refok| + __kprobes| + __ref + }x; + +# Notes to $Attribute: +# We need \b after 'init' otherwise 'initconst' will cause a false positive in a check +our $Attribute = qr{ + const| + __percpu| + __nocast| + __safe| + __bitwise__| + __packed__| + __packed2__| + __naked| + __maybe_unused| + __always_unused| + __noreturn| + __used| + __cold| + __noclone| + __deprecated| + __read_mostly| + __kprobes| + __(?:mem|cpu|dev|)(?:initdata|initconst|init\b)| + ____cacheline_aligned| + ____cacheline_aligned_in_smp| + ____cacheline_internodealigned_in_smp| + __weak + }x; +our $Modifier; +our $Inline = qr{inline|__always_inline|noinline}; +our $Member = qr{->$Ident|\.$Ident|\[[^]]*\]}; +our $Lval = qr{$Ident(?:$Member)*}; + +our $Constant = qr{(?:[0-9]+|0x[0-9a-fA-F]+)[UL]*}; +our $Assignment = qr{(?:\*\=|/=|%=|\+=|-=|<<=|>>=|&=|\^=|\|=|=)}; +our $Compare = qr{<=|>=|==|!=|<|>}; +our $Operators = qr{ + <=|>=|==|!=| + =>|->|<<|>>|<|>|!|~| + &&|\|\||,|\^|\+\+|--|&|\||\+|-|\*|\/|% + }x; + +our $NonptrType; +our $Type; +our $Declare; + +our $UTF8 = qr { + [\x09\x0A\x0D\x20-\x7E] # ASCII + | [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte + | \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs + | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte + | \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates + | \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3 + | [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15 + | \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16 +}x; + +our $typeTypedefs = qr{(?x: + (?:__)?(?:u|s|be|le)(?:8|16|32|64)| + atomic_t +)}; + +our $logFunctions = qr{(?x: + printk| + pr_(debug|dbg|vdbg|devel|info|warning|err|notice|alert|crit|emerg|cont)| + (dev|netdev|netif)_(printk|dbg|vdbg|info|warn|err|notice|alert|crit|emerg|WARN)| + WARN| + panic +)}; + +our @typeList = ( + qr{void}, + qr{(?:unsigned\s+)?char}, + qr{(?:unsigned\s+)?short}, + qr{(?:unsigned\s+)?int}, + qr{(?:unsigned\s+)?long}, + qr{(?:unsigned\s+)?long\s+int}, + qr{(?:unsigned\s+)?long\s+long}, + qr{(?:unsigned\s+)?long\s+long\s+int}, + qr{unsigned}, + qr{float}, + qr{double}, + qr{bool}, + qr{struct\s+$Ident}, + qr{union\s+$Ident}, + qr{enum\s+$Ident}, + qr{${Ident}_t}, + qr{${Ident}_handler}, + qr{${Ident}_handler_fn}, +); +our @modifierList = ( + qr{fastcall}, +); + +our $allowed_asm_includes = qr{(?x: + irq| + memory +)}; +# memory.h: ARM has a custom one + +sub build_types { + my $mods = "(?x: \n" . join("|\n ", @modifierList) . "\n)"; + my $all = "(?x: \n" . join("|\n ", @typeList) . "\n)"; + $Modifier = qr{(?:$Attribute|$Sparse|$mods)}; + $NonptrType = qr{ + (?:$Modifier\s+|const\s+)* + (?: + (?:typeof|__typeof__)\s*\(\s*\**\s*$Ident\s*\)| + (?:$typeTypedefs\b)| + (?:${all}\b) + ) + (?:\s+$Modifier|\s+const)* + }x; + $Type = qr{ + $NonptrType + (?:[\s\*]+\s*const|[\s\*]+|(?:\s*\[\s*\])+)? + (?:\s+$Inline|\s+$Modifier)* + }x; + $Declare = qr{(?:$Storage\s+)?$Type}; +} +build_types(); + +$chk_signoff = 0 if ($file); + +my @dep_includes = (); +my @dep_functions = (); +my $removal = "Documentation/feature-removal-schedule.txt"; +if ($tree && -f "$root/$removal") { + open(my $REMOVE, '<', "$root/$removal") || + die "$P: $removal: open failed - $!\n"; + while (<$REMOVE>) { + if (/^Check:\s+(.*\S)/) { + for my $entry (split(/[, ]+/, $1)) { + if ($entry =~ m@include/(.*)@) { + push(@dep_includes, $1); + + } elsif ($entry !~ m@/@) { + push(@dep_functions, $entry); + } + } + } + } + close($REMOVE); +} + +my @rawlines = (); +my @lines = (); +my $vname; +for my $filename (@ARGV) { + my $FILE; + if ($file) { + open($FILE, '-|', "diff -u /dev/null $filename") || + die "$P: $filename: diff failed - $!\n"; + } elsif ($filename eq '-') { + open($FILE, '<&STDIN'); + } else { + open($FILE, '<', "$filename") || + die "$P: $filename: open failed - $!\n"; + } + if ($filename eq '-') { + $vname = 'Your patch'; + } else { + $vname = $filename; + } + while (<$FILE>) { + chomp; + push(@rawlines, $_); + } + close($FILE); + if (!process($filename)) { + $exit = 1; + } + @rawlines = (); + @lines = (); +} + +exit($exit); + +sub top_of_kernel_tree { + my ($root) = @_; + + my @tree_check = ( + "COPYING", "MAINTAINERS", "Makefile", + "README", "docs" + ); + + foreach my $check (@tree_check) { + if (! -e $root . '/' . $check) { + return 0; + } + } + return 1; +} + +sub expand_tabs { + my ($str) = @_; + + my $res = ''; + my $n = 0; + for my $c (split(//, $str)) { + if ($c eq "\t") { + $res .= ' '; + $n++; + for (; ($n % 8) != 0; $n++) { + $res .= ' '; + } + next; + } + $res .= $c; + $n++; + } + + return $res; +} +sub copy_spacing { + (my $res = shift) =~ tr/\t/ /c; + return $res; +} + +sub line_stats { + my ($line) = @_; + + # Drop the diff line leader and expand tabs + $line =~ s/^.//; + $line = expand_tabs($line); + + # Pick the indent from the front of the line. + my ($white) = ($line =~ /^(\s*)/); + + return (length($line), length($white)); +} + +my $sanitise_quote = ''; + +sub sanitise_line_reset { + my ($in_comment) = @_; + + if ($in_comment) { + $sanitise_quote = '*/'; + } else { + $sanitise_quote = ''; + } +} +sub sanitise_line { + my ($line) = @_; + + my $res = ''; + my $l = ''; + + my $qlen = 0; + my $off = 0; + my $c; + + # Always copy over the diff marker. + $res = substr($line, 0, 1); + + for ($off = 1; $off < length($line); $off++) { + $c = substr($line, $off, 1); + + # Comments we are wacking completly including the begin + # and end, all to $;. + if ($sanitise_quote eq '' && substr($line, $off, 2) eq '/*') { + $sanitise_quote = '*/'; + + substr($res, $off, 2, "$;$;"); + $off++; + next; + } + if ($sanitise_quote eq '*/' && substr($line, $off, 2) eq '*/') { + $sanitise_quote = ''; + substr($res, $off, 2, "$;$;"); + $off++; + next; + } + if ($sanitise_quote eq '' && substr($line, $off, 2) eq '//') { + $sanitise_quote = '//'; + + substr($res, $off, 2, $sanitise_quote); + $off++; + next; + } + + # A \ in a string means ignore the next character. + if (($sanitise_quote eq "'" || $sanitise_quote eq '"') && + $c eq "\\") { + substr($res, $off, 2, 'XX'); + $off++; + next; + } + # Regular quotes. + if ($c eq "'" || $c eq '"') { + if ($sanitise_quote eq '') { + $sanitise_quote = $c; + + substr($res, $off, 1, $c); + next; + } elsif ($sanitise_quote eq $c) { + $sanitise_quote = ''; + } + } + + #print "c<$c> SQ<$sanitise_quote>\n"; + if ($off != 0 && $sanitise_quote eq '*/' && $c ne "\t") { + substr($res, $off, 1, $;); + } elsif ($off != 0 && $sanitise_quote eq '//' && $c ne "\t") { + substr($res, $off, 1, $;); + } elsif ($off != 0 && $sanitise_quote && $c ne "\t") { + substr($res, $off, 1, 'X'); + } else { + substr($res, $off, 1, $c); + } + } + + if ($sanitise_quote eq '//') { + $sanitise_quote = ''; + } + + # The pathname on a #include may be surrounded by '<' and '>'. + if ($res =~ /^.\s*\#\s*include\s+\<(.*)\>/) { + my $clean = 'X' x length($1); + $res =~ s@\<.*\>@<$clean>@; + + # The whole of a #error is a string. + } elsif ($res =~ /^.\s*\#\s*(?:error|warning)\s+(.*)\b/) { + my $clean = 'X' x length($1); + $res =~ s@(\#\s*(?:error|warning)\s+).*@$1$clean@; + } + + return $res; +} + +sub ctx_statement_block { + my ($linenr, $remain, $off) = @_; + my $line = $linenr - 1; + my $blk = ''; + my $soff = $off; + my $coff = $off - 1; + my $coff_set = 0; + + my $loff = 0; + + my $type = ''; + my $level = 0; + my @stack = (); + my $p; + my $c; + my $len = 0; + + my $remainder; + while (1) { + @stack = (['', 0]) if ($#stack == -1); + + #warn "CSB: blk<$blk> remain<$remain>\n"; + # If we are about to drop off the end, pull in more + # context. + if ($off >= $len) { + for (; $remain > 0; $line++) { + last if (!defined $lines[$line]); + next if ($lines[$line] =~ /^-/); + $remain--; + $loff = $len; + $blk .= $lines[$line] . "\n"; + $len = length($blk); + $line++; + last; + } + # Bail if there is no further context. + #warn "CSB: blk<$blk> off<$off> len<$len>\n"; + if ($off >= $len) { + last; + } + } + $p = $c; + $c = substr($blk, $off, 1); + $remainder = substr($blk, $off); + + #warn "CSB: c<$c> type<$type> level<$level> remainder<$remainder> coff_set<$coff_set>\n"; + + # Handle nested #if/#else. + if ($remainder =~ /^#\s*(?:ifndef|ifdef|if)\s/) { + push(@stack, [ $type, $level ]); + } elsif ($remainder =~ /^#\s*(?:else|elif)\b/) { + ($type, $level) = @{$stack[$#stack - 1]}; + } elsif ($remainder =~ /^#\s*endif\b/) { + ($type, $level) = @{pop(@stack)}; + } + + # Statement ends at the ';' or a close '}' at the + # outermost level. + if ($level == 0 && $c eq ';') { + last; + } + + # An else is really a conditional as long as its not else if + if ($level == 0 && $coff_set == 0 && + (!defined($p) || $p =~ /(?:\s|\}|\+)/) && + $remainder =~ /^(else)(?:\s|{)/ && + $remainder !~ /^else\s+if\b/) { + $coff = $off + length($1) - 1; + $coff_set = 1; + #warn "CSB: mark coff<$coff> soff<$soff> 1<$1>\n"; + #warn "[" . substr($blk, $soff, $coff - $soff + 1) . "]\n"; + } + + if (($type eq '' || $type eq '(') && $c eq '(') { + $level++; + $type = '('; + } + if ($type eq '(' && $c eq ')') { + $level--; + $type = ($level != 0)? '(' : ''; + + if ($level == 0 && $coff < $soff) { + $coff = $off; + $coff_set = 1; + #warn "CSB: mark coff<$coff>\n"; + } + } + if (($type eq '' || $type eq '{') && $c eq '{') { + $level++; + $type = '{'; + } + if ($type eq '{' && $c eq '}') { + $level--; + $type = ($level != 0)? '{' : ''; + + if ($level == 0) { + if (substr($blk, $off + 1, 1) eq ';') { + $off++; + } + last; + } + } + $off++; + } + # We are truly at the end, so shuffle to the next line. + if ($off == $len) { + $loff = $len + 1; + $line++; + $remain--; + } + + my $statement = substr($blk, $soff, $off - $soff + 1); + my $condition = substr($blk, $soff, $coff - $soff + 1); + + #warn "STATEMENT<$statement>\n"; + #warn "CONDITION<$condition>\n"; + + #print "coff<$coff> soff<$off> loff<$loff>\n"; + + return ($statement, $condition, + $line, $remain + 1, $off - $loff + 1, $level); +} + +sub statement_lines { + my ($stmt) = @_; + + # Strip the diff line prefixes and rip blank lines at start and end. + $stmt =~ s/(^|\n)./$1/g; + $stmt =~ s/^\s*//; + $stmt =~ s/\s*$//; + + my @stmt_lines = ($stmt =~ /\n/g); + + return $#stmt_lines + 2; +} + +sub statement_rawlines { + my ($stmt) = @_; + + my @stmt_lines = ($stmt =~ /\n/g); + + return $#stmt_lines + 2; +} + +sub statement_block_size { + my ($stmt) = @_; + + $stmt =~ s/(^|\n)./$1/g; + $stmt =~ s/^\s*{//; + $stmt =~ s/}\s*$//; + $stmt =~ s/^\s*//; + $stmt =~ s/\s*$//; + + my @stmt_lines = ($stmt =~ /\n/g); + my @stmt_statements = ($stmt =~ /;/g); + + my $stmt_lines = $#stmt_lines + 2; + my $stmt_statements = $#stmt_statements + 1; + + if ($stmt_lines > $stmt_statements) { + return $stmt_lines; + } else { + return $stmt_statements; + } +} + +sub ctx_statement_full { + my ($linenr, $remain, $off) = @_; + my ($statement, $condition, $level); + + my (@chunks); + + # Grab the first conditional/block pair. + ($statement, $condition, $linenr, $remain, $off, $level) = + ctx_statement_block($linenr, $remain, $off); + #print "F: c<$condition> s<$statement> remain<$remain>\n"; + push(@chunks, [ $condition, $statement ]); + if (!($remain > 0 && $condition =~ /^\s*(?:\n[+-])?\s*(?:if|else|do)\b/s)) { + return ($level, $linenr, @chunks); + } + + # Pull in the following conditional/block pairs and see if they + # could continue the statement. + for (;;) { + ($statement, $condition, $linenr, $remain, $off, $level) = + ctx_statement_block($linenr, $remain, $off); + #print "C: c<$condition> s<$statement> remain<$remain>\n"; + last if (!($remain > 0 && $condition =~ /^(?:\s*\n[+-])*\s*(?:else|do)\b/s)); + #print "C: push\n"; + push(@chunks, [ $condition, $statement ]); + } + + return ($level, $linenr, @chunks); +} + +sub ctx_block_get { + my ($linenr, $remain, $outer, $open, $close, $off) = @_; + my $line; + my $start = $linenr - 1; + my $blk = ''; + my @o; + my @c; + my @res = (); + + my $level = 0; + my @stack = ($level); + for ($line = $start; $remain > 0; $line++) { + next if ($rawlines[$line] =~ /^-/); + $remain--; + + $blk .= $rawlines[$line]; + + # Handle nested #if/#else. + if ($lines[$line] =~ /^.\s*#\s*(?:ifndef|ifdef|if)\s/) { + push(@stack, $level); + } elsif ($lines[$line] =~ /^.\s*#\s*(?:else|elif)\b/) { + $level = $stack[$#stack - 1]; + } elsif ($lines[$line] =~ /^.\s*#\s*endif\b/) { + $level = pop(@stack); + } + + foreach my $c (split(//, $lines[$line])) { + ##print "C<$c>L<$level><$open$close>O<$off>\n"; + if ($off > 0) { + $off--; + next; + } + + if ($c eq $close && $level > 0) { + $level--; + last if ($level == 0); + } elsif ($c eq $open) { + $level++; + } + } + + if (!$outer || $level <= 1) { + push(@res, $rawlines[$line]); + } + + last if ($level == 0); + } + + return ($level, @res); +} +sub ctx_block_outer { + my ($linenr, $remain) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 1, '{', '}', 0); + return @r; +} +sub ctx_block { + my ($linenr, $remain) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 0, '{', '}', 0); + return @r; +} +sub ctx_statement { + my ($linenr, $remain, $off) = @_; + + my ($level, @r) = ctx_block_get($linenr, $remain, 0, '(', ')', $off); + return @r; +} +sub ctx_block_level { + my ($linenr, $remain) = @_; + + return ctx_block_get($linenr, $remain, 0, '{', '}', 0); +} +sub ctx_statement_level { + my ($linenr, $remain, $off) = @_; + + return ctx_block_get($linenr, $remain, 0, '(', ')', $off); +} + +sub ctx_locate_comment { + my ($first_line, $end_line) = @_; + + # Catch a comment on the end of the line itself. + my ($current_comment) = ($rawlines[$end_line - 1] =~ m@.*(/\*.*\*/)\s*(?:\\\s*)?$@); + return $current_comment if (defined $current_comment); + + # Look through the context and try and figure out if there is a + # comment. + my $in_comment = 0; + $current_comment = ''; + for (my $linenr = $first_line; $linenr < $end_line; $linenr++) { + my $line = $rawlines[$linenr - 1]; + #warn " $line\n"; + if ($linenr == $first_line and $line =~ m@^.\s*\*@) { + $in_comment = 1; + } + if ($line =~ m@/\*@) { + $in_comment = 1; + } + if (!$in_comment && $current_comment ne '') { + $current_comment = ''; + } + $current_comment .= $line . "\n" if ($in_comment); + if ($line =~ m@\*/@) { + $in_comment = 0; + } + } + + chomp($current_comment); + return($current_comment); +} +sub ctx_has_comment { + my ($first_line, $end_line) = @_; + my $cmt = ctx_locate_comment($first_line, $end_line); + + ##print "LINE: $rawlines[$end_line - 1 ]\n"; + ##print "CMMT: $cmt\n"; + + return ($cmt ne ''); +} + +sub raw_line { + my ($linenr, $cnt) = @_; + + my $offset = $linenr - 1; + $cnt++; + + my $line; + while ($cnt) { + $line = $rawlines[$offset++]; + next if (defined($line) && $line =~ /^-/); + $cnt--; + } + + return $line; +} + +sub cat_vet { + my ($vet) = @_; + my ($res, $coded); + + $res = ''; + while ($vet =~ /([^[:cntrl:]]*)([[:cntrl:]]|$)/g) { + $res .= $1; + if ($2 ne '') { + $coded = sprintf("^%c", unpack('C', $2) + 64); + $res .= $coded; + } + } + $res =~ s/$/\$/; + + return $res; +} + +my $av_preprocessor = 0; +my $av_pending; +my @av_paren_type; +my $av_pend_colon; + +sub annotate_reset { + $av_preprocessor = 0; + $av_pending = '_'; + @av_paren_type = ('E'); + $av_pend_colon = 'O'; +} + +sub annotate_values { + my ($stream, $type) = @_; + + my $res; + my $var = '_' x length($stream); + my $cur = $stream; + + print "$stream\n" if ($dbg_values > 1); + + while (length($cur)) { + @av_paren_type = ('E') if ($#av_paren_type < 0); + print " <" . join('', @av_paren_type) . + "> <$type> <$av_pending>" if ($dbg_values > 1); + if ($cur =~ /^(\s+)/o) { + print "WS($1)\n" if ($dbg_values > 1); + if ($1 =~ /\n/ && $av_preprocessor) { + $type = pop(@av_paren_type); + $av_preprocessor = 0; + } + + } elsif ($cur =~ /^(\(\s*$Type\s*)\)/ && $av_pending eq '_') { + print "CAST($1)\n" if ($dbg_values > 1); + push(@av_paren_type, $type); + $type = 'C'; + + } elsif ($cur =~ /^($Type)\s*(?:$Ident|,|\)|\(|\s*$)/) { + print "DECLARE($1)\n" if ($dbg_values > 1); + $type = 'T'; + + } elsif ($cur =~ /^($Modifier)\s*/) { + print "MODIFIER($1)\n" if ($dbg_values > 1); + $type = 'T'; + + } elsif ($cur =~ /^(\#\s*define\s*$Ident)(\(?)/o) { + print "DEFINE($1,$2)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + push(@av_paren_type, $type); + if ($2 ne '') { + $av_pending = 'N'; + } + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:undef\s*$Ident|include\b))/o) { + print "UNDEF($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + push(@av_paren_type, $type); + + } elsif ($cur =~ /^(\#\s*(?:ifdef|ifndef|if))/o) { + print "PRE_START($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + + push(@av_paren_type, $type); + push(@av_paren_type, $type); + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:else|elif))/o) { + print "PRE_RESTART($1)\n" if ($dbg_values > 1); + $av_preprocessor = 1; + + push(@av_paren_type, $av_paren_type[$#av_paren_type]); + + $type = 'E'; + + } elsif ($cur =~ /^(\#\s*(?:endif))/o) { + print "PRE_END($1)\n" if ($dbg_values > 1); + + $av_preprocessor = 1; + + # Assume all arms of the conditional end as this + # one does, and continue as if the #endif was not here. + pop(@av_paren_type); + push(@av_paren_type, $type); + $type = 'E'; + + } elsif ($cur =~ /^(\\\n)/o) { + print "PRECONT($1)\n" if ($dbg_values > 1); + + } elsif ($cur =~ /^(__attribute__)\s*\(?/o) { + print "ATTR($1)\n" if ($dbg_values > 1); + $av_pending = $type; + $type = 'N'; + + } elsif ($cur =~ /^(sizeof)\s*(\()?/o) { + print "SIZEOF($1)\n" if ($dbg_values > 1); + if (defined $2) { + $av_pending = 'V'; + } + $type = 'N'; + + } elsif ($cur =~ /^(if|while|for)\b/o) { + print "COND($1)\n" if ($dbg_values > 1); + $av_pending = 'E'; + $type = 'N'; + + } elsif ($cur =~/^(case)/o) { + print "CASE($1)\n" if ($dbg_values > 1); + $av_pend_colon = 'C'; + $type = 'N'; + + } elsif ($cur =~/^(return|else|goto|typeof|__typeof__)\b/o) { + print "KEYWORD($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(\()/o) { + print "PAREN('$1')\n" if ($dbg_values > 1); + push(@av_paren_type, $av_pending); + $av_pending = '_'; + $type = 'N'; + + } elsif ($cur =~ /^(\))/o) { + my $new_type = pop(@av_paren_type); + if ($new_type ne '_') { + $type = $new_type; + print "PAREN('$1') -> $type\n" + if ($dbg_values > 1); + } else { + print "PAREN('$1')\n" if ($dbg_values > 1); + } + + } elsif ($cur =~ /^($Ident)\s*\(/o) { + print "FUNC($1)\n" if ($dbg_values > 1); + $type = 'V'; + $av_pending = 'V'; + + } elsif ($cur =~ /^($Ident\s*):(?:\s*\d+\s*(,|=|;))?/) { + if (defined $2 && $type eq 'C' || $type eq 'T') { + $av_pend_colon = 'B'; + } elsif ($type eq 'E') { + $av_pend_colon = 'L'; + } + print "IDENT_COLON($1,$type>$av_pend_colon)\n" if ($dbg_values > 1); + $type = 'V'; + + } elsif ($cur =~ /^($Ident|$Constant)/o) { + print "IDENT($1)\n" if ($dbg_values > 1); + $type = 'V'; + + } elsif ($cur =~ /^($Assignment)/o) { + print "ASSIGN($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~/^(;|{|})/) { + print "END($1)\n" if ($dbg_values > 1); + $type = 'E'; + $av_pend_colon = 'O'; + + } elsif ($cur =~/^(,)/) { + print "COMMA($1)\n" if ($dbg_values > 1); + $type = 'C'; + + } elsif ($cur =~ /^(\?)/o) { + print "QUESTION($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(:)/o) { + print "COLON($1,$av_pend_colon)\n" if ($dbg_values > 1); + + substr($var, length($res), 1, $av_pend_colon); + if ($av_pend_colon eq 'C' || $av_pend_colon eq 'L') { + $type = 'E'; + } else { + $type = 'N'; + } + $av_pend_colon = 'O'; + + } elsif ($cur =~ /^(\[)/o) { + print "CLOSE($1)\n" if ($dbg_values > 1); + $type = 'N'; + + } elsif ($cur =~ /^(-(?![->])|\+(?!\+)|\*|\&\&|\&)/o) { + my $variant; + + print "OPV($1)\n" if ($dbg_values > 1); + if ($type eq 'V') { + $variant = 'B'; + } else { + $variant = 'U'; + } + + substr($var, length($res), 1, $variant); + $type = 'N'; + + } elsif ($cur =~ /^($Operators)/o) { + print "OP($1)\n" if ($dbg_values > 1); + if ($1 ne '++' && $1 ne '--') { + $type = 'N'; + } + + } elsif ($cur =~ /(^.)/o) { + print "C($1)\n" if ($dbg_values > 1); + } + if (defined $1) { + $cur = substr($cur, length($1)); + $res .= $type x length($1); + } + } + + return ($res, $var); +} + +sub possible { + my ($possible, $line) = @_; + my $notPermitted = qr{(?: + ^(?: + $Modifier| + $Storage| + $Type| + DEFINE_\S+ + )$| + ^(?: + goto| + return| + case| + else| + asm|__asm__| + do + )(?:\s|$)| + ^(?:typedef|struct|enum)\b + )}x; + warn "CHECK<$possible> ($line)\n" if ($dbg_possible > 2); + if ($possible !~ $notPermitted) { + # Check for modifiers. + $possible =~ s/\s*$Storage\s*//g; + $possible =~ s/\s*$Sparse\s*//g; + if ($possible =~ /^\s*$/) { + + } elsif ($possible =~ /\s/) { + $possible =~ s/\s*$Type\s*//g; + for my $modifier (split(' ', $possible)) { + if ($modifier !~ $notPermitted) { + warn "MODIFIER: $modifier ($possible) ($line)\n" if ($dbg_possible); + push(@modifierList, $modifier); + } + } + + } else { + warn "POSSIBLE: $possible ($line)\n" if ($dbg_possible); + push(@typeList, $possible); + } + build_types(); + } else { + warn "NOTPOSS: $possible ($line)\n" if ($dbg_possible > 1); + } +} + +my $prefix = ''; + +sub report { + if (defined $tst_only && $_[0] !~ /\Q$tst_only\E/) { + return 0; + } + my $line = $prefix . $_[0]; + + $line = (split('\n', $line))[0] . "\n" if ($terse); + + push(our @report, $line); + + return 1; +} +sub report_dump { + our @report; +} +sub ERROR { + if (report("ERROR: $_[0]\n")) { + our $clean = 0; + our $cnt_error++; + } +} +sub WARN { + if (report("WARNING: $_[0]\n")) { + our $clean = 0; + our $cnt_warn++; + } +} +sub CHK { + if ($check && report("CHECK: $_[0]\n")) { + our $clean = 0; + our $cnt_chk++; + } +} + +sub check_absolute_file { + my ($absolute, $herecurr) = @_; + my $file = $absolute; + + ##print "absolute<$absolute>\n"; + + # See if any suffix of this path is a path within the tree. + while ($file =~ s@^[^/]*/@@) { + if (-f "$root/$file") { + ##print "file<$file>\n"; + last; + } + } + if (! -f _) { + return 0; + } + + # It is, so see if the prefix is acceptable. + my $prefix = $absolute; + substr($prefix, -length($file)) = ''; + + ##print "prefix<$prefix>\n"; + if ($prefix ne ".../") { + WARN("use relative pathname instead of absolute in changelog text\n" . $herecurr); + } +} + +sub process { + my $filename = shift; + + my $linenr=0; + my $prevline=""; + my $prevrawline=""; + my $stashline=""; + my $stashrawline=""; + + my $length; + my $indent; + my $previndent=0; + my $stashindent=0; + + our $clean = 1; + my $signoff = 0; + my $is_patch = 0; + + our @report = (); + our $cnt_lines = 0; + our $cnt_error = 0; + our $cnt_warn = 0; + our $cnt_chk = 0; + + # Trace the real file/line as we go. + my $realfile = ''; + my $realline = 0; + my $realcnt = 0; + my $here = ''; + my $in_comment = 0; + my $comment_edge = 0; + my $first_line = 0; + my $p1_prefix = ''; + + my $prev_values = 'E'; + + # suppression flags + my %suppress_ifbraces; + my %suppress_whiletrailers; + my %suppress_export; + + # Pre-scan the patch sanitizing the lines. + # Pre-scan the patch looking for any __setup documentation. + # + my @setup_docs = (); + my $setup_docs = 0; + + sanitise_line_reset(); + my $line; + foreach my $rawline (@rawlines) { + $linenr++; + $line = $rawline; + + if ($rawline=~/^\+\+\+\s+(\S+)/) { + $setup_docs = 0; + if ($1 =~ m@Documentation/kernel-parameters.txt$@) { + $setup_docs = 1; + } + #next; + } + if ($rawline=~/^\@\@ -\d+(?:,\d+)? \+(\d+)(,(\d+))? \@\@/) { + $realline=$1-1; + if (defined $2) { + $realcnt=$3+1; + } else { + $realcnt=1+1; + } + $in_comment = 0; + + # Guestimate if this is a continuing comment. Run + # the context looking for a comment "edge". If this + # edge is a close comment then we must be in a comment + # at context start. + my $edge; + my $cnt = $realcnt; + for (my $ln = $linenr + 1; $cnt > 0; $ln++) { + next if (defined $rawlines[$ln - 1] && + $rawlines[$ln - 1] =~ /^-/); + $cnt--; + #print "RAW<$rawlines[$ln - 1]>\n"; + last if (!defined $rawlines[$ln - 1]); + if ($rawlines[$ln - 1] =~ m@(/\*|\*/)@ && + $rawlines[$ln - 1] !~ m@"[^"]*(?:/\*|\*/)[^"]*"@) { + ($edge) = $1; + last; + } + } + if (defined $edge && $edge eq '*/') { + $in_comment = 1; + } + + # Guestimate if this is a continuing comment. If this + # is the start of a diff block and this line starts + # ' *' then it is very likely a comment. + if (!defined $edge && + $rawlines[$linenr] =~ m@^.\s*(?:\*\*+| \*)(?:\s|$)@) + { + $in_comment = 1; + } + + ##print "COMMENT:$in_comment edge<$edge> $rawline\n"; + sanitise_line_reset($in_comment); + + } elsif ($realcnt && $rawline =~ /^(?:\+| |$)/) { + # Standardise the strings and chars within the input to + # simplify matching -- only bother with positive lines. + $line = sanitise_line($rawline); + } + push(@lines, $line); + + if ($realcnt > 1) { + $realcnt-- if ($line =~ /^(?:\+| |$)/); + } else { + $realcnt = 0; + } + + #print "==>$rawline\n"; + #print "-->$line\n"; + + if ($setup_docs && $line =~ /^\+/) { + push(@setup_docs, $line); + } + } + + $prefix = ''; + + $realcnt = 0; + $linenr = 0; + foreach my $line (@lines) { + $linenr++; + + my $rawline = $rawlines[$linenr - 1]; + +#extract the line range in the file after the patch is applied + if ($line=~/^\@\@ -\d+(?:,\d+)? \+(\d+)(,(\d+))? \@\@/) { + $is_patch = 1; + $first_line = $linenr + 1; + $realline=$1-1; + if (defined $2) { + $realcnt=$3+1; + } else { + $realcnt=1+1; + } + annotate_reset(); + $prev_values = 'E'; + + %suppress_ifbraces = (); + %suppress_whiletrailers = (); + %suppress_export = (); + next; + +# track the line number as we move through the hunk, note that +# new versions of GNU diff omit the leading space on completely +# blank context lines so we need to count that too. + } elsif ($line =~ /^( |\+|$)/) { + $realline++; + $realcnt-- if ($realcnt != 0); + + # Measure the line length and indent. + ($length, $indent) = line_stats($rawline); + + # Track the previous line. + ($prevline, $stashline) = ($stashline, $line); + ($previndent, $stashindent) = ($stashindent, $indent); + ($prevrawline, $stashrawline) = ($stashrawline, $rawline); + + #warn "line<$line>\n"; + + } elsif ($realcnt == 1) { + $realcnt--; + } + + my $hunk_line = ($realcnt != 0); + +#make up the handle for any error we report on this line + $prefix = "$filename:$realline: " if ($emacs && $file); + $prefix = "$filename:$linenr: " if ($emacs && !$file); + + $here = "#$linenr: " if (!$file); + $here = "#$realline: " if ($file); + + # extract the filename as it passes + if ($line =~ /^diff --git.*?(\S+)$/) { + $realfile = $1; + $realfile =~ s@^([^/]*)/@@; + + } elsif ($line =~ /^\+\+\+\s+(\S+)/) { + $realfile = $1; + $realfile =~ s@^([^/]*)/@@; + + $p1_prefix = $1; + if (!$file && $tree && $p1_prefix ne '' && + -e "$root/$p1_prefix") { + WARN("patch prefix '$p1_prefix' exists, appears to be a -p0 patch\n"); + } + + if ($realfile =~ m@^include/asm/@) { + ERROR("do not modify files in include/asm, change architecture specific files in include/asm-\n" . "$here$rawline\n"); + } + next; + } + + $here .= "FILE: $realfile:$realline:" if ($realcnt != 0); + + my $hereline = "$here\n$rawline\n"; + my $herecurr = "$here\n$rawline\n"; + my $hereprev = "$here\n$prevrawline\n$rawline\n"; + + $cnt_lines++ if ($realcnt != 0); + +# Check for incorrect file permissions + if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) { + my $permhere = $here . "FILE: $realfile\n"; + if ($realfile =~ /(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) { + ERROR("do not set execute permissions for source files\n" . $permhere); + } + } + +#check the patch for a signoff: + if ($line =~ /^\s*signed-off-by:/i) { + # This is a signoff, if ugly, so do not double report. + $signoff++; + if (!($line =~ /^\s*Signed-off-by:/)) { + WARN("Signed-off-by: is the preferred form\n" . + $herecurr); + } + if ($line =~ /^\s*signed-off-by:\S/i) { + WARN("space required after Signed-off-by:\n" . + $herecurr); + } + } + +# Check for wrappage within a valid hunk of the file + if ($realcnt != 0 && $line !~ m{^(?:\+|-| |\\ No newline|$)}) { + ERROR("patch seems to be corrupt (line wrapped?)\n" . + $herecurr) if (!$emitted_corrupt++); + } + +# Check for absolute kernel paths. + if ($tree) { + while ($line =~ m{(?:^|\s)(/\S*)}g) { + my $file = $1; + + if ($file =~ m{^(.*?)(?::\d+)+:?$} && + check_absolute_file($1, $herecurr)) { + # + } else { + check_absolute_file($file, $herecurr); + } + } + } + +# UTF-8 regex found at http://www.w3.org/International/questions/qa-forms-utf-8.en.php + if (($realfile =~ /^$/ || $line =~ /^\+/) && + $rawline !~ m/^$UTF8*$/) { + my ($utf8_prefix) = ($rawline =~ /^($UTF8*)/); + + my $blank = copy_spacing($rawline); + my $ptr = substr($blank, 0, length($utf8_prefix)) . "^"; + my $hereptr = "$hereline$ptr\n"; + + ERROR("Invalid UTF-8, patch and commit message should be encoded in UTF-8\n" . $hereptr); + } + +# ignore non-hunk lines and lines being removed + next if (!$hunk_line || $line =~ /^-/); + +#trailing whitespace + if ($line =~ /^\+.*\015/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("DOS line endings\n" . $herevet); + + } elsif ($rawline =~ /^\+.*\S\s+$/ || $rawline =~ /^\+\s+$/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("trailing whitespace\n" . $herevet); + $rpt_cleaners = 1; + } + +# check for Kconfig help text having a real description +# Only applies when adding the entry originally, after that we do not have +# sufficient context to determine whether it is indeed long enough. + if ($realfile =~ /Kconfig/ && + $line =~ /\+\s*(?:---)?help(?:---)?$/) { + my $length = 0; + my $cnt = $realcnt; + my $ln = $linenr + 1; + my $f; + my $is_end = 0; + while ($cnt > 0 && defined $lines[$ln - 1]) { + $f = $lines[$ln - 1]; + $cnt-- if ($lines[$ln - 1] !~ /^-/); + $is_end = $lines[$ln - 1] =~ /^\+/; + $ln++; + + next if ($f =~ /^-/); + $f =~ s/^.//; + $f =~ s/#.*//; + $f =~ s/^\s+//; + next if ($f =~ /^$/); + if ($f =~ /^\s*config\s/) { + $is_end = 1; + last; + } + $length++; + } + WARN("please write a paragraph that describes the config symbol fully\n" . $herecurr) if ($is_end && $length < 4); + #print "is_end<$is_end> length<$length>\n"; + } + +# check we are in a valid source file if not then ignore this hunk +# only chek files in tools/libxl/ + next if ($realfile !~ /^tools\/libxl\/.*\.(h|c|s|S|pl|sh)$/); + +#80 column limit + if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ && + $rawline !~ /^.\s*\*\s*\@$Ident\s/ && + !($line =~ /^\+\s*$logFunctions\s*\(\s*(?:(KERN_\S+\s*|[^"]*))?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ || + $line =~ /^\+\s*"[^"]*"\s*(?:\s*|,|\)\s*;)\s*$/) && + $length > 80) + { + WARN("line over 80 characters\n" . $herecurr); + } + +# check for spaces before a quoted newline + if ($rawline =~ /^.*\".*\s\\n/) { + WARN("unnecessary whitespace before a quoted newline\n" . $herecurr); + } + +# check for adding lines without a newline. + if ($line =~ /^\+/ && defined $lines[$linenr] && $lines[$linenr] =~ /^\\ No newline at end of file/) { + WARN("adding a line without newline at end of file\n" . $herecurr); + } + + +# check we are in a valid source file C or perl if not then ignore this hunk + next if ($realfile !~ /\.(h|c|pl)$/); + +# in QEMU, no tabs are allowed + if ($rawline =~ /^\+.*\t/) { + my $herevet = "$here\n" . cat_vet($rawline) . "\n"; + ERROR("code indent should never use tabs\n" . $herevet); + $rpt_cleaners = 1; + } + +# check we are in a valid C source file if not then ignore this hunk + next if ($realfile !~ /\.(h|c)$/); + +# check for RCS/CVS revision markers + if ($rawline =~ /^\+.*\$(Revision|Log|Id)(?:\$|)/) { + WARN("CVS style keyword markers, these will _not_ be updated\n". $herecurr); + } + +# Check for libxl__sprintf + if ($line =~ /^\+.*libxl__sprintf/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the GCSPRINTF macro instead of libxl__sprintf\n" . $herevet); + } +# Check for old log functions + if ($line =~ /^\+.*LIBXL__LOG_/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the new set of logging functions, LOG, LOGE and LOGEV\n" . $herevet); + } +# Check for definitions of ctx + if ($line =~ /^\+.*libxl_ctx *ctx =/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the CTX macro directly instead of a variable\n" . $herevet); + } +# Check for use of libxl__gc_owner + if ($line =~ /^\+.*libxl__gc_owner/) { + my $herevet = "$here\n" . cat_vet($line) . "\n"; + ERROR("use the CTX macro\n" . $herevet); + } + +# Check for potential 'bare' types + my ($stat, $cond, $line_nr_next, $remain_next, $off_next, + $realline_next); + if ($realcnt && $line =~ /.\s*\S/) { + ($stat, $cond, $line_nr_next, $remain_next, $off_next) = + ctx_statement_block($linenr, $realcnt, 0); + $stat =~ s/\n./\n /g; + $cond =~ s/\n./\n /g; + + # Find the real next line. + $realline_next = $line_nr_next; + if (defined $realline_next && + (!defined $lines[$realline_next - 1] || + substr($lines[$realline_next - 1], $off_next) =~ /^\s*$/)) { + $realline_next++; + } + + my $s = $stat; + $s =~ s/{.*$//s; + + # Ignore goto labels. + if ($s =~ /$Ident:\*$/s) { + + # Ignore functions being called + } elsif ($s =~ /^.\s*$Ident\s*\(/s) { + + } elsif ($s =~ /^.\s*else\b/s) { + + # declarations always start with types + } elsif ($prev_values eq 'E' && $s =~ /^.\s*(?:$Storage\s+)?(?:$Inline\s+)?(?:const\s+)?((?:\s*$Ident)+?)\b(?:\s+$Sparse)?\s*\**\s*(?:$Ident|\(\*[^\)]*\))(?:\s*$Modifier)?\s*(?:;|=|,|\()/s) { + my $type = $1; + $type =~ s/\s+/ /g; + possible($type, "A:" . $s); + + # definitions in global scope can only start with types + } elsif ($s =~ /^.(?:$Storage\s+)?(?:$Inline\s+)?(?:const\s+)?($Ident)\b\s*(?!:)/s) { + possible($1, "B:" . $s); + } + + # any (foo ... *) is a pointer cast, and foo is a type + while ($s =~ /\(($Ident)(?:\s+$Sparse)*[\s\*]+\s*\)/sg) { + possible($1, "C:" . $s); + } + + # Check for any sort of function declaration. + # int foo(something bar, other baz); + # void (*store_gdt)(x86_descr_ptr *); + if ($prev_values eq 'E' && $s =~ /^(.(?:typedef\s*)?(?:(?:$Storage|$Inline)\s*)*\s*$Type\s*(?:\b$Ident|\(\*\s*$Ident\))\s*)\(/s) { + my ($name_len) = length($1); + + my $ctx = $s; + substr($ctx, 0, $name_len + 1, ''); + $ctx =~ s/\)[^\)]*$//; + + for my $arg (split(/\s*,\s*/, $ctx)) { + if ($arg =~ /^(?:const\s+)?($Ident)(?:\s+$Sparse)*\s*\**\s*(:?\b$Ident)?$/s || $arg =~ /^($Ident)$/s) { + + possible($1, "D:" . $s); + } + } + } + + } + +# +# Checks which may be anchored in the context. +# + +# Check for switch () and associated case and default +# statements should be at the same indent. + if ($line=~/\bswitch\s*\(.*\)/) { + my $err = ''; + my $sep = ''; + my @ctx = ctx_block_outer($linenr, $realcnt); + shift(@ctx); + for my $ctx (@ctx) { + my ($clen, $cindent) = line_stats($ctx); + if ($ctx =~ /^\+\s*(case\s+|default:)/ && + $indent != $cindent) { + $err .= "$sep$ctx\n"; + $sep = ''; + } else { + $sep = "[...]\n"; + } + } + if ($err ne '') { + ERROR("switch and case should be at the same indent\n$hereline$err"); + } + } + +# if/while/etc brace do not go on next line, unless defining a do while loop, +# or if that brace on the next line is for something else + if ($line =~ /(.*)\b((?:if|while|for|switch)\s*\(|do\b|else\b)/ && $line !~ /^.\s*\#/) { + my $pre_ctx = "$1$2"; + + my ($level, @ctx) = ctx_statement_level($linenr, $realcnt, 0); + my $ctx_cnt = $realcnt - $#ctx - 1; + my $ctx = join("\n", @ctx); + + my $ctx_ln = $linenr; + my $ctx_skip = $realcnt; + + while ($ctx_skip > $ctx_cnt || ($ctx_skip == $ctx_cnt && + defined $lines[$ctx_ln - 1] && + $lines[$ctx_ln - 1] =~ /^-/)) { + ##print "SKIP<$ctx_skip> CNT<$ctx_cnt>\n"; + $ctx_skip-- if (!defined $lines[$ctx_ln - 1] || $lines[$ctx_ln - 1] !~ /^-/); + $ctx_ln++; + } + + #print "realcnt<$realcnt> ctx_cnt<$ctx_cnt>\n"; + #print "pre<$pre_ctx>\nline<$line>\nctx<$ctx>\nnext<$lines[$ctx_ln - 1]>\n"; + + if ($ctx !~ /{\s*/ && defined($lines[$ctx_ln -1]) && $lines[$ctx_ln - 1] =~ /^\+\s*{/) { + ERROR("that open brace { should be on the previous line\n" . + "$here\n$ctx\n$rawlines[$ctx_ln - 1]\n"); + } + if ($level == 0 && $pre_ctx !~ /}\s*while\s*\($/ && + $ctx =~ /\)\s*\;\s*$/ && + defined $lines[$ctx_ln - 1]) + { + my ($nlength, $nindent) = line_stats($lines[$ctx_ln - 1]); + if ($nindent > $indent) { + WARN("trailing semicolon indicates no statements, indent implies otherwise\n" . + "$here\n$ctx\n$rawlines[$ctx_ln - 1]\n"); + } + } + } + +# Check relative indent for conditionals and blocks. + if ($line =~ /\b(?:(?:if|while|for)\s*\(|do\b)/ && $line !~ /^.\s*#/ && $line !~ /\}\s*while\s*/) { + my ($s, $c) = ($stat, $cond); + + substr($s, 0, length($c), ''); + + # Make sure we remove the line prefixes as we have + # none on the first line, and are going to readd them + # where necessary. + $s =~ s/\n./\n/gs; + + # Find out how long the conditional actually is. + my @newlines = ($c =~ /\n/gs); + my $cond_lines = 1 + $#newlines; + + # We want to check the first line inside the block + # starting at the end of the conditional, so remove: + # 1) any blank line termination + # 2) any opening brace { on end of the line + # 3) any do (...) { + my $continuation = 0; + my $check = 0; + $s =~ s/^.*\bdo\b//; + $s =~ s/^\s*{//; + if ($s =~ s/^\s*\\//) { + $continuation = 1; + } + if ($s =~ s/^\s*?\n//) { + $check = 1; + $cond_lines++; + } + + # Also ignore a loop construct at the end of a + # preprocessor statement. + if (($prevline =~ /^.\s*#\s*define\s/ || + $prevline =~ /\\\s*$/) && $continuation == 0) { + $check = 0; + } + + my $cond_ptr = -1; + $continuation = 0; + while ($cond_ptr != $cond_lines) { + $cond_ptr = $cond_lines; + + # If we see an #else/#elif then the code + # is not linear. + if ($s =~ /^\s*\#\s*(?:else|elif)/) { + $check = 0; + } + + # Ignore: + # 1) blank lines, they should be at 0, + # 2) preprocessor lines, and + # 3) labels. + if ($continuation || + $s =~ /^\s*?\n/ || + $s =~ /^\s*#\s*?/ || + $s =~ /^\s*$Ident\s*:/) { + $continuation = ($s =~ /^.*?\\\n/) ? 1 : 0; + if ($s =~ s/^.*?\n//) { + $cond_lines++; + } + } + } + + my (undef, $sindent) = line_stats("+" . $s); + my $stat_real = raw_line($linenr, $cond_lines); + + # Check if either of these lines are modified, else + # this is not this patch's fault. + if (!defined($stat_real) || + $stat !~ /^\+/ && $stat_real !~ /^\+/) { + $check = 0; + } + if (defined($stat_real) && $cond_lines > 1) { + $stat_real = "[...]\n$stat_real"; + } + + #print "line<$line> prevline<$prevline> indent<$indent> sindent<$sindent> check<$check> continuation<$continuation> s<$s> cond_lines<$cond_lines> stat_real<$stat_real> stat<$stat>\n"; + + if ($check && (($sindent % 4) != 0 || + ($sindent <= $indent && $s ne ''))) { + WARN("suspect code indent for conditional statements ($indent, $sindent)\n" . $herecurr . "$stat_real\n"); + } + } + + # Track the 'values' across context and added lines. + my $opline = $line; $opline =~ s/^./ /; + my ($curr_values, $curr_vars) = + annotate_values($opline . "\n", $prev_values); + $curr_values = $prev_values . $curr_values; + if ($dbg_values) { + my $outline = $opline; $outline =~ s/\t/ /g; + print "$linenr > .$outline\n"; + print "$linenr > $curr_values\n"; + print "$linenr > $curr_vars\n"; + } + $prev_values = substr($curr_values, -1); + +#ignore lines not being added + if ($line=~/^[^\+]/) {next;} + +# TEST: allow direct testing of the type matcher. + if ($dbg_type) { + if ($line =~ /^.\s*$Declare\s*$/) { + ERROR("TEST: is type\n" . $herecurr); + } elsif ($dbg_type > 1 && $line =~ /^.+($Declare)/) { + ERROR("TEST: is not type ($1 is)\n". $herecurr); + } + next; + } +# TEST: allow direct testing of the attribute matcher. + if ($dbg_attr) { + if ($line =~ /^.\s*$Modifier\s*$/) { + ERROR("TEST: is attr\n" . $herecurr); + } elsif ($dbg_attr > 1 && $line =~ /^.+($Modifier)/) { + ERROR("TEST: is not attr ($1 is)\n". $herecurr); + } + next; + } + +# check for initialisation to aggregates open brace on the next line + if ($line =~ /^.\s*{/ && + $prevline =~ /(?:^|[^=])=\s*$/) { + ERROR("that open brace { should be on the previous line\n" . $hereprev); + } + +# +# Checks which are anchored on the added line. +# + +# check for malformed paths in #include statements (uses RAW line) + if ($rawline =~ m{^.\s*\#\s*include\s+[<"](.*)[">]}) { + my $path = $1; + if ($path =~ m{//}) { + ERROR("malformed #include filename\n" . + $herecurr); + } + } + +# no C99 // comments + if ($line =~ m{//}) { + ERROR("do not use C99 // comments\n" . $herecurr); + } + # Remove C99 comments. + $line =~ s@//.*@@; + $opline =~ s@//.*@@; + +# EXPORT_SYMBOL should immediately follow the thing it is exporting, consider +# the whole statement. +#print "APW <$lines[$realline_next - 1]>\n"; + if (defined $realline_next && + exists $lines[$realline_next - 1] && + !defined $suppress_export{$realline_next} && + ($lines[$realline_next - 1] =~ /EXPORT_SYMBOL.*\((.*)\)/ || + $lines[$realline_next - 1] =~ /EXPORT_UNUSED_SYMBOL.*\((.*)\)/)) { + # Handle definitions which produce identifiers with + # a prefix: + # XXX(foo); + # EXPORT_SYMBOL(something_foo); + my $name = $1; + if ($stat =~ /^.([A-Z_]+)\s*\(\s*($Ident)/ && + $name =~ /^${Ident}_$2/) { +#print "FOO C name<$name>\n"; + $suppress_export{$realline_next} = 1; + + } elsif ($stat !~ /(?: + \n.}\s*$| + ^.DEFINE_$Ident\(\Q$name\E\)| + ^.DECLARE_$Ident\(\Q$name\E\)| + ^.LIST_HEAD\(\Q$name\E\)| + ^.(?:$Storage\s+)?$Type\s*\(\s*\*\s*\Q$name\E\s*\)\s*\(| + \b\Q$name\E(?:\s+$Attribute)*\s*(?:;|=|\[|\() + )/x) { +#print "FOO A<$lines[$realline_next - 1]> stat<$stat> name<$name>\n"; + $suppress_export{$realline_next} = 2; + } else { + $suppress_export{$realline_next} = 1; + } + } + if (!defined $suppress_export{$linenr} && + $prevline =~ /^.\s*$/ && + ($line =~ /EXPORT_SYMBOL.*\((.*)\)/ || + $line =~ /EXPORT_UNUSED_SYMBOL.*\((.*)\)/)) { +#print "FOO B <$lines[$linenr - 1]>\n"; + $suppress_export{$linenr} = 2; + } + if (defined $suppress_export{$linenr} && + $suppress_export{$linenr} == 2) { + WARN("EXPORT_SYMBOL(foo); should immediately follow its function/variable\n" . $herecurr); + } + +# check for global initialisers. + if ($line =~ /^.$Type\s*$Ident\s*(?:\s+$Modifier)*\s*=\s*(0|NULL|false)\s*;/) { + ERROR("do not initialise globals to 0 or NULL\n" . + $herecurr); + } +# check for static initialisers. + if ($line =~ /\bstatic\s.*=\s*(0|NULL|false)\s*;/) { + ERROR("do not initialise statics to 0 or NULL\n" . + $herecurr); + } + +# * goes on variable not on type + # (char*[ const]) + if ($line =~ m{\($NonptrType(\s*(?:$Modifier\b\s*|\*\s*)+)\)}) { + my ($from, $to) = ($1, $1); + + # Should start with a space. + $to =~ s/^(\S)/ $1/; + # Should not end with a space. + $to =~ s/\s+$//; + # '*'s should not have spaces between. + while ($to =~ s/\*\s+\*/\*\*/) { + } + + #print "from<$from> to<$to>\n"; + if ($from ne $to) { + ERROR("\"(foo$from)\" should be \"(foo$to)\"\n" . $herecurr); + } + } elsif ($line =~ m{\b$NonptrType(\s*(?:$Modifier\b\s*|\*\s*)+)($Ident)}) { + my ($from, $to, $ident) = ($1, $1, $2); + + # Should start with a space. + $to =~ s/^(\S)/ $1/; + # Should not end with a space. + $to =~ s/\s+$//; + # '*'s should not have spaces between. + while ($to =~ s/\*\s+\*/\*\*/) { + } + # Modifiers should have spaces. + $to =~ s/(\b$Modifier$)/$1 /; + + #print "from<$from> to<$to> ident<$ident>\n"; + if ($from ne $to && $ident !~ /^$Modifier$/) { + ERROR("\"foo${from}bar\" should be \"foo${to}bar\"\n" . $herecurr); + } + } + +# # no BUG() or BUG_ON() +# if ($line =~ /\b(BUG|BUG_ON)\b/) { +# print "Try to use WARN_ON & Recovery code rather than BUG() or BUG_ON()\n"; +# print "$herecurr"; +# $clean = 0; +# } + + if ($line =~ /\bLINUX_VERSION_CODE\b/) { + WARN("LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged\n" . $herecurr); + } + +# printk should use KERN_* levels. Note that follow on printk's on the +# same line do not need a level, so we use the current block context +# to try and find and validate the current printk. In summary the current +# printk includes all preceding printk's which have no newline on the end. +# we assume the first bad printk is the one to report. + if ($line =~ /\bprintk\((?!KERN_)\s*"/) { + my $ok = 0; + for (my $ln = $linenr - 1; $ln >= $first_line; $ln--) { + #print "CHECK<$lines[$ln - 1]\n"; + # we have a preceding printk if it ends + # with "\n" ignore it, else it is to blame + if ($lines[$ln - 1] =~ m{\bprintk\(}) { + if ($rawlines[$ln - 1] !~ m{\\n"}) { + $ok = 1; + } + last; + } + } + if ($ok == 0) { + WARN("printk() should include KERN_ facility level\n" . $herecurr); + } + } + +# function brace can't be on same line, except for #defines of do while, +# or if closed on same line + if (($line=~/$Type\s*$Ident\(.*\).*\s{/) and + !($line=~/\#\s*define.*do\s{/) and !($line=~/}/)) { + ERROR("open brace '{' following function declarations go on the next line\n" . $herecurr); + } + +# open braces for enum, union and struct go on the same line. + if ($line =~ /^.\s*{/ && + $prevline =~ /^.\s*(?:typedef\s+)?(enum|union|struct)(?:\s+$Ident)?\s*$/) { + ERROR("open brace '{' following $1 go on the same line\n" . $hereprev); + } + +# missing space after union, struct or enum definition + if ($line =~ /^.\s*(?:typedef\s+)?(enum|union|struct)(?:\s+$Ident)?(?:\s+$Ident)?[=\{]/) { + WARN("missing space after $1 definition\n" . $herecurr); + } + +# check for spacing round square brackets; allowed: +# 1. with a type on the left -- int [] a; +# 2. at the beginning of a line for slice initialisers -- [0...10] = 5, +# 3. inside a curly brace -- = { [0...10] = 5 } + while ($line =~ /(.*?\s)\[/g) { + my ($where, $prefix) = ($-[1], $1); + if ($prefix !~ /$Type\s+$/ && + ($where != 0 || $prefix !~ /^.\s+$/) && + $prefix !~ /{\s+$/) { + ERROR("space prohibited before open square bracket '['\n" . $herecurr); + } + } + +# check for spaces between functions and their parentheses. + while ($line =~ /($Ident)\s+\(/g) { + my $name = $1; + my $ctx_before = substr($line, 0, $-[1]); + my $ctx = "$ctx_before$name"; + + # Ignore those directives where spaces _are_ permitted. + if ($name =~ /^(?: + if|for|while|switch|return|case| + volatile|__volatile__| + __attribute__|format|__extension__| + asm|__asm__)$/x) + { + + # cpp #define statements have non-optional spaces, ie + # if there is a space between the name and the open + # parenthesis it is simply not a parameter group. + } elsif ($ctx_before =~ /^.\s*\#\s*define\s*$/) { + + # cpp #elif statement condition may start with a ( + } elsif ($ctx =~ /^.\s*\#\s*elif\s*$/) { + + # If this whole things ends with a type its most + # likely a typedef for a function. + } elsif ($ctx =~ /$Type$/) { + + } else { + WARN("space prohibited between function name and open parenthesis '('\n" . $herecurr); + } + } +# Check operator spacing. + if (!($line=~/\#\s*include/)) { + my $ops = qr{ + <<=|>>=|<=|>=|==|!=| + \+=|-=|\*=|\/=|%=|\^=|\|=|&=| + =>|->|<<|>>|<|>|=|!|~| + &&|\|\||,|\^|\+\+|--|&|\||\+|-|\*|\/|%| + \?|: + }x; + my @elements = split(/($ops|;)/, $opline); + my $off = 0; + + my $blank = copy_spacing($opline); + + for (my $n = 0; $n < $#elements; $n += 2) { + $off += length($elements[$n]); + + # Pick up the preceding and succeeding characters. + my $ca = substr($opline, 0, $off); + my $cc = ''; + if (length($opline) >= ($off + length($elements[$n + 1]))) { + $cc = substr($opline, $off + length($elements[$n + 1])); + } + my $cb = "$ca$;$cc"; + + my $a = ''; + $a = 'V' if ($elements[$n] ne ''); + $a = 'W' if ($elements[$n] =~ /\s$/); + $a = 'C' if ($elements[$n] =~ /$;$/); + $a = 'B' if ($elements[$n] =~ /(\[|\()$/); + $a = 'O' if ($elements[$n] eq ''); + $a = 'E' if ($ca =~ /^\s*$/); + + my $op = $elements[$n + 1]; + + my $c = ''; + if (defined $elements[$n + 2]) { + $c = 'V' if ($elements[$n + 2] ne ''); + $c = 'W' if ($elements[$n + 2] =~ /^\s/); + $c = 'C' if ($elements[$n + 2] =~ /^$;/); + $c = 'B' if ($elements[$n + 2] =~ /^(\)|\]|;)/); + $c = 'O' if ($elements[$n + 2] eq ''); + $c = 'E' if ($elements[$n + 2] =~ /^\s*\\$/); + } else { + $c = 'E'; + } + + my $ctx = "${a}x${c}"; + + my $at = "(ctx:$ctx)"; + + my $ptr = substr($blank, 0, $off) . "^"; + my $hereptr = "$hereline$ptr\n"; + + # Pull out the value of this operator. + my $op_type = substr($curr_values, $off + 1, 1); + + # Get the full operator variant. + my $opv = $op . substr($curr_vars, $off, 1); + + # Ignore operators passed as parameters. + if ($op_type ne 'V' && + $ca =~ /\s$/ && $cc =~ /^\s*,/) { + +# # Ignore comments +# } elsif ($op =~ /^$;+$/) { + + # ; should have either the end of line or a space or \ after it + } elsif ($op eq ';') { + if ($ctx !~ /.x[WEBC]/ && + $cc !~ /^\\/ && $cc !~ /^;/) { + ERROR("space required after that '$op' $at\n" . $hereptr); + } + + # // is a comment + } elsif ($op eq '//') { + + # No spaces for: + # -> + # : when part of a bitfield + } elsif ($op eq '->' || $opv eq ':B') { + if ($ctx =~ /Wx.|.xW/) { + ERROR("spaces prohibited around that '$op' $at\n" . $hereptr); + } + + # , must have a space on the right. + # not required when having a single },{ on one line + } elsif ($op eq ',') { + if ($ctx !~ /.x[WEC]/ && $cc !~ /^}/ && + ($elements[$n] . $elements[$n + 2]) !~ " *}{") { + ERROR("space required after that '$op' $at\n" . $hereptr); + } + + # '*' as part of a type definition -- reported already. + } elsif ($opv eq '*_') { + #warn "'*' is part of type\n"; + + # unary operators should have a space before and + # none after. May be left adjacent to another + # unary operator, or a cast + } elsif ($op eq '!' || $op eq '~' || + $opv eq '*U' || $opv eq '-U' || + $opv eq '&U' || $opv eq '&&U') { + if ($ctx !~ /[WEBC]x./ && $ca !~ /(?:\)|!|~|\*|-|\&|\||\+\+|\-\-|\{)$/) { + ERROR("space required before that '$op' $at\n" . $hereptr); + } + if ($op eq '*' && $cc =~/\s*$Modifier\b/) { + # A unary '*' may be const + + } elsif ($ctx =~ /.xW/) { + ERROR("space prohibited after that '$op' $at\n" . $hereptr); + } + + # unary ++ and unary -- are allowed no space on one side. + } elsif ($op eq '++' or $op eq '--') { + if ($ctx !~ /[WEOBC]x[^W]/ && $ctx !~ /[^W]x[WOBEC]/) { + ERROR("space required one side of that '$op' $at\n" . $hereptr); + } + if ($ctx =~ /Wx[BE]/ || + ($ctx =~ /Wx./ && $cc =~ /^;/)) { + ERROR("space prohibited before that '$op' $at\n" . $hereptr); + } + if ($ctx =~ /ExW/) { + ERROR("space prohibited after that '$op' $at\n" . $hereptr); + } + + + # << and >> may either have or not have spaces both sides + } elsif ($op eq '<<' or $op eq '>>' or + $op eq '&' or $op eq '^' or $op eq '|' or + $op eq '+' or $op eq '-' or + $op eq '/' or $op eq '%') + { + if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) { + ERROR("need consistent spacing around '$op' $at\n" . + $hereptr); + } + + # A colon needs no spaces before when it is + # terminating a case value or a label. + } elsif ($opv eq ':C' || $opv eq ':L') { + if ($ctx =~ /Wx./) { + ERROR("space prohibited before that '$op' $at\n" . $hereptr); + } + + # All the others need spaces both sides. + } elsif ($ctx !~ /[EWC]x[CWE]/ && $opv ne '*B') { + my $ok = 0; + + # Ignore email addresses + if (($op eq '<' && + $cc =~ /^\S+\@\S+>/) || + ($op eq '>' && + $ca =~ /<\S+\@\S+$/)) + { + $ok = 1; + } + + # Ignore ?: + if (($opv eq ':O' && $ca =~ /\?$/) || + ($op eq '?' && $cc =~ /^:/)) { + $ok = 1; + } + + if ($ok == 0) { + ERROR("spaces required around that '$op' $at\n" . $hereptr); + } + } + $off += length($elements[$n + 1]); + } + } + +# check for multiple assignments + if ($line =~ /^.\s*$Lval\s*=\s*$Lval\s*=(?!=)/) { + CHK("multiple assignments should be avoided\n" . $herecurr); + } + +## # check for multiple declarations, allowing for a function declaration +## # continuation. +## if ($line =~ /^.\s*$Type\s+$Ident(?:\s*=[^,{]*)?\s*,\s*$Ident.*/ && +## $line !~ /^.\s*$Type\s+$Ident(?:\s*=[^,{]*)?\s*,\s*$Type\s*$Ident.*/) { +## +## # Remove any bracketed sections to ensure we do not +## # falsly report the parameters of functions. +## my $ln = $line; +## while ($ln =~ s/\([^\(\)]*\)//g) { +## } +## if ($ln =~ /,/) { +## WARN("declaring multiple variables together should be avoided\n" . $herecurr); +## } +## } + +#need space before brace following if, while, etc + if (($line =~ /\(.*\){/ && $line !~ /\($Type\){/) || + $line =~ /do{/) { + ERROR("space required before the open brace '{'\n" . $herecurr); + } + +# closing brace should have a space following it when it has anything +# on the line + if ($line =~ /}(?!(?:,|;|\)))\S/) { + ERROR("space required after that close brace '}'\n" . $herecurr); + } + +# check spacing on square brackets + if ($line =~ /\[\s/ && $line !~ /\[\s*$/) { + ERROR("space prohibited after that open square bracket '['\n" . $herecurr); + } + if ($line =~ /\s\]/) { + ERROR("space prohibited before that close square bracket ']'\n" . $herecurr); + } + +# check spacing on parentheses + if ($line =~ /\(\s/ && $line !~ /\(\s*(?:\\)?$/ && + $line !~ /for\s*\(\s+;/) { + ERROR("space prohibited after that open parenthesis '('\n" . $herecurr); + } + if ($line =~ /(\s+)\)/ && $line !~ /^.\s*\)/ && + $line !~ /for\s*\(.*;\s+\)/ && + $line !~ /:\s+\)/) { + ERROR("space prohibited before that close parenthesis ')'\n" . $herecurr); + } + +# Return is not a function. + if (defined($stat) && $stat =~ /^.\s*return(\s*)(\(.*);/s) { + my $spacing = $1; + my $value = $2; + + # Flatten any parentheses + $value =~ s/\(/ \(/g; + $value =~ s/\)/\) /g; + while ($value =~ s/\[[^\{\}]*\]/1/ || + $value !~ /(?:$Ident|-?$Constant)\s* + $Compare\s* + (?:$Ident|-?$Constant)/x && + $value =~ s/\([^\(\)]*\)/1/) { + } +#print "value<$value>\n"; + if ($value =~ /^\s*(?:$Ident|-?$Constant)\s*$/) { + ERROR("return is not a function, parentheses are not required\n" . $herecurr); + + } elsif ($spacing !~ /\s+/) { + ERROR("space required before the open parenthesis '('\n" . $herecurr); + } + } +# Return of what appears to be an errno should normally be -'ve + if ($line =~ /^.\s*return\s*(E[A-Z]*)\s*;/) { + my $name = $1; + if ($name ne 'EOF' && $name ne 'ERROR') { + CHK("return of an errno should typically be -ve (return -$1)\n" . $herecurr); + } + } + +# Need a space before open parenthesis after if, while etc + if ($line=~/\b(if|while|for|switch)\(/) { + ERROR("space required before the open parenthesis '('\n" . $herecurr); + } + +# Check for illegal assignment in if conditional -- and check for trailing +# statements after the conditional. + if ($line =~ /do\s*(?!{)/) { + my ($stat_next) = ctx_statement_block($line_nr_next, + $remain_next, $off_next); + $stat_next =~ s/\n./\n /g; + ##print "stat<$stat> stat_next<$stat_next>\n"; + + if ($stat_next =~ /^\s*while\b/) { + # If the statement carries leading newlines, + # then count those as offsets. + my ($whitespace) = + ($stat_next =~ /^((?:\s*\n[+-])*\s*)/s); + my $offset = + statement_rawlines($whitespace) - 1; + + $suppress_whiletrailers{$line_nr_next + + $offset} = 1; + } + } + if (!defined $suppress_whiletrailers{$linenr} && + $line =~ /\b(?:if|while|for)\s*\(/ && $line !~ /^.\s*#/) { + my ($s, $c) = ($stat, $cond); + + if ($c =~ /\bif\s*\(.*[^<>!=]=[^=].*/s) { + ERROR("do not use assignment in if condition\n" . $herecurr); + } + + # Find out what is on the end of the line after the + # conditional. + substr($s, 0, length($c), ''); + $s =~ s/\n.*//g; + $s =~ s/$;//g; # Remove any comments + if (length($c) && $s !~ /^\s*{?\s*\\*\s*$/ && + $c !~ /}\s*while\s*/ && length($s) == 1) + { + # Find out how long the conditional actually is. + my @newlines = ($c =~ /\n/gs); + my $cond_lines = 1 + $#newlines; + my $stat_real = ''; + + $stat_real = raw_line($linenr, $cond_lines) + . "\n" if ($cond_lines); + if (defined($stat_real) && $cond_lines > 1) { + $stat_real = "[...]\n$stat_real"; + } + + ERROR("trailing statements should be on next line\n" . $herecurr . $stat_real); + } + } + +# Check for bitwise tests written as boolean + if ($line =~ / + (?: + (?:\[|\(|\&\&|\|\|) + \s*0[xX][0-9]+\s* + (?:\&\&|\|\|) + | + (?:\&\&|\|\|) + \s*0[xX][0-9]+\s* + (?:\&\&|\|\||\)|\]) + )/x) + { + WARN("boolean test with hexadecimal, perhaps just 1 \& or \|?\n" . $herecurr); + } + +# if and else should not have general statements after it + if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/) { + my $s = $1; + $s =~ s/$;//g; # Remove any comments + if ($s !~ /^\s*(?:\sif|(?:{|)\s*\\?\s*$)/) { + ERROR("trailing statements should be on next line\n" . $herecurr); + } + } +# if should not continue a brace + if ($line =~ /}\s*if\b/) { + ERROR("trailing statements should be on next line\n" . + $herecurr); + } +# case and default should not have general statements after them + if ($line =~ /^.\s*(?:case\s*.*|default\s*):/g && + $line !~ /\G(?: + (?:\s*$;*)(?:\s*{)?(?:\s*$;*)(?:\s*\\)?\s*$| + \s*return\s+ + )/xg) + { + ERROR("trailing statements should be on next line\n" . $herecurr); + } + + # Check for }else {, these must be at the same + # indent level to be relevant to each other. + if ($prevline=~/}\s*$/ and $line=~/^.\s*else\s*/ and + $previndent == $indent) { + ERROR("else should follow close brace '}'\n" . $hereprev); + } + + if ($prevline=~/}\s*$/ and $line=~/^.\s*while\s*/ and + $previndent == $indent) { + my ($s, $c) = ctx_statement_block($linenr, $realcnt, 0); + + # Find out what is on the end of the line after the + # conditional. + substr($s, 0, length($c), ''); + $s =~ s/\n.*//g; + + if ($s =~ /^\s*;/) { + ERROR("while should follow close brace '}'\n" . $hereprev); + } + } + +#studly caps, commented out until figure out how to distinguish between use of existing and adding new +# if (($line=~/[\w_][a-z\d]+[A-Z]/) and !($line=~/print/)) { +# print "No studly caps, use _\n"; +# print "$herecurr"; +# $clean = 0; +# } + +#no spaces allowed after \ in define + if ($line=~/\#\s*define.*\\\s$/) { + WARN("Whitepspace after \\ makes next lines useless\n" . $herecurr); + } + +#warn if is #included and is available (uses RAW line) + if ($tree && $rawline =~ m{^.\s*\#\s*include\s*\}) { + my $file = "$1.h"; + my $checkfile = "include/linux/$file"; + if (-f "$root/$checkfile" && + $realfile ne $checkfile && + $1 !~ /$allowed_asm_includes/) + { + if ($realfile =~ m{^arch/}) { + CHK("Consider using #include instead of \n" . $herecurr); + } else { + WARN("Use #include instead of \n" . $herecurr); + } + } + } + +# multi-statement macros should be enclosed in a do while loop, grab the +# first statement and ensure its the whole macro if its not enclosed +# in a known good container + if ($realfile !~ m@/vmlinux.lds.h$@ && + $line =~ /^.\s*\#\s*define\s*$Ident(\()?/) { + my $ln = $linenr; + my $cnt = $realcnt; + my ($off, $dstat, $dcond, $rest); + my $ctx = ''; + + my $args = defined($1); + + # Find the end of the macro and limit our statement + # search to that. + while ($cnt > 0 && defined $lines[$ln - 1] && + $lines[$ln - 1] =~ /^(?:-|..*\\$)/) + { + $ctx .= $rawlines[$ln - 1] . "\n"; + $cnt-- if ($lines[$ln - 1] !~ /^-/); + $ln++; + } + $ctx .= $rawlines[$ln - 1]; + + ($dstat, $dcond, $ln, $cnt, $off) = + ctx_statement_block($linenr, $ln - $linenr + 1, 0); + #print "dstat<$dstat> dcond<$dcond> cnt<$cnt> off<$off>\n"; + #print "LINE<$lines[$ln-1]> len<" . length($lines[$ln-1]) . "\n"; + + # Extract the remainder of the define (if any) and + # rip off surrounding spaces, and trailing \'s. + $rest = ''; + while ($off != 0 || ($cnt > 0 && $rest =~ /\\\s*$/)) { + #print "ADDING cnt<$cnt> $off <" . substr($lines[$ln - 1], $off) . "> rest<$rest>\n"; + if ($off != 0 || $lines[$ln - 1] !~ /^-/) { + $rest .= substr($lines[$ln - 1], $off) . "\n"; + $cnt--; + } + $ln++; + $off = 0; + } + $rest =~ s/\\\n.//g; + $rest =~ s/^\s*//s; + $rest =~ s/\s*$//s; + + # Clean up the original statement. + if ($args) { + substr($dstat, 0, length($dcond), ''); + } else { + $dstat =~ s/^.\s*\#\s*define\s+$Ident\s*//; + } + $dstat =~ s/$;//g; + $dstat =~ s/\\\n.//g; + $dstat =~ s/^\s*//s; + $dstat =~ s/\s*$//s; + + # Flatten any parentheses and braces + while ($dstat =~ s/\([^\(\)]*\)/1/ || + $dstat =~ s/\{[^\{\}]*\}/1/ || + $dstat =~ s/\[[^\{\}]*\]/1/) + { + } + + my $exceptions = qr{ + $Declare| + module_param_named| + MODULE_PARAM_DESC| + DECLARE_PER_CPU| + DEFINE_PER_CPU| + __typeof__\(| + union| + struct| + \.$Ident\s*=\s*| + ^\"|\"$ + }x; + #print "REST<$rest> dstat<$dstat> ctx<$ctx>\n"; + if ($rest ne '' && $rest ne ',') { + if ($rest !~ /while\s*\(/ && + $dstat !~ /$exceptions/) + { + ERROR("Macros with multiple statements should be enclosed in a do - while loop\n" . "$here\n$ctx\n"); + } + + } elsif ($ctx !~ /;/) { + if ($dstat ne '' && + $dstat !~ /^(?:$Ident|-?$Constant)$/ && + $dstat !~ /$exceptions/ && + $dstat !~ /^\.$Ident\s*=/ && + $dstat =~ /$Operators/) + { + ERROR("Macros with complex values should be enclosed in parenthesis\n" . "$here\n$ctx\n"); + } + } + } + +# make sure symbols are always wrapped with VMLINUX_SYMBOL() ... +# all assignments may have only one of the following with an assignment: +# . +# ALIGN(...) +# VMLINUX_SYMBOL(...) + if ($realfile eq 'vmlinux.lds.h' && $line =~ /(?:(?:^|\s)$Ident\s*=|=\s*$Ident(?:\s|$))/) { + WARN("vmlinux.lds.h needs VMLINUX_SYMBOL() around C-visible symbols\n" . $herecurr); + } + +# check for missing bracing round if etc + if ($line =~ /(^.*)\bif\b/ && $line !~ /\#\s*if/) { + my ($level, $endln, @chunks) = + ctx_statement_full($linenr, $realcnt, 1); + #print "chunks<$#chunks> linenr<$linenr> endln<$endln> level<$level>\n"; + #print "APW: <<$chunks[1][0]>><<$chunks[1][1]>>\n"; + if ($#chunks >= 0 && $level == 0) { + my $allowed = 0; + my $seen = 0; + my $herectx = $here . "\n"; + my $ln = $linenr - 1; + for my $chunk (@chunks) { + my ($cond, $block) = @{$chunk}; + + # If the condition carries leading newlines, then count those as offsets. + my ($whitespace) = ($cond =~ /^((?:\s*\n[+-])*\s*)/s); + my $offset = statement_rawlines($whitespace) - 1; + + #print "COND<$cond> whitespace<$whitespace> offset<$offset>\n"; + + # We have looked at and allowed this specific line. + $suppress_ifbraces{$ln + $offset} = 1; + + $herectx .= "$rawlines[$ln + $offset]\n[...]\n"; + $ln += statement_rawlines($block) - 1; + + substr($block, 0, length($cond), ''); + $seen++ if ($block =~ /^\s*{/ || $block =~ /;{1,1}/); + + #print "cond<$cond> block<$block> allowed<$allowed>\n"; + if (statement_lines($cond) > 1) { + #print "APW: ALLOWED: cond<$cond>\n"; + $allowed = 1; + } + if ($block =~/\b(?:if|for|while)\b/) { + #print "APW: ALLOWED: block<$block>\n"; + $allowed = 1; + } + if (statement_block_size($block) > 1) { + #print "APW: ALLOWED: lines block<$block>\n"; + $allowed = 1; + } + } + #print "seen: $seen\nchunks: $#chunks\nln: $ln\nlinenr: $linenr\n"; + if ($seen != ($#chunks + 1)) { + WARN("braces {} are necessary for all arms of this statement\n" . $herectx); + } + } + } + if (!defined $suppress_ifbraces{$linenr - 1} && + $line =~ /\b(if|while|for|else)\b/ && + $line !~ /\#\s*if/ && + $line !~ /\#\s*else/) { + my $allowed = 0; + + # Check the pre-context. + if (substr($line, 0, $-[0]) =~ /(\}\s*)$/) { + #print "APW: ALLOWED: pre<$1>\n"; + $allowed = 1; + } + + my ($level, $endln, @chunks) = + ctx_statement_full($linenr, $realcnt, $-[0]); + + # Check the condition. + my ($cond, $block) = @{$chunks[0]}; + #print "CHECKING<$linenr> cond<$cond> block<$block>\n"; + if (defined $cond) { + substr($block, 0, length($cond), ''); + } + if (statement_lines($cond) > 1) { + #print "APW: ALLOWED: cond<$cond>\n"; + $allowed = 1; + } + if ($block =~/\b(?:if|for|while)\b/) { + #print "APW: ALLOWED: block<$block>\n"; + $allowed = 1; + } + if (statement_block_size($block) > 1) { + #print "APW: ALLOWED: lines block<$block>\n"; + $allowed = 1; + } + # Check the post-context. + if (defined $chunks[1]) { + my ($cond, $block) = @{$chunks[1]}; + if (defined $cond) { + substr($block, 0, length($cond), ''); + } + if ($block =~ /^\s*\{/) { + #print "APW: ALLOWED: chunk-1 block<$block>\n"; + $allowed = 1; + } + } + if ($level == 0 && $block !~ /^\s*\{/ && !$allowed) { + my $herectx = $here . "\n";; + my $cnt = statement_rawlines($block); + + for (my $n = 0; $n < $cnt; $n++) { + $herectx .= raw_line($linenr, $n) . "\n";; + } + + WARN("braces {} are necessary even for single statement blocks\n" . $herectx); + } + } + +# don't include deprecated include files (uses RAW line) + for my $inc (@dep_includes) { + if ($rawline =~ m@^.\s*\#\s*include\s*\<$inc>@) { + ERROR("Don't use <$inc>: see Documentation/feature-removal-schedule.txt\n" . $herecurr); + } + } + +# don't use deprecated functions + for my $func (@dep_functions) { + if ($line =~ /\b$func\b/) { + ERROR("Don't use $func(): see Documentation/feature-removal-schedule.txt\n" . $herecurr); + } + } + +# no volatiles please + my $asm_volatile = qr{\b(__asm__|asm)\s+(__volatile__|volatile)\b}; + if ($line =~ /\bvolatile\b/ && $line !~ /$asm_volatile/) { + WARN("Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt\n" . $herecurr); + } + +# SPIN_LOCK_UNLOCKED & RW_LOCK_UNLOCKED are deprecated + if ($line =~ /\b(SPIN_LOCK_UNLOCKED|RW_LOCK_UNLOCKED)/) { + ERROR("Use of $1 is deprecated: see Documentation/spinlocks.txt\n" . $herecurr); + } + +# warn about #if 0 + if ($line =~ /^.\s*\#\s*if\s+0\b/) { + CHK("if this code is redundant consider removing it\n" . + $herecurr); + } + +# check for needless kfree() checks + if ($prevline =~ /\bif\s*\(([^\)]*)\)/) { + my $expr = $1; + if ($line =~ /\bkfree\(\Q$expr\E\);/) { + WARN("kfree(NULL) is safe this check is probably not required\n" . $hereprev); + } + } +# check for needless usb_free_urb() checks + if ($prevline =~ /\bif\s*\(([^\)]*)\)/) { + my $expr = $1; + if ($line =~ /\busb_free_urb\(\Q$expr\E\);/) { + WARN("usb_free_urb(NULL) is safe this check is probably not required\n" . $hereprev); + } + } + +# prefer usleep_range over udelay + if ($line =~ /\budelay\s*\(\s*(\w+)\s*\)/) { + # ignore udelay's < 10, however + if (! (($1 =~ /(\d+)/) && ($1 < 10)) ) { + CHK("usleep_range is preferred over udelay; see Documentation/timers/timers-howto.txt\n" . $line); + } + } + +# warn about unexpectedly long msleep's + if ($line =~ /\bmsleep\s*\((\d+)\);/) { + if ($1 < 20) { + WARN("msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt\n" . $line); + } + } + +# warn about #ifdefs in C files +# if ($line =~ /^.\s*\#\s*if(|n)def/ && ($realfile =~ /\.c$/)) { +# print "#ifdef in C files should be avoided\n"; +# print "$herecurr"; +# $clean = 0; +# } + +# warn about spacing in #ifdefs + if ($line =~ /^.\s*\#\s*(ifdef|ifndef|elif)\s\s+/) { + ERROR("exactly one space required after that #$1\n" . $herecurr); + } + +# check for spinlock_t definitions without a comment. + if ($line =~ /^.\s*(struct\s+mutex|spinlock_t)\s+\S+;/ || + $line =~ /^.\s*(DEFINE_MUTEX)\s*\(/) { + my $which = $1; + if (!ctx_has_comment($first_line, $linenr)) { + CHK("$1 definition without comment\n" . $herecurr); + } + } +# check for memory barriers without a comment. + if ($line =~ /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/) { + if (!ctx_has_comment($first_line, $linenr)) { + CHK("memory barrier without comment\n" . $herecurr); + } + } +# check of hardware specific defines + if ($line =~ m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ m@include/asm-@) { + CHK("architecture specific defines should be avoided\n" . $herecurr); + } + +# Check that the storage class is at the beginning of a declaration + if ($line =~ /\b$Storage\b/ && $line !~ /^.\s*$Storage\b/) { + WARN("storage class should be at the beginning of the declaration\n" . $herecurr) + } + +# check the location of the inline attribute, that it is between +# storage class and type. + if ($line =~ /\b$Type\s+$Inline\b/ || + $line =~ /\b$Inline\s+$Storage\b/) { + ERROR("inline keyword should sit between storage class and type\n" . $herecurr); + } + +# Check for __inline__ and __inline, prefer inline + if ($line =~ /\b(__inline__|__inline)\b/) { + WARN("plain inline is preferred over $1\n" . $herecurr); + } + +# check for sizeof(&) + if ($line =~ /\bsizeof\s*\(\s*\&/) { + WARN("sizeof(& should be avoided\n" . $herecurr); + } + +# check for new externs in .c files. + if ($realfile =~ /\.c$/ && defined $stat && + $stat =~ /^.\s*(?:extern\s+)?$Type\s+($Ident)(\s*)\(/s) + { + my $function_name = $1; + my $paren_space = $2; + + my $s = $stat; + if (defined $cond) { + substr($s, 0, length($cond), ''); + } + if ($s =~ /^\s*;/ && + $function_name ne 'uninitialized_var') + { + WARN("externs should be avoided in .c files\n" . $herecurr); + } + + if ($paren_space =~ /\n/) { + WARN("arguments for function declarations should follow identifier\n" . $herecurr); + } + + } elsif ($realfile =~ /\.c$/ && defined $stat && + $stat =~ /^.\s*extern\s+/) + { + WARN("externs should be avoided in .c files\n" . $herecurr); + } + +# checks for new __setup's + if ($rawline =~ /\b__setup\("([^"]*)"/) { + my $name = $1; + + if (!grep(/$name/, @setup_docs)) { + CHK("__setup appears un-documented -- check Documentation/kernel-parameters.txt\n" . $herecurr); + } + } + +# check for pointless casting of kmalloc return + if ($line =~ /\*\s*\)\s*k[czm]alloc\b/) { + WARN("unnecessary cast may hide bugs, see http://c-faq.com/malloc/mallocnocast.html\n" . $herecurr); + } + +# check for gcc specific __FUNCTION__ + if ($line =~ /__FUNCTION__/) { + WARN("__func__ should be used instead of gcc specific __FUNCTION__\n" . $herecurr); + } + +# check for semaphores used as mutexes + if ($line =~ /^.\s*(DECLARE_MUTEX|init_MUTEX)\s*\(/) { + WARN("mutexes are preferred for single holder semaphores\n" . $herecurr); + } +# check for semaphores used as mutexes + if ($line =~ /^.\s*init_MUTEX_LOCKED\s*\(/) { + WARN("consider using a completion\n" . $herecurr); + + } +# recommend strict_strto* over simple_strto* + if ($line =~ /\bsimple_(strto.*?)\s*\(/) { + WARN("consider using strict_$1 in preference to simple_$1\n" . $herecurr); + } +# check for __initcall(), use device_initcall() explicitly please + if ($line =~ /^.\s*__initcall\s*\(/) { + WARN("please use device_initcall() instead of __initcall()\n" . $herecurr); + } +# check for various ops structs, ensure they are const. + my $struct_ops = qr{acpi_dock_ops| + address_space_operations| + backlight_ops| + block_device_operations| + dentry_operations| + dev_pm_ops| + dma_map_ops| + extent_io_ops| + file_lock_operations| + file_operations| + hv_ops| + ide_dma_ops| + intel_dvo_dev_ops| + item_operations| + iwl_ops| + kgdb_arch| + kgdb_io| + kset_uevent_ops| + lock_manager_operations| + microcode_ops| + mtrr_ops| + neigh_ops| + nlmsvc_binding| + pci_raw_ops| + pipe_buf_operations| + platform_hibernation_ops| + platform_suspend_ops| + proto_ops| + rpc_pipe_ops| + seq_operations| + snd_ac97_build_ops| + soc_pcmcia_socket_ops| + stacktrace_ops| + sysfs_ops| + tty_operations| + usb_mon_operations| + wd_ops}x; + if ($line !~ /\bconst\b/ && + $line =~ /\bstruct\s+($struct_ops)\b/) { + WARN("struct $1 should normally be const\n" . + $herecurr); + } + +# use of NR_CPUS is usually wrong +# ignore definitions of NR_CPUS and usage to define arrays as likely right + if ($line =~ /\bNR_CPUS\b/ && + $line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ && + $line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ && + $line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ && + $line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ && + $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/) + { + WARN("usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr); + } + +# check for %L{u,d,i} in strings + my $string; + while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) { + $string = substr($rawline, $-[1], $+[1] - $-[1]); + $string =~ s/%%/__/g; + if ($string =~ /(?mutex.\n" . $herecurr); + } + } + } + + # If we have no input at all, then there is nothing to report on + # so just keep quiet. + if ($#rawlines == -1) { + exit(0); + } + + # In mailback mode only produce a report in the negative, for + # things that appear to be patches. + if ($mailback && ($clean == 1 || !$is_patch)) { + exit(0); + } + + # This is not a patch, and we are are in 'no-patch' mode so + # just keep quiet. + if (!$chk_patch && !$is_patch) { + exit(0); + } + + if (!$is_patch) { + ERROR("Does not appear to be a unified-diff format patch\n"); + } + if ($is_patch && $chk_signoff && $signoff == 0) { + ERROR("Missing Signed-off-by: line(s)\n"); + } + + print report_dump(); + if ($summary && !($clean == 1 && $quiet == 1)) { + print "$filename " if ($summary_file); + print "total: $cnt_error errors, $cnt_warn warnings, " . + (($check)? "$cnt_chk checks, " : "") . + "$cnt_lines lines checked\n"; + print "\n" if ($quiet == 0); + } + + if ($quiet == 0) { + # If there were whitespace errors which cleanpatch can fix + # then suggest that. +# if ($rpt_cleaners) { +# print "NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or\n"; +# print " scripts/cleanfile\n\n"; +# } + } + + if ($clean == 1 && $quiet == 0) { + print "$vname has no obvious style problems and is ready for submission.\n" + } + if ($clean == 0 && $quiet == 0) { + print "$vname has style problems, please review. If any of these errors\n"; + print "are false positives report them to the maintainer, see\n"; + print "CHECKPATCH in MAINTAINERS.\n"; + } + + return $clean; +} -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:53:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSrg-0002rU-Ff; Thu, 10 May 2012 12:53:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSrf-0002rN-4g for xen-devel@lists.xen.org; Thu, 10 May 2012 12:53:03 +0000 Received: from [85.158.143.35:51190] by server-1.bemta-4.messagelabs.com id 59/87-20925-E2ABBAF4; Thu, 10 May 2012 12:53:02 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336654378!13388409!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19033 invoked from network); 10 May 2012 12:52:59 -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 May 2012 12:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12405548" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:52: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, 10 May 2012 13:52:57 +0100 Date: Thu, 10 May 2012 13:52:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> Message-ID: References: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] qemu xen_disk mis-accounting? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > ioreq_release() gets called from two places, yet only in the > blk_send_response_all() case does it appear appropriate to decrement > blkdev->requests_finished. In the error handling path of > blk_handle_requests() I would think it should decrement > blkdev->requests_inflight instead. > > While blkdev->requests_finished isn't being used anywhere, > blkdev->requests_inflight serves blk_handle_requests() to tell > whether to call qemu_bh_schedule(), so this isn't a purely cosmetic > mistake afaics (and the error path in question is actually being > consistently exercised by our frontends probing for the packet > command extension - yes, it should have been implemented via > xenstore node presence, but the author failed to do so back then). The error handling path of blk_handle_requests() should definitely decrement blkdev->requests_inflight for the reasons you mentioned, but it should also call ioreq_release(), because otherwise blk_send_response_all could call blk_send_response_one on the ioreq that wasn't parsed correctly. Could you please submit a patch to add blkdev->requests_inflight-- in the right place? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 12:53:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 12: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 ) id 1SSSrg-0002rU-Ff; Thu, 10 May 2012 12:53:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSrf-0002rN-4g for xen-devel@lists.xen.org; Thu, 10 May 2012 12:53:03 +0000 Received: from [85.158.143.35:51190] by server-1.bemta-4.messagelabs.com id 59/87-20925-E2ABBAF4; Thu, 10 May 2012 12:53:02 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336654378!13388409!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19033 invoked from network); 10 May 2012 12:52:59 -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 May 2012 12:52:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12405548" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:52: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, 10 May 2012 13:52:57 +0100 Date: Thu, 10 May 2012 13:52:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> Message-ID: References: <4FAB8F1D0200007800082A79@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] qemu xen_disk mis-accounting? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > ioreq_release() gets called from two places, yet only in the > blk_send_response_all() case does it appear appropriate to decrement > blkdev->requests_finished. In the error handling path of > blk_handle_requests() I would think it should decrement > blkdev->requests_inflight instead. > > While blkdev->requests_finished isn't being used anywhere, > blkdev->requests_inflight serves blk_handle_requests() to tell > whether to call qemu_bh_schedule(), so this isn't a purely cosmetic > mistake afaics (and the error path in question is actually being > consistently exercised by our frontends probing for the packet > command extension - yes, it should have been implemented via > xenstore node presence, but the author failed to do so back then). The error handling path of blk_handle_requests() should definitely decrement blkdev->requests_inflight for the reasons you mentioned, but it should also call ioreq_release(), because otherwise blk_send_response_all could call blk_send_response_one on the ioreq that wasn't parsed correctly. Could you please submit a patch to add blkdev->requests_inflight-- in the right place? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:01:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:01:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSzY-000394-JX; Thu, 10 May 2012 13:01:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSzW-00038w-8W for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:01:10 +0000 Received: from [85.158.138.51:48055] by server-8.bemta-3.messagelabs.com id C0/7B-24428-51CBBAF4; Thu, 10 May 2012 13:01:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336654868!17426877!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1274 invoked from network); 10 May 2012 13:01:09 -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; 10 May 2012 13:01:09 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12405815" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:01: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, 10 May 2012 14:01:08 +0100 Message-ID: <1336654867.7098.118.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen.org , Keir Fraser , "Olaf Hering" Date: Thu, 10 May 2012 14:01:07 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > flight 12828 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386 4 xen-build fail REGR. vs. 12827 gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c cc1: warnings being treated as errors block-remus.c: In function 'ramdisk_flush': block-remus.c:508: error: 'buf' may be used uninitialized in this function make[5]: *** [block-remus.o] Error 1 make[5]: *** Waiting for unfinished jobs.... I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or one of the followup patches? Ah: > version targeted for testing: > xen 27d63b9f111a So before all the fixups -- I suppose this will pass on the next run. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:01:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:01:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSzY-000394-JX; Thu, 10 May 2012 13:01:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSSzW-00038w-8W for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:01:10 +0000 Received: from [85.158.138.51:48055] by server-8.bemta-3.messagelabs.com id C0/7B-24428-51CBBAF4; Thu, 10 May 2012 13:01:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336654868!17426877!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1274 invoked from network); 10 May 2012 13:01:09 -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; 10 May 2012 13:01:09 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12405815" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:01: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, 10 May 2012 14:01:08 +0100 Message-ID: <1336654867.7098.118.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen.org , Keir Fraser , "Olaf Hering" Date: Thu, 10 May 2012 14:01:07 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > flight 12828 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386 4 xen-build fail REGR. vs. 12827 gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c cc1: warnings being treated as errors block-remus.c: In function 'ramdisk_flush': block-remus.c:508: error: 'buf' may be used uninitialized in this function make[5]: *** [block-remus.o] Error 1 make[5]: *** Waiting for unfinished jobs.... I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or one of the followup patches? Ah: > version targeted for testing: > xen 27d63b9f111a So before all the fixups -- I suppose this will pass on the next run. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:07:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SST5d-0003W5-0q; Thu, 10 May 2012 13:07:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SST5b-0003Vx-LX for xen-devel@lists.xen.org; Thu, 10 May 2012 13:07:27 +0000 Received: from [85.158.139.83:22534] by server-8.bemta-5.messagelabs.com id C4/36-26964-E8DBBAF4; Thu, 10 May 2012 13:07:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336655245!27708611!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12581 invoked from network); 10 May 2012 13:07:25 -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; 10 May 2012 13:07:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 14:07:24 +0100 Message-Id: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 14:07:44 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Ian Jackson , Ian Campbell , xen-devel Subject: Re: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:12, Stefano Stabellini wrote: > Hi all, > this patch implements local_attach support for QDISK: that means that > you can use qcow2 as disk format for your PV guests disks and use > pygrub to retrieve the kernel and initrd in dom0. > > The idea is that we start a QEMU instance at boot time to listen to > local_attach requests. When libxl_device_disk_local_attach is called on > a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk > so that blkfront in dom0 will create a new xvd device for it. > Then pygrub can be pointed at this device to retrieve kernel and > initrd. So I pulled this into my local tree to be able to debug problems in our gntdev driver in a reasonably isolated way (i.e. not needing to fire up guests). While block-attach works fine, block-detach doesn't at all. This may be related to me using the deprecated file:/ form of specifying the source during attach, as all of the supposedly modern forms I tried weren't accepted by the parser. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:07:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SST5d-0003W5-0q; Thu, 10 May 2012 13:07:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SST5b-0003Vx-LX for xen-devel@lists.xen.org; Thu, 10 May 2012 13:07:27 +0000 Received: from [85.158.139.83:22534] by server-8.bemta-5.messagelabs.com id C4/36-26964-E8DBBAF4; Thu, 10 May 2012 13:07:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336655245!27708611!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12581 invoked from network); 10 May 2012 13:07:25 -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; 10 May 2012 13:07:25 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 14:07:24 +0100 Message-Id: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 14:07:44 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Ian Jackson , Ian Campbell , xen-devel Subject: Re: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.05.12 at 13:12, Stefano Stabellini wrote: > Hi all, > this patch implements local_attach support for QDISK: that means that > you can use qcow2 as disk format for your PV guests disks and use > pygrub to retrieve the kernel and initrd in dom0. > > The idea is that we start a QEMU instance at boot time to listen to > local_attach requests. When libxl_device_disk_local_attach is called on > a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk > so that blkfront in dom0 will create a new xvd device for it. > Then pygrub can be pointed at this device to retrieve kernel and > initrd. So I pulled this into my local tree to be able to debug problems in our gntdev driver in a reasonably isolated way (i.e. not needing to fire up guests). While block-attach works fine, block-detach doesn't at all. This may be related to me using the deprecated file:/ form of specifying the source during attach, as all of the supposedly modern forms I tried weren't accepted by the parser. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:16:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:16:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTDc-0003kD-Va; Thu, 10 May 2012 13:15:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTDb-0003k8-Qp for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:15:44 +0000 Received: from [85.158.143.35:14006] by server-1.bemta-4.messagelabs.com id 5B/F4-20925-F7FBBAF4; Thu, 10 May 2012 13:15:43 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336655740!13391969!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3868 invoked from network); 10 May 2012 13:15: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; 10 May 2012 13:15:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406456" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:15: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, 10 May 2012 14:15:39 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTDX-0007J7-NS; Thu, 10 May 2012 13:15:39 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTDX-0005Dp-MI; Thu, 10 May 2012 14:15:39 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49019.672920.1826@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:15:39 +0100 To: Tim Deegan In-Reply-To: <20120510114414.GC73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Tim Deegan writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > > Boggle. Any such build processes need to be taken out and shot. > > There is nothing wrong with strcmp. Are you sure you're not thinking > > of strcat or sprintf ? > > If the user controlled both the length and contents of > info->u.pv.bootloader, it could cause this to overrun that buffer and > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > for many people. info->u.pv.bootloader is a string. The in-process caller of libxl is required to provide a nul-terminated buffer. In general, strcmp is correct for user-provided strings when the string is a string. I think perhaps people have been confused by the habit of some kernel ABI designers to write something like: struct mumble { char mumblename[16]; ... }; and then to allow callers to supply 16-octet mumblenames (necessarily, then, without a trailing nul), or shorter mumblenames (with trailing nul). In that case strncmp is indeed necessary. But these kind of interfaces are a rarity in userland and certainly libxl's API/ABI doesn't have anything like that. In the case of info->u.pv.bootloader the string is from malloc and the "buffer length" isn't even recorded anywhere so there would be no correct value to pass to strncmp that wasn't ~(size_t)0. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:16:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:16:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTDc-0003kD-Va; Thu, 10 May 2012 13:15:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTDb-0003k8-Qp for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:15:44 +0000 Received: from [85.158.143.35:14006] by server-1.bemta-4.messagelabs.com id 5B/F4-20925-F7FBBAF4; Thu, 10 May 2012 13:15:43 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336655740!13391969!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3868 invoked from network); 10 May 2012 13:15: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; 10 May 2012 13:15:41 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406456" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:15: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, 10 May 2012 14:15:39 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTDX-0007J7-NS; Thu, 10 May 2012 13:15:39 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTDX-0005Dp-MI; Thu, 10 May 2012 14:15:39 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49019.672920.1826@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:15:39 +0100 To: Tim Deegan In-Reply-To: <20120510114414.GC73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Tim Deegan writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > > Boggle. Any such build processes need to be taken out and shot. > > There is nothing wrong with strcmp. Are you sure you're not thinking > > of strcat or sprintf ? > > If the user controlled both the length and contents of > info->u.pv.bootloader, it could cause this to overrun that buffer and > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > for many people. info->u.pv.bootloader is a string. The in-process caller of libxl is required to provide a nul-terminated buffer. In general, strcmp is correct for user-provided strings when the string is a string. I think perhaps people have been confused by the habit of some kernel ABI designers to write something like: struct mumble { char mumblename[16]; ... }; and then to allow callers to supply 16-octet mumblenames (necessarily, then, without a trailing nul), or shorter mumblenames (with trailing nul). In that case strncmp is indeed necessary. But these kind of interfaces are a rarity in userland and certainly libxl's API/ABI doesn't have anything like that. In the case of info->u.pv.bootloader the string is from malloc and the "buffer length" isn't even recorded anywhere so there would be no correct value to pass to strncmp that wasn't ~(size_t)0. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:16:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:16:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTED-0003mM-Cs; Thu, 10 May 2012 13:16:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTEC-0003m8-7m for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:16:20 +0000 Received: from [193.109.254.147:41199] by server-6.bemta-14.messagelabs.com id 29/03-04960-3AFBBAF4; Thu, 10 May 2012 13:16:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336655760!1735584!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31637 invoked from network); 10 May 2012 13:16:00 -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 May 2012 13:16:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:16: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, 10 May 2012 14:16:00 +0100 Message-ID: <1336655758.7098.121.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:15:58 +0100 In-Reply-To: <1336654867.7098.118.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Shriram Rajagopalan , Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:01 +0100, Ian Campbell wrote: > On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > > flight 12828 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-i386 4 xen-build fail REGR. vs. 12827 > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c > cc1: warnings being treated as errors > block-remus.c: In function 'ramdisk_flush': > block-remus.c:508: error: 'buf' may be used uninitialized in this function > make[5]: *** [block-remus.o] Error 1 > make[5]: *** Waiting for unfinished jobs.... > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > one of the followup patches? > > Ah: > > > version targeted for testing: > > xen 27d63b9f111a > > So before all the fixups -- I suppose this will pass on the next run. Keir says this isn't one he has fixed. I can't repro it either (and I run Squeeze, just like the build system) but by inspection this ought to solve it. 8<-------------------------------------- # HG changeset patch # User Ian Campbell # Date 1336655664 -3600 # Node ID 6d45fbdca09be60726eb7043a42dbac552e202e0 # Parent bc8630bc68025bdee747ebe707b764e323914fd6 blktap2/remus: initialise variable. gcc seems to not be able to spot that it is always initialised, based on the complexity of merge_requests' error handling I don't blame it. Signed-off-by: Ian Campbell diff -r bc8630bc6802 -r 6d45fbdca09b tools/blktap2/drivers/block-remus.c --- a/tools/blktap2/drivers/block-remus.c Thu May 10 14:07:31 2012 +0100 +++ b/tools/blktap2/drivers/block-remus.c Thu May 10 14:14:24 2012 +0100 @@ -533,6 +533,7 @@ static int ramdisk_flush(td_driver_t *dr i++; batchlen = sectors[i-1] - base + 1; + buf = NULL; j = merge_requests(&s->ramdisk, base, batchlen, &buf); if (j) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:16:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:16:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTED-0003mM-Cs; Thu, 10 May 2012 13:16:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTEC-0003m8-7m for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:16:20 +0000 Received: from [193.109.254.147:41199] by server-6.bemta-14.messagelabs.com id 29/03-04960-3AFBBAF4; Thu, 10 May 2012 13:16:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336655760!1735584!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31637 invoked from network); 10 May 2012 13:16:00 -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 May 2012 13:16:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:16: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, 10 May 2012 14:16:00 +0100 Message-ID: <1336655758.7098.121.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:15:58 +0100 In-Reply-To: <1336654867.7098.118.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Shriram Rajagopalan , Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:01 +0100, Ian Campbell wrote: > On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > > flight 12828 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-i386 4 xen-build fail REGR. vs. 12827 > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c > cc1: warnings being treated as errors > block-remus.c: In function 'ramdisk_flush': > block-remus.c:508: error: 'buf' may be used uninitialized in this function > make[5]: *** [block-remus.o] Error 1 > make[5]: *** Waiting for unfinished jobs.... > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > one of the followup patches? > > Ah: > > > version targeted for testing: > > xen 27d63b9f111a > > So before all the fixups -- I suppose this will pass on the next run. Keir says this isn't one he has fixed. I can't repro it either (and I run Squeeze, just like the build system) but by inspection this ought to solve it. 8<-------------------------------------- # HG changeset patch # User Ian Campbell # Date 1336655664 -3600 # Node ID 6d45fbdca09be60726eb7043a42dbac552e202e0 # Parent bc8630bc68025bdee747ebe707b764e323914fd6 blktap2/remus: initialise variable. gcc seems to not be able to spot that it is always initialised, based on the complexity of merge_requests' error handling I don't blame it. Signed-off-by: Ian Campbell diff -r bc8630bc6802 -r 6d45fbdca09b tools/blktap2/drivers/block-remus.c --- a/tools/blktap2/drivers/block-remus.c Thu May 10 14:07:31 2012 +0100 +++ b/tools/blktap2/drivers/block-remus.c Thu May 10 14:14:24 2012 +0100 @@ -533,6 +533,7 @@ static int ramdisk_flush(td_driver_t *dr i++; batchlen = sectors[i-1] - base + 1; + buf = NULL; j = merge_requests(&s->ramdisk, base, batchlen, &buf); if (j) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:21:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:21:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTIT-00040W-3A; Thu, 10 May 2012 13:20:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTIR-00040O-Bn for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:20:43 +0000 Received: from [85.158.143.99:34830] by server-2.bemta-4.messagelabs.com id B2/BD-17550-AA0CBAF4; Thu, 10 May 2012 13:20:42 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-14.tower-216.messagelabs.com!1336656040!17741112!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18350 invoked from network); 10 May 2012 13:20:41 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 13:20:41 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSTIN-000MSJ-Pr; Thu, 10 May 2012 13:20:39 +0000 Date: Thu, 10 May 2012 14:20:39 +0100 From: Tim Deegan To: Ian Jackson Message-ID: <20120510132039.GE73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> <20395.49019.672920.1826@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20395.49019.672920.1826@mariner.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:15 +0100 on 10 May (1336659339), Ian Jackson wrote: > Tim Deegan writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > > > Boggle. Any such build processes need to be taken out and shot. > > > There is nothing wrong with strcmp. Are you sure you're not thinking > > > of strcat or sprintf ? > > > > If the user controlled both the length and contents of > > info->u.pv.bootloader, it could cause this to overrun that buffer and > > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > > for many people. > > info->u.pv.bootloader is a string. The in-process caller of libxl > is required to provide a nul-terminated buffer. In general, strcmp is > correct for user-provided strings when the string is a string. Sure, in this case, strcmp is fine; I was talking about the reasons why people are scared of it. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:21:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:21:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTIT-00040W-3A; Thu, 10 May 2012 13:20:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTIR-00040O-Bn for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:20:43 +0000 Received: from [85.158.143.99:34830] by server-2.bemta-4.messagelabs.com id B2/BD-17550-AA0CBAF4; Thu, 10 May 2012 13:20:42 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-14.tower-216.messagelabs.com!1336656040!17741112!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18350 invoked from network); 10 May 2012 13:20:41 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 13:20:41 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1SSTIN-000MSJ-Pr; Thu, 10 May 2012 13:20:39 +0000 Date: Thu, 10 May 2012 14:20:39 +0100 From: Tim Deegan To: Ian Jackson Message-ID: <20120510132039.GE73773@ocelot.phlegethon.org> References: <794778a6e9fa761bd388.1336560666@kodo2> <1336570982.25514.120.camel@zakaz.uk.xensource.com> <4FAA83A8.8070804@eu.citrix.com> <20395.43075.534483.485017@mariner.uk.xensource.com> <20120510114414.GC73773@ocelot.phlegethon.org> <20395.49019.672920.1826@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20395.49019.672920.1826@mariner.uk.xensource.com> User-Agent: Mutt/1.4.2.1i Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:15 +0100 on 10 May (1336659339), Ian Jackson wrote: > Tim Deegan writes ("Re: [Xen-devel] [PATCH 3 of 3 RESEND] libxl: Warn that /usr/bin/pygrub is deprecated"): > > At 12:36 +0100 on 10 May (1336653395), Ian Jackson wrote: > > > Boggle. Any such build processes need to be taken out and shot. > > > There is nothing wrong with strcmp. Are you sure you're not thinking > > > of strcat or sprintf ? > > > > If the user controlled both the length and contents of > > info->u.pv.bootloader, it could cause this to overrun that buffer and > > cause a SEGV. So, sadly, strcmp goes on the 'just never use it' list > > for many people. > > info->u.pv.bootloader is a string. The in-process caller of libxl > is required to provide a nul-terminated buffer. In general, strcmp is > correct for user-provided strings when the string is a string. Sure, in this case, strcmp is fine; I was talking about the reasons why people are scared of it. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:26:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTNn-0004HB-Ks; Thu, 10 May 2012 13:26:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTNm-0004H2-Er for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:14 +0000 Received: from [85.158.143.35:31571] by server-3.bemta-4.messagelabs.com id 99/D4-05853-5F1CBAF4; Thu, 10 May 2012 13:26:13 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-21.messagelabs.com!1336656372!11629161!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzkzNjQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzkzNjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14029 invoked from network); 10 May 2012 13:26:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 13:26:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PFpY= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-094-015.pools.arcor-ip.net [88.65.94.15]) by smtp.strato.de (josoe mo22) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R014a2o4AC2Tk4 ; Thu, 10 May 2012 15:26:11 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A9E4818637; Thu, 10 May 2012 15:26:10 +0200 (CEST) Date: Thu, 10 May 2012 15:26:10 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120510132610.GA5002@aepfle.de> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <1336655758.7098.121.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336655758.7098.121.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: Shriram Rajagopalan , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, Ian Campbell wrote: > On Thu, 2012-05-10 at 14:01 +0100, Ian Campbell wrote: > > On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > > > flight 12828 xen-unstable real [real] > > > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > > > > > Regressions :-( > > > > > > Tests which did not succeed and are blocking, > > > including tests which could not be run: > > > build-i386 4 xen-build fail REGR. vs. 12827 > > > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c > > cc1: warnings being treated as errors > > block-remus.c: In function 'ramdisk_flush': > > block-remus.c:508: error: 'buf' may be used uninitialized in this function > > make[5]: *** [block-remus.o] Error 1 > > make[5]: *** Waiting for unfinished jobs.... > > > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > > one of the followup patches? > > > > Ah: > > > > > version targeted for testing: > > > xen 27d63b9f111a > > > > So before all the fixups -- I suppose this will pass on the next run. > > Keir says this isn't one he has fixed. I can't repro it either (and I > run Squeeze, just like the build system) but by inspection this ought to > solve it. Looks like a compiler issue, since merge_requests() seems to correctly return a non-null value when it does not touch the passed pointer to buf. So your simple change looks like a correct workaround. In general I think Makefiles should rather not mess with -W* and -O* options like this, and use only the global flags if possible. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:26:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTNn-0004HB-Ks; Thu, 10 May 2012 13:26:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTNm-0004H2-Er for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:14 +0000 Received: from [85.158.143.35:31571] by server-3.bemta-4.messagelabs.com id 99/D4-05853-5F1CBAF4; Thu, 10 May 2012 13:26:13 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-3.tower-21.messagelabs.com!1336656372!11629161!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzkzNjQ=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyNzkzNjQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14029 invoked from network); 10 May 2012 13:26:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 13:26:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PFpY= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-094-015.pools.arcor-ip.net [88.65.94.15]) by smtp.strato.de (josoe mo22) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R014a2o4AC2Tk4 ; Thu, 10 May 2012 15:26:11 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id A9E4818637; Thu, 10 May 2012 15:26:10 +0200 (CEST) Date: Thu, 10 May 2012 15:26:10 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120510132610.GA5002@aepfle.de> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <1336655758.7098.121.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336655758.7098.121.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: Shriram Rajagopalan , "Keir \(Xen.org\)" , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, Ian Campbell wrote: > On Thu, 2012-05-10 at 14:01 +0100, Ian Campbell wrote: > > On Thu, 2012-05-10 at 12:58 +0100, xen.org wrote: > > > flight 12828 xen-unstable real [real] > > > http://www.chiark.greenend.org.uk/~xensrcts/logs/12828/ > > > > > > Regressions :-( > > > > > > Tests which did not succeed and are blocking, > > > including tests which could not be run: > > > build-i386 4 xen-build fail REGR. vs. 12827 > > > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .img2qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o img2qcow.o img2qcow.c > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .qcow2raw.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-amd64/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o qcow2raw.o qcow2raw.c > > cc1: warnings being treated as errors > > block-remus.c: In function 'ramdisk_flush': > > block-remus.c:508: error: 'buf' may be used uninitialized in this function > > make[5]: *** [block-remus.o] Error 1 > > make[5]: *** Waiting for unfinished jobs.... > > > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > > one of the followup patches? > > > > Ah: > > > > > version targeted for testing: > > > xen 27d63b9f111a > > > > So before all the fixups -- I suppose this will pass on the next run. > > Keir says this isn't one he has fixed. I can't repro it either (and I > run Squeeze, just like the build system) but by inspection this ought to > solve it. Looks like a compiler issue, since merge_requests() seems to correctly return a non-null value when it does not touch the passed pointer to buf. So your simple change looks like a correct workaround. In general I think Makefiles should rather not mess with -W* and -O* options like this, and use only the global flags if possible. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:27:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTOM-0004LV-7y; Thu, 10 May 2012 13:26:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTOK-0004LL-Pa for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:48 +0000 Received: from [193.109.254.147:41511] by server-7.bemta-14.messagelabs.com id 27/17-01627-812CBAF4; Thu, 10 May 2012 13:26:48 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336656407!8407372!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 835 invoked from network); 10 May 2012 13:26:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 13:26:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:26: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, 10 May 2012 14:26:46 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTOI-0007Ms-IX for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:46 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTOI-0005Ij-Hc for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:26:46 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49686.531779.62494@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:26:46 +0100 To: "xen-devel@lists.xensource.com" In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen.org writes ("[xen-unstable test] 12828: regressions - FAIL"): > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386 4 xen-build fail REGR. vs. 12827 I have just committed the patch below to fix this. Ian. # HG changeset patch # User Ian Jackson # Date 1336656374 -3600 # Node ID 60064411a8a9b68136e16ae5abdd98410745d5c7 # Parent 81088df89e80b960ba922e4b82fcc504d86cb499 blktap2: Fix another uninitialised value error gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .block-remus.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -c -o block-remus.o block-remus.c block-remus.c: In function 'ramdisk_flush': block-remus.c:508: error: 'buf' may be used uninitialized in this function make[5]: *** [block-remus.o] Error 1 This is because gcc can see that merge_requests doesn't always set *mergedbuf but gcc isn't able to prove that it always does so if merge_requests returns 0 and that in that case the value of ramdisk_flush::buf isn't used. This is too useful a warning to disable, despite the occasional false positive of this form. The conventional approach is to suppress the warning by explicitly initialising the variable to 0. This has just come to light because 25275:27d63b9f111a reenabled optimisation for this area of code, and gcc's data flow analysis (which is required to trigger the uninitialised variable warning) only occurs when optimisation is turned on. Signed-off-by: Ian Jackson diff -r 81088df89e80 -r 60064411a8a9 tools/blktap2/drivers/block-remus.c --- a/tools/blktap2/drivers/block-remus.c Thu May 10 12:19:16 2012 +0100 +++ b/tools/blktap2/drivers/block-remus.c Thu May 10 14:26:14 2012 +0100 @@ -505,7 +505,7 @@ fail: static int ramdisk_flush(td_driver_t *driver, struct tdremus_state* s) { uint64_t* sectors; - char* buf; + char* buf = NULL; uint64_t base, batchlen; int i, j, count = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:27:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTOM-0004LV-7y; Thu, 10 May 2012 13:26:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTOK-0004LL-Pa for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:48 +0000 Received: from [193.109.254.147:41511] by server-7.bemta-14.messagelabs.com id 27/17-01627-812CBAF4; Thu, 10 May 2012 13:26:48 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336656407!8407372!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 835 invoked from network); 10 May 2012 13:26:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 13:26:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:26: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, 10 May 2012 14:26:46 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTOI-0007Ms-IX for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:26:46 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTOI-0005Ij-Hc for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:26:46 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49686.531779.62494@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:26:46 +0100 To: "xen-devel@lists.xensource.com" In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen.org writes ("[xen-unstable test] 12828: regressions - FAIL"): > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386 4 xen-build fail REGR. vs. 12827 I have just committed the patch below to fix this. Ian. # HG changeset patch # User Ian Jackson # Date 1336656374 -3600 # Node ID 60064411a8a9b68136e16ae5abdd98410745d5c7 # Parent 81088df89e80b960ba922e4b82fcc504d86cb499 blktap2: Fix another uninitialised value error gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .block-remus.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/libxc -I/home/osstest/build.12828.build-i386/xen-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -c -o block-remus.o block-remus.c block-remus.c: In function 'ramdisk_flush': block-remus.c:508: error: 'buf' may be used uninitialized in this function make[5]: *** [block-remus.o] Error 1 This is because gcc can see that merge_requests doesn't always set *mergedbuf but gcc isn't able to prove that it always does so if merge_requests returns 0 and that in that case the value of ramdisk_flush::buf isn't used. This is too useful a warning to disable, despite the occasional false positive of this form. The conventional approach is to suppress the warning by explicitly initialising the variable to 0. This has just come to light because 25275:27d63b9f111a reenabled optimisation for this area of code, and gcc's data flow analysis (which is required to trigger the uninitialised variable warning) only occurs when optimisation is turned on. Signed-off-by: Ian Jackson diff -r 81088df89e80 -r 60064411a8a9 tools/blktap2/drivers/block-remus.c --- a/tools/blktap2/drivers/block-remus.c Thu May 10 12:19:16 2012 +0100 +++ b/tools/blktap2/drivers/block-remus.c Thu May 10 14:26:14 2012 +0100 @@ -505,7 +505,7 @@ fail: static int ramdisk_flush(td_driver_t *driver, struct tdremus_state* s) { uint64_t* sectors; - char* buf; + char* buf = NULL; uint64_t base, batchlen; int i, j, count = 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:28:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTPt-0004Xn-Nj; Thu, 10 May 2012 13:28:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTPt-0004Xg-3D for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:28:25 +0000 Received: from [85.158.139.83:13647] by server-10.bemta-5.messagelabs.com id CE/9F-08260-772CBAF4; Thu, 10 May 2012 13:28:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336656498!27680267!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18703 invoked from network); 10 May 2012 13:28:19 -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; 10 May 2012 13:28:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406897" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:28: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, 10 May 2012 14:28:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTPl-0007NQ-RS; Thu, 10 May 2012 13:28:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTPl-0005J3-QG; Thu, 10 May 2012 14:28:17 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49777.634130.544681@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:28:17 +0100 To: Ian Campbell In-Reply-To: <1336654867.7098.118.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > one of the followup patches? > > Ah: > > > version targeted for testing: > > xen 27d63b9f111a > > So before all the fixups -- I suppose this will pass on the next run. I repro'd this particular failure in 25280:81088df89e80 and have therefore committed a fix. I guess Keir's compiler is different to mine. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:28:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTPt-0004Xn-Nj; Thu, 10 May 2012 13:28:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTPt-0004Xg-3D for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:28:25 +0000 Received: from [85.158.139.83:13647] by server-10.bemta-5.messagelabs.com id CE/9F-08260-772CBAF4; Thu, 10 May 2012 13:28:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336656498!27680267!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18703 invoked from network); 10 May 2012 13:28:19 -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; 10 May 2012 13:28:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12406897" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:28: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, 10 May 2012 14:28:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTPl-0007NQ-RS; Thu, 10 May 2012 13:28:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTPl-0005J3-QG; Thu, 10 May 2012 14:28:17 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.49777.634130.544681@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:28:17 +0100 To: Ian Campbell In-Reply-To: <1336654867.7098.118.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > one of the followup patches? > > Ah: > > > version targeted for testing: > > xen 27d63b9f111a > > So before all the fixups -- I suppose this will pass on the next run. I repro'd this particular failure in 25280:81088df89e80 and have therefore committed a fix. I guess Keir's compiler is different to mine. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTSu-0004pf-CD; Thu, 10 May 2012 13:31:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTSt-0004ou-CE for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:31:31 +0000 Received: from [85.158.139.83:49610] by server-2.bemta-5.messagelabs.com id 1C/62-17016-F23CBAF4; Thu, 10 May 2012 13:31:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336656676!26996696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21506 invoked from network); 10 May 2012 13:31:18 -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; 10 May 2012 13:31:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407000" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:31:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 14:31:05 +0100 Message-ID: <1336656664.7098.124.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:31:04 +0100 In-Reply-To: <20395.49777.634130.544681@mariner.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:28 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > > one of the followup patches? > > > > Ah: > > > > > version targeted for testing: > > > xen 27d63b9f111a > > > > So before all the fixups -- I suppose this will pass on the next run. > > I repro'd this particular failure in 25280:81088df89e80 and have > therefore committed a fix. I guess Keir's compiler is different to > mine. He runs Fedora IIRC. I tried to repro on Squeeze though and couldn't -- I expected you and the test system to also be running Squeeze. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:31:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTSu-0004pf-CD; Thu, 10 May 2012 13:31:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTSt-0004ou-CE for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:31:31 +0000 Received: from [85.158.139.83:49610] by server-2.bemta-5.messagelabs.com id 1C/62-17016-F23CBAF4; Thu, 10 May 2012 13:31:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336656676!26996696!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21506 invoked from network); 10 May 2012 13:31:18 -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; 10 May 2012 13:31:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407000" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:31:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 14:31:05 +0100 Message-ID: <1336656664.7098.124.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:31:04 +0100 In-Reply-To: <20395.49777.634130.544681@mariner.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:28 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > > I presume this is 25289:27d63b9f111a "blktap2: Do not build with -O0" or > > one of the followup patches? > > > > Ah: > > > > > version targeted for testing: > > > xen 27d63b9f111a > > > > So before all the fixups -- I suppose this will pass on the next run. > > I repro'd this particular failure in 25280:81088df89e80 and have > therefore committed a fix. I guess Keir's compiler is different to > mine. He runs Fedora IIRC. I tried to repro on Squeeze though and couldn't -- I expected you and the test system to also be running Squeeze. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:33:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTUz-000506-Tc; Thu, 10 May 2012 13:33:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTUy-0004zz-AM for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:33:40 +0000 Received: from [85.158.139.83:44097] by server-10.bemta-5.messagelabs.com id 61/D4-08260-3B3CBAF4; Thu, 10 May 2012 13:33:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336656747!26996900!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28348 invoked from network); 10 May 2012 13:32:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 13:32:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407042" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:32: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, 10 May 2012 14:32:26 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTTm-0007Oi-Fw; Thu, 10 May 2012 13:32:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTTm-0005JT-Es; Thu, 10 May 2012 14:32:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.50026.445263.650522@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:32:26 +0100 To: Ian Campbell In-Reply-To: <1336656664.7098.124.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> <1336656664.7098.124.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > I tried to repro on Squeeze though and couldn't -- I expected you and > the test system to also be running Squeeze. Well, who knows :-). Anyway my fix is in staging now. (And I think I prefer mine, initialising the variable in its definition, to yours, which assigns NULL to it at some midpoint.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:33:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTUz-000506-Tc; Thu, 10 May 2012 13:33:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTUy-0004zz-AM for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:33:40 +0000 Received: from [85.158.139.83:44097] by server-10.bemta-5.messagelabs.com id 61/D4-08260-3B3CBAF4; Thu, 10 May 2012 13:33:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336656747!26996900!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28348 invoked from network); 10 May 2012 13:32:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 13:32:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407042" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:32: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, 10 May 2012 14:32:26 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTTm-0007Oi-Fw; Thu, 10 May 2012 13:32:26 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTTm-0005JT-Es; Thu, 10 May 2012 14:32:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.50026.445263.650522@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:32:26 +0100 To: Ian Campbell In-Reply-To: <1336656664.7098.124.camel@zakaz.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> <1336656664.7098.124.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > I tried to repro on Squeeze though and couldn't -- I expected you and > the test system to also be running Squeeze. Well, who knows :-). Anyway my fix is in staging now. (And I think I prefer mine, initialising the variable in its definition, to yours, which assigns NULL to it at some midpoint.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:36:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTXR-00059X-En; Thu, 10 May 2012 13:36:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTXQ-00059L-28 for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:36:12 +0000 Received: from [193.109.254.147:13104] by server-6.bemta-14.messagelabs.com id A4/DB-04960-A44CBAF4; Thu, 10 May 2012 13:36:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336656968!2939414!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7919 invoked from network); 10 May 2012 13:36:08 -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; 10 May 2012 13:36:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13: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; Thu, 10 May 2012 14:36:08 +0100 Message-ID: <1336656966.7098.125.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:36:06 +0100 In-Reply-To: <20395.50026.445263.650522@mariner.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> <1336656664.7098.124.camel@zakaz.uk.xensource.com> <20395.50026.445263.650522@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:32 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > > I tried to repro on Squeeze though and couldn't -- I expected you and > > the test system to also be running Squeeze. > > Well, who knows :-). Anyway my fix is in staging now. (And I think I > prefer mine, initialising the variable in its definition, to yours, > which assigns NULL to it at some midpoint.) Yeah, I'm happy with yours too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:36:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSTXR-00059X-En; Thu, 10 May 2012 13:36:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTXQ-00059L-28 for xen-devel@lists.xensource.com; Thu, 10 May 2012 13:36:12 +0000 Received: from [193.109.254.147:13104] by server-6.bemta-14.messagelabs.com id A4/DB-04960-A44CBAF4; Thu, 10 May 2012 13:36:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336656968!2939414!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7919 invoked from network); 10 May 2012 13:36:08 -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; 10 May 2012 13:36:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13: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; Thu, 10 May 2012 14:36:08 +0100 Message-ID: <1336656966.7098.125.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:36:06 +0100 In-Reply-To: <20395.50026.445263.650522@mariner.uk.xensource.com> References: <1336654867.7098.118.camel@zakaz.uk.xensource.com> <20395.49777.634130.544681@mariner.uk.xensource.com> <1336656664.7098.124.camel@zakaz.uk.xensource.com> <20395.50026.445263.650522@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir \(Xen.org\)" Subject: Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:32 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 12828: regressions - FAIL"): > > I tried to repro on Squeeze though and couldn't -- I expected you and > > the test system to also be running Squeeze. > > Well, who knows :-). Anyway my fix is in staging now. (And I think I > prefer mine, initialising the variable in its definition, to yours, > which assigns NULL to it at some midpoint.) Yeah, I'm happy with yours too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:37:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:37:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTYc-0005Gi-Tf; Thu, 10 May 2012 13:37:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTYc-0005GV-3b for xen-devel@lists.xen.org; Thu, 10 May 2012 13:37:26 +0000 Received: from [85.158.143.99:41967] by server-3.bemta-4.messagelabs.com id 06/DB-05853-594CBAF4; Thu, 10 May 2012 13:37:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336657043!17602599!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24458 invoked from network); 10 May 2012 13:37: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; 10 May 2012 13:37:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407234" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:37: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, 10 May 2012 14:37:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTYM-0007QQ-6X; Thu, 10 May 2012 13:37:10 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTYM-0005K4-5d; Thu, 10 May 2012 14:37:10 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.50310.159688.722301@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:37:10 +0100 To: Jean Guyader Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Eric Chanudet , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jean Guyader writes ("[Xen-devel] [PATCH] tools/xenconsoled: Add syslog"): > Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. > The default behaviour remains the same (log into plain files) Thanks. This sounds like a very useful new feature. However xen-unstable.hg is now in feature freeze for the 4.2 release, and we are very busy working on the remaining release blockers and bugfixes. Can I ask you to repost this after 4.2 has branched and development has reopened ? I will review it properly then. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:37:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13:37:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTYc-0005Gi-Tf; Thu, 10 May 2012 13:37:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSTYc-0005GV-3b for xen-devel@lists.xen.org; Thu, 10 May 2012 13:37:26 +0000 Received: from [85.158.143.99:41967] by server-3.bemta-4.messagelabs.com id 06/DB-05853-594CBAF4; Thu, 10 May 2012 13:37:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336657043!17602599!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24458 invoked from network); 10 May 2012 13:37: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; 10 May 2012 13:37:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407234" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:37: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, 10 May 2012 14:37:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSTYM-0007QQ-6X; Thu, 10 May 2012 13:37:10 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSTYM-0005K4-5d; Thu, 10 May 2012 14:37:10 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.50310.159688.722301@mariner.uk.xensource.com> Date: Thu, 10 May 2012 14:37:10 +0100 To: Jean Guyader Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Eric Chanudet , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jean Guyader writes ("[Xen-devel] [PATCH] tools/xenconsoled: Add syslog"): > Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. > The default behaviour remains the same (log into plain files) Thanks. This sounds like a very useful new feature. However xen-unstable.hg is now in feature freeze for the 4.2 release, and we are very busy working on the remaining release blockers and bugfixes. Can I ask you to repost this after 4.2 has branched and development has reopened ? I will review it properly then. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:46:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSThX-0005Wv-Hu; Thu, 10 May 2012 13:46:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSThV-0005Wq-Nk for xen-devel@lists.xen.org; Thu, 10 May 2012 13:46:37 +0000 Received: from [85.158.143.99:38458] by server-3.bemta-4.messagelabs.com id 91/5D-05853-DB6CBAF4; Thu, 10 May 2012 13:46:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336657596!24006994!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4297 invoked from network); 10 May 2012 13:46: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; 10 May 2012 13:46:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407882" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:46: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, 10 May 2012 14:46:35 +0100 Message-ID: <1336657594.7098.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:46:34 +0100 In-Reply-To: <20395.50310.159688.722301@mariner.uk.xensource.com> References: <20395.50310.159688.722301@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Eric Chanudet , Jean Guyader , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:37 +0100, Ian Jackson wrote: > Jean Guyader writes ("[Xen-devel] [PATCH] tools/xenconsoled: Add syslog"): > > Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. > > The default behaviour remains the same (log into plain files) > > Thanks. This sounds like a very useful new feature. > > However xen-unstable.hg is now in feature freeze for the 4.2 release, > and we are very busy working on the remaining release blockers and > bugfixes. Can I ask you to repost this after 4.2 has branched and > development has reopened ? /release hat on... Yes, I should have said that too, thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 13:46:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 13: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 ) id 1SSThX-0005Wv-Hu; Thu, 10 May 2012 13:46:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSThV-0005Wq-Nk for xen-devel@lists.xen.org; Thu, 10 May 2012 13:46:37 +0000 Received: from [85.158.143.99:38458] by server-3.bemta-4.messagelabs.com id 91/5D-05853-DB6CBAF4; Thu, 10 May 2012 13:46:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336657596!24006994!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4297 invoked from network); 10 May 2012 13:46: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; 10 May 2012 13:46:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12407882" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 13:46: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, 10 May 2012 14:46:35 +0100 Message-ID: <1336657594.7098.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Thu, 10 May 2012 14:46:34 +0100 In-Reply-To: <20395.50310.159688.722301@mariner.uk.xensource.com> References: <20395.50310.159688.722301@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Eric Chanudet , Jean Guyader , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] tools/xenconsoled: Add syslog X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 14:37 +0100, Ian Jackson wrote: > Jean Guyader writes ("[Xen-devel] [PATCH] tools/xenconsoled: Add syslog"): > > Introduce a new option (-s/--syslog) to make xenconsoled log into syslog. > > The default behaviour remains the same (log into plain files) > > Thanks. This sounds like a very useful new feature. > > However xen-unstable.hg is now in feature freeze for the 4.2 release, > and we are very busy working on the remaining release blockers and > bugfixes. Can I ask you to repost this after 4.2 has branched and > development has reopened ? /release hat on... Yes, I should have said that too, thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:12:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:12:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSU6K-00065P-CQ; Thu, 10 May 2012 14:12:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSU6J-00065J-Gn for xen-devel@lists.xen.org; Thu, 10 May 2012 14:12:15 +0000 Received: from [85.158.143.35:59324] by server-3.bemta-4.messagelabs.com id 57/95-05853-EBCCBAF4; Thu, 10 May 2012 14:12:14 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-13.tower-21.messagelabs.com!1336659132!13564524!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24833 invoked from network); 10 May 2012 14:12:13 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 10 May 2012 14:12:13 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49874 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SSU1k-00022s-Fq; Thu, 10 May 2012 16:07:32 +0200 Date: Thu, 10 May 2012 16:12:11 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <686683228.20120510161211@eikelenboom.it> To: Ian Campbell In-Reply-To: <1336646320.7098.62.camel@zakaz.uk.xensource.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Ian, Thursday, May 10, 2012, 12:38:40 PM, you wrote: > On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: >> On Wed, May 9, 2012 at 2:45 PM, George Dunlap >> wrote: >> > On 09/05/12 12:59, Ian Campbell wrote: >> >> >> >> Right, however it is strictly speaking a new feature which is not >> >> mentioned on the TODO list and has not previously been posted (AFAIK, >> >> please correct me if not) and we are currently supposed to be in feature >> >> freeze (and have been for several weeks, if not a month). >> >> >> >> IIRC this functionality was mooted when the pci permissive patch was >> >> being done as something which would be a 4.3 feature. >> >> We need to decide if we want to make an exception for this new feature >> >> or not. Although I'm sure this feature is very nice and handy, we've >> >> lived without it for years and people seem to be able to use the >> >> existing scheme. >> >> And, I realize that at some point all of the deadlines are going to be >> arbitrary; but I have always felt this is important enough to get an >> exception. I consider having to muck about with sysfs to be basically >> a UI bug that really needs fixing. I have a lot of other things that >> I would like to get done for the 4.2 release; but I thought this was >> important enough to get priority (above the PoD patch series, for >> instance). NB I'm not saying that you should accept it because I >> worked on it; I only bring it up to demonstrate how important I think >> the feature is. > OK, given that the code is basically self contained and shouldn't effect > anything unless a user "opts-in" to using it I think you've convinced > me. Lets take this (I'll review the actual patches shortly). > BTW, IMHO it is preferable for actual deployments to use the kernel > command line options to hide devices rather than either this feature or > sysfs. > Fully hiding the device from dom0 drivers generally seems like it is > always better. That way the first driver to try and touch the hardware > is the one inside the domU. This avoids issues with dom0 drivers setting > stuff up but not tearing it down in a way that domU can cope with and > makes the use of hardware which doesn't support FLR more reliable etc. Haven't checked it (haven't got the time right now) but: Is using wildcards in the BDF's on the commandline supported already (like the ones supported in the config files for domains) I tend to have quite long commandlines to hide a pci-e card with 8 functions (needed to specify 8 BDF's seperatly) for pci passthrough, would be nice if one could just specify 09:00.* for example. > Ian. -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:12:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:12:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSU6K-00065P-CQ; Thu, 10 May 2012 14:12:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSU6J-00065J-Gn for xen-devel@lists.xen.org; Thu, 10 May 2012 14:12:15 +0000 Received: from [85.158.143.35:59324] by server-3.bemta-4.messagelabs.com id 57/95-05853-EBCCBAF4; Thu, 10 May 2012 14:12:14 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-13.tower-21.messagelabs.com!1336659132!13564524!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24833 invoked from network); 10 May 2012 14:12:13 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-13.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 10 May 2012 14:12:13 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49874 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SSU1k-00022s-Fq; Thu, 10 May 2012 16:07:32 +0200 Date: Thu, 10 May 2012 16:12:11 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <686683228.20120510161211@eikelenboom.it> To: Ian Campbell In-Reply-To: <1336646320.7098.62.camel@zakaz.uk.xensource.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Ian, Thursday, May 10, 2012, 12:38:40 PM, you wrote: > On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: >> On Wed, May 9, 2012 at 2:45 PM, George Dunlap >> wrote: >> > On 09/05/12 12:59, Ian Campbell wrote: >> >> >> >> Right, however it is strictly speaking a new feature which is not >> >> mentioned on the TODO list and has not previously been posted (AFAIK, >> >> please correct me if not) and we are currently supposed to be in feature >> >> freeze (and have been for several weeks, if not a month). >> >> >> >> IIRC this functionality was mooted when the pci permissive patch was >> >> being done as something which would be a 4.3 feature. >> >> We need to decide if we want to make an exception for this new feature >> >> or not. Although I'm sure this feature is very nice and handy, we've >> >> lived without it for years and people seem to be able to use the >> >> existing scheme. >> >> And, I realize that at some point all of the deadlines are going to be >> arbitrary; but I have always felt this is important enough to get an >> exception. I consider having to muck about with sysfs to be basically >> a UI bug that really needs fixing. I have a lot of other things that >> I would like to get done for the 4.2 release; but I thought this was >> important enough to get priority (above the PoD patch series, for >> instance). NB I'm not saying that you should accept it because I >> worked on it; I only bring it up to demonstrate how important I think >> the feature is. > OK, given that the code is basically self contained and shouldn't effect > anything unless a user "opts-in" to using it I think you've convinced > me. Lets take this (I'll review the actual patches shortly). > BTW, IMHO it is preferable for actual deployments to use the kernel > command line options to hide devices rather than either this feature or > sysfs. > Fully hiding the device from dom0 drivers generally seems like it is > always better. That way the first driver to try and touch the hardware > is the one inside the domU. This avoids issues with dom0 drivers setting > stuff up but not tearing it down in a way that domU can cope with and > makes the use of hardware which doesn't support FLR more reliable etc. Haven't checked it (haven't got the time right now) but: Is using wildcards in the BDF's on the commandline supported already (like the ones supported in the config files for domains) I tend to have quite long commandlines to hide a pci-e card with 8 functions (needed to specify 8 BDF's seperatly) for pci passthrough, would be nice if one could just specify 09:00.* for example. > Ian. -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:17:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14: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 ) id 1SSUAx-0006HN-9j; Thu, 10 May 2012 14:17:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUAv-0006HG-RK for xen-devel@lists.xen.org; Thu, 10 May 2012 14:17:02 +0000 Received: from [85.158.139.83:40855] by server-6.bemta-5.messagelabs.com id 1D/9B-13222-DDDCBAF4; Thu, 10 May 2012 14:17:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336659419!24976548!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2547 invoked from network); 10 May 2012 14:16:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 14:16:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12408914" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 14:16: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, 10 May 2012 15:16:58 +0100 Message-ID: <1336659417.14220.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Thu, 10 May 2012 15:16:57 +0100 In-Reply-To: <686683228.20120510161211@eikelenboom.it> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> <686683228.20120510161211@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:12 +0100, Sander Eikelenboom wrote: > Hello Ian, > > Thursday, May 10, 2012, 12:38:40 PM, you wrote: > > > On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: > >> On Wed, May 9, 2012 at 2:45 PM, George Dunlap > >> wrote: > >> > On 09/05/12 12:59, Ian Campbell wrote: > >> >> > >> >> Right, however it is strictly speaking a new feature which is not > >> >> mentioned on the TODO list and has not previously been posted (AFAIK, > >> >> please correct me if not) and we are currently supposed to be in feature > >> >> freeze (and have been for several weeks, if not a month). > >> >> > >> >> IIRC this functionality was mooted when the pci permissive patch was > >> >> being done as something which would be a 4.3 feature. > >> >> We need to decide if we want to make an exception for this new feature > >> >> or not. Although I'm sure this feature is very nice and handy, we've > >> >> lived without it for years and people seem to be able to use the > >> >> existing scheme. > >> > >> And, I realize that at some point all of the deadlines are going to be > >> arbitrary; but I have always felt this is important enough to get an > >> exception. I consider having to muck about with sysfs to be basically > >> a UI bug that really needs fixing. I have a lot of other things that > >> I would like to get done for the 4.2 release; but I thought this was > >> important enough to get priority (above the PoD patch series, for > >> instance). NB I'm not saying that you should accept it because I > >> worked on it; I only bring it up to demonstrate how important I think > >> the feature is. > > > OK, given that the code is basically self contained and shouldn't effect > > anything unless a user "opts-in" to using it I think you've convinced > > me. Lets take this (I'll review the actual patches shortly). > > > BTW, IMHO it is preferable for actual deployments to use the kernel > > command line options to hide devices rather than either this feature or > > sysfs. > > > Fully hiding the device from dom0 drivers generally seems like it is > > always better. That way the first driver to try and touch the hardware > > is the one inside the domU. This avoids issues with dom0 drivers setting > > stuff up but not tearing it down in a way that domU can cope with and > > makes the use of hardware which doesn't support FLR more reliable etc. > > Haven't checked it (haven't got the time right now) but: > Is using wildcards in the BDF's on the commandline supported already > (like the ones supported in the config files for domains) Based on a quick scan of the code it doesn't appear so, I don't maintain PCI backthough so there might be something in the pipeline. > I tend to have quite long commandlines to hide a pci-e card with 8 > functions (needed to specify 8 BDF's seperatly) for pci passthrough, > would be nice if one could just specify 09:00.* for example. It sounds useful to me. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:17:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14: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 ) id 1SSUAx-0006HN-9j; Thu, 10 May 2012 14:17:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUAv-0006HG-RK for xen-devel@lists.xen.org; Thu, 10 May 2012 14:17:02 +0000 Received: from [85.158.139.83:40855] by server-6.bemta-5.messagelabs.com id 1D/9B-13222-DDDCBAF4; Thu, 10 May 2012 14:17:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336659419!24976548!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2547 invoked from network); 10 May 2012 14:16:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 14:16:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12408914" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 14:16: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, 10 May 2012 15:16:58 +0100 Message-ID: <1336659417.14220.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Thu, 10 May 2012 15:16:57 +0100 In-Reply-To: <686683228.20120510161211@eikelenboom.it> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> <686683228.20120510161211@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:12 +0100, Sander Eikelenboom wrote: > Hello Ian, > > Thursday, May 10, 2012, 12:38:40 PM, you wrote: > > > On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote: > >> On Wed, May 9, 2012 at 2:45 PM, George Dunlap > >> wrote: > >> > On 09/05/12 12:59, Ian Campbell wrote: > >> >> > >> >> Right, however it is strictly speaking a new feature which is not > >> >> mentioned on the TODO list and has not previously been posted (AFAIK, > >> >> please correct me if not) and we are currently supposed to be in feature > >> >> freeze (and have been for several weeks, if not a month). > >> >> > >> >> IIRC this functionality was mooted when the pci permissive patch was > >> >> being done as something which would be a 4.3 feature. > >> >> We need to decide if we want to make an exception for this new feature > >> >> or not. Although I'm sure this feature is very nice and handy, we've > >> >> lived without it for years and people seem to be able to use the > >> >> existing scheme. > >> > >> And, I realize that at some point all of the deadlines are going to be > >> arbitrary; but I have always felt this is important enough to get an > >> exception. I consider having to muck about with sysfs to be basically > >> a UI bug that really needs fixing. I have a lot of other things that > >> I would like to get done for the 4.2 release; but I thought this was > >> important enough to get priority (above the PoD patch series, for > >> instance). NB I'm not saying that you should accept it because I > >> worked on it; I only bring it up to demonstrate how important I think > >> the feature is. > > > OK, given that the code is basically self contained and shouldn't effect > > anything unless a user "opts-in" to using it I think you've convinced > > me. Lets take this (I'll review the actual patches shortly). > > > BTW, IMHO it is preferable for actual deployments to use the kernel > > command line options to hide devices rather than either this feature or > > sysfs. > > > Fully hiding the device from dom0 drivers generally seems like it is > > always better. That way the first driver to try and touch the hardware > > is the one inside the domU. This avoids issues with dom0 drivers setting > > stuff up but not tearing it down in a way that domU can cope with and > > makes the use of hardware which doesn't support FLR more reliable etc. > > Haven't checked it (haven't got the time right now) but: > Is using wildcards in the BDF's on the commandline supported already > (like the ones supported in the config files for domains) Based on a quick scan of the code it doesn't appear so, I don't maintain PCI backthough so there might be something in the pipeline. > I tend to have quite long commandlines to hide a pci-e card with 8 > functions (needed to specify 8 BDF's seperatly) for pci passthrough, > would be nice if one could just specify 09:00.* for example. It sounds useful to me. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:45:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUbo-0006kb-JE; Thu, 10 May 2012 14:44:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUbm-0006kT-IK for xen-devel@lists.xen.org; Thu, 10 May 2012 14:44:46 +0000 Received: from [85.158.143.99:54445] by server-2.bemta-4.messagelabs.com id DB/3B-17550-C54DBAF4; Thu, 10 May 2012 14:44:44 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336661082!27058840!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2767 invoked from network); 10 May 2012 14:44:43 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:44:43 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEicEn008401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:44:39 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 q4AEibu8012037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:44:38 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AEiYlM012287; Thu, 10 May 2012 09:44:34 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:44:34 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7F5FE4032D; Thu, 10 May 2012 10:38:30 -0400 (EDT) Date: Thu, 10 May 2012 10:38:30 -0400 From: Konrad Rzeszutek Wilk To: "Ren, Yongjie" Message-ID: <20120510143830.GH26152@phenom.dumpdata.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Wu, GabrielX" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > xen-changeset: 25256 > > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > > > Please update your dom0. > > I think we can use 3.4-RCx kernel as dom0 when sending the report next time. Excellent! > > > > > > ============================================================ > > ===== > > > > > > New issue(1) > > > ============== > > > 1. cpu weight out of range error when create hvm domU > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > > > And what is the guest config? Does it have any cpu weights? > > Added the config in the BZ. It doesn't have any cpu weight in config. > Some other person also reported this issue in the mailing list several days ago. I think some of the Citrix folks were going to take a look at this. > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > > 3. [VT-D]fail to detach NIC from guest > > > > Hmm, the last update is from a year ago. Are you sure this > > is an issue? > > > Yeah, it still exist. It may be a similar issue with BZ# 1812. > According to our recent testing, it something about VNC console. > Also added some latest info in the BZ. > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > > > the bug talks about 2.6.32. Can you update it to include the > > 3.4 (or 3.3) dmesg output? > > > This is about 32bit Xen. > As we don't test 32bit Xen for a long time, we may update it when we're free. > > > > 5. [VT-D] device reset fail when create/destroy guest > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > > > Does this happen if you manually echo 1 > ../reset? And is this > > an issue with the kernel if you upgrade it to 3.4-rc5? > > > When doing 'echo 1 >../reset', I get the same error as list in the BZ. > "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". OK, so then the device can't do reset's properly. Is this the physical adaptor or the virtual one? > This bug only exists when we use 'pcistub' to hide a device. Ok, so it looks like upstream Linux can't do this properly on that device. > > > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > > > Where does it slow down? When bringing the NIC down or in specific > > cases? > > Is this an issue with if you are using a different guest (say Fedora Core 16?) > > > We found it is related to 'stdgva' option in guest config file. > If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. > If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. What does turning standard VGA and VNC on mean to the guest? Doesn't that mean that the VGA adapter is gone from the guest? And is this issue only present if you have PCI devices in the guest? Meaning do you get this if you boot a normal HVM guest and do 'stdvga=0' and 'vnc='1? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:45:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUbo-0006kb-JE; Thu, 10 May 2012 14:44:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUbm-0006kT-IK for xen-devel@lists.xen.org; Thu, 10 May 2012 14:44:46 +0000 Received: from [85.158.143.99:54445] by server-2.bemta-4.messagelabs.com id DB/3B-17550-C54DBAF4; Thu, 10 May 2012 14:44:44 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336661082!27058840!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2767 invoked from network); 10 May 2012 14:44:43 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:44:43 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEicEn008401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:44:39 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 q4AEibu8012037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:44:38 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AEiYlM012287; Thu, 10 May 2012 09:44:34 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:44:34 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7F5FE4032D; Thu, 10 May 2012 10:38:30 -0400 (EDT) Date: Thu, 10 May 2012 10:38:30 -0400 From: Konrad Rzeszutek Wilk To: "Ren, Yongjie" Message-ID: <20120510143830.GH26152@phenom.dumpdata.com> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Wu, GabrielX" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > xen-changeset: 25256 > > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > > > Please update your dom0. > > I think we can use 3.4-RCx kernel as dom0 when sending the report next time. Excellent! > > > > > > ============================================================ > > ===== > > > > > > New issue(1) > > > ============== > > > 1. cpu weight out of range error when create hvm domU > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > > > And what is the guest config? Does it have any cpu weights? > > Added the config in the BZ. It doesn't have any cpu weight in config. > Some other person also reported this issue in the mailing list several days ago. I think some of the Citrix folks were going to take a look at this. > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > > 3. [VT-D]fail to detach NIC from guest > > > > Hmm, the last update is from a year ago. Are you sure this > > is an issue? > > > Yeah, it still exist. It may be a similar issue with BZ# 1812. > According to our recent testing, it something about VNC console. > Also added some latest info in the BZ. > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > > > the bug talks about 2.6.32. Can you update it to include the > > 3.4 (or 3.3) dmesg output? > > > This is about 32bit Xen. > As we don't test 32bit Xen for a long time, we may update it when we're free. > > > > 5. [VT-D] device reset fail when create/destroy guest > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > > > Does this happen if you manually echo 1 > ../reset? And is this > > an issue with the kernel if you upgrade it to 3.4-rc5? > > > When doing 'echo 1 >../reset', I get the same error as list in the BZ. > "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". OK, so then the device can't do reset's properly. Is this the physical adaptor or the virtual one? > This bug only exists when we use 'pcistub' to hide a device. Ok, so it looks like upstream Linux can't do this properly on that device. > > > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > > > Where does it slow down? When bringing the NIC down or in specific > > cases? > > Is this an issue with if you are using a different guest (say Fedora Core 16?) > > > We found it is related to 'stdgva' option in guest config file. > If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. > If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. What does turning standard VGA and VNC on mean to the guest? Doesn't that mean that the VGA adapter is gone from the guest? And is this issue only present if you have PCI devices in the guest? Meaning do you get this if you boot a normal HVM guest and do 'stdvga=0' and 'vnc='1? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:49:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUfh-0006u3-8K; Thu, 10 May 2012 14:48:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUfg-0006tu-0p for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:48:48 +0000 Received: from [85.158.139.83:34670] by server-3.bemta-5.messagelabs.com id 14/0E-25237-F45DBAF4; Thu, 10 May 2012 14:48:47 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336661325!20470941!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30264 invoked from network); 10 May 2012 14:48:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:48:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEmgEt005902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:48:43 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 q4AEmgPZ010839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:48:42 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 q4AEmfoq029455; Thu, 10 May 2012 09:48:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:48:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4F45D4032D; Thu, 10 May 2012 10:42:37 -0400 (EDT) Date: Thu, 10 May 2012 10:42:37 -0400 From: Konrad Rzeszutek Wilk To: Dan Magenheimer Message-ID: <20120510144237.GI26152@phenom.dumpdata.com> References: <1335728058.4574.18.camel@localhost> <1335953632.3599.16.camel@localhost> <3a2da977-299d-4200-8f31-542b8a4fcb34@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3a2da977-299d-4200-8f31-542b8a4fcb34@default> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Jana Saout Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 10:51:12AM -0700, Dan Magenheimer wrote: > > From: Jana Saout [mailto:jana@saout.de] > > Subject: Re: [Xen-devel] Self-ballooning question / cache issue > > > > Hi Jana -- > > Since you have tested this patch and have found it useful, and > since its use is entirely optional, it is OK with me for it to > be upstreamed at the next window. Konrad cc'ed. > > You will need to add a Signed-off-by line to the patch > but other than that you can consider it > > Acked-by: Dan Magenheimer Looks good. Can you resend it with the right tags to xen-devel and lkml and to me please? > > > > Your idea of the tunable is interesting (and patches are always > > > welcome!) but I am skeptical that it will solve the problem > > > since I would guess the Linux kernel is shrinking dcache > > > proportional to the size of the page cache. So adding more > > > RAM with your "user-specified amount of pages that is > > > added on top of the computed target number of pages", > > > the RAM will still be shared across all caches and only > > > some small portion of the added RAM will likely be used > > > for dcache. > > > > That's true. In fact, I have to add about 1 GB of memory in order to > > keep the relevant dcache / inode cache entries to stay in the cache. > > When I do that the largest portion of memory is still eaten up by the > > regular page cache. So this is more of a workaround than a solution, > > but for now it works. > > > > I've attached the simple patch I've whipped up below. > > > > > However, if you have a chance to try it, I would be interested > > > in your findings. Note that you already can set a > > > permanent floor for selfballooning ("min_usable_mb") or, > > > of course, just turn off selfballooning altogether. > > > > Sure, that's always a possibility. However, the VM already had an > > overly large amount of memory before to avoid the problem. Now it runs > > with less memory (still a bit more than required), and when a load spike > > comes, it can quickly balloon up, which is exactly what I was looking > > for. > > > > Jana > > > > ---- > > Author: Jana Saout > > Date: Sun Apr 29 22:09:29 2012 +0200 > > > > Add selfballoning memory reservation tunable. > > > > diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c > > index 146c948..7d041cb 100644 > > --- a/drivers/xen/xen-selfballoon.c > > +++ b/drivers/xen/xen-selfballoon.c > > @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; > > */ > > static unsigned int selfballoon_min_usable_mb; > > > > +/* > > + * Amount of RAM in MB to add to the target number of pages. > > + * Can be used to reserve some more room for caches and the like. > > + */ > > +static unsigned int selfballoon_reserved_mb; > > + > > static void selfballoon_process(struct work_struct *work); > > static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); > > > > @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) > > cur_pages = totalram_pages; > > tgt_pages = cur_pages; /* default is no change */ > > goal_pages = percpu_counter_read_positive(&vm_committed_as) + > > - totalreserve_pages; > > + totalreserve_pages + > > + MB2PAGES(selfballoon_reserved_mb); > > #ifdef CONFIG_FRONTSWAP > > /* allow space for frontswap pages to be repatriated */ > > if (frontswap_selfshrinking && frontswap_enabled) > > @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, > > show_selfballoon_min_usable_mb, > > store_selfballoon_min_usable_mb); > > > > +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", > > + selfballoon_reserved_mb); > > + > > +static ssize_t store_selfballoon_reserved_mb(struct device *dev, > > + struct device_attribute *attr, > > + const char *buf, > > + size_t count) > > +{ > > + unsigned long val; > > + int err; > > + > > + if (!capable(CAP_SYS_ADMIN)) > > + return -EPERM; > > + err = strict_strtoul(buf, 10, &val); > > + if (err) > > + return -EINVAL; > > + selfballoon_reserved_mb = val; > > + return count; > > +} > > + > > +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, > > + show_selfballoon_reserved_mb, > > + store_selfballoon_reserved_mb); > > + > > > > #ifdef CONFIG_FRONTSWAP > > SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); > > @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { > > &dev_attr_selfballoon_downhysteresis.attr, > > &dev_attr_selfballoon_uphysteresis.attr, > > &dev_attr_selfballoon_min_usable_mb.attr, > > + &dev_attr_selfballoon_reserved_mb.attr, > > #ifdef CONFIG_FRONTSWAP > > &dev_attr_frontswap_selfshrinking.attr, > > &dev_attr_frontswap_hysteresis.attr, > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:49:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUfh-0006u3-8K; Thu, 10 May 2012 14:48:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUfg-0006tu-0p for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:48:48 +0000 Received: from [85.158.139.83:34670] by server-3.bemta-5.messagelabs.com id 14/0E-25237-F45DBAF4; Thu, 10 May 2012 14:48:47 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336661325!20470941!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30264 invoked from network); 10 May 2012 14:48:46 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:48:46 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEmgEt005902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:48:43 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 q4AEmgPZ010839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:48:42 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 q4AEmfoq029455; Thu, 10 May 2012 09:48:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:48:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4F45D4032D; Thu, 10 May 2012 10:42:37 -0400 (EDT) Date: Thu, 10 May 2012 10:42:37 -0400 From: Konrad Rzeszutek Wilk To: Dan Magenheimer Message-ID: <20120510144237.GI26152@phenom.dumpdata.com> References: <1335728058.4574.18.camel@localhost> <1335953632.3599.16.camel@localhost> <3a2da977-299d-4200-8f31-542b8a4fcb34@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3a2da977-299d-4200-8f31-542b8a4fcb34@default> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com, Jana Saout Subject: Re: [Xen-devel] Self-ballooning question / cache issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 02, 2012 at 10:51:12AM -0700, Dan Magenheimer wrote: > > From: Jana Saout [mailto:jana@saout.de] > > Subject: Re: [Xen-devel] Self-ballooning question / cache issue > > > > Hi Jana -- > > Since you have tested this patch and have found it useful, and > since its use is entirely optional, it is OK with me for it to > be upstreamed at the next window. Konrad cc'ed. > > You will need to add a Signed-off-by line to the patch > but other than that you can consider it > > Acked-by: Dan Magenheimer Looks good. Can you resend it with the right tags to xen-devel and lkml and to me please? > > > > Your idea of the tunable is interesting (and patches are always > > > welcome!) but I am skeptical that it will solve the problem > > > since I would guess the Linux kernel is shrinking dcache > > > proportional to the size of the page cache. So adding more > > > RAM with your "user-specified amount of pages that is > > > added on top of the computed target number of pages", > > > the RAM will still be shared across all caches and only > > > some small portion of the added RAM will likely be used > > > for dcache. > > > > That's true. In fact, I have to add about 1 GB of memory in order to > > keep the relevant dcache / inode cache entries to stay in the cache. > > When I do that the largest portion of memory is still eaten up by the > > regular page cache. So this is more of a workaround than a solution, > > but for now it works. > > > > I've attached the simple patch I've whipped up below. > > > > > However, if you have a chance to try it, I would be interested > > > in your findings. Note that you already can set a > > > permanent floor for selfballooning ("min_usable_mb") or, > > > of course, just turn off selfballooning altogether. > > > > Sure, that's always a possibility. However, the VM already had an > > overly large amount of memory before to avoid the problem. Now it runs > > with less memory (still a bit more than required), and when a load spike > > comes, it can quickly balloon up, which is exactly what I was looking > > for. > > > > Jana > > > > ---- > > Author: Jana Saout > > Date: Sun Apr 29 22:09:29 2012 +0200 > > > > Add selfballoning memory reservation tunable. > > > > diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c > > index 146c948..7d041cb 100644 > > --- a/drivers/xen/xen-selfballoon.c > > +++ b/drivers/xen/xen-selfballoon.c > > @@ -105,6 +105,12 @@ static unsigned int selfballoon_interval __read_mostly = 5; > > */ > > static unsigned int selfballoon_min_usable_mb; > > > > +/* > > + * Amount of RAM in MB to add to the target number of pages. > > + * Can be used to reserve some more room for caches and the like. > > + */ > > +static unsigned int selfballoon_reserved_mb; > > + > > static void selfballoon_process(struct work_struct *work); > > static DECLARE_DELAYED_WORK(selfballoon_worker, selfballoon_process); > > > > @@ -217,7 +223,8 @@ static void selfballoon_process(struct work_struct *work) > > cur_pages = totalram_pages; > > tgt_pages = cur_pages; /* default is no change */ > > goal_pages = percpu_counter_read_positive(&vm_committed_as) + > > - totalreserve_pages; > > + totalreserve_pages + > > + MB2PAGES(selfballoon_reserved_mb); > > #ifdef CONFIG_FRONTSWAP > > /* allow space for frontswap pages to be repatriated */ > > if (frontswap_selfshrinking && frontswap_enabled) > > @@ -397,6 +404,30 @@ static DEVICE_ATTR(selfballoon_min_usable_mb, S_IRUGO | S_IWUSR, > > show_selfballoon_min_usable_mb, > > store_selfballoon_min_usable_mb); > > > > +SELFBALLOON_SHOW(selfballoon_reserved_mb, "%d\n", > > + selfballoon_reserved_mb); > > + > > +static ssize_t store_selfballoon_reserved_mb(struct device *dev, > > + struct device_attribute *attr, > > + const char *buf, > > + size_t count) > > +{ > > + unsigned long val; > > + int err; > > + > > + if (!capable(CAP_SYS_ADMIN)) > > + return -EPERM; > > + err = strict_strtoul(buf, 10, &val); > > + if (err) > > + return -EINVAL; > > + selfballoon_reserved_mb = val; > > + return count; > > +} > > + > > +static DEVICE_ATTR(selfballoon_reserved_mb, S_IRUGO | S_IWUSR, > > + show_selfballoon_reserved_mb, > > + store_selfballoon_reserved_mb); > > + > > > > #ifdef CONFIG_FRONTSWAP > > SELFBALLOON_SHOW(frontswap_selfshrinking, "%d\n", frontswap_selfshrinking); > > @@ -480,6 +511,7 @@ static struct attribute *selfballoon_attrs[] = { > > &dev_attr_selfballoon_downhysteresis.attr, > > &dev_attr_selfballoon_uphysteresis.attr, > > &dev_attr_selfballoon_min_usable_mb.attr, > > + &dev_attr_selfballoon_reserved_mb.attr, > > #ifdef CONFIG_FRONTSWAP > > &dev_attr_frontswap_selfshrinking.attr, > > &dev_attr_frontswap_hysteresis.attr, > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:50:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:50:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh6-000700-GR; Thu, 10 May 2012 14:50:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh4-0006zD-9c for xen-devel@lists.xen.org; Thu, 10 May 2012 14:50:14 +0000 Received: from [85.158.143.35:4213] by server-2.bemta-4.messagelabs.com id 9B/74-17550-5A5DBAF4; Thu, 10 May 2012 14:50:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336661401!11642650!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1391 invoked from network); 10 May 2012 14:50:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:50:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEnwsp007214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:49:59 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 q4AEnvsZ013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:49:58 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AEnvUC026464; Thu, 10 May 2012 09:49:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:49:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 69DC64032D; Thu, 10 May 2012 10:43:53 -0400 (EDT) Date: Thu, 10 May 2012 10:43:53 -0400 From: Konrad Rzeszutek Wilk To: Lars Kurth Message-ID: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F912F15.2030202@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-api@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > Hi everybody, > > we have another Xen Documentation Day come up next Monday, April 23. When is the next one? I am itching to write some new docs! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:50:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:50:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh6-000700-GR; Thu, 10 May 2012 14:50:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUh4-0006zD-9c for xen-devel@lists.xen.org; Thu, 10 May 2012 14:50:14 +0000 Received: from [85.158.143.35:4213] by server-2.bemta-4.messagelabs.com id 9B/74-17550-5A5DBAF4; Thu, 10 May 2012 14:50:13 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336661401!11642650!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1391 invoked from network); 10 May 2012 14:50:11 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 14:50:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AEnwsp007214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 14:49:59 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 q4AEnvsZ013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 14:49:58 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AEnvUC026464; Thu, 10 May 2012 09:49:57 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 07:49:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 69DC64032D; Thu, 10 May 2012 10:43:53 -0400 (EDT) Date: Thu, 10 May 2012 10:43:53 -0400 From: Konrad Rzeszutek Wilk To: Lars Kurth Message-ID: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F912F15.2030202@xen.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-api@lists.xen.org, xen-arm@lists.xen.org, xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > Hi everybody, > > we have another Xen Documentation Day come up next Monday, April 23. When is the next one? I am itching to write some new docs! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:54:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14: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 ) id 1SSUky-0007Sy-6i; Thu, 10 May 2012 14:54:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUkw-0007Sk-NE for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:54:15 +0000 Received: from [193.109.254.147:13051] by server-3.bemta-14.messagelabs.com id 03/50-23274-696DBAF4; Thu, 10 May 2012 14:54:14 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336661652!1758296!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5060 invoked from network); 10 May 2012 14:54:13 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-14.tower-27.messagelabs.com with SMTP; 10 May 2012 14:54:13 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 07:54:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141424688" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 10 May 2012 07:54:10 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 07:54:09 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Thu, 10 May 2012 22:54:07 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNHys61b8pDRiwSFiwkpXixs4X8JbDMq/Q Date: Thu, 10 May 2012 14:54:07 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> In-Reply-To: <20120420192439.GA32170@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad, Thanks for help me review! Update according to your suggestion. Add some comments below. >> >> Manage physical cpus in dom0, get physical cpus info and provide sys >> interface. > > Anything that exposes SysFS attributes needs documentation in > Documentation/ABI Yes, added. > > Can you explain what this solves? And if there are any > userland applications that use this? > It provide cpu online/offline interface to user. User can use it for their own purpose, like power saving - by offlining some cpus when light workload it save power greatly. > > >> + switch (buf[0]) { > > Use strict_strtoull pls. kernel suggest: WARNING: strict_strtoull is obsolete, use kstrtoull instead :) > >> + case '0': >> + ret = xen_pcpu_down(cpu->xen_id); >> + break; >> + case '1': >> + ret = xen_pcpu_up(cpu->xen_id); >> + break; >> + default: >> + ret = -EINVAL; >> + } >> + >> + if (ret >= 0) >> + ret = count; >> + return ret; >> +} >> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, >> store_online); > >> + >> +static ssize_t show_apicid(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct pcpu *cpu = container_of(dev, struct pcpu, dev); + >> + return sprintf(buf, "%u\n", cpu->apic_id); >> +} >> + >> +static ssize_t show_acpiid(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct pcpu *cpu = container_of(dev, struct pcpu, dev); + >> + return sprintf(buf, "%u\n", cpu->acpi_id); >> +} >> +static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL); >> +static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL); > > What benefit is there in exposing these values to the user? Yes, no benefit so let's cancel exposing acpi_id and apic_id. >> + >> +static void pcpu_sys_remove(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + >> + if (!pcpu) >> + return; >> + >> + dev = &pcpu->dev; >> + if (dev->id) >> + device_remove_file(dev, &dev_attr_online); >> + device_remove_file(dev, &dev_attr_acpi_id); >> + device_remove_file(dev, &dev_attr_apic_id); >> + device_unregister(dev); > > So .. if you are using that, can't you use the .release > and define something like: > > static void pcpu_release(struct device *dev) > { > struct pcpu *pcpu = container_of(dev, struct pcpu, dev); > > list_del(&pcpu->pcpu_list); > kfree(pcpu); > } >> +} >> + >> +static void free_pcpu(struct pcpu *pcpu) >> +{ >> + if (!pcpu) >> + return; >> + >> + pcpu_sys_remove(pcpu); > >> + list_del(&pcpu->pcpu_list); >> + kfree(pcpu); > > Those two shouldn't be there. They sould be part of the > release function. >> +} >> + >> +static int pcpu_sys_create(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + int err = -EINVAL; >> + >> + if (!pcpu) >> + return err; >> + >> + dev = &pcpu->dev; >> + dev->bus = &xen_pcpu_subsys; >> + dev->id = pcpu->xen_id; > > And then here dev->release = &pcpu_release; > Hmm, it's good if it's convenient to do it automatically via dev->release. However, dev container (pcpu) would be free at some other error cases, so I prefer do it 'manually'. > >> + /* Not open pcpu0 online access to user */ > > Huh? You mean "Nobody can touch PCPU0" ? Add comments: /* * Xen never offline cpu0 due to several restrictions * and assumptions. This basically doesn't add a sys control * to user, one cannot attempt to offline BSP. */ > > Why? Why can they touch the other ones? And better yet, > what happens if one boots without "dom0_max_vcpus=X" > and powers of some of the CPUs? > Only those at cpu present map has its sys interface. >> +static int __init xen_pcpu_init(void) >> +{ >> + int ret; >> + >> + if (!xen_initial_domain()) >> + return -ENODEV; >> + >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); >> + return ret; + } >> + >> + INIT_LIST_HEAD(&xen_pcpus.list); >> + >> + ret = xen_sync_pcpus(); >> + if (ret) { >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + return ret; >> + } >> + >> + ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, >> + xen_pcpu_interrupt, 0, >> + "pcpu", NULL); > > "xen-pcpu" > >> + if (ret < 0) { >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > > Shouldn't you delete what 'xen_sync_pcpus' did? yes, add error handling. > Or is it OK to still work without the interrupts? What is the purpose > of that interrupt? How does it actually work - the hypervisor > decides when/where to turn off CPUs? > user online/offline cpu via sys interface --> xen implement --> inject virq back to dom0 --> sync cpu status. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:54:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14: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 ) id 1SSUky-0007Sy-6i; Thu, 10 May 2012 14:54:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUkw-0007Sk-NE for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:54:15 +0000 Received: from [193.109.254.147:13051] by server-3.bemta-14.messagelabs.com id 03/50-23274-696DBAF4; Thu, 10 May 2012 14:54:14 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336661652!1758296!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5060 invoked from network); 10 May 2012 14:54:13 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-14.tower-27.messagelabs.com with SMTP; 10 May 2012 14:54:13 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 07:54:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141424688" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 10 May 2012 07:54:10 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 07:54:09 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Thu, 10 May 2012 22:54:07 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNHys61b8pDRiwSFiwkpXixs4X8JbDMq/Q Date: Thu, 10 May 2012 14:54:07 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> In-Reply-To: <20120420192439.GA32170@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad, Thanks for help me review! Update according to your suggestion. Add some comments below. >> >> Manage physical cpus in dom0, get physical cpus info and provide sys >> interface. > > Anything that exposes SysFS attributes needs documentation in > Documentation/ABI Yes, added. > > Can you explain what this solves? And if there are any > userland applications that use this? > It provide cpu online/offline interface to user. User can use it for their own purpose, like power saving - by offlining some cpus when light workload it save power greatly. > > >> + switch (buf[0]) { > > Use strict_strtoull pls. kernel suggest: WARNING: strict_strtoull is obsolete, use kstrtoull instead :) > >> + case '0': >> + ret = xen_pcpu_down(cpu->xen_id); >> + break; >> + case '1': >> + ret = xen_pcpu_up(cpu->xen_id); >> + break; >> + default: >> + ret = -EINVAL; >> + } >> + >> + if (ret >= 0) >> + ret = count; >> + return ret; >> +} >> +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, >> store_online); > >> + >> +static ssize_t show_apicid(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct pcpu *cpu = container_of(dev, struct pcpu, dev); + >> + return sprintf(buf, "%u\n", cpu->apic_id); >> +} >> + >> +static ssize_t show_acpiid(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct pcpu *cpu = container_of(dev, struct pcpu, dev); + >> + return sprintf(buf, "%u\n", cpu->acpi_id); >> +} >> +static DEVICE_ATTR(apic_id, S_IRUGO, show_apicid, NULL); >> +static DEVICE_ATTR(acpi_id, S_IRUGO, show_acpiid, NULL); > > What benefit is there in exposing these values to the user? Yes, no benefit so let's cancel exposing acpi_id and apic_id. >> + >> +static void pcpu_sys_remove(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + >> + if (!pcpu) >> + return; >> + >> + dev = &pcpu->dev; >> + if (dev->id) >> + device_remove_file(dev, &dev_attr_online); >> + device_remove_file(dev, &dev_attr_acpi_id); >> + device_remove_file(dev, &dev_attr_apic_id); >> + device_unregister(dev); > > So .. if you are using that, can't you use the .release > and define something like: > > static void pcpu_release(struct device *dev) > { > struct pcpu *pcpu = container_of(dev, struct pcpu, dev); > > list_del(&pcpu->pcpu_list); > kfree(pcpu); > } >> +} >> + >> +static void free_pcpu(struct pcpu *pcpu) >> +{ >> + if (!pcpu) >> + return; >> + >> + pcpu_sys_remove(pcpu); > >> + list_del(&pcpu->pcpu_list); >> + kfree(pcpu); > > Those two shouldn't be there. They sould be part of the > release function. >> +} >> + >> +static int pcpu_sys_create(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + int err = -EINVAL; >> + >> + if (!pcpu) >> + return err; >> + >> + dev = &pcpu->dev; >> + dev->bus = &xen_pcpu_subsys; >> + dev->id = pcpu->xen_id; > > And then here dev->release = &pcpu_release; > Hmm, it's good if it's convenient to do it automatically via dev->release. However, dev container (pcpu) would be free at some other error cases, so I prefer do it 'manually'. > >> + /* Not open pcpu0 online access to user */ > > Huh? You mean "Nobody can touch PCPU0" ? Add comments: /* * Xen never offline cpu0 due to several restrictions * and assumptions. This basically doesn't add a sys control * to user, one cannot attempt to offline BSP. */ > > Why? Why can they touch the other ones? And better yet, > what happens if one boots without "dom0_max_vcpus=X" > and powers of some of the CPUs? > Only those at cpu present map has its sys interface. >> +static int __init xen_pcpu_init(void) >> +{ >> + int ret; >> + >> + if (!xen_initial_domain()) >> + return -ENODEV; >> + >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); >> + return ret; + } >> + >> + INIT_LIST_HEAD(&xen_pcpus.list); >> + >> + ret = xen_sync_pcpus(); >> + if (ret) { >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + return ret; >> + } >> + >> + ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, >> + xen_pcpu_interrupt, 0, >> + "pcpu", NULL); > > "xen-pcpu" > >> + if (ret < 0) { >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > > Shouldn't you delete what 'xen_sync_pcpus' did? yes, add error handling. > Or is it OK to still work without the interrupts? What is the purpose > of that interrupt? How does it actually work - the hypervisor > decides when/where to turn off CPUs? > user online/offline cpu via sys interface --> xen implement --> inject virq back to dom0 --> sync cpu status. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:59:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:59:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUq5-0007mO-P7; Thu, 10 May 2012 14:59:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUq4-0007m1-7m for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:59:32 +0000 Received: from [85.158.138.51:4427] by server-2.bemta-3.messagelabs.com id 0B/D1-09269-3D7DBAF4; Thu, 10 May 2012 14:59:31 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336661970!17460442!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28287 invoked from network); 10 May 2012 14:59:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 14:59:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 14:59: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, 10 May 2012 15:59:29 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSUq1-0007r6-NP; Thu, 10 May 2012 14:59:29 +0000 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 10 May 2012 15:59:19 +0100 Message-ID: <1336661959-13259-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH] x86/hvm: put value of emulated register reads into trace records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The tracepoint for emulated MMIO and I/O port reads was always before the emulated read or write was done. This means that for reads the register value in the trace record was always 0. So for reads, move the tracepoint until the register value is available. Signed-off-by: David Vrabel Cc: George Dunlap --- A candidate for 4.0 and 4.1? --- xen/arch/x86/hvm/emulate.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index 82efd1a..3a7fe95 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -191,7 +191,8 @@ static int hvmemul_do_io( p->df = df; p->data = value; - hvmtrace_io_assist(is_mmio, p); + if ( dir == IOREQ_WRITE ) + hvmtrace_io_assist(is_mmio, p); if ( is_mmio ) { @@ -232,6 +233,9 @@ static int hvmemul_do_io( } finish_access: + if ( dir == IOREQ_READ ) + hvmtrace_io_assist(is_mmio, p); + if ( p_data != NULL ) memcpy(p_data, &vio->io_data, size); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 14:59:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 14:59:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUq5-0007mO-P7; Thu, 10 May 2012 14:59:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUq4-0007m1-7m for xen-devel@lists.xensource.com; Thu, 10 May 2012 14:59:32 +0000 Received: from [85.158.138.51:4427] by server-2.bemta-3.messagelabs.com id 0B/D1-09269-3D7DBAF4; Thu, 10 May 2012 14:59:31 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336661970!17460442!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28287 invoked from network); 10 May 2012 14:59:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 14:59:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 14:59: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, 10 May 2012 15:59:29 +0100 Received: from spare.cam.xci-test.com ([10.80.2.76] helo=qabil.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSUq1-0007r6-NP; Thu, 10 May 2012 14:59:29 +0000 From: David Vrabel To: xen-devel@lists.xensource.com Date: Thu, 10 May 2012 15:59:19 +0100 Message-ID: <1336661959-13259-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH] x86/hvm: put value of emulated register reads into trace records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel The tracepoint for emulated MMIO and I/O port reads was always before the emulated read or write was done. This means that for reads the register value in the trace record was always 0. So for reads, move the tracepoint until the register value is available. Signed-off-by: David Vrabel Cc: George Dunlap --- A candidate for 4.0 and 4.1? --- xen/arch/x86/hvm/emulate.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index 82efd1a..3a7fe95 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -191,7 +191,8 @@ static int hvmemul_do_io( p->df = df; p->data = value; - hvmtrace_io_assist(is_mmio, p); + if ( dir == IOREQ_WRITE ) + hvmtrace_io_assist(is_mmio, p); if ( is_mmio ) { @@ -232,6 +233,9 @@ static int hvmemul_do_io( } finish_access: + if ( dir == IOREQ_READ ) + hvmtrace_io_assist(is_mmio, p); + if ( p_data != NULL ) memcpy(p_data, &vio->io_data, size); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:01:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:01:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUrY-0007yY-9o; Thu, 10 May 2012 15:01:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUrW-0007yF-Qh for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:01:03 +0000 Received: from [85.158.143.99:43227] by server-1.bemta-4.messagelabs.com id 0E/5B-20925-E28DBAF4; Thu, 10 May 2012 15:01:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336662059!24022551!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7262 invoked from network); 10 May 2012 15:01:00 -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; 10 May 2012 15:01:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194274615" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:56:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 10:56:54 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUnW-0007HN-IA; Thu, 10 May 2012 15:56:54 +0100 Message-ID: <4FABD6EF.4020607@eu.citrix.com> Date: Thu, 10 May 2012 15:55:43 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> In-Reply-To: <1336648786.7098.89.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:19, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: >> Introduce libxl helper functions to prepare devices to be passed through to >> guests. This is meant to replace of all the manual sysfs commands which >> are currently required. >> >> pci_assignable_add accepts a BDF for a device and will: >> * Unbind a device from its current driver, if any >> * If "rebind" is set, it will store the path of the driver from which we >> unplugged it in /libxl/pciback/$BDF/driver_path > Since you don't know whether the user is going to pass -r to > assignable_remove why not always store this? The xl command does in fact do this (i.e., always passes '1' here). I considered just taking this option out, as you suggest, but I thought it might be useful for the libxl implementation to have more flexibility. >> * If necessary, create a slot for it in pciback > I must confess I'm a bit fuzzy on the relationship between slots and > bindings, where does the "if necessary" come into it? > > I was wondering while reading the patch if unconditionally adding a > removing the slot might simplify a bunch of stuff, but I suspect I just > don't appreciate some particular aspect of how pciback works... I have no idea what the "slot" thing is for. What I've determined by experimentation is: * Before "echo $BDF > .../pciback/bind" will work, $BDF must be listed in pciback/slots * The way to get $BDF listed in pciback/slots is "echo $BDF > pciback/new_slot" * The above command is not idempotent; if you do it twice, you'll get two entries of $BDF in pciback/slots I wasn't sure if having two slots would be a problem or not; so I did the conservative thing, and check for the existence of $BDF in pciback/slots first, only creating a new slot if there is not already an existing slot. So "if necessary" means, "if the device doesn't already have a slot". >> + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", >> + pcidev->domain, >> + pcidev->bus, >> + pcidev->dev, >> + pcidev->func); >> + if ( !lstat(spath,&st) ) { >> + /* Find the canonical path to the driver. */ >> + *dp = libxl__zalloc(gc, PATH_MAX); > Should we be actually using fpathconf / sysconf here? I don't really follow. What exactly is it you're proposing? >> + *dp = realpath(spath, *dp); >> + if ( !*dp ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); > Since errno is meaningful you want LIBXL__LOGERRNO here. Or the short > form LOGE(). Done. > > Where you have pointer output params (like driver_path here) in general > I think it is preferable to do everything with a local (single > indirection) pointer and only update the output parameter on success. > This means you avoid leaking/exposing a partial result on error but also > means you can drop a lot of "*" from around the function. > > Maybe the gc makes this moot, but the "if ( driver_path )" stuff at the > top of the fn took me several seconds to work out also ;-). Yeah, that's a lot simpler, and easier to read. Done. >> + return -1; >> + } >> + >> + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", >> + *dp); >> + >> + /* Unbind from the old driver */ >> + spath = libxl__sprintf(gc, "%s/unbind", *dp); >> + if ( sysfs_write_bdf(gc, spath, pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); > Not sure what errno is like here, worth printing it. Looking back at > patch #1 I suspect sysfs_write_bdf should preserve errno over the call > to close, so that suitable reporting can happen in the caller. Done. >> +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ >> +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) > Is the concept of "having a slot" distinct from being bound to pciback? Technically, yes. You can't be bound without a slot; but you can have a slot without being bound. I don't know exactly what the "slot" functionality is for, and why it's a separate step, but that's the way it is at the moment. >> +{ >> + libxl_ctx *ctx = libxl__gc_owner(gc); >> + FILE *f; >> + int rc = 0; >> + unsigned bus, dev, func; >> + >> + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); >> + >> + if (f == NULL) { >> + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", >> + SYSFS_PCIBACK_DRIVER"/slots"); >> + return ERROR_FAIL; >> + } >> + >> + while(fscanf(f, "0000:%x:%x.%x\n",&bus,&dev,&func)==3) { > Jan recently added support for PCI domains, does that have any impact on > the hardcoded 0000 here? I suppose that would require PCI domains > support in the dom0 kernel -- but that seems likely to already be there > (or be imminent) > > I think the 0000 should be %x into domain compared with pcidev->domain. Ah, right -- I don't think I knew anything about the whole PCI domains thing. Done. > >> + if ( (rc=pciback_dev_has_slot(gc, pcidev))< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Error checking for pciback slot"); > Log errno? > > Also pciback_dev_has_slot itself always logs on error, you probably > don't need both. This way you get a sort of callback path; but I could take it out if you want. > >> + return ERROR_FAIL; >> + } else if (rc == 0) { >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", >> + pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Couldn't bind device to pciback!"); > ERRNO here too. ack > >> + return ERROR_FAIL; >> + } >> + } >> + >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); > ERRNO here too. Or since there are loads of these perhaps sysfs_write_bf > should log on failure, either just the fact of the failed write to a > path (which implies the underlying failure was to bind/unbind) or you > could add a "const char *what" param to use in logging. Just doing ERRNO for all the callers makes more sense to me. >> + /* Remove slot if necessary */ >> + if ( pciback_dev_has_slot(gc, pcidev)> 0 ) { >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", >> + pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Couldn't remove pciback slot"); > ERRNO ack > >> + return ERROR_FAIL; >> + } >> + } >> + return 0; >> +} >> + >> +/* FIXME */ > Leftover? Yeah, noticed this just after I sent it. :-) >> +retry: >> + t = xs_transaction_start(ctx->xsh); >> + >> + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", >> + pcidev->domain, >> + pcidev->bus, >> + pcidev->dev, >> + pcidev->func); >> + xs_rm(ctx->xsh, t, path); > Why do you need to rm first? Won't the write just replace whatever it is > (and that means the need for a transaction goes away too) > > In any case you should create path outside the retry loop instead of > needlessly recreating it each time around. TBH, I just looked at another bit of code that did xs transactions and tried to follow suit. Since I only need one operation, I'll take out the transaction stuff. >> + xs_rm(ctx->xsh, t, path); > You don't need a transaction for a single operation. (and if you did > then "path = ..." could have been hoisted out) Very well. > >> +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, >> + int rebind) >> +{ >> + GC_INIT(ctx); >> + int rc; >> + >> + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); >> + >> + GC_FREE; >> + return rc; >> +} > Are there internal callers of libxl__device_pci_assignable_add/remove? > If not then there's no reason to split into internal/external functions. > Doesn't matter much I guess. Not yet, but I don't think it hurts to have that flexibility. Thanks for the detailed review. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:01:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:01:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUrY-0007yY-9o; Thu, 10 May 2012 15:01:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUrW-0007yF-Qh for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:01:03 +0000 Received: from [85.158.143.99:43227] by server-1.bemta-4.messagelabs.com id 0E/5B-20925-E28DBAF4; Thu, 10 May 2012 15:01:02 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336662059!24022551!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7262 invoked from network); 10 May 2012 15:01:00 -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; 10 May 2012 15:01:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194274615" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 10:56:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 10:56:54 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUnW-0007HN-IA; Thu, 10 May 2012 15:56:54 +0100 Message-ID: <4FABD6EF.4020607@eu.citrix.com> Date: Thu, 10 May 2012 15:55:43 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> In-Reply-To: <1336648786.7098.89.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/05/12 12:19, Ian Campbell wrote: > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: >> Introduce libxl helper functions to prepare devices to be passed through to >> guests. This is meant to replace of all the manual sysfs commands which >> are currently required. >> >> pci_assignable_add accepts a BDF for a device and will: >> * Unbind a device from its current driver, if any >> * If "rebind" is set, it will store the path of the driver from which we >> unplugged it in /libxl/pciback/$BDF/driver_path > Since you don't know whether the user is going to pass -r to > assignable_remove why not always store this? The xl command does in fact do this (i.e., always passes '1' here). I considered just taking this option out, as you suggest, but I thought it might be useful for the libxl implementation to have more flexibility. >> * If necessary, create a slot for it in pciback > I must confess I'm a bit fuzzy on the relationship between slots and > bindings, where does the "if necessary" come into it? > > I was wondering while reading the patch if unconditionally adding a > removing the slot might simplify a bunch of stuff, but I suspect I just > don't appreciate some particular aspect of how pciback works... I have no idea what the "slot" thing is for. What I've determined by experimentation is: * Before "echo $BDF > .../pciback/bind" will work, $BDF must be listed in pciback/slots * The way to get $BDF listed in pciback/slots is "echo $BDF > pciback/new_slot" * The above command is not idempotent; if you do it twice, you'll get two entries of $BDF in pciback/slots I wasn't sure if having two slots would be a problem or not; so I did the conservative thing, and check for the existence of $BDF in pciback/slots first, only creating a new slot if there is not already an existing slot. So "if necessary" means, "if the device doesn't already have a slot". >> + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", >> + pcidev->domain, >> + pcidev->bus, >> + pcidev->dev, >> + pcidev->func); >> + if ( !lstat(spath,&st) ) { >> + /* Find the canonical path to the driver. */ >> + *dp = libxl__zalloc(gc, PATH_MAX); > Should we be actually using fpathconf / sysconf here? I don't really follow. What exactly is it you're proposing? >> + *dp = realpath(spath, *dp); >> + if ( !*dp ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "realpath() failed"); > Since errno is meaningful you want LIBXL__LOGERRNO here. Or the short > form LOGE(). Done. > > Where you have pointer output params (like driver_path here) in general > I think it is preferable to do everything with a local (single > indirection) pointer and only update the output parameter on success. > This means you avoid leaking/exposing a partial result on error but also > means you can drop a lot of "*" from around the function. > > Maybe the gc makes this moot, but the "if ( driver_path )" stuff at the > top of the fn took me several seconds to work out also ;-). Yeah, that's a lot simpler, and easier to read. Done. >> + return -1; >> + } >> + >> + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", >> + *dp); >> + >> + /* Unbind from the old driver */ >> + spath = libxl__sprintf(gc, "%s/unbind", *dp); >> + if ( sysfs_write_bdf(gc, spath, pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); > Not sure what errno is like here, worth printing it. Looking back at > patch #1 I suspect sysfs_write_bdf should preserve errno over the call > to close, so that suitable reporting can happen in the caller. Done. >> +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ >> +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) > Is the concept of "having a slot" distinct from being bound to pciback? Technically, yes. You can't be bound without a slot; but you can have a slot without being bound. I don't know exactly what the "slot" functionality is for, and why it's a separate step, but that's the way it is at the moment. >> +{ >> + libxl_ctx *ctx = libxl__gc_owner(gc); >> + FILE *f; >> + int rc = 0; >> + unsigned bus, dev, func; >> + >> + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); >> + >> + if (f == NULL) { >> + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", >> + SYSFS_PCIBACK_DRIVER"/slots"); >> + return ERROR_FAIL; >> + } >> + >> + while(fscanf(f, "0000:%x:%x.%x\n",&bus,&dev,&func)==3) { > Jan recently added support for PCI domains, does that have any impact on > the hardcoded 0000 here? I suppose that would require PCI domains > support in the dom0 kernel -- but that seems likely to already be there > (or be imminent) > > I think the 0000 should be %x into domain compared with pcidev->domain. Ah, right -- I don't think I knew anything about the whole PCI domains thing. Done. > >> + if ( (rc=pciback_dev_has_slot(gc, pcidev))< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Error checking for pciback slot"); > Log errno? > > Also pciback_dev_has_slot itself always logs on error, you probably > don't need both. This way you get a sort of callback path; but I could take it out if you want. > >> + return ERROR_FAIL; >> + } else if (rc == 0) { >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", >> + pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Couldn't bind device to pciback!"); > ERRNO here too. ack > >> + return ERROR_FAIL; >> + } >> + } >> + >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); > ERRNO here too. Or since there are loads of these perhaps sysfs_write_bf > should log on failure, either just the fact of the failed write to a > path (which implies the underlying failure was to bind/unbind) or you > could add a "const char *what" param to use in logging. Just doing ERRNO for all the callers makes more sense to me. >> + /* Remove slot if necessary */ >> + if ( pciback_dev_has_slot(gc, pcidev)> 0 ) { >> + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", >> + pcidev)< 0 ) { >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Couldn't remove pciback slot"); > ERRNO ack > >> + return ERROR_FAIL; >> + } >> + } >> + return 0; >> +} >> + >> +/* FIXME */ > Leftover? Yeah, noticed this just after I sent it. :-) >> +retry: >> + t = xs_transaction_start(ctx->xsh); >> + >> + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", >> + pcidev->domain, >> + pcidev->bus, >> + pcidev->dev, >> + pcidev->func); >> + xs_rm(ctx->xsh, t, path); > Why do you need to rm first? Won't the write just replace whatever it is > (and that means the need for a transaction goes away too) > > In any case you should create path outside the retry loop instead of > needlessly recreating it each time around. TBH, I just looked at another bit of code that did xs transactions and tried to follow suit. Since I only need one operation, I'll take out the transaction stuff. >> + xs_rm(ctx->xsh, t, path); > You don't need a transaction for a single operation. (and if you did > then "path = ..." could have been hoisted out) Very well. > >> +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, >> + int rebind) >> +{ >> + GC_INIT(ctx); >> + int rc; >> + >> + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); >> + >> + GC_FREE; >> + return rc; >> +} > Are there internal callers of libxl__device_pci_assignable_add/remove? > If not then there's no reason to split into internal/external functions. > Doesn't matter much I guess. Not yet, but I don't think it hurts to have that flexibility. Thanks for the detailed review. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:04:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUuK-0008Mi-Ko; Thu, 10 May 2012 15:03:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUuJ-0008MV-Mt for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:03:55 +0000 Received: from [85.158.143.35:35220] by server-1.bemta-4.messagelabs.com id 8C/21-20925-BD8DBAF4; Thu, 10 May 2012 15:03:55 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336662232!8291547!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32472 invoked from network); 10 May 2012 15:03:54 -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; 10 May 2012 15:03:54 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AF3oag032654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:03:51 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 q4AF3o5e015625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:03:50 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 q4AF3nkK011178; Thu, 10 May 2012 10:03:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:03:50 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DC13B4032D; Thu, 10 May 2012 10:57:45 -0400 (EDT) Date: Thu, 10 May 2012 10:57:45 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120510145745.GO26152@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 02:54:07PM +0000, Liu, Jinsong wrote: > Konrad, > > Thanks for help me review! Sure thing. > Update according to your suggestion. > Add some comments below. > > >> > >> Manage physical cpus in dom0, get physical cpus info and provide sys > >> interface. > > > > Anything that exposes SysFS attributes needs documentation in > > Documentation/ABI > > Yes, added. > > > > > Can you explain what this solves? And if there are any > > userland applications that use this? > > > > It provide cpu online/offline interface to user. User can use it for their own purpose, like power saving - by offlining some cpus when light workload it save power greatly. OK, please include that in the descritpion. > > > > > > >> + switch (buf[0]) { > > > > Use strict_strtoull pls. > > kernel suggest: > WARNING: strict_strtoull is obsolete, use kstrtoull instead :) Ah yes. .. snip.. > > And then here dev->release = &pcpu_release; > > > > Hmm, it's good if it's convenient to do it automatically via dev->release. > However, dev container (pcpu) would be free at some other error cases, so I prefer do it 'manually'. You could also call pcpu_release(..) to do it manually. > > > > >> + /* Not open pcpu0 online access to user */ > > > > Huh? You mean "Nobody can touch PCPU0" ? > > Add comments: > /* > * Xen never offline cpu0 due to several restrictions > * and assumptions. This basically doesn't add a sys control > * to user, one cannot attempt to offline BSP. > */ > > > > > Why? Why can they touch the other ones? And better yet, > > what happens if one boots without "dom0_max_vcpus=X" > > and powers of some of the CPUs? > > > > Only those at cpu present map has its sys interface. OK, put that in the file so folks are aware of the limitations. > > >> +static int __init xen_pcpu_init(void) > >> +{ > >> + int ret; > >> + > >> + if (!xen_initial_domain()) > >> + return -ENODEV; > >> + > >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { > >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); > >> + return ret; + } > >> + > >> + INIT_LIST_HEAD(&xen_pcpus.list); > >> + > >> + ret = xen_sync_pcpus(); > >> + if (ret) { > >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + return ret; > >> + } > >> + > >> + ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, > >> + xen_pcpu_interrupt, 0, > >> + "pcpu", NULL); > > > > "xen-pcpu" > > > >> + if (ret < 0) { > >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > > > > Shouldn't you delete what 'xen_sync_pcpus' did? > > yes, add error handling. > > > Or is it OK to still work without the interrupts? What is the purpose > > of that interrupt? How does it actually work - the hypervisor > > decides when/where to turn off CPUs? > > > > user online/offline cpu via sys interface --> xen implement --> inject virq back to dom0 --> sync cpu status. Add that in the file so the workflow is explained. > > Thanks, > Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:04:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUuK-0008Mi-Ko; Thu, 10 May 2012 15:03:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUuJ-0008MV-Mt for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:03:55 +0000 Received: from [85.158.143.35:35220] by server-1.bemta-4.messagelabs.com id 8C/21-20925-BD8DBAF4; Thu, 10 May 2012 15:03:55 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336662232!8291547!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32472 invoked from network); 10 May 2012 15:03:54 -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; 10 May 2012 15:03:54 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AF3oag032654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:03:51 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 q4AF3o5e015625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:03:50 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 q4AF3nkK011178; Thu, 10 May 2012 10:03:49 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:03:50 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id DC13B4032D; Thu, 10 May 2012 10:57:45 -0400 (EDT) Date: Thu, 10 May 2012 10:57:45 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120510145745.GO26152@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 02:54:07PM +0000, Liu, Jinsong wrote: > Konrad, > > Thanks for help me review! Sure thing. > Update according to your suggestion. > Add some comments below. > > >> > >> Manage physical cpus in dom0, get physical cpus info and provide sys > >> interface. > > > > Anything that exposes SysFS attributes needs documentation in > > Documentation/ABI > > Yes, added. > > > > > Can you explain what this solves? And if there are any > > userland applications that use this? > > > > It provide cpu online/offline interface to user. User can use it for their own purpose, like power saving - by offlining some cpus when light workload it save power greatly. OK, please include that in the descritpion. > > > > > > >> + switch (buf[0]) { > > > > Use strict_strtoull pls. > > kernel suggest: > WARNING: strict_strtoull is obsolete, use kstrtoull instead :) Ah yes. .. snip.. > > And then here dev->release = &pcpu_release; > > > > Hmm, it's good if it's convenient to do it automatically via dev->release. > However, dev container (pcpu) would be free at some other error cases, so I prefer do it 'manually'. You could also call pcpu_release(..) to do it manually. > > > > >> + /* Not open pcpu0 online access to user */ > > > > Huh? You mean "Nobody can touch PCPU0" ? > > Add comments: > /* > * Xen never offline cpu0 due to several restrictions > * and assumptions. This basically doesn't add a sys control > * to user, one cannot attempt to offline BSP. > */ > > > > > Why? Why can they touch the other ones? And better yet, > > what happens if one boots without "dom0_max_vcpus=X" > > and powers of some of the CPUs? > > > > Only those at cpu present map has its sys interface. OK, put that in the file so folks are aware of the limitations. > > >> +static int __init xen_pcpu_init(void) > >> +{ > >> + int ret; > >> + > >> + if (!xen_initial_domain()) > >> + return -ENODEV; > >> + > >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { > >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); > >> + return ret; + } > >> + > >> + INIT_LIST_HEAD(&xen_pcpus.list); > >> + > >> + ret = xen_sync_pcpus(); > >> + if (ret) { > >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + return ret; > >> + } > >> + > >> + ret = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, > >> + xen_pcpu_interrupt, 0, > >> + "pcpu", NULL); > > > > "xen-pcpu" > > > >> + if (ret < 0) { > >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > > > > Shouldn't you delete what 'xen_sync_pcpus' did? > > yes, add error handling. > > > Or is it OK to still work without the interrupts? What is the purpose > > of that interrupt? How does it actually work - the hypervisor > > decides when/where to turn off CPUs? > > > > user online/offline cpu via sys interface --> xen implement --> inject virq back to dom0 --> sync cpu status. Add that in the file so the workflow is explained. > > Thanks, > Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:04:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:04:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUv9-0008Uw-7A; Thu, 10 May 2012 15:04:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUv7-0008UV-Ok for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:04:45 +0000 Received: from [85.158.143.99:12047] by server-2.bemta-4.messagelabs.com id C0/BC-17550-D09DBAF4; Thu, 10 May 2012 15:04:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336662284!22143658!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23442 invoked from network); 10 May 2012 15:04:44 -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; 10 May 2012 15:04:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410644" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:04: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, 10 May 2012 16:04:43 +0100 Message-ID: <1336662282.14220.9.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 16:04:42 +0100 In-Reply-To: <4FABD6EF.4020607@eu.citrix.com> References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:55 +0100, George Dunlap wrote: > On 10/05/12 12:19, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > >> Introduce libxl helper functions to prepare devices to be passed through to > >> guests. This is meant to replace of all the manual sysfs commands which > >> are currently required. > >> > >> pci_assignable_add accepts a BDF for a device and will: > >> * Unbind a device from its current driver, if any > >> * If "rebind" is set, it will store the path of the driver from which we > >> unplugged it in /libxl/pciback/$BDF/driver_path > > Since you don't know whether the user is going to pass -r to > > assignable_remove why not always store this? > The xl command does in fact do this (i.e., always passes '1' here). I > considered just taking this option out, as you suggest, but I thought > it might be useful for the libxl implementation to have more flexibility. Oh, I see, I lost track of this being a libxl patch. That seems fine. > >> * If necessary, create a slot for it in pciback > > I must confess I'm a bit fuzzy on the relationship between slots and > > bindings, where does the "if necessary" come into it? > > > > I was wondering while reading the patch if unconditionally adding a > > removing the slot might simplify a bunch of stuff, but I suspect I just > > don't appreciate some particular aspect of how pciback works... > I have no idea what the "slot" thing is for. What I've determined by > experimentation is: > * Before "echo $BDF > .../pciback/bind" will work, $BDF must be listed > in pciback/slots > * The way to get $BDF listed in pciback/slots is "echo $BDF > > pciback/new_slot" > * The above command is not idempotent; if you do it twice, you'll get > two entries of $BDF in pciback/slots > > I wasn't sure if having two slots would be a problem or not; so I did > the conservative thing, and check for the existence of $BDF in > pciback/slots first, only creating a new slot if there is not already an > existing slot. > > So "if necessary" means, "if the device doesn't already have a slot". OK, so it looks like the stuff to check all this is in fact necessary. > > >> + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", > >> + pcidev->domain, > >> + pcidev->bus, > >> + pcidev->dev, > >> + pcidev->func); > >> + if ( !lstat(spath,&st) ) { > >> + /* Find the canonical path to the driver. */ > >> + *dp = libxl__zalloc(gc, PATH_MAX); > > Should we be actually using fpathconf / sysconf here? > I don't really follow. What exactly is it you're proposing? PATH_MAX isn't really a constant these days, you can get the dynamic value for a particular filesystem from fpathconf. I honestly don't know how much of a concern this really is, especially given we are always necessarily talking to sysfs. > >> + if ( (rc=pciback_dev_has_slot(gc, pcidev))< 0 ) { > >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > >> + "Error checking for pciback slot"); > > Log errno? > > > > Also pciback_dev_has_slot itself always logs on error, you probably > > don't need both. > This way you get a sort of callback path; but I could take it out if you > want. I don't feel especially strongly, up to you (/knocks ball back over net ;-) ) > > > >> + return ERROR_FAIL; > >> + } > >> + } > >> + return 0; > >> +} > >> + > >> +/* FIXME */ > > Leftover? > Yeah, noticed this just after I sent it. :-) That's always the way... > >> +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, > >> + int rebind) > >> +{ > >> + GC_INIT(ctx); > >> + int rc; > >> + > >> + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); > >> + > >> + GC_FREE; > >> + return rc; > >> +} > > Are there internal callers of libxl__device_pci_assignable_add/remove? > > If not then there's no reason to split into internal/external functions. > > Doesn't matter much I guess. > Not yet, but I don't think it hurts to have that flexibility. Sure. > Thanks for the detailed review. No problem. BTW, rather than writing done/ack dozens of times I normally assume agreement if someone just trims the whole section. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:04:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:04:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUv9-0008Uw-7A; Thu, 10 May 2012 15:04:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUv7-0008UV-Ok for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:04:45 +0000 Received: from [85.158.143.99:12047] by server-2.bemta-4.messagelabs.com id C0/BC-17550-D09DBAF4; Thu, 10 May 2012 15:04:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336662284!22143658!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23442 invoked from network); 10 May 2012 15:04:44 -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; 10 May 2012 15:04:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410644" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:04: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, 10 May 2012 16:04:43 +0100 Message-ID: <1336662282.14220.9.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 16:04:42 +0100 In-Reply-To: <4FABD6EF.4020607@eu.citrix.com> References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:55 +0100, George Dunlap wrote: > On 10/05/12 12:19, Ian Campbell wrote: > > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote: > >> Introduce libxl helper functions to prepare devices to be passed through to > >> guests. This is meant to replace of all the manual sysfs commands which > >> are currently required. > >> > >> pci_assignable_add accepts a BDF for a device and will: > >> * Unbind a device from its current driver, if any > >> * If "rebind" is set, it will store the path of the driver from which we > >> unplugged it in /libxl/pciback/$BDF/driver_path > > Since you don't know whether the user is going to pass -r to > > assignable_remove why not always store this? > The xl command does in fact do this (i.e., always passes '1' here). I > considered just taking this option out, as you suggest, but I thought > it might be useful for the libxl implementation to have more flexibility. Oh, I see, I lost track of this being a libxl patch. That seems fine. > >> * If necessary, create a slot for it in pciback > > I must confess I'm a bit fuzzy on the relationship between slots and > > bindings, where does the "if necessary" come into it? > > > > I was wondering while reading the patch if unconditionally adding a > > removing the slot might simplify a bunch of stuff, but I suspect I just > > don't appreciate some particular aspect of how pciback works... > I have no idea what the "slot" thing is for. What I've determined by > experimentation is: > * Before "echo $BDF > .../pciback/bind" will work, $BDF must be listed > in pciback/slots > * The way to get $BDF listed in pciback/slots is "echo $BDF > > pciback/new_slot" > * The above command is not idempotent; if you do it twice, you'll get > two entries of $BDF in pciback/slots > > I wasn't sure if having two slots would be a problem or not; so I did > the conservative thing, and check for the existence of $BDF in > pciback/slots first, only creating a new slot if there is not already an > existing slot. > > So "if necessary" means, "if the device doesn't already have a slot". OK, so it looks like the stuff to check all this is in fact necessary. > > >> + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", > >> + pcidev->domain, > >> + pcidev->bus, > >> + pcidev->dev, > >> + pcidev->func); > >> + if ( !lstat(spath,&st) ) { > >> + /* Find the canonical path to the driver. */ > >> + *dp = libxl__zalloc(gc, PATH_MAX); > > Should we be actually using fpathconf / sysconf here? > I don't really follow. What exactly is it you're proposing? PATH_MAX isn't really a constant these days, you can get the dynamic value for a particular filesystem from fpathconf. I honestly don't know how much of a concern this really is, especially given we are always necessarily talking to sysfs. > >> + if ( (rc=pciback_dev_has_slot(gc, pcidev))< 0 ) { > >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, > >> + "Error checking for pciback slot"); > > Log errno? > > > > Also pciback_dev_has_slot itself always logs on error, you probably > > don't need both. > This way you get a sort of callback path; but I could take it out if you > want. I don't feel especially strongly, up to you (/knocks ball back over net ;-) ) > > > >> + return ERROR_FAIL; > >> + } > >> + } > >> + return 0; > >> +} > >> + > >> +/* FIXME */ > > Leftover? > Yeah, noticed this just after I sent it. :-) That's always the way... > >> +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, > >> + int rebind) > >> +{ > >> + GC_INIT(ctx); > >> + int rc; > >> + > >> + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); > >> + > >> + GC_FREE; > >> + return rc; > >> +} > > Are there internal callers of libxl__device_pci_assignable_add/remove? > > If not then there's no reason to split into internal/external functions. > > Doesn't matter much I guess. > Not yet, but I don't think it hurts to have that flexibility. Sure. > Thanks for the detailed review. No problem. BTW, rather than writing done/ack dozens of times I normally assume agreement if someone just trims the whole section. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUw3-0000Bc-LY; Thu, 10 May 2012 15:05:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUw2-0000BR-9E for xen-devel@lists.xen.org; Thu, 10 May 2012 15:05:42 +0000 Received: from [85.158.143.99:31787] by server-3.bemta-4.messagelabs.com id 89/F3-05853-549DBAF4; Thu, 10 May 2012 15:05:41 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1336662338!26831018!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28905 invoked from network); 10 May 2012 15:05:40 -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; 10 May 2012 15:05:40 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068386" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:37 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvw-0007Os-I7; Thu, 10 May 2012 16:05:36 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvu-0000JW-Rl; Thu, 10 May 2012 16:05:34 +0100 MIME-Version: 1.0 X-Mercurial-Node: 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca Message-ID: <4a99c5456e9d8aa707bb.1336661985@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:45 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 01 of 11] x86/mm: make p2m lock into an rwlock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca # Parent 8a86d841e6d42fbffc9e20d3028875dd4990882d x86/mm: make p2m lock into an rwlock Because the p2m lock was already recursive, we need to add a new mm-lock class of recursive rwlocks. Signed-off-by: Tim Deegan diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/arch/x86/mm/mm-locks.h --- a/xen/arch/x86/mm/mm-locks.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/arch/x86/mm/mm-locks.h Thu May 10 15:54:16 2012 +0100 @@ -97,13 +97,71 @@ static inline void _mm_enforce_order_loc __set_lock_level(level); } + +static inline void mm_rwlock_init(mm_rwlock_t *l) +{ + rwlock_init(&l->lock); + l->locker = -1; + l->locker_function = "nobody"; + l->unlock_level = 0; +} + +static inline int mm_write_locked_by_me(mm_rwlock_t *l) +{ + return (l->locker == get_processor_id()); +} + +static inline void _mm_write_lock(mm_rwlock_t *l, const char *func, int level) +{ + if ( !mm_write_locked_by_me(l) ) + { + __check_lock_level(level); + write_lock(&l->lock); + l->locker = get_processor_id(); + l->locker_function = func; + l->unlock_level = __get_lock_level(); + __set_lock_level(level); + } + l->recurse_count++; +} + +static inline void mm_write_unlock(mm_rwlock_t *l) +{ + if ( --(l->recurse_count) != 0 ) + return; + l->locker = -1; + l->locker_function = "nobody"; + __set_lock_level(l->unlock_level); + write_unlock(&l->lock); +} + +static inline void _mm_read_lock(mm_rwlock_t *l, int level) +{ + __check_lock_level(level); + read_lock(&l->lock); + /* There's nowhere to store the per-CPU unlock level so we can't + * set the lock level. */ +} + +static inline void mm_read_unlock(mm_rwlock_t *l) +{ + read_unlock(&l->lock); +} + /* This wrapper uses the line number to express the locking order below */ #define declare_mm_lock(name) \ static inline void mm_lock_##name(mm_lock_t *l, const char *func, int rec)\ { _mm_lock(l, func, __LINE__, rec); } +#define declare_mm_rwlock(name) \ + static inline void mm_write_lock_##name(mm_rwlock_t *l, const char *func) \ + { _mm_write_lock(l, func, __LINE__); } \ + static inline void mm_read_lock_##name(mm_rwlock_t *l) \ + { _mm_read_lock(l, __LINE__); } /* These capture the name of the calling function */ #define mm_lock(name, l) mm_lock_##name(l, __func__, 0) #define mm_lock_recursive(name, l) mm_lock_##name(l, __func__, 1) +#define mm_write_lock(name, l) mm_write_lock_##name(l, __func__) +#define mm_read_lock(name, l) mm_read_lock_##name(l) /* This wrapper is intended for "external" locks which do not use * the mm_lock_t types. Such locks inside the mm code are also subject @@ -152,27 +210,24 @@ declare_mm_lock(nestedp2m) #define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock) /* P2M lock (per-p2m-table) - * - * This protects all queries and updates to the p2m table. * - * A note about ordering: - * The order established here is enforced on all mutations of a p2m. - * For lookups, the order established here is enforced only for hap - * domains (1. shadow domains present a few nasty inversions; - * 2. shadow domains do not support paging and sharing, - * the main sources of dynamic p2m mutations) - * - * The lock is recursive as it is common for a code path to look up a gfn - * and later mutate it. + * This protects all queries and updates to the p2m table. + * Queries may be made under the read lock but all modifications + * need the main (write) lock. + * + * The write lock is recursive as it is common for a code path to look + * up a gfn and later mutate it. */ -declare_mm_lock(p2m) -#define p2m_lock(p) mm_lock_recursive(p2m, &(p)->lock) -#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) -#define p2m_unlock(p) mm_unlock(&(p)->lock) -#define gfn_unlock(p,g,o) mm_unlock(&(p)->lock) -#define p2m_locked_by_me(p) mm_locked_by_me(&(p)->lock) -#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock) +declare_mm_rwlock(p2m); +#define p2m_lock(p) mm_write_lock(p2m, &(p)->lock); +#define p2m_unlock(p) mm_write_unlock(&(p)->lock); +#define gfn_lock(p,g,o) p2m_lock(p) +#define gfn_unlock(p,g,o) p2m_unlock(p) +#define p2m_read_lock(p) mm_read_lock(p2m, &(p)->lock) +#define p2m_read_unlock(p) mm_read_unlock(&(p)->lock) +#define p2m_locked_by_me(p) mm_write_locked_by_me(&(p)->lock) +#define gfn_locked_by_me(p,g) p2m_locked_by_me(p) /* Sharing per page lock * diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Tue May 08 13:36:24 2012 +0200 +++ b/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 @@ -71,7 +71,7 @@ boolean_param("hap_2mb", opt_hap_2mb); /* Init the datastructures for later use by the p2m code */ static void p2m_initialise(struct domain *d, struct p2m_domain *p2m) { - mm_lock_init(&p2m->lock); + mm_rwlock_init(&p2m->lock); mm_lock_init(&p2m->pod.lock); INIT_LIST_HEAD(&p2m->np2m_list); INIT_PAGE_LIST_HEAD(&p2m->pages); diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/include/asm-x86/mm.h --- a/xen/include/asm-x86/mm.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/include/asm-x86/mm.h Thu May 10 15:54:16 2012 +0100 @@ -649,4 +649,12 @@ typedef struct mm_lock { const char *locker_function; /* func that took it */ } mm_lock_t; +typedef struct mm_rwlock { + rwlock_t lock; + int unlock_level; + int recurse_count; + int locker; /* CPU that holds the write lock */ + const char *locker_function; /* func that took it */ +} mm_rwlock_t; + #endif /* __ASM_X86_MM_H__ */ diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -192,7 +192,7 @@ typedef unsigned int p2m_query_t; /* Per-p2m-table state */ struct p2m_domain { /* Lock that protects updates to the p2m */ - mm_lock_t lock; + mm_rwlock_t lock; /* Shadow translated domain: p2m mapping */ pagetable_t phys_table; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUw3-0000Bc-LY; Thu, 10 May 2012 15:05:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUw2-0000BR-9E for xen-devel@lists.xen.org; Thu, 10 May 2012 15:05:42 +0000 Received: from [85.158.143.99:31787] by server-3.bemta-4.messagelabs.com id 89/F3-05853-549DBAF4; Thu, 10 May 2012 15:05:41 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-216.messagelabs.com!1336662338!26831018!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28905 invoked from network); 10 May 2012 15:05:40 -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; 10 May 2012 15:05:40 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068386" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:37 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:37 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvw-0007Os-I7; Thu, 10 May 2012 16:05:36 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvu-0000JW-Rl; Thu, 10 May 2012 16:05:34 +0100 MIME-Version: 1.0 X-Mercurial-Node: 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca Message-ID: <4a99c5456e9d8aa707bb.1336661985@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:45 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 01 of 11] x86/mm: make p2m lock into an rwlock X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca # Parent 8a86d841e6d42fbffc9e20d3028875dd4990882d x86/mm: make p2m lock into an rwlock Because the p2m lock was already recursive, we need to add a new mm-lock class of recursive rwlocks. Signed-off-by: Tim Deegan diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/arch/x86/mm/mm-locks.h --- a/xen/arch/x86/mm/mm-locks.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/arch/x86/mm/mm-locks.h Thu May 10 15:54:16 2012 +0100 @@ -97,13 +97,71 @@ static inline void _mm_enforce_order_loc __set_lock_level(level); } + +static inline void mm_rwlock_init(mm_rwlock_t *l) +{ + rwlock_init(&l->lock); + l->locker = -1; + l->locker_function = "nobody"; + l->unlock_level = 0; +} + +static inline int mm_write_locked_by_me(mm_rwlock_t *l) +{ + return (l->locker == get_processor_id()); +} + +static inline void _mm_write_lock(mm_rwlock_t *l, const char *func, int level) +{ + if ( !mm_write_locked_by_me(l) ) + { + __check_lock_level(level); + write_lock(&l->lock); + l->locker = get_processor_id(); + l->locker_function = func; + l->unlock_level = __get_lock_level(); + __set_lock_level(level); + } + l->recurse_count++; +} + +static inline void mm_write_unlock(mm_rwlock_t *l) +{ + if ( --(l->recurse_count) != 0 ) + return; + l->locker = -1; + l->locker_function = "nobody"; + __set_lock_level(l->unlock_level); + write_unlock(&l->lock); +} + +static inline void _mm_read_lock(mm_rwlock_t *l, int level) +{ + __check_lock_level(level); + read_lock(&l->lock); + /* There's nowhere to store the per-CPU unlock level so we can't + * set the lock level. */ +} + +static inline void mm_read_unlock(mm_rwlock_t *l) +{ + read_unlock(&l->lock); +} + /* This wrapper uses the line number to express the locking order below */ #define declare_mm_lock(name) \ static inline void mm_lock_##name(mm_lock_t *l, const char *func, int rec)\ { _mm_lock(l, func, __LINE__, rec); } +#define declare_mm_rwlock(name) \ + static inline void mm_write_lock_##name(mm_rwlock_t *l, const char *func) \ + { _mm_write_lock(l, func, __LINE__); } \ + static inline void mm_read_lock_##name(mm_rwlock_t *l) \ + { _mm_read_lock(l, __LINE__); } /* These capture the name of the calling function */ #define mm_lock(name, l) mm_lock_##name(l, __func__, 0) #define mm_lock_recursive(name, l) mm_lock_##name(l, __func__, 1) +#define mm_write_lock(name, l) mm_write_lock_##name(l, __func__) +#define mm_read_lock(name, l) mm_read_lock_##name(l) /* This wrapper is intended for "external" locks which do not use * the mm_lock_t types. Such locks inside the mm code are also subject @@ -152,27 +210,24 @@ declare_mm_lock(nestedp2m) #define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock) /* P2M lock (per-p2m-table) - * - * This protects all queries and updates to the p2m table. * - * A note about ordering: - * The order established here is enforced on all mutations of a p2m. - * For lookups, the order established here is enforced only for hap - * domains (1. shadow domains present a few nasty inversions; - * 2. shadow domains do not support paging and sharing, - * the main sources of dynamic p2m mutations) - * - * The lock is recursive as it is common for a code path to look up a gfn - * and later mutate it. + * This protects all queries and updates to the p2m table. + * Queries may be made under the read lock but all modifications + * need the main (write) lock. + * + * The write lock is recursive as it is common for a code path to look + * up a gfn and later mutate it. */ -declare_mm_lock(p2m) -#define p2m_lock(p) mm_lock_recursive(p2m, &(p)->lock) -#define gfn_lock(p,g,o) mm_lock_recursive(p2m, &(p)->lock) -#define p2m_unlock(p) mm_unlock(&(p)->lock) -#define gfn_unlock(p,g,o) mm_unlock(&(p)->lock) -#define p2m_locked_by_me(p) mm_locked_by_me(&(p)->lock) -#define gfn_locked_by_me(p,g) mm_locked_by_me(&(p)->lock) +declare_mm_rwlock(p2m); +#define p2m_lock(p) mm_write_lock(p2m, &(p)->lock); +#define p2m_unlock(p) mm_write_unlock(&(p)->lock); +#define gfn_lock(p,g,o) p2m_lock(p) +#define gfn_unlock(p,g,o) p2m_unlock(p) +#define p2m_read_lock(p) mm_read_lock(p2m, &(p)->lock) +#define p2m_read_unlock(p) mm_read_unlock(&(p)->lock) +#define p2m_locked_by_me(p) mm_write_locked_by_me(&(p)->lock) +#define gfn_locked_by_me(p,g) p2m_locked_by_me(p) /* Sharing per page lock * diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Tue May 08 13:36:24 2012 +0200 +++ b/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 @@ -71,7 +71,7 @@ boolean_param("hap_2mb", opt_hap_2mb); /* Init the datastructures for later use by the p2m code */ static void p2m_initialise(struct domain *d, struct p2m_domain *p2m) { - mm_lock_init(&p2m->lock); + mm_rwlock_init(&p2m->lock); mm_lock_init(&p2m->pod.lock); INIT_LIST_HEAD(&p2m->np2m_list); INIT_PAGE_LIST_HEAD(&p2m->pages); diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/include/asm-x86/mm.h --- a/xen/include/asm-x86/mm.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/include/asm-x86/mm.h Thu May 10 15:54:16 2012 +0100 @@ -649,4 +649,12 @@ typedef struct mm_lock { const char *locker_function; /* func that took it */ } mm_lock_t; +typedef struct mm_rwlock { + rwlock_t lock; + int unlock_level; + int recurse_count; + int locker; /* CPU that holds the write lock */ + const char *locker_function; /* func that took it */ +} mm_rwlock_t; + #endif /* __ASM_X86_MM_H__ */ diff -r 8a86d841e6d4 -r 4a99c5456e9d xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Tue May 08 13:36:24 2012 +0200 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -192,7 +192,7 @@ typedef unsigned int p2m_query_t; /* Per-p2m-table state */ struct p2m_domain { /* Lock that protects updates to the p2m */ - mm_lock_t lock; + mm_rwlock_t lock; /* Shadow translated domain: p2m mapping */ pagetable_t phys_table; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwM-0000Fb-L8; Thu, 10 May 2012 15:06:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwL-0000F5-S7 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:02 +0000 Received: from [193.109.254.147:25602] by server-4.bemta-14.messagelabs.com id 20/2D-11570-959DBAF4; Thu, 10 May 2012 15:06:01 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336662356!8429487!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1652 invoked from network); 10 May 2012 15:05:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068397" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pq-Ez; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwG-0000KF-5C; Thu, 10 May 2012 16:05:56 +0100 MIME-Version: 1.0 X-Mercurial-Node: 65768e16352c6bb0e11bb6c661da5137e99ecceb Message-ID: <65768e16352c6bb0e11b.1336661994@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:54 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 10 of 11] x86/hvm/svm: used unlocked p2m lookups in trace and error paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Andres Lagar-Cavilla # Date 1336661656 -3600 # Node ID 65768e16352c6bb0e11bb6c661da5137e99ecceb # Parent d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc x86/hvm/svm: used unlocked p2m lookups in trace and error paths. Signed-off-by: Andres Lagar-Cavilla diff -r d514c4cfcd2b -r 65768e16352c xen/arch/x86/hvm/svm/svm.c --- a/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 @@ -1321,8 +1321,7 @@ static void svm_do_nested_pgfault(struct p2m = p2m_get_p2m(v); _d.gpa = gpa; _d.qualification = 0; - mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL); - __put_gfn(p2m, gfn); + mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0); _d.mfn = mfn_x(mfn); __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d); @@ -1343,8 +1342,7 @@ static void svm_do_nested_pgfault(struct if ( p2m == NULL ) p2m = p2m_get_p2m(v); /* Everything else is an error. */ - mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL); - __put_gfn(p2m, gfn); + mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0); gdprintk(XENLOG_ERR, "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n", gpa, mfn_x(mfn), p2mt); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwM-0000Fb-L8; Thu, 10 May 2012 15:06:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwL-0000F5-S7 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:02 +0000 Received: from [193.109.254.147:25602] by server-4.bemta-14.messagelabs.com id 20/2D-11570-959DBAF4; Thu, 10 May 2012 15:06:01 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336662356!8429487!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1652 invoked from network); 10 May 2012 15:05:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068397" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pq-Ez; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwG-0000KF-5C; Thu, 10 May 2012 16:05:56 +0100 MIME-Version: 1.0 X-Mercurial-Node: 65768e16352c6bb0e11bb6c661da5137e99ecceb Message-ID: <65768e16352c6bb0e11b.1336661994@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:54 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 10 of 11] x86/hvm/svm: used unlocked p2m lookups in trace and error paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Andres Lagar-Cavilla # Date 1336661656 -3600 # Node ID 65768e16352c6bb0e11bb6c661da5137e99ecceb # Parent d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc x86/hvm/svm: used unlocked p2m lookups in trace and error paths. Signed-off-by: Andres Lagar-Cavilla diff -r d514c4cfcd2b -r 65768e16352c xen/arch/x86/hvm/svm/svm.c --- a/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 @@ -1321,8 +1321,7 @@ static void svm_do_nested_pgfault(struct p2m = p2m_get_p2m(v); _d.gpa = gpa; _d.qualification = 0; - mfn = get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL); - __put_gfn(p2m, gfn); + mfn = __get_gfn_type_access(p2m, gfn, &_d.p2mt, &p2ma, 0, NULL, 0); _d.mfn = mfn_x(mfn); __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d); @@ -1343,8 +1342,7 @@ static void svm_do_nested_pgfault(struct if ( p2m == NULL ) p2m = p2m_get_p2m(v); /* Everything else is an error. */ - mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL); - __put_gfn(p2m, gfn); + mfn = __get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, 0, NULL, 0); gdprintk(XENLOG_ERR, "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n", gpa, mfn_x(mfn), p2mt); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwM-0000FM-7O; Thu, 10 May 2012 15:06:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwL-0000Ew-2I for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:01 +0000 Received: from [193.109.254.147:25546] by server-10.bemta-14.messagelabs.com id D2/04-05847-859DBAF4; Thu, 10 May 2012 15:06:00 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336662356!8429487!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1623 invoked from network); 10 May 2012 15:05:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068396" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:53 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwC-0007Pe-Qi; Thu, 10 May 2012 16:05:52 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw9-0000Jy-9t; Thu, 10 May 2012 16:05:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: d19b3ba026fd844d21a250f768f70a1543d6bbd7 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:50 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 06 of 11] x86: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d19b3ba026fd844d21a250f768f70a1543d6bbd7 # Parent c68f83ff7bf403637ade5a6002a7749226602c05 x86: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/domain.c Thu May 10 15:54:16 2012 +0100 @@ -716,7 +716,7 @@ int arch_set_info_guest( { struct domain *d = v->domain; unsigned long cr3_gfn; - unsigned long cr3_pfn = INVALID_MFN; + struct page_info *cr3_page; unsigned long flags, cr4; unsigned int i; int rc = 0, compat; @@ -925,46 +925,45 @@ int arch_set_info_guest( if ( !compat ) { cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_base_page_table)) ) + if ( !cr3_page ) { - put_gfn(d, cr3_gfn); + destroy_gdt(v); + return -EINVAL; + } + if ( !paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_base_page_table) ) + { + put_page(cr3_page); destroy_gdt(v); return -EINVAL; } - v->arch.guest_table = pagetable_from_pfn(cr3_pfn); - put_gfn(d, cr3_gfn); + v->arch.guest_table = pagetable_from_page(cr3_page); #ifdef __x86_64__ if ( c.nat->ctrlreg[1] ) { cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_base_page_table)) ) + if ( !cr3_page || + (!paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_base_page_table)) ) { - cr3_pfn = pagetable_get_pfn(v->arch.guest_table); + if (cr3_page) + put_page(cr3_page); + cr3_page = pagetable_get_page(v->arch.guest_table); v->arch.guest_table = pagetable_null(); if ( paging_mode_refcounts(d) ) - put_page(mfn_to_page(cr3_pfn)); + put_page(cr3_page); else - put_page_and_type(mfn_to_page(cr3_pfn)); - put_gfn(d, cr3_gfn); + put_page_and_type(cr3_page); destroy_gdt(v); return -EINVAL; } - v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn); - put_gfn(d, cr3_gfn); + v->arch.guest_table_user = pagetable_from_page(cr3_page); } else if ( !(flags & VGCF_in_kernel) ) { @@ -977,23 +976,25 @@ int arch_set_info_guest( l4_pgentry_t *l4tab; cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_l3_page_table)) ) + if ( !cr3_page) { - put_gfn(d, cr3_gfn); + destroy_gdt(v); + return -EINVAL; + } + + if (!paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_l3_page_table) ) + { + put_page(cr3_page); destroy_gdt(v); return -EINVAL; } l4tab = __va(pagetable_get_paddr(v->arch.guest_table)); - *l4tab = l4e_from_pfn( - cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED); - put_gfn(d, cr3_gfn); + *l4tab = l4e_from_pfn(page_to_mfn(cr3_page), + _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED); #endif } @@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l struct domain *d = v->domain; void *mapping; vcpu_info_t *new_info; - unsigned long mfn; + struct page_info *page; int i; if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) ) @@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) ) return -EINVAL; - mfn = get_gfn_untyped(d, gfn); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC); + if ( !page ) + return -EINVAL; + + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gfn); + put_page(page); return -EINVAL; } - mapping = map_domain_page_global(mfn); + mapping = __map_domain_page_global(page); if ( mapping == NULL ) { - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gfn); + put_page_and_type(page); return -ENOMEM; } @@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l } v->vcpu_info = new_info; - v->arch.pv_vcpu.vcpu_info_mfn = mfn; + v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page); /* Set new vcpu_info pointer /before/ setting pending flags. */ wmb(); @@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ ) set_bit(i, &vcpu_info(v, evtchn_pending_sel)); - put_gfn(d, gfn); return 0; } diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/domctl.c --- a/xen/arch/x86/domctl.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/domctl.c Thu May 10 15:54:16 2012 +0100 @@ -202,16 +202,16 @@ long arch_do_domctl( for ( j = 0; j < k; j++ ) { - unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]); + unsigned long type = 0; - page = mfn_to_page(mfn); + page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC); - if ( unlikely(!mfn_valid(mfn)) || - unlikely(is_xen_heap_mfn(mfn)) ) + if ( unlikely(!page) || + unlikely(is_xen_heap_page(page)) ) type = XEN_DOMCTL_PFINFO_XTAB; else if ( xsm_getpageframeinfo(page) != 0 ) ; - else if ( likely(get_page(page, d)) ) + else { switch( page->u.inuse.type_info & PGT_type_mask ) { @@ -231,13 +231,10 @@ long arch_do_domctl( if ( page->u.inuse.type_info & PGT_pinned ) type |= XEN_DOMCTL_PFINFO_LPINTAB; + } + if ( page ) put_page(page); - } - else - type = XEN_DOMCTL_PFINFO_XTAB; - - put_gfn(d, arr[j]); arr[j] = type; } @@ -304,21 +301,21 @@ long arch_do_domctl( { struct page_info *page; unsigned long gfn = arr32[j]; - unsigned long mfn = get_gfn_untyped(d, gfn); - page = mfn_to_page(mfn); + page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC); if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3) arr32[j] = 0; - if ( unlikely(!mfn_valid(mfn)) || - unlikely(is_xen_heap_mfn(mfn)) ) + if ( unlikely(!page) || + unlikely(is_xen_heap_page(page)) ) arr32[j] |= XEN_DOMCTL_PFINFO_XTAB; else if ( xsm_getpageframeinfo(page) != 0 ) { - put_gfn(d, gfn); + put_page(page); continue; - } else if ( likely(get_page(page, d)) ) + } + else { unsigned long type = 0; @@ -341,12 +338,10 @@ long arch_do_domctl( if ( page->u.inuse.type_info & PGT_pinned ) type |= XEN_DOMCTL_PFINFO_LPINTAB; arr32[j] |= type; + } + + if ( page ) put_page(page); - } - else - arr32[j] |= XEN_DOMCTL_PFINFO_XTAB; - - put_gfn(d, gfn); } if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array, @@ -419,7 +414,7 @@ long arch_do_domctl( { struct domain *d = rcu_lock_domain_by_id(domctl->domain); unsigned long gmfn = domctl->u.hypercall_init.gmfn; - unsigned long mfn; + struct page_info *page; void *hypercall_page; ret = -ESRCH; @@ -433,26 +428,25 @@ long arch_do_domctl( break; } - mfn = get_gfn_untyped(d, gmfn); + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); ret = -EACCES; - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); rcu_unlock_domain(d); break; } ret = 0; - hypercall_page = map_domain_page(mfn); + hypercall_page = __map_domain_page(page); hypercall_page_initialise(d, hypercall_page); unmap_domain_page(hypercall_page); - put_page_and_type(mfn_to_page(mfn)); + put_page_and_type(page); - put_gfn(d, gmfn); rcu_unlock_domain(d); } break; diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/physdev.c --- a/xen/arch/x86/physdev.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/physdev.c Thu May 10 15:54:16 2012 +0100 @@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H case PHYSDEVOP_pirq_eoi_gmfn_v1: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; + struct page_info *page; ret = -EFAULT; if ( copy_from_guest(&info, arg, 1) != 0 ) break; ret = -EINVAL; - mfn = get_gfn_untyped(current->domain, info.gmfn); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), v->domain, - PGT_writable_page) ) + page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC); + if ( !page ) + break; + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(current->domain, info.gmfn); + put_page(page); break; } + mfn = page_to_mfn(page); if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn, 0, mfn) != 0 ) { put_page_and_type(mfn_to_page(mfn)); - put_gfn(current->domain, info.gmfn); ret = -EBUSY; break; } @@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H { v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0; put_page_and_type(mfn_to_page(mfn)); - put_gfn(current->domain, info.gmfn); 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; break; } diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/traps.c Thu May 10 15:54:16 2012 +0100 @@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, case 0: { void *hypercall_page; - unsigned long mfn; unsigned long gmfn = val >> 12; unsigned int idx = val & 0xfff; + struct page_info *page; if ( idx > 0 ) { @@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, return 0; } - mfn = get_gfn_untyped(d, gmfn); - - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx) to MSR %08x\n", - gmfn, mfn, base + idx); + gmfn, page_to_mfn(page), base + idx); return 0; } - hypercall_page = map_domain_page(mfn); + hypercall_page = __map_domain_page(page); hypercall_page_initialise(d, hypercall_page); unmap_domain_page(hypercall_page); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); break; } @@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct break; case 3: {/* Write CR3 */ - unsigned long mfn, gfn; + unsigned long gfn; + struct page_info *page; domain_lock(v->domain); if ( !is_pv_32on64_vcpu(v) ) { @@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct gfn = compat_cr3_to_pfn(*reg); #endif } - mfn = get_gfn_untyped(v->domain, gfn); - rc = new_guest_cr3(mfn); - put_gfn(v->domain, gfn); + page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC); + rc = page ? new_guest_cr3(page_to_mfn(page)) : 0; + if ( page ) + put_page(page); domain_unlock(v->domain); if ( rc == 0 ) /* not okay */ goto fail; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwM-0000FM-7O; Thu, 10 May 2012 15:06:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwL-0000Ew-2I for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:01 +0000 Received: from [193.109.254.147:25546] by server-10.bemta-14.messagelabs.com id D2/04-05847-859DBAF4; Thu, 10 May 2012 15:06:00 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1336662356!8429487!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1623 invoked from network); 10 May 2012 15:05:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068396" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:53 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwC-0007Pe-Qi; Thu, 10 May 2012 16:05:52 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw9-0000Jy-9t; Thu, 10 May 2012 16:05:49 +0100 MIME-Version: 1.0 X-Mercurial-Node: d19b3ba026fd844d21a250f768f70a1543d6bbd7 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:50 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 06 of 11] x86: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d19b3ba026fd844d21a250f768f70a1543d6bbd7 # Parent c68f83ff7bf403637ade5a6002a7749226602c05 x86: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/domain.c Thu May 10 15:54:16 2012 +0100 @@ -716,7 +716,7 @@ int arch_set_info_guest( { struct domain *d = v->domain; unsigned long cr3_gfn; - unsigned long cr3_pfn = INVALID_MFN; + struct page_info *cr3_page; unsigned long flags, cr4; unsigned int i; int rc = 0, compat; @@ -925,46 +925,45 @@ int arch_set_info_guest( if ( !compat ) { cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_base_page_table)) ) + if ( !cr3_page ) { - put_gfn(d, cr3_gfn); + destroy_gdt(v); + return -EINVAL; + } + if ( !paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_base_page_table) ) + { + put_page(cr3_page); destroy_gdt(v); return -EINVAL; } - v->arch.guest_table = pagetable_from_pfn(cr3_pfn); - put_gfn(d, cr3_gfn); + v->arch.guest_table = pagetable_from_page(cr3_page); #ifdef __x86_64__ if ( c.nat->ctrlreg[1] ) { cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[1]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_base_page_table)) ) + if ( !cr3_page || + (!paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_base_page_table)) ) { - cr3_pfn = pagetable_get_pfn(v->arch.guest_table); + if (cr3_page) + put_page(cr3_page); + cr3_page = pagetable_get_page(v->arch.guest_table); v->arch.guest_table = pagetable_null(); if ( paging_mode_refcounts(d) ) - put_page(mfn_to_page(cr3_pfn)); + put_page(cr3_page); else - put_page_and_type(mfn_to_page(cr3_pfn)); - put_gfn(d, cr3_gfn); + put_page_and_type(cr3_page); destroy_gdt(v); return -EINVAL; } - v->arch.guest_table_user = pagetable_from_pfn(cr3_pfn); - put_gfn(d, cr3_gfn); + v->arch.guest_table_user = pagetable_from_page(cr3_page); } else if ( !(flags & VGCF_in_kernel) ) { @@ -977,23 +976,25 @@ int arch_set_info_guest( l4_pgentry_t *l4tab; cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]); - cr3_pfn = get_gfn_untyped(d, cr3_gfn); + cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC); - if ( !mfn_valid(cr3_pfn) || - (paging_mode_refcounts(d) - ? !get_page(mfn_to_page(cr3_pfn), d) - : !get_page_and_type(mfn_to_page(cr3_pfn), d, - PGT_l3_page_table)) ) + if ( !cr3_page) { - put_gfn(d, cr3_gfn); + destroy_gdt(v); + return -EINVAL; + } + + if (!paging_mode_refcounts(d) + && !get_page_type(cr3_page, PGT_l3_page_table) ) + { + put_page(cr3_page); destroy_gdt(v); return -EINVAL; } l4tab = __va(pagetable_get_paddr(v->arch.guest_table)); - *l4tab = l4e_from_pfn( - cr3_pfn, _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED); - put_gfn(d, cr3_gfn); + *l4tab = l4e_from_pfn(page_to_mfn(cr3_page), + _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_ACCESSED); #endif } @@ -1064,7 +1065,7 @@ map_vcpu_info(struct vcpu *v, unsigned l struct domain *d = v->domain; void *mapping; vcpu_info_t *new_info; - unsigned long mfn; + struct page_info *page; int i; if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) ) @@ -1077,19 +1078,20 @@ map_vcpu_info(struct vcpu *v, unsigned l if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) ) return -EINVAL; - mfn = get_gfn_untyped(d, gfn); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC); + if ( !page ) + return -EINVAL; + + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gfn); + put_page(page); return -EINVAL; } - mapping = map_domain_page_global(mfn); + mapping = __map_domain_page_global(page); if ( mapping == NULL ) { - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gfn); + put_page_and_type(page); return -ENOMEM; } @@ -1106,7 +1108,7 @@ map_vcpu_info(struct vcpu *v, unsigned l } v->vcpu_info = new_info; - v->arch.pv_vcpu.vcpu_info_mfn = mfn; + v->arch.pv_vcpu.vcpu_info_mfn = page_to_mfn(page); /* Set new vcpu_info pointer /before/ setting pending flags. */ wmb(); @@ -1119,7 +1121,6 @@ map_vcpu_info(struct vcpu *v, unsigned l for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ ) set_bit(i, &vcpu_info(v, evtchn_pending_sel)); - put_gfn(d, gfn); return 0; } diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/domctl.c --- a/xen/arch/x86/domctl.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/domctl.c Thu May 10 15:54:16 2012 +0100 @@ -202,16 +202,16 @@ long arch_do_domctl( for ( j = 0; j < k; j++ ) { - unsigned long type = 0, mfn = get_gfn_untyped(d, arr[j]); + unsigned long type = 0; - page = mfn_to_page(mfn); + page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC); - if ( unlikely(!mfn_valid(mfn)) || - unlikely(is_xen_heap_mfn(mfn)) ) + if ( unlikely(!page) || + unlikely(is_xen_heap_page(page)) ) type = XEN_DOMCTL_PFINFO_XTAB; else if ( xsm_getpageframeinfo(page) != 0 ) ; - else if ( likely(get_page(page, d)) ) + else { switch( page->u.inuse.type_info & PGT_type_mask ) { @@ -231,13 +231,10 @@ long arch_do_domctl( if ( page->u.inuse.type_info & PGT_pinned ) type |= XEN_DOMCTL_PFINFO_LPINTAB; + } + if ( page ) put_page(page); - } - else - type = XEN_DOMCTL_PFINFO_XTAB; - - put_gfn(d, arr[j]); arr[j] = type; } @@ -304,21 +301,21 @@ long arch_do_domctl( { struct page_info *page; unsigned long gfn = arr32[j]; - unsigned long mfn = get_gfn_untyped(d, gfn); - page = mfn_to_page(mfn); + page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC); if ( domctl->cmd == XEN_DOMCTL_getpageframeinfo3) arr32[j] = 0; - if ( unlikely(!mfn_valid(mfn)) || - unlikely(is_xen_heap_mfn(mfn)) ) + if ( unlikely(!page) || + unlikely(is_xen_heap_page(page)) ) arr32[j] |= XEN_DOMCTL_PFINFO_XTAB; else if ( xsm_getpageframeinfo(page) != 0 ) { - put_gfn(d, gfn); + put_page(page); continue; - } else if ( likely(get_page(page, d)) ) + } + else { unsigned long type = 0; @@ -341,12 +338,10 @@ long arch_do_domctl( if ( page->u.inuse.type_info & PGT_pinned ) type |= XEN_DOMCTL_PFINFO_LPINTAB; arr32[j] |= type; + } + + if ( page ) put_page(page); - } - else - arr32[j] |= XEN_DOMCTL_PFINFO_XTAB; - - put_gfn(d, gfn); } if ( copy_to_guest_offset(domctl->u.getpageframeinfo2.array, @@ -419,7 +414,7 @@ long arch_do_domctl( { struct domain *d = rcu_lock_domain_by_id(domctl->domain); unsigned long gmfn = domctl->u.hypercall_init.gmfn; - unsigned long mfn; + struct page_info *page; void *hypercall_page; ret = -ESRCH; @@ -433,26 +428,25 @@ long arch_do_domctl( break; } - mfn = get_gfn_untyped(d, gmfn); + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); ret = -EACCES; - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); rcu_unlock_domain(d); break; } ret = 0; - hypercall_page = map_domain_page(mfn); + hypercall_page = __map_domain_page(page); hypercall_page_initialise(d, hypercall_page); unmap_domain_page(hypercall_page); - put_page_and_type(mfn_to_page(mfn)); + put_page_and_type(page); - put_gfn(d, gmfn); rcu_unlock_domain(d); } break; diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/physdev.c --- a/xen/arch/x86/physdev.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/physdev.c Thu May 10 15:54:16 2012 +0100 @@ -306,26 +306,27 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H case PHYSDEVOP_pirq_eoi_gmfn_v1: { struct physdev_pirq_eoi_gmfn info; unsigned long mfn; + struct page_info *page; ret = -EFAULT; if ( copy_from_guest(&info, arg, 1) != 0 ) break; ret = -EINVAL; - mfn = get_gfn_untyped(current->domain, info.gmfn); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), v->domain, - PGT_writable_page) ) + page = get_page_from_gfn(current->domain, info.gmfn, NULL, P2M_ALLOC); + if ( !page ) + break; + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(current->domain, info.gmfn); + put_page(page); break; } + mfn = page_to_mfn(page); if ( cmpxchg(&v->domain->arch.pv_domain.pirq_eoi_map_mfn, 0, mfn) != 0 ) { put_page_and_type(mfn_to_page(mfn)); - put_gfn(current->domain, info.gmfn); ret = -EBUSY; break; } @@ -335,14 +336,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H { v->domain->arch.pv_domain.pirq_eoi_map_mfn = 0; put_page_and_type(mfn_to_page(mfn)); - put_gfn(current->domain, info.gmfn); 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; break; } diff -r c68f83ff7bf4 -r d19b3ba026fd xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/traps.c Thu May 10 15:54:16 2012 +0100 @@ -662,9 +662,9 @@ int wrmsr_hypervisor_regs(uint32_t idx, case 0: { void *hypercall_page; - unsigned long mfn; unsigned long gmfn = val >> 12; unsigned int idx = val & 0xfff; + struct page_info *page; if ( idx > 0 ) { @@ -674,24 +674,23 @@ int wrmsr_hypervisor_regs(uint32_t idx, return 0; } - mfn = get_gfn_untyped(d, gmfn); - - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx) to MSR %08x\n", - gmfn, mfn, base + idx); + gmfn, page_to_mfn(page), base + idx); return 0; } - hypercall_page = map_domain_page(mfn); + hypercall_page = __map_domain_page(page); hypercall_page_initialise(d, hypercall_page); unmap_domain_page(hypercall_page); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); break; } @@ -2374,7 +2373,8 @@ static int emulate_privileged_op(struct break; case 3: {/* Write CR3 */ - unsigned long mfn, gfn; + unsigned long gfn; + struct page_info *page; domain_lock(v->domain); if ( !is_pv_32on64_vcpu(v) ) { @@ -2384,9 +2384,10 @@ static int emulate_privileged_op(struct gfn = compat_cr3_to_pfn(*reg); #endif } - mfn = get_gfn_untyped(v->domain, gfn); - rc = new_guest_cr3(mfn); - put_gfn(v->domain, gfn); + page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC); + rc = page ? new_guest_cr3(page_to_mfn(page)) : 0; + if ( page ) + put_page(page); domain_unlock(v->domain); if ( rc == 0 ) /* not okay */ goto fail; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwS-0000HL-Gi; Thu, 10 May 2012 15:06:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwQ-0000GO-2L for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:06 +0000 Received: from [193.109.254.147:2829] by server-11.bemta-14.messagelabs.com id CF/26-05858-D59DBAF4; Thu, 10 May 2012 15:06:05 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1336662354!8614845!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16991 invoked from network); 10 May 2012 15:05:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068395" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:48 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw7-0007P4-FJ; Thu, 10 May 2012 16:05:47 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw2-0000Jo-FL; Thu, 10 May 2012 16:05:42 +0100 MIME-Version: 1.0 X-Mercurial-Node: 9da426cdc7e478e426bcbd5391b8deacdc85db1e Message-ID: <9da426cdc7e478e426bc.1336661988@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:48 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 04 of 11] x86/hvm: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 9da426cdc7e478e426bcbd5391b8deacdc85db1e # Parent d774bb5c6326d1a7e88a3bfadc546d154a2ad895 x86/hvm: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/emulate.c --- a/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 @@ -60,34 +60,25 @@ static int hvmemul_do_io( ioreq_t *p = get_ioreq(curr); unsigned long ram_gfn = paddr_to_pfn(ram_gpa); p2m_type_t p2mt; - mfn_t ram_mfn; + struct page_info *ram_page; int rc; /* Check for paged out page */ - ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt); + ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(curr->domain, ram_gfn); + if ( ram_page ) + put_page(ram_page); p2m_mem_paging_populate(curr->domain, ram_gfn); return X86EMUL_RETRY; } if ( p2m_is_shared(p2mt) ) { - put_gfn(curr->domain, ram_gfn); + if ( ram_page ) + put_page(ram_page); return X86EMUL_RETRY; } - /* Maintain a ref on the mfn to ensure liveness. Put the gfn - * to avoid potential deadlock wrt event channel lock, later. */ - if ( mfn_valid(mfn_x(ram_mfn)) ) - if ( !get_page(mfn_to_page(mfn_x(ram_mfn)), - curr->domain) ) - { - put_gfn(curr->domain, ram_gfn); - return X86EMUL_RETRY; - } - put_gfn(curr->domain, ram_gfn); - /* * Weird-sized accesses have undefined behaviour: we discard writes * and read all-ones. @@ -98,8 +89,8 @@ static int hvmemul_do_io( ASSERT(p_data != NULL); /* cannot happen with a REP prefix */ if ( dir == IOREQ_READ ) memset(p_data, ~0, size); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -120,8 +111,8 @@ static int hvmemul_do_io( unsigned int bytes = vio->mmio_large_write_bytes; if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } } @@ -133,8 +124,8 @@ static int hvmemul_do_io( { memcpy(p_data, &vio->mmio_large_read[addr - pa], size); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } } @@ -148,8 +139,8 @@ static int hvmemul_do_io( vio->io_state = HVMIO_none; if ( p_data == NULL ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } goto finish_access; @@ -159,13 +150,13 @@ static int hvmemul_do_io( (addr == (vio->mmio_large_write_pa + vio->mmio_large_write_bytes)) ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_RETRY; } default: - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -173,8 +164,8 @@ static int hvmemul_do_io( { gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n", p->state); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -226,8 +217,8 @@ static int hvmemul_do_io( if ( rc != X86EMUL_OKAY ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return rc; } @@ -263,8 +254,8 @@ static int hvmemul_do_io( } } - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/hvm.c Thu May 10 15:54:16 2012 +0100 @@ -395,48 +395,41 @@ int prepare_ring_for_helper( { struct page_info *page; p2m_type_t p2mt; - unsigned long mfn; void *va; - mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt)); - if ( !p2m_is_ram(p2mt) ) - { - put_gfn(d, gmfn); - return -EINVAL; - } + page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); p2m_mem_paging_populate(d, gmfn); return -ENOENT; } if ( p2m_is_shared(p2mt) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); return -ENOENT; } - ASSERT(mfn_valid(mfn)); - - page = mfn_to_page(mfn); - if ( !get_page_and_type(page, d, PGT_writable_page) ) + if ( !page ) + return -EINVAL; + + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + put_page(page); return -EINVAL; } - va = map_domain_page_global(mfn); + va = __map_domain_page_global(page); if ( va == NULL ) { put_page_and_type(page); - put_gfn(d, gmfn); return -ENOMEM; } *_va = va; *_page = page; - put_gfn(d, gmfn); - return 0; } @@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns int hvm_set_cr0(unsigned long value) { struct vcpu *v = current; - p2m_type_t p2mt; - unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0]; + unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0]; + struct page_info *page; HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value); @@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value) { /* The guest CR3 must be pointing to the guest physical. */ gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT; - mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - !get_page(mfn_to_page(mfn), v->domain)) + page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, gfn); - gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n", - v->arch.hvm_vcpu.guest_cr[3], mfn); + gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n", + v->arch.hvm_vcpu.guest_cr[3]); domain_crash(v->domain); return X86EMUL_UNHANDLEABLE; } /* Now arch.guest_table points to machine physical. */ - v->arch.guest_table = pagetable_from_pfn(mfn); + v->arch.guest_table = pagetable_from_page(page); HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx", - v->arch.hvm_vcpu.guest_cr[3], mfn); - put_gfn(v->domain, gfn); + v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page)); } } else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) ) @@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value) int hvm_set_cr3(unsigned long value) { - unsigned long mfn; - p2m_type_t p2mt; struct vcpu *v = current; + struct page_info *page; if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) && (value != v->arch.hvm_vcpu.guest_cr[3]) ) { /* Shadow-mode CR3 change. Check PDBR and update refcounts. */ HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value); - mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - !get_page(mfn_to_page(mfn), v->domain) ) - { - put_gfn(v->domain, value >> PAGE_SHIFT); - goto bad_cr3; - } + page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) + goto bad_cr3; put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - put_gfn(v->domain, value >> PAGE_SHIFT); + v->arch.guest_table = pagetable_from_page(page); HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value); } @@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr( static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable) { void *map; - unsigned long mfn; p2m_type_t p2mt; - struct page_info *pg; + struct page_info *page; struct domain *d = current->domain; - int rc; - - mfn = mfn_x(writable - ? get_gfn_unshare(d, gfn, &p2mt) - : get_gfn(d, gfn, &p2mt)); - if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) ) + + page = get_page_from_gfn(d, gfn, &p2mt, + writable ? P2M_UNSHARE : P2M_ALLOC); + if ( (p2m_is_shared(p2mt) && writable) || !page ) { - put_gfn(d, gfn); + if ( page ) + put_page(page); return NULL; } if ( p2m_is_paging(p2mt) ) { - put_gfn(d, gfn); + put_page(page); p2m_mem_paging_populate(d, gfn); return NULL; } - ASSERT(mfn_valid(mfn)); - if ( writable ) - paging_mark_dirty(d, mfn); - - /* Get a ref on the page, considering that it could be shared */ - pg = mfn_to_page(mfn); - rc = get_page(pg, d); - if ( !rc && !writable ) - /* Page could be shared */ - rc = get_page(pg, dom_cow); - if ( !rc ) - { - put_gfn(d, gfn); - return NULL; - } - - map = map_domain_page(mfn); - put_gfn(d, gfn); + paging_mark_dirty(d, page_to_mfn(page)); + + map = __map_domain_page(page); return map; } @@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy( void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec) { struct vcpu *curr = current; - unsigned long gfn, mfn; + unsigned long gfn; + struct page_info *page; p2m_type_t p2mt; char *p; int count, todo = size; @@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy( gfn = addr >> PAGE_SHIFT; } - mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt)); + page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); p2m_mem_paging_populate(curr->domain, gfn); return HVMCOPY_gfn_paged_out; } if ( p2m_is_shared(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_gfn_shared; } if ( p2m_is_grant(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_unhandleable; } - if ( !p2m_is_ram(p2mt) ) + if ( !page ) { - put_gfn(curr->domain, gfn); return HVMCOPY_bad_gfn_to_mfn; } - ASSERT(mfn_valid(mfn)); - - p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK); + + p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK); if ( flags & HVMCOPY_to_guest ) { @@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy( if ( xchg(&lastpage, gfn) != gfn ) gdprintk(XENLOG_DEBUG, "guest attempted write to read-only" " memory page. gfn=%#lx, mfn=%#lx\n", - gfn, mfn); + gfn, page_to_mfn(page)); } else { memcpy(p, buf, count); - paging_mark_dirty(curr->domain, mfn); + paging_mark_dirty(curr->domain, page_to_mfn(page)); } } else @@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy( addr += count; buf += count; todo -= count; - put_gfn(curr->domain, gfn); + put_page(page); } return HVMCOPY_okay; @@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy( static enum hvm_copy_result __hvm_clear(paddr_t addr, int size) { struct vcpu *curr = current; - unsigned long gfn, mfn; + unsigned long gfn; + struct page_info *page; p2m_type_t p2mt; char *p; int count, todo = size; @@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear( return HVMCOPY_bad_gva_to_gfn; } - mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt)); + page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { + if ( page ) + put_page(page); 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); + if ( page ) + put_page(page); return HVMCOPY_gfn_shared; } if ( p2m_is_grant(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_unhandleable; } - if ( !p2m_is_ram(p2mt) ) + if ( !page ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_bad_gfn_to_mfn; } - ASSERT(mfn_valid(mfn)); - - p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK); + + p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK); if ( p2mt == p2m_ram_ro ) { @@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear( if ( xchg(&lastpage, gfn) != gfn ) gdprintk(XENLOG_DEBUG, "guest attempted write to read-only" " memory page. gfn=%#lx, mfn=%#lx\n", - gfn, mfn); + gfn, page_to_mfn(page)); } else { memset(p, 0x00, count); - paging_mark_dirty(curr->domain, mfn); + paging_mark_dirty(curr->domain, page_to_mfn(page)); } unmap_domain_page(p); addr += count; todo -= count; - put_gfn(curr->domain, gfn); + put_page(page); } return HVMCOPY_okay; @@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ ) { - p2m_type_t t; - mfn_t mfn = get_gfn_unshare(d, pfn, &t); - if ( p2m_is_paging(t) ) + struct page_info *page; + page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE); + if ( page ) { - put_gfn(d, pfn); - p2m_mem_paging_populate(d, pfn); - rc = -EINVAL; - goto param_fail3; - } - if( p2m_is_shared(t) ) - { - /* If it insists on not unsharing itself, crash the domain - * rather than crashing the host down in mark dirty */ - gdprintk(XENLOG_WARNING, - "shared pfn 0x%lx modified?\n", pfn); - domain_crash(d); - put_gfn(d, pfn); - rc = -EINVAL; - goto param_fail3; - } - - if ( mfn_x(mfn) != INVALID_MFN ) - { - paging_mark_dirty(d, mfn_x(mfn)); + paging_mark_dirty(d, page_to_mfn(page)); /* These are most probably not page tables any more */ /* don't take a long time and don't die either */ - sh_remove_shadows(d->vcpu[0], mfn, 1, 0); + sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0); + put_page(page); } - put_gfn(d, pfn); } param_fail3: diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/stdvga.c --- a/xen/arch/x86/hvm/stdvga.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/stdvga.c Thu May 10 15:54:16 2012 +0100 @@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg if ( hvm_copy_to_guest_phys(data, &tmp, p->size) != HVMCOPY_okay ) { - (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt); + struct page_info *dp = get_page_from_gfn( + d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC); /* * The only case we handle is vga_mem <-> vga_mem. * Anything else disables caching and leaves it to qemu-dm. @@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) || ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) ) { - put_gfn(d, data >> PAGE_SHIFT); + if ( dp ) + put_page(dp); return 0; } + ASSERT(!dp); stdvga_mem_write(data, tmp, p->size); - put_gfn(d, data >> PAGE_SHIFT); } data += sign * p->size; addr += sign * p->size; @@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg if ( hvm_copy_from_guest_phys(&tmp, data, p->size) != HVMCOPY_okay ) { - (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt); + struct page_info *dp = get_page_from_gfn( + d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC); if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) || ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) ) { - put_gfn(d, data >> PAGE_SHIFT); + if ( dp ) + put_page(dp); 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 d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/svm/svm.c --- a/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 @@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v, static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) { - unsigned long mfn = 0; - p2m_type_t p2mt; + struct page_info *page = NULL; struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb; struct p2m_domain *p2m = p2m_get_hostp2m(v->domain); @@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu { if ( c->cr0 & X86_CR0_PG ) { - mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, c->cr3 >> PAGE_SHIFT); gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n", c->cr3); return -EINVAL; @@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG ) put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - if ( c->cr0 & X86_CR0_PG ) - put_gfn(v->domain, c->cr3 >> PAGE_SHIFT); + v->arch.guest_table = + page ? pagetable_from_page(page) : pagetable_null(); } v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET; diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/viridian.c --- a/xen/arch/x86/hvm/viridian.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/viridian.c Thu May 10 15:54:16 2012 +0100 @@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v) static void enable_hypercall_page(struct domain *d) { unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; - unsigned long mfn = get_gfn_untyped(d, gmfn); + struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); uint8_t *p; - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); - gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); + if ( page ) + put_page(page); + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, + page_to_mfn(page)); return; } - p = map_domain_page(mfn); + p = __map_domain_page(page); /* * We set the bit 31 in %eax (reserved field in the Viridian hypercall @@ -162,15 +163,14 @@ static void enable_hypercall_page(struct unmap_domain_page(p); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); } void initialize_apic_assist(struct vcpu *v) { struct domain *d = v->domain; unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn; - unsigned long mfn = get_gfn_untyped(d, gmfn); + struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); uint8_t *p; /* @@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu * details of how Windows uses the page. */ - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); - gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); + if ( page ) + put_page(page); + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, + page_to_mfn(page)); return; } - p = map_domain_page(mfn); + p = __map_domain_page(page); *(u32 *)p = 0; unmap_domain_page(p); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); } int wrmsr_viridian_regs(uint32_t idx, uint64_t val) diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu May 10 15:54:16 2012 +0100 @@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v static int vmx_restore_cr0_cr3( struct vcpu *v, unsigned long cr0, unsigned long cr3) { - unsigned long mfn = 0; - p2m_type_t p2mt; + struct page_info *page = NULL; if ( paging_mode_shadow(v->domain) ) { if ( cr0 & X86_CR0_PG ) { - mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, cr3 >> PAGE_SHIFT); gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3); return -EINVAL; } @@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3( if ( hvm_paging_enabled(v) ) put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - if ( cr0 & X86_CR0_PG ) - put_gfn(v->domain, cr3 >> PAGE_SHIFT); + v->arch.guest_table = + page ? pagetable_from_page(page) : pagetable_null(); } v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET; @@ -1035,8 +1033,9 @@ static void vmx_set_interrupt_shadow(str static void vmx_load_pdptrs(struct vcpu *v) { - unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn; + unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3]; uint64_t *guest_pdptrs; + struct page_info *page; p2m_type_t p2mt; char *p; @@ -1047,24 +1046,19 @@ static void vmx_load_pdptrs(struct vcpu if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) goto crash; - mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - /* If we didn't succeed in unsharing, get_page will fail - * (page still belongs to dom_cow) */ - !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); + if ( !page ) { /* Ideally you don't want to crash but rather go into a wait * queue, but this is the wrong place. We're holding at least * the paging lock */ gdprintk(XENLOG_ERR, - "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n", - cr3 >> PAGE_SHIFT, mfn, (int) p2mt); - put_gfn(v->domain, cr3 >> PAGE_SHIFT); + "Bad cr3 on load pdptrs gfn %lx type %d\n", + cr3 >> PAGE_SHIFT, (int) p2mt); goto crash; } - put_gfn(v->domain, cr3 >> PAGE_SHIFT); - - p = map_domain_page(mfn); + + p = __map_domain_page(page); guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); @@ -1090,7 +1084,7 @@ static void vmx_load_pdptrs(struct vcpu vmx_vmcs_exit(v); unmap_domain_page(p); - put_page(mfn_to_page(mfn)); + put_page(page); return; crash: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSUwS-0000HL-Gi; Thu, 10 May 2012 15:06:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwQ-0000GO-2L for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:06 +0000 Received: from [193.109.254.147:2829] by server-11.bemta-14.messagelabs.com id CF/26-05858-D59DBAF4; Thu, 10 May 2012 15:06:05 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1336662354!8614845!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16991 invoked from network); 10 May 2012 15:05:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068395" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:53 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:48 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw7-0007P4-FJ; Thu, 10 May 2012 16:05:47 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw2-0000Jo-FL; Thu, 10 May 2012 16:05:42 +0100 MIME-Version: 1.0 X-Mercurial-Node: 9da426cdc7e478e426bcbd5391b8deacdc85db1e Message-ID: <9da426cdc7e478e426bc.1336661988@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:48 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 04 of 11] x86/hvm: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 9da426cdc7e478e426bcbd5391b8deacdc85db1e # Parent d774bb5c6326d1a7e88a3bfadc546d154a2ad895 x86/hvm: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/emulate.c --- a/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 @@ -60,34 +60,25 @@ static int hvmemul_do_io( ioreq_t *p = get_ioreq(curr); unsigned long ram_gfn = paddr_to_pfn(ram_gpa); p2m_type_t p2mt; - mfn_t ram_mfn; + struct page_info *ram_page; int rc; /* Check for paged out page */ - ram_mfn = get_gfn_unshare(curr->domain, ram_gfn, &p2mt); + ram_page = get_page_from_gfn(curr->domain, ram_gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(curr->domain, ram_gfn); + if ( ram_page ) + put_page(ram_page); p2m_mem_paging_populate(curr->domain, ram_gfn); return X86EMUL_RETRY; } if ( p2m_is_shared(p2mt) ) { - put_gfn(curr->domain, ram_gfn); + if ( ram_page ) + put_page(ram_page); return X86EMUL_RETRY; } - /* Maintain a ref on the mfn to ensure liveness. Put the gfn - * to avoid potential deadlock wrt event channel lock, later. */ - if ( mfn_valid(mfn_x(ram_mfn)) ) - if ( !get_page(mfn_to_page(mfn_x(ram_mfn)), - curr->domain) ) - { - put_gfn(curr->domain, ram_gfn); - return X86EMUL_RETRY; - } - put_gfn(curr->domain, ram_gfn); - /* * Weird-sized accesses have undefined behaviour: we discard writes * and read all-ones. @@ -98,8 +89,8 @@ static int hvmemul_do_io( ASSERT(p_data != NULL); /* cannot happen with a REP prefix */ if ( dir == IOREQ_READ ) memset(p_data, ~0, size); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -120,8 +111,8 @@ static int hvmemul_do_io( unsigned int bytes = vio->mmio_large_write_bytes; if ( (addr >= pa) && ((addr + size) <= (pa + bytes)) ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } } @@ -133,8 +124,8 @@ static int hvmemul_do_io( { memcpy(p_data, &vio->mmio_large_read[addr - pa], size); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } } @@ -148,8 +139,8 @@ static int hvmemul_do_io( vio->io_state = HVMIO_none; if ( p_data == NULL ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } goto finish_access; @@ -159,13 +150,13 @@ static int hvmemul_do_io( (addr == (vio->mmio_large_write_pa + vio->mmio_large_write_bytes)) ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_RETRY; } default: - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -173,8 +164,8 @@ static int hvmemul_do_io( { gdprintk(XENLOG_WARNING, "WARNING: io already pending (%d)?\n", p->state); - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_UNHANDLEABLE; } @@ -226,8 +217,8 @@ static int hvmemul_do_io( if ( rc != X86EMUL_OKAY ) { - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return rc; } @@ -263,8 +254,8 @@ static int hvmemul_do_io( } } - if ( mfn_valid(mfn_x(ram_mfn)) ) - put_page(mfn_to_page(mfn_x(ram_mfn))); + if ( ram_page ) + put_page(ram_page); return X86EMUL_OKAY; } diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/hvm.c Thu May 10 15:54:16 2012 +0100 @@ -395,48 +395,41 @@ int prepare_ring_for_helper( { struct page_info *page; p2m_type_t p2mt; - unsigned long mfn; void *va; - mfn = mfn_x(get_gfn_unshare(d, gmfn, &p2mt)); - if ( !p2m_is_ram(p2mt) ) - { - put_gfn(d, gmfn); - return -EINVAL; - } + page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); p2m_mem_paging_populate(d, gmfn); return -ENOENT; } if ( p2m_is_shared(p2mt) ) { - put_gfn(d, gmfn); + if ( page ) + put_page(page); return -ENOENT; } - ASSERT(mfn_valid(mfn)); - - page = mfn_to_page(mfn); - if ( !get_page_and_type(page, d, PGT_writable_page) ) + if ( !page ) + return -EINVAL; + + if ( !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); + put_page(page); return -EINVAL; } - va = map_domain_page_global(mfn); + va = __map_domain_page_global(page); if ( va == NULL ) { put_page_and_type(page); - put_gfn(d, gmfn); return -ENOMEM; } *_va = va; *_page = page; - put_gfn(d, gmfn); - return 0; } @@ -1607,8 +1600,8 @@ int hvm_mov_from_cr(unsigned int cr, uns int hvm_set_cr0(unsigned long value) { struct vcpu *v = current; - p2m_type_t p2mt; - unsigned long gfn, mfn, old_value = v->arch.hvm_vcpu.guest_cr[0]; + unsigned long gfn, old_value = v->arch.hvm_vcpu.guest_cr[0]; + struct page_info *page; HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR0 value = %lx", value); @@ -1647,23 +1640,20 @@ int hvm_set_cr0(unsigned long value) { /* The guest CR3 must be pointing to the guest physical. */ gfn = v->arch.hvm_vcpu.guest_cr[3]>>PAGE_SHIFT; - mfn = mfn_x(get_gfn(v->domain, gfn, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - !get_page(mfn_to_page(mfn), v->domain)) + page = get_page_from_gfn(v->domain, gfn, NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, gfn); - gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx (mfn=%lx)\n", - v->arch.hvm_vcpu.guest_cr[3], mfn); + gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n", + v->arch.hvm_vcpu.guest_cr[3]); domain_crash(v->domain); return X86EMUL_UNHANDLEABLE; } /* Now arch.guest_table points to machine physical. */ - v->arch.guest_table = pagetable_from_pfn(mfn); + v->arch.guest_table = pagetable_from_page(page); HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx, mfn = %lx", - v->arch.hvm_vcpu.guest_cr[3], mfn); - put_gfn(v->domain, gfn); + v->arch.hvm_vcpu.guest_cr[3], page_to_mfn(page)); } } else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) ) @@ -1738,26 +1728,21 @@ int hvm_set_cr0(unsigned long value) int hvm_set_cr3(unsigned long value) { - unsigned long mfn; - p2m_type_t p2mt; struct vcpu *v = current; + struct page_info *page; if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) && (value != v->arch.hvm_vcpu.guest_cr[3]) ) { /* Shadow-mode CR3 change. Check PDBR and update refcounts. */ HVM_DBG_LOG(DBG_LEVEL_VMMU, "CR3 value = %lx", value); - mfn = mfn_x(get_gfn(v->domain, value >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - !get_page(mfn_to_page(mfn), v->domain) ) - { - put_gfn(v->domain, value >> PAGE_SHIFT); - goto bad_cr3; - } + page = get_page_from_gfn(v->domain, value >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) + goto bad_cr3; put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - put_gfn(v->domain, value >> PAGE_SHIFT); + v->arch.guest_table = pagetable_from_page(page); HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value); } @@ -1914,46 +1899,29 @@ int hvm_virtual_to_linear_addr( static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable) { void *map; - unsigned long mfn; p2m_type_t p2mt; - struct page_info *pg; + struct page_info *page; struct domain *d = current->domain; - int rc; - - mfn = mfn_x(writable - ? get_gfn_unshare(d, gfn, &p2mt) - : get_gfn(d, gfn, &p2mt)); - if ( (p2m_is_shared(p2mt) && writable) || !p2m_is_ram(p2mt) ) + + page = get_page_from_gfn(d, gfn, &p2mt, + writable ? P2M_UNSHARE : P2M_ALLOC); + if ( (p2m_is_shared(p2mt) && writable) || !page ) { - put_gfn(d, gfn); + if ( page ) + put_page(page); return NULL; } if ( p2m_is_paging(p2mt) ) { - put_gfn(d, gfn); + put_page(page); p2m_mem_paging_populate(d, gfn); return NULL; } - ASSERT(mfn_valid(mfn)); - if ( writable ) - paging_mark_dirty(d, mfn); - - /* Get a ref on the page, considering that it could be shared */ - pg = mfn_to_page(mfn); - rc = get_page(pg, d); - if ( !rc && !writable ) - /* Page could be shared */ - rc = get_page(pg, dom_cow); - if ( !rc ) - { - put_gfn(d, gfn); - return NULL; - } - - map = map_domain_page(mfn); - put_gfn(d, gfn); + paging_mark_dirty(d, page_to_mfn(page)); + + map = __map_domain_page(page); return map; } @@ -2358,7 +2326,8 @@ static enum hvm_copy_result __hvm_copy( void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec) { struct vcpu *curr = current; - unsigned long gfn, mfn; + unsigned long gfn; + struct page_info *page; p2m_type_t p2mt; char *p; int count, todo = size; @@ -2402,32 +2371,33 @@ static enum hvm_copy_result __hvm_copy( gfn = addr >> PAGE_SHIFT; } - mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt)); + page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); p2m_mem_paging_populate(curr->domain, gfn); return HVMCOPY_gfn_paged_out; } if ( p2m_is_shared(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_gfn_shared; } if ( p2m_is_grant(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_unhandleable; } - if ( !p2m_is_ram(p2mt) ) + if ( !page ) { - put_gfn(curr->domain, gfn); return HVMCOPY_bad_gfn_to_mfn; } - ASSERT(mfn_valid(mfn)); - - p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK); + + p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK); if ( flags & HVMCOPY_to_guest ) { @@ -2437,12 +2407,12 @@ static enum hvm_copy_result __hvm_copy( if ( xchg(&lastpage, gfn) != gfn ) gdprintk(XENLOG_DEBUG, "guest attempted write to read-only" " memory page. gfn=%#lx, mfn=%#lx\n", - gfn, mfn); + gfn, page_to_mfn(page)); } else { memcpy(p, buf, count); - paging_mark_dirty(curr->domain, mfn); + paging_mark_dirty(curr->domain, page_to_mfn(page)); } } else @@ -2455,7 +2425,7 @@ static enum hvm_copy_result __hvm_copy( addr += count; buf += count; todo -= count; - put_gfn(curr->domain, gfn); + put_page(page); } return HVMCOPY_okay; @@ -2464,7 +2434,8 @@ static enum hvm_copy_result __hvm_copy( static enum hvm_copy_result __hvm_clear(paddr_t addr, int size) { struct vcpu *curr = current; - unsigned long gfn, mfn; + unsigned long gfn; + struct page_info *page; p2m_type_t p2mt; char *p; int count, todo = size; @@ -2500,32 +2471,35 @@ static enum hvm_copy_result __hvm_clear( return HVMCOPY_bad_gva_to_gfn; } - mfn = mfn_x(get_gfn_unshare(curr->domain, gfn, &p2mt)); + page = get_page_from_gfn(curr->domain, gfn, &p2mt, P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { + if ( page ) + put_page(page); 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); + if ( page ) + put_page(page); return HVMCOPY_gfn_shared; } if ( p2m_is_grant(p2mt) ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_unhandleable; } - if ( !p2m_is_ram(p2mt) ) + if ( !page ) { - put_gfn(curr->domain, gfn); + if ( page ) + put_page(page); return HVMCOPY_bad_gfn_to_mfn; } - ASSERT(mfn_valid(mfn)); - - p = (char *)map_domain_page(mfn) + (addr & ~PAGE_MASK); + + p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK); if ( p2mt == p2m_ram_ro ) { @@ -2533,19 +2507,19 @@ static enum hvm_copy_result __hvm_clear( if ( xchg(&lastpage, gfn) != gfn ) gdprintk(XENLOG_DEBUG, "guest attempted write to read-only" " memory page. gfn=%#lx, mfn=%#lx\n", - gfn, mfn); + gfn, page_to_mfn(page)); } else { memset(p, 0x00, count); - paging_mark_dirty(curr->domain, mfn); + paging_mark_dirty(curr->domain, page_to_mfn(page)); } unmap_domain_page(p); addr += count; todo -= count; - put_gfn(curr->domain, gfn); + put_page(page); } return HVMCOPY_okay; @@ -4000,35 +3974,16 @@ long do_hvm_op(unsigned long op, XEN_GUE for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ ) { - p2m_type_t t; - mfn_t mfn = get_gfn_unshare(d, pfn, &t); - if ( p2m_is_paging(t) ) + struct page_info *page; + page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE); + if ( page ) { - put_gfn(d, pfn); - p2m_mem_paging_populate(d, pfn); - rc = -EINVAL; - goto param_fail3; - } - if( p2m_is_shared(t) ) - { - /* If it insists on not unsharing itself, crash the domain - * rather than crashing the host down in mark dirty */ - gdprintk(XENLOG_WARNING, - "shared pfn 0x%lx modified?\n", pfn); - domain_crash(d); - put_gfn(d, pfn); - rc = -EINVAL; - goto param_fail3; - } - - if ( mfn_x(mfn) != INVALID_MFN ) - { - paging_mark_dirty(d, mfn_x(mfn)); + paging_mark_dirty(d, page_to_mfn(page)); /* These are most probably not page tables any more */ /* don't take a long time and don't die either */ - sh_remove_shadows(d->vcpu[0], mfn, 1, 0); + sh_remove_shadows(d->vcpu[0], _mfn(page_to_mfn(page)), 1, 0); + put_page(page); } - put_gfn(d, pfn); } param_fail3: diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/stdvga.c --- a/xen/arch/x86/hvm/stdvga.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/stdvga.c Thu May 10 15:54:16 2012 +0100 @@ -482,7 +482,8 @@ static int mmio_move(struct hvm_hw_stdvg if ( hvm_copy_to_guest_phys(data, &tmp, p->size) != HVMCOPY_okay ) { - (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt); + struct page_info *dp = get_page_from_gfn( + d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC); /* * The only case we handle is vga_mem <-> vga_mem. * Anything else disables caching and leaves it to qemu-dm. @@ -490,11 +491,12 @@ static int mmio_move(struct hvm_hw_stdvg if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) || ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) ) { - put_gfn(d, data >> PAGE_SHIFT); + if ( dp ) + put_page(dp); return 0; } + ASSERT(!dp); stdvga_mem_write(data, tmp, p->size); - put_gfn(d, data >> PAGE_SHIFT); } data += sign * p->size; addr += sign * p->size; @@ -508,15 +510,16 @@ static int mmio_move(struct hvm_hw_stdvg if ( hvm_copy_from_guest_phys(&tmp, data, p->size) != HVMCOPY_okay ) { - (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt); + struct page_info *dp = get_page_from_gfn( + d, data >> PAGE_SHIFT, &p2mt, P2M_ALLOC); if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) || ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) ) { - put_gfn(d, data >> PAGE_SHIFT); + if ( dp ) + put_page(dp); 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 d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/svm/svm.c --- a/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/svm/svm.c Thu May 10 15:54:16 2012 +0100 @@ -232,8 +232,7 @@ static int svm_vmcb_save(struct vcpu *v, static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) { - unsigned long mfn = 0; - p2m_type_t p2mt; + struct page_info *page = NULL; struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb; struct p2m_domain *p2m = p2m_get_hostp2m(v->domain); @@ -250,10 +249,10 @@ static int svm_vmcb_restore(struct vcpu { if ( c->cr0 & X86_CR0_PG ) { - mfn = mfn_x(get_gfn(v->domain, c->cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, c->cr3 >> PAGE_SHIFT); gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n", c->cr3); return -EINVAL; @@ -263,9 +262,8 @@ static int svm_vmcb_restore(struct vcpu if ( v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG ) put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - if ( c->cr0 & X86_CR0_PG ) - put_gfn(v->domain, c->cr3 >> PAGE_SHIFT); + v->arch.guest_table = + page ? pagetable_from_page(page) : pagetable_null(); } v->arch.hvm_vcpu.guest_cr[0] = c->cr0 | X86_CR0_ET; diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/viridian.c --- a/xen/arch/x86/hvm/viridian.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/viridian.c Thu May 10 15:54:16 2012 +0100 @@ -134,18 +134,19 @@ void dump_apic_assist(struct vcpu *v) static void enable_hypercall_page(struct domain *d) { unsigned long gmfn = d->arch.hvm_domain.viridian.hypercall_gpa.fields.pfn; - unsigned long mfn = get_gfn_untyped(d, gmfn); + struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); uint8_t *p; - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); - gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); + if ( page ) + put_page(page); + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, + page_to_mfn(page)); return; } - p = map_domain_page(mfn); + p = __map_domain_page(page); /* * We set the bit 31 in %eax (reserved field in the Viridian hypercall @@ -162,15 +163,14 @@ static void enable_hypercall_page(struct unmap_domain_page(p); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); } void initialize_apic_assist(struct vcpu *v) { struct domain *d = v->domain; unsigned long gmfn = v->arch.hvm_vcpu.viridian.apic_assist.fields.pfn; - unsigned long mfn = get_gfn_untyped(d, gmfn); + struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); uint8_t *p; /* @@ -183,22 +183,22 @@ void initialize_apic_assist(struct vcpu * details of how Windows uses the page. */ - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_writable_page) ) + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, gmfn); - gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, mfn); + if ( page ) + put_page(page); + gdprintk(XENLOG_WARNING, "Bad GMFN %lx (MFN %lx)\n", gmfn, + page_to_mfn(page)); return; } - p = map_domain_page(mfn); + p = __map_domain_page(page); *(u32 *)p = 0; unmap_domain_page(p); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, gmfn); + put_page_and_type(page); } int wrmsr_viridian_regs(uint32_t idx, uint64_t val) diff -r d774bb5c6326 -r 9da426cdc7e4 xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu May 10 15:54:16 2012 +0100 @@ -480,17 +480,16 @@ static void vmx_vmcs_save(struct vcpu *v static int vmx_restore_cr0_cr3( struct vcpu *v, unsigned long cr0, unsigned long cr3) { - unsigned long mfn = 0; - p2m_type_t p2mt; + struct page_info *page = NULL; if ( paging_mode_shadow(v->domain) ) { if ( cr0 & X86_CR0_PG ) { - mfn = mfn_x(get_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, + NULL, P2M_ALLOC); + if ( !page ) { - put_gfn(v->domain, cr3 >> PAGE_SHIFT); gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3); return -EINVAL; } @@ -499,9 +498,8 @@ static int vmx_restore_cr0_cr3( if ( hvm_paging_enabled(v) ) put_page(pagetable_get_page(v->arch.guest_table)); - v->arch.guest_table = pagetable_from_pfn(mfn); - if ( cr0 & X86_CR0_PG ) - put_gfn(v->domain, cr3 >> PAGE_SHIFT); + v->arch.guest_table = + page ? pagetable_from_page(page) : pagetable_null(); } v->arch.hvm_vcpu.guest_cr[0] = cr0 | X86_CR0_ET; @@ -1035,8 +1033,9 @@ static void vmx_set_interrupt_shadow(str static void vmx_load_pdptrs(struct vcpu *v) { - unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn; + unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3]; uint64_t *guest_pdptrs; + struct page_info *page; p2m_type_t p2mt; char *p; @@ -1047,24 +1046,19 @@ static void vmx_load_pdptrs(struct vcpu if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) goto crash; - mfn = mfn_x(get_gfn_unshare(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); - if ( !p2m_is_ram(p2mt) || !mfn_valid(mfn) || - /* If we didn't succeed in unsharing, get_page will fail - * (page still belongs to dom_cow) */ - !get_page(mfn_to_page(mfn), v->domain) ) + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); + if ( !page ) { /* Ideally you don't want to crash but rather go into a wait * queue, but this is the wrong place. We're holding at least * the paging lock */ gdprintk(XENLOG_ERR, - "Bad cr3 on load pdptrs gfn %lx mfn %lx type %d\n", - cr3 >> PAGE_SHIFT, mfn, (int) p2mt); - put_gfn(v->domain, cr3 >> PAGE_SHIFT); + "Bad cr3 on load pdptrs gfn %lx type %d\n", + cr3 >> PAGE_SHIFT, (int) p2mt); goto crash; } - put_gfn(v->domain, cr3 >> PAGE_SHIFT); - - p = map_domain_page(mfn); + + p = __map_domain_page(page); guest_pdptrs = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); @@ -1090,7 +1084,7 @@ static void vmx_load_pdptrs(struct vcpu vmx_vmcs_exit(v); unmap_domain_page(p); - put_page(mfn_to_page(mfn)); + put_page(page); return; crash: _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:06:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwS-0000H8-3D; Thu, 10 May 2012 15:06:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwQ-0000Ew-6T for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:06 +0000 Received: from [193.109.254.147:44084] by server-10.bemta-14.messagelabs.com id F2/24-05847-D59DBAF4; Thu, 10 May 2012 15:06:05 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1336662354!8614845!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17225 invoked from network); 10 May 2012 15:05:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068398" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwF-0007Pk-RM; Thu, 10 May 2012 16:05:55 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwD-0000K7-Do; Thu, 10 May 2012 16:05:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:52 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 08 of 11] grant-tables: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Andres Lagar-Cavilla # Date 1336661656 -3600 # Node ID ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b # Parent 28d15a29ab59d29a1fd5deb79ceda5d557343f14 grant-tables: Use get_page_from_gfn() instead of get_gfn()/put_gfn. This requires some careful re-engineering of __get_paged_frame and its callers. Functions that previously returned gfn's to be put now return pages to be put. Tested with Win7 + Citrix PV drivers guest, using speedtest for networking (yes!) plus the loginVSI framework to constantly hit disk. Signed-off-by: Andres Lagar-Cavilla diff -r 28d15a29ab59 -r ed61cd76e3e3 xen/common/grant_table.c --- a/xen/common/grant_table.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/grant_table.c Thu May 10 15:54:16 2012 +0100 @@ -107,18 +107,6 @@ static unsigned inline int max_nr_maptra return (max_nr_grant_frames * MAX_MAPTRACK_TO_GRANTS_RATIO); } -#ifdef CONFIG_X86 -#define gfn_to_mfn_private(_d, _gfn) ({ \ - p2m_type_t __p2mt; \ - unsigned long __x; \ - __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt)); \ - if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) ) \ - __x = INVALID_MFN; \ - __x; }) -#else -#define gfn_to_mfn_private(_d, _gfn) gmfn_to_mfn(_d, _gfn) -#endif - #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t)) #define shared_entry_v1(t, e) \ ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1]) @@ -141,41 +129,41 @@ 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. 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) +/* Check if the page has been paged out, or needs unsharing. + If rc == GNTST_okay, *page contains the page struct with a ref taken. + Caller must do put_page(*page). + If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */ +static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct page_info **page, + int readonly, struct domain *rd) { int rc = GNTST_okay; #if defined(P2M_PAGED_TYPES) || defined(P2M_SHARED_TYPES) p2m_type_t p2mt; - mfn_t mfn; - - if ( readonly ) - mfn = get_gfn(rd, gfn, &p2mt); - else + + *page = get_page_from_gfn(rd, gfn, &p2mt, + (readonly) ? P2M_ALLOC : P2M_UNSHARE); + if ( !(*page) ) { - mfn = get_gfn_unshare(rd, gfn, &p2mt); + *frame = INVALID_MFN; if ( p2m_is_shared(p2mt) ) + return GNTST_eagain; + if ( p2m_is_paging(p2mt) ) { - put_gfn(rd, gfn); + p2m_mem_paging_populate(rd, gfn); return GNTST_eagain; } + return GNTST_bad_page; } - - if ( p2m_is_valid(p2mt) ) { - *frame = mfn_x(mfn); - if ( p2m_is_paging(p2mt) ) - { - put_gfn(rd, gfn); - p2m_mem_paging_populate(rd, gfn); - rc = GNTST_eagain; - } - } else { - put_gfn(rd, gfn); - *frame = INVALID_MFN; - rc = GNTST_bad_page; + *frame = page_to_mfn(*page); +#else + *frame = gmfn_to_mfn(rd, gfn); + *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL; + if ( (!(*page)) || (!get_page(*page, rd)) ) + { + *frame = INVALID_MFN; + *page = NULL; + rc = GNTST_bad_page; } -#else - *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn); #endif return rc; @@ -470,12 +458,11 @@ static void __gnttab_map_grant_ref( struct gnttab_map_grant_ref *op) { - struct domain *ld, *rd, *owner; + struct domain *ld, *rd, *owner = NULL; struct vcpu *led; int handle; - unsigned long gfn = INVALID_GFN; unsigned long frame = 0, nr_gets = 0; - struct page_info *pg; + struct page_info *pg = NULL; int rc = GNTST_okay; u32 old_pin; u32 act_pin; @@ -573,13 +560,11 @@ static void { unsigned long frame; - gfn = sha1 ? sha1->frame : sha2->full_page.frame; - rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd); + unsigned long gfn = sha1 ? sha1->frame : sha2->full_page.frame; + rc = __get_paged_frame(gfn, &frame, &pg, + !!(op->flags & GNTMAP_readonly), rd); if ( rc != GNTST_okay ) - { - gfn = INVALID_GFN; goto unlock_out_clear; - } act->gfn = gfn; act->domid = ld->domain_id; act->frame = frame; @@ -606,9 +591,17 @@ static void spin_unlock(&rd->grant_table->lock); - pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL; - - if ( !pg || (owner = page_get_owner_and_reference(pg)) == dom_io ) + /* pg may be set, with a refcount included, from __get_paged_frame */ + if ( !pg ) + { + pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL; + if ( pg ) + owner = page_get_owner_and_reference(pg); + } + else + owner = page_get_owner(pg); + + if ( !pg || (owner == dom_io) ) { /* Only needed the reference to confirm dom_io ownership. */ if ( pg ) @@ -708,8 +701,6 @@ static void op->handle = handle; op->status = GNTST_okay; - if ( gfn != INVALID_GFN ) - put_gfn(rd, gfn); rcu_unlock_domain(rd); return; @@ -748,8 +739,6 @@ static void gnttab_clear_flag(_GTF_reading, status); unlock_out: - if ( gfn != INVALID_GFN ) - put_gfn(rd, gfn); spin_unlock(&rd->grant_table->lock); op->status = rc; put_maptrack_handle(ld->grant_table, handle); @@ -1479,7 +1468,16 @@ gnttab_transfer( return -EFAULT; } - mfn = gfn_to_mfn_private(d, gop.mfn); +#ifdef CONFIG_X86 + { + p2m_type_t __p2mt; + mfn = mfn_x(get_gfn_unshare(d, gop.mfn, &__p2mt)); + if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) ) + mfn = INVALID_MFN; + } +#else + mfn = gmfn_to_mfn(d, gop.mfn); +#endif /* Check the passed page frame for basic validity. */ if ( unlikely(!mfn_valid(mfn)) ) @@ -1723,15 +1721,14 @@ static void __fixup_status_for_pin(const } /* Grab a frame number from a grant entry and update the flags and pin - count as appropriate. Note that this does *not* update the page - type or reference counts, and does not check that the mfn is - actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then - we leave this function holding the p2m entry for *gfn in *owning_domain */ + count as appropriate. If rc == GNTST_okay, note that this *does* + take one ref count on the target page, stored in *page. + If there is any error, *page = NULL, no ref taken. */ static int __acquire_grant_for_copy( struct domain *rd, unsigned long gref, struct domain *ld, int readonly, - unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length, - unsigned allow_transitive, struct domain **owning_domain) + unsigned long *frame, struct page_info **page, + unsigned *page_off, unsigned *length, unsigned allow_transitive) { grant_entry_v1_t *sha1; grant_entry_v2_t *sha2; @@ -1746,11 +1743,9 @@ static int unsigned trans_page_off; unsigned trans_length; int is_sub_page; - struct domain *ignore; s16 rc = GNTST_okay; - *owning_domain = NULL; - *gfn = INVALID_GFN; + *page = NULL; spin_lock(&rd->grant_table->lock); @@ -1827,14 +1822,13 @@ static int spin_unlock(&rd->grant_table->lock); rc = __acquire_grant_for_copy(td, trans_gref, rd, - readonly, &grant_frame, gfn, - &trans_page_off, &trans_length, - 0, &ignore); + readonly, &grant_frame, page, + &trans_page_off, &trans_length, 0); spin_lock(&rd->grant_table->lock); if ( rc != GNTST_okay ) { __fixup_status_for_pin(act, status); - rcu_unlock_domain(td); + rcu_unlock_domain(td); spin_unlock(&rd->grant_table->lock); return rc; } @@ -1846,56 +1840,49 @@ static int if ( act->pin != old_pin ) { __fixup_status_for_pin(act, status); - rcu_unlock_domain(td); + rcu_unlock_domain(td); spin_unlock(&rd->grant_table->lock); + put_page(*page); return __acquire_grant_for_copy(rd, gref, ld, readonly, - frame, gfn, page_off, length, - allow_transitive, - owning_domain); + frame, page, page_off, length, + allow_transitive); } /* The actual remote remote grant may or may not be a sub-page, but we always treat it as one because that blocks mappings of transitive grants. */ is_sub_page = 1; - *owning_domain = td; act->gfn = -1ul; } else if ( sha1 ) { - *gfn = sha1->frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha1->frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha1->frame; is_sub_page = 0; trans_page_off = 0; trans_length = PAGE_SIZE; - *owning_domain = rd; } else if ( !(sha2->hdr.flags & GTF_sub_page) ) { - *gfn = sha2->full_page.frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha2->full_page.frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha2->full_page.frame; is_sub_page = 0; trans_page_off = 0; trans_length = PAGE_SIZE; - *owning_domain = rd; } else { - *gfn = sha2->sub_page.frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha2->sub_page.frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha2->sub_page.frame; is_sub_page = 1; trans_page_off = sha2->sub_page.page_off; trans_length = sha2->sub_page.length; - *owning_domain = rd; } if ( !act->pin ) @@ -1911,7 +1898,9 @@ static int } else { - *owning_domain = rd; + ASSERT(mfn_valid(act->frame)); + *page = mfn_to_page(act->frame); + (void)page_get_owner_and_reference(*page); } act->pin += readonly ? GNTPIN_hstr_inc : GNTPIN_hstw_inc; @@ -1930,11 +1919,11 @@ static void struct gnttab_copy *op) { struct domain *sd = NULL, *dd = NULL; - struct domain *source_domain = NULL, *dest_domain = NULL; - unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN; + unsigned long s_frame, d_frame; + struct page_info *s_pg = NULL, *d_pg = NULL; char *sp, *dp; s16 rc = GNTST_okay; - int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0; + int have_d_grant = 0, have_s_grant = 0; int src_is_gref, dest_is_gref; if ( ((op->source.offset + op->len) > PAGE_SIZE) || @@ -1972,82 +1961,54 @@ static void { unsigned source_off, source_len; rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1, - &s_frame, &s_gfn, &source_off, &source_len, 1, - &source_domain); + &s_frame, &s_pg, &source_off, &source_len, 1); if ( rc != GNTST_okay ) goto error_out; have_s_grant = 1; if ( op->source.offset < source_off || op->len > source_len ) - PIN_FAIL(error_put_s_gfn, GNTST_general_error, + PIN_FAIL(error_out, GNTST_general_error, "copy source out of bounds: %d < %d || %d > %d\n", op->source.offset, source_off, op->len, source_len); } else { -#ifdef CONFIG_X86 - s_gfn = op->source.u.gmfn; - rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd); + rc = __get_paged_frame(op->source.u.gmfn, &s_frame, &s_pg, 1, sd); if ( rc != GNTST_okay ) - goto error_out; -#else - s_frame = gmfn_to_mfn(sd, op->source.u.gmfn); -#endif - source_domain = sd; + PIN_FAIL(error_out, rc, + "source frame %lx invalid.\n", s_frame); } - if ( unlikely(!mfn_valid(s_frame)) ) - PIN_FAIL(error_put_s_gfn, GNTST_general_error, - "source frame %lx invalid.\n", s_frame); - /* For the source frame, the page could still be shared, so - * don't assume ownership by source_domain */ - if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) ) - { - if ( !sd->is_dying ) - gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame); - rc = GNTST_general_error; - goto error_put_s_gfn; - } - have_s_ref = 1; if ( dest_is_gref ) { unsigned dest_off, dest_len; rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0, - &d_frame, &d_gfn, &dest_off, &dest_len, 1, - &dest_domain); + &d_frame, &d_pg, &dest_off, &dest_len, 1); if ( rc != GNTST_okay ) - goto error_put_s_gfn; + goto error_out; have_d_grant = 1; if ( op->dest.offset < dest_off || op->len > dest_len ) - PIN_FAIL(error_put_d_gfn, GNTST_general_error, + PIN_FAIL(error_out, GNTST_general_error, "copy dest out of bounds: %d < %d || %d > %d\n", op->dest.offset, dest_off, op->len, dest_len); } else { -#ifdef CONFIG_X86 - d_gfn = op->dest.u.gmfn; - rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd); + rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, &d_pg, 0, dd); if ( rc != GNTST_okay ) - goto error_put_s_gfn; -#else - d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn); -#endif - dest_domain = dd; + PIN_FAIL(error_out, rc, + "destination frame %lx invalid.\n", d_frame); } - if ( unlikely(!mfn_valid(d_frame)) ) - PIN_FAIL(error_put_d_gfn, GNTST_general_error, - "destination frame %lx invalid.\n", d_frame); - if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain, - PGT_writable_page) ) + + if ( !get_page_type(d_pg, PGT_writable_page) ) { if ( !dd->is_dying ) gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame); rc = GNTST_general_error; - goto error_put_d_gfn; + goto error_out; } sp = map_domain_page(s_frame); @@ -2060,16 +2021,12 @@ static void gnttab_mark_dirty(dd, d_frame); - put_page_and_type(mfn_to_page(d_frame)); - error_put_d_gfn: - if ( (d_gfn != INVALID_GFN) && (dest_domain) ) - put_gfn(dest_domain, d_gfn); - error_put_s_gfn: - if ( (s_gfn != INVALID_GFN) && (source_domain) ) - put_gfn(source_domain, s_gfn); + put_page_type(d_pg); error_out: - if ( have_s_ref ) - put_page(mfn_to_page(s_frame)); + if ( d_pg ) + put_page(d_pg); + if ( s_pg ) + put_page(s_pg); if ( have_s_grant ) __release_grant_for_copy(sd, op->source.u.ref, 1); if ( have_d_grant ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:06:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:06:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwS-0000H8-3D; Thu, 10 May 2012 15:06:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUwQ-0000Ew-6T for xen-devel@lists.xen.org; Thu, 10 May 2012 15:06:06 +0000 Received: from [193.109.254.147:44084] by server-10.bemta-14.messagelabs.com id F2/24-05847-D59DBAF4; Thu, 10 May 2012 15:06:05 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1336662354!8614845!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17225 invoked from network); 10 May 2012 15:05:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:05:59 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25068398" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwF-0007Pk-RM; Thu, 10 May 2012 16:05:55 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwD-0000K7-Do; Thu, 10 May 2012 16:05:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:52 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 08 of 11] grant-tables: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Andres Lagar-Cavilla # Date 1336661656 -3600 # Node ID ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b # Parent 28d15a29ab59d29a1fd5deb79ceda5d557343f14 grant-tables: Use get_page_from_gfn() instead of get_gfn()/put_gfn. This requires some careful re-engineering of __get_paged_frame and its callers. Functions that previously returned gfn's to be put now return pages to be put. Tested with Win7 + Citrix PV drivers guest, using speedtest for networking (yes!) plus the loginVSI framework to constantly hit disk. Signed-off-by: Andres Lagar-Cavilla diff -r 28d15a29ab59 -r ed61cd76e3e3 xen/common/grant_table.c --- a/xen/common/grant_table.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/grant_table.c Thu May 10 15:54:16 2012 +0100 @@ -107,18 +107,6 @@ static unsigned inline int max_nr_maptra return (max_nr_grant_frames * MAX_MAPTRACK_TO_GRANTS_RATIO); } -#ifdef CONFIG_X86 -#define gfn_to_mfn_private(_d, _gfn) ({ \ - p2m_type_t __p2mt; \ - unsigned long __x; \ - __x = mfn_x(get_gfn_unshare((_d), (_gfn), &__p2mt)); \ - if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) ) \ - __x = INVALID_MFN; \ - __x; }) -#else -#define gfn_to_mfn_private(_d, _gfn) gmfn_to_mfn(_d, _gfn) -#endif - #define SHGNT_PER_PAGE_V1 (PAGE_SIZE / sizeof(grant_entry_v1_t)) #define shared_entry_v1(t, e) \ ((t)->shared_v1[(e)/SHGNT_PER_PAGE_V1][(e)%SHGNT_PER_PAGE_V1]) @@ -141,41 +129,41 @@ 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. 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) +/* Check if the page has been paged out, or needs unsharing. + If rc == GNTST_okay, *page contains the page struct with a ref taken. + Caller must do put_page(*page). + If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */ +static int __get_paged_frame(unsigned long gfn, unsigned long *frame, struct page_info **page, + int readonly, struct domain *rd) { int rc = GNTST_okay; #if defined(P2M_PAGED_TYPES) || defined(P2M_SHARED_TYPES) p2m_type_t p2mt; - mfn_t mfn; - - if ( readonly ) - mfn = get_gfn(rd, gfn, &p2mt); - else + + *page = get_page_from_gfn(rd, gfn, &p2mt, + (readonly) ? P2M_ALLOC : P2M_UNSHARE); + if ( !(*page) ) { - mfn = get_gfn_unshare(rd, gfn, &p2mt); + *frame = INVALID_MFN; if ( p2m_is_shared(p2mt) ) + return GNTST_eagain; + if ( p2m_is_paging(p2mt) ) { - put_gfn(rd, gfn); + p2m_mem_paging_populate(rd, gfn); return GNTST_eagain; } + return GNTST_bad_page; } - - if ( p2m_is_valid(p2mt) ) { - *frame = mfn_x(mfn); - if ( p2m_is_paging(p2mt) ) - { - put_gfn(rd, gfn); - p2m_mem_paging_populate(rd, gfn); - rc = GNTST_eagain; - } - } else { - put_gfn(rd, gfn); - *frame = INVALID_MFN; - rc = GNTST_bad_page; + *frame = page_to_mfn(*page); +#else + *frame = gmfn_to_mfn(rd, gfn); + *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL; + if ( (!(*page)) || (!get_page(*page, rd)) ) + { + *frame = INVALID_MFN; + *page = NULL; + rc = GNTST_bad_page; } -#else - *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn); #endif return rc; @@ -470,12 +458,11 @@ static void __gnttab_map_grant_ref( struct gnttab_map_grant_ref *op) { - struct domain *ld, *rd, *owner; + struct domain *ld, *rd, *owner = NULL; struct vcpu *led; int handle; - unsigned long gfn = INVALID_GFN; unsigned long frame = 0, nr_gets = 0; - struct page_info *pg; + struct page_info *pg = NULL; int rc = GNTST_okay; u32 old_pin; u32 act_pin; @@ -573,13 +560,11 @@ static void { unsigned long frame; - gfn = sha1 ? sha1->frame : sha2->full_page.frame; - rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd); + unsigned long gfn = sha1 ? sha1->frame : sha2->full_page.frame; + rc = __get_paged_frame(gfn, &frame, &pg, + !!(op->flags & GNTMAP_readonly), rd); if ( rc != GNTST_okay ) - { - gfn = INVALID_GFN; goto unlock_out_clear; - } act->gfn = gfn; act->domid = ld->domain_id; act->frame = frame; @@ -606,9 +591,17 @@ static void spin_unlock(&rd->grant_table->lock); - pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL; - - if ( !pg || (owner = page_get_owner_and_reference(pg)) == dom_io ) + /* pg may be set, with a refcount included, from __get_paged_frame */ + if ( !pg ) + { + pg = mfn_valid(frame) ? mfn_to_page(frame) : NULL; + if ( pg ) + owner = page_get_owner_and_reference(pg); + } + else + owner = page_get_owner(pg); + + if ( !pg || (owner == dom_io) ) { /* Only needed the reference to confirm dom_io ownership. */ if ( pg ) @@ -708,8 +701,6 @@ static void op->handle = handle; op->status = GNTST_okay; - if ( gfn != INVALID_GFN ) - put_gfn(rd, gfn); rcu_unlock_domain(rd); return; @@ -748,8 +739,6 @@ static void gnttab_clear_flag(_GTF_reading, status); unlock_out: - if ( gfn != INVALID_GFN ) - put_gfn(rd, gfn); spin_unlock(&rd->grant_table->lock); op->status = rc; put_maptrack_handle(ld->grant_table, handle); @@ -1479,7 +1468,16 @@ gnttab_transfer( return -EFAULT; } - mfn = gfn_to_mfn_private(d, gop.mfn); +#ifdef CONFIG_X86 + { + p2m_type_t __p2mt; + mfn = mfn_x(get_gfn_unshare(d, gop.mfn, &__p2mt)); + if ( p2m_is_shared(__p2mt) || !p2m_is_valid(__p2mt) ) + mfn = INVALID_MFN; + } +#else + mfn = gmfn_to_mfn(d, gop.mfn); +#endif /* Check the passed page frame for basic validity. */ if ( unlikely(!mfn_valid(mfn)) ) @@ -1723,15 +1721,14 @@ static void __fixup_status_for_pin(const } /* Grab a frame number from a grant entry and update the flags and pin - count as appropriate. Note that this does *not* update the page - type or reference counts, and does not check that the mfn is - actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then - we leave this function holding the p2m entry for *gfn in *owning_domain */ + count as appropriate. If rc == GNTST_okay, note that this *does* + take one ref count on the target page, stored in *page. + If there is any error, *page = NULL, no ref taken. */ static int __acquire_grant_for_copy( struct domain *rd, unsigned long gref, struct domain *ld, int readonly, - unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length, - unsigned allow_transitive, struct domain **owning_domain) + unsigned long *frame, struct page_info **page, + unsigned *page_off, unsigned *length, unsigned allow_transitive) { grant_entry_v1_t *sha1; grant_entry_v2_t *sha2; @@ -1746,11 +1743,9 @@ static int unsigned trans_page_off; unsigned trans_length; int is_sub_page; - struct domain *ignore; s16 rc = GNTST_okay; - *owning_domain = NULL; - *gfn = INVALID_GFN; + *page = NULL; spin_lock(&rd->grant_table->lock); @@ -1827,14 +1822,13 @@ static int spin_unlock(&rd->grant_table->lock); rc = __acquire_grant_for_copy(td, trans_gref, rd, - readonly, &grant_frame, gfn, - &trans_page_off, &trans_length, - 0, &ignore); + readonly, &grant_frame, page, + &trans_page_off, &trans_length, 0); spin_lock(&rd->grant_table->lock); if ( rc != GNTST_okay ) { __fixup_status_for_pin(act, status); - rcu_unlock_domain(td); + rcu_unlock_domain(td); spin_unlock(&rd->grant_table->lock); return rc; } @@ -1846,56 +1840,49 @@ static int if ( act->pin != old_pin ) { __fixup_status_for_pin(act, status); - rcu_unlock_domain(td); + rcu_unlock_domain(td); spin_unlock(&rd->grant_table->lock); + put_page(*page); return __acquire_grant_for_copy(rd, gref, ld, readonly, - frame, gfn, page_off, length, - allow_transitive, - owning_domain); + frame, page, page_off, length, + allow_transitive); } /* The actual remote remote grant may or may not be a sub-page, but we always treat it as one because that blocks mappings of transitive grants. */ is_sub_page = 1; - *owning_domain = td; act->gfn = -1ul; } else if ( sha1 ) { - *gfn = sha1->frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha1->frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha1->frame; is_sub_page = 0; trans_page_off = 0; trans_length = PAGE_SIZE; - *owning_domain = rd; } else if ( !(sha2->hdr.flags & GTF_sub_page) ) { - *gfn = sha2->full_page.frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha2->full_page.frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha2->full_page.frame; is_sub_page = 0; trans_page_off = 0; trans_length = PAGE_SIZE; - *owning_domain = rd; } else { - *gfn = sha2->sub_page.frame; - rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd); + rc = __get_paged_frame(sha2->sub_page.frame, &grant_frame, page, readonly, rd); if ( rc != GNTST_okay ) goto unlock_out; - act->gfn = *gfn; + act->gfn = sha2->sub_page.frame; is_sub_page = 1; trans_page_off = sha2->sub_page.page_off; trans_length = sha2->sub_page.length; - *owning_domain = rd; } if ( !act->pin ) @@ -1911,7 +1898,9 @@ static int } else { - *owning_domain = rd; + ASSERT(mfn_valid(act->frame)); + *page = mfn_to_page(act->frame); + (void)page_get_owner_and_reference(*page); } act->pin += readonly ? GNTPIN_hstr_inc : GNTPIN_hstw_inc; @@ -1930,11 +1919,11 @@ static void struct gnttab_copy *op) { struct domain *sd = NULL, *dd = NULL; - struct domain *source_domain = NULL, *dest_domain = NULL; - unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN; + unsigned long s_frame, d_frame; + struct page_info *s_pg = NULL, *d_pg = NULL; char *sp, *dp; s16 rc = GNTST_okay; - int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0; + int have_d_grant = 0, have_s_grant = 0; int src_is_gref, dest_is_gref; if ( ((op->source.offset + op->len) > PAGE_SIZE) || @@ -1972,82 +1961,54 @@ static void { unsigned source_off, source_len; rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1, - &s_frame, &s_gfn, &source_off, &source_len, 1, - &source_domain); + &s_frame, &s_pg, &source_off, &source_len, 1); if ( rc != GNTST_okay ) goto error_out; have_s_grant = 1; if ( op->source.offset < source_off || op->len > source_len ) - PIN_FAIL(error_put_s_gfn, GNTST_general_error, + PIN_FAIL(error_out, GNTST_general_error, "copy source out of bounds: %d < %d || %d > %d\n", op->source.offset, source_off, op->len, source_len); } else { -#ifdef CONFIG_X86 - s_gfn = op->source.u.gmfn; - rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd); + rc = __get_paged_frame(op->source.u.gmfn, &s_frame, &s_pg, 1, sd); if ( rc != GNTST_okay ) - goto error_out; -#else - s_frame = gmfn_to_mfn(sd, op->source.u.gmfn); -#endif - source_domain = sd; + PIN_FAIL(error_out, rc, + "source frame %lx invalid.\n", s_frame); } - if ( unlikely(!mfn_valid(s_frame)) ) - PIN_FAIL(error_put_s_gfn, GNTST_general_error, - "source frame %lx invalid.\n", s_frame); - /* For the source frame, the page could still be shared, so - * don't assume ownership by source_domain */ - if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) ) - { - if ( !sd->is_dying ) - gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame); - rc = GNTST_general_error; - goto error_put_s_gfn; - } - have_s_ref = 1; if ( dest_is_gref ) { unsigned dest_off, dest_len; rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0, - &d_frame, &d_gfn, &dest_off, &dest_len, 1, - &dest_domain); + &d_frame, &d_pg, &dest_off, &dest_len, 1); if ( rc != GNTST_okay ) - goto error_put_s_gfn; + goto error_out; have_d_grant = 1; if ( op->dest.offset < dest_off || op->len > dest_len ) - PIN_FAIL(error_put_d_gfn, GNTST_general_error, + PIN_FAIL(error_out, GNTST_general_error, "copy dest out of bounds: %d < %d || %d > %d\n", op->dest.offset, dest_off, op->len, dest_len); } else { -#ifdef CONFIG_X86 - d_gfn = op->dest.u.gmfn; - rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd); + rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, &d_pg, 0, dd); if ( rc != GNTST_okay ) - goto error_put_s_gfn; -#else - d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn); -#endif - dest_domain = dd; + PIN_FAIL(error_out, rc, + "destination frame %lx invalid.\n", d_frame); } - if ( unlikely(!mfn_valid(d_frame)) ) - PIN_FAIL(error_put_d_gfn, GNTST_general_error, - "destination frame %lx invalid.\n", d_frame); - if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain, - PGT_writable_page) ) + + if ( !get_page_type(d_pg, PGT_writable_page) ) { if ( !dd->is_dying ) gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame); rc = GNTST_general_error; - goto error_put_d_gfn; + goto error_out; } sp = map_domain_page(s_frame); @@ -2060,16 +2021,12 @@ static void gnttab_mark_dirty(dd, d_frame); - put_page_and_type(mfn_to_page(d_frame)); - error_put_d_gfn: - if ( (d_gfn != INVALID_GFN) && (dest_domain) ) - put_gfn(dest_domain, d_gfn); - error_put_s_gfn: - if ( (s_gfn != INVALID_GFN) && (source_domain) ) - put_gfn(source_domain, s_gfn); + put_page_type(d_pg); error_out: - if ( have_s_ref ) - put_page(mfn_to_page(s_frame)); + if ( d_pg ) + put_page(d_pg); + if ( s_pg ) + put_page(s_pg); if ( have_s_grant ) __release_grant_for_copy(sd, op->source.u.ref, 1); if ( have_d_grant ) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:07:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSUxj-0000ic-AD; Thu, 10 May 2012 15:07:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUxh-0000i1-RQ for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:07:26 +0000 Received: from [85.158.143.35:26535] by server-1.bemta-4.messagelabs.com id 36/C6-20925-DA9DBAF4; Thu, 10 May 2012 15:07:25 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336662442!15490098!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2801 invoked from network); 10 May 2012 15:07:22 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-21.messagelabs.com with SMTP; 10 May 2012 15:07:22 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 08:07:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="141431584" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 10 May 2012 08:06:17 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 08:06:16 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Thu, 10 May 2012 23:06:14 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: Ac0uvnBnJV8RtIigTTax7Uicx2M6Kw== Date: Thu, 10 May 2012 15:06:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_" MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong Date: Fri, 11 May 2012 06:55:35 +0800 Subject: [PATCH 3/3] Xen physical cpus interface Manage physical cpus in dom0, get physical cpus info and provide sys interf= ace. Signed-off-by: Liu, Jinsong Signed-off-by: Jiang, Yunhong --- .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + drivers/xen/Makefile | 1 + drivers/xen/pcpu.c | 374 ++++++++++++++++= ++++ include/xen/interface/platform.h | 8 + include/xen/interface/xen.h | 1 + 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu create mode 100644 drivers/xen/pcpu.c diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Docum= entation/ABI/testing/sysfs-devices-system-xen_cpu new file mode 100644 index 0000000..9ca02fb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu @@ -0,0 +1,20 @@ +What: /sys/devices/system/xen_cpu/ +Date: May 2012 +Contact: Liu, Jinsong +Description: + A collection of global/individual Xen physical cpu attributes + + Individual physical cpu attributes are contained in + subdirectories named by the Xen's logical cpu number, e.g.: + /sys/devices/system/xen_cpu/xen_cpu#/ + + +What: /sys/devices/system/xen_cpu/xen_cpu#/online +Date: May 2012 +Contact: Liu, Jinsong +Description: + Interface to online/offline Xen physical cpus + + When running under Xen platform, it provide user interface + to online/offline physical cpus, except cpu0 due to several + logic restrictions and assumptions. diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 1d3e763..d12d14d 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM) +=3D platform-pci.o obj-$(CONFIG_XEN_TMEM) +=3D tmem.o obj-$(CONFIG_SWIOTLB_XEN) +=3D swiotlb-xen.o obj-$(CONFIG_XEN_DOM0) +=3D pci.o +obj-$(CONFIG_XEN_DOM0) +=3D pcpu.o obj-$(CONFIG_XEN_PCIDEV_BACKEND) +=3D xen-pciback/ obj-$(CONFIG_XEN_PRIVCMD) +=3D xen-privcmd.o obj-$(CONFIG_XEN_ACPI_PROCESSOR) +=3D xen-acpi-processor.o diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c new file mode 100644 index 0000000..9014ff1 --- /dev/null +++ b/drivers/xen/pcpu.c @@ -0,0 +1,374 @@ +/*************************************************************************= ***** + * pcpu.c + * Management physical cpu in dom0, get pcpu info and provide sys interfac= e + * + * Copyright (c) 2012 Intel Corporation + * Author: Liu, Jinsong + * Author: Jiang, Yunhong + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a= copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modi= fy, + * merge, publish, distribute, sublicense, and/or sell copies of the Softw= are, + * and to permit persons to whom the Software is furnished to do so, subje= ct to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included= in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS= OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY= , + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL= THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA= LINGS + * IN THE SOFTWARE. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define XEN_PCPU "xen_cpu: " + +/* + * @cpu_id: Xen physical cpu logic number + * @flags: Xen physical cpu status flag + * - XEN_PCPU_FLAGS_ONLINE: cpu is online + * - XEN_PCPU_FLAGS_INVALID: cpu is not present + */ +struct pcpu { + struct list_head list; + struct device dev; + uint32_t cpu_id; + uint32_t flags; +}; + +static struct bus_type xen_pcpu_subsys =3D { + .name =3D "xen_cpu", + .dev_name =3D "xen_cpu", +}; + +static DEFINE_MUTEX(xen_pcpu_lock); + +static LIST_HEAD(xen_pcpus); + +static int xen_pcpu_down(uint32_t cpu_id) +{ + struct xen_platform_op op =3D { + .cmd =3D XENPF_cpu_offline, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.cpu_ol.cpuid =3D cpu_id, + }; + + return HYPERVISOR_dom0_op(&op); +} + +static int xen_pcpu_up(uint32_t cpu_id) +{ + struct xen_platform_op op =3D { + .cmd =3D XENPF_cpu_online, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.cpu_ol.cpuid =3D cpu_id, + }; + + return HYPERVISOR_dom0_op(&op); +} + +static ssize_t show_online(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct pcpu *cpu =3D container_of(dev, struct pcpu, dev); + + return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE)); +} + +static ssize_t __ref store_online(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev); + unsigned long long val; + ssize_t ret; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + if (kstrtoull(buf, 0, &val) < 0) + return -EINVAL; + + switch (val) { + case 0: + ret =3D xen_pcpu_down(pcpu->cpu_id); + break; + case 1: + ret =3D xen_pcpu_up(pcpu->cpu_id); + break; + default: + ret =3D -EINVAL; + } + + if (ret >=3D 0) + ret =3D count; + return ret; +} +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online); + +static bool xen_pcpu_online(uint32_t flags) +{ + return !!(flags & XEN_PCPU_FLAGS_ONLINE); +} + +static void pcpu_online_status(struct xenpf_pcpuinfo *info, + struct pcpu *pcpu) +{ + if (xen_pcpu_online(info->flags) && + !xen_pcpu_online(pcpu->flags)) { + /* the pcpu is onlined */ + pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE; + kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE); + } else if (!xen_pcpu_online(info->flags) && + xen_pcpu_online(pcpu->flags)) { + /* The pcpu is offlined */ + pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE; + kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE); + } +} + +static struct pcpu *get_pcpu(uint32_t cpu_id) +{ + struct list_head *cur; + struct pcpu *pcpu; + + list_for_each(cur, &xen_pcpus) { + pcpu =3D list_entry(cur, struct pcpu, list); + if (pcpu->cpu_id =3D=3D cpu_id) + return pcpu; + } + + return NULL; +} + +static void pcpu_sys_remove(struct pcpu *pcpu) +{ + struct device *dev; + + if (!pcpu) + return; + + dev =3D &pcpu->dev; + if (dev->id) + device_remove_file(dev, &dev_attr_online); + + device_unregister(dev); +} + +static void free_pcpu(struct pcpu *pcpu) +{ + if (!pcpu) + return; + + pcpu_sys_remove(pcpu); + + list_del(&pcpu->list); + kfree(pcpu); +} + +static int pcpu_sys_create(struct pcpu *pcpu) +{ + struct device *dev; + int err =3D -EINVAL; + + if (!pcpu) + return err; + + dev =3D &pcpu->dev; + dev->bus =3D &xen_pcpu_subsys; + dev->id =3D pcpu->cpu_id; + + err =3D device_register(dev); + if (err) + return err; + + /* + * Xen never offline cpu0 due to several restrictions + * and assumptions. This basically doesn't add a sys control + * to user, one cannot attempt to offline BSP. + */ + if (dev->id) { + err =3D device_create_file(dev, &dev_attr_online); + if (err) { + device_unregister(dev); + return err; + } + } + + return 0; +} + +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) +{ + struct pcpu *pcpu; + int err; + + if (info->flags & XEN_PCPU_FLAGS_INVALID) + return ERR_PTR(-ENODEV); + + pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL); + if (!pcpu) + return ERR_PTR(-ENOMEM); + + INIT_LIST_HEAD(&pcpu->list); + pcpu->cpu_id =3D info->xen_cpuid; + pcpu->flags =3D info->flags; + + err =3D pcpu_sys_create(pcpu); + if (err) { + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", + info->xen_cpuid); + kfree(pcpu); + return ERR_PTR(-ENOENT); + } + + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ + list_add_tail(&pcpu->list, &xen_pcpus); + return pcpu; +} + +/* + * Caller should hold the xen_pcpu_lock + */ +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) +{ + int ret; + struct pcpu *pcpu =3D NULL; + struct xenpf_pcpuinfo *info; + struct xen_platform_op op =3D { + .cmd =3D XENPF_get_cpuinfo, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid =3D cpu, + }; + + ret =3D HYPERVISOR_dom0_op(&op); + if (ret) + return ret; + + info =3D &op.u.pcpu_info; + if (max_cpu) + *max_cpu =3D info->max_present; + + pcpu =3D get_pcpu(cpu); + + if (info->flags & XEN_PCPU_FLAGS_INVALID) { + /* The pcpu has been removed */ + if (pcpu) + free_pcpu(pcpu); + return 0; + } + + if (!pcpu) { + pcpu =3D init_pcpu(info); + if (IS_ERR_OR_NULL(pcpu)) + return -ENODEV; + } else + pcpu_online_status(info, pcpu); + + return 0; +} + +/* + * Sync dom0's pcpu information with xen hypervisor's + */ +static int xen_sync_pcpus(void) +{ + /* + * Boot cpu always have cpu_id 0 in xen + */ + uint32_t cpu =3D 0, max_cpu =3D 0; + int err =3D 0; + struct list_head *cur, *tmp; + struct pcpu *pcpu; + + mutex_lock(&xen_pcpu_lock); + + while (!err && (cpu <=3D max_cpu)) { + err =3D sync_pcpu(cpu, &max_cpu); + cpu++; + } + + if (err) { + list_for_each_safe(cur, tmp, &xen_pcpus) { + pcpu =3D list_entry(cur, struct pcpu, list); + free_pcpu(pcpu); + } + } + + mutex_unlock(&xen_pcpu_lock); + + return err; +} + +static void xen_pcpu_work_fn(struct work_struct *work) +{ + xen_sync_pcpus(); +} +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); + +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) +{ + schedule_work(&xen_pcpu_work); + return IRQ_HANDLED; +} + +static int __init xen_pcpu_init(void) +{ + int irq, ret; + + if (!xen_initial_domain()) + return -ENODEV; + + irq =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, + xen_pcpu_interrupt, 0, + "xen-pcpu", NULL); + if (irq < 0) { + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); + return irq; + } + + ret =3D subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); + goto err1; + } + + ret =3D xen_sync_pcpus(); + if (ret) { + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + goto err2; + } + + return 0; + +err2: + bus_unregister(&xen_pcpu_subsys); +err1: + unbind_from_irqhandler(irq, NULL); + return ret; +} +arch_initcall(xen_pcpu_init); diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf= orm.h index 486653f..61fa661 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo { }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); =20 +#define XENPF_cpu_online 56 +#define XENPF_cpu_offline 57 +struct xenpf_cpu_ol { + uint32_t cpuid; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); + struct xen_platform_op { uint32_t cmd; uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ @@ -330,6 +337,7 @@ struct xen_platform_op { struct xenpf_getidletime getidletime; struct xenpf_set_processor_pminfo set_pminfo; struct xenpf_pcpuinfo pcpu_info; + struct xenpf_cpu_ol cpu_ol; uint8_t pad[128]; } u; }; diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index a890804..0801468 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -80,6 +80,7 @@ #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency console. = */ #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event for some domain. = */ #define VIRQ_DEBUGGER 6 /* (DOM0) A domain has paused for debugging. = */ +#define VIRQ_PCPU_STATE 9 /* (DOM0) PCPU state changed = */ =20 /* Architecture-specific VIRQ definitions. */ #define VIRQ_ARCH_0 16 --=20 1.7.1 --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="0003-Xen-physical-cpus-interface.patch" Content-Description: 0003-Xen-physical-cpus-interface.patch Content-Disposition: attachment; filename="0003-Xen-physical-cpus-interface.patch"; size=12603; creation-date="Thu, 10 May 2012 15:03:13 GMT"; modification-date="Thu, 10 May 2012 22:58:00 GMT" Content-Transfer-Encoding: base64 RnJvbSA3YWE0Y2Y3YzExNzJlMjQ2MTFkYzc2MTYzMzk3Yjg3MDhhY2FjYzU5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K RGF0ZTogRnJpLCAxMSBNYXkgMjAxMiAwNjo1NTozNSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z XSBYZW4gcGh5c2ljYWwgY3B1cyBpbnRlcmZhY2UKCk1hbmFnZSBwaHlzaWNhbCBjcHVzIGluIGRv bTAsIGdldCBwaHlzaWNhbCBjcHVzIGluZm8gYW5kIHByb3ZpZGUgc3lzIGludGVyZmFjZS4KClNp Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+Ci0tLQogLi4u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUgICAgICAgfCAgIDIwICsK IGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg MSArCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAzNzQgKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9y bS5oICAgICAgICAgICAgICAgICAgIHwgICAgOCArCiBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVu LmggICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDEgKwogNSBmaWxlcyBjaGFuZ2VkLCA0MDQg aW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBEb2N1bWVu dGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUKIGNyZWF0ZSBt b2RlIDEwMDY0NCBkcml2ZXJzL3hlbi9wY3B1LmMKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUgYi9Eb2N1bWVudGF0aW9u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUKbmV3IGZpbGUgbW9kZSAx MDA2NDQKaW5kZXggMDAwMDAwMC4uOWNhMDJmYgotLS0gL2Rldi9udWxsCisrKyBiL0RvY3VtZW50 YXRpb24vQUJJL3Rlc3Rpbmcvc3lzZnMtZGV2aWNlcy1zeXN0ZW0teGVuX2NwdQpAQCAtMCwwICsx LDIwIEBACitXaGF0OgkJL3N5cy9kZXZpY2VzL3N5c3RlbS94ZW5fY3B1LworRGF0ZToJCU1heSAy MDEyCitDb250YWN0OglMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KK0Rlc2Ny aXB0aW9uOgorCQlBIGNvbGxlY3Rpb24gb2YgZ2xvYmFsL2luZGl2aWR1YWwgWGVuIHBoeXNpY2Fs IGNwdSBhdHRyaWJ1dGVzCisKKwkJSW5kaXZpZHVhbCBwaHlzaWNhbCBjcHUgYXR0cmlidXRlcyBh cmUgY29udGFpbmVkIGluCisJCXN1YmRpcmVjdG9yaWVzIG5hbWVkIGJ5IHRoZSBYZW4ncyBsb2dp Y2FsIGNwdSBudW1iZXIsIGUuZy46CisJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2NwdS94ZW5f Y3B1Iy8KKworCitXaGF0OgkJL3N5cy9kZXZpY2VzL3N5c3RlbS94ZW5fY3B1L3hlbl9jcHUjL29u bGluZQorRGF0ZToJCU1heSAyMDEyCitDb250YWN0OglMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1 QGludGVsLmNvbT4KK0Rlc2NyaXB0aW9uOgorCQlJbnRlcmZhY2UgdG8gb25saW5lL29mZmxpbmUg WGVuIHBoeXNpY2FsIGNwdXMKKworCQlXaGVuIHJ1bm5pbmcgdW5kZXIgWGVuIHBsYXRmb3JtLCBp dCBwcm92aWRlIHVzZXIgaW50ZXJmYWNlCisJCXRvIG9ubGluZS9vZmZsaW5lIHBoeXNpY2FsIGNw dXMsIGV4Y2VwdCBjcHUwIGR1ZSB0byBzZXZlcmFsCisJCWxvZ2ljIHJlc3RyaWN0aW9ucyBhbmQg YXNzdW1wdGlvbnMuCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMv eGVuL01ha2VmaWxlCmluZGV4IDFkM2U3NjMuLmQxMmQxNGQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMv eGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0xOSw2ICsxOSw3IEBA IG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9iai0kKENPTkZJ R19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3 aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubworb2JqLSQoQ09O RklHX1hFTl9ET00wKQkJCSs9IHBjcHUubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO RCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJp dmNtZC5vCiBvYmotJChDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SKQkrPSB4ZW4tYWNwaS1wcm9j ZXNzb3IubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vcGNwdS5jIGIvZHJpdmVycy94ZW4vcGNw dS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjkwMTRmZjEKLS0tIC9kZXYv bnVsbAorKysgYi9kcml2ZXJzL3hlbi9wY3B1LmMKQEAgLTAsMCArMSwzNzQgQEAKKy8qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioKKyAqIHBjcHUuYworICogTWFuYWdlbWVudCBwaHlzaWNhbCBjcHUgaW4g ZG9tMCwgZ2V0IHBjcHUgaW5mbyBhbmQgcHJvdmlkZSBzeXMgaW50ZXJmYWNlCisgKgorICogQ29w eXJpZ2h0IChjKSAyMDEyIEludGVsIENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29u ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICogQXV0aG9yOiBKaWFuZywgWXVuaG9uZyA8eXVu aG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVuZGVyIHRo ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyCisgKiBh cyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdoZW4gZGlz dHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGluY29ycG9y YXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0aGUgZm9s bG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJl ZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBz b3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2FyZSB3aXRo b3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0aGUgcmln aHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3RyaWJ1dGUs IHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisgKiBhbmQg dG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVkIHRvIGRv IHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgorICogVGhl IGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwg YmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlvbnMgb2Yg dGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBX SVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVELCBJTkNM VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZSSU5HRU1F TlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVS UyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElBQklMSVRZ LCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJU0UsIEFS SVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNPRlRXQVJF IE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4KKyAqLwor CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2su aD4KKyNpbmNsdWRlIDxsaW51eC9jcHUuaD4KKyNpbmNsdWRlIDxsaW51eC9zdGF0Lmg+CisjaW5j bHVkZSA8bGludXgvY2FwYWJpbGl0eS5oPgorCisjaW5jbHVkZSA8eGVuL3hlbi5oPgorI2luY2x1 ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5jbHVkZSA8eGVu L2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJ2aXNvci5oPgor I2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisKKyNkZWZpbmUgWEVOX1BDUFUgInhlbl9j cHU6ICIKKworLyoKKyAqIEBjcHVfaWQ6IFhlbiBwaHlzaWNhbCBjcHUgbG9naWMgbnVtYmVyCisg KiBAZmxhZ3M6IFhlbiBwaHlzaWNhbCBjcHUgc3RhdHVzIGZsYWcKKyAqIC0gWEVOX1BDUFVfRkxB R1NfT05MSU5FOiBjcHUgaXMgb25saW5lCisgKiAtIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQ6IGNw dSBpcyBub3QgcHJlc2VudAorICovCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBs aXN0OworCXN0cnVjdCBkZXZpY2UgZGV2OworCXVpbnQzMl90IGNwdV9pZDsKKwl1aW50MzJfdCBm bGFnczsKK307CisKK3N0YXRpYyBzdHJ1Y3QgYnVzX3R5cGUgeGVuX3BjcHVfc3Vic3lzID0gewor CS5uYW1lID0gInhlbl9jcHUiLAorCS5kZXZfbmFtZSA9ICJ4ZW5fY3B1IiwKK307CisKK3N0YXRp YyBERUZJTkVfTVVURVgoeGVuX3BjcHVfbG9jayk7CisKK3N0YXRpYyBMSVNUX0hFQUQoeGVuX3Bj cHVzKTsKKworc3RhdGljIGludCB4ZW5fcGNwdV9kb3duKHVpbnQzMl90IGNwdV9pZCkKK3sKKwlz dHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBYRU5QRl9jcHVfb2ZmbGlu ZSwKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51 LmNwdV9vbC5jcHVpZAkJPSBjcHVfaWQsCisJfTsKKworCXJldHVybiBIWVBFUlZJU09SX2RvbTBf b3AoJm9wKTsKK30KKworc3RhdGljIGludCB4ZW5fcGNwdV91cCh1aW50MzJfdCBjcHVfaWQpCit7 CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfY3B1X29u bGluZSwKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJ CS51LmNwdV9vbC5jcHVpZAkJPSBjcHVfaWQsCisJfTsKKworCXJldHVybiBIWVBFUlZJU09SX2Rv bTBfb3AoJm9wKTsKK30KKworc3RhdGljIHNzaXplX3Qgc2hvd19vbmxpbmUoc3RydWN0IGRldmlj ZSAqZGV2LAorCQkJICAgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkgICBjaGFy ICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBw Y3B1LCBkZXYpOworCisJcmV0dXJuIHNwcmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3Mg JiBYRU5fUENQVV9GTEFHU19PTkxJTkUpKTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3Rv cmVfb25saW5lKHN0cnVjdCBkZXZpY2UgKmRldiwKKwkJCQkgIHN0cnVjdCBkZXZpY2VfYXR0cmli dXRlICphdHRyLAorCQkJCSAgY29uc3QgY2hhciAqYnVmLCBzaXplX3QgY291bnQpCit7CisJc3Ry dWN0IHBjcHUgKnBjcHUgPSBjb250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgZGV2KTsKKwl1 bnNpZ25lZCBsb25nIGxvbmcgdmFsOworCXNzaXplX3QgcmV0OworCisJaWYgKCFjYXBhYmxlKENB UF9TWVNfQURNSU4pKQorCQlyZXR1cm4gLUVQRVJNOworCisJaWYgKGtzdHJ0b3VsbChidWYsIDAs ICZ2YWwpIDwgMCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzd2l0Y2ggKHZhbCkgeworCWNhc2Ug MDoKKwkJcmV0ID0geGVuX3BjcHVfZG93bihwY3B1LT5jcHVfaWQpOworCQlicmVhazsKKwljYXNl IDE6CisJCXJldCA9IHhlbl9wY3B1X3VwKHBjcHUtPmNwdV9pZCk7CisJCWJyZWFrOworCWRlZmF1 bHQ6CisJCXJldCA9IC1FSU5WQUw7CisJfQorCisJaWYgKHJldCA+PSAwKQorCQlyZXQgPSBjb3Vu dDsKKwlyZXR1cm4gcmV0OworfQorc3RhdGljIERFVklDRV9BVFRSKG9ubGluZSwgU19JUlVHTyB8 IFNfSVdVU1IsIHNob3dfb25saW5lLCBzdG9yZV9vbmxpbmUpOworCitzdGF0aWMgYm9vbCB4ZW5f cGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BD UFVfRkxBR1NfT05MSU5FKTsKK30KKworc3RhdGljIHZvaWQgcGNwdV9vbmxpbmVfc3RhdHVzKHN0 cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK K3sKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJgorCSAgICF4ZW5fcGNwdV9v bmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJCS8qIHRoZSBwY3B1IGlzIG9ubGluZWQgKi8KKwkJcGNw dS0+ZmxhZ3MgfD0gWEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNw dS0+ZGV2LmtvYmosIEtPQkpfT05MSU5FKTsKKwl9IGVsc2UgaWYgKCF4ZW5fcGNwdV9vbmxpbmUo aW5mby0+ZmxhZ3MpICYmCisJCSAgICB4ZW5fcGNwdV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJ CS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkICovCisJCXBjcHUtPmZsYWdzICY9IH5YRU5fUENQVV9G TEFHU19PTkxJTkU7CisJCWtvYmplY3RfdWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9PRkZM SU5FKTsKKwl9Cit9CisKK3N0YXRpYyBzdHJ1Y3QgcGNwdSAqZ2V0X3BjcHUodWludDMyX3QgY3B1 X2lkKQoreworCXN0cnVjdCBsaXN0X2hlYWQgKmN1cjsKKwlzdHJ1Y3QgcGNwdSAqcGNwdTsKKwor CWxpc3RfZm9yX2VhY2goY3VyLCAmeGVuX3BjcHVzKSB7CisJCXBjcHUgPSBsaXN0X2VudHJ5KGN1 ciwgc3RydWN0IHBjcHUsIGxpc3QpOworCQlpZiAocGNwdS0+Y3B1X2lkID09IGNwdV9pZCkKKwkJ CXJldHVybiBwY3B1OworCX0KKworCXJldHVybiBOVUxMOworfQorCitzdGF0aWMgdm9pZCBwY3B1 X3N5c19yZW1vdmUoc3RydWN0IHBjcHUgKnBjcHUpCit7CisJc3RydWN0IGRldmljZSAqZGV2Owor CisJaWYgKCFwY3B1KQorCQlyZXR1cm47CisKKwlkZXYgPSAmcGNwdS0+ZGV2OworCWlmIChkZXYt PmlkKQorCQlkZXZpY2VfcmVtb3ZlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfb25saW5lKTsKKworCWRl dmljZV91bnJlZ2lzdGVyKGRldik7Cit9CisKK3N0YXRpYyB2b2lkIGZyZWVfcGNwdShzdHJ1Y3Qg cGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCXBjcHVfc3lzX3JlbW92 ZShwY3B1KTsKKworCWxpc3RfZGVsKCZwY3B1LT5saXN0KTsKKwlrZnJlZShwY3B1KTsKK30KKwor c3RhdGljIGludCBwY3B1X3N5c19jcmVhdGUoc3RydWN0IHBjcHUgKnBjcHUpCit7CisJc3RydWN0 IGRldmljZSAqZGV2OworCWludCBlcnIgPSAtRUlOVkFMOworCisJaWYgKCFwY3B1KQorCQlyZXR1 cm4gZXJyOworCisJZGV2ID0gJnBjcHUtPmRldjsKKwlkZXYtPmJ1cyA9ICZ4ZW5fcGNwdV9zdWJz eXM7CisJZGV2LT5pZCA9IHBjcHUtPmNwdV9pZDsKKworCWVyciA9IGRldmljZV9yZWdpc3Rlcihk ZXYpOworCWlmIChlcnIpCisJCXJldHVybiBlcnI7CisKKwkvKgorCSAqIFhlbiBuZXZlciBvZmZs aW5lIGNwdTAgZHVlIHRvIHNldmVyYWwgcmVzdHJpY3Rpb25zCisJICogYW5kIGFzc3VtcHRpb25z LiBUaGlzIGJhc2ljYWxseSBkb2Vzbid0IGFkZCBhIHN5cyBjb250cm9sCisJICogdG8gdXNlciwg b25lIGNhbm5vdCBhdHRlbXB0IHRvIG9mZmxpbmUgQlNQLgorCSAqLworCWlmIChkZXYtPmlkKSB7 CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZkZXZfYXR0cl9vbmxpbmUpOworCQlp ZiAoZXJyKSB7CisJCQlkZXZpY2VfdW5yZWdpc3RlcihkZXYpOworCQkJcmV0dXJuIGVycjsKKwkJ fQorCX0KKworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShz dHJ1Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50 IGVycjsKKworCWlmIChpbmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJl dHVybiBFUlJfUFRSKC1FTk9ERVYpOworCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBw Y3B1KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVN KTsKKworCUlOSVRfTElTVF9IRUFEKCZwY3B1LT5saXN0KTsKKwlwY3B1LT5jcHVfaWQgPSBpbmZv LT54ZW5fY3B1aWQ7CisJcGNwdS0+ZmxhZ3MgPSBpbmZvLT5mbGFnczsKKworCWVyciA9IHBjcHVf c3lzX2NyZWF0ZShwY3B1KTsKKwlpZiAoZXJyKSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh aWxlZCB0byByZWdpc3RlciBwY3B1JXVcbiIsCisJCQkgICBpbmZvLT54ZW5fY3B1aWQpOworCQlr ZnJlZShwY3B1KTsKKwkJcmV0dXJuIEVSUl9QVFIoLUVOT0VOVCk7CisJfQorCisJLyogTmVlZCBo b2xkIG9uIHhlbl9wY3B1X2xvY2sgYmVmb3JlIHBjcHUgbGlzdCBtYW5pcHVsYXRpb25zICovCisJ bGlzdF9hZGRfdGFpbCgmcGNwdS0+bGlzdCwgJnhlbl9wY3B1cyk7CisJcmV0dXJuIHBjcHU7Cit9 CisKKy8qCisgKiBDYWxsZXIgc2hvdWxkIGhvbGQgdGhlIHhlbl9wY3B1X2xvY2sKKyAqLworc3Rh dGljIGludCBzeW5jX3BjcHUodWludDMyX3QgY3B1LCB1aW50MzJfdCAqbWF4X2NwdSkKK3sKKwlp bnQgcmV0OworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKwlzdHJ1Y3QgeGVucGZfcGNwdWlu Zm8gKmluZm87CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCAgICAgICAg ICAgICAgICAgICA9IFhFTlBGX2dldF9jcHVpbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gICAg ID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51LnBjcHVfaW5mby54ZW5fY3B1aWQgPSBj cHUsCisJfTsKKworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlmIChyZXQpCisJ CXJldHVybiByZXQ7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWlmIChtYXhfY3B1KQor CQkqbWF4X2NwdSA9IGluZm8tPm1heF9wcmVzZW50OworCisJcGNwdSA9IGdldF9wY3B1KGNwdSk7 CisKKwlpZiAoaW5mby0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19JTlZBTElEKSB7CisJCS8qIFRo ZSBwY3B1IGhhcyBiZWVuIHJlbW92ZWQgKi8KKwkJaWYgKHBjcHUpCisJCQlmcmVlX3BjcHUocGNw dSk7CisJCXJldHVybiAwOworCX0KKworCWlmICghcGNwdSkgeworCQlwY3B1ID0gaW5pdF9wY3B1 KGluZm8pOworCQlpZiAoSVNfRVJSX09SX05VTEwocGNwdSkpCisJCQlyZXR1cm4gLUVOT0RFVjsK Kwl9IGVsc2UKKwkJcGNwdV9vbmxpbmVfc3RhdHVzKGluZm8sIHBjcHUpOworCisJcmV0dXJuIDA7 Cit9CisKKy8qCisgKiBTeW5jIGRvbTAncyBwY3B1IGluZm9ybWF0aW9uIHdpdGggeGVuIGh5cGVy dmlzb3IncworICovCitzdGF0aWMgaW50IHhlbl9zeW5jX3BjcHVzKHZvaWQpCit7CisJLyoKKwkg KiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQgMCBpbiB4ZW4KKwkgKi8KKwl1aW50MzJfdCBj cHUgPSAwLCBtYXhfY3B1ID0gMDsKKwlpbnQgZXJyID0gMDsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpj dXIsICp0bXA7CisJc3RydWN0IHBjcHUgKnBjcHU7CisKKwltdXRleF9sb2NrKCZ4ZW5fcGNwdV9s b2NrKTsKKworCXdoaWxlICghZXJyICYmIChjcHUgPD0gbWF4X2NwdSkpIHsKKwkJZXJyID0gc3lu Y19wY3B1KGNwdSwgJm1heF9jcHUpOworCQljcHUrKzsKKwl9CisKKwlpZiAoZXJyKSB7CisJCWxp c3RfZm9yX2VhY2hfc2FmZShjdXIsIHRtcCwgJnhlbl9wY3B1cykgeworCQkJcGNwdSA9IGxpc3Rf ZW50cnkoY3VyLCBzdHJ1Y3QgcGNwdSwgbGlzdCk7CisJCQlmcmVlX3BjcHUocGNwdSk7CisJCX0K Kwl9CisKKwltdXRleF91bmxvY2soJnhlbl9wY3B1X2xvY2spOworCisJcmV0dXJuIGVycjsKK30K Kworc3RhdGljIHZvaWQgeGVuX3BjcHVfd29ya19mbihzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmsp Cit7CisJeGVuX3N5bmNfcGNwdXMoKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVf d29yaywgeGVuX3BjcHVfd29ya19mbik7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNwdV9p bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhlbl9w Y3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2luaXQg eGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBpcnEsIHJldDsKKworCWlmICgheGVuX2luaXRp YWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVWOworCisJaXJxID0gYmluZF92aXJxX3RvX2ly cWhhbmRsZXIoVklSUV9QQ1BVX1NUQVRFLCAwLAorCQkJCSAgICAgIHhlbl9wY3B1X2ludGVycnVw dCwgMCwKKwkJCQkgICAgICAieGVuLXBjcHUiLCBOVUxMKTsKKwlpZiAoaXJxIDwgMCkgeworCQlw cl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQgdG8gYmluZCBwY3B1IHZpcnFcbiIpOworCQlyZXR1 cm4gaXJxOworCX0KKworCXJldCA9IHN1YnN5c19zeXN0ZW1fcmVnaXN0ZXIoJnhlbl9wY3B1X3N1 YnN5cywgTlVMTCk7CisJaWYgKHJldCkgeworCQlwcl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQg dG8gcmVnaXN0ZXIgcGNwdSBzdWJzeXNcbiIpOworCQlnb3RvIGVycjE7CisJfQorCisJcmV0ID0g eGVuX3N5bmNfcGNwdXMoKTsKKwlpZiAocmV0KSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh aWxlZCB0byBzeW5jIHBjcHUgaW5mb1xuIik7CisJCWdvdG8gZXJyMjsKKwl9CisKKwlyZXR1cm4g MDsKKworZXJyMjoKKwlidXNfdW5yZWdpc3RlcigmeGVuX3BjcHVfc3Vic3lzKTsKK2VycjE6CisJ dW5iaW5kX2Zyb21faXJxaGFuZGxlcihpcnEsIE5VTEwpOworCXJldHVybiByZXQ7Cit9CithcmNo X2luaXRjYWxsKHhlbl9wY3B1X2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJm YWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaAppbmRleCA0 ODY2NTNmLi42MWZhNjYxIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv cm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApAQCAtMzE0LDYgKzMx NCwxMyBAQCBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogfTsKIERFRklORV9HVUVTVF9IQU5ETEVf U1RSVUNUKHhlbnBmX3BjcHVpbmZvKTsKIAorI2RlZmluZSBYRU5QRl9jcHVfb25saW5lCTU2Cisj ZGVmaW5lIFhFTlBGX2NwdV9vZmZsaW5lCTU3CitzdHJ1Y3QgeGVucGZfY3B1X29sIHsKKwl1aW50 MzJfdCBjcHVpZDsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5wZl9jcHVfb2wp OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zMzAs NiArMzM3LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9nZXRp ZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3Jf cG1pbmZvIHNldF9wbWluZm87CiAJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1 X2luZm87CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4 X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwpkaWZmIC0tZ2l0 IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl bi5oCmluZGV4IGE4OTA4MDQuLjA4MDE0NjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVy ZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKQEAgLTgwLDYgKzgw LDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8qIChET00wKSBCeXRlcyByZWNlaXZl ZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUgVklSUV9ET01fRVhDICAgIDMgIC8q IChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBkb21haW4uICAgKi8KICNkZWZpbmUg VklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFpbiBoYXMgcGF1c2VkIGZvciBkZWJ1 Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRFIDkgIC8qIChET00wKSBQQ1BVIHN0 YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAogLyogQXJjaGl0ZWN0dXJlLXNwZWNp ZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJUlFfQVJDSF8wICAgIDE2Ci0tIAox LjcuMQoK --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Thu May 10 15:07:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSUxj-0000ic-AD; Thu, 10 May 2012 15:07:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUxh-0000i1-RQ for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:07:26 +0000 Received: from [85.158.143.35:26535] by server-1.bemta-4.messagelabs.com id 36/C6-20925-DA9DBAF4; Thu, 10 May 2012 15:07:25 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336662442!15490098!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2801 invoked from network); 10 May 2012 15:07:22 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-7.tower-21.messagelabs.com with SMTP; 10 May 2012 15:07:22 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 08:07:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,223";a="141431584" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 10 May 2012 08:06:17 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 08:06:16 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Thu, 10 May 2012 23:06:14 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: Ac0uvnBnJV8RtIigTTax7Uicx2M6Kw== Date: Thu, 10 May 2012 15:06:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/mixed; boundary="_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_" MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong Date: Fri, 11 May 2012 06:55:35 +0800 Subject: [PATCH 3/3] Xen physical cpus interface Manage physical cpus in dom0, get physical cpus info and provide sys interf= ace. Signed-off-by: Liu, Jinsong Signed-off-by: Jiang, Yunhong --- .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + drivers/xen/Makefile | 1 + drivers/xen/pcpu.c | 374 ++++++++++++++++= ++++ include/xen/interface/platform.h | 8 + include/xen/interface/xen.h | 1 + 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu create mode 100644 drivers/xen/pcpu.c diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Docum= entation/ABI/testing/sysfs-devices-system-xen_cpu new file mode 100644 index 0000000..9ca02fb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu @@ -0,0 +1,20 @@ +What: /sys/devices/system/xen_cpu/ +Date: May 2012 +Contact: Liu, Jinsong +Description: + A collection of global/individual Xen physical cpu attributes + + Individual physical cpu attributes are contained in + subdirectories named by the Xen's logical cpu number, e.g.: + /sys/devices/system/xen_cpu/xen_cpu#/ + + +What: /sys/devices/system/xen_cpu/xen_cpu#/online +Date: May 2012 +Contact: Liu, Jinsong +Description: + Interface to online/offline Xen physical cpus + + When running under Xen platform, it provide user interface + to online/offline physical cpus, except cpu0 due to several + logic restrictions and assumptions. diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 1d3e763..d12d14d 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_XEN_PVHVM) +=3D platform-pci.o obj-$(CONFIG_XEN_TMEM) +=3D tmem.o obj-$(CONFIG_SWIOTLB_XEN) +=3D swiotlb-xen.o obj-$(CONFIG_XEN_DOM0) +=3D pci.o +obj-$(CONFIG_XEN_DOM0) +=3D pcpu.o obj-$(CONFIG_XEN_PCIDEV_BACKEND) +=3D xen-pciback/ obj-$(CONFIG_XEN_PRIVCMD) +=3D xen-privcmd.o obj-$(CONFIG_XEN_ACPI_PROCESSOR) +=3D xen-acpi-processor.o diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c new file mode 100644 index 0000000..9014ff1 --- /dev/null +++ b/drivers/xen/pcpu.c @@ -0,0 +1,374 @@ +/*************************************************************************= ***** + * pcpu.c + * Management physical cpu in dom0, get pcpu info and provide sys interfac= e + * + * Copyright (c) 2012 Intel Corporation + * Author: Liu, Jinsong + * Author: Jiang, Yunhong + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a= copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modi= fy, + * merge, publish, distribute, sublicense, and/or sell copies of the Softw= are, + * and to permit persons to whom the Software is furnished to do so, subje= ct to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included= in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS= OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY= , + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL= THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA= LINGS + * IN THE SOFTWARE. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define XEN_PCPU "xen_cpu: " + +/* + * @cpu_id: Xen physical cpu logic number + * @flags: Xen physical cpu status flag + * - XEN_PCPU_FLAGS_ONLINE: cpu is online + * - XEN_PCPU_FLAGS_INVALID: cpu is not present + */ +struct pcpu { + struct list_head list; + struct device dev; + uint32_t cpu_id; + uint32_t flags; +}; + +static struct bus_type xen_pcpu_subsys =3D { + .name =3D "xen_cpu", + .dev_name =3D "xen_cpu", +}; + +static DEFINE_MUTEX(xen_pcpu_lock); + +static LIST_HEAD(xen_pcpus); + +static int xen_pcpu_down(uint32_t cpu_id) +{ + struct xen_platform_op op =3D { + .cmd =3D XENPF_cpu_offline, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.cpu_ol.cpuid =3D cpu_id, + }; + + return HYPERVISOR_dom0_op(&op); +} + +static int xen_pcpu_up(uint32_t cpu_id) +{ + struct xen_platform_op op =3D { + .cmd =3D XENPF_cpu_online, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.cpu_ol.cpuid =3D cpu_id, + }; + + return HYPERVISOR_dom0_op(&op); +} + +static ssize_t show_online(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct pcpu *cpu =3D container_of(dev, struct pcpu, dev); + + return sprintf(buf, "%u\n", !!(cpu->flags & XEN_PCPU_FLAGS_ONLINE)); +} + +static ssize_t __ref store_online(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct pcpu *pcpu =3D container_of(dev, struct pcpu, dev); + unsigned long long val; + ssize_t ret; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + if (kstrtoull(buf, 0, &val) < 0) + return -EINVAL; + + switch (val) { + case 0: + ret =3D xen_pcpu_down(pcpu->cpu_id); + break; + case 1: + ret =3D xen_pcpu_up(pcpu->cpu_id); + break; + default: + ret =3D -EINVAL; + } + + if (ret >=3D 0) + ret =3D count; + return ret; +} +static DEVICE_ATTR(online, S_IRUGO | S_IWUSR, show_online, store_online); + +static bool xen_pcpu_online(uint32_t flags) +{ + return !!(flags & XEN_PCPU_FLAGS_ONLINE); +} + +static void pcpu_online_status(struct xenpf_pcpuinfo *info, + struct pcpu *pcpu) +{ + if (xen_pcpu_online(info->flags) && + !xen_pcpu_online(pcpu->flags)) { + /* the pcpu is onlined */ + pcpu->flags |=3D XEN_PCPU_FLAGS_ONLINE; + kobject_uevent(&pcpu->dev.kobj, KOBJ_ONLINE); + } else if (!xen_pcpu_online(info->flags) && + xen_pcpu_online(pcpu->flags)) { + /* The pcpu is offlined */ + pcpu->flags &=3D ~XEN_PCPU_FLAGS_ONLINE; + kobject_uevent(&pcpu->dev.kobj, KOBJ_OFFLINE); + } +} + +static struct pcpu *get_pcpu(uint32_t cpu_id) +{ + struct list_head *cur; + struct pcpu *pcpu; + + list_for_each(cur, &xen_pcpus) { + pcpu =3D list_entry(cur, struct pcpu, list); + if (pcpu->cpu_id =3D=3D cpu_id) + return pcpu; + } + + return NULL; +} + +static void pcpu_sys_remove(struct pcpu *pcpu) +{ + struct device *dev; + + if (!pcpu) + return; + + dev =3D &pcpu->dev; + if (dev->id) + device_remove_file(dev, &dev_attr_online); + + device_unregister(dev); +} + +static void free_pcpu(struct pcpu *pcpu) +{ + if (!pcpu) + return; + + pcpu_sys_remove(pcpu); + + list_del(&pcpu->list); + kfree(pcpu); +} + +static int pcpu_sys_create(struct pcpu *pcpu) +{ + struct device *dev; + int err =3D -EINVAL; + + if (!pcpu) + return err; + + dev =3D &pcpu->dev; + dev->bus =3D &xen_pcpu_subsys; + dev->id =3D pcpu->cpu_id; + + err =3D device_register(dev); + if (err) + return err; + + /* + * Xen never offline cpu0 due to several restrictions + * and assumptions. This basically doesn't add a sys control + * to user, one cannot attempt to offline BSP. + */ + if (dev->id) { + err =3D device_create_file(dev, &dev_attr_online); + if (err) { + device_unregister(dev); + return err; + } + } + + return 0; +} + +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) +{ + struct pcpu *pcpu; + int err; + + if (info->flags & XEN_PCPU_FLAGS_INVALID) + return ERR_PTR(-ENODEV); + + pcpu =3D kzalloc(sizeof(struct pcpu), GFP_KERNEL); + if (!pcpu) + return ERR_PTR(-ENOMEM); + + INIT_LIST_HEAD(&pcpu->list); + pcpu->cpu_id =3D info->xen_cpuid; + pcpu->flags =3D info->flags; + + err =3D pcpu_sys_create(pcpu); + if (err) { + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", + info->xen_cpuid); + kfree(pcpu); + return ERR_PTR(-ENOENT); + } + + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ + list_add_tail(&pcpu->list, &xen_pcpus); + return pcpu; +} + +/* + * Caller should hold the xen_pcpu_lock + */ +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) +{ + int ret; + struct pcpu *pcpu =3D NULL; + struct xenpf_pcpuinfo *info; + struct xen_platform_op op =3D { + .cmd =3D XENPF_get_cpuinfo, + .interface_version =3D XENPF_INTERFACE_VERSION, + .u.pcpu_info.xen_cpuid =3D cpu, + }; + + ret =3D HYPERVISOR_dom0_op(&op); + if (ret) + return ret; + + info =3D &op.u.pcpu_info; + if (max_cpu) + *max_cpu =3D info->max_present; + + pcpu =3D get_pcpu(cpu); + + if (info->flags & XEN_PCPU_FLAGS_INVALID) { + /* The pcpu has been removed */ + if (pcpu) + free_pcpu(pcpu); + return 0; + } + + if (!pcpu) { + pcpu =3D init_pcpu(info); + if (IS_ERR_OR_NULL(pcpu)) + return -ENODEV; + } else + pcpu_online_status(info, pcpu); + + return 0; +} + +/* + * Sync dom0's pcpu information with xen hypervisor's + */ +static int xen_sync_pcpus(void) +{ + /* + * Boot cpu always have cpu_id 0 in xen + */ + uint32_t cpu =3D 0, max_cpu =3D 0; + int err =3D 0; + struct list_head *cur, *tmp; + struct pcpu *pcpu; + + mutex_lock(&xen_pcpu_lock); + + while (!err && (cpu <=3D max_cpu)) { + err =3D sync_pcpu(cpu, &max_cpu); + cpu++; + } + + if (err) { + list_for_each_safe(cur, tmp, &xen_pcpus) { + pcpu =3D list_entry(cur, struct pcpu, list); + free_pcpu(pcpu); + } + } + + mutex_unlock(&xen_pcpu_lock); + + return err; +} + +static void xen_pcpu_work_fn(struct work_struct *work) +{ + xen_sync_pcpus(); +} +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); + +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) +{ + schedule_work(&xen_pcpu_work); + return IRQ_HANDLED; +} + +static int __init xen_pcpu_init(void) +{ + int irq, ret; + + if (!xen_initial_domain()) + return -ENODEV; + + irq =3D bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, + xen_pcpu_interrupt, 0, + "xen-pcpu", NULL); + if (irq < 0) { + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); + return irq; + } + + ret =3D subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); + goto err1; + } + + ret =3D xen_sync_pcpus(); + if (ret) { + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + goto err2; + } + + return 0; + +err2: + bus_unregister(&xen_pcpu_subsys); +err1: + unbind_from_irqhandler(irq, NULL); + return ret; +} +arch_initcall(xen_pcpu_init); diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf= orm.h index 486653f..61fa661 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo { }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); =20 +#define XENPF_cpu_online 56 +#define XENPF_cpu_offline 57 +struct xenpf_cpu_ol { + uint32_t cpuid; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); + struct xen_platform_op { uint32_t cmd; uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ @@ -330,6 +337,7 @@ struct xen_platform_op { struct xenpf_getidletime getidletime; struct xenpf_set_processor_pminfo set_pminfo; struct xenpf_pcpuinfo pcpu_info; + struct xenpf_cpu_ol cpu_ol; uint8_t pad[128]; } u; }; diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index a890804..0801468 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -80,6 +80,7 @@ #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency console. = */ #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event for some domain. = */ #define VIRQ_DEBUGGER 6 /* (DOM0) A domain has paused for debugging. = */ +#define VIRQ_PCPU_STATE 9 /* (DOM0) PCPU state changed = */ =20 /* Architecture-specific VIRQ definitions. */ #define VIRQ_ARCH_0 16 --=20 1.7.1 --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: application/octet-stream; name="0003-Xen-physical-cpus-interface.patch" Content-Description: 0003-Xen-physical-cpus-interface.patch Content-Disposition: attachment; filename="0003-Xen-physical-cpus-interface.patch"; size=12603; creation-date="Thu, 10 May 2012 15:03:13 GMT"; modification-date="Thu, 10 May 2012 22:58:00 GMT" Content-Transfer-Encoding: base64 RnJvbSA3YWE0Y2Y3YzExNzJlMjQ2MTFkYzc2MTYzMzk3Yjg3MDhhY2FjYzU5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K RGF0ZTogRnJpLCAxMSBNYXkgMjAxMiAwNjo1NTozNSArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy8z XSBYZW4gcGh5c2ljYWwgY3B1cyBpbnRlcmZhY2UKCk1hbmFnZSBwaHlzaWNhbCBjcHVzIGluIGRv bTAsIGdldCBwaHlzaWNhbCBjcHVzIGluZm8gYW5kIHByb3ZpZGUgc3lzIGludGVyZmFjZS4KClNp Z25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTaWduZWQt b2ZmLWJ5OiBKaWFuZywgWXVuaG9uZyA8eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+Ci0tLQogLi4u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUgICAgICAgfCAgIDIwICsK IGRyaXZlcnMveGVuL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg MSArCiBkcml2ZXJzL3hlbi9wY3B1LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAzNzQgKysrKysrKysrKysrKysrKysrKysKIGluY2x1ZGUveGVuL2ludGVyZmFjZS9wbGF0Zm9y bS5oICAgICAgICAgICAgICAgICAgIHwgICAgOCArCiBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVu LmggICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDEgKwogNSBmaWxlcyBjaGFuZ2VkLCA0MDQg aW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBEb2N1bWVu dGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUKIGNyZWF0ZSBt b2RlIDEwMDY0NCBkcml2ZXJzL3hlbi9wY3B1LmMKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUgYi9Eb2N1bWVudGF0aW9u L0FCSS90ZXN0aW5nL3N5c2ZzLWRldmljZXMtc3lzdGVtLXhlbl9jcHUKbmV3IGZpbGUgbW9kZSAx MDA2NDQKaW5kZXggMDAwMDAwMC4uOWNhMDJmYgotLS0gL2Rldi9udWxsCisrKyBiL0RvY3VtZW50 YXRpb24vQUJJL3Rlc3Rpbmcvc3lzZnMtZGV2aWNlcy1zeXN0ZW0teGVuX2NwdQpAQCAtMCwwICsx LDIwIEBACitXaGF0OgkJL3N5cy9kZXZpY2VzL3N5c3RlbS94ZW5fY3B1LworRGF0ZToJCU1heSAy MDEyCitDb250YWN0OglMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KK0Rlc2Ny aXB0aW9uOgorCQlBIGNvbGxlY3Rpb24gb2YgZ2xvYmFsL2luZGl2aWR1YWwgWGVuIHBoeXNpY2Fs IGNwdSBhdHRyaWJ1dGVzCisKKwkJSW5kaXZpZHVhbCBwaHlzaWNhbCBjcHUgYXR0cmlidXRlcyBh cmUgY29udGFpbmVkIGluCisJCXN1YmRpcmVjdG9yaWVzIG5hbWVkIGJ5IHRoZSBYZW4ncyBsb2dp Y2FsIGNwdSBudW1iZXIsIGUuZy46CisJCS9zeXMvZGV2aWNlcy9zeXN0ZW0veGVuX2NwdS94ZW5f Y3B1Iy8KKworCitXaGF0OgkJL3N5cy9kZXZpY2VzL3N5c3RlbS94ZW5fY3B1L3hlbl9jcHUjL29u bGluZQorRGF0ZToJCU1heSAyMDEyCitDb250YWN0OglMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1 QGludGVsLmNvbT4KK0Rlc2NyaXB0aW9uOgorCQlJbnRlcmZhY2UgdG8gb25saW5lL29mZmxpbmUg WGVuIHBoeXNpY2FsIGNwdXMKKworCQlXaGVuIHJ1bm5pbmcgdW5kZXIgWGVuIHBsYXRmb3JtLCBp dCBwcm92aWRlIHVzZXIgaW50ZXJmYWNlCisJCXRvIG9ubGluZS9vZmZsaW5lIHBoeXNpY2FsIGNw dXMsIGV4Y2VwdCBjcHUwIGR1ZSB0byBzZXZlcmFsCisJCWxvZ2ljIHJlc3RyaWN0aW9ucyBhbmQg YXNzdW1wdGlvbnMuCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMv eGVuL01ha2VmaWxlCmluZGV4IDFkM2U3NjMuLmQxMmQxNGQgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMv eGVuL01ha2VmaWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0xOSw2ICsxOSw3IEBA IG9iai0kKENPTkZJR19YRU5fUFZIVk0pCQkJKz0gcGxhdGZvcm0tcGNpLm8KIG9iai0kKENPTkZJ R19YRU5fVE1FTSkJCQkrPSB0bWVtLm8KIG9iai0kKENPTkZJR19TV0lPVExCX1hFTikJCSs9IHN3 aW90bGIteGVuLm8KIG9iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSBwY2kubworb2JqLSQoQ09O RklHX1hFTl9ET00wKQkJCSs9IHBjcHUubwogb2JqLSQoQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO RCkJKz0geGVuLXBjaWJhY2svCiBvYmotJChDT05GSUdfWEVOX1BSSVZDTUQpCQkrPSB4ZW4tcHJp dmNtZC5vCiBvYmotJChDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SKQkrPSB4ZW4tYWNwaS1wcm9j ZXNzb3IubwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4vcGNwdS5jIGIvZHJpdmVycy94ZW4vcGNw dS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjkwMTRmZjEKLS0tIC9kZXYv bnVsbAorKysgYi9kcml2ZXJzL3hlbi9wY3B1LmMKQEAgLTAsMCArMSwzNzQgQEAKKy8qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioKKyAqIHBjcHUuYworICogTWFuYWdlbWVudCBwaHlzaWNhbCBjcHUgaW4g ZG9tMCwgZ2V0IHBjcHUgaW5mbyBhbmQgcHJvdmlkZSBzeXMgaW50ZXJmYWNlCisgKgorICogQ29w eXJpZ2h0IChjKSAyMDEyIEludGVsIENvcnBvcmF0aW9uCisgKiBBdXRob3I6IExpdSwgSmluc29u ZyA8amluc29uZy5saXVAaW50ZWwuY29tPgorICogQXV0aG9yOiBKaWFuZywgWXVuaG9uZyA8eXVu aG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICogbW9kaWZ5IGl0IHVuZGVyIHRo ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyCisgKiBh cyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgb3IsIHdoZW4gZGlz dHJpYnV0ZWQKKyAqIHNlcGFyYXRlbHkgZnJvbSB0aGUgTGludXgga2VybmVsIG9yIGluY29ycG9y YXRlZCBpbnRvIG90aGVyCisgKiBzb2Z0d2FyZSBwYWNrYWdlcywgc3ViamVjdCB0byB0aGUgZm9s bG93aW5nIGxpY2Vuc2U6CisgKgorICogUGVybWlzc2lvbiBpcyBoZXJlYnkgZ3JhbnRlZCwgZnJl ZSBvZiBjaGFyZ2UsIHRvIGFueSBwZXJzb24gb2J0YWluaW5nIGEgY29weQorICogb2YgdGhpcyBz b3VyY2UgZmlsZSAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRoZSBTb2Z0d2FyZSB3aXRo b3V0CisgKiByZXN0cmljdGlvbiwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiB0aGUgcmln aHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LAorICogbWVyZ2UsIHB1Ymxpc2gsIGRpc3RyaWJ1dGUs IHN1YmxpY2Vuc2UsIGFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUsCisgKiBhbmQg dG8gcGVybWl0IHBlcnNvbnMgdG8gd2hvbSB0aGUgU29mdHdhcmUgaXMgZnVybmlzaGVkIHRvIGRv IHNvLCBzdWJqZWN0IHRvCisgKiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6CisgKgorICogVGhl IGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwg YmUgaW5jbHVkZWQgaW4KKyAqIGFsbCBjb3BpZXMgb3Igc3Vic3RhbnRpYWwgcG9ydGlvbnMgb2Yg dGhlIFNvZnR3YXJlLgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBX SVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBSRVNTIE9SCisgKiBJTVBMSUVELCBJTkNM VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSwKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZSSU5HRU1F TlQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRQorICogQVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVS UyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUiBPVEhFUgorICogTElBQklMSVRZ LCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJU0UsIEFS SVNJTkcKKyAqIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNPRlRXQVJF IE9SIFRIRSBVU0UgT1IgT1RIRVIgREVBTElOR1MKKyAqIElOIFRIRSBTT0ZUV0FSRS4KKyAqLwor CisjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2su aD4KKyNpbmNsdWRlIDxsaW51eC9jcHUuaD4KKyNpbmNsdWRlIDxsaW51eC9zdGF0Lmg+CisjaW5j bHVkZSA8bGludXgvY2FwYWJpbGl0eS5oPgorCisjaW5jbHVkZSA8eGVuL3hlbi5oPgorI2luY2x1 ZGUgPHhlbi94ZW5idXMuaD4KKyNpbmNsdWRlIDx4ZW4vZXZlbnRzLmg+CisjaW5jbHVkZSA8eGVu L2ludGVyZmFjZS9wbGF0Zm9ybS5oPgorI2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJ2aXNvci5oPgor I2luY2x1ZGUgPGFzbS94ZW4vaHlwZXJjYWxsLmg+CisKKyNkZWZpbmUgWEVOX1BDUFUgInhlbl9j cHU6ICIKKworLyoKKyAqIEBjcHVfaWQ6IFhlbiBwaHlzaWNhbCBjcHUgbG9naWMgbnVtYmVyCisg KiBAZmxhZ3M6IFhlbiBwaHlzaWNhbCBjcHUgc3RhdHVzIGZsYWcKKyAqIC0gWEVOX1BDUFVfRkxB R1NfT05MSU5FOiBjcHUgaXMgb25saW5lCisgKiAtIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQ6IGNw dSBpcyBub3QgcHJlc2VudAorICovCitzdHJ1Y3QgcGNwdSB7CisJc3RydWN0IGxpc3RfaGVhZCBs aXN0OworCXN0cnVjdCBkZXZpY2UgZGV2OworCXVpbnQzMl90IGNwdV9pZDsKKwl1aW50MzJfdCBm bGFnczsKK307CisKK3N0YXRpYyBzdHJ1Y3QgYnVzX3R5cGUgeGVuX3BjcHVfc3Vic3lzID0gewor CS5uYW1lID0gInhlbl9jcHUiLAorCS5kZXZfbmFtZSA9ICJ4ZW5fY3B1IiwKK307CisKK3N0YXRp YyBERUZJTkVfTVVURVgoeGVuX3BjcHVfbG9jayk7CisKK3N0YXRpYyBMSVNUX0hFQUQoeGVuX3Bj cHVzKTsKKworc3RhdGljIGludCB4ZW5fcGNwdV9kb3duKHVpbnQzMl90IGNwdV9pZCkKK3sKKwlz dHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kCQkJPSBYRU5QRl9jcHVfb2ZmbGlu ZSwKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51 LmNwdV9vbC5jcHVpZAkJPSBjcHVfaWQsCisJfTsKKworCXJldHVybiBIWVBFUlZJU09SX2RvbTBf b3AoJm9wKTsKK30KKworc3RhdGljIGludCB4ZW5fcGNwdV91cCh1aW50MzJfdCBjcHVfaWQpCit7 CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZAkJCT0gWEVOUEZfY3B1X29u bGluZSwKKwkJLmludGVyZmFjZV92ZXJzaW9uCT0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJ CS51LmNwdV9vbC5jcHVpZAkJPSBjcHVfaWQsCisJfTsKKworCXJldHVybiBIWVBFUlZJU09SX2Rv bTBfb3AoJm9wKTsKK30KKworc3RhdGljIHNzaXplX3Qgc2hvd19vbmxpbmUoc3RydWN0IGRldmlj ZSAqZGV2LAorCQkJICAgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQkgICBjaGFy ICpidWYpCit7CisJc3RydWN0IHBjcHUgKmNwdSA9IGNvbnRhaW5lcl9vZihkZXYsIHN0cnVjdCBw Y3B1LCBkZXYpOworCisJcmV0dXJuIHNwcmludGYoYnVmLCAiJXVcbiIsICEhKGNwdS0+ZmxhZ3Mg JiBYRU5fUENQVV9GTEFHU19PTkxJTkUpKTsKK30KKworc3RhdGljIHNzaXplX3QgX19yZWYgc3Rv cmVfb25saW5lKHN0cnVjdCBkZXZpY2UgKmRldiwKKwkJCQkgIHN0cnVjdCBkZXZpY2VfYXR0cmli dXRlICphdHRyLAorCQkJCSAgY29uc3QgY2hhciAqYnVmLCBzaXplX3QgY291bnQpCit7CisJc3Ry dWN0IHBjcHUgKnBjcHUgPSBjb250YWluZXJfb2YoZGV2LCBzdHJ1Y3QgcGNwdSwgZGV2KTsKKwl1 bnNpZ25lZCBsb25nIGxvbmcgdmFsOworCXNzaXplX3QgcmV0OworCisJaWYgKCFjYXBhYmxlKENB UF9TWVNfQURNSU4pKQorCQlyZXR1cm4gLUVQRVJNOworCisJaWYgKGtzdHJ0b3VsbChidWYsIDAs ICZ2YWwpIDwgMCkKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlzd2l0Y2ggKHZhbCkgeworCWNhc2Ug MDoKKwkJcmV0ID0geGVuX3BjcHVfZG93bihwY3B1LT5jcHVfaWQpOworCQlicmVhazsKKwljYXNl IDE6CisJCXJldCA9IHhlbl9wY3B1X3VwKHBjcHUtPmNwdV9pZCk7CisJCWJyZWFrOworCWRlZmF1 bHQ6CisJCXJldCA9IC1FSU5WQUw7CisJfQorCisJaWYgKHJldCA+PSAwKQorCQlyZXQgPSBjb3Vu dDsKKwlyZXR1cm4gcmV0OworfQorc3RhdGljIERFVklDRV9BVFRSKG9ubGluZSwgU19JUlVHTyB8 IFNfSVdVU1IsIHNob3dfb25saW5lLCBzdG9yZV9vbmxpbmUpOworCitzdGF0aWMgYm9vbCB4ZW5f cGNwdV9vbmxpbmUodWludDMyX3QgZmxhZ3MpCit7CisJcmV0dXJuICEhKGZsYWdzICYgWEVOX1BD UFVfRkxBR1NfT05MSU5FKTsKK30KKworc3RhdGljIHZvaWQgcGNwdV9vbmxpbmVfc3RhdHVzKHN0 cnVjdCB4ZW5wZl9wY3B1aW5mbyAqaW5mbywKKwkJCSAgICAgICBzdHJ1Y3QgcGNwdSAqcGNwdSkK K3sKKwlpZiAoeGVuX3BjcHVfb25saW5lKGluZm8tPmZsYWdzKSAmJgorCSAgICF4ZW5fcGNwdV9v bmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJCS8qIHRoZSBwY3B1IGlzIG9ubGluZWQgKi8KKwkJcGNw dS0+ZmxhZ3MgfD0gWEVOX1BDUFVfRkxBR1NfT05MSU5FOworCQlrb2JqZWN0X3VldmVudCgmcGNw dS0+ZGV2LmtvYmosIEtPQkpfT05MSU5FKTsKKwl9IGVsc2UgaWYgKCF4ZW5fcGNwdV9vbmxpbmUo aW5mby0+ZmxhZ3MpICYmCisJCSAgICB4ZW5fcGNwdV9vbmxpbmUocGNwdS0+ZmxhZ3MpKSB7CisJ CS8qIFRoZSBwY3B1IGlzIG9mZmxpbmVkICovCisJCXBjcHUtPmZsYWdzICY9IH5YRU5fUENQVV9G TEFHU19PTkxJTkU7CisJCWtvYmplY3RfdWV2ZW50KCZwY3B1LT5kZXYua29iaiwgS09CSl9PRkZM SU5FKTsKKwl9Cit9CisKK3N0YXRpYyBzdHJ1Y3QgcGNwdSAqZ2V0X3BjcHUodWludDMyX3QgY3B1 X2lkKQoreworCXN0cnVjdCBsaXN0X2hlYWQgKmN1cjsKKwlzdHJ1Y3QgcGNwdSAqcGNwdTsKKwor CWxpc3RfZm9yX2VhY2goY3VyLCAmeGVuX3BjcHVzKSB7CisJCXBjcHUgPSBsaXN0X2VudHJ5KGN1 ciwgc3RydWN0IHBjcHUsIGxpc3QpOworCQlpZiAocGNwdS0+Y3B1X2lkID09IGNwdV9pZCkKKwkJ CXJldHVybiBwY3B1OworCX0KKworCXJldHVybiBOVUxMOworfQorCitzdGF0aWMgdm9pZCBwY3B1 X3N5c19yZW1vdmUoc3RydWN0IHBjcHUgKnBjcHUpCit7CisJc3RydWN0IGRldmljZSAqZGV2Owor CisJaWYgKCFwY3B1KQorCQlyZXR1cm47CisKKwlkZXYgPSAmcGNwdS0+ZGV2OworCWlmIChkZXYt PmlkKQorCQlkZXZpY2VfcmVtb3ZlX2ZpbGUoZGV2LCAmZGV2X2F0dHJfb25saW5lKTsKKworCWRl dmljZV91bnJlZ2lzdGVyKGRldik7Cit9CisKK3N0YXRpYyB2b2lkIGZyZWVfcGNwdShzdHJ1Y3Qg cGNwdSAqcGNwdSkKK3sKKwlpZiAoIXBjcHUpCisJCXJldHVybjsKKworCXBjcHVfc3lzX3JlbW92 ZShwY3B1KTsKKworCWxpc3RfZGVsKCZwY3B1LT5saXN0KTsKKwlrZnJlZShwY3B1KTsKK30KKwor c3RhdGljIGludCBwY3B1X3N5c19jcmVhdGUoc3RydWN0IHBjcHUgKnBjcHUpCit7CisJc3RydWN0 IGRldmljZSAqZGV2OworCWludCBlcnIgPSAtRUlOVkFMOworCisJaWYgKCFwY3B1KQorCQlyZXR1 cm4gZXJyOworCisJZGV2ID0gJnBjcHUtPmRldjsKKwlkZXYtPmJ1cyA9ICZ4ZW5fcGNwdV9zdWJz eXM7CisJZGV2LT5pZCA9IHBjcHUtPmNwdV9pZDsKKworCWVyciA9IGRldmljZV9yZWdpc3Rlcihk ZXYpOworCWlmIChlcnIpCisJCXJldHVybiBlcnI7CisKKwkvKgorCSAqIFhlbiBuZXZlciBvZmZs aW5lIGNwdTAgZHVlIHRvIHNldmVyYWwgcmVzdHJpY3Rpb25zCisJICogYW5kIGFzc3VtcHRpb25z LiBUaGlzIGJhc2ljYWxseSBkb2Vzbid0IGFkZCBhIHN5cyBjb250cm9sCisJICogdG8gdXNlciwg b25lIGNhbm5vdCBhdHRlbXB0IHRvIG9mZmxpbmUgQlNQLgorCSAqLworCWlmIChkZXYtPmlkKSB7 CisJCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZShkZXYsICZkZXZfYXR0cl9vbmxpbmUpOworCQlp ZiAoZXJyKSB7CisJCQlkZXZpY2VfdW5yZWdpc3RlcihkZXYpOworCQkJcmV0dXJuIGVycjsKKwkJ fQorCX0KKworCXJldHVybiAwOworfQorCitzdGF0aWMgc3RydWN0IHBjcHUgKmluaXRfcGNwdShz dHJ1Y3QgeGVucGZfcGNwdWluZm8gKmluZm8pCit7CisJc3RydWN0IHBjcHUgKnBjcHU7CisJaW50 IGVycjsKKworCWlmIChpbmZvLT5mbGFncyAmIFhFTl9QQ1BVX0ZMQUdTX0lOVkFMSUQpCisJCXJl dHVybiBFUlJfUFRSKC1FTk9ERVYpOworCisJcGNwdSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBw Y3B1KSwgR0ZQX0tFUk5FTCk7CisJaWYgKCFwY3B1KQorCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVN KTsKKworCUlOSVRfTElTVF9IRUFEKCZwY3B1LT5saXN0KTsKKwlwY3B1LT5jcHVfaWQgPSBpbmZv LT54ZW5fY3B1aWQ7CisJcGNwdS0+ZmxhZ3MgPSBpbmZvLT5mbGFnczsKKworCWVyciA9IHBjcHVf c3lzX2NyZWF0ZShwY3B1KTsKKwlpZiAoZXJyKSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh aWxlZCB0byByZWdpc3RlciBwY3B1JXVcbiIsCisJCQkgICBpbmZvLT54ZW5fY3B1aWQpOworCQlr ZnJlZShwY3B1KTsKKwkJcmV0dXJuIEVSUl9QVFIoLUVOT0VOVCk7CisJfQorCisJLyogTmVlZCBo b2xkIG9uIHhlbl9wY3B1X2xvY2sgYmVmb3JlIHBjcHUgbGlzdCBtYW5pcHVsYXRpb25zICovCisJ bGlzdF9hZGRfdGFpbCgmcGNwdS0+bGlzdCwgJnhlbl9wY3B1cyk7CisJcmV0dXJuIHBjcHU7Cit9 CisKKy8qCisgKiBDYWxsZXIgc2hvdWxkIGhvbGQgdGhlIHhlbl9wY3B1X2xvY2sKKyAqLworc3Rh dGljIGludCBzeW5jX3BjcHUodWludDMyX3QgY3B1LCB1aW50MzJfdCAqbWF4X2NwdSkKK3sKKwlp bnQgcmV0OworCXN0cnVjdCBwY3B1ICpwY3B1ID0gTlVMTDsKKwlzdHJ1Y3QgeGVucGZfcGNwdWlu Zm8gKmluZm87CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcCA9IHsKKwkJLmNtZCAgICAgICAg ICAgICAgICAgICA9IFhFTlBGX2dldF9jcHVpbmZvLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gICAg ID0gWEVOUEZfSU5URVJGQUNFX1ZFUlNJT04sCisJCS51LnBjcHVfaW5mby54ZW5fY3B1aWQgPSBj cHUsCisJfTsKKworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlmIChyZXQpCisJ CXJldHVybiByZXQ7CisKKwlpbmZvID0gJm9wLnUucGNwdV9pbmZvOworCWlmIChtYXhfY3B1KQor CQkqbWF4X2NwdSA9IGluZm8tPm1heF9wcmVzZW50OworCisJcGNwdSA9IGdldF9wY3B1KGNwdSk7 CisKKwlpZiAoaW5mby0+ZmxhZ3MgJiBYRU5fUENQVV9GTEFHU19JTlZBTElEKSB7CisJCS8qIFRo ZSBwY3B1IGhhcyBiZWVuIHJlbW92ZWQgKi8KKwkJaWYgKHBjcHUpCisJCQlmcmVlX3BjcHUocGNw dSk7CisJCXJldHVybiAwOworCX0KKworCWlmICghcGNwdSkgeworCQlwY3B1ID0gaW5pdF9wY3B1 KGluZm8pOworCQlpZiAoSVNfRVJSX09SX05VTEwocGNwdSkpCisJCQlyZXR1cm4gLUVOT0RFVjsK Kwl9IGVsc2UKKwkJcGNwdV9vbmxpbmVfc3RhdHVzKGluZm8sIHBjcHUpOworCisJcmV0dXJuIDA7 Cit9CisKKy8qCisgKiBTeW5jIGRvbTAncyBwY3B1IGluZm9ybWF0aW9uIHdpdGggeGVuIGh5cGVy dmlzb3IncworICovCitzdGF0aWMgaW50IHhlbl9zeW5jX3BjcHVzKHZvaWQpCit7CisJLyoKKwkg KiBCb290IGNwdSBhbHdheXMgaGF2ZSBjcHVfaWQgMCBpbiB4ZW4KKwkgKi8KKwl1aW50MzJfdCBj cHUgPSAwLCBtYXhfY3B1ID0gMDsKKwlpbnQgZXJyID0gMDsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpj dXIsICp0bXA7CisJc3RydWN0IHBjcHUgKnBjcHU7CisKKwltdXRleF9sb2NrKCZ4ZW5fcGNwdV9s b2NrKTsKKworCXdoaWxlICghZXJyICYmIChjcHUgPD0gbWF4X2NwdSkpIHsKKwkJZXJyID0gc3lu Y19wY3B1KGNwdSwgJm1heF9jcHUpOworCQljcHUrKzsKKwl9CisKKwlpZiAoZXJyKSB7CisJCWxp c3RfZm9yX2VhY2hfc2FmZShjdXIsIHRtcCwgJnhlbl9wY3B1cykgeworCQkJcGNwdSA9IGxpc3Rf ZW50cnkoY3VyLCBzdHJ1Y3QgcGNwdSwgbGlzdCk7CisJCQlmcmVlX3BjcHUocGNwdSk7CisJCX0K Kwl9CisKKwltdXRleF91bmxvY2soJnhlbl9wY3B1X2xvY2spOworCisJcmV0dXJuIGVycjsKK30K Kworc3RhdGljIHZvaWQgeGVuX3BjcHVfd29ya19mbihzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmsp Cit7CisJeGVuX3N5bmNfcGNwdXMoKTsKK30KK3N0YXRpYyBERUNMQVJFX1dPUksoeGVuX3BjcHVf d29yaywgeGVuX3BjcHVfd29ya19mbik7CisKK3N0YXRpYyBpcnFyZXR1cm5fdCB4ZW5fcGNwdV9p bnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQoreworCXNjaGVkdWxlX3dvcmsoJnhlbl9w Y3B1X3dvcmspOworCXJldHVybiBJUlFfSEFORExFRDsKK30KKworc3RhdGljIGludCBfX2luaXQg eGVuX3BjcHVfaW5pdCh2b2lkKQoreworCWludCBpcnEsIHJldDsKKworCWlmICgheGVuX2luaXRp YWxfZG9tYWluKCkpCisJCXJldHVybiAtRU5PREVWOworCisJaXJxID0gYmluZF92aXJxX3RvX2ly cWhhbmRsZXIoVklSUV9QQ1BVX1NUQVRFLCAwLAorCQkJCSAgICAgIHhlbl9wY3B1X2ludGVycnVw dCwgMCwKKwkJCQkgICAgICAieGVuLXBjcHUiLCBOVUxMKTsKKwlpZiAoaXJxIDwgMCkgeworCQlw cl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQgdG8gYmluZCBwY3B1IHZpcnFcbiIpOworCQlyZXR1 cm4gaXJxOworCX0KKworCXJldCA9IHN1YnN5c19zeXN0ZW1fcmVnaXN0ZXIoJnhlbl9wY3B1X3N1 YnN5cywgTlVMTCk7CisJaWYgKHJldCkgeworCQlwcl93YXJuaW5nKFhFTl9QQ1BVICJGYWlsZWQg dG8gcmVnaXN0ZXIgcGNwdSBzdWJzeXNcbiIpOworCQlnb3RvIGVycjE7CisJfQorCisJcmV0ID0g eGVuX3N5bmNfcGNwdXMoKTsKKwlpZiAocmV0KSB7CisJCXByX3dhcm5pbmcoWEVOX1BDUFUgIkZh aWxlZCB0byBzeW5jIHBjcHUgaW5mb1xuIik7CisJCWdvdG8gZXJyMjsKKwl9CisKKwlyZXR1cm4g MDsKKworZXJyMjoKKwlidXNfdW5yZWdpc3RlcigmeGVuX3BjcHVfc3Vic3lzKTsKK2VycjE6CisJ dW5iaW5kX2Zyb21faXJxaGFuZGxlcihpcnEsIE5VTEwpOworCXJldHVybiByZXQ7Cit9CithcmNo X2luaXRjYWxsKHhlbl9wY3B1X2luaXQpOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJm YWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaAppbmRleCA0 ODY2NTNmLi42MWZhNjYxIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZv cm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApAQCAtMzE0LDYgKzMx NCwxMyBAQCBzdHJ1Y3QgeGVucGZfcGNwdWluZm8gewogfTsKIERFRklORV9HVUVTVF9IQU5ETEVf U1RSVUNUKHhlbnBmX3BjcHVpbmZvKTsKIAorI2RlZmluZSBYRU5QRl9jcHVfb25saW5lCTU2Cisj ZGVmaW5lIFhFTlBGX2NwdV9vZmZsaW5lCTU3CitzdHJ1Y3QgeGVucGZfY3B1X29sIHsKKwl1aW50 MzJfdCBjcHVpZDsKK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5wZl9jcHVfb2wp OworCiBzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIHsKIAl1aW50MzJfdCBjbWQ7CiAJdWludDMyX3Qg aW50ZXJmYWNlX3ZlcnNpb247IC8qIFhFTlBGX0lOVEVSRkFDRV9WRVJTSU9OICovCkBAIC0zMzAs NiArMzM3LDcgQEAgc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCB7CiAJCXN0cnVjdCB4ZW5wZl9nZXRp ZGxldGltZSAgICAgICBnZXRpZGxldGltZTsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3Jf cG1pbmZvIHNldF9wbWluZm87CiAJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1 X2luZm87CisJCXN0cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CiAJCXVpbnQ4 X3QgICAgICAgICAgICAgICAgICAgICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwpkaWZmIC0tZ2l0 IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl bi5oCmluZGV4IGE4OTA4MDQuLjA4MDE0NjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2ludGVy ZmFjZS94ZW4uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKQEAgLTgwLDYgKzgw LDcgQEAKICNkZWZpbmUgVklSUV9DT05TT0xFICAgIDIgIC8qIChET00wKSBCeXRlcyByZWNlaXZl ZCBvbiBlbWVyZ2VuY3kgY29uc29sZS4gKi8KICNkZWZpbmUgVklSUV9ET01fRVhDICAgIDMgIC8q IChET00wKSBFeGNlcHRpb25hbCBldmVudCBmb3Igc29tZSBkb21haW4uICAgKi8KICNkZWZpbmUg VklSUV9ERUJVR0dFUiAgIDYgIC8qIChET00wKSBBIGRvbWFpbiBoYXMgcGF1c2VkIGZvciBkZWJ1 Z2dpbmcuICAgKi8KKyNkZWZpbmUgVklSUV9QQ1BVX1NUQVRFIDkgIC8qIChET00wKSBQQ1BVIHN0 YXRlIGNoYW5nZWQgICAgICAgICAgICAgICAgICAgKi8KIAogLyogQXJjaGl0ZWN0dXJlLXNwZWNp ZmljIFZJUlEgZGVmaW5pdGlvbnMuICovCiAjZGVmaW5lIFZJUlFfQVJDSF8wICAgIDE2Ci0tIAox LjcuMQoK --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --_002_DE8DF0795D48FD4CA783C40EC82923351B58A3SHSMSX101ccrcorpi_-- From xen-devel-bounces@lists.xen.org Thu May 10 15:10:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0A-0001F9-3o; Thu, 10 May 2012 15:09:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV09-0001Ew-Kz for xen-devel@lists.xen.org; Thu, 10 May 2012 15:09:57 +0000 Received: from [85.158.139.83:5055] by server-6.bemta-5.messagelabs.com id CF/DA-13222-44ADBAF4; Thu, 10 May 2012 15:09:56 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1336662594!27018446!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10548 invoked from network); 10 May 2012 15:09:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:09:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276829" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:36 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:35 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvu-0007Op-RQ; Thu, 10 May 2012 16:05:34 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvs-0000JJ-33; Thu, 10 May 2012 16:05:32 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:44 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 00 of 11] Use a reader-writer lock for the p2m X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cleaned-up version of my patch of two weeks ago to make the p2m lock into an rwlock, with some updates from Andres folded in. With these applied, p2m lookups are no longer serialized in the common case (where there are few updates). I hope to check these in next week, before we branch for 4.2. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0A-0001F9-3o; Thu, 10 May 2012 15:09:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV09-0001Ew-Kz for xen-devel@lists.xen.org; Thu, 10 May 2012 15:09:57 +0000 Received: from [85.158.139.83:5055] by server-6.bemta-5.messagelabs.com id CF/DA-13222-44ADBAF4; Thu, 10 May 2012 15:09:56 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1336662594!27018446!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10548 invoked from network); 10 May 2012 15:09:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:09:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276829" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:36 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:35 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvu-0007Op-RQ; Thu, 10 May 2012 16:05:34 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvs-0000JJ-33; Thu, 10 May 2012 16:05:32 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:44 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 00 of 11] Use a reader-writer lock for the p2m X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cleaned-up version of my patch of two weeks ago to make the p2m lock into an rwlock, with some updates from Andres folded in. With these applied, p2m lookups are no longer serialized in the common case (where there are few updates). I hope to check these in next week, before we branch for 4.2. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0C-0001Fj-GN; Thu, 10 May 2012 15:10:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0A-0001FE-Qz for xen-devel@lists.xen.org; Thu, 10 May 2012 15:09:59 +0000 Received: from [85.158.139.83:5200] by server-8.bemta-5.messagelabs.com id 47/63-26964-54ADBAF4; Thu, 10 May 2012 15:09:57 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1336662594!27018446!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10640 invoked from network); 10 May 2012 15:09:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:09:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276842" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:38 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:38 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvx-0007Ov-DD; Thu, 10 May 2012 16:05:37 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvw-0000Je-IU; Thu, 10 May 2012 16:05:36 +0100 MIME-Version: 1.0 X-Mercurial-Node: e03806b10f0026590e7775008f24d2a96051552e Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:46 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 02 of 11] x86/mm: Introduce get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID e03806b10f0026590e7775008f24d2a96051552e # Parent 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca x86/mm: Introduce get_page_from_gfn(). This new function does a p2m lookup under the read lock, falling back to the write lock only if it needs to make a change. If the GFN is backed by RAM, it takes a refcount on the underlying page. The following patches will convert many paths that currently use get_gfn/put_gfn to use the new interface. That will avoid serializing p2m accesses in the common case where no updates are needed (i.e. no page-sharing, VM paging or other p2m trickery). Signed-off-by: Tim Deegan diff -r 4a99c5456e9d -r e03806b10f00 xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 @@ -207,6 +207,59 @@ void __put_gfn(struct p2m_domain *p2m, u gfn_unlock(p2m, gfn, 0); } +/* Atomically look up a GFN and take a reference count on the backing page. */ +struct page_info *get_page_from_gfn_p2m( + struct domain *d, struct p2m_domain *p2m, unsigned long gfn, + p2m_type_t *t, p2m_access_t *a, p2m_query_t q) +{ + struct page_info *page = NULL; + p2m_access_t _a; + p2m_type_t _t; + mfn_t mfn; + + /* Allow t or a to be NULL */ + t = t ?: &_t; + a = a ?: &_a; + + if ( likely(!p2m_locked_by_me(p2m)) ) + { + /* Fast path: look up and get out */ + p2m_read_lock(p2m); + mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0); + if ( (p2m_is_ram(*t) || p2m_is_grant(*t)) + && mfn_valid(mfn) + && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) ) + { + page = mfn_to_page(mfn); + if ( !get_page(page, d) + /* Page could be shared */ + && !get_page(page, dom_cow) ) + page = NULL; + } + p2m_read_unlock(p2m); + + if ( page ) + return page; + + /* Error path: not a suitable GFN at all */ + if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) ) + return NULL; + } + + /* Slow path: take the write lock and do fixups */ + mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL); + if ( p2m_is_ram(*t) && mfn_valid(mfn) ) + { + page = mfn_to_page(mfn); + if ( !get_page(page, d) ) + page = NULL; + } + put_gfn(d, gfn); + + return page; +} + + int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma) { diff -r 4a99c5456e9d -r e03806b10f00 xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -377,6 +377,33 @@ static inline mfn_t get_gfn_query_unlock return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0); } +/* Atomically look up a GFN and take a reference count on the backing page. + * This makes sure the page doesn't get freed (or shared) underfoot, + * and should be used by any path that intends to write to the backing page. + * Returns NULL if the page is not backed by RAM. + * The caller is responsible for calling put_page() afterwards. */ +struct page_info *get_page_from_gfn_p2m(struct domain *d, + struct p2m_domain *p2m, + unsigned long gfn, + p2m_type_t *t, p2m_access_t *a, + p2m_query_t q); + +static inline struct page_info *get_page_from_gfn( + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) +{ + struct page_info *page; + + if ( paging_mode_translate(d) ) + return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q); + + /* Non-translated guests see 1-1 RAM mappings everywhere */ + if (t) + *t = p2m_ram_rw; + page = __mfn_to_page(gfn); + return get_page(page, d) ? page : NULL; +} + + /* General conversion function from mfn to gfn */ static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0C-0001Fj-GN; Thu, 10 May 2012 15:10:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0A-0001FE-Qz for xen-devel@lists.xen.org; Thu, 10 May 2012 15:09:59 +0000 Received: from [85.158.139.83:5200] by server-8.bemta-5.messagelabs.com id 47/63-26964-54ADBAF4; Thu, 10 May 2012 15:09:57 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-9.tower-182.messagelabs.com!1336662594!27018446!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10640 invoked from network); 10 May 2012 15:09:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:09:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276842" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:38 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:38 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUvx-0007Ov-DD; Thu, 10 May 2012 16:05:37 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvw-0000Je-IU; Thu, 10 May 2012 16:05:36 +0100 MIME-Version: 1.0 X-Mercurial-Node: e03806b10f0026590e7775008f24d2a96051552e Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:46 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 02 of 11] x86/mm: Introduce get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID e03806b10f0026590e7775008f24d2a96051552e # Parent 4a99c5456e9d8aa707bbd57bb4f4af88e1d456ca x86/mm: Introduce get_page_from_gfn(). This new function does a p2m lookup under the read lock, falling back to the write lock only if it needs to make a change. If the GFN is backed by RAM, it takes a refcount on the underlying page. The following patches will convert many paths that currently use get_gfn/put_gfn to use the new interface. That will avoid serializing p2m accesses in the common case where no updates are needed (i.e. no page-sharing, VM paging or other p2m trickery). Signed-off-by: Tim Deegan diff -r 4a99c5456e9d -r e03806b10f00 xen/arch/x86/mm/p2m.c --- a/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/p2m.c Thu May 10 15:54:16 2012 +0100 @@ -207,6 +207,59 @@ void __put_gfn(struct p2m_domain *p2m, u gfn_unlock(p2m, gfn, 0); } +/* Atomically look up a GFN and take a reference count on the backing page. */ +struct page_info *get_page_from_gfn_p2m( + struct domain *d, struct p2m_domain *p2m, unsigned long gfn, + p2m_type_t *t, p2m_access_t *a, p2m_query_t q) +{ + struct page_info *page = NULL; + p2m_access_t _a; + p2m_type_t _t; + mfn_t mfn; + + /* Allow t or a to be NULL */ + t = t ?: &_t; + a = a ?: &_a; + + if ( likely(!p2m_locked_by_me(p2m)) ) + { + /* Fast path: look up and get out */ + p2m_read_lock(p2m); + mfn = __get_gfn_type_access(p2m, gfn, t, a, 0, NULL, 0); + if ( (p2m_is_ram(*t) || p2m_is_grant(*t)) + && mfn_valid(mfn) + && !((q & P2M_UNSHARE) && p2m_is_shared(*t)) ) + { + page = mfn_to_page(mfn); + if ( !get_page(page, d) + /* Page could be shared */ + && !get_page(page, dom_cow) ) + page = NULL; + } + p2m_read_unlock(p2m); + + if ( page ) + return page; + + /* Error path: not a suitable GFN at all */ + if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) ) + return NULL; + } + + /* Slow path: take the write lock and do fixups */ + mfn = get_gfn_type_access(p2m, gfn, t, a, q, NULL); + if ( p2m_is_ram(*t) && mfn_valid(mfn) ) + { + page = mfn_to_page(mfn); + if ( !get_page(page, d) ) + page = NULL; + } + put_gfn(d, gfn); + + return page; +} + + int set_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma) { diff -r 4a99c5456e9d -r e03806b10f00 xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -377,6 +377,33 @@ static inline mfn_t get_gfn_query_unlock return __get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, &a, 0, NULL, 0); } +/* Atomically look up a GFN and take a reference count on the backing page. + * This makes sure the page doesn't get freed (or shared) underfoot, + * and should be used by any path that intends to write to the backing page. + * Returns NULL if the page is not backed by RAM. + * The caller is responsible for calling put_page() afterwards. */ +struct page_info *get_page_from_gfn_p2m(struct domain *d, + struct p2m_domain *p2m, + unsigned long gfn, + p2m_type_t *t, p2m_access_t *a, + p2m_query_t q); + +static inline struct page_info *get_page_from_gfn( + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) +{ + struct page_info *page; + + if ( paging_mode_translate(d) ) + return get_page_from_gfn_p2m(d, p2m_get_hostp2m(d), gfn, t, NULL, q); + + /* Non-translated guests see 1-1 RAM mappings everywhere */ + if (t) + *t = p2m_ram_rw; + page = __mfn_to_page(gfn); + return get_page(page, d) ? page : NULL; +} + + /* General conversion function from mfn to gfn */ static inline unsigned long mfn_to_gfn(struct domain *d, mfn_t mfn) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0K-0001IO-TV; Thu, 10 May 2012 15:10:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0J-0001He-5N for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:07 +0000 Received: from [85.158.143.99:14224] by server-3.bemta-4.messagelabs.com id FA/2B-05853-E4ADBAF4; Thu, 10 May 2012 15:10:06 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1336662604!26493992!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7372 invoked from network); 10 May 2012 15:10:05 -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; 10 May 2012 15:10:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276864" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:43 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:43 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw2-0007Oy-FB; Thu, 10 May 2012 16:05:42 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvx-0000Jj-DT; Thu, 10 May 2012 16:05:37 +0100 MIME-Version: 1.0 X-Mercurial-Node: d774bb5c6326d1a7e88a3bfadc546d154a2ad895 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:47 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 03 of 11] arm: Implement get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d774bb5c6326d1a7e88a3bfadc546d154a2ad895 # Parent e03806b10f0026590e7775008f24d2a96051552e arm: Implement get_page_from_gfn() We will be calling this from common code, so add a basic implementation to arch/arm. After 4.2 we should reshuffle some of the p2m interface out of arch/x86 into common headers; for now duplicate a little bit of it. Signed-off-by: Tim Deegan diff -r e03806b10f00 -r d774bb5c6326 xen/include/asm-arm/p2m.h --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -53,6 +53,28 @@ p2m_pod_decrease_reservation(struct doma xen_pfn_t gpfn, unsigned int order); +/* Look up a GFN and take a reference count on the backing page. */ +typedef int p2m_type_t; +typedef unsigned int p2m_query_t; +#define P2M_ALLOC (1u<<0) /* Populate PoD and paged-out entries */ +#define P2M_UNSHARE (1u<<1) /* Break CoW sharing */ + +static inline struct page_info *get_page_from_gfn( + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) +{ + struct page_info *page; + unsigned long mfn = gmfn_to_mfn(d, gfn); + + ASSERT(t == NULL); + + if (!mfn_valid(mfn)) + return NULL; + page = mfn_to_page(mfn); + if ( !get_page(page, d) ) + return NULL; + return page; +} + /* Compatibility function exporting the old untyped interface */ static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0K-0001IO-TV; Thu, 10 May 2012 15:10:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0J-0001He-5N for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:07 +0000 Received: from [85.158.143.99:14224] by server-3.bemta-4.messagelabs.com id FA/2B-05853-E4ADBAF4; Thu, 10 May 2012 15:10:06 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1336662604!26493992!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7372 invoked from network); 10 May 2012 15:10:05 -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; 10 May 2012 15:10:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276864" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:43 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:43 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw2-0007Oy-FB; Thu, 10 May 2012 16:05:42 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUvx-0000Jj-DT; Thu, 10 May 2012 16:05:37 +0100 MIME-Version: 1.0 X-Mercurial-Node: d774bb5c6326d1a7e88a3bfadc546d154a2ad895 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:47 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 03 of 11] arm: Implement get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d774bb5c6326d1a7e88a3bfadc546d154a2ad895 # Parent e03806b10f0026590e7775008f24d2a96051552e arm: Implement get_page_from_gfn() We will be calling this from common code, so add a basic implementation to arch/arm. After 4.2 we should reshuffle some of the p2m interface out of arch/x86 into common headers; for now duplicate a little bit of it. Signed-off-by: Tim Deegan diff -r e03806b10f00 -r d774bb5c6326 xen/include/asm-arm/p2m.h --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -53,6 +53,28 @@ p2m_pod_decrease_reservation(struct doma xen_pfn_t gpfn, unsigned int order); +/* Look up a GFN and take a reference count on the backing page. */ +typedef int p2m_type_t; +typedef unsigned int p2m_query_t; +#define P2M_ALLOC (1u<<0) /* Populate PoD and paged-out entries */ +#define P2M_UNSHARE (1u<<1) /* Break CoW sharing */ + +static inline struct page_info *get_page_from_gfn( + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) +{ + struct page_info *page; + unsigned long mfn = gmfn_to_mfn(d, gfn); + + ASSERT(t == NULL); + + if (!mfn_valid(mfn)) + return NULL; + page = mfn_to_page(mfn); + if ( !get_page(page, d) ) + return NULL; + return page; +} + /* Compatibility function exporting the old untyped interface */ static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Ly-Ap; Thu, 10 May 2012 15:10:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0U-0001LR-Dj for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:18 +0000 Received: from [85.158.138.51:48147] by server-12.bemta-3.messagelabs.com id 37/A5-29760-95ADBAF4; Thu, 10 May 2012 15:10:17 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1336662615!26333110!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14581 invoked from network); 10 May 2012 15:10:16 -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; 10 May 2012 15:10:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276899" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pn-4l; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwF-0000KB-Rf; Thu, 10 May 2012 16:05:55 +0100 MIME-Version: 1.0 X-Mercurial-Node: d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:53 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 09 of 11] x86/hvm: use unlocked p2m lookups in hvmemul_rep_movs() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc # Parent ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b x86/hvm: use unlocked p2m lookups in hvmemul_rep_movs() The eventual hvm_copy or IO emulations will re-check the p2m and DTRT. Signed-off-by: Tim Deegan diff -r ed61cd76e3e3 -r d514c4cfcd2b xen/arch/x86/hvm/emulate.c --- a/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 @@ -677,7 +677,6 @@ static int hvmemul_rep_movs( p2m_type_t sp2mt, dp2mt; int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF); char *buf; - struct two_gfns tg; rc = hvmemul_virtual_to_linear( src_seg, src_offset, bytes_per_rep, reps, hvm_access_read, @@ -705,25 +704,17 @@ static int hvmemul_rep_movs( if ( rc != X86EMUL_OKAY ) return rc; - get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL, - current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL, - P2M_ALLOC, &tg); + /* Check for MMIO ops */ + (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt); + (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt); - if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) ) - { - rc = hvmemul_do_mmio( + if ( sp2mt == p2m_mmio_dm ) + return hvmemul_do_mmio( sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL); - put_two_gfns(&tg); - return rc; - } - if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) ) - { - rc = hvmemul_do_mmio( + if ( dp2mt == p2m_mmio_dm ) + return hvmemul_do_mmio( dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL); - put_two_gfns(&tg); - return rc; - } /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */ bytes = *reps * bytes_per_rep; @@ -738,10 +729,7 @@ 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_two_gfns(&tg); return X86EMUL_UNHANDLEABLE; - } /* Adjust destination address for reverse copy. */ if ( df ) @@ -750,10 +738,7 @@ static int hvmemul_rep_movs( /* Allocate temporary buffer. Fall back to slow emulation if this fails. */ buf = xmalloc_bytes(bytes); if ( buf == NULL ) - { - put_two_gfns(&tg); return X86EMUL_UNHANDLEABLE; - } /* * We do a modicum of checking here, just for paranoia's sake and to @@ -764,7 +749,6 @@ static int hvmemul_rep_movs( rc = hvm_copy_to_guest_phys(dgpa, buf, bytes); xfree(buf); - put_two_gfns(&tg); if ( rc == HVMCOPY_gfn_paged_out ) return X86EMUL_RETRY; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Ly-Ap; Thu, 10 May 2012 15:10:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0U-0001LR-Dj for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:18 +0000 Received: from [85.158.138.51:48147] by server-12.bemta-3.messagelabs.com id 37/A5-29760-95ADBAF4; Thu, 10 May 2012 15:10:17 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1336662615!26333110!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14581 invoked from network); 10 May 2012 15:10:16 -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; 10 May 2012 15:10:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276899" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:56 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:56 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pn-4l; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwF-0000KB-Rf; Thu, 10 May 2012 16:05:55 +0100 MIME-Version: 1.0 X-Mercurial-Node: d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:53 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 09 of 11] x86/hvm: use unlocked p2m lookups in hvmemul_rep_movs() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d514c4cfcd2b18baafa3aa61cb4cc4971cdbeecc # Parent ed61cd76e3e3fad3ec4c216669d1e9ee8c0bfa4b x86/hvm: use unlocked p2m lookups in hvmemul_rep_movs() The eventual hvm_copy or IO emulations will re-check the p2m and DTRT. Signed-off-by: Tim Deegan diff -r ed61cd76e3e3 -r d514c4cfcd2b xen/arch/x86/hvm/emulate.c --- a/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/hvm/emulate.c Thu May 10 15:54:16 2012 +0100 @@ -677,7 +677,6 @@ static int hvmemul_rep_movs( p2m_type_t sp2mt, dp2mt; int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF); char *buf; - struct two_gfns tg; rc = hvmemul_virtual_to_linear( src_seg, src_offset, bytes_per_rep, reps, hvm_access_read, @@ -705,25 +704,17 @@ static int hvmemul_rep_movs( if ( rc != X86EMUL_OKAY ) return rc; - get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL, - current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL, - P2M_ALLOC, &tg); + /* Check for MMIO ops */ + (void) get_gfn_query_unlocked(current->domain, sgpa >> PAGE_SHIFT, &sp2mt); + (void) get_gfn_query_unlocked(current->domain, dgpa >> PAGE_SHIFT, &dp2mt); - if ( !p2m_is_ram(sp2mt) && !p2m_is_grant(sp2mt) ) - { - rc = hvmemul_do_mmio( + if ( sp2mt == p2m_mmio_dm ) + return hvmemul_do_mmio( sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL); - put_two_gfns(&tg); - return rc; - } - if ( !p2m_is_ram(dp2mt) && !p2m_is_grant(dp2mt) ) - { - rc = hvmemul_do_mmio( + if ( dp2mt == p2m_mmio_dm ) + return hvmemul_do_mmio( dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL); - put_two_gfns(&tg); - return rc; - } /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */ bytes = *reps * bytes_per_rep; @@ -738,10 +729,7 @@ 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_two_gfns(&tg); return X86EMUL_UNHANDLEABLE; - } /* Adjust destination address for reverse copy. */ if ( df ) @@ -750,10 +738,7 @@ static int hvmemul_rep_movs( /* Allocate temporary buffer. Fall back to slow emulation if this fails. */ buf = xmalloc_bytes(bytes); if ( buf == NULL ) - { - put_two_gfns(&tg); return X86EMUL_UNHANDLEABLE; - } /* * We do a modicum of checking here, just for paranoia's sake and to @@ -764,7 +749,6 @@ static int hvmemul_rep_movs( rc = hvm_copy_to_guest_phys(dgpa, buf, bytes); xfree(buf); - put_two_gfns(&tg); if ( rc == HVMCOPY_gfn_paged_out ) return X86EMUL_RETRY; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0W-0001Mj-Pu; Thu, 10 May 2012 15:10:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Lg-29 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:19 +0000 Received: from [85.158.143.35:55777] by server-2.bemta-4.messagelabs.com id 51/55-17550-A5ADBAF4; Thu, 10 May 2012 15:10:18 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-21.messagelabs.com!1336662614!12295526!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18241 invoked from network); 10 May 2012 15:10:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:10:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276895" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:52 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw9-0007P7-9P; Thu, 10 May 2012 16:05:49 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw7-0000Ju-FW; Thu, 10 May 2012 16:05:47 +0100 MIME-Version: 1.0 X-Mercurial-Node: c68f83ff7bf403637ade5a6002a7749226602c05 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:49 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 05 of 11] x86/mm: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID c68f83ff7bf403637ade5a6002a7749226602c05 # Parent 9da426cdc7e478e426bcbd5391b8deacdc85db1e x86/mm: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 @@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off { struct vcpu *v = current; struct domain *d = v->domain; - unsigned long gmfn, mfn; + unsigned long gmfn; + struct page_info *page; l1_pgentry_t l1e, nl1e; unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT); int okay; @@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off return 0; gmfn = l1e_get_pfn(l1e); - mfn = get_gfn_untyped(d, gmfn); - if ( unlikely(!mfn_valid(mfn)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) + return 0; + + okay = get_page_type(page, PGT_seg_desc_page); + if ( unlikely(!okay) ) { - put_gfn(d, gmfn); + put_page(page); return 0; } - okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page); - if ( unlikely(!okay) ) - { - put_gfn(d, gmfn); - return 0; - } - - nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW); + nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW); spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock); l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e); v->arch.pv_vcpu.shadow_ldt_mapcnt++; spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock); - put_gfn(d, gmfn); return 1; } @@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl { l1_pgentry_t ol1e; struct domain *pt_dom = pt_vcpu->domain; - p2m_type_t p2mt; int rc = 0; if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) ) @@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl if ( l1e_get_flags(nl1e) & _PAGE_PRESENT ) { /* Translate foreign guest addresses. */ - unsigned long mfn, gfn; - gfn = l1e_get_pfn(nl1e); - mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt)); - if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) ) + struct page_info *page = NULL; + if ( paging_mode_translate(pg_dom) ) { - put_gfn(pg_dom, gfn); - return -EINVAL; + page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC); + if ( !page ) + return -EINVAL; + nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e)); } - ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0); - nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e)); if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) ) { MEM_LOG("Bad L1 flags %x", l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)); - put_gfn(pg_dom, gfn); + if ( page ) + put_page(page); return -EINVAL; } @@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl adjust_guest_l1e(nl1e, pt_dom); if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad) ) + { + if ( page ) + put_page(page); return 0; - put_gfn(pg_dom, gfn); + } + if ( page ) + put_page(page); return -EBUSY; } switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) ) { default: - put_gfn(pg_dom, gfn); + if ( page ) + put_page(page); return rc; case 0: break; @@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl l1e_remove_flags(nl1e, _PAGE_RW); break; } - + if ( page ) + put_page(page); + adjust_guest_l1e(nl1e, pt_dom); if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad)) ) @@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl ol1e = nl1e; rc = -EBUSY; } - put_gfn(pg_dom, gfn); } else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad)) ) @@ -3042,7 +3044,6 @@ int do_mmuext_op( type = PGT_l4_page_table; pin_page: { - unsigned long mfn; struct page_info *page; /* Ignore pinning of invalid paging levels. */ @@ -3052,25 +3053,28 @@ int do_mmuext_op( if ( paging_mode_refcounts(pg_owner) ) break; - mfn = get_gfn_untyped(pg_owner, op.arg1.mfn); - rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1); + page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) + { + rc = -EINVAL; + break; + } + + rc = get_page_type_preemptible(page, type); okay = !rc; if ( unlikely(!okay) ) { if ( rc == -EINTR ) rc = -EAGAIN; else if ( rc != -EAGAIN ) - MEM_LOG("Error while pinning mfn %lx", mfn); - put_gfn(pg_owner, op.arg1.mfn); + MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page)); + put_page(page); break; } - page = mfn_to_page(mfn); - if ( (rc = xsm_memory_pin_page(d, page)) != 0 ) { put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); okay = 0; break; } @@ -3078,16 +3082,15 @@ int do_mmuext_op( if ( unlikely(test_and_set_bit(_PGT_pinned, &page->u.inuse.type_info)) ) { - MEM_LOG("Mfn %lx already pinned", mfn); + MEM_LOG("Mfn %lx already pinned", page_to_mfn(page)); put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); okay = 0; break; } /* A page is dirtied when its pin status is set. */ - paging_mark_dirty(pg_owner, mfn); - + paging_mark_dirty(pg_owner, page_to_mfn(page)); + /* We can race domain destruction (domain_relinquish_resources). */ if ( unlikely(pg_owner != d) ) { @@ -3099,35 +3102,29 @@ int do_mmuext_op( spin_unlock(&pg_owner->page_alloc_lock); if ( drop_ref ) put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); } break; } case MMUEXT_UNPIN_TABLE: { - unsigned long mfn; struct page_info *page; if ( paging_mode_refcounts(pg_owner) ) break; - mfn = get_gfn_untyped(pg_owner, op.arg1.mfn); - if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) ) + page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) { - put_gfn(pg_owner, op.arg1.mfn); - MEM_LOG("Mfn %lx bad domain", mfn); + MEM_LOG("Mfn %lx bad domain", op.arg1.mfn); break; } - page = mfn_to_page(mfn); - if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) ) { okay = 0; put_page(page); - put_gfn(pg_owner, op.arg1.mfn); - MEM_LOG("Mfn %lx not pinned", mfn); + MEM_LOG("Mfn %lx not pinned", op.arg1.mfn); break; } @@ -3135,40 +3132,43 @@ int do_mmuext_op( put_page(page); /* A page is dirtied when its pin status is cleared. */ - paging_mark_dirty(pg_owner, mfn); - - put_gfn(pg_owner, op.arg1.mfn); + paging_mark_dirty(pg_owner, page_to_mfn(page)); + break; } case MMUEXT_NEW_BASEPTR: - okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn)); - put_gfn(d, op.arg1.mfn); + okay = (!paging_mode_translate(d) + && new_guest_cr3(op.arg1.mfn)); break; + #ifdef __x86_64__ case MMUEXT_NEW_USER_BASEPTR: { - unsigned long old_mfn, mfn; - - mfn = get_gfn_untyped(d, op.arg1.mfn); - if ( mfn != 0 ) + unsigned long old_mfn; + + if ( paging_mode_translate(current->domain) ) + { + okay = 0; + break; + } + + if ( op.arg1.mfn != 0 ) { if ( paging_mode_refcounts(d) ) - okay = get_page_from_pagenr(mfn, d); + okay = get_page_from_pagenr(op.arg1.mfn, d); else okay = !get_page_and_type_from_pagenr( - mfn, PGT_root_page_table, d, 0, 0); + op.arg1.mfn, PGT_root_page_table, d, 0, 0); if ( unlikely(!okay) ) { - put_gfn(d, op.arg1.mfn); - MEM_LOG("Error while installing new mfn %lx", mfn); + MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn); break; } } old_mfn = pagetable_get_pfn(curr->arch.guest_table_user); - curr->arch.guest_table_user = pagetable_from_pfn(mfn); - put_gfn(d, op.arg1.mfn); + curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn); if ( old_mfn != 0 ) { @@ -3283,28 +3283,27 @@ int do_mmuext_op( } case MMUEXT_CLEAR_PAGE: { - unsigned long mfn; + struct page_info *page; unsigned char *ptr; - mfn = get_gfn_untyped(d, op.arg1.mfn); - okay = !get_page_and_type_from_pagenr( - mfn, PGT_writable_page, d, 0, 0); - if ( unlikely(!okay) ) + page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC); + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, op.arg1.mfn); - MEM_LOG("Error while clearing mfn %lx", mfn); + if ( page ) + put_page(page); + MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn); + okay = 0; break; } /* A page is dirtied when it's being cleared. */ - paging_mark_dirty(d, mfn); - - ptr = fixmap_domain_page(mfn); + paging_mark_dirty(d, page_to_mfn(page)); + + ptr = fixmap_domain_page(page_to_mfn(page)); clear_page(ptr); fixunmap_domain_page(ptr); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, op.arg1.mfn); + put_page_and_type(page); break; } @@ -3312,42 +3311,38 @@ int do_mmuext_op( { const unsigned char *src; unsigned char *dst; - unsigned long src_mfn, mfn; - - src_mfn = get_gfn_untyped(d, op.arg2.src_mfn); - okay = get_page_from_pagenr(src_mfn, d); + struct page_info *src_page, *dst_page; + + src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC); + if ( unlikely(!src_page) ) + { + okay = 0; + MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn); + break; + } + + dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC); + okay = (dst_page && get_page_type(dst_page, PGT_writable_page)); if ( unlikely(!okay) ) { - put_gfn(d, op.arg2.src_mfn); - MEM_LOG("Error while copying from mfn %lx", src_mfn); + put_page(src_page); + if ( dst_page ) + put_page(dst_page); + MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn); break; } - mfn = get_gfn_untyped(d, op.arg1.mfn); - okay = !get_page_and_type_from_pagenr( - mfn, PGT_writable_page, d, 0, 0); - if ( unlikely(!okay) ) - { - put_gfn(d, op.arg1.mfn); - put_page(mfn_to_page(src_mfn)); - put_gfn(d, op.arg2.src_mfn); - MEM_LOG("Error while copying to mfn %lx", mfn); - break; - } - /* A page is dirtied when it's being copied to. */ - paging_mark_dirty(d, mfn); - - src = map_domain_page(src_mfn); - dst = fixmap_domain_page(mfn); + paging_mark_dirty(d, page_to_mfn(dst_page)); + + src = __map_domain_page(src_page); + dst = fixmap_domain_page(page_to_mfn(dst_page)); copy_page(dst, src); fixunmap_domain_page(dst); unmap_domain_page(src); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, op.arg1.mfn); - put_page(mfn_to_page(src_mfn)); - put_gfn(d, op.arg2.src_mfn); + put_page_and_type(dst_page); + put_page(src_page); break; } @@ -3538,29 +3533,26 @@ int do_mmu_update( req.ptr -= cmd; gmfn = req.ptr >> PAGE_SHIFT; - mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt)); - if ( !p2m_is_valid(p2mt) ) - mfn = INVALID_MFN; + page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC); if ( p2m_is_paged(p2mt) ) { - put_gfn(pt_owner, gmfn); + ASSERT(!page); p2m_mem_paging_populate(pg_owner, gmfn); rc = -ENOENT; break; } - if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) ) + if ( unlikely(!page) ) { MEM_LOG("Could not get page for normal update"); - put_gfn(pt_owner, gmfn); break; } + mfn = page_to_mfn(page); va = map_domain_page_with_cache(mfn, &mapcache); va = (void *)((unsigned long)va + (unsigned long)(req.ptr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( page_lock(page) ) { @@ -3569,22 +3561,23 @@ int do_mmu_update( case PGT_l1_page_table: { l1_pgentry_t l1e = l1e_from_intpte(req.val); - p2m_type_t l1e_p2mt; - unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn; - - l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt)); + p2m_type_t l1e_p2mt = p2m_ram_rw; + struct page_info *target = NULL; + + if ( paging_mode_translate(pg_owner) ) + target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e), + &l1e_p2mt, P2M_ALLOC); if ( p2m_is_paged(l1e_p2mt) ) { - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e)); rc = -ENOENT; break; } - else if ( p2m_ram_paging_in == l1e_p2mt && - !mfn_valid(l1emfn) ) + else if ( p2m_ram_paging_in == l1e_p2mt && !target ) { - put_gfn(pg_owner, l1egfn); rc = -ENOENT; break; } @@ -3601,7 +3594,8 @@ int do_mmu_update( rc = mem_sharing_unshare_page(pg_owner, gfn, 0); if ( rc ) { - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); /* Notify helper, don't care about errors, will not * sleep on wq, since we're a foreign domain. */ (void)mem_sharing_notify_enomem(pg_owner, gfn, 0); @@ -3614,112 +3608,22 @@ int do_mmu_update( rc = mod_l1_entry(va, l1e, mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v, pg_owner); - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); } break; case PGT_l2_page_table: - { - l2_pgentry_t l2e = l2e_from_intpte(req.val); - p2m_type_t l2e_p2mt; - unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn; - - l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt)); - - if ( p2m_is_paged(l2e_p2mt) ) - { - put_gfn(pg_owner, l2egfn); - p2m_mem_paging_populate(pg_owner, l2egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l2e_p2mt && - !mfn_valid(l2emfn) ) - { - put_gfn(pg_owner, l2egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l2e_p2mt ) - { - put_gfn(pg_owner, l2egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - - rc = mod_l2_entry(va, l2e, mfn, + rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v); - put_gfn(pg_owner, l2egfn); - } - break; + break; case PGT_l3_page_table: - { - l3_pgentry_t l3e = l3e_from_intpte(req.val); - p2m_type_t l3e_p2mt; - unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn; - - l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt)); - - if ( p2m_is_paged(l3e_p2mt) ) - { - put_gfn(pg_owner, l3egfn); - p2m_mem_paging_populate(pg_owner, l3egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l3e_p2mt && - !mfn_valid(l3emfn) ) - { - put_gfn(pg_owner, l3egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l3e_p2mt ) - { - put_gfn(pg_owner, l3egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - rc = mod_l3_entry(va, l3e, mfn, + rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v); - put_gfn(pg_owner, l3egfn); - } - break; + break; #if CONFIG_PAGING_LEVELS >= 4 case PGT_l4_page_table: - { - l4_pgentry_t l4e = l4e_from_intpte(req.val); - p2m_type_t l4e_p2mt; - unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn; - - l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt)); - - if ( p2m_is_paged(l4e_p2mt) ) - { - put_gfn(pg_owner, l4egfn); - p2m_mem_paging_populate(pg_owner, l4egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l4e_p2mt && - !mfn_valid(l4emfn) ) - { - put_gfn(pg_owner, l4egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l4e_p2mt ) - { - put_gfn(pg_owner, l4egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - rc = mod_l4_entry(va, l4e, mfn, + rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v); - put_gfn(pg_owner, l4egfn); - } break; #endif case PGT_writable_page: @@ -3742,7 +3646,6 @@ int do_mmu_update( unmap_domain_page_with_cache(va, &mapcache); put_page(page); - put_gfn(pt_owner, gmfn); } break; @@ -3829,18 +3732,17 @@ static int create_grant_pte_mapping( adjust_guest_l1e(nl1e, d); gmfn = pte_addr >> PAGE_SHIFT; - mfn = get_gfn_untyped(d, gmfn); - - if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( unlikely(!page) ) { - put_gfn(d, gmfn); MEM_LOG("Could not get page for normal update"); return GNTST_general_error; } + mfn = page_to_mfn(page); va = map_domain_page(mfn); va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( !page_lock(page) ) { @@ -3871,7 +3773,6 @@ static int create_grant_pte_mapping( failed: unmap_domain_page(va); put_page(page); - put_gfn(d, gmfn); return rc; } @@ -3886,18 +3787,17 @@ static int destroy_grant_pte_mapping( l1_pgentry_t ol1e; gmfn = addr >> PAGE_SHIFT; - mfn = get_gfn_untyped(d, gmfn); - - if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( unlikely(!page) ) { - put_gfn(d, gmfn); MEM_LOG("Could not get page for normal update"); return GNTST_general_error; } + mfn = page_to_mfn(page); va = map_domain_page(mfn); va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( !page_lock(page) ) { @@ -3942,7 +3842,6 @@ static int destroy_grant_pte_mapping( failed: unmap_domain_page(va); put_page(page); - put_gfn(d, gmfn); return rc; } @@ -4465,11 +4364,17 @@ long set_gdt(struct vcpu *v, /* Check the pages in the new GDT. */ for ( i = 0; i < nr_pages; i++ ) { + struct page_info *page; pfns[i] = frames[i]; - mfn = frames[i] = get_gfn_untyped(d, frames[i]); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) ) + page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC); + if ( !page ) goto fail; + if ( !get_page_type(page, PGT_seg_desc_page) ) + { + put_page(page); + goto fail; + } + mfn = frames[i] = page_to_mfn(page); } /* Tear down the old GDT. */ @@ -4482,7 +4387,6 @@ long set_gdt(struct vcpu *v, v->arch.pv_vcpu.gdt_frames[i] = frames[i]; l1e_write(&v->arch.perdomain_ptes[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR)); - put_gfn(d, pfns[i]); } xfree(pfns); @@ -4492,7 +4396,6 @@ long set_gdt(struct vcpu *v, while ( i-- > 0 ) { put_page_and_type(mfn_to_page(frames[i])); - put_gfn(d, pfns[i]); } xfree(pfns); return -EINVAL; @@ -4538,21 +4441,16 @@ long do_update_descriptor(u64 pa, u64 de *(u64 *)&d = desc; - mfn = get_gfn_untyped(dom, gmfn); + page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC); if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) || - !mfn_valid(mfn) || + !page || !check_descriptor(dom, &d) ) { - put_gfn(dom, gmfn); + if ( page ) + put_page(page); return -EINVAL; } - - page = mfn_to_page(mfn); - if ( unlikely(!get_page(page, dom)) ) - { - put_gfn(dom, gmfn); - return -EINVAL; - } + mfn = page_to_mfn(page); /* Check if the given frame is in use in an unsafe context. */ switch ( page->u.inuse.type_info & PGT_type_mask ) @@ -4580,7 +4478,6 @@ long do_update_descriptor(u64 pa, u64 de out: put_page(page); - put_gfn(dom, gmfn); return ret; } diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm/guest_walk.c --- a/xen/arch/x86/mm/guest_walk.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/guest_walk.c Thu May 10 15:54:16 2012 +0100 @@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc p2m_type_t *p2mt, uint32_t *rc) { - p2m_access_t p2ma; + struct page_info *page; void *map; /* Translate the gfn, unsharing if shared */ - *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL, + P2M_ALLOC | P2M_UNSHARE); if ( p2m_is_paging(*p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); - __put_gfn(p2m, gfn_x(gfn)); + if ( page ) + put_page(page); p2m_mem_paging_populate(p2m->domain, gfn_x(gfn)); *rc = _PAGE_PAGED; return NULL; } if ( p2m_is_shared(*p2mt) ) { - __put_gfn(p2m, gfn_x(gfn)); + if ( page ) + put_page(page); *rc = _PAGE_SHARED; return NULL; } - if ( !p2m_is_ram(*p2mt) ) + if ( !page ) { - __put_gfn(p2m, gfn_x(gfn)); *rc |= _PAGE_PRESENT; return NULL; } + *mfn = _mfn(page_to_mfn(page)); ASSERT(mfn_valid(mfn_x(*mfn))); - - /* Get an extra ref to the page to ensure liveness of the map. - * Then we can safely put gfn */ - page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn))); + map = map_domain_page(mfn_x(*mfn)); - __put_gfn(p2m, gfn_x(gfn)); return map; } diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm/hap/guest_walk.c --- a/xen/arch/x86/mm/hap/guest_walk.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/hap/guest_walk.c Thu May 10 15:54:16 2012 +0100 @@ -54,34 +54,36 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA mfn_t top_mfn; void *top_map; p2m_type_t p2mt; - p2m_access_t p2ma; walk_t gw; unsigned long top_gfn; + struct page_info *top_page; /* Get the top-level table's MFN */ top_gfn = cr3 >> PAGE_SHIFT; - top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn, + &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); pfec[0] = PFEC_page_paged; - __put_gfn(p2m, top_gfn); + if ( top_page ) + put_page(top_page); p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT); return INVALID_GFN; } if ( p2m_is_shared(p2mt) ) { pfec[0] = PFEC_page_shared; - __put_gfn(p2m, top_gfn); + if ( top_page ) + put_page(top_page); return INVALID_GFN; } - if ( !p2m_is_ram(p2mt) ) + if ( !top_page ) { pfec[0] &= ~PFEC_page_present; - __put_gfn(p2m, top_gfn); return INVALID_GFN; } + top_mfn = _mfn(page_to_mfn(top_page)); /* Map the top-level table and call the tree-walker */ ASSERT(mfn_valid(mfn_x(top_mfn))); @@ -91,31 +93,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA #endif missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map); unmap_domain_page(top_map); - __put_gfn(p2m, top_gfn); + put_page(top_page); /* Interpret the answer */ if ( missing == 0 ) { gfn_t gfn = guest_l1e_get_gfn(gw.l1e); - (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + struct page_info *page; + page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt, + NULL, P2M_ALLOC | P2M_UNSHARE); + if ( page ) + put_page(page); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); pfec[0] = PFEC_page_paged; - __put_gfn(p2m, gfn_x(gfn)); p2m_mem_paging_populate(p2m->domain, gfn_x(gfn)); return INVALID_GFN; } if ( p2m_is_shared(p2mt) ) { pfec[0] = PFEC_page_shared; - __put_gfn(p2m, gfn_x(gfn)); return INVALID_GFN; } - __put_gfn(p2m, gfn_x(gfn)); - if ( page_order ) *page_order = guest_walk_to_page_order(&gw); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0W-0001Mj-Pu; Thu, 10 May 2012 15:10:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Lg-29 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:19 +0000 Received: from [85.158.143.35:55777] by server-2.bemta-4.messagelabs.com id 51/55-17550-A5ADBAF4; Thu, 10 May 2012 15:10:18 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-21.messagelabs.com!1336662614!12295526!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18241 invoked from network); 10 May 2012 15:10:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 15:10:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276895" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:52 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUw9-0007P7-9P; Thu, 10 May 2012 16:05:49 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUw7-0000Ju-FW; Thu, 10 May 2012 16:05:47 +0100 MIME-Version: 1.0 X-Mercurial-Node: c68f83ff7bf403637ade5a6002a7749226602c05 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:49 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 05 of 11] x86/mm: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID c68f83ff7bf403637ade5a6002a7749226602c05 # Parent 9da426cdc7e478e426bcbd5391b8deacdc85db1e x86/mm: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 @@ -651,7 +651,8 @@ int map_ldt_shadow_page(unsigned int off { struct vcpu *v = current; struct domain *d = v->domain; - unsigned long gmfn, mfn; + unsigned long gmfn; + struct page_info *page; l1_pgentry_t l1e, nl1e; unsigned long gva = v->arch.pv_vcpu.ldt_base + (off << PAGE_SHIFT); int okay; @@ -663,28 +664,24 @@ int map_ldt_shadow_page(unsigned int off return 0; gmfn = l1e_get_pfn(l1e); - mfn = get_gfn_untyped(d, gmfn); - if ( unlikely(!mfn_valid(mfn)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) + return 0; + + okay = get_page_type(page, PGT_seg_desc_page); + if ( unlikely(!okay) ) { - put_gfn(d, gmfn); + put_page(page); return 0; } - okay = get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page); - if ( unlikely(!okay) ) - { - put_gfn(d, gmfn); - return 0; - } - - nl1e = l1e_from_pfn(mfn, l1e_get_flags(l1e) | _PAGE_RW); + nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW); spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock); l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e); v->arch.pv_vcpu.shadow_ldt_mapcnt++; spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock); - put_gfn(d, gmfn); return 1; } @@ -1819,7 +1816,6 @@ static int mod_l1_entry(l1_pgentry_t *pl { l1_pgentry_t ol1e; struct domain *pt_dom = pt_vcpu->domain; - p2m_type_t p2mt; int rc = 0; if ( unlikely(__copy_from_user(&ol1e, pl1e, sizeof(ol1e)) != 0) ) @@ -1835,22 +1831,21 @@ static int mod_l1_entry(l1_pgentry_t *pl if ( l1e_get_flags(nl1e) & _PAGE_PRESENT ) { /* Translate foreign guest addresses. */ - unsigned long mfn, gfn; - gfn = l1e_get_pfn(nl1e); - mfn = mfn_x(get_gfn(pg_dom, gfn, &p2mt)); - if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) ) + struct page_info *page = NULL; + if ( paging_mode_translate(pg_dom) ) { - put_gfn(pg_dom, gfn); - return -EINVAL; + page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC); + if ( !page ) + return -EINVAL; + nl1e = l1e_from_pfn(page_to_mfn(page), l1e_get_flags(nl1e)); } - ASSERT((mfn & ~(PADDR_MASK >> PAGE_SHIFT)) == 0); - nl1e = l1e_from_pfn(mfn, l1e_get_flags(nl1e)); if ( unlikely(l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)) ) { MEM_LOG("Bad L1 flags %x", l1e_get_flags(nl1e) & l1_disallow_mask(pt_dom)); - put_gfn(pg_dom, gfn); + if ( page ) + put_page(page); return -EINVAL; } @@ -1860,15 +1855,21 @@ static int mod_l1_entry(l1_pgentry_t *pl adjust_guest_l1e(nl1e, pt_dom); if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad) ) + { + if ( page ) + put_page(page); return 0; - put_gfn(pg_dom, gfn); + } + if ( page ) + put_page(page); return -EBUSY; } switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) ) { default: - put_gfn(pg_dom, gfn); + if ( page ) + put_page(page); return rc; case 0: break; @@ -1876,7 +1877,9 @@ static int mod_l1_entry(l1_pgentry_t *pl l1e_remove_flags(nl1e, _PAGE_RW); break; } - + if ( page ) + put_page(page); + adjust_guest_l1e(nl1e, pt_dom); if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad)) ) @@ -1884,7 +1887,6 @@ static int mod_l1_entry(l1_pgentry_t *pl ol1e = nl1e; rc = -EBUSY; } - put_gfn(pg_dom, gfn); } else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, preserve_ad)) ) @@ -3042,7 +3044,6 @@ int do_mmuext_op( type = PGT_l4_page_table; pin_page: { - unsigned long mfn; struct page_info *page; /* Ignore pinning of invalid paging levels. */ @@ -3052,25 +3053,28 @@ int do_mmuext_op( if ( paging_mode_refcounts(pg_owner) ) break; - mfn = get_gfn_untyped(pg_owner, op.arg1.mfn); - rc = get_page_and_type_from_pagenr(mfn, type, pg_owner, 0, 1); + page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) + { + rc = -EINVAL; + break; + } + + rc = get_page_type_preemptible(page, type); okay = !rc; if ( unlikely(!okay) ) { if ( rc == -EINTR ) rc = -EAGAIN; else if ( rc != -EAGAIN ) - MEM_LOG("Error while pinning mfn %lx", mfn); - put_gfn(pg_owner, op.arg1.mfn); + MEM_LOG("Error while pinning mfn %lx", page_to_mfn(page)); + put_page(page); break; } - page = mfn_to_page(mfn); - if ( (rc = xsm_memory_pin_page(d, page)) != 0 ) { put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); okay = 0; break; } @@ -3078,16 +3082,15 @@ int do_mmuext_op( if ( unlikely(test_and_set_bit(_PGT_pinned, &page->u.inuse.type_info)) ) { - MEM_LOG("Mfn %lx already pinned", mfn); + MEM_LOG("Mfn %lx already pinned", page_to_mfn(page)); put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); okay = 0; break; } /* A page is dirtied when its pin status is set. */ - paging_mark_dirty(pg_owner, mfn); - + paging_mark_dirty(pg_owner, page_to_mfn(page)); + /* We can race domain destruction (domain_relinquish_resources). */ if ( unlikely(pg_owner != d) ) { @@ -3099,35 +3102,29 @@ int do_mmuext_op( spin_unlock(&pg_owner->page_alloc_lock); if ( drop_ref ) put_page_and_type(page); - put_gfn(pg_owner, op.arg1.mfn); } break; } case MMUEXT_UNPIN_TABLE: { - unsigned long mfn; struct page_info *page; if ( paging_mode_refcounts(pg_owner) ) break; - mfn = get_gfn_untyped(pg_owner, op.arg1.mfn); - if ( unlikely(!(okay = get_page_from_pagenr(mfn, pg_owner))) ) + page = get_page_from_gfn(pg_owner, op.arg1.mfn, NULL, P2M_ALLOC); + if ( unlikely(!page) ) { - put_gfn(pg_owner, op.arg1.mfn); - MEM_LOG("Mfn %lx bad domain", mfn); + MEM_LOG("Mfn %lx bad domain", op.arg1.mfn); break; } - page = mfn_to_page(mfn); - if ( !test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) ) { okay = 0; put_page(page); - put_gfn(pg_owner, op.arg1.mfn); - MEM_LOG("Mfn %lx not pinned", mfn); + MEM_LOG("Mfn %lx not pinned", op.arg1.mfn); break; } @@ -3135,40 +3132,43 @@ int do_mmuext_op( put_page(page); /* A page is dirtied when its pin status is cleared. */ - paging_mark_dirty(pg_owner, mfn); - - put_gfn(pg_owner, op.arg1.mfn); + paging_mark_dirty(pg_owner, page_to_mfn(page)); + break; } case MMUEXT_NEW_BASEPTR: - okay = new_guest_cr3(get_gfn_untyped(d, op.arg1.mfn)); - put_gfn(d, op.arg1.mfn); + okay = (!paging_mode_translate(d) + && new_guest_cr3(op.arg1.mfn)); break; + #ifdef __x86_64__ case MMUEXT_NEW_USER_BASEPTR: { - unsigned long old_mfn, mfn; - - mfn = get_gfn_untyped(d, op.arg1.mfn); - if ( mfn != 0 ) + unsigned long old_mfn; + + if ( paging_mode_translate(current->domain) ) + { + okay = 0; + break; + } + + if ( op.arg1.mfn != 0 ) { if ( paging_mode_refcounts(d) ) - okay = get_page_from_pagenr(mfn, d); + okay = get_page_from_pagenr(op.arg1.mfn, d); else okay = !get_page_and_type_from_pagenr( - mfn, PGT_root_page_table, d, 0, 0); + op.arg1.mfn, PGT_root_page_table, d, 0, 0); if ( unlikely(!okay) ) { - put_gfn(d, op.arg1.mfn); - MEM_LOG("Error while installing new mfn %lx", mfn); + MEM_LOG("Error while installing new mfn %lx", op.arg1.mfn); break; } } old_mfn = pagetable_get_pfn(curr->arch.guest_table_user); - curr->arch.guest_table_user = pagetable_from_pfn(mfn); - put_gfn(d, op.arg1.mfn); + curr->arch.guest_table_user = pagetable_from_pfn(op.arg1.mfn); if ( old_mfn != 0 ) { @@ -3283,28 +3283,27 @@ int do_mmuext_op( } case MMUEXT_CLEAR_PAGE: { - unsigned long mfn; + struct page_info *page; unsigned char *ptr; - mfn = get_gfn_untyped(d, op.arg1.mfn); - okay = !get_page_and_type_from_pagenr( - mfn, PGT_writable_page, d, 0, 0); - if ( unlikely(!okay) ) + page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC); + if ( !page || !get_page_type(page, PGT_writable_page) ) { - put_gfn(d, op.arg1.mfn); - MEM_LOG("Error while clearing mfn %lx", mfn); + if ( page ) + put_page(page); + MEM_LOG("Error while clearing mfn %lx", op.arg1.mfn); + okay = 0; break; } /* A page is dirtied when it's being cleared. */ - paging_mark_dirty(d, mfn); - - ptr = fixmap_domain_page(mfn); + paging_mark_dirty(d, page_to_mfn(page)); + + ptr = fixmap_domain_page(page_to_mfn(page)); clear_page(ptr); fixunmap_domain_page(ptr); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, op.arg1.mfn); + put_page_and_type(page); break; } @@ -3312,42 +3311,38 @@ int do_mmuext_op( { const unsigned char *src; unsigned char *dst; - unsigned long src_mfn, mfn; - - src_mfn = get_gfn_untyped(d, op.arg2.src_mfn); - okay = get_page_from_pagenr(src_mfn, d); + struct page_info *src_page, *dst_page; + + src_page = get_page_from_gfn(d, op.arg2.src_mfn, NULL, P2M_ALLOC); + if ( unlikely(!src_page) ) + { + okay = 0; + MEM_LOG("Error while copying from mfn %lx", op.arg2.src_mfn); + break; + } + + dst_page = get_page_from_gfn(d, op.arg1.mfn, NULL, P2M_ALLOC); + okay = (dst_page && get_page_type(dst_page, PGT_writable_page)); if ( unlikely(!okay) ) { - put_gfn(d, op.arg2.src_mfn); - MEM_LOG("Error while copying from mfn %lx", src_mfn); + put_page(src_page); + if ( dst_page ) + put_page(dst_page); + MEM_LOG("Error while copying to mfn %lx", op.arg1.mfn); break; } - mfn = get_gfn_untyped(d, op.arg1.mfn); - okay = !get_page_and_type_from_pagenr( - mfn, PGT_writable_page, d, 0, 0); - if ( unlikely(!okay) ) - { - put_gfn(d, op.arg1.mfn); - put_page(mfn_to_page(src_mfn)); - put_gfn(d, op.arg2.src_mfn); - MEM_LOG("Error while copying to mfn %lx", mfn); - break; - } - /* A page is dirtied when it's being copied to. */ - paging_mark_dirty(d, mfn); - - src = map_domain_page(src_mfn); - dst = fixmap_domain_page(mfn); + paging_mark_dirty(d, page_to_mfn(dst_page)); + + src = __map_domain_page(src_page); + dst = fixmap_domain_page(page_to_mfn(dst_page)); copy_page(dst, src); fixunmap_domain_page(dst); unmap_domain_page(src); - put_page_and_type(mfn_to_page(mfn)); - put_gfn(d, op.arg1.mfn); - put_page(mfn_to_page(src_mfn)); - put_gfn(d, op.arg2.src_mfn); + put_page_and_type(dst_page); + put_page(src_page); break; } @@ -3538,29 +3533,26 @@ int do_mmu_update( req.ptr -= cmd; gmfn = req.ptr >> PAGE_SHIFT; - mfn = mfn_x(get_gfn(pt_owner, gmfn, &p2mt)); - if ( !p2m_is_valid(p2mt) ) - mfn = INVALID_MFN; + page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC); if ( p2m_is_paged(p2mt) ) { - put_gfn(pt_owner, gmfn); + ASSERT(!page); p2m_mem_paging_populate(pg_owner, gmfn); rc = -ENOENT; break; } - if ( unlikely(!get_page_from_pagenr(mfn, pt_owner)) ) + if ( unlikely(!page) ) { MEM_LOG("Could not get page for normal update"); - put_gfn(pt_owner, gmfn); break; } + mfn = page_to_mfn(page); va = map_domain_page_with_cache(mfn, &mapcache); va = (void *)((unsigned long)va + (unsigned long)(req.ptr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( page_lock(page) ) { @@ -3569,22 +3561,23 @@ int do_mmu_update( case PGT_l1_page_table: { l1_pgentry_t l1e = l1e_from_intpte(req.val); - p2m_type_t l1e_p2mt; - unsigned long l1egfn = l1e_get_pfn(l1e), l1emfn; - - l1emfn = mfn_x(get_gfn(pg_owner, l1egfn, &l1e_p2mt)); + p2m_type_t l1e_p2mt = p2m_ram_rw; + struct page_info *target = NULL; + + if ( paging_mode_translate(pg_owner) ) + target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e), + &l1e_p2mt, P2M_ALLOC); if ( p2m_is_paged(l1e_p2mt) ) { - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); p2m_mem_paging_populate(pg_owner, l1e_get_pfn(l1e)); rc = -ENOENT; break; } - else if ( p2m_ram_paging_in == l1e_p2mt && - !mfn_valid(l1emfn) ) + else if ( p2m_ram_paging_in == l1e_p2mt && !target ) { - put_gfn(pg_owner, l1egfn); rc = -ENOENT; break; } @@ -3601,7 +3594,8 @@ int do_mmu_update( rc = mem_sharing_unshare_page(pg_owner, gfn, 0); if ( rc ) { - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); /* Notify helper, don't care about errors, will not * sleep on wq, since we're a foreign domain. */ (void)mem_sharing_notify_enomem(pg_owner, gfn, 0); @@ -3614,112 +3608,22 @@ int do_mmu_update( rc = mod_l1_entry(va, l1e, mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v, pg_owner); - put_gfn(pg_owner, l1egfn); + if ( target ) + put_page(target); } break; case PGT_l2_page_table: - { - l2_pgentry_t l2e = l2e_from_intpte(req.val); - p2m_type_t l2e_p2mt; - unsigned long l2egfn = l2e_get_pfn(l2e), l2emfn; - - l2emfn = mfn_x(get_gfn(pg_owner, l2egfn, &l2e_p2mt)); - - if ( p2m_is_paged(l2e_p2mt) ) - { - put_gfn(pg_owner, l2egfn); - p2m_mem_paging_populate(pg_owner, l2egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l2e_p2mt && - !mfn_valid(l2emfn) ) - { - put_gfn(pg_owner, l2egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l2e_p2mt ) - { - put_gfn(pg_owner, l2egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - - rc = mod_l2_entry(va, l2e, mfn, + rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v); - put_gfn(pg_owner, l2egfn); - } - break; + break; case PGT_l3_page_table: - { - l3_pgentry_t l3e = l3e_from_intpte(req.val); - p2m_type_t l3e_p2mt; - unsigned long l3egfn = l3e_get_pfn(l3e), l3emfn; - - l3emfn = mfn_x(get_gfn(pg_owner, l3egfn, &l3e_p2mt)); - - if ( p2m_is_paged(l3e_p2mt) ) - { - put_gfn(pg_owner, l3egfn); - p2m_mem_paging_populate(pg_owner, l3egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l3e_p2mt && - !mfn_valid(l3emfn) ) - { - put_gfn(pg_owner, l3egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l3e_p2mt ) - { - put_gfn(pg_owner, l3egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - rc = mod_l3_entry(va, l3e, mfn, + rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v); - put_gfn(pg_owner, l3egfn); - } - break; + break; #if CONFIG_PAGING_LEVELS >= 4 case PGT_l4_page_table: - { - l4_pgentry_t l4e = l4e_from_intpte(req.val); - p2m_type_t l4e_p2mt; - unsigned long l4egfn = l4e_get_pfn(l4e), l4emfn; - - l4emfn = mfn_x(get_gfn(pg_owner, l4egfn, &l4e_p2mt)); - - if ( p2m_is_paged(l4e_p2mt) ) - { - put_gfn(pg_owner, l4egfn); - p2m_mem_paging_populate(pg_owner, l4egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_paging_in == l4e_p2mt && - !mfn_valid(l4emfn) ) - { - put_gfn(pg_owner, l4egfn); - rc = -ENOENT; - break; - } - else if ( p2m_ram_shared == l4e_p2mt ) - { - put_gfn(pg_owner, l4egfn); - MEM_LOG("Unexpected attempt to map shared page.\n"); - break; - } - - rc = mod_l4_entry(va, l4e, mfn, + rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, 1, v); - put_gfn(pg_owner, l4egfn); - } break; #endif case PGT_writable_page: @@ -3742,7 +3646,6 @@ int do_mmu_update( unmap_domain_page_with_cache(va, &mapcache); put_page(page); - put_gfn(pt_owner, gmfn); } break; @@ -3829,18 +3732,17 @@ static int create_grant_pte_mapping( adjust_guest_l1e(nl1e, d); gmfn = pte_addr >> PAGE_SHIFT; - mfn = get_gfn_untyped(d, gmfn); - - if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( unlikely(!page) ) { - put_gfn(d, gmfn); MEM_LOG("Could not get page for normal update"); return GNTST_general_error; } + mfn = page_to_mfn(page); va = map_domain_page(mfn); va = (void *)((unsigned long)va + ((unsigned long)pte_addr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( !page_lock(page) ) { @@ -3871,7 +3773,6 @@ static int create_grant_pte_mapping( failed: unmap_domain_page(va); put_page(page); - put_gfn(d, gmfn); return rc; } @@ -3886,18 +3787,17 @@ static int destroy_grant_pte_mapping( l1_pgentry_t ol1e; gmfn = addr >> PAGE_SHIFT; - mfn = get_gfn_untyped(d, gmfn); - - if ( unlikely(!get_page_from_pagenr(mfn, current->domain)) ) + page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC); + + if ( unlikely(!page) ) { - put_gfn(d, gmfn); MEM_LOG("Could not get page for normal update"); return GNTST_general_error; } + mfn = page_to_mfn(page); va = map_domain_page(mfn); va = (void *)((unsigned long)va + ((unsigned long)addr & ~PAGE_MASK)); - page = mfn_to_page(mfn); if ( !page_lock(page) ) { @@ -3942,7 +3842,6 @@ static int destroy_grant_pte_mapping( failed: unmap_domain_page(va); put_page(page); - put_gfn(d, gmfn); return rc; } @@ -4465,11 +4364,17 @@ long set_gdt(struct vcpu *v, /* Check the pages in the new GDT. */ for ( i = 0; i < nr_pages; i++ ) { + struct page_info *page; pfns[i] = frames[i]; - mfn = frames[i] = get_gfn_untyped(d, frames[i]); - if ( !mfn_valid(mfn) || - !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) ) + page = get_page_from_gfn(d, frames[i], NULL, P2M_ALLOC); + if ( !page ) goto fail; + if ( !get_page_type(page, PGT_seg_desc_page) ) + { + put_page(page); + goto fail; + } + mfn = frames[i] = page_to_mfn(page); } /* Tear down the old GDT. */ @@ -4482,7 +4387,6 @@ long set_gdt(struct vcpu *v, v->arch.pv_vcpu.gdt_frames[i] = frames[i]; l1e_write(&v->arch.perdomain_ptes[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR)); - put_gfn(d, pfns[i]); } xfree(pfns); @@ -4492,7 +4396,6 @@ long set_gdt(struct vcpu *v, while ( i-- > 0 ) { put_page_and_type(mfn_to_page(frames[i])); - put_gfn(d, pfns[i]); } xfree(pfns); return -EINVAL; @@ -4538,21 +4441,16 @@ long do_update_descriptor(u64 pa, u64 de *(u64 *)&d = desc; - mfn = get_gfn_untyped(dom, gmfn); + page = get_page_from_gfn(dom, gmfn, NULL, P2M_ALLOC); if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) || - !mfn_valid(mfn) || + !page || !check_descriptor(dom, &d) ) { - put_gfn(dom, gmfn); + if ( page ) + put_page(page); return -EINVAL; } - - page = mfn_to_page(mfn); - if ( unlikely(!get_page(page, dom)) ) - { - put_gfn(dom, gmfn); - return -EINVAL; - } + mfn = page_to_mfn(page); /* Check if the given frame is in use in an unsafe context. */ switch ( page->u.inuse.type_info & PGT_type_mask ) @@ -4580,7 +4478,6 @@ long do_update_descriptor(u64 pa, u64 de out: put_page(page); - put_gfn(dom, gmfn); return ret; } diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm/guest_walk.c --- a/xen/arch/x86/mm/guest_walk.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/guest_walk.c Thu May 10 15:54:16 2012 +0100 @@ -94,39 +94,37 @@ static inline void *map_domain_gfn(struc p2m_type_t *p2mt, uint32_t *rc) { - p2m_access_t p2ma; + struct page_info *page; void *map; /* Translate the gfn, unsharing if shared */ - *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), p2mt, NULL, + P2M_ALLOC | P2M_UNSHARE); if ( p2m_is_paging(*p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); - __put_gfn(p2m, gfn_x(gfn)); + if ( page ) + put_page(page); p2m_mem_paging_populate(p2m->domain, gfn_x(gfn)); *rc = _PAGE_PAGED; return NULL; } if ( p2m_is_shared(*p2mt) ) { - __put_gfn(p2m, gfn_x(gfn)); + if ( page ) + put_page(page); *rc = _PAGE_SHARED; return NULL; } - if ( !p2m_is_ram(*p2mt) ) + if ( !page ) { - __put_gfn(p2m, gfn_x(gfn)); *rc |= _PAGE_PRESENT; return NULL; } + *mfn = _mfn(page_to_mfn(page)); ASSERT(mfn_valid(mfn_x(*mfn))); - - /* Get an extra ref to the page to ensure liveness of the map. - * Then we can safely put gfn */ - page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn))); + map = map_domain_page(mfn_x(*mfn)); - __put_gfn(p2m, gfn_x(gfn)); return map; } diff -r 9da426cdc7e4 -r c68f83ff7bf4 xen/arch/x86/mm/hap/guest_walk.c --- a/xen/arch/x86/mm/hap/guest_walk.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm/hap/guest_walk.c Thu May 10 15:54:16 2012 +0100 @@ -54,34 +54,36 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA mfn_t top_mfn; void *top_map; p2m_type_t p2mt; - p2m_access_t p2ma; walk_t gw; unsigned long top_gfn; + struct page_info *top_page; /* Get the top-level table's MFN */ top_gfn = cr3 >> PAGE_SHIFT; - top_mfn = get_gfn_type_access(p2m, top_gfn, &p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + top_page = get_page_from_gfn_p2m(p2m->domain, p2m, top_gfn, + &p2mt, NULL, P2M_ALLOC | P2M_UNSHARE); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); pfec[0] = PFEC_page_paged; - __put_gfn(p2m, top_gfn); + if ( top_page ) + put_page(top_page); p2m_mem_paging_populate(p2m->domain, cr3 >> PAGE_SHIFT); return INVALID_GFN; } if ( p2m_is_shared(p2mt) ) { pfec[0] = PFEC_page_shared; - __put_gfn(p2m, top_gfn); + if ( top_page ) + put_page(top_page); return INVALID_GFN; } - if ( !p2m_is_ram(p2mt) ) + if ( !top_page ) { pfec[0] &= ~PFEC_page_present; - __put_gfn(p2m, top_gfn); return INVALID_GFN; } + top_mfn = _mfn(page_to_mfn(top_page)); /* Map the top-level table and call the tree-walker */ ASSERT(mfn_valid(mfn_x(top_mfn))); @@ -91,31 +93,30 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PA #endif missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map); unmap_domain_page(top_map); - __put_gfn(p2m, top_gfn); + put_page(top_page); /* Interpret the answer */ if ( missing == 0 ) { gfn_t gfn = guest_l1e_get_gfn(gw.l1e); - (void)get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma, - P2M_ALLOC | P2M_UNSHARE, NULL); + struct page_info *page; + page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt, + NULL, P2M_ALLOC | P2M_UNSHARE); + if ( page ) + put_page(page); if ( p2m_is_paging(p2mt) ) { ASSERT(!p2m_is_nestedp2m(p2m)); pfec[0] = PFEC_page_paged; - __put_gfn(p2m, gfn_x(gfn)); p2m_mem_paging_populate(p2m->domain, gfn_x(gfn)); return INVALID_GFN; } if ( p2m_is_shared(p2mt) ) { pfec[0] = PFEC_page_shared; - __put_gfn(p2m, gfn_x(gfn)); return INVALID_GFN; } - __put_gfn(p2m, gfn_x(gfn)); - if ( page_order ) *page_order = guest_walk_to_page_order(&gw); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0X-0001Mx-6E; Thu, 10 May 2012 15:10:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Lq-Eb for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:19 +0000 Received: from [85.158.138.51:48323] by server-11.bemta-3.messagelabs.com id 68/51-18894-A5ADBAF4; Thu, 10 May 2012 15:10:18 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1336662615!26333110!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14620 invoked from network); 10 May 2012 15:10:17 -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; 10 May 2012 15:10:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276901" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:57 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:57 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pt-QL; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwG-0000KJ-FI; Thu, 10 May 2012 16:05:56 +0100 MIME-Version: 1.0 X-Mercurial-Node: d95f0fb6c358f7e2624d317da6e405e8d733603a Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:55 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 11 of 11] x86/p2m, arm/p2m: remove get_gfn_untyped() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d95f0fb6c358f7e2624d317da6e405e8d733603a # Parent 65768e16352c6bb0e11bb6c661da5137e99ecceb x86/p2m, arm/p2m: remove get_gfn_untyped(). Adjust its only user to use get_gfn. Signed-off-by: Andres Lagar-Cavilla Signed-off-by: Tim Deegan diff -r 65768e16352c -r d95f0fb6c358 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 @@ -4524,6 +4524,7 @@ static int xenmem_add_to_physmap_once( unsigned long gfn = 0; /* gcc ... */ unsigned long prev_mfn, mfn = 0, gpfn, idx; int rc; + p2m_type_t p2mt; switch ( xatp->space ) { @@ -4596,7 +4597,7 @@ static int xenmem_add_to_physmap_once( put_page(page); /* Remove previously mapped page if it was present. */ - prev_mfn = get_gfn_untyped(d, xatp->gpfn); + prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt)); if ( mfn_valid(prev_mfn) ) { if ( is_xen_heap_mfn(prev_mfn) ) diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-arm/p2m.h --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -75,12 +75,6 @@ static inline struct page_info *get_page return page; } -/* 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, diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -339,17 +339,6 @@ static inline mfn_t get_gfn_type(struct #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \ P2M_ALLOC | P2M_UNSHARE) -/* Compatibility function exporting the old untyped interface */ -static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) -{ - mfn_t mfn; - p2m_type_t t; - mfn = get_gfn(d, gpfn, &t); - if ( p2m_is_valid(t) ) - return mfn_x(mfn); - return INVALID_MFN; -} - /* Will release the p2m_lock for this gfn entry. */ void __put_gfn(struct p2m_domain *p2m, unsigned long gfn); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0X-0001Mx-6E; Thu, 10 May 2012 15:10:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0V-0001Lq-Eb for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:19 +0000 Received: from [85.158.138.51:48323] by server-11.bemta-3.messagelabs.com id 68/51-18894-A5ADBAF4; Thu, 10 May 2012 15:10:18 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-4.tower-174.messagelabs.com!1336662615!26333110!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14620 invoked from network); 10 May 2012 15:10:17 -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; 10 May 2012 15:10:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194276901" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:05:57 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:05:57 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwG-0007Pt-QL; Thu, 10 May 2012 16:05:56 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwG-0000KJ-FI; Thu, 10 May 2012 16:05:56 +0100 MIME-Version: 1.0 X-Mercurial-Node: d95f0fb6c358f7e2624d317da6e405e8d733603a Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:55 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 11 of 11] x86/p2m, arm/p2m: remove get_gfn_untyped() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID d95f0fb6c358f7e2624d317da6e405e8d733603a # Parent 65768e16352c6bb0e11bb6c661da5137e99ecceb x86/p2m, arm/p2m: remove get_gfn_untyped(). Adjust its only user to use get_gfn. Signed-off-by: Andres Lagar-Cavilla Signed-off-by: Tim Deegan diff -r 65768e16352c -r d95f0fb6c358 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 @@ -4524,6 +4524,7 @@ static int xenmem_add_to_physmap_once( unsigned long gfn = 0; /* gcc ... */ unsigned long prev_mfn, mfn = 0, gpfn, idx; int rc; + p2m_type_t p2mt; switch ( xatp->space ) { @@ -4596,7 +4597,7 @@ static int xenmem_add_to_physmap_once( put_page(page); /* Remove previously mapped page if it was present. */ - prev_mfn = get_gfn_untyped(d, xatp->gpfn); + prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt)); if ( mfn_valid(prev_mfn) ) { if ( is_xen_heap_mfn(prev_mfn) ) diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-arm/p2m.h --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -75,12 +75,6 @@ static inline struct page_info *get_page return page; } -/* 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, diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-x86/p2m.h --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 @@ -339,17 +339,6 @@ static inline mfn_t get_gfn_type(struct #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \ P2M_ALLOC | P2M_UNSHARE) -/* Compatibility function exporting the old untyped interface */ -static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) -{ - mfn_t mfn; - p2m_type_t t; - mfn = get_gfn(d, gpfn, &t); - if ( p2m_is_valid(t) ) - return mfn_x(mfn); - return INVALID_MFN; -} - /* Will release the p2m_lock for this gfn entry. */ void __put_gfn(struct p2m_domain *p2m, unsigned long gfn); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV0y-0001aA-Ml; Thu, 10 May 2012 15:10:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0x-0001Yp-CI for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:47 +0000 Received: from [85.158.143.99:20857] by server-2.bemta-4.messagelabs.com id AA/F5-17550-67ADBAF4; Thu, 10 May 2012 15:10:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336662645!19864850!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13434 invoked from network); 10 May 2012 15:10:45 -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; 10 May 2012 15:10:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410803" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:10: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, 10 May 2012 16:10:11 +0100 Message-ID: <1336662609.14220.12.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 10 May 2012 16:10:09 +0100 In-Reply-To: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> <20120510144353.GJ26152@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-arm@lists.xen.org" , "xen-users@lists.xen.org" , Lars Kurth , "xen-devel@lists.xen.org" , "xen-api@lists.xen.org" Subject: Re: [Xen-devel] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:43 +0100, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > > Hi everybody, > > > > we have another Xen Documentation Day come up next Monday, April 23. > > When is the next one? I am itching to write some new docs! http://wiki.xen.org/wiki/Xen_Document_Days says "last Monday of each month" and names May 28 as the next one. There's nothing stopping you writing docs on the other N-1 days of the month ;-) Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:10:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV0y-0001aA-Ml; Thu, 10 May 2012 15:10:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV0x-0001Yp-CI for xen-devel@lists.xen.org; Thu, 10 May 2012 15:10:47 +0000 Received: from [85.158.143.99:20857] by server-2.bemta-4.messagelabs.com id AA/F5-17550-67ADBAF4; Thu, 10 May 2012 15:10:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336662645!19864850!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13434 invoked from network); 10 May 2012 15:10:45 -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; 10 May 2012 15:10:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12410803" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:10: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, 10 May 2012 16:10:11 +0100 Message-ID: <1336662609.14220.12.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 10 May 2012 16:10:09 +0100 In-Reply-To: <20120510144353.GJ26152@phenom.dumpdata.com> References: <4F912F15.2030202@xen.org> <20120510144353.GJ26152@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-arm@lists.xen.org" , "xen-users@lists.xen.org" , Lars Kurth , "xen-devel@lists.xen.org" , "xen-api@lists.xen.org" Subject: Re: [Xen-devel] [Xen-API] Xen Documentation Day : April 23rd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:43 +0100, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 20, 2012 at 10:40:37AM +0100, Lars Kurth wrote: > > Hi everybody, > > > > we have another Xen Documentation Day come up next Monday, April 23. > > When is the next one? I am itching to write some new docs! http://wiki.xen.org/wiki/Xen_Document_Days says "last Monday of each month" and names May 28 as the next one. There's nothing stopping you writing docs on the other N-1 days of the month ;-) Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:16:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV5v-0002iQ-G2; Thu, 10 May 2012 15:15:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV5u-0002iG-Gh for xen-devel@lists.xen.org; Thu, 10 May 2012 15:15:54 +0000 Received: from [85.158.139.83:42112] by server-11.bemta-5.messagelabs.com id A7/1D-12959-9ABDBAF4; Thu, 10 May 2012 15:15:53 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336662952!24990747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31858 invoked from network); 10 May 2012 15:15:53 -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; 10 May 2012 15:15:53 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:15:52 +0100 Message-Id: <4FABF7DD0200007800082C7E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:16:13 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/4] linux-2.6.18/gntdev: various adjustments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 1: fix VM_FOREIGN users after c/s 878:eba6fe6d8d53 2: gntdev: fix multi-page slot allocation 3: gntdev: adjust indentation (and fix bugs noticed by doing so) 4: gntdev: misc cleanup Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:16:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV5v-0002iQ-G2; Thu, 10 May 2012 15:15:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV5u-0002iG-Gh for xen-devel@lists.xen.org; Thu, 10 May 2012 15:15:54 +0000 Received: from [85.158.139.83:42112] by server-11.bemta-5.messagelabs.com id A7/1D-12959-9ABDBAF4; Thu, 10 May 2012 15:15:53 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336662952!24990747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31858 invoked from network); 10 May 2012 15:15:53 -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; 10 May 2012 15:15:53 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:15:52 +0100 Message-Id: <4FABF7DD0200007800082C7E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:16:13 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/4] linux-2.6.18/gntdev: various adjustments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 1: fix VM_FOREIGN users after c/s 878:eba6fe6d8d53 2: gntdev: fix multi-page slot allocation 3: gntdev: adjust indentation (and fix bugs noticed by doing so) 4: gntdev: misc cleanup Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:16:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV6m-0002oR-Tv; Thu, 10 May 2012 15:16:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV6l-0002oH-I6 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:16:47 +0000 Received: from [85.158.139.83:53641] by server-9.bemta-5.messagelabs.com id E9/A1-09826-EDBDBAF4; Thu, 10 May 2012 15:16:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336663004!27621628!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8471 invoked from network); 10 May 2012 15:16:45 -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; 10 May 2012 15:16:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:16:44 +0100 Message-Id: <4FABF8120200007800082C87@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:17:06 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB59B5CE2.0__=" Subject: [Xen-devel] [PATCH 1/4] linux-2.6.18: fix VM_FOREIGN users after c/s 878:eba6fe6d8d53 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB59B5CE2.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The level of indirection got increased by the blktap2 changes, yet existing users were not properly updated. While c/s 901:9242c5b965c1 did so for a specific case in blktap, this was incomplete and left out gntdev altogether. Signed-off-by: Jan Beulich --- a/drivers/xen/blktap/blktap.c +++ b/drivers/xen/blktap/blktap.c @@ -120,7 +120,7 @@ typedef struct tap_blkif { [req id, idx] tuple = */ blkif_t *blkif; /*Associate blkif with tapdev = */ struct domid_translate_ext trans; /*Translation from domid to bus. = */ - struct vm_foreign_map foreign_map; /*Mapping page */ + struct vm_foreign_map *foreign_maps; /*Mapping pages = */ } tap_blkif_t; =20 static struct tap_blkif *tapfds[MAX_TAP_DEV]; @@ -329,7 +329,7 @@ static pte_t blktap_clear_pte(struct vm_ =20 pg =3D idx_to_page(mmap_idx, pending_idx, seg); ClearPageReserved(pg); - info->foreign_map.map[offset + RING_PAGES] =3D NULL; + info->foreign_maps->map[offset + RING_PAGES] =3D NULL; =20 khandle =3D &pending_handle(mmap_idx, pending_idx, seg); =20 @@ -377,12 +377,17 @@ static pte_t blktap_clear_pte(struct vm_ static void blktap_vma_open(struct vm_area_struct *vma) { tap_blkif_t *info; + unsigned long idx; + struct vm_foreign_map *foreign_map; + if (vma->vm_file =3D=3D NULL) return; =20 info =3D vma->vm_file->private_data; - vma->vm_private_data =3D - &info->foreign_map.map[(vma->vm_start - info->rings_vstart)= >> PAGE_SHIFT]; + idx =3D (vma->vm_start - info->rings_vstart) >> PAGE_SHIFT; + foreign_map =3D &info->foreign_maps[idx]; + foreign_map->map =3D &info->foreign_maps->map[idx]; + vma->vm_private_data =3D foreign_map; } =20 /* tricky part @@ -392,7 +397,6 @@ static void blktap_vma_open(struct vm_ar */ static void blktap_vma_close(struct vm_area_struct *vma) { - tap_blkif_t *info; struct vm_area_struct *next =3D vma->vm_next; =20 if (next =3D=3D NULL || @@ -402,9 +406,7 @@ static void blktap_vma_close(struct vm_a vma->vm_file !=3D next->vm_file) return; =20 - info =3D vma->vm_file->private_data; - next->vm_private_data =3D - &info->foreign_map.map[(next->vm_start - info->rings_vstart= ) >> PAGE_SHIFT]; + blktap_vma_open(next); } =20 static struct vm_operations_struct blktap_vm_ops =3D { @@ -640,8 +642,9 @@ static int blktap_release(struct inode * mm =3D xchg(&info->mm, NULL); if (mm) mmput(mm); - kfree(info->foreign_map.map); - info->foreign_map.map =3D NULL; + kfree(info->foreign_maps->map); + kfree(info->foreign_maps); + info->foreign_maps =3D NULL; =20 /* Free the ring page. */ ClearPageReserved(virt_to_page(info->ufe_ring.sring)); @@ -730,14 +733,19 @@ static int blktap_mmap(struct file *filp } =20 /* Mark this VM as containing foreign pages, and set up mappings. = */ - info->foreign_map.map =3D kzalloc(((vma->vm_end - vma->vm_start) = >> PAGE_SHIFT) * - sizeof(*info->foreign_map.map), GFP_KERNEL); - if (info->foreign_map.map =3D=3D NULL) { + info->foreign_maps =3D kcalloc(size, sizeof(*info->foreign_maps), + GFP_KERNEL); + if (info->foreign_maps) + info->foreign_maps->map =3D + kcalloc(size, sizeof(*info->foreign_maps->map), + GFP_KERNEL); + if (!info->foreign_maps || !info->foreign_maps->map) { + kfree(info->foreign_maps); WPRINTK("Couldn't alloc VM_FOREIGN map.\n"); goto fail; } =20 - vma->vm_private_data =3D &info->foreign_map; + vma->vm_private_data =3D info->foreign_maps; vma->vm_flags |=3D VM_FOREIGN; vma->vm_flags |=3D VM_DONTCOPY; =20 @@ -1242,7 +1250,7 @@ static int blktap_read_ufe_ring(tap_blki pg =3D idx_to_page(mmap_idx, pending_idx, j); ClearPageReserved(pg); offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; - info->foreign_map.map[offset] =3D NULL; + info->foreign_maps->map[offset] =3D NULL; } fast_flush_area(pending_req, pending_idx, usr_idx, info); make_response(blkif, pending_req->id, res.operation, @@ -1530,7 +1538,7 @@ static void dispatch_rw_block_io(blkif_t FOREIGN_FRAME(map[i].dev_bus_ad= dr >> PAGE_SHIFT)); offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; - info->foreign_map.map[offset] =3D pg; + info->foreign_maps->map[offset] =3D pg; } } else { for (i =3D 0; i < nseg; i++) { @@ -1556,7 +1564,7 @@ static void dispatch_rw_block_io(blkif_t =20 offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; pg =3D idx_to_page(mmap_idx, pending_idx, i); - info->foreign_map.map[offset] =3D pg; + info->foreign_maps->map[offset] =3D pg; } } =20 --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -459,6 +459,7 @@ static int gntdev_mmap (struct file *fli int i; struct page *page; gntdev_file_private_data_t *private_data =3D flip->private_data; + struct vm_foreign_map *foreign_map; =20 if (unlikely(!private_data)) { printk(KERN_ERR "File's private data is NULL.\n"); @@ -487,6 +488,14 @@ static int gntdev_mmap (struct file *fli return -EINVAL; } =20 + foreign_map =3D kmalloc(sizeof(*foreign_map), GFP_KERNEL); + if (!foreign_map) { + printk(KERN_ERR "Couldn't allocate mapping structure for = VM " + "area.\n"); + return -ENOMEM; + } + foreign_map->map =3D &private_data->foreign_pages[slot_index]; + /* Slots must be in the NOT_YET_MAPPED state. */ down_write(&private_data->grants_sem); for (i =3D 0; i < size; ++i) { @@ -496,6 +505,7 @@ static int gntdev_mmap (struct file *fli "state (%d).\n", slot_index + i,=20 private_data->grants[slot_index + i].state);= up_write(&private_data->grants_sem); + kfree(foreign_map); return -EINVAL; } } @@ -504,14 +514,8 @@ static int gntdev_mmap (struct file *fli vma->vm_ops =3D &gntdev_vmops; =20 /* The VM area contains pages from another VM. */ + vma->vm_private_data =3D foreign_map; vma->vm_flags |=3D VM_FOREIGN; - vma->vm_private_data =3D kzalloc(size * sizeof(struct page *), - GFP_KERNEL); - if (vma->vm_private_data =3D=3D NULL) { - printk(KERN_ERR "Couldn't allocate mapping structure for = VM " - "area.\n"); - return -ENOMEM; - } =20 /* This flag prevents Bad PTE errors when the memory is unmapped. = */ vma->vm_flags |=3D VM_RESERVED; @@ -567,11 +571,6 @@ static int gntdev_mmap (struct file *fli goto undo_map_out; } =20 - /* Store a reference to the page that will be mapped into = user - * space. - */ - ((struct page **) vma->vm_private_data)[i] =3D page; - /* Mark mapped page as reserved. */ SetPageReserved(page); =20 @@ -676,7 +675,8 @@ undo_map_out: * by do_mmap_pgoff(), which will eventually call gntdev_clear_pte(= ). * All we need to do here is free the vma_private_data. */ - kfree(vma->vm_private_data); + vma->vm_flags &=3D ~VM_FOREIGN; + kfree(foreign_map); =20 /* THIS IS VERY UNPLEASANT: do_mmap_pgoff() will set the vma->vm_fi= le * to NULL on failure. However, we need this in gntdev_clear_pte() = to @@ -780,9 +780,8 @@ static pte_t gntdev_clear_pte(struct vm_ /* "Destructor" for a VM area. */ static void gntdev_vma_close(struct vm_area_struct *vma) { - if (vma->vm_private_data) { + if (vma->vm_flags & VM_FOREIGN) kfree(vma->vm_private_data); - } } =20 /* Called when an ioctl is made on the device. --=__PartB59B5CE2.0__= Content-Type: text/plain; name="xen-foreign-map.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-foreign-map.patch" fix VM_FOREIGN users after c/s 878:eba6fe6d8d53=0A=0AThe level of = indirection got increased by the blktap2 changes, yet=0Aexisting users = were not properly updated. While c/s 901:9242c5b965c1=0Adid so for a = specific case in blktap, this was incomplete and left out=0Agntdev = altogether.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/blktap/blktap.c=0A+++ b/drivers/xen/blktap/blktap.c=0A@@ = -120,7 +120,7 @@ typedef struct tap_blkif {=0A = [req id, idx] tuple */=0A blkif_t *blkif; = /*Associate blkif with tapdev */=0A struct domid_transl= ate_ext trans; /*Translation from domid to bus. */=0A- struct = vm_foreign_map foreign_map; /*Mapping page */=0A+ struct vm_foreign_m= ap *foreign_maps; /*Mapping pages */=0A } tap_blkif_t;=0A = =0A static struct tap_blkif *tapfds[MAX_TAP_DEV];=0A@@ -329,7 +329,7 @@ = static pte_t blktap_clear_pte(struct vm_=0A =0A pg =3D idx_to_page(= mmap_idx, pending_idx, seg);=0A ClearPageReserved(pg);=0A- = info->foreign_map.map[offset + RING_PAGES] =3D NULL;=0A+ info->forei= gn_maps->map[offset + RING_PAGES] =3D NULL;=0A =0A khandle =3D = &pending_handle(mmap_idx, pending_idx, seg);=0A =0A@@ -377,12 +377,17 @@ = static pte_t blktap_clear_pte(struct vm_=0A static void blktap_vma_open(str= uct vm_area_struct *vma)=0A {=0A tap_blkif_t *info;=0A+ unsigned = long idx;=0A+ struct vm_foreign_map *foreign_map;=0A+=0A if = (vma->vm_file =3D=3D NULL)=0A return;=0A =0A info =3D vma->vm_fi= le->private_data;=0A- vma->vm_private_data =3D=0A- &info->fore= ign_map.map[(vma->vm_start - info->rings_vstart) >> PAGE_SHIFT];=0A+ = idx =3D (vma->vm_start - info->rings_vstart) >> PAGE_SHIFT;=0A+ foreign_map= =3D &info->foreign_maps[idx];=0A+ foreign_map->map =3D &info->foreign= _maps->map[idx];=0A+ vma->vm_private_data =3D foreign_map;=0A }=0A =0A = /* tricky part=0A@@ -392,7 +397,6 @@ static void blktap_vma_open(struct = vm_ar=0A */=0A static void blktap_vma_close(struct vm_area_struct = *vma)=0A {=0A- tap_blkif_t *info;=0A struct vm_area_struct *next =3D = vma->vm_next;=0A =0A if (next =3D=3D NULL ||=0A@@ -402,9 +406,7 @@ = static void blktap_vma_close(struct vm_a=0A vma->vm_file !=3D = next->vm_file)=0A return;=0A =0A- info =3D vma->vm_file->priv= ate_data;=0A- next->vm_private_data =3D=0A- &info->foreign_map.= map[(next->vm_start - info->rings_vstart) >> PAGE_SHIFT];=0A+ blktap_vma_= open(next);=0A }=0A =0A static struct vm_operations_struct blktap_vm_ops = =3D {=0A@@ -640,8 +642,9 @@ static int blktap_release(struct inode *=0A = mm =3D xchg(&info->mm, NULL);=0A if (mm)=0A mmput(mm);= =0A- kfree(info->foreign_map.map);=0A- info->foreign_map.map =3D = NULL;=0A+ kfree(info->foreign_maps->map);=0A+ kfree(info->foreign= _maps);=0A+ info->foreign_maps =3D NULL;=0A =0A /* Free the ring = page. */=0A ClearPageReserved(virt_to_page(info->ufe_ring.sring));=0A@@= -730,14 +733,19 @@ static int blktap_mmap(struct file *filp=0A = }=0A =0A /* Mark this VM as containing foreign pages, and set up = mappings. */=0A- info->foreign_map.map =3D kzalloc(((vma->vm_end - = vma->vm_start) >> PAGE_SHIFT) *=0A- sizeof(*info->f= oreign_map.map), GFP_KERNEL);=0A- if (info->foreign_map.map =3D=3D = NULL) {=0A+ info->foreign_maps =3D kcalloc(size, sizeof(*info->foreign_= maps),=0A+ GFP_KERNEL);=0A+ if = (info->foreign_maps)=0A+ info->foreign_maps->map =3D=0A+ = kcalloc(size, sizeof(*info->foreign_maps->map),=0A+ = GFP_KERNEL);=0A+ if (!info->foreign_maps || !info->foreign_m= aps->map) {=0A+ kfree(info->foreign_maps);=0A WPRINTK("Co= uldn't alloc VM_FOREIGN map.\n");=0A goto fail;=0A }=0A =0A- = vma->vm_private_data =3D &info->foreign_map;=0A+ vma->vm_private_dat= a =3D info->foreign_maps;=0A vma->vm_flags |=3D VM_FOREIGN;=0A = vma->vm_flags |=3D VM_DONTCOPY;=0A =0A@@ -1242,7 +1250,7 @@ static int = blktap_read_ufe_ring(tap_blki=0A pg =3D idx_to_page(= mmap_idx, pending_idx, j);=0A ClearPageReserved(pg);=0A = offset =3D (uvaddr - info->rings_vstart) >> PAGE_SHIFT;=0A-= info->foreign_map.map[offset] =3D NULL;=0A+ = info->foreign_maps->map[offset] =3D NULL;=0A }=0A = fast_flush_area(pending_req, pending_idx, usr_idx, info);=0A = make_response(blkif, pending_req->id, res.operation,=0A@@ -1530,7 +1538,7 = @@ static void dispatch_rw_block_io(blkif_t=0A = FOREIGN_FRAME(map[i].dev_bus_addr=0A = >> PAGE_SHIFT));=0A offset =3D (uvaddr = - info->rings_vstart) >> PAGE_SHIFT;=0A- info->forei= gn_map.map[offset] =3D pg;=0A+ info->foreign_maps->map[off= set] =3D pg;=0A }=0A } else {=0A for (i =3D = 0; i < nseg; i++) {=0A@@ -1556,7 +1564,7 @@ static void dispatch_rw_block_i= o(blkif_t=0A =0A offset =3D (uvaddr - info->rings_vs= tart) >> PAGE_SHIFT;=0A pg =3D idx_to_page(mmap_idx= , pending_idx, i);=0A- info->foreign_map.map[offset] =3D = pg;=0A+ info->foreign_maps->map[offset] =3D pg;=0A = }=0A }=0A =0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntde= v/gntdev.c=0A@@ -459,6 +459,7 @@ static int gntdev_mmap (struct file = *fli=0A int i;=0A struct page *page;=0A gntdev_file_private= _data_t *private_data =3D flip->private_data;=0A+ struct vm_foreign_m= ap *foreign_map;=0A =0A if (unlikely(!private_data)) {=0A = printk(KERN_ERR "File's private data is NULL.\n");=0A@@ -487,6 +488,14 @@ = static int gntdev_mmap (struct file *fli=0A return -EINVAL;=0A = }=0A =0A+ foreign_map =3D kmalloc(sizeof(*foreign_map), = GFP_KERNEL);=0A+ if (!foreign_map) {=0A+ printk(KERN_ERR = "Couldn't allocate mapping structure for VM "=0A+ = "area.\n");=0A+ return -ENOMEM;=0A+ }=0A+ foreign_map->map = =3D &private_data->foreign_pages[slot_index];=0A+=0A /* Slots must be = in the NOT_YET_MAPPED state. */=0A down_write(&private_data->grants_se= m);=0A for (i =3D 0; i < size; ++i) {=0A@@ -496,6 +505,7 @@ static int = gntdev_mmap (struct file *fli=0A "state = (%d).\n", slot_index + i, =0A private_data->grants= [slot_index + i].state);=0A up_write(&private_data->gra= nts_sem);=0A+ kfree(foreign_map);=0A = return -EINVAL;=0A }=0A }=0A@@ -504,14 +514,8 @@ static = int gntdev_mmap (struct file *fli=0A vma->vm_ops =3D &gntdev_vmops;=0A = =0A /* The VM area contains pages from another VM. */=0A+ vma->vm_pri= vate_data =3D foreign_map;=0A vma->vm_flags |=3D VM_FOREIGN;=0A- = vma->vm_private_data =3D kzalloc(size * sizeof(struct page *),=0A- = GFP_KERNEL);=0A- if (vma->vm_private_data =3D=3D = NULL) {=0A- printk(KERN_ERR "Couldn't allocate mapping = structure for VM "=0A- "area.\n");=0A- return = -ENOMEM;=0A- }=0A =0A /* This flag prevents Bad PTE errors when = the memory is unmapped. */=0A vma->vm_flags |=3D VM_RESERVED;=0A@@ = -567,11 +571,6 @@ static int gntdev_mmap (struct file *fli=0A = goto undo_map_out;=0A }=0A =0A- /* Store a = reference to the page that will be mapped into user=0A- * = space.=0A- */=0A- ((struct page **) vma->vm_private_d= ata)[i] =3D page;=0A-=0A /* Mark mapped page as reserved. = */=0A SetPageReserved(page);=0A =0A@@ -676,7 +675,8 @@ undo_map_o= ut:=0A * by do_mmap_pgoff(), which will eventually call gntdev_clear_pte(= ).=0A * All we need to do here is free the vma_private_data.=0A = */=0A- kfree(vma->vm_private_data);=0A+ vma->vm_flags &=3D = ~VM_FOREIGN;=0A+ kfree(foreign_map);=0A =0A /* THIS IS VERY = UNPLEASANT: do_mmap_pgoff() will set the vma->vm_file=0A * to NULL = on failure. However, we need this in gntdev_clear_pte() to=0A@@ -780,9 = +780,8 @@ static pte_t gntdev_clear_pte(struct vm_=0A /* "Destructor" for = a VM area.=0A */=0A static void gntdev_vma_close(struct vm_area_struct = *vma) {=0A- if (vma->vm_private_data) {=0A+ if (vma->vm_flags & = VM_FOREIGN)=0A kfree(vma->vm_private_data);=0A- }=0A }=0A = =0A /* Called when an ioctl is made on the device.=0A --=__PartB59B5CE2.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartB59B5CE2.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:16:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSV6m-0002oR-Tv; Thu, 10 May 2012 15:16:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV6l-0002oH-I6 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:16:47 +0000 Received: from [85.158.139.83:53641] by server-9.bemta-5.messagelabs.com id E9/A1-09826-EDBDBAF4; Thu, 10 May 2012 15:16:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336663004!27621628!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8471 invoked from network); 10 May 2012 15:16:45 -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; 10 May 2012 15:16:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:16:44 +0100 Message-Id: <4FABF8120200007800082C87@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:17:06 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB59B5CE2.0__=" Subject: [Xen-devel] [PATCH 1/4] linux-2.6.18: fix VM_FOREIGN users after c/s 878:eba6fe6d8d53 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB59B5CE2.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The level of indirection got increased by the blktap2 changes, yet existing users were not properly updated. While c/s 901:9242c5b965c1 did so for a specific case in blktap, this was incomplete and left out gntdev altogether. Signed-off-by: Jan Beulich --- a/drivers/xen/blktap/blktap.c +++ b/drivers/xen/blktap/blktap.c @@ -120,7 +120,7 @@ typedef struct tap_blkif { [req id, idx] tuple = */ blkif_t *blkif; /*Associate blkif with tapdev = */ struct domid_translate_ext trans; /*Translation from domid to bus. = */ - struct vm_foreign_map foreign_map; /*Mapping page */ + struct vm_foreign_map *foreign_maps; /*Mapping pages = */ } tap_blkif_t; =20 static struct tap_blkif *tapfds[MAX_TAP_DEV]; @@ -329,7 +329,7 @@ static pte_t blktap_clear_pte(struct vm_ =20 pg =3D idx_to_page(mmap_idx, pending_idx, seg); ClearPageReserved(pg); - info->foreign_map.map[offset + RING_PAGES] =3D NULL; + info->foreign_maps->map[offset + RING_PAGES] =3D NULL; =20 khandle =3D &pending_handle(mmap_idx, pending_idx, seg); =20 @@ -377,12 +377,17 @@ static pte_t blktap_clear_pte(struct vm_ static void blktap_vma_open(struct vm_area_struct *vma) { tap_blkif_t *info; + unsigned long idx; + struct vm_foreign_map *foreign_map; + if (vma->vm_file =3D=3D NULL) return; =20 info =3D vma->vm_file->private_data; - vma->vm_private_data =3D - &info->foreign_map.map[(vma->vm_start - info->rings_vstart)= >> PAGE_SHIFT]; + idx =3D (vma->vm_start - info->rings_vstart) >> PAGE_SHIFT; + foreign_map =3D &info->foreign_maps[idx]; + foreign_map->map =3D &info->foreign_maps->map[idx]; + vma->vm_private_data =3D foreign_map; } =20 /* tricky part @@ -392,7 +397,6 @@ static void blktap_vma_open(struct vm_ar */ static void blktap_vma_close(struct vm_area_struct *vma) { - tap_blkif_t *info; struct vm_area_struct *next =3D vma->vm_next; =20 if (next =3D=3D NULL || @@ -402,9 +406,7 @@ static void blktap_vma_close(struct vm_a vma->vm_file !=3D next->vm_file) return; =20 - info =3D vma->vm_file->private_data; - next->vm_private_data =3D - &info->foreign_map.map[(next->vm_start - info->rings_vstart= ) >> PAGE_SHIFT]; + blktap_vma_open(next); } =20 static struct vm_operations_struct blktap_vm_ops =3D { @@ -640,8 +642,9 @@ static int blktap_release(struct inode * mm =3D xchg(&info->mm, NULL); if (mm) mmput(mm); - kfree(info->foreign_map.map); - info->foreign_map.map =3D NULL; + kfree(info->foreign_maps->map); + kfree(info->foreign_maps); + info->foreign_maps =3D NULL; =20 /* Free the ring page. */ ClearPageReserved(virt_to_page(info->ufe_ring.sring)); @@ -730,14 +733,19 @@ static int blktap_mmap(struct file *filp } =20 /* Mark this VM as containing foreign pages, and set up mappings. = */ - info->foreign_map.map =3D kzalloc(((vma->vm_end - vma->vm_start) = >> PAGE_SHIFT) * - sizeof(*info->foreign_map.map), GFP_KERNEL); - if (info->foreign_map.map =3D=3D NULL) { + info->foreign_maps =3D kcalloc(size, sizeof(*info->foreign_maps), + GFP_KERNEL); + if (info->foreign_maps) + info->foreign_maps->map =3D + kcalloc(size, sizeof(*info->foreign_maps->map), + GFP_KERNEL); + if (!info->foreign_maps || !info->foreign_maps->map) { + kfree(info->foreign_maps); WPRINTK("Couldn't alloc VM_FOREIGN map.\n"); goto fail; } =20 - vma->vm_private_data =3D &info->foreign_map; + vma->vm_private_data =3D info->foreign_maps; vma->vm_flags |=3D VM_FOREIGN; vma->vm_flags |=3D VM_DONTCOPY; =20 @@ -1242,7 +1250,7 @@ static int blktap_read_ufe_ring(tap_blki pg =3D idx_to_page(mmap_idx, pending_idx, j); ClearPageReserved(pg); offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; - info->foreign_map.map[offset] =3D NULL; + info->foreign_maps->map[offset] =3D NULL; } fast_flush_area(pending_req, pending_idx, usr_idx, info); make_response(blkif, pending_req->id, res.operation, @@ -1530,7 +1538,7 @@ static void dispatch_rw_block_io(blkif_t FOREIGN_FRAME(map[i].dev_bus_ad= dr >> PAGE_SHIFT)); offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; - info->foreign_map.map[offset] =3D pg; + info->foreign_maps->map[offset] =3D pg; } } else { for (i =3D 0; i < nseg; i++) { @@ -1556,7 +1564,7 @@ static void dispatch_rw_block_io(blkif_t =20 offset =3D (uvaddr - info->rings_vstart) >> = PAGE_SHIFT; pg =3D idx_to_page(mmap_idx, pending_idx, i); - info->foreign_map.map[offset] =3D pg; + info->foreign_maps->map[offset] =3D pg; } } =20 --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -459,6 +459,7 @@ static int gntdev_mmap (struct file *fli int i; struct page *page; gntdev_file_private_data_t *private_data =3D flip->private_data; + struct vm_foreign_map *foreign_map; =20 if (unlikely(!private_data)) { printk(KERN_ERR "File's private data is NULL.\n"); @@ -487,6 +488,14 @@ static int gntdev_mmap (struct file *fli return -EINVAL; } =20 + foreign_map =3D kmalloc(sizeof(*foreign_map), GFP_KERNEL); + if (!foreign_map) { + printk(KERN_ERR "Couldn't allocate mapping structure for = VM " + "area.\n"); + return -ENOMEM; + } + foreign_map->map =3D &private_data->foreign_pages[slot_index]; + /* Slots must be in the NOT_YET_MAPPED state. */ down_write(&private_data->grants_sem); for (i =3D 0; i < size; ++i) { @@ -496,6 +505,7 @@ static int gntdev_mmap (struct file *fli "state (%d).\n", slot_index + i,=20 private_data->grants[slot_index + i].state);= up_write(&private_data->grants_sem); + kfree(foreign_map); return -EINVAL; } } @@ -504,14 +514,8 @@ static int gntdev_mmap (struct file *fli vma->vm_ops =3D &gntdev_vmops; =20 /* The VM area contains pages from another VM. */ + vma->vm_private_data =3D foreign_map; vma->vm_flags |=3D VM_FOREIGN; - vma->vm_private_data =3D kzalloc(size * sizeof(struct page *), - GFP_KERNEL); - if (vma->vm_private_data =3D=3D NULL) { - printk(KERN_ERR "Couldn't allocate mapping structure for = VM " - "area.\n"); - return -ENOMEM; - } =20 /* This flag prevents Bad PTE errors when the memory is unmapped. = */ vma->vm_flags |=3D VM_RESERVED; @@ -567,11 +571,6 @@ static int gntdev_mmap (struct file *fli goto undo_map_out; } =20 - /* Store a reference to the page that will be mapped into = user - * space. - */ - ((struct page **) vma->vm_private_data)[i] =3D page; - /* Mark mapped page as reserved. */ SetPageReserved(page); =20 @@ -676,7 +675,8 @@ undo_map_out: * by do_mmap_pgoff(), which will eventually call gntdev_clear_pte(= ). * All we need to do here is free the vma_private_data. */ - kfree(vma->vm_private_data); + vma->vm_flags &=3D ~VM_FOREIGN; + kfree(foreign_map); =20 /* THIS IS VERY UNPLEASANT: do_mmap_pgoff() will set the vma->vm_fi= le * to NULL on failure. However, we need this in gntdev_clear_pte() = to @@ -780,9 +780,8 @@ static pte_t gntdev_clear_pte(struct vm_ /* "Destructor" for a VM area. */ static void gntdev_vma_close(struct vm_area_struct *vma) { - if (vma->vm_private_data) { + if (vma->vm_flags & VM_FOREIGN) kfree(vma->vm_private_data); - } } =20 /* Called when an ioctl is made on the device. --=__PartB59B5CE2.0__= Content-Type: text/plain; name="xen-foreign-map.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-foreign-map.patch" fix VM_FOREIGN users after c/s 878:eba6fe6d8d53=0A=0AThe level of = indirection got increased by the blktap2 changes, yet=0Aexisting users = were not properly updated. While c/s 901:9242c5b965c1=0Adid so for a = specific case in blktap, this was incomplete and left out=0Agntdev = altogether.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/blktap/blktap.c=0A+++ b/drivers/xen/blktap/blktap.c=0A@@ = -120,7 +120,7 @@ typedef struct tap_blkif {=0A = [req id, idx] tuple */=0A blkif_t *blkif; = /*Associate blkif with tapdev */=0A struct domid_transl= ate_ext trans; /*Translation from domid to bus. */=0A- struct = vm_foreign_map foreign_map; /*Mapping page */=0A+ struct vm_foreign_m= ap *foreign_maps; /*Mapping pages */=0A } tap_blkif_t;=0A = =0A static struct tap_blkif *tapfds[MAX_TAP_DEV];=0A@@ -329,7 +329,7 @@ = static pte_t blktap_clear_pte(struct vm_=0A =0A pg =3D idx_to_page(= mmap_idx, pending_idx, seg);=0A ClearPageReserved(pg);=0A- = info->foreign_map.map[offset + RING_PAGES] =3D NULL;=0A+ info->forei= gn_maps->map[offset + RING_PAGES] =3D NULL;=0A =0A khandle =3D = &pending_handle(mmap_idx, pending_idx, seg);=0A =0A@@ -377,12 +377,17 @@ = static pte_t blktap_clear_pte(struct vm_=0A static void blktap_vma_open(str= uct vm_area_struct *vma)=0A {=0A tap_blkif_t *info;=0A+ unsigned = long idx;=0A+ struct vm_foreign_map *foreign_map;=0A+=0A if = (vma->vm_file =3D=3D NULL)=0A return;=0A =0A info =3D vma->vm_fi= le->private_data;=0A- vma->vm_private_data =3D=0A- &info->fore= ign_map.map[(vma->vm_start - info->rings_vstart) >> PAGE_SHIFT];=0A+ = idx =3D (vma->vm_start - info->rings_vstart) >> PAGE_SHIFT;=0A+ foreign_map= =3D &info->foreign_maps[idx];=0A+ foreign_map->map =3D &info->foreign= _maps->map[idx];=0A+ vma->vm_private_data =3D foreign_map;=0A }=0A =0A = /* tricky part=0A@@ -392,7 +397,6 @@ static void blktap_vma_open(struct = vm_ar=0A */=0A static void blktap_vma_close(struct vm_area_struct = *vma)=0A {=0A- tap_blkif_t *info;=0A struct vm_area_struct *next =3D = vma->vm_next;=0A =0A if (next =3D=3D NULL ||=0A@@ -402,9 +406,7 @@ = static void blktap_vma_close(struct vm_a=0A vma->vm_file !=3D = next->vm_file)=0A return;=0A =0A- info =3D vma->vm_file->priv= ate_data;=0A- next->vm_private_data =3D=0A- &info->foreign_map.= map[(next->vm_start - info->rings_vstart) >> PAGE_SHIFT];=0A+ blktap_vma_= open(next);=0A }=0A =0A static struct vm_operations_struct blktap_vm_ops = =3D {=0A@@ -640,8 +642,9 @@ static int blktap_release(struct inode *=0A = mm =3D xchg(&info->mm, NULL);=0A if (mm)=0A mmput(mm);= =0A- kfree(info->foreign_map.map);=0A- info->foreign_map.map =3D = NULL;=0A+ kfree(info->foreign_maps->map);=0A+ kfree(info->foreign= _maps);=0A+ info->foreign_maps =3D NULL;=0A =0A /* Free the ring = page. */=0A ClearPageReserved(virt_to_page(info->ufe_ring.sring));=0A@@= -730,14 +733,19 @@ static int blktap_mmap(struct file *filp=0A = }=0A =0A /* Mark this VM as containing foreign pages, and set up = mappings. */=0A- info->foreign_map.map =3D kzalloc(((vma->vm_end - = vma->vm_start) >> PAGE_SHIFT) *=0A- sizeof(*info->f= oreign_map.map), GFP_KERNEL);=0A- if (info->foreign_map.map =3D=3D = NULL) {=0A+ info->foreign_maps =3D kcalloc(size, sizeof(*info->foreign_= maps),=0A+ GFP_KERNEL);=0A+ if = (info->foreign_maps)=0A+ info->foreign_maps->map =3D=0A+ = kcalloc(size, sizeof(*info->foreign_maps->map),=0A+ = GFP_KERNEL);=0A+ if (!info->foreign_maps || !info->foreign_m= aps->map) {=0A+ kfree(info->foreign_maps);=0A WPRINTK("Co= uldn't alloc VM_FOREIGN map.\n");=0A goto fail;=0A }=0A =0A- = vma->vm_private_data =3D &info->foreign_map;=0A+ vma->vm_private_dat= a =3D info->foreign_maps;=0A vma->vm_flags |=3D VM_FOREIGN;=0A = vma->vm_flags |=3D VM_DONTCOPY;=0A =0A@@ -1242,7 +1250,7 @@ static int = blktap_read_ufe_ring(tap_blki=0A pg =3D idx_to_page(= mmap_idx, pending_idx, j);=0A ClearPageReserved(pg);=0A = offset =3D (uvaddr - info->rings_vstart) >> PAGE_SHIFT;=0A-= info->foreign_map.map[offset] =3D NULL;=0A+ = info->foreign_maps->map[offset] =3D NULL;=0A }=0A = fast_flush_area(pending_req, pending_idx, usr_idx, info);=0A = make_response(blkif, pending_req->id, res.operation,=0A@@ -1530,7 +1538,7 = @@ static void dispatch_rw_block_io(blkif_t=0A = FOREIGN_FRAME(map[i].dev_bus_addr=0A = >> PAGE_SHIFT));=0A offset =3D (uvaddr = - info->rings_vstart) >> PAGE_SHIFT;=0A- info->forei= gn_map.map[offset] =3D pg;=0A+ info->foreign_maps->map[off= set] =3D pg;=0A }=0A } else {=0A for (i =3D = 0; i < nseg; i++) {=0A@@ -1556,7 +1564,7 @@ static void dispatch_rw_block_i= o(blkif_t=0A =0A offset =3D (uvaddr - info->rings_vs= tart) >> PAGE_SHIFT;=0A pg =3D idx_to_page(mmap_idx= , pending_idx, i);=0A- info->foreign_map.map[offset] =3D = pg;=0A+ info->foreign_maps->map[offset] =3D pg;=0A = }=0A }=0A =0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntde= v/gntdev.c=0A@@ -459,6 +459,7 @@ static int gntdev_mmap (struct file = *fli=0A int i;=0A struct page *page;=0A gntdev_file_private= _data_t *private_data =3D flip->private_data;=0A+ struct vm_foreign_m= ap *foreign_map;=0A =0A if (unlikely(!private_data)) {=0A = printk(KERN_ERR "File's private data is NULL.\n");=0A@@ -487,6 +488,14 @@ = static int gntdev_mmap (struct file *fli=0A return -EINVAL;=0A = }=0A =0A+ foreign_map =3D kmalloc(sizeof(*foreign_map), = GFP_KERNEL);=0A+ if (!foreign_map) {=0A+ printk(KERN_ERR = "Couldn't allocate mapping structure for VM "=0A+ = "area.\n");=0A+ return -ENOMEM;=0A+ }=0A+ foreign_map->map = =3D &private_data->foreign_pages[slot_index];=0A+=0A /* Slots must be = in the NOT_YET_MAPPED state. */=0A down_write(&private_data->grants_se= m);=0A for (i =3D 0; i < size; ++i) {=0A@@ -496,6 +505,7 @@ static int = gntdev_mmap (struct file *fli=0A "state = (%d).\n", slot_index + i, =0A private_data->grants= [slot_index + i].state);=0A up_write(&private_data->gra= nts_sem);=0A+ kfree(foreign_map);=0A = return -EINVAL;=0A }=0A }=0A@@ -504,14 +514,8 @@ static = int gntdev_mmap (struct file *fli=0A vma->vm_ops =3D &gntdev_vmops;=0A = =0A /* The VM area contains pages from another VM. */=0A+ vma->vm_pri= vate_data =3D foreign_map;=0A vma->vm_flags |=3D VM_FOREIGN;=0A- = vma->vm_private_data =3D kzalloc(size * sizeof(struct page *),=0A- = GFP_KERNEL);=0A- if (vma->vm_private_data =3D=3D = NULL) {=0A- printk(KERN_ERR "Couldn't allocate mapping = structure for VM "=0A- "area.\n");=0A- return = -ENOMEM;=0A- }=0A =0A /* This flag prevents Bad PTE errors when = the memory is unmapped. */=0A vma->vm_flags |=3D VM_RESERVED;=0A@@ = -567,11 +571,6 @@ static int gntdev_mmap (struct file *fli=0A = goto undo_map_out;=0A }=0A =0A- /* Store a = reference to the page that will be mapped into user=0A- * = space.=0A- */=0A- ((struct page **) vma->vm_private_d= ata)[i] =3D page;=0A-=0A /* Mark mapped page as reserved. = */=0A SetPageReserved(page);=0A =0A@@ -676,7 +675,8 @@ undo_map_o= ut:=0A * by do_mmap_pgoff(), which will eventually call gntdev_clear_pte(= ).=0A * All we need to do here is free the vma_private_data.=0A = */=0A- kfree(vma->vm_private_data);=0A+ vma->vm_flags &=3D = ~VM_FOREIGN;=0A+ kfree(foreign_map);=0A =0A /* THIS IS VERY = UNPLEASANT: do_mmap_pgoff() will set the vma->vm_file=0A * to NULL = on failure. However, we need this in gntdev_clear_pte() to=0A@@ -780,9 = +780,8 @@ static pte_t gntdev_clear_pte(struct vm_=0A /* "Destructor" for = a VM area.=0A */=0A static void gntdev_vma_close(struct vm_area_struct = *vma) {=0A- if (vma->vm_private_data) {=0A+ if (vma->vm_flags & = VM_FOREIGN)=0A kfree(vma->vm_private_data);=0A- }=0A }=0A = =0A /* Called when an ioctl is made on the device.=0A --=__PartB59B5CE2.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartB59B5CE2.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:17:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:17:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV7S-0002sg-Bf; Thu, 10 May 2012 15:17:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV7Q-0002s2-9S for xen-devel@lists.xen.org; Thu, 10 May 2012 15:17:28 +0000 Received: from [85.158.139.83:20726] by server-7.bemta-5.messagelabs.com id 21/97-16195-50CDBAF4; Thu, 10 May 2012 15:17:25 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336663044!27737939!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19690 invoked from network); 10 May 2012 15:17:24 -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; 10 May 2012 15:17:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:17:23 +0100 Message-Id: <4FABF83A0200007800082C8B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:17:46 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part5A74B30A.0__=" Subject: [Xen-devel] [PATCH 2/4] linux-2.6.18/gntdev: fix multi-page slot allocation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5A74B30A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Any range with the first slot available would have got considered usable, as range_length never got reset when encountering an in-use slot. Additionally fold the two almost identical loops into a single instance, at once avoiding to go through both loops when start_index was zero even for the first one. Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -285,35 +285,27 @@ static void compress_free_list(gntdev_fi static int find_contiguous_free_range(gntdev_file_private_data_t = *private_data, uint32_t num_slots)=20 { - uint32_t i, start_index =3D private_data->next_fit_index; - uint32_t range_start =3D 0, range_length; - - /* First search from the start_index to the end of the array. */ - range_length =3D 0; - for (i =3D start_index; i < private_data->grants_size; ++i) { - if (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALI= D) { - if (range_length =3D=3D 0) { - range_start =3D i; - } - ++range_length; - if (range_length =3D=3D num_slots) { - return range_start; - } - } - } -=09 - /* Now search from the start of the array to the start_index. */ - range_length =3D 0; - for (i =3D 0; i < start_index; ++i) { - if (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALI= D) { - if (range_length =3D=3D 0) { - range_start =3D i; - } - ++range_length; - if (range_length =3D=3D num_slots) { - return range_start; - } - } + /* First search from next_fit_index to the end of the array. */ + uint32_t start_index =3D private_data->next_fit_index; + uint32_t end_index =3D private_data->grants_size; + + for (;;) { + uint32_t i, range_start =3D 0, range_length =3D 0; + + for (i =3D start_index; i < end_index; ++i) { + if (private_data->grants[i].state =3D=3D GNTDEV_SLO= T_INVALID) { + if (range_length =3D=3D 0) + range_start =3D i; + if (++range_length =3D=3D num_slots) + return range_start; + } else + range_length =3D 0; + } + /* Now search from the start of the array to next_fit_index= . */ + if (!start_index) + break; + end_index =3D start_index; + start_index =3D 0; } =09 return -ENOMEM; --=__Part5A74B30A.0__= Content-Type: text/plain; name="xen-gntdev-multi-page.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-multi-page.patch" gntdev: fix multi-page slot allocation=0A=0AAny range with the first slot = available would have got considered=0Ausable, as range_length never got = reset when encountering an in-use=0Aslot.=0A=0AAdditionally fold the two = almost identical loops into a single=0Ainstance, at once avoiding to go = through both loops when start_index=0Awas zero even for the first = one.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ = -285,35 +285,27 @@ static void compress_free_list(gntdev_fi=0A static int = find_contiguous_free_range(gntdev_file_private_data_t *private_data,=0A = uint32_t num_slots) =0A {=0A- uint32_t = i, start_index =3D private_data->next_fit_index;=0A- uint32_t range_star= t =3D 0, range_length;=0A-=0A- /* First search from the start_index to = the end of the array. */=0A- range_length =3D 0;=0A- for (i =3D = start_index; i < private_data->grants_size; ++i) {=0A- if = (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALID) {=0A- = if (range_length =3D=3D 0) {=0A- = range_start =3D i;=0A- }=0A- ++range_len= gth;=0A- if (range_length =3D=3D num_slots) {=0A- = return range_start;=0A- }=0A- = }=0A- }=0A- =0A- /* Now search from the start of the array to the = start_index. */=0A- range_length =3D 0;=0A- for (i =3D 0; i < = start_index; ++i) {=0A- if (private_data->grants[i].state =3D=3D = GNTDEV_SLOT_INVALID) {=0A- if (range_length =3D=3D 0) = {=0A- range_start =3D i;=0A- = }=0A- ++range_length;=0A- if = (range_length =3D=3D num_slots) {=0A- return = range_start;=0A- }=0A- }=0A+ /* First = search from next_fit_index to the end of the array. */=0A+ uint32_t = start_index =3D private_data->next_fit_index;=0A+ uint32_t end_index = =3D private_data->grants_size;=0A+=0A+ for (;;) {=0A+ uint32_t = i, range_start =3D 0, range_length =3D 0;=0A+=0A+ for (i =3D = start_index; i < end_index; ++i) {=0A+ if (private_data->g= rants[i].state =3D=3D GNTDEV_SLOT_INVALID) {=0A+ = if (range_length =3D=3D 0)=0A+ range_start= =3D i;=0A+ if (++range_length =3D=3D = num_slots)=0A+ return range_start;=0A+ = } else=0A+ range_length =3D 0;=0A+ = }=0A+ /* Now search from the start of the array to next_fit_index= . */=0A+ if (!start_index)=0A+ break;=0A+ = end_index =3D start_index;=0A+ start_index =3D 0;=0A = }=0A =0A return -ENOMEM;=0A --=__Part5A74B30A.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part5A74B30A.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:17:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:17:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV7S-0002sg-Bf; Thu, 10 May 2012 15:17:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV7Q-0002s2-9S for xen-devel@lists.xen.org; Thu, 10 May 2012 15:17:28 +0000 Received: from [85.158.139.83:20726] by server-7.bemta-5.messagelabs.com id 21/97-16195-50CDBAF4; Thu, 10 May 2012 15:17:25 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336663044!27737939!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19690 invoked from network); 10 May 2012 15:17:24 -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; 10 May 2012 15:17:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:17:23 +0100 Message-Id: <4FABF83A0200007800082C8B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:17:46 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part5A74B30A.0__=" Subject: [Xen-devel] [PATCH 2/4] linux-2.6.18/gntdev: fix multi-page slot allocation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5A74B30A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Any range with the first slot available would have got considered usable, as range_length never got reset when encountering an in-use slot. Additionally fold the two almost identical loops into a single instance, at once avoiding to go through both loops when start_index was zero even for the first one. Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -285,35 +285,27 @@ static void compress_free_list(gntdev_fi static int find_contiguous_free_range(gntdev_file_private_data_t = *private_data, uint32_t num_slots)=20 { - uint32_t i, start_index =3D private_data->next_fit_index; - uint32_t range_start =3D 0, range_length; - - /* First search from the start_index to the end of the array. */ - range_length =3D 0; - for (i =3D start_index; i < private_data->grants_size; ++i) { - if (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALI= D) { - if (range_length =3D=3D 0) { - range_start =3D i; - } - ++range_length; - if (range_length =3D=3D num_slots) { - return range_start; - } - } - } -=09 - /* Now search from the start of the array to the start_index. */ - range_length =3D 0; - for (i =3D 0; i < start_index; ++i) { - if (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALI= D) { - if (range_length =3D=3D 0) { - range_start =3D i; - } - ++range_length; - if (range_length =3D=3D num_slots) { - return range_start; - } - } + /* First search from next_fit_index to the end of the array. */ + uint32_t start_index =3D private_data->next_fit_index; + uint32_t end_index =3D private_data->grants_size; + + for (;;) { + uint32_t i, range_start =3D 0, range_length =3D 0; + + for (i =3D start_index; i < end_index; ++i) { + if (private_data->grants[i].state =3D=3D GNTDEV_SLO= T_INVALID) { + if (range_length =3D=3D 0) + range_start =3D i; + if (++range_length =3D=3D num_slots) + return range_start; + } else + range_length =3D 0; + } + /* Now search from the start of the array to next_fit_index= . */ + if (!start_index) + break; + end_index =3D start_index; + start_index =3D 0; } =09 return -ENOMEM; --=__Part5A74B30A.0__= Content-Type: text/plain; name="xen-gntdev-multi-page.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-multi-page.patch" gntdev: fix multi-page slot allocation=0A=0AAny range with the first slot = available would have got considered=0Ausable, as range_length never got = reset when encountering an in-use=0Aslot.=0A=0AAdditionally fold the two = almost identical loops into a single=0Ainstance, at once avoiding to go = through both loops when start_index=0Awas zero even for the first = one.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ = -285,35 +285,27 @@ static void compress_free_list(gntdev_fi=0A static int = find_contiguous_free_range(gntdev_file_private_data_t *private_data,=0A = uint32_t num_slots) =0A {=0A- uint32_t = i, start_index =3D private_data->next_fit_index;=0A- uint32_t range_star= t =3D 0, range_length;=0A-=0A- /* First search from the start_index to = the end of the array. */=0A- range_length =3D 0;=0A- for (i =3D = start_index; i < private_data->grants_size; ++i) {=0A- if = (private_data->grants[i].state =3D=3D GNTDEV_SLOT_INVALID) {=0A- = if (range_length =3D=3D 0) {=0A- = range_start =3D i;=0A- }=0A- ++range_len= gth;=0A- if (range_length =3D=3D num_slots) {=0A- = return range_start;=0A- }=0A- = }=0A- }=0A- =0A- /* Now search from the start of the array to the = start_index. */=0A- range_length =3D 0;=0A- for (i =3D 0; i < = start_index; ++i) {=0A- if (private_data->grants[i].state =3D=3D = GNTDEV_SLOT_INVALID) {=0A- if (range_length =3D=3D 0) = {=0A- range_start =3D i;=0A- = }=0A- ++range_length;=0A- if = (range_length =3D=3D num_slots) {=0A- return = range_start;=0A- }=0A- }=0A+ /* First = search from next_fit_index to the end of the array. */=0A+ uint32_t = start_index =3D private_data->next_fit_index;=0A+ uint32_t end_index = =3D private_data->grants_size;=0A+=0A+ for (;;) {=0A+ uint32_t = i, range_start =3D 0, range_length =3D 0;=0A+=0A+ for (i =3D = start_index; i < end_index; ++i) {=0A+ if (private_data->g= rants[i].state =3D=3D GNTDEV_SLOT_INVALID) {=0A+ = if (range_length =3D=3D 0)=0A+ range_start= =3D i;=0A+ if (++range_length =3D=3D = num_slots)=0A+ return range_start;=0A+ = } else=0A+ range_length =3D 0;=0A+ = }=0A+ /* Now search from the start of the array to next_fit_index= . */=0A+ if (!start_index)=0A+ break;=0A+ = end_index =3D start_index;=0A+ start_index =3D 0;=0A = }=0A =0A return -ENOMEM;=0A --=__Part5A74B30A.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part5A74B30A.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:18:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV89-00030J-Vg; Thu, 10 May 2012 15:18:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV88-0002zz-7o for xen-devel@lists.xen.org; Thu, 10 May 2012 15:18:12 +0000 Received: from [85.158.139.83:39148] by server-12.bemta-5.messagelabs.com id 44/7A-01344-33CDBAF4; Thu, 10 May 2012 15:18:11 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336663089!27169730!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22599 invoked from network); 10 May 2012 15:18:09 -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; 10 May 2012 15:18:09 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:18:09 +0100 Message-Id: <4FABF8670200007800082C8F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:18:31 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part0729EE57.0__=" Subject: [Xen-devel] [PATCH 3/4] linux-2.6.18/gntdev: adjust indentation (and fix bugs noticed by doing so) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0729EE57.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline By inverting two conditions, indentation can be decreased by one level for large code portions, thus improving legibility. In gntdev_mmap(), this made obvious that failure of vm_insert_page() was silently ignored rather than being propagated to the caller. In gntdev_clear_pte(), the final set_phys_to_machine() must not be called for the auto-translated case. Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -607,85 +607,85 @@ static int gntdev_mmap (struct file *fli GNTDEV_INVALID_HANDLE; =20 /* Now perform the mapping to user space. */ - if (!xen_feature(XENFEAT_auto_translated_physmap)) { - - /* NOT USING SHADOW PAGE TABLES. */ - /* In this case, we map the grant(s) straight into = user - * space. - */ - - /* Get the machine address of the PTE for the = user=20 - * page. - */ - if ((ret =3D create_lookup_pte_addr(vma->vm_mm,=20 - vma->vm_start=20 - + (i << = PAGE_SHIFT),=20 - &ptep))) - { - printk(KERN_ERR "Error obtaining PTE = pointer " - "(%d).\n", ret); - goto undo_map_out; - } - =09 - /* Configure the map operation. */ - =09 - /* The reference is to be used by host CPUs. */ - flags =3D GNTMAP_host_map; - =09 - /* Specifies a user space mapping. */ - flags |=3D GNTMAP_application_map; - =09 - /* The map request contains the machine address of = the - * PTE to update. - */ - flags |=3D GNTMAP_contains_pte; - =09 - if (!(vma->vm_flags & VM_WRITE)) - flags |=3D GNTMAP_readonly; - - gnttab_set_map_op(&op, ptep, flags,=20 - private_data->grants[slot_index+i= ] - .u.valid.ref,=20 - private_data->grants[slot_index+i= ] - .u.valid.domid); - - /* Carry out the mapping of the grant reference. = */ - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_gran= t_ref, - &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) { - printk(KERN_ERR "Error mapping the grant " - "reference into user space (%d). = domid " - "=3D %d; ref =3D %d\n", op.status, - private_data->grants[slot_index+i].u= - .valid.domid, - private_data->grants[slot_index+i].u= - .valid.ref); - /* This should never happen after we've = mapped into - * the kernel space. */ - BUG_ON(op.status =3D=3D GNTST_eagain); - goto undo_map_out; - } - =09 - /* Record the grant handle, for use in the = unmap=20 - * operation.=20 - */ - private_data->grants[slot_index+i].u. - valid.user_handle =3D op.handle; - - /* Update p2m structure with the new mapping. */ - set_phys_to_machine(__pa(kernel_vaddr) >> = PAGE_SHIFT, - FOREIGN_FRAME(private_data-> - grants[slot_index= +i] - .u.valid.dev_bus_= addr - >> PAGE_SHIFT)); - } else { + if (xen_feature(XENFEAT_auto_translated_physmap)) { /* USING SHADOW PAGE TABLES. */ /* In this case, we simply insert the page into = the VM * area. */ ret =3D vm_insert_page(vma, user_vaddr, page); + if (!ret) + continue; + exit_ret =3D ret; + goto undo_map_out; + } + + /* NOT USING SHADOW PAGE TABLES. */ + /* In this case, we map the grant(s) straight into user + * space. + */ + + /* Get the machine address of the PTE for the user page. = */ + if ((ret =3D create_lookup_pte_addr(vma->vm_mm, + vma->vm_start + + (i << PAGE_SHIFT), + &ptep))) + { + printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n", + ret); + goto undo_map_out; + } + + /* Configure the map operation. */ + + /* The reference is to be used by host CPUs. */ + flags =3D GNTMAP_host_map; + + /* Specifies a user space mapping. */ + flags |=3D GNTMAP_application_map; + + /* The map request contains the machine address of the + * PTE to update. + */ + flags |=3D GNTMAP_contains_pte; + + if (!(vma->vm_flags & VM_WRITE)) + flags |=3D GNTMAP_readonly; + + gnttab_set_map_op(&op, ptep, flags, + private_data->grants[slot_index+i] + .u.valid.ref, + private_data->grants[slot_index+i] + .u.valid.domid); + + /* Carry out the mapping of the grant reference. */ + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, + &op, 1); + BUG_ON(ret); + if (op.status !=3D GNTST_okay) { + printk(KERN_ERR "Error mapping the grant reference = " + "into user space (%d). domid =3D %d; ref = =3D %d\n", + op.status, + private_data->grants[slot_index+i].u + .valid.domid, + private_data->grants[slot_index+i].u + .valid.ref); + /* This should never happen after we've mapped = into + * the kernel space. */ + BUG_ON(op.status =3D=3D GNTST_eagain); + goto undo_map_out; } =20 + /* Record the grant handle, for use in the unmap + * operation. + */ + private_data->grants[slot_index+i].u.valid.user_handle + =3D op.handle; + + /* Update p2m structure with the new mapping. */ + set_phys_to_machine(__pa(kernel_vaddr) >> PAGE_SHIFT, + FOREIGN_FRAME(private_data-> + grants[slot_index+i] + .u.valid.dev_bus_addr + >> PAGE_SHIFT)); } exit_ret =3D 0; =20 @@ -745,55 +745,52 @@ static pte_t gntdev_clear_pte(struct vm_ /* Only unmap grants if the slot has been mapped. This could be = being * called from a failing mmap(). */ - if (private_data->grants[slot_index].state =3D=3D GNTDEV_SLOT_MAPPE= D) { - - /* First, we clear the user space mapping, if it has been = made. - */ - if (private_data->grants[slot_index].u.valid.user_handle = !=3D - GNTDEV_INVALID_HANDLE &&=20 - !xen_feature(XENFEAT_auto_translated_physmap)) { - /* NOT USING SHADOW PAGE TABLES. */ - gnttab_set_unmap_op(&op, ptep_to_machine(ptep),=20 - GNTMAP_contains_pte, - private_data->grants[slot_index= ] - .u.valid.user_handle); - ret =3D HYPERVISOR_grant_table_op( - GNTTABOP_unmap_grant_ref, &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("User unmap grant status =3D = %d\n",=20 - op.status); - } else { - /* USING SHADOW PAGE TABLES. */ - pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); - } + if (private_data->grants[slot_index].state !=3D GNTDEV_SLOT_MAPPED)= { + pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + return copy; + } =20 - /* Finally, we unmap the grant from kernel space. */ - gnttab_set_unmap_op(&op,=20 - get_kernel_vaddr(private_data, = slot_index), - GNTMAP_host_map,=20 + /* First, we clear the user space mapping, if it has been made. + */ + if (private_data->grants[slot_index].u.valid.user_handle !=3D + GNTDEV_INVALID_HANDLE && + !xen_feature(XENFEAT_auto_translated_physmap)) { + /* NOT USING SHADOW PAGE TABLES. */ + gnttab_set_unmap_op(&op, ptep_to_machine(ptep), + GNTMAP_contains_pte, private_data->grants[slot_index].u.vali= d - .kernel_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= =20 + .user_handle); + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= &op, 1); BUG_ON(ret); if (op.status !=3D GNTST_okay) - printk("Kernel unmap grant status =3D %d\n", = op.status); + printk("User unmap grant status =3D %d\n", = op.status); + } else { + /* USING SHADOW PAGE TABLES. */ + pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + } =20 + /* Finally, we unmap the grant from kernel space. */ + gnttab_set_unmap_op(&op, + get_kernel_vaddr(private_data, slot_index), + GNTMAP_host_map, + private_data->grants[slot_index].u.valid + .kernel_handle); + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, = 1); + BUG_ON(ret); + if (op.status !=3D GNTST_okay) + printk("Kernel unmap grant status =3D %d\n", op.status); =20 - /* Return slot to the not-yet-mapped state, so that it may = be - * mapped again, or removed by a subsequent ioctl. - */ - private_data->grants[slot_index].state =3D=20 - GNTDEV_SLOT_NOT_YET_MAPPED; + /* Return slot to the not-yet-mapped state, so that it may be + * mapped again, or removed by a subsequent ioctl. + */ + private_data->grants[slot_index].state =3D GNTDEV_SLOT_NOT_YET_MAPP= ED; =20 + if (!xen_feature(XENFEAT_auto_translated_physmap)) { /* Invalidate the physical to machine mapping for this = page. */ set_phys_to_machine( page_to_pfn(private_data->foreign_pages[slot_index]= ), INVALID_P2M_ENTRY); - - } else { - pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); } =20 return copy; --=__Part0729EE57.0__= Content-Type: text/plain; name="xen-gntdev-indent.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-indent.patch" gntdev: adjust indentation (and fix bugs noticed by doing so)=0A=0ABy = inverting two conditions, indentation can be decreased by one level=0Afor = large code portions, thus improving legibility.=0A=0AIn gntdev_mmap(), = this made obvious that failure of vm_insert_page()=0Awas silently ignored = rather than being propagated to the caller.=0A=0AIn gntdev_clear_pte(), = the final set_phys_to_machine() must not be=0Acalled for the auto-translate= d case.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ = -607,85 +607,85 @@ static int gntdev_mmap (struct file *fli=0A = GNTDEV_INVALID_HANDLE;=0A =0A /* Now perform the mapping to user = space. */=0A- if (!xen_feature(XENFEAT_auto_translated_physmap)) = {=0A-=0A- /* NOT USING SHADOW PAGE TABLES. */=0A- = /* In this case, we map the grant(s) straight into user=0A- = * space.=0A- */=0A-=0A- /* = Get the machine address of the PTE for the user =0A- * = page.=0A- */=0A- if ((ret =3D = create_lookup_pte_addr(vma->vm_mm, =0A- = vma->vm_start =0A- = + (i << PAGE_SHIFT), =0A- = &ptep)))=0A- {=0A- printk(KERN= _ERR "Error obtaining PTE pointer "=0A- = "(%d).\n", ret);=0A- goto undo_map_out;=0A- = }=0A- =0A- /* Configure the = map operation. */=0A- =0A- /* The reference = is to be used by host CPUs. */=0A- flags =3D = GNTMAP_host_map;=0A- =0A- /* = Specifies a user space mapping. */=0A- flags |=3D = GNTMAP_application_map;=0A- =0A- /* = The map request contains the machine address of the=0A- * = PTE to update.=0A- */=0A- flags |=3D = GNTMAP_contains_pte;=0A- =0A- if = (!(vma->vm_flags & VM_WRITE))=0A- flags |=3D = GNTMAP_readonly;=0A-=0A- gnttab_set_map_op(&op, = ptep, flags, =0A- private_data->gra= nts[slot_index+i]=0A- .u.valid.ref, = =0A- private_data->grants[slot_index+i= ]=0A- .u.valid.domid);=0A-=0A- = /* Carry out the mapping of the grant reference. */=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,=0A- = &op, 1);=0A- BUG_ON(ret)= ;=0A- if (op.status !=3D GNTST_okay) {=0A- = printk(KERN_ERR "Error mapping the grant "=0A- = "reference into user space (%d). domid "=0A- = "=3D %d; ref =3D %d\n", op.status,=0A- = private_data->grants[slot_index+i].u=0A- = .valid.domid,=0A- private_data->grants= [slot_index+i].u=0A- .valid.ref);=0A- = /* This should never happen after we've mapped into=0A- = * the kernel space. */=0A- = BUG_ON(op.status =3D=3D GNTST_eagain);=0A- = goto undo_map_out;=0A- }=0A- =0A- = /* Record the grant handle, for use in the unmap =0A- = * operation. =0A- */=0A- private_dat= a->grants[slot_index+i].u.=0A- valid.user_handle = =3D op.handle;=0A-=0A- /* Update p2m structure with the = new mapping. */=0A- set_phys_to_machine(__pa(kernel_vad= dr) >> PAGE_SHIFT,=0A- FOREIGN_FRAME(p= rivate_data->=0A- = grants[slot_index+i]=0A- = .u.valid.dev_bus_addr=0A- = >> PAGE_SHIFT));=0A- } else {=0A+ if (xen_feature(XEN= FEAT_auto_translated_physmap)) {=0A /* USING SHADOW = PAGE TABLES. */=0A /* In this case, we simply insert = the page into the VM=0A * area. */=0A = ret =3D vm_insert_page(vma, user_vaddr, page);=0A+ if = (!ret)=0A+ continue;=0A+ = exit_ret =3D ret;=0A+ goto undo_map_out;=0A+ = }=0A+=0A+ /* NOT USING SHADOW PAGE TABLES. */=0A+ /* = In this case, we map the grant(s) straight into user=0A+ * = space.=0A+ */=0A+=0A+ /* Get the machine address = of the PTE for the user page. */=0A+ if ((ret =3D create_lookup_= pte_addr(vma->vm_mm,=0A+ = vma->vm_start=0A+ + (i << = PAGE_SHIFT),=0A+ = &ptep)))=0A+ {=0A+ printk(KERN_ERR "Error = obtaining PTE pointer (%d)\n",=0A+ ret);=0A+ = goto undo_map_out;=0A+ }=0A+=0A+ /* = Configure the map operation. */=0A+=0A+ /* The reference is to be = used by host CPUs. */=0A+ flags =3D GNTMAP_host_map;=0A+=0A+ = /* Specifies a user space mapping. */=0A+ flags |=3D = GNTMAP_application_map;=0A+=0A+ /* The map request contains the = machine address of the=0A+ * PTE to update.=0A+ = */=0A+ flags |=3D GNTMAP_contains_pte;=0A+=0A+ if = (!(vma->vm_flags & VM_WRITE))=0A+ flags |=3D = GNTMAP_readonly;=0A+=0A+ gnttab_set_map_op(&op, ptep, = flags,=0A+ private_data->grants[slot_index+i= ]=0A+ .u.valid.ref,=0A+ = private_data->grants[slot_index+i]=0A+ = .u.valid.domid);=0A+=0A+ /* Carry out the mapping of the = grant reference. */=0A+ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_= map_grant_ref,=0A+ &op, = 1);=0A+ BUG_ON(ret);=0A+ if (op.status !=3D = GNTST_okay) {=0A+ printk(KERN_ERR "Error mapping the = grant reference "=0A+ "into user space (%d). = domid =3D %d; ref =3D %d\n",=0A+ op.status,= =0A+ private_data->grants[slot_index+i].u=0A+ = .valid.domid,=0A+ private_data= ->grants[slot_index+i].u=0A+ .valid.ref);=0A+ = /* This should never happen after we've mapped into=0A+ = * the kernel space. */=0A+ BUG_ON(op.status =3D=3D = GNTST_eagain);=0A+ goto undo_map_out;=0A = }=0A =0A+ /* Record the grant handle, for use in the = unmap=0A+ * operation.=0A+ */=0A+ = private_data->grants[slot_index+i].u.valid.user_handle=0A+ = =3D op.handle;=0A+=0A+ /* Update p2m structure with the new = mapping. */=0A+ set_phys_to_machine(__pa(kernel_vaddr) >> = PAGE_SHIFT,=0A+ FOREIGN_FRAME(private_data->=0A= + grants[slot_index+i]=0A+ = .u.valid.dev_bus_addr=0A+ = >> PAGE_SHIFT));=0A }=0A exit_ret = =3D 0;=0A =0A@@ -745,55 +745,52 @@ static pte_t gntdev_clear_pte(struct = vm_=0A /* Only unmap grants if the slot has been mapped. This could be = being=0A * called from a failing mmap().=0A */=0A- if = (private_data->grants[slot_index].state =3D=3D GNTDEV_SLOT_MAPPED) = {=0A-=0A- /* First, we clear the user space mapping, if it = has been made.=0A- */=0A- if (private_data->grants[sl= ot_index].u.valid.user_handle !=3D=0A- GNTDEV_INVALID_HANDLE = && =0A- !xen_feature(XENFEAT_auto_translated_physmap)) {=0A- = /* NOT USING SHADOW PAGE TABLES. */=0A- = gnttab_set_unmap_op(&op, ptep_to_machine(ptep), =0A- = GNTMAP_contains_pte,=0A- = private_data->grants[slot_index]=0A- = .u.valid.user_handle);=0A- ret =3D HYPERVISOR_grant_ta= ble_op(=0A- GNTTABOP_unmap_grant_ref, &op, = 1);=0A- BUG_ON(ret);=0A- if = (op.status !=3D GNTST_okay)=0A- printk("User unmap = grant status =3D %d\n", =0A- op.status);= =0A- } else {=0A- /* USING SHADOW PAGE = TABLES. */=0A- pte_clear_full(vma->vm_mm, addr, ptep, = is_fullmm);=0A- }=0A+ if (private_data->grants[slot_index].state = !=3D GNTDEV_SLOT_MAPPED) {=0A+ pte_clear_full(vma->vm_mm, addr, = ptep, is_fullmm);=0A+ return copy;=0A+ }=0A =0A- = /* Finally, we unmap the grant from kernel space. */=0A- = gnttab_set_unmap_op(&op, =0A- get_kernel_vadd= r(private_data, slot_index),=0A- = GNTMAP_host_map, =0A+ /* First, we clear the user space mapping, if it = has been made.=0A+ */=0A+ if (private_data->grants[slot_index].u.vali= d.user_handle !=3D=0A+ GNTDEV_INVALID_HANDLE &&=0A+ = !xen_feature(XENFEAT_auto_translated_physmap)) {=0A+ /* NOT = USING SHADOW PAGE TABLES. */=0A+ gnttab_set_unmap_op(&op, = ptep_to_machine(ptep),=0A+ GNTMAP_contains= _pte,=0A private_data->grants[slot_index= ].u.valid=0A- .kernel_handle);=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, =0A+ = .user_handle);=0A+ ret =3D HYPERVISOR_grant_ta= ble_op(GNTTABOP_unmap_grant_ref,=0A = &op, 1);=0A BUG_ON(ret);=0A if (op.status !=3D = GNTST_okay)=0A- printk("Kernel unmap grant status =3D = %d\n", op.status);=0A+ printk("User unmap grant status = =3D %d\n", op.status);=0A+ } else {=0A+ /* USING SHADOW = PAGE TABLES. */=0A+ pte_clear_full(vma->vm_mm, addr, ptep, = is_fullmm);=0A+ }=0A =0A+ /* Finally, we unmap the grant from kernel = space. */=0A+ gnttab_set_unmap_op(&op,=0A+ = get_kernel_vaddr(private_data, slot_index),=0A+ = GNTMAP_host_map,=0A+ private_data->grants[slot_index= ].u.valid=0A+ .kernel_handle);=0A+ ret =3D = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);=0A+ = BUG_ON(ret);=0A+ if (op.status !=3D GNTST_okay)=0A+ = printk("Kernel unmap grant status =3D %d\n", op.status);=0A =0A- = /* Return slot to the not-yet-mapped state, so that it may be=0A- = * mapped again, or removed by a subsequent ioctl.=0A- */=0A- = private_data->grants[slot_index].state =3D =0A- GNTDEV_SLOT= _NOT_YET_MAPPED;=0A+ /* Return slot to the not-yet-mapped state, so = that it may be=0A+ * mapped again, or removed by a subsequent = ioctl.=0A+ */=0A+ private_data->grants[slot_index].state =3D = GNTDEV_SLOT_NOT_YET_MAPPED;=0A =0A+ if (!xen_feature(XENFEAT_auto_trans= lated_physmap)) {=0A /* Invalidate the physical to machine = mapping for this page. */=0A set_phys_to_machine(=0A = page_to_pfn(private_data->foreign_pages[slot_index]),=0A = INVALID_P2M_ENTRY);=0A-=0A- } else {=0A- pte_clear_f= ull(vma->vm_mm, addr, ptep, is_fullmm);=0A }=0A =0A return = copy;=0A --=__Part0729EE57.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part0729EE57.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:18:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV89-00030J-Vg; Thu, 10 May 2012 15:18:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV88-0002zz-7o for xen-devel@lists.xen.org; Thu, 10 May 2012 15:18:12 +0000 Received: from [85.158.139.83:39148] by server-12.bemta-5.messagelabs.com id 44/7A-01344-33CDBAF4; Thu, 10 May 2012 15:18:11 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1336663089!27169730!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22599 invoked from network); 10 May 2012 15:18:09 -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; 10 May 2012 15:18:09 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:18:09 +0100 Message-Id: <4FABF8670200007800082C8F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:18:31 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part0729EE57.0__=" Subject: [Xen-devel] [PATCH 3/4] linux-2.6.18/gntdev: adjust indentation (and fix bugs noticed by doing so) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0729EE57.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline By inverting two conditions, indentation can be decreased by one level for large code portions, thus improving legibility. In gntdev_mmap(), this made obvious that failure of vm_insert_page() was silently ignored rather than being propagated to the caller. In gntdev_clear_pte(), the final set_phys_to_machine() must not be called for the auto-translated case. Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -607,85 +607,85 @@ static int gntdev_mmap (struct file *fli GNTDEV_INVALID_HANDLE; =20 /* Now perform the mapping to user space. */ - if (!xen_feature(XENFEAT_auto_translated_physmap)) { - - /* NOT USING SHADOW PAGE TABLES. */ - /* In this case, we map the grant(s) straight into = user - * space. - */ - - /* Get the machine address of the PTE for the = user=20 - * page. - */ - if ((ret =3D create_lookup_pte_addr(vma->vm_mm,=20 - vma->vm_start=20 - + (i << = PAGE_SHIFT),=20 - &ptep))) - { - printk(KERN_ERR "Error obtaining PTE = pointer " - "(%d).\n", ret); - goto undo_map_out; - } - =09 - /* Configure the map operation. */ - =09 - /* The reference is to be used by host CPUs. */ - flags =3D GNTMAP_host_map; - =09 - /* Specifies a user space mapping. */ - flags |=3D GNTMAP_application_map; - =09 - /* The map request contains the machine address of = the - * PTE to update. - */ - flags |=3D GNTMAP_contains_pte; - =09 - if (!(vma->vm_flags & VM_WRITE)) - flags |=3D GNTMAP_readonly; - - gnttab_set_map_op(&op, ptep, flags,=20 - private_data->grants[slot_index+i= ] - .u.valid.ref,=20 - private_data->grants[slot_index+i= ] - .u.valid.domid); - - /* Carry out the mapping of the grant reference. = */ - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_gran= t_ref, - &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) { - printk(KERN_ERR "Error mapping the grant " - "reference into user space (%d). = domid " - "=3D %d; ref =3D %d\n", op.status, - private_data->grants[slot_index+i].u= - .valid.domid, - private_data->grants[slot_index+i].u= - .valid.ref); - /* This should never happen after we've = mapped into - * the kernel space. */ - BUG_ON(op.status =3D=3D GNTST_eagain); - goto undo_map_out; - } - =09 - /* Record the grant handle, for use in the = unmap=20 - * operation.=20 - */ - private_data->grants[slot_index+i].u. - valid.user_handle =3D op.handle; - - /* Update p2m structure with the new mapping. */ - set_phys_to_machine(__pa(kernel_vaddr) >> = PAGE_SHIFT, - FOREIGN_FRAME(private_data-> - grants[slot_index= +i] - .u.valid.dev_bus_= addr - >> PAGE_SHIFT)); - } else { + if (xen_feature(XENFEAT_auto_translated_physmap)) { /* USING SHADOW PAGE TABLES. */ /* In this case, we simply insert the page into = the VM * area. */ ret =3D vm_insert_page(vma, user_vaddr, page); + if (!ret) + continue; + exit_ret =3D ret; + goto undo_map_out; + } + + /* NOT USING SHADOW PAGE TABLES. */ + /* In this case, we map the grant(s) straight into user + * space. + */ + + /* Get the machine address of the PTE for the user page. = */ + if ((ret =3D create_lookup_pte_addr(vma->vm_mm, + vma->vm_start + + (i << PAGE_SHIFT), + &ptep))) + { + printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n", + ret); + goto undo_map_out; + } + + /* Configure the map operation. */ + + /* The reference is to be used by host CPUs. */ + flags =3D GNTMAP_host_map; + + /* Specifies a user space mapping. */ + flags |=3D GNTMAP_application_map; + + /* The map request contains the machine address of the + * PTE to update. + */ + flags |=3D GNTMAP_contains_pte; + + if (!(vma->vm_flags & VM_WRITE)) + flags |=3D GNTMAP_readonly; + + gnttab_set_map_op(&op, ptep, flags, + private_data->grants[slot_index+i] + .u.valid.ref, + private_data->grants[slot_index+i] + .u.valid.domid); + + /* Carry out the mapping of the grant reference. */ + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, + &op, 1); + BUG_ON(ret); + if (op.status !=3D GNTST_okay) { + printk(KERN_ERR "Error mapping the grant reference = " + "into user space (%d). domid =3D %d; ref = =3D %d\n", + op.status, + private_data->grants[slot_index+i].u + .valid.domid, + private_data->grants[slot_index+i].u + .valid.ref); + /* This should never happen after we've mapped = into + * the kernel space. */ + BUG_ON(op.status =3D=3D GNTST_eagain); + goto undo_map_out; } =20 + /* Record the grant handle, for use in the unmap + * operation. + */ + private_data->grants[slot_index+i].u.valid.user_handle + =3D op.handle; + + /* Update p2m structure with the new mapping. */ + set_phys_to_machine(__pa(kernel_vaddr) >> PAGE_SHIFT, + FOREIGN_FRAME(private_data-> + grants[slot_index+i] + .u.valid.dev_bus_addr + >> PAGE_SHIFT)); } exit_ret =3D 0; =20 @@ -745,55 +745,52 @@ static pte_t gntdev_clear_pte(struct vm_ /* Only unmap grants if the slot has been mapped. This could be = being * called from a failing mmap(). */ - if (private_data->grants[slot_index].state =3D=3D GNTDEV_SLOT_MAPPE= D) { - - /* First, we clear the user space mapping, if it has been = made. - */ - if (private_data->grants[slot_index].u.valid.user_handle = !=3D - GNTDEV_INVALID_HANDLE &&=20 - !xen_feature(XENFEAT_auto_translated_physmap)) { - /* NOT USING SHADOW PAGE TABLES. */ - gnttab_set_unmap_op(&op, ptep_to_machine(ptep),=20 - GNTMAP_contains_pte, - private_data->grants[slot_index= ] - .u.valid.user_handle); - ret =3D HYPERVISOR_grant_table_op( - GNTTABOP_unmap_grant_ref, &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("User unmap grant status =3D = %d\n",=20 - op.status); - } else { - /* USING SHADOW PAGE TABLES. */ - pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); - } + if (private_data->grants[slot_index].state !=3D GNTDEV_SLOT_MAPPED)= { + pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + return copy; + } =20 - /* Finally, we unmap the grant from kernel space. */ - gnttab_set_unmap_op(&op,=20 - get_kernel_vaddr(private_data, = slot_index), - GNTMAP_host_map,=20 + /* First, we clear the user space mapping, if it has been made. + */ + if (private_data->grants[slot_index].u.valid.user_handle !=3D + GNTDEV_INVALID_HANDLE && + !xen_feature(XENFEAT_auto_translated_physmap)) { + /* NOT USING SHADOW PAGE TABLES. */ + gnttab_set_unmap_op(&op, ptep_to_machine(ptep), + GNTMAP_contains_pte, private_data->grants[slot_index].u.vali= d - .kernel_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= =20 + .user_handle); + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= &op, 1); BUG_ON(ret); if (op.status !=3D GNTST_okay) - printk("Kernel unmap grant status =3D %d\n", = op.status); + printk("User unmap grant status =3D %d\n", = op.status); + } else { + /* USING SHADOW PAGE TABLES. */ + pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + } =20 + /* Finally, we unmap the grant from kernel space. */ + gnttab_set_unmap_op(&op, + get_kernel_vaddr(private_data, slot_index), + GNTMAP_host_map, + private_data->grants[slot_index].u.valid + .kernel_handle); + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, = 1); + BUG_ON(ret); + if (op.status !=3D GNTST_okay) + printk("Kernel unmap grant status =3D %d\n", op.status); =20 - /* Return slot to the not-yet-mapped state, so that it may = be - * mapped again, or removed by a subsequent ioctl. - */ - private_data->grants[slot_index].state =3D=20 - GNTDEV_SLOT_NOT_YET_MAPPED; + /* Return slot to the not-yet-mapped state, so that it may be + * mapped again, or removed by a subsequent ioctl. + */ + private_data->grants[slot_index].state =3D GNTDEV_SLOT_NOT_YET_MAPP= ED; =20 + if (!xen_feature(XENFEAT_auto_translated_physmap)) { /* Invalidate the physical to machine mapping for this = page. */ set_phys_to_machine( page_to_pfn(private_data->foreign_pages[slot_index]= ), INVALID_P2M_ENTRY); - - } else { - pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); } =20 return copy; --=__Part0729EE57.0__= Content-Type: text/plain; name="xen-gntdev-indent.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-indent.patch" gntdev: adjust indentation (and fix bugs noticed by doing so)=0A=0ABy = inverting two conditions, indentation can be decreased by one level=0Afor = large code portions, thus improving legibility.=0A=0AIn gntdev_mmap(), = this made obvious that failure of vm_insert_page()=0Awas silently ignored = rather than being propagated to the caller.=0A=0AIn gntdev_clear_pte(), = the final set_phys_to_machine() must not be=0Acalled for the auto-translate= d case.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ = -607,85 +607,85 @@ static int gntdev_mmap (struct file *fli=0A = GNTDEV_INVALID_HANDLE;=0A =0A /* Now perform the mapping to user = space. */=0A- if (!xen_feature(XENFEAT_auto_translated_physmap)) = {=0A-=0A- /* NOT USING SHADOW PAGE TABLES. */=0A- = /* In this case, we map the grant(s) straight into user=0A- = * space.=0A- */=0A-=0A- /* = Get the machine address of the PTE for the user =0A- * = page.=0A- */=0A- if ((ret =3D = create_lookup_pte_addr(vma->vm_mm, =0A- = vma->vm_start =0A- = + (i << PAGE_SHIFT), =0A- = &ptep)))=0A- {=0A- printk(KERN= _ERR "Error obtaining PTE pointer "=0A- = "(%d).\n", ret);=0A- goto undo_map_out;=0A- = }=0A- =0A- /* Configure the = map operation. */=0A- =0A- /* The reference = is to be used by host CPUs. */=0A- flags =3D = GNTMAP_host_map;=0A- =0A- /* = Specifies a user space mapping. */=0A- flags |=3D = GNTMAP_application_map;=0A- =0A- /* = The map request contains the machine address of the=0A- * = PTE to update.=0A- */=0A- flags |=3D = GNTMAP_contains_pte;=0A- =0A- if = (!(vma->vm_flags & VM_WRITE))=0A- flags |=3D = GNTMAP_readonly;=0A-=0A- gnttab_set_map_op(&op, = ptep, flags, =0A- private_data->gra= nts[slot_index+i]=0A- .u.valid.ref, = =0A- private_data->grants[slot_index+i= ]=0A- .u.valid.domid);=0A-=0A- = /* Carry out the mapping of the grant reference. */=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,=0A- = &op, 1);=0A- BUG_ON(ret)= ;=0A- if (op.status !=3D GNTST_okay) {=0A- = printk(KERN_ERR "Error mapping the grant "=0A- = "reference into user space (%d). domid "=0A- = "=3D %d; ref =3D %d\n", op.status,=0A- = private_data->grants[slot_index+i].u=0A- = .valid.domid,=0A- private_data->grants= [slot_index+i].u=0A- .valid.ref);=0A- = /* This should never happen after we've mapped into=0A- = * the kernel space. */=0A- = BUG_ON(op.status =3D=3D GNTST_eagain);=0A- = goto undo_map_out;=0A- }=0A- =0A- = /* Record the grant handle, for use in the unmap =0A- = * operation. =0A- */=0A- private_dat= a->grants[slot_index+i].u.=0A- valid.user_handle = =3D op.handle;=0A-=0A- /* Update p2m structure with the = new mapping. */=0A- set_phys_to_machine(__pa(kernel_vad= dr) >> PAGE_SHIFT,=0A- FOREIGN_FRAME(p= rivate_data->=0A- = grants[slot_index+i]=0A- = .u.valid.dev_bus_addr=0A- = >> PAGE_SHIFT));=0A- } else {=0A+ if (xen_feature(XEN= FEAT_auto_translated_physmap)) {=0A /* USING SHADOW = PAGE TABLES. */=0A /* In this case, we simply insert = the page into the VM=0A * area. */=0A = ret =3D vm_insert_page(vma, user_vaddr, page);=0A+ if = (!ret)=0A+ continue;=0A+ = exit_ret =3D ret;=0A+ goto undo_map_out;=0A+ = }=0A+=0A+ /* NOT USING SHADOW PAGE TABLES. */=0A+ /* = In this case, we map the grant(s) straight into user=0A+ * = space.=0A+ */=0A+=0A+ /* Get the machine address = of the PTE for the user page. */=0A+ if ((ret =3D create_lookup_= pte_addr(vma->vm_mm,=0A+ = vma->vm_start=0A+ + (i << = PAGE_SHIFT),=0A+ = &ptep)))=0A+ {=0A+ printk(KERN_ERR "Error = obtaining PTE pointer (%d)\n",=0A+ ret);=0A+ = goto undo_map_out;=0A+ }=0A+=0A+ /* = Configure the map operation. */=0A+=0A+ /* The reference is to be = used by host CPUs. */=0A+ flags =3D GNTMAP_host_map;=0A+=0A+ = /* Specifies a user space mapping. */=0A+ flags |=3D = GNTMAP_application_map;=0A+=0A+ /* The map request contains the = machine address of the=0A+ * PTE to update.=0A+ = */=0A+ flags |=3D GNTMAP_contains_pte;=0A+=0A+ if = (!(vma->vm_flags & VM_WRITE))=0A+ flags |=3D = GNTMAP_readonly;=0A+=0A+ gnttab_set_map_op(&op, ptep, = flags,=0A+ private_data->grants[slot_index+i= ]=0A+ .u.valid.ref,=0A+ = private_data->grants[slot_index+i]=0A+ = .u.valid.domid);=0A+=0A+ /* Carry out the mapping of the = grant reference. */=0A+ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_= map_grant_ref,=0A+ &op, = 1);=0A+ BUG_ON(ret);=0A+ if (op.status !=3D = GNTST_okay) {=0A+ printk(KERN_ERR "Error mapping the = grant reference "=0A+ "into user space (%d). = domid =3D %d; ref =3D %d\n",=0A+ op.status,= =0A+ private_data->grants[slot_index+i].u=0A+ = .valid.domid,=0A+ private_data= ->grants[slot_index+i].u=0A+ .valid.ref);=0A+ = /* This should never happen after we've mapped into=0A+ = * the kernel space. */=0A+ BUG_ON(op.status =3D=3D = GNTST_eagain);=0A+ goto undo_map_out;=0A = }=0A =0A+ /* Record the grant handle, for use in the = unmap=0A+ * operation.=0A+ */=0A+ = private_data->grants[slot_index+i].u.valid.user_handle=0A+ = =3D op.handle;=0A+=0A+ /* Update p2m structure with the new = mapping. */=0A+ set_phys_to_machine(__pa(kernel_vaddr) >> = PAGE_SHIFT,=0A+ FOREIGN_FRAME(private_data->=0A= + grants[slot_index+i]=0A+ = .u.valid.dev_bus_addr=0A+ = >> PAGE_SHIFT));=0A }=0A exit_ret = =3D 0;=0A =0A@@ -745,55 +745,52 @@ static pte_t gntdev_clear_pte(struct = vm_=0A /* Only unmap grants if the slot has been mapped. This could be = being=0A * called from a failing mmap().=0A */=0A- if = (private_data->grants[slot_index].state =3D=3D GNTDEV_SLOT_MAPPED) = {=0A-=0A- /* First, we clear the user space mapping, if it = has been made.=0A- */=0A- if (private_data->grants[sl= ot_index].u.valid.user_handle !=3D=0A- GNTDEV_INVALID_HANDLE = && =0A- !xen_feature(XENFEAT_auto_translated_physmap)) {=0A- = /* NOT USING SHADOW PAGE TABLES. */=0A- = gnttab_set_unmap_op(&op, ptep_to_machine(ptep), =0A- = GNTMAP_contains_pte,=0A- = private_data->grants[slot_index]=0A- = .u.valid.user_handle);=0A- ret =3D HYPERVISOR_grant_ta= ble_op(=0A- GNTTABOP_unmap_grant_ref, &op, = 1);=0A- BUG_ON(ret);=0A- if = (op.status !=3D GNTST_okay)=0A- printk("User unmap = grant status =3D %d\n", =0A- op.status);= =0A- } else {=0A- /* USING SHADOW PAGE = TABLES. */=0A- pte_clear_full(vma->vm_mm, addr, ptep, = is_fullmm);=0A- }=0A+ if (private_data->grants[slot_index].state = !=3D GNTDEV_SLOT_MAPPED) {=0A+ pte_clear_full(vma->vm_mm, addr, = ptep, is_fullmm);=0A+ return copy;=0A+ }=0A =0A- = /* Finally, we unmap the grant from kernel space. */=0A- = gnttab_set_unmap_op(&op, =0A- get_kernel_vadd= r(private_data, slot_index),=0A- = GNTMAP_host_map, =0A+ /* First, we clear the user space mapping, if it = has been made.=0A+ */=0A+ if (private_data->grants[slot_index].u.vali= d.user_handle !=3D=0A+ GNTDEV_INVALID_HANDLE &&=0A+ = !xen_feature(XENFEAT_auto_translated_physmap)) {=0A+ /* NOT = USING SHADOW PAGE TABLES. */=0A+ gnttab_set_unmap_op(&op, = ptep_to_machine(ptep),=0A+ GNTMAP_contains= _pte,=0A private_data->grants[slot_index= ].u.valid=0A- .kernel_handle);=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, =0A+ = .user_handle);=0A+ ret =3D HYPERVISOR_grant_ta= ble_op(GNTTABOP_unmap_grant_ref,=0A = &op, 1);=0A BUG_ON(ret);=0A if (op.status !=3D = GNTST_okay)=0A- printk("Kernel unmap grant status =3D = %d\n", op.status);=0A+ printk("User unmap grant status = =3D %d\n", op.status);=0A+ } else {=0A+ /* USING SHADOW = PAGE TABLES. */=0A+ pte_clear_full(vma->vm_mm, addr, ptep, = is_fullmm);=0A+ }=0A =0A+ /* Finally, we unmap the grant from kernel = space. */=0A+ gnttab_set_unmap_op(&op,=0A+ = get_kernel_vaddr(private_data, slot_index),=0A+ = GNTMAP_host_map,=0A+ private_data->grants[slot_index= ].u.valid=0A+ .kernel_handle);=0A+ ret =3D = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);=0A+ = BUG_ON(ret);=0A+ if (op.status !=3D GNTST_okay)=0A+ = printk("Kernel unmap grant status =3D %d\n", op.status);=0A =0A- = /* Return slot to the not-yet-mapped state, so that it may be=0A- = * mapped again, or removed by a subsequent ioctl.=0A- */=0A- = private_data->grants[slot_index].state =3D =0A- GNTDEV_SLOT= _NOT_YET_MAPPED;=0A+ /* Return slot to the not-yet-mapped state, so = that it may be=0A+ * mapped again, or removed by a subsequent = ioctl.=0A+ */=0A+ private_data->grants[slot_index].state =3D = GNTDEV_SLOT_NOT_YET_MAPPED;=0A =0A+ if (!xen_feature(XENFEAT_auto_trans= lated_physmap)) {=0A /* Invalidate the physical to machine = mapping for this page. */=0A set_phys_to_machine(=0A = page_to_pfn(private_data->foreign_pages[slot_index]),=0A = INVALID_P2M_ENTRY);=0A-=0A- } else {=0A- pte_clear_f= ull(vma->vm_mm, addr, ptep, is_fullmm);=0A }=0A =0A return = copy;=0A --=__Part0729EE57.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part0729EE57.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:18:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:18:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV8i-00036A-E5; Thu, 10 May 2012 15:18:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV8g-00035k-M1 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:18:47 +0000 Received: from [85.158.139.83:22286] by server-9.bemta-5.messagelabs.com id C1/29-09826-55CDBAF4; Thu, 10 May 2012 15:18:45 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336663123!27622200!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21047 invoked from network); 10 May 2012 15:18:44 -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; 10 May 2012 15:18:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:18:43 +0100 Message-Id: <4FABF88A0200007800082C93@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:19:06 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2A04C37A.0__=" Subject: [Xen-devel] [PATCH 4/4] linux-2.6.18/gntdev: misc cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2A04C37A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - eliminate struct gntdev_grant_info's dev_bus_addr member (which was used to communicate a value inside the main loop of gntdev_mmap()) - correct types - use a local variable 'grants' in gntdev_mmap() to improve readability - avoid re-calculating already calculated values - properly check for out of range values - combine both GNTTABOP_unmap_grant_ref calls in gntdev_clear_pte() into a single hypercall - adjust error diagnostic in unmap ioctl to be more useful and better legible Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -80,7 +80,6 @@ typedef struct gntdev_grant_info { grant_ref_t ref; grant_handle_t kernel_handle; grant_handle_t user_handle; - uint64_t dev_bus_addr; } valid; } u; } gntdev_grant_info_t; @@ -473,14 +472,14 @@ static int gntdev_mmap (struct file *fli { struct gnttab_map_grant_ref op; unsigned long slot_index =3D vma->vm_pgoff; - unsigned long kernel_vaddr, user_vaddr; - uint32_t size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + unsigned long kernel_vaddr, user_vaddr, mfn; + unsigned long size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;= uint64_t ptep; int ret, exit_ret; - int flags; - int i; + unsigned int i, flags; struct page *page; gntdev_file_private_data_t *private_data =3D flip->private_data; + gntdev_grant_info_t *grants; struct vm_foreign_map *foreign_map; =20 if (unlikely(!private_data)) { @@ -490,17 +489,19 @@ static int gntdev_mmap (struct file *fli =20 /* Test to make sure that the grants array has been initialised. = */ down_read(&private_data->grants_sem); - if (unlikely(!private_data->grants)) { - up_read(&private_data->grants_sem); + grants =3D private_data->grants; + up_read(&private_data->grants_sem); + + if (unlikely(!grants)) { printk(KERN_ERR "Attempted to mmap before ioctl.\n"); return -EINVAL; } - up_read(&private_data->grants_sem); + grants +=3D slot_index; =20 - if (unlikely((size <=3D 0) ||=20 - (size + slot_index) > private_data->grants_size)) { + if (unlikely(size + slot_index <=3D slot_index || + size + slot_index > private_data->grants_size)) { printk(KERN_ERR "Invalid number of pages or offset" - "(num_pages =3D %d, first_slot =3D %ld).\n", + "(num_pages =3D %lu, first_slot =3D %lu)\n", size, slot_index); return -ENXIO; } @@ -521,11 +522,10 @@ static int gntdev_mmap (struct file *fli /* Slots must be in the NOT_YET_MAPPED state. */ down_write(&private_data->grants_sem); for (i =3D 0; i < size; ++i) { - if (private_data->grants[slot_index + i].state !=3D=20 - GNTDEV_SLOT_NOT_YET_MAPPED) { - printk(KERN_ERR "Slot (index =3D %ld) is in the = wrong " + if (grants[i].state !=3D GNTDEV_SLOT_NOT_YET_MAPPED) { + printk(KERN_ERR "Slot (index =3D %lu) is in the = wrong " "state (%d).\n", slot_index + i,=20 - private_data->grants[slot_index + i].state);= + grants[i].state); up_write(&private_data->grants_sem); kfree(foreign_map); return -EINVAL; @@ -565,14 +565,11 @@ static int gntdev_mmap (struct file *fli flags |=3D GNTMAP_readonly; =20 kernel_vaddr =3D get_kernel_vaddr(private_data, slot_index = + i); - user_vaddr =3D get_user_vaddr(vma, i); page =3D private_data->foreign_pages[slot_index + i]; =20 gnttab_set_map_op(&op, kernel_vaddr, flags, =20 - private_data->grants[slot_index+i] - .u.valid.ref,=20 - private_data->grants[slot_index+i] - .u.valid.domid); + grants[i].u.valid.ref, + grants[i].u.valid.domid); =20 /* Carry out the mapping of the grant reference. */ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,= =20 @@ -583,10 +580,8 @@ static int gntdev_mmap (struct file *fli printk(KERN_ERR "Error mapping the grant = reference " "into the kernel (%d). domid =3D = %d; ref =3D %d\n", op.status, - private_data->grants[slot_index+i] - .u.valid.domid, - private_data->grants[slot_index+i] - .u.valid.ref); + grants[i].u.valid.domid, + grants[i].u.valid.ref); else /* Propagate eagain instead of trying to = fix it up */ exit_ret =3D -EAGAIN; @@ -597,16 +592,14 @@ static int gntdev_mmap (struct file *fli SetPageReserved(page); =20 /* Record the grant handle, for use in the unmap operation.= */ - private_data->grants[slot_index+i].u.valid.kernel_handle = =3D=20 - op.handle; - private_data->grants[slot_index+i].u.valid.dev_bus_addr = =3D=20 - op.dev_bus_addr; + grants[i].u.valid.kernel_handle =3D op.handle; =09 - private_data->grants[slot_index+i].state =3D GNTDEV_SLOT_MA= PPED; - private_data->grants[slot_index+i].u.valid.user_handle =3D - GNTDEV_INVALID_HANDLE; + grants[i].state =3D GNTDEV_SLOT_MAPPED; + grants[i].u.valid.user_handle =3D GNTDEV_INVALID_HANDLE; =20 /* Now perform the mapping to user space. */ + user_vaddr =3D get_user_vaddr(vma, i); + if (xen_feature(XENFEAT_auto_translated_physmap)) { /* USING SHADOW PAGE TABLES. */ /* In this case, we simply insert the page into = the VM @@ -622,11 +615,11 @@ static int gntdev_mmap (struct file *fli /* In this case, we map the grant(s) straight into user * space. */ + mfn =3D op.dev_bus_addr >> PAGE_SHIFT; =20 /* Get the machine address of the PTE for the user page. = */ if ((ret =3D create_lookup_pte_addr(vma->vm_mm, - vma->vm_start - + (i << PAGE_SHIFT), + user_vaddr, &ptep))) { printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n", @@ -636,9 +629,6 @@ static int gntdev_mmap (struct file *fli =20 /* Configure the map operation. */ =20 - /* The reference is to be used by host CPUs. */ - flags =3D GNTMAP_host_map; - /* Specifies a user space mapping. */ flags |=3D GNTMAP_application_map; =20 @@ -647,14 +637,9 @@ static int gntdev_mmap (struct file *fli */ flags |=3D GNTMAP_contains_pte; =20 - if (!(vma->vm_flags & VM_WRITE)) - flags |=3D GNTMAP_readonly; - gnttab_set_map_op(&op, ptep, flags, - private_data->grants[slot_index+i] - .u.valid.ref, - private_data->grants[slot_index+i] - .u.valid.domid); + grants[i].u.valid.ref, + grants[i].u.valid.domid); =20 /* Carry out the mapping of the grant reference. */ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, @@ -664,10 +649,8 @@ static int gntdev_mmap (struct file *fli printk(KERN_ERR "Error mapping the grant reference = " "into user space (%d). domid =3D %d; ref = =3D %d\n", op.status, - private_data->grants[slot_index+i].u - .valid.domid, - private_data->grants[slot_index+i].u - .valid.ref); + grants[i].u.valid.domid, + grants[i].u.valid.ref); /* This should never happen after we've mapped = into * the kernel space. */ BUG_ON(op.status =3D=3D GNTST_eagain); @@ -677,15 +660,11 @@ static int gntdev_mmap (struct file *fli /* Record the grant handle, for use in the unmap * operation. */ - private_data->grants[slot_index+i].u.valid.user_handle - =3D op.handle; + grants[i].u.valid.user_handle =3D op.handle; =20 /* Update p2m structure with the new mapping. */ set_phys_to_machine(__pa(kernel_vaddr) >> PAGE_SHIFT, - FOREIGN_FRAME(private_data-> - grants[slot_index+i] - .u.valid.dev_bus_addr - >> PAGE_SHIFT)); + FOREIGN_FRAME(mfn)); } exit_ret =3D 0; =20 @@ -715,9 +694,11 @@ undo_map_out: static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long = addr, pte_t *ptep, int is_fullmm) { - int slot_index, ret; + int ret; + unsigned int nr; + unsigned long slot_index; pte_t copy; - struct gnttab_unmap_grant_ref op; + struct gnttab_unmap_grant_ref op[2]; gntdev_file_private_data_t *private_data; =20 /* THIS IS VERY UNPLEASANT: do_mmap_pgoff() will set the vma->vm_fi= le @@ -750,36 +731,35 @@ static pte_t gntdev_clear_pte(struct vm_ return copy; } =20 - /* First, we clear the user space mapping, if it has been made. - */ + /* Clear the user space mapping, if it has been made. */ if (private_data->grants[slot_index].u.valid.user_handle !=3D - GNTDEV_INVALID_HANDLE && - !xen_feature(XENFEAT_auto_translated_physmap)) { - /* NOT USING SHADOW PAGE TABLES. */ - gnttab_set_unmap_op(&op, ptep_to_machine(ptep), + GNTDEV_INVALID_HANDLE) { + /* NOT USING SHADOW PAGE TABLES (and user handle valid). = */ + gnttab_set_unmap_op(&op[0], ptep_to_machine(ptep), GNTMAP_contains_pte, private_data->grants[slot_index].u.vali= d .user_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= - &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("User unmap grant status =3D %d\n", = op.status); + nr =3D 1; } else { - /* USING SHADOW PAGE TABLES. */ + /* USING SHADOW PAGE TABLES (or user handle invalid). */ pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + nr =3D 0; } =20 - /* Finally, we unmap the grant from kernel space. */ - gnttab_set_unmap_op(&op, + /* We always unmap the grant from kernel space. */ + gnttab_set_unmap_op(&op[nr], get_kernel_vaddr(private_data, slot_index), GNTMAP_host_map, private_data->grants[slot_index].u.valid .kernel_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, = 1); + + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, nr = + 1); BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("Kernel unmap grant status =3D %d\n", op.status); + + if (nr && op[0].status !=3D GNTST_okay) + printk("User unmap grant status =3D %d\n", op[0].status); + if (op[nr].status !=3D GNTST_okay) + printk("Kernel unmap grant status =3D %d\n", op[nr].status)= ; =20 /* Return slot to the not-yet-mapped state, so that it may be * mapped again, or removed by a subsequent ioctl. @@ -915,7 +895,8 @@ private_data_initialised: return -EFAULT; =20 start_index =3D op.index >> PAGE_SHIFT; - if (start_index + op.count > private_data->grants_size) + if (start_index + op.count < start_index || + start_index + op.count > private_data->grants_size) return -EINVAL; =20 down_write(&private_data->grants_sem); @@ -924,28 +905,29 @@ private_data_initialised: * state. */ for (i =3D 0; i < op.count; ++i) { - if (unlikely - (private_data->grants[start_index + i].state - !=3D GNTDEV_SLOT_NOT_YET_MAPPED)) { - if (private_data->grants[start_index + = i].state - =3D=3D GNTDEV_SLOT_INVALID) { - printk(KERN_ERR - "Tried to remove an invalid = " - "grant at offset 0x%x.", - (start_index + i)=20 - << PAGE_SHIFT); - rc =3D -EINVAL; - } else { - printk(KERN_ERR - "Tried to remove a grant = which " - "is currently mmap()-ed at = " - "offset 0x%x.", - (start_index + i)=20 - << PAGE_SHIFT); - rc =3D -EBUSY; - } - goto unmap_out; + const char *what; + + switch (private_data->grants[start_index + = i].state) { + case GNTDEV_SLOT_NOT_YET_MAPPED: + continue; + case GNTDEV_SLOT_INVALID: + what =3D "invalid"; + rc =3D -EINVAL; + break; + case GNTDEV_SLOT_MAPPED: + what =3D "currently mmap()-ed"; + rc =3D -EBUSY; + break; + default: + what =3D "in an invalid state"; + rc =3D -ENXIO; + break; } + printk(KERN_ERR "%s[%d] tried to remove a grant" + " which is %s at %#x+%#x\n", + current->comm, current->pid, + what, start_index, i); + goto unmap_out; } =20 down_write(&private_data->free_list_sem); --=__Part2A04C37A.0__= Content-Type: text/plain; name="xen-gntdev-cleanup.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-cleanup.patch" gntdev: misc cleanup=0A=0A- eliminate struct gntdev_grant_info's dev_bus_ad= dr member (which was=0A used to communicate a value inside the main loop = of gntdev_mmap())=0A- correct types=0A- use a local variable 'grants' in = gntdev_mmap() to improve readability=0A- avoid re-calculating already = calculated values=0A- properly check for out of range values=0A- combine = both GNTTABOP_unmap_grant_ref calls in gntdev_clear_pte()=0A into a = single hypercall=0A- adjust error diagnostic in unmap ioctl to be more = useful and better=0A legible=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gn= tdev.c=0A@@ -80,7 +80,6 @@ typedef struct gntdev_grant_info {=0A = grant_ref_t ref;=0A grant_handle_t kernel_handl= e;=0A grant_handle_t user_handle;=0A- = uint64_t dev_bus_addr;=0A } valid;=0A } u;=0A } = gntdev_grant_info_t;=0A@@ -473,14 +472,14 @@ static int gntdev_mmap = (struct file *fli=0A {=0A struct gnttab_map_grant_ref op;=0A = unsigned long slot_index =3D vma->vm_pgoff;=0A- unsigned long kernel_vaddr,= user_vaddr;=0A- uint32_t size =3D (vma->vm_end - vma->vm_start) >> = PAGE_SHIFT;=0A+ unsigned long kernel_vaddr, user_vaddr, mfn;=0A+ = unsigned long size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;=0A = uint64_t ptep;=0A int ret, exit_ret;=0A- int flags;=0A- int i;=0A+ = unsigned int i, flags;=0A struct page *page;=0A gntdev_file_private= _data_t *private_data =3D flip->private_data;=0A+ gntdev_grant_info_t= *grants;=0A struct vm_foreign_map *foreign_map;=0A =0A if = (unlikely(!private_data)) {=0A@@ -490,17 +489,19 @@ static int gntdev_mmap = (struct file *fli=0A =0A /* Test to make sure that the grants array = has been initialised. */=0A down_read(&private_data->grants_sem);=0A- = if (unlikely(!private_data->grants)) {=0A- up_read(&private_da= ta->grants_sem);=0A+ grants =3D private_data->grants;=0A+ up_read(&pr= ivate_data->grants_sem);=0A+=0A+ if (unlikely(!grants)) {=0A = printk(KERN_ERR "Attempted to mmap before ioctl.\n");=0A = return -EINVAL;=0A }=0A- up_read(&private_data->grants_sem);=0A+ = grants +=3D slot_index;=0A =0A- if (unlikely((size <=3D 0) || =0A- = (size + slot_index) > private_data->grants_size)) {=0A+ if = (unlikely(size + slot_index <=3D slot_index ||=0A+ size = + slot_index > private_data->grants_size)) {=0A printk(KERN= _ERR "Invalid number of pages or offset"=0A- "(num_pages = =3D %d, first_slot =3D %ld).\n",=0A+ "(num_pages =3D = %lu, first_slot =3D %lu)\n",=0A size, slot_index);= =0A return -ENXIO;=0A }=0A@@ -521,11 +522,10 @@ static = int gntdev_mmap (struct file *fli=0A /* Slots must be in the NOT_YET_MAP= PED state. */=0A down_write(&private_data->grants_sem);=0A = for (i =3D 0; i < size; ++i) {=0A- if (private_data->grants[sl= ot_index + i].state !=3D =0A- GNTDEV_SLOT_NOT_YET_MAPPED) = {=0A- printk(KERN_ERR "Slot (index =3D %ld) is in the = wrong "=0A+ if (grants[i].state !=3D GNTDEV_SLOT_NOT_YET_MAPPED= ) {=0A+ printk(KERN_ERR "Slot (index =3D %lu) is in the = wrong "=0A "state (%d).\n", slot_index + i, = =0A- private_data->grants[slot_index + i].state);= =0A+ grants[i].state);=0A = up_write(&private_data->grants_sem);=0A kfree(forei= gn_map);=0A return -EINVAL;=0A@@ -565,14 +565,11 @@ = static int gntdev_mmap (struct file *fli=0A flags |=3D = GNTMAP_readonly;=0A =0A kernel_vaddr =3D get_kernel_vaddr(p= rivate_data, slot_index + i);=0A- user_vaddr =3D get_user_vad= dr(vma, i);=0A page =3D private_data->foreign_pages[slot_index + = i];=0A =0A gnttab_set_map_op(&op, kernel_vaddr, flags, =0A- = private_data->grants[slot_index+i]=0A- = .u.valid.ref, =0A- = private_data->grants[slot_index+i]=0A- = .u.valid.domid);=0A+ grants[i].u.valid.ref,=0A= + grants[i].u.valid.domid);=0A =0A = /* Carry out the mapping of the grant reference. */=0A ret =3D = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, =0A@@ -583,10 +580,8 @@ = static int gntdev_mmap (struct file *fli=0A = printk(KERN_ERR "Error mapping the grant reference "=0A = "into the kernel (%d). domid =3D %d; ref =3D %d\n",=0A = op.status,=0A- = private_data->grants[slot_index+i]=0A- = .u.valid.domid,=0A- private_data->grants= [slot_index+i]=0A- .u.valid.ref);=0A+ = grants[i].u.valid.domid,=0A+ = grants[i].u.valid.ref);=0A else=0A = /* Propagate eagain instead of trying to fix it up = */=0A exit_ret =3D -EAGAIN;=0A@@ -597,16 +592,14 = @@ static int gntdev_mmap (struct file *fli=0A SetPageReserved(pag= e);=0A =0A /* Record the grant handle, for use in the unmap = operation. */=0A- private_data->grants[slot_index+i].u.valid.= kernel_handle =3D =0A- op.handle;=0A- private_dat= a->grants[slot_index+i].u.valid.dev_bus_addr =3D =0A- = op.dev_bus_addr;=0A+ grants[i].u.valid.kernel_handle =3D = op.handle;=0A =0A- private_data->grants[slot_index+i].= state =3D GNTDEV_SLOT_MAPPED;=0A- private_data->grants[slot_i= ndex+i].u.valid.user_handle =3D=0A- GNTDEV_INVALID_HAND= LE;=0A+ grants[i].state =3D GNTDEV_SLOT_MAPPED;=0A+ = grants[i].u.valid.user_handle =3D GNTDEV_INVALID_HANDLE;=0A =0A = /* Now perform the mapping to user space. */=0A+ user_vaddr = =3D get_user_vaddr(vma, i);=0A+=0A if (xen_feature(XENFEAT_aut= o_translated_physmap)) {=0A /* USING SHADOW PAGE = TABLES. */=0A /* In this case, we simply insert the page = into the VM=0A@@ -622,11 +615,11 @@ static int gntdev_mmap (struct file = *fli=0A /* In this case, we map the grant(s) straight into = user=0A * space.=0A */=0A+ mfn =3D = op.dev_bus_addr >> PAGE_SHIFT;=0A =0A /* Get the machine address = of the PTE for the user page. */=0A if ((ret =3D create_lookup_= pte_addr(vma->vm_mm,=0A- = vma->vm_start=0A- + (i << = PAGE_SHIFT),=0A+ = user_vaddr,=0A &ptep)))=0A = {=0A printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n",=0A@@ -636,9 +629,6 @@ static int gntdev_mmap (struct file *fli=0A = =0A /* Configure the map operation. */=0A =0A- /* = The reference is to be used by host CPUs. */=0A- flags =3D = GNTMAP_host_map;=0A-=0A /* Specifies a user space mapping. = */=0A flags |=3D GNTMAP_application_map;=0A =0A@@ -647,14 +637,9 = @@ static int gntdev_mmap (struct file *fli=0A */=0A = flags |=3D GNTMAP_contains_pte;=0A =0A- if (!(vma->vm_flags & = VM_WRITE))=0A- flags |=3D GNTMAP_readonly;=0A-=0A = gnttab_set_map_op(&op, ptep, flags,=0A- = private_data->grants[slot_index+i]=0A- = .u.valid.ref,=0A- private_data->grants[slot= _index+i]=0A- .u.valid.domid);=0A+ = grants[i].u.valid.ref,=0A+ = grants[i].u.valid.domid);=0A =0A /* Carry out the mapping = of the grant reference. */=0A ret =3D HYPERVISOR_grant_table_op(G= NTTABOP_map_grant_ref,=0A@@ -664,10 +649,8 @@ static int gntdev_mmap = (struct file *fli=0A printk(KERN_ERR "Error mapping the = grant reference "=0A "into user space (%d). = domid =3D %d; ref =3D %d\n",=0A op.status,= =0A- private_data->grants[slot_index+i].u=0A- = .valid.domid,=0A- private_data= ->grants[slot_index+i].u=0A- .valid.ref);=0A+ = grants[i].u.valid.domid,=0A+ = grants[i].u.valid.ref);=0A /* This should never = happen after we've mapped into=0A * the kernel = space. */=0A BUG_ON(op.status =3D=3D GNTST_eagain);=0A@@= -677,15 +660,11 @@ static int gntdev_mmap (struct file *fli=0A = /* Record the grant handle, for use in the unmap=0A * = operation.=0A */=0A- private_data->grants[slot_index+i].= u.valid.user_handle=0A- =3D op.handle;=0A+ = grants[i].u.valid.user_handle =3D op.handle;=0A =0A /* Update = p2m structure with the new mapping. */=0A set_phys_to_machine= (__pa(kernel_vaddr) >> PAGE_SHIFT,=0A- = FOREIGN_FRAME(private_data->=0A- = grants[slot_index+i]=0A- = .u.valid.dev_bus_addr=0A- = >> PAGE_SHIFT));=0A+ FOREIGN_FRAME(mfn));=0A= }=0A exit_ret =3D 0;=0A =0A@@ -715,9 +694,11 @@ undo_map_out:=0A= static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long = addr,=0A pte_t *ptep, int is_fullmm)=0A {=0A- = int slot_index, ret;=0A+ int ret;=0A+ unsigned int nr;=0A+ = unsigned long slot_index;=0A pte_t copy;=0A- struct gnttab_unmap_grant_r= ef op;=0A+ struct gnttab_unmap_grant_ref op[2];=0A gntdev_file= _private_data_t *private_data;=0A =0A /* THIS IS VERY UNPLEASANT: = do_mmap_pgoff() will set the vma->vm_file=0A@@ -750,36 +731,35 @@ static = pte_t gntdev_clear_pte(struct vm_=0A return copy;=0A = }=0A =0A- /* First, we clear the user space mapping, if it has been = made.=0A- */=0A+ /* Clear the user space mapping, if it has been = made. */=0A if (private_data->grants[slot_index].u.valid.user_handle = !=3D=0A- GNTDEV_INVALID_HANDLE &&=0A- !xen_feature(XE= NFEAT_auto_translated_physmap)) {=0A- /* NOT USING SHADOW PAGE = TABLES. */=0A- gnttab_set_unmap_op(&op, ptep_to_machine(ptep),=0A+= GNTDEV_INVALID_HANDLE) {=0A+ /* NOT USING = SHADOW PAGE TABLES (and user handle valid). */=0A+ gnttab_set_= unmap_op(&op[0], ptep_to_machine(ptep),=0A = GNTMAP_contains_pte,=0A private_data->g= rants[slot_index].u.valid=0A .user_handle);= =0A- ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= =0A- &op, 1);=0A- = BUG_ON(ret);=0A- if (op.status !=3D GNTST_okay)=0A- = printk("User unmap grant status =3D %d\n", op.status);=0A+ = nr =3D 1;=0A } else {=0A- /* USING SHADOW PAGE TABLES. = */=0A+ /* USING SHADOW PAGE TABLES (or user handle invalid). = */=0A pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm);=0A+ = nr =3D 0;=0A }=0A =0A- /* Finally, we unmap the grant from kernel = space. */=0A- gnttab_set_unmap_op(&op,=0A+ /* We always unmap the = grant from kernel space. */=0A+ gnttab_set_unmap_op(&op[nr],=0A = get_kernel_vaddr(private_data, slot_index),=0A = GNTMAP_host_map,=0A private_data->grants[sl= ot_index].u.valid=0A .kernel_handle);=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);=0A+=0A= + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, nr = + 1);=0A BUG_ON(ret);=0A- if (op.status !=3D GNTST_okay)=0A- = printk("Kernel unmap grant status =3D %d\n", op.status);=0A+=0A+ = if (nr && op[0].status !=3D GNTST_okay)=0A+ printk("User unmap = grant status =3D %d\n", op[0].status);=0A+ if (op[nr].status !=3D = GNTST_okay)=0A+ printk("Kernel unmap grant status =3D %d\n", = op[nr].status);=0A =0A /* Return slot to the not-yet-mapped state, so = that it may be=0A * mapped again, or removed by a subsequent = ioctl.=0A@@ -915,7 +895,8 @@ private_data_initialised:=0A = return -EFAULT;=0A =0A start_index =3D op.index >> PAGE_SHIFT;=0A-= if (start_index + op.count > private_data->grants_size)=0A+= if (start_index + op.count < start_index ||=0A+ = start_index + op.count > private_data->grants_size)=0A = return -EINVAL;=0A =0A down_write(&private_data->grants_sem);=0A@@= -924,28 +905,29 @@ private_data_initialised:=0A * = state.=0A */=0A for (i =3D 0; i < op.count; ++i) = {=0A- if (unlikely=0A- = (private_data->grants[start_index + i].state=0A- = !=3D GNTDEV_SLOT_NOT_YET_MAPPED)) {=0A- if = (private_data->grants[start_index + i].state=0A- = =3D=3D GNTDEV_SLOT_INVALID) {=0A- = printk(KERN_ERR=0A- "Tried to = remove an invalid "=0A- "grant at = offset 0x%x.",=0A- (start_index= + i) =0A- << PAGE_SHIFT);=0A- = rc =3D -EINVAL;=0A- = } else {=0A- printk(KERN_ERR=0A- = "Tried to remove a grant which "=0A- = "is currently mmap()-ed at "=0A- = "offset 0x%x.",=0A- = (start_index + i) =0A- << = PAGE_SHIFT);=0A- rc =3D -EBUSY;=0A- = }=0A- goto unmap_out;=0A+= const char *what;=0A+=0A+ = switch (private_data->grants[start_index + i].state) {=0A+ = case GNTDEV_SLOT_NOT_YET_MAPPED:=0A+ = continue;=0A+ case GNTDEV_SLOT_INVALID:=0A+ = what =3D "invalid";=0A+ rc =3D -EINVAL;=0A+= break;=0A+ case = GNTDEV_SLOT_MAPPED:=0A+ what =3D "currently = mmap()-ed";=0A+ rc =3D -EBUSY;=0A+ = break;=0A+ default:=0A+ = what =3D "in an invalid state";=0A+ rc =3D = -ENXIO;=0A+ break;=0A = }=0A+ printk(KERN_ERR "%s[%d] tried to remove a = grant"=0A+ " which is %s at %#x+%#x\n",=0A+ = current->comm, current->pid,=0A+ = what, start_index, i);=0A+ goto unmap_out;=0A = }=0A =0A down_write(&private_data->free_list_sem);=0A --=__Part2A04C37A.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2A04C37A.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:18:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:18:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV8i-00036A-E5; Thu, 10 May 2012 15:18:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSV8g-00035k-M1 for xen-devel@lists.xen.org; Thu, 10 May 2012 15:18:47 +0000 Received: from [85.158.139.83:22286] by server-9.bemta-5.messagelabs.com id C1/29-09826-55CDBAF4; Thu, 10 May 2012 15:18:45 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336663123!27622200!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21047 invoked from network); 10 May 2012 15:18:44 -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; 10 May 2012 15:18:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:18:43 +0100 Message-Id: <4FABF88A0200007800082C93@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:19:06 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2A04C37A.0__=" Subject: [Xen-devel] [PATCH 4/4] linux-2.6.18/gntdev: misc cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2A04C37A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - eliminate struct gntdev_grant_info's dev_bus_addr member (which was used to communicate a value inside the main loop of gntdev_mmap()) - correct types - use a local variable 'grants' in gntdev_mmap() to improve readability - avoid re-calculating already calculated values - properly check for out of range values - combine both GNTTABOP_unmap_grant_ref calls in gntdev_clear_pte() into a single hypercall - adjust error diagnostic in unmap ioctl to be more useful and better legible Signed-off-by: Jan Beulich --- a/drivers/xen/gntdev/gntdev.c +++ b/drivers/xen/gntdev/gntdev.c @@ -80,7 +80,6 @@ typedef struct gntdev_grant_info { grant_ref_t ref; grant_handle_t kernel_handle; grant_handle_t user_handle; - uint64_t dev_bus_addr; } valid; } u; } gntdev_grant_info_t; @@ -473,14 +472,14 @@ static int gntdev_mmap (struct file *fli { struct gnttab_map_grant_ref op; unsigned long slot_index =3D vma->vm_pgoff; - unsigned long kernel_vaddr, user_vaddr; - uint32_t size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + unsigned long kernel_vaddr, user_vaddr, mfn; + unsigned long size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;= uint64_t ptep; int ret, exit_ret; - int flags; - int i; + unsigned int i, flags; struct page *page; gntdev_file_private_data_t *private_data =3D flip->private_data; + gntdev_grant_info_t *grants; struct vm_foreign_map *foreign_map; =20 if (unlikely(!private_data)) { @@ -490,17 +489,19 @@ static int gntdev_mmap (struct file *fli =20 /* Test to make sure that the grants array has been initialised. = */ down_read(&private_data->grants_sem); - if (unlikely(!private_data->grants)) { - up_read(&private_data->grants_sem); + grants =3D private_data->grants; + up_read(&private_data->grants_sem); + + if (unlikely(!grants)) { printk(KERN_ERR "Attempted to mmap before ioctl.\n"); return -EINVAL; } - up_read(&private_data->grants_sem); + grants +=3D slot_index; =20 - if (unlikely((size <=3D 0) ||=20 - (size + slot_index) > private_data->grants_size)) { + if (unlikely(size + slot_index <=3D slot_index || + size + slot_index > private_data->grants_size)) { printk(KERN_ERR "Invalid number of pages or offset" - "(num_pages =3D %d, first_slot =3D %ld).\n", + "(num_pages =3D %lu, first_slot =3D %lu)\n", size, slot_index); return -ENXIO; } @@ -521,11 +522,10 @@ static int gntdev_mmap (struct file *fli /* Slots must be in the NOT_YET_MAPPED state. */ down_write(&private_data->grants_sem); for (i =3D 0; i < size; ++i) { - if (private_data->grants[slot_index + i].state !=3D=20 - GNTDEV_SLOT_NOT_YET_MAPPED) { - printk(KERN_ERR "Slot (index =3D %ld) is in the = wrong " + if (grants[i].state !=3D GNTDEV_SLOT_NOT_YET_MAPPED) { + printk(KERN_ERR "Slot (index =3D %lu) is in the = wrong " "state (%d).\n", slot_index + i,=20 - private_data->grants[slot_index + i].state);= + grants[i].state); up_write(&private_data->grants_sem); kfree(foreign_map); return -EINVAL; @@ -565,14 +565,11 @@ static int gntdev_mmap (struct file *fli flags |=3D GNTMAP_readonly; =20 kernel_vaddr =3D get_kernel_vaddr(private_data, slot_index = + i); - user_vaddr =3D get_user_vaddr(vma, i); page =3D private_data->foreign_pages[slot_index + i]; =20 gnttab_set_map_op(&op, kernel_vaddr, flags, =20 - private_data->grants[slot_index+i] - .u.valid.ref,=20 - private_data->grants[slot_index+i] - .u.valid.domid); + grants[i].u.valid.ref, + grants[i].u.valid.domid); =20 /* Carry out the mapping of the grant reference. */ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,= =20 @@ -583,10 +580,8 @@ static int gntdev_mmap (struct file *fli printk(KERN_ERR "Error mapping the grant = reference " "into the kernel (%d). domid =3D = %d; ref =3D %d\n", op.status, - private_data->grants[slot_index+i] - .u.valid.domid, - private_data->grants[slot_index+i] - .u.valid.ref); + grants[i].u.valid.domid, + grants[i].u.valid.ref); else /* Propagate eagain instead of trying to = fix it up */ exit_ret =3D -EAGAIN; @@ -597,16 +592,14 @@ static int gntdev_mmap (struct file *fli SetPageReserved(page); =20 /* Record the grant handle, for use in the unmap operation.= */ - private_data->grants[slot_index+i].u.valid.kernel_handle = =3D=20 - op.handle; - private_data->grants[slot_index+i].u.valid.dev_bus_addr = =3D=20 - op.dev_bus_addr; + grants[i].u.valid.kernel_handle =3D op.handle; =09 - private_data->grants[slot_index+i].state =3D GNTDEV_SLOT_MA= PPED; - private_data->grants[slot_index+i].u.valid.user_handle =3D - GNTDEV_INVALID_HANDLE; + grants[i].state =3D GNTDEV_SLOT_MAPPED; + grants[i].u.valid.user_handle =3D GNTDEV_INVALID_HANDLE; =20 /* Now perform the mapping to user space. */ + user_vaddr =3D get_user_vaddr(vma, i); + if (xen_feature(XENFEAT_auto_translated_physmap)) { /* USING SHADOW PAGE TABLES. */ /* In this case, we simply insert the page into = the VM @@ -622,11 +615,11 @@ static int gntdev_mmap (struct file *fli /* In this case, we map the grant(s) straight into user * space. */ + mfn =3D op.dev_bus_addr >> PAGE_SHIFT; =20 /* Get the machine address of the PTE for the user page. = */ if ((ret =3D create_lookup_pte_addr(vma->vm_mm, - vma->vm_start - + (i << PAGE_SHIFT), + user_vaddr, &ptep))) { printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n", @@ -636,9 +629,6 @@ static int gntdev_mmap (struct file *fli =20 /* Configure the map operation. */ =20 - /* The reference is to be used by host CPUs. */ - flags =3D GNTMAP_host_map; - /* Specifies a user space mapping. */ flags |=3D GNTMAP_application_map; =20 @@ -647,14 +637,9 @@ static int gntdev_mmap (struct file *fli */ flags |=3D GNTMAP_contains_pte; =20 - if (!(vma->vm_flags & VM_WRITE)) - flags |=3D GNTMAP_readonly; - gnttab_set_map_op(&op, ptep, flags, - private_data->grants[slot_index+i] - .u.valid.ref, - private_data->grants[slot_index+i] - .u.valid.domid); + grants[i].u.valid.ref, + grants[i].u.valid.domid); =20 /* Carry out the mapping of the grant reference. */ ret =3D HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, @@ -664,10 +649,8 @@ static int gntdev_mmap (struct file *fli printk(KERN_ERR "Error mapping the grant reference = " "into user space (%d). domid =3D %d; ref = =3D %d\n", op.status, - private_data->grants[slot_index+i].u - .valid.domid, - private_data->grants[slot_index+i].u - .valid.ref); + grants[i].u.valid.domid, + grants[i].u.valid.ref); /* This should never happen after we've mapped = into * the kernel space. */ BUG_ON(op.status =3D=3D GNTST_eagain); @@ -677,15 +660,11 @@ static int gntdev_mmap (struct file *fli /* Record the grant handle, for use in the unmap * operation. */ - private_data->grants[slot_index+i].u.valid.user_handle - =3D op.handle; + grants[i].u.valid.user_handle =3D op.handle; =20 /* Update p2m structure with the new mapping. */ set_phys_to_machine(__pa(kernel_vaddr) >> PAGE_SHIFT, - FOREIGN_FRAME(private_data-> - grants[slot_index+i] - .u.valid.dev_bus_addr - >> PAGE_SHIFT)); + FOREIGN_FRAME(mfn)); } exit_ret =3D 0; =20 @@ -715,9 +694,11 @@ undo_map_out: static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long = addr, pte_t *ptep, int is_fullmm) { - int slot_index, ret; + int ret; + unsigned int nr; + unsigned long slot_index; pte_t copy; - struct gnttab_unmap_grant_ref op; + struct gnttab_unmap_grant_ref op[2]; gntdev_file_private_data_t *private_data; =20 /* THIS IS VERY UNPLEASANT: do_mmap_pgoff() will set the vma->vm_fi= le @@ -750,36 +731,35 @@ static pte_t gntdev_clear_pte(struct vm_ return copy; } =20 - /* First, we clear the user space mapping, if it has been made. - */ + /* Clear the user space mapping, if it has been made. */ if (private_data->grants[slot_index].u.valid.user_handle !=3D - GNTDEV_INVALID_HANDLE && - !xen_feature(XENFEAT_auto_translated_physmap)) { - /* NOT USING SHADOW PAGE TABLES. */ - gnttab_set_unmap_op(&op, ptep_to_machine(ptep), + GNTDEV_INVALID_HANDLE) { + /* NOT USING SHADOW PAGE TABLES (and user handle valid). = */ + gnttab_set_unmap_op(&op[0], ptep_to_machine(ptep), GNTMAP_contains_pte, private_data->grants[slot_index].u.vali= d .user_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= - &op, 1); - BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("User unmap grant status =3D %d\n", = op.status); + nr =3D 1; } else { - /* USING SHADOW PAGE TABLES. */ + /* USING SHADOW PAGE TABLES (or user handle invalid). */ pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm); + nr =3D 0; } =20 - /* Finally, we unmap the grant from kernel space. */ - gnttab_set_unmap_op(&op, + /* We always unmap the grant from kernel space. */ + gnttab_set_unmap_op(&op[nr], get_kernel_vaddr(private_data, slot_index), GNTMAP_host_map, private_data->grants[slot_index].u.valid .kernel_handle); - ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, = 1); + + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, nr = + 1); BUG_ON(ret); - if (op.status !=3D GNTST_okay) - printk("Kernel unmap grant status =3D %d\n", op.status); + + if (nr && op[0].status !=3D GNTST_okay) + printk("User unmap grant status =3D %d\n", op[0].status); + if (op[nr].status !=3D GNTST_okay) + printk("Kernel unmap grant status =3D %d\n", op[nr].status)= ; =20 /* Return slot to the not-yet-mapped state, so that it may be * mapped again, or removed by a subsequent ioctl. @@ -915,7 +895,8 @@ private_data_initialised: return -EFAULT; =20 start_index =3D op.index >> PAGE_SHIFT; - if (start_index + op.count > private_data->grants_size) + if (start_index + op.count < start_index || + start_index + op.count > private_data->grants_size) return -EINVAL; =20 down_write(&private_data->grants_sem); @@ -924,28 +905,29 @@ private_data_initialised: * state. */ for (i =3D 0; i < op.count; ++i) { - if (unlikely - (private_data->grants[start_index + i].state - !=3D GNTDEV_SLOT_NOT_YET_MAPPED)) { - if (private_data->grants[start_index + = i].state - =3D=3D GNTDEV_SLOT_INVALID) { - printk(KERN_ERR - "Tried to remove an invalid = " - "grant at offset 0x%x.", - (start_index + i)=20 - << PAGE_SHIFT); - rc =3D -EINVAL; - } else { - printk(KERN_ERR - "Tried to remove a grant = which " - "is currently mmap()-ed at = " - "offset 0x%x.", - (start_index + i)=20 - << PAGE_SHIFT); - rc =3D -EBUSY; - } - goto unmap_out; + const char *what; + + switch (private_data->grants[start_index + = i].state) { + case GNTDEV_SLOT_NOT_YET_MAPPED: + continue; + case GNTDEV_SLOT_INVALID: + what =3D "invalid"; + rc =3D -EINVAL; + break; + case GNTDEV_SLOT_MAPPED: + what =3D "currently mmap()-ed"; + rc =3D -EBUSY; + break; + default: + what =3D "in an invalid state"; + rc =3D -ENXIO; + break; } + printk(KERN_ERR "%s[%d] tried to remove a grant" + " which is %s at %#x+%#x\n", + current->comm, current->pid, + what, start_index, i); + goto unmap_out; } =20 down_write(&private_data->free_list_sem); --=__Part2A04C37A.0__= Content-Type: text/plain; name="xen-gntdev-cleanup.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-gntdev-cleanup.patch" gntdev: misc cleanup=0A=0A- eliminate struct gntdev_grant_info's dev_bus_ad= dr member (which was=0A used to communicate a value inside the main loop = of gntdev_mmap())=0A- correct types=0A- use a local variable 'grants' in = gntdev_mmap() to improve readability=0A- avoid re-calculating already = calculated values=0A- properly check for out of range values=0A- combine = both GNTTABOP_unmap_grant_ref calls in gntdev_clear_pte()=0A into a = single hypercall=0A- adjust error diagnostic in unmap ioctl to be more = useful and better=0A legible=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gn= tdev.c=0A@@ -80,7 +80,6 @@ typedef struct gntdev_grant_info {=0A = grant_ref_t ref;=0A grant_handle_t kernel_handl= e;=0A grant_handle_t user_handle;=0A- = uint64_t dev_bus_addr;=0A } valid;=0A } u;=0A } = gntdev_grant_info_t;=0A@@ -473,14 +472,14 @@ static int gntdev_mmap = (struct file *fli=0A {=0A struct gnttab_map_grant_ref op;=0A = unsigned long slot_index =3D vma->vm_pgoff;=0A- unsigned long kernel_vaddr,= user_vaddr;=0A- uint32_t size =3D (vma->vm_end - vma->vm_start) >> = PAGE_SHIFT;=0A+ unsigned long kernel_vaddr, user_vaddr, mfn;=0A+ = unsigned long size =3D (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;=0A = uint64_t ptep;=0A int ret, exit_ret;=0A- int flags;=0A- int i;=0A+ = unsigned int i, flags;=0A struct page *page;=0A gntdev_file_private= _data_t *private_data =3D flip->private_data;=0A+ gntdev_grant_info_t= *grants;=0A struct vm_foreign_map *foreign_map;=0A =0A if = (unlikely(!private_data)) {=0A@@ -490,17 +489,19 @@ static int gntdev_mmap = (struct file *fli=0A =0A /* Test to make sure that the grants array = has been initialised. */=0A down_read(&private_data->grants_sem);=0A- = if (unlikely(!private_data->grants)) {=0A- up_read(&private_da= ta->grants_sem);=0A+ grants =3D private_data->grants;=0A+ up_read(&pr= ivate_data->grants_sem);=0A+=0A+ if (unlikely(!grants)) {=0A = printk(KERN_ERR "Attempted to mmap before ioctl.\n");=0A = return -EINVAL;=0A }=0A- up_read(&private_data->grants_sem);=0A+ = grants +=3D slot_index;=0A =0A- if (unlikely((size <=3D 0) || =0A- = (size + slot_index) > private_data->grants_size)) {=0A+ if = (unlikely(size + slot_index <=3D slot_index ||=0A+ size = + slot_index > private_data->grants_size)) {=0A printk(KERN= _ERR "Invalid number of pages or offset"=0A- "(num_pages = =3D %d, first_slot =3D %ld).\n",=0A+ "(num_pages =3D = %lu, first_slot =3D %lu)\n",=0A size, slot_index);= =0A return -ENXIO;=0A }=0A@@ -521,11 +522,10 @@ static = int gntdev_mmap (struct file *fli=0A /* Slots must be in the NOT_YET_MAP= PED state. */=0A down_write(&private_data->grants_sem);=0A = for (i =3D 0; i < size; ++i) {=0A- if (private_data->grants[sl= ot_index + i].state !=3D =0A- GNTDEV_SLOT_NOT_YET_MAPPED) = {=0A- printk(KERN_ERR "Slot (index =3D %ld) is in the = wrong "=0A+ if (grants[i].state !=3D GNTDEV_SLOT_NOT_YET_MAPPED= ) {=0A+ printk(KERN_ERR "Slot (index =3D %lu) is in the = wrong "=0A "state (%d).\n", slot_index + i, = =0A- private_data->grants[slot_index + i].state);= =0A+ grants[i].state);=0A = up_write(&private_data->grants_sem);=0A kfree(forei= gn_map);=0A return -EINVAL;=0A@@ -565,14 +565,11 @@ = static int gntdev_mmap (struct file *fli=0A flags |=3D = GNTMAP_readonly;=0A =0A kernel_vaddr =3D get_kernel_vaddr(p= rivate_data, slot_index + i);=0A- user_vaddr =3D get_user_vad= dr(vma, i);=0A page =3D private_data->foreign_pages[slot_index + = i];=0A =0A gnttab_set_map_op(&op, kernel_vaddr, flags, =0A- = private_data->grants[slot_index+i]=0A- = .u.valid.ref, =0A- = private_data->grants[slot_index+i]=0A- = .u.valid.domid);=0A+ grants[i].u.valid.ref,=0A= + grants[i].u.valid.domid);=0A =0A = /* Carry out the mapping of the grant reference. */=0A ret =3D = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, =0A@@ -583,10 +580,8 @@ = static int gntdev_mmap (struct file *fli=0A = printk(KERN_ERR "Error mapping the grant reference "=0A = "into the kernel (%d). domid =3D %d; ref =3D %d\n",=0A = op.status,=0A- = private_data->grants[slot_index+i]=0A- = .u.valid.domid,=0A- private_data->grants= [slot_index+i]=0A- .u.valid.ref);=0A+ = grants[i].u.valid.domid,=0A+ = grants[i].u.valid.ref);=0A else=0A = /* Propagate eagain instead of trying to fix it up = */=0A exit_ret =3D -EAGAIN;=0A@@ -597,16 +592,14 = @@ static int gntdev_mmap (struct file *fli=0A SetPageReserved(pag= e);=0A =0A /* Record the grant handle, for use in the unmap = operation. */=0A- private_data->grants[slot_index+i].u.valid.= kernel_handle =3D =0A- op.handle;=0A- private_dat= a->grants[slot_index+i].u.valid.dev_bus_addr =3D =0A- = op.dev_bus_addr;=0A+ grants[i].u.valid.kernel_handle =3D = op.handle;=0A =0A- private_data->grants[slot_index+i].= state =3D GNTDEV_SLOT_MAPPED;=0A- private_data->grants[slot_i= ndex+i].u.valid.user_handle =3D=0A- GNTDEV_INVALID_HAND= LE;=0A+ grants[i].state =3D GNTDEV_SLOT_MAPPED;=0A+ = grants[i].u.valid.user_handle =3D GNTDEV_INVALID_HANDLE;=0A =0A = /* Now perform the mapping to user space. */=0A+ user_vaddr = =3D get_user_vaddr(vma, i);=0A+=0A if (xen_feature(XENFEAT_aut= o_translated_physmap)) {=0A /* USING SHADOW PAGE = TABLES. */=0A /* In this case, we simply insert the page = into the VM=0A@@ -622,11 +615,11 @@ static int gntdev_mmap (struct file = *fli=0A /* In this case, we map the grant(s) straight into = user=0A * space.=0A */=0A+ mfn =3D = op.dev_bus_addr >> PAGE_SHIFT;=0A =0A /* Get the machine address = of the PTE for the user page. */=0A if ((ret =3D create_lookup_= pte_addr(vma->vm_mm,=0A- = vma->vm_start=0A- + (i << = PAGE_SHIFT),=0A+ = user_vaddr,=0A &ptep)))=0A = {=0A printk(KERN_ERR "Error obtaining PTE pointer = (%d)\n",=0A@@ -636,9 +629,6 @@ static int gntdev_mmap (struct file *fli=0A = =0A /* Configure the map operation. */=0A =0A- /* = The reference is to be used by host CPUs. */=0A- flags =3D = GNTMAP_host_map;=0A-=0A /* Specifies a user space mapping. = */=0A flags |=3D GNTMAP_application_map;=0A =0A@@ -647,14 +637,9 = @@ static int gntdev_mmap (struct file *fli=0A */=0A = flags |=3D GNTMAP_contains_pte;=0A =0A- if (!(vma->vm_flags & = VM_WRITE))=0A- flags |=3D GNTMAP_readonly;=0A-=0A = gnttab_set_map_op(&op, ptep, flags,=0A- = private_data->grants[slot_index+i]=0A- = .u.valid.ref,=0A- private_data->grants[slot= _index+i]=0A- .u.valid.domid);=0A+ = grants[i].u.valid.ref,=0A+ = grants[i].u.valid.domid);=0A =0A /* Carry out the mapping = of the grant reference. */=0A ret =3D HYPERVISOR_grant_table_op(G= NTTABOP_map_grant_ref,=0A@@ -664,10 +649,8 @@ static int gntdev_mmap = (struct file *fli=0A printk(KERN_ERR "Error mapping the = grant reference "=0A "into user space (%d). = domid =3D %d; ref =3D %d\n",=0A op.status,= =0A- private_data->grants[slot_index+i].u=0A- = .valid.domid,=0A- private_data= ->grants[slot_index+i].u=0A- .valid.ref);=0A+ = grants[i].u.valid.domid,=0A+ = grants[i].u.valid.ref);=0A /* This should never = happen after we've mapped into=0A * the kernel = space. */=0A BUG_ON(op.status =3D=3D GNTST_eagain);=0A@@= -677,15 +660,11 @@ static int gntdev_mmap (struct file *fli=0A = /* Record the grant handle, for use in the unmap=0A * = operation.=0A */=0A- private_data->grants[slot_index+i].= u.valid.user_handle=0A- =3D op.handle;=0A+ = grants[i].u.valid.user_handle =3D op.handle;=0A =0A /* Update = p2m structure with the new mapping. */=0A set_phys_to_machine= (__pa(kernel_vaddr) >> PAGE_SHIFT,=0A- = FOREIGN_FRAME(private_data->=0A- = grants[slot_index+i]=0A- = .u.valid.dev_bus_addr=0A- = >> PAGE_SHIFT));=0A+ FOREIGN_FRAME(mfn));=0A= }=0A exit_ret =3D 0;=0A =0A@@ -715,9 +694,11 @@ undo_map_out:=0A= static pte_t gntdev_clear_pte(struct vm_area_struct *vma, unsigned long = addr,=0A pte_t *ptep, int is_fullmm)=0A {=0A- = int slot_index, ret;=0A+ int ret;=0A+ unsigned int nr;=0A+ = unsigned long slot_index;=0A pte_t copy;=0A- struct gnttab_unmap_grant_r= ef op;=0A+ struct gnttab_unmap_grant_ref op[2];=0A gntdev_file= _private_data_t *private_data;=0A =0A /* THIS IS VERY UNPLEASANT: = do_mmap_pgoff() will set the vma->vm_file=0A@@ -750,36 +731,35 @@ static = pte_t gntdev_clear_pte(struct vm_=0A return copy;=0A = }=0A =0A- /* First, we clear the user space mapping, if it has been = made.=0A- */=0A+ /* Clear the user space mapping, if it has been = made. */=0A if (private_data->grants[slot_index].u.valid.user_handle = !=3D=0A- GNTDEV_INVALID_HANDLE &&=0A- !xen_feature(XE= NFEAT_auto_translated_physmap)) {=0A- /* NOT USING SHADOW PAGE = TABLES. */=0A- gnttab_set_unmap_op(&op, ptep_to_machine(ptep),=0A+= GNTDEV_INVALID_HANDLE) {=0A+ /* NOT USING = SHADOW PAGE TABLES (and user handle valid). */=0A+ gnttab_set_= unmap_op(&op[0], ptep_to_machine(ptep),=0A = GNTMAP_contains_pte,=0A private_data->g= rants[slot_index].u.valid=0A .user_handle);= =0A- ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,= =0A- &op, 1);=0A- = BUG_ON(ret);=0A- if (op.status !=3D GNTST_okay)=0A- = printk("User unmap grant status =3D %d\n", op.status);=0A+ = nr =3D 1;=0A } else {=0A- /* USING SHADOW PAGE TABLES. = */=0A+ /* USING SHADOW PAGE TABLES (or user handle invalid). = */=0A pte_clear_full(vma->vm_mm, addr, ptep, is_fullmm);=0A+ = nr =3D 0;=0A }=0A =0A- /* Finally, we unmap the grant from kernel = space. */=0A- gnttab_set_unmap_op(&op,=0A+ /* We always unmap the = grant from kernel space. */=0A+ gnttab_set_unmap_op(&op[nr],=0A = get_kernel_vaddr(private_data, slot_index),=0A = GNTMAP_host_map,=0A private_data->grants[sl= ot_index].u.valid=0A .kernel_handle);=0A- = ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);=0A+=0A= + ret =3D HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op, nr = + 1);=0A BUG_ON(ret);=0A- if (op.status !=3D GNTST_okay)=0A- = printk("Kernel unmap grant status =3D %d\n", op.status);=0A+=0A+ = if (nr && op[0].status !=3D GNTST_okay)=0A+ printk("User unmap = grant status =3D %d\n", op[0].status);=0A+ if (op[nr].status !=3D = GNTST_okay)=0A+ printk("Kernel unmap grant status =3D %d\n", = op[nr].status);=0A =0A /* Return slot to the not-yet-mapped state, so = that it may be=0A * mapped again, or removed by a subsequent = ioctl.=0A@@ -915,7 +895,8 @@ private_data_initialised:=0A = return -EFAULT;=0A =0A start_index =3D op.index >> PAGE_SHIFT;=0A-= if (start_index + op.count > private_data->grants_size)=0A+= if (start_index + op.count < start_index ||=0A+ = start_index + op.count > private_data->grants_size)=0A = return -EINVAL;=0A =0A down_write(&private_data->grants_sem);=0A@@= -924,28 +905,29 @@ private_data_initialised:=0A * = state.=0A */=0A for (i =3D 0; i < op.count; ++i) = {=0A- if (unlikely=0A- = (private_data->grants[start_index + i].state=0A- = !=3D GNTDEV_SLOT_NOT_YET_MAPPED)) {=0A- if = (private_data->grants[start_index + i].state=0A- = =3D=3D GNTDEV_SLOT_INVALID) {=0A- = printk(KERN_ERR=0A- "Tried to = remove an invalid "=0A- "grant at = offset 0x%x.",=0A- (start_index= + i) =0A- << PAGE_SHIFT);=0A- = rc =3D -EINVAL;=0A- = } else {=0A- printk(KERN_ERR=0A- = "Tried to remove a grant which "=0A- = "is currently mmap()-ed at "=0A- = "offset 0x%x.",=0A- = (start_index + i) =0A- << = PAGE_SHIFT);=0A- rc =3D -EBUSY;=0A- = }=0A- goto unmap_out;=0A+= const char *what;=0A+=0A+ = switch (private_data->grants[start_index + i].state) {=0A+ = case GNTDEV_SLOT_NOT_YET_MAPPED:=0A+ = continue;=0A+ case GNTDEV_SLOT_INVALID:=0A+ = what =3D "invalid";=0A+ rc =3D -EINVAL;=0A+= break;=0A+ case = GNTDEV_SLOT_MAPPED:=0A+ what =3D "currently = mmap()-ed";=0A+ rc =3D -EBUSY;=0A+ = break;=0A+ default:=0A+ = what =3D "in an invalid state";=0A+ rc =3D = -ENXIO;=0A+ break;=0A = }=0A+ printk(KERN_ERR "%s[%d] tried to remove a = grant"=0A+ " which is %s at %#x+%#x\n",=0A+ = current->comm, current->pid,=0A+ = what, start_index, i);=0A+ goto unmap_out;=0A = }=0A =0A down_write(&private_data->free_list_sem);=0A --=__Part2A04C37A.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part2A04C37A.0__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:20:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVAa-0003QC-8s; Thu, 10 May 2012 15:20:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVAZ-0003Pu-75 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:20:43 +0000 Received: from [193.109.254.147:45790] by server-4.bemta-14.messagelabs.com id DC/8D-11570-ACCDBAF4; Thu, 10 May 2012 15:20:42 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336663237!8655149!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20161 invoked from network); 10 May 2012 15:20:38 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-8.tower-27.messagelabs.com with SMTP; 10 May 2012 15:20:38 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 08:20:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98561246" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 10 May 2012 08:20:37 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 08:20:36 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Thu, 10 May 2012 23:20:34 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQ Date: Thu, 10 May 2012 15:20:34 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> In-Reply-To: <20120510145745.GO26152@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just notice your reply (so quick :) Agree and will update later, except 1 concern below. Konrad Rzeszutek Wilk wrote: >> >> Hmm, it's good if it's convenient to do it automatically via >> dev->release. >> However, dev container (pcpu) would be free at some other error >> cases, so I prefer do it 'manually'. > > You could also call pcpu_release(..) to do it manually. > that means kfree(pcpu) would be done twice at some error cases, do you think it really good? Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:20:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVAa-0003QC-8s; Thu, 10 May 2012 15:20:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVAZ-0003Pu-75 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:20:43 +0000 Received: from [193.109.254.147:45790] by server-4.bemta-14.messagelabs.com id DC/8D-11570-ACCDBAF4; Thu, 10 May 2012 15:20:42 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336663237!8655149!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3OTkx\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20161 invoked from network); 10 May 2012 15:20:38 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-8.tower-27.messagelabs.com with SMTP; 10 May 2012 15:20:38 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 10 May 2012 08:20:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98561246" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 10 May 2012 08:20:37 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 08:20:36 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Thu, 10 May 2012 23:20:34 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQ Date: Thu, 10 May 2012 15:20:34 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> In-Reply-To: <20120510145745.GO26152@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just notice your reply (so quick :) Agree and will update later, except 1 concern below. Konrad Rzeszutek Wilk wrote: >> >> Hmm, it's good if it's convenient to do it automatically via >> dev->release. >> However, dev container (pcpu) would be free at some other error >> cases, so I prefer do it 'manually'. > > You could also call pcpu_release(..) to do it manually. > that means kfree(pcpu) would be done twice at some error cases, do you think it really good? Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:21:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:21:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVBD-0003Wm-Mo; Thu, 10 May 2012 15:21:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVBC-0003WR-Gy for xen-devel@lists.xen.org; Thu, 10 May 2012 15:21:22 +0000 Received: from [193.109.254.147:44127] by server-10.bemta-14.messagelabs.com id 7E/CA-05847-1FCDBAF4; Thu, 10 May 2012 15:21:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336663280!1763756!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6807 invoked from network); 10 May 2012 15:21: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; 10 May 2012 15:21:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411160" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:21: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, 10 May 2012 16:21:20 +0100 Message-ID: <1336663279.14220.13.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 10 May 2012 16:21:19 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andres Lagar-Cavilla , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 03 of 11] arm: Implement get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:59 +0100, Tim Deegan wrote: > # HG changeset patch > # User Tim Deegan > # Date 1336661656 -3600 > # Node ID d774bb5c6326d1a7e88a3bfadc546d154a2ad895 > # Parent e03806b10f0026590e7775008f24d2a96051552e > arm: Implement get_page_from_gfn() > > We will be calling this from common code, so add a basic > implementation to arch/arm. > > After 4.2 we should reshuffle some of the p2m interface out of > arch/x86 into common headers; for now duplicate a little bit of it. > > Signed-off-by: Tim Deegan Acked-by: Ian Campbell Feel free to commit along with the rest of the series. Ian. > > diff -r e03806b10f00 -r d774bb5c6326 xen/include/asm-arm/p2m.h > --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -53,6 +53,28 @@ p2m_pod_decrease_reservation(struct doma > xen_pfn_t gpfn, > unsigned int order); > > +/* Look up a GFN and take a reference count on the backing page. */ > +typedef int p2m_type_t; > +typedef unsigned int p2m_query_t; > +#define P2M_ALLOC (1u<<0) /* Populate PoD and paged-out entries */ > +#define P2M_UNSHARE (1u<<1) /* Break CoW sharing */ > + > +static inline struct page_info *get_page_from_gfn( > + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) > +{ > + struct page_info *page; > + unsigned long mfn = gmfn_to_mfn(d, gfn); > + > + ASSERT(t == NULL); > + > + if (!mfn_valid(mfn)) > + return NULL; > + page = mfn_to_page(mfn); > + if ( !get_page(page, d) ) > + return NULL; > + return page; > +} > + > /* Compatibility function exporting the old untyped interface */ > static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) > { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:21:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:21:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVBD-0003Wm-Mo; Thu, 10 May 2012 15:21:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVBC-0003WR-Gy for xen-devel@lists.xen.org; Thu, 10 May 2012 15:21:22 +0000 Received: from [193.109.254.147:44127] by server-10.bemta-14.messagelabs.com id 7E/CA-05847-1FCDBAF4; Thu, 10 May 2012 15:21:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336663280!1763756!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6807 invoked from network); 10 May 2012 15:21: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; 10 May 2012 15:21:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411160" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:21: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, 10 May 2012 16:21:20 +0100 Message-ID: <1336663279.14220.13.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 10 May 2012 16:21:19 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andres Lagar-Cavilla , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 03 of 11] arm: Implement get_page_from_gfn() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:59 +0100, Tim Deegan wrote: > # HG changeset patch > # User Tim Deegan > # Date 1336661656 -3600 > # Node ID d774bb5c6326d1a7e88a3bfadc546d154a2ad895 > # Parent e03806b10f0026590e7775008f24d2a96051552e > arm: Implement get_page_from_gfn() > > We will be calling this from common code, so add a basic > implementation to arch/arm. > > After 4.2 we should reshuffle some of the p2m interface out of > arch/x86 into common headers; for now duplicate a little bit of it. > > Signed-off-by: Tim Deegan Acked-by: Ian Campbell Feel free to commit along with the rest of the series. Ian. > > diff -r e03806b10f00 -r d774bb5c6326 xen/include/asm-arm/p2m.h > --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -53,6 +53,28 @@ p2m_pod_decrease_reservation(struct doma > xen_pfn_t gpfn, > unsigned int order); > > +/* Look up a GFN and take a reference count on the backing page. */ > +typedef int p2m_type_t; > +typedef unsigned int p2m_query_t; > +#define P2M_ALLOC (1u<<0) /* Populate PoD and paged-out entries */ > +#define P2M_UNSHARE (1u<<1) /* Break CoW sharing */ > + > +static inline struct page_info *get_page_from_gfn( > + struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) > +{ > + struct page_info *page; > + unsigned long mfn = gmfn_to_mfn(d, gfn); > + > + ASSERT(t == NULL); > + > + if (!mfn_valid(mfn)) > + return NULL; > + page = mfn_to_page(mfn); > + if ( !get_page(page, d) ) > + return NULL; > + return page; > +} > + > /* Compatibility function exporting the old untyped interface */ > static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) > { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:25:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSVFU-0003ul-HG; Thu, 10 May 2012 15:25:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVFT-0003ud-6T for xen-devel@lists.xen.org; Thu, 10 May 2012 15:25:47 +0000 Received: from [85.158.143.35:29669] by server-3.bemta-4.messagelabs.com id 56/04-05853-AFDDBAF4; Thu, 10 May 2012 15:25:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336663545!10410443!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20542 invoked from network); 10 May 2012 15:25:45 -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; 10 May 2012 15:25:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411263" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15: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; Thu, 10 May 2012 16:24:55 +0100 Message-ID: <1336663493.14220.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 10 May 2012 16:24:53 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andres Lagar-Cavilla , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11 of 11] x86/p2m, arm/p2m: remove get_gfn_untyped() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:59 +0100, Tim Deegan wrote: > # HG changeset patch > # User Tim Deegan > # Date 1336661656 -3600 > # Node ID d95f0fb6c358f7e2624d317da6e405e8d733603a > # Parent 65768e16352c6bb0e11bb6c661da5137e99ecceb > x86/p2m, arm/p2m: remove get_gfn_untyped(). > > Adjust its only user to use get_gfn. > > Signed-off-by: Andres Lagar-Cavilla > Signed-off-by: Tim Deegan (trivial) ARM bit: Acked-by: Ian Campbell > > diff -r 65768e16352c -r d95f0fb6c358 xen/arch/x86/mm.c > --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 > +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 > @@ -4524,6 +4524,7 @@ static int xenmem_add_to_physmap_once( > unsigned long gfn = 0; /* gcc ... */ > unsigned long prev_mfn, mfn = 0, gpfn, idx; > int rc; > + p2m_type_t p2mt; > > switch ( xatp->space ) > { > @@ -4596,7 +4597,7 @@ static int xenmem_add_to_physmap_once( > put_page(page); > > /* Remove previously mapped page if it was present. */ > - prev_mfn = get_gfn_untyped(d, xatp->gpfn); > + prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt)); > if ( mfn_valid(prev_mfn) ) > { > if ( is_xen_heap_mfn(prev_mfn) ) > diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-arm/p2m.h > --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -75,12 +75,6 @@ static inline struct page_info *get_page > return page; > } > > -/* 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, > diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-x86/p2m.h > --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -339,17 +339,6 @@ static inline mfn_t get_gfn_type(struct > #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \ > P2M_ALLOC | P2M_UNSHARE) > > -/* Compatibility function exporting the old untyped interface */ > -static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) > -{ > - mfn_t mfn; > - p2m_type_t t; > - mfn = get_gfn(d, gpfn, &t); > - if ( p2m_is_valid(t) ) > - return mfn_x(mfn); > - return INVALID_MFN; > -} > - > /* Will release the p2m_lock for this gfn entry. */ > void __put_gfn(struct p2m_domain *p2m, unsigned long gfn); > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:25:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSVFU-0003ul-HG; Thu, 10 May 2012 15:25:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVFT-0003ud-6T for xen-devel@lists.xen.org; Thu, 10 May 2012 15:25:47 +0000 Received: from [85.158.143.35:29669] by server-3.bemta-4.messagelabs.com id 56/04-05853-AFDDBAF4; Thu, 10 May 2012 15:25:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336663545!10410443!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20542 invoked from network); 10 May 2012 15:25:45 -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; 10 May 2012 15:25:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411263" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15: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; Thu, 10 May 2012 16:24:55 +0100 Message-ID: <1336663493.14220.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 10 May 2012 16:24:53 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Andres Lagar-Cavilla , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11 of 11] x86/p2m, arm/p2m: remove get_gfn_untyped() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-05-10 at 15:59 +0100, Tim Deegan wrote: > # HG changeset patch > # User Tim Deegan > # Date 1336661656 -3600 > # Node ID d95f0fb6c358f7e2624d317da6e405e8d733603a > # Parent 65768e16352c6bb0e11bb6c661da5137e99ecceb > x86/p2m, arm/p2m: remove get_gfn_untyped(). > > Adjust its only user to use get_gfn. > > Signed-off-by: Andres Lagar-Cavilla > Signed-off-by: Tim Deegan (trivial) ARM bit: Acked-by: Ian Campbell > > diff -r 65768e16352c -r d95f0fb6c358 xen/arch/x86/mm.c > --- a/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 > +++ b/xen/arch/x86/mm.c Thu May 10 15:54:16 2012 +0100 > @@ -4524,6 +4524,7 @@ static int xenmem_add_to_physmap_once( > unsigned long gfn = 0; /* gcc ... */ > unsigned long prev_mfn, mfn = 0, gpfn, idx; > int rc; > + p2m_type_t p2mt; > > switch ( xatp->space ) > { > @@ -4596,7 +4597,7 @@ static int xenmem_add_to_physmap_once( > put_page(page); > > /* Remove previously mapped page if it was present. */ > - prev_mfn = get_gfn_untyped(d, xatp->gpfn); > + prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt)); > if ( mfn_valid(prev_mfn) ) > { > if ( is_xen_heap_mfn(prev_mfn) ) > diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-arm/p2m.h > --- a/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-arm/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -75,12 +75,6 @@ static inline struct page_info *get_page > return page; > } > > -/* 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, > diff -r 65768e16352c -r d95f0fb6c358 xen/include/asm-x86/p2m.h > --- a/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 > +++ b/xen/include/asm-x86/p2m.h Thu May 10 15:54:16 2012 +0100 > @@ -339,17 +339,6 @@ static inline mfn_t get_gfn_type(struct > #define get_gfn_unshare(d, g, t) get_gfn_type((d), (g), (t), \ > P2M_ALLOC | P2M_UNSHARE) > > -/* Compatibility function exporting the old untyped interface */ > -static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn) > -{ > - mfn_t mfn; > - p2m_type_t t; > - mfn = get_gfn(d, gpfn, &t); > - if ( p2m_is_valid(t) ) > - return mfn_x(mfn); > - return INVALID_MFN; > -} > - > /* Will release the p2m_lock for this gfn entry. */ > void __put_gfn(struct p2m_domain *p2m, unsigned long gfn); > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:29:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVJ5-00046s-6I; Thu, 10 May 2012 15:29:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVJ3-00046k-5V for xen-devel@lists.xen.org; Thu, 10 May 2012 15:29:29 +0000 Received: from [85.158.143.99:47149] by server-3.bemta-4.messagelabs.com id D4/29-05853-8DEDBAF4; Thu, 10 May 2012 15:29:28 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1336663764!26497699!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29832 invoked from network); 10 May 2012 15:29:26 -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; 10 May 2012 15:29:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194281894" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:26:29 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:26:29 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwD-0007Ph-DQ; Thu, 10 May 2012 16:05:53 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwC-0000K2-R1; Thu, 10 May 2012 16:05:52 +0100 MIME-Version: 1.0 X-Mercurial-Node: 28d15a29ab59d29a1fd5deb79ceda5d557343f14 Message-ID: <28d15a29ab59d29a1fd5.1336661991@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:51 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 07 of 11] common: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 28d15a29ab59d29a1fd5deb79ceda5d557343f14 # Parent d19b3ba026fd844d21a250f768f70a1543d6bbd7 common: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r d19b3ba026fd -r 28d15a29ab59 xen/common/memory.c --- a/xen/common/memory.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/memory.c Thu May 10 15:54:16 2012 +0100 @@ -676,7 +676,7 @@ long do_memory_op(unsigned long cmd, XEN case XENMEM_remove_from_physmap: { struct xen_remove_from_physmap xrfp; - unsigned long mfn; + struct page_info *page; struct domain *d; if ( copy_from_guest(&xrfp, arg, 1) ) @@ -694,15 +694,15 @@ long do_memory_op(unsigned long cmd, XEN domain_lock(d); - mfn = get_gfn_untyped(d, xrfp.gpfn); - - if ( mfn_valid(mfn) ) - guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0); + page = get_page_from_gfn(d, xrfp.gpfn, NULL, P2M_ALLOC); + if ( page ) + { + guest_physmap_remove_page(d, xrfp.gpfn, page_to_mfn(page), 0); + put_page(page); + } else rc = -ENOENT; - put_gfn(d, xrfp.gpfn); - domain_unlock(d); rcu_unlock_domain(d); diff -r d19b3ba026fd -r 28d15a29ab59 xen/common/tmem_xen.c --- a/xen/common/tmem_xen.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/tmem_xen.c Thu May 10 15:54:16 2012 +0100 @@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn, pfp_t **pcli_pfp, bool_t cli_write) { - unsigned long cli_mfn; p2m_type_t t; struct page_info *page; - int ret; - cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t)); - if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) ) + page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC); + if ( !page || t != p2m_ram_rw ) { - put_gfn(current->domain, (unsigned long) cmfn); - return NULL; + if ( page ) + put_page(page); } - page = mfn_to_page(cli_mfn); - if ( cli_write ) - ret = get_page_and_type(page, current->domain, PGT_writable_page); - else - ret = get_page(page, current->domain); - if ( !ret ) + + if ( cli_write && !get_page_type(page, PGT_writable_page) ) { - put_gfn(current->domain, (unsigned long) cmfn); + put_page(page); return NULL; } - *pcli_mfn = cli_mfn; + + *pcli_mfn = page_to_mfn(page); *pcli_pfp = (pfp_t *)page; - return map_domain_page(cli_mfn); + return map_domain_page(*pcli_mfn); } static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp, @@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli else put_page((struct page_info *)cli_pfp); unmap_domain_page(cli_va); - put_gfn(current->domain, (unsigned long) cmfn); } #endif diff -r d19b3ba026fd -r 28d15a29ab59 xen/xsm/flask/hooks.c --- a/xen/xsm/flask/hooks.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/xsm/flask/hooks.c Thu May 10 15:54:16 2012 +0100 @@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc struct domain_security_struct *dsec; u32 fsid; struct avc_audit_data ad; + struct page_info *page = NULL; if (d != t) rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP); @@ -1333,8 +1334,9 @@ static int flask_mmu_normal_update(struc map_perms |= MMU__MAP_WRITE; AVC_AUDIT_DATA_INIT(&ad, MEMORY); - fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte))); - + page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), + NULL, P2M_ALLOC); + fmfn = page ? page_to_mfn(page) : INVALID_MFN; ad.sdom = d; ad.tdom = f; ad.memory.pte = fpte; @@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc rc = get_mfn_sid(fmfn, &fsid); - put_gfn(f, fmfn); + if ( page ) + put_page(page); if ( rc ) return rc; @@ -1370,7 +1373,7 @@ static int flask_update_va_mapping(struc int rc = 0; u32 psid; u32 map_perms = MMU__MAP_READ; - unsigned long mfn; + struct page_info *page = NULL; struct domain_security_struct *dsec; if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) ) @@ -1381,8 +1384,10 @@ static int flask_update_va_mapping(struc dsec = d->ssid; - mfn = get_gfn_untyped(f, l1e_get_pfn(pte)); - rc = get_mfn_sid(mfn, &psid); + page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC); + rc = get_mfn_sid(page ? page_to_mfn(page) : INVALID_MFN, &psid); + if ( page ) + put_page(page); if ( rc ) return rc; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:29:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVJ5-00046s-6I; Thu, 10 May 2012 15:29:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVJ3-00046k-5V for xen-devel@lists.xen.org; Thu, 10 May 2012 15:29:29 +0000 Received: from [85.158.143.99:47149] by server-3.bemta-4.messagelabs.com id D4/29-05853-8DEDBAF4; Thu, 10 May 2012 15:29:28 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-13.tower-216.messagelabs.com!1336663764!26497699!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE0NTg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29832 invoked from network); 10 May 2012 15:29:26 -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; 10 May 2012 15:29:26 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="194281894" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 11:26:29 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 11:26:29 -0400 Received: from whitby.uk.xensource.com ([10.80.2.60]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSUwD-0007Ph-DQ; Thu, 10 May 2012 16:05:53 +0100 Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76) (envelope-from ) id 1SSUwC-0000K2-R1; Thu, 10 May 2012 16:05:52 +0100 MIME-Version: 1.0 X-Mercurial-Node: 28d15a29ab59d29a1fd5deb79ceda5d557343f14 Message-ID: <28d15a29ab59d29a1fd5.1336661991@whitby.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.0.1 Date: Thu, 10 May 2012 15:59:51 +0100 From: Tim Deegan To: xen-devel@lists.xen.org Cc: Andres Lagar-Cavilla Subject: [Xen-devel] [PATCH 07 of 11] common: Use get_page_from_gfn() instead of get_gfn()/put_gfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Tim Deegan # Date 1336661656 -3600 # Node ID 28d15a29ab59d29a1fd5deb79ceda5d557343f14 # Parent d19b3ba026fd844d21a250f768f70a1543d6bbd7 common: Use get_page_from_gfn() instead of get_gfn()/put_gfn. Signed-off-by: Tim Deegan Signed-off-by: Andres Lagar-Cavilla diff -r d19b3ba026fd -r 28d15a29ab59 xen/common/memory.c --- a/xen/common/memory.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/memory.c Thu May 10 15:54:16 2012 +0100 @@ -676,7 +676,7 @@ long do_memory_op(unsigned long cmd, XEN case XENMEM_remove_from_physmap: { struct xen_remove_from_physmap xrfp; - unsigned long mfn; + struct page_info *page; struct domain *d; if ( copy_from_guest(&xrfp, arg, 1) ) @@ -694,15 +694,15 @@ long do_memory_op(unsigned long cmd, XEN domain_lock(d); - mfn = get_gfn_untyped(d, xrfp.gpfn); - - if ( mfn_valid(mfn) ) - guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0); + page = get_page_from_gfn(d, xrfp.gpfn, NULL, P2M_ALLOC); + if ( page ) + { + guest_physmap_remove_page(d, xrfp.gpfn, page_to_mfn(page), 0); + put_page(page); + } else rc = -ENOENT; - put_gfn(d, xrfp.gpfn); - domain_unlock(d); rcu_unlock_domain(d); diff -r d19b3ba026fd -r 28d15a29ab59 xen/common/tmem_xen.c --- a/xen/common/tmem_xen.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/common/tmem_xen.c Thu May 10 15:54:16 2012 +0100 @@ -107,30 +107,25 @@ static inline void cli_put_page(tmem_cli static inline void *cli_get_page(tmem_cli_mfn_t cmfn, unsigned long *pcli_mfn, pfp_t **pcli_pfp, bool_t cli_write) { - unsigned long cli_mfn; p2m_type_t t; struct page_info *page; - int ret; - cli_mfn = mfn_x(get_gfn(current->domain, cmfn, &t)); - if ( t != p2m_ram_rw || !mfn_valid(cli_mfn) ) + page = get_page_from_gfn(current->domain, cmfn, &t, P2M_ALLOC); + if ( !page || t != p2m_ram_rw ) { - put_gfn(current->domain, (unsigned long) cmfn); - return NULL; + if ( page ) + put_page(page); } - page = mfn_to_page(cli_mfn); - if ( cli_write ) - ret = get_page_and_type(page, current->domain, PGT_writable_page); - else - ret = get_page(page, current->domain); - if ( !ret ) + + if ( cli_write && !get_page_type(page, PGT_writable_page) ) { - put_gfn(current->domain, (unsigned long) cmfn); + put_page(page); return NULL; } - *pcli_mfn = cli_mfn; + + *pcli_mfn = page_to_mfn(page); *pcli_pfp = (pfp_t *)page; - return map_domain_page(cli_mfn); + return map_domain_page(*pcli_mfn); } static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp, @@ -144,7 +139,6 @@ static inline void cli_put_page(tmem_cli else put_page((struct page_info *)cli_pfp); unmap_domain_page(cli_va); - put_gfn(current->domain, (unsigned long) cmfn); } #endif diff -r d19b3ba026fd -r 28d15a29ab59 xen/xsm/flask/hooks.c --- a/xen/xsm/flask/hooks.c Thu May 10 15:54:16 2012 +0100 +++ b/xen/xsm/flask/hooks.c Thu May 10 15:54:16 2012 +0100 @@ -1318,6 +1318,7 @@ static int flask_mmu_normal_update(struc struct domain_security_struct *dsec; u32 fsid; struct avc_audit_data ad; + struct page_info *page = NULL; if (d != t) rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP); @@ -1333,8 +1334,9 @@ static int flask_mmu_normal_update(struc map_perms |= MMU__MAP_WRITE; AVC_AUDIT_DATA_INIT(&ad, MEMORY); - fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte))); - + page = get_page_from_gfn(f, l1e_get_pfn(l1e_from_intpte(fpte)), + NULL, P2M_ALLOC); + fmfn = page ? page_to_mfn(page) : INVALID_MFN; ad.sdom = d; ad.tdom = f; ad.memory.pte = fpte; @@ -1342,7 +1344,8 @@ static int flask_mmu_normal_update(struc rc = get_mfn_sid(fmfn, &fsid); - put_gfn(f, fmfn); + if ( page ) + put_page(page); if ( rc ) return rc; @@ -1370,7 +1373,7 @@ static int flask_update_va_mapping(struc int rc = 0; u32 psid; u32 map_perms = MMU__MAP_READ; - unsigned long mfn; + struct page_info *page = NULL; struct domain_security_struct *dsec; if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) ) @@ -1381,8 +1384,10 @@ static int flask_update_va_mapping(struc dsec = d->ssid; - mfn = get_gfn_untyped(f, l1e_get_pfn(pte)); - rc = get_mfn_sid(mfn, &psid); + page = get_page_from_gfn(f, l1e_get_pfn(pte), NULL, P2M_ALLOC); + rc = get_mfn_sid(page ? page_to_mfn(page) : INVALID_MFN, &psid); + if ( page ) + put_page(page); if ( rc ) return rc; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:35:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVOP-0004LT-0e; Thu, 10 May 2012 15:35:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVOM-0004LM-VF for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:35:00 +0000 Received: from [85.158.138.51:14741] by server-8.bemta-3.messagelabs.com id 7A/4A-24428-220EBAF4; Thu, 10 May 2012 15:34:58 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336664094!26279570!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21647 invoked from network); 10 May 2012 15:34:55 -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; 10 May 2012 15:34:55 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFYqQW008028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:34: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 q4AFYp8O017068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:34:51 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 q4AFYoU5025893; Thu, 10 May 2012 10:34:50 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:34:48 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D59284032D; Thu, 10 May 2012 11:28:44 -0400 (EDT) Date: Thu, 10 May 2012 11:28:44 -0400 From: Konrad Rzeszutek Wilk To: JBeulich@suse.com, xen-devel@lists.xensource.com Message-ID: <20120510152844.GP26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [Xen-devel] pvops domU guest booting problem - 131GB ok, 132GB not ok. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Jan, I've just started to trying to track down why a pvops 64-bit PV guest can't boot with more than 128GB of memory. The issue I am seeing is that the module loading subsystem stops working and I get this: WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: Pid: 1051, comm: modprobe Not tainted 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dc6 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 1051, comm: modprobe Tainted: G W 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 73 active_anon:253 inactive_anon:31970 isolated_anon:0 active_file:391 inactive_file:27806 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33525733 slab_reclaimable:1660 slab_unreclaimable:976 mapped:340 shmem:31960 pagetables:34 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130456376kB min:45112kB low:56388kB high:67668kB active_anon:1012kB inactive_anon:127880kB active_file:1564kB inactive_file:111224kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:1360kB shmem:127840kB slab_reclaimable:6640kB slab_unreclaimable:3904kB kernel_stack:368kB pagetables:136kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 26*4kB 26*8kB 14*16kB 11*32kB 11*64kB 6*128kB 8*256kB 7*512kB 9*1024kB 3*2048kB 31844*4096kB = 130456376kB 60151 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 983 pages shared 166525 pages non-shared Which tells me that there is more than enough memory. So my thinking is that it is either: - it can't stick the new pagetables in the memory b/c there isn't enough physical space in the region it wants - but the region it uses is Normal, so that should be OK? - it is hitting some page tables that are used by the hypervisor? Was wondering if you had hit this at some point with SLES guests and if there are any ideas of what I should look for ? Thanks! --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="131gb.txt" Content-Transfer-Encoding: quoted-printable console [hvc0] enabled, bootconsole disabled Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2261.074 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. = 4522.14 BogoMIPS (lpj=3D2261074) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 16777216 (order: 15, 134217728 bytes) Inode-cache hash table entries: 8388608 (order: 14, 67108864 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 24k freed cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 46 no PMU driver, software eve= nts only. NMI watchdog: disabled (cpu0): hardware events not enabled Brought up 1 CPUs kworker/u:0 used greatest stack depth: 6000 bytes left Grant tables using version 2 layout. Grant table initialized RTC time: 165:165:165, date: 165/165/65 NET: Registered protocol family 16 kworker/u:0 used greatest stack depth: 5536 bytes left dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size =3D 128 NetLabel: protocols =3D UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 65536 (order: 9, 2097152 bytes) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 227672k freed platform rtc_cmos: registered platform RTC device (no PNP device found) Machine check injector initialized microcode: CPU0 sig=3D0x206e5, pf=3D0x4, revision=3D0xffff0018 microcode: Microcode Update Driver: v2.00 , Pe= ter Oruba audit: initializing netlink socket (disabled) type=3D2000 audit(1336419344.018:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) NFS: Registering the id_resolver key type NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 32768 SELinux: Registering netfilter hooks Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ioatdma: Intel(R) QuickData Technology Driver 4.00 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 brd: module loaded loop: module loaded Fixed MDIO Bus: probed tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - = version 2.2.0-k ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 80 td 96 uhci_hcd: USB Universal Host Controller Interface driver usbcore: registered new interface driver usblp usbcore: registered new interface driver libusual i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ctnetlink v0.93: registering with nfnetlink. ip_tables: (C) 2000-2006 Netfilter Core Team TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Registering the dns_resolver key type PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Magic number: 1:252:3141 Freeing unused kernel memory: 692k freed Write protecting the kernel read-only data: 8192k Freeing unused kernel memory: 292k freed Freeing unused kernel memory: 400k freed BusyBox v1.14.3 (2012-05-07 12:16:33 EDT) consoletype used greatest stack depth: 5336 bytes left ories [ OK ] modprobe used greatest stack depth: 5096 bytes left int /sys/kernel/config does not exist core_filesystem used greatest stack depth: 5016 bytes left Initialising Xen virtual ethernet driver. 16: 2062 xen-percpu-virq timer0 17: 0 xen-percpu-ipi spinlock0 18: 0 xen-percpu-ipi resched0 19: 0 xen-percpu-ipi callfunc0 20: 0 xen-percpu-virq debug0 21: 0 xen-percpu-ipi callfuncsingle0 22: 0 xen-percpu-ipi irqwork0 23: 47 xen-dyn-event xenbus 24: 61 xen-dyn-event hvc_console NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts IWI: 0 IRQ work interrupts RTR: 0 APIC ICR read retries RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts MCE: 0 Machine check exceptions MCP: 0 Machine check polls ERR: 0 MIS: 0 00000000-0000ffff : reserved 00010000-0009ffff : System RAM 000a0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-1f407fffff : System RAM 01000000-015b1d63 : Kernel code 015b1d64-018838bf : Kernel data 01939000-01a1efff : Kernel bss MemTotal: 128734892 kB MemFree: 128251264 kB Buffers: 0 kB Cached: 240696 kB SwapCached: 0 kB Active: 20436 kB Inactive: 219972 kB Active(anon): 14760 kB Inactive(anon): 116532 kB Active(file): 5676 kB Inactive(file): 103440 kB Unevictable: 4876 kB Mlocked: 4896 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 4708 kB Mapped: 5056 kB Shmem: 127992 kB Slab: 15880 kB SReclaimable: 9344 kB SUnreclaim: 6536 kB KernelStack: 328 kB PageTables: 668 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 64367444 kB Committed_AS: 136444 kB VmallocTotal: 34359738367 kB VmallocUsed: 214720 kB VmallocChunk: 34359523635 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 131080192 kB DirectMap2M: 0 kB Waiting for init.late [ OK ] connect: Network is unreachable May 7 19:35:50 (none) rpc.statd[2099]: Caught signal 15, un-registering an= d exiting connect: Network is unreachable May 7 19:35:50 (none) iscsid: semop down failed 22 warning: /sysctl.conf(1): invalid syntax, continuing... net.ipv4.ip_forward =3D 0 net.ipv4.conf.default.rp_filter =3D 2 net.ipv4.conf.default.accept_source_route =3D 0 kernel.sysrq =3D 0 kernel.core_uses_pid =3D 1 net.ipv4.tcp_syncookies =3D 1 kernel.msgmnb =3D 65536 kernel.msgmax =3D 65536 kernel.shmmax =3D 68719476736 kernel.shmall =3D 4294967296 vm.min_free_kbytes =3D 65536 kernel.panic_on_oops =3D 1 kernel.panic =3D 60 Error : Name or service not known Linux (none) 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 SMP Mon May 7 13:30:= 51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux MemTotal: 128734892 kB MemFree: 128254048 kB Buffers: 0 kB Cached: 240844 kB SwapCached: 0 kB Active: 19576 kB Inactive: 219628 kB Active(anon): 13424 kB Inactive(anon): 116512 kB Active(file): 6152 kB Inactive(file): 103116 kB Unevictable: 3584 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 1944 kB Mapped: 1676 kB Shmem: 127992 kB Slab: 15860 kB SReclaimable: 9324 kB SUnreclaim: 6536 kB KernelStack: 320 kB PageTables: 516 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 64367444 kB Committed_AS: 133016 kB VmallocTotal: 34359738367 kB VmallocUsed: 214720 kB VmallocChunk: 34359523635 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 131080192 kB DirectMap2M: 0 kB 0xffffc90000000000-0xffffc90008001000 134221824 alloc_large_system_hash+0x1= 54/0x213 pages=3D32768 vmalloc vpages N0=3D32768 0xffffc90008001000-0xffffc90008042000 266240 alloc_large_system_hash+0x154= /0x213 pages=3D64 vmalloc N0=3D64 0xffffc90008042000-0xffffc9000c043000 67112960 alloc_large_system_hash+0x15= 4/0x213 pages=3D16384 vmalloc vpages N0=3D16384 0xffffc9000c043000-0xffffc9000c064000 135168 alloc_large_system_hash+0x154= /0x213 pages=3D32 vmalloc N0=3D32 0xffffc9000c064000-0xffffc9000c067000 12288 alloc_large_system_hash+0x154= /0x213 pages=3D2 vmalloc N0=3D2 0xffffc9000c068000-0xffffc9000c06d000 20480 arch_gnttab_map_status+0x50/0= x70 ioremap 0xffffc9000c06d000-0xffffc9000c072000 20480 alloc_large_system_hash+0x154= /0x213 pages=3D4 vmalloc N0=3D4 0xffffc9000c072000-0xffffc9000c07e000 49152 zisofs_init+0x11/0x23 pages= =3D11 vmalloc N0=3D11 0xffffc9000c080000-0xffffc9000c0a1000 135168 arch_gnttab_map_shared+0x50/0= x70 ioremap 0xffffc9000c0a1000-0xffffc9000c4a2000 4198400 alloc_large_system_hash+0x154= /0x213 pages=3D1024 vmalloc vpages N0=3D1024 0xffffc9000c4a2000-0xffffc9000cca3000 8392704 alloc_large_system_hash+0x154= /0x213 pages=3D2048 vmalloc vpages N0=3D2048 0xffffc9000cca3000-0xffffc9000cda4000 1052672 alloc_large_system_hash+0x154= /0x213 pages=3D256 vmalloc N0=3D256 0xffffc9000cda4000-0xffffc9000cfa5000 2101248 alloc_large_system_hash+0x154= /0x213 pages=3D512 vmalloc N0=3D512 0xffffc9000cfa5000-0xffffc9000d1a6000 2101248 alloc_large_system_hash+0x154= /0x213 pages=3D512 vmalloc N0=3D512 0xffffc9000d1a6000-0xffffc9000d1b3000 53248 netback_init+0x4c/0x210 pages= =3D12 vmalloc N0=3D12 0xffffffffa0000000-0xffffffffa0005000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0008000-0xffffffffa000d000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0010000-0xffffffffa0015000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0018000-0xffffffffa001d000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa001d000-0xffffffffa0022000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0022000-0xffffffffa0027000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0027000-0xffffffffa002c000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa002c000-0xffffffffa0032000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa0036000-0xffffffffa003e000 32768 module_alloc_update_bounds+0x= 19/0x80 pages=3D7 vmalloc N0=3D7 0xffffffffa0042000-0xffffffffa0049000 28672 module_alloc_update_bounds+0x= 19/0x80 pages=3D6 vmalloc N0=3D6 0xffffffffa004d000-0xffffffffa0052000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0052000-0xffffffffa005c000 40960 module_alloc_update_bounds+0x= 19/0x80 pages=3D9 vmalloc N0=3D9 0xffffffffa005c000-0xffffffffa0061000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0061000-0xffffffffa0074000 77824 module_alloc_update_bounds+0x= 19/0x80 pages=3D18 vmalloc N0=3D18 0xffffffffa0074000-0xffffffffa007a000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa007c000-0xffffffffa0081000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0081000-0xffffffffa0086000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0086000-0xffffffffa0093000 53248 module_alloc_update_bounds+0x= 19/0x80 pages=3D12 vmalloc N0=3D12 0xffffffffa0097000-0xffffffffa0169000 860160 module_alloc_update_bounds+0x= 19/0x80 pages=3D209 vmalloc N0=3D209 0xffffffffa0169000-0xffffffffa016e000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa016e000-0xffffffffa0173000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0173000-0xffffffffa0199000 155648 module_alloc_update_bounds+0x= 19/0x80 pages=3D37 vmalloc N0=3D37 0xffffffffa0199000-0xffffffffa01a4000 45056 module_alloc_update_bounds+0x= 19/0x80 pages=3D10 vmalloc N0=3D10 0xffffffffa01a8000-0xffffffffa01b4000 49152 module_alloc_update_bounds+0x= 19/0x80 pages=3D11 vmalloc N0=3D11 0xffffffffa01b4000-0xffffffffa01ba000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa01ba000-0xffffffffa01c0000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa01c4000-0xffffffffa01c9000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa01c9000-0xffffffffa01ce000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 # lsmod Module Size Used by xen_evtchn 12835 0=20 iscsi_boot_sysfs 12922 0=20 iscsi_tcp 17580 0=20 libiscsi_tcp 17354 1 iscsi_tcp libiscsi 39804 2 iscsi_tcp,libiscsi_tcp scsi_transport_iscsi 43755 2 iscsi_tcp,libiscsi scsi_mod 148537 3 iscsi_tcp,libiscsi,scsi_transport_iscsi libcrc32c 12426 0=20 crc32c 12656 0=20 radeon 854431 0=20 fbcon 47234 0=20 tileblit 12581 1 fbcon font 16484 1 fbcon bitblit 12610 1 fbcon softcursor 12349 1 bitblit ttm 73322 1 radeon drm_kms_helper 35139 1 radeon,[permanent] crc32c_intel 12704 1=20 xen_blkfront 21357 0=20 xen_netfront 25845 0=20 xen_fbfront 17211 0=20 fb_sys_fops 12350 1 xen_fbfront sysimgblt 12313 1 xen_fbfront sysfillrect 12522 1 xen_fbfront syscopyarea 12313 1 xen_fbfront xen_kbdfront 12686 0=20 xenfs 12737 1=20 xen_privcmd 12829 1 xenfs # cat /sys/kernel/debug/=1B[Jker=1B[21D# cat /sys/kernel/debug/kernel_page_= tables =1B[J ---[ User Space ]--- 0x0000000000000000-0xffff800000000000 16777088T = pgd ---[ Kernel Space ]--- 0xffff800000000000-0xffff814000000000 1280G = pud 0xffff814000000000-0xffff8140a0000000 2560M = pmd 0xffff8140a0000000-0xffff8140a0500000 5M = pte 0xffff8140a0500000-0xffff8140a0501000 4K USR RW x= pte 0xffff8140a0501000-0xffff8140a0503000 8K RW x= pte 0xffff8140a0503000-0xffff8140a0504000 4K = pte 0xffff8140a0504000-0xffff8140a0505000 4K RW x= pte 0xffff8140a0505000-0xffff8140a0507000 8K USR RW x= pte 0xffff8140a0507000-0xffff8140a0509000 8K RW x= pte 0xffff8140a0509000-0xffff8140a0510000 28K = pte 0xffff8140a0510000-0xffff8140a0511000 4K USR RW x= pte 0xffff8140a0511000-0xffff8140a0592000 516K = pte 0xffff8140a0592000-0xffff8140a0593000 4K USR RW x= pte 0xffff8140a0593000-0xffff8140a05d4000 260K = pte 0xffff8140a05d4000-0xffff8140a05d5000 4K USR RW x= pte 0xffff8140a05d5000-0xffff8140a05ff000 168K = pte 0xffff8140a05ff000-0xffff8140a0600000 4K USR RW x= pte 0xffff8140a0600000-0xffff8140a0800000 2M = pmd 0xffff8140a0800000-0xffff8140a1200000 10M = pte 0xffff8140a1200000-0xffff8140a2000000 14M = pmd 0xffff8140a2000000-0xffff8140a207e000 504K USR RW x= pte 0xffff8140a207e000-0xffff8140a2200000 1544K = pte 0xffff8140a2200000-0xffff8140b2400000 258M = pmd 0xffff8140b2400000-0xffff8140b2401000 4K USR RW x= pte 0xffff8140b2401000-0xffff8140b2600000 2044K = pte 0xffff8140b2600000-0xffff8140ba800000 130M = pmd 0xffff8140ba800000-0xffff8140ba802000 8K USR RW x= pte 0xffff8140ba802000-0xffff8140baa00000 2040K = pte 0xffff8140baa00000-0xffff8140bfe00000 84M = pmd 0xffff8140bfe00000-0xffff8140bfffe000 2040K = pte 0xffff8140bfffe000-0xffff8140c0000000 8K USR RW x= pte 0xffff8140c0000000-0xffff814100000000 1G = pud 0xffff814100000000-0xffff814240000000 5G = pmd 0xffff814240000000-0xffff814400000000 7G = pud 0xffff814400000000-0xffff81440fa04000 256016K USR RW x= pte 0xffff81440fa04000-0xffff81440fc00000 2032K = pte 0xffff81440fc00000-0xffff814440000000 772M = pmd 0xffff814440000000-0xffff816480000000 129G = pud 0xffff816480000000-0xffff81648006c000 432K USR RW x= pte 0xffff81648006c000-0xffff816480200000 1616K = pte 0xffff816480200000-0xffff8164c0000000 1022M = pmd 0xffff8164c0000000-0xffff817500000000 65G = pud 0xffff817500000000-0xffff81750036c000 3504K USR RW x= pte 0xffff81750036c000-0xffff817500400000 592K = pte 0xffff817500400000-0xffff817540000000 1020M = pmd 0xffff817540000000-0xffff817fc0000000 42G = pud 0xffff817fc0000000-0xffff817fffc00000 1020M = pmd 0xffff817fffc00000-0xffff817fffc08000 32K = pte 0xffff817fffc08000-0xffff817fffc0e000 24K USR RW x= pte 0xffff817fffc0e000-0xffff817fffc7e000 448K = pte 0xffff817fffc7e000-0xffff817fffcfe000 512K USR RW x= pte 0xffff817fffcfe000-0xffff817fffd00000 8K = pte 0xffff817fffd00000-0xffff817fffd01000 4K USR RW x= pte 0xffff817fffd01000-0xffff817fffe00000 1020K = pte 0xffff817fffe00000-0xffff817fffefe000 1016K USR RW x= pte 0xffff817fffefe000-0xffff817fffffa000 1008K = pte 0xffff817fffffa000-0xffff817fffffc000 8K USR RW x= pte 0xffff817fffffc000-0xffff818000000000 16K = pte 0xffff818000000000-0xffff820000000000 512G = pgd 0xffff820000000000-0xffff848000000000 2560G = pud 0xffff848000000000-0xffff880000000000 3584G = pgd ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff88000009b000 620K USR RW x= pte 0xffff88000009b000-0xffff8800000a0000 20K USR RW x= pte 0xffff8800000a0000-0xffff8800007fb000 7532K USR RW x= pte 0xffff8800007fb000-0xffff880000efc000 7172K USR ro x= pte 0xffff880000efc000-0xffff880001000000 1040K USR RW x= pte 0xffff880001000000-0xffff880001002000 8K USR ro x= pte 0xffff880001002000-0xffff880001013000 68K USR ro x= pte 0xffff880001013000-0xffff880001015000 8K USR ro x= pte 0xffff880001015000-0xffff880001017000 8K USR ro x= pte 0xffff880001017000-0xffff880001019000 8K USR ro x= pte 0xffff880001019000-0xffff88000101a000 4K USR ro x= pte 0xffff88000101a000-0xffff88000101b000 4K USR ro x= pte 0xffff88000101b000-0xffff88000101f000 16K USR ro x= pte 0xffff88000101f000-0xffff880001028000 36K USR ro x= pte 0xffff880001028000-0xffff88000102a000 8K USR ro x= pte 0xffff88000102a000-0xffff88000102c000 8K USR ro x= pte 0xffff88000102c000-0xffff88000103c000 64K USR ro x= pte 0xffff88000103c000-0xffff88000103d000 4K USR ro x= pte 0xffff88000103d000-0xffff880001051000 80K USR ro x= pte 0xffff880001051000-0xffff880001052000 4K USR ro x= pte 0xffff880001052000-0xffff880001057000 20K USR ro x= pte 0xffff880001057000-0xffff880001058000 4K USR ro x= pte 0xffff880001058000-0xffff880001061000 36K USR ro x= pte 0xffff880001061000-0xffff880001063000 8K USR ro x= pte 0xffff880001063000-0xffff88000106b000 32K USR ro x= pte 0xffff88000106b000-0xffff88000106c000 4K USR ro x= pte 0xffff88000106c000-0xffff880001078000 48K USR ro x= pte 0xffff880001078000-0xffff88000107a000 8K USR ro x= pte 0xffff88000107a000-0xffff880001083000 36K USR ro x= pte 0xffff880001083000-0xffff880001084000 4K USR ro x= pte 0xffff880001084000-0xffff88000108f000 44K USR ro x= pte 0xffff88000108f000-0xffff880001090000 4K USR ro x= pte 0xffff880001090000-0xffff880001094000 16K USR ro x= pte 0xffff880001094000-0xffff880001097000 12K USR ro x= pte 0xffff880001097000-0xffff8800010a0000 36K USR ro x= pte 0xffff8800010a0000-0xffff8800010a2000 8K USR ro x= pte 0xffff8800010a2000-0xffff8800010a7000 20K USR ro x= pte 0xffff8800010a7000-0xffff8800010a8000 4K USR ro x= pte 0xffff8800010a8000-0xffff8800010aa000 8K USR ro x= pte 0xffff8800010aa000-0xffff8800010af000 20K USR ro x= pte 0xffff8800010af000-0xffff8800010b4000 20K USR ro x= pte 0xffff8800010b4000-0xffff8800010b6000 8K USR ro x= pte 0xffff8800010b6000-0xffff8800010c0000 40K USR ro x= pte 0xffff8800010c0000-0xffff8800010c4000 16K USR ro x= pte 0xffff8800010c4000-0xffff8800010c6000 8K USR ro x= pte 0xffff8800010c6000-0xffff8800010ca000 16K USR ro x= pte 0xffff8800010ca000-0xffff8800010cc000 8K USR ro x= pte 0xffff8800010cc000-0xffff8800010cd000 4K USR ro x= pte 0xffff8800010cd000-0xffff8800010d5000 32K USR ro x= pte 0xffff8800010d5000-0xffff8800010d9000 16K USR ro x= pte 0xffff8800010d9000-0xffff8800010da000 4K USR ro x= pte 0xffff8800010da000-0xffff8800010db000 4K USR ro x= pte 0xffff8800010db000-0xffff8800010dc000 4K USR ro x= pte 0xffff8800010dc000-0xffff8800010dd000 4K USR ro x= pte 0xffff8800010dd000-0xffff8800010e2000 20K USR ro x= pte 0xffff8800010e2000-0xffff8800010e3000 4K USR ro x= pte 0xffff8800010e3000-0xffff8800010f8000 84K USR ro x= pte 0xffff8800010f8000-0xffff8800010fb000 12K USR ro x= pte 0xffff8800010fb000-0xffff880001101000 24K USR ro x= pte 0xffff880001101000-0xffff880001102000 4K USR ro x= pte 0xffff880001102000-0xffff880001106000 16K USR ro x= pte 0xffff880001106000-0xffff880001107000 4K USR ro x= pte 0xffff880001107000-0xffff880001108000 4K USR ro x= pte 0xffff880001108000-0xffff880001109000 4K USR ro x= pte 0xffff880001109000-0xffff880001113000 40K USR ro x= pte 0xffff880001113000-0xffff880001114000 4K USR ro x= pte 0xffff880001114000-0xffff880001117000 12K USR ro x= pte 0xffff880001117000-0xffff880001118000 4K USR ro x= pte 0xffff880001118000-0xffff880001122000 40K USR ro x= pte 0xffff880001122000-0xffff880001124000 8K USR ro x= pte 0xffff880001124000-0xffff880001143000 124K USR ro x= pte 0xffff880001143000-0xffff880001145000 8K USR ro x= pte 0xffff880001145000-0xffff880001166000 132K USR ro x= pte 0xffff880001166000-0xffff880001168000 8K USR ro x= pte 0xffff880001168000-0xffff88000116d000 20K USR ro x= pte 0xffff88000116d000-0xffff88000116e000 4K USR ro x= pte 0xffff88000116e000-0xffff88000116f000 4K USR ro x= pte 0xffff88000116f000-0xffff880001170000 4K USR ro x= pte 0xffff880001170000-0xffff880001174000 16K USR ro x= pte 0xffff880001174000-0xffff880001177000 12K USR ro x= pte 0xffff880001177000-0xffff88000117a000 12K USR ro x= pte 0xffff88000117a000-0xffff88000117e000 16K USR ro x= pte 0xffff88000117e000-0xffff88000118d000 60K USR ro x= pte 0xffff88000118d000-0xffff88000118e000 4K USR ro x= pte 0xffff88000118e000-0xffff880001190000 8K USR ro x= pte 0xffff880001190000-0xffff880001191000 4K USR ro x= pte 0xffff880001191000-0xffff880001192000 4K USR ro x= pte 0xffff880001192000-0xffff880001193000 4K USR ro x= pte 0xffff880001193000-0xffff880001194000 4K USR ro x= pte 0xffff880001194000-0xffff880001197000 12K USR ro x= pte 0xffff880001197000-0xffff880001198000 4K USR ro x= pte 0xffff880001198000-0xffff880001199000 4K USR ro x= pte 0xffff880001199000-0xffff8800011a0000 28K USR ro x= pte 0xffff8800011a0000-0xffff8800011a1000 4K USR ro x= pte 0xffff8800011a1000-0xffff8800011ab000 40K USR ro x= pte 0xffff8800011ab000-0xffff8800011ac000 4K USR ro x= pte 0xffff8800011ac000-0xffff8800011af000 12K USR ro x= pte 0xffff8800011af000-0xffff8800011b1000 8K USR ro x= pte 0xffff8800011b1000-0xffff8800011b4000 12K USR ro x= pte 0xffff8800011b4000-0xffff8800011b5000 4K USR ro x= pte 0xffff8800011b5000-0xffff8800011b9000 16K USR ro x= pte 0xffff8800011b9000-0xffff8800011bb000 8K USR ro x= pte 0xffff8800011bb000-0xffff8800011bd000 8K USR ro x= pte 0xffff8800011bd000-0xffff8800011be000 4K USR ro x= pte 0xffff8800011be000-0xffff8800011c2000 16K USR ro x= pte 0xffff8800011c2000-0xffff8800011c6000 16K USR ro x= pte 0xffff8800011c6000-0xffff8800011c7000 4K USR ro x= pte 0xffff8800011c7000-0xffff8800011c8000 4K USR ro x= pte 0xffff8800011c8000-0xffff8800011c9000 4K USR ro x= pte 0xffff8800011c9000-0xffff8800011ca000 4K USR ro x= pte 0xffff8800011ca000-0xffff8800011cf000 20K USR ro x= pte 0xffff8800011cf000-0xffff8800011d0000 4K USR ro x= pte 0xffff8800011d0000-0xffff8800011d3000 12K USR ro x= pte 0xffff8800011d3000-0xffff8800011d5000 8K USR ro x= pte 0xffff8800011d5000-0xffff8800011d6000 4K USR ro x= pte 0xffff8800011d6000-0xffff8800011d8000 8K USR ro x= pte 0xffff8800011d8000-0xffff8800011d9000 4K USR ro x= pte 0xffff8800011d9000-0xffff8800011da000 4K USR ro x= pte 0xffff8800011da000-0xffff8800011e0000 24K USR ro x= pte 0xffff8800011e0000-0xffff8800011e3000 12K USR ro x= pte 0xffff8800011e3000-0xffff8800011e9000 24K USR ro x= pte 0xffff8800011e9000-0xffff8800011ea000 4K USR ro x= pte 0xffff8800011ea000-0xffff8800011eb000 4K USR ro x= pte 0xffff8800011eb000-0xffff8800011f1000 24K USR ro x= pte 0xffff8800011f1000-0xffff8800011f7000 24K USR ro x= pte 0xffff8800011f7000-0xffff8800011f8000 4K USR ro x= pte 0xffff8800011f8000-0xffff8800011fa000 8K USR ro x= pte 0xffff8800011fa000-0xffff8800011fb000 4K USR ro x= pte 0xffff8800011fb000-0xffff8800011fd000 8K USR ro x= pte 0xffff8800011fd000-0xffff8800011fe000 4K USR ro x= pte 0xffff8800011fe000-0xffff880001200000 8K USR ro x= pte 0xffff880001200000-0xffff880001201000 4K USR ro x= pte 0xffff880001201000-0xffff880001203000 8K USR ro x= pte 0xffff880001203000-0xffff880001207000 16K USR ro x= pte 0xffff880001207000-0xffff880001209000 8K USR ro x= pte 0xffff880001209000-0xffff88000120a000 4K USR ro x= pte 0xffff88000120a000-0xffff88000120b000 4K USR ro x= pte 0xffff88000120b000-0xffff88000120c000 4K USR ro x= pte 0xffff88000120c000-0xffff88000120e000 8K USR ro x= pte 0xffff88000120e000-0xffff880001223000 84K USR ro x= pte 0xffff880001223000-0xffff880001228000 20K USR ro x= pte 0xffff880001228000-0xffff880001229000 4K USR ro x= pte 0xffff880001229000-0xffff88000123b000 72K USR ro x= pte 0xffff88000123b000-0xffff88000123d000 8K USR ro x= pte 0xffff88000123d000-0xffff88000123e000 4K USR ro x= pte 0xffff88000123e000-0xffff88000123f000 4K USR ro x= pte 0xffff88000123f000-0xffff880001242000 12K USR ro x= pte 0xffff880001242000-0xffff880001244000 8K USR ro x= pte 0xffff880001244000-0xffff880001245000 4K USR ro x= pte 0xffff880001245000-0xffff880001247000 8K USR ro x= pte 0xffff880001247000-0xffff880001248000 4K USR ro x= pte 0xffff880001248000-0xffff880001252000 40K USR ro x= pte 0xffff880001252000-0xffff880001253000 4K USR ro x= pte 0xffff880001253000-0xffff880001254000 4K USR ro x= pte 0xffff880001254000-0xffff880001255000 4K USR ro x= pte 0xffff880001255000-0xffff880001258000 12K USR ro x= pte 0xffff880001258000-0xffff880001259000 4K USR ro x= pte 0xffff880001259000-0xffff880001268000 60K USR ro x= pte 0xffff880001268000-0xffff88000126e000 24K USR ro x= pte 0xffff88000126e000-0xffff88000126f000 4K USR ro x= pte 0xffff88000126f000-0xffff880001272000 12K USR ro x= pte 0xffff880001272000-0xffff880001273000 4K USR ro x= pte 0xffff880001273000-0xffff880001274000 4K USR ro x= pte 0xffff880001274000-0xffff88000127a000 24K USR ro x= pte 0xffff88000127a000-0xffff88000127c000 8K USR ro x= pte 0xffff88000127c000-0xffff88000127d000 4K USR ro x= pte 0xffff88000127d000-0xffff880001285000 32K USR ro x= pte 0xffff880001285000-0xffff880001286000 4K USR ro x= pte 0xffff880001286000-0xffff880001287000 4K USR ro x= pte 0xffff880001287000-0xffff880001288000 4K USR ro x= pte 0xffff880001288000-0xffff880001289000 4K USR ro x= pte 0xffff880001289000-0xffff88000128d000 16K USR ro x= pte 0xffff88000128d000-0xffff88000128f000 8K USR ro x= pte 0xffff88000128f000-0xffff880001291000 8K USR ro x= pte 0xffff880001291000-0xffff880001292000 4K USR ro x= pte 0xffff880001292000-0xffff88000129f000 52K USR ro x= pte 0xffff88000129f000-0xffff8800012a0000 4K USR ro x= pte 0xffff8800012a0000-0xffff8800012a1000 4K USR ro x= pte 0xffff8800012a1000-0xffff8800012a3000 8K USR ro x= pte 0xffff8800012a3000-0xffff8800012a5000 8K USR ro x= pte 0xffff8800012a5000-0xffff8800012a6000 4K USR ro x= pte 0xffff8800012a6000-0xffff8800012a9000 12K USR ro x= pte 0xffff8800012a9000-0xffff8800012ab000 8K USR ro x= pte 0xffff8800012ab000-0xffff8800012c3000 96K USR ro x= pte 0xffff8800012c3000-0xffff8800012c6000 12K USR ro x= pte 0xffff8800012c6000-0xffff8800012cc000 24K USR ro x= pte 0xffff8800012cc000-0xffff8800012cf000 12K USR ro x= pte 0xffff8800012cf000-0xffff8800012d1000 8K USR ro x= pte 0xffff8800012d1000-0xffff8800012d2000 4K USR ro x= pte 0xffff8800012d2000-0xffff8800012d3000 4K USR ro x= pte 0xffff8800012d3000-0xffff8800012d7000 16K USR ro x= pte 0xffff8800012d7000-0xffff8800012d8000 4K USR ro x= pte 0xffff8800012d8000-0xffff8800012da000 8K USR ro x= pte 0xffff8800012da000-0xffff8800012dc000 8K USR ro x= pte 0xffff8800012dc000-0xffff8800012e1000 20K USR ro x= pte 0xffff8800012e1000-0xffff8800012e3000 8K USR ro x= pte 0xffff8800012e3000-0xffff8800012e4000 4K USR ro x= pte 0xffff8800012e4000-0xffff8800012e5000 4K USR ro x= pte 0xffff8800012e5000-0xffff8800012e6000 4K USR ro x= pte 0xffff8800012e6000-0xffff8800012e7000 4K USR ro x= pte 0xffff8800012e7000-0xffff8800012ed000 24K USR ro x= pte 0xffff8800012ed000-0xffff8800012ee000 4K USR ro x= pte 0xffff8800012ee000-0xffff8800012f9000 44K USR ro x= pte 0xffff8800012f9000-0xffff8800012fa000 4K USR ro x= pte 0xffff8800012fa000-0xffff8800012fe000 16K USR ro x= pte 0xffff8800012fe000-0xffff880001300000 8K USR ro x= pte 0xffff880001300000-0xffff880001302000 8K USR ro x= pte 0xffff880001302000-0xffff88000130d000 44K USR ro x= pte 0xffff88000130d000-0xffff88000130e000 4K USR ro x= pte 0xffff88000130e000-0xffff88000130f000 4K USR ro x= pte 0xffff88000130f000-0xffff880001312000 12K USR ro x= pte 0xffff880001312000-0xffff880001314000 8K USR ro x= pte 0xffff880001314000-0xffff880001318000 16K USR ro x= pte 0xffff880001318000-0xffff88000131b000 12K USR ro x= pte 0xffff88000131b000-0xffff88000131c000 4K USR ro x= pte 0xffff88000131c000-0xffff880001324000 32K USR ro x= pte 0xffff880001324000-0xffff880001329000 20K USR ro x= pte 0xffff880001329000-0xffff88000132d000 16K USR ro x= pte 0xffff88000132d000-0xffff88000132e000 4K USR ro x= pte 0xffff88000132e000-0xffff88000132f000 4K USR ro x= pte 0xffff88000132f000-0xffff880001332000 12K USR ro x= pte 0xffff880001332000-0xffff880001333000 4K USR ro x= pte 0xffff880001333000-0xffff880001334000 4K USR ro x= pte 0xffff880001334000-0xffff880001335000 4K USR ro x= pte 0xffff880001335000-0xffff880001337000 8K USR ro x= pte 0xffff880001337000-0xffff88000133b000 16K USR ro x= pte 0xffff88000133b000-0xffff88000133c000 4K USR ro x= pte 0xffff88000133c000-0xffff880001340000 16K USR ro x= pte 0xffff880001340000-0xffff880001342000 8K USR ro x= pte 0xffff880001342000-0xffff880001343000 4K USR ro x= pte 0xffff880001343000-0xffff880001348000 20K USR ro x= pte 0xffff880001348000-0xffff88000134c000 16K USR ro x= pte 0xffff88000134c000-0xffff880001350000 16K USR ro x= pte 0xffff880001350000-0xffff880001351000 4K USR ro x= pte 0xffff880001351000-0xffff880001353000 8K USR ro x= pte 0xffff880001353000-0xffff880001358000 20K USR ro x= pte 0xffff880001358000-0xffff88000135e000 24K USR ro x= pte 0xffff88000135e000-0xffff88000135f000 4K USR ro x= pte 0xffff88000135f000-0xffff880001361000 8K USR ro x= pte 0xffff880001361000-0xffff880001366000 20K USR ro x= pte 0xffff880001366000-0xffff880001367000 4K USR ro x= pte 0xffff880001367000-0xffff880001368000 4K USR ro x= pte 0xffff880001368000-0xffff88000136a000 8K USR ro x= pte 0xffff88000136a000-0xffff880001374000 40K USR ro x= pte 0xffff880001374000-0xffff880001376000 8K USR ro x= pte 0xffff880001376000-0xffff880001379000 12K USR ro x= pte 0xffff880001379000-0xffff88000137f000 24K USR ro x= pte 0xffff88000137f000-0xffff880001380000 4K USR ro x= pte 0xffff880001380000-0xffff880001383000 12K USR ro x= pte 0xffff880001383000-0xffff880001384000 4K USR ro x= pte 0xffff880001384000-0xffff880001387000 12K USR ro x= pte 0xffff880001387000-0xffff880001389000 8K USR ro x= pte 0xffff880001389000-0xffff88000138c000 12K USR ro x= pte 0xffff88000138c000-0xffff880001393000 28K USR ro x= pte 0xffff880001393000-0xffff880001395000 8K USR ro x= pte 0xffff880001395000-0xffff880001398000 12K USR ro x= pte 0xffff880001398000-0xffff88000139a000 8K USR ro x= pte 0xffff88000139a000-0xffff88000139c000 8K USR ro x= pte 0xffff88000139c000-0xffff88000139d000 4K USR ro x= pte 0xffff88000139d000-0xffff8800013a3000 24K USR ro x= pte 0xffff8800013a3000-0xffff8800013a4000 4K USR ro x= pte 0xffff8800013a4000-0xffff8800013a5000 4K USR ro x= pte 0xffff8800013a5000-0xffff8800013a6000 4K USR ro x= pte 0xffff8800013a6000-0xffff8800013a9000 12K USR ro x= pte 0xffff8800013a9000-0xffff8800013ab000 8K USR ro x= pte 0xffff8800013ab000-0xffff8800013ac000 4K USR ro x= pte 0xffff8800013ac000-0xffff8800013ae000 8K USR ro x= pte 0xffff8800013ae000-0xffff8800013b1000 12K USR ro x= pte 0xffff8800013b1000-0xffff8800013b3000 8K USR ro x= pte 0xffff8800013b3000-0xffff8800013b5000 8K USR ro x= pte 0xffff8800013b5000-0xffff8800013b9000 16K USR ro x= pte 0xffff8800013b9000-0xffff8800013ba000 4K USR ro x= pte 0xffff8800013ba000-0xffff8800013bf000 20K USR ro x= pte 0xffff8800013bf000-0xffff8800013ce000 60K USR ro x= pte 0xffff8800013ce000-0xffff8800013cf000 4K USR ro x= pte 0xffff8800013cf000-0xffff8800013d0000 4K USR ro x= pte 0xffff8800013d0000-0xffff8800013d2000 8K USR ro x= pte 0xffff8800013d2000-0xffff8800013d3000 4K USR ro x= pte 0xffff8800013d3000-0xffff8800013db000 32K USR ro x= pte 0xffff8800013db000-0xffff8800013dc000 4K USR ro x= pte 0xffff8800013dc000-0xffff8800013dd000 4K USR ro x= pte 0xffff8800013dd000-0xffff8800013de000 4K USR ro x= pte 0xffff8800013de000-0xffff8800013e0000 8K USR ro x= pte 0xffff8800013e0000-0xffff8800013e3000 12K USR ro x= pte 0xffff8800013e3000-0xffff8800013e5000 8K USR ro x= pte 0xffff8800013e5000-0xffff8800013e8000 12K USR ro x= pte 0xffff8800013e8000-0xffff8800013ea000 8K USR ro x= pte 0xffff8800013ea000-0xffff8800013ec000 8K USR ro x= pte 0xffff8800013ec000-0xffff8800013ed000 4K USR ro x= pte 0xffff8800013ed000-0xffff8800013ef000 8K USR ro x= pte 0xffff8800013ef000-0xffff8800013f3000 16K USR ro x= pte 0xffff8800013f3000-0xffff8800013f4000 4K USR ro x= pte 0xffff8800013f4000-0xffff8800013f6000 8K USR ro x= pte 0xffff8800013f6000-0xffff8800013f7000 4K USR ro x= pte 0xffff8800013f7000-0xffff8800013fa000 12K USR ro x= pte 0xffff8800013fa000-0xffff8800013fb000 4K USR ro x= pte 0xffff8800013fb000-0xffff8800013fd000 8K USR ro x= pte 0xffff8800013fd000-0xffff8800013fe000 4K USR ro x= pte 0xffff8800013fe000-0xffff880001403000 20K USR ro x= pte 0xffff880001403000-0xffff880001404000 4K USR ro x= pte 0xffff880001404000-0xffff880001406000 8K USR ro x= pte 0xffff880001406000-0xffff880001408000 8K USR ro x= pte 0xffff880001408000-0xffff880001411000 36K USR ro x= pte 0xffff880001411000-0xffff880001412000 4K USR ro x= pte 0xffff880001412000-0xffff880001413000 4K USR ro x= pte 0xffff880001413000-0xffff880001415000 8K USR ro x= pte 0xffff880001415000-0xffff880001416000 4K USR ro x= pte 0xffff880001416000-0xffff880001419000 12K USR ro x= pte 0xffff880001419000-0xffff88000141e000 20K USR ro x= pte 0xffff88000141e000-0xffff880001425000 28K USR ro x= pte 0xffff880001425000-0xffff880001426000 4K USR ro x= pte 0xffff880001426000-0xffff880001428000 8K USR ro x= pte 0xffff880001428000-0xffff88000142f000 28K USR ro x= pte 0xffff88000142f000-0xffff880001430000 4K USR ro x= pte 0xffff880001430000-0xffff880001437000 28K USR ro x= pte 0xffff880001437000-0xffff880001438000 4K USR ro x= pte 0xffff880001438000-0xffff880001439000 4K USR ro x= pte 0xffff880001439000-0xffff88000143d000 16K USR ro x= pte 0xffff88000143d000-0xffff88000143e000 4K USR ro x= pte 0xffff88000143e000-0xffff88000143f000 4K USR ro x= pte 0xffff88000143f000-0xffff880001440000 4K USR ro x= pte 0xffff880001440000-0xffff880001443000 12K USR ro x= pte 0xffff880001443000-0xffff880001445000 8K USR ro x= pte 0xffff880001445000-0xffff880001446000 4K USR ro x= pte 0xffff880001446000-0xffff880001448000 8K USR ro x= pte 0xffff880001448000-0xffff88000144d000 20K USR ro x= pte 0xffff88000144d000-0xffff88000144f000 8K USR ro x= pte 0xffff88000144f000-0xffff880001451000 8K USR ro x= pte 0xffff880001451000-0xffff880001452000 4K USR ro x= pte 0xffff880001452000-0xffff880001458000 24K USR ro x= pte 0xffff880001458000-0xffff880001459000 4K USR ro x= pte 0xffff880001459000-0xffff88000145a000 4K USR ro x= pte 0xffff88000145a000-0xffff88000145c000 8K USR ro x= pte 0xffff88000145c000-0xffff88000145d000 4K USR ro x= pte 0xffff88000145d000-0xffff880001462000 20K USR ro x= pte 0xffff880001462000-0xffff880001463000 4K USR ro x= pte 0xffff880001463000-0xffff880001464000 4K USR ro x= pte 0xffff880001464000-0xffff880001465000 4K USR ro x= pte 0xffff880001465000-0xffff880001467000 8K USR ro x= pte 0xffff880001467000-0xffff880001468000 4K USR ro x= pte 0xffff880001468000-0xffff880001469000 4K USR ro x= pte 0xffff880001469000-0xffff88000146a000 4K USR ro x= pte 0xffff88000146a000-0xffff88000146b000 4K USR ro x= pte 0xffff88000146b000-0xffff880001470000 20K USR ro x= pte 0xffff880001470000-0xffff880001471000 4K USR ro x= pte 0xffff880001471000-0xffff880001473000 8K USR ro x= pte 0xffff880001473000-0xffff880001477000 16K USR ro x= pte 0xffff880001477000-0xffff88000147a000 12K USR ro x= pte 0xffff88000147a000-0xffff88000147b000 4K USR ro x= pte 0xffff88000147b000-0xffff88000147c000 4K USR ro x= pte 0xffff88000147c000-0xffff88000147d000 4K USR ro x= pte 0xffff88000147d000-0xffff880001482000 20K USR ro x= pte 0xffff880001482000-0xffff880001484000 8K USR ro x= pte 0xffff880001484000-0xffff880001485000 4K USR ro x= pte 0xffff880001485000-0xffff880001486000 4K USR ro x= pte 0xffff880001486000-0xffff880001489000 12K USR ro x= pte 0xffff880001489000-0xffff88000148a000 4K USR ro x= pte 0xffff88000148a000-0xffff88000148b000 4K USR ro x= pte 0xffff88000148b000-0xffff88000148c000 4K USR ro x= pte 0xffff88000148c000-0xffff880001499000 52K USR ro x= pte 0xffff880001499000-0xffff88000149a000 4K USR ro x= pte 0xffff88000149a000-0xffff8800014a2000 32K USR ro x= pte 0xffff8800014a2000-0xffff8800014a5000 12K USR ro x= pte 0xffff8800014a5000-0xffff8800014a8000 12K USR ro x= pte 0xffff8800014a8000-0xffff8800014b0000 32K USR ro x= pte 0xffff8800014b0000-0xffff8800014b1000 4K USR ro x= pte 0xffff8800014b1000-0xffff8800014b2000 4K USR ro x= pte 0xffff8800014b2000-0xffff8800014c2000 64K USR ro x= pte 0xffff8800014c2000-0xffff8800014c3000 4K USR ro x= pte 0xffff8800014c3000-0xffff8800014c5000 8K USR ro x= pte 0xffff8800014c5000-0xffff8800014cb000 24K USR ro x= pte 0xffff8800014cb000-0xffff8800014cc000 4K USR ro x= pte 0xffff8800014cc000-0xffff8800014cf000 12K USR ro x= pte 0xffff8800014cf000-0xffff8800014d0000 4K USR ro x= pte 0xffff8800014d0000-0xffff8800014d1000 4K USR ro x= pte 0xffff8800014d1000-0xffff8800014d3000 8K USR ro x= pte 0xffff8800014d3000-0xffff8800014d4000 4K USR ro x= pte 0xffff8800014d4000-0xffff8800014d6000 8K USR ro x= pte 0xffff8800014d6000-0xffff8800014d7000 4K USR ro x= pte 0xffff8800014d7000-0xffff8800014db000 16K USR ro x= pte 0xffff8800014db000-0xffff8800014dc000 4K USR ro x= pte 0xffff8800014dc000-0xffff8800014de000 8K USR ro x= pte 0xffff8800014de000-0xffff8800014df000 4K USR ro x= pte 0xffff8800014df000-0xffff8800014e3000 16K USR ro x= pte 0xffff8800014e3000-0xffff8800014e7000 16K USR ro x= pte 0xffff8800014e7000-0xffff8800014e8000 4K USR ro x= pte 0xffff8800014e8000-0xffff8800014e9000 4K USR ro x= pte 0xffff8800014e9000-0xffff8800014f1000 32K USR ro x= pte 0xffff8800014f1000-0xffff8800014f2000 4K USR ro x= pte 0xffff8800014f2000-0xffff8800014f6000 16K USR ro x= pte 0xffff8800014f6000-0xffff8800014f7000 4K USR ro x= pte 0xffff8800014f7000-0xffff8800014f8000 4K USR ro x= pte 0xffff8800014f8000-0xffff8800014f9000 4K USR ro x= pte 0xffff8800014f9000-0xffff8800014fe000 20K USR ro x= pte 0xffff8800014fe000-0xffff880001503000 20K USR ro x= pte 0xffff880001503000-0xffff880001508000 20K USR ro x= pte 0xffff880001508000-0xffff88000150d000 20K USR ro x= pte 0xffff88000150d000-0xffff880001511000 16K USR ro x= pte 0xffff880001511000-0xffff880001513000 8K USR ro x= pte 0xffff880001513000-0xffff880001514000 4K USR ro x= pte 0xffff880001514000-0xffff880001515000 4K USR ro x= pte 0xffff880001515000-0xffff880001516000 4K USR ro x= pte 0xffff880001516000-0xffff88000151b000 20K USR ro x= pte 0xffff88000151b000-0xffff880001520000 20K USR ro x= pte 0xffff880001520000-0xffff880001521000 4K USR ro x= pte 0xffff880001521000-0xffff880001523000 8K USR ro x= pte 0xffff880001523000-0xffff880001525000 8K USR ro x= pte 0xffff880001525000-0xffff880001526000 4K USR ro x= pte 0xffff880001526000-0xffff880001529000 12K USR ro x= pte 0xffff880001529000-0xffff88000152a000 4K USR ro x= pte 0xffff88000152a000-0xffff88000152b000 4K USR ro x= pte 0xffff88000152b000-0xffff88000152e000 12K USR ro x= pte 0xffff88000152e000-0xffff880001533000 20K USR ro x= pte 0xffff880001533000-0xffff880001535000 8K USR ro x= pte 0xffff880001535000-0xffff880001537000 8K USR ro x= pte 0xffff880001537000-0xffff880001538000 4K USR ro x= pte 0xffff880001538000-0xffff880001539000 4K USR ro x= pte 0xffff880001539000-0xffff88000153b000 8K USR ro x= pte 0xffff88000153b000-0xffff88000153d000 8K USR ro x= pte 0xffff88000153d000-0xffff880001541000 16K USR ro x= pte 0xffff880001541000-0xffff880001542000 4K USR ro x= pte 0xffff880001542000-0xffff880001544000 8K USR ro x= pte 0xffff880001544000-0xffff880001545000 4K USR ro x= pte 0xffff880001545000-0xffff880001547000 8K USR ro x= pte 0xffff880001547000-0xffff880001551000 40K USR ro x= pte 0xffff880001551000-0xffff880001552000 4K USR ro x= pte 0xffff880001552000-0xffff880001554000 8K USR ro x= pte 0xffff880001554000-0xffff880001555000 4K USR ro x= pte 0xffff880001555000-0xffff88000155d000 32K USR ro x= pte 0xffff88000155d000-0xffff88000155f000 8K USR ro x= pte 0xffff88000155f000-0xffff880001563000 16K USR ro x= pte 0xffff880001563000-0xffff880001566000 12K USR ro x= pte 0xffff880001566000-0xffff880001567000 4K USR ro x= pte 0xffff880001567000-0xffff880001568000 4K USR ro x= pte 0xffff880001568000-0xffff88000156a000 8K USR ro x= pte 0xffff88000156a000-0xffff88000156b000 4K USR ro x= pte 0xffff88000156b000-0xffff880001572000 28K USR ro x= pte 0xffff880001572000-0xffff880001573000 4K USR ro x= pte 0xffff880001573000-0xffff880001576000 12K USR ro x= pte 0xffff880001576000-0xffff880001577000 4K USR ro x= pte 0xffff880001577000-0xffff880001578000 4K USR ro x= pte 0xffff880001578000-0xffff880001579000 4K USR ro x= pte 0xffff880001579000-0xffff88000157a000 4K USR ro x= pte 0xffff88000157a000-0xffff88000157b000 4K USR ro x= pte 0xffff88000157b000-0xffff88000157d000 8K USR ro x= pte 0xffff88000157d000-0xffff88000157f000 8K USR ro x= pte 0xffff88000157f000-0xffff880001582000 12K USR ro x= pte 0xffff880001582000-0xffff880001584000 8K USR ro x= pte 0xffff880001584000-0xffff880001586000 8K USR ro x= pte 0xffff880001586000-0xffff880001588000 8K USR ro x= pte 0xffff880001588000-0xffff880001589000 4K USR ro x= pte 0xffff880001589000-0xffff88000158d000 16K USR ro x= pte 0xffff88000158d000-0xffff88000158f000 8K USR ro x= pte 0xffff88000158f000-0xffff880001593000 16K USR ro x= pte 0xffff880001593000-0xffff880001594000 4K USR ro x= pte 0xffff880001594000-0xffff880001595000 4K USR ro x= pte 0xffff880001595000-0xffff880001596000 4K USR ro x= pte 0xffff880001596000-0xffff880001599000 12K USR ro x= pte 0xffff880001599000-0xffff8800015ab000 72K USR ro x= pte 0xffff8800015ab000-0xffff8800015ac000 4K USR ro x= pte 0xffff8800015ac000-0xffff8800015b0000 16K USR ro x= pte 0xffff8800015b0000-0xffff8800015b1000 4K USR ro x= pte 0xffff8800015b1000-0xffff8800015b7000 24K USR ro x= pte 0xffff8800015b7000-0xffff880001600000 292K USR RW N= X pte 0xffff880001600000-0xffff88000179c000 1648K USR ro N= X pte 0xffff88000179c000-0xffff880001800000 400K USR RW N= X pte 0xffff880001800000-0xffff880001802000 8K USR RW x= pte 0xffff880001802000-0xffff880001803000 4K USR RW x= pte 0xffff880001803000-0xffff880001805000 8K USR RW x= pte 0xffff880001805000-0xffff88000180b000 24K USR RW x= pte 0xffff88000180b000-0xffff88000180f000 16K USR ro x= pte 0xffff88000180f000-0xffff880001810000 4K USR RW x= pte 0xffff880001810000-0xffff880001812000 8K USR ro x= pte 0xffff880001812000-0xffff880001813000 4K USR RW x= pte 0xffff880001813000-0xffff880001815000 8K USR RW x= pte 0xffff880001815000-0xffff880001816000 4K USR RW x= pte 0xffff880001816000-0xffff880001818000 8K USR RW x= pte 0xffff880001818000-0xffff88000181a000 8K USR RW x= pte 0xffff88000181a000-0xffff88000181d000 12K USR RW x= pte 0xffff88000181d000-0xffff88000181e000 4K USR RW x= pte 0xffff88000181e000-0xffff880001832000 80K USR RW x= pte 0xffff880001832000-0xffff880001834000 8K USR RW x= pte 0xffff880001834000-0xffff88000183a000 24K USR RW x= pte 0xffff88000183a000-0xffff88000183d000 12K USR RW x= pte 0xffff88000183d000-0xffff880001841000 16K USR RW x= pte 0xffff880001841000-0xffff880001843000 8K USR RW x= pte 0xffff880001843000-0xffff880001845000 8K USR RW x= pte 0xffff880001845000-0xffff880001846000 4K USR RW x= pte 0xffff880001846000-0xffff880001849000 12K USR RW x= pte 0xffff880001849000-0xffff88000184a000 4K USR RW x= pte 0xffff88000184a000-0xffff88000184f000 20K USR RW x= pte 0xffff88000184f000-0xffff880001850000 4K USR RW x= pte 0xffff880001850000-0xffff880001885000 212K USR RW x= pte 0xffff880001885000-0xffff880001938000 716K USR RW N= X pte 0xffff880001938000-0xffff88000193a000 8K USR RW x= pte 0xffff88000193a000-0xffff88000193b000 4K USR ro x= pte 0xffff88000193b000-0xffff88000193d000 8K USR RW x= pte 0xffff88000193d000-0xffff88000193e000 4K USR ro x= pte 0xffff88000193e000-0xffff880001948000 40K USR RW x= pte 0xffff880001948000-0xffff88000194a000 8K USR RW x= pte 0xffff88000194a000-0xffff88000194c000 8K USR RW x= pte 0xffff88000194c000-0xffff88000196c000 128K USR RW x= pte 0xffff88000196c000-0xffff88000196d000 4K USR RW x= pte 0xffff88000196d000-0xffff880001970000 12K USR RW x= pte 0xffff880001970000-0xffff880001971000 4K USR RW x= pte 0xffff880001971000-0xffff880001972000 4K USR RW x= pte 0xffff880001972000-0xffff880001973000 4K USR RW x= pte 0xffff880001973000-0xffff880001975000 8K USR RW x= pte 0xffff880001975000-0xffff880001976000 4K USR RW x= pte 0xffff880001976000-0xffff880001977000 4K USR RW x= pte 0xffff880001977000-0xffff88000197b000 16K USR RW x= pte 0xffff88000197b000-0xffff8800019b9000 248K USR RW x= pte 0xffff8800019b9000-0xffff8800019c0000 28K USR RW x= pte 0xffff8800019c0000-0xffff8800019df000 124K USR RW x= pte 0xffff8800019df000-0xffff8800019e8000 36K USR RW x= pte 0xffff8800019e8000-0xffff8800019f1000 36K USR RW x= pte 0xffff8800019f1000-0xffff8800019f2000 4K USR RW x= pte 0xffff8800019f2000-0xffff8800019f3000 4K USR RW x= pte 0xffff8800019f3000-0xffff8800019f5000 8K USR RW x= pte 0xffff8800019f5000-0xffff8800019f8000 12K USR RW x= pte 0xffff8800019f8000-0xffff880001a0a000 72K USR RW x= pte 0xffff880001a0a000-0xffff880001a0f000 20K USR RW x= pte 0xffff880001a0f000-0xffff880001a1c000 52K USR RW x= pte 0xffff880001a1c000-0xffff880001a1d000 4K USR RW x= pte 0xffff880001a1d000-0xffff880001aa4000 540K USR RW x= pte 0xffff880001aa4000-0xffff880001aa8000 16K USR ro x= pte 0xffff880001aa8000-0xffff880001b28000 512K USR RW x= pte 0xffff880001b28000-0xffff880001e3d000 3156K USR RW x= pte 0xffff880001e3d000-0xffff88000fc93000 227672K USR RW N= X pte 0xffff88000fc93000-0xffff88001f694000 256004K USR RW x= pte 0xffff88001f694000-0xffff88001f696000 8K USR RW x= pte 0xffff88001f696000-0xffff88001f797000 1028K USR ro x= pte 0xffff88001f797000-0xffff88001fc00000 4516K USR RW x= pte 0xffff88001fc00000-0xffff880020400000 8M USR RW x= pte 0xffff880020400000-0xffff8800f057d000 3409396K USR RW N= X pte 0xffff8800f057d000-0xffff8800ff7fb000 248312K USR ro N= X pte 0xffff8800ff7fb000-0xffff881eb3801000 124583960K USR RW N= X pte 0xffff881eb3801000-0xffff881eb3802000 4K USR ro N= X pte 0xffff881eb3802000-0xffff881eb3838000 216K USR RW N= X pte 0xffff881eb3838000-0xffff881eb3839000 4K USR ro N= X pte 0xffff881eb3839000-0xffff881eb384d000 80K USR RW N= X pte 0xffff881eb384d000-0xffff881eb384e000 4K USR ro N= X pte 0xffff881eb384e000-0xffff881eb3888000 232K USR RW N= X pte 0xffff881eb3888000-0xffff881eb3889000 4K USR ro N= X pte 0xffff881eb3889000-0xffff881eb388f000 24K USR RW N= X pte 0xffff881eb388f000-0xffff881eb3892000 12K USR ro N= X pte 0xffff881eb3892000-0xffff881eb3894000 8K USR RW N= X pte 0xffff881eb3894000-0xffff881eb3896000 8K USR ro N= X pte 0xffff881eb3896000-0xffff881eb389a000 16K USR RW N= X pte 0xffff881eb389a000-0xffff881eb389b000 4K USR ro N= X pte 0xffff881eb389b000-0xffff881eb389c000 4K USR RW N= X pte 0xffff881eb389c000-0xffff881eb389d000 4K USR ro N= X pte 0xffff881eb389d000-0xffff881eb389e000 4K USR RW N= X pte 0xffff881eb389e000-0xffff881eb38a0000 8K USR ro N= X pte 0xffff881eb38a0000-0xffff881eb38a3000 12K USR RW N= X pte 0xffff881eb38a3000-0xffff881eb38a7000 16K USR ro N= X pte 0xffff881eb38a7000-0xffff881eb38aa000 12K USR RW N= X pte 0xffff881eb38aa000-0xffff881eb38ac000 8K USR ro N= X pte 0xffff881eb38ac000-0xffff881eb38ae000 8K USR RW N= X pte 0xffff881eb38ae000-0xffff881eb38af000 4K USR ro N= X pte 0xffff881eb38af000-0xffff881eb38bc000 52K USR RW N= X pte 0xffff881eb38bc000-0xffff881eb38c0000 16K USR ro N= X pte 0xffff881eb38c0000-0xffff881eb3c36000 3544K USR RW N= X pte 0xffff881eb3c36000-0xffff881eb3c37000 4K USR ro N= X pte 0xffff881eb3c37000-0xffff881eb3c80000 292K USR RW N= X pte 0xffff881eb3c80000-0xffff881eb3c82000 8K USR ro N= X pte 0xffff881eb3c82000-0xffff881eb3f30000 2744K USR RW N= X pte 0xffff881eb3f30000-0xffff881eb3f34000 16K USR ro N= X pte 0xffff881eb3f34000-0xffff881eb3f52000 120K USR RW N= X pte 0xffff881eb3f52000-0xffff881eb3f54000 8K USR ro N= X pte 0xffff881eb3f54000-0xffff881eb3f61000 52K USR RW N= X pte 0xffff881eb3f61000-0xffff881eb3f62000 4K USR ro N= X pte 0xffff881eb3f62000-0xffff881eb3fae000 304K USR RW N= X pte 0xffff881eb3fae000-0xffff881eb3fb2000 16K USR ro N= X pte 0xffff881eb3fb2000-0xffff881eb3fb3000 4K USR RW N= X pte 0xffff881eb3fb3000-0xffff881eb3fb6000 12K USR ro N= X pte 0xffff881eb3fb6000-0xffff881eb3fb7000 4K USR RW N= X pte 0xffff881eb3fb7000-0xffff881eb3fbf000 32K USR ro N= X pte 0xffff881eb3fbf000-0xffff881eb3fc3000 16K USR RW N= X pte 0xffff881eb3fc3000-0xffff881eb3fca000 28K USR ro N= X pte 0xffff881eb3fca000-0xffff881eb3fcb000 4K USR RW N= X pte 0xffff881eb3fcb000-0xffff881eb3fcc000 4K USR ro N= X pte 0xffff881eb3fcc000-0xffff881eb3fd5000 36K USR RW N= X pte 0xffff881eb3fd5000-0xffff881eb3fd7000 8K USR ro N= X pte 0xffff881eb3fd7000-0xffff881eb3fdb000 16K USR RW N= X pte 0xffff881eb3fdb000-0xffff881eb3fdd000 8K USR ro N= X pte 0xffff881eb3fdd000-0xffff881eb3fef000 72K USR RW N= X pte 0xffff881eb3fef000-0xffff881eb3ff1000 8K USR ro N= X pte 0xffff881eb3ff1000-0xffff881eb3ff3000 8K USR RW N= X pte 0xffff881eb3ff3000-0xffff881eb3ff4000 4K USR ro N= X pte 0xffff881eb3ff4000-0xffff881eb3ff8000 16K USR RW N= X pte 0xffff881eb3ff8000-0xffff881eb3ff9000 4K USR ro N= X pte 0xffff881eb3ff9000-0xffff881eb3ffb000 8K USR RW N= X pte 0xffff881eb3ffb000-0xffff881eb3ffc000 4K USR ro N= X pte 0xffff881eb3ffc000-0xffff881eb4023000 156K USR RW N= X pte 0xffff881eb4023000-0xffff881eb4024000 4K USR ro N= X pte 0xffff881eb4024000-0xffff881eb402b000 28K USR RW N= X pte 0xffff881eb402b000-0xffff881eb4030000 20K USR ro N= X pte 0xffff881eb4030000-0xffff881eb4035000 20K USR RW N= X pte 0xffff881eb4035000-0xffff881eb4037000 8K USR ro N= X pte 0xffff881eb4037000-0xffff881eb4038000 4K USR RW N= X pte 0xffff881eb4038000-0xffff881eb4039000 4K USR ro N= X pte 0xffff881eb4039000-0xffff881eb403a000 4K USR RW N= X pte 0xffff881eb403a000-0xffff881eb403b000 4K USR ro N= X pte 0xffff881eb403b000-0xffff881eb4041000 24K USR RW N= X pte 0xffff881eb4041000-0xffff881eb4044000 12K USR ro N= X pte 0xffff881eb4044000-0xffff881eb431a000 2904K USR RW N= X pte 0xffff881eb431a000-0xffff881eb431c000 8K USR ro N= X pte 0xffff881eb431c000-0xffff881eb4389000 436K USR RW N= X pte 0xffff881eb4389000-0xffff881eb438a000 4K USR ro N= X pte 0xffff881eb438a000-0xffff881eb5a16000 23088K USR RW N= X pte 0xffff881eb5a16000-0xffff881eb5a17000 4K USR ro N= X pte 0xffff881eb5a17000-0xffff881eb5a31000 104K USR RW N= X pte 0xffff881eb5a31000-0xffff881eb5a32000 4K USR ro N= X pte 0xffff881eb5a32000-0xffff881eb5a36000 16K USR RW N= X pte 0xffff881eb5a36000-0xffff881eb5a38000 8K USR ro N= X pte 0xffff881eb5a38000-0xffff881eb5b57000 1148K USR RW N= X pte 0xffff881eb5b57000-0xffff881eb5b58000 4K USR ro N= X pte 0xffff881eb5b58000-0xffff881eb5b5a000 8K USR RW N= X pte 0xffff881eb5b5a000-0xffff881eb5b5d000 12K USR ro N= X pte 0xffff881eb5b5d000-0xffff881eb5b61000 16K USR RW N= X pte 0xffff881eb5b61000-0xffff881eb5b71000 64K USR ro N= X pte 0xffff881eb5b71000-0xffff881eb5b74000 12K USR RW N= X pte 0xffff881eb5b74000-0xffff881eb5b76000 8K USR ro N= X pte 0xffff881eb5b76000-0xffff881eb5b77000 4K USR RW N= X pte 0xffff881eb5b77000-0xffff881eb5b78000 4K USR ro N= X pte 0xffff881eb5b78000-0xffff881eb5b79000 4K USR RW N= X pte 0xffff881eb5b79000-0xffff881eb5b7b000 8K USR ro N= X pte 0xffff881eb5b7b000-0xffff881eb5b7f000 16K USR RW N= X pte 0xffff881eb5b7f000-0xffff881eb5b86000 28K USR ro N= X pte 0xffff881eb5b86000-0xffff881eb5b87000 4K USR RW N= X pte 0xffff881eb5b87000-0xffff881eb5b89000 8K USR ro N= X pte 0xffff881eb5b89000-0xffff881eb5b96000 52K USR RW N= X pte 0xffff881eb5b96000-0xffff881eb5b97000 4K USR ro N= X pte 0xffff881eb5b97000-0xffff881eb5bc9000 200K USR RW N= X pte 0xffff881eb5bc9000-0xffff881eb5bca000 4K USR ro N= X pte 0xffff881eb5bca000-0xffff881eb5bd6000 48K USR RW N= X pte 0xffff881eb5bd6000-0xffff881eb5bd7000 4K USR ro N= X pte 0xffff881eb5bd7000-0xffff881eb5bda000 12K USR RW N= X pte 0xffff881eb5bda000-0xffff881eb5bdb000 4K USR ro N= X pte 0xffff881eb5bdb000-0xffff881eb5bed000 72K USR RW N= X pte 0xffff881eb5bed000-0xffff881eb5bee000 4K USR ro N= X pte 0xffff881eb5bee000-0xffff881eb5bf0000 8K USR RW N= X pte 0xffff881eb5bf0000-0xffff881eb5bf1000 4K USR ro N= X pte 0xffff881eb5bf1000-0xffff881eb5bf8000 28K USR RW N= X pte 0xffff881eb5bf8000-0xffff881eb5bf9000 4K USR ro N= X pte 0xffff881eb5bf9000-0xffff881eb5bfe000 20K USR RW N= X pte 0xffff881eb5bfe000-0xffff881eb5c00000 8K USR ro N= X pte 0xffff881eb5c00000-0xffff881eb7600000 26M USR RW N= X pte 0xffff881eb7600000-0xffff881eb761b000 108K USR ro N= X pte 0xffff881eb761b000-0xffff881eb7622000 28K USR RW N= X pte 0xffff881eb7622000-0xffff881eb7626000 16K USR ro N= X pte 0xffff881eb7626000-0xffff881eb7627000 4K USR RW N= X pte 0xffff881eb7627000-0xffff881eb7628000 4K USR ro N= X pte 0xffff881eb7628000-0xffff881eb7629000 4K USR RW N= X pte 0xffff881eb7629000-0xffff881eb762a000 4K USR ro N= X pte 0xffff881eb762a000-0xffff881eb7631000 28K USR RW N= X pte 0xffff881eb7631000-0xffff881eb7632000 4K USR ro N= X pte 0xffff881eb7632000-0xffff881eb7633000 4K USR RW N= X pte 0xffff881eb7633000-0xffff881eb7634000 4K USR ro N= X pte 0xffff881eb7634000-0xffff881eb7640000 48K USR RW N= X pte 0xffff881eb7640000-0xffff881eb76f4000 720K USR ro N= X pte 0xffff881eb76f4000-0xffff881eb77a9000 724K USR RW N= X pte 0xffff881eb77a9000-0xffff881eb77aa000 4K USR ro N= X pte 0xffff881eb77aa000-0xffff881eb77b4000 40K USR RW N= X pte 0xffff881eb77b4000-0xffff881eb77ba000 24K USR ro N= X pte 0xffff881eb77ba000-0xffff881eb77bb000 4K USR RW N= X pte 0xffff881eb77bb000-0xffff881eb77bc000 4K USR ro N= X pte 0xffff881eb77bc000-0xffff881eb77c8000 48K USR RW N= X pte 0xffff881eb77c8000-0xffff881eb77ca000 8K USR ro N= X pte 0xffff881eb77ca000-0xffff881eb77cb000 4K USR RW N= X pte 0xffff881eb77cb000-0xffff881eb77cc000 4K USR ro N= X pte 0xffff881eb77cc000-0xffff881eb77ce000 8K USR RW N= X pte 0xffff881eb77ce000-0xffff881eb77d0000 8K USR ro N= X pte 0xffff881eb77d0000-0xffff881eb77da000 40K USR RW N= X pte 0xffff881eb77da000-0xffff881eb77dd000 12K USR ro N= X pte 0xffff881eb77dd000-0xffff881eb77df000 8K USR RW N= X pte 0xffff881eb77df000-0xffff881eb77e0000 4K USR ro N= X pte 0xffff881eb77e0000-0xffff881eb77ee000 56K USR RW N= X pte 0xffff881eb77ee000-0xffff881eb77f0000 8K USR ro N= X pte 0xffff881eb77f0000-0xffff881ebb489000 62052K USR RW N= X pte 0xffff881ebb489000-0xffff881ebb48c000 12K USR ro N= X pte 0xffff881ebb48c000-0xffff881ebb48f000 12K USR RW N= X pte 0xffff881ebb48f000-0xffff881ebb491000 8K USR ro N= X pte 0xffff881ebb491000-0xffff881ebb495000 16K USR RW N= X pte 0xffff881ebb495000-0xffff881ebb49a000 20K USR ro N= X pte 0xffff881ebb49a000-0xffff881ebb49c000 8K USR RW N= X pte 0xffff881ebb49c000-0xffff881ebb49d000 4K USR ro N= X pte 0xffff881ebb49d000-0xffff881ebb49e000 4K USR RW N= X pte 0xffff881ebb49e000-0xffff881ebb49f000 4K USR ro N= X pte 0xffff881ebb49f000-0xffff881ebb4a2000 12K USR RW N= X pte 0xffff881ebb4a2000-0xffff881ebb4a3000 4K USR ro N= X pte 0xffff881ebb4a3000-0xffff881ebb4a6000 12K USR RW N= X pte 0xffff881ebb4a6000-0xffff881ebb4a8000 8K USR ro N= X pte 0xffff881ebb4a8000-0xffff881ebb4af000 28K USR RW N= X pte 0xffff881ebb4af000-0xffff881ebb4b0000 4K USR ro N= X pte 0xffff881ebb4b0000-0xffff881ebb4b1000 4K USR RW N= X pte 0xffff881ebb4b1000-0xffff881ebb4b6000 20K USR ro N= X pte 0xffff881ebb4b6000-0xffff881ebb4bf000 36K USR RW N= X pte 0xffff881ebb4bf000-0xffff881ebb4c0000 4K USR ro N= X pte 0xffff881ebb4c0000-0xffff881ebb4c9000 36K USR RW N= X pte 0xffff881ebb4c9000-0xffff881ebb4ca000 4K USR ro N= X pte 0xffff881ebb4ca000-0xffff881ebb4ce000 16K USR RW N= X pte 0xffff881ebb4ce000-0xffff881ebb4cf000 4K USR ro N= X pte 0xffff881ebb4cf000-0xffff881ebb4d0000 4K USR RW N= X pte 0xffff881ebb4d0000-0xffff881ebb4d4000 16K USR ro N= X pte 0xffff881ebb4d4000-0xffff881ebb4d5000 4K USR RW N= X pte 0xffff881ebb4d5000-0xffff881ebb4d6000 4K USR ro N= X pte 0xffff881ebb4d6000-0xffff881ebb4d7000 4K USR RW N= X pte 0xffff881ebb4d7000-0xffff881ebb4d8000 4K USR ro N= X pte 0xffff881ebb4d8000-0xffff881ebb4db000 12K USR RW N= X pte 0xffff881ebb4db000-0xffff881ebb4dc000 4K USR ro N= X pte 0xffff881ebb4dc000-0xffff881ebb4e0000 16K USR RW N= X pte 0xffff881ebb4e0000-0xffff881ebb4e1000 4K USR ro N= X pte 0xffff881ebb4e1000-0xffff881ebb4ea000 36K USR RW N= X pte 0xffff881ebb4ea000-0xffff881ebb4eb000 4K USR ro N= X pte 0xffff881ebb4eb000-0xffff881ebb4f9000 56K USR RW N= X pte 0xffff881ebb4f9000-0xffff881ebb4fa000 4K USR ro N= X pte 0xffff881ebb4fa000-0xffff881ebb4ff000 20K USR RW N= X pte 0xffff881ebb4ff000-0xffff881ebb500000 4K USR ro N= X pte 0xffff881ebb500000-0xffff881ebb684000 1552K USR RW N= X pte 0xffff881ebb684000-0xffff881ebb686000 8K USR ro N= X pte 0xffff881ebb686000-0xffff881ebb68c000 24K USR RW N= X pte 0xffff881ebb68c000-0xffff881ebb68d000 4K USR ro N= X pte 0xffff881ebb68d000-0xffff881ebb68f000 8K USR RW N= X pte 0xffff881ebb68f000-0xffff881ebb690000 4K USR ro N= X pte 0xffff881ebb690000-0xffff881ebb6a6000 88K USR RW N= X pte 0xffff881ebb6a6000-0xffff881ebb6a8000 8K USR ro N= X pte 0xffff881ebb6a8000-0xffff881ebb6b7000 60K USR RW N= X pte 0xffff881ebb6b7000-0xffff881ebb6b8000 4K USR ro N= X pte 0xffff881ebb6b8000-0xffff881ebb6bb000 12K USR RW N= X pte 0xffff881ebb6bb000-0xffff881ebb6bc000 4K USR ro N= X pte 0xffff881ebb6bc000-0xffff881ebb6c4000 32K USR RW N= X pte 0xffff881ebb6c4000-0xffff881ebb6d0000 48K USR ro N= X pte 0xffff881ebb6d0000-0xffff881ebb6d1000 4K USR RW N= X pte 0xffff881ebb6d1000-0xffff881ebb6d4000 12K USR ro N= X pte 0xffff881ebb6d4000-0xffff881ebb6d9000 20K USR RW N= X pte 0xffff881ebb6d9000-0xffff881ebb6db000 8K USR ro N= X pte 0xffff881ebb6db000-0xffff881ebb6de000 12K USR RW N= X pte 0xffff881ebb6de000-0xffff881ebb6df000 4K USR ro N= X pte 0xffff881ebb6df000-0xffff881ebb6e5000 24K USR RW N= X pte 0xffff881ebb6e5000-0xffff881ebb6e6000 4K USR ro N= X pte 0xffff881ebb6e6000-0xffff881ebbf06000 8320K USR RW N= X pte 0xffff881ebbf06000-0xffff881ebbf08000 8K USR ro N= X pte 0xffff881ebbf08000-0xffff881ebbf0e000 24K USR RW N= X pte 0xffff881ebbf0e000-0xffff881ebbf10000 8K USR ro N= X pte 0xffff881ebbf10000-0xffff881ebbf11000 4K USR RW N= X pte 0xffff881ebbf11000-0xffff881ebbf13000 8K USR ro N= X pte 0xffff881ebbf13000-0xffff881ebbf14000 4K USR RW N= X pte 0xffff881ebbf14000-0xffff881ebbf19000 20K USR ro N= X pte 0xffff881ebbf19000-0xffff881ebbf24000 44K USR RW N= X pte 0xffff881ebbf24000-0xffff881ebbf25000 4K USR ro N= X pte 0xffff881ebbf25000-0xffff881ebbf26000 4K USR RW N= X pte 0xffff881ebbf26000-0xffff881ebbf27000 4K USR ro N= X pte 0xffff881ebbf27000-0xffff881ebbf30000 36K USR RW N= X pte 0xffff881ebbf30000-0xffff881ebbf31000 4K USR ro N= X pte 0xffff881ebbf31000-0xffff881ebbf3c000 44K USR RW N= X pte 0xffff881ebbf3c000-0xffff881ebbf3d000 4K USR ro N= X pte 0xffff881ebbf3d000-0xffff881ebbf41000 16K USR RW N= X pte 0xffff881ebbf41000-0xffff881ebbf42000 4K USR ro N= X pte 0xffff881ebbf42000-0xffff881ebbf5e000 112K USR RW N= X pte 0xffff881ebbf5e000-0xffff881ebbf5f000 4K USR ro N= X pte 0xffff881ebbf5f000-0xffff881ebbf68000 36K USR RW N= X pte 0xffff881ebbf68000-0xffff881ebbf69000 4K USR ro N= X pte 0xffff881ebbf69000-0xffff881ebbf81000 96K USR RW N= X pte 0xffff881ebbf81000-0xffff881ebbf83000 8K USR ro N= X pte 0xffff881ebbf83000-0xffff881ebbf84000 4K USR RW N= X pte 0xffff881ebbf84000-0xffff881ebbf86000 8K USR ro N= X pte 0xffff881ebbf86000-0xffff881ebbf8c000 24K USR RW N= X pte 0xffff881ebbf8c000-0xffff881ebbf8d000 4K USR ro N= X pte 0xffff881ebbf8d000-0xffff881ebbf8e000 4K USR RW N= X pte 0xffff881ebbf8e000-0xffff881ebbf8f000 4K USR ro N= X pte 0xffff881ebbf8f000-0xffff881ebbf90000 4K USR RW N= X pte 0xffff881ebbf90000-0xffff881ebbf96000 24K USR ro N= X pte 0xffff881ebbf96000-0xffff881ebbf9c000 24K USR RW N= X pte 0xffff881ebbf9c000-0xffff881ebbfa0000 16K USR ro N= X pte 0xffff881ebbfa0000-0xffff881ebbfa3000 12K USR RW N= X pte 0xffff881ebbfa3000-0xffff881ebbfac000 36K USR ro N= X pte 0xffff881ebbfac000-0xffff881ebbfae000 8K USR RW N= X pte 0xffff881ebbfae000-0xffff881ebbfaf000 4K USR ro N= X pte 0xffff881ebbfaf000-0xffff881ebbfb0000 4K USR RW N= X pte 0xffff881ebbfb0000-0xffff881ebbfb1000 4K USR ro N= X pte 0xffff881ebbfb1000-0xffff881ebbfb2000 4K USR RW N= X pte 0xffff881ebbfb2000-0xffff881ebbfb4000 8K USR ro N= X pte 0xffff881ebbfb4000-0xffff881ebbfc5000 68K USR RW N= X pte 0xffff881ebbfc5000-0xffff881ebbfc7000 8K USR ro N= X pte 0xffff881ebbfc7000-0xffff881ebbfe1000 104K USR RW N= X pte 0xffff881ebbfe1000-0xffff881ebbfe2000 4K USR ro N= X pte 0xffff881ebbfe2000-0xffff881ebbfe5000 12K USR RW N= X pte 0xffff881ebbfe5000-0xffff881ebbfe8000 12K USR ro N= X pte 0xffff881ebbfe8000-0xffff881ebbfed000 20K USR RW N= X pte 0xffff881ebbfed000-0xffff881ebbfee000 4K USR ro N= X pte 0xffff881ebbfee000-0xffff881ebbff2000 16K USR RW N= X pte 0xffff881ebbff2000-0xffff881ebbff3000 4K USR ro N= X pte 0xffff881ebbff3000-0xffff881ebbff6000 12K USR RW N= X pte 0xffff881ebbff6000-0xffff881ebbfff000 36K USR ro N= X pte 0xffff881ebbfff000-0xffff881ebc355000 3416K USR RW N= X pte 0xffff881ebc355000-0xffff881ebc356000 4K USR ro N= X pte 0xffff881ebc356000-0xffff881ebc35c000 24K USR RW N= X pte 0xffff881ebc35c000-0xffff881ebc35e000 8K USR ro N= X pte 0xffff881ebc35e000-0xffff881ebc362000 16K USR RW N= X pte 0xffff881ebc362000-0xffff881ebc364000 8K USR ro N= X pte 0xffff881ebc364000-0xffff881ebc366000 8K USR RW N= X pte 0xffff881ebc366000-0xffff881ebc368000 8K USR ro N= X pte 0xffff881ebc368000-0xffff881ebc372000 40K USR RW N= X pte 0xffff881ebc372000-0xffff881ebc374000 8K USR ro N= X pte 0xffff881ebc374000-0xffff881ebc376000 8K USR RW N= X pte 0xffff881ebc376000-0xffff881ebc377000 4K USR ro N= X pte 0xffff881ebc377000-0xffff881ebc37e000 28K USR RW N= X pte 0xffff881ebc37e000-0xffff881ebc37f000 4K USR ro N= X pte 0xffff881ebc37f000-0xffff881ebc385000 24K USR RW N= X pte 0xffff881ebc385000-0xffff881ebc387000 8K USR ro N= X pte 0xffff881ebc387000-0xffff881ebc388000 4K USR RW N= X pte 0xffff881ebc388000-0xffff881ebc38a000 8K USR ro N= X pte 0xffff881ebc38a000-0xffff881ebc38c000 8K USR RW N= X pte 0xffff881ebc38c000-0xffff881ebc38f000 12K USR ro N= X pte 0xffff881ebc38f000-0xffff881ebc392000 12K USR RW N= X pte 0xffff881ebc392000-0xffff881ebc393000 4K USR ro N= X pte 0xffff881ebc393000-0xffff881ebc395000 8K USR RW N= X pte 0xffff881ebc395000-0xffff881ebc396000 4K USR ro N= X pte 0xffff881ebc396000-0xffff881ebc39c000 24K USR RW N= X pte 0xffff881ebc39c000-0xffff881ebc39e000 8K USR ro N= X pte 0xffff881ebc39e000-0xffff881ebc39f000 4K USR RW N= X pte 0xffff881ebc39f000-0xffff881ebc3a0000 4K USR ro N= X pte 0xffff881ebc3a0000-0xffff881ebc3a2000 8K USR RW N= X pte 0xffff881ebc3a2000-0xffff881ebc3a4000 8K USR ro N= X pte 0xffff881ebc3a4000-0xffff881ebc3a5000 4K USR RW N= X pte 0xffff881ebc3a5000-0xffff881ebc3a6000 4K USR ro N= X pte 0xffff881ebc3a6000-0xffff881ebc3aa000 16K USR RW N= X pte 0xffff881ebc3aa000-0xffff881ebc3ab000 4K USR ro N= X pte 0xffff881ebc3ab000-0xffff881ebc3ad000 8K USR RW N= X pte 0xffff881ebc3ad000-0xffff881ebc3ae000 4K USR ro N= X pte 0xffff881ebc3ae000-0xffff881ebc3af000 4K USR RW N= X pte 0xffff881ebc3af000-0xffff881ebc3b0000 4K USR ro N= X pte 0xffff881ebc3b0000-0xffff881ebc3c5000 84K USR RW N= X pte 0xffff881ebc3c5000-0xffff881ebc3c6000 4K USR ro N= X pte 0xffff881ebc3c6000-0xffff881ebc3d0000 40K USR RW N= X pte 0xffff881ebc3d0000-0xffff881ebc3d2000 8K USR ro N= X pte 0xffff881ebc3d2000-0xffff881ebc3d4000 8K USR RW N= X pte 0xffff881ebc3d4000-0xffff881ebc3d5000 4K USR ro N= X pte 0xffff881ebc3d5000-0xffff881ebc3d8000 12K USR RW N= X pte 0xffff881ebc3d8000-0xffff881ebc3da000 8K USR ro N= X pte 0xffff881ebc3da000-0xffff881ebc3f9000 124K USR RW N= X pte 0xffff881ebc3f9000-0xffff881ebc3fa000 4K USR ro N= X pte 0xffff881ebc3fa000-0xffff881ebe71a000 35968K USR RW N= X pte 0xffff881ebe71a000-0xffff881ebe71d000 12K USR ro N= X pte 0xffff881ebe71d000-0xffff881ebe71e000 4K USR RW N= X pte 0xffff881ebe71e000-0xffff881ebe71f000 4K USR ro N= X pte 0xffff881ebe71f000-0xffff881ebe721000 8K USR RW N= X pte 0xffff881ebe721000-0xffff881ebe723000 8K USR ro N= X pte 0xffff881ebe723000-0xffff881ec1283000 44416K USR RW N= X pte 0xffff881ec1283000-0xffff881ec1400000 1524K USR ro N= X pte 0xffff881ec1400000-0xffff881f3082c000 1822896K USR RW N= X pte 0xffff881f3082c000-0xffff881f3082e000 8K USR ro N= X pte 0xffff881f3082e000-0xffff881f30855000 156K USR RW N= X pte 0xffff881f30855000-0xffff881f30856000 4K USR ro N= X pte 0xffff881f30856000-0xffff881f30d21000 4908K USR RW N= X pte 0xffff881f30d21000-0xffff881f30d22000 4K USR ro N= X pte 0xffff881f30d22000-0xffff881f30f23000 2052K USR RW N= X pte 0xffff881f30f23000-0xffff881f30f24000 4K USR ro N= X pte 0xffff881f30f24000-0xffff881f3121d000 3044K USR RW N= X pte 0xffff881f3121d000-0xffff881f31221000 16K USR ro N= X pte 0xffff881f31221000-0xffff881f31a09000 8096K USR RW N= X pte 0xffff881f31a09000-0xffff881f31a0b000 8K USR ro N= X pte 0xffff881f31a0b000-0xffff881f31cbf000 2768K USR RW N= X pte 0xffff881f31cbf000-0xffff881f31cde000 124K USR ro N= X pte 0xffff881f31cde000-0xffff881f35c5e000 65024K USR RW N= X pte 0xffff881f35c5e000-0xffff881f35c9e000 256K USR ro N= X pte 0xffff881f35c9e000-0xffff881f35cbe000 128K USR RW N= X pte 0xffff881f35cbe000-0xffff881f35cbf000 4K USR ro N= X pte 0xffff881f35cbf000-0xffff881f3e05b000 134768K USR RW N= X pte 0xffff881f3e05b000-0xffff881f3e05e000 12K USR ro N= X pte 0xffff881f3e05e000-0xffff881f3e600000 5768K USR RW N= X pte 0xffff881f3e600000-0xffff881f3e7f2000 1992K USR ro N= X pte 0xffff881f3e7f2000-0xffff881f3efaa000 7904K USR RW N= X pte 0xffff881f3efaa000-0xffff881f3efab000 4K USR ro N= X pte 0xffff881f3efab000-0xffff881f3efc3000 96K USR RW N= X pte 0xffff881f3efc3000-0xffff881f3efc7000 16K USR ro N= X pte 0xffff881f3efc7000-0xffff881f40000000 16612K USR RW N= X pte 0xffff881f40000000-0xffff881f40800000 8M = pte 0xffff881f40800000-0xffff881f80000000 1016M = pmd 0xffff881f80000000-0xffff888000000000 386G = pud 0xffff888000000000-0xffffc90000000000 66048G = pgd ---[ vmalloc() Area ]--- 0xffffc90000000000-0xffffc90008000000 128M USR RW N= X pte 0xffffc90008000000-0xffffc90008001000 4K = pte 0xffffc90008001000-0xffffc90008041000 256K USR RW N= X pte 0xffffc90008041000-0xffffc90008042000 4K = pte 0xffffc90008042000-0xffffc9000c042000 64M USR RW N= X pte 0xffffc9000c042000-0xffffc9000c043000 4K = pte 0xffffc9000c043000-0xffffc9000c063000 128K USR RW N= X pte 0xffffc9000c063000-0xffffc9000c064000 4K = pte 0xffffc9000c064000-0xffffc9000c066000 8K USR RW N= X pte 0xffffc9000c066000-0xffffc9000c068000 8K = pte 0xffffc9000c068000-0xffffc9000c069000 4K USR RW N= X pte 0xffffc9000c069000-0xffffc9000c06d000 16K = pte 0xffffc9000c06d000-0xffffc9000c071000 16K USR RW N= X pte 0xffffc9000c071000-0xffffc9000c072000 4K = pte 0xffffc9000c072000-0xffffc9000c07d000 44K USR RW N= X pte 0xffffc9000c07d000-0xffffc9000c080000 12K = pte 0xffffc9000c080000-0xffffc9000c081000 4K USR RW N= X pte 0xffffc9000c081000-0xffffc9000c0a1000 128K = pte 0xffffc9000c0a1000-0xffffc9000c4a1000 4M USR RW N= X pte 0xffffc9000c4a1000-0xffffc9000c4a2000 4K = pte 0xffffc9000c4a2000-0xffffc9000cca2000 8M USR RW N= X pte 0xffffc9000cca2000-0xffffc9000cca3000 4K = pte 0xffffc9000cca3000-0xffffc9000cda3000 1M USR RW N= X pte 0xffffc9000cda3000-0xffffc9000cda4000 4K = pte 0xffffc9000cda4000-0xffffc9000cfa4000 2M USR RW N= X pte 0xffffc9000cfa4000-0xffffc9000cfa5000 4K = pte 0xffffc9000cfa5000-0xffffc9000d1a5000 2M USR RW N= X pte 0xffffc9000d1a5000-0xffffc9000d1a6000 4K = pte 0xffffc9000d1a6000-0xffffc9000d1b2000 48K USR RW N= X pte 0xffffc9000d1b2000-0xffffc9000d800000 6456K = pte 0xffffc9000d800000-0xffffc90040000000 808M = pmd 0xffffc90040000000-0xffffc98000000000 511G = pud 0xffffc98000000000-0xffffea0000000000 33280G = pgd ---[ Vmemmap ]--- 0xffffea0000000000-0xffffea006d7c0000 1793792K USR RW N= X pte 0xffffea006d7c0000-0xffffea006d800000 256K = pte 0xffffea006d800000-0xffffea0080000000 296M = pmd 0xffffea0080000000-0xffffea8000000000 510G = pud 0xffffea8000000000-0xffffff8000000000 21T = pgd 0xffffff8000000000-0xffffffff80000000 510G = pud ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M = pmd 0xffffffff81000000-0xffffffff81002000 8K USR ro x= pte 0xffffffff81002000-0xffffffff81013000 68K USR ro x= pte 0xffffffff81013000-0xffffffff81015000 8K USR ro x= pte 0xffffffff81015000-0xffffffff81017000 8K USR ro x= pte 0xffffffff81017000-0xffffffff81019000 8K USR ro x= pte 0xffffffff81019000-0xffffffff8101a000 4K USR ro x= pte 0xffffffff8101a000-0xffffffff8101b000 4K USR ro x= pte 0xffffffff8101b000-0xffffffff8101f000 16K USR ro x= pte 0xffffffff8101f000-0xffffffff81028000 36K USR ro x= pte 0xffffffff81028000-0xffffffff8102a000 8K USR ro x= pte 0xffffffff8102a000-0xffffffff8102c000 8K USR ro x= pte 0xffffffff8102c000-0xffffffff8103c000 64K USR ro x= pte 0xffffffff8103c000-0xffffffff8103d000 4K USR ro x= pte 0xffffffff8103d000-0xffffffff81051000 80K USR ro x= pte 0xffffffff81051000-0xffffffff81052000 4K USR ro x= pte 0xffffffff81052000-0xffffffff81057000 20K USR ro x= pte 0xffffffff81057000-0xffffffff81058000 4K USR ro x= pte 0xffffffff81058000-0xffffffff81061000 36K USR ro x= pte 0xffffffff81061000-0xffffffff81063000 8K USR ro x= pte 0xffffffff81063000-0xffffffff8106b000 32K USR ro x= pte 0xffffffff8106b000-0xffffffff8106c000 4K USR ro x= pte 0xffffffff8106c000-0xffffffff81078000 48K USR ro x= pte 0xffffffff81078000-0xffffffff8107a000 8K USR ro x= pte 0xffffffff8107a000-0xffffffff81083000 36K USR ro x= pte 0xffffffff81083000-0xffffffff81084000 4K USR ro x= pte 0xffffffff81084000-0xffffffff8108f000 44K USR ro x= pte 0xffffffff8108f000-0xffffffff81090000 4K USR ro x= pte 0xffffffff81090000-0xffffffff81094000 16K USR ro x= pte 0xffffffff81094000-0xffffffff81097000 12K USR ro x= pte 0xffffffff81097000-0xffffffff810a0000 36K USR ro x= pte 0xffffffff810a0000-0xffffffff810a2000 8K USR ro x= pte 0xffffffff810a2000-0xffffffff810a7000 20K USR ro x= pte 0xffffffff810a7000-0xffffffff810a8000 4K USR ro x= pte 0xffffffff810a8000-0xffffffff810aa000 8K USR ro x= pte 0xffffffff810aa000-0xffffffff810af000 20K USR ro x= pte 0xffffffff810af000-0xffffffff810b4000 20K USR ro x= pte 0xffffffff810b4000-0xffffffff810b6000 8K USR ro x= pte 0xffffffff810b6000-0xffffffff810c0000 40K USR ro x= pte 0xffffffff810c0000-0xffffffff810c4000 16K USR ro x= pte 0xffffffff810c4000-0xffffffff810c6000 8K USR ro x= pte 0xffffffff810c6000-0xffffffff810ca000 16K USR ro x= pte 0xffffffff810ca000-0xffffffff810cc000 8K USR ro x= pte 0xffffffff810cc000-0xffffffff810cd000 4K USR ro x= pte 0xffffffff810cd000-0xffffffff810d5000 32K USR ro x= pte 0xffffffff810d5000-0xffffffff810d9000 16K USR ro x= pte 0xffffffff810d9000-0xffffffff810da000 4K USR ro x= pte 0xffffffff810da000-0xffffffff810db000 4K USR ro x= pte 0xffffffff810db000-0xffffffff810dc000 4K USR ro x= pte 0xffffffff810dc000-0xffffffff810dd000 4K USR ro x= pte 0xffffffff810dd000-0xffffffff810e2000 20K USR ro x= pte 0xffffffff810e2000-0xffffffff810e3000 4K USR ro x= pte 0xffffffff810e3000-0xffffffff810f8000 84K USR ro x= pte 0xffffffff810f8000-0xffffffff810fb000 12K USR ro x= pte 0xffffffff810fb000-0xffffffff81101000 24K USR ro x= pte 0xffffffff81101000-0xffffffff81102000 4K USR ro x= pte 0xffffffff81102000-0xffffffff81106000 16K USR ro x= pte 0xffffffff81106000-0xffffffff81107000 4K USR ro x= pte 0xffffffff81107000-0xffffffff81108000 4K USR ro x= pte 0xffffffff81108000-0xffffffff81109000 4K USR ro x= pte 0xffffffff81109000-0xffffffff81113000 40K USR ro x= pte 0xffffffff81113000-0xffffffff81114000 4K USR ro x= pte 0xffffffff81114000-0xffffffff81117000 12K USR ro x= pte 0xffffffff81117000-0xffffffff81118000 4K USR ro x= pte 0xffffffff81118000-0xffffffff81122000 40K USR ro x= pte 0xffffffff81122000-0xffffffff81124000 8K USR ro x= pte 0xffffffff81124000-0xffffffff81143000 124K USR ro x= pte 0xffffffff81143000-0xffffffff81145000 8K USR ro x= pte 0xffffffff81145000-0xffffffff81166000 132K USR ro x= pte 0xffffffff81166000-0xffffffff81168000 8K USR ro x= pte 0xffffffff81168000-0xffffffff8116d000 20K USR ro x= pte 0xffffffff8116d000-0xffffffff8116e000 4K USR ro x= pte 0xffffffff8116e000-0xffffffff8116f000 4K USR ro x= pte 0xffffffff8116f000-0xffffffff81170000 4K USR ro x= pte 0xffffffff81170000-0xffffffff81174000 16K USR ro x= pte 0xffffffff81174000-0xffffffff81177000 12K USR ro x= pte 0xffffffff81177000-0xffffffff8117a000 12K USR ro x= pte 0xffffffff8117a000-0xffffffff8117e000 16K USR ro x= pte 0xffffffff8117e000-0xffffffff8118d000 60K USR ro x= pte 0xffffffff8118d000-0xffffffff8118e000 4K USR ro x= pte 0xffffffff8118e000-0xffffffff81190000 8K USR ro x= pte 0xffffffff81190000-0xffffffff81191000 4K USR ro x= pte 0xffffffff81191000-0xffffffff81192000 4K USR ro x= pte 0xffffffff81192000-0xffffffff81193000 4K USR ro x= pte 0xffffffff81193000-0xffffffff81194000 4K USR ro x= pte 0xffffffff81194000-0xffffffff81197000 12K USR ro x= pte 0xffffffff81197000-0xffffffff81198000 4K USR ro x= pte 0xffffffff81198000-0xffffffff81199000 4K USR ro x= pte 0xffffffff81199000-0xffffffff811a0000 28K USR ro x= pte 0xffffffff811a0000-0xffffffff811a1000 4K USR ro x= pte 0xffffffff811a1000-0xffffffff811ab000 40K USR ro x= pte 0xffffffff811ab000-0xffffffff811ac000 4K USR ro x= pte 0xffffffff811ac000-0xffffffff811af000 12K USR ro x= pte 0xffffffff811af000-0xffffffff811b1000 8K USR ro x= pte 0xffffffff811b1000-0xffffffff811b4000 12K USR ro x= pte 0xffffffff811b4000-0xffffffff811b5000 4K USR ro x= pte 0xffffffff811b5000-0xffffffff811b9000 16K USR ro x= pte 0xffffffff811b9000-0xffffffff811bb000 8K USR ro x= pte 0xffffffff811bb000-0xffffffff811bd000 8K USR ro x= pte 0xffffffff811bd000-0xffffffff811be000 4K USR ro x= pte 0xffffffff811be000-0xffffffff811c2000 16K USR ro x= pte 0xffffffff811c2000-0xffffffff811c6000 16K USR ro x= pte 0xffffffff811c6000-0xffffffff811c7000 4K USR ro x= pte 0xffffffff811c7000-0xffffffff811c8000 4K USR ro x= pte 0xffffffff811c8000-0xffffffff811c9000 4K USR ro x= pte 0xffffffff811c9000-0xffffffff811ca000 4K USR ro x= pte 0xffffffff811ca000-0xffffffff811cf000 20K USR ro x= pte 0xffffffff811cf000-0xffffffff811d0000 4K USR ro x= pte 0xffffffff811d0000-0xffffffff811d3000 12K USR ro x= pte 0xffffffff811d3000-0xffffffff811d5000 8K USR ro x= pte 0xffffffff811d5000-0xffffffff811d6000 4K USR ro x= pte 0xffffffff811d6000-0xffffffff811d8000 8K USR ro x= pte 0xffffffff811d8000-0xffffffff811d9000 4K USR ro x= pte 0xffffffff811d9000-0xffffffff811da000 4K USR ro x= pte 0xffffffff811da000-0xffffffff811e0000 24K USR ro x= pte 0xffffffff811e0000-0xffffffff811e3000 12K USR ro x= pte 0xffffffff811e3000-0xffffffff811e9000 24K USR ro x= pte 0xffffffff811e9000-0xffffffff811ea000 4K USR ro x= pte 0xffffffff811ea000-0xffffffff811eb000 4K USR ro x= pte 0xffffffff811eb000-0xffffffff811f1000 24K USR ro x= pte 0xffffffff811f1000-0xffffffff811f7000 24K USR ro x= pte 0xffffffff811f7000-0xffffffff811f8000 4K USR ro x= pte 0xffffffff811f8000-0xffffffff811fa000 8K USR ro x= pte 0xffffffff811fa000-0xffffffff811fb000 4K USR ro x= pte 0xffffffff811fb000-0xffffffff811fd000 8K USR ro x= pte 0xffffffff811fd000-0xffffffff811fe000 4K USR ro x= pte 0xffffffff811fe000-0xffffffff81200000 8K USR ro x= pte 0xffffffff81200000-0xffffffff81201000 4K USR ro x= pte 0xffffffff81201000-0xffffffff81203000 8K USR ro x= pte 0xffffffff81203000-0xffffffff81207000 16K USR ro x= pte 0xffffffff81207000-0xffffffff81209000 8K USR ro x= pte 0xffffffff81209000-0xffffffff8120a000 4K USR ro x= pte 0xffffffff8120a000-0xffffffff8120b000 4K USR ro x= pte 0xffffffff8120b000-0xffffffff8120c000 4K USR ro x= pte 0xffffffff8120c000-0xffffffff8120e000 8K USR ro x= pte 0xffffffff8120e000-0xffffffff81223000 84K USR ro x= pte 0xffffffff81223000-0xffffffff81228000 20K USR ro x= pte 0xffffffff81228000-0xffffffff81229000 4K USR ro x= pte 0xffffffff81229000-0xffffffff8123b000 72K USR ro x= pte 0xffffffff8123b000-0xffffffff8123d000 8K USR ro x= pte 0xffffffff8123d000-0xffffffff8123e000 4K USR ro x= pte 0xffffffff8123e000-0xffffffff8123f000 4K USR ro x= pte 0xffffffff8123f000-0xffffffff81242000 12K USR ro x= pte 0xffffffff81242000-0xffffffff81244000 8K USR ro x= pte 0xffffffff81244000-0xffffffff81245000 4K USR ro x= pte 0xffffffff81245000-0xffffffff81247000 8K USR ro x= pte 0xffffffff81247000-0xffffffff81248000 4K USR ro x= pte 0xffffffff81248000-0xffffffff81252000 40K USR ro x= pte 0xffffffff81252000-0xffffffff81253000 4K USR ro x= pte 0xffffffff81253000-0xffffffff81254000 4K USR ro x= pte 0xffffffff81254000-0xffffffff81255000 4K USR ro x= pte 0xffffffff81255000-0xffffffff81258000 12K USR ro x= pte 0xffffffff81258000-0xffffffff81259000 4K USR ro x= pte 0xffffffff81259000-0xffffffff81268000 60K USR ro x= pte 0xffffffff81268000-0xffffffff8126e000 24K USR ro x= pte 0xffffffff8126e000-0xffffffff8126f000 4K USR ro x= pte 0xffffffff8126f000-0xffffffff81272000 12K USR ro x= pte 0xffffffff81272000-0xffffffff81273000 4K USR ro x= pte 0xffffffff81273000-0xffffffff81274000 4K USR ro x= pte 0xffffffff81274000-0xffffffff8127a000 24K USR ro x= pte 0xffffffff8127a000-0xffffffff8127c000 8K USR ro x= pte 0xffffffff8127c000-0xffffffff8127d000 4K USR ro x= pte 0xffffffff8127d000-0xffffffff81285000 32K USR ro x= pte 0xffffffff81285000-0xffffffff81286000 4K USR ro x= pte 0xffffffff81286000-0xffffffff81287000 4K USR ro x= pte 0xffffffff81287000-0xffffffff81288000 4K USR ro x= pte 0xffffffff81288000-0xffffffff81289000 4K USR ro x= pte 0xffffffff81289000-0xffffffff8128d000 16K USR ro x= pte 0xffffffff8128d000-0xffffffff8128f000 8K USR ro x= pte 0xffffffff8128f000-0xffffffff81291000 8K USR ro x= pte 0xffffffff81291000-0xffffffff81292000 4K USR ro x= pte 0xffffffff81292000-0xffffffff8129f000 52K USR ro x= pte 0xffffffff8129f000-0xffffffff812a0000 4K USR ro x= pte 0xffffffff812a0000-0xffffffff812a1000 4K USR ro x= pte 0xffffffff812a1000-0xffffffff812a3000 8K USR ro x= pte 0xffffffff812a3000-0xffffffff812a5000 8K USR ro x= pte 0xffffffff812a5000-0xffffffff812a6000 4K USR ro x= pte 0xffffffff812a6000-0xffffffff812a9000 12K USR ro x= pte 0xffffffff812a9000-0xffffffff812ab000 8K USR ro x= pte 0xffffffff812ab000-0xffffffff812c3000 96K USR ro x= pte 0xffffffff812c3000-0xffffffff812c6000 12K USR ro x= pte 0xffffffff812c6000-0xffffffff812cc000 24K USR ro x= pte 0xffffffff812cc000-0xffffffff812cf000 12K USR ro x= pte 0xffffffff812cf000-0xffffffff812d1000 8K USR ro x= pte 0xffffffff812d1000-0xffffffff812d2000 4K USR ro x= pte 0xffffffff812d2000-0xffffffff812d3000 4K USR ro x= pte 0xffffffff812d3000-0xffffffff812d7000 16K USR ro x= pte 0xffffffff812d7000-0xffffffff812d8000 4K USR ro x= pte 0xffffffff812d8000-0xffffffff812da000 8K USR ro x= pte 0xffffffff812da000-0xffffffff812dc000 8K USR ro x= pte 0xffffffff812dc000-0xffffffff812e1000 20K USR ro x= pte 0xffffffff812e1000-0xffffffff812e3000 8K USR ro x= pte 0xffffffff812e3000-0xffffffff812e4000 4K USR ro x= pte 0xffffffff812e4000-0xffffffff812e5000 4K USR ro x= pte 0xffffffff812e5000-0xffffffff812e6000 4K USR ro x= pte 0xffffffff812e6000-0xffffffff812e7000 4K USR ro x= pte 0xffffffff812e7000-0xffffffff812ed000 24K USR ro x= pte 0xffffffff812ed000-0xffffffff812ee000 4K USR ro x= pte 0xffffffff812ee000-0xffffffff812f9000 44K USR ro x= pte 0xffffffff812f9000-0xffffffff812fa000 4K USR ro x= pte 0xffffffff812fa000-0xffffffff812fe000 16K USR ro x= pte 0xffffffff812fe000-0xffffffff81300000 8K USR ro x= pte 0xffffffff81300000-0xffffffff81302000 8K USR ro x= pte 0xffffffff81302000-0xffffffff8130d000 44K USR ro x= pte 0xffffffff8130d000-0xffffffff8130e000 4K USR ro x= pte 0xffffffff8130e000-0xffffffff8130f000 4K USR ro x= pte 0xffffffff8130f000-0xffffffff81312000 12K USR ro x= pte 0xffffffff81312000-0xffffffff81314000 8K USR ro x= pte 0xffffffff81314000-0xffffffff81318000 16K USR ro x= pte 0xffffffff81318000-0xffffffff8131b000 12K USR ro x= pte 0xffffffff8131b000-0xffffffff8131c000 4K USR ro x= pte 0xffffffff8131c000-0xffffffff81324000 32K USR ro x= pte 0xffffffff81324000-0xffffffff81329000 20K USR ro x= pte 0xffffffff81329000-0xffffffff8132d000 16K USR ro x= pte 0xffffffff8132d000-0xffffffff8132e000 4K USR ro x= pte 0xffffffff8132e000-0xffffffff8132f000 4K USR ro x= pte 0xffffffff8132f000-0xffffffff81332000 12K USR ro x= pte 0xffffffff81332000-0xffffffff81333000 4K USR ro x= pte 0xffffffff81333000-0xffffffff81334000 4K USR ro x= pte 0xffffffff81334000-0xffffffff81335000 4K USR ro x= pte 0xffffffff81335000-0xffffffff81337000 8K USR ro x= pte 0xffffffff81337000-0xffffffff8133b000 16K USR ro x= pte 0xffffffff8133b000-0xffffffff8133c000 4K USR ro x= pte 0xffffffff8133c000-0xffffffff81340000 16K USR ro x= pte 0xffffffff81340000-0xffffffff81342000 8K USR ro x= pte 0xffffffff81342000-0xffffffff81343000 4K USR ro x= pte 0xffffffff81343000-0xffffffff81348000 20K USR ro x= pte 0xffffffff81348000-0xffffffff8134c000 16K USR ro x= pte 0xffffffff8134c000-0xffffffff81350000 16K USR ro x= pte 0xffffffff81350000-0xffffffff81351000 4K USR ro x= pte 0xffffffff81351000-0xffffffff81353000 8K USR ro x= pte 0xffffffff81353000-0xffffffff81358000 20K USR ro x= pte 0xffffffff81358000-0xffffffff8135e000 24K USR ro x= pte 0xffffffff8135e000-0xffffffff8135f000 4K USR ro x= pte 0xffffffff8135f000-0xffffffff81361000 8K USR ro x= pte 0xffffffff81361000-0xffffffff81366000 20K USR ro x= pte 0xffffffff81366000-0xffffffff81367000 4K USR ro x= pte 0xffffffff81367000-0xffffffff81368000 4K USR ro x= pte 0xffffffff81368000-0xffffffff8136a000 8K USR ro x= pte 0xffffffff8136a000-0xffffffff81374000 40K USR ro x= pte 0xffffffff81374000-0xffffffff81376000 8K USR ro x= pte 0xffffffff81376000-0xffffffff81379000 12K USR ro x= pte 0xffffffff81379000-0xffffffff8137f000 24K USR ro x= pte 0xffffffff8137f000-0xffffffff81380000 4K USR ro x= pte 0xffffffff81380000-0xffffffff81383000 12K USR ro x= pte 0xffffffff81383000-0xffffffff81384000 4K USR ro x= pte 0xffffffff81384000-0xffffffff81387000 12K USR ro x= pte 0xffffffff81387000-0xffffffff81389000 8K USR ro x= pte 0xffffffff81389000-0xffffffff8138c000 12K USR ro x= pte 0xffffffff8138c000-0xffffffff81393000 28K USR ro x= pte 0xffffffff81393000-0xffffffff81395000 8K USR ro x= pte 0xffffffff81395000-0xffffffff81398000 12K USR ro x= pte 0xffffffff81398000-0xffffffff8139a000 8K USR ro x= pte 0xffffffff8139a000-0xffffffff8139c000 8K USR ro x= pte 0xffffffff8139c000-0xffffffff8139d000 4K USR ro x= pte 0xffffffff8139d000-0xffffffff813a3000 24K USR ro x= pte 0xffffffff813a3000-0xffffffff813a4000 4K USR ro x= pte 0xffffffff813a4000-0xffffffff813a5000 4K USR ro x= pte 0xffffffff813a5000-0xffffffff813a6000 4K USR ro x= pte 0xffffffff813a6000-0xffffffff813a9000 12K USR ro x= pte 0xffffffff813a9000-0xffffffff813ab000 8K USR ro x= pte 0xffffffff813ab000-0xffffffff813ac000 4K USR ro x= pte 0xffffffff813ac000-0xffffffff813ae000 8K USR ro x= pte 0xffffffff813ae000-0xffffffff813b1000 12K USR ro x= pte 0xffffffff813b1000-0xffffffff813b3000 8K USR ro x= pte 0xffffffff813b3000-0xffffffff813b5000 8K USR ro x= pte 0xffffffff813b5000-0xffffffff813b9000 16K USR ro x= pte 0xffffffff813b9000-0xffffffff813ba000 4K USR ro x= pte 0xffffffff813ba000-0xffffffff813bf000 20K USR ro x= pte 0xffffffff813bf000-0xffffffff813ce000 60K USR ro x= pte 0xffffffff813ce000-0xffffffff813cf000 4K USR ro x= pte 0xffffffff813cf000-0xffffffff813d0000 4K USR ro x= pte 0xffffffff813d0000-0xffffffff813d2000 8K USR ro x= pte 0xffffffff813d2000-0xffffffff813d3000 4K USR ro x= pte 0xffffffff813d3000-0xffffffff813db000 32K USR ro x= pte 0xffffffff813db000-0xffffffff813dc000 4K USR ro x= pte 0xffffffff813dc000-0xffffffff813dd000 4K USR ro x= pte 0xffffffff813dd000-0xffffffff813de000 4K USR ro x= pte 0xffffffff813de000-0xffffffff813e0000 8K USR ro x= pte 0xffffffff813e0000-0xffffffff813e3000 12K USR ro x= pte 0xffffffff813e3000-0xffffffff813e5000 8K USR ro x= pte 0xffffffff813e5000-0xffffffff813e8000 12K USR ro x= pte 0xffffffff813e8000-0xffffffff813ea000 8K USR ro x= pte 0xffffffff813ea000-0xffffffff813ec000 8K USR ro x= pte 0xffffffff813ec000-0xffffffff813ed000 4K USR ro x= pte 0xffffffff813ed000-0xffffffff813ef000 8K USR ro x= pte 0xffffffff813ef000-0xffffffff813f3000 16K USR ro x= pte 0xffffffff813f3000-0xffffffff813f4000 4K USR ro x= pte 0xffffffff813f4000-0xffffffff813f6000 8K USR ro x= pte 0xffffffff813f6000-0xffffffff813f7000 4K USR ro x= pte 0xffffffff813f7000-0xffffffff813fa000 12K USR ro x= pte 0xffffffff813fa000-0xffffffff813fb000 4K USR ro x= pte 0xffffffff813fb000-0xffffffff813fd000 8K USR ro x= pte 0xffffffff813fd000-0xffffffff813fe000 4K USR ro x= pte 0xffffffff813fe000-0xffffffff81403000 20K USR ro x= pte 0xffffffff81403000-0xffffffff81404000 4K USR ro x= pte 0xffffffff81404000-0xffffffff81406000 8K USR ro x= pte 0xffffffff81406000-0xffffffff81408000 8K USR ro x= pte 0xffffffff81408000-0xffffffff81411000 36K USR ro x= pte 0xffffffff81411000-0xffffffff81412000 4K USR ro x= pte 0xffffffff81412000-0xffffffff81413000 4K USR ro x= pte 0xffffffff81413000-0xffffffff81415000 8K USR ro x= pte 0xffffffff81415000-0xffffffff81416000 4K USR ro x= pte 0xffffffff81416000-0xffffffff81419000 12K USR ro x= pte 0xffffffff81419000-0xffffffff8141e000 20K USR ro x= pte 0xffffffff8141e000-0xffffffff81425000 28K USR ro x= pte 0xffffffff81425000-0xffffffff81426000 4K USR ro x= pte 0xffffffff81426000-0xffffffff81428000 8K USR ro x= pte 0xffffffff81428000-0xffffffff8142f000 28K USR ro x= pte 0xffffffff8142f000-0xffffffff81430000 4K USR ro x= pte 0xffffffff81430000-0xffffffff81437000 28K USR ro x= pte 0xffffffff81437000-0xffffffff81438000 4K USR ro x= pte 0xffffffff81438000-0xffffffff81439000 4K USR ro x= pte 0xffffffff81439000-0xffffffff8143d000 16K USR ro x= pte 0xffffffff8143d000-0xffffffff8143e000 4K USR ro x= pte 0xffffffff8143e000-0xffffffff8143f000 4K USR ro x= pte 0xffffffff8143f000-0xffffffff81440000 4K USR ro x= pte 0xffffffff81440000-0xffffffff81443000 12K USR ro x= pte 0xffffffff81443000-0xffffffff81445000 8K USR ro x= pte 0xffffffff81445000-0xffffffff81446000 4K USR ro x= pte 0xffffffff81446000-0xffffffff81448000 8K USR ro x= pte 0xffffffff81448000-0xffffffff8144d000 20K USR ro x= pte 0xffffffff8144d000-0xffffffff8144f000 8K USR ro x= pte 0xffffffff8144f000-0xffffffff81451000 8K USR ro x= pte 0xffffffff81451000-0xffffffff81452000 4K USR ro x= pte 0xffffffff81452000-0xffffffff81458000 24K USR ro x= pte 0xffffffff81458000-0xffffffff81459000 4K USR ro x= pte 0xffffffff81459000-0xffffffff8145a000 4K USR ro x= pte 0xffffffff8145a000-0xffffffff8145c000 8K USR ro x= pte 0xffffffff8145c000-0xffffffff8145d000 4K USR ro x= pte 0xffffffff8145d000-0xffffffff81462000 20K USR ro x= pte 0xffffffff81462000-0xffffffff81463000 4K USR ro x= pte 0xffffffff81463000-0xffffffff81464000 4K USR ro x= pte 0xffffffff81464000-0xffffffff81465000 4K USR ro x= pte 0xffffffff81465000-0xffffffff81467000 8K USR ro x= pte 0xffffffff81467000-0xffffffff81468000 4K USR ro x= pte 0xffffffff81468000-0xffffffff81469000 4K USR ro x= pte 0xffffffff81469000-0xffffffff8146a000 4K USR ro x= pte 0xffffffff8146a000-0xffffffff8146b000 4K USR ro x= pte 0xffffffff8146b000-0xffffffff81470000 20K USR ro x= pte 0xffffffff81470000-0xffffffff81471000 4K USR ro x= pte 0xffffffff81471000-0xffffffff81473000 8K USR ro x= pte 0xffffffff81473000-0xffffffff81477000 16K USR ro x= pte 0xffffffff81477000-0xffffffff8147a000 12K USR ro x= pte 0xffffffff8147a000-0xffffffff8147b000 4K USR ro x= pte 0xffffffff8147b000-0xffffffff8147c000 4K USR ro x= pte 0xffffffff8147c000-0xffffffff8147d000 4K USR ro x= pte 0xffffffff8147d000-0xffffffff81482000 20K USR ro x= pte 0xffffffff81482000-0xffffffff81484000 8K USR ro x= pte 0xffffffff81484000-0xffffffff81485000 4K USR ro x= pte 0xffffffff81485000-0xffffffff81486000 4K USR ro x= pte 0xffffffff81486000-0xffffffff81489000 12K USR ro x= pte 0xffffffff81489000-0xffffffff8148a000 4K USR ro x= pte 0xffffffff8148a000-0xffffffff8148b000 4K USR ro x= pte 0xffffffff8148b000-0xffffffff8148c000 4K USR ro x= pte 0xffffffff8148c000-0xffffffff81499000 52K USR ro x= pte 0xffffffff81499000-0xffffffff8149a000 4K USR ro x= pte 0xffffffff8149a000-0xffffffff814a2000 32K USR ro x= pte 0xffffffff814a2000-0xffffffff814a5000 12K USR ro x= pte 0xffffffff814a5000-0xffffffff814a8000 12K USR ro x= pte 0xffffffff814a8000-0xffffffff814b0000 32K USR ro x= pte 0xffffffff814b0000-0xffffffff814b1000 4K USR ro x= pte 0xffffffff814b1000-0xffffffff814b2000 4K USR ro x= pte 0xffffffff814b2000-0xffffffff814c2000 64K USR ro x= pte 0xffffffff814c2000-0xffffffff814c3000 4K USR ro x= pte 0xffffffff814c3000-0xffffffff814c5000 8K USR ro x= pte 0xffffffff814c5000-0xffffffff814cb000 24K USR ro x= pte 0xffffffff814cb000-0xffffffff814cc000 4K USR ro x= pte 0xffffffff814cc000-0xffffffff814cf000 12K USR ro x= pte 0xffffffff814cf000-0xffffffff814d0000 4K USR ro x= pte 0xffffffff814d0000-0xffffffff814d1000 4K USR ro x= pte 0xffffffff814d1000-0xffffffff814d3000 8K USR ro x= pte 0xffffffff814d3000-0xffffffff814d4000 4K USR ro x= pte 0xffffffff814d4000-0xffffffff814d6000 8K USR ro x= pte 0xffffffff814d6000-0xffffffff814d7000 4K USR ro x= pte 0xffffffff814d7000-0xffffffff814db000 16K USR ro x= pte 0xffffffff814db000-0xffffffff814dc000 4K USR ro x= pte 0xffffffff814dc000-0xffffffff814de000 8K USR ro x= pte 0xffffffff814de000-0xffffffff814df000 4K USR ro x= pte 0xffffffff814df000-0xffffffff814e3000 16K USR ro x= pte 0xffffffff814e3000-0xffffffff814e7000 16K USR ro x= pte 0xffffffff814e7000-0xffffffff814e8000 4K USR ro x= pte 0xffffffff814e8000-0xffffffff814e9000 4K USR ro x= pte 0xffffffff814e9000-0xffffffff814f1000 32K USR ro x= pte 0xffffffff814f1000-0xffffffff814f2000 4K USR ro x= pte 0xffffffff814f2000-0xffffffff814f6000 16K USR ro x= pte 0xffffffff814f6000-0xffffffff814f7000 4K USR ro x= pte 0xffffffff814f7000-0xffffffff814f8000 4K USR ro x= pte 0xffffffff814f8000-0xffffffff814f9000 4K USR ro x= pte 0xffffffff814f9000-0xffffffff814fe000 20K USR ro x= pte 0xffffffff814fe000-0xffffffff81503000 20K USR ro x= pte 0xffffffff81503000-0xffffffff81508000 20K USR ro x= pte 0xffffffff81508000-0xffffffff8150d000 20K USR ro x= pte 0xffffffff8150d000-0xffffffff81511000 16K USR ro x= pte 0xffffffff81511000-0xffffffff81513000 8K USR ro x= pte 0xffffffff81513000-0xffffffff81514000 4K USR ro x= pte 0xffffffff81514000-0xffffffff81515000 4K USR ro x= pte 0xffffffff81515000-0xffffffff81516000 4K USR ro x= pte 0xffffffff81516000-0xffffffff8151b000 20K USR ro x= pte 0xffffffff8151b000-0xffffffff81520000 20K USR ro x= pte 0xffffffff81520000-0xffffffff81521000 4K USR ro x= pte 0xffffffff81521000-0xffffffff81523000 8K USR ro x= pte 0xffffffff81523000-0xffffffff81525000 8K USR ro x= pte 0xffffffff81525000-0xffffffff81526000 4K USR ro x= pte 0xffffffff81526000-0xffffffff81529000 12K USR ro x= pte 0xffffffff81529000-0xffffffff8152a000 4K USR ro x= pte 0xffffffff8152a000-0xffffffff8152b000 4K USR ro x= pte 0xffffffff8152b000-0xffffffff8152e000 12K USR ro x= pte 0xffffffff8152e000-0xffffffff81533000 20K USR ro x= pte 0xffffffff81533000-0xffffffff81535000 8K USR ro x= pte 0xffffffff81535000-0xffffffff81537000 8K USR ro x= pte 0xffffffff81537000-0xffffffff81538000 4K USR ro x= pte 0xffffffff81538000-0xffffffff81539000 4K USR ro x= pte 0xffffffff81539000-0xffffffff8153b000 8K USR ro x= pte 0xffffffff8153b000-0xffffffff8153d000 8K USR ro x= pte 0xffffffff8153d000-0xffffffff81541000 16K USR ro x= pte 0xffffffff81541000-0xffffffff81542000 4K USR ro x= pte 0xffffffff81542000-0xffffffff81544000 8K USR ro x= pte 0xffffffff81544000-0xffffffff81545000 4K USR ro x= pte 0xffffffff81545000-0xffffffff81547000 8K USR ro x= pte 0xffffffff81547000-0xffffffff81551000 40K USR ro x= pte 0xffffffff81551000-0xffffffff81552000 4K USR ro x= pte 0xffffffff81552000-0xffffffff81554000 8K USR ro x= pte 0xffffffff81554000-0xffffffff81555000 4K USR ro x= pte 0xffffffff81555000-0xffffffff8155d000 32K USR ro x= pte 0xffffffff8155d000-0xffffffff8155f000 8K USR ro x= pte 0xffffffff8155f000-0xffffffff81563000 16K USR ro x= pte 0xffffffff81563000-0xffffffff81566000 12K USR ro x= pte 0xffffffff81566000-0xffffffff81567000 4K USR ro x= pte 0xffffffff81567000-0xffffffff81568000 4K USR ro x= pte 0xffffffff81568000-0xffffffff8156a000 8K USR ro x= pte 0xffffffff8156a000-0xffffffff8156b000 4K USR ro x= pte 0xffffffff8156b000-0xffffffff81572000 28K USR ro x= pte 0xffffffff81572000-0xffffffff81573000 4K USR ro x= pte 0xffffffff81573000-0xffffffff81576000 12K USR ro x= pte 0xffffffff81576000-0xffffffff81577000 4K USR ro x= pte 0xffffffff81577000-0xffffffff81578000 4K USR ro x= pte 0xffffffff81578000-0xffffffff81579000 4K USR ro x= pte 0xffffffff81579000-0xffffffff8157a000 4K USR ro x= pte 0xffffffff8157a000-0xffffffff8157b000 4K USR ro x= pte 0xffffffff8157b000-0xffffffff8157d000 8K USR ro x= pte 0xffffffff8157d000-0xffffffff8157f000 8K USR ro x= pte 0xffffffff8157f000-0xffffffff81582000 12K USR ro x= pte 0xffffffff81582000-0xffffffff81584000 8K USR ro x= pte 0xffffffff81584000-0xffffffff81586000 8K USR ro x= pte 0xffffffff81586000-0xffffffff81588000 8K USR ro x= pte 0xffffffff81588000-0xffffffff81589000 4K USR ro x= pte 0xffffffff81589000-0xffffffff8158d000 16K USR ro x= pte 0xffffffff8158d000-0xffffffff8158f000 8K USR ro x= pte 0xffffffff8158f000-0xffffffff81593000 16K USR ro x= pte 0xffffffff81593000-0xffffffff81594000 4K USR ro x= pte 0xffffffff81594000-0xffffffff81595000 4K USR ro x= pte 0xffffffff81595000-0xffffffff81596000 4K USR ro x= pte 0xffffffff81596000-0xffffffff81599000 12K USR ro x= pte 0xffffffff81599000-0xffffffff815ab000 72K USR ro x= pte 0xffffffff815ab000-0xffffffff815ac000 4K USR ro x= pte 0xffffffff815ac000-0xffffffff815b0000 16K USR ro x= pte 0xffffffff815b0000-0xffffffff815b1000 4K USR ro x= pte 0xffffffff815b1000-0xffffffff815b7000 24K USR ro x= pte 0xffffffff815b7000-0xffffffff81600000 292K USR RW N= X pte 0xffffffff81600000-0xffffffff8179c000 1648K USR ro N= X pte 0xffffffff8179c000-0xffffffff81800000 400K USR RW N= X pte 0xffffffff81800000-0xffffffff81802000 8K USR RW x= pte 0xffffffff81802000-0xffffffff81803000 4K USR RW x= pte 0xffffffff81803000-0xffffffff81805000 8K USR RW x= pte 0xffffffff81805000-0xffffffff8180b000 24K USR RW x= pte 0xffffffff8180b000-0xffffffff8180f000 16K USR ro x= pte 0xffffffff8180f000-0xffffffff81810000 4K USR RW x= pte 0xffffffff81810000-0xffffffff81812000 8K USR ro x= pte 0xffffffff81812000-0xffffffff81813000 4K USR RW x= pte 0xffffffff81813000-0xffffffff81815000 8K USR RW x= pte 0xffffffff81815000-0xffffffff81816000 4K USR RW x= pte 0xffffffff81816000-0xffffffff81818000 8K USR RW x= pte 0xffffffff81818000-0xffffffff8181a000 8K USR RW x= pte 0xffffffff8181a000-0xffffffff8181d000 12K USR RW x= pte 0xffffffff8181d000-0xffffffff8181e000 4K USR RW x= pte 0xffffffff8181e000-0xffffffff81832000 80K USR RW x= pte 0xffffffff81832000-0xffffffff81834000 8K USR RW x= pte 0xffffffff81834000-0xffffffff8183a000 24K USR RW x= pte 0xffffffff8183a000-0xffffffff8183d000 12K USR RW x= pte 0xffffffff8183d000-0xffffffff81841000 16K USR RW x= pte 0xffffffff81841000-0xffffffff81843000 8K USR RW x= pte 0xffffffff81843000-0xffffffff81845000 8K USR RW x= pte 0xffffffff81845000-0xffffffff81846000 4K USR RW x= pte 0xffffffff81846000-0xffffffff81849000 12K USR RW x= pte 0xffffffff81849000-0xffffffff8184a000 4K USR RW x= pte 0xffffffff8184a000-0xffffffff8184f000 20K USR RW x= pte 0xffffffff8184f000-0xffffffff81850000 4K USR RW x= pte 0xffffffff81850000-0xffffffff81885000 212K USR RW x= pte 0xffffffff81885000-0xffffffff81938000 716K USR RW N= X pte 0xffffffff81938000-0xffffffff8193a000 8K USR RW x= pte 0xffffffff8193a000-0xffffffff8193b000 4K USR ro x= pte 0xffffffff8193b000-0xffffffff8193d000 8K USR RW x= pte 0xffffffff8193d000-0xffffffff8193e000 4K USR ro x= pte 0xffffffff8193e000-0xffffffff81948000 40K USR RW x= pte 0xffffffff81948000-0xffffffff8194a000 8K USR RW x= pte 0xffffffff8194a000-0xffffffff8194c000 8K USR RW x= pte 0xffffffff8194c000-0xffffffff8196c000 128K USR RW x= pte 0xffffffff8196c000-0xffffffff8196d000 4K USR RW x= pte 0xffffffff8196d000-0xffffffff81970000 12K USR RW x= pte 0xffffffff81970000-0xffffffff81971000 4K USR RW x= pte 0xffffffff81971000-0xffffffff81972000 4K USR RW x= pte 0xffffffff81972000-0xffffffff81973000 4K USR RW x= pte 0xffffffff81973000-0xffffffff81975000 8K USR RW x= pte 0xffffffff81975000-0xffffffff81976000 4K USR RW x= pte 0xffffffff81976000-0xffffffff81977000 4K USR RW x= pte 0xffffffff81977000-0xffffffff8197b000 16K USR RW x= pte 0xffffffff8197b000-0xffffffff819b9000 248K USR RW x= pte 0xffffffff819b9000-0xffffffff819c0000 28K USR RW x= pte 0xffffffff819c0000-0xffffffff819df000 124K USR RW x= pte 0xffffffff819df000-0xffffffff819e8000 36K USR RW x= pte 0xffffffff819e8000-0xffffffff819f1000 36K USR RW x= pte 0xffffffff819f1000-0xffffffff819f2000 4K USR RW x= pte 0xffffffff819f2000-0xffffffff819f3000 4K USR RW x= pte 0xffffffff819f3000-0xffffffff819f5000 8K USR RW x= pte 0xffffffff819f5000-0xffffffff819f8000 12K USR RW x= pte 0xffffffff819f8000-0xffffffff81a0a000 72K USR RW x= pte 0xffffffff81a0a000-0xffffffff81a0f000 20K USR RW x= pte 0xffffffff81a0f000-0xffffffff81a1c000 52K USR RW x= pte 0xffffffff81a1c000-0xffffffff81a1d000 4K USR RW x= pte 0xffffffff81a1d000-0xffffffff81aa4000 540K USR RW x= pte 0xffffffff81aa4000-0xffffffff81aa8000 16K USR ro x= pte 0xffffffff81aa8000-0xffffffff81b28000 512K USR RW x= pte 0xffffffff81b28000-0xffffffff81c00000 864K USR RW x= pte 0xffffffff81c00000-0xffffffff8fc00000 224M = pmd 0xffffffff8fc00000-0xffffffff8fc93000 588K USR RW N= X pte 0xffffffff8fc93000-0xffffffff9f694000 256004K USR RW x= pte 0xffffffff9f694000-0xffffffff9f696000 8K USR RW x= pte 0xffffffff9f696000-0xffffffff9f797000 1028K USR ro x= pte 0xffffffff9f797000-0xffffffff9fc00000 4516K USR RW x= pte 0xffffffff9fc00000-0xffffffffa0000000 4M = pmd ---[ Modules ]--- 0xffffffffa0000000-0xffffffffa0001000 4K USR ro x= pte 0xffffffffa0001000-0xffffffffa0002000 4K USR ro N= X pte 0xffffffffa0002000-0xffffffffa0004000 8K USR RW N= X pte 0xffffffffa0004000-0xffffffffa0008000 16K = pte 0xffffffffa0008000-0xffffffffa0009000 4K USR ro x= pte 0xffffffffa0009000-0xffffffffa000a000 4K USR ro N= X pte 0xffffffffa000a000-0xffffffffa000c000 8K USR RW N= X pte 0xffffffffa000c000-0xffffffffa0010000 16K = pte 0xffffffffa0010000-0xffffffffa0011000 4K USR ro x= pte 0xffffffffa0011000-0xffffffffa0012000 4K USR ro N= X pte 0xffffffffa0012000-0xffffffffa0014000 8K USR RW N= X pte 0xffffffffa0014000-0xffffffffa0018000 16K = pte 0xffffffffa0018000-0xffffffffa0019000 4K USR ro x= pte 0xffffffffa0019000-0xffffffffa001a000 4K USR ro N= X pte 0xffffffffa001a000-0xffffffffa001c000 8K USR RW N= X pte 0xffffffffa001c000-0xffffffffa001d000 4K = pte 0xffffffffa001d000-0xffffffffa001e000 4K USR ro x= pte 0xffffffffa001e000-0xffffffffa001f000 4K USR ro N= X pte 0xffffffffa001f000-0xffffffffa0021000 8K USR RW N= X pte 0xffffffffa0021000-0xffffffffa0022000 4K = pte 0xffffffffa0022000-0xffffffffa0023000 4K USR ro x= pte 0xffffffffa0023000-0xffffffffa0024000 4K USR ro N= X pte 0xffffffffa0024000-0xffffffffa0026000 8K USR RW N= X pte 0xffffffffa0026000-0xffffffffa0027000 4K = pte 0xffffffffa0027000-0xffffffffa0028000 4K USR ro x= pte 0xffffffffa0028000-0xffffffffa0029000 4K USR ro N= X pte 0xffffffffa0029000-0xffffffffa002b000 8K USR RW N= X pte 0xffffffffa002b000-0xffffffffa002c000 4K = pte 0xffffffffa002c000-0xffffffffa002e000 8K USR ro x= pte 0xffffffffa002e000-0xffffffffa002f000 4K USR ro N= X pte 0xffffffffa002f000-0xffffffffa0031000 8K USR RW N= X pte 0xffffffffa0031000-0xffffffffa0036000 20K = pte 0xffffffffa0036000-0xffffffffa003a000 16K USR ro x= pte 0xffffffffa003a000-0xffffffffa003b000 4K USR ro N= X pte 0xffffffffa003b000-0xffffffffa003d000 8K USR RW N= X pte 0xffffffffa003d000-0xffffffffa0042000 20K = pte 0xffffffffa0042000-0xffffffffa0045000 12K USR ro x= pte 0xffffffffa0045000-0xffffffffa0046000 4K USR ro N= X pte 0xffffffffa0046000-0xffffffffa0048000 8K USR RW N= X pte 0xffffffffa0048000-0xffffffffa004d000 20K = pte 0xffffffffa004d000-0xffffffffa004e000 4K USR ro x= pte 0xffffffffa004e000-0xffffffffa004f000 4K USR ro N= X pte 0xffffffffa004f000-0xffffffffa0051000 8K USR RW N= X pte 0xffffffffa0051000-0xffffffffa0052000 4K = pte 0xffffffffa0052000-0xffffffffa0057000 20K USR ro x= pte 0xffffffffa0057000-0xffffffffa0059000 8K USR ro N= X pte 0xffffffffa0059000-0xffffffffa005b000 8K USR RW N= X pte 0xffffffffa005b000-0xffffffffa005c000 4K = pte 0xffffffffa005c000-0xffffffffa005d000 4K USR ro x= pte 0xffffffffa005d000-0xffffffffa005e000 4K USR ro N= X pte 0xffffffffa005e000-0xffffffffa0060000 8K USR RW N= X pte 0xffffffffa0060000-0xffffffffa0061000 4K = pte 0xffffffffa0061000-0xffffffffa006d000 48K USR ro x= pte 0xffffffffa006d000-0xffffffffa0070000 12K USR ro N= X pte 0xffffffffa0070000-0xffffffffa0073000 12K USR RW N= X pte 0xffffffffa0073000-0xffffffffa0074000 4K = pte 0xffffffffa0074000-0xffffffffa0075000 4K USR ro x= pte 0xffffffffa0075000-0xffffffffa0077000 8K USR ro N= X pte 0xffffffffa0077000-0xffffffffa0079000 8K USR RW N= X pte 0xffffffffa0079000-0xffffffffa007c000 12K = pte 0xffffffffa007c000-0xffffffffa007d000 4K USR ro x= pte 0xffffffffa007d000-0xffffffffa007e000 4K USR ro N= X pte 0xffffffffa007e000-0xffffffffa0080000 8K USR RW N= X pte 0xffffffffa0080000-0xffffffffa0081000 4K = pte 0xffffffffa0081000-0xffffffffa0082000 4K USR ro x= pte 0xffffffffa0082000-0xffffffffa0083000 4K USR ro N= X pte 0xffffffffa0083000-0xffffffffa0085000 8K USR RW N= X pte 0xffffffffa0085000-0xffffffffa0086000 4K = pte 0xffffffffa0086000-0xffffffffa008d000 28K USR ro x= pte 0xffffffffa008d000-0xffffffffa008e000 4K USR ro N= X pte 0xffffffffa008e000-0xffffffffa0092000 16K USR RW N= X pte 0xffffffffa0092000-0xffffffffa0097000 20K = pte 0xffffffffa0097000-0xffffffffa0126000 572K USR ro x= pte 0xffffffffa0126000-0xffffffffa014b000 148K USR ro N= X pte 0xffffffffa014b000-0xffffffffa0168000 116K USR RW N= X pte 0xffffffffa0168000-0xffffffffa0169000 4K = pte 0xffffffffa0169000-0xffffffffa016a000 4K USR ro x= pte 0xffffffffa016a000-0xffffffffa016b000 4K USR ro N= X pte 0xffffffffa016b000-0xffffffffa016d000 8K USR RW N= X pte 0xffffffffa016d000-0xffffffffa016e000 4K = pte 0xffffffffa016e000-0xffffffffa016f000 4K USR ro x= pte 0xffffffffa016f000-0xffffffffa0170000 4K USR ro N= X pte 0xffffffffa0170000-0xffffffffa0172000 8K USR RW N= X pte 0xffffffffa0172000-0xffffffffa0173000 4K = pte 0xffffffffa0173000-0xffffffffa0183000 64K USR ro x= pte 0xffffffffa0183000-0xffffffffa0192000 60K USR ro N= X pte 0xffffffffa0192000-0xffffffffa0198000 24K USR RW N= X pte 0xffffffffa0198000-0xffffffffa0199000 4K = pte 0xffffffffa0199000-0xffffffffa019f000 24K USR ro x= pte 0xffffffffa019f000-0xffffffffa01a1000 8K USR ro N= X pte 0xffffffffa01a1000-0xffffffffa01a3000 8K USR RW N= X pte 0xffffffffa01a3000-0xffffffffa01a8000 20K = pte 0xffffffffa01a8000-0xffffffffa01ad000 20K USR ro x= pte 0xffffffffa01ad000-0xffffffffa01af000 8K USR ro N= X pte 0xffffffffa01af000-0xffffffffa01b3000 16K USR RW N= X pte 0xffffffffa01b3000-0xffffffffa01b4000 4K = pte 0xffffffffa01b4000-0xffffffffa01b6000 8K USR ro x= pte 0xffffffffa01b6000-0xffffffffa01b7000 4K USR ro N= X pte 0xffffffffa01b7000-0xffffffffa01b9000 8K USR RW N= X pte 0xffffffffa01b9000-0xffffffffa01ba000 4K = pte 0xffffffffa01ba000-0xffffffffa01bc000 8K USR ro x= pte 0xffffffffa01bc000-0xffffffffa01bd000 4K USR ro N= X pte 0xffffffffa01bd000-0xffffffffa01bf000 8K USR RW N= X pte 0xffffffffa01bf000-0xffffffffa01c4000 20K = pte 0xffffffffa01c4000-0xffffffffa01c5000 4K USR ro x= pte 0xffffffffa01c5000-0xffffffffa01c6000 4K USR ro N= X pte 0xffffffffa01c6000-0xffffffffa01c8000 8K USR RW N= X pte 0xffffffffa01c8000-0xffffffffa01c9000 4K = pte 0xffffffffa01c9000-0xffffffffa01ca000 4K USR ro x= pte 0xffffffffa01ca000-0xffffffffa01cb000 4K USR ro N= X pte 0xffffffffa01cb000-0xffffffffa01cd000 8K USR RW N= X pte 0xffffffffa01cd000-0xffffffffa0200000 204K = pte 0xffffffffa0200000-0xffffffffc0000000 510M = pmd 0xffffffffc0000000-0xffffffffc009b000 620K USR RW x= pte 0xffffffffc009b000-0xffffffffc00a0000 20K USR RW x= pte 0xffffffffc00a0000-0xffffffffc07fb000 7532K USR RW x= pte 0xffffffffc07fb000-0xffffffffc0efc000 7172K USR ro x= pte 0xffffffffc0efc000-0xffffffffc1000000 1040K USR RW x= pte 0xffffffffc1000000-0xffffffffc1002000 8K USR ro x= pte 0xffffffffc1002000-0xffffffffc1013000 68K USR ro x= pte 0xffffffffc1013000-0xffffffffc1015000 8K USR ro x= pte 0xffffffffc1015000-0xffffffffc1017000 8K USR ro x= pte 0xffffffffc1017000-0xffffffffc1019000 8K USR ro x= pte 0xffffffffc1019000-0xffffffffc101a000 4K USR ro x= pte 0xffffffffc101a000-0xffffffffc101b000 4K USR ro x= pte 0xffffffffc101b000-0xffffffffc101f000 16K USR ro x= pte 0xffffffffc101f000-0xffffffffc1028000 36K USR ro x= pte 0xffffffffc1028000-0xffffffffc102a000 8K USR ro x= pte 0xffffffffc102a000-0xffffffffc102c000 8K USR ro x= pte 0xffffffffc102c000-0xffffffffc103c000 64K USR ro x= pte 0xffffffffc103c000-0xffffffffc103d000 4K USR ro x= pte 0xffffffffc103d000-0xffffffffc1051000 80K USR ro x= pte 0xffffffffc1051000-0xffffffffc1052000 4K USR ro x= pte 0xffffffffc1052000-0xffffffffc1057000 20K USR ro x= pte 0xffffffffc1057000-0xffffffffc1058000 4K USR ro x= pte 0xffffffffc1058000-0xffffffffc1061000 36K USR ro x= pte 0xffffffffc1061000-0xffffffffc1063000 8K USR ro x= pte 0xffffffffc1063000-0xffffffffc106b000 32K USR ro x= pte 0xffffffffc106b000-0xffffffffc106c000 4K USR ro x= pte 0xffffffffc106c000-0xffffffffc1078000 48K USR ro x= pte 0xffffffffc1078000-0xffffffffc107a000 8K USR ro x= pte 0xffffffffc107a000-0xffffffffc1083000 36K USR ro x= pte 0xffffffffc1083000-0xffffffffc1084000 4K USR ro x= pte 0xffffffffc1084000-0xffffffffc108f000 44K USR ro x= pte 0xffffffffc108f000-0xffffffffc1090000 4K USR ro x= pte 0xffffffffc1090000-0xffffffffc1094000 16K USR ro x= pte 0xffffffffc1094000-0xffffffffc1097000 12K USR ro x= pte 0xffffffffc1097000-0xffffffffc10a0000 36K USR ro x= pte 0xffffffffc10a0000-0xffffffffc10a2000 8K USR ro x= pte 0xffffffffc10a2000-0xffffffffc10a7000 20K USR ro x= pte 0xffffffffc10a7000-0xffffffffc10a8000 4K USR ro x= pte 0xffffffffc10a8000-0xffffffffc10aa000 8K USR ro x= pte 0xffffffffc10aa000-0xffffffffc10af000 20K USR ro x= pte 0xffffffffc10af000-0xffffffffc10b4000 20K USR ro x= pte 0xffffffffc10b4000-0xffffffffc10b6000 8K USR ro x= pte 0xffffffffc10b6000-0xffffffffc10c0000 40K USR ro x= pte 0xffffffffc10c0000-0xffffffffc10c4000 16K USR ro x= pte 0xffffffffc10c4000-0xffffffffc10c6000 8K USR ro x= pte 0xffffffffc10c6000-0xffffffffc10ca000 16K USR ro x= pte 0xffffffffc10ca000-0xffffffffc10cc000 8K USR ro x= pte 0xffffffffc10cc000-0xffffffffc10cd000 4K USR ro x= pte 0xffffffffc10cd000-0xffffffffc10d5000 32K USR ro x= pte 0xffffffffc10d5000-0xffffffffc10d9000 16K USR ro x= pte 0xffffffffc10d9000-0xffffffffc10da000 4K USR ro x= pte 0xffffffffc10da000-0xffffffffc10db000 4K USR ro x= pte 0xffffffffc10db000-0xffffffffc10dc000 4K USR ro x= pte 0xffffffffc10dc000-0xffffffffc10dd000 4K USR ro x= pte 0xffffffffc10dd000-0xffffffffc10e2000 20K USR ro x= pte 0xffffffffc10e2000-0xffffffffc10e3000 4K USR ro x= pte 0xffffffffc10e3000-0xffffffffc10f8000 84K USR ro x= pte 0xffffffffc10f8000-0xffffffffc10fb000 12K USR ro x= pte 0xffffffffc10fb000-0xffffffffc1101000 24K USR ro x= pte 0xffffffffc1101000-0xffffffffc1102000 4K USR ro x= pte 0xffffffffc1102000-0xffffffffc1106000 16K USR ro x= pte 0xffffffffc1106000-0xffffffffc1107000 4K USR ro x= pte 0xffffffffc1107000-0xffffffffc1108000 4K USR ro x= pte 0xffffffffc1108000-0xffffffffc1109000 4K USR ro x= pte 0xffffffffc1109000-0xffffffffc1113000 40K USR ro x= pte 0xffffffffc1113000-0xffffffffc1114000 4K USR ro x= pte 0xffffffffc1114000-0xffffffffc1117000 12K USR ro x= pte 0xffffffffc1117000-0xffffffffc1118000 4K USR ro x= pte 0xffffffffc1118000-0xffffffffc1122000 40K USR ro x= pte 0xffffffffc1122000-0xffffffffc1124000 8K USR ro x= pte 0xffffffffc1124000-0xffffffffc1143000 124K USR ro x= pte 0xffffffffc1143000-0xffffffffc1145000 8K USR ro x= pte 0xffffffffc1145000-0xffffffffc1166000 132K USR ro x= pte 0xffffffffc1166000-0xffffffffc1168000 8K USR ro x= pte 0xffffffffc1168000-0xffffffffc116d000 20K USR ro x= pte 0xffffffffc116d000-0xffffffffc116e000 4K USR ro x= pte 0xffffffffc116e000-0xffffffffc116f000 4K USR ro x= pte 0xffffffffc116f000-0xffffffffc1170000 4K USR ro x= pte 0xffffffffc1170000-0xffffffffc1174000 16K USR ro x= pte 0xffffffffc1174000-0xffffffffc1177000 12K USR ro x= pte 0xffffffffc1177000-0xffffffffc117a000 12K USR ro x= pte 0xffffffffc117a000-0xffffffffc117e000 16K USR ro x= pte 0xffffffffc117e000-0xffffffffc118d000 60K USR ro x= pte 0xffffffffc118d000-0xffffffffc118e000 4K USR ro x= pte 0xffffffffc118e000-0xffffffffc1190000 8K USR ro x= pte 0xffffffffc1190000-0xffffffffc1191000 4K USR ro x= pte 0xffffffffc1191000-0xffffffffc1192000 4K USR ro x= pte 0xffffffffc1192000-0xffffffffc1193000 4K USR ro x= pte 0xffffffffc1193000-0xffffffffc1194000 4K USR ro x= pte 0xffffffffc1194000-0xffffffffc1197000 12K USR ro x= pte 0xffffffffc1197000-0xffffffffc1198000 4K USR ro x= pte 0xffffffffc1198000-0xffffffffc1199000 4K USR ro x= pte 0xffffffffc1199000-0xffffffffc11a0000 28K USR ro x= pte 0xffffffffc11a0000-0xffffffffc11a1000 4K USR ro x= pte 0xffffffffc11a1000-0xffffffffc11ab000 40K USR ro x= pte 0xffffffffc11ab000-0xffffffffc11ac000 4K USR ro x= pte 0xffffffffc11ac000-0xffffffffc11af000 12K USR ro x= pte 0xffffffffc11af000-0xffffffffc11b1000 8K USR ro x= pte 0xffffffffc11b1000-0xffffffffc11b4000 12K USR ro x= pte 0xffffffffc11b4000-0xffffffffc11b5000 4K USR ro x= pte 0xffffffffc11b5000-0xffffffffc11b9000 16K USR ro x= pte 0xffffffffc11b9000-0xffffffffc11bb000 8K USR ro x= pte 0xffffffffc11bb000-0xffffffffc11bd000 8K USR ro x= pte 0xffffffffc11bd000-0xffffffffc11be000 4K USR ro x= pte 0xffffffffc11be000-0xffffffffc11c2000 16K USR ro x= pte 0xffffffffc11c2000-0xffffffffc11c6000 16K USR ro x= pte 0xffffffffc11c6000-0xffffffffc11c7000 4K USR ro x= pte 0xffffffffc11c7000-0xffffffffc11c8000 4K USR ro x= pte 0xffffffffc11c8000-0xffffffffc11c9000 4K USR ro x= pte 0xffffffffc11c9000-0xffffffffc11ca000 4K USR ro x= pte 0xffffffffc11ca000-0xffffffffc11cf000 20K USR ro x= pte 0xffffffffc11cf000-0xffffffffc11d0000 4K USR ro x= pte 0xffffffffc11d0000-0xffffffffc11d3000 12K USR ro x= pte 0xffffffffc11d3000-0xffffffffc11d5000 8K USR ro x= pte 0xffffffffc11d5000-0xffffffffc11d6000 4K USR ro x= pte 0xffffffffc11d6000-0xffffffffc11d8000 8K USR ro x= pte 0xffffffffc11d8000-0xffffffffc11d9000 4K USR ro x= pte 0xffffffffc11d9000-0xffffffffc11da000 4K USR ro x= pte 0xffffffffc11da000-0xffffffffc11e0000 24K USR ro x= pte 0xffffffffc11e0000-0xffffffffc11e3000 12K USR ro x= pte 0xffffffffc11e3000-0xffffffffc11e9000 24K USR ro x= pte 0xffffffffc11e9000-0xffffffffc11ea000 4K USR ro x= pte 0xffffffffc11ea000-0xffffffffc11eb000 4K USR ro x= pte 0xffffffffc11eb000-0xffffffffc11f1000 24K USR ro x= pte 0xffffffffc11f1000-0xffffffffc11f7000 24K USR ro x= pte 0xffffffffc11f7000-0xffffffffc11f8000 4K USR ro x= pte 0xffffffffc11f8000-0xffffffffc11fa000 8K USR ro x= pte 0xffffffffc11fa000-0xffffffffc11fb000 4K USR ro x= pte 0xffffffffc11fb000-0xffffffffc11fd000 8K USR ro x= pte 0xffffffffc11fd000-0xffffffffc11fe000 4K USR ro x= pte 0xffffffffc11fe000-0xffffffffc1200000 8K USR ro x= pte 0xffffffffc1200000-0xffffffffc1201000 4K USR ro x= pte 0xffffffffc1201000-0xffffffffc1203000 8K USR ro x= pte 0xffffffffc1203000-0xffffffffc1207000 16K USR ro x= pte 0xffffffffc1207000-0xffffffffc1209000 8K USR ro x= pte 0xffffffffc1209000-0xffffffffc120a000 4K USR ro x= pte 0xffffffffc120a000-0xffffffffc120b000 4K USR ro x= pte 0xffffffffc120b000-0xffffffffc120c000 4K USR ro x= pte 0xffffffffc120c000-0xffffffffc120e000 8K USR ro x= pte 0xffffffffc120e000-0xffffffffc1223000 84K USR ro x= pte 0xffffffffc1223000-0xffffffffc1228000 20K USR ro x= pte 0xffffffffc1228000-0xffffffffc1229000 4K USR ro x= pte 0xffffffffc1229000-0xffffffffc123b000 72K USR ro x= pte 0xffffffffc123b000-0xffffffffc123d000 8K USR ro x= pte 0xffffffffc123d000-0xffffffffc123e000 4K USR ro x= pte 0xffffffffc123e000-0xffffffffc123f000 4K USR ro x= pte 0xffffffffc123f000-0xffffffffc1242000 12K USR ro x= pte 0xffffffffc1242000-0xffffffffc1244000 8K USR ro x= pte 0xffffffffc1244000-0xffffffffc1245000 4K USR ro x= pte 0xffffffffc1245000-0xffffffffc1247000 8K USR ro x= pte 0xffffffffc1247000-0xffffffffc1248000 4K USR ro x= pte 0xffffffffc1248000-0xffffffffc1252000 40K USR ro x= pte 0xffffffffc1252000-0xffffffffc1253000 4K USR ro x= pte 0xffffffffc1253000-0xffffffffc1254000 4K USR ro x= pte 0xffffffffc1254000-0xffffffffc1255000 4K USR ro x= pte 0xffffffffc1255000-0xffffffffc1258000 12K USR ro x= pte 0xffffffffc1258000-0xffffffffc1259000 4K USR ro x= pte 0xffffffffc1259000-0xffffffffc1268000 60K USR ro x= pte 0xffffffffc1268000-0xffffffffc126e000 24K USR ro x= pte 0xffffffffc126e000-0xffffffffc126f000 4K USR ro x= pte 0xffffffffc126f000-0xffffffffc1272000 12K USR ro x= pte 0xffffffffc1272000-0xffffffffc1273000 4K USR ro x= pte 0xffffffffc1273000-0xffffffffc1274000 4K USR ro x= pte 0xffffffffc1274000-0xffffffffc127a000 24K USR ro x= pte 0xffffffffc127a000-0xffffffffc127c000 8K USR ro x= pte 0xffffffffc127c000-0xffffffffc127d000 4K USR ro x= pte 0xffffffffc127d000-0xffffffffc1285000 32K USR ro x= pte 0xffffffffc1285000-0xffffffffc1286000 4K USR ro x= pte 0xffffffffc1286000-0xffffffffc1287000 4K USR ro x= pte 0xffffffffc1287000-0xffffffffc1288000 4K USR ro x= pte 0xffffffffc1288000-0xffffffffc1289000 4K USR ro x= pte 0xffffffffc1289000-0xffffffffc128d000 16K USR ro x= pte 0xffffffffc128d000-0xffffffffc128f000 8K USR ro x= pte 0xffffffffc128f000-0xffffffffc1291000 8K USR ro x= pte 0xffffffffc1291000-0xffffffffc1292000 4K USR ro x= pte 0xffffffffc1292000-0xffffffffc129f000 52K USR ro x= pte 0xffffffffc129f000-0xffffffffc12a0000 4K USR ro x= pte 0xffffffffc12a0000-0xffffffffc12a1000 4K USR ro x= pte 0xffffffffc12a1000-0xffffffffc12a3000 8K USR ro x= pte 0xffffffffc12a3000-0xffffffffc12a5000 8K USR ro x= pte 0xffffffffc12a5000-0xffffffffc12a6000 4K USR ro x= pte 0xffffffffc12a6000-0xffffffffc12a9000 12K USR ro x= pte 0xffffffffc12a9000-0xffffffffc12ab000 8K USR ro x= pte 0xffffffffc12ab000-0xffffffffc12c3000 96K USR ro x= pte 0xffffffffc12c3000-0xffffffffc12c6000 12K USR ro x= pte 0xffffffffc12c6000-0xffffffffc12cc000 24K USR ro x= pte 0xffffffffc12cc000-0xffffffffc12cf000 12K USR ro x= pte 0xffffffffc12cf000-0xffffffffc12d1000 8K USR ro x= pte 0xffffffffc12d1000-0xffffffffc12d2000 4K USR ro x= pte 0xffffffffc12d2000-0xffffffffc12d3000 4K USR ro x= pte 0xffffffffc12d3000-0xffffffffc12d7000 16K USR ro x= pte 0xffffffffc12d7000-0xffffffffc12d8000 4K USR ro x= pte 0xffffffffc12d8000-0xffffffffc12da000 8K USR ro x= pte 0xffffffffc12da000-0xffffffffc12dc000 8K USR ro x= pte 0xffffffffc12dc000-0xffffffffc12e1000 20K USR ro x= pte 0xffffffffc12e1000-0xffffffffc12e3000 8K USR ro x= pte 0xffffffffc12e3000-0xffffffffc12e4000 4K USR ro x= pte 0xffffffffc12e4000-0xffffffffc12e5000 4K USR ro x= pte 0xffffffffc12e5000-0xffffffffc12e6000 4K USR ro x= pte 0xffffffffc12e6000-0xffffffffc12e7000 4K USR ro x= pte 0xffffffffc12e7000-0xffffffffc12ed000 24K USR ro x= pte 0xffffffffc12ed000-0xffffffffc12ee000 4K USR ro x= pte 0xffffffffc12ee000-0xffffffffc12f9000 44K USR ro x= pte 0xffffffffc12f9000-0xffffffffc12fa000 4K USR ro x= pte 0xffffffffc12fa000-0xffffffffc12fe000 16K USR ro x= pte 0xffffffffc12fe000-0xffffffffc1300000 8K USR ro x= pte 0xffffffffc1300000-0xffffffffc1302000 8K USR ro x= pte 0xffffffffc1302000-0xffffffffc130d000 44K USR ro x= pte 0xffffffffc130d000-0xffffffffc130e000 4K USR ro x= pte 0xffffffffc130e000-0xffffffffc130f000 4K USR ro x= pte 0xffffffffc130f000-0xffffffffc1312000 12K USR ro x= pte 0xffffffffc1312000-0xffffffffc1314000 8K USR ro x= pte 0xffffffffc1314000-0xffffffffc1318000 16K USR ro x= pte 0xffffffffc1318000-0xffffffffc131b000 12K USR ro x= pte 0xffffffffc131b000-0xffffffffc131c000 4K USR ro x= pte 0xffffffffc131c000-0xffffffffc1324000 32K USR ro x= pte 0xffffffffc1324000-0xffffffffc1329000 20K USR ro x= pte 0xffffffffc1329000-0xffffffffc132d000 16K USR ro x= pte 0xffffffffc132d000-0xffffffffc132e000 4K USR ro x= pte 0xffffffffc132e000-0xffffffffc132f000 4K USR ro x= pte 0xffffffffc132f000-0xffffffffc1332000 12K USR ro x= pte 0xffffffffc1332000-0xffffffffc1333000 4K USR ro x= pte 0xffffffffc1333000-0xffffffffc1334000 4K USR ro x= pte 0xffffffffc1334000-0xffffffffc1335000 4K USR ro x= pte 0xffffffffc1335000-0xffffffffc1337000 8K USR ro x= pte 0xffffffffc1337000-0xffffffffc133b000 16K USR ro x= pte 0xffffffffc133b000-0xffffffffc133c000 4K USR ro x= pte 0xffffffffc133c000-0xffffffffc1340000 16K USR ro x= pte 0xffffffffc1340000-0xffffffffc1342000 8K USR ro x= pte 0xffffffffc1342000-0xffffffffc1343000 4K USR ro x= pte 0xffffffffc1343000-0xffffffffc1348000 20K USR ro x= pte 0xffffffffc1348000-0xffffffffc134c000 16K USR ro x= pte 0xffffffffc134c000-0xffffffffc1350000 16K USR ro x= pte 0xffffffffc1350000-0xffffffffc1351000 4K USR ro x= pte 0xffffffffc1351000-0xffffffffc1353000 8K USR ro x= pte 0xffffffffc1353000-0xffffffffc1358000 20K USR ro x= pte 0xffffffffc1358000-0xffffffffc135e000 24K USR ro x= pte 0xffffffffc135e000-0xffffffffc135f000 4K USR ro x= pte 0xffffffffc135f000-0xffffffffc1361000 8K USR ro x= pte 0xffffffffc1361000-0xffffffffc1366000 20K USR ro x= pte 0xffffffffc1366000-0xffffffffc1367000 4K USR ro x= pte 0xffffffffc1367000-0xffffffffc1368000 4K USR ro x= pte 0xffffffffc1368000-0xffffffffc136a000 8K USR ro x= pte 0xffffffffc136a000-0xffffffffc1374000 40K USR ro x= pte 0xffffffffc1374000-0xffffffffc1376000 8K USR ro x= pte 0xffffffffc1376000-0xffffffffc1379000 12K USR ro x= pte 0xffffffffc1379000-0xffffffffc137f000 24K USR ro x= pte 0xffffffffc137f000-0xffffffffc1380000 4K USR ro x= pte 0xffffffffc1380000-0xffffffffc1383000 12K USR ro x= pte 0xffffffffc1383000-0xffffffffc1384000 4K USR ro x= pte 0xffffffffc1384000-0xffffffffc1387000 12K USR ro x= pte 0xffffffffc1387000-0xffffffffc1389000 8K USR ro x= pte 0xffffffffc1389000-0xffffffffc138c000 12K USR ro x= pte 0xffffffffc138c000-0xffffffffc1393000 28K USR ro x= pte 0xffffffffc1393000-0xffffffffc1395000 8K USR ro x= pte 0xffffffffc1395000-0xffffffffc1398000 12K USR ro x= pte 0xffffffffc1398000-0xffffffffc139a000 8K USR ro x= pte 0xffffffffc139a000-0xffffffffc139c000 8K USR ro x= pte 0xffffffffc139c000-0xffffffffc139d000 4K USR ro x= pte 0xffffffffc139d000-0xffffffffc13a3000 24K USR ro x= pte 0xffffffffc13a3000-0xffffffffc13a4000 4K USR ro x= pte 0xffffffffc13a4000-0xffffffffc13a5000 4K USR ro x= pte 0xffffffffc13a5000-0xffffffffc13a6000 4K USR ro x= pte 0xffffffffc13a6000-0xffffffffc13a9000 12K USR ro x= pte 0xffffffffc13a9000-0xffffffffc13ab000 8K USR ro x= pte 0xffffffffc13ab000-0xffffffffc13ac000 4K USR ro x= pte 0xffffffffc13ac000-0xffffffffc13ae000 8K USR ro x= pte 0xffffffffc13ae000-0xffffffffc13b1000 12K USR ro x= pte 0xffffffffc13b1000-0xffffffffc13b3000 8K USR ro x= pte 0xffffffffc13b3000-0xffffffffc13b5000 8K USR ro x= pte 0xffffffffc13b5000-0xffffffffc13b9000 16K USR ro x= pte 0xffffffffc13b9000-0xffffffffc13ba000 4K USR ro x= pte 0xffffffffc13ba000-0xffffffffc13bf000 20K USR ro x= pte 0xffffffffc13bf000-0xffffffffc13ce000 60K USR ro x= pte 0xffffffffc13ce000-0xffffffffc13cf000 4K USR ro x= pte 0xffffffffc13cf000-0xffffffffc13d0000 4K USR ro x= pte 0xffffffffc13d0000-0xffffffffc13d2000 8K USR ro x= pte 0xffffffffc13d2000-0xffffffffc13d3000 4K USR ro x= pte 0xffffffffc13d3000-0xffffffffc13db000 32K USR ro x= pte 0xffffffffc13db000-0xffffffffc13dc000 4K USR ro x= pte 0xffffffffc13dc000-0xffffffffc13dd000 4K USR ro x= pte 0xffffffffc13dd000-0xffffffffc13de000 4K USR ro x= pte 0xffffffffc13de000-0xffffffffc13e0000 8K USR ro x= pte 0xffffffffc13e0000-0xffffffffc13e3000 12K USR ro x= pte 0xffffffffc13e3000-0xffffffffc13e5000 8K USR ro x= pte 0xffffffffc13e5000-0xffffffffc13e8000 12K USR ro x= pte 0xffffffffc13e8000-0xffffffffc13ea000 8K USR ro x= pte 0xffffffffc13ea000-0xffffffffc13ec000 8K USR ro x= pte 0xffffffffc13ec000-0xffffffffc13ed000 4K USR ro x= pte 0xffffffffc13ed000-0xffffffffc13ef000 8K USR ro x= pte 0xffffffffc13ef000-0xffffffffc13f3000 16K USR ro x= pte 0xffffffffc13f3000-0xffffffffc13f4000 4K USR ro x= pte 0xffffffffc13f4000-0xffffffffc13f6000 8K USR ro x= pte 0xffffffffc13f6000-0xffffffffc13f7000 4K USR ro x= pte 0xffffffffc13f7000-0xffffffffc13fa000 12K USR ro x= pte 0xffffffffc13fa000-0xffffffffc13fb000 4K USR ro x= pte 0xffffffffc13fb000-0xffffffffc13fd000 8K USR ro x= pte 0xffffffffc13fd000-0xffffffffc13fe000 4K USR ro x= pte 0xffffffffc13fe000-0xffffffffc1403000 20K USR ro x= pte 0xffffffffc1403000-0xffffffffc1404000 4K USR ro x= pte 0xffffffffc1404000-0xffffffffc1406000 8K USR ro x= pte 0xffffffffc1406000-0xffffffffc1408000 8K USR ro x= pte 0xffffffffc1408000-0xffffffffc1411000 36K USR ro x= pte 0xffffffffc1411000-0xffffffffc1412000 4K USR ro x= pte 0xffffffffc1412000-0xffffffffc1413000 4K USR ro x= pte 0xffffffffc1413000-0xffffffffc1415000 8K USR ro x= pte 0xffffffffc1415000-0xffffffffc1416000 4K USR ro x= pte 0xffffffffc1416000-0xffffffffc1419000 12K USR ro x= pte 0xffffffffc1419000-0xffffffffc141e000 20K USR ro x= pte 0xffffffffc141e000-0xffffffffc1425000 28K USR ro x= pte 0xffffffffc1425000-0xffffffffc1426000 4K USR ro x= pte 0xffffffffc1426000-0xffffffffc1428000 8K USR ro x= pte 0xffffffffc1428000-0xffffffffc142f000 28K USR ro x= pte 0xffffffffc142f000-0xffffffffc1430000 4K USR ro x= pte 0xffffffffc1430000-0xffffffffc1437000 28K USR ro x= pte 0xffffffffc1437000-0xffffffffc1438000 4K USR ro x= pte 0xffffffffc1438000-0xffffffffc1439000 4K USR ro x= pte 0xffffffffc1439000-0xffffffffc143d000 16K USR ro x= pte 0xffffffffc143d000-0xffffffffc143e000 4K USR ro x= pte 0xffffffffc143e000-0xffffffffc143f000 4K USR ro x= pte 0xffffffffc143f000-0xffffffffc1440000 4K USR ro x= pte 0xffffffffc1440000-0xffffffffc1443000 12K USR ro x= pte 0xffffffffc1443000-0xffffffffc1445000 8K USR ro x= pte 0xffffffffc1445000-0xffffffffc1446000 4K USR ro x= pte 0xffffffffc1446000-0xffffffffc1448000 8K USR ro x= pte 0xffffffffc1448000-0xffffffffc144d000 20K USR ro x= pte 0xffffffffc144d000-0xffffffffc144f000 8K USR ro x= pte 0xffffffffc144f000-0xffffffffc1451000 8K USR ro x= pte 0xffffffffc1451000-0xffffffffc1452000 4K USR ro x= pte 0xffffffffc1452000-0xffffffffc1458000 24K USR ro x= pte 0xffffffffc1458000-0xffffffffc1459000 4K USR ro x= pte 0xffffffffc1459000-0xffffffffc145a000 4K USR ro x= pte 0xffffffffc145a000-0xffffffffc145c000 8K USR ro x= pte 0xffffffffc145c000-0xffffffffc145d000 4K USR ro x= pte 0xffffffffc145d000-0xffffffffc1462000 20K USR ro x= pte 0xffffffffc1462000-0xffffffffc1463000 4K USR ro x= pte 0xffffffffc1463000-0xffffffffc1464000 4K USR ro x= pte 0xffffffffc1464000-0xffffffffc1465000 4K USR ro x= pte 0xffffffffc1465000-0xffffffffc1467000 8K USR ro x= pte 0xffffffffc1467000-0xffffffffc1468000 4K USR ro x= pte 0xffffffffc1468000-0xffffffffc1469000 4K USR ro x= pte 0xffffffffc1469000-0xffffffffc146a000 4K USR ro x= pte 0xffffffffc146a000-0xffffffffc146b000 4K USR ro x= pte 0xffffffffc146b000-0xffffffffc1470000 20K USR ro x= pte 0xffffffffc1470000-0xffffffffc1471000 4K USR ro x= pte 0xffffffffc1471000-0xffffffffc1473000 8K USR ro x= pte 0xffffffffc1473000-0xffffffffc1477000 16K USR ro x= pte 0xffffffffc1477000-0xffffffffc147a000 12K USR ro x= pte 0xffffffffc147a000-0xffffffffc147b000 4K USR ro x= pte 0xffffffffc147b000-0xffffffffc147c000 4K USR ro x= pte 0xffffffffc147c000-0xffffffffc147d000 4K USR ro x= pte 0xffffffffc147d000-0xffffffffc1482000 20K USR ro x= pte 0xffffffffc1482000-0xffffffffc1484000 8K USR ro x= pte 0xffffffffc1484000-0xffffffffc1485000 4K USR ro x= pte 0xffffffffc1485000-0xffffffffc1486000 4K USR ro x= pte 0xffffffffc1486000-0xffffffffc1489000 12K USR ro x= pte 0xffffffffc1489000-0xffffffffc148a000 4K USR ro x= pte 0xffffffffc148a000-0xffffffffc148b000 4K USR ro x= pte 0xffffffffc148b000-0xffffffffc148c000 4K USR ro x= pte 0xffffffffc148c000-0xffffffffc1499000 52K USR ro x= pte 0xffffffffc1499000-0xffffffffc149a000 4K USR ro x= pte 0xffffffffc149a000-0xffffffffc14a2000 32K USR ro x= pte 0xffffffffc14a2000-0xffffffffc14a5000 12K USR ro x= pte 0xffffffffc14a5000-0xffffffffc14a8000 12K USR ro x= pte 0xffffffffc14a8000-0xffffffffc14b0000 32K USR ro x= pte 0xffffffffc14b0000-0xffffffffc14b1000 4K USR ro x= pte 0xffffffffc14b1000-0xffffffffc14b2000 4K USR ro x= pte 0xffffffffc14b2000-0xffffffffc14c2000 64K USR ro x= pte 0xffffffffc14c2000-0xffffffffc14c3000 4K USR ro x= pte 0xffffffffc14c3000-0xffffffffc14c5000 8K USR ro x= pte 0xffffffffc14c5000-0xffffffffc14cb000 24K USR ro x= pte 0xffffffffc14cb000-0xffffffffc14cc000 4K USR ro x= pte 0xffffffffc14cc000-0xffffffffc14cf000 12K USR ro x= pte 0xffffffffc14cf000-0xffffffffc14d0000 4K USR ro x= pte 0xffffffffc14d0000-0xffffffffc14d1000 4K USR ro x= pte 0xffffffffc14d1000-0xffffffffc14d3000 8K USR ro x= pte 0xffffffffc14d3000-0xffffffffc14d4000 4K USR ro x= pte 0xffffffffc14d4000-0xffffffffc14d6000 8K USR ro x= pte 0xffffffffc14d6000-0xffffffffc14d7000 4K USR ro x= pte 0xffffffffc14d7000-0xffffffffc14db000 16K USR ro x= pte 0xffffffffc14db000-0xffffffffc14dc000 4K USR ro x= pte 0xffffffffc14dc000-0xffffffffc14de000 8K USR ro x= pte 0xffffffffc14de000-0xffffffffc14df000 4K USR ro x= pte 0xffffffffc14df000-0xffffffffc14e3000 16K USR ro x= pte 0xffffffffc14e3000-0xffffffffc14e7000 16K USR ro x= pte 0xffffffffc14e7000-0xffffffffc14e8000 4K USR ro x= pte 0xffffffffc14e8000-0xffffffffc14e9000 4K USR ro x= pte 0xffffffffc14e9000-0xffffffffc14f1000 32K USR ro x= pte 0xffffffffc14f1000-0xffffffffc14f2000 4K USR ro x= pte 0xffffffffc14f2000-0xffffffffc14f6000 16K USR ro x= pte 0xffffffffc14f6000-0xffffffffc14f7000 4K USR ro x= pte 0xffffffffc14f7000-0xffffffffc14f8000 4K USR ro x= pte 0xffffffffc14f8000-0xffffffffc14f9000 4K USR ro x= pte 0xffffffffc14f9000-0xffffffffc14fe000 20K USR ro x= pte 0xffffffffc14fe000-0xffffffffc1503000 20K USR ro x= pte 0xffffffffc1503000-0xffffffffc1508000 20K USR ro x= pte 0xffffffffc1508000-0xffffffffc150d000 20K USR ro x= pte 0xffffffffc150d000-0xffffffffc1511000 16K USR ro x= pte 0xffffffffc1511000-0xffffffffc1513000 8K USR ro x= pte 0xffffffffc1513000-0xffffffffc1514000 4K USR ro x= pte 0xffffffffc1514000-0xffffffffc1515000 4K USR ro x= pte 0xffffffffc1515000-0xffffffffc1516000 4K USR ro x= pte 0xffffffffc1516000-0xffffffffc151b000 20K USR ro x= pte 0xffffffffc151b000-0xffffffffc1520000 20K USR ro x= pte 0xffffffffc1520000-0xffffffffc1521000 4K USR ro x= pte 0xffffffffc1521000-0xffffffffc1523000 8K USR ro x= pte 0xffffffffc1523000-0xffffffffc1525000 8K USR ro x= pte 0xffffffffc1525000-0xffffffffc1526000 4K USR ro x= pte 0xffffffffc1526000-0xffffffffc1529000 12K USR ro x= pte 0xffffffffc1529000-0xffffffffc152a000 4K USR ro x= pte 0xffffffffc152a000-0xffffffffc152b000 4K USR ro x= pte 0xffffffffc152b000-0xffffffffc152e000 12K USR ro x= pte 0xffffffffc152e000-0xffffffffc1533000 20K USR ro x= pte 0xffffffffc1533000-0xffffffffc1535000 8K USR ro x= pte 0xffffffffc1535000-0xffffffffc1537000 8K USR ro x= pte 0xffffffffc1537000-0xffffffffc1538000 4K USR ro x= pte 0xffffffffc1538000-0xffffffffc1539000 4K USR ro x= pte 0xffffffffc1539000-0xffffffffc153b000 8K USR ro x= pte 0xffffffffc153b000-0xffffffffc153d000 8K USR ro x= pte 0xffffffffc153d000-0xffffffffc1541000 16K USR ro x= pte 0xffffffffc1541000-0xffffffffc1542000 4K USR ro x= pte 0xffffffffc1542000-0xffffffffc1544000 8K USR ro x= pte 0xffffffffc1544000-0xffffffffc1545000 4K USR ro x= pte 0xffffffffc1545000-0xffffffffc1547000 8K USR ro x= pte 0xffffffffc1547000-0xffffffffc1551000 40K USR ro x= pte 0xffffffffc1551000-0xffffffffc1552000 4K USR ro x= pte 0xffffffffc1552000-0xffffffffc1554000 8K USR ro x= pte 0xffffffffc1554000-0xffffffffc1555000 4K USR ro x= pte 0xffffffffc1555000-0xffffffffc155d000 32K USR ro x= pte 0xffffffffc155d000-0xffffffffc155f000 8K USR ro x= pte 0xffffffffc155f000-0xffffffffc1563000 16K USR ro x= pte 0xffffffffc1563000-0xffffffffc1566000 12K USR ro x= pte 0xffffffffc1566000-0xffffffffc1567000 4K USR ro x= pte 0xffffffffc1567000-0xffffffffc1568000 4K USR ro x= pte 0xffffffffc1568000-0xffffffffc156a000 8K USR ro x= pte 0xffffffffc156a000-0xffffffffc156b000 4K USR ro x= pte 0xffffffffc156b000-0xffffffffc1572000 28K USR ro x= pte 0xffffffffc1572000-0xffffffffc1573000 4K USR ro x= pte 0xffffffffc1573000-0xffffffffc1576000 12K USR ro x= pte 0xffffffffc1576000-0xffffffffc1577000 4K USR ro x= pte 0xffffffffc1577000-0xffffffffc1578000 4K USR ro x= pte 0xffffffffc1578000-0xffffffffc1579000 4K USR ro x= pte 0xffffffffc1579000-0xffffffffc157a000 4K USR ro x= pte 0xffffffffc157a000-0xffffffffc157b000 4K USR ro x= pte 0xffffffffc157b000-0xffffffffc157d000 8K USR ro x= pte 0xffffffffc157d000-0xffffffffc157f000 8K USR ro x= pte 0xffffffffc157f000-0xffffffffc1582000 12K USR ro x= pte 0xffffffffc1582000-0xffffffffc1584000 8K USR ro x= pte 0xffffffffc1584000-0xffffffffc1586000 8K USR ro x= pte 0xffffffffc1586000-0xffffffffc1588000 8K USR ro x= pte 0xffffffffc1588000-0xffffffffc1589000 4K USR ro x= pte 0xffffffffc1589000-0xffffffffc158d000 16K USR ro x= pte 0xffffffffc158d000-0xffffffffc158f000 8K USR ro x= pte 0xffffffffc158f000-0xffffffffc1593000 16K USR ro x= pte 0xffffffffc1593000-0xffffffffc1594000 4K USR ro x= pte 0xffffffffc1594000-0xffffffffc1595000 4K USR ro x= pte 0xffffffffc1595000-0xffffffffc1596000 4K USR ro x= pte 0xffffffffc1596000-0xffffffffc1599000 12K USR ro x= pte 0xffffffffc1599000-0xffffffffc15ab000 72K USR ro x= pte 0xffffffffc15ab000-0xffffffffc15ac000 4K USR ro x= pte 0xffffffffc15ac000-0xffffffffc15b0000 16K USR ro x= pte 0xffffffffc15b0000-0xffffffffc15b1000 4K USR ro x= pte 0xffffffffc15b1000-0xffffffffc15b7000 24K USR ro x= pte 0xffffffffc15b7000-0xffffffffc1600000 292K USR RW N= X pte 0xffffffffc1600000-0xffffffffc179c000 1648K USR ro N= X pte 0xffffffffc179c000-0xffffffffc1800000 400K USR RW N= X pte 0xffffffffc1800000-0xffffffffc1802000 8K USR RW x= pte 0xffffffffc1802000-0xffffffffc1803000 4K USR RW x= pte 0xffffffffc1803000-0xffffffffc1805000 8K USR RW x= pte 0xffffffffc1805000-0xffffffffc180b000 24K USR RW x= pte 0xffffffffc180b000-0xffffffffc180f000 16K USR ro x= pte 0xffffffffc180f000-0xffffffffc1810000 4K USR RW x= pte 0xffffffffc1810000-0xffffffffc1812000 8K USR ro x= pte 0xffffffffc1812000-0xffffffffc1813000 4K USR RW x= pte 0xffffffffc1813000-0xffffffffc1815000 8K USR RW x= pte 0xffffffffc1815000-0xffffffffc1816000 4K USR RW x= pte 0xffffffffc1816000-0xffffffffc1818000 8K USR RW x= pte 0xffffffffc1818000-0xffffffffc181a000 8K USR RW x= pte 0xffffffffc181a000-0xffffffffc181d000 12K USR RW x= pte 0xffffffffc181d000-0xffffffffc181e000 4K USR RW x= pte 0xffffffffc181e000-0xffffffffc1832000 80K USR RW x= pte 0xffffffffc1832000-0xffffffffc1834000 8K USR RW x= pte 0xffffffffc1834000-0xffffffffc183a000 24K USR RW x= pte 0xffffffffc183a000-0xffffffffc183d000 12K USR RW x= pte 0xffffffffc183d000-0xffffffffc1841000 16K USR RW x= pte 0xffffffffc1841000-0xffffffffc1843000 8K USR RW x= pte 0xffffffffc1843000-0xffffffffc1845000 8K USR RW x= pte 0xffffffffc1845000-0xffffffffc1846000 4K USR RW x= pte 0xffffffffc1846000-0xffffffffc1849000 12K USR RW x= pte 0xffffffffc1849000-0xffffffffc184a000 4K USR RW x= pte 0xffffffffc184a000-0xffffffffc184f000 20K USR RW x= pte 0xffffffffc184f000-0xffffffffc1850000 4K USR RW x= pte 0xffffffffc1850000-0xffffffffc1885000 212K USR RW x= pte 0xffffffffc1885000-0xffffffffc1938000 716K USR RW N= X pte 0xffffffffc1938000-0xffffffffc193a000 8K USR RW x= pte 0xffffffffc193a000-0xffffffffc193b000 4K USR ro x= pte 0xffffffffc193b000-0xffffffffc193d000 8K USR RW x= pte 0xffffffffc193d000-0xffffffffc193e000 4K USR ro x= pte 0xffffffffc193e000-0xffffffffc1948000 40K USR RW x= pte 0xffffffffc1948000-0xffffffffc194a000 8K USR RW x= pte 0xffffffffc194a000-0xffffffffc194c000 8K USR RW x= pte 0xffffffffc194c000-0xffffffffc196c000 128K USR RW x= pte 0xffffffffc196c000-0xffffffffc196d000 4K USR RW x= pte 0xffffffffc196d000-0xffffffffc1970000 12K USR RW x= pte 0xffffffffc1970000-0xffffffffc1971000 4K USR RW x= pte 0xffffffffc1971000-0xffffffffc1972000 4K USR RW x= pte 0xffffffffc1972000-0xffffffffc1973000 4K USR RW x= pte 0xffffffffc1973000-0xffffffffc1975000 8K USR RW x= pte 0xffffffffc1975000-0xffffffffc1976000 4K USR RW x= pte 0xffffffffc1976000-0xffffffffc1977000 4K USR RW x= pte 0xffffffffc1977000-0xffffffffc197b000 16K USR RW x= pte 0xffffffffc197b000-0xffffffffc19b9000 248K USR RW x= pte 0xffffffffc19b9000-0xffffffffc19c0000 28K USR RW x= pte 0xffffffffc19c0000-0xffffffffc19df000 124K USR RW x= pte 0xffffffffc19df000-0xffffffffc19e8000 36K USR RW x= pte 0xffffffffc19e8000-0xffffffffc19f1000 36K USR RW x= pte 0xffffffffc19f1000-0xffffffffc19f2000 4K USR RW x= pte 0xffffffffc19f2000-0xffffffffc19f3000 4K USR RW x= pte 0xffffffffc19f3000-0xffffffffc19f5000 8K USR RW x= pte 0xffffffffc19f5000-0xffffffffc19f8000 12K USR RW x= pte 0xffffffffc19f8000-0xffffffffc1a0a000 72K USR RW x= pte 0xffffffffc1a0a000-0xffffffffc1a0f000 20K USR RW x= pte 0xffffffffc1a0f000-0xffffffffc1a1c000 52K USR RW x= pte 0xffffffffc1a1c000-0xffffffffc1a1d000 4K USR RW x= pte 0xffffffffc1a1d000-0xffffffffc1aa4000 540K USR RW x= pte 0xffffffffc1aa4000-0xffffffffc1aa8000 16K USR ro x= pte 0xffffffffc1aa8000-0xffffffffc1b28000 512K USR RW x= pte 0xffffffffc1b28000-0xffffffffc1e3d000 3156K USR RW x= pte 0xffffffffc1e3d000-0xffffffffcfc93000 227672K USR RW N= X pte 0xffffffffcfc93000-0xffffffffdf694000 256004K USR RW x= pte 0xffffffffdf694000-0xffffffffdf696000 8K USR RW x= pte 0xffffffffdf696000-0xffffffffdf797000 1028K USR ro x= pte 0xffffffffdf797000-0xffffffffdfc00000 4516K USR RW x= pte 0xffffffffdfc00000-0xffffffffff000000 500M = pmd ---[ End Modules ]--- 0xffffffffff000000-0xffffffffff400000 4M = pmd 0xffffffffff400000-0xffffffffff579000 1508K = pte 0xffffffffff579000-0xffffffffff57a000 4K USR RW N= X pte 0xffffffffff57a000-0xffffffffff5ff000 532K = pte 0xffffffffff5ff000-0xffffffffff601000 8K USR ro GLB N= X pte 0xffffffffff601000-0xffffffffff800000 2044K = pte 0xffffffffff800000-0x0000000000000000 8M = pmd # poweroff --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="133-gb-bad.txt" console [hvc0] enabled, bootconsole disabled Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2261.074 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4522.14 BogoMIPS (lpj=2261074) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes) Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 24k freed cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 46 no PMU driver, software events only. NMI watchdog: disabled (cpu0): hardware events not enabled Brought up 1 CPUs kworker/u:0 used greatest stack depth: 6000 bytes left Grant tables using version 2 layout. Grant table initialized RTC time: 165:165:165, date: 165/165/65 NET: Registered protocol family 16 kworker/u:0 used greatest stack depth: 5536 bytes left dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 65536 (order: 9, 2097152 bytes) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 227672k freed platform rtc_cmos: registered platform RTC device (no PNP device found) Machine check injector initialized microcode: CPU0 sig=0x206e5, pf=0x4, revision=0xffff0018 microcode: Microcode Update Driver: v2.00 , Peter Oruba audit: initializing netlink socket (disabled) type=2000 audit(1336432515.722:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) NFS: Registering the id_resolver key type NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 32768 SELinux: Registering netfilter hooks Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ioatdma: Intel(R) QuickData Technology Driver 4.00 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 brd: module loaded loop: module loaded Fixed MDIO Bus: probed tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.2.0-k ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 80 td 96 uhci_hcd: USB Universal Host Controller Interface driver usbcore: registered new interface driver usblp usbcore: registered new interface driver libusual i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ctnetlink v0.93: registering with nfnetlink. ip_tables: (C) 2000-2006 Netfilter Core Team TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Registering the dns_resolver key type PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Magic number: 1:252:3141 Freeing unused kernel memory: 692k freed Write protecting the kernel read-only data: 8192k Freeing unused kernel memory: 292k freed Freeing unused kernel memory: 400k freed init started: BusyBox v1.14.3 (2012-05-07 12:16:33 EDT) Mounting directories [ OK ] ------------[ cut here ]------------ WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: Pid: 1051, comm: modprobe Not tainted 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dc6 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 1051, comm: modprobe Tainted: G W 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 73 active_anon:253 inactive_anon:31970 isolated_anon:0 active_file:391 inactive_file:27806 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33525733 slab_reclaimable:1660 slab_unreclaimable:976 mapped:340 shmem:31960 pagetables:34 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130456376kB min:45112kB low:56388kB high:67668kB active_anon:1012kB inactive_anon:127880kB active_file:1564kB inactive_file:111224kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:1360kB shmem:127840kB slab_reclaimable:6640kB slab_unreclaimable:3904kB kernel_stack:368kB pagetables:136kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 26*4kB 26*8kB 14*16kB 11*32kB 11*64kB 6*128kB 8*256kB 7*512kB 9*1024kB 3*2048kB 31844*4096kB = 130456376kB 60151 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 983 pages shared 166525 pages non-shared modprobe: FATAL: Error inserting xenfs (/lib/modules/3.4.0-rc6upstream-00024-g3bfd88d-dirty/kernel/drivers/xen/xenfs/xenfs.ko): Cannot allocate memory ... ------------[ cut here ]------------ WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: libcrc32c crc32c Pid: 2165, comm: modprobe Tainted: G W O 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dd2 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 2165, comm: modprobe Tainted: G W O 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 37 active_anon:1428 inactive_anon:31278 isolated_anon:0 active_file:1711 inactive_file:26465 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33523833 slab_reclaimable:2320 slab_unreclaimable:1641 mapped:586 shmem:31998 pagetables:132 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130448776kB min:45112kB low:56388kB high:67668kB active_anon:5712kB inactive_anon:125112kB active_file:6844kB inactive_file:105860kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:2340kB shmem:127992kB slab_reclaimable:9280kB slab_unreclaimable:6564kB kernel_stack:296kB pagetables:528kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 126*4kB 84*8kB 70*16kB 33*32kB 10*64kB 4*128kB 2*256kB 3*512kB 7*1024kB 5*2048kB 31842*4096kB = 130448792kB 60174 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 1735 pages shared 168082 pages non-shared 0xffffc90000000000-0xffffc90010001000 268439552 alloc_large_system_hash+0x154/0x213 pages=65536 vmalloc vpages N0=65536 0xffffc90010001000-0xffffc90010082000 528384 alloc_large_system_hash+0x154/0x213 pages=128 vmalloc N0=128 0xffffc90010082000-0xffffc90018083000 134221824 alloc_large_system_hash+0x154/0x213 pages=32768 vmalloc vpages N0=32768 0xffffc90018083000-0xffffc900180c4000 266240 alloc_large_system_hash+0x154/0x213 pages=64 vmalloc N0=64 0xffffc900180c4000-0xffffc900180c7000 12288 alloc_large_system_hash+0x154/0x213 pages=2 vmalloc N0=2 0xffffc900180c8000-0xffffc900180cd000 20480 arch_gnttab_map_status+0x50/0x70 ioremap 0xffffc900180cd000-0xffffc900180d2000 20480 alloc_large_system_hash+0x154/0x213 pages=4 vmalloc N0=4 0xffffc900180d2000-0xffffc900180de000 49152 zisofs_init+0x11/0x23 pages=11 vmalloc N0=11 0xffffc900180de000-0xffffc900180eb000 53248 netback_init+0x4c/0x210 pages=12 vmalloc N0=12 0xffffc90018100000-0xffffc90018121000 135168 arch_gnttab_map_shared+0x50/0x70 ioremap 0xffffc90018121000-0xffffc90018522000 4198400 alloc_large_system_hash+0x154/0x213 pages=1024 vmalloc vpages N0=1024 0xffffc90018522000-0xffffc90018d23000 8392704 alloc_large_system_hash+0x154/0x213 pages=2048 vmalloc vpages N0=2048 0xffffc90018d23000-0xffffc90018e24000 1052672 alloc_large_system_hash+0x154/0x213 pages=256 vmalloc N0=256 0xffffc90018e24000-0xffffc90019025000 2101248 alloc_large_system_hash+0x154/0x213 pages=512 vmalloc N0=512 0xffffc90019025000-0xffffc90019226000 2101248 alloc_large_system_hash+0x154/0x213 pages=512 vmalloc N0=512 0xffffffffa0000000-0xffffffffa0005000 20480 module_alloc_update_bounds+0x19/0x80 pages=4 vmalloc N0=4 0xffffffffa0008000-0xffffffffa000d000 20480 module_alloc_update_bounds+0x19/0x80 pages=4 vmalloc N0=4 ---[ User Space ]--- 0x0000000000000000-0xffff800000000000 16777088T pgd ---[ Kernel Space ]--- 0xffff800000000000-0xffff814000000000 1280G pud 0xffff814000000000-0xffff8140a0000000 2560M pmd 0xffff8140a0000000-0xffff8140a0500000 5M pte 0xffff8140a0500000-0xffff8140a0501000 4K USR RW x pte 0xffff8140a0501000-0xffff8140a0503000 8K RW x pte 0xffff8140a0503000-0xffff8140a0504000 4K pte 0xffff8140a0504000-0xffff8140a0505000 4K RW x pte 0xffff8140a0505000-0xffff8140a0507000 8K USR RW x pte 0xffff8140a0507000-0xffff8140a0509000 8K RW x pte 0xffff8140a0509000-0xffff8140a0510000 28K pte 0xffff8140a0510000-0xffff8140a0511000 4K USR RW x pte 0xffff8140a0511000-0xffff8140a0592000 516K pte 0xffff8140a0592000-0xffff8140a0593000 4K USR RW x pte 0xffff8140a0593000-0xffff8140a05d4000 260K pte 0xffff8140a05d4000-0xffff8140a05d5000 4K USR RW x pte 0xffff8140a05d5000-0xffff8140a05ff000 168K pte 0xffff8140a05ff000-0xffff8140a0600000 4K USR RW x pte 0xffff8140a0600000-0xffff8140a0800000 2M pmd 0xffff8140a0800000-0xffff8140a1200000 10M pte 0xffff8140a1200000-0xffff8140a2000000 14M pmd 0xffff8140a2000000-0xffff8140a2083000 524K USR RW x pte 0xffff8140a2083000-0xffff8140a2200000 1524K pte 0xffff8140a2200000-0xffff8140b2400000 258M pmd 0xffff8140b2400000-0xffff8140b2401000 4K USR RW x pte 0xffff8140b2401000-0xffff8140b2600000 2044K pte 0xffff8140b2600000-0xffff8140ba800000 130M pmd 0xffff8140ba800000-0xffff8140ba802000 8K USR RW x pte 0xffff8140ba802000-0xffff8140baa00000 2040K pte 0xffff8140baa00000-0xffff8140bfe00000 84M pmd 0xffff8140bfe00000-0xffff8140bfffe000 2040K pte 0xffff8140bfffe000-0xffff8140c0000000 8K USR RW x pte 0xffff8140c0000000-0xffff814100000000 1G pud 0xffff814100000000-0xffff814240000000 5G pmd 0xffff814240000000-0xffff814400000000 7G pud 0xffff814400000000-0xffff8144105bc000 268016K USR RW x pte 0xffff8144105bc000-0xffff814410600000 272K pte 0xffff814410600000-0xffff814440000000 762M pmd 0xffff814440000000-0xffff816480000000 129G pud 0xffff816480000000-0xffff8164800cb000 812K USR RW x pte 0xffff8164800cb000-0xffff816480200000 1236K pte 0xffff816480200000-0xffff8164c0000000 1022M pmd 0xffff8164c0000000-0xffff817500000000 65G pud 0xffff817500000000-0xffff817500395000 3668K USR RW x pte 0xffff817500395000-0xffff817500400000 428K pte 0xffff817500400000-0xffff817540000000 1020M pmd 0xffff817540000000-0xffff817fc0000000 42G pud 0xffff817fc0000000-0xffff817fffc00000 1020M pmd 0xffff817fffc00000-0xffff817fffc08000 32K pte 0xffff817fffc08000-0xffff817fffc0e000 24K USR RW x pte 0xffff817fffc0e000-0xffff817fffc7e000 448K pte 0xffff817fffc7e000-0xffff817fffd02000 528K USR RW x pte 0xffff817fffd02000-0xffff817fffe00000 1016K pte 0xffff817fffe00000-0xffff817ffff02000 1032K USR RW x pte 0xffff817ffff02000-0xffff817fffffa000 992K pte 0xffff817fffffa000-0xffff817fffffc000 8K USR RW x pte 0xffff817fffffc000-0xffff818000000000 16K pte 0xffff818000000000-0xffff820000000000 512G pgd 0xffff820000000000-0xffff848000000000 2560G pud 0xffff848000000000-0xffff880000000000 3584G pgd ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff88000009b000 620K USR RW x pte 0xffff88000009b000-0xffff8800000a0000 20K USR RW x pte 0xffff8800000a0000-0xffff8800007fb000 7532K USR RW x pte 0xffff8800007fb000-0xffff880000ef8000 7156K USR ro x pte 0xffff880000ef8000-0xffff880001000000 1056K USR RW x pte 0xffff880001000000-0xffff880001002000 8K USR ro x pte 0xffff880001002000-0xffff880001013000 68K USR ro x pte 0xffff880001013000-0xffff880001015000 8K USR ro x pte 0xffff880001015000-0xffff880001017000 8K USR ro x pte 0xffff880001017000-0xffff880001019000 8K USR ro x pte 0xffff880001019000-0xffff88000101a000 4K USR ro x pte 0xffff88000101a000-0xffff88000101b000 4K USR ro x pte 0xffff88000101b000-0xffff88000101f000 16K USR ro x pte 0xffff88000101f000-0xffff880001028000 36K USR ro x pte 0xffff880001028000-0xffff88000102a000 8K USR ro x pte 0xffff88000102a000-0xffff88000102c000 8K USR ro x pte 0xffff88000102c000-0xffff88000103c000 64K USR ro x pte 0xffff88000103c000-0xffff88000103d000 4K USR ro x pte 0xffff88000103d000-0xffff880001051000 80K USR ro x pte 0xffff880001051000-0xffff880001052000 4K USR ro x pte 0xffff880001052000-0xffff880001057000 20K USR ro x pte 0xffff880001057000-0xffff880001058000 4K USR ro x pte 0xffff880001058000-0xffff880001061000 36K USR ro x pte 0xffff880001061000-0xffff880001063000 8K USR ro x pte 0xffff880001063000-0xffff88000106b000 32K USR ro x pte 0xffff88000106b000-0xffff88000106c000 4K USR ro x pte 0xffff88000106c000-0xffff880001078000 48K USR ro x pte 0xffff880001078000-0xffff88000107a000 8K USR ro x pte 0xffff88000107a000-0xffff880001083000 36K USR ro x pte 0xffff880001083000-0xffff880001084000 4K USR ro x pte 0xffff880001084000-0xffff88000108f000 44K USR ro x pte 0xffff88000108f000-0xffff880001090000 4K USR ro x pte 0xffff880001090000-0xffff880001094000 16K USR ro x pte 0xffff880001094000-0xffff880001097000 12K USR ro x pte 0xffff880001097000-0xffff8800010a0000 36K USR ro x pte 0xffff8800010a0000-0xffff8800010a2000 8K USR ro x pte 0xffff8800010a2000-0xffff8800010a7000 20K USR ro x pte 0xffff8800010a7000-0xffff8800010a8000 4K USR ro x pte 0xffff8800010a8000-0xffff8800010aa000 8K USR ro x pte 0xffff8800010aa000-0xffff8800010af000 20K USR ro x pte 0xffff8800010af000-0xffff8800010b4000 20K USR ro x pte 0xffff8800010b4000-0xffff8800010b6000 8K USR ro x pte 0xffff8800010b6000-0xffff8800010c0000 40K USR ro x pte 0xffff8800010c0000-0xffff8800010c4000 16K USR ro x pte 0xffff8800010c4000-0xffff8800010c6000 8K USR ro x pte 0xffff8800010c6000-0xffff8800010ca000 16K USR ro x pte 0xffff8800010ca000-0xffff8800010cc000 8K USR ro x pte 0xffff8800010cc000-0xffff8800010cd000 4K USR ro x pte 0xffff8800010cd000-0xffff8800010d5000 32K USR ro x pte 0xffff8800010d5000-0xffff8800010d9000 16K USR ro x pte 0xffff8800010d9000-0xffff8800010da000 4K USR ro x pte 0xffff8800010da000-0xffff8800010db000 4K USR ro x pte 0xffff8800010db000-0xffff8800010dc000 4K USR ro x pte 0xffff8800010dc000-0xffff8800010dd000 4K USR ro x pte 0xffff8800010dd000-0xffff8800010e2000 20K USR ro x pte 0xffff8800010e2000-0xffff8800010e3000 4K USR ro x pte 0xffff8800010e3000-0xffff8800010f8000 84K USR ro x pte 0xffff8800010f8000-0xffff8800010fb000 12K USR ro x pte 0xffff8800010fb000-0xffff880001101000 24K USR ro x pte 0xffff880001101000-0xffff880001102000 4K USR ro x pte 0xffff880001102000-0xffff880001106000 16K USR ro x pte 0xffff880001106000-0xffff880001107000 4K USR ro x pte 0xffff880001107000-0xffff880001108000 4K USR ro x pte 0xffff880001108000-0xffff880001109000 4K USR ro x pte 0xffff880001109000-0xffff880001113000 40K USR ro x pte 0xffff880001113000-0xffff880001114000 4K USR ro x pte 0xffff880001114000-0xffff880001117000 12K USR ro x pte 0xffff880001117000-0xffff880001118000 4K USR ro x pte 0xffff880001118000-0xffff880001122000 40K USR ro x pte 0xffff880001122000-0xffff880001124000 8K USR ro x pte 0xffff880001124000-0xffff880001143000 124K USR ro x pte 0xffff880001143000-0xffff880001145000 8K USR ro x pte 0xffff880001145000-0xffff880001166000 132K USR ro x pte 0xffff880001166000-0xffff880001168000 8K USR ro x pte 0xffff880001168000-0xffff88000116d000 20K USR ro x pte 0xffff88000116d000-0xffff88000116e000 4K USR ro x pte 0xffff88000116e000-0xffff88000116f000 4K USR ro x pte 0xffff88000116f000-0xffff880001170000 4K USR ro x pte 0xffff880001170000-0xffff880001174000 16K USR ro x pte 0xffff880001174000-0xffff880001177000 12K USR ro x pte 0xffff880001177000-0xffff88000117a000 12K USR ro x pte 0xffff88000117a000-0xffff88000117e000 16K USR ro x pte 0xffff88000117e000-0xffff88000118d000 60K USR ro x pte 0xffff88000118d000-0xffff88000118e000 4K USR ro x pte 0xffff88000118e000-0xffff880001190000 8K USR ro x pte 0xffff880001190000-0xffff880001191000 4K USR ro x pte 0xffff880001191000-0xffff880001192000 4K USR ro x pte 0xffff880001192000-0xffff880001193000 4K USR ro x pte 0xffff880001193000-0xffff880001194000 4K USR ro x pte 0xffff880001194000-0xffff880001197000 12K USR ro x pte 0xffff880001197000-0xffff880001198000 4K USR ro x pte 0xffff880001198000-0xffff880001199000 4K USR ro x pte 0xffff880001199000-0xffff8800011a0000 28K USR ro x pte 0xffff8800011a0000-0xffff8800011a1000 4K USR ro x pte 0xffff8800011a1000-0xffff8800011ab000 40K USR ro x pte 0xffff8800011ab000-0xffff8800011ac000 4K USR ro x pte 0xffff8800011ac000-0xffff8800011af000 12K USR ro x pte 0xffff8800011af000-0xffff8800011b1000 8K USR ro x pte 0xffff8800011b1000-0xffff8800011b4000 12K USR ro x pte 0xffff8800011b4000-0xffff8800011b5000 4K USR ro x pte 0xffff8800011b5000-0xffff8800011b9000 16K USR ro x pte 0xffff8800011b9000-0xffff8800011bb000 8K USR ro x pte 0xffff8800011bb000-0xffff8800011bd000 8K USR ro x pte 0xffff8800011bd000-0xffff8800011be000 4K USR ro x pte 0xffff8800011be000-0xffff8800011c2000 16K USR ro x pte 0xffff8800011c2000-0xffff8800011c6000 16K USR ro x pte 0xffff8800011c6000-0xffff8800011c7000 4K USR ro x pte 0xffff8800011c7000-0xffff8800011c8000 4K USR ro x pte 0xffff8800011c8000-0xffff8800011c9000 4K USR ro x pte 0xffff8800011c9000-0xffff8800011ca000 4K USR ro x pte 0xffff8800011ca000-0xffff8800011cf000 20K USR ro x pte 0xffff8800011cf000-0xffff8800011d0000 4K USR ro x pte 0xffff8800011d0000-0xffff8800011d3000 12K USR ro x pte 0xffff8800011d3000-0xffff8800011d5000 8K USR ro x pte 0xffff8800011d5000-0xffff8800011d6000 4K USR ro x pte 0xffff8800011d6000-0xffff8800011d8000 8K USR ro x pte 0xffff8800011d8000-0xffff8800011d9000 4K USR ro x pte 0xffff8800011d9000-0xffff8800011da000 4K USR ro x pte 0xffff8800011da000-0xffff8800011e0000 24K USR ro x pte 0xffff8800011e0000-0xffff8800011e3000 12K USR ro x pte 0xffff8800011e3000-0xffff8800011e9000 24K USR ro x pte 0xffff8800011e9000-0xffff8800011ea000 4K USR ro x pte 0xffff8800011ea000-0xffff8800011eb000 4K USR ro x pte 0xffff8800011eb000-0xffff8800011f1000 24K USR ro x pte 0xffff8800011f1000-0xffff8800011f7000 24K USR ro x pte 0xffff8800011f7000-0xffff8800011f8000 4K USR ro x pte 0xffff8800011f8000-0xffff8800011fa000 8K USR ro x pte 0xffff8800011fa000-0xffff8800011fb000 4K USR ro x pte 0xffff8800011fb000-0xffff8800011fd000 8K USR ro x pte 0xffff8800011fd000-0xffff8800011fe000 4K USR ro x pte 0xffff8800011fe000-0xffff880001200000 8K USR ro x pte 0xffff880001200000-0xffff880001201000 4K USR ro x pte 0xffff880001201000-0xffff880001203000 8K USR ro x pte 0xffff880001203000-0xffff880001207000 16K USR ro x pte 0xffff880001207000-0xffff880001209000 8K USR ro x pte 0xffff880001209000-0xffff88000120a000 4K USR ro x pte 0xffff88000120a000-0xffff88000120b000 4K USR ro x pte 0xffff88000120b000-0xffff88000120c000 4K USR ro x pte 0xffff88000120c000-0xffff88000120e000 8K USR ro x pte 0xffff88000120e000-0xffff880001223000 84K USR ro x pte 0xffff880001223000-0xffff880001228000 20K USR ro x pte 0xffff880001228000-0xffff880001229000 4K USR ro x pte 0xffff880001229000-0xffff88000123b000 72K USR ro x pte 0xffff88000123b000-0xffff88000123d000 8K USR ro x pte 0xffff88000123d000-0xffff88000123e000 4K USR ro x pte 0xffff88000123e000-0xffff88000123f000 4K USR ro x pte 0xffff88000123f000-0xffff880001242000 12K USR ro x pte 0xffff880001242000-0xffff880001244000 8K USR ro x pte 0xffff880001244000-0xffff880001245000 4K USR ro x pte 0xffff880001245000-0xffff880001247000 8K USR ro x pte 0xffff880001247000-0xffff880001248000 4K USR ro x pte 0xffff880001248000-0xffff880001252000 40K USR ro x pte 0xffff880001252000-0xffff880001253000 4K USR ro x pte 0xffff880001253000-0xffff880001254000 4K USR ro x pte 0xffff880001254000-0xffff880001255000 4K USR ro x pte 0xffff880001255000-0xffff880001258000 12K USR ro x pte 0xffff880001258000-0xffff880001259000 4K USR ro x pte 0xffff880001259000-0xffff880001268000 60K USR ro x pte 0xffff880001268000-0xffff88000126e000 24K USR ro x pte 0xffff88000126e000-0xffff88000126f000 4K USR ro x pte 0xffff88000126f000-0xffff880001272000 12K USR ro x pte 0xffff880001272000-0xffff880001273000 4K USR ro x pte 0xffff880001273000-0xffff880001274000 4K USR ro x pte 0xffff880001274000-0xffff88000127a000 24K USR ro x pte 0xffff88000127a000-0xffff88000127c000 8K USR ro x pte 0xffff88000127c000-0xffff88000127d000 4K USR ro x pte 0xffff88000127d000-0xffff880001285000 32K USR ro x pte 0xffff880001285000-0xffff880001286000 4K USR ro x pte 0xffff880001286000-0xffff880001287000 4K USR ro x pte 0xffff880001287000-0xffff880001288000 4K USR ro x pte 0xffff880001288000-0xffff880001289000 4K USR ro x pte 0xffff880001289000-0xffff88000128d000 16K USR ro x pte 0xffff88000128d000-0xffff88000128f000 8K USR ro x pte 0xffff88000128f000-0xffff880001291000 8K USR ro x pte 0xffff880001291000-0xffff880001292000 4K USR ro x pte 0xffff880001292000-0xffff88000129f000 52K USR ro x pte 0xffff88000129f000-0xffff8800012a0000 4K USR ro x pte 0xffff8800012a0000-0xffff8800012a1000 4K USR ro x pte 0xffff8800012a1000-0xffff8800012a3000 8K USR ro x pte 0xffff8800012a3000-0xffff8800012a5000 8K USR ro x pte 0xffff8800012a5000-0xffff8800012a6000 4K USR ro x pte 0xffff8800012a6000-0xffff8800012a9000 12K USR ro x pte 0xffff8800012a9000-0xffff8800012ab000 8K USR ro x pte 0xffff8800012ab000-0xffff8800012c3000 96K USR ro x pte 0xffff8800012c3000-0xffff8800012c6000 12K USR ro x pte 0xffff8800012c6000-0xffff8800012cc000 24K USR ro x pte 0xffff8800012cc000-0xffff8800012cf000 12K USR ro x pte 0xffff8800012cf000-0xffff8800012d1000 8K USR ro x pte 0xffff8800012d1000-0xffff8800012d2000 4K USR ro x pte 0xffff8800012d2000-0xffff8800012d3000 4K USR ro x pte 0xffff8800012d3000-0xffff8800012d7000 16K USR ro x pte 0xffff8800012d7000-0xffff8800012d8000 4K USR ro x pte 0xffff8800012d8000-0xffff8800012da000 8K USR ro x pte 0xffff8800012da000-0xffff8800012dc000 8K USR ro x pte 0xffff8800012dc000-0xffff8800012e1000 20K USR ro x pte 0xffff8800012e1000-0xffff8800012e3000 8K USR ro x pte 0xffff8800012e3000-0xffff8800012e4000 4K USR ro x pte 0xffff8800012e4000-0xffff8800012e5000 4K USR ro x pte 0xffff8800012e5000-0xffff8800012e6000 4K USR ro x pte 0xffff8800012e6000-0xffff8800012e7000 4K USR ro x pte 0xffff8800012e7000-0xffff8800012ed000 24K USR ro x pte 0xffff8800012ed000-0xffff8800012ee000 4K USR ro x pte 0xffff8800012ee000-0xffff8800012f9000 44K USR ro x pte 0xffff8800012f9000-0xffff8800012fa000 4K USR ro x pte 0xffff8800012fa000-0xffff8800012fe000 16K USR ro x pte 0xffff8800012fe000-0xffff880001300000 8K USR ro x pte 0xffff880001300000-0xffff880001302000 8K USR ro x pte 0xffff880001302000-0xffff88000130d000 44K USR ro x pte 0xffff88000130d000-0xffff88000130e000 4K USR ro x pte 0xffff88000130e000-0xffff88000130f000 4K USR ro x pte 0xffff88000130f000-0xffff880001312000 12K USR ro x pte 0xffff880001312000-0xffff880001314000 8K USR ro x pte 0xffff880001314000-0xffff880001318000 16K USR ro x pte 0xffff880001318000-0xffff88000131b000 12K USR ro x pte 0xffff88000131b000-0xffff88000131c000 4K USR ro x pte 0xffff88000131c000-0xffff880001324000 32K USR ro x pte 0xffff880001324000-0xffff880001329000 20K USR ro x pte 0xffff880001329000-0xffff88000132d000 16K USR ro x pte 0xffff88000132d000-0xffff88000132e000 4K USR ro x pte 0xffff88000132e000-0xffff88000132f000 4K USR ro x pte 0xffff88000132f000-0xffff880001332000 12K USR ro x pte 0xffff880001332000-0xffff880001333000 4K USR ro x pte 0xffff880001333000-0xffff880001334000 4K USR ro x pte 0xffff880001334000-0xffff880001335000 4K USR ro x pte 0xffff880001335000-0xffff880001337000 8K USR ro x pte 0xffff880001337000-0xffff88000133b000 16K USR ro x pte 0xffff88000133b000-0xffff88000133c000 4K USR ro x pte 0xffff88000133c000-0xffff880001340000 16K USR ro x pte 0xffff880001340000-0xffff880001342000 8K USR ro x pte 0xffff880001342000-0xffff880001343000 4K USR ro x pte 0xffff880001343000-0xffff880001348000 20K USR ro x pte 0xffff880001348000-0xffff88000134c000 16K USR ro x pte 0xffff88000134c000-0xffff880001350000 16K USR ro x pte 0xffff880001350000-0xffff880001351000 4K USR ro x pte 0xffff880001351000-0xffff880001353000 8K USR ro x pte 0xffff880001353000-0xffff880001358000 20K USR ro x pte 0xffff880001358000-0xffff88000135e000 24K USR ro x pte 0xffff88000135e000-0xffff88000135f000 4K USR ro x pte 0xffff88000135f000-0xffff880001361000 8K USR ro x pte 0xffff880001361000-0xffff880001366000 20K USR ro x pte 0xffff880001366000-0xffff880001367000 4K USR ro x pte 0xffff880001367000-0xffff880001368000 4K USR ro x pte 0xffff880001368000-0xffff88000136a000 8K USR ro x pte 0xffff88000136a000-0xffff880001374000 40K USR ro x pte 0xffff880001374000-0xffff880001376000 8K USR ro x pte 0xffff880001376000-0xffff880001379000 12K USR ro x pte 0xffff880001379000-0xffff88000137f000 24K USR ro x pte 0xffff88000137f000-0xffff880001380000 4K USR ro x pte 0xffff880001380000-0xffff880001383000 12K USR ro x pte 0xffff880001383000-0xffff880001384000 4K USR ro x pte 0xffff880001384000-0xffff880001387000 12K USR ro x pte 0xffff880001387000-0xffff880001389000 8K USR ro x pte 0xffff880001389000-0xffff88000138c000 12K USR ro x pte 0xffff88000138c000-0xffff880001393000 28K USR ro x pte 0xffff880001393000-0xffff880001395000 8K USR ro x pte 0xffff880001395000-0xffff880001398000 12K USR ro x pte 0xffff880001398000-0xffff88000139a000 8K USR ro x pte 0xffff88000139a000-0xffff88000139c000 8K USR ro x pte 0xffff88000139c000-0xffff88000139d000 4K USR ro x pte 0xffff88000139d000-0xffff8800013a3000 24K USR ro x pte 0xffff8800013a3000-0xffff8800013a4000 4K USR ro x pte 0xffff8800013a4000-0xffff8800013a5000 4K USR ro x pte 0xffff8800013a5000-0xffff8800013a6000 4K USR ro x pte 0xffff8800013a6000-0xffff8800013a9000 12K USR ro x pte 0xffff8800013a9000-0xffff8800013ab000 8K USR ro x pte 0xffff8800013ab000-0xffff8800013ac000 4K USR ro x pte 0xffff8800013ac000-0xffff8800013ae000 8K USR ro x pte 0xffff8800013ae000-0xffff8800013b1000 12K USR ro x pte 0xffff8800013b1000-0xffff8800013b3000 8K USR ro x pte 0xffff8800013b3000-0xffff8800013b5000 8K USR ro x pte 0xffff8800013b5000-0xffff8800013b9000 16K USR ro x pte 0xffff8800013b9000-0xffff8800013ba000 4K USR ro x pte 0xffff8800013ba000-0xffff8800013bf000 20K USR ro x pte 0xffff8800013bf000-0xffff8800013ce000 60K USR ro x pte 0xffff8800013ce000-0xffff8800013cf000 4K USR ro x pte 0xffff8800013cf000-0xffff8800013d0000 4K USR ro x pte 0xffff8800013d0000-0xffff8800013d2000 8K USR ro x pte 0xffff8800013d2000-0xffff8800013d3000 4K USR ro x pte 0xffff8800013d3000-0xffff8800013db000 32K USR ro x pte 0xffff8800013db000-0xffff8800013dc000 4K USR ro x pte 0xffff8800013dc000-0xffff8800013dd000 4K USR ro x pte 0xffff8800013dd000-0xffff8800013de000 4K USR ro x pte 0xffff8800013de000-0xffff8800013e0000 8K USR ro x pte 0xffff8800013e0000-0xffff8800013e3000 12K USR ro x pte 0xffff8800013e3000-0xffff8800013e5000 8K USR ro x pte 0xffff8800013e5000-0xffff8800013e8000 12K USR ro x pte 0xffff8800013e8000-0xffff8800013ea000 8K USR ro x pte 0xffff8800013ea000-0xffff8800013ec000 8K USR ro x pte 0xffff8800013ec000-0xffff8800013ed000 4K USR ro x pte 0xffff8800013ed000-0xffff8800013ef000 8K USR ro x pte 0xffff8800013ef000-0xffff8800013f3000 16K USR ro x pte 0xffff8800013f3000-0xffff8800013f4000 4K USR ro x pte 0xffff8800013f4000-0xffff8800013f6000 8K USR ro x pte 0xffff8800013f6000-0xffff8800013f7000 4K USR ro x pte 0xffff8800013f7000-0xffff8800013fa000 12K USR ro x pte 0xffff8800013fa000-0xffff8800013fb000 4K USR ro x pte 0xffff8800013fb000-0xffff8800013fd000 8K USR ro x pte 0xffff8800013fd000-0xffff8800013fe000 4K USR ro x pte 0xffff8800013fe000-0xffff880001403000 20K USR ro x pte 0xffff880001403000-0xffff880001404000 4K USR ro x pte 0xffff880001404000-0xffff880001406000 8K USR ro x pte 0xffff880001406000-0xffff880001408000 8K USR ro x pte 0xffff880001408000-0xffff880001411000 36K USR ro x pte 0xffff880001411000-0xffff880001412000 4K USR ro x pte 0xffff880001412000-0xffff880001413000 4K USR ro x pte 0xffff880001413000-0xffff880001415000 8K USR ro x pte 0xffff880001415000-0xffff880001416000 4K USR ro x pte 0xffff880001416000-0xffff880001419000 12K USR ro x pte 0xffff880001419000-0xffff88000141e000 20K USR ro x pte 0xffff88000141e000-0xffff880001425000 28K USR ro x pte 0xffff880001425000-0xffff880001426000 4K USR ro x pte 0xffff880001426000-0xffff880001428000 8K USR ro x pte 0xffff880001428000-0xffff88000142f000 28K USR ro x pte 0xffff88000142f000-0xffff880001430000 4K USR ro x pte 0xffff880001430000-0xffff880001437000 28K USR ro x pte 0xffff880001437000-0xffff880001438000 4K USR ro x pte 0xffff880001438000-0xffff880001439000 4K USR ro x pte 0xffff880001439000-0xffff88000143d000 16K USR ro x pte 0xffff88000143d000-0xffff88000143e000 4K USR ro x pte 0xffff88000143e000-0xffff88000143f000 4K USR ro x pte 0xffff88000143f000-0xffff880001440000 4K USR ro x pte 0xffff880001440000-0xffff880001443000 12K USR ro x pte 0xffff880001443000-0xffff880001445000 8K USR ro x pte 0xffff880001445000-0xffff880001446000 4K USR ro x pte 0xffff880001446000-0xffff880001448000 8K USR ro x pte 0xffff880001448000-0xffff88000144d000 20K USR ro x pte 0xffff88000144d000-0xffff88000144f000 8K USR ro x pte 0xffff88000144f000-0xffff880001451000 8K USR ro x pte 0xffff880001451000-0xffff880001452000 4K USR ro x pte 0xffff880001452000-0xffff880001458000 24K USR ro x pte 0xffff880001458000-0xffff880001459000 4K USR ro x pte 0xffff880001459000-0xffff88000145a000 4K USR ro x pte 0xffff88000145a000-0xffff88000145c000 8K USR ro x pte 0xffff88000145c000-0xffff88000145d000 4K USR ro x pte 0xffff88000145d000-0xffff880001462000 20K USR ro x pte 0xffff880001462000-0xffff880001463000 4K USR ro x pte 0xffff880001463000-0xffff880001464000 4K USR ro x pte 0xffff880001464000-0xffff880001465000 4K USR ro x pte 0xffff880001465000-0xffff880001467000 8K USR ro x pte 0xffff880001467000-0xffff880001468000 4K USR ro x pte 0xffff880001468000-0xffff880001469000 4K USR ro x pte 0xffff880001469000-0xffff88000146a000 4K USR ro x pte 0xffff88000146a000-0xffff88000146b000 4K USR ro x pte 0xffff88000146b000-0xffff880001470000 20K USR ro x pte 0xffff880001470000-0xffff880001471000 4K USR ro x pte 0xffff880001471000-0xffff880001473000 8K USR ro x pte 0xffff880001473000-0xffff880001477000 16K USR ro x pte 0xffff880001477000-0xffff88000147a000 12K USR ro x pte 0xffff88000147a000-0xffff88000147b000 4K USR ro x pte 0xffff88000147b000-0xffff88000147c000 4K USR ro x pte 0xffff88000147c000-0xffff88000147d000 4K USR ro x pte 0xffff88000147d000-0xffff880001482000 20K USR ro x pte 0xffff880001482000-0xffff880001484000 8K USR ro x pte 0xffff880001484000-0xffff880001485000 4K USR ro x pte 0xffff880001485000-0xffff880001486000 4K USR ro x pte 0xffff880001486000-0xffff880001489000 12K USR ro x pte 0xffff880001489000-0xffff88000148a000 4K USR ro x pte 0xffff88000148a000-0xffff88000148b000 4K USR ro x pte 0xffff88000148b000-0xffff88000148c000 4K USR ro x pte 0xffff88000148c000-0xffff880001499000 52K USR ro x pte 0xffff880001499000-0xffff88000149a000 4K USR ro x pte 0xffff88000149a000-0xffff8800014a2000 32K USR ro x pte 0xffff8800014a2000-0xffff8800014a5000 12K USR ro x pte 0xffff8800014a5000-0xffff8800014a8000 12K USR ro x pte 0xffff8800014a8000-0xffff8800014b0000 32K USR ro x pte 0xffff8800014b0000-0xffff8800014b1000 4K USR ro x pte 0xffff8800014b1000-0xffff8800014b2000 4K USR ro x pte 0xffff8800014b2000-0xffff8800014c2000 64K USR ro x pte 0xffff8800014c2000-0xffff8800014c3000 4K USR ro x pte 0xffff8800014c3000-0xffff8800014c5000 8K USR ro x pte 0xffff8800014c5000-0xffff8800014cb000 24K USR ro x pte 0xffff8800014cb000-0xffff8800014cc000 4K USR ro x pte 0xffff8800014cc000-0xffff8800014cf000 12K USR ro x pte 0xffff8800014cf000-0xffff8800014d0000 4K USR ro x pte 0xffff8800014d0000-0xffff8800014d1000 4K USR ro x pte 0xffff8800014d1000-0xffff8800014d3000 8K USR ro x pte 0xffff8800014d3000-0xffff8800014d4000 4K USR ro x pte 0xffff8800014d4000-0xffff8800014d6000 8K USR ro x pte 0xffff8800014d6000-0xffff8800014d7000 4K USR ro x pte 0xffff8800014d7000-0xffff8800014db000 16K USR ro x pte 0xffff8800014db000-0xffff8800014dc000 4K USR ro x pte 0xffff8800014dc000-0xffff8800014de000 8K USR ro x pte 0xffff8800014de000-0xffff8800014df000 4K USR ro x pte 0xffff8800014df000-0xffff8800014e3000 16K USR ro x pte 0xffff8800014e3000-0xffff8800014e7000 16K USR ro x pte 0xffff8800014e7000-0xffff8800014e8000 4K USR ro x pte 0xffff8800014e8000-0xffff8800014e9000 4K USR ro x pte 0xffff8800014e9000-0xffff8800014f1000 32K USR ro x pte 0xffff8800014f1000-0xffff8800014f2000 4K USR ro x pte 0xffff8800014f2000-0xffff8800014f6000 16K USR ro x pte 0xffff8800014f6000-0xffff8800014f7000 4K USR ro x pte 0xffff8800014f7000-0xffff8800014f8000 4K USR ro x pte 0xffff8800014f8000-0xffff8800014f9000 4K USR ro x pte 0xffff8800014f9000-0xffff8800014fe000 20K USR ro x pte 0xffff8800014fe000-0xffff880001503000 20K USR ro x pte 0xffff880001503000-0xffff880001508000 20K USR ro x pte 0xffff880001508000-0xffff88000150d000 20K USR ro x pte 0xffff88000150d000-0xffff880001511000 16K USR ro x pte 0xffff880001511000-0xffff880001513000 8K USR ro x pte 0xffff880001513000-0xffff880001514000 4K USR ro x pte 0xffff880001514000-0xffff880001515000 4K USR ro x pte 0xffff880001515000-0xffff880001516000 4K USR ro x pte 0xffff880001516000-0xffff88000151b000 20K USR ro x pte 0xffff88000151b000-0xffff880001520000 20K USR ro x pte 0xffff880001520000-0xffff880001521000 4K USR ro x pte 0xffff880001521000-0xffff880001523000 8K USR ro x pte 0xffff880001523000-0xffff880001525000 8K USR ro x pte 0xffff880001525000-0xffff880001526000 4K USR ro x pte 0xffff880001526000-0xffff880001529000 12K USR ro x pte 0xffff880001529000-0xffff88000152a000 4K USR ro x pte 0xffff88000152a000-0xffff88000152b000 4K USR ro x pte 0xffff88000152b000-0xffff88000152e000 12K USR ro x pte 0xffff88000152e000-0xffff880001533000 20K USR ro x pte 0xffff880001533000-0xffff880001535000 8K USR ro x pte 0xffff880001535000-0xffff880001537000 8K USR ro x pte 0xffff880001537000-0xffff880001538000 4K USR ro x pte 0xffff880001538000-0xffff880001539000 4K USR ro x pte 0xffff880001539000-0xffff88000153b000 8K USR ro x pte 0xffff88000153b000-0xffff88000153d000 8K USR ro x pte 0xffff88000153d000-0xffff880001541000 16K USR ro x pte 0xffff880001541000-0xffff880001542000 4K USR ro x pte 0xffff880001542000-0xffff880001544000 8K USR ro x pte 0xffff880001544000-0xffff880001545000 4K USR ro x pte 0xffff880001545000-0xffff880001547000 8K USR ro x pte 0xffff880001547000-0xffff880001551000 40K USR ro x pte 0xffff880001551000-0xffff880001552000 4K USR ro x pte 0xffff880001552000-0xffff880001554000 8K USR ro x pte 0xffff880001554000-0xffff880001555000 4K USR ro x pte 0xffff880001555000-0xffff88000155d000 32K USR ro x pte 0xffff88000155d000-0xffff88000155f000 8K USR ro x pte 0xffff88000155f000-0xffff880001563000 16K USR ro x pte 0xffff880001563000-0xffff880001566000 12K USR ro x pte 0xffff880001566000-0xffff880001567000 4K USR ro x pte 0xffff880001567000-0xffff880001568000 4K USR ro x pte 0xffff880001568000-0xffff88000156a000 8K USR ro x pte 0xffff88000156a000-0xffff88000156b000 4K USR ro x pte 0xffff88000156b000-0xffff880001572000 28K USR ro x pte 0xffff880001572000-0xffff880001573000 4K USR ro x pte 0xffff880001573000-0xffff880001576000 12K USR ro x pte 0xffff880001576000-0xffff880001577000 4K USR ro x pte 0xffff880001577000-0xffff880001578000 4K USR ro x pte 0xffff880001578000-0xffff880001579000 4K USR ro x pte 0xffff880001579000-0xffff88000157a000 4K USR ro x pte 0xffff88000157a000-0xffff88000157b000 4K USR ro x pte 0xffff88000157b000-0xffff88000157d000 8K USR ro x pte 0xffff88000157d000-0xffff88000157f000 8K USR ro x pte 0xffff88000157f000-0xffff880001582000 12K USR ro x pte 0xffff880001582000-0xffff880001584000 8K USR ro x pte 0xffff880001584000-0xffff880001586000 8K USR ro x pte 0xffff880001586000-0xffff880001588000 8K USR ro x pte 0xffff880001588000-0xffff880001589000 4K USR ro x pte 0xffff880001589000-0xffff88000158d000 16K USR ro x pte 0xffff88000158d000-0xffff88000158f000 8K USR ro x pte 0xffff88000158f000-0xffff880001593000 16K USR ro x pte 0xffff880001593000-0xffff880001594000 4K USR ro x pte 0xffff880001594000-0xffff880001595000 4K USR ro x pte 0xffff880001595000-0xffff880001596000 4K USR ro x pte 0xffff880001596000-0xffff880001599000 12K USR ro x pte 0xffff880001599000-0xffff8800015ab000 72K USR ro x pte 0xffff8800015ab000-0xffff8800015ac000 4K USR ro x pte 0xffff8800015ac000-0xffff8800015b0000 16K USR ro x pte 0xffff8800015b0000-0xffff8800015b1000 4K USR ro x pte 0xffff8800015b1000-0xffff8800015b7000 24K USR ro x pte 0xffff8800015b7000-0xffff880001600000 292K USR RW NX pte 0xffff880001600000-0xffff88000179c000 1648K USR ro NX pte 0xffff88000179c000-0xffff880001800000 400K USR RW NX pte 0xffff880001800000-0xffff880001802000 8K USR RW x pte 0xffff880001802000-0xffff880001803000 4K USR RW x pte 0xffff880001803000-0xffff880001805000 8K USR RW x pte 0xffff880001805000-0xffff88000180b000 24K USR RW x pte 0xffff88000180b000-0xffff88000180f000 16K USR ro x pte 0xffff88000180f000-0xffff880001810000 4K USR RW x pte 0xffff880001810000-0xffff880001812000 8K USR ro x pte 0xffff880001812000-0xffff880001813000 4K USR RW x pte 0xffff880001813000-0xffff880001815000 8K USR RW x pte 0xffff880001815000-0xffff880001816000 4K USR RW x pte 0xffff880001816000-0xffff880001818000 8K USR RW x pte 0xffff880001818000-0xffff88000181a000 8K USR RW x pte 0xffff88000181a000-0xffff88000181d000 12K USR RW x pte 0xffff88000181d000-0xffff88000181e000 4K USR RW x pte 0xffff88000181e000-0xffff880001832000 80K USR RW x pte 0xffff880001832000-0xffff880001834000 8K USR RW x pte 0xffff880001834000-0xffff88000183a000 24K USR RW x pte 0xffff88000183a000-0xffff88000183d000 12K USR RW x pte 0xffff88000183d000-0xffff880001841000 16K USR RW x pte 0xffff880001841000-0xffff880001843000 8K USR RW x pte 0xffff880001843000-0xffff880001845000 8K USR RW x pte 0xffff880001845000-0xffff880001846000 4K USR RW x pte 0xffff880001846000-0xffff880001849000 12K USR RW x pte 0xffff880001849000-0xffff88000184a000 4K USR RW x pte 0xffff88000184a000-0xffff88000184f000 20K USR RW x pte 0xffff88000184f000-0xffff880001850000 4K USR RW x pte 0xffff880001850000-0xffff880001885000 212K USR RW x pte 0xffff880001885000-0xffff880001938000 716K USR RW NX pte 0xffff880001938000-0xffff88000193a000 8K USR RW x pte 0xffff88000193a000-0xffff88000193b000 4K USR ro x pte 0xffff88000193b000-0xffff88000193d000 8K USR RW x pte 0xffff88000193d000-0xffff88000193e000 4K USR ro x pte 0xffff88000193e000-0xffff880001948000 40K USR RW x pte 0xffff880001948000-0xffff88000194a000 8K USR RW x pte 0xffff88000194a000-0xffff88000194c000 8K USR RW x pte 0xffff88000194c000-0xffff88000196c000 128K USR RW x pte 0xffff88000196c000-0xffff88000196d000 4K USR RW x pte 0xffff88000196d000-0xffff880001970000 12K USR RW x pte 0xffff880001970000-0xffff880001971000 4K USR RW x pte 0xffff880001971000-0xffff880001972000 4K USR RW x pte 0xffff880001972000-0xffff880001973000 4K USR RW x pte 0xffff880001973000-0xffff880001975000 8K USR RW x pte 0xffff880001975000-0xffff880001976000 4K USR RW x pte 0xffff880001976000-0xffff880001977000 4K USR RW x pte 0xffff880001977000-0xffff88000197b000 16K USR RW x pte 0xffff88000197b000-0xffff8800019b9000 248K USR RW x pte 0xffff8800019b9000-0xffff8800019c0000 28K USR RW x pte 0xffff8800019c0000-0xffff8800019df000 124K USR RW x pte 0xffff8800019df000-0xffff8800019e8000 36K USR RW x pte 0xffff8800019e8000-0xffff8800019f1000 36K USR RW x pte 0xffff8800019f1000-0xffff8800019f2000 4K USR RW x pte 0xffff8800019f2000-0xffff8800019f3000 4K USR RW x pte 0xffff8800019f3000-0xffff8800019f5000 8K USR RW x pte 0xffff8800019f5000-0xffff8800019f8000 12K USR RW x pte 0xffff8800019f8000-0xffff880001a0a000 72K USR RW x pte 0xffff880001a0a000-0xffff880001a0f000 20K USR RW x pte 0xffff880001a0f000-0xffff880001a1c000 52K USR RW x pte 0xffff880001a1c000-0xffff880001a1d000 4K USR RW x pte 0xffff880001a1d000-0xffff880001aaa000 564K USR RW x pte 0xffff880001aaa000-0xffff880001aae000 16K USR ro x pte 0xffff880001aae000-0xffff880001b34000 536K USR RW x pte 0xffff880001b34000-0xffff880001e3d000 3108K USR RW x pte 0xffff880001e3d000-0xffff88000fc93000 227672K USR RW NX pte 0xffff88000fc93000-0xffff880020000000 265652K USR RW x pte 0xffff880020000000-0xffff880020001000 4K USR ro x pte 0xffff880020001000-0xffff880020002000 4K USR ro NX pte 0xffff880020002000-0xffff880020004000 8K USR RW NX pte 0xffff880020004000-0xffff880020008000 16K pte 0xffff880020008000-0xffff880020009000 4K USR ro x pte 0xffff880020009000-0xffff88002000a000 4K USR ro NX pte 0xffff88002000a000-0xffff88002000c000 8K USR RW NX pte 0xffff88002000c000-0xffff880020070000 400K pte 0xffff880020070000-0xffff88002024c000 1904K USR RW x pte 0xffff88002024c000-0xffff88002024e000 8K USR RW x pte 0xffff88002024e000-0xffff880020353000 1044K USR ro x pte 0xffff880020353000-0xffff880020400000 692K USR RW x pte 0xffff880020400000-0xffff880020c00000 8M USR RW x pte 0xffff880020c00000-0xffff8800ef9c0000 3389184K USR RW NX pte 0xffff8800ef9c0000-0xffff8800ff7fb000 260332K USR ro NX pte 0xffff8800ff7fb000-0xffff882019404000 130445348K USR RW NX pte 0xffff882019404000-0xffff882019406000 8K USR ro NX pte 0xffff882019406000-0xffff882019407000 4K USR RW NX pte 0xffff882019407000-0xffff882019408000 4K USR ro NX pte 0xffff882019408000-0xffff88201940a000 8K USR RW NX pte 0xffff88201940a000-0xffff88201940b000 4K USR ro NX pte 0xffff88201940b000-0xffff882019471000 408K USR RW NX pte 0xffff882019471000-0xffff882019473000 8K USR ro NX pte 0xffff882019473000-0xffff882019474000 4K USR RW NX pte 0xffff882019474000-0xffff882019477000 12K USR ro NX pte 0xffff882019477000-0xffff882019479000 8K USR RW NX pte 0xffff882019479000-0xffff88201947a000 4K USR ro NX pte 0xffff88201947a000-0xffff88201947c000 8K USR RW NX pte 0xffff88201947c000-0xffff882019482000 24K USR ro NX pte 0xffff882019482000-0xffff882019483000 4K USR RW NX pte 0xffff882019483000-0xffff882019486000 12K USR ro NX pte 0xffff882019486000-0xffff882019487000 4K USR RW NX pte 0xffff882019487000-0xffff88201948e000 28K USR ro NX pte 0xffff88201948e000-0xffff882019494000 24K USR RW NX pte 0xffff882019494000-0xffff882019495000 4K USR ro NX pte 0xffff882019495000-0xffff882019499000 16K USR RW NX pte 0xffff882019499000-0xffff88201949a000 4K USR ro NX pte 0xffff88201949a000-0xffff88201949d000 12K USR RW NX pte 0xffff88201949d000-0xffff88201949e000 4K USR ro NX pte 0xffff88201949e000-0xffff8820194a0000 8K USR RW NX pte 0xffff8820194a0000-0xffff8820194a1000 4K USR ro NX pte 0xffff8820194a1000-0xffff8820194ae000 52K USR RW NX pte 0xffff8820194ae000-0xffff8820194af000 4K USR ro NX pte 0xffff8820194af000-0xffff8820194b5000 24K USR RW NX pte 0xffff8820194b5000-0xffff8820194b6000 4K USR ro NX pte 0xffff8820194b6000-0xffff8820194b7000 4K USR RW NX pte 0xffff8820194b7000-0xffff8820194b9000 8K USR ro NX pte 0xffff8820194b9000-0xffff8820194bb000 8K USR RW NX pte 0xffff8820194bb000-0xffff8820194bc000 4K USR ro NX pte 0xffff8820194bc000-0xffff8820194bd000 4K USR RW NX pte 0xffff8820194bd000-0xffff8820194be000 4K USR ro NX pte 0xffff8820194be000-0xffff8820194f8000 232K USR RW NX pte 0xffff8820194f8000-0xffff8820194f9000 4K USR ro NX pte 0xffff8820194f9000-0xffff8820194ff000 24K USR RW NX pte 0xffff8820194ff000-0xffff882019500000 4K USR ro NX pte 0xffff882019500000-0xffff8820198be000 3832K USR RW NX pte 0xffff8820198be000-0xffff8820198c0000 8K USR ro NX pte 0xffff8820198c0000-0xffff8820198f7000 220K USR RW NX pte 0xffff8820198f7000-0xffff8820198f8000 4K USR ro NX pte 0xffff8820198f8000-0xffff882019bd8000 2944K USR RW NX pte 0xffff882019bd8000-0xffff882019be0000 32K USR ro NX pte 0xffff882019be0000-0xffff882019c06000 152K USR RW NX pte 0xffff882019c06000-0xffff882019c07000 4K USR ro NX pte 0xffff882019c07000-0xffff882019c0d000 24K USR RW NX pte 0xffff882019c0d000-0xffff882019c10000 12K USR ro NX pte 0xffff882019c10000-0xffff882019c13000 12K USR RW NX pte 0xffff882019c13000-0xffff882019c16000 12K USR ro NX pte 0xffff882019c16000-0xffff882019c17000 4K USR RW NX pte 0xffff882019c17000-0xffff882019c1f000 32K USR ro NX pte 0xffff882019c1f000-0xffff882019c20000 4K USR RW NX pte 0xffff882019c20000-0xffff882019c22000 8K USR ro NX pte 0xffff882019c22000-0xffff882019c25000 12K USR RW NX pte 0xffff882019c25000-0xffff882019c2f000 40K USR ro NX pte 0xffff882019c2f000-0xffff882019c3d000 56K USR RW NX pte 0xffff882019c3d000-0xffff882019c3e000 4K USR ro NX pte 0xffff882019c3e000-0xffff882019c40000 8K USR RW NX pte 0xffff882019c40000-0xffff882019c41000 4K USR ro NX pte 0xffff882019c41000-0xffff882019c49000 32K USR RW NX pte 0xffff882019c49000-0xffff882019c4b000 8K USR ro NX pte 0xffff882019c4b000-0xffff882019c4e000 12K USR RW NX pte 0xffff882019c4e000-0xffff882019c4f000 4K USR ro NX pte 0xffff882019c4f000-0xffff882019c50000 4K USR RW NX pte 0xffff882019c50000-0xffff882019c52000 8K USR ro NX pte 0xffff882019c52000-0xffff882019c58000 24K USR RW NX pte 0xffff882019c58000-0xffff882019c59000 4K USR ro NX pte 0xffff882019c59000-0xffff882019c64000 44K USR RW NX pte 0xffff882019c64000-0xffff882019c6b000 28K USR ro NX pte 0xffff882019c6b000-0xffff882019c6e000 12K USR RW NX pte 0xffff882019c6e000-0xffff882019c70000 8K USR ro NX pte 0xffff882019c70000-0xffff882019c72000 8K USR RW NX pte 0xffff882019c72000-0xffff882019c76000 16K USR ro NX pte 0xffff882019c76000-0xffff882019c82000 48K USR RW NX pte 0xffff882019c82000-0xffff882019c83000 4K USR ro NX pte 0xffff882019c83000-0xffff882019cc6000 268K USR RW NX pte 0xffff882019cc6000-0xffff882019cc8000 8K USR ro NX pte 0xffff882019cc8000-0xffff882019cf3000 172K USR RW NX pte 0xffff882019cf3000-0xffff882019cf4000 4K USR ro NX pte 0xffff882019cf4000-0xffff88201b000000 19504K USR RW NX pte 0xffff88201b000000-0xffff88201b006000 24K USR ro NX pte 0xffff88201b006000-0xffff88201b080000 488K USR RW NX pte 0xffff88201b080000-0xffff88201b083000 12K USR ro NX pte 0xffff88201b083000-0xffff88201b092000 60K USR RW NX pte 0xffff88201b092000-0xffff88201b093000 4K USR ro NX pte 0xffff88201b093000-0xffff88201b09c000 36K USR RW NX pte 0xffff88201b09c000-0xffff88201b09d000 4K USR ro NX pte 0xffff88201b09d000-0xffff88201b0ab000 56K USR RW NX pte 0xffff88201b0ab000-0xffff88201b0ac000 4K USR ro NX pte 0xffff88201b0ac000-0xffff88201b0c2000 88K USR RW NX pte 0xffff88201b0c2000-0xffff88201b0c3000 4K USR ro NX pte 0xffff88201b0c3000-0xffff88201b0d4000 68K USR RW NX pte 0xffff88201b0d4000-0xffff88201b0d5000 4K USR ro NX pte 0xffff88201b0d5000-0xffff88201b0e4000 60K USR RW NX pte 0xffff88201b0e4000-0xffff88201b0e5000 4K USR ro NX pte 0xffff88201b0e5000-0xffff88201b0e6000 4K USR RW NX pte 0xffff88201b0e6000-0xffff88201b0e7000 4K USR ro NX pte 0xffff88201b0e7000-0xffff88201b0eb000 16K USR RW NX pte 0xffff88201b0eb000-0xffff88201b0ec000 4K USR ro NX pte 0xffff88201b0ec000-0xffff88201b0f3000 28K USR RW NX pte 0xffff88201b0f3000-0xffff88201b0f4000 4K USR ro NX pte 0xffff88201b0f4000-0xffff88201b0f5000 4K USR RW NX pte 0xffff88201b0f5000-0xffff88201b0f6000 4K USR ro NX pte 0xffff88201b0f6000-0xffff88201b0fa000 16K USR RW NX pte 0xffff88201b0fa000-0xffff88201b0fc000 8K USR ro NX pte 0xffff88201b0fc000-0xffff88201cc9c000 28288K USR RW NX pte 0xffff88201cc9c000-0xffff88201cc9f000 12K USR ro NX pte 0xffff88201cc9f000-0xffff88201ccb7000 96K USR RW NX pte 0xffff88201ccb7000-0xffff88201ccb8000 4K USR ro NX pte 0xffff88201ccb8000-0xffff88201ccb9000 4K USR RW NX pte 0xffff88201ccb9000-0xffff88201ccba000 4K USR ro NX pte 0xffff88201ccba000-0xffff88201ccc6000 48K USR RW NX pte 0xffff88201ccc6000-0xffff88201ccc7000 4K USR ro NX pte 0xffff88201ccc7000-0xffff88201cce8000 132K USR RW NX pte 0xffff88201cce8000-0xffff88201cce9000 4K USR ro NX pte 0xffff88201cce9000-0xffff88201ccea000 4K USR RW NX pte 0xffff88201ccea000-0xffff88201cceb000 4K USR ro NX pte 0xffff88201cceb000-0xffff88201ccf5000 40K USR RW NX pte 0xffff88201ccf5000-0xffff88201ccf6000 4K USR ro NX pte 0xffff88201ccf6000-0xffff882021184000 70200K USR RW NX pte 0xffff882021184000-0xffff882021185000 4K USR ro NX pte 0xffff882021185000-0xffff882021186000 4K USR RW NX pte 0xffff882021186000-0xffff882021188000 8K USR ro NX pte 0xffff882021188000-0xffff882021195000 52K USR RW NX pte 0xffff882021195000-0xffff882021196000 4K USR ro NX pte 0xffff882021196000-0xffff88202119f000 36K USR RW NX pte 0xffff88202119f000-0xffff8820211a0000 4K USR ro NX pte 0xffff8820211a0000-0xffff8820211d1000 196K USR RW NX pte 0xffff8820211d1000-0xffff8820211d3000 8K USR ro NX pte 0xffff8820211d3000-0xffff8820211f8000 148K USR RW NX pte 0xffff8820211f8000-0xffff8820211f9000 4K USR ro NX pte 0xffff8820211f9000-0xffff8820211fa000 4K USR RW NX pte 0xffff8820211fa000-0xffff8820211fb000 4K USR ro NX pte 0xffff8820211fb000-0xffff8820211fd000 8K USR RW NX pte 0xffff8820211fd000-0xffff8820211fe000 4K USR ro NX pte 0xffff8820211fe000-0xffff882021360000 1416K USR RW NX pte 0xffff882021360000-0xffff882021361000 4K USR ro NX pte 0xffff882021361000-0xffff882021362000 4K USR RW NX pte 0xffff882021362000-0xffff882021363000 4K USR ro NX pte 0xffff882021363000-0xffff882021397000 208K USR RW NX pte 0xffff882021397000-0xffff882021398000 4K USR ro NX pte 0xffff882021398000-0xffff8820213a2000 40K USR RW NX pte 0xffff8820213a2000-0xffff8820213a3000 4K USR ro NX pte 0xffff8820213a3000-0xffff8820213ab000 32K USR RW NX pte 0xffff8820213ab000-0xffff8820213ac000 4K USR ro NX pte 0xffff8820213ac000-0xffff8820213bb000 60K USR RW NX pte 0xffff8820213bb000-0xffff8820213be000 12K USR ro NX pte 0xffff8820213be000-0xffff8820213bf000 4K USR RW NX pte 0xffff8820213bf000-0xffff8820213c0000 4K USR ro NX pte 0xffff8820213c0000-0xffff8820213c1000 4K USR RW NX pte 0xffff8820213c1000-0xffff8820213c2000 4K USR ro NX pte 0xffff8820213c2000-0xffff8820213c3000 4K USR RW NX pte 0xffff8820213c3000-0xffff8820213c4000 4K USR ro NX pte 0xffff8820213c4000-0xffff8820213c5000 4K USR RW NX pte 0xffff8820213c5000-0xffff8820213c6000 4K USR ro NX pte 0xffff8820213c6000-0xffff8820213c7000 4K USR RW NX pte 0xffff8820213c7000-0xffff8820213c8000 4K USR ro NX pte 0xffff8820213c8000-0xffff8820213c9000 4K USR RW NX pte 0xffff8820213c9000-0xffff8820213cb000 8K USR ro NX pte 0xffff8820213cb000-0xffff8820213cf000 16K USR RW NX pte 0xffff8820213cf000-0xffff8820213d0000 4K USR ro NX pte 0xffff8820213d0000-0xffff8820213d3000 12K USR RW NX pte 0xffff8820213d3000-0xffff8820213d4000 4K USR ro NX pte 0xffff8820213d4000-0xffff8820213d5000 4K USR RW NX pte 0xffff8820213d5000-0xffff8820213d6000 4K USR ro NX pte 0xffff8820213d6000-0xffff8820213db000 20K USR RW NX pte 0xffff8820213db000-0xffff8820213dc000 4K USR ro NX pte 0xffff8820213dc000-0xffff8820213dd000 4K USR RW NX pte 0xffff8820213dd000-0xffff8820213df000 8K USR ro NX pte 0xffff8820213df000-0xffff8820213e7000 32K USR RW NX pte 0xffff8820213e7000-0xffff8820213e8000 4K USR ro NX pte 0xffff8820213e8000-0xffff8820213f6000 56K USR RW NX pte 0xffff8820213f6000-0xffff8820213f7000 4K USR ro NX pte 0xffff8820213f7000-0xffff8820213fd000 24K USR RW NX pte 0xffff8820213fd000-0xffff8820213fe000 4K USR ro NX pte 0xffff8820213fe000-0xffff882021816000 4192K USR RW NX pte 0xffff882021816000-0xffff882021817000 4K USR ro NX pte 0xffff882021817000-0xffff882021826000 60K USR RW NX pte 0xffff882021826000-0xffff882021829000 12K USR ro NX pte 0xffff882021829000-0xffff88202182d000 16K USR RW NX pte 0xffff88202182d000-0xffff88202182e000 4K USR ro NX pte 0xffff88202182e000-0xffff882021840000 72K USR RW NX pte 0xffff882021840000-0xffff882021842000 8K USR ro NX pte 0xffff882021842000-0xffff882021843000 4K USR RW NX pte 0xffff882021843000-0xffff882021844000 4K USR ro NX pte 0xffff882021844000-0xffff882021846000 8K USR RW NX pte 0xffff882021846000-0xffff88202184a000 16K USR ro NX pte 0xffff88202184a000-0xffff88202184b000 4K USR RW NX pte 0xffff88202184b000-0xffff882021850000 20K USR ro NX pte 0xffff882021850000-0xffff882021859000 36K USR RW NX pte 0xffff882021859000-0xffff88202185b000 8K USR ro NX pte 0xffff88202185b000-0xffff882021861000 24K USR RW NX pte 0xffff882021861000-0xffff882021866000 20K USR ro NX pte 0xffff882021866000-0xffff882021867000 4K USR RW NX pte 0xffff882021867000-0xffff882021868000 4K USR ro NX pte 0xffff882021868000-0xffff88202186b000 12K USR RW NX pte 0xffff88202186b000-0xffff88202186c000 4K USR ro NX pte 0xffff88202186c000-0xffff88202188a000 120K USR RW NX pte 0xffff88202188a000-0xffff88202188b000 4K USR ro NX pte 0xffff88202188b000-0xffff882021891000 24K USR RW NX pte 0xffff882021891000-0xffff882021892000 4K USR ro NX pte 0xffff882021892000-0xffff8820218b2000 128K USR RW NX pte 0xffff8820218b2000-0xffff8820218b3000 4K USR ro NX pte 0xffff8820218b3000-0xffff8820218ee000 236K USR RW NX pte 0xffff8820218ee000-0xffff8820218ef000 4K USR ro NX pte 0xffff8820218ef000-0xffff8820218fa000 44K USR RW NX pte 0xffff8820218fa000-0xffff8820218fb000 4K USR ro NX pte 0xffff8820218fb000-0xffff882021b1f000 2192K USR RW NX pte 0xffff882021b1f000-0xffff882021b20000 4K USR ro NX pte 0xffff882021b20000-0xffff882021b33000 76K USR RW NX pte 0xffff882021b33000-0xffff882021b34000 4K USR ro NX pte 0xffff882021b34000-0xffff882021b3c000 32K USR RW NX pte 0xffff882021b3c000-0xffff882021b3d000 4K USR ro NX pte 0xffff882021b3d000-0xffff882021b68000 172K USR RW NX pte 0xffff882021b68000-0xffff882021b69000 4K USR ro NX pte 0xffff882021b69000-0xffff882021b77000 56K USR RW NX pte 0xffff882021b77000-0xffff882021b78000 4K USR ro NX pte 0xffff882021b78000-0xffff882021b84000 48K USR RW NX pte 0xffff882021b84000-0xffff882021b85000 4K USR ro NX pte 0xffff882021b85000-0xffff882021baf000 168K USR RW NX pte 0xffff882021baf000-0xffff882021bb0000 4K USR ro NX pte 0xffff882021bb0000-0xffff882021bcf000 124K USR RW NX pte 0xffff882021bcf000-0xffff882021bd0000 4K USR ro NX pte 0xffff882021bd0000-0xffff882021be2000 72K USR RW NX pte 0xffff882021be2000-0xffff882021be4000 8K USR ro NX pte 0xffff882021be4000-0xffff8820243d9000 40916K USR RW NX pte 0xffff8820243d9000-0xffff8820243dc000 12K USR ro NX pte 0xffff8820243dc000-0xffff8820243e1000 20K USR RW NX pte 0xffff8820243e1000-0xffff8820243e2000 4K USR ro NX pte 0xffff8820243e2000-0xffff882028dde000 75760K USR RW NX pte 0xffff882028dde000-0xffff882028ddf000 4K USR ro NX pte 0xffff882028ddf000-0xffff882028fe0000 2052K USR RW NX pte 0xffff882028fe0000-0xffff882028fe1000 4K USR ro NX pte 0xffff882028fe1000-0xffff8820292d8000 3036K USR RW NX pte 0xffff8820292d8000-0xffff8820292dc000 16K USR ro NX pte 0xffff8820292dc000-0xffff8820293dd000 1028K USR RW NX pte 0xffff8820293dd000-0xffff8820293de000 4K USR ro NX pte 0xffff8820293de000-0xffff882029ac4000 7064K USR RW NX pte 0xffff882029ac4000-0xffff882029ac6000 8K USR ro NX pte 0xffff882029ac6000-0xffff882029d5f000 2660K USR RW NX pte 0xffff882029d5f000-0xffff882029d9e000 252K USR ro NX pte 0xffff882029d9e000-0xffff882031c9e000 127M USR RW NX pte 0xffff882031c9e000-0xffff882031d1e000 512K USR ro NX pte 0xffff882031d1e000-0xffff882031d5e000 256K USR RW NX pte 0xffff882031d5e000-0xffff882031d5f000 4K USR ro NX pte 0xffff882031d5f000-0xffff882032658000 9188K USR RW NX pte 0xffff882032658000-0xffff882032800000 1696K USR ro NX pte 0xffff882032800000-0xffff8820b509b000 2138732K USR RW NX pte 0xffff8820b509b000-0xffff8820b509e000 12K USR ro NX pte 0xffff8820b509e000-0xffff8820b5600000 5512K USR RW NX pte 0xffff8820b5600000-0xffff8820b57f0000 1984K USR ro NX pte 0xffff8820b57f0000-0xffff8820b5fa9000 7908K USR RW NX pte 0xffff8820b5fa9000-0xffff8820b5faa000 4K USR ro NX pte 0xffff8820b5faa000-0xffff8820b5fc2000 96K USR RW NX pte 0xffff8820b5fc2000-0xffff8820b5fc6000 16K USR ro NX pte 0xffff8820b5fc6000-0xffff8820b7000000 16616K USR RW NX pte 0xffff8820b7000000-0xffff8820b7800000 8M pte 0xffff8820b7800000-0xffff8820c0000000 136M pmd 0xffff8820c0000000-0xffff888000000000 381G pud 0xffff888000000000-0xffffc90000000000 66048G pgd ---[ vmalloc() Area ]--- 0xffffc90000000000-0xffffc90010000000 256M USR RW NX pte 0xffffc90010000000-0xffffc90010001000 4K pte 0xffffc90010001000-0xffffc90010081000 512K USR RW NX pte 0xffffc90010081000-0xffffc90010082000 4K pte 0xffffc90010082000-0xffffc90018082000 128M USR RW NX pte 0xffffc90018082000-0xffffc90018083000 4K pte 0xffffc90018083000-0xffffc900180c3000 256K USR RW NX pte 0xffffc900180c3000-0xffffc900180c4000 4K pte 0xffffc900180c4000-0xffffc900180c6000 8K USR RW NX pte 0xffffc900180c6000-0xffffc900180c8000 8K pte 0xffffc900180c8000-0xffffc900180c9000 4K USR RW NX pte 0xffffc900180c9000-0xffffc900180cd000 16K pte 0xffffc900180cd000-0xffffc900180d1000 16K USR RW NX pte 0xffffc900180d1000-0xffffc900180d2000 4K pte 0xffffc900180d2000-0xffffc900180dd000 44K USR RW NX pte 0xffffc900180dd000-0xffffc900180de000 4K pte 0xffffc900180de000-0xffffc900180ea000 48K USR RW NX pte 0xffffc900180ea000-0xffffc90018100000 88K pte 0xffffc90018100000-0xffffc90018101000 4K USR RW NX pte 0xffffc90018101000-0xffffc90018121000 128K pte 0xffffc90018121000-0xffffc90018521000 4M USR RW NX pte 0xffffc90018521000-0xffffc90018522000 4K pte 0xffffc90018522000-0xffffc90018d22000 8M USR RW NX pte 0xffffc90018d22000-0xffffc90018d23000 4K pte 0xffffc90018d23000-0xffffc90018e23000 1M USR RW NX pte 0xffffc90018e23000-0xffffc90018e24000 4K pte 0xffffc90018e24000-0xffffc90019024000 2M USR RW NX pte 0xffffc90019024000-0xffffc90019025000 4K pte 0xffffc90019025000-0xffffc90019225000 2M USR RW NX pte 0xffffc90019225000-0xffffc90019600000 3948K pte 0xffffc90019600000-0xffffc90040000000 618M pmd 0xffffc90040000000-0xffffc98000000000 511G pud 0xffffc98000000000-0xffffea0000000000 33280G pgd ---[ Vmemmap ]--- 0xffffea0000000000-0xffffea0072840000 1876224K USR RW NX pte 0xffffea0072840000-0xffffea0072a00000 1792K pte 0xffffea0072a00000-0xffffea0080000000 214M pmd 0xffffea0080000000-0xffffea8000000000 510G pud 0xffffea8000000000-0xffffff8000000000 21T pgd 0xffffff8000000000-0xffffffff80000000 510G pud ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff81002000 8K USR ro x pte 0xffffffff81002000-0xffffffff81013000 68K USR ro x pte 0xffffffff81013000-0xffffffff81015000 8K USR ro x pte 0xffffffff81015000-0xffffffff81017000 8K USR ro x pte 0xffffffff81017000-0xffffffff81019000 8K USR ro x pte 0xffffffff81019000-0xffffffff8101a000 4K USR ro x pte 0xffffffff8101a000-0xffffffff8101b000 4K USR ro x pte 0xffffffff8101b000-0xffffffff8101f000 16K USR ro x pte 0xffffffff8101f000-0xffffffff81028000 36K USR ro x pte 0xffffffff81028000-0xffffffff8102a000 8K USR ro x pte 0xffffffff8102a000-0xffffffff8102c000 8K USR ro x pte 0xffffffff8102c000-0xffffffff8103c000 64K USR ro x pte 0xffffffff8103c000-0xffffffff8103d000 4K USR ro x pte 0xffffffff8103d000-0xffffffff81051000 80K USR ro x pte 0xffffffff81051000-0xffffffff81052000 4K USR ro x pte 0xffffffff81052000-0xffffffff81057000 20K USR ro x pte 0xffffffff81057000-0xffffffff81058000 4K USR ro x pte 0xffffffff81058000-0xffffffff81061000 36K USR ro x pte 0xffffffff81061000-0xffffffff81063000 8K USR ro x pte 0xffffffff81063000-0xffffffff8106b000 32K USR ro x pte 0xffffffff8106b000-0xffffffff8106c000 4K USR ro x pte 0xffffffff8106c000-0xffffffff81078000 48K USR ro x pte 0xffffffff81078000-0xffffffff8107a000 8K USR ro x pte 0xffffffff8107a000-0xffffffff81083000 36K USR ro x pte 0xffffffff81083000-0xffffffff81084000 4K USR ro x pte 0xffffffff81084000-0xffffffff8108f000 44K USR ro x pte 0xffffffff8108f000-0xffffffff81090000 4K USR ro x pte 0xffffffff81090000-0xffffffff81094000 16K USR ro x pte 0xffffffff81094000-0xffffffff81097000 12K USR ro x pte 0xffffffff81097000-0xffffffff810a0000 36K USR ro x pte 0xffffffff810a0000-0xffffffff810a2000 8K USR ro x pte 0xffffffff810a2000-0xffffffff810a7000 20K USR ro x pte 0xffffffff810a7000-0xffffffff810a8000 4K USR ro x pte 0xffffffff810a8000-0xffffffff810aa000 8K USR ro x pte 0xffffffff810aa000-0xffffffff810af000 20K USR ro x pte 0xffffffff810af000-0xffffffff810b4000 20K USR ro x pte 0xffffffff810b4000-0xffffffff810b6000 8K USR ro x pte 0xffffffff810b6000-0xffffffff810c0000 40K USR ro x pte 0xffffffff810c0000-0xffffffff810c4000 16K USR ro x pte 0xffffffff810c4000-0xffffffff810c6000 8K USR ro x pte 0xffffffff810c6000-0xffffffff810ca000 16K USR ro x pte 0xffffffff810ca000-0xffffffff810cc000 8K USR ro x pte 0xffffffff810cc000-0xffffffff810cd000 4K USR ro x pte 0xffffffff810cd000-0xffffffff810d5000 32K USR ro x pte 0xffffffff810d5000-0xffffffff810d9000 16K USR ro x pte 0xffffffff810d9000-0xffffffff810da000 4K USR ro x pte 0xffffffff810da000-0xffffffff810db000 4K USR ro x pte 0xffffffff810db000-0xffffffff810dc000 4K USR ro x pte 0xffffffff810dc000-0xffffffff810dd000 4K USR ro x pte 0xffffffff810dd000-0xffffffff810e2000 20K USR ro x pte 0xffffffff810e2000-0xffffffff810e3000 4K USR ro x pte 0xffffffff810e3000-0xffffffff810f8000 84K USR ro x pte 0xffffffff810f8000-0xffffffff810fb000 12K USR ro x pte 0xffffffff810fb000-0xffffffff81101000 24K USR ro x pte 0xffffffff81101000-0xffffffff81102000 4K USR ro x pte 0xffffffff81102000-0xffffffff81106000 16K USR ro x pte 0xffffffff81106000-0xffffffff81107000 4K USR ro x pte 0xffffffff81107000-0xffffffff81108000 4K USR ro x pte 0xffffffff81108000-0xffffffff81109000 4K USR ro x pte 0xffffffff81109000-0xffffffff81113000 40K USR ro x pte 0xffffffff81113000-0xffffffff81114000 4K USR ro x pte 0xffffffff81114000-0xffffffff81117000 12K USR ro x pte 0xffffffff81117000-0xffffffff81118000 4K USR ro x pte 0xffffffff81118000-0xffffffff81122000 40K USR ro x pte 0xffffffff81122000-0xffffffff81124000 8K USR ro x pte 0xffffffff81124000-0xffffffff81143000 124K USR ro x pte 0xffffffff81143000-0xffffffff81145000 8K USR ro x pte 0xffffffff81145000-0xffffffff81166000 132K USR ro x pte 0xffffffff81166000-0xffffffff81168000 8K USR ro x pte 0xffffffff81168000-0xffffffff8116d000 20K USR ro x pte 0xffffffff8116d000-0xffffffff8116e000 4K USR ro x pte 0xffffffff8116e000-0xffffffff8116f000 4K USR ro x pte 0xffffffff8116f000-0xffffffff81170000 4K USR ro x pte 0xffffffff81170000-0xffffffff81174000 16K USR ro x pte 0xffffffff81174000-0xffffffff81177000 12K USR ro x pte 0xffffffff81177000-0xffffffff8117a000 12K USR ro x pte 0xffffffff8117a000-0xffffffff8117e000 16K USR ro x pte 0xffffffff8117e000-0xffffffff8118d000 60K USR ro x pte 0xffffffff8118d000-0xffffffff8118e000 4K USR ro x pte 0xffffffff8118e000-0xffffffff81190000 8K USR ro x pte 0xffffffff81190000-0xffffffff81191000 4K USR ro x pte 0xffffffff81191000-0xffffffff81192000 4K USR ro x pte 0xffffffff81192000-0xffffffff81193000 4K USR ro x pte 0xffffffff81193000-0xffffffff81194000 4K USR ro x pte 0xffffffff81194000-0xffffffff81197000 12K USR ro x pte 0xffffffff81197000-0xffffffff81198000 4K USR ro x pte 0xffffffff81198000-0xffffffff81199000 4K USR ro x pte 0xffffffff81199000-0xffffffff811a0000 28K USR ro x pte 0xffffffff811a0000-0xffffffff811a1000 4K USR ro x pte 0xffffffff811a1000-0xffffffff811ab000 40K USR ro x pte 0xffffffff811ab000-0xffffffff811ac000 4K USR ro x pte 0xffffffff811ac000-0xffffffff811af000 12K USR ro x pte 0xffffffff811af000-0xffffffff811b1000 8K USR ro x pte 0xffffffff811b1000-0xffffffff811b4000 12K USR ro x pte 0xffffffff811b4000-0xffffffff811b5000 4K USR ro x pte 0xffffffff811b5000-0xffffffff811b9000 16K USR ro x pte 0xffffffff811b9000-0xffffffff811bb000 8K USR ro x pte 0xffffffff811bb000-0xffffffff811bd000 8K USR ro x pte 0xffffffff811bd000-0xffffffff811be000 4K USR ro x pte 0xffffffff811be000-0xffffffff811c2000 16K USR ro x pte 0xffffffff811c2000-0xffffffff811c6000 16K USR ro x pte 0xffffffff811c6000-0xffffffff811c7000 4K USR ro x pte 0xffffffff811c7000-0xffffffff811c8000 4K USR ro x pte 0xffffffff811c8000-0xffffffff811c9000 4K USR ro x pte 0xffffffff811c9000-0xffffffff811ca000 4K USR ro x pte 0xffffffff811ca000-0xffffffff811cf000 20K USR ro x pte 0xffffffff811cf000-0xffffffff811d0000 4K USR ro x pte 0xffffffff811d0000-0xffffffff811d3000 12K USR ro x pte 0xffffffff811d3000-0xffffffff811d5000 8K USR ro x pte 0xffffffff811d5000-0xffffffff811d6000 4K USR ro x pte 0xffffffff811d6000-0xffffffff811d8000 8K USR ro x pte 0xffffffff811d8000-0xffffffff811d9000 4K USR ro x pte 0xffffffff811d9000-0xffffffff811da000 4K USR ro x pte 0xffffffff811da000-0xffffffff811e0000 24K USR ro x pte 0xffffffff811e0000-0xffffffff811e3000 12K USR ro x pte 0xffffffff811e3000-0xffffffff811e9000 24K USR ro x pte 0xffffffff811e9000-0xffffffff811ea000 4K USR ro x pte 0xffffffff811ea000-0xffffffff811eb000 4K USR ro x pte 0xffffffff811eb000-0xffffffff811f1000 24K USR ro x pte 0xffffffff811f1000-0xffffffff811f7000 24K USR ro x pte 0xffffffff811f7000-0xffffffff811f8000 4K USR ro x pte 0xffffffff811f8000-0xffffffff811fa000 8K USR ro x pte 0xffffffff811fa000-0xffffffff811fb000 4K USR ro x pte 0xffffffff811fb000-0xffffffff811fd000 8K USR ro x pte 0xffffffff811fd000-0xffffffff811fe000 4K USR ro x pte 0xffffffff811fe000-0xffffffff81200000 8K USR ro x pte 0xffffffff81200000-0xffffffff81201000 4K USR ro x pte 0xffffffff81201000-0xffffffff81203000 8K USR ro x pte 0xffffffff81203000-0xffffffff81207000 16K USR ro x pte 0xffffffff81207000-0xffffffff81209000 8K USR ro x pte 0xffffffff81209000-0xffffffff8120a000 4K USR ro x pte 0xffffffff8120a000-0xffffffff8120b000 4K USR ro x pte 0xffffffff8120b000-0xffffffff8120c000 4K USR ro x pte 0xffffffff8120c000-0xffffffff8120e000 8K USR ro x pte 0xffffffff8120e000-0xffffffff81223000 84K USR ro x pte 0xffffffff81223000-0xffffffff81228000 20K USR ro x pte 0xffffffff81228000-0xffffffff81229000 4K USR ro x pte 0xffffffff81229000-0xffffffff8123b000 72K USR ro x pte 0xffffffff8123b000-0xffffffff8123d000 8K USR ro x pte 0xffffffff8123d000-0xffffffff8123e000 4K USR ro x pte 0xffffffff8123e000-0xffffffff8123f000 4K USR ro x pte 0xffffffff8123f000-0xffffffff81242000 12K USR ro x pte 0xffffffff81242000-0xffffffff81244000 8K USR ro x pte 0xffffffff81244000-0xffffffff81245000 4K USR ro x pte 0xffffffff81245000-0xffffffff81247000 8K USR ro x pte 0xffffffff81247000-0xffffffff81248000 4K USR ro x pte 0xffffffff81248000-0xffffffff81252000 40K USR ro x pte 0xffffffff81252000-0xffffffff81253000 4K USR ro x pte 0xffffffff81253000-0xffffffff81254000 4K USR ro x pte 0xffffffff81254000-0xffffffff81255000 4K USR ro x pte 0xffffffff81255000-0xffffffff81258000 12K USR ro x pte 0xffffffff81258000-0xffffffff81259000 4K USR ro x pte 0xffffffff81259000-0xffffffff81268000 60K USR ro x pte 0xffffffff81268000-0xffffffff8126e000 24K USR ro x pte 0xffffffff8126e000-0xffffffff8126f000 4K USR ro x pte 0xffffffff8126f000-0xffffffff81272000 12K USR ro x pte 0xffffffff81272000-0xffffffff81273000 4K USR ro x pte 0xffffffff81273000-0xffffffff81274000 4K USR ro x pte 0xffffffff81274000-0xffffffff8127a000 24K USR ro x pte 0xffffffff8127a000-0xffffffff8127c000 8K USR ro x pte 0xffffffff8127c000-0xffffffff8127d000 4K USR ro x pte 0xffffffff8127d000-0xffffffff81285000 32K USR ro x pte 0xffffffff81285000-0xffffffff81286000 4K USR ro x pte 0xffffffff81286000-0xffffffff81287000 4K USR ro x pte 0xffffffff81287000-0xffffffff81288000 4K USR ro x pte 0xffffffff81288000-0xffffffff81289000 4K USR ro x pte 0xffffffff81289000-0xffffffff8128d000 16K USR ro x pte 0xffffffff8128d000-0xffffffff8128f000 8K USR ro x pte 0xffffffff8128f000-0xffffffff81291000 8K USR ro x pte 0xffffffff81291000-0xffffffff81292000 4K USR ro x pte 0xffffffff81292000-0xffffffff8129f000 52K USR ro x pte 0xffffffff8129f000-0xffffffff812a0000 4K USR ro x pte 0xffffffff812a0000-0xffffffff812a1000 4K USR ro x pte 0xffffffff812a1000-0xffffffff812a3000 8K USR ro x pte 0xffffffff812a3000-0xffffffff812a5000 8K USR ro x pte 0xffffffff812a5000-0xffffffff812a6000 4K USR ro x pte 0xffffffff812a6000-0xffffffff812a9000 12K USR ro x pte 0xffffffff812a9000-0xffffffff812ab000 8K USR ro x pte 0xffffffff812ab000-0xffffffff812c3000 96K USR ro x pte 0xffffffff812c3000-0xffffffff812c6000 12K USR ro x pte 0xffffffff812c6000-0xffffffff812cc000 24K USR ro x pte 0xffffffff812cc000-0xffffffff812cf000 12K USR ro x pte 0xffffffff812cf000-0xffffffff812d1000 8K USR ro x pte 0xffffffff812d1000-0xffffffff812d2000 4K USR ro x pte 0xffffffff812d2000-0xffffffff812d3000 4K USR ro x pte 0xffffffff812d3000-0xffffffff812d7000 16K USR ro x pte 0xffffffff812d7000-0xffffffff812d8000 4K USR ro x pte 0xffffffff812d8000-0xffffffff812da000 8K USR ro x pte 0xffffffff812da000-0xffffffff812dc000 8K USR ro x pte 0xffffffff812dc000-0xffffffff812e1000 20K USR ro x pte 0xffffffff812e1000-0xffffffff812e3000 8K USR ro x pte 0xffffffff812e3000-0xffffffff812e4000 4K USR ro x pte 0xffffffff812e4000-0xffffffff812e5000 4K USR ro x pte 0xffffffff812e5000-0xffffffff812e6000 4K USR ro x pte 0xffffffff812e6000-0xffffffff812e7000 4K USR ro x pte 0xffffffff812e7000-0xffffffff812ed000 24K USR ro x pte 0xffffffff812ed000-0xffffffff812ee000 4K USR ro x pte 0xffffffff812ee000-0xffffffff812f9000 44K USR ro x pte 0xffffffff812f9000-0xffffffff812fa000 4K USR ro x pte 0xffffffff812fa000-0xffffffff812fe000 16K USR ro x pte 0xffffffff812fe000-0xffffffff81300000 8K USR ro x pte 0xffffffff81300000-0xffffffff81302000 8K USR ro x pte 0xffffffff81302000-0xffffffff8130d000 44K USR ro x pte 0xffffffff8130d000-0xffffffff8130e000 4K USR ro x pte 0xffffffff8130e000-0xffffffff8130f000 4K USR ro x pte 0xffffffff8130f000-0xffffffff81312000 12K USR ro x pte 0xffffffff81312000-0xffffffff81314000 8K USR ro x pte 0xffffffff81314000-0xffffffff81318000 16K USR ro x pte 0xffffffff81318000-0xffffffff8131b000 12K USR ro x pte 0xffffffff8131b000-0xffffffff8131c000 4K USR ro x pte 0xffffffff8131c000-0xffffffff81324000 32K USR ro x pte 0xffffffff81324000-0xffffffff81329000 20K USR ro x pte 0xffffffff81329000-0xffffffff8132d000 16K USR ro x pte 0xffffffff8132d000-0xffffffff8132e000 4K USR ro x pte 0xffffffff8132e000-0xffffffff8132f000 4K USR ro x pte 0xffffffff8132f000-0xffffffff81332000 12K USR ro x pte 0xffffffff81332000-0xffffffff81333000 4K USR ro x pte 0xffffffff81333000-0xffffffff81334000 4K USR ro x pte 0xffffffff81334000-0xffffffff81335000 4K USR ro x pte 0xffffffff81335000-0xffffffff81337000 8K USR ro x pte 0xffffffff81337000-0xffffffff8133b000 16K USR ro x pte 0xffffffff8133b000-0xffffffff8133c000 4K USR ro x pte 0xffffffff8133c000-0xffffffff81340000 16K USR ro x pte 0xffffffff81340000-0xffffffff81342000 8K USR ro x pte 0xffffffff81342000-0xffffffff81343000 4K USR ro x pte 0xffffffff81343000-0xffffffff81348000 20K USR ro x pte 0xffffffff81348000-0xffffffff8134c000 16K USR ro x pte 0xffffffff8134c000-0xffffffff81350000 16K USR ro x pte 0xffffffff81350000-0xffffffff81351000 4K USR ro x pte 0xffffffff81351000-0xffffffff81353000 8K USR ro x pte 0xffffffff81353000-0xffffffff81358000 20K USR ro x pte 0xffffffff81358000-0xffffffff8135e000 24K USR ro x pte 0xffffffff8135e000-0xffffffff8135f000 4K USR ro x pte 0xffffffff8135f000-0xffffffff81361000 8K USR ro x pte 0xffffffff81361000-0xffffffff81366000 20K USR ro x pte 0xffffffff81366000-0xffffffff81367000 4K USR ro x pte 0xffffffff81367000-0xffffffff81368000 4K USR ro x pte 0xffffffff81368000-0xffffffff8136a000 8K USR ro x pte 0xffffffff8136a000-0xffffffff81374000 40K USR ro x pte 0xffffffff81374000-0xffffffff81376000 8K USR ro x pte 0xffffffff81376000-0xffffffff81379000 12K USR ro x pte 0xffffffff81379000-0xffffffff8137f000 24K USR ro x pte 0xffffffff8137f000-0xffffffff81380000 4K USR ro x pte 0xffffffff81380000-0xffffffff81383000 12K USR ro x pte 0xffffffff81383000-0xffffffff81384000 4K USR ro x pte 0xffffffff81384000-0xffffffff81387000 12K USR ro x pte 0xffffffff81387000-0xffffffff81389000 8K USR ro x pte 0xffffffff81389000-0xffffffff8138c000 12K USR ro x pte 0xffffffff8138c000-0xffffffff81393000 28K USR ro x pte 0xffffffff81393000-0xffffffff81395000 8K USR ro x pte 0xffffffff81395000-0xffffffff81398000 12K USR ro x pte 0xffffffff81398000-0xffffffff8139a000 8K USR ro x pte 0xffffffff8139a000-0xffffffff8139c000 8K USR ro x pte 0xffffffff8139c000-0xffffffff8139d000 4K USR ro x pte 0xffffffff8139d000-0xffffffff813a3000 24K USR ro x pte 0xffffffff813a3000-0xffffffff813a4000 4K USR ro x pte 0xffffffff813a4000-0xffffffff813a5000 4K USR ro x pte 0xffffffff813a5000-0xffffffff813a6000 4K USR ro x pte 0xffffffff813a6000-0xffffffff813a9000 12K USR ro x pte 0xffffffff813a9000-0xffffffff813ab000 8K USR ro x pte 0xffffffff813ab000-0xffffffff813ac000 4K USR ro x pte 0xffffffff813ac000-0xffffffff813ae000 8K USR ro x pte 0xffffffff813ae000-0xffffffff813b1000 12K USR ro x pte 0xffffffff813b1000-0xffffffff813b3000 8K USR ro x pte 0xffffffff813b3000-0xffffffff813b5000 8K USR ro x pte 0xffffffff813b5000-0xffffffff813b9000 16K USR ro x pte 0xffffffff813b9000-0xffffffff813ba000 4K USR ro x pte 0xffffffff813ba000-0xffffffff813bf000 20K USR ro x pte 0xffffffff813bf000-0xffffffff813ce000 60K USR ro x pte 0xffffffff813ce000-0xffffffff813cf000 4K USR ro x pte 0xffffffff813cf000-0xffffffff813d0000 4K USR ro x pte 0xffffffff813d0000-0xffffffff813d2000 8K USR ro x pte 0xffffffff813d2000-0xffffffff813d3000 4K USR ro x pte 0xffffffff813d3000-0xffffffff813db000 32K USR ro x pte 0xffffffff813db000-0xffffffff813dc000 4K USR ro x pte 0xffffffff813dc000-0xffffffff813dd000 4K USR ro x pte 0xffffffff813dd000-0xffffffff813de000 4K USR ro x pte 0xffffffff813de000-0xffffffff813e0000 8K USR ro x pte 0xffffffff813e0000-0xffffffff813e3000 12K USR ro x pte 0xffffffff813e3000-0xffffffff813e5000 8K USR ro x pte 0xffffffff813e5000-0xffffffff813e8000 12K USR ro x pte 0xffffffff813e8000-0xffffffff813ea000 8K USR ro x pte 0xffffffff813ea000-0xffffffff813ec000 8K USR ro x pte 0xffffffff813ec000-0xffffffff813ed000 4K USR ro x pte 0xffffffff813ed000-0xffffffff813ef000 8K USR ro x pte 0xffffffff813ef000-0xffffffff813f3000 16K USR ro x pte 0xffffffff813f3000-0xffffffff813f4000 4K USR ro x pte 0xffffffff813f4000-0xffffffff813f6000 8K USR ro x pte 0xffffffff813f6000-0xffffffff813f7000 4K USR ro x pte 0xffffffff813f7000-0xffffffff813fa000 12K USR ro x pte 0xffffffff813fa000-0xffffffff813fb000 4K USR ro x pte 0xffffffff813fb000-0xffffffff813fd000 8K USR ro x pte 0xffffffff813fd000-0xffffffff813fe000 4K USR ro x pte 0xffffffff813fe000-0xffffffff81403000 20K USR ro x pte 0xffffffff81403000-0xffffffff81404000 4K USR ro x pte 0xffffffff81404000-0xffffffff81406000 8K USR ro x pte 0xffffffff81406000-0xffffffff81408000 8K USR ro x pte 0xffffffff81408000-0xffffffff81411000 36K USR ro x pte 0xffffffff81411000-0xffffffff81412000 4K USR ro x pte 0xffffffff81412000-0xffffffff81413000 4K USR ro x pte 0xffffffff81413000-0xffffffff81415000 8K USR ro x pte 0xffffffff81415000-0xffffffff81416000 4K USR ro x pte 0xffffffff81416000-0xffffffff81419000 12K USR ro x pte 0xffffffff81419000-0xffffffff8141e000 20K USR ro x pte 0xffffffff8141e000-0xffffffff81425000 28K USR ro x pte 0xffffffff81425000-0xffffffff81426000 4K USR ro x pte 0xffffffff81426000-0xffffffff81428000 8K USR ro x pte 0xffffffff81428000-0xffffffff8142f000 28K USR ro x pte 0xffffffff8142f000-0xffffffff81430000 4K USR ro x pte 0xffffffff81430000-0xffffffff81437000 28K USR ro x pte 0xffffffff81437000-0xffffffff81438000 4K USR ro x pte 0xffffffff81438000-0xffffffff81439000 4K USR ro x pte 0xffffffff81439000-0xffffffff8143d000 16K USR ro x pte 0xffffffff8143d000-0xffffffff8143e000 4K USR ro x pte 0xffffffff8143e000-0xffffffff8143f000 4K USR ro x pte 0xffffffff8143f000-0xffffffff81440000 4K USR ro x pte 0xffffffff81440000-0xffffffff81443000 12K USR ro x pte 0xffffffff81443000-0xffffffff81445000 8K USR ro x pte 0xffffffff81445000-0xffffffff81446000 4K USR ro x pte 0xffffffff81446000-0xffffffff81448000 8K USR ro x pte 0xffffffff81448000-0xffffffff8144d000 20K USR ro x pte 0xffffffff8144d000-0xffffffff8144f000 8K USR ro x pte 0xffffffff8144f000-0xffffffff81451000 8K USR ro x pte 0xffffffff81451000-0xffffffff81452000 4K USR ro x pte 0xffffffff81452000-0xffffffff81458000 24K USR ro x pte 0xffffffff81458000-0xffffffff81459000 4K USR ro x pte 0xffffffff81459000-0xffffffff8145a000 4K USR ro x pte 0xffffffff8145a000-0xffffffff8145c000 8K USR ro x pte 0xffffffff8145c000-0xffffffff8145d000 4K USR ro x pte 0xffffffff8145d000-0xffffffff81462000 20K USR ro x pte 0xffffffff81462000-0xffffffff81463000 4K USR ro x pte 0xffffffff81463000-0xffffffff81464000 4K USR ro x pte 0xffffffff81464000-0xffffffff81465000 4K USR ro x pte 0xffffffff81465000-0xffffffff81467000 8K USR ro x pte 0xffffffff81467000-0xffffffff81468000 4K USR ro x pte 0xffffffff81468000-0xffffffff81469000 4K USR ro x pte 0xffffffff81469000-0xffffffff8146a000 4K USR ro x pte 0xffffffff8146a000-0xffffffff8146b000 4K USR ro x pte 0xffffffff8146b000-0xffffffff81470000 20K USR ro x pte 0xffffffff81470000-0xffffffff81471000 4K USR ro x pte 0xffffffff81471000-0xffffffff81473000 8K USR ro x pte 0xffffffff81473000-0xffffffff81477000 16K USR ro x pte 0xffffffff81477000-0xffffffff8147a000 12K USR ro x pte 0xffffffff8147a000-0xffffffff8147b000 4K USR ro x pte 0xffffffff8147b000-0xffffffff8147c000 4K USR ro x pte 0xffffffff8147c000-0xffffffff8147d000 4K USR ro x pte 0xffffffff8147d000-0xffffffff81482000 20K USR ro x pte 0xffffffff81482000-0xffffffff81484000 8K USR ro x pte 0xffffffff81484000-0xffffffff81485000 4K USR ro x pte 0xffffffff81485000-0xffffffff81486000 4K USR ro x pte 0xffffffff81486000-0xffffffff81489000 12K USR ro x pte 0xffffffff81489000-0xffffffff8148a000 4K USR ro x pte 0xffffffff8148a000-0xffffffff8148b000 4K USR ro x pte 0xffffffff8148b000-0xffffffff8148c000 4K USR ro x pte 0xffffffff8148c000-0xffffffff81499000 52K USR ro x pte 0xffffffff81499000-0xffffffff8149a000 4K USR ro x pte 0xffffffff8149a000-0xffffffff814a2000 32K USR ro x pte 0xffffffff814a2000-0xffffffff814a5000 12K USR ro x pte 0xffffffff814a5000-0xffffffff814a8000 12K USR ro x pte 0xffffffff814a8000-0xffffffff814b0000 32K USR ro x pte 0xffffffff814b0000-0xffffffff814b1000 4K USR ro x pte 0xffffffff814b1000-0xffffffff814b2000 4K USR ro x pte 0xffffffff814b2000-0xffffffff814c2000 64K USR ro x pte 0xffffffff814c2000-0xffffffff814c3000 4K USR ro x pte 0xffffffff814c3000-0xffffffff814c5000 8K USR ro x pte 0xffffffff814c5000-0xffffffff814cb000 24K USR ro x pte 0xffffffff814cb000-0xffffffff814cc000 4K USR ro x pte 0xffffffff814cc000-0xffffffff814cf000 12K USR ro x pte 0xffffffff814cf000-0xffffffff814d0000 4K USR ro x pte 0xffffffff814d0000-0xffffffff814d1000 4K USR ro x pte 0xffffffff814d1000-0xffffffff814d3000 8K USR ro x pte 0xffffffff814d3000-0xffffffff814d4000 4K USR ro x pte 0xffffffff814d4000-0xffffffff814d6000 8K USR ro x pte 0xffffffff814d6000-0xffffffff814d7000 4K USR ro x pte 0xffffffff814d7000-0xffffffff814db000 16K USR ro x pte 0xffffffff814db000-0xffffffff814dc000 4K USR ro x pte 0xffffffff814dc000-0xffffffff814de000 8K USR ro x pte 0xffffffff814de000-0xffffffff814df000 4K USR ro x pte 0xffffffff814df000-0xffffffff814e3000 16K USR ro x pte 0xffffffff814e3000-0xffffffff814e7000 16K USR ro x pte 0xffffffff814e7000-0xffffffff814e8000 4K USR ro x pte 0xffffffff814e8000-0xffffffff814e9000 4K USR ro x pte 0xffffffff814e9000-0xffffffff814f1000 32K USR ro x pte 0xffffffff814f1000-0xffffffff814f2000 4K USR ro x pte 0xffffffff814f2000-0xffffffff814f6000 16K USR ro x pte 0xffffffff814f6000-0xffffffff814f7000 4K USR ro x pte 0xffffffff814f7000-0xffffffff814f8000 4K USR ro x pte 0xffffffff814f8000-0xffffffff814f9000 4K USR ro x pte 0xffffffff814f9000-0xffffffff814fe000 20K USR ro x pte 0xffffffff814fe000-0xffffffff81503000 20K USR ro x pte 0xffffffff81503000-0xffffffff81508000 20K USR ro x pte 0xffffffff81508000-0xffffffff8150d000 20K USR ro x pte 0xffffffff8150d000-0xffffffff81511000 16K USR ro x pte 0xffffffff81511000-0xffffffff81513000 8K USR ro x pte 0xffffffff81513000-0xffffffff81514000 4K USR ro x pte 0xffffffff81514000-0xffffffff81515000 4K USR ro x pte 0xffffffff81515000-0xffffffff81516000 4K USR ro x pte 0xffffffff81516000-0xffffffff8151b000 20K USR ro x pte 0xffffffff8151b000-0xffffffff81520000 20K USR ro x pte 0xffffffff81520000-0xffffffff81521000 4K USR ro x pte 0xffffffff81521000-0xffffffff81523000 8K USR ro x pte 0xffffffff81523000-0xffffffff81525000 8K USR ro x pte 0xffffffff81525000-0xffffffff81526000 4K USR ro x pte 0xffffffff81526000-0xffffffff81529000 12K USR ro x pte 0xffffffff81529000-0xffffffff8152a000 4K USR ro x pte 0xffffffff8152a000-0xffffffff8152b000 4K USR ro x pte 0xffffffff8152b000-0xffffffff8152e000 12K USR ro x pte 0xffffffff8152e000-0xffffffff81533000 20K USR ro x pte 0xffffffff81533000-0xffffffff81535000 8K USR ro x pte 0xffffffff81535000-0xffffffff81537000 8K USR ro x pte 0xffffffff81537000-0xffffffff81538000 4K USR ro x pte 0xffffffff81538000-0xffffffff81539000 4K USR ro x pte 0xffffffff81539000-0xffffffff8153b000 8K USR ro x pte 0xffffffff8153b000-0xffffffff8153d000 8K USR ro x pte 0xffffffff8153d000-0xffffffff81541000 16K USR ro x pte 0xffffffff81541000-0xffffffff81542000 4K USR ro x pte 0xffffffff81542000-0xffffffff81544000 8K USR ro x pte 0xffffffff81544000-0xffffffff81545000 4K USR ro x pte 0xffffffff81545000-0xffffffff81547000 8K USR ro x pte 0xffffffff81547000-0xffffffff81551000 40K USR ro x pte 0xffffffff81551000-0xffffffff81552000 4K USR ro x pte 0xffffffff81552000-0xffffffff81554000 8K USR ro x pte 0xffffffff81554000-0xffffffff81555000 4K USR ro x pte 0xffffffff81555000-0xffffffff8155d000 32K USR ro x pte 0xffffffff8155d000-0xffffffff8155f000 8K USR ro x pte 0xffffffff8155f000-0xffffffff81563000 16K USR ro x pte 0xffffffff81563000-0xffffffff81566000 12K USR ro x pte 0xffffffff81566000-0xffffffff81567000 4K USR ro x pte 0xffffffff81567000-0xffffffff81568000 4K USR ro x pte 0xffffffff81568000-0xffffffff8156a000 8K USR ro x pte 0xffffffff8156a000-0xffffffff8156b000 4K USR ro x pte 0xffffffff8156b000-0xffffffff81572000 28K USR ro x pte 0xffffffff81572000-0xffffffff81573000 4K USR ro x pte 0xffffffff81573000-0xffffffff81576000 12K USR ro x pte 0xffffffff81576000-0xffffffff81577000 4K USR ro x pte 0xffffffff81577000-0xffffffff81578000 4K USR ro x pte 0xffffffff81578000-0xffffffff81579000 4K USR ro x pte 0xffffffff81579000-0xffffffff8157a000 4K USR ro x pte 0xffffffff8157a000-0xffffffff8157b000 4K USR ro x pte 0xffffffff8157b000-0xffffffff8157d000 8K USR ro x pte 0xffffffff8157d000-0xffffffff8157f000 8K USR ro x pte 0xffffffff8157f000-0xffffffff81582000 12K USR ro x pte 0xffffffff81582000-0xffffffff81584000 8K USR ro x pte 0xffffffff81584000-0xffffffff81586000 8K USR ro x pte 0xffffffff81586000-0xffffffff81588000 8K USR ro x pte 0xffffffff81588000-0xffffffff81589000 4K USR ro x pte 0xffffffff81589000-0xffffffff8158d000 16K USR ro x pte 0xffffffff8158d000-0xffffffff8158f000 8K USR ro x pte 0xffffffff8158f000-0xffffffff81593000 16K USR ro x pte 0xffffffff81593000-0xffffffff81594000 4K USR ro x pte 0xffffffff81594000-0xffffffff81595000 4K USR ro x pte 0xffffffff81595000-0xffffffff81596000 4K USR ro x pte 0xffffffff81596000-0xffffffff81599000 12K USR ro x pte 0xffffffff81599000-0xffffffff815ab000 72K USR ro x pte 0xffffffff815ab000-0xffffffff815ac000 4K USR ro x pte 0xffffffff815ac000-0xffffffff815b0000 16K USR ro x pte 0xffffffff815b0000-0xffffffff815b1000 4K USR ro x pte 0xffffffff815b1000-0xffffffff815b7000 24K USR ro x pte 0xffffffff815b7000-0xffffffff81600000 292K USR RW NX pte 0xffffffff81600000-0xffffffff8179c000 1648K USR ro NX pte 0xffffffff8179c000-0xffffffff81800000 400K USR RW NX pte 0xffffffff81800000-0xffffffff81802000 8K USR RW x pte 0xffffffff81802000-0xffffffff81803000 4K USR RW x pte 0xffffffff81803000-0xffffffff81805000 8K USR RW x pte 0xffffffff81805000-0xffffffff8180b000 24K USR RW x pte 0xffffffff8180b000-0xffffffff8180f000 16K USR ro x pte 0xffffffff8180f000-0xffffffff81810000 4K USR RW x pte 0xffffffff81810000-0xffffffff81812000 8K USR ro x pte 0xffffffff81812000-0xffffffff81813000 4K USR RW x pte 0xffffffff81813000-0xffffffff81815000 8K USR RW x pte 0xffffffff81815000-0xffffffff81816000 4K USR RW x pte 0xffffffff81816000-0xffffffff81818000 8K USR RW x pte 0xffffffff81818000-0xffffffff8181a000 8K USR RW x pte 0xffffffff8181a000-0xffffffff8181d000 12K USR RW x pte 0xffffffff8181d000-0xffffffff8181e000 4K USR RW x pte 0xffffffff8181e000-0xffffffff81832000 80K USR RW x pte 0xffffffff81832000-0xffffffff81834000 8K USR RW x pte 0xffffffff81834000-0xffffffff8183a000 24K USR RW x pte 0xffffffff8183a000-0xffffffff8183d000 12K USR RW x pte 0xffffffff8183d000-0xffffffff81841000 16K USR RW x pte 0xffffffff81841000-0xffffffff81843000 8K USR RW x pte 0xffffffff81843000-0xffffffff81845000 8K USR RW x pte 0xffffffff81845000-0xffffffff81846000 4K USR RW x pte 0xffffffff81846000-0xffffffff81849000 12K USR RW x pte 0xffffffff81849000-0xffffffff8184a000 4K USR RW x pte 0xffffffff8184a000-0xffffffff8184f000 20K USR RW x pte 0xffffffff8184f000-0xffffffff81850000 4K USR RW x pte 0xffffffff81850000-0xffffffff81885000 212K USR RW x pte 0xffffffff81885000-0xffffffff81938000 716K USR RW NX pte 0xffffffff81938000-0xffffffff8193a000 8K USR RW x pte 0xffffffff8193a000-0xffffffff8193b000 4K USR ro x pte 0xffffffff8193b000-0xffffffff8193d000 8K USR RW x pte 0xffffffff8193d000-0xffffffff8193e000 4K USR ro x pte 0xffffffff8193e000-0xffffffff81948000 40K USR RW x pte 0xffffffff81948000-0xffffffff8194a000 8K USR RW x pte 0xffffffff8194a000-0xffffffff8194c000 8K USR RW x pte 0xffffffff8194c000-0xffffffff8196c000 128K USR RW x pte 0xffffffff8196c000-0xffffffff8196d000 4K USR RW x pte 0xffffffff8196d000-0xffffffff81970000 12K USR RW x pte 0xffffffff81970000-0xffffffff81971000 4K USR RW x pte 0xffffffff81971000-0xffffffff81972000 4K USR RW x pte 0xffffffff81972000-0xffffffff81973000 4K USR RW x pte 0xffffffff81973000-0xffffffff81975000 8K USR RW x pte 0xffffffff81975000-0xffffffff81976000 4K USR RW x pte 0xffffffff81976000-0xffffffff81977000 4K USR RW x pte 0xffffffff81977000-0xffffffff8197b000 16K USR RW x pte 0xffffffff8197b000-0xffffffff819b9000 248K USR RW x pte 0xffffffff819b9000-0xffffffff819c0000 28K USR RW x pte 0xffffffff819c0000-0xffffffff819df000 124K USR RW x pte 0xffffffff819df000-0xffffffff819e8000 36K USR RW x pte 0xffffffff819e8000-0xffffffff819f1000 36K USR RW x pte 0xffffffff819f1000-0xffffffff819f2000 4K USR RW x pte 0xffffffff819f2000-0xffffffff819f3000 4K USR RW x pte 0xffffffff819f3000-0xffffffff819f5000 8K USR RW x pte 0xffffffff819f5000-0xffffffff819f8000 12K USR RW x pte 0xffffffff819f8000-0xffffffff81a0a000 72K USR RW x pte 0xffffffff81a0a000-0xffffffff81a0f000 20K USR RW x pte 0xffffffff81a0f000-0xffffffff81a1c000 52K USR RW x pte 0xffffffff81a1c000-0xffffffff81a1d000 4K USR RW x pte 0xffffffff81a1d000-0xffffffff81aaa000 564K USR RW x pte 0xffffffff81aaa000-0xffffffff81aae000 16K USR ro x pte 0xffffffff81aae000-0xffffffff81b34000 536K USR RW x pte 0xffffffff81b34000-0xffffffff81c00000 816K USR RW x pte 0xffffffff81c00000-0xffffffff8fc00000 224M pmd 0xffffffff8fc00000-0xffffffff8fc93000 588K USR RW NX pte 0xffffffff8fc93000-0xffffffffa0000000 265652K USR RW x pte ---[ Modules ]--- 0xffffffffa0000000-0xffffffffa0001000 4K USR ro x pte 0xffffffffa0001000-0xffffffffa0002000 4K USR ro NX pte 0xffffffffa0002000-0xffffffffa0004000 8K USR RW NX pte 0xffffffffa0004000-0xffffffffa0008000 16K pte 0xffffffffa0008000-0xffffffffa0009000 4K USR ro x pte 0xffffffffa0009000-0xffffffffa000a000 4K USR ro NX pte 0xffffffffa000a000-0xffffffffa000c000 8K USR RW NX pte 0xffffffffa000c000-0xffffffffa0070000 400K pte 0xffffffffa0070000-0xffffffffa024c000 1904K USR RW x pte 0xffffffffa024c000-0xffffffffa024e000 8K USR RW x pte 0xffffffffa024e000-0xffffffffa0353000 1044K USR ro x pte 0xffffffffa0353000-0xffffffffa0400000 692K USR RW x pte 0xffffffffa0400000-0xffffffffc0000000 508M pmd 0xffffffffc0000000-0xffffffffc009b000 620K USR RW x pte 0xffffffffc009b000-0xffffffffc00a0000 20K USR RW x pte 0xffffffffc00a0000-0xffffffffc07fb000 7532K USR RW x pte 0xffffffffc07fb000-0xffffffffc0ef8000 7156K USR ro x pte 0xffffffffc0ef8000-0xffffffffc1000000 1056K USR RW x pte 0xffffffffc1000000-0xffffffffc1002000 8K USR ro x pte 0xffffffffc1002000-0xffffffffc1013000 68K USR ro x pte 0xffffffffc1013000-0xffffffffc1015000 8K USR ro x pte 0xffffffffc1015000-0xffffffffc1017000 8K USR ro x pte 0xffffffffc1017000-0xffffffffc1019000 8K USR ro x pte 0xffffffffc1019000-0xffffffffc101a000 4K USR ro x pte 0xffffffffc101a000-0xffffffffc101b000 4K USR ro x pte 0xffffffffc101b000-0xffffffffc101f000 16K USR ro x pte 0xffffffffc101f000-0xffffffffc1028000 36K USR ro x pte 0xffffffffc1028000-0xffffffffc102a000 8K USR ro x pte 0xffffffffc102a000-0xffffffffc102c000 8K USR ro x pte 0xffffffffc102c000-0xffffffffc103c000 64K USR ro x pte 0xffffffffc103c000-0xffffffffc103d000 4K USR ro x pte 0xffffffffc103d000-0xffffffffc1051000 80K USR ro x pte 0xffffffffc1051000-0xffffffffc1052000 4K USR ro x pte 0xffffffffc1052000-0xffffffffc1057000 20K USR ro x pte 0xffffffffc1057000-0xffffffffc1058000 4K USR ro x pte 0xffffffffc1058000-0xffffffffc1061000 36K USR ro x pte 0xffffffffc1061000-0xffffffffc1063000 8K USR ro x pte 0xffffffffc1063000-0xffffffffc106b000 32K USR ro x pte 0xffffffffc106b000-0xffffffffc106c000 4K USR ro x pte 0xffffffffc106c000-0xffffffffc1078000 48K USR ro x pte 0xffffffffc1078000-0xffffffffc107a000 8K USR ro x pte 0xffffffffc107a000-0xffffffffc1083000 36K USR ro x pte 0xffffffffc1083000-0xffffffffc1084000 4K USR ro x pte 0xffffffffc1084000-0xffffffffc108f000 44K USR ro x pte 0xffffffffc108f000-0xffffffffc1090000 4K USR ro x pte 0xffffffffc1090000-0xffffffffc1094000 16K USR ro x pte 0xffffffffc1094000-0xffffffffc1097000 12K USR ro x pte 0xffffffffc1097000-0xffffffffc10a0000 36K USR ro x pte 0xffffffffc10a0000-0xffffffffc10a2000 8K USR ro x pte 0xffffffffc10a2000-0xffffffffc10a7000 20K USR ro x pte 0xffffffffc10a7000-0xffffffffc10a8000 4K USR ro x pte 0xffffffffc10a8000-0xffffffffc10aa000 8K USR ro x pte 0xffffffffc10aa000-0xffffffffc10af000 20K USR ro x pte 0xffffffffc10af000-0xffffffffc10b4000 20K USR ro x pte 0xffffffffc10b4000-0xffffffffc10b6000 8K USR ro x pte 0xffffffffc10b6000-0xffffffffc10c0000 40K USR ro x pte 0xffffffffc10c0000-0xffffffffc10c4000 16K USR ro x pte 0xffffffffc10c4000-0xffffffffc10c6000 8K USR ro x pte 0xffffffffc10c6000-0xffffffffc10ca000 16K USR ro x pte 0xffffffffc10ca000-0xffffffffc10cc000 8K USR ro x pte 0xffffffffc10cc000-0xffffffffc10cd000 4K USR ro x pte 0xffffffffc10cd000-0xffffffffc10d5000 32K USR ro x pte 0xffffffffc10d5000-0xffffffffc10d9000 16K USR ro x pte 0xffffffffc10d9000-0xffffffffc10da000 4K USR ro x pte 0xffffffffc10da000-0xffffffffc10db000 4K USR ro x pte 0xffffffffc10db000-0xffffffffc10dc000 4K USR ro x pte 0xffffffffc10dc000-0xffffffffc10dd000 4K USR ro x pte 0xffffffffc10dd000-0xffffffffc10e2000 20K USR ro x pte 0xffffffffc10e2000-0xffffffffc10e3000 4K USR ro x pte 0xffffffffc10e3000-0xffffffffc10f8000 84K USR ro x pte 0xffffffffc10f8000-0xffffffffc10fb000 12K USR ro x pte 0xffffffffc10fb000-0xffffffffc1101000 24K USR ro x pte 0xffffffffc1101000-0xffffffffc1102000 4K USR ro x pte 0xffffffffc1102000-0xffffffffc1106000 16K USR ro x pte 0xffffffffc1106000-0xffffffffc1107000 4K USR ro x pte 0xffffffffc1107000-0xffffffffc1108000 4K USR ro x pte 0xffffffffc1108000-0xffffffffc1109000 4K USR ro x pte 0xffffffffc1109000-0xffffffffc1113000 40K USR ro x pte 0xffffffffc1113000-0xffffffffc1114000 4K USR ro x pte 0xffffffffc1114000-0xffffffffc1117000 12K USR ro x pte 0xffffffffc1117000-0xffffffffc1118000 4K USR ro x pte 0xffffffffc1118000-0xffffffffc1122000 40K USR ro x pte 0xffffffffc1122000-0xffffffffc1124000 8K USR ro x pte 0xffffffffc1124000-0xffffffffc1143000 124K USR ro x pte 0xffffffffc1143000-0xffffffffc1145000 8K USR ro x pte 0xffffffffc1145000-0xffffffffc1166000 132K USR ro x pte 0xffffffffc1166000-0xffffffffc1168000 8K USR ro x pte 0xffffffffc1168000-0xffffffffc116d000 20K USR ro x pte 0xffffffffc116d000-0xffffffffc116e000 4K USR ro x pte 0xffffffffc116e000-0xffffffffc116f000 4K USR ro x pte 0xffffffffc116f000-0xffffffffc1170000 4K USR ro x pte 0xffffffffc1170000-0xffffffffc1174000 16K USR ro x pte 0xffffffffc1174000-0xffffffffc1177000 12K USR ro x pte 0xffffffffc1177000-0xffffffffc117a000 12K USR ro x pte 0xffffffffc117a000-0xffffffffc117e000 16K USR ro x pte 0xffffffffc117e000-0xffffffffc118d000 60K USR ro x pte 0xffffffffc118d000-0xffffffffc118e000 4K USR ro x pte 0xffffffffc118e000-0xffffffffc1190000 8K USR ro x pte 0xffffffffc1190000-0xffffffffc1191000 4K USR ro x pte 0xffffffffc1191000-0xffffffffc1192000 4K USR ro x pte 0xffffffffc1192000-0xffffffffc1193000 4K USR ro x pte 0xffffffffc1193000-0xffffffffc1194000 4K USR ro x pte 0xffffffffc1194000-0xffffffffc1197000 12K USR ro x pte 0xffffffffc1197000-0xffffffffc1198000 4K USR ro x pte 0xffffffffc1198000-0xffffffffc1199000 4K USR ro x pte 0xffffffffc1199000-0xffffffffc11a0000 28K USR ro x pte 0xffffffffc11a0000-0xffffffffc11a1000 4K USR ro x pte 0xffffffffc11a1000-0xffffffffc11ab000 40K USR ro x pte 0xffffffffc11ab000-0xffffffffc11ac000 4K USR ro x pte 0xffffffffc11ac000-0xffffffffc11af000 12K USR ro x pte 0xffffffffc11af000-0xffffffffc11b1000 8K USR ro x pte 0xffffffffc11b1000-0xffffffffc11b4000 12K USR ro x pte 0xffffffffc11b4000-0xffffffffc11b5000 4K USR ro x pte 0xffffffffc11b5000-0xffffffffc11b9000 16K USR ro x pte 0xffffffffc11b9000-0xffffffffc11bb000 8K USR ro x pte 0xffffffffc11bb000-0xffffffffc11bd000 8K USR ro x pte 0xffffffffc11bd000-0xffffffffc11be000 4K USR ro x pte 0xffffffffc11be000-0xffffffffc11c2000 16K USR ro x pte 0xffffffffc11c2000-0xffffffffc11c6000 16K USR ro x pte 0xffffffffc11c6000-0xffffffffc11c7000 4K USR ro x pte 0xffffffffc11c7000-0xffffffffc11c8000 4K USR ro x pte 0xffffffffc11c8000-0xffffffffc11c9000 4K USR ro x pte 0xffffffffc11c9000-0xffffffffc11ca000 4K USR ro x pte 0xffffffffc11ca000-0xffffffffc11cf000 20K USR ro x pte 0xffffffffc11cf000-0xffffffffc11d0000 4K USR ro x pte 0xffffffffc11d0000-0xffffffffc11d3000 12K USR ro x pte 0xffffffffc11d3000-0xffffffffc11d5000 8K USR ro x pte 0xffffffffc11d5000-0xffffffffc11d6000 4K USR ro x pte 0xffffffffc11d6000-0xffffffffc11d8000 8K USR ro x pte 0xffffffffc11d8000-0xffffffffc11d9000 4K USR ro x pte 0xffffffffc11d9000-0xffffffffc11da000 4K USR ro x pte 0xffffffffc11da000-0xffffffffc11e0000 24K USR ro x pte 0xffffffffc11e0000-0xffffffffc11e3000 12K USR ro x pte 0xffffffffc11e3000-0xffffffffc11e9000 24K USR ro x pte 0xffffffffc11e9000-0xffffffffc11ea000 4K USR ro x pte 0xffffffffc11ea000-0xffffffffc11eb000 4K USR ro x pte 0xffffffffc11eb000-0xffffffffc11f1000 24K USR ro x pte 0xffffffffc11f1000-0xffffffffc11f7000 24K USR ro x pte 0xffffffffc11f7000-0xffffffffc11f8000 4K USR ro x pte 0xffffffffc11f8000-0xffffffffc11fa000 8K USR ro x pte 0xffffffffc11fa000-0xffffffffc11fb000 4K USR ro x pte 0xffffffffc11fb000-0xffffffffc11fd000 8K USR ro x pte 0xffffffffc11fd000-0xffffffffc11fe000 4K USR ro x pte 0xffffffffc11fe000-0xffffffffc1200000 8K USR ro x pte 0xffffffffc1200000-0xffffffffc1201000 4K USR ro x pte 0xffffffffc1201000-0xffffffffc1203000 8K USR ro x pte 0xffffffffc1203000-0xffffffffc1207000 16K USR ro x pte 0xffffffffc1207000-0xffffffffc1209000 8K USR ro x pte 0xffffffffc1209000-0xffffffffc120a000 4K USR ro x pte 0xffffffffc120a000-0xffffffffc120b000 4K USR ro x pte 0xffffffffc120b000-0xffffffffc120c000 4K USR ro x pte 0xffffffffc120c000-0xffffffffc120e000 8K USR ro x pte 0xffffffffc120e000-0xffffffffc1223000 84K USR ro x pte 0xffffffffc1223000-0xffffffffc1228000 20K USR ro x pte 0xffffffffc1228000-0xffffffffc1229000 4K USR ro x pte 0xffffffffc1229000-0xffffffffc123b000 72K USR ro x pte 0xffffffffc123b000-0xffffffffc123d000 8K USR ro x pte 0xffffffffc123d000-0xffffffffc123e000 4K USR ro x pte 0xffffffffc123e000-0xffffffffc123f000 4K USR ro x pte 0xffffffffc123f000-0xffffffffc1242000 12K USR ro x pte 0xffffffffc1242000-0xffffffffc1244000 8K USR ro x pte 0xffffffffc1244000-0xffffffffc1245000 4K USR ro x pte 0xffffffffc1245000-0xffffffffc1247000 8K USR ro x pte 0xffffffffc1247000-0xffffffffc1248000 4K USR ro x pte 0xffffffffc1248000-0xffffffffc1252000 40K USR ro x pte 0xffffffffc1252000-0xffffffffc1253000 4K USR ro x pte 0xffffffffc1253000-0xffffffffc1254000 4K USR ro x pte 0xffffffffc1254000-0xffffffffc1255000 4K USR ro x pte 0xffffffffc1255000-0xffffffffc1258000 12K USR ro x pte 0xffffffffc1258000-0xffffffffc1259000 4K USR ro x pte 0xffffffffc1259000-0xffffffffc1268000 60K USR ro x pte 0xffffffffc1268000-0xffffffffc126e000 24K USR ro x pte 0xffffffffc126e000-0xffffffffc126f000 4K USR ro x pte 0xffffffffc126f000-0xffffffffc1272000 12K USR ro x pte 0xffffffffc1272000-0xffffffffc1273000 4K USR ro x pte 0xffffffffc1273000-0xffffffffc1274000 4K USR ro x pte 0xffffffffc1274000-0xffffffffc127a000 24K USR ro x pte 0xffffffffc127a000-0xffffffffc127c000 8K USR ro x pte 0xffffffffc127c000-0xffffffffc127d000 4K USR ro x pte 0xffffffffc127d000-0xffffffffc1285000 32K USR ro x pte 0xffffffffc1285000-0xffffffffc1286000 4K USR ro x pte 0xffffffffc1286000-0xffffffffc1287000 4K USR ro x pte 0xffffffffc1287000-0xffffffffc1288000 4K USR ro x pte 0xffffffffc1288000-0xffffffffc1289000 4K USR ro x pte 0xffffffffc1289000-0xffffffffc128d000 16K USR ro x pte 0xffffffffc128d000-0xffffffffc128f000 8K USR ro x pte 0xffffffffc128f000-0xffffffffc1291000 8K USR ro x pte 0xffffffffc1291000-0xffffffffc1292000 4K USR ro x pte 0xffffffffc1292000-0xffffffffc129f000 52K USR ro x pte 0xffffffffc129f000-0xffffffffc12a0000 4K USR ro x pte 0xffffffffc12a0000-0xffffffffc12a1000 4K USR ro x pte 0xffffffffc12a1000-0xffffffffc12a3000 8K USR ro x pte 0xffffffffc12a3000-0xffffffffc12a5000 8K USR ro x pte 0xffffffffc12a5000-0xffffffffc12a6000 4K USR ro x pte 0xffffffffc12a6000-0xffffffffc12a9000 12K USR ro x pte 0xffffffffc12a9000-0xffffffffc12ab000 8K USR ro x pte 0xffffffffc12ab000-0xffffffffc12c3000 96K USR ro x pte 0xffffffffc12c3000-0xffffffffc12c6000 12K USR ro x pte 0xffffffffc12c6000-0xffffffffc12cc000 24K USR ro x pte 0xffffffffc12cc000-0xffffffffc12cf000 12K USR ro x pte 0xffffffffc12cf000-0xffffffffc12d1000 8K USR ro x pte 0xffffffffc12d1000-0xffffffffc12d2000 4K USR ro x pte 0xffffffffc12d2000-0xffffffffc12d3000 4K USR ro x pte 0xffffffffc12d3000-0xffffffffc12d7000 16K USR ro x pte 0xffffffffc12d7000-0xffffffffc12d8000 4K USR ro x pte 0xffffffffc12d8000-0xffffffffc12da000 8K USR ro x pte 0xffffffffc12da000-0xffffffffc12dc000 8K USR ro x pte 0xffffffffc12dc000-0xffffffffc12e1000 20K USR ro x pte 0xffffffffc12e1000-0xffffffffc12e3000 8K USR ro x pte 0xffffffffc12e3000-0xffffffffc12e4000 4K USR ro x pte 0xffffffffc12e4000-0xffffffffc12e5000 4K USR ro x pte 0xffffffffc12e5000-0xffffffffc12e6000 4K USR ro x pte 0xffffffffc12e6000-0xffffffffc12e7000 4K USR ro x pte 0xffffffffc12e7000-0xffffffffc12ed000 24K USR ro x pte 0xffffffffc12ed000-0xffffffffc12ee000 4K USR ro x pte 0xffffffffc12ee000-0xffffffffc12f9000 44K USR ro x pte 0xffffffffc12f9000-0xffffffffc12fa000 4K USR ro x pte 0xffffffffc12fa000-0xffffffffc12fe000 16K USR ro x pte 0xffffffffc12fe000-0xffffffffc1300000 8K USR ro x pte 0xffffffffc1300000-0xffffffffc1302000 8K USR ro x pte 0xffffffffc1302000-0xffffffffc130d000 44K USR ro x pte 0xffffffffc130d000-0xffffffffc130e000 4K USR ro x pte 0xffffffffc130e000-0xffffffffc130f000 4K USR ro x pte 0xffffffffc130f000-0xffffffffc1312000 12K USR ro x pte 0xffffffffc1312000-0xffffffffc1314000 8K USR ro x pte 0xffffffffc1314000-0xffffffffc1318000 16K USR ro x pte 0xffffffffc1318000-0xffffffffc131b000 12K USR ro x pte 0xffffffffc131b000-0xffffffffc131c000 4K USR ro x pte 0xffffffffc131c000-0xffffffffc1324000 32K USR ro x pte 0xffffffffc1324000-0xffffffffc1329000 20K USR ro x pte 0xffffffffc1329000-0xffffffffc132d000 16K USR ro x pte 0xffffffffc132d000-0xffffffffc132e000 4K USR ro x pte 0xffffffffc132e000-0xffffffffc132f000 4K USR ro x pte 0xffffffffc132f000-0xffffffffc1332000 12K USR ro x pte 0xffffffffc1332000-0xffffffffc1333000 4K USR ro x pte 0xffffffffc1333000-0xffffffffc1334000 4K USR ro x pte 0xffffffffc1334000-0xffffffffc1335000 4K USR ro x pte 0xffffffffc1335000-0xffffffffc1337000 8K USR ro x pte 0xffffffffc1337000-0xffffffffc133b000 16K USR ro x pte 0xffffffffc133b000-0xffffffffc133c000 4K USR ro x pte 0xffffffffc133c000-0xffffffffc1340000 16K USR ro x pte 0xffffffffc1340000-0xffffffffc1342000 8K USR ro x pte 0xffffffffc1342000-0xffffffffc1343000 4K USR ro x pte 0xffffffffc1343000-0xffffffffc1348000 20K USR ro x pte 0xffffffffc1348000-0xffffffffc134c000 16K USR ro x pte 0xffffffffc134c000-0xffffffffc1350000 16K USR ro x pte 0xffffffffc1350000-0xffffffffc1351000 4K USR ro x pte 0xffffffffc1351000-0xffffffffc1353000 8K USR ro x pte 0xffffffffc1353000-0xffffffffc1358000 20K USR ro x pte 0xffffffffc1358000-0xffffffffc135e000 24K USR ro x pte 0xffffffffc135e000-0xffffffffc135f000 4K USR ro x pte 0xffffffffc135f000-0xffffffffc1361000 8K USR ro x pte 0xffffffffc1361000-0xffffffffc1366000 20K USR ro x pte 0xffffffffc1366000-0xffffffffc1367000 4K USR ro x pte 0xffffffffc1367000-0xffffffffc1368000 4K USR ro x pte 0xffffffffc1368000-0xffffffffc136a000 8K USR ro x pte 0xffffffffc136a000-0xffffffffc1374000 40K USR ro x pte 0xffffffffc1374000-0xffffffffc1376000 8K USR ro x pte 0xffffffffc1376000-0xffffffffc1379000 12K USR ro x pte 0xffffffffc1379000-0xffffffffc137f000 24K USR ro x pte 0xffffffffc137f000-0xffffffffc1380000 4K USR ro x pte 0xffffffffc1380000-0xffffffffc1383000 12K USR ro x pte 0xffffffffc1383000-0xffffffffc1384000 4K USR ro x pte 0xffffffffc1384000-0xffffffffc1387000 12K USR ro x pte 0xffffffffc1387000-0xffffffffc1389000 8K USR ro x pte 0xffffffffc1389000-0xffffffffc138c000 12K USR ro x pte 0xffffffffc138c000-0xffffffffc1393000 28K USR ro x pte 0xffffffffc1393000-0xffffffffc1395000 8K USR ro x pte 0xffffffffc1395000-0xffffffffc1398000 12K USR ro x pte 0xffffffffc1398000-0xffffffffc139a000 8K USR ro x pte 0xffffffffc139a000-0xffffffffc139c000 8K USR ro x pte 0xffffffffc139c000-0xffffffffc139d000 4K USR ro x pte 0xffffffffc139d000-0xffffffffc13a3000 24K USR ro x pte 0xffffffffc13a3000-0xffffffffc13a4000 4K USR ro x pte 0xffffffffc13a4000-0xffffffffc13a5000 4K USR ro x pte 0xffffffffc13a5000-0xffffffffc13a6000 4K USR ro x pte 0xffffffffc13a6000-0xffffffffc13a9000 12K USR ro x pte 0xffffffffc13a9000-0xffffffffc13ab000 8K USR ro x pte 0xffffffffc13ab000-0xffffffffc13ac000 4K USR ro x pte 0xffffffffc13ac000-0xffffffffc13ae000 8K USR ro x pte 0xffffffffc13ae000-0xffffffffc13b1000 12K USR ro x pte 0xffffffffc13b1000-0xffffffffc13b3000 8K USR ro x pte 0xffffffffc13b3000-0xffffffffc13b5000 8K USR ro x pte 0xffffffffc13b5000-0xffffffffc13b9000 16K USR ro x pte 0xffffffffc13b9000-0xffffffffc13ba000 4K USR ro x pte 0xffffffffc13ba000-0xffffffffc13bf000 20K USR ro x pte 0xffffffffc13bf000-0xffffffffc13ce000 60K USR ro x pte 0xffffffffc13ce000-0xffffffffc13cf000 4K USR ro x pte 0xffffffffc13cf000-0xffffffffc13d0000 4K USR ro x pte 0xffffffffc13d0000-0xffffffffc13d2000 8K USR ro x pte 0xffffffffc13d2000-0xffffffffc13d3000 4K USR ro x pte 0xffffffffc13d3000-0xffffffffc13db000 32K USR ro x pte 0xffffffffc13db000-0xffffffffc13dc000 4K USR ro x pte 0xffffffffc13dc000-0xffffffffc13dd000 4K USR ro x pte 0xffffffffc13dd000-0xffffffffc13de000 4K USR ro x pte 0xffffffffc13de000-0xffffffffc13e0000 8K USR ro x pte 0xffffffffc13e0000-0xffffffffc13e3000 12K USR ro x pte 0xffffffffc13e3000-0xffffffffc13e5000 8K USR ro x pte 0xffffffffc13e5000-0xffffffffc13e8000 12K USR ro x pte 0xffffffffc13e8000-0xffffffffc13ea000 8K USR ro x pte 0xffffffffc13ea000-0xffffffffc13ec000 8K USR ro x pte 0xffffffffc13ec000-0xffffffffc13ed000 4K USR ro x pte 0xffffffffc13ed000-0xffffffffc13ef000 8K USR ro x pte 0xffffffffc13ef000-0xffffffffc13f3000 16K USR ro x pte 0xffffffffc13f3000-0xffffffffc13f4000 4K USR ro x pte 0xffffffffc13f4000-0xffffffffc13f6000 8K USR ro x pte 0xffffffffc13f6000-0xffffffffc13f7000 4K USR ro x pte 0xffffffffc13f7000-0xffffffffc13fa000 12K USR ro x pte 0xffffffffc13fa000-0xffffffffc13fb000 4K USR ro x pte 0xffffffffc13fb000-0xffffffffc13fd000 8K USR ro x pte 0xffffffffc13fd000-0xffffffffc13fe000 4K USR ro x pte 0xffffffffc13fe000-0xffffffffc1403000 20K USR ro x pte 0xffffffffc1403000-0xffffffffc1404000 4K USR ro x pte 0xffffffffc1404000-0xffffffffc1406000 8K USR ro x pte 0xffffffffc1406000-0xffffffffc1408000 8K USR ro x pte 0xffffffffc1408000-0xffffffffc1411000 36K USR ro x pte 0xffffffffc1411000-0xffffffffc1412000 4K USR ro x pte 0xffffffffc1412000-0xffffffffc1413000 4K USR ro x pte 0xffffffffc1413000-0xffffffffc1415000 8K USR ro x pte 0xffffffffc1415000-0xffffffffc1416000 4K USR ro x pte 0xffffffffc1416000-0xffffffffc1419000 12K USR ro x pte 0xffffffffc1419000-0xffffffffc141e000 20K USR ro x pte 0xffffffffc141e000-0xffffffffc1425000 28K USR ro x pte 0xffffffffc1425000-0xffffffffc1426000 4K USR ro x pte 0xffffffffc1426000-0xffffffffc1428000 8K USR ro x pte 0xffffffffc1428000-0xffffffffc142f000 28K USR ro x pte 0xffffffffc142f000-0xffffffffc1430000 4K USR ro x pte 0xffffffffc1430000-0xffffffffc1437000 28K USR ro x pte 0xffffffffc1437000-0xffffffffc1438000 4K USR ro x pte 0xffffffffc1438000-0xffffffffc1439000 4K USR ro x pte 0xffffffffc1439000-0xffffffffc143d000 16K USR ro x pte 0xffffffffc143d000-0xffffffffc143e000 4K USR ro x pte 0xffffffffc143e000-0xffffffffc143f000 4K USR ro x pte 0xffffffffc143f000-0xffffffffc1440000 4K USR ro x pte 0xffffffffc1440000-0xffffffffc1443000 12K USR ro x pte 0xffffffffc1443000-0xffffffffc1445000 8K USR ro x pte 0xffffffffc1445000-0xffffffffc1446000 4K USR ro x pte 0xffffffffc1446000-0xffffffffc1448000 8K USR ro x pte 0xffffffffc1448000-0xffffffffc144d000 20K USR ro x pte 0xffffffffc144d000-0xffffffffc144f000 8K USR ro x pte 0xffffffffc144f000-0xffffffffc1451000 8K USR ro x pte 0xffffffffc1451000-0xffffffffc1452000 4K USR ro x pte 0xffffffffc1452000-0xffffffffc1458000 24K USR ro x pte 0xffffffffc1458000-0xffffffffc1459000 4K USR ro x pte 0xffffffffc1459000-0xffffffffc145a000 4K USR ro x pte 0xffffffffc145a000-0xffffffffc145c000 8K USR ro x pte 0xffffffffc145c000-0xffffffffc145d000 4K USR ro x pte 0xffffffffc145d000-0xffffffffc1462000 20K USR ro x pte 0xffffffffc1462000-0xffffffffc1463000 4K USR ro x pte 0xffffffffc1463000-0xffffffffc1464000 4K USR ro x pte 0xffffffffc1464000-0xffffffffc1465000 4K USR ro x pte 0xffffffffc1465000-0xffffffffc1467000 8K USR ro x pte 0xffffffffc1467000-0xffffffffc1468000 4K USR ro x pte 0xffffffffc1468000-0xffffffffc1469000 4K USR ro x pte 0xffffffffc1469000-0xffffffffc146a000 4K USR ro x pte 0xffffffffc146a000-0xffffffffc146b000 4K USR ro x pte 0xffffffffc146b000-0xffffffffc1470000 20K USR ro x pte 0xffffffffc1470000-0xffffffffc1471000 4K USR ro x pte 0xffffffffc1471000-0xffffffffc1473000 8K USR ro x pte 0xffffffffc1473000-0xffffffffc1477000 16K USR ro x pte 0xffffffffc1477000-0xffffffffc147a000 12K USR ro x pte 0xffffffffc147a000-0xffffffffc147b000 4K USR ro x pte 0xffffffffc147b000-0xffffffffc147c000 4K USR ro x pte 0xffffffffc147c000-0xffffffffc147d000 4K USR ro x pte 0xffffffffc147d000-0xffffffffc1482000 20K USR ro x pte 0xffffffffc1482000-0xffffffffc1484000 8K USR ro x pte 0xffffffffc1484000-0xffffffffc1485000 4K USR ro x pte 0xffffffffc1485000-0xffffffffc1486000 4K USR ro x pte 0xffffffffc1486000-0xffffffffc1489000 12K USR ro x pte 0xffffffffc1489000-0xffffffffc148a000 4K USR ro x pte 0xffffffffc148a000-0xffffffffc148b000 4K USR ro x pte 0xffffffffc148b000-0xffffffffc148c000 4K USR ro x pte 0xffffffffc148c000-0xffffffffc1499000 52K USR ro x pte 0xffffffffc1499000-0xffffffffc149a000 4K USR ro x pte 0xffffffffc149a000-0xffffffffc14a2000 32K USR ro x pte 0xffffffffc14a2000-0xffffffffc14a5000 12K USR ro x pte 0xffffffffc14a5000-0xffffffffc14a8000 12K USR ro x pte 0xffffffffc14a8000-0xffffffffc14b0000 32K USR ro x pte 0xffffffffc14b0000-0xffffffffc14b1000 4K USR ro x pte 0xffffffffc14b1000-0xffffffffc14b2000 4K USR ro x pte 0xffffffffc14b2000-0xffffffffc14c2000 64K USR ro x pte 0xffffffffc14c2000-0xffffffffc14c3000 4K USR ro x pte 0xffffffffc14c3000-0xffffffffc14c5000 8K USR ro x pte 0xffffffffc14c5000-0xffffffffc14cb000 24K USR ro x pte 0xffffffffc14cb000-0xffffffffc14cc000 4K USR ro x pte 0xffffffffc14cc000-0xffffffffc14cf000 12K USR ro x pte 0xffffffffc14cf000-0xffffffffc14d0000 4K USR ro x pte 0xffffffffc14d0000-0xffffffffc14d1000 4K USR ro x pte 0xffffffffc14d1000-0xffffffffc14d3000 8K USR ro x pte 0xffffffffc14d3000-0xffffffffc14d4000 4K USR ro x pte 0xffffffffc14d4000-0xffffffffc14d6000 8K USR ro x pte 0xffffffffc14d6000-0xffffffffc14d7000 4K USR ro x pte 0xffffffffc14d7000-0xffffffffc14db000 16K USR ro x pte 0xffffffffc14db000-0xffffffffc14dc000 4K USR ro x pte 0xffffffffc14dc000-0xffffffffc14de000 8K USR ro x pte 0xffffffffc14de000-0xffffffffc14df000 4K USR ro x pte 0xffffffffc14df000-0xffffffffc14e3000 16K USR ro x pte 0xffffffffc14e3000-0xffffffffc14e7000 16K USR ro x pte 0xffffffffc14e7000-0xffffffffc14e8000 4K USR ro x pte 0xffffffffc14e8000-0xffffffffc14e9000 4K USR ro x pte 0xffffffffc14e9000-0xffffffffc14f1000 32K USR ro x pte 0xffffffffc14f1000-0xffffffffc14f2000 4K USR ro x pte 0xffffffffc14f2000-0xffffffffc14f6000 16K USR ro x pte 0xffffffffc14f6000-0xffffffffc14f7000 4K USR ro x pte 0xffffffffc14f7000-0xffffffffc14f8000 4K USR ro x pte 0xffffffffc14f8000-0xffffffffc14f9000 4K USR ro x pte 0xffffffffc14f9000-0xffffffffc14fe000 20K USR ro x pte 0xffffffffc14fe000-0xffffffffc1503000 20K USR ro x pte 0xffffffffc1503000-0xffffffffc1508000 20K USR ro x pte 0xffffffffc1508000-0xffffffffc150d000 20K USR ro x pte 0xffffffffc150d000-0xffffffffc1511000 16K USR ro x pte 0xffffffffc1511000-0xffffffffc1513000 8K USR ro x pte 0xffffffffc1513000-0xffffffffc1514000 4K USR ro x pte 0xffffffffc1514000-0xffffffffc1515000 4K USR ro x pte 0xffffffffc1515000-0xffffffffc1516000 4K USR ro x pte 0xffffffffc1516000-0xffffffffc151b000 20K USR ro x pte 0xffffffffc151b000-0xffffffffc1520000 20K USR ro x pte 0xffffffffc1520000-0xffffffffc1521000 4K USR ro x pte 0xffffffffc1521000-0xffffffffc1523000 8K USR ro x pte 0xffffffffc1523000-0xffffffffc1525000 8K USR ro x pte 0xffffffffc1525000-0xffffffffc1526000 4K USR ro x pte 0xffffffffc1526000-0xffffffffc1529000 12K USR ro x pte 0xffffffffc1529000-0xffffffffc152a000 4K USR ro x pte 0xffffffffc152a000-0xffffffffc152b000 4K USR ro x pte 0xffffffffc152b000-0xffffffffc152e000 12K USR ro x pte 0xffffffffc152e000-0xffffffffc1533000 20K USR ro x pte 0xffffffffc1533000-0xffffffffc1535000 8K USR ro x pte 0xffffffffc1535000-0xffffffffc1537000 8K USR ro x pte 0xffffffffc1537000-0xffffffffc1538000 4K USR ro x pte 0xffffffffc1538000-0xffffffffc1539000 4K USR ro x pte 0xffffffffc1539000-0xffffffffc153b000 8K USR ro x pte 0xffffffffc153b000-0xffffffffc153d000 8K USR ro x pte 0xffffffffc153d000-0xffffffffc1541000 16K USR ro x pte 0xffffffffc1541000-0xffffffffc1542000 4K USR ro x pte 0xffffffffc1542000-0xffffffffc1544000 8K USR ro x pte 0xffffffffc1544000-0xffffffffc1545000 4K USR ro x pte 0xffffffffc1545000-0xffffffffc1547000 8K USR ro x pte 0xffffffffc1547000-0xffffffffc1551000 40K USR ro x pte 0xffffffffc1551000-0xffffffffc1552000 4K USR ro x pte 0xffffffffc1552000-0xffffffffc1554000 8K USR ro x pte 0xffffffffc1554000-0xffffffffc1555000 4K USR ro x pte 0xffffffffc1555000-0xffffffffc155d000 32K USR ro x pte 0xffffffffc155d000-0xffffffffc155f000 8K USR ro x pte 0xffffffffc155f000-0xffffffffc1563000 16K USR ro x pte 0xffffffffc1563000-0xffffffffc1566000 12K USR ro x pte 0xffffffffc1566000-0xffffffffc1567000 4K USR ro x pte 0xffffffffc1567000-0xffffffffc1568000 4K USR ro x pte 0xffffffffc1568000-0xffffffffc156a000 8K USR ro x pte 0xffffffffc156a000-0xffffffffc156b000 4K USR ro x pte 0xffffffffc156b000-0xffffffffc1572000 28K USR ro x pte 0xffffffffc1572000-0xffffffffc1573000 4K USR ro x pte 0xffffffffc1573000-0xffffffffc1576000 12K USR ro x pte 0xffffffffc1576000-0xffffffffc1577000 4K USR ro x pte 0xffffffffc1577000-0xffffffffc1578000 4K USR ro x pte 0xffffffffc1578000-0xffffffffc1579000 4K USR ro x pte 0xffffffffc1579000-0xffffffffc157a000 4K USR ro x pte 0xffffffffc157a000-0xffffffffc157b000 4K USR ro x pte 0xffffffffc157b000-0xffffffffc157d000 8K USR ro x pte 0xffffffffc157d000-0xffffffffc157f000 8K USR ro x pte 0xffffffffc157f000-0xffffffffc1582000 12K USR ro x pte 0xffffffffc1582000-0xffffffffc1584000 8K USR ro x pte 0xffffffffc1584000-0xffffffffc1586000 8K USR ro x pte 0xffffffffc1586000-0xffffffffc1588000 8K USR ro x pte 0xffffffffc1588000-0xffffffffc1589000 4K USR ro x pte 0xffffffffc1589000-0xffffffffc158d000 16K USR ro x pte 0xffffffffc158d000-0xffffffffc158f000 8K USR ro x pte 0xffffffffc158f000-0xffffffffc1593000 16K USR ro x pte 0xffffffffc1593000-0xffffffffc1594000 4K USR ro x pte 0xffffffffc1594000-0xffffffffc1595000 4K USR ro x pte 0xffffffffc1595000-0xffffffffc1596000 4K USR ro x pte 0xffffffffc1596000-0xffffffffc1599000 12K USR ro x pte 0xffffffffc1599000-0xffffffffc15ab000 72K USR ro x pte 0xffffffffc15ab000-0xffffffffc15ac000 4K USR ro x pte 0xffffffffc15ac000-0xffffffffc15b0000 16K USR ro x pte 0xffffffffc15b0000-0xffffffffc15b1000 4K USR ro x pte 0xffffffffc15b1000-0xffffffffc15b7000 24K USR ro x pte 0xffffffffc15b7000-0xffffffffc1600000 292K USR RW NX pte 0xffffffffc1600000-0xffffffffc179c000 1648K USR ro NX pte 0xffffffffc179c000-0xffffffffc1800000 400K USR RW NX pte 0xffffffffc1800000-0xffffffffc1802000 8K USR RW x pte 0xffffffffc1802000-0xffffffffc1803000 4K USR RW x pte 0xffffffffc1803000-0xffffffffc1805000 8K USR RW x pte 0xffffffffc1805000-0xffffffffc180b000 24K USR RW x pte 0xffffffffc180b000-0xffffffffc180f000 16K USR ro x pte 0xffffffffc180f000-0xffffffffc1810000 4K USR RW x pte 0xffffffffc1810000-0xffffffffc1812000 8K USR ro x pte 0xffffffffc1812000-0xffffffffc1813000 4K USR RW x pte 0xffffffffc1813000-0xffffffffc1815000 8K USR RW x pte 0xffffffffc1815000-0xffffffffc1816000 4K USR RW x pte 0xffffffffc1816000-0xffffffffc1818000 8K USR RW x pte 0xffffffffc1818000-0xffffffffc181a000 8K USR RW x pte 0xffffffffc181a000-0xffffffffc181d000 12K USR RW x pte 0xffffffffc181d000-0xffffffffc181e000 4K USR RW x pte 0xffffffffc181e000-0xffffffffc1832000 80K USR RW x pte 0xffffffffc1832000-0xffffffffc1834000 8K USR RW x pte 0xffffffffc1834000-0xffffffffc183a000 24K USR RW x pte 0xffffffffc183a000-0xffffffffc183d000 12K USR RW x pte 0xffffffffc183d000-0xffffffffc1841000 16K USR RW x pte 0xffffffffc1841000-0xffffffffc1843000 8K USR RW x pte 0xffffffffc1843000-0xffffffffc1845000 8K USR RW x pte 0xffffffffc1845000-0xffffffffc1846000 4K USR RW x pte 0xffffffffc1846000-0xffffffffc1849000 12K USR RW x pte 0xffffffffc1849000-0xffffffffc184a000 4K USR RW x pte 0xffffffffc184a000-0xffffffffc184f000 20K USR RW x pte 0xffffffffc184f000-0xffffffffc1850000 4K USR RW x pte 0xffffffffc1850000-0xffffffffc1885000 212K USR RW x pte 0xffffffffc1885000-0xffffffffc1938000 716K USR RW NX pte 0xffffffffc1938000-0xffffffffc193a000 8K USR RW x pte 0xffffffffc193a000-0xffffffffc193b000 4K USR ro x pte 0xffffffffc193b000-0xffffffffc193d000 8K USR RW x pte 0xffffffffc193d000-0xffffffffc193e000 4K USR ro x pte 0xffffffffc193e000-0xffffffffc1948000 40K USR RW x pte 0xffffffffc1948000-0xffffffffc194a000 8K USR RW x pte 0xffffffffc194a000-0xffffffffc194c000 8K USR RW x pte 0xffffffffc194c000-0xffffffffc196c000 128K USR RW x pte 0xffffffffc196c000-0xffffffffc196d000 4K USR RW x pte 0xffffffffc196d000-0xffffffffc1970000 12K USR RW x pte 0xffffffffc1970000-0xffffffffc1971000 4K USR RW x pte 0xffffffffc1971000-0xffffffffc1972000 4K USR RW x pte 0xffffffffc1972000-0xffffffffc1973000 4K USR RW x pte 0xffffffffc1973000-0xffffffffc1975000 8K USR RW x pte 0xffffffffc1975000-0xffffffffc1976000 4K USR RW x pte 0xffffffffc1976000-0xffffffffc1977000 4K USR RW x pte 0xffffffffc1977000-0xffffffffc197b000 16K USR RW x pte 0xffffffffc197b000-0xffffffffc19b9000 248K USR RW x pte 0xffffffffc19b9000-0xffffffffc19c0000 28K USR RW x pte 0xffffffffc19c0000-0xffffffffc19df000 124K USR RW x pte 0xffffffffc19df000-0xffffffffc19e8000 36K USR RW x pte 0xffffffffc19e8000-0xffffffffc19f1000 36K USR RW x pte 0xffffffffc19f1000-0xffffffffc19f2000 4K USR RW x pte 0xffffffffc19f2000-0xffffffffc19f3000 4K USR RW x pte 0xffffffffc19f3000-0xffffffffc19f5000 8K USR RW x pte 0xffffffffc19f5000-0xffffffffc19f8000 12K USR RW x pte 0xffffffffc19f8000-0xffffffffc1a0a000 72K USR RW x pte 0xffffffffc1a0a000-0xffffffffc1a0f000 20K USR RW x pte 0xffffffffc1a0f000-0xffffffffc1a1c000 52K USR RW x pte 0xffffffffc1a1c000-0xffffffffc1a1d000 4K USR RW x pte 0xffffffffc1a1d000-0xffffffffc1aaa000 564K USR RW x pte 0xffffffffc1aaa000-0xffffffffc1aae000 16K USR ro x pte 0xffffffffc1aae000-0xffffffffc1b34000 536K USR RW x pte 0xffffffffc1b34000-0xffffffffc1e3d000 3108K USR RW x pte 0xffffffffc1e3d000-0xffffffffcfc93000 227672K USR RW NX pte 0xffffffffcfc93000-0xffffffffe0000000 265652K USR RW x pte 0xffffffffe0000000-0xffffffffe0001000 4K USR ro x pte 0xffffffffe0001000-0xffffffffe0002000 4K USR ro NX pte 0xffffffffe0002000-0xffffffffe0004000 8K USR RW NX pte 0xffffffffe0004000-0xffffffffe0008000 16K pte 0xffffffffe0008000-0xffffffffe0009000 4K USR ro x pte 0xffffffffe0009000-0xffffffffe000a000 4K USR ro NX pte 0xffffffffe000a000-0xffffffffe000c000 8K USR RW NX pte 0xffffffffe000c000-0xffffffffe0070000 400K pte 0xffffffffe0070000-0xffffffffe024c000 1904K USR RW x pte 0xffffffffe024c000-0xffffffffe024e000 8K USR RW x pte 0xffffffffe024e000-0xffffffffe0353000 1044K USR ro x pte 0xffffffffe0353000-0xffffffffe0400000 692K USR RW x pte 0xffffffffe0400000-0xffffffffff000000 492M pmd ---[ End Modules ]--- 0xffffffffff000000-0xffffffffff400000 4M pmd 0xffffffffff400000-0xffffffffff579000 1508K pte 0xffffffffff579000-0xffffffffff57a000 4K USR RW NX pte 0xffffffffff57a000-0xffffffffff5ff000 532K pte 0xffffffffff5ff000-0xffffffffff601000 8K USR ro GLB NX pte 0xffffffffff601000-0xffffffffff800000 2044K pte 0xffffffffff800000-0x0000000000000000 8M pmd # poweroff --azLHFNyN32YCQGCU Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --azLHFNyN32YCQGCU-- From xen-devel-bounces@lists.xen.org Thu May 10 15:35:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVOP-0004LT-0e; Thu, 10 May 2012 15:35:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVOM-0004LM-VF for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:35:00 +0000 Received: from [85.158.138.51:14741] by server-8.bemta-3.messagelabs.com id 7A/4A-24428-220EBAF4; Thu, 10 May 2012 15:34:58 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336664094!26279570!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21647 invoked from network); 10 May 2012 15:34:55 -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; 10 May 2012 15:34:55 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFYqQW008028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:34: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 q4AFYp8O017068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:34:51 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 q4AFYoU5025893; Thu, 10 May 2012 10:34:50 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:34:48 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D59284032D; Thu, 10 May 2012 11:28:44 -0400 (EDT) Date: Thu, 10 May 2012 11:28:44 -0400 From: Konrad Rzeszutek Wilk To: JBeulich@suse.com, xen-devel@lists.xensource.com Message-ID: <20120510152844.GP26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [Xen-devel] pvops domU guest booting problem - 131GB ok, 132GB not ok. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Jan, I've just started to trying to track down why a pvops 64-bit PV guest can't boot with more than 128GB of memory. The issue I am seeing is that the module loading subsystem stops working and I get this: WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: Pid: 1051, comm: modprobe Not tainted 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dc6 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 1051, comm: modprobe Tainted: G W 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 73 active_anon:253 inactive_anon:31970 isolated_anon:0 active_file:391 inactive_file:27806 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33525733 slab_reclaimable:1660 slab_unreclaimable:976 mapped:340 shmem:31960 pagetables:34 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130456376kB min:45112kB low:56388kB high:67668kB active_anon:1012kB inactive_anon:127880kB active_file:1564kB inactive_file:111224kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:1360kB shmem:127840kB slab_reclaimable:6640kB slab_unreclaimable:3904kB kernel_stack:368kB pagetables:136kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 26*4kB 26*8kB 14*16kB 11*32kB 11*64kB 6*128kB 8*256kB 7*512kB 9*1024kB 3*2048kB 31844*4096kB = 130456376kB 60151 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 983 pages shared 166525 pages non-shared Which tells me that there is more than enough memory. So my thinking is that it is either: - it can't stick the new pagetables in the memory b/c there isn't enough physical space in the region it wants - but the region it uses is Normal, so that should be OK? - it is hitting some page tables that are used by the hypervisor? Was wondering if you had hit this at some point with SLES guests and if there are any ideas of what I should look for ? Thanks! --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="131gb.txt" Content-Transfer-Encoding: quoted-printable console [hvc0] enabled, bootconsole disabled Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2261.074 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. = 4522.14 BogoMIPS (lpj=3D2261074) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 16777216 (order: 15, 134217728 bytes) Inode-cache hash table entries: 8388608 (order: 14, 67108864 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 24k freed cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 46 no PMU driver, software eve= nts only. NMI watchdog: disabled (cpu0): hardware events not enabled Brought up 1 CPUs kworker/u:0 used greatest stack depth: 6000 bytes left Grant tables using version 2 layout. Grant table initialized RTC time: 165:165:165, date: 165/165/65 NET: Registered protocol family 16 kworker/u:0 used greatest stack depth: 5536 bytes left dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size =3D 128 NetLabel: protocols =3D UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 65536 (order: 9, 2097152 bytes) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 227672k freed platform rtc_cmos: registered platform RTC device (no PNP device found) Machine check injector initialized microcode: CPU0 sig=3D0x206e5, pf=3D0x4, revision=3D0xffff0018 microcode: Microcode Update Driver: v2.00 , Pe= ter Oruba audit: initializing netlink socket (disabled) type=3D2000 audit(1336419344.018:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) NFS: Registering the id_resolver key type NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 32768 SELinux: Registering netfilter hooks Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ioatdma: Intel(R) QuickData Technology Driver 4.00 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 brd: module loaded loop: module loaded Fixed MDIO Bus: probed tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - = version 2.2.0-k ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 80 td 96 uhci_hcd: USB Universal Host Controller Interface driver usbcore: registered new interface driver usblp usbcore: registered new interface driver libusual i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ctnetlink v0.93: registering with nfnetlink. ip_tables: (C) 2000-2006 Netfilter Core Team TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Registering the dns_resolver key type PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Magic number: 1:252:3141 Freeing unused kernel memory: 692k freed Write protecting the kernel read-only data: 8192k Freeing unused kernel memory: 292k freed Freeing unused kernel memory: 400k freed BusyBox v1.14.3 (2012-05-07 12:16:33 EDT) consoletype used greatest stack depth: 5336 bytes left ories [ OK ] modprobe used greatest stack depth: 5096 bytes left int /sys/kernel/config does not exist core_filesystem used greatest stack depth: 5016 bytes left Initialising Xen virtual ethernet driver. 16: 2062 xen-percpu-virq timer0 17: 0 xen-percpu-ipi spinlock0 18: 0 xen-percpu-ipi resched0 19: 0 xen-percpu-ipi callfunc0 20: 0 xen-percpu-virq debug0 21: 0 xen-percpu-ipi callfuncsingle0 22: 0 xen-percpu-ipi irqwork0 23: 47 xen-dyn-event xenbus 24: 61 xen-dyn-event hvc_console NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts IWI: 0 IRQ work interrupts RTR: 0 APIC ICR read retries RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts MCE: 0 Machine check exceptions MCP: 0 Machine check polls ERR: 0 MIS: 0 00000000-0000ffff : reserved 00010000-0009ffff : System RAM 000a0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-1f407fffff : System RAM 01000000-015b1d63 : Kernel code 015b1d64-018838bf : Kernel data 01939000-01a1efff : Kernel bss MemTotal: 128734892 kB MemFree: 128251264 kB Buffers: 0 kB Cached: 240696 kB SwapCached: 0 kB Active: 20436 kB Inactive: 219972 kB Active(anon): 14760 kB Inactive(anon): 116532 kB Active(file): 5676 kB Inactive(file): 103440 kB Unevictable: 4876 kB Mlocked: 4896 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 4708 kB Mapped: 5056 kB Shmem: 127992 kB Slab: 15880 kB SReclaimable: 9344 kB SUnreclaim: 6536 kB KernelStack: 328 kB PageTables: 668 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 64367444 kB Committed_AS: 136444 kB VmallocTotal: 34359738367 kB VmallocUsed: 214720 kB VmallocChunk: 34359523635 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 131080192 kB DirectMap2M: 0 kB Waiting for init.late [ OK ] connect: Network is unreachable May 7 19:35:50 (none) rpc.statd[2099]: Caught signal 15, un-registering an= d exiting connect: Network is unreachable May 7 19:35:50 (none) iscsid: semop down failed 22 warning: /sysctl.conf(1): invalid syntax, continuing... net.ipv4.ip_forward =3D 0 net.ipv4.conf.default.rp_filter =3D 2 net.ipv4.conf.default.accept_source_route =3D 0 kernel.sysrq =3D 0 kernel.core_uses_pid =3D 1 net.ipv4.tcp_syncookies =3D 1 kernel.msgmnb =3D 65536 kernel.msgmax =3D 65536 kernel.shmmax =3D 68719476736 kernel.shmall =3D 4294967296 vm.min_free_kbytes =3D 65536 kernel.panic_on_oops =3D 1 kernel.panic =3D 60 Error : Name or service not known Linux (none) 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 SMP Mon May 7 13:30:= 51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux MemTotal: 128734892 kB MemFree: 128254048 kB Buffers: 0 kB Cached: 240844 kB SwapCached: 0 kB Active: 19576 kB Inactive: 219628 kB Active(anon): 13424 kB Inactive(anon): 116512 kB Active(file): 6152 kB Inactive(file): 103116 kB Unevictable: 3584 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 1944 kB Mapped: 1676 kB Shmem: 127992 kB Slab: 15860 kB SReclaimable: 9324 kB SUnreclaim: 6536 kB KernelStack: 320 kB PageTables: 516 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 64367444 kB Committed_AS: 133016 kB VmallocTotal: 34359738367 kB VmallocUsed: 214720 kB VmallocChunk: 34359523635 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 131080192 kB DirectMap2M: 0 kB 0xffffc90000000000-0xffffc90008001000 134221824 alloc_large_system_hash+0x1= 54/0x213 pages=3D32768 vmalloc vpages N0=3D32768 0xffffc90008001000-0xffffc90008042000 266240 alloc_large_system_hash+0x154= /0x213 pages=3D64 vmalloc N0=3D64 0xffffc90008042000-0xffffc9000c043000 67112960 alloc_large_system_hash+0x15= 4/0x213 pages=3D16384 vmalloc vpages N0=3D16384 0xffffc9000c043000-0xffffc9000c064000 135168 alloc_large_system_hash+0x154= /0x213 pages=3D32 vmalloc N0=3D32 0xffffc9000c064000-0xffffc9000c067000 12288 alloc_large_system_hash+0x154= /0x213 pages=3D2 vmalloc N0=3D2 0xffffc9000c068000-0xffffc9000c06d000 20480 arch_gnttab_map_status+0x50/0= x70 ioremap 0xffffc9000c06d000-0xffffc9000c072000 20480 alloc_large_system_hash+0x154= /0x213 pages=3D4 vmalloc N0=3D4 0xffffc9000c072000-0xffffc9000c07e000 49152 zisofs_init+0x11/0x23 pages= =3D11 vmalloc N0=3D11 0xffffc9000c080000-0xffffc9000c0a1000 135168 arch_gnttab_map_shared+0x50/0= x70 ioremap 0xffffc9000c0a1000-0xffffc9000c4a2000 4198400 alloc_large_system_hash+0x154= /0x213 pages=3D1024 vmalloc vpages N0=3D1024 0xffffc9000c4a2000-0xffffc9000cca3000 8392704 alloc_large_system_hash+0x154= /0x213 pages=3D2048 vmalloc vpages N0=3D2048 0xffffc9000cca3000-0xffffc9000cda4000 1052672 alloc_large_system_hash+0x154= /0x213 pages=3D256 vmalloc N0=3D256 0xffffc9000cda4000-0xffffc9000cfa5000 2101248 alloc_large_system_hash+0x154= /0x213 pages=3D512 vmalloc N0=3D512 0xffffc9000cfa5000-0xffffc9000d1a6000 2101248 alloc_large_system_hash+0x154= /0x213 pages=3D512 vmalloc N0=3D512 0xffffc9000d1a6000-0xffffc9000d1b3000 53248 netback_init+0x4c/0x210 pages= =3D12 vmalloc N0=3D12 0xffffffffa0000000-0xffffffffa0005000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0008000-0xffffffffa000d000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0010000-0xffffffffa0015000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0018000-0xffffffffa001d000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa001d000-0xffffffffa0022000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0022000-0xffffffffa0027000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0027000-0xffffffffa002c000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa002c000-0xffffffffa0032000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa0036000-0xffffffffa003e000 32768 module_alloc_update_bounds+0x= 19/0x80 pages=3D7 vmalloc N0=3D7 0xffffffffa0042000-0xffffffffa0049000 28672 module_alloc_update_bounds+0x= 19/0x80 pages=3D6 vmalloc N0=3D6 0xffffffffa004d000-0xffffffffa0052000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0052000-0xffffffffa005c000 40960 module_alloc_update_bounds+0x= 19/0x80 pages=3D9 vmalloc N0=3D9 0xffffffffa005c000-0xffffffffa0061000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0061000-0xffffffffa0074000 77824 module_alloc_update_bounds+0x= 19/0x80 pages=3D18 vmalloc N0=3D18 0xffffffffa0074000-0xffffffffa007a000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa007c000-0xffffffffa0081000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0081000-0xffffffffa0086000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0086000-0xffffffffa0093000 53248 module_alloc_update_bounds+0x= 19/0x80 pages=3D12 vmalloc N0=3D12 0xffffffffa0097000-0xffffffffa0169000 860160 module_alloc_update_bounds+0x= 19/0x80 pages=3D209 vmalloc N0=3D209 0xffffffffa0169000-0xffffffffa016e000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa016e000-0xffffffffa0173000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa0173000-0xffffffffa0199000 155648 module_alloc_update_bounds+0x= 19/0x80 pages=3D37 vmalloc N0=3D37 0xffffffffa0199000-0xffffffffa01a4000 45056 module_alloc_update_bounds+0x= 19/0x80 pages=3D10 vmalloc N0=3D10 0xffffffffa01a8000-0xffffffffa01b4000 49152 module_alloc_update_bounds+0x= 19/0x80 pages=3D11 vmalloc N0=3D11 0xffffffffa01b4000-0xffffffffa01ba000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa01ba000-0xffffffffa01c0000 24576 module_alloc_update_bounds+0x= 19/0x80 pages=3D5 vmalloc N0=3D5 0xffffffffa01c4000-0xffffffffa01c9000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 0xffffffffa01c9000-0xffffffffa01ce000 20480 module_alloc_update_bounds+0x= 19/0x80 pages=3D4 vmalloc N0=3D4 # lsmod Module Size Used by xen_evtchn 12835 0=20 iscsi_boot_sysfs 12922 0=20 iscsi_tcp 17580 0=20 libiscsi_tcp 17354 1 iscsi_tcp libiscsi 39804 2 iscsi_tcp,libiscsi_tcp scsi_transport_iscsi 43755 2 iscsi_tcp,libiscsi scsi_mod 148537 3 iscsi_tcp,libiscsi,scsi_transport_iscsi libcrc32c 12426 0=20 crc32c 12656 0=20 radeon 854431 0=20 fbcon 47234 0=20 tileblit 12581 1 fbcon font 16484 1 fbcon bitblit 12610 1 fbcon softcursor 12349 1 bitblit ttm 73322 1 radeon drm_kms_helper 35139 1 radeon,[permanent] crc32c_intel 12704 1=20 xen_blkfront 21357 0=20 xen_netfront 25845 0=20 xen_fbfront 17211 0=20 fb_sys_fops 12350 1 xen_fbfront sysimgblt 12313 1 xen_fbfront sysfillrect 12522 1 xen_fbfront syscopyarea 12313 1 xen_fbfront xen_kbdfront 12686 0=20 xenfs 12737 1=20 xen_privcmd 12829 1 xenfs # cat /sys/kernel/debug/=1B[Jker=1B[21D# cat /sys/kernel/debug/kernel_page_= tables =1B[J ---[ User Space ]--- 0x0000000000000000-0xffff800000000000 16777088T = pgd ---[ Kernel Space ]--- 0xffff800000000000-0xffff814000000000 1280G = pud 0xffff814000000000-0xffff8140a0000000 2560M = pmd 0xffff8140a0000000-0xffff8140a0500000 5M = pte 0xffff8140a0500000-0xffff8140a0501000 4K USR RW x= pte 0xffff8140a0501000-0xffff8140a0503000 8K RW x= pte 0xffff8140a0503000-0xffff8140a0504000 4K = pte 0xffff8140a0504000-0xffff8140a0505000 4K RW x= pte 0xffff8140a0505000-0xffff8140a0507000 8K USR RW x= pte 0xffff8140a0507000-0xffff8140a0509000 8K RW x= pte 0xffff8140a0509000-0xffff8140a0510000 28K = pte 0xffff8140a0510000-0xffff8140a0511000 4K USR RW x= pte 0xffff8140a0511000-0xffff8140a0592000 516K = pte 0xffff8140a0592000-0xffff8140a0593000 4K USR RW x= pte 0xffff8140a0593000-0xffff8140a05d4000 260K = pte 0xffff8140a05d4000-0xffff8140a05d5000 4K USR RW x= pte 0xffff8140a05d5000-0xffff8140a05ff000 168K = pte 0xffff8140a05ff000-0xffff8140a0600000 4K USR RW x= pte 0xffff8140a0600000-0xffff8140a0800000 2M = pmd 0xffff8140a0800000-0xffff8140a1200000 10M = pte 0xffff8140a1200000-0xffff8140a2000000 14M = pmd 0xffff8140a2000000-0xffff8140a207e000 504K USR RW x= pte 0xffff8140a207e000-0xffff8140a2200000 1544K = pte 0xffff8140a2200000-0xffff8140b2400000 258M = pmd 0xffff8140b2400000-0xffff8140b2401000 4K USR RW x= pte 0xffff8140b2401000-0xffff8140b2600000 2044K = pte 0xffff8140b2600000-0xffff8140ba800000 130M = pmd 0xffff8140ba800000-0xffff8140ba802000 8K USR RW x= pte 0xffff8140ba802000-0xffff8140baa00000 2040K = pte 0xffff8140baa00000-0xffff8140bfe00000 84M = pmd 0xffff8140bfe00000-0xffff8140bfffe000 2040K = pte 0xffff8140bfffe000-0xffff8140c0000000 8K USR RW x= pte 0xffff8140c0000000-0xffff814100000000 1G = pud 0xffff814100000000-0xffff814240000000 5G = pmd 0xffff814240000000-0xffff814400000000 7G = pud 0xffff814400000000-0xffff81440fa04000 256016K USR RW x= pte 0xffff81440fa04000-0xffff81440fc00000 2032K = pte 0xffff81440fc00000-0xffff814440000000 772M = pmd 0xffff814440000000-0xffff816480000000 129G = pud 0xffff816480000000-0xffff81648006c000 432K USR RW x= pte 0xffff81648006c000-0xffff816480200000 1616K = pte 0xffff816480200000-0xffff8164c0000000 1022M = pmd 0xffff8164c0000000-0xffff817500000000 65G = pud 0xffff817500000000-0xffff81750036c000 3504K USR RW x= pte 0xffff81750036c000-0xffff817500400000 592K = pte 0xffff817500400000-0xffff817540000000 1020M = pmd 0xffff817540000000-0xffff817fc0000000 42G = pud 0xffff817fc0000000-0xffff817fffc00000 1020M = pmd 0xffff817fffc00000-0xffff817fffc08000 32K = pte 0xffff817fffc08000-0xffff817fffc0e000 24K USR RW x= pte 0xffff817fffc0e000-0xffff817fffc7e000 448K = pte 0xffff817fffc7e000-0xffff817fffcfe000 512K USR RW x= pte 0xffff817fffcfe000-0xffff817fffd00000 8K = pte 0xffff817fffd00000-0xffff817fffd01000 4K USR RW x= pte 0xffff817fffd01000-0xffff817fffe00000 1020K = pte 0xffff817fffe00000-0xffff817fffefe000 1016K USR RW x= pte 0xffff817fffefe000-0xffff817fffffa000 1008K = pte 0xffff817fffffa000-0xffff817fffffc000 8K USR RW x= pte 0xffff817fffffc000-0xffff818000000000 16K = pte 0xffff818000000000-0xffff820000000000 512G = pgd 0xffff820000000000-0xffff848000000000 2560G = pud 0xffff848000000000-0xffff880000000000 3584G = pgd ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff88000009b000 620K USR RW x= pte 0xffff88000009b000-0xffff8800000a0000 20K USR RW x= pte 0xffff8800000a0000-0xffff8800007fb000 7532K USR RW x= pte 0xffff8800007fb000-0xffff880000efc000 7172K USR ro x= pte 0xffff880000efc000-0xffff880001000000 1040K USR RW x= pte 0xffff880001000000-0xffff880001002000 8K USR ro x= pte 0xffff880001002000-0xffff880001013000 68K USR ro x= pte 0xffff880001013000-0xffff880001015000 8K USR ro x= pte 0xffff880001015000-0xffff880001017000 8K USR ro x= pte 0xffff880001017000-0xffff880001019000 8K USR ro x= pte 0xffff880001019000-0xffff88000101a000 4K USR ro x= pte 0xffff88000101a000-0xffff88000101b000 4K USR ro x= pte 0xffff88000101b000-0xffff88000101f000 16K USR ro x= pte 0xffff88000101f000-0xffff880001028000 36K USR ro x= pte 0xffff880001028000-0xffff88000102a000 8K USR ro x= pte 0xffff88000102a000-0xffff88000102c000 8K USR ro x= pte 0xffff88000102c000-0xffff88000103c000 64K USR ro x= pte 0xffff88000103c000-0xffff88000103d000 4K USR ro x= pte 0xffff88000103d000-0xffff880001051000 80K USR ro x= pte 0xffff880001051000-0xffff880001052000 4K USR ro x= pte 0xffff880001052000-0xffff880001057000 20K USR ro x= pte 0xffff880001057000-0xffff880001058000 4K USR ro x= pte 0xffff880001058000-0xffff880001061000 36K USR ro x= pte 0xffff880001061000-0xffff880001063000 8K USR ro x= pte 0xffff880001063000-0xffff88000106b000 32K USR ro x= pte 0xffff88000106b000-0xffff88000106c000 4K USR ro x= pte 0xffff88000106c000-0xffff880001078000 48K USR ro x= pte 0xffff880001078000-0xffff88000107a000 8K USR ro x= pte 0xffff88000107a000-0xffff880001083000 36K USR ro x= pte 0xffff880001083000-0xffff880001084000 4K USR ro x= pte 0xffff880001084000-0xffff88000108f000 44K USR ro x= pte 0xffff88000108f000-0xffff880001090000 4K USR ro x= pte 0xffff880001090000-0xffff880001094000 16K USR ro x= pte 0xffff880001094000-0xffff880001097000 12K USR ro x= pte 0xffff880001097000-0xffff8800010a0000 36K USR ro x= pte 0xffff8800010a0000-0xffff8800010a2000 8K USR ro x= pte 0xffff8800010a2000-0xffff8800010a7000 20K USR ro x= pte 0xffff8800010a7000-0xffff8800010a8000 4K USR ro x= pte 0xffff8800010a8000-0xffff8800010aa000 8K USR ro x= pte 0xffff8800010aa000-0xffff8800010af000 20K USR ro x= pte 0xffff8800010af000-0xffff8800010b4000 20K USR ro x= pte 0xffff8800010b4000-0xffff8800010b6000 8K USR ro x= pte 0xffff8800010b6000-0xffff8800010c0000 40K USR ro x= pte 0xffff8800010c0000-0xffff8800010c4000 16K USR ro x= pte 0xffff8800010c4000-0xffff8800010c6000 8K USR ro x= pte 0xffff8800010c6000-0xffff8800010ca000 16K USR ro x= pte 0xffff8800010ca000-0xffff8800010cc000 8K USR ro x= pte 0xffff8800010cc000-0xffff8800010cd000 4K USR ro x= pte 0xffff8800010cd000-0xffff8800010d5000 32K USR ro x= pte 0xffff8800010d5000-0xffff8800010d9000 16K USR ro x= pte 0xffff8800010d9000-0xffff8800010da000 4K USR ro x= pte 0xffff8800010da000-0xffff8800010db000 4K USR ro x= pte 0xffff8800010db000-0xffff8800010dc000 4K USR ro x= pte 0xffff8800010dc000-0xffff8800010dd000 4K USR ro x= pte 0xffff8800010dd000-0xffff8800010e2000 20K USR ro x= pte 0xffff8800010e2000-0xffff8800010e3000 4K USR ro x= pte 0xffff8800010e3000-0xffff8800010f8000 84K USR ro x= pte 0xffff8800010f8000-0xffff8800010fb000 12K USR ro x= pte 0xffff8800010fb000-0xffff880001101000 24K USR ro x= pte 0xffff880001101000-0xffff880001102000 4K USR ro x= pte 0xffff880001102000-0xffff880001106000 16K USR ro x= pte 0xffff880001106000-0xffff880001107000 4K USR ro x= pte 0xffff880001107000-0xffff880001108000 4K USR ro x= pte 0xffff880001108000-0xffff880001109000 4K USR ro x= pte 0xffff880001109000-0xffff880001113000 40K USR ro x= pte 0xffff880001113000-0xffff880001114000 4K USR ro x= pte 0xffff880001114000-0xffff880001117000 12K USR ro x= pte 0xffff880001117000-0xffff880001118000 4K USR ro x= pte 0xffff880001118000-0xffff880001122000 40K USR ro x= pte 0xffff880001122000-0xffff880001124000 8K USR ro x= pte 0xffff880001124000-0xffff880001143000 124K USR ro x= pte 0xffff880001143000-0xffff880001145000 8K USR ro x= pte 0xffff880001145000-0xffff880001166000 132K USR ro x= pte 0xffff880001166000-0xffff880001168000 8K USR ro x= pte 0xffff880001168000-0xffff88000116d000 20K USR ro x= pte 0xffff88000116d000-0xffff88000116e000 4K USR ro x= pte 0xffff88000116e000-0xffff88000116f000 4K USR ro x= pte 0xffff88000116f000-0xffff880001170000 4K USR ro x= pte 0xffff880001170000-0xffff880001174000 16K USR ro x= pte 0xffff880001174000-0xffff880001177000 12K USR ro x= pte 0xffff880001177000-0xffff88000117a000 12K USR ro x= pte 0xffff88000117a000-0xffff88000117e000 16K USR ro x= pte 0xffff88000117e000-0xffff88000118d000 60K USR ro x= pte 0xffff88000118d000-0xffff88000118e000 4K USR ro x= pte 0xffff88000118e000-0xffff880001190000 8K USR ro x= pte 0xffff880001190000-0xffff880001191000 4K USR ro x= pte 0xffff880001191000-0xffff880001192000 4K USR ro x= pte 0xffff880001192000-0xffff880001193000 4K USR ro x= pte 0xffff880001193000-0xffff880001194000 4K USR ro x= pte 0xffff880001194000-0xffff880001197000 12K USR ro x= pte 0xffff880001197000-0xffff880001198000 4K USR ro x= pte 0xffff880001198000-0xffff880001199000 4K USR ro x= pte 0xffff880001199000-0xffff8800011a0000 28K USR ro x= pte 0xffff8800011a0000-0xffff8800011a1000 4K USR ro x= pte 0xffff8800011a1000-0xffff8800011ab000 40K USR ro x= pte 0xffff8800011ab000-0xffff8800011ac000 4K USR ro x= pte 0xffff8800011ac000-0xffff8800011af000 12K USR ro x= pte 0xffff8800011af000-0xffff8800011b1000 8K USR ro x= pte 0xffff8800011b1000-0xffff8800011b4000 12K USR ro x= pte 0xffff8800011b4000-0xffff8800011b5000 4K USR ro x= pte 0xffff8800011b5000-0xffff8800011b9000 16K USR ro x= pte 0xffff8800011b9000-0xffff8800011bb000 8K USR ro x= pte 0xffff8800011bb000-0xffff8800011bd000 8K USR ro x= pte 0xffff8800011bd000-0xffff8800011be000 4K USR ro x= pte 0xffff8800011be000-0xffff8800011c2000 16K USR ro x= pte 0xffff8800011c2000-0xffff8800011c6000 16K USR ro x= pte 0xffff8800011c6000-0xffff8800011c7000 4K USR ro x= pte 0xffff8800011c7000-0xffff8800011c8000 4K USR ro x= pte 0xffff8800011c8000-0xffff8800011c9000 4K USR ro x= pte 0xffff8800011c9000-0xffff8800011ca000 4K USR ro x= pte 0xffff8800011ca000-0xffff8800011cf000 20K USR ro x= pte 0xffff8800011cf000-0xffff8800011d0000 4K USR ro x= pte 0xffff8800011d0000-0xffff8800011d3000 12K USR ro x= pte 0xffff8800011d3000-0xffff8800011d5000 8K USR ro x= pte 0xffff8800011d5000-0xffff8800011d6000 4K USR ro x= pte 0xffff8800011d6000-0xffff8800011d8000 8K USR ro x= pte 0xffff8800011d8000-0xffff8800011d9000 4K USR ro x= pte 0xffff8800011d9000-0xffff8800011da000 4K USR ro x= pte 0xffff8800011da000-0xffff8800011e0000 24K USR ro x= pte 0xffff8800011e0000-0xffff8800011e3000 12K USR ro x= pte 0xffff8800011e3000-0xffff8800011e9000 24K USR ro x= pte 0xffff8800011e9000-0xffff8800011ea000 4K USR ro x= pte 0xffff8800011ea000-0xffff8800011eb000 4K USR ro x= pte 0xffff8800011eb000-0xffff8800011f1000 24K USR ro x= pte 0xffff8800011f1000-0xffff8800011f7000 24K USR ro x= pte 0xffff8800011f7000-0xffff8800011f8000 4K USR ro x= pte 0xffff8800011f8000-0xffff8800011fa000 8K USR ro x= pte 0xffff8800011fa000-0xffff8800011fb000 4K USR ro x= pte 0xffff8800011fb000-0xffff8800011fd000 8K USR ro x= pte 0xffff8800011fd000-0xffff8800011fe000 4K USR ro x= pte 0xffff8800011fe000-0xffff880001200000 8K USR ro x= pte 0xffff880001200000-0xffff880001201000 4K USR ro x= pte 0xffff880001201000-0xffff880001203000 8K USR ro x= pte 0xffff880001203000-0xffff880001207000 16K USR ro x= pte 0xffff880001207000-0xffff880001209000 8K USR ro x= pte 0xffff880001209000-0xffff88000120a000 4K USR ro x= pte 0xffff88000120a000-0xffff88000120b000 4K USR ro x= pte 0xffff88000120b000-0xffff88000120c000 4K USR ro x= pte 0xffff88000120c000-0xffff88000120e000 8K USR ro x= pte 0xffff88000120e000-0xffff880001223000 84K USR ro x= pte 0xffff880001223000-0xffff880001228000 20K USR ro x= pte 0xffff880001228000-0xffff880001229000 4K USR ro x= pte 0xffff880001229000-0xffff88000123b000 72K USR ro x= pte 0xffff88000123b000-0xffff88000123d000 8K USR ro x= pte 0xffff88000123d000-0xffff88000123e000 4K USR ro x= pte 0xffff88000123e000-0xffff88000123f000 4K USR ro x= pte 0xffff88000123f000-0xffff880001242000 12K USR ro x= pte 0xffff880001242000-0xffff880001244000 8K USR ro x= pte 0xffff880001244000-0xffff880001245000 4K USR ro x= pte 0xffff880001245000-0xffff880001247000 8K USR ro x= pte 0xffff880001247000-0xffff880001248000 4K USR ro x= pte 0xffff880001248000-0xffff880001252000 40K USR ro x= pte 0xffff880001252000-0xffff880001253000 4K USR ro x= pte 0xffff880001253000-0xffff880001254000 4K USR ro x= pte 0xffff880001254000-0xffff880001255000 4K USR ro x= pte 0xffff880001255000-0xffff880001258000 12K USR ro x= pte 0xffff880001258000-0xffff880001259000 4K USR ro x= pte 0xffff880001259000-0xffff880001268000 60K USR ro x= pte 0xffff880001268000-0xffff88000126e000 24K USR ro x= pte 0xffff88000126e000-0xffff88000126f000 4K USR ro x= pte 0xffff88000126f000-0xffff880001272000 12K USR ro x= pte 0xffff880001272000-0xffff880001273000 4K USR ro x= pte 0xffff880001273000-0xffff880001274000 4K USR ro x= pte 0xffff880001274000-0xffff88000127a000 24K USR ro x= pte 0xffff88000127a000-0xffff88000127c000 8K USR ro x= pte 0xffff88000127c000-0xffff88000127d000 4K USR ro x= pte 0xffff88000127d000-0xffff880001285000 32K USR ro x= pte 0xffff880001285000-0xffff880001286000 4K USR ro x= pte 0xffff880001286000-0xffff880001287000 4K USR ro x= pte 0xffff880001287000-0xffff880001288000 4K USR ro x= pte 0xffff880001288000-0xffff880001289000 4K USR ro x= pte 0xffff880001289000-0xffff88000128d000 16K USR ro x= pte 0xffff88000128d000-0xffff88000128f000 8K USR ro x= pte 0xffff88000128f000-0xffff880001291000 8K USR ro x= pte 0xffff880001291000-0xffff880001292000 4K USR ro x= pte 0xffff880001292000-0xffff88000129f000 52K USR ro x= pte 0xffff88000129f000-0xffff8800012a0000 4K USR ro x= pte 0xffff8800012a0000-0xffff8800012a1000 4K USR ro x= pte 0xffff8800012a1000-0xffff8800012a3000 8K USR ro x= pte 0xffff8800012a3000-0xffff8800012a5000 8K USR ro x= pte 0xffff8800012a5000-0xffff8800012a6000 4K USR ro x= pte 0xffff8800012a6000-0xffff8800012a9000 12K USR ro x= pte 0xffff8800012a9000-0xffff8800012ab000 8K USR ro x= pte 0xffff8800012ab000-0xffff8800012c3000 96K USR ro x= pte 0xffff8800012c3000-0xffff8800012c6000 12K USR ro x= pte 0xffff8800012c6000-0xffff8800012cc000 24K USR ro x= pte 0xffff8800012cc000-0xffff8800012cf000 12K USR ro x= pte 0xffff8800012cf000-0xffff8800012d1000 8K USR ro x= pte 0xffff8800012d1000-0xffff8800012d2000 4K USR ro x= pte 0xffff8800012d2000-0xffff8800012d3000 4K USR ro x= pte 0xffff8800012d3000-0xffff8800012d7000 16K USR ro x= pte 0xffff8800012d7000-0xffff8800012d8000 4K USR ro x= pte 0xffff8800012d8000-0xffff8800012da000 8K USR ro x= pte 0xffff8800012da000-0xffff8800012dc000 8K USR ro x= pte 0xffff8800012dc000-0xffff8800012e1000 20K USR ro x= pte 0xffff8800012e1000-0xffff8800012e3000 8K USR ro x= pte 0xffff8800012e3000-0xffff8800012e4000 4K USR ro x= pte 0xffff8800012e4000-0xffff8800012e5000 4K USR ro x= pte 0xffff8800012e5000-0xffff8800012e6000 4K USR ro x= pte 0xffff8800012e6000-0xffff8800012e7000 4K USR ro x= pte 0xffff8800012e7000-0xffff8800012ed000 24K USR ro x= pte 0xffff8800012ed000-0xffff8800012ee000 4K USR ro x= pte 0xffff8800012ee000-0xffff8800012f9000 44K USR ro x= pte 0xffff8800012f9000-0xffff8800012fa000 4K USR ro x= pte 0xffff8800012fa000-0xffff8800012fe000 16K USR ro x= pte 0xffff8800012fe000-0xffff880001300000 8K USR ro x= pte 0xffff880001300000-0xffff880001302000 8K USR ro x= pte 0xffff880001302000-0xffff88000130d000 44K USR ro x= pte 0xffff88000130d000-0xffff88000130e000 4K USR ro x= pte 0xffff88000130e000-0xffff88000130f000 4K USR ro x= pte 0xffff88000130f000-0xffff880001312000 12K USR ro x= pte 0xffff880001312000-0xffff880001314000 8K USR ro x= pte 0xffff880001314000-0xffff880001318000 16K USR ro x= pte 0xffff880001318000-0xffff88000131b000 12K USR ro x= pte 0xffff88000131b000-0xffff88000131c000 4K USR ro x= pte 0xffff88000131c000-0xffff880001324000 32K USR ro x= pte 0xffff880001324000-0xffff880001329000 20K USR ro x= pte 0xffff880001329000-0xffff88000132d000 16K USR ro x= pte 0xffff88000132d000-0xffff88000132e000 4K USR ro x= pte 0xffff88000132e000-0xffff88000132f000 4K USR ro x= pte 0xffff88000132f000-0xffff880001332000 12K USR ro x= pte 0xffff880001332000-0xffff880001333000 4K USR ro x= pte 0xffff880001333000-0xffff880001334000 4K USR ro x= pte 0xffff880001334000-0xffff880001335000 4K USR ro x= pte 0xffff880001335000-0xffff880001337000 8K USR ro x= pte 0xffff880001337000-0xffff88000133b000 16K USR ro x= pte 0xffff88000133b000-0xffff88000133c000 4K USR ro x= pte 0xffff88000133c000-0xffff880001340000 16K USR ro x= pte 0xffff880001340000-0xffff880001342000 8K USR ro x= pte 0xffff880001342000-0xffff880001343000 4K USR ro x= pte 0xffff880001343000-0xffff880001348000 20K USR ro x= pte 0xffff880001348000-0xffff88000134c000 16K USR ro x= pte 0xffff88000134c000-0xffff880001350000 16K USR ro x= pte 0xffff880001350000-0xffff880001351000 4K USR ro x= pte 0xffff880001351000-0xffff880001353000 8K USR ro x= pte 0xffff880001353000-0xffff880001358000 20K USR ro x= pte 0xffff880001358000-0xffff88000135e000 24K USR ro x= pte 0xffff88000135e000-0xffff88000135f000 4K USR ro x= pte 0xffff88000135f000-0xffff880001361000 8K USR ro x= pte 0xffff880001361000-0xffff880001366000 20K USR ro x= pte 0xffff880001366000-0xffff880001367000 4K USR ro x= pte 0xffff880001367000-0xffff880001368000 4K USR ro x= pte 0xffff880001368000-0xffff88000136a000 8K USR ro x= pte 0xffff88000136a000-0xffff880001374000 40K USR ro x= pte 0xffff880001374000-0xffff880001376000 8K USR ro x= pte 0xffff880001376000-0xffff880001379000 12K USR ro x= pte 0xffff880001379000-0xffff88000137f000 24K USR ro x= pte 0xffff88000137f000-0xffff880001380000 4K USR ro x= pte 0xffff880001380000-0xffff880001383000 12K USR ro x= pte 0xffff880001383000-0xffff880001384000 4K USR ro x= pte 0xffff880001384000-0xffff880001387000 12K USR ro x= pte 0xffff880001387000-0xffff880001389000 8K USR ro x= pte 0xffff880001389000-0xffff88000138c000 12K USR ro x= pte 0xffff88000138c000-0xffff880001393000 28K USR ro x= pte 0xffff880001393000-0xffff880001395000 8K USR ro x= pte 0xffff880001395000-0xffff880001398000 12K USR ro x= pte 0xffff880001398000-0xffff88000139a000 8K USR ro x= pte 0xffff88000139a000-0xffff88000139c000 8K USR ro x= pte 0xffff88000139c000-0xffff88000139d000 4K USR ro x= pte 0xffff88000139d000-0xffff8800013a3000 24K USR ro x= pte 0xffff8800013a3000-0xffff8800013a4000 4K USR ro x= pte 0xffff8800013a4000-0xffff8800013a5000 4K USR ro x= pte 0xffff8800013a5000-0xffff8800013a6000 4K USR ro x= pte 0xffff8800013a6000-0xffff8800013a9000 12K USR ro x= pte 0xffff8800013a9000-0xffff8800013ab000 8K USR ro x= pte 0xffff8800013ab000-0xffff8800013ac000 4K USR ro x= pte 0xffff8800013ac000-0xffff8800013ae000 8K USR ro x= pte 0xffff8800013ae000-0xffff8800013b1000 12K USR ro x= pte 0xffff8800013b1000-0xffff8800013b3000 8K USR ro x= pte 0xffff8800013b3000-0xffff8800013b5000 8K USR ro x= pte 0xffff8800013b5000-0xffff8800013b9000 16K USR ro x= pte 0xffff8800013b9000-0xffff8800013ba000 4K USR ro x= pte 0xffff8800013ba000-0xffff8800013bf000 20K USR ro x= pte 0xffff8800013bf000-0xffff8800013ce000 60K USR ro x= pte 0xffff8800013ce000-0xffff8800013cf000 4K USR ro x= pte 0xffff8800013cf000-0xffff8800013d0000 4K USR ro x= pte 0xffff8800013d0000-0xffff8800013d2000 8K USR ro x= pte 0xffff8800013d2000-0xffff8800013d3000 4K USR ro x= pte 0xffff8800013d3000-0xffff8800013db000 32K USR ro x= pte 0xffff8800013db000-0xffff8800013dc000 4K USR ro x= pte 0xffff8800013dc000-0xffff8800013dd000 4K USR ro x= pte 0xffff8800013dd000-0xffff8800013de000 4K USR ro x= pte 0xffff8800013de000-0xffff8800013e0000 8K USR ro x= pte 0xffff8800013e0000-0xffff8800013e3000 12K USR ro x= pte 0xffff8800013e3000-0xffff8800013e5000 8K USR ro x= pte 0xffff8800013e5000-0xffff8800013e8000 12K USR ro x= pte 0xffff8800013e8000-0xffff8800013ea000 8K USR ro x= pte 0xffff8800013ea000-0xffff8800013ec000 8K USR ro x= pte 0xffff8800013ec000-0xffff8800013ed000 4K USR ro x= pte 0xffff8800013ed000-0xffff8800013ef000 8K USR ro x= pte 0xffff8800013ef000-0xffff8800013f3000 16K USR ro x= pte 0xffff8800013f3000-0xffff8800013f4000 4K USR ro x= pte 0xffff8800013f4000-0xffff8800013f6000 8K USR ro x= pte 0xffff8800013f6000-0xffff8800013f7000 4K USR ro x= pte 0xffff8800013f7000-0xffff8800013fa000 12K USR ro x= pte 0xffff8800013fa000-0xffff8800013fb000 4K USR ro x= pte 0xffff8800013fb000-0xffff8800013fd000 8K USR ro x= pte 0xffff8800013fd000-0xffff8800013fe000 4K USR ro x= pte 0xffff8800013fe000-0xffff880001403000 20K USR ro x= pte 0xffff880001403000-0xffff880001404000 4K USR ro x= pte 0xffff880001404000-0xffff880001406000 8K USR ro x= pte 0xffff880001406000-0xffff880001408000 8K USR ro x= pte 0xffff880001408000-0xffff880001411000 36K USR ro x= pte 0xffff880001411000-0xffff880001412000 4K USR ro x= pte 0xffff880001412000-0xffff880001413000 4K USR ro x= pte 0xffff880001413000-0xffff880001415000 8K USR ro x= pte 0xffff880001415000-0xffff880001416000 4K USR ro x= pte 0xffff880001416000-0xffff880001419000 12K USR ro x= pte 0xffff880001419000-0xffff88000141e000 20K USR ro x= pte 0xffff88000141e000-0xffff880001425000 28K USR ro x= pte 0xffff880001425000-0xffff880001426000 4K USR ro x= pte 0xffff880001426000-0xffff880001428000 8K USR ro x= pte 0xffff880001428000-0xffff88000142f000 28K USR ro x= pte 0xffff88000142f000-0xffff880001430000 4K USR ro x= pte 0xffff880001430000-0xffff880001437000 28K USR ro x= pte 0xffff880001437000-0xffff880001438000 4K USR ro x= pte 0xffff880001438000-0xffff880001439000 4K USR ro x= pte 0xffff880001439000-0xffff88000143d000 16K USR ro x= pte 0xffff88000143d000-0xffff88000143e000 4K USR ro x= pte 0xffff88000143e000-0xffff88000143f000 4K USR ro x= pte 0xffff88000143f000-0xffff880001440000 4K USR ro x= pte 0xffff880001440000-0xffff880001443000 12K USR ro x= pte 0xffff880001443000-0xffff880001445000 8K USR ro x= pte 0xffff880001445000-0xffff880001446000 4K USR ro x= pte 0xffff880001446000-0xffff880001448000 8K USR ro x= pte 0xffff880001448000-0xffff88000144d000 20K USR ro x= pte 0xffff88000144d000-0xffff88000144f000 8K USR ro x= pte 0xffff88000144f000-0xffff880001451000 8K USR ro x= pte 0xffff880001451000-0xffff880001452000 4K USR ro x= pte 0xffff880001452000-0xffff880001458000 24K USR ro x= pte 0xffff880001458000-0xffff880001459000 4K USR ro x= pte 0xffff880001459000-0xffff88000145a000 4K USR ro x= pte 0xffff88000145a000-0xffff88000145c000 8K USR ro x= pte 0xffff88000145c000-0xffff88000145d000 4K USR ro x= pte 0xffff88000145d000-0xffff880001462000 20K USR ro x= pte 0xffff880001462000-0xffff880001463000 4K USR ro x= pte 0xffff880001463000-0xffff880001464000 4K USR ro x= pte 0xffff880001464000-0xffff880001465000 4K USR ro x= pte 0xffff880001465000-0xffff880001467000 8K USR ro x= pte 0xffff880001467000-0xffff880001468000 4K USR ro x= pte 0xffff880001468000-0xffff880001469000 4K USR ro x= pte 0xffff880001469000-0xffff88000146a000 4K USR ro x= pte 0xffff88000146a000-0xffff88000146b000 4K USR ro x= pte 0xffff88000146b000-0xffff880001470000 20K USR ro x= pte 0xffff880001470000-0xffff880001471000 4K USR ro x= pte 0xffff880001471000-0xffff880001473000 8K USR ro x= pte 0xffff880001473000-0xffff880001477000 16K USR ro x= pte 0xffff880001477000-0xffff88000147a000 12K USR ro x= pte 0xffff88000147a000-0xffff88000147b000 4K USR ro x= pte 0xffff88000147b000-0xffff88000147c000 4K USR ro x= pte 0xffff88000147c000-0xffff88000147d000 4K USR ro x= pte 0xffff88000147d000-0xffff880001482000 20K USR ro x= pte 0xffff880001482000-0xffff880001484000 8K USR ro x= pte 0xffff880001484000-0xffff880001485000 4K USR ro x= pte 0xffff880001485000-0xffff880001486000 4K USR ro x= pte 0xffff880001486000-0xffff880001489000 12K USR ro x= pte 0xffff880001489000-0xffff88000148a000 4K USR ro x= pte 0xffff88000148a000-0xffff88000148b000 4K USR ro x= pte 0xffff88000148b000-0xffff88000148c000 4K USR ro x= pte 0xffff88000148c000-0xffff880001499000 52K USR ro x= pte 0xffff880001499000-0xffff88000149a000 4K USR ro x= pte 0xffff88000149a000-0xffff8800014a2000 32K USR ro x= pte 0xffff8800014a2000-0xffff8800014a5000 12K USR ro x= pte 0xffff8800014a5000-0xffff8800014a8000 12K USR ro x= pte 0xffff8800014a8000-0xffff8800014b0000 32K USR ro x= pte 0xffff8800014b0000-0xffff8800014b1000 4K USR ro x= pte 0xffff8800014b1000-0xffff8800014b2000 4K USR ro x= pte 0xffff8800014b2000-0xffff8800014c2000 64K USR ro x= pte 0xffff8800014c2000-0xffff8800014c3000 4K USR ro x= pte 0xffff8800014c3000-0xffff8800014c5000 8K USR ro x= pte 0xffff8800014c5000-0xffff8800014cb000 24K USR ro x= pte 0xffff8800014cb000-0xffff8800014cc000 4K USR ro x= pte 0xffff8800014cc000-0xffff8800014cf000 12K USR ro x= pte 0xffff8800014cf000-0xffff8800014d0000 4K USR ro x= pte 0xffff8800014d0000-0xffff8800014d1000 4K USR ro x= pte 0xffff8800014d1000-0xffff8800014d3000 8K USR ro x= pte 0xffff8800014d3000-0xffff8800014d4000 4K USR ro x= pte 0xffff8800014d4000-0xffff8800014d6000 8K USR ro x= pte 0xffff8800014d6000-0xffff8800014d7000 4K USR ro x= pte 0xffff8800014d7000-0xffff8800014db000 16K USR ro x= pte 0xffff8800014db000-0xffff8800014dc000 4K USR ro x= pte 0xffff8800014dc000-0xffff8800014de000 8K USR ro x= pte 0xffff8800014de000-0xffff8800014df000 4K USR ro x= pte 0xffff8800014df000-0xffff8800014e3000 16K USR ro x= pte 0xffff8800014e3000-0xffff8800014e7000 16K USR ro x= pte 0xffff8800014e7000-0xffff8800014e8000 4K USR ro x= pte 0xffff8800014e8000-0xffff8800014e9000 4K USR ro x= pte 0xffff8800014e9000-0xffff8800014f1000 32K USR ro x= pte 0xffff8800014f1000-0xffff8800014f2000 4K USR ro x= pte 0xffff8800014f2000-0xffff8800014f6000 16K USR ro x= pte 0xffff8800014f6000-0xffff8800014f7000 4K USR ro x= pte 0xffff8800014f7000-0xffff8800014f8000 4K USR ro x= pte 0xffff8800014f8000-0xffff8800014f9000 4K USR ro x= pte 0xffff8800014f9000-0xffff8800014fe000 20K USR ro x= pte 0xffff8800014fe000-0xffff880001503000 20K USR ro x= pte 0xffff880001503000-0xffff880001508000 20K USR ro x= pte 0xffff880001508000-0xffff88000150d000 20K USR ro x= pte 0xffff88000150d000-0xffff880001511000 16K USR ro x= pte 0xffff880001511000-0xffff880001513000 8K USR ro x= pte 0xffff880001513000-0xffff880001514000 4K USR ro x= pte 0xffff880001514000-0xffff880001515000 4K USR ro x= pte 0xffff880001515000-0xffff880001516000 4K USR ro x= pte 0xffff880001516000-0xffff88000151b000 20K USR ro x= pte 0xffff88000151b000-0xffff880001520000 20K USR ro x= pte 0xffff880001520000-0xffff880001521000 4K USR ro x= pte 0xffff880001521000-0xffff880001523000 8K USR ro x= pte 0xffff880001523000-0xffff880001525000 8K USR ro x= pte 0xffff880001525000-0xffff880001526000 4K USR ro x= pte 0xffff880001526000-0xffff880001529000 12K USR ro x= pte 0xffff880001529000-0xffff88000152a000 4K USR ro x= pte 0xffff88000152a000-0xffff88000152b000 4K USR ro x= pte 0xffff88000152b000-0xffff88000152e000 12K USR ro x= pte 0xffff88000152e000-0xffff880001533000 20K USR ro x= pte 0xffff880001533000-0xffff880001535000 8K USR ro x= pte 0xffff880001535000-0xffff880001537000 8K USR ro x= pte 0xffff880001537000-0xffff880001538000 4K USR ro x= pte 0xffff880001538000-0xffff880001539000 4K USR ro x= pte 0xffff880001539000-0xffff88000153b000 8K USR ro x= pte 0xffff88000153b000-0xffff88000153d000 8K USR ro x= pte 0xffff88000153d000-0xffff880001541000 16K USR ro x= pte 0xffff880001541000-0xffff880001542000 4K USR ro x= pte 0xffff880001542000-0xffff880001544000 8K USR ro x= pte 0xffff880001544000-0xffff880001545000 4K USR ro x= pte 0xffff880001545000-0xffff880001547000 8K USR ro x= pte 0xffff880001547000-0xffff880001551000 40K USR ro x= pte 0xffff880001551000-0xffff880001552000 4K USR ro x= pte 0xffff880001552000-0xffff880001554000 8K USR ro x= pte 0xffff880001554000-0xffff880001555000 4K USR ro x= pte 0xffff880001555000-0xffff88000155d000 32K USR ro x= pte 0xffff88000155d000-0xffff88000155f000 8K USR ro x= pte 0xffff88000155f000-0xffff880001563000 16K USR ro x= pte 0xffff880001563000-0xffff880001566000 12K USR ro x= pte 0xffff880001566000-0xffff880001567000 4K USR ro x= pte 0xffff880001567000-0xffff880001568000 4K USR ro x= pte 0xffff880001568000-0xffff88000156a000 8K USR ro x= pte 0xffff88000156a000-0xffff88000156b000 4K USR ro x= pte 0xffff88000156b000-0xffff880001572000 28K USR ro x= pte 0xffff880001572000-0xffff880001573000 4K USR ro x= pte 0xffff880001573000-0xffff880001576000 12K USR ro x= pte 0xffff880001576000-0xffff880001577000 4K USR ro x= pte 0xffff880001577000-0xffff880001578000 4K USR ro x= pte 0xffff880001578000-0xffff880001579000 4K USR ro x= pte 0xffff880001579000-0xffff88000157a000 4K USR ro x= pte 0xffff88000157a000-0xffff88000157b000 4K USR ro x= pte 0xffff88000157b000-0xffff88000157d000 8K USR ro x= pte 0xffff88000157d000-0xffff88000157f000 8K USR ro x= pte 0xffff88000157f000-0xffff880001582000 12K USR ro x= pte 0xffff880001582000-0xffff880001584000 8K USR ro x= pte 0xffff880001584000-0xffff880001586000 8K USR ro x= pte 0xffff880001586000-0xffff880001588000 8K USR ro x= pte 0xffff880001588000-0xffff880001589000 4K USR ro x= pte 0xffff880001589000-0xffff88000158d000 16K USR ro x= pte 0xffff88000158d000-0xffff88000158f000 8K USR ro x= pte 0xffff88000158f000-0xffff880001593000 16K USR ro x= pte 0xffff880001593000-0xffff880001594000 4K USR ro x= pte 0xffff880001594000-0xffff880001595000 4K USR ro x= pte 0xffff880001595000-0xffff880001596000 4K USR ro x= pte 0xffff880001596000-0xffff880001599000 12K USR ro x= pte 0xffff880001599000-0xffff8800015ab000 72K USR ro x= pte 0xffff8800015ab000-0xffff8800015ac000 4K USR ro x= pte 0xffff8800015ac000-0xffff8800015b0000 16K USR ro x= pte 0xffff8800015b0000-0xffff8800015b1000 4K USR ro x= pte 0xffff8800015b1000-0xffff8800015b7000 24K USR ro x= pte 0xffff8800015b7000-0xffff880001600000 292K USR RW N= X pte 0xffff880001600000-0xffff88000179c000 1648K USR ro N= X pte 0xffff88000179c000-0xffff880001800000 400K USR RW N= X pte 0xffff880001800000-0xffff880001802000 8K USR RW x= pte 0xffff880001802000-0xffff880001803000 4K USR RW x= pte 0xffff880001803000-0xffff880001805000 8K USR RW x= pte 0xffff880001805000-0xffff88000180b000 24K USR RW x= pte 0xffff88000180b000-0xffff88000180f000 16K USR ro x= pte 0xffff88000180f000-0xffff880001810000 4K USR RW x= pte 0xffff880001810000-0xffff880001812000 8K USR ro x= pte 0xffff880001812000-0xffff880001813000 4K USR RW x= pte 0xffff880001813000-0xffff880001815000 8K USR RW x= pte 0xffff880001815000-0xffff880001816000 4K USR RW x= pte 0xffff880001816000-0xffff880001818000 8K USR RW x= pte 0xffff880001818000-0xffff88000181a000 8K USR RW x= pte 0xffff88000181a000-0xffff88000181d000 12K USR RW x= pte 0xffff88000181d000-0xffff88000181e000 4K USR RW x= pte 0xffff88000181e000-0xffff880001832000 80K USR RW x= pte 0xffff880001832000-0xffff880001834000 8K USR RW x= pte 0xffff880001834000-0xffff88000183a000 24K USR RW x= pte 0xffff88000183a000-0xffff88000183d000 12K USR RW x= pte 0xffff88000183d000-0xffff880001841000 16K USR RW x= pte 0xffff880001841000-0xffff880001843000 8K USR RW x= pte 0xffff880001843000-0xffff880001845000 8K USR RW x= pte 0xffff880001845000-0xffff880001846000 4K USR RW x= pte 0xffff880001846000-0xffff880001849000 12K USR RW x= pte 0xffff880001849000-0xffff88000184a000 4K USR RW x= pte 0xffff88000184a000-0xffff88000184f000 20K USR RW x= pte 0xffff88000184f000-0xffff880001850000 4K USR RW x= pte 0xffff880001850000-0xffff880001885000 212K USR RW x= pte 0xffff880001885000-0xffff880001938000 716K USR RW N= X pte 0xffff880001938000-0xffff88000193a000 8K USR RW x= pte 0xffff88000193a000-0xffff88000193b000 4K USR ro x= pte 0xffff88000193b000-0xffff88000193d000 8K USR RW x= pte 0xffff88000193d000-0xffff88000193e000 4K USR ro x= pte 0xffff88000193e000-0xffff880001948000 40K USR RW x= pte 0xffff880001948000-0xffff88000194a000 8K USR RW x= pte 0xffff88000194a000-0xffff88000194c000 8K USR RW x= pte 0xffff88000194c000-0xffff88000196c000 128K USR RW x= pte 0xffff88000196c000-0xffff88000196d000 4K USR RW x= pte 0xffff88000196d000-0xffff880001970000 12K USR RW x= pte 0xffff880001970000-0xffff880001971000 4K USR RW x= pte 0xffff880001971000-0xffff880001972000 4K USR RW x= pte 0xffff880001972000-0xffff880001973000 4K USR RW x= pte 0xffff880001973000-0xffff880001975000 8K USR RW x= pte 0xffff880001975000-0xffff880001976000 4K USR RW x= pte 0xffff880001976000-0xffff880001977000 4K USR RW x= pte 0xffff880001977000-0xffff88000197b000 16K USR RW x= pte 0xffff88000197b000-0xffff8800019b9000 248K USR RW x= pte 0xffff8800019b9000-0xffff8800019c0000 28K USR RW x= pte 0xffff8800019c0000-0xffff8800019df000 124K USR RW x= pte 0xffff8800019df000-0xffff8800019e8000 36K USR RW x= pte 0xffff8800019e8000-0xffff8800019f1000 36K USR RW x= pte 0xffff8800019f1000-0xffff8800019f2000 4K USR RW x= pte 0xffff8800019f2000-0xffff8800019f3000 4K USR RW x= pte 0xffff8800019f3000-0xffff8800019f5000 8K USR RW x= pte 0xffff8800019f5000-0xffff8800019f8000 12K USR RW x= pte 0xffff8800019f8000-0xffff880001a0a000 72K USR RW x= pte 0xffff880001a0a000-0xffff880001a0f000 20K USR RW x= pte 0xffff880001a0f000-0xffff880001a1c000 52K USR RW x= pte 0xffff880001a1c000-0xffff880001a1d000 4K USR RW x= pte 0xffff880001a1d000-0xffff880001aa4000 540K USR RW x= pte 0xffff880001aa4000-0xffff880001aa8000 16K USR ro x= pte 0xffff880001aa8000-0xffff880001b28000 512K USR RW x= pte 0xffff880001b28000-0xffff880001e3d000 3156K USR RW x= pte 0xffff880001e3d000-0xffff88000fc93000 227672K USR RW N= X pte 0xffff88000fc93000-0xffff88001f694000 256004K USR RW x= pte 0xffff88001f694000-0xffff88001f696000 8K USR RW x= pte 0xffff88001f696000-0xffff88001f797000 1028K USR ro x= pte 0xffff88001f797000-0xffff88001fc00000 4516K USR RW x= pte 0xffff88001fc00000-0xffff880020400000 8M USR RW x= pte 0xffff880020400000-0xffff8800f057d000 3409396K USR RW N= X pte 0xffff8800f057d000-0xffff8800ff7fb000 248312K USR ro N= X pte 0xffff8800ff7fb000-0xffff881eb3801000 124583960K USR RW N= X pte 0xffff881eb3801000-0xffff881eb3802000 4K USR ro N= X pte 0xffff881eb3802000-0xffff881eb3838000 216K USR RW N= X pte 0xffff881eb3838000-0xffff881eb3839000 4K USR ro N= X pte 0xffff881eb3839000-0xffff881eb384d000 80K USR RW N= X pte 0xffff881eb384d000-0xffff881eb384e000 4K USR ro N= X pte 0xffff881eb384e000-0xffff881eb3888000 232K USR RW N= X pte 0xffff881eb3888000-0xffff881eb3889000 4K USR ro N= X pte 0xffff881eb3889000-0xffff881eb388f000 24K USR RW N= X pte 0xffff881eb388f000-0xffff881eb3892000 12K USR ro N= X pte 0xffff881eb3892000-0xffff881eb3894000 8K USR RW N= X pte 0xffff881eb3894000-0xffff881eb3896000 8K USR ro N= X pte 0xffff881eb3896000-0xffff881eb389a000 16K USR RW N= X pte 0xffff881eb389a000-0xffff881eb389b000 4K USR ro N= X pte 0xffff881eb389b000-0xffff881eb389c000 4K USR RW N= X pte 0xffff881eb389c000-0xffff881eb389d000 4K USR ro N= X pte 0xffff881eb389d000-0xffff881eb389e000 4K USR RW N= X pte 0xffff881eb389e000-0xffff881eb38a0000 8K USR ro N= X pte 0xffff881eb38a0000-0xffff881eb38a3000 12K USR RW N= X pte 0xffff881eb38a3000-0xffff881eb38a7000 16K USR ro N= X pte 0xffff881eb38a7000-0xffff881eb38aa000 12K USR RW N= X pte 0xffff881eb38aa000-0xffff881eb38ac000 8K USR ro N= X pte 0xffff881eb38ac000-0xffff881eb38ae000 8K USR RW N= X pte 0xffff881eb38ae000-0xffff881eb38af000 4K USR ro N= X pte 0xffff881eb38af000-0xffff881eb38bc000 52K USR RW N= X pte 0xffff881eb38bc000-0xffff881eb38c0000 16K USR ro N= X pte 0xffff881eb38c0000-0xffff881eb3c36000 3544K USR RW N= X pte 0xffff881eb3c36000-0xffff881eb3c37000 4K USR ro N= X pte 0xffff881eb3c37000-0xffff881eb3c80000 292K USR RW N= X pte 0xffff881eb3c80000-0xffff881eb3c82000 8K USR ro N= X pte 0xffff881eb3c82000-0xffff881eb3f30000 2744K USR RW N= X pte 0xffff881eb3f30000-0xffff881eb3f34000 16K USR ro N= X pte 0xffff881eb3f34000-0xffff881eb3f52000 120K USR RW N= X pte 0xffff881eb3f52000-0xffff881eb3f54000 8K USR ro N= X pte 0xffff881eb3f54000-0xffff881eb3f61000 52K USR RW N= X pte 0xffff881eb3f61000-0xffff881eb3f62000 4K USR ro N= X pte 0xffff881eb3f62000-0xffff881eb3fae000 304K USR RW N= X pte 0xffff881eb3fae000-0xffff881eb3fb2000 16K USR ro N= X pte 0xffff881eb3fb2000-0xffff881eb3fb3000 4K USR RW N= X pte 0xffff881eb3fb3000-0xffff881eb3fb6000 12K USR ro N= X pte 0xffff881eb3fb6000-0xffff881eb3fb7000 4K USR RW N= X pte 0xffff881eb3fb7000-0xffff881eb3fbf000 32K USR ro N= X pte 0xffff881eb3fbf000-0xffff881eb3fc3000 16K USR RW N= X pte 0xffff881eb3fc3000-0xffff881eb3fca000 28K USR ro N= X pte 0xffff881eb3fca000-0xffff881eb3fcb000 4K USR RW N= X pte 0xffff881eb3fcb000-0xffff881eb3fcc000 4K USR ro N= X pte 0xffff881eb3fcc000-0xffff881eb3fd5000 36K USR RW N= X pte 0xffff881eb3fd5000-0xffff881eb3fd7000 8K USR ro N= X pte 0xffff881eb3fd7000-0xffff881eb3fdb000 16K USR RW N= X pte 0xffff881eb3fdb000-0xffff881eb3fdd000 8K USR ro N= X pte 0xffff881eb3fdd000-0xffff881eb3fef000 72K USR RW N= X pte 0xffff881eb3fef000-0xffff881eb3ff1000 8K USR ro N= X pte 0xffff881eb3ff1000-0xffff881eb3ff3000 8K USR RW N= X pte 0xffff881eb3ff3000-0xffff881eb3ff4000 4K USR ro N= X pte 0xffff881eb3ff4000-0xffff881eb3ff8000 16K USR RW N= X pte 0xffff881eb3ff8000-0xffff881eb3ff9000 4K USR ro N= X pte 0xffff881eb3ff9000-0xffff881eb3ffb000 8K USR RW N= X pte 0xffff881eb3ffb000-0xffff881eb3ffc000 4K USR ro N= X pte 0xffff881eb3ffc000-0xffff881eb4023000 156K USR RW N= X pte 0xffff881eb4023000-0xffff881eb4024000 4K USR ro N= X pte 0xffff881eb4024000-0xffff881eb402b000 28K USR RW N= X pte 0xffff881eb402b000-0xffff881eb4030000 20K USR ro N= X pte 0xffff881eb4030000-0xffff881eb4035000 20K USR RW N= X pte 0xffff881eb4035000-0xffff881eb4037000 8K USR ro N= X pte 0xffff881eb4037000-0xffff881eb4038000 4K USR RW N= X pte 0xffff881eb4038000-0xffff881eb4039000 4K USR ro N= X pte 0xffff881eb4039000-0xffff881eb403a000 4K USR RW N= X pte 0xffff881eb403a000-0xffff881eb403b000 4K USR ro N= X pte 0xffff881eb403b000-0xffff881eb4041000 24K USR RW N= X pte 0xffff881eb4041000-0xffff881eb4044000 12K USR ro N= X pte 0xffff881eb4044000-0xffff881eb431a000 2904K USR RW N= X pte 0xffff881eb431a000-0xffff881eb431c000 8K USR ro N= X pte 0xffff881eb431c000-0xffff881eb4389000 436K USR RW N= X pte 0xffff881eb4389000-0xffff881eb438a000 4K USR ro N= X pte 0xffff881eb438a000-0xffff881eb5a16000 23088K USR RW N= X pte 0xffff881eb5a16000-0xffff881eb5a17000 4K USR ro N= X pte 0xffff881eb5a17000-0xffff881eb5a31000 104K USR RW N= X pte 0xffff881eb5a31000-0xffff881eb5a32000 4K USR ro N= X pte 0xffff881eb5a32000-0xffff881eb5a36000 16K USR RW N= X pte 0xffff881eb5a36000-0xffff881eb5a38000 8K USR ro N= X pte 0xffff881eb5a38000-0xffff881eb5b57000 1148K USR RW N= X pte 0xffff881eb5b57000-0xffff881eb5b58000 4K USR ro N= X pte 0xffff881eb5b58000-0xffff881eb5b5a000 8K USR RW N= X pte 0xffff881eb5b5a000-0xffff881eb5b5d000 12K USR ro N= X pte 0xffff881eb5b5d000-0xffff881eb5b61000 16K USR RW N= X pte 0xffff881eb5b61000-0xffff881eb5b71000 64K USR ro N= X pte 0xffff881eb5b71000-0xffff881eb5b74000 12K USR RW N= X pte 0xffff881eb5b74000-0xffff881eb5b76000 8K USR ro N= X pte 0xffff881eb5b76000-0xffff881eb5b77000 4K USR RW N= X pte 0xffff881eb5b77000-0xffff881eb5b78000 4K USR ro N= X pte 0xffff881eb5b78000-0xffff881eb5b79000 4K USR RW N= X pte 0xffff881eb5b79000-0xffff881eb5b7b000 8K USR ro N= X pte 0xffff881eb5b7b000-0xffff881eb5b7f000 16K USR RW N= X pte 0xffff881eb5b7f000-0xffff881eb5b86000 28K USR ro N= X pte 0xffff881eb5b86000-0xffff881eb5b87000 4K USR RW N= X pte 0xffff881eb5b87000-0xffff881eb5b89000 8K USR ro N= X pte 0xffff881eb5b89000-0xffff881eb5b96000 52K USR RW N= X pte 0xffff881eb5b96000-0xffff881eb5b97000 4K USR ro N= X pte 0xffff881eb5b97000-0xffff881eb5bc9000 200K USR RW N= X pte 0xffff881eb5bc9000-0xffff881eb5bca000 4K USR ro N= X pte 0xffff881eb5bca000-0xffff881eb5bd6000 48K USR RW N= X pte 0xffff881eb5bd6000-0xffff881eb5bd7000 4K USR ro N= X pte 0xffff881eb5bd7000-0xffff881eb5bda000 12K USR RW N= X pte 0xffff881eb5bda000-0xffff881eb5bdb000 4K USR ro N= X pte 0xffff881eb5bdb000-0xffff881eb5bed000 72K USR RW N= X pte 0xffff881eb5bed000-0xffff881eb5bee000 4K USR ro N= X pte 0xffff881eb5bee000-0xffff881eb5bf0000 8K USR RW N= X pte 0xffff881eb5bf0000-0xffff881eb5bf1000 4K USR ro N= X pte 0xffff881eb5bf1000-0xffff881eb5bf8000 28K USR RW N= X pte 0xffff881eb5bf8000-0xffff881eb5bf9000 4K USR ro N= X pte 0xffff881eb5bf9000-0xffff881eb5bfe000 20K USR RW N= X pte 0xffff881eb5bfe000-0xffff881eb5c00000 8K USR ro N= X pte 0xffff881eb5c00000-0xffff881eb7600000 26M USR RW N= X pte 0xffff881eb7600000-0xffff881eb761b000 108K USR ro N= X pte 0xffff881eb761b000-0xffff881eb7622000 28K USR RW N= X pte 0xffff881eb7622000-0xffff881eb7626000 16K USR ro N= X pte 0xffff881eb7626000-0xffff881eb7627000 4K USR RW N= X pte 0xffff881eb7627000-0xffff881eb7628000 4K USR ro N= X pte 0xffff881eb7628000-0xffff881eb7629000 4K USR RW N= X pte 0xffff881eb7629000-0xffff881eb762a000 4K USR ro N= X pte 0xffff881eb762a000-0xffff881eb7631000 28K USR RW N= X pte 0xffff881eb7631000-0xffff881eb7632000 4K USR ro N= X pte 0xffff881eb7632000-0xffff881eb7633000 4K USR RW N= X pte 0xffff881eb7633000-0xffff881eb7634000 4K USR ro N= X pte 0xffff881eb7634000-0xffff881eb7640000 48K USR RW N= X pte 0xffff881eb7640000-0xffff881eb76f4000 720K USR ro N= X pte 0xffff881eb76f4000-0xffff881eb77a9000 724K USR RW N= X pte 0xffff881eb77a9000-0xffff881eb77aa000 4K USR ro N= X pte 0xffff881eb77aa000-0xffff881eb77b4000 40K USR RW N= X pte 0xffff881eb77b4000-0xffff881eb77ba000 24K USR ro N= X pte 0xffff881eb77ba000-0xffff881eb77bb000 4K USR RW N= X pte 0xffff881eb77bb000-0xffff881eb77bc000 4K USR ro N= X pte 0xffff881eb77bc000-0xffff881eb77c8000 48K USR RW N= X pte 0xffff881eb77c8000-0xffff881eb77ca000 8K USR ro N= X pte 0xffff881eb77ca000-0xffff881eb77cb000 4K USR RW N= X pte 0xffff881eb77cb000-0xffff881eb77cc000 4K USR ro N= X pte 0xffff881eb77cc000-0xffff881eb77ce000 8K USR RW N= X pte 0xffff881eb77ce000-0xffff881eb77d0000 8K USR ro N= X pte 0xffff881eb77d0000-0xffff881eb77da000 40K USR RW N= X pte 0xffff881eb77da000-0xffff881eb77dd000 12K USR ro N= X pte 0xffff881eb77dd000-0xffff881eb77df000 8K USR RW N= X pte 0xffff881eb77df000-0xffff881eb77e0000 4K USR ro N= X pte 0xffff881eb77e0000-0xffff881eb77ee000 56K USR RW N= X pte 0xffff881eb77ee000-0xffff881eb77f0000 8K USR ro N= X pte 0xffff881eb77f0000-0xffff881ebb489000 62052K USR RW N= X pte 0xffff881ebb489000-0xffff881ebb48c000 12K USR ro N= X pte 0xffff881ebb48c000-0xffff881ebb48f000 12K USR RW N= X pte 0xffff881ebb48f000-0xffff881ebb491000 8K USR ro N= X pte 0xffff881ebb491000-0xffff881ebb495000 16K USR RW N= X pte 0xffff881ebb495000-0xffff881ebb49a000 20K USR ro N= X pte 0xffff881ebb49a000-0xffff881ebb49c000 8K USR RW N= X pte 0xffff881ebb49c000-0xffff881ebb49d000 4K USR ro N= X pte 0xffff881ebb49d000-0xffff881ebb49e000 4K USR RW N= X pte 0xffff881ebb49e000-0xffff881ebb49f000 4K USR ro N= X pte 0xffff881ebb49f000-0xffff881ebb4a2000 12K USR RW N= X pte 0xffff881ebb4a2000-0xffff881ebb4a3000 4K USR ro N= X pte 0xffff881ebb4a3000-0xffff881ebb4a6000 12K USR RW N= X pte 0xffff881ebb4a6000-0xffff881ebb4a8000 8K USR ro N= X pte 0xffff881ebb4a8000-0xffff881ebb4af000 28K USR RW N= X pte 0xffff881ebb4af000-0xffff881ebb4b0000 4K USR ro N= X pte 0xffff881ebb4b0000-0xffff881ebb4b1000 4K USR RW N= X pte 0xffff881ebb4b1000-0xffff881ebb4b6000 20K USR ro N= X pte 0xffff881ebb4b6000-0xffff881ebb4bf000 36K USR RW N= X pte 0xffff881ebb4bf000-0xffff881ebb4c0000 4K USR ro N= X pte 0xffff881ebb4c0000-0xffff881ebb4c9000 36K USR RW N= X pte 0xffff881ebb4c9000-0xffff881ebb4ca000 4K USR ro N= X pte 0xffff881ebb4ca000-0xffff881ebb4ce000 16K USR RW N= X pte 0xffff881ebb4ce000-0xffff881ebb4cf000 4K USR ro N= X pte 0xffff881ebb4cf000-0xffff881ebb4d0000 4K USR RW N= X pte 0xffff881ebb4d0000-0xffff881ebb4d4000 16K USR ro N= X pte 0xffff881ebb4d4000-0xffff881ebb4d5000 4K USR RW N= X pte 0xffff881ebb4d5000-0xffff881ebb4d6000 4K USR ro N= X pte 0xffff881ebb4d6000-0xffff881ebb4d7000 4K USR RW N= X pte 0xffff881ebb4d7000-0xffff881ebb4d8000 4K USR ro N= X pte 0xffff881ebb4d8000-0xffff881ebb4db000 12K USR RW N= X pte 0xffff881ebb4db000-0xffff881ebb4dc000 4K USR ro N= X pte 0xffff881ebb4dc000-0xffff881ebb4e0000 16K USR RW N= X pte 0xffff881ebb4e0000-0xffff881ebb4e1000 4K USR ro N= X pte 0xffff881ebb4e1000-0xffff881ebb4ea000 36K USR RW N= X pte 0xffff881ebb4ea000-0xffff881ebb4eb000 4K USR ro N= X pte 0xffff881ebb4eb000-0xffff881ebb4f9000 56K USR RW N= X pte 0xffff881ebb4f9000-0xffff881ebb4fa000 4K USR ro N= X pte 0xffff881ebb4fa000-0xffff881ebb4ff000 20K USR RW N= X pte 0xffff881ebb4ff000-0xffff881ebb500000 4K USR ro N= X pte 0xffff881ebb500000-0xffff881ebb684000 1552K USR RW N= X pte 0xffff881ebb684000-0xffff881ebb686000 8K USR ro N= X pte 0xffff881ebb686000-0xffff881ebb68c000 24K USR RW N= X pte 0xffff881ebb68c000-0xffff881ebb68d000 4K USR ro N= X pte 0xffff881ebb68d000-0xffff881ebb68f000 8K USR RW N= X pte 0xffff881ebb68f000-0xffff881ebb690000 4K USR ro N= X pte 0xffff881ebb690000-0xffff881ebb6a6000 88K USR RW N= X pte 0xffff881ebb6a6000-0xffff881ebb6a8000 8K USR ro N= X pte 0xffff881ebb6a8000-0xffff881ebb6b7000 60K USR RW N= X pte 0xffff881ebb6b7000-0xffff881ebb6b8000 4K USR ro N= X pte 0xffff881ebb6b8000-0xffff881ebb6bb000 12K USR RW N= X pte 0xffff881ebb6bb000-0xffff881ebb6bc000 4K USR ro N= X pte 0xffff881ebb6bc000-0xffff881ebb6c4000 32K USR RW N= X pte 0xffff881ebb6c4000-0xffff881ebb6d0000 48K USR ro N= X pte 0xffff881ebb6d0000-0xffff881ebb6d1000 4K USR RW N= X pte 0xffff881ebb6d1000-0xffff881ebb6d4000 12K USR ro N= X pte 0xffff881ebb6d4000-0xffff881ebb6d9000 20K USR RW N= X pte 0xffff881ebb6d9000-0xffff881ebb6db000 8K USR ro N= X pte 0xffff881ebb6db000-0xffff881ebb6de000 12K USR RW N= X pte 0xffff881ebb6de000-0xffff881ebb6df000 4K USR ro N= X pte 0xffff881ebb6df000-0xffff881ebb6e5000 24K USR RW N= X pte 0xffff881ebb6e5000-0xffff881ebb6e6000 4K USR ro N= X pte 0xffff881ebb6e6000-0xffff881ebbf06000 8320K USR RW N= X pte 0xffff881ebbf06000-0xffff881ebbf08000 8K USR ro N= X pte 0xffff881ebbf08000-0xffff881ebbf0e000 24K USR RW N= X pte 0xffff881ebbf0e000-0xffff881ebbf10000 8K USR ro N= X pte 0xffff881ebbf10000-0xffff881ebbf11000 4K USR RW N= X pte 0xffff881ebbf11000-0xffff881ebbf13000 8K USR ro N= X pte 0xffff881ebbf13000-0xffff881ebbf14000 4K USR RW N= X pte 0xffff881ebbf14000-0xffff881ebbf19000 20K USR ro N= X pte 0xffff881ebbf19000-0xffff881ebbf24000 44K USR RW N= X pte 0xffff881ebbf24000-0xffff881ebbf25000 4K USR ro N= X pte 0xffff881ebbf25000-0xffff881ebbf26000 4K USR RW N= X pte 0xffff881ebbf26000-0xffff881ebbf27000 4K USR ro N= X pte 0xffff881ebbf27000-0xffff881ebbf30000 36K USR RW N= X pte 0xffff881ebbf30000-0xffff881ebbf31000 4K USR ro N= X pte 0xffff881ebbf31000-0xffff881ebbf3c000 44K USR RW N= X pte 0xffff881ebbf3c000-0xffff881ebbf3d000 4K USR ro N= X pte 0xffff881ebbf3d000-0xffff881ebbf41000 16K USR RW N= X pte 0xffff881ebbf41000-0xffff881ebbf42000 4K USR ro N= X pte 0xffff881ebbf42000-0xffff881ebbf5e000 112K USR RW N= X pte 0xffff881ebbf5e000-0xffff881ebbf5f000 4K USR ro N= X pte 0xffff881ebbf5f000-0xffff881ebbf68000 36K USR RW N= X pte 0xffff881ebbf68000-0xffff881ebbf69000 4K USR ro N= X pte 0xffff881ebbf69000-0xffff881ebbf81000 96K USR RW N= X pte 0xffff881ebbf81000-0xffff881ebbf83000 8K USR ro N= X pte 0xffff881ebbf83000-0xffff881ebbf84000 4K USR RW N= X pte 0xffff881ebbf84000-0xffff881ebbf86000 8K USR ro N= X pte 0xffff881ebbf86000-0xffff881ebbf8c000 24K USR RW N= X pte 0xffff881ebbf8c000-0xffff881ebbf8d000 4K USR ro N= X pte 0xffff881ebbf8d000-0xffff881ebbf8e000 4K USR RW N= X pte 0xffff881ebbf8e000-0xffff881ebbf8f000 4K USR ro N= X pte 0xffff881ebbf8f000-0xffff881ebbf90000 4K USR RW N= X pte 0xffff881ebbf90000-0xffff881ebbf96000 24K USR ro N= X pte 0xffff881ebbf96000-0xffff881ebbf9c000 24K USR RW N= X pte 0xffff881ebbf9c000-0xffff881ebbfa0000 16K USR ro N= X pte 0xffff881ebbfa0000-0xffff881ebbfa3000 12K USR RW N= X pte 0xffff881ebbfa3000-0xffff881ebbfac000 36K USR ro N= X pte 0xffff881ebbfac000-0xffff881ebbfae000 8K USR RW N= X pte 0xffff881ebbfae000-0xffff881ebbfaf000 4K USR ro N= X pte 0xffff881ebbfaf000-0xffff881ebbfb0000 4K USR RW N= X pte 0xffff881ebbfb0000-0xffff881ebbfb1000 4K USR ro N= X pte 0xffff881ebbfb1000-0xffff881ebbfb2000 4K USR RW N= X pte 0xffff881ebbfb2000-0xffff881ebbfb4000 8K USR ro N= X pte 0xffff881ebbfb4000-0xffff881ebbfc5000 68K USR RW N= X pte 0xffff881ebbfc5000-0xffff881ebbfc7000 8K USR ro N= X pte 0xffff881ebbfc7000-0xffff881ebbfe1000 104K USR RW N= X pte 0xffff881ebbfe1000-0xffff881ebbfe2000 4K USR ro N= X pte 0xffff881ebbfe2000-0xffff881ebbfe5000 12K USR RW N= X pte 0xffff881ebbfe5000-0xffff881ebbfe8000 12K USR ro N= X pte 0xffff881ebbfe8000-0xffff881ebbfed000 20K USR RW N= X pte 0xffff881ebbfed000-0xffff881ebbfee000 4K USR ro N= X pte 0xffff881ebbfee000-0xffff881ebbff2000 16K USR RW N= X pte 0xffff881ebbff2000-0xffff881ebbff3000 4K USR ro N= X pte 0xffff881ebbff3000-0xffff881ebbff6000 12K USR RW N= X pte 0xffff881ebbff6000-0xffff881ebbfff000 36K USR ro N= X pte 0xffff881ebbfff000-0xffff881ebc355000 3416K USR RW N= X pte 0xffff881ebc355000-0xffff881ebc356000 4K USR ro N= X pte 0xffff881ebc356000-0xffff881ebc35c000 24K USR RW N= X pte 0xffff881ebc35c000-0xffff881ebc35e000 8K USR ro N= X pte 0xffff881ebc35e000-0xffff881ebc362000 16K USR RW N= X pte 0xffff881ebc362000-0xffff881ebc364000 8K USR ro N= X pte 0xffff881ebc364000-0xffff881ebc366000 8K USR RW N= X pte 0xffff881ebc366000-0xffff881ebc368000 8K USR ro N= X pte 0xffff881ebc368000-0xffff881ebc372000 40K USR RW N= X pte 0xffff881ebc372000-0xffff881ebc374000 8K USR ro N= X pte 0xffff881ebc374000-0xffff881ebc376000 8K USR RW N= X pte 0xffff881ebc376000-0xffff881ebc377000 4K USR ro N= X pte 0xffff881ebc377000-0xffff881ebc37e000 28K USR RW N= X pte 0xffff881ebc37e000-0xffff881ebc37f000 4K USR ro N= X pte 0xffff881ebc37f000-0xffff881ebc385000 24K USR RW N= X pte 0xffff881ebc385000-0xffff881ebc387000 8K USR ro N= X pte 0xffff881ebc387000-0xffff881ebc388000 4K USR RW N= X pte 0xffff881ebc388000-0xffff881ebc38a000 8K USR ro N= X pte 0xffff881ebc38a000-0xffff881ebc38c000 8K USR RW N= X pte 0xffff881ebc38c000-0xffff881ebc38f000 12K USR ro N= X pte 0xffff881ebc38f000-0xffff881ebc392000 12K USR RW N= X pte 0xffff881ebc392000-0xffff881ebc393000 4K USR ro N= X pte 0xffff881ebc393000-0xffff881ebc395000 8K USR RW N= X pte 0xffff881ebc395000-0xffff881ebc396000 4K USR ro N= X pte 0xffff881ebc396000-0xffff881ebc39c000 24K USR RW N= X pte 0xffff881ebc39c000-0xffff881ebc39e000 8K USR ro N= X pte 0xffff881ebc39e000-0xffff881ebc39f000 4K USR RW N= X pte 0xffff881ebc39f000-0xffff881ebc3a0000 4K USR ro N= X pte 0xffff881ebc3a0000-0xffff881ebc3a2000 8K USR RW N= X pte 0xffff881ebc3a2000-0xffff881ebc3a4000 8K USR ro N= X pte 0xffff881ebc3a4000-0xffff881ebc3a5000 4K USR RW N= X pte 0xffff881ebc3a5000-0xffff881ebc3a6000 4K USR ro N= X pte 0xffff881ebc3a6000-0xffff881ebc3aa000 16K USR RW N= X pte 0xffff881ebc3aa000-0xffff881ebc3ab000 4K USR ro N= X pte 0xffff881ebc3ab000-0xffff881ebc3ad000 8K USR RW N= X pte 0xffff881ebc3ad000-0xffff881ebc3ae000 4K USR ro N= X pte 0xffff881ebc3ae000-0xffff881ebc3af000 4K USR RW N= X pte 0xffff881ebc3af000-0xffff881ebc3b0000 4K USR ro N= X pte 0xffff881ebc3b0000-0xffff881ebc3c5000 84K USR RW N= X pte 0xffff881ebc3c5000-0xffff881ebc3c6000 4K USR ro N= X pte 0xffff881ebc3c6000-0xffff881ebc3d0000 40K USR RW N= X pte 0xffff881ebc3d0000-0xffff881ebc3d2000 8K USR ro N= X pte 0xffff881ebc3d2000-0xffff881ebc3d4000 8K USR RW N= X pte 0xffff881ebc3d4000-0xffff881ebc3d5000 4K USR ro N= X pte 0xffff881ebc3d5000-0xffff881ebc3d8000 12K USR RW N= X pte 0xffff881ebc3d8000-0xffff881ebc3da000 8K USR ro N= X pte 0xffff881ebc3da000-0xffff881ebc3f9000 124K USR RW N= X pte 0xffff881ebc3f9000-0xffff881ebc3fa000 4K USR ro N= X pte 0xffff881ebc3fa000-0xffff881ebe71a000 35968K USR RW N= X pte 0xffff881ebe71a000-0xffff881ebe71d000 12K USR ro N= X pte 0xffff881ebe71d000-0xffff881ebe71e000 4K USR RW N= X pte 0xffff881ebe71e000-0xffff881ebe71f000 4K USR ro N= X pte 0xffff881ebe71f000-0xffff881ebe721000 8K USR RW N= X pte 0xffff881ebe721000-0xffff881ebe723000 8K USR ro N= X pte 0xffff881ebe723000-0xffff881ec1283000 44416K USR RW N= X pte 0xffff881ec1283000-0xffff881ec1400000 1524K USR ro N= X pte 0xffff881ec1400000-0xffff881f3082c000 1822896K USR RW N= X pte 0xffff881f3082c000-0xffff881f3082e000 8K USR ro N= X pte 0xffff881f3082e000-0xffff881f30855000 156K USR RW N= X pte 0xffff881f30855000-0xffff881f30856000 4K USR ro N= X pte 0xffff881f30856000-0xffff881f30d21000 4908K USR RW N= X pte 0xffff881f30d21000-0xffff881f30d22000 4K USR ro N= X pte 0xffff881f30d22000-0xffff881f30f23000 2052K USR RW N= X pte 0xffff881f30f23000-0xffff881f30f24000 4K USR ro N= X pte 0xffff881f30f24000-0xffff881f3121d000 3044K USR RW N= X pte 0xffff881f3121d000-0xffff881f31221000 16K USR ro N= X pte 0xffff881f31221000-0xffff881f31a09000 8096K USR RW N= X pte 0xffff881f31a09000-0xffff881f31a0b000 8K USR ro N= X pte 0xffff881f31a0b000-0xffff881f31cbf000 2768K USR RW N= X pte 0xffff881f31cbf000-0xffff881f31cde000 124K USR ro N= X pte 0xffff881f31cde000-0xffff881f35c5e000 65024K USR RW N= X pte 0xffff881f35c5e000-0xffff881f35c9e000 256K USR ro N= X pte 0xffff881f35c9e000-0xffff881f35cbe000 128K USR RW N= X pte 0xffff881f35cbe000-0xffff881f35cbf000 4K USR ro N= X pte 0xffff881f35cbf000-0xffff881f3e05b000 134768K USR RW N= X pte 0xffff881f3e05b000-0xffff881f3e05e000 12K USR ro N= X pte 0xffff881f3e05e000-0xffff881f3e600000 5768K USR RW N= X pte 0xffff881f3e600000-0xffff881f3e7f2000 1992K USR ro N= X pte 0xffff881f3e7f2000-0xffff881f3efaa000 7904K USR RW N= X pte 0xffff881f3efaa000-0xffff881f3efab000 4K USR ro N= X pte 0xffff881f3efab000-0xffff881f3efc3000 96K USR RW N= X pte 0xffff881f3efc3000-0xffff881f3efc7000 16K USR ro N= X pte 0xffff881f3efc7000-0xffff881f40000000 16612K USR RW N= X pte 0xffff881f40000000-0xffff881f40800000 8M = pte 0xffff881f40800000-0xffff881f80000000 1016M = pmd 0xffff881f80000000-0xffff888000000000 386G = pud 0xffff888000000000-0xffffc90000000000 66048G = pgd ---[ vmalloc() Area ]--- 0xffffc90000000000-0xffffc90008000000 128M USR RW N= X pte 0xffffc90008000000-0xffffc90008001000 4K = pte 0xffffc90008001000-0xffffc90008041000 256K USR RW N= X pte 0xffffc90008041000-0xffffc90008042000 4K = pte 0xffffc90008042000-0xffffc9000c042000 64M USR RW N= X pte 0xffffc9000c042000-0xffffc9000c043000 4K = pte 0xffffc9000c043000-0xffffc9000c063000 128K USR RW N= X pte 0xffffc9000c063000-0xffffc9000c064000 4K = pte 0xffffc9000c064000-0xffffc9000c066000 8K USR RW N= X pte 0xffffc9000c066000-0xffffc9000c068000 8K = pte 0xffffc9000c068000-0xffffc9000c069000 4K USR RW N= X pte 0xffffc9000c069000-0xffffc9000c06d000 16K = pte 0xffffc9000c06d000-0xffffc9000c071000 16K USR RW N= X pte 0xffffc9000c071000-0xffffc9000c072000 4K = pte 0xffffc9000c072000-0xffffc9000c07d000 44K USR RW N= X pte 0xffffc9000c07d000-0xffffc9000c080000 12K = pte 0xffffc9000c080000-0xffffc9000c081000 4K USR RW N= X pte 0xffffc9000c081000-0xffffc9000c0a1000 128K = pte 0xffffc9000c0a1000-0xffffc9000c4a1000 4M USR RW N= X pte 0xffffc9000c4a1000-0xffffc9000c4a2000 4K = pte 0xffffc9000c4a2000-0xffffc9000cca2000 8M USR RW N= X pte 0xffffc9000cca2000-0xffffc9000cca3000 4K = pte 0xffffc9000cca3000-0xffffc9000cda3000 1M USR RW N= X pte 0xffffc9000cda3000-0xffffc9000cda4000 4K = pte 0xffffc9000cda4000-0xffffc9000cfa4000 2M USR RW N= X pte 0xffffc9000cfa4000-0xffffc9000cfa5000 4K = pte 0xffffc9000cfa5000-0xffffc9000d1a5000 2M USR RW N= X pte 0xffffc9000d1a5000-0xffffc9000d1a6000 4K = pte 0xffffc9000d1a6000-0xffffc9000d1b2000 48K USR RW N= X pte 0xffffc9000d1b2000-0xffffc9000d800000 6456K = pte 0xffffc9000d800000-0xffffc90040000000 808M = pmd 0xffffc90040000000-0xffffc98000000000 511G = pud 0xffffc98000000000-0xffffea0000000000 33280G = pgd ---[ Vmemmap ]--- 0xffffea0000000000-0xffffea006d7c0000 1793792K USR RW N= X pte 0xffffea006d7c0000-0xffffea006d800000 256K = pte 0xffffea006d800000-0xffffea0080000000 296M = pmd 0xffffea0080000000-0xffffea8000000000 510G = pud 0xffffea8000000000-0xffffff8000000000 21T = pgd 0xffffff8000000000-0xffffffff80000000 510G = pud ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M = pmd 0xffffffff81000000-0xffffffff81002000 8K USR ro x= pte 0xffffffff81002000-0xffffffff81013000 68K USR ro x= pte 0xffffffff81013000-0xffffffff81015000 8K USR ro x= pte 0xffffffff81015000-0xffffffff81017000 8K USR ro x= pte 0xffffffff81017000-0xffffffff81019000 8K USR ro x= pte 0xffffffff81019000-0xffffffff8101a000 4K USR ro x= pte 0xffffffff8101a000-0xffffffff8101b000 4K USR ro x= pte 0xffffffff8101b000-0xffffffff8101f000 16K USR ro x= pte 0xffffffff8101f000-0xffffffff81028000 36K USR ro x= pte 0xffffffff81028000-0xffffffff8102a000 8K USR ro x= pte 0xffffffff8102a000-0xffffffff8102c000 8K USR ro x= pte 0xffffffff8102c000-0xffffffff8103c000 64K USR ro x= pte 0xffffffff8103c000-0xffffffff8103d000 4K USR ro x= pte 0xffffffff8103d000-0xffffffff81051000 80K USR ro x= pte 0xffffffff81051000-0xffffffff81052000 4K USR ro x= pte 0xffffffff81052000-0xffffffff81057000 20K USR ro x= pte 0xffffffff81057000-0xffffffff81058000 4K USR ro x= pte 0xffffffff81058000-0xffffffff81061000 36K USR ro x= pte 0xffffffff81061000-0xffffffff81063000 8K USR ro x= pte 0xffffffff81063000-0xffffffff8106b000 32K USR ro x= pte 0xffffffff8106b000-0xffffffff8106c000 4K USR ro x= pte 0xffffffff8106c000-0xffffffff81078000 48K USR ro x= pte 0xffffffff81078000-0xffffffff8107a000 8K USR ro x= pte 0xffffffff8107a000-0xffffffff81083000 36K USR ro x= pte 0xffffffff81083000-0xffffffff81084000 4K USR ro x= pte 0xffffffff81084000-0xffffffff8108f000 44K USR ro x= pte 0xffffffff8108f000-0xffffffff81090000 4K USR ro x= pte 0xffffffff81090000-0xffffffff81094000 16K USR ro x= pte 0xffffffff81094000-0xffffffff81097000 12K USR ro x= pte 0xffffffff81097000-0xffffffff810a0000 36K USR ro x= pte 0xffffffff810a0000-0xffffffff810a2000 8K USR ro x= pte 0xffffffff810a2000-0xffffffff810a7000 20K USR ro x= pte 0xffffffff810a7000-0xffffffff810a8000 4K USR ro x= pte 0xffffffff810a8000-0xffffffff810aa000 8K USR ro x= pte 0xffffffff810aa000-0xffffffff810af000 20K USR ro x= pte 0xffffffff810af000-0xffffffff810b4000 20K USR ro x= pte 0xffffffff810b4000-0xffffffff810b6000 8K USR ro x= pte 0xffffffff810b6000-0xffffffff810c0000 40K USR ro x= pte 0xffffffff810c0000-0xffffffff810c4000 16K USR ro x= pte 0xffffffff810c4000-0xffffffff810c6000 8K USR ro x= pte 0xffffffff810c6000-0xffffffff810ca000 16K USR ro x= pte 0xffffffff810ca000-0xffffffff810cc000 8K USR ro x= pte 0xffffffff810cc000-0xffffffff810cd000 4K USR ro x= pte 0xffffffff810cd000-0xffffffff810d5000 32K USR ro x= pte 0xffffffff810d5000-0xffffffff810d9000 16K USR ro x= pte 0xffffffff810d9000-0xffffffff810da000 4K USR ro x= pte 0xffffffff810da000-0xffffffff810db000 4K USR ro x= pte 0xffffffff810db000-0xffffffff810dc000 4K USR ro x= pte 0xffffffff810dc000-0xffffffff810dd000 4K USR ro x= pte 0xffffffff810dd000-0xffffffff810e2000 20K USR ro x= pte 0xffffffff810e2000-0xffffffff810e3000 4K USR ro x= pte 0xffffffff810e3000-0xffffffff810f8000 84K USR ro x= pte 0xffffffff810f8000-0xffffffff810fb000 12K USR ro x= pte 0xffffffff810fb000-0xffffffff81101000 24K USR ro x= pte 0xffffffff81101000-0xffffffff81102000 4K USR ro x= pte 0xffffffff81102000-0xffffffff81106000 16K USR ro x= pte 0xffffffff81106000-0xffffffff81107000 4K USR ro x= pte 0xffffffff81107000-0xffffffff81108000 4K USR ro x= pte 0xffffffff81108000-0xffffffff81109000 4K USR ro x= pte 0xffffffff81109000-0xffffffff81113000 40K USR ro x= pte 0xffffffff81113000-0xffffffff81114000 4K USR ro x= pte 0xffffffff81114000-0xffffffff81117000 12K USR ro x= pte 0xffffffff81117000-0xffffffff81118000 4K USR ro x= pte 0xffffffff81118000-0xffffffff81122000 40K USR ro x= pte 0xffffffff81122000-0xffffffff81124000 8K USR ro x= pte 0xffffffff81124000-0xffffffff81143000 124K USR ro x= pte 0xffffffff81143000-0xffffffff81145000 8K USR ro x= pte 0xffffffff81145000-0xffffffff81166000 132K USR ro x= pte 0xffffffff81166000-0xffffffff81168000 8K USR ro x= pte 0xffffffff81168000-0xffffffff8116d000 20K USR ro x= pte 0xffffffff8116d000-0xffffffff8116e000 4K USR ro x= pte 0xffffffff8116e000-0xffffffff8116f000 4K USR ro x= pte 0xffffffff8116f000-0xffffffff81170000 4K USR ro x= pte 0xffffffff81170000-0xffffffff81174000 16K USR ro x= pte 0xffffffff81174000-0xffffffff81177000 12K USR ro x= pte 0xffffffff81177000-0xffffffff8117a000 12K USR ro x= pte 0xffffffff8117a000-0xffffffff8117e000 16K USR ro x= pte 0xffffffff8117e000-0xffffffff8118d000 60K USR ro x= pte 0xffffffff8118d000-0xffffffff8118e000 4K USR ro x= pte 0xffffffff8118e000-0xffffffff81190000 8K USR ro x= pte 0xffffffff81190000-0xffffffff81191000 4K USR ro x= pte 0xffffffff81191000-0xffffffff81192000 4K USR ro x= pte 0xffffffff81192000-0xffffffff81193000 4K USR ro x= pte 0xffffffff81193000-0xffffffff81194000 4K USR ro x= pte 0xffffffff81194000-0xffffffff81197000 12K USR ro x= pte 0xffffffff81197000-0xffffffff81198000 4K USR ro x= pte 0xffffffff81198000-0xffffffff81199000 4K USR ro x= pte 0xffffffff81199000-0xffffffff811a0000 28K USR ro x= pte 0xffffffff811a0000-0xffffffff811a1000 4K USR ro x= pte 0xffffffff811a1000-0xffffffff811ab000 40K USR ro x= pte 0xffffffff811ab000-0xffffffff811ac000 4K USR ro x= pte 0xffffffff811ac000-0xffffffff811af000 12K USR ro x= pte 0xffffffff811af000-0xffffffff811b1000 8K USR ro x= pte 0xffffffff811b1000-0xffffffff811b4000 12K USR ro x= pte 0xffffffff811b4000-0xffffffff811b5000 4K USR ro x= pte 0xffffffff811b5000-0xffffffff811b9000 16K USR ro x= pte 0xffffffff811b9000-0xffffffff811bb000 8K USR ro x= pte 0xffffffff811bb000-0xffffffff811bd000 8K USR ro x= pte 0xffffffff811bd000-0xffffffff811be000 4K USR ro x= pte 0xffffffff811be000-0xffffffff811c2000 16K USR ro x= pte 0xffffffff811c2000-0xffffffff811c6000 16K USR ro x= pte 0xffffffff811c6000-0xffffffff811c7000 4K USR ro x= pte 0xffffffff811c7000-0xffffffff811c8000 4K USR ro x= pte 0xffffffff811c8000-0xffffffff811c9000 4K USR ro x= pte 0xffffffff811c9000-0xffffffff811ca000 4K USR ro x= pte 0xffffffff811ca000-0xffffffff811cf000 20K USR ro x= pte 0xffffffff811cf000-0xffffffff811d0000 4K USR ro x= pte 0xffffffff811d0000-0xffffffff811d3000 12K USR ro x= pte 0xffffffff811d3000-0xffffffff811d5000 8K USR ro x= pte 0xffffffff811d5000-0xffffffff811d6000 4K USR ro x= pte 0xffffffff811d6000-0xffffffff811d8000 8K USR ro x= pte 0xffffffff811d8000-0xffffffff811d9000 4K USR ro x= pte 0xffffffff811d9000-0xffffffff811da000 4K USR ro x= pte 0xffffffff811da000-0xffffffff811e0000 24K USR ro x= pte 0xffffffff811e0000-0xffffffff811e3000 12K USR ro x= pte 0xffffffff811e3000-0xffffffff811e9000 24K USR ro x= pte 0xffffffff811e9000-0xffffffff811ea000 4K USR ro x= pte 0xffffffff811ea000-0xffffffff811eb000 4K USR ro x= pte 0xffffffff811eb000-0xffffffff811f1000 24K USR ro x= pte 0xffffffff811f1000-0xffffffff811f7000 24K USR ro x= pte 0xffffffff811f7000-0xffffffff811f8000 4K USR ro x= pte 0xffffffff811f8000-0xffffffff811fa000 8K USR ro x= pte 0xffffffff811fa000-0xffffffff811fb000 4K USR ro x= pte 0xffffffff811fb000-0xffffffff811fd000 8K USR ro x= pte 0xffffffff811fd000-0xffffffff811fe000 4K USR ro x= pte 0xffffffff811fe000-0xffffffff81200000 8K USR ro x= pte 0xffffffff81200000-0xffffffff81201000 4K USR ro x= pte 0xffffffff81201000-0xffffffff81203000 8K USR ro x= pte 0xffffffff81203000-0xffffffff81207000 16K USR ro x= pte 0xffffffff81207000-0xffffffff81209000 8K USR ro x= pte 0xffffffff81209000-0xffffffff8120a000 4K USR ro x= pte 0xffffffff8120a000-0xffffffff8120b000 4K USR ro x= pte 0xffffffff8120b000-0xffffffff8120c000 4K USR ro x= pte 0xffffffff8120c000-0xffffffff8120e000 8K USR ro x= pte 0xffffffff8120e000-0xffffffff81223000 84K USR ro x= pte 0xffffffff81223000-0xffffffff81228000 20K USR ro x= pte 0xffffffff81228000-0xffffffff81229000 4K USR ro x= pte 0xffffffff81229000-0xffffffff8123b000 72K USR ro x= pte 0xffffffff8123b000-0xffffffff8123d000 8K USR ro x= pte 0xffffffff8123d000-0xffffffff8123e000 4K USR ro x= pte 0xffffffff8123e000-0xffffffff8123f000 4K USR ro x= pte 0xffffffff8123f000-0xffffffff81242000 12K USR ro x= pte 0xffffffff81242000-0xffffffff81244000 8K USR ro x= pte 0xffffffff81244000-0xffffffff81245000 4K USR ro x= pte 0xffffffff81245000-0xffffffff81247000 8K USR ro x= pte 0xffffffff81247000-0xffffffff81248000 4K USR ro x= pte 0xffffffff81248000-0xffffffff81252000 40K USR ro x= pte 0xffffffff81252000-0xffffffff81253000 4K USR ro x= pte 0xffffffff81253000-0xffffffff81254000 4K USR ro x= pte 0xffffffff81254000-0xffffffff81255000 4K USR ro x= pte 0xffffffff81255000-0xffffffff81258000 12K USR ro x= pte 0xffffffff81258000-0xffffffff81259000 4K USR ro x= pte 0xffffffff81259000-0xffffffff81268000 60K USR ro x= pte 0xffffffff81268000-0xffffffff8126e000 24K USR ro x= pte 0xffffffff8126e000-0xffffffff8126f000 4K USR ro x= pte 0xffffffff8126f000-0xffffffff81272000 12K USR ro x= pte 0xffffffff81272000-0xffffffff81273000 4K USR ro x= pte 0xffffffff81273000-0xffffffff81274000 4K USR ro x= pte 0xffffffff81274000-0xffffffff8127a000 24K USR ro x= pte 0xffffffff8127a000-0xffffffff8127c000 8K USR ro x= pte 0xffffffff8127c000-0xffffffff8127d000 4K USR ro x= pte 0xffffffff8127d000-0xffffffff81285000 32K USR ro x= pte 0xffffffff81285000-0xffffffff81286000 4K USR ro x= pte 0xffffffff81286000-0xffffffff81287000 4K USR ro x= pte 0xffffffff81287000-0xffffffff81288000 4K USR ro x= pte 0xffffffff81288000-0xffffffff81289000 4K USR ro x= pte 0xffffffff81289000-0xffffffff8128d000 16K USR ro x= pte 0xffffffff8128d000-0xffffffff8128f000 8K USR ro x= pte 0xffffffff8128f000-0xffffffff81291000 8K USR ro x= pte 0xffffffff81291000-0xffffffff81292000 4K USR ro x= pte 0xffffffff81292000-0xffffffff8129f000 52K USR ro x= pte 0xffffffff8129f000-0xffffffff812a0000 4K USR ro x= pte 0xffffffff812a0000-0xffffffff812a1000 4K USR ro x= pte 0xffffffff812a1000-0xffffffff812a3000 8K USR ro x= pte 0xffffffff812a3000-0xffffffff812a5000 8K USR ro x= pte 0xffffffff812a5000-0xffffffff812a6000 4K USR ro x= pte 0xffffffff812a6000-0xffffffff812a9000 12K USR ro x= pte 0xffffffff812a9000-0xffffffff812ab000 8K USR ro x= pte 0xffffffff812ab000-0xffffffff812c3000 96K USR ro x= pte 0xffffffff812c3000-0xffffffff812c6000 12K USR ro x= pte 0xffffffff812c6000-0xffffffff812cc000 24K USR ro x= pte 0xffffffff812cc000-0xffffffff812cf000 12K USR ro x= pte 0xffffffff812cf000-0xffffffff812d1000 8K USR ro x= pte 0xffffffff812d1000-0xffffffff812d2000 4K USR ro x= pte 0xffffffff812d2000-0xffffffff812d3000 4K USR ro x= pte 0xffffffff812d3000-0xffffffff812d7000 16K USR ro x= pte 0xffffffff812d7000-0xffffffff812d8000 4K USR ro x= pte 0xffffffff812d8000-0xffffffff812da000 8K USR ro x= pte 0xffffffff812da000-0xffffffff812dc000 8K USR ro x= pte 0xffffffff812dc000-0xffffffff812e1000 20K USR ro x= pte 0xffffffff812e1000-0xffffffff812e3000 8K USR ro x= pte 0xffffffff812e3000-0xffffffff812e4000 4K USR ro x= pte 0xffffffff812e4000-0xffffffff812e5000 4K USR ro x= pte 0xffffffff812e5000-0xffffffff812e6000 4K USR ro x= pte 0xffffffff812e6000-0xffffffff812e7000 4K USR ro x= pte 0xffffffff812e7000-0xffffffff812ed000 24K USR ro x= pte 0xffffffff812ed000-0xffffffff812ee000 4K USR ro x= pte 0xffffffff812ee000-0xffffffff812f9000 44K USR ro x= pte 0xffffffff812f9000-0xffffffff812fa000 4K USR ro x= pte 0xffffffff812fa000-0xffffffff812fe000 16K USR ro x= pte 0xffffffff812fe000-0xffffffff81300000 8K USR ro x= pte 0xffffffff81300000-0xffffffff81302000 8K USR ro x= pte 0xffffffff81302000-0xffffffff8130d000 44K USR ro x= pte 0xffffffff8130d000-0xffffffff8130e000 4K USR ro x= pte 0xffffffff8130e000-0xffffffff8130f000 4K USR ro x= pte 0xffffffff8130f000-0xffffffff81312000 12K USR ro x= pte 0xffffffff81312000-0xffffffff81314000 8K USR ro x= pte 0xffffffff81314000-0xffffffff81318000 16K USR ro x= pte 0xffffffff81318000-0xffffffff8131b000 12K USR ro x= pte 0xffffffff8131b000-0xffffffff8131c000 4K USR ro x= pte 0xffffffff8131c000-0xffffffff81324000 32K USR ro x= pte 0xffffffff81324000-0xffffffff81329000 20K USR ro x= pte 0xffffffff81329000-0xffffffff8132d000 16K USR ro x= pte 0xffffffff8132d000-0xffffffff8132e000 4K USR ro x= pte 0xffffffff8132e000-0xffffffff8132f000 4K USR ro x= pte 0xffffffff8132f000-0xffffffff81332000 12K USR ro x= pte 0xffffffff81332000-0xffffffff81333000 4K USR ro x= pte 0xffffffff81333000-0xffffffff81334000 4K USR ro x= pte 0xffffffff81334000-0xffffffff81335000 4K USR ro x= pte 0xffffffff81335000-0xffffffff81337000 8K USR ro x= pte 0xffffffff81337000-0xffffffff8133b000 16K USR ro x= pte 0xffffffff8133b000-0xffffffff8133c000 4K USR ro x= pte 0xffffffff8133c000-0xffffffff81340000 16K USR ro x= pte 0xffffffff81340000-0xffffffff81342000 8K USR ro x= pte 0xffffffff81342000-0xffffffff81343000 4K USR ro x= pte 0xffffffff81343000-0xffffffff81348000 20K USR ro x= pte 0xffffffff81348000-0xffffffff8134c000 16K USR ro x= pte 0xffffffff8134c000-0xffffffff81350000 16K USR ro x= pte 0xffffffff81350000-0xffffffff81351000 4K USR ro x= pte 0xffffffff81351000-0xffffffff81353000 8K USR ro x= pte 0xffffffff81353000-0xffffffff81358000 20K USR ro x= pte 0xffffffff81358000-0xffffffff8135e000 24K USR ro x= pte 0xffffffff8135e000-0xffffffff8135f000 4K USR ro x= pte 0xffffffff8135f000-0xffffffff81361000 8K USR ro x= pte 0xffffffff81361000-0xffffffff81366000 20K USR ro x= pte 0xffffffff81366000-0xffffffff81367000 4K USR ro x= pte 0xffffffff81367000-0xffffffff81368000 4K USR ro x= pte 0xffffffff81368000-0xffffffff8136a000 8K USR ro x= pte 0xffffffff8136a000-0xffffffff81374000 40K USR ro x= pte 0xffffffff81374000-0xffffffff81376000 8K USR ro x= pte 0xffffffff81376000-0xffffffff81379000 12K USR ro x= pte 0xffffffff81379000-0xffffffff8137f000 24K USR ro x= pte 0xffffffff8137f000-0xffffffff81380000 4K USR ro x= pte 0xffffffff81380000-0xffffffff81383000 12K USR ro x= pte 0xffffffff81383000-0xffffffff81384000 4K USR ro x= pte 0xffffffff81384000-0xffffffff81387000 12K USR ro x= pte 0xffffffff81387000-0xffffffff81389000 8K USR ro x= pte 0xffffffff81389000-0xffffffff8138c000 12K USR ro x= pte 0xffffffff8138c000-0xffffffff81393000 28K USR ro x= pte 0xffffffff81393000-0xffffffff81395000 8K USR ro x= pte 0xffffffff81395000-0xffffffff81398000 12K USR ro x= pte 0xffffffff81398000-0xffffffff8139a000 8K USR ro x= pte 0xffffffff8139a000-0xffffffff8139c000 8K USR ro x= pte 0xffffffff8139c000-0xffffffff8139d000 4K USR ro x= pte 0xffffffff8139d000-0xffffffff813a3000 24K USR ro x= pte 0xffffffff813a3000-0xffffffff813a4000 4K USR ro x= pte 0xffffffff813a4000-0xffffffff813a5000 4K USR ro x= pte 0xffffffff813a5000-0xffffffff813a6000 4K USR ro x= pte 0xffffffff813a6000-0xffffffff813a9000 12K USR ro x= pte 0xffffffff813a9000-0xffffffff813ab000 8K USR ro x= pte 0xffffffff813ab000-0xffffffff813ac000 4K USR ro x= pte 0xffffffff813ac000-0xffffffff813ae000 8K USR ro x= pte 0xffffffff813ae000-0xffffffff813b1000 12K USR ro x= pte 0xffffffff813b1000-0xffffffff813b3000 8K USR ro x= pte 0xffffffff813b3000-0xffffffff813b5000 8K USR ro x= pte 0xffffffff813b5000-0xffffffff813b9000 16K USR ro x= pte 0xffffffff813b9000-0xffffffff813ba000 4K USR ro x= pte 0xffffffff813ba000-0xffffffff813bf000 20K USR ro x= pte 0xffffffff813bf000-0xffffffff813ce000 60K USR ro x= pte 0xffffffff813ce000-0xffffffff813cf000 4K USR ro x= pte 0xffffffff813cf000-0xffffffff813d0000 4K USR ro x= pte 0xffffffff813d0000-0xffffffff813d2000 8K USR ro x= pte 0xffffffff813d2000-0xffffffff813d3000 4K USR ro x= pte 0xffffffff813d3000-0xffffffff813db000 32K USR ro x= pte 0xffffffff813db000-0xffffffff813dc000 4K USR ro x= pte 0xffffffff813dc000-0xffffffff813dd000 4K USR ro x= pte 0xffffffff813dd000-0xffffffff813de000 4K USR ro x= pte 0xffffffff813de000-0xffffffff813e0000 8K USR ro x= pte 0xffffffff813e0000-0xffffffff813e3000 12K USR ro x= pte 0xffffffff813e3000-0xffffffff813e5000 8K USR ro x= pte 0xffffffff813e5000-0xffffffff813e8000 12K USR ro x= pte 0xffffffff813e8000-0xffffffff813ea000 8K USR ro x= pte 0xffffffff813ea000-0xffffffff813ec000 8K USR ro x= pte 0xffffffff813ec000-0xffffffff813ed000 4K USR ro x= pte 0xffffffff813ed000-0xffffffff813ef000 8K USR ro x= pte 0xffffffff813ef000-0xffffffff813f3000 16K USR ro x= pte 0xffffffff813f3000-0xffffffff813f4000 4K USR ro x= pte 0xffffffff813f4000-0xffffffff813f6000 8K USR ro x= pte 0xffffffff813f6000-0xffffffff813f7000 4K USR ro x= pte 0xffffffff813f7000-0xffffffff813fa000 12K USR ro x= pte 0xffffffff813fa000-0xffffffff813fb000 4K USR ro x= pte 0xffffffff813fb000-0xffffffff813fd000 8K USR ro x= pte 0xffffffff813fd000-0xffffffff813fe000 4K USR ro x= pte 0xffffffff813fe000-0xffffffff81403000 20K USR ro x= pte 0xffffffff81403000-0xffffffff81404000 4K USR ro x= pte 0xffffffff81404000-0xffffffff81406000 8K USR ro x= pte 0xffffffff81406000-0xffffffff81408000 8K USR ro x= pte 0xffffffff81408000-0xffffffff81411000 36K USR ro x= pte 0xffffffff81411000-0xffffffff81412000 4K USR ro x= pte 0xffffffff81412000-0xffffffff81413000 4K USR ro x= pte 0xffffffff81413000-0xffffffff81415000 8K USR ro x= pte 0xffffffff81415000-0xffffffff81416000 4K USR ro x= pte 0xffffffff81416000-0xffffffff81419000 12K USR ro x= pte 0xffffffff81419000-0xffffffff8141e000 20K USR ro x= pte 0xffffffff8141e000-0xffffffff81425000 28K USR ro x= pte 0xffffffff81425000-0xffffffff81426000 4K USR ro x= pte 0xffffffff81426000-0xffffffff81428000 8K USR ro x= pte 0xffffffff81428000-0xffffffff8142f000 28K USR ro x= pte 0xffffffff8142f000-0xffffffff81430000 4K USR ro x= pte 0xffffffff81430000-0xffffffff81437000 28K USR ro x= pte 0xffffffff81437000-0xffffffff81438000 4K USR ro x= pte 0xffffffff81438000-0xffffffff81439000 4K USR ro x= pte 0xffffffff81439000-0xffffffff8143d000 16K USR ro x= pte 0xffffffff8143d000-0xffffffff8143e000 4K USR ro x= pte 0xffffffff8143e000-0xffffffff8143f000 4K USR ro x= pte 0xffffffff8143f000-0xffffffff81440000 4K USR ro x= pte 0xffffffff81440000-0xffffffff81443000 12K USR ro x= pte 0xffffffff81443000-0xffffffff81445000 8K USR ro x= pte 0xffffffff81445000-0xffffffff81446000 4K USR ro x= pte 0xffffffff81446000-0xffffffff81448000 8K USR ro x= pte 0xffffffff81448000-0xffffffff8144d000 20K USR ro x= pte 0xffffffff8144d000-0xffffffff8144f000 8K USR ro x= pte 0xffffffff8144f000-0xffffffff81451000 8K USR ro x= pte 0xffffffff81451000-0xffffffff81452000 4K USR ro x= pte 0xffffffff81452000-0xffffffff81458000 24K USR ro x= pte 0xffffffff81458000-0xffffffff81459000 4K USR ro x= pte 0xffffffff81459000-0xffffffff8145a000 4K USR ro x= pte 0xffffffff8145a000-0xffffffff8145c000 8K USR ro x= pte 0xffffffff8145c000-0xffffffff8145d000 4K USR ro x= pte 0xffffffff8145d000-0xffffffff81462000 20K USR ro x= pte 0xffffffff81462000-0xffffffff81463000 4K USR ro x= pte 0xffffffff81463000-0xffffffff81464000 4K USR ro x= pte 0xffffffff81464000-0xffffffff81465000 4K USR ro x= pte 0xffffffff81465000-0xffffffff81467000 8K USR ro x= pte 0xffffffff81467000-0xffffffff81468000 4K USR ro x= pte 0xffffffff81468000-0xffffffff81469000 4K USR ro x= pte 0xffffffff81469000-0xffffffff8146a000 4K USR ro x= pte 0xffffffff8146a000-0xffffffff8146b000 4K USR ro x= pte 0xffffffff8146b000-0xffffffff81470000 20K USR ro x= pte 0xffffffff81470000-0xffffffff81471000 4K USR ro x= pte 0xffffffff81471000-0xffffffff81473000 8K USR ro x= pte 0xffffffff81473000-0xffffffff81477000 16K USR ro x= pte 0xffffffff81477000-0xffffffff8147a000 12K USR ro x= pte 0xffffffff8147a000-0xffffffff8147b000 4K USR ro x= pte 0xffffffff8147b000-0xffffffff8147c000 4K USR ro x= pte 0xffffffff8147c000-0xffffffff8147d000 4K USR ro x= pte 0xffffffff8147d000-0xffffffff81482000 20K USR ro x= pte 0xffffffff81482000-0xffffffff81484000 8K USR ro x= pte 0xffffffff81484000-0xffffffff81485000 4K USR ro x= pte 0xffffffff81485000-0xffffffff81486000 4K USR ro x= pte 0xffffffff81486000-0xffffffff81489000 12K USR ro x= pte 0xffffffff81489000-0xffffffff8148a000 4K USR ro x= pte 0xffffffff8148a000-0xffffffff8148b000 4K USR ro x= pte 0xffffffff8148b000-0xffffffff8148c000 4K USR ro x= pte 0xffffffff8148c000-0xffffffff81499000 52K USR ro x= pte 0xffffffff81499000-0xffffffff8149a000 4K USR ro x= pte 0xffffffff8149a000-0xffffffff814a2000 32K USR ro x= pte 0xffffffff814a2000-0xffffffff814a5000 12K USR ro x= pte 0xffffffff814a5000-0xffffffff814a8000 12K USR ro x= pte 0xffffffff814a8000-0xffffffff814b0000 32K USR ro x= pte 0xffffffff814b0000-0xffffffff814b1000 4K USR ro x= pte 0xffffffff814b1000-0xffffffff814b2000 4K USR ro x= pte 0xffffffff814b2000-0xffffffff814c2000 64K USR ro x= pte 0xffffffff814c2000-0xffffffff814c3000 4K USR ro x= pte 0xffffffff814c3000-0xffffffff814c5000 8K USR ro x= pte 0xffffffff814c5000-0xffffffff814cb000 24K USR ro x= pte 0xffffffff814cb000-0xffffffff814cc000 4K USR ro x= pte 0xffffffff814cc000-0xffffffff814cf000 12K USR ro x= pte 0xffffffff814cf000-0xffffffff814d0000 4K USR ro x= pte 0xffffffff814d0000-0xffffffff814d1000 4K USR ro x= pte 0xffffffff814d1000-0xffffffff814d3000 8K USR ro x= pte 0xffffffff814d3000-0xffffffff814d4000 4K USR ro x= pte 0xffffffff814d4000-0xffffffff814d6000 8K USR ro x= pte 0xffffffff814d6000-0xffffffff814d7000 4K USR ro x= pte 0xffffffff814d7000-0xffffffff814db000 16K USR ro x= pte 0xffffffff814db000-0xffffffff814dc000 4K USR ro x= pte 0xffffffff814dc000-0xffffffff814de000 8K USR ro x= pte 0xffffffff814de000-0xffffffff814df000 4K USR ro x= pte 0xffffffff814df000-0xffffffff814e3000 16K USR ro x= pte 0xffffffff814e3000-0xffffffff814e7000 16K USR ro x= pte 0xffffffff814e7000-0xffffffff814e8000 4K USR ro x= pte 0xffffffff814e8000-0xffffffff814e9000 4K USR ro x= pte 0xffffffff814e9000-0xffffffff814f1000 32K USR ro x= pte 0xffffffff814f1000-0xffffffff814f2000 4K USR ro x= pte 0xffffffff814f2000-0xffffffff814f6000 16K USR ro x= pte 0xffffffff814f6000-0xffffffff814f7000 4K USR ro x= pte 0xffffffff814f7000-0xffffffff814f8000 4K USR ro x= pte 0xffffffff814f8000-0xffffffff814f9000 4K USR ro x= pte 0xffffffff814f9000-0xffffffff814fe000 20K USR ro x= pte 0xffffffff814fe000-0xffffffff81503000 20K USR ro x= pte 0xffffffff81503000-0xffffffff81508000 20K USR ro x= pte 0xffffffff81508000-0xffffffff8150d000 20K USR ro x= pte 0xffffffff8150d000-0xffffffff81511000 16K USR ro x= pte 0xffffffff81511000-0xffffffff81513000 8K USR ro x= pte 0xffffffff81513000-0xffffffff81514000 4K USR ro x= pte 0xffffffff81514000-0xffffffff81515000 4K USR ro x= pte 0xffffffff81515000-0xffffffff81516000 4K USR ro x= pte 0xffffffff81516000-0xffffffff8151b000 20K USR ro x= pte 0xffffffff8151b000-0xffffffff81520000 20K USR ro x= pte 0xffffffff81520000-0xffffffff81521000 4K USR ro x= pte 0xffffffff81521000-0xffffffff81523000 8K USR ro x= pte 0xffffffff81523000-0xffffffff81525000 8K USR ro x= pte 0xffffffff81525000-0xffffffff81526000 4K USR ro x= pte 0xffffffff81526000-0xffffffff81529000 12K USR ro x= pte 0xffffffff81529000-0xffffffff8152a000 4K USR ro x= pte 0xffffffff8152a000-0xffffffff8152b000 4K USR ro x= pte 0xffffffff8152b000-0xffffffff8152e000 12K USR ro x= pte 0xffffffff8152e000-0xffffffff81533000 20K USR ro x= pte 0xffffffff81533000-0xffffffff81535000 8K USR ro x= pte 0xffffffff81535000-0xffffffff81537000 8K USR ro x= pte 0xffffffff81537000-0xffffffff81538000 4K USR ro x= pte 0xffffffff81538000-0xffffffff81539000 4K USR ro x= pte 0xffffffff81539000-0xffffffff8153b000 8K USR ro x= pte 0xffffffff8153b000-0xffffffff8153d000 8K USR ro x= pte 0xffffffff8153d000-0xffffffff81541000 16K USR ro x= pte 0xffffffff81541000-0xffffffff81542000 4K USR ro x= pte 0xffffffff81542000-0xffffffff81544000 8K USR ro x= pte 0xffffffff81544000-0xffffffff81545000 4K USR ro x= pte 0xffffffff81545000-0xffffffff81547000 8K USR ro x= pte 0xffffffff81547000-0xffffffff81551000 40K USR ro x= pte 0xffffffff81551000-0xffffffff81552000 4K USR ro x= pte 0xffffffff81552000-0xffffffff81554000 8K USR ro x= pte 0xffffffff81554000-0xffffffff81555000 4K USR ro x= pte 0xffffffff81555000-0xffffffff8155d000 32K USR ro x= pte 0xffffffff8155d000-0xffffffff8155f000 8K USR ro x= pte 0xffffffff8155f000-0xffffffff81563000 16K USR ro x= pte 0xffffffff81563000-0xffffffff81566000 12K USR ro x= pte 0xffffffff81566000-0xffffffff81567000 4K USR ro x= pte 0xffffffff81567000-0xffffffff81568000 4K USR ro x= pte 0xffffffff81568000-0xffffffff8156a000 8K USR ro x= pte 0xffffffff8156a000-0xffffffff8156b000 4K USR ro x= pte 0xffffffff8156b000-0xffffffff81572000 28K USR ro x= pte 0xffffffff81572000-0xffffffff81573000 4K USR ro x= pte 0xffffffff81573000-0xffffffff81576000 12K USR ro x= pte 0xffffffff81576000-0xffffffff81577000 4K USR ro x= pte 0xffffffff81577000-0xffffffff81578000 4K USR ro x= pte 0xffffffff81578000-0xffffffff81579000 4K USR ro x= pte 0xffffffff81579000-0xffffffff8157a000 4K USR ro x= pte 0xffffffff8157a000-0xffffffff8157b000 4K USR ro x= pte 0xffffffff8157b000-0xffffffff8157d000 8K USR ro x= pte 0xffffffff8157d000-0xffffffff8157f000 8K USR ro x= pte 0xffffffff8157f000-0xffffffff81582000 12K USR ro x= pte 0xffffffff81582000-0xffffffff81584000 8K USR ro x= pte 0xffffffff81584000-0xffffffff81586000 8K USR ro x= pte 0xffffffff81586000-0xffffffff81588000 8K USR ro x= pte 0xffffffff81588000-0xffffffff81589000 4K USR ro x= pte 0xffffffff81589000-0xffffffff8158d000 16K USR ro x= pte 0xffffffff8158d000-0xffffffff8158f000 8K USR ro x= pte 0xffffffff8158f000-0xffffffff81593000 16K USR ro x= pte 0xffffffff81593000-0xffffffff81594000 4K USR ro x= pte 0xffffffff81594000-0xffffffff81595000 4K USR ro x= pte 0xffffffff81595000-0xffffffff81596000 4K USR ro x= pte 0xffffffff81596000-0xffffffff81599000 12K USR ro x= pte 0xffffffff81599000-0xffffffff815ab000 72K USR ro x= pte 0xffffffff815ab000-0xffffffff815ac000 4K USR ro x= pte 0xffffffff815ac000-0xffffffff815b0000 16K USR ro x= pte 0xffffffff815b0000-0xffffffff815b1000 4K USR ro x= pte 0xffffffff815b1000-0xffffffff815b7000 24K USR ro x= pte 0xffffffff815b7000-0xffffffff81600000 292K USR RW N= X pte 0xffffffff81600000-0xffffffff8179c000 1648K USR ro N= X pte 0xffffffff8179c000-0xffffffff81800000 400K USR RW N= X pte 0xffffffff81800000-0xffffffff81802000 8K USR RW x= pte 0xffffffff81802000-0xffffffff81803000 4K USR RW x= pte 0xffffffff81803000-0xffffffff81805000 8K USR RW x= pte 0xffffffff81805000-0xffffffff8180b000 24K USR RW x= pte 0xffffffff8180b000-0xffffffff8180f000 16K USR ro x= pte 0xffffffff8180f000-0xffffffff81810000 4K USR RW x= pte 0xffffffff81810000-0xffffffff81812000 8K USR ro x= pte 0xffffffff81812000-0xffffffff81813000 4K USR RW x= pte 0xffffffff81813000-0xffffffff81815000 8K USR RW x= pte 0xffffffff81815000-0xffffffff81816000 4K USR RW x= pte 0xffffffff81816000-0xffffffff81818000 8K USR RW x= pte 0xffffffff81818000-0xffffffff8181a000 8K USR RW x= pte 0xffffffff8181a000-0xffffffff8181d000 12K USR RW x= pte 0xffffffff8181d000-0xffffffff8181e000 4K USR RW x= pte 0xffffffff8181e000-0xffffffff81832000 80K USR RW x= pte 0xffffffff81832000-0xffffffff81834000 8K USR RW x= pte 0xffffffff81834000-0xffffffff8183a000 24K USR RW x= pte 0xffffffff8183a000-0xffffffff8183d000 12K USR RW x= pte 0xffffffff8183d000-0xffffffff81841000 16K USR RW x= pte 0xffffffff81841000-0xffffffff81843000 8K USR RW x= pte 0xffffffff81843000-0xffffffff81845000 8K USR RW x= pte 0xffffffff81845000-0xffffffff81846000 4K USR RW x= pte 0xffffffff81846000-0xffffffff81849000 12K USR RW x= pte 0xffffffff81849000-0xffffffff8184a000 4K USR RW x= pte 0xffffffff8184a000-0xffffffff8184f000 20K USR RW x= pte 0xffffffff8184f000-0xffffffff81850000 4K USR RW x= pte 0xffffffff81850000-0xffffffff81885000 212K USR RW x= pte 0xffffffff81885000-0xffffffff81938000 716K USR RW N= X pte 0xffffffff81938000-0xffffffff8193a000 8K USR RW x= pte 0xffffffff8193a000-0xffffffff8193b000 4K USR ro x= pte 0xffffffff8193b000-0xffffffff8193d000 8K USR RW x= pte 0xffffffff8193d000-0xffffffff8193e000 4K USR ro x= pte 0xffffffff8193e000-0xffffffff81948000 40K USR RW x= pte 0xffffffff81948000-0xffffffff8194a000 8K USR RW x= pte 0xffffffff8194a000-0xffffffff8194c000 8K USR RW x= pte 0xffffffff8194c000-0xffffffff8196c000 128K USR RW x= pte 0xffffffff8196c000-0xffffffff8196d000 4K USR RW x= pte 0xffffffff8196d000-0xffffffff81970000 12K USR RW x= pte 0xffffffff81970000-0xffffffff81971000 4K USR RW x= pte 0xffffffff81971000-0xffffffff81972000 4K USR RW x= pte 0xffffffff81972000-0xffffffff81973000 4K USR RW x= pte 0xffffffff81973000-0xffffffff81975000 8K USR RW x= pte 0xffffffff81975000-0xffffffff81976000 4K USR RW x= pte 0xffffffff81976000-0xffffffff81977000 4K USR RW x= pte 0xffffffff81977000-0xffffffff8197b000 16K USR RW x= pte 0xffffffff8197b000-0xffffffff819b9000 248K USR RW x= pte 0xffffffff819b9000-0xffffffff819c0000 28K USR RW x= pte 0xffffffff819c0000-0xffffffff819df000 124K USR RW x= pte 0xffffffff819df000-0xffffffff819e8000 36K USR RW x= pte 0xffffffff819e8000-0xffffffff819f1000 36K USR RW x= pte 0xffffffff819f1000-0xffffffff819f2000 4K USR RW x= pte 0xffffffff819f2000-0xffffffff819f3000 4K USR RW x= pte 0xffffffff819f3000-0xffffffff819f5000 8K USR RW x= pte 0xffffffff819f5000-0xffffffff819f8000 12K USR RW x= pte 0xffffffff819f8000-0xffffffff81a0a000 72K USR RW x= pte 0xffffffff81a0a000-0xffffffff81a0f000 20K USR RW x= pte 0xffffffff81a0f000-0xffffffff81a1c000 52K USR RW x= pte 0xffffffff81a1c000-0xffffffff81a1d000 4K USR RW x= pte 0xffffffff81a1d000-0xffffffff81aa4000 540K USR RW x= pte 0xffffffff81aa4000-0xffffffff81aa8000 16K USR ro x= pte 0xffffffff81aa8000-0xffffffff81b28000 512K USR RW x= pte 0xffffffff81b28000-0xffffffff81c00000 864K USR RW x= pte 0xffffffff81c00000-0xffffffff8fc00000 224M = pmd 0xffffffff8fc00000-0xffffffff8fc93000 588K USR RW N= X pte 0xffffffff8fc93000-0xffffffff9f694000 256004K USR RW x= pte 0xffffffff9f694000-0xffffffff9f696000 8K USR RW x= pte 0xffffffff9f696000-0xffffffff9f797000 1028K USR ro x= pte 0xffffffff9f797000-0xffffffff9fc00000 4516K USR RW x= pte 0xffffffff9fc00000-0xffffffffa0000000 4M = pmd ---[ Modules ]--- 0xffffffffa0000000-0xffffffffa0001000 4K USR ro x= pte 0xffffffffa0001000-0xffffffffa0002000 4K USR ro N= X pte 0xffffffffa0002000-0xffffffffa0004000 8K USR RW N= X pte 0xffffffffa0004000-0xffffffffa0008000 16K = pte 0xffffffffa0008000-0xffffffffa0009000 4K USR ro x= pte 0xffffffffa0009000-0xffffffffa000a000 4K USR ro N= X pte 0xffffffffa000a000-0xffffffffa000c000 8K USR RW N= X pte 0xffffffffa000c000-0xffffffffa0010000 16K = pte 0xffffffffa0010000-0xffffffffa0011000 4K USR ro x= pte 0xffffffffa0011000-0xffffffffa0012000 4K USR ro N= X pte 0xffffffffa0012000-0xffffffffa0014000 8K USR RW N= X pte 0xffffffffa0014000-0xffffffffa0018000 16K = pte 0xffffffffa0018000-0xffffffffa0019000 4K USR ro x= pte 0xffffffffa0019000-0xffffffffa001a000 4K USR ro N= X pte 0xffffffffa001a000-0xffffffffa001c000 8K USR RW N= X pte 0xffffffffa001c000-0xffffffffa001d000 4K = pte 0xffffffffa001d000-0xffffffffa001e000 4K USR ro x= pte 0xffffffffa001e000-0xffffffffa001f000 4K USR ro N= X pte 0xffffffffa001f000-0xffffffffa0021000 8K USR RW N= X pte 0xffffffffa0021000-0xffffffffa0022000 4K = pte 0xffffffffa0022000-0xffffffffa0023000 4K USR ro x= pte 0xffffffffa0023000-0xffffffffa0024000 4K USR ro N= X pte 0xffffffffa0024000-0xffffffffa0026000 8K USR RW N= X pte 0xffffffffa0026000-0xffffffffa0027000 4K = pte 0xffffffffa0027000-0xffffffffa0028000 4K USR ro x= pte 0xffffffffa0028000-0xffffffffa0029000 4K USR ro N= X pte 0xffffffffa0029000-0xffffffffa002b000 8K USR RW N= X pte 0xffffffffa002b000-0xffffffffa002c000 4K = pte 0xffffffffa002c000-0xffffffffa002e000 8K USR ro x= pte 0xffffffffa002e000-0xffffffffa002f000 4K USR ro N= X pte 0xffffffffa002f000-0xffffffffa0031000 8K USR RW N= X pte 0xffffffffa0031000-0xffffffffa0036000 20K = pte 0xffffffffa0036000-0xffffffffa003a000 16K USR ro x= pte 0xffffffffa003a000-0xffffffffa003b000 4K USR ro N= X pte 0xffffffffa003b000-0xffffffffa003d000 8K USR RW N= X pte 0xffffffffa003d000-0xffffffffa0042000 20K = pte 0xffffffffa0042000-0xffffffffa0045000 12K USR ro x= pte 0xffffffffa0045000-0xffffffffa0046000 4K USR ro N= X pte 0xffffffffa0046000-0xffffffffa0048000 8K USR RW N= X pte 0xffffffffa0048000-0xffffffffa004d000 20K = pte 0xffffffffa004d000-0xffffffffa004e000 4K USR ro x= pte 0xffffffffa004e000-0xffffffffa004f000 4K USR ro N= X pte 0xffffffffa004f000-0xffffffffa0051000 8K USR RW N= X pte 0xffffffffa0051000-0xffffffffa0052000 4K = pte 0xffffffffa0052000-0xffffffffa0057000 20K USR ro x= pte 0xffffffffa0057000-0xffffffffa0059000 8K USR ro N= X pte 0xffffffffa0059000-0xffffffffa005b000 8K USR RW N= X pte 0xffffffffa005b000-0xffffffffa005c000 4K = pte 0xffffffffa005c000-0xffffffffa005d000 4K USR ro x= pte 0xffffffffa005d000-0xffffffffa005e000 4K USR ro N= X pte 0xffffffffa005e000-0xffffffffa0060000 8K USR RW N= X pte 0xffffffffa0060000-0xffffffffa0061000 4K = pte 0xffffffffa0061000-0xffffffffa006d000 48K USR ro x= pte 0xffffffffa006d000-0xffffffffa0070000 12K USR ro N= X pte 0xffffffffa0070000-0xffffffffa0073000 12K USR RW N= X pte 0xffffffffa0073000-0xffffffffa0074000 4K = pte 0xffffffffa0074000-0xffffffffa0075000 4K USR ro x= pte 0xffffffffa0075000-0xffffffffa0077000 8K USR ro N= X pte 0xffffffffa0077000-0xffffffffa0079000 8K USR RW N= X pte 0xffffffffa0079000-0xffffffffa007c000 12K = pte 0xffffffffa007c000-0xffffffffa007d000 4K USR ro x= pte 0xffffffffa007d000-0xffffffffa007e000 4K USR ro N= X pte 0xffffffffa007e000-0xffffffffa0080000 8K USR RW N= X pte 0xffffffffa0080000-0xffffffffa0081000 4K = pte 0xffffffffa0081000-0xffffffffa0082000 4K USR ro x= pte 0xffffffffa0082000-0xffffffffa0083000 4K USR ro N= X pte 0xffffffffa0083000-0xffffffffa0085000 8K USR RW N= X pte 0xffffffffa0085000-0xffffffffa0086000 4K = pte 0xffffffffa0086000-0xffffffffa008d000 28K USR ro x= pte 0xffffffffa008d000-0xffffffffa008e000 4K USR ro N= X pte 0xffffffffa008e000-0xffffffffa0092000 16K USR RW N= X pte 0xffffffffa0092000-0xffffffffa0097000 20K = pte 0xffffffffa0097000-0xffffffffa0126000 572K USR ro x= pte 0xffffffffa0126000-0xffffffffa014b000 148K USR ro N= X pte 0xffffffffa014b000-0xffffffffa0168000 116K USR RW N= X pte 0xffffffffa0168000-0xffffffffa0169000 4K = pte 0xffffffffa0169000-0xffffffffa016a000 4K USR ro x= pte 0xffffffffa016a000-0xffffffffa016b000 4K USR ro N= X pte 0xffffffffa016b000-0xffffffffa016d000 8K USR RW N= X pte 0xffffffffa016d000-0xffffffffa016e000 4K = pte 0xffffffffa016e000-0xffffffffa016f000 4K USR ro x= pte 0xffffffffa016f000-0xffffffffa0170000 4K USR ro N= X pte 0xffffffffa0170000-0xffffffffa0172000 8K USR RW N= X pte 0xffffffffa0172000-0xffffffffa0173000 4K = pte 0xffffffffa0173000-0xffffffffa0183000 64K USR ro x= pte 0xffffffffa0183000-0xffffffffa0192000 60K USR ro N= X pte 0xffffffffa0192000-0xffffffffa0198000 24K USR RW N= X pte 0xffffffffa0198000-0xffffffffa0199000 4K = pte 0xffffffffa0199000-0xffffffffa019f000 24K USR ro x= pte 0xffffffffa019f000-0xffffffffa01a1000 8K USR ro N= X pte 0xffffffffa01a1000-0xffffffffa01a3000 8K USR RW N= X pte 0xffffffffa01a3000-0xffffffffa01a8000 20K = pte 0xffffffffa01a8000-0xffffffffa01ad000 20K USR ro x= pte 0xffffffffa01ad000-0xffffffffa01af000 8K USR ro N= X pte 0xffffffffa01af000-0xffffffffa01b3000 16K USR RW N= X pte 0xffffffffa01b3000-0xffffffffa01b4000 4K = pte 0xffffffffa01b4000-0xffffffffa01b6000 8K USR ro x= pte 0xffffffffa01b6000-0xffffffffa01b7000 4K USR ro N= X pte 0xffffffffa01b7000-0xffffffffa01b9000 8K USR RW N= X pte 0xffffffffa01b9000-0xffffffffa01ba000 4K = pte 0xffffffffa01ba000-0xffffffffa01bc000 8K USR ro x= pte 0xffffffffa01bc000-0xffffffffa01bd000 4K USR ro N= X pte 0xffffffffa01bd000-0xffffffffa01bf000 8K USR RW N= X pte 0xffffffffa01bf000-0xffffffffa01c4000 20K = pte 0xffffffffa01c4000-0xffffffffa01c5000 4K USR ro x= pte 0xffffffffa01c5000-0xffffffffa01c6000 4K USR ro N= X pte 0xffffffffa01c6000-0xffffffffa01c8000 8K USR RW N= X pte 0xffffffffa01c8000-0xffffffffa01c9000 4K = pte 0xffffffffa01c9000-0xffffffffa01ca000 4K USR ro x= pte 0xffffffffa01ca000-0xffffffffa01cb000 4K USR ro N= X pte 0xffffffffa01cb000-0xffffffffa01cd000 8K USR RW N= X pte 0xffffffffa01cd000-0xffffffffa0200000 204K = pte 0xffffffffa0200000-0xffffffffc0000000 510M = pmd 0xffffffffc0000000-0xffffffffc009b000 620K USR RW x= pte 0xffffffffc009b000-0xffffffffc00a0000 20K USR RW x= pte 0xffffffffc00a0000-0xffffffffc07fb000 7532K USR RW x= pte 0xffffffffc07fb000-0xffffffffc0efc000 7172K USR ro x= pte 0xffffffffc0efc000-0xffffffffc1000000 1040K USR RW x= pte 0xffffffffc1000000-0xffffffffc1002000 8K USR ro x= pte 0xffffffffc1002000-0xffffffffc1013000 68K USR ro x= pte 0xffffffffc1013000-0xffffffffc1015000 8K USR ro x= pte 0xffffffffc1015000-0xffffffffc1017000 8K USR ro x= pte 0xffffffffc1017000-0xffffffffc1019000 8K USR ro x= pte 0xffffffffc1019000-0xffffffffc101a000 4K USR ro x= pte 0xffffffffc101a000-0xffffffffc101b000 4K USR ro x= pte 0xffffffffc101b000-0xffffffffc101f000 16K USR ro x= pte 0xffffffffc101f000-0xffffffffc1028000 36K USR ro x= pte 0xffffffffc1028000-0xffffffffc102a000 8K USR ro x= pte 0xffffffffc102a000-0xffffffffc102c000 8K USR ro x= pte 0xffffffffc102c000-0xffffffffc103c000 64K USR ro x= pte 0xffffffffc103c000-0xffffffffc103d000 4K USR ro x= pte 0xffffffffc103d000-0xffffffffc1051000 80K USR ro x= pte 0xffffffffc1051000-0xffffffffc1052000 4K USR ro x= pte 0xffffffffc1052000-0xffffffffc1057000 20K USR ro x= pte 0xffffffffc1057000-0xffffffffc1058000 4K USR ro x= pte 0xffffffffc1058000-0xffffffffc1061000 36K USR ro x= pte 0xffffffffc1061000-0xffffffffc1063000 8K USR ro x= pte 0xffffffffc1063000-0xffffffffc106b000 32K USR ro x= pte 0xffffffffc106b000-0xffffffffc106c000 4K USR ro x= pte 0xffffffffc106c000-0xffffffffc1078000 48K USR ro x= pte 0xffffffffc1078000-0xffffffffc107a000 8K USR ro x= pte 0xffffffffc107a000-0xffffffffc1083000 36K USR ro x= pte 0xffffffffc1083000-0xffffffffc1084000 4K USR ro x= pte 0xffffffffc1084000-0xffffffffc108f000 44K USR ro x= pte 0xffffffffc108f000-0xffffffffc1090000 4K USR ro x= pte 0xffffffffc1090000-0xffffffffc1094000 16K USR ro x= pte 0xffffffffc1094000-0xffffffffc1097000 12K USR ro x= pte 0xffffffffc1097000-0xffffffffc10a0000 36K USR ro x= pte 0xffffffffc10a0000-0xffffffffc10a2000 8K USR ro x= pte 0xffffffffc10a2000-0xffffffffc10a7000 20K USR ro x= pte 0xffffffffc10a7000-0xffffffffc10a8000 4K USR ro x= pte 0xffffffffc10a8000-0xffffffffc10aa000 8K USR ro x= pte 0xffffffffc10aa000-0xffffffffc10af000 20K USR ro x= pte 0xffffffffc10af000-0xffffffffc10b4000 20K USR ro x= pte 0xffffffffc10b4000-0xffffffffc10b6000 8K USR ro x= pte 0xffffffffc10b6000-0xffffffffc10c0000 40K USR ro x= pte 0xffffffffc10c0000-0xffffffffc10c4000 16K USR ro x= pte 0xffffffffc10c4000-0xffffffffc10c6000 8K USR ro x= pte 0xffffffffc10c6000-0xffffffffc10ca000 16K USR ro x= pte 0xffffffffc10ca000-0xffffffffc10cc000 8K USR ro x= pte 0xffffffffc10cc000-0xffffffffc10cd000 4K USR ro x= pte 0xffffffffc10cd000-0xffffffffc10d5000 32K USR ro x= pte 0xffffffffc10d5000-0xffffffffc10d9000 16K USR ro x= pte 0xffffffffc10d9000-0xffffffffc10da000 4K USR ro x= pte 0xffffffffc10da000-0xffffffffc10db000 4K USR ro x= pte 0xffffffffc10db000-0xffffffffc10dc000 4K USR ro x= pte 0xffffffffc10dc000-0xffffffffc10dd000 4K USR ro x= pte 0xffffffffc10dd000-0xffffffffc10e2000 20K USR ro x= pte 0xffffffffc10e2000-0xffffffffc10e3000 4K USR ro x= pte 0xffffffffc10e3000-0xffffffffc10f8000 84K USR ro x= pte 0xffffffffc10f8000-0xffffffffc10fb000 12K USR ro x= pte 0xffffffffc10fb000-0xffffffffc1101000 24K USR ro x= pte 0xffffffffc1101000-0xffffffffc1102000 4K USR ro x= pte 0xffffffffc1102000-0xffffffffc1106000 16K USR ro x= pte 0xffffffffc1106000-0xffffffffc1107000 4K USR ro x= pte 0xffffffffc1107000-0xffffffffc1108000 4K USR ro x= pte 0xffffffffc1108000-0xffffffffc1109000 4K USR ro x= pte 0xffffffffc1109000-0xffffffffc1113000 40K USR ro x= pte 0xffffffffc1113000-0xffffffffc1114000 4K USR ro x= pte 0xffffffffc1114000-0xffffffffc1117000 12K USR ro x= pte 0xffffffffc1117000-0xffffffffc1118000 4K USR ro x= pte 0xffffffffc1118000-0xffffffffc1122000 40K USR ro x= pte 0xffffffffc1122000-0xffffffffc1124000 8K USR ro x= pte 0xffffffffc1124000-0xffffffffc1143000 124K USR ro x= pte 0xffffffffc1143000-0xffffffffc1145000 8K USR ro x= pte 0xffffffffc1145000-0xffffffffc1166000 132K USR ro x= pte 0xffffffffc1166000-0xffffffffc1168000 8K USR ro x= pte 0xffffffffc1168000-0xffffffffc116d000 20K USR ro x= pte 0xffffffffc116d000-0xffffffffc116e000 4K USR ro x= pte 0xffffffffc116e000-0xffffffffc116f000 4K USR ro x= pte 0xffffffffc116f000-0xffffffffc1170000 4K USR ro x= pte 0xffffffffc1170000-0xffffffffc1174000 16K USR ro x= pte 0xffffffffc1174000-0xffffffffc1177000 12K USR ro x= pte 0xffffffffc1177000-0xffffffffc117a000 12K USR ro x= pte 0xffffffffc117a000-0xffffffffc117e000 16K USR ro x= pte 0xffffffffc117e000-0xffffffffc118d000 60K USR ro x= pte 0xffffffffc118d000-0xffffffffc118e000 4K USR ro x= pte 0xffffffffc118e000-0xffffffffc1190000 8K USR ro x= pte 0xffffffffc1190000-0xffffffffc1191000 4K USR ro x= pte 0xffffffffc1191000-0xffffffffc1192000 4K USR ro x= pte 0xffffffffc1192000-0xffffffffc1193000 4K USR ro x= pte 0xffffffffc1193000-0xffffffffc1194000 4K USR ro x= pte 0xffffffffc1194000-0xffffffffc1197000 12K USR ro x= pte 0xffffffffc1197000-0xffffffffc1198000 4K USR ro x= pte 0xffffffffc1198000-0xffffffffc1199000 4K USR ro x= pte 0xffffffffc1199000-0xffffffffc11a0000 28K USR ro x= pte 0xffffffffc11a0000-0xffffffffc11a1000 4K USR ro x= pte 0xffffffffc11a1000-0xffffffffc11ab000 40K USR ro x= pte 0xffffffffc11ab000-0xffffffffc11ac000 4K USR ro x= pte 0xffffffffc11ac000-0xffffffffc11af000 12K USR ro x= pte 0xffffffffc11af000-0xffffffffc11b1000 8K USR ro x= pte 0xffffffffc11b1000-0xffffffffc11b4000 12K USR ro x= pte 0xffffffffc11b4000-0xffffffffc11b5000 4K USR ro x= pte 0xffffffffc11b5000-0xffffffffc11b9000 16K USR ro x= pte 0xffffffffc11b9000-0xffffffffc11bb000 8K USR ro x= pte 0xffffffffc11bb000-0xffffffffc11bd000 8K USR ro x= pte 0xffffffffc11bd000-0xffffffffc11be000 4K USR ro x= pte 0xffffffffc11be000-0xffffffffc11c2000 16K USR ro x= pte 0xffffffffc11c2000-0xffffffffc11c6000 16K USR ro x= pte 0xffffffffc11c6000-0xffffffffc11c7000 4K USR ro x= pte 0xffffffffc11c7000-0xffffffffc11c8000 4K USR ro x= pte 0xffffffffc11c8000-0xffffffffc11c9000 4K USR ro x= pte 0xffffffffc11c9000-0xffffffffc11ca000 4K USR ro x= pte 0xffffffffc11ca000-0xffffffffc11cf000 20K USR ro x= pte 0xffffffffc11cf000-0xffffffffc11d0000 4K USR ro x= pte 0xffffffffc11d0000-0xffffffffc11d3000 12K USR ro x= pte 0xffffffffc11d3000-0xffffffffc11d5000 8K USR ro x= pte 0xffffffffc11d5000-0xffffffffc11d6000 4K USR ro x= pte 0xffffffffc11d6000-0xffffffffc11d8000 8K USR ro x= pte 0xffffffffc11d8000-0xffffffffc11d9000 4K USR ro x= pte 0xffffffffc11d9000-0xffffffffc11da000 4K USR ro x= pte 0xffffffffc11da000-0xffffffffc11e0000 24K USR ro x= pte 0xffffffffc11e0000-0xffffffffc11e3000 12K USR ro x= pte 0xffffffffc11e3000-0xffffffffc11e9000 24K USR ro x= pte 0xffffffffc11e9000-0xffffffffc11ea000 4K USR ro x= pte 0xffffffffc11ea000-0xffffffffc11eb000 4K USR ro x= pte 0xffffffffc11eb000-0xffffffffc11f1000 24K USR ro x= pte 0xffffffffc11f1000-0xffffffffc11f7000 24K USR ro x= pte 0xffffffffc11f7000-0xffffffffc11f8000 4K USR ro x= pte 0xffffffffc11f8000-0xffffffffc11fa000 8K USR ro x= pte 0xffffffffc11fa000-0xffffffffc11fb000 4K USR ro x= pte 0xffffffffc11fb000-0xffffffffc11fd000 8K USR ro x= pte 0xffffffffc11fd000-0xffffffffc11fe000 4K USR ro x= pte 0xffffffffc11fe000-0xffffffffc1200000 8K USR ro x= pte 0xffffffffc1200000-0xffffffffc1201000 4K USR ro x= pte 0xffffffffc1201000-0xffffffffc1203000 8K USR ro x= pte 0xffffffffc1203000-0xffffffffc1207000 16K USR ro x= pte 0xffffffffc1207000-0xffffffffc1209000 8K USR ro x= pte 0xffffffffc1209000-0xffffffffc120a000 4K USR ro x= pte 0xffffffffc120a000-0xffffffffc120b000 4K USR ro x= pte 0xffffffffc120b000-0xffffffffc120c000 4K USR ro x= pte 0xffffffffc120c000-0xffffffffc120e000 8K USR ro x= pte 0xffffffffc120e000-0xffffffffc1223000 84K USR ro x= pte 0xffffffffc1223000-0xffffffffc1228000 20K USR ro x= pte 0xffffffffc1228000-0xffffffffc1229000 4K USR ro x= pte 0xffffffffc1229000-0xffffffffc123b000 72K USR ro x= pte 0xffffffffc123b000-0xffffffffc123d000 8K USR ro x= pte 0xffffffffc123d000-0xffffffffc123e000 4K USR ro x= pte 0xffffffffc123e000-0xffffffffc123f000 4K USR ro x= pte 0xffffffffc123f000-0xffffffffc1242000 12K USR ro x= pte 0xffffffffc1242000-0xffffffffc1244000 8K USR ro x= pte 0xffffffffc1244000-0xffffffffc1245000 4K USR ro x= pte 0xffffffffc1245000-0xffffffffc1247000 8K USR ro x= pte 0xffffffffc1247000-0xffffffffc1248000 4K USR ro x= pte 0xffffffffc1248000-0xffffffffc1252000 40K USR ro x= pte 0xffffffffc1252000-0xffffffffc1253000 4K USR ro x= pte 0xffffffffc1253000-0xffffffffc1254000 4K USR ro x= pte 0xffffffffc1254000-0xffffffffc1255000 4K USR ro x= pte 0xffffffffc1255000-0xffffffffc1258000 12K USR ro x= pte 0xffffffffc1258000-0xffffffffc1259000 4K USR ro x= pte 0xffffffffc1259000-0xffffffffc1268000 60K USR ro x= pte 0xffffffffc1268000-0xffffffffc126e000 24K USR ro x= pte 0xffffffffc126e000-0xffffffffc126f000 4K USR ro x= pte 0xffffffffc126f000-0xffffffffc1272000 12K USR ro x= pte 0xffffffffc1272000-0xffffffffc1273000 4K USR ro x= pte 0xffffffffc1273000-0xffffffffc1274000 4K USR ro x= pte 0xffffffffc1274000-0xffffffffc127a000 24K USR ro x= pte 0xffffffffc127a000-0xffffffffc127c000 8K USR ro x= pte 0xffffffffc127c000-0xffffffffc127d000 4K USR ro x= pte 0xffffffffc127d000-0xffffffffc1285000 32K USR ro x= pte 0xffffffffc1285000-0xffffffffc1286000 4K USR ro x= pte 0xffffffffc1286000-0xffffffffc1287000 4K USR ro x= pte 0xffffffffc1287000-0xffffffffc1288000 4K USR ro x= pte 0xffffffffc1288000-0xffffffffc1289000 4K USR ro x= pte 0xffffffffc1289000-0xffffffffc128d000 16K USR ro x= pte 0xffffffffc128d000-0xffffffffc128f000 8K USR ro x= pte 0xffffffffc128f000-0xffffffffc1291000 8K USR ro x= pte 0xffffffffc1291000-0xffffffffc1292000 4K USR ro x= pte 0xffffffffc1292000-0xffffffffc129f000 52K USR ro x= pte 0xffffffffc129f000-0xffffffffc12a0000 4K USR ro x= pte 0xffffffffc12a0000-0xffffffffc12a1000 4K USR ro x= pte 0xffffffffc12a1000-0xffffffffc12a3000 8K USR ro x= pte 0xffffffffc12a3000-0xffffffffc12a5000 8K USR ro x= pte 0xffffffffc12a5000-0xffffffffc12a6000 4K USR ro x= pte 0xffffffffc12a6000-0xffffffffc12a9000 12K USR ro x= pte 0xffffffffc12a9000-0xffffffffc12ab000 8K USR ro x= pte 0xffffffffc12ab000-0xffffffffc12c3000 96K USR ro x= pte 0xffffffffc12c3000-0xffffffffc12c6000 12K USR ro x= pte 0xffffffffc12c6000-0xffffffffc12cc000 24K USR ro x= pte 0xffffffffc12cc000-0xffffffffc12cf000 12K USR ro x= pte 0xffffffffc12cf000-0xffffffffc12d1000 8K USR ro x= pte 0xffffffffc12d1000-0xffffffffc12d2000 4K USR ro x= pte 0xffffffffc12d2000-0xffffffffc12d3000 4K USR ro x= pte 0xffffffffc12d3000-0xffffffffc12d7000 16K USR ro x= pte 0xffffffffc12d7000-0xffffffffc12d8000 4K USR ro x= pte 0xffffffffc12d8000-0xffffffffc12da000 8K USR ro x= pte 0xffffffffc12da000-0xffffffffc12dc000 8K USR ro x= pte 0xffffffffc12dc000-0xffffffffc12e1000 20K USR ro x= pte 0xffffffffc12e1000-0xffffffffc12e3000 8K USR ro x= pte 0xffffffffc12e3000-0xffffffffc12e4000 4K USR ro x= pte 0xffffffffc12e4000-0xffffffffc12e5000 4K USR ro x= pte 0xffffffffc12e5000-0xffffffffc12e6000 4K USR ro x= pte 0xffffffffc12e6000-0xffffffffc12e7000 4K USR ro x= pte 0xffffffffc12e7000-0xffffffffc12ed000 24K USR ro x= pte 0xffffffffc12ed000-0xffffffffc12ee000 4K USR ro x= pte 0xffffffffc12ee000-0xffffffffc12f9000 44K USR ro x= pte 0xffffffffc12f9000-0xffffffffc12fa000 4K USR ro x= pte 0xffffffffc12fa000-0xffffffffc12fe000 16K USR ro x= pte 0xffffffffc12fe000-0xffffffffc1300000 8K USR ro x= pte 0xffffffffc1300000-0xffffffffc1302000 8K USR ro x= pte 0xffffffffc1302000-0xffffffffc130d000 44K USR ro x= pte 0xffffffffc130d000-0xffffffffc130e000 4K USR ro x= pte 0xffffffffc130e000-0xffffffffc130f000 4K USR ro x= pte 0xffffffffc130f000-0xffffffffc1312000 12K USR ro x= pte 0xffffffffc1312000-0xffffffffc1314000 8K USR ro x= pte 0xffffffffc1314000-0xffffffffc1318000 16K USR ro x= pte 0xffffffffc1318000-0xffffffffc131b000 12K USR ro x= pte 0xffffffffc131b000-0xffffffffc131c000 4K USR ro x= pte 0xffffffffc131c000-0xffffffffc1324000 32K USR ro x= pte 0xffffffffc1324000-0xffffffffc1329000 20K USR ro x= pte 0xffffffffc1329000-0xffffffffc132d000 16K USR ro x= pte 0xffffffffc132d000-0xffffffffc132e000 4K USR ro x= pte 0xffffffffc132e000-0xffffffffc132f000 4K USR ro x= pte 0xffffffffc132f000-0xffffffffc1332000 12K USR ro x= pte 0xffffffffc1332000-0xffffffffc1333000 4K USR ro x= pte 0xffffffffc1333000-0xffffffffc1334000 4K USR ro x= pte 0xffffffffc1334000-0xffffffffc1335000 4K USR ro x= pte 0xffffffffc1335000-0xffffffffc1337000 8K USR ro x= pte 0xffffffffc1337000-0xffffffffc133b000 16K USR ro x= pte 0xffffffffc133b000-0xffffffffc133c000 4K USR ro x= pte 0xffffffffc133c000-0xffffffffc1340000 16K USR ro x= pte 0xffffffffc1340000-0xffffffffc1342000 8K USR ro x= pte 0xffffffffc1342000-0xffffffffc1343000 4K USR ro x= pte 0xffffffffc1343000-0xffffffffc1348000 20K USR ro x= pte 0xffffffffc1348000-0xffffffffc134c000 16K USR ro x= pte 0xffffffffc134c000-0xffffffffc1350000 16K USR ro x= pte 0xffffffffc1350000-0xffffffffc1351000 4K USR ro x= pte 0xffffffffc1351000-0xffffffffc1353000 8K USR ro x= pte 0xffffffffc1353000-0xffffffffc1358000 20K USR ro x= pte 0xffffffffc1358000-0xffffffffc135e000 24K USR ro x= pte 0xffffffffc135e000-0xffffffffc135f000 4K USR ro x= pte 0xffffffffc135f000-0xffffffffc1361000 8K USR ro x= pte 0xffffffffc1361000-0xffffffffc1366000 20K USR ro x= pte 0xffffffffc1366000-0xffffffffc1367000 4K USR ro x= pte 0xffffffffc1367000-0xffffffffc1368000 4K USR ro x= pte 0xffffffffc1368000-0xffffffffc136a000 8K USR ro x= pte 0xffffffffc136a000-0xffffffffc1374000 40K USR ro x= pte 0xffffffffc1374000-0xffffffffc1376000 8K USR ro x= pte 0xffffffffc1376000-0xffffffffc1379000 12K USR ro x= pte 0xffffffffc1379000-0xffffffffc137f000 24K USR ro x= pte 0xffffffffc137f000-0xffffffffc1380000 4K USR ro x= pte 0xffffffffc1380000-0xffffffffc1383000 12K USR ro x= pte 0xffffffffc1383000-0xffffffffc1384000 4K USR ro x= pte 0xffffffffc1384000-0xffffffffc1387000 12K USR ro x= pte 0xffffffffc1387000-0xffffffffc1389000 8K USR ro x= pte 0xffffffffc1389000-0xffffffffc138c000 12K USR ro x= pte 0xffffffffc138c000-0xffffffffc1393000 28K USR ro x= pte 0xffffffffc1393000-0xffffffffc1395000 8K USR ro x= pte 0xffffffffc1395000-0xffffffffc1398000 12K USR ro x= pte 0xffffffffc1398000-0xffffffffc139a000 8K USR ro x= pte 0xffffffffc139a000-0xffffffffc139c000 8K USR ro x= pte 0xffffffffc139c000-0xffffffffc139d000 4K USR ro x= pte 0xffffffffc139d000-0xffffffffc13a3000 24K USR ro x= pte 0xffffffffc13a3000-0xffffffffc13a4000 4K USR ro x= pte 0xffffffffc13a4000-0xffffffffc13a5000 4K USR ro x= pte 0xffffffffc13a5000-0xffffffffc13a6000 4K USR ro x= pte 0xffffffffc13a6000-0xffffffffc13a9000 12K USR ro x= pte 0xffffffffc13a9000-0xffffffffc13ab000 8K USR ro x= pte 0xffffffffc13ab000-0xffffffffc13ac000 4K USR ro x= pte 0xffffffffc13ac000-0xffffffffc13ae000 8K USR ro x= pte 0xffffffffc13ae000-0xffffffffc13b1000 12K USR ro x= pte 0xffffffffc13b1000-0xffffffffc13b3000 8K USR ro x= pte 0xffffffffc13b3000-0xffffffffc13b5000 8K USR ro x= pte 0xffffffffc13b5000-0xffffffffc13b9000 16K USR ro x= pte 0xffffffffc13b9000-0xffffffffc13ba000 4K USR ro x= pte 0xffffffffc13ba000-0xffffffffc13bf000 20K USR ro x= pte 0xffffffffc13bf000-0xffffffffc13ce000 60K USR ro x= pte 0xffffffffc13ce000-0xffffffffc13cf000 4K USR ro x= pte 0xffffffffc13cf000-0xffffffffc13d0000 4K USR ro x= pte 0xffffffffc13d0000-0xffffffffc13d2000 8K USR ro x= pte 0xffffffffc13d2000-0xffffffffc13d3000 4K USR ro x= pte 0xffffffffc13d3000-0xffffffffc13db000 32K USR ro x= pte 0xffffffffc13db000-0xffffffffc13dc000 4K USR ro x= pte 0xffffffffc13dc000-0xffffffffc13dd000 4K USR ro x= pte 0xffffffffc13dd000-0xffffffffc13de000 4K USR ro x= pte 0xffffffffc13de000-0xffffffffc13e0000 8K USR ro x= pte 0xffffffffc13e0000-0xffffffffc13e3000 12K USR ro x= pte 0xffffffffc13e3000-0xffffffffc13e5000 8K USR ro x= pte 0xffffffffc13e5000-0xffffffffc13e8000 12K USR ro x= pte 0xffffffffc13e8000-0xffffffffc13ea000 8K USR ro x= pte 0xffffffffc13ea000-0xffffffffc13ec000 8K USR ro x= pte 0xffffffffc13ec000-0xffffffffc13ed000 4K USR ro x= pte 0xffffffffc13ed000-0xffffffffc13ef000 8K USR ro x= pte 0xffffffffc13ef000-0xffffffffc13f3000 16K USR ro x= pte 0xffffffffc13f3000-0xffffffffc13f4000 4K USR ro x= pte 0xffffffffc13f4000-0xffffffffc13f6000 8K USR ro x= pte 0xffffffffc13f6000-0xffffffffc13f7000 4K USR ro x= pte 0xffffffffc13f7000-0xffffffffc13fa000 12K USR ro x= pte 0xffffffffc13fa000-0xffffffffc13fb000 4K USR ro x= pte 0xffffffffc13fb000-0xffffffffc13fd000 8K USR ro x= pte 0xffffffffc13fd000-0xffffffffc13fe000 4K USR ro x= pte 0xffffffffc13fe000-0xffffffffc1403000 20K USR ro x= pte 0xffffffffc1403000-0xffffffffc1404000 4K USR ro x= pte 0xffffffffc1404000-0xffffffffc1406000 8K USR ro x= pte 0xffffffffc1406000-0xffffffffc1408000 8K USR ro x= pte 0xffffffffc1408000-0xffffffffc1411000 36K USR ro x= pte 0xffffffffc1411000-0xffffffffc1412000 4K USR ro x= pte 0xffffffffc1412000-0xffffffffc1413000 4K USR ro x= pte 0xffffffffc1413000-0xffffffffc1415000 8K USR ro x= pte 0xffffffffc1415000-0xffffffffc1416000 4K USR ro x= pte 0xffffffffc1416000-0xffffffffc1419000 12K USR ro x= pte 0xffffffffc1419000-0xffffffffc141e000 20K USR ro x= pte 0xffffffffc141e000-0xffffffffc1425000 28K USR ro x= pte 0xffffffffc1425000-0xffffffffc1426000 4K USR ro x= pte 0xffffffffc1426000-0xffffffffc1428000 8K USR ro x= pte 0xffffffffc1428000-0xffffffffc142f000 28K USR ro x= pte 0xffffffffc142f000-0xffffffffc1430000 4K USR ro x= pte 0xffffffffc1430000-0xffffffffc1437000 28K USR ro x= pte 0xffffffffc1437000-0xffffffffc1438000 4K USR ro x= pte 0xffffffffc1438000-0xffffffffc1439000 4K USR ro x= pte 0xffffffffc1439000-0xffffffffc143d000 16K USR ro x= pte 0xffffffffc143d000-0xffffffffc143e000 4K USR ro x= pte 0xffffffffc143e000-0xffffffffc143f000 4K USR ro x= pte 0xffffffffc143f000-0xffffffffc1440000 4K USR ro x= pte 0xffffffffc1440000-0xffffffffc1443000 12K USR ro x= pte 0xffffffffc1443000-0xffffffffc1445000 8K USR ro x= pte 0xffffffffc1445000-0xffffffffc1446000 4K USR ro x= pte 0xffffffffc1446000-0xffffffffc1448000 8K USR ro x= pte 0xffffffffc1448000-0xffffffffc144d000 20K USR ro x= pte 0xffffffffc144d000-0xffffffffc144f000 8K USR ro x= pte 0xffffffffc144f000-0xffffffffc1451000 8K USR ro x= pte 0xffffffffc1451000-0xffffffffc1452000 4K USR ro x= pte 0xffffffffc1452000-0xffffffffc1458000 24K USR ro x= pte 0xffffffffc1458000-0xffffffffc1459000 4K USR ro x= pte 0xffffffffc1459000-0xffffffffc145a000 4K USR ro x= pte 0xffffffffc145a000-0xffffffffc145c000 8K USR ro x= pte 0xffffffffc145c000-0xffffffffc145d000 4K USR ro x= pte 0xffffffffc145d000-0xffffffffc1462000 20K USR ro x= pte 0xffffffffc1462000-0xffffffffc1463000 4K USR ro x= pte 0xffffffffc1463000-0xffffffffc1464000 4K USR ro x= pte 0xffffffffc1464000-0xffffffffc1465000 4K USR ro x= pte 0xffffffffc1465000-0xffffffffc1467000 8K USR ro x= pte 0xffffffffc1467000-0xffffffffc1468000 4K USR ro x= pte 0xffffffffc1468000-0xffffffffc1469000 4K USR ro x= pte 0xffffffffc1469000-0xffffffffc146a000 4K USR ro x= pte 0xffffffffc146a000-0xffffffffc146b000 4K USR ro x= pte 0xffffffffc146b000-0xffffffffc1470000 20K USR ro x= pte 0xffffffffc1470000-0xffffffffc1471000 4K USR ro x= pte 0xffffffffc1471000-0xffffffffc1473000 8K USR ro x= pte 0xffffffffc1473000-0xffffffffc1477000 16K USR ro x= pte 0xffffffffc1477000-0xffffffffc147a000 12K USR ro x= pte 0xffffffffc147a000-0xffffffffc147b000 4K USR ro x= pte 0xffffffffc147b000-0xffffffffc147c000 4K USR ro x= pte 0xffffffffc147c000-0xffffffffc147d000 4K USR ro x= pte 0xffffffffc147d000-0xffffffffc1482000 20K USR ro x= pte 0xffffffffc1482000-0xffffffffc1484000 8K USR ro x= pte 0xffffffffc1484000-0xffffffffc1485000 4K USR ro x= pte 0xffffffffc1485000-0xffffffffc1486000 4K USR ro x= pte 0xffffffffc1486000-0xffffffffc1489000 12K USR ro x= pte 0xffffffffc1489000-0xffffffffc148a000 4K USR ro x= pte 0xffffffffc148a000-0xffffffffc148b000 4K USR ro x= pte 0xffffffffc148b000-0xffffffffc148c000 4K USR ro x= pte 0xffffffffc148c000-0xffffffffc1499000 52K USR ro x= pte 0xffffffffc1499000-0xffffffffc149a000 4K USR ro x= pte 0xffffffffc149a000-0xffffffffc14a2000 32K USR ro x= pte 0xffffffffc14a2000-0xffffffffc14a5000 12K USR ro x= pte 0xffffffffc14a5000-0xffffffffc14a8000 12K USR ro x= pte 0xffffffffc14a8000-0xffffffffc14b0000 32K USR ro x= pte 0xffffffffc14b0000-0xffffffffc14b1000 4K USR ro x= pte 0xffffffffc14b1000-0xffffffffc14b2000 4K USR ro x= pte 0xffffffffc14b2000-0xffffffffc14c2000 64K USR ro x= pte 0xffffffffc14c2000-0xffffffffc14c3000 4K USR ro x= pte 0xffffffffc14c3000-0xffffffffc14c5000 8K USR ro x= pte 0xffffffffc14c5000-0xffffffffc14cb000 24K USR ro x= pte 0xffffffffc14cb000-0xffffffffc14cc000 4K USR ro x= pte 0xffffffffc14cc000-0xffffffffc14cf000 12K USR ro x= pte 0xffffffffc14cf000-0xffffffffc14d0000 4K USR ro x= pte 0xffffffffc14d0000-0xffffffffc14d1000 4K USR ro x= pte 0xffffffffc14d1000-0xffffffffc14d3000 8K USR ro x= pte 0xffffffffc14d3000-0xffffffffc14d4000 4K USR ro x= pte 0xffffffffc14d4000-0xffffffffc14d6000 8K USR ro x= pte 0xffffffffc14d6000-0xffffffffc14d7000 4K USR ro x= pte 0xffffffffc14d7000-0xffffffffc14db000 16K USR ro x= pte 0xffffffffc14db000-0xffffffffc14dc000 4K USR ro x= pte 0xffffffffc14dc000-0xffffffffc14de000 8K USR ro x= pte 0xffffffffc14de000-0xffffffffc14df000 4K USR ro x= pte 0xffffffffc14df000-0xffffffffc14e3000 16K USR ro x= pte 0xffffffffc14e3000-0xffffffffc14e7000 16K USR ro x= pte 0xffffffffc14e7000-0xffffffffc14e8000 4K USR ro x= pte 0xffffffffc14e8000-0xffffffffc14e9000 4K USR ro x= pte 0xffffffffc14e9000-0xffffffffc14f1000 32K USR ro x= pte 0xffffffffc14f1000-0xffffffffc14f2000 4K USR ro x= pte 0xffffffffc14f2000-0xffffffffc14f6000 16K USR ro x= pte 0xffffffffc14f6000-0xffffffffc14f7000 4K USR ro x= pte 0xffffffffc14f7000-0xffffffffc14f8000 4K USR ro x= pte 0xffffffffc14f8000-0xffffffffc14f9000 4K USR ro x= pte 0xffffffffc14f9000-0xffffffffc14fe000 20K USR ro x= pte 0xffffffffc14fe000-0xffffffffc1503000 20K USR ro x= pte 0xffffffffc1503000-0xffffffffc1508000 20K USR ro x= pte 0xffffffffc1508000-0xffffffffc150d000 20K USR ro x= pte 0xffffffffc150d000-0xffffffffc1511000 16K USR ro x= pte 0xffffffffc1511000-0xffffffffc1513000 8K USR ro x= pte 0xffffffffc1513000-0xffffffffc1514000 4K USR ro x= pte 0xffffffffc1514000-0xffffffffc1515000 4K USR ro x= pte 0xffffffffc1515000-0xffffffffc1516000 4K USR ro x= pte 0xffffffffc1516000-0xffffffffc151b000 20K USR ro x= pte 0xffffffffc151b000-0xffffffffc1520000 20K USR ro x= pte 0xffffffffc1520000-0xffffffffc1521000 4K USR ro x= pte 0xffffffffc1521000-0xffffffffc1523000 8K USR ro x= pte 0xffffffffc1523000-0xffffffffc1525000 8K USR ro x= pte 0xffffffffc1525000-0xffffffffc1526000 4K USR ro x= pte 0xffffffffc1526000-0xffffffffc1529000 12K USR ro x= pte 0xffffffffc1529000-0xffffffffc152a000 4K USR ro x= pte 0xffffffffc152a000-0xffffffffc152b000 4K USR ro x= pte 0xffffffffc152b000-0xffffffffc152e000 12K USR ro x= pte 0xffffffffc152e000-0xffffffffc1533000 20K USR ro x= pte 0xffffffffc1533000-0xffffffffc1535000 8K USR ro x= pte 0xffffffffc1535000-0xffffffffc1537000 8K USR ro x= pte 0xffffffffc1537000-0xffffffffc1538000 4K USR ro x= pte 0xffffffffc1538000-0xffffffffc1539000 4K USR ro x= pte 0xffffffffc1539000-0xffffffffc153b000 8K USR ro x= pte 0xffffffffc153b000-0xffffffffc153d000 8K USR ro x= pte 0xffffffffc153d000-0xffffffffc1541000 16K USR ro x= pte 0xffffffffc1541000-0xffffffffc1542000 4K USR ro x= pte 0xffffffffc1542000-0xffffffffc1544000 8K USR ro x= pte 0xffffffffc1544000-0xffffffffc1545000 4K USR ro x= pte 0xffffffffc1545000-0xffffffffc1547000 8K USR ro x= pte 0xffffffffc1547000-0xffffffffc1551000 40K USR ro x= pte 0xffffffffc1551000-0xffffffffc1552000 4K USR ro x= pte 0xffffffffc1552000-0xffffffffc1554000 8K USR ro x= pte 0xffffffffc1554000-0xffffffffc1555000 4K USR ro x= pte 0xffffffffc1555000-0xffffffffc155d000 32K USR ro x= pte 0xffffffffc155d000-0xffffffffc155f000 8K USR ro x= pte 0xffffffffc155f000-0xffffffffc1563000 16K USR ro x= pte 0xffffffffc1563000-0xffffffffc1566000 12K USR ro x= pte 0xffffffffc1566000-0xffffffffc1567000 4K USR ro x= pte 0xffffffffc1567000-0xffffffffc1568000 4K USR ro x= pte 0xffffffffc1568000-0xffffffffc156a000 8K USR ro x= pte 0xffffffffc156a000-0xffffffffc156b000 4K USR ro x= pte 0xffffffffc156b000-0xffffffffc1572000 28K USR ro x= pte 0xffffffffc1572000-0xffffffffc1573000 4K USR ro x= pte 0xffffffffc1573000-0xffffffffc1576000 12K USR ro x= pte 0xffffffffc1576000-0xffffffffc1577000 4K USR ro x= pte 0xffffffffc1577000-0xffffffffc1578000 4K USR ro x= pte 0xffffffffc1578000-0xffffffffc1579000 4K USR ro x= pte 0xffffffffc1579000-0xffffffffc157a000 4K USR ro x= pte 0xffffffffc157a000-0xffffffffc157b000 4K USR ro x= pte 0xffffffffc157b000-0xffffffffc157d000 8K USR ro x= pte 0xffffffffc157d000-0xffffffffc157f000 8K USR ro x= pte 0xffffffffc157f000-0xffffffffc1582000 12K USR ro x= pte 0xffffffffc1582000-0xffffffffc1584000 8K USR ro x= pte 0xffffffffc1584000-0xffffffffc1586000 8K USR ro x= pte 0xffffffffc1586000-0xffffffffc1588000 8K USR ro x= pte 0xffffffffc1588000-0xffffffffc1589000 4K USR ro x= pte 0xffffffffc1589000-0xffffffffc158d000 16K USR ro x= pte 0xffffffffc158d000-0xffffffffc158f000 8K USR ro x= pte 0xffffffffc158f000-0xffffffffc1593000 16K USR ro x= pte 0xffffffffc1593000-0xffffffffc1594000 4K USR ro x= pte 0xffffffffc1594000-0xffffffffc1595000 4K USR ro x= pte 0xffffffffc1595000-0xffffffffc1596000 4K USR ro x= pte 0xffffffffc1596000-0xffffffffc1599000 12K USR ro x= pte 0xffffffffc1599000-0xffffffffc15ab000 72K USR ro x= pte 0xffffffffc15ab000-0xffffffffc15ac000 4K USR ro x= pte 0xffffffffc15ac000-0xffffffffc15b0000 16K USR ro x= pte 0xffffffffc15b0000-0xffffffffc15b1000 4K USR ro x= pte 0xffffffffc15b1000-0xffffffffc15b7000 24K USR ro x= pte 0xffffffffc15b7000-0xffffffffc1600000 292K USR RW N= X pte 0xffffffffc1600000-0xffffffffc179c000 1648K USR ro N= X pte 0xffffffffc179c000-0xffffffffc1800000 400K USR RW N= X pte 0xffffffffc1800000-0xffffffffc1802000 8K USR RW x= pte 0xffffffffc1802000-0xffffffffc1803000 4K USR RW x= pte 0xffffffffc1803000-0xffffffffc1805000 8K USR RW x= pte 0xffffffffc1805000-0xffffffffc180b000 24K USR RW x= pte 0xffffffffc180b000-0xffffffffc180f000 16K USR ro x= pte 0xffffffffc180f000-0xffffffffc1810000 4K USR RW x= pte 0xffffffffc1810000-0xffffffffc1812000 8K USR ro x= pte 0xffffffffc1812000-0xffffffffc1813000 4K USR RW x= pte 0xffffffffc1813000-0xffffffffc1815000 8K USR RW x= pte 0xffffffffc1815000-0xffffffffc1816000 4K USR RW x= pte 0xffffffffc1816000-0xffffffffc1818000 8K USR RW x= pte 0xffffffffc1818000-0xffffffffc181a000 8K USR RW x= pte 0xffffffffc181a000-0xffffffffc181d000 12K USR RW x= pte 0xffffffffc181d000-0xffffffffc181e000 4K USR RW x= pte 0xffffffffc181e000-0xffffffffc1832000 80K USR RW x= pte 0xffffffffc1832000-0xffffffffc1834000 8K USR RW x= pte 0xffffffffc1834000-0xffffffffc183a000 24K USR RW x= pte 0xffffffffc183a000-0xffffffffc183d000 12K USR RW x= pte 0xffffffffc183d000-0xffffffffc1841000 16K USR RW x= pte 0xffffffffc1841000-0xffffffffc1843000 8K USR RW x= pte 0xffffffffc1843000-0xffffffffc1845000 8K USR RW x= pte 0xffffffffc1845000-0xffffffffc1846000 4K USR RW x= pte 0xffffffffc1846000-0xffffffffc1849000 12K USR RW x= pte 0xffffffffc1849000-0xffffffffc184a000 4K USR RW x= pte 0xffffffffc184a000-0xffffffffc184f000 20K USR RW x= pte 0xffffffffc184f000-0xffffffffc1850000 4K USR RW x= pte 0xffffffffc1850000-0xffffffffc1885000 212K USR RW x= pte 0xffffffffc1885000-0xffffffffc1938000 716K USR RW N= X pte 0xffffffffc1938000-0xffffffffc193a000 8K USR RW x= pte 0xffffffffc193a000-0xffffffffc193b000 4K USR ro x= pte 0xffffffffc193b000-0xffffffffc193d000 8K USR RW x= pte 0xffffffffc193d000-0xffffffffc193e000 4K USR ro x= pte 0xffffffffc193e000-0xffffffffc1948000 40K USR RW x= pte 0xffffffffc1948000-0xffffffffc194a000 8K USR RW x= pte 0xffffffffc194a000-0xffffffffc194c000 8K USR RW x= pte 0xffffffffc194c000-0xffffffffc196c000 128K USR RW x= pte 0xffffffffc196c000-0xffffffffc196d000 4K USR RW x= pte 0xffffffffc196d000-0xffffffffc1970000 12K USR RW x= pte 0xffffffffc1970000-0xffffffffc1971000 4K USR RW x= pte 0xffffffffc1971000-0xffffffffc1972000 4K USR RW x= pte 0xffffffffc1972000-0xffffffffc1973000 4K USR RW x= pte 0xffffffffc1973000-0xffffffffc1975000 8K USR RW x= pte 0xffffffffc1975000-0xffffffffc1976000 4K USR RW x= pte 0xffffffffc1976000-0xffffffffc1977000 4K USR RW x= pte 0xffffffffc1977000-0xffffffffc197b000 16K USR RW x= pte 0xffffffffc197b000-0xffffffffc19b9000 248K USR RW x= pte 0xffffffffc19b9000-0xffffffffc19c0000 28K USR RW x= pte 0xffffffffc19c0000-0xffffffffc19df000 124K USR RW x= pte 0xffffffffc19df000-0xffffffffc19e8000 36K USR RW x= pte 0xffffffffc19e8000-0xffffffffc19f1000 36K USR RW x= pte 0xffffffffc19f1000-0xffffffffc19f2000 4K USR RW x= pte 0xffffffffc19f2000-0xffffffffc19f3000 4K USR RW x= pte 0xffffffffc19f3000-0xffffffffc19f5000 8K USR RW x= pte 0xffffffffc19f5000-0xffffffffc19f8000 12K USR RW x= pte 0xffffffffc19f8000-0xffffffffc1a0a000 72K USR RW x= pte 0xffffffffc1a0a000-0xffffffffc1a0f000 20K USR RW x= pte 0xffffffffc1a0f000-0xffffffffc1a1c000 52K USR RW x= pte 0xffffffffc1a1c000-0xffffffffc1a1d000 4K USR RW x= pte 0xffffffffc1a1d000-0xffffffffc1aa4000 540K USR RW x= pte 0xffffffffc1aa4000-0xffffffffc1aa8000 16K USR ro x= pte 0xffffffffc1aa8000-0xffffffffc1b28000 512K USR RW x= pte 0xffffffffc1b28000-0xffffffffc1e3d000 3156K USR RW x= pte 0xffffffffc1e3d000-0xffffffffcfc93000 227672K USR RW N= X pte 0xffffffffcfc93000-0xffffffffdf694000 256004K USR RW x= pte 0xffffffffdf694000-0xffffffffdf696000 8K USR RW x= pte 0xffffffffdf696000-0xffffffffdf797000 1028K USR ro x= pte 0xffffffffdf797000-0xffffffffdfc00000 4516K USR RW x= pte 0xffffffffdfc00000-0xffffffffff000000 500M = pmd ---[ End Modules ]--- 0xffffffffff000000-0xffffffffff400000 4M = pmd 0xffffffffff400000-0xffffffffff579000 1508K = pte 0xffffffffff579000-0xffffffffff57a000 4K USR RW N= X pte 0xffffffffff57a000-0xffffffffff5ff000 532K = pte 0xffffffffff5ff000-0xffffffffff601000 8K USR ro GLB N= X pte 0xffffffffff601000-0xffffffffff800000 2044K = pte 0xffffffffff800000-0x0000000000000000 8M = pmd # poweroff --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="133-gb-bad.txt" console [hvc0] enabled, bootconsole disabled Xen: using vcpuop timer interface installing Xen timer for CPU 0 Detected 2261.074 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4522.14 BogoMIPS (lpj=2261074) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes) Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 24k freed cpu 0 spinlock event irq 17 Performance Events: unsupported p6 CPU model 46 no PMU driver, software events only. NMI watchdog: disabled (cpu0): hardware events not enabled Brought up 1 CPUs kworker/u:0 used greatest stack depth: 6000 bytes left Grant tables using version 2 layout. Grant table initialized RTC time: 165:165:165, date: 165/165/65 NET: Registered protocol family 16 kworker/u:0 used greatest stack depth: 5536 bytes left dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub PCI: pci_cache_line_size set to 64 bytes bio: create slab at 0 ACPI: Interpreter disabled. xen/balloon: Initialising balloon driver. xen-balloon: Initialising balloon driver. vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource xen pnp: PnP ACPI: disabled NET: Registered protocol family 2 IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP: reno registered UDP hash table entries: 65536 (order: 9, 2097152 bytes) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 Trying to unpack rootfs image as initramfs... Freeing initrd memory: 227672k freed platform rtc_cmos: registered platform RTC device (no PNP device found) Machine check injector initialized microcode: CPU0 sig=0x206e5, pf=0x4, revision=0xffff0018 microcode: Microcode Update Driver: v2.00 , Peter Oruba audit: initializing netlink socket (disabled) type=2000 audit(1336432515.722:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) NFS: Registering the id_resolver key type NTFS driver 2.1.30 [Flags: R/W]. msgmni has been set to 32768 SELinux: Registering netfilter hooks Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ioatdma: Intel(R) QuickData Technology Driver 4.00 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 brd: module loaded loop: module loaded Fixed MDIO Bus: probed tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.2.0-k ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 80 td 96 uhci_hcd: USB Universal Host Controller Interface driver usbcore: registered new interface driver usblp usbcore: registered new interface driver libusual i8042: PNP: No PS/2 controller found. Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 EFI Variables Facility v0.08 2004-May-17 zram: num_devices not specified. Using default: 1 zram: Creating 1 devices ... Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ctnetlink v0.93: registering with nfnetlink. ip_tables: (C) 2000-2006 Netfilter Core Team TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Registering the dns_resolver key type PM: Hibernation image not present or could not be loaded. registered taskstats version 1 Magic number: 1:252:3141 Freeing unused kernel memory: 692k freed Write protecting the kernel read-only data: 8192k Freeing unused kernel memory: 292k freed Freeing unused kernel memory: 400k freed init started: BusyBox v1.14.3 (2012-05-07 12:16:33 EDT) Mounting directories [ OK ] ------------[ cut here ]------------ WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: Pid: 1051, comm: modprobe Not tainted 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dc6 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 1051, comm: modprobe Tainted: G W 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 73 active_anon:253 inactive_anon:31970 isolated_anon:0 active_file:391 inactive_file:27806 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33525733 slab_reclaimable:1660 slab_unreclaimable:976 mapped:340 shmem:31960 pagetables:34 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130456376kB min:45112kB low:56388kB high:67668kB active_anon:1012kB inactive_anon:127880kB active_file:1564kB inactive_file:111224kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:1360kB shmem:127840kB slab_reclaimable:6640kB slab_unreclaimable:3904kB kernel_stack:368kB pagetables:136kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 26*4kB 26*8kB 14*16kB 11*32kB 11*64kB 6*128kB 8*256kB 7*512kB 9*1024kB 3*2048kB 31844*4096kB = 130456376kB 60151 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 983 pages shared 166525 pages non-shared modprobe: FATAL: Error inserting xenfs (/lib/modules/3.4.0-rc6upstream-00024-g3bfd88d-dirty/kernel/drivers/xen/xenfs/xenfs.ko): Cannot allocate memory ... ------------[ cut here ]------------ WARNING: at /home/konrad/ssd/linux/mm/vmalloc.c:107 vmap_page_range_noflush+0x328/0x3a0() Modules linked in: libcrc32c crc32c Pid: 2165, comm: modprobe Tainted: G W O 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] warn_slowpath_null+0x15/0x20 [] vmap_page_range_noflush+0x328/0x3a0 [] vmap_page_range+0x3d/0x60 [] map_vm_area+0x2d/0x50 [] __vmalloc_node_range+0x160/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace efd7fe3e15953dd2 ]--- vmalloc: allocation failure, allocated 16384 of 20480 bytes modprobe: page allocation failure: order:0, mode:0xd2 Pid: 2165, comm: modprobe Tainted: G W O 3.4.0-rc6upstream-00024-g3bfd88d-dirty #1 Call Trace: [] warn_alloc_failed+0xeb/0x130 [] ? vmap_page_range+0x44/0x60 [] __vmalloc_node_range+0x216/0x250 [] ? module_alloc_update_bounds+0x19/0x80 [] ? load_module+0x66/0x19b0 [] module_alloc+0x5c/0x60 [] ? module_alloc_update_bounds+0x19/0x80 [] module_alloc_update_bounds+0x19/0x80 [] load_module+0xf93/0x19b0 [] sys_init_module+0x5a/0x220 [] system_call_fastpath+0x16/0x1b Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 168 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 37 active_anon:1428 inactive_anon:31278 isolated_anon:0 active_file:1711 inactive_file:26465 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:33523833 slab_reclaimable:2320 slab_unreclaimable:1641 mapped:586 shmem:31998 pagetables:132 bounce:0 Node 0 DMA free:8760kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:8536kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 4024 132160 132160 Node 0 DMA32 free:3637796kB min:1416kB low:1768kB high:2124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 128135 128135 Node 0 Normal free:130448776kB min:45112kB low:56388kB high:67668kB active_anon:5712kB inactive_anon:125112kB active_file:6844kB inactive_file:105860kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131211120kB mlocked:0kB dirty:0kB writeback:0kB mapped:2340kB shmem:127992kB slab_reclaimable:9280kB slab_unreclaimable:6564kB kernel_stack:296kB pagetables:528kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 2*4kB 2*8kB 0*16kB 3*32kB 3*64kB 2*128kB 2*256kB 1*512kB 3*1024kB 2*2048kB 0*4096kB = 8760kB Node 0 DMA32: 5*4kB 2*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 4*512kB 1*1024kB 0*2048kB 887*4096kB = 3637796kB Node 0 Normal: 126*4kB 84*8kB 70*16kB 33*32kB 10*64kB 4*128kB 2*256kB 3*512kB 7*1024kB 5*2048kB 31842*4096kB = 130448792kB 60174 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 34306032 pages RAM 612977 pages reserved 1735 pages shared 168082 pages non-shared 0xffffc90000000000-0xffffc90010001000 268439552 alloc_large_system_hash+0x154/0x213 pages=65536 vmalloc vpages N0=65536 0xffffc90010001000-0xffffc90010082000 528384 alloc_large_system_hash+0x154/0x213 pages=128 vmalloc N0=128 0xffffc90010082000-0xffffc90018083000 134221824 alloc_large_system_hash+0x154/0x213 pages=32768 vmalloc vpages N0=32768 0xffffc90018083000-0xffffc900180c4000 266240 alloc_large_system_hash+0x154/0x213 pages=64 vmalloc N0=64 0xffffc900180c4000-0xffffc900180c7000 12288 alloc_large_system_hash+0x154/0x213 pages=2 vmalloc N0=2 0xffffc900180c8000-0xffffc900180cd000 20480 arch_gnttab_map_status+0x50/0x70 ioremap 0xffffc900180cd000-0xffffc900180d2000 20480 alloc_large_system_hash+0x154/0x213 pages=4 vmalloc N0=4 0xffffc900180d2000-0xffffc900180de000 49152 zisofs_init+0x11/0x23 pages=11 vmalloc N0=11 0xffffc900180de000-0xffffc900180eb000 53248 netback_init+0x4c/0x210 pages=12 vmalloc N0=12 0xffffc90018100000-0xffffc90018121000 135168 arch_gnttab_map_shared+0x50/0x70 ioremap 0xffffc90018121000-0xffffc90018522000 4198400 alloc_large_system_hash+0x154/0x213 pages=1024 vmalloc vpages N0=1024 0xffffc90018522000-0xffffc90018d23000 8392704 alloc_large_system_hash+0x154/0x213 pages=2048 vmalloc vpages N0=2048 0xffffc90018d23000-0xffffc90018e24000 1052672 alloc_large_system_hash+0x154/0x213 pages=256 vmalloc N0=256 0xffffc90018e24000-0xffffc90019025000 2101248 alloc_large_system_hash+0x154/0x213 pages=512 vmalloc N0=512 0xffffc90019025000-0xffffc90019226000 2101248 alloc_large_system_hash+0x154/0x213 pages=512 vmalloc N0=512 0xffffffffa0000000-0xffffffffa0005000 20480 module_alloc_update_bounds+0x19/0x80 pages=4 vmalloc N0=4 0xffffffffa0008000-0xffffffffa000d000 20480 module_alloc_update_bounds+0x19/0x80 pages=4 vmalloc N0=4 ---[ User Space ]--- 0x0000000000000000-0xffff800000000000 16777088T pgd ---[ Kernel Space ]--- 0xffff800000000000-0xffff814000000000 1280G pud 0xffff814000000000-0xffff8140a0000000 2560M pmd 0xffff8140a0000000-0xffff8140a0500000 5M pte 0xffff8140a0500000-0xffff8140a0501000 4K USR RW x pte 0xffff8140a0501000-0xffff8140a0503000 8K RW x pte 0xffff8140a0503000-0xffff8140a0504000 4K pte 0xffff8140a0504000-0xffff8140a0505000 4K RW x pte 0xffff8140a0505000-0xffff8140a0507000 8K USR RW x pte 0xffff8140a0507000-0xffff8140a0509000 8K RW x pte 0xffff8140a0509000-0xffff8140a0510000 28K pte 0xffff8140a0510000-0xffff8140a0511000 4K USR RW x pte 0xffff8140a0511000-0xffff8140a0592000 516K pte 0xffff8140a0592000-0xffff8140a0593000 4K USR RW x pte 0xffff8140a0593000-0xffff8140a05d4000 260K pte 0xffff8140a05d4000-0xffff8140a05d5000 4K USR RW x pte 0xffff8140a05d5000-0xffff8140a05ff000 168K pte 0xffff8140a05ff000-0xffff8140a0600000 4K USR RW x pte 0xffff8140a0600000-0xffff8140a0800000 2M pmd 0xffff8140a0800000-0xffff8140a1200000 10M pte 0xffff8140a1200000-0xffff8140a2000000 14M pmd 0xffff8140a2000000-0xffff8140a2083000 524K USR RW x pte 0xffff8140a2083000-0xffff8140a2200000 1524K pte 0xffff8140a2200000-0xffff8140b2400000 258M pmd 0xffff8140b2400000-0xffff8140b2401000 4K USR RW x pte 0xffff8140b2401000-0xffff8140b2600000 2044K pte 0xffff8140b2600000-0xffff8140ba800000 130M pmd 0xffff8140ba800000-0xffff8140ba802000 8K USR RW x pte 0xffff8140ba802000-0xffff8140baa00000 2040K pte 0xffff8140baa00000-0xffff8140bfe00000 84M pmd 0xffff8140bfe00000-0xffff8140bfffe000 2040K pte 0xffff8140bfffe000-0xffff8140c0000000 8K USR RW x pte 0xffff8140c0000000-0xffff814100000000 1G pud 0xffff814100000000-0xffff814240000000 5G pmd 0xffff814240000000-0xffff814400000000 7G pud 0xffff814400000000-0xffff8144105bc000 268016K USR RW x pte 0xffff8144105bc000-0xffff814410600000 272K pte 0xffff814410600000-0xffff814440000000 762M pmd 0xffff814440000000-0xffff816480000000 129G pud 0xffff816480000000-0xffff8164800cb000 812K USR RW x pte 0xffff8164800cb000-0xffff816480200000 1236K pte 0xffff816480200000-0xffff8164c0000000 1022M pmd 0xffff8164c0000000-0xffff817500000000 65G pud 0xffff817500000000-0xffff817500395000 3668K USR RW x pte 0xffff817500395000-0xffff817500400000 428K pte 0xffff817500400000-0xffff817540000000 1020M pmd 0xffff817540000000-0xffff817fc0000000 42G pud 0xffff817fc0000000-0xffff817fffc00000 1020M pmd 0xffff817fffc00000-0xffff817fffc08000 32K pte 0xffff817fffc08000-0xffff817fffc0e000 24K USR RW x pte 0xffff817fffc0e000-0xffff817fffc7e000 448K pte 0xffff817fffc7e000-0xffff817fffd02000 528K USR RW x pte 0xffff817fffd02000-0xffff817fffe00000 1016K pte 0xffff817fffe00000-0xffff817ffff02000 1032K USR RW x pte 0xffff817ffff02000-0xffff817fffffa000 992K pte 0xffff817fffffa000-0xffff817fffffc000 8K USR RW x pte 0xffff817fffffc000-0xffff818000000000 16K pte 0xffff818000000000-0xffff820000000000 512G pgd 0xffff820000000000-0xffff848000000000 2560G pud 0xffff848000000000-0xffff880000000000 3584G pgd ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff88000009b000 620K USR RW x pte 0xffff88000009b000-0xffff8800000a0000 20K USR RW x pte 0xffff8800000a0000-0xffff8800007fb000 7532K USR RW x pte 0xffff8800007fb000-0xffff880000ef8000 7156K USR ro x pte 0xffff880000ef8000-0xffff880001000000 1056K USR RW x pte 0xffff880001000000-0xffff880001002000 8K USR ro x pte 0xffff880001002000-0xffff880001013000 68K USR ro x pte 0xffff880001013000-0xffff880001015000 8K USR ro x pte 0xffff880001015000-0xffff880001017000 8K USR ro x pte 0xffff880001017000-0xffff880001019000 8K USR ro x pte 0xffff880001019000-0xffff88000101a000 4K USR ro x pte 0xffff88000101a000-0xffff88000101b000 4K USR ro x pte 0xffff88000101b000-0xffff88000101f000 16K USR ro x pte 0xffff88000101f000-0xffff880001028000 36K USR ro x pte 0xffff880001028000-0xffff88000102a000 8K USR ro x pte 0xffff88000102a000-0xffff88000102c000 8K USR ro x pte 0xffff88000102c000-0xffff88000103c000 64K USR ro x pte 0xffff88000103c000-0xffff88000103d000 4K USR ro x pte 0xffff88000103d000-0xffff880001051000 80K USR ro x pte 0xffff880001051000-0xffff880001052000 4K USR ro x pte 0xffff880001052000-0xffff880001057000 20K USR ro x pte 0xffff880001057000-0xffff880001058000 4K USR ro x pte 0xffff880001058000-0xffff880001061000 36K USR ro x pte 0xffff880001061000-0xffff880001063000 8K USR ro x pte 0xffff880001063000-0xffff88000106b000 32K USR ro x pte 0xffff88000106b000-0xffff88000106c000 4K USR ro x pte 0xffff88000106c000-0xffff880001078000 48K USR ro x pte 0xffff880001078000-0xffff88000107a000 8K USR ro x pte 0xffff88000107a000-0xffff880001083000 36K USR ro x pte 0xffff880001083000-0xffff880001084000 4K USR ro x pte 0xffff880001084000-0xffff88000108f000 44K USR ro x pte 0xffff88000108f000-0xffff880001090000 4K USR ro x pte 0xffff880001090000-0xffff880001094000 16K USR ro x pte 0xffff880001094000-0xffff880001097000 12K USR ro x pte 0xffff880001097000-0xffff8800010a0000 36K USR ro x pte 0xffff8800010a0000-0xffff8800010a2000 8K USR ro x pte 0xffff8800010a2000-0xffff8800010a7000 20K USR ro x pte 0xffff8800010a7000-0xffff8800010a8000 4K USR ro x pte 0xffff8800010a8000-0xffff8800010aa000 8K USR ro x pte 0xffff8800010aa000-0xffff8800010af000 20K USR ro x pte 0xffff8800010af000-0xffff8800010b4000 20K USR ro x pte 0xffff8800010b4000-0xffff8800010b6000 8K USR ro x pte 0xffff8800010b6000-0xffff8800010c0000 40K USR ro x pte 0xffff8800010c0000-0xffff8800010c4000 16K USR ro x pte 0xffff8800010c4000-0xffff8800010c6000 8K USR ro x pte 0xffff8800010c6000-0xffff8800010ca000 16K USR ro x pte 0xffff8800010ca000-0xffff8800010cc000 8K USR ro x pte 0xffff8800010cc000-0xffff8800010cd000 4K USR ro x pte 0xffff8800010cd000-0xffff8800010d5000 32K USR ro x pte 0xffff8800010d5000-0xffff8800010d9000 16K USR ro x pte 0xffff8800010d9000-0xffff8800010da000 4K USR ro x pte 0xffff8800010da000-0xffff8800010db000 4K USR ro x pte 0xffff8800010db000-0xffff8800010dc000 4K USR ro x pte 0xffff8800010dc000-0xffff8800010dd000 4K USR ro x pte 0xffff8800010dd000-0xffff8800010e2000 20K USR ro x pte 0xffff8800010e2000-0xffff8800010e3000 4K USR ro x pte 0xffff8800010e3000-0xffff8800010f8000 84K USR ro x pte 0xffff8800010f8000-0xffff8800010fb000 12K USR ro x pte 0xffff8800010fb000-0xffff880001101000 24K USR ro x pte 0xffff880001101000-0xffff880001102000 4K USR ro x pte 0xffff880001102000-0xffff880001106000 16K USR ro x pte 0xffff880001106000-0xffff880001107000 4K USR ro x pte 0xffff880001107000-0xffff880001108000 4K USR ro x pte 0xffff880001108000-0xffff880001109000 4K USR ro x pte 0xffff880001109000-0xffff880001113000 40K USR ro x pte 0xffff880001113000-0xffff880001114000 4K USR ro x pte 0xffff880001114000-0xffff880001117000 12K USR ro x pte 0xffff880001117000-0xffff880001118000 4K USR ro x pte 0xffff880001118000-0xffff880001122000 40K USR ro x pte 0xffff880001122000-0xffff880001124000 8K USR ro x pte 0xffff880001124000-0xffff880001143000 124K USR ro x pte 0xffff880001143000-0xffff880001145000 8K USR ro x pte 0xffff880001145000-0xffff880001166000 132K USR ro x pte 0xffff880001166000-0xffff880001168000 8K USR ro x pte 0xffff880001168000-0xffff88000116d000 20K USR ro x pte 0xffff88000116d000-0xffff88000116e000 4K USR ro x pte 0xffff88000116e000-0xffff88000116f000 4K USR ro x pte 0xffff88000116f000-0xffff880001170000 4K USR ro x pte 0xffff880001170000-0xffff880001174000 16K USR ro x pte 0xffff880001174000-0xffff880001177000 12K USR ro x pte 0xffff880001177000-0xffff88000117a000 12K USR ro x pte 0xffff88000117a000-0xffff88000117e000 16K USR ro x pte 0xffff88000117e000-0xffff88000118d000 60K USR ro x pte 0xffff88000118d000-0xffff88000118e000 4K USR ro x pte 0xffff88000118e000-0xffff880001190000 8K USR ro x pte 0xffff880001190000-0xffff880001191000 4K USR ro x pte 0xffff880001191000-0xffff880001192000 4K USR ro x pte 0xffff880001192000-0xffff880001193000 4K USR ro x pte 0xffff880001193000-0xffff880001194000 4K USR ro x pte 0xffff880001194000-0xffff880001197000 12K USR ro x pte 0xffff880001197000-0xffff880001198000 4K USR ro x pte 0xffff880001198000-0xffff880001199000 4K USR ro x pte 0xffff880001199000-0xffff8800011a0000 28K USR ro x pte 0xffff8800011a0000-0xffff8800011a1000 4K USR ro x pte 0xffff8800011a1000-0xffff8800011ab000 40K USR ro x pte 0xffff8800011ab000-0xffff8800011ac000 4K USR ro x pte 0xffff8800011ac000-0xffff8800011af000 12K USR ro x pte 0xffff8800011af000-0xffff8800011b1000 8K USR ro x pte 0xffff8800011b1000-0xffff8800011b4000 12K USR ro x pte 0xffff8800011b4000-0xffff8800011b5000 4K USR ro x pte 0xffff8800011b5000-0xffff8800011b9000 16K USR ro x pte 0xffff8800011b9000-0xffff8800011bb000 8K USR ro x pte 0xffff8800011bb000-0xffff8800011bd000 8K USR ro x pte 0xffff8800011bd000-0xffff8800011be000 4K USR ro x pte 0xffff8800011be000-0xffff8800011c2000 16K USR ro x pte 0xffff8800011c2000-0xffff8800011c6000 16K USR ro x pte 0xffff8800011c6000-0xffff8800011c7000 4K USR ro x pte 0xffff8800011c7000-0xffff8800011c8000 4K USR ro x pte 0xffff8800011c8000-0xffff8800011c9000 4K USR ro x pte 0xffff8800011c9000-0xffff8800011ca000 4K USR ro x pte 0xffff8800011ca000-0xffff8800011cf000 20K USR ro x pte 0xffff8800011cf000-0xffff8800011d0000 4K USR ro x pte 0xffff8800011d0000-0xffff8800011d3000 12K USR ro x pte 0xffff8800011d3000-0xffff8800011d5000 8K USR ro x pte 0xffff8800011d5000-0xffff8800011d6000 4K USR ro x pte 0xffff8800011d6000-0xffff8800011d8000 8K USR ro x pte 0xffff8800011d8000-0xffff8800011d9000 4K USR ro x pte 0xffff8800011d9000-0xffff8800011da000 4K USR ro x pte 0xffff8800011da000-0xffff8800011e0000 24K USR ro x pte 0xffff8800011e0000-0xffff8800011e3000 12K USR ro x pte 0xffff8800011e3000-0xffff8800011e9000 24K USR ro x pte 0xffff8800011e9000-0xffff8800011ea000 4K USR ro x pte 0xffff8800011ea000-0xffff8800011eb000 4K USR ro x pte 0xffff8800011eb000-0xffff8800011f1000 24K USR ro x pte 0xffff8800011f1000-0xffff8800011f7000 24K USR ro x pte 0xffff8800011f7000-0xffff8800011f8000 4K USR ro x pte 0xffff8800011f8000-0xffff8800011fa000 8K USR ro x pte 0xffff8800011fa000-0xffff8800011fb000 4K USR ro x pte 0xffff8800011fb000-0xffff8800011fd000 8K USR ro x pte 0xffff8800011fd000-0xffff8800011fe000 4K USR ro x pte 0xffff8800011fe000-0xffff880001200000 8K USR ro x pte 0xffff880001200000-0xffff880001201000 4K USR ro x pte 0xffff880001201000-0xffff880001203000 8K USR ro x pte 0xffff880001203000-0xffff880001207000 16K USR ro x pte 0xffff880001207000-0xffff880001209000 8K USR ro x pte 0xffff880001209000-0xffff88000120a000 4K USR ro x pte 0xffff88000120a000-0xffff88000120b000 4K USR ro x pte 0xffff88000120b000-0xffff88000120c000 4K USR ro x pte 0xffff88000120c000-0xffff88000120e000 8K USR ro x pte 0xffff88000120e000-0xffff880001223000 84K USR ro x pte 0xffff880001223000-0xffff880001228000 20K USR ro x pte 0xffff880001228000-0xffff880001229000 4K USR ro x pte 0xffff880001229000-0xffff88000123b000 72K USR ro x pte 0xffff88000123b000-0xffff88000123d000 8K USR ro x pte 0xffff88000123d000-0xffff88000123e000 4K USR ro x pte 0xffff88000123e000-0xffff88000123f000 4K USR ro x pte 0xffff88000123f000-0xffff880001242000 12K USR ro x pte 0xffff880001242000-0xffff880001244000 8K USR ro x pte 0xffff880001244000-0xffff880001245000 4K USR ro x pte 0xffff880001245000-0xffff880001247000 8K USR ro x pte 0xffff880001247000-0xffff880001248000 4K USR ro x pte 0xffff880001248000-0xffff880001252000 40K USR ro x pte 0xffff880001252000-0xffff880001253000 4K USR ro x pte 0xffff880001253000-0xffff880001254000 4K USR ro x pte 0xffff880001254000-0xffff880001255000 4K USR ro x pte 0xffff880001255000-0xffff880001258000 12K USR ro x pte 0xffff880001258000-0xffff880001259000 4K USR ro x pte 0xffff880001259000-0xffff880001268000 60K USR ro x pte 0xffff880001268000-0xffff88000126e000 24K USR ro x pte 0xffff88000126e000-0xffff88000126f000 4K USR ro x pte 0xffff88000126f000-0xffff880001272000 12K USR ro x pte 0xffff880001272000-0xffff880001273000 4K USR ro x pte 0xffff880001273000-0xffff880001274000 4K USR ro x pte 0xffff880001274000-0xffff88000127a000 24K USR ro x pte 0xffff88000127a000-0xffff88000127c000 8K USR ro x pte 0xffff88000127c000-0xffff88000127d000 4K USR ro x pte 0xffff88000127d000-0xffff880001285000 32K USR ro x pte 0xffff880001285000-0xffff880001286000 4K USR ro x pte 0xffff880001286000-0xffff880001287000 4K USR ro x pte 0xffff880001287000-0xffff880001288000 4K USR ro x pte 0xffff880001288000-0xffff880001289000 4K USR ro x pte 0xffff880001289000-0xffff88000128d000 16K USR ro x pte 0xffff88000128d000-0xffff88000128f000 8K USR ro x pte 0xffff88000128f000-0xffff880001291000 8K USR ro x pte 0xffff880001291000-0xffff880001292000 4K USR ro x pte 0xffff880001292000-0xffff88000129f000 52K USR ro x pte 0xffff88000129f000-0xffff8800012a0000 4K USR ro x pte 0xffff8800012a0000-0xffff8800012a1000 4K USR ro x pte 0xffff8800012a1000-0xffff8800012a3000 8K USR ro x pte 0xffff8800012a3000-0xffff8800012a5000 8K USR ro x pte 0xffff8800012a5000-0xffff8800012a6000 4K USR ro x pte 0xffff8800012a6000-0xffff8800012a9000 12K USR ro x pte 0xffff8800012a9000-0xffff8800012ab000 8K USR ro x pte 0xffff8800012ab000-0xffff8800012c3000 96K USR ro x pte 0xffff8800012c3000-0xffff8800012c6000 12K USR ro x pte 0xffff8800012c6000-0xffff8800012cc000 24K USR ro x pte 0xffff8800012cc000-0xffff8800012cf000 12K USR ro x pte 0xffff8800012cf000-0xffff8800012d1000 8K USR ro x pte 0xffff8800012d1000-0xffff8800012d2000 4K USR ro x pte 0xffff8800012d2000-0xffff8800012d3000 4K USR ro x pte 0xffff8800012d3000-0xffff8800012d7000 16K USR ro x pte 0xffff8800012d7000-0xffff8800012d8000 4K USR ro x pte 0xffff8800012d8000-0xffff8800012da000 8K USR ro x pte 0xffff8800012da000-0xffff8800012dc000 8K USR ro x pte 0xffff8800012dc000-0xffff8800012e1000 20K USR ro x pte 0xffff8800012e1000-0xffff8800012e3000 8K USR ro x pte 0xffff8800012e3000-0xffff8800012e4000 4K USR ro x pte 0xffff8800012e4000-0xffff8800012e5000 4K USR ro x pte 0xffff8800012e5000-0xffff8800012e6000 4K USR ro x pte 0xffff8800012e6000-0xffff8800012e7000 4K USR ro x pte 0xffff8800012e7000-0xffff8800012ed000 24K USR ro x pte 0xffff8800012ed000-0xffff8800012ee000 4K USR ro x pte 0xffff8800012ee000-0xffff8800012f9000 44K USR ro x pte 0xffff8800012f9000-0xffff8800012fa000 4K USR ro x pte 0xffff8800012fa000-0xffff8800012fe000 16K USR ro x pte 0xffff8800012fe000-0xffff880001300000 8K USR ro x pte 0xffff880001300000-0xffff880001302000 8K USR ro x pte 0xffff880001302000-0xffff88000130d000 44K USR ro x pte 0xffff88000130d000-0xffff88000130e000 4K USR ro x pte 0xffff88000130e000-0xffff88000130f000 4K USR ro x pte 0xffff88000130f000-0xffff880001312000 12K USR ro x pte 0xffff880001312000-0xffff880001314000 8K USR ro x pte 0xffff880001314000-0xffff880001318000 16K USR ro x pte 0xffff880001318000-0xffff88000131b000 12K USR ro x pte 0xffff88000131b000-0xffff88000131c000 4K USR ro x pte 0xffff88000131c000-0xffff880001324000 32K USR ro x pte 0xffff880001324000-0xffff880001329000 20K USR ro x pte 0xffff880001329000-0xffff88000132d000 16K USR ro x pte 0xffff88000132d000-0xffff88000132e000 4K USR ro x pte 0xffff88000132e000-0xffff88000132f000 4K USR ro x pte 0xffff88000132f000-0xffff880001332000 12K USR ro x pte 0xffff880001332000-0xffff880001333000 4K USR ro x pte 0xffff880001333000-0xffff880001334000 4K USR ro x pte 0xffff880001334000-0xffff880001335000 4K USR ro x pte 0xffff880001335000-0xffff880001337000 8K USR ro x pte 0xffff880001337000-0xffff88000133b000 16K USR ro x pte 0xffff88000133b000-0xffff88000133c000 4K USR ro x pte 0xffff88000133c000-0xffff880001340000 16K USR ro x pte 0xffff880001340000-0xffff880001342000 8K USR ro x pte 0xffff880001342000-0xffff880001343000 4K USR ro x pte 0xffff880001343000-0xffff880001348000 20K USR ro x pte 0xffff880001348000-0xffff88000134c000 16K USR ro x pte 0xffff88000134c000-0xffff880001350000 16K USR ro x pte 0xffff880001350000-0xffff880001351000 4K USR ro x pte 0xffff880001351000-0xffff880001353000 8K USR ro x pte 0xffff880001353000-0xffff880001358000 20K USR ro x pte 0xffff880001358000-0xffff88000135e000 24K USR ro x pte 0xffff88000135e000-0xffff88000135f000 4K USR ro x pte 0xffff88000135f000-0xffff880001361000 8K USR ro x pte 0xffff880001361000-0xffff880001366000 20K USR ro x pte 0xffff880001366000-0xffff880001367000 4K USR ro x pte 0xffff880001367000-0xffff880001368000 4K USR ro x pte 0xffff880001368000-0xffff88000136a000 8K USR ro x pte 0xffff88000136a000-0xffff880001374000 40K USR ro x pte 0xffff880001374000-0xffff880001376000 8K USR ro x pte 0xffff880001376000-0xffff880001379000 12K USR ro x pte 0xffff880001379000-0xffff88000137f000 24K USR ro x pte 0xffff88000137f000-0xffff880001380000 4K USR ro x pte 0xffff880001380000-0xffff880001383000 12K USR ro x pte 0xffff880001383000-0xffff880001384000 4K USR ro x pte 0xffff880001384000-0xffff880001387000 12K USR ro x pte 0xffff880001387000-0xffff880001389000 8K USR ro x pte 0xffff880001389000-0xffff88000138c000 12K USR ro x pte 0xffff88000138c000-0xffff880001393000 28K USR ro x pte 0xffff880001393000-0xffff880001395000 8K USR ro x pte 0xffff880001395000-0xffff880001398000 12K USR ro x pte 0xffff880001398000-0xffff88000139a000 8K USR ro x pte 0xffff88000139a000-0xffff88000139c000 8K USR ro x pte 0xffff88000139c000-0xffff88000139d000 4K USR ro x pte 0xffff88000139d000-0xffff8800013a3000 24K USR ro x pte 0xffff8800013a3000-0xffff8800013a4000 4K USR ro x pte 0xffff8800013a4000-0xffff8800013a5000 4K USR ro x pte 0xffff8800013a5000-0xffff8800013a6000 4K USR ro x pte 0xffff8800013a6000-0xffff8800013a9000 12K USR ro x pte 0xffff8800013a9000-0xffff8800013ab000 8K USR ro x pte 0xffff8800013ab000-0xffff8800013ac000 4K USR ro x pte 0xffff8800013ac000-0xffff8800013ae000 8K USR ro x pte 0xffff8800013ae000-0xffff8800013b1000 12K USR ro x pte 0xffff8800013b1000-0xffff8800013b3000 8K USR ro x pte 0xffff8800013b3000-0xffff8800013b5000 8K USR ro x pte 0xffff8800013b5000-0xffff8800013b9000 16K USR ro x pte 0xffff8800013b9000-0xffff8800013ba000 4K USR ro x pte 0xffff8800013ba000-0xffff8800013bf000 20K USR ro x pte 0xffff8800013bf000-0xffff8800013ce000 60K USR ro x pte 0xffff8800013ce000-0xffff8800013cf000 4K USR ro x pte 0xffff8800013cf000-0xffff8800013d0000 4K USR ro x pte 0xffff8800013d0000-0xffff8800013d2000 8K USR ro x pte 0xffff8800013d2000-0xffff8800013d3000 4K USR ro x pte 0xffff8800013d3000-0xffff8800013db000 32K USR ro x pte 0xffff8800013db000-0xffff8800013dc000 4K USR ro x pte 0xffff8800013dc000-0xffff8800013dd000 4K USR ro x pte 0xffff8800013dd000-0xffff8800013de000 4K USR ro x pte 0xffff8800013de000-0xffff8800013e0000 8K USR ro x pte 0xffff8800013e0000-0xffff8800013e3000 12K USR ro x pte 0xffff8800013e3000-0xffff8800013e5000 8K USR ro x pte 0xffff8800013e5000-0xffff8800013e8000 12K USR ro x pte 0xffff8800013e8000-0xffff8800013ea000 8K USR ro x pte 0xffff8800013ea000-0xffff8800013ec000 8K USR ro x pte 0xffff8800013ec000-0xffff8800013ed000 4K USR ro x pte 0xffff8800013ed000-0xffff8800013ef000 8K USR ro x pte 0xffff8800013ef000-0xffff8800013f3000 16K USR ro x pte 0xffff8800013f3000-0xffff8800013f4000 4K USR ro x pte 0xffff8800013f4000-0xffff8800013f6000 8K USR ro x pte 0xffff8800013f6000-0xffff8800013f7000 4K USR ro x pte 0xffff8800013f7000-0xffff8800013fa000 12K USR ro x pte 0xffff8800013fa000-0xffff8800013fb000 4K USR ro x pte 0xffff8800013fb000-0xffff8800013fd000 8K USR ro x pte 0xffff8800013fd000-0xffff8800013fe000 4K USR ro x pte 0xffff8800013fe000-0xffff880001403000 20K USR ro x pte 0xffff880001403000-0xffff880001404000 4K USR ro x pte 0xffff880001404000-0xffff880001406000 8K USR ro x pte 0xffff880001406000-0xffff880001408000 8K USR ro x pte 0xffff880001408000-0xffff880001411000 36K USR ro x pte 0xffff880001411000-0xffff880001412000 4K USR ro x pte 0xffff880001412000-0xffff880001413000 4K USR ro x pte 0xffff880001413000-0xffff880001415000 8K USR ro x pte 0xffff880001415000-0xffff880001416000 4K USR ro x pte 0xffff880001416000-0xffff880001419000 12K USR ro x pte 0xffff880001419000-0xffff88000141e000 20K USR ro x pte 0xffff88000141e000-0xffff880001425000 28K USR ro x pte 0xffff880001425000-0xffff880001426000 4K USR ro x pte 0xffff880001426000-0xffff880001428000 8K USR ro x pte 0xffff880001428000-0xffff88000142f000 28K USR ro x pte 0xffff88000142f000-0xffff880001430000 4K USR ro x pte 0xffff880001430000-0xffff880001437000 28K USR ro x pte 0xffff880001437000-0xffff880001438000 4K USR ro x pte 0xffff880001438000-0xffff880001439000 4K USR ro x pte 0xffff880001439000-0xffff88000143d000 16K USR ro x pte 0xffff88000143d000-0xffff88000143e000 4K USR ro x pte 0xffff88000143e000-0xffff88000143f000 4K USR ro x pte 0xffff88000143f000-0xffff880001440000 4K USR ro x pte 0xffff880001440000-0xffff880001443000 12K USR ro x pte 0xffff880001443000-0xffff880001445000 8K USR ro x pte 0xffff880001445000-0xffff880001446000 4K USR ro x pte 0xffff880001446000-0xffff880001448000 8K USR ro x pte 0xffff880001448000-0xffff88000144d000 20K USR ro x pte 0xffff88000144d000-0xffff88000144f000 8K USR ro x pte 0xffff88000144f000-0xffff880001451000 8K USR ro x pte 0xffff880001451000-0xffff880001452000 4K USR ro x pte 0xffff880001452000-0xffff880001458000 24K USR ro x pte 0xffff880001458000-0xffff880001459000 4K USR ro x pte 0xffff880001459000-0xffff88000145a000 4K USR ro x pte 0xffff88000145a000-0xffff88000145c000 8K USR ro x pte 0xffff88000145c000-0xffff88000145d000 4K USR ro x pte 0xffff88000145d000-0xffff880001462000 20K USR ro x pte 0xffff880001462000-0xffff880001463000 4K USR ro x pte 0xffff880001463000-0xffff880001464000 4K USR ro x pte 0xffff880001464000-0xffff880001465000 4K USR ro x pte 0xffff880001465000-0xffff880001467000 8K USR ro x pte 0xffff880001467000-0xffff880001468000 4K USR ro x pte 0xffff880001468000-0xffff880001469000 4K USR ro x pte 0xffff880001469000-0xffff88000146a000 4K USR ro x pte 0xffff88000146a000-0xffff88000146b000 4K USR ro x pte 0xffff88000146b000-0xffff880001470000 20K USR ro x pte 0xffff880001470000-0xffff880001471000 4K USR ro x pte 0xffff880001471000-0xffff880001473000 8K USR ro x pte 0xffff880001473000-0xffff880001477000 16K USR ro x pte 0xffff880001477000-0xffff88000147a000 12K USR ro x pte 0xffff88000147a000-0xffff88000147b000 4K USR ro x pte 0xffff88000147b000-0xffff88000147c000 4K USR ro x pte 0xffff88000147c000-0xffff88000147d000 4K USR ro x pte 0xffff88000147d000-0xffff880001482000 20K USR ro x pte 0xffff880001482000-0xffff880001484000 8K USR ro x pte 0xffff880001484000-0xffff880001485000 4K USR ro x pte 0xffff880001485000-0xffff880001486000 4K USR ro x pte 0xffff880001486000-0xffff880001489000 12K USR ro x pte 0xffff880001489000-0xffff88000148a000 4K USR ro x pte 0xffff88000148a000-0xffff88000148b000 4K USR ro x pte 0xffff88000148b000-0xffff88000148c000 4K USR ro x pte 0xffff88000148c000-0xffff880001499000 52K USR ro x pte 0xffff880001499000-0xffff88000149a000 4K USR ro x pte 0xffff88000149a000-0xffff8800014a2000 32K USR ro x pte 0xffff8800014a2000-0xffff8800014a5000 12K USR ro x pte 0xffff8800014a5000-0xffff8800014a8000 12K USR ro x pte 0xffff8800014a8000-0xffff8800014b0000 32K USR ro x pte 0xffff8800014b0000-0xffff8800014b1000 4K USR ro x pte 0xffff8800014b1000-0xffff8800014b2000 4K USR ro x pte 0xffff8800014b2000-0xffff8800014c2000 64K USR ro x pte 0xffff8800014c2000-0xffff8800014c3000 4K USR ro x pte 0xffff8800014c3000-0xffff8800014c5000 8K USR ro x pte 0xffff8800014c5000-0xffff8800014cb000 24K USR ro x pte 0xffff8800014cb000-0xffff8800014cc000 4K USR ro x pte 0xffff8800014cc000-0xffff8800014cf000 12K USR ro x pte 0xffff8800014cf000-0xffff8800014d0000 4K USR ro x pte 0xffff8800014d0000-0xffff8800014d1000 4K USR ro x pte 0xffff8800014d1000-0xffff8800014d3000 8K USR ro x pte 0xffff8800014d3000-0xffff8800014d4000 4K USR ro x pte 0xffff8800014d4000-0xffff8800014d6000 8K USR ro x pte 0xffff8800014d6000-0xffff8800014d7000 4K USR ro x pte 0xffff8800014d7000-0xffff8800014db000 16K USR ro x pte 0xffff8800014db000-0xffff8800014dc000 4K USR ro x pte 0xffff8800014dc000-0xffff8800014de000 8K USR ro x pte 0xffff8800014de000-0xffff8800014df000 4K USR ro x pte 0xffff8800014df000-0xffff8800014e3000 16K USR ro x pte 0xffff8800014e3000-0xffff8800014e7000 16K USR ro x pte 0xffff8800014e7000-0xffff8800014e8000 4K USR ro x pte 0xffff8800014e8000-0xffff8800014e9000 4K USR ro x pte 0xffff8800014e9000-0xffff8800014f1000 32K USR ro x pte 0xffff8800014f1000-0xffff8800014f2000 4K USR ro x pte 0xffff8800014f2000-0xffff8800014f6000 16K USR ro x pte 0xffff8800014f6000-0xffff8800014f7000 4K USR ro x pte 0xffff8800014f7000-0xffff8800014f8000 4K USR ro x pte 0xffff8800014f8000-0xffff8800014f9000 4K USR ro x pte 0xffff8800014f9000-0xffff8800014fe000 20K USR ro x pte 0xffff8800014fe000-0xffff880001503000 20K USR ro x pte 0xffff880001503000-0xffff880001508000 20K USR ro x pte 0xffff880001508000-0xffff88000150d000 20K USR ro x pte 0xffff88000150d000-0xffff880001511000 16K USR ro x pte 0xffff880001511000-0xffff880001513000 8K USR ro x pte 0xffff880001513000-0xffff880001514000 4K USR ro x pte 0xffff880001514000-0xffff880001515000 4K USR ro x pte 0xffff880001515000-0xffff880001516000 4K USR ro x pte 0xffff880001516000-0xffff88000151b000 20K USR ro x pte 0xffff88000151b000-0xffff880001520000 20K USR ro x pte 0xffff880001520000-0xffff880001521000 4K USR ro x pte 0xffff880001521000-0xffff880001523000 8K USR ro x pte 0xffff880001523000-0xffff880001525000 8K USR ro x pte 0xffff880001525000-0xffff880001526000 4K USR ro x pte 0xffff880001526000-0xffff880001529000 12K USR ro x pte 0xffff880001529000-0xffff88000152a000 4K USR ro x pte 0xffff88000152a000-0xffff88000152b000 4K USR ro x pte 0xffff88000152b000-0xffff88000152e000 12K USR ro x pte 0xffff88000152e000-0xffff880001533000 20K USR ro x pte 0xffff880001533000-0xffff880001535000 8K USR ro x pte 0xffff880001535000-0xffff880001537000 8K USR ro x pte 0xffff880001537000-0xffff880001538000 4K USR ro x pte 0xffff880001538000-0xffff880001539000 4K USR ro x pte 0xffff880001539000-0xffff88000153b000 8K USR ro x pte 0xffff88000153b000-0xffff88000153d000 8K USR ro x pte 0xffff88000153d000-0xffff880001541000 16K USR ro x pte 0xffff880001541000-0xffff880001542000 4K USR ro x pte 0xffff880001542000-0xffff880001544000 8K USR ro x pte 0xffff880001544000-0xffff880001545000 4K USR ro x pte 0xffff880001545000-0xffff880001547000 8K USR ro x pte 0xffff880001547000-0xffff880001551000 40K USR ro x pte 0xffff880001551000-0xffff880001552000 4K USR ro x pte 0xffff880001552000-0xffff880001554000 8K USR ro x pte 0xffff880001554000-0xffff880001555000 4K USR ro x pte 0xffff880001555000-0xffff88000155d000 32K USR ro x pte 0xffff88000155d000-0xffff88000155f000 8K USR ro x pte 0xffff88000155f000-0xffff880001563000 16K USR ro x pte 0xffff880001563000-0xffff880001566000 12K USR ro x pte 0xffff880001566000-0xffff880001567000 4K USR ro x pte 0xffff880001567000-0xffff880001568000 4K USR ro x pte 0xffff880001568000-0xffff88000156a000 8K USR ro x pte 0xffff88000156a000-0xffff88000156b000 4K USR ro x pte 0xffff88000156b000-0xffff880001572000 28K USR ro x pte 0xffff880001572000-0xffff880001573000 4K USR ro x pte 0xffff880001573000-0xffff880001576000 12K USR ro x pte 0xffff880001576000-0xffff880001577000 4K USR ro x pte 0xffff880001577000-0xffff880001578000 4K USR ro x pte 0xffff880001578000-0xffff880001579000 4K USR ro x pte 0xffff880001579000-0xffff88000157a000 4K USR ro x pte 0xffff88000157a000-0xffff88000157b000 4K USR ro x pte 0xffff88000157b000-0xffff88000157d000 8K USR ro x pte 0xffff88000157d000-0xffff88000157f000 8K USR ro x pte 0xffff88000157f000-0xffff880001582000 12K USR ro x pte 0xffff880001582000-0xffff880001584000 8K USR ro x pte 0xffff880001584000-0xffff880001586000 8K USR ro x pte 0xffff880001586000-0xffff880001588000 8K USR ro x pte 0xffff880001588000-0xffff880001589000 4K USR ro x pte 0xffff880001589000-0xffff88000158d000 16K USR ro x pte 0xffff88000158d000-0xffff88000158f000 8K USR ro x pte 0xffff88000158f000-0xffff880001593000 16K USR ro x pte 0xffff880001593000-0xffff880001594000 4K USR ro x pte 0xffff880001594000-0xffff880001595000 4K USR ro x pte 0xffff880001595000-0xffff880001596000 4K USR ro x pte 0xffff880001596000-0xffff880001599000 12K USR ro x pte 0xffff880001599000-0xffff8800015ab000 72K USR ro x pte 0xffff8800015ab000-0xffff8800015ac000 4K USR ro x pte 0xffff8800015ac000-0xffff8800015b0000 16K USR ro x pte 0xffff8800015b0000-0xffff8800015b1000 4K USR ro x pte 0xffff8800015b1000-0xffff8800015b7000 24K USR ro x pte 0xffff8800015b7000-0xffff880001600000 292K USR RW NX pte 0xffff880001600000-0xffff88000179c000 1648K USR ro NX pte 0xffff88000179c000-0xffff880001800000 400K USR RW NX pte 0xffff880001800000-0xffff880001802000 8K USR RW x pte 0xffff880001802000-0xffff880001803000 4K USR RW x pte 0xffff880001803000-0xffff880001805000 8K USR RW x pte 0xffff880001805000-0xffff88000180b000 24K USR RW x pte 0xffff88000180b000-0xffff88000180f000 16K USR ro x pte 0xffff88000180f000-0xffff880001810000 4K USR RW x pte 0xffff880001810000-0xffff880001812000 8K USR ro x pte 0xffff880001812000-0xffff880001813000 4K USR RW x pte 0xffff880001813000-0xffff880001815000 8K USR RW x pte 0xffff880001815000-0xffff880001816000 4K USR RW x pte 0xffff880001816000-0xffff880001818000 8K USR RW x pte 0xffff880001818000-0xffff88000181a000 8K USR RW x pte 0xffff88000181a000-0xffff88000181d000 12K USR RW x pte 0xffff88000181d000-0xffff88000181e000 4K USR RW x pte 0xffff88000181e000-0xffff880001832000 80K USR RW x pte 0xffff880001832000-0xffff880001834000 8K USR RW x pte 0xffff880001834000-0xffff88000183a000 24K USR RW x pte 0xffff88000183a000-0xffff88000183d000 12K USR RW x pte 0xffff88000183d000-0xffff880001841000 16K USR RW x pte 0xffff880001841000-0xffff880001843000 8K USR RW x pte 0xffff880001843000-0xffff880001845000 8K USR RW x pte 0xffff880001845000-0xffff880001846000 4K USR RW x pte 0xffff880001846000-0xffff880001849000 12K USR RW x pte 0xffff880001849000-0xffff88000184a000 4K USR RW x pte 0xffff88000184a000-0xffff88000184f000 20K USR RW x pte 0xffff88000184f000-0xffff880001850000 4K USR RW x pte 0xffff880001850000-0xffff880001885000 212K USR RW x pte 0xffff880001885000-0xffff880001938000 716K USR RW NX pte 0xffff880001938000-0xffff88000193a000 8K USR RW x pte 0xffff88000193a000-0xffff88000193b000 4K USR ro x pte 0xffff88000193b000-0xffff88000193d000 8K USR RW x pte 0xffff88000193d000-0xffff88000193e000 4K USR ro x pte 0xffff88000193e000-0xffff880001948000 40K USR RW x pte 0xffff880001948000-0xffff88000194a000 8K USR RW x pte 0xffff88000194a000-0xffff88000194c000 8K USR RW x pte 0xffff88000194c000-0xffff88000196c000 128K USR RW x pte 0xffff88000196c000-0xffff88000196d000 4K USR RW x pte 0xffff88000196d000-0xffff880001970000 12K USR RW x pte 0xffff880001970000-0xffff880001971000 4K USR RW x pte 0xffff880001971000-0xffff880001972000 4K USR RW x pte 0xffff880001972000-0xffff880001973000 4K USR RW x pte 0xffff880001973000-0xffff880001975000 8K USR RW x pte 0xffff880001975000-0xffff880001976000 4K USR RW x pte 0xffff880001976000-0xffff880001977000 4K USR RW x pte 0xffff880001977000-0xffff88000197b000 16K USR RW x pte 0xffff88000197b000-0xffff8800019b9000 248K USR RW x pte 0xffff8800019b9000-0xffff8800019c0000 28K USR RW x pte 0xffff8800019c0000-0xffff8800019df000 124K USR RW x pte 0xffff8800019df000-0xffff8800019e8000 36K USR RW x pte 0xffff8800019e8000-0xffff8800019f1000 36K USR RW x pte 0xffff8800019f1000-0xffff8800019f2000 4K USR RW x pte 0xffff8800019f2000-0xffff8800019f3000 4K USR RW x pte 0xffff8800019f3000-0xffff8800019f5000 8K USR RW x pte 0xffff8800019f5000-0xffff8800019f8000 12K USR RW x pte 0xffff8800019f8000-0xffff880001a0a000 72K USR RW x pte 0xffff880001a0a000-0xffff880001a0f000 20K USR RW x pte 0xffff880001a0f000-0xffff880001a1c000 52K USR RW x pte 0xffff880001a1c000-0xffff880001a1d000 4K USR RW x pte 0xffff880001a1d000-0xffff880001aaa000 564K USR RW x pte 0xffff880001aaa000-0xffff880001aae000 16K USR ro x pte 0xffff880001aae000-0xffff880001b34000 536K USR RW x pte 0xffff880001b34000-0xffff880001e3d000 3108K USR RW x pte 0xffff880001e3d000-0xffff88000fc93000 227672K USR RW NX pte 0xffff88000fc93000-0xffff880020000000 265652K USR RW x pte 0xffff880020000000-0xffff880020001000 4K USR ro x pte 0xffff880020001000-0xffff880020002000 4K USR ro NX pte 0xffff880020002000-0xffff880020004000 8K USR RW NX pte 0xffff880020004000-0xffff880020008000 16K pte 0xffff880020008000-0xffff880020009000 4K USR ro x pte 0xffff880020009000-0xffff88002000a000 4K USR ro NX pte 0xffff88002000a000-0xffff88002000c000 8K USR RW NX pte 0xffff88002000c000-0xffff880020070000 400K pte 0xffff880020070000-0xffff88002024c000 1904K USR RW x pte 0xffff88002024c000-0xffff88002024e000 8K USR RW x pte 0xffff88002024e000-0xffff880020353000 1044K USR ro x pte 0xffff880020353000-0xffff880020400000 692K USR RW x pte 0xffff880020400000-0xffff880020c00000 8M USR RW x pte 0xffff880020c00000-0xffff8800ef9c0000 3389184K USR RW NX pte 0xffff8800ef9c0000-0xffff8800ff7fb000 260332K USR ro NX pte 0xffff8800ff7fb000-0xffff882019404000 130445348K USR RW NX pte 0xffff882019404000-0xffff882019406000 8K USR ro NX pte 0xffff882019406000-0xffff882019407000 4K USR RW NX pte 0xffff882019407000-0xffff882019408000 4K USR ro NX pte 0xffff882019408000-0xffff88201940a000 8K USR RW NX pte 0xffff88201940a000-0xffff88201940b000 4K USR ro NX pte 0xffff88201940b000-0xffff882019471000 408K USR RW NX pte 0xffff882019471000-0xffff882019473000 8K USR ro NX pte 0xffff882019473000-0xffff882019474000 4K USR RW NX pte 0xffff882019474000-0xffff882019477000 12K USR ro NX pte 0xffff882019477000-0xffff882019479000 8K USR RW NX pte 0xffff882019479000-0xffff88201947a000 4K USR ro NX pte 0xffff88201947a000-0xffff88201947c000 8K USR RW NX pte 0xffff88201947c000-0xffff882019482000 24K USR ro NX pte 0xffff882019482000-0xffff882019483000 4K USR RW NX pte 0xffff882019483000-0xffff882019486000 12K USR ro NX pte 0xffff882019486000-0xffff882019487000 4K USR RW NX pte 0xffff882019487000-0xffff88201948e000 28K USR ro NX pte 0xffff88201948e000-0xffff882019494000 24K USR RW NX pte 0xffff882019494000-0xffff882019495000 4K USR ro NX pte 0xffff882019495000-0xffff882019499000 16K USR RW NX pte 0xffff882019499000-0xffff88201949a000 4K USR ro NX pte 0xffff88201949a000-0xffff88201949d000 12K USR RW NX pte 0xffff88201949d000-0xffff88201949e000 4K USR ro NX pte 0xffff88201949e000-0xffff8820194a0000 8K USR RW NX pte 0xffff8820194a0000-0xffff8820194a1000 4K USR ro NX pte 0xffff8820194a1000-0xffff8820194ae000 52K USR RW NX pte 0xffff8820194ae000-0xffff8820194af000 4K USR ro NX pte 0xffff8820194af000-0xffff8820194b5000 24K USR RW NX pte 0xffff8820194b5000-0xffff8820194b6000 4K USR ro NX pte 0xffff8820194b6000-0xffff8820194b7000 4K USR RW NX pte 0xffff8820194b7000-0xffff8820194b9000 8K USR ro NX pte 0xffff8820194b9000-0xffff8820194bb000 8K USR RW NX pte 0xffff8820194bb000-0xffff8820194bc000 4K USR ro NX pte 0xffff8820194bc000-0xffff8820194bd000 4K USR RW NX pte 0xffff8820194bd000-0xffff8820194be000 4K USR ro NX pte 0xffff8820194be000-0xffff8820194f8000 232K USR RW NX pte 0xffff8820194f8000-0xffff8820194f9000 4K USR ro NX pte 0xffff8820194f9000-0xffff8820194ff000 24K USR RW NX pte 0xffff8820194ff000-0xffff882019500000 4K USR ro NX pte 0xffff882019500000-0xffff8820198be000 3832K USR RW NX pte 0xffff8820198be000-0xffff8820198c0000 8K USR ro NX pte 0xffff8820198c0000-0xffff8820198f7000 220K USR RW NX pte 0xffff8820198f7000-0xffff8820198f8000 4K USR ro NX pte 0xffff8820198f8000-0xffff882019bd8000 2944K USR RW NX pte 0xffff882019bd8000-0xffff882019be0000 32K USR ro NX pte 0xffff882019be0000-0xffff882019c06000 152K USR RW NX pte 0xffff882019c06000-0xffff882019c07000 4K USR ro NX pte 0xffff882019c07000-0xffff882019c0d000 24K USR RW NX pte 0xffff882019c0d000-0xffff882019c10000 12K USR ro NX pte 0xffff882019c10000-0xffff882019c13000 12K USR RW NX pte 0xffff882019c13000-0xffff882019c16000 12K USR ro NX pte 0xffff882019c16000-0xffff882019c17000 4K USR RW NX pte 0xffff882019c17000-0xffff882019c1f000 32K USR ro NX pte 0xffff882019c1f000-0xffff882019c20000 4K USR RW NX pte 0xffff882019c20000-0xffff882019c22000 8K USR ro NX pte 0xffff882019c22000-0xffff882019c25000 12K USR RW NX pte 0xffff882019c25000-0xffff882019c2f000 40K USR ro NX pte 0xffff882019c2f000-0xffff882019c3d000 56K USR RW NX pte 0xffff882019c3d000-0xffff882019c3e000 4K USR ro NX pte 0xffff882019c3e000-0xffff882019c40000 8K USR RW NX pte 0xffff882019c40000-0xffff882019c41000 4K USR ro NX pte 0xffff882019c41000-0xffff882019c49000 32K USR RW NX pte 0xffff882019c49000-0xffff882019c4b000 8K USR ro NX pte 0xffff882019c4b000-0xffff882019c4e000 12K USR RW NX pte 0xffff882019c4e000-0xffff882019c4f000 4K USR ro NX pte 0xffff882019c4f000-0xffff882019c50000 4K USR RW NX pte 0xffff882019c50000-0xffff882019c52000 8K USR ro NX pte 0xffff882019c52000-0xffff882019c58000 24K USR RW NX pte 0xffff882019c58000-0xffff882019c59000 4K USR ro NX pte 0xffff882019c59000-0xffff882019c64000 44K USR RW NX pte 0xffff882019c64000-0xffff882019c6b000 28K USR ro NX pte 0xffff882019c6b000-0xffff882019c6e000 12K USR RW NX pte 0xffff882019c6e000-0xffff882019c70000 8K USR ro NX pte 0xffff882019c70000-0xffff882019c72000 8K USR RW NX pte 0xffff882019c72000-0xffff882019c76000 16K USR ro NX pte 0xffff882019c76000-0xffff882019c82000 48K USR RW NX pte 0xffff882019c82000-0xffff882019c83000 4K USR ro NX pte 0xffff882019c83000-0xffff882019cc6000 268K USR RW NX pte 0xffff882019cc6000-0xffff882019cc8000 8K USR ro NX pte 0xffff882019cc8000-0xffff882019cf3000 172K USR RW NX pte 0xffff882019cf3000-0xffff882019cf4000 4K USR ro NX pte 0xffff882019cf4000-0xffff88201b000000 19504K USR RW NX pte 0xffff88201b000000-0xffff88201b006000 24K USR ro NX pte 0xffff88201b006000-0xffff88201b080000 488K USR RW NX pte 0xffff88201b080000-0xffff88201b083000 12K USR ro NX pte 0xffff88201b083000-0xffff88201b092000 60K USR RW NX pte 0xffff88201b092000-0xffff88201b093000 4K USR ro NX pte 0xffff88201b093000-0xffff88201b09c000 36K USR RW NX pte 0xffff88201b09c000-0xffff88201b09d000 4K USR ro NX pte 0xffff88201b09d000-0xffff88201b0ab000 56K USR RW NX pte 0xffff88201b0ab000-0xffff88201b0ac000 4K USR ro NX pte 0xffff88201b0ac000-0xffff88201b0c2000 88K USR RW NX pte 0xffff88201b0c2000-0xffff88201b0c3000 4K USR ro NX pte 0xffff88201b0c3000-0xffff88201b0d4000 68K USR RW NX pte 0xffff88201b0d4000-0xffff88201b0d5000 4K USR ro NX pte 0xffff88201b0d5000-0xffff88201b0e4000 60K USR RW NX pte 0xffff88201b0e4000-0xffff88201b0e5000 4K USR ro NX pte 0xffff88201b0e5000-0xffff88201b0e6000 4K USR RW NX pte 0xffff88201b0e6000-0xffff88201b0e7000 4K USR ro NX pte 0xffff88201b0e7000-0xffff88201b0eb000 16K USR RW NX pte 0xffff88201b0eb000-0xffff88201b0ec000 4K USR ro NX pte 0xffff88201b0ec000-0xffff88201b0f3000 28K USR RW NX pte 0xffff88201b0f3000-0xffff88201b0f4000 4K USR ro NX pte 0xffff88201b0f4000-0xffff88201b0f5000 4K USR RW NX pte 0xffff88201b0f5000-0xffff88201b0f6000 4K USR ro NX pte 0xffff88201b0f6000-0xffff88201b0fa000 16K USR RW NX pte 0xffff88201b0fa000-0xffff88201b0fc000 8K USR ro NX pte 0xffff88201b0fc000-0xffff88201cc9c000 28288K USR RW NX pte 0xffff88201cc9c000-0xffff88201cc9f000 12K USR ro NX pte 0xffff88201cc9f000-0xffff88201ccb7000 96K USR RW NX pte 0xffff88201ccb7000-0xffff88201ccb8000 4K USR ro NX pte 0xffff88201ccb8000-0xffff88201ccb9000 4K USR RW NX pte 0xffff88201ccb9000-0xffff88201ccba000 4K USR ro NX pte 0xffff88201ccba000-0xffff88201ccc6000 48K USR RW NX pte 0xffff88201ccc6000-0xffff88201ccc7000 4K USR ro NX pte 0xffff88201ccc7000-0xffff88201cce8000 132K USR RW NX pte 0xffff88201cce8000-0xffff88201cce9000 4K USR ro NX pte 0xffff88201cce9000-0xffff88201ccea000 4K USR RW NX pte 0xffff88201ccea000-0xffff88201cceb000 4K USR ro NX pte 0xffff88201cceb000-0xffff88201ccf5000 40K USR RW NX pte 0xffff88201ccf5000-0xffff88201ccf6000 4K USR ro NX pte 0xffff88201ccf6000-0xffff882021184000 70200K USR RW NX pte 0xffff882021184000-0xffff882021185000 4K USR ro NX pte 0xffff882021185000-0xffff882021186000 4K USR RW NX pte 0xffff882021186000-0xffff882021188000 8K USR ro NX pte 0xffff882021188000-0xffff882021195000 52K USR RW NX pte 0xffff882021195000-0xffff882021196000 4K USR ro NX pte 0xffff882021196000-0xffff88202119f000 36K USR RW NX pte 0xffff88202119f000-0xffff8820211a0000 4K USR ro NX pte 0xffff8820211a0000-0xffff8820211d1000 196K USR RW NX pte 0xffff8820211d1000-0xffff8820211d3000 8K USR ro NX pte 0xffff8820211d3000-0xffff8820211f8000 148K USR RW NX pte 0xffff8820211f8000-0xffff8820211f9000 4K USR ro NX pte 0xffff8820211f9000-0xffff8820211fa000 4K USR RW NX pte 0xffff8820211fa000-0xffff8820211fb000 4K USR ro NX pte 0xffff8820211fb000-0xffff8820211fd000 8K USR RW NX pte 0xffff8820211fd000-0xffff8820211fe000 4K USR ro NX pte 0xffff8820211fe000-0xffff882021360000 1416K USR RW NX pte 0xffff882021360000-0xffff882021361000 4K USR ro NX pte 0xffff882021361000-0xffff882021362000 4K USR RW NX pte 0xffff882021362000-0xffff882021363000 4K USR ro NX pte 0xffff882021363000-0xffff882021397000 208K USR RW NX pte 0xffff882021397000-0xffff882021398000 4K USR ro NX pte 0xffff882021398000-0xffff8820213a2000 40K USR RW NX pte 0xffff8820213a2000-0xffff8820213a3000 4K USR ro NX pte 0xffff8820213a3000-0xffff8820213ab000 32K USR RW NX pte 0xffff8820213ab000-0xffff8820213ac000 4K USR ro NX pte 0xffff8820213ac000-0xffff8820213bb000 60K USR RW NX pte 0xffff8820213bb000-0xffff8820213be000 12K USR ro NX pte 0xffff8820213be000-0xffff8820213bf000 4K USR RW NX pte 0xffff8820213bf000-0xffff8820213c0000 4K USR ro NX pte 0xffff8820213c0000-0xffff8820213c1000 4K USR RW NX pte 0xffff8820213c1000-0xffff8820213c2000 4K USR ro NX pte 0xffff8820213c2000-0xffff8820213c3000 4K USR RW NX pte 0xffff8820213c3000-0xffff8820213c4000 4K USR ro NX pte 0xffff8820213c4000-0xffff8820213c5000 4K USR RW NX pte 0xffff8820213c5000-0xffff8820213c6000 4K USR ro NX pte 0xffff8820213c6000-0xffff8820213c7000 4K USR RW NX pte 0xffff8820213c7000-0xffff8820213c8000 4K USR ro NX pte 0xffff8820213c8000-0xffff8820213c9000 4K USR RW NX pte 0xffff8820213c9000-0xffff8820213cb000 8K USR ro NX pte 0xffff8820213cb000-0xffff8820213cf000 16K USR RW NX pte 0xffff8820213cf000-0xffff8820213d0000 4K USR ro NX pte 0xffff8820213d0000-0xffff8820213d3000 12K USR RW NX pte 0xffff8820213d3000-0xffff8820213d4000 4K USR ro NX pte 0xffff8820213d4000-0xffff8820213d5000 4K USR RW NX pte 0xffff8820213d5000-0xffff8820213d6000 4K USR ro NX pte 0xffff8820213d6000-0xffff8820213db000 20K USR RW NX pte 0xffff8820213db000-0xffff8820213dc000 4K USR ro NX pte 0xffff8820213dc000-0xffff8820213dd000 4K USR RW NX pte 0xffff8820213dd000-0xffff8820213df000 8K USR ro NX pte 0xffff8820213df000-0xffff8820213e7000 32K USR RW NX pte 0xffff8820213e7000-0xffff8820213e8000 4K USR ro NX pte 0xffff8820213e8000-0xffff8820213f6000 56K USR RW NX pte 0xffff8820213f6000-0xffff8820213f7000 4K USR ro NX pte 0xffff8820213f7000-0xffff8820213fd000 24K USR RW NX pte 0xffff8820213fd000-0xffff8820213fe000 4K USR ro NX pte 0xffff8820213fe000-0xffff882021816000 4192K USR RW NX pte 0xffff882021816000-0xffff882021817000 4K USR ro NX pte 0xffff882021817000-0xffff882021826000 60K USR RW NX pte 0xffff882021826000-0xffff882021829000 12K USR ro NX pte 0xffff882021829000-0xffff88202182d000 16K USR RW NX pte 0xffff88202182d000-0xffff88202182e000 4K USR ro NX pte 0xffff88202182e000-0xffff882021840000 72K USR RW NX pte 0xffff882021840000-0xffff882021842000 8K USR ro NX pte 0xffff882021842000-0xffff882021843000 4K USR RW NX pte 0xffff882021843000-0xffff882021844000 4K USR ro NX pte 0xffff882021844000-0xffff882021846000 8K USR RW NX pte 0xffff882021846000-0xffff88202184a000 16K USR ro NX pte 0xffff88202184a000-0xffff88202184b000 4K USR RW NX pte 0xffff88202184b000-0xffff882021850000 20K USR ro NX pte 0xffff882021850000-0xffff882021859000 36K USR RW NX pte 0xffff882021859000-0xffff88202185b000 8K USR ro NX pte 0xffff88202185b000-0xffff882021861000 24K USR RW NX pte 0xffff882021861000-0xffff882021866000 20K USR ro NX pte 0xffff882021866000-0xffff882021867000 4K USR RW NX pte 0xffff882021867000-0xffff882021868000 4K USR ro NX pte 0xffff882021868000-0xffff88202186b000 12K USR RW NX pte 0xffff88202186b000-0xffff88202186c000 4K USR ro NX pte 0xffff88202186c000-0xffff88202188a000 120K USR RW NX pte 0xffff88202188a000-0xffff88202188b000 4K USR ro NX pte 0xffff88202188b000-0xffff882021891000 24K USR RW NX pte 0xffff882021891000-0xffff882021892000 4K USR ro NX pte 0xffff882021892000-0xffff8820218b2000 128K USR RW NX pte 0xffff8820218b2000-0xffff8820218b3000 4K USR ro NX pte 0xffff8820218b3000-0xffff8820218ee000 236K USR RW NX pte 0xffff8820218ee000-0xffff8820218ef000 4K USR ro NX pte 0xffff8820218ef000-0xffff8820218fa000 44K USR RW NX pte 0xffff8820218fa000-0xffff8820218fb000 4K USR ro NX pte 0xffff8820218fb000-0xffff882021b1f000 2192K USR RW NX pte 0xffff882021b1f000-0xffff882021b20000 4K USR ro NX pte 0xffff882021b20000-0xffff882021b33000 76K USR RW NX pte 0xffff882021b33000-0xffff882021b34000 4K USR ro NX pte 0xffff882021b34000-0xffff882021b3c000 32K USR RW NX pte 0xffff882021b3c000-0xffff882021b3d000 4K USR ro NX pte 0xffff882021b3d000-0xffff882021b68000 172K USR RW NX pte 0xffff882021b68000-0xffff882021b69000 4K USR ro NX pte 0xffff882021b69000-0xffff882021b77000 56K USR RW NX pte 0xffff882021b77000-0xffff882021b78000 4K USR ro NX pte 0xffff882021b78000-0xffff882021b84000 48K USR RW NX pte 0xffff882021b84000-0xffff882021b85000 4K USR ro NX pte 0xffff882021b85000-0xffff882021baf000 168K USR RW NX pte 0xffff882021baf000-0xffff882021bb0000 4K USR ro NX pte 0xffff882021bb0000-0xffff882021bcf000 124K USR RW NX pte 0xffff882021bcf000-0xffff882021bd0000 4K USR ro NX pte 0xffff882021bd0000-0xffff882021be2000 72K USR RW NX pte 0xffff882021be2000-0xffff882021be4000 8K USR ro NX pte 0xffff882021be4000-0xffff8820243d9000 40916K USR RW NX pte 0xffff8820243d9000-0xffff8820243dc000 12K USR ro NX pte 0xffff8820243dc000-0xffff8820243e1000 20K USR RW NX pte 0xffff8820243e1000-0xffff8820243e2000 4K USR ro NX pte 0xffff8820243e2000-0xffff882028dde000 75760K USR RW NX pte 0xffff882028dde000-0xffff882028ddf000 4K USR ro NX pte 0xffff882028ddf000-0xffff882028fe0000 2052K USR RW NX pte 0xffff882028fe0000-0xffff882028fe1000 4K USR ro NX pte 0xffff882028fe1000-0xffff8820292d8000 3036K USR RW NX pte 0xffff8820292d8000-0xffff8820292dc000 16K USR ro NX pte 0xffff8820292dc000-0xffff8820293dd000 1028K USR RW NX pte 0xffff8820293dd000-0xffff8820293de000 4K USR ro NX pte 0xffff8820293de000-0xffff882029ac4000 7064K USR RW NX pte 0xffff882029ac4000-0xffff882029ac6000 8K USR ro NX pte 0xffff882029ac6000-0xffff882029d5f000 2660K USR RW NX pte 0xffff882029d5f000-0xffff882029d9e000 252K USR ro NX pte 0xffff882029d9e000-0xffff882031c9e000 127M USR RW NX pte 0xffff882031c9e000-0xffff882031d1e000 512K USR ro NX pte 0xffff882031d1e000-0xffff882031d5e000 256K USR RW NX pte 0xffff882031d5e000-0xffff882031d5f000 4K USR ro NX pte 0xffff882031d5f000-0xffff882032658000 9188K USR RW NX pte 0xffff882032658000-0xffff882032800000 1696K USR ro NX pte 0xffff882032800000-0xffff8820b509b000 2138732K USR RW NX pte 0xffff8820b509b000-0xffff8820b509e000 12K USR ro NX pte 0xffff8820b509e000-0xffff8820b5600000 5512K USR RW NX pte 0xffff8820b5600000-0xffff8820b57f0000 1984K USR ro NX pte 0xffff8820b57f0000-0xffff8820b5fa9000 7908K USR RW NX pte 0xffff8820b5fa9000-0xffff8820b5faa000 4K USR ro NX pte 0xffff8820b5faa000-0xffff8820b5fc2000 96K USR RW NX pte 0xffff8820b5fc2000-0xffff8820b5fc6000 16K USR ro NX pte 0xffff8820b5fc6000-0xffff8820b7000000 16616K USR RW NX pte 0xffff8820b7000000-0xffff8820b7800000 8M pte 0xffff8820b7800000-0xffff8820c0000000 136M pmd 0xffff8820c0000000-0xffff888000000000 381G pud 0xffff888000000000-0xffffc90000000000 66048G pgd ---[ vmalloc() Area ]--- 0xffffc90000000000-0xffffc90010000000 256M USR RW NX pte 0xffffc90010000000-0xffffc90010001000 4K pte 0xffffc90010001000-0xffffc90010081000 512K USR RW NX pte 0xffffc90010081000-0xffffc90010082000 4K pte 0xffffc90010082000-0xffffc90018082000 128M USR RW NX pte 0xffffc90018082000-0xffffc90018083000 4K pte 0xffffc90018083000-0xffffc900180c3000 256K USR RW NX pte 0xffffc900180c3000-0xffffc900180c4000 4K pte 0xffffc900180c4000-0xffffc900180c6000 8K USR RW NX pte 0xffffc900180c6000-0xffffc900180c8000 8K pte 0xffffc900180c8000-0xffffc900180c9000 4K USR RW NX pte 0xffffc900180c9000-0xffffc900180cd000 16K pte 0xffffc900180cd000-0xffffc900180d1000 16K USR RW NX pte 0xffffc900180d1000-0xffffc900180d2000 4K pte 0xffffc900180d2000-0xffffc900180dd000 44K USR RW NX pte 0xffffc900180dd000-0xffffc900180de000 4K pte 0xffffc900180de000-0xffffc900180ea000 48K USR RW NX pte 0xffffc900180ea000-0xffffc90018100000 88K pte 0xffffc90018100000-0xffffc90018101000 4K USR RW NX pte 0xffffc90018101000-0xffffc90018121000 128K pte 0xffffc90018121000-0xffffc90018521000 4M USR RW NX pte 0xffffc90018521000-0xffffc90018522000 4K pte 0xffffc90018522000-0xffffc90018d22000 8M USR RW NX pte 0xffffc90018d22000-0xffffc90018d23000 4K pte 0xffffc90018d23000-0xffffc90018e23000 1M USR RW NX pte 0xffffc90018e23000-0xffffc90018e24000 4K pte 0xffffc90018e24000-0xffffc90019024000 2M USR RW NX pte 0xffffc90019024000-0xffffc90019025000 4K pte 0xffffc90019025000-0xffffc90019225000 2M USR RW NX pte 0xffffc90019225000-0xffffc90019600000 3948K pte 0xffffc90019600000-0xffffc90040000000 618M pmd 0xffffc90040000000-0xffffc98000000000 511G pud 0xffffc98000000000-0xffffea0000000000 33280G pgd ---[ Vmemmap ]--- 0xffffea0000000000-0xffffea0072840000 1876224K USR RW NX pte 0xffffea0072840000-0xffffea0072a00000 1792K pte 0xffffea0072a00000-0xffffea0080000000 214M pmd 0xffffea0080000000-0xffffea8000000000 510G pud 0xffffea8000000000-0xffffff8000000000 21T pgd 0xffffff8000000000-0xffffffff80000000 510G pud ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff81002000 8K USR ro x pte 0xffffffff81002000-0xffffffff81013000 68K USR ro x pte 0xffffffff81013000-0xffffffff81015000 8K USR ro x pte 0xffffffff81015000-0xffffffff81017000 8K USR ro x pte 0xffffffff81017000-0xffffffff81019000 8K USR ro x pte 0xffffffff81019000-0xffffffff8101a000 4K USR ro x pte 0xffffffff8101a000-0xffffffff8101b000 4K USR ro x pte 0xffffffff8101b000-0xffffffff8101f000 16K USR ro x pte 0xffffffff8101f000-0xffffffff81028000 36K USR ro x pte 0xffffffff81028000-0xffffffff8102a000 8K USR ro x pte 0xffffffff8102a000-0xffffffff8102c000 8K USR ro x pte 0xffffffff8102c000-0xffffffff8103c000 64K USR ro x pte 0xffffffff8103c000-0xffffffff8103d000 4K USR ro x pte 0xffffffff8103d000-0xffffffff81051000 80K USR ro x pte 0xffffffff81051000-0xffffffff81052000 4K USR ro x pte 0xffffffff81052000-0xffffffff81057000 20K USR ro x pte 0xffffffff81057000-0xffffffff81058000 4K USR ro x pte 0xffffffff81058000-0xffffffff81061000 36K USR ro x pte 0xffffffff81061000-0xffffffff81063000 8K USR ro x pte 0xffffffff81063000-0xffffffff8106b000 32K USR ro x pte 0xffffffff8106b000-0xffffffff8106c000 4K USR ro x pte 0xffffffff8106c000-0xffffffff81078000 48K USR ro x pte 0xffffffff81078000-0xffffffff8107a000 8K USR ro x pte 0xffffffff8107a000-0xffffffff81083000 36K USR ro x pte 0xffffffff81083000-0xffffffff81084000 4K USR ro x pte 0xffffffff81084000-0xffffffff8108f000 44K USR ro x pte 0xffffffff8108f000-0xffffffff81090000 4K USR ro x pte 0xffffffff81090000-0xffffffff81094000 16K USR ro x pte 0xffffffff81094000-0xffffffff81097000 12K USR ro x pte 0xffffffff81097000-0xffffffff810a0000 36K USR ro x pte 0xffffffff810a0000-0xffffffff810a2000 8K USR ro x pte 0xffffffff810a2000-0xffffffff810a7000 20K USR ro x pte 0xffffffff810a7000-0xffffffff810a8000 4K USR ro x pte 0xffffffff810a8000-0xffffffff810aa000 8K USR ro x pte 0xffffffff810aa000-0xffffffff810af000 20K USR ro x pte 0xffffffff810af000-0xffffffff810b4000 20K USR ro x pte 0xffffffff810b4000-0xffffffff810b6000 8K USR ro x pte 0xffffffff810b6000-0xffffffff810c0000 40K USR ro x pte 0xffffffff810c0000-0xffffffff810c4000 16K USR ro x pte 0xffffffff810c4000-0xffffffff810c6000 8K USR ro x pte 0xffffffff810c6000-0xffffffff810ca000 16K USR ro x pte 0xffffffff810ca000-0xffffffff810cc000 8K USR ro x pte 0xffffffff810cc000-0xffffffff810cd000 4K USR ro x pte 0xffffffff810cd000-0xffffffff810d5000 32K USR ro x pte 0xffffffff810d5000-0xffffffff810d9000 16K USR ro x pte 0xffffffff810d9000-0xffffffff810da000 4K USR ro x pte 0xffffffff810da000-0xffffffff810db000 4K USR ro x pte 0xffffffff810db000-0xffffffff810dc000 4K USR ro x pte 0xffffffff810dc000-0xffffffff810dd000 4K USR ro x pte 0xffffffff810dd000-0xffffffff810e2000 20K USR ro x pte 0xffffffff810e2000-0xffffffff810e3000 4K USR ro x pte 0xffffffff810e3000-0xffffffff810f8000 84K USR ro x pte 0xffffffff810f8000-0xffffffff810fb000 12K USR ro x pte 0xffffffff810fb000-0xffffffff81101000 24K USR ro x pte 0xffffffff81101000-0xffffffff81102000 4K USR ro x pte 0xffffffff81102000-0xffffffff81106000 16K USR ro x pte 0xffffffff81106000-0xffffffff81107000 4K USR ro x pte 0xffffffff81107000-0xffffffff81108000 4K USR ro x pte 0xffffffff81108000-0xffffffff81109000 4K USR ro x pte 0xffffffff81109000-0xffffffff81113000 40K USR ro x pte 0xffffffff81113000-0xffffffff81114000 4K USR ro x pte 0xffffffff81114000-0xffffffff81117000 12K USR ro x pte 0xffffffff81117000-0xffffffff81118000 4K USR ro x pte 0xffffffff81118000-0xffffffff81122000 40K USR ro x pte 0xffffffff81122000-0xffffffff81124000 8K USR ro x pte 0xffffffff81124000-0xffffffff81143000 124K USR ro x pte 0xffffffff81143000-0xffffffff81145000 8K USR ro x pte 0xffffffff81145000-0xffffffff81166000 132K USR ro x pte 0xffffffff81166000-0xffffffff81168000 8K USR ro x pte 0xffffffff81168000-0xffffffff8116d000 20K USR ro x pte 0xffffffff8116d000-0xffffffff8116e000 4K USR ro x pte 0xffffffff8116e000-0xffffffff8116f000 4K USR ro x pte 0xffffffff8116f000-0xffffffff81170000 4K USR ro x pte 0xffffffff81170000-0xffffffff81174000 16K USR ro x pte 0xffffffff81174000-0xffffffff81177000 12K USR ro x pte 0xffffffff81177000-0xffffffff8117a000 12K USR ro x pte 0xffffffff8117a000-0xffffffff8117e000 16K USR ro x pte 0xffffffff8117e000-0xffffffff8118d000 60K USR ro x pte 0xffffffff8118d000-0xffffffff8118e000 4K USR ro x pte 0xffffffff8118e000-0xffffffff81190000 8K USR ro x pte 0xffffffff81190000-0xffffffff81191000 4K USR ro x pte 0xffffffff81191000-0xffffffff81192000 4K USR ro x pte 0xffffffff81192000-0xffffffff81193000 4K USR ro x pte 0xffffffff81193000-0xffffffff81194000 4K USR ro x pte 0xffffffff81194000-0xffffffff81197000 12K USR ro x pte 0xffffffff81197000-0xffffffff81198000 4K USR ro x pte 0xffffffff81198000-0xffffffff81199000 4K USR ro x pte 0xffffffff81199000-0xffffffff811a0000 28K USR ro x pte 0xffffffff811a0000-0xffffffff811a1000 4K USR ro x pte 0xffffffff811a1000-0xffffffff811ab000 40K USR ro x pte 0xffffffff811ab000-0xffffffff811ac000 4K USR ro x pte 0xffffffff811ac000-0xffffffff811af000 12K USR ro x pte 0xffffffff811af000-0xffffffff811b1000 8K USR ro x pte 0xffffffff811b1000-0xffffffff811b4000 12K USR ro x pte 0xffffffff811b4000-0xffffffff811b5000 4K USR ro x pte 0xffffffff811b5000-0xffffffff811b9000 16K USR ro x pte 0xffffffff811b9000-0xffffffff811bb000 8K USR ro x pte 0xffffffff811bb000-0xffffffff811bd000 8K USR ro x pte 0xffffffff811bd000-0xffffffff811be000 4K USR ro x pte 0xffffffff811be000-0xffffffff811c2000 16K USR ro x pte 0xffffffff811c2000-0xffffffff811c6000 16K USR ro x pte 0xffffffff811c6000-0xffffffff811c7000 4K USR ro x pte 0xffffffff811c7000-0xffffffff811c8000 4K USR ro x pte 0xffffffff811c8000-0xffffffff811c9000 4K USR ro x pte 0xffffffff811c9000-0xffffffff811ca000 4K USR ro x pte 0xffffffff811ca000-0xffffffff811cf000 20K USR ro x pte 0xffffffff811cf000-0xffffffff811d0000 4K USR ro x pte 0xffffffff811d0000-0xffffffff811d3000 12K USR ro x pte 0xffffffff811d3000-0xffffffff811d5000 8K USR ro x pte 0xffffffff811d5000-0xffffffff811d6000 4K USR ro x pte 0xffffffff811d6000-0xffffffff811d8000 8K USR ro x pte 0xffffffff811d8000-0xffffffff811d9000 4K USR ro x pte 0xffffffff811d9000-0xffffffff811da000 4K USR ro x pte 0xffffffff811da000-0xffffffff811e0000 24K USR ro x pte 0xffffffff811e0000-0xffffffff811e3000 12K USR ro x pte 0xffffffff811e3000-0xffffffff811e9000 24K USR ro x pte 0xffffffff811e9000-0xffffffff811ea000 4K USR ro x pte 0xffffffff811ea000-0xffffffff811eb000 4K USR ro x pte 0xffffffff811eb000-0xffffffff811f1000 24K USR ro x pte 0xffffffff811f1000-0xffffffff811f7000 24K USR ro x pte 0xffffffff811f7000-0xffffffff811f8000 4K USR ro x pte 0xffffffff811f8000-0xffffffff811fa000 8K USR ro x pte 0xffffffff811fa000-0xffffffff811fb000 4K USR ro x pte 0xffffffff811fb000-0xffffffff811fd000 8K USR ro x pte 0xffffffff811fd000-0xffffffff811fe000 4K USR ro x pte 0xffffffff811fe000-0xffffffff81200000 8K USR ro x pte 0xffffffff81200000-0xffffffff81201000 4K USR ro x pte 0xffffffff81201000-0xffffffff81203000 8K USR ro x pte 0xffffffff81203000-0xffffffff81207000 16K USR ro x pte 0xffffffff81207000-0xffffffff81209000 8K USR ro x pte 0xffffffff81209000-0xffffffff8120a000 4K USR ro x pte 0xffffffff8120a000-0xffffffff8120b000 4K USR ro x pte 0xffffffff8120b000-0xffffffff8120c000 4K USR ro x pte 0xffffffff8120c000-0xffffffff8120e000 8K USR ro x pte 0xffffffff8120e000-0xffffffff81223000 84K USR ro x pte 0xffffffff81223000-0xffffffff81228000 20K USR ro x pte 0xffffffff81228000-0xffffffff81229000 4K USR ro x pte 0xffffffff81229000-0xffffffff8123b000 72K USR ro x pte 0xffffffff8123b000-0xffffffff8123d000 8K USR ro x pte 0xffffffff8123d000-0xffffffff8123e000 4K USR ro x pte 0xffffffff8123e000-0xffffffff8123f000 4K USR ro x pte 0xffffffff8123f000-0xffffffff81242000 12K USR ro x pte 0xffffffff81242000-0xffffffff81244000 8K USR ro x pte 0xffffffff81244000-0xffffffff81245000 4K USR ro x pte 0xffffffff81245000-0xffffffff81247000 8K USR ro x pte 0xffffffff81247000-0xffffffff81248000 4K USR ro x pte 0xffffffff81248000-0xffffffff81252000 40K USR ro x pte 0xffffffff81252000-0xffffffff81253000 4K USR ro x pte 0xffffffff81253000-0xffffffff81254000 4K USR ro x pte 0xffffffff81254000-0xffffffff81255000 4K USR ro x pte 0xffffffff81255000-0xffffffff81258000 12K USR ro x pte 0xffffffff81258000-0xffffffff81259000 4K USR ro x pte 0xffffffff81259000-0xffffffff81268000 60K USR ro x pte 0xffffffff81268000-0xffffffff8126e000 24K USR ro x pte 0xffffffff8126e000-0xffffffff8126f000 4K USR ro x pte 0xffffffff8126f000-0xffffffff81272000 12K USR ro x pte 0xffffffff81272000-0xffffffff81273000 4K USR ro x pte 0xffffffff81273000-0xffffffff81274000 4K USR ro x pte 0xffffffff81274000-0xffffffff8127a000 24K USR ro x pte 0xffffffff8127a000-0xffffffff8127c000 8K USR ro x pte 0xffffffff8127c000-0xffffffff8127d000 4K USR ro x pte 0xffffffff8127d000-0xffffffff81285000 32K USR ro x pte 0xffffffff81285000-0xffffffff81286000 4K USR ro x pte 0xffffffff81286000-0xffffffff81287000 4K USR ro x pte 0xffffffff81287000-0xffffffff81288000 4K USR ro x pte 0xffffffff81288000-0xffffffff81289000 4K USR ro x pte 0xffffffff81289000-0xffffffff8128d000 16K USR ro x pte 0xffffffff8128d000-0xffffffff8128f000 8K USR ro x pte 0xffffffff8128f000-0xffffffff81291000 8K USR ro x pte 0xffffffff81291000-0xffffffff81292000 4K USR ro x pte 0xffffffff81292000-0xffffffff8129f000 52K USR ro x pte 0xffffffff8129f000-0xffffffff812a0000 4K USR ro x pte 0xffffffff812a0000-0xffffffff812a1000 4K USR ro x pte 0xffffffff812a1000-0xffffffff812a3000 8K USR ro x pte 0xffffffff812a3000-0xffffffff812a5000 8K USR ro x pte 0xffffffff812a5000-0xffffffff812a6000 4K USR ro x pte 0xffffffff812a6000-0xffffffff812a9000 12K USR ro x pte 0xffffffff812a9000-0xffffffff812ab000 8K USR ro x pte 0xffffffff812ab000-0xffffffff812c3000 96K USR ro x pte 0xffffffff812c3000-0xffffffff812c6000 12K USR ro x pte 0xffffffff812c6000-0xffffffff812cc000 24K USR ro x pte 0xffffffff812cc000-0xffffffff812cf000 12K USR ro x pte 0xffffffff812cf000-0xffffffff812d1000 8K USR ro x pte 0xffffffff812d1000-0xffffffff812d2000 4K USR ro x pte 0xffffffff812d2000-0xffffffff812d3000 4K USR ro x pte 0xffffffff812d3000-0xffffffff812d7000 16K USR ro x pte 0xffffffff812d7000-0xffffffff812d8000 4K USR ro x pte 0xffffffff812d8000-0xffffffff812da000 8K USR ro x pte 0xffffffff812da000-0xffffffff812dc000 8K USR ro x pte 0xffffffff812dc000-0xffffffff812e1000 20K USR ro x pte 0xffffffff812e1000-0xffffffff812e3000 8K USR ro x pte 0xffffffff812e3000-0xffffffff812e4000 4K USR ro x pte 0xffffffff812e4000-0xffffffff812e5000 4K USR ro x pte 0xffffffff812e5000-0xffffffff812e6000 4K USR ro x pte 0xffffffff812e6000-0xffffffff812e7000 4K USR ro x pte 0xffffffff812e7000-0xffffffff812ed000 24K USR ro x pte 0xffffffff812ed000-0xffffffff812ee000 4K USR ro x pte 0xffffffff812ee000-0xffffffff812f9000 44K USR ro x pte 0xffffffff812f9000-0xffffffff812fa000 4K USR ro x pte 0xffffffff812fa000-0xffffffff812fe000 16K USR ro x pte 0xffffffff812fe000-0xffffffff81300000 8K USR ro x pte 0xffffffff81300000-0xffffffff81302000 8K USR ro x pte 0xffffffff81302000-0xffffffff8130d000 44K USR ro x pte 0xffffffff8130d000-0xffffffff8130e000 4K USR ro x pte 0xffffffff8130e000-0xffffffff8130f000 4K USR ro x pte 0xffffffff8130f000-0xffffffff81312000 12K USR ro x pte 0xffffffff81312000-0xffffffff81314000 8K USR ro x pte 0xffffffff81314000-0xffffffff81318000 16K USR ro x pte 0xffffffff81318000-0xffffffff8131b000 12K USR ro x pte 0xffffffff8131b000-0xffffffff8131c000 4K USR ro x pte 0xffffffff8131c000-0xffffffff81324000 32K USR ro x pte 0xffffffff81324000-0xffffffff81329000 20K USR ro x pte 0xffffffff81329000-0xffffffff8132d000 16K USR ro x pte 0xffffffff8132d000-0xffffffff8132e000 4K USR ro x pte 0xffffffff8132e000-0xffffffff8132f000 4K USR ro x pte 0xffffffff8132f000-0xffffffff81332000 12K USR ro x pte 0xffffffff81332000-0xffffffff81333000 4K USR ro x pte 0xffffffff81333000-0xffffffff81334000 4K USR ro x pte 0xffffffff81334000-0xffffffff81335000 4K USR ro x pte 0xffffffff81335000-0xffffffff81337000 8K USR ro x pte 0xffffffff81337000-0xffffffff8133b000 16K USR ro x pte 0xffffffff8133b000-0xffffffff8133c000 4K USR ro x pte 0xffffffff8133c000-0xffffffff81340000 16K USR ro x pte 0xffffffff81340000-0xffffffff81342000 8K USR ro x pte 0xffffffff81342000-0xffffffff81343000 4K USR ro x pte 0xffffffff81343000-0xffffffff81348000 20K USR ro x pte 0xffffffff81348000-0xffffffff8134c000 16K USR ro x pte 0xffffffff8134c000-0xffffffff81350000 16K USR ro x pte 0xffffffff81350000-0xffffffff81351000 4K USR ro x pte 0xffffffff81351000-0xffffffff81353000 8K USR ro x pte 0xffffffff81353000-0xffffffff81358000 20K USR ro x pte 0xffffffff81358000-0xffffffff8135e000 24K USR ro x pte 0xffffffff8135e000-0xffffffff8135f000 4K USR ro x pte 0xffffffff8135f000-0xffffffff81361000 8K USR ro x pte 0xffffffff81361000-0xffffffff81366000 20K USR ro x pte 0xffffffff81366000-0xffffffff81367000 4K USR ro x pte 0xffffffff81367000-0xffffffff81368000 4K USR ro x pte 0xffffffff81368000-0xffffffff8136a000 8K USR ro x pte 0xffffffff8136a000-0xffffffff81374000 40K USR ro x pte 0xffffffff81374000-0xffffffff81376000 8K USR ro x pte 0xffffffff81376000-0xffffffff81379000 12K USR ro x pte 0xffffffff81379000-0xffffffff8137f000 24K USR ro x pte 0xffffffff8137f000-0xffffffff81380000 4K USR ro x pte 0xffffffff81380000-0xffffffff81383000 12K USR ro x pte 0xffffffff81383000-0xffffffff81384000 4K USR ro x pte 0xffffffff81384000-0xffffffff81387000 12K USR ro x pte 0xffffffff81387000-0xffffffff81389000 8K USR ro x pte 0xffffffff81389000-0xffffffff8138c000 12K USR ro x pte 0xffffffff8138c000-0xffffffff81393000 28K USR ro x pte 0xffffffff81393000-0xffffffff81395000 8K USR ro x pte 0xffffffff81395000-0xffffffff81398000 12K USR ro x pte 0xffffffff81398000-0xffffffff8139a000 8K USR ro x pte 0xffffffff8139a000-0xffffffff8139c000 8K USR ro x pte 0xffffffff8139c000-0xffffffff8139d000 4K USR ro x pte 0xffffffff8139d000-0xffffffff813a3000 24K USR ro x pte 0xffffffff813a3000-0xffffffff813a4000 4K USR ro x pte 0xffffffff813a4000-0xffffffff813a5000 4K USR ro x pte 0xffffffff813a5000-0xffffffff813a6000 4K USR ro x pte 0xffffffff813a6000-0xffffffff813a9000 12K USR ro x pte 0xffffffff813a9000-0xffffffff813ab000 8K USR ro x pte 0xffffffff813ab000-0xffffffff813ac000 4K USR ro x pte 0xffffffff813ac000-0xffffffff813ae000 8K USR ro x pte 0xffffffff813ae000-0xffffffff813b1000 12K USR ro x pte 0xffffffff813b1000-0xffffffff813b3000 8K USR ro x pte 0xffffffff813b3000-0xffffffff813b5000 8K USR ro x pte 0xffffffff813b5000-0xffffffff813b9000 16K USR ro x pte 0xffffffff813b9000-0xffffffff813ba000 4K USR ro x pte 0xffffffff813ba000-0xffffffff813bf000 20K USR ro x pte 0xffffffff813bf000-0xffffffff813ce000 60K USR ro x pte 0xffffffff813ce000-0xffffffff813cf000 4K USR ro x pte 0xffffffff813cf000-0xffffffff813d0000 4K USR ro x pte 0xffffffff813d0000-0xffffffff813d2000 8K USR ro x pte 0xffffffff813d2000-0xffffffff813d3000 4K USR ro x pte 0xffffffff813d3000-0xffffffff813db000 32K USR ro x pte 0xffffffff813db000-0xffffffff813dc000 4K USR ro x pte 0xffffffff813dc000-0xffffffff813dd000 4K USR ro x pte 0xffffffff813dd000-0xffffffff813de000 4K USR ro x pte 0xffffffff813de000-0xffffffff813e0000 8K USR ro x pte 0xffffffff813e0000-0xffffffff813e3000 12K USR ro x pte 0xffffffff813e3000-0xffffffff813e5000 8K USR ro x pte 0xffffffff813e5000-0xffffffff813e8000 12K USR ro x pte 0xffffffff813e8000-0xffffffff813ea000 8K USR ro x pte 0xffffffff813ea000-0xffffffff813ec000 8K USR ro x pte 0xffffffff813ec000-0xffffffff813ed000 4K USR ro x pte 0xffffffff813ed000-0xffffffff813ef000 8K USR ro x pte 0xffffffff813ef000-0xffffffff813f3000 16K USR ro x pte 0xffffffff813f3000-0xffffffff813f4000 4K USR ro x pte 0xffffffff813f4000-0xffffffff813f6000 8K USR ro x pte 0xffffffff813f6000-0xffffffff813f7000 4K USR ro x pte 0xffffffff813f7000-0xffffffff813fa000 12K USR ro x pte 0xffffffff813fa000-0xffffffff813fb000 4K USR ro x pte 0xffffffff813fb000-0xffffffff813fd000 8K USR ro x pte 0xffffffff813fd000-0xffffffff813fe000 4K USR ro x pte 0xffffffff813fe000-0xffffffff81403000 20K USR ro x pte 0xffffffff81403000-0xffffffff81404000 4K USR ro x pte 0xffffffff81404000-0xffffffff81406000 8K USR ro x pte 0xffffffff81406000-0xffffffff81408000 8K USR ro x pte 0xffffffff81408000-0xffffffff81411000 36K USR ro x pte 0xffffffff81411000-0xffffffff81412000 4K USR ro x pte 0xffffffff81412000-0xffffffff81413000 4K USR ro x pte 0xffffffff81413000-0xffffffff81415000 8K USR ro x pte 0xffffffff81415000-0xffffffff81416000 4K USR ro x pte 0xffffffff81416000-0xffffffff81419000 12K USR ro x pte 0xffffffff81419000-0xffffffff8141e000 20K USR ro x pte 0xffffffff8141e000-0xffffffff81425000 28K USR ro x pte 0xffffffff81425000-0xffffffff81426000 4K USR ro x pte 0xffffffff81426000-0xffffffff81428000 8K USR ro x pte 0xffffffff81428000-0xffffffff8142f000 28K USR ro x pte 0xffffffff8142f000-0xffffffff81430000 4K USR ro x pte 0xffffffff81430000-0xffffffff81437000 28K USR ro x pte 0xffffffff81437000-0xffffffff81438000 4K USR ro x pte 0xffffffff81438000-0xffffffff81439000 4K USR ro x pte 0xffffffff81439000-0xffffffff8143d000 16K USR ro x pte 0xffffffff8143d000-0xffffffff8143e000 4K USR ro x pte 0xffffffff8143e000-0xffffffff8143f000 4K USR ro x pte 0xffffffff8143f000-0xffffffff81440000 4K USR ro x pte 0xffffffff81440000-0xffffffff81443000 12K USR ro x pte 0xffffffff81443000-0xffffffff81445000 8K USR ro x pte 0xffffffff81445000-0xffffffff81446000 4K USR ro x pte 0xffffffff81446000-0xffffffff81448000 8K USR ro x pte 0xffffffff81448000-0xffffffff8144d000 20K USR ro x pte 0xffffffff8144d000-0xffffffff8144f000 8K USR ro x pte 0xffffffff8144f000-0xffffffff81451000 8K USR ro x pte 0xffffffff81451000-0xffffffff81452000 4K USR ro x pte 0xffffffff81452000-0xffffffff81458000 24K USR ro x pte 0xffffffff81458000-0xffffffff81459000 4K USR ro x pte 0xffffffff81459000-0xffffffff8145a000 4K USR ro x pte 0xffffffff8145a000-0xffffffff8145c000 8K USR ro x pte 0xffffffff8145c000-0xffffffff8145d000 4K USR ro x pte 0xffffffff8145d000-0xffffffff81462000 20K USR ro x pte 0xffffffff81462000-0xffffffff81463000 4K USR ro x pte 0xffffffff81463000-0xffffffff81464000 4K USR ro x pte 0xffffffff81464000-0xffffffff81465000 4K USR ro x pte 0xffffffff81465000-0xffffffff81467000 8K USR ro x pte 0xffffffff81467000-0xffffffff81468000 4K USR ro x pte 0xffffffff81468000-0xffffffff81469000 4K USR ro x pte 0xffffffff81469000-0xffffffff8146a000 4K USR ro x pte 0xffffffff8146a000-0xffffffff8146b000 4K USR ro x pte 0xffffffff8146b000-0xffffffff81470000 20K USR ro x pte 0xffffffff81470000-0xffffffff81471000 4K USR ro x pte 0xffffffff81471000-0xffffffff81473000 8K USR ro x pte 0xffffffff81473000-0xffffffff81477000 16K USR ro x pte 0xffffffff81477000-0xffffffff8147a000 12K USR ro x pte 0xffffffff8147a000-0xffffffff8147b000 4K USR ro x pte 0xffffffff8147b000-0xffffffff8147c000 4K USR ro x pte 0xffffffff8147c000-0xffffffff8147d000 4K USR ro x pte 0xffffffff8147d000-0xffffffff81482000 20K USR ro x pte 0xffffffff81482000-0xffffffff81484000 8K USR ro x pte 0xffffffff81484000-0xffffffff81485000 4K USR ro x pte 0xffffffff81485000-0xffffffff81486000 4K USR ro x pte 0xffffffff81486000-0xffffffff81489000 12K USR ro x pte 0xffffffff81489000-0xffffffff8148a000 4K USR ro x pte 0xffffffff8148a000-0xffffffff8148b000 4K USR ro x pte 0xffffffff8148b000-0xffffffff8148c000 4K USR ro x pte 0xffffffff8148c000-0xffffffff81499000 52K USR ro x pte 0xffffffff81499000-0xffffffff8149a000 4K USR ro x pte 0xffffffff8149a000-0xffffffff814a2000 32K USR ro x pte 0xffffffff814a2000-0xffffffff814a5000 12K USR ro x pte 0xffffffff814a5000-0xffffffff814a8000 12K USR ro x pte 0xffffffff814a8000-0xffffffff814b0000 32K USR ro x pte 0xffffffff814b0000-0xffffffff814b1000 4K USR ro x pte 0xffffffff814b1000-0xffffffff814b2000 4K USR ro x pte 0xffffffff814b2000-0xffffffff814c2000 64K USR ro x pte 0xffffffff814c2000-0xffffffff814c3000 4K USR ro x pte 0xffffffff814c3000-0xffffffff814c5000 8K USR ro x pte 0xffffffff814c5000-0xffffffff814cb000 24K USR ro x pte 0xffffffff814cb000-0xffffffff814cc000 4K USR ro x pte 0xffffffff814cc000-0xffffffff814cf000 12K USR ro x pte 0xffffffff814cf000-0xffffffff814d0000 4K USR ro x pte 0xffffffff814d0000-0xffffffff814d1000 4K USR ro x pte 0xffffffff814d1000-0xffffffff814d3000 8K USR ro x pte 0xffffffff814d3000-0xffffffff814d4000 4K USR ro x pte 0xffffffff814d4000-0xffffffff814d6000 8K USR ro x pte 0xffffffff814d6000-0xffffffff814d7000 4K USR ro x pte 0xffffffff814d7000-0xffffffff814db000 16K USR ro x pte 0xffffffff814db000-0xffffffff814dc000 4K USR ro x pte 0xffffffff814dc000-0xffffffff814de000 8K USR ro x pte 0xffffffff814de000-0xffffffff814df000 4K USR ro x pte 0xffffffff814df000-0xffffffff814e3000 16K USR ro x pte 0xffffffff814e3000-0xffffffff814e7000 16K USR ro x pte 0xffffffff814e7000-0xffffffff814e8000 4K USR ro x pte 0xffffffff814e8000-0xffffffff814e9000 4K USR ro x pte 0xffffffff814e9000-0xffffffff814f1000 32K USR ro x pte 0xffffffff814f1000-0xffffffff814f2000 4K USR ro x pte 0xffffffff814f2000-0xffffffff814f6000 16K USR ro x pte 0xffffffff814f6000-0xffffffff814f7000 4K USR ro x pte 0xffffffff814f7000-0xffffffff814f8000 4K USR ro x pte 0xffffffff814f8000-0xffffffff814f9000 4K USR ro x pte 0xffffffff814f9000-0xffffffff814fe000 20K USR ro x pte 0xffffffff814fe000-0xffffffff81503000 20K USR ro x pte 0xffffffff81503000-0xffffffff81508000 20K USR ro x pte 0xffffffff81508000-0xffffffff8150d000 20K USR ro x pte 0xffffffff8150d000-0xffffffff81511000 16K USR ro x pte 0xffffffff81511000-0xffffffff81513000 8K USR ro x pte 0xffffffff81513000-0xffffffff81514000 4K USR ro x pte 0xffffffff81514000-0xffffffff81515000 4K USR ro x pte 0xffffffff81515000-0xffffffff81516000 4K USR ro x pte 0xffffffff81516000-0xffffffff8151b000 20K USR ro x pte 0xffffffff8151b000-0xffffffff81520000 20K USR ro x pte 0xffffffff81520000-0xffffffff81521000 4K USR ro x pte 0xffffffff81521000-0xffffffff81523000 8K USR ro x pte 0xffffffff81523000-0xffffffff81525000 8K USR ro x pte 0xffffffff81525000-0xffffffff81526000 4K USR ro x pte 0xffffffff81526000-0xffffffff81529000 12K USR ro x pte 0xffffffff81529000-0xffffffff8152a000 4K USR ro x pte 0xffffffff8152a000-0xffffffff8152b000 4K USR ro x pte 0xffffffff8152b000-0xffffffff8152e000 12K USR ro x pte 0xffffffff8152e000-0xffffffff81533000 20K USR ro x pte 0xffffffff81533000-0xffffffff81535000 8K USR ro x pte 0xffffffff81535000-0xffffffff81537000 8K USR ro x pte 0xffffffff81537000-0xffffffff81538000 4K USR ro x pte 0xffffffff81538000-0xffffffff81539000 4K USR ro x pte 0xffffffff81539000-0xffffffff8153b000 8K USR ro x pte 0xffffffff8153b000-0xffffffff8153d000 8K USR ro x pte 0xffffffff8153d000-0xffffffff81541000 16K USR ro x pte 0xffffffff81541000-0xffffffff81542000 4K USR ro x pte 0xffffffff81542000-0xffffffff81544000 8K USR ro x pte 0xffffffff81544000-0xffffffff81545000 4K USR ro x pte 0xffffffff81545000-0xffffffff81547000 8K USR ro x pte 0xffffffff81547000-0xffffffff81551000 40K USR ro x pte 0xffffffff81551000-0xffffffff81552000 4K USR ro x pte 0xffffffff81552000-0xffffffff81554000 8K USR ro x pte 0xffffffff81554000-0xffffffff81555000 4K USR ro x pte 0xffffffff81555000-0xffffffff8155d000 32K USR ro x pte 0xffffffff8155d000-0xffffffff8155f000 8K USR ro x pte 0xffffffff8155f000-0xffffffff81563000 16K USR ro x pte 0xffffffff81563000-0xffffffff81566000 12K USR ro x pte 0xffffffff81566000-0xffffffff81567000 4K USR ro x pte 0xffffffff81567000-0xffffffff81568000 4K USR ro x pte 0xffffffff81568000-0xffffffff8156a000 8K USR ro x pte 0xffffffff8156a000-0xffffffff8156b000 4K USR ro x pte 0xffffffff8156b000-0xffffffff81572000 28K USR ro x pte 0xffffffff81572000-0xffffffff81573000 4K USR ro x pte 0xffffffff81573000-0xffffffff81576000 12K USR ro x pte 0xffffffff81576000-0xffffffff81577000 4K USR ro x pte 0xffffffff81577000-0xffffffff81578000 4K USR ro x pte 0xffffffff81578000-0xffffffff81579000 4K USR ro x pte 0xffffffff81579000-0xffffffff8157a000 4K USR ro x pte 0xffffffff8157a000-0xffffffff8157b000 4K USR ro x pte 0xffffffff8157b000-0xffffffff8157d000 8K USR ro x pte 0xffffffff8157d000-0xffffffff8157f000 8K USR ro x pte 0xffffffff8157f000-0xffffffff81582000 12K USR ro x pte 0xffffffff81582000-0xffffffff81584000 8K USR ro x pte 0xffffffff81584000-0xffffffff81586000 8K USR ro x pte 0xffffffff81586000-0xffffffff81588000 8K USR ro x pte 0xffffffff81588000-0xffffffff81589000 4K USR ro x pte 0xffffffff81589000-0xffffffff8158d000 16K USR ro x pte 0xffffffff8158d000-0xffffffff8158f000 8K USR ro x pte 0xffffffff8158f000-0xffffffff81593000 16K USR ro x pte 0xffffffff81593000-0xffffffff81594000 4K USR ro x pte 0xffffffff81594000-0xffffffff81595000 4K USR ro x pte 0xffffffff81595000-0xffffffff81596000 4K USR ro x pte 0xffffffff81596000-0xffffffff81599000 12K USR ro x pte 0xffffffff81599000-0xffffffff815ab000 72K USR ro x pte 0xffffffff815ab000-0xffffffff815ac000 4K USR ro x pte 0xffffffff815ac000-0xffffffff815b0000 16K USR ro x pte 0xffffffff815b0000-0xffffffff815b1000 4K USR ro x pte 0xffffffff815b1000-0xffffffff815b7000 24K USR ro x pte 0xffffffff815b7000-0xffffffff81600000 292K USR RW NX pte 0xffffffff81600000-0xffffffff8179c000 1648K USR ro NX pte 0xffffffff8179c000-0xffffffff81800000 400K USR RW NX pte 0xffffffff81800000-0xffffffff81802000 8K USR RW x pte 0xffffffff81802000-0xffffffff81803000 4K USR RW x pte 0xffffffff81803000-0xffffffff81805000 8K USR RW x pte 0xffffffff81805000-0xffffffff8180b000 24K USR RW x pte 0xffffffff8180b000-0xffffffff8180f000 16K USR ro x pte 0xffffffff8180f000-0xffffffff81810000 4K USR RW x pte 0xffffffff81810000-0xffffffff81812000 8K USR ro x pte 0xffffffff81812000-0xffffffff81813000 4K USR RW x pte 0xffffffff81813000-0xffffffff81815000 8K USR RW x pte 0xffffffff81815000-0xffffffff81816000 4K USR RW x pte 0xffffffff81816000-0xffffffff81818000 8K USR RW x pte 0xffffffff81818000-0xffffffff8181a000 8K USR RW x pte 0xffffffff8181a000-0xffffffff8181d000 12K USR RW x pte 0xffffffff8181d000-0xffffffff8181e000 4K USR RW x pte 0xffffffff8181e000-0xffffffff81832000 80K USR RW x pte 0xffffffff81832000-0xffffffff81834000 8K USR RW x pte 0xffffffff81834000-0xffffffff8183a000 24K USR RW x pte 0xffffffff8183a000-0xffffffff8183d000 12K USR RW x pte 0xffffffff8183d000-0xffffffff81841000 16K USR RW x pte 0xffffffff81841000-0xffffffff81843000 8K USR RW x pte 0xffffffff81843000-0xffffffff81845000 8K USR RW x pte 0xffffffff81845000-0xffffffff81846000 4K USR RW x pte 0xffffffff81846000-0xffffffff81849000 12K USR RW x pte 0xffffffff81849000-0xffffffff8184a000 4K USR RW x pte 0xffffffff8184a000-0xffffffff8184f000 20K USR RW x pte 0xffffffff8184f000-0xffffffff81850000 4K USR RW x pte 0xffffffff81850000-0xffffffff81885000 212K USR RW x pte 0xffffffff81885000-0xffffffff81938000 716K USR RW NX pte 0xffffffff81938000-0xffffffff8193a000 8K USR RW x pte 0xffffffff8193a000-0xffffffff8193b000 4K USR ro x pte 0xffffffff8193b000-0xffffffff8193d000 8K USR RW x pte 0xffffffff8193d000-0xffffffff8193e000 4K USR ro x pte 0xffffffff8193e000-0xffffffff81948000 40K USR RW x pte 0xffffffff81948000-0xffffffff8194a000 8K USR RW x pte 0xffffffff8194a000-0xffffffff8194c000 8K USR RW x pte 0xffffffff8194c000-0xffffffff8196c000 128K USR RW x pte 0xffffffff8196c000-0xffffffff8196d000 4K USR RW x pte 0xffffffff8196d000-0xffffffff81970000 12K USR RW x pte 0xffffffff81970000-0xffffffff81971000 4K USR RW x pte 0xffffffff81971000-0xffffffff81972000 4K USR RW x pte 0xffffffff81972000-0xffffffff81973000 4K USR RW x pte 0xffffffff81973000-0xffffffff81975000 8K USR RW x pte 0xffffffff81975000-0xffffffff81976000 4K USR RW x pte 0xffffffff81976000-0xffffffff81977000 4K USR RW x pte 0xffffffff81977000-0xffffffff8197b000 16K USR RW x pte 0xffffffff8197b000-0xffffffff819b9000 248K USR RW x pte 0xffffffff819b9000-0xffffffff819c0000 28K USR RW x pte 0xffffffff819c0000-0xffffffff819df000 124K USR RW x pte 0xffffffff819df000-0xffffffff819e8000 36K USR RW x pte 0xffffffff819e8000-0xffffffff819f1000 36K USR RW x pte 0xffffffff819f1000-0xffffffff819f2000 4K USR RW x pte 0xffffffff819f2000-0xffffffff819f3000 4K USR RW x pte 0xffffffff819f3000-0xffffffff819f5000 8K USR RW x pte 0xffffffff819f5000-0xffffffff819f8000 12K USR RW x pte 0xffffffff819f8000-0xffffffff81a0a000 72K USR RW x pte 0xffffffff81a0a000-0xffffffff81a0f000 20K USR RW x pte 0xffffffff81a0f000-0xffffffff81a1c000 52K USR RW x pte 0xffffffff81a1c000-0xffffffff81a1d000 4K USR RW x pte 0xffffffff81a1d000-0xffffffff81aaa000 564K USR RW x pte 0xffffffff81aaa000-0xffffffff81aae000 16K USR ro x pte 0xffffffff81aae000-0xffffffff81b34000 536K USR RW x pte 0xffffffff81b34000-0xffffffff81c00000 816K USR RW x pte 0xffffffff81c00000-0xffffffff8fc00000 224M pmd 0xffffffff8fc00000-0xffffffff8fc93000 588K USR RW NX pte 0xffffffff8fc93000-0xffffffffa0000000 265652K USR RW x pte ---[ Modules ]--- 0xffffffffa0000000-0xffffffffa0001000 4K USR ro x pte 0xffffffffa0001000-0xffffffffa0002000 4K USR ro NX pte 0xffffffffa0002000-0xffffffffa0004000 8K USR RW NX pte 0xffffffffa0004000-0xffffffffa0008000 16K pte 0xffffffffa0008000-0xffffffffa0009000 4K USR ro x pte 0xffffffffa0009000-0xffffffffa000a000 4K USR ro NX pte 0xffffffffa000a000-0xffffffffa000c000 8K USR RW NX pte 0xffffffffa000c000-0xffffffffa0070000 400K pte 0xffffffffa0070000-0xffffffffa024c000 1904K USR RW x pte 0xffffffffa024c000-0xffffffffa024e000 8K USR RW x pte 0xffffffffa024e000-0xffffffffa0353000 1044K USR ro x pte 0xffffffffa0353000-0xffffffffa0400000 692K USR RW x pte 0xffffffffa0400000-0xffffffffc0000000 508M pmd 0xffffffffc0000000-0xffffffffc009b000 620K USR RW x pte 0xffffffffc009b000-0xffffffffc00a0000 20K USR RW x pte 0xffffffffc00a0000-0xffffffffc07fb000 7532K USR RW x pte 0xffffffffc07fb000-0xffffffffc0ef8000 7156K USR ro x pte 0xffffffffc0ef8000-0xffffffffc1000000 1056K USR RW x pte 0xffffffffc1000000-0xffffffffc1002000 8K USR ro x pte 0xffffffffc1002000-0xffffffffc1013000 68K USR ro x pte 0xffffffffc1013000-0xffffffffc1015000 8K USR ro x pte 0xffffffffc1015000-0xffffffffc1017000 8K USR ro x pte 0xffffffffc1017000-0xffffffffc1019000 8K USR ro x pte 0xffffffffc1019000-0xffffffffc101a000 4K USR ro x pte 0xffffffffc101a000-0xffffffffc101b000 4K USR ro x pte 0xffffffffc101b000-0xffffffffc101f000 16K USR ro x pte 0xffffffffc101f000-0xffffffffc1028000 36K USR ro x pte 0xffffffffc1028000-0xffffffffc102a000 8K USR ro x pte 0xffffffffc102a000-0xffffffffc102c000 8K USR ro x pte 0xffffffffc102c000-0xffffffffc103c000 64K USR ro x pte 0xffffffffc103c000-0xffffffffc103d000 4K USR ro x pte 0xffffffffc103d000-0xffffffffc1051000 80K USR ro x pte 0xffffffffc1051000-0xffffffffc1052000 4K USR ro x pte 0xffffffffc1052000-0xffffffffc1057000 20K USR ro x pte 0xffffffffc1057000-0xffffffffc1058000 4K USR ro x pte 0xffffffffc1058000-0xffffffffc1061000 36K USR ro x pte 0xffffffffc1061000-0xffffffffc1063000 8K USR ro x pte 0xffffffffc1063000-0xffffffffc106b000 32K USR ro x pte 0xffffffffc106b000-0xffffffffc106c000 4K USR ro x pte 0xffffffffc106c000-0xffffffffc1078000 48K USR ro x pte 0xffffffffc1078000-0xffffffffc107a000 8K USR ro x pte 0xffffffffc107a000-0xffffffffc1083000 36K USR ro x pte 0xffffffffc1083000-0xffffffffc1084000 4K USR ro x pte 0xffffffffc1084000-0xffffffffc108f000 44K USR ro x pte 0xffffffffc108f000-0xffffffffc1090000 4K USR ro x pte 0xffffffffc1090000-0xffffffffc1094000 16K USR ro x pte 0xffffffffc1094000-0xffffffffc1097000 12K USR ro x pte 0xffffffffc1097000-0xffffffffc10a0000 36K USR ro x pte 0xffffffffc10a0000-0xffffffffc10a2000 8K USR ro x pte 0xffffffffc10a2000-0xffffffffc10a7000 20K USR ro x pte 0xffffffffc10a7000-0xffffffffc10a8000 4K USR ro x pte 0xffffffffc10a8000-0xffffffffc10aa000 8K USR ro x pte 0xffffffffc10aa000-0xffffffffc10af000 20K USR ro x pte 0xffffffffc10af000-0xffffffffc10b4000 20K USR ro x pte 0xffffffffc10b4000-0xffffffffc10b6000 8K USR ro x pte 0xffffffffc10b6000-0xffffffffc10c0000 40K USR ro x pte 0xffffffffc10c0000-0xffffffffc10c4000 16K USR ro x pte 0xffffffffc10c4000-0xffffffffc10c6000 8K USR ro x pte 0xffffffffc10c6000-0xffffffffc10ca000 16K USR ro x pte 0xffffffffc10ca000-0xffffffffc10cc000 8K USR ro x pte 0xffffffffc10cc000-0xffffffffc10cd000 4K USR ro x pte 0xffffffffc10cd000-0xffffffffc10d5000 32K USR ro x pte 0xffffffffc10d5000-0xffffffffc10d9000 16K USR ro x pte 0xffffffffc10d9000-0xffffffffc10da000 4K USR ro x pte 0xffffffffc10da000-0xffffffffc10db000 4K USR ro x pte 0xffffffffc10db000-0xffffffffc10dc000 4K USR ro x pte 0xffffffffc10dc000-0xffffffffc10dd000 4K USR ro x pte 0xffffffffc10dd000-0xffffffffc10e2000 20K USR ro x pte 0xffffffffc10e2000-0xffffffffc10e3000 4K USR ro x pte 0xffffffffc10e3000-0xffffffffc10f8000 84K USR ro x pte 0xffffffffc10f8000-0xffffffffc10fb000 12K USR ro x pte 0xffffffffc10fb000-0xffffffffc1101000 24K USR ro x pte 0xffffffffc1101000-0xffffffffc1102000 4K USR ro x pte 0xffffffffc1102000-0xffffffffc1106000 16K USR ro x pte 0xffffffffc1106000-0xffffffffc1107000 4K USR ro x pte 0xffffffffc1107000-0xffffffffc1108000 4K USR ro x pte 0xffffffffc1108000-0xffffffffc1109000 4K USR ro x pte 0xffffffffc1109000-0xffffffffc1113000 40K USR ro x pte 0xffffffffc1113000-0xffffffffc1114000 4K USR ro x pte 0xffffffffc1114000-0xffffffffc1117000 12K USR ro x pte 0xffffffffc1117000-0xffffffffc1118000 4K USR ro x pte 0xffffffffc1118000-0xffffffffc1122000 40K USR ro x pte 0xffffffffc1122000-0xffffffffc1124000 8K USR ro x pte 0xffffffffc1124000-0xffffffffc1143000 124K USR ro x pte 0xffffffffc1143000-0xffffffffc1145000 8K USR ro x pte 0xffffffffc1145000-0xffffffffc1166000 132K USR ro x pte 0xffffffffc1166000-0xffffffffc1168000 8K USR ro x pte 0xffffffffc1168000-0xffffffffc116d000 20K USR ro x pte 0xffffffffc116d000-0xffffffffc116e000 4K USR ro x pte 0xffffffffc116e000-0xffffffffc116f000 4K USR ro x pte 0xffffffffc116f000-0xffffffffc1170000 4K USR ro x pte 0xffffffffc1170000-0xffffffffc1174000 16K USR ro x pte 0xffffffffc1174000-0xffffffffc1177000 12K USR ro x pte 0xffffffffc1177000-0xffffffffc117a000 12K USR ro x pte 0xffffffffc117a000-0xffffffffc117e000 16K USR ro x pte 0xffffffffc117e000-0xffffffffc118d000 60K USR ro x pte 0xffffffffc118d000-0xffffffffc118e000 4K USR ro x pte 0xffffffffc118e000-0xffffffffc1190000 8K USR ro x pte 0xffffffffc1190000-0xffffffffc1191000 4K USR ro x pte 0xffffffffc1191000-0xffffffffc1192000 4K USR ro x pte 0xffffffffc1192000-0xffffffffc1193000 4K USR ro x pte 0xffffffffc1193000-0xffffffffc1194000 4K USR ro x pte 0xffffffffc1194000-0xffffffffc1197000 12K USR ro x pte 0xffffffffc1197000-0xffffffffc1198000 4K USR ro x pte 0xffffffffc1198000-0xffffffffc1199000 4K USR ro x pte 0xffffffffc1199000-0xffffffffc11a0000 28K USR ro x pte 0xffffffffc11a0000-0xffffffffc11a1000 4K USR ro x pte 0xffffffffc11a1000-0xffffffffc11ab000 40K USR ro x pte 0xffffffffc11ab000-0xffffffffc11ac000 4K USR ro x pte 0xffffffffc11ac000-0xffffffffc11af000 12K USR ro x pte 0xffffffffc11af000-0xffffffffc11b1000 8K USR ro x pte 0xffffffffc11b1000-0xffffffffc11b4000 12K USR ro x pte 0xffffffffc11b4000-0xffffffffc11b5000 4K USR ro x pte 0xffffffffc11b5000-0xffffffffc11b9000 16K USR ro x pte 0xffffffffc11b9000-0xffffffffc11bb000 8K USR ro x pte 0xffffffffc11bb000-0xffffffffc11bd000 8K USR ro x pte 0xffffffffc11bd000-0xffffffffc11be000 4K USR ro x pte 0xffffffffc11be000-0xffffffffc11c2000 16K USR ro x pte 0xffffffffc11c2000-0xffffffffc11c6000 16K USR ro x pte 0xffffffffc11c6000-0xffffffffc11c7000 4K USR ro x pte 0xffffffffc11c7000-0xffffffffc11c8000 4K USR ro x pte 0xffffffffc11c8000-0xffffffffc11c9000 4K USR ro x pte 0xffffffffc11c9000-0xffffffffc11ca000 4K USR ro x pte 0xffffffffc11ca000-0xffffffffc11cf000 20K USR ro x pte 0xffffffffc11cf000-0xffffffffc11d0000 4K USR ro x pte 0xffffffffc11d0000-0xffffffffc11d3000 12K USR ro x pte 0xffffffffc11d3000-0xffffffffc11d5000 8K USR ro x pte 0xffffffffc11d5000-0xffffffffc11d6000 4K USR ro x pte 0xffffffffc11d6000-0xffffffffc11d8000 8K USR ro x pte 0xffffffffc11d8000-0xffffffffc11d9000 4K USR ro x pte 0xffffffffc11d9000-0xffffffffc11da000 4K USR ro x pte 0xffffffffc11da000-0xffffffffc11e0000 24K USR ro x pte 0xffffffffc11e0000-0xffffffffc11e3000 12K USR ro x pte 0xffffffffc11e3000-0xffffffffc11e9000 24K USR ro x pte 0xffffffffc11e9000-0xffffffffc11ea000 4K USR ro x pte 0xffffffffc11ea000-0xffffffffc11eb000 4K USR ro x pte 0xffffffffc11eb000-0xffffffffc11f1000 24K USR ro x pte 0xffffffffc11f1000-0xffffffffc11f7000 24K USR ro x pte 0xffffffffc11f7000-0xffffffffc11f8000 4K USR ro x pte 0xffffffffc11f8000-0xffffffffc11fa000 8K USR ro x pte 0xffffffffc11fa000-0xffffffffc11fb000 4K USR ro x pte 0xffffffffc11fb000-0xffffffffc11fd000 8K USR ro x pte 0xffffffffc11fd000-0xffffffffc11fe000 4K USR ro x pte 0xffffffffc11fe000-0xffffffffc1200000 8K USR ro x pte 0xffffffffc1200000-0xffffffffc1201000 4K USR ro x pte 0xffffffffc1201000-0xffffffffc1203000 8K USR ro x pte 0xffffffffc1203000-0xffffffffc1207000 16K USR ro x pte 0xffffffffc1207000-0xffffffffc1209000 8K USR ro x pte 0xffffffffc1209000-0xffffffffc120a000 4K USR ro x pte 0xffffffffc120a000-0xffffffffc120b000 4K USR ro x pte 0xffffffffc120b000-0xffffffffc120c000 4K USR ro x pte 0xffffffffc120c000-0xffffffffc120e000 8K USR ro x pte 0xffffffffc120e000-0xffffffffc1223000 84K USR ro x pte 0xffffffffc1223000-0xffffffffc1228000 20K USR ro x pte 0xffffffffc1228000-0xffffffffc1229000 4K USR ro x pte 0xffffffffc1229000-0xffffffffc123b000 72K USR ro x pte 0xffffffffc123b000-0xffffffffc123d000 8K USR ro x pte 0xffffffffc123d000-0xffffffffc123e000 4K USR ro x pte 0xffffffffc123e000-0xffffffffc123f000 4K USR ro x pte 0xffffffffc123f000-0xffffffffc1242000 12K USR ro x pte 0xffffffffc1242000-0xffffffffc1244000 8K USR ro x pte 0xffffffffc1244000-0xffffffffc1245000 4K USR ro x pte 0xffffffffc1245000-0xffffffffc1247000 8K USR ro x pte 0xffffffffc1247000-0xffffffffc1248000 4K USR ro x pte 0xffffffffc1248000-0xffffffffc1252000 40K USR ro x pte 0xffffffffc1252000-0xffffffffc1253000 4K USR ro x pte 0xffffffffc1253000-0xffffffffc1254000 4K USR ro x pte 0xffffffffc1254000-0xffffffffc1255000 4K USR ro x pte 0xffffffffc1255000-0xffffffffc1258000 12K USR ro x pte 0xffffffffc1258000-0xffffffffc1259000 4K USR ro x pte 0xffffffffc1259000-0xffffffffc1268000 60K USR ro x pte 0xffffffffc1268000-0xffffffffc126e000 24K USR ro x pte 0xffffffffc126e000-0xffffffffc126f000 4K USR ro x pte 0xffffffffc126f000-0xffffffffc1272000 12K USR ro x pte 0xffffffffc1272000-0xffffffffc1273000 4K USR ro x pte 0xffffffffc1273000-0xffffffffc1274000 4K USR ro x pte 0xffffffffc1274000-0xffffffffc127a000 24K USR ro x pte 0xffffffffc127a000-0xffffffffc127c000 8K USR ro x pte 0xffffffffc127c000-0xffffffffc127d000 4K USR ro x pte 0xffffffffc127d000-0xffffffffc1285000 32K USR ro x pte 0xffffffffc1285000-0xffffffffc1286000 4K USR ro x pte 0xffffffffc1286000-0xffffffffc1287000 4K USR ro x pte 0xffffffffc1287000-0xffffffffc1288000 4K USR ro x pte 0xffffffffc1288000-0xffffffffc1289000 4K USR ro x pte 0xffffffffc1289000-0xffffffffc128d000 16K USR ro x pte 0xffffffffc128d000-0xffffffffc128f000 8K USR ro x pte 0xffffffffc128f000-0xffffffffc1291000 8K USR ro x pte 0xffffffffc1291000-0xffffffffc1292000 4K USR ro x pte 0xffffffffc1292000-0xffffffffc129f000 52K USR ro x pte 0xffffffffc129f000-0xffffffffc12a0000 4K USR ro x pte 0xffffffffc12a0000-0xffffffffc12a1000 4K USR ro x pte 0xffffffffc12a1000-0xffffffffc12a3000 8K USR ro x pte 0xffffffffc12a3000-0xffffffffc12a5000 8K USR ro x pte 0xffffffffc12a5000-0xffffffffc12a6000 4K USR ro x pte 0xffffffffc12a6000-0xffffffffc12a9000 12K USR ro x pte 0xffffffffc12a9000-0xffffffffc12ab000 8K USR ro x pte 0xffffffffc12ab000-0xffffffffc12c3000 96K USR ro x pte 0xffffffffc12c3000-0xffffffffc12c6000 12K USR ro x pte 0xffffffffc12c6000-0xffffffffc12cc000 24K USR ro x pte 0xffffffffc12cc000-0xffffffffc12cf000 12K USR ro x pte 0xffffffffc12cf000-0xffffffffc12d1000 8K USR ro x pte 0xffffffffc12d1000-0xffffffffc12d2000 4K USR ro x pte 0xffffffffc12d2000-0xffffffffc12d3000 4K USR ro x pte 0xffffffffc12d3000-0xffffffffc12d7000 16K USR ro x pte 0xffffffffc12d7000-0xffffffffc12d8000 4K USR ro x pte 0xffffffffc12d8000-0xffffffffc12da000 8K USR ro x pte 0xffffffffc12da000-0xffffffffc12dc000 8K USR ro x pte 0xffffffffc12dc000-0xffffffffc12e1000 20K USR ro x pte 0xffffffffc12e1000-0xffffffffc12e3000 8K USR ro x pte 0xffffffffc12e3000-0xffffffffc12e4000 4K USR ro x pte 0xffffffffc12e4000-0xffffffffc12e5000 4K USR ro x pte 0xffffffffc12e5000-0xffffffffc12e6000 4K USR ro x pte 0xffffffffc12e6000-0xffffffffc12e7000 4K USR ro x pte 0xffffffffc12e7000-0xffffffffc12ed000 24K USR ro x pte 0xffffffffc12ed000-0xffffffffc12ee000 4K USR ro x pte 0xffffffffc12ee000-0xffffffffc12f9000 44K USR ro x pte 0xffffffffc12f9000-0xffffffffc12fa000 4K USR ro x pte 0xffffffffc12fa000-0xffffffffc12fe000 16K USR ro x pte 0xffffffffc12fe000-0xffffffffc1300000 8K USR ro x pte 0xffffffffc1300000-0xffffffffc1302000 8K USR ro x pte 0xffffffffc1302000-0xffffffffc130d000 44K USR ro x pte 0xffffffffc130d000-0xffffffffc130e000 4K USR ro x pte 0xffffffffc130e000-0xffffffffc130f000 4K USR ro x pte 0xffffffffc130f000-0xffffffffc1312000 12K USR ro x pte 0xffffffffc1312000-0xffffffffc1314000 8K USR ro x pte 0xffffffffc1314000-0xffffffffc1318000 16K USR ro x pte 0xffffffffc1318000-0xffffffffc131b000 12K USR ro x pte 0xffffffffc131b000-0xffffffffc131c000 4K USR ro x pte 0xffffffffc131c000-0xffffffffc1324000 32K USR ro x pte 0xffffffffc1324000-0xffffffffc1329000 20K USR ro x pte 0xffffffffc1329000-0xffffffffc132d000 16K USR ro x pte 0xffffffffc132d000-0xffffffffc132e000 4K USR ro x pte 0xffffffffc132e000-0xffffffffc132f000 4K USR ro x pte 0xffffffffc132f000-0xffffffffc1332000 12K USR ro x pte 0xffffffffc1332000-0xffffffffc1333000 4K USR ro x pte 0xffffffffc1333000-0xffffffffc1334000 4K USR ro x pte 0xffffffffc1334000-0xffffffffc1335000 4K USR ro x pte 0xffffffffc1335000-0xffffffffc1337000 8K USR ro x pte 0xffffffffc1337000-0xffffffffc133b000 16K USR ro x pte 0xffffffffc133b000-0xffffffffc133c000 4K USR ro x pte 0xffffffffc133c000-0xffffffffc1340000 16K USR ro x pte 0xffffffffc1340000-0xffffffffc1342000 8K USR ro x pte 0xffffffffc1342000-0xffffffffc1343000 4K USR ro x pte 0xffffffffc1343000-0xffffffffc1348000 20K USR ro x pte 0xffffffffc1348000-0xffffffffc134c000 16K USR ro x pte 0xffffffffc134c000-0xffffffffc1350000 16K USR ro x pte 0xffffffffc1350000-0xffffffffc1351000 4K USR ro x pte 0xffffffffc1351000-0xffffffffc1353000 8K USR ro x pte 0xffffffffc1353000-0xffffffffc1358000 20K USR ro x pte 0xffffffffc1358000-0xffffffffc135e000 24K USR ro x pte 0xffffffffc135e000-0xffffffffc135f000 4K USR ro x pte 0xffffffffc135f000-0xffffffffc1361000 8K USR ro x pte 0xffffffffc1361000-0xffffffffc1366000 20K USR ro x pte 0xffffffffc1366000-0xffffffffc1367000 4K USR ro x pte 0xffffffffc1367000-0xffffffffc1368000 4K USR ro x pte 0xffffffffc1368000-0xffffffffc136a000 8K USR ro x pte 0xffffffffc136a000-0xffffffffc1374000 40K USR ro x pte 0xffffffffc1374000-0xffffffffc1376000 8K USR ro x pte 0xffffffffc1376000-0xffffffffc1379000 12K USR ro x pte 0xffffffffc1379000-0xffffffffc137f000 24K USR ro x pte 0xffffffffc137f000-0xffffffffc1380000 4K USR ro x pte 0xffffffffc1380000-0xffffffffc1383000 12K USR ro x pte 0xffffffffc1383000-0xffffffffc1384000 4K USR ro x pte 0xffffffffc1384000-0xffffffffc1387000 12K USR ro x pte 0xffffffffc1387000-0xffffffffc1389000 8K USR ro x pte 0xffffffffc1389000-0xffffffffc138c000 12K USR ro x pte 0xffffffffc138c000-0xffffffffc1393000 28K USR ro x pte 0xffffffffc1393000-0xffffffffc1395000 8K USR ro x pte 0xffffffffc1395000-0xffffffffc1398000 12K USR ro x pte 0xffffffffc1398000-0xffffffffc139a000 8K USR ro x pte 0xffffffffc139a000-0xffffffffc139c000 8K USR ro x pte 0xffffffffc139c000-0xffffffffc139d000 4K USR ro x pte 0xffffffffc139d000-0xffffffffc13a3000 24K USR ro x pte 0xffffffffc13a3000-0xffffffffc13a4000 4K USR ro x pte 0xffffffffc13a4000-0xffffffffc13a5000 4K USR ro x pte 0xffffffffc13a5000-0xffffffffc13a6000 4K USR ro x pte 0xffffffffc13a6000-0xffffffffc13a9000 12K USR ro x pte 0xffffffffc13a9000-0xffffffffc13ab000 8K USR ro x pte 0xffffffffc13ab000-0xffffffffc13ac000 4K USR ro x pte 0xffffffffc13ac000-0xffffffffc13ae000 8K USR ro x pte 0xffffffffc13ae000-0xffffffffc13b1000 12K USR ro x pte 0xffffffffc13b1000-0xffffffffc13b3000 8K USR ro x pte 0xffffffffc13b3000-0xffffffffc13b5000 8K USR ro x pte 0xffffffffc13b5000-0xffffffffc13b9000 16K USR ro x pte 0xffffffffc13b9000-0xffffffffc13ba000 4K USR ro x pte 0xffffffffc13ba000-0xffffffffc13bf000 20K USR ro x pte 0xffffffffc13bf000-0xffffffffc13ce000 60K USR ro x pte 0xffffffffc13ce000-0xffffffffc13cf000 4K USR ro x pte 0xffffffffc13cf000-0xffffffffc13d0000 4K USR ro x pte 0xffffffffc13d0000-0xffffffffc13d2000 8K USR ro x pte 0xffffffffc13d2000-0xffffffffc13d3000 4K USR ro x pte 0xffffffffc13d3000-0xffffffffc13db000 32K USR ro x pte 0xffffffffc13db000-0xffffffffc13dc000 4K USR ro x pte 0xffffffffc13dc000-0xffffffffc13dd000 4K USR ro x pte 0xffffffffc13dd000-0xffffffffc13de000 4K USR ro x pte 0xffffffffc13de000-0xffffffffc13e0000 8K USR ro x pte 0xffffffffc13e0000-0xffffffffc13e3000 12K USR ro x pte 0xffffffffc13e3000-0xffffffffc13e5000 8K USR ro x pte 0xffffffffc13e5000-0xffffffffc13e8000 12K USR ro x pte 0xffffffffc13e8000-0xffffffffc13ea000 8K USR ro x pte 0xffffffffc13ea000-0xffffffffc13ec000 8K USR ro x pte 0xffffffffc13ec000-0xffffffffc13ed000 4K USR ro x pte 0xffffffffc13ed000-0xffffffffc13ef000 8K USR ro x pte 0xffffffffc13ef000-0xffffffffc13f3000 16K USR ro x pte 0xffffffffc13f3000-0xffffffffc13f4000 4K USR ro x pte 0xffffffffc13f4000-0xffffffffc13f6000 8K USR ro x pte 0xffffffffc13f6000-0xffffffffc13f7000 4K USR ro x pte 0xffffffffc13f7000-0xffffffffc13fa000 12K USR ro x pte 0xffffffffc13fa000-0xffffffffc13fb000 4K USR ro x pte 0xffffffffc13fb000-0xffffffffc13fd000 8K USR ro x pte 0xffffffffc13fd000-0xffffffffc13fe000 4K USR ro x pte 0xffffffffc13fe000-0xffffffffc1403000 20K USR ro x pte 0xffffffffc1403000-0xffffffffc1404000 4K USR ro x pte 0xffffffffc1404000-0xffffffffc1406000 8K USR ro x pte 0xffffffffc1406000-0xffffffffc1408000 8K USR ro x pte 0xffffffffc1408000-0xffffffffc1411000 36K USR ro x pte 0xffffffffc1411000-0xffffffffc1412000 4K USR ro x pte 0xffffffffc1412000-0xffffffffc1413000 4K USR ro x pte 0xffffffffc1413000-0xffffffffc1415000 8K USR ro x pte 0xffffffffc1415000-0xffffffffc1416000 4K USR ro x pte 0xffffffffc1416000-0xffffffffc1419000 12K USR ro x pte 0xffffffffc1419000-0xffffffffc141e000 20K USR ro x pte 0xffffffffc141e000-0xffffffffc1425000 28K USR ro x pte 0xffffffffc1425000-0xffffffffc1426000 4K USR ro x pte 0xffffffffc1426000-0xffffffffc1428000 8K USR ro x pte 0xffffffffc1428000-0xffffffffc142f000 28K USR ro x pte 0xffffffffc142f000-0xffffffffc1430000 4K USR ro x pte 0xffffffffc1430000-0xffffffffc1437000 28K USR ro x pte 0xffffffffc1437000-0xffffffffc1438000 4K USR ro x pte 0xffffffffc1438000-0xffffffffc1439000 4K USR ro x pte 0xffffffffc1439000-0xffffffffc143d000 16K USR ro x pte 0xffffffffc143d000-0xffffffffc143e000 4K USR ro x pte 0xffffffffc143e000-0xffffffffc143f000 4K USR ro x pte 0xffffffffc143f000-0xffffffffc1440000 4K USR ro x pte 0xffffffffc1440000-0xffffffffc1443000 12K USR ro x pte 0xffffffffc1443000-0xffffffffc1445000 8K USR ro x pte 0xffffffffc1445000-0xffffffffc1446000 4K USR ro x pte 0xffffffffc1446000-0xffffffffc1448000 8K USR ro x pte 0xffffffffc1448000-0xffffffffc144d000 20K USR ro x pte 0xffffffffc144d000-0xffffffffc144f000 8K USR ro x pte 0xffffffffc144f000-0xffffffffc1451000 8K USR ro x pte 0xffffffffc1451000-0xffffffffc1452000 4K USR ro x pte 0xffffffffc1452000-0xffffffffc1458000 24K USR ro x pte 0xffffffffc1458000-0xffffffffc1459000 4K USR ro x pte 0xffffffffc1459000-0xffffffffc145a000 4K USR ro x pte 0xffffffffc145a000-0xffffffffc145c000 8K USR ro x pte 0xffffffffc145c000-0xffffffffc145d000 4K USR ro x pte 0xffffffffc145d000-0xffffffffc1462000 20K USR ro x pte 0xffffffffc1462000-0xffffffffc1463000 4K USR ro x pte 0xffffffffc1463000-0xffffffffc1464000 4K USR ro x pte 0xffffffffc1464000-0xffffffffc1465000 4K USR ro x pte 0xffffffffc1465000-0xffffffffc1467000 8K USR ro x pte 0xffffffffc1467000-0xffffffffc1468000 4K USR ro x pte 0xffffffffc1468000-0xffffffffc1469000 4K USR ro x pte 0xffffffffc1469000-0xffffffffc146a000 4K USR ro x pte 0xffffffffc146a000-0xffffffffc146b000 4K USR ro x pte 0xffffffffc146b000-0xffffffffc1470000 20K USR ro x pte 0xffffffffc1470000-0xffffffffc1471000 4K USR ro x pte 0xffffffffc1471000-0xffffffffc1473000 8K USR ro x pte 0xffffffffc1473000-0xffffffffc1477000 16K USR ro x pte 0xffffffffc1477000-0xffffffffc147a000 12K USR ro x pte 0xffffffffc147a000-0xffffffffc147b000 4K USR ro x pte 0xffffffffc147b000-0xffffffffc147c000 4K USR ro x pte 0xffffffffc147c000-0xffffffffc147d000 4K USR ro x pte 0xffffffffc147d000-0xffffffffc1482000 20K USR ro x pte 0xffffffffc1482000-0xffffffffc1484000 8K USR ro x pte 0xffffffffc1484000-0xffffffffc1485000 4K USR ro x pte 0xffffffffc1485000-0xffffffffc1486000 4K USR ro x pte 0xffffffffc1486000-0xffffffffc1489000 12K USR ro x pte 0xffffffffc1489000-0xffffffffc148a000 4K USR ro x pte 0xffffffffc148a000-0xffffffffc148b000 4K USR ro x pte 0xffffffffc148b000-0xffffffffc148c000 4K USR ro x pte 0xffffffffc148c000-0xffffffffc1499000 52K USR ro x pte 0xffffffffc1499000-0xffffffffc149a000 4K USR ro x pte 0xffffffffc149a000-0xffffffffc14a2000 32K USR ro x pte 0xffffffffc14a2000-0xffffffffc14a5000 12K USR ro x pte 0xffffffffc14a5000-0xffffffffc14a8000 12K USR ro x pte 0xffffffffc14a8000-0xffffffffc14b0000 32K USR ro x pte 0xffffffffc14b0000-0xffffffffc14b1000 4K USR ro x pte 0xffffffffc14b1000-0xffffffffc14b2000 4K USR ro x pte 0xffffffffc14b2000-0xffffffffc14c2000 64K USR ro x pte 0xffffffffc14c2000-0xffffffffc14c3000 4K USR ro x pte 0xffffffffc14c3000-0xffffffffc14c5000 8K USR ro x pte 0xffffffffc14c5000-0xffffffffc14cb000 24K USR ro x pte 0xffffffffc14cb000-0xffffffffc14cc000 4K USR ro x pte 0xffffffffc14cc000-0xffffffffc14cf000 12K USR ro x pte 0xffffffffc14cf000-0xffffffffc14d0000 4K USR ro x pte 0xffffffffc14d0000-0xffffffffc14d1000 4K USR ro x pte 0xffffffffc14d1000-0xffffffffc14d3000 8K USR ro x pte 0xffffffffc14d3000-0xffffffffc14d4000 4K USR ro x pte 0xffffffffc14d4000-0xffffffffc14d6000 8K USR ro x pte 0xffffffffc14d6000-0xffffffffc14d7000 4K USR ro x pte 0xffffffffc14d7000-0xffffffffc14db000 16K USR ro x pte 0xffffffffc14db000-0xffffffffc14dc000 4K USR ro x pte 0xffffffffc14dc000-0xffffffffc14de000 8K USR ro x pte 0xffffffffc14de000-0xffffffffc14df000 4K USR ro x pte 0xffffffffc14df000-0xffffffffc14e3000 16K USR ro x pte 0xffffffffc14e3000-0xffffffffc14e7000 16K USR ro x pte 0xffffffffc14e7000-0xffffffffc14e8000 4K USR ro x pte 0xffffffffc14e8000-0xffffffffc14e9000 4K USR ro x pte 0xffffffffc14e9000-0xffffffffc14f1000 32K USR ro x pte 0xffffffffc14f1000-0xffffffffc14f2000 4K USR ro x pte 0xffffffffc14f2000-0xffffffffc14f6000 16K USR ro x pte 0xffffffffc14f6000-0xffffffffc14f7000 4K USR ro x pte 0xffffffffc14f7000-0xffffffffc14f8000 4K USR ro x pte 0xffffffffc14f8000-0xffffffffc14f9000 4K USR ro x pte 0xffffffffc14f9000-0xffffffffc14fe000 20K USR ro x pte 0xffffffffc14fe000-0xffffffffc1503000 20K USR ro x pte 0xffffffffc1503000-0xffffffffc1508000 20K USR ro x pte 0xffffffffc1508000-0xffffffffc150d000 20K USR ro x pte 0xffffffffc150d000-0xffffffffc1511000 16K USR ro x pte 0xffffffffc1511000-0xffffffffc1513000 8K USR ro x pte 0xffffffffc1513000-0xffffffffc1514000 4K USR ro x pte 0xffffffffc1514000-0xffffffffc1515000 4K USR ro x pte 0xffffffffc1515000-0xffffffffc1516000 4K USR ro x pte 0xffffffffc1516000-0xffffffffc151b000 20K USR ro x pte 0xffffffffc151b000-0xffffffffc1520000 20K USR ro x pte 0xffffffffc1520000-0xffffffffc1521000 4K USR ro x pte 0xffffffffc1521000-0xffffffffc1523000 8K USR ro x pte 0xffffffffc1523000-0xffffffffc1525000 8K USR ro x pte 0xffffffffc1525000-0xffffffffc1526000 4K USR ro x pte 0xffffffffc1526000-0xffffffffc1529000 12K USR ro x pte 0xffffffffc1529000-0xffffffffc152a000 4K USR ro x pte 0xffffffffc152a000-0xffffffffc152b000 4K USR ro x pte 0xffffffffc152b000-0xffffffffc152e000 12K USR ro x pte 0xffffffffc152e000-0xffffffffc1533000 20K USR ro x pte 0xffffffffc1533000-0xffffffffc1535000 8K USR ro x pte 0xffffffffc1535000-0xffffffffc1537000 8K USR ro x pte 0xffffffffc1537000-0xffffffffc1538000 4K USR ro x pte 0xffffffffc1538000-0xffffffffc1539000 4K USR ro x pte 0xffffffffc1539000-0xffffffffc153b000 8K USR ro x pte 0xffffffffc153b000-0xffffffffc153d000 8K USR ro x pte 0xffffffffc153d000-0xffffffffc1541000 16K USR ro x pte 0xffffffffc1541000-0xffffffffc1542000 4K USR ro x pte 0xffffffffc1542000-0xffffffffc1544000 8K USR ro x pte 0xffffffffc1544000-0xffffffffc1545000 4K USR ro x pte 0xffffffffc1545000-0xffffffffc1547000 8K USR ro x pte 0xffffffffc1547000-0xffffffffc1551000 40K USR ro x pte 0xffffffffc1551000-0xffffffffc1552000 4K USR ro x pte 0xffffffffc1552000-0xffffffffc1554000 8K USR ro x pte 0xffffffffc1554000-0xffffffffc1555000 4K USR ro x pte 0xffffffffc1555000-0xffffffffc155d000 32K USR ro x pte 0xffffffffc155d000-0xffffffffc155f000 8K USR ro x pte 0xffffffffc155f000-0xffffffffc1563000 16K USR ro x pte 0xffffffffc1563000-0xffffffffc1566000 12K USR ro x pte 0xffffffffc1566000-0xffffffffc1567000 4K USR ro x pte 0xffffffffc1567000-0xffffffffc1568000 4K USR ro x pte 0xffffffffc1568000-0xffffffffc156a000 8K USR ro x pte 0xffffffffc156a000-0xffffffffc156b000 4K USR ro x pte 0xffffffffc156b000-0xffffffffc1572000 28K USR ro x pte 0xffffffffc1572000-0xffffffffc1573000 4K USR ro x pte 0xffffffffc1573000-0xffffffffc1576000 12K USR ro x pte 0xffffffffc1576000-0xffffffffc1577000 4K USR ro x pte 0xffffffffc1577000-0xffffffffc1578000 4K USR ro x pte 0xffffffffc1578000-0xffffffffc1579000 4K USR ro x pte 0xffffffffc1579000-0xffffffffc157a000 4K USR ro x pte 0xffffffffc157a000-0xffffffffc157b000 4K USR ro x pte 0xffffffffc157b000-0xffffffffc157d000 8K USR ro x pte 0xffffffffc157d000-0xffffffffc157f000 8K USR ro x pte 0xffffffffc157f000-0xffffffffc1582000 12K USR ro x pte 0xffffffffc1582000-0xffffffffc1584000 8K USR ro x pte 0xffffffffc1584000-0xffffffffc1586000 8K USR ro x pte 0xffffffffc1586000-0xffffffffc1588000 8K USR ro x pte 0xffffffffc1588000-0xffffffffc1589000 4K USR ro x pte 0xffffffffc1589000-0xffffffffc158d000 16K USR ro x pte 0xffffffffc158d000-0xffffffffc158f000 8K USR ro x pte 0xffffffffc158f000-0xffffffffc1593000 16K USR ro x pte 0xffffffffc1593000-0xffffffffc1594000 4K USR ro x pte 0xffffffffc1594000-0xffffffffc1595000 4K USR ro x pte 0xffffffffc1595000-0xffffffffc1596000 4K USR ro x pte 0xffffffffc1596000-0xffffffffc1599000 12K USR ro x pte 0xffffffffc1599000-0xffffffffc15ab000 72K USR ro x pte 0xffffffffc15ab000-0xffffffffc15ac000 4K USR ro x pte 0xffffffffc15ac000-0xffffffffc15b0000 16K USR ro x pte 0xffffffffc15b0000-0xffffffffc15b1000 4K USR ro x pte 0xffffffffc15b1000-0xffffffffc15b7000 24K USR ro x pte 0xffffffffc15b7000-0xffffffffc1600000 292K USR RW NX pte 0xffffffffc1600000-0xffffffffc179c000 1648K USR ro NX pte 0xffffffffc179c000-0xffffffffc1800000 400K USR RW NX pte 0xffffffffc1800000-0xffffffffc1802000 8K USR RW x pte 0xffffffffc1802000-0xffffffffc1803000 4K USR RW x pte 0xffffffffc1803000-0xffffffffc1805000 8K USR RW x pte 0xffffffffc1805000-0xffffffffc180b000 24K USR RW x pte 0xffffffffc180b000-0xffffffffc180f000 16K USR ro x pte 0xffffffffc180f000-0xffffffffc1810000 4K USR RW x pte 0xffffffffc1810000-0xffffffffc1812000 8K USR ro x pte 0xffffffffc1812000-0xffffffffc1813000 4K USR RW x pte 0xffffffffc1813000-0xffffffffc1815000 8K USR RW x pte 0xffffffffc1815000-0xffffffffc1816000 4K USR RW x pte 0xffffffffc1816000-0xffffffffc1818000 8K USR RW x pte 0xffffffffc1818000-0xffffffffc181a000 8K USR RW x pte 0xffffffffc181a000-0xffffffffc181d000 12K USR RW x pte 0xffffffffc181d000-0xffffffffc181e000 4K USR RW x pte 0xffffffffc181e000-0xffffffffc1832000 80K USR RW x pte 0xffffffffc1832000-0xffffffffc1834000 8K USR RW x pte 0xffffffffc1834000-0xffffffffc183a000 24K USR RW x pte 0xffffffffc183a000-0xffffffffc183d000 12K USR RW x pte 0xffffffffc183d000-0xffffffffc1841000 16K USR RW x pte 0xffffffffc1841000-0xffffffffc1843000 8K USR RW x pte 0xffffffffc1843000-0xffffffffc1845000 8K USR RW x pte 0xffffffffc1845000-0xffffffffc1846000 4K USR RW x pte 0xffffffffc1846000-0xffffffffc1849000 12K USR RW x pte 0xffffffffc1849000-0xffffffffc184a000 4K USR RW x pte 0xffffffffc184a000-0xffffffffc184f000 20K USR RW x pte 0xffffffffc184f000-0xffffffffc1850000 4K USR RW x pte 0xffffffffc1850000-0xffffffffc1885000 212K USR RW x pte 0xffffffffc1885000-0xffffffffc1938000 716K USR RW NX pte 0xffffffffc1938000-0xffffffffc193a000 8K USR RW x pte 0xffffffffc193a000-0xffffffffc193b000 4K USR ro x pte 0xffffffffc193b000-0xffffffffc193d000 8K USR RW x pte 0xffffffffc193d000-0xffffffffc193e000 4K USR ro x pte 0xffffffffc193e000-0xffffffffc1948000 40K USR RW x pte 0xffffffffc1948000-0xffffffffc194a000 8K USR RW x pte 0xffffffffc194a000-0xffffffffc194c000 8K USR RW x pte 0xffffffffc194c000-0xffffffffc196c000 128K USR RW x pte 0xffffffffc196c000-0xffffffffc196d000 4K USR RW x pte 0xffffffffc196d000-0xffffffffc1970000 12K USR RW x pte 0xffffffffc1970000-0xffffffffc1971000 4K USR RW x pte 0xffffffffc1971000-0xffffffffc1972000 4K USR RW x pte 0xffffffffc1972000-0xffffffffc1973000 4K USR RW x pte 0xffffffffc1973000-0xffffffffc1975000 8K USR RW x pte 0xffffffffc1975000-0xffffffffc1976000 4K USR RW x pte 0xffffffffc1976000-0xffffffffc1977000 4K USR RW x pte 0xffffffffc1977000-0xffffffffc197b000 16K USR RW x pte 0xffffffffc197b000-0xffffffffc19b9000 248K USR RW x pte 0xffffffffc19b9000-0xffffffffc19c0000 28K USR RW x pte 0xffffffffc19c0000-0xffffffffc19df000 124K USR RW x pte 0xffffffffc19df000-0xffffffffc19e8000 36K USR RW x pte 0xffffffffc19e8000-0xffffffffc19f1000 36K USR RW x pte 0xffffffffc19f1000-0xffffffffc19f2000 4K USR RW x pte 0xffffffffc19f2000-0xffffffffc19f3000 4K USR RW x pte 0xffffffffc19f3000-0xffffffffc19f5000 8K USR RW x pte 0xffffffffc19f5000-0xffffffffc19f8000 12K USR RW x pte 0xffffffffc19f8000-0xffffffffc1a0a000 72K USR RW x pte 0xffffffffc1a0a000-0xffffffffc1a0f000 20K USR RW x pte 0xffffffffc1a0f000-0xffffffffc1a1c000 52K USR RW x pte 0xffffffffc1a1c000-0xffffffffc1a1d000 4K USR RW x pte 0xffffffffc1a1d000-0xffffffffc1aaa000 564K USR RW x pte 0xffffffffc1aaa000-0xffffffffc1aae000 16K USR ro x pte 0xffffffffc1aae000-0xffffffffc1b34000 536K USR RW x pte 0xffffffffc1b34000-0xffffffffc1e3d000 3108K USR RW x pte 0xffffffffc1e3d000-0xffffffffcfc93000 227672K USR RW NX pte 0xffffffffcfc93000-0xffffffffe0000000 265652K USR RW x pte 0xffffffffe0000000-0xffffffffe0001000 4K USR ro x pte 0xffffffffe0001000-0xffffffffe0002000 4K USR ro NX pte 0xffffffffe0002000-0xffffffffe0004000 8K USR RW NX pte 0xffffffffe0004000-0xffffffffe0008000 16K pte 0xffffffffe0008000-0xffffffffe0009000 4K USR ro x pte 0xffffffffe0009000-0xffffffffe000a000 4K USR ro NX pte 0xffffffffe000a000-0xffffffffe000c000 8K USR RW NX pte 0xffffffffe000c000-0xffffffffe0070000 400K pte 0xffffffffe0070000-0xffffffffe024c000 1904K USR RW x pte 0xffffffffe024c000-0xffffffffe024e000 8K USR RW x pte 0xffffffffe024e000-0xffffffffe0353000 1044K USR ro x pte 0xffffffffe0353000-0xffffffffe0400000 692K USR RW x pte 0xffffffffe0400000-0xffffffffff000000 492M pmd ---[ End Modules ]--- 0xffffffffff000000-0xffffffffff400000 4M pmd 0xffffffffff400000-0xffffffffff579000 1508K pte 0xffffffffff579000-0xffffffffff57a000 4K USR RW NX pte 0xffffffffff57a000-0xffffffffff5ff000 532K pte 0xffffffffff5ff000-0xffffffffff601000 8K USR ro GLB NX pte 0xffffffffff601000-0xffffffffff800000 2044K pte 0xffffffffff800000-0x0000000000000000 8M pmd # poweroff --azLHFNyN32YCQGCU Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --azLHFNyN32YCQGCU-- From xen-devel-bounces@lists.xen.org Thu May 10 15:37:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:37:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVQx-0004UX-9D; Thu, 10 May 2012 15:37:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVQv-0004UM-CP for xen-devel@lists.xen.org; Thu, 10 May 2012 15:37:37 +0000 Received: from [85.158.143.35:24635] by server-2.bemta-4.messagelabs.com id AD/9D-17550-0C0EBAF4; Thu, 10 May 2012 15:37:36 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336664255!14904628!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13742 invoked from network); 10 May 2012 15:37:35 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:37:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:37:35 +0100 Message-Id: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:37:56 +0100 From: "Jan Beulich" To: "xen-devel" , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartA88641C4.1__=" Cc: Stefano Stabellini Subject: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartA88641C4.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline While for the "normal" case (called from blk_send_response_all()) decrementing requests_finished is correct, doing so in the parse error case is wrong; requests_inflight needs to be decremented instead. Signed-off-by: Jan Beulich --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i blkdev->requests_finished++; } =20 -static void ioreq_release(struct ioreq *ioreq) +static void ioreq_release(struct ioreq *ioreq, bool finish) { struct XenBlkDev *blkdev =3D ioreq->blkdev; =20 @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * memset(ioreq, 0, sizeof(*ioreq)); ioreq->blkdev =3D blkdev; QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); - blkdev->requests_finished--; + if (finish) + blkdev->requests_finished--; + else + blkdev->requests_inflight--; } =20 /* @@ -449,7 +452,7 @@ static void blk_send_response_all(struct while (!QLIST_EMPTY(&blkdev->finished)) { ioreq =3D QLIST_FIRST(&blkdev->finished); send_notify +=3D blk_send_response_one(ioreq); - ioreq_release(ioreq); + ioreq_release(ioreq, true); } if (send_notify) { xen_be_send_notify(&blkdev->xendev); @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X if (blk_send_response_one(ioreq)) { xen_be_send_notify(&blkdev->xendev); } - ioreq_release(ioreq); + ioreq_release(ioreq, false); continue; } =20 --=__PartA88641C4.1__= Content-Type: text/plain; name="qemu-xendisk-accounting.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemu-xendisk-accounting.patch" qemu/xendisk: properly update stats in ioreq_release()=0A=0AWhile for the = "normal" case (called from blk_send_response_all())=0Adecrementing = requests_finished is correct, doing so in the parse error=0Acase is wrong; = requests_inflight needs to be decremented instead.=0A=0ASigned-off-by: Jan = Beulich =0A=0A--- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c= =0A@@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i=0A = blkdev->requests_finished++;=0A }=0A =0A-static void ioreq_release(struct = ioreq *ioreq)=0A+static void ioreq_release(struct ioreq *ioreq, bool = finish)=0A {=0A struct XenBlkDev *blkdev =3D ioreq->blkdev;=0A =0A@@ = -162,7 +162,10 @@ static void ioreq_release(struct ioreq *=0A = memset(ioreq, 0, sizeof(*ioreq));=0A ioreq->blkdev =3D blkdev;=0A = QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list);=0A- blkdev->requests_= finished--;=0A+ if (finish)=0A+ blkdev->requests_finished--;=0A+ = else=0A+ blkdev->requests_inflight--;=0A }=0A =0A /*=0A@@ -449,7 = +452,7 @@ static void blk_send_response_all(struct=0A while (!QLIST_EMP= TY(&blkdev->finished)) {=0A ioreq =3D QLIST_FIRST(&blkdev->finished= );=0A send_notify +=3D blk_send_response_one(ioreq);=0A- = ioreq_release(ioreq);=0A+ ioreq_release(ioreq, true);=0A }=0A = if (send_notify) {=0A xen_be_send_notify(&blkdev->xendev);=0A@@ = -505,7 +508,7 @@ static void blk_handle_requests(struct X=0A = if (blk_send_response_one(ioreq)) {=0A xen_be_send_notify(&= blkdev->xendev);=0A }=0A- ioreq_release(ioreq);=0A+ = ioreq_release(ioreq, false);=0A continue;=0A = }=0A =0A --=__PartA88641C4.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartA88641C4.1__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:37:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:37:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVQx-0004UX-9D; Thu, 10 May 2012 15:37:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVQv-0004UM-CP for xen-devel@lists.xen.org; Thu, 10 May 2012 15:37:37 +0000 Received: from [85.158.143.35:24635] by server-2.bemta-4.messagelabs.com id AD/9D-17550-0C0EBAF4; Thu, 10 May 2012 15:37:36 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1336664255!14904628!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13742 invoked from network); 10 May 2012 15:37:35 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:37:35 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:37:35 +0100 Message-Id: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:37:56 +0100 From: "Jan Beulich" To: "xen-devel" , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartA88641C4.1__=" Cc: Stefano Stabellini Subject: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartA88641C4.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline While for the "normal" case (called from blk_send_response_all()) decrementing requests_finished is correct, doing so in the parse error case is wrong; requests_inflight needs to be decremented instead. Signed-off-by: Jan Beulich --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i blkdev->requests_finished++; } =20 -static void ioreq_release(struct ioreq *ioreq) +static void ioreq_release(struct ioreq *ioreq, bool finish) { struct XenBlkDev *blkdev =3D ioreq->blkdev; =20 @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * memset(ioreq, 0, sizeof(*ioreq)); ioreq->blkdev =3D blkdev; QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); - blkdev->requests_finished--; + if (finish) + blkdev->requests_finished--; + else + blkdev->requests_inflight--; } =20 /* @@ -449,7 +452,7 @@ static void blk_send_response_all(struct while (!QLIST_EMPTY(&blkdev->finished)) { ioreq =3D QLIST_FIRST(&blkdev->finished); send_notify +=3D blk_send_response_one(ioreq); - ioreq_release(ioreq); + ioreq_release(ioreq, true); } if (send_notify) { xen_be_send_notify(&blkdev->xendev); @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X if (blk_send_response_one(ioreq)) { xen_be_send_notify(&blkdev->xendev); } - ioreq_release(ioreq); + ioreq_release(ioreq, false); continue; } =20 --=__PartA88641C4.1__= Content-Type: text/plain; name="qemu-xendisk-accounting.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemu-xendisk-accounting.patch" qemu/xendisk: properly update stats in ioreq_release()=0A=0AWhile for the = "normal" case (called from blk_send_response_all())=0Adecrementing = requests_finished is correct, doing so in the parse error=0Acase is wrong; = requests_inflight needs to be decremented instead.=0A=0ASigned-off-by: Jan = Beulich =0A=0A--- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c= =0A@@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i=0A = blkdev->requests_finished++;=0A }=0A =0A-static void ioreq_release(struct = ioreq *ioreq)=0A+static void ioreq_release(struct ioreq *ioreq, bool = finish)=0A {=0A struct XenBlkDev *blkdev =3D ioreq->blkdev;=0A =0A@@ = -162,7 +162,10 @@ static void ioreq_release(struct ioreq *=0A = memset(ioreq, 0, sizeof(*ioreq));=0A ioreq->blkdev =3D blkdev;=0A = QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list);=0A- blkdev->requests_= finished--;=0A+ if (finish)=0A+ blkdev->requests_finished--;=0A+ = else=0A+ blkdev->requests_inflight--;=0A }=0A =0A /*=0A@@ -449,7 = +452,7 @@ static void blk_send_response_all(struct=0A while (!QLIST_EMP= TY(&blkdev->finished)) {=0A ioreq =3D QLIST_FIRST(&blkdev->finished= );=0A send_notify +=3D blk_send_response_one(ioreq);=0A- = ioreq_release(ioreq);=0A+ ioreq_release(ioreq, true);=0A }=0A = if (send_notify) {=0A xen_be_send_notify(&blkdev->xendev);=0A@@ = -505,7 +508,7 @@ static void blk_handle_requests(struct X=0A = if (blk_send_response_one(ioreq)) {=0A xen_be_send_notify(&= blkdev->xendev);=0A }=0A- ioreq_release(ioreq);=0A+ = ioreq_release(ioreq, false);=0A continue;=0A = }=0A =0A --=__PartA88641C4.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartA88641C4.1__=-- From xen-devel-bounces@lists.xen.org Thu May 10 15:41:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVUY-0004hc-1Y; Thu, 10 May 2012 15:41:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVUX-0004hW-9i for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:41:21 +0000 Received: from [85.158.143.35:41350] by server-1.bemta-4.messagelabs.com id 82/88-20925-0A1EBAF4; Thu, 10 May 2012 15:41:20 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336664477!12299786!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27858 invoked from network); 10 May 2012 15:41:19 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:41:19 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFf3CN008093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:41:04 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 q4AFf2Vh001920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:41:02 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 q4AFf1Nu009505; Thu, 10 May 2012 10:41:01 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:41:01 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 203324032D; Thu, 10 May 2012 11:34:57 -0400 (EDT) Date: Thu, 10 May 2012 11:34:57 -0400 From: Konrad Rzeszutek Wilk To: Jason Garrett-Glaser Message-ID: <20120510153457.GB6389@phenom.dumpdata.com> References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote: > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk > wrote: > > The attached patch fixes RH BZ #742032, #787403, and #745574 > > and touch x86 subsystem. > > > > The patch description gives a very good overview of the problem and > > one solution. The one solution it chooses is not the most architectural= ly > > sound but it does not cause performance degradation. If this your > > first time reading this, please read the patch first and then come back= to > > this cover letter as I've some perf numbers and more detailed explanati= on here. > > > > A bit of overview of the __page_change_attr_set_clr: > > > > Its purpose is to change page attributes from one type to another. > > It is important to understand that the entrance that code: > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which mak= es > > that whole code be single threaded. > > > > Albeit it seems that if debug mode is turned on, it can run in parallel= . The > > effect of using the posted patch is that __page_change_attr_set_clr() w= ill be > > affected when we change caching attributes on 4KB pages and/or the NX f= lag. > > > > The execution of __page_change_attr_set_clr is concentrated in > > (looked for ioremap_* and set_pages_*): > > =A0- during bootup ("Write protecting the ..") > > =A0- suspend/resume and graphic adapters evicting their buffers from th= e card > > =A0 to RAM (which is usually done during suspend but can be done via the > > =A0 'evict' attribute in debugfs) > > =A0- when setting the memory for the cursor (AGP cards using i8xx chips= et) - > > =A0 done during bootup and startup of Xserver. > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done during b= ootup) > > =A0- payload (purgatory code) for kexec (done during kexec -l). > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards lik= e to use > > =A0 ioremap_wc. > > =A0- Intel, radeon, nouveau running into memory pressure and evicting p= ages from > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with only= 4GB). > > > > These are the cases I found when running on baremetal (and Xen) using a= normal > > Fedora Core 16 distro. > > > > The alternate solution to the problem I am trying to solve, which is mu= ch > > more architecturally sound (but has some perf disadvantages) is to wrap > > the pte_flags with paravirt call everywhere. For that these patches two= patches: > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravir= t-xen-Introduce-pte_flags.patch > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravir= t-xen-Optimize-pte_flags-by-marking-it-as.patch > > > > make the pte_flags function (after bootup and patching with alternative= asm) > > look as so: > > > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rdi,%r= ax > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xchg %= ax,%ax > > > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well= on Intel > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that= I found out > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled = in (but the tracer > > is set to the default 'nop'). If I disable that specific config option = the numbers > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on = the AMD box. > > Interestingly enough I only see these on AMD machines - not on the Inte= l ones. > = > The AMD software optimization manual says that -- at least on some > chips -- too many prefixes forces the instruction decoder into a slow > mode (basically microcoded) where it takes literally dozens of cycles > for a single instruction. I believe more than 2 prefixes will do > this; check the manual itself for specifics. I've been digging in to this during my "free" time to figure out what is going on. Sadly, haven't progressed much besides writting a set of patch= es that would add the 'notrace' to the pvops calls and playing with those patches. In other words - still not sure what is happening. > = > Jason > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:41:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVUY-0004hc-1Y; Thu, 10 May 2012 15:41:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVUX-0004hW-9i for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:41:21 +0000 Received: from [85.158.143.35:41350] by server-1.bemta-4.messagelabs.com id 82/88-20925-0A1EBAF4; Thu, 10 May 2012 15:41:20 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336664477!12299786!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27858 invoked from network); 10 May 2012 15:41:19 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:41:19 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFf3CN008093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:41:04 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 q4AFf2Vh001920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:41:02 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 q4AFf1Nu009505; Thu, 10 May 2012 10:41:01 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:41:01 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 203324032D; Thu, 10 May 2012 11:34:57 -0400 (EDT) Date: Thu, 10 May 2012 11:34:57 -0400 From: Konrad Rzeszutek Wilk To: Jason Garrett-Glaser Message-ID: <20120510153457.GB6389@phenom.dumpdata.com> References: <1328888091-9692-1-git-send-email-konrad.wilk@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1). X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Feb 21, 2012 at 06:53:35PM -0800, Jason Garrett-Glaser wrote: > On Fri, Feb 10, 2012 at 7:34 AM, Konrad Rzeszutek Wilk > wrote: > > The attached patch fixes RH BZ #742032, #787403, and #745574 > > and touch x86 subsystem. > > > > The patch description gives a very good overview of the problem and > > one solution. The one solution it chooses is not the most architectural= ly > > sound but it does not cause performance degradation. If this your > > first time reading this, please read the patch first and then come back= to > > this cover letter as I've some perf numbers and more detailed explanati= on here. > > > > A bit of overview of the __page_change_attr_set_clr: > > > > Its purpose is to change page attributes from one type to another. > > It is important to understand that the entrance that code: > > __page_change_attr_set_clr is guarded by cpa_lock spin-lock - which mak= es > > that whole code be single threaded. > > > > Albeit it seems that if debug mode is turned on, it can run in parallel= . The > > effect of using the posted patch is that __page_change_attr_set_clr() w= ill be > > affected when we change caching attributes on 4KB pages and/or the NX f= lag. > > > > The execution of __page_change_attr_set_clr is concentrated in > > (looked for ioremap_* and set_pages_*): > > =A0- during bootup ("Write protecting the ..") > > =A0- suspend/resume and graphic adapters evicting their buffers from th= e card > > =A0 to RAM (which is usually done during suspend but can be done via the > > =A0 'evict' attribute in debugfs) > > =A0- when setting the memory for the cursor (AGP cards using i8xx chips= et) - > > =A0 done during bootup and startup of Xserver. > > =A0- setting up memory for Intel GTT scratch (i9xx) page (done during b= ootup) > > =A0- payload (purgatory code) for kexec (done during kexec -l). > > =A0- ioremap_* during PCI devices load - InfiniBand and video cards lik= e to use > > =A0 ioremap_wc. > > =A0- Intel, radeon, nouveau running into memory pressure and evicting p= ages from > > =A0 their GEM/TTM pool (once an hour or so if compiling a lot with only= 4GB). > > > > These are the cases I found when running on baremetal (and Xen) using a= normal > > Fedora Core 16 distro. > > > > The alternate solution to the problem I am trying to solve, which is mu= ch > > more architecturally sound (but has some perf disadvantages) is to wrap > > the pte_flags with paravirt call everywhere. For that these patches two= patches: > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravir= t-xen-Introduce-pte_flags.patch > > http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravir= t-xen-Optimize-pte_flags-by-marking-it-as.patch > > > > make the pte_flags function (after bootup and patching with alternative= asm) > > look as so: > > > > =A0 48 89 f8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0%rdi,%r= ax > > =A0 66 66 66 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data32 data32 xchg %= ax,%ax > > > > [the 66 66 .. is 'nop']. Looks good right? Well, it does work very well= on Intel > > (used an i3 2100), but on AMD A8-3850 it hits a performance wall - that= I found out > > is a result of CONFIG_FUNCTION_TRACER (too many nops??) being compiled = in (but the tracer > > is set to the default 'nop'). If I disable that specific config option = the numbers > > are the same as the baseline (with CONFIG_FUNCTION_TRACER disabled) on = the AMD box. > > Interestingly enough I only see these on AMD machines - not on the Inte= l ones. > = > The AMD software optimization manual says that -- at least on some > chips -- too many prefixes forces the instruction decoder into a slow > mode (basically microcoded) where it takes literally dozens of cycles > for a single instruction. I believe more than 2 prefixes will do > this; check the manual itself for specifics. I've been digging in to this during my "free" time to figure out what is going on. Sadly, haven't progressed much besides writting a set of patch= es that would add the 'notrace' to the pvops calls and playing with those patches. In other words - still not sure what is happening. > = > Jason > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:42:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:42:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVVL-0004lI-Hy; Thu, 10 May 2012 15:42:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVVK-0004l9-4A for xen-devel@lists.xen.org; Thu, 10 May 2012 15:42:10 +0000 Received: from [85.158.139.83:10460] by server-2.bemta-5.messagelabs.com id C8/82-17016-1D1EBAF4; Thu, 10 May 2012 15:42:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336664528!23839618!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6639 invoked from network); 10 May 2012 15:42:08 -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; 10 May 2012 15:42:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:42:08 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 16:42:08 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVVI-00086B-0p; Thu, 10 May 2012 15:42:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVVH-0007ET-W0; Thu, 10 May 2012 16:42:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.57807.951152.444088@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:42:07 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> References: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails"): > This is needed in order to perform the domain destruction if > libxl__domain_make fails. Thanks, I have included this in my series in the form below. From: Roger Pau Monne Subject: [PATCH] libxl: set guest_domid even if libxl__domain_make fails This is needed in order to perform the domain destruction if libxl__domain_make fails. Also move doc comment about error behaviour of libxl__domain_make from implementation to declaration. Signed-off-by: Roger Pau Monne Signed-off-by: Ian Jackson --- tools/libxl/libxl_create.c | 3 +-- tools/libxl/libxl_internal.h | 4 ++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 0f17202..447d8ba 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -396,8 +396,6 @@ out: int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid) - /* on entry, libxl_domid_valid_guest(domid) must be false; - * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); int flags, ret, rc; @@ -600,6 +598,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 90b08ef..84bfbc6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1073,9 +1073,13 @@ _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, char **args); // logs errors, never returns /* from xl_create */ + + /* on entry, libxl_domid_valid_guest(domid) must be false; + * on exit (even error exit), domid may be valid and refer to a domain */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); + _hidden int libxl__domain_build(libxl__gc *gc, libxl_domain_build_info *info, uint32_t domid, -- tg: (3aaba1c..) t/xen/xl.create-do-destroy (depends on: t/xen/xl.event.spawn) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:42:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:42:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVVL-0004lI-Hy; Thu, 10 May 2012 15:42:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVVK-0004l9-4A for xen-devel@lists.xen.org; Thu, 10 May 2012 15:42:10 +0000 Received: from [85.158.139.83:10460] by server-2.bemta-5.messagelabs.com id C8/82-17016-1D1EBAF4; Thu, 10 May 2012 15:42:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1336664528!23839618!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6639 invoked from network); 10 May 2012 15:42:08 -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; 10 May 2012 15:42:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:42:08 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 16:42:08 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVVI-00086B-0p; Thu, 10 May 2012 15:42:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVVH-0007ET-W0; Thu, 10 May 2012 16:42:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.57807.951152.444088@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:42:07 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> References: <1336144455-45617-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: set guest_domid even if libxl__domain_make fails"): > This is needed in order to perform the domain destruction if > libxl__domain_make fails. Thanks, I have included this in my series in the form below. From: Roger Pau Monne Subject: [PATCH] libxl: set guest_domid even if libxl__domain_make fails This is needed in order to perform the domain destruction if libxl__domain_make fails. Also move doc comment about error behaviour of libxl__domain_make from implementation to declaration. Signed-off-by: Roger Pau Monne Signed-off-by: Ian Jackson --- tools/libxl/libxl_create.c | 3 +-- tools/libxl/libxl_internal.h | 4 ++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 0f17202..447d8ba 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -396,8 +396,6 @@ out: int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid) - /* on entry, libxl_domid_valid_guest(domid) must be false; - * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); int flags, ret, rc; @@ -600,6 +598,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 90b08ef..84bfbc6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1073,9 +1073,13 @@ _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, char **args); // logs errors, never returns /* from xl_create */ + + /* on entry, libxl_domid_valid_guest(domid) must be false; + * on exit (even error exit), domid may be valid and refer to a domain */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); + _hidden int libxl__domain_build(libxl__gc *gc, libxl_domain_build_info *info, uint32_t domid, -- tg: (3aaba1c..) t/xen/xl.create-do-destroy (depends on: t/xen/xl.event.spawn) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:43:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVWc-0004sq-0R; Thu, 10 May 2012 15:43:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVWa-0004se-Ga for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:43:28 +0000 Received: from [85.158.143.35:51730] by server-2.bemta-4.messagelabs.com id 7C/F6-17550-F12EBAF4; Thu, 10 May 2012 15:43:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336664604!11650851!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16558 invoked from network); 10 May 2012 15:43:26 -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; 10 May 2012 15:43:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFhMPF020542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:43:23 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AFhM7i024044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:43:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AFhMKo015632; Thu, 10 May 2012 10:43:22 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:43:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0820E4032D; Thu, 10 May 2012 11:37:18 -0400 (EDT) Date: Thu, 10 May 2012 11:37:17 -0400 From: Konrad Rzeszutek Wilk To: Nupur Ghatnekar Message-ID: <20120510153717.GD6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] notification in xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Mar 21, 2012 at 11:50:48AM +0530, Nupur Ghatnekar wrote: > hey, > For event notification there are 2 functions that i came across. > > notify_remote_via_irq(int irq) > notify_remote_via_evtchn(int port) > > I tried to use those, but didnt know how to check whether notification has > occurred. Is there a way in which i can check the success of the commands. You should also use 'request_irq' to bind yourself to the IRQ number. That way your handler would awake when it is done. Look at how the existing front and backend drivers do it. > > Thanks. > > -- > > Nupur Ghatnekar > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:43:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVWc-0004sq-0R; Thu, 10 May 2012 15:43:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVWa-0004se-Ga for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:43:28 +0000 Received: from [85.158.143.35:51730] by server-2.bemta-4.messagelabs.com id 7C/F6-17550-F12EBAF4; Thu, 10 May 2012 15:43:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336664604!11650851!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16558 invoked from network); 10 May 2012 15:43:26 -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; 10 May 2012 15:43:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFhMPF020542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:43:23 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AFhM7i024044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:43:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AFhMKo015632; Thu, 10 May 2012 10:43:22 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:43:21 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0820E4032D; Thu, 10 May 2012 11:37:18 -0400 (EDT) Date: Thu, 10 May 2012 11:37:17 -0400 From: Konrad Rzeszutek Wilk To: Nupur Ghatnekar Message-ID: <20120510153717.GD6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] notification in xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Mar 21, 2012 at 11:50:48AM +0530, Nupur Ghatnekar wrote: > hey, > For event notification there are 2 functions that i came across. > > notify_remote_via_irq(int irq) > notify_remote_via_evtchn(int port) > > I tried to use those, but didnt know how to check whether notification has > occurred. Is there a way in which i can check the success of the commands. You should also use 'request_irq' to bind yourself to the IRQ number. That way your handler would awake when it is done. Look at how the existing front and backend drivers do it. > > Thanks. > > -- > > Nupur Ghatnekar > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:44:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVXS-0004zh-ET; Thu, 10 May 2012 15:44:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVXR-0004zO-P4 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:44:21 +0000 Received: from [85.158.143.99:44368] by server-1.bemta-4.messagelabs.com id 9C/FC-20925-552EBAF4; Thu, 10 May 2012 15:44:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336664658!17628697!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6141 invoked from network); 10 May 2012 15:44:20 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:44:20 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFiFRZ011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:44:15 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 q4AFiEvw000929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:44:14 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 q4AFiEUS002751; Thu, 10 May 2012 10:44:14 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:44:13 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0A1434032D; Thu, 10 May 2012 11:38:10 -0400 (EDT) Date: Thu, 10 May 2012 11:38:10 -0400 From: Konrad Rzeszutek Wilk To: Nupur Ghatnekar Message-ID: <20120510153809.GE6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] irqhandler for xenbus device X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Mar 21, 2012 at 11:56:41AM +0530, Nupur Ghatnekar wrote: > Hello, > > I have written 2 modules (front and backend) of a device driver. > here all i have tried to do is share a page and map the page. > i have added an irqhandler to the eventchannel using > bind_interdomain_evtchn_to_irqhandler() > > but ,this is what i got.. i do not understand what happened. > > any help will be appreciated!! > > [ 6098.141305] p9_xen_backend_init > [ 6098.141332] leaving backend_init > [ 6169.434245] Backprobe fired 1 > [ 6169.434703] node name: /local/domain/2/device/p9xen/0 > [ 6169.434980] INITIAL PAGE: 855 INITAL PORT: 34 > [ 6169.435005] Map Successful: data: Hey this is a new page..we just sent > it! > [ 6169.435032] interrupt registered:: 312 > [ 6169.435037] we are in the irq handler!!312 > [ 6169.435040] > [ 6169.435040] notify by irq > [ 6169.435043] irq event 312: bogus return value 33 That is the problem. You need to return IRQ_HANDLED in your irq handler. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:44:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVXS-0004zh-ET; Thu, 10 May 2012 15:44:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVXR-0004zO-P4 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:44:21 +0000 Received: from [85.158.143.99:44368] by server-1.bemta-4.messagelabs.com id 9C/FC-20925-552EBAF4; Thu, 10 May 2012 15:44:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336664658!17628697!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNDU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6141 invoked from network); 10 May 2012 15:44:20 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:44:20 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFiFRZ011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:44:15 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 q4AFiEvw000929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:44:14 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 q4AFiEUS002751; Thu, 10 May 2012 10:44:14 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:44:13 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0A1434032D; Thu, 10 May 2012 11:38:10 -0400 (EDT) Date: Thu, 10 May 2012 11:38:10 -0400 From: Konrad Rzeszutek Wilk To: Nupur Ghatnekar Message-ID: <20120510153809.GE6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] irqhandler for xenbus device X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Mar 21, 2012 at 11:56:41AM +0530, Nupur Ghatnekar wrote: > Hello, > > I have written 2 modules (front and backend) of a device driver. > here all i have tried to do is share a page and map the page. > i have added an irqhandler to the eventchannel using > bind_interdomain_evtchn_to_irqhandler() > > but ,this is what i got.. i do not understand what happened. > > any help will be appreciated!! > > [ 6098.141305] p9_xen_backend_init > [ 6098.141332] leaving backend_init > [ 6169.434245] Backprobe fired 1 > [ 6169.434703] node name: /local/domain/2/device/p9xen/0 > [ 6169.434980] INITIAL PAGE: 855 INITAL PORT: 34 > [ 6169.435005] Map Successful: data: Hey this is a new page..we just sent > it! > [ 6169.435032] interrupt registered:: 312 > [ 6169.435037] we are in the irq handler!!312 > [ 6169.435040] > [ 6169.435040] notify by irq > [ 6169.435043] irq event 312: bogus return value 33 That is the problem. You need to return IRQ_HANDLED in your irq handler. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:45:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:45:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVYG-00057K-TJ; Thu, 10 May 2012 15:45:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVYF-000575-K7 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:45:11 +0000 Received: from [85.158.138.51:21255] by server-3.bemta-3.messagelabs.com id DD/12-04048-682EBAF4; Thu, 10 May 2012 15:45:10 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336664708!26333308!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23175 invoked from network); 10 May 2012 15:45:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:45:09 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFj694022401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:45:07 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 q4AFj53i009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:45:06 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 q4AFj53T012873; Thu, 10 May 2012 10:45:05 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:45:05 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 498754032D; Thu, 10 May 2012 11:39:01 -0400 (EDT) Date: Thu, 10 May 2012 11:39:01 -0400 From: Konrad Rzeszutek Wilk To: Rajendra Bele Message-ID: <20120510153901.GF6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen Enhancement X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Mar 22, 2012 at 03:05:46PM +0530, Rajendra Bele wrote: > Dear Friends > > I am interested for research in virtualization ; i wanted to identify some > algorithms and enhance them; OK, so you are looking at fixing bugs. Great! > > can anybody help me for following activities > > 1. Install Xen on laptop > > 2. Add open source os to create virtualization environment > > 3. check performance with current souce code > > 4. Identify algorithms associated with existing > > 5. Identify performance bottlenecks with current algorithms > > 6. Modify algorithms and implement code > > 7. execute the code and check performance > > I will be more happy if abybody guides me to conduct above research plan Are you still interested in this? > > Thanking you > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:45:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:45:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVYG-00057K-TJ; Thu, 10 May 2012 15:45:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVYF-000575-K7 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:45:11 +0000 Received: from [85.158.138.51:21255] by server-3.bemta-3.messagelabs.com id DD/12-04048-682EBAF4; Thu, 10 May 2012 15:45:10 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336664708!26333308!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23175 invoked from network); 10 May 2012 15:45:09 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:45:09 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFj694022401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:45:07 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 q4AFj53i009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:45:06 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 q4AFj53T012873; Thu, 10 May 2012 10:45:05 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:45:05 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 498754032D; Thu, 10 May 2012 11:39:01 -0400 (EDT) Date: Thu, 10 May 2012 11:39:01 -0400 From: Konrad Rzeszutek Wilk To: Rajendra Bele Message-ID: <20120510153901.GF6389@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen Enhancement X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Mar 22, 2012 at 03:05:46PM +0530, Rajendra Bele wrote: > Dear Friends > > I am interested for research in virtualization ; i wanted to identify some > algorithms and enhance them; OK, so you are looking at fixing bugs. Great! > > can anybody help me for following activities > > 1. Install Xen on laptop > > 2. Add open source os to create virtualization environment > > 3. check performance with current souce code > > 4. Identify algorithms associated with existing > > 5. Identify performance bottlenecks with current algorithms > > 6. Modify algorithms and implement code > > 7. execute the code and check performance > > I will be more happy if abybody guides me to conduct above research plan Are you still interested in this? > > Thanking you > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVaX-0005Pu-Ih; Thu, 10 May 2012 15:47:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVaV-0005Pg-V9 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:47:32 +0000 Received: from [85.158.138.51:60911] by server-10.bemta-3.messagelabs.com id 5B/EB-29478-313EBAF4; Thu, 10 May 2012 15:47:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336664849!18345917!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1699 invoked from network); 10 May 2012 15:47: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; 10 May 2012 15:47:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411925" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:47: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, 10 May 2012 16:47:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVaS-00087v-D3; Thu, 10 May 2012 15:47:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVaS-0007po-CE; Thu, 10 May 2012 16:47:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.58128.360283.981292@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:47:28 +0100 To: Goncalo Gomes Newsgroups: chiark.mail.xen.devel In-Reply-To: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> References: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com Subject: Re: [Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Goncalo Gomes writes ("[Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option"): > Signed-off-by: Goncalo Gomes > > diff -r 53f124f82cfd -r 79526068a874 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 Mon May 07 01:10:57 2012 +0000 > +++ b/docs/man/xl.cfg.pod.5 Mon May 07 01:10:58 2012 +0000 > @@ -624,6 +624,11 @@ frequency changes. > > Please see F for more information on this option. > > +=item B > + > +Automatically attach to domain's VNC server forking a vncviewer process > +on domain creation and/or restore. > + Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVaX-0005Pu-Ih; Thu, 10 May 2012 15:47:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVaV-0005Pg-V9 for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:47:32 +0000 Received: from [85.158.138.51:60911] by server-10.bemta-3.messagelabs.com id 5B/EB-29478-313EBAF4; Thu, 10 May 2012 15:47:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336664849!18345917!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1699 invoked from network); 10 May 2012 15:47: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; 10 May 2012 15:47:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411925" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:47: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, 10 May 2012 16:47:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVaS-00087v-D3; Thu, 10 May 2012 15:47:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVaS-0007po-CE; Thu, 10 May 2012 16:47:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.58128.360283.981292@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:47:28 +0100 To: Goncalo Gomes Newsgroups: chiark.mail.xen.devel In-Reply-To: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> References: <79526068a8743f4a593c.1336353617@dt29.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com Subject: Re: [Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Goncalo Gomes writes ("[Xen-devel] [PATCH 2 of 6] Update xl.cfg man page to introduce new config option"): > Signed-off-by: Goncalo Gomes > > diff -r 53f124f82cfd -r 79526068a874 docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 Mon May 07 01:10:57 2012 +0000 > +++ b/docs/man/xl.cfg.pod.5 Mon May 07 01:10:58 2012 +0000 > @@ -624,6 +624,11 @@ frequency changes. > > Please see F for more information on this option. > > +=item B > + > +Automatically attach to domain's VNC server forking a vncviewer process > +on domain creation and/or restore. > + Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVbv-0005Xz-4e; Thu, 10 May 2012 15:48:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVbu-0005Xq-7K for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:48:58 +0000 Received: from [85.158.143.35:39199] by server-1.bemta-4.messagelabs.com id 07/53-20925-963EBAF4; Thu, 10 May 2012 15:48:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336664936!14804218!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31547 invoked from network); 10 May 2012 15:48:56 -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; 10 May 2012 15:48:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411967" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:48:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 16:48:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVbr-00088c-Tw; Thu, 10 May 2012 15:48:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVbr-0007q4-T7; Thu, 10 May 2012 16:48:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.58215.886046.419417@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:48:55 +0100 To: Goncalo Gomes Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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 6 of 6] xl: extend the help options of the create and restore commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Goncalo Gomes writes ("[Xen-devel] [PATCH 6 of 6] xl: extend the help options of the create and restore commands"): the domain." > + "-e Do not wait in the background for the death of the domain.\n" > + "-V, --vncviewer Connect to the VNC display after the domain is created.\n" > + "-A, --vncviewer-autopass\n" > + " Pass VNC password to viewer via stdin." Acked-by: Ian Jackson However I think ideally this and the previous patch I have just acked (the corresponding documentation) should be in the same patch as the implementation. So when you resend can you combine them ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVbv-0005Xz-4e; Thu, 10 May 2012 15:48:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVbu-0005Xq-7K for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:48:58 +0000 Received: from [85.158.143.35:39199] by server-1.bemta-4.messagelabs.com id 07/53-20925-963EBAF4; Thu, 10 May 2012 15:48:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336664936!14804218!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31547 invoked from network); 10 May 2012 15:48:56 -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; 10 May 2012 15:48:56 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12411967" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 15:48:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 16:48:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVbr-00088c-Tw; Thu, 10 May 2012 15:48:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVbr-0007q4-T7; Thu, 10 May 2012 16:48:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.58215.886046.419417@mariner.uk.xensource.com> Date: Thu, 10 May 2012 16:48:55 +0100 To: Goncalo Gomes Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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 6 of 6] xl: extend the help options of the create and restore commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Goncalo Gomes writes ("[Xen-devel] [PATCH 6 of 6] xl: extend the help options of the create and restore commands"): the domain." > + "-e Do not wait in the background for the death of the domain.\n" > + "-V, --vncviewer Connect to the VNC display after the domain is created.\n" > + "-A, --vncviewer-autopass\n" > + " Pass VNC password to viewer via stdin." Acked-by: Ian Jackson However I think ideally this and the previous patch I have just acked (the corresponding documentation) should be in the same patch as the implementation. So when you resend can you combine them ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:49:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc6-0005Zr-Ur; Thu, 10 May 2012 15:49:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc5-0005Ys-5d for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:49:09 +0000 Received: from [85.158.143.99:41408] by server-1.bemta-4.messagelabs.com id 07/93-20925-473EBAF4; Thu, 10 May 2012 15:49:08 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336664945!17629586!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24251 invoked from network); 10 May 2012 15:49:07 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:49:07 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFn1ee026853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:49:02 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 q4AFn0uI000279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:49:00 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AFmx9d016150; Thu, 10 May 2012 10:49:00 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:48:59 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D77884032D; Thu, 10 May 2012 11:42:55 -0400 (EDT) Date: Thu, 10 May 2012 11:42:55 -0400 From: Konrad Rzeszutek Wilk To: Kristoffer Harthing Egefelt Message-ID: <20120510154255.GH6389@phenom.dumpdata.com> References: <1332865415525-5598276.post@n5.nabble.com> <20120327192644.GQ12984@reaktio.net> <1332880165775-5598838.post@n5.nabble.com> <1332883903167-5598955.post@n5.nabble.com> <20120327215159.GA17203@phenom.dumpdata.com> <1332887727951-5599061.post@n5.nabble.com> <20120328143712.GG18161@phenom.dumpdata.com> <1333009808678-5602999.post@n5.nabble.com> <20120329145944.GF12008@phenom.dumpdata.com> <1333046630807-5604684.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1333046630807-5604684.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] no-carrier on qlogic 8242 10gig with linux 3.x running xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Mar 29, 2012 at 11:43:50AM -0700, Kristoffer Harthing Egefelt wrote: > > On Thu, Mar 29, 2012 at 01:30:08AM -0700, Kristoffer Harthing Egefelt wrote: > > >Can you attach the /proc/interrupts please - for both Xen and baremetal. > > > > *Bare metal:* > > CPU0 > > 0: 0 IR-IO-APIC-edge timer > > 8: 0 IR-IO-APIC-edge rtc0 > > 9: 0 IR-IO-APIC-fasteoi acpi > > 17: 0 IR-IO-APIC-fasteoi uhci_hcd:usb3, ata_piix > > 18: 0 IR-IO-APIC-fasteoi uhci_hcd:usb4 > > 19: 0 IR-IO-APIC-fasteoi ehci_hcd:usb1 > > 20: 0 IR-IO-APIC-fasteoi uhci_hcd:usb6 > > 21: 0 IR-IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5, uhci_hcd:usb7 > > 72: 0 DMAR_MSI-edge dmar0 > > 73: 0 IR-PCI-MSI-edge PCIe PME > > 74: 0 IR-PCI-MSI-edge PCIe PME > > 75: 0 IR-PCI-MSI-edge PCIe PME > > 76: 0 IR-PCI-MSI-edge PCIe PME > > 77: 0 IR-PCI-MSI-edge megasas > > 78: 0 IR-PCI-MSI-edge eth0[0] > > 79: 0 IR-PCI-MSI-edge eth0[1] > > 80: 0 IR-PCI-MSI-edge eth0[2] > > 81: 0 IR-PCI-MSI-edge eth0[3] > > 82: 0 IR-PCI-MSI-edge eth1[0] > > 83: 0 IR-PCI-MSI-edge eth1[1] > > 84: 0 IR-PCI-MSI-edge eth1[2] > > 85: 0 IR-PCI-MSI-edge eth1[3] > > NMI: 0 Non-maskable interrupts > > LOC: 1288 Local timer interrupts > > SPU: 0 Spurious interrupts > > PMI: 0 Performance monitoring interrupts > > IWI: 0 IRQ work interrupts > > RES: 295 Rescheduling interrupts > > CAL: 675 Function call interrupts > > TLB: 5 TLB shootdowns > > TRM: 0 Thermal event interrupts > > THR: 0 Threshold APIC interrupts > > MCE: 0 Machine check exceptions > > MCP: 2 Machine check polls > > ERR: > > MIS: > > > > *Xen:* > > CPU0 > > 8: 0 xen-pirq-ioapic-edge rtc0 > > 9: 0 xen-pirq-ioapic-level acpi > > 17: 0 xen-pirq-ioapic-level ata_piix, uhci_hcd:usb3 > > 18: 0 xen-pirq-ioapic-level uhci_hcd:usb4 > > 19: 0 xen-pirq-ioapic-level ehci_hcd:usb1 > > 20: 0 xen-pirq-ioapic-level uhci_hcd:usb6 > > 21: 0 xen-pirq-ioapic-level ehci_hcd:usb2, uhci_hcd:usb5, uhci_hcd:usb7 > > 304: 0 xen-percpu-virq timer0 > > 305: 0 xen-percpu-ipi resched0 > > 306: 0 xen-percpu-ipi callfunc0 > > 307: 0 xen-percpu-virq debug0 > > 308: 0 xen-percpu-ipi callfuncsingle0 > > 424: 0 xen-dyn-event xenbus > > 425: 0 xen-pirq-msi PCIe PME > > 426: 0 xen-pirq-msi PCIe PME > > 427: 0 xen-pirq-msi PCIe PME > > 428: 0 xen-pirq-msi PCIe PME > > > >So something is bogus here. There should be a bunch of ethX[Y] - and > >it looks like the MSI's just didn't get setup. > I'm still trying to get qlogic and dell to find out why qlogics firmwares > does not work on the OEM cards from Dell - I'm not sure this will do > anything though. I'll try and downgrade the linux driver to .24 Any luck? > > >What kernel version are you using? > I have tried 3.1.8-2 and 3.2.9-1 (debian wheezy) > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/no-carrier-on-qlogic-8242-10gig-with-linux-3-x-running-xen-tp5597283p5604684.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:49:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc6-0005Zr-Ur; Thu, 10 May 2012 15:49:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc5-0005Ys-5d for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:49:09 +0000 Received: from [85.158.143.99:41408] by server-1.bemta-4.messagelabs.com id 07/93-20925-473EBAF4; Thu, 10 May 2012 15:49:08 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336664945!17629586!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24251 invoked from network); 10 May 2012 15:49:07 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:49:07 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AFn1ee026853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 15:49:02 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 q4AFn0uI000279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 15:49:00 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AFmx9d016150; Thu, 10 May 2012 10:49:00 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 08:48:59 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D77884032D; Thu, 10 May 2012 11:42:55 -0400 (EDT) Date: Thu, 10 May 2012 11:42:55 -0400 From: Konrad Rzeszutek Wilk To: Kristoffer Harthing Egefelt Message-ID: <20120510154255.GH6389@phenom.dumpdata.com> References: <1332865415525-5598276.post@n5.nabble.com> <20120327192644.GQ12984@reaktio.net> <1332880165775-5598838.post@n5.nabble.com> <1332883903167-5598955.post@n5.nabble.com> <20120327215159.GA17203@phenom.dumpdata.com> <1332887727951-5599061.post@n5.nabble.com> <20120328143712.GG18161@phenom.dumpdata.com> <1333009808678-5602999.post@n5.nabble.com> <20120329145944.GF12008@phenom.dumpdata.com> <1333046630807-5604684.post@n5.nabble.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1333046630807-5604684.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] no-carrier on qlogic 8242 10gig with linux 3.x running xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Mar 29, 2012 at 11:43:50AM -0700, Kristoffer Harthing Egefelt wrote: > > On Thu, Mar 29, 2012 at 01:30:08AM -0700, Kristoffer Harthing Egefelt wrote: > > >Can you attach the /proc/interrupts please - for both Xen and baremetal. > > > > *Bare metal:* > > CPU0 > > 0: 0 IR-IO-APIC-edge timer > > 8: 0 IR-IO-APIC-edge rtc0 > > 9: 0 IR-IO-APIC-fasteoi acpi > > 17: 0 IR-IO-APIC-fasteoi uhci_hcd:usb3, ata_piix > > 18: 0 IR-IO-APIC-fasteoi uhci_hcd:usb4 > > 19: 0 IR-IO-APIC-fasteoi ehci_hcd:usb1 > > 20: 0 IR-IO-APIC-fasteoi uhci_hcd:usb6 > > 21: 0 IR-IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5, uhci_hcd:usb7 > > 72: 0 DMAR_MSI-edge dmar0 > > 73: 0 IR-PCI-MSI-edge PCIe PME > > 74: 0 IR-PCI-MSI-edge PCIe PME > > 75: 0 IR-PCI-MSI-edge PCIe PME > > 76: 0 IR-PCI-MSI-edge PCIe PME > > 77: 0 IR-PCI-MSI-edge megasas > > 78: 0 IR-PCI-MSI-edge eth0[0] > > 79: 0 IR-PCI-MSI-edge eth0[1] > > 80: 0 IR-PCI-MSI-edge eth0[2] > > 81: 0 IR-PCI-MSI-edge eth0[3] > > 82: 0 IR-PCI-MSI-edge eth1[0] > > 83: 0 IR-PCI-MSI-edge eth1[1] > > 84: 0 IR-PCI-MSI-edge eth1[2] > > 85: 0 IR-PCI-MSI-edge eth1[3] > > NMI: 0 Non-maskable interrupts > > LOC: 1288 Local timer interrupts > > SPU: 0 Spurious interrupts > > PMI: 0 Performance monitoring interrupts > > IWI: 0 IRQ work interrupts > > RES: 295 Rescheduling interrupts > > CAL: 675 Function call interrupts > > TLB: 5 TLB shootdowns > > TRM: 0 Thermal event interrupts > > THR: 0 Threshold APIC interrupts > > MCE: 0 Machine check exceptions > > MCP: 2 Machine check polls > > ERR: > > MIS: > > > > *Xen:* > > CPU0 > > 8: 0 xen-pirq-ioapic-edge rtc0 > > 9: 0 xen-pirq-ioapic-level acpi > > 17: 0 xen-pirq-ioapic-level ata_piix, uhci_hcd:usb3 > > 18: 0 xen-pirq-ioapic-level uhci_hcd:usb4 > > 19: 0 xen-pirq-ioapic-level ehci_hcd:usb1 > > 20: 0 xen-pirq-ioapic-level uhci_hcd:usb6 > > 21: 0 xen-pirq-ioapic-level ehci_hcd:usb2, uhci_hcd:usb5, uhci_hcd:usb7 > > 304: 0 xen-percpu-virq timer0 > > 305: 0 xen-percpu-ipi resched0 > > 306: 0 xen-percpu-ipi callfunc0 > > 307: 0 xen-percpu-virq debug0 > > 308: 0 xen-percpu-ipi callfuncsingle0 > > 424: 0 xen-dyn-event xenbus > > 425: 0 xen-pirq-msi PCIe PME > > 426: 0 xen-pirq-msi PCIe PME > > 427: 0 xen-pirq-msi PCIe PME > > 428: 0 xen-pirq-msi PCIe PME > > > >So something is bogus here. There should be a bunch of ethX[Y] - and > >it looks like the MSI's just didn't get setup. > I'm still trying to get qlogic and dell to find out why qlogics firmwares > does not work on the OEM cards from Dell - I'm not sure this will do > anything though. I'll try and downgrade the linux driver to .24 Any luck? > > >What kernel version are you using? > I have tried 3.1.8-2 and 3.2.9-1 (debian wheezy) > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/no-carrier-on-qlogic-8242-10gig-with-linux-3-x-running-xen-tp5597283p5604684.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVc5-0005ZW-Hw; Thu, 10 May 2012 15:49:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc4-0005Ys-9K for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:49:08 +0000 Received: from [85.158.143.99:41271] by server-1.bemta-4.messagelabs.com id DC/83-20925-273EBAF4; Thu, 10 May 2012 15:49:06 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-216.messagelabs.com!1336664944!27378961!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13281 invoked from network); 10 May 2012 15:49:05 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-216.messagelabs.com with SMTP; 10 May 2012 15:49:05 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q4AFn201001025; Thu, 10 May 2012 11:49:02 -0400 Message-ID: <4FABE36E.3030109@theshore.net> Date: Thu, 10 May 2012 11:49:02 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen devel References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> <4FA81669.5040202@theshore.net> <4FA82992.1030508@theshore.net> In-Reply-To: <4FA82992.1030508@theshore.net> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We've tried 3.3.5 along with disabling CONFIG_HUGETLB_PAGE (since it was potentially in the code path looking at the source) and we're still able to trigger the bug. Is there anything else we can try or more information we can provide that can help this along? Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:49:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15: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 ) id 1SSVc5-0005ZW-Hw; Thu, 10 May 2012 15:49:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVc4-0005Ys-9K for xen-devel@lists.xensource.com; Thu, 10 May 2012 15:49:08 +0000 Received: from [85.158.143.99:41271] by server-1.bemta-4.messagelabs.com id DC/83-20925-273EBAF4; Thu, 10 May 2012 15:49:06 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-15.tower-216.messagelabs.com!1336664944!27378961!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13281 invoked from network); 10 May 2012 15:49:05 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-15.tower-216.messagelabs.com with SMTP; 10 May 2012 15:49:05 -0000 Received: from beefcake.linlan (173-161-199-49-Philadelphia.hfc.comcastbusiness.net [173.161.199.49]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q4AFn201001025; Thu, 10 May 2012 11:49:02 -0400 Message-ID: <4FABE36E.3030109@theshore.net> Date: Thu, 10 May 2012 11:49:02 -0400 From: "Christopher S. Aker" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: xen devel References: <4FA7EBF6.6040204@theshore.net> <20120507171703.GA5746@phenom.dumpdata.com> <4FA81669.5040202@theshore.net> <4FA82992.1030508@theshore.net> In-Reply-To: <4FA82992.1030508@theshore.net> Cc: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We've tried 3.3.5 along with disabling CONFIG_HUGETLB_PAGE (since it was potentially in the code path looking at the source) and we're still able to trigger the bug. Is there anything else we can try or more information we can provide that can help this along? Thanks, -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:53:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:53:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVgF-00062s-O4; Thu, 10 May 2012 15:53:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVgD-00062l-TS for xen-devel@lists.xen.org; Thu, 10 May 2012 15:53:26 +0000 Received: from [85.158.143.99:64878] by server-2.bemta-4.messagelabs.com id 75/64-17550-474EBAF4; Thu, 10 May 2012 15:53:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336665203!27379729!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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31548 invoked from network); 10 May 2012 15:53:23 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:53:23 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:53:23 +0100 Message-Id: <4FAC00A90200007800082D42@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:53:45 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <20120510152844.GP26152@phenom.dumpdata.com> In-Reply-To: <20120510152844.GP26152@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] pvops domU guest booting problem - 131GB ok, 132GB not ok. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 17:28, Konrad Rzeszutek Wilk wrote: > I've just started to trying to track down why a pvops 64-bit > PV guest can't boot with more than 128GB of memory. The issue > I am seeing is that the module loading subsystem stops working and > I get this: > ... > - it is hitting some page tables that are used by the hypervisor? No, rather its own page tables. As soon as the initial mappings extends beyond MODULES_VADDR, you will run into problems if the initial page tables don't get cleaned up properly. I'd suppose that this is missing in your code (xen_setup_kernel_pagetable() just blindly copies over everything). > Was wondering if you had hit this at some point with SLES guests > and if there are any ideas of what I should look for ? Thanks! Yes, we certainly had to fix that. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 15:53:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 15:53:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVgF-00062s-O4; Thu, 10 May 2012 15:53:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVgD-00062l-TS for xen-devel@lists.xen.org; Thu, 10 May 2012 15:53:26 +0000 Received: from [85.158.143.99:64878] by server-2.bemta-4.messagelabs.com id 75/64-17550-474EBAF4; Thu, 10 May 2012 15:53:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336665203!27379729!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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31548 invoked from network); 10 May 2012 15:53:23 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 15:53:23 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 10 May 2012 16:53:23 +0100 Message-Id: <4FAC00A90200007800082D42@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 10 May 2012 16:53:45 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" References: <20120510152844.GP26152@phenom.dumpdata.com> In-Reply-To: <20120510152844.GP26152@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] pvops domU guest booting problem - 131GB ok, 132GB not ok. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 17:28, Konrad Rzeszutek Wilk wrote: > I've just started to trying to track down why a pvops 64-bit > PV guest can't boot with more than 128GB of memory. The issue > I am seeing is that the module loading subsystem stops working and > I get this: > ... > - it is hitting some page tables that are used by the hypervisor? No, rather its own page tables. As soon as the initial mappings extends beyond MODULES_VADDR, you will run into problems if the initial page tables don't get cleaned up properly. I'd suppose that this is missing in your code (xen_setup_kernel_pagetable() just blindly copies over everything). > Was wondering if you had hit this at some point with SLES guests > and if there are any ideas of what I should look for ? Thanks! Yes, we certainly had to fix that. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:03:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVq0-0006cn-1T; Thu, 10 May 2012 16:03:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVpz-0006cf-45 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:03:31 +0000 Received: from [85.158.143.99:43824] by server-3.bemta-4.messagelabs.com id 1E/FD-05853-2D6EBAF4; Thu, 10 May 2012 16:03:30 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336665809!22122970!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1392 invoked from network); 10 May 2012 16:03:30 -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; 10 May 2012 16:03:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12412450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:03:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:03:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVpw-0008DY-VA; Thu, 10 May 2012 16:03:29 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVpw-0007rO-T0; Thu, 10 May 2012 17:03:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.59088.884891.753666@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:03:28 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-2-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-2-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Jackson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec"): > + if (setenv(env[i], env[i+1], 1) < 0) { > + switch (errno) { > + case EINVAL: > + LOGEV(ERROR, errno, "invalid env variables (%s = %s)", > + env[i], env[i+1]); > + break; > + case ENOMEM: > + libxl__alloc_failed(CTX, __func__, 0, 0); > + } > + goto out; This silently exits if errno isn't one of the expected values. TBH I'm not sure you need to bother switching on errno here. Whatever the errno is we're going to log a message and exit nonzero, so you might as well simply LOGEV even in the ENOMEM case. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:03:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVq0-0006cn-1T; Thu, 10 May 2012 16:03:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVpz-0006cf-45 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:03:31 +0000 Received: from [85.158.143.99:43824] by server-3.bemta-4.messagelabs.com id 1E/FD-05853-2D6EBAF4; Thu, 10 May 2012 16:03:30 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336665809!22122970!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1392 invoked from network); 10 May 2012 16:03:30 -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; 10 May 2012 16:03:30 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12412450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:03:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:03:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVpw-0008DY-VA; Thu, 10 May 2012 16:03:29 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVpw-0007rO-T0; Thu, 10 May 2012 17:03:28 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.59088.884891.753666@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:03:28 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-2-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-2-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Jackson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 1/4] libxl: pass env vars to libxl__exec"): > + if (setenv(env[i], env[i+1], 1) < 0) { > + switch (errno) { > + case EINVAL: > + LOGEV(ERROR, errno, "invalid env variables (%s = %s)", > + env[i], env[i+1]); > + break; > + case ENOMEM: > + libxl__alloc_failed(CTX, __func__, 0, 0); > + } > + goto out; This silently exits if errno isn't one of the expected values. TBH I'm not sure you need to bother switching on errno here. Whatever the errno is we're going to log a message and exit nonzero, so you might as well simply LOGEV even in the ENOMEM case. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:04:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVqn-0006gW-FP; Thu, 10 May 2012 16:04:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVqm-0006gP-CQ for xen-devel@lists.xen.org; Thu, 10 May 2012 16:04:20 +0000 Received: from [85.158.138.51:23953] by server-4.bemta-3.messagelabs.com id 9F/1D-15341-307EBAF4; Thu, 10 May 2012 16:04:19 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-4.tower-174.messagelabs.com!1336665858!26347068!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDM0NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12880 invoked from network); 10 May 2012 16:04:18 -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; 10 May 2012 16:04:18 -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 8FDF92F72; Thu, 10 May 2012 19:03:37 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D38DB2005F; Thu, 10 May 2012 19:03:36 +0300 (EEST) Date: Thu, 10 May 2012 19:03:36 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120510160336.GJ2058@reaktio.net> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> <20120510143830.GH26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510143830.GH26152@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Ren, Yongjie" , "Wu, GabrielX" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 10:38:30AM -0400, Konrad Rzeszutek Wilk wrote: > > > > xen-changeset: 25256 > > > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > > > > > Please update your dom0. > > > > I think we can use 3.4-RCx kernel as dom0 when sending the report next time. > > Excellent! > > > > > > > > > ============================================================ > > > ===== > > > > > > > > New issue(1) > > > > ============== > > > > 1. cpu weight out of range error when create hvm domU > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > > > > > And what is the guest config? Does it have any cpu weights? > > > > Added the config in the BZ. It doesn't have any cpu weight in config. > > Some other person also reported this issue in the mailing list several days ago. > > I think some of the Citrix folks were going to take a look at this. > > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > > > 3. [VT-D]fail to detach NIC from guest > > > > > > Hmm, the last update is from a year ago. Are you sure this > > > is an issue? > > > > > Yeah, it still exist. It may be a similar issue with BZ# 1812. > > According to our recent testing, it something about VNC console. > > Also added some latest info in the BZ. > > > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > > > > > the bug talks about 2.6.32. Can you update it to include the > > > 3.4 (or 3.3) dmesg output? > > > > > This is about 32bit Xen. > > As we don't test 32bit Xen for a long time, we may update it when we're free. > > > > > > 5. [VT-D] device reset fail when create/destroy guest > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > > > > > Does this happen if you manually echo 1 > ../reset? And is this > > > an issue with the kernel if you upgrade it to 3.4-rc5? > > > > > When doing 'echo 1 >../reset', I get the same error as list in the BZ. > > "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". > > OK, so then the device can't do reset's properly. Is this the > physical adaptor or the virtual one? > > > This bug only exists when we use 'pcistub' to hide a device. > > Ok, so it looks like upstream Linux can't do this properly on that device. > > > > > > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > > > > > Where does it slow down? When bringing the NIC down or in specific > > > cases? > > > Is this an issue with if you are using a different guest (say Fedora Core 16?) > > > > > We found it is related to 'stdgva' option in guest config file. > > If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. > > If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. > > What does turning standard VGA and VNC on mean to the guest? Doesn't that mean > that the VGA adapter is gone from the guest? And is this issue only > present if you have PCI devices in the guest? Meaning do you get this > if you boot a normal HVM guest and do 'stdvga=0' and 'vnc='1? > stdvga=0 gives you the emulated Cirrus? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:04:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVqn-0006gW-FP; Thu, 10 May 2012 16:04:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVqm-0006gP-CQ for xen-devel@lists.xen.org; Thu, 10 May 2012 16:04:20 +0000 Received: from [85.158.138.51:23953] by server-4.bemta-3.messagelabs.com id 9F/1D-15341-307EBAF4; Thu, 10 May 2012 16:04:19 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-4.tower-174.messagelabs.com!1336665858!26347068!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDM0NTQ=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12880 invoked from network); 10 May 2012 16:04:18 -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; 10 May 2012 16:04:18 -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 8FDF92F72; Thu, 10 May 2012 19:03:37 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D38DB2005F; Thu, 10 May 2012 19:03:36 +0300 (EEST) Date: Thu, 10 May 2012 19:03:36 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Konrad Rzeszutek Wilk Message-ID: <20120510160336.GJ2058@reaktio.net> References: <40352EBA8B4DF841A9907B883F22B59B0FD2D31F@SHSMSX102.ccr.corp.intel.com> <20120504131244.GA26418@phenom.dumpdata.com> <1B4B44D9196EFF41AE41FDA404FC0A100BAEC9@SHSMSX101.ccr.corp.intel.com> <20120510143830.GH26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510143830.GH26152@phenom.dumpdata.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Ren, Yongjie" , "Wu, GabrielX" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] VMX status report. Xen:25256 & Dom0:d93dc5c... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 10:38:30AM -0400, Konrad Rzeszutek Wilk wrote: > > > > xen-changeset: 25256 > > > > Dom0: linux.git 3.1.0-rc7 (commit: d93dc5c...) > > > > > > Please update your dom0. > > > > I think we can use 3.4-RCx kernel as dom0 when sending the report next time. > > Excellent! > > > > > > > > > ============================================================ > > > ===== > > > > > > > > New issue(1) > > > > ============== > > > > 1. cpu weight out of range error when create hvm domU > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818 > > > > > > And what is the guest config? Does it have any cpu weights? > > > > Added the config in the BZ. It doesn't have any cpu weight in config. > > Some other person also reported this issue in the mailing list several days ago. > > I think some of the Citrix folks were going to take a look at this. > > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730 > > > > 3. [VT-D]fail to detach NIC from guest > > > > > > Hmm, the last update is from a year ago. Are you sure this > > > is an issue? > > > > > Yeah, it still exist. It may be a similar issue with BZ# 1812. > > According to our recent testing, it something about VNC console. > > Also added some latest info in the BZ. > > > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736 > > > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747 > > > > > > the bug talks about 2.6.32. Can you update it to include the > > > 3.4 (or 3.3) dmesg output? > > > > > This is about 32bit Xen. > > As we don't test 32bit Xen for a long time, we may update it when we're free. > > > > > > 5. [VT-D] device reset fail when create/destroy guest > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752 > > > > > > Does this happen if you manually echo 1 > ../reset? And is this > > > an issue with the kernel if you upgrade it to 3.4-rc5? > > > > > When doing 'echo 1 >../reset', I get the same error as list in the BZ. > > "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument". > > OK, so then the device can't do reset's properly. Is this the > physical adaptor or the virtual one? > > > This bug only exists when we use 'pcistub' to hide a device. > > Ok, so it looks like upstream Linux can't do this properly on that device. > > > > > > > 8. after detaching a VF from a guest, shutdown the guest is very slow > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812 > > > > > > Where does it slow down? When bringing the NIC down or in specific > > > cases? > > > Is this an issue with if you are using a different guest (say Fedora Core 16?) > > > > > We found it is related to 'stdgva' option in guest config file. > > If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown. > > If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow. > > What does turning standard VGA and VNC on mean to the guest? Doesn't that mean > that the VGA adapter is gone from the guest? And is this issue only > present if you have PCI devices in the guest? Meaning do you get this > if you boot a normal HVM guest and do 'stdvga=0' and 'vnc='1? > stdvga=0 gives you the emulated Cirrus? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:04:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:04:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVr4-0006iK-Rv; Thu, 10 May 2012 16:04:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVr3-0006i6-4C for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:04:37 +0000 Received: from [85.158.138.51:28189] by server-10.bemta-3.messagelabs.com id DD/AA-29478-417EBAF4; Thu, 10 May 2012 16:04:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336665874!24617563!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26156 invoked from network); 10 May 2012 16:04:35 -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; 10 May 2012 16:04:35 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AG3v8e012700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:03:58 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 q4AG3uXb018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:03:56 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 q4AG3tNx000440; Thu, 10 May 2012 11:03:56 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:03:55 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8FDA24032D; Thu, 10 May 2012 11:57:51 -0400 (EDT) Date: Thu, 10 May 2012 11:57:51 -0400 From: Konrad Rzeszutek Wilk To: Daniel Castro Message-ID: <20120510155751.GJ6389@phenom.dumpdata.com> References: <6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: James Harper , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, Apr 07, 2012 at 08:01:14PM +0900, Daniel Castro wrote: > Yes, out of sync, anyway... > = > On Fri, Mar 9, 2012 at 8:59 AM, James Harper > wrote: > >> Hello All, > >> > >> I have a little setback with the development of PV Drivers for Xen in = SeaBIOS. > >> The initialization code that runs in 32 Bit is working properly. > >> But, when the system tries to read on the disk I use the ring macros t= o get a > >> request. The macro usage looks like this: > >> struct blkif_ring * shared =3D memalign_low(4096,4096); //return > >> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So > >> far I have a pointer located at 0x0009a000 Under 32bit the struct is c= orrect > >> and all is working according to plan. > >> > >> But on 16bit operation read on disk I have struct blkfront_info * shar= ed_ring > >> =3D container_of(op->drive_g.info->shared)); // I get d630 I should ge= t it from > >> the correct segment, but how? > >> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be > >> something 0xa010 segment SS or something like that > > > > Just curios, does 16 bit include the required atomic instructions to ma= nipulate the 32 bit ring counters? Or are you manipulating the ring in 32 b= it mode and only accessing the requests already retrieved from the ring in = 16 bit mode? > This is my current problem, when I do > RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->priva= te->req_prod_pvt)); > The return address is incorrect, so I guess since inside the > RING_REQUEST MACRO I make memory access I will need to rewrite the > macro to include the SeaBios macros needed to address 32bit pointers > in 16bit mode. Which is /* Direct access to individual ring elements, by index. */ #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) ? I would try to not use macros at the start to unravel any complexity. Did GET_GLOBAL(blk_info->private) get you a valid pointer? If you do a hexdump of that area do you get what you expect? > > > >> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by ch= anging > >> the segment register, yet I do not know in what segment the ring is lo= cated, > >> and the macros are not applied inside the procedure of the macro, for > >> example: > >> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring)); > >> But this will change a 16Bit pointer of segment SS to a 32 bit segment= . There > >> is also the reverse but, again I do not know the segment in which I sh= ould > >> look for. Lastly the process inside the macro does not get this benefi= n, and I > >> do not know if the macro will work with a pointer of size 16bits. > >> > >> Any help will be GREATLY appreciated, I am almost done. > >> > > > > I'm not sure if this would be useful, but is there a way to hand over t= he ring to the OS PV drivers and avoid the teardown/setup? > This is before there is an OS. The bios handles the boot process, > right now I am trying to get the first read on the drive, the boot > sector. > > > > James > > > = > = > = > -- = > +-=3D=3D=3D=3D=3D---------------------------+ > | +---------------------------------+ | This space intentionally blank > for notetaking. > | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > | |=A0=A0 | Consultant/Programmer.| > | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | > +-------------------------------------+ > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:04:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:04:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVr4-0006iK-Rv; Thu, 10 May 2012 16:04:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVr3-0006i6-4C for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:04:37 +0000 Received: from [85.158.138.51:28189] by server-10.bemta-3.messagelabs.com id DD/AA-29478-417EBAF4; Thu, 10 May 2012 16:04:36 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336665874!24617563!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26156 invoked from network); 10 May 2012 16:04:35 -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; 10 May 2012 16:04:35 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AG3v8e012700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:03:58 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 q4AG3uXb018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:03:56 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 q4AG3tNx000440; Thu, 10 May 2012 11:03:56 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:03:55 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8FDA24032D; Thu, 10 May 2012 11:57:51 -0400 (EDT) Date: Thu, 10 May 2012 11:57:51 -0400 From: Konrad Rzeszutek Wilk To: Daniel Castro Message-ID: <20120510155751.GJ6389@phenom.dumpdata.com> References: <6035A0D088A63A46850C3988ED045A4B10A95EAB@BITCOM1.int.sbss.com.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: James Harper , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] Little help with Seabios PV-Drivers for XEN X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, Apr 07, 2012 at 08:01:14PM +0900, Daniel Castro wrote: > Yes, out of sync, anyway... > = > On Fri, Mar 9, 2012 at 8:59 AM, James Harper > wrote: > >> Hello All, > >> > >> I have a little setback with the development of PV Drivers for Xen in = SeaBIOS. > >> The initialization code that runs in 32 Bit is working properly. > >> But, when the system tries to read on the disk I use the ring macros t= o get a > >> request. The macro usage looks like this: > >> struct blkif_ring * shared =3D memalign_low(4096,4096); //return > >> 0x000fd630 this above 16bit address space SHARED_RING_INIT(shared); So > >> far I have a pointer located at 0x0009a000 Under 32bit the struct is c= orrect > >> and all is working according to plan. > >> > >> But on 16bit operation read on disk I have struct blkfront_info * shar= ed_ring > >> =3D container_of(op->drive_g.info->shared)); // I get d630 I should ge= t it from > >> the correct segment, but how? > >> RING_GET_REQUEST(shared_ring); //this returns 0xffff and should be > >> something 0xa010 segment SS or something like that > > > > Just curios, does 16 bit include the required atomic instructions to ma= nipulate the 32 bit ring counters? Or are you manipulating the ring in 32 b= it mode and only accessing the requests already retrieved from the ring in = 16 bit mode? > This is my current problem, when I do > RING_GET_REQUEST(GET_GLOBAL(blk_info->private),GET_GLOBAL(blk_info->priva= te->req_prod_pvt)); > The return address is incorrect, so I guess since inside the > RING_REQUEST MACRO I make memory access I will need to rewrite the > macro to include the SeaBios macros needed to address 32bit pointers > in 16bit mode. Which is /* Direct access to individual ring elements, by index. */ #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) ? I would try to not use macros at the start to unravel any complexity. Did GET_GLOBAL(blk_info->private) get you a valid pointer? If you do a hexdump of that area do you get what you expect? > > > >> SeaBios has some macros that convert a pointer in 32Bit to 16Bit by ch= anging > >> the segment register, yet I do not know in what segment the ring is lo= cated, > >> and the macros are not applied inside the procedure of the macro, for > >> example: > >> MAKE_FLATPTR(GET_SEG(SS),RING_GET_REQUEST(shared_ring)); > >> But this will change a 16Bit pointer of segment SS to a 32 bit segment= . There > >> is also the reverse but, again I do not know the segment in which I sh= ould > >> look for. Lastly the process inside the macro does not get this benefi= n, and I > >> do not know if the macro will work with a pointer of size 16bits. > >> > >> Any help will be GREATLY appreciated, I am almost done. > >> > > > > I'm not sure if this would be useful, but is there a way to hand over t= he ring to the OS PV drivers and avoid the teardown/setup? > This is before there is an OS. The bios handles the boot process, > right now I am trying to get the first read on the drive, the boot > sector. > > > > James > > > = > = > = > -- = > +-=3D=3D=3D=3D=3D---------------------------+ > | +---------------------------------+ | This space intentionally blank > for notetaking. > | |=A0=A0 | Daniel Castro,=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > | |=A0=A0 | Consultant/Programmer.| > | |=A0=A0 | U Andes=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | > +-------------------------------------+ > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:06:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSVsC-0006sp-Ez; Thu, 10 May 2012 16:05:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVsB-0006sb-B3 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:05:47 +0000 Received: from [85.158.143.35:33387] by server-3.bemta-4.messagelabs.com id 0C/C0-05853-A57EBAF4; Thu, 10 May 2012 16:05:46 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336665941!14806308!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13728 invoked from network); 10 May 2012 16:05:45 -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; 10 May 2012 16:05:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12412505" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 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; Thu, 10 May 2012 17:05:11 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVrb-0008EM-0Q; Thu, 10 May 2012 16:05:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVra-0007rf-Vo; Thu, 10 May 2012 17:05:10 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.59190.970887.861230@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:05:10 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-3-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-3-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup"): > Add a function which behaves like "xenstore-rm -t", and which will be > used to > clean xenstore after unplug since we will be no longer executing > xen-hotplug-cleanup script, that used to do that for us. I still think this needs to run in a transaction. Otherwise, if another xenstore user adds an entry to one of the directories we think is empty, we will unwittingly remove that entry. And in general it may be necessary to use the caller's transaction. So I would make libxl__xs_path_cleanup always require a non-null transaction to be passed in by the caller. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:06:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSVsC-0006sp-Ez; Thu, 10 May 2012 16:05:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSVsB-0006sb-B3 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:05:47 +0000 Received: from [85.158.143.35:33387] by server-3.bemta-4.messagelabs.com id 0C/C0-05853-A57EBAF4; Thu, 10 May 2012 16:05:46 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336665941!14806308!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13728 invoked from network); 10 May 2012 16:05:45 -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; 10 May 2012 16:05:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12412505" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 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; Thu, 10 May 2012 17:05:11 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSVrb-0008EM-0Q; Thu, 10 May 2012 16:05:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSVra-0007rf-Vo; Thu, 10 May 2012 17:05:10 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.59190.970887.861230@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:05:10 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-3-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-3-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 2/4] libxl: add libxl__xs_path_cleanup"): > Add a function which behaves like "xenstore-rm -t", and which will be > used to > clean xenstore after unplug since we will be no longer executing > xen-hotplug-cleanup script, that used to do that for us. I still think this needs to run in a transaction. Otherwise, if another xenstore user adds an entry to one of the directories we think is empty, we will unwittingly remove that entry. And in general it may be necessary to use the caller's transaction. So I would make libxl__xs_path_cleanup always require a non-null transaction to be passed in by the caller. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:20:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:20:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW5r-0007Qe-0o; Thu, 10 May 2012 16:19:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW5p-0007QZ-W4 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:19:54 +0000 Received: from [85.158.143.35:29748] by server-1.bemta-4.messagelabs.com id 5A/4D-20925-9AAEBAF4; Thu, 10 May 2012 16:19:53 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336666791!13583340!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3927 invoked from network); 10 May 2012 16:19:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 16:19:52 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AGImuJ001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:18:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AGIlPD022120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:18:47 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AGIjlA012929; Thu, 10 May 2012 11:18:46 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:18:44 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C55E24032D; Thu, 10 May 2012 12:12:40 -0400 (EDT) Date: Thu, 10 May 2012 12:12:40 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120510161240.GA3215@phenom.dumpdata.com> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, 2012 at 07:42:33PM +0100, Stefano Stabellini wrote: > On Tue, 8 May 2012, Stefano Stabellini wrote: > > I have been unable to reproduce this problem (I haven't given up yet) > > but I bet that the following patch fixes it: > > > > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > > index e3a9945..88e9304 100644 > > --- a/drivers/block/xen-blkfront.c > > +++ b/drivers/block/xen-blkfront.c > > @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) > > buffer_mfn, > > rq_data_dir(req)); > > > > - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > > + info->shadow[id].frame[i] = buffer_pfn; > > ring_req->u.rw.seg[i] = > > (struct blkif_request_segment) { > > .gref = ref, > > > > > > The idea is that the request contains a page for which > > > > pfn->mfn->pfn == 0xffffffffffffffff > > > > I am not sure exactly how it could be possible to get into this state in > > blkfront, I hope that some more tracing and code reading will be able to > > shed some lights on the issue. > > The one line patch fixes the issue: when using LVM in the guest the same > page can be used in two different requests (in blkif_queue_request) > before being unmapped. > The second time mfn_to_pfn is going to return ~0 because buffer_mfn has > the FOREIGN_FRAME_BIT set. > But actually we don't need to call mfn_to_pfn at all because we already > know the pfn value, that is stored in buffer_pfn. > > However the real problem remains at the time of blkif_completion: we > will remove the FOREIGN_FRAME_BIT before the other requests have been > completed. > > If sharing the same page twice (or more) is a normal condition then I > might have to revisit this patch completely and choose another > strategy... Ok, will wait for that and in the meantime drop the patch so I can send a git pull to Jens. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:20:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:20:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW5r-0007Qe-0o; Thu, 10 May 2012 16:19:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW5p-0007QZ-W4 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:19:54 +0000 Received: from [85.158.143.35:29748] by server-1.bemta-4.messagelabs.com id 5A/4D-20925-9AAEBAF4; Thu, 10 May 2012 16:19:53 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336666791!13583340!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3927 invoked from network); 10 May 2012 16:19:52 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 16:19:52 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AGImuJ001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:18:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AGIlPD022120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:18:47 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AGIjlA012929; Thu, 10 May 2012 11:18:46 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:18:44 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C55E24032D; Thu, 10 May 2012 12:12:40 -0400 (EDT) Date: Thu, 10 May 2012 12:12:40 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20120510161240.GA3215@phenom.dumpdata.com> References: <1334075119-25102-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120416195258.GA14982@phenom.dumpdata.com> <20120507212536.GA24344@andromeda.dapyr.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH v3] xen-blkfront: set pages are FOREIGN_FRAME when sharing them X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 09, 2012 at 07:42:33PM +0100, Stefano Stabellini wrote: > On Tue, 8 May 2012, Stefano Stabellini wrote: > > I have been unable to reproduce this problem (I haven't given up yet) > > but I bet that the following patch fixes it: > > > > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > > index e3a9945..88e9304 100644 > > --- a/drivers/block/xen-blkfront.c > > +++ b/drivers/block/xen-blkfront.c > > @@ -333,7 +333,7 @@ static int blkif_queue_request(struct request *req) > > buffer_mfn, > > rq_data_dir(req)); > > > > - info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn); > > + info->shadow[id].frame[i] = buffer_pfn; > > ring_req->u.rw.seg[i] = > > (struct blkif_request_segment) { > > .gref = ref, > > > > > > The idea is that the request contains a page for which > > > > pfn->mfn->pfn == 0xffffffffffffffff > > > > I am not sure exactly how it could be possible to get into this state in > > blkfront, I hope that some more tracing and code reading will be able to > > shed some lights on the issue. > > The one line patch fixes the issue: when using LVM in the guest the same > page can be used in two different requests (in blkif_queue_request) > before being unmapped. > The second time mfn_to_pfn is going to return ~0 because buffer_mfn has > the FOREIGN_FRAME_BIT set. > But actually we don't need to call mfn_to_pfn at all because we already > know the pfn value, that is stored in buffer_pfn. > > However the real problem remains at the time of blkif_completion: we > will remove the FOREIGN_FRAME_BIT before the other requests have been > completed. > > If sharing the same page twice (or more) is a normal condition then I > might have to revisit this patch completely and choose another > strategy... Ok, will wait for that and in the meantime drop the patch so I can send a git pull to Jens. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:22:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSW7l-0007Uz-Gy; Thu, 10 May 2012 16:21:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW7j-0007Uq-KU for xen-devel@lists.xen.org; Thu, 10 May 2012 16:21:51 +0000 Received: from [85.158.143.99:4730] by server-2.bemta-4.messagelabs.com id 20/E9-17550-E1BEBAF4; Thu, 10 May 2012 16:21:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336666907!26843970!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12729 invoked from network); 10 May 2012 16:21:49 -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; 10 May 2012 16:21:49 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AGLdY5004453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:21:40 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AGLclG027913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:21:39 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AGLbfN011481; Thu, 10 May 2012 11:21:37 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:21:37 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D1C5E4032D; Thu, 10 May 2012 12:15:33 -0400 (EDT) Date: Thu, 10 May 2012 12:15:33 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20120510161533.GC3215@phenom.dumpdata.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> <686683228.20120510161211@eikelenboom.it> <1336659417.14220.4.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336659417.14220.4.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: George Dunlap , Sander Eikelenboom , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > Fully hiding the device from dom0 drivers generally seems like it is > > > always better. That way the first driver to try and touch the hardware > > > is the one inside the domU. This avoids issues with dom0 drivers setting > > > stuff up but not tearing it down in a way that domU can cope with and > > > makes the use of hardware which doesn't support FLR more reliable etc. > > > > Haven't checked it (haven't got the time right now) but: > > Is using wildcards in the BDF's on the commandline supported already > > (like the ones supported in the config files for domains) > > Based on a quick scan of the code it doesn't appear so, I don't maintain > PCI backthough so there might be something in the pipeline. > > > I tend to have quite long commandlines to hide a pci-e card with 8 > > functions (needed to specify 8 BDF's seperatly) for pci passthrough, > > would be nice if one could just specify 09:00.* for example. > > It sounds useful to me. Patches are most welcome :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:22:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSW7l-0007Uz-Gy; Thu, 10 May 2012 16:21:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSW7j-0007Uq-KU for xen-devel@lists.xen.org; Thu, 10 May 2012 16:21:51 +0000 Received: from [85.158.143.99:4730] by server-2.bemta-4.messagelabs.com id 20/E9-17550-E1BEBAF4; Thu, 10 May 2012 16:21:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1336666907!26843970!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIyMjAy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12729 invoked from network); 10 May 2012 16:21:49 -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; 10 May 2012 16:21:49 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4AGLdY5004453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 16:21:40 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4AGLclG027913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 16:21:39 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4AGLbfN011481; Thu, 10 May 2012 11:21:37 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 09:21:37 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D1C5E4032D; Thu, 10 May 2012 12:15:33 -0400 (EDT) Date: Thu, 10 May 2012 12:15:33 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20120510161533.GC3215@phenom.dumpdata.com> References: <1336560543.25514.74.camel@zakaz.uk.xensource.com> <4FAA4F03.600@eu.citrix.com> <1336564773.25514.101.camel@zakaz.uk.xensource.com> <4FAA7504.5030103@eu.citrix.com> <1336646320.7098.62.camel@zakaz.uk.xensource.com> <686683228.20120510161211@eikelenboom.it> <1336659417.14220.4.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336659417.14220.4.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: George Dunlap , Sander Eikelenboom , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > Fully hiding the device from dom0 drivers generally seems like it is > > > always better. That way the first driver to try and touch the hardware > > > is the one inside the domU. This avoids issues with dom0 drivers setting > > > stuff up but not tearing it down in a way that domU can cope with and > > > makes the use of hardware which doesn't support FLR more reliable etc. > > > > Haven't checked it (haven't got the time right now) but: > > Is using wildcards in the BDF's on the commandline supported already > > (like the ones supported in the config files for domains) > > Based on a quick scan of the code it doesn't appear so, I don't maintain > PCI backthough so there might be something in the pipeline. > > > I tend to have quite long commandlines to hide a pci-e card with 8 > > functions (needed to specify 8 BDF's seperatly) for pci passthrough, > > would be nice if one could just specify 09:00.* for example. > > It sounds useful to me. Patches are most welcome :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:30:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWFz-0007iJ-Gc; Thu, 10 May 2012 16:30:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWFy-0007iE-PC for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:30:23 +0000 Received: from [85.158.138.51:30523] by server-11.bemta-3.messagelabs.com id A0/8A-18894-D1DEBAF4; Thu, 10 May 2012 16:30:21 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336667419!18443491!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23461 invoked from network); 10 May 2012 16:30:21 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 16:30:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25072731" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:30:19 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:30:18 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSWFu-0000OT-9T; Thu, 10 May 2012 17:30:18 +0100 Message-ID: <4FABECD3.7000401@eu.citrix.com> Date: Thu, 10 May 2012 17:29:07 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> <1336662282.14220.9.camel@zakaz.uk.xensource.com> In-Reply-To: <1336662282.14220.9.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gMTAvMDUvMTIgMTY6MDQsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+PiArICAgIHNwYXRoID0g bGlieGxfX3NwcmludGYoZ2MsIFNZU0ZTX1BDSV9ERVYiLyJQQ0lfQkRGIi9kcml2ZXIiLAo+Pj4+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBwY2lkZXYtPmRvbWFpbiwKPj4+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgcGNpZGV2LT5idXMsCj4+Pj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBjaWRldi0+ZGV2LAo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBw Y2lkZXYtPmZ1bmMpOwo+Pj4+ICsgICAgaWYgKCAhbHN0YXQoc3BhdGgsJnN0KSApIHsKPj4+PiAr ICAgICAgICAvKiBGaW5kIHRoZSBjYW5vbmljYWwgcGF0aCB0byB0aGUgZHJpdmVyLiAqLwo+Pj4+ ICsgICAgICAgICpkcCA9IGxpYnhsX196YWxsb2MoZ2MsIFBBVEhfTUFYKTsKPj4+IFNob3VsZCB3 ZSBiZSBhY3R1YWxseSB1c2luZyBmcGF0aGNvbmYgLyBzeXNjb25mIGhlcmU/Cj4+IEkgZG9uJ3Qg cmVhbGx5IGZvbGxvdy4gIFdoYXQgZXhhY3RseSBpcyBpdCB5b3UncmUgcHJvcG9zaW5nPwo+IFBB VEhfTUFYIGlzbid0IHJlYWxseSBhIGNvbnN0YW50IHRoZXNlIGRheXMsIHlvdSBjYW4gZ2V0IHRo ZSBkeW5hbWljCj4gdmFsdWUgZm9yIGEgcGFydGljdWxhciBmaWxlc3lzdGVtIGZyb20gZnBhdGhj b25mLiBJIGhvbmVzdGx5IGRvbid0IGtub3cKPiBob3cgbXVjaCBvZiBhIGNvbmNlcm4gdGhpcyBy ZWFsbHkgaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gd2UgYXJlIGFsd2F5cwo+IG5lY2Vzc2FyaWx5IHRh bGtpbmcgdG8gc3lzZnMuCkFoIHJpZ2h0IC0tIEkgZGlkbid0IGdldCB0aGF0IHlvdSB3ZXJlIHJl ZmVycmluZyB0byBQQVRIX01BWC4gIFRoZSAKInJlYWxwYXRoIiBtYW5wYWdlIHNwZWNpZmllczog ICAiVGhlIHJlc3VsdGluZyBwYXRo4oCQbmFtZSBpcyBzdG9yZWQgYXMgYSAKbnVsbC10ZXJtaW5h dGVkIHN0cmluZywgdXAgdG8gYSBtYXhpbXVtIG9mIFBBVEhfTUFYIGJ5dGVzLCBpbiB0aGUgYnVm ZmVyIApwb2ludGVkIHRvIGJ5IHJlc29sdmVkX3BhdGguIiAgVGhhdCdzIHdoeSBJIHVzZWQgUEFU SF9NQVggaW4gdGhlIAphbGxvY2F0aW9uLiAgSSB3b3VsZCBob3BlIHRoYXQgaWYgdGhlIG1hbnBh Z2Ugc2F5cyBQQVRIX01BWCwgaXQgbWVhbnMgClBBVEhfTUFYLCBhbmQgbm90ICJzb21lIG90aGVy IHRoaW5nIHdoaWNoIHlvdSBjYW4gZ2V0IGJ5IHJ1bm5pbmcgdGhpcyAKY29tcGxpY2F0ZWQgY29t bWFuZCBJIGhhdmVuJ3QgbWVudGlvbmVkIi4gOi0pCgpPSyAtLSBJJ3ZlIGFsc28gYWRkZWQgYSBj b21tZW50IGV4cGxhaW5pbmcgd2h5IEknbSBkb2luZyB3aGF0IEknbSBkb2luZyAKd2l0aCBzbG90 cywgd2hpY2ggSSdsbCBpbmNsdWRlIHdoZW4gSSByZS1wb3N0IHRoZSBwYXRjaC4KCiAgLUdlb3Jn ZQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 10 16:30:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWFz-0007iJ-Gc; Thu, 10 May 2012 16:30:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWFy-0007iE-PC for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:30:23 +0000 Received: from [85.158.138.51:30523] by server-11.bemta-3.messagelabs.com id A0/8A-18894-D1DEBAF4; Thu, 10 May 2012 16:30:21 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336667419!18443491!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQxNzM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23461 invoked from network); 10 May 2012 16:30:21 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 16:30:21 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="25072731" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 12:30:19 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 12:30:18 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSWFu-0000OT-9T; Thu, 10 May 2012 17:30:18 +0100 Message-ID: <4FABECD3.7000401@eu.citrix.com> Date: Thu, 10 May 2012 17:29:07 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> <1336662282.14220.9.camel@zakaz.uk.xensource.com> In-Reply-To: <1336662282.14220.9.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gMTAvMDUvMTIgMTY6MDQsIElhbiBDYW1wYmVsbCB3cm90ZToKPj4+PiArICAgIHNwYXRoID0g bGlieGxfX3NwcmludGYoZ2MsIFNZU0ZTX1BDSV9ERVYiLyJQQ0lfQkRGIi9kcml2ZXIiLAo+Pj4+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBwY2lkZXYtPmRvbWFpbiwKPj4+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgcGNpZGV2LT5idXMsCj4+Pj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBjaWRldi0+ZGV2LAo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBw Y2lkZXYtPmZ1bmMpOwo+Pj4+ICsgICAgaWYgKCAhbHN0YXQoc3BhdGgsJnN0KSApIHsKPj4+PiAr ICAgICAgICAvKiBGaW5kIHRoZSBjYW5vbmljYWwgcGF0aCB0byB0aGUgZHJpdmVyLiAqLwo+Pj4+ ICsgICAgICAgICpkcCA9IGxpYnhsX196YWxsb2MoZ2MsIFBBVEhfTUFYKTsKPj4+IFNob3VsZCB3 ZSBiZSBhY3R1YWxseSB1c2luZyBmcGF0aGNvbmYgLyBzeXNjb25mIGhlcmU/Cj4+IEkgZG9uJ3Qg cmVhbGx5IGZvbGxvdy4gIFdoYXQgZXhhY3RseSBpcyBpdCB5b3UncmUgcHJvcG9zaW5nPwo+IFBB VEhfTUFYIGlzbid0IHJlYWxseSBhIGNvbnN0YW50IHRoZXNlIGRheXMsIHlvdSBjYW4gZ2V0IHRo ZSBkeW5hbWljCj4gdmFsdWUgZm9yIGEgcGFydGljdWxhciBmaWxlc3lzdGVtIGZyb20gZnBhdGhj b25mLiBJIGhvbmVzdGx5IGRvbid0IGtub3cKPiBob3cgbXVjaCBvZiBhIGNvbmNlcm4gdGhpcyBy ZWFsbHkgaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gd2UgYXJlIGFsd2F5cwo+IG5lY2Vzc2FyaWx5IHRh bGtpbmcgdG8gc3lzZnMuCkFoIHJpZ2h0IC0tIEkgZGlkbid0IGdldCB0aGF0IHlvdSB3ZXJlIHJl ZmVycmluZyB0byBQQVRIX01BWC4gIFRoZSAKInJlYWxwYXRoIiBtYW5wYWdlIHNwZWNpZmllczog ICAiVGhlIHJlc3VsdGluZyBwYXRo4oCQbmFtZSBpcyBzdG9yZWQgYXMgYSAKbnVsbC10ZXJtaW5h dGVkIHN0cmluZywgdXAgdG8gYSBtYXhpbXVtIG9mIFBBVEhfTUFYIGJ5dGVzLCBpbiB0aGUgYnVm ZmVyIApwb2ludGVkIHRvIGJ5IHJlc29sdmVkX3BhdGguIiAgVGhhdCdzIHdoeSBJIHVzZWQgUEFU SF9NQVggaW4gdGhlIAphbGxvY2F0aW9uLiAgSSB3b3VsZCBob3BlIHRoYXQgaWYgdGhlIG1hbnBh Z2Ugc2F5cyBQQVRIX01BWCwgaXQgbWVhbnMgClBBVEhfTUFYLCBhbmQgbm90ICJzb21lIG90aGVy IHRoaW5nIHdoaWNoIHlvdSBjYW4gZ2V0IGJ5IHJ1bm5pbmcgdGhpcyAKY29tcGxpY2F0ZWQgY29t bWFuZCBJIGhhdmVuJ3QgbWVudGlvbmVkIi4gOi0pCgpPSyAtLSBJJ3ZlIGFsc28gYWRkZWQgYSBj b21tZW50IGV4cGxhaW5pbmcgd2h5IEknbSBkb2luZyB3aGF0IEknbSBkb2luZyAKd2l0aCBzbG90 cywgd2hpY2ggSSdsbCBpbmNsdWRlIHdoZW4gSSByZS1wb3N0IHRoZSBwYXRjaC4KCiAgLUdlb3Jn ZQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Thu May 10 16:31:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWGh-0007kp-Tr; Thu, 10 May 2012 16:31:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWGh-0007kf-4z for xen-devel@lists.xen.org; Thu, 10 May 2012 16:31:07 +0000 Received: from [193.109.254.147:23255] by server-5.bemta-14.messagelabs.com id 16/30-30733-A4DEBAF4; Thu, 10 May 2012 16:31:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336667459!8667113!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6678 invoked from network); 10 May 2012 16:31:00 -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; 10 May 2012 16:31:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413277" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:30:40 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:30:40 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWGF-0008Ns-VU; Thu, 10 May 2012 16:30:40 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWGF-0007u5-Ug; Thu, 10 May 2012 17:30:39 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60719.885071.452187@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:30:39 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-4-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-4-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd"): > This is a rather big change, that adds the necessary machinery to > perform hotplug script calling from libxl for Linux. This patch > launches the necessary scripts to attach and detach PHY and TAP > backend types (Qemu doesn't use hotplug scripts). Thanks. > -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*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}" > +SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}" Wouldn't it be better to have an env var set by libxl to mean "_not_ called from udev?". That would mean that if the udev rules weren't updated for some reason it would all still work. On many setups these are config files which may require the user to merge changes, etc., so this is a real concern. > +# Hack to prevent the execution of hotplug scripts from udev if the domain > +# has been launched from libxl > +if [ -n "${UDEV_CALL}" ] && \ > + `xenstore-read "libxl/disable_udev" >/dev/null 2>&1`; then This reads something from xenstore and executes it as a shell command! (Also it will go wrong if the value read is empty eg becaue the key doesn't exist.) Also didn't I say that in xenstore we normally record booleans as decimal integers, "0" for false and "1" for true ? > -} > +} > > -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid) > -{ > - GC_INIT(ctx); > - char *dom_path; > - char *vm_path; > - char *pid; > - int rc, dm_present; > +/* Callback for domain destruction */ The rest of this is very very difficult to review because of the amount of code motion, variable renaming, and so forth. Do you think it would be possible to reorganise things so that the diff is as minimal as possible ? Techniques you will probably find useful include: * Declare some convenience variables such as uint32_t const domid = dis->domid; This is best done near the top of each function along with the new function prototype etc., so it doesn't introduce a mid-function patch hunk. This will avoid irrelevant noise in the diff caused by the movement of state into the operation state struct. * Declare callback functions at the top of the file so that they can appear after the point where they are referenced, and write all the code in the order in which it actually occurs. This is useful anyway, but it probably means that the code won't need to move because it's probably already in that order. If it isn't you may need to move it about separately. * In general, avoid moving any code if at all possible in the main patch. If you need to move code, do it in a pre- or post-patch. * Only take the opportunity to make unrelated changes (eg, changing from libxl__sprintf to GCSPRINTF) if you have to make another change to the very same line of code. * If any code motion is needed, split it out into a pre-patch which contains only code motion. * Be prepared to leave wrinkles in the code style or layout and fix them up in a later patch. * If it is necessary to switch a variable from a "struct foo" to a "struct foo*", split out a separate pre-patch which changes it to a "struct foo[1]". This separate patch will then obviously have no functional change and wiull simply contain a lot of removing of "&" etc. The actual patch with the meat can leave all those references unchanged. * Likewise if you want to change something from a "struct foo*" to a "struct foo" you can do the reverse: in your main patch change it to "struct foo[1]" instead. Then, you can add a post-patch to fix that up by changing "struct foo[1]" to "struct foo" which again will have no functional change. You will see me applying these techniques in my recent child process series; I can point you at specific commits etc. if you want more hints. Of course this may not be feasible. If for some parts of the code this approach is not feasible, and the result is always going to look like a rewrite, mention in the commit message that such-and-such function(s) or parts of code have essentially been rewritten. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:31:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWGh-0007kp-Tr; Thu, 10 May 2012 16:31:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWGh-0007kf-4z for xen-devel@lists.xen.org; Thu, 10 May 2012 16:31:07 +0000 Received: from [193.109.254.147:23255] by server-5.bemta-14.messagelabs.com id 16/30-30733-A4DEBAF4; Thu, 10 May 2012 16:31:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336667459!8667113!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6678 invoked from network); 10 May 2012 16:31:00 -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; 10 May 2012 16:31:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413277" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:30:40 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:30:40 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWGF-0008Ns-VU; Thu, 10 May 2012 16:30:40 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWGF-0007u5-Ug; Thu, 10 May 2012 17:30:39 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60719.885071.452187@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:30:39 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336649312-11198-4-git-send-email-roger.pau@citrix.com> References: <1336649312-11198-1-git-send-email-roger.pau@citrix.com> <1336649312-11198-4-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v4 3/4] libxl: call hotplug scripts from libxl for vbd"): > This is a rather big change, that adds the necessary machinery to > perform hotplug script calling from libxl for Linux. This patch > launches the necessary scripts to attach and detach PHY and TAP > backend types (Qemu doesn't use hotplug scripts). Thanks. > -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*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/blktap $env{ACTION}" > +SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ENV{UDEV_CALL}="1", RUN+="/etc/xen/scripts/block $env{ACTION}" Wouldn't it be better to have an env var set by libxl to mean "_not_ called from udev?". That would mean that if the udev rules weren't updated for some reason it would all still work. On many setups these are config files which may require the user to merge changes, etc., so this is a real concern. > +# Hack to prevent the execution of hotplug scripts from udev if the domain > +# has been launched from libxl > +if [ -n "${UDEV_CALL}" ] && \ > + `xenstore-read "libxl/disable_udev" >/dev/null 2>&1`; then This reads something from xenstore and executes it as a shell command! (Also it will go wrong if the value read is empty eg becaue the key doesn't exist.) Also didn't I say that in xenstore we normally record booleans as decimal integers, "0" for false and "1" for true ? > -} > +} > > -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid) > -{ > - GC_INIT(ctx); > - char *dom_path; > - char *vm_path; > - char *pid; > - int rc, dm_present; > +/* Callback for domain destruction */ The rest of this is very very difficult to review because of the amount of code motion, variable renaming, and so forth. Do you think it would be possible to reorganise things so that the diff is as minimal as possible ? Techniques you will probably find useful include: * Declare some convenience variables such as uint32_t const domid = dis->domid; This is best done near the top of each function along with the new function prototype etc., so it doesn't introduce a mid-function patch hunk. This will avoid irrelevant noise in the diff caused by the movement of state into the operation state struct. * Declare callback functions at the top of the file so that they can appear after the point where they are referenced, and write all the code in the order in which it actually occurs. This is useful anyway, but it probably means that the code won't need to move because it's probably already in that order. If it isn't you may need to move it about separately. * In general, avoid moving any code if at all possible in the main patch. If you need to move code, do it in a pre- or post-patch. * Only take the opportunity to make unrelated changes (eg, changing from libxl__sprintf to GCSPRINTF) if you have to make another change to the very same line of code. * If any code motion is needed, split it out into a pre-patch which contains only code motion. * Be prepared to leave wrinkles in the code style or layout and fix them up in a later patch. * If it is necessary to switch a variable from a "struct foo" to a "struct foo*", split out a separate pre-patch which changes it to a "struct foo[1]". This separate patch will then obviously have no functional change and wiull simply contain a lot of removing of "&" etc. The actual patch with the meat can leave all those references unchanged. * Likewise if you want to change something from a "struct foo*" to a "struct foo" you can do the reverse: in your main patch change it to "struct foo[1]" instead. Then, you can add a post-patch to fix that up by changing "struct foo[1]" to "struct foo" which again will have no functional change. You will see me applying these techniques in my recent child process series; I can point you at specific commits etc. if you want more hints. Of course this may not be feasible. If for some parts of the code this approach is not feasible, and the result is always going to look like a rewrite, mention in the commit message that such-and-such function(s) or parts of code have essentially been rewritten. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:34:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWK9-0007xu-I0; Thu, 10 May 2012 16:34:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWK8-0007xk-0p for xen-devel@lists.xen.org; Thu, 10 May 2012 16:34:40 +0000 Received: from [85.158.143.99:40817] by server-3.bemta-4.messagelabs.com id FE/B1-05853-F1EEBAF4; Thu, 10 May 2012 16:34:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336667677!20375897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6492 invoked from network); 10 May 2012 16:34:38 -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; 10 May 2012 16:34:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413344" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:34: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, 10 May 2012 17:34:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWK4-0008PQ-6q; Thu, 10 May 2012 16:34:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWK4-0007wf-69; Thu, 10 May 2012 17:34:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60956.170569.592055@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:34:36 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> References: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call"): > Currently we only pass script=no to Qemu, to avoid calling any scripts when > attaching a tap interface, but we should also pass downscript=no to avoid Qemu > trying to execute a script when disconnecting the interface. This prevents the > following harmless error message: Acked and applied both, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:34:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWK9-0007xu-I0; Thu, 10 May 2012 16:34:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWK8-0007xk-0p for xen-devel@lists.xen.org; Thu, 10 May 2012 16:34:40 +0000 Received: from [85.158.143.99:40817] by server-3.bemta-4.messagelabs.com id FE/B1-05853-F1EEBAF4; Thu, 10 May 2012 16:34:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336667677!20375897!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6492 invoked from network); 10 May 2012 16:34:38 -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; 10 May 2012 16:34:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413344" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:34: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, 10 May 2012 17:34:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWK4-0008PQ-6q; Thu, 10 May 2012 16:34:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWK4-0007wf-69; Thu, 10 May 2012 17:34:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60956.170569.592055@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:34:36 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> References: <1336652343-12279-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] libxl: add "downscript=no" to Qemu call"): > Currently we only pass script=no to Qemu, to avoid calling any scripts when > attaching a tap interface, but we should also pass downscript=no to avoid Qemu > trying to execute a script when disconnecting the interface. This prevents the > following harmless error message: Acked and applied both, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:35:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:35:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWKR-0007ze-Ua; Thu, 10 May 2012 16:34:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWKQ-0007zG-LU for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:34:58 +0000 Received: from [85.158.143.35:28265] by server-3.bemta-4.messagelabs.com id CB/02-05853-13EEBAF4; Thu, 10 May 2012 16:34:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336667696!10456856!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5445 invoked from network); 10 May 2012 16:34: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; 10 May 2012 16:34:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413347" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:34:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:34:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWKN-0008Pb-Tu; Thu, 10 May 2012 16:34:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWKN-0007wj-TB; Thu, 10 May 2012 17:34:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60975.888286.338290@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:34:55 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: <77ed22f4b55b4528d71e.1336146061@probook.site> References: <77ed22f4b55b4528d71e.1336146061@probook.site> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule"): > tools/vtpm_manager: add missing DESTDIR to install rule Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:35:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:35:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWKR-0007ze-Ua; Thu, 10 May 2012 16:34:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWKQ-0007zG-LU for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:34:58 +0000 Received: from [85.158.143.35:28265] by server-3.bemta-4.messagelabs.com id CB/02-05853-13EEBAF4; Thu, 10 May 2012 16:34:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1336667696!10456856!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5445 invoked from network); 10 May 2012 16:34: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; 10 May 2012 16:34:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413347" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:34:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:34:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWKN-0008Pb-Tu; Thu, 10 May 2012 16:34:55 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWKN-0007wj-TB; Thu, 10 May 2012 17:34:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.60975.888286.338290@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:34:55 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: <77ed22f4b55b4528d71e.1336146061@probook.site> References: <77ed22f4b55b4528d71e.1336146061@probook.site> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm_manager: add missing DESTDIR to install rule"): > tools/vtpm_manager: add missing DESTDIR to install rule Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:36:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWLO-00088L-Hc; Thu, 10 May 2012 16:35:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLN-00088B-85 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:35:57 +0000 Received: from [85.158.143.35:39169] by server-1.bemta-4.messagelabs.com id 99/7D-20925-C6EEBAF4; Thu, 10 May 2012 16:35:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336667755!12306587!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8519 invoked from network); 10 May 2012 16:35:55 -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; 10 May 2012 16:35:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413366" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16: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; Thu, 10 May 2012 17:35:54 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWLK-0008Py-Ow; Thu, 10 May 2012 16:35:54 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWLK-0007wu-O5; Thu, 10 May 2012 17:35:54 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61034.710697.730395@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:35:54 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: <9a430b7e2df2893f7f4f.1336153114@probook.site> References: <9a430b7e2df2893f7f4f.1336153114@probook.site> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains"): > tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:36:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWLO-00088L-Hc; Thu, 10 May 2012 16:35:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLN-00088B-85 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:35:57 +0000 Received: from [85.158.143.35:39169] by server-1.bemta-4.messagelabs.com id 99/7D-20925-C6EEBAF4; Thu, 10 May 2012 16:35:56 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336667755!12306587!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8519 invoked from network); 10 May 2012 16:35:55 -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; 10 May 2012 16:35:55 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413366" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16: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; Thu, 10 May 2012 17:35:54 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWLK-0008Py-Ow; Thu, 10 May 2012 16:35:54 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWLK-0007wu-O5; Thu, 10 May 2012 17:35:54 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61034.710697.730395@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:35:54 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: <9a430b7e2df2893f7f4f.1336153114@probook.site> References: <9a430b7e2df2893f7f4f.1336153114@probook.site> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains"): > tools/hotplug: remove 4 from default runlevel in xen-watchdog, xend and xendomains Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:36:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:36:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLS-00089I-UD; Thu, 10 May 2012 16:36:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLR-00088B-P6 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:36:01 +0000 Received: from [85.158.143.35:30996] by server-1.bemta-4.messagelabs.com id 0D/8D-20925-17EEBAF4; Thu, 10 May 2012 16:36:01 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336667755!12306587!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8624 invoked from network); 10 May 2012 16:36:00 -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; 10 May 2012 16:36:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413370" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:36:00 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:36:00 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWLQ-0008Q2-As; Thu, 10 May 2012 16:36:00 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWLQ-0007wy-AC; Thu, 10 May 2012 17:36:00 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61040.302603.309980@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:36:00 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, Ross Philipson Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"): > tools/vtpm: use LDLIBS to pass -lgmp Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:36:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:36:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLS-00089I-UD; Thu, 10 May 2012 16:36:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWLR-00088B-P6 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:36:01 +0000 Received: from [85.158.143.35:30996] by server-1.bemta-4.messagelabs.com id 0D/8D-20925-17EEBAF4; Thu, 10 May 2012 16:36:01 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336667755!12306587!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8624 invoked from network); 10 May 2012 16:36:00 -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; 10 May 2012 16:36:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413370" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:36:00 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:36:00 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWLQ-0008Q2-As; Thu, 10 May 2012 16:36:00 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWLQ-0007wy-AC; Thu, 10 May 2012 17:36:00 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61040.302603.309980@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:36:00 +0100 To: Olaf Hering Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com, Ross Philipson Subject: Re: [Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Olaf Hering writes ("[Xen-devel] [PATCH] tools/vtpm: use LDLIBS to pass -lgmp"): > tools/vtpm: use LDLIBS to pass -lgmp Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:38:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWO2-00006x-Hy; Thu, 10 May 2012 16:38:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWO0-00006h-9X for xen-devel@lists.xen.org; Thu, 10 May 2012 16:38:40 +0000 Received: from [193.109.254.147:62822] by server-3.bemta-14.messagelabs.com id AE/FB-23274-F0FEBAF4; Thu, 10 May 2012 16:38:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336667917!2974925!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20608 invoked from network); 10 May 2012 16:38: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; 10 May 2012 16:38:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413422" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:38: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, 10 May 2012 17:38:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWNx-0008Qs-7Z; Thu, 10 May 2012 16:38:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWNx-0007xG-6W; Thu, 10 May 2012 17:38:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61197.187421.725113@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:38:37 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> References: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations."): > Also move the functions to libxl_device.c, as done with disk and nic > add fuctions, so libxl_device_{vkb,vfb}_add are mere wrappers arround > libxl__device_{vkb,vfb}_add, that can be called from a running AO > operation. Quite a lot of code motion here also, and integration with > the new AO domain creation. > > This should be applied after my "libxl: call hotplug scripts from > libxl for vif" series. Can you please (a) add it to the end of your series and (b) separate out the code motion ? As it is it is difficult to review. As a guideline, I would recommend trying to actually read the patch, by eye, before you post it. If you find you can't make head or tail of it then probably we won't be able to either :-). Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:38:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWO2-00006x-Hy; Thu, 10 May 2012 16:38:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWO0-00006h-9X for xen-devel@lists.xen.org; Thu, 10 May 2012 16:38:40 +0000 Received: from [193.109.254.147:62822] by server-3.bemta-14.messagelabs.com id AE/FB-23274-F0FEBAF4; Thu, 10 May 2012 16:38:39 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336667917!2974925!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20608 invoked from network); 10 May 2012 16:38: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; 10 May 2012 16:38:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413422" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:38: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, 10 May 2012 17:38:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWNx-0008Qs-7Z; Thu, 10 May 2012 16:38:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWNx-0007xG-6W; Thu, 10 May 2012 17:38:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61197.187421.725113@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:38:37 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> References: <1336652920-12358-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: make libxl_device_{vkb, vfb}_add async operations."): > Also move the functions to libxl_device.c, as done with disk and nic > add fuctions, so libxl_device_{vkb,vfb}_add are mere wrappers arround > libxl__device_{vkb,vfb}_add, that can be called from a running AO > operation. Quite a lot of code motion here also, and integration with > the new AO domain creation. > > This should be applied after my "libxl: call hotplug scripts from > libxl for vif" series. Can you please (a) add it to the end of your series and (b) separate out the code motion ? As it is it is difficult to review. As a guideline, I would recommend trying to actually read the patch, by eye, before you post it. If you find you can't make head or tail of it then probably we won't be able to either :-). Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:41:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:41:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWQV-0000KN-3h; Thu, 10 May 2012 16:41:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWQU-0000KG-F6 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:41:14 +0000 Received: from [193.109.254.147:52095] by server-6.bemta-14.messagelabs.com id EC/48-04960-9AFEBAF4; Thu, 10 May 2012 16:41:13 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336668072!8652123!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25997 invoked from network); 10 May 2012 16:41:13 -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; 10 May 2012 16:41:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:41:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:41:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWQH-0008Re-Qz; Thu, 10 May 2012 16:41:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWQH-0007xf-Q4; Thu, 10 May 2012 17:41:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61341.793000.935045@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:41:01 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> References: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script"): > This script is a copy from the QEMU one, wich is itself a copy from > the Linux kernel one (as far as I can tell). > > This script will only check for parts of the patches that touch libxl > files, and I've adapted it to match our CODING_STYLE a little bit, > major differences include the following: Thanks. I'm not going to review the actual Perl code here :-) but I might try it out on some examples. But shouldn't this go in tools/libxl ? I think trying to have a single checkpatch for the whole tree is doomed and the clone and hack is acceptable here I think. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:41:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:41:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWQV-0000KN-3h; Thu, 10 May 2012 16:41:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWQU-0000KG-F6 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:41:14 +0000 Received: from [193.109.254.147:52095] by server-6.bemta-14.messagelabs.com id EC/48-04960-9AFEBAF4; Thu, 10 May 2012 16:41:13 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336668072!8652123!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25997 invoked from network); 10 May 2012 16:41:13 -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; 10 May 2012 16:41:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413450" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:41:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 17:41:02 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWQH-0008Re-Qz; Thu, 10 May 2012 16:41:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWQH-0007xf-Q4; Thu, 10 May 2012 17:41:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61341.793000.935045@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:41:01 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> References: <1336654013-12457-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH RFC] scripts: add checkpatch.pl script"): > This script is a copy from the QEMU one, wich is itself a copy from > the Linux kernel one (as far as I can tell). > > This script will only check for parts of the patches that touch libxl > files, and I've adapted it to match our CODING_STYLE a little bit, > major differences include the following: Thanks. I'm not going to review the actual Perl code here :-) but I might try it out on some examples. But shouldn't this go in tools/libxl ? I think trying to have a single checkpatch for the whole tree is doomed and the clone and hack is acceptable here I think. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWRy-0000Qi-Pp; Thu, 10 May 2012 16:42:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWRx-0000Q9-Ls for xen-devel@lists.xen.org; Thu, 10 May 2012 16:42:45 +0000 Received: from [85.158.139.83:3202] by server-9.bemta-5.messagelabs.com id 3C/BF-09826-400FBAF4; Thu, 10 May 2012 16:42:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336668162!27720018!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23788 invoked from network); 10 May 2012 16:42: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; 10 May 2012 16:42:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:42: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, 10 May 2012 17:42:42 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWRt-0008S8-R6; Thu, 10 May 2012 16:42:41 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWRt-0007xz-QI; Thu, 10 May 2012 17:42:41 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61441.798609.813385@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:42:41 +0100 To: lars.kurth@xen.org Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Lars Kurth writes ("[Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance"): > Timetable: > > 1) Open review with feedback until 11th May (a bit more than a week from > today) > > 2) Lars to incorporate any feedback and publish a revision. > > 3) Lars to set up a private poll via a form, the week of May 14th which > will be open for a week. Community members that can vote are maintainers > (including committers and maintainers)of any mature project in Xen (aka > Xen and XCP). Thanks for taking the lead on this Lars. The changes look sensible and uncontroversial to me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:42:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16: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 ) id 1SSWRy-0000Qi-Pp; Thu, 10 May 2012 16:42:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWRx-0000Q9-Ls for xen-devel@lists.xen.org; Thu, 10 May 2012 16:42:45 +0000 Received: from [85.158.139.83:3202] by server-9.bemta-5.messagelabs.com id 3C/BF-09826-400FBAF4; Thu, 10 May 2012 16:42:44 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1336668162!27720018!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23788 invoked from network); 10 May 2012 16:42: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; 10 May 2012 16:42:43 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:42: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, 10 May 2012 17:42:42 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWRt-0008S8-R6; Thu, 10 May 2012 16:42:41 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWRt-0007xz-QI; Thu, 10 May 2012 17:42:41 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.61441.798609.813385@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:42:41 +0100 To: lars.kurth@xen.org Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Lars Kurth writes ("[Xen-devel] [Proposal] Minor additions and clarification to Xen Project Governance"): > Timetable: > > 1) Open review with feedback until 11th May (a bit more than a week from > today) > > 2) Lars to incorporate any feedback and publish a revision. > > 3) Lars to set up a private poll via a form, the week of May 14th which > will be open for a week. Community members that can vote are maintainers > (including committers and maintainers)of any mature project in Xen (aka > Xen and XCP). Thanks for taking the lead on this Lars. The changes look sensible and uncontroversial to me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:46:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSWVG-0000il-DS; Thu, 10 May 2012 16:46:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWVE-0000ia-Jh for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:46:08 +0000 Received: from [85.158.143.35:33131] by server-1.bemta-4.messagelabs.com id A9/B7-20925-FC0FBAF4; Thu, 10 May 2012 16:46:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336668366!12307775!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5966 invoked from network); 10 May 2012 16:46:06 -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; 10 May 2012 16:46:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413532" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:45: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, 10 May 2012 17:45:53 +0100 Message-ID: <1336668352.14220.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 17:45:52 +0100 In-Reply-To: <4FABECD3.7000401@eu.citrix.com> References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> <1336662282.14220.9.camel@zakaz.uk.xensource.com> <4FABECD3.7000401@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCAyMDEyLTA1LTEwIGF0IDE3OjI5ICswMTAwLCBHZW9yZ2UgRHVubGFwIHdyb3RlOgo+ IE9uIDEwLzA1LzEyIDE2OjA0LCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPj4+PiArICAgIHNwYXRo ID0gbGlieGxfX3NwcmludGYoZ2MsIFNZU0ZTX1BDSV9ERVYiLyJQQ0lfQkRGIi9kcml2ZXIiLAo+ ID4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaWRldi0+ZG9tYWluLAo+ID4+Pj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaWRldi0+YnVzLAo+ID4+Pj4gKyAgICAgICAg ICAgICAgICAgICAgICAgICAgIHBjaWRldi0+ZGV2LAo+ID4+Pj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBjaWRldi0+ZnVuYyk7Cj4gPj4+PiArICAgIGlmICggIWxzdGF0KHNwYXRoLCZz dCkgKSB7Cj4gPj4+PiArICAgICAgICAvKiBGaW5kIHRoZSBjYW5vbmljYWwgcGF0aCB0byB0aGUg ZHJpdmVyLiAqLwo+ID4+Pj4gKyAgICAgICAgKmRwID0gbGlieGxfX3phbGxvYyhnYywgUEFUSF9N QVgpOwo+ID4+PiBTaG91bGQgd2UgYmUgYWN0dWFsbHkgdXNpbmcgZnBhdGhjb25mIC8gc3lzY29u ZiBoZXJlPwo+ID4+IEkgZG9uJ3QgcmVhbGx5IGZvbGxvdy4gIFdoYXQgZXhhY3RseSBpcyBpdCB5 b3UncmUgcHJvcG9zaW5nPwo+ID4gUEFUSF9NQVggaXNuJ3QgcmVhbGx5IGEgY29uc3RhbnQgdGhl c2UgZGF5cywgeW91IGNhbiBnZXQgdGhlIGR5bmFtaWMKPiA+IHZhbHVlIGZvciBhIHBhcnRpY3Vs YXIgZmlsZXN5c3RlbSBmcm9tIGZwYXRoY29uZi4gSSBob25lc3RseSBkb24ndCBrbm93Cj4gPiBo b3cgbXVjaCBvZiBhIGNvbmNlcm4gdGhpcyByZWFsbHkgaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gd2Ug YXJlIGFsd2F5cwo+ID4gbmVjZXNzYXJpbHkgdGFsa2luZyB0byBzeXNmcy4KPiBBaCByaWdodCAt LSBJIGRpZG4ndCBnZXQgdGhhdCB5b3Ugd2VyZSByZWZlcnJpbmcgdG8gUEFUSF9NQVguICBUaGUg Cj4gInJlYWxwYXRoIiBtYW5wYWdlIHNwZWNpZmllczogICAiVGhlIHJlc3VsdGluZyBwYXRo4oCQ bmFtZSBpcyBzdG9yZWQgYXMgYSAKPiBudWxsLXRlcm1pbmF0ZWQgc3RyaW5nLCB1cCB0byBhIG1h eGltdW0gb2YgUEFUSF9NQVggYnl0ZXMsIGluIHRoZSBidWZmZXIgCj4gcG9pbnRlZCB0byBieSBy ZXNvbHZlZF9wYXRoLiIgIFRoYXQncyB3aHkgSSB1c2VkIFBBVEhfTUFYIGluIHRoZSAKPiBhbGxv Y2F0aW9uLiAgSSB3b3VsZCBob3BlIHRoYXQgaWYgdGhlIG1hbnBhZ2Ugc2F5cyBQQVRIX01BWCwg aXQgbWVhbnMgCj4gUEFUSF9NQVgsIGFuZCBub3QgInNvbWUgb3RoZXIgdGhpbmcgd2hpY2ggeW91 IGNhbiBnZXQgYnkgcnVubmluZyB0aGlzIAo+IGNvbXBsaWNhdGVkIGNvbW1hbmQgSSBoYXZlbid0 IG1lbnRpb25lZCIuIDotKQoKWWVzLCB0aGF0J3MgZmFpciA7LSkKCkkgdGhpbmsgdGhlIGlzc3Vl IG1pZ2h0IGJlIHRoYXQgc29tZSBzeXN0ZW1zIGRlY2xhcmUgUEFUSF9NQVggdG8gYmUKZW5vcm1v dXMgKHRvIGNvdmVyIGFsbCBiYXNlcykgYW5kIHN5c2NvbmYgbGV0cyB5b3UgdXNlIHNvbWV0aGlu ZyBtb3JlCnJlYWxpc3RpYy9yZWxldmFudCB0byB0aGUgYWN0dWFsIHNpdHVhdGlvbi4KCkxvb2tz IGxpa2Ugb24gTGludXggaXQgaXMgNDA5Niwgd2hpY2ggSSBndWVzcyBpcyBvay4KCj4gT0sgLS0g SSd2ZSBhbHNvIGFkZGVkIGEgY29tbWVudCBleHBsYWluaW5nIHdoeSBJJ20gZG9pbmcgd2hhdCBJ J20gZG9pbmcgCj4gd2l0aCBzbG90cywgd2hpY2ggSSdsbCBpbmNsdWRlIHdoZW4gSSByZS1wb3N0 IHRoZSBwYXRjaC4KClRhIQoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54 ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Thu May 10 16:46:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 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 ) id 1SSWVG-0000il-DS; Thu, 10 May 2012 16:46:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWVE-0000ia-Jh for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:46:08 +0000 Received: from [85.158.143.35:33131] by server-1.bemta-4.messagelabs.com id A9/B7-20925-FC0FBAF4; Thu, 10 May 2012 16:46:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1336668366!12307775!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5966 invoked from network); 10 May 2012 16:46:06 -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; 10 May 2012 16:46:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413532" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:45: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, 10 May 2012 17:45:53 +0100 Message-ID: <1336668352.14220.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Thu, 10 May 2012 17:45:52 +0100 In-Reply-To: <4FABECD3.7000401@eu.citrix.com> References: <17a5b562d1e79d094c58.1336559323@kodo2> <1336648786.7098.89.camel@zakaz.uk.xensource.com> <4FABD6EF.4020607@eu.citrix.com> <1336662282.14220.9.camel@zakaz.uk.xensource.com> <4FABECD3.7000401@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 3 of 4] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCAyMDEyLTA1LTEwIGF0IDE3OjI5ICswMTAwLCBHZW9yZ2UgRHVubGFwIHdyb3RlOgo+ IE9uIDEwLzA1LzEyIDE2OjA0LCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPj4+PiArICAgIHNwYXRo ID0gbGlieGxfX3NwcmludGYoZ2MsIFNZU0ZTX1BDSV9ERVYiLyJQQ0lfQkRGIi9kcml2ZXIiLAo+ ID4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaWRldi0+ZG9tYWluLAo+ID4+Pj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBjaWRldi0+YnVzLAo+ID4+Pj4gKyAgICAgICAg ICAgICAgICAgICAgICAgICAgIHBjaWRldi0+ZGV2LAo+ID4+Pj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBjaWRldi0+ZnVuYyk7Cj4gPj4+PiArICAgIGlmICggIWxzdGF0KHNwYXRoLCZz dCkgKSB7Cj4gPj4+PiArICAgICAgICAvKiBGaW5kIHRoZSBjYW5vbmljYWwgcGF0aCB0byB0aGUg ZHJpdmVyLiAqLwo+ID4+Pj4gKyAgICAgICAgKmRwID0gbGlieGxfX3phbGxvYyhnYywgUEFUSF9N QVgpOwo+ID4+PiBTaG91bGQgd2UgYmUgYWN0dWFsbHkgdXNpbmcgZnBhdGhjb25mIC8gc3lzY29u ZiBoZXJlPwo+ID4+IEkgZG9uJ3QgcmVhbGx5IGZvbGxvdy4gIFdoYXQgZXhhY3RseSBpcyBpdCB5 b3UncmUgcHJvcG9zaW5nPwo+ID4gUEFUSF9NQVggaXNuJ3QgcmVhbGx5IGEgY29uc3RhbnQgdGhl c2UgZGF5cywgeW91IGNhbiBnZXQgdGhlIGR5bmFtaWMKPiA+IHZhbHVlIGZvciBhIHBhcnRpY3Vs YXIgZmlsZXN5c3RlbSBmcm9tIGZwYXRoY29uZi4gSSBob25lc3RseSBkb24ndCBrbm93Cj4gPiBo b3cgbXVjaCBvZiBhIGNvbmNlcm4gdGhpcyByZWFsbHkgaXMsIGVzcGVjaWFsbHkgZ2l2ZW4gd2Ug YXJlIGFsd2F5cwo+ID4gbmVjZXNzYXJpbHkgdGFsa2luZyB0byBzeXNmcy4KPiBBaCByaWdodCAt LSBJIGRpZG4ndCBnZXQgdGhhdCB5b3Ugd2VyZSByZWZlcnJpbmcgdG8gUEFUSF9NQVguICBUaGUg Cj4gInJlYWxwYXRoIiBtYW5wYWdlIHNwZWNpZmllczogICAiVGhlIHJlc3VsdGluZyBwYXRo4oCQ bmFtZSBpcyBzdG9yZWQgYXMgYSAKPiBudWxsLXRlcm1pbmF0ZWQgc3RyaW5nLCB1cCB0byBhIG1h eGltdW0gb2YgUEFUSF9NQVggYnl0ZXMsIGluIHRoZSBidWZmZXIgCj4gcG9pbnRlZCB0byBieSBy ZXNvbHZlZF9wYXRoLiIgIFRoYXQncyB3aHkgSSB1c2VkIFBBVEhfTUFYIGluIHRoZSAKPiBhbGxv Y2F0aW9uLiAgSSB3b3VsZCBob3BlIHRoYXQgaWYgdGhlIG1hbnBhZ2Ugc2F5cyBQQVRIX01BWCwg aXQgbWVhbnMgCj4gUEFUSF9NQVgsIGFuZCBub3QgInNvbWUgb3RoZXIgdGhpbmcgd2hpY2ggeW91 IGNhbiBnZXQgYnkgcnVubmluZyB0aGlzIAo+IGNvbXBsaWNhdGVkIGNvbW1hbmQgSSBoYXZlbid0 IG1lbnRpb25lZCIuIDotKQoKWWVzLCB0aGF0J3MgZmFpciA7LSkKCkkgdGhpbmsgdGhlIGlzc3Vl IG1pZ2h0IGJlIHRoYXQgc29tZSBzeXN0ZW1zIGRlY2xhcmUgUEFUSF9NQVggdG8gYmUKZW5vcm1v dXMgKHRvIGNvdmVyIGFsbCBiYXNlcykgYW5kIHN5c2NvbmYgbGV0cyB5b3UgdXNlIHNvbWV0aGlu ZyBtb3JlCnJlYWxpc3RpYy9yZWxldmFudCB0byB0aGUgYWN0dWFsIHNpdHVhdGlvbi4KCkxvb2tz IGxpa2Ugb24gTGludXggaXQgaXMgNDA5Niwgd2hpY2ggSSBndWVzcyBpcyBvay4KCj4gT0sgLS0g SSd2ZSBhbHNvIGFkZGVkIGEgY29tbWVudCBleHBsYWluaW5nIHdoeSBJJ20gZG9pbmcgd2hhdCBJ J20gZG9pbmcgCj4gd2l0aCBzbG90cywgd2hpY2ggSSdsbCBpbmNsdWRlIHdoZW4gSSByZS1wb3N0 IHRoZSBwYXRjaC4KClRhIQoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54 ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Thu May 10 16:53:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:53:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWc5-0000tI-9S; Thu, 10 May 2012 16:53:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWc3-0000tA-R1 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:53:12 +0000 Received: from [85.158.143.99:7825] by server-1.bemta-4.messagelabs.com id E8/AF-20925-772FBAF4; Thu, 10 May 2012 16:53:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336668790!22159809!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7627 invoked from network); 10 May 2012 16:53: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; 10 May 2012 16:53:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:53: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, 10 May 2012 17:53:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWc1-0008Vg-KC; Thu, 10 May 2012 16:53:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWc1-0007z3-JA; Thu, 10 May 2012 17:53:09 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62069.578209.953705@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:53:09 +0100 To: "Zhang, Yang Z" Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhang, Yang Z writes ("[Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > libxl: allow to set more than 31 vcpus > > In current implementation, it uses integer for record current avail cpus and this only allows user to specify 31 vcpus. > In following patch, it uses cpumap instead interger which make more sense than before. Also there is no limit to the max vcpus. ... > - if (!b_info->cur_vcpus) > - b_info->cur_vcpus = 1; > + if (!b_info->avail_vcpus.size) { > + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) > + return ERROR_NOMEM; > + libxl_cpumap_set(&b_info->avail_vcpus, 0); > + } This error handling should really go away. Would you be able to provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? That never fails, so that would also mean libxl_cpumap_alloc can't fail. > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dm.c > --- a/tools/libxl/libxl_dm.c Thu Apr 12 14:01:27 2012 +0100 > +++ b/tools/libxl/libxl_dm.c Fri May 04 10:47:00 2012 +0800 > @@ -200,10 +200,35 @@ static char ** libxl__build_device_model > libxl__sprintf(gc, "%d", b_info->max_vcpus), > NULL); > } > - if (b_info->cur_vcpus) { > + if (b_info->avail_vcpus.size) { > + int i, nr_set_cpus = 0; > + char *s; > + > + libxl_for_each_set_cpu(i, > + ((libxl_domain_build_info *)b_info)->avail_vcpus) > + nr_set_cpus++; > + > + s = (char *)malloc((nr_set_cpus + 3) / 4 + 1); > + > + memset(s + ((nr_set_cpus % 4) ? 1 : 0), 'f', nr_set_cpus / 4); > + switch (nr_set_cpus % 4) { > + case 1: > + s[0] = '1'; > + break; > + case 2: > + s[0] = '3'; > + break; > + case 3: > + s[0] = '7'; > + break; > + } > + > + s[(nr_set_cpus + 3) / 4] = '\0'; This is an arbitrary precision conversion to hex. Wouldn't it be better to provide libxl_cpumap_set_all, and libxl_cpumap_hexmask or something ? > @@ -437,11 +462,16 @@ static char ** libxl__build_device_model > } > if (b_info->max_vcpus > 1) { > flexarray_append(dm_args, "-smp"); > - if (b_info->cur_vcpus) > + if (b_info->avail_vcpus.size) { > + int i, nr_set_cpus = 0; > + libxl_for_each_set_cpu(i, > + ((libxl_domain_build_info *)b_info)->avail_vcpus) > + nr_set_cpus++; If we had libxl_cpumap_count_set this would be clearer. > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > for (i = 0; i < info->max_vcpus; i++) { > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i))) > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > + && !libxl_cpumap_test(&info->avail_vcpus, i)) > ? "offline" : "online"; If libxl_cpumap_test returned 0 if cpumap==NULL then this would be simpler. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:53:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:53:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWc5-0000tI-9S; Thu, 10 May 2012 16:53:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWc3-0000tA-R1 for xen-devel@lists.xensource.com; Thu, 10 May 2012 16:53:12 +0000 Received: from [85.158.143.99:7825] by server-1.bemta-4.messagelabs.com id E8/AF-20925-772FBAF4; Thu, 10 May 2012 16:53:11 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336668790!22159809!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7627 invoked from network); 10 May 2012 16:53: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; 10 May 2012 16:53:10 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16:53: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, 10 May 2012 17:53:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWc1-0008Vg-KC; Thu, 10 May 2012 16:53:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWc1-0007z3-JA; Thu, 10 May 2012 17:53:09 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62069.578209.953705@mariner.uk.xensource.com> Date: Thu, 10 May 2012 17:53:09 +0100 To: "Zhang, Yang Z" Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhang, Yang Z writes ("[Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > libxl: allow to set more than 31 vcpus > > In current implementation, it uses integer for record current avail cpus and this only allows user to specify 31 vcpus. > In following patch, it uses cpumap instead interger which make more sense than before. Also there is no limit to the max vcpus. ... > - if (!b_info->cur_vcpus) > - b_info->cur_vcpus = 1; > + if (!b_info->avail_vcpus.size) { > + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) > + return ERROR_NOMEM; > + libxl_cpumap_set(&b_info->avail_vcpus, 0); > + } This error handling should really go away. Would you be able to provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? That never fails, so that would also mean libxl_cpumap_alloc can't fail. > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dm.c > --- a/tools/libxl/libxl_dm.c Thu Apr 12 14:01:27 2012 +0100 > +++ b/tools/libxl/libxl_dm.c Fri May 04 10:47:00 2012 +0800 > @@ -200,10 +200,35 @@ static char ** libxl__build_device_model > libxl__sprintf(gc, "%d", b_info->max_vcpus), > NULL); > } > - if (b_info->cur_vcpus) { > + if (b_info->avail_vcpus.size) { > + int i, nr_set_cpus = 0; > + char *s; > + > + libxl_for_each_set_cpu(i, > + ((libxl_domain_build_info *)b_info)->avail_vcpus) > + nr_set_cpus++; > + > + s = (char *)malloc((nr_set_cpus + 3) / 4 + 1); > + > + memset(s + ((nr_set_cpus % 4) ? 1 : 0), 'f', nr_set_cpus / 4); > + switch (nr_set_cpus % 4) { > + case 1: > + s[0] = '1'; > + break; > + case 2: > + s[0] = '3'; > + break; > + case 3: > + s[0] = '7'; > + break; > + } > + > + s[(nr_set_cpus + 3) / 4] = '\0'; This is an arbitrary precision conversion to hex. Wouldn't it be better to provide libxl_cpumap_set_all, and libxl_cpumap_hexmask or something ? > @@ -437,11 +462,16 @@ static char ** libxl__build_device_model > } > if (b_info->max_vcpus > 1) { > flexarray_append(dm_args, "-smp"); > - if (b_info->cur_vcpus) > + if (b_info->avail_vcpus.size) { > + int i, nr_set_cpus = 0; > + libxl_for_each_set_cpu(i, > + ((libxl_domain_build_info *)b_info)->avail_vcpus) > + nr_set_cpus++; If we had libxl_cpumap_count_set this would be clearer. > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > for (i = 0; i < info->max_vcpus; i++) { > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i))) > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > + && !libxl_cpumap_test(&info->avail_vcpus, i)) > ? "offline" : "online"; If libxl_cpumap_test returned 0 if cpumap==NULL then this would be simpler. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:56:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:56:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWfM-0000zk-Sq; Thu, 10 May 2012 16:56:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWfL-0000zZ-G6 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:56:35 +0000 Received: from [85.158.138.51:27890] by server-3.bemta-3.messagelabs.com id C4/D5-04048-243FBAF4; Thu, 10 May 2012 16:56:34 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336668993!18447669!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30215 invoked from network); 10 May 2012 16:56:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 16:56:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413676" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16: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; Thu, 10 May 2012 17:56:33 +0100 Date: Thu, 10 May 2012 17:56:17 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jean Guyader In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jean Guyader wrote: > After a host sleep MSI will be off on the host but qemu still thinks > it's on because of some state that have been set previously. > > If qemu thinks that the device has been configure already > and the host MSI are disabled tell Xen to reconfigure the MSI. > > Signed-off-by: Jean Guyader > > > diff --git a/hw/pass-through.c b/hw/pass-through.c > index f832c5a..5c32a2e 100644 > --- a/hw/pass-through.c > +++ b/hw/pass-through.c > @@ -3772,6 +3772,21 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev, > return 0; > } > > +static int msi_is_enable(struct pt_dev *dev) > +{ > + uint16_t val = 0; > + uint32_t address = 0; > + if (!dev->msi) > + return 0; > + > + address = dev->msi->ctrl_offset; > + if (!address) > + return 0; > + > + val = pci_read_word(dev->pci_dev, address); > + return val & PCI_MSI_FLAGS_ENABLE; > +} > + > /* write Message Control register */ > static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > struct pt_reg_tbl *cfg_entry, > @@ -3835,6 +3850,14 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > ptdev->msi->flags &= ~MSI_FLAG_UNINIT; > ptdev->msi->flags |= PT_MSI_MAPPED; > } > + else > + { > + if (!msi_is_enable(ptdev)) > + { > + pt_msi_setup(ptdev); > + pt_msi_update(ptdev); > + } > + } > ptdev->msi->flags |= PCI_MSI_FLAGS_ENABLE; > } > else Would it make sense to replace the condition above: if (ptdev->msi->flags & MSI_FLAG_UNINIT) with the new condition you wrote? if (!msi_is_enable(ptdev)) It seems more reliable to me. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 16:56:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 16:56:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWfM-0000zk-Sq; Thu, 10 May 2012 16:56:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWfL-0000zZ-G6 for xen-devel@lists.xen.org; Thu, 10 May 2012 16:56:35 +0000 Received: from [85.158.138.51:27890] by server-3.bemta-3.messagelabs.com id C4/D5-04048-243FBAF4; Thu, 10 May 2012 16:56:34 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336668993!18447669!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30215 invoked from network); 10 May 2012 16:56:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 16:56:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413676" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 16: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; Thu, 10 May 2012 17:56:33 +0100 Date: Thu, 10 May 2012 17:56:17 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jean Guyader In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jean Guyader wrote: > After a host sleep MSI will be off on the host but qemu still thinks > it's on because of some state that have been set previously. > > If qemu thinks that the device has been configure already > and the host MSI are disabled tell Xen to reconfigure the MSI. > > Signed-off-by: Jean Guyader > > > diff --git a/hw/pass-through.c b/hw/pass-through.c > index f832c5a..5c32a2e 100644 > --- a/hw/pass-through.c > +++ b/hw/pass-through.c > @@ -3772,6 +3772,21 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev, > return 0; > } > > +static int msi_is_enable(struct pt_dev *dev) > +{ > + uint16_t val = 0; > + uint32_t address = 0; > + if (!dev->msi) > + return 0; > + > + address = dev->msi->ctrl_offset; > + if (!address) > + return 0; > + > + val = pci_read_word(dev->pci_dev, address); > + return val & PCI_MSI_FLAGS_ENABLE; > +} > + > /* write Message Control register */ > static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > struct pt_reg_tbl *cfg_entry, > @@ -3835,6 +3850,14 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > ptdev->msi->flags &= ~MSI_FLAG_UNINIT; > ptdev->msi->flags |= PT_MSI_MAPPED; > } > + else > + { > + if (!msi_is_enable(ptdev)) > + { > + pt_msi_setup(ptdev); > + pt_msi_update(ptdev); > + } > + } > ptdev->msi->flags |= PCI_MSI_FLAGS_ENABLE; > } > else Would it make sense to replace the condition above: if (ptdev->msi->flags & MSI_FLAG_UNINIT) with the new condition you wrote? if (!msi_is_enable(ptdev)) It seems more reliable to me. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:02:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17:02:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWlB-0001Eb-Qf; Thu, 10 May 2012 17:02:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWl9-0001EW-PR for xen-devel@lists.xensource.com; Thu, 10 May 2012 17:02:36 +0000 Received: from [85.158.139.83:10011] by server-1.bemta-5.messagelabs.com id C4/8A-28458-BA4FBAF4; Thu, 10 May 2012 17:02:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336669354!28035001!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21955 invoked from network); 10 May 2012 17:02: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; 10 May 2012 17:02:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413780" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:02:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 18:02:32 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWl6-00006m-Ma; Thu, 10 May 2012 17:02:32 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWl6-000803-Ld; Thu, 10 May 2012 18:02:32 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62632.654951.334814@mariner.uk.xensource.com> Date: Thu, 10 May 2012 18:02:32 +0100 To: Bamvor Jian Zhang Newsgroups: chiark.mail.xen.devel In-Reply-To: <4a6043e1434a458506c3.1335626069@linux-bhi8.site> References: <4a6043e1434a458506c3.1335626069@linux-bhi8.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] [mq]: patch_libxl_get_console_tty.diff X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bamvor Jian Zhang writes ("[Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff"): > diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.c > --- a/tools/libxl/libxl.c Fri Apr 27 17:57:55 2012 +0200 > +++ b/tools/libxl/libxl.c Sat Apr 28 22:36:56 2012 +0800 > @@ -15,6 +15,8 @@ > */ > > #include "libxl_osdeps.h" > +//#include "libxl_osdeps.h" > +//#include "libxl_osdeps.h" Thanks for posting this but was int actually inteded for inclusion in the tree ? If so we need a commit message and a Signed-off-by and so forth. Also we may be too late for 4.2 considering the feature freeze. > +int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path) > +{ We already have various functions to refer to and open consoles, which have much of this functionality in them already. That shouldn't be duplicated. Also we need to make a policy decision about whether the fact that the console looks like a tty is a part of the API. > +/* libxl_get_console_tty get the tty path from xenstore according to the > + * domain id. > + */ > +int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path); In any case the doc comment should not mention xenstore. It should also document the memory allocation behaviour. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:02:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17:02:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWlB-0001Eb-Qf; Thu, 10 May 2012 17:02:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWl9-0001EW-PR for xen-devel@lists.xensource.com; Thu, 10 May 2012 17:02:36 +0000 Received: from [85.158.139.83:10011] by server-1.bemta-5.messagelabs.com id C4/8A-28458-BA4FBAF4; Thu, 10 May 2012 17:02:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336669354!28035001!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21955 invoked from network); 10 May 2012 17:02: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; 10 May 2012 17:02:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413780" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:02:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 18:02:32 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWl6-00006m-Ma; Thu, 10 May 2012 17:02:32 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWl6-000803-Ld; Thu, 10 May 2012 18:02:32 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62632.654951.334814@mariner.uk.xensource.com> Date: Thu, 10 May 2012 18:02:32 +0100 To: Bamvor Jian Zhang Newsgroups: chiark.mail.xen.devel In-Reply-To: <4a6043e1434a458506c3.1335626069@linux-bhi8.site> References: <4a6043e1434a458506c3.1335626069@linux-bhi8.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] [mq]: patch_libxl_get_console_tty.diff X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bamvor Jian Zhang writes ("[Xen-devel] [PATCH] [mq]: patch_libxl_get_console_tty.diff"): > diff -r 9dda0efd8ce1 -r 4a6043e1434a tools/libxl/libxl.c > --- a/tools/libxl/libxl.c Fri Apr 27 17:57:55 2012 +0200 > +++ b/tools/libxl/libxl.c Sat Apr 28 22:36:56 2012 +0800 > @@ -15,6 +15,8 @@ > */ > > #include "libxl_osdeps.h" > +//#include "libxl_osdeps.h" > +//#include "libxl_osdeps.h" Thanks for posting this but was int actually inteded for inclusion in the tree ? If so we need a commit message and a Signed-off-by and so forth. Also we may be too late for 4.2 considering the feature freeze. > +int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path) > +{ We already have various functions to refer to and open consoles, which have much of this functionality in them already. That shouldn't be duplicated. Also we need to make a policy decision about whether the fact that the console looks like a tty is a part of the API. > +/* libxl_get_console_tty get the tty path from xenstore according to the > + * domain id. > + */ > +int libxl_get_console_tty(libxl_ctx *ctx, uint32_t domid, char **path); In any case the doc comment should not mention xenstore. It should also document the memory allocation behaviour. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17: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 ) id 1SSWmN-0001IG-8z; Thu, 10 May 2012 17:03:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWmL-0001I9-L7 for xen-devel@lists.xen.org; Thu, 10 May 2012 17:03:49 +0000 Received: from [85.158.143.35:7078] by server-2.bemta-4.messagelabs.com id 90/D4-17550-5F4FBAF4; Thu, 10 May 2012 17:03:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336669428!15503668!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10090 invoked from network); 10 May 2012 17:03:48 -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 May 2012 17:03:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413795" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:03: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; Thu, 10 May 2012 18:03:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWmJ-00007Q-Oa; Thu, 10 May 2012 17:03:47 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWmJ-00081D-Nl; Thu, 10 May 2012 18:03:47 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62707.712989.84155@mariner.uk.xensource.com> Date: Thu, 10 May 2012 18:03:47 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335518995.28015.186.camel@zakaz.uk.xensource.com> References: <95424045.BJ4a0xs4Vr@amur> <1335518995.28015.186.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Dietmar Hahn , xen-devel Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to xen-command-line.markdown X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: add vpmu description to xen-command-line.markdown"): > On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote: > > # HG changeset patch > > # User Dietmar Hahn > > # Date 1335517766 -7200 > > # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565 > > # Parent 107285938c50f82667bd4d014820b439a077c22c > > > > Add a short description to the vpmu boot option in the > > xen-command-line.markdown > > > > > > Signed-off-by: Dietmar Hahn > > Acked-by: Ian Campbell Thanks, Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17: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 ) id 1SSWmN-0001IG-8z; Thu, 10 May 2012 17:03:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWmL-0001I9-L7 for xen-devel@lists.xen.org; Thu, 10 May 2012 17:03:49 +0000 Received: from [85.158.143.35:7078] by server-2.bemta-4.messagelabs.com id 90/D4-17550-5F4FBAF4; Thu, 10 May 2012 17:03:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336669428!15503668!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10090 invoked from network); 10 May 2012 17:03:48 -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 May 2012 17:03:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12413795" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:03: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; Thu, 10 May 2012 18:03:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSWmJ-00007Q-Oa; Thu, 10 May 2012 17:03:47 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSWmJ-00081D-Nl; Thu, 10 May 2012 18:03:47 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20395.62707.712989.84155@mariner.uk.xensource.com> Date: Thu, 10 May 2012 18:03:47 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335518995.28015.186.camel@zakaz.uk.xensource.com> References: <95424045.BJ4a0xs4Vr@amur> <1335518995.28015.186.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Dietmar Hahn , xen-devel Subject: Re: [Xen-devel] [PATCH] docs: add vpmu description to xen-command-line.markdown X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: add vpmu description to xen-command-line.markdown"): > On Fri, 2012-04-27 at 10:20 +0100, Dietmar Hahn wrote: > > # HG changeset patch > > # User Dietmar Hahn > > # Date 1335517766 -7200 > > # Node ID 9ba4e4a5f3b1b7dad77e2801afc0253d6d30d565 > > # Parent 107285938c50f82667bd4d014820b439a077c22c > > > > Add a short description to the vpmu boot option in the > > xen-command-line.markdown > > > > > > Signed-off-by: Dietmar Hahn > > Acked-by: Ian Campbell Thanks, Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:25:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17:25:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSX7H-0001dl-8b; Thu, 10 May 2012 17:25:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSX7F-0001dg-HF for xen-devel@lists.xensource.com; Thu, 10 May 2012 17:25:25 +0000 Received: from [85.158.138.51:30502] by server-7.bemta-3.messagelabs.com id D3/5E-03078-40AFBAF4; Thu, 10 May 2012 17:25:24 +0000 X-Env-Sender: malcolm.crossley@citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336670723!22359384!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11155 invoked from network); 10 May 2012 17:25:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 17:25:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12414066" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:25:23 +0000 Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 18:25:23 +0100 MIME-Version: 1.0 X-Mercurial-Node: a909ee6d97995abda9201e55c14d9216b0438ec0 Message-ID: User-Agent: Mercurial-patchbomb/2.2.1 Date: Thu, 10 May 2012 18:25:17 +0100 From: Malcolm Crossley To: xen-devel@lists.xensource.com Cc: keir@xen.org Subject: [Xen-devel] [PATCH] [RFC] Xen: Spread boot time page scrubbing across all available CPU's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The page scrubbing is done in 256MB chunks in lockstep across all the CPU's. This allows for the boot CPU to hold the heap_lock whilst each chunk is being scrubbed and then release the heap_lock when all CPU's are finished scrubing their individual chunk. This allows for the heap_lock to not be held continously and for pending softirqs are to be serviced periodically across all CPU's. The page scrub memory chunks are allocated to the CPU's in a NUMA aware fashion to reduce Socket interconnect overhead and improve performance. This patch reduces the boot page scrub time on a 256GB 16 core AMD Opteron machine from 1 minute 46 seconds to 38 seconds. diff -r 8a86d841e6d4 -r a909ee6d9799 xen/common/page_alloc.c --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -89,6 +89,15 @@ static struct bootmem_region { } *__initdata bootmem_region_list; static unsigned int __initdata nr_bootmem_regions; +static atomic_t __initdata bootscrub_count = ATOMIC_INIT(0); + +struct scrub_region { + unsigned long offset; + unsigned long start; + unsigned long chunk_size; + unsigned long cpu_block_size; +}; + static void __init boot_bug(int line) { panic("Boot BUG at %s:%d\n", __FILE__, line); @@ -1090,28 +1099,43 @@ void __init end_boot_allocator(void) printk("\n"); } -/* - * Scrub all unallocated pages in all heap zones. This function is more - * convoluted than appears necessary because we do not want to continuously - * hold the lock while scrubbing very large memory areas. - */ -void __init scrub_heap_pages(void) +void __init smp_scrub_heap_pages(void *data) { unsigned long mfn; struct page_info *pg; + unsigned long start_mfn, end_mfn; + struct scrub_region *region = (struct scrub_region *) data; + int temp_cpu, local_node, local_cpu_index; - if ( !opt_bootscrub ) - return; + ASSERT(region != NULL); - printk("Scrubbing Free RAM: "); + /* Determine the current CPU's index into all this Node's CPU's*/ + local_node = cpu_to_node(smp_processor_id()); + local_cpu_index = 0; + for_each_cpu(temp_cpu, &node_to_cpumask(local_node)) + { + if(smp_processor_id() == temp_cpu) + break; + local_cpu_index++; + } - for ( mfn = first_valid_mfn; mfn < max_page; mfn++ ) + /* Calculate the starting mfn for this CPU's memory block */ + start_mfn = region->start + (region->cpu_block_size * local_cpu_index) + + region->offset; + + /* Calculate the end mfn into this CPU's memory block for this iteration */ + if ( ( region->offset + region->chunk_size ) > region->cpu_block_size ) + end_mfn = region->start + (region->cpu_block_size * local_cpu_index) + + region->cpu_block_size; + else + end_mfn = start_mfn + region->chunk_size; + + + for ( mfn = start_mfn; mfn < end_mfn; mfn++ ) { - process_pending_softirqs(); - pg = mfn_to_page(mfn); - /* Quick lock-free check. */ + /* Check the mfn is valid and page is free. */ if ( !mfn_valid(mfn) || !page_state_is(pg, free) ) continue; @@ -1119,11 +1143,82 @@ void __init scrub_heap_pages(void) if ( (mfn % ((100*1024*1024)/PAGE_SIZE)) == 0 ) printk("."); + /* Do the scrub if possible */ + if ( page_state_is(pg, free) ) + scrub_one_page(pg); + } + /* Increment count to indicate scrubbing complete on this CPU */ + atomic_inc(&bootscrub_count); +} + +/* + * Scrub all unallocated pages in all heap zones. This function uses all + * online cpu's to scrub the memory in parallel. + */ +void __init scrub_heap_pages(void) +{ + cpumask_t node_cpus; + unsigned int i; + struct scrub_region region[MAX_NUMNODES]; + unsigned long mfn_off, chunk_size, max_cpu_blk_size, mem_start, mem_end; + + if ( !opt_bootscrub ) + return; + + printk("Scrubbing Free RAM: "); + + /* Scrub block size */ + chunk_size = (256*1024*1024/PAGE_SIZE); + + max_cpu_blk_size = 0; + /* Determine the amount of memory to scrub, per CPU on each Node */ + for_each_online_node ( i ) + { + /* Calculate Node memory start and end address */ + mem_start = max(node_start_pfn(i), first_valid_mfn); + mem_end = min(mem_start + node_spanned_pages(i), max_page); + node_cpus = node_to_cpumask(i); + /* Divide by number of CPU's for this node */ + region[i].cpu_block_size = (mem_end - mem_start) / + cpumask_weight(&node_cpus); + region[i].start = mem_start; + + if ( region[i].cpu_block_size > max_cpu_blk_size ) + max_cpu_blk_size = region[i].cpu_block_size; + } + + if ( chunk_size > max_cpu_blk_size ) + chunk_size = max_cpu_blk_size; + + /* + * Start all CPU's scrubbing memory, chunk_size at a time + */ + for ( mfn_off = 0; mfn_off < max_cpu_blk_size; mfn_off += chunk_size ) + { + process_pending_softirqs(); + + atomic_set(&bootscrub_count, 0); + spin_lock(&heap_lock); - /* Re-check page status with lock held. */ - if ( page_state_is(pg, free) ) - scrub_one_page(pg); + /* Start all other CPU's on all nodes */ + for_each_online_node ( i ) + { + region[i].chunk_size = chunk_size; + region[i].offset = mfn_off; + node_cpus = node_to_cpumask(i); + /* Clear local cpu ID */ + cpumask_clear_cpu(smp_processor_id(), &node_cpus); + /* Start page scrubbing on all other CPU's */ + on_selected_cpus(&allbutself, smp_scrub_heap_pages, ®ion[i], 0); + } + + /* Start scrub on local CPU */ + smp_scrub_heap_pages(®ion[cpu_to_node(smp_processor_id())]); + + /* Wait for page scrubbing to complete on all other CPU's */ + while ( atomic_read(&bootscrub_count) < cpumask_weight(&cpu_online_map) ) + cpu_relax(); spin_unlock(&heap_lock); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 17:25:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 17:25:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSX7H-0001dl-8b; Thu, 10 May 2012 17:25:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSX7F-0001dg-HF for xen-devel@lists.xensource.com; Thu, 10 May 2012 17:25:25 +0000 Received: from [85.158.138.51:30502] by server-7.bemta-3.messagelabs.com id D3/5E-03078-40AFBAF4; Thu, 10 May 2012 17:25:24 +0000 X-Env-Sender: malcolm.crossley@citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336670723!22359384!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11155 invoked from network); 10 May 2012 17:25:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 17:25:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="12414066" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 17:25:23 +0000 Received: from [127.0.1.1] (10.80.3.206) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 10 May 2012 18:25:23 +0100 MIME-Version: 1.0 X-Mercurial-Node: a909ee6d97995abda9201e55c14d9216b0438ec0 Message-ID: User-Agent: Mercurial-patchbomb/2.2.1 Date: Thu, 10 May 2012 18:25:17 +0100 From: Malcolm Crossley To: xen-devel@lists.xensource.com Cc: keir@xen.org Subject: [Xen-devel] [PATCH] [RFC] Xen: Spread boot time page scrubbing across all available CPU's X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The page scrubbing is done in 256MB chunks in lockstep across all the CPU's. This allows for the boot CPU to hold the heap_lock whilst each chunk is being scrubbed and then release the heap_lock when all CPU's are finished scrubing their individual chunk. This allows for the heap_lock to not be held continously and for pending softirqs are to be serviced periodically across all CPU's. The page scrub memory chunks are allocated to the CPU's in a NUMA aware fashion to reduce Socket interconnect overhead and improve performance. This patch reduces the boot page scrub time on a 256GB 16 core AMD Opteron machine from 1 minute 46 seconds to 38 seconds. diff -r 8a86d841e6d4 -r a909ee6d9799 xen/common/page_alloc.c --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -89,6 +89,15 @@ static struct bootmem_region { } *__initdata bootmem_region_list; static unsigned int __initdata nr_bootmem_regions; +static atomic_t __initdata bootscrub_count = ATOMIC_INIT(0); + +struct scrub_region { + unsigned long offset; + unsigned long start; + unsigned long chunk_size; + unsigned long cpu_block_size; +}; + static void __init boot_bug(int line) { panic("Boot BUG at %s:%d\n", __FILE__, line); @@ -1090,28 +1099,43 @@ void __init end_boot_allocator(void) printk("\n"); } -/* - * Scrub all unallocated pages in all heap zones. This function is more - * convoluted than appears necessary because we do not want to continuously - * hold the lock while scrubbing very large memory areas. - */ -void __init scrub_heap_pages(void) +void __init smp_scrub_heap_pages(void *data) { unsigned long mfn; struct page_info *pg; + unsigned long start_mfn, end_mfn; + struct scrub_region *region = (struct scrub_region *) data; + int temp_cpu, local_node, local_cpu_index; - if ( !opt_bootscrub ) - return; + ASSERT(region != NULL); - printk("Scrubbing Free RAM: "); + /* Determine the current CPU's index into all this Node's CPU's*/ + local_node = cpu_to_node(smp_processor_id()); + local_cpu_index = 0; + for_each_cpu(temp_cpu, &node_to_cpumask(local_node)) + { + if(smp_processor_id() == temp_cpu) + break; + local_cpu_index++; + } - for ( mfn = first_valid_mfn; mfn < max_page; mfn++ ) + /* Calculate the starting mfn for this CPU's memory block */ + start_mfn = region->start + (region->cpu_block_size * local_cpu_index) + + region->offset; + + /* Calculate the end mfn into this CPU's memory block for this iteration */ + if ( ( region->offset + region->chunk_size ) > region->cpu_block_size ) + end_mfn = region->start + (region->cpu_block_size * local_cpu_index) + + region->cpu_block_size; + else + end_mfn = start_mfn + region->chunk_size; + + + for ( mfn = start_mfn; mfn < end_mfn; mfn++ ) { - process_pending_softirqs(); - pg = mfn_to_page(mfn); - /* Quick lock-free check. */ + /* Check the mfn is valid and page is free. */ if ( !mfn_valid(mfn) || !page_state_is(pg, free) ) continue; @@ -1119,11 +1143,82 @@ void __init scrub_heap_pages(void) if ( (mfn % ((100*1024*1024)/PAGE_SIZE)) == 0 ) printk("."); + /* Do the scrub if possible */ + if ( page_state_is(pg, free) ) + scrub_one_page(pg); + } + /* Increment count to indicate scrubbing complete on this CPU */ + atomic_inc(&bootscrub_count); +} + +/* + * Scrub all unallocated pages in all heap zones. This function uses all + * online cpu's to scrub the memory in parallel. + */ +void __init scrub_heap_pages(void) +{ + cpumask_t node_cpus; + unsigned int i; + struct scrub_region region[MAX_NUMNODES]; + unsigned long mfn_off, chunk_size, max_cpu_blk_size, mem_start, mem_end; + + if ( !opt_bootscrub ) + return; + + printk("Scrubbing Free RAM: "); + + /* Scrub block size */ + chunk_size = (256*1024*1024/PAGE_SIZE); + + max_cpu_blk_size = 0; + /* Determine the amount of memory to scrub, per CPU on each Node */ + for_each_online_node ( i ) + { + /* Calculate Node memory start and end address */ + mem_start = max(node_start_pfn(i), first_valid_mfn); + mem_end = min(mem_start + node_spanned_pages(i), max_page); + node_cpus = node_to_cpumask(i); + /* Divide by number of CPU's for this node */ + region[i].cpu_block_size = (mem_end - mem_start) / + cpumask_weight(&node_cpus); + region[i].start = mem_start; + + if ( region[i].cpu_block_size > max_cpu_blk_size ) + max_cpu_blk_size = region[i].cpu_block_size; + } + + if ( chunk_size > max_cpu_blk_size ) + chunk_size = max_cpu_blk_size; + + /* + * Start all CPU's scrubbing memory, chunk_size at a time + */ + for ( mfn_off = 0; mfn_off < max_cpu_blk_size; mfn_off += chunk_size ) + { + process_pending_softirqs(); + + atomic_set(&bootscrub_count, 0); + spin_lock(&heap_lock); - /* Re-check page status with lock held. */ - if ( page_state_is(pg, free) ) - scrub_one_page(pg); + /* Start all other CPU's on all nodes */ + for_each_online_node ( i ) + { + region[i].chunk_size = chunk_size; + region[i].offset = mfn_off; + node_cpus = node_to_cpumask(i); + /* Clear local cpu ID */ + cpumask_clear_cpu(smp_processor_id(), &node_cpus); + /* Start page scrubbing on all other CPU's */ + on_selected_cpus(&allbutself, smp_scrub_heap_pages, ®ion[i], 0); + } + + /* Start scrub on local CPU */ + smp_scrub_heap_pages(®ion[cpu_to_node(smp_processor_id())]); + + /* Wait for page scrubbing to complete on all other CPU's */ + while ( atomic_read(&bootscrub_count) < cpumask_weight(&cpu_online_map) ) + cpu_relax(); spin_unlock(&heap_lock); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 19:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYfu-0002aj-KQ; Thu, 10 May 2012 19:05:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYft-0002ae-Nt for xen-devel@lists.xen.org; Thu, 10 May 2012 19:05:17 +0000 Received: from [85.158.143.35:23849] by server-2.bemta-4.messagelabs.com id FB/14-17550-D611CAF4; Thu, 10 May 2012 19:05:17 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336676713!14001937!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19005 invoked from network); 10 May 2012 19:05:15 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 19:05:15 -0000 Received: by vbbfn1 with SMTP id fn1so947991vbb.32 for ; Thu, 10 May 2012 12:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=Vyp3iLcW4jLDswl6IqkANh//VDL3+Wbw6zM/9IZo8tg=; b=I2+X8+y+C/nYCB/etf51tTIKzV6uNHD3+IjaMZvtdc5xeeVUM8XpODjYS0yxRhRoWt qX39nJ9fKVbSpNIcRUFz0FB3sEKhK6uByTkZHvPCH4SlxoOc1gFyqSVhL/Mt49W6YEjD 0iTFcitXxQV107DBpWKF/OaG/fGCDulHGT33kr8hUp4lhJI0xRRjH10qmVpibRzVuXG+ CaUdq90w17Bo2Br0k6m1WGKdbOMnK/r/gTnrJpXN3w3b/vy9WxCUwzCurcVu7BoDQFuW WdymcsmD+vV51ZiI+O5aGiHFZ9bY5AgLx+GYPaRurlTd3ehirrk6wG2Vtlv6fGZZI906 bYlA== Received: by 10.220.224.68 with SMTP id in4mr3387197vcb.24.1336676712076; Thu, 10 May 2012 12:05:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 12:04:51 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 20:04:51 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=14dae9ccde269a553d04bfb34c70 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae9ccde269a553d04bfb34c70 Content-Type: text/plain; charset=ISO-8859-1 After a host sleep MSI will be off on the host but qemu still thinks it's on because of some state that have been set previously. If qemu thinks that the device has been configure already and the host MSI are disabled tell Xen to reconfigure the MSI. Signed-off-by: Jean Guyader --14dae9ccde269a553d04bfb34c70 Content-Type: text/x-patch; charset=US-ASCII; name="msi-after-sleep.patch" Content-Disposition: attachment; filename="msi-after-sleep.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h226tm4g0 ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5kZXgg ZjgzMmM1YS4uYTZhOWI3YSAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysrIGIvaHcv cGFzcy10aHJvdWdoLmMKQEAgLTM3NzIsNiArMzc3MiwyMSBAQCBzdGF0aWMgaW50IHB0X3BtY3Ny X3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gMDsKIH0KIAorc3Rh dGljIGludCBtc2lfaXNfZW5hYmxlKHN0cnVjdCBwdF9kZXYgKmRldikKK3sKKyAgICB1aW50MTZf dCB2YWwgPSAwOworICAgIHVpbnQzMl90IGFkZHJlc3MgPSAwOworICAgIGlmICghZGV2LT5tc2kp CisgICAgICAgIHJldHVybiAwOworCisgICAgYWRkcmVzcyA9IGRldi0+bXNpLT5jdHJsX29mZnNl dDsKKyAgICBpZiAoIWFkZHJlc3MpCisgICAgICAgIHJldHVybiAwOworCisgICAgdmFsID0gcGNp X3JlYWRfd29yZChkZXYtPnBjaV9kZXYsIGFkZHJlc3MpOworICAgIHJldHVybiB2YWwgJiBQQ0lf TVNJX0ZMQUdTX0VOQUJMRTsKK30KKwogLyogd3JpdGUgTWVzc2FnZSBDb250cm9sIHJlZ2lzdGVy ICovCiBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2 LAogICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCkBAIC0zODAzLDggKzM4MTgsNyBA QCBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAog ICAgIC8qIHVwZGF0ZSBNU0kgKi8KICAgICBpZiAodmFsICYgUENJX01TSV9GTEFHU19FTkFCTEUp CiAgICAgewotICAgICAgICAvKiBzZXR1cCBNU0kgcGlycSBmb3IgdGhlIGZpcnN0IHRpbWUgKi8K LSAgICAgICAgaWYgKHB0ZGV2LT5tc2ktPmZsYWdzICYgTVNJX0ZMQUdfVU5JTklUKQorICAgICAg ICBpZiAoIW1zaV9pc19lbmFibGUocHRkZXYpKQogICAgICAgICB7CiAgICAgICAgICAgICBpZiAo cHRkZXYtPm1zaV90cmFuc19lbikgewogICAgICAgICAgICAgICAgIFBUX0xPRygiZ3Vlc3QgZW5h YmxpbmcgTVNJLCBkaXNhYmxlIE1TSS1JTlR4IHRyYW5zbGF0aW9uXG4iKTsKZGlmZiAtLWdpdCBh L2h3L3B0LW1zaS5jIGIvaHcvcHQtbXNpLmMKaW5kZXggNzBjNDAyMy4uOTlmOWFmZCAxMDA2NDQK LS0tIGEvaHcvcHQtbXNpLmMKKysrIGIvaHcvcHQtbXNpLmMKQEAgLTY3LDEyICs2Nyw2IEBAIGlu dCBwdF9tc2lfc2V0dXAoc3RydWN0IHB0X2RldiAqZGV2KQogICAgIGludCBwaXJxID0gLTE7CiAg ICAgdWludDhfdCBndmVjID0gMDsKIAotICAgIGlmICggIShkZXYtPm1zaS0+ZmxhZ3MgJiBNU0lf RkxBR19VTklOSVQpICkKLSAgICB7Ci0gICAgICAgIFBUX0xPRygiRXJyb3I6IHNldHVwIHBoeXNp Y2FsIGFmdGVyIGluaXRpYWxpemVkPz8gXG4iKTsKLSAgICAgICAgcmV0dXJuIC0xOwotICAgIH0K LQogICAgIGd2ZWMgPSBkZXYtPm1zaS0+ZGF0YSAmIDB4RkY7CiAgICAgaWYgKCFndmVjKSB7CiAg ICAgICAgIC8qIGlmIGd2ZWMgaXMgMCwgdGhlIGd1ZXN0IGlzIGFza2luZyBmb3IgYSBwYXJ0aWN1 bGFyIHBpcnEgdGhhdAo= --14dae9ccde269a553d04bfb34c70 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae9ccde269a553d04bfb34c70-- From xen-devel-bounces@lists.xen.org Thu May 10 19:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYfu-0002aj-KQ; Thu, 10 May 2012 19:05:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYft-0002ae-Nt for xen-devel@lists.xen.org; Thu, 10 May 2012 19:05:17 +0000 Received: from [85.158.143.35:23849] by server-2.bemta-4.messagelabs.com id FB/14-17550-D611CAF4; Thu, 10 May 2012 19:05:17 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336676713!14001937!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19005 invoked from network); 10 May 2012 19:05:15 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 19:05:15 -0000 Received: by vbbfn1 with SMTP id fn1so947991vbb.32 for ; Thu, 10 May 2012 12:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=Vyp3iLcW4jLDswl6IqkANh//VDL3+Wbw6zM/9IZo8tg=; b=I2+X8+y+C/nYCB/etf51tTIKzV6uNHD3+IjaMZvtdc5xeeVUM8XpODjYS0yxRhRoWt qX39nJ9fKVbSpNIcRUFz0FB3sEKhK6uByTkZHvPCH4SlxoOc1gFyqSVhL/Mt49W6YEjD 0iTFcitXxQV107DBpWKF/OaG/fGCDulHGT33kr8hUp4lhJI0xRRjH10qmVpibRzVuXG+ CaUdq90w17Bo2Br0k6m1WGKdbOMnK/r/gTnrJpXN3w3b/vy9WxCUwzCurcVu7BoDQFuW WdymcsmD+vV51ZiI+O5aGiHFZ9bY5AgLx+GYPaRurlTd3ehirrk6wG2Vtlv6fGZZI906 bYlA== Received: by 10.220.224.68 with SMTP id in4mr3387197vcb.24.1336676712076; Thu, 10 May 2012 12:05:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 12:04:51 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 20:04:51 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=14dae9ccde269a553d04bfb34c70 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae9ccde269a553d04bfb34c70 Content-Type: text/plain; charset=ISO-8859-1 After a host sleep MSI will be off on the host but qemu still thinks it's on because of some state that have been set previously. If qemu thinks that the device has been configure already and the host MSI are disabled tell Xen to reconfigure the MSI. Signed-off-by: Jean Guyader --14dae9ccde269a553d04bfb34c70 Content-Type: text/x-patch; charset=US-ASCII; name="msi-after-sleep.patch" Content-Disposition: attachment; filename="msi-after-sleep.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h226tm4g0 ZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5jIGIvaHcvcGFzcy10aHJvdWdoLmMKaW5kZXgg ZjgzMmM1YS4uYTZhOWI3YSAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmMKKysrIGIvaHcv cGFzcy10aHJvdWdoLmMKQEAgLTM3NzIsNiArMzc3MiwyMSBAQCBzdGF0aWMgaW50IHB0X3BtY3Ny X3JlZ193cml0ZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gMDsKIH0KIAorc3Rh dGljIGludCBtc2lfaXNfZW5hYmxlKHN0cnVjdCBwdF9kZXYgKmRldikKK3sKKyAgICB1aW50MTZf dCB2YWwgPSAwOworICAgIHVpbnQzMl90IGFkZHJlc3MgPSAwOworICAgIGlmICghZGV2LT5tc2kp CisgICAgICAgIHJldHVybiAwOworCisgICAgYWRkcmVzcyA9IGRldi0+bXNpLT5jdHJsX29mZnNl dDsKKyAgICBpZiAoIWFkZHJlc3MpCisgICAgICAgIHJldHVybiAwOworCisgICAgdmFsID0gcGNp X3JlYWRfd29yZChkZXYtPnBjaV9kZXYsIGFkZHJlc3MpOworICAgIHJldHVybiB2YWwgJiBQQ0lf TVNJX0ZMQUdTX0VOQUJMRTsKK30KKwogLyogd3JpdGUgTWVzc2FnZSBDb250cm9sIHJlZ2lzdGVy ICovCiBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2 LAogICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCkBAIC0zODAzLDggKzM4MTgsNyBA QCBzdGF0aWMgaW50IHB0X21zZ2N0cmxfcmVnX3dyaXRlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAog ICAgIC8qIHVwZGF0ZSBNU0kgKi8KICAgICBpZiAodmFsICYgUENJX01TSV9GTEFHU19FTkFCTEUp CiAgICAgewotICAgICAgICAvKiBzZXR1cCBNU0kgcGlycSBmb3IgdGhlIGZpcnN0IHRpbWUgKi8K LSAgICAgICAgaWYgKHB0ZGV2LT5tc2ktPmZsYWdzICYgTVNJX0ZMQUdfVU5JTklUKQorICAgICAg ICBpZiAoIW1zaV9pc19lbmFibGUocHRkZXYpKQogICAgICAgICB7CiAgICAgICAgICAgICBpZiAo cHRkZXYtPm1zaV90cmFuc19lbikgewogICAgICAgICAgICAgICAgIFBUX0xPRygiZ3Vlc3QgZW5h YmxpbmcgTVNJLCBkaXNhYmxlIE1TSS1JTlR4IHRyYW5zbGF0aW9uXG4iKTsKZGlmZiAtLWdpdCBh L2h3L3B0LW1zaS5jIGIvaHcvcHQtbXNpLmMKaW5kZXggNzBjNDAyMy4uOTlmOWFmZCAxMDA2NDQK LS0tIGEvaHcvcHQtbXNpLmMKKysrIGIvaHcvcHQtbXNpLmMKQEAgLTY3LDEyICs2Nyw2IEBAIGlu dCBwdF9tc2lfc2V0dXAoc3RydWN0IHB0X2RldiAqZGV2KQogICAgIGludCBwaXJxID0gLTE7CiAg ICAgdWludDhfdCBndmVjID0gMDsKIAotICAgIGlmICggIShkZXYtPm1zaS0+ZmxhZ3MgJiBNU0lf RkxBR19VTklOSVQpICkKLSAgICB7Ci0gICAgICAgIFBUX0xPRygiRXJyb3I6IHNldHVwIHBoeXNp Y2FsIGFmdGVyIGluaXRpYWxpemVkPz8gXG4iKTsKLSAgICAgICAgcmV0dXJuIC0xOwotICAgIH0K LQogICAgIGd2ZWMgPSBkZXYtPm1zaS0+ZGF0YSAmIDB4RkY7CiAgICAgaWYgKCFndmVjKSB7CiAg ICAgICAgIC8qIGlmIGd2ZWMgaXMgMCwgdGhlIGd1ZXN0IGlzIGFza2luZyBmb3IgYSBwYXJ0aWN1 bGFyIHBpcnEgdGhhdAo= --14dae9ccde269a553d04bfb34c70 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae9ccde269a553d04bfb34c70-- From xen-devel-bounces@lists.xen.org Thu May 10 19:07:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:07:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYi1-0002jV-Q2; Thu, 10 May 2012 19:07:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYi0-0002jA-2T for xen-devel@lists.xen.org; Thu, 10 May 2012 19:07:28 +0000 Received: from [85.158.143.99:7506] by server-3.bemta-4.messagelabs.com id E9/75-05853-FE11CAF4; Thu, 10 May 2012 19:07:27 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336676844!26526054!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31451 invoked from network); 10 May 2012 19:07:26 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 19:07:26 -0000 Received: by qafl39 with SMTP id l39so931692qaf.16 for ; Thu, 10 May 2012 12:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=4LIODJ0mFlkgMWNDAtyFVL8Qc2bbmUyldK8Gw+Rf//A=; b=Jb/1Xn4Cf/Y3iVdBOxGnrBQkKS2BO0hg3GT7WPa4CR1sWrfAgQYIV+RM+/rFDW/tOV GZbwFpv5Tx/CsNvByzOnCfq71ssE9WcTpITcVgGcRSv3pYSWItfbM33jQN1sZEMcw/85 xgcEnk9ZoBdOF2nRvVFrTiudZeUV1uCAFaJqcOq9tuqzIQM/7YaaBLJd16r1YNGxaXMh v2kCi8MBc4S0vRDO0js0vrd3rZSJrb0RLniHFWLEFVAyfw7c2N91tp7ux7DjVre1h1iB G4+LtcSvqlemZzCz16ShjvyxvQQe4ftzZDzc+3+dAGa4UMyJE0D7cX8s9SOQCDT8RWaN IO4Q== Received: by 10.220.214.8 with SMTP id gy8mr3399934vcb.45.1336676844420; Thu, 10 May 2012 12:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 12:07:04 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 20:07:04 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=14dae9cdc8217dbd9f04bfb3547f Cc: "Kay, Allen M" , Konrad Rzeszutek Wilk , Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/plain; charset=ISO-8859-1 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 --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/x-patch; charset=US-ASCII; name="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch" Content-Disposition: attachment; filename="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h226vxjk0 Y29tbWl0IGE2MDM2YmVlMjNiYjMzOGU2Y2Y0OGU5ZjBkNzVmZjA4NDVmOGNmZTMKQXV0aG9yOiBK ZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29tPgpEYXRlOiAgIFdlZCBOb3Yg MjMgMDc6NTM6MzAgMjAxMSArMDAwMAoKICAgIHFlbXUteGVuOiBJbnRlbCBHUFUgcGFzc3Rocm91 Z2gsIGZpeCBPcFJlZ2lvbiBtYXBwaW5nLgogICAgCiAgICBUaGUgT3BSZWdpb24gc2hvdWxkbid0 IGJlIG1hcHBlZCAxOjEgYmVjYXVzZSB0aGUgYWRkcmVzcyBpbiB0aGUgaG9zdAogICAgY2FuJ3Qg YmUgdXNlZCBpbiB0aGUgZ3Vlc3QgZGlyZWN0bHkuCiAgICAKICAgIFRoaXMgcGF0Y2ggdHJhcHMg cmVhZCBhbmQgd3JpdGUgYWNjZXNzIHRvIHRoZSBvcHJlZ2lvbiBvZiB0aGUgSW50ZWwKICAgIEdQ VSBjb25maWcgc3BhY2UgKG9mZnNldCAweGZjKS4KICAgIAogICAgVG8gd29yayBjb3JyZWN0bHkg dGhpcyBwYXRjaCBuZWVkcyBhIGNoYW5nZSBpbiBodm1sb2FkZXIuCiAgICAKICAgIEhWTWxvYWRl ciB3aWxsIGFsbG9jYXRlIDIgcGFnZXMgZm9yIHRoZSBPcFJlZ2lvbiBhbmQgd3JpdGUgdGhpcyBh ZGRyZXNzCiAgICBvbiB0aGUgY29uZmlnIHNwYWNlIG9mIHRoZSBJbnRlbCBHUFUuIFFlbXUgd2ls bCB0cmFwIGFuZCBtYXAgdGhlIGhvc3QKICAgIE9wUmVnaW9uIHRvIHRoZSBndWVzdC4gQW55IHdy aXRlIHRvIHRoaXMgb2Zmc2V0IGFmdGVyIHRoYXQgd29uJ3QgaGF2ZQogICAgYW55IGVmZmVjdC4g QW55IHJlYWQgb2YgdGhpcyBjb25maWcgc3BhY2Ugb2Zmc2V0IHdpbGwgcmV0dXJuIHRoZSBhZGRy ZXNzCiAgICBpbiB0aGUgZ3Vlc3QuCgpkaWZmIC0tZ2l0IGEvaHcvcGFzcy10aHJvdWdoLmMgYi9o dy9wYXNzLXRocm91Z2guYwppbmRleCBkYmU4ODA0Li43ZWUzYzYxIDEwMDY0NAotLS0gYS9ody9w YXNzLXRocm91Z2guYworKysgYi9ody9wYXNzLXRocm91Z2guYwpAQCAtMjM4LDYgKzIzOCwxNCBA QCBzdGF0aWMgaW50IHB0X2Jhcl9yZWdfcmVzdG9yZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKIHN0 YXRpYyBpbnQgcHRfZXhwX3JvbV9iYXJfcmVnX3Jlc3RvcmUoc3RydWN0IHB0X2RldiAqcHRkZXYs CiAgICAgc3RydWN0IHB0X3JlZ190YmwgKmNmZ19lbnRyeSwKICAgICB1aW50MzJfdCByZWFsX29m ZnNldCwgdWludDMyX3QgZGV2X3ZhbHVlLCB1aW50MzJfdCAqdmFsdWUpOworc3RhdGljIGludCBw dF9pbnRlbF9vcHJlZ2lvbl9yZWFkKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAorICAgICAgICBzdHJ1 Y3QgcHRfcmVnX3RibCAqY2ZnX2VudHJ5LAorICAgICAgICB1aW50MzJfdCAqdmFsdWUsIHVpbnQz Ml90IHZhbGlkX21hc2spOworc3RhdGljIGludCBwdF9pbnRlbF9vcHJlZ2lvbl93cml0ZShzdHJ1 Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ190YmwgKmNmZ19lbnRyeSwK KyAgICAgICAgdWludDMyX3QgKnZhbHVlLCB1aW50MzJfdCBkZXZfdmFsdWUsIHVpbnQzMl90IHZh bGlkX21hc2spOworc3RhdGljIHVpbnQ4X3QgcHRfcmVnX2dycF9oZWFkZXIwX3NpemVfaW5pdChz dHJ1Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ19ncnBfaW5mb190Ymwg KmdycF9yZWcsIHVpbnQzMl90IGJhc2Vfb2Zmc2V0KTsKIAogLyogcHRfcmVnX2luZm9fdGJsIGRl Y2xhcmF0aW9uCiAgKiAtIG9ubHkgZm9yIGVtdWxhdGVkIHJlZ2lzdGVyIChlaXRoZXIgYSBwYXJ0 IG9yIHdob2xlIGJpdCkuCkBAIC00NDQsNiArNDUyLDE2IEBAIHN0YXRpYyBzdHJ1Y3QgcHRfcmVn X2luZm9fdGJsIHB0X2VtdV9yZWdfaGVhZGVyMF90YmxbXSA9IHsKICAgICAgICAgLnUuZHcud3Jp dGUgPSBwdF9leHBfcm9tX2Jhcl9yZWdfd3JpdGUsCiAgICAgICAgIC51LmR3LnJlc3RvcmUgPSBw dF9leHBfcm9tX2Jhcl9yZWdfcmVzdG9yZSwKICAgICB9LAorICAgIC8qIEludGVsIElHRlggT3BS ZWdpb24gcmVnICovCisgICAgeworICAgICAgICAub2Zmc2V0ICAgICA9IFBDSV9JTlRFTF9PUFJF R0lPTiwKKyAgICAgICAgLnNpemUgICAgICAgPSA0LAorICAgICAgICAuaW5pdF92YWwgICA9IDAs CisgICAgICAgIC5ub193YiAgICAgID0gMSwKKyAgICAgICAgLnUuZHcucmVhZCAgID0gcHRfaW50 ZWxfb3ByZWdpb25fcmVhZCwKKyAgICAgICAgLnUuZHcud3JpdGUgID0gcHRfaW50ZWxfb3ByZWdp b25fd3JpdGUsCisgICAgICAgIC51LmR3LnJlc3RvcmUgID0gTlVMTCwKKyAgICB9LAogICAgIHsK ICAgICAgICAgLnNpemUgPSAwLAogICAgIH0sCkBAIC03MzcsNyArNzU1LDcgQEAgc3RhdGljIGNv bnN0IHN0cnVjdCBwdF9yZWdfZ3JwX2luZm9fdGJsIHB0X2VtdV9yZWdfZ3JwX3RibFtdID0gewog ICAgICAgICAuZ3JwX2lkICAgICA9IDB4RkYsCiAgICAgICAgIC5ncnBfdHlwZSAgID0gR1JQX1RZ UEVfRU1VLAogICAgICAgICAuZ3JwX3NpemUgICA9IDB4NDAsCi0gICAgICAgIC5zaXplX2luaXQg ID0gcHRfcmVnX2dycF9zaXplX2luaXQsCisgICAgICAgIC5zaXplX2luaXQgID0gcHRfcmVnX2dy cF9oZWFkZXIwX3NpemVfaW5pdCwKICAgICAgICAgLmVtdV9yZWdfdGJsPSBwdF9lbXVfcmVnX2hl YWRlcjBfdGJsLAogICAgIH0sCiAgICAgLyogUENJIFBvd2VyTWFuYWdlbWVudCBDYXBhYmlsaXR5 IHJlZyBncm91cCAqLwpAQCAtMzAwNiw2ICszMDI0LDE5IEBAIHN0YXRpYyB1aW50MzJfdCBwdF9t c2l4Y3RybF9yZWdfaW5pdChzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gcmVnLT5p bml0X3ZhbDsKIH0KIAorc3RhdGljIHVpbnQ4X3QgcHRfcmVnX2dycF9oZWFkZXIwX3NpemVfaW5p dChzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ19ncnBfaW5mb190 YmwgKmdycF9yZWcsIHVpbnQzMl90IGJhc2Vfb2Zmc2V0KQoreworICAgIC8qCisgICAgKiogQnkg ZGVmYXVsdCB3ZSB3aWxsIHRyYXAgdXAgdG8gMHg0MCBpbiB0aGUgY2ZnIHNwYWNlLgorICAgICoq IElmIGFuIGludGVsIGRldmljZSBpcyBwYXNzIHRocm91Z2ggd2UgbmVlZCB0byB0cmFwIDB4ZmMs CisgICAgKiogdGhlcmVmb3JlIHRoZSBzaXplIHNob3VsZCBiZSAweGZmLgorICAgICovCisgICAg aWYgKGlnZF9wYXNzdGhydSkKKyAgICAgICAgcmV0dXJuIDB4RkY7CisgICAgcmV0dXJuIGdycF9y ZWctPmdycF9zaXplOworfQorCiAvKiBnZXQgcmVnaXN0ZXIgZ3JvdXAgc2l6ZSAqLwogc3RhdGlj IHVpbnQ4X3QgcHRfcmVnX2dycF9zaXplX2luaXQoc3RydWN0IHB0X2RldiAqcHRkZXYsCiAgICAg ICAgIHN0cnVjdCBwdF9yZWdfZ3JwX2luZm9fdGJsICpncnBfcmVnLCB1aW50MzJfdCBiYXNlX29m ZnNldCkKQEAgLTQxNTQsNiArNDE4NSwyMiBAQCBzdGF0aWMgaW50IHB0X3BtY3NyX3JlZ19yZXN0 b3JlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAogICAgIHJldHVybiAwOwogfQogCitzdGF0aWMgaW50 IHB0X2ludGVsX29wcmVnaW9uX3JlYWQoc3RydWN0IHB0X2RldiAqcHRkZXYsCisgICAgICAgIHN0 cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCisgICAgICAgIHVpbnQzMl90ICp2YWx1ZSwgdWlu dDMyX3QgdmFsaWRfbWFzaykKK3sKKyAgICAqdmFsdWUgPSBpZ2RfcmVhZF9vcHJlZ2lvbihwdGRl dik7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgcHRfaW50ZWxfb3ByZWdpb25fd3Jp dGUoc3RydWN0IHB0X2RldiAqcHRkZXYsCisgICAgICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdf ZW50cnksCisgICAgICAgIHVpbnQzMl90ICp2YWx1ZSwgdWludDMyX3QgZGV2X3ZhbHVlLCB1aW50 MzJfdCB2YWxpZF9tYXNrKQoreworICAgIGlnZF93cml0ZV9vcHJlZ2lvbihwdGRldiwgKnZhbHVl KTsKKyAgICByZXR1cm4gMDsKK30KKwogc3RhdGljIHN0cnVjdCBwdF9kZXYgKiByZWdpc3Rlcl9y ZWFsX2RldmljZShQQ0lCdXMgKmVfYnVzLAogICAgICAgICBjb25zdCBjaGFyICplX2Rldl9uYW1l LCBpbnQgZV9kZXZmbiwgdWludDhfdCByX2J1cywgdWludDhfdCByX2RldiwKICAgICAgICAgdWlu dDhfdCByX2Z1bmMsIHVpbnQzMl90IG1hY2hpbmVfaXJxLCBzdHJ1Y3QgcGNpX2FjY2VzcyAqcGNp X2FjY2VzcywKZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5oIGIvaHcvcGFzcy10aHJvdWdo LmgKaW5kZXggODg0MTM5Yy4uYzYxYTdmYiAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmgK KysrIGIvaHcvcGFzcy10aHJvdWdoLmgKQEAgLTQyMiw2ICs0MjIsOCBAQCBQQ0lCdXMgKmludGVs X3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywgaW50IGRldmZuLCB1aW50MTZfdCB2aWQsCiAg ICAgICAgICAgIHVpbnQxNl90IGRpZCwgY29uc3QgY2hhciAqbmFtZSwgdWludDE2X3QgcmV2aXNp b24pOwogdm9pZCBpZ2RfcGNpX3dyaXRlKFBDSURldmljZSAqcGNpX2RldiwgdWludDMyX3QgY29u ZmlnX2FkZHIsIHVpbnQzMl90IHZhbCwgaW50IGxlbik7CiB1aW50MzJfdCBpZ2RfcGNpX3JlYWQo UENJRGV2aWNlICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgaW50IGxlbik7Cit1aW50 MzJfdCBpZ2RfcmVhZF9vcHJlZ2lvbihzdHJ1Y3QgcHRfZGV2ICpwY2lfZGV2KTsKK3ZvaWQgaWdk X3dyaXRlX29wcmVnaW9uKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2LCB1aW50MzJfdCB2YWwpOwog CiAjZW5kaWYgLyogX19QQVNTVEhST1VHSF9IX18gKi8KIApkaWZmIC0tZ2l0IGEvaHcvcHQtZ3Jh cGhpY3MuYyBiL2h3L3B0LWdyYXBoaWNzLmMKaW5kZXggZmVjNzM5MC4uYTYwNjczZiAxMDA2NDQK LS0tIGEvaHcvcHQtZ3JhcGhpY3MuYworKysgYi9ody9wdC1ncmFwaGljcy5jCkBAIC0xMyw2ICsx Myw4IEBACiBleHRlcm4gaW50IGdmeF9wYXNzdGhydTsKIGV4dGVybiBpbnQgaWdkX3Bhc3N0aHJ1 OwogCitzdGF0aWMgdWludDMyX3QgaWdkX2d1ZXN0X29wcmVnaW9uID0gMDsKKwogc3RhdGljIGlu dCBwY2hfbWFwX2lycShQQ0lEZXZpY2UgKnBjaV9kZXYsIGludCBpcnFfbnVtKQogewogICAgIFBU X0xPRygicGNoX21hcF9pcnEgY2FsbGVkXG4iKTsKQEAgLTM3LDYgKzM5LDU0IEBAIHZvaWQgaW50 ZWxfcGNoX2luaXQoUENJQnVzICpidXMpCiAgICAgICAgICAgICAgICAgICAgICAgICBwY2hfbWFw X2lycSwgImludGVsX2JyaWRnZV8xZiIpOwogfQogCit1aW50MzJfdCBpZ2RfcmVhZF9vcHJlZ2lv bihzdHJ1Y3QgcHRfZGV2ICpwY2lfZGV2KQoreworICAgIHVpbnQzMl90IHZhbCA9IC0xOworCisg ICAgaWYgKCBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPT0gMCApCisgICAgICAgIHJldHVybiAtMTsKKwor ICAgIHZhbCA9IGlnZF9ndWVzdF9vcHJlZ2lvbjsKKyNpZmRlZiBQVF9ERUJVR19QQ0lfQ09ORklH X0FDQ0VTUworICAgIFBUX0xPR19ERVYoKFBDSURldmljZSopcGNpX2RldiwgImFkZHI9JXggbGVu PSV4IHZhbD0leFxuIiwKKyAgICAgICAgICAgIFBDSV9JTlRFTF9PUFJFR0lPTiwgNCwgdmFsKTsK KyNlbmRpZgorICAgIHJldHVybiB2YWw7Cit9CisKK3ZvaWQgaWdkX3dyaXRlX29wcmVnaW9uKHN0 cnVjdCBwdF9kZXYgKnJlYWxfZGV2LCB1aW50MzJfdCB2YWwpCit7CisgICAgdWludDMyX3QgaG9z dF9vcHJlZ2lvbiA9IDA7CisgICAgaW50IHJldDsKKworICAgIGlmICggaWdkX2d1ZXN0X29wcmVn aW9uICkKKyAgICB7CisgICAgICAgIFBUX0xPRygib3ByZWdpb24gcmVnaXN0ZXIgYWxyZWFkeSBi ZWVuIHNldCwgaWdub3JpbmcgJXhcbiIsIHZhbCk7CisgICAgICAgIHJldHVybjsKKyAgICB9CisK KyAgICBob3N0X29wcmVnaW9uID0gcHRfcGNpX2hvc3RfcmVhZChyZWFsX2Rldi0+cGNpX2Rldiwg UENJX0lOVEVMX09QUkVHSU9OLCA0KTsKKyAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPSAodmFsICYg fjB4ZmZmKSB8IChob3N0X29wcmVnaW9uICYgMHhmZmYpOworICAgIFBUX0xPRygiTWFwIE9wUmVn aW9uOiAleCAtPiAleFxuIiwgaG9zdF9vcHJlZ2lvbiwgaWdkX2d1ZXN0X29wcmVnaW9uKTsKKwor ICAgIHJldCA9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAorICAg ICAgICAgICAgaWdkX2d1ZXN0X29wcmVnaW9uID4+IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAg ICBob3N0X29wcmVnaW9uID4+IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAgICAyLAorICAgICAg ICAgICAgRFBDSV9BRERfTUFQUElORyk7CisKKyAgICBpZiAoIHJldCAhPSAwICkKKyAgICB7Cisg ICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0IG1hcCBvcHJlZ2lvblxuIik7CisgICAgICAgIGln ZF9ndWVzdF9vcHJlZ2lvbiA9IDA7CisgICAgfQorI2lmZGVmIFBUX0RFQlVHX1BDSV9DT05GSUdf QUNDRVNTCisgICAgUFRfTE9HX0RFVigoUENJRGV2aWNlKilyZWFsX2RldiwgImFkZHI9JXggbGVu PSVseCB2YWw9JXhcbiIsCisgICAgICAgICAgICBQQ0lfSU5URUxfT1BSRUdJT04sIGxlbiwgdmFs KTsKKyNlbmRpZgorCit9CisKIHZvaWQgaWdkX3BjaV93cml0ZShQQ0lEZXZpY2UgKnBjaV9kZXYs IHVpbnQzMl90IGNvbmZpZ19hZGRyLCB1aW50MzJfdCB2YWwsIGludCBsZW4pCiB7CiAgICAgc3Ry dWN0IHBjaV9kZXYgKnBjaV9kZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lfZ2V0X2RldigwLCAwLCAw KTsKQEAgLTk5LDcgKzE0OSw2IEBAIHVpbnQzMl90IGlnZF9wY2lfcmVhZChQQ0lEZXZpY2UgKnBj aV9kZXYsIHVpbnQzMl90IGNvbmZpZ19hZGRyLCBpbnQgbGVuKQogaW50IHJlZ2lzdGVyX3ZnYV9y ZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogewogICAgIHUxNiB2ZW5kb3JfaWQ7 Ci0gICAgaW50IGlnZF9vcHJlZ2lvbjsKICAgICBpbnQgcmV0ID0gMDsKIAogICAgIGlmICggIWdm eF9wYXNzdGhydSB8fCByZWFsX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzICE9IDB4MDMw MCApCkBAIC0xMTcsMTkgKzE2Niw2IEBAIGludCByZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3Qg cHRfZGV2ICpyZWFsX2RldmljZSkKICAgICAgICAgICAgIDB4MjAsCiAgICAgICAgICAgICBEUENJ X0FERF9NQVBQSU5HKTsKIAotICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIgdmFs dWUgKi8KLSAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lf ZGV2LCAwLCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2 aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOwotICAgIGlmICggKHZlbmRvcl9p ZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMICkgJiYgaWdkX29wcmVnaW9uICkKLSAgICB7Ci0gICAg ICAgIHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKLSAg ICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAg ICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAgICAgICAyLAot ICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOwotICAgICAgICBQVF9MT0coInJlZ2lz dGVyX3ZnYTogaWdkX29wcmVnaW9uID0gJXhcbiIsIGlnZF9vcHJlZ2lvbik7Ci0gICAgfQotCiAg ICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAgIFBUX0xPRygiVkdBIHJlZ2lvbiBtYXBwaW5nIGZh aWxlZFxuIik7CiAKQEAgLTE0MSw3ICsxNzcsNyBAQCBpbnQgcmVnaXN0ZXJfdmdhX3JlZ2lvbnMo c3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCiAgKi8KIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdp b25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogewotICAgIHUzMiB2ZW5kb3JfaWQsIGln ZF9vcHJlZ2lvbjsKKyAgICB1MzIgdmVuZG9yX2lkOwogICAgIGludCByZXQgPSAwOwogCiAgICAg aWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3Mg IT0gMHgwMzAwICkKQEAgLTE2MCwxMiArMTk2LDExIEBAIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdp b25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogICAgICAgICAgICAgRFBDSV9SRU1PVkVf TUFQUElORyk7CiAKICAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNl LT5wY2lfZGV2LCBQQ0lfVkVORE9SX0lELCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lf aG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOwot ICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdp b24gKQorICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rf Z3Vlc3Rfb3ByZWdpb24gKQogICAgIHsKICAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlf bWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+ PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdF X1NISUZULAorICAgICAgICAgICAgICAgIGlnZF9ndWVzdF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NI SUZULAorICAgICAgICAgICAgICAgIGlnZF9ndWVzdF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZU LAogICAgICAgICAgICAgICAgIDIsCiAgICAgICAgICAgICAgICAgRFBDSV9SRU1PVkVfTUFQUElO Ryk7CiAgICAgfQo= --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae9cdc8217dbd9f04bfb3547f-- From xen-devel-bounces@lists.xen.org Thu May 10 19:07:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:07:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYi1-0002jV-Q2; Thu, 10 May 2012 19:07:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYi0-0002jA-2T for xen-devel@lists.xen.org; Thu, 10 May 2012 19:07:28 +0000 Received: from [85.158.143.99:7506] by server-3.bemta-4.messagelabs.com id E9/75-05853-FE11CAF4; Thu, 10 May 2012 19:07:27 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336676844!26526054!1 X-Originating-IP: [209.85.216.50] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31451 invoked from network); 10 May 2012 19:07:26 -0000 Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 19:07:26 -0000 Received: by qafl39 with SMTP id l39so931692qaf.16 for ; Thu, 10 May 2012 12:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=4LIODJ0mFlkgMWNDAtyFVL8Qc2bbmUyldK8Gw+Rf//A=; b=Jb/1Xn4Cf/Y3iVdBOxGnrBQkKS2BO0hg3GT7WPa4CR1sWrfAgQYIV+RM+/rFDW/tOV GZbwFpv5Tx/CsNvByzOnCfq71ssE9WcTpITcVgGcRSv3pYSWItfbM33jQN1sZEMcw/85 xgcEnk9ZoBdOF2nRvVFrTiudZeUV1uCAFaJqcOq9tuqzIQM/7YaaBLJd16r1YNGxaXMh v2kCi8MBc4S0vRDO0js0vrd3rZSJrb0RLniHFWLEFVAyfw7c2N91tp7ux7DjVre1h1iB G4+LtcSvqlemZzCz16ShjvyxvQQe4ftzZDzc+3+dAGa4UMyJE0D7cX8s9SOQCDT8RWaN IO4Q== Received: by 10.220.214.8 with SMTP id gy8mr3399934vcb.45.1336676844420; Thu, 10 May 2012 12:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 12:07:04 -0700 (PDT) From: Jean Guyader Date: Thu, 10 May 2012 20:07:04 +0100 Message-ID: To: xen-devel@lists.xen.org Content-Type: multipart/mixed; boundary=14dae9cdc8217dbd9f04bfb3547f Cc: "Kay, Allen M" , Konrad Rzeszutek Wilk , Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/plain; charset=ISO-8859-1 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 --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/x-patch; charset=US-ASCII; name="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch" Content-Disposition: attachment; filename="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h226vxjk0 Y29tbWl0IGE2MDM2YmVlMjNiYjMzOGU2Y2Y0OGU5ZjBkNzVmZjA4NDVmOGNmZTMKQXV0aG9yOiBK ZWFuIEd1eWFkZXIgPGplYW4uZ3V5YWRlckBldS5jaXRyaXguY29tPgpEYXRlOiAgIFdlZCBOb3Yg MjMgMDc6NTM6MzAgMjAxMSArMDAwMAoKICAgIHFlbXUteGVuOiBJbnRlbCBHUFUgcGFzc3Rocm91 Z2gsIGZpeCBPcFJlZ2lvbiBtYXBwaW5nLgogICAgCiAgICBUaGUgT3BSZWdpb24gc2hvdWxkbid0 IGJlIG1hcHBlZCAxOjEgYmVjYXVzZSB0aGUgYWRkcmVzcyBpbiB0aGUgaG9zdAogICAgY2FuJ3Qg YmUgdXNlZCBpbiB0aGUgZ3Vlc3QgZGlyZWN0bHkuCiAgICAKICAgIFRoaXMgcGF0Y2ggdHJhcHMg cmVhZCBhbmQgd3JpdGUgYWNjZXNzIHRvIHRoZSBvcHJlZ2lvbiBvZiB0aGUgSW50ZWwKICAgIEdQ VSBjb25maWcgc3BhY2UgKG9mZnNldCAweGZjKS4KICAgIAogICAgVG8gd29yayBjb3JyZWN0bHkg dGhpcyBwYXRjaCBuZWVkcyBhIGNoYW5nZSBpbiBodm1sb2FkZXIuCiAgICAKICAgIEhWTWxvYWRl ciB3aWxsIGFsbG9jYXRlIDIgcGFnZXMgZm9yIHRoZSBPcFJlZ2lvbiBhbmQgd3JpdGUgdGhpcyBh ZGRyZXNzCiAgICBvbiB0aGUgY29uZmlnIHNwYWNlIG9mIHRoZSBJbnRlbCBHUFUuIFFlbXUgd2ls bCB0cmFwIGFuZCBtYXAgdGhlIGhvc3QKICAgIE9wUmVnaW9uIHRvIHRoZSBndWVzdC4gQW55IHdy aXRlIHRvIHRoaXMgb2Zmc2V0IGFmdGVyIHRoYXQgd29uJ3QgaGF2ZQogICAgYW55IGVmZmVjdC4g QW55IHJlYWQgb2YgdGhpcyBjb25maWcgc3BhY2Ugb2Zmc2V0IHdpbGwgcmV0dXJuIHRoZSBhZGRy ZXNzCiAgICBpbiB0aGUgZ3Vlc3QuCgpkaWZmIC0tZ2l0IGEvaHcvcGFzcy10aHJvdWdoLmMgYi9o dy9wYXNzLXRocm91Z2guYwppbmRleCBkYmU4ODA0Li43ZWUzYzYxIDEwMDY0NAotLS0gYS9ody9w YXNzLXRocm91Z2guYworKysgYi9ody9wYXNzLXRocm91Z2guYwpAQCAtMjM4LDYgKzIzOCwxNCBA QCBzdGF0aWMgaW50IHB0X2Jhcl9yZWdfcmVzdG9yZShzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKIHN0 YXRpYyBpbnQgcHRfZXhwX3JvbV9iYXJfcmVnX3Jlc3RvcmUoc3RydWN0IHB0X2RldiAqcHRkZXYs CiAgICAgc3RydWN0IHB0X3JlZ190YmwgKmNmZ19lbnRyeSwKICAgICB1aW50MzJfdCByZWFsX29m ZnNldCwgdWludDMyX3QgZGV2X3ZhbHVlLCB1aW50MzJfdCAqdmFsdWUpOworc3RhdGljIGludCBw dF9pbnRlbF9vcHJlZ2lvbl9yZWFkKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAorICAgICAgICBzdHJ1 Y3QgcHRfcmVnX3RibCAqY2ZnX2VudHJ5LAorICAgICAgICB1aW50MzJfdCAqdmFsdWUsIHVpbnQz Ml90IHZhbGlkX21hc2spOworc3RhdGljIGludCBwdF9pbnRlbF9vcHJlZ2lvbl93cml0ZShzdHJ1 Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ190YmwgKmNmZ19lbnRyeSwK KyAgICAgICAgdWludDMyX3QgKnZhbHVlLCB1aW50MzJfdCBkZXZfdmFsdWUsIHVpbnQzMl90IHZh bGlkX21hc2spOworc3RhdGljIHVpbnQ4X3QgcHRfcmVnX2dycF9oZWFkZXIwX3NpemVfaW5pdChz dHJ1Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ19ncnBfaW5mb190Ymwg KmdycF9yZWcsIHVpbnQzMl90IGJhc2Vfb2Zmc2V0KTsKIAogLyogcHRfcmVnX2luZm9fdGJsIGRl Y2xhcmF0aW9uCiAgKiAtIG9ubHkgZm9yIGVtdWxhdGVkIHJlZ2lzdGVyIChlaXRoZXIgYSBwYXJ0 IG9yIHdob2xlIGJpdCkuCkBAIC00NDQsNiArNDUyLDE2IEBAIHN0YXRpYyBzdHJ1Y3QgcHRfcmVn X2luZm9fdGJsIHB0X2VtdV9yZWdfaGVhZGVyMF90YmxbXSA9IHsKICAgICAgICAgLnUuZHcud3Jp dGUgPSBwdF9leHBfcm9tX2Jhcl9yZWdfd3JpdGUsCiAgICAgICAgIC51LmR3LnJlc3RvcmUgPSBw dF9leHBfcm9tX2Jhcl9yZWdfcmVzdG9yZSwKICAgICB9LAorICAgIC8qIEludGVsIElHRlggT3BS ZWdpb24gcmVnICovCisgICAgeworICAgICAgICAub2Zmc2V0ICAgICA9IFBDSV9JTlRFTF9PUFJF R0lPTiwKKyAgICAgICAgLnNpemUgICAgICAgPSA0LAorICAgICAgICAuaW5pdF92YWwgICA9IDAs CisgICAgICAgIC5ub193YiAgICAgID0gMSwKKyAgICAgICAgLnUuZHcucmVhZCAgID0gcHRfaW50 ZWxfb3ByZWdpb25fcmVhZCwKKyAgICAgICAgLnUuZHcud3JpdGUgID0gcHRfaW50ZWxfb3ByZWdp b25fd3JpdGUsCisgICAgICAgIC51LmR3LnJlc3RvcmUgID0gTlVMTCwKKyAgICB9LAogICAgIHsK ICAgICAgICAgLnNpemUgPSAwLAogICAgIH0sCkBAIC03MzcsNyArNzU1LDcgQEAgc3RhdGljIGNv bnN0IHN0cnVjdCBwdF9yZWdfZ3JwX2luZm9fdGJsIHB0X2VtdV9yZWdfZ3JwX3RibFtdID0gewog ICAgICAgICAuZ3JwX2lkICAgICA9IDB4RkYsCiAgICAgICAgIC5ncnBfdHlwZSAgID0gR1JQX1RZ UEVfRU1VLAogICAgICAgICAuZ3JwX3NpemUgICA9IDB4NDAsCi0gICAgICAgIC5zaXplX2luaXQg ID0gcHRfcmVnX2dycF9zaXplX2luaXQsCisgICAgICAgIC5zaXplX2luaXQgID0gcHRfcmVnX2dy cF9oZWFkZXIwX3NpemVfaW5pdCwKICAgICAgICAgLmVtdV9yZWdfdGJsPSBwdF9lbXVfcmVnX2hl YWRlcjBfdGJsLAogICAgIH0sCiAgICAgLyogUENJIFBvd2VyTWFuYWdlbWVudCBDYXBhYmlsaXR5 IHJlZyBncm91cCAqLwpAQCAtMzAwNiw2ICszMDI0LDE5IEBAIHN0YXRpYyB1aW50MzJfdCBwdF9t c2l4Y3RybF9yZWdfaW5pdChzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKICAgICByZXR1cm4gcmVnLT5p bml0X3ZhbDsKIH0KIAorc3RhdGljIHVpbnQ4X3QgcHRfcmVnX2dycF9oZWFkZXIwX3NpemVfaW5p dChzdHJ1Y3QgcHRfZGV2ICpwdGRldiwKKyAgICAgICAgc3RydWN0IHB0X3JlZ19ncnBfaW5mb190 YmwgKmdycF9yZWcsIHVpbnQzMl90IGJhc2Vfb2Zmc2V0KQoreworICAgIC8qCisgICAgKiogQnkg ZGVmYXVsdCB3ZSB3aWxsIHRyYXAgdXAgdG8gMHg0MCBpbiB0aGUgY2ZnIHNwYWNlLgorICAgICoq IElmIGFuIGludGVsIGRldmljZSBpcyBwYXNzIHRocm91Z2ggd2UgbmVlZCB0byB0cmFwIDB4ZmMs CisgICAgKiogdGhlcmVmb3JlIHRoZSBzaXplIHNob3VsZCBiZSAweGZmLgorICAgICovCisgICAg aWYgKGlnZF9wYXNzdGhydSkKKyAgICAgICAgcmV0dXJuIDB4RkY7CisgICAgcmV0dXJuIGdycF9y ZWctPmdycF9zaXplOworfQorCiAvKiBnZXQgcmVnaXN0ZXIgZ3JvdXAgc2l6ZSAqLwogc3RhdGlj IHVpbnQ4X3QgcHRfcmVnX2dycF9zaXplX2luaXQoc3RydWN0IHB0X2RldiAqcHRkZXYsCiAgICAg ICAgIHN0cnVjdCBwdF9yZWdfZ3JwX2luZm9fdGJsICpncnBfcmVnLCB1aW50MzJfdCBiYXNlX29m ZnNldCkKQEAgLTQxNTQsNiArNDE4NSwyMiBAQCBzdGF0aWMgaW50IHB0X3BtY3NyX3JlZ19yZXN0 b3JlKHN0cnVjdCBwdF9kZXYgKnB0ZGV2LAogICAgIHJldHVybiAwOwogfQogCitzdGF0aWMgaW50 IHB0X2ludGVsX29wcmVnaW9uX3JlYWQoc3RydWN0IHB0X2RldiAqcHRkZXYsCisgICAgICAgIHN0 cnVjdCBwdF9yZWdfdGJsICpjZmdfZW50cnksCisgICAgICAgIHVpbnQzMl90ICp2YWx1ZSwgdWlu dDMyX3QgdmFsaWRfbWFzaykKK3sKKyAgICAqdmFsdWUgPSBpZ2RfcmVhZF9vcHJlZ2lvbihwdGRl dik7CisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgcHRfaW50ZWxfb3ByZWdpb25fd3Jp dGUoc3RydWN0IHB0X2RldiAqcHRkZXYsCisgICAgICAgIHN0cnVjdCBwdF9yZWdfdGJsICpjZmdf ZW50cnksCisgICAgICAgIHVpbnQzMl90ICp2YWx1ZSwgdWludDMyX3QgZGV2X3ZhbHVlLCB1aW50 MzJfdCB2YWxpZF9tYXNrKQoreworICAgIGlnZF93cml0ZV9vcHJlZ2lvbihwdGRldiwgKnZhbHVl KTsKKyAgICByZXR1cm4gMDsKK30KKwogc3RhdGljIHN0cnVjdCBwdF9kZXYgKiByZWdpc3Rlcl9y ZWFsX2RldmljZShQQ0lCdXMgKmVfYnVzLAogICAgICAgICBjb25zdCBjaGFyICplX2Rldl9uYW1l LCBpbnQgZV9kZXZmbiwgdWludDhfdCByX2J1cywgdWludDhfdCByX2RldiwKICAgICAgICAgdWlu dDhfdCByX2Z1bmMsIHVpbnQzMl90IG1hY2hpbmVfaXJxLCBzdHJ1Y3QgcGNpX2FjY2VzcyAqcGNp X2FjY2VzcywKZGlmZiAtLWdpdCBhL2h3L3Bhc3MtdGhyb3VnaC5oIGIvaHcvcGFzcy10aHJvdWdo LmgKaW5kZXggODg0MTM5Yy4uYzYxYTdmYiAxMDA2NDQKLS0tIGEvaHcvcGFzcy10aHJvdWdoLmgK KysrIGIvaHcvcGFzcy10aHJvdWdoLmgKQEAgLTQyMiw2ICs0MjIsOCBAQCBQQ0lCdXMgKmludGVs X3BjaV9icmlkZ2VfaW5pdChQQ0lCdXMgKmJ1cywgaW50IGRldmZuLCB1aW50MTZfdCB2aWQsCiAg ICAgICAgICAgIHVpbnQxNl90IGRpZCwgY29uc3QgY2hhciAqbmFtZSwgdWludDE2X3QgcmV2aXNp b24pOwogdm9pZCBpZ2RfcGNpX3dyaXRlKFBDSURldmljZSAqcGNpX2RldiwgdWludDMyX3QgY29u ZmlnX2FkZHIsIHVpbnQzMl90IHZhbCwgaW50IGxlbik7CiB1aW50MzJfdCBpZ2RfcGNpX3JlYWQo UENJRGV2aWNlICpwY2lfZGV2LCB1aW50MzJfdCBjb25maWdfYWRkciwgaW50IGxlbik7Cit1aW50 MzJfdCBpZ2RfcmVhZF9vcHJlZ2lvbihzdHJ1Y3QgcHRfZGV2ICpwY2lfZGV2KTsKK3ZvaWQgaWdk X3dyaXRlX29wcmVnaW9uKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2LCB1aW50MzJfdCB2YWwpOwog CiAjZW5kaWYgLyogX19QQVNTVEhST1VHSF9IX18gKi8KIApkaWZmIC0tZ2l0IGEvaHcvcHQtZ3Jh cGhpY3MuYyBiL2h3L3B0LWdyYXBoaWNzLmMKaW5kZXggZmVjNzM5MC4uYTYwNjczZiAxMDA2NDQK LS0tIGEvaHcvcHQtZ3JhcGhpY3MuYworKysgYi9ody9wdC1ncmFwaGljcy5jCkBAIC0xMyw2ICsx Myw4IEBACiBleHRlcm4gaW50IGdmeF9wYXNzdGhydTsKIGV4dGVybiBpbnQgaWdkX3Bhc3N0aHJ1 OwogCitzdGF0aWMgdWludDMyX3QgaWdkX2d1ZXN0X29wcmVnaW9uID0gMDsKKwogc3RhdGljIGlu dCBwY2hfbWFwX2lycShQQ0lEZXZpY2UgKnBjaV9kZXYsIGludCBpcnFfbnVtKQogewogICAgIFBU X0xPRygicGNoX21hcF9pcnEgY2FsbGVkXG4iKTsKQEAgLTM3LDYgKzM5LDU0IEBAIHZvaWQgaW50 ZWxfcGNoX2luaXQoUENJQnVzICpidXMpCiAgICAgICAgICAgICAgICAgICAgICAgICBwY2hfbWFw X2lycSwgImludGVsX2JyaWRnZV8xZiIpOwogfQogCit1aW50MzJfdCBpZ2RfcmVhZF9vcHJlZ2lv bihzdHJ1Y3QgcHRfZGV2ICpwY2lfZGV2KQoreworICAgIHVpbnQzMl90IHZhbCA9IC0xOworCisg ICAgaWYgKCBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPT0gMCApCisgICAgICAgIHJldHVybiAtMTsKKwor ICAgIHZhbCA9IGlnZF9ndWVzdF9vcHJlZ2lvbjsKKyNpZmRlZiBQVF9ERUJVR19QQ0lfQ09ORklH X0FDQ0VTUworICAgIFBUX0xPR19ERVYoKFBDSURldmljZSopcGNpX2RldiwgImFkZHI9JXggbGVu PSV4IHZhbD0leFxuIiwKKyAgICAgICAgICAgIFBDSV9JTlRFTF9PUFJFR0lPTiwgNCwgdmFsKTsK KyNlbmRpZgorICAgIHJldHVybiB2YWw7Cit9CisKK3ZvaWQgaWdkX3dyaXRlX29wcmVnaW9uKHN0 cnVjdCBwdF9kZXYgKnJlYWxfZGV2LCB1aW50MzJfdCB2YWwpCit7CisgICAgdWludDMyX3QgaG9z dF9vcHJlZ2lvbiA9IDA7CisgICAgaW50IHJldDsKKworICAgIGlmICggaWdkX2d1ZXN0X29wcmVn aW9uICkKKyAgICB7CisgICAgICAgIFBUX0xPRygib3ByZWdpb24gcmVnaXN0ZXIgYWxyZWFkeSBi ZWVuIHNldCwgaWdub3JpbmcgJXhcbiIsIHZhbCk7CisgICAgICAgIHJldHVybjsKKyAgICB9CisK KyAgICBob3N0X29wcmVnaW9uID0gcHRfcGNpX2hvc3RfcmVhZChyZWFsX2Rldi0+cGNpX2Rldiwg UENJX0lOVEVMX09QUkVHSU9OLCA0KTsKKyAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPSAodmFsICYg fjB4ZmZmKSB8IChob3N0X29wcmVnaW9uICYgMHhmZmYpOworICAgIFBUX0xPRygiTWFwIE9wUmVn aW9uOiAleCAtPiAleFxuIiwgaG9zdF9vcHJlZ2lvbiwgaWdkX2d1ZXN0X29wcmVnaW9uKTsKKwor ICAgIHJldCA9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAorICAg ICAgICAgICAgaWdkX2d1ZXN0X29wcmVnaW9uID4+IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAg ICBob3N0X29wcmVnaW9uID4+IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAgICAyLAorICAgICAg ICAgICAgRFBDSV9BRERfTUFQUElORyk7CisKKyAgICBpZiAoIHJldCAhPSAwICkKKyAgICB7Cisg ICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0IG1hcCBvcHJlZ2lvblxuIik7CisgICAgICAgIGln ZF9ndWVzdF9vcHJlZ2lvbiA9IDA7CisgICAgfQorI2lmZGVmIFBUX0RFQlVHX1BDSV9DT05GSUdf QUNDRVNTCisgICAgUFRfTE9HX0RFVigoUENJRGV2aWNlKilyZWFsX2RldiwgImFkZHI9JXggbGVu PSVseCB2YWw9JXhcbiIsCisgICAgICAgICAgICBQQ0lfSU5URUxfT1BSRUdJT04sIGxlbiwgdmFs KTsKKyNlbmRpZgorCit9CisKIHZvaWQgaWdkX3BjaV93cml0ZShQQ0lEZXZpY2UgKnBjaV9kZXYs IHVpbnQzMl90IGNvbmZpZ19hZGRyLCB1aW50MzJfdCB2YWwsIGludCBsZW4pCiB7CiAgICAgc3Ry dWN0IHBjaV9kZXYgKnBjaV9kZXZfaG9zdF9icmlkZ2UgPSBwdF9wY2lfZ2V0X2RldigwLCAwLCAw KTsKQEAgLTk5LDcgKzE0OSw2IEBAIHVpbnQzMl90IGlnZF9wY2lfcmVhZChQQ0lEZXZpY2UgKnBj aV9kZXYsIHVpbnQzMl90IGNvbmZpZ19hZGRyLCBpbnQgbGVuKQogaW50IHJlZ2lzdGVyX3ZnYV9y ZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogewogICAgIHUxNiB2ZW5kb3JfaWQ7 Ci0gICAgaW50IGlnZF9vcHJlZ2lvbjsKICAgICBpbnQgcmV0ID0gMDsKIAogICAgIGlmICggIWdm eF9wYXNzdGhydSB8fCByZWFsX2RldmljZS0+cGNpX2Rldi0+ZGV2aWNlX2NsYXNzICE9IDB4MDMw MCApCkBAIC0xMTcsMTkgKzE2Niw2IEBAIGludCByZWdpc3Rlcl92Z2FfcmVnaW9ucyhzdHJ1Y3Qg cHRfZGV2ICpyZWFsX2RldmljZSkKICAgICAgICAgICAgIDB4MjAsCiAgICAgICAgICAgICBEUENJ X0FERF9NQVBQSU5HKTsKIAotICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIgdmFs dWUgKi8KLSAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lf ZGV2LCAwLCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2 aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOwotICAgIGlmICggKHZlbmRvcl9p ZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMICkgJiYgaWdkX29wcmVnaW9uICkKLSAgICB7Ci0gICAg ICAgIHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKLSAg ICAgICAgICAgICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAg ICAgICBpZ2Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAgICAgICAyLAot ICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOwotICAgICAgICBQVF9MT0coInJlZ2lz dGVyX3ZnYTogaWdkX29wcmVnaW9uID0gJXhcbiIsIGlnZF9vcHJlZ2lvbik7Ci0gICAgfQotCiAg ICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAgIFBUX0xPRygiVkdBIHJlZ2lvbiBtYXBwaW5nIGZh aWxlZFxuIik7CiAKQEAgLTE0MSw3ICsxNzcsNyBAQCBpbnQgcmVnaXN0ZXJfdmdhX3JlZ2lvbnMo c3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCiAgKi8KIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdp b25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogewotICAgIHUzMiB2ZW5kb3JfaWQsIGln ZF9vcHJlZ2lvbjsKKyAgICB1MzIgdmVuZG9yX2lkOwogICAgIGludCByZXQgPSAwOwogCiAgICAg aWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3Mg IT0gMHgwMzAwICkKQEAgLTE2MCwxMiArMTk2LDExIEBAIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdp b25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKQogICAgICAgICAgICAgRFBDSV9SRU1PVkVf TUFQUElORyk7CiAKICAgICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNl LT5wY2lfZGV2LCBQQ0lfVkVORE9SX0lELCAyKTsKLSAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lf aG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOwot ICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdp b24gKQorICAgIGlmICggKHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rf Z3Vlc3Rfb3ByZWdpb24gKQogICAgIHsKICAgICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlf bWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+ PiBYQ19QQUdFX1NISUZULAotICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdF X1NISUZULAorICAgICAgICAgICAgICAgIGlnZF9ndWVzdF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NI SUZULAorICAgICAgICAgICAgICAgIGlnZF9ndWVzdF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZU LAogICAgICAgICAgICAgICAgIDIsCiAgICAgICAgICAgICAgICAgRFBDSV9SRU1PVkVfTUFQUElO Ryk7CiAgICAgfQo= --14dae9cdc8217dbd9f04bfb3547f Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae9cdc8217dbd9f04bfb3547f-- From xen-devel-bounces@lists.xen.org Thu May 10 19:35:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:35:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZ8G-0003H4-Bi; Thu, 10 May 2012 19:34:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZ8E-0003Gz-Jl for xen-devel@lists.xensource.com; Thu, 10 May 2012 19:34:34 +0000 Received: from [85.158.143.99:51032] by server-1.bemta-4.messagelabs.com id 8A/1F-20925-9481CAF4; Thu, 10 May 2012 19:34:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336678471!17656797!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30625 invoked from network); 10 May 2012 19:34:32 -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; 10 May 2012 19:34:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,566,1330905600"; d="scan'208";a="12415843" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 19:34: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, 10 May 2012 20:34:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSZ88-0000v7-PB; Thu, 10 May 2012 19:34:28 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSZ88-000552-MN; Thu, 10 May 2012 20:34:28 +0100 To: Message-ID: From: xen.org Date: Thu, 10 May 2012 20:34:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete build-i386 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org branch xen-unstable xen branch xen-unstable job build-i386 test xen-build Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 27d63b9f111a Bug not present: cb82b5aa73bd changeset: 25275:27d63b9f111a user: Keir Fraser date: Thu May 10 11:22:18 2012 +0100 blktap2: Do not build with -O0 Signed-off-by: Keir Fraser For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 12828 fail [host=field-cricket] / 12827 [host=moss-bug] 12823 ok. Failure / basis pass flights: 12828 / 12823 Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Latest 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a Basis pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/staging/qemu-xen-unstable.git#82db8de16530f016809264d3179823999d702849-82db8de16530f016809264d3179823999d702849 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7-fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 http://xenbits.xen.org/staging/xen-unstable.hg#8a86d841e6d4-27d63b9f111a 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 125 nodes in revision graph Searching for test results: 12806 [host=lace-bug] 12824 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12821 [host=moss-bug] 12823 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12827 [host=moss-bug] 12828 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12829 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12830 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12831 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 ca02580986d2 12832 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 83a02f225bde 12833 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12835 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12836 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12842 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12843 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12844 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a Searching for interesting versions Result found: flight 12823 (pass), for basis pass Result found: flight 12828 (fail), for basis failure Repro found: flight 12829 (pass), for basis pass Repro found: flight 12830 (fail), for basis failure 0 revisions at 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd No revisions left to test, checking graph state. Result found: flight 12833 (pass), for last pass Result found: flight 12835 (fail), for first failure Repro found: flight 12836 (pass), for last pass Repro found: flight 12842 (fail), for first failure Repro found: flight 12843 (pass), for last pass Repro found: flight 12844 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 27d63b9f111a Bug not present: cb82b5aa73bd pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg searching for changes no changes found changeset: 25275:27d63b9f111a user: Keir Fraser date: Thu May 10 11:22:18 2012 +0100 blktap2: Do not build with -O0 Signed-off-by: Keir Fraser Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}. ---------------------------------------- 12844: tolerable ALL FAIL flight 12844 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12844/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: build-i386 4 xen-build fail baseline untested jobs: build-i386 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 19:35:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 19:35:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZ8G-0003H4-Bi; Thu, 10 May 2012 19:34:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZ8E-0003Gz-Jl for xen-devel@lists.xensource.com; Thu, 10 May 2012 19:34:34 +0000 Received: from [85.158.143.99:51032] by server-1.bemta-4.messagelabs.com id 8A/1F-20925-9481CAF4; Thu, 10 May 2012 19:34:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336678471!17656797!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30625 invoked from network); 10 May 2012 19:34:32 -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; 10 May 2012 19:34:32 -0000 X-IronPort-AV: E=Sophos;i="4.75,566,1330905600"; d="scan'208";a="12415843" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 19:34: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, 10 May 2012 20:34:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSZ88-0000v7-PB; Thu, 10 May 2012 19:34:28 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSZ88-000552-MN; Thu, 10 May 2012 20:34:28 +0100 To: Message-ID: From: xen.org Date: Thu, 10 May 2012 20:34:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com Subject: [Xen-devel] [xen-unstable bisection] complete build-i386 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org branch xen-unstable xen branch xen-unstable job build-i386 test xen-build Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 27d63b9f111a Bug not present: cb82b5aa73bd changeset: 25275:27d63b9f111a user: Keir Fraser date: Thu May 10 11:22:18 2012 +0100 blktap2: Do not build with -O0 Signed-off-by: Keir Fraser For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Searching for failure / basis pass: 12828 fail [host=field-cricket] / 12827 [host=moss-bug] 12823 ok. Failure / basis pass flights: 12828 / 12823 Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Latest 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a Basis pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/staging/qemu-xen-unstable.git#82db8de16530f016809264d3179823999d702849-82db8de16530f016809264d3179823999d702849 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7-fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 http://xenbits.xen.org/staging/xen-unstable.hg#8a86d841e6d4-27d63b9f111a 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 125 nodes in revision graph Searching for test results: 12806 [host=lace-bug] 12824 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12821 [host=moss-bug] 12823 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12827 [host=moss-bug] 12828 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12829 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 8a86d841e6d4 12830 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12831 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 ca02580986d2 12832 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 83a02f225bde 12833 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12835 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12836 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12842 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a 12843 pass 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd 12844 fail 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 27d63b9f111a Searching for interesting versions Result found: flight 12823 (pass), for basis pass Result found: flight 12828 (fail), for basis failure Repro found: flight 12829 (pass), for basis pass Repro found: flight 12830 (fail), for basis failure 0 revisions at 82db8de16530f016809264d3179823999d702849 fcd11a4f9f279ee89686706fe1cedf36cf9a7ee7 cb82b5aa73bd No revisions left to test, checking graph state. Result found: flight 12833 (pass), for last pass Result found: flight 12835 (fail), for first failure Repro found: flight 12836 (pass), for last pass Repro found: flight 12842 (fail), for first failure Repro found: flight 12843 (pass), for last pass Repro found: flight 12844 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg Bug introduced: 27d63b9f111a Bug not present: cb82b5aa73bd pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg searching for changes no changes found changeset: 25275:27d63b9f111a user: Keir Fraser date: Thu May 10 11:22:18 2012 +0100 blktap2: Do not build with -O0 Signed-off-by: Keir Fraser Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}. ---------------------------------------- 12844: tolerable ALL FAIL flight 12844 xen-unstable real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12844/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: build-i386 4 xen-build fail baseline untested jobs: build-i386 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 20:03:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 20:03:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZZI-0003XB-8X; Thu, 10 May 2012 20:02:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZZG-0003X6-MD for xen-devel@lists.xen.org; Thu, 10 May 2012 20:02:30 +0000 Received: from [85.158.139.83:30526] by server-12.bemta-5.messagelabs.com id D4/39-01344-5DE1CAF4; Thu, 10 May 2012 20:02:29 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336680146!20401966!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7054 invoked from network); 10 May 2012 20:02:28 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 20:02:28 -0000 Received: by vbbfn1 with SMTP id fn1so1020662vbb.32 for ; Thu, 10 May 2012 13:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i+nyRnJBhnJkaGt6mv82p8HBdn+nuYpSfwgDniodMvQ=; b=G1k4W038rgDf7fbKlH2egOI+roXj1sLhFfuPQoJbROgcZu7detvkmP1ezu9RNwzOfT 2BkRt05IsGQZsz0w5PWVVDFw0igtXxLqDpnN5EzHJWwAvgkDPMoam9g0GfZED6ZwcBRZ PseyGmXQdy8gXYjEWWRCiYzxQETG4mFhlH5S1ZECYQ3HaEssGlJR8hCasSnVlJPvFL3Y sxUJc0I2ZvL3vskDB2iu0Chj5IuZPpxw3FaBLAsbtvJBUtGw3h9Df59+ia9+JtL7bLW3 2emFGXUvfbawe1wzTeS+heo8FL/+41Ec6Xvoa2FTntjHCurCSaOOeJT8R3Qq26u5ODk4 mqCg== Received: by 10.52.72.137 with SMTP id d9mr2652339vdv.122.1336680145758; Thu, 10 May 2012 13:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 13:02:05 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 21:02:05 +0100 Message-ID: To: xen-devel@lists.xen.org Cc: "Kay, Allen M" , Konrad Rzeszutek Wilk , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10 May 2012 20:07, 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 0x). > > 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 Sorry forgot to say, it was acked by Stefano. Acked-by: Stefano Stabellini _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 20:03:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 20:03:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZZI-0003XB-8X; Thu, 10 May 2012 20:02:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZZG-0003X6-MD for xen-devel@lists.xen.org; Thu, 10 May 2012 20:02:30 +0000 Received: from [85.158.139.83:30526] by server-12.bemta-5.messagelabs.com id D4/39-01344-5DE1CAF4; Thu, 10 May 2012 20:02:29 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336680146!20401966!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7054 invoked from network); 10 May 2012 20:02:28 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 20:02:28 -0000 Received: by vbbfn1 with SMTP id fn1so1020662vbb.32 for ; Thu, 10 May 2012 13:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i+nyRnJBhnJkaGt6mv82p8HBdn+nuYpSfwgDniodMvQ=; b=G1k4W038rgDf7fbKlH2egOI+roXj1sLhFfuPQoJbROgcZu7detvkmP1ezu9RNwzOfT 2BkRt05IsGQZsz0w5PWVVDFw0igtXxLqDpnN5EzHJWwAvgkDPMoam9g0GfZED6ZwcBRZ PseyGmXQdy8gXYjEWWRCiYzxQETG4mFhlH5S1ZECYQ3HaEssGlJR8hCasSnVlJPvFL3Y sxUJc0I2ZvL3vskDB2iu0Chj5IuZPpxw3FaBLAsbtvJBUtGw3h9Df59+ia9+JtL7bLW3 2emFGXUvfbawe1wzTeS+heo8FL/+41Ec6Xvoa2FTntjHCurCSaOOeJT8R3Qq26u5ODk4 mqCg== Received: by 10.52.72.137 with SMTP id d9mr2652339vdv.122.1336680145758; Thu, 10 May 2012 13:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.100.71 with HTTP; Thu, 10 May 2012 13:02:05 -0700 (PDT) In-Reply-To: References: From: Jean Guyader Date: Thu, 10 May 2012 21:02:05 +0100 Message-ID: To: xen-devel@lists.xen.org Cc: "Kay, Allen M" , Konrad Rzeszutek Wilk , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10 May 2012 20:07, 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 0x). > > 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 Sorry forgot to say, it was acked by Stefano. Acked-by: Stefano Stabellini _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 20:58:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 20: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 ) id 1SSaR0-0003ph-1G; Thu, 10 May 2012 20:58:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSaQy-0003pc-6U for xen-devel@lists.xen.org; Thu, 10 May 2012 20:58:00 +0000 Received: from [85.158.143.99:64141] by server-1.bemta-4.messagelabs.com id 22/4E-20925-7DB2CAF4; Thu, 10 May 2012 20:57:59 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336683477!19904371!1 X-Originating-IP: [209.85.212.169] 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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20830 invoked from network); 10 May 2012 20:57:57 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 20:57:57 -0000 Received: by wibhn14 with SMTP id hn14so985790wib.2 for ; Thu, 10 May 2012 13:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7e+ORu9pHBf2hJbQ5jygoIqe2WyTJoMf1BbJssvt0d8=; b=IHQxqEsgKAYcNEvjfvLeR+o++yrdI8SohZOpTj0Fo6zrujTaaCcEx2TcgPbXK4WtGw 2NE8sXzWzKEMixjXr6ORLngoss+GTkEb4gOKMRZI1b/TXOgRO4bysXr6ngxI5C8c/p+w 99QGlAHE+yFS82NuerF9zT36bobUuRCaF68/PObZJDemLrXA55cSlqegYJsdwFS5MYXA JUJjppP528OIkmc1S7A85wGZFPxuuAp5X8UTTZUs4w0q5esbqFMJZm56YSBQlvn2rtO5 8rLKyIyH3xPUR0tHju20qt1h68r91gf214YRIq27W4f0/BBiAqwJ4FrtJM0ZvRvNHde3 ucOw== MIME-Version: 1.0 Received: by 10.180.24.103 with SMTP id t7mr1021264wif.16.1336683476825; Thu, 10 May 2012 13:57:56 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 13:57:56 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 13:57:56 -0700 (PDT) In-Reply-To: <4FAC1989.4060201@redhat.com> References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> Date: Thu, 10 May 2012 16:57:56 -0400 X-Google-Sender-Auth: ARnxGWzyJEjdkptla5tgEzR7smk Message-ID: From: Konrad Rzeszutek Wilk To: Jeff Law Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk , haitao.shan@intel.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7650766948609096804==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7650766948609096804== Content-Type: multipart/alternative; boundary=f46d043c8060d0379104bfb4dfea --f46d043c8060d0379104bfb4dfea Content-Type: text/plain; charset=ISO-8859-1 On May 10, 2012 3:40 PM, "Jeff Law" wrote: > > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: >>> >>> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >> >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_AVX) >> >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_OSXSAVE) != 0 >> 151&& ({ unsigned int xcrlow; >> >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> >> 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID flags, I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV guest >> still crashes on that machine) - which means that in multi-lib the bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. > > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but not the YMM registers and thus the right check is for AVX. > > That doesn't make sense to me given the text under availability and support here: > > http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/ > > According to my reading AVX can only be used if the hardware supports AVX *and* the OS supports XSAVE. The only weasel language is "To use the Intel AVX extensions reliably in most settings ..." Which Uli might be relying upon for his position. > > Ironically, the code in init-arch used to look like: > > > if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) > { > > /* Reset the AVX bit in case OSXSAVE is disabled. */ > if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSXSAVE) == 0 > || ({ unsigned int xcrlow; > unsigned int xcrhigh; > asm ("xgetbv" > > : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); > (xcrlow & 6) != 6; })) > > __cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ~bit_AVX; > } > > > Which I think would have done the right thing. Uli changed it to the form you quoted just 2 hours after installing the version I quoted. Sadly no as it would have executed the xgetv instruction. Since the first part of the boolean logic returns false. > > If i'm going to make the claim Uli is wrong, some clarification from Intel would be appreciated. > > > jeff > On May 10, 2012 3:40 PM, "Jeff Law" wrote: > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: > >> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >>> >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx& bit_AVX) >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx& >> bit_OSXSAVE) != 0 >> 151&& ({ unsigned int xcrlow; >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> 156 __cpu_features.feature[index_**YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID >> flags, I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit >> PV guest >> still crashes on that machine) - which means that in multi-lib the >> bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%**rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+** >> index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. >> > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but not > the YMM registers and thus the right check is for AVX. > > That doesn't make sense to me given the text under availability and > support here: > > http://software.intel.com/en-**us/articles/introduction-to-** > intel-advanced-vector-**extensions/ > > According to my reading AVX can only be used if the hardware supports AVX > *and* the OS supports XSAVE. The only weasel language is "To use the > Intel AVX extensions reliably in most settings ..." Which Uli might be > relying upon for his position. > > Ironically, the code in init-arch used to look like: > > if (__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx & bit_AVX) > { > /* Reset the AVX bit in case OSXSAVE is disabled. */ > if ((__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx & bit_OSXSAVE) > == 0 > || ({ unsigned int xcrlow; > unsigned int xcrhigh; > asm ("xgetbv" > : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); > (xcrlow & 6) != 6; })) > __cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx &= ~bit_AVX; > } > > > Which I think would have done the right thing. Uli changed it to the > form you quoted just 2 hours after installing the version I quoted. > > If i'm going to make the claim Uli is wrong, some clarification from Intel > would be appreciated. > > > jeff > > --f46d043c8060d0379104bfb4dfea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 10, 2012 3:40 PM, "Jeff Law" <law@redhat.com> wrote:
>
> On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>>
>>> And finally one always has to keep in mind that there is this = nice
>>> glibc bug in that in some versions it is failing to look at CP= UID.OSXSAVE
>>> when trying to determine whether AVX or FMA is available.
>>
>>
>> It has this:
>> 146
>> 147 =A0 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& = =A0bit_AVX)
>>
>> 148 =A0 =A0 {
>> 149 =A0 =A0 =A0 /* Reset the AVX bit in case OSXSAVE is disabled. = =A0*/
>> 150 =A0 =A0 =A0 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ec= x& =A0bit_OSXSAVE) !=3D 0
>> 151&& =A0({ unsigned int xcrlow;
>>
>> 152 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int xcrhigh;
>> 153 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 asm ("xgetbv"
>> 154 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "=3Da" = (xcrlow), "=3Dd" (xcrhigh) : "c" (0));
>> 155 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (xcrlow& =A06) =3D=3D 6; }= ))
>>
>> 156 =A0 =A0 =A0 =A0 __cpu_features.feature[index_YMM_Usable] |=3D = bit_YMM_Usable;
>> 157 =A0 =A0 }
>>
>>
>> And when I ran a little silly C program (attached) to probe the CP= UID flags, I got:
>> =A0/root/test-xsave
>> SSE3 CMOV
>> AVX =A0XSAVE
>> Trying XGETBV
>> Illegal instruction (core dumped)
>>
>> Which would imply that the OSXSAVE is not set (but Fedora Core 17 = 64-bit PV guest
>> still crashes on that machine) - which means that in multi-lib the= bit_YMM_Usable
>> is _not_ set. But then looking at the sources I see:
>>
>> # ifdef USE_AS_STRCASECMP_L
>> 102 ENTRY(__strcasecmp)
>> 103 =A0 =A0 =A0 =A0 .type =A0 __strcasecmp, @gnu_indirect_function=
>> 104 =A0 =A0 =A0 =A0 cmpl =A0 =A0$0, __cpu_features+KIND_OFFSET(%ri= p)
>> 105 =A0 =A0 =A0 =A0 jne =A0 =A0 1f
>> 106 =A0 =A0 =A0 =A0 call =A0 =A0__init_cpu_features
>> 107 1:
>> 108 # =A0ifdef HAVE_AVX_SUPPORT
>> 109 =A0 =A0 =A0 =A0 leaq =A0 =A0__strcasecmp_avx(%rip), %rax
>> 110 =A0 =A0 =A0 =A0 testl =A0 $bit_AVX, __cpu_features+CPUID_OFFSE= T+index_AVX(%rip)
>> 111 =A0 =A0 =A0 =A0 jnz =A0 =A0 2f
>> 112 # =A0endif
>>
>> which would imply that the AVX bit is sampled here instead of the<= br> >> YMM one.
>
> [ ... ]
> I think Uli's position is that this code only uses AVX encodings, = but not the YMM registers and thus the right check is for AVX.
>
> That doesn't make sense to me given the text under availability an= d support here:
>
> http://software.intel.com/en-us/articles/i= ntroduction-to-intel-advanced-vector-extensions/
>
> According to my reading AVX can only be used if the hardware supports = AVX *and* the OS supports XSAVE. =A0 =A0The only weasel language is "T= o use the Intel AVX extensions reliably in most settings ..." =A0Which= Uli might be relying upon for his position.
>
> Ironically, the code in init-arch used to look like:
>
>
> =A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) > =A0 =A0{
>
> =A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
> =A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & b= it_OSXSAVE) =3D=3D 0
> =A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv"
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "= ;=3Dd" (xcrhigh) : "c" (0));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; }))
>
> =A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &=3D= ~bit_AVX;
> =A0 =A0}
>
>
> Which I think would have done the right thing. =A0 Uli changed it to t= he form you quoted just 2 hours after installing the version I quoted.

Sadly no as it would have executed the xgetv instruction. Since the firs= t part of the boolean logic returns false.
>
> If i'm going to make the claim Uli is wrong, some clarification fr= om Intel would be appreciated.
>
>
> jeff
>

On May 10, 2012 3:40 PM, "Jeff Law" &l= t;law@redhat.com> wrote:
On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:

And finally one always has to keep in mind that there is this nice
glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE when trying to determine whether AVX or FMA is available.

It has this:
146
147 =A0 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& =A0b= it_AVX)
148 =A0 =A0 {
149 =A0 =A0 =A0 /* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
150 =A0 =A0 =A0 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx&= amp; =A0bit_OSXSAVE) !=3D 0
151&& =A0({ unsigned int xcrlow;
152 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int xcrhigh;
153 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 asm ("xgetbv"
154 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "=3Da" (xcrlow),= "=3Dd" (xcrhigh) : "c" (0));
155 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (xcrlow& =A06) =3D=3D 6; }))
156 =A0 =A0 =A0 =A0 __cpu_features.feature[index_YMM_Usable] |=3D bi= t_YMM_Usable;
157 =A0 =A0 }


And when I ran a little silly C program (attached) to probe the CPUID flags= , I got:
=A0/root/test-xsave
SSE3 CMOV
AVX =A0XSAVE
Trying XGETBV
Illegal instruction (core dumped)

Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV= guest
still crashes on that machine) - which means that in multi-lib the bit_YMM_= Usable
is _not_ set. But then looking at the sources I see:

# ifdef USE_AS_STRCASECMP_L
102 ENTRY(__strcasecmp)
103 =A0 =A0 =A0 =A0 .type =A0 __strcasecmp, @gnu_indirect_function
104 =A0 =A0 =A0 =A0 cmpl =A0 =A0$0, __cpu_features+KIND_OFFSET(%rip)=
105 =A0 =A0 =A0 =A0 jne =A0 =A0 1f
106 =A0 =A0 =A0 =A0 call =A0 =A0__init_cpu_features
107 1:
108 # =A0ifdef HAVE_AVX_SUPPORT
109 =A0 =A0 =A0 =A0 leaq =A0 =A0__strcasecmp_avx(%rip), %rax
110 =A0 =A0 =A0 =A0 testl =A0 $bit_AVX, __cpu_features+CPUID_OFFSET+= index_AVX(%rip)
111 =A0 =A0 =A0 =A0 jnz =A0 =A0 2f
112 # =A0endif

which would imply that the AVX bit is sampled here instead of the
YMM one.
[ ... ]
I think Uli's position is that this code only uses AVX encodings, but n= ot the YMM registers and thus the right check is for AVX.

That doesn't make sense to me given the text under availability and sup= port here:

http://software.intel.com/en-= us/articles/introduction-to-intel-advanced-vector-exte= nsions/

According to my reading AVX can only be used if the hardware supports AVX *= and* the OS supports XSAVE. =A0 =A0The only weasel language is "To use= the Intel AVX extensions reliably in most settings ..." =A0Which Uli = might be relying upon for his position.

Ironically, the code in init-arch used to look like:

=A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX)=
=A0 =A0{
=A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
=A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ; bit_OSXSAVE) =3D=3D 0
=A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow;
=A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh;
=A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "=3D= d" (xcrhigh) : "c" (0));
=A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; }))
=A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= =3D ~bit_AVX;
=A0 =A0}


Which I think would have done the right thing. =A0 Uli changed it to the fo= rm you quoted just 2 hours after installing the version I quoted.

If i'm going to make the claim Uli is wrong, some clarification from In= tel would be appreciated.


jeff

--f46d043c8060d0379104bfb4dfea-- --===============7650766948609096804== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7650766948609096804==-- From xen-devel-bounces@lists.xen.org Thu May 10 20:58:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 20: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 ) id 1SSaR0-0003ph-1G; Thu, 10 May 2012 20:58:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSaQy-0003pc-6U for xen-devel@lists.xen.org; Thu, 10 May 2012 20:58:00 +0000 Received: from [85.158.143.99:64141] by server-1.bemta-4.messagelabs.com id 22/4E-20925-7DB2CAF4; Thu, 10 May 2012 20:57:59 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336683477!19904371!1 X-Originating-IP: [209.85.212.169] 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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20830 invoked from network); 10 May 2012 20:57:57 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 10 May 2012 20:57:57 -0000 Received: by wibhn14 with SMTP id hn14so985790wib.2 for ; Thu, 10 May 2012 13:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7e+ORu9pHBf2hJbQ5jygoIqe2WyTJoMf1BbJssvt0d8=; b=IHQxqEsgKAYcNEvjfvLeR+o++yrdI8SohZOpTj0Fo6zrujTaaCcEx2TcgPbXK4WtGw 2NE8sXzWzKEMixjXr6ORLngoss+GTkEb4gOKMRZI1b/TXOgRO4bysXr6ngxI5C8c/p+w 99QGlAHE+yFS82NuerF9zT36bobUuRCaF68/PObZJDemLrXA55cSlqegYJsdwFS5MYXA JUJjppP528OIkmc1S7A85wGZFPxuuAp5X8UTTZUs4w0q5esbqFMJZm56YSBQlvn2rtO5 8rLKyIyH3xPUR0tHju20qt1h68r91gf214YRIq27W4f0/BBiAqwJ4FrtJM0ZvRvNHde3 ucOw== MIME-Version: 1.0 Received: by 10.180.24.103 with SMTP id t7mr1021264wif.16.1336683476825; Thu, 10 May 2012 13:57:56 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 13:57:56 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 13:57:56 -0700 (PDT) In-Reply-To: <4FAC1989.4060201@redhat.com> References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> Date: Thu, 10 May 2012 16:57:56 -0400 X-Google-Sender-Auth: ARnxGWzyJEjdkptla5tgEzR7smk Message-ID: From: Konrad Rzeszutek Wilk To: Jeff Law Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk , haitao.shan@intel.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7650766948609096804==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7650766948609096804== Content-Type: multipart/alternative; boundary=f46d043c8060d0379104bfb4dfea --f46d043c8060d0379104bfb4dfea Content-Type: text/plain; charset=ISO-8859-1 On May 10, 2012 3:40 PM, "Jeff Law" wrote: > > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: >>> >>> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >> >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_AVX) >> >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_OSXSAVE) != 0 >> 151&& ({ unsigned int xcrlow; >> >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> >> 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID flags, I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV guest >> still crashes on that machine) - which means that in multi-lib the bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. > > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but not the YMM registers and thus the right check is for AVX. > > That doesn't make sense to me given the text under availability and support here: > > http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/ > > According to my reading AVX can only be used if the hardware supports AVX *and* the OS supports XSAVE. The only weasel language is "To use the Intel AVX extensions reliably in most settings ..." Which Uli might be relying upon for his position. > > Ironically, the code in init-arch used to look like: > > > if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) > { > > /* Reset the AVX bit in case OSXSAVE is disabled. */ > if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSXSAVE) == 0 > || ({ unsigned int xcrlow; > unsigned int xcrhigh; > asm ("xgetbv" > > : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); > (xcrlow & 6) != 6; })) > > __cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ~bit_AVX; > } > > > Which I think would have done the right thing. Uli changed it to the form you quoted just 2 hours after installing the version I quoted. Sadly no as it would have executed the xgetv instruction. Since the first part of the boolean logic returns false. > > If i'm going to make the claim Uli is wrong, some clarification from Intel would be appreciated. > > > jeff > On May 10, 2012 3:40 PM, "Jeff Law" wrote: > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: > >> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >>> >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx& bit_AVX) >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx& >> bit_OSXSAVE) != 0 >> 151&& ({ unsigned int xcrlow; >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> 156 __cpu_features.feature[index_**YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID >> flags, I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit >> PV guest >> still crashes on that machine) - which means that in multi-lib the >> bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%**rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+** >> index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. >> > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but not > the YMM registers and thus the right check is for AVX. > > That doesn't make sense to me given the text under availability and > support here: > > http://software.intel.com/en-**us/articles/introduction-to-** > intel-advanced-vector-**extensions/ > > According to my reading AVX can only be used if the hardware supports AVX > *and* the OS supports XSAVE. The only weasel language is "To use the > Intel AVX extensions reliably in most settings ..." Which Uli might be > relying upon for his position. > > Ironically, the code in init-arch used to look like: > > if (__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx & bit_AVX) > { > /* Reset the AVX bit in case OSXSAVE is disabled. */ > if ((__cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx & bit_OSXSAVE) > == 0 > || ({ unsigned int xcrlow; > unsigned int xcrhigh; > asm ("xgetbv" > : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); > (xcrlow & 6) != 6; })) > __cpu_features.cpuid[COMMON_**CPUID_INDEX_1].ecx &= ~bit_AVX; > } > > > Which I think would have done the right thing. Uli changed it to the > form you quoted just 2 hours after installing the version I quoted. > > If i'm going to make the claim Uli is wrong, some clarification from Intel > would be appreciated. > > > jeff > > --f46d043c8060d0379104bfb4dfea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 10, 2012 3:40 PM, "Jeff Law" <law@redhat.com> wrote:
>
> On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>>
>>> And finally one always has to keep in mind that there is this = nice
>>> glibc bug in that in some versions it is failing to look at CP= UID.OSXSAVE
>>> when trying to determine whether AVX or FMA is available.
>>
>>
>> It has this:
>> 146
>> 147 =A0 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& = =A0bit_AVX)
>>
>> 148 =A0 =A0 {
>> 149 =A0 =A0 =A0 /* Reset the AVX bit in case OSXSAVE is disabled. = =A0*/
>> 150 =A0 =A0 =A0 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ec= x& =A0bit_OSXSAVE) !=3D 0
>> 151&& =A0({ unsigned int xcrlow;
>>
>> 152 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int xcrhigh;
>> 153 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 asm ("xgetbv"
>> 154 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "=3Da" = (xcrlow), "=3Dd" (xcrhigh) : "c" (0));
>> 155 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (xcrlow& =A06) =3D=3D 6; }= ))
>>
>> 156 =A0 =A0 =A0 =A0 __cpu_features.feature[index_YMM_Usable] |=3D = bit_YMM_Usable;
>> 157 =A0 =A0 }
>>
>>
>> And when I ran a little silly C program (attached) to probe the CP= UID flags, I got:
>> =A0/root/test-xsave
>> SSE3 CMOV
>> AVX =A0XSAVE
>> Trying XGETBV
>> Illegal instruction (core dumped)
>>
>> Which would imply that the OSXSAVE is not set (but Fedora Core 17 = 64-bit PV guest
>> still crashes on that machine) - which means that in multi-lib the= bit_YMM_Usable
>> is _not_ set. But then looking at the sources I see:
>>
>> # ifdef USE_AS_STRCASECMP_L
>> 102 ENTRY(__strcasecmp)
>> 103 =A0 =A0 =A0 =A0 .type =A0 __strcasecmp, @gnu_indirect_function=
>> 104 =A0 =A0 =A0 =A0 cmpl =A0 =A0$0, __cpu_features+KIND_OFFSET(%ri= p)
>> 105 =A0 =A0 =A0 =A0 jne =A0 =A0 1f
>> 106 =A0 =A0 =A0 =A0 call =A0 =A0__init_cpu_features
>> 107 1:
>> 108 # =A0ifdef HAVE_AVX_SUPPORT
>> 109 =A0 =A0 =A0 =A0 leaq =A0 =A0__strcasecmp_avx(%rip), %rax
>> 110 =A0 =A0 =A0 =A0 testl =A0 $bit_AVX, __cpu_features+CPUID_OFFSE= T+index_AVX(%rip)
>> 111 =A0 =A0 =A0 =A0 jnz =A0 =A0 2f
>> 112 # =A0endif
>>
>> which would imply that the AVX bit is sampled here instead of the<= br> >> YMM one.
>
> [ ... ]
> I think Uli's position is that this code only uses AVX encodings, = but not the YMM registers and thus the right check is for AVX.
>
> That doesn't make sense to me given the text under availability an= d support here:
>
> http://software.intel.com/en-us/articles/i= ntroduction-to-intel-advanced-vector-extensions/
>
> According to my reading AVX can only be used if the hardware supports = AVX *and* the OS supports XSAVE. =A0 =A0The only weasel language is "T= o use the Intel AVX extensions reliably in most settings ..." =A0Which= Uli might be relying upon for his position.
>
> Ironically, the code in init-arch used to look like:
>
>
> =A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) > =A0 =A0{
>
> =A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
> =A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & b= it_OSXSAVE) =3D=3D 0
> =A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv"
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "= ;=3Dd" (xcrhigh) : "c" (0));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; }))
>
> =A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &=3D= ~bit_AVX;
> =A0 =A0}
>
>
> Which I think would have done the right thing. =A0 Uli changed it to t= he form you quoted just 2 hours after installing the version I quoted.

Sadly no as it would have executed the xgetv instruction. Since the firs= t part of the boolean logic returns false.
>
> If i'm going to make the claim Uli is wrong, some clarification fr= om Intel would be appreciated.
>
>
> jeff
>

On May 10, 2012 3:40 PM, "Jeff Law" &l= t;law@redhat.com> wrote:
On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote:

And finally one always has to keep in mind that there is this nice
glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE when trying to determine whether AVX or FMA is available.

It has this:
146
147 =A0 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& =A0b= it_AVX)
148 =A0 =A0 {
149 =A0 =A0 =A0 /* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
150 =A0 =A0 =A0 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx&= amp; =A0bit_OSXSAVE) !=3D 0
151&& =A0({ unsigned int xcrlow;
152 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int xcrhigh;
153 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 asm ("xgetbv"
154 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "=3Da" (xcrlow),= "=3Dd" (xcrhigh) : "c" (0));
155 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (xcrlow& =A06) =3D=3D 6; }))
156 =A0 =A0 =A0 =A0 __cpu_features.feature[index_YMM_Usable] |=3D bi= t_YMM_Usable;
157 =A0 =A0 }


And when I ran a little silly C program (attached) to probe the CPUID flags= , I got:
=A0/root/test-xsave
SSE3 CMOV
AVX =A0XSAVE
Trying XGETBV
Illegal instruction (core dumped)

Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV= guest
still crashes on that machine) - which means that in multi-lib the bit_YMM_= Usable
is _not_ set. But then looking at the sources I see:

# ifdef USE_AS_STRCASECMP_L
102 ENTRY(__strcasecmp)
103 =A0 =A0 =A0 =A0 .type =A0 __strcasecmp, @gnu_indirect_function
104 =A0 =A0 =A0 =A0 cmpl =A0 =A0$0, __cpu_features+KIND_OFFSET(%rip)=
105 =A0 =A0 =A0 =A0 jne =A0 =A0 1f
106 =A0 =A0 =A0 =A0 call =A0 =A0__init_cpu_features
107 1:
108 # =A0ifdef HAVE_AVX_SUPPORT
109 =A0 =A0 =A0 =A0 leaq =A0 =A0__strcasecmp_avx(%rip), %rax
110 =A0 =A0 =A0 =A0 testl =A0 $bit_AVX, __cpu_features+CPUID_OFFSET+= index_AVX(%rip)
111 =A0 =A0 =A0 =A0 jnz =A0 =A0 2f
112 # =A0endif

which would imply that the AVX bit is sampled here instead of the
YMM one.
[ ... ]
I think Uli's position is that this code only uses AVX encodings, but n= ot the YMM registers and thus the right check is for AVX.

That doesn't make sense to me given the text under availability and sup= port here:

http://software.intel.com/en-= us/articles/introduction-to-intel-advanced-vector-exte= nsions/

According to my reading AVX can only be used if the hardware supports AVX *= and* the OS supports XSAVE. =A0 =A0The only weasel language is "To use= the Intel AVX extensions reliably in most settings ..." =A0Which Uli = might be relying upon for his position.

Ironically, the code in init-arch used to look like:

=A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX)=
=A0 =A0{
=A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/
=A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= ; bit_OSXSAVE) =3D=3D 0
=A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow;
=A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh;
=A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "=3D= d" (xcrhigh) : "c" (0));
=A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; }))
=A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &= =3D ~bit_AVX;
=A0 =A0}


Which I think would have done the right thing. =A0 Uli changed it to the fo= rm you quoted just 2 hours after installing the version I quoted.

If i'm going to make the claim Uli is wrong, some clarification from In= tel would be appreciated.


jeff

--f46d043c8060d0379104bfb4dfea-- --===============7650766948609096804== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7650766948609096804==-- From xen-devel-bounces@lists.xen.org Thu May 10 21:26:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 21: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 ) id 1SSasP-00045z-KH; Thu, 10 May 2012 21:26:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSasO-00045u-5u for xen-devel@lists.xensource.com; Thu, 10 May 2012 21:26:20 +0000 Received: from [85.158.143.99:42589] by server-1.bemta-4.messagelabs.com id 97/30-20925-B723CAF4; Thu, 10 May 2012 21:26:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336685178!21055655!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25952 invoked from network); 10 May 2012 21:26:18 -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 May 2012 21:26:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="12417329" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 21:26: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, 10 May 2012 22:26:18 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSasL-0001Vt-VV; Thu, 10 May 2012 21:26:18 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSasL-0000bQ-VE; Thu, 10 May 2012 22:26:17 +0100 To: Message-ID: From: xen.org Date: Thu, 10 May 2012 22:26:17 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12834: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12834 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12834/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pair 16 guest-start fail REGR. vs. 12827 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12827 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 12827 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 60064411a8a9 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 21:26:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 21: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 ) id 1SSasP-00045z-KH; Thu, 10 May 2012 21:26:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSasO-00045u-5u for xen-devel@lists.xensource.com; Thu, 10 May 2012 21:26:20 +0000 Received: from [85.158.143.99:42589] by server-1.bemta-4.messagelabs.com id 97/30-20925-B723CAF4; Thu, 10 May 2012 21:26:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336685178!21055655!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODA1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25952 invoked from network); 10 May 2012 21:26:18 -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 May 2012 21:26:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,567,1330905600"; d="scan'208";a="12417329" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 10 May 2012 21:26: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, 10 May 2012 22:26:18 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSasL-0001Vt-VV; Thu, 10 May 2012 21:26:18 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSasL-0000bQ-VE; Thu, 10 May 2012 22:26:17 +0100 To: Message-ID: From: xen.org Date: Thu, 10 May 2012 22:26:17 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12834: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12834 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12834/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-i386-i386-pair 16 guest-start fail REGR. vs. 12827 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12827 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 12827 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore 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-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 60064411a8a9 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair fail test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 22:42:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 22: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 ) id 1SSc3N-00060f-7y; Thu, 10 May 2012 22:41:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSc3K-00060Y-VL for xen-devel@lists.xen.org; Thu, 10 May 2012 22:41:43 +0000 Received: from [85.158.143.99:32449] by server-2.bemta-4.messagelabs.com id 38/60-17550-6244CAF4; Thu, 10 May 2012 22:41:42 +0000 X-Env-Sender: jfehlig@suse.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336689697!17672707!1 X-Originating-IP: [137.65.250.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29861 invoked from network); 10 May 2012 22:41:40 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 22:41:40 -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); Thu, 10 May 2012 16:41:30 -0600 Message-ID: <4FAC4419.60808@suse.com> Date: Thu, 10 May 2012 16:41:29 -0600 From: Jim Fehlig User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: "Daniel P. Berrange" References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> <1336643766.7098.40.camel@zakaz.uk.xensource.com> <20120510101043.GH1223@redhat.com> In-Reply-To: <20120510101043.GH1223@redhat.com> Cc: Ian Campbell , "libvir-list@redhat.com" , Ian Jackson , "xen-devel@lists.xen.org" , Bamvor Jian Zhang , Daniel De Graaf Subject: Re: [Xen-devel] [libvirt] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel P. Berrange wrote: > On Thu, May 10, 2012 at 10:56:06AM +0100, Ian Campbell wrote: > >> On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: >> >>> This patch changes libxl to use the interface in Xen 4.2. It is provided >>> as an example, not intended to go in to libvirt as-is since it removes >>> all support for libxl from Xen 4.1. It also still has some cruft (extra >>> void casts on parameters) and the device model info population is not >>> written. It has been tested with simple domain create/destroy. >>> --- >>> src/libxl/libxl_conf.c | 134 +++++++++------ >>> src/libxl/libxl_conf.h | 8 +- >>> src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- >>> 3 files changed, 326 insertions(+), 246 deletions(-) >>> >> Thanks Daniel, interesting to see. It doesn't seem as invasive as I >> expected given the number of changes to libxl's interfaces between 4.1 >> and 4.2. >> >> I suppose it is worth mentioning in this context that we are intending >> to maintain the 4.2 libxl API in a stable manner going forward, as >> described near the top of: >> http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h >> >> Since libvirt is one of the main reasons we are doing this it would be >> useful to check that this actually meets the needs from that side. >> > > Having a long term stable API for libxl certainly gets our vote. > > WRT the use of LIBXL_API_VERSION to control API version. Libvirt generally > aims to support all possible API versions, so I expect we would not want > to define LIBXL_API_VERSION. Instead the libvirt code would #ifdef various > bits according to the libxl version it detects. > > >> That doesn't really help with support 4.1 and 4.2+. A large portion of >> the below looks like it would be reasonably easy to abstract away with a >> header full of compat defines for naming changes etc, other bits don't >> look so simple to deal with. >> > > Personally I would prefer to keep support for all 4.x versions, but I'll > defer to Suse developers to decide upon this since they are the primary > maintainers & users of the libxl driver. > Yes, I too would like to keep support for all 4.x versions. As pointed out by you and Ian, it can be detected at build time vs the runtime probing that the legacy xen libvirt driver does. Bamvor has just started looking into this, so hopefully he can help with the effort. Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu May 10 22:42:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 May 2012 22: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 ) id 1SSc3N-00060f-7y; Thu, 10 May 2012 22:41:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSc3K-00060Y-VL for xen-devel@lists.xen.org; Thu, 10 May 2012 22:41:43 +0000 Received: from [85.158.143.99:32449] by server-2.bemta-4.messagelabs.com id 38/60-17550-6244CAF4; Thu, 10 May 2012 22:41:42 +0000 X-Env-Sender: jfehlig@suse.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336689697!17672707!1 X-Originating-IP: [137.65.250.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29861 invoked from network); 10 May 2012 22:41:40 -0000 Received: from victor.provo.novell.com (HELO victor.provo.novell.com) (137.65.250.26) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2012 22:41:40 -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); Thu, 10 May 2012 16:41:30 -0600 Message-ID: <4FAC4419.60808@suse.com> Date: Thu, 10 May 2012 16:41:29 -0600 From: Jim Fehlig User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: "Daniel P. Berrange" References: <20394.36444.760368.974206@mariner.uk.xensource.com> <1336583603-7029-1-git-send-email-dgdegra@tycho.nsa.gov> <1336643766.7098.40.camel@zakaz.uk.xensource.com> <20120510101043.GH1223@redhat.com> In-Reply-To: <20120510101043.GH1223@redhat.com> Cc: Ian Campbell , "libvir-list@redhat.com" , Ian Jackson , "xen-devel@lists.xen.org" , Bamvor Jian Zhang , Daniel De Graaf Subject: Re: [Xen-devel] [libvirt] [PATCH-RFC] Change libxl to use Xen 4.2 interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Daniel P. Berrange wrote: > On Thu, May 10, 2012 at 10:56:06AM +0100, Ian Campbell wrote: > >> On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote: >> >>> This patch changes libxl to use the interface in Xen 4.2. It is provided >>> as an example, not intended to go in to libvirt as-is since it removes >>> all support for libxl from Xen 4.1. It also still has some cruft (extra >>> void casts on parameters) and the device model info population is not >>> written. It has been tested with simple domain create/destroy. >>> --- >>> src/libxl/libxl_conf.c | 134 +++++++++------ >>> src/libxl/libxl_conf.h | 8 +- >>> src/libxl/libxl_driver.c | 430 ++++++++++++++++++++++++++-------------------- >>> 3 files changed, 326 insertions(+), 246 deletions(-) >>> >> Thanks Daniel, interesting to see. It doesn't seem as invasive as I >> expected given the number of changes to libxl's interfaces between 4.1 >> and 4.2. >> >> I suppose it is worth mentioning in this context that we are intending >> to maintain the 4.2 libxl API in a stable manner going forward, as >> described near the top of: >> http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h >> >> Since libvirt is one of the main reasons we are doing this it would be >> useful to check that this actually meets the needs from that side. >> > > Having a long term stable API for libxl certainly gets our vote. > > WRT the use of LIBXL_API_VERSION to control API version. Libvirt generally > aims to support all possible API versions, so I expect we would not want > to define LIBXL_API_VERSION. Instead the libvirt code would #ifdef various > bits according to the libxl version it detects. > > >> That doesn't really help with support 4.1 and 4.2+. A large portion of >> the below looks like it would be reasonably easy to abstract away with a >> header full of compat defines for naming changes etc, other bits don't >> look so simple to deal with. >> > > Personally I would prefer to keep support for all 4.x versions, but I'll > defer to Suse developers to decide upon this since they are the primary > maintainers & users of the libxl driver. > Yes, I too would like to keep support for all 4.x versions. As pointed out by you and Ian, it can be detected at build time vs the runtime probing that the legacy xen libvirt driver does. Bamvor has just started looking into this, so hopefully he can help with the effort. Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 00:59:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 00: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 ) id 1SSeBe-0007pd-5z; Fri, 11 May 2012 00:58:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeBc-0007pY-Fv for xen-devel@lists.xen.org; Fri, 11 May 2012 00:58:24 +0000 Received: from [193.109.254.147:62798] by server-9.bemta-14.messagelabs.com id 7B/3B-05787-F246CAF4; Fri, 11 May 2012 00:58:23 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336697902!1823178!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 491 invoked from network); 11 May 2012 00:58:23 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 00:58:23 -0000 Received: by werf3 with SMTP id f3so964674wer.32 for ; Thu, 10 May 2012 17:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oIMcTKueWRu/OwwTmbZRnIRzK9Bb7ERFTuEBHef3QzA=; b=d6BUDVfgVooEZ3Y9UNsRtCS7w8v+57A+/IxObR6BT2TxV/W6c+H9/D9+u2tjqZQxA8 mQVC38+eEAyUf8DhRnNR1dHeNbQtwR6TqfBWAoY3ravRvq2GzxQk8fnB7T3znG3mtDjE FAzaQE7IFr0Wc1m1pEid8XcOFO2iYSuwWNOAwTgLIKsAybnsrp52zSz2oN/8CDdhCIAp QZh8H/LM0bzQ72B3NiyeHGIh/U1d6z8l/hbe2tn/2FXuEOoOuvHrE9EeF4IcCgAcwIOE nUY07JgFjFc0WiAokFS/BPhS1nAlEMifSTd5VRtRqyKN83F2y8bymvRnR6BoORkTa9Cd UmIw== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr2595390wib.13.1336697902656; Thu, 10 May 2012 17:58:22 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 17:58:22 -0700 (PDT) In-Reply-To: References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> Date: Thu, 10 May 2012 20:58:22 -0400 X-Google-Sender-Auth: yxv_8iwrL-6OtpGhDz1QsB-Isck Message-ID: From: Konrad Rzeszutek Wilk To: Jeff Law Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk , haitao.shan@intel.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> Ironically, the code in init-arch used to look like: >> >> >> =A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) >> =A0 =A0{ >> >> =A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/ >> =A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSX= SAVE) =3D=3D >> 0 >> =A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv" >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "=3Dd" (xcrhigh) = : "c" (0)); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; })) >> >> =A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &=3D ~bit_= AVX; >> =A0 =A0} >> >> >> Which I think would have done the right thing. =A0 Uli changed it to the >> form you quoted just 2 hours after installing the version I quoted. > > Sadly no as it would have executed the xgetv instruction. Since the first > part of the boolean logic returns false. And that is what I get from typing this while stopping at lights and being in a hurry and doing this on a cellphone. Please ignore what I said above - the earlier version would have worked cor= rect. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 00:59:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 00: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 ) id 1SSeBe-0007pd-5z; Fri, 11 May 2012 00:58:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeBc-0007pY-Fv for xen-devel@lists.xen.org; Fri, 11 May 2012 00:58:24 +0000 Received: from [193.109.254.147:62798] by server-9.bemta-14.messagelabs.com id 7B/3B-05787-F246CAF4; Fri, 11 May 2012 00:58:23 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336697902!1823178!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 491 invoked from network); 11 May 2012 00:58:23 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 00:58:23 -0000 Received: by werf3 with SMTP id f3so964674wer.32 for ; Thu, 10 May 2012 17:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oIMcTKueWRu/OwwTmbZRnIRzK9Bb7ERFTuEBHef3QzA=; b=d6BUDVfgVooEZ3Y9UNsRtCS7w8v+57A+/IxObR6BT2TxV/W6c+H9/D9+u2tjqZQxA8 mQVC38+eEAyUf8DhRnNR1dHeNbQtwR6TqfBWAoY3ravRvq2GzxQk8fnB7T3znG3mtDjE FAzaQE7IFr0Wc1m1pEid8XcOFO2iYSuwWNOAwTgLIKsAybnsrp52zSz2oN/8CDdhCIAp QZh8H/LM0bzQ72B3NiyeHGIh/U1d6z8l/hbe2tn/2FXuEOoOuvHrE9EeF4IcCgAcwIOE nUY07JgFjFc0WiAokFS/BPhS1nAlEMifSTd5VRtRqyKN83F2y8bymvRnR6BoORkTa9Cd UmIw== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr2595390wib.13.1336697902656; Thu, 10 May 2012 17:58:22 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Thu, 10 May 2012 17:58:22 -0700 (PDT) In-Reply-To: References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> Date: Thu, 10 May 2012 20:58:22 -0400 X-Google-Sender-Auth: yxv_8iwrL-6OtpGhDz1QsB-Isck Message-ID: From: Konrad Rzeszutek Wilk To: Jeff Law Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, Konrad Rzeszutek Wilk , haitao.shan@intel.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> Ironically, the code in init-arch used to look like: >> >> >> =A0if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_AVX) >> =A0 =A0{ >> >> =A0 =A0 =A0/* Reset the AVX bit in case OSXSAVE is disabled. =A0*/ >> =A0 =A0 =A0if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx & bit_OSX= SAVE) =3D=3D >> 0 >> =A0 =A0 =A0 =A0 =A0|| ({ unsigned int xcrlow; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned int xcrhigh; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0asm ("xgetbv" >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : "=3Da" (xcrlow), "=3Dd" (xcrhigh) = : "c" (0)); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0(xcrlow & 6) !=3D 6; })) >> >> =A0 =A0 =A0 =A0__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx &=3D ~bit_= AVX; >> =A0 =A0} >> >> >> Which I think would have done the right thing. =A0 Uli changed it to the >> form you quoted just 2 hours after installing the version I quoted. > > Sadly no as it would have executed the xgetv instruction. Since the first > part of the boolean logic returns false. And that is what I get from typing this while stopping at lights and being in a hurry and doing this on a cellphone. Please ignore what I said above - the earlier version would have worked cor= rect. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 01:03:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 01:03:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeFi-0003Id-Rd; Fri, 11 May 2012 01:02:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeFh-0003IU-6m for Xen-devel@lists.xensource.com; Fri, 11 May 2012 01:02:37 +0000 Received: from [85.158.143.99:26655] by server-2.bemta-4.messagelabs.com id 1E/10-17550-C256CAF4; Fri, 11 May 2012 01:02:36 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336698154!19922756!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNTk0Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11016 invoked from network); 11 May 2012 01:02:35 -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; 11 May 2012 01:02:35 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4B12R5j002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 01:02: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 q4B12Rq9021181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 01:02:27 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 q4B12Qa3002455; Thu, 10 May 2012 20:02:26 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 18:02:26 -0700 Date: Thu, 10 May 2012 18:02:13 -0700 From: Mukesh Rathor To: "Xen-devel@lists.xensource.com" , Ian Campbell , "stefano.stabellini@eu.citrix.com" , Keir Fraser Message-ID: <20120510180213.6083e857@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Guys, Cheers.... JFYI... I've all combinations working now, for both UP and MP. Normal PV dom0: PV domU, Hyb domU, HVM domU Hybrid dom0: PV domU, Hyb domU, HVM domU. So, next now: - refresh my linux and xen trees to latest. i'm on xen 4.1.3. - make sure everything works with latest, and without tons of debug code i've there right now ;). - test it out a bit. - submit patch. - once patch is accepted, do more benchmarks and improvements over time. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 01:03:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 01:03:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeFi-0003Id-Rd; Fri, 11 May 2012 01:02:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSeFh-0003IU-6m for Xen-devel@lists.xensource.com; Fri, 11 May 2012 01:02:37 +0000 Received: from [85.158.143.99:26655] by server-2.bemta-4.messagelabs.com id 1E/10-17550-C256CAF4; Fri, 11 May 2012 01:02:36 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336698154!19922756!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNTk0Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11016 invoked from network); 11 May 2012 01:02:35 -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; 11 May 2012 01:02:35 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4B12R5j002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 01:02: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 q4B12Rq9021181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 01:02:27 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 q4B12Qa3002455; Thu, 10 May 2012 20:02:26 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 18:02:26 -0700 Date: Thu, 10 May 2012 18:02:13 -0700 From: Mukesh Rathor To: "Xen-devel@lists.xensource.com" , Ian Campbell , "stefano.stabellini@eu.citrix.com" , Keir Fraser Message-ID: <20120510180213.6083e857@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Guys, Cheers.... JFYI... I've all combinations working now, for both UP and MP. Normal PV dom0: PV domU, Hyb domU, HVM domU Hybrid dom0: PV domU, Hyb domU, HVM domU. So, next now: - refresh my linux and xen trees to latest. i'm on xen 4.1.3. - make sure everything works with latest, and without tons of debug code i've there right now ;). - test it out a bit. - submit patch. - once patch is accepted, do more benchmarks and improvements over time. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 01:47:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 01:47:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSewV-0003dL-GL; Fri, 11 May 2012 01:46:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSewU-0003dG-MY for Xen-devel@lists.xensource.com; Fri, 11 May 2012 01:46:50 +0000 Received: from [193.109.254.147:13019] by server-11.bemta-14.messagelabs.com id 31/E9-05858-98F6CAF4; Fri, 11 May 2012 01:46:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336700808!8671223!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIzNjIz\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18981 invoked from network); 11 May 2012 01:46:49 -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; 11 May 2012 01:46:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4B1kfEU024559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 01:46:42 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4B1keeB021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 01:46:41 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 q4B1keEM021347; Thu, 10 May 2012 20:46:40 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 18:46:39 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 45A5440359; Thu, 10 May 2012 21:40:36 -0400 (EDT) Date: Thu, 10 May 2012 21:40:36 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20120511014036.GA12150@phenom.dumpdata.com> References: <20120510180213.6083e857@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510180213.6083e857@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Ian Campbell , "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > Hi Guys, > > > Cheers.... JFYI... I've all combinations working now, for both UP and > MP. YEEEY! > > Normal PV dom0: PV domU, Hyb domU, HVM domU > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > So, next now: > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > - make sure everything works with latest, and without tons of debug > code i've there right now ;). > - test it out a bit. > - submit patch. > - once patch is accepted, do more benchmarks and improvements over > time. > > thanks, > Mukesh > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 01:47:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 01:47:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSewV-0003dL-GL; Fri, 11 May 2012 01:46:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSewU-0003dG-MY for Xen-devel@lists.xensource.com; Fri, 11 May 2012 01:46:50 +0000 Received: from [193.109.254.147:13019] by server-11.bemta-14.messagelabs.com id 31/E9-05858-98F6CAF4; Fri, 11 May 2012 01:46:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336700808!8671223!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTIzNjIz\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18981 invoked from network); 11 May 2012 01:46:49 -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; 11 May 2012 01:46:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4B1kfEU024559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 01:46:42 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4B1keeB021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 01:46:41 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 q4B1keEM021347; Thu, 10 May 2012 20:46:40 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2012 18:46:39 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 45A5440359; Thu, 10 May 2012 21:40:36 -0400 (EDT) Date: Thu, 10 May 2012 21:40:36 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20120511014036.GA12150@phenom.dumpdata.com> References: <20120510180213.6083e857@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510180213.6083e857@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Ian Campbell , "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > Hi Guys, > > > Cheers.... JFYI... I've all combinations working now, for both UP and > MP. YEEEY! > > Normal PV dom0: PV domU, Hyb domU, HVM domU > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > So, next now: > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > - make sure everything works with latest, and without tons of debug > code i've there right now ;). > - test it out a bit. > - submit patch. > - once patch is accepted, do more benchmarks and improvements over > time. > > thanks, > Mukesh > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 02:23:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 02: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 ) id 1SSfUz-0004Bf-F4; Fri, 11 May 2012 02:22:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSfUx-0004Ba-Vw for xen-devel@lists.xensource.com; Fri, 11 May 2012 02:22:28 +0000 Received: from [85.158.138.51:41843] by server-3.bemta-3.messagelabs.com id 95/0E-04048-3E77CAF4; Fri, 11 May 2012 02:22:27 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336702945!26516987!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMyNjYz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6478 invoked from network); 11 May 2012 02:22:26 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-174.messagelabs.com with SMTP; 11 May 2012 02:22:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 10 May 2012 19:22:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98785561" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 10 May 2012 19:22:20 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 19:22:20 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Fri, 11 May 2012 10:22:18 +0800 From: "Zhang, Yang Z" To: Ian Jackson Thread-Topic: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus Thread-Index: Ac0poYSvmJALVq5wRuSA2SJW/RtHzwE6M3uAACPaVvA= Date: Fri, 11 May 2012 02:22:17 +0000 Message-ID: References: <20395.62069.578209.953705@mariner.uk.xensource.com> In-Reply-To: <20395.62069.578209.953705@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Friday, May 11, 2012 12:53 AM > Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus > > Zhang, Yang Z writes ("[Xen-devel] [PATCH]libxl: allow to set more than 31 > vcpus"): > > libxl: allow to set more than 31 vcpus > > > > In current implementation, it uses integer for record current avail cpus and > this only allows user to specify 31 vcpus. > > In following patch, it uses cpumap instead interger which make more sense > than before. Also there is no limit to the max vcpus. > ... > > - if (!b_info->cur_vcpus) > > - b_info->cur_vcpus = 1; > > + if (!b_info->avail_vcpus.size) { > > + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) > > + return ERROR_NOMEM; > > + libxl_cpumap_set(&b_info->avail_vcpus, 0); > > + } > > This error handling should really go away. Would you be able to > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > That never fails, so that would also mean libxl_cpumap_alloc can't > fail. I don't think so. Libxl_cpumap_alloc() also returned error when max_cpus equal zero. So the error handling cannot be avoid even using libxl__zalloc. > This is an arbitrary precision conversion to hex. Wouldn't it be > better to provide libxl_cpumap_set_all, and libxl_cpumap_hexmask or > something ? Yes, it's better to use a function to do the convert cpumap to hex. > > @@ -437,11 +462,16 @@ static char ** libxl__build_device_model > > } > > if (b_info->max_vcpus > 1) { > > flexarray_append(dm_args, "-smp"); > > - if (b_info->cur_vcpus) > > + if (b_info->avail_vcpus.size) { > > + int i, nr_set_cpus = 0; > > + libxl_for_each_set_cpu(i, > > + ((libxl_domain_build_info > *)b_info)->avail_vcpus) > > + nr_set_cpus++; > > If we had libxl_cpumap_count_set this would be clearer. Agree. > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > for (i = 0; i < info->max_vcpus; i++) { > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > << i))) > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > + > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > ? "offline" : "online"; > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > simpler. Sorry. What your mean for this? Best regard yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 02:23:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 02: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 ) id 1SSfUz-0004Bf-F4; Fri, 11 May 2012 02:22:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSfUx-0004Ba-Vw for xen-devel@lists.xensource.com; Fri, 11 May 2012 02:22:28 +0000 Received: from [85.158.138.51:41843] by server-3.bemta-3.messagelabs.com id 95/0E-04048-3E77CAF4; Fri, 11 May 2012 02:22:27 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336702945!26516987!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMyNjYz\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6478 invoked from network); 11 May 2012 02:22:26 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-9.tower-174.messagelabs.com with SMTP; 11 May 2012 02:22:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 10 May 2012 19:22:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98785561" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 10 May 2012 19:22:20 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 May 2012 19:22:20 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Fri, 11 May 2012 10:22:18 +0800 From: "Zhang, Yang Z" To: Ian Jackson Thread-Topic: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus Thread-Index: Ac0poYSvmJALVq5wRuSA2SJW/RtHzwE6M3uAACPaVvA= Date: Fri, 11 May 2012 02:22:17 +0000 Message-ID: References: <20395.62069.578209.953705@mariner.uk.xensource.com> In-Reply-To: <20395.62069.578209.953705@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Friday, May 11, 2012 12:53 AM > Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus > > Zhang, Yang Z writes ("[Xen-devel] [PATCH]libxl: allow to set more than 31 > vcpus"): > > libxl: allow to set more than 31 vcpus > > > > In current implementation, it uses integer for record current avail cpus and > this only allows user to specify 31 vcpus. > > In following patch, it uses cpumap instead interger which make more sense > than before. Also there is no limit to the max vcpus. > ... > > - if (!b_info->cur_vcpus) > > - b_info->cur_vcpus = 1; > > + if (!b_info->avail_vcpus.size) { > > + if (libxl_cpumap_alloc_size(CTX, &b_info->avail_vcpus, 1)) > > + return ERROR_NOMEM; > > + libxl_cpumap_set(&b_info->avail_vcpus, 0); > > + } > > This error handling should really go away. Would you be able to > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > That never fails, so that would also mean libxl_cpumap_alloc can't > fail. I don't think so. Libxl_cpumap_alloc() also returned error when max_cpus equal zero. So the error handling cannot be avoid even using libxl__zalloc. > This is an arbitrary precision conversion to hex. Wouldn't it be > better to provide libxl_cpumap_set_all, and libxl_cpumap_hexmask or > something ? Yes, it's better to use a function to do the convert cpumap to hex. > > @@ -437,11 +462,16 @@ static char ** libxl__build_device_model > > } > > if (b_info->max_vcpus > 1) { > > flexarray_append(dm_args, "-smp"); > > - if (b_info->cur_vcpus) > > + if (b_info->avail_vcpus.size) { > > + int i, nr_set_cpus = 0; > > + libxl_for_each_set_cpu(i, > > + ((libxl_domain_build_info > *)b_info)->avail_vcpus) > > + nr_set_cpus++; > > If we had libxl_cpumap_count_set this would be clearer. Agree. > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > for (i = 0; i < info->max_vcpus; i++) { > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > << i))) > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > + > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > ? "offline" : "online"; > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > simpler. Sorry. What your mean for this? Best regard yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 03:27:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 03:27:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSgVE-0004a7-Vr; Fri, 11 May 2012 03:26:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSgVE-0004a2-58 for xen-devel@lists.xensource.com; Fri, 11 May 2012 03:26:48 +0000 Received: from [85.158.143.99:3628] by server-1.bemta-4.messagelabs.com id ED/BB-20925-7F68CAF4; Fri, 11 May 2012 03:26:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336706805!26565245!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2045 invoked from network); 11 May 2012 03:26:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 03:26:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,569,1330905600"; d="scan'208";a="12419269" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 03:26: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, 11 May 2012 04:26:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSgV8-0003PG-TU; Fri, 11 May 2012 03:26:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSgV8-00010N-HW; Fri, 11 May 2012 04:26:42 +0100 To: Message-ID: From: xen.org Date: Fri, 11 May 2012 04:26:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12849: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12849 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12849/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12827 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 12827 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 54c8c9eaee92 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=54c8c9eaee92 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 54c8c9eaee92 + branch=xen-unstable + revision=54c8c9eaee92 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 54c8c9eaee92 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 18 changesets with 27 changes to 26 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 03:27:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 03:27:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSgVE-0004a7-Vr; Fri, 11 May 2012 03:26:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSgVE-0004a2-58 for xen-devel@lists.xensource.com; Fri, 11 May 2012 03:26:48 +0000 Received: from [85.158.143.99:3628] by server-1.bemta-4.messagelabs.com id ED/BB-20925-7F68CAF4; Fri, 11 May 2012 03:26:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336706805!26565245!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2045 invoked from network); 11 May 2012 03:26:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 03:26:45 -0000 X-IronPort-AV: E=Sophos;i="4.75,569,1330905600"; d="scan'208";a="12419269" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 03:26: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, 11 May 2012 04:26:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSgV8-0003PG-TU; Fri, 11 May 2012 03:26:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSgV8-00010N-HW; Fri, 11 May 2012 04:26:42 +0100 To: Message-ID: From: xen.org Date: Fri, 11 May 2012 04:26:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12849: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12849 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12849/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12827 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 12827 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 54c8c9eaee92 baseline version: xen 8a86d841e6d4 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=54c8c9eaee92 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 54c8c9eaee92 + branch=xen-unstable + revision=54c8c9eaee92 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 54c8c9eaee92 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 18 changesets with 27 changes to 26 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 06:15:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 06:15:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSj7g-0005Zh-NM; Fri, 11 May 2012 06:14:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSj7f-0005Zc-Cd for Xen-devel@lists.xensource.com; Fri, 11 May 2012 06:14:39 +0000 Received: from [85.158.138.51:13027] by server-6.bemta-3.messagelabs.com id 82/58-05145-E4EACAF4; Fri, 11 May 2012 06:14:38 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-174.messagelabs.com!1336716877!26519544!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDQ1MTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16587 invoked from network); 11 May 2012 06:14:38 -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; 11 May 2012 06:14:38 -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 D35591424; Fri, 11 May 2012 09:14:35 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 34A5B2005D; Fri, 11 May 2012 09:14:35 +0300 (EEST) Date: Fri, 11 May 2012 09:14:35 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Mukesh Rathor Message-ID: <20120511061435.GK2058@reaktio.net> References: <20120510180213.6083e857@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510180213.6083e857@mantra.us.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Ian Campbell , "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > Hi Guys, > > > Cheers.... JFYI... I've all combinations working now, for both UP and > MP. > > Normal PV dom0: PV domU, Hyb domU, HVM domU > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > So, next now: > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > - make sure everything works with latest, and without tons of debug > code i've there right now ;). > - test it out a bit. > - submit patch. > - once patch is accepted, do more benchmarks and improvements over > time. > Great! Looking forward to testing the patch :) Thank you a lot for your hard work! -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 06:15:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 06:15:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSj7g-0005Zh-NM; Fri, 11 May 2012 06:14:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSj7f-0005Zc-Cd for Xen-devel@lists.xensource.com; Fri, 11 May 2012 06:14:39 +0000 Received: from [85.158.138.51:13027] by server-6.bemta-3.messagelabs.com id 82/58-05145-E4EACAF4; Fri, 11 May 2012 06:14:38 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-174.messagelabs.com!1336716877!26519544!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDQ1MTc=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16587 invoked from network); 11 May 2012 06:14:38 -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; 11 May 2012 06:14:38 -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 D35591424; Fri, 11 May 2012 09:14:35 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 34A5B2005D; Fri, 11 May 2012 09:14:35 +0300 (EEST) Date: Fri, 11 May 2012 09:14:35 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Mukesh Rathor Message-ID: <20120511061435.GK2058@reaktio.net> References: <20120510180213.6083e857@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120510180213.6083e857@mantra.us.oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Ian Campbell , "stefano.stabellini@eu.citrix.com" Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > Hi Guys, > > > Cheers.... JFYI... I've all combinations working now, for both UP and > MP. > > Normal PV dom0: PV domU, Hyb domU, HVM domU > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > So, next now: > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > - make sure everything works with latest, and without tons of debug > code i've there right now ;). > - test it out a bit. > - submit patch. > - once patch is accepted, do more benchmarks and improvements over > time. > Great! Looking forward to testing the patch :) Thank you a lot for your hard work! -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 07:19:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 07: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 ) id 1SSk82-00063W-6j; Fri, 11 May 2012 07:19:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSk80-00063R-3w for xen-devel@lists.xen.org; Fri, 11 May 2012 07:19:04 +0000 Received: from [193.109.254.147:29540] by server-5.bemta-14.messagelabs.com id 37/C5-30733-76DBCAF4; Fri, 11 May 2012 07:19:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336720734!1882625!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23836 invoked from network); 11 May 2012 07:18:55 -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; 11 May 2012 07:18:55 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 08:18:54 +0100 Message-Id: <4FACD9940200007800082F0D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 08:19:16 +0100 From: "Jan Beulich" To: "xen-devel" , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part527CBC64.1__=" Cc: Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part527CBC64.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Legacy (non-pvops) gntdev drivers may require this to be done when the number of grants intended to be used simultaneously exceeds a certain driver specific default limit. Signed-off-by: Jan Beulich --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * if (xen_mode !=3D XEN_EMULATE) { batch_maps =3D 1; } + if (xc_gnttab_set_max_grants(xendev->gnttabdev, + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", + strerror(errno)); } =20 static int blk_init(struct XenDevice *xendev) --=__Part527CBC64.1__= Content-Type: text/plain; name="qemu-xendisk-set-max-grants.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemu-xendisk-set-max-grants.patch" qemu/xendisk: set maximum number of grants to be used=0A=0ALegacy = (non-pvops) gntdev drivers may require this to be done when the=0Anumber = of grants intended to be used simultaneously exceeds a certain=0Adriver = specific default limit.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c=0A@@ -536,6 +536,10 @@ = static void blk_alloc(struct XenDevice *=0A if (xen_mode !=3D = XEN_EMULATE) {=0A batch_maps =3D 1;=0A }=0A+ if (xc_gnttab_s= et_max_grants(xendev->gnttabdev,=0A+ max_requests * BLKIF_MAX_SE= GMENTS_PER_REQUEST + 1) < 0)=0A+ xen_be_printf(xendev, 0, "xc_gnttab= _set_max_grants failed: %s\n",=0A+ strerror(errno));= =0A }=0A =0A static int blk_init(struct XenDevice *xendev)=0A --=__Part527CBC64.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part527CBC64.1__=-- From xen-devel-bounces@lists.xen.org Fri May 11 07:19:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 07: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 ) id 1SSk82-00063W-6j; Fri, 11 May 2012 07:19:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSk80-00063R-3w for xen-devel@lists.xen.org; Fri, 11 May 2012 07:19:04 +0000 Received: from [193.109.254.147:29540] by server-5.bemta-14.messagelabs.com id 37/C5-30733-76DBCAF4; Fri, 11 May 2012 07:19:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336720734!1882625!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23836 invoked from network); 11 May 2012 07:18:55 -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; 11 May 2012 07:18:55 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 08:18:54 +0100 Message-Id: <4FACD9940200007800082F0D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 08:19:16 +0100 From: "Jan Beulich" To: "xen-devel" , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part527CBC64.1__=" Cc: Stefano Stabellini Subject: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part527CBC64.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Legacy (non-pvops) gntdev drivers may require this to be done when the number of grants intended to be used simultaneously exceeds a certain driver specific default limit. Signed-off-by: Jan Beulich --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * if (xen_mode !=3D XEN_EMULATE) { batch_maps =3D 1; } + if (xc_gnttab_set_max_grants(xendev->gnttabdev, + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", + strerror(errno)); } =20 static int blk_init(struct XenDevice *xendev) --=__Part527CBC64.1__= Content-Type: text/plain; name="qemu-xendisk-set-max-grants.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemu-xendisk-set-max-grants.patch" qemu/xendisk: set maximum number of grants to be used=0A=0ALegacy = (non-pvops) gntdev drivers may require this to be done when the=0Anumber = of grants intended to be used simultaneously exceeds a certain=0Adriver = specific default limit.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/hw/xen_disk.c=0A+++ b/hw/xen_disk.c=0A@@ -536,6 +536,10 @@ = static void blk_alloc(struct XenDevice *=0A if (xen_mode !=3D = XEN_EMULATE) {=0A batch_maps =3D 1;=0A }=0A+ if (xc_gnttab_s= et_max_grants(xendev->gnttabdev,=0A+ max_requests * BLKIF_MAX_SE= GMENTS_PER_REQUEST + 1) < 0)=0A+ xen_be_printf(xendev, 0, "xc_gnttab= _set_max_grants failed: %s\n",=0A+ strerror(errno));= =0A }=0A =0A static int blk_init(struct XenDevice *xendev)=0A --=__Part527CBC64.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part527CBC64.1__=-- From xen-devel-bounces@lists.xen.org Fri May 11 07:23:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 07:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkBp-0006A6-Ru; Fri, 11 May 2012 07:23:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkBo-0006A0-G9 for xen-devel@lists.xen.org; Fri, 11 May 2012 07:23:00 +0000 Received: from [193.109.254.147:16386] by server-12.bemta-14.messagelabs.com id 25/8E-05898-35EBCAF4; Fri, 11 May 2012 07:22:59 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336720978!8750233!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15904 invoked from network); 11 May 2012 07:22:59 -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; 11 May 2012 07:22:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 08:22:58 +0100 Message-Id: <4FACDA880200007800082F18@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 08:23:20 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part4D63A378.0__=" Subject: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part4D63A378.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Legacy (non-pvops) gntdev drivers may require this operation to be performed when the number of grants intended to be used simultaneously exceeds a certain driver specific default limit, and qemu's qdisk driver is an example of needing to do so. Signed-off-by: Jan Beulich --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -541,6 +541,27 @@ static int linux_gnttab_close(xc_gnttab=20 return close(fd); } =20 +static int linux_gnttab_set_max_grants(xc_gnttab *xch, xc_osdep_handle h, + uint32_t count) +{ + int fd =3D (int)h, rc; + struct ioctl_gntdev_set_max_grants max_grants =3D { .count =3D count = }; + + rc =3D ioctl(fd, IOCTL_GNTDEV_SET_MAX_GRANTS, &max_grants); + if (rc) { + /* + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, + * so ignore the resulting specific failure. + */ + if (errno =3D=3D ENOTTY) + rc =3D 0; + else + PERROR("linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS = failed"); + } + + return rc; +} + static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h, uint32_t count, int flags, int prot, uint32_t *domids, uint32_t *refs, @@ -680,6 +701,7 @@ static struct xc_osdep_ops linux_gnttab_ .close =3D &linux_gnttab_close, =20 .u.gnttab =3D { + .set_max_grants =3D linux_gnttab_set_max_grants, .grant_map =3D &linux_gnttab_grant_map, .munmap =3D &linux_gnttab_munmap, }, --=__Part4D63A378.0__= Content-Type: text/plain; name="libxc-linux-set-max-grants.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="libxc-linux-set-max-grants.patch" libxc: implement gnttab.set_max_grants for Linux=0A=0ALegacy (non-pvops) = gntdev drivers may require this operation to be=0Aperformed when the = number of grants intended to be used simultaneously=0Aexceeds a certain = driver specific default limit, and qemu's qdisk=0Adriver is an example of = needing to do so.=0A=0ASigned-off-by: Jan Beulich =0A=0A= --- a/tools/libxc/xc_linux_osdep.c=0A+++ b/tools/libxc/xc_linux_osdep.c=0A@= @ -541,6 +541,27 @@ static int linux_gnttab_close(xc_gnttab =0A return = close(fd);=0A }=0A =0A+static int linux_gnttab_set_max_grants(xc_gnttab = *xch, xc_osdep_handle h,=0A+ = uint32_t count)=0A+{=0A+ int fd =3D (int)h, rc;=0A+ struct ioctl_gntd= ev_set_max_grants max_grants =3D { .count =3D count };=0A+=0A+ rc =3D = ioctl(fd, IOCTL_GNTDEV_SET_MAX_GRANTS, &max_grants);=0A+ if (rc) {=0A+ = /*=0A+ * Newer (e.g. pv-ops) kernels don't implement this = IOCTL,=0A+ * so ignore the resulting specific failure.=0A+ = */=0A+ if (errno =3D=3D ENOTTY)=0A+ rc =3D 0;=0A+ = else=0A+ PERROR("linux_gnttab_set_max_grants: ioctl SET_MAX_GRAN= TS failed");=0A+ }=0A+=0A+ return rc;=0A+}=0A+=0A static void = *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,=0A = uint32_t count, int flags, int prot,=0A = uint32_t *domids, uint32_t *refs,=0A@@ -680,6 = +701,7 @@ static struct xc_osdep_ops linux_gnttab_=0A .close =3D = &linux_gnttab_close,=0A =0A .u.gnttab =3D {=0A+ .set_max_grants = =3D linux_gnttab_set_max_grants,=0A .grant_map =3D &linux_gnttab_gr= ant_map,=0A .munmap =3D &linux_gnttab_munmap,=0A },=0A --=__Part4D63A378.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part4D63A378.0__=-- From xen-devel-bounces@lists.xen.org Fri May 11 07:23:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 07:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkBp-0006A6-Ru; Fri, 11 May 2012 07:23:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkBo-0006A0-G9 for xen-devel@lists.xen.org; Fri, 11 May 2012 07:23:00 +0000 Received: from [193.109.254.147:16386] by server-12.bemta-14.messagelabs.com id 25/8E-05898-35EBCAF4; Fri, 11 May 2012 07:22:59 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336720978!8750233!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15904 invoked from network); 11 May 2012 07:22:59 -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; 11 May 2012 07:22:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 08:22:58 +0100 Message-Id: <4FACDA880200007800082F18@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 08:23:20 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part4D63A378.0__=" Subject: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part4D63A378.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Legacy (non-pvops) gntdev drivers may require this operation to be performed when the number of grants intended to be used simultaneously exceeds a certain driver specific default limit, and qemu's qdisk driver is an example of needing to do so. Signed-off-by: Jan Beulich --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -541,6 +541,27 @@ static int linux_gnttab_close(xc_gnttab=20 return close(fd); } =20 +static int linux_gnttab_set_max_grants(xc_gnttab *xch, xc_osdep_handle h, + uint32_t count) +{ + int fd =3D (int)h, rc; + struct ioctl_gntdev_set_max_grants max_grants =3D { .count =3D count = }; + + rc =3D ioctl(fd, IOCTL_GNTDEV_SET_MAX_GRANTS, &max_grants); + if (rc) { + /* + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, + * so ignore the resulting specific failure. + */ + if (errno =3D=3D ENOTTY) + rc =3D 0; + else + PERROR("linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS = failed"); + } + + return rc; +} + static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h, uint32_t count, int flags, int prot, uint32_t *domids, uint32_t *refs, @@ -680,6 +701,7 @@ static struct xc_osdep_ops linux_gnttab_ .close =3D &linux_gnttab_close, =20 .u.gnttab =3D { + .set_max_grants =3D linux_gnttab_set_max_grants, .grant_map =3D &linux_gnttab_grant_map, .munmap =3D &linux_gnttab_munmap, }, --=__Part4D63A378.0__= Content-Type: text/plain; name="libxc-linux-set-max-grants.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="libxc-linux-set-max-grants.patch" libxc: implement gnttab.set_max_grants for Linux=0A=0ALegacy (non-pvops) = gntdev drivers may require this operation to be=0Aperformed when the = number of grants intended to be used simultaneously=0Aexceeds a certain = driver specific default limit, and qemu's qdisk=0Adriver is an example of = needing to do so.=0A=0ASigned-off-by: Jan Beulich =0A=0A= --- a/tools/libxc/xc_linux_osdep.c=0A+++ b/tools/libxc/xc_linux_osdep.c=0A@= @ -541,6 +541,27 @@ static int linux_gnttab_close(xc_gnttab =0A return = close(fd);=0A }=0A =0A+static int linux_gnttab_set_max_grants(xc_gnttab = *xch, xc_osdep_handle h,=0A+ = uint32_t count)=0A+{=0A+ int fd =3D (int)h, rc;=0A+ struct ioctl_gntd= ev_set_max_grants max_grants =3D { .count =3D count };=0A+=0A+ rc =3D = ioctl(fd, IOCTL_GNTDEV_SET_MAX_GRANTS, &max_grants);=0A+ if (rc) {=0A+ = /*=0A+ * Newer (e.g. pv-ops) kernels don't implement this = IOCTL,=0A+ * so ignore the resulting specific failure.=0A+ = */=0A+ if (errno =3D=3D ENOTTY)=0A+ rc =3D 0;=0A+ = else=0A+ PERROR("linux_gnttab_set_max_grants: ioctl SET_MAX_GRAN= TS failed");=0A+ }=0A+=0A+ return rc;=0A+}=0A+=0A static void = *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,=0A = uint32_t count, int flags, int prot,=0A = uint32_t *domids, uint32_t *refs,=0A@@ -680,6 = +701,7 @@ static struct xc_osdep_ops linux_gnttab_=0A .close =3D = &linux_gnttab_close,=0A =0A .u.gnttab =3D {=0A+ .set_max_grants = =3D linux_gnttab_set_max_grants,=0A .grant_map =3D &linux_gnttab_gr= ant_map,=0A .munmap =3D &linux_gnttab_munmap,=0A },=0A --=__Part4D63A378.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part4D63A378.0__=-- From xen-devel-bounces@lists.xen.org Fri May 11 08:03:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:03:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoW-0006v9-I1; Fri, 11 May 2012 08:03:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoV-0006v4-NC for xen-devel@lists.xen.org; Fri, 11 May 2012 08:02:59 +0000 Received: from [85.158.143.99:62448] by server-2.bemta-4.messagelabs.com id 99/7B-17550-2B7CCAF4; Fri, 11 May 2012 08:02:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336723378!20463435!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21047 invoked from network); 11 May 2012 08:02:58 -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; 11 May 2012 08:02:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12421822" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:02: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, 11 May 2012 09:02:58 +0100 Message-ID: <1336723376.23818.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 11 May 2012 09:02:56 +0100 In-Reply-To: <4FACDA880200007800082F18@nat28.tlf.novell.com> References: <4FACDA880200007800082F18@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 08:23 +0100, Jan Beulich wrote: > + /* > + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, > + * so ignore the resulting specific failure. > + */ pvops doesn't implement this ioctl because it is already more dynamic and therefore setting a max unnecessary? (I'm pretty sure yes, but just wanted to confirm we shouldn't be fixing anything on the pvops side). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:03:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:03:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoW-0006v9-I1; Fri, 11 May 2012 08:03:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoV-0006v4-NC for xen-devel@lists.xen.org; Fri, 11 May 2012 08:02:59 +0000 Received: from [85.158.143.99:62448] by server-2.bemta-4.messagelabs.com id 99/7B-17550-2B7CCAF4; Fri, 11 May 2012 08:02:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336723378!20463435!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21047 invoked from network); 11 May 2012 08:02:58 -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; 11 May 2012 08:02:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12421822" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:02: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, 11 May 2012 09:02:58 +0100 Message-ID: <1336723376.23818.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 11 May 2012 09:02:56 +0100 In-Reply-To: <4FACDA880200007800082F18@nat28.tlf.novell.com> References: <4FACDA880200007800082F18@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 08:23 +0100, Jan Beulich wrote: > + /* > + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, > + * so ignore the resulting specific failure. > + */ pvops doesn't implement this ioctl because it is already more dynamic and therefore setting a max unnecessary? (I'm pretty sure yes, but just wanted to confirm we shouldn't be fixing anything on the pvops side). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:03:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:03:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoj-0006ws-Uc; Fri, 11 May 2012 08:03:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoi-0006wk-No for Xen-devel@lists.xensource.com; Fri, 11 May 2012 08:03:12 +0000 Received: from [85.158.138.51:65190] by server-1.bemta-3.messagelabs.com id 13/7D-11491-FB7CCAF4; Fri, 11 May 2012 08:03:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336723391!26411833!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11856 invoked from network); 11 May 2012 08:03: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; 11 May 2012 08:03:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12421827" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:03: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, 11 May 2012 09:03:10 +0100 Message-ID: <1336723389.23818.5.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Fri, 11 May 2012 09:03:09 +0100 In-Reply-To: <20120511014036.GA12150@phenom.dumpdata.com> References: <20120510180213.6083e857@mantra.us.oracle.com> <20120511014036.GA12150@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Stefano Stabellini Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 02:40 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > > Hi Guys, > > > > > > Cheers.... JFYI... I've all combinations working now, for both UP and > > MP. > > YEEEY! What he said! > > > > Normal PV dom0: PV domU, Hyb domU, HVM domU > > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > > > So, next now: > > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > > - make sure everything works with latest, and without tons of debug > > code i've there right now ;). > > - test it out a bit. > > - submit patch. > > - once patch is accepted, do more benchmarks and improvements over > > time. > > > > thanks, > > Mukesh > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:03:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:03:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoj-0006ws-Uc; Fri, 11 May 2012 08:03:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkoi-0006wk-No for Xen-devel@lists.xensource.com; Fri, 11 May 2012 08:03:12 +0000 Received: from [85.158.138.51:65190] by server-1.bemta-3.messagelabs.com id 13/7D-11491-FB7CCAF4; Fri, 11 May 2012 08:03:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336723391!26411833!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11856 invoked from network); 11 May 2012 08:03: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; 11 May 2012 08:03:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12421827" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:03: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, 11 May 2012 09:03:10 +0100 Message-ID: <1336723389.23818.5.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Fri, 11 May 2012 09:03:09 +0100 In-Reply-To: <20120511014036.GA12150@phenom.dumpdata.com> References: <20120510180213.6083e857@mantra.us.oracle.com> <20120511014036.GA12150@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Keir Fraser , Stefano Stabellini Subject: Re: [Xen-devel] [HYBRID] : status update... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 02:40 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, May 10, 2012 at 06:02:13PM -0700, Mukesh Rathor wrote: > > Hi Guys, > > > > > > Cheers.... JFYI... I've all combinations working now, for both UP and > > MP. > > YEEEY! What he said! > > > > Normal PV dom0: PV domU, Hyb domU, HVM domU > > Hybrid dom0: PV domU, Hyb domU, HVM domU. > > > > So, next now: > > - refresh my linux and xen trees to latest. i'm on xen 4.1.3. > > - make sure everything works with latest, and without tons of debug > > code i've there right now ;). > > - test it out a bit. > > - submit patch. > > - once patch is accepted, do more benchmarks and improvements over > > time. > > > > thanks, > > Mukesh > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:09:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:09:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkuP-0007CI-Rw; Fri, 11 May 2012 08:09:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkuO-0007CC-C4 for xen-devel@lists.xen.org; Fri, 11 May 2012 08:09:04 +0000 Received: from [85.158.143.35:49489] by server-2.bemta-4.messagelabs.com id 03/75-17550-F19CCAF4; Fri, 11 May 2012 08:09:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336723742!10489071!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19800 invoked from network); 11 May 2012 08:09:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 08:09:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 09:09:01 +0100 Message-Id: <4FACE5520200007800082F61@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 09:09:22 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <4FACDA880200007800082F18@nat28.tlf.novell.com> <1336723376.23818.4.camel@zakaz.uk.xensource.com> In-Reply-To: <1336723376.23818.4.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 10:02, Ian Campbell wrote: > On Fri, 2012-05-11 at 08:23 +0100, Jan Beulich wrote: >> + /* >> + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, >> + * so ignore the resulting specific failure. >> + */ > > pvops doesn't implement this ioctl because it is already more dynamic > and therefore setting a max unnecessary? > > (I'm pretty sure yes, but just wanted to confirm we shouldn't be fixing > anything on the pvops side). Correct. The only adjustment I would consider worth doing is to accept the unnecessary ioctl without producing an error or logging any message (perhaps one could in fact return an error for insanely high input values). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:09:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08:09:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkuP-0007CI-Rw; Fri, 11 May 2012 08:09:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSkuO-0007CC-C4 for xen-devel@lists.xen.org; Fri, 11 May 2012 08:09:04 +0000 Received: from [85.158.143.35:49489] by server-2.bemta-4.messagelabs.com id 03/75-17550-F19CCAF4; Fri, 11 May 2012 08:09:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336723742!10489071!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19800 invoked from network); 11 May 2012 08:09:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 08:09:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 09:09:01 +0100 Message-Id: <4FACE5520200007800082F61@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 09:09:22 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <4FACDA880200007800082F18@nat28.tlf.novell.com> <1336723376.23818.4.camel@zakaz.uk.xensource.com> In-Reply-To: <1336723376.23818.4.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] libxc: implement gnttab.set_max_grants for Linux X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 10:02, Ian Campbell wrote: > On Fri, 2012-05-11 at 08:23 +0100, Jan Beulich wrote: >> + /* >> + * Newer (e.g. pv-ops) kernels don't implement this IOCTL, >> + * so ignore the resulting specific failure. >> + */ > > pvops doesn't implement this ioctl because it is already more dynamic > and therefore setting a max unnecessary? > > (I'm pretty sure yes, but just wanted to confirm we shouldn't be fixing > anything on the pvops side). Correct. The only adjustment I would consider worth doing is to accept the unnecessary ioctl without producing an error or logging any message (perhaps one could in fact return an error for insanely high input values). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:23:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08: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 ) id 1SSl7g-0007uL-KG; Fri, 11 May 2012 08:22:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSl7f-0007uE-DV for xen-devel@lists.xen.org; Fri, 11 May 2012 08:22:47 +0000 Received: from [85.158.143.99:35388] by server-1.bemta-4.messagelabs.com id 22/84-20925-65CCCAF4; Fri, 11 May 2012 08:22:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336724564!17866806!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3105 invoked from network); 11 May 2012 08:22:45 -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; 11 May 2012 08:22:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 09:22:43 +0100 Message-Id: <4FACE8870200007800082F81@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 09:23:03 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" , "Jeff Law" References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> In-Reply-To: <4FAC1989.4060201@redhat.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, haitao.shan@intel.com, stefan.bader@canonical.com, xen-devel , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 21:39, Jeff Law wrote: > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: >>> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_AVX) >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_OSXSAVE) > != 0 >> 151&& ({ unsigned int xcrlow; >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID flags, > I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV > guest >> still crashes on that machine) - which means that in multi-lib the > bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but > not the YMM registers and thus the right check is for AVX. Which is wrong: (Almost?) all VEX encoded operations act on the full YMM registers, even if they operate only on 128 bits - the upper 128 bits get zeroed in that case. Plus all exception type descriptions in the SDM are clearly indicating that VEX encoded AVX instructions require CR4.OSXSAVE (mirrored in CPUID.OSXSAVE) to be set along with the corresponding specific CPUID feature flag(s). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 08:23:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 08: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 ) id 1SSl7g-0007uL-KG; Fri, 11 May 2012 08:22:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSl7f-0007uE-DV for xen-devel@lists.xen.org; Fri, 11 May 2012 08:22:47 +0000 Received: from [85.158.143.99:35388] by server-1.bemta-4.messagelabs.com id 22/84-20925-65CCCAF4; Fri, 11 May 2012 08:22:46 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336724564!17866806!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3105 invoked from network); 11 May 2012 08:22:45 -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; 11 May 2012 08:22:45 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 09:22:43 +0100 Message-Id: <4FACE8870200007800082F81@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 09:23:03 +0100 From: "Jan Beulich" To: "Konrad Rzeszutek Wilk" , "Jeff Law" References: <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> <20120509003510.GA19643@phenom.dumpdata.com> <20120509131153.GA13956@andromeda.dapyr.net> <4FAA8E96020000780008288F@nat28.tlf.novell.com> <20120509173836.GB9094@phenom.dumpdata.com> <4FAC1989.4060201@redhat.com> In-Reply-To: <4FAC1989.4060201@redhat.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, haitao.shan@intel.com, stefan.bader@canonical.com, xen-devel , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 10.05.12 at 21:39, Jeff Law wrote: > On 05/09/2012 11:38 AM, Konrad Rzeszutek Wilk wrote: >>> >>> And finally one always has to keep in mind that there is this nice >>> glibc bug in that in some versions it is failing to look at CPUID.OSXSAVE >>> when trying to determine whether AVX or FMA is available. >> >> It has this: >> 146 >> 147 if (__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_AVX) >> 148 { >> 149 /* Reset the AVX bit in case OSXSAVE is disabled. */ >> 150 if ((__cpu_features.cpuid[COMMON_CPUID_INDEX_1].ecx& bit_OSXSAVE) > != 0 >> 151&& ({ unsigned int xcrlow; >> 152 unsigned int xcrhigh; >> 153 asm ("xgetbv" >> 154 : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0)); >> 155 (xcrlow& 6) == 6; })) >> 156 __cpu_features.feature[index_YMM_Usable] |= bit_YMM_Usable; >> 157 } >> >> >> And when I ran a little silly C program (attached) to probe the CPUID flags, > I got: >> /root/test-xsave >> SSE3 CMOV >> AVX XSAVE >> Trying XGETBV >> Illegal instruction (core dumped) >> >> Which would imply that the OSXSAVE is not set (but Fedora Core 17 64-bit PV > guest >> still crashes on that machine) - which means that in multi-lib the > bit_YMM_Usable >> is _not_ set. But then looking at the sources I see: >> >> # ifdef USE_AS_STRCASECMP_L >> 102 ENTRY(__strcasecmp) >> 103 .type __strcasecmp, @gnu_indirect_function >> 104 cmpl $0, __cpu_features+KIND_OFFSET(%rip) >> 105 jne 1f >> 106 call __init_cpu_features >> 107 1: >> 108 # ifdef HAVE_AVX_SUPPORT >> 109 leaq __strcasecmp_avx(%rip), %rax >> 110 testl $bit_AVX, __cpu_features+CPUID_OFFSET+index_AVX(%rip) >> 111 jnz 2f >> 112 # endif >> >> which would imply that the AVX bit is sampled here instead of the >> YMM one. > [ ... ] > I think Uli's position is that this code only uses AVX encodings, but > not the YMM registers and thus the right check is for AVX. Which is wrong: (Almost?) all VEX encoded operations act on the full YMM registers, even if they operate only on 128 bits - the upper 128 bits get zeroed in that case. Plus all exception type descriptions in the SDM are clearly indicating that VEX encoded AVX instructions require CR4.OSXSAVE (mirrored in CPUID.OSXSAVE) to be set along with the corresponding specific CPUID feature flag(s). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 09:04:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 09:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSlli-0000ad-DR; Fri, 11 May 2012 09:04:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSllh-0000aX-BU for xen-devel@lists.xensource.com; Fri, 11 May 2012 09:04:09 +0000 Received: from [193.109.254.147:5211] by server-11.bemta-14.messagelabs.com id 0A/72-05858-806DCAF4; Fri, 11 May 2012 09:04:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336727047!8722432!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3185 invoked from network); 11 May 2012 09:04:08 -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; 11 May 2012 09:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12423637" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09: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; Fri, 11 May 2012 10:04:07 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSllf-0005Cv-Am; Fri, 11 May 2012 09:04:07 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSllf-0005Ls-8q; Fri, 11 May 2012 10:04:07 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 11 May 2012 10:04:07 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12852: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12852 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12852/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 54c8c9eaee92 baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 09:04:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 09:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSlli-0000ad-DR; Fri, 11 May 2012 09:04:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSllh-0000aX-BU for xen-devel@lists.xensource.com; Fri, 11 May 2012 09:04:09 +0000 Received: from [193.109.254.147:5211] by server-11.bemta-14.messagelabs.com id 0A/72-05858-806DCAF4; Fri, 11 May 2012 09:04:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336727047!8722432!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODI5Mw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3185 invoked from network); 11 May 2012 09:04:08 -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; 11 May 2012 09:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12423637" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09: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; Fri, 11 May 2012 10:04:07 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSllf-0005Cv-Am; Fri, 11 May 2012 09:04:07 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSllf-0005Ls-8q; Fri, 11 May 2012 10:04:07 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 11 May 2012 10:04:07 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12852: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12852 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12852/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 54c8c9eaee92 baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 09:38:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 09:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmId-0001tt-Da; Fri, 11 May 2012 09:38:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmIb-0001tj-Ar for xen-devel@lists.xensource.com; Fri, 11 May 2012 09:38:10 +0000 Received: from [85.158.139.83:55555] by server-9.bemta-5.messagelabs.com id 88/06-09826-00EDCAF4; Fri, 11 May 2012 09:38:08 +0000 X-Env-Sender: carsten@schiers.de X-Msg-Ref: server-14.tower-182.messagelabs.com!1336729082!23566658!1 X-Originating-IP: [194.117.254.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, FROM_EXCESS_QP,HTML_MESSAGE X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20047 invoked from network); 11 May 2012 09:38:03 -0000 Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 09:38:03 -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=5Pko0iUfb3F2TVDcLJq8K6AchjHgz vNIYOBOuyJVHSE=; b=rzSg+gfZM9p9WI0ZsnRwR4se6VCB4JwXzP7B1s9ihU1Ul h4VD9qIUhzQEL56ioe88N9d7OoCK+0w9ErUruet824QGigXsIO4d75X0C1L9HZd3 EKl5QyHPwnUU/cDKo7jwF+HQHMOgYvlLfhjAFZjtOtR3mRw68w4LVDGXhNMnDk= Received: (qmail 30756 invoked from network); 11 May 2012 11:37:53 +0200 Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.27.13) by mail.zeus06.de with ESMTPA; 11 May 2012 11:37:53 +0200 Received: from localhost (localhost [127.0.0.1]) by uhura.zz (Postfix) with ESMTP id 97A8F2C575; Fri, 11 May 2012 11:39:20 +0200 (CEST) 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 o908giwQewg3; Fri, 11 May 2012 11:39:09 +0200 (CEST) Received: from uhura.space.zz (localhost [127.0.0.1]) by uhura.zz (Postfix) with ESMTP id 0AE9E2C574; Fri, 11 May 2012 11:39:09 +0200 (CEST) From: =?utf-8?Q?Carsten_Schiers?= To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= Date: Fri, 11 May 2012 11:39:08 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.0.6-32752 Message-Id: Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= , =?utf-8?Q?xen-devel?= , =?utf-8?Q?Jan_Beulich?= , =?utf-8?Q?Sander_Eikelenboom?= Subject: Re: [Xen-devel] Load increase after memory upgrade (part2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809693732979586600==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --===============1809693732979586600== Content-Type: multipart/alternative; boundary="=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d" This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Konrad,=0D=0A=0D=0A=C2=A0=0D=0Adon't want to be pushy, as I have no re= al issue. I simply use the Xenified kernel or take the double load.=20=0D= =0A=0D=0ABut I think this mistery is still open. My last status was that = the latest patch you produced resulted in a BUG,=20=0D=0A=0D=0Aso we stil= l have not checked whether our theory is correct.=0D=0A=0D=0A=C2=A0=0D=0A= BR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachrich= t-----=0D=0AVon:Carsten Schiers =0D=0AGesendet:Mi 29.= 02.2012 14:01=0D=0ABetreff:Re: [Xen-devel] Load increase after memory upg= rade (part2)=0D=0AAnlage:debug.log, inline.txt=0D=0AAn:Konrad Rzeszutek W= ilk ;=20=0D=0ACC:Sander Eikelenboom ; xen-devel ; Jan Beulich ; Konrad Rzeszutek Wilk ;=20=0D=0A=20=0D=0A= =0D=0AI am very sorry. I accidently started the DomU with the wrong confi= g file, thus it's clear why there is no difference=0D=0A=0D=0Abetween the= two. And unfortunately, the DomU with the correct config file is having = a BUG:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=0A [ 14.674883] BUG: unable to han= dle kernel paging request at ffffc7fffffff000 [ 14.674910] IP: [] swiotlb_bounce+0x2e/0x31 [ 14.674930] PGD 0 [ 14.674940= ] Oops: 0002 [#1] SMP [ 14.674952] CPU 0 [ 14.674957] Modules linke= d in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc tda10023= budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobuf_dma_sg = videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd ttpci_ee= prom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache xen_netfro= nt xen_blkfront [ 14.675057] [ 14.675065] Pid: 0, comm: swapper/0 No= t tainted 3.2.8-amd64 #1 [ 14.675079] RIP: e030:[] = [] swiotlb_bounce+0x2e/0x31 [ 14.675097] RSP: e02b:f= fff880013fabe58 EFLAGS: 00010202 [ 14.675106] RAX: ffff880012800000 RB= X: 0000000000000001 RCX: 0000000000001000 [ 14.675116] RDX: 00000000000= 01000 RSI: ffff880012800000 RDI: ffffc7fffffff000 [ 14.675126] RBP: 000= 0000000000002 R08: ffffc7fffffff000 R09: ffff880013f98000 [ 14.675137] = R10: 0000000000000001 R11: ffff880003376000 R12: ffff8800032c5090 [ 14.= 675147] R13: 0000000000000149 R14: ffff8800033e0000 R15: ffffffff81601fd8= [ 14.675163] FS: 00007f3ff9893700(0000) GS:ffff880013fa8000(0000) knl= GS:0000000000000000 [ 14.675175] CS: e033 DS: 0000 ES: 0000 CR0: 00000= 0008005003b [ 14.675184] CR2: ffffc7fffffff000 CR3: 0000000012683000 CR= 4: 0000000000000660 [ 14.675195] DR0: 0000000000000000 DR1: 00000000000= 00000 DR2: 0000000000000000 [ 14.675205] DR3: 0000000000000000 DR6: 000= 00000ffff0ff0 DR7: 0000000000000400 [ 14.675216] Process swapper/0 (pid= : 0, threadinfo ffffffff81600000, task ffffffff8160d020) [ 14.675227] S= tack: [ 14.675232] ffffffff81211826 ffff880002eda000 0000000000000000 = ffffc90000408000 [ 14.675251] 00000000000b0150 0000000000000006 ffffff= ffa013ec4a ffffffff810946cd [ 14.675270] ffffffff81099203 ffff88000337= 6000 0000000000000000 ffff880002eda4b0 [ 14.675289] Call Trace: [ 14.= 675295] [ 14.675307] [] =3F xen_swiotlb_sync= _sg_for_cpu+0x2e/0x47 [ 14.675322] [] =3F vpeirq+0x7= f/0x198 [budget_core] [ 14.675337] [] =3F handle_irq= _event_percpu+0x166/0x184 [ 14.675350] [] =3F __rcu_= process_callbacks+0x71/0x2f8 [ 14.675364] [] =3F tas= klet_action+0x76/0xc5 [ 14.675376] [] =3F eoi_pirq+0= x5b/0x77 [ 14.675388] [] =3F __do_softirq+0xc4/0x1a0= [ 14.675400] [] =3F __xen_evtchn_do_upcall+0x1c7/0x= 205 [ 14.675412] [] =3F call_softirq+0x1c/0x30 [ 1= 4.675425] [] =3F do_softirq+0x3f/0x79 [ 14.675436] = [] =3F irq_exit+0x44/0xb5 [ 14.675452] [] =3F xen_evtchn_do_upcall+0x27/0x32 [ 14.675464] [] =3F xen_do_hypervisor_callback+0x1e/0x30 [ 14.675473] =20=0D= =0A=0D=0A=C2=A0=0D=0AComplete log is attached.=0D=0A=0D=0A=C2=A0=0D=0ABR,= Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn= :Konrad Rzeszutek Wilk ;=20=0D=0ACC:Konrad Rzeszu= tek Wilk ; xen-devel ; = Jan Beulich ; Sander Eikelenboom ;=20=0D=0AVon:Carsten Schiers =0D=0AGesendet:Mi 29.0= 2.2012 13:16=0D=0ABetreff:Re: [Xen-devel] Load increase after memory upgr= ade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0AGreat news: it wor= ks and load is back to normal. In the attached graph you can see the peak= =0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 Kernel) and then af= ter 16.00 the going life of the=0D=0A=0D=0Avideo DomU. We are below an av= aerage of 7% usage (figures are in Permille).=0D=0A=0D=0A=0D=0AThanks so = much. Is that already "the final patch"=3F=0D=0A=0D=0A=C2=A0=0D=0ABR, Car= sten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Na= chricht-----=0D=0AAn:Konrad Rzeszutek Wilk ;=20=0D= =0ACC:Sander Eikelenboom ; xen-devel ; Jan Beulich ; Konrad Rzeszutek Wilk= ;=20=0D=0AVon:Carsten Schiers =0D= =0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [Xen-devel] Load increas= e after memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0A= Well let me check for a longer period of time, and especially, whether th= e DomU is still=0D=0A=0D=0Aworking (can do that only from at home), but l= oad looks pretty well after applying the=0D=0A=0D=0Apatch to 3.2.8 :-D.=0D= =0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3= =BCngliche Nachricht-----=0D=0AAn:Jan Beulich ;=20=0D=0A= CC:Konrad Rzeszutek Wilk ; xen-devel ; Carsten Schiers ; Sander Eikelenboom = ;=20=0D=0AVon:Konrad Rzeszutek Wilk =0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff:Re: [Xen-devel] = Load increase after memory upgrade (part2)=0D=0AOn Thu, Feb 16, 2012 at 0= 8:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.12 at 20:28, Konr= ad Rzeszutek Wilk wrote:=0D=0A> >@@ -1550,7 +155= 2,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gf= p_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned int nr_pages, arr= ay_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) |= __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_mask & (__GFP_DMA = | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >+if (dma_mask =3D= =3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't spot where you f= orce this normally invalid combination, without=0D=0A> which the change w= on't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=0A> >+gfp_mask &= =3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask &=3D ~(__GFP_DMA= | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=0AGood eyes. Tha= nks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A> > nr_pages =3D (= area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_size =3D (nr_pages = * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=0A______________= _________________________________=0D=0AXen-devel mailing list=0D=0AXen-de= vel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-devel=0D=0A=20= =0D=0A=20=0D=0A=0D=0A=C2=A0=0D=0A --------------------------------=0D=0AE= -Mail ist virenfrei.=0D=0A Von AVG =C3=BCberpr=C3=BCft - www.avg.de=0D=0A= Version: 2012.0.2127 / Virendatenbank: 2411/4932 - Ausgabedatum: 12.04.2= 012=0D=0A=20 --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+ CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj Y2VzcyB2Ny4wLjYtMzI3NTIiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0 bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh ZD4KPGJvZHk+CjxwPkhpIEtvbnJhZCw8L3A+PHA+Jm5ic3A7PC9wPjxwPmRvbiYjMzk7dCB3 YW50IHRvIGJlIHB1c2h5LCBhcyBJIGhhdmUgbm8gcmVhbCBpc3N1ZS4gSSBzaW1wbHkgdXNl IHRoZSBYZW5pZmllZCBrZXJuZWwgb3IgdGFrZSB0aGUgZG91YmxlIGxvYWQuIDwvcD48cD5C dXQgSSB0aGluayB0aGlzIG1pc3RlcnkgaXMgc3RpbGwgb3Blbi4gTXkgbGFzdCBzdGF0dXMg d2FzIHRoYXQgdGhlIGxhdGVzdCBwYXRjaCB5b3UgcHJvZHVjZWQgcmVzdWx0ZWQgaW4gYSBC VUcsIDwvcD48cD5zbyB3ZSBzdGlsbCBoYXZlIG5vdCBjaGVja2VkIHdoZXRoZXIgb3VyIHRo ZW9yeSBpcyBjb3JyZWN0LjwvcD48cD4mbmJzcDs8L3A+PHA+QlIsPC9wPjxwPkNhcnN0ZW4u PGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNv bGlkICMzMjVGQkE7IHBhZGRpbmctbGVmdDogNXB4O21hcmdpbi1sZWZ0OjVweDsiPi0tLS0t VXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPGJyIC8+PHN0cm9uZz5Wb246PC9z dHJvbmc+CUNhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0OzxiciAv PjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CU1pIDI5LjAyLjIwMTIgMTQ6MDE8YnIgLz48 c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz48c3Ryb25nPkFubGFnZTo8L3N0 cm9uZz4JZGVidWcubG9nLCBpbmxpbmUudHh0PGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4J S29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0Ozsg PGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4JU2FuZGVyIEVpa2VsZW5ib29tICZsdDtsaW51 eEBlaWtlbGVuYm9vbS5pdCZndDs7IHhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhl bnNvdXJjZS5jb20mZ3Q7OyBKYW4gQmV1bGljaCAmbHQ7amJldWxpY2hAc3VzZS5jb20mZ3Q7 OyBLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgPGJy IC8+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHsgZm9udC1mYW1pbHk6IG1vbm9zcGFj ZTsgfTwvc3R5bGU+ICAgICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gICAg ICAgLmJvZHljbGFzcyAgICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFsLCBWZXJk YW5hLCBTYW5zLVNlcmlmICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTogMTJweDsg ICAgICAgICBwYWRkaW5nOiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2luOiAwcHg7 ICAgICAgICAgYm9yZGVyLXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQtY29sb3I6 ICNmZmZmZmY7ICAgICAgIH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAgICAgbWFy Z2luLXRvcDogMHB4OyAgICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAgfSAgIDwv c3R5bGU+ICA8ZGl2PjxwPkkgYW0gdmVyeSBzb3JyeS4gSSBhY2NpZGVudGx5IHN0YXJ0ZWQg dGhlIERvbVUgd2l0aCB0aGUgd3JvbmcgY29uZmlnIGZpbGUsIHRodXMgaXQmIzM5O3MgY2xl YXIgd2h5IHRoZXJlIGlzIG5vIGRpZmZlcmVuY2U8L3A+PHA+YmV0d2VlbiB0aGUgdHdvLiBB bmQgdW5mb3J0dW5hdGVseSwgdGhlIERvbVUgd2l0aCB0aGUgY29ycmVjdCBjb25maWcgZmls ZSBpcyBoYXZpbmcgYSBCVUc6PC9wPjxwPiZuYnNwOzwvcD48cHJlPgogWyAgIDE0LjY3NDg4 M10gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCBmZmZm YzdmZmZmZmZmMDAwIFsgICAxNC42NzQ5MTBdIElQOiBbJmx0O2ZmZmZmZmZmODExYjRjMGIm Z3Q7XSBzd2lvdGxiX2JvdW5jZSsweDJlLzB4MzEgWyAgIDE0LjY3NDkzMF0gUEdEIDAgIFsg ICAxNC42NzQ5NDBdIE9vcHM6IDAwMDIgWyMxXSBTTVAgIFsgICAxNC42NzQ5NTJdIENQVSAw ICBbICAgMTQuNjc0OTU3XSBNb2R1bGVzIGxpbmtlZCBpbjogbmZzZCBleHBvcnRmcyBuZnMg bG9ja2QgZnNjYWNoZSBhdXRoX3JwY2dzcyBuZnNfYWNsIHN1bnJwYyB0ZGExMDAyMyBidWRn ZXRfYXYgZXZkZXYgc2FhNzE0Nl92diB2aWRlb2RldiB2NGwyX2NvbXBhdF9pb2N0bDMyIHZp ZGVvYnVmX2RtYV9zZyB2aWRlb2J1Zl9jb3JlIGJ1ZGdldF9jb3JlIHNuZF9wY20gZHZiX2Nv cmUgc25kX3RpbWVyIHNhYTcxNDYgc25kIHR0cGNpX2VlcHJvbSBzb3VuZGNvcmUgc25kX3Bh Z2VfYWxsb2MgaTJjX2NvcmUgcGNzcGtyIGV4dDMgamJkIG1iY2FjaGUgeGVuX25ldGZyb250 IHhlbl9ibGtmcm9udCBbICAgMTQuNjc1MDU3XSAgWyAgIDE0LjY3NTA2NV0gUGlkOiAwLCBj b21tOiBzd2FwcGVyLzAgTm90IHRhaW50ZWQgMy4yLjgtYW1kNjQgIzEgICBbICAgMTQuNjc1 MDc5XSBSSVA6IGUwMzA6WyZsdDtmZmZmZmZmZjgxMWI0YzBiJmd0O10gIFsmbHQ7ZmZmZmZm ZmY4MTFiNGMwYiZndDtdIHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMSBbICAgMTQuNjc1MDk3 XSBSU1A6IGUwMmI6ZmZmZjg4MDAxM2ZhYmU1OCAgRUZMQUdTOiAwMDAxMDIwMiBbICAgMTQu Njc1MTA2XSBSQVg6IGZmZmY4ODAwMTI4MDAwMDAgUkJYOiAwMDAwMDAwMDAwMDAwMDAxIFJD WDogMDAwMDAwMDAwMDAwMTAwMCBbICAgMTQuNjc1MTE2XSBSRFg6IDAwMDAwMDAwMDAwMDEw MDAgUlNJOiBmZmZmODgwMDEyODAwMDAwIFJESTogZmZmZmM3ZmZmZmZmZjAwMCBbICAgMTQu Njc1MTI2XSBSQlA6IDAwMDAwMDAwMDAwMDAwMDIgUjA4OiBmZmZmYzdmZmZmZmZmMDAwIFIw OTogZmZmZjg4MDAxM2Y5ODAwMCBbICAgMTQuNjc1MTM3XSBSMTA6IDAwMDAwMDAwMDAwMDAw MDEgUjExOiBmZmZmODgwMDAzMzc2MDAwIFIxMjogZmZmZjg4MDAwMzJjNTA5MCBbICAgMTQu Njc1MTQ3XSBSMTM6IDAwMDAwMDAwMDAwMDAxNDkgUjE0OiBmZmZmODgwMDAzM2UwMDAwIFIx NTogZmZmZmZmZmY4MTYwMWZkOCBbICAgMTQuNjc1MTYzXSBGUzogIDAwMDA3ZjNmZjk4OTM3 MDAoMDAwMCkgR1M6ZmZmZjg4MDAxM2ZhODAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAw MDAwIFsgICAxNC42NzUxNzVdIENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAw MDAwMDAwODAwNTAwM2IgWyAgIDE0LjY3NTE4NF0gQ1IyOiBmZmZmYzdmZmZmZmZmMDAwIENS MzogMDAwMDAwMDAxMjY4MzAwMCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjAgWyAgIDE0LjY3NTE5 NV0gRFIwOiAwMDAwMDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAw MDAwMDAwMDAwMDAwMDAgWyAgIDE0LjY3NTIwNV0gRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERS NjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAgWyAgIDE0LjY3NTIx Nl0gUHJvY2VzcyBzd2FwcGVyLzAgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxNjAw MDAwLCB0YXNrIGZmZmZmZmZmODE2MGQwMjApIFsgICAxNC42NzUyMjddIFN0YWNrOiBbICAg MTQuNjc1MjMyXSAgZmZmZmZmZmY4MTIxMTgyNiBmZmZmODgwMDAyZWRhMDAwIDAwMDAwMDAw MDAwMDAwMDAgZmZmZmM5MDAwMDQwODAwMCBbICAgMTQuNjc1MjUxXSAgMDAwMDAwMDAwMDBi MDE1MCAwMDAwMDAwMDAwMDAwMDA2IGZmZmZmZmZmYTAxM2VjNGEgZmZmZmZmZmY4MTA5NDZj ZCBbICAgMTQuNjc1MjcwXSAgZmZmZmZmZmY4MTA5OTIwMyBmZmZmODgwMDAzMzc2MDAwIDAw MDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAwMmVkYTRiMCBbICAgMTQuNjc1Mjg5XSBDYWxsIFRy YWNlOiBbICAgMTQuNjc1Mjk1XSAgJmx0O0lSUSZndDsgIFsgICAxNC42NzUzMDddICBbJmx0 O2ZmZmZmZmZmODEyMTE4MjYmZ3Q7XSA/IHhlbl9zd2lvdGxiX3N5bmNfc2dfZm9yX2NwdSsw eDJlLzB4NDcgWyAgIDE0LjY3NTMyMl0gIFsmbHQ7ZmZmZmZmZmZhMDEzZWM0YSZndDtdID8g dnBlaXJxKzB4N2YvMHgxOTggW2J1ZGdldF9jb3JlXSBbICAgMTQuNjc1MzM3XSAgWyZsdDtm ZmZmZmZmZjgxMDk0NmNkJmd0O10gPyBoYW5kbGVfaXJxX2V2ZW50X3BlcmNwdSsweDE2Ni8w eDE4NCBbICAgMTQuNjc1MzUwXSAgWyZsdDtmZmZmZmZmZjgxMDk5MjAzJmd0O10gPyBfX3Jj dV9wcm9jZXNzX2NhbGxiYWNrcysweDcxLzB4MmY4IFsgICAxNC42NzUzNjRdICBbJmx0O2Zm ZmZmZmZmODEwNGQxNzUmZ3Q7XSA/IHRhc2tsZXRfYWN0aW9uKzB4NzYvMHhjNSBbICAgMTQu Njc1Mzc2XSAgWyZsdDtmZmZmZmZmZjgxMjBhOWFjJmd0O10gPyBlb2lfcGlycSsweDViLzB4 NzcgWyAgIDE0LjY3NTM4OF0gIFsmbHQ7ZmZmZmZmZmY4MTA0Y2JjNiZndDtdID8gX19kb19z b2Z0aXJxKzB4YzQvMHgxYTAgWyAgIDE0LjY3NTQwMF0gIFsmbHQ7ZmZmZmZmZmY4MTIwYTAy MiZndDtdID8gX194ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDFjNy8weDIwNSBbICAgMTQuNjc1 NDEyXSAgWyZsdDtmZmZmZmZmZjgxMzRiMDZjJmd0O10gPyBjYWxsX3NvZnRpcnErMHgxYy8w eDMwIFsgICAxNC42NzU0MjVdICBbJmx0O2ZmZmZmZmZmODEwMGZhNDcmZ3Q7XSA/IGRvX3Nv ZnRpcnErMHgzZi8weDc5IFsgICAxNC42NzU0MzZdICBbJmx0O2ZmZmZmZmZmODEwNGM5OTYm Z3Q7XSA/IGlycV9leGl0KzB4NDQvMHhiNSBbICAgMTQuNjc1NDUyXSAgWyZsdDtmZmZmZmZm ZjgxMjBiMDMyJmd0O10gPyB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDI3LzB4MzIgWyAgIDE0 LjY3NTQ2NF0gIFsmbHQ7ZmZmZmZmZmY4MTM0YjBiZSZndDtdID8geGVuX2RvX2h5cGVydmlz b3JfY2FsbGJhY2srMHgxZS8weDMwIFsgICAxNC42NzU0NzNdICAmbHQ7RU9JJmd0OyA8L3By ZT48cD4mbmJzcDs8L3A+PHA+Q29tcGxldGUgbG9nIGlzIGF0dGFjaGVkLjwvcD48cD4mbmJz cDs8L3A+PHA+QlIsIENhcnN0ZW4uPGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXItbGVmdDogMnB4IHNvbGlkICMzMjVGQkE7IHBhZGRpbmctbGVmdDogNXB4O21h cmdpbi1sZWZ0OjVweDsiPi0tLS0tVXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hyaWNodC0tLS0t PGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4JS29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtr b25yYWQud2lsa0BvcmFjbGUuY29tJmd0OzsgPGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4J S29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IHhlbi1k ZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7OyBKYW4gQmV1bGlj aCAmbHQ7amJldWxpY2hAc3VzZS5jb20mZ3Q7OyBTYW5kZXIgRWlrZWxlbmJvb20gJmx0O2xp bnV4QGVpa2VsZW5ib29tLml0Jmd0OzsgPGJyIC8+PHN0cm9uZz5Wb246PC9zdHJvbmc+CUNh cnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0OzxiciAvPjxzdHJvbmc+ R2VzZW5kZXQ6PC9zdHJvbmc+CU1pIDI5LjAyLjIwMTIgMTM6MTY8YnIgLz48c3Ryb25nPkJl dHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNlIGFmdGVyIG1l bW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz48c3Ryb25nPkFubGFnZTo8L3N0cm9uZz4JaW5s aW5lLnR4dDxiciAvPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+LmJvZHljbGFzcyB7IGZvbnQt ZmFtaWx5OiBtb25vc3BhY2U7IH08L3N0eWxlPiAgICAgICAgICAgICAgIDxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+ICAgICAgIC5ib2R5Y2xhc3MgICAgICAgeyAgICAgICAgIGZvbnQtZmFt aWx5OiBBcmlhbCwgVmVyZGFuYSwgU2Fucy1TZXJpZiAhIGltcG9ydGFudDsgICAgICAgICBm b250LXNpemU6IDEycHg7ICAgICAgICAgcGFkZGluZzogNXB4IDVweCA1cHggNXB4OyAgICAg ICAgIG1hcmdpbjogMHB4OyAgICAgICAgIGJvcmRlci1zdHlsZTogbm9uZTsgICAgICAgICBi YWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOyAgICAgICB9ICAgICAgICBwLCB1bCwgbGkgICAg ICAgeyAgICAgICAgIG1hcmdpbi10b3A6IDBweDsgICAgICAgICBtYXJnaW4tYm90dG9tOiAw cHg7ICAgICAgIH0gICA8L3N0eWxlPiAgPGRpdj48cD5HcmVhdCBuZXdzOiBpdCB3b3JrcyBh bmQgbG9hZCBpcyBiYWNrIHRvIG5vcm1hbC4gSW4gdGhlIGF0dGFjaGVkIGdyYXBoIHlvdSBj YW4gc2VlIHRoZSBwZWFrPC9wPjxwPmluIGJsdWUgKGNvbXBpbGF0aW9uIG9mIHRoZSBwYXRj aGVkIDMuMi44IEtlcm5lbCkgYW5kIHRoZW4gYWZ0ZXIgMTYuMDAgdGhlIGdvaW5nIGxpZmUg b2YgdGhlPC9wPjxwPnZpZGVvIERvbVUuIFdlIGFyZSBiZWxvdyBhbiBhdmFlcmFnZSBvZiA3 JSB1c2FnZSAoZmlndXJlcyBhcmUgaW4gUGVybWlsbGUpLjwvcD48cD48YnIgLz5UaGFua3Mg c28gbXVjaC4gSXMgdGhhdCBhbHJlYWR5ICZxdW90O3RoZSBmaW5hbCBwYXRjaCZxdW90Oz88 L3A+PHA+Jm5ic3A7PC9wPjxwPkJSLCBDYXJzdGVuLjwvcD48cD4mbmJzcDs8L3A+PHA+PGJy IC8+Jm5ic3A7PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3 MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBR0VDQUlBQUFDcHY0NVlBQUFnQUVsRVFWUjRuTzJk ZlhRVVZaNzNiMGdDSVNBSndTQmd0a25Fa0pBM3pBWVZmVWFQajJjZEhjZURPSUZsWmdCM2Rw eGhSa1FqNktvYzUyQ3ZzRG9LQXpqQkxEbW9aSU5CTU4yQkJGbGZFRWtFOXhBSjZLQkVqTHc0 S0VoM09xLzNuejNuK1NQUEh4ZXVSZDJxNnB2dXJ1cnFxdS9uOU9uVFhYM3IzdnU3ZGV2YnY5 eXUrb1o4QmdBQXdCRzB0cmFTZVBjQkFBQkFER2h0YlgzampUY3VhVG9GQUFDUXlMenh4aHZR ZEFBQWNBalFkQUFBY0E3UWRBQUFjQTdRZEFBQVNDUWFCWlNmUXRNQmtJSVFFdTh1RElOWTlU YXhvbllWZzRPRFRNMmg2Y0NCbUNjOXZHYnhSVXlxTlFsb3VyUHA3KzgvY3VTSXorYzdmLzU4 VTFPVDhpTm91cXRadUhEaGIzLzdXK1dXZi8zWGYxMjBhRkUwZFJKQ0NDRkpTVWxYWFhWVldW blo4dVhMejU0OUcxMDNZNHltVG9XVjdDalZ6V0p4aEtZN21NN096cGFXbHJhMnRxNnVycWFt cGlOSGppZy9oYWE3bWtBZ1VGUlU5TVliYjdDM3I3LytlbkZ4Y1RBWWpLWk9yZ0tCUU9EUW9V TVBQL3p3NU1tVFQ1dzRFVzFmWXdjMDNmcDZRQXo1NktPUHpwOC9yL2NwTk4zdEhEMTY5SnBy cmpsMjdOaXhZOGNtVFpyRXBrRi9mLytLRlN1dXZ2cnEwYU5IVjFaVy92RERENnd3SVdUanhv MGVqeWMxTmJXc3JPeVRUejRSS3hSVjRPbW5uLzdsTDMvSlhuZDNkLy9Mdi96TFZWZGRkZFZW Vi8zbU43L3A3dTdtZTIzWXNHSHExS2tqUjQ2Y01XUEdCeDk4c0huejVtblRwckdHRGg4K3pJ cDk4Y1VYUC92Wno4YU1HVE5xMUtpNzdycnJ6Smt6cWtZajZ5SGZTQlNJTllzdnhQS2FQVFNv MW1CQXdnWmlBQ0ZrOWVyVjJkblo2ZW5waXhZdENvVkNsTkpiYjcxMTY5YXR2RXhuWitla1Na TlU2aEFLaFJZdVhKaWVuajV4NHNRMWE5WVl4eVZUSWJBWWFEcWdyNzMyV25GeGNYRnhjVjFk SGR2eXB6Lzk2YzQ3N3p4NTh1UVBQL3l3Y09IQzMvM3VkMnc3SWFTeXN2THJyNzhPQkFMUFB2 dHNSVVdGV0p1b21KMmRuZGRjY3cxNy9kaGpqOTE5OTkxbnpwdzVmZnIwUC8zVFAxVlZWZkc5 NXN5Wjg5VlhYd1VDZ2VlZWUyN3MyTEVQUFBBQWYzdmpqVGV5WW9XRmhlKzg4MDR3R0R4Ly92 elNwVXNYTEZpZ2FqU3lIbEw5UEYxbVBiMjZ1dnFlZSs2UjdLSHFyY0dBaEEzRUFFSUlxL2JN bVROMzMzMzM0NDgvVGluZHRXdFhRVUhCd01BQUsvUGdndzgrLy96enFoMnJxcXA0Zis2NjZ5 N2VUODI0WkNvRU1RZlh2WUR3bEplWHo1bzFpNy8xZUR6SGpoMWpyMCtmUGoxeDRrVDJtaEJ5 N3R3NTlqb1FDS1NrcEloVmlaTFgyOXVibXByS1hrK2VQUG56eno5bnJ6Lzc3TE1wVTZid3Zm Nys5Ny96bWxWdk5Sc0tCQUpYWDMyMXF0SElla2lqMFBTV2xwYVpNMmZ5UDJYQzlsRDExbUJB d2daaUFDSGtiMy83RzN2OStlZWZYM3Z0dGV4MVJVWEY2NisvempjR0FnSFZqbE9tVE9FN2Z2 YlpaNXBqcFl3cmJJWEFKSERkQzlCbDgrYk5OOXh3d3cwMzNQRGFhNit4TFNrcEtjcmxncVNr SkxaZFQ1aU1ON0kveWRucjVPVGsvdjUrOXJxdnI0OUxsWEhOL08ySEgzNTR5eTIzcEtlbjYz Vk1wb2NqUm96Z2ZXRDA5L2VQR0RIQ3VBYk5KbzRjT1RKdDJqVGxyd1ZoZTZoNkc5bUE4STNL OVJ6VlI1clY3dGl4SXo4L3Y3Ky9mLzc4K1d2WHJoVjNWUFVuN01pSHJSQ1lBYTU3QWJvY09Y Sms4dVRKWDN6eHhmSGp4eWRQbm56MDZGRkthVTVPenRkZmZ5MFdqa3pUbjM3NjZWLzk2bGZz OWVUSms1VnA0T1RKazJWcTVtK25USmxTVjFkMy92ejV3Y0hCQ3hjdWhFMmlOWHZvOFhqKzUz LytSN25sMEtGREhvL0h1QWJ4eFprelovTHo4L2Z0MjZjc0g3YUhxcmVSRFVoWWxIbjYzLzcy TjU3K0R3NE9GaGNYVjFWVmVUeWVucDRlY1VkbG52NzU1NStISGZtd0ZZS1lnK3RlZ0M2QlFH REdqQmx2dmZVV2Uvdm1tMit5NjE2ZWUrNjV1KysrKy9qeDQzMTlmWWNQSDY2c3JHUUZocVhw N0xxWHBVdVhLcTk3V2Jac0dWL252ZXV1dXg1OTlGR1ptdm5iOGVQSDc5aXhJeFFLZmZIRkY1 V1ZsWkZwK3IvLys3K1hsNWQvOU5GSG9WQW9GQXJ0Mzc5LzVzeVphOWFzWVo5bVpHVHdkU2ZO bXZtTEcyKzhjZlBtemFySzlYcW9WMjFrQXhJV1FzalBmdmF6czJmUG5qMTc5cDU3N3VITDlK VFN1cm82UXNpcnI3NnF1V05WVlJYYmtTM0VoeDM1c0JXQ21JUHJYb0F1Q3hjdTVDTENlUGpo aHhjdVhEZ3dNT0QxZXRsRkYwVkZSZnkzVS9rRmdhU2twREZqeHBTV2xqNysrT1A4NmhSS2FU QVlYTHg0OGRpeFk4ZU9IYnQ0OFdKKzNhU2twci8xMWx1NXVibkp5Y24vOEEvL3NIYnQyc2cw ZlhCd2NPM2F0Y1hGeGFOR2pSbzFhbFJ4Y2ZGZi92SVgvdW1xVmF2R2pCbGpVTFB5aFJMakh1 cFZHOW1BaElVb3JudFp1SEFodjV5R1VycHQyN1pwMDZiMTlmVnA3dGpkM2YzclgvOTY5T2pS MmRuWnl1dGU5T0lLV3lHd0dHZzZBTzdpM252djVYY2syTE5DWUF5dWV3RUFVRXJwd01CQWRY VjFZV0Vodi9yUWJoVUNHVlFpRGswSHdLVVFRandlVDJ0cnEyMHJCREkwTlRYMTl2YXkxNzI5 dmJqdUJRQUFFcGpXMXRaUFAvMjByNit2cjYvdjAwOC9iV3RyVTM0S1RRY0FnRVNpdTd2N3dJ RURmci9mNy9lM3RyWXFmd0NuMEhRQUFFaG9zSjRPQUFET0Fab09BQUFKakl1dVpUeStkKy94 dlh2ajNRc0FBTEFPeDJwNlh5aTAvcFpiMXQ5eVMxOG9GTysrQUFDQVJUaFcwejk0NlNXdngr UDFlRDU0NmFWNDl3VUFBT0tEUXpUOS9NbVRhL0x6bWFhdnljOC9mL0prdkhzRUFBQ21FQXdH VzF0YitiV01xbjgyNlJCTnIxKzhtQWs2ZTlRdlhoenZIZ0VBZ0NuczI3ZnYyTEZqdmIyOXZi MjlSNDhlVmJrOU8wVFRHVTg5OVpSTXNhNnVMdXVMeVpmczdlaUlTN3VJMTVwMkVhODE3ZG84 M21qdytYemNZR2RnWU1Ebjh5ay9kYU9tSHp4NDBQcGk4aVV2Yk5vVWwzWVJyelh0SWw1cjJy VjV2TkhnaWp5OXQ3ZjN4SWtUdi8zdGI0ZUdoazZmUG0zOC9MLy8rNzloeXd3TkRaMDhlVEtH dGNtWDdEcDJMQzd0SWw3RWkzZ3RpM2RvYU9qcnI3OCtjZUtFL0I4S25FQWc0UHoxZE1aVFR6 MDFKTUdwVTZlc0x5WmZrcmExeGFWZHhHdE51NGpYbW5adEh1K2x3aWJnUmswSEFBQTdFSm5R dWVLNkZ3Ynk5R2hLSWw1cjJrVzgxclJyODNndkZZNElPNjZuMTlmWEZ4WVdwcWFtbHBhV3Ry UzA4TzByVjY3ay8rZnc2NisvbmoxNzlzaVJJMmZQbnMzK2g3MjRSUVh5ZEFCQUFoR1pmdHJ4 dXBjSEhuaWd2YjI5dTd0NzA2Wk5FeVpNWUJ2YjJ0b21UWnJFTlgzZXZIa3JWcXpvN3U1ZXNX TEYvUG56TmJlb1FKNGVUVW5FYTAyN2lOZWFkbTBlNzZYQ0VXSEhQSjF6NHNRSmo4ZERLZTN1 N2k0dUx0NjdkeS9YOUFrVEpwdytmWnBTZXZyMGFhYjc0aFlWeU5NQkFBbEVaTEpwMyt0ZVRw MDZWVjVldm5QblRrcnAwcVZMWDN6eFJVb3AxL1FSSTBhd3Z5LzYrL3VUazVNMXQzRDYvLzcz QzYrODh1VHZmMDhQSEJnYUdqSitQcjF6WjlneTlNQ0JVNmRPeGJBMitaSzByUzB1N1NKZXhJ dDRMWXVYSGpqdy8wS2hDNis4MHRQZUhsdGRqWnVtdDdhMmVqeWVMVnUyc0xkSlNVbEVBYVUw S3l0TGxaV0xXMVFnVHdjQUpCQ1JpYWNkL2RPcnE2dXpzN04zNzk0dGZzVHo5TXJLU3I1Nlhs bFpxYmxGQmRiVG95bUplSzFwRi9GYTA2N040NzFVT0NKVUlxNGlQcHBPcnVUaXhZdktqOWlM cjc3NjZxYWJia3BOVGIzNTVwdFBuanlwdVVVRjhuUUFRQUlSbVg3YVVkTk5Bbmw2TkNVUnJ6 WHRJbDVyMnJWNXZKY0tSd1EwSFFBQTdJZ1pNdWhHVFhmRzk3emI4aHJFRzJWSnhHdE51L0I3 aVEzRDhtWEVNNTd4ak9lNFAwZm15L2pPTysrMHQ3ZWZQbjI2djc5ZnM0QkROSjJCUEQyYWtv alhtbllScnpYdDJqemVTNFdIejRVTEY0NGZQNzUvLy82bXBxYjkrL2NmUDM3OHdvVUx5Z0p1 MUhRQUFMQUQwY2hkWDEvZjZkT24yOXZiMzNubkhlVjJOMnE2TTc3bjNaYlhJTjRvU3lKZWE5 cDE2WHE2Nk1zb2JvRXZJd0RBMlppaHJuYnhaUlMzd0pmUjRuWVJyelh0SWw1cjJyVjV2SmNL bTRCZGZCbkZMZkJsQkFBNG01aW9xQzM4WGhpbkZMNk00aGI0TXNMSER2RWlYcWZHUzJQbnky Z1hUVmY1TW9wYjRNc0lBSEEya1lsbll2Z3lpbHZneTJoeHU0alhtbllScnpYdDJqemVTNFZq Z1MwMFhmUmxGTGZBbHhFQTRHeGlJcWUyMEhTVFFKNGVUVW5FYTAyN2lOZWFkbTBlNzZYQ0p1 QkdUUWNBQURzUW1kQUZnMEdiL2ovU21JTThQWnFTaU5lYWRoR3ZOZTNhUE41TGhTTmkzNzU5 eDQ0ZDYrM3Q3ZTN0UFhyMDZMNTkrNVNmT2tUVDRjdUlaenpqT2JHZUkvTmxwSlQ2ZkQ1MlZU ZWxkR0Jnd09mektUOTFpS1l6bkplbmt3MkViQ0RXdEd1SGVLMXNGL0ZhMHk3aU5Tb2NFYTdJ MHhuT1cwODMwSFFBUUtJVG1kQUZBZ0dzcDE5QkFuM1Bkd3lSamlIazZhYTBpM2l0YVJmeEdo VTJBYnY0TXNxNE1MckVsMUdabTllUzJscFNHOS8rQUFCTUlqTDl0T045cEpHNU1EclBsNUZy TjlOeDlwaXpNb2ZMZWdXcHJkRFJkTGZsTllnM3lwS0kxNXAyTGNqVG1ZaHpLYmVGcG5PRzVj TG9QRjlHbGFZUEVVSTJFSy9YMnpGRVdIcHVvT2tBZ0VRbk10bjArLzAvL1BDRHorZTdjT0hD aFFzWGR1M2FwZnpVTHI2TU1pNk16dk5sckgvc01mYmE2L1cyNUt5cUpiVXRPYXVhYzU1cnlW bFZRV3JwZ1FNVnBIWjV6cXFZdDV1SVBuYUlGL0U2S1Y0YWhTL2pwNTkrMnRUVTFOblorYzQ3 Ny9qOS9pKy8vRkw1cVYxOEdXVmNHSjNueThqWHltdEpiWVh3R0JvYUlrdjJrQ1Y3NHRwSEFJ QlptQ0d0ZHZGbGxIRmhkSjR2WTRXV3BsZmxQQ2VqNlc1YmYwUzhVWlpFdk5hMGE4MTZ1dTEr STQzTWhkRjV2b3hjMHkrSnVKZndGMHpLa2FjRDRHRE1VRmRjbjI1Uk1jMlNTazFuOGsyVzdK bno0RVl1NWNqVHpXc1g4VnJUTHVJMUttd0NidFIwKzhEMW1ndTY4akdFUEIwQVIyT0dETHBS MCszelBhK3A2Y2pUcldrWDhWclRMdUkxS213Q0R0SDBCUFZsSkV2MnNOZkZLM2FRSlh0VXoz eDczUHVKWnp6ak9lYlBFZnN5d2o5ZGpYMis1NUduRHlHUHM2cGR4R3ROdS9CbGpDVllUd2NB SkJDUkNSMzgwOVhZNTNzZWVmb1E4amlyMmtXODFyVHIwanlkWDVuT3R6UTBOT1RsNVNVbkor Zm01alkwTkZCMytESWlUd2ZBelVTbW4vYjFUMWRxK3JoeDQveCtmeWdVOHZsOEdSa1oxQ1cr ak1qVGtjZFoxUzdpdGFaZFYxLzNvdFQwa3BJU3Y5L2YwOVBqOC9uS3lzcW9TM3daa2FjRDRH SWlVMDQ3ZWdNd2xKcCs0TUNCY2VQR0VVTEdqUnQzNE1BQjZnNWZ4cm1MMTdQWFpNbWV1WXZY cytjNUQyNWtyL24ybUxlYmlENTJpQmZ4T2lsZUdvVXZvMzM5MDVXYVBtM2FOTDcyY3YzMTEx TjMrRElpVHdmQXpVU21uSW1oNlptWm1YenRaZno0OGRRZHZveGt5WjVMLzk0STYrbVd0NHQ0 cldrWDhSb1ZqZ2c3YXJyS2w1RlNXbDlmNy9GNGtwT1RwMDZkK3VhYmIxSjMrREpxYWpyeWRB QmNRa3prMUJhYWJoS0ptS2V6L3lLTlBOMzZkaEd2TmUwaVhxUENzUUNhYmlQSWtqM01NQjE1 T2dBdUpES2hzKzkxTHpFbkVmTjBVZE9ScDF2VEx1SzFwbDNFYTFRNEZqaFQweFBYbC9IKzRw b0tVZ3RmUmp6ajJXM1BFZnN5cW5DbXBqTVNNVThYSDhqVHJXa1g4VnJUTHVJMUttd0NidFIw bTZCM3VRdlcwd0Z3Q1pFSkhkYlQxZGprZTE1UDA1R25XOU11NHJXbVhjUnJWTmdFN09MTE9E QXdzSExseXNtVEp5Y2xKYkh0anZkbDdCZ0trNmR6MFk5M1R3RUFwaENaZnRvM1QxZHErcXBW cTZaUG45N2UzajQ0T01pMk9ONlhzVmJuRWthZXAvTUNzVzNYbW1MeUpaSEhXZE11NHJXbVhX dnk5SjZlbnZmZWU2K3BxZW5zMmJPcWoreWk2UjZQUi9YZk9oenZ5NmgzV1RwL1ZCaHFPZ0Fn MFlsTU9abWdIenQyN0x2dnZ0dTllL2Y1OCtlVm45cEYwNU9Ua3g5NTVKSFJvMGQ3UEo0ZE8z WlFGL2d5VnBCYTdzVkl0SHdabCtlc0l2QmxSTHlJMTRueDBpaDhHZDk5OTEwdTE5OTg4MDFM UzR2eVU3dG8rb1FKRTN3K0gvTmx2UHJxcTZrTGZCbVJwd1BnY2lKVFRwVldmL25sbDhxM1lU UjkzNzU5K2ZuNVNVbEpsTklGQ3hiVTFkVkYxZ2xObEpvK2YvNThuOC9IZkJtenM3T3BDM3da OWFTY3I2Y2JhN3JiMWg4UmI1UWxFYTgxN1Zyanl4ajViNlRYWDMvOXJsMjdtUGgrOWRWWFU2 ZE9qYXdUS2tSZnhxNnVycC84NUNlcHFhbDVlWGxzWWQzeHZveGhMbnE1OGtKMUFJRHppRXcv by9MYVRVMU5EWVZDVEhiUG5UdVhucDRlV1Nlc3dXRjV1ckdtdXkydlFieFJsa1M4MXJScmQv LzBPKzY0WS9QbXpZU1FycTZ1QlFzV3pKa3pKN0pPV0FQeWRBQkFBaEdaMEVXbDZWMWRYZmZk ZDE5NmVucDZldnFjT1hPKy9mYmJ5RHBoRGNqVG95bHA4N3dHOFVaWkV2RmEwNjVMN3lPTk9Z bm95NmpweGFqNWJJZmU0aG5QZUk3dGM4UytqUGE5anpUbUlFK1BwcVROOHhyRUcyVkp4R3RO dTVibDZZT0RnNnBGR0lhMnBoTjlvdW1FMldBOUhRQ1FRRVNzZGYzOS9VZU9IUEg1Zk9mUG4y OXFhbEoraER6ZG9tSmlTZVRwRE9SeDFyU0xlSzFwMTRJOHZiT3pzNldscGEydHJhdXJxNm1w NmNpUkk4cFA3ZUxMeUZpNWNpWGY2SGhmUnVUcEFMaWN5UFR6bzQ4K1VubThLSW5uMm91cXRy YTJ0a21USnZHTmp2ZGxSSjdPUUI1blRidUkxNXAyWFgzZGkxTFR1N3U3aTR1TDkrN2R5emM2 M3BjUmVUb0FMc2NNWGJXTHBpOWR1dlRGRjE5VWJuUzhMeU1SSEJuSmxiNk0vRG0yN2NZclhy MW4rUFloWGhmR1M2UHdaVFJHVjlPWnRscTI5c0wrdlpHeUZjZjdNaUpQQjhEbHhGQk9PWGJK MDhXTjhHWEVlcnFwN1NKZWE5cEZ2RWFGVFNETzE3Mkl1VDkvQzE5RzVPa0FPQnN6MURXTXBt L2Z2dDNqOFNnWFJzem9SS3hBbmg1TlNadm5OWWczeXBLSTE1cDI3WjZuVDVnd1lkdTJiZjM5 L1dhMEhYT1Fwd01BRWdnelpEQ01wbWRtWmdZQ0FUTWFOZ1BrNmRHVXRIbGVnM2lqTElsNHJX blg3bm42czg4K3UzTGx5dTd1YmpQYWppSHdaY1F6bnZHY1dNOFIreklhRTBiVEd4b2FSbzBh NVRBUEw1dDh6eU5QWnlDUHM2WmR4R3ROdTNiUDA3T3pzeHNhR3JDZWJnWllUd2ZBNVpnaGcy RTBmZHk0Y1ZoUGowa3hzU1R5ZEFieU9HdmFSYnpXdEd2M1BOMms5WFJ4SmFlK3ZyNndzREEx TmJXMHRMU2xwWVhDbHhGNU9nQk9KN2E2eWdpajZaWjVBenp3d0FQdDdlM2QzZDJiTm0xaTkv M0RseEY1dXFudElsNXIya1c4Um9WTndIYmVBQ2RPblBCNFBCUytqTXJIQmhMdnpnSUFZbzha dWhwRzA1T1Nrc3hvbFNGcStxbFRwOHJMeTNmdTNFbmh5Nmpjdm9IQXh3N3hJbDRueFV1dDky VmtUSmt5NWV6WnM3RnRrcVBTOU5iV1ZvL0hzMlhMRnZZV3Zvejg0ZlY2NDkxWkFFRHNNVU5Y dzJqNml5KysrTkJERDEyOGVOR010cFdhWGwxZG5aMmR2WHYzYnI0RnZvejhVVXRxWTlpdU5j WGtTMks5MVpwMkVhODE3ZHA5UGQyazMwakZPbFZiTGw2OENGOUdZMDBIQUNRNk1aRlRGZkg4 alRUbU9EVlByMENlam5pakxvbDRyV25YN25sNll1SFVQRjFUMHdFQWlZNFpNaGhHMC9mdDI1 ZWZuOCt1Zmxtd1lFRmRYWjBabllnVnlOT2o2YUhOOHhyRUcyVkp4R3ROdTNiUDA2Ky8vdnBk dTNheEplK3Z2dnBxNnRTcFpuUWllaHp1eS9oK2NkeDdpMmM4NHptMnovSHhaVXhOVFEyRlFr elR6NTA3bDU2ZUh0dm1ZNHRUOC9RaHI4WTlSMjdMYTZ5TVYzbVRseHZpTmJWZHhHdFUyQVRD YVBvZGQ5eXhlZk5tUWtoWFY5ZUNCUXZtekpsalJpZGloVlBYMHdrc1g2d0ZOKzRDYXpCREJz Tm9lbGRYMTMzMzNaZWVucDZlbmo1bnpweHZ2LzNXakU3RUNxZm02WnFhN3JhOEJubDZsQ1Z4 ZksxcDErNTV1a21JVjd2THVEQzYxcGNSZWJyRklFOEgxbUNHdXRyRncwdkdoZEcxdm96STA4 MW9GM202TmUwaVhxUENKcUNyNlI5KytHRmhZV0ZLU2twaFllRkhIMzFrUnR0S1RaZHhZWFN2 THlQeWRHdEJuZzZzd1F4ZDFkWDBvcUtpbDE5K09SQUl2UHp5eXlVbEpXYTByZFIwR1JkRzkv b3lMdGtESHpzcjQ1MzdkSTZyNG5YYjhiVkR2TlI2WDhiazVPU2VuaDVLYVNnVVVnbG9yRkJx dW93TG8ydDlHWkduV3d6WlFKQ3FBd3N3UTFkMU5WMHB1TEg5OTBhYTFjcTRNTHJXbHhIcjZX YTBhN3llempYZERmR2EyaTdpTlNwc0FrYWFya2xNV2hYcmxIRmhkSzB2SS9KMGkwR2VEcXdo Sm5LcXdvMGVYamI1bmtlZXpyQmhIb2M4UFlZbEVhOVJZUk53bzZiYkJPVHB0Z1Y1T3JBR00y VFFqWnB1ays5NTVPa01HK1p4eU5OaldCTHhHaFUyQVlkb3VyTjlHWXRYN0loN2IxMzFURGFR NGczd3dzU3p1Yy94OFdWTUxKQ25SOU5EbStjMXlOT2pMSW5qYTAyN3lOTmpDZGJUUVV6QWVq cXdCak5rMEkyYWJwUHZlZVRwREJ2bWNjalRZMWdTOFJvVk5nRzdhSHBEUTBOZVhsNXljbkp1 Ym01RFF3T0ZMeVB5OVBpQlBCMVlneGxhYWhkTkh6ZHVuTi92RDRWQ1BwOHZJeU9Ed3BjUmVi cko3U0pQdDZaZHhHdFUyQVRzb3VrbEpTVit2NytucDhmbjg1V1ZsVkg0TWlKUGp4L0kwNEUx bUtHbGR0SDBBd2NPakJzM2poQXlidHk0QXdjT1VQZ3l3cGN4ZnZIT2ZUcUhiQ0R1aWRkdHg5 Y084VkxyZlJrdFp0cTBhWHp0NWZycnI2ZndaVVNlSGorUXB3TnJNRU5MN2FMcG1abVpmTzFs L1BqeEZMNk1XRTgzdVYyc3AxdlRMdUkxS213Q2R0SDArdnA2ajhlVG5KdzhkZXJVTjk5OGs4 S1hFWGw2L0VDZURxekJEQzIxaTZiSEJPVHAwZlRRNW5rTjh2UW9TK0w0V3RNdTh2Ullnandk eEFUazZjQWF6SkJCTjJxNlRiN25rYWN6YkpqSElVK1BZVW5FYTFUWUJCeWk2ZkJseEhNTW4r SExpR2NMbnVITEdCN2s2ZEgwME9aNURmTDBLRXZpK0ZyVEx2TDBXSUwxZEJBVHNKNE96RUNj VkdiSW9CczEzU2JmODhqVEdUYk00NUNueDdBazR1VzRTOU1IQmdaV3JsdzVlZkxrcEtRa1Fn aUZMeVB5OVBpQlBCMllnYnMwZmRXcVZkT25UMjl2Yng4Y0hHUmI0TXRva3p4ZE5SSGRrTWNo VDQ5aFNjVExjWmVtZXp3ZW44K24zQUpmUnB2azZjUE5XQjJRNURvZ0JHQkQzS1hweWNuSmp6 enl5T2pSb3owZXo0NGRPeWg4R1ZYYm44NkpWYnZEalpjN0ZFcldSallRMXR2RTllMkRMeVBp TlNOZTFWbnNjRi9HQ1JNbStIdys1c3Q0OWRWWFUvZ3lxaDV4VEJzSjhuUUFZb0M3OHZUNTgr ZjdmRDdteTVpZG5VM2h5M2psdyt2MXhxcmQ0UmFySmJYRHE0MFE5aldRdU91dFdFK1BZVW5F eTNHWHBuZDFkZjNrSno5SlRVM055OHRqQyt2d1pWUStWTUpxSmNOdHVwYlV4ckczTVFGNU9q QURkMmw2VEhCd25sNGhxS1J0ODNTdTZZbWJ4eUZQajJGSnhNdUJwZzhiQitmcG9xWmJCdkow QUdJQ05IM1lJRStQcG9kaU1UWUZrYWZIdGwwYnhtdHF1NGlYQTAwZkJvNzNaYXdndFhIbzRZ Wmlzb0hVRk5jTWE2K2E0cHJhZVBRMnRsSERseEhQTVg4bUc0aHlDM3dadzRNOFBab2Vpc1c4 WGkvWlFOeVdwN01rSFhsNnJFb2lYZzd5OUdHVFFPdnBaQU1aM3ZYcDhiaVZ0SmJVZGd5cE5W MW1yNFJlVDFkcE9nQ3hBcG8rYkJJb1R6ZlFkTTA4WGRSMEMvSWFwczdHZWJvNFRaR25HMk8z ZU0xdUYvRnkzS2pwSzFldVpLYU0xT20rakxXa05pSHk5TEJKdDRHbUp5akkwNEZKdUU3VDI5 cmFKazJheERYZDJiNk1CcHB1aHp5ZGlacE1uaTdLTi9KMFkrd1dyOW50SWw2T3V6Uzl1N3U3 dUxoNDc5NjlYTk9kNnN2STlLTEMzbm02Z2Fhck1ORDBCQ1hoOHZRRTZxckxjWmVtTDEyNjlN VVhYNlNVY2sxM3FpL2ozS2R6dkY3djhweFZaRmkrakl2WFI5bnVzT0psM29xMXBMWWxaMVV0 cVRXb1RmVXAyOUtTczBxK1hidjU5ckhZRThpWGNkblRzNk9KMSt4eHR0dnhqV084N3ZKbFpQ L2VpRU9kNjh2bzlYcHJTYTNOODNTdjE4djZpVHpkL2lUMGFMc0tkK1hwSEo2bk85V1hrVW1l Z2FiYllUMmRxL21scmlybUl0YlRvMnczNXZIV2xOVEVzRUw3eDR2MWRHUHNxK2xPOVdXOEpI bGVXMStmYnFEcFlrbk5mVTN1b0lrZ1R3Y200VkpOajRaRXlkT05GMTdNeTlPTnBjbzRUOWZM VzVHbkQ3ZGQ1T25XdEd2RGVLSHB3eVloOHZTS2lCYlRvOC9UeVFiQ1ZzbkRacUQ4aXBlS3l3 K0QxTlVaZWJveU9oNXNvcVRxdFlaL1NBRTd3QTRRTkgzWUpFU2VIbGJUVGNyVHVWTHIvUzg2 WGt6VTlGcFN5NzhQVkpleDYybTZxcVFCTW5tY2ZHMURPaU1qYXJSNFBiN3lOZDlpLzd5MXBx U21ZeWk4cHRzd2J6VzFYVnZGQzAwZk5nbmt5MWhCYXU4dnJpSFNqb3cvUGtmbkZPajFldTh2 cnFrZ3RjWStpOFViaW9jSVlTWFpjL0g3eGJXa2xya3RybG16UmxXbldOdWx2VFlVRDEzMk9J emV3UzU2bDBSVlQ1VE9pOHg3a250SmNsOUdzZWN4NzFWTW5tdkRIVk83UGNkMzNPTFNPcHM1 OEdVY05oSGs2WkxyeTVLMXlaU01PRThYMDB6TkpRSlZ2c2xMS3ZOdWcrN3hTeTEvWEhqcElN cUVYVngySDdweUdQbHlEV3VYL1NkVmczRTJ5R3VVRFVXVFQya01GQ0h2bnlxNXRJVVE1WHFS UVo2dS9NZzQ4VGNJeDR3OFhXYXhLKzU1cTNKbVd0Q3V3ZThsZXNXTWw3Q1FwOGVCQ05iVEkx ZzJsU3l2Vnl5eXhYU3laTThRdWFLcm9yaUlpcU44aE5WMHhoWEZPb2hLMDFYWHdOVHkyb2hh MDlueUMxK0gwUnRuWmVjTlFsQlZvaG9INDZPZ1hFM1NmS3U2REYvVjZKWFZhV2k2ekJReWRi M2JnaDh3WXRKL0EwMDNkWHprMnpLdkc5RDBDTkhVZEhFMFdmN0lQOVhMdlBqNnNuR3hrZzBs eHZteXF0MncycTJYcHlzbGlXd2dKUnRLaGdoaE9lWVZIUk4wcDJSRFNlMlYwcXdYTDlsQVZC azZleWczOG5pSCtEVThWOG9mMTNUVzdxV1BpTWJvc2RkelZ1YW94NWFvQTJHMXNYZzFLeEhI V1huVXZGNnZNbkRXSzdZTXJkUjAxVjZzdlBMNEtvZmE2L1dxZ2xLT2pBcmxlamR0YXhPbmls NFVNdkpuUVo2dXVWNHZuN2VTeTM4UDhkcFVVWGk5WHRYZm5RYnlLaCtJYWdBMWExWVdNOVow cFc2b1VQYmM0UGlLQjlvTUdiU0xwdGZYMXhjV0ZxYW1wcGFXbHJhMHROQklmUm5GNFl2eUlV cWtaaG1aWXBkcTZ4ajJsZWxzbDRyTDBzTTh6VlcvWWZLUEtraHR4eERoWlhoNVBVMVhQcmoy R1dpNk10NEtoYWIvdU1iaUpVUGVIMXV2VUNxbVlwVkRiSjExbTRVd1JJZ3lMakZleWNPbkdp dldnUXFkQjZ1V0tRNkxqbTNodncrTHFUM3Z0bkUzVkIzbW9zYUhYWFhDS3dlRVhQbE5veXBE cnZ5YlEwOUVOQ3ZSSzhEalZmVmZUOHYwWk91S2FhOFlCREdyRUErb2NraFZhaXQ1NkRXNkpI ZVNSdjlRTmFRM1hSMnU2UTg4OEVCN2UzdDNkL2VtVFp2WWZmK1IrVExXQ2ljOGt4disxdXYx dm4rcWhGMyt3US9BajFwREx1VmZRNFN3OUVlcElGeHJPb1orVE5QV3JGbkRGWUh0eUI2c0dL dVFGVDVWVXZLalVBNHJUNytzNmNySC9TVTFldHFrV1pLMU8rUWxReDJLMVFaRlJzeTZwMUx6 UzNzcFpMM21jcnRNZkpYS2UybVFMMzhOOEpMOFU2Nm5iRURZTTgzSk1kQlp2WGlWM3l0SzVX VUw1V0hsVzI4QTJZSGpoN3VDMUo0cUtSRy9uelFmYkY2cGpydHlickF0YzFibUtLY2ZENEh2 eURieXc4Ry9EbGwwckJpZnQwT0VzRUNVKzdKaUZmeGZtaERpOVhyNW4wMnNKQ3ZEZXNnRmxJ MWU3WldUbWJ0RXFDUkovRHRNZVI3eEhoNXZ5eEVIdHZieWFQTXZTOTV1N2VWanAvd2VWWjdD YTlhc3FWVk1BSFdaY09rQUFDQUFTVVJCVlBacDdlV3JzL2c0c3dGa0pWVzVnbkpmZm54NVo3 Z3hCZytmbjcrcUFWVEd5N2ZUbkJ6ZUJHOVhWSGIyVjRzWldtb1hUZWVjT0hIQzQvSFFTSDBa SldVdWpvK3dtcTZkcDErWkxFZmVya1JWUTFjS3V2R095aStiUzJkNExIb2I1Mk9rMEhRODhJ aitvVnlsNUJ0ZG9lbW5UcDBxTHkvZnVYTW5qZFNYY1huT3FncFNhL3o4L093L2hTMnpQR2ZW L1NVMU1heU5sNXo3Umc3cElIUGZ5Q0h5dm93ZFpPNGJPVEZydDRNWXhEdDB1WXplczZwZHNU YmVXOGtlVnVVOFo4WTRSM044NXo2ZDB6RkVUR3JYaHZHYTJpN2lWYzRyNVJhSCt6SlNTbHRi V3owZXo1WXRXOWpieUh3WksrTDloUnoyOFdQYU84dzhmY2diVmVZb21hZnJaZWg2KzJwdVNm UThYV1l0Q0E4OGh2dmdhMktYM2pvN1Q2K3VyczdPenQ2OWV6ZmZFcGt2bzh6SVNxNUV4N1pZ eFpYcjJnYWFycjJlTGdqbC9TVTF2SUJ5dStiSysxQzRKUlNON3VrOGxQSHFxVHpieU5vTisx VlVsZk9jR2VPc1BwMnUvRlZBcGtJMmtsRzJhMDI4UXhKZm9pYk41d2ppMWV4dHpOdTFUN3g2 RDRkck9ybVNpeGN2UnVqTEtKeTZvc1pwYm1SWGE0Z2JsU1V2WGE4dDdDc0txMEc3VjBpazhx MU9lbTdHWStqeVF5TmVpVHlkeDZ2VWRENTZ5bFo0QWQ2VzVsaXBlc0xlaW9majBuWDYzdkRI VjJQZks3OStyaGp6eXk5VTErT1R5ejlOODdtaG1neWFFMGExVVc5ZWlmSHF6VW4xNElRTHpi aGRaVzI2N1dyT0RTMGhGa3ZxelN2bHdMSzNlcU1uRHFETThkV04xeXNScjhReDBqdm9tdnVx bWhpNjhoVDRjYnV6TlQwbVBQWFVVektLVnZKK2lmWEY1RXZPZVhDald1NHRhVGY2WWt3eWRF dnFSSFFwWHN2SDJhQ1lVaXRqZjN6cmNvd0hoRzIvb2piK3hSTk52Q3QyR0JXNC9QV20wYTZx REM5NXVjSkxxWURlOGVYeEdqU3RHWVZtNjhwQVlqSXNjck0wa3VNclZGdWhOTm51Y00xMUw5 RWdxZWw0NEdIOHFKQllnOElEaitFK1ZQTUttaDRlaCtUcFlmTWFjOXBGdklnWDhWb1dMNEdt RzhOOUdVa0hLWDYvR005NHhqT2ViZjRNWDhid0lFOUh2SWdYOFNaRXZBUjV1Z3hZVDhjRER6 d1M1UUZORHcveWRNU0xlQkZ2UXNSTG9PbFUwcGRSYmpUeHdBTVBQT0w3NEpwZS8rQ0QzMy8x VmF4ME1wRTBYY2FYVVdZb25mRTk3N2E4QnZFaVhpZkZTeFNhN3ZWNDFreWYvc0ZMTC9WMWQw ZXZrNG1rNlRLK2pKS2ppUWNlZU9BUjM0ZFMwOWxqdy8vNVAzOTc1NTBvZFRLUk5GM1RsL0hv MGFOUFBQSEVpbVhMSHJ2dnZ2OTc2NjJQTDF6NHhCTlBHRC8vN3Y3N3c1WjVmT0hDMy96bU56 R3NUYjVrMVM5K0VaZDJFUy9pUmJ5V3hmdjR3b1ZNdFpiLzlyYy9hdnF0dC81dHo1NG9kVEtS TkYzR2wxR21uaSsvL05MNll2SWx1OTkvUHk3dElsNXIya1c4MXJScjgzaVZzTFdYOS8vOFo5 ZXR2Y2o0TXNyVTA5UFRZMzB4K1pJWE5tMktTN3VJMTVwMkVhODE3ZG84WGlYMWl4ZC8zOWs1 M0wzMFNDUk5sL0ZsdEw1WE1hZi83Tmw0ZDhGU0VLK3pRYndXazBpYUhwYjJXUC9IRUFBQVND d2NwZW1KQWlFazNsMEE1b0pEN0d6c2ZIeWg2U2JDL3IvSHFGR2pwaytmL3R4enovWDM5eHNV VTg2Uyt2cjZ3c0xDMU5UVTB0TFNscFlXWldIeHhxdXd0MklCa3lDRS9OZC8vUmQvK3gvLzhS OTZwL3F3amhvT3NVMlFQNzYyT29XaDZTYkNqbkZ2YisvSEgzOTg0NDAzL3R1Ly9Wdll3b3dI SG5pZ3ZiMjl1N3Q3MDZaTnFpdDh4QnV2d3Q2S0JVeUNFREo3OXV6QndVRkthVzl2YjJscHFk NDVQNnlqaGtOc0UrU1BMeS9QWDhmeEZJYW1tNGp5R0hkMGRGeDc3YlhpZHMzQ25CTW5Ubmc4 SHVXbjRvMVhZVy9GQWlaQkNQbmpILys0WThjT1N1bm16WnVmZU9JSmZwaFVSMVBtcU9FUTJ3 MzU0MnV3MGZwVEdKcHVJc3BqM052Ym01S1NJbTdYTE13NGRlcFVlWG41enAwN2xSdkZHNjgw YjhVQ0ZrQUlPWDc4ZUVWRnhlRGdZR2xwNmNtVEovWE8rV0VkTlJ4aW15Qi9mUFUyeHVVVWhx YWJpUElZSHoxNk5DY25SOXl1V1poUzJ0cmE2dkY0dG16Wm9pb20zbmdWOWxZc1lCTHNrTjEz MzMyLy8vM3ZmL0dMWDFERlFWUWR6V0VkTlJ4aW15Qi9mRFUzeHVzVWhxYWJDRjlQUDNUbzBP elpzL2w2ZXRnSlVWMWRuWjJkdlh2M2JyR1llT05WMkZ1eGdFbXdRL2IrKys4VFF2YnQyMGYx ei9saEhUVWNZcHNnZjN6RmpYRThoYUhwSnNKK0NoODVjaVM3N3FXdnI0OXZGNHNwZnpwWGJi bDQ4U0xmUmJ6eEt1eXRXTUFreEJOYjc1eVhPV280eEhaRC92amE2aFNHcGdNQWdIT0FwZ01B Z0hPQXBnTUFnSE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFnSE9BcGdNQWdIT0FwZ08zWTJ6TUJF QmlBVTFQWUhwNmVwWXRXM2IxMVZlUEhUdjIrZWVmajNkMzdBNGg1SVVYWHFDR3BxbUEwOTdl VGdqQi81bVJ3VlpUQzVxZXdDeGZ2dnkrKys3NzVwdHZ2di8rKzBjZmZUVGUzYkU3aEpDQ2dv TEJ3Y0hwMDZmSC9jU3pQMnZXckJreFlzU2FOV3ZpM1pFRXdGWlRDNXFld0V5Wk1rWDF2OHlW ODBsNUgvUHk1Y3ZUMDlQTHlzckVZdTZCRUhMTExiZXNXclhxMWx0dlZRNk9hdEJlZnZubDhl UEhaMlptYnJyOHo0TGRPVngzM0hISGd3OCtlTWNkZDdDM1pXVmw3SDg3TkRjM3o1dzVrMUxh MXRaV1VGQ1FscGEyWXNVS1l5TVV4eU5PTFRhdlVsSlMrUC9FK1AzdmYvL3JYLythVXZxclgv MXF5WklsZk1lWWR3YWFuc0FrSnllci9uZVNucWEvOE1JTGdVRGdvWWNlc3JSL05vTVE4c1li YjR3WU1XTHIxcTJhQThWZXIxKy9QaGdNTmpVMXVka0JNUkFJakJrejVwdHZ2aGt6Wmt3Z0VL Q1VybDI3bHY4RGgzWHIxbEZLUzBwS05tN2NHQWdFTm0zYTVFNHA1K2hOcmY3Ky9uMzc5azJh TklsUzJ0ZlhkK2VkZC83aEQzKzQ4ODQ3dWZXVEdVRFRFeGlEUEwydnIwK3A2YjI5dlZaM3pu NFk2TGp5dFo3Vm1xdG9iR3prL2xPTmpZMlUwblBuem1Wa1pIejU1WmNaR1JuZmZmY2RwVFFs SlNVWURGSktnOEdnbThlS2FrMm45ZXZYZXp5ZUVTTkdFRUtTa3BMWVIyMXRiWVNRdHJZMlV6 c0RUVTlncXFxcTdydnZ2bE9uVHAwL2Y3NnFxb3BTT21IQ2hOMjdkM2QzZDIvWXNNSGxmdzZM U0dxNjVtdTNzV1RKRXZhcisvUFBQODhYQ2lvcksyKzQ0WVo1OCtheHQ4WEZ4WC85NjErRHdl Qi8vdWQvdW5tc3FOYTBTVXRMYTJwcUNnYURQcCtQYlFrR2c2V2xwWGZmZlhkcGFXbDNkN2Q1 bllHbUp6Q2hVT2poaHgrZU1HRUN2KzZsdXJvNkl5TmovUGp4NjlhdE05QjBkNTZCNG9tbmFa RXFsbmZoY09YbDVSMCtmSmhTZXZqdzRieThQTGF4dWJtWkVOTGMzTXpldHJhMjV1Zm5wNlds UGY3NDR5TkdqR0FiWFRoV1ZHdmFQUHZzc3hrWkdSa1pHYXRYcjJaYkZpMWF0R0RCQWtycFAv L3pQeTlldkZqY01WWkEwd0VBa1RNd01QRFdXMjlObno0OTNoMEJsNENtQXdBaWhDMFc1K1hs L2ZkLy8zZTgrd0l1QVUwSEFBRG5BRTBIQUFEbmtCaWE3czRmWGdBQVlMZ01UOU9KRHBvbGs1 S1Nycm5tbWovODRRL3NJbFlyNmV6c3ZPbW1tMGFPSEhuVFRUZDk5ZFZYRnJkdUdlTDROelEw ekpneFkrVElrZVhsNWUrOTl4N2JrcGVYbDV5Y25KZVh0MzM3ZHMxNkdob2FQQjVQYW1ycWpU ZmVlUHo0Y1VycGxpMWJycnZ1dXRUVTFKa3paKzdkdTllYWNNeEdIQzV4U3lnVWV1U1JSN0t6 cy9VbU50VWFaT056SVJIUkM4ZnI5ZktONHJTUnFVYzVWbGxaV1NiMTMyTEVLU0ZLa0l3b2ll ZWR6SVJVTVh4Tjd4QWVPcG8rT0RoNDh1VEorZlBuLy9HUGY1VHBTZ3laTzNmdWloVXJ1cnU3 VjZ4WVVWbFphWEhyRnFNYy84ckt5bzZPamxBb3RIMzc5b2tUSjFKS016SXlkdTNhRlFxRi9I NS9Sa2FHWmcxWldWa3RMUzA5UFQwK24rL25QLzg1cFhUdTNMbUhEeC91N3U3ZXNtV0x3MjZu Tkw2eXM2cXFxcXlzcktPalkzQndVSzhHY1pBZEkrVXFWSEY5OHNrblRGellXM0hhU05iRFdM Smt5Wk5QUGhuRDNzWVJjVXFJRWlRalN1SjVKek1oVlppbzZlekZ5Wk1uMmEyeEgzNzRZV0Zo WVVwS1NtRmg0WWNmZnNqSy9PTS8vdU84ZWZOeWMzUFpqUXpzdTBocGtzQTNLbXNXSFRsVVpH VmxuVDU5bWxKNit2UnBoMG1TaURqK3dXQ3d2cjZlWFY1V1dscmEzTnpjMDlPemUvZHVadE1o a3BXVnRXZlBIblp5amg4L1h2blJ5Wk1uVTFOVG5YUWJxckdtVDU0OCtkMTMzNVdwUnpuSWhK Q01qSXowOVBTZi92U25KMDZjaUdGdjQ0dnFMNWlpb3FMWFhudE5xZWw2MDhhZ0hzYjMzMytm bVpuWjFkVVY4ejdIRWVXVUVDVm9XS0xFenp2NUNja3hYZFA3Ky90VFVsSW9wUVVGQmErKytt b3dHS3l1cmk0c0xHUmx1Si9ubURGaitMNUtrd1JWYlZUT2tXUEVpQkVEQXdPMzNISkxmMzkv Y25LeXpFQWtMcXJ4NTMvVkhqeDRrRkxhMnRxYW1abEpDTW5Nek5TN0tibXVydTdhYTY4ZFBY cjA0NDgvcmh5dWI3Lzl0cUtpd21HT2o4YWFucHljdkdMRml2VDA5SnljbkczYnRobFVvaHhr eHRtelo2dXFxbTY2NmFhWTl6bGVLRWZtc2NjZSs4VXZmcUhjcURkdGpPdGhyRjY5bXQyQTR4 aFVVMEtVSUhsUlVwNTNraE5TaVhWNWVuSnlNbHRZRHdRQ1RPV0o0czQ5b20rU1FBVk5EK3ZJ a1pXVmRlYk1HZXJXUEQwUUNHemR1cldvcUloU21wK2Y3L2Y3UTZHUXorY3JLQ2d3cm1ydjNy MVRwa3hocnc4ZVBKaWJtN3RpeFlxQmdRRXp1aDB2akRVOU16UFQ1L1AxOVBTMHRMUVlyL1lx QjVuVDNkMmRtcG9hdzk3R0YrWElzTE5TYzUxZE9XM0Mxa01wN2V2cnk4bkpNZHYyeEhxVVUw S1VJRWxSVXAxMzhoT1NZKzU2K3RkZmYvM0xYLzZTK1VWbzV1bXFaOUVrZ2RjVzlyV1MrKysv Lzhrbm53eUZRazgrK1NSTExoeU1jaEFXTFZyVTJka1pDb1hxNit2Wm44UGp4bzN6Ky8wOVBU MjdkdTNTVzArbmxBNE9EaDQ5ZXJTa3BJVDV4dFRVMUZSVVZMQWxNb2Rock9uMzNuc3ZQNFgw VGp4eGtCay8vUEREcWxXcktpb3FZdC9wT0dHY3JsRmgya2pXVTFkWE4zdjI3RmgxMGc2SVUw S1VJQmxSRXM4N21RbXB3a1JOVDBwS21qaHg0dTkrOXp2bTFibHYzNzZDZ29MazVPU0NnZ0sr bnE1NkZrMFN5SlZRT1UwL2NlTEVyRm16MkMveW5aMmRNZ09SaUlpRFUxdGJtNXVibTVLU1Vs UlU1UGY3S2FWMWRYWHNUNStwVTZmVzE5ZnpIY1Y2c3JPemx5NWRHZ3FGeEpvdlhyeG9lWEN4 UjNNdXFiWWNQMzU4MXF4WktTa3BIbytub2FHQjc2aXNSeHhrdHZ1b1VhTnV2LzMyenovLzNQ TElZbzg0TXNxUGxHV1UwNGJxVEMxVlBiTm16WkpjUmtnVXhDa2hTcENtS0JrUDE4V0xGelVu cERGbVhjc0lBQURBZWhMam5pTUQ4QVVEQUFDY2hOZDBBQUFBSEdnNkFBQTRCK3MwWFdaVkJD c25BQUFRRGRiOVJocERUWWYweXlCemRQUThLSlMySG01QXhvdERMQ1BqcFpQUWlHWWpNa1pB WWhtSC9kWWxoaVBPQkwyQk1qNnpZdUs4Tkh4Tlg3SkgvWUNtMnhqanNkTDBvRkRaZXJnQlNT OE9WUmtaTDUyRVJqUWJrVEVDMGl2anNCbWxERWVjQ1pxREVQYk1pb256a2xtYWZ1alFvWmt6 WnlZbkp4UEYxYXdxbjVhalI0L2VmUFBOcWFtcDA2Wk40LzUybE5Lelo4L2VkdHR0bXpkdnBq b3VNYXJ2U2JHZVdiTm1zZithNkx5N0c0YUw4WWtrZWxDSXRoNXVRTWFMUXl3ajQ2V1QwQmlZ amNnWUFhbktPR3hHS2NNeG1BbDhFR1RPckpnNEw1bWw2U1VsSmV2V3JlTjNJbEF0bjVieTh2 TFhYMzg5RkFydDJyVnIyclJwckV4SFIwZFpXUmszOEJMdlBxWEM1QkRyMmJwMUt6TUZLeTh2 Mzdselo5aTRISXp4aVNSNlVJaTJIbTVBeG90RExDUGpwWlBRNkptTnlCZ0JpV1VjTnFPVTRl ak5CT1VneUp4Wk1YRmVNa3ZUVTFKUzJPMmp5bjFWUGkwcEtTazg0MmJ1TG9TUTB0TFM3T3pz OXZaMlZsSjBpYUhDb0lqMTlQWDFYWGZkZGR1MmJTc29LSkQzcUhRa1lmTjBsUWVGZ2EySGc1 SHg0aERMRE10TEp4SFJOQnVSTVFMU0xPT3c2YVFNUjNNbXFBWmhXR2RXTk01TFptbDZjWEh4 dW5YcmVucDZsUHVxWGxkVVZEUTJOblozZHl1M256bHpac2VPSGJtNXVlenZYTTA4ZmVUSWtV cEhVN0VlU3Vuenp6K2ZucDZ1WjhickhveG5qNEVIaGNQT1FHTmt2RGpFTXBKZU9vbUxhRFlp WXdTa1Y4WmhNMG9aampnVERBYktlQnlpZDE0eVM5TS8vdmpqMHRKUzl0VWtSc0plSHp0MjdQ YmJiMDlMUytOZlhMeE1UVTNOckZtemdzR2c2QkpES1YyMmJCbmJpNzBWNjZHVS92M3ZmOC9L eXJMK1h5elpCM0lsZktPeWpJRXhqc1BPUUdOa3ZEakVNcHBlT2s1Q05CdFJUU3BtQktRYUtM R001bFJNWE1Sd3hKbWdPVkI4ZDgzWGZLOG9uWmVjNmZjeU1ERHdsNy84WmRteVpmSHVDQUFB V0lvejd5TWxoSlNWbGJIVkd3QUFjQS9PMUhRQUFIQW4wSFFBQUhBTzhIc0JBQURua0pCK0ww QWVHYjhJMGNsRXh2L0VrY2hNYVF3WFEyYXNSQU1UY1l1ckNPdjNvdktOaVdDNGhxM3BRMTcx QTVwdVp5UU5PbFJPSmpMK0p3N0dlQjVpdUpRWWo1Vm9ZQ0p1Y1E5aC9WNUUzNWdJaHNzc1RU ZlA3NFU3QnpRM056dlNaTU1rRFB3aVJDY1RHZjhUQnhOV3B6QmNuTEJqcFRJd01iQTBjVFl5 ZmkraWIwd0V3MldXcHB2bjk3SjI3ZHI1OCtkVFN1Zk5tN2R1M1RxWklJR3hYNFRvWkNMamYr SmdqSFVLdzZYRWVLeEVBeE05U3hQSEkrUDNJdnJHUkRCY1ptbTZlWDR2NTg2ZHk4akkrUExM THpNeU1yNzc3anVaSUYxT1dMOEkwY2xFeHYvRXdZVE5QVEZjSE1uMVVxV0JpZDRXWnlQajky TGdJQ1EvWEdacHVxbCtMNVdWbFRmY2NBTnpYZ1RHeVBoRmlFNG1NdjRuRHNaWXB6QmNTc0px dXNyQVJIT0xxekFZTVUwSG9lRU9sMW1hYnFyZlMzTnpNeUdFT2FRRFkxUlhLR2thZEloT0pn WStNTTVHODRJdURKY21NbVBGUGhJTlRKUmIzSWFvaEJ3OTM1aGhEWmN6L1Y0QUFNQ2Q0RDVT QUFCd0R0QjBBQUJ3RHRCMEFBQndEbVpwT2hiWkFRREFlc3o2alJTYWJoUGc5eklzWkg3Mngz QXhaS1pXUTBQRGpCa3pSbzRjV1Y1ZXp1NFZENFZDanp6eUNMdEYzc0VxSVU0a3BXRHlmKzZx aWRJVEpvS3BOZnhyR1R2VUQyaTZuWUhmU3dRWXoxNE1GME5tYWxWV1ZuWjBkSVJDb2UzYnQw K2NPSkZTV2xWVlZWWlcxdEhSNFlaLy9xNDVrWllzV2ZMa2swL3E3YUx5aElsZ2FwbXI2VXJu RnRIZFplM2F0UjZQaDNuQzREdkFiT0QzSW8veGJNUndxVENZV294Z01GaGZYejk5K25SSzZl VEprOTk5OTEwTGV4ZFB4SW4wL2ZmZloyWm1kblYxYVpZWFBXRWltRm9tYXJyS3VVVjBkeGt6 Wm96WDYrM282RkRlYmdyTUFINHZ3OEpZMHpGY1NveW5GcjI4NXBDVmxYWHc0RUZLYVhKeThv b1ZLOUxUMDNOeWNyWnQyMlpoVCtPQU9KRldyMTY5WU1FQ3ZmS2lKMHdFVTh0RVRWYzV0NGp1 TG0rLy9mWTk5OXd6YmRxMHNXUEhQdlBNTXpMZEJSRUF2NWZoRWpaUHgzQXh3azR0UmlBUTJM cDFhMUZSRWFVME16UFQ1L1AxOVBTMHRMUVlMeXM3QU5WRTZ1dnJ5OG5KWWVaY21vaWVNQkZN TFJNMVhlWGNJcnE3TUFZR0J2YnUzWnVlbmk3VFhUQmM0UGNTQWNhYWp1Rml5RXl0UllzV2RY WjJoa0toK3ZwNlpoVjc3NzMzY2sxMy9QY2ZFVzc5bnoxNzlyQjJqR0JxbWY0YktYZHUwWFIz SVlRd2M0T05HemZLZEJjTUY5VVZTdkI3TVVZMVhIeWpzZ3lHaXlFenRXcHJhM056YzFOU1Vv cUtpdngrUDZYMCtQSGpzMmJOU2tsSjhYZzhEUTBOOGVtNitXaE9wRm16WnFtV20vU3lCNzQ5 Z3FrRnZ4Y0FBSEFPdUk4VUFBQ2NBelFkQUFDY0F6UWRBQUNjZzlXYXJseDh4MEk4QUFERWxu aitSZ3BOanptaW1VWkRRME5lWGw1eWNuSmVYdDcyN2RzMTkycG9hUEI0UE95MzllUEhqMnZX NHhKa1BFekV3WEdEMzRzWXRWSUI5SzQwRjZlZnpJUjBBT0k1SlROSlltSWxOR3hOcnlDMXFn YzAzVDZJWmhvWkdSbTdkdTBLaFVKK3Y1Ly9oME1WV1ZsWkxTMHRQVDA5UHAvdjV6Ly91V1k5 TGtIR3cwUWNIRGY0dlJoTUNRTURFM0g2eVV4SUJ5Q2VVektUSkNaV1FpWnFPaUZrK2ZMbDZl bnBaV1ZsZkl1NDltTHNDYU5aRDlCRE5OTW9MUzF0Ym03dTZlblp2WHYzekprek5mZkt5c3Jh czJjUG0zL3N4aEJYbVhKb1l1QmhJZzZPRy94ZTlLYUVzWUdKT1Axa0pxUURFTThwbVVrU0V5 c2hjelg5aFJkZUNBUUNEejMwa0hLajhuVllUeGk5ZW9BbW9wbEdhMnRyWm1ZbUlTUXpNMVB2 cHVTNnVycHJyNzEyOU9qUmp6LytPUE9VY0pVcGg0aXhoNGs0T0c3d2U5R2JFc1lHSnVMMGs1 bVFEa0E4cDJRbVNVeXNoTXpWZERITlVXbDZXRThZdlhxQUpxS1pSbjUrdnQvdkQ0VkNQcCt2 b0tEQWVQZTllL2RPbVRKRnN4NzNFTmJEUkJ3Y04vaTlhRTZKc0FZbTR2UWIxb1IwQVB5Y2tw a2tNYkVTTWxmVGpUY1NPVThZTEx2TEk1cHBqQnMzenUvMzkvVDA3TnExeTJENWNuQnc4T2pS b3lVbEpWVlZWWnIxdUFRWkR4TnhjTnpnOTZJNUpjSWFtSWpUVDNKQ09nRFZPU1V6U1dKaUpX U2Rwb3VYeXZBQ0JwNHdZajNBQU5GTW82NnV6dVB4TUZPZCt2cDZWa3p6MEdSblp5OWR1alFV Q21uVzR4SlVzMVRUdzBRY0hEZjR2V2hPaWJBR0p1TDAwNXlRemtNOHB6UW5pV3E0WW1JbEJM OFhBQUJ3RHJpUEZBQUFuQU0wSFFBQW5BTTBIUUFBbklOMW1qNnN5MlA0UjhicjlWaktCd0FB SmRiOVJocXgva0xUbzBIR3VRVitMeHlaV2ExbndlSDFlaDA4VnVLd05EUTB6Smd4WStUSWtl WGw1Znl1YnhYaVdEblM3MFcwQ1JJbmt1U1pxQnFjQ0s1REdiYW0xNUphMVFPYWJtZGtuRnZn OThLUm1WR2FGaHlmZlBJSk8xM043Vis4VVFaWVdWblowZEVSQ29XMmI5OCtjZUpFemZMaVdE blM3MFcwQ1JKbmdzdzVwVGM0dHREMHRXdlhlanllNU9Say9pVkRDSG41NVpmSGp4K2ZtWm01 YWRNbVhxRnlkejIvRjJYTnJhMnRCUVVGYVdscFZWVlY3Q094TGNDUmNXNkIzd3VIRUpLUmta R2VudjdUbi83MHhJa1RtbVZFQzQ1UUtGUlVWUFRhYTY4NWZ2cUpBUWFEd2ZyNit1blRwMnVX RjhmSzJYNHYzQ1pJbkVneTU1VGU0TmhDMDhlTUdlUDFlanM2T25wNmV2aSs2OWV2RHdhRFRV MU55bHNUbGJ2citiMG9hNTR4WTBaTlRVMHdHSHpsbFZmWVIySmJnQ1BqM0FLL0Z4Vm56NTZ0 cXFxNjZhYWJORDhWTFRnZWUrd3hkbytmMnpTZFpWRlpXVmtIRHg3VUxDK09sWVA5WGtTYklP VkVram1uOUFiSEZwcis5dHR2MzNQUFBkT21UUnM3ZHV3enp6ekQ5dTNyNnhPN3FIeXQ1L2Vp ckRrbEpTVVlERkpLQTRFQSswaHNDM0NHNWR3Q3Z4ZE9kM2QzYW1xcTVrZWlCY2VJRVNPRysv TlNnaUpHRndnRXRtN2RXbFJVcEZsZUhDdW4rcjNvMlFUeGlTUnpUdWtOamkwMG5URXdNTEIz Nzk3MDlIU3FyK1BLMTVwK0w1TW1UVkptQVVWRlJTeFByNjZ1VnU2cmJBdHdKSjFiNFBlaTVJ Y2ZmbGkxYWxWRlJZWG1wd1lXSE00V2RIcGxnSXNXTGVyczdBeUZRdlgxOVd6SlRrUWNLMGY2 dmVqWkJDa25rc3c1cFRjNHR0QjBsckF3VjRlTkd6ZFNMUjBuVjBJcDFmUjcrZXRmLzVxZW5z N2Y3dCsvUHo4L1B5MHRiZm55NWNwNmxHMEJqcVpOaCtaZjBQQjdvWmVIWXRTb1ViZmZmdnZu bjMvT055ckxHRmh3T0ZqVHhiTzF0clkyTnpjM0pTV2xxS2pJNy9mellzcTl4TEZ5cE4rTGFu QXVYcndvVGlTWk0xRWNISEhZd3dLL0Z3QUFjQTY0anhRQUFKd0ROQjBBQUp3RE5CMEFBSnlE M1RVZGkvVUFBQ0NQM1g4amhhWkhpZWhFSVNLYWN1aFptamdlbVNtTjRXTElqSlZvSmVSSXZ4 ZDVqRTJCeE1FUkJ6QXN3OWIwamlIMUE1cHVaMFFuQ3MweUtsTU9UVXNUOTJBODZ6QmNTb3pI U3JRU2NxVGZpeVJoVFlIRXdSRUhNQ3htYWJxbTMwdFZWVlZhV3RyMDZkTmJXMXNwcFI5KytH RmhZV0ZLU2twaFlTRzdYUC9Rb1VNelo4NWtlL0VXS2FWbno1Njk3YmJiTm0vZUxCTVMwSVE3 VVlnZmlhWWM0aFpYRVZhbk1GeWNzR09sc2hKeXR0K0xBVEttUU9MZ2lBTVlGck0wWGRQdnBi cTZPaGdNMXRUVUZCY1hVMG9MQ2dwZWZmVlZka2RvWVdFaHBiU2twR1RkdW5Yc3RwY2ZXK3pv S0NzcmEybHBrWWtIYUNJNlVTZ1JUVG5FTGE3Q1dLY3dYRXFNeDBxMEVuS3czNHN4TXFaQTR1 Q0lBeGdXc3pSZDArK0YrYlFFZzBGbWdKQ2NuTXlkVzFKU1VpaWxLU2twZ1VCQTFXSnBhV2wy ZG5aN2U3dE1QRUJFejRtQ0k1cHlpRnRjUmRqY0U4UEZrVndkNVZaQ1R2VjdDWXVNS1pEQjRQ QUJESXU1NitrcXZ4ZVdsZGZVMU15WU1ZTnE1ZW5GeGNYcjFxMVQyaXNTUXM2Y09iTmp4NDdj M0Z6MjV5MFlGbnBPRkVwRVV3NERTeE0zWUt4VEdDNGxZVFZkWlNYa1NMK1hZV0V3WXBxRG94 ckFzSmlsNmV5N1NPWDN3dGJUOC9QejkrL2ZUeW5kdDI5ZlFVRkJjbkp5UVVFQkU1MlBQLzY0 dExTVWZhR3A0cStwcVprMWF4Ykw2NEU4cWl1VUxsNjhTQ1ZNT1F3c1RaeU41Z1ZkR0M1TlpN YUtmYVMwRW5LazM4dXdVQTZSYXJqMC9GNlVBeGlXQlBqZmRRQUFBQ1NKLy8rWUJnQUFFQ3Zz Zmg4cEFBQUFlYURwQUFEZ0hPeW82VmlsQVFDQXlERHhOMUpJc3gxb2FHaVlNV1BHeUpFank4 dkwzM3Z2UGMweU1ERGh3QjVISHBteDByTXJNYlk5Y1RCaC9WNVV3eVV6eUNxR3JlbER3Z09h Ym1jcUt5czdPanBDb2REMjdkc25UcHlvV1FZR0poelk0OGdqTTFhYWRpVmhiVStjU3RqQXhl R1NHV1FWWm1tNlpoWlBDRm0rZkhsNmVucFpXUm5WOG52aE84cDBIY2dUREFicjYrdW5UNSt1 K1NrTVRFUmdqeU9QOFZpcDdFcGtiRThjaVV6Z0J1NHVCb09zd3RJOG5SRHl3Z3N2QkFLQmh4 NTZpR3JkUjZxM0k0Z0c5aldabFpWMThPQkJ6UUl3TUZFQmV4eDVqTWRLdEN1UnNUMXhKREtC NjdtN0dBK3lDcXMxWGZrOUkvcTk2TzBJb2lRUUNHemR1cldvcUVqelV4aVlLSUU5amp4aHg0 ckQ3VXBrYkU4Y3liQUNWN3E3eUE4eXcwUk5Iemx5NUlrVEoxUzdLOThpVDdlQVJZc1dkWFoy aGtLaCt2cDZQYTlPR0pod1lJOGpqOHhZVVgyN0V0ZWU1c2FCcTRaTGNwQ1ZtS2pweTVZdFMw dExVNjJuS3d1SWZpOFJXQTRBWTJwcmEzTnpjMU5TVW9xS2l2eCtQOXVvR2xzWW1IQlVNeEQy T0FiSWpCWDdTTk91eExVbnVJRWtpc09sT2NqRzJQMS8xd0VBQUpESGp2Y2NBUUFBaUF4b09n QUFPQWRvT2dBQU9BZTdhem9XNndFQVFCNjcrNzFBMDZORTVuZHNHSmh3TUZ6eXlJeFZRME5E WGw1ZWNuSnlYbDdlOXUzYkpmZHlBR0tZa3NPbDhudUpZTGlHcmVsZUFXaTYvVEVlUmhpWXFN Qnd5V004VmhrWkdidDI3UXFGUW42L1gvbmZSMTF5WG90aEdnZXVhWThUZGk4VlptbTZtTVVU NGFyTXNyS3lscFlXU21semMvUE1tVE9wbGdNTUszbjI3Tm5iYnJ0dDgrYk44b0VCSldGbkVn eE1sR0M0NURFZXE5TFMwdWJtNXA2ZW50MjdkN056WEdZdnh4Q0JwbXY2dmRoQzA4VitpSnEr ZHUzYStmUG5VMHJuelp1M2J0MDZxblZuS1NHa282T0RxeitJRE9NNUFRTVRGUmd1ZVl6SHFy VzFOVE16a3hDU21abloxdFltdVpkakdLNm02L205MkYzVCsvcjYyT3R6NTg1bFpHUjgrZVdY R1JrWjMzMzNIZFZ5Z0NHRWxKYVdabWRudDdlM3kwY0ZWSVRORG1CZ29nVERKWS94V09YbjUv djkvbEFvNVBQNUNnb0tKUGR5RE1QVmRJN1M3MFYrTDRhSm1xN3llNWt3WWNMdTNidTd1N3Mz Yk5qQWQ2bXNyTHpoaGh2bXpadkgzbXJtNldmT25ObXhZMGR1Ymk3Ny9Nd0ZwZ0FBQ0haSlJF RlU4eFpFZ1BHY2dJR0pDZ3lYUE1aak5XN2NPTC9mMzlQVHMydlhMcXluYTI1Um9XbVBZeGRO Vi9tOVZGZFhaMlJrakI4L2Z0MjZkWHhqYzNNeklhUzV1Wm05MVhTQVlSL1YxTlRNbWpXTFpm RkFIbklsZktPeURBeE1PQmd1ZVdUR3FxNnV6dVB4akJneFl1clVxZlgxOVhwN09ROHhUSm5o WWg4WitMM0lOQTIvRndBQWNBNTJ2K2NJQUFDQVBOQjBBQUJ3RHRCMEFBQndEdFpwT3BiZEFR REFiS3o3alJTYWJnRjZSOFRnOGlUcVlsTU9FZVdzenNySzBpeWo1KzVpUE1pSnpwWXRXNjY3 N3JyVTFOU1pNMmZ1M2J1WFV0clEwREJqeG95UkkwZVdsNWUvOTk1N21udUpFMG1zeHdHSVo1 RG8zQ0lUZUdTRHJHTDRtcjVCZUVEVGJZWnFxRC81NUpQczdHeUQ4WGU1S1ljbVM1WXNlZkxK SnpVLzBuUjNDVHZJaWM3Y3VYTVBIejdjM2QyOVpjc1dkbDlWWldWbFIwZEhLQlRhdm4zN3hJ a1REZlpWRG90WWp3TVF6eURSdVVVbThHZ0dtV09XcGlzMzhzc3pYMzc1NWZIangyZG1abTdh dEVtekRIdXhmUG55OVBUMHNySXlldmw3UGlVbHBiUzBGUFlBa2lnSE5oUUtGUlVWdmZiYWF3 Wnk0M0pURHBIdnYvOCtNek96cTZ0TDgxUFIzVVZta0IzRHlaTW5VMU5UZTN0NzJkdGdNRmhm WHo5OStuU0RYVFNIUlZWUFFpT2VRWHJPTFZRdThBZ0dtV09wcHE5ZnZ6NFlERFkxTmJFelFV L1RYM2poaFVBZzhOQkREL0ZQKy92NzkrM2JOMm5TSkptUWdISmdIM3ZzTVhabm80SGN1TnlV UTJUMTZ0VUxGaXpRKzFSMGQ1RVpaR2Z3N2JmZlZsUlVQUHJvbyt3dFg2UTZlUENnd1Y3aXNL anFTWFRFTTBqUHVVVW04TWdHbVdPNnBuTjNGMEpJWDErZjhsT3hETnVvL0FaYnYzNDl1dytO RUpLVWxDUVRFbEFlRVRaMHh1dmpMamZsVU5IWDE1ZVRrNlA4YmxNaHVydklETElET0hqd1lH NXU3b29WS3dZR0J2akdRQ0N3ZGV2V29xSWlneDFWWTZKWlQwS2pkd2JSSzUxYlpBS1BlSkE1 Wm1tNjZPNGladVdhRGpDcTJ0TFMwcHFhbW9MQm9NL25jL0RaRWx2Qy91V2t3dVdtSENycTZ1 cG16NTV0VU1EQTNjWEJJMVpUVTFOUlVjRWNPeGlMRmkzcTdPd01oVUwxOWZXcTVRVVZ5bUVS NjNFQW1tZVF5cmxGSnZCb0JwbGpscWFMN2k2aXBtczZ3S2hxZS9iWlp6TXlNakl5TWxhdlh1 M2dFeVpXa0N0UmZhVDVtcnJZbEVPVFdiTm1iZHUyVGJsRk5RSUc3aTRPSGl2VmxMaDQ4V0p0 YlcxdWJtNUtTa3BSVVpIZjcrZkZEUGJTckNjT3djUWF2VFBJd0xtRkJXNDhYSHFEYkF6OFhn QUF3RG5nUGxJQUFIQU8wSFFBQUhBTzBIUUFBSEFPMEhRQWJJM2RmcStLcGo5Mmk4V1JRTk1C MENCaTlZbTViQmxVR0gxYi9KNVlTdW1wVTZmMExHNWtHcFc1YmtLbXc1cWVKeXJ2RklQVytS WVpweFRSdWtmUHpNZTRMWm1yUmNTNHhMYkVlaUt3eDRHbUE2Q0JTelQ5NXB0dmZ1Kzk5eVpQ bmp4bHlwUjMzMzNYK01KODQwWmxPaU5UUnZROEViMVRaT3FYY1VvUnJYczB6WHdrWXpHT1Rv eExyeTFsUFJIWTQwRFRBZEJBODR3bFYxb1ByVjI3MXVQeEpDY244OXhLNWdKZlZYN0hucXVx cXRMUzBxWlBuOTdhMmtvcGJXMXRMU2dvU0V0THE2cXFVdGFzYkYxczYralJvemZmZkhOcWF1 cTBhZE40Wm1vc05Jc1dMVnE5ZXZYVXFWTTlIcythTldzV0wxNnNXWS9ZSDVrUkUrc2hoQ3hm dm56MDZORThVZ080NTRtQmQwcllQcWljVWxRRlJPc2VjWXRtdFpvYkpiOWlsWEdKYmVuVkky K1BBMDBIUUFPOTgxTnBQVFJtekJpdjE5dlIwZEhUMHhOMlI4MENYSytycTZ1RHdXQk5UVTF4 Y1RHbGRNYU1HVFUxTmNGZzhKVlhYbEdXVnhrZnFkb3FMeTkvL2ZYWFE2SFFybDI3cGsyYkpo UG02dFdyYjd6eHhubno1bFZXVnQ1NDQ0MXIxcXpSckVldlA2cTRWRjh6WWozS1NJM3ZkRmQ2 bnVoNXAyajJRZXlTZ1ZPS2FOMGpicEZzUzNPTGNWeDZiWW4xRE1zZUI1b09nQWJpZVNWYUQ3 Mzk5dHYzM0hQUHRHblR4bzRkKzh3enoranRxRmV6MGdvcEdBeFNTb1BCWUdwcUtxVTBKU1dG YlFrRUFxeU1wdkdScXEyVWxCUXVxWkxtU0R0MjdFaEtTbnJwcFpmKy9PYy9KeVVsN2R5NVU3 TWVzVDh5SXliV0kwYXFpWjR2aXRJN1JiSVB4azRwb25XUHVFVytyYkNIWGhXWFhsdXFlb1py andOTkIwQUQ4ZnpVc3g0YUdCall1M2R2ZW5vNmV6dHk1TWdUSjA0WTFLeHBoZlRxcTYreTdI WEdqQm1VMHFLaUlwWVhWMWRYc3pLYXJhdmFxcWlvYUd4czdPN3VsZy96MkxGamhKQURCdzU4 OU5GSGhCQW1BbUk5WW45RXhPMWlQY3BJMlY4a0lwcStLQ3J2RkQyVWZaQnhTaEd0ZXd6TWZN TEdhNnpwWWx4NmJTbnJpY0FlQjVvT2dBYmlTb0pvUGNRK1lpNGZHemR1WkRzdVc3WXNMUzNO NFBUV3RFSmk2K241K2ZuNzkrK25sTzdmdno4L1B6OHRMVzM1OHVWNnJZdHRIVHQyN1BiYmIy ZGIrRVpqb2VudDdSMHpaa3hQVDA4b0ZCb3paZ3h6VGhYckVmdWpPV0txTFdJOXlrajExdE5W STMveDRrWDJRdW1kRW5ZdlNxbU1IWTFvM2FOcDVxUGFTMnhMM0NJVGw5aFcySnBsN0hHZzZR REVHV1BaQldCWVFOTUJpRFBRZEJCRG9Pa0FBT0Fjb09rQUFPQWNvT2tBQU9BY29Pa0FBT0Fj b09rZ01XaHNiR3hxYXVydjcyOXFhbXBzYkpUY3hmaFR2UUtCUU1EbjgybVdOOWdMQURzQVRR ZUpRV05qNC92dnYvL1paNTk5OE1FSHNWSlZ2WG9PSFRva2ZnUXBCd2tCTkIwa0JvMk5qY2VP SGZQNy9jZU9IZVB5cW5yUjJOalkzdDd1OS91UEhqMnF0MUZWcDlqUUR6LzgwTnpjcktucGZy OS96NTQ5cDA2ZGltbGtBTVFTYURwSURCb2JHOCtkTzhlZitVYmxpOGJHeHUrKyt5NFFDTEQ3 QmpVM3F1b1VHL3I0NDQrUEh6K3UrZEhnNE9DcFU2ZDI3OTRkdTdBQWlESFFkSkFZTkRZMkRn NE92dlBPTzRPRGcxeHcvWDUvSUJEZ0tpOUt2TGhSVmFkbVEzcnI1b09EZzJmT25JR21BenNE VFFlSmdWSmgrZXVqUjQvNi9mNzI5dllJTkYwbDNPS240b3ZHeHNZOWUvWjg4ODAzc1F3TWdK Z0NUUWNBQU9jQVRRY0FBT2NBVFFjQUFPY0FUUWNBQU9jQVRRY0FBT2NBVFFjQUFPZndvNmEz dHJhK0FRQUFJUEVoRUhRQUFIQU0veC9PYmg1MWt3QkRHZ0FBQUFCSlJVNUVya0pnZ2c9PSIg Lz48L3A+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZC QTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFyZ2luLWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1s O25nbGljaGUgTmFjaHJpY2h0LS0tLS08YnIgLz48c3Ryb25nPkFuOjwvc3Ryb25nPglLb25y YWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZC53aWxrQG9yYWNsZS5jb20mZ3Q7OyA8YnIg Lz48c3Ryb25nPkNDOjwvc3Ryb25nPglTYW5kZXIgRWlrZWxlbmJvb20gJmx0O2xpbnV4QGVp a2VsZW5ib29tLml0Jmd0OzsgeGVuLWRldmVsICZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291 cmNlLmNvbSZndDs7IEphbiBCZXVsaWNoICZsdDtqYmV1bGljaEBzdXNlLmNvbSZndDs7IEtv bnJhZCBSemVzenV0ZWsgV2lsayAmbHQ7a29ucmFkQGRhcm5vay5vcmcmZ3Q7OyA8YnIgLz48 c3Ryb25nPlZvbjo8L3N0cm9uZz4JQ2Fyc3RlbiBTY2hpZXJzICZsdDtjYXJzdGVuQHNjaGll cnMuZGUmZ3Q7PGJyIC8+PHN0cm9uZz5HZXNlbmRldDo8L3N0cm9uZz4JRGkgMjguMDIuMjAx MiAxNTozOTxiciAvPjxzdHJvbmc+QmV0cmVmZjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxd IExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTxiciAvPjxzdHJv bmc+QW5sYWdlOjwvc3Ryb25nPglpbmxpbmUudHh0PGJyIC8+PHN0eWxlIHR5cGU9InRleHQv Y3NzIj4uYm9keWNsYXNzIHsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgfTwvc3R5bGU+ICAg ICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gICAgICAgLmJvZHljbGFzcyAg ICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFsLCBWZXJkYW5hLCBTYW5zLVNlcmlm ICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTogMTJweDsgICAgICAgICBwYWRkaW5n OiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2luOiAwcHg7ICAgICAgICAgYm9yZGVy LXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQtY29sb3I6ICNmZmZmZmY7ICAgICAg IH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAgICAgbWFyZ2luLXRvcDogMHB4OyAg ICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAgfSAgIDwvc3R5bGU+ICA8ZGl2Pjxw PldlbGwgbGV0IG1lIGNoZWNrIGZvciBhIGxvbmdlciBwZXJpb2Qgb2YgdGltZSwgYW5kIGVz cGVjaWFsbHksIHdoZXRoZXIgdGhlIERvbVUgaXMgc3RpbGw8L3A+PHA+d29ya2luZyAoY2Fu IGRvIHRoYXQgb25seSBmcm9tIGF0IGhvbWUpLCBidXQgbG9hZCBsb29rcyBwcmV0dHkgd2Vs bCBhZnRlciBhcHBseWluZyB0aGU8L3A+PHA+cGF0Y2ggdG8gMy4yLjggOi1ELjwvcD48cD4m bmJzcDs8L3A+PHA+QlIsPC9wPjxwPkNhcnN0ZW4uPGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNvbGlkICMzMjVGQkE7IHBhZGRpbmctbGVm dDogNXB4O21hcmdpbi1sZWZ0OjVweDsiPi0tLS0tVXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hy aWNodC0tLS0tPGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4JSmFuIEJldWxpY2ggJmx0O0pC ZXVsaWNoQHN1c2UuY29tJmd0OzsgPGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4JS29ucmFk IFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IHhlbi1kZXZlbCAm bHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7OyBDYXJzdGVuIFNjaGllcnMg Jmx0O2NhcnN0ZW5Ac2NoaWVycy5kZSZndDs7IFNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGlu dXhAZWlrZWxlbmJvb20uaXQmZ3Q7OyA8YnIgLz48c3Ryb25nPlZvbjo8L3N0cm9uZz4JS29u cmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0OzxiciAv PjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CUZyIDE3LjAyLjIwMTIgMTY6MTg8YnIgLz48 c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz5PbiBUaHUsIEZlYiAxNiwgMjAx MiBhdCAwODo1Njo1M0FNICswMDAwLCBKYW4gQmV1bGljaCB3cm90ZTo8YnIgLz4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBPbiAxNS4wMi4xMiBhdCAyMDoyOCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxr ICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0OyB3cm90ZTo8YnIgLz4mZ3Q7ICZndDtA QCAtMTU1MCw3ICsxNTUyLDExIEBAIHN0YXRpYyB2b2lkICpfX3ZtYWxsb2NfYXJlYV9ub2Rl KHN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEsIGdmcF90IGdmcF9tYXNrLDxiciAvPiZndDsgJmd0 OyAJc3RydWN0IHBhZ2UgKipwYWdlczs8YnIgLz4mZ3Q7ICZndDsgCXVuc2lnbmVkIGludCBu cl9wYWdlcywgYXJyYXlfc2l6ZSwgaTs8YnIgLz4mZ3Q7ICZndDsgCWdmcF90IG5lc3RlZF9n ZnAgPSAoZ2ZwX21hc2sgJmFtcDsgR0ZQX1JFQ0xBSU1fTUFTSykgfCBfX0dGUF9aRVJPOzxi ciAvPiZndDsgJmd0Oy08YnIgLz4mZ3Q7ICZndDsrCWdmcF90IGRtYV9tYXNrID0gZ2ZwX21h c2sgJmFtcDsgKF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKTs8YnIgLz4mZ3Q7ICZndDsrCWlm ICh4ZW5fcHZfZG9tYWluKCkpIHs8YnIgLz4mZ3Q7ICZndDsrCQlpZiAoZG1hX21hc2sgPT0g KF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKSk8YnIgLz4mZ3Q7IDxiciAvPiZndDsgSSBkaWRu JiMzOTt0IHNwb3Qgd2hlcmUgeW91IGZvcmNlIHRoaXMgbm9ybWFsbHkgaW52YWxpZCBjb21i aW5hdGlvbiwgd2l0aG91dDxiciAvPiZndDsgd2hpY2ggdGhlIGNoYW5nZSB3b24mIzM5O3Qg YWZmZWN0IHZtYWxsb2MzMigpIGluIGEgMzItYml0IGtlcm5lbC48YnIgLz4mZ3Q7IDxiciAv PiZndDsgJmd0OysJCQlnZnBfbWFzayAmYW1wOz0gKF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMy KTs8YnIgLz4mZ3Q7IDxiciAvPiZndDsgCQkJZ2ZwX21hc2sgJmFtcDs9IH4oX19HRlBfRE1B IHwgX19HRlBfRE1BMzIpOzxiciAvPiZndDsgPGJyIC8+Jmd0OyBKYW48YnIgLz48YnIgLz5E dWghPGJyIC8+R29vZCBleWVzLiBUaGFua3MgZm9yIGNhdGNoaW5nIHRoYXQuPGJyIC8+PGJy IC8+Jmd0OyA8YnIgLz4mZ3Q7ICZndDsrCX08YnIgLz4mZ3Q7ICZndDsgCW5yX3BhZ2VzID0g KGFyZWEtJmd0O3NpemUgLSBQQUdFX1NJWkUpICZndDsmZ3Q7IFBBR0VfU0hJRlQ7PGJyIC8+ Jmd0OyAmZ3Q7IAlhcnJheV9zaXplID0gKG5yX3BhZ2VzICogc2l6ZW9mKHN0cnVjdCBwYWdl ICopKTs8YnIgLz4mZ3Q7ICZndDsgPGJyIC8+Jmd0OyA8YnIgLz48YnIgLz5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciAvPlhlbi1kZXZlbCBt YWlsaW5nIGxpc3Q8YnIgLz5YZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTxiciAvPmh0 dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbDxiciAvPjwvYmxvY2txdW90ZT48 L2Rpdj4gICA8L2Jsb2NrcXVvdGU+PC9kaXY+ICAgPC9ibG9ja3F1b3RlPjxwPiZuYnNwOzwv cD4gPGhyIHNpemU9IjEiIG5vc2hhZGU9Im5vc2hhZGUiIC8+RS1NYWlsIGlzdCB2aXJlbmZy ZWkuPGJyIC8+IFZvbiBBVkcgJnV1bWw7YmVycHImdXVtbDtmdCAtIDxhIHRpdGxlPSJEaWVz ZXIgZXh0ZXJuZSBMaW5rIHdpcmQgaW4gZWluZW0gbmV1ZW4gRmVuc3RlciBnZSZvdW1sO2Zm bmV0IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cDovL3d3dy5hdmcuZGUiPnd3dy5hdmcu ZGU8L2E+PGJyIC8+IFZlcnNpb246IDIwMTIuMC4yMTI3IC8gVmlyZW5kYXRlbmJhbms6IDI0 MTEvNDkzMiAtIEF1c2dhYmVkYXR1bTogMTIuMDQuMjAxMjwvZGl2PiAgIDwvYmxvY2txdW90 ZT4KPC9ib2R5Pgo8L2h0bWw+ --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d-- --===============1809693732979586600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1809693732979586600==-- From xen-devel-bounces@lists.xen.org Fri May 11 09:38:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 09:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmId-0001tt-Da; Fri, 11 May 2012 09:38:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmIb-0001tj-Ar for xen-devel@lists.xensource.com; Fri, 11 May 2012 09:38:10 +0000 Received: from [85.158.139.83:55555] by server-9.bemta-5.messagelabs.com id 88/06-09826-00EDCAF4; Fri, 11 May 2012 09:38:08 +0000 X-Env-Sender: carsten@schiers.de X-Msg-Ref: server-14.tower-182.messagelabs.com!1336729082!23566658!1 X-Originating-IP: [194.117.254.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, FROM_EXCESS_QP,HTML_MESSAGE X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20047 invoked from network); 11 May 2012 09:38:03 -0000 Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 09:38:03 -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=5Pko0iUfb3F2TVDcLJq8K6AchjHgz vNIYOBOuyJVHSE=; b=rzSg+gfZM9p9WI0ZsnRwR4se6VCB4JwXzP7B1s9ihU1Ul h4VD9qIUhzQEL56ioe88N9d7OoCK+0w9ErUruet824QGigXsIO4d75X0C1L9HZd3 EKl5QyHPwnUU/cDKo7jwF+HQHMOgYvlLfhjAFZjtOtR3mRw68w4LVDGXhNMnDk= Received: (qmail 30756 invoked from network); 11 May 2012 11:37:53 +0200 Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.27.13) by mail.zeus06.de with ESMTPA; 11 May 2012 11:37:53 +0200 Received: from localhost (localhost [127.0.0.1]) by uhura.zz (Postfix) with ESMTP id 97A8F2C575; Fri, 11 May 2012 11:39:20 +0200 (CEST) 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 o908giwQewg3; Fri, 11 May 2012 11:39:09 +0200 (CEST) Received: from uhura.space.zz (localhost [127.0.0.1]) by uhura.zz (Postfix) with ESMTP id 0AE9E2C574; Fri, 11 May 2012 11:39:09 +0200 (CEST) From: =?utf-8?Q?Carsten_Schiers?= To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= Date: Fri, 11 May 2012 11:39:08 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.0.6-32752 Message-Id: Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= , =?utf-8?Q?xen-devel?= , =?utf-8?Q?Jan_Beulich?= , =?utf-8?Q?Sander_Eikelenboom?= Subject: Re: [Xen-devel] Load increase after memory upgrade (part2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809693732979586600==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --===============1809693732979586600== Content-Type: multipart/alternative; boundary="=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d" This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Konrad,=0D=0A=0D=0A=C2=A0=0D=0Adon't want to be pushy, as I have no re= al issue. I simply use the Xenified kernel or take the double load.=20=0D= =0A=0D=0ABut I think this mistery is still open. My last status was that = the latest patch you produced resulted in a BUG,=20=0D=0A=0D=0Aso we stil= l have not checked whether our theory is correct.=0D=0A=0D=0A=C2=A0=0D=0A= BR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachrich= t-----=0D=0AVon:Carsten Schiers =0D=0AGesendet:Mi 29.= 02.2012 14:01=0D=0ABetreff:Re: [Xen-devel] Load increase after memory upg= rade (part2)=0D=0AAnlage:debug.log, inline.txt=0D=0AAn:Konrad Rzeszutek W= ilk ;=20=0D=0ACC:Sander Eikelenboom ; xen-devel ; Jan Beulich ; Konrad Rzeszutek Wilk ;=20=0D=0A=20=0D=0A= =0D=0AI am very sorry. I accidently started the DomU with the wrong confi= g file, thus it's clear why there is no difference=0D=0A=0D=0Abetween the= two. And unfortunately, the DomU with the correct config file is having = a BUG:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=0A [ 14.674883] BUG: unable to han= dle kernel paging request at ffffc7fffffff000 [ 14.674910] IP: [] swiotlb_bounce+0x2e/0x31 [ 14.674930] PGD 0 [ 14.674940= ] Oops: 0002 [#1] SMP [ 14.674952] CPU 0 [ 14.674957] Modules linke= d in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc tda10023= budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobuf_dma_sg = videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd ttpci_ee= prom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache xen_netfro= nt xen_blkfront [ 14.675057] [ 14.675065] Pid: 0, comm: swapper/0 No= t tainted 3.2.8-amd64 #1 [ 14.675079] RIP: e030:[] = [] swiotlb_bounce+0x2e/0x31 [ 14.675097] RSP: e02b:f= fff880013fabe58 EFLAGS: 00010202 [ 14.675106] RAX: ffff880012800000 RB= X: 0000000000000001 RCX: 0000000000001000 [ 14.675116] RDX: 00000000000= 01000 RSI: ffff880012800000 RDI: ffffc7fffffff000 [ 14.675126] RBP: 000= 0000000000002 R08: ffffc7fffffff000 R09: ffff880013f98000 [ 14.675137] = R10: 0000000000000001 R11: ffff880003376000 R12: ffff8800032c5090 [ 14.= 675147] R13: 0000000000000149 R14: ffff8800033e0000 R15: ffffffff81601fd8= [ 14.675163] FS: 00007f3ff9893700(0000) GS:ffff880013fa8000(0000) knl= GS:0000000000000000 [ 14.675175] CS: e033 DS: 0000 ES: 0000 CR0: 00000= 0008005003b [ 14.675184] CR2: ffffc7fffffff000 CR3: 0000000012683000 CR= 4: 0000000000000660 [ 14.675195] DR0: 0000000000000000 DR1: 00000000000= 00000 DR2: 0000000000000000 [ 14.675205] DR3: 0000000000000000 DR6: 000= 00000ffff0ff0 DR7: 0000000000000400 [ 14.675216] Process swapper/0 (pid= : 0, threadinfo ffffffff81600000, task ffffffff8160d020) [ 14.675227] S= tack: [ 14.675232] ffffffff81211826 ffff880002eda000 0000000000000000 = ffffc90000408000 [ 14.675251] 00000000000b0150 0000000000000006 ffffff= ffa013ec4a ffffffff810946cd [ 14.675270] ffffffff81099203 ffff88000337= 6000 0000000000000000 ffff880002eda4b0 [ 14.675289] Call Trace: [ 14.= 675295] [ 14.675307] [] =3F xen_swiotlb_sync= _sg_for_cpu+0x2e/0x47 [ 14.675322] [] =3F vpeirq+0x7= f/0x198 [budget_core] [ 14.675337] [] =3F handle_irq= _event_percpu+0x166/0x184 [ 14.675350] [] =3F __rcu_= process_callbacks+0x71/0x2f8 [ 14.675364] [] =3F tas= klet_action+0x76/0xc5 [ 14.675376] [] =3F eoi_pirq+0= x5b/0x77 [ 14.675388] [] =3F __do_softirq+0xc4/0x1a0= [ 14.675400] [] =3F __xen_evtchn_do_upcall+0x1c7/0x= 205 [ 14.675412] [] =3F call_softirq+0x1c/0x30 [ 1= 4.675425] [] =3F do_softirq+0x3f/0x79 [ 14.675436] = [] =3F irq_exit+0x44/0xb5 [ 14.675452] [] =3F xen_evtchn_do_upcall+0x27/0x32 [ 14.675464] [] =3F xen_do_hypervisor_callback+0x1e/0x30 [ 14.675473] =20=0D= =0A=0D=0A=C2=A0=0D=0AComplete log is attached.=0D=0A=0D=0A=C2=A0=0D=0ABR,= Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn= :Konrad Rzeszutek Wilk ;=20=0D=0ACC:Konrad Rzeszu= tek Wilk ; xen-devel ; = Jan Beulich ; Sander Eikelenboom ;=20=0D=0AVon:Carsten Schiers =0D=0AGesendet:Mi 29.0= 2.2012 13:16=0D=0ABetreff:Re: [Xen-devel] Load increase after memory upgr= ade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0AGreat news: it wor= ks and load is back to normal. In the attached graph you can see the peak= =0D=0A=0D=0Ain blue (compilation of the patched 3.2.8 Kernel) and then af= ter 16.00 the going life of the=0D=0A=0D=0Avideo DomU. We are below an av= aerage of 7% usage (figures are in Permille).=0D=0A=0D=0A=0D=0AThanks so = much. Is that already "the final patch"=3F=0D=0A=0D=0A=C2=A0=0D=0ABR, Car= sten.=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Na= chricht-----=0D=0AAn:Konrad Rzeszutek Wilk ;=20=0D= =0ACC:Sander Eikelenboom ; xen-devel ; Jan Beulich ; Konrad Rzeszutek Wilk= ;=20=0D=0AVon:Carsten Schiers =0D= =0AGesendet:Di 28.02.2012 15:39=0D=0ABetreff:Re: [Xen-devel] Load increas= e after memory upgrade (part2)=0D=0AAnlage:inline.txt=0D=0A=20=0D=0A=0D=0A= Well let me check for a longer period of time, and especially, whether th= e DomU is still=0D=0A=0D=0Aworking (can do that only from at home), but l= oad looks pretty well after applying the=0D=0A=0D=0Apatch to 3.2.8 :-D.=0D= =0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3= =BCngliche Nachricht-----=0D=0AAn:Jan Beulich ;=20=0D=0A= CC:Konrad Rzeszutek Wilk ; xen-devel ; Carsten Schiers ; Sander Eikelenboom = ;=20=0D=0AVon:Konrad Rzeszutek Wilk =0D=0AGesendet:Fr 17.02.2012 16:18=0D=0ABetreff:Re: [Xen-devel] = Load increase after memory upgrade (part2)=0D=0AOn Thu, Feb 16, 2012 at 0= 8:56:53AM +0000, Jan Beulich wrote:=0D=0A> >>> On 15.02.12 at 20:28, Konr= ad Rzeszutek Wilk wrote:=0D=0A> >@@ -1550,7 +155= 2,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gf= p_mask,=0D=0A> > struct page **pages;=0D=0A> > unsigned int nr_pages, arr= ay_size, i;=0D=0A> > gfp_t nested_gfp =3D (gfp_mask & GFP_RECLAIM_MASK) |= __GFP_ZERO;=0D=0A> >-=0D=0A> >+gfp_t dma_mask =3D gfp_mask & (__GFP_DMA = | __GFP_DMA32);=0D=0A> >+if (xen_pv_domain()) {=0D=0A> >+if (dma_mask =3D= =3D (__GFP_DMA | __GFP_DMA32))=0D=0A>=20=0D=0A> I didn't spot where you f= orce this normally invalid combination, without=0D=0A> which the change w= on't affect vmalloc32() in a 32-bit kernel.=0D=0A>=20=0D=0A> >+gfp_mask &= =3D (__GFP_DMA | __GFP_DMA32);=0D=0A>=20=0D=0A> gfp_mask &=3D ~(__GFP_DMA= | __GFP_DMA32);=0D=0A>=20=0D=0A> Jan=0D=0A=0D=0ADuh!=0D=0AGood eyes. Tha= nks for catching that.=0D=0A=0D=0A>=20=0D=0A> >+}=0D=0A> > nr_pages =3D (= area->size - PAGE_SIZE) >> PAGE_SHIFT;=0D=0A> > array_size =3D (nr_pages = * sizeof(struct page *));=0D=0A> >=20=0D=0A>=20=0D=0A=0D=0A______________= _________________________________=0D=0AXen-devel mailing list=0D=0AXen-de= vel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-devel=0D=0A=20= =0D=0A=20=0D=0A=0D=0A=C2=A0=0D=0A --------------------------------=0D=0AE= -Mail ist virenfrei.=0D=0A Von AVG =C3=BCberpr=C3=BCft - www.avg.de=0D=0A= Version: 2012.0.2127 / Virendatenbank: 2411/4932 - Ausgabedatum: 12.04.2= 012=0D=0A=20 --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+ CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj Y2VzcyB2Ny4wLjYtMzI3NTIiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0 bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh ZD4KPGJvZHk+CjxwPkhpIEtvbnJhZCw8L3A+PHA+Jm5ic3A7PC9wPjxwPmRvbiYjMzk7dCB3 YW50IHRvIGJlIHB1c2h5LCBhcyBJIGhhdmUgbm8gcmVhbCBpc3N1ZS4gSSBzaW1wbHkgdXNl IHRoZSBYZW5pZmllZCBrZXJuZWwgb3IgdGFrZSB0aGUgZG91YmxlIGxvYWQuIDwvcD48cD5C dXQgSSB0aGluayB0aGlzIG1pc3RlcnkgaXMgc3RpbGwgb3Blbi4gTXkgbGFzdCBzdGF0dXMg d2FzIHRoYXQgdGhlIGxhdGVzdCBwYXRjaCB5b3UgcHJvZHVjZWQgcmVzdWx0ZWQgaW4gYSBC VUcsIDwvcD48cD5zbyB3ZSBzdGlsbCBoYXZlIG5vdCBjaGVja2VkIHdoZXRoZXIgb3VyIHRo ZW9yeSBpcyBjb3JyZWN0LjwvcD48cD4mbmJzcDs8L3A+PHA+QlIsPC9wPjxwPkNhcnN0ZW4u PGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNv bGlkICMzMjVGQkE7IHBhZGRpbmctbGVmdDogNXB4O21hcmdpbi1sZWZ0OjVweDsiPi0tLS0t VXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPGJyIC8+PHN0cm9uZz5Wb246PC9z dHJvbmc+CUNhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0OzxiciAv PjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CU1pIDI5LjAyLjIwMTIgMTQ6MDE8YnIgLz48 c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz48c3Ryb25nPkFubGFnZTo8L3N0 cm9uZz4JZGVidWcubG9nLCBpbmxpbmUudHh0PGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4J S29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0Ozsg PGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4JU2FuZGVyIEVpa2VsZW5ib29tICZsdDtsaW51 eEBlaWtlbGVuYm9vbS5pdCZndDs7IHhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhl bnNvdXJjZS5jb20mZ3Q7OyBKYW4gQmV1bGljaCAmbHQ7amJldWxpY2hAc3VzZS5jb20mZ3Q7 OyBLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBkYXJub2sub3JnJmd0OzsgPGJy IC8+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHsgZm9udC1mYW1pbHk6IG1vbm9zcGFj ZTsgfTwvc3R5bGU+ICAgICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gICAg ICAgLmJvZHljbGFzcyAgICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFsLCBWZXJk YW5hLCBTYW5zLVNlcmlmICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTogMTJweDsg ICAgICAgICBwYWRkaW5nOiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2luOiAwcHg7 ICAgICAgICAgYm9yZGVyLXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQtY29sb3I6 ICNmZmZmZmY7ICAgICAgIH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAgICAgbWFy Z2luLXRvcDogMHB4OyAgICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAgfSAgIDwv c3R5bGU+ICA8ZGl2PjxwPkkgYW0gdmVyeSBzb3JyeS4gSSBhY2NpZGVudGx5IHN0YXJ0ZWQg dGhlIERvbVUgd2l0aCB0aGUgd3JvbmcgY29uZmlnIGZpbGUsIHRodXMgaXQmIzM5O3MgY2xl YXIgd2h5IHRoZXJlIGlzIG5vIGRpZmZlcmVuY2U8L3A+PHA+YmV0d2VlbiB0aGUgdHdvLiBB bmQgdW5mb3J0dW5hdGVseSwgdGhlIERvbVUgd2l0aCB0aGUgY29ycmVjdCBjb25maWcgZmls ZSBpcyBoYXZpbmcgYSBCVUc6PC9wPjxwPiZuYnNwOzwvcD48cHJlPgogWyAgIDE0LjY3NDg4 M10gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCBmZmZm YzdmZmZmZmZmMDAwIFsgICAxNC42NzQ5MTBdIElQOiBbJmx0O2ZmZmZmZmZmODExYjRjMGIm Z3Q7XSBzd2lvdGxiX2JvdW5jZSsweDJlLzB4MzEgWyAgIDE0LjY3NDkzMF0gUEdEIDAgIFsg ICAxNC42NzQ5NDBdIE9vcHM6IDAwMDIgWyMxXSBTTVAgIFsgICAxNC42NzQ5NTJdIENQVSAw ICBbICAgMTQuNjc0OTU3XSBNb2R1bGVzIGxpbmtlZCBpbjogbmZzZCBleHBvcnRmcyBuZnMg bG9ja2QgZnNjYWNoZSBhdXRoX3JwY2dzcyBuZnNfYWNsIHN1bnJwYyB0ZGExMDAyMyBidWRn ZXRfYXYgZXZkZXYgc2FhNzE0Nl92diB2aWRlb2RldiB2NGwyX2NvbXBhdF9pb2N0bDMyIHZp ZGVvYnVmX2RtYV9zZyB2aWRlb2J1Zl9jb3JlIGJ1ZGdldF9jb3JlIHNuZF9wY20gZHZiX2Nv cmUgc25kX3RpbWVyIHNhYTcxNDYgc25kIHR0cGNpX2VlcHJvbSBzb3VuZGNvcmUgc25kX3Bh Z2VfYWxsb2MgaTJjX2NvcmUgcGNzcGtyIGV4dDMgamJkIG1iY2FjaGUgeGVuX25ldGZyb250 IHhlbl9ibGtmcm9udCBbICAgMTQuNjc1MDU3XSAgWyAgIDE0LjY3NTA2NV0gUGlkOiAwLCBj b21tOiBzd2FwcGVyLzAgTm90IHRhaW50ZWQgMy4yLjgtYW1kNjQgIzEgICBbICAgMTQuNjc1 MDc5XSBSSVA6IGUwMzA6WyZsdDtmZmZmZmZmZjgxMWI0YzBiJmd0O10gIFsmbHQ7ZmZmZmZm ZmY4MTFiNGMwYiZndDtdIHN3aW90bGJfYm91bmNlKzB4MmUvMHgzMSBbICAgMTQuNjc1MDk3 XSBSU1A6IGUwMmI6ZmZmZjg4MDAxM2ZhYmU1OCAgRUZMQUdTOiAwMDAxMDIwMiBbICAgMTQu Njc1MTA2XSBSQVg6IGZmZmY4ODAwMTI4MDAwMDAgUkJYOiAwMDAwMDAwMDAwMDAwMDAxIFJD WDogMDAwMDAwMDAwMDAwMTAwMCBbICAgMTQuNjc1MTE2XSBSRFg6IDAwMDAwMDAwMDAwMDEw MDAgUlNJOiBmZmZmODgwMDEyODAwMDAwIFJESTogZmZmZmM3ZmZmZmZmZjAwMCBbICAgMTQu Njc1MTI2XSBSQlA6IDAwMDAwMDAwMDAwMDAwMDIgUjA4OiBmZmZmYzdmZmZmZmZmMDAwIFIw OTogZmZmZjg4MDAxM2Y5ODAwMCBbICAgMTQuNjc1MTM3XSBSMTA6IDAwMDAwMDAwMDAwMDAw MDEgUjExOiBmZmZmODgwMDAzMzc2MDAwIFIxMjogZmZmZjg4MDAwMzJjNTA5MCBbICAgMTQu Njc1MTQ3XSBSMTM6IDAwMDAwMDAwMDAwMDAxNDkgUjE0OiBmZmZmODgwMDAzM2UwMDAwIFIx NTogZmZmZmZmZmY4MTYwMWZkOCBbICAgMTQuNjc1MTYzXSBGUzogIDAwMDA3ZjNmZjk4OTM3 MDAoMDAwMCkgR1M6ZmZmZjg4MDAxM2ZhODAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAw MDAwIFsgICAxNC42NzUxNzVdIENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAw MDAwMDAwODAwNTAwM2IgWyAgIDE0LjY3NTE4NF0gQ1IyOiBmZmZmYzdmZmZmZmZmMDAwIENS MzogMDAwMDAwMDAxMjY4MzAwMCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjAgWyAgIDE0LjY3NTE5 NV0gRFIwOiAwMDAwMDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAw MDAwMDAwMDAwMDAwMDAgWyAgIDE0LjY3NTIwNV0gRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERS NjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAgWyAgIDE0LjY3NTIx Nl0gUHJvY2VzcyBzd2FwcGVyLzAgKHBpZDogMCwgdGhyZWFkaW5mbyBmZmZmZmZmZjgxNjAw MDAwLCB0YXNrIGZmZmZmZmZmODE2MGQwMjApIFsgICAxNC42NzUyMjddIFN0YWNrOiBbICAg MTQuNjc1MjMyXSAgZmZmZmZmZmY4MTIxMTgyNiBmZmZmODgwMDAyZWRhMDAwIDAwMDAwMDAw MDAwMDAwMDAgZmZmZmM5MDAwMDQwODAwMCBbICAgMTQuNjc1MjUxXSAgMDAwMDAwMDAwMDBi MDE1MCAwMDAwMDAwMDAwMDAwMDA2IGZmZmZmZmZmYTAxM2VjNGEgZmZmZmZmZmY4MTA5NDZj ZCBbICAgMTQuNjc1MjcwXSAgZmZmZmZmZmY4MTA5OTIwMyBmZmZmODgwMDAzMzc2MDAwIDAw MDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAwMmVkYTRiMCBbICAgMTQuNjc1Mjg5XSBDYWxsIFRy YWNlOiBbICAgMTQuNjc1Mjk1XSAgJmx0O0lSUSZndDsgIFsgICAxNC42NzUzMDddICBbJmx0 O2ZmZmZmZmZmODEyMTE4MjYmZ3Q7XSA/IHhlbl9zd2lvdGxiX3N5bmNfc2dfZm9yX2NwdSsw eDJlLzB4NDcgWyAgIDE0LjY3NTMyMl0gIFsmbHQ7ZmZmZmZmZmZhMDEzZWM0YSZndDtdID8g dnBlaXJxKzB4N2YvMHgxOTggW2J1ZGdldF9jb3JlXSBbICAgMTQuNjc1MzM3XSAgWyZsdDtm ZmZmZmZmZjgxMDk0NmNkJmd0O10gPyBoYW5kbGVfaXJxX2V2ZW50X3BlcmNwdSsweDE2Ni8w eDE4NCBbICAgMTQuNjc1MzUwXSAgWyZsdDtmZmZmZmZmZjgxMDk5MjAzJmd0O10gPyBfX3Jj dV9wcm9jZXNzX2NhbGxiYWNrcysweDcxLzB4MmY4IFsgICAxNC42NzUzNjRdICBbJmx0O2Zm ZmZmZmZmODEwNGQxNzUmZ3Q7XSA/IHRhc2tsZXRfYWN0aW9uKzB4NzYvMHhjNSBbICAgMTQu Njc1Mzc2XSAgWyZsdDtmZmZmZmZmZjgxMjBhOWFjJmd0O10gPyBlb2lfcGlycSsweDViLzB4 NzcgWyAgIDE0LjY3NTM4OF0gIFsmbHQ7ZmZmZmZmZmY4MTA0Y2JjNiZndDtdID8gX19kb19z b2Z0aXJxKzB4YzQvMHgxYTAgWyAgIDE0LjY3NTQwMF0gIFsmbHQ7ZmZmZmZmZmY4MTIwYTAy MiZndDtdID8gX194ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDFjNy8weDIwNSBbICAgMTQuNjc1 NDEyXSAgWyZsdDtmZmZmZmZmZjgxMzRiMDZjJmd0O10gPyBjYWxsX3NvZnRpcnErMHgxYy8w eDMwIFsgICAxNC42NzU0MjVdICBbJmx0O2ZmZmZmZmZmODEwMGZhNDcmZ3Q7XSA/IGRvX3Nv ZnRpcnErMHgzZi8weDc5IFsgICAxNC42NzU0MzZdICBbJmx0O2ZmZmZmZmZmODEwNGM5OTYm Z3Q7XSA/IGlycV9leGl0KzB4NDQvMHhiNSBbICAgMTQuNjc1NDUyXSAgWyZsdDtmZmZmZmZm ZjgxMjBiMDMyJmd0O10gPyB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDI3LzB4MzIgWyAgIDE0 LjY3NTQ2NF0gIFsmbHQ7ZmZmZmZmZmY4MTM0YjBiZSZndDtdID8geGVuX2RvX2h5cGVydmlz b3JfY2FsbGJhY2srMHgxZS8weDMwIFsgICAxNC42NzU0NzNdICAmbHQ7RU9JJmd0OyA8L3By ZT48cD4mbmJzcDs8L3A+PHA+Q29tcGxldGUgbG9nIGlzIGF0dGFjaGVkLjwvcD48cD4mbmJz cDs8L3A+PHA+QlIsIENhcnN0ZW4uPGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXItbGVmdDogMnB4IHNvbGlkICMzMjVGQkE7IHBhZGRpbmctbGVmdDogNXB4O21h cmdpbi1sZWZ0OjVweDsiPi0tLS0tVXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hyaWNodC0tLS0t PGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4JS29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtr b25yYWQud2lsa0BvcmFjbGUuY29tJmd0OzsgPGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4J S29ucmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IHhlbi1k ZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7OyBKYW4gQmV1bGlj aCAmbHQ7amJldWxpY2hAc3VzZS5jb20mZ3Q7OyBTYW5kZXIgRWlrZWxlbmJvb20gJmx0O2xp bnV4QGVpa2VsZW5ib29tLml0Jmd0OzsgPGJyIC8+PHN0cm9uZz5Wb246PC9zdHJvbmc+CUNh cnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0OzxiciAvPjxzdHJvbmc+ R2VzZW5kZXQ6PC9zdHJvbmc+CU1pIDI5LjAyLjIwMTIgMTM6MTY8YnIgLz48c3Ryb25nPkJl dHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNlIGFmdGVyIG1l bW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz48c3Ryb25nPkFubGFnZTo8L3N0cm9uZz4JaW5s aW5lLnR4dDxiciAvPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+LmJvZHljbGFzcyB7IGZvbnQt ZmFtaWx5OiBtb25vc3BhY2U7IH08L3N0eWxlPiAgICAgICAgICAgICAgIDxzdHlsZSB0eXBl PSJ0ZXh0L2NzcyI+ICAgICAgIC5ib2R5Y2xhc3MgICAgICAgeyAgICAgICAgIGZvbnQtZmFt aWx5OiBBcmlhbCwgVmVyZGFuYSwgU2Fucy1TZXJpZiAhIGltcG9ydGFudDsgICAgICAgICBm b250LXNpemU6IDEycHg7ICAgICAgICAgcGFkZGluZzogNXB4IDVweCA1cHggNXB4OyAgICAg ICAgIG1hcmdpbjogMHB4OyAgICAgICAgIGJvcmRlci1zdHlsZTogbm9uZTsgICAgICAgICBi YWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOyAgICAgICB9ICAgICAgICBwLCB1bCwgbGkgICAg ICAgeyAgICAgICAgIG1hcmdpbi10b3A6IDBweDsgICAgICAgICBtYXJnaW4tYm90dG9tOiAw cHg7ICAgICAgIH0gICA8L3N0eWxlPiAgPGRpdj48cD5HcmVhdCBuZXdzOiBpdCB3b3JrcyBh bmQgbG9hZCBpcyBiYWNrIHRvIG5vcm1hbC4gSW4gdGhlIGF0dGFjaGVkIGdyYXBoIHlvdSBj YW4gc2VlIHRoZSBwZWFrPC9wPjxwPmluIGJsdWUgKGNvbXBpbGF0aW9uIG9mIHRoZSBwYXRj aGVkIDMuMi44IEtlcm5lbCkgYW5kIHRoZW4gYWZ0ZXIgMTYuMDAgdGhlIGdvaW5nIGxpZmUg b2YgdGhlPC9wPjxwPnZpZGVvIERvbVUuIFdlIGFyZSBiZWxvdyBhbiBhdmFlcmFnZSBvZiA3 JSB1c2FnZSAoZmlndXJlcyBhcmUgaW4gUGVybWlsbGUpLjwvcD48cD48YnIgLz5UaGFua3Mg c28gbXVjaC4gSXMgdGhhdCBhbHJlYWR5ICZxdW90O3RoZSBmaW5hbCBwYXRjaCZxdW90Oz88 L3A+PHA+Jm5ic3A7PC9wPjxwPkJSLCBDYXJzdGVuLjwvcD48cD4mbmJzcDs8L3A+PHA+PGJy IC8+Jm5ic3A7PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3 MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBR0VDQUlBQUFDcHY0NVlBQUFnQUVsRVFWUjRuTzJk ZlhRVVZaNzNiMGdDSVNBSndTQmd0a25Fa0pBM3pBWVZmVWFQajJjZEhjZURPSUZsWmdCM2Rw eGhSa1FqNktvYzUyQ3ZzRG9LQXpqQkxEbW9aSU5CTU4yQkJGbGZFRWtFOXhBSjZLQkVqTHc0 S0VoM09xLzNuejNuK1NQUEh4ZXVSZDJxNnB2dXJ1cnFxdS9uOU9uVFhYM3IzdnU3ZGV2YnY5 eXUrb1o4QmdBQXdCRzB0cmFTZVBjQkFBQkFER2h0YlgzampUY3VhVG9GQUFDUXlMenh4aHZR ZEFBQWNBalFkQUFBY0E3UWRBQUFjQTdRZEFBQVNDUWFCWlNmUXRNQmtJSVFFdTh1RElOWTlU YXhvbllWZzRPRFRNMmg2Y0NCbUNjOXZHYnhSVXlxTlFsb3VyUHA3KzgvY3VTSXorYzdmLzU4 VTFPVDhpTm91cXRadUhEaGIzLzdXK1dXZi8zWGYxMjBhRkUwZFJKQ0NDRkpTVWxYWFhWVldW blo4dVhMejU0OUcxMDNZNHltVG9XVjdDalZ6V0p4aEtZN21NN096cGFXbHJhMnRxNnVycWFt cGlOSGppZy9oYWE3bWtBZ1VGUlU5TVliYjdDM3I3LytlbkZ4Y1RBWWpLWk9yZ0tCUU9EUW9V TVBQL3p3NU1tVFQ1dzRFVzFmWXdjMDNmcDZRQXo1NktPUHpwOC9yL2NwTk4zdEhEMTY5SnBy cmpsMjdOaXhZOGNtVFpyRXBrRi9mLytLRlN1dXZ2cnEwYU5IVjFaVy92RERENnd3SVdUanhv MGVqeWMxTmJXc3JPeVRUejRSS3hSVjRPbW5uLzdsTDMvSlhuZDNkLy9Mdi96TFZWZGRkZFZW Vi8zbU43L3A3dTdtZTIzWXNHSHExS2tqUjQ2Y01XUEdCeDk4c0huejVtblRwckdHRGg4K3pJ cDk4Y1VYUC92Wno4YU1HVE5xMUtpNzdycnJ6Smt6cWtZajZ5SGZTQlNJTllzdnhQS2FQVFNv MW1CQXdnWmlBQ0ZrOWVyVjJkblo2ZW5waXhZdENvVkNsTkpiYjcxMTY5YXR2RXhuWitla1Na TlU2aEFLaFJZdVhKaWVuajV4NHNRMWE5WVl4eVZUSWJBWWFEcWdyNzMyV25GeGNYRnhjVjFk SGR2eXB6Lzk2YzQ3N3p4NTh1UVBQL3l3Y09IQzMvM3VkMnc3SWFTeXN2THJyNzhPQkFMUFB2 dHNSVVdGV0p1b21KMmRuZGRjY3cxNy9kaGpqOTE5OTkxbnpwdzVmZnIwUC8zVFAxVlZWZkc5 NXN5Wjg5VlhYd1VDZ2VlZWUyN3MyTEVQUFBBQWYzdmpqVGV5WW9XRmhlKzg4MDR3R0R4Ly92 elNwVXNYTEZpZ2FqU3lIbEw5UEYxbVBiMjZ1dnFlZSs2UjdLSHFyY0dBaEEzRUFFSUlxL2JN bVROMzMzMzM0NDgvVGluZHRXdFhRVUhCd01BQUsvUGdndzgrLy96enFoMnJxcXA0Zis2NjZ5 N2VUODI0WkNvRU1RZlh2WUR3bEplWHo1bzFpNy8xZUR6SGpoMWpyMCtmUGoxeDRrVDJtaEJ5 N3R3NTlqb1FDS1NrcEloVmlaTFgyOXVibXByS1hrK2VQUG56eno5bnJ6Lzc3TE1wVTZid3Zm Nys5Ny96bWxWdk5Sc0tCQUpYWDMyMXF0SElla2lqMFBTV2xwYVpNMmZ5UDJYQzlsRDExbUJB d2daaUFDSGtiMy83RzN2OStlZWZYM3Z0dGV4MVJVWEY2NisvempjR0FnSFZqbE9tVE9FN2Z2 YlpaNXBqcFl3cmJJWEFKSERkQzlCbDgrYk5OOXh3d3cwMzNQRGFhNit4TFNrcEtjcmxncVNr SkxaZFQ1aU1ON0kveWRucjVPVGsvdjUrOXJxdnI0OUxsWEhOL08ySEgzNTR5eTIzcEtlbjYz Vk1wb2NqUm96Z2ZXRDA5L2VQR0RIQ3VBYk5KbzRjT1RKdDJqVGxyd1ZoZTZoNkc5bUE4STNL OVJ6VlI1clY3dGl4SXo4L3Y3Ky9mLzc4K1d2WHJoVjNWUFVuN01pSHJSQ1lBYTU3QWJvY09Y Sms4dVRKWDN6eHhmSGp4eWRQbm56MDZGRkthVTVPenRkZmZ5MFdqa3pUbjM3NjZWLzk2bGZz OWVUSms1VnA0T1RKazJWcTVtK25USmxTVjFkMy92ejV3Y0hCQ3hjdWhFMmlOWHZvOFhqKzUz LytSN25sMEtGREhvL0h1QWJ4eFprelovTHo4L2Z0MjZjc0g3YUhxcmVSRFVoWWxIbjYzLzcy TjU3K0R3NE9GaGNYVjFWVmVUeWVucDRlY1VkbG52NzU1NStISGZtd0ZZS1lnK3RlZ0M2QlFH REdqQmx2dmZVV2Uvdm1tMit5NjE2ZWUrNjV1KysrKy9qeDQzMTlmWWNQSDY2c3JHUUZocVhw N0xxWHBVdVhLcTk3V2Jac0dWL252ZXV1dXg1OTlGR1ptdm5iOGVQSDc5aXhJeFFLZmZIRkY1 V1ZsWkZwK3IvLys3K1hsNWQvOU5GSG9WQW9GQXJ0Mzc5LzVzeVphOWFzWVo5bVpHVHdkU2ZO bXZtTEcyKzhjZlBtemFySzlYcW9WMjFrQXhJV1FzalBmdmF6czJmUG5qMTc5cDU3N3VITDlK VFN1cm82UXNpcnI3NnF1V05WVlJYYmtTM0VoeDM1c0JXQ21JUHJYb0F1Q3hjdTVDTENlUGpo aHhjdVhEZ3dNT0QxZXRsRkYwVkZSZnkzVS9rRmdhU2twREZqeHBTV2xqNysrT1A4NmhSS2FU QVlYTHg0OGRpeFk4ZU9IYnQ0OFdKKzNhU2twci8xMWx1NXVibkp5Y24vOEEvL3NIYnQyc2cw ZlhCd2NPM2F0Y1hGeGFOR2pSbzFhbFJ4Y2ZGZi92SVgvdW1xVmF2R2pCbGpVTFB5aFJMakh1 cFZHOW1BaElVb3JudFp1SEFodjV5R1VycHQyN1pwMDZiMTlmVnA3dGpkM2YzclgvOTY5T2pS MmRuWnl1dGU5T0lLV3lHd0dHZzZBTzdpM252djVYY2syTE5DWUF5dWV3RUFVRXJwd01CQWRY VjFZV0Vodi9yUWJoVUNHVlFpRGswSHdLVVFRandlVDJ0cnEyMHJCREkwTlRYMTl2YXkxNzI5 dmJqdUJRQUFFcGpXMXRaUFAvMjByNit2cjYvdjAwOC9iV3RyVTM0S1RRY0FnRVNpdTd2N3dJ RURmci9mNy9lM3RyWXFmd0NuMEhRQUFFaG9zSjRPQUFET0Fab09BQUFKakl1dVpUeStkKy94 dlh2ajNRc0FBTEFPeDJwNlh5aTAvcFpiMXQ5eVMxOG9GTysrQUFDQVJUaFcwejk0NlNXdngr UDFlRDU0NmFWNDl3VUFBT0tEUXpUOS9NbVRhL0x6bWFhdnljOC9mL0prdkhzRUFBQ21FQXdH VzF0YitiV01xbjgyNlJCTnIxKzhtQWs2ZTlRdlhoenZIZ0VBZ0NuczI3ZnYyTEZqdmIyOXZi MjlSNDhlVmJrOU8wVFRHVTg5OVpSTXNhNnVMdXVMeVpmczdlaUlTN3VJMTVwMkVhODE3ZG84 M21qdytYemNZR2RnWU1Ebjh5ay9kYU9tSHp4NDBQcGk4aVV2Yk5vVWwzWVJyelh0SWw1cjJy VjV2TkhnaWp5OXQ3ZjN4SWtUdi8zdGI0ZUdoazZmUG0zOC9MLy8rNzloeXd3TkRaMDhlVEtH dGNtWDdEcDJMQzd0SWw3RWkzZ3RpM2RvYU9qcnI3OCtjZUtFL0I4S25FQWc0UHoxZE1aVFR6 MDFKTUdwVTZlc0x5WmZrcmExeGFWZHhHdE51NGpYbW5adEh1K2x3aWJnUmswSEFBQTdFSm5R dWVLNkZ3Ynk5R2hLSWw1cjJrVzgxclJyODNndkZZNElPNjZuMTlmWEZ4WVdwcWFtbHBhV3Ry UzA4TzByVjY3ay8rZnc2NisvbmoxNzlzaVJJMmZQbnMzK2g3MjRSUVh5ZEFCQUFoR1pmdHJ4 dXBjSEhuaWd2YjI5dTd0NzA2Wk5FeVpNWUJ2YjJ0b21UWnJFTlgzZXZIa3JWcXpvN3U1ZXNX TEYvUG56TmJlb1FKNGVUVW5FYTAyN2lOZWFkbTBlNzZYQ0VXSEhQSjF6NHNRSmo4ZERLZTN1 N2k0dUx0NjdkeS9YOUFrVEpwdytmWnBTZXZyMGFhYjc0aFlWeU5NQkFBbEVaTEpwMyt0ZVRw MDZWVjVldm5QblRrcnAwcVZMWDN6eFJVb3AxL1FSSTBhd3Z5LzYrL3VUazVNMXQzRDYvLzcz QzYrODh1VHZmMDhQSEJnYUdqSitQcjF6WjlneTlNQ0JVNmRPeGJBMitaSzByUzB1N1NKZXhJ dDRMWXVYSGpqdy8wS2hDNis4MHRQZUhsdGRqWnVtdDdhMmVqeWVMVnUyc0xkSlNVbEVBYVUw S3l0TGxaV0xXMVFnVHdjQUpCQ1JpYWNkL2RPcnE2dXpzN04zNzk0dGZzVHo5TXJLU3I1Nlhs bFpxYmxGQmRiVG95bUplSzFwRi9GYTA2N040NzFVT0NKVUlxNGlQcHBPcnVUaXhZdktqOWlM cjc3NjZxYWJia3BOVGIzNTVwdFBuanlwdVVVRjhuUUFRQUlSbVg3YVVkTk5Bbmw2TkNVUnJ6 WHRJbDVyMnJWNXZKY0tSd1EwSFFBQTdJZ1pNdWhHVFhmRzk3emI4aHJFRzJWSnhHdE51L0I3 aVEzRDhtWEVNNTd4ak9lNFAwZm15L2pPTysrMHQ3ZWZQbjI2djc5ZnM0QkROSjJCUEQyYWtv alhtbllScnpYdDJqemVTNFdIejRVTEY0NGZQNzUvLy82bXBxYjkrL2NmUDM3OHdvVUx5Z0p1 MUhRQUFMQUQwY2hkWDEvZjZkT24yOXZiMzNubkhlVjJOMnE2TTc3bjNaYlhJTjRvU3lKZWE5 cDE2WHE2Nk1zb2JvRXZJd0RBMlppaHJuYnhaUlMzd0pmUjRuWVJyelh0SWw1cjJyVjV2SmNL bTRCZGZCbkZMZkJsQkFBNG01aW9xQzM4WGhpbkZMNk00aGI0TXNMSER2RWlYcWZHUzJQbnky Z1hUVmY1TW9wYjRNc0lBSEEya1lsbll2Z3lpbHZneTJoeHU0alhtbllScnpYdDJqemVTNFZq Z1MwMFhmUmxGTGZBbHhFQTRHeGlJcWUyMEhTVFFKNGVUVW5FYTAyN2lOZWFkbTBlNzZYQ0p1 QkdUUWNBQURzUW1kQUZnMEdiL2ovU21JTThQWnFTaU5lYWRoR3ZOZTNhUE41TGhTTmkzNzU5 eDQ0ZDYrM3Q3ZTN0UFhyMDZMNTkrNVNmT2tUVDRjdUlaenpqT2JHZUkvTmxwSlQ2ZkQ1MlZU ZWxkR0Jnd09mektUOTFpS1l6bkplbmt3MkViQ0RXdEd1SGVLMXNGL0ZhMHk3aU5Tb2NFYTdJ MHhuT1cwODMwSFFBUUtJVG1kQUZBZ0dzcDE5QkFuM1Bkd3lSamlIazZhYTBpM2l0YVJmeEdo VTJBYnY0TXNxNE1MckVsMUdabTllUzJscFNHOS8rQUFCTUlqTDl0T045cEpHNU1EclBsNUZy TjlOeDlwaXpNb2ZMZWdXcHJkRFJkTGZsTllnM3lwS0kxNXAyTGNqVG1ZaHpLYmVGcG5PRzVj TG9QRjlHbGFZUEVVSTJFSy9YMnpGRVdIcHVvT2tBZ0VRbk10bjArLzAvL1BDRHorZTdjT0hD aFFzWGR1M2FwZnpVTHI2TU1pNk16dk5sckgvc01mYmE2L1cyNUt5cUpiVXRPYXVhYzU1cnlW bFZRV3JwZ1FNVnBIWjV6cXFZdDV1SVBuYUlGL0U2S1Y0YWhTL2pwNTkrMnRUVTFOblorYzQ3 Ny9qOS9pKy8vRkw1cVYxOEdXVmNHSjNueThqWHltdEpiWVh3R0JvYUlrdjJrQ1Y3NHRwSEFJ QlptQ0d0ZHZGbGxIRmhkSjR2WTRXV3BsZmxQQ2VqNlc1YmYwUzhVWlpFdk5hMGE4MTZ1dTEr STQzTWhkRjV2b3hjMHkrSnVKZndGMHpLa2FjRDRHRE1VRmRjbjI1Uk1jMlNTazFuOGsyVzdK bno0RVl1NWNqVHpXc1g4VnJUTHVJMUttd0NidFIwKzhEMW1ndTY4akdFUEIwQVIyT0dETHBS MCszelBhK3A2Y2pUcldrWDhWclRMdUkxS213Q0R0SDBCUFZsSkV2MnNOZkZLM2FRSlh0VXoz eDczUHVKWnp6ak9lYlBFZnN5d2o5ZGpYMis1NUduRHlHUHM2cGR4R3ROdS9CbGpDVllUd2NB SkJDUkNSMzgwOVhZNTNzZWVmb1E4amlyMmtXODFyVHIwanlkWDVuT3R6UTBOT1RsNVNVbkor Zm01alkwTkZCMytESWlUd2ZBelVTbW4vYjFUMWRxK3JoeDQveCtmeWdVOHZsOEdSa1oxQ1cr ak1qVGtjZFoxUzdpdGFaZFYxLzNvdFQwa3BJU3Y5L2YwOVBqOC9uS3lzcW9TM3daa2FjRDRH SWlVMDQ3ZWdNd2xKcCs0TUNCY2VQR0VVTEdqUnQzNE1BQjZnNWZ4cm1MMTdQWFpNbWV1WXZY cytjNUQyNWtyL24ybUxlYmlENTJpQmZ4T2lsZUdvVXZvMzM5MDVXYVBtM2FOTDcyY3YzMTEx TjMrRElpVHdmQXpVU21uSW1oNlptWm1YenRaZno0OGRRZHZveGt5WjVMLzk0STYrbVd0NHQ0 cldrWDhSb1ZqZ2c3YXJyS2w1RlNXbDlmNy9GNGtwT1RwMDZkK3VhYmIxSjMrREpxYWpyeWRB QmNRa3prMUJhYWJoS0ptS2V6L3lLTlBOMzZkaEd2TmUwaVhxUENzUUNhYmlQSWtqM01NQjE1 T2dBdUpES2hzKzkxTHpFbkVmTjBVZE9ScDF2VEx1SzFwbDNFYTFRNEZqaFQweFBYbC9IKzRw b0tVZ3RmUmp6ajJXM1BFZnN5cW5DbXBqTVNNVThYSDhqVHJXa1g4VnJUTHVJMUttd0NidFIw bTZCM3VRdlcwd0Z3Q1pFSkhkYlQxZGprZTE1UDA1R25XOU11NHJXbVhjUnJWTmdFN09MTE9E QXdzSExseXNtVEp5Y2xKYkh0anZkbDdCZ0trNmR6MFk5M1R3RUFwaENaZnRvM1QxZHErcXBW cTZaUG45N2UzajQ0T01pMk9ONlhzVmJuRWthZXAvTUNzVzNYbW1MeUpaSEhXZE11NHJXbVhX dnk5SjZlbnZmZWU2K3BxZW5zMmJPcWoreWk2UjZQUi9YZk9oenZ5NmgzV1RwL1ZCaHFPZ0Fn MFlsTU9abWdIenQyN0x2dnZ0dTllL2Y1OCtlVm45cEYwNU9Ua3g5NTVKSFJvMGQ3UEo0ZE8z WlFGL2d5VnBCYTdzVkl0SHdabCtlc0l2QmxSTHlJMTRueDBpaDhHZDk5OTEwdTE5OTg4MDFM UzR2eVU3dG8rb1FKRTN3K0gvTmx2UHJxcTZrTGZCbVJwd1BnY2lKVFRwVldmL25sbDhxM1lU UjkzNzU5K2ZuNVNVbEpsTklGQ3hiVTFkVkYxZ2xObEpvK2YvNThuOC9IZkJtenM3T3BDM3da OWFTY3I2Y2JhN3JiMWg4UmI1UWxFYTgxN1Zyanl4ajViNlRYWDMvOXJsMjdtUGgrOWRWWFU2 ZE9qYXdUS2tSZnhxNnVycC84NUNlcHFhbDVlWGxzWWQzeHZveGhMbnE1OGtKMUFJRHppRXcv by9MYVRVMU5EWVZDVEhiUG5UdVhucDRlV1Nlc3dXRjV1ckdtdXkydlFieFJsa1M4MXJScmQv LzBPKzY0WS9QbXpZU1FycTZ1QlFzV3pKa3pKN0pPV0FQeWRBQkFBaEdaMEVXbDZWMWRYZmZk ZDE5NmVucDZldnFjT1hPKy9mYmJ5RHBoRGNqVG95bHA4N3dHOFVaWkV2RmEwNjVMN3lPTk9Z bm95NmpweGFqNWJJZmU0aG5QZUk3dGM4UytqUGE5anpUbUlFK1BwcVROOHhyRUcyVkp4R3RO dTVibDZZT0RnNnBGR0lhMnBoTjlvdW1FMldBOUhRQ1FRRVNzZGYzOS9VZU9IUEg1Zk9mUG4y OXFhbEoraER6ZG9tSmlTZVRwRE9SeDFyU0xlSzFwMTRJOHZiT3pzNldscGEydHJhdXJxNm1w NmNpUkk4cFA3ZUxMeUZpNWNpWGY2SGhmUnVUcEFMaWN5UFR6bzQ4K1VubThLSW5uMm91cXRy YTJ0a21USnZHTmp2ZGxSSjdPUUI1blRidUkxNXAyWFgzZGkxTFR1N3U3aTR1TDkrN2R5emM2 M3BjUmVUb0FMc2NNWGJXTHBpOWR1dlRGRjE5VWJuUzhMeU1SSEJuSmxiNk0vRG0yN2NZclhy MW4rUFloWGhmR1M2UHdaVFJHVjlPWnRscTI5c0wrdlpHeUZjZjdNaUpQQjhEbHhGQk9PWGJK MDhXTjhHWEVlcnFwN1NKZWE5cEZ2RWFGVFNETzE3Mkl1VDkvQzE5RzVPa0FPQnN6MURXTXBt L2Z2dDNqOFNnWFJzem9SS3hBbmg1TlNadm5OWWczeXBLSTE1cDI3WjZuVDVnd1lkdTJiZjM5 L1dhMEhYT1Fwd01BRWdnelpEQ01wbWRtWmdZQ0FUTWFOZ1BrNmRHVXRIbGVnM2lqTElsNHJX blg3bm42czg4K3UzTGx5dTd1YmpQYWppSHdaY1F6bnZHY1dNOFIreklhRTBiVEd4b2FSbzBh NVRBUEw1dDh6eU5QWnlDUHM2WmR4R3ROdTNiUDA3T3pzeHNhR3JDZWJnWllUd2ZBNVpnaGcy RTBmZHk0Y1ZoUGowa3hzU1R5ZEFieU9HdmFSYnpXdEd2M1BOMms5WFJ4SmFlK3ZyNndzREEx TmJXMHRMU2xwWVhDbHhGNU9nQk9KN2E2eWdpajZaWjVBenp3d0FQdDdlM2QzZDJiTm0xaTkv M0RseEY1dXFudElsNXIya1c4Um9WTndIYmVBQ2RPblBCNFBCUytqTXJIQmhMdnpnSUFZbzha dWhwRzA1T1Nrc3hvbFNGcStxbFRwOHJMeTNmdTNFbmh5Nmpjdm9IQXh3N3hJbDRueFV1dDky VmtUSmt5NWV6WnM3RnRrcVBTOU5iV1ZvL0hzMlhMRnZZV3Zvejg0ZlY2NDkxWkFFRHNNVU5Y dzJqNml5KysrTkJERDEyOGVOR010cFdhWGwxZG5aMmR2WHYzYnI0RnZvejhVVXRxWTlpdU5j WGtTMks5MVpwMkVhODE3ZHA5UGQyazMwakZPbFZiTGw2OENGOUdZMDBIQUNRNk1aRlRGZkg4 alRUbU9EVlByMENlam5pakxvbDRyV25YN25sNll1SFVQRjFUMHdFQWlZNFpNaGhHMC9mdDI1 ZWZuOCt1Zmxtd1lFRmRYWjBabllnVnlOT2o2YUhOOHhyRUcyVkp4R3ROdTNiUDA2Ky8vdnBk dTNheEplK3Z2dnBxNnRTcFpuUWllaHp1eS9oK2NkeDdpMmM4NHptMnovSHhaVXhOVFEyRlFr elR6NTA3bDU2ZUh0dm1ZNHRUOC9RaHI4WTlSMjdMYTZ5TVYzbVRseHZpTmJWZHhHdFUyQVRD YVBvZGQ5eXhlZk5tUWtoWFY5ZUNCUXZtekpsalJpZGloVlBYMHdrc1g2d0ZOKzRDYXpCREJz Tm9lbGRYMTMzMzNaZWVucDZlbmo1bnpweHZ2LzNXakU3RUNxZm02WnFhN3JhOEJubDZsQ1Z4 ZksxcDErNTV1a21JVjd2THVEQzYxcGNSZWJyRklFOEgxbUNHdXRyRncwdkdoZEcxdm96STA4 MW9GM202TmUwaVhxUENKcUNyNlI5KytHRmhZV0ZLU2twaFllRkhIMzFrUnR0S1RaZHhZWFN2 THlQeWRHdEJuZzZzd1F4ZDFkWDBvcUtpbDE5K09SQUl2UHp5eXlVbEpXYTByZFIwR1JkRzkv b3lMdGtESHpzcjQ1MzdkSTZyNG5YYjhiVkR2TlI2WDhiazVPU2VuaDVLYVNnVVVnbG9yRkJx dW93TG8ydDlHWkduV3d6WlFKQ3FBd3N3UTFkMU5WMHB1TEg5OTBhYTFjcTRNTHJXbHhIcjZX YTBhN3llempYZERmR2EyaTdpTlNwc0FrYWFya2xNV2hYcmxIRmhkSzB2SS9KMGkwR2VEcXdo Sm5LcXdvMGVYamI1bmtlZXpyQmhIb2M4UFlZbEVhOVJZUk53bzZiYkJPVHB0Z1Y1T3JBR00y VFFqWnB1ays5NTVPa01HK1p4eU5OaldCTHhHaFUyQVlkb3VyTjlHWXRYN0loN2IxMzFURGFR NGczd3dzU3p1Yy94OFdWTUxKQ25SOU5EbStjMXlOT2pMSW5qYTAyN3lOTmpDZGJUUVV6QWVq cXdCak5rMEkyYWJwUHZlZVRwREJ2bWNjalRZMWdTOFJvVk5nRzdhSHBEUTBOZVhsNXljbkp1 Ym01RFF3T0ZMeVB5OVBpQlBCMVlneGxhYWhkTkh6ZHVuTi92RDRWQ1BwOHZJeU9Ed3BjUmVi cko3U0pQdDZaZHhHdFUyQVRzb3VrbEpTVit2NytucDhmbjg1V1ZsVkg0TWlKUGp4L0kwNEUx bUtHbGR0SDBBd2NPakJzM2poQXlidHk0QXdjT1VQZ3l3cGN4ZnZIT2ZUcUhiQ0R1aWRkdHg5 Y084VkxyZlJrdFp0cTBhWHp0NWZycnI2ZndaVVNlSGorUXB3TnJNRU5MN2FMcG1abVpmTzFs L1BqeEZMNk1XRTgzdVYyc3AxdlRMdUkxS213Q2R0SDArdnA2ajhlVG5KdzhkZXJVTjk5OGs4 S1hFWGw2L0VDZURxekJEQzIxaTZiSEJPVHAwZlRRNW5rTjh2UW9TK0w0V3RNdTh2Ullnandk eEFUazZjQWF6SkJCTjJxNlRiN25rYWN6YkpqSElVK1BZVW5FYTFUWUJCeWk2ZkJseEhNTW4r SExpR2NMbnVITEdCN2s2ZEgwME9aNURmTDBLRXZpK0ZyVEx2TDBXSUwxZEJBVHNKNE96RUNj VkdiSW9CczEzU2JmODhqVEdUYk00NUNueDdBazR1VzRTOU1IQmdaV3JsdzVlZkxrcEtRa1Fn aUZMeVB5OVBpQlBCMllnYnMwZmRXcVZkT25UMjl2Yng4Y0hHUmI0TXRva3p4ZE5SSGRrTWNo VDQ5aFNjVExjWmVtZXp3ZW44K24zQUpmUnB2azZjUE5XQjJRNURvZ0JHQkQzS1hweWNuSmp6 enl5T2pSb3owZXo0NGRPeWg4R1ZYYm44NkpWYnZEalpjN0ZFcldSallRMXR2RTllMkRMeVBp TlNOZTFWbnNjRi9HQ1JNbStIdys1c3Q0OWRWWFUvZ3lxaDV4VEJzSjhuUUFZb0M3OHZUNTgr ZjdmRDdteTVpZG5VM2h5M2psdyt2MXhxcmQ0UmFySmJYRHE0MFE5aldRdU91dFdFK1BZVW5F eTNHWHBuZDFkZjNrSno5SlRVM055OHRqQyt2d1pWUStWTUpxSmNOdHVwYlV4ckczTVFGNU9q QURkMmw2VEhCd25sNGhxS1J0ODNTdTZZbWJ4eUZQajJGSnhNdUJwZzhiQitmcG9xWmJCdkow QUdJQ05IM1lJRStQcG9kaU1UWUZrYWZIdGwwYnhtdHF1NGlYQTAwZkJvNzNaYXdndFhIbzRZ Wmlzb0hVRk5jTWE2K2E0cHJhZVBRMnRsSERseEhQTVg4bUc0aHlDM3dadzRNOFBab2Vpc1c4 WGkvWlFOeVdwN01rSFhsNnJFb2lYZzd5OUdHVFFPdnBaQU1aM3ZYcDhiaVZ0SmJVZGd5cE5W MW1yNFJlVDFkcE9nQ3hBcG8rYkJJb1R6ZlFkTTA4WGRSMEMvSWFwczdHZWJvNFRaR25HMk8z ZU0xdUYvRnkzS2pwSzFldVpLYU0xT20rakxXa05pSHk5TEJKdDRHbUp5akkwNEZKdUU3VDI5 cmFKazJheERYZDJiNk1CcHB1aHp5ZGlacE1uaTdLTi9KMFkrd1dyOW50SWw2T3V6Uzl1N3U3 dUxoNDc5NjlYTk9kNnN2STlLTEMzbm02Z2Fhck1ORDBCQ1hoOHZRRTZxckxjWmVtTDEyNjlN VVhYNlNVY2sxM3FpL2ozS2R6dkY3djhweFZaRmkrakl2WFI5bnVzT0psM29xMXBMWWxaMVV0 cVRXb1RmVXAyOUtTczBxK1hidjU5ckhZRThpWGNkblRzNk9KMSt4eHR0dnhqV084N3ZKbFpQ L2VpRU9kNjh2bzlYcHJTYTNOODNTdjE4djZpVHpkL2lUMGFMc0tkK1hwSEo2bk85V1hrVW1l Z2FiYllUMmRxL21scmlybUl0YlRvMnczNXZIV2xOVEVzRUw3eDR2MWRHUHNxK2xPOVdXOEpI bGVXMStmYnFEcFlrbk5mVTN1b0lrZ1R3Y200VkpOajRaRXlkT05GMTdNeTlPTnBjbzRUOWZM VzVHbkQ3ZGQ1T25XdEd2RGVLSHB3eVloOHZTS2lCYlRvOC9UeVFiQ1ZzbkRacUQ4aXBlS3l3 K0QxTlVaZWJveU9oNXNvcVRxdFlaL1NBRTd3QTRRTkgzWUpFU2VIbGJUVGNyVHVWTHIvUzg2 WGt6VTlGcFN5NzhQVkpleDYybTZxcVFCTW5tY2ZHMURPaU1qYXJSNFBiN3lOZDlpLzd5MXBx U21ZeWk4cHRzd2J6VzFYVnZGQzAwZk5nbmt5MWhCYXU4dnJpSFNqb3cvUGtmbkZPajFldTh2 cnFrZ3RjWStpOFViaW9jSVlTWFpjL0g3eGJXa2xya3RybG16UmxXbldOdWx2VFlVRDEzMk9J emV3UzU2bDBSVlQ1VE9pOHg3a250SmNsOUdzZWN4NzFWTW5tdkRIVk83UGNkMzNPTFNPcHM1 OEdVY05oSGs2WkxyeTVLMXlaU01PRThYMDB6TkpRSlZ2c2xMS3ZOdWcrN3hTeTEvWEhqcElN cUVYVngySDdweUdQbHlEV3VYL1NkVmczRTJ5R3VVRFVXVFQya01GQ0h2bnlxNXRJVVE1WHFS UVo2dS9NZzQ4VGNJeDR3OFhXYXhLKzU1cTNKbVd0Q3V3ZThsZXNXTWw3Q1FwOGVCQ05iVEkx ZzJsU3l2Vnl5eXhYU3laTThRdWFLcm9yaUlpcU44aE5WMHhoWEZPb2hLMDFYWHdOVHkyb2hh MDlueUMxK0gwUnRuWmVjTlFsQlZvaG9INDZPZ1hFM1NmS3U2REYvVjZKWFZhV2k2ekJReWRi M2JnaDh3WXRKL0EwMDNkWHprMnpLdkc5RDBDTkhVZEhFMFdmN0lQOVhMdlBqNnNuR3hrZzBs eHZteXF0MncycTJYcHlzbGlXd2dKUnRLaGdoaE9lWVZIUk4wcDJSRFNlMlYwcXdYTDlsQVZC azZleWczOG5pSCtEVThWOG9mMTNUVzdxV1BpTWJvc2RkelZ1YW94NWFvQTJHMXNYZzFLeEhI V1huVXZGNnZNbkRXSzdZTXJkUjAxVjZzdlBMNEtvZmE2L1dxZ2xLT2pBcmxlamR0YXhPbmls NFVNdkpuUVo2dXVWNHZuN2VTeTM4UDhkcFVVWGk5WHRYZm5RYnlLaCtJYWdBMWExWVdNOVow cFc2b1VQYmM0UGlLQjlvTUdiU0xwdGZYMXhjV0ZxYW1wcGFXbHJhMHROQklmUm5GNFl2eUlV cWtaaG1aWXBkcTZ4ajJsZWxzbDRyTDBzTTh6VlcvWWZLUEtraHR4eERoWlhoNVBVMVhQcmoy R1dpNk10NEtoYWIvdU1iaUpVUGVIMXV2VUNxbVlwVkRiSjExbTRVd1JJZ3lMakZleWNPbkdp dldnUXFkQjZ1V0tRNkxqbTNodncrTHFUM3Z0bkUzVkIzbW9zYUhYWFhDS3dlRVhQbE5veXBE cnZ5YlEwOUVOQ3ZSSzhEalZmVmZUOHYwWk91S2FhOFlCREdyRUErb2NraFZhaXQ1NkRXNkpI ZVNSdjlRTmFRM1hSMnU2UTg4OEVCN2UzdDNkL2VtVFp2WWZmK1IrVExXQ2ljOGt4disxdXYx dm4rcWhGMyt3US9BajFwREx1VmZRNFN3OUVlcElGeHJPb1orVE5QV3JGbkRGWUh0eUI2c0dL dVFGVDVWVXZLalVBNHJUNytzNmNySC9TVTFldHFrV1pLMU8rUWxReDJLMVFaRlJzeTZwMUx6 UzNzcFpMM21jcnRNZkpYS2UybVFMMzhOOEpMOFU2Nm5iRURZTTgzSk1kQlp2WGlWM3l0SzVX VUw1V0hsVzI4QTJZSGpoN3VDMUo0cUtSRy9uelFmYkY2cGpydHlickF0YzFibUtLY2ZENEh2 eURieXc4Ry9EbGwwckJpZnQwT0VzRUNVKzdKaUZmeGZtaERpOVhyNW4wMnNKQ3ZEZXNnRmxJ MWU3WldUbWJ0RXFDUkovRHRNZVI3eEhoNXZ5eEVIdHZieWFQTXZTOTV1N2VWanAvd2VWWjdD YTlhc3FWVk1BSFdaY09rQUFDQUFTVVJCVlBacDdlV3JzL2c0c3dGa0pWVzVnbkpmZm54NVo3 Z3hCZytmbjcrcUFWVEd5N2ZUbkJ6ZUJHOVhWSGIyVjRzWldtb1hUZWVjT0hIQzQvSFFTSDBa SldVdWpvK3dtcTZkcDErWkxFZmVya1JWUTFjS3V2R095aStiUzJkNExIb2I1Mk9rMEhRODhJ aitvVnlsNUJ0ZG9lbW5UcDBxTHkvZnVYTW5qZFNYY1huT3FncFNhL3o4L093L2hTMnpQR2ZW L1NVMU1heU5sNXo3Umc3cElIUGZ5Q0h5dm93ZFpPNGJPVEZydDRNWXhEdDB1WXplczZwZHNU YmVXOGtlVnVVOFo4WTRSM044NXo2ZDB6RkVUR3JYaHZHYTJpN2lWYzRyNVJhSCt6SlNTbHRi V3owZXo1WXRXOWpieUh3WksrTDloUnoyOFdQYU84dzhmY2diVmVZb21hZnJaZWg2KzJwdVNm UThYV1l0Q0E4OGh2dmdhMktYM2pvN1Q2K3VyczdPenQ2OWV6ZmZFcGt2bzh6SVNxNUV4N1pZ eFpYcjJnYWFycjJlTGdqbC9TVTF2SUJ5dStiSysxQzRKUlNON3VrOGxQSHFxVHpieU5vTisx VlVsZk9jR2VPc1BwMnUvRlZBcGtJMmtsRzJhMDI4UXhKZm9pYk41d2ppMWV4dHpOdTFUN3g2 RDRkck9ybVNpeGN2UnVqTEtKeTZvc1pwYm1SWGE0Z2JsU1V2WGE4dDdDc0txMEc3VjBpazhx MU9lbTdHWStqeVF5TmVpVHlkeDZ2VWRENTZ5bFo0QWQ2VzVsaXBlc0xlaW9majBuWDYzdkRI VjJQZks3OStyaGp6eXk5VTErT1R5ejlOODdtaG1neWFFMGExVVc5ZWlmSHF6VW4xNElRTHpi aGRaVzI2N1dyT0RTMGhGa3ZxelN2bHdMSzNlcU1uRHFETThkV04xeXNScjhReDBqdm9tdnVx bWhpNjhoVDRjYnV6TlQwbVBQWFVVektLVnZKK2lmWEY1RXZPZVhDald1NHRhVGY2WWt3eWRF dnFSSFFwWHN2SDJhQ1lVaXRqZjN6cmNvd0hoRzIvb2piK3hSTk52Q3QyR0JXNC9QV20wYTZx REM5NXVjSkxxWURlOGVYeEdqU3RHWVZtNjhwQVlqSXNjck0wa3VNclZGdWhOTm51Y00xMUw5 RWdxZWw0NEdIOHFKQllnOElEaitFK1ZQTUttaDRlaCtUcFlmTWFjOXBGdklnWDhWb1dMNEdt RzhOOUdVa0hLWDYvR005NHhqT2ViZjRNWDhid0lFOUh2SWdYOFNaRXZBUjV1Z3hZVDhjRER6 d1M1UUZORHcveWRNU0xlQkZ2UXNSTG9PbFUwcGRSYmpUeHdBTVBQT0w3NEpwZS8rQ0QzMy8x VmF4ME1wRTBYY2FYVVdZb25mRTk3N2E4QnZFaVhpZkZTeFNhN3ZWNDFreWYvc0ZMTC9WMWQw ZXZrNG1rNlRLK2pKS2ppUWNlZU9BUjM0ZFMwOWxqdy8vNVAzOTc1NTBvZFRLUk5GM1RsL0hv MGFOUFBQSEVpbVhMSHJ2dnZ2OTc2NjJQTDF6NHhCTlBHRC8vN3Y3N3c1WjVmT0hDMy96bU56 R3NUYjVrMVM5K0VaZDJFUy9pUmJ5V3hmdjR3b1ZNdFpiLzlyYy9hdnF0dC81dHo1NG9kVEtS TkYzR2wxR21uaSsvL05MNll2SWx1OTkvUHk3dElsNXIya1c4MXJScjgzaVZzTFdYOS8vOFo5 ZXR2Y2o0TXNyVTA5UFRZMzB4K1pJWE5tMktTN3VJMTVwMkVhODE3ZG84WGlYMWl4ZC8zOWs1 M0wzMFNDUk5sL0ZsdEw1WE1hZi83Tmw0ZDhGU0VLK3pRYndXazBpYUhwYjJXUC9IRUFBQVND d2NwZW1KQWlFazNsMEE1b0pEN0d6c2ZIeWg2U2JDL3IvSHFGR2pwaytmL3R4enovWDM5eHNV VTg2Uyt2cjZ3c0xDMU5UVTB0TFNscFlXWldIeHhxdXd0MklCa3lDRS9OZC8vUmQvK3gvLzhS OTZwL3F3amhvT3NVMlFQNzYyT29XaDZTYkNqbkZ2YisvSEgzOTg0NDAzL3R1Ly9Wdll3b3dI SG5pZ3ZiMjl1N3Q3MDZaTnFpdDh4QnV2d3Q2S0JVeUNFREo3OXV6QndVRkthVzl2YjJscHFk NDVQNnlqaGtOc0UrU1BMeS9QWDhmeEZJYW1tNGp5R0hkMGRGeDc3YlhpZHMzQ25CTW5Ubmc4 SHVXbjRvMVhZVy9GQWlaQkNQbmpILys0WThjT1N1bm16WnVmZU9JSmZwaFVSMVBtcU9FUTJ3 MzU0MnV3MGZwVEdKcHVJc3BqM052Ym01S1NJbTdYTE13NGRlcFVlWG41enAwN2xSdkZHNjgw YjhVQ0ZrQUlPWDc4ZUVWRnhlRGdZR2xwNmNtVEovWE8rV0VkTlJ4aW15Qi9mUFUyeHVVVWhx YWJpUElZSHoxNk5DY25SOXl1V1poUzJ0cmE2dkY0dG16Wm9pb20zbmdWOWxZc1lCTHNrTjEz MzMyLy8vM3ZmL0dMWDFERlFWUWR6V0VkTlJ4aW15Qi9mRFUzeHVzVWhxYWJDRjlQUDNUbzBP elpzL2w2ZXRnSlVWMWRuWjJkdlh2M2JyR1llT05WMkZ1eGdFbXdRL2IrKys4VFF2YnQyMGYx ei9saEhUVWNZcHNnZjN6RmpYRThoYUhwSnNKK0NoODVjaVM3N3FXdnI0OXZGNHNwZnpwWGJi bDQ4U0xmUmJ6eEt1eXRXTUFreEJOYjc1eVhPV280eEhaRC92amE2aFNHcGdNQWdIT0FwZ01B Z0hPQXBnTUFnSE9BcGdNQWdIT0FwZ01BZ0hPQXBnTUFnSE9BcGdNQWdIT0FwZ08zWTJ6TUJF QmlBVTFQWUhwNmVwWXRXM2IxMVZlUEhUdjIrZWVmajNkMzdBNGg1SVVYWHFDR3BxbUEwOTdl VGdqQi81bVJ3VlpUQzVxZXdDeGZ2dnkrKys3NzVwdHZ2di8rKzBjZmZUVGUzYkU3aEpDQ2dv TEJ3Y0hwMDZmSC9jU3pQMnZXckJreFlzU2FOV3ZpM1pFRXdGWlRDNXFld0V5Wk1rWDF2OHlW ODBsNUgvUHk1Y3ZUMDlQTHlzckVZdTZCRUhMTExiZXNXclhxMWx0dlZRNk9hdEJlZnZubDhl UEhaMlptYnJyOHo0TGRPVngzM0hISGd3OCtlTWNkZDdDM1pXVmw3SDg3TkRjM3o1dzVrMUxh MXRaV1VGQ1FscGEyWXNVS1l5TVV4eU5PTFRhdlVsSlMrUC9FK1AzdmYvL3JYLythVXZxclgv MXF5WklsZk1lWWR3YWFuc0FrSnllci9uZVNucWEvOE1JTGdVRGdvWWNlc3JSL05vTVE4c1li YjR3WU1XTHIxcTJhQThWZXIxKy9QaGdNTmpVMXVka0JNUkFJakJrejVwdHZ2aGt6Wmt3Z0VL Q1VybDI3bHY4RGgzWHIxbEZLUzBwS05tN2NHQWdFTm0zYTVFNHA1K2hOcmY3Ky9uMzc5azJh TklsUzJ0ZlhkK2VkZC83aEQzKzQ4ODQ3dWZXVEdVRFRFeGlEUEwydnIwK3A2YjI5dlZaM3pu NFk2TGp5dFo3Vm1xdG9iR3prL2xPTmpZMlUwblBuem1Wa1pIejU1WmNaR1JuZmZmY2RwVFFs SlNVWURGSktnOEdnbThlS2FrMm45ZXZYZXp5ZUVTTkdFRUtTa3BMWVIyMXRiWVNRdHJZMlV6 c0RUVTlncXFxcTdydnZ2bE9uVHAwL2Y3NnFxb3BTT21IQ2hOMjdkM2QzZDIvWXNNSGxmdzZM U0dxNjVtdTNzV1RKRXZhcisvUFBQODhYQ2lvcksyKzQ0WVo1OCtheHQ4WEZ4WC85NjErRHdl Qi8vdWQvdW5tc3FOYTBTVXRMYTJwcUNnYURQcCtQYlFrR2c2V2xwWGZmZlhkcGFXbDNkN2Q1 bllHbUp6Q2hVT2poaHgrZU1HRUN2KzZsdXJvNkl5TmovUGp4NjlhdE05QjBkNTZCNG9tbmFa RXFsbmZoY09YbDVSMCtmSmhTZXZqdzRieThQTGF4dWJtWkVOTGMzTXpldHJhMjV1Zm5wNlds UGY3NDR5TkdqR0FiWFRoV1ZHdmFQUHZzc3hrWkdSa1pHYXRYcjJaYkZpMWF0R0RCQWtycFAv L3pQeTlldkZqY01WWkEwd0VBa1RNd01QRFdXMjlObno0OTNoMEJsNENtQXdBaWhDMFc1K1hs L2ZkLy8zZTgrd0l1QVUwSEFBRG5BRTBIQUFEbmtCaWE3czRmWGdBQVlMZ01UOU9KRHBvbGs1 S1Nycm5tbWovODRRL3NJbFlyNmV6c3ZPbW1tMGFPSEhuVFRUZDk5ZFZYRnJkdUdlTDROelEw ekpneFkrVElrZVhsNWUrOTl4N2JrcGVYbDV5Y25KZVh0MzM3ZHMxNkdob2FQQjVQYW1ycWpU ZmVlUHo0Y1VycGxpMWJycnZ1dXRUVTFKa3paKzdkdTllYWNNeEdIQzV4U3lnVWV1U1JSN0t6 cy9VbU50VWFaT056SVJIUkM4ZnI5ZktONHJTUnFVYzVWbGxaV1NiMTMyTEVLU0ZLa0l3b2ll ZWR6SVJVTVh4Tjd4QWVPcG8rT0RoNDh1VEorZlBuLy9HUGY1VHBTZ3laTzNmdWloVXJ1cnU3 VjZ4WVVWbFphWEhyRnFNYy84ckt5bzZPamxBb3RIMzc5b2tUSjFKS016SXlkdTNhRlFxRi9I NS9Sa2FHWmcxWldWa3RMUzA5UFQwK24rL25QLzg1cFhUdTNMbUhEeC91N3U3ZXNtV0x3MjZu Tkw2eXM2cXFxcXlzcktPalkzQndVSzhHY1pBZEkrVXFWSEY5OHNrblRGellXM0hhU05iRFdM Smt5Wk5QUGhuRDNzWVJjVXFJRWlRalN1SjVKek1oVlppbzZlekZ5Wk1uMmEyeEgzNzRZV0Zo WVVwS1NtRmg0WWNmZnNqSy9PTS8vdU84ZWZOeWMzUFpqUXpzdTBocGtzQTNLbXNXSFRsVVpH VmxuVDU5bWxKNit2UnBoMG1TaURqK3dXQ3d2cjZlWFY1V1dscmEzTnpjMDlPemUvZHVadE1o a3BXVnRXZlBIblp5amg4L1h2blJ5Wk1uVTFOVG5YUWJxckdtVDU0OCtkMTMzNVdwUnpuSWhK Q01qSXowOVBTZi92U25KMDZjaUdGdjQ0dnFMNWlpb3FMWFhudE5xZWw2MDhhZ0hzYjMzMytm bVpuWjFkVVY4ejdIRWVXVUVDVm9XS0xFenp2NUNja3hYZFA3Ky90VFVsSW9wUVVGQmErKytt b3dHS3l1cmk0c0xHUmx1Si9ubURGaitMNUtrd1JWYlZUT2tXUEVpQkVEQXdPMzNISkxmMzkv Y25LeXpFQWtMcXJ4NTMvVkhqeDRrRkxhMnRxYW1abEpDTW5Nek5TN0tibXVydTdhYTY4ZFBY cjA0NDgvcmh5dWI3Lzl0cUtpd21HT2o4YWFucHljdkdMRml2VDA5SnljbkczYnRobFVvaHhr eHRtelo2dXFxbTY2NmFhWTl6bGVLRWZtc2NjZSs4VXZmcUhjcURkdGpPdGhyRjY5bXQyQTR4 aFVVMEtVSUhsUlVwNTNraE5TaVhWNWVuSnlNbHRZRHdRQ1RPV0o0czQ5b20rU1FBVk5EK3ZJ a1pXVmRlYk1HZXJXUEQwUUNHemR1cldvcUloU21wK2Y3L2Y3UTZHUXorY3JLQ2d3cm1ydjNy MVRwa3hocnc4ZVBKaWJtN3RpeFlxQmdRRXp1aDB2akRVOU16UFQ1L1AxOVBTMHRMUVlyL1lx QjVuVDNkMmRtcG9hdzk3R0YrWElzTE5TYzUxZE9XM0Mxa01wN2V2cnk4bkpNZHYyeEhxVVUw S1VJRWxSVXAxMzhoT1NZKzU2K3RkZmYvM0xYLzZTK1VWbzV1bXFaOUVrZ2RjVzlyV1MrKysv Lzhrbm53eUZRazgrK1NSTExoeU1jaEFXTFZyVTJka1pDb1hxNit2Wm44UGp4bzN6Ky8wOVBU MjdkdTNTVzArbmxBNE9EaDQ5ZXJTa3BJVDV4dFRVMUZSVVZMQWxNb2Rock9uMzNuc3ZQNFgw VGp4eGtCay8vUEREcWxXcktpb3FZdC9wT0dHY3JsRmgya2pXVTFkWE4zdjI3RmgxMGc2SVUw S1VJQmxSRXM4N21RbXB3a1JOVDBwS21qaHg0dTkrOXp2bTFibHYzNzZDZ29MazVPU0NnZ0sr bnE1NkZrMFN5SlZRT1UwL2NlTEVyRm16MkMveW5aMmRNZ09SaUlpRFUxdGJtNXVibTVLU1Vs UlU1UGY3S2FWMWRYWHNUNStwVTZmVzE5ZnpIY1Y2c3JPemx5NWRHZ3FGeEpvdlhyeG9lWEN4 UjNNdXFiWWNQMzU4MXF4WktTa3BIbytub2FHQjc2aXNSeHhrdHZ1b1VhTnV2LzMyenovLzNQ TElZbzg0TXNxUGxHV1UwNGJxVEMxVlBiTm16WkpjUmtnVXhDa2hTcENtS0JrUDE4V0xGelVu cERGbVhjc0lBQURBZWhMam5pTUQ4QVVEQUFDY2hOZDBBQUFBSEdnNkFBQTRCK3MwWFdaVkJD c25BQUFRRGRiOVJocERUWWYweXlCemRQUThLSlMySG01QXhvdERMQ1BqcFpQUWlHWWpNa1pB WWhtSC9kWWxoaVBPQkwyQk1qNnpZdUs4Tkh4Tlg3SkgvWUNtMnhqanNkTDBvRkRaZXJnQlNT OE9WUmtaTDUyRVJqUWJrVEVDMGl2anNCbWxERWVjQ1pxREVQYk1pb256a2xtYWZ1alFvWmt6 WnlZbkp4UEYxYXdxbjVhalI0L2VmUFBOcWFtcDA2Wk40LzUybE5Lelo4L2VkdHR0bXpkdnBq b3VNYXJ2U2JHZVdiTm1zZithNkx5N0c0YUw4WWtrZWxDSXRoNXVRTWFMUXl3ajQ2V1QwQmlZ amNnWUFhbktPR3hHS2NNeG1BbDhFR1RPckpnNEw1bWw2U1VsSmV2V3JlTjNJbEF0bjVieTh2 TFhYMzg5RkFydDJyVnIyclJwckV4SFIwZFpXUmszOEJMdlBxWEM1QkRyMmJwMUt6TUZLeTh2 Mzdselo5aTRISXp4aVNSNlVJaTJIbTVBeG90RExDUGpwWlBRNkptTnlCZ0JpV1VjTnFPVTRl ak5CT1VneUp4Wk1YRmVNa3ZUVTFKUzJPMmp5bjFWUGkwcEtTazg0MmJ1TG9TUTB0TFM3T3pz OXZaMlZsSjBpYUhDb0lqMTlQWDFYWGZkZGR1MmJTc29LSkQzcUhRa1lmTjBsUWVGZ2EySGc1 SHg0aERMRE10TEp4SFJOQnVSTVFMU0xPT3c2YVFNUjNNbXFBWmhXR2RXTk01TFptbDZjWEh4 dW5YcmVucDZsUHVxWGxkVVZEUTJOblozZHl1M256bHpac2VPSGJtNXVlenZYTTA4ZmVUSWtV cEhVN0VlU3Vuenp6K2ZucDZ1WjhickhveG5qNEVIaGNQT1FHTmt2RGpFTXBKZU9vbUxhRFlp WXdTa1Y4WmhNMG9aampnVERBYktlQnlpZDE0eVM5TS8vdmpqMHRKUzl0VWtSc0plSHp0MjdQ YmJiMDlMUytOZlhMeE1UVTNOckZtemdzR2c2QkpES1YyMmJCbmJpNzBWNjZHVS92M3ZmOC9L eXJMK1h5elpCM0lsZktPeWpJRXhqc1BPUUdOa3ZEakVNcHBlT2s1Q05CdFJUU3BtQktRYUtM R001bFJNWE1Sd3hKbWdPVkI4ZDgzWGZLOG9uWmVjNmZjeU1ERHdsNy84WmRteVpmSHVDQUFB V0lvejd5TWxoSlNWbGJIVkd3QUFjQS9PMUhRQUFIQW4wSFFBQUhBTzhIc0JBQURua0pCK0ww QWVHYjhJMGNsRXh2L0VrY2hNYVF3WFEyYXNSQU1UY1l1ckNPdjNvdktOaVdDNGhxM3BRMTcx QTVwdVp5UU5PbFJPSmpMK0p3N0dlQjVpdUpRWWo1Vm9ZQ0p1Y1E5aC9WNUUzNWdJaHNzc1RU ZlA3NFU3QnpRM056dlNaTU1rRFB3aVJDY1RHZjhUQnhOV3B6QmNuTEJqcFRJd01iQTBjVFl5 ZmkraWIwd0V3MldXcHB2bjk3SjI3ZHI1OCtkVFN1Zk5tN2R1M1RxWklJR3hYNFRvWkNMamYr SmdqSFVLdzZYRWVLeEVBeE05U3hQSEkrUDNJdnJHUkRCY1ptbTZlWDR2NTg2ZHk4akkrUExM THpNeU1yNzc3anVaSUYxT1dMOEkwY2xFeHYvRXdZVE5QVEZjSE1uMVVxV0JpZDRXWnlQajky TGdJQ1EvWEdacHVxbCtMNVdWbFRmY2NBTnpYZ1RHeVBoRmlFNG1NdjRuRHNaWXB6QmNTc0px dXNyQVJIT0xxekFZTVUwSG9lRU9sMW1hYnFyZlMzTnpNeUdFT2FRRFkxUlhLR2thZEloT0pn WStNTTVHODRJdURKY21NbVBGUGhJTlRKUmIzSWFvaEJ3OTM1aGhEWmN6L1Y0QUFNQ2Q0RDVT QUFCd0R0QjBBQUJ3RHRCMEFBQndEbVpwT2hiWkFRREFlc3o2alJTYWJoUGc5eklzWkg3Mngz QXhaS1pXUTBQRGpCa3pSbzRjV1Y1ZXp1NFZENFZDanp6eUNMdEYzc0VxSVU0a3BXRHlmKzZx aWRJVEpvS3BOZnhyR1R2VUQyaTZuWUhmU3dRWXoxNE1GME5tYWxWV1ZuWjBkSVJDb2UzYnQw K2NPSkZTV2xWVlZWWlcxdEhSNFlaLy9xNDVrWllzV2ZMa2swL3E3YUx5aElsZ2FwbXI2VXJu RnRIZFplM2F0UjZQaDNuQzREdkFiT0QzSW8veGJNUndxVENZV294Z01GaGZYejk5K25SSzZl VEprOTk5OTEwTGV4ZFB4SW4wL2ZmZloyWm1kblYxYVpZWFBXRWltRm9tYXJyS3VVVjBkeGt6 Wm96WDYrM282RkRlYmdyTUFINHZ3OEpZMHpGY1NveW5GcjI4NXBDVmxYWHc0RUZLYVhKeThv b1ZLOUxUMDNOeWNyWnQyMlpoVCtPQU9KRldyMTY5WU1FQ3ZmS2lKMHdFVTh0RVRWYzV0NGp1 TG0rLy9mWTk5OXd6YmRxMHNXUEhQdlBNTXpMZEJSRUF2NWZoRWpaUHgzQXh3azR0UmlBUTJM cDFhMUZSRWFVME16UFQ1L1AxOVBTMHRMUVlMeXM3QU5WRTZ1dnJ5OG5KWWVaY21vaWVNQkZN TFJNMVhlWGNJcnE3TUFZR0J2YnUzWnVlbmk3VFhUQmM0UGNTQWNhYWp1Rml5RXl0UllzV2RY WjJoa0toK3ZwNlpoVjc3NzMzY2sxMy9QY2ZFVzc5bnoxNzlyQjJqR0JxbWY0YktYZHUwWFIz SVlRd2M0T05HemZLZEJjTUY5VVZTdkI3TVVZMVhIeWpzZ3lHaXlFenRXcHJhM056YzFOU1Vv cUtpdngrUDZYMCtQSGpzMmJOU2tsSjhYZzhEUTBOOGVtNitXaE9wRm16WnFtV20vU3lCNzQ5 Z3FrRnZ4Y0FBSEFPdUk4VUFBQ2NBelFkQUFDY0F6UWRBQUNjZzlXYXJseDh4MEk4QUFERWxu aitSZ3BOanptaW1VWkRRME5lWGw1eWNuSmVYdDcyN2RzMTkycG9hUEI0UE95MzllUEhqMnZX NHhKa1BFekV3WEdEMzRzWXRWSUI5SzQwRjZlZnpJUjBBT0k1SlROSlltSWxOR3hOcnlDMXFn YzAzVDZJWmhvWkdSbTdkdTBLaFVKK3Y1Ly9oME1WV1ZsWkxTMHRQVDA5UHAvdjV6Ly91V1k5 TGtIR3cwUWNIRGY0dlJoTUNRTURFM0g2eVV4SUJ5Q2VVektUSkNaV1FpWnFPaUZrK2ZMbDZl bnBaV1ZsZkl1NDltTHNDYU5aRDlCRE5OTW9MUzF0Ym03dTZlblp2WHYzekprek5mZkt5c3Jh czJjUG0zL3N4aEJYbVhKb1l1QmhJZzZPRy94ZTlLYUVzWUdKT1Axa0pxUURFTThwbVVrU0V5 c2hjelg5aFJkZUNBUUNEejMwa0hLajhuVllUeGk5ZW9BbW9wbEdhMnRyWm1ZbUlTUXpNMVB2 cHVTNnVycHJyNzEyOU9qUmp6LytPUE9VY0pVcGg0aXhoNGs0T0c3d2U5R2JFc1lHSnVMMGs1 bVFEa0E4cDJRbVNVeXNoTXpWZERITlVXbDZXRThZdlhxQUpxS1pSbjUrdnQvdkQ0VkNQcCt2 b0tEQWVQZTllL2RPbVRKRnN4NzNFTmJEUkJ3Y04vaTlhRTZKc0FZbTR2UWIxb1IwQVB5Y2tw a2tNYkVTTWxmVGpUY1NPVThZTEx2TEk1cHBqQnMzenUvMzkvVDA3TnExeTJENWNuQnc4T2pS b3lVbEpWVlZWWnIxdUFRWkR4TnhjTnpnOTZJNUpjSWFtSWpUVDNKQ09nRFZPU1V6U1dKaUpX U2Rwb3VYeXZBQ0JwNHdZajNBQU5GTW82NnV6dVB4TUZPZCt2cDZWa3p6MEdSblp5OWR1alFV Q21uVzR4SlVzMVRUdzBRY0hEZjR2V2hPaWJBR0p1TDAwNXlRemtNOHB6UW5pV3E0WW1JbEJM OFhBQUJ3RHJpUEZBQUFuQU0wSFFBQW5BTTBIUUFBbklOMW1qNnN5MlA0UjhicjlWaktCd0FB SmRiOVJocXgva0xUbzBIR3VRVitMeHlaV2ExbndlSDFlaDA4VnVLd05EUTB6Smd4WStUSWtl WGw1Znl1YnhYaVdEblM3MFcwQ1JJbmt1U1pxQnFjQ0s1REdiYW0xNUphMVFPYWJtZGtuRnZn OThLUm1WR2FGaHlmZlBJSk8xM043Vis4VVFaWVdWblowZEVSQ29XMmI5OCtjZUpFemZMaVdE blM3MFcwQ1JKbmdzdzVwVGM0dHREMHRXdlhlanllNU9Say9pVkRDSG41NVpmSGp4K2ZtWm01 YWRNbVhxRnlkejIvRjJYTnJhMnRCUVVGYVdscFZWVlY3Q094TGNDUmNXNkIzd3VIRUpLUmta R2VudjdUbi83MHhJa1RtbVZFQzQ1UUtGUlVWUFRhYTY4NWZ2cUpBUWFEd2ZyNit1blRwMnVX RjhmSzJYNHYzQ1pJbkVneTU1VGU0TmhDMDhlTUdlUDFlanM2T25wNmV2aSs2OWV2RHdhRFRV MU55bHNUbGJ2citiMG9hNTR4WTBaTlRVMHdHSHpsbFZmWVIySmJnQ1BqM0FLL0Z4Vm56NTZ0 cXFxNjZhYWJORDhWTFRnZWUrd3hkbytmMnpTZFpWRlpXVmtIRHg3VUxDK09sWVA5WGtTYklP VkVram1uOUFiSEZwcis5dHR2MzNQUFBkT21UUnM3ZHV3enp6ekQ5dTNyNnhPN3FIeXQ1L2Vp ckRrbEpTVVlERkpLQTRFQSswaHNDM0NHNWR3Q3Z4ZE9kM2QzYW1xcTVrZWlCY2VJRVNPRysv TlNnaUpHRndnRXRtN2RXbFJVcEZsZUhDdW4rcjNvMlFUeGlTUnpUdWtOamkwMG5URXdNTEIz Nzk3MDlIU3FyK1BLMTVwK0w1TW1UVkptQVVWRlJTeFByNjZ1VnU2cmJBdHdKSjFiNFBlaTVJ Y2ZmbGkxYWxWRlJZWG1wd1lXSE00V2RIcGxnSXNXTGVyczdBeUZRdlgxOVd6SlRrUWNLMGY2 dmVqWkJDa25rc3c1cFRjNHR0QjBsckF3VjRlTkd6ZFNMUjBuVjBJcDFmUjcrZXRmLzVxZW5z N2Y3dCsvUHo4L1B5MHRiZm55NWNwNmxHMEJqcVpOaCtaZjBQQjdvWmVIWXRTb1ViZmZmdnZu bjMvT055ckxHRmh3T0ZqVHhiTzF0clkyTnpjM0pTV2xxS2pJNy9mellzcTl4TEZ5cE4rTGFu QXVYcndvVGlTWk0xRWNISEhZd3dLL0Z3QUFjQTY0anhRQUFKd0ROQjBBQUp3RE5CMEFBSnlE M1RVZGkvVUFBQ0NQM1g4amhhWkhpZWhFSVNLYWN1aFptamdlbVNtTjRXTElqSlZvSmVSSXZ4 ZDVqRTJCeE1FUkJ6QXN3OWIwamlIMUE1cHVaMFFuQ3MweUtsTU9UVXNUOTJBODZ6QmNTb3pI U3JRU2NxVGZpeVJoVFlIRXdSRUhNQ3htYWJxbTMwdFZWVlZhV3RyMDZkTmJXMXNwcFI5KytH RmhZV0ZLU2twaFlTRzdYUC9Rb1VNelo4NWtlL0VXS2FWbno1Njk3YmJiTm0vZUxCTVMwSVE3 VVlnZmlhWWM0aFpYRVZhbk1GeWNzR09sc2hKeXR0K0xBVEttUU9MZ2lBTVlGck0wWGRQdnBi cTZPaGdNMXRUVUZCY1hVMG9MQ2dwZWZmVlZka2RvWVdFaHBiU2twR1RkdW5Yc3RwY2ZXK3pv S0NzcmEybHBrWWtIYUNJNlVTZ1JUVG5FTGE3Q1dLY3dYRXFNeDBxMEVuS3czNHN4TXFaQTR1 Q0lBeGdXc3pSZDArK0YrYlFFZzBGbWdKQ2NuTXlkVzFKU1VpaWxLU2twZ1VCQTFXSnBhV2wy ZG5aN2U3dE1QRUJFejRtQ0k1cHlpRnRjUmRqY0U4UEZrVndkNVZaQ1R2VjdDWXVNS1pEQjRQ QUJESXU1NitrcXZ4ZVdsZGZVMU15WU1ZTnE1ZW5GeGNYcjFxMVQyaXNTUXM2Y09iTmp4NDdj M0Z6MjV5MFlGbnBPRkVwRVV3NERTeE0zWUt4VEdDNGxZVFZkWlNYa1NMK1hZV0V3WXBxRG94 ckFzSmlsNmV5N1NPWDN3dGJUOC9QejkrL2ZUeW5kdDI5ZlFVRkJjbkp5UVVFQkU1MlBQLzY0 dExTVWZhR3A0cStwcVprMWF4Ykw2NEU4cWl1VUxsNjhTQ1ZNT1F3c1RaeU41Z1ZkR0M1TlpN YUtmYVMwRW5LazM4dXdVQTZSYXJqMC9GNlVBeGlXQlBqZmRRQUFBQ1NKLy8rWUJnQUFFQ3Zz Zmg4cEFBQUFlYURwQUFEZ0hPeW82VmlsQVFDQXlERHhOMUpJc3gxb2FHaVlNV1BHeUpFank4 dkwzM3Z2UGMweU1ERGh3QjVISHBteDByTXJNYlk5Y1RCaC9WNVV3eVV6eUNxR3JlbER3Z09h Ym1jcUt5czdPanBDb2REMjdkc25UcHlvV1FZR0poelk0OGdqTTFhYWRpVmhiVStjU3RqQXhl R1NHV1FWWm1tNlpoWlBDRm0rZkhsNmVucFpXUm5WOG52aE84cDBIY2dUREFicjYrdW5UNSt1 K1NrTVRFUmdqeU9QOFZpcDdFcGtiRThjaVV6Z0J1NHVCb09zd3RJOG5SRHl3Z3N2QkFLQmh4 NTZpR3JkUjZxM0k0Z0c5aldabFpWMThPQkJ6UUl3TUZFQmV4eDVqTWRLdEN1UnNUMXhKREtC NjdtN0dBK3lDcXMxWGZrOUkvcTk2TzBJb2lRUUNHemR1cldvcUVqelV4aVlLSUU5amp4aHg0 ckQ3VXBrYkU4Y3liQUNWN3E3eUE4eXcwUk5Iemx5NUlrVEoxUzdLOThpVDdlQVJZc1dkWFoy aGtLaCt2cDZQYTlPR0pod1lJOGpqOHhZVVgyN0V0ZWU1c2FCcTRaTGNwQ1ZtS2pweTVZdFMw dExVNjJuS3d1SWZpOFJXQTRBWTJwcmEzTnpjMU5TVW9xS2l2eCtQOXVvR2xzWW1IQlVNeEQy T0FiSWpCWDdTTk91eExVbnVJRWtpc09sT2NqRzJQMS8xd0VBQUpESGp2Y2NBUUFBaUF4b09n QUFPQWRvT2dBQU9BZTdhem9XNndFQVFCNjcrNzFBMDZORTVuZHNHSmh3TUZ6eXlJeFZRME5E WGw1ZWNuSnlYbDdlOXUzYkpmZHlBR0tZa3NPbDhudUpZTGlHcmVsZUFXaTYvVEVlUmhpWXFN Qnd5V004VmhrWkdidDI3UXFGUW42L1gvbmZSMTF5WG90aEdnZXVhWThUZGk4VlptbTZtTVVU NGFyTXNyS3lscFlXU21semMvUE1tVE9wbGdNTUszbjI3Tm5iYnJ0dDgrYk44b0VCSldGbkVn eE1sR0M0NURFZXE5TFMwdWJtNXA2ZW50MjdkN056WEdZdnh4Q0JwbXY2dmRoQzA4VitpSnEr ZHUzYStmUG5VMHJuelp1M2J0MDZxblZuS1NHa282T0RxeitJRE9NNUFRTVRGUmd1ZVl6SHFy VzFOVE16a3hDU21abloxdFltdVpkakdLNm02L205MkYzVCsvcjYyT3R6NTg1bFpHUjgrZVdY R1JrWjMzMzNIZFZ5Z0NHRWxKYVdabWRudDdlM3kwY0ZWSVRORG1CZ29nVERKWS94V09YbjUv djkvbEFvNVBQNUNnb0tKUGR5RE1QVmRJN1M3MFYrTDRhSm1xN3llNWt3WWNMdTNidTd1N3Mz Yk5qQWQ2bXNyTHpoaGh2bXpadkgzbXJtNldmT25ObXhZMGR1Ymk3Ny9Nd0ZwZ0FBQ0haSlJF RlU4eFpFZ1BHY2dJR0pDZ3lYUE1aak5XN2NPTC9mMzlQVHMydlhMcXluYTI1Um9XbVBZeGRO Vi9tOVZGZFhaMlJrakI4L2Z0MjZkWHhqYzNNeklhUzV1Wm05MVhTQVlSL1YxTlRNbWpXTFpm RkFIbklsZktPeURBeE1PQmd1ZVdUR3FxNnV6dVB4akJneFl1clVxZlgxOVhwN09ROHhUSm5o WWg4WitMM0lOQTIvRndBQWNBNTJ2K2NJQUFDQVBOQjBBQUJ3RHRCMEFBQndEdFpwT3BiZEFR REFiS3o3alJTYWJnRjZSOFRnOGlUcVlsTU9FZVdzenNySzBpeWo1KzVpUE1pSnpwWXRXNjY3 N3JyVTFOU1pNMmZ1M2J1WFV0clEwREJqeG95UkkwZVdsNWUvOTk1N21udUpFMG1zeHdHSVo1 RG8zQ0lUZUdTRHJHTDRtcjVCZUVEVGJZWnFxRC81NUpQczdHeUQ4WGU1S1ljbVM1WXNlZkxK SnpVLzBuUjNDVHZJaWM3Y3VYTVBIejdjM2QyOVpjc1dkbDlWWldWbFIwZEhLQlRhdm4zN3hJ a1REZlpWRG90WWp3TVF6eURSdVVVbThHZ0dtV09XcGlzMzhzc3pYMzc1NWZIangyZG1abTdh dEVtekRIdXhmUG55OVBUMHNySXlldmw3UGlVbHBiUzBGUFlBa2lnSE5oUUtGUlVWdmZiYWF3 Wnk0M0pURHBIdnYvOCtNek96cTZ0TDgxUFIzVVZta0IzRHlaTW5VMU5UZTN0NzJkdGdNRmhm WHo5OStuU0RYVFNIUlZWUFFpT2VRWHJPTFZRdThBZ0dtV09wcHE5ZnZ6NFlERFkxTmJFelFV L1RYM2poaFVBZzhOQkREL0ZQKy92NzkrM2JOMm5TSkptUWdISmdIM3ZzTVhabm80SGN1TnlV UTJUMTZ0VUxGaXpRKzFSMGQ1RVpaR2Z3N2JmZlZsUlVQUHJvbyt3dFg2UTZlUENnd1Y3aXNL anFTWFRFTTBqUHVVVW04TWdHbVdPNnBuTjNGMEpJWDErZjhsT3hETnVvL0FaYnYzNDl1dytO RUpLVWxDUVRFbEFlRVRaMHh1dmpMamZsVU5IWDE1ZVRrNlA4YmxNaHVydklETElET0hqd1lH NXU3b29WS3dZR0J2akdRQ0N3ZGV2V29xSWlneDFWWTZKWlQwS2pkd2JSSzUxYlpBS1BlSkE1 Wm1tNjZPNGladVdhRGpDcTJ0TFMwcHFhbW9MQm9NL25jL0RaRWx2Qy91V2t3dVdtSENycTZ1 cG16NTV0VU1EQTNjWEJJMVpUVTFOUlVjRWNPeGlMRmkzcTdPd01oVUwxOWZXcTVRVVZ5bUVS NjNFQW1tZVF5cmxGSnZCb0JwbGpscWFMN2k2aXBtczZ3S2hxZS9iWlp6TXlNakl5TWxhdlh1 M2dFeVpXa0N0UmZhVDVtcnJZbEVPVFdiTm1iZHUyVGJsRk5RSUc3aTRPSGl2VmxMaDQ4V0p0 YlcxdWJtNUtTa3BSVVpIZjcrZkZEUGJTckNjT3djUWF2VFBJd0xtRkJXNDhYSHFEYkF6OFhn QUF3RG5nUGxJQUFIQU8wSFFBQUhBTzBIUUFBSEFPMEhRQWJJM2RmcStLcGo5Mmk4V1JRTk1C MENCaTlZbTViQmxVR0gxYi9KNVlTdW1wVTZmMExHNWtHcFc1YmtLbXc1cWVKeXJ2RklQVytS WVpweFRSdWtmUHpNZTRMWm1yUmNTNHhMYkVlaUt3eDRHbUE2Q0JTelQ5NXB0dmZ1Kzk5eVpQ bmp4bHlwUjMzMzNYK01KODQwWmxPaU5UUnZROEViMVRaT3FYY1VvUnJYczB6WHdrWXpHT1Rv eExyeTFsUFJIWTQwRFRBZEJBODR3bFYxb1ByVjI3MXVQeEpDY244OXhLNWdKZlZYN0hucXVx cXRMUzBxWlBuOTdhMmtvcGJXMXRMU2dvU0V0THE2cXFVdGFzYkYxczYralJvemZmZkhOcWF1 cTBhZE40Wm1vc05Jc1dMVnE5ZXZYVXFWTTlIcythTldzV0wxNnNXWS9ZSDVrUkUrc2hoQ3hm dm56MDZORThVZ080NTRtQmQwcllQcWljVWxRRlJPc2VjWXRtdFpvYkpiOWlsWEdKYmVuVkky K1BBMDBIUUFPOTgxTnBQVFJtekJpdjE5dlIwZEhUMHhOMlI4MENYSytycTZ1RHdXQk5UVTF4 Y1RHbGRNYU1HVFUxTmNGZzhKVlhYbEdXVnhrZnFkb3FMeTkvL2ZYWFE2SFFybDI3cGsyYkpo UG02dFdyYjd6eHhubno1bFZXVnQ1NDQ0MXIxcXpSckVldlA2cTRWRjh6WWozS1NJM3ZkRmQ2 bnVoNXAyajJRZXlTZ1ZPS2FOMGpicEZzUzNPTGNWeDZiWW4xRE1zZUI1b09nQWJpZVNWYUQ3 Mzk5dHYzM0hQUHRHblR4bzRkKzh3enoranRxRmV6MGdvcEdBeFNTb1BCWUdwcUtxVTBKU1dG YlFrRUFxeU1wdkdScXEyVWxCUXVxWkxtU0R0MjdFaEtTbnJwcFpmKy9PYy9KeVVsN2R5NVU3 TWVzVDh5SXliV0kwYXFpWjR2aXRJN1JiSVB4azRwb25XUHVFVytyYkNIWGhXWFhsdXFlb1py andOTkIwQUQ4ZnpVc3g0YUdCall1M2R2ZW5vNmV6dHk1TWdUSjA0WTFLeHBoZlRxcTYreTdI WEdqQm1VMHFLaUlwWVhWMWRYc3pLYXJhdmFxcWlvYUd4czdPN3VsZy96MkxGamhKQURCdzU4 OU5GSGhCQW1BbUk5WW45RXhPMWlQY3BJMlY4a0lwcStLQ3J2RkQyVWZaQnhTaEd0ZXd6TWZN TEdhNnpwWWx4NmJTbnJpY0FlQjVvT2dBYmlTb0pvUGNRK1lpNGZHemR1WkRzdVc3WXNMUzNO NFBUV3RFSmk2K241K2ZuNzkrK25sTzdmdno4L1B6OHRMVzM1OHVWNnJZdHRIVHQyN1BiYmIy ZGIrRVpqb2VudDdSMHpaa3hQVDA4b0ZCb3paZ3h6VGhYckVmdWpPV0txTFdJOXlrajExdE5W STMveDRrWDJRdW1kRW5ZdlNxbU1IWTFvM2FOcDVxUGFTMnhMM0NJVGw5aFcySnBsN0hHZzZR REVHV1BaQldCWVFOTUJpRFBRZEJCRG9Pa0FBT0Fjb09rQUFPQWNvT2tBQU9BY29Pa0FBT0Fj b09rZ01XaHNiR3hxYXVydjcyOXFhbXBzYkpUY3hmaFR2UUtCUU1EbjgybVdOOWdMQURzQVRR ZUpRV05qNC92dnYvL1paNTk5OE1FSHNWSlZ2WG9PSFRva2ZnUXBCd2tCTkIwa0JvMk5qY2VP SGZQNy9jZU9IZVB5cW5yUjJOalkzdDd1OS91UEhqMnF0MUZWcDlqUUR6LzgwTnpjcktucGZy OS96NTQ5cDA2ZGltbGtBTVFTYURwSURCb2JHOCtkTzhlZitVYmxpOGJHeHUrKyt5NFFDTEQ3 QmpVM3F1b1VHL3I0NDQrUEh6K3UrZEhnNE9DcFU2ZDI3OTRkdTdBQWlESFFkSkFZTkRZMkRn NE92dlBPTzRPRGcxeHcvWDUvSUJEZ0tpOUt2TGhSVmFkbVEzcnI1b09EZzJmT25JR21BenNE VFFlSmdWSmgrZXVqUjQvNi9mNzI5dllJTkYwbDNPS240b3ZHeHNZOWUvWjg4ODAzc1F3TWdK Z0NUUWNBQU9jQVRRY0FBT2NBVFFjQUFPY0FUUWNBQU9jQVRRY0FBT2NBVFFjQUFPZndvNmEz dHJhK0FRQUFJUEVoRUhRQUFIQU0veC9PYmg1MWt3QkRHZ0FBQUFCSlJVNUVya0pnZ2c9PSIg Lz48L3A+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OiAycHggc29saWQgIzMyNUZC QTsgcGFkZGluZy1sZWZ0OiA1cHg7bWFyZ2luLWxlZnQ6NXB4OyI+LS0tLS1VcnNwciZ1dW1s O25nbGljaGUgTmFjaHJpY2h0LS0tLS08YnIgLz48c3Ryb25nPkFuOjwvc3Ryb25nPglLb25y YWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZC53aWxrQG9yYWNsZS5jb20mZ3Q7OyA8YnIg Lz48c3Ryb25nPkNDOjwvc3Ryb25nPglTYW5kZXIgRWlrZWxlbmJvb20gJmx0O2xpbnV4QGVp a2VsZW5ib29tLml0Jmd0OzsgeGVuLWRldmVsICZsdDt4ZW4tZGV2ZWxAbGlzdHMueGVuc291 cmNlLmNvbSZndDs7IEphbiBCZXVsaWNoICZsdDtqYmV1bGljaEBzdXNlLmNvbSZndDs7IEtv bnJhZCBSemVzenV0ZWsgV2lsayAmbHQ7a29ucmFkQGRhcm5vay5vcmcmZ3Q7OyA8YnIgLz48 c3Ryb25nPlZvbjo8L3N0cm9uZz4JQ2Fyc3RlbiBTY2hpZXJzICZsdDtjYXJzdGVuQHNjaGll cnMuZGUmZ3Q7PGJyIC8+PHN0cm9uZz5HZXNlbmRldDo8L3N0cm9uZz4JRGkgMjguMDIuMjAx MiAxNTozOTxiciAvPjxzdHJvbmc+QmV0cmVmZjo8L3N0cm9uZz4JUmU6IFtYZW4tZGV2ZWxd IExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTxiciAvPjxzdHJv bmc+QW5sYWdlOjwvc3Ryb25nPglpbmxpbmUudHh0PGJyIC8+PHN0eWxlIHR5cGU9InRleHQv Y3NzIj4uYm9keWNsYXNzIHsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgfTwvc3R5bGU+ICAg ICAgICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gICAgICAgLmJvZHljbGFzcyAg ICAgICB7ICAgICAgICAgZm9udC1mYW1pbHk6IEFyaWFsLCBWZXJkYW5hLCBTYW5zLVNlcmlm ICEgaW1wb3J0YW50OyAgICAgICAgIGZvbnQtc2l6ZTogMTJweDsgICAgICAgICBwYWRkaW5n OiA1cHggNXB4IDVweCA1cHg7ICAgICAgICAgbWFyZ2luOiAwcHg7ICAgICAgICAgYm9yZGVy LXN0eWxlOiBub25lOyAgICAgICAgIGJhY2tncm91bmQtY29sb3I6ICNmZmZmZmY7ICAgICAg IH0gICAgICAgIHAsIHVsLCBsaSAgICAgICB7ICAgICAgICAgbWFyZ2luLXRvcDogMHB4OyAg ICAgICAgIG1hcmdpbi1ib3R0b206IDBweDsgICAgICAgfSAgIDwvc3R5bGU+ICA8ZGl2Pjxw PldlbGwgbGV0IG1lIGNoZWNrIGZvciBhIGxvbmdlciBwZXJpb2Qgb2YgdGltZSwgYW5kIGVz cGVjaWFsbHksIHdoZXRoZXIgdGhlIERvbVUgaXMgc3RpbGw8L3A+PHA+d29ya2luZyAoY2Fu IGRvIHRoYXQgb25seSBmcm9tIGF0IGhvbWUpLCBidXQgbG9hZCBsb29rcyBwcmV0dHkgd2Vs bCBhZnRlciBhcHBseWluZyB0aGU8L3A+PHA+cGF0Y2ggdG8gMy4yLjggOi1ELjwvcD48cD4m bmJzcDs8L3A+PHA+QlIsPC9wPjxwPkNhcnN0ZW4uPGJyIC8+Jm5ic3A7PC9wPjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNvbGlkICMzMjVGQkE7IHBhZGRpbmctbGVm dDogNXB4O21hcmdpbi1sZWZ0OjVweDsiPi0tLS0tVXJzcHImdXVtbDtuZ2xpY2hlIE5hY2hy aWNodC0tLS0tPGJyIC8+PHN0cm9uZz5Bbjo8L3N0cm9uZz4JSmFuIEJldWxpY2ggJmx0O0pC ZXVsaWNoQHN1c2UuY29tJmd0OzsgPGJyIC8+PHN0cm9uZz5DQzo8L3N0cm9uZz4JS29ucmFk IFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWRAZGFybm9rLm9yZyZndDs7IHhlbi1kZXZlbCAm bHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7OyBDYXJzdGVuIFNjaGllcnMg Jmx0O2NhcnN0ZW5Ac2NoaWVycy5kZSZndDs7IFNhbmRlciBFaWtlbGVuYm9vbSAmbHQ7bGlu dXhAZWlrZWxlbmJvb20uaXQmZ3Q7OyA8YnIgLz48c3Ryb25nPlZvbjo8L3N0cm9uZz4JS29u cmFkIFJ6ZXN6dXRlayBXaWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0OzxiciAv PjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CUZyIDE3LjAyLjIwMTIgMTY6MTg8YnIgLz48 c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz5PbiBUaHUsIEZlYiAxNiwgMjAx MiBhdCAwODo1Njo1M0FNICswMDAwLCBKYW4gQmV1bGljaCB3cm90ZTo8YnIgLz4mZ3Q7ICZn dDsmZ3Q7Jmd0OyBPbiAxNS4wMi4xMiBhdCAyMDoyOCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxr ICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29tJmd0OyB3cm90ZTo8YnIgLz4mZ3Q7ICZndDtA QCAtMTU1MCw3ICsxNTUyLDExIEBAIHN0YXRpYyB2b2lkICpfX3ZtYWxsb2NfYXJlYV9ub2Rl KHN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEsIGdmcF90IGdmcF9tYXNrLDxiciAvPiZndDsgJmd0 OyAJc3RydWN0IHBhZ2UgKipwYWdlczs8YnIgLz4mZ3Q7ICZndDsgCXVuc2lnbmVkIGludCBu cl9wYWdlcywgYXJyYXlfc2l6ZSwgaTs8YnIgLz4mZ3Q7ICZndDsgCWdmcF90IG5lc3RlZF9n ZnAgPSAoZ2ZwX21hc2sgJmFtcDsgR0ZQX1JFQ0xBSU1fTUFTSykgfCBfX0dGUF9aRVJPOzxi ciAvPiZndDsgJmd0Oy08YnIgLz4mZ3Q7ICZndDsrCWdmcF90IGRtYV9tYXNrID0gZ2ZwX21h c2sgJmFtcDsgKF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKTs8YnIgLz4mZ3Q7ICZndDsrCWlm ICh4ZW5fcHZfZG9tYWluKCkpIHs8YnIgLz4mZ3Q7ICZndDsrCQlpZiAoZG1hX21hc2sgPT0g KF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKSk8YnIgLz4mZ3Q7IDxiciAvPiZndDsgSSBkaWRu JiMzOTt0IHNwb3Qgd2hlcmUgeW91IGZvcmNlIHRoaXMgbm9ybWFsbHkgaW52YWxpZCBjb21i aW5hdGlvbiwgd2l0aG91dDxiciAvPiZndDsgd2hpY2ggdGhlIGNoYW5nZSB3b24mIzM5O3Qg YWZmZWN0IHZtYWxsb2MzMigpIGluIGEgMzItYml0IGtlcm5lbC48YnIgLz4mZ3Q7IDxiciAv PiZndDsgJmd0OysJCQlnZnBfbWFzayAmYW1wOz0gKF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMy KTs8YnIgLz4mZ3Q7IDxiciAvPiZndDsgCQkJZ2ZwX21hc2sgJmFtcDs9IH4oX19HRlBfRE1B IHwgX19HRlBfRE1BMzIpOzxiciAvPiZndDsgPGJyIC8+Jmd0OyBKYW48YnIgLz48YnIgLz5E dWghPGJyIC8+R29vZCBleWVzLiBUaGFua3MgZm9yIGNhdGNoaW5nIHRoYXQuPGJyIC8+PGJy IC8+Jmd0OyA8YnIgLz4mZ3Q7ICZndDsrCX08YnIgLz4mZ3Q7ICZndDsgCW5yX3BhZ2VzID0g KGFyZWEtJmd0O3NpemUgLSBQQUdFX1NJWkUpICZndDsmZ3Q7IFBBR0VfU0hJRlQ7PGJyIC8+ Jmd0OyAmZ3Q7IAlhcnJheV9zaXplID0gKG5yX3BhZ2VzICogc2l6ZW9mKHN0cnVjdCBwYWdl ICopKTs8YnIgLz4mZ3Q7ICZndDsgPGJyIC8+Jmd0OyA8YnIgLz48YnIgLz5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciAvPlhlbi1kZXZlbCBt YWlsaW5nIGxpc3Q8YnIgLz5YZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTxiciAvPmh0 dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbDxiciAvPjwvYmxvY2txdW90ZT48 L2Rpdj4gICA8L2Jsb2NrcXVvdGU+PC9kaXY+ICAgPC9ibG9ja3F1b3RlPjxwPiZuYnNwOzwv cD4gPGhyIHNpemU9IjEiIG5vc2hhZGU9Im5vc2hhZGUiIC8+RS1NYWlsIGlzdCB2aXJlbmZy ZWkuPGJyIC8+IFZvbiBBVkcgJnV1bWw7YmVycHImdXVtbDtmdCAtIDxhIHRpdGxlPSJEaWVz ZXIgZXh0ZXJuZSBMaW5rIHdpcmQgaW4gZWluZW0gbmV1ZW4gRmVuc3RlciBnZSZvdW1sO2Zm bmV0IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cDovL3d3dy5hdmcuZGUiPnd3dy5hdmcu ZGU8L2E+PGJyIC8+IFZlcnNpb246IDIwMTIuMC4yMTI3IC8gVmlyZW5kYXRlbmJhbms6IDI0 MTEvNDkzMiAtIEF1c2dhYmVkYXR1bTogMTIuMDQuMjAxMjwvZGl2PiAgIDwvYmxvY2txdW90 ZT4KPC9ib2R5Pgo8L2h0bWw+ --=_YUdH-dvcOkdqumcxjwwOCt1SaC2W6cO+GX5lCiR8bVByKT8d-- --===============1809693732979586600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1809693732979586600==-- From xen-devel-bounces@lists.xen.org Fri May 11 11:14:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSnnl-0005VG-Fg; Fri, 11 May 2012 11:14:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnnl-0005VB-21 for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:14:25 +0000 Received: from [85.158.138.51:46642] by server-4.bemta-3.messagelabs.com id 87/71-15341-094FCAF4; Fri, 11 May 2012 11:14:24 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336734861!22523138!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5342 invoked from network); 11 May 2012 11:14:23 -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 May 2012 11:14:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330923600"; d="scan'208";a="194422011" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 07:14:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 07:14:20 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSnng-0000Pl-6k; Fri, 11 May 2012 12:14:20 +0100 Message-ID: <4FACF443.5080002@eu.citrix.com> Date: Fri, 11 May 2012 12:13:07 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> In-Reply-To: <1336649508.7098.97.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> + >> +static void pciassignable_remove(const char *bdf, int rebind) >> +{ >> + libxl_device_pci pcidev; >> + XLU_Config *config; >> + >> + memset(&pcidev, 0x00, sizeof(pcidev)); > libxl_device_pci_init also. > > You are also missing the xlu_cfg_destroy both here and in the add fn. > > (it's a bit annoying that an XLU_COnfig is needed for these simple > helper functions, I suppose it's for logging, but maybe they could log > to stderr if cfg==NULL. Anyway, lets not fix that here) Hmm -- I just copied and pasted from pciattach() and friends. I'll fix those up while I'm at it. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:14:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSnnl-0005VG-Fg; Fri, 11 May 2012 11:14:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnnl-0005VB-21 for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:14:25 +0000 Received: from [85.158.138.51:46642] by server-4.bemta-3.messagelabs.com id 87/71-15341-094FCAF4; Fri, 11 May 2012 11:14:24 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336734861!22523138!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5342 invoked from network); 11 May 2012 11:14:23 -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 May 2012 11:14:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330923600"; d="scan'208";a="194422011" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 07:14:20 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 07:14:20 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSnng-0000Pl-6k; Fri, 11 May 2012 12:14:20 +0100 Message-ID: <4FACF443.5080002@eu.citrix.com> Date: Fri, 11 May 2012 12:13:07 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> In-Reply-To: <1336649508.7098.97.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> + >> +static void pciassignable_remove(const char *bdf, int rebind) >> +{ >> + libxl_device_pci pcidev; >> + XLU_Config *config; >> + >> + memset(&pcidev, 0x00, sizeof(pcidev)); > libxl_device_pci_init also. > > You are also missing the xlu_cfg_destroy both here and in the add fn. > > (it's a bit annoying that an XLU_COnfig is needed for these simple > helper functions, I suppose it's for logging, but maybe they could log > to stderr if cfg==NULL. Anyway, lets not fix that here) Hmm -- I just copied and pasted from pciattach() and friends. I'll fix those up while I'm at it. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:20:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:20:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnsd-0005dC-6u; Fri, 11 May 2012 11:19:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnsb-0005d6-Qi for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:19:25 +0000 Received: from [193.109.254.147:10233] by server-3.bemta-14.messagelabs.com id 24/88-23274-DB5FCAF4; Fri, 11 May 2012 11:19:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336735164!8837512!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28767 invoked from network); 11 May 2012 11:19:24 -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 May 2012 11:19:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427425" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:19: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, 11 May 2012 12:19:24 +0100 Message-ID: <1336735163.23818.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 11 May 2012 12:19:23 +0100 In-Reply-To: <4FACF443.5080002@eu.citrix.com> References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: > >> + > >> +static void pciassignable_remove(const char *bdf, int rebind) > >> +{ > >> + libxl_device_pci pcidev; > >> + XLU_Config *config; > >> + > >> + memset(&pcidev, 0x00, sizeof(pcidev)); > > libxl_device_pci_init also. > > > > You are also missing the xlu_cfg_destroy both here and in the add fn. > > > > (it's a bit annoying that an XLU_COnfig is needed for these simple > > helper functions, I suppose it's for logging, but maybe they could log > > to stderr if cfg==NULL. Anyway, lets not fix that here) > Hmm -- I just copied and pasted from pciattach() and friends. I'll fix > those up while I'm at it. Thanks, looked like my grep missed them somehow when I added the init fns. The reset of the memset's in xl_cmdimpl.c look ok except for: memset(cpumap.map, 0, cpumap.size); in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate that one... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:20:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:20:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnsd-0005dC-6u; Fri, 11 May 2012 11:19:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnsb-0005d6-Qi for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:19:25 +0000 Received: from [193.109.254.147:10233] by server-3.bemta-14.messagelabs.com id 24/88-23274-DB5FCAF4; Fri, 11 May 2012 11:19:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336735164!8837512!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28767 invoked from network); 11 May 2012 11:19:24 -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 May 2012 11:19:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427425" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:19: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, 11 May 2012 12:19:24 +0100 Message-ID: <1336735163.23818.72.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 11 May 2012 12:19:23 +0100 In-Reply-To: <4FACF443.5080002@eu.citrix.com> References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: > >> + > >> +static void pciassignable_remove(const char *bdf, int rebind) > >> +{ > >> + libxl_device_pci pcidev; > >> + XLU_Config *config; > >> + > >> + memset(&pcidev, 0x00, sizeof(pcidev)); > > libxl_device_pci_init also. > > > > You are also missing the xlu_cfg_destroy both here and in the add fn. > > > > (it's a bit annoying that an XLU_COnfig is needed for these simple > > helper functions, I suppose it's for logging, but maybe they could log > > to stderr if cfg==NULL. Anyway, lets not fix that here) > Hmm -- I just copied and pasted from pciattach() and friends. I'll fix > those up while I'm at it. Thanks, looked like my grep missed them somehow when I added the init fns. The reset of the memset's in xl_cmdimpl.c look ok except for: memset(cpumap.map, 0, cpumap.size); in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate that one... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:21:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:21:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSntl-0005gY-M1; Fri, 11 May 2012 11:20:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSntk-0005gR-6o for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:20:36 +0000 Received: from [193.109.254.147:8519] by server-12.bemta-14.messagelabs.com id BF/F5-05898-306FCAF4; Fri, 11 May 2012 11:20:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336735223!8736180!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4090 invoked from network); 11 May 2012 11:20:23 -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; 11 May 2012 11:20:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427448" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:20: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, 11 May 2012 12:20:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSntW-00060H-Ig; Fri, 11 May 2012 11:20:22 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSntW-0000K4-H1; Fri, 11 May 2012 12:20:22 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.62966.512112.404603@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:20:22 +0100 To: "Zhang, Yang Z" In-Reply-To: References: <20395.62069.578209.953705@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhang, Yang Z writes ("RE: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > This error handling should really go away. Would you be able to > > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > > That never fails, so that would also mean libxl_cpumap_alloc can't > > fail. > > I don't think so. Libxl_cpumap_alloc() also returned error when > max_cpus equal zero. So the error handling cannot be avoid even > using libxl__zalloc. Hmm. Can it not be made to either abort or succeed in this case ? > > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > > for (i = 0; i < info->max_vcpus; i++) { > > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > > << i))) > > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > > + > > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > > ? "offline" : "online"; > > > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > > simpler. > > Sorry. What your mean for this? I mean that if you changed libxl_cpumap_test to tolerate a NULL cpumap and simply return false, then the caller wouldn't have to check for it. But you may prefer to keep it the current way. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:21:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:21:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSntl-0005gY-M1; Fri, 11 May 2012 11:20:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSntk-0005gR-6o for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:20:36 +0000 Received: from [193.109.254.147:8519] by server-12.bemta-14.messagelabs.com id BF/F5-05898-306FCAF4; Fri, 11 May 2012 11:20:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336735223!8736180!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4090 invoked from network); 11 May 2012 11:20:23 -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; 11 May 2012 11:20:23 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427448" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:20: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, 11 May 2012 12:20:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSntW-00060H-Ig; Fri, 11 May 2012 11:20:22 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSntW-0000K4-H1; Fri, 11 May 2012 12:20:22 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.62966.512112.404603@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:20:22 +0100 To: "Zhang, Yang Z" In-Reply-To: References: <20395.62069.578209.953705@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhang, Yang Z writes ("RE: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > This error handling should really go away. Would you be able to > > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > > That never fails, so that would also mean libxl_cpumap_alloc can't > > fail. > > I don't think so. Libxl_cpumap_alloc() also returned error when > max_cpus equal zero. So the error handling cannot be avoid even > using libxl__zalloc. Hmm. Can it not be made to either abort or succeed in this case ? > > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > > for (i = 0; i < info->max_vcpus; i++) { > > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > > << i))) > > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > > + > > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > > ? "offline" : "online"; > > > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > > simpler. > > Sorry. What your mean for this? I mean that if you changed libxl_cpumap_test to tolerate a NULL cpumap and simply return false, then the caller wouldn't have to check for it. But you may prefer to keep it the current way. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnw6-0005q5-7X; Fri, 11 May 2012 11:23:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnw4-0005ps-Ii for xen-devel@lists.xen.org; Fri, 11 May 2012 11:23:00 +0000 Received: from [85.158.143.35:16942] by server-3.bemta-4.messagelabs.com id 01/23-05853-396FCAF4; Fri, 11 May 2012 11:22:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336735376!15605637!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24324 invoked from network); 11 May 2012 11:22:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:22:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330923600"; d="scan'208";a="25097871" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 07:22:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 07:22:55 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSnvy-0000Y6-Sa; Fri, 11 May 2012 12:22:54 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5abc2c4e80892ca27db56406dcaf5cc3d7d9afda Message-ID: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 12:22:54 +0100 From: Ian Campbell To: xen-devel@lists.xen.org Cc: George Dunlap , Ian.Jackson@citrix.com Subject: [Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Ian Campbell # Date 1336735243 -3600 # Node ID 5abc2c4e80892ca27db56406dcaf5cc3d7d9afda # Parent 6d45fbdca09be60726eb7043a42dbac552e202e0 xl: use libxl_cpumap_set_none not memset Signed-off-by: Ian Campbell diff -r 6d45fbdca09b -r 5abc2c4e8089 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu May 10 14:14:24 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 12:20:43 2012 +0100 @@ -6107,7 +6107,7 @@ int main_cpupoolnumasplit(int argc, char fprintf(stderr, "failed to offline vcpus\n"); goto out; } - memset(cpumap.map, 0, cpumap.size); + libxl_cpumap_set_none(&cpumap); for (c = 0; c < n_cpus; c++) { if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:23:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:23:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnw6-0005q5-7X; Fri, 11 May 2012 11:23:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnw4-0005ps-Ii for xen-devel@lists.xen.org; Fri, 11 May 2012 11:23:00 +0000 Received: from [85.158.143.35:16942] by server-3.bemta-4.messagelabs.com id 01/23-05853-396FCAF4; Fri, 11 May 2012 11:22:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336735376!15605637!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24324 invoked from network); 11 May 2012 11:22:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:22:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330923600"; d="scan'208";a="25097871" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 07:22:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 07:22:55 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSnvy-0000Y6-Sa; Fri, 11 May 2012 12:22:54 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5abc2c4e80892ca27db56406dcaf5cc3d7d9afda Message-ID: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 12:22:54 +0100 From: Ian Campbell To: xen-devel@lists.xen.org Cc: George Dunlap , Ian.Jackson@citrix.com Subject: [Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Ian Campbell # Date 1336735243 -3600 # Node ID 5abc2c4e80892ca27db56406dcaf5cc3d7d9afda # Parent 6d45fbdca09be60726eb7043a42dbac552e202e0 xl: use libxl_cpumap_set_none not memset Signed-off-by: Ian Campbell diff -r 6d45fbdca09b -r 5abc2c4e8089 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Thu May 10 14:14:24 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 12:20:43 2012 +0100 @@ -6107,7 +6107,7 @@ int main_cpupoolnumasplit(int argc, char fprintf(stderr, "failed to offline vcpus\n"); goto out; } - memset(cpumap.map, 0, cpumap.size); + libxl_cpumap_set_none(&cpumap); for (c = 0; c < n_cpus; c++) { if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:26:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:26:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnzF-00061Q-Sx; Fri, 11 May 2012 11:26:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnzF-000617-5D for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:26:17 +0000 Received: from [85.158.139.83:5621] by server-5.bemta-5.messagelabs.com id B7/FC-13566-657FCAF4; Fri, 11 May 2012 11:26:14 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336735572!25151432!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14781 invoked from network); 11 May 2012 11:26:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:26:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427561" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:26: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, 11 May 2012 12:26:12 +0100 Message-ID: <1336735571.23818.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 12:26:11 +0100 In-Reply-To: <20396.62966.512112.404603@mariner.uk.xensource.com> References: <20395.62069.578209.953705@mariner.uk.xensource.com> <20396.62966.512112.404603@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Zhang, Yang Z" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 12:20 +0100, Ian Jackson wrote: > Zhang, Yang Z writes ("RE: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > > This error handling should really go away. Would you be able to > > > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > > > That never fails, so that would also mean libxl_cpumap_alloc can't > > > fail. > > > > I don't think so. Libxl_cpumap_alloc() also returned error when > > max_cpus equal zero. So the error handling cannot be avoid even > > using libxl__zalloc. > > Hmm. Can it not be made to either abort or succeed in this case ? max_cpus == 0 means xc_physinfo failed, which is either a memory allocation failure (bounce buffering) or a pretty serious error (toolstack/hypervisor mismatch which is logged or perhaps an XSM/privilege type thing) from which we are unlikely to recover. I'd say that a hard failure would be acceptable here. Ian. > > > > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > > > for (i = 0; i < info->max_vcpus; i++) { > > > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > > > << i))) > > > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > > > + > > > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > > > ? "offline" : "online"; > > > > > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > > > simpler. > > > > Sorry. What your mean for this? > > I mean that if you changed libxl_cpumap_test to tolerate a NULL cpumap > and simply return false, then the caller wouldn't have to check for > it. But you may prefer to keep it the current way. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:26:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11:26:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnzF-00061Q-Sx; Fri, 11 May 2012 11:26:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSnzF-000617-5D for xen-devel@lists.xensource.com; Fri, 11 May 2012 11:26:17 +0000 Received: from [85.158.139.83:5621] by server-5.bemta-5.messagelabs.com id B7/FC-13566-657FCAF4; Fri, 11 May 2012 11:26:14 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336735572!25151432!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14781 invoked from network); 11 May 2012 11:26:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:26:13 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427561" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:26: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, 11 May 2012 12:26:12 +0100 Message-ID: <1336735571.23818.75.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 12:26:11 +0100 In-Reply-To: <20396.62966.512112.404603@mariner.uk.xensource.com> References: <20395.62069.578209.953705@mariner.uk.xensource.com> <20396.62966.512112.404603@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Zhang, Yang Z" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 12:20 +0100, Ian Jackson wrote: > Zhang, Yang Z writes ("RE: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus"): > > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > > This error handling should really go away. Would you be able to > > > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ? > > > That never fails, so that would also mean libxl_cpumap_alloc can't > > > fail. > > > > I don't think so. Libxl_cpumap_alloc() also returned error when > > max_cpus equal zero. So the error handling cannot be avoid even > > using libxl__zalloc. > > Hmm. Can it not be made to either abort or succeed in this case ? max_cpus == 0 means xc_physinfo failed, which is either a memory allocation failure (bounce buffering) or a pretty serious error (toolstack/hypervisor mismatch which is logged or perhaps an XSM/privilege type thing) from which we are unlikely to recover. I'd say that a hard failure would be acceptable here. Ian. > > > > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c > > > > --- a/tools/libxl/libxl_dom.c Thu Apr 12 14:01:27 2012 +0100 > > > > +++ b/tools/libxl/libxl_dom.c Fri May 04 10:47:00 2012 +0800 > > > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin > > > > ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn); > > > > for (i = 0; i < info->max_vcpus; i++) { > > > > ents[12+(i*2)] = libxl__sprintf(gc, "cpu/%d/availability", i); > > > > - ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 > > > << i))) > > > > + ents[12+(i*2)+1] = (i && info->avail_vcpus.size > > > > + > > > && !libxl_cpumap_test(&info->avail_vcpus, i)) > > > > ? "offline" : "online"; > > > > > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be > > > simpler. > > > > Sorry. What your mean for this? > > I mean that if you changed libxl_cpumap_test to tolerate a NULL cpumap > and simply return false, then the caller wouldn't have to check for > it. But you may prefer to keep it the current way. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:41:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSoCh-0006GY-D8; Fri, 11 May 2012 11:40:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSoCg-0006GT-49 for xen-devel@lists.xen.org; Fri, 11 May 2012 11:40:10 +0000 Received: from [85.158.143.35:4600] by server-1.bemta-4.messagelabs.com id 29/00-20925-99AFCAF4; Fri, 11 May 2012 11:40:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336736407!3908173!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11255 invoked from network); 11 May 2012 11:40:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:40:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427864" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:40:08 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 12:40:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSoCd-00069I-K5; Fri, 11 May 2012 11:40:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSoCd-0000Nn-Il; Fri, 11 May 2012 12:40:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.64151.561157.893460@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:40:07 +0100 To: Darrio Faggioli Newsgroups: chiark.mail.xen.devel In-Reply-To: <95f7eacc32f0bf7ba281.1336567580@Solace> References: <95f7eacc32f0bf7ba281.1336567580@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , Ian Campbell , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Darrio Faggioli writes ("[Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have"): > Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor > supports to be valid topology entries might lead to misleading and incorrect > behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:41:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSoCh-0006GY-D8; Fri, 11 May 2012 11:40:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSoCg-0006GT-49 for xen-devel@lists.xen.org; Fri, 11 May 2012 11:40:10 +0000 Received: from [85.158.143.35:4600] by server-1.bemta-4.messagelabs.com id 29/00-20925-99AFCAF4; Fri, 11 May 2012 11:40:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336736407!3908173!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11255 invoked from network); 11 May 2012 11:40:08 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:40:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="12427864" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:40:08 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 12:40:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSoCd-00069I-K5; Fri, 11 May 2012 11:40:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSoCd-0000Nn-Il; Fri, 11 May 2012 12:40:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.64151.561157.893460@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:40:07 +0100 To: Darrio Faggioli Newsgroups: chiark.mail.xen.devel In-Reply-To: <95f7eacc32f0bf7ba281.1336567580@Solace> References: <95f7eacc32f0bf7ba281.1336567580@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , Ian Campbell , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Darrio Faggioli writes ("[Xen-devel] [PATCH v2] libxl: use xc_topologyinfo to figure out how many CPUs we actually have"): > Within libxl_get_cpu_topology(), considering all the CPUs the hypervisor > supports to be valid topology entries might lead to misleading and incorrect > behaviours, e.g., the output of `xl info -n' below on a 16 cores machine: Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:43:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSoFq-0006MD-VY; Fri, 11 May 2012 11:43:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSoFp-0006M8-Nx for xen-devel@lists.xen.org; Fri, 11 May 2012 11:43:25 +0000 Received: from [193.109.254.147:28283] by server-8.bemta-14.messagelabs.com id D0/29-23244-D5BFCAF4; Fri, 11 May 2012 11:43:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336736604!8582033!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11967 invoked from network); 11 May 2012 11:43:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:43:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12427913" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:42: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, 11 May 2012 12:42:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSoEz-0006A3-J7; Fri, 11 May 2012 11:42:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSoEz-00015Y-I4; Fri, 11 May 2012 12:42:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.64297.543577.394652@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:42:33 +0100 To: Jean Guyader Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Konrad Rzeszutek Wilk , Stefano Stabellini , "Kay, Allen M" , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jean Guyader writes ("Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3)"): > On 10 May 2012 20:07, 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. > > Sorry forgot to say, it was acked by Stefano. > > Acked-by: Stefano Stabellini Thanks. Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 11:43:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 11: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 ) id 1SSoFq-0006MD-VY; Fri, 11 May 2012 11:43:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSoFp-0006M8-Nx for xen-devel@lists.xen.org; Fri, 11 May 2012 11:43:25 +0000 Received: from [193.109.254.147:28283] by server-8.bemta-14.messagelabs.com id D0/29-23244-D5BFCAF4; Fri, 11 May 2012 11:43:25 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1336736604!8582033!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11967 invoked from network); 11 May 2012 11:43:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 11:43:24 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12427913" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 11:42: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, 11 May 2012 12:42:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSoEz-0006A3-J7; Fri, 11 May 2012 11:42:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSoEz-00015Y-I4; Fri, 11 May 2012 12:42:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20396.64297.543577.394652@mariner.uk.xensource.com> Date: Fri, 11 May 2012 12:42:33 +0100 To: Jean Guyader Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Konrad Rzeszutek Wilk , Stefano Stabellini , "Kay, Allen M" , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jean Guyader writes ("Re: [Xen-devel] [PATCH][RESEND] qemu-xen: Intel GPU passthrough, fix OpRegion mapping (v3)"): > On 10 May 2012 20:07, 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. > > Sorry forgot to say, it was acked by Stefano. > > Acked-by: Stefano Stabellini Thanks. Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:19:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:19:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSooS-00077j-DJ; Fri, 11 May 2012 12:19:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSooR-00077d-Ai for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:19:11 +0000 Received: from [193.109.254.147:16818] by server-5.bemta-14.messagelabs.com id 7B/65-30733-EB30DAF4; Fri, 11 May 2012 12:19:10 +0000 X-Env-Sender: heliman@katamail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336738748!3624270!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16042 invoked from network); 11 May 2012 12:19:10 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 11 May 2012 12:19:09 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SSooN-00048N-TB for xen-devel@lists.xensource.com; Fri, 11 May 2012 05:19:07 -0700 Date: Fri, 11 May 2012 05:19:07 -0700 (PDT) From: Geraldes To: xen-devel@lists.xensource.com Message-ID: <1336738747897-5702906.post@n5.nabble.com> In-Reply-To: References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD-2 wrote > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. > How can you see these 8MB ? In my tests with cirrus/stdvga, in a Linux guest lspci always report 32M and Xorg.0.log report "VideoRAM: 4096 kByte". In a Windows XP/7 guest the Device Manager show 32M as well. This is confusing. Is there a better way to check videoram and videoram usage in a Linux or Windows guest? -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5702906.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:19:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:19:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSooS-00077j-DJ; Fri, 11 May 2012 12:19:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSooR-00077d-Ai for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:19:11 +0000 Received: from [193.109.254.147:16818] by server-5.bemta-14.messagelabs.com id 7B/65-30733-EB30DAF4; Fri, 11 May 2012 12:19:10 +0000 X-Env-Sender: heliman@katamail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1336738748!3624270!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16042 invoked from network); 11 May 2012 12:19:10 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 11 May 2012 12:19:09 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SSooN-00048N-TB for xen-devel@lists.xensource.com; Fri, 11 May 2012 05:19:07 -0700 Date: Fri, 11 May 2012 05:19:07 -0700 (PDT) From: Geraldes To: xen-devel@lists.xensource.com Message-ID: <1336738747897-5702906.post@n5.nabble.com> In-Reply-To: References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> MIME-Version: 1.0 Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD-2 wrote > > For cirrus/stdvga, there is no way to pass the parameter to qemu, the > size in qemu is fixed to 8MB. > How can you see these 8MB ? In my tests with cirrus/stdvga, in a Linux guest lspci always report 32M and Xorg.0.log report "VideoRAM: 4096 kByte". In a Windows XP/7 guest the Device Manager show 32M as well. This is confusing. Is there a better way to check videoram and videoram usage in a Linux or Windows guest? -- View this message in context: http://xen.1045712.n5.nabble.com/Unable-to-get-QXL-vga-working-tp5667919p5702906.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:52:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:52:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpKa-0007Pw-8E; Fri, 11 May 2012 12:52:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpKY-0007Pr-Mc for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:52:22 +0000 Received: from [193.109.254.147:58281] by server-10.bemta-14.messagelabs.com id 57/D0-05847-68B0DAF4; Fri, 11 May 2012 12:52:22 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336740730!8798496!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12704 invoked from network); 11 May 2012 12:52:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 12:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25099785" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:52:10 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 08:52:10 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpKL-0001qF-SH; Fri, 11 May 2012 13:52:09 +0100 Message-ID: <4FAD0B31.3010608@eu.citrix.com> Date: Fri, 11 May 2012 13:50:57 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> <1336735163.23818.72.camel@zakaz.uk.xensource.com> In-Reply-To: <1336735163.23818.72.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/12 12:19, Ian Campbell wrote: > On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: >>>> + >>>> +static void pciassignable_remove(const char *bdf, int rebind) >>>> +{ >>>> + libxl_device_pci pcidev; >>>> + XLU_Config *config; >>>> + >>>> + memset(&pcidev, 0x00, sizeof(pcidev)); >>> libxl_device_pci_init also. >>> >>> You are also missing the xlu_cfg_destroy both here and in the add fn. >>> >>> (it's a bit annoying that an XLU_COnfig is needed for these simple >>> helper functions, I suppose it's for logging, but maybe they could log >>> to stderr if cfg==NULL. Anyway, lets not fix that here) >> Hmm -- I just copied and pasted from pciattach() and friends. I'll fix >> those up while I'm at it. > Thanks, looked like my grep missed them somehow when I added the init > fns. The reset of the memset's in xl_cmdimpl.c look ok except for: > > memset(cpumap.map, 0, cpumap.size); > > in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate > that one... OK -- I found another place xl_cfg_destroy() wasn't being called. I think I'll send those as a separate clean-up series; but the new functions added in the series will have the fixes you suggested. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:52:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:52:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpKa-0007Pw-8E; Fri, 11 May 2012 12:52:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpKY-0007Pr-Mc for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:52:22 +0000 Received: from [193.109.254.147:58281] by server-10.bemta-14.messagelabs.com id 57/D0-05847-68B0DAF4; Fri, 11 May 2012 12:52:22 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336740730!8798496!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12704 invoked from network); 11 May 2012 12:52:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 12:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25099785" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 08:52:10 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 08:52:10 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpKL-0001qF-SH; Fri, 11 May 2012 13:52:09 +0100 Message-ID: <4FAD0B31.3010608@eu.citrix.com> Date: Fri, 11 May 2012 13:50:57 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ian Campbell References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> <1336735163.23818.72.camel@zakaz.uk.xensource.com> In-Reply-To: <1336735163.23818.72.camel@zakaz.uk.xensource.com> Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/12 12:19, Ian Campbell wrote: > On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: >>>> + >>>> +static void pciassignable_remove(const char *bdf, int rebind) >>>> +{ >>>> + libxl_device_pci pcidev; >>>> + XLU_Config *config; >>>> + >>>> + memset(&pcidev, 0x00, sizeof(pcidev)); >>> libxl_device_pci_init also. >>> >>> You are also missing the xlu_cfg_destroy both here and in the add fn. >>> >>> (it's a bit annoying that an XLU_COnfig is needed for these simple >>> helper functions, I suppose it's for logging, but maybe they could log >>> to stderr if cfg==NULL. Anyway, lets not fix that here) >> Hmm -- I just copied and pasted from pciattach() and friends. I'll fix >> those up while I'm at it. > Thanks, looked like my grep missed them somehow when I added the init > fns. The reset of the memset's in xl_cmdimpl.c look ok except for: > > memset(cpumap.map, 0, cpumap.size); > > in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate > that one... OK -- I found another place xl_cfg_destroy() wasn't being called. I think I'll send those as a separate clean-up series; but the new functions added in the series will have the fixes you suggested. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:59:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpQg-0007YI-28; Fri, 11 May 2012 12:58:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpQf-0007YB-44 for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:58:41 +0000 Received: from [85.158.139.83:51521] by server-2.bemta-5.messagelabs.com id AA/8C-17016-00D0DAF4; Fri, 11 May 2012 12:58:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336741119!20540034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16064 invoked from network); 11 May 2012 12:58:39 -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; 11 May 2012 12:58:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12429400" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 12:58: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, 11 May 2012 13:58:04 +0100 Message-ID: <1336741083.23818.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 11 May 2012 13:58:03 +0100 In-Reply-To: <4FAD0B31.3010608@eu.citrix.com> References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> <1336735163.23818.72.camel@zakaz.uk.xensource.com> <4FAD0B31.3010608@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 13:50 +0100, George Dunlap wrote: > On 11/05/12 12:19, Ian Campbell wrote: > > On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: > >>>> + > >>>> +static void pciassignable_remove(const char *bdf, int rebind) > >>>> +{ > >>>> + libxl_device_pci pcidev; > >>>> + XLU_Config *config; > >>>> + > >>>> + memset(&pcidev, 0x00, sizeof(pcidev)); > >>> libxl_device_pci_init also. > >>> > >>> You are also missing the xlu_cfg_destroy both here and in the add fn. > >>> > >>> (it's a bit annoying that an XLU_COnfig is needed for these simple > >>> helper functions, I suppose it's for logging, but maybe they could log > >>> to stderr if cfg==NULL. Anyway, lets not fix that here) > >> Hmm -- I just copied and pasted from pciattach() and friends. I'll fix > >> those up while I'm at it. > > Thanks, looked like my grep missed them somehow when I added the init > > fns. The reset of the memset's in xl_cmdimpl.c look ok except for: > > > > memset(cpumap.map, 0, cpumap.size); > > > > in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate > > that one... > OK -- I found another place xl_cfg_destroy() wasn't being called. I > think I'll send those as a separate clean-up series; but the new > functions added in the series will have the fixes you suggested. THanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 12:59:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 12:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpQg-0007YI-28; Fri, 11 May 2012 12:58:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpQf-0007YB-44 for xen-devel@lists.xensource.com; Fri, 11 May 2012 12:58:41 +0000 Received: from [85.158.139.83:51521] by server-2.bemta-5.messagelabs.com id AA/8C-17016-00D0DAF4; Fri, 11 May 2012 12:58:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1336741119!20540034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16064 invoked from network); 11 May 2012 12:58:39 -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; 11 May 2012 12:58:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12429400" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 12:58: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, 11 May 2012 13:58:04 +0100 Message-ID: <1336741083.23818.76.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 11 May 2012 13:58:03 +0100 In-Reply-To: <4FAD0B31.3010608@eu.citrix.com> References: <1336649508.7098.97.camel@zakaz.uk.xensource.com> <4FACF443.5080002@eu.citrix.com> <1336735163.23818.72.camel@zakaz.uk.xensource.com> <4FAD0B31.3010608@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 13:50 +0100, George Dunlap wrote: > On 11/05/12 12:19, Ian Campbell wrote: > > On Fri, 2012-05-11 at 12:13 +0100, George Dunlap wrote: > >>>> + > >>>> +static void pciassignable_remove(const char *bdf, int rebind) > >>>> +{ > >>>> + libxl_device_pci pcidev; > >>>> + XLU_Config *config; > >>>> + > >>>> + memset(&pcidev, 0x00, sizeof(pcidev)); > >>> libxl_device_pci_init also. > >>> > >>> You are also missing the xlu_cfg_destroy both here and in the add fn. > >>> > >>> (it's a bit annoying that an XLU_COnfig is needed for these simple > >>> helper functions, I suppose it's for logging, but maybe they could log > >>> to stderr if cfg==NULL. Anyway, lets not fix that here) > >> Hmm -- I just copied and pasted from pciattach() and friends. I'll fix > >> those up while I'm at it. > > Thanks, looked like my grep missed them somehow when I added the init > > fns. The reset of the memset's in xl_cmdimpl.c look ok except for: > > > > memset(cpumap.map, 0, cpumap.size); > > > > in main_cpupoolnumasplit which smells a bit fishy -- I'll investigate > > that one... > OK -- I found another place xl_cfg_destroy() wasn't being called. I > think I'll send those as a separate clean-up series; but the new > functions added in the series will have the fixes you suggested. THanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:01:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpTE-0007fq-Kp; Fri, 11 May 2012 13:01:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpTD-0007fl-3C for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:01:19 +0000 Received: from [85.158.143.99:58939] by server-3.bemta-4.messagelabs.com id 84/4C-05853-E9D0DAF4; Fri, 11 May 2012 13:01:18 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336741277!24184851!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6517 invoked from network); 11 May 2012 13:01:17 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 13:01:17 -0000 Received: by wibhm14 with SMTP id hm14so1132843wib.6 for ; Fri, 11 May 2012 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Fg1heC3f0VgKKIzXk0kCiUbUPoIOioJyJJRnnCW4SeA=; b=ahMN1sh4AjkZM3nBBNVBWksCsphrDGfGIHxVvaK1Sz9TmhnhSUxpMbhRTESkhvL/FC OpgfxIMRSvRYR+gzG3rKZhO4eK19W6+OuLaRvkBOT7T35wdHLRUz56EF360hO+0JQcqh qWp3w+cX1U4xtztkbGPM1jMS7rxF6fP2zkaFqKzdbkeKhTtFBQo8gNSgF5hhmT+QMoTr 3gwSs0Qk5oFHEe8aEEyPgG7BEbSTd+338WLKMdul2JbtEGEfpuJCUOpNkwAaEQ9BKW7Q NKV4PFZ8K/jzw5NqskUpd7l58en7YES+nJK5R/OyJkMwfGQ4pkBl8hjHG8eDnsIAqs00 Yd3g== Received: by 10.50.179.104 with SMTP id df8mr1639742igc.11.1336741276250; Fri, 11 May 2012 06:01:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Fri, 11 May 2012 06:00:46 -0700 (PDT) In-Reply-To: <1336738747897-5702906.post@n5.nabble.com> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336738747897-5702906.post@n5.nabble.com> From: Anthony PERARD Date: Fri, 11 May 2012 14:00:46 +0100 X-Google-Sender-Auth: d2yBSVu6cUGk1OADzIYYl-VMwOU Message-ID: To: Geraldes Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 1:19 PM, Geraldes wrote: > > Anthony PERARD-2 wrote >> >> For cirrus/stdvga, there is no way to pass the parameter to qemu, the >> size in qemu is fixed to 8MB. >> > > How can you see these 8MB ? This is just the size of the vram allocated by qemu, I saw this in the code. > In my tests with cirrus/stdvga, in a Linux guest lspci always report 32M and > Xorg.0.log report "VideoRAM: 4096 kByte". In a Windows XP/7 guest the Device > Manager show 32M as well. This is confusing. It seams that part of the 32MB are used to do other kind of operation that just accessing to the vram. For the 4MB instead of 8 reported by Xorg, I don't know. There is probably a reason why Cirrus will report 4 instead of 8. > Is there a better way to check videoram and videoram usage in a Linux or > Windows guest? I don't think so. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:01:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpTE-0007fq-Kp; Fri, 11 May 2012 13:01:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpTD-0007fl-3C for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:01:19 +0000 Received: from [85.158.143.99:58939] by server-3.bemta-4.messagelabs.com id 84/4C-05853-E9D0DAF4; Fri, 11 May 2012 13:01:18 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1336741277!24184851!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6517 invoked from network); 11 May 2012 13:01:17 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 13:01:17 -0000 Received: by wibhm14 with SMTP id hm14so1132843wib.6 for ; Fri, 11 May 2012 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Fg1heC3f0VgKKIzXk0kCiUbUPoIOioJyJJRnnCW4SeA=; b=ahMN1sh4AjkZM3nBBNVBWksCsphrDGfGIHxVvaK1Sz9TmhnhSUxpMbhRTESkhvL/FC OpgfxIMRSvRYR+gzG3rKZhO4eK19W6+OuLaRvkBOT7T35wdHLRUz56EF360hO+0JQcqh qWp3w+cX1U4xtztkbGPM1jMS7rxF6fP2zkaFqKzdbkeKhTtFBQo8gNSgF5hhmT+QMoTr 3gwSs0Qk5oFHEe8aEEyPgG7BEbSTd+338WLKMdul2JbtEGEfpuJCUOpNkwAaEQ9BKW7Q NKV4PFZ8K/jzw5NqskUpd7l58en7YES+nJK5R/OyJkMwfGQ4pkBl8hjHG8eDnsIAqs00 Yd3g== Received: by 10.50.179.104 with SMTP id df8mr1639742igc.11.1336741276250; Fri, 11 May 2012 06:01:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.228 with HTTP; Fri, 11 May 2012 06:00:46 -0700 (PDT) In-Reply-To: <1336738747897-5702906.post@n5.nabble.com> References: <1335946863612-5679908.post@n5.nabble.com> <1336048124596-5683034.post@n5.nabble.com> <20120503140045.GP2058@reaktio.net> <1336055231213-5683345.post@n5.nabble.com> <20120503160244.GQ2058@reaktio.net> <1336119794999-5685158.post@n5.nabble.com> <1336120109.26385.7.camel@dagon.hellion.org.uk> <1336738747897-5702906.post@n5.nabble.com> From: Anthony PERARD Date: Fri, 11 May 2012 14:00:46 +0100 X-Google-Sender-Auth: d2yBSVu6cUGk1OADzIYYl-VMwOU Message-ID: To: Geraldes Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Unable to get QXL vga working / videomem over 4MB issue X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 1:19 PM, Geraldes wrote: > > Anthony PERARD-2 wrote >> >> For cirrus/stdvga, there is no way to pass the parameter to qemu, the >> size in qemu is fixed to 8MB. >> > > How can you see these 8MB ? This is just the size of the vram allocated by qemu, I saw this in the code. > In my tests with cirrus/stdvga, in a Linux guest lspci always report 32M and > Xorg.0.log report "VideoRAM: 4096 kByte". In a Windows XP/7 guest the Device > Manager show 32M as well. This is confusing. It seams that part of the 32MB are used to do other kind of operation that just accessing to the vram. For the 4MB instead of 8 reported by Xorg, I don't know. There is probably a reason why Cirrus will report 4 instead of 8. > Is there a better way to check videoram and videoram usage in a Linux or > Windows guest? I don't think so. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:12:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSpds-0007vN-Q0; Fri, 11 May 2012 13:12:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpdq-0007vI-RJ for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:12:19 +0000 Received: from [85.158.143.35:62855] by server-2.bemta-4.messagelabs.com id 30/B3-17550-2301DAF4; Fri, 11 May 2012 13:12:18 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336741936!11763423!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5465 invoked from network); 11 May 2012 13:12:17 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-8.tower-21.messagelabs.com with SMTP; 11 May 2012 13:12:17 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 06:12:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98948144" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 06:12:15 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 06:12:14 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Fri, 11 May 2012 21:12:13 +0800 From: "Liu, Jinsong" To: 'Konrad Rzeszutek Wilk' Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAFaJPA= Date: Fri, 11 May 2012 13:12:13 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> In-Reply-To: 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'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Liu, Jinsong wrote: > Just notice your reply (so quick :) > > Agree and will update later, except 1 concern below. > > Konrad Rzeszutek Wilk wrote: >>> >>> Hmm, it's good if it's convenient to do it automatically via >>> dev->release. However, dev container (pcpu) would be free at some >>> other error cases, so I prefer do it 'manually'. >> >> You could also call pcpu_release(..) to do it manually. >> > > that means kfree(pcpu) would be done twice at some error cases, do > you think it really good? > Ping. I think error recovery should be kept inside error logic level itself, if try to recover upper level error would bring trouble. In our example, there are 2 logic levels: pcpu level (as container), and dev level (subfield used for sys) dev->release should only recover error occurred at dev/sys level, and the pcpu error should be recovered at pcpu level. If dev->release try to recover its container pcpu level error, like list_del/kfree(pcpu), it would make confusing. i.e., considering pcpu_sys_create(), 2 error cases: device_register fail, and device_create_file fail --> how can the caller decide kfree(pcpu) or not? So how about recover pcpu error manually and explicitly? Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:12:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSpds-0007vN-Q0; Fri, 11 May 2012 13:12:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpdq-0007vI-RJ for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:12:19 +0000 Received: from [85.158.143.35:62855] by server-2.bemta-4.messagelabs.com id 30/B3-17550-2301DAF4; Fri, 11 May 2012 13:12:18 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336741936!11763423!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5465 invoked from network); 11 May 2012 13:12:17 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-8.tower-21.messagelabs.com with SMTP; 11 May 2012 13:12:17 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 06:12:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="98948144" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 06:12:15 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 06:12:14 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Fri, 11 May 2012 21:12:13 +0800 From: "Liu, Jinsong" To: 'Konrad Rzeszutek Wilk' Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAFaJPA= Date: Fri, 11 May 2012 13:12:13 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> In-Reply-To: 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'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Liu, Jinsong wrote: > Just notice your reply (so quick :) > > Agree and will update later, except 1 concern below. > > Konrad Rzeszutek Wilk wrote: >>> >>> Hmm, it's good if it's convenient to do it automatically via >>> dev->release. However, dev container (pcpu) would be free at some >>> other error cases, so I prefer do it 'manually'. >> >> You could also call pcpu_release(..) to do it manually. >> > > that means kfree(pcpu) would be done twice at some error cases, do > you think it really good? > Ping. I think error recovery should be kept inside error logic level itself, if try to recover upper level error would bring trouble. In our example, there are 2 logic levels: pcpu level (as container), and dev level (subfield used for sys) dev->release should only recover error occurred at dev/sys level, and the pcpu error should be recovered at pcpu level. If dev->release try to recover its container pcpu level error, like list_del/kfree(pcpu), it would make confusing. i.e., considering pcpu_sys_create(), 2 error cases: device_register fail, and device_create_file fail --> how can the caller decide kfree(pcpu) or not? So how about recover pcpu error manually and explicitly? Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpz0-00087q-Dk; Fri, 11 May 2012 13:34:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyy-00086q-HF for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:08 +0000 Received: from [85.158.138.51:46317] by server-12.bemta-3.messagelabs.com id B9/46-29760-F451DAF4; Fri, 11 May 2012 13:34:07 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21985 invoked from network); 11 May 2012 13:34:06 -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 May 2012 13:34:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100956" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Sv; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: ba3d30d721eef8c31b331bd2bac5b2f99d515511 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:33 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 4 of 4 v2] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pci-assignable-add will always store the driver rebind path, but pci-assignable-remove will only actually rebind if asked to do so. v2: - Use libxl_device_pci_init() instead of memset() - Call xlu_cfg_destroy() properly Signed-off-by: George Dunlap diff -r 5e21532dab5b -r ba3d30d721ee docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 11 13:55:04 2012 +0100 +++ b/docs/man/xl.pod.1 Fri May 11 14:19:50 2012 +0100 @@ -1026,6 +1026,26 @@ These are devices in the system which ar available for passthrough and are bound to a suitable PCI backend driver in domain 0 rather than a real driver. +=item B I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will bind the device to the pciback driver. If it is already bound to a +driver, it will first be unbound, and the original driver stored so that it +can be re-bound to the same driver later if desired. + +CAUTION: This will make the device unusable by Domain 0 until it is +returned with pci-assignable-remove. Care should therefore be taken +not to do this on a device critical to domain 0's operation, such as +storage controllers, network interfaces, or GPUs that are currently +being used. + +=item B [I<-r>] I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will at least unbind the device from pciback. If the -r option is specified, +it will also attempt to re-bind the device to its original driver, making it +usable by Domain 0 again. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl.h --- a/tools/libxl/xl.h Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl.h Fri May 11 14:19:50 2012 +0100 @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv int main_pcilist(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_add(int argc, char **argv); +int main_pciassignable_remove(int argc, char **argv); int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:19:50 2012 +0100 @@ -2368,6 +2368,86 @@ int main_pciassignable_list(int argc, ch return 0; } +static void pciassignable_add(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + libxl_device_pci_init(&pcidev); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); + + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); +} + +int main_pciassignable_add(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + } + } + + bdf = argv[optind]; + + pciassignable_add(bdf, 1); + return 0; +} + +static void pciassignable_remove(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + libxl_device_pci_init(&pcidev); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); + + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); +} + +int main_pciassignable_remove(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + int rebind = 0; + + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + case 'r': + rebind=1; + break; + } + } + + bdf = argv[optind]; + + pciassignable_remove(bdf, rebind); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Fri May 11 14:19:50 2012 +0100 @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, + { "pci-assignable-add", + &main_pciassignable_add, 0, + "Make a device assignable for pci-passthru", + "", + "-h Print this help.\n" + }, + { "pci-assignable-remove", + &main_pciassignable_remove, 0, + "Remove a device from being assignable", + "[options] ", + "-h Print this help.\n" + "-r Attempt to re-assign the device to the\n" + " original driver" + }, { "pci-assignable-list", &main_pciassignable_list, 0, "List all the assignable pci devices", _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpz0-00087q-Dk; Fri, 11 May 2012 13:34:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyy-00086q-HF for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:08 +0000 Received: from [85.158.138.51:46317] by server-12.bemta-3.messagelabs.com id B9/46-29760-F451DAF4; Fri, 11 May 2012 13:34:07 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21985 invoked from network); 11 May 2012 13:34:06 -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 May 2012 13:34:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100956" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Sv; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: ba3d30d721eef8c31b331bd2bac5b2f99d515511 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:33 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 4 of 4 v2] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org pci-assignable-add will always store the driver rebind path, but pci-assignable-remove will only actually rebind if asked to do so. v2: - Use libxl_device_pci_init() instead of memset() - Call xlu_cfg_destroy() properly Signed-off-by: George Dunlap diff -r 5e21532dab5b -r ba3d30d721ee docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 11 13:55:04 2012 +0100 +++ b/docs/man/xl.pod.1 Fri May 11 14:19:50 2012 +0100 @@ -1026,6 +1026,26 @@ These are devices in the system which ar available for passthrough and are bound to a suitable PCI backend driver in domain 0 rather than a real driver. +=item B I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will bind the device to the pciback driver. If it is already bound to a +driver, it will first be unbound, and the original driver stored so that it +can be re-bound to the same driver later if desired. + +CAUTION: This will make the device unusable by Domain 0 until it is +returned with pci-assignable-remove. Care should therefore be taken +not to do this on a device critical to domain 0's operation, such as +storage controllers, network interfaces, or GPUs that are currently +being used. + +=item B [I<-r>] I + +Make the device at PCI Bus/Device/Function BDF assignable to guests. This +will at least unbind the device from pciback. If the -r option is specified, +it will also attempt to re-bind the device to its original driver, making it +usable by Domain 0 again. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl.h --- a/tools/libxl/xl.h Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl.h Fri May 11 14:19:50 2012 +0100 @@ -36,6 +36,8 @@ int main_vncviewer(int argc, char **argv int main_pcilist(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_add(int argc, char **argv); +int main_pciassignable_remove(int argc, char **argv); int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:19:50 2012 +0100 @@ -2368,6 +2368,86 @@ int main_pciassignable_list(int argc, ch return 0; } +static void pciassignable_add(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + libxl_device_pci_init(&pcidev); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-add: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_add(ctx, &pcidev, rebind); + + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); +} + +int main_pciassignable_add(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + + while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + } + } + + bdf = argv[optind]; + + pciassignable_add(bdf, 1); + return 0; +} + +static void pciassignable_remove(const char *bdf, int rebind) +{ + libxl_device_pci pcidev; + XLU_Config *config; + + libxl_device_pci_init(&pcidev); + + config = xlu_cfg_init(stderr, "command line"); + if (!config) { perror("xlu_cfg_inig"); exit(-1); } + + if (xlu_pci_parse_bdf(config, &pcidev, bdf)) { + fprintf(stderr, "pci-assignable-remove: malformed BDF specification \"%s\"\n", bdf); + exit(2); + } + libxl_device_pci_assignable_remove(ctx, &pcidev, rebind); + + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); +} + +int main_pciassignable_remove(int argc, char **argv) +{ + int opt; + const char *bdf = NULL; + int rebind = 0; + + while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + case 'r': + rebind=1; + break; + } + } + + bdf = argv[optind]; + + pciassignable_remove(bdf, rebind); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 5e21532dab5b -r ba3d30d721ee tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Fri May 11 13:55:04 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Fri May 11 14:19:50 2012 +0100 @@ -86,6 +86,20 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, + { "pci-assignable-add", + &main_pciassignable_add, 0, + "Make a device assignable for pci-passthru", + "", + "-h Print this help.\n" + }, + { "pci-assignable-remove", + &main_pciassignable_remove, 0, + "Remove a device from being assignable", + "[options] ", + "-h Print this help.\n" + "-r Attempt to re-assign the device to the\n" + " original driver" + }, { "pci-assignable-list", &main_pciassignable_list, 0, "List all the assignable pci devices", _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyy-000872-25; Fri, 11 May 2012 13:34:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086g-6D for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:07 +0000 Received: from [85.158.138.51:46051] by server-5.bemta-3.messagelabs.com id 15/43-17113-E451DAF4; Fri, 11 May 2012 13:34:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21872 invoked from network); 11 May 2012 13:34:05 -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 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100954" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Qp; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:29 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 4 v2] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add commands to automatically prep devices for pass-through The current method for passing through devices requires users to either modify cryptic Linux boot parameters and reboot, or do a lot of manual reads and writes into sysfs nodes. This set of patches introduces commands to make this easier. It expands on the concept of "assignable" (from the list_assignable_devices command). The new xl commands are: pci_assignable_add: Make a device assignable to guests. This involves unbinding the device from its old driver, creating a slot for it in pciback (if necessary), and binding it to pciback. pci_assignable_list: List devices assignable to guests. Just renamed from pci_list_assignable. pci_assignable_remove: Make the device no longer assignable to guests. This involves unbinding the device from pciback and removing the slot. It optionally involves rebinding the device to the driver from which we stole it. Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyy-000872-25; Fri, 11 May 2012 13:34:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086g-6D for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:07 +0000 Received: from [85.158.138.51:46051] by server-5.bemta-3.messagelabs.com id 15/43-17113-E451DAF4; Fri, 11 May 2012 13:34:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21872 invoked from network); 11 May 2012 13:34:05 -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 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100954" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Qp; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:29 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 4 v2] Add commands to automatically prep devices for pass-through X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Add commands to automatically prep devices for pass-through The current method for passing through devices requires users to either modify cryptic Linux boot parameters and reboot, or do a lot of manual reads and writes into sysfs nodes. This set of patches introduces commands to make this easier. It expands on the concept of "assignable" (from the list_assignable_devices command). The new xl commands are: pci_assignable_add: Make a device assignable to guests. This involves unbinding the device from its old driver, creating a slot for it in pciback (if necessary), and binding it to pciback. pci_assignable_list: List devices assignable to guests. Just renamed from pci_list_assignable. pci_assignable_remove: Make the device no longer assignable to guests. This involves unbinding the device from pciback and removing the slot. It optionally involves rebinding the device to the driver from which we stole it. Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyz-00087Y-KV; Fri, 11 May 2012 13:34:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086l-Hn for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:07 +0000 Received: from [85.158.139.83:35046] by server-5.bemta-5.messagelabs.com id 4B/D3-13566-E451DAF4; Fri, 11 May 2012 13:34:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336743243!27202211!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17368 invoked from network); 11 May 2012 13:34:05 -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; 11 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194438073" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-SP; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5e21532dab5b1c31e54e70a2769b132e3cd5f633 Message-ID: <5e21532dab5b1c31e54e.1336743092@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:32 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 4 v2] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl helper functions to prepare devices to be passed through to guests. This is meant to replace of all the manual sysfs commands which are currently required. pci_assignable_add accepts a BDF for a device and will: * Unbind a device from its current driver, if any * If "rebind" is set, it will store the path of the driver from which we unplugged it in /libxl/pciback/$BDF/driver_path * If create a slot for it in pciback if one doesn't yet exist * Bind the device to pciback At this point it will show up in pci_assignable_list, and is ready to be passed through to a guest. pci_assignable_remove accepts a BDF for a device and will: * Unbind the device from pciback * Remove the slot from pciback * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will attempt to rebind the device to its original driver. NB that "$BDF" in this case uses '-' instead of ':' and '.', because ':' and '.' are illegal characters in xenstore paths. v2: - sysfs_dev_unbind uses a local var for the path pointer, and sets only at the end - Actually read pci domain when looking at slots, instead of assuming 0000 - Call LOG_ERRNO after failed sysfs_write_bdf calls, rather than just LOG - Removed stray FIXME - Made xenstore reads and writes single operations, and removed transaction infrastructure - Wrapped a couple of lines that were above 80 characters - Added a comment explaining the patch's treatment of slots - Clarified patch description of when it creates slots Signed-off-by: George Dunlap diff -r aa29f428a005 -r 5e21532dab5b tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri May 11 13:51:12 2012 +0100 +++ b/tools/libxl/libxl.h Fri May 11 13:55:04 2012 +0100 @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); /* - * Similar to libxl_device_pci_list but returns all devices which - * could be assigned to a domain (i.e. are bound to the backend - * driver) but are not currently. + * Functions related to making devices assignable -- that is, bound to + * the pciback driver, ready to be given to a guest via + * libxl_pci_device_add. + * + * - ..._add() will unbind the device from its current driver (if + * already bound) and re-bind it to pciback; at that point it will be + * ready to be assigned to a VM. If rebind is set, it will store the + * path to the old driver in xenstore so that it can be handed back to + * dom0 on restore. + * + * - ..._remove() will unbind the device from pciback, and if + * rebind is non-zero, attempt to assign it back to the driver + * from whence it came. + * + * - ..._list() will return a list of the PCI devices available to be + * assigned. */ +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ diff -r aa29f428a005 -r 5e21532dab5b tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 11 13:51:12 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:55:04 2012 +0100 @@ -21,6 +21,7 @@ #define PCI_BDF "%04x:%02x:%02x.%01x" #define PCI_BDF_SHORT "%02x:%02x.%01x" #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) { @@ -408,6 +409,334 @@ out: return pcidevs; } +/* Unbind device from its current driver, if any. If driver_path is non-NULL, + * store the path to the original driver in it. */ +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, + char **driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath, *dp = NULL; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( !lstat(spath, &st) ) { + /* Find the canonical path to the driver. */ + dp = libxl__zalloc(gc, PATH_MAX); + dp = realpath(spath, dp); + if ( !dp ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "realpath() failed"); + return -1; + } + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", + dp); + + /* Unbind from the old driver */ + spath = libxl__sprintf(gc, "%s/unbind", dp); + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); + return -1; + } + } + + if ( driver_path ) + *driver_path = dp; + + return 0; +} + +/* + * A brief comment about slots. I don't know what slots are for; however, + * I have by experimentation determined: + * - Before a device can be bound to pciback, its BDF must first be listed + * in pciback/slots + * - The way to get the BDF listed there is to write BDF to + * pciback/new_slot + * - Writing the same BDF to pciback/new_slot is not idempotent; it results + * in two entries of the BDF in pciback/slots + * It's not clear whether having two entries in pciback/slots is a problem + * or not. Just to be safe, this code does the conservative thing, and + * first checks to see if there is a slot, adding one only if one does not + * already exist. + */ + +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + FILE *f; + int rc = 0; + unsigned dom, bus, dev, func; + + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); + + if (f == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + SYSFS_PCIBACK_DRIVER"/slots"); + return ERROR_FAIL; + } + + while(fscanf(f, "%x:%x:%x.%x\n", &dom, &bus, &dev, &func)==3) { + if(dom == pcidev->domain + && bus == pcidev->bus + && dev == pcidev->dev + && func == pcidev->func) { + rc = 1; + goto out; + } + } +out: + fclose(f); + return rc; +} + +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath; + int rc; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, + pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = lstat(spath, &st); + + if( rc == 0 ) + return 1; + if ( rc < 0 && errno == ENOENT ) + return 0; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); + return -1; +} + +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Error checking for pciback slot"); + return ERROR_FAIL; + } else if (rc == 0) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + } + + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + return 0; +} + +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove from pciback */ + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); + return ERROR_FAIL; + } + + /* Remove slot if necessary */ + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't remove pciback slot"); + return ERROR_FAIL; + } + } + return 0; +} + +#define PCIBACK_INFO_PATH "/libxl/pciback" + +static void pci_assignable_driver_path_write(libxl__gc *gc, + libxl_device_pci *pcidev, + char *driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *path; + + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, + "Write of %s to node %s failed.", + driver_path, path); + } +} + +static char * pci_assignable_driver_path_read(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + return libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func)); +} + +static void pci_assignable_driver_path_remove(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove the xenstore entry */ + xs_rm(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func) ); +} + +static int libxl__device_pci_assignable_add(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned dom, bus, dev, func; + char *spath, *driver_path = NULL; + struct stat st; + + /* Local copy for convenience */ + dom = pcidev->domain; + bus = pcidev->bus; + dev = pcidev->dev; + func = pcidev->func; + + /* See if the device exists */ + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); + if ( lstat(spath, &st) ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); + return ERROR_FAIL; + } + + /* Check to see if it's already assigned to pciback */ + if ( pciback_dev_is_assigned(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", + dom, bus, dev, func); + return 0; + } + + /* Check to see if there's already a driver that we need to unbind from */ + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't unbind "PCI_BDF" from driver", + dom, bus, dev, func); + return ERROR_FAIL; + } + + /* Store driver_path for rebinding to dom0 */ + if ( rebind ) { + if ( driver_path ) { + pci_assignable_driver_path_write(gc, pcidev, driver_path); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + PCI_BDF" not bound to a driver, will not be rebound.", + dom, bus, dev, func); + } + } + + if ( pciback_dev_assign(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + + return 0; +} + +static int libxl__device_pci_assignable_remove(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + char *driver_path; + + /* Unbind from pciback */ + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); + return ERROR_FAIL; + } else if ( rc ) { + pciback_dev_unassign(gc, pcidev); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Not bound to pciback"); + } + + /* Rebind if necessary */ + driver_path = pci_assignable_driver_path_read(gc, pcidev); + + if ( driver_path ) { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", + driver_path); + + if ( sysfs_write_bdf(gc, + libxl__sprintf(gc, "%s/bind", driver_path), + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to %s", driver_path); + return -1; + } + } + + pci_assignable_driver_path_remove(gc, pcidev); + } else { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Couldn't find path for original driver; not rebinding"); + } + } + + return 0; +} + +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + + +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + /* * This function checks that all functions of a device are bound to pciback * driver. It also initialises a bit-mask of which function numbers are present _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyx-00086r-N7; Fri, 11 May 2012 13:34:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyw-00086f-8A for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:06 +0000 Received: from [85.158.139.83:2407] by server-7.bemta-5.messagelabs.com id 36/F9-16195-D451DAF4; Fri, 11 May 2012 13:34:05 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336743243!27202211!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17304 invoked from network); 11 May 2012 13:34:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 13:34:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194438072" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Rv; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: aa29f428a005383fed0e11c62292fa812325ebd6 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:31 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 4 v2] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ...to prepare for a consistent "pci_assignable_*" naming scheme. Also move the man page entry into the PCI PASS-THROUGH section, rather than the XEN HOST section. No functional changes. Signed-off-by: George Dunlap Acked-by: Ian Campbell diff -r 6e2d2728620b -r aa29f428a005 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 11 13:50:47 2012 +0100 +++ b/docs/man/xl.pod.1 Fri May 11 13:51:12 2012 +0100 @@ -687,13 +687,6 @@ explanatory. Prints the current uptime of the domains running. -=item B - -List all the assignable PCI devices. -These are devices in the system which are configured to be -available for passthrough and are bound to a suitable PCI -backend driver in domain 0 rather than a real driver. - =back =head1 SCHEDULER SUBCOMMANDS @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do =over 4 +=item B + +List all the assignable PCI devices. +These are devices in the system which are configured to be +available for passthrough and are bound to a suitable PCI +backend driver in domain 0 rather than a real driver. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/libxl.h Fri May 11 13:51:12 2012 +0100 @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( * could be assigned to a domain (i.e. are bound to the backend * driver) but are not currently. */ -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:51:12 2012 +0100 @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc return 0; } -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) { GC_INIT(ctx); libxl_device_pci *pcidevs = NULL, *new, *assigned; @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl libxl_device_pci *pcidevs; int num, i; - pcidevs = libxl_device_pci_list_assignable(ctx, &num); + pcidevs = libxl_device_pci_assignable_list(ctx, &num); for (i = 0; i < num; i++) { if (pcidevs[i].domain == pcidev->domain && pcidevs[i].bus == pcidev->bus && diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl.h --- a/tools/libxl/xl.h Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl.h Fri May 11 13:51:12 2012 +0100 @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv int main_console(int argc, char **argv); int main_vncviewer(int argc, char **argv); int main_pcilist(int argc, char **argv); -int main_pcilist_assignable(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 13:51:12 2012 +0100 @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv return 0; } -static void pcilist_assignable(void) -{ - libxl_device_pci *pcidevs; - int num, i; - - pcidevs = libxl_device_pci_list_assignable(ctx, &num); - - if ( pcidevs == NULL ) - return; - for (i = 0; i < num; i++) { - printf("%04x:%02x:%02x.%01x\n", - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); - libxl_device_pci_dispose(&pcidevs[i]); - } - free(pcidevs); -} - -int main_pcilist_assignable(int argc, char **argv) -{ - int opt; - - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) - return opt; - - pcilist_assignable(); - return 0; -} - static void pcilist(const char *dom) { libxl_device_pci *pcidevs; @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv return 0; } +static void pciassignable_list(void) +{ + libxl_device_pci *pcidevs; + int num, i; + + pcidevs = libxl_device_pci_assignable_list(ctx, &num); + + if ( pcidevs == NULL ) + return; + for (i = 0; i < num; i++) { + printf("%04x:%02x:%02x.%01x\n", + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + libxl_device_pci_dispose(&pcidevs[i]); + } + free(pcidevs); +} + +int main_pciassignable_list(int argc, char **argv) +{ + int opt; + + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) + return opt; + + pciassignable_list(); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Fri May 11 13:51:12 2012 +0100 @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, - { "pci-list-assignable-devices", - &main_pcilist_assignable, 0, + { "pci-assignable-list", + &main_pciassignable_list, 0, "List all the assignable pci devices", "", }, diff -r 6e2d2728620b -r aa29f428a005 tools/python/xen/lowlevel/xl/xl.c --- a/tools/python/xen/lowlevel/xl/xl.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/python/xen/lowlevel/xl/xl.c Fri May 11 13:51:12 2012 +0100 @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject return (PyObject *)pci; } -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) { libxl_device_pci *dev; PyObject *list; int nr_dev, i; - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { "Parse pass-through PCI device spec (BDF)"}, {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, "List PCI devices assigned to a domain"}, - {"device_pci_list_assignable", - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, + {"device_pci_assignable_list", + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, "List assignable PCI devices"}, { NULL, NULL, 0, NULL } }; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyz-00087Y-KV; Fri, 11 May 2012 13:34:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086l-Hn for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:07 +0000 Received: from [85.158.139.83:35046] by server-5.bemta-5.messagelabs.com id 4B/D3-13566-E451DAF4; Fri, 11 May 2012 13:34:06 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336743243!27202211!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17368 invoked from network); 11 May 2012 13:34:05 -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; 11 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194438073" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-SP; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: 5e21532dab5b1c31e54e70a2769b132e3cd5f633 Message-ID: <5e21532dab5b1c31e54e.1336743092@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:32 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 4 v2] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Introduce libxl helper functions to prepare devices to be passed through to guests. This is meant to replace of all the manual sysfs commands which are currently required. pci_assignable_add accepts a BDF for a device and will: * Unbind a device from its current driver, if any * If "rebind" is set, it will store the path of the driver from which we unplugged it in /libxl/pciback/$BDF/driver_path * If create a slot for it in pciback if one doesn't yet exist * Bind the device to pciback At this point it will show up in pci_assignable_list, and is ready to be passed through to a guest. pci_assignable_remove accepts a BDF for a device and will: * Unbind the device from pciback * Remove the slot from pciback * If "rebind" is set, and /libx/pciback/$BDF/driver_path exists, it will attempt to rebind the device to its original driver. NB that "$BDF" in this case uses '-' instead of ':' and '.', because ':' and '.' are illegal characters in xenstore paths. v2: - sysfs_dev_unbind uses a local var for the path pointer, and sets only at the end - Actually read pci domain when looking at slots, instead of assuming 0000 - Call LOG_ERRNO after failed sysfs_write_bdf calls, rather than just LOG - Removed stray FIXME - Made xenstore reads and writes single operations, and removed transaction infrastructure - Wrapped a couple of lines that were above 80 characters - Added a comment explaining the patch's treatment of slots - Clarified patch description of when it creates slots Signed-off-by: George Dunlap diff -r aa29f428a005 -r 5e21532dab5b tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri May 11 13:51:12 2012 +0100 +++ b/tools/libxl/libxl.h Fri May 11 13:55:04 2012 +0100 @@ -658,10 +658,25 @@ int libxl_device_pci_destroy(libxl_ctx * libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid, int *num); /* - * Similar to libxl_device_pci_list but returns all devices which - * could be assigned to a domain (i.e. are bound to the backend - * driver) but are not currently. + * Functions related to making devices assignable -- that is, bound to + * the pciback driver, ready to be given to a guest via + * libxl_pci_device_add. + * + * - ..._add() will unbind the device from its current driver (if + * already bound) and re-bind it to pciback; at that point it will be + * ready to be assigned to a VM. If rebind is set, it will store the + * path to the old driver in xenstore so that it can be handed back to + * dom0 on restore. + * + * - ..._remove() will unbind the device from pciback, and if + * rebind is non-zero, attempt to assign it back to the driver + * from whence it came. + * + * - ..._list() will return a list of the PCI devices available to be + * assigned. */ +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, int rebind); libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ diff -r aa29f428a005 -r 5e21532dab5b tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 11 13:51:12 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:55:04 2012 +0100 @@ -21,6 +21,7 @@ #define PCI_BDF "%04x:%02x:%02x.%01x" #define PCI_BDF_SHORT "%02x:%02x.%01x" #define PCI_BDF_VDEVFN "%04x:%02x:%02x.%01x@%02x" +#define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" static unsigned int pcidev_encode_bdf(libxl_device_pci *pcidev) { @@ -408,6 +409,334 @@ out: return pcidevs; } +/* Unbind device from its current driver, if any. If driver_path is non-NULL, + * store the path to the original driver in it. */ +static int sysfs_dev_unbind(libxl__gc *gc, libxl_device_pci *pcidev, + char **driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath, *dp = NULL; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF"/driver", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( !lstat(spath, &st) ) { + /* Find the canonical path to the driver. */ + dp = libxl__zalloc(gc, PATH_MAX); + dp = realpath(spath, dp); + if ( !dp ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "realpath() failed"); + return -1; + } + + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Driver re-plug path: %s", + dp); + + /* Unbind from the old driver */ + spath = libxl__sprintf(gc, "%s/unbind", dp); + if ( sysfs_write_bdf(gc, spath, pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device"); + return -1; + } + } + + if ( driver_path ) + *driver_path = dp; + + return 0; +} + +/* + * A brief comment about slots. I don't know what slots are for; however, + * I have by experimentation determined: + * - Before a device can be bound to pciback, its BDF must first be listed + * in pciback/slots + * - The way to get the BDF listed there is to write BDF to + * pciback/new_slot + * - Writing the same BDF to pciback/new_slot is not idempotent; it results + * in two entries of the BDF in pciback/slots + * It's not clear whether having two entries in pciback/slots is a problem + * or not. Just to be safe, this code does the conservative thing, and + * first checks to see if there is a slot, adding one only if one does not + * already exist. + */ + +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + FILE *f; + int rc = 0; + unsigned dom, bus, dev, func; + + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); + + if (f == NULL) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + SYSFS_PCIBACK_DRIVER"/slots"); + return ERROR_FAIL; + } + + while(fscanf(f, "%x:%x:%x.%x\n", &dom, &bus, &dev, &func)==3) { + if(dom == pcidev->domain + && bus == pcidev->bus + && dev == pcidev->dev + && func == pcidev->func) { + rc = 1; + goto out; + } + } +out: + fclose(f); + return rc; +} + +static int pciback_dev_is_assigned(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char * spath; + int rc; + struct stat st; + + spath = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/"PCI_BDF, + pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = lstat(spath, &st); + + if( rc == 0 ) + return 1; + if ( rc < 0 && errno == ENOENT ) + return 0; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Accessing %s", spath); + return -1; +} + +static int pciback_dev_assign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + + if ( (rc=pciback_dev_has_slot(gc, pcidev)) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Error checking for pciback slot"); + return ERROR_FAIL; + } else if (rc == 0) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/new_slot", + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + } + + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/bind", pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + return 0; +} + +static int pciback_dev_unassign(libxl__gc *gc, libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove from pciback */ + if ( sysfs_dev_unbind(gc, pcidev, NULL) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't unbind device!"); + return ERROR_FAIL; + } + + /* Remove slot if necessary */ + if ( pciback_dev_has_slot(gc, pcidev) > 0 ) { + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/remove_slot", + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't remove pciback slot"); + return ERROR_FAIL; + } + } + return 0; +} + +#define PCIBACK_INFO_PATH "/libxl/pciback" + +static void pci_assignable_driver_path_write(libxl__gc *gc, + libxl_device_pci *pcidev, + char *driver_path) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + char *path; + + path = libxl__sprintf(gc, PCIBACK_INFO_PATH"/"PCI_BDF_XSPATH"/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func); + if ( libxl__xs_write(gc, XBT_NULL, path, "%s", driver_path) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_WARNING, + "Write of %s to node %s failed.", + driver_path, path); + } +} + +static char * pci_assignable_driver_path_read(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + return libxl__xs_read(gc, XBT_NULL, + libxl__sprintf(gc, + PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH "/driver_path", + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func)); +} + +static void pci_assignable_driver_path_remove(libxl__gc *gc, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + + /* Remove the xenstore entry */ + xs_rm(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, PCIBACK_INFO_PATH "/" PCI_BDF_XSPATH, + pcidev->domain, + pcidev->bus, + pcidev->dev, + pcidev->func) ); +} + +static int libxl__device_pci_assignable_add(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + unsigned dom, bus, dev, func; + char *spath, *driver_path = NULL; + struct stat st; + + /* Local copy for convenience */ + dom = pcidev->domain; + bus = pcidev->bus; + dev = pcidev->dev; + func = pcidev->func; + + /* See if the device exists */ + spath = libxl__sprintf(gc, SYSFS_PCI_DEV"/"PCI_BDF, dom, bus, dev, func); + if ( lstat(spath, &st) ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't lstat %s", spath); + return ERROR_FAIL; + } + + /* Check to see if it's already assigned to pciback */ + if ( pciback_dev_is_assigned(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, PCI_BDF" already assigned to pciback", + dom, bus, dev, func); + return 0; + } + + /* Check to see if there's already a driver that we need to unbind from */ + if ( sysfs_dev_unbind(gc, pcidev, &driver_path ) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Couldn't unbind "PCI_BDF" from driver", + dom, bus, dev, func); + return ERROR_FAIL; + } + + /* Store driver_path for rebinding to dom0 */ + if ( rebind ) { + if ( driver_path ) { + pci_assignable_driver_path_write(gc, pcidev, driver_path); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + PCI_BDF" not bound to a driver, will not be rebound.", + dom, bus, dev, func); + } + } + + if ( pciback_dev_assign(gc, pcidev) ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Couldn't bind device to pciback!"); + return ERROR_FAIL; + } + + return 0; +} + +static int libxl__device_pci_assignable_remove(libxl__gc *gc, + libxl_device_pci *pcidev, + int rebind) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc; + char *driver_path; + + /* Unbind from pciback */ + if ( (rc=pciback_dev_is_assigned(gc, pcidev)) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Checking if pciback was assigned"); + return ERROR_FAIL; + } else if ( rc ) { + pciback_dev_unassign(gc, pcidev); + } else { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Not bound to pciback"); + } + + /* Rebind if necessary */ + driver_path = pci_assignable_driver_path_read(gc, pcidev); + + if ( driver_path ) { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_INFO, "Rebinding to driver at %s", + driver_path); + + if ( sysfs_write_bdf(gc, + libxl__sprintf(gc, "%s/bind", driver_path), + pcidev) < 0 ) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "Couldn't bind device to %s", driver_path); + return -1; + } + } + + pci_assignable_driver_path_remove(gc, pcidev); + } else { + if ( rebind ) { + LIBXL__LOG(ctx, LIBXL__LOG_WARNING, + "Couldn't find path for original driver; not rebinding"); + } + } + + return 0; +} + +int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_add(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + + +int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci *pcidev, + int rebind) +{ + GC_INIT(ctx); + int rc; + + rc = libxl__device_pci_assignable_remove(gc, pcidev, rebind); + + GC_FREE; + return rc; +} + /* * This function checks that all functions of a device are bound to pciback * driver. It also initialises a bit-mask of which function numbers are present _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpyx-00086r-N7; Fri, 11 May 2012 13:34:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyw-00086f-8A for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:06 +0000 Received: from [85.158.139.83:2407] by server-7.bemta-5.messagelabs.com id 36/F9-16195-D451DAF4; Fri, 11 May 2012 13:34:05 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336743243!27202211!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17304 invoked from network); 11 May 2012 13:34:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 13:34:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194438072" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-Rv; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: aa29f428a005383fed0e11c62292fa812325ebd6 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:31 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 4 v2] libxl: Rename pci_list_assignable to pci_assignable_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ...to prepare for a consistent "pci_assignable_*" naming scheme. Also move the man page entry into the PCI PASS-THROUGH section, rather than the XEN HOST section. No functional changes. Signed-off-by: George Dunlap Acked-by: Ian Campbell diff -r 6e2d2728620b -r aa29f428a005 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Fri May 11 13:50:47 2012 +0100 +++ b/docs/man/xl.pod.1 Fri May 11 13:51:12 2012 +0100 @@ -687,13 +687,6 @@ explanatory. Prints the current uptime of the domains running. -=item B - -List all the assignable PCI devices. -These are devices in the system which are configured to be -available for passthrough and are bound to a suitable PCI -backend driver in domain 0 rather than a real driver. - =back =head1 SCHEDULER SUBCOMMANDS @@ -1026,6 +1019,13 @@ List virtual network interfaces for a do =over 4 +=item B + +List all the assignable PCI devices. +These are devices in the system which are configured to be +available for passthrough and are bound to a suitable PCI +backend driver in domain 0 rather than a real driver. + =item B I I Hot-plug a new pass-through pci device to the specified domain. diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/libxl.h --- a/tools/libxl/libxl.h Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/libxl.h Fri May 11 13:51:12 2012 +0100 @@ -662,7 +662,7 @@ libxl_device_pci *libxl_device_pci_list( * could be assigned to a domain (i.e. are bound to the backend * driver) but are not currently. */ -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num); +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num); /* CPUID handling */ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:51:12 2012 +0100 @@ -357,7 +357,7 @@ static int sysfs_write_bdf(libxl__gc *gc return 0; } -libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) +libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num) { GC_INIT(ctx); libxl_device_pci *pcidevs = NULL, *new, *assigned; @@ -684,7 +684,7 @@ static int libxl_pcidev_assignable(libxl libxl_device_pci *pcidevs; int num, i; - pcidevs = libxl_device_pci_list_assignable(ctx, &num); + pcidevs = libxl_device_pci_assignable_list(ctx, &num); for (i = 0; i < num; i++) { if (pcidevs[i].domain == pcidev->domain && pcidevs[i].bus == pcidev->bus && diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl.h --- a/tools/libxl/xl.h Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl.h Fri May 11 13:51:12 2012 +0100 @@ -34,9 +34,9 @@ int main_cd_insert(int argc, char **argv int main_console(int argc, char **argv); int main_vncviewer(int argc, char **argv); int main_pcilist(int argc, char **argv); -int main_pcilist_assignable(int argc, char **argv); int main_pcidetach(int argc, char **argv); int main_pciattach(int argc, char **argv); +int main_pciassignable_list(int argc, char **argv); int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 13:51:12 2012 +0100 @@ -2223,34 +2223,6 @@ int main_vncviewer(int argc, char **argv return 0; } -static void pcilist_assignable(void) -{ - libxl_device_pci *pcidevs; - int num, i; - - pcidevs = libxl_device_pci_list_assignable(ctx, &num); - - if ( pcidevs == NULL ) - return; - for (i = 0; i < num; i++) { - printf("%04x:%02x:%02x.%01x\n", - pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); - libxl_device_pci_dispose(&pcidevs[i]); - } - free(pcidevs); -} - -int main_pcilist_assignable(int argc, char **argv) -{ - int opt; - - if ((opt = def_getopt(argc, argv, "", "pci-list-assignable-devices", 0)) != -1) - return opt; - - pcilist_assignable(); - return 0; -} - static void pcilist(const char *dom) { libxl_device_pci *pcidevs; @@ -2368,6 +2340,34 @@ int main_pciattach(int argc, char **argv return 0; } +static void pciassignable_list(void) +{ + libxl_device_pci *pcidevs; + int num, i; + + pcidevs = libxl_device_pci_assignable_list(ctx, &num); + + if ( pcidevs == NULL ) + return; + for (i = 0; i < num; i++) { + printf("%04x:%02x:%02x.%01x\n", + pcidevs[i].domain, pcidevs[i].bus, pcidevs[i].dev, pcidevs[i].func); + libxl_device_pci_dispose(&pcidevs[i]); + } + free(pcidevs); +} + +int main_pciassignable_list(int argc, char **argv) +{ + int opt; + + if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1) + return opt; + + pciassignable_list(); + return 0; +} + static void pause_domain(const char *p) { find_domain(p); diff -r 6e2d2728620b -r aa29f428a005 tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/libxl/xl_cmdtable.c Fri May 11 13:51:12 2012 +0100 @@ -86,8 +86,8 @@ struct cmd_spec cmd_table[] = { "List pass-through pci devices for a domain", "", }, - { "pci-list-assignable-devices", - &main_pcilist_assignable, 0, + { "pci-assignable-list", + &main_pciassignable_list, 0, "List all the assignable pci devices", "", }, diff -r 6e2d2728620b -r aa29f428a005 tools/python/xen/lowlevel/xl/xl.c --- a/tools/python/xen/lowlevel/xl/xl.c Fri May 11 13:50:47 2012 +0100 +++ b/tools/python/xen/lowlevel/xl/xl.c Fri May 11 13:51:12 2012 +0100 @@ -566,13 +566,13 @@ static PyObject *pyxl_pci_parse(XlObject return (PyObject *)pci; } -static PyObject *pyxl_pci_list_assignable(XlObject *self, PyObject *args) +static PyObject *pyxl_pci_assignable_list(XlObject *self, PyObject *args) { libxl_device_pci *dev; PyObject *list; int nr_dev, i; - dev = libxl_device_pci_list_assignable(self->ctx, &nr_dev); + dev = libxl_device_pci_assignable_list(self->ctx, &nr_dev); if ( dev == NULL ) { PyErr_SetString(xl_error_obj, "Cannot list assignable devices"); return NULL; @@ -662,8 +662,8 @@ static PyMethodDef pyxl_methods[] = { "Parse pass-through PCI device spec (BDF)"}, {"device_pci_list", (PyCFunction)pyxl_pci_list, METH_VARARGS, "List PCI devices assigned to a domain"}, - {"device_pci_list_assignable", - (PyCFunction)pyxl_pci_list_assignable, METH_NOARGS, + {"device_pci_assignable_list", + (PyCFunction)pyxl_pci_assignable_list, METH_NOARGS, "List assignable PCI devices"}, { NULL, NULL, 0, NULL } }; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpz0-00087h-0w; Fri, 11 May 2012 13:34:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086q-Ve for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:08 +0000 Received: from [85.158.138.51:46129] by server-12.bemta-3.messagelabs.com id 6D/36-29760-F451DAF4; Fri, 11 May 2012 13:34:07 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21927 invoked from network); 11 May 2012 13:34:05 -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 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100955" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-RR; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: 6e2d2728620b5b139c4ce98a2c31598d85822a86 Message-ID: <6e2d2728620b5b139c4c.1336743090@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:30 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 4 v2] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This functionality will be used several times in subsequent patches. Signed-off-by: George Dunlap Acked-by: Ian Campbell diff -r ef0365894118 -r 6e2d2728620b tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Thu May 10 14:26:47 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:50:47 2012 +0100 @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi return 0; } +/* Write the standard BDF into the sysfs path given by sysfs_path. */ +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc, fd; + char *buf; + + fd = open(sysfs_path, O_WRONLY); + if (fd < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + sysfs_path); + return ERROR_FAIL; + } + + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = write(fd, buf, strlen(buf)); + /* Annoying to have two if's, but we need the errno */ + if (rc < 0) + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "write to %s returned %d", sysfs_path, rc); + close(fd); + + if (rc < 0) + return ERROR_FAIL; + + return 0; +} + libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) { GC_INIT(ctx); @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin /* Don't restrict writes to the PCI config space from this VM */ if (pcidev->permissive) { - int fd; - char *buf; - - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); - fd = open(sysfs_path, O_WRONLY); - if (fd < 0) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", - sysfs_path); + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Setting permissive for device"); return ERROR_FAIL; } - - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, - pcidev->dev, pcidev->func); - rc = write(fd, buf, strlen(buf)); - /* Annoying to have two if's, but we need the errno */ - if (rc < 0) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "write to %s returned %d", sysfs_path, rc); - close(fd); - if (rc < 0) - return ERROR_FAIL; } break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 13:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 13: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 ) id 1SSpz0-00087h-0w; Fri, 11 May 2012 13:34:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpyx-00086q-Ve for xen-devel@lists.xensource.com; Fri, 11 May 2012 13:34:08 +0000 Received: from [85.158.138.51:46129] by server-12.bemta-3.messagelabs.com id 6D/36-29760-F451DAF4; Fri, 11 May 2012 13:34:07 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1336743243!24833275!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21927 invoked from network); 11 May 2012 13:34:05 -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 May 2012 13:34:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25100955" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 09:34:02 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 09:34:02 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSpyr-0002Rc-RR; Fri, 11 May 2012 14:34:01 +0100 MIME-Version: 1.0 X-Mercurial-Node: 6e2d2728620b5b139c4ce98a2c31598d85822a86 Message-ID: <6e2d2728620b5b139c4c.1336743090@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 14:31:30 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 4 v2] libxl: Make a helper function write a BDF to a sysfs path X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This functionality will be used several times in subsequent patches. Signed-off-by: George Dunlap Acked-by: Ian Campbell diff -r ef0365894118 -r 6e2d2728620b tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Thu May 10 14:26:47 2012 +0100 +++ b/tools/libxl/libxl_pci.c Fri May 11 13:50:47 2012 +0100 @@ -327,6 +327,36 @@ static int is_pcidev_in_array(libxl_devi return 0; } +/* Write the standard BDF into the sysfs path given by sysfs_path. */ +static int sysfs_write_bdf(libxl__gc *gc, const char * sysfs_path, + libxl_device_pci *pcidev) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc, fd; + char *buf; + + fd = open(sysfs_path, O_WRONLY); + if (fd < 0) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", + sysfs_path); + return ERROR_FAIL; + } + + buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, + pcidev->dev, pcidev->func); + rc = write(fd, buf, strlen(buf)); + /* Annoying to have two if's, but we need the errno */ + if (rc < 0) + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "write to %s returned %d", sysfs_path, rc); + close(fd); + + if (rc < 0) + return ERROR_FAIL; + + return 0; +} + libxl_device_pci *libxl_device_pci_list_assignable(libxl_ctx *ctx, int *num) { GC_INIT(ctx); @@ -571,27 +601,12 @@ static int do_pci_add(libxl__gc *gc, uin /* Don't restrict writes to the PCI config space from this VM */ if (pcidev->permissive) { - int fd; - char *buf; - - sysfs_path = libxl__sprintf(gc, SYSFS_PCIBACK_DRIVER"/permissive"); - fd = open(sysfs_path, O_WRONLY); - if (fd < 0) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", - sysfs_path); + if ( sysfs_write_bdf(gc, SYSFS_PCIBACK_DRIVER"/permissive", + pcidev) < 0 ) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "Setting permissive for device"); return ERROR_FAIL; } - - buf = libxl__sprintf(gc, PCI_BDF, pcidev->domain, pcidev->bus, - pcidev->dev, pcidev->func); - rc = write(fd, buf, strlen(buf)); - /* Annoying to have two if's, but we need the errno */ - if (rc < 0) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "write to %s returned %d", sysfs_path, rc); - close(fd); - if (rc < 0) - return ERROR_FAIL; } break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:08:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:08:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqVu-0000cs-IU; Fri, 11 May 2012 14:08:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqVs-0000cn-5e for xen-devel@lists.xen.org; Fri, 11 May 2012 14:08:08 +0000 Received: from [85.158.143.35:60896] by server-2.bemta-4.messagelabs.com id EE/8A-17550-74D1DAF4; Fri, 11 May 2012 14:08:07 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336745286!8429104!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8401 invoked from network); 11 May 2012 14:08:06 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:08:06 -0000 Received: by wgbed3 with SMTP id ed3so2081094wgb.32 for ; Fri, 11 May 2012 07:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lfIsuoVj+sqyOFJoWVTP3/2mKav2pey5DVzkM2xv6xE=; b=ydb4FGWDpwvvJpidyUB6cHv2xDBnJ4gkjy2QmB7xg2UuvVHTQ7AS5T233kBzL55NOH ncA1etRim4eSNya+BKgVXTFz5qQq4B/uGjx2+GwstEPbgT/9L+z2sOyYaxR1aDpoJBCr V8ZUhoYnNZebAWaLc0WM6XWJgHC+S0girsZxgJL6fIDuEOmrOPyqNZ+fcfxHRq57juht i0qg6Qf28DL/43zN/ZxsenP1hFiV7bD8CPrh3F+nSGIdUJklqZEl7BaPKk/4Vp5lr3NT GXriDklkS6x3V0GAn3n+5yvl37VIFwCLaQevapXEwlmzVBSy4Rmf93Yh/w5g1xG+XBkt FB/w== MIME-Version: 1.0 Received: by 10.180.106.9 with SMTP id gq9mr8074900wib.17.1336745286155; Fri, 11 May 2012 07:08:06 -0700 (PDT) Received: by 10.223.61.208 with HTTP; Fri, 11 May 2012 07:08:06 -0700 (PDT) Date: Fri, 11 May 2012 22:08:06 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4499938332538435427==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4499938332538435427== Content-Type: multipart/alternative; boundary=f46d04451a15efbc6c04bfc3430f --f46d04451a15efbc6c04bfc3430f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, When I do the "make install-tools" with xen-4.2-unstable, there are some errors about "warn_unused_result". Is it the error in code or the error in the compiling environment? Thank you so much. gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk-queue.o tapdisk-queue.c cc1: warnings being treated as errors tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92: tapdisk-queue.c:438: error: ignoring return value of =91read=92, declared w= ith attribute warn_unused_result make[5]: *** [tapdisk-queue.o] Error 1 make[5]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' make[4]: *** [subdir-install-drivers] Error 2 make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' make[2]: *** [subdir-install-blktap2] Error 2 make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' make: *** [install-tools] Error 2 ------ root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk-log.o tapdisk-log.c cc1: warnings being treated as errors tapdisk-log.c: In function =91tlog_flush=92: tapdisk-log.c:250: error: ignoring return value of =91write=92, declared wi= th attribute warn_unused_result ------ /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk2.o tapdisk2.c cc1: warnings being treated as errors tapdisk2.c: In function =91main=92: tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared with attribute warn_unused_result ------ cc1: warnings being treated as errors tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92: tapdisk-stream.c:148: error: ignoring return value of =91read=92, declared = with attribute warn_unused_result tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92: tapdisk-stream.c:158: error: ignoring return value of =91write=92, declared with attribute warn_unused_result tapdisk-stream.c: In function =91tapdisk_stream_print_request=92: tapdisk-stream.c:206: error: ignoring return value of =91write=92, declared with attribute warn_unused_result Best Regards, Bei Guan --f46d04451a15efbc6c04bfc3430f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

When I do the "make install-tools" with xen-4.2-unstab= le, there are some errors about "warn_unused_result".
Is it th= e error in code or the error in the compiling environment? Thank you so muc= h.


gcc=A0 -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -st= d=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement=A0=A0 -D_= _XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d=A0 -D_LARGEFILE_SOURCE -D_LARGEFIL= E64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-a= liasing -I../include -I../drivers -I/root/Xen/xen-4.2-unstable/tools/blktap= 2/drivers/../../../tools/libxc -I/root/Xen/xen-4.2-unstable/tools/blktap2/d= rivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/= Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src=A0 -c = -o tapdisk-queue.o tapdisk-queue.c
cc1: warnings being treated as errors
tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92:
tapdisk-queue.c:= 438: error: ignoring return value of =91read=92, declared with attribute wa= rn_unused_result
make[5]: *** [tapdisk-queue.o] Error 1
make[5]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools/blktap2/drivers'
make[4]: *** [subdir-in= stall-drivers] Error 2
make[4]: Leaving directory `/root/Xen/xen-4.2-uns= table/tools/blktap2'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools/blktap2'
make[2]: *** [subdir-install-bl= ktap2] Error 2
make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/to= ols'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools'
make: *** [install-tools] Error 2
--= ----
root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/liba= io/src=A0 -c -o tapdisk-log.o tapdisk-log.c
cc1: warnings being treated as errors
tapdisk-log.c: In function =91tlog_flush=92:
tapdisk-log.c:250: error: igno= ring return value of =91write=92, declared with attribute warn_unused_resul= t
------
/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/l= ibaio/src=A0 -c -o tapdisk2.o tapdisk2.c
cc1: warnings being treated as= errors
tapdisk2.c: In function =91ma= in=92:
tapdisk2.c:82: error: ignoring return va= lue of =91chdir=92, declared with attribute warn_unused_result
--= ----
cc1: warnings being treated as errors
tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92:
tapdisk-stream.c:148: error: ignoring re= turn value of =91read=92, declared with attribute warn_unused_result=
tapdisk= -stream.c: In function =91tapdisk_stream_poll_set=92:
tapdisk-stream.c:158: error: ignoring re= turn value of =91write=92, declared with attribute warn_unused_result
tapdis= k-stream.c: In function =91tapdisk_stream_print_request=92:
tapdisk-stream.c:206: error: ignoring re= turn value of =91write=92, declared with attribute warn_unused_result



Best Regards,
Bei Guan

--f46d04451a15efbc6c04bfc3430f-- --===============4499938332538435427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4499938332538435427==-- From xen-devel-bounces@lists.xen.org Fri May 11 14:08:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:08:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqVu-0000cs-IU; Fri, 11 May 2012 14:08:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqVs-0000cn-5e for xen-devel@lists.xen.org; Fri, 11 May 2012 14:08:08 +0000 Received: from [85.158.143.35:60896] by server-2.bemta-4.messagelabs.com id EE/8A-17550-74D1DAF4; Fri, 11 May 2012 14:08:07 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336745286!8429104!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8401 invoked from network); 11 May 2012 14:08:06 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:08:06 -0000 Received: by wgbed3 with SMTP id ed3so2081094wgb.32 for ; Fri, 11 May 2012 07:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lfIsuoVj+sqyOFJoWVTP3/2mKav2pey5DVzkM2xv6xE=; b=ydb4FGWDpwvvJpidyUB6cHv2xDBnJ4gkjy2QmB7xg2UuvVHTQ7AS5T233kBzL55NOH ncA1etRim4eSNya+BKgVXTFz5qQq4B/uGjx2+GwstEPbgT/9L+z2sOyYaxR1aDpoJBCr V8ZUhoYnNZebAWaLc0WM6XWJgHC+S0girsZxgJL6fIDuEOmrOPyqNZ+fcfxHRq57juht i0qg6Qf28DL/43zN/ZxsenP1hFiV7bD8CPrh3F+nSGIdUJklqZEl7BaPKk/4Vp5lr3NT GXriDklkS6x3V0GAn3n+5yvl37VIFwCLaQevapXEwlmzVBSy4Rmf93Yh/w5g1xG+XBkt FB/w== MIME-Version: 1.0 Received: by 10.180.106.9 with SMTP id gq9mr8074900wib.17.1336745286155; Fri, 11 May 2012 07:08:06 -0700 (PDT) Received: by 10.223.61.208 with HTTP; Fri, 11 May 2012 07:08:06 -0700 (PDT) Date: Fri, 11 May 2012 22:08:06 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4499938332538435427==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4499938332538435427== Content-Type: multipart/alternative; boundary=f46d04451a15efbc6c04bfc3430f --f46d04451a15efbc6c04bfc3430f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, When I do the "make install-tools" with xen-4.2-unstable, there are some errors about "warn_unused_result". Is it the error in code or the error in the compiling environment? Thank you so much. gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk-queue.o tapdisk-queue.c cc1: warnings being treated as errors tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92: tapdisk-queue.c:438: error: ignoring return value of =91read=92, declared w= ith attribute warn_unused_result make[5]: *** [tapdisk-queue.o] Error 1 make[5]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' make[4]: *** [subdir-install-drivers] Error 2 make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' make[2]: *** [subdir-install-blktap2] Error 2 make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' make: *** [install-tools] Error 2 ------ root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk-log.o tapdisk-log.c cc1: warnings being treated as errors tapdisk-log.c: In function =91tlog_flush=92: tapdisk-log.c:250: error: ignoring return value of =91write=92, declared wi= th attribute warn_unused_result ------ /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src -c -o tapdisk2.o tapdisk2.c cc1: warnings being treated as errors tapdisk2.c: In function =91main=92: tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared with attribute warn_unused_result ------ cc1: warnings being treated as errors tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92: tapdisk-stream.c:148: error: ignoring return value of =91read=92, declared = with attribute warn_unused_result tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92: tapdisk-stream.c:158: error: ignoring return value of =91write=92, declared with attribute warn_unused_result tapdisk-stream.c: In function =91tapdisk_stream_print_request=92: tapdisk-stream.c:206: error: ignoring return value of =91write=92, declared with attribute warn_unused_result Best Regards, Bei Guan --f46d04451a15efbc6c04bfc3430f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

When I do the "make install-tools" with xen-4.2-unstab= le, there are some errors about "warn_unused_result".
Is it th= e error in code or the error in the compiling environment? Thank you so muc= h.


gcc=A0 -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -st= d=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement=A0=A0 -D_= _XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d=A0 -D_LARGEFILE_SOURCE -D_LARGEFIL= E64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-a= liasing -I../include -I../drivers -I/root/Xen/xen-4.2-unstable/tools/blktap= 2/drivers/../../../tools/libxc -I/root/Xen/xen-4.2-unstable/tools/blktap2/d= rivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/= Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src=A0 -c = -o tapdisk-queue.o tapdisk-queue.c
cc1: warnings being treated as errors
tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92:
tapdisk-queue.c:= 438: error: ignoring return value of =91read=92, declared with attribute wa= rn_unused_result
make[5]: *** [tapdisk-queue.o] Error 1
make[5]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools/blktap2/drivers'
make[4]: *** [subdir-in= stall-drivers] Error 2
make[4]: Leaving directory `/root/Xen/xen-4.2-uns= table/tools/blktap2'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools/blktap2'
make[2]: *** [subdir-install-bl= ktap2] Error 2
make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/to= ols'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/root= /Xen/xen-4.2-unstable/tools'
make: *** [install-tools] Error 2
--= ----
root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/liba= io/src=A0 -c -o tapdisk-log.o tapdisk-log.c
cc1: warnings being treated as errors
tapdisk-log.c: In function =91tlog_flush=92:
tapdisk-log.c:250: error: igno= ring return value of =91write=92, declared with attribute warn_unused_resul= t
------
/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/l= ibaio/src=A0 -c -o tapdisk2.o tapdisk2.c
cc1: warnings being treated as= errors
tapdisk2.c: In function =91ma= in=92:
tapdisk2.c:82: error: ignoring return va= lue of =91chdir=92, declared with attribute warn_unused_result
--= ----
cc1: warnings being treated as errors
tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92:
tapdisk-stream.c:148: error: ignoring re= turn value of =91read=92, declared with attribute warn_unused_result=
tapdisk= -stream.c: In function =91tapdisk_stream_poll_set=92:
tapdisk-stream.c:158: error: ignoring re= turn value of =91write=92, declared with attribute warn_unused_result
tapdis= k-stream.c: In function =91tapdisk_stream_print_request=92:
tapdisk-stream.c:206: error: ignoring re= turn value of =91write=92, declared with attribute warn_unused_result



Best Regards,
Bei Guan

--f46d04451a15efbc6c04bfc3430f-- --===============4499938332538435427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4499938332538435427==-- From xen-devel-bounces@lists.xen.org Fri May 11 14:11:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqYk-0000iM-Om; Fri, 11 May 2012 14:11:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqYj-0000iH-GZ for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:11:05 +0000 Received: from [85.158.143.99:25895] by server-1.bemta-4.messagelabs.com id 9D/F7-20925-8FD1DAF4; Fri, 11 May 2012 14:11:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336745462!20035414!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24260 invoked from network); 11 May 2012 14:11:03 -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; 11 May 2012 14:11:03 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEB0YW008576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:11:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BEAxvP016764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:10:59 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 q4BEAw4s015717; Fri, 11 May 2012 09:10:58 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:10:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 19F6D40359; Fri, 11 May 2012 10:04:55 -0400 (EDT) Date: Fri, 11 May 2012 10:04:54 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511140454.GA13735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 03:06:14PM +0000, Liu, Jinsong wrote: > >From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 2001 > From: Liu, Jinsong > Date: Fri, 11 May 2012 06:55:35 +0800 > Subject: [PATCH 3/3] Xen physical cpus interface > > Manage physical cpus in dom0, get physical cpus info and provide sys interface. > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > --- > .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + > drivers/xen/Makefile | 1 + > drivers/xen/pcpu.c | 374 ++++++++++++++++++++ > include/xen/interface/platform.h | 8 + > include/xen/interface/xen.h | 1 + > 5 files changed, 404 insertions(+), 0 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu > create mode 100644 drivers/xen/pcpu.c > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu > new file mode 100644 > index 0000000..9ca02fb > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu > @@ -0,0 +1,20 @@ > +What: /sys/devices/system/xen_cpu/ > +Date: May 2012 > +Contact: Liu, Jinsong > +Description: > + A collection of global/individual Xen physical cpu attributes > + > + Individual physical cpu attributes are contained in > + subdirectories named by the Xen's logical cpu number, e.g.: > + /sys/devices/system/xen_cpu/xen_cpu#/ > + > + > +What: /sys/devices/system/xen_cpu/xen_cpu#/online > +Date: May 2012 > +Contact: Liu, Jinsong > +Description: > + Interface to online/offline Xen physical cpus > + > + When running under Xen platform, it provide user interface > + to online/offline physical cpus, except cpu0 due to several > + logic restrictions and assumptions. > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 1d3e763..d12d14d 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -19,6 +19,7 @@ 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_DOM0) += pcpu.o > obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ > obj-$(CONFIG_XEN_PRIVCMD) += xen-privcmd.o > obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o > diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c > new file mode 100644 > index 0000000..9014ff1 > --- /dev/null > +++ b/drivers/xen/pcpu.c > @@ -0,0 +1,374 @@ > +/****************************************************************************** > + * pcpu.c > + * Management physical cpu in dom0, get pcpu info and provide sys interface > + * > + * Copyright (c) 2012 Intel Corporation > + * Author: Liu, Jinsong > + * Author: Jiang, Yunhong > + * > + * This program is free software; you can 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 > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define XEN_PCPU "xen_cpu: " > + > +/* > + * @cpu_id: Xen physical cpu logic number > + * @flags: Xen physical cpu status flag > + * - XEN_PCPU_FLAGS_ONLINE: cpu is online > + * - XEN_PCPU_FLAGS_INVALID: cpu is not present > + */ > +struct pcpu { > + struct list_head list; > + struct device dev; > + uint32_t cpu_id; > + uint32_t flags; > +}; > + > +static struct bus_type xen_pcpu_subsys = { > + .name = "xen_cpu", > + .dev_name = "xen_cpu", > +}; > + > +static DEFINE_MUTEX(xen_pcpu_lock); > + > +static LIST_HEAD(xen_pcpus); So what about the recommendation to get rid of that and instead do struct pcpu *xen_cpu; and use that as a list? Meaning .. snip.. > +{ > + struct list_head *cur; > + struct pcpu *pcpu; > + > + list_for_each(cur, &xen_pcpus) { > + pcpu = list_entry(cur, struct pcpu, list); > + if (pcpu->cpu_id == cpu_id) > + return pcpu; > + } do: struct pcpu *pcpu; list_for_each_entry(pcpu, xen_pcpus, list) if (pcpu->cpu_id == cpu_id) return pcpu; ? and such. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:11:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqYk-0000iM-Om; Fri, 11 May 2012 14:11:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqYj-0000iH-GZ for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:11:05 +0000 Received: from [85.158.143.99:25895] by server-1.bemta-4.messagelabs.com id 9D/F7-20925-8FD1DAF4; Fri, 11 May 2012 14:11:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336745462!20035414!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24260 invoked from network); 11 May 2012 14:11:03 -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; 11 May 2012 14:11:03 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEB0YW008576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:11:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BEAxvP016764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:10:59 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 q4BEAw4s015717; Fri, 11 May 2012 09:10:58 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:10:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 19F6D40359; Fri, 11 May 2012 10:04:55 -0400 (EDT) Date: Fri, 11 May 2012 10:04:54 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511140454.GA13735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, May 10, 2012 at 03:06:14PM +0000, Liu, Jinsong wrote: > >From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 2001 > From: Liu, Jinsong > Date: Fri, 11 May 2012 06:55:35 +0800 > Subject: [PATCH 3/3] Xen physical cpus interface > > Manage physical cpus in dom0, get physical cpus info and provide sys interface. > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > --- > .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + > drivers/xen/Makefile | 1 + > drivers/xen/pcpu.c | 374 ++++++++++++++++++++ > include/xen/interface/platform.h | 8 + > include/xen/interface/xen.h | 1 + > 5 files changed, 404 insertions(+), 0 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-devices-system-xen_cpu > create mode 100644 drivers/xen/pcpu.c > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu > new file mode 100644 > index 0000000..9ca02fb > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu > @@ -0,0 +1,20 @@ > +What: /sys/devices/system/xen_cpu/ > +Date: May 2012 > +Contact: Liu, Jinsong > +Description: > + A collection of global/individual Xen physical cpu attributes > + > + Individual physical cpu attributes are contained in > + subdirectories named by the Xen's logical cpu number, e.g.: > + /sys/devices/system/xen_cpu/xen_cpu#/ > + > + > +What: /sys/devices/system/xen_cpu/xen_cpu#/online > +Date: May 2012 > +Contact: Liu, Jinsong > +Description: > + Interface to online/offline Xen physical cpus > + > + When running under Xen platform, it provide user interface > + to online/offline physical cpus, except cpu0 due to several > + logic restrictions and assumptions. > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 1d3e763..d12d14d 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -19,6 +19,7 @@ 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_DOM0) += pcpu.o > obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ > obj-$(CONFIG_XEN_PRIVCMD) += xen-privcmd.o > obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o > diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c > new file mode 100644 > index 0000000..9014ff1 > --- /dev/null > +++ b/drivers/xen/pcpu.c > @@ -0,0 +1,374 @@ > +/****************************************************************************** > + * pcpu.c > + * Management physical cpu in dom0, get pcpu info and provide sys interface > + * > + * Copyright (c) 2012 Intel Corporation > + * Author: Liu, Jinsong > + * Author: Jiang, Yunhong > + * > + * This program is free software; you can 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 > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define XEN_PCPU "xen_cpu: " > + > +/* > + * @cpu_id: Xen physical cpu logic number > + * @flags: Xen physical cpu status flag > + * - XEN_PCPU_FLAGS_ONLINE: cpu is online > + * - XEN_PCPU_FLAGS_INVALID: cpu is not present > + */ > +struct pcpu { > + struct list_head list; > + struct device dev; > + uint32_t cpu_id; > + uint32_t flags; > +}; > + > +static struct bus_type xen_pcpu_subsys = { > + .name = "xen_cpu", > + .dev_name = "xen_cpu", > +}; > + > +static DEFINE_MUTEX(xen_pcpu_lock); > + > +static LIST_HEAD(xen_pcpus); So what about the recommendation to get rid of that and instead do struct pcpu *xen_cpu; and use that as a list? Meaning .. snip.. > +{ > + struct list_head *cur; > + struct pcpu *pcpu; > + > + list_for_each(cur, &xen_pcpus) { > + pcpu = list_entry(cur, struct pcpu, list); > + if (pcpu->cpu_id == cpu_id) > + return pcpu; > + } do: struct pcpu *pcpu; list_for_each_entry(pcpu, xen_pcpus, list) if (pcpu->cpu_id == cpu_id) return pcpu; ? and such. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbq-0000ru-Oh; Fri, 11 May 2012 14:14:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbo-0000rN-HD for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:16 +0000 Received: from [85.158.143.35:31842] by server-2.bemta-4.messagelabs.com id CA/43-17550-7BE1DAF4; Fri, 11 May 2012 14:14:15 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10848 invoked from network); 11 May 2012 14:14:14 -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; 11 May 2012 14:14:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445107" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Lb; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:50 +0100 Message-ID: <1336745632-28158-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org NetBSD `python-conf --ldflags` doesn't return the library dir, so we have to add it to LDFLAGS based on the prefix returned by `python-conf --prefix`. Also the include dir has been added to CFLAGS using the same technique. If not passed the configure script fails on NetBSD, complaining it cannot find lpythonx.x library during the python_dev test phase. This is currently done on all OSes, since I think it's harmless to do this on other systems also. Signed-off-by: Roger Pau Monne --- tools/m4/python_devel.m4 | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4 index 0a2202c..61326df 100644 --- a/tools/m4/python_devel.m4 +++ b/tools/m4/python_devel.m4 @@ -23,8 +23,9 @@ AS_IF([test x"$pyconfig" == x"no"], [ print distutils.sysconfig.get_config_var("LDFLAGS")'`" ], [ dnl If python-config is found use it - CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`" - LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`" + ac_python_prefix=`$PYTHON-config --prefix` + CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include" + LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib" ]) AC_CHECK_HEADER([Python.h], [], -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbq-0000ru-Oh; Fri, 11 May 2012 14:14:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbo-0000rN-HD for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:16 +0000 Received: from [85.158.143.35:31842] by server-2.bemta-4.messagelabs.com id CA/43-17550-7BE1DAF4; Fri, 11 May 2012 14:14:15 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10848 invoked from network); 11 May 2012 14:14:14 -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; 11 May 2012 14:14:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445107" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Lb; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:50 +0100 Message-ID: <1336745632-28158-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org NetBSD `python-conf --ldflags` doesn't return the library dir, so we have to add it to LDFLAGS based on the prefix returned by `python-conf --prefix`. Also the include dir has been added to CFLAGS using the same technique. If not passed the configure script fails on NetBSD, complaining it cannot find lpythonx.x library during the python_dev test phase. This is currently done on all OSes, since I think it's harmless to do this on other systems also. Signed-off-by: Roger Pau Monne --- tools/m4/python_devel.m4 | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4 index 0a2202c..61326df 100644 --- a/tools/m4/python_devel.m4 +++ b/tools/m4/python_devel.m4 @@ -23,8 +23,9 @@ AS_IF([test x"$pyconfig" == x"no"], [ print distutils.sysconfig.get_config_var("LDFLAGS")'`" ], [ dnl If python-config is found use it - CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`" - LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`" + ac_python_prefix=`$PYTHON-config --prefix` + CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include" + LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib" ]) AC_CHECK_HEADER([Python.h], [], -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbr-0000s1-3g; Fri, 11 May 2012 14:14:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rU-8F for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:17 +0000 Received: from [85.158.143.35:31884] by server-1.bemta-4.messagelabs.com id 55/2C-20925-8BE1DAF4; Fri, 11 May 2012 14:14:16 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10885 invoked from network); 11 May 2012 14:14:15 -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; 11 May 2012 14:14:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445108" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Mg; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:52 +0100 Message-ID: <1336745632-28158-4-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Parse those options correctly, since the "+=" operator is not valid. Also added CPPFLAGS, so headers checks don't give strange results. Signed-off-by: Roger Pau Monne --- tools/m4/set_cflags_ldflags.m4 | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tools/m4/set_cflags_ldflags.m4 b/tools/m4/set_cflags_ldflags.m4 index 7e357ba..631e81c 100644 --- a/tools/m4/set_cflags_ldflags.m4 +++ b/tools/m4/set_cflags_ldflags.m4 @@ -1,20 +1,21 @@ AC_DEFUN([AX_SET_FLAGS], [for cflag in $PREPEND_INCLUDES do - PREPEND_CFLAGS+=" -I$cflag" + PREPEND_CFLAGS="$PREPEND_CFLAGS -I$cflag" done for ldflag in $PREPEND_LIB do - PREPEND_LDFLAGS+=" -L$ldflag" + PREPEND_LDFLAGS="$PREPEND_LDFLAGS -L$ldflag" done for cflag in $APPEND_INCLUDES do - APPEND_CFLAGS+=" -I$cflag" + APPEND_CFLAGS="$APPEND_CFLAGS -I$cflag" done for ldflag in $APPEND_LIB do - APPEND_LDFLAGS+=" -L$ldflag" + APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag" done CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS" +CPPFLAGS="$CFLAGS" LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"]) -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbr-0000s1-3g; Fri, 11 May 2012 14:14:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rU-8F for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:17 +0000 Received: from [85.158.143.35:31884] by server-1.bemta-4.messagelabs.com id 55/2C-20925-8BE1DAF4; Fri, 11 May 2012 14:14:16 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10885 invoked from network); 11 May 2012 14:14:15 -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; 11 May 2012 14:14:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445108" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Mg; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:52 +0100 Message-ID: <1336745632-28158-4-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Parse those options correctly, since the "+=" operator is not valid. Also added CPPFLAGS, so headers checks don't give strange results. Signed-off-by: Roger Pau Monne --- tools/m4/set_cflags_ldflags.m4 | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tools/m4/set_cflags_ldflags.m4 b/tools/m4/set_cflags_ldflags.m4 index 7e357ba..631e81c 100644 --- a/tools/m4/set_cflags_ldflags.m4 +++ b/tools/m4/set_cflags_ldflags.m4 @@ -1,20 +1,21 @@ AC_DEFUN([AX_SET_FLAGS], [for cflag in $PREPEND_INCLUDES do - PREPEND_CFLAGS+=" -I$cflag" + PREPEND_CFLAGS="$PREPEND_CFLAGS -I$cflag" done for ldflag in $PREPEND_LIB do - PREPEND_LDFLAGS+=" -L$ldflag" + PREPEND_LDFLAGS="$PREPEND_LDFLAGS -L$ldflag" done for cflag in $APPEND_INCLUDES do - APPEND_CFLAGS+=" -I$cflag" + APPEND_CFLAGS="$APPEND_CFLAGS -I$cflag" done for ldflag in $APPEND_LIB do - APPEND_LDFLAGS+=" -L$ldflag" + APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag" done CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS" +CPPFLAGS="$CFLAGS" LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"]) -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rW-CG; Fri, 11 May 2012 14:14:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbn-0000rG-O0 for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:15 +0000 Received: from [85.158.143.35:34953] by server-3.bemta-4.messagelabs.com id 06/71-05853-6BE1DAF4; Fri, 11 May 2012 14:14:14 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10820 invoked from network); 11 May 2012 14:14:14 -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; 11 May 2012 14:14:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445106" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Jl for xen-devel@lists.xen.org; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:49 +0100 Message-ID: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 0/3] Minor fixes to the build system for NetBSD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Small fixes to the build system to build out of the box on NetBSD. One patch has already been sent to the qemu-devel ml, to allow qemu upstream to build correctly on NetBSD. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rW-CG; Fri, 11 May 2012 14:14:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbn-0000rG-O0 for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:15 +0000 Received: from [85.158.143.35:34953] by server-3.bemta-4.messagelabs.com id 06/71-05853-6BE1DAF4; Fri, 11 May 2012 14:14:14 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10820 invoked from network); 11 May 2012 14:14:14 -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; 11 May 2012 14:14:14 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445106" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-Jl for xen-devel@lists.xen.org; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:49 +0100 Message-ID: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 0/3] Minor fixes to the build system for NetBSD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Small fixes to the build system to build out of the box on NetBSD. One patch has already been sent to the qemu-devel ml, to allow qemu upstream to build correctly on NetBSD. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbr-0000sB-Fz; Fri, 11 May 2012 14:14:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rN-KW for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:17 +0000 Received: from [85.158.143.35:35139] by server-2.bemta-4.messagelabs.com id 53/53-17550-9BE1DAF4; Fri, 11 May 2012 14:14:17 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10903 invoked from network); 11 May 2012 14:14: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; 11 May 2012 14:14:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445109" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-MA; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:51 +0100 Message-ID: <1336745632-28158-3-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org NetBSD doesn't have a gntdev, so libvchan is unable to build due to the lack of the header files gntalloc.h. This is the error: gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .init.o.d -fno-optimize-sibling-calls -I../include -I. -I/root/xen/xen-netbsd/tools/libvchan/../../tools/xenstore -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include -I/root/xen/xen-netbsd/tools/libvchan/../../tools/libxc -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include -c -o init.o init.c init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory compilation terminated. gmake[3]: *** [init.opic] Error 1 gmake[3]: *** Waiting for unfinished jobs.... init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory compilation terminated. Signed-off-by: Roger Pau Monne --- tools/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index a74df2f..18a58e8 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -30,7 +30,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen -SUBDIRS-y += libvchan +SUBDIRS-$(CONFIG_Linux) += libvchan # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbr-0000sB-Fz; Fri, 11 May 2012 14:14:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqbp-0000rN-KW for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:17 +0000 Received: from [85.158.143.35:35139] by server-2.bemta-4.messagelabs.com id 53/53-17550-9BE1DAF4; Fri, 11 May 2012 14:14:17 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336745652!11786164!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10903 invoked from network); 11 May 2012 14:14: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; 11 May 2012 14:14:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445109" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:13:55 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:13:55 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqbS-0003AN-MA; Fri, 11 May 2012 15:13:54 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 15:13:51 +0100 Message-ID: <1336745632-28158-3-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne Subject: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org NetBSD doesn't have a gntdev, so libvchan is unable to build due to the lack of the header files gntalloc.h. This is the error: gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .init.o.d -fno-optimize-sibling-calls -I../include -I. -I/root/xen/xen-netbsd/tools/libvchan/../../tools/xenstore -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include -I/root/xen/xen-netbsd/tools/libvchan/../../tools/libxc -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include -c -o init.o init.c init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory compilation terminated. gmake[3]: *** [init.opic] Error 1 gmake[3]: *** Waiting for unfinished jobs.... init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or directory compilation terminated. Signed-off-by: Roger Pau Monne --- tools/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index a74df2f..18a58e8 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -30,7 +30,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd SUBDIRS-y += libfsimage SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen -SUBDIRS-y += libvchan +SUBDIRS-$(CONFIG_Linux) += libvchan # do not recurse in to a dir we are about to delete ifneq "$(MAKECMDGOALS)" "distclean" -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqc3-0000vB-2p; Fri, 11 May 2012 14:14:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqc1-0000ub-JX for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:29 +0000 Received: from [85.158.138.51:8807] by server-3.bemta-3.messagelabs.com id C5/19-04048-4CE1DAF4; Fri, 11 May 2012 14:14:28 +0000 X-Env-Sender: dominic.curran@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336745666!17698391!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21372 invoked from network); 11 May 2012 14:14:27 -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; 11 May 2012 14:14:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445180" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:13 -0400 Received: from [10.80.2.144] (10.80.2.144) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:13 -0400 Message-ID: <4FAD2022.6050009@citrix.com> Date: Fri, 11 May 2012 15:20:18 +0100 From: Dominic Curran User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: , Subject: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Dominic Curran Date: Fri, 11 May 2012 12:24:42 +0100 Subject: [PATCH] xen: Fix a grant table resource leak If the resource (my testing shows an object in TX/RX ring) still has a reference held on it, then add to a list and kick-off a timer to try and free later. Signed-off-by: Dominic Curran --- drivers/xen/grant-table.c | 72 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 68 insertions(+), 4 deletions(-) Index: linux-2.6/drivers/xen/grant-table.c =================================================================== --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 13:52:54.000000000 +0100 +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 +0100 @@ -33,6 +33,7 @@ #include #include +#include #include #include #include @@ -57,6 +58,7 @@ (grant_table_version == 1 ? \ (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ (PAGE_SIZE / sizeof(union grant_entry_v2))) +#define GNTTAB_CLEANUP_TIMER 10 static grant_ref_t **gnttab_list; static unsigned int nr_grant_frames; @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; static DEFINE_SPINLOCK(gnttab_list_lock); unsigned long xen_hvm_resume_frames; EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); +static LIST_HEAD(gnttab_used_ref_list); +static DEFINE_SPINLOCK(gnttab_used_ref_lock); +static struct timer_list gnttab_timer; static union { struct grant_entry_v1 *v1; @@ -145,6 +150,16 @@ struct gnttab_ops { domid_t trans_domid, grant_ref_t trans_gref); }; +/* This structure is used to hold references to pages until they become + ready to free. +*/ +struct gnttab_used_ref { + struct list_head list; + grant_ref_t ref; + unsigned long page; + int readonly; +}; + static struct gnttab_ops *gnttab_interface; /*This reflects status of grant entries, so act as a global value*/ @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ } EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); +static void gnttab_attempt_clean_used_refs(unsigned long arg) +{ + struct gnttab_used_ref *u; + struct list_head *pos, *q; + unsigned long flags; + + spin_lock_irqsave(&gnttab_used_ref_lock, flags); + + list_for_each_safe(pos, q, &gnttab_used_ref_list) { + u = list_entry(pos, struct gnttab_used_ref, list); + + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { + list_del(pos); + + put_free_entry(u->ref); + if (u->page != 0) + free_page(u->page); + + kfree(u); + } + } + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); + + if (!list_empty(&gnttab_used_ref_list)) + mod_timer(&gnttab_timer, jiffies + HZ); +} + void gnttab_end_foreign_access(grant_ref_t ref, int readonly, unsigned long page) { + struct gnttab_used_ref *u; + unsigned long flags; + if (gnttab_end_foreign_access_ref(ref, readonly)) { put_free_entry(ref); if (page != 0) free_page(page); } else { - /* XXX This needs to be fixed so that the ref and page are - placed on a list to be freed up later. */ - printk(KERN_WARNING - "WARNING: leaking g.e. and page still in use!\n"); + /* References that aren't cleaned up immediately sit on + * a list until they are abandoned & can be cleaned safely. + */ + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); + if (!u) + return; + + u->page = page; + u->ref = ref; + u->readonly = readonly; + + spin_lock_irqsave(&gnttab_used_ref_lock, flags); + list_add(&(u->list), &gnttab_used_ref_list); + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); + + /* Kick off the cleanup timer. */ + if (!timer_pending(&gnttab_timer)) + add_timer(&gnttab_timer); } } EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); @@ -1068,6 +1127,11 @@ int gnttab_init(void) gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; gnttab_free_head = NR_RESERVED_ENTRIES; + init_timer(&gnttab_timer); + gnttab_timer.data = 0; + gnttab_timer.function = gnttab_attempt_clean_used_refs; + gnttab_timer.expires = jiffies + msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); + printk("Grant table initialized\n"); return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqc3-0000vB-2p; Fri, 11 May 2012 14:14:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqc1-0000ub-JX for xen-devel@lists.xen.org; Fri, 11 May 2012 14:14:29 +0000 Received: from [85.158.138.51:8807] by server-3.bemta-3.messagelabs.com id C5/19-04048-4CE1DAF4; Fri, 11 May 2012 14:14:28 +0000 X-Env-Sender: dominic.curran@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336745666!17698391!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21372 invoked from network); 11 May 2012 14:14:27 -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; 11 May 2012 14:14:27 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194445180" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:13 -0400 Received: from [10.80.2.144] (10.80.2.144) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:13 -0400 Message-ID: <4FAD2022.6050009@citrix.com> Date: Fri, 11 May 2012 15:20:18 +0100 From: Dominic Curran User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: , Subject: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Dominic Curran Date: Fri, 11 May 2012 12:24:42 +0100 Subject: [PATCH] xen: Fix a grant table resource leak If the resource (my testing shows an object in TX/RX ring) still has a reference held on it, then add to a list and kick-off a timer to try and free later. Signed-off-by: Dominic Curran --- drivers/xen/grant-table.c | 72 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 68 insertions(+), 4 deletions(-) Index: linux-2.6/drivers/xen/grant-table.c =================================================================== --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 13:52:54.000000000 +0100 +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 +0100 @@ -33,6 +33,7 @@ #include #include +#include #include #include #include @@ -57,6 +58,7 @@ (grant_table_version == 1 ? \ (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ (PAGE_SIZE / sizeof(union grant_entry_v2))) +#define GNTTAB_CLEANUP_TIMER 10 static grant_ref_t **gnttab_list; static unsigned int nr_grant_frames; @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; static DEFINE_SPINLOCK(gnttab_list_lock); unsigned long xen_hvm_resume_frames; EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); +static LIST_HEAD(gnttab_used_ref_list); +static DEFINE_SPINLOCK(gnttab_used_ref_lock); +static struct timer_list gnttab_timer; static union { struct grant_entry_v1 *v1; @@ -145,6 +150,16 @@ struct gnttab_ops { domid_t trans_domid, grant_ref_t trans_gref); }; +/* This structure is used to hold references to pages until they become + ready to free. +*/ +struct gnttab_used_ref { + struct list_head list; + grant_ref_t ref; + unsigned long page; + int readonly; +}; + static struct gnttab_ops *gnttab_interface; /*This reflects status of grant entries, so act as a global value*/ @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ } EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); +static void gnttab_attempt_clean_used_refs(unsigned long arg) +{ + struct gnttab_used_ref *u; + struct list_head *pos, *q; + unsigned long flags; + + spin_lock_irqsave(&gnttab_used_ref_lock, flags); + + list_for_each_safe(pos, q, &gnttab_used_ref_list) { + u = list_entry(pos, struct gnttab_used_ref, list); + + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { + list_del(pos); + + put_free_entry(u->ref); + if (u->page != 0) + free_page(u->page); + + kfree(u); + } + } + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); + + if (!list_empty(&gnttab_used_ref_list)) + mod_timer(&gnttab_timer, jiffies + HZ); +} + void gnttab_end_foreign_access(grant_ref_t ref, int readonly, unsigned long page) { + struct gnttab_used_ref *u; + unsigned long flags; + if (gnttab_end_foreign_access_ref(ref, readonly)) { put_free_entry(ref); if (page != 0) free_page(page); } else { - /* XXX This needs to be fixed so that the ref and page are - placed on a list to be freed up later. */ - printk(KERN_WARNING - "WARNING: leaking g.e. and page still in use!\n"); + /* References that aren't cleaned up immediately sit on + * a list until they are abandoned & can be cleaned safely. + */ + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); + if (!u) + return; + + u->page = page; + u->ref = ref; + u->readonly = readonly; + + spin_lock_irqsave(&gnttab_used_ref_lock, flags); + list_add(&(u->list), &gnttab_used_ref_list); + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); + + /* Kick off the cleanup timer. */ + if (!timer_pending(&gnttab_timer)) + add_timer(&gnttab_timer); } } EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); @@ -1068,6 +1127,11 @@ int gnttab_init(void) gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; gnttab_free_head = NR_RESERVED_ENTRIES; + init_timer(&gnttab_timer); + gnttab_timer.data = 0; + gnttab_timer.function = gnttab_attempt_clean_used_refs; + gnttab_timer.expires = jiffies + msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); + printk("Grant table initialized\n"); return 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqcC-000104-LP; Fri, 11 May 2012 14:14:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcB-0000yj-5d for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:39 +0000 Received: from [85.158.143.99:6752] by server-3.bemta-4.messagelabs.com id 22/12-05853-ECE1DAF4; Fri, 11 May 2012 14:14:38 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336745676!27235217!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17942 invoked from network); 11 May 2012 14:14:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102871" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-PZ; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:11:58 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 3] xl: Some clean-up X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xl: Some clean-up * Use libxl_device_pci_init instead of memset * Call xlu_cfg_destroy when necessary Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqcC-000104-LP; Fri, 11 May 2012 14:14:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcB-0000yj-5d for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:39 +0000 Received: from [85.158.143.99:6752] by server-3.bemta-4.messagelabs.com id 22/12-05853-ECE1DAF4; Fri, 11 May 2012 14:14:38 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336745676!27235217!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17942 invoked from network); 11 May 2012 14:14:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:37 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102871" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-PZ; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:11:58 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 0 of 3] xl: Some clean-up X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xl: Some clean-up * Use libxl_device_pci_init instead of memset * Call xlu_cfg_destroy when necessary Signed-off-by: George Dunlap _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yW-FI; Fri, 11 May 2012 14:14:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqc9-0000xj-6N for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:37 +0000 Received: from [193.109.254.147:17953] by server-7.bemta-14.messagelabs.com id 5C/2D-01627-CCE1DAF4; Fri, 11 May 2012 14:14:36 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13795 invoked from network); 11 May 2012 14:14:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102870" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-R1; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: 66ee1a4de61a886cad47c058a7eff1ab6a1073d2 Message-ID: <66ee1a4de61a886cad47.1336745519@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:11:59 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 3] xl: Replace memset with libxl_device_pci_init X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r ba3d30d721ee -r 66ee1a4de61a tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:19:50 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:45:30 2012 +0100 @@ -2264,7 +2264,7 @@ static void pcidetach(const char *dom, c find_domain(dom); - memset(&pcidev, 0x00, sizeof(pcidev)); + libxl_device_pci_init(&pcidev); config = xlu_cfg_init(stderr, "command line"); if (!config) { perror("xlu_cfg_inig"); exit(-1); } @@ -2309,7 +2309,7 @@ static void pciattach(const char *dom, c find_domain(dom); - memset(&pcidev, 0x00, sizeof(pcidev)); + libxl_device_pci_init(&pcidev); config = xlu_cfg_init(stderr, "command line"); if (!config) { perror("xlu_cfg_inig"); exit(-1); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yW-FI; Fri, 11 May 2012 14:14:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqc9-0000xj-6N for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:37 +0000 Received: from [193.109.254.147:17953] by server-7.bemta-14.messagelabs.com id 5C/2D-01627-CCE1DAF4; Fri, 11 May 2012 14:14:36 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13795 invoked from network); 11 May 2012 14:14:35 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:35 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102870" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-R1; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: 66ee1a4de61a886cad47c058a7eff1ab6a1073d2 Message-ID: <66ee1a4de61a886cad47.1336745519@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:11:59 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 1 of 3] xl: Replace memset with libxl_device_pci_init X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r ba3d30d721ee -r 66ee1a4de61a tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:19:50 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:45:30 2012 +0100 @@ -2264,7 +2264,7 @@ static void pcidetach(const char *dom, c find_domain(dom); - memset(&pcidev, 0x00, sizeof(pcidev)); + libxl_device_pci_init(&pcidev); config = xlu_cfg_init(stderr, "command line"); if (!config) { perror("xlu_cfg_inig"); exit(-1); } @@ -2309,7 +2309,7 @@ static void pciattach(const char *dom, c find_domain(dom); - memset(&pcidev, 0x00, sizeof(pcidev)); + libxl_device_pci_init(&pcidev); config = xlu_cfg_init(stderr, "command line"); if (!config) { perror("xlu_cfg_inig"); exit(-1); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcB-0000zO-SL; Fri, 11 May 2012 14:14:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yB-5J for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:38 +0000 Received: from [193.109.254.147:18033] by server-4.bemta-14.messagelabs.com id B2/22-11570-DCE1DAF4; Fri, 11 May 2012 14:14:37 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13865 invoked from network); 11 May 2012 14:14:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102872" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-Rk; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: 25a5ebd0117f6b594eff51d84bdfdfb079d406a6 Message-ID: <25a5ebd0117f6b594eff.1336745520@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:12:00 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 3] xl: Call xlu_cfg_destroy in the pciattach and pcidetach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r 66ee1a4de61a -r 25a5ebd0117f tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:45:30 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:49:22 2012 +0100 @@ -2277,7 +2277,9 @@ static void pcidetach(const char *dom, c libxl_device_pci_destroy(ctx, domid, &pcidev); else libxl_device_pci_remove(ctx, domid, &pcidev); + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); } int main_pcidetach(int argc, char **argv) @@ -2319,7 +2321,9 @@ static void pciattach(const char *dom, c exit(2); } libxl_device_pci_add(ctx, domid, &pcidev); + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); } int main_pciattach(int argc, char **argv) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcB-0000zO-SL; Fri, 11 May 2012 14:14:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yB-5J for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:38 +0000 Received: from [193.109.254.147:18033] by server-4.bemta-14.messagelabs.com id B2/22-11570-DCE1DAF4; Fri, 11 May 2012 14:14:37 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13865 invoked from network); 11 May 2012 14:14:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102872" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-Rk; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: 25a5ebd0117f6b594eff51d84bdfdfb079d406a6 Message-ID: <25a5ebd0117f6b594eff.1336745520@kodo2> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:12:00 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 2 of 3] xl: Call xlu_cfg_destroy in the pciattach and pcidetach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: George Dunlap diff -r 66ee1a4de61a -r 25a5ebd0117f tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:45:30 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 14:49:22 2012 +0100 @@ -2277,7 +2277,9 @@ static void pcidetach(const char *dom, c libxl_device_pci_destroy(ctx, domid, &pcidev); else libxl_device_pci_remove(ctx, domid, &pcidev); + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); } int main_pcidetach(int argc, char **argv) @@ -2319,7 +2321,9 @@ static void pciattach(const char *dom, c exit(2); } libxl_device_pci_add(ctx, domid, &pcidev); + libxl_device_pci_dispose(&pcidev); + xlu_cfg_destroy(config); } int main_pciattach(int argc, char **argv) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcC-0000zi-8Z; Fri, 11 May 2012 14:14:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yM-HX for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:38 +0000 Received: from [193.109.254.147:61950] by server-9.bemta-14.messagelabs.com id ED/90-05787-DCE1DAF4; Fri, 11 May 2012 14:14:37 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13901 invoked from network); 11 May 2012 14:14:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102873" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-T3; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: bf9a0309c2ba1bfe5daf9461dbe9ff85e31ce839 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:12:01 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 3] xl: Call xlu_cfg_destroy in main_cpupoolcreate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This involves making a goto clean-up path, rather than calling return directly. Signed-off-by: George Dunlap diff -r 25a5ebd0117f -r bf9a0309c2ba tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:49:22 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 15:07:51 2012 +0100 @@ -5677,6 +5677,7 @@ int main_cpupoolcreate(int argc, char ** libxl_cpumap cpumap; libxl_uuid uuid; libxl_cputopology *topology; + int rc = -ERROR_FAIL; while (1) { opt = getopt_long(argc, argv, "hnf:", long_options, &option_index); @@ -5710,7 +5711,7 @@ int main_cpupoolcreate(int argc, char ** filename = argv[optind]; } else { help("cpupool-create"); - return -ERROR_FAIL; + goto out; } optind++; } @@ -5721,7 +5722,7 @@ int main_cpupoolcreate(int argc, char ** &config_len)) { fprintf(stderr, "Failed to read config file: %s: %s\n", filename, strerror(errno)); - return -ERROR_FAIL; + goto out; } config_src=filename; } @@ -5731,13 +5732,13 @@ int main_cpupoolcreate(int argc, char ** if (strlen(extra_config)) { if (config_len > INT_MAX - (strlen(extra_config) + 2)) { fprintf(stderr, "Failed to attach extra configration\n"); - return -ERROR_FAIL; + goto out; } config_data = xrealloc(config_data, config_len + strlen(extra_config) + 2); if (!config_data) { fprintf(stderr, "Failed to realloc config_data\n"); - return -ERROR_FAIL; + goto out; } config_data[config_len] = 0; strcat(config_data, extra_config); @@ -5748,13 +5749,13 @@ int main_cpupoolcreate(int argc, char ** config = xlu_cfg_init(stderr, config_src); if (!config) { fprintf(stderr, "Failed to allocate for configuration\n"); - return -ERROR_FAIL; + goto out; } ret = xlu_cfg_readdata(config, config_data, config_len); if (ret) { fprintf(stderr, "Failed to parse config file: %s\n", strerror(ret)); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_string (config, "name", &buf, 0)) @@ -5763,32 +5764,32 @@ int main_cpupoolcreate(int argc, char ** name = libxl_basename(filename); else { fprintf(stderr, "Missing cpupool name!\n"); - return -ERROR_FAIL; + goto out_cfg; } if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) { fprintf(stderr, "Pool name \"%s\" already exists\n", name); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_string (config, "sched", &buf, 0)) { if ((libxl_scheduler_from_string(buf, &sched)) < 0) { fprintf(stderr, "Unknown scheduler\n"); - return -ERROR_FAIL; + goto out_cfg; } } else { if ((sched = libxl_get_scheduler(ctx)) < 0) { fprintf(stderr, "get_scheduler sysctl failed.\n"); - return -ERROR_FAIL; + goto out_cfg; } } if (libxl_get_freecpus(ctx, &freemap)) { fprintf(stderr, "libxl_get_freecpus failed\n"); - return -ERROR_FAIL; + goto out_cfg; } if (libxl_cpumap_alloc(ctx, &cpumap)) { fprintf(stderr, "Failed to allocate cpumap\n"); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) { int nr; @@ -5797,7 +5798,7 @@ int main_cpupoolcreate(int argc, char ** topology = libxl_get_cpu_topology(ctx, &nr); if (topology == NULL) { fprintf(stderr, "libxl_get_topologyinfo failed\n"); - return -ERROR_FAIL; + goto out_cfg; } while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) { n = atoi(buf); @@ -5815,7 +5816,7 @@ int main_cpupoolcreate(int argc, char ** if (n_cpus == 0) { fprintf(stderr, "no free cpu found\n"); - return -ERROR_FAIL; + goto out_cfg; } } else if (!xlu_cfg_get_list(config, "cpus", &cpus, 0, 0)) { n_cpus = 0; @@ -5824,7 +5825,7 @@ int main_cpupoolcreate(int argc, char ** if ((i < 0) || (i >= freemap.size * 8) || !libxl_cpumap_test(&freemap, i)) { fprintf(stderr, "cpu %d illegal or not free\n", i); - return -ERROR_FAIL; + goto out_cfg; } libxl_cpumap_set(&cpumap, i); n_cpus++; @@ -5839,16 +5840,20 @@ int main_cpupoolcreate(int argc, char ** printf("scheduler: %s\n", libxl_scheduler_to_string(sched)); printf("number of cpus: %d\n", n_cpus); - if (dryrun_only) - return 0; - - poolid = 0; - if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) { - fprintf(stderr, "error on creating cpupool\n"); - return -ERROR_FAIL; - } - - return 0; + if (!dryrun_only) { + poolid = 0; + if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) { + fprintf(stderr, "error on creating cpupool\n"); + goto out_cfg; + } + } + /* We made it! */ + rc = 0; + +out_cfg: + xlu_cfg_destroy(config); +out: + return rc; } int main_cpupoollist(int argc, char **argv) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcC-0000zi-8Z; Fri, 11 May 2012 14:14:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqcA-0000yM-HX for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:14:38 +0000 Received: from [193.109.254.147:61950] by server-9.bemta-14.messagelabs.com id ED/90-05787-DCE1DAF4; Fri, 11 May 2012 14:14:37 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336745674!1964857!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNDQ1MDg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13901 invoked from network); 11 May 2012 14:14:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:14:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="25102873" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:14:32 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:14:31 -0400 Received: from kodo2.uk.xensource.com ([10.80.227.109] helo=[127.0.1.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SSqc2-0003An-T3; Fri, 11 May 2012 15:14:30 +0100 MIME-Version: 1.0 X-Mercurial-Node: bf9a0309c2ba1bfe5daf9461dbe9ff85e31ce839 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Fri, 11 May 2012 15:12:01 +0100 From: George Dunlap To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com Subject: [Xen-devel] [PATCH 3 of 3] xl: Call xlu_cfg_destroy in main_cpupoolcreate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This involves making a goto clean-up path, rather than calling return directly. Signed-off-by: George Dunlap diff -r 25a5ebd0117f -r bf9a0309c2ba tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Fri May 11 14:49:22 2012 +0100 +++ b/tools/libxl/xl_cmdimpl.c Fri May 11 15:07:51 2012 +0100 @@ -5677,6 +5677,7 @@ int main_cpupoolcreate(int argc, char ** libxl_cpumap cpumap; libxl_uuid uuid; libxl_cputopology *topology; + int rc = -ERROR_FAIL; while (1) { opt = getopt_long(argc, argv, "hnf:", long_options, &option_index); @@ -5710,7 +5711,7 @@ int main_cpupoolcreate(int argc, char ** filename = argv[optind]; } else { help("cpupool-create"); - return -ERROR_FAIL; + goto out; } optind++; } @@ -5721,7 +5722,7 @@ int main_cpupoolcreate(int argc, char ** &config_len)) { fprintf(stderr, "Failed to read config file: %s: %s\n", filename, strerror(errno)); - return -ERROR_FAIL; + goto out; } config_src=filename; } @@ -5731,13 +5732,13 @@ int main_cpupoolcreate(int argc, char ** if (strlen(extra_config)) { if (config_len > INT_MAX - (strlen(extra_config) + 2)) { fprintf(stderr, "Failed to attach extra configration\n"); - return -ERROR_FAIL; + goto out; } config_data = xrealloc(config_data, config_len + strlen(extra_config) + 2); if (!config_data) { fprintf(stderr, "Failed to realloc config_data\n"); - return -ERROR_FAIL; + goto out; } config_data[config_len] = 0; strcat(config_data, extra_config); @@ -5748,13 +5749,13 @@ int main_cpupoolcreate(int argc, char ** config = xlu_cfg_init(stderr, config_src); if (!config) { fprintf(stderr, "Failed to allocate for configuration\n"); - return -ERROR_FAIL; + goto out; } ret = xlu_cfg_readdata(config, config_data, config_len); if (ret) { fprintf(stderr, "Failed to parse config file: %s\n", strerror(ret)); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_string (config, "name", &buf, 0)) @@ -5763,32 +5764,32 @@ int main_cpupoolcreate(int argc, char ** name = libxl_basename(filename); else { fprintf(stderr, "Missing cpupool name!\n"); - return -ERROR_FAIL; + goto out_cfg; } if (!libxl_name_to_cpupoolid(ctx, name, &poolid)) { fprintf(stderr, "Pool name \"%s\" already exists\n", name); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_string (config, "sched", &buf, 0)) { if ((libxl_scheduler_from_string(buf, &sched)) < 0) { fprintf(stderr, "Unknown scheduler\n"); - return -ERROR_FAIL; + goto out_cfg; } } else { if ((sched = libxl_get_scheduler(ctx)) < 0) { fprintf(stderr, "get_scheduler sysctl failed.\n"); - return -ERROR_FAIL; + goto out_cfg; } } if (libxl_get_freecpus(ctx, &freemap)) { fprintf(stderr, "libxl_get_freecpus failed\n"); - return -ERROR_FAIL; + goto out_cfg; } if (libxl_cpumap_alloc(ctx, &cpumap)) { fprintf(stderr, "Failed to allocate cpumap\n"); - return -ERROR_FAIL; + goto out_cfg; } if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) { int nr; @@ -5797,7 +5798,7 @@ int main_cpupoolcreate(int argc, char ** topology = libxl_get_cpu_topology(ctx, &nr); if (topology == NULL) { fprintf(stderr, "libxl_get_topologyinfo failed\n"); - return -ERROR_FAIL; + goto out_cfg; } while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) { n = atoi(buf); @@ -5815,7 +5816,7 @@ int main_cpupoolcreate(int argc, char ** if (n_cpus == 0) { fprintf(stderr, "no free cpu found\n"); - return -ERROR_FAIL; + goto out_cfg; } } else if (!xlu_cfg_get_list(config, "cpus", &cpus, 0, 0)) { n_cpus = 0; @@ -5824,7 +5825,7 @@ int main_cpupoolcreate(int argc, char ** if ((i < 0) || (i >= freemap.size * 8) || !libxl_cpumap_test(&freemap, i)) { fprintf(stderr, "cpu %d illegal or not free\n", i); - return -ERROR_FAIL; + goto out_cfg; } libxl_cpumap_set(&cpumap, i); n_cpus++; @@ -5839,16 +5840,20 @@ int main_cpupoolcreate(int argc, char ** printf("scheduler: %s\n", libxl_scheduler_to_string(sched)); printf("number of cpus: %d\n", n_cpus); - if (dryrun_only) - return 0; - - poolid = 0; - if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) { - fprintf(stderr, "error on creating cpupool\n"); - return -ERROR_FAIL; - } - - return 0; + if (!dryrun_only) { + poolid = 0; + if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) { + fprintf(stderr, "error on creating cpupool\n"); + goto out_cfg; + } + } + /* We made it! */ + rc = 0; + +out_cfg: + xlu_cfg_destroy(config); +out: + return rc; } int main_cpupoollist(int argc, char **argv) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:16:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqdv-0001bj-5L; Fri, 11 May 2012 14:16:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqdt-0001bA-Nq for xen-devel@lists.xen.org; Fri, 11 May 2012 14:16:25 +0000 Received: from [193.109.254.147:60808] by server-12.bemta-14.messagelabs.com id 35/DD-05898-93F1DAF4; Fri, 11 May 2012 14:16:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336745781!8785648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9598 invoked from network); 11 May 2012 14:16:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:16:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12431575" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14: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; Fri, 11 May 2012 15:16:21 +0100 Message-ID: <1336745780.23818.80.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan Date: Fri, 11 May 2012 15:16:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gRnJpLCAyMDEyLTA1LTExIGF0IDE1OjA4ICswMTAwLCBCZWkgR3VhbiB3cm90ZToKPiBXaGVu IEkgZG8gdGhlICJtYWtlIGluc3RhbGwtdG9vbHMiIHdpdGggeGVuLTQuMi11bnN0YWJsZSwgdGhl cmUgYXJlCj4gc29tZSBlcnJvcnMgYWJvdXQgIndhcm5fdW51c2VkX3Jlc3VsdCIuCj4gSXMgaXQg dGhlIGVycm9yIGluIGNvZGUgb3IgdGhlIGVycm9yIGluIHRoZSBjb21waWxpbmcgZW52aXJvbm1l bnQ/Cj4gVGhhbmsgeW91IHNvIG11Y2guCgpUaGlzIGNvbW1pdAogICAgICAgIGNoYW5nZXNldDog ICAyNTI3NToyN2Q2M2I5ZjExMWEKICAgICAgICB1c2VyOiAgICAgICAgS2VpciBGcmFzZXIgPGtl aXJAeGVuLm9yZz4KICAgICAgICBkYXRlOiAgICAgICAgVGh1IE1heSAxMCAxMToyMjoxOCAyMDEy ICswMTAwCiAgICAgICAgc3VtbWFyeTogICAgIGJsa3RhcDI6IERvIG5vdCBidWlsZCB3aXRoIC1P MApoYXMgY2F1c2VkIG1vcmUgd2FybmluZ3MgdG8gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBjb21waWxl ciwgd2hpY2ggaW4gdHVybgpsZWFkcyB0byBidWlsZCBmYWlsdXJlcy4gU2luY2UgdGhpcyBpcyBh IGNvbXBpbGVyIHNwZWNpZmljIHRoaW5nIHdlIGFyZQpzdGlsbCB0cmFja2luZyB0aGVtIGFsbCBk b3duLgoKQ2FuIHlvdSBjb25maXJtIHdoaWNoIHZlcnNpb25vZiB4ZW4tdW5zdGFibGUuaGcgeW91 IGFyZSB1c2luZyAtLSB0aGVyZQpoYXZlIGJlZW4gc2V2ZXJhbCBmaXh1cCBwYXRjaGVzIHNpbmNl IHRoZSBhYm92ZS4gSWYgeW91IGFyZSBjb21wbGV0ZWx5CnVwIHRvIGRhdGUgYW5kIHlvdSBzdGls bCBzZWUgZXJyb3JzIHdlIGNhbiBkaWcgaW50byB3aGF0ZXZlciBpcyBsZWZ0LgoKSWFuLiAoc3Rh cnRpbmcgdG8gdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSB3YXNuJ3Qgc3VpdGFibGUgZHVyaW5nIGEK ZmVhdHVyZSBmcmVlemUuLi4uKQoKPiAKPiAKPiBnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nCj4gLXN0ZD1nbnU5OSAtV2FsbCAtV3N0 cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50Cj4gLURfX1hFTl9U T09MU19fIC1NTUQgLU1GIC50YXBkaXNrLXF1ZXVlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRQo+ IC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLVdlcnJv ciAtZwo+IC1Xbm8tdW51c2VkIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JLi4vaW5jbHVkZSAtSS4u L2RyaXZlcnMKPiAtSS9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rvb2xzL2Jsa3RhcDIvZHJp dmVycy8uLi8uLi8uLi90b29scy9saWJ4YyAtSS9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rv b2xzL2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0Ug LURVU0VfTkZTX0xPQ0tTIC1mUElDIC1JIC9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9saWJhaW8vc3JjICAtYyAtbyB0YXBkaXNr LXF1ZXVlLm8gdGFwZGlzay1xdWV1ZS5jIAo+IGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBh cyBlcnJvcnMKPiB0YXBkaXNrLXF1ZXVlLmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfbGlvX2Fj a19ldmVudOKAmToKPiB0YXBkaXNrLXF1ZXVlLmM6NDM4OiBlcnJvcjogaWdub3JpbmcgcmV0dXJu IHZhbHVlIG9mIOKAmHJlYWTigJksIGRlY2xhcmVkCj4gd2l0aCBhdHRyaWJ1dGUgd2Fybl91bnVz ZWRfcmVzdWx0Cj4gbWFrZVs1XTogKioqIFt0YXBkaXNrLXF1ZXVlLm9dIEVycm9yIDEKPiBtYWtl WzVdOiBMZWF2aW5nIGRpcmVjdG9yeQo+IGAvcm9vdC9YZW4veGVuLTQuMi11bnN0YWJsZS90b29s cy9ibGt0YXAyL2RyaXZlcnMnCj4gbWFrZVs0XTogKioqIFtzdWJkaXItaW5zdGFsbC1kcml2ZXJz XSBFcnJvciAyCj4gbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9yb290L1hlbi94ZW4tNC4y LXVuc3RhYmxlL3Rvb2xzL2Jsa3RhcDInCj4gbWFrZVszXTogKioqIFtzdWJkaXJzLWluc3RhbGxd IEVycm9yIDIKPiBtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hlbi00LjIt dW5zdGFibGUvdG9vbHMvYmxrdGFwMicKPiBtYWtlWzJdOiAqKiogW3N1YmRpci1pbnN0YWxsLWJs a3RhcDJdIEVycm9yIDIKPiBtYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hl bi00LjItdW5zdGFibGUvdG9vbHMnCj4gbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVy cm9yIDIKPiBtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hlbi00LjItdW5z dGFibGUvdG9vbHMnCj4gbWFrZTogKioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gLS0tLS0t Cj4gcm9vdC9YZW4veGVuLTQuMi11bnN0YWJsZS90b29scy9ibGt0YXAyL2RyaXZlcnMvLi4vLi4v Li4vdG9vbHMvbGliYWlvL3NyYyAgLWMgLW8gdGFwZGlzay1sb2cubyB0YXBkaXNrLWxvZy5jIAo+ IGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiB0YXBkaXNrLWxvZy5jOiBJ biBmdW5jdGlvbiDigJh0bG9nX2ZsdXNo4oCZOgo+IHRhcGRpc2stbG9nLmM6MjUwOiBlcnJvcjog aWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mIOKAmHdyaXRl4oCZLCBkZWNsYXJlZAo+IHdpdGggYXR0 cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IC0tLS0tLQo+IC9yb290L1hlbi94ZW4tNC4yLXVu c3RhYmxlL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9saWJhaW8vc3JjICAt YyAtbyB0YXBkaXNrMi5vIHRhcGRpc2syLmMgCj4gY2MxOiB3YXJuaW5ncyBiZWluZyB0cmVhdGVk IGFzIGVycm9ycwo+IHRhcGRpc2syLmM6IEluIGZ1bmN0aW9uIOKAmG1haW7igJk6Cj4gdGFwZGlz azIuYzo4MjogZXJyb3I6IGlnbm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhjaGRpcuKAmSwgZGVj bGFyZWQgd2l0aAo+IGF0dHJpYnV0ZSB3YXJuX3VudXNlZF9yZXN1bHQKPiAtLS0tLS0KPiBjYzE6 IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4gdGFwZGlzay1zdHJlYW0uYzogSW4g ZnVuY3Rpb24g4oCYdGFwZGlza19zdHJlYW1fcG9sbF9jbGVhcuKAmToKPiB0YXBkaXNrLXN0cmVh bS5jOjE0ODogZXJyb3I6IGlnbm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZLCBkZWNs YXJlZAo+IHdpdGggYXR0cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IHRhcGRpc2stc3RyZWFt LmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfc3RyZWFtX3BvbGxfc2V04oCZOgo+IHRhcGRpc2st c3RyZWFtLmM6MTU4OiBlcnJvcjogaWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mIOKAmHdyaXRl4oCZ LAo+IGRlY2xhcmVkIHdpdGggYXR0cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IHRhcGRpc2st c3RyZWFtLmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfc3RyZWFtX3ByaW50X3JlcXVlc3TigJk6 Cj4gdGFwZGlzay1zdHJlYW0uYzoyMDY6IGVycm9yOiBpZ25vcmluZyByZXR1cm4gdmFsdWUgb2Yg 4oCYd3JpdGXigJksCj4gZGVjbGFyZWQgd2l0aCBhdHRyaWJ1dGUgd2Fybl91bnVzZWRfcmVzdWx0 Cj4gCj4gCj4gCj4gQmVzdCBSZWdhcmRzLAo+IEJlaSBHdWFuCj4gCgoKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 11 14:16:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqdv-0001bj-5L; Fri, 11 May 2012 14:16:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqdt-0001bA-Nq for xen-devel@lists.xen.org; Fri, 11 May 2012 14:16:25 +0000 Received: from [193.109.254.147:60808] by server-12.bemta-14.messagelabs.com id 35/DD-05898-93F1DAF4; Fri, 11 May 2012 14:16:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336745781!8785648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9598 invoked from network); 11 May 2012 14:16:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 14:16:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12431575" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14: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; Fri, 11 May 2012 15:16:21 +0100 Message-ID: <1336745780.23818.80.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan Date: Fri, 11 May 2012 15:16:20 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gRnJpLCAyMDEyLTA1LTExIGF0IDE1OjA4ICswMTAwLCBCZWkgR3VhbiB3cm90ZToKPiBXaGVu IEkgZG8gdGhlICJtYWtlIGluc3RhbGwtdG9vbHMiIHdpdGggeGVuLTQuMi11bnN0YWJsZSwgdGhl cmUgYXJlCj4gc29tZSBlcnJvcnMgYWJvdXQgIndhcm5fdW51c2VkX3Jlc3VsdCIuCj4gSXMgaXQg dGhlIGVycm9yIGluIGNvZGUgb3IgdGhlIGVycm9yIGluIHRoZSBjb21waWxpbmcgZW52aXJvbm1l bnQ/Cj4gVGhhbmsgeW91IHNvIG11Y2guCgpUaGlzIGNvbW1pdAogICAgICAgIGNoYW5nZXNldDog ICAyNTI3NToyN2Q2M2I5ZjExMWEKICAgICAgICB1c2VyOiAgICAgICAgS2VpciBGcmFzZXIgPGtl aXJAeGVuLm9yZz4KICAgICAgICBkYXRlOiAgICAgICAgVGh1IE1heSAxMCAxMToyMjoxOCAyMDEy ICswMTAwCiAgICAgICAgc3VtbWFyeTogICAgIGJsa3RhcDI6IERvIG5vdCBidWlsZCB3aXRoIC1P MApoYXMgY2F1c2VkIG1vcmUgd2FybmluZ3MgdG8gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBjb21waWxl ciwgd2hpY2ggaW4gdHVybgpsZWFkcyB0byBidWlsZCBmYWlsdXJlcy4gU2luY2UgdGhpcyBpcyBh IGNvbXBpbGVyIHNwZWNpZmljIHRoaW5nIHdlIGFyZQpzdGlsbCB0cmFja2luZyB0aGVtIGFsbCBk b3duLgoKQ2FuIHlvdSBjb25maXJtIHdoaWNoIHZlcnNpb25vZiB4ZW4tdW5zdGFibGUuaGcgeW91 IGFyZSB1c2luZyAtLSB0aGVyZQpoYXZlIGJlZW4gc2V2ZXJhbCBmaXh1cCBwYXRjaGVzIHNpbmNl IHRoZSBhYm92ZS4gSWYgeW91IGFyZSBjb21wbGV0ZWx5CnVwIHRvIGRhdGUgYW5kIHlvdSBzdGls bCBzZWUgZXJyb3JzIHdlIGNhbiBkaWcgaW50byB3aGF0ZXZlciBpcyBsZWZ0LgoKSWFuLiAoc3Rh cnRpbmcgdG8gdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSB3YXNuJ3Qgc3VpdGFibGUgZHVyaW5nIGEK ZmVhdHVyZSBmcmVlemUuLi4uKQoKPiAKPiAKPiBnY2MgIC1PMSAtZm5vLW9taXQtZnJhbWUtcG9p bnRlciAtbTY0IC1nIC1mbm8tc3RyaWN0LWFsaWFzaW5nCj4gLXN0ZD1nbnU5OSAtV2FsbCAtV3N0 cmljdC1wcm90b3R5cGVzIC1XZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50Cj4gLURfX1hFTl9U T09MU19fIC1NTUQgLU1GIC50YXBkaXNrLXF1ZXVlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRQo+ IC1EX0xBUkdFRklMRTY0X1NPVVJDRSAtZm5vLW9wdGltaXplLXNpYmxpbmctY2FsbHMgLVdlcnJv ciAtZwo+IC1Xbm8tdW51c2VkIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JLi4vaW5jbHVkZSAtSS4u L2RyaXZlcnMKPiAtSS9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rvb2xzL2Jsa3RhcDIvZHJp dmVycy8uLi8uLi8uLi90b29scy9saWJ4YyAtSS9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rv b2xzL2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0Ug LURVU0VfTkZTX0xPQ0tTIC1mUElDIC1JIC9yb290L1hlbi94ZW4tNC4yLXVuc3RhYmxlL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9saWJhaW8vc3JjICAtYyAtbyB0YXBkaXNr LXF1ZXVlLm8gdGFwZGlzay1xdWV1ZS5jIAo+IGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBh cyBlcnJvcnMKPiB0YXBkaXNrLXF1ZXVlLmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfbGlvX2Fj a19ldmVudOKAmToKPiB0YXBkaXNrLXF1ZXVlLmM6NDM4OiBlcnJvcjogaWdub3JpbmcgcmV0dXJu IHZhbHVlIG9mIOKAmHJlYWTigJksIGRlY2xhcmVkCj4gd2l0aCBhdHRyaWJ1dGUgd2Fybl91bnVz ZWRfcmVzdWx0Cj4gbWFrZVs1XTogKioqIFt0YXBkaXNrLXF1ZXVlLm9dIEVycm9yIDEKPiBtYWtl WzVdOiBMZWF2aW5nIGRpcmVjdG9yeQo+IGAvcm9vdC9YZW4veGVuLTQuMi11bnN0YWJsZS90b29s cy9ibGt0YXAyL2RyaXZlcnMnCj4gbWFrZVs0XTogKioqIFtzdWJkaXItaW5zdGFsbC1kcml2ZXJz XSBFcnJvciAyCj4gbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9yb290L1hlbi94ZW4tNC4y LXVuc3RhYmxlL3Rvb2xzL2Jsa3RhcDInCj4gbWFrZVszXTogKioqIFtzdWJkaXJzLWluc3RhbGxd IEVycm9yIDIKPiBtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hlbi00LjIt dW5zdGFibGUvdG9vbHMvYmxrdGFwMicKPiBtYWtlWzJdOiAqKiogW3N1YmRpci1pbnN0YWxsLWJs a3RhcDJdIEVycm9yIDIKPiBtYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hl bi00LjItdW5zdGFibGUvdG9vbHMnCj4gbWFrZVsxXTogKioqIFtzdWJkaXJzLWluc3RhbGxdIEVy cm9yIDIKPiBtYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jvb3QvWGVuL3hlbi00LjItdW5z dGFibGUvdG9vbHMnCj4gbWFrZTogKioqIFtpbnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gLS0tLS0t Cj4gcm9vdC9YZW4veGVuLTQuMi11bnN0YWJsZS90b29scy9ibGt0YXAyL2RyaXZlcnMvLi4vLi4v Li4vdG9vbHMvbGliYWlvL3NyYyAgLWMgLW8gdGFwZGlzay1sb2cubyB0YXBkaXNrLWxvZy5jIAo+ IGNjMTogd2FybmluZ3MgYmVpbmcgdHJlYXRlZCBhcyBlcnJvcnMKPiB0YXBkaXNrLWxvZy5jOiBJ biBmdW5jdGlvbiDigJh0bG9nX2ZsdXNo4oCZOgo+IHRhcGRpc2stbG9nLmM6MjUwOiBlcnJvcjog aWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mIOKAmHdyaXRl4oCZLCBkZWNsYXJlZAo+IHdpdGggYXR0 cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IC0tLS0tLQo+IC9yb290L1hlbi94ZW4tNC4yLXVu c3RhYmxlL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy8uLi8uLi8uLi90b29scy9saWJhaW8vc3JjICAt YyAtbyB0YXBkaXNrMi5vIHRhcGRpc2syLmMgCj4gY2MxOiB3YXJuaW5ncyBiZWluZyB0cmVhdGVk IGFzIGVycm9ycwo+IHRhcGRpc2syLmM6IEluIGZ1bmN0aW9uIOKAmG1haW7igJk6Cj4gdGFwZGlz azIuYzo4MjogZXJyb3I6IGlnbm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhjaGRpcuKAmSwgZGVj bGFyZWQgd2l0aAo+IGF0dHJpYnV0ZSB3YXJuX3VudXNlZF9yZXN1bHQKPiAtLS0tLS0KPiBjYzE6 IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCj4gdGFwZGlzay1zdHJlYW0uYzogSW4g ZnVuY3Rpb24g4oCYdGFwZGlza19zdHJlYW1fcG9sbF9jbGVhcuKAmToKPiB0YXBkaXNrLXN0cmVh bS5jOjE0ODogZXJyb3I6IGlnbm9yaW5nIHJldHVybiB2YWx1ZSBvZiDigJhyZWFk4oCZLCBkZWNs YXJlZAo+IHdpdGggYXR0cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IHRhcGRpc2stc3RyZWFt LmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfc3RyZWFtX3BvbGxfc2V04oCZOgo+IHRhcGRpc2st c3RyZWFtLmM6MTU4OiBlcnJvcjogaWdub3JpbmcgcmV0dXJuIHZhbHVlIG9mIOKAmHdyaXRl4oCZ LAo+IGRlY2xhcmVkIHdpdGggYXR0cmlidXRlIHdhcm5fdW51c2VkX3Jlc3VsdAo+IHRhcGRpc2st c3RyZWFtLmM6IEluIGZ1bmN0aW9uIOKAmHRhcGRpc2tfc3RyZWFtX3ByaW50X3JlcXVlc3TigJk6 Cj4gdGFwZGlzay1zdHJlYW0uYzoyMDY6IGVycm9yOiBpZ25vcmluZyByZXR1cm4gdmFsdWUgb2Yg 4oCYd3JpdGXigJksCj4gZGVjbGFyZWQgd2l0aCBhdHRyaWJ1dGUgd2Fybl91bnVzZWRfcmVzdWx0 Cj4gCj4gCj4gCj4gQmVzdCBSZWdhcmRzLAo+IEJlaSBHdWFuCj4gCgoKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Fri May 11 14:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqgP-0002BM-Ty; Fri, 11 May 2012 14:19:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqgO-0002B5-BE for xen-devel@lists.xen.org; Fri, 11 May 2012 14:19:00 +0000 Received: from [193.109.254.147:27257] by server-3.bemta-14.messagelabs.com id A9/4D-23274-3DF1DAF4; Fri, 11 May 2012 14:18:59 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336745939!3136479!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 856 invoked from network); 11 May 2012 14:18:59 -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; 11 May 2012 14:18:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 15:18:58 +0100 Message-Id: <4FAD3C0802000078000830D8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 15:19:20 +0100 From: "Jan Beulich" To: "xen-devel" , References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> In-Reply-To: <4FACD9940200007800082F0D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Olaf Hering , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: > Legacy (non-pvops) gntdev drivers may require this to be done when the > number of grants intended to be used simultaneously exceeds a certain > driver specific default limit. > > Signed-off-by: Jan Beulich > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > if (xen_mode != XEN_EMULATE) { > batch_maps = 1; > } > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) In more extensive testing it appears that very rarely this value is still too low: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) 342 + 11 = 353 > 352 = 32 * 11 Could someone help out here? I first thought this might be due to use_aio being non-zero, but ioreq_start() doesn't permit more than max_requests struct ioreqs-s to be around. Additionally, shouldn't the driver be smarter and gracefully handle grant mapping failures (as the per-domain map track table in the hypervisor is a finite resource)? Jan > + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", > + strerror(errno)); > } > > static int blk_init(struct XenDevice *xendev) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqgP-0002BM-Ty; Fri, 11 May 2012 14:19:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqgO-0002B5-BE for xen-devel@lists.xen.org; Fri, 11 May 2012 14:19:00 +0000 Received: from [193.109.254.147:27257] by server-3.bemta-14.messagelabs.com id A9/4D-23274-3DF1DAF4; Fri, 11 May 2012 14:18:59 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1336745939!3136479!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 856 invoked from network); 11 May 2012 14:18:59 -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; 11 May 2012 14:18:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 15:18:58 +0100 Message-Id: <4FAD3C0802000078000830D8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 15:19:20 +0100 From: "Jan Beulich" To: "xen-devel" , References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> In-Reply-To: <4FACD9940200007800082F0D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Olaf Hering , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: > Legacy (non-pvops) gntdev drivers may require this to be done when the > number of grants intended to be used simultaneously exceeds a certain > driver specific default limit. > > Signed-off-by: Jan Beulich > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > if (xen_mode != XEN_EMULATE) { > batch_maps = 1; > } > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) In more extensive testing it appears that very rarely this value is still too low: xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) 342 + 11 = 353 > 352 = 32 * 11 Could someone help out here? I first thought this might be due to use_aio being non-zero, but ioreq_start() doesn't permit more than max_requests struct ioreqs-s to be around. Additionally, shouldn't the driver be smarter and gracefully handle grant mapping failures (as the per-domain map track table in the hypervisor is a finite resource)? Jan > + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", > + strerror(errno)); > } > > static int blk_init(struct XenDevice *xendev) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:20:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:20:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqhL-0002KX-CG; Fri, 11 May 2012 14:19:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqhK-0002KG-AR for xen-devel@lists.xen.org; Fri, 11 May 2012 14:19:58 +0000 Received: from [85.158.139.83:51189] by server-12.bemta-5.messagelabs.com id EE/37-01344-D002DAF4; Fri, 11 May 2012 14:19:57 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-182.messagelabs.com!1336745996!27815859!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODEzMzA=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODEzMzA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12439 invoked from network); 11 May 2012 14:19:56 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:19:56 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jorabe mo37) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4022bbo4BBOA95 for ; Fri, 11 May 2012 16:19:56 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 3D8CB18637; Fri, 11 May 2012 16:19:55 +0200 (CEST) Date: Fri, 11 May 2012 16:19:55 +0200 From: Olaf Hering To: xen-devel Message-ID: <20120511141955.GA7991@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, Bei Guan wrote: > Hi, > > When I do the "make install-tools" with xen-4.2-unstable, there are some errors > about "warn_unused_result". > Is it the error in code or the error in the compiling environment? Thank you so > much. I suggest to remove all -Werror from the Makefiles and introduce a --disable-Werror/--enable-Werror configure option, similar to what binutils and other projects have (not sure what the exact configure option name is in those projects). Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:20:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:20:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqhL-0002KX-CG; Fri, 11 May 2012 14:19:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqhK-0002KG-AR for xen-devel@lists.xen.org; Fri, 11 May 2012 14:19:58 +0000 Received: from [85.158.139.83:51189] by server-12.bemta-5.messagelabs.com id EE/37-01344-D002DAF4; Fri, 11 May 2012 14:19:57 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-182.messagelabs.com!1336745996!27815859!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODEzMzA=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyODEzMzA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12439 invoked from network); 11 May 2012 14:19:56 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:19:56 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jorabe mo37) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4022bbo4BBOA95 for ; Fri, 11 May 2012 16:19:56 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 3D8CB18637; Fri, 11 May 2012 16:19:55 +0200 (CEST) Date: Fri, 11 May 2012 16:19:55 +0200 From: Olaf Hering To: xen-devel Message-ID: <20120511141955.GA7991@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, Bei Guan wrote: > Hi, > > When I do the "make install-tools" with xen-4.2-unstable, there are some errors > about "warn_unused_result". > Is it the error in code or the error in the compiling environment? Thank you so > much. I suggest to remove all -Werror from the Makefiles and introduce a --disable-Werror/--enable-Werror configure option, similar to what binutils and other projects have (not sure what the exact configure option name is in those projects). Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:24:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqli-0002fd-O9; Fri, 11 May 2012 14:24:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqlg-0002fN-2a for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:24:29 +0000 Received: from [85.158.143.99:38872] by server-3.bemta-4.messagelabs.com id 6F/20-05853-B112DAF4; Fri, 11 May 2012 14:24:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336746265!26670803!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25147 invoked from network); 11 May 2012 14:24:26 -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; 11 May 2012 14:24:26 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEOMJ6012053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:24:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BEOLAj013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:24:21 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BEOKMN005229; Fri, 11 May 2012 09:24:20 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:24:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5C94340359; Fri, 11 May 2012 10:18:17 -0400 (EDT) Date: Fri, 11 May 2012 10:18:17 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511141817.GB13735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > +static void pcpu_sys_remove(struct pcpu *pcpu) > +{ > + struct device *dev; > + > + if (!pcpu) > + return; > + > + dev = &pcpu->dev; > + if (dev->id) > + device_remove_file(dev, &dev_attr_online); > + > + device_unregister(dev); > +} > + > +static void free_pcpu(struct pcpu *pcpu) 1) So this isn't just freeing the PCPU, it also unregisters the SysFS. As such you should call this differently: unregister_and_free(struct pcpu *pcpu) or do the unregistration part seperatly. 2) But there is also another issue - a possiblity of race. The user might be running: while (true) do echo 1 > online echo 0 > online done and the the sync_pcpu will end up calling pcpu_sys_remove and free the pcpu. The SysFS aren't deleted until all of the object references (kref's) have been put. So when you get to 'kfree(pcpu)' you might be still holding a reference (meaning the user is doing 'echo 0 > online') and crash. I think you need to hold the mutex in the store_online() function (not good), or better yet, make a device_release function that will be called when the last kref has been put. 3) Third the name. These functions all depend on the mutex lock being held. As such add a postfix to the name of the function of "_locked" or a prefix of "__' so it is known that the caller holds the mutex. > +{ > + if (!pcpu) > + return; > + > + pcpu_sys_remove(pcpu); > + > + list_del(&pcpu->list); > + kfree(pcpu); > +} > + > +static int pcpu_sys_create(struct pcpu *pcpu) > +{ > + struct device *dev; > + int err = -EINVAL; > + > + if (!pcpu) > + return err; > + > + dev = &pcpu->dev; > + dev->bus = &xen_pcpu_subsys; > + dev->id = pcpu->cpu_id; > + > + err = device_register(dev); > + if (err) > + return err; > + > + /* > + * Xen never offline cpu0 due to several restrictions > + * and assumptions. This basically doesn't add a sys control > + * to user, one cannot attempt to offline BSP. > + */ > + if (dev->id) { > + err = device_create_file(dev, &dev_attr_online); > + if (err) { > + device_unregister(dev); > + return err; > + } > + } > + > + return 0; > +} > + > +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) > +{ > + struct pcpu *pcpu; > + int err; > + > + if (info->flags & XEN_PCPU_FLAGS_INVALID) > + return ERR_PTR(-ENODEV); > + > + pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL); > + if (!pcpu) > + return ERR_PTR(-ENOMEM); > + > + INIT_LIST_HEAD(&pcpu->list); > + pcpu->cpu_id = info->xen_cpuid; > + pcpu->flags = info->flags; > + > + err = pcpu_sys_create(pcpu); > + if (err) { > + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", > + info->xen_cpuid); > + kfree(pcpu); > + return ERR_PTR(-ENOENT); > + } > + > + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ > + list_add_tail(&pcpu->list, &xen_pcpus); > + return pcpu; > +} > + > +/* > + * Caller should hold the xen_pcpu_lock > + */ > +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) > +{ > + int ret; > + struct pcpu *pcpu = NULL; > + struct xenpf_pcpuinfo *info; > + struct xen_platform_op op = { > + .cmd = XENPF_get_cpuinfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid = cpu, > + }; > + > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + return ret; > + > + info = &op.u.pcpu_info; > + if (max_cpu) > + *max_cpu = info->max_present; > + > + pcpu = get_pcpu(cpu); > + > + if (info->flags & XEN_PCPU_FLAGS_INVALID) { > + /* The pcpu has been removed */ > + if (pcpu) > + free_pcpu(pcpu); > + return 0; > + } > + > + if (!pcpu) { > + pcpu = init_pcpu(info); > + if (IS_ERR_OR_NULL(pcpu)) > + return -ENODEV; > + } else > + pcpu_online_status(info, pcpu); > + > + return 0; > +} > + > +/* > + * Sync dom0's pcpu information with xen hypervisor's > + */ > +static int xen_sync_pcpus(void) > +{ > + /* > + * Boot cpu always have cpu_id 0 in xen > + */ > + uint32_t cpu = 0, max_cpu = 0; > + int err = 0; > + struct list_head *cur, *tmp; > + struct pcpu *pcpu; > + > + mutex_lock(&xen_pcpu_lock); > + > + while (!err && (cpu <= max_cpu)) { > + err = sync_pcpu(cpu, &max_cpu); > + cpu++; > + } > + > + if (err) { > + list_for_each_safe(cur, tmp, &xen_pcpus) { > + pcpu = list_entry(cur, struct pcpu, list); > + free_pcpu(pcpu); > + } > + } > + > + mutex_unlock(&xen_pcpu_lock); > + > + return err; > +} > + > +static void xen_pcpu_work_fn(struct work_struct *work) > +{ > + xen_sync_pcpus(); > +} > +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); > + > +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) > +{ > + schedule_work(&xen_pcpu_work); > + return IRQ_HANDLED; > +} > + > +static int __init xen_pcpu_init(void) > +{ > + int irq, ret; > + > + if (!xen_initial_domain()) > + return -ENODEV; > + > + irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, > + xen_pcpu_interrupt, 0, > + "xen-pcpu", NULL); > + if (irq < 0) { > + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > + return irq; > + } > + > + ret = subsys_system_register(&xen_pcpu_subsys, NULL); > + if (ret) { > + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); > + goto err1; > + } > + > + ret = xen_sync_pcpus(); > + if (ret) { > + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); > + goto err2; > + } > + > + return 0; > + > +err2: > + bus_unregister(&xen_pcpu_subsys); > +err1: > + unbind_from_irqhandler(irq, NULL); > + return ret; > +} > +arch_initcall(xen_pcpu_init); > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 486653f..61fa661 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo { > }; > DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); > > +#define XENPF_cpu_online 56 > +#define XENPF_cpu_offline 57 > +struct xenpf_cpu_ol { > + uint32_t cpuid; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); > + > struct xen_platform_op { > uint32_t cmd; > uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ > @@ -330,6 +337,7 @@ struct xen_platform_op { > struct xenpf_getidletime getidletime; > struct xenpf_set_processor_pminfo set_pminfo; > struct xenpf_pcpuinfo pcpu_info; > + struct xenpf_cpu_ol cpu_ol; > uint8_t pad[128]; > } u; > }; > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > index a890804..0801468 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -80,6 +80,7 @@ > #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency console. */ > #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event for some domain. */ > #define VIRQ_DEBUGGER 6 /* (DOM0) A domain has paused for debugging. */ > +#define VIRQ_PCPU_STATE 9 /* (DOM0) PCPU state changed */ > > /* Architecture-specific VIRQ definitions. */ > #define VIRQ_ARCH_0 16 > -- > 1.7.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:24:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqli-0002fd-O9; Fri, 11 May 2012 14:24:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqlg-0002fN-2a for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:24:29 +0000 Received: from [85.158.143.99:38872] by server-3.bemta-4.messagelabs.com id 6F/20-05853-B112DAF4; Fri, 11 May 2012 14:24:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336746265!26670803!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25147 invoked from network); 11 May 2012 14:24:26 -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; 11 May 2012 14:24:26 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEOMJ6012053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:24:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BEOLAj013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:24:21 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BEOKMN005229; Fri, 11 May 2012 09:24:20 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:24:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5C94340359; Fri, 11 May 2012 10:18:17 -0400 (EDT) Date: Fri, 11 May 2012 10:18:17 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511141817.GB13735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > +static void pcpu_sys_remove(struct pcpu *pcpu) > +{ > + struct device *dev; > + > + if (!pcpu) > + return; > + > + dev = &pcpu->dev; > + if (dev->id) > + device_remove_file(dev, &dev_attr_online); > + > + device_unregister(dev); > +} > + > +static void free_pcpu(struct pcpu *pcpu) 1) So this isn't just freeing the PCPU, it also unregisters the SysFS. As such you should call this differently: unregister_and_free(struct pcpu *pcpu) or do the unregistration part seperatly. 2) But there is also another issue - a possiblity of race. The user might be running: while (true) do echo 1 > online echo 0 > online done and the the sync_pcpu will end up calling pcpu_sys_remove and free the pcpu. The SysFS aren't deleted until all of the object references (kref's) have been put. So when you get to 'kfree(pcpu)' you might be still holding a reference (meaning the user is doing 'echo 0 > online') and crash. I think you need to hold the mutex in the store_online() function (not good), or better yet, make a device_release function that will be called when the last kref has been put. 3) Third the name. These functions all depend on the mutex lock being held. As such add a postfix to the name of the function of "_locked" or a prefix of "__' so it is known that the caller holds the mutex. > +{ > + if (!pcpu) > + return; > + > + pcpu_sys_remove(pcpu); > + > + list_del(&pcpu->list); > + kfree(pcpu); > +} > + > +static int pcpu_sys_create(struct pcpu *pcpu) > +{ > + struct device *dev; > + int err = -EINVAL; > + > + if (!pcpu) > + return err; > + > + dev = &pcpu->dev; > + dev->bus = &xen_pcpu_subsys; > + dev->id = pcpu->cpu_id; > + > + err = device_register(dev); > + if (err) > + return err; > + > + /* > + * Xen never offline cpu0 due to several restrictions > + * and assumptions. This basically doesn't add a sys control > + * to user, one cannot attempt to offline BSP. > + */ > + if (dev->id) { > + err = device_create_file(dev, &dev_attr_online); > + if (err) { > + device_unregister(dev); > + return err; > + } > + } > + > + return 0; > +} > + > +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) > +{ > + struct pcpu *pcpu; > + int err; > + > + if (info->flags & XEN_PCPU_FLAGS_INVALID) > + return ERR_PTR(-ENODEV); > + > + pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL); > + if (!pcpu) > + return ERR_PTR(-ENOMEM); > + > + INIT_LIST_HEAD(&pcpu->list); > + pcpu->cpu_id = info->xen_cpuid; > + pcpu->flags = info->flags; > + > + err = pcpu_sys_create(pcpu); > + if (err) { > + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", > + info->xen_cpuid); > + kfree(pcpu); > + return ERR_PTR(-ENOENT); > + } > + > + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ > + list_add_tail(&pcpu->list, &xen_pcpus); > + return pcpu; > +} > + > +/* > + * Caller should hold the xen_pcpu_lock > + */ > +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) > +{ > + int ret; > + struct pcpu *pcpu = NULL; > + struct xenpf_pcpuinfo *info; > + struct xen_platform_op op = { > + .cmd = XENPF_get_cpuinfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + .u.pcpu_info.xen_cpuid = cpu, > + }; > + > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + return ret; > + > + info = &op.u.pcpu_info; > + if (max_cpu) > + *max_cpu = info->max_present; > + > + pcpu = get_pcpu(cpu); > + > + if (info->flags & XEN_PCPU_FLAGS_INVALID) { > + /* The pcpu has been removed */ > + if (pcpu) > + free_pcpu(pcpu); > + return 0; > + } > + > + if (!pcpu) { > + pcpu = init_pcpu(info); > + if (IS_ERR_OR_NULL(pcpu)) > + return -ENODEV; > + } else > + pcpu_online_status(info, pcpu); > + > + return 0; > +} > + > +/* > + * Sync dom0's pcpu information with xen hypervisor's > + */ > +static int xen_sync_pcpus(void) > +{ > + /* > + * Boot cpu always have cpu_id 0 in xen > + */ > + uint32_t cpu = 0, max_cpu = 0; > + int err = 0; > + struct list_head *cur, *tmp; > + struct pcpu *pcpu; > + > + mutex_lock(&xen_pcpu_lock); > + > + while (!err && (cpu <= max_cpu)) { > + err = sync_pcpu(cpu, &max_cpu); > + cpu++; > + } > + > + if (err) { > + list_for_each_safe(cur, tmp, &xen_pcpus) { > + pcpu = list_entry(cur, struct pcpu, list); > + free_pcpu(pcpu); > + } > + } > + > + mutex_unlock(&xen_pcpu_lock); > + > + return err; > +} > + > +static void xen_pcpu_work_fn(struct work_struct *work) > +{ > + xen_sync_pcpus(); > +} > +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); > + > +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) > +{ > + schedule_work(&xen_pcpu_work); > + return IRQ_HANDLED; > +} > + > +static int __init xen_pcpu_init(void) > +{ > + int irq, ret; > + > + if (!xen_initial_domain()) > + return -ENODEV; > + > + irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, > + xen_pcpu_interrupt, 0, > + "xen-pcpu", NULL); > + if (irq < 0) { > + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); > + return irq; > + } > + > + ret = subsys_system_register(&xen_pcpu_subsys, NULL); > + if (ret) { > + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); > + goto err1; > + } > + > + ret = xen_sync_pcpus(); > + if (ret) { > + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); > + goto err2; > + } > + > + return 0; > + > +err2: > + bus_unregister(&xen_pcpu_subsys); > +err1: > + unbind_from_irqhandler(irq, NULL); > + return ret; > +} > +arch_initcall(xen_pcpu_init); > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 486653f..61fa661 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -314,6 +314,13 @@ struct xenpf_pcpuinfo { > }; > DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); > > +#define XENPF_cpu_online 56 > +#define XENPF_cpu_offline 57 > +struct xenpf_cpu_ol { > + uint32_t cpuid; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); > + > struct xen_platform_op { > uint32_t cmd; > uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ > @@ -330,6 +337,7 @@ struct xen_platform_op { > struct xenpf_getidletime getidletime; > struct xenpf_set_processor_pminfo set_pminfo; > struct xenpf_pcpuinfo pcpu_info; > + struct xenpf_cpu_ol cpu_ol; > uint8_t pad[128]; > } u; > }; > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > index a890804..0801468 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -80,6 +80,7 @@ > #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency console. */ > #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event for some domain. */ > #define VIRQ_DEBUGGER 6 /* (DOM0) A domain has paused for debugging. */ > +#define VIRQ_PCPU_STATE 9 /* (DOM0) PCPU state changed */ > > /* Architecture-specific VIRQ definitions. */ > #define VIRQ_ARCH_0 16 > -- > 1.7.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:29:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqqo-0002xm-Hj; Fri, 11 May 2012 14:29:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqqn-0002xh-IC for xen-devel@lists.xen.org; Fri, 11 May 2012 14:29:45 +0000 Received: from [85.158.143.35:37974] by server-3.bemta-4.messagelabs.com id A4/D7-05853-8522DAF4; Fri, 11 May 2012 14:29:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336746584!15634355!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16297 invoked from network); 11 May 2012 14:29:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:29:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 15:29:44 +0100 Message-Id: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 15:30:05 +0100 From: "Jan Beulich" To: "Dominic Curran" References: <4FAD2022.6050009@citrix.com> In-Reply-To: <4FAD2022.6050009@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: konrad.wilk@oracle.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 16:20, Dominic Curran wrote: > From: Dominic Curran > Date: Fri, 11 May 2012 12:24:42 +0100 > Subject: [PATCH] xen: Fix a grant table resource leak > > If the resource (my testing shows an object in TX/RX ring) still has a > reference held on it, then add to a list and kick-off a timer to try > and free later. Did you see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html Jan > Signed-off-by: Dominic Curran > --- > drivers/xen/grant-table.c | 72 > +++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 4 deletions(-) > > Index: linux-2.6/drivers/xen/grant-table.c > =================================================================== > --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 > 13:52:54.000000000 +0100 > +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 > +0100 > @@ -33,6 +33,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -57,6 +58,7 @@ > (grant_table_version == 1 ? \ > (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ > (PAGE_SIZE / sizeof(union grant_entry_v2))) > +#define GNTTAB_CLEANUP_TIMER 10 > > static grant_ref_t **gnttab_list; > static unsigned int nr_grant_frames; > @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; > static DEFINE_SPINLOCK(gnttab_list_lock); > unsigned long xen_hvm_resume_frames; > EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); > +static LIST_HEAD(gnttab_used_ref_list); > +static DEFINE_SPINLOCK(gnttab_used_ref_lock); > +static struct timer_list gnttab_timer; > > static union { > struct grant_entry_v1 *v1; > @@ -145,6 +150,16 @@ struct gnttab_ops { > domid_t trans_domid, grant_ref_t trans_gref); > }; > > +/* This structure is used to hold references to pages until they become > + ready to free. > +*/ > +struct gnttab_used_ref { > + struct list_head list; > + grant_ref_t ref; > + unsigned long page; > + int readonly; > +}; > + > static struct gnttab_ops *gnttab_interface; > > /*This reflects status of grant entries, so act as a global value*/ > @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ > } > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); > > +static void gnttab_attempt_clean_used_refs(unsigned long arg) > +{ > + struct gnttab_used_ref *u; > + struct list_head *pos, *q; > + unsigned long flags; > + > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > + > + list_for_each_safe(pos, q, &gnttab_used_ref_list) { > + u = list_entry(pos, struct gnttab_used_ref, list); > + > + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { > + list_del(pos); > + > + put_free_entry(u->ref); > + if (u->page != 0) > + free_page(u->page); > + > + kfree(u); > + } > + } > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > + > + if (!list_empty(&gnttab_used_ref_list)) > + mod_timer(&gnttab_timer, jiffies + HZ); > +} > + > void gnttab_end_foreign_access(grant_ref_t ref, int readonly, > unsigned long page) > { > + struct gnttab_used_ref *u; > + unsigned long flags; > + > if (gnttab_end_foreign_access_ref(ref, readonly)) { > put_free_entry(ref); > if (page != 0) > free_page(page); > } else { > - /* XXX This needs to be fixed so that the ref and page are > - placed on a list to be freed up later. */ > - printk(KERN_WARNING > - "WARNING: leaking g.e. and page still in use!\n"); > + /* References that aren't cleaned up immediately sit on > + * a list until they are abandoned & can be cleaned safely. > + */ > + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); > + if (!u) > + return; > + > + u->page = page; > + u->ref = ref; > + u->readonly = readonly; > + > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > + list_add(&(u->list), &gnttab_used_ref_list); > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > + > + /* Kick off the cleanup timer. */ > + if (!timer_pending(&gnttab_timer)) > + add_timer(&gnttab_timer); > } > } > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); > @@ -1068,6 +1127,11 @@ int gnttab_init(void) > gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; > gnttab_free_head = NR_RESERVED_ENTRIES; > > + init_timer(&gnttab_timer); > + gnttab_timer.data = 0; > + gnttab_timer.function = gnttab_attempt_clean_used_refs; > + gnttab_timer.expires = jiffies + > msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); > + > printk("Grant table initialized\n"); > return 0; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:29:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqqo-0002xm-Hj; Fri, 11 May 2012 14:29:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqqn-0002xh-IC for xen-devel@lists.xen.org; Fri, 11 May 2012 14:29:45 +0000 Received: from [85.158.143.35:37974] by server-3.bemta-4.messagelabs.com id A4/D7-05853-8522DAF4; Fri, 11 May 2012 14:29:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336746584!15634355!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM1MjM=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16297 invoked from network); 11 May 2012 14:29:44 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:29:44 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 11 May 2012 15:29:44 +0100 Message-Id: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 11 May 2012 15:30:05 +0100 From: "Jan Beulich" To: "Dominic Curran" References: <4FAD2022.6050009@citrix.com> In-Reply-To: <4FAD2022.6050009@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: konrad.wilk@oracle.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 16:20, Dominic Curran wrote: > From: Dominic Curran > Date: Fri, 11 May 2012 12:24:42 +0100 > Subject: [PATCH] xen: Fix a grant table resource leak > > If the resource (my testing shows an object in TX/RX ring) still has a > reference held on it, then add to a list and kick-off a timer to try > and free later. Did you see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html Jan > Signed-off-by: Dominic Curran > --- > drivers/xen/grant-table.c | 72 > +++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 4 deletions(-) > > Index: linux-2.6/drivers/xen/grant-table.c > =================================================================== > --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 > 13:52:54.000000000 +0100 > +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 > +0100 > @@ -33,6 +33,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -57,6 +58,7 @@ > (grant_table_version == 1 ? \ > (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ > (PAGE_SIZE / sizeof(union grant_entry_v2))) > +#define GNTTAB_CLEANUP_TIMER 10 > > static grant_ref_t **gnttab_list; > static unsigned int nr_grant_frames; > @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; > static DEFINE_SPINLOCK(gnttab_list_lock); > unsigned long xen_hvm_resume_frames; > EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); > +static LIST_HEAD(gnttab_used_ref_list); > +static DEFINE_SPINLOCK(gnttab_used_ref_lock); > +static struct timer_list gnttab_timer; > > static union { > struct grant_entry_v1 *v1; > @@ -145,6 +150,16 @@ struct gnttab_ops { > domid_t trans_domid, grant_ref_t trans_gref); > }; > > +/* This structure is used to hold references to pages until they become > + ready to free. > +*/ > +struct gnttab_used_ref { > + struct list_head list; > + grant_ref_t ref; > + unsigned long page; > + int readonly; > +}; > + > static struct gnttab_ops *gnttab_interface; > > /*This reflects status of grant entries, so act as a global value*/ > @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ > } > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); > > +static void gnttab_attempt_clean_used_refs(unsigned long arg) > +{ > + struct gnttab_used_ref *u; > + struct list_head *pos, *q; > + unsigned long flags; > + > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > + > + list_for_each_safe(pos, q, &gnttab_used_ref_list) { > + u = list_entry(pos, struct gnttab_used_ref, list); > + > + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { > + list_del(pos); > + > + put_free_entry(u->ref); > + if (u->page != 0) > + free_page(u->page); > + > + kfree(u); > + } > + } > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > + > + if (!list_empty(&gnttab_used_ref_list)) > + mod_timer(&gnttab_timer, jiffies + HZ); > +} > + > void gnttab_end_foreign_access(grant_ref_t ref, int readonly, > unsigned long page) > { > + struct gnttab_used_ref *u; > + unsigned long flags; > + > if (gnttab_end_foreign_access_ref(ref, readonly)) { > put_free_entry(ref); > if (page != 0) > free_page(page); > } else { > - /* XXX This needs to be fixed so that the ref and page are > - placed on a list to be freed up later. */ > - printk(KERN_WARNING > - "WARNING: leaking g.e. and page still in use!\n"); > + /* References that aren't cleaned up immediately sit on > + * a list until they are abandoned & can be cleaned safely. > + */ > + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); > + if (!u) > + return; > + > + u->page = page; > + u->ref = ref; > + u->readonly = readonly; > + > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > + list_add(&(u->list), &gnttab_used_ref_list); > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > + > + /* Kick off the cleanup timer. */ > + if (!timer_pending(&gnttab_timer)) > + add_timer(&gnttab_timer); > } > } > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); > @@ -1068,6 +1127,11 @@ int gnttab_init(void) > gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; > gnttab_free_head = NR_RESERVED_ENTRIES; > > + init_timer(&gnttab_timer); > + gnttab_timer.data = 0; > + gnttab_timer.function = gnttab_attempt_clean_used_refs; > + gnttab_timer.expires = jiffies + > msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); > + > printk("Grant table initialized\n"); > return 0; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqv7-00038q-7J; Fri, 11 May 2012 14:34:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqv5-00038d-IT for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:34:11 +0000 Received: from [85.158.138.51:12269] by server-3.bemta-3.messagelabs.com id 9F/50-04048-2632DAF4; Fri, 11 May 2012 14:34:10 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336746847!26612764!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27806 invoked from network); 11 May 2012 14:34:08 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:34:08 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEY3Y8022891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:34:04 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 q4BEY2mL002978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:34:03 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 q4BEY2C4001433; Fri, 11 May 2012 09:34:02 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:34:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1702A40359; Fri, 11 May 2012 10:27:59 -0400 (EDT) Date: Fri, 11 May 2012 10:27:58 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511142758.GA29677@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > Liu, Jinsong wrote: > > Just notice your reply (so quick :) > > > > Agree and will update later, except 1 concern below. > > > > Konrad Rzeszutek Wilk wrote: > >>> > >>> Hmm, it's good if it's convenient to do it automatically via > >>> dev->release. However, dev container (pcpu) would be free at some > >>> other error cases, so I prefer do it 'manually'. > >> > >> You could also call pcpu_release(..) to do it manually. > >> > > > > that means kfree(pcpu) would be done twice at some error cases, do > > you think it really good? > > > > Ping. > > I think error recovery should be kept inside error logic level itself, if try to recover upper level error would bring trouble. > > In our example, there are 2 logic levels: > pcpu level (as container), and dev level (subfield used for sys) So you need to untangle free_pcpu from doing both. Meaning one does the SysFS and the other deals with free-ing the structure and removing itself from the list. > dev->release should only recover error occurred at dev/sys level, and the pcpu error should be recovered at pcpu level. > > If dev->release try to recover its container pcpu level error, like list_del/kfree(pcpu), it would make confusing. i.e., considering pcpu_sys_create(), 2 error cases: > device_register fail, and device_create_file fail --> how can the caller decide kfree(pcpu) or not? Then you should free it manually. But you can do this by a wrapper function: __pcpu_release(..) { .. /* Does the removing itself from the list and kfree the pcpu */ } pcpu_release(..) { struct pcpcu *p= container_of(..) __pcpu_release(p); } dev->release = &pcpu_release; > > So how about recover pcpu error manually and explicitly? > > Thanks, > Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:34:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqv7-00038q-7J; Fri, 11 May 2012 14:34:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqv5-00038d-IT for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:34:11 +0000 Received: from [85.158.138.51:12269] by server-3.bemta-3.messagelabs.com id 9F/50-04048-2632DAF4; Fri, 11 May 2012 14:34:10 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336746847!26612764!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27806 invoked from network); 11 May 2012 14:34:08 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 14:34:08 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEY3Y8022891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:34:04 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 q4BEY2mL002978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:34:03 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 q4BEY2C4001433; Fri, 11 May 2012 09:34:02 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:34:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1702A40359; Fri, 11 May 2012 10:27:59 -0400 (EDT) Date: Fri, 11 May 2012 10:27:58 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511142758.GA29677@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > Liu, Jinsong wrote: > > Just notice your reply (so quick :) > > > > Agree and will update later, except 1 concern below. > > > > Konrad Rzeszutek Wilk wrote: > >>> > >>> Hmm, it's good if it's convenient to do it automatically via > >>> dev->release. However, dev container (pcpu) would be free at some > >>> other error cases, so I prefer do it 'manually'. > >> > >> You could also call pcpu_release(..) to do it manually. > >> > > > > that means kfree(pcpu) would be done twice at some error cases, do > > you think it really good? > > > > Ping. > > I think error recovery should be kept inside error logic level itself, if try to recover upper level error would bring trouble. > > In our example, there are 2 logic levels: > pcpu level (as container), and dev level (subfield used for sys) So you need to untangle free_pcpu from doing both. Meaning one does the SysFS and the other deals with free-ing the structure and removing itself from the list. > dev->release should only recover error occurred at dev/sys level, and the pcpu error should be recovered at pcpu level. > > If dev->release try to recover its container pcpu level error, like list_del/kfree(pcpu), it would make confusing. i.e., considering pcpu_sys_create(), 2 error cases: > device_register fail, and device_create_file fail --> how can the caller decide kfree(pcpu) or not? Then you should free it manually. But you can do this by a wrapper function: __pcpu_release(..) { .. /* Does the removing itself from the list and kfree the pcpu */ } pcpu_release(..) { struct pcpcu *p= container_of(..) __pcpu_release(p); } dev->release = &pcpu_release; > > So how about recover pcpu error manually and explicitly? > > Thanks, > Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:35:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqwQ-0003Dv-NU; Fri, 11 May 2012 14:35:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqwP-0003Dj-Hq for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:35:33 +0000 Received: from [193.109.254.147:37954] by server-11.bemta-14.messagelabs.com id 31/24-05858-4B32DAF4; Fri, 11 May 2012 14:35:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1336746931!8773642!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9815 invoked from network); 11 May 2012 14:35:32 -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; 11 May 2012 14:35:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jorabe mo41) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i02694o4BEWaNT for ; Fri, 11 May 2012 16:35:31 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0B16518630 for ; Fri, 11 May 2012 16:35:31 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 11 May 2012 16:35:29 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336743357 -7200 # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 unmodified_drivers: remove inclusion of asm/system.h Allow compilation of PVonHVM drivers with forward-ported xenlinux sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present anymore. Remove inclusion of this header, its not needed. Signed-off-by: Olaf Hering diff -r 0f53540494f7 -r f81fa4014d8c 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 @@ -30,7 +30,6 @@ #include #include #include -#include #include #include #include _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:35:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqwQ-0003Dv-NU; Fri, 11 May 2012 14:35:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqwP-0003Dj-Hq for xen-devel@lists.xensource.com; Fri, 11 May 2012 14:35:33 +0000 Received: from [193.109.254.147:37954] by server-11.bemta-14.messagelabs.com id 31/24-05858-4B32DAF4; Fri, 11 May 2012 14:35:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1336746931!8773642!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9815 invoked from network); 11 May 2012 14:35:32 -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; 11 May 2012 14:35:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jorabe mo41) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i02694o4BEWaNT for ; Fri, 11 May 2012 16:35:31 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 0B16518630 for ; Fri, 11 May 2012 16:35:31 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 11 May 2012 16:35:29 +0200 From: Olaf Hering To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1336743357 -7200 # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 unmodified_drivers: remove inclusion of asm/system.h Allow compilation of PVonHVM drivers with forward-ported xenlinux sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present anymore. Remove inclusion of this header, its not needed. Signed-off-by: Olaf Hering diff -r 0f53540494f7 -r f81fa4014d8c 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 @@ -30,7 +30,6 @@ #include #include #include -#include #include #include #include _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:37:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqxq-0003N3-B7; Fri, 11 May 2012 14:37:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqxo-0003Mp-Kb for xen-devel@lists.xen.org; Fri, 11 May 2012 14:37:00 +0000 Received: from [85.158.138.51:47304] by server-10.bemta-3.messagelabs.com id 82/8A-29478-B042DAF4; Fri, 11 May 2012 14:36:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336747016!18668022!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26005 invoked from network); 11 May 2012 14:36:58 -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; 11 May 2012 14:36:58 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEarxI004185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:36:54 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 q4BEaqCn017499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:36:53 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BEaqtm015455; Fri, 11 May 2012 09:36:52 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:36:52 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4A79440359; Fri, 11 May 2012 10:30:49 -0400 (EDT) Date: Fri, 11 May 2012 10:30:49 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120511143049.GB29677@phenom.dumpdata.com> References: <4FAD2022.6050009@citrix.com> <4FAD3E8D0200007800083110@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 03:30:05PM +0100, Jan Beulich wrote: > >>> On 11.05.12 at 16:20, Dominic Curran wrote: > > From: Dominic Curran > > Date: Fri, 11 May 2012 12:24:42 +0100 > > Subject: [PATCH] xen: Fix a grant table resource leak > > > > If the resource (my testing shows an object in TX/RX ring) still has a > > reference held on it, then add to a list and kick-off a timer to try > > and free later. > > Did you see > > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html Which is on the 3.5 queue list: http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=569ca5b3f94cd0b3295ec5943aa457cf4a4f6a3a > > Jan > > > Signed-off-by: Dominic Curran > > --- > > drivers/xen/grant-table.c | 72 > > +++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 68 insertions(+), 4 deletions(-) > > > > Index: linux-2.6/drivers/xen/grant-table.c > > =================================================================== > > --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 > > 13:52:54.000000000 +0100 > > +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 > > +0100 > > @@ -33,6 +33,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -57,6 +58,7 @@ > > (grant_table_version == 1 ? \ > > (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ > > (PAGE_SIZE / sizeof(union grant_entry_v2))) > > +#define GNTTAB_CLEANUP_TIMER 10 > > > > static grant_ref_t **gnttab_list; > > static unsigned int nr_grant_frames; > > @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; > > static DEFINE_SPINLOCK(gnttab_list_lock); > > unsigned long xen_hvm_resume_frames; > > EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); > > +static LIST_HEAD(gnttab_used_ref_list); > > +static DEFINE_SPINLOCK(gnttab_used_ref_lock); > > +static struct timer_list gnttab_timer; > > > > static union { > > struct grant_entry_v1 *v1; > > @@ -145,6 +150,16 @@ struct gnttab_ops { > > domid_t trans_domid, grant_ref_t trans_gref); > > }; > > > > +/* This structure is used to hold references to pages until they become > > + ready to free. > > +*/ > > +struct gnttab_used_ref { > > + struct list_head list; > > + grant_ref_t ref; > > + unsigned long page; > > + int readonly; > > +}; > > + > > static struct gnttab_ops *gnttab_interface; > > > > /*This reflects status of grant entries, so act as a global value*/ > > @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ > > } > > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); > > > > +static void gnttab_attempt_clean_used_refs(unsigned long arg) > > +{ > > + struct gnttab_used_ref *u; > > + struct list_head *pos, *q; > > + unsigned long flags; > > + > > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > > + > > + list_for_each_safe(pos, q, &gnttab_used_ref_list) { > > + u = list_entry(pos, struct gnttab_used_ref, list); > > + > > + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { > > + list_del(pos); > > + > > + put_free_entry(u->ref); > > + if (u->page != 0) > > + free_page(u->page); > > + > > + kfree(u); > > + } > > + } > > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > > + > > + if (!list_empty(&gnttab_used_ref_list)) > > + mod_timer(&gnttab_timer, jiffies + HZ); > > +} > > + > > void gnttab_end_foreign_access(grant_ref_t ref, int readonly, > > unsigned long page) > > { > > + struct gnttab_used_ref *u; > > + unsigned long flags; > > + > > if (gnttab_end_foreign_access_ref(ref, readonly)) { > > put_free_entry(ref); > > if (page != 0) > > free_page(page); > > } else { > > - /* XXX This needs to be fixed so that the ref and page are > > - placed on a list to be freed up later. */ > > - printk(KERN_WARNING > > - "WARNING: leaking g.e. and page still in use!\n"); > > + /* References that aren't cleaned up immediately sit on > > + * a list until they are abandoned & can be cleaned safely. > > + */ > > + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); > > + if (!u) > > + return; > > + > > + u->page = page; > > + u->ref = ref; > > + u->readonly = readonly; > > + > > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > > + list_add(&(u->list), &gnttab_used_ref_list); > > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > > + > > + /* Kick off the cleanup timer. */ > > + if (!timer_pending(&gnttab_timer)) > > + add_timer(&gnttab_timer); > > } > > } > > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); > > @@ -1068,6 +1127,11 @@ int gnttab_init(void) > > gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; > > gnttab_free_head = NR_RESERVED_ENTRIES; > > > > + init_timer(&gnttab_timer); > > + gnttab_timer.data = 0; > > + gnttab_timer.function = gnttab_attempt_clean_used_refs; > > + gnttab_timer.expires = jiffies + > > msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); > > + > > printk("Grant table initialized\n"); > > return 0; > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:37:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSqxq-0003N3-B7; Fri, 11 May 2012 14:37:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSqxo-0003Mp-Kb for xen-devel@lists.xen.org; Fri, 11 May 2012 14:37:00 +0000 Received: from [85.158.138.51:47304] by server-10.bemta-3.messagelabs.com id 82/8A-29478-B042DAF4; Fri, 11 May 2012 14:36:59 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1336747016!18668022!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26005 invoked from network); 11 May 2012 14:36:58 -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; 11 May 2012 14:36:58 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEarxI004185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 14:36:54 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 q4BEaqCn017499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 14:36:53 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BEaqtm015455; Fri, 11 May 2012 09:36:52 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 07:36:52 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 4A79440359; Fri, 11 May 2012 10:30:49 -0400 (EDT) Date: Fri, 11 May 2012 10:30:49 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20120511143049.GB29677@phenom.dumpdata.com> References: <4FAD2022.6050009@citrix.com> <4FAD3E8D0200007800083110@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 03:30:05PM +0100, Jan Beulich wrote: > >>> On 11.05.12 at 16:20, Dominic Curran wrote: > > From: Dominic Curran > > Date: Fri, 11 May 2012 12:24:42 +0100 > > Subject: [PATCH] xen: Fix a grant table resource leak > > > > If the resource (my testing shows an object in TX/RX ring) still has a > > reference held on it, then add to a list and kick-off a timer to try > > and free later. > > Did you see > > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html Which is on the 3.5 queue list: http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=569ca5b3f94cd0b3295ec5943aa457cf4a4f6a3a > > Jan > > > Signed-off-by: Dominic Curran > > --- > > drivers/xen/grant-table.c | 72 > > +++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 68 insertions(+), 4 deletions(-) > > > > Index: linux-2.6/drivers/xen/grant-table.c > > =================================================================== > > --- linux-2.6.orig/drivers/xen/grant-table.c 2012-05-08 > > 13:52:54.000000000 +0100 > > +++ linux-2.6/drivers/xen/grant-table.c 2012-05-08 16:53:52.000000000 > > +0100 > > @@ -33,6 +33,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -57,6 +58,7 @@ > > (grant_table_version == 1 ? \ > > (PAGE_SIZE / sizeof(struct grant_entry_v1)) : \ > > (PAGE_SIZE / sizeof(union grant_entry_v2))) > > +#define GNTTAB_CLEANUP_TIMER 10 > > > > static grant_ref_t **gnttab_list; > > static unsigned int nr_grant_frames; > > @@ -66,6 +68,9 @@ static grant_ref_t gnttab_free_head; > > static DEFINE_SPINLOCK(gnttab_list_lock); > > unsigned long xen_hvm_resume_frames; > > EXPORT_SYMBOL_GPL(xen_hvm_resume_frames); > > +static LIST_HEAD(gnttab_used_ref_list); > > +static DEFINE_SPINLOCK(gnttab_used_ref_lock); > > +static struct timer_list gnttab_timer; > > > > static union { > > struct grant_entry_v1 *v1; > > @@ -145,6 +150,16 @@ struct gnttab_ops { > > domid_t trans_domid, grant_ref_t trans_gref); > > }; > > > > +/* This structure is used to hold references to pages until they become > > + ready to free. > > +*/ > > +struct gnttab_used_ref { > > + struct list_head list; > > + grant_ref_t ref; > > + unsigned long page; > > + int readonly; > > +}; > > + > > static struct gnttab_ops *gnttab_interface; > > > > /*This reflects status of grant entries, so act as a global value*/ > > @@ -464,18 +479,62 @@ int gnttab_end_foreign_access_ref(grant_ > > } > > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); > > > > +static void gnttab_attempt_clean_used_refs(unsigned long arg) > > +{ > > + struct gnttab_used_ref *u; > > + struct list_head *pos, *q; > > + unsigned long flags; > > + > > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > > + > > + list_for_each_safe(pos, q, &gnttab_used_ref_list) { > > + u = list_entry(pos, struct gnttab_used_ref, list); > > + > > + if (gnttab_end_foreign_access_ref(u->ref, u->readonly)) { > > + list_del(pos); > > + > > + put_free_entry(u->ref); > > + if (u->page != 0) > > + free_page(u->page); > > + > > + kfree(u); > > + } > > + } > > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > > + > > + if (!list_empty(&gnttab_used_ref_list)) > > + mod_timer(&gnttab_timer, jiffies + HZ); > > +} > > + > > void gnttab_end_foreign_access(grant_ref_t ref, int readonly, > > unsigned long page) > > { > > + struct gnttab_used_ref *u; > > + unsigned long flags; > > + > > if (gnttab_end_foreign_access_ref(ref, readonly)) { > > put_free_entry(ref); > > if (page != 0) > > free_page(page); > > } else { > > - /* XXX This needs to be fixed so that the ref and page are > > - placed on a list to be freed up later. */ > > - printk(KERN_WARNING > > - "WARNING: leaking g.e. and page still in use!\n"); > > + /* References that aren't cleaned up immediately sit on > > + * a list until they are abandoned & can be cleaned safely. > > + */ > > + u = kmalloc(sizeof(struct gnttab_used_ref), GFP_KERNEL); > > + if (!u) > > + return; > > + > > + u->page = page; > > + u->ref = ref; > > + u->readonly = readonly; > > + > > + spin_lock_irqsave(&gnttab_used_ref_lock, flags); > > + list_add(&(u->list), &gnttab_used_ref_list); > > + spin_unlock_irqrestore(&gnttab_used_ref_lock, flags); > > + > > + /* Kick off the cleanup timer. */ > > + if (!timer_pending(&gnttab_timer)) > > + add_timer(&gnttab_timer); > > } > > } > > EXPORT_SYMBOL_GPL(gnttab_end_foreign_access); > > @@ -1068,6 +1127,11 @@ int gnttab_init(void) > > gnttab_free_count = nr_init_grefs - NR_RESERVED_ENTRIES; > > gnttab_free_head = NR_RESERVED_ENTRIES; > > > > + init_timer(&gnttab_timer); > > + gnttab_timer.data = 0; > > + gnttab_timer.function = gnttab_attempt_clean_used_refs; > > + gnttab_timer.expires = jiffies + > > msecs_to_jiffies(GNTTAB_CLEANUP_TIMER); > > + > > printk("Grant table initialized\n"); > > return 0; > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:49:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSr9s-0003zu-9K; Fri, 11 May 2012 14:49:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSr9q-0003zp-Kh for xen-devel@lists.xen.org; Fri, 11 May 2012 14:49:26 +0000 Received: from [85.158.143.35:39804] by server-3.bemta-4.messagelabs.com id 75/23-05853-5F62DAF4; Fri, 11 May 2012 14:49:25 +0000 X-Env-Sender: dominic.curran@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336747756!14121214!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15948 invoked from network); 11 May 2012 14:49:17 -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; 11 May 2012 14:49:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194451235" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:49:14 -0400 Received: from [10.80.2.144] (10.80.2.144) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:49:14 -0400 Message-ID: <4FAD2857.3070107@citrix.com> Date: Fri, 11 May 2012 15:55:19 +0100 From: Dominic Curran User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Jan Beulich References: <4FAD2022.6050009@citrix.com> <4FAD3E8D0200007800083110@nat28.tlf.novell.com> In-Reply-To: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/12 15:30, Jan Beulich wrote: >>>> On 11.05.12 at 16:20, Dominic Curran wrote: >> From: Dominic Curran >> Date: Fri, 11 May 2012 12:24:42 +0100 >> Subject: [PATCH] xen: Fix a grant table resource leak >> >> If the resource (my testing shows an object in TX/RX ring) still has a >> reference held on it, then add to a list and kick-off a timer to try >> and free later. > Did you see > > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html > > Jan Oh! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:49:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14: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 ) id 1SSr9s-0003zu-9K; Fri, 11 May 2012 14:49:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSr9q-0003zp-Kh for xen-devel@lists.xen.org; Fri, 11 May 2012 14:49:26 +0000 Received: from [85.158.143.35:39804] by server-3.bemta-4.messagelabs.com id 75/23-05853-5F62DAF4; Fri, 11 May 2012 14:49:25 +0000 X-Env-Sender: dominic.curran@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336747756!14121214!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTE3NzI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15948 invoked from network); 11 May 2012 14:49:17 -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; 11 May 2012 14:49:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330923600"; d="scan'208";a="194451235" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 10:49:14 -0400 Received: from [10.80.2.144] (10.80.2.144) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 10:49:14 -0400 Message-ID: <4FAD2857.3070107@citrix.com> Date: Fri, 11 May 2012 15:55:19 +0100 From: Dominic Curran User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Jan Beulich References: <4FAD2022.6050009@citrix.com> <4FAD3E8D0200007800083110@nat28.tlf.novell.com> In-Reply-To: <4FAD3E8D0200007800083110@nat28.tlf.novell.com> Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xen: Fix a grant table resource leak X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/12 15:30, Jan Beulich wrote: >>>> On 11.05.12 at 16:20, Dominic Curran wrote: >> From: Dominic Curran >> Date: Fri, 11 May 2012 12:24:42 +0100 >> Subject: [PATCH] xen: Fix a grant table resource leak >> >> If the resource (my testing shows an object in TX/RX ring) still has a >> reference held on it, then add to a list and kick-off a timer to try >> and free later. > Did you see > > http://lists.xen.org/archives/html/xen-devel/2012-04/msg00406.html > > Jan Oh! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEH-0004Ac-05; Fri, 11 May 2012 14:54:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEG-0004AV-7V for xen-devel@lists.xen.org; Fri, 11 May 2012 14:54:00 +0000 Received: from [85.158.138.51:47304] by server-3.bemta-3.messagelabs.com id BA/68-04048-7082DAF4; Fri, 11 May 2012 14:53:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336748038!7924109!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9792 invoked from network); 11 May 2012 14:53:58 -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; 11 May 2012 14:53:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432318" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14: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; Fri, 11 May 2012 15:53:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrDs-0007J3-4W; Fri, 11 May 2012 14:53:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrDs-0001Zd-3Y; Fri, 11 May 2012 15:53:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Fri, 11 May 2012 15:53:36 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335358736.28015.41.camel@zakaz.uk.xensource.com> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Teck Choon Giam , "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): > libxl/xend: name tap devices vifX.Y-emu Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEH-0004Ac-05; Fri, 11 May 2012 14:54:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEG-0004AV-7V for xen-devel@lists.xen.org; Fri, 11 May 2012 14:54:00 +0000 Received: from [85.158.138.51:47304] by server-3.bemta-3.messagelabs.com id BA/68-04048-7082DAF4; Fri, 11 May 2012 14:53:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336748038!7924109!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9792 invoked from network); 11 May 2012 14:53:58 -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; 11 May 2012 14:53:58 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432318" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14: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; Fri, 11 May 2012 15:53:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrDs-0007J3-4W; Fri, 11 May 2012 14:53:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrDs-0001Zd-3Y; Fri, 11 May 2012 15:53:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Fri, 11 May 2012 15:53:36 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335358736.28015.41.camel@zakaz.uk.xensource.com> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Teck Choon Giam , "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): > libxl/xend: name tap devices vifX.Y-emu Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEI-0004Au-Cq; Fri, 11 May 2012 14:54:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEH-0004Ab-DS for xen-devel@lists.xen.org; Fri, 11 May 2012 14:54:01 +0000 Received: from [85.158.138.51:57205] by server-8.bemta-3.messagelabs.com id A8/85-24428-8082DAF4; Fri, 11 May 2012 14:54:00 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336748038!7924109!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9985 invoked from network); 11 May 2012 14:54:00 -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; 11 May 2012 14:54:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432324" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14:53:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 15:53:58 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrED-0007JC-To; Fri, 11 May 2012 14:53:57 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrED-0001Zs-T8; Fri, 11 May 2012 15:53:57 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10245.887979.508626@mariner.uk.xensource.com> Date: Fri, 11 May 2012 15:53:57 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <1335350442.28015.29.camel@zakaz.uk.xensource.com> <1335351773.28015.33.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"): > On Wed, 25 Apr 2012, Ian Campbell wrote: > > libxl: default to xenconsoled for pv guests, even if qemu is running. ... > Acked-by: Stefano Stabellini Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 14:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 14:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEI-0004Au-Cq; Fri, 11 May 2012 14:54:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrEH-0004Ab-DS for xen-devel@lists.xen.org; Fri, 11 May 2012 14:54:01 +0000 Received: from [85.158.138.51:57205] by server-8.bemta-3.messagelabs.com id A8/85-24428-8082DAF4; Fri, 11 May 2012 14:54:00 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336748038!7924109!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9985 invoked from network); 11 May 2012 14:54:00 -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; 11 May 2012 14:54:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432324" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 14:53:58 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 15:53:58 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrED-0007JC-To; Fri, 11 May 2012 14:53:57 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrED-0001Zs-T8; Fri, 11 May 2012 15:53:57 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10245.887979.508626@mariner.uk.xensource.com> Date: Fri, 11 May 2012 15:53:57 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <1335350442.28015.29.camel@zakaz.uk.xensource.com> <1335351773.28015.33.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] libxl: default to xenconsoled for pv guests, even if qemu is running"): > On Wed, 25 Apr 2012, Ian Campbell wrote: > > libxl: default to xenconsoled for pv guests, even if qemu is running. ... > Acked-by: Stefano Stabellini Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:00:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSrKB-0004vo-G4; Fri, 11 May 2012 15:00:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrK9-0004tW-F0 for xen-devel@lists.xen.org; Fri, 11 May 2012 15:00:05 +0000 Received: from [85.158.143.99:47025] by server-2.bemta-4.messagelabs.com id F7/41-17550-5792DAF4; Fri, 11 May 2012 15:00:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336748403!22319754!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26897 invoked from network); 11 May 2012 15:00:04 -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; 11 May 2012 15:00:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432444" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:00: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, 11 May 2012 16:00:03 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrK6-0007L8-Se; Fri, 11 May 2012 15:00:02 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrK6-0001vM-Fs; Fri, 11 May 2012 16:00:02 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10609.18007.71477@mariner.uk.xensource.com> Date: Fri, 11 May 2012 16:00:01 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <20348.27879.297617.171564@mariner.uk.xensource.com> <20374.59940.607143.114201@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Jonathan Ludlam , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Driver domains communication protocol proposal X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol proposal"): > Ah, so what you're calling "vdi" in this case is a thing into which > vbd's can plug -- what we might call the backend "node" for a > particular disk image? Yes. > So we have: > > [A] <--> [B] <--> { [C], [D], [E] } > > Where: > * A is the actual disk image on stable storage somewhere > * B is the instance of the code that can access A and provide access > to VMs which connect to it (not persistent) > * C D and E are instances of code running inside the guest which > connect to B and provide a block device to the guest OS which looks > like A (again not persistent) > > Is that correct? Yes. > I think calling A a "virtual disk image" makes the most sense; reusing > that name for B is a bad idea given that it's already used for A in > XenServer terminology. (Jonathan, correct me if I'm wrong here.) Right. > I think that calling C D and E "vbd"s also makes sense. > > So we just need to have a good name for the running instance of a > blockback process / thread / whatever that accesses a particular VDI. > Virtual disk provider (VDP)? Block back instance (BBI)? Virtual block > backend (VBB)? Anything with "backend" in it is probably wrong because in general C, D and E are backend/frontend pairs. The thing that B has that A (the vdi) hasn't is that B has done all the preparatory work necessary for accessing the vdi apart from anything that involves exclusivity. "nonexclusive image context" aka "nic" ? :-) "nonexclusive image handle" aka "nih" :-) "preparatory exclusive (not) image session" ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:00:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSrKB-0004vo-G4; Fri, 11 May 2012 15:00:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrK9-0004tW-F0 for xen-devel@lists.xen.org; Fri, 11 May 2012 15:00:05 +0000 Received: from [85.158.143.99:47025] by server-2.bemta-4.messagelabs.com id F7/41-17550-5792DAF4; Fri, 11 May 2012 15:00:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1336748403!22319754!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26897 invoked from network); 11 May 2012 15:00:04 -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; 11 May 2012 15:00:04 -0000 X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208";a="12432444" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:00: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, 11 May 2012 16:00:03 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSrK6-0007L8-Se; Fri, 11 May 2012 15:00:02 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSrK6-0001vM-Fs; Fri, 11 May 2012 16:00:02 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.10609.18007.71477@mariner.uk.xensource.com> Date: Fri, 11 May 2012 16:00:01 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <20348.27879.297617.171564@mariner.uk.xensource.com> <20374.59940.607143.114201@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Jonathan Ludlam , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Driver domains communication protocol proposal X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol proposal"): > Ah, so what you're calling "vdi" in this case is a thing into which > vbd's can plug -- what we might call the backend "node" for a > particular disk image? Yes. > So we have: > > [A] <--> [B] <--> { [C], [D], [E] } > > Where: > * A is the actual disk image on stable storage somewhere > * B is the instance of the code that can access A and provide access > to VMs which connect to it (not persistent) > * C D and E are instances of code running inside the guest which > connect to B and provide a block device to the guest OS which looks > like A (again not persistent) > > Is that correct? Yes. > I think calling A a "virtual disk image" makes the most sense; reusing > that name for B is a bad idea given that it's already used for A in > XenServer terminology. (Jonathan, correct me if I'm wrong here.) Right. > I think that calling C D and E "vbd"s also makes sense. > > So we just need to have a good name for the running instance of a > blockback process / thread / whatever that accesses a particular VDI. > Virtual disk provider (VDP)? Block back instance (BBI)? Virtual block > backend (VBB)? Anything with "backend" in it is probably wrong because in general C, D and E are backend/frontend pairs. The thing that B has that A (the vdi) hasn't is that B has done all the preparatory work necessary for accessing the vdi apart from anything that involves exclusivity. "nonexclusive image context" aka "nic" ? :-) "nonexclusive image handle" aka "nih" :-) "preparatory exclusive (not) image session" ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:12:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSrW0-0005OR-Sj; Fri, 11 May 2012 15:12:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrVy-0005OM-DA for xen-devel@lists.xen.org; Fri, 11 May 2012 15:12:18 +0000 Received: from [85.158.138.51:18460] by server-11.bemta-3.messagelabs.com id 6D/3E-18894-15C2DAF4; Fri, 11 May 2012 15:12:17 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336749135!17712699!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19323 invoked from network); 11 May 2012 15:12:15 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 15:12:15 -0000 Received: by lbok6 with SMTP id k6so2457213lbo.32 for ; Fri, 11 May 2012 08:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpJ6lb2wgoGih8+GCZlG+ct2oBQ+STazYm4e00IVlx0=; b=LSEbOSvEi/787qpbkxd1qb7xm45dxpYbMyZWZf+0myKsnBVRUNrdRZo4oT4mUJ5QHi MMpsLP1zjMyoOLyJD0gsxPHOkth5GUC/9YL5+BjETXAdS5xgoj2yHu0TGxUr9dMBTAKt zms5WKwIjfbt3qZHljmQczOkX3axGVeOvRnwhY81CJCjisdo1fp7vInqsHGl9d/e+mYi zEwzQZ00Lwm4KX9TC2I/olXAjc+SfGD0OVjhDLNuhr1phL8drYQU6VLMhhKXiuG23fQb mmqeQ3nkNTXbvD7W1IREMKubdsU7D5s1ZqIhWifR0cYW3XVY6qf8E1ndKCnCg8WsWcKe lI7Q== MIME-Version: 1.0 Received: by 10.152.145.228 with SMTP id sx4mr8600567lab.45.1336749134545; Fri, 11 May 2012 08:12:14 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 08:12:14 -0700 (PDT) In-Reply-To: <1336745780.23818.80.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Date: Fri, 11 May 2012 23:12:14 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990667684200572237==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1990667684200572237== Content-Type: multipart/alternative; boundary=e89a8f2348bf5183fb04bfc429f9 --e89a8f2348bf5183fb04bfc429f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > When I do the "make install-tools" with xen-4.2-unstable, there are > > some errors about "warn_unused_result". > > Is it the error in code or the error in the compiling environment? > > Thank you so much. > > This commit > changeset: 25275:27d63b9f111a > user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 > summary: blktap2: Do not build with -O0 > has caused more warnings to be generated by the compiler, which in turn > leads to build failures. Since this is a compiler specific thing we are > still tracking them all down. > > Can you confirm which versionof xen-unstable.hg you are using -- there > have been several fixup patches since the above. If you are completely > up to date and you still see errors we can dig into whatever is left. > Thank you for your reply. I have used "hg pull; hg update" to update to the latest Xen and it is the version info: root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip changeset: 25287:54c8c9eaee92 tag: tip user: Dietmar Hahn date: Fri Apr 27 11:09:26 2012 +0200 summary: docs: add vpmu description to xen-command-line.markdown But, it still has the same errors. Thanks, Bei Guan > > Ian. (starting to think that this change wasn't suitable during a > feature freeze....) > > > > > > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing > > -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement > > -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d -D_LARGEFILE_SOURCE > > -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g > > -Wno-unused -fno-strict-aliasing -I../include -I../drivers > > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include > -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c > -c -o tapdisk-queue.o tapdisk-queue.c > > cc1: warnings being treated as errors > > tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92: > > tapdisk-queue.c:438: error: ignoring return value of =91read=92, declar= ed > > with attribute warn_unused_result > > make[5]: *** [tapdisk-queue.o] Error 1 > > make[5]: Leaving directory > > `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' > > make[4]: *** [subdir-install-drivers] Error 2 > > make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' > > make[3]: *** [subdirs-install] Error 2 > > make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' > > make[2]: *** [subdir-install-blktap2] Error 2 > > make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > > make: *** [install-tools] Error 2 > > ------ > > > root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src > -c -o tapdisk-log.o tapdisk-log.c > > cc1: warnings being treated as errors > > tapdisk-log.c: In function =91tlog_flush=92: > > tapdisk-log.c:250: error: ignoring return value of =91write=92, declare= d > > with attribute warn_unused_result > > ------ > > > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c > -c -o tapdisk2.o tapdisk2.c > > cc1: warnings being treated as errors > > tapdisk2.c: In function =91main=92: > > tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared wi= th > > attribute warn_unused_result > > ------ > > cc1: warnings being treated as errors > > tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92: > > tapdisk-stream.c:148: error: ignoring return value of =91read=92, decla= red > > with attribute warn_unused_result > > tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92: > > tapdisk-stream.c:158: error: ignoring return value of =91write=92, > > declared with attribute warn_unused_result > > tapdisk-stream.c: In function =91tapdisk_stream_print_request=92: > > tapdisk-stream.c:206: error: ignoring return value of =91write=92, > > declared with attribute warn_unused_result > > > > > > > > Best Regards, > > Bei Guan > > > > > --=20 Best Regards, Bei Guan --e89a8f2348bf5183fb04bfc429f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
2012/5/11 Ian Campbell <= ;Ian.Campbell@= citrix.com>
On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote:
> When I do the "make install-tools" with xen-4.2-unstable, th= ere are
> some errors about "warn_unused_result".
> Is it the error in code or the error in the compiling environment?
> Thank you so much.

This commit
=A0 =A0 =A0 =A0changeset: =A0 25275:27d63b9f111a
=A0 =A0 =A0 =A0user: =A0 =A0 =A0 =A0Keir Fraser <keir@xen.org>
=A0 =A0 =A0 =A0date: =A0 =A0 =A0 =A0Thu May 10 11:22:18 2012 +0100
=A0 =A0 =A0 =A0summary: =A0 =A0 blktap2: Do not build with -O0
has caused more warnings to be generated by the compiler, which in turn
leads to build failures. Since this is a compiler specific thing we are
still tracking them all down.

Can you confirm which versionof xen-unstable.hg you are using -- there
have been several fixup patches since the above. If you are completely
up to date and you still see errors we can dig into whatever is left.

Thank you for your reply. I have used "hg pull; hg= update" to update to the latest Xen and it is the version info:

root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip
changeset:=A0=A0 2= 5287:54c8c9eaee92
tag:=A0=A0=A0=A0=A0=A0=A0=A0 tip
user:=A0=A0=A0=A0= =A0=A0=A0 Dietmar Hahn <d= ietmar.hahn@ts.fujitsu.com>
date:=A0=A0=A0=A0=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0200
summary:=A0=A0= =A0=A0 docs: add vpmu description to xen-command-line.markdown

But, = it still has the same errors.


Thanks,
Bei Guan

=A0

Ian. (starting to think that this change wasn't suitable during a
feature freeze....)

>
>
> gcc =A0-O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
> -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement > -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d =A0-D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g
> -Wno-unused -fno-strict-aliasing -I../include -I../drivers
> -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libx= c -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include= -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/Xen/xen-4.2-unstable/tools/bl= ktap2/drivers/../../../tools/libaio/src =A0-c -o tapdisk-queue.o tapdisk-qu= eue.c
> cc1: warnings being treated as errors
> tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92:
> tapdisk-queue.c:438: error: ignoring return value of =91read=92, decla= red
> with attribute warn_unused_result
> make[5]: *** [tapdisk-queue.o] Error 1
> make[5]: Leaving directory
> `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers'
> make[4]: *** [subdir-install-drivers] Error 2
> make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2&#= 39;
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2&#= 39;
> make[2]: *** [subdir-install-blktap2] Error 2
> make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools'
> make: *** [install-tools] Error 2
> ------
> root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/= src =A0-c -o tapdisk-log.o tapdisk-log.c
> cc1: warnings being treated as errors
> tapdisk-log.c: In function =91tlog_flush=92:
> tapdisk-log.c:250: error: ignoring return value of =91write=92, declar= ed
> with attribute warn_unused_result
> ------
> /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio= /src =A0-c -o tapdisk2.o tapdisk2.c
> cc1: warnings being treated as errors
> tapdisk2.c: In function =91main=92:
> tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared w= ith
> attribute warn_unused_result
> ------
> cc1: warnings being treated as errors
> tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92:
> tapdisk-stream.c:148: error: ignoring return value of =91read=92, decl= ared
> with attribute warn_unused_result
> tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92:
> tapdisk-stream.c:158: error: ignoring return value of =91write=92,
> declared with attribute warn_unused_result
> tapdisk-stream.c: In function =91tapdisk_stream_print_request=92:
> tapdisk-stream.c:206: error: ignoring return value of =91write=92,
> declared with attribute warn_unused_result
>
>
>
> Best Regards,
> Bei Guan
>





--
Best Regard= s,
Bei Guan

--e89a8f2348bf5183fb04bfc429f9-- --===============1990667684200572237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1990667684200572237==-- From xen-devel-bounces@lists.xen.org Fri May 11 15:12:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSrW0-0005OR-Sj; Fri, 11 May 2012 15:12:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrVy-0005OM-DA for xen-devel@lists.xen.org; Fri, 11 May 2012 15:12:18 +0000 Received: from [85.158.138.51:18460] by server-11.bemta-3.messagelabs.com id 6D/3E-18894-15C2DAF4; Fri, 11 May 2012 15:12:17 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336749135!17712699!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19323 invoked from network); 11 May 2012 15:12:15 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 15:12:15 -0000 Received: by lbok6 with SMTP id k6so2457213lbo.32 for ; Fri, 11 May 2012 08:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpJ6lb2wgoGih8+GCZlG+ct2oBQ+STazYm4e00IVlx0=; b=LSEbOSvEi/787qpbkxd1qb7xm45dxpYbMyZWZf+0myKsnBVRUNrdRZo4oT4mUJ5QHi MMpsLP1zjMyoOLyJD0gsxPHOkth5GUC/9YL5+BjETXAdS5xgoj2yHu0TGxUr9dMBTAKt zms5WKwIjfbt3qZHljmQczOkX3axGVeOvRnwhY81CJCjisdo1fp7vInqsHGl9d/e+mYi zEwzQZ00Lwm4KX9TC2I/olXAjc+SfGD0OVjhDLNuhr1phL8drYQU6VLMhhKXiuG23fQb mmqeQ3nkNTXbvD7W1IREMKubdsU7D5s1ZqIhWifR0cYW3XVY6qf8E1ndKCnCg8WsWcKe lI7Q== MIME-Version: 1.0 Received: by 10.152.145.228 with SMTP id sx4mr8600567lab.45.1336749134545; Fri, 11 May 2012 08:12:14 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 08:12:14 -0700 (PDT) In-Reply-To: <1336745780.23818.80.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Date: Fri, 11 May 2012 23:12:14 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990667684200572237==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1990667684200572237== Content-Type: multipart/alternative; boundary=e89a8f2348bf5183fb04bfc429f9 --e89a8f2348bf5183fb04bfc429f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > When I do the "make install-tools" with xen-4.2-unstable, there are > > some errors about "warn_unused_result". > > Is it the error in code or the error in the compiling environment? > > Thank you so much. > > This commit > changeset: 25275:27d63b9f111a > user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 > summary: blktap2: Do not build with -O0 > has caused more warnings to be generated by the compiler, which in turn > leads to build failures. Since this is a compiler specific thing we are > still tracking them all down. > > Can you confirm which versionof xen-unstable.hg you are using -- there > have been several fixup patches since the above. If you are completely > up to date and you still see errors we can dig into whatever is left. > Thank you for your reply. I have used "hg pull; hg update" to update to the latest Xen and it is the version info: root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip changeset: 25287:54c8c9eaee92 tag: tip user: Dietmar Hahn date: Fri Apr 27 11:09:26 2012 +0200 summary: docs: add vpmu description to xen-command-line.markdown But, it still has the same errors. Thanks, Bei Guan > > Ian. (starting to think that this change wasn't suitable during a > feature freeze....) > > > > > > > gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing > > -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement > > -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d -D_LARGEFILE_SOURCE > > -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g > > -Wno-unused -fno-strict-aliasing -I../include -I../drivers > > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include > -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c > -c -o tapdisk-queue.o tapdisk-queue.c > > cc1: warnings being treated as errors > > tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92: > > tapdisk-queue.c:438: error: ignoring return value of =91read=92, declar= ed > > with attribute warn_unused_result > > make[5]: *** [tapdisk-queue.o] Error 1 > > make[5]: Leaving directory > > `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' > > make[4]: *** [subdir-install-drivers] Error 2 > > make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' > > make[3]: *** [subdirs-install] Error 2 > > make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2' > > make[2]: *** [subdir-install-blktap2] Error 2 > > make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > > make: *** [install-tools] Error 2 > > ------ > > > root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src > -c -o tapdisk-log.o tapdisk-log.c > > cc1: warnings being treated as errors > > tapdisk-log.c: In function =91tlog_flush=92: > > tapdisk-log.c:250: error: ignoring return value of =91write=92, declare= d > > with attribute warn_unused_result > > ------ > > > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c > -c -o tapdisk2.o tapdisk2.c > > cc1: warnings being treated as errors > > tapdisk2.c: In function =91main=92: > > tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared wi= th > > attribute warn_unused_result > > ------ > > cc1: warnings being treated as errors > > tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92: > > tapdisk-stream.c:148: error: ignoring return value of =91read=92, decla= red > > with attribute warn_unused_result > > tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92: > > tapdisk-stream.c:158: error: ignoring return value of =91write=92, > > declared with attribute warn_unused_result > > tapdisk-stream.c: In function =91tapdisk_stream_print_request=92: > > tapdisk-stream.c:206: error: ignoring return value of =91write=92, > > declared with attribute warn_unused_result > > > > > > > > Best Regards, > > Bei Guan > > > > > --=20 Best Regards, Bei Guan --e89a8f2348bf5183fb04bfc429f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
2012/5/11 Ian Campbell <= ;Ian.Campbell@= citrix.com>
On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote:
> When I do the "make install-tools" with xen-4.2-unstable, th= ere are
> some errors about "warn_unused_result".
> Is it the error in code or the error in the compiling environment?
> Thank you so much.

This commit
=A0 =A0 =A0 =A0changeset: =A0 25275:27d63b9f111a
=A0 =A0 =A0 =A0user: =A0 =A0 =A0 =A0Keir Fraser <keir@xen.org>
=A0 =A0 =A0 =A0date: =A0 =A0 =A0 =A0Thu May 10 11:22:18 2012 +0100
=A0 =A0 =A0 =A0summary: =A0 =A0 blktap2: Do not build with -O0
has caused more warnings to be generated by the compiler, which in turn
leads to build failures. Since this is a compiler specific thing we are
still tracking them all down.

Can you confirm which versionof xen-unstable.hg you are using -- there
have been several fixup patches since the above. If you are completely
up to date and you still see errors we can dig into whatever is left.

Thank you for your reply. I have used "hg pull; hg= update" to update to the latest Xen and it is the version info:

root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip
changeset:=A0=A0 2= 5287:54c8c9eaee92
tag:=A0=A0=A0=A0=A0=A0=A0=A0 tip
user:=A0=A0=A0=A0= =A0=A0=A0 Dietmar Hahn <d= ietmar.hahn@ts.fujitsu.com>
date:=A0=A0=A0=A0=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0200
summary:=A0=A0= =A0=A0 docs: add vpmu description to xen-command-line.markdown

But, = it still has the same errors.


Thanks,
Bei Guan

=A0

Ian. (starting to think that this change wasn't suitable during a
feature freeze....)

>
>
> gcc =A0-O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
> -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement > -D__XEN_TOOLS__ -MMD -MF .tapdisk-queue.o.d =A0-D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g
> -Wno-unused -fno-strict-aliasing -I../include -I../drivers
> -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libx= c -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include= -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I /root/Xen/xen-4.2-unstable/tools/bl= ktap2/drivers/../../../tools/libaio/src =A0-c -o tapdisk-queue.o tapdisk-qu= eue.c
> cc1: warnings being treated as errors
> tapdisk-queue.c: In function =91tapdisk_lio_ack_event=92:
> tapdisk-queue.c:438: error: ignoring return value of =91read=92, decla= red
> with attribute warn_unused_result
> make[5]: *** [tapdisk-queue.o] Error 1
> make[5]: Leaving directory
> `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers'
> make[4]: *** [subdir-install-drivers] Error 2
> make[4]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2&#= 39;
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/root/Xen/xen-4.2-unstable/tools/blktap2&#= 39;
> make[2]: *** [subdir-install-blktap2] Error 2
> make[2]: Leaving directory `/root/Xen/xen-4.2-unstable/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools'
> make: *** [install-tools] Error 2
> ------
> root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/= src =A0-c -o tapdisk-log.o tapdisk-log.c
> cc1: warnings being treated as errors
> tapdisk-log.c: In function =91tlog_flush=92:
> tapdisk-log.c:250: error: ignoring return value of =91write=92, declar= ed
> with attribute warn_unused_result
> ------
> /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio= /src =A0-c -o tapdisk2.o tapdisk2.c
> cc1: warnings being treated as errors
> tapdisk2.c: In function =91main=92:
> tapdisk2.c:82: error: ignoring return value of =91chdir=92, declared w= ith
> attribute warn_unused_result
> ------
> cc1: warnings being treated as errors
> tapdisk-stream.c: In function =91tapdisk_stream_poll_clear=92:
> tapdisk-stream.c:148: error: ignoring return value of =91read=92, decl= ared
> with attribute warn_unused_result
> tapdisk-stream.c: In function =91tapdisk_stream_poll_set=92:
> tapdisk-stream.c:158: error: ignoring return value of =91write=92,
> declared with attribute warn_unused_result
> tapdisk-stream.c: In function =91tapdisk_stream_print_request=92:
> tapdisk-stream.c:206: error: ignoring return value of =91write=92,
> declared with attribute warn_unused_result
>
>
>
> Best Regards,
> Bei Guan
>





--
Best Regard= s,
Bei Guan

--e89a8f2348bf5183fb04bfc429f9-- --===============1990667684200572237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1990667684200572237==-- From xen-devel-bounces@lists.xen.org Fri May 11 15:27:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:27:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrkB-0005Zx-Gt; Fri, 11 May 2012 15:26:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrkA-0005Zs-4E for xen-devel@lists.xen.org; Fri, 11 May 2012 15:26:58 +0000 Received: from [193.109.254.147:47986] by server-11.bemta-14.messagelabs.com id BB/40-05858-1CF2DAF4; Fri, 11 May 2012 15:26:57 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336750015!8782907!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23716 invoked from network); 11 May 2012 15:26:55 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 15:26:55 -0000 Received: by lahc1 with SMTP id c1so2174892lah.32 for ; Fri, 11 May 2012 08:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9x4GzUWmcRP2yNuk1kVbkJCNojKN6GhYmWFqyQk59xs=; b=kezMm2hilcL/d9t87HG2j4V6TJqP8+/Zkj+XykLlFTwGR6JaU5SyKHu/aOAOnc4Z36 IEO2M7MruagBNVp6P+pGNtrWAIz/u6h5dwNuHfPVWBb3S1bM4OlYaFgmfvLlSDqobaAH UWJf3ATZ5NXYX+HQAWtIb6htkie3g/oKLtGaAkqNSy5KuCCr5zITGAGSA30YbrYJptPI XGtcxVPICo0Ud4LaDNDgPmtQNjwRMJncKHQddEj/+sMl6EF6WQz+3qwp4HxPzB2mwk0p CqHswn5QObHU8rCG8IvGdwTfFCEh9w3gBmuMMj6c4ym1uvIFMyFCMmTFf3+qDn1sVK/l Zo2g== MIME-Version: 1.0 Received: by 10.112.46.198 with SMTP id x6mr4042652lbm.19.1336750014925; Fri, 11 May 2012 08:26:54 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 08:26:54 -0700 (PDT) In-Reply-To: <20120511141955.GA7991@aepfle.de> References: <20120511141955.GA7991@aepfle.de> Date: Fri, 11 May 2012 23:26:54 +0800 Message-ID: From: Bei Guan To: Olaf Hering Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9172580847804276381==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============9172580847804276381== Content-Type: multipart/alternative; boundary=bcaec5540604cb0bea04bfc45d5e --bcaec5540604cb0bea04bfc45d5e Content-Type: text/plain; charset=ISO-8859-1 2012/5/11 Olaf Hering > On Fri, May 11, Bei Guan wrote: > > > Hi, > > > > When I do the "make install-tools" with xen-4.2-unstable, there are some > errors > > about "warn_unused_result". > > Is it the error in code or the error in the compiling environment? Thank > you so > > much. > > I suggest to remove all -Werror from the Makefiles and introduce a > --disable-Werror/--enable-Werror configure option, similar to what > binutils and other projects have (not sure what the exact configure > option name is in those projects). > Thank you so much for your reply too. It is better to have such as a choice to enable or disable -Werror option. But, now it doesn't have in the configure file. Thanks, Bei Guan > > Olaf > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > -- Best Regards, Bei Guan --bcaec5540604cb0bea04bfc45d5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/11 Olaf Hering = <olaf@aepfle.de&= gt;
On Fri, May 11, Bei Guan wrote:

> Hi,
>
> When I do the "make install-tools" with xen-4.2-unstable, th= ere are some errors
> about "warn_unused_result".
> Is it the error in code or the error in the compiling environment? Tha= nk you so
> much.

I suggest to remove all -Werror from the Makefiles and introduce a --disable-Werror/--enable-Werror configure option, similar to what
binutils and other projects have (not sure what the exact configure
option name is in those projects).
Thank you so much f= or your reply too.
It is better to have such as a choice to enable or di= sable -Werror option. But, now it doesn't have in the configure file.

Thanks,
Bei Guan

=A0

Olaf

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



--
Best Regards,
Bei G= uan

--bcaec5540604cb0bea04bfc45d5e-- --===============9172580847804276381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9172580847804276381==-- From xen-devel-bounces@lists.xen.org Fri May 11 15:27:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:27:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrkB-0005Zx-Gt; Fri, 11 May 2012 15:26:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSrkA-0005Zs-4E for xen-devel@lists.xen.org; Fri, 11 May 2012 15:26:58 +0000 Received: from [193.109.254.147:47986] by server-11.bemta-14.messagelabs.com id BB/40-05858-1CF2DAF4; Fri, 11 May 2012 15:26:57 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336750015!8782907!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23716 invoked from network); 11 May 2012 15:26:55 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 15:26:55 -0000 Received: by lahc1 with SMTP id c1so2174892lah.32 for ; Fri, 11 May 2012 08:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9x4GzUWmcRP2yNuk1kVbkJCNojKN6GhYmWFqyQk59xs=; b=kezMm2hilcL/d9t87HG2j4V6TJqP8+/Zkj+XykLlFTwGR6JaU5SyKHu/aOAOnc4Z36 IEO2M7MruagBNVp6P+pGNtrWAIz/u6h5dwNuHfPVWBb3S1bM4OlYaFgmfvLlSDqobaAH UWJf3ATZ5NXYX+HQAWtIb6htkie3g/oKLtGaAkqNSy5KuCCr5zITGAGSA30YbrYJptPI XGtcxVPICo0Ud4LaDNDgPmtQNjwRMJncKHQddEj/+sMl6EF6WQz+3qwp4HxPzB2mwk0p CqHswn5QObHU8rCG8IvGdwTfFCEh9w3gBmuMMj6c4ym1uvIFMyFCMmTFf3+qDn1sVK/l Zo2g== MIME-Version: 1.0 Received: by 10.112.46.198 with SMTP id x6mr4042652lbm.19.1336750014925; Fri, 11 May 2012 08:26:54 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 08:26:54 -0700 (PDT) In-Reply-To: <20120511141955.GA7991@aepfle.de> References: <20120511141955.GA7991@aepfle.de> Date: Fri, 11 May 2012 23:26:54 +0800 Message-ID: From: Bei Guan To: Olaf Hering Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9172580847804276381==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============9172580847804276381== Content-Type: multipart/alternative; boundary=bcaec5540604cb0bea04bfc45d5e --bcaec5540604cb0bea04bfc45d5e Content-Type: text/plain; charset=ISO-8859-1 2012/5/11 Olaf Hering > On Fri, May 11, Bei Guan wrote: > > > Hi, > > > > When I do the "make install-tools" with xen-4.2-unstable, there are some > errors > > about "warn_unused_result". > > Is it the error in code or the error in the compiling environment? Thank > you so > > much. > > I suggest to remove all -Werror from the Makefiles and introduce a > --disable-Werror/--enable-Werror configure option, similar to what > binutils and other projects have (not sure what the exact configure > option name is in those projects). > Thank you so much for your reply too. It is better to have such as a choice to enable or disable -Werror option. But, now it doesn't have in the configure file. Thanks, Bei Guan > > Olaf > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > -- Best Regards, Bei Guan --bcaec5540604cb0bea04bfc45d5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/11 Olaf Hering = <olaf@aepfle.de&= gt;
On Fri, May 11, Bei Guan wrote:

> Hi,
>
> When I do the "make install-tools" with xen-4.2-unstable, th= ere are some errors
> about "warn_unused_result".
> Is it the error in code or the error in the compiling environment? Tha= nk you so
> much.

I suggest to remove all -Werror from the Makefiles and introduce a --disable-Werror/--enable-Werror configure option, similar to what
binutils and other projects have (not sure what the exact configure
option name is in those projects).
Thank you so much f= or your reply too.
It is better to have such as a choice to enable or di= sable -Werror option. But, now it doesn't have in the configure file.

Thanks,
Bei Guan

=A0

Olaf

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



--
Best Regards,
Bei G= uan

--bcaec5540604cb0bea04bfc45d5e-- --===============9172580847804276381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9172580847804276381==-- From xen-devel-bounces@lists.xen.org Fri May 11 15:46:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSs2I-0005rz-9U; Fri, 11 May 2012 15:45:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs2G-0005ru-EZ for xen-devel@lists.xensource.com; Fri, 11 May 2012 15:45:40 +0000 Received: from [85.158.138.51:44961] by server-3.bemta-3.messagelabs.com id 54/02-04048-3243DAF4; Fri, 11 May 2012 15:45:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336751137!26528527!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5939 invoked from network); 11 May 2012 15:45:38 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 15:45:38 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BFjajR013812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 15:45:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BFjZjh005959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 15:45:36 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BFjZ6j004365; Fri, 11 May 2012 10:45:35 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 08:45:35 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1253F40359; Fri, 11 May 2012 11:39:32 -0400 (EDT) Date: Fri, 11 May 2012 11:39:31 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120511153931.GA21486@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done So I tried this with 3.4-rc6 and didn't see this. The machine isn't that powerfull - just a Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz so four CPUs are visible. Let me try with 3.2.x shortly. > > BUG: unable to handle kernel paging request at bffff628 > IP: [] __page_check_address+0xb8/0x170 > *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 > EIP: 0061:[] EFLAGS: 00010246 CPU: 6 > EIP is at __page_check_address+0xb8/0x170 > EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 > ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 > Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) > Stack: > e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 > 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 > b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 > Call Trace: > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 > e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c > 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 > EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c > CR2: 00000000bffff628 > ---[ end trace 8039aeca9c19f5ab ]--- > note: lvremove[27902] exited with preempt_count 1 > BUG: scheduling while atomic: lvremove/27902/0x00000001 > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 > Call Trace: > [] __schedule_bug+0x5d/0x70 > [] __schedule+0x679/0x830 > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? rcu_enter_nohz+0x3c/0x60 > [] ? xen_evtchn_do_upcall+0x20/0x30 > [] ? hypercall_page+0x227/0x1000 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] schedule+0x30/0x50 > [] rwsem_down_failed_common+0x9d/0xf0 > [] rwsem_down_read_failed+0x12/0x14 > [] call_rwsem_down_read_failed+0x7/0xc > [] ? down_read+0xd/0x10 > [] acct_collect+0x3a/0x170 > [] do_exit+0x62a/0x7d0 > [] ? kmsg_dump+0x37/0xc0 > [] oops_end+0x90/0xd0 > [] no_context+0xbe/0x190 > [] __bad_area_nosemaphore+0x98/0x140 > [] ? xen_clocksource_read+0x19/0x20 > [] ? xen_vcpuop_set_next_event+0x47/0x80 > [] bad_area_nosemaphore+0x12/0x20 > [] do_page_fault+0x2d2/0x3f0 > [] ? hrtimer_interrupt+0x1a9/0x2b0 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] ? check_events+0x8/0xc > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? _raw_spin_unlock_irqrestore+0x14/0x20 > [] ? spurious_fault+0x130/0x130 > [] error_code+0x5a/0x60 > [] ? spurious_fault+0x130/0x130 > [] ? __page_check_address+0xb8/0x170 > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > > Thanks, > -Chris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:46:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSs2I-0005rz-9U; Fri, 11 May 2012 15:45:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs2G-0005ru-EZ for xen-devel@lists.xensource.com; Fri, 11 May 2012 15:45:40 +0000 Received: from [85.158.138.51:44961] by server-3.bemta-3.messagelabs.com id 54/02-04048-3243DAF4; Fri, 11 May 2012 15:45:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1336751137!26528527!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5939 invoked from network); 11 May 2012 15:45:38 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 15:45:38 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BFjajR013812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 15:45:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BFjZjh005959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 15:45:36 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BFjZ6j004365; Fri, 11 May 2012 10:45:35 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 08:45:35 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1253F40359; Fri, 11 May 2012 11:39:32 -0400 (EDT) Date: Fri, 11 May 2012 11:39:31 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120511153931.GA21486@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done So I tried this with 3.4-rc6 and didn't see this. The machine isn't that powerfull - just a Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz so four CPUs are visible. Let me try with 3.2.x shortly. > > BUG: unable to handle kernel paging request at bffff628 > IP: [] __page_check_address+0xb8/0x170 > *pdpt = 0000000003cfb027 *pde = 0000000013873067 *pte = 0000000000000000 > Oops: 0000 [#1] SMP > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Not tainted 3.2.6-1 #1 Supermicro X8DT6/X8DT6 > EIP: 0061:[] EFLAGS: 00010246 CPU: 6 > EIP is at __page_check_address+0xb8/0x170 > EAX: bffff000 EBX: cbf76dd8 ECX: 00000000 EDX: 00000000 > ESI: bffff628 EDI: e49ed900 EBP: c80ffe60 ESP: c80ffe4c > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 > Process lvremove (pid: 27902, ti=c80fe000 task=d29adca0 task.ti=c80fe000) > Stack: > e4205000 00000fff da9b6bc0 d0068dc0 e49ed900 c80ffe94 c10ec769 c80ffe84 > 00000000 00000129 00000125 b76c5000 00000001 00000000 d0068c08 d0068dc0 > b76c5000 e49ed900 c80fff24 c10ecb73 00000002 00000005 35448025 c80ffec4 > Call Trace: > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > Code: ff c1 ee 09 81 e6 f8 0f 00 00 81 e1 ff 0f 00 00 0f ac ca 0c c1 > e2 05 03 55 ec 89 d0 e8 12 d3 f4 ff 8b 4d 0c 85 c9 8d 34 30 75 0c > 06 01 01 00 00 0f 84 84 00 00 00 8b 0d 00 0e 9b c1 89 4d f0 > EIP: [] __page_check_address+0xb8/0x170 SS:ESP 0069:c80ffe4c > CR2: 00000000bffff628 > ---[ end trace 8039aeca9c19f5ab ]--- > note: lvremove[27902] exited with preempt_count 1 > BUG: scheduling while atomic: lvremove/27902/0x00000001 > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 > ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev e1000e > Pid: 27902, comm: lvremove Tainted: G D 3.2.6-1 #1 > Call Trace: > [] __schedule_bug+0x5d/0x70 > [] __schedule+0x679/0x830 > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? rcu_enter_nohz+0x3c/0x60 > [] ? xen_evtchn_do_upcall+0x20/0x30 > [] ? hypercall_page+0x227/0x1000 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] schedule+0x30/0x50 > [] rwsem_down_failed_common+0x9d/0xf0 > [] rwsem_down_read_failed+0x12/0x14 > [] call_rwsem_down_read_failed+0x7/0xc > [] ? down_read+0xd/0x10 > [] acct_collect+0x3a/0x170 > [] do_exit+0x62a/0x7d0 > [] ? kmsg_dump+0x37/0xc0 > [] oops_end+0x90/0xd0 > [] no_context+0xbe/0x190 > [] __bad_area_nosemaphore+0x98/0x140 > [] ? xen_clocksource_read+0x19/0x20 > [] ? xen_vcpuop_set_next_event+0x47/0x80 > [] bad_area_nosemaphore+0x12/0x20 > [] do_page_fault+0x2d2/0x3f0 > [] ? hrtimer_interrupt+0x1a9/0x2b0 > [] ? xen_force_evtchn_callback+0x1a/0x30 > [] ? check_events+0x8/0xc > [] ? xen_restore_fl_direct_reloc+0x4/0x4 > [] ? _raw_spin_unlock_irqrestore+0x14/0x20 > [] ? spurious_fault+0x130/0x130 > [] error_code+0x5a/0x60 > [] ? spurious_fault+0x130/0x130 > [] ? __page_check_address+0xb8/0x170 > [] try_to_unmap_one+0x29/0x310 > [] try_to_unmap_file+0x83/0x560 > [] ? xen_pte_val+0xb9/0x140 > [] ? __raw_callee_save_xen_pte_val+0x6/0x8 > [] ? vm_normal_page+0x28/0xc0 > [] ? kmap_atomic_prot+0x45/0x110 > [] try_to_munlock+0x1c/0x40 > [] munlock_vma_page+0x49/0x90 > [] munlock_vma_pages_range+0x57/0xa0 > [] mlock_fixup+0xc2/0x130 > [] do_mlockall+0x6c/0x80 > [] sys_munlockall+0x29/0x50 > [] sysenter_do_call+0x12/0x28 > > Thanks, > -Chris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:47:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSs40-0005vy-PN; Fri, 11 May 2012 15:47:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs3y-0005vm-Ki for xen-devel@lists.xen.org; Fri, 11 May 2012 15:47:26 +0000 Received: from [193.109.254.147:17442] by server-11.bemta-14.messagelabs.com id BD/1A-05858-D843DAF4; Fri, 11 May 2012 15:47:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336751245!8887207!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28951 invoked from network); 11 May 2012 15:47:25 -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; 11 May 2012 15:47:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433686" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:47: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, 11 May 2012 16:47:24 +0100 Message-ID: <1336751243.23818.106.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan , Keir Fraser Date: Fri, 11 May 2012 16:47:23 +0100 In-Reply-To: References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: > > 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > When I do the "make install-tools" with xen-4.2-unstable, > there are > > some errors about "warn_unused_result". > > Is it the error in code or the error in the compiling > environment? > > Thank you so much. > > > This commit > changeset: 25275:27d63b9f111a > user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 > summary: blktap2: Do not build with -O0 > has caused more warnings to be generated by the compiler, > which in turn > leads to build failures. Since this is a compiler specific > thing we are > still tracking them all down. > > Can you confirm which versionof xen-unstable.hg you are using > -- there > have been several fixup patches since the above. If you are > completely > up to date and you still see errors we can dig into whatever > is left. > > Thank you for your reply. I have used "hg pull; hg update" to update > to the latest Xen and it is the version info: > > root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip > changeset: 25287:54c8c9eaee92 > tag: tip > user: Dietmar Hahn > date: Fri Apr 27 11:09:26 2012 +0200 > summary: docs: add vpmu description to xen-command-line.markdown > > But, it still has the same errors. Thanks, looks like we still need to fix these errors then. I'm not really happy with the following, but it's no worse than things are today... Bei, I don't see these build failures, does this work for you? 8<------------------------------------------------------ # HG changeset patch # User Ian Campbell # Date 1336751175 -3600 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 blktap: avoid attribute warn_unused_result build failures. I'm not proud of this, but since none of these callers of read/write have any other error handling and return void themselves (for several links up the call chain AFAICT) and because I don't really want to get into a massive reworking of blktap2 I suppose it is at least pragmatic Signed-off-by: Ian Campbell diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:46:15 2012 +0100 @@ -247,7 +247,7 @@ tlog_flush(void) wsize = ((size + 511) & (~511)); memset(tapdisk_log.buf + size, '\n', wsize - size); - write(fd, tapdisk_log.buf, wsize); + (void)write(fd, tapdisk_log.buf, wsize); tapdisk_log.p = tapdisk_log.buf; diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:46:15 2012 +0100 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que uint64_t val; if (lio->flags & LIO_FLAG_EVENTFD) - read(lio->event_fd, &val, sizeof(val)); + (void)read(lio->event_fd, &val, sizeof(val)); } static void diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:46:15 2012 +0100 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk { int dummy; - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); p->set = 0; } @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s int dummy = 0; if (!p->set) { - write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); + (void)write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); p->set = 1; } } @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd { unsigned long idx = (unsigned long)tapdisk_stream_request_idx(s, sreq); char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, idx, 0); - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); + (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); } static void diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 2012 +0100 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) if (optind != argc) usage(argv[0], EINVAL); - chdir("/"); + if (chdir("/")) { + DPRINTF("failed to chdir(/): %d\n", errno); + err = 1; + goto out; + } + tapdisk_start_logging("tapdisk2"); err = tapdisk_server_init(); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:47:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15: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 ) id 1SSs40-0005vy-PN; Fri, 11 May 2012 15:47:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs3y-0005vm-Ki for xen-devel@lists.xen.org; Fri, 11 May 2012 15:47:26 +0000 Received: from [193.109.254.147:17442] by server-11.bemta-14.messagelabs.com id BD/1A-05858-D843DAF4; Fri, 11 May 2012 15:47:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336751245!8887207!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28951 invoked from network); 11 May 2012 15:47:25 -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; 11 May 2012 15:47:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433686" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:47: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, 11 May 2012 16:47:24 +0100 Message-ID: <1336751243.23818.106.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan , Keir Fraser Date: Fri, 11 May 2012 16:47:23 +0100 In-Reply-To: References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: > > 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > When I do the "make install-tools" with xen-4.2-unstable, > there are > > some errors about "warn_unused_result". > > Is it the error in code or the error in the compiling > environment? > > Thank you so much. > > > This commit > changeset: 25275:27d63b9f111a > user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 > summary: blktap2: Do not build with -O0 > has caused more warnings to be generated by the compiler, > which in turn > leads to build failures. Since this is a compiler specific > thing we are > still tracking them all down. > > Can you confirm which versionof xen-unstable.hg you are using > -- there > have been several fixup patches since the above. If you are > completely > up to date and you still see errors we can dig into whatever > is left. > > Thank you for your reply. I have used "hg pull; hg update" to update > to the latest Xen and it is the version info: > > root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip > changeset: 25287:54c8c9eaee92 > tag: tip > user: Dietmar Hahn > date: Fri Apr 27 11:09:26 2012 +0200 > summary: docs: add vpmu description to xen-command-line.markdown > > But, it still has the same errors. Thanks, looks like we still need to fix these errors then. I'm not really happy with the following, but it's no worse than things are today... Bei, I don't see these build failures, does this work for you? 8<------------------------------------------------------ # HG changeset patch # User Ian Campbell # Date 1336751175 -3600 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 blktap: avoid attribute warn_unused_result build failures. I'm not proud of this, but since none of these callers of read/write have any other error handling and return void themselves (for several links up the call chain AFAICT) and because I don't really want to get into a massive reworking of blktap2 I suppose it is at least pragmatic Signed-off-by: Ian Campbell diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:46:15 2012 +0100 @@ -247,7 +247,7 @@ tlog_flush(void) wsize = ((size + 511) & (~511)); memset(tapdisk_log.buf + size, '\n', wsize - size); - write(fd, tapdisk_log.buf, wsize); + (void)write(fd, tapdisk_log.buf, wsize); tapdisk_log.p = tapdisk_log.buf; diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:46:15 2012 +0100 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que uint64_t val; if (lio->flags & LIO_FLAG_EVENTFD) - read(lio->event_fd, &val, sizeof(val)); + (void)read(lio->event_fd, &val, sizeof(val)); } static void diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:46:15 2012 +0100 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk { int dummy; - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); p->set = 0; } @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s int dummy = 0; if (!p->set) { - write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); + (void)write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); p->set = 1; } } @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd { unsigned long idx = (unsigned long)tapdisk_stream_request_idx(s, sreq); char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, idx, 0); - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); + (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); } static void diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 2012 +0100 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) if (optind != argc) usage(argv[0], EINVAL); - chdir("/"); + if (chdir("/")) { + DPRINTF("failed to chdir(/): %d\n", errno); + err = 1; + goto out; + } + tapdisk_start_logging("tapdisk2"); err = tapdisk_server_init(); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:52:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs8I-000683-Fx; Fri, 11 May 2012 15:51:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs8G-00067x-Um for xen-devel@lists.xen.org; Fri, 11 May 2012 15:51:53 +0000 Received: from [85.158.143.99:42981] by server-1.bemta-4.messagelabs.com id A8/8D-20925-8953DAF4; Fri, 11 May 2012 15:51:52 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-216.messagelabs.com!1336751510!26685545!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDk3NzE=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDk3NzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11987 invoked from network); 11 May 2012 15:51:50 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 15:51:50 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (joses mo32) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V00da9o4BFNpBG ; Fri, 11 May 2012 17:51:49 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 8AE9618637; Fri, 11 May 2012 17:51:48 +0200 (CEST) Date: Fri, 11 May 2012 17:51:48 +0200 From: Olaf Hering To: Keir Fraser Message-ID: <20120511155148.GA21206@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, Keir Fraser wrote: > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) Keir, the changes to unmodified_drivers//linux-2.6/ should be backported to the 4.1 branch: changeset: 25069:46bf3ab42baf changeset: 25067:05768bd498f2 optional: changeset: 24045:4ed766d70396 changeset: 25068:e4460795ee66 Also the asm/system.h patch I sent out today is a candidate. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:52:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs8I-000683-Fx; Fri, 11 May 2012 15:51:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSs8G-00067x-Um for xen-devel@lists.xen.org; Fri, 11 May 2012 15:51:53 +0000 Received: from [85.158.143.99:42981] by server-1.bemta-4.messagelabs.com id A8/8D-20925-8953DAF4; Fri, 11 May 2012 15:51:52 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-13.tower-216.messagelabs.com!1336751510!26685545!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDk3NzE=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMDk3NzE=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11987 invoked from network); 11 May 2012 15:51:50 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 15:51:50 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (joses mo32) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V00da9o4BFNpBG ; Fri, 11 May 2012 17:51:49 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 8AE9618637; Fri, 11 May 2012 17:51:48 +0200 (CEST) Date: Fri, 11 May 2012 17:51:48 +0200 From: Olaf Hering To: Keir Fraser Message-ID: <20120511155148.GA21206@aepfle.de> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] First release candidates for Xen 4.0.4 and 4.1.3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, May 07, Keir Fraser wrote: > http://xenbits.xen.org/staging/xen-4.1-testing.hg (tag 4.1.3-rc1) Keir, the changes to unmodified_drivers//linux-2.6/ should be backported to the 4.1 branch: changeset: 25069:46bf3ab42baf changeset: 25067:05768bd498f2 optional: changeset: 24045:4ed766d70396 changeset: 25068:e4460795ee66 Also the asm/system.h patch I sent out today is a candidate. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:58:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSsEO-0006IE-9T; Fri, 11 May 2012 15:58:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsEM-0006I6-CP for xen-devel@lists.xen.org; Fri, 11 May 2012 15:58:10 +0000 Received: from [85.158.138.51:42142] by server-10.bemta-3.messagelabs.com id A2/F4-29478-1173DAF4; Fri, 11 May 2012 15:58:09 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336751888!22589239!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18101 invoked from network); 11 May 2012 15:58:08 -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; 11 May 2012 15:58:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:58: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, 11 May 2012 16:58:07 +0100 Date: Fri, 11 May 2012 16:57:52 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> Message-ID: References: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel , Ian Jackson , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > >>> On 04.05.12 at 13:12, Stefano Stabellini wrote: > > Hi all, > > this patch implements local_attach support for QDISK: that means that > > you can use qcow2 as disk format for your PV guests disks and use > > pygrub to retrieve the kernel and initrd in dom0. > > > > The idea is that we start a QEMU instance at boot time to listen to > > local_attach requests. When libxl_device_disk_local_attach is called on > > a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk > > so that blkfront in dom0 will create a new xvd device for it. > > Then pygrub can be pointed at this device to retrieve kernel and > > initrd. > > So I pulled this into my local tree to be able to debug problems in > our gntdev driver in a reasonably isolated way (i.e. not needing > to fire up guests). While block-attach works fine, block-detach > doesn't at all. This may be related to me using the deprecated > file:/ form of specifying the source during attach, as all of the > supposedly modern forms I tried weren't accepted by the parser. Block-detach needs another small patch to libxl in order to work. I'll add it as part of the next local_attach patch series. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:58:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSsEO-0006IE-9T; Fri, 11 May 2012 15:58:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsEM-0006I6-CP for xen-devel@lists.xen.org; Fri, 11 May 2012 15:58:10 +0000 Received: from [85.158.138.51:42142] by server-10.bemta-3.messagelabs.com id A2/F4-29478-1173DAF4; Fri, 11 May 2012 15:58:09 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336751888!22589239!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18101 invoked from network); 11 May 2012 15:58:08 -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; 11 May 2012 15:58:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:58: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, 11 May 2012 16:58:07 +0100 Date: Fri, 11 May 2012 16:57:52 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> Message-ID: References: <4FABD9C00200007800082BC5@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: xen-devel , Ian Jackson , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v5 0/8] qdisk local attach X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > >>> On 04.05.12 at 13:12, Stefano Stabellini wrote: > > Hi all, > > this patch implements local_attach support for QDISK: that means that > > you can use qcow2 as disk format for your PV guests disks and use > > pygrub to retrieve the kernel and initrd in dom0. > > > > The idea is that we start a QEMU instance at boot time to listen to > > local_attach requests. When libxl_device_disk_local_attach is called on > > a QDISK images, libxl sets up a backend/frontend pair in dom0 for the disk > > so that blkfront in dom0 will create a new xvd device for it. > > Then pygrub can be pointed at this device to retrieve kernel and > > initrd. > > So I pulled this into my local tree to be able to debug problems in > our gntdev driver in a reasonably isolated way (i.e. not needing > to fire up guests). While block-attach works fine, block-detach > doesn't at all. This may be related to me using the deprecated > file:/ form of specifying the source during attach, as all of the > supposedly modern forms I tried weren't accepted by the parser. Block-detach needs another small patch to libxl in order to work. I'll add it as part of the next local_attach patch series. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:59:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:59:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsFT-0006LH-OM; Fri, 11 May 2012 15:59:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsFR-0006L7-S4 for xen-devel@lists.xensource.com; Fri, 11 May 2012 15:59:17 +0000 Received: from [85.158.143.35:48845] by server-2.bemta-4.messagelabs.com id 8D/ED-17550-5573DAF4; Fri, 11 May 2012 15:59:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336751955!10561436!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8164 invoked from network); 11 May 2012 15:59:15 -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; 11 May 2012 15:59:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433867" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:59:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 16:59:15 +0100 Message-ID: <1336751953.23818.118.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Fri, 11 May 2012 16:59:13 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 15:35 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336743357 -7200 > # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > unmodified_drivers: remove inclusion of asm/system.h > > Allow compilation of PVonHVM drivers with forward-ported xenlinux > sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present > anymore. Remove inclusion of this header, its not needed. It is not needed for 3.4 or it is not needed for any historical Linux version which these drivers are supposed to be built against? What kernels have you build tested? Ian. > Signed-off-by: Olaf Hering > > diff -r 0f53540494f7 -r f81fa4014d8c 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 > @@ -30,7 +30,6 @@ > #include > #include > #include > -#include > #include > #include > #include > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 15:59:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 15:59:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsFT-0006LH-OM; Fri, 11 May 2012 15:59:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsFR-0006L7-S4 for xen-devel@lists.xensource.com; Fri, 11 May 2012 15:59:17 +0000 Received: from [85.158.143.35:48845] by server-2.bemta-4.messagelabs.com id 8D/ED-17550-5573DAF4; Fri, 11 May 2012 15:59:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336751955!10561436!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8164 invoked from network); 11 May 2012 15:59:15 -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; 11 May 2012 15:59:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433867" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 15:59:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 16:59:15 +0100 Message-ID: <1336751953.23818.118.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Olaf Hering Date: Fri, 11 May 2012 16:59:13 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 15:35 +0100, Olaf Hering wrote: > # HG changeset patch > # User Olaf Hering > # Date 1336743357 -7200 > # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > unmodified_drivers: remove inclusion of asm/system.h > > Allow compilation of PVonHVM drivers with forward-ported xenlinux > sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present > anymore. Remove inclusion of this header, its not needed. It is not needed for 3.4 or it is not needed for any historical Linux version which these drivers are supposed to be built against? What kernels have you build tested? Ian. > Signed-off-by: Olaf Hering > > diff -r 0f53540494f7 -r f81fa4014d8c 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 > @@ -30,7 +30,6 @@ > #include > #include > #include > -#include > #include > #include > #include > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:02:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:02:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsIB-0006wx-Ej; Fri, 11 May 2012 16:02:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsIA-0006wp-KQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:02:06 +0000 Received: from [193.109.254.147:49546] by server-11.bemta-14.messagelabs.com id D1/5B-05858-DF73DAF4; Fri, 11 May 2012 16:02:05 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336752125!1956663!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11901 invoked from network); 11 May 2012 16:02:05 -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; 11 May 2012 16:02:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433922" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:02:05 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:02:04 +0100 Date: Fri, 11 May 2012 17:01:49 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> Message-ID: References: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > While for the "normal" case (called from blk_send_response_all()) > decrementing requests_finished is correct, doing so in the parse error > case is wrong; requests_inflight needs to be decremented instead. > > Signed-off-by: Jan Beulich > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i > blkdev->requests_finished++; > } > > -static void ioreq_release(struct ioreq *ioreq) > +static void ioreq_release(struct ioreq *ioreq, bool finish) > { > struct XenBlkDev *blkdev = ioreq->blkdev; > > @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * > memset(ioreq, 0, sizeof(*ioreq)); > ioreq->blkdev = blkdev; > QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); > - blkdev->requests_finished--; > + if (finish) > + blkdev->requests_finished--; > + else > + blkdev->requests_inflight--; > } > > /* > @@ -449,7 +452,7 @@ static void blk_send_response_all(struct > while (!QLIST_EMPTY(&blkdev->finished)) { > ioreq = QLIST_FIRST(&blkdev->finished); > send_notify += blk_send_response_one(ioreq); > - ioreq_release(ioreq); > + ioreq_release(ioreq, true); > } > if (send_notify) { > xen_be_send_notify(&blkdev->xendev); > @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X > if (blk_send_response_one(ioreq)) { > xen_be_send_notify(&blkdev->xendev); > } > - ioreq_release(ioreq); > + ioreq_release(ioreq, false); > continue; > } In case of an error returned by ioreq_parse requests_finished should also be decremented. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:02:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:02:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsIB-0006wx-Ej; Fri, 11 May 2012 16:02:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsIA-0006wp-KQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:02:06 +0000 Received: from [193.109.254.147:49546] by server-11.bemta-14.messagelabs.com id D1/5B-05858-DF73DAF4; Fri, 11 May 2012 16:02:05 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336752125!1956663!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11901 invoked from network); 11 May 2012 16:02:05 -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; 11 May 2012 16:02:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433922" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:02:05 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:02:04 +0100 Date: Fri, 11 May 2012 17:01:49 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> Message-ID: References: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jan Beulich wrote: > While for the "normal" case (called from blk_send_response_all()) > decrementing requests_finished is correct, doing so in the parse error > case is wrong; requests_inflight needs to be decremented instead. > > Signed-off-by: Jan Beulich > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i > blkdev->requests_finished++; > } > > -static void ioreq_release(struct ioreq *ioreq) > +static void ioreq_release(struct ioreq *ioreq, bool finish) > { > struct XenBlkDev *blkdev = ioreq->blkdev; > > @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * > memset(ioreq, 0, sizeof(*ioreq)); > ioreq->blkdev = blkdev; > QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); > - blkdev->requests_finished--; > + if (finish) > + blkdev->requests_finished--; > + else > + blkdev->requests_inflight--; > } > > /* > @@ -449,7 +452,7 @@ static void blk_send_response_all(struct > while (!QLIST_EMPTY(&blkdev->finished)) { > ioreq = QLIST_FIRST(&blkdev->finished); > send_notify += blk_send_response_one(ioreq); > - ioreq_release(ioreq); > + ioreq_release(ioreq, true); > } > if (send_notify) { > xen_be_send_notify(&blkdev->xendev); > @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X > if (blk_send_response_one(ioreq)) { > xen_be_send_notify(&blkdev->xendev); > } > - ioreq_release(ioreq); > + ioreq_release(ioreq, false); > continue; > } In case of an error returned by ioreq_parse requests_finished should also be decremented. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:04:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:04:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsKB-00075A-Vx; Fri, 11 May 2012 16:04:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsKA-00074t-AQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:04:10 +0000 Received: from [85.158.143.35:10477] by server-2.bemta-4.messagelabs.com id 6C/83-17550-9783DAF4; Fri, 11 May 2012 16:04:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336752248!14130519!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26494 invoked from network); 11 May 2012 16:04:08 -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; 11 May 2012 16:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433953" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16: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; Fri, 11 May 2012 17:04:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsK6-0007fw-Ok; Fri, 11 May 2012 16:04:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsK6-00021B-My; Fri, 11 May 2012 17:04:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.14454.676453.9389@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:04:06 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335352142-43858-1-git-send-email-roger.pau@citrix.com> References: <1335352142-43858-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is running. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is running."): > Prevent xl from doing any operation if xend daemon is running. That > prevents bugs that happened when xl and xend raced to close a domain. Thanks, Acked-by: Ian Jackson I tried to apply this but I'm afraid it needs a refresh. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:04:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:04:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsKB-00075A-Vx; Fri, 11 May 2012 16:04:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsKA-00074t-AQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:04:10 +0000 Received: from [85.158.143.35:10477] by server-2.bemta-4.messagelabs.com id 6C/83-17550-9783DAF4; Fri, 11 May 2012 16:04:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336752248!14130519!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26494 invoked from network); 11 May 2012 16:04:08 -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; 11 May 2012 16:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12433953" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16: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; Fri, 11 May 2012 17:04:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsK6-0007fw-Ok; Fri, 11 May 2012 16:04:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsK6-00021B-My; Fri, 11 May 2012 17:04:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.14454.676453.9389@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:04:06 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335352142-43858-1-git-send-email-roger.pau@citrix.com> References: <1335352142-43858-1-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is running. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH v3] libxl: prevent xl from running if xend is running."): > Prevent xl from doing any operation if xend daemon is running. That > prevents bugs that happened when xl and xend raced to close a domain. Thanks, Acked-by: Ian Jackson I tried to apply this but I'm afraid it needs a refresh. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:07:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMu-0007Ev-V7; Fri, 11 May 2012 16:07:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMs-0007Eb-RQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:06:59 +0000 Received: from [85.158.138.51:11506] by server-10.bemta-3.messagelabs.com id DE/4A-29478-1293DAF4; Fri, 11 May 2012 16:06:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336752416!7941043!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17923 invoked from network); 11 May 2012 16:06:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:06:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:06:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:06:56 +0100 Date: Fri, 11 May 2012 17:06:41 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jean Guyader In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jean Guyader wrote: > After a host sleep MSI will be off on the host but qemu still thinks > it's on because of some state that have been set previously. > > If qemu thinks that the device has been configure already > and the host MSI are disabled tell Xen to reconfigure the MSI. > > Signed-off-by: Jean Guyader > > diff --git a/hw/pass-through.c b/hw/pass-through.c > index f832c5a..a6a9b7a 100644 > --- a/hw/pass-through.c > +++ b/hw/pass-through.c > @@ -3772,6 +3772,21 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev, > return 0; > } > > +static int msi_is_enable(struct pt_dev *dev) > +{ > + uint16_t val = 0; > + uint32_t address = 0; > + if (!dev->msi) > + return 0; > + > + address = dev->msi->ctrl_offset; > + if (!address) > + return 0; > + > + val = pci_read_word(dev->pci_dev, address); > + return val & PCI_MSI_FLAGS_ENABLE; > +} > + > /* write Message Control register */ > static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > struct pt_reg_tbl *cfg_entry, > @@ -3803,8 +3818,7 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > /* update MSI */ > if (val & PCI_MSI_FLAGS_ENABLE) > { > - /* setup MSI pirq for the first time */ > - if (ptdev->msi->flags & MSI_FLAG_UNINIT) > + if (!msi_is_enable(ptdev)) > { > if (ptdev->msi_trans_en) { > PT_LOG("guest enabling MSI, disable MSI-INTx translation\n"); > diff --git a/hw/pt-msi.c b/hw/pt-msi.c > index 70c4023..99f9afd 100644 > --- a/hw/pt-msi.c > +++ b/hw/pt-msi.c > @@ -67,12 +67,6 @@ int pt_msi_setup(struct pt_dev *dev) > int pirq = -1; > uint8_t gvec = 0; > > - if ( !(dev->msi->flags & MSI_FLAG_UNINIT) ) > - { > - PT_LOG("Error: setup physical after initialized?? \n"); > - return -1; > - } > - > gvec = dev->msi->data & 0xFF; > if (!gvec) { > /* if gvec is 0, the guest is asking for a particular pirq that The patch makes sense. Only one last comment, sorry for not having noticed this before, but there might be another (flags & MSI_FLAG_UNINIT) check that should probably be changed into msi_is_enable in pt_msi_disable. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:07:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMu-0007Ev-V7; Fri, 11 May 2012 16:07:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMs-0007Eb-RQ for xen-devel@lists.xen.org; Fri, 11 May 2012 16:06:59 +0000 Received: from [85.158.138.51:11506] by server-10.bemta-3.messagelabs.com id DE/4A-29478-1293DAF4; Fri, 11 May 2012 16:06:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336752416!7941043!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17923 invoked from network); 11 May 2012 16:06:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:06:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:06:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:06:56 +0100 Date: Fri, 11 May 2012 17:06:41 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jean Guyader In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefano Stabellini , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] qemu-xen-traditional: Enable MSI after host sleep (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 10 May 2012, Jean Guyader wrote: > After a host sleep MSI will be off on the host but qemu still thinks > it's on because of some state that have been set previously. > > If qemu thinks that the device has been configure already > and the host MSI are disabled tell Xen to reconfigure the MSI. > > Signed-off-by: Jean Guyader > > diff --git a/hw/pass-through.c b/hw/pass-through.c > index f832c5a..a6a9b7a 100644 > --- a/hw/pass-through.c > +++ b/hw/pass-through.c > @@ -3772,6 +3772,21 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev, > return 0; > } > > +static int msi_is_enable(struct pt_dev *dev) > +{ > + uint16_t val = 0; > + uint32_t address = 0; > + if (!dev->msi) > + return 0; > + > + address = dev->msi->ctrl_offset; > + if (!address) > + return 0; > + > + val = pci_read_word(dev->pci_dev, address); > + return val & PCI_MSI_FLAGS_ENABLE; > +} > + > /* write Message Control register */ > static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > struct pt_reg_tbl *cfg_entry, > @@ -3803,8 +3818,7 @@ static int pt_msgctrl_reg_write(struct pt_dev *ptdev, > /* update MSI */ > if (val & PCI_MSI_FLAGS_ENABLE) > { > - /* setup MSI pirq for the first time */ > - if (ptdev->msi->flags & MSI_FLAG_UNINIT) > + if (!msi_is_enable(ptdev)) > { > if (ptdev->msi_trans_en) { > PT_LOG("guest enabling MSI, disable MSI-INTx translation\n"); > diff --git a/hw/pt-msi.c b/hw/pt-msi.c > index 70c4023..99f9afd 100644 > --- a/hw/pt-msi.c > +++ b/hw/pt-msi.c > @@ -67,12 +67,6 @@ int pt_msi_setup(struct pt_dev *dev) > int pirq = -1; > uint8_t gvec = 0; > > - if ( !(dev->msi->flags & MSI_FLAG_UNINIT) ) > - { > - PT_LOG("Error: setup physical after initialized?? \n"); > - return -1; > - } > - > gvec = dev->msi->data & 0xFF; > if (!gvec) { > /* if gvec is 0, the guest is asking for a particular pirq that The patch makes sense. Only one last comment, sorry for not having noticed this before, but there might be another (flags & MSI_FLAG_UNINIT) check that should probably be changed into msi_is_enable in pt_msi_disable. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:07:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:07:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMu-0007En-JJ; Fri, 11 May 2012 16:07:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMs-0007Ec-L6 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:06:58 +0000 Received: from [85.158.138.51:11526] by server-12.bemta-3.messagelabs.com id DD/00-29760-1293DAF4; Fri, 11 May 2012 16:06:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336752416!7941043!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17943 invoked from network); 11 May 2012 16:06:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:06:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434003" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:06:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:06:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsMq-0007gr-3H; Fri, 11 May 2012 16:06:56 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsMq-00021X-2O; Fri, 11 May 2012 17:06:56 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.14624.57140.518016@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:06:56 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335445762.28015.141.camel@zakaz.uk.xensource.com> References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-4-git-send-email-roger.pau@citrix.com> <20373.34767.584624.953798@mariner.uk.xensource.com> <4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com> <20377.18296.235567.918003@mariner.uk.xensource.com> <1335445762.28015.141.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Roger Pau Monne , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"): > On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote: > > I think we need to think about these timeouts. At the very least > > they're policy which should probably not be hardcoded in libxl; and > > arguably people might want to be able to specify infinite ("I trust my > > guest or driver domain and never want to pull the rug out from under > > its feet") or zero ("this guest or driver domain has gone wrong and I > > want it killed, now"). > > Unless the same is going to be true of the eventual solution (which I > suppose it may well be?) we should be wary of over engineering the > interim solution for 4.2. I guess. Also xend's poor behaviour in this area (failing hotplug timeouts) provides something of an excuse... > > Perhaps it would be better to do things the other way around, and have > > an env var for the case where we're _not_ calling the script from > > udev ? After all, udev config is configuration (at least on my > > distros) which the user may not update when the software is updated. > > It was my suggestion to do it this way so that we don't end up with a > vestigial env var which must always be set for no real reason after > we've removed the udev path altogether. When we have "removed the udev path altogether" we will still need to have something to prevent trouble if the udev rules remain for some reason. > I don't really mind though, we could live with that vestigial thing, or > have another, easier, transition a few releases down the line. The vestigial thing can indeed eventually go away. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:07:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:07:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMu-0007En-JJ; Fri, 11 May 2012 16:07:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsMs-0007Ec-L6 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:06:58 +0000 Received: from [85.158.138.51:11526] by server-12.bemta-3.messagelabs.com id DD/00-29760-1293DAF4; Fri, 11 May 2012 16:06:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336752416!7941043!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17943 invoked from network); 11 May 2012 16:06:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:06:57 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434003" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:06:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:06:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsMq-0007gr-3H; Fri, 11 May 2012 16:06:56 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsMq-00021X-2O; Fri, 11 May 2012 17:06:56 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.14624.57140.518016@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:06:56 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335445762.28015.141.camel@zakaz.uk.xensource.com> References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-4-git-send-email-roger.pau@citrix.com> <20373.34767.584624.953798@mariner.uk.xensource.com> <4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com> <20377.18296.235567.918003@mariner.uk.xensource.com> <1335445762.28015.141.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Roger Pau Monne , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"): > On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote: > > I think we need to think about these timeouts. At the very least > > they're policy which should probably not be hardcoded in libxl; and > > arguably people might want to be able to specify infinite ("I trust my > > guest or driver domain and never want to pull the rug out from under > > its feet") or zero ("this guest or driver domain has gone wrong and I > > want it killed, now"). > > Unless the same is going to be true of the eventual solution (which I > suppose it may well be?) we should be wary of over engineering the > interim solution for 4.2. I guess. Also xend's poor behaviour in this area (failing hotplug timeouts) provides something of an excuse... > > Perhaps it would be better to do things the other way around, and have > > an env var for the case where we're _not_ calling the script from > > udev ? After all, udev config is configuration (at least on my > > distros) which the user may not update when the software is updated. > > It was my suggestion to do it this way so that we don't end up with a > vestigial env var which must always be set for no real reason after > we've removed the udev path altogether. When we have "removed the udev path altogether" we will still need to have something to prevent trouble if the udev rules remain for some reason. > I don't really mind though, we could live with that vestigial thing, or > have another, easier, transition a few releases down the line. The vestigial thing can indeed eventually go away. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:10:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:10:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsQG-0007YM-JY; Fri, 11 May 2012 16:10:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsQE-0007YC-VR for xen-devel@lists.xen.org; Fri, 11 May 2012 16:10:27 +0000 Received: from [85.158.143.99:22398] by server-2.bemta-4.messagelabs.com id 20/7A-17550-2F93DAF4; Fri, 11 May 2012 16:10:26 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336752624!17955902!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30770 invoked from network); 11 May 2012 16:10:24 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:10:24 -0000 Received: by lbok6 with SMTP id k6so2510233lbo.32 for ; Fri, 11 May 2012 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AzJDr2xc8hITwOC9xBz9uBGowdLPdJBfiPPk6A8Bwr8=; b=VRcGAo4j0W31AMWa3Pt4qUgu2HZg7kBmYBC9z7DLzIo1KBKhKksmVmOuUmFYxdKq2d nqgf7qaFJtlQuUgrOyPes90FykT48J9/2/IsHyV4JId5VPjlTFLeSddZkxOV2flkK6wx +FNPBfjlPwjiCJ7laLCHZtAIEemCbzr2orAipU3abTuhPo36z3Kw4jDmqWvSHq62n3AC vfgTZkQxGKkA2z79U8hYWtPga68cvUeFjY3SK4JGcbOv2fGfe1Ol3M/sfXS4DXt217mB PQgyFa6cAxDWE09gXp0SRg9XCHZ+lJPlSjGgO3WSULxQz9vdcsFJ+b5CxnxHZ9JGBepy WKvg== MIME-Version: 1.0 Received: by 10.152.123.244 with SMTP id md20mr748306lab.0.1336752623774; Fri, 11 May 2012 09:10:23 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:10:23 -0700 (PDT) In-Reply-To: <1336751243.23818.106.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:10:23 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: Keir Fraser , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4245889692456929609==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4245889692456929609== Content-Type: multipart/alternative; boundary=f46d042f9cd84aedb404bfc4f923 --f46d042f9cd84aedb404bfc4f923 Content-Type: text/plain; charset=ISO-8859-1 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: > > > > 2012/5/11 Ian Campbell > > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > > When I do the "make install-tools" with xen-4.2-unstable, > > there are > > > some errors about "warn_unused_result". > > > Is it the error in code or the error in the compiling > > environment? > > > Thank you so much. > > > > > > This commit > > changeset: 25275:27d63b9f111a > > user: Keir Fraser > > date: Thu May 10 11:22:18 2012 +0100 > > summary: blktap2: Do not build with -O0 > > has caused more warnings to be generated by the compiler, > > which in turn > > leads to build failures. Since this is a compiler specific > > thing we are > > still tracking them all down. > > > > Can you confirm which versionof xen-unstable.hg you are using > > -- there > > have been several fixup patches since the above. If you are > > completely > > up to date and you still see errors we can dig into whatever > > is left. > > > > Thank you for your reply. I have used "hg pull; hg update" to update > > to the latest Xen and it is the version info: > > > > root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip > > changeset: 25287:54c8c9eaee92 > > tag: tip > > user: Dietmar Hahn > > date: Fri Apr 27 11:09:26 2012 +0200 > > summary: docs: add vpmu description to xen-command-line.markdown > > > > But, it still has the same errors. > > Thanks, looks like we still need to fix these errors then. > > I'm not really happy with the following, but it's no worse than things > are today... > > Bei, I don't see these build failures, does this work for you? > No, it doesn't work for me. There is the same error. My environment and gcc version are like this: root@gavin-desktop:~# uname -a Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 x86_64 GNU/Linux root@gavin-desktop:~# gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) Thanks, Bei Guan > > 8<------------------------------------------------------ > > # HG changeset patch > # User Ian Campbell > # Date 1336751175 -3600 > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > blktap: avoid attribute warn_unused_result build failures. > > I'm not proud of this, but since none of these callers of read/write have > any > other error handling and return void themselves (for several links up the > call > chain AFAICT) and because I don't really want to get into a massive > reworking > of blktap2 I suppose it is at least pragmatic > > Signed-off-by: Ian Campbell > > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:46:15 2012 > +0100 > @@ -247,7 +247,7 @@ tlog_flush(void) > wsize = ((size + 511) & (~511)); > > memset(tapdisk_log.buf + size, '\n', wsize - size); > - write(fd, tapdisk_log.buf, wsize); > + (void)write(fd, tapdisk_log.buf, wsize); > > tapdisk_log.p = tapdisk_log.buf; > > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:46:15 2012 > +0100 > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > uint64_t val; > > if (lio->flags & LIO_FLAG_EVENTFD) > - read(lio->event_fd, &val, sizeof(val)); > + (void)read(lio->event_fd, &val, sizeof(val)); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:46:15 2012 > +0100 > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > { > int dummy; > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > p->set = 0; > } > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > int dummy = 0; > > if (!p->set) { > - write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); > + (void)write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); > p->set = 1; > } > } > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > { > unsigned long idx = (unsigned long)tapdisk_stream_request_idx(s, > sreq); > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, idx, 0); > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > + (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 2012 +0100 > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > if (optind != argc) > usage(argv[0], EINVAL); > > - chdir("/"); > + if (chdir("/")) { > + DPRINTF("failed to chdir(/): %d\n", errno); > + err = 1; > + goto out; > + } > + > tapdisk_start_logging("tapdisk2"); > > err = tapdisk_server_init(); > > > -- Best Regards, Bei Guan --f46d042f9cd84aedb404bfc4f923 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/11 Ian Campbell <Ian.Campb= ell@citrix.com>
On Fri, 2012-05-11 at 16:12 +0100, = Bei Guan wrote:
>
> 2012/5/11 Ian Campbell <= Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote:
> =A0 =A0 =A0 =A0 > When I do the "make install-tools" with= xen-4.2-unstable,
> =A0 =A0 =A0 =A0 there are
> =A0 =A0 =A0 =A0 > some errors about "warn_unused_result".=
> =A0 =A0 =A0 =A0 > Is it the error in code or the error in the compi= ling
> =A0 =A0 =A0 =A0 environment?
> =A0 =A0 =A0 =A0 > Thank you so much.
>
>
> =A0 =A0 =A0 =A0 This commit
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0changeset: =A0 25275:27d63b9f111a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0user: =A0 =A0 =A0 =A0Keir Fraser <keir@xen.org>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0date: =A0 =A0 =A0 =A0Thu May 10 11:22:1= 8 2012 +0100
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0summary: =A0 =A0 blktap2: Do not build = with -O0
> =A0 =A0 =A0 =A0 has caused more warnings to be generated by the compil= er,
> =A0 =A0 =A0 =A0 which in turn
> =A0 =A0 =A0 =A0 leads to build failures. Since this is a compiler spec= ific
> =A0 =A0 =A0 =A0 thing we are
> =A0 =A0 =A0 =A0 still tracking them all down.
>
> =A0 =A0 =A0 =A0 Can you confirm which versionof xen-unstable.hg you ar= e using
> =A0 =A0 =A0 =A0 -- there
> =A0 =A0 =A0 =A0 have been several fixup patches since the above. If yo= u are
> =A0 =A0 =A0 =A0 completely
> =A0 =A0 =A0 =A0 up to date and you still see errors we can dig into wh= atever
> =A0 =A0 =A0 =A0 is left.
>
> Thank you for your reply. I have used "hg pull; hg update" t= o update
> to the latest Xen and it is the version info:
>
> root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip
> changeset: =A0 25287:54c8c9eaee92
> tag: =A0 =A0 =A0 =A0 tip
> user: =A0 =A0 =A0 =A0Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> date: =A0 =A0 =A0 =A0Fri Apr 27 11:09:26 2012 +0200
> summary: =A0 =A0 docs: add vpmu description to xen-command-line.markdo= wn
>
> But, it still has the same errors.

Thanks, looks like we still need to fix these errors then.

I'm not really happy with the following, but it's no worse than thi= ngs
are today...

Bei, I don't see these build failures, does this work for you?

No, it doesn't work for me. There is the same error.My environment and gcc version are like this:

root@gavin-desktop:~= # uname -a
Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 = x86_64 GNU/Linux

root@gavin-desktop:~# gcc -v
Using built-in spec= s.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --wi= th-pkgversion=3D'Ubuntu 4.4.3-4ubuntu5' --with-bugurl=3Dfile:///usr= /share/doc/gcc-4.4/README.Bugs --enable-languages=3Dc,c++,fortran,objc,obj-= c++ --prefix=3D/usr --enable-shared --enable-multiarch --enable-linker-buil= d-id --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext = --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4 --pr= ogram-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu --enable-libstdcxx-= debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=3Di4= 86 --with-tune=3Dgeneric --enable-checking=3Drelease --build=3Dx86_64-linux= -gnu --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)



Thanks,
Bei Guan



=A0

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.camp= bell@citrix.com>
# Date 1336751175 -3600
# Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99
# Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999
blktap: avoid attribute warn_unused_result build failures.

I'm not proud of this, but since none of these callers of read/write ha= ve any
other error handling and return void themselves (for several links up the c= all
chain AFAICT) and because I don't really want to get into a massive rew= orking
of blktap2 I suppose it is at least pragmatic

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

diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:19:16 2= 012 +0100
+++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:46:15 2= 012 +0100
@@ -247,7 +247,7 @@ tlog_flush(void)
=A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511));

=A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsize - size);=
- =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize);
+ =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize);

=A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;

diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c<= br> --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:19:16 201= 2 +0100
+++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:46:15 201= 2 +0100
@@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que
=A0 =A0 =A0 =A0uint64_t val;

=A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val, sizeof(val))= ;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd, &val, sizeof= (val));
=A0}

=A0static void
diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c=
--- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:19:16 201= 2 +0100
+++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:46:15 201= 2 +0100
@@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk
=A0{
=A0 =A0 =A0 =A0int dummy;

- =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(dummy));
+ =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy));=
=A0 =A0 =A0 =A0p->set =3D 0;
=A0}

@@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s
=A0 =A0 =A0 =A0int dummy =3D 0;

=A0 =A0 =A0 =A0if (!p->set) {
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE], &dummy, siz= eof(dummy));
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_WRITE], &dumm= y, sizeof(dummy));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1;
=A0 =A0 =A0 =A0}
=A0}
@@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd
=A0{
=A0 =A0 =A0 =A0unsigned long idx =3D (unsigned long)tapdisk_stream_request= _idx(s, sreq);
=A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd->ring.vstart,= idx, 0);
- =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT)= ;
+ =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << SECTOR_= SHIFT);
=A0}

=A0static void
diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c
--- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:46:15 2012 +0100 @@ -79,7 +79,12 @@ main(int argc, char *argv[])
=A0 =A0 =A0 =A0if (optind !=3D argc)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL);

- =A0 =A0 =A0 chdir("/");
+ =A0 =A0 =A0 if (chdir("/")) {
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(/): %d\n",= errno);
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
+ =A0 =A0 =A0 }
+
=A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2");

=A0 =A0 =A0 =A0err =3D tapdisk_server_init();





--
Best Regards,
Bei G= uan

--f46d042f9cd84aedb404bfc4f923-- --===============4245889692456929609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4245889692456929609==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:10:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:10:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsQG-0007YM-JY; Fri, 11 May 2012 16:10:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsQE-0007YC-VR for xen-devel@lists.xen.org; Fri, 11 May 2012 16:10:27 +0000 Received: from [85.158.143.99:22398] by server-2.bemta-4.messagelabs.com id 20/7A-17550-2F93DAF4; Fri, 11 May 2012 16:10:26 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1336752624!17955902!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30770 invoked from network); 11 May 2012 16:10:24 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:10:24 -0000 Received: by lbok6 with SMTP id k6so2510233lbo.32 for ; Fri, 11 May 2012 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AzJDr2xc8hITwOC9xBz9uBGowdLPdJBfiPPk6A8Bwr8=; b=VRcGAo4j0W31AMWa3Pt4qUgu2HZg7kBmYBC9z7DLzIo1KBKhKksmVmOuUmFYxdKq2d nqgf7qaFJtlQuUgrOyPes90FykT48J9/2/IsHyV4JId5VPjlTFLeSddZkxOV2flkK6wx +FNPBfjlPwjiCJ7laLCHZtAIEemCbzr2orAipU3abTuhPo36z3Kw4jDmqWvSHq62n3AC vfgTZkQxGKkA2z79U8hYWtPga68cvUeFjY3SK4JGcbOv2fGfe1Ol3M/sfXS4DXt217mB PQgyFa6cAxDWE09gXp0SRg9XCHZ+lJPlSjGgO3WSULxQz9vdcsFJ+b5CxnxHZ9JGBepy WKvg== MIME-Version: 1.0 Received: by 10.152.123.244 with SMTP id md20mr748306lab.0.1336752623774; Fri, 11 May 2012 09:10:23 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:10:23 -0700 (PDT) In-Reply-To: <1336751243.23818.106.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:10:23 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: Keir Fraser , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4245889692456929609==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4245889692456929609== Content-Type: multipart/alternative; boundary=f46d042f9cd84aedb404bfc4f923 --f46d042f9cd84aedb404bfc4f923 Content-Type: text/plain; charset=ISO-8859-1 2012/5/11 Ian Campbell > On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: > > > > 2012/5/11 Ian Campbell > > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > > > When I do the "make install-tools" with xen-4.2-unstable, > > there are > > > some errors about "warn_unused_result". > > > Is it the error in code or the error in the compiling > > environment? > > > Thank you so much. > > > > > > This commit > > changeset: 25275:27d63b9f111a > > user: Keir Fraser > > date: Thu May 10 11:22:18 2012 +0100 > > summary: blktap2: Do not build with -O0 > > has caused more warnings to be generated by the compiler, > > which in turn > > leads to build failures. Since this is a compiler specific > > thing we are > > still tracking them all down. > > > > Can you confirm which versionof xen-unstable.hg you are using > > -- there > > have been several fixup patches since the above. If you are > > completely > > up to date and you still see errors we can dig into whatever > > is left. > > > > Thank you for your reply. I have used "hg pull; hg update" to update > > to the latest Xen and it is the version info: > > > > root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip > > changeset: 25287:54c8c9eaee92 > > tag: tip > > user: Dietmar Hahn > > date: Fri Apr 27 11:09:26 2012 +0200 > > summary: docs: add vpmu description to xen-command-line.markdown > > > > But, it still has the same errors. > > Thanks, looks like we still need to fix these errors then. > > I'm not really happy with the following, but it's no worse than things > are today... > > Bei, I don't see these build failures, does this work for you? > No, it doesn't work for me. There is the same error. My environment and gcc version are like this: root@gavin-desktop:~# uname -a Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 x86_64 GNU/Linux root@gavin-desktop:~# gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) Thanks, Bei Guan > > 8<------------------------------------------------------ > > # HG changeset patch > # User Ian Campbell > # Date 1336751175 -3600 > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > blktap: avoid attribute warn_unused_result build failures. > > I'm not proud of this, but since none of these callers of read/write have > any > other error handling and return void themselves (for several links up the > call > chain AFAICT) and because I don't really want to get into a massive > reworking > of blktap2 I suppose it is at least pragmatic > > Signed-off-by: Ian Campbell > > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 16:46:15 2012 > +0100 > @@ -247,7 +247,7 @@ tlog_flush(void) > wsize = ((size + 511) & (~511)); > > memset(tapdisk_log.buf + size, '\n', wsize - size); > - write(fd, tapdisk_log.buf, wsize); > + (void)write(fd, tapdisk_log.buf, wsize); > > tapdisk_log.p = tapdisk_log.buf; > > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 16:46:15 2012 > +0100 > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > uint64_t val; > > if (lio->flags & LIO_FLAG_EVENTFD) > - read(lio->event_fd, &val, sizeof(val)); > + (void)read(lio->event_fd, &val, sizeof(val)); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:19:16 2012 > +0100 > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 16:46:15 2012 > +0100 > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > { > int dummy; > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > p->set = 0; > } > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > int dummy = 0; > > if (!p->set) { > - write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); > + (void)write(p->pipe[POLL_WRITE], &dummy, sizeof(dummy)); > p->set = 1; > } > } > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > { > unsigned long idx = (unsigned long)tapdisk_stream_request_idx(s, > sreq); > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, idx, 0); > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > + (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 2012 +0100 > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > if (optind != argc) > usage(argv[0], EINVAL); > > - chdir("/"); > + if (chdir("/")) { > + DPRINTF("failed to chdir(/): %d\n", errno); > + err = 1; > + goto out; > + } > + > tapdisk_start_logging("tapdisk2"); > > err = tapdisk_server_init(); > > > -- Best Regards, Bei Guan --f46d042f9cd84aedb404bfc4f923 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/11 Ian Campbell <Ian.Campb= ell@citrix.com>
On Fri, 2012-05-11 at 16:12 +0100, = Bei Guan wrote:
>
> 2012/5/11 Ian Campbell <= Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote:
> =A0 =A0 =A0 =A0 > When I do the "make install-tools" with= xen-4.2-unstable,
> =A0 =A0 =A0 =A0 there are
> =A0 =A0 =A0 =A0 > some errors about "warn_unused_result".=
> =A0 =A0 =A0 =A0 > Is it the error in code or the error in the compi= ling
> =A0 =A0 =A0 =A0 environment?
> =A0 =A0 =A0 =A0 > Thank you so much.
>
>
> =A0 =A0 =A0 =A0 This commit
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0changeset: =A0 25275:27d63b9f111a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0user: =A0 =A0 =A0 =A0Keir Fraser <keir@xen.org>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0date: =A0 =A0 =A0 =A0Thu May 10 11:22:1= 8 2012 +0100
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0summary: =A0 =A0 blktap2: Do not build = with -O0
> =A0 =A0 =A0 =A0 has caused more warnings to be generated by the compil= er,
> =A0 =A0 =A0 =A0 which in turn
> =A0 =A0 =A0 =A0 leads to build failures. Since this is a compiler spec= ific
> =A0 =A0 =A0 =A0 thing we are
> =A0 =A0 =A0 =A0 still tracking them all down.
>
> =A0 =A0 =A0 =A0 Can you confirm which versionof xen-unstable.hg you ar= e using
> =A0 =A0 =A0 =A0 -- there
> =A0 =A0 =A0 =A0 have been several fixup patches since the above. If yo= u are
> =A0 =A0 =A0 =A0 completely
> =A0 =A0 =A0 =A0 up to date and you still see errors we can dig into wh= atever
> =A0 =A0 =A0 =A0 is left.
>
> Thank you for your reply. I have used "hg pull; hg update" t= o update
> to the latest Xen and it is the version info:
>
> root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip
> changeset: =A0 25287:54c8c9eaee92
> tag: =A0 =A0 =A0 =A0 tip
> user: =A0 =A0 =A0 =A0Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> date: =A0 =A0 =A0 =A0Fri Apr 27 11:09:26 2012 +0200
> summary: =A0 =A0 docs: add vpmu description to xen-command-line.markdo= wn
>
> But, it still has the same errors.

Thanks, looks like we still need to fix these errors then.

I'm not really happy with the following, but it's no worse than thi= ngs
are today...

Bei, I don't see these build failures, does this work for you?

No, it doesn't work for me. There is the same error.My environment and gcc version are like this:

root@gavin-desktop:~= # uname -a
Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 = x86_64 GNU/Linux

root@gavin-desktop:~# gcc -v
Using built-in spec= s.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --wi= th-pkgversion=3D'Ubuntu 4.4.3-4ubuntu5' --with-bugurl=3Dfile:///usr= /share/doc/gcc-4.4/README.Bugs --enable-languages=3Dc,c++,fortran,objc,obj-= c++ --prefix=3D/usr --enable-shared --enable-multiarch --enable-linker-buil= d-id --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext = --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4 --pr= ogram-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu --enable-libstdcxx-= debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=3Di4= 86 --with-tune=3Dgeneric --enable-checking=3Drelease --build=3Dx86_64-linux= -gnu --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)



Thanks,
Bei Guan



=A0

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.camp= bell@citrix.com>
# Date 1336751175 -3600
# Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99
# Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999
blktap: avoid attribute warn_unused_result build failures.

I'm not proud of this, but since none of these callers of read/write ha= ve any
other error handling and return void themselves (for several links up the c= all
chain AFAICT) and because I don't really want to get into a massive rew= orking
of blktap2 I suppose it is at least pragmatic

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

diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:19:16 2= 012 +0100
+++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:46:15 2= 012 +0100
@@ -247,7 +247,7 @@ tlog_flush(void)
=A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511));

=A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsize - size);=
- =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize);
+ =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize);

=A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;

diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue.c<= br> --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:19:16 201= 2 +0100
+++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:46:15 201= 2 +0100
@@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que
=A0 =A0 =A0 =A0uint64_t val;

=A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val, sizeof(val))= ;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd, &val, sizeof= (val));
=A0}

=A0static void
diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-stream.c=
--- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:19:16 201= 2 +0100
+++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:46:15 201= 2 +0100
@@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk
=A0{
=A0 =A0 =A0 =A0int dummy;

- =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(dummy));
+ =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy));=
=A0 =A0 =A0 =A0p->set =3D 0;
=A0}

@@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s
=A0 =A0 =A0 =A0int dummy =3D 0;

=A0 =A0 =A0 =A0if (!p->set) {
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE], &dummy, siz= eof(dummy));
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_WRITE], &dumm= y, sizeof(dummy));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1;
=A0 =A0 =A0 =A0}
=A0}
@@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd
=A0{
=A0 =A0 =A0 =A0unsigned long idx =3D (unsigned long)tapdisk_stream_request= _idx(s, sreq);
=A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd->ring.vstart,= idx, 0);
- =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT)= ;
+ =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << SECTOR_= SHIFT);
=A0}

=A0static void
diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c
--- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:19:16 2012 +0100 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:46:15 2012 +0100 @@ -79,7 +79,12 @@ main(int argc, char *argv[])
=A0 =A0 =A0 =A0if (optind !=3D argc)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL);

- =A0 =A0 =A0 chdir("/");
+ =A0 =A0 =A0 if (chdir("/")) {
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(/): %d\n",= errno);
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
+ =A0 =A0 =A0 }
+
=A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2");

=A0 =A0 =A0 =A0err =3D tapdisk_server_init();





--
Best Regards,
Bei G= uan

--f46d042f9cd84aedb404bfc4f923-- --===============4245889692456929609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4245889692456929609==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:14:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSsTf-0007kC-LW; Fri, 11 May 2012 16:13:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsTd-0007je-QX for xen-devel@lists.xen.org; Fri, 11 May 2012 16:13:58 +0000 Received: from [85.158.143.35:48232] by server-2.bemta-4.messagelabs.com id 70/DD-17550-4CA3DAF4; Fri, 11 May 2012 16:13:56 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336752832!10563182!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4847 invoked from network); 11 May 2012 16:13:54 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:13:54 -0000 Received: by pbbro12 with SMTP id ro12so3787351pbb.32 for ; Fri, 11 May 2012 09:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=vTbLHOhv1i9awkAIRL+0QbrHWLID/cqWpw8Kz5CfoJk=; b=bKdVF2TTemt3EQrFEuSGZGBhM7O9sVdKyeO44ar1ZbrixDUpUGJ9rvIVcA85RTb2lG hVdMU+jiVxF7p7WvOzdf9E9P5jEngpNlqxC/WYGRTH9UnYDnvufRecgsPnqtimX3Rio/ 3LmK8r4zkREqifeoPo3Md8pIlNuljQCmM2/egCn9MRGqdCYyZzDXn/c0/gj3l3YntiaZ e9wm+TBXN7T7EFneUy2l9W9hlku+uMqR6Y+RtQIvjQBJptY7jnv7ALJTJEZtKXZCd/5/ 257E4Z8M+QbF32p3vAvzwhDX3MhmRzeUYu0mXJcFcwftBwzU6N5DLt7hSDJkhUpST981 F9Gw== Received: by 10.68.221.98 with SMTP id qd2mr14030235pbc.3.1336752832178; Fri, 11 May 2012 09:13:52 -0700 (PDT) Received: from [172.16.25.10] ([206.15.84.247]) by mx.google.com with ESMTPS id pb4sm13196971pbc.55.2012.05.11.09.13.49 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:13:50 -0700 (PDT) Message-ID: <4FAD3ABC.7070905@xen.org> Date: Fri, 11 May 2012 09:13:48 -0700 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: lars.kurth@xen.org References: <4FA2B2B1.3040901@xen.org> In-Reply-To: <4FA2B2B1.3040901@xen.org> Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-announce@lists.xen.org, xen-devel@lists.xen.org Subject: [Xen-devel] [Vote] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4244378782723293960==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4244378782723293960== Content-Type: multipart/alternative; boundary="------------020301020001070906070506" This is a multi-part message in MIME format. --------------020301020001070906070506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, dear was no controversial feedback on the proposal to change http://xen.org/projects/governance.html The proposal can be viewed at: http://xen.org/projects/governance_v1_2.html Community Manager, Maintainers, Committers and Project leads of mature projects can vote according to http://xen.org/projects/governance.html). Voting works as follows: +1: for proposal 0: abstain -1: against proposal - must contain an alternative suggestion to the proposal or an explanation to be valid The vote is open until May 18th (for 1 week). Regards Lars On 03/05/2012 09:30, Lars Kurth wrote: > Dear Developers, > > we have had the original Xen project governance document (see > http://xen.org/projects/governance.html > ) in effect now since > July last year. The last minor review was in October 2011. > > Since then I had feedback on two items: > > a) Our governance does not specify how friction in the community is > resolved. The role definitions cover the concept of Committers and > Project leads acting as Referees, without being specific. In essence, > the proposal reflects what happens informally in practice today and > has happened in the past. > > b) There also was a bug in the definition of Project Lead: "Xen.org > projects are managed by a Project Lead, who also is a maintainer" > should be "..., who also is a committer". I clarified this and added a > sentence that a project lead can also act as referee (which was > implied before as a project lead is a committer). > > Please find a proposal for a new revision of the process at > http://xen.org/projects/governance_v1_2.html which fixes these two > issues. Changes are marked in italics and are in sections "Conflict > Resolution" and "Project Lead". > > Timetable: > > 1) Open review with feedback until 11th May (a bit more than a week > from today) > > 2) Lars to incorporate any feedback and publish a revision. > > 3) Lars to set up a private poll via a form, the week of May 14th > which will be open for a week. Community members that can vote are > maintainers (including committers and maintainers)of any mature > project in Xen (aka Xen and XCP). > > Best Regards > Lars > --------------020301020001070906070506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

dear was no controversial feedback on the proposal to change http://xen.org/projects/governance.html

The proposal can be viewed at: http://xen.org/projects/governance_v1_2.html

Community Manager, Maintainers, Committers and Project leads of mature projects can vote according to http://xen.org/projects/governance.html).

Voting works as follows:
+1: for proposal
0: abstain
-1: against proposal - must contain an alternative suggestion to the proposal or an explanation to be valid

The vote is open until May 18th (for 1 week).

Regards
Lars

On 03/05/2012 09:30, Lars Kurth wrote:
Dear Developers,

we have had the original Xen project governance document (see http://xen.org/projects/governance.html <http://www.xen.org/projects/governance.html>) in effect now since July last year. The last minor review was in October 2011.

Since then I had feedback on two items:

a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past.

b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer).

Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead".

Timetable:

1) Open review with feedback until 11th May (a bit more than a week from today)

2) Lars to incorporate any feedback and publish a revision.

3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP).

Best Regards
Lars


--------------020301020001070906070506-- --===============4244378782723293960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4244378782723293960==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:14:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSsTf-0007kC-LW; Fri, 11 May 2012 16:13:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsTd-0007je-QX for xen-devel@lists.xen.org; Fri, 11 May 2012 16:13:58 +0000 Received: from [85.158.143.35:48232] by server-2.bemta-4.messagelabs.com id 70/DD-17550-4CA3DAF4; Fri, 11 May 2012 16:13:56 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1336752832!10563182!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4847 invoked from network); 11 May 2012 16:13:54 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:13:54 -0000 Received: by pbbro12 with SMTP id ro12so3787351pbb.32 for ; Fri, 11 May 2012 09:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=vTbLHOhv1i9awkAIRL+0QbrHWLID/cqWpw8Kz5CfoJk=; b=bKdVF2TTemt3EQrFEuSGZGBhM7O9sVdKyeO44ar1ZbrixDUpUGJ9rvIVcA85RTb2lG hVdMU+jiVxF7p7WvOzdf9E9P5jEngpNlqxC/WYGRTH9UnYDnvufRecgsPnqtimX3Rio/ 3LmK8r4zkREqifeoPo3Md8pIlNuljQCmM2/egCn9MRGqdCYyZzDXn/c0/gj3l3YntiaZ e9wm+TBXN7T7EFneUy2l9W9hlku+uMqR6Y+RtQIvjQBJptY7jnv7ALJTJEZtKXZCd/5/ 257E4Z8M+QbF32p3vAvzwhDX3MhmRzeUYu0mXJcFcwftBwzU6N5DLt7hSDJkhUpST981 F9Gw== Received: by 10.68.221.98 with SMTP id qd2mr14030235pbc.3.1336752832178; Fri, 11 May 2012 09:13:52 -0700 (PDT) Received: from [172.16.25.10] ([206.15.84.247]) by mx.google.com with ESMTPS id pb4sm13196971pbc.55.2012.05.11.09.13.49 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:13:50 -0700 (PDT) Message-ID: <4FAD3ABC.7070905@xen.org> Date: Fri, 11 May 2012 09:13:48 -0700 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: lars.kurth@xen.org References: <4FA2B2B1.3040901@xen.org> In-Reply-To: <4FA2B2B1.3040901@xen.org> Cc: xen-arm@lists.xen.org, xen-api@lists.xen.org, xen-announce@lists.xen.org, xen-devel@lists.xen.org Subject: [Xen-devel] [Vote] Minor additions and clarification to Xen Project Governance X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4244378782723293960==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4244378782723293960== Content-Type: multipart/alternative; boundary="------------020301020001070906070506" This is a multi-part message in MIME format. --------------020301020001070906070506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, dear was no controversial feedback on the proposal to change http://xen.org/projects/governance.html The proposal can be viewed at: http://xen.org/projects/governance_v1_2.html Community Manager, Maintainers, Committers and Project leads of mature projects can vote according to http://xen.org/projects/governance.html). Voting works as follows: +1: for proposal 0: abstain -1: against proposal - must contain an alternative suggestion to the proposal or an explanation to be valid The vote is open until May 18th (for 1 week). Regards Lars On 03/05/2012 09:30, Lars Kurth wrote: > Dear Developers, > > we have had the original Xen project governance document (see > http://xen.org/projects/governance.html > ) in effect now since > July last year. The last minor review was in October 2011. > > Since then I had feedback on two items: > > a) Our governance does not specify how friction in the community is > resolved. The role definitions cover the concept of Committers and > Project leads acting as Referees, without being specific. In essence, > the proposal reflects what happens informally in practice today and > has happened in the past. > > b) There also was a bug in the definition of Project Lead: "Xen.org > projects are managed by a Project Lead, who also is a maintainer" > should be "..., who also is a committer". I clarified this and added a > sentence that a project lead can also act as referee (which was > implied before as a project lead is a committer). > > Please find a proposal for a new revision of the process at > http://xen.org/projects/governance_v1_2.html which fixes these two > issues. Changes are marked in italics and are in sections "Conflict > Resolution" and "Project Lead". > > Timetable: > > 1) Open review with feedback until 11th May (a bit more than a week > from today) > > 2) Lars to incorporate any feedback and publish a revision. > > 3) Lars to set up a private poll via a form, the week of May 14th > which will be open for a week. Community members that can vote are > maintainers (including committers and maintainers)of any mature > project in Xen (aka Xen and XCP). > > Best Regards > Lars > --------------020301020001070906070506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

dear was no controversial feedback on the proposal to change http://xen.org/projects/governance.html

The proposal can be viewed at: http://xen.org/projects/governance_v1_2.html

Community Manager, Maintainers, Committers and Project leads of mature projects can vote according to http://xen.org/projects/governance.html).

Voting works as follows:
+1: for proposal
0: abstain
-1: against proposal - must contain an alternative suggestion to the proposal or an explanation to be valid

The vote is open until May 18th (for 1 week).

Regards
Lars

On 03/05/2012 09:30, Lars Kurth wrote:
Dear Developers,

we have had the original Xen project governance document (see http://xen.org/projects/governance.html <http://www.xen.org/projects/governance.html>) in effect now since July last year. The last minor review was in October 2011.

Since then I had feedback on two items:

a) Our governance does not specify how friction in the community is resolved. The role definitions cover the concept of Committers and Project leads acting as Referees, without being specific. In essence, the proposal reflects what happens informally in practice today and has happened in the past.

b) There also was a bug in the definition of Project Lead: "Xen.org projects are managed by a Project Lead, who also is a maintainer" should be "..., who also is a committer". I clarified this and added a sentence that a project lead can also act as referee (which was implied before as a project lead is a committer).

Please find a proposal for a new revision of the process at http://xen.org/projects/governance_v1_2.html which fixes these two issues. Changes are marked in italics and are in sections "Conflict Resolution" and "Project Lead".

Timetable:

1) Open review with feedback until 11th May (a bit more than a week from today)

2) Lars to incorporate any feedback and publish a revision.

3) Lars to set up a private poll via a form, the week of May 14th which will be open for a week. Community members that can vote are maintainers (including committers and maintainers)of any mature project in Xen (aka Xen and XCP).

Best Regards
Lars


--------------020301020001070906070506-- --===============4244378782723293960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4244378782723293960==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:16:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsW0-0007w3-Tw; Fri, 11 May 2012 16:16:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsW0-0007vq-21 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:16:24 +0000 Received: from [193.109.254.147:3221] by server-10.bemta-14.messagelabs.com id 7A/DD-05847-75B3DAF4; Fri, 11 May 2012 16:16:23 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336752982!8851599!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27392 invoked from network); 11 May 2012 16:16:22 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:16:22 -0000 Received: by eaak12 with SMTP id k12so1166668eaa.32 for ; Fri, 11 May 2012 09:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=J6P+Wv9UTYAai2zF+9jVcbfOWYgHpcNlGgdoFJb6Uzw=; b=pSnU/Mf04nbSRn9jk+lLjhHkv2bk4GaxawBGNft4EOctgmUyBQVo1x3ddkMv5BzRrh MoGvgIO0bhyKgRQmOWMtyBeYb90NmvpZRnB8z5wa/3UYxQM8X0gXCSqH0hGP/krDyaAi Pr9QGfN/+zzgpSXA1tERopGzWlQj5Zs0VmcPTijsVo8TFWMn064Ufz5amu1Lt0eTiwBV NMMzhE/kw22+lV/C9iFWNpjL1mCVbnqazUd8cFbapWQraunTYWbCuxiWSltwnL/k+bbY lqa3s9cjZpJzu+YJrFAQPckTdG1M2Vi403m57XULZqJInby1vBsJxfq1Aqa3SPqd0yaO 75wA== Received: by 10.213.156.66 with SMTP id v2mr2637879ebw.115.1336752982099; Fri, 11 May 2012 09:16:22 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm47225614eea.3.2012.05.11.09.16.19 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:16:21 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:16:14 +0100 From: Keir Fraser To: Ian Campbell , Bei Guan Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vkWLr9sU75xEjoE2K1ucxfuzOew== In-Reply-To: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 15:16, "Ian Campbell" wrote: > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > When I do the "make > install-tools" with xen-4.2-unstable, there are > some errors about > "warn_unused_result". > Is it the error in code or the error in the compiling > environment? > Thank you so much. This commit changeset: > 25275:27d63b9f111a user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 summary: blktap2: Do > not build with -O0 has caused more warnings to be generated by the compiler, > which in turn leads to build failures. Since this is a compiler specific thing > we are still tracking them all down. Can you confirm which versionof > xen-unstable.hg you are using -- there have been several fixup patches since > the above. If you are completely up to date and you still see errors we can > dig into whatever is left. Ian. (starting to think that this change wasn't > suitable during a feature freeze....) The original reason for making this fix now was build failure on Fedora 17, due to -O0 implying -D_FORTIFY_SOURCE=3D2, and some kind of fall-out from that. A simpler feature-freeze fix might be to simply disable -Werror for subtrees that are using -O0. Since this needs backport for 4.0 and 4.1 as well. Or perhaps we are nearly at the end of the bug tail. ;-) -- Keir > = > = > gcc -O1 = > -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing > -std=3Dgnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement > -D__XEN_TOOLS__ -MMD -MF > .tapdisk-queue.o.d -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE > -fno-optimize-sibling-calls -Werror -g > -Wno-unused -fno-strict-aliasing > -I../include -I../drivers > > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include > -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c -c > -o tapdisk-queue.o tapdisk-queue.c = > cc1: warnings being treated as errors > > tapdisk-queue.c: In function =8Ctapdisk_lio_ack_event=B9: > tapdisk-queue.c:438: > error: ignoring return value of =8Cread=B9, declared > with attribute > warn_unused_result > make[5]: *** [tapdisk-queue.o] Error 1 > make[5]: Leaving > directory > `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' > make[4]: *** > [subdir-install-drivers] Error 2 > make[4]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools/blktap2' > make[3]: *** [subdirs-install] > Error 2 > make[3]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools/blktap2' > make[2]: *** > [subdir-install-blktap2] Error 2 > make[2]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools' > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > make: *** > [install-tools] Error 2 > ------ > > root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src= -c > -o tapdisk-log.o tapdisk-log.c = > cc1: warnings being treated as errors > > tapdisk-log.c: In function =8Ctlog_flush=B9: > tapdisk-log.c:250: error: ignoring > return value of =8Cwrite=B9, declared > with attribute warn_unused_result > > ------ > = > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c -c > -o tapdisk2.o tapdisk2.c = > cc1: warnings being treated as errors > > tapdisk2.c: In function =8Cmain=B9: > tapdisk2.c:82: error: ignoring return value > of =8Cchdir=B9, declared with > attribute warn_unused_result > ------ > cc1: > warnings being treated as errors > tapdisk-stream.c: In function > =8Ctapdisk_stream_poll_clear=B9: > tapdisk-stream.c:148: error: ignoring return > value of =8Cread=B9, declared > with attribute warn_unused_result > > tapdisk-stream.c: In function =8Ctapdisk_stream_poll_set=B9: > > tapdisk-stream.c:158: error: ignoring return value of =8Cwrite=B9, > declared with > attribute warn_unused_result > tapdisk-stream.c: In function > =8Ctapdisk_stream_print_request=B9: > tapdisk-stream.c:206: error: ignoring return > value of =8Cwrite=B9, > declared with attribute warn_unused_result > = > = > = > Best > Regards, > Bei Guan > > = _______________________________________________ Xen-devel mailing > list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:16:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsW0-0007w3-Tw; Fri, 11 May 2012 16:16:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsW0-0007vq-21 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:16:24 +0000 Received: from [193.109.254.147:3221] by server-10.bemta-14.messagelabs.com id 7A/DD-05847-75B3DAF4; Fri, 11 May 2012 16:16:23 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336752982!8851599!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27392 invoked from network); 11 May 2012 16:16:22 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:16:22 -0000 Received: by eaak12 with SMTP id k12so1166668eaa.32 for ; Fri, 11 May 2012 09:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=J6P+Wv9UTYAai2zF+9jVcbfOWYgHpcNlGgdoFJb6Uzw=; b=pSnU/Mf04nbSRn9jk+lLjhHkv2bk4GaxawBGNft4EOctgmUyBQVo1x3ddkMv5BzRrh MoGvgIO0bhyKgRQmOWMtyBeYb90NmvpZRnB8z5wa/3UYxQM8X0gXCSqH0hGP/krDyaAi Pr9QGfN/+zzgpSXA1tERopGzWlQj5Zs0VmcPTijsVo8TFWMn064Ufz5amu1Lt0eTiwBV NMMzhE/kw22+lV/C9iFWNpjL1mCVbnqazUd8cFbapWQraunTYWbCuxiWSltwnL/k+bbY lqa3s9cjZpJzu+YJrFAQPckTdG1M2Vi403m57XULZqJInby1vBsJxfq1Aqa3SPqd0yaO 75wA== Received: by 10.213.156.66 with SMTP id v2mr2637879ebw.115.1336752982099; Fri, 11 May 2012 09:16:22 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y53sm47225614eea.3.2012.05.11.09.16.19 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:16:21 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:16:14 +0100 From: Keir Fraser To: Ian Campbell , Bei Guan Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vkWLr9sU75xEjoE2K1ucxfuzOew== In-Reply-To: <1336745780.23818.80.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 15:16, "Ian Campbell" wrote: > On Fri, 2012-05-11 at 15:08 +0100, Bei Guan wrote: > When I do the "make > install-tools" with xen-4.2-unstable, there are > some errors about > "warn_unused_result". > Is it the error in code or the error in the compiling > environment? > Thank you so much. This commit changeset: > 25275:27d63b9f111a user: Keir Fraser > date: Thu May 10 11:22:18 2012 +0100 summary: blktap2: Do > not build with -O0 has caused more warnings to be generated by the compiler, > which in turn leads to build failures. Since this is a compiler specific thing > we are still tracking them all down. Can you confirm which versionof > xen-unstable.hg you are using -- there have been several fixup patches since > the above. If you are completely up to date and you still see errors we can > dig into whatever is left. Ian. (starting to think that this change wasn't > suitable during a feature freeze....) The original reason for making this fix now was build failure on Fedora 17, due to -O0 implying -D_FORTIFY_SOURCE=3D2, and some kind of fall-out from that. A simpler feature-freeze fix might be to simply disable -Werror for subtrees that are using -O0. Since this needs backport for 4.0 and 4.1 as well. Or perhaps we are nearly at the end of the bug tail. ;-) -- Keir > = > = > gcc -O1 = > -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing > -std=3Dgnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement > -D__XEN_TOOLS__ -MMD -MF > .tapdisk-queue.o.d -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE > -fno-optimize-sibling-calls -Werror -g > -Wno-unused -fno-strict-aliasing > -I../include -I../drivers > > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libxc > -I/root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/include > -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -I > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c -c > -o tapdisk-queue.o tapdisk-queue.c = > cc1: warnings being treated as errors > > tapdisk-queue.c: In function =8Ctapdisk_lio_ack_event=B9: > tapdisk-queue.c:438: > error: ignoring return value of =8Cread=B9, declared > with attribute > warn_unused_result > make[5]: *** [tapdisk-queue.o] Error 1 > make[5]: Leaving > directory > `/root/Xen/xen-4.2-unstable/tools/blktap2/drivers' > make[4]: *** > [subdir-install-drivers] Error 2 > make[4]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools/blktap2' > make[3]: *** [subdirs-install] > Error 2 > make[3]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools/blktap2' > make[2]: *** > [subdir-install-blktap2] Error 2 > make[2]: Leaving directory > `/root/Xen/xen-4.2-unstable/tools' > make[1]: *** [subdirs-install] Error 2 > > make[1]: Leaving directory `/root/Xen/xen-4.2-unstable/tools' > make: *** > [install-tools] Error 2 > ------ > > root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/src= -c > -o tapdisk-log.o tapdisk-log.c = > cc1: warnings being treated as errors > > tapdisk-log.c: In function =8Ctlog_flush=B9: > tapdisk-log.c:250: error: ignoring > return value of =8Cwrite=B9, declared > with attribute warn_unused_result > > ------ > = > /root/Xen/xen-4.2-unstable/tools/blktap2/drivers/../../../tools/libaio/sr= c -c > -o tapdisk2.o tapdisk2.c = > cc1: warnings being treated as errors > > tapdisk2.c: In function =8Cmain=B9: > tapdisk2.c:82: error: ignoring return value > of =8Cchdir=B9, declared with > attribute warn_unused_result > ------ > cc1: > warnings being treated as errors > tapdisk-stream.c: In function > =8Ctapdisk_stream_poll_clear=B9: > tapdisk-stream.c:148: error: ignoring return > value of =8Cread=B9, declared > with attribute warn_unused_result > > tapdisk-stream.c: In function =8Ctapdisk_stream_poll_set=B9: > > tapdisk-stream.c:158: error: ignoring return value of =8Cwrite=B9, > declared with > attribute warn_unused_result > tapdisk-stream.c: In function > =8Ctapdisk_stream_print_request=B9: > tapdisk-stream.c:206: error: ignoring return > value of =8Cwrite=B9, > declared with attribute warn_unused_result > = > = > = > Best > Regards, > Bei Guan > > = _______________________________________________ Xen-devel mailing > list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:18:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsXt-00085p-FO; Fri, 11 May 2012 16:18:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsXs-00085c-D5 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:18:20 +0000 Received: from [85.158.143.35:9014] by server-1.bemta-4.messagelabs.com id DA/2A-20925-BCB3DAF4; Fri, 11 May 2012 16:18:19 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336753098!13564697!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20818 invoked from network); 11 May 2012 16:18:18 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:18:18 -0000 Received: by eekd41 with SMTP id d41so132915eek.32 for ; Fri, 11 May 2012 09:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=7oS+/M4SLBmL4fUN+ur5jx9Kp+SeOkHQAdnCXLN4hlQ=; b=HhaAvC0+irzzWQKpziUbAYecaLkx1vadDV+Zbla0efKWj76Gbi7VOu4sDJy5ktaNv/ TDv3IxY3A6oda8hfrDxJmExiMnCBX+hwD+XRD/6RkNUgi43SZ+HkIj36glKx+RmIAZuO /oVkR8HtRoOd/Cc2e+u/4TJ7qrfqHvXZzM7d88X+nkmQyZglMBjfYXrh2dw6uww2FSuB fJiBFxIrzXN1Cdujp5gR/Dcg+VTaNftr3eOXvNVC+yS+ur49h+DuIssCh5wUgP0q6AFE dbcE9cj9u4VdHcAo5uhtVtRigN4AEwko0EfPBBTRvNu4PLUfEXqdQKB2vL1xSfBIVhxj EbFQ== Received: by 10.213.113.14 with SMTP id y14mr2743544ebp.12.1336753097940; Fri, 11 May 2012 09:18:17 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y54sm47188537eef.10.2012.05.11.09.18.16 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:18:17 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:18:13 +0100 From: Keir Fraser To: Bei Guan , Ian Campbell Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vkanZ08+Wb0u9d0+2LCshBJFncA== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 17:10, "Bei Guan" wrote: > 2012/5/11 Ian Campbell >> On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: >>> = >>> 2012/5/11 Ian Campbell >>> = >>> Thank you for your reply. I have used "hg pull; hg update" to update >>> to the latest Xen and it is the version info: >>> = >>> root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip >>> changeset: =A0 25287:54c8c9eaee92 >>> tag: =A0 =A0 =A0 =A0 tip >>> user: =A0 =A0 =A0 =A0Dietmar Hahn >>> date: =A0 =A0 =A0 =A0Fri Apr 27 11:09:26 2012 +0200 >>> summary: =A0 =A0 docs: add vpmu description to xen-command-line.markdown >>> = >>> But, it still has the same errors. >> = >> Thanks, looks like we still need to fix these errors then. >> = >> I'm not really happy with the following, but it's no worse than things >> are today... >> = >> Bei, I don't see these build failures, does this work for you? > = > No, it doesn't work for me. There is the same error. > My environment and gcc version are like this: I think the problem is that casting the function result to void doesn't work around this warning. You actually have to do something with the return code. :-( -- Keir > root@gavin-desktop:~# uname -a > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 > x86_64 GNU/Linux > = > root@gavin-desktop:~# gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu 4.4.3-4u= buntu5' > --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr --enable-= shared > --enable-multiarch --enable-linker-build-id --with-system-zlib > --libexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dpos= ix > --with-gxx-include-dir=3D/usr/include/c++/4.4 --program-suffix=3D-4.4 --e= nable-nls > --enable-clocale=3Dgnu --enable-libstdcxx-debug --enable-plugin --enable-= objc-gc > --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric > --enable-checking=3Drelease --build=3Dx86_64-linux-gnu --host=3Dx86_64-li= nux-gnu > --target=3Dx86_64-linux-gnu > Thread model: posix > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > = > = > = > = > Thanks, > Bei Guan > = > = > = > =A0 >> = >> 8<------------------------------------------------------ >> = >> # HG changeset patch >> # User Ian Campbell >> # Date 1336751175 -3600 >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >> # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 >> blktap: avoid attribute warn_unused_result build failures. >> = >> I'm not proud of this, but since none of these callers of read/write hav= e any >> other error handling and return void themselves (for several links up the >> call >> chain AFAICT) and because I don't really want to get into a massive rewo= rking >> of blktap2 I suppose it is at least pragmatic >> = >> Signed-off-by: Ian Campbell >> = >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c >> --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:19:1= 6 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:46:1= 5 2012 >> +0100 >> @@ -247,7 +247,7 @@ tlog_flush(void) >> =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511)); >> = >> =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsize - size); >> - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >> + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize); >> = >> =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf; >> = >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue= .c >> --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:19:16 = 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:46:15 = 2012 >> +0100 >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que >> =A0 =A0 =A0 =A0uint64_t val; >> = >> =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD) >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val, sizeof(val)); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd, &val, sizeof(val= )); >> =A0} >> = >> =A0static void >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-strea= m.c >> --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:19:16 = 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:46:15 = 2012 >> +0100 >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk >> =A0{ >> =A0 =A0 =A0 =A0int dummy; >> = >> - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> =A0 =A0 =A0 =A0p->set =3D 0; >> =A0} >> = >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s >> =A0 =A0 =A0 =A0int dummy =3D 0; >> = >> =A0 =A0 =A0 =A0if (!p->set) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE], &dummy, sizeof(= dummy)); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_WRITE], &dummy, s= izeof(dummy)); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >> =A0 =A0 =A0 =A0} >> =A0} >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd >> =A0{ >> =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned long)tapdisk_stream_requ= est_idx(s, >> sreq); >> =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd->ring.vstart, id= x, 0); >> - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> =A0} >> = >> =A0static void >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c >> --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:46:15 2012 +0100 >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0if (optind !=3D argc) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL); >> = >> - =A0 =A0 =A0 chdir("/"); >> + =A0 =A0 =A0 if (chdir("/")) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(/): %d\n", errno); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out; >> + =A0 =A0 =A0 } >> + >> =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2"); >> = >> =A0 =A0 =A0 =A0err =3D tapdisk_server_init(); >> = >> = > = > = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:18:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsXt-00085p-FO; Fri, 11 May 2012 16:18:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsXs-00085c-D5 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:18:20 +0000 Received: from [85.158.143.35:9014] by server-1.bemta-4.messagelabs.com id DA/2A-20925-BCB3DAF4; Fri, 11 May 2012 16:18:19 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336753098!13564697!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20818 invoked from network); 11 May 2012 16:18:18 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:18:18 -0000 Received: by eekd41 with SMTP id d41so132915eek.32 for ; Fri, 11 May 2012 09:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=7oS+/M4SLBmL4fUN+ur5jx9Kp+SeOkHQAdnCXLN4hlQ=; b=HhaAvC0+irzzWQKpziUbAYecaLkx1vadDV+Zbla0efKWj76Gbi7VOu4sDJy5ktaNv/ TDv3IxY3A6oda8hfrDxJmExiMnCBX+hwD+XRD/6RkNUgi43SZ+HkIj36glKx+RmIAZuO /oVkR8HtRoOd/Cc2e+u/4TJ7qrfqHvXZzM7d88X+nkmQyZglMBjfYXrh2dw6uww2FSuB fJiBFxIrzXN1Cdujp5gR/Dcg+VTaNftr3eOXvNVC+yS+ur49h+DuIssCh5wUgP0q6AFE dbcE9cj9u4VdHcAo5uhtVtRigN4AEwko0EfPBBTRvNu4PLUfEXqdQKB2vL1xSfBIVhxj EbFQ== Received: by 10.213.113.14 with SMTP id y14mr2743544ebp.12.1336753097940; Fri, 11 May 2012 09:18:17 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id y54sm47188537eef.10.2012.05.11.09.18.16 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:18:17 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:18:13 +0100 From: Keir Fraser To: Bei Guan , Ian Campbell Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vkanZ08+Wb0u9d0+2LCshBJFncA== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 17:10, "Bei Guan" wrote: > 2012/5/11 Ian Campbell >> On Fri, 2012-05-11 at 16:12 +0100, Bei Guan wrote: >>> = >>> 2012/5/11 Ian Campbell >>> = >>> Thank you for your reply. I have used "hg pull; hg update" to update >>> to the latest Xen and it is the version info: >>> = >>> root@gavin-desktop:~/Xen/xen-4.2-unstable# hg tip >>> changeset: =A0 25287:54c8c9eaee92 >>> tag: =A0 =A0 =A0 =A0 tip >>> user: =A0 =A0 =A0 =A0Dietmar Hahn >>> date: =A0 =A0 =A0 =A0Fri Apr 27 11:09:26 2012 +0200 >>> summary: =A0 =A0 docs: add vpmu description to xen-command-line.markdown >>> = >>> But, it still has the same errors. >> = >> Thanks, looks like we still need to fix these errors then. >> = >> I'm not really happy with the following, but it's no worse than things >> are today... >> = >> Bei, I don't see these build failures, does this work for you? > = > No, it doesn't work for me. There is the same error. > My environment and gcc version are like this: I think the problem is that casting the function result to void doesn't work around this warning. You actually have to do something with the return code. :-( -- Keir > root@gavin-desktop:~# uname -a > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 > x86_64 GNU/Linux > = > root@gavin-desktop:~# gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu 4.4.3-4u= buntu5' > --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr --enable-= shared > --enable-multiarch --enable-linker-build-id --with-system-zlib > --libexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dpos= ix > --with-gxx-include-dir=3D/usr/include/c++/4.4 --program-suffix=3D-4.4 --e= nable-nls > --enable-clocale=3Dgnu --enable-libstdcxx-debug --enable-plugin --enable-= objc-gc > --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric > --enable-checking=3Drelease --build=3Dx86_64-linux-gnu --host=3Dx86_64-li= nux-gnu > --target=3Dx86_64-linux-gnu > Thread model: posix > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > = > = > = > = > Thanks, > Bei Guan > = > = > = > =A0 >> = >> 8<------------------------------------------------------ >> = >> # HG changeset patch >> # User Ian Campbell >> # Date 1336751175 -3600 >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >> # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 >> blktap: avoid attribute warn_unused_result build failures. >> = >> I'm not proud of this, but since none of these callers of read/write hav= e any >> other error handling and return void themselves (for several links up the >> call >> chain AFAICT) and because I don't really want to get into a massive rewo= rking >> of blktap2 I suppose it is at least pragmatic >> = >> Signed-off-by: Ian Campbell >> = >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-log.c >> --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:19:1= 6 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 Fri May 11 16:46:1= 5 2012 >> +0100 >> @@ -247,7 +247,7 @@ tlog_flush(void) >> =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511)); >> = >> =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsize - size); >> - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >> + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize); >> = >> =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf; >> = >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-queue= .c >> --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:19:16 = 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri May 11 16:46:15 = 2012 >> +0100 >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que >> =A0 =A0 =A0 =A0uint64_t val; >> = >> =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD) >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val, sizeof(val)); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd, &val, sizeof(val= )); >> =A0} >> = >> =A0static void >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk-strea= m.c >> --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:19:16 = 2012 >> +0100 >> +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri May 11 16:46:15 = 2012 >> +0100 >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk >> =A0{ >> =A0 =A0 =A0 =A0int dummy; >> = >> - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> =A0 =A0 =A0 =A0p->set =3D 0; >> =A0} >> = >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s >> =A0 =A0 =A0 =A0int dummy =3D 0; >> = >> =A0 =A0 =A0 =A0if (!p->set) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE], &dummy, sizeof(= dummy)); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_WRITE], &dummy, s= izeof(dummy)); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >> =A0 =A0 =A0 =A0} >> =A0} >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd >> =A0{ >> =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned long)tapdisk_stream_requ= est_idx(s, >> sreq); >> =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd->ring.vstart, id= x, 0); >> - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> =A0} >> = >> =A0static void >> diff -r adc74e492edf -r 15ed8f45c4e5 tools/blktap2/drivers/tapdisk2.c >> --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16:46:15 2012 +0100 >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0if (optind !=3D argc) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL); >> = >> - =A0 =A0 =A0 chdir("/"); >> + =A0 =A0 =A0 if (chdir("/")) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(/): %d\n", errno); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out; >> + =A0 =A0 =A0 } >> + >> =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2"); >> = >> =A0 =A0 =A0 =A0err =3D tapdisk_server_init(); >> = >> = > = > = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:21:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsaa-0008OX-1n; Fri, 11 May 2012 16:21:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsaY-0008OM-AA for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:21:06 +0000 Received: from [85.158.143.35:26710] by server-3.bemta-4.messagelabs.com id 9B/26-05853-17C3DAF4; Fri, 11 May 2012 16:21:05 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1336753264!14132481!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7433 invoked from network); 11 May 2012 16:21:04 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 16:21:04 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jored mo82) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J010eao4BEFxXL ; Fri, 11 May 2012 18:21:04 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 92F5918637; Fri, 11 May 2012 18:21:03 +0200 (CEST) Date: Fri, 11 May 2012 18:21:03 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120511162103.GA24144@aepfle.de> References: <1336751953.23818.118.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336751953.23818.118.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, Ian Campbell wrote: > On Fri, 2012-05-11 at 15:35 +0100, Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering > > # Date 1336743357 -7200 > > # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 > > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > > unmodified_drivers: remove inclusion of asm/system.h > > > > Allow compilation of PVonHVM drivers with forward-ported xenlinux > > sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present > > anymore. Remove inclusion of this header, its not needed. > > It is not needed for 3.4 or it is not needed for any historical Linux > version which these drivers are supposed to be built against? What > kernels have you build tested? asm/system.h does not need to be included. I tested it with sles11sp1+2, opensuse 11.2, 11.4, 12.1 and 12.2. I have not tested it with a plain linux-2.6.18-xen.hg, but I suspect it should work there too. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:21:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsaa-0008OX-1n; Fri, 11 May 2012 16:21:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsaY-0008OM-AA for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:21:06 +0000 Received: from [85.158.143.35:26710] by server-3.bemta-4.messagelabs.com id 9B/26-05853-17C3DAF4; Fri, 11 May 2012 16:21:05 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1336753264!14132481!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyOTYwNjg=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7433 invoked from network); 11 May 2012 16:21:04 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 16:21:04 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEiK4 X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-090-115.pools.arcor-ip.net [88.65.90.115]) by smtp.strato.de (jored mo82) (RZmta 29.7 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J010eao4BEFxXL ; Fri, 11 May 2012 18:21:04 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 92F5918637; Fri, 11 May 2012 18:21:03 +0200 (CEST) Date: Fri, 11 May 2012 18:21:03 +0200 From: Olaf Hering To: Ian Campbell Message-ID: <20120511162103.GA24144@aepfle.de> References: <1336751953.23818.118.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336751953.23818.118.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21.rev5543 (2011-12-20) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: remove inclusion of asm/system.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, Ian Campbell wrote: > On Fri, 2012-05-11 at 15:35 +0100, Olaf Hering wrote: > > # HG changeset patch > > # User Olaf Hering > > # Date 1336743357 -7200 > > # Node ID f81fa4014d8c66bd1a80e4914c5d777cbdb343d1 > > # Parent 0f53540494f779a1260d4e5319dcdb268389dd07 > > unmodified_drivers: remove inclusion of asm/system.h > > > > Allow compilation of PVonHVM drivers with forward-ported xenlinux > > sources in openSuSE 12.2. Since Linux 3.4 asm/system.h is not present > > anymore. Remove inclusion of this header, its not needed. > > It is not needed for 3.4 or it is not needed for any historical Linux > version which these drivers are supposed to be built against? What > kernels have you build tested? asm/system.h does not need to be included. I tested it with sles11sp1+2, opensuse 11.2, 11.4, 12.1 and 12.2. I have not tested it with a plain linux-2.6.18-xen.hg, but I suspect it should work there too. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:22:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsc5-000088-I0; Fri, 11 May 2012 16:22:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsc3-00007t-N2 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:22:39 +0000 Received: from [85.158.143.35:38392] by server-3.bemta-4.messagelabs.com id C5/87-05853-ECC3DAF4; Fri, 11 May 2012 16:22:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336753357!14953731!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26482 invoked from network); 11 May 2012 16:22: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; 11 May 2012 16:22:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434314" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:22: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, 11 May 2012 17:22:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsc0-0007m4-Uy; Fri, 11 May 2012 16:22:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsc0-000253-U3; Fri, 11 May 2012 17:22:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.15564.760599.342906@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:22:36 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> References: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset"): > xl: use libxl_cpumap_set_none not memset Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:22:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsc5-000088-I0; Fri, 11 May 2012 16:22:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsc3-00007t-N2 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:22:39 +0000 Received: from [85.158.143.35:38392] by server-3.bemta-4.messagelabs.com id C5/87-05853-ECC3DAF4; Fri, 11 May 2012 16:22:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1336753357!14953731!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26482 invoked from network); 11 May 2012 16:22: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; 11 May 2012 16:22:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434314" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:22: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, 11 May 2012 17:22:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsc0-0007m4-Uy; Fri, 11 May 2012 16:22:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsc0-000253-U3; Fri, 11 May 2012 17:22:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.15564.760599.342906@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:22:36 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> References: <5abc2c4e80892ca27db5.1336735374@cosworth.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] [PATCH] xl: use libxl_cpumap_set_none not memset"): > xl: use libxl_cpumap_set_none not memset Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:24:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:24:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsdo-0000NB-8f; Fri, 11 May 2012 16:24:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsdm-0000Mx-Rj for xen-devel@lists.xen.org; Fri, 11 May 2012 16:24:27 +0000 Received: from [193.109.254.147:38407] by server-10.bemta-14.messagelabs.com id 07/85-05847-A3D3DAF4; Fri, 11 May 2012 16:24:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336753465!1959224!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6625 invoked from network); 11 May 2012 16:24:25 -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; 11 May 2012 16:24:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434353" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:24: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, 11 May 2012 17:24:24 +0100 Message-ID: <1336753463.23818.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan Date: Fri, 11 May 2012 17:24:23 +0100 In-Reply-To: References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > No, it doesn't work for me. There is the same error. Hrm. Since you can reproduce would you mind experimenting a bit to figure out the correct fix for this? Perhaps adding -Wno-unused-result to C flags helps (google suggests it may not)? Or maybe just assigning to a dummy variable. Ian. > My environment and gcc version are like this: > > root@gavin-desktop:~# uname -a > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > 2011 x86_64 GNU/Linux > > root@gavin-desktop:~# gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 4.4.3-4ubuntu5' > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --enable-multiarch --enable-linker-build-id > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > --disable-werror --with-arch-32=i486 --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > > > > > Thanks, > Bei Guan > > > > > > 8<------------------------------------------------------ > > # HG changeset patch > # User Ian Campbell > # Date 1336751175 -3600 > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > blktap: avoid attribute warn_unused_result build failures. > > I'm not proud of this, but since none of these callers of > read/write have any > other error handling and return void themselves (for several > links up the call > chain AFAICT) and because I don't really want to get into a > massive reworking > of blktap2 I suppose it is at least pragmatic > > Signed-off-by: Ian Campbell > > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-log.c > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > 16:46:15 2012 +0100 > @@ -247,7 +247,7 @@ tlog_flush(void) > wsize = ((size + 511) & (~511)); > > memset(tapdisk_log.buf + size, '\n', wsize - size); > - write(fd, tapdisk_log.buf, wsize); > + (void)write(fd, tapdisk_log.buf, wsize); > > tapdisk_log.p = tapdisk_log.buf; > > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-queue.c > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > 16:46:15 2012 +0100 > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > uint64_t val; > > if (lio->flags & LIO_FLAG_EVENTFD) > - read(lio->event_fd, &val, sizeof(val)); > + (void)read(lio->event_fd, &val, sizeof(val)); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-stream.c > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > 16:46:15 2012 +0100 > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > { > int dummy; > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > p->set = 0; > } > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > int dummy = 0; > > if (!p->set) { > - write(p->pipe[POLL_WRITE], &dummy, > sizeof(dummy)); > + (void)write(p->pipe[POLL_WRITE], &dummy, > sizeof(dummy)); > p->set = 1; > } > } > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > { > unsigned long idx = (unsigned > long)tapdisk_stream_request_idx(s, sreq); > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > idx, 0); > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > + (void)write(s->out_fd, buf, sreq->secs << > SECTOR_SHIFT); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk2.c > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > 2012 +0100 > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > if (optind != argc) > usage(argv[0], EINVAL); > > - chdir("/"); > + if (chdir("/")) { > + DPRINTF("failed to chdir(/): %d\n", errno); > + err = 1; > + goto out; > + } > + > tapdisk_start_logging("tapdisk2"); > > err = tapdisk_server_init(); > > > > > > -- > Best Regards, > Bei Guan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:24:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:24:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsdo-0000NB-8f; Fri, 11 May 2012 16:24:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsdm-0000Mx-Rj for xen-devel@lists.xen.org; Fri, 11 May 2012 16:24:27 +0000 Received: from [193.109.254.147:38407] by server-10.bemta-14.messagelabs.com id 07/85-05847-A3D3DAF4; Fri, 11 May 2012 16:24:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1336753465!1959224!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6625 invoked from network); 11 May 2012 16:24:25 -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; 11 May 2012 16:24:25 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434353" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:24: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, 11 May 2012 17:24:24 +0100 Message-ID: <1336753463.23818.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Bei Guan Date: Fri, 11 May 2012 17:24:23 +0100 In-Reply-To: References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > No, it doesn't work for me. There is the same error. Hrm. Since you can reproduce would you mind experimenting a bit to figure out the correct fix for this? Perhaps adding -Wno-unused-result to C flags helps (google suggests it may not)? Or maybe just assigning to a dummy variable. Ian. > My environment and gcc version are like this: > > root@gavin-desktop:~# uname -a > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > 2011 x86_64 GNU/Linux > > root@gavin-desktop:~# gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 4.4.3-4ubuntu5' > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --enable-multiarch --enable-linker-build-id > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > --disable-werror --with-arch-32=i486 --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > > > > > Thanks, > Bei Guan > > > > > > 8<------------------------------------------------------ > > # HG changeset patch > # User Ian Campbell > # Date 1336751175 -3600 > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > blktap: avoid attribute warn_unused_result build failures. > > I'm not proud of this, but since none of these callers of > read/write have any > other error handling and return void themselves (for several > links up the call > chain AFAICT) and because I don't really want to get into a > massive reworking > of blktap2 I suppose it is at least pragmatic > > Signed-off-by: Ian Campbell > > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-log.c > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > 16:46:15 2012 +0100 > @@ -247,7 +247,7 @@ tlog_flush(void) > wsize = ((size + 511) & (~511)); > > memset(tapdisk_log.buf + size, '\n', wsize - size); > - write(fd, tapdisk_log.buf, wsize); > + (void)write(fd, tapdisk_log.buf, wsize); > > tapdisk_log.p = tapdisk_log.buf; > > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-queue.c > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > 16:46:15 2012 +0100 > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > uint64_t val; > > if (lio->flags & LIO_FLAG_EVENTFD) > - read(lio->event_fd, &val, sizeof(val)); > + (void)read(lio->event_fd, &val, sizeof(val)); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk-stream.c > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > 16:19:16 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > 16:46:15 2012 +0100 > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > { > int dummy; > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > p->set = 0; > } > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > int dummy = 0; > > if (!p->set) { > - write(p->pipe[POLL_WRITE], &dummy, > sizeof(dummy)); > + (void)write(p->pipe[POLL_WRITE], &dummy, > sizeof(dummy)); > p->set = 1; > } > } > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > { > unsigned long idx = (unsigned > long)tapdisk_stream_request_idx(s, sreq); > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > idx, 0); > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > + (void)write(s->out_fd, buf, sreq->secs << > SECTOR_SHIFT); > } > > static void > diff -r adc74e492edf -r 15ed8f45c4e5 > tools/blktap2/drivers/tapdisk2.c > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > 2012 +0100 > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > 2012 +0100 > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > if (optind != argc) > usage(argv[0], EINVAL); > > - chdir("/"); > + if (chdir("/")) { > + DPRINTF("failed to chdir(/): %d\n", errno); > + err = 1; > + goto out; > + } > + > tapdisk_start_logging("tapdisk2"); > > err = tapdisk_server_init(); > > > > > > -- > Best Regards, > Bei Guan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:26:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:26:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsg3-0000di-Up; Fri, 11 May 2012 16:26:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsg1-0000dE-Rd for xen-devel@lists.xen.org; Fri, 11 May 2012 16:26:46 +0000 Received: from [193.109.254.147:59489] by server-10.bemta-14.messagelabs.com id A6/D7-05847-5CD3DAF4; Fri, 11 May 2012 16:26:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336753604!8791247!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17209 invoked from network); 11 May 2012 16:26:44 -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; 11 May 2012 16:26:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434396" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:26:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:26:43 +0100 Message-ID: <1336753602.23818.133.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:26:42 +0100 In-Reply-To: <20397.14624.57140.518016@mariner.uk.xensource.com> References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-4-git-send-email-roger.pau@citrix.com> <20373.34767.584624.953798@mariner.uk.xensource.com> <4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com> <20377.18296.235567.918003@mariner.uk.xensource.com> <1335445762.28015.141.camel@zakaz.uk.xensource.com> <20397.14624.57140.518016@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Roger Pau Monne , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:06 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"): > > On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote: > > > I think we need to think about these timeouts. At the very least > > > they're policy which should probably not be hardcoded in libxl; and > > > arguably people might want to be able to specify infinite ("I trust my > > > guest or driver domain and never want to pull the rug out from under > > > its feet") or zero ("this guest or driver domain has gone wrong and I > > > want it killed, now"). > > > > Unless the same is going to be true of the eventual solution (which I > > suppose it may well be?) we should be wary of over engineering the > > interim solution for 4.2. > > I guess. Also xend's poor behaviour in this area (failing hotplug > timeouts) provides something of an excuse... > > > > Perhaps it would be better to do things the other way around, and have > > > an env var for the case where we're _not_ calling the script from > > > udev ? After all, udev config is configuration (at least on my > > > distros) which the user may not update when the software is updated. > > > > It was my suggestion to do it this way so that we don't end up with a > > vestigial env var which must always be set for no real reason after > > we've removed the udev path altogether. > > When we have "removed the udev path altogether" we will still need to > have something to prevent trouble if the udev rules remain for some > reason. > > > I don't really mind though, we could live with that vestigial thing, or > > have another, easier, transition a few releases down the line. > > The vestigial thing can indeed eventually go away. I'm happy for Roger and you to agree whichever sense you think best for the flag. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:26:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:26:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsg3-0000di-Up; Fri, 11 May 2012 16:26:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsg1-0000dE-Rd for xen-devel@lists.xen.org; Fri, 11 May 2012 16:26:46 +0000 Received: from [193.109.254.147:59489] by server-10.bemta-14.messagelabs.com id A6/D7-05847-5CD3DAF4; Fri, 11 May 2012 16:26:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336753604!8791247!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17209 invoked from network); 11 May 2012 16:26:44 -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; 11 May 2012 16:26:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434396" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:26:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:26:43 +0100 Message-ID: <1336753602.23818.133.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:26:42 +0100 In-Reply-To: <20397.14624.57140.518016@mariner.uk.xensource.com> References: <1334928211-29856-1-git-send-email-roger.pau@citrix.com> <1334928211-29856-4-git-send-email-roger.pau@citrix.com> <20373.34767.584624.953798@mariner.uk.xensource.com> <4F982F18.2080902@citrix.com> <4F99360E.2010201@citrix.com> <20377.18296.235567.918003@mariner.uk.xensource.com> <1335445762.28015.141.camel@zakaz.uk.xensource.com> <20397.14624.57140.518016@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Roger Pau Monne , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:06 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd"): > > On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote: > > > I think we need to think about these timeouts. At the very least > > > they're policy which should probably not be hardcoded in libxl; and > > > arguably people might want to be able to specify infinite ("I trust my > > > guest or driver domain and never want to pull the rug out from under > > > its feet") or zero ("this guest or driver domain has gone wrong and I > > > want it killed, now"). > > > > Unless the same is going to be true of the eventual solution (which I > > suppose it may well be?) we should be wary of over engineering the > > interim solution for 4.2. > > I guess. Also xend's poor behaviour in this area (failing hotplug > timeouts) provides something of an excuse... > > > > Perhaps it would be better to do things the other way around, and have > > > an env var for the case where we're _not_ calling the script from > > > udev ? After all, udev config is configuration (at least on my > > > distros) which the user may not update when the software is updated. > > > > It was my suggestion to do it this way so that we don't end up with a > > vestigial env var which must always be set for no real reason after > > we've removed the udev path altogether. > > When we have "removed the udev path altogether" we will still need to > have something to prevent trouble if the udev rules remain for some > reason. > > > I don't really mind though, we could live with that vestigial thing, or > > have another, easier, transition a few releases down the line. > > The vestigial thing can indeed eventually go away. I'm happy for Roger and you to agree whichever sense you think best for the flag. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:33:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:33:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSslw-00010Y-U8; Fri, 11 May 2012 16:32:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSslv-00010N-Ga for xen-devel@lists.xen.org; Fri, 11 May 2012 16:32:51 +0000 Received: from [85.158.143.35:60317] by server-2.bemta-4.messagelabs.com id BB/40-17550-23F3DAF4; Fri, 11 May 2012 16:32:50 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336753970!15648569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14266 invoked from network); 11 May 2012 16:32:50 -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; 11 May 2012 16:32:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:32: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, 11 May 2012 17:32:50 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSslt-0007pY-Sq; Fri, 11 May 2012 16:32:49 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSslt-00026Q-Rz; Fri, 11 May 2012 17:32:49 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16177.826755.879002@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:32:49 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336745632-28158-2-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> <1336745632-28158-2-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix"): > NetBSD `python-conf --ldflags` doesn't return the library dir, so we > have to add it to LDFLAGS based on the prefix returned by `python-conf > --prefix`. Also the include dir has been added to CFLAGS using the > same technique. ... > dnl If python-config is found use it > - CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`" > - LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`" > + ac_python_prefix=`$PYTHON-config --prefix` > + CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include" > + LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib" Shouldn't the -I and particulary the -L come first ? TBH I'm surprised that this works since it looks like it ought to generate -lpython2.6 -L/usr/blah/lib/bleh/python2.6 or something, which I wouldn't expect to work. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:33:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:33:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSslw-00010Y-U8; Fri, 11 May 2012 16:32:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSslv-00010N-Ga for xen-devel@lists.xen.org; Fri, 11 May 2012 16:32:51 +0000 Received: from [85.158.143.35:60317] by server-2.bemta-4.messagelabs.com id BB/40-17550-23F3DAF4; Fri, 11 May 2012 16:32:50 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1336753970!15648569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14266 invoked from network); 11 May 2012 16:32:50 -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; 11 May 2012 16:32:50 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:32: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, 11 May 2012 17:32:50 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSslt-0007pY-Sq; Fri, 11 May 2012 16:32:49 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSslt-00026Q-Rz; Fri, 11 May 2012 17:32:49 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16177.826755.879002@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:32:49 +0100 To: Roger Pau Monne Newsgroups: chiark.mail.xen.devel In-Reply-To: <1336745632-28158-2-git-send-email-roger.pau@citrix.com> References: <1336745632-28158-1-git-send-email-roger.pau@citrix.com> <1336745632-28158-2-git-send-email-roger.pau@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Roger Pau Monne writes ("[Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix"): > NetBSD `python-conf --ldflags` doesn't return the library dir, so we > have to add it to LDFLAGS based on the prefix returned by `python-conf > --prefix`. Also the include dir has been added to CFLAGS using the > same technique. ... > dnl If python-config is found use it > - CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`" > - LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`" > + ac_python_prefix=`$PYTHON-config --prefix` > + CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include" > + LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib" Shouldn't the -I and particulary the -L come first ? TBH I'm surprised that this works since it looks like it ought to generate -lpython2.6 -L/usr/blah/lib/bleh/python2.6 or something, which I wouldn't expect to work. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:33:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsmD-000127-B6; Fri, 11 May 2012 16:33:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsmC-00011p-15 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:33:08 +0000 Received: from [85.158.138.51:16838] by server-2.bemta-3.messagelabs.com id 6D/D4-09269-24F3DAF4; Fri, 11 May 2012 16:33:06 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336753984!26596074!1 X-Originating-IP: [209.85.217.173] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8791 invoked from network); 11 May 2012 16:33:05 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:33:05 -0000 Received: by lbok6 with SMTP id k6so2529215lbo.32 for ; Fri, 11 May 2012 09:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/pWPR51mUITazkoRibJWYRVsIY4UCY/RUeYA/NXmqyk=; b=mCdeIPZfa33hvLMDWiSsHsdNBF8EfNCY37bKLChAjVKmOGTIdnIm75ZBpfrovbS41g Fgty25UDQLrNHy6CqAUtFbVVTyO5SjFADAlY3aYpDI+2EqynaEABbalP8Yko425Vs84K j3kCaVTDKMpzv/+ewtv45/FkuGJQut05AwQi4yOiODAe0N6weeeNkfKI1vJiO4P0i7/C VKgpa5uVen8toIw/+PjVjuDNonQUY4Cc/OaME/PqITB8t7L97o/rJG5QWY5WknV9KlTS GLl4e5tEsM0iQTNzX7pcOg7EE3B7g4jNTEnObtmFtfWU5xAqM0Bx0jaTxICO8pa8QE+6 uHqg== MIME-Version: 1.0 Received: by 10.152.123.244 with SMTP id md20mr819387lab.0.1336753984300; Fri, 11 May 2012 09:33:04 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:33:04 -0700 (PDT) In-Reply-To: <1336753463.23818.131.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> <1336753463.23818.131.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:33:04 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: "Keir \(Xen.org\)" , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3953058332252177758==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3953058332252177758== Content-Type: multipart/alternative; boundary=f46d042f9cd862e76e04bfc54a97 --f46d042f9cd862e76e04bfc54a97 Content-Type: text/plain; charset=ISO-8859-1 2012/5/12 Ian Campbell > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > > > No, it doesn't work for me. There is the same error. > > Hrm. Since you can reproduce would you mind experimenting a bit to > figure out the correct fix for this? > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > may not)? > Yes, I add this option to Makefile. And now it works well. The patch is as the following. Thank you very much. diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile --- a/tools/blktap2/drivers/Makefile Fri Apr 27 11:09:26 2012 +0200 +++ b/tools/blktap2/drivers/Makefile Sat May 12 00:31:12 2012 +0800 @@ -11,6 +11,7 @@ CFLAGS += -Werror -g CFLAGS += -Wno-unused +CFLAGS += -Wno-unused-result CFLAGS += -fno-strict-aliasing CFLAGS += -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers CFLAGS += $(CFLAGS_libxenctrl) Thanks, Bei Guan > > Or maybe just assigning to a dummy variable. > > Ian. > > > My environment and gcc version are like this: > > > > root@gavin-desktop:~# uname -a > > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > > 2011 x86_64 GNU/Linux > > > > root@gavin-desktop:~# gcc -v > > Using built-in specs. > > Target: x86_64-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > > 4.4.3-4ubuntu5' > > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > > --enable-shared --enable-multiarch --enable-linker-build-id > > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > > --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > > --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > > --disable-werror --with-arch-32=i486 --with-tune=generic > > --enable-checking=release --build=x86_64-linux-gnu > > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > > Thread model: posix > > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > > > > > > > > > > Thanks, > > Bei Guan > > > > > > > > > > > > 8<------------------------------------------------------ > > > > # HG changeset patch > > # User Ian Campbell > > # Date 1336751175 -3600 > > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > > blktap: avoid attribute warn_unused_result build failures. > > > > I'm not proud of this, but since none of these callers of > > read/write have any > > other error handling and return void themselves (for several > > links up the call > > chain AFAICT) and because I don't really want to get into a > > massive reworking > > of blktap2 I suppose it is at least pragmatic > > > > Signed-off-by: Ian Campbell > > > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-log.c > > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -247,7 +247,7 @@ tlog_flush(void) > > wsize = ((size + 511) & (~511)); > > > > memset(tapdisk_log.buf + size, '\n', wsize - size); > > - write(fd, tapdisk_log.buf, wsize); > > + (void)write(fd, tapdisk_log.buf, wsize); > > > > tapdisk_log.p = tapdisk_log.buf; > > > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-queue.c > > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > > uint64_t val; > > > > if (lio->flags & LIO_FLAG_EVENTFD) > > - read(lio->event_fd, &val, sizeof(val)); > > + (void)read(lio->event_fd, &val, sizeof(val)); > > } > > > > static void > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-stream.c > > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > > { > > int dummy; > > > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > > p->set = 0; > > } > > > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > > int dummy = 0; > > > > if (!p->set) { > > - write(p->pipe[POLL_WRITE], &dummy, > > sizeof(dummy)); > > + (void)write(p->pipe[POLL_WRITE], &dummy, > > sizeof(dummy)); > > p->set = 1; > > } > > } > > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > > { > > unsigned long idx = (unsigned > > long)tapdisk_stream_request_idx(s, sreq); > > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > > idx, 0); > > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > > + (void)write(s->out_fd, buf, sreq->secs << > > SECTOR_SHIFT); > > } > > > > static void > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk2.c > > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > > 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > > 2012 +0100 > > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > > if (optind != argc) > > usage(argv[0], EINVAL); > > > > - chdir("/"); > > + if (chdir("/")) { > > + DPRINTF("failed to chdir(/): %d\n", errno); > > + err = 1; > > + goto out; > > + } > > + > > tapdisk_start_logging("tapdisk2"); > > > > err = tapdisk_server_init(); > > > > > > > > > > > > -- > > Best Regards, > > Bei Guan > > > > > -- Best Regards, Bei Guan --f46d042f9cd862e76e04bfc54a97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/12 Ian Campbell <Ian.Campb= ell@citrix.com>
On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote:


> No, it doesn't work for me. There is the same error.

Hrm. Since you can reproduce would you mind experimenting a bit to figure out the correct fix for this?

Perhaps adding -Wno-unused-result to C flags helps (google suggests it
may not)?
Yes, I add this option to Makefile. And now = it works well. The patch is as the following. Thank you very much.

<= br>diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile
--- a/tools/blkta= p2/drivers/Makefile=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0200
+++ b/tools/blktap2/drivers/Makefile=A0=A0=A0 Sat May 12 00:31:12 2012 +080= 0
@@ -11,6 +11,7 @@
=A0
=A0CFLAGS=A0=A0=A0 +=3D -Werror -g
=A0C= FLAGS=A0=A0=A0 +=3D -Wno-unused
+CFLAGS=A0=A0=A0 +=3D -Wno-unused-result=
=A0CFLAGS=A0=A0=A0 +=3D -fno-strict-aliasing
=A0CFLAGS=A0=A0=A0 +=3D -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers=A0CFLAGS=A0=A0=A0 +=3D $(CFLAGS_libxenctrl)




Thanks,Bei Guan



=A0

Or maybe just assigning to a dummy variable.

Ian.

> My environment and gcc version are like this:
>
> root@gavin-desktop:~# uname -a
> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC<= br> > 2011 x86_64 GNU/Linux
>
> root@gavin-desktop:~# gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu > 4.4.3-4ubuntu5'
> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext<= br> > --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4=
> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu
> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric
> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu
> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>
>
>
>
> Thanks,
> Bei Guan
>
>
>
>
>
> =A0 =A0 =A0 =A0 8<-------------------------------------------------= -----
>
> =A0 =A0 =A0 =A0 # HG changeset patch
> =A0 =A0 =A0 =A0 # User Ian Campbell <ian.campbell@citrix.com>
> =A0 =A0 =A0 =A0 # Date 1336751175 -3600
> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99
> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 > =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build failu= res.
>
> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these cal= lers of
> =A0 =A0 =A0 =A0 read/write have any
> =A0 =A0 =A0 =A0 other error handling and return void themselves (for s= everal
> =A0 =A0 =A0 =A0 links up the call
> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want to g= et into a
> =A0 =A0 =A0 =A0 massive reworking
> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic
>
> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 = Fri May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 = Fri May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511));<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n&= #39;, wsize - size);
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize);=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;
>
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fr= i May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fr= i May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueu= e *que
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTF= D)
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &= amp;val, sizeof(val));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event= _fd, &val, sizeof(val));
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0static void
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fr= i May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fr= i May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct t= apdisk
> =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy;
>
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, = sizeof(dummy));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &d= ummy, sizeof(dummy));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0;
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tap= disk_s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) {
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WR= ITE], &dummy,
> =A0 =A0 =A0 =A0 sizeof(dummy));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[P= OLL_WRITE], &dummy,
> =A0 =A0 =A0 =A0 sizeof(dummy));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struc= t tapd
> =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned
> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->= vbd->ring.vstart,
> =A0 =A0 =A0 =A0 idx, 0);
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs &= lt;< SECTOR_SHIFT);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->= secs <<
> =A0 =A0 =A0 =A0 SECTOR_SHIFT);
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0static void
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 1= 6:19:16
> =A0 =A0 =A0 =A0 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 1= 6:46:15
> =A0 =A0 =A0 =A0 2012 +0100
> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[])
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL);=
>
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/");
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) {
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to = chdir(/): %d\n", errno);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2&qu= ot;);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init();
>
>
>
>
>
> --
> Best Regards,
> Bei Guan
>





--
Best Regard= s,
Bei Guan

--f46d042f9cd862e76e04bfc54a97-- --===============3953058332252177758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3953058332252177758==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:33:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSsmD-000127-B6; Fri, 11 May 2012 16:33:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsmC-00011p-15 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:33:08 +0000 Received: from [85.158.138.51:16838] by server-2.bemta-3.messagelabs.com id 6D/D4-09269-24F3DAF4; Fri, 11 May 2012 16:33:06 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336753984!26596074!1 X-Originating-IP: [209.85.217.173] 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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8791 invoked from network); 11 May 2012 16:33:05 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:33:05 -0000 Received: by lbok6 with SMTP id k6so2529215lbo.32 for ; Fri, 11 May 2012 09:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/pWPR51mUITazkoRibJWYRVsIY4UCY/RUeYA/NXmqyk=; b=mCdeIPZfa33hvLMDWiSsHsdNBF8EfNCY37bKLChAjVKmOGTIdnIm75ZBpfrovbS41g Fgty25UDQLrNHy6CqAUtFbVVTyO5SjFADAlY3aYpDI+2EqynaEABbalP8Yko425Vs84K j3kCaVTDKMpzv/+ewtv45/FkuGJQut05AwQi4yOiODAe0N6weeeNkfKI1vJiO4P0i7/C VKgpa5uVen8toIw/+PjVjuDNonQUY4Cc/OaME/PqITB8t7L97o/rJG5QWY5WknV9KlTS GLl4e5tEsM0iQTNzX7pcOg7EE3B7g4jNTEnObtmFtfWU5xAqM0Bx0jaTxICO8pa8QE+6 uHqg== MIME-Version: 1.0 Received: by 10.152.123.244 with SMTP id md20mr819387lab.0.1336753984300; Fri, 11 May 2012 09:33:04 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:33:04 -0700 (PDT) In-Reply-To: <1336753463.23818.131.camel@zakaz.uk.xensource.com> References: <1336745780.23818.80.camel@zakaz.uk.xensource.com> <1336751243.23818.106.camel@zakaz.uk.xensource.com> <1336753463.23818.131.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:33:04 +0800 Message-ID: From: Bei Guan To: Ian Campbell Cc: "Keir \(Xen.org\)" , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3953058332252177758==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3953058332252177758== Content-Type: multipart/alternative; boundary=f46d042f9cd862e76e04bfc54a97 --f46d042f9cd862e76e04bfc54a97 Content-Type: text/plain; charset=ISO-8859-1 2012/5/12 Ian Campbell > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > > > No, it doesn't work for me. There is the same error. > > Hrm. Since you can reproduce would you mind experimenting a bit to > figure out the correct fix for this? > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > may not)? > Yes, I add this option to Makefile. And now it works well. The patch is as the following. Thank you very much. diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile --- a/tools/blktap2/drivers/Makefile Fri Apr 27 11:09:26 2012 +0200 +++ b/tools/blktap2/drivers/Makefile Sat May 12 00:31:12 2012 +0800 @@ -11,6 +11,7 @@ CFLAGS += -Werror -g CFLAGS += -Wno-unused +CFLAGS += -Wno-unused-result CFLAGS += -fno-strict-aliasing CFLAGS += -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers CFLAGS += $(CFLAGS_libxenctrl) Thanks, Bei Guan > > Or maybe just assigning to a dummy variable. > > Ian. > > > My environment and gcc version are like this: > > > > root@gavin-desktop:~# uname -a > > Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > > 2011 x86_64 GNU/Linux > > > > root@gavin-desktop:~# gcc -v > > Using built-in specs. > > Target: x86_64-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > > 4.4.3-4ubuntu5' > > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > > --enable-shared --enable-multiarch --enable-linker-build-id > > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > > --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > > --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > > --disable-werror --with-arch-32=i486 --with-tune=generic > > --enable-checking=release --build=x86_64-linux-gnu > > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > > Thread model: posix > > gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > > > > > > > > > > Thanks, > > Bei Guan > > > > > > > > > > > > 8<------------------------------------------------------ > > > > # HG changeset patch > > # User Ian Campbell > > # Date 1336751175 -3600 > > # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > > # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > > blktap: avoid attribute warn_unused_result build failures. > > > > I'm not proud of this, but since none of these callers of > > read/write have any > > other error handling and return void themselves (for several > > links up the call > > chain AFAICT) and because I don't really want to get into a > > massive reworking > > of blktap2 I suppose it is at least pragmatic > > > > Signed-off-by: Ian Campbell > > > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-log.c > > --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -247,7 +247,7 @@ tlog_flush(void) > > wsize = ((size + 511) & (~511)); > > > > memset(tapdisk_log.buf + size, '\n', wsize - size); > > - write(fd, tapdisk_log.buf, wsize); > > + (void)write(fd, tapdisk_log.buf, wsize); > > > > tapdisk_log.p = tapdisk_log.buf; > > > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-queue.c > > --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > > uint64_t val; > > > > if (lio->flags & LIO_FLAG_EVENTFD) > > - read(lio->event_fd, &val, sizeof(val)); > > + (void)read(lio->event_fd, &val, sizeof(val)); > > } > > > > static void > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk-stream.c > > --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > > 16:19:16 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > > 16:46:15 2012 +0100 > > @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > > { > > int dummy; > > > > - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > > + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > > p->set = 0; > > } > > > > @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > > int dummy = 0; > > > > if (!p->set) { > > - write(p->pipe[POLL_WRITE], &dummy, > > sizeof(dummy)); > > + (void)write(p->pipe[POLL_WRITE], &dummy, > > sizeof(dummy)); > > p->set = 1; > > } > > } > > @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > > { > > unsigned long idx = (unsigned > > long)tapdisk_stream_request_idx(s, sreq); > > char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > > idx, 0); > > - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > > + (void)write(s->out_fd, buf, sreq->secs << > > SECTOR_SHIFT); > > } > > > > static void > > diff -r adc74e492edf -r 15ed8f45c4e5 > > tools/blktap2/drivers/tapdisk2.c > > --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > > 2012 +0100 > > +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > > 2012 +0100 > > @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > > if (optind != argc) > > usage(argv[0], EINVAL); > > > > - chdir("/"); > > + if (chdir("/")) { > > + DPRINTF("failed to chdir(/): %d\n", errno); > > + err = 1; > > + goto out; > > + } > > + > > tapdisk_start_logging("tapdisk2"); > > > > err = tapdisk_server_init(); > > > > > > > > > > > > -- > > Best Regards, > > Bei Guan > > > > > -- Best Regards, Bei Guan --f46d042f9cd862e76e04bfc54a97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/12 Ian Campbell <Ian.Campb= ell@citrix.com>
On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote:


> No, it doesn't work for me. There is the same error.

Hrm. Since you can reproduce would you mind experimenting a bit to figure out the correct fix for this?

Perhaps adding -Wno-unused-result to C flags helps (google suggests it
may not)?
Yes, I add this option to Makefile. And now = it works well. The patch is as the following. Thank you very much.

<= br>diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile
--- a/tools/blkta= p2/drivers/Makefile=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0200
+++ b/tools/blktap2/drivers/Makefile=A0=A0=A0 Sat May 12 00:31:12 2012 +080= 0
@@ -11,6 +11,7 @@
=A0
=A0CFLAGS=A0=A0=A0 +=3D -Werror -g
=A0C= FLAGS=A0=A0=A0 +=3D -Wno-unused
+CFLAGS=A0=A0=A0 +=3D -Wno-unused-result=
=A0CFLAGS=A0=A0=A0 +=3D -fno-strict-aliasing
=A0CFLAGS=A0=A0=A0 +=3D -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers=A0CFLAGS=A0=A0=A0 +=3D $(CFLAGS_libxenctrl)




Thanks,Bei Guan



=A0

Or maybe just assigning to a dummy variable.

Ian.

> My environment and gcc version are like this:
>
> root@gavin-desktop:~# uname -a
> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC<= br> > 2011 x86_64 GNU/Linux
>
> root@gavin-desktop:~# gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu > 4.4.3-4ubuntu5'
> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext<= br> > --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4=
> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu
> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric
> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu
> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>
>
>
>
> Thanks,
> Bei Guan
>
>
>
>
>
> =A0 =A0 =A0 =A0 8<-------------------------------------------------= -----
>
> =A0 =A0 =A0 =A0 # HG changeset patch
> =A0 =A0 =A0 =A0 # User Ian Campbell <ian.campbell@citrix.com>
> =A0 =A0 =A0 =A0 # Date 1336751175 -3600
> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99
> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 > =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build failu= res.
>
> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these cal= lers of
> =A0 =A0 =A0 =A0 read/write have any
> =A0 =A0 =A0 =A0 other error handling and return void themselves (for s= everal
> =A0 =A0 =A0 =A0 links up the call
> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want to g= et into a
> =A0 =A0 =A0 =A0 massive reworking
> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic
>
> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 = Fri May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 = Fri May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511));<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n&= #39;, wsize - size);
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize);=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;
>
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fr= i May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fr= i May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueu= e *que
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTF= D)
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &= amp;val, sizeof(val));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event= _fd, &val, sizeof(val));
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0static void
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fr= i May 11
> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fr= i May 11
> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct t= apdisk
> =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy;
>
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, = sizeof(dummy));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &d= ummy, sizeof(dummy));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0;
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tap= disk_s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) {
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WR= ITE], &dummy,
> =A0 =A0 =A0 =A0 sizeof(dummy));
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[P= OLL_WRITE], &dummy,
> =A0 =A0 =A0 =A0 sizeof(dummy));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struc= t tapd
> =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned
> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->= vbd->ring.vstart,
> =A0 =A0 =A0 =A0 idx, 0);
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs &= lt;< SECTOR_SHIFT);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->= secs <<
> =A0 =A0 =A0 =A0 SECTOR_SHIFT);
> =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0static void
> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c
> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 1= 6:19:16
> =A0 =A0 =A0 =A0 2012 +0100
> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 1= 6:46:15
> =A0 =A0 =A0 =A0 2012 +0100
> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[])
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL);=
>
> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/");
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) {
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to = chdir(/): %d\n", errno);
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2&qu= ot;);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init();
>
>
>
>
>
> --
> Best Regards,
> Bei Guan
>





--
Best Regard= s,
Bei Guan

--f46d042f9cd862e76e04bfc54a97-- --===============3953058332252177758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3953058332252177758==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:35:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:35:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsns-0001GJ-1M; Fri, 11 May 2012 16:34:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsnq-0001G4-IL for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:34:50 +0000 Received: from [193.109.254.147:42585] by server-7.bemta-14.messagelabs.com id 63/59-01627-9AF3DAF4; Fri, 11 May 2012 16:34:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336754089!1135476!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29065 invoked from network); 11 May 2012 16:34:49 -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; 11 May 2012 16:34:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434488" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16: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; Fri, 11 May 2012 17:34:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsno-0007qO-Kz; Fri, 11 May 2012 16:34:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsno-00027y-K5; Fri, 11 May 2012 17:34:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16296.528441.70516@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:34:48 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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] xl: Some clean-up X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH 0 of 3] xl: Some clean-up"): > xl: Some clean-up > > * Use libxl_device_pci_init instead of memset > * Call xlu_cfg_destroy when necessary > > Signed-off-by: George Dunlap Acked-by: Ian Jackson Committed-by: Ian Jackson All 3. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:35:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:35:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsns-0001GJ-1M; Fri, 11 May 2012 16:34:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsnq-0001G4-IL for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:34:50 +0000 Received: from [193.109.254.147:42585] by server-7.bemta-14.messagelabs.com id 63/59-01627-9AF3DAF4; Fri, 11 May 2012 16:34:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336754089!1135476!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29065 invoked from network); 11 May 2012 16:34:49 -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; 11 May 2012 16:34:49 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434488" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16: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; Fri, 11 May 2012 17:34:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsno-0007qO-Kz; Fri, 11 May 2012 16:34:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsno-00027y-K5; Fri, 11 May 2012 17:34:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16296.528441.70516@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:34:48 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: 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] xl: Some clean-up X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH 0 of 3] xl: Some clean-up"): > xl: Some clean-up > > * Use libxl_device_pci_init instead of memset > * Call xlu_cfg_destroy when necessary > > Signed-off-by: George Dunlap Acked-by: Ian Jackson Committed-by: Ian Jackson All 3. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:40:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSssk-0001hd-Hr; Fri, 11 May 2012 16:39:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSssi-0001hO-Kj for xen-devel@lists.xen.org; Fri, 11 May 2012 16:39:52 +0000 Received: from [85.158.143.35:25327] by server-2.bemta-4.messagelabs.com id E0/E8-17550-7D04DAF4; Fri, 11 May 2012 16:39:51 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336754390!11803037!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6653 invoked from network); 11 May 2012 16:39:51 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:39:51 -0000 Received: by lbok6 with SMTP id k6so2534486lbo.32 for ; Fri, 11 May 2012 09:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zub9VehM83osA7BkyyiI6uoZzjLtWtHQu74ltdBg08o=; b=MjoTKuSDZhilnp4OprXN5qefMOM7jgfPlpaPXtpmNCGi6HRARxLX5FRPm4aIazR2TL nDlzskWnSQdmgGgzs+0sUkUCFR50bMqyPkuUXKflF0aAUq8Mf2ZE4sUXkT2iiB++r4gM ZvYvOr96xAvhhhBC5Z8siQ2ILOc40ibdLi/A8ez6feabI0uue//lZjMo83H98k8O13Hc 1nO8GWcWWQ6lz/NGY54FQC4yTO9OEA0349cnBZ3hWkO1h0nbbcxcjsvj6CmwyFxssmhR MYDikRU9b1BYGZVnNyEL9nrXvJBfyiYh+TikSoM5+UwxeSP6uaMH50dJEYDFHmh1lPNU 4dPw== MIME-Version: 1.0 Received: by 10.112.86.71 with SMTP id n7mr3918968lbz.33.1336754390325; Fri, 11 May 2012 09:39:50 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:39:50 -0700 (PDT) Date: Sat, 12 May 2012 00:39:50 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2444773774503096737==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2444773774503096737== Content-Type: multipart/alternative; boundary=bcaec554e116965b0704bfc56297 --bcaec554e116965b0704bfc56297 Content-Type: text/plain; charset=ISO-8859-1 Hi, When I do "xl list", there is an error like this: root@gavin-desktop:~# xl list xl: error while loading shared libraries: libyajl.so.2: cannot open shared object file: No such file or directory I install the yajl followed this message: http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html After that, the module libyajl.so.2 is copied to /usr/local/lib/. Is there any advice on this problem. Thank you so much. Best Regards, Bei Guan --bcaec554e116965b0704bfc56297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

When I do "xl list", there is an error like this:
<= br>root@gavin-desktop:~# xl list
xl: error while loading shared librarie= s: libyajl.so.2: cannot open shared object file: No such file or directory<= br clear=3D"all">
I install the yajl followed this message:
http://lists.xen.org/a= rchives/html/xen-users/2012-03/msg00325.html

After that, the mod= ule libyajl.so.2 is copied to /usr/local/lib/.

Is there any advice on this problem. Thank you so much.


Best= Regards,
Bei Guan

--bcaec554e116965b0704bfc56297-- --===============2444773774503096737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2444773774503096737==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:40:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSssk-0001hd-Hr; Fri, 11 May 2012 16:39:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSssi-0001hO-Kj for xen-devel@lists.xen.org; Fri, 11 May 2012 16:39:52 +0000 Received: from [85.158.143.35:25327] by server-2.bemta-4.messagelabs.com id E0/E8-17550-7D04DAF4; Fri, 11 May 2012 16:39:51 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1336754390!11803037!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6653 invoked from network); 11 May 2012 16:39:51 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:39:51 -0000 Received: by lbok6 with SMTP id k6so2534486lbo.32 for ; Fri, 11 May 2012 09:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zub9VehM83osA7BkyyiI6uoZzjLtWtHQu74ltdBg08o=; b=MjoTKuSDZhilnp4OprXN5qefMOM7jgfPlpaPXtpmNCGi6HRARxLX5FRPm4aIazR2TL nDlzskWnSQdmgGgzs+0sUkUCFR50bMqyPkuUXKflF0aAUq8Mf2ZE4sUXkT2iiB++r4gM ZvYvOr96xAvhhhBC5Z8siQ2ILOc40ibdLi/A8ez6feabI0uue//lZjMo83H98k8O13Hc 1nO8GWcWWQ6lz/NGY54FQC4yTO9OEA0349cnBZ3hWkO1h0nbbcxcjsvj6CmwyFxssmhR MYDikRU9b1BYGZVnNyEL9nrXvJBfyiYh+TikSoM5+UwxeSP6uaMH50dJEYDFHmh1lPNU 4dPw== MIME-Version: 1.0 Received: by 10.112.86.71 with SMTP id n7mr3918968lbz.33.1336754390325; Fri, 11 May 2012 09:39:50 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:39:50 -0700 (PDT) Date: Sat, 12 May 2012 00:39:50 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2444773774503096737==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2444773774503096737== Content-Type: multipart/alternative; boundary=bcaec554e116965b0704bfc56297 --bcaec554e116965b0704bfc56297 Content-Type: text/plain; charset=ISO-8859-1 Hi, When I do "xl list", there is an error like this: root@gavin-desktop:~# xl list xl: error while loading shared libraries: libyajl.so.2: cannot open shared object file: No such file or directory I install the yajl followed this message: http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html After that, the module libyajl.so.2 is copied to /usr/local/lib/. Is there any advice on this problem. Thank you so much. Best Regards, Bei Guan --bcaec554e116965b0704bfc56297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

When I do "xl list", there is an error like this:
<= br>root@gavin-desktop:~# xl list
xl: error while loading shared librarie= s: libyajl.so.2: cannot open shared object file: No such file or directory<= br clear=3D"all">
I install the yajl followed this message:
http://lists.xen.org/a= rchives/html/xen-users/2012-03/msg00325.html

After that, the mod= ule libyajl.so.2 is copied to /usr/local/lib/.

Is there any advice on this problem. Thank you so much.


Best= Regards,
Bei Guan

--bcaec554e116965b0704bfc56297-- --===============2444773774503096737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2444773774503096737==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:43:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:43:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsvu-00021b-VB; Fri, 11 May 2012 16:43:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsvt-00021I-I5 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:43:09 +0000 Received: from [85.158.143.35:37283] by server-3.bemta-4.messagelabs.com id DC/E0-05853-C914DAF4; Fri, 11 May 2012 16:43:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336754588!8448448!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9834 invoked from network); 11 May 2012 16:43:08 -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; 11 May 2012 16:43:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434714" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:43:07 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:43:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsvr-0007tE-83; Fri, 11 May 2012 16:43:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsvr-00029R-5s; Fri, 11 May 2012 17:43:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16795.166767.442835@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:43:07 +0100 To: Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335487527.4742.19.camel@goosenl-desktop> References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6> <4F992DCF0200007800080283@nat28.tlf.novell.com> <1335432002.28015.78.camel@zakaz.uk.xensource.com> <1335433871.4742.18.camel@goosenl-desktop> <1335487527.4742.19.camel@goosenl-desktop> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel , Ian Campbell , Jan Beulich , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"): > readnote: Add bzImage kernel support I tried to apply this but I'm afraid it no longer applies to xen-unstable tip: patching file tools/xcutils/readnotes.c Hunk #1 FAILED at 17 Hunk #3 FAILED at 161 2 out of 3 hunks FAILED -- saving rejects to file tools/xcutils/readnotes.c.rej abort: patch failed to apply Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:43:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:43:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsvu-00021b-VB; Fri, 11 May 2012 16:43:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsvt-00021I-I5 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:43:09 +0000 Received: from [85.158.143.35:37283] by server-3.bemta-4.messagelabs.com id DC/E0-05853-C914DAF4; Fri, 11 May 2012 16:43:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336754588!8448448!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9834 invoked from network); 11 May 2012 16:43:08 -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; 11 May 2012 16:43:08 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434714" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:43:07 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:43:07 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSsvr-0007tE-83; Fri, 11 May 2012 16:43:07 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSsvr-00029R-5s; Fri, 11 May 2012 17:43:07 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.16795.166767.442835@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:43:07 +0100 To: Newsgroups: chiark.mail.xen.devel In-Reply-To: <1335487527.4742.19.camel@goosenl-desktop> References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6> <4F992DCF0200007800080283@nat28.tlf.novell.com> <1335432002.28015.78.camel@zakaz.uk.xensource.com> <1335433871.4742.18.camel@goosenl-desktop> <1335487527.4742.19.camel@goosenl-desktop> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel , Ian Campbell , Jan Beulich , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"): > readnote: Add bzImage kernel support I tried to apply this but I'm afraid it no longer applies to xen-unstable tip: patching file tools/xcutils/readnotes.c Hunk #1 FAILED at 17 Hunk #3 FAILED at 161 2 out of 3 hunks FAILED -- saving rejects to file tools/xcutils/readnotes.c.rej abort: patch failed to apply Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:44:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:44:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsxC-0002Gs-6K; Fri, 11 May 2012 16:44:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsxA-0002GL-T0 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:44:29 +0000 Received: from [85.158.143.99:10545] by server-2.bemta-4.messagelabs.com id 7F/2F-17550-BE14DAF4; Fri, 11 May 2012 16:44:27 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336754665!22270800!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14032 invoked from network); 11 May 2012 16:44:26 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:44:26 -0000 Received: by wgbed3 with SMTP id ed3so2219642wgb.32 for ; Fri, 11 May 2012 09:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; bh=OE2Edwa8gkqiXGFiWRRWiZ/rzbdm54rvVdgqMaifwbg=; b=zVinpqtvpUUyPbW/fCkdwJzbBEXZwEHkZRqHxsMnXQRWqc55vVgGloR5AU8EarKFlE 1FtgVHKwastmnCvGk49JXouG9O3E6/JjNkQHtr995ObxqhlQDgvzm9WAbcJ9+T4zwNdz IPhxgin6IKaARuB9aI+rXNucOEs9nkXi/laRlu8vlve4Gz/CCixSPX4pQRk1jOmGif/y TG05KOs77IYiSGKOBzeOV1ht8PcY+JYsnuJS34/IfKjtcc1aRrM8a4fW6ijWkSGxWqR9 u+LuIzpII5D7l2EjLmxNktSrWqqSrDI6ct/bHHjDNQ2O5wt4okykJrHyTVQjljEbGOBD sUng== Received: by 10.216.135.223 with SMTP id u73mr1934357wei.117.1336754665284; Fri, 11 May 2012 09:44:25 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id r2sm18768117wif.7.2012.05.11.09.44.22 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:44:24 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:44:16 +0100 From: Keir Fraser To: Ian Campbell , Bei Guan Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vlU14GmwR9Yyd80WCCADPrUGjUA== In-Reply-To: <1336753463.23818.131.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3419603063_121100067" Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3419603063_121100067 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 11/05/2012 17:24, "Ian Campbell" wrote: > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > >> No, it doesn't work for me. There is the same error. > > Hrm. Since you can reproduce would you mind experimenting a bit to > figure out the correct fix for this? > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > may not)? > > Or maybe just assigning to a dummy variable. Bei, Please try the attached patch. -- Keir > Ian. > >> My environment and gcc version are like this: >> >> root@gavin-desktop:~# uname -a >> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC >> 2011 x86_64 GNU/Linux >> >> root@gavin-desktop:~# gcc -v >> Using built-in specs. >> Target: x86_64-linux-gnu >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu >> 4.4.3-4ubuntu5' >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr >> --enable-shared --enable-multiarch --enable-linker-build-id >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu >> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc >> --disable-werror --with-arch-32=i486 --with-tune=generic >> --enable-checking=release --build=x86_64-linux-gnu >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu >> Thread model: posix >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) >> >> >> >> >> Thanks, >> Bei Guan >> >> >> >> >> >> 8<------------------------------------------------------ >> >> # HG changeset patch >> # User Ian Campbell >> # Date 1336751175 -3600 >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 >> blktap: avoid attribute warn_unused_result build failures. >> >> I'm not proud of this, but since none of these callers of >> read/write have any >> other error handling and return void themselves (for several >> links up the call >> chain AFAICT) and because I don't really want to get into a >> massive reworking >> of blktap2 I suppose it is at least pragmatic >> >> Signed-off-by: Ian Campbell >> >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-log.c >> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -247,7 +247,7 @@ tlog_flush(void) >> wsize = ((size + 511) & (~511)); >> >> memset(tapdisk_log.buf + size, '\n', wsize - size); >> - write(fd, tapdisk_log.buf, wsize); >> + (void)write(fd, tapdisk_log.buf, wsize); >> >> tapdisk_log.p = tapdisk_log.buf; >> >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-queue.c >> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que >> uint64_t val; >> >> if (lio->flags & LIO_FLAG_EVENTFD) >> - read(lio->event_fd, &val, sizeof(val)); >> + (void)read(lio->event_fd, &val, sizeof(val)); >> } >> >> static void >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-stream.c >> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk >> { >> int dummy; >> >> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> p->set = 0; >> } >> >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s >> int dummy = 0; >> >> if (!p->set) { >> - write(p->pipe[POLL_WRITE], &dummy, >> sizeof(dummy)); >> + (void)write(p->pipe[POLL_WRITE], &dummy, >> sizeof(dummy)); >> p->set = 1; >> } >> } >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd >> { >> unsigned long idx = (unsigned >> long)tapdisk_stream_request_idx(s, sreq); >> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, >> idx, 0); >> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> + (void)write(s->out_fd, buf, sreq->secs << >> SECTOR_SHIFT); >> } >> >> static void >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk2.c >> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 >> 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 >> 2012 +0100 >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> if (optind != argc) >> usage(argv[0], EINVAL); >> >> - chdir("/"); >> + if (chdir("/")) { >> + DPRINTF("failed to chdir(/): %d\n", errno); >> + err = 1; >> + goto out; >> + } >> + >> tapdisk_start_logging("tapdisk2"); >> >> err = tapdisk_server_init(); >> >> >> >> >> >> -- >> Best Regards, >> Bei Guan >> > > --B_3419603063_121100067 Content-type: application/octet-stream; name="00-tapdisk-check-io-result" Content-disposition: attachment; filename="00-tapdisk-check-io-result" Content-transfer-encoding: base64 ZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stZGlm Zi5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpZmYuYwlGcmkgTWF5 IDExIDEyOjIwOjQzIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stZGlmZi5jCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiArMDEwMApAQCAtMzksNiAr MzksNyBAQAogI2luY2x1ZGUgInRhcGRpc2stdmJkLmgiCiAjaW5jbHVkZSAidGFwZGlzay1z ZXJ2ZXIuaCIKICNpbmNsdWRlICJ0YXBkaXNrLWRpc2t0eXBlLmgiCisjaW5jbHVkZSAidGFw ZGlzay11dGlscy5oIgogI2luY2x1ZGUgImxpYnZoZC5oIgogCiAjZGVmaW5lIFBPTExfUkVB RCAgICAgICAgICAgICAgICAgICAgICAgIDAKQEAgLTE3MCw3ICsxNzEsNyBAQCB0YXBkaXNr X3N0cmVhbV9wb2xsX2NsZWFyKHN0cnVjdCB0YXBkaXNrCiB7CiAJaW50IGR1bW15OwogCi0J cmVhZChwLT5waXBlW1BPTExfUkVBRF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CisJcmVh ZF9leGFjdChwLT5waXBlW1BPTExfUkVBRF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CiAJ cC0+c2V0ID0gMDsKIH0KIApAQCAtMTgwLDcgKzE4MSw3IEBAIHRhcGRpc2tfc3RyZWFtX3Bv bGxfc2V0KHN0cnVjdCB0YXBkaXNrX3MKIAlpbnQgZHVtbXkgPSAwOwogCiAJaWYgKCFwLT5z ZXQpIHsKLQkJd3JpdGUocC0+cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVt bXkpKTsKKwkJd3JpdGVfZXhhY3QocC0+cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXpl b2YoZHVtbXkpKTsKIAkJcC0+c2V0ID0gMTsKIAl9CiB9CmRpZmYgLXIgYWY2ZDI0ZDQ3YjU2 IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWxvZy5jCi0tLSBhL3Rvb2xzL2Jsa3Rh cDIvZHJpdmVycy90YXBkaXNrLWxvZy5jCUZyaSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEw MAorKysgYi90b29scy9ibGt0YXAyL2RyaXZlcnMvdGFwZGlzay1sb2cuYwlGcmkgTWF5IDEx IDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAgLTM3LDYgKzM3LDcgQEAKICNpbmNsdWRlIDxzeXMv dGltZS5oPgogCiAjaW5jbHVkZSAidGFwZGlzay1sb2cuaCIKKyNpbmNsdWRlICJ0YXBkaXNr LXV0aWxzLmgiCiAKICNkZWZpbmUgTUFYX0VOVFJZX0xFTiAgICAgIDUxMgogI2RlZmluZSBN QVhfRVJST1JfTUVTU0FHRVMgMTYKQEAgLTI0Nyw3ICsyNDgsNyBAQCB0bG9nX2ZsdXNoKHZv aWQpCiAJd3NpemUgPSAoKHNpemUgKyA1MTEpICYgKH41MTEpKTsKIAogCW1lbXNldCh0YXBk aXNrX2xvZy5idWYgKyBzaXplLCAnXG4nLCB3c2l6ZSAtIHNpemUpOwotCXdyaXRlKGZkLCB0 YXBkaXNrX2xvZy5idWYsIHdzaXplKTsKKwl3cml0ZV9leGFjdChmZCwgdGFwZGlza19sb2cu YnVmLCB3c2l6ZSk7CiAKIAl0YXBkaXNrX2xvZy5wID0gdGFwZGlza19sb2cuYnVmOwogCmRp ZmYgLXIgYWY2ZDI0ZDQ3YjU2IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXF1ZXVl LmMKLS0tIGEvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stcXVldWUuYwlGcmkgTWF5 IDExIDEyOjIwOjQzIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stcXVldWUuYwlGcmkgTWF5IDExIDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAgLTQzNSw3 ICs0MzUsNyBAQCB0YXBkaXNrX2xpb19hY2tfZXZlbnQoc3RydWN0IHRxdWV1ZSAqcXVlCiAJ dWludDY0X3QgdmFsOwogCiAJaWYgKGxpby0+ZmxhZ3MgJiBMSU9fRkxBR19FVkVOVEZEKQot CQlyZWFkKGxpby0+ZXZlbnRfZmQsICZ2YWwsIHNpemVvZih2YWwpKTsKKwkJcmVhZF9leGFj dChsaW8tPmV2ZW50X2ZkLCAmdmFsLCBzaXplb2YodmFsKSk7CiB9CiAKIHN0YXRpYyB2b2lk CmRpZmYgLXIgYWY2ZDI0ZDQ3YjU2IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXN0 cmVhbS5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXN0cmVhbS5jCUZy aSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAyL2RyaXZl cnMvdGFwZGlzay1zdHJlYW0uYwlGcmkgTWF5IDExIDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAg LTM4LDYgKzM4LDcgQEAKICNpbmNsdWRlICJ0YXBkaXNrLXZiZC5oIgogI2luY2x1ZGUgInRh cGRpc2stc2VydmVyLmgiCiAjaW5jbHVkZSAidGFwZGlzay1kaXNrdHlwZS5oIgorI2luY2x1 ZGUgInRhcGRpc2stdXRpbHMuaCIKIAogI2RlZmluZSBQT0xMX1JFQUQgICAgICAgICAgICAg ICAgICAgICAgICAwCiAjZGVmaW5lIFBPTExfV1JJVEUgICAgICAgICAgICAgICAgICAgICAg IDEKQEAgLTE0NSw3ICsxNDYsNyBAQCB0YXBkaXNrX3N0cmVhbV9wb2xsX2NsZWFyKHN0cnVj dCB0YXBkaXNrCiB7CiAJaW50IGR1bW15OwogCi0JcmVhZChwLT5waXBlW1BPTExfUkVBRF0s ICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CisJcmVhZF9leGFjdChwLT5waXBlW1BPTExfUkVB RF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CiAJcC0+c2V0ID0gMDsKIH0KIApAQCAtMTU1 LDcgKzE1Niw3IEBAIHRhcGRpc2tfc3RyZWFtX3BvbGxfc2V0KHN0cnVjdCB0YXBkaXNrX3MK IAlpbnQgZHVtbXkgPSAwOwogCiAJaWYgKCFwLT5zZXQpIHsKLQkJd3JpdGUocC0+cGlwZVtQ T0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVtbXkpKTsKKwkJd3JpdGVfZXhhY3QocC0+ cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVtbXkpKTsKIAkJcC0+c2V0ID0g MTsKIAl9CiB9CkBAIC0yMDMsNyArMjA0LDcgQEAgdGFwZGlza19zdHJlYW1fcHJpbnRfcmVx dWVzdChzdHJ1Y3QgdGFwZAogewogCXVuc2lnbmVkIGxvbmcgaWR4ID0gKHVuc2lnbmVkIGxv bmcpdGFwZGlza19zdHJlYW1fcmVxdWVzdF9pZHgocywgc3JlcSk7CiAJY2hhciAqYnVmID0g KGNoYXIgKilNTUFQX1ZBRERSKHMtPnZiZC0+cmluZy52c3RhcnQsIGlkeCwgMCk7Ci0Jd3Jp dGUocy0+b3V0X2ZkLCBidWYsIHNyZXEtPnNlY3MgPDwgU0VDVE9SX1NISUZUKTsKKwl3cml0 ZV9leGFjdChzLT5vdXRfZmQsIGJ1Ziwgc3JlcS0+c2VjcyA8PCBTRUNUT1JfU0hJRlQpOwog fQogCiBzdGF0aWMgdm9pZApkaWZmIC1yIGFmNmQyNGQ0N2I1NiB0b29scy9ibGt0YXAyL2Ry aXZlcnMvdGFwZGlzay11dGlscy5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBk aXNrLXV0aWxzLmMJRnJpIE1heSAxMSAxMjoyMDo0MyAyMDEyICswMTAwCisrKyBiL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXV0aWxzLmMJRnJpIE1heSAxMSAxNzo0Mzo0NyAy MDEyICswMTAwCkBAIC0xNzUsMyArMTc1LDQwIEBAIGludCB0YXBkaXNrX2xpbnV4X3ZlcnNp b24odm9pZCkKIH0KIAogI2VuZGlmCitpbnQgcmVhZF9leGFjdChpbnQgZmQsIHZvaWQgKmRh dGEsIHNpemVfdCBzaXplKQoreworICAgIHNpemVfdCBvZmZzZXQgPSAwOworICAgIHNzaXpl X3QgbGVuOworCisgICAgd2hpbGUgKCBvZmZzZXQgPCBzaXplICkKKyAgICB7CisgICAgICAg IGxlbiA9IHJlYWQoZmQsIChjaGFyICopZGF0YSArIG9mZnNldCwgc2l6ZSAtIG9mZnNldCk7 CisgICAgICAgIGlmICggKGxlbiA9PSAtMSkgJiYgKGVycm5vID09IEVJTlRSKSApCisgICAg ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgaWYgKCBsZW4gPT0gMCApCisgICAgICAgICAg ICBlcnJubyA9IDA7CisgICAgICAgIGlmICggbGVuIDw9IDAgKQorICAgICAgICAgICAgcmV0 dXJuIC0xOworICAgICAgICBvZmZzZXQgKz0gbGVuOworICAgIH0KKworICAgIHJldHVybiAw OworfQorCitpbnQgd3JpdGVfZXhhY3QoaW50IGZkLCBjb25zdCB2b2lkICpkYXRhLCBzaXpl X3Qgc2l6ZSkKK3sKKyAgICBzaXplX3Qgb2Zmc2V0ID0gMDsKKyAgICBzc2l6ZV90IGxlbjsK KworICAgIHdoaWxlICggb2Zmc2V0IDwgc2l6ZSApCisgICAgeworICAgICAgICBsZW4gPSB3 cml0ZShmZCwgKGNvbnN0IGNoYXIgKilkYXRhICsgb2Zmc2V0LCBzaXplIC0gb2Zmc2V0KTsK KyAgICAgICAgaWYgKCAobGVuID09IC0xKSAmJiAoZXJybm8gPT0gRUlOVFIpICkKKyAgICAg ICAgICAgIGNvbnRpbnVlOworICAgICAgICBpZiAoIGxlbiA8PSAwICkKKyAgICAgICAgICAg IHJldHVybiAtMTsKKyAgICAgICAgb2Zmc2V0ICs9IGxlbjsKKyAgICB9CisKKyAgICByZXR1 cm4gMDsKK30KZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stdXRpbHMuaAotLS0gYS90b29scy9ibGt0YXAyL2RyaXZlcnMvdGFwZGlzay11dGls cy5oCUZyaSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAy L2RyaXZlcnMvdGFwZGlzay11dGlscy5oCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiArMDEw MApAQCAtMzksNCArMzksNyBAQCBpbnQgdGFwZGlza19uYW1lZHVwKGNoYXIgKiosIGNvbnN0 IGNoYXIgCiBpbnQgdGFwZGlza19nZXRfaW1hZ2Vfc2l6ZShpbnQsIHVpbnQ2NF90ICosIHVp bnQzMl90ICopOwogaW50IHRhcGRpc2tfbGludXhfdmVyc2lvbih2b2lkKTsKIAoraW50IHJl YWRfZXhhY3QoaW50IGZkLCB2b2lkICpkYXRhLCBzaXplX3Qgc2l6ZSk7IC8qIEVPRiA9PiAt MSwgZXJybm89MCAqLworaW50IHdyaXRlX2V4YWN0KGludCBmZCwgY29uc3Qgdm9pZCAqZGF0 YSwgc2l6ZV90IHNpemUpOworCiAjZW5kaWYKZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMv YmxrdGFwMi9kcml2ZXJzL3RhcGRpc2syLmMKLS0tIGEvdG9vbHMvYmxrdGFwMi9kcml2ZXJz L3RhcGRpc2syLmMJRnJpIE1heSAxMSAxMjoyMDo0MyAyMDEyICswMTAwCisrKyBiL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrMi5jCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiAr MDEwMApAQCAtNzksNyArNzksMTIgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQog CWlmIChvcHRpbmQgIT0gYXJnYykKIAkJdXNhZ2UoYXJndlswXSwgRUlOVkFMKTsKIAotCWNo ZGlyKCIvIik7CisJaWYgKGNoZGlyKCIvIikpIHsKKwkJRFBSSU5URigiZmFpbGVkIHRvIGNo ZGlyKC8pOiAlZFxuIiwgZXJybm8pOworCQllcnIgPSAxOworCQlnb3RvIG91dDsKKwl9CisK IAl0YXBkaXNrX3N0YXJ0X2xvZ2dpbmcoInRhcGRpc2syIik7CiAKIAllcnIgPSB0YXBkaXNr X3NlcnZlcl9pbml0KCk7Cg== --B_3419603063_121100067 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --B_3419603063_121100067-- From xen-devel-bounces@lists.xen.org Fri May 11 16:44:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:44:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsxC-0002Gs-6K; Fri, 11 May 2012 16:44:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSsxA-0002GL-T0 for xen-devel@lists.xen.org; Fri, 11 May 2012 16:44:29 +0000 Received: from [85.158.143.99:10545] by server-2.bemta-4.messagelabs.com id 7F/2F-17550-BE14DAF4; Fri, 11 May 2012 16:44:27 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1336754665!22270800!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14032 invoked from network); 11 May 2012 16:44:26 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:44:26 -0000 Received: by wgbed3 with SMTP id ed3so2219642wgb.32 for ; Fri, 11 May 2012 09:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; bh=OE2Edwa8gkqiXGFiWRRWiZ/rzbdm54rvVdgqMaifwbg=; b=zVinpqtvpUUyPbW/fCkdwJzbBEXZwEHkZRqHxsMnXQRWqc55vVgGloR5AU8EarKFlE 1FtgVHKwastmnCvGk49JXouG9O3E6/JjNkQHtr995ObxqhlQDgvzm9WAbcJ9+T4zwNdz IPhxgin6IKaARuB9aI+rXNucOEs9nkXi/laRlu8vlve4Gz/CCixSPX4pQRk1jOmGif/y TG05KOs77IYiSGKOBzeOV1ht8PcY+JYsnuJS34/IfKjtcc1aRrM8a4fW6ijWkSGxWqR9 u+LuIzpII5D7l2EjLmxNktSrWqqSrDI6ct/bHHjDNQ2O5wt4okykJrHyTVQjljEbGOBD sUng== Received: by 10.216.135.223 with SMTP id u73mr1934357wei.117.1336754665284; Fri, 11 May 2012 09:44:25 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id r2sm18768117wif.7.2012.05.11.09.44.22 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:44:24 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:44:16 +0100 From: Keir Fraser To: Ian Campbell , Bei Guan Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vlU14GmwR9Yyd80WCCADPrUGjUA== In-Reply-To: <1336753463.23818.131.camel@zakaz.uk.xensource.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3419603063_121100067" Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3419603063_121100067 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 11/05/2012 17:24, "Ian Campbell" wrote: > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > >> No, it doesn't work for me. There is the same error. > > Hrm. Since you can reproduce would you mind experimenting a bit to > figure out the correct fix for this? > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > may not)? > > Or maybe just assigning to a dummy variable. Bei, Please try the attached patch. -- Keir > Ian. > >> My environment and gcc version are like this: >> >> root@gavin-desktop:~# uname -a >> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC >> 2011 x86_64 GNU/Linux >> >> root@gavin-desktop:~# gcc -v >> Using built-in specs. >> Target: x86_64-linux-gnu >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu >> 4.4.3-4ubuntu5' >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr >> --enable-shared --enable-multiarch --enable-linker-build-id >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu >> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc >> --disable-werror --with-arch-32=i486 --with-tune=generic >> --enable-checking=release --build=x86_64-linux-gnu >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu >> Thread model: posix >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) >> >> >> >> >> Thanks, >> Bei Guan >> >> >> >> >> >> 8<------------------------------------------------------ >> >> # HG changeset patch >> # User Ian Campbell >> # Date 1336751175 -3600 >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 >> blktap: avoid attribute warn_unused_result build failures. >> >> I'm not proud of this, but since none of these callers of >> read/write have any >> other error handling and return void themselves (for several >> links up the call >> chain AFAICT) and because I don't really want to get into a >> massive reworking >> of blktap2 I suppose it is at least pragmatic >> >> Signed-off-by: Ian Campbell >> >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-log.c >> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -247,7 +247,7 @@ tlog_flush(void) >> wsize = ((size + 511) & (~511)); >> >> memset(tapdisk_log.buf + size, '\n', wsize - size); >> - write(fd, tapdisk_log.buf, wsize); >> + (void)write(fd, tapdisk_log.buf, wsize); >> >> tapdisk_log.p = tapdisk_log.buf; >> >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-queue.c >> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que >> uint64_t val; >> >> if (lio->flags & LIO_FLAG_EVENTFD) >> - read(lio->event_fd, &val, sizeof(val)); >> + (void)read(lio->event_fd, &val, sizeof(val)); >> } >> >> static void >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk-stream.c >> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 >> 16:19:16 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 >> 16:46:15 2012 +0100 >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk >> { >> int dummy; >> >> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); >> p->set = 0; >> } >> >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s >> int dummy = 0; >> >> if (!p->set) { >> - write(p->pipe[POLL_WRITE], &dummy, >> sizeof(dummy)); >> + (void)write(p->pipe[POLL_WRITE], &dummy, >> sizeof(dummy)); >> p->set = 1; >> } >> } >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd >> { >> unsigned long idx = (unsigned >> long)tapdisk_stream_request_idx(s, sreq); >> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, >> idx, 0); >> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); >> + (void)write(s->out_fd, buf, sreq->secs << >> SECTOR_SHIFT); >> } >> >> static void >> diff -r adc74e492edf -r 15ed8f45c4e5 >> tools/blktap2/drivers/tapdisk2.c >> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 >> 2012 +0100 >> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 >> 2012 +0100 >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> if (optind != argc) >> usage(argv[0], EINVAL); >> >> - chdir("/"); >> + if (chdir("/")) { >> + DPRINTF("failed to chdir(/): %d\n", errno); >> + err = 1; >> + goto out; >> + } >> + >> tapdisk_start_logging("tapdisk2"); >> >> err = tapdisk_server_init(); >> >> >> >> >> >> -- >> Best Regards, >> Bei Guan >> > > --B_3419603063_121100067 Content-type: application/octet-stream; name="00-tapdisk-check-io-result" Content-disposition: attachment; filename="00-tapdisk-check-io-result" Content-transfer-encoding: base64 ZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stZGlm Zi5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWRpZmYuYwlGcmkgTWF5 IDExIDEyOjIwOjQzIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stZGlmZi5jCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiArMDEwMApAQCAtMzksNiAr MzksNyBAQAogI2luY2x1ZGUgInRhcGRpc2stdmJkLmgiCiAjaW5jbHVkZSAidGFwZGlzay1z ZXJ2ZXIuaCIKICNpbmNsdWRlICJ0YXBkaXNrLWRpc2t0eXBlLmgiCisjaW5jbHVkZSAidGFw ZGlzay11dGlscy5oIgogI2luY2x1ZGUgImxpYnZoZC5oIgogCiAjZGVmaW5lIFBPTExfUkVB RCAgICAgICAgICAgICAgICAgICAgICAgIDAKQEAgLTE3MCw3ICsxNzEsNyBAQCB0YXBkaXNr X3N0cmVhbV9wb2xsX2NsZWFyKHN0cnVjdCB0YXBkaXNrCiB7CiAJaW50IGR1bW15OwogCi0J cmVhZChwLT5waXBlW1BPTExfUkVBRF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CisJcmVh ZF9leGFjdChwLT5waXBlW1BPTExfUkVBRF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CiAJ cC0+c2V0ID0gMDsKIH0KIApAQCAtMTgwLDcgKzE4MSw3IEBAIHRhcGRpc2tfc3RyZWFtX3Bv bGxfc2V0KHN0cnVjdCB0YXBkaXNrX3MKIAlpbnQgZHVtbXkgPSAwOwogCiAJaWYgKCFwLT5z ZXQpIHsKLQkJd3JpdGUocC0+cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVt bXkpKTsKKwkJd3JpdGVfZXhhY3QocC0+cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXpl b2YoZHVtbXkpKTsKIAkJcC0+c2V0ID0gMTsKIAl9CiB9CmRpZmYgLXIgYWY2ZDI0ZDQ3YjU2 IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLWxvZy5jCi0tLSBhL3Rvb2xzL2Jsa3Rh cDIvZHJpdmVycy90YXBkaXNrLWxvZy5jCUZyaSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEw MAorKysgYi90b29scy9ibGt0YXAyL2RyaXZlcnMvdGFwZGlzay1sb2cuYwlGcmkgTWF5IDEx IDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAgLTM3LDYgKzM3LDcgQEAKICNpbmNsdWRlIDxzeXMv dGltZS5oPgogCiAjaW5jbHVkZSAidGFwZGlzay1sb2cuaCIKKyNpbmNsdWRlICJ0YXBkaXNr LXV0aWxzLmgiCiAKICNkZWZpbmUgTUFYX0VOVFJZX0xFTiAgICAgIDUxMgogI2RlZmluZSBN QVhfRVJST1JfTUVTU0FHRVMgMTYKQEAgLTI0Nyw3ICsyNDgsNyBAQCB0bG9nX2ZsdXNoKHZv aWQpCiAJd3NpemUgPSAoKHNpemUgKyA1MTEpICYgKH41MTEpKTsKIAogCW1lbXNldCh0YXBk aXNrX2xvZy5idWYgKyBzaXplLCAnXG4nLCB3c2l6ZSAtIHNpemUpOwotCXdyaXRlKGZkLCB0 YXBkaXNrX2xvZy5idWYsIHdzaXplKTsKKwl3cml0ZV9leGFjdChmZCwgdGFwZGlza19sb2cu YnVmLCB3c2l6ZSk7CiAKIAl0YXBkaXNrX2xvZy5wID0gdGFwZGlza19sb2cuYnVmOwogCmRp ZmYgLXIgYWY2ZDI0ZDQ3YjU2IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXF1ZXVl LmMKLS0tIGEvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3RhcGRpc2stcXVldWUuYwlGcmkgTWF5 IDExIDEyOjIwOjQzIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stcXVldWUuYwlGcmkgTWF5IDExIDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAgLTQzNSw3 ICs0MzUsNyBAQCB0YXBkaXNrX2xpb19hY2tfZXZlbnQoc3RydWN0IHRxdWV1ZSAqcXVlCiAJ dWludDY0X3QgdmFsOwogCiAJaWYgKGxpby0+ZmxhZ3MgJiBMSU9fRkxBR19FVkVOVEZEKQot CQlyZWFkKGxpby0+ZXZlbnRfZmQsICZ2YWwsIHNpemVvZih2YWwpKTsKKwkJcmVhZF9leGFj dChsaW8tPmV2ZW50X2ZkLCAmdmFsLCBzaXplb2YodmFsKSk7CiB9CiAKIHN0YXRpYyB2b2lk CmRpZmYgLXIgYWY2ZDI0ZDQ3YjU2IHRvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXN0 cmVhbS5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXN0cmVhbS5jCUZy aSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAyL2RyaXZl cnMvdGFwZGlzay1zdHJlYW0uYwlGcmkgTWF5IDExIDE3OjQzOjQ3IDIwMTIgKzAxMDAKQEAg LTM4LDYgKzM4LDcgQEAKICNpbmNsdWRlICJ0YXBkaXNrLXZiZC5oIgogI2luY2x1ZGUgInRh cGRpc2stc2VydmVyLmgiCiAjaW5jbHVkZSAidGFwZGlzay1kaXNrdHlwZS5oIgorI2luY2x1 ZGUgInRhcGRpc2stdXRpbHMuaCIKIAogI2RlZmluZSBQT0xMX1JFQUQgICAgICAgICAgICAg ICAgICAgICAgICAwCiAjZGVmaW5lIFBPTExfV1JJVEUgICAgICAgICAgICAgICAgICAgICAg IDEKQEAgLTE0NSw3ICsxNDYsNyBAQCB0YXBkaXNrX3N0cmVhbV9wb2xsX2NsZWFyKHN0cnVj dCB0YXBkaXNrCiB7CiAJaW50IGR1bW15OwogCi0JcmVhZChwLT5waXBlW1BPTExfUkVBRF0s ICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CisJcmVhZF9leGFjdChwLT5waXBlW1BPTExfUkVB RF0sICZkdW1teSwgc2l6ZW9mKGR1bW15KSk7CiAJcC0+c2V0ID0gMDsKIH0KIApAQCAtMTU1 LDcgKzE1Niw3IEBAIHRhcGRpc2tfc3RyZWFtX3BvbGxfc2V0KHN0cnVjdCB0YXBkaXNrX3MK IAlpbnQgZHVtbXkgPSAwOwogCiAJaWYgKCFwLT5zZXQpIHsKLQkJd3JpdGUocC0+cGlwZVtQ T0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVtbXkpKTsKKwkJd3JpdGVfZXhhY3QocC0+ cGlwZVtQT0xMX1dSSVRFXSwgJmR1bW15LCBzaXplb2YoZHVtbXkpKTsKIAkJcC0+c2V0ID0g MTsKIAl9CiB9CkBAIC0yMDMsNyArMjA0LDcgQEAgdGFwZGlza19zdHJlYW1fcHJpbnRfcmVx dWVzdChzdHJ1Y3QgdGFwZAogewogCXVuc2lnbmVkIGxvbmcgaWR4ID0gKHVuc2lnbmVkIGxv bmcpdGFwZGlza19zdHJlYW1fcmVxdWVzdF9pZHgocywgc3JlcSk7CiAJY2hhciAqYnVmID0g KGNoYXIgKilNTUFQX1ZBRERSKHMtPnZiZC0+cmluZy52c3RhcnQsIGlkeCwgMCk7Ci0Jd3Jp dGUocy0+b3V0X2ZkLCBidWYsIHNyZXEtPnNlY3MgPDwgU0VDVE9SX1NISUZUKTsKKwl3cml0 ZV9leGFjdChzLT5vdXRfZmQsIGJ1Ziwgc3JlcS0+c2VjcyA8PCBTRUNUT1JfU0hJRlQpOwog fQogCiBzdGF0aWMgdm9pZApkaWZmIC1yIGFmNmQyNGQ0N2I1NiB0b29scy9ibGt0YXAyL2Ry aXZlcnMvdGFwZGlzay11dGlscy5jCi0tLSBhL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy90YXBk aXNrLXV0aWxzLmMJRnJpIE1heSAxMSAxMjoyMDo0MyAyMDEyICswMTAwCisrKyBiL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrLXV0aWxzLmMJRnJpIE1heSAxMSAxNzo0Mzo0NyAy MDEyICswMTAwCkBAIC0xNzUsMyArMTc1LDQwIEBAIGludCB0YXBkaXNrX2xpbnV4X3ZlcnNp b24odm9pZCkKIH0KIAogI2VuZGlmCitpbnQgcmVhZF9leGFjdChpbnQgZmQsIHZvaWQgKmRh dGEsIHNpemVfdCBzaXplKQoreworICAgIHNpemVfdCBvZmZzZXQgPSAwOworICAgIHNzaXpl X3QgbGVuOworCisgICAgd2hpbGUgKCBvZmZzZXQgPCBzaXplICkKKyAgICB7CisgICAgICAg IGxlbiA9IHJlYWQoZmQsIChjaGFyICopZGF0YSArIG9mZnNldCwgc2l6ZSAtIG9mZnNldCk7 CisgICAgICAgIGlmICggKGxlbiA9PSAtMSkgJiYgKGVycm5vID09IEVJTlRSKSApCisgICAg ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgaWYgKCBsZW4gPT0gMCApCisgICAgICAgICAg ICBlcnJubyA9IDA7CisgICAgICAgIGlmICggbGVuIDw9IDAgKQorICAgICAgICAgICAgcmV0 dXJuIC0xOworICAgICAgICBvZmZzZXQgKz0gbGVuOworICAgIH0KKworICAgIHJldHVybiAw OworfQorCitpbnQgd3JpdGVfZXhhY3QoaW50IGZkLCBjb25zdCB2b2lkICpkYXRhLCBzaXpl X3Qgc2l6ZSkKK3sKKyAgICBzaXplX3Qgb2Zmc2V0ID0gMDsKKyAgICBzc2l6ZV90IGxlbjsK KworICAgIHdoaWxlICggb2Zmc2V0IDwgc2l6ZSApCisgICAgeworICAgICAgICBsZW4gPSB3 cml0ZShmZCwgKGNvbnN0IGNoYXIgKilkYXRhICsgb2Zmc2V0LCBzaXplIC0gb2Zmc2V0KTsK KyAgICAgICAgaWYgKCAobGVuID09IC0xKSAmJiAoZXJybm8gPT0gRUlOVFIpICkKKyAgICAg ICAgICAgIGNvbnRpbnVlOworICAgICAgICBpZiAoIGxlbiA8PSAwICkKKyAgICAgICAgICAg IHJldHVybiAtMTsKKyAgICAgICAgb2Zmc2V0ICs9IGxlbjsKKyAgICB9CisKKyAgICByZXR1 cm4gMDsKK30KZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMvYmxrdGFwMi9kcml2ZXJzL3Rh cGRpc2stdXRpbHMuaAotLS0gYS90b29scy9ibGt0YXAyL2RyaXZlcnMvdGFwZGlzay11dGls cy5oCUZyaSBNYXkgMTEgMTI6MjA6NDMgMjAxMiArMDEwMAorKysgYi90b29scy9ibGt0YXAy L2RyaXZlcnMvdGFwZGlzay11dGlscy5oCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiArMDEw MApAQCAtMzksNCArMzksNyBAQCBpbnQgdGFwZGlza19uYW1lZHVwKGNoYXIgKiosIGNvbnN0 IGNoYXIgCiBpbnQgdGFwZGlza19nZXRfaW1hZ2Vfc2l6ZShpbnQsIHVpbnQ2NF90ICosIHVp bnQzMl90ICopOwogaW50IHRhcGRpc2tfbGludXhfdmVyc2lvbih2b2lkKTsKIAoraW50IHJl YWRfZXhhY3QoaW50IGZkLCB2b2lkICpkYXRhLCBzaXplX3Qgc2l6ZSk7IC8qIEVPRiA9PiAt MSwgZXJybm89MCAqLworaW50IHdyaXRlX2V4YWN0KGludCBmZCwgY29uc3Qgdm9pZCAqZGF0 YSwgc2l6ZV90IHNpemUpOworCiAjZW5kaWYKZGlmZiAtciBhZjZkMjRkNDdiNTYgdG9vbHMv YmxrdGFwMi9kcml2ZXJzL3RhcGRpc2syLmMKLS0tIGEvdG9vbHMvYmxrdGFwMi9kcml2ZXJz L3RhcGRpc2syLmMJRnJpIE1heSAxMSAxMjoyMDo0MyAyMDEyICswMTAwCisrKyBiL3Rvb2xz L2Jsa3RhcDIvZHJpdmVycy90YXBkaXNrMi5jCUZyaSBNYXkgMTEgMTc6NDM6NDcgMjAxMiAr MDEwMApAQCAtNzksNyArNzksMTIgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQog CWlmIChvcHRpbmQgIT0gYXJnYykKIAkJdXNhZ2UoYXJndlswXSwgRUlOVkFMKTsKIAotCWNo ZGlyKCIvIik7CisJaWYgKGNoZGlyKCIvIikpIHsKKwkJRFBSSU5URigiZmFpbGVkIHRvIGNo ZGlyKC8pOiAlZFxuIiwgZXJybm8pOworCQllcnIgPSAxOworCQlnb3RvIG91dDsKKwl9CisK IAl0YXBkaXNrX3N0YXJ0X2xvZ2dpbmcoInRhcGRpc2syIik7CiAKIAllcnIgPSB0YXBkaXNr X3NlcnZlcl9pbml0KCk7Cg== --B_3419603063_121100067 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --B_3419603063_121100067-- From xen-devel-bounces@lists.xen.org Fri May 11 16:47:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSszT-0002dV-P4; Fri, 11 May 2012 16:46:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszR-0002dC-Md for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:46:49 +0000 Received: from [193.109.254.147:24355] by server-11.bemta-14.messagelabs.com id 32/09-05858-9724DAF4; Fri, 11 May 2012 16:46:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336754808!6400201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14408 invoked from network); 11 May 2012 16:46:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:46:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434764" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:46: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, 11 May 2012 17:46:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSszQ-0007uT-2y; Fri, 11 May 2012 16:46:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSszP-0002Gh-Vy; Fri, 11 May 2012 17:46:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17015.827585.110465@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:46:47 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "rshriram@cs.ubc.ca" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap"): > 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. All 3: Committed-by: Ian Jackson Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:47:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSszT-0002dV-P4; Fri, 11 May 2012 16:46:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszR-0002dC-Md for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:46:49 +0000 Received: from [193.109.254.147:24355] by server-11.bemta-14.messagelabs.com id 32/09-05858-9724DAF4; Fri, 11 May 2012 16:46:49 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336754808!6400201!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14408 invoked from network); 11 May 2012 16:46:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:46:48 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434764" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:46: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, 11 May 2012 17:46:48 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSszQ-0007uT-2y; Fri, 11 May 2012 16:46:48 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSszP-0002Gh-Vy; Fri, 11 May 2012 17:46:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17015.827585.110465@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:46:47 +0100 To: Stefano Stabellini Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "rshriram@cs.ubc.ca" , "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes ("[Xen-devel] [PATCH v8 0/3] libxl: save/restore qemu physmap"): > 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. All 3: Committed-by: Ian Jackson Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:47:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:47:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszp-0002hT-A8; Fri, 11 May 2012 16:47:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszn-0002h1-RI for xen-devel@lists.xen.org; Fri, 11 May 2012 16:47:12 +0000 Received: from [85.158.143.99:23524] by server-1.bemta-4.messagelabs.com id DA/7B-20925-F824DAF4; Fri, 11 May 2012 16:47:11 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336754829!16384923!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27056 invoked from network); 11 May 2012 16:47:10 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:47:10 -0000 Received: by wgbds1 with SMTP id ds1so1745070wgb.2 for ; Fri, 11 May 2012 09:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=edbrZzqd/ACG7JJH+W9M69GkKpw7tNzYIYciKeoHLvc=; b=Rd5V4BgNdS2Wru8qeb8bfKRorXKr3X5T7RPBSnVm/nG7PU7t1kie/HosNnhpg4jzvC KalZJILvtry1IAboc1CwW1ScH1A+ta33cKe+6/hjMHhwQliDYQ6LpiIFURnGmFhx75gG Q1s0HBVXz6loMc0LUNP+YBPZH+hTJSod42ObpfzDufQOAxwqkWmbw7hL/IpBSCRnvaHp /L5YuRZa+tpcbuzBMC/erHS1l7KXrDNhTdoYKTUSJXePTkpuOtoRAs3NYDAadjLJNwGU IM1q+EqCVYMmZC5KvtcaDc5e1vnndwrp9q/5wb2GdJ1dM9v1bR6Suht46WZkITee/5iM TkyQ== Received: by 10.180.103.42 with SMTP id ft10mr9293090wib.18.1336754829440; Fri, 11 May 2012 09:47:09 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id fm1sm11618707wib.10.2012.05.11.09.47.08 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:47:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:47:05 +0100 From: Keir Fraser To: Bei Guan , Ian Campbell Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vlbI0xEAt/6MFzUysUP6/JofztQ== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 17:33, "Bei Guan" wrote: > 2012/5/12 Ian Campbell >> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: >> = >> = >>> No, it doesn't work for me. There is the same error. >> = >> Hrm. Since you can reproduce would you mind experimenting a bit to >> figure out the correct fix for this? >> = >> Perhaps adding -Wno-unused-result to C flags helps (google suggests it >> may not)? > Yes, I add this option to Makefile. And now it works well. The patch is a= s the > following. Thank you very much. I'd be worried about more command-line meddling causing even more fallout. Particularly because we haven't used that option anywhere else so far, so it's untested by us. E.g., do all gcc support -Wno-unused-result? -- Keir > = > diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile > --- a/tools/blktap2/drivers/Makefile=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0= 200 > +++ b/tools/blktap2/drivers/Makefile=A0=A0=A0 Sat May 12 00:31:12 2012 +0= 800 > @@ -11,6 +11,7 @@ > =A0 > =A0CFLAGS=A0=A0=A0 +=3D -Werror -g > =A0CFLAGS=A0=A0=A0 +=3D -Wno-unused > +CFLAGS=A0=A0=A0 +=3D -Wno-unused-result > =A0CFLAGS=A0=A0=A0 +=3D -fno-strict-aliasing > =A0CFLAGS=A0=A0=A0 +=3D -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers > =A0CFLAGS=A0=A0=A0 +=3D $(CFLAGS_libxenctrl) > = > = > = > = > Thanks, > Bei Guan > = > = > = > =A0 >> = >> Or maybe just assigning to a dummy variable. >> = >> Ian. >> = >>> My environment and gcc version are like this: >>> = >>> root@gavin-desktop:~# uname -a >>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC >>> 2011 x86_64 GNU/Linux >>> = >>> root@gavin-desktop:~# gcc -v >>> Using built-in specs. >>> Target: x86_64-linux-gnu >>> Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu >>> 4.4.3-4ubuntu5' >>> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs >>> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr >>> --enable-shared --enable-multiarch --enable-linker-build-id >>> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext >>> --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4 >>> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu >>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc >>> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric >>> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu >>> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu >>> Thread model: posix >>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) >>> = >>> = >>> = >>> = >>> Thanks, >>> Bei Guan >>> = >>> = >>> = >>> = >>> = >>> =A0 =A0 =A0 =A0 8<------------------------------------------------------ >>> = >>> =A0 =A0 =A0 =A0 # HG changeset patch >>> =A0 =A0 =A0 =A0 # User Ian Campbell >>> =A0 =A0 =A0 =A0 # Date 1336751175 -3600 >>> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >>> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 >>> =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build failur= es. >>> = >>> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these callers = of >>> =A0 =A0 =A0 =A0 read/write have any >>> =A0 =A0 =A0 =A0 other error handling and return void themselves (for se= veral >>> =A0 =A0 =A0 =A0 links up the call >>> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want to get in= to a >>> =A0 =A0 =A0 =A0 massive reworking >>> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic >>> = >>> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell >>> = >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 F= ri May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 F= ri May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511)); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsi= ze - size); >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf; >>> = >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri= May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri= May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue= *que >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val; >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD) >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val,= sizeof(val)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd,= &val, sizeof(val)); >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 =A0static void >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri= May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri= May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct ta= pdisk >>> =A0 =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy; >>> = >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(d= ummy)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, si= zeof(dummy)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0; >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapd= isk_s >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0; >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) { >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE]= , &dummy, >>> =A0 =A0 =A0 =A0 sizeof(dummy)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_= WRITE], &dummy, >>> =A0 =A0 =A0 =A0 sizeof(dummy)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct= tapd >>> =A0 =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned >>> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd-= >ring.vstart, >>> =A0 =A0 =A0 =A0 idx, 0); >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTO= R_SHIFT); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << >>> =A0 =A0 =A0 =A0 SECTOR_SHIFT); >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 =A0static void >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16= :19:16 >>> =A0 =A0 =A0 =A0 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16= :46:15 >>> =A0 =A0 =A0 =A0 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL); >>> = >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/"); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) { >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(= /): %d\n", errno); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1; >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out; >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 } >>> =A0 =A0 =A0 =A0 + >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2"); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init(); >>> = >>> = >>> = >>> = >>> = >>> -- >>> Best Regards, >>> Bei Guan >>> = >> = >> = > = > = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:47:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:47:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszp-0002hT-A8; Fri, 11 May 2012 16:47:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSszn-0002h1-RI for xen-devel@lists.xen.org; Fri, 11 May 2012 16:47:12 +0000 Received: from [85.158.143.99:23524] by server-1.bemta-4.messagelabs.com id DA/7B-20925-F824DAF4; Fri, 11 May 2012 16:47:11 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336754829!16384923!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27056 invoked from network); 11 May 2012 16:47:10 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:47:10 -0000 Received: by wgbds1 with SMTP id ds1so1745070wgb.2 for ; Fri, 11 May 2012 09:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=edbrZzqd/ACG7JJH+W9M69GkKpw7tNzYIYciKeoHLvc=; b=Rd5V4BgNdS2Wru8qeb8bfKRorXKr3X5T7RPBSnVm/nG7PU7t1kie/HosNnhpg4jzvC KalZJILvtry1IAboc1CwW1ScH1A+ta33cKe+6/hjMHhwQliDYQ6LpiIFURnGmFhx75gG Q1s0HBVXz6loMc0LUNP+YBPZH+hTJSod42ObpfzDufQOAxwqkWmbw7hL/IpBSCRnvaHp /L5YuRZa+tpcbuzBMC/erHS1l7KXrDNhTdoYKTUSJXePTkpuOtoRAs3NYDAadjLJNwGU IM1q+EqCVYMmZC5KvtcaDc5e1vnndwrp9q/5wb2GdJ1dM9v1bR6Suht46WZkITee/5iM TkyQ== Received: by 10.180.103.42 with SMTP id ft10mr9293090wib.18.1336754829440; Fri, 11 May 2012 09:47:09 -0700 (PDT) Received: from [192.168.1.3] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id fm1sm11618707wib.10.2012.05.11.09.47.08 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 09:47:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 11 May 2012 17:47:05 +0100 From: Keir Fraser To: Bei Guan , Ian Campbell Message-ID: Thread-Topic: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? Thread-Index: Ac0vlbI0xEAt/6MFzUysUP6/JofztQ== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 11/05/2012 17:33, "Bei Guan" wrote: > 2012/5/12 Ian Campbell >> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: >> = >> = >>> No, it doesn't work for me. There is the same error. >> = >> Hrm. Since you can reproduce would you mind experimenting a bit to >> figure out the correct fix for this? >> = >> Perhaps adding -Wno-unused-result to C flags helps (google suggests it >> may not)? > Yes, I add this option to Makefile. And now it works well. The patch is a= s the > following. Thank you very much. I'd be worried about more command-line meddling causing even more fallout. Particularly because we haven't used that option anywhere else so far, so it's untested by us. E.g., do all gcc support -Wno-unused-result? -- Keir > = > diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile > --- a/tools/blktap2/drivers/Makefile=A0=A0=A0 Fri Apr 27 11:09:26 2012 +0= 200 > +++ b/tools/blktap2/drivers/Makefile=A0=A0=A0 Sat May 12 00:31:12 2012 +0= 800 > @@ -11,6 +11,7 @@ > =A0 > =A0CFLAGS=A0=A0=A0 +=3D -Werror -g > =A0CFLAGS=A0=A0=A0 +=3D -Wno-unused > +CFLAGS=A0=A0=A0 +=3D -Wno-unused-result > =A0CFLAGS=A0=A0=A0 +=3D -fno-strict-aliasing > =A0CFLAGS=A0=A0=A0 +=3D -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers > =A0CFLAGS=A0=A0=A0 +=3D $(CFLAGS_libxenctrl) > = > = > = > = > Thanks, > Bei Guan > = > = > = > =A0 >> = >> Or maybe just assigning to a dummy variable. >> = >> Ian. >> = >>> My environment and gcc version are like this: >>> = >>> root@gavin-desktop:~# uname -a >>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC >>> 2011 x86_64 GNU/Linux >>> = >>> root@gavin-desktop:~# gcc -v >>> Using built-in specs. >>> Target: x86_64-linux-gnu >>> Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu >>> 4.4.3-4ubuntu5' >>> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs >>> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr >>> --enable-shared --enable-multiarch --enable-linker-build-id >>> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gettext >>> --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.4 >>> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu >>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc >>> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric >>> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu >>> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu >>> Thread model: posix >>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) >>> = >>> = >>> = >>> = >>> Thanks, >>> Bei Guan >>> = >>> = >>> = >>> = >>> = >>> =A0 =A0 =A0 =A0 8<------------------------------------------------------ >>> = >>> =A0 =A0 =A0 =A0 # HG changeset patch >>> =A0 =A0 =A0 =A0 # User Ian Campbell >>> =A0 =A0 =A0 =A0 # Date 1336751175 -3600 >>> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 >>> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf71999 >>> =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build failur= es. >>> = >>> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these callers = of >>> =A0 =A0 =A0 =A0 read/write have any >>> =A0 =A0 =A0 =A0 other error handling and return void themselves (for se= veral >>> =A0 =A0 =A0 =A0 links up the call >>> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want to get in= to a >>> =A0 =A0 =A0 =A0 massive reworking >>> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic >>> = >>> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell >>> = >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 F= ri May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 =A0 F= ri May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511)); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '\n', wsi= ze - size); >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsize); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf; >>> = >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri= May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 =A0 Fri= May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue= *que >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val; >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EVENTFD) >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_fd, &val,= sizeof(val)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->event_fd,= &val, sizeof(val)); >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 =A0static void >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri= May 11 >>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 =A0Fri= May 11 >>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct ta= pdisk >>> =A0 =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy; >>> = >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dummy, sizeof(d= ummy)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &dummy, si= zeof(dummy)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0; >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapd= isk_s >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0; >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) { >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POLL_WRITE]= , &dummy, >>> =A0 =A0 =A0 =A0 sizeof(dummy)); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pipe[POLL_= WRITE], &dummy, >>> =A0 =A0 =A0 =A0 sizeof(dummy)); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 =A0} >>> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct= tapd >>> =A0 =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned >>> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s->vbd-= >ring.vstart, >>> =A0 =A0 =A0 =A0 idx, 0); >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->secs << SECTO= R_SHIFT); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq->secs << >>> =A0 =A0 =A0 =A0 SECTOR_SHIFT); >>> =A0 =A0 =A0 =A0 =A0} >>> = >>> =A0 =A0 =A0 =A0 =A0static void >>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5 >>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c >>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16= :19:16 >>> =A0 =A0 =A0 =A0 2012 +0100 >>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May 11 16= :46:15 >>> =A0 =A0 =A0 =A0 2012 +0100 >>> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINVAL); >>> = >>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/"); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) { >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed to chdir(= /): %d\n", errno); >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1; >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out; >>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 } >>> =A0 =A0 =A0 =A0 + >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk2"); >>> = >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init(); >>> = >>> = >>> = >>> = >>> = >>> -- >>> Best Regards, >>> Bei Guan >>> = >> = >> = > = > = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:49:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:49:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt25-00039k-Gx; Fri, 11 May 2012 16:49:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt23-00039G-HW for xen-devel@lists.xen.org; Fri, 11 May 2012 16:49:31 +0000 Received: from [85.158.143.99:34843] by server-1.bemta-4.messagelabs.com id 39/FD-20925-A134DAF4; Fri, 11 May 2012 16:49:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336754969!27258554!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24294 invoked from network); 11 May 2012 16:49:29 -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; 11 May 2012 16:49:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434806" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:49: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, 11 May 2012 17:49:29 +0100 Message-ID: <1336754967.23818.142.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:49:27 +0100 In-Reply-To: <20397.16795.166767.442835@mariner.uk.xensource.com> References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6> <4F992DCF0200007800080283@nat28.tlf.novell.com> <1335432002.28015.78.camel@zakaz.uk.xensource.com> <1335433871.4742.18.camel@goosenl-desktop> <1335487527.4742.19.camel@goosenl-desktop> <20397.16795.166767.442835@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xuesen.Guo@hitachiconsulting.com" , xen-devel , Jan Beulich , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:43 +0100, Ian Jackson wrote: > Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"): > > readnote: Add bzImage kernel support > > I tried to apply this but I'm afraid it no longer applies to > xen-unstable tip: > > patching file tools/xcutils/readnotes.c > Hunk #1 FAILED at 17 > Hunk #3 FAILED at 161 > 2 out of 3 hunks FAILED -- saving rejects to file tools/xcutils/readnotes.c.rej > abort: patch failed to apply > > Ian. The most recent change to this file was changeset: 21483:779c0ef9682c user: Keir Fraser date: Fri May 28 09:30:19 2010 +0100 summary: libxc: eliminate static variables, use xentoollog; API change I expect something else is up -- whitespace mangling perhaps? Or maybe the patch simply isn't based on xen-unstable.hg? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:49:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:49:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt25-00039k-Gx; Fri, 11 May 2012 16:49:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt23-00039G-HW for xen-devel@lists.xen.org; Fri, 11 May 2012 16:49:31 +0000 Received: from [85.158.143.99:34843] by server-1.bemta-4.messagelabs.com id 39/FD-20925-A134DAF4; Fri, 11 May 2012 16:49:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1336754969!27258554!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24294 invoked from network); 11 May 2012 16:49:29 -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; 11 May 2012 16:49:29 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434806" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:49: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, 11 May 2012 17:49:29 +0100 Message-ID: <1336754967.23818.142.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:49:27 +0100 In-Reply-To: <20397.16795.166767.442835@mariner.uk.xensource.com> References: <27a6422ac06df8bef75d.1335430449@localhost6.localdomain6> <4F992DCF0200007800080283@nat28.tlf.novell.com> <1335432002.28015.78.camel@zakaz.uk.xensource.com> <1335433871.4742.18.camel@goosenl-desktop> <1335487527.4742.19.camel@goosenl-desktop> <20397.16795.166767.442835@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "Xuesen.Guo@hitachiconsulting.com" , xen-devel , Jan Beulich , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:43 +0100, Ian Jackson wrote: > Xuesen Guo writes ("Re: [Xen-devel] [PATCH] readnote: Add bzImage kernel support"): > > readnote: Add bzImage kernel support > > I tried to apply this but I'm afraid it no longer applies to > xen-unstable tip: > > patching file tools/xcutils/readnotes.c > Hunk #1 FAILED at 17 > Hunk #3 FAILED at 161 > 2 out of 3 hunks FAILED -- saving rejects to file tools/xcutils/readnotes.c.rej > abort: patch failed to apply > > Ian. The most recent change to this file was changeset: 21483:779c0ef9682c user: Keir Fraser date: Fri May 28 09:30:19 2010 +0100 summary: libxc: eliminate static variables, use xentoollog; API change I expect something else is up -- whitespace mangling perhaps? Or maybe the patch simply isn't based on xen-unstable.hg? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:50:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSt2b-0003Gn-V0; Fri, 11 May 2012 16:50:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt2a-0003GT-R0 for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:50:05 +0000 Received: from [85.158.143.99:39499] by server-2.bemta-4.messagelabs.com id 27/37-17550-C334DAF4; Fri, 11 May 2012 16:50:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336755002!21038540!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7753 invoked from network); 11 May 2012 16:50:02 -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; 11 May 2012 16:50:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434815" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:50:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:50:01 +0100 Message-ID: <1336754999.23818.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:49:59 +0100 In-Reply-To: <20374.54942.132249.434292@mariner.uk.xensource.com> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: multipart/mixed; boundary="=-clOl9qCt3yG9yvqgPCDe" X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --=-clOl9qCt3yG9yvqgPCDe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > > [0] apart perhaps from having /usr/include/xen-compat/xs.h and > > suggesting that people can use -I/usr/include/xen-compat as a bandaid, > > but at that point they may as well just sed their code, since they may > > need to support 4.1 anyhow. > > I think this would be a useful thing to add. Providing that would > mean that with -I/usr/include/xen-compat, the same code could compile > against both 4.1 and 4.2, if it said . I'm a little concerned about breaking out of tree users (specifically upstream Qemu). How about the following based on Bastian's patch. This installs the headers as xenstore.h and xenstore_lib.h and provides compat headers in /usr/include/xenstore-compat/xs{,_lib}.h which #warn and then include the new names. This means that upstream code should be buildable using -I/usr/include/xenstore-compat. However, since we are now frozen for 4.2 I propose that we also create symlinks from the old xs.h and xs_lib.h to the compat versions inorder to not break 3rd party software for the 4.2 release. We will ship these for the 4.2 release only. If distros wish to omit these from their packaging then that's fine, although they should probably check their reverse-build depends etc. We will remove these links early in 4.3. qemu-xs-compat.patch fixes trad qemu, upstream is fixed when built in our build system by this patch and is fixed when built independently by the symlinks, for now. We can convert these properly at our leisure before 4.3 (NB: git style patch, so the rename is represented in the minimised manner) 8<------------------------------------ # HG changeset patch # User Ian Campbell # Date 1336754841 -3600 # Node ID b61d5b46f3a91f7cc9064186e10acacfab10b184 # Parent 15ed8f45c4e57a1e206af020e0ff17b792108e99 xenstore: rename public xenstore headers The xenstore header xs.h is producing conflicts with other software[1]. xs is a too short identifier and does not matche the library. Renaming the headers to xenstore.h and xenstore_lib.h is the easiest way to make them easy recognizable and prevent furthe problems. [1]: http://bugs.debian.org/668550 Signed-off-by: Bastian Blank Signed-off-by: Ian Campbell diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -241,6 +241,8 @@ uninstall: rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore-compat/xs_lib.h $(D)$(INCLUDEDIR)/xensotre-compat/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h rm -rf $(D)$(INCLUDEDIR)/xen rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl* rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h 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 @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include diff --git a/extras/mini-os/lib/xs.c b/extras/mini-os/lib/xs.c --- a/extras/mini-os/lib/xs.c +++ b/extras/mini-os/lib/xs.c @@ -9,7 +9,7 @@ #ifdef HAVE_LIBC #include #include -#include +#include #include #include #include diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -150,7 +150,8 @@ subdir-all-qemu-xen-dir subdir-install-q --source-path=$$source \ --extra-cflags="-I$(XEN_ROOT)/tools/include \ -I$(XEN_ROOT)/tools/libxc \ - -I$(XEN_ROOT)/tools/xenstore" \ + -I$(XEN_ROOT)/tools/xenstore \ + -I$(XEN_ROOT)/tools/xenstore/compat" \ --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ -L$(XEN_ROOT)/tools/xenstore" \ --bindir=$(LIBEXEC) \ diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c --- a/tools/blktap/drivers/blktapctrl.c +++ b/tools/blktap/drivers/blktapctrl.c @@ -47,7 +47,7 @@ #include #include #include -#include +#include #include #include #ifdef MEMSHR diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h --- a/tools/blktap/lib/blktaplib.h +++ b/tools/blktap/lib/blktaplib.h @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c --- a/tools/blktap/lib/xenbus.c +++ b/tools/blktap/lib/xenbus.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c --- a/tools/blktap/lib/xs_api.c +++ b/tools/blktap/lib/xs_api.c @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/tools/console/client/main.c b/tools/console/client/main.c --- a/tools/console/client/main.c +++ b/tools/console/client/main.c @@ -39,7 +39,7 @@ #include #endif -#include "xs.h" +#include #include "xenctrl.h" #define ESCAPE_CHARACTER 0x1d diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c --- a/tools/console/daemon/io.c +++ b/tools/console/daemon/io.c @@ -22,7 +22,7 @@ #include "utils.h" #include "io.h" -#include +#include #include #include diff --git a/tools/console/daemon/utils.h b/tools/console/daemon/utils.h --- a/tools/console/daemon/utils.h +++ b/tools/console/daemon/utils.h @@ -26,7 +26,7 @@ #include #include -#include "xs.h" +#include void daemonize(const char *pidfile); bool xen_setup(void); diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c --- a/tools/libvchan/init.c +++ b/tools/libvchan/init.c @@ -40,7 +40,7 @@ #include #include -#include +#include #include #include #include diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -43,7 +43,7 @@ #include #include -#include +#include #include #include "xentoollog.h" diff --git a/tools/misc/xen-lowmemd.c b/tools/misc/xen-lowmemd.c --- a/tools/misc/xen-lowmemd.c +++ b/tools/misc/xen-lowmemd.c @@ -5,7 +5,7 @@ #include #include -#include +#include #include #include diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c @@ -2,7 +2,7 @@ #include -#include +#include #include #include "checkpoint.h" diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.h b/tools/python/xen/lowlevel/checkpoint/checkpoint.h --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h @@ -8,7 +8,7 @@ #include #include -#include +#include typedef enum { dt_unknown, diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c @@ -11,7 +11,7 @@ #include #include -#include +#include #include "checkpoint.h" diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c --- a/tools/python/xen/lowlevel/xs/xs.c +++ b/tools/python/xen/lowlevel/xs/xs.c @@ -30,7 +30,7 @@ #include #include -#include "xs.h" +#include /** @file * Python interface to the Xen Store Daemon (xs). diff --git a/tools/tests/mce-test/tools/xen-mceinj.c b/tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c +++ b/tools/tests/mce-test/tools/xen-mceinj.c @@ -38,7 +38,7 @@ #include #include #include -#include +#include #define MCi_type_CTL 0x0 #define MCi_type_STATUS 0x1 diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c --- a/tools/xcutils/xc_save.c +++ b/tools/xcutils/xc_save.c @@ -19,7 +19,7 @@ #include #include -#include +#include #include #include diff --git a/tools/xenbackendd/xenbackendd.c b/tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c +++ b/tools/xenbackendd/xenbackendd.c @@ -28,7 +28,7 @@ #include #include -#include +#include #define DEVTYPE_UNKNOWN 0 #define DEVTYPE_VIF 1 diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include #include "xc_bitops.h" diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c --- a/tools/xenpmd/xenpmd.c +++ b/tools/xenpmd/xenpmd.c @@ -40,7 +40,7 @@ #include #include #include -#include +#include /* #define RUN_STANDALONE */ #define RUN_IN_SIMULATE_MODE diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h b/tools/xenstat/libxenstat/src/xenstat_priv.h --- a/tools/xenstat/libxenstat/src/xenstat_priv.h +++ b/tools/xenstat/libxenstat/src/xenstat_priv.h @@ -24,7 +24,7 @@ #define XENSTAT_PRIV_H #include -#include +#include #include "xenstat.h" #include "xenctrl.h" diff --git a/tools/xenstore/COPYING b/tools/xenstore/COPYING --- a/tools/xenstore/COPYING +++ b/tools/xenstore/COPYING @@ -1,6 +1,6 @@ This license (LGPL) applies to the xenstore library which interfaces -with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and -xs_lib.h). The remaining files in the directory are licensed as +with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and +xenstore_lib.h). The remaining files in the directory are licensed as stated in the comments (as of this writing, GPL, see ../../COPYING). diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile --- a/tools/xenstore/Makefile +++ b/tools/xenstore/Makefile @@ -109,6 +109,7 @@ install: all $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xenstore-compat $(INSTALL_DIR) $(DESTDIR)/var/run/xenstored $(INSTALL_DIR) $(DESTDIR)/var/lib/xenstored $(INSTALL_PROG) xenstored $(DESTDIR)$(SBINDIR) @@ -122,8 +123,12 @@ install: all ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR) ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so $(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR) - $(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs.h + $(INSTALL_DATA) compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs_lib.h + ln -sf xenstore-compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xs.h + ln -sf xenstore-compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xs_lib.h -include $(DEPS) diff --git a/tools/xenstore/compat/xs.h b/tools/xenstore/compat/xs.h new file mode 100644 --- /dev/null +++ b/tools/xenstore/compat/xs.h @@ -0,0 +1,5 @@ +#ifndef XENSTORE_COMPAT_H +#define XENSTORE_COMPAT_H +#warning xs.h is deprecated use xenstore.h instead +#include +#endif diff --git a/tools/xenstore/compat/xs_lib.h b/tools/xenstore/compat/xs_lib.h new file mode 100644 --- /dev/null +++ b/tools/xenstore/compat/xs_lib.h @@ -0,0 +1,5 @@ +#ifndef XENSTORE_LIB_COMPAT_H +#define XENSTORE_LIB_COMPAT_H +#warning xs_lib.h is deprecated use xenstore_lib.h instead +#include +#endif diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c --- a/tools/xenstore/init-xenstore-domain.c +++ b/tools/xenstore/init-xenstore-domain.c @@ -7,7 +7,7 @@ #include #include #include -#include +#include #include static uint32_t domid = -1; diff --git a/tools/xenstore/xs.h b/tools/xenstore/xenstore.h rename from tools/xenstore/xs.h rename to tools/xenstore/xenstore.h --- a/tools/xenstore/xs.h +++ b/tools/xenstore/xenstore.h @@ -17,10 +17,10 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef _XS_H -#define _XS_H +#ifndef XENSTORE_H +#define XENSTORE_H -#include +#include #define XBT_NULL 0 @@ -223,7 +223,7 @@ char *xs_debug_command(struct xs_handle void *data, unsigned int len); int xs_suspend_evtchn_port(int domid); -#endif /* _XS_H */ +#endif /* XENSTORE_H */ /* * Local variables: diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c --- a/tools/xenstore/xenstore_client.c +++ b/tools/xenstore/xenstore_client.c @@ -18,7 +18,7 @@ #include #include #include -#include +#include #include diff --git a/tools/xenstore/xenstore_control.c b/tools/xenstore/xenstore_control.c --- a/tools/xenstore/xenstore_control.c +++ b/tools/xenstore/xenstore_control.c @@ -2,7 +2,7 @@ #include #include -#include "xs.h" +#include "xenstore.h" int main(int argc, char **argv) diff --git a/tools/xenstore/xs_lib.h b/tools/xenstore/xenstore_lib.h rename from tools/xenstore/xs_lib.h rename to tools/xenstore/xenstore_lib.h --- a/tools/xenstore/xs_lib.h +++ b/tools/xenstore/xenstore_lib.h @@ -17,8 +17,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef _XS_LIB_H -#define _XS_LIB_H +#ifndef XENSTORE_LIB_H +#define XENSTORE_LIB_H #include #include @@ -82,4 +82,4 @@ char *sanitise_value(struct expanding_bu /* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ void unsanitise_value(char *out, unsigned *out_len_r, const char *in); -#endif /* _XS_LIB_H */ +#endif /* XENSTORE_LIB_H */ diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c --- a/tools/xenstore/xenstored_core.c +++ b/tools/xenstore/xenstored_core.c @@ -44,7 +44,7 @@ #include "utils.h" #include "list.h" #include "talloc.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "xenstored_core.h" #include "xenstored_watch.h" #include "xenstored_transaction.h" diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h --- a/tools/xenstore/xenstored_core.h +++ b/tools/xenstore/xenstored_core.h @@ -27,7 +27,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "list.h" #include "tdb.h" diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c --- a/tools/xenstore/xenstored_transaction.c +++ b/tools/xenstore/xenstored_transaction.c @@ -33,7 +33,7 @@ #include "xenstored_transaction.h" #include "xenstored_watch.h" #include "xenstored_domain.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" struct changed_node diff --git a/tools/xenstore/xenstored_watch.c b/tools/xenstore/xenstored_watch.c --- a/tools/xenstore/xenstored_watch.c +++ b/tools/xenstore/xenstored_watch.c @@ -27,7 +27,7 @@ #include "talloc.h" #include "list.h" #include "xenstored_watch.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" #include "xenstored_domain.h" diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c --- a/tools/xenstore/xs.c +++ b/tools/xenstore/xs.c @@ -32,7 +32,7 @@ #include #include #include -#include "xs.h" +#include "xenstore.h" #include "list.h" #include "utils.h" diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c --- a/tools/xenstore/xs_lib.c +++ b/tools/xenstore/xs_lib.c @@ -23,7 +23,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" /* Common routines for the Xen store daemon and client library. */ diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c --- a/tools/xenstore/xs_tdb_dump.c +++ b/tools/xenstore/xs_tdb_dump.c @@ -5,7 +5,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "tdb.h" #include "talloc.h" #include "utils.h" --=-clOl9qCt3yG9yvqgPCDe Content-Disposition: attachment; filename="qemu-xs-compat.patch" Content-Type: text/x-patch; name="qemu-xs-compat.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit diff --git a/Makefile b/Makefile index 37c7066..a43ca67 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,7 @@ recurse-all: $(SUBDIR_RULES) CPPFLAGS += -I$(XEN_ROOT)/tools/libxc CPPFLAGS += -I$(XEN_ROOT)/tools/blktap/lib CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS += -I$(XEN_ROOT)/tools/include tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c diff --git a/xen-hooks.mak b/xen-hooks.mak index b55f45b..8e9cadf 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -1,5 +1,6 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS+= -I$(XEN_ROOT)/tools/include SSE2 := $(call cc-option,-msse2,) --=-clOl9qCt3yG9yvqgPCDe Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=-clOl9qCt3yG9yvqgPCDe-- From xen-devel-bounces@lists.xen.org Fri May 11 16:50:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SSt2b-0003Gn-V0; Fri, 11 May 2012 16:50:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt2a-0003GT-R0 for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:50:05 +0000 Received: from [85.158.143.99:39499] by server-2.bemta-4.messagelabs.com id 27/37-17550-C334DAF4; Fri, 11 May 2012 16:50:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1336755002!21038540!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7753 invoked from network); 11 May 2012 16:50:02 -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; 11 May 2012 16:50:02 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434815" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:50:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 17:50:01 +0100 Message-ID: <1336754999.23818.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 11 May 2012 17:49:59 +0100 In-Reply-To: <20374.54942.132249.434292@mariner.uk.xensource.com> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. Content-Type: multipart/mixed; boundary="=-clOl9qCt3yG9yvqgPCDe" X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --=-clOl9qCt3yG9yvqgPCDe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > > [0] apart perhaps from having /usr/include/xen-compat/xs.h and > > suggesting that people can use -I/usr/include/xen-compat as a bandaid, > > but at that point they may as well just sed their code, since they may > > need to support 4.1 anyhow. > > I think this would be a useful thing to add. Providing that would > mean that with -I/usr/include/xen-compat, the same code could compile > against both 4.1 and 4.2, if it said . I'm a little concerned about breaking out of tree users (specifically upstream Qemu). How about the following based on Bastian's patch. This installs the headers as xenstore.h and xenstore_lib.h and provides compat headers in /usr/include/xenstore-compat/xs{,_lib}.h which #warn and then include the new names. This means that upstream code should be buildable using -I/usr/include/xenstore-compat. However, since we are now frozen for 4.2 I propose that we also create symlinks from the old xs.h and xs_lib.h to the compat versions inorder to not break 3rd party software for the 4.2 release. We will ship these for the 4.2 release only. If distros wish to omit these from their packaging then that's fine, although they should probably check their reverse-build depends etc. We will remove these links early in 4.3. qemu-xs-compat.patch fixes trad qemu, upstream is fixed when built in our build system by this patch and is fixed when built independently by the symlinks, for now. We can convert these properly at our leisure before 4.3 (NB: git style patch, so the rename is represented in the minimised manner) 8<------------------------------------ # HG changeset patch # User Ian Campbell # Date 1336754841 -3600 # Node ID b61d5b46f3a91f7cc9064186e10acacfab10b184 # Parent 15ed8f45c4e57a1e206af020e0ff17b792108e99 xenstore: rename public xenstore headers The xenstore header xs.h is producing conflicts with other software[1]. xs is a too short identifier and does not matche the library. Renaming the headers to xenstore.h and xenstore_lib.h is the easiest way to make them easy recognizable and prevent furthe problems. [1]: http://bugs.debian.org/668550 Signed-off-by: Bastian Blank Signed-off-by: Ian Campbell diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -241,6 +241,8 @@ uninstall: rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore-compat/xs_lib.h $(D)$(INCLUDEDIR)/xensotre-compat/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h rm -rf $(D)$(INCLUDEDIR)/xen rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl* rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h 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 @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include diff --git a/extras/mini-os/lib/xs.c b/extras/mini-os/lib/xs.c --- a/extras/mini-os/lib/xs.c +++ b/extras/mini-os/lib/xs.c @@ -9,7 +9,7 @@ #ifdef HAVE_LIBC #include #include -#include +#include #include #include #include diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -150,7 +150,8 @@ subdir-all-qemu-xen-dir subdir-install-q --source-path=$$source \ --extra-cflags="-I$(XEN_ROOT)/tools/include \ -I$(XEN_ROOT)/tools/libxc \ - -I$(XEN_ROOT)/tools/xenstore" \ + -I$(XEN_ROOT)/tools/xenstore \ + -I$(XEN_ROOT)/tools/xenstore/compat" \ --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ -L$(XEN_ROOT)/tools/xenstore" \ --bindir=$(LIBEXEC) \ diff --git a/tools/blktap/drivers/blktapctrl.c b/tools/blktap/drivers/blktapctrl.c --- a/tools/blktap/drivers/blktapctrl.c +++ b/tools/blktap/drivers/blktapctrl.c @@ -47,7 +47,7 @@ #include #include #include -#include +#include #include #include #ifdef MEMSHR diff --git a/tools/blktap/lib/blktaplib.h b/tools/blktap/lib/blktaplib.h --- a/tools/blktap/lib/blktaplib.h +++ b/tools/blktap/lib/blktaplib.h @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include diff --git a/tools/blktap/lib/xenbus.c b/tools/blktap/lib/xenbus.c --- a/tools/blktap/lib/xenbus.c +++ b/tools/blktap/lib/xenbus.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/tools/blktap/lib/xs_api.c b/tools/blktap/lib/xs_api.c --- a/tools/blktap/lib/xs_api.c +++ b/tools/blktap/lib/xs_api.c @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/tools/console/client/main.c b/tools/console/client/main.c --- a/tools/console/client/main.c +++ b/tools/console/client/main.c @@ -39,7 +39,7 @@ #include #endif -#include "xs.h" +#include #include "xenctrl.h" #define ESCAPE_CHARACTER 0x1d diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c --- a/tools/console/daemon/io.c +++ b/tools/console/daemon/io.c @@ -22,7 +22,7 @@ #include "utils.h" #include "io.h" -#include +#include #include #include diff --git a/tools/console/daemon/utils.h b/tools/console/daemon/utils.h --- a/tools/console/daemon/utils.h +++ b/tools/console/daemon/utils.h @@ -26,7 +26,7 @@ #include #include -#include "xs.h" +#include void daemonize(const char *pidfile); bool xen_setup(void); diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c --- a/tools/libvchan/init.c +++ b/tools/libvchan/init.c @@ -40,7 +40,7 @@ #include #include -#include +#include #include #include #include diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -43,7 +43,7 @@ #include #include -#include +#include #include #include "xentoollog.h" diff --git a/tools/misc/xen-lowmemd.c b/tools/misc/xen-lowmemd.c --- a/tools/misc/xen-lowmemd.c +++ b/tools/misc/xen-lowmemd.c @@ -5,7 +5,7 @@ #include #include -#include +#include #include #include diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.c b/tools/python/xen/lowlevel/checkpoint/checkpoint.c --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c @@ -2,7 +2,7 @@ #include -#include +#include #include #include "checkpoint.h" diff --git a/tools/python/xen/lowlevel/checkpoint/checkpoint.h b/tools/python/xen/lowlevel/checkpoint/checkpoint.h --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h @@ -8,7 +8,7 @@ #include #include -#include +#include typedef enum { dt_unknown, diff --git a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c @@ -11,7 +11,7 @@ #include #include -#include +#include #include "checkpoint.h" diff --git a/tools/python/xen/lowlevel/xs/xs.c b/tools/python/xen/lowlevel/xs/xs.c --- a/tools/python/xen/lowlevel/xs/xs.c +++ b/tools/python/xen/lowlevel/xs/xs.c @@ -30,7 +30,7 @@ #include #include -#include "xs.h" +#include /** @file * Python interface to the Xen Store Daemon (xs). diff --git a/tools/tests/mce-test/tools/xen-mceinj.c b/tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c +++ b/tools/tests/mce-test/tools/xen-mceinj.c @@ -38,7 +38,7 @@ #include #include #include -#include +#include #define MCi_type_CTL 0x0 #define MCi_type_STATUS 0x1 diff --git a/tools/xcutils/xc_save.c b/tools/xcutils/xc_save.c --- a/tools/xcutils/xc_save.c +++ b/tools/xcutils/xc_save.c @@ -19,7 +19,7 @@ #include #include -#include +#include #include #include diff --git a/tools/xenbackendd/xenbackendd.c b/tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c +++ b/tools/xenbackendd/xenbackendd.c @@ -28,7 +28,7 @@ #include #include -#include +#include #define DEVTYPE_UNKNOWN 0 #define DEVTYPE_VIF 1 diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c +++ b/tools/xenpaging/xenpaging.c @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include #include "xc_bitops.h" diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c --- a/tools/xenpmd/xenpmd.c +++ b/tools/xenpmd/xenpmd.c @@ -40,7 +40,7 @@ #include #include #include -#include +#include /* #define RUN_STANDALONE */ #define RUN_IN_SIMULATE_MODE diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h b/tools/xenstat/libxenstat/src/xenstat_priv.h --- a/tools/xenstat/libxenstat/src/xenstat_priv.h +++ b/tools/xenstat/libxenstat/src/xenstat_priv.h @@ -24,7 +24,7 @@ #define XENSTAT_PRIV_H #include -#include +#include #include "xenstat.h" #include "xenctrl.h" diff --git a/tools/xenstore/COPYING b/tools/xenstore/COPYING --- a/tools/xenstore/COPYING +++ b/tools/xenstore/COPYING @@ -1,6 +1,6 @@ This license (LGPL) applies to the xenstore library which interfaces -with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and -xs_lib.h). The remaining files in the directory are licensed as +with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and +xenstore_lib.h). The remaining files in the directory are licensed as stated in the comments (as of this writing, GPL, see ../../COPYING). diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile --- a/tools/xenstore/Makefile +++ b/tools/xenstore/Makefile @@ -109,6 +109,7 @@ install: all $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xenstore-compat $(INSTALL_DIR) $(DESTDIR)/var/run/xenstored $(INSTALL_DIR) $(DESTDIR)/var/lib/xenstored $(INSTALL_PROG) xenstored $(DESTDIR)$(SBINDIR) @@ -122,8 +123,12 @@ install: all ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR) ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so $(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR) - $(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs.h + $(INSTALL_DATA) compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs_lib.h + ln -sf xenstore-compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xs.h + ln -sf xenstore-compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xs_lib.h -include $(DEPS) diff --git a/tools/xenstore/compat/xs.h b/tools/xenstore/compat/xs.h new file mode 100644 --- /dev/null +++ b/tools/xenstore/compat/xs.h @@ -0,0 +1,5 @@ +#ifndef XENSTORE_COMPAT_H +#define XENSTORE_COMPAT_H +#warning xs.h is deprecated use xenstore.h instead +#include +#endif diff --git a/tools/xenstore/compat/xs_lib.h b/tools/xenstore/compat/xs_lib.h new file mode 100644 --- /dev/null +++ b/tools/xenstore/compat/xs_lib.h @@ -0,0 +1,5 @@ +#ifndef XENSTORE_LIB_COMPAT_H +#define XENSTORE_LIB_COMPAT_H +#warning xs_lib.h is deprecated use xenstore_lib.h instead +#include +#endif diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c --- a/tools/xenstore/init-xenstore-domain.c +++ b/tools/xenstore/init-xenstore-domain.c @@ -7,7 +7,7 @@ #include #include #include -#include +#include #include static uint32_t domid = -1; diff --git a/tools/xenstore/xs.h b/tools/xenstore/xenstore.h rename from tools/xenstore/xs.h rename to tools/xenstore/xenstore.h --- a/tools/xenstore/xs.h +++ b/tools/xenstore/xenstore.h @@ -17,10 +17,10 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef _XS_H -#define _XS_H +#ifndef XENSTORE_H +#define XENSTORE_H -#include +#include #define XBT_NULL 0 @@ -223,7 +223,7 @@ char *xs_debug_command(struct xs_handle void *data, unsigned int len); int xs_suspend_evtchn_port(int domid); -#endif /* _XS_H */ +#endif /* XENSTORE_H */ /* * Local variables: diff --git a/tools/xenstore/xenstore_client.c b/tools/xenstore/xenstore_client.c --- a/tools/xenstore/xenstore_client.c +++ b/tools/xenstore/xenstore_client.c @@ -18,7 +18,7 @@ #include #include #include -#include +#include #include diff --git a/tools/xenstore/xenstore_control.c b/tools/xenstore/xenstore_control.c --- a/tools/xenstore/xenstore_control.c +++ b/tools/xenstore/xenstore_control.c @@ -2,7 +2,7 @@ #include #include -#include "xs.h" +#include "xenstore.h" int main(int argc, char **argv) diff --git a/tools/xenstore/xs_lib.h b/tools/xenstore/xenstore_lib.h rename from tools/xenstore/xs_lib.h rename to tools/xenstore/xenstore_lib.h --- a/tools/xenstore/xs_lib.h +++ b/tools/xenstore/xenstore_lib.h @@ -17,8 +17,8 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef _XS_LIB_H -#define _XS_LIB_H +#ifndef XENSTORE_LIB_H +#define XENSTORE_LIB_H #include #include @@ -82,4 +82,4 @@ char *sanitise_value(struct expanding_bu /* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ void unsanitise_value(char *out, unsigned *out_len_r, const char *in); -#endif /* _XS_LIB_H */ +#endif /* XENSTORE_LIB_H */ diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c --- a/tools/xenstore/xenstored_core.c +++ b/tools/xenstore/xenstored_core.c @@ -44,7 +44,7 @@ #include "utils.h" #include "list.h" #include "talloc.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "xenstored_core.h" #include "xenstored_watch.h" #include "xenstored_transaction.h" diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h --- a/tools/xenstore/xenstored_core.h +++ b/tools/xenstore/xenstored_core.h @@ -27,7 +27,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "list.h" #include "tdb.h" diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c --- a/tools/xenstore/xenstored_transaction.c +++ b/tools/xenstore/xenstored_transaction.c @@ -33,7 +33,7 @@ #include "xenstored_transaction.h" #include "xenstored_watch.h" #include "xenstored_domain.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" struct changed_node diff --git a/tools/xenstore/xenstored_watch.c b/tools/xenstore/xenstored_watch.c --- a/tools/xenstore/xenstored_watch.c +++ b/tools/xenstore/xenstored_watch.c @@ -27,7 +27,7 @@ #include "talloc.h" #include "list.h" #include "xenstored_watch.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" #include "xenstored_domain.h" diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c --- a/tools/xenstore/xs.c +++ b/tools/xenstore/xs.c @@ -32,7 +32,7 @@ #include #include #include -#include "xs.h" +#include "xenstore.h" #include "list.h" #include "utils.h" diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c --- a/tools/xenstore/xs_lib.c +++ b/tools/xenstore/xs_lib.c @@ -23,7 +23,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" /* Common routines for the Xen store daemon and client library. */ diff --git a/tools/xenstore/xs_tdb_dump.c b/tools/xenstore/xs_tdb_dump.c --- a/tools/xenstore/xs_tdb_dump.c +++ b/tools/xenstore/xs_tdb_dump.c @@ -5,7 +5,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "tdb.h" #include "talloc.h" #include "utils.h" --=-clOl9qCt3yG9yvqgPCDe Content-Disposition: attachment; filename="qemu-xs-compat.patch" Content-Type: text/x-patch; name="qemu-xs-compat.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit diff --git a/Makefile b/Makefile index 37c7066..a43ca67 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,7 @@ recurse-all: $(SUBDIR_RULES) CPPFLAGS += -I$(XEN_ROOT)/tools/libxc CPPFLAGS += -I$(XEN_ROOT)/tools/blktap/lib CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS += -I$(XEN_ROOT)/tools/include tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c diff --git a/xen-hooks.mak b/xen-hooks.mak index b55f45b..8e9cadf 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -1,5 +1,6 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS+= -I$(XEN_ROOT)/tools/include SSE2 := $(call cc-option,-msse2,) --=-clOl9qCt3yG9yvqgPCDe Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=-clOl9qCt3yG9yvqgPCDe-- From xen-devel-bounces@lists.xen.org Fri May 11 16:55:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSt7U-0003ov-Uu; Fri, 11 May 2012 16:55:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt7T-0003on-Sp for xen-devel@lists.xen.org; Fri, 11 May 2012 16:55:07 +0000 Received: from [85.158.143.35:38198] by server-2.bemta-4.messagelabs.com id 60/CC-17550-B644DAF4; Fri, 11 May 2012 16:55:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336755306!11792421!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9629 invoked from network); 11 May 2012 16:55:06 -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; 11 May 2012 16:55:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434838" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:51: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, 11 May 2012 17:51:50 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSt4I-0007wF-1O; Fri, 11 May 2012 16:51:50 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSt4I-0002cK-0W; Fri, 11 May 2012 17:51:50 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17317.965011.748577@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:51:49 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1334595483.14560.249.camel@zakaz.uk.xensource.com> References: <20364.16337.971144.457146@mariner.uk.xensource.com> <1334591807.14560.220.camel@zakaz.uk.xensource.com> <20364.18772.529397.220632@mariner.uk.xensource.com> <1334595483.14560.249.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"): > libxl: add a dummy ao_how to libxl_domain_core_dump Acked-by: Ian Jackson I have added this to my child process handling series. It will go in with the rest of those. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:55:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16: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 ) id 1SSt7U-0003ov-Uu; Fri, 11 May 2012 16:55:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt7T-0003on-Sp for xen-devel@lists.xen.org; Fri, 11 May 2012 16:55:07 +0000 Received: from [85.158.143.35:38198] by server-2.bemta-4.messagelabs.com id 60/CC-17550-B644DAF4; Fri, 11 May 2012 16:55:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1336755306!11792421!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9629 invoked from network); 11 May 2012 16:55:06 -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; 11 May 2012 16:55:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434838" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 16:51: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, 11 May 2012 17:51:50 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSt4I-0007wF-1O; Fri, 11 May 2012 16:51:50 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSt4I-0002cK-0W; Fri, 11 May 2012 17:51:50 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17317.965011.748577@mariner.uk.xensource.com> Date: Fri, 11 May 2012 17:51:49 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1334595483.14560.249.camel@zakaz.uk.xensource.com> References: <20364.16337.971144.457146@mariner.uk.xensource.com> <1334591807.14560.220.camel@zakaz.uk.xensource.com> <20364.18772.529397.220632@mariner.uk.xensource.com> <1334595483.14560.249.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add a dummy ao_how to libxl_domain_core_dump"): > libxl: add a dummy ao_how to libxl_domain_core_dump Acked-by: Ian Jackson I have added this to my child process handling series. It will go in with the rest of those. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:57:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt9w-0003xX-GP; Fri, 11 May 2012 16:57:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt9u-0003xN-FE for xen-devel@lists.xen.org; Fri, 11 May 2012 16:57:38 +0000 Received: from [193.109.254.147:49054] by server-12.bemta-14.messagelabs.com id BE/7E-05898-1054DAF4; Fri, 11 May 2012 16:57:37 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336755452!8795350!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8443 invoked from network); 11 May 2012 16:57:33 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:57:33 -0000 Received: by lahc1 with SMTP id c1so2250164lah.32 for ; Fri, 11 May 2012 09:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7VJO1+HBEwkKYAc1+8GYqq9Zp7mMZWhODuz/vbe0/Q=; b=pJsFOsMgfFGiSl/ncGamxq9Wy8H0w0yKlCgQOWJSdtvCGyIJ8BL4FXwgY1pu7L0E+9 kBu+IR03fUyzah2MdSdwVNOO740JQTZab36HYsmf1Hm77ho8Ja1G1HlfrXMTusckTM2z PugAbrQltvpwFpWwfIF2nOxxdZ5dUA8/t5n/v//+OA9ZSGxF9ywdYW4oh5j3hzqomXeB x1AXU8T97HCk0F4hdK9t6bCm9hup7RzbN2BQ6xAIpK5hLkHCyaXuM8yrn802zAsxUO7V h7WlO87fVogxqms7o7h7aWAB0/Ke5FjQvEhqmr8a0EgxCJ42q5HImzSwQrctTwsx4Aa7 k5cQ== MIME-Version: 1.0 Received: by 10.152.112.97 with SMTP id ip1mr8985858lab.31.1336755452248; Fri, 11 May 2012 09:57:32 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:57:32 -0700 (PDT) In-Reply-To: References: <1336753463.23818.131.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:57:32 +0800 Message-ID: From: Bei Guan To: Keir Fraser Cc: Ian Campbell , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6399305107554103395==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6399305107554103395== Content-Type: multipart/alternative; boundary=f46d0421ad61e2012804bfc5a10d --f46d0421ad61e2012804bfc5a10d Content-Type: text/plain; charset=ISO-8859-1 2012/5/12 Keir Fraser > On 11/05/2012 17:24, "Ian Campbell" wrote: > > > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > > > > >> No, it doesn't work for me. There is the same error. > > > > Hrm. Since you can reproduce would you mind experimenting a bit to > > figure out the correct fix for this? > > > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > > may not)? > > > > Or maybe just assigning to a dummy variable. > > Bei, Please try the attached patch. > It works now. Thank you. Thanks, Bei Guan > > -- Keir > > > Ian. > > > >> My environment and gcc version are like this: > >> > >> root@gavin-desktop:~# uname -a > >> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > >> 2011 x86_64 GNU/Linux > >> > >> root@gavin-desktop:~# gcc -v > >> Using built-in specs. > >> Target: x86_64-linux-gnu > >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >> 4.4.3-4ubuntu5' > >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > >> --enable-shared --enable-multiarch --enable-linker-build-id > >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > >> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > >> --disable-werror --with-arch-32=i486 --with-tune=generic > >> --enable-checking=release --build=x86_64-linux-gnu > >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu > >> Thread model: posix > >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > >> > >> > >> > >> > >> Thanks, > >> Bei Guan > >> > >> > >> > >> > >> > >> 8<------------------------------------------------------ > >> > >> # HG changeset patch > >> # User Ian Campbell > >> # Date 1336751175 -3600 > >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > >> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > >> blktap: avoid attribute warn_unused_result build failures. > >> > >> I'm not proud of this, but since none of these callers of > >> read/write have any > >> other error handling and return void themselves (for several > >> links up the call > >> chain AFAICT) and because I don't really want to get into a > >> massive reworking > >> of blktap2 I suppose it is at least pragmatic > >> > >> Signed-off-by: Ian Campbell > >> > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-log.c > >> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -247,7 +247,7 @@ tlog_flush(void) > >> wsize = ((size + 511) & (~511)); > >> > >> memset(tapdisk_log.buf + size, '\n', wsize - size); > >> - write(fd, tapdisk_log.buf, wsize); > >> + (void)write(fd, tapdisk_log.buf, wsize); > >> > >> tapdisk_log.p = tapdisk_log.buf; > >> > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-queue.c > >> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > >> uint64_t val; > >> > >> if (lio->flags & LIO_FLAG_EVENTFD) > >> - read(lio->event_fd, &val, sizeof(val)); > >> + (void)read(lio->event_fd, &val, sizeof(val)); > >> } > >> > >> static void > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-stream.c > >> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > >> { > >> int dummy; > >> > >> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >> p->set = 0; > >> } > >> > >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > >> int dummy = 0; > >> > >> if (!p->set) { > >> - write(p->pipe[POLL_WRITE], &dummy, > >> sizeof(dummy)); > >> + (void)write(p->pipe[POLL_WRITE], &dummy, > >> sizeof(dummy)); > >> p->set = 1; > >> } > >> } > >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > >> { > >> unsigned long idx = (unsigned > >> long)tapdisk_stream_request_idx(s, sreq); > >> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > >> idx, 0); > >> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > >> + (void)write(s->out_fd, buf, sreq->secs << > >> SECTOR_SHIFT); > >> } > >> > >> static void > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk2.c > >> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > >> 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > >> 2012 +0100 > >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > >> if (optind != argc) > >> usage(argv[0], EINVAL); > >> > >> - chdir("/"); > >> + if (chdir("/")) { > >> + DPRINTF("failed to chdir(/): %d\n", errno); > >> + err = 1; > >> + goto out; > >> + } > >> + > >> tapdisk_start_logging("tapdisk2"); > >> > >> err = tapdisk_server_init(); > >> > >> > >> > >> > >> > >> -- > >> Best Regards, > >> Bei Guan > >> > > > > > > -- Best Regards, Bei Guan --f46d0421ad61e2012804bfc5a10d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/12 Keir Fraser = <keir@xen.org><= /span>
On 11/05/2012 17:24, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:<= br>
> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote:
>
>
>> No, it doesn't work for me. There is the same error.
>
> Hrm. Since you can reproduce would you mind experimenting a bit to
> figure out the correct fix for this?
>
> Perhaps adding -Wno-unused-result to C flags helps (google suggests it=
> may not)?
>
> Or maybe just assigning to a dummy variable.

Bei, Please try the attached patch.
It works now= . Thank you.


Thanks,
Bei Guan
=A0

=A0-- Keir

> Ian.
>
>> My environment and gcc version are like this:
>>
>> root@gavin-desktop:~# uname -a
>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 = UTC
>> 2011 x86_64 GNU/Linux
>>
>> root@gavin-desktop:~# gcc -v
>> Using built-in specs.
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion=3D'Ubun= tu
>> 4.4.3-4ubuntu5'
>> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs
>> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr >> --enable-shared --enable-multiarch --enable-linker-build-id
>> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gett= ext
>> --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++= /4.4
>> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu
>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
>> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric
>> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu
>> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
>> Thread model: posix
>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>>
>>
>>
>>
>> Thanks,
>> Bei Guan
>>
>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 8<---------------------------------------------= ---------
>>
>> =A0 =A0 =A0 =A0 # HG changeset patch
>> =A0 =A0 =A0 =A0 # User Ian Campbell <ian.campbell@citrix.com>
>> =A0 =A0 =A0 =A0 # Date 1336751175 -3600
>> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99=
>> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf719= 99
>> =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build f= ailures.
>>
>> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these= callers of
>> =A0 =A0 =A0 =A0 read/write have any
>> =A0 =A0 =A0 =A0 other error handling and return void themselves (f= or several
>> =A0 =A0 =A0 =A0 links up the call
>> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want = to get into a
>> =A0 =A0 =A0 =A0 massive reworking
>> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic
>>
>> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511= ));
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '= ;\n', wsize - size);
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsi= ze);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;<= br> >>
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct t= queue *que
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EV= ENTFD)
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_f= d, &val, sizeof(val));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->e= vent_fd, &val, sizeof(val));
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0static void
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 = =A0Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 = =A0Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(stru= ct tapdisk
>> =A0 =A0 =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy;
>>
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dum= my, sizeof(dummy));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &a= mp;dummy, sizeof(dummy));
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct= tapdisk_s
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) {
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POL= L_WRITE], &dummy,
>> =A0 =A0 =A0 =A0 sizeof(dummy));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pi= pe[POLL_WRITE], &dummy,
>> =A0 =A0 =A0 =A0 sizeof(dummy));
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(s= truct tapd
>> =A0 =A0 =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned
>> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s-= >vbd->ring.vstart,
>> =A0 =A0 =A0 =A0 idx, 0);
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->se= cs << SECTOR_SHIFT);
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq-= >secs <<
>> =A0 =A0 =A0 =A0 SECTOR_SHIFT);
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0static void
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May = 11 16:19:16
>> =A0 =A0 =A0 =A0 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May = 11 16:46:15
>> =A0 =A0 =A0 =A0 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINV= AL);
>>
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/");
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) {
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed= to chdir(/): %d\n", errno);
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 +
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk= 2");
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init();
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Bei Guan
>>
>
>




--
Best Regard= s,
Bei Guan

--f46d0421ad61e2012804bfc5a10d-- --===============6399305107554103395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6399305107554103395==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:57:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt9w-0003xX-GP; Fri, 11 May 2012 16:57:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSt9u-0003xN-FE for xen-devel@lists.xen.org; Fri, 11 May 2012 16:57:38 +0000 Received: from [193.109.254.147:49054] by server-12.bemta-14.messagelabs.com id BE/7E-05898-1054DAF4; Fri, 11 May 2012 16:57:37 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336755452!8795350!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8443 invoked from network); 11 May 2012 16:57:33 -0000 Received: from mail-lpp01m010-f45.google.com (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 16:57:33 -0000 Received: by lahc1 with SMTP id c1so2250164lah.32 for ; Fri, 11 May 2012 09:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7VJO1+HBEwkKYAc1+8GYqq9Zp7mMZWhODuz/vbe0/Q=; b=pJsFOsMgfFGiSl/ncGamxq9Wy8H0w0yKlCgQOWJSdtvCGyIJ8BL4FXwgY1pu7L0E+9 kBu+IR03fUyzah2MdSdwVNOO740JQTZab36HYsmf1Hm77ho8Ja1G1HlfrXMTusckTM2z PugAbrQltvpwFpWwfIF2nOxxdZ5dUA8/t5n/v//+OA9ZSGxF9ywdYW4oh5j3hzqomXeB x1AXU8T97HCk0F4hdK9t6bCm9hup7RzbN2BQ6xAIpK5hLkHCyaXuM8yrn802zAsxUO7V h7WlO87fVogxqms7o7h7aWAB0/Ke5FjQvEhqmr8a0EgxCJ42q5HImzSwQrctTwsx4Aa7 k5cQ== MIME-Version: 1.0 Received: by 10.152.112.97 with SMTP id ip1mr8985858lab.31.1336755452248; Fri, 11 May 2012 09:57:32 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 09:57:32 -0700 (PDT) In-Reply-To: References: <1336753463.23818.131.camel@zakaz.uk.xensource.com> Date: Sat, 12 May 2012 00:57:32 +0800 Message-ID: From: Bei Guan To: Keir Fraser Cc: Ian Campbell , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6399305107554103395==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6399305107554103395== Content-Type: multipart/alternative; boundary=f46d0421ad61e2012804bfc5a10d --f46d0421ad61e2012804bfc5a10d Content-Type: text/plain; charset=ISO-8859-1 2012/5/12 Keir Fraser > On 11/05/2012 17:24, "Ian Campbell" wrote: > > > On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > > > > > >> No, it doesn't work for me. There is the same error. > > > > Hrm. Since you can reproduce would you mind experimenting a bit to > > figure out the correct fix for this? > > > > Perhaps adding -Wno-unused-result to C flags helps (google suggests it > > may not)? > > > > Or maybe just assigning to a dummy variable. > > Bei, Please try the attached patch. > It works now. Thank you. Thanks, Bei Guan > > -- Keir > > > Ian. > > > >> My environment and gcc version are like this: > >> > >> root@gavin-desktop:~# uname -a > >> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > >> 2011 x86_64 GNU/Linux > >> > >> root@gavin-desktop:~# gcc -v > >> Using built-in specs. > >> Target: x86_64-linux-gnu > >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >> 4.4.3-4ubuntu5' > >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > >> --enable-shared --enable-multiarch --enable-linker-build-id > >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > >> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > >> --disable-werror --with-arch-32=i486 --with-tune=generic > >> --enable-checking=release --build=x86_64-linux-gnu > >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu > >> Thread model: posix > >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > >> > >> > >> > >> > >> Thanks, > >> Bei Guan > >> > >> > >> > >> > >> > >> 8<------------------------------------------------------ > >> > >> # HG changeset patch > >> # User Ian Campbell > >> # Date 1336751175 -3600 > >> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > >> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > >> blktap: avoid attribute warn_unused_result build failures. > >> > >> I'm not proud of this, but since none of these callers of > >> read/write have any > >> other error handling and return void themselves (for several > >> links up the call > >> chain AFAICT) and because I don't really want to get into a > >> massive reworking > >> of blktap2 I suppose it is at least pragmatic > >> > >> Signed-off-by: Ian Campbell > >> > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-log.c > >> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -247,7 +247,7 @@ tlog_flush(void) > >> wsize = ((size + 511) & (~511)); > >> > >> memset(tapdisk_log.buf + size, '\n', wsize - size); > >> - write(fd, tapdisk_log.buf, wsize); > >> + (void)write(fd, tapdisk_log.buf, wsize); > >> > >> tapdisk_log.p = tapdisk_log.buf; > >> > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-queue.c > >> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > >> uint64_t val; > >> > >> if (lio->flags & LIO_FLAG_EVENTFD) > >> - read(lio->event_fd, &val, sizeof(val)); > >> + (void)read(lio->event_fd, &val, sizeof(val)); > >> } > >> > >> static void > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk-stream.c > >> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >> 16:19:16 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >> 16:46:15 2012 +0100 > >> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > >> { > >> int dummy; > >> > >> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >> p->set = 0; > >> } > >> > >> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > >> int dummy = 0; > >> > >> if (!p->set) { > >> - write(p->pipe[POLL_WRITE], &dummy, > >> sizeof(dummy)); > >> + (void)write(p->pipe[POLL_WRITE], &dummy, > >> sizeof(dummy)); > >> p->set = 1; > >> } > >> } > >> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > >> { > >> unsigned long idx = (unsigned > >> long)tapdisk_stream_request_idx(s, sreq); > >> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > >> idx, 0); > >> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > >> + (void)write(s->out_fd, buf, sreq->secs << > >> SECTOR_SHIFT); > >> } > >> > >> static void > >> diff -r adc74e492edf -r 15ed8f45c4e5 > >> tools/blktap2/drivers/tapdisk2.c > >> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > >> 2012 +0100 > >> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > >> 2012 +0100 > >> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > >> if (optind != argc) > >> usage(argv[0], EINVAL); > >> > >> - chdir("/"); > >> + if (chdir("/")) { > >> + DPRINTF("failed to chdir(/): %d\n", errno); > >> + err = 1; > >> + goto out; > >> + } > >> + > >> tapdisk_start_logging("tapdisk2"); > >> > >> err = tapdisk_server_init(); > >> > >> > >> > >> > >> > >> -- > >> Best Regards, > >> Bei Guan > >> > > > > > > -- Best Regards, Bei Guan --f46d0421ad61e2012804bfc5a10d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/12 Keir Fraser = <keir@xen.org><= /span>
On 11/05/2012 17:24, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:<= br>
> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote:
>
>
>> No, it doesn't work for me. There is the same error.
>
> Hrm. Since you can reproduce would you mind experimenting a bit to
> figure out the correct fix for this?
>
> Perhaps adding -Wno-unused-result to C flags helps (google suggests it=
> may not)?
>
> Or maybe just assigning to a dummy variable.

Bei, Please try the attached patch.
It works now= . Thank you.


Thanks,
Bei Guan
=A0

=A0-- Keir

> Ian.
>
>> My environment and gcc version are like this:
>>
>> root@gavin-desktop:~# uname -a
>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 = UTC
>> 2011 x86_64 GNU/Linux
>>
>> root@gavin-desktop:~# gcc -v
>> Using built-in specs.
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion=3D'Ubun= tu
>> 4.4.3-4ubuntu5'
>> --with-bugurl=3Dfile:///usr/share/doc/gcc-4.4/README.Bugs
>> --enable-languages=3Dc,c++,fortran,objc,obj-c++ --prefix=3D/usr >> --enable-shared --enable-multiarch --enable-linker-build-id
>> --with-system-zlib --libexecdir=3D/usr/lib --without-included-gett= ext
>> --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++= /4.4
>> --program-suffix=3D-4.4 --enable-nls --enable-clocale=3Dgnu
>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
>> --disable-werror --with-arch-32=3Di486 --with-tune=3Dgeneric
>> --enable-checking=3Drelease --build=3Dx86_64-linux-gnu
>> --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu
>> Thread model: posix
>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>>
>>
>>
>>
>> Thanks,
>> Bei Guan
>>
>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 8<---------------------------------------------= ---------
>>
>> =A0 =A0 =A0 =A0 # HG changeset patch
>> =A0 =A0 =A0 =A0 # User Ian Campbell <ian.campbell@citrix.com>
>> =A0 =A0 =A0 =A0 # Date 1336751175 -3600
>> =A0 =A0 =A0 =A0 # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99=
>> =A0 =A0 =A0 =A0 # Parent =A0adc74e492edfee6cf44e433e3e93743a3cf719= 99
>> =A0 =A0 =A0 =A0 blktap: avoid attribute warn_unused_result build f= ailures.
>>
>> =A0 =A0 =A0 =A0 I'm not proud of this, but since none of these= callers of
>> =A0 =A0 =A0 =A0 read/write have any
>> =A0 =A0 =A0 =A0 other error handling and return void themselves (f= or several
>> =A0 =A0 =A0 =A0 links up the call
>> =A0 =A0 =A0 =A0 chain AFAICT) and because I don't really want = to get into a
>> =A0 =A0 =A0 =A0 massive reworking
>> =A0 =A0 =A0 =A0 of blktap2 I suppose it is at least pragmatic
>>
>> =A0 =A0 =A0 =A0 Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-log.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-log.c =A0 =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -247,7 +247,7 @@ tlog_flush(void)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wsize =3D ((size + 511) & (~511= ));
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(tapdisk_log.buf + size, '= ;\n', wsize - size);
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(fd, tapdisk_log.buf, wsize); >> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(fd, tapdisk_log.buf, wsi= ze);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_log.p =3D tapdisk_log.buf;<= br> >>
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-queue.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-queue.c =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-queue.c =A0 = =A0 Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct t= queue *que
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t val;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (lio->flags & LIO_FLAG_EV= ENTFD)
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 read(lio->event_f= d, &val, sizeof(val));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)read(lio->e= vent_fd, &val, sizeof(val));
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0static void
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk-stream.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk-stream.c =A0 = =A0Fri May 11
>> =A0 =A0 =A0 =A0 16:19:16 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk-stream.c =A0 = =A0Fri May 11
>> =A0 =A0 =A0 =A0 16:46:15 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(stru= ct tapdisk
>> =A0 =A0 =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy;
>>
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 read(p->pipe[POLL_READ], &dum= my, sizeof(dummy));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)read(p->pipe[POLL_READ], &a= mp;dummy, sizeof(dummy));
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 0;
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct= tapdisk_s
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int dummy =3D 0;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!p->set) {
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 write(p->pipe[POL= L_WRITE], &dummy,
>> =A0 =A0 =A0 =A0 sizeof(dummy));
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (void)write(p->pi= pe[POLL_WRITE], &dummy,
>> =A0 =A0 =A0 =A0 sizeof(dummy));
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->set =3D 1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0 @@ -203,7 +203,7 @@ tapdisk_stream_print_request(s= truct tapd
>> =A0 =A0 =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long idx =3D (unsigned
>> =A0 =A0 =A0 =A0 long)tapdisk_stream_request_idx(s, sreq);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *buf =3D (char *)MMAP_VADDR(s-= >vbd->ring.vstart,
>> =A0 =A0 =A0 =A0 idx, 0);
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 write(s->out_fd, buf, sreq->se= cs << SECTOR_SHIFT);
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 (void)write(s->out_fd, buf, sreq-= >secs <<
>> =A0 =A0 =A0 =A0 SECTOR_SHIFT);
>> =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0 =A0 =A0static void
>> =A0 =A0 =A0 =A0 diff -r adc74e492edf -r 15ed8f45c4e5
>> =A0 =A0 =A0 =A0 tools/blktap2/drivers/tapdisk2.c
>> =A0 =A0 =A0 =A0 --- a/tools/blktap2/drivers/tapdisk2.c =A0Fri May = 11 16:19:16
>> =A0 =A0 =A0 =A0 2012 +0100
>> =A0 =A0 =A0 =A0 +++ b/tools/blktap2/drivers/tapdisk2.c =A0Fri May = 11 16:46:15
>> =A0 =A0 =A0 =A0 2012 +0100
>> =A0 =A0 =A0 =A0 @@ -79,7 +79,12 @@ main(int argc, char *argv[]) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (optind !=3D argc)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usage(argv[0], EINV= AL);
>>
>> =A0 =A0 =A0 =A0 - =A0 =A0 =A0 chdir("/");
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 if (chdir("/")) {
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DPRINTF("failed= to chdir(/): %d\n", errno);
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D 1;
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>> =A0 =A0 =A0 =A0 + =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 +
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tapdisk_start_logging("tapdisk= 2");
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D tapdisk_server_init();
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Bei Guan
>>
>
>




--
Best Regard= s,
Bei Guan

--f46d0421ad61e2012804bfc5a10d-- --===============6399305107554103395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6399305107554103395==-- From xen-devel-bounces@lists.xen.org Fri May 11 16:58:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:58:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStAj-00042e-Uv; Fri, 11 May 2012 16:58:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStAi-00042P-Nw for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:58:29 +0000 Received: from [85.158.138.51:45072] by server-5.bemta-3.messagelabs.com id CF/16-17113-3354DAF4; Fri, 11 May 2012 16:58:27 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336755505!18613287!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27615 invoked from network); 11 May 2012 16:58:26 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-6.tower-174.messagelabs.com with SMTP; 11 May 2012 16:58:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 09:58:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99033893" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 09:58:11 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 09:58:11 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Sat, 12 May 2012 00:58:09 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: AQHNL38KJV8RtIigTTax7Uicx2M6K5bEzH6w Date: Fri, 11 May 2012 16:58:08 +0000 Message-ID: References: <20120511140454.GA13735@phenom.dumpdata.com> In-Reply-To: <20120511140454.GA13735@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Thu, May 10, 2012 at 03:06:14PM +0000, Liu, Jinsong wrote: >>> From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 >>> 2001 >> From: Liu, Jinsong >> Date: Fri, 11 May 2012 06:55:35 +0800 >> Subject: [PATCH 3/3] Xen physical cpus interface >> >> Manage physical cpus in dom0, get physical cpus info and provide sys >> interface. >> >> Signed-off-by: Liu, Jinsong >> Signed-off-by: Jiang, Yunhong --- >> .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + >> drivers/xen/Makefile | 1 + >> drivers/xen/pcpu.c | 374 >> ++++++++++++++++++++ include/xen/interface/platform.h >> | 8 + include/xen/interface/xen.h | 1 + >> 5 files changed, 404 insertions(+), 0 deletions(-) >> create mode 100644 >> Documentation/ABI/testing/sysfs-devices-system-xen_cpu create mode >> 100644 drivers/xen/pcpu.c >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu >> b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu new file >> mode 100644 index 0000000..9ca02fb --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu @@ -0,0 >> +1,20 @@ +What: /sys/devices/system/xen_cpu/ >> +Date: May 2012 >> +Contact: Liu, Jinsong >> +Description: >> + A collection of global/individual Xen physical cpu attributes + >> + Individual physical cpu attributes are contained in >> + subdirectories named by the Xen's logical cpu number, e.g.: >> + /sys/devices/system/xen_cpu/xen_cpu#/ >> + >> + >> +What: /sys/devices/system/xen_cpu/xen_cpu#/online +Date: May 2012 >> +Contact: Liu, Jinsong >> +Description: >> + Interface to online/offline Xen physical cpus >> + >> + When running under Xen platform, it provide user interface >> + to online/offline physical cpus, except cpu0 due to several >> + logic restrictions and assumptions. >> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile >> index 1d3e763..d12d14d 100644 >> --- a/drivers/xen/Makefile >> +++ b/drivers/xen/Makefile >> @@ -19,6 +19,7 @@ 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_DOM0) += pcpu.o >> obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ >> obj-$(CONFIG_XEN_PRIVCMD) += xen-privcmd.o >> obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o >> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c >> new file mode 100644 >> index 0000000..9014ff1 >> --- /dev/null >> +++ b/drivers/xen/pcpu.c >> @@ -0,0 +1,374 @@ >> +/****************************************************************************** >> + * pcpu.c + * Management physical cpu in dom0, get pcpu info and >> provide sys interface + * + * Copyright (c) 2012 Intel Corporation >> + * Author: Liu, Jinsong >> + * Author: Jiang, Yunhong + * >> + * This program is free software; you can 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 >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define XEN_PCPU "xen_cpu: " >> + >> +/* >> + * @cpu_id: Xen physical cpu logic number >> + * @flags: Xen physical cpu status flag >> + * - XEN_PCPU_FLAGS_ONLINE: cpu is online >> + * - XEN_PCPU_FLAGS_INVALID: cpu is not present >> + */ >> +struct pcpu { >> + struct list_head list; >> + struct device dev; >> + uint32_t cpu_id; >> + uint32_t flags; >> +}; >> + >> +static struct bus_type xen_pcpu_subsys = { >> + .name = "xen_cpu", >> + .dev_name = "xen_cpu", >> +}; >> + >> +static DEFINE_MUTEX(xen_pcpu_lock); >> + >> +static LIST_HEAD(xen_pcpus); > > So what about the recommendation to get rid of that and > instead do > > struct pcpu *xen_cpu; I'm not quite clear your meaning here, do you mean 'LIST_HEAD(xen_pcpus)' instead of 'struct pcpu *xen_cpu'? > > and use that as a list? Meaning > .. snip.. >> +{ >> + struct list_head *cur; >> + struct pcpu *pcpu; >> + >> + list_for_each(cur, &xen_pcpus) { >> + pcpu = list_entry(cur, struct pcpu, list); >> + if (pcpu->cpu_id == cpu_id) >> + return pcpu; >> + } > > do: > struct pcpu *pcpu; > > list_for_each_entry(pcpu, xen_pcpus, list) > if (pcpu->cpu_id == cpu_id) > return pcpu; > ? > > and such. OK for me to update. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 16:58:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 16:58:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStAj-00042e-Uv; Fri, 11 May 2012 16:58:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStAi-00042P-Nw for xen-devel@lists.xensource.com; Fri, 11 May 2012 16:58:29 +0000 Received: from [85.158.138.51:45072] by server-5.bemta-3.messagelabs.com id CF/16-17113-3354DAF4; Fri, 11 May 2012 16:58:27 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336755505!18613287!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27615 invoked from network); 11 May 2012 16:58:26 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-6.tower-174.messagelabs.com with SMTP; 11 May 2012 16:58:26 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 09:58:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99033893" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 09:58:11 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 09:58:11 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Sat, 12 May 2012 00:58:09 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: AQHNL38KJV8RtIigTTax7Uicx2M6K5bEzH6w Date: Fri, 11 May 2012 16:58:08 +0000 Message-ID: References: <20120511140454.GA13735@phenom.dumpdata.com> In-Reply-To: <20120511140454.GA13735@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Thu, May 10, 2012 at 03:06:14PM +0000, Liu, Jinsong wrote: >>> From 7aa4cf7c1172e24611dc76163397b8708acacc59 Mon Sep 17 00:00:00 >>> 2001 >> From: Liu, Jinsong >> Date: Fri, 11 May 2012 06:55:35 +0800 >> Subject: [PATCH 3/3] Xen physical cpus interface >> >> Manage physical cpus in dom0, get physical cpus info and provide sys >> interface. >> >> Signed-off-by: Liu, Jinsong >> Signed-off-by: Jiang, Yunhong --- >> .../ABI/testing/sysfs-devices-system-xen_cpu | 20 + >> drivers/xen/Makefile | 1 + >> drivers/xen/pcpu.c | 374 >> ++++++++++++++++++++ include/xen/interface/platform.h >> | 8 + include/xen/interface/xen.h | 1 + >> 5 files changed, 404 insertions(+), 0 deletions(-) >> create mode 100644 >> Documentation/ABI/testing/sysfs-devices-system-xen_cpu create mode >> 100644 drivers/xen/pcpu.c >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu >> b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu new file >> mode 100644 index 0000000..9ca02fb --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu @@ -0,0 >> +1,20 @@ +What: /sys/devices/system/xen_cpu/ >> +Date: May 2012 >> +Contact: Liu, Jinsong >> +Description: >> + A collection of global/individual Xen physical cpu attributes + >> + Individual physical cpu attributes are contained in >> + subdirectories named by the Xen's logical cpu number, e.g.: >> + /sys/devices/system/xen_cpu/xen_cpu#/ >> + >> + >> +What: /sys/devices/system/xen_cpu/xen_cpu#/online +Date: May 2012 >> +Contact: Liu, Jinsong >> +Description: >> + Interface to online/offline Xen physical cpus >> + >> + When running under Xen platform, it provide user interface >> + to online/offline physical cpus, except cpu0 due to several >> + logic restrictions and assumptions. >> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile >> index 1d3e763..d12d14d 100644 >> --- a/drivers/xen/Makefile >> +++ b/drivers/xen/Makefile >> @@ -19,6 +19,7 @@ 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_DOM0) += pcpu.o >> obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ >> obj-$(CONFIG_XEN_PRIVCMD) += xen-privcmd.o >> obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o >> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c >> new file mode 100644 >> index 0000000..9014ff1 >> --- /dev/null >> +++ b/drivers/xen/pcpu.c >> @@ -0,0 +1,374 @@ >> +/****************************************************************************** >> + * pcpu.c + * Management physical cpu in dom0, get pcpu info and >> provide sys interface + * + * Copyright (c) 2012 Intel Corporation >> + * Author: Liu, Jinsong >> + * Author: Jiang, Yunhong + * >> + * This program is free software; you can 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 >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define XEN_PCPU "xen_cpu: " >> + >> +/* >> + * @cpu_id: Xen physical cpu logic number >> + * @flags: Xen physical cpu status flag >> + * - XEN_PCPU_FLAGS_ONLINE: cpu is online >> + * - XEN_PCPU_FLAGS_INVALID: cpu is not present >> + */ >> +struct pcpu { >> + struct list_head list; >> + struct device dev; >> + uint32_t cpu_id; >> + uint32_t flags; >> +}; >> + >> +static struct bus_type xen_pcpu_subsys = { >> + .name = "xen_cpu", >> + .dev_name = "xen_cpu", >> +}; >> + >> +static DEFINE_MUTEX(xen_pcpu_lock); >> + >> +static LIST_HEAD(xen_pcpus); > > So what about the recommendation to get rid of that and > instead do > > struct pcpu *xen_cpu; I'm not quite clear your meaning here, do you mean 'LIST_HEAD(xen_pcpus)' instead of 'struct pcpu *xen_cpu'? > > and use that as a list? Meaning > .. snip.. >> +{ >> + struct list_head *cur; >> + struct pcpu *pcpu; >> + >> + list_for_each(cur, &xen_pcpus) { >> + pcpu = list_entry(cur, struct pcpu, list); >> + if (pcpu->cpu_id == cpu_id) >> + return pcpu; >> + } > > do: > struct pcpu *pcpu; > > list_for_each_entry(pcpu, xen_pcpus, list) > if (pcpu->cpu_id == cpu_id) > return pcpu; > ? > > and such. OK for me to update. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:02:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStEl-0004MA-Qa; Fri, 11 May 2012 17:02:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEj-0004Lt-Sc for xen-devel@lists.xen.org; Fri, 11 May 2012 17:02:38 +0000 Received: from [193.109.254.147:38942] by server-2.bemta-14.messagelabs.com id 58/EC-19409-D264DAF4; Fri, 11 May 2012 17:02:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336755756!1139020!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26460 invoked from network); 11 May 2012 17:02:36 -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; 11 May 2012 17:02:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434961" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:01: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; Fri, 11 May 2012 18:01:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStDh-0007zB-Be; Fri, 11 May 2012 17:01:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStDh-0002d5-9h; Fri, 11 May 2012 18:01:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17901.273097.286232@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:01:33 +0100 To: Keir Fraser Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel , Bei Guan , Ian Campbell Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ~Keir Fraser writes ("Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable?"): > On 11/05/2012 17:33, "Bei Guan" wrote: > Yes, I add this option to Makefile. And now it works well. The patch is as the > > following. Thank you very much. > > I'd be worried about more command-line meddling causing even more fallout. > Particularly because we haven't used that option anywhere else so far, so > it's untested by us. E.g., do all gcc support -Wno-unused-result? Checking the manuals (which are all online), gcc 4.0 doesn't support it. So no, relevant gccs don't. However the tools build now uses autoconf. I would accept a patch which used autoconf to determine whether gcc accepts -Wno-unused-result and to supply it in the blktap2 Makefile if it does. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:02:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStEl-0004MA-Qa; Fri, 11 May 2012 17:02:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEj-0004Lt-Sc for xen-devel@lists.xen.org; Fri, 11 May 2012 17:02:38 +0000 Received: from [193.109.254.147:38942] by server-2.bemta-14.messagelabs.com id 58/EC-19409-D264DAF4; Fri, 11 May 2012 17:02:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1336755756!1139020!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26460 invoked from network); 11 May 2012 17:02:36 -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; 11 May 2012 17:02:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12434961" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:01: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; Fri, 11 May 2012 18:01:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStDh-0007zB-Be; Fri, 11 May 2012 17:01:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStDh-0002d5-9h; Fri, 11 May 2012 18:01:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.17901.273097.286232@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:01:33 +0100 To: Keir Fraser Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel , Bei Guan , Ian Campbell Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org ~Keir Fraser writes ("Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable?"): > On 11/05/2012 17:33, "Bei Guan" wrote: > Yes, I add this option to Makefile. And now it works well. The patch is as the > > following. Thank you very much. > > I'd be worried about more command-line meddling causing even more fallout. > Particularly because we haven't used that option anywhere else so far, so > it's untested by us. E.g., do all gcc support -Wno-unused-result? Checking the manuals (which are all online), gcc 4.0 doesn't support it. So no, relevant gccs don't. However the tools build now uses autoconf. I would accept a patch which used autoconf to determine whether gcc accepts -Wno-unused-result and to supply it in the blktap2 Makefile if it does. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:02:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEs-0004NX-6n; Fri, 11 May 2012 17:02:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEr-0004NF-Rl for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:02:45 +0000 Received: from [85.158.143.99:35843] by server-2.bemta-4.messagelabs.com id 64/76-17550-5364DAF4; Fri, 11 May 2012 17:02:45 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1336755763!17815856!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1249 invoked from network); 11 May 2012 17:02:44 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 17:02:44 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id B8EA7541C6; Fri, 11 May 2012 19:02:40 +0200 (CEST) Date: Fri, 11 May 2012 19:02:40 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120511170240.GA15662@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , Ian Jackson , "xen-devel@lists.xensource.com" , Stefano Stabellini References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336754999.23818.144.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stefano Stabellini , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > --- /dev/null > +++ b/tools/xenstore/compat/xs.h Why not in tools/xenstore? > +#ifndef XENSTORE_COMPAT_H > +#define XENSTORE_COMPAT_H Don't. Bastian -- Well, Jim, I'm not much of an actor either. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:02:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEs-0004NX-6n; Fri, 11 May 2012 17:02:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStEr-0004NF-Rl for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:02:45 +0000 Received: from [85.158.143.99:35843] by server-2.bemta-4.messagelabs.com id 64/76-17550-5364DAF4; Fri, 11 May 2012 17:02:45 +0000 X-Env-Sender: waldi@debian.org X-Msg-Ref: server-8.tower-216.messagelabs.com!1336755763!17815856!1 X-Originating-IP: [82.139.201.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1249 invoked from network); 11 May 2012 17:02:44 -0000 Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org) (82.139.201.20) by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 17:02:44 -0000 Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000) id B8EA7541C6; Fri, 11 May 2012 19:02:40 +0200 (CEST) Date: Fri, 11 May 2012 19:02:40 +0200 From: Bastian Blank To: Ian Campbell Message-ID: <20120511170240.GA15662@wavehammer.waldi.eu.org> Mail-Followup-To: Bastian Blank , Ian Campbell , Ian Jackson , "xen-devel@lists.xensource.com" , Stefano Stabellini References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1336754999.23818.144.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stefano Stabellini , "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > --- /dev/null > +++ b/tools/xenstore/compat/xs.h Why not in tools/xenstore? > +#ifndef XENSTORE_COMPAT_H > +#define XENSTORE_COMPAT_H Don't. Bastian -- Well, Jim, I'm not much of an actor either. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:07:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJ6-0004gE-VE; Fri, 11 May 2012 17:07:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJ6-0004g3-31 for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:07:08 +0000 Received: from [85.158.139.83:23779] by server-7.bemta-5.messagelabs.com id 56/0D-16195-B374DAF4; Fri, 11 May 2012 17:07:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336756026!16652656!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4770 invoked from network); 11 May 2012 17:07:06 -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; 11 May 2012 17:07:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435091" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:07:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:07:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStJ4-000817-3E; Fri, 11 May 2012 17:07:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStJ4-0002du-2A; Fri, 11 May 2012 18:07:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.18234.50742.594420@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:07:06 +0100 To: Bastian Blank In-Reply-To: <20120511170240.GA15662@wavehammer.waldi.eu.org> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bastian Blank writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"): > On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > > --- /dev/null > > +++ b/tools/xenstore/compat/xs.h > > Why not in tools/xenstore? Good question. One answer is that this prevents in-tree users from accidentally using the old header - but do we really care about that ? > > +#ifndef XENSTORE_COMPAT_H > > +#define XENSTORE_COMPAT_H > > Don't. I guess you mean that we want a warning each time is #included, rather than only the first time. In which case I agree. Ian: I tried your patch but it didn't seem to apply to my current tip. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:07:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJ6-0004gE-VE; Fri, 11 May 2012 17:07:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJ6-0004g3-31 for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:07:08 +0000 Received: from [85.158.139.83:23779] by server-7.bemta-5.messagelabs.com id 56/0D-16195-B374DAF4; Fri, 11 May 2012 17:07:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1336756026!16652656!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4770 invoked from network); 11 May 2012 17:07:06 -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; 11 May 2012 17:07:06 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435091" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:07:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:07:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStJ4-000817-3E; Fri, 11 May 2012 17:07:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStJ4-0002du-2A; Fri, 11 May 2012 18:07:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20397.18234.50742.594420@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:07:06 +0100 To: Bastian Blank In-Reply-To: <20120511170240.GA15662@wavehammer.waldi.eu.org> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bastian Blank writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"): > On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > > --- /dev/null > > +++ b/tools/xenstore/compat/xs.h > > Why not in tools/xenstore? Good question. One answer is that this prevents in-tree users from accidentally using the old header - but do we really care about that ? > > +#ifndef XENSTORE_COMPAT_H > > +#define XENSTORE_COMPAT_H > > Don't. I guess you mean that we want a warning each time is #included, rather than only the first time. In which case I agree. Ian: I tried your patch but it didn't seem to apply to my current tip. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:08:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SStJz-0004kg-52; Fri, 11 May 2012 17:08:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJx-0004kT-Sm for xen-devel@lists.xen.org; Fri, 11 May 2012 17:08:02 +0000 Received: from [85.158.143.99:51423] by server-3.bemta-4.messagelabs.com id 78/40-05853-1774DAF4; Fri, 11 May 2012 17:08:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336756079!17816480!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15704 invoked from network); 11 May 2012 17:08:00 -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; 11 May 2012 17:08:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435097" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:07: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; Fri, 11 May 2012 18:07:58 +0100 Date: Fri, 11 May 2012 18:07:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FAD3C0802000078000830D8@nat28.tlf.novell.com> Message-ID: References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> <4FAD3C0802000078000830D8@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Olaf Hering , Stefano Stabellini , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 11 May 2012, Jan Beulich wrote: > >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: > > Legacy (non-pvops) gntdev drivers may require this to be done when the > > number of grants intended to be used simultaneously exceeds a certain > > driver specific default limit. > > > > Signed-off-by: Jan Beulich > > > > --- a/hw/xen_disk.c > > +++ b/hw/xen_disk.c > > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > > if (xen_mode != XEN_EMULATE) { > > batch_maps = 1; > > } > > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) > > In more extensive testing it appears that very rarely this value is still > too low: > > xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) > > 342 + 11 = 353 > 352 = 32 * 11 > > Could someone help out here? I first thought this might be due to > use_aio being non-zero, but ioreq_start() doesn't permit more than > max_requests struct ioreqs-s to be around. Actually 342 + 11 = 353, that should be still OK because it is equal to 32 * 11 + 1, where the additional 1 is for the ring, right? > Additionally, shouldn't the driver be smarter and gracefully handle > grant mapping failures (as the per-domain map track table in the > hypervisor is a finite resource)? yes, probably _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:08:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 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 ) id 1SStJz-0004kg-52; Fri, 11 May 2012 17:08:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStJx-0004kT-Sm for xen-devel@lists.xen.org; Fri, 11 May 2012 17:08:02 +0000 Received: from [85.158.143.99:51423] by server-3.bemta-4.messagelabs.com id 78/40-05853-1774DAF4; Fri, 11 May 2012 17:08:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336756079!17816480!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15704 invoked from network); 11 May 2012 17:08:00 -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; 11 May 2012 17:08:00 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435097" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:07: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; Fri, 11 May 2012 18:07:58 +0100 Date: Fri, 11 May 2012 18:07:42 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball-desktop To: Jan Beulich In-Reply-To: <4FAD3C0802000078000830D8@nat28.tlf.novell.com> Message-ID: References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> <4FAD3C0802000078000830D8@nat28.tlf.novell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Cc: Olaf Hering , Stefano Stabellini , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 11 May 2012, Jan Beulich wrote: > >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: > > Legacy (non-pvops) gntdev drivers may require this to be done when the > > number of grants intended to be used simultaneously exceeds a certain > > driver specific default limit. > > > > Signed-off-by: Jan Beulich > > > > --- a/hw/xen_disk.c > > +++ b/hw/xen_disk.c > > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > > if (xen_mode != XEN_EMULATE) { > > batch_maps = 1; > > } > > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) > > In more extensive testing it appears that very rarely this value is still > too low: > > xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) > > 342 + 11 = 353 > 352 = 32 * 11 > > Could someone help out here? I first thought this might be due to > use_aio being non-zero, but ioreq_start() doesn't permit more than > max_requests struct ioreqs-s to be around. Actually 342 + 11 = 353, that should be still OK because it is equal to 32 * 11 + 1, where the additional 1 is for the ring, right? > Additionally, shouldn't the driver be smarter and gracefully handle > grant mapping failures (as the per-domain map track table in the > hypervisor is a finite resource)? yes, probably _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStLX-0004ya-Lr; Fri, 11 May 2012 17:09:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStLW-0004yH-2c for xen-devel@lists.xen.org; Fri, 11 May 2012 17:09:38 +0000 Received: from [85.158.143.99:10022] by server-1.bemta-4.messagelabs.com id B0/47-20925-1D74DAF4; Fri, 11 May 2012 17:09:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336756175!27615609!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13639 invoked from network); 11 May 2012 17:09:36 -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; 11 May 2012 17:09:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:09: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, 11 May 2012 18:09:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStLS-00081t-I4 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:09:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStLS-0002eW-HQ for xen-devel@lists.xen.org; Fri, 11 May 2012 18:09:34 +0100 From: Ian Jackson Message-ID: <20397.18382.526907.218622@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:09:34 +0100 MIME-Version: 1.0 To: xen-devel@lists.xen.org X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: [Xen-devel] Tools patch backlog cleared (I hope) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I think I have got to the end of my list mail backlog. If you have submitted something and not had a reply, I have dropped it and you should resend. Thanks to everyone for your patience. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStLX-0004ya-Lr; Fri, 11 May 2012 17:09:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStLW-0004yH-2c for xen-devel@lists.xen.org; Fri, 11 May 2012 17:09:38 +0000 Received: from [85.158.143.99:10022] by server-1.bemta-4.messagelabs.com id B0/47-20925-1D74DAF4; Fri, 11 May 2012 17:09:37 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1336756175!27615609!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13639 invoked from network); 11 May 2012 17:09:36 -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; 11 May 2012 17:09:36 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:09: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, 11 May 2012 18:09:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SStLS-00081t-I4 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:09:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SStLS-0002eW-HQ for xen-devel@lists.xen.org; Fri, 11 May 2012 18:09:34 +0100 From: Ian Jackson Message-ID: <20397.18382.526907.218622@mariner.uk.xensource.com> Date: Fri, 11 May 2012 18:09:34 +0100 MIME-Version: 1.0 To: xen-devel@lists.xen.org X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: [Xen-devel] Tools patch backlog cleared (I hope) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I think I have got to the end of my list mail backlog. If you have submitted something and not had a reply, I have dropped it and you should resend. Thanks to everyone for your patience. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:23:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStYP-0005pu-PX; Fri, 11 May 2012 17:22:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStYO-0005pp-IY for xen-devel@lists.xen.org; Fri, 11 May 2012 17:22:56 +0000 Received: from [85.158.138.51:25673] by server-6.bemta-3.messagelabs.com id 0A/96-05145-FEA4DAF4; Fri, 11 May 2012 17:22:55 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336756973!22603136!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31883 invoked from network); 11 May 2012 17:22:54 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:22:54 -0000 Received: by lbok6 with SMTP id k6so2567148lbo.32 for ; Fri, 11 May 2012 10:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=t8ukL8cByCAJkNU7+Tio7ZIRLo2yINu+AlxR2/k8Qn0=; b=pHme3v8v5bW96d6Jo/KpOCijXq1fKOM5Jq+QT8t0JsMFNWoezUDL3cSyq481eOxym+ 6nHUswzdZ/1UJKwGZ3N478wmfT2X5RUKVla6KS7pnkwTjioRW8XIA2NtYTAnIgZvfJHL JYAGLBd7CGGqQ3r2AEzNu6JFvpGyFUEFqeEs7/eshCRQNqf0RnqdSlY9pPMMFmWhBUOC gxAEQg4e8r5TSYdpbb78nJnE68zsC44WzKItJWUjT6/dxDtgw7/Fg09JutHaytwaPgdV ITNxPzi2DIK5t0poGufFeh5IXEGJRlaKs7iaCT2Cy8N4gZhFPiU8XJRV8mqxjXtqpm+Y uW+Q== MIME-Version: 1.0 Received: by 10.152.111.198 with SMTP id ik6mr9037240lab.38.1336756973255; Fri, 11 May 2012 10:22:53 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 10:22:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 12 May 2012 01:22:53 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3326488397959265117==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3326488397959265117== Content-Type: multipart/alternative; boundary=f46d040839898aba9804bfc5fc7f --f46d040839898aba9804bfc5fc7f Content-Type: text/plain; charset=ISO-8859-1 Hi, This problem is solved now. My environment is 64-bit ubuntu and xl needs to find libyajl from the following paths. trying file=/lib/libyajl.so.2 trying file=/usr/lib/libyajl.so.2 trying file=/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2 trying file=/lib/x86_64-linux-gnu/tls/libyajl.so.2 ... However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 where I just installed into. So, a symbolic link is enough to solve this problem. Just like this: # ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2 Thanks, Bei Guan 2012/5/12 Bei Guan > Hi, > > When I do "xl list", there is an error like this: > > root@gavin-desktop:~# xl list > xl: error while loading shared libraries: libyajl.so.2: cannot open shared > object file: No such file or directory > > I install the yajl followed this message: > http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html > > After that, the module libyajl.so.2 is copied to /usr/local/lib/. > > Is there any advice on this problem. Thank you so much. > > > Best Regards, > Bei Guan > > -- Best Regards, Bei Guan --f46d040839898aba9804bfc5fc7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

This problem is solved now.

My environment is 64-bit ubun= tu and xl needs to find libyajl from the following paths.

=A0=A0 try= ing file=3D/lib/libyajl.so.2
=A0=A0 trying file=3D/usr/lib/libyajl.so.2<= br>=A0=A0 trying file=3D/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2
=A0=A0 trying file=3D/lib/x86_64-linux-gnu/tls/libyajl.so.2
=A0 ...
<= br>However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 w= here I just installed into.
So, a symbolic link is enough to solve this = problem. Just like this:
# ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2


Thank= s,
Bei Guan




2012/5/12 Bei = Guan <gbtju85@gmail.com>
Hi,

When I do &quo= t;xl list", there is an error like this:

root@gavin-desktop:~# = xl list
xl: error while loading shared libraries: libyajl.so.2: cannot open shared = object file: No such file or directory

I install the yajl followed this message:
http= ://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html

After that, the module libyajl.so.2 is copied to /usr/local/lib/.

Is there any advice on this problem. Thank you so much.


Best= Regards,
Bei Guan




--
Best Regards,
Bei G= uan

--f46d040839898aba9804bfc5fc7f-- --===============3326488397959265117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3326488397959265117==-- From xen-devel-bounces@lists.xen.org Fri May 11 17:23:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SStYP-0005pu-PX; Fri, 11 May 2012 17:22:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SStYO-0005pp-IY for xen-devel@lists.xen.org; Fri, 11 May 2012 17:22:56 +0000 Received: from [85.158.138.51:25673] by server-6.bemta-3.messagelabs.com id 0A/96-05145-FEA4DAF4; Fri, 11 May 2012 17:22:55 +0000 X-Env-Sender: gbtju85@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1336756973!22603136!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31883 invoked from network); 11 May 2012 17:22:54 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:22:54 -0000 Received: by lbok6 with SMTP id k6so2567148lbo.32 for ; Fri, 11 May 2012 10:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=t8ukL8cByCAJkNU7+Tio7ZIRLo2yINu+AlxR2/k8Qn0=; b=pHme3v8v5bW96d6Jo/KpOCijXq1fKOM5Jq+QT8t0JsMFNWoezUDL3cSyq481eOxym+ 6nHUswzdZ/1UJKwGZ3N478wmfT2X5RUKVla6KS7pnkwTjioRW8XIA2NtYTAnIgZvfJHL JYAGLBd7CGGqQ3r2AEzNu6JFvpGyFUEFqeEs7/eshCRQNqf0RnqdSlY9pPMMFmWhBUOC gxAEQg4e8r5TSYdpbb78nJnE68zsC44WzKItJWUjT6/dxDtgw7/Fg09JutHaytwaPgdV ITNxPzi2DIK5t0poGufFeh5IXEGJRlaKs7iaCT2Cy8N4gZhFPiU8XJRV8mqxjXtqpm+Y uW+Q== MIME-Version: 1.0 Received: by 10.152.111.198 with SMTP id ik6mr9037240lab.38.1336756973255; Fri, 11 May 2012 10:22:53 -0700 (PDT) Received: by 10.112.23.194 with HTTP; Fri, 11 May 2012 10:22:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 12 May 2012 01:22:53 +0800 Message-ID: From: Bei Guan To: xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3326488397959265117==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3326488397959265117== Content-Type: multipart/alternative; boundary=f46d040839898aba9804bfc5fc7f --f46d040839898aba9804bfc5fc7f Content-Type: text/plain; charset=ISO-8859-1 Hi, This problem is solved now. My environment is 64-bit ubuntu and xl needs to find libyajl from the following paths. trying file=/lib/libyajl.so.2 trying file=/usr/lib/libyajl.so.2 trying file=/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2 trying file=/lib/x86_64-linux-gnu/tls/libyajl.so.2 ... However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 where I just installed into. So, a symbolic link is enough to solve this problem. Just like this: # ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2 Thanks, Bei Guan 2012/5/12 Bei Guan > Hi, > > When I do "xl list", there is an error like this: > > root@gavin-desktop:~# xl list > xl: error while loading shared libraries: libyajl.so.2: cannot open shared > object file: No such file or directory > > I install the yajl followed this message: > http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html > > After that, the module libyajl.so.2 is copied to /usr/local/lib/. > > Is there any advice on this problem. Thank you so much. > > > Best Regards, > Bei Guan > > -- Best Regards, Bei Guan --f46d040839898aba9804bfc5fc7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

This problem is solved now.

My environment is 64-bit ubun= tu and xl needs to find libyajl from the following paths.

=A0=A0 try= ing file=3D/lib/libyajl.so.2
=A0=A0 trying file=3D/usr/lib/libyajl.so.2<= br>=A0=A0 trying file=3D/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2
=A0=A0 trying file=3D/lib/x86_64-linux-gnu/tls/libyajl.so.2
=A0 ...
<= br>However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 w= here I just installed into.
So, a symbolic link is enough to solve this = problem. Just like this:
# ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2


Thank= s,
Bei Guan




2012/5/12 Bei = Guan <gbtju85@gmail.com>
Hi,

When I do &quo= t;xl list", there is an error like this:

root@gavin-desktop:~# = xl list
xl: error while loading shared libraries: libyajl.so.2: cannot open shared = object file: No such file or directory

I install the yajl followed this message:
http= ://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html

After that, the module libyajl.so.2 is copied to /usr/local/lib/.

Is there any advice on this problem. Thank you so much.


Best= Regards,
Bei Guan




--
Best Regards,
Bei G= uan

--f46d040839898aba9804bfc5fc7f-- --===============3326488397959265117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3326488397959265117==-- From xen-devel-bounces@lists.xen.org Fri May 11 17:28:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSte1-0005yb-IQ; Fri, 11 May 2012 17:28:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSte0-0005yV-Jo for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:28:44 +0000 Received: from [193.109.254.147:4371] by server-8.bemta-14.messagelabs.com id 88/C6-23244-B4C4DAF4; Fri, 11 May 2012 17:28:43 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336757322!6404978!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc4Nzcw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13373 invoked from network); 11 May 2012 17:28:43 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-5.tower-27.messagelabs.com with SMTP; 11 May 2012 17:28:43 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 May 2012 10:28:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141961125" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 10:28:41 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 10:28:41 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 01:28:39 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: AQHNL4DoJV8RtIigTTax7Uicx2M6K5bEz5ng Date: Fri, 11 May 2012 17:28:38 +0000 Message-ID: References: <20120511141817.GB13735@phenom.dumpdata.com> In-Reply-To: <20120511141817.GB13735@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: >> +static void pcpu_sys_remove(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + >> + if (!pcpu) >> + return; >> + >> + dev = &pcpu->dev; >> + if (dev->id) >> + device_remove_file(dev, &dev_attr_online); >> + >> + device_unregister(dev); >> +} >> + >> +static void free_pcpu(struct pcpu *pcpu) > > 1) So this isn't just freeing the PCPU, it also unregisters > the SysFS. > > As such you should call this differently: > > unregister_and_free(struct pcpu *pcpu) Fine, rename 2 funcs: init_pcpu --> int_and_register_pcpu free_pcpu --> unregister_and_free_pcpu > > or do the unregistration part seperatly. > > 2) But there is also another issue - a possiblity of race. > > The user might be running: > while (true) > do > echo 1 > online > echo 0 > online > done > > and the the sync_pcpu will end up calling pcpu_sys_remove and > free the pcpu. The SysFS aren't deleted until all of the No race here. echo x > online would not change cpu present map. > object references (kref's) have been put. So when you get to > 'kfree(pcpu)' you might be still holding a reference (meaning > the user is doing 'echo 0 > online') and crash. > > I think you need to hold the mutex in the store_online() function > (not good), or better yet, make a device_release function > that will be called when the last kref has been put. > > > 3) Third the name. These functions all depend on the mutex lock being > held. As such add a postfix to the name of the function of > "_locked" or a prefix of "__' so it is known that the caller holds > the mutex. OK, add _locked postfix to these functions. Thanks, Jinsong > >> +{ >> + if (!pcpu) >> + return; >> + >> + pcpu_sys_remove(pcpu); >> + >> + list_del(&pcpu->list); >> + kfree(pcpu); >> +} >> + >> +static int pcpu_sys_create(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + int err = -EINVAL; >> + >> + if (!pcpu) >> + return err; >> + >> + dev = &pcpu->dev; >> + dev->bus = &xen_pcpu_subsys; >> + dev->id = pcpu->cpu_id; >> + >> + err = device_register(dev); >> + if (err) >> + return err; >> + >> + /* >> + * Xen never offline cpu0 due to several restrictions >> + * and assumptions. This basically doesn't add a sys control >> + * to user, one cannot attempt to offline BSP. >> + */ >> + if (dev->id) { >> + err = device_create_file(dev, &dev_attr_online); + if (err) { >> + device_unregister(dev); >> + return err; >> + } >> + } >> + >> + return 0; >> +} >> + >> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) +{ >> + struct pcpu *pcpu; >> + int err; >> + >> + if (info->flags & XEN_PCPU_FLAGS_INVALID) >> + return ERR_PTR(-ENODEV); >> + >> + pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL); >> + if (!pcpu) >> + return ERR_PTR(-ENOMEM); >> + >> + INIT_LIST_HEAD(&pcpu->list); >> + pcpu->cpu_id = info->xen_cpuid; >> + pcpu->flags = info->flags; >> + >> + err = pcpu_sys_create(pcpu); >> + if (err) { >> + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", + >> info->xen_cpuid); + kfree(pcpu); >> + return ERR_PTR(-ENOENT); >> + } >> + >> + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ >> + list_add_tail(&pcpu->list, &xen_pcpus); >> + return pcpu; >> +} >> + >> +/* >> + * Caller should hold the xen_pcpu_lock >> + */ >> +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) +{ >> + int ret; >> + struct pcpu *pcpu = NULL; >> + struct xenpf_pcpuinfo *info; >> + struct xen_platform_op op = { >> + .cmd = XENPF_get_cpuinfo, >> + .interface_version = XENPF_INTERFACE_VERSION, >> + .u.pcpu_info.xen_cpuid = cpu, >> + }; >> + >> + ret = HYPERVISOR_dom0_op(&op); >> + if (ret) >> + return ret; >> + >> + info = &op.u.pcpu_info; >> + if (max_cpu) >> + *max_cpu = info->max_present; >> + >> + pcpu = get_pcpu(cpu); >> + >> + if (info->flags & XEN_PCPU_FLAGS_INVALID) { >> + /* The pcpu has been removed */ >> + if (pcpu) >> + free_pcpu(pcpu); >> + return 0; >> + } >> + >> + if (!pcpu) { >> + pcpu = init_pcpu(info); >> + if (IS_ERR_OR_NULL(pcpu)) >> + return -ENODEV; >> + } else >> + pcpu_online_status(info, pcpu); >> + >> + return 0; >> +} >> + >> +/* >> + * Sync dom0's pcpu information with xen hypervisor's + */ >> +static int xen_sync_pcpus(void) >> +{ >> + /* >> + * Boot cpu always have cpu_id 0 in xen >> + */ >> + uint32_t cpu = 0, max_cpu = 0; >> + int err = 0; >> + struct list_head *cur, *tmp; >> + struct pcpu *pcpu; >> + >> + mutex_lock(&xen_pcpu_lock); >> + >> + while (!err && (cpu <= max_cpu)) { >> + err = sync_pcpu(cpu, &max_cpu); >> + cpu++; >> + } >> + >> + if (err) { >> + list_for_each_safe(cur, tmp, &xen_pcpus) { >> + pcpu = list_entry(cur, struct pcpu, list); >> + free_pcpu(pcpu); >> + } >> + } >> + >> + mutex_unlock(&xen_pcpu_lock); >> + >> + return err; >> +} >> + >> +static void xen_pcpu_work_fn(struct work_struct *work) +{ >> + xen_sync_pcpus(); >> +} >> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); + >> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) +{ >> + schedule_work(&xen_pcpu_work); >> + return IRQ_HANDLED; >> +} >> + >> +static int __init xen_pcpu_init(void) >> +{ >> + int irq, ret; >> + >> + if (!xen_initial_domain()) >> + return -ENODEV; >> + >> + irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, >> + xen_pcpu_interrupt, 0, >> + "xen-pcpu", NULL); >> + if (irq < 0) { >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); + return irq; >> + } >> + >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); + goto >> err1; + } >> + >> + ret = xen_sync_pcpus(); >> + if (ret) { >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + goto err2; >> + } >> + >> + return 0; >> + >> +err2: >> + bus_unregister(&xen_pcpu_subsys); >> +err1: >> + unbind_from_irqhandler(irq, NULL); >> + return ret; >> +} >> +arch_initcall(xen_pcpu_init); >> diff --git a/include/xen/interface/platform.h >> b/include/xen/interface/platform.h index 486653f..61fa661 100644 --- >> a/include/xen/interface/platform.h +++ >> b/include/xen/interface/platform.h @@ -314,6 +314,13 @@ struct >> xenpf_pcpuinfo { }; >> DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); >> >> +#define XENPF_cpu_online 56 >> +#define XENPF_cpu_offline 57 >> +struct xenpf_cpu_ol { >> + uint32_t cpuid; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); >> + >> struct xen_platform_op { >> uint32_t cmd; >> uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ >> @@ -330,6 +337,7 @@ struct xen_platform_op { >> struct xenpf_getidletime getidletime; >> struct xenpf_set_processor_pminfo set_pminfo; >> struct xenpf_pcpuinfo pcpu_info; >> + struct xenpf_cpu_ol cpu_ol; >> uint8_t pad[128]; >> } u; >> }; >> diff --git a/include/xen/interface/xen.h >> b/include/xen/interface/xen.h >> index a890804..0801468 100644 >> --- a/include/xen/interface/xen.h >> +++ b/include/xen/interface/xen.h >> @@ -80,6 +80,7 @@ >> #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency >> console. */ #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event >> for some domain. */ #define VIRQ_DEBUGGER 6 /* (DOM0) A domain >> has paused for debugging. */ +#define VIRQ_PCPU_STATE 9 /* (DOM0) >> PCPU state changed */ >> >> /* Architecture-specific VIRQ definitions. */ >> #define VIRQ_ARCH_0 16 >> -- >> 1.7.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:28:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSte1-0005yb-IQ; Fri, 11 May 2012 17:28:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSte0-0005yV-Jo for xen-devel@lists.xensource.com; Fri, 11 May 2012 17:28:44 +0000 Received: from [193.109.254.147:4371] by server-8.bemta-14.messagelabs.com id 88/C6-23244-B4C4DAF4; Fri, 11 May 2012 17:28:43 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336757322!6404978!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc4Nzcw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13373 invoked from network); 11 May 2012 17:28:43 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-5.tower-27.messagelabs.com with SMTP; 11 May 2012 17:28:43 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 May 2012 10:28:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141961125" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 10:28:41 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 10:28:41 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 01:28:39 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface (V2) Thread-Index: AQHNL4DoJV8RtIigTTax7Uicx2M6K5bEz5ng Date: Fri, 11 May 2012 17:28:38 +0000 Message-ID: References: <20120511141817.GB13735@phenom.dumpdata.com> In-Reply-To: <20120511141817.GB13735@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: >> +static void pcpu_sys_remove(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + >> + if (!pcpu) >> + return; >> + >> + dev = &pcpu->dev; >> + if (dev->id) >> + device_remove_file(dev, &dev_attr_online); >> + >> + device_unregister(dev); >> +} >> + >> +static void free_pcpu(struct pcpu *pcpu) > > 1) So this isn't just freeing the PCPU, it also unregisters > the SysFS. > > As such you should call this differently: > > unregister_and_free(struct pcpu *pcpu) Fine, rename 2 funcs: init_pcpu --> int_and_register_pcpu free_pcpu --> unregister_and_free_pcpu > > or do the unregistration part seperatly. > > 2) But there is also another issue - a possiblity of race. > > The user might be running: > while (true) > do > echo 1 > online > echo 0 > online > done > > and the the sync_pcpu will end up calling pcpu_sys_remove and > free the pcpu. The SysFS aren't deleted until all of the No race here. echo x > online would not change cpu present map. > object references (kref's) have been put. So when you get to > 'kfree(pcpu)' you might be still holding a reference (meaning > the user is doing 'echo 0 > online') and crash. > > I think you need to hold the mutex in the store_online() function > (not good), or better yet, make a device_release function > that will be called when the last kref has been put. > > > 3) Third the name. These functions all depend on the mutex lock being > held. As such add a postfix to the name of the function of > "_locked" or a prefix of "__' so it is known that the caller holds > the mutex. OK, add _locked postfix to these functions. Thanks, Jinsong > >> +{ >> + if (!pcpu) >> + return; >> + >> + pcpu_sys_remove(pcpu); >> + >> + list_del(&pcpu->list); >> + kfree(pcpu); >> +} >> + >> +static int pcpu_sys_create(struct pcpu *pcpu) >> +{ >> + struct device *dev; >> + int err = -EINVAL; >> + >> + if (!pcpu) >> + return err; >> + >> + dev = &pcpu->dev; >> + dev->bus = &xen_pcpu_subsys; >> + dev->id = pcpu->cpu_id; >> + >> + err = device_register(dev); >> + if (err) >> + return err; >> + >> + /* >> + * Xen never offline cpu0 due to several restrictions >> + * and assumptions. This basically doesn't add a sys control >> + * to user, one cannot attempt to offline BSP. >> + */ >> + if (dev->id) { >> + err = device_create_file(dev, &dev_attr_online); + if (err) { >> + device_unregister(dev); >> + return err; >> + } >> + } >> + >> + return 0; >> +} >> + >> +static struct pcpu *init_pcpu(struct xenpf_pcpuinfo *info) +{ >> + struct pcpu *pcpu; >> + int err; >> + >> + if (info->flags & XEN_PCPU_FLAGS_INVALID) >> + return ERR_PTR(-ENODEV); >> + >> + pcpu = kzalloc(sizeof(struct pcpu), GFP_KERNEL); >> + if (!pcpu) >> + return ERR_PTR(-ENOMEM); >> + >> + INIT_LIST_HEAD(&pcpu->list); >> + pcpu->cpu_id = info->xen_cpuid; >> + pcpu->flags = info->flags; >> + >> + err = pcpu_sys_create(pcpu); >> + if (err) { >> + pr_warning(XEN_PCPU "Failed to register pcpu%u\n", + >> info->xen_cpuid); + kfree(pcpu); >> + return ERR_PTR(-ENOENT); >> + } >> + >> + /* Need hold on xen_pcpu_lock before pcpu list manipulations */ >> + list_add_tail(&pcpu->list, &xen_pcpus); >> + return pcpu; >> +} >> + >> +/* >> + * Caller should hold the xen_pcpu_lock >> + */ >> +static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu) +{ >> + int ret; >> + struct pcpu *pcpu = NULL; >> + struct xenpf_pcpuinfo *info; >> + struct xen_platform_op op = { >> + .cmd = XENPF_get_cpuinfo, >> + .interface_version = XENPF_INTERFACE_VERSION, >> + .u.pcpu_info.xen_cpuid = cpu, >> + }; >> + >> + ret = HYPERVISOR_dom0_op(&op); >> + if (ret) >> + return ret; >> + >> + info = &op.u.pcpu_info; >> + if (max_cpu) >> + *max_cpu = info->max_present; >> + >> + pcpu = get_pcpu(cpu); >> + >> + if (info->flags & XEN_PCPU_FLAGS_INVALID) { >> + /* The pcpu has been removed */ >> + if (pcpu) >> + free_pcpu(pcpu); >> + return 0; >> + } >> + >> + if (!pcpu) { >> + pcpu = init_pcpu(info); >> + if (IS_ERR_OR_NULL(pcpu)) >> + return -ENODEV; >> + } else >> + pcpu_online_status(info, pcpu); >> + >> + return 0; >> +} >> + >> +/* >> + * Sync dom0's pcpu information with xen hypervisor's + */ >> +static int xen_sync_pcpus(void) >> +{ >> + /* >> + * Boot cpu always have cpu_id 0 in xen >> + */ >> + uint32_t cpu = 0, max_cpu = 0; >> + int err = 0; >> + struct list_head *cur, *tmp; >> + struct pcpu *pcpu; >> + >> + mutex_lock(&xen_pcpu_lock); >> + >> + while (!err && (cpu <= max_cpu)) { >> + err = sync_pcpu(cpu, &max_cpu); >> + cpu++; >> + } >> + >> + if (err) { >> + list_for_each_safe(cur, tmp, &xen_pcpus) { >> + pcpu = list_entry(cur, struct pcpu, list); >> + free_pcpu(pcpu); >> + } >> + } >> + >> + mutex_unlock(&xen_pcpu_lock); >> + >> + return err; >> +} >> + >> +static void xen_pcpu_work_fn(struct work_struct *work) +{ >> + xen_sync_pcpus(); >> +} >> +static DECLARE_WORK(xen_pcpu_work, xen_pcpu_work_fn); + >> +static irqreturn_t xen_pcpu_interrupt(int irq, void *dev_id) +{ >> + schedule_work(&xen_pcpu_work); >> + return IRQ_HANDLED; >> +} >> + >> +static int __init xen_pcpu_init(void) >> +{ >> + int irq, ret; >> + >> + if (!xen_initial_domain()) >> + return -ENODEV; >> + >> + irq = bind_virq_to_irqhandler(VIRQ_PCPU_STATE, 0, >> + xen_pcpu_interrupt, 0, >> + "xen-pcpu", NULL); >> + if (irq < 0) { >> + pr_warning(XEN_PCPU "Failed to bind pcpu virq\n"); + return irq; >> + } >> + >> + ret = subsys_system_register(&xen_pcpu_subsys, NULL); + if (ret) { >> + pr_warning(XEN_PCPU "Failed to register pcpu subsys\n"); + goto >> err1; + } >> + >> + ret = xen_sync_pcpus(); >> + if (ret) { >> + pr_warning(XEN_PCPU "Failed to sync pcpu info\n"); + goto err2; >> + } >> + >> + return 0; >> + >> +err2: >> + bus_unregister(&xen_pcpu_subsys); >> +err1: >> + unbind_from_irqhandler(irq, NULL); >> + return ret; >> +} >> +arch_initcall(xen_pcpu_init); >> diff --git a/include/xen/interface/platform.h >> b/include/xen/interface/platform.h index 486653f..61fa661 100644 --- >> a/include/xen/interface/platform.h +++ >> b/include/xen/interface/platform.h @@ -314,6 +314,13 @@ struct >> xenpf_pcpuinfo { }; >> DEFINE_GUEST_HANDLE_STRUCT(xenpf_pcpuinfo); >> >> +#define XENPF_cpu_online 56 >> +#define XENPF_cpu_offline 57 >> +struct xenpf_cpu_ol { >> + uint32_t cpuid; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol); >> + >> struct xen_platform_op { >> uint32_t cmd; >> uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ >> @@ -330,6 +337,7 @@ struct xen_platform_op { >> struct xenpf_getidletime getidletime; >> struct xenpf_set_processor_pminfo set_pminfo; >> struct xenpf_pcpuinfo pcpu_info; >> + struct xenpf_cpu_ol cpu_ol; >> uint8_t pad[128]; >> } u; >> }; >> diff --git a/include/xen/interface/xen.h >> b/include/xen/interface/xen.h >> index a890804..0801468 100644 >> --- a/include/xen/interface/xen.h >> +++ b/include/xen/interface/xen.h >> @@ -80,6 +80,7 @@ >> #define VIRQ_CONSOLE 2 /* (DOM0) Bytes received on emergency >> console. */ #define VIRQ_DOM_EXC 3 /* (DOM0) Exceptional event >> for some domain. */ #define VIRQ_DEBUGGER 6 /* (DOM0) A domain >> has paused for debugging. */ +#define VIRQ_PCPU_STATE 9 /* (DOM0) >> PCPU state changed */ >> >> /* Architecture-specific VIRQ definitions. */ >> #define VIRQ_ARCH_0 16 >> -- >> 1.7.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6h-0006Zr-As; Fri, 11 May 2012 17:58:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wq-Rh for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:57397] by server-3.bemta-4.messagelabs.com id 1C/F4-05853-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25727 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435469" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I5-9l; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fr-7Z; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:57 +0100 Message-ID: <1336759092-2432-13-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 12/27] libxl: make libxl_create_logfile const-correct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_utils.c | 2 +- tools/libxl/libxl_utils.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 19b4615..f0d94c6 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new) return 0; } -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name) +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name) { GC_INIT(ctx); struct stat stat_buf; diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h index ca53a8a..2b47622 100644 --- a/tools/libxl/libxl_utils.h +++ b/tools/libxl/libxl_utils.h @@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid); char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid); int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid); int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid); -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name); +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name); int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend); int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6k-0006da-U5; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wf-EI for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:16347] by server-3.bemta-5.messagelabs.com id 7D/4E-25237-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!12 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30232 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435480" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IW-Si; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gR-QB; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:06 +0100 Message-ID: <1336759092-2432-22-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 21/27] libxl: Fix an ao completion bug; document locking policy X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Document the concurrent access policies for libxl__ao and libxl__egc, and their corresponding gcs. Fix a violation of the policy: If an ao was submitted and a callback requested, and while the initiating function was still running on the original thread, the ao is completed on another thread, the completing thread would improperly concurrently access the ao with the initiating thread. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_event.c | 7 +++++++ tools/libxl/libxl_internal.h | 23 ++++++++++++++++++++++- 2 files changed, 29 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 3e784f0..b546471 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -901,6 +901,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval, static void egc_run_callbacks(libxl__egc *egc) { + /* + * The callbacks must happen with the ctx unlocked. + * See the comment near #define EGC_GC in libxl_internal.h and + * those in the definitions of libxl__egc and libxl__ao. + */ EGC_GC; libxl_event *ev, *ev_tmp; @@ -914,9 +919,11 @@ static void egc_run_callbacks(libxl__egc *egc) 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); + CTX_LOCK; ao->notified = 1; if (!ao->in_initiator) libxl__ao__destroy(CTX, ao); + CTX_UNLOCK; } } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9b4c273..f48cfdc 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -359,7 +359,8 @@ struct libxl__gc { }; struct libxl__egc { - /* for event-generating functions only */ + /* For event-generating functions only. + * The egc and its gc may be accessed only on the creating thread. */ struct libxl__gc gc; struct libxl__event_list occurred_for_callback; LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback; @@ -369,6 +370,20 @@ struct libxl__egc { #define LIBXL__AO_MAGIC_DESTROYED 0xA0DEAD00ul struct libxl__ao { + /* + * An ao and its gc may be accessed only with the ctx lock held. + * + * Special exception: If an ao has been added to + * egc->aos_for_callback, the thread owning the egc may remove the + * ao from that list and make the callback without holding the + * lock. + * + * Corresponding restriction: An ao may be added only to one + * egc->aos_for_callback, once; rc and how must already have been + * set and may not be subsequently modified. (This restriction is + * easily and obviously met since the ao is queued for callback + * only in libxl__ao_complete.) + */ uint32_t magic; unsigned constructing:1, in_initiator:1, complete:1, notified:1; int rc; @@ -1365,6 +1380,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); * should in any case not find it necessary to call egc-creators from * within libxl. * + * The callbacks must all take place with the ctx unlocked because + * the application is entitled to reenter libxl from them. This + * would be bad not because the lock is not recursive (it is) but + * because the application might make blocking libxl calls which + * would hold the lock unreasonably long. + * * 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. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6h-0006Zr-As; Fri, 11 May 2012 17:58:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wq-Rh for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:57397] by server-3.bemta-4.messagelabs.com id 1C/F4-05853-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25727 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435469" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I5-9l; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fr-7Z; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:57 +0100 Message-ID: <1336759092-2432-13-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 12/27] libxl: make libxl_create_logfile const-correct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_utils.c | 2 +- tools/libxl/libxl_utils.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 19b4615..f0d94c6 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -193,7 +193,7 @@ static int logrename(libxl__gc *gc, const char *old, const char *new) return 0; } -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name) +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name) { GC_INIT(ctx); struct stat stat_buf; diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h index ca53a8a..2b47622 100644 --- a/tools/libxl/libxl_utils.h +++ b/tools/libxl/libxl_utils.h @@ -26,7 +26,7 @@ int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid); char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid); int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid); int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid); -int libxl_create_logfile(libxl_ctx *ctx, char *name, char **full_name); +int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name); int libxl_string_to_backend(libxl_ctx *ctx, char *s, libxl_disk_backend *backend); int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6k-0006da-U5; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wf-EI for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:16347] by server-3.bemta-5.messagelabs.com id 7D/4E-25237-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!12 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30232 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435480" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IW-Si; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gR-QB; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:06 +0100 Message-ID: <1336759092-2432-22-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 21/27] libxl: Fix an ao completion bug; document locking policy X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Document the concurrent access policies for libxl__ao and libxl__egc, and their corresponding gcs. Fix a violation of the policy: If an ao was submitted and a callback requested, and while the initiating function was still running on the original thread, the ao is completed on another thread, the completing thread would improperly concurrently access the ao with the initiating thread. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_event.c | 7 +++++++ tools/libxl/libxl_internal.h | 23 ++++++++++++++++++++++- 2 files changed, 29 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 3e784f0..b546471 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -901,6 +901,11 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval, static void egc_run_callbacks(libxl__egc *egc) { + /* + * The callbacks must happen with the ctx unlocked. + * See the comment near #define EGC_GC in libxl_internal.h and + * those in the definitions of libxl__egc and libxl__ao. + */ EGC_GC; libxl_event *ev, *ev_tmp; @@ -914,9 +919,11 @@ static void egc_run_callbacks(libxl__egc *egc) 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); + CTX_LOCK; ao->notified = 1; if (!ao->in_initiator) libxl__ao__destroy(CTX, ao); + CTX_UNLOCK; } } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9b4c273..f48cfdc 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -359,7 +359,8 @@ struct libxl__gc { }; struct libxl__egc { - /* for event-generating functions only */ + /* For event-generating functions only. + * The egc and its gc may be accessed only on the creating thread. */ struct libxl__gc gc; struct libxl__event_list occurred_for_callback; LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback; @@ -369,6 +370,20 @@ struct libxl__egc { #define LIBXL__AO_MAGIC_DESTROYED 0xA0DEAD00ul struct libxl__ao { + /* + * An ao and its gc may be accessed only with the ctx lock held. + * + * Special exception: If an ao has been added to + * egc->aos_for_callback, the thread owning the egc may remove the + * ao from that list and make the callback without holding the + * lock. + * + * Corresponding restriction: An ao may be added only to one + * egc->aos_for_callback, once; rc and how must already have been + * set and may not be subsequently modified. (This restriction is + * easily and obviously met since the ao is queued for callback + * only in libxl__ao_complete.) + */ uint32_t magic; unsigned constructing:1, in_initiator:1, complete:1, notified:1; int rc; @@ -1365,6 +1380,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); * should in any case not find it necessary to call egc-creators from * within libxl. * + * The callbacks must all take place with the ctx unlocked because + * the application is entitled to reenter libxl from them. This + * would be bad not because the lock is not recursive (it is) but + * because the application might make blocking libxl calls which + * would hold the lock unreasonably long. + * * 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. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6e-0006Wt-KG; Fri, 11 May 2012 17:58:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W5-Is for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:16192] by server-11.bemta-5.messagelabs.com id 60/8C-12959-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30116 invoked from network); 11 May 2012 17:58:17 -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 May 2012 17:58:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435460" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HX-IE; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eA-Fx; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:47 +0100 Message-ID: <1336759092-2432-3-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 02/27] libxl: support multiple libxl__ev_fds for the same fd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We need a slightly more sophisticated data structure to allow this, where we record the slot not just for each fd but also for each (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT. Document the new relaxed restriction. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v6: * Fix typo --- tools/libxl/libxl_event.c | 62 +++++++++++++++++++++++------------------ tools/libxl/libxl_internal.h | 10 +++++-- 2 files changed, 42 insertions(+), 30 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 5046938..93c1d1f 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -639,10 +639,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, /* - * 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. + * 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_rindices: each fd corresponds to a slot in + * fd_rindices, and each element in the rindices is three indices + * into the fd array (for POLLIN, POLLPRI and POLLOUT). */ if (*nfds_io) { @@ -663,14 +664,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, }); /* make sure our array is as big as *nfds_io */ - if (poller->fd_rindex_allocd < maxfd) { - assert(maxfd < INT_MAX / sizeof(int) / 2); - int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd); - if (!newarray) { rc = ERROR_NOMEM; goto out; } - memset(newarray + poller->fd_rindex_allocd, 0, - sizeof(int) * (maxfd - poller->fd_rindex_allocd)); - poller->fd_rindex = newarray; - poller->fd_rindex_allocd = maxfd; + if (poller->fd_rindices_allocd < maxfd) { + assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd)); + poller->fd_rindices = + libxl__realloc(0, poller->fd_rindices, + maxfd * sizeof(*poller->fd_rindices)); + memset(poller->fd_rindices + poller->fd_rindices_allocd, + 0, + (maxfd - poller->fd_rindices_allocd) + * sizeof(*poller->fd_rindices)); + poller->fd_rindices_allocd = maxfd; } } @@ -681,8 +684,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, 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; + assert(req_fd < poller->fd_rindices_allocd); + if (req_events & POLLIN) poller->fd_rindices[req_fd][0] = used; + if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used; + if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used; } used++; }); @@ -710,7 +715,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, *timeout_upd = our_timeout; } - out: return rc; } @@ -732,24 +736,28 @@ static int afterpoll_check_fd(libxl__poller *poller, int fd, int events) /* returns mask of events which were requested and occurred */ { - if (fd >= poller->fd_rindex_allocd) + if (fd >= poller->fd_rindices_allocd) /* added after we went into poll, have to try again */ return 0; - int slot = poller->fd_rindex[fd]; + int i, revents = 0; + for (i=0; i<3; i++) { + int slot = poller->fd_rindices[fd][i]; - if (slot >= nfds) - /* stale slot entry; again, added afterwards */ - return 0; + if (slot >= nfds) + /* stale slot entry; again, added afterwards */ + continue; - if (fds[slot].fd != fd) - /* again, stale slot entry */ - return 0; + if (fds[slot].fd != fd) + /* again, stale slot entry */ + continue; - assert(!(fds[slot].revents & POLLNVAL)); + assert(!(fds[slot].revents & POLLNVAL)); + revents |= fds[slot].revents; + } - int revents = fds[slot].revents & (events | POLLERR | POLLHUP); /* we mask in case requested events have changed */ + revents &= (events | POLLERR | POLLHUP); return revents; } @@ -1013,7 +1021,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p) { int r, rc; p->fd_polls = 0; - p->fd_rindex = 0; + p->fd_rindices = 0; r = pipe(p->wakeup_pipe); if (r) { @@ -1040,7 +1048,7 @@ 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); + free(p->fd_rindices); } libxl__poller *libxl__poller_get(libxl_ctx *ctx) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 74e640f..01c9ba9 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -132,7 +132,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev, * events; otherwise revents contains only bits in events. Contrary * to the documentation for poll(2), POLLERR and POLLHUP can occur * even if only POLLIN was set in events. (POLLNVAL is a fatal - * error and will cause libxl event machinery to fail an assertion.) */ + * error and will cause libxl event machinery to fail an assertion.) + * + * It is not permitted to listen for the same or overlapping events + * on the same fd using multiple different libxl__ev_fd's. + */ struct libxl__ev_fd { /* caller should include this in their own struct */ /* read-only for caller, who may read only when registered: */ @@ -248,8 +252,8 @@ struct libxl__poller { struct pollfd *fd_polls; int fd_polls_allocd; - int fd_rindex_allocd; - int *fd_rindex; /* see libxl_osevent_beforepoll */ + int fd_rindices_allocd; + int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */ int wakeup_pipe[2]; /* 0 means no fd allocated */ }; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6e-0006Wt-KG; Fri, 11 May 2012 17:58:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W5-Is for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:16192] by server-11.bemta-5.messagelabs.com id 60/8C-12959-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30116 invoked from network); 11 May 2012 17:58:17 -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 May 2012 17:58:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435460" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HX-IE; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eA-Fx; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:47 +0100 Message-ID: <1336759092-2432-3-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 02/27] libxl: support multiple libxl__ev_fds for the same fd X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We need a slightly more sophisticated data structure to allow this, where we record the slot not just for each fd but also for each (fd,eventbit) where eventbit is POLLIN, POLLPRI, POLLOUT. Document the new relaxed restriction. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v6: * Fix typo --- tools/libxl/libxl_event.c | 62 +++++++++++++++++++++++------------------ tools/libxl/libxl_internal.h | 10 +++++-- 2 files changed, 42 insertions(+), 30 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 5046938..93c1d1f 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -639,10 +639,11 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, /* - * 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. + * 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_rindices: each fd corresponds to a slot in + * fd_rindices, and each element in the rindices is three indices + * into the fd array (for POLLIN, POLLPRI and POLLOUT). */ if (*nfds_io) { @@ -663,14 +664,16 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, }); /* make sure our array is as big as *nfds_io */ - if (poller->fd_rindex_allocd < maxfd) { - assert(maxfd < INT_MAX / sizeof(int) / 2); - int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd); - if (!newarray) { rc = ERROR_NOMEM; goto out; } - memset(newarray + poller->fd_rindex_allocd, 0, - sizeof(int) * (maxfd - poller->fd_rindex_allocd)); - poller->fd_rindex = newarray; - poller->fd_rindex_allocd = maxfd; + if (poller->fd_rindices_allocd < maxfd) { + assert(ARRAY_SIZE_OK(poller->fd_rindices, maxfd)); + poller->fd_rindices = + libxl__realloc(0, poller->fd_rindices, + maxfd * sizeof(*poller->fd_rindices)); + memset(poller->fd_rindices + poller->fd_rindices_allocd, + 0, + (maxfd - poller->fd_rindices_allocd) + * sizeof(*poller->fd_rindices)); + poller->fd_rindices_allocd = maxfd; } } @@ -681,8 +684,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, 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; + assert(req_fd < poller->fd_rindices_allocd); + if (req_events & POLLIN) poller->fd_rindices[req_fd][0] = used; + if (req_events & POLLPRI) poller->fd_rindices[req_fd][1] = used; + if (req_events & POLLOUT) poller->fd_rindices[req_fd][2] = used; } used++; }); @@ -710,7 +715,6 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, *timeout_upd = our_timeout; } - out: return rc; } @@ -732,24 +736,28 @@ static int afterpoll_check_fd(libxl__poller *poller, int fd, int events) /* returns mask of events which were requested and occurred */ { - if (fd >= poller->fd_rindex_allocd) + if (fd >= poller->fd_rindices_allocd) /* added after we went into poll, have to try again */ return 0; - int slot = poller->fd_rindex[fd]; + int i, revents = 0; + for (i=0; i<3; i++) { + int slot = poller->fd_rindices[fd][i]; - if (slot >= nfds) - /* stale slot entry; again, added afterwards */ - return 0; + if (slot >= nfds) + /* stale slot entry; again, added afterwards */ + continue; - if (fds[slot].fd != fd) - /* again, stale slot entry */ - return 0; + if (fds[slot].fd != fd) + /* again, stale slot entry */ + continue; - assert(!(fds[slot].revents & POLLNVAL)); + assert(!(fds[slot].revents & POLLNVAL)); + revents |= fds[slot].revents; + } - int revents = fds[slot].revents & (events | POLLERR | POLLHUP); /* we mask in case requested events have changed */ + revents &= (events | POLLERR | POLLHUP); return revents; } @@ -1013,7 +1021,7 @@ int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p) { int r, rc; p->fd_polls = 0; - p->fd_rindex = 0; + p->fd_rindices = 0; r = pipe(p->wakeup_pipe); if (r) { @@ -1040,7 +1048,7 @@ 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); + free(p->fd_rindices); } libxl__poller *libxl__poller_get(libxl_ctx *ctx) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 74e640f..01c9ba9 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -132,7 +132,11 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev, * events; otherwise revents contains only bits in events. Contrary * to the documentation for poll(2), POLLERR and POLLHUP can occur * even if only POLLIN was set in events. (POLLNVAL is a fatal - * error and will cause libxl event machinery to fail an assertion.) */ + * error and will cause libxl event machinery to fail an assertion.) + * + * It is not permitted to listen for the same or overlapping events + * on the same fd using multiple different libxl__ev_fd's. + */ struct libxl__ev_fd { /* caller should include this in their own struct */ /* read-only for caller, who may read only when registered: */ @@ -248,8 +252,8 @@ struct libxl__poller { struct pollfd *fd_polls; int fd_polls_allocd; - int fd_rindex_allocd; - int *fd_rindex; /* see libxl_osevent_beforepoll */ + int fd_rindices_allocd; + int (*fd_rindices)[3]; /* see libxl_osevent_beforepoll */ int wakeup_pipe[2]; /* 0 means no fd allocated */ }; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006aI-37; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wl-Sd for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:16291] by server-10.bemta-5.messagelabs.com id 18/AF-08260-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!8 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30188 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IB-Dj; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fz-BW; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:59 +0100 Message-ID: <1336759092-2432-15-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 14/27] libxl: Allow AO_GC and EGC_GC even if not used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Mark the gc produced by AO_GC and EGC_GC with the gcc feature __attribute__((unused)). This allows the use of EGC_INIT and STATE_AO_GC by functions which do actually use the gc. This is convenient because those functions might want to use the ao or egc, rather than the gc; and also because it means that functions which morally ought to be fishing any gc they use out of an egc or state structure can be written do so regardless of whether the gc is actually used right then. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c5ec586..21fe99c 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1287,7 +1287,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); /* useful for all functions which take an egc: */ #define EGC_GC \ - libxl__gc *const gc = &egc->gc + libxl__gc *const gc __attribute__((unused)) = &egc->gc /* egc initialisation and destruction: */ @@ -1390,7 +1390,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); }) #define AO_GC \ - libxl__gc *const gc = &ao->gc + libxl__gc *const gc __attribute__((unused)) = &ao->gc #define STATE_AO_GC(op_ao) \ libxl__ao *const ao = (op_ao); \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6o-0006iB-0Q; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-EV for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57430] by server-1.bemta-4.messagelabs.com id A5/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32056 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435479" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IQ-OL; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gJ-LR; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:04 +0100 Message-ID: <1336759092-2432-20-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH 19/27] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Roger Pau Monne This is needed in order to perform the domain destruction if libxl__domain_make fails. Also move doc comment about error behaviour of libxl__domain_make from implementation to declaration. Signed-off-by: Roger Pau Monne Signed-off-by: Ian Jackson --- tools/libxl/libxl_create.c | 3 +-- tools/libxl/libxl_internal.h | 4 ++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 9ce107a..5075537 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -396,8 +396,6 @@ out: int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid) - /* on entry, libxl_domid_valid_guest(domid) must be false; - * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); int flags, ret, rc; @@ -600,6 +598,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index dc84881..b1ce4d6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1078,9 +1078,13 @@ _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, char **args); // logs errors, never returns /* from xl_create */ + + /* on entry, libxl_domid_valid_guest(domid) must be false; + * on exit (even error exit), domid may be valid and refer to a domain */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); + _hidden int libxl__domain_build(libxl__gc *gc, libxl_domain_build_info *info, uint32_t domid, -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6m-0006fc-Hz; Fri, 11 May 2012 17:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006X7-T9 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42723] by server-2.bemta-4.messagelabs.com id A9/02-17550-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25794 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435481" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IY-Uo; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gV-SQ; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:07 +0100 Message-ID: <1336759092-2432-23-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 22/27] libxl: provide progress reporting for long-running operations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This will be used for reporting, during domain creation, that the console is ready. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * If aop->how.callback, actually add the aop to the for_callback list (!) * Document the threadsafety of aop's, and make appropriate cross-references. * Allocate the actual aop from its thread's egc; do not free it. * Remove pointless code motion of libxl__ao_create. * Minor formatting fixes. --- tools/libxl/libxl.h | 45 ++++++++++++++++++++++++++ tools/libxl/libxl_event.c | 72 ++++++++++++++++++++++++++++++++++++++++-- tools/libxl/libxl_internal.h | 35 ++++++++++++++++++++ 3 files changed, 149 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index e19d947..ba0f4de 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -435,6 +435,51 @@ typedef struct { } u; } libxl_asyncop_how; +/* + * Some more complex asynchronous operations can report intermediate + * progress. How this is to be reported is controlled, for each + * function, by a parameter + * libxl_asyncprogress_how *aop_FOO_how; + * for each kind of progress FOO supported by that function. Each + * such kind of progress is associated with an event type. + * + * The function description will document whether, when, and how + * many times, the intermediate progress will be reported, and + * what the corresponding event type(s) are. + * + * If aop_FOO_how==NULL, intermediate progress reports are discarded. + * + * If aop_FOO_how->callback==NULL, intermediate progress reports + * generate libxl events which can be obtained from libxl_event_wait + * or libxl_event_check. + * + * If aop_FOO_how->callback!=NULL, libxl will report intermediate + * progress by calling callback(ctx, &event, for_callback). + * + * The rules for these events are otherwise the same as those for + * ordinary events. The reentrancy and threading rules for the + * callback are the same as those for ao completion callbacks. + * + * Note that the callback, if provided, is responsible for freeing + * the event. + * + * If callbacks are requested, they will be made, and returned, before + * the long-running libxl operation is considered finished (so if the + * long-running libxl operation was invoked with ao_how==NULL then any + * callbacks will occur strictly before the long-running operation + * returns). However, the callbacks may occur on any thread. + * + * In general, otherwise, no promises are made about the relative + * order of callbacks in a multithreaded program. In particular + * different callbacks relating to the same long-running operation may + * be delivered out of order. + */ + +typedef struct { + void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback); + libxl_ev_user for_event; /* always used */ + void *for_callback; /* passed to callback */ +} libxl_asyncprogress_how; #define LIBXL_VERSION 0 diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index b546471..460ef66 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -902,18 +902,29 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval, static void egc_run_callbacks(libxl__egc *egc) { /* - * The callbacks must happen with the ctx unlocked. - * See the comment near #define EGC_GC in libxl_internal.h and - * those in the definitions of libxl__egc and libxl__ao. + * The callbacks must happen with the ctx unlocked. See the + * comment near #define EGC_GC in libxl_internal.h and those in + * the definitions of libxl__egc, libxl__ao and libxl__aop. */ EGC_GC; libxl_event *ev, *ev_tmp; + libxl__aop_occurred *aop, *aop_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_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) { + LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry); + aop->how->callback(CTX, aop->ev, aop->how->for_callback); + + CTX_LOCK; + aop->ao->progress_reports_outstanding--; + libxl__ao_complete_check_progress_reports(egc, aop->ao); + CTX_UNLOCK; + } + libxl__ao *ao, *ao_tmp; LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback, entry_for_callback, ao_tmp) { @@ -1296,6 +1307,7 @@ void libxl__ao_abort(libxl__ao *ao) assert(ao->magic == LIBXL__AO_MAGIC); assert(ao->in_initiator); assert(!ao->complete); + assert(!ao->progress_reports_outstanding); libxl__ao__destroy(CTX, ao); } @@ -1306,6 +1318,24 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) ao->complete = 1; ao->rc = rc; + libxl__ao_complete_check_progress_reports(egc, ao); +} + +void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao) +{ + /* + * We don't consider an ao complete if it has any outstanding + * callbacks. These callbacks might be outstanding on other + * threads, queued up in the other threads' egc's. Those threads + * will, after making the callback, take out the lock again, + * decrement progress_reports_outstanding, and call us again. + */ + + assert(ao->progress_reports_outstanding >= 0); + + if (!ao->complete || ao->progress_reports_outstanding) + return; + if (ao->poller) { assert(ao->in_initiator); if (!ao->constructing) @@ -1355,6 +1385,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid, return NULL; } + int libxl__ao_inprogress(libxl__ao *ao) { AO_GC; @@ -1412,6 +1443,41 @@ int libxl__ao_inprogress(libxl__ao *ao) } +/* progress reporting */ + +/* The application indicates a desire to ignore events by passing NULL + * for how. But we want to copy *how. So we have this dummy function + * whose address is stored in callback if the app passed how==NULL. */ +static void dummy_asyncprogress_callback_ignore + (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { } + +void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state, + const libxl_asyncprogress_how *from_app) { + if (from_app) + *in_state = *from_app; + else + in_state->callback = dummy_asyncprogress_callback_ignore; +} + +void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao, + const libxl_asyncprogress_how *how, libxl_event *ev) +{ + ev->for_user = how->for_event; + if (how->callback == dummy_asyncprogress_callback_ignore) { + /* ignore */ + } else if (how->callback) { + libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop)); + ao->progress_reports_outstanding++; + aop->ao = ao; + aop->ev = ev; + aop->how = how; + LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry); + } else { + libxl__event_occurred(egc, ev); + } +} + + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index f48cfdc..d5cf69a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -119,6 +119,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__aop_occurred libxl__aop_occurred; _hidden void libxl__alloc_failed(libxl_ctx *, const char *func, size_t nmemb, size_t size) __attribute__((noreturn)); @@ -364,6 +365,21 @@ struct libxl__egc { struct libxl__gc gc; struct libxl__event_list occurred_for_callback; LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback; + LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback; +}; + +struct libxl__aop_occurred { + /* + * An aop belongs to, and may be accessed only on, the thread + * which created it. It normally lives in that thread's egc. + * + * While an aop exists, it corresponds to one refcount in + * ao->progress_reports_outstanding, preventing ao destruction. + */ + LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry; + libxl__ao *ao; + libxl_event *ev; + const libxl_asyncprogress_how *how; }; #define LIBXL__AO_MAGIC 0xA0FACE00ul @@ -386,6 +402,7 @@ struct libxl__ao { */ uint32_t magic; unsigned constructing:1, in_initiator:1, complete:1, notified:1; + int progress_reports_outstanding; int rc; libxl__gc gc; libxl_asyncop_how how; @@ -1402,6 +1419,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); LIBXL_INIT_GC((egc).gc,ctx); \ LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \ LIBXL_TAILQ_INIT(&(egc).aos_for_callback); \ + LIBXL_TAILQ_INIT(&(egc).aops_for_callback); \ } while(0) _hidden void libxl__egc_cleanup(libxl__egc *egc); @@ -1448,6 +1466,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); * 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 the operation provides progress reports, the aop_how(s) + * must be copied into the per-operation structure using + * libxl__ao_progress_gethow. * * - If initiation is successful, the initiating function needs * to run libxl__ao_inprogress right before unlocking and @@ -1457,6 +1478,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); * call libxl__ao_abort before unlocking and returning whatever * error code is appropriate (AO_ABORT macro). * + * - If the operation supports progress reports, it may generate + * suitable events with NEW_EVENT and report them with + * libxl__ao_progress_report (with the ctx locked). + * * - 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 @@ -1512,8 +1537,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */ _hidden void libxl__ao_abort(libxl__ao *ao); _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc); +/* Can be called at any time. Use is essential for any aop user. */ +_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state, + const libxl_asyncprogress_how *from_app); + +/* Must be called with the ctx locked. Will fill in ev->for_user, + * so caller need not do that. */ +_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao, + const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */); + /* For use by ao machinery ONLY */ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao); +_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*); /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6q-0006mI-2d; Fri, 11 May 2012 17:58:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-RD for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:23 +0000 Received: from [85.158.143.35:42729] by server-1.bemta-4.messagelabs.com id 26/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!8 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25806 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435485" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Im-7X; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gs-6p; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:12 +0100 Message-ID: <1336759092-2432-28-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 27/27] libxl: abort bootloader invocation when domain dies X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Cancel the bootloader (specifically, by sending it a signal) if the domain is seen to disappear from xenstore. We use a new utility event source libxl__domaindeathcheck which provides a convenient wrapper for the xenstore watch. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v8: * Fixed the commit message summary line. Changes since v7: * Add a comment explaining why we use a watch on the domain's xenstore path rather than @releaseDomain. * Fix typo in error message. --- tools/libxl/libxl_bootloader.c | 43 ++++++++++++++++++++++++++++-------- tools/libxl/libxl_event.c | 47 ++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 29 +++++++++++++++++++++++- 3 files changed, 108 insertions(+), 11 deletions(-) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 8436c07..fb1302b 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval); static void bootloader_display_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc); static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, pid_t pid, int status); @@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl) bl->ptys[0].master = bl->ptys[0].slave = 0; bl->ptys[1].master = bl->ptys[1].slave = 0; libxl__ev_child_init(&bl->child); + libxl__domaindeathcheck_init(&bl->deathcheck); bl->keystrokes.ao = bl->ao; libxl__datacopier_init(&bl->keystrokes); bl->display.ao = bl->ao; libxl__datacopier_init(&bl->display); } @@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) free(bl->diskpath); bl->diskpath = 0; } + libxl__domaindeathcheck_stop(gc,&bl->deathcheck); libxl__datacopier_kill(&bl->keystrokes); libxl__datacopier_kill(&bl->display); for (i=0; i<2; i++) { @@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl, bl->callback(egc, bl, rc); } +/* might be called at any time, provided it's init'd */ +static void bootloader_abort(libxl__egc *egc, + libxl__bootloader_state *bl, int rc) +{ + STATE_AO_GC(bl->ao); + int r; + + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + if (libxl__ev_child_inuse(&bl->child)) { + r = kill(bl->child.pid, SIGTERM); + if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", + (unsigned long)bl->child.pid); + } + bl->rc = rc; +} + /*----- main flow of control -----*/ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) @@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) goto out; } + bl->deathcheck.what = "stopping bootloader"; + bl->deathcheck.domid = bl->domid; + bl->deathcheck.callback = bootloader_domaindeath; + rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck); + if (rc) goto out; + if (bl->console_available) bl->console_available(egc, bl); @@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which, libxl__bootloader_state *bl, int onwrite, int errnoval) { STATE_AO_GC(bl->ao); - int r; - if (!onwrite && !errnoval) LOG(ERROR, "unexpected eof copying %s", which); - libxl__datacopier_kill(&bl->keystrokes); - libxl__datacopier_kill(&bl->display); - if (libxl__ev_child_inuse(&bl->child)) { - r = kill(bl->child.pid, SIGTERM); - if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", - (unsigned long)bl->child.pid); - } - bl->rc = ERROR_FAIL; + bootloader_abort(egc, bl, ERROR_FAIL); } static void bootloader_keystrokes_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval) @@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc, bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval); } +static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck); + bootloader_abort(egc, bl, ERROR_FAIL); +} + static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, pid_t pid, int status) { diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 63719b2..03d0498 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -589,6 +589,53 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, } /* + * domain death/destruction + */ + +/* + * We use a xenstore watch on the domain's path, rather than using an + * @releaseDomain watch and asking the hypervisor. This is simpler + * because turning @releaseDomain into domain-specific information is + * complicated. + * + * It is also sufficient for our callers, which are generally trying + * to do cleanup of their own execution state on domain death, for the + * following reason: if the domain is destroyed then either (a) the + * entries in xenstore have already been deleted, in which case the + * test here works or (b) they have not in which case something has + * gone very badly wrong and we are going to leak those xenstore + * entries, in which case trying to avoid leaking other stuff is + * futile. + */ + +static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w, + const char *watch_path, const char *event_path) +{ + libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch); + EGC_GC; + const char *p = libxl__xs_read(gc, XBT_NULL, watch_path); + if (p) return; + + if (errno!=ENOENT) { + LIBXL__EVENT_DISASTER(egc,"failed to read xenstore" + " for domain detach check", errno, 0); + return; + } + + LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)", + dc->what, dc->domid, watch_path); + dc->callback(egc, dc); +} + +int libxl__domaindeathcheck_start(libxl__gc *gc, + libxl__domaindeathcheck *dc) +{ + const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid); + return libxl__ev_xswatch_register(gc, &dc->watch, + domaindeathcheck_callback, path); +} + +/* * osevent poll */ diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 83fabea..f71e76a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -866,6 +866,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, const char *state_path, int state, int milliseconds); +/* + * libxl__ev_domaindeathcheck_register - arranges to call back (once) + * if the domain is destroyed. If the domain dies, we log a message + * of the form ": ". + */ + +typedef struct libxl__domaindeathcheck libxl__domaindeathcheck; +typedef void libxl___domaindeathcheck_callback(libxl__egc *egc, + libxl__domaindeathcheck*); + +struct libxl__domaindeathcheck { + /* must be filled in by caller, and remain valid: */ + const char *what; + uint32_t domid; + libxl___domaindeathcheck_callback *callback; + /* private */ + libxl__ev_xswatch watch; +}; + +_hidden int libxl__domaindeathcheck_start(libxl__gc *gc, + libxl__domaindeathcheck *dc); + +static inline void libxl__domaindeathcheck_init + (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); } +static inline void libxl__domaindeathcheck_stop(libxl__gc *gc, + libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); } + /* * libxl__try_phy_backend - Check if there's support for the passed @@ -1738,6 +1765,7 @@ struct libxl__bootloader_state { libxl__openpty_state openpty; libxl__openpty_result ptys[2]; /* [0] is for bootloader */ libxl__ev_child child; + libxl__domaindeathcheck deathcheck; int nargs, argsspace; const char **args; libxl__datacopier_state keystrokes, display; @@ -1750,7 +1778,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); * If callback is passed rc==0, will have updated st->info appropriately */ _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); - /*----- Domain creation -----*/ typedef struct libxl__domain_create_state libxl__domain_create_state; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006aI-37; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wl-Sd for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:16291] by server-10.bemta-5.messagelabs.com id 18/AF-08260-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!8 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30188 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435470" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IB-Dj; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fz-BW; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:59 +0100 Message-ID: <1336759092-2432-15-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 14/27] libxl: Allow AO_GC and EGC_GC even if not used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Mark the gc produced by AO_GC and EGC_GC with the gcc feature __attribute__((unused)). This allows the use of EGC_INIT and STATE_AO_GC by functions which do actually use the gc. This is convenient because those functions might want to use the ao or egc, rather than the gc; and also because it means that functions which morally ought to be fishing any gc they use out of an egc or state structure can be written do so regardless of whether the gc is actually used right then. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c5ec586..21fe99c 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1287,7 +1287,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); /* useful for all functions which take an egc: */ #define EGC_GC \ - libxl__gc *const gc = &egc->gc + libxl__gc *const gc __attribute__((unused)) = &egc->gc /* egc initialisation and destruction: */ @@ -1390,7 +1390,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); }) #define AO_GC \ - libxl__gc *const gc = &ao->gc + libxl__gc *const gc __attribute__((unused)) = &ao->gc #define STATE_AO_GC(op_ao) \ libxl__ao *const ao = (op_ao); \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6o-0006iB-0Q; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-EV for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57430] by server-1.bemta-4.messagelabs.com id A5/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32056 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435479" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IQ-OL; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gJ-LR; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:04 +0100 Message-ID: <1336759092-2432-20-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Roger Pau Monne Subject: [Xen-devel] [PATCH 19/27] libxl: set guest_domid even if libxl__domain_make fails X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Roger Pau Monne This is needed in order to perform the domain destruction if libxl__domain_make fails. Also move doc comment about error behaviour of libxl__domain_make from implementation to declaration. Signed-off-by: Roger Pau Monne Signed-off-by: Ian Jackson --- tools/libxl/libxl_create.c | 3 +-- tools/libxl/libxl_internal.h | 4 ++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 9ce107a..5075537 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -396,8 +396,6 @@ out: int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid) - /* on entry, libxl_domid_valid_guest(domid) must be false; - * on exit (even error exit), domid may be valid and refer to a domain */ { libxl_ctx *ctx = libxl__gc_owner(gc); int flags, ret, rc; @@ -600,6 +598,7 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); + dcs->guest_domid = domid; ret = ERROR_FAIL; goto error_out; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index dc84881..b1ce4d6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1078,9 +1078,13 @@ _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0, char **args); // logs errors, never returns /* from xl_create */ + + /* on entry, libxl_domid_valid_guest(domid) must be false; + * on exit (even error exit), domid may be valid and refer to a domain */ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid); + _hidden int libxl__domain_build(libxl__gc *gc, libxl_domain_build_info *info, uint32_t domid, -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6l-0006eM-LC; Fri, 11 May 2012 17:58:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006XP-Jx for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4152] by server-6.bemta-5.messagelabs.com id E7/1C-13222-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!11 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30221 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435477" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IV-R7; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gN-O8; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:05 +0100 Message-ID: <1336759092-2432-21-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 20/27] libxl: make libxl_create run bootloader via callback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Change initiate_domain_create to properly use libxl__bootloader_run rather than improperly calling libxl_run_bootloader with NULL ao_how. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * constify convenience aliases. Changes since v6: * Bugfixes from testing. --- tools/libxl/libxl_create.c | 53 +++++++++++++++++++++++++++++++---------- tools/libxl/libxl_internal.h | 1 + 2 files changed, 41 insertions(+), 13 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 5075537..63cb430 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -569,6 +569,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int rc); +static void domcreate_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *bl, + int rc); /* Our own function to clean up and call the user's callback. * The final call in the sequence. */ @@ -589,6 +592,7 @@ static void initiate_domain_create(libxl__egc *egc, const int restore_fd = dcs->restore_fd; const libxl_console_ready cb = dcs->console_cb; void *const priv = dcs->console_cb_priv; + memset(&dcs->build_state, 0, sizeof(dcs->build_state)); domid = 0; @@ -619,21 +623,43 @@ static void initiate_domain_create(libxl__egc *egc, if (ret) goto error_out; } + dcs->bl.ao = ao; libxl_device_disk *bootdisk = d_config->num_disks > 0 ? &d_config->disks[0] : NULL; if (restore_fd < 0 && bootdisk) { - ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid, - 0 /* fixme-ao */); - if (ret) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "failed to run bootloader: %d", ret); - goto error_out; - } + dcs->bl.callback = domcreate_bootloader_done; + dcs->bl.info = &d_config->b_info, + dcs->bl.disk = bootdisk; + dcs->bl.domid = dcs->guest_domid; + + libxl__bootloader_run(egc, &dcs->bl); + } else { + domcreate_bootloader_done(egc, &dcs->bl, 0); } + return; - memset(&dcs->build_state, 0, sizeof(dcs->build_state)); - libxl__domain_build_state *state = &dcs->build_state; +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *bl, + int ret) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl); + STATE_AO_GC(bl->ao); + int i; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + const int restore_fd = dcs->restore_fd; + libxl__domain_build_state *const state = &dcs->build_state; + libxl_ctx *const ctx = CTX; + + if (ret) goto error_out; /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. * Fill in any field required by either, including both relevant @@ -784,12 +810,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && libxl_defbool_val(d_config->b_info.u.pv.e820_host)) { - int rc; - rc = libxl__e820_alloc(gc, domid, d_config); - if (rc) + ret = libxl__e820_alloc(gc, domid, d_config); + if (ret) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed while collecting E820 with: %d (errno:%d)\n", - rc, errno); + ret, errno); + goto error_out; + } } if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM || (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b1ce4d6..9b4c273 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1689,6 +1689,7 @@ struct libxl__domain_create_state { /* private to domain_create */ int guest_domid; libxl__domain_build_state build_state; + libxl__bootloader_state bl; libxl__stub_dm_spawn_state dmss; /* If we're not doing stubdom, we use only dmss.dm, * for the non-stubdom device model. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006ac-HL; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wf-Pk for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4095] by server-3.bemta-5.messagelabs.com id AA/4E-25237-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30172 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435468" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Hz-6Y; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fj-3f; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:55 +0100 Message-ID: <1336759092-2432-11-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 10/27] libxl: provide libxl__openpty_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org General facility for ao operations to open ptys. This will be used by the bootloader machinery. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_aoutils.c | 127 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 36 ++++++++++++ 2 files changed, 163 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 4c60ad9..734a5dc 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc) return rc; } +/*----- openpty -----*/ + +/* implementation */ + +static void openpty_cleanup(libxl__openpty_state *op) +{ + int i; + + for (i=0; icount; i++) { + libxl__openpty_result *res = &op->results[i]; + libxl__carefd_close(res->master); res->master = 0; + libxl__carefd_close(res->slave); res->slave = 0; + } +} + +static void openpty_exited(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) { + libxl__openpty_state *op = CONTAINER_OF(child, *op, child); + STATE_AO_GC(op->ao); + + if (status) { + /* Perhaps the child gave us the fds and then exited nonzero. + * Well that would be odd but we don't really care. */ + libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR + : LIBXL__LOG_WARNING, + "openpty child", pid, status); + } + if (op->rc) + openpty_cleanup(op); + op->callback(egc, op); +} + +int libxl__openptys(libxl__openpty_state *op, + const struct termios *termp, + const struct winsize *winp) { + /* + * This is completely crazy. openpty calls grantpt which the spec + * says may fork, and may not be called with a SIGCHLD handler. + * Now our application may have a SIGCHLD handler so that's bad. + * We could perhaps block it but we'd need to block it on all + * threads. This is just Too Hard. + * + * So instead, we run openpty in a child process. That child + * process then of course has only our own thread and our own + * signal handlers. We pass the fds back. + * + * Since our only current caller actually wants two ptys, we + * support calling openpty multiple times for a single fork. + */ + STATE_AO_GC(op->ao); + int count = op->count; + int r, i, rc, sockets[2], ptyfds[count][2]; + libxl__carefd *for_child = 0; + pid_t pid = -1; + + for (i=0; iresults[i]; + assert(!res->master); + assert(!res->slave); + } + sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */ + + libxl__carefd_begin(); + r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets); + if (r) { sockets[0] = sockets[1] = -1; } + for_child = libxl__carefd_opened(CTX, sockets[1]); + if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; } + + pid = libxl__ev_child_fork(gc, &op->child, openpty_exited); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; + } + + if (!pid) { + /* child */ + close(sockets[0]); + signal(SIGCHLD, SIG_DFL); + + for (i=0; iresults[i]; + res->master = libxl__carefd_record(CTX, ptyfds[i][0]); + res->slave = libxl__carefd_record(CTX, ptyfds[i][1]); + } + } + /* now the pty fds are in the carefds, if they were ever open */ + libxl__carefd_unlock(); + if (rc) + goto out; + + rc = 0; + + out: + if (sockets[0] >= 0) close(sockets[0]); + libxl__carefd_close(for_child); + if (libxl__ev_child_inuse(&op->child)) { + op->rc = rc; + /* we will get a callback when the child dies */ + return 0; + } + + assert(rc); + openpty_cleanup(op); + return rc; +} + diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index be11fbd..3744a28 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1513,6 +1513,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc); _hidden int libxl__datacopier_start(libxl__datacopier_state *dc); +/*----- openpty -----*/ + +/* + * opens count (>0) ptys like count calls to openpty, and then + * calls back. On entry, all op[].master and op[].slave must be + * 0. On callback, either rc==0 and master and slave are non-0, + * or rc is a libxl error and they are both 0. If libxl__openpty + * returns non-0 no callback will happen and everything is left + * cleaned up. + */ + +typedef struct libxl__openpty_state libxl__openpty_state; +typedef struct libxl__openpty_result libxl__openpty_result; +typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op); + +struct libxl__openpty_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + libxl__openpty_callback *callback; + int count; + libxl__openpty_result *results; /* actual size is count, out parameter */ + /* public, result, caller may only read in callback */ + int rc; + /* private for implementation */ + libxl__ev_child child; +}; + +struct libxl__openpty_result { + libxl__carefd *master, *slave; +}; + +int libxl__openptys(libxl__openpty_state *op, + const struct termios *termp, + const struct winsize *winp); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6m-0006fc-Hz; Fri, 11 May 2012 17:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006X7-T9 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42723] by server-2.bemta-4.messagelabs.com id A9/02-17550-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25794 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435481" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IY-Uo; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gV-SQ; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:07 +0100 Message-ID: <1336759092-2432-23-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 22/27] libxl: provide progress reporting for long-running operations X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This will be used for reporting, during domain creation, that the console is ready. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * If aop->how.callback, actually add the aop to the for_callback list (!) * Document the threadsafety of aop's, and make appropriate cross-references. * Allocate the actual aop from its thread's egc; do not free it. * Remove pointless code motion of libxl__ao_create. * Minor formatting fixes. --- tools/libxl/libxl.h | 45 ++++++++++++++++++++++++++ tools/libxl/libxl_event.c | 72 ++++++++++++++++++++++++++++++++++++++++-- tools/libxl/libxl_internal.h | 35 ++++++++++++++++++++ 3 files changed, 149 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index e19d947..ba0f4de 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -435,6 +435,51 @@ typedef struct { } u; } libxl_asyncop_how; +/* + * Some more complex asynchronous operations can report intermediate + * progress. How this is to be reported is controlled, for each + * function, by a parameter + * libxl_asyncprogress_how *aop_FOO_how; + * for each kind of progress FOO supported by that function. Each + * such kind of progress is associated with an event type. + * + * The function description will document whether, when, and how + * many times, the intermediate progress will be reported, and + * what the corresponding event type(s) are. + * + * If aop_FOO_how==NULL, intermediate progress reports are discarded. + * + * If aop_FOO_how->callback==NULL, intermediate progress reports + * generate libxl events which can be obtained from libxl_event_wait + * or libxl_event_check. + * + * If aop_FOO_how->callback!=NULL, libxl will report intermediate + * progress by calling callback(ctx, &event, for_callback). + * + * The rules for these events are otherwise the same as those for + * ordinary events. The reentrancy and threading rules for the + * callback are the same as those for ao completion callbacks. + * + * Note that the callback, if provided, is responsible for freeing + * the event. + * + * If callbacks are requested, they will be made, and returned, before + * the long-running libxl operation is considered finished (so if the + * long-running libxl operation was invoked with ao_how==NULL then any + * callbacks will occur strictly before the long-running operation + * returns). However, the callbacks may occur on any thread. + * + * In general, otherwise, no promises are made about the relative + * order of callbacks in a multithreaded program. In particular + * different callbacks relating to the same long-running operation may + * be delivered out of order. + */ + +typedef struct { + void (*callback)(libxl_ctx *ctx, libxl_event*, void *for_callback); + libxl_ev_user for_event; /* always used */ + void *for_callback; /* passed to callback */ +} libxl_asyncprogress_how; #define LIBXL_VERSION 0 diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index b546471..460ef66 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -902,18 +902,29 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval, static void egc_run_callbacks(libxl__egc *egc) { /* - * The callbacks must happen with the ctx unlocked. - * See the comment near #define EGC_GC in libxl_internal.h and - * those in the definitions of libxl__egc and libxl__ao. + * The callbacks must happen with the ctx unlocked. See the + * comment near #define EGC_GC in libxl_internal.h and those in + * the definitions of libxl__egc, libxl__ao and libxl__aop. */ EGC_GC; libxl_event *ev, *ev_tmp; + libxl__aop_occurred *aop, *aop_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_TAILQ_FOREACH_SAFE(aop, &egc->aops_for_callback, entry, aop_tmp) { + LIBXL_TAILQ_REMOVE(&egc->aops_for_callback, aop, entry); + aop->how->callback(CTX, aop->ev, aop->how->for_callback); + + CTX_LOCK; + aop->ao->progress_reports_outstanding--; + libxl__ao_complete_check_progress_reports(egc, aop->ao); + CTX_UNLOCK; + } + libxl__ao *ao, *ao_tmp; LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback, entry_for_callback, ao_tmp) { @@ -1296,6 +1307,7 @@ void libxl__ao_abort(libxl__ao *ao) assert(ao->magic == LIBXL__AO_MAGIC); assert(ao->in_initiator); assert(!ao->complete); + assert(!ao->progress_reports_outstanding); libxl__ao__destroy(CTX, ao); } @@ -1306,6 +1318,24 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) ao->complete = 1; ao->rc = rc; + libxl__ao_complete_check_progress_reports(egc, ao); +} + +void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao) +{ + /* + * We don't consider an ao complete if it has any outstanding + * callbacks. These callbacks might be outstanding on other + * threads, queued up in the other threads' egc's. Those threads + * will, after making the callback, take out the lock again, + * decrement progress_reports_outstanding, and call us again. + */ + + assert(ao->progress_reports_outstanding >= 0); + + if (!ao->complete || ao->progress_reports_outstanding) + return; + if (ao->poller) { assert(ao->in_initiator); if (!ao->constructing) @@ -1355,6 +1385,7 @@ libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid, return NULL; } + int libxl__ao_inprogress(libxl__ao *ao) { AO_GC; @@ -1412,6 +1443,41 @@ int libxl__ao_inprogress(libxl__ao *ao) } +/* progress reporting */ + +/* The application indicates a desire to ignore events by passing NULL + * for how. But we want to copy *how. So we have this dummy function + * whose address is stored in callback if the app passed how==NULL. */ +static void dummy_asyncprogress_callback_ignore + (libxl_ctx *ctx, libxl_event *ev, void *for_callback) { } + +void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state, + const libxl_asyncprogress_how *from_app) { + if (from_app) + *in_state = *from_app; + else + in_state->callback = dummy_asyncprogress_callback_ignore; +} + +void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao, + const libxl_asyncprogress_how *how, libxl_event *ev) +{ + ev->for_user = how->for_event; + if (how->callback == dummy_asyncprogress_callback_ignore) { + /* ignore */ + } else if (how->callback) { + libxl__aop_occurred *aop = libxl__zalloc(&egc->gc, sizeof(*aop)); + ao->progress_reports_outstanding++; + aop->ao = ao; + aop->ev = ev; + aop->how = how; + LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry); + } else { + libxl__event_occurred(egc, ev); + } +} + + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index f48cfdc..d5cf69a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -119,6 +119,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__aop_occurred libxl__aop_occurred; _hidden void libxl__alloc_failed(libxl_ctx *, const char *func, size_t nmemb, size_t size) __attribute__((noreturn)); @@ -364,6 +365,21 @@ struct libxl__egc { struct libxl__gc gc; struct libxl__event_list occurred_for_callback; LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback; + LIBXL_TAILQ_HEAD(, libxl__aop_occurred) aops_for_callback; +}; + +struct libxl__aop_occurred { + /* + * An aop belongs to, and may be accessed only on, the thread + * which created it. It normally lives in that thread's egc. + * + * While an aop exists, it corresponds to one refcount in + * ao->progress_reports_outstanding, preventing ao destruction. + */ + LIBXL_TAILQ_ENTRY(libxl__aop_occurred) entry; + libxl__ao *ao; + libxl_event *ev; + const libxl_asyncprogress_how *how; }; #define LIBXL__AO_MAGIC 0xA0FACE00ul @@ -386,6 +402,7 @@ struct libxl__ao { */ uint32_t magic; unsigned constructing:1, in_initiator:1, complete:1, notified:1; + int progress_reports_outstanding; int rc; libxl__gc gc; libxl_asyncop_how how; @@ -1402,6 +1419,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid); LIBXL_INIT_GC((egc).gc,ctx); \ LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \ LIBXL_TAILQ_INIT(&(egc).aos_for_callback); \ + LIBXL_TAILQ_INIT(&(egc).aops_for_callback); \ } while(0) _hidden void libxl__egc_cleanup(libxl__egc *egc); @@ -1448,6 +1466,9 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); * 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 the operation provides progress reports, the aop_how(s) + * must be copied into the per-operation structure using + * libxl__ao_progress_gethow. * * - If initiation is successful, the initiating function needs * to run libxl__ao_inprogress right before unlocking and @@ -1457,6 +1478,10 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc); * call libxl__ao_abort before unlocking and returning whatever * error code is appropriate (AO_ABORT macro). * + * - If the operation supports progress reports, it may generate + * suitable events with NEW_EVENT and report them with + * libxl__ao_progress_report (with the ctx locked). + * * - 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 @@ -1512,8 +1537,18 @@ _hidden int libxl__ao_inprogress(libxl__ao *ao); /* temporarily unlocks */ _hidden void libxl__ao_abort(libxl__ao *ao); _hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc); +/* Can be called at any time. Use is essential for any aop user. */ +_hidden void libxl__ao_progress_gethow(libxl_asyncprogress_how *in_state, + const libxl_asyncprogress_how *from_app); + +/* Must be called with the ctx locked. Will fill in ev->for_user, + * so caller need not do that. */ +_hidden void libxl__ao_progress_report(libxl__egc *egc, libxl__ao *ao, + const libxl_asyncprogress_how *how, libxl_event *ev /* consumed */); + /* For use by ao machinery ONLY */ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao); +_hidden void libxl__ao_complete_check_progress_reports(libxl__egc*, libxl__ao*); /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6q-0006mI-2d; Fri, 11 May 2012 17:58:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-RD for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:23 +0000 Received: from [85.158.143.35:42729] by server-1.bemta-4.messagelabs.com id 26/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!8 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25806 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435485" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Im-7X; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gs-6p; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:12 +0100 Message-ID: <1336759092-2432-28-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 27/27] libxl: abort bootloader invocation when domain dies X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Cancel the bootloader (specifically, by sending it a signal) if the domain is seen to disappear from xenstore. We use a new utility event source libxl__domaindeathcheck which provides a convenient wrapper for the xenstore watch. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v8: * Fixed the commit message summary line. Changes since v7: * Add a comment explaining why we use a watch on the domain's xenstore path rather than @releaseDomain. * Fix typo in error message. --- tools/libxl/libxl_bootloader.c | 43 ++++++++++++++++++++++++++++-------- tools/libxl/libxl_event.c | 47 ++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 29 +++++++++++++++++++++++- 3 files changed, 108 insertions(+), 11 deletions(-) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 8436c07..fb1302b 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -31,6 +31,7 @@ static void bootloader_keystrokes_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval); static void bootloader_display_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_domaindeath(libxl__egc*, libxl__domaindeathcheck *dc); static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, pid_t pid, int status); @@ -213,6 +214,7 @@ void libxl__bootloader_init(libxl__bootloader_state *bl) bl->ptys[0].master = bl->ptys[0].slave = 0; bl->ptys[1].master = bl->ptys[1].slave = 0; libxl__ev_child_init(&bl->child); + libxl__domaindeathcheck_init(&bl->deathcheck); bl->keystrokes.ao = bl->ao; libxl__datacopier_init(&bl->keystrokes); bl->display.ao = bl->ao; libxl__datacopier_init(&bl->display); } @@ -230,6 +232,7 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) free(bl->diskpath); bl->diskpath = 0; } + libxl__domaindeathcheck_stop(gc,&bl->deathcheck); libxl__datacopier_kill(&bl->keystrokes); libxl__datacopier_kill(&bl->display); for (i=0; i<2; i++) { @@ -256,6 +259,23 @@ static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl, bl->callback(egc, bl, rc); } +/* might be called at any time, provided it's init'd */ +static void bootloader_abort(libxl__egc *egc, + libxl__bootloader_state *bl, int rc) +{ + STATE_AO_GC(bl->ao); + int r; + + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + if (libxl__ev_child_inuse(&bl->child)) { + r = kill(bl->child.pid, SIGTERM); + if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", + (unsigned long)bl->child.pid); + } + bl->rc = rc; +} + /*----- main flow of control -----*/ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) @@ -377,6 +397,12 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) goto out; } + bl->deathcheck.what = "stopping bootloader"; + bl->deathcheck.domid = bl->domid; + bl->deathcheck.callback = bootloader_domaindeath; + rc = libxl__domaindeathcheck_start(gc, &bl->deathcheck); + if (rc) goto out; + if (bl->console_available) bl->console_available(egc, bl); @@ -454,18 +480,9 @@ static void bootloader_copyfail(libxl__egc *egc, const char *which, libxl__bootloader_state *bl, int onwrite, int errnoval) { STATE_AO_GC(bl->ao); - int r; - if (!onwrite && !errnoval) LOG(ERROR, "unexpected eof copying %s", which); - libxl__datacopier_kill(&bl->keystrokes); - libxl__datacopier_kill(&bl->display); - if (libxl__ev_child_inuse(&bl->child)) { - r = kill(bl->child.pid, SIGTERM); - if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", - (unsigned long)bl->child.pid); - } - bl->rc = ERROR_FAIL; + bootloader_abort(egc, bl, ERROR_FAIL); } static void bootloader_keystrokes_copyfail(libxl__egc *egc, libxl__datacopier_state *dc, int onwrite, int errnoval) @@ -480,6 +497,12 @@ static void bootloader_display_copyfail(libxl__egc *egc, bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval); } +static void bootloader_domaindeath(libxl__egc *egc, libxl__domaindeathcheck *dc) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, deathcheck); + bootloader_abort(egc, bl, ERROR_FAIL); +} + static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, pid_t pid, int status) { diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 63719b2..03d0498 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -589,6 +589,53 @@ int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, } /* + * domain death/destruction + */ + +/* + * We use a xenstore watch on the domain's path, rather than using an + * @releaseDomain watch and asking the hypervisor. This is simpler + * because turning @releaseDomain into domain-specific information is + * complicated. + * + * It is also sufficient for our callers, which are generally trying + * to do cleanup of their own execution state on domain death, for the + * following reason: if the domain is destroyed then either (a) the + * entries in xenstore have already been deleted, in which case the + * test here works or (b) they have not in which case something has + * gone very badly wrong and we are going to leak those xenstore + * entries, in which case trying to avoid leaking other stuff is + * futile. + */ + +static void domaindeathcheck_callback(libxl__egc *egc, libxl__ev_xswatch *w, + const char *watch_path, const char *event_path) +{ + libxl__domaindeathcheck *dc = CONTAINER_OF(w, *dc, watch); + EGC_GC; + const char *p = libxl__xs_read(gc, XBT_NULL, watch_path); + if (p) return; + + if (errno!=ENOENT) { + LIBXL__EVENT_DISASTER(egc,"failed to read xenstore" + " for domain detach check", errno, 0); + return; + } + + LOG(ERROR,"%s: domain %"PRIu32" removed (%s no longer in xenstore)", + dc->what, dc->domid, watch_path); + dc->callback(egc, dc); +} + +int libxl__domaindeathcheck_start(libxl__gc *gc, + libxl__domaindeathcheck *dc) +{ + const char *path = GCSPRINTF("/local/domain/%"PRIu32, dc->domid); + return libxl__ev_xswatch_register(gc, &dc->watch, + domaindeathcheck_callback, path); +} + +/* * osevent poll */ diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 83fabea..f71e76a 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -866,6 +866,33 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, const char *state_path, int state, int milliseconds); +/* + * libxl__ev_domaindeathcheck_register - arranges to call back (once) + * if the domain is destroyed. If the domain dies, we log a message + * of the form ": ". + */ + +typedef struct libxl__domaindeathcheck libxl__domaindeathcheck; +typedef void libxl___domaindeathcheck_callback(libxl__egc *egc, + libxl__domaindeathcheck*); + +struct libxl__domaindeathcheck { + /* must be filled in by caller, and remain valid: */ + const char *what; + uint32_t domid; + libxl___domaindeathcheck_callback *callback; + /* private */ + libxl__ev_xswatch watch; +}; + +_hidden int libxl__domaindeathcheck_start(libxl__gc *gc, + libxl__domaindeathcheck *dc); + +static inline void libxl__domaindeathcheck_init + (libxl__domaindeathcheck *dc) { libxl__ev_xswatch_init(&dc->watch); } +static inline void libxl__domaindeathcheck_stop(libxl__gc *gc, + libxl__domaindeathcheck *dc) { libxl__ev_xswatch_deregister(gc,&dc->watch); } + /* * libxl__try_phy_backend - Check if there's support for the passed @@ -1738,6 +1765,7 @@ struct libxl__bootloader_state { libxl__openpty_state openpty; libxl__openpty_result ptys[2]; /* [0] is for bootloader */ libxl__ev_child child; + libxl__domaindeathcheck deathcheck; int nargs, argsspace; const char **args; libxl__datacopier_state keystrokes, display; @@ -1750,7 +1778,6 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); * If callback is passed rc==0, will have updated st->info appropriately */ _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); - /*----- Domain creation -----*/ typedef struct libxl__domain_create_state libxl__domain_create_state; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6o-0006jN-GS; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006X7-F8 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42728] by server-2.bemta-4.messagelabs.com id F9/02-17550-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32070 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435484" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ie-3L; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gg-0Y; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:09 +0100 Message-ID: <1336759092-2432-25-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH 24/27] libxl: convert console callback to libxl_asyncprogress_how X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove the old console callback. (Its reentrancy properties were troublesome: in principle, the event loop might be reentered during the callback, and the libxl__domain_create_state swept out from under the feet of the domain creation.) As a side effect of the new code arrangements, the console callback for non-bootloader-using PV guests now occurs near the end of domain creation, in the same place as for HVM guests, rather than near the start. The new arrangements should in principle mean that by the time the console is described as ready by the callback, the xenstore key is indeed ready. So in the future the timeout might be removed from the console client. Signed-off-by: Ian Jackson Cc: Stefano Stabellini Acked-by: Ian Campbell --- tools/libxl/libxl.h | 17 ++++++----- tools/libxl/libxl_bootloader.c | 3 ++ tools/libxl/libxl_create.c | 59 +++++++++++++++++++++++----------------- tools/libxl/libxl_internal.h | 6 +++- tools/libxl/libxl_types.idl | 2 + tools/libxl/xl_cmdimpl.c | 25 ++++++++++------- 6 files changed, 67 insertions(+), 45 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index ba0f4de..979940a 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */); /* domain related functions */ -typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv); - /* fixme-ao Need to review this API. If we keep it, the reentrancy - * properties need to be documented but they may turn out to be too - * awkward */ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - const libxl_asyncop_how *ao_how); + uint32_t *domid, + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how); 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, - const libxl_asyncop_how *ao_how); + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how); + /* A progress report will be made via ao_console_how, of type + * domain_create_console_available, when the domain's primary + * console is available and can be connected to. + */ void libxl_domain_config_init(libxl_domain_config *d_config); void libxl_domain_config_dispose(libxl_domain_config *d_config); diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 1534bae..8436c07 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) goto out; } + if (bl->console_available) + bl->console_available(egc, bl); + int bootloader_master = libxl__carefd_fd(bl->ptys[0].master); int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 63cb430..14721eb 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -569,10 +569,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int rc); +static void domcreate_bootloader_console_available(libxl__egc *egc, + libxl__bootloader_state *bl); static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int rc); +static void domcreate_console_available(libxl__egc *egc, + libxl__domain_create_state *dcs); + /* Our own function to clean up and call the user's callback. * The final call in the sequence. */ static void domcreate_complete(libxl__egc *egc, @@ -590,8 +595,6 @@ static void initiate_domain_create(libxl__egc *egc, /* convenience aliases */ libxl_domain_config *const d_config = dcs->guest_config; const int restore_fd = dcs->restore_fd; - const libxl_console_ready cb = dcs->console_cb; - void *const priv = dcs->console_cb_priv; memset(&dcs->build_state, 0, sizeof(dcs->build_state)); domid = 0; @@ -610,11 +613,6 @@ static void initiate_domain_create(libxl__egc *egc, dcs->guest_domid = domid; dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */ - if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) { - ret = (*cb)(ctx, domid, priv); - if (ret) goto error_out; - } - ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info); if (ret) goto error_out; @@ -629,6 +627,7 @@ static void initiate_domain_create(libxl__egc *egc, if (restore_fd < 0 && bootdisk) { dcs->bl.callback = domcreate_bootloader_done; + dcs->bl.console_available = domcreate_bootloader_console_available; dcs->bl.info = &d_config->b_info, dcs->bl.disk = bootdisk; dcs->bl.domid = dcs->guest_domid; @@ -644,6 +643,21 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_bootloader_console_available(libxl__egc *egc, + libxl__bootloader_state *bl) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl); + STATE_AO_GC(bl->ao); + domcreate_console_available(egc, dcs); +} + +static void domcreate_console_available(libxl__egc *egc, + libxl__domain_create_state *dcs) { + libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how, + NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE, + dcs->guest_domid)); +} + static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int ret) @@ -779,8 +793,6 @@ static void domcreate_devmodel_started(libxl__egc *egc, /* convenience aliases */ libxl_domain_config *const d_config = dcs->guest_config; - const libxl_console_ready cb = dcs->console_cb; - void *const priv = dcs->console_cb_priv; if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, @@ -818,12 +830,7 @@ static void domcreate_devmodel_started(libxl__egc *egc, goto error_out; } } - 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 ))) { - ret = (*cb)(ctx, domid, priv); - if (ret) goto error_out; - } + domcreate_console_available(egc, dcs); domcreate_complete(egc, dcs, 0); return; @@ -863,8 +870,9 @@ static void domain_create_cb(libxl__egc *egc, int rc, uint32_t domid); static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - int restore_fd, const libxl_asyncop_how *ao_how) + uint32_t *domid, + int restore_fd, const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { AO_CREATE(ctx, 0, ao_how); libxl__app_domain_create_state *cdcs; @@ -873,9 +881,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, cdcs->dcs.ao = ao; cdcs->dcs.guest_config = d_config; cdcs->dcs.restore_fd = restore_fd; - cdcs->dcs.console_cb = cb; - cdcs->dcs.console_cb_priv = priv; cdcs->dcs.callback = domain_create_cb; + libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how); cdcs->domid_out = domid; initiate_domain_create(egc, &cdcs->dcs); @@ -897,19 +904,21 @@ static void domain_create_cb(libxl__egc *egc, } int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - const libxl_asyncop_how *ao_how) + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { - return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how); + return do_domain_create(ctx, d_config, domid, -1, + ao_how, aop_console_how); } 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, - const libxl_asyncop_how *ao_how) + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { - return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how); + return do_domain_create(ctx, d_config, domid, restore_fd, + ao_how, aop_console_how); } /* diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index a407317..3aa0ed7 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1699,11 +1699,14 @@ int libxl__openptys(libxl__openpty_state *op, typedef struct libxl__bootloader_state libxl__bootloader_state; typedef void libxl__run_bootloader_callback(libxl__egc*, libxl__bootloader_state*, int rc); +typedef void libxl__bootloader_console_callback(libxl__egc*, + libxl__bootloader_state*); struct libxl__bootloader_state { /* caller must fill these in, and they must all remain valid */ libxl__ao *ao; libxl__run_bootloader_callback *callback; + libxl__bootloader_console_callback *console_available; libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */ libxl_device_disk *disk; uint32_t domid; @@ -1739,9 +1742,8 @@ struct libxl__domain_create_state { libxl__ao *ao; libxl_domain_config *guest_config; int restore_fd; - libxl_console_ready console_cb; - void *console_cb_priv; libxl__domain_create_cb *callback; + libxl_asyncprogress_how aop_console_how; /* private to domain_create */ int guest_domid; libxl__domain_build_state build_state; diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 68599cb..551e367 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -459,6 +459,7 @@ libxl_event_type = Enumeration("event_type", [ (2, "DOMAIN_DEATH"), (3, "DISK_EJECT"), (4, "OPERATION_COMPLETE"), + (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"), ]) libxl_ev_user = UInt(64) @@ -484,4 +485,5 @@ libxl_event = Struct("event",[ ("operation_complete", Struct(None, [ ("rc", integer), ])), + ("domain_create_console_available", Struct(None, [])), ]))]) diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 621aeaf..b91a2d5 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1457,16 +1457,18 @@ static int freemem(libxl_domain_build_info *b_info) return ERROR_NOMEM; } -static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv) +static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv) { pid_t *pid = priv; + libxl_event_free(ctx, ev); + *pid = fork(); if (*pid < 0) { perror("unable to fork xenconsole"); - return ERROR_FAIL; + return; } else if (*pid > 0) - return 0; + return; postfork(); @@ -1533,7 +1535,7 @@ static int create_domain(struct domain_create *dom_info) int config_len = 0; int restore_fd = -1; int status = 0; - libxl_console_ready cb; + const libxl_asyncprogress_how *autoconnect_console_how; pid_t child_console_pid = -1; struct save_file_header hdr; @@ -1687,24 +1689,27 @@ start: goto error_out; } + libxl_asyncprogress_how autoconnect_console_how_buf; if ( dom_info->console_autoconnect ) { - cb = autoconnect_console; + autoconnect_console_how_buf.callback = autoconnect_console; + autoconnect_console_how_buf.for_callback = &child_console_pid; + autoconnect_console_how = &autoconnect_console_how_buf; }else{ - cb = NULL; + autoconnect_console_how = 0; } if ( restore_file ) { ret = libxl_domain_create_restore(ctx, &d_config, - cb, &child_console_pid, - &domid, restore_fd, 0); + &domid, restore_fd, + 0, autoconnect_console_how); /* * On subsequent reboot etc we should create the domain, not * restore/migrate-receive it again. */ restore_file = NULL; }else{ - ret = libxl_domain_create_new(ctx, &d_config, - cb, &child_console_pid, &domid, 0); + ret = libxl_domain_create_new(ctx, &d_config, &domid, + 0, autoconnect_console_how); } if ( ret ) goto error_out; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6j-0006bs-Lq; Fri, 11 May 2012 17:58:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006X7-9f for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:57415] by server-2.bemta-4.messagelabs.com id 97/02-17550-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32036 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435474" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IK-Jj; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gB-Hy; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:02 +0100 Message-ID: <1336759092-2432-18-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 17/27] libxl: change some structures to unit arrays X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org In the next patch these variables will turn into actual pointers. To clarify that patch, prepare the ground by changing these variables from "struct foo var" to "struct foo var[1]". This enables accesses to them and their members to be made as if they were pointers. No functional change. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_create.c | 18 +++++----- tools/libxl/libxl_dm.c | 84 ++++++++++++++++++++++---------------------- 2 files changed, 51 insertions(+), 51 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index f7732aa..b137288 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -564,7 +564,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, { libxl_ctx *ctx = libxl__gc_owner(gc); libxl__spawner_starting *dm_starting = 0; - libxl__domain_build_state state; + libxl__domain_build_state state[1]; uint32_t domid; int i, ret; @@ -606,12 +606,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } } - memset(&state, 0, sizeof(state)); + memset(state, 0, sizeof(*state)); if ( restore_fd >= 0 ) { - ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state); + ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state); } else { - ret = libxl__domain_build(gc, &d_config->b_info, domid, &state); + ret = libxl__domain_build(gc, &d_config->b_info, domid, state); } if (ret) { @@ -649,7 +649,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, ret = init_console_info(&console, 0); if ( ret ) goto error_out; - libxl__device_console_add(gc, domid, &console, &state); + libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); libxl_device_vkb_init(&vkb); @@ -657,7 +657,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl_device_vkb_dispose(&vkb); ret = libxl__create_device_model(gc, domid, d_config, - &state, &dm_starting); + state, &dm_starting); if (ret < 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to create device model: %d", ret); @@ -683,11 +683,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, d_config->num_vfbs, d_config->vfbs, d_config->num_disks, &d_config->disks[0]); - libxl__device_console_add(gc, domid, &console, &state); + libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); if (need_qemu) { - libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting); + libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting); } break; } @@ -701,7 +701,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { libxl__qmp_initializations(gc, domid, d_config); } - ret = libxl__confirm_device_model_startup(gc, &state, 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 --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 36b0730..725c3c0 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -678,10 +678,10 @@ static int libxl__create_stubdom(libxl__gc *gc, 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_domain_config dm_config[1]; libxl_device_vfb vfb; libxl_device_vkb vkb; - libxl__domain_build_state stubdom_state; + libxl__domain_build_state stubdom_state[1]; uint32_t dm_domid; char **args; struct xs_permissions perm[2]; @@ -694,58 +694,58 @@ static int libxl__create_stubdom(libxl__gc *gc, goto out; } - libxl_domain_create_info_init(&dm_config.c_info); - dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV; - dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", + libxl_domain_create_info_init(&dm_config->c_info); + dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV; + dm_config->c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, guest_domid)); - dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref; + dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref; - libxl_uuid_generate(&dm_config.c_info.uuid); + libxl_uuid_generate(&dm_config->c_info.uuid); - libxl_domain_build_info_init(&dm_config.b_info); - libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV); + libxl_domain_build_info_init(&dm_config->b_info); + libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV); - dm_config.b_info.max_vcpus = 1; - dm_config.b_info.max_memkb = 32 * 1024; - dm_config.b_info.target_memkb = dm_config.b_info.max_memkb; + 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.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz", + dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path()); - dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid); - dm_config.b_info.u.pv.ramdisk.path = ""; - dm_config.b_info.u.pv.features = ""; + 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 = ""; - dm_config.b_info.device_model_version = + dm_config->b_info.device_model_version = guest_config->b_info.device_model_version; - dm_config.b_info.device_model = + 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->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; + 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; + dm_config->vifs = guest_config->vifs; + dm_config->num_vifs = guest_config->num_vifs; - ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info); + ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info); if (ret) goto out; - ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info); + ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info); if (ret) goto out; libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb); - dm_config.vfbs = &vfb; - dm_config.num_vfbs = 1; - dm_config.vkbs = &vkb; - dm_config.num_vkbs = 1; + 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 */ dm_domid = 0; - ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid); + ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid); if (ret) goto out; - ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state); + ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state); if (ret) goto out; @@ -790,20 +790,20 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - for (i = 0; i < dm_config.num_disks; i++) { - ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]); + for (i = 0; i < dm_config->num_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, dm_domid, &dm_config.vifs[i]); + for (i = 0; i < dm_config->num_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, dm_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, dm_domid, &dm_config.vkbs[0]); + ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); if (ret) goto out_free; @@ -847,14 +847,14 @@ retry_transaction: break; } ret = libxl__device_console_add(gc, dm_domid, &console[i], - i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL); + i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL); if (ret) goto out_free; } if (libxl__create_xenpv_qemu(gc, dm_domid, - &dm_config, - &stubdom_state, + dm_config, + stubdom_state, &dm_starting) < 0) { ret = ERROR_FAIL; goto out_free; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6k-0006cG-0q; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wq-Af for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42659] by server-3.bemta-4.messagelabs.com id 5C/F4-05853-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32026 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435467" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Ht-3p; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fe-1u; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:54 +0100 Message-ID: <1336759092-2432-10-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 09/27] libxl: provide libxl__datacopier_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org General facility for ao operations to shovel data between fds. This will be used by the bootloader machinery. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes in v7: * assert that the ao is non-null on _init. --- tools/libxl/Makefile | 3 +- tools/libxl/libxl_aoutils.c | 189 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 40 +++++++++ 3 files changed, 231 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_aoutils.c diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 1261d43..5d9227e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -64,7 +64,8 @@ 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_internal.o libxl_utils.o libxl_uuid.o \ + libxl_json.o libxl_aoutils.o \ libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c new file mode 100644 index 0000000..4c60ad9 --- /dev/null +++ b/tools/libxl/libxl_aoutils.c @@ -0,0 +1,189 @@ +/* + * Copyright (C) 2010 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. + */ + +#include "libxl_osdeps.h" /* must come before any other headers */ + +#include "libxl_internal.h" + +/*----- data copier -----*/ + +void libxl__datacopier_init(libxl__datacopier_state *dc) +{ + assert(dc->ao); + libxl__ev_fd_init(&dc->toread); + libxl__ev_fd_init(&dc->towrite); + LIBXL_TAILQ_INIT(&dc->bufs); +} + +void libxl__datacopier_kill(libxl__datacopier_state *dc) +{ + STATE_AO_GC(dc->ao); + libxl__datacopier_buf *buf, *tbuf; + + libxl__ev_fd_deregister(gc, &dc->toread); + libxl__ev_fd_deregister(gc, &dc->towrite); + LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf) + free(buf); + LIBXL_TAILQ_INIT(&dc->bufs); +} + +static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc, + int onwrite, int errnoval) +{ + libxl__datacopier_kill(dc); + dc->callback(egc, dc, onwrite, errnoval); +} + +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents); + +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc) +{ + STATE_AO_GC(dc->ao); + int rc; + + if (dc->used) { + if (!libxl__ev_fd_isregistered(&dc->towrite)) { + rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable, + dc->writefd, POLLOUT); + if (rc) { + LOG(ERROR, "unable to establish write event on %s" + " during copy of %s", dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + } + } else if (!libxl__ev_fd_isregistered(&dc->toread)) { + /* we have had eof */ + datacopier_callback(egc, dc, 0, 0); + return; + } else { + /* nothing buffered, but still reading */ + libxl__ev_fd_deregister(gc, &dc->towrite); + } +} + +static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents) { + libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread); + STATE_AO_GC(dc->ao); + + if (revents & ~POLLIN) { + LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)" + " on %s during copy of %s", revents, dc->readwhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + assert(revents & POLLIN); + for (;;) { + while (dc->used >= dc->maxsz) { + libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs); + dc->used -= rm->used; + assert(dc->used >= 0); + LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry); + free(rm); + } + + libxl__datacopier_buf *buf = + LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs); + if (!buf || buf->used >= sizeof(buf->buf)) { + buf = malloc(sizeof(*buf)); + if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf)); + buf->used = 0; + LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry); + } + int r = read(ev->fd, + buf->buf + buf->used, + sizeof(buf->buf) - buf->used); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) break; + LOGE(ERROR, "error reading %s during copy of %s", + dc->readwhat, dc->copywhat); + datacopier_callback(egc, dc, 0, errno); + return; + } + if (r == 0) { + libxl__ev_fd_deregister(gc, &dc->toread); + break; + } + buf->used += r; + dc->used += r; + assert(buf->used <= sizeof(buf->buf)); + } + datacopier_check_state(egc, dc); +} + +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents) { + libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite); + STATE_AO_GC(dc->ao); + + if (revents & ~POLLOUT) { + LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)" + " on %s during copy of %s", revents, dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + assert(revents & POLLOUT); + for (;;) { + libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs); + if (!buf) + break; + if (!buf->used) { + LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry); + free(buf); + continue; + } + int r = write(ev->fd, buf->buf, buf->used); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) break; + LOGE(ERROR, "error writing to %s during copy of %s", + dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, 1, errno); + return; + } + assert(r > 0); + assert(r <= buf->used); + buf->used -= r; + dc->used -= r; + assert(dc->used >= 0); + memmove(buf->buf, buf->buf+r, buf->used); + } + datacopier_check_state(egc, dc); +} + +int libxl__datacopier_start(libxl__datacopier_state *dc) +{ + int rc; + STATE_AO_GC(dc->ao); + + libxl__datacopier_init(dc); + + rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable, + dc->readfd, POLLIN); + if (rc) goto out; + + rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable, + dc->writefd, POLLOUT); + if (rc) goto out; + + return 0; + + out: + libxl__datacopier_kill(dc); + return rc; +} + diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index e25569c..be11fbd 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -840,6 +840,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, */ _hidden int libxl__try_phy_backend(mode_t st_mode); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); @@ -1473,6 +1474,45 @@ _hidden const char *libxl__xen_script_dir_path(void); _hidden const char *libxl__lock_dir_path(void); _hidden const char *libxl__run_dir_path(void); +/*----- datacopier: copies data from one fd to another -----*/ + +typedef struct libxl__datacopier_state libxl__datacopier_state; +typedef struct libxl__datacopier_buf libxl__datacopier_buf; + +/* onwrite==1 means failure happened when writing, logged, errnoval is valid + * onwrite==0 means failure happened when reading + * errnoval==0 means we got eof and all data was written + * errnoval!=0 means we had a read error, logged + * onwrite==-1 means some other internal failure, errnoval not valid, logged + * in all cases copier is killed before calling this callback */ +typedef void libxl__datacopier_callback(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); + +struct libxl__datacopier_buf { + /* private to datacopier */ + LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry; + int used; + char buf[1000]; +}; + +struct libxl__datacopier_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + int readfd, writefd; + ssize_t maxsz; + const char *copywhat, *readwhat, *writewhat; /* for error msgs */ + libxl__datacopier_callback *callback; + /* remaining fields are private to datacopier */ + libxl__ev_fd toread, towrite; + ssize_t used; + LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs; +}; + +_hidden void libxl__datacopier_init(libxl__datacopier_state *dc); +_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc); +_hidden int libxl__datacopier_start(libxl__datacopier_state *dc); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6l-0006eM-LC; Fri, 11 May 2012 17:58:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006XP-Jx for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4152] by server-6.bemta-5.messagelabs.com id E7/1C-13222-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!11 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30221 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435477" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IV-R7; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gN-O8; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:05 +0100 Message-ID: <1336759092-2432-21-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 20/27] libxl: make libxl_create run bootloader via callback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Change initiate_domain_create to properly use libxl__bootloader_run rather than improperly calling libxl_run_bootloader with NULL ao_how. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * constify convenience aliases. Changes since v6: * Bugfixes from testing. --- tools/libxl/libxl_create.c | 53 +++++++++++++++++++++++++++++++---------- tools/libxl/libxl_internal.h | 1 + 2 files changed, 41 insertions(+), 13 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 5075537..63cb430 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -569,6 +569,9 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int rc); +static void domcreate_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *bl, + int rc); /* Our own function to clean up and call the user's callback. * The final call in the sequence. */ @@ -589,6 +592,7 @@ static void initiate_domain_create(libxl__egc *egc, const int restore_fd = dcs->restore_fd; const libxl_console_ready cb = dcs->console_cb; void *const priv = dcs->console_cb_priv; + memset(&dcs->build_state, 0, sizeof(dcs->build_state)); domid = 0; @@ -619,21 +623,43 @@ static void initiate_domain_create(libxl__egc *egc, if (ret) goto error_out; } + dcs->bl.ao = ao; libxl_device_disk *bootdisk = d_config->num_disks > 0 ? &d_config->disks[0] : NULL; if (restore_fd < 0 && bootdisk) { - ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid, - 0 /* fixme-ao */); - if (ret) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "failed to run bootloader: %d", ret); - goto error_out; - } + dcs->bl.callback = domcreate_bootloader_done; + dcs->bl.info = &d_config->b_info, + dcs->bl.disk = bootdisk; + dcs->bl.domid = dcs->guest_domid; + + libxl__bootloader_run(egc, &dcs->bl); + } else { + domcreate_bootloader_done(egc, &dcs->bl, 0); } + return; - memset(&dcs->build_state, 0, sizeof(dcs->build_state)); - libxl__domain_build_state *state = &dcs->build_state; +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *bl, + int ret) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl); + STATE_AO_GC(bl->ao); + int i; + + /* convenience aliases */ + const uint32_t domid = dcs->guest_domid; + libxl_domain_config *const d_config = dcs->guest_config; + const int restore_fd = dcs->restore_fd; + libxl__domain_build_state *const state = &dcs->build_state; + libxl_ctx *const ctx = CTX; + + if (ret) goto error_out; /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. * Fill in any field required by either, including both relevant @@ -784,12 +810,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && libxl_defbool_val(d_config->b_info.u.pv.e820_host)) { - int rc; - rc = libxl__e820_alloc(gc, domid, d_config); - if (rc) + ret = libxl__e820_alloc(gc, domid, d_config); + if (ret) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed while collecting E820 with: %d (errno:%d)\n", - rc, errno); + ret, errno); + goto error_out; + } } if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM || (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b1ce4d6..9b4c273 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1689,6 +1689,7 @@ struct libxl__domain_create_state { /* private to domain_create */ int guest_domid; libxl__domain_build_state build_state; + libxl__bootloader_state bl; libxl__stub_dm_spawn_state dmss; /* If we're not doing stubdom, we use only dmss.dm, * for the non-stubdom device model. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006ac-HL; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wf-Pk for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4095] by server-3.bemta-5.messagelabs.com id AA/4E-25237-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30172 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435468" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Hz-6Y; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fj-3f; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:55 +0100 Message-ID: <1336759092-2432-11-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 10/27] libxl: provide libxl__openpty_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org General facility for ao operations to open ptys. This will be used by the bootloader machinery. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_aoutils.c | 127 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 36 ++++++++++++ 2 files changed, 163 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 4c60ad9..734a5dc 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -187,3 +187,130 @@ int libxl__datacopier_start(libxl__datacopier_state *dc) return rc; } +/*----- openpty -----*/ + +/* implementation */ + +static void openpty_cleanup(libxl__openpty_state *op) +{ + int i; + + for (i=0; icount; i++) { + libxl__openpty_result *res = &op->results[i]; + libxl__carefd_close(res->master); res->master = 0; + libxl__carefd_close(res->slave); res->slave = 0; + } +} + +static void openpty_exited(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) { + libxl__openpty_state *op = CONTAINER_OF(child, *op, child); + STATE_AO_GC(op->ao); + + if (status) { + /* Perhaps the child gave us the fds and then exited nonzero. + * Well that would be odd but we don't really care. */ + libxl_report_child_exitstatus(CTX, op->rc ? LIBXL__LOG_ERROR + : LIBXL__LOG_WARNING, + "openpty child", pid, status); + } + if (op->rc) + openpty_cleanup(op); + op->callback(egc, op); +} + +int libxl__openptys(libxl__openpty_state *op, + const struct termios *termp, + const struct winsize *winp) { + /* + * This is completely crazy. openpty calls grantpt which the spec + * says may fork, and may not be called with a SIGCHLD handler. + * Now our application may have a SIGCHLD handler so that's bad. + * We could perhaps block it but we'd need to block it on all + * threads. This is just Too Hard. + * + * So instead, we run openpty in a child process. That child + * process then of course has only our own thread and our own + * signal handlers. We pass the fds back. + * + * Since our only current caller actually wants two ptys, we + * support calling openpty multiple times for a single fork. + */ + STATE_AO_GC(op->ao); + int count = op->count; + int r, i, rc, sockets[2], ptyfds[count][2]; + libxl__carefd *for_child = 0; + pid_t pid = -1; + + for (i=0; iresults[i]; + assert(!res->master); + assert(!res->slave); + } + sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */ + + libxl__carefd_begin(); + r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets); + if (r) { sockets[0] = sockets[1] = -1; } + for_child = libxl__carefd_opened(CTX, sockets[1]); + if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; } + + pid = libxl__ev_child_fork(gc, &op->child, openpty_exited); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; + } + + if (!pid) { + /* child */ + close(sockets[0]); + signal(SIGCHLD, SIG_DFL); + + for (i=0; iresults[i]; + res->master = libxl__carefd_record(CTX, ptyfds[i][0]); + res->slave = libxl__carefd_record(CTX, ptyfds[i][1]); + } + } + /* now the pty fds are in the carefds, if they were ever open */ + libxl__carefd_unlock(); + if (rc) + goto out; + + rc = 0; + + out: + if (sockets[0] >= 0) close(sockets[0]); + libxl__carefd_close(for_child); + if (libxl__ev_child_inuse(&op->child)) { + op->rc = rc; + /* we will get a callback when the child dies */ + return 0; + } + + assert(rc); + openpty_cleanup(op); + return rc; +} + diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index be11fbd..3744a28 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1513,6 +1513,42 @@ _hidden void libxl__datacopier_kill(libxl__datacopier_state *dc); _hidden int libxl__datacopier_start(libxl__datacopier_state *dc); +/*----- openpty -----*/ + +/* + * opens count (>0) ptys like count calls to openpty, and then + * calls back. On entry, all op[].master and op[].slave must be + * 0. On callback, either rc==0 and master and slave are non-0, + * or rc is a libxl error and they are both 0. If libxl__openpty + * returns non-0 no callback will happen and everything is left + * cleaned up. + */ + +typedef struct libxl__openpty_state libxl__openpty_state; +typedef struct libxl__openpty_result libxl__openpty_result; +typedef void libxl__openpty_callback(libxl__egc *egc, libxl__openpty_state *op); + +struct libxl__openpty_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + libxl__openpty_callback *callback; + int count; + libxl__openpty_result *results; /* actual size is count, out parameter */ + /* public, result, caller may only read in callback */ + int rc; + /* private for implementation */ + libxl__ev_child child; +}; + +struct libxl__openpty_result { + libxl__carefd *master, *slave; +}; + +int libxl__openptys(libxl__openpty_state *op, + const struct termios *termp, + const struct winsize *winp); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6n-0006gG-02; Fri, 11 May 2012 17:58:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wa-2E for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42691] by server-1.bemta-4.messagelabs.com id 25/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32043 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435476" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IN-Li; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gF-JS; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:03 +0100 Message-ID: <1336759092-2432-19-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 18/27] libxl: ao: convert libxl__spawn_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org libxl__spawn_spawn becomes a callback-style asynchronous function. The implementation is now in terms of libxl__ev_* including libxl_ev_child. All the callers need to be updated. This includes the device model spawning functions libxl__create_device_model and libxl__create_stubdom; these are replaced with libxl__spawn_local_dm and libxl__spawn_stubdom. libxl__confirm_device_model_startup is abolished; instead the dm spawner calls back. (The choice of which kind of device model to create is lifted out of what used to be libxl__create_device_model, because that function was indirectly recursive. Recursive callback-style operations are clumsy because they require a pointer indirection for the nested states.) Waiting for proper device model startup it is no longer notionally optional. Previously the code appeared to tolerate this by passing NULL for various libxl__spawner_starting* parameters to device model spawners. However, this was not used anywhere. Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is no longer supported. It remains as an unused formal parameter to avoid updating, in this patch, all the call sites which pass NULL. libxl__wait_for_offspring is in any case itself an obsolete function, so this wrinkle will go away when its callers are updated to use the event system. Consequently libxl__spawn_check is also abolished. The "console ready" callback also remains unchanged in this patch. The API for this needs to be reviewed in the context of the event series and its reentrancy restrictions documented. Thus their callers need to be updated. These are the domain creation functions libxl_domain_create_new and _restore. These functions now take ao_hows, and have a private state structure. However domain creation remains not completely converted to the event mechanism; in particular it runs the outward-facing function libxl_run_bootloader with a NULL ao_how, which is quite wrong. As it happens in the current code this is not a bug because none of the rest of the functionality surrounding the bootloader call will mind if the event loop is reentered in the middle of its execution. The file-scope function libxl__set_fd_flag which was used by the previous spawn arrangements becomes unused and is removed; other places in libxl can use libxl_fd_set_nonblock and libxl_fd_set_cloexec, which of course remain. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v8: * Make midproc_cb callback with correct pid (that of the grandchild, not "middle" which is zero). Reported by Roger Pau Monne. Changes since v7: * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state); rename the state's stubdom_* members to dm_*. * Eliminate the union between the two dm creation states in libxl__domain_create_state. Instead, the domain creation code simply uses libxl__stub_dm_spawn_state.dm directly, if we're taking the local dm path. * Remove a spurious "break". * In domain creation, move the PV non-qemu case into the switch. * Code style fixes. * Constify some convenience aliases. * Improve comments (including typo fixes). --- tools/libxl/libxl.h | 14 ++- tools/libxl/libxl_create.c | 206 +++++++++++++++++++----- tools/libxl/libxl_dm.c | 219 +++++++++++++++----------- tools/libxl/libxl_exec.c | 354 +++++++++++++++++++++--------------------- tools/libxl/libxl_internal.h | 286 +++++++++++++++++++++++----------- tools/libxl/xl_cmdimpl.c | 6 +- 6 files changed, 683 insertions(+), 402 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d8dbb1e..e19d947 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */); /* domain related functions */ 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); + /* fixme-ao Need to review this API. If we keep it, the reentrancy + * properties need to be documented but they may turn out to be too + * awkward */ + +int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, + libxl_console_ready cb, void *priv, uint32_t *domid, + const libxl_asyncop_how *ao_how); +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, + const libxl_asyncop_how *ao_how); + void libxl_domain_config_init(libxl_domain_config *d_config); void libxl_domain_config_dispose(libxl_domain_config *d_config); int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info, diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index b137288..9ce107a 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -558,16 +558,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, libxl_device_model_version_to_string(b_info->device_model_version)); } -static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, - uint32_t *domid_out, int restore_fd) +/*----- main domain creation -----*/ + +/* We have a linear control flow; only one event callback is + * outstanding at any time. Each initiation and callback function + * arranges for the next to be called, as the very last thing it + * does. (If that particular sub-operation is not needed, a + * function will call the next event callback directly.) + */ + +/* Event callbacks, in this order: */ +static void domcreate_devmodel_started(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc); + +/* Our own function to clean up and call the user's callback. + * The final call in the sequence. */ +static void domcreate_complete(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc); + +static void initiate_domain_create(libxl__egc *egc, + libxl__domain_create_state *dcs) { + STATE_AO_GC(dcs->ao); libxl_ctx *ctx = libxl__gc_owner(gc); - libxl__spawner_starting *dm_starting = 0; - libxl__domain_build_state state[1]; uint32_t domid; int i, ret; + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + const int restore_fd = dcs->restore_fd; + const libxl_console_ready cb = dcs->console_cb; + void *const priv = dcs->console_cb_priv; + domid = 0; ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); @@ -580,9 +604,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, goto error_out; } + dcs->guest_domid = domid; + dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */ + if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) { - if ( (*cb)(ctx, domid, priv) ) - goto error_out; + ret = (*cb)(ctx, domid, priv); + if (ret) goto error_out; } ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info); @@ -606,7 +633,17 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } } - memset(state, 0, sizeof(*state)); + memset(&dcs->build_state, 0, sizeof(dcs->build_state)); + libxl__domain_build_state *state = &dcs->build_state; + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; if ( restore_fd >= 0 ) { ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state); @@ -656,14 +693,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl_device_vkb_add(ctx, domid, &vkb); libxl_device_vkb_dispose(&vkb); - ret = libxl__create_device_model(gc, domid, d_config, - state, &dm_starting); - if (ret < 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "failed to create device model: %d", ret); - goto error_out; - } - break; + dcs->dmss.dm.guest_domid = domid; + if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) + libxl__spawn_stub_dm(egc, &dcs->dmss); + else + libxl__spawn_local_dm(egc, &dcs->dmss.dm); + return; } case LIBXL_DOMAIN_TYPE_PV: { @@ -687,26 +722,52 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl__device_console_dispose(&console); if (need_qemu) { - libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting); + dcs->dmss.dm.guest_domid = domid; + libxl__spawn_local_dm(egc, &dcs->dmss.dm); + return; + } else { + assert(!dcs->dmss.dm.guest_domid); + domcreate_devmodel_started(egc, &dcs->dmss.dm, 0); + return; } - break; } default: ret = ERROR_INVAL; goto error_out; } + abort(); /* not reached */ + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_devmodel_started(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int ret) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm); + STATE_AO_GC(dmss->spawn.ao); + int i; + libxl_ctx *ctx = CTX; + int domid = dcs->guest_domid; + + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + const libxl_console_ready cb = dcs->console_cb; + void *const priv = dcs->console_cb_priv; + + if (ret) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "device model did not start: %d", ret); + goto error_out; + } - if (dm_starting) { + if (dcs->dmss.dm.guest_domid) { if (d_config->b_info.device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { libxl__qmp_initializations(gc, domid, d_config); } - 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); - goto error_out; - } } for (i = 0; i < d_config->num_pcidevs; i++) @@ -734,38 +795,95 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, 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 ))) { - if ( (*cb)(ctx, domid, priv) ) - goto error_out; + ret = (*cb)(ctx, domid, priv); + if (ret) goto error_out; } - *domid_out = domid; - return 0; + domcreate_complete(egc, dcs, 0); + return; error_out: - if (domid) - libxl_domain_destroy(ctx, domid); + assert(ret); + domcreate_complete(egc, dcs, ret); +} - return ret; +static void domcreate_complete(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc) +{ + STATE_AO_GC(dcs->ao); + + if (rc) { + if (dcs->guest_domid) { + int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid); + if (rc2) + LOG(ERROR, "unable to destroy domain %d following" + " failed creation", dcs->guest_domid); + } + dcs->guest_domid = -1; + } + dcs->callback(egc, dcs, rc, dcs->guest_domid); } +/*----- application-facing domain creation interface -----*/ + +typedef struct { + libxl__domain_create_state dcs; + uint32_t *domid_out; +} libxl__app_domain_create_state; + +static void domain_create_cb(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc, uint32_t domid); + +static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, + libxl_console_ready cb, void *priv, uint32_t *domid, + int restore_fd, const libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx, 0, ao_how); + libxl__app_domain_create_state *cdcs; + + GCNEW(cdcs); + cdcs->dcs.ao = ao; + cdcs->dcs.guest_config = d_config; + cdcs->dcs.restore_fd = restore_fd; + cdcs->dcs.console_cb = cb; + cdcs->dcs.console_cb_priv = priv; + cdcs->dcs.callback = domain_create_cb; + cdcs->domid_out = domid; + + initiate_domain_create(egc, &cdcs->dcs); + + return AO_INPROGRESS; +} + +static void domain_create_cb(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc, uint32_t domid) +{ + libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs); + STATE_AO_GC(cdcs->dcs.ao); + + if (!rc) + *cdcs->domid_out = domid; + + libxl__ao_complete(egc, ao, rc); +} + int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid) + libxl_console_ready cb, void *priv, + uint32_t *domid, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - int rc; - rc = do_domain_create(gc, d_config, cb, priv, domid, -1); - GC_FREE; - return rc; + return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how); } int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd) + libxl_console_ready cb, void *priv, + uint32_t *domid, int restore_fd, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - int rc; - rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd); - GC_FREE; - return rc; + return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how); } /* diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 725c3c0..4ad7d02 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -669,24 +669,28 @@ retry_transaction: return 0; } -static int libxl__create_stubdom(libxl__gc *gc, - int guest_domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *d_state, - libxl__spawner_starting **starting_r) +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc); + +void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { + STATE_AO_GC(sdss->dm.spawn.ao); libxl_ctx *ctx = libxl__gc_owner(gc); int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret; libxl__device_console *console; - libxl_domain_config dm_config[1]; libxl_device_vfb vfb; libxl_device_vkb vkb; - libxl__domain_build_state stubdom_state[1]; - uint32_t dm_domid; char **args; struct xs_permissions perm[2]; xs_transaction_t t; - libxl__spawner_starting *dm_starting = 0; + + /* convenience aliases */ + libxl_domain_config *const dm_config = &sdss->dm_config; + libxl_domain_config *const guest_config = sdss->dm.guest_config; + const int guest_domid = sdss->dm.guest_domid; + libxl__domain_build_state *const d_state = sdss->dm.build_state; + libxl__domain_build_state *const stubdom_state = &sdss->dm_state; if (guest_config->b_info.device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) { @@ -694,6 +698,8 @@ static int libxl__create_stubdom(libxl__gc *gc, goto out; } + sdss->pvqemu.guest_domid = 0; + libxl_domain_create_info_init(&dm_config->c_info); dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV; dm_config->c_info.name = libxl__sprintf(gc, "%s-dm", @@ -741,10 +747,10 @@ static int libxl__create_stubdom(libxl__gc *gc, dm_config->num_vkbs = 1; /* fixme: this function can leak the stubdom if it fails */ - dm_domid = 0; - ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid); + ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid); if (ret) goto out; + uint32_t dm_domid = sdss->pvqemu.guest_domid; ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state); if (ret) goto out; @@ -852,42 +858,67 @@ retry_transaction: goto out_free; } - if (libxl__create_xenpv_qemu(gc, dm_domid, - dm_config, - stubdom_state, - &dm_starting) < 0) { - ret = ERROR_FAIL; - goto out_free; - } - if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) { - ret = ERROR_FAIL; - goto out_free; - } - - libxl_domain_unpause(ctx, dm_domid); + sdss->pvqemu.guest_domid = dm_domid; + sdss->pvqemu.guest_config = &sdss->dm_config; + sdss->pvqemu.build_state = &sdss->dm_state; + sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb; - if (starting_r) { - *starting_r = calloc(1, sizeof(libxl__spawner_starting)); - (*starting_r)->domid = guest_domid; - (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid); - (*starting_r)->for_spawn = NULL; - } + libxl__spawn_local_dm(egc, &sdss->pvqemu); - ret = 0; + free(args); + return; out_free: free(args); out: - return ret; + assert(ret); + spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); } -int libxl__create_device_model(libxl__gc *gc, - int domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *state, - libxl__spawner_starting **starting_r) +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc) { - libxl_ctx *ctx = libxl__gc_owner(gc); + libxl__stub_dm_spawn_state *sdss = + CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); + STATE_AO_GC(sdss->dm.spawn.ao); + uint32_t dm_domid = sdss->pvqemu.guest_domid; + + if (rc) goto out; + + rc = libxl_domain_unpause(CTX, dm_domid); + if (rc) goto out; + + out: + if (rc) { + if (dm_domid) + libxl_domain_destroy(CTX, dm_domid); + } + sdss->callback(egc, &sdss->dm, rc); +} + +/* callbacks passed to libxl__spawn_spawn */ +static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, + const char *xsdata); +static void device_model_startup_failed(libxl__egc *egc, + libxl__spawn_state *spawn); + +/* our "next step" function, called from those callbacks and elsewhere */ +static void device_model_spawn_outcome(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc); + +void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss) +{ + /* convenience aliases */ + const int domid = dmss->guest_domid; + libxl__domain_build_state *const state = dmss->build_state; + libxl__spawn_state *const spawn = &dmss->spawn; + + STATE_AO_GC(dmss->spawn.ao); + + libxl_ctx *ctx = CTX; + libxl_domain_config *guest_config = dmss->guest_config; 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 = libxl__dm_vnc(guest_config); @@ -895,15 +926,13 @@ int libxl__create_device_model(libxl__gc *gc, int logfile_w, null; int rc; char **args, **arg; - libxl__spawner_starting buf_starting, *p; xs_transaction_t t; char *vm_path; char **pass_stuff; const char *dm; if (libxl_defbool_val(b_info->device_model_stubdomain)) { - rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r); - goto out; + abort(); } dm = libxl__domain_device_model(gc, b_info); @@ -947,25 +976,8 @@ int libxl__create_device_model(libxl__gc *gc, free(logfile); null = open("/dev/null", O_RDONLY); - if (starting_r) { - rc = ERROR_NOMEM; - *starting_r = calloc(1, sizeof(libxl__spawner_starting)); - if (!*starting_r) - goto out_close; - p = *starting_r; - p->for_spawn = calloc(1, sizeof(libxl__spawn_starting)); - } else { - p = &buf_starting; - p->for_spawn = NULL; - } - - 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; - goto out_close; - } + const char *dom_path = libxl__xs_get_dompath(gc, domid); + spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid"); if (vnc && vnc->passwd) { /* This xenstore key will only be used by qemu-xen-traditionnal. @@ -973,7 +985,7 @@ int libxl__create_device_model(libxl__gc *gc, retry_transaction: /* Find uuid and the write the vnc password to xenstore for qemu. */ t = xs_transaction_start(ctx->xsh); - vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path)); + vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path)); if (vm_path) { /* Now write the vncpassword into it. */ pass_stuff = libxl__calloc(gc, 3, sizeof(char *)); @@ -990,8 +1002,15 @@ retry_transaction: for (arg = args; *arg; arg++) LIBXL__LOG(CTX, XTL_DEBUG, " %s", *arg); - rc = libxl__spawn_spawn(gc, p->for_spawn, "device model", - libxl_spawner_record_pid, p); + spawn->what = GCSPRINTF("domain %d device model", domid); + spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid); + spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000; + spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path); + spawn->midproc_cb = libxl__spawn_record_pid; + spawn->confirm_cb = device_model_confirm; + spawn->failure_cb = device_model_startup_failed; + + rc = libxl__spawn_spawn(egc, spawn); if (rc < 0) goto out_close; if (!rc) { /* inner child */ @@ -1006,30 +1025,61 @@ out_close: close(logfile_w); free(args); out: - return rc; + if (rc) + device_model_spawn_outcome(egc, dmss, rc); +} + + +static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, + const char *xsdata) +{ + libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn); + STATE_AO_GC(spawn->ao); + + if (!xsdata) + return; + + if (strcmp(xsdata, "running")) + return; + + libxl__spawn_detach(gc, spawn); + + device_model_spawn_outcome(egc, dmss, 0); } +static void device_model_startup_failed(libxl__egc *egc, + libxl__spawn_state *spawn) +{ + libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn); + device_model_spawn_outcome(egc, dmss, ERROR_FAIL); +} -int libxl__confirm_device_model_startup(libxl__gc *gc, - libxl__domain_build_state *state, - libxl__spawner_starting *starting) +static void device_model_spawn_outcome(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc) { - char *path; - int domid = starting->domid; - int ret, ret2; - path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid); - ret = libxl__spawn_confirm_offspring_startup(gc, - LIBXL_DEVICE_MODEL_START_TIMEOUT, - "Device Model", path, "running", starting); + STATE_AO_GC(dmss->spawn.ao); + int ret2; + + if (rc) + LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc); + + libxl__domain_build_state *state = dmss->build_state; + 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", - state->saved_state); - /* Do not clobber spawn_confirm error code with unlink error code. */ - if (!ret) ret = ret2; + if (ret2) { + LOGE(ERROR, "%s: failed to remove device-model state %s", + dmss->spawn.what, state->saved_state); + rc = ERROR_FAIL; + goto out; + } } - return ret; + + rc = 0; + + out: + dmss->callback(egc, dmss, rc); } int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) @@ -1131,15 +1181,6 @@ out: return ret; } -int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *state, - libxl__spawner_starting **starting_r) -{ - libxl__create_device_model(gc, domid, guest_config, state, starting_r); - return 0; -} - /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index 2ee2154..882c048 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx, } } -void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild) +int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, + pid_t innerchild) { - libxl__spawner_starting *starting = for_spawn; - struct xs_handle *xsh; - char *path = NULL, *pid = NULL; - int len; - - if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0) - goto out; + struct xs_handle *xsh = NULL; + const char *pid = NULL; + int rc, xsok; - len = asprintf(&pid, "%d", innerchild); - if (len < 0) - goto out; + pid = GCSPRINTF("%d", innerchild); /* we mustn't use the parent's handle in the child */ xsh = xs_daemon_open(); + if (!xsh) { + LOGE(ERROR, "write %s = %s: xenstore reopen failed", + spawn->pidpath, pid); + rc = ERROR_FAIL; goto out; + } - xs_write(xsh, XBT_NULL, path, pid, len); + xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid)); + if (!xsok) { + LOGE(ERROR, + "write %s = %s: xenstore write failed", spawn->pidpath, pid); + rc = ERROR_FAIL; goto out; + } + + rc = 0; - xs_daemon_close(xsh); out: - free(path); - free(pid); + if (xsh) xs_daemon_close(xsh); + return rc ? SIGTERM : 0; } int libxl__wait_for_offspring(libxl__gc *gc, @@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc, tv.tv_sec = timeout; tv.tv_usec = 0; nfds = xs_fileno(xsh) + 1; - if (spawning && spawning->fd > xs_fileno(xsh)) - nfds = spawning->fd + 1; + assert(!spawning); while (rc > 0 || (!rc && tv.tv_sec > 0)) { - if ( spawning ) { - rc = libxl__spawn_check(gc, spawning); - if ( rc ) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "%s died during startup", what); - rc = -1; - goto err_died; - } - } p = xs_read(xsh, XBT_NULL, path, &len); if ( NULL == p ) goto again; @@ -218,8 +214,6 @@ again: free(p); FD_ZERO(&rfds); FD_SET(xs_fileno(xsh), &rfds); - if (spawning) - FD_SET(spawning->fd, &rfds); rc = select(nfds, &rfds, NULL, NULL, &tv); if (rc > 0) { if (FD_ISSET(xs_fileno(xsh), &rfds)) { @@ -229,207 +223,215 @@ again: else goto again; } - if (spawning && FD_ISSET(spawning->fd, &rfds)) { - unsigned char dummy; - if (read(spawning->fd, &dummy, sizeof(dummy)) != 1) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG, - "failed to read spawn status pipe"); - } } } LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what); -err_died: + xs_unwatch(xsh, path, path); xs_daemon_close(xsh); err: return -1; } -static int detach_offspring(libxl__gc *gc, - libxl__spawner_starting *starting) -{ - int rc; - rc = libxl__spawn_detach(gc, starting->for_spawn); - if (starting->for_spawn) - free(starting->for_spawn); - free(starting); - return rc; -} -int libxl__spawn_confirm_offspring_startup(libxl__gc *gc, - uint32_t timeout, char *what, - char *path, char *state, - libxl__spawner_starting *starting) -{ - int detach; - int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what, - path, state, - starting->for_spawn, NULL, NULL); - detach = detach_offspring(gc, starting); - return problem ? problem : detach; -} +/*----- spawn implementation -----*/ -static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag) -{ - int flags; +/* + * Full set of possible states of a libxl__spawn_state and its _detachable: + * + * ss-> ss-> ss-> | ssd-> ssd-> + * timeout xswatch ssd | mid ss + * - Undefined undef undef no | - - + * - Idle Idle Idle no | - - + * - Active Active Active yes | Active yes + * - Partial Active/Idle Active/Idle maybe | Active/Idle yes (if exists) + * - Detached - - - | Active no + * + * When in state Detached, the middle process has been sent a SIGKILL. + */ - flags = fcntl(fd, F_GETFL); - if (flags == -1) - return ERROR_FAIL; +/* Event callbacks. */ +static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw, + const char *watch_path, const char *event_path); +static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs); +static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw, + pid_t pid, int status); - flags |= flag; +/* Precondition: Partial. Results: Detached. */ +static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss); - if (fcntl(fd, F_SETFL, flags) == -1) - return ERROR_FAIL; +/* Precondition: Partial; caller has logged failure reason. + * Results: Caller notified of failure; + * after return, ss may be completely invalid as caller may reuse it */ +static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss); - return 0; +void libxl__spawn_init(libxl__spawn_state *ss) +{ + libxl__ev_time_init(&ss->timeout); + libxl__ev_xswatch_init(&ss->xswatch); + ss->ssd = 0; } -int libxl__spawn_spawn(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - const char *what, - void (*intermediate_hook)(void *for_spawn, - pid_t innerchild), - void *hook_data) +int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss) { - libxl_ctx *ctx = libxl__gc_owner(gc); - pid_t child, got; + STATE_AO_GC(ss->ao); + int r; + pid_t child; int status, rc; - pid_t intermediate; - int pipes[2]; - unsigned char dummy = 0; - - if (for_spawn) { - for_spawn->what = strdup(what); - if (!for_spawn->what) return ERROR_NOMEM; - - if (libxl_pipe(ctx, pipes) < 0) - goto err_parent; - if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 || - libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0) - goto err_parent_pipes; - } - intermediate = libxl_fork(ctx); - if (intermediate ==-1) - goto err_parent_pipes; + libxl__spawn_init(ss); + ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd)); + libxl__ev_child_init(&ss->ssd->mid); + + rc = libxl__ev_time_register_rel(gc, &ss->timeout, + spawn_timeout, ss->timeout_ms); + if (rc) goto out_err; - if (intermediate) { + rc = libxl__ev_xswatch_register(gc, &ss->xswatch, + spawn_watch_event, ss->xspath); + if (rc) goto out_err; + + pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death); + if (middle ==-1) { rc = ERROR_FAIL; goto out_err; } + + if (middle) { /* parent */ - if (for_spawn) { - for_spawn->intermediate = intermediate; - for_spawn->fd = pipes[0]; - close(pipes[1]); - } return 1; } - /* we are now the intermediate process */ - if (for_spawn) close(pipes[0]); + /* we are now the middle process */ child = fork(); if (child == -1) exit(255); if (!child) { - if (for_spawn) close(pipes[1]); return 0; /* caller runs child code */ } - intermediate_hook(hook_data, child); - - if (!for_spawn) _exit(0); /* just detach then */ - - got = waitpid(child, &status, 0); - assert(got == child); - - rc = (WIFEXITED(status) ? WEXITSTATUS(status) : - WIFSIGNALED(status) && WTERMSIG(status) < 127 - ? WTERMSIG(status)+128 : -1); - if (for_spawn) { - if (write(pipes[1], &dummy, sizeof(dummy)) != 1) - perror("libxl__spawn_spawn: unable to signal child exit to parent"); + int failsig = ss->midproc_cb(gc, ss, child); + if (failsig) { + kill(child, failsig); + _exit(127); } - _exit(rc); - err_parent_pipes: - if (for_spawn) { - close(pipes[0]); - close(pipes[1]); + for (;;) { + pid_t got = waitpid(child, &status, 0); + if (got == -1) { + assert(errno == EINTR); + continue; + } + assert(got == child); + break; } - err_parent: - if (for_spawn) free(for_spawn->what); + r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) : + WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 : + -1); + _exit(r); - return ERROR_FAIL; + out_err: + spawn_cleanup(gc, ss); + return rc; } -static void report_spawn_intermediate_status(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - int status) +static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss) { - if (!WIFEXITED(status)) { - libxl_ctx *ctx = libxl__gc_owner(gc); - char *intermediate_what; - /* intermediate process did the logging itself if it exited */ - if ( asprintf(&intermediate_what, - "%s intermediate process (startup monitor)", - for_spawn->what) < 0 ) - intermediate_what = "intermediate process (startup monitor)"; - libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what, - for_spawn->intermediate, status); + int r; + + libxl__ev_time_deregister(gc, &ss->timeout); + libxl__ev_xswatch_deregister(gc, &ss->xswatch); + + libxl__spawn_state_detachable *ssd = ss->ssd; + if (ssd) { + if (libxl__ev_child_inuse(&ssd->mid)) { + pid_t child = ssd->mid.pid; + r = kill(child, SIGKILL); + if (r && errno != ESRCH) + LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)", + ss->what, (unsigned long)child); + } + + /* disconnect the ss and ssd from each other */ + ssd->ss = 0; + ss->ssd = 0; } } -int libxl__spawn_detach(libxl__gc *gc, - libxl__spawn_starting *for_spawn) +static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss) { - libxl_ctx *ctx = libxl__gc_owner(gc); - int r, status; - pid_t got; - int rc = 0; + EGC_GC; + spawn_cleanup(gc, ss); + ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */ +} - if (!for_spawn) return 0; +static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs) +{ + /* Before event, was Active; is now Partial. */ + EGC_GC; + libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout); + LOG(ERROR, "%s: startup timed out", ss->what); + spawn_failed(egc, ss); /* must be last */ +} - if (for_spawn->intermediate) { - r = kill(for_spawn->intermediate, SIGKILL); - if (r) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "could not kill %s intermediate process [%ld]", - for_spawn->what, - (unsigned long)for_spawn->intermediate); - abort(); /* things are very wrong */ - } - got = waitpid(for_spawn->intermediate, &status, 0); - assert(got == for_spawn->intermediate); - if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) { - report_spawn_intermediate_status(gc, for_spawn, status); - rc = ERROR_FAIL; - } - for_spawn->intermediate = 0; +static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw, + const char *watch_path, const char *event_path) +{ + /* On entry, is Active. */ + EGC_GC; + libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch); + char *p = libxl__xs_read(gc, 0, ss->xspath); + if (!p && errno != ENOENT) { + LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath); + spawn_failed(egc, ss); /* must be last */ + return; } - - free(for_spawn->what); - for_spawn->what = 0; - - return rc; + ss->confirm_cb(egc, ss, p); /* must be last */ } -int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn) +static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw, + pid_t pid, int status) + /* Before event, was Active or Detached; + * is now Active or Detached except that ssd->mid is Idle */ { - pid_t got; - int status; - - if (!for_spawn) return 0; + EGC_GC; + libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid); + libxl__spawn_state *ss = ssd->ss; - assert(for_spawn->intermediate); - got = waitpid(for_spawn->intermediate, &status, WNOHANG); - if (!got) return 0; - - assert(got == for_spawn->intermediate); - report_spawn_intermediate_status(gc, for_spawn, status); + if (!WIFEXITED(status)) { + const char *what = + GCSPRINTF("%s intermediate process (startup monitor)", + ss ? ss->what : "(detached)"); + int loglevel = ss ? XTL_ERROR : XTL_WARN; + libxl_report_child_exitstatus(CTX, loglevel, what, pid, status); + } else if (ss) { /* otherwise it was supposed to be a daemon by now */ + if (!status) + LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0," + " when we were waiting for it to confirm startup", + ss->what, (unsigned long)pid); + else if (status <= 127) + LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d", + ss->what, (unsigned long)pid, status); + else if (status < 255) { + int sig = status - 128; + const char *str = strsignal(sig); + if (str) + LOG(ERROR, "%s [%ld]: died during startup due to fatal" + " signal %s", ss->what, (unsigned long)pid, str); + else + LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal" + " signal number %d", ss->what, (unsigned long)pid, sig); + } + ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */ + spawn_failed(egc, ss); /* must be last use of ss */ + } + free(ssd); +} - for_spawn->intermediate = 0; - return ERROR_FAIL; +void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss) +{ + spawn_cleanup(gc, ss); } /* diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6fb99f6..dc84881 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -847,75 +847,198 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int num); _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid); -/* xl_exec */ +/* + *----- spawn ----- + * + * Higher-level double-fork and separate detach eg as for device models + * + * Each libxl__spawn_state is in one of the conventional states + * Undefined, Idle, Active + */ - /* higher-level double-fork and separate detach eg as for device models */ +typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting; +/* this type is never defined, so no objects of this type exist + * fixme-ao This should go away completely. */ -typedef struct { - /* put this in your own status structure as returned to application */ - /* all fields are private to libxl_spawn_... */ - pid_t intermediate; - int fd; - char *what; /* malloc'd in spawn_spawn */ -} libxl__spawn_starting; +typedef struct libxl__spawn_state libxl__spawn_state; -typedef struct { - char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */ - const char *pid_path; /* only for libxl_spawner_record_pid */ - int domid; - libxl__spawn_starting *for_spawn; -} libxl__spawner_starting; +/* Clears out a spawn state; idempotent. */ +_hidden void libxl__spawn_init(libxl__spawn_state*); /* - * libxl__spawn_spawn - Create a new process - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * what: string describing the spawned process - * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid - * hook_data: data to pass to the hook function + * libxl__spawn_spawn - Create a new process which will become daemonic + * Forks twice, to allow the child to detach entirely from the parent. + * + * We call the two generated processes the "middle child" (result of + * the first fork) and the "inner child" (result of the second fork + * which takes place in the middle child). + * + * The inner child must soon exit or exec. It must also soon exit or + * notify the parent of its successful startup by writing to the + * xenstore path xspath. + * + * The user (in the parent) will be called back (confirm_cb) every + * time that xenstore path is modified. + * + * In both children, the ctx is not fully usable: gc and logging + * operations are OK, but operations on Xen and xenstore are not. + * (The restrictions are the same as those which apply to children + * made with libxl__ev_child_fork.) + * + * midproc_cb will be called in the middle child, with the pid of the + * inner child; this could for example record the pid. midproc_cb + * should be fast, and should return. It will be called (reentrantly) + * within libxl__spawn_init. + * + * failure_cb will be called in the parent on failure of the + * intermediate or final child; an error message will have been + * logged. + * + * confirm_cb and failure_cb will not be called reentrantly from + * within libxl__spawn_spawn. + * + * what: string describing the spawned process, used for logging * * Logs errors. A copy of "what" is taken. * Return values: - * < 0 error, for_spawn need not be detached - * +1 caller is the parent, must call detach on *for_spawn eventually + * < 0 error, *spawn is now Idle and need not be detached + * +1 caller is the parent, *spawn is Active and must eventually be detached * 0 caller is now the inner child, should probably call libxl__exec - * Caller, may pass 0 for for_spawn, in which case no need to detach. + * + * The spawn state must be Undefined or Idle on entry. */ -_hidden int libxl__spawn_spawn(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - const char *what, - void (*intermediate_hook)(void *for_spawn, pid_t innerchild), - void *hook_data); +_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn); /* - * libxl_spawner_record_pid - Record given pid in xenstore - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * innerchild: pid of the child + * libxl__spawn_detach - Detaches the daemonic child. + * + * Works by killing the intermediate process from spawn_spawn. + * After this function returns, failures of either child are no + * longer reported via failure_cb. + * + * If called before the inner child has been created, this may prevent + * it from running at all. Thus this should be called only when the + * inner child has notified that it is ready. Normally it will be + * called from within confirm_cb. * - * This function is passed as intermediate_hook to libxl__spawn_spawn. + * Logs errors. + * + * The spawn state must be Active or Idle on entry and will be Idle + * on return. */ -_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild); +_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*); /* - * libxl__spawn_confirm_offspring_startup - Wait for child state - * gc: allocation pool - * timeout: how many seconds to wait for the child - * what: string describing the spawned process - * path: path to the state file in xenstore - * state: expected string to wait for in path (optional) - * starting: malloc'd pointer to libxl__spawner_starting + * If successful, this should return 0. * - * Returns 0 on success, and < 0 on error. + * Otherwise it should return a signal number, which will be + * sent to the inner child; the overall spawn will then fail. + */ +typedef int /* signal number */ +libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner); + +/* + * Called if the spawn failed. The reason will have been logged. + * The spawn state will be Idle on entry to the callback (and + * it may be reused immediately if desired). + */ +typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*); + +/* + * Called when the xspath watch triggers. xspath will have been read + * and the result placed in xsdata; if that failed because the key + * didn't exist, xspath==0. (If it failed for some other reason, + * the spawn machinery calls failure_cb instead.) * - * This function waits the given timeout for the given path to appear - * in xenstore, and optionally for state in path. - * The intermediate process created in libxl__spawn_spawn is killed. - * The memory referenced by starting->for_spawn and starting is free'd. + * If the child has indicated its successful startup, or a failure + * has occurred, this should call libxl__spawn_detach. + * + * If the child is still starting up, should simply return, doing + * nothing. + * + * The spawn state will be Active on entry to the callback; there + * are no restrictions on the state on return; it may even have + * been detached and reused. */ -_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc, - uint32_t timeout, char *what, - char *path, char *state, - libxl__spawner_starting *starting); +typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*, + const char *xsdata); + +typedef struct { + /* Private to the spawn implementation. + */ + /* This separate struct, from malloc, allows us to "detach" + * the child and reap it later, when our user has gone + * away and freed its libxl__spawn_state */ + struct libxl__spawn_state *ss; + libxl__ev_child mid; +} libxl__spawn_state_detachable; + +struct libxl__spawn_state { + /* must be filled in by user and remain valid */ + libxl__ao *ao; + const char *what; + const char *xspath; + const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */ + int timeout_ms; /* -1 means forever */ + libxl__spawn_midproc_cb *midproc_cb; + libxl__spawn_failure_cb *failure_cb; + libxl__spawn_confirm_cb *confirm_cb; + + /* remaining fields are private to libxl_spawn_... */ + libxl__ev_time timeout; + libxl__ev_xswatch xswatch; + libxl__spawn_state_detachable *ssd; +}; + +static inline int libxl__spawn_inuse(libxl__spawn_state *ss) + { return !!ss->ssd; } + +/* + * libxl_spawner_record_pid - Record given pid in xenstore + * + * This function can be passed directly as an intermediate_hook to + * libxl__spawn_spawn. On failure, returns the value SIGTERM. + */ +_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*, + pid_t innerchild); + +/*----- device model creation -----*/ + +/* First layer; wraps libxl__spawn_spawn. */ + +typedef struct libxl__dm_spawn_state libxl__dm_spawn_state; + +typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*, + int rc /* if !0, error was logged */); + +struct libxl__dm_spawn_state { + /* mixed - spawn.ao must be initialised by user; rest is private: */ + libxl__spawn_state spawn; + /* filled in by user, must remain valid: */ + uint32_t guest_domid; /* domain being served */ + libxl_domain_config *guest_config; + libxl__domain_build_state *build_state; /* relates to guest_domid */ + libxl__dm_spawn_cb *callback; +}; + +_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*); + +/* Stubdom device models. */ + +typedef struct { + /* Mixed - user must fill in public parts EXCEPT callback, + * which may be undefined on entry. (See above for details) */ + libxl__dm_spawn_state dm; /* the stub domain device model */ + /* filled in by user, must remain valid: */ + libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */ + /* private to libxl__spawn_stub_dm: */ + libxl_domain_config dm_config; + libxl__domain_build_state dm_state; + libxl__dm_spawn_state pvqemu; +} libxl__stub_dm_spawn_state; + +_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*); + /* * libxl__wait_for_offspring - Wait for child state @@ -948,31 +1071,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc, void *userdata), void *check_callback_userdata); -/* - * libxl__spawn_detach - Kill intermediate process from spawn_spawn - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * - * Returns 0 on success, and < 0 on error. - * - * Logs errors. Idempotent, but only permitted after successful - * call to libxl__spawn_spawn, and no point calling it again if it fails. - */ -_hidden int libxl__spawn_detach(libxl__gc *gc, - libxl__spawn_starting *for_spawn); - -/* - * libxl__spawn_check - Check intermediate child process - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * - * Returns 0 on success, and < 0 on error. - * - * Logs errors but also returns them. - * Caller must still call detach. - */ -_hidden int libxl__spawn_check(libxl__gc *gc, - libxl__spawn_starting *for_spawn); /* low-level stuff, for synchronous subprocesses etc. */ @@ -991,15 +1089,6 @@ _hidden int libxl__domain_build(libxl__gc *gc, /* for device model creation */ _hidden const char *libxl__domain_device_model(libxl__gc *gc, const libxl_domain_build_info *info); -_hidden int libxl__create_device_model(libxl__gc *gc, - int domid, - libxl_domain_config *guest_config, - 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__domain_build_state *state, - libxl__spawner_starting **starting_r); _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, int nr_consoles, libxl__device_console *consoles, int nr_vfbs, libxl_device_vfb *vfbs, @@ -1007,10 +1096,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, /* Caller must either: pass starting_r==0, or on successful * 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__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, uint32_t domid, char *state, libxl__spawn_starting *spawning, @@ -1581,6 +1666,31 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); +/*----- Domain creation -----*/ + +typedef struct libxl__domain_create_state libxl__domain_create_state; + +typedef void libxl__domain_create_cb(libxl__egc *egc, + libxl__domain_create_state*, + int rc, uint32_t domid); + +struct libxl__domain_create_state { + /* filled in by user */ + libxl__ao *ao; + libxl_domain_config *guest_config; + int restore_fd; + libxl_console_ready console_cb; + void *console_cb_priv; + libxl__domain_create_cb *callback; + /* private to domain_create */ + int guest_domid; + libxl__domain_build_state build_state; + libxl__stub_dm_spawn_state dmss; + /* If we're not doing stubdom, we use only dmss.dm, + * for the non-stubdom device model. */ +}; + + /* * Convenience macros. */ diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 45e2c30..621aeaf 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1695,8 +1695,8 @@ start: if ( restore_file ) { ret = libxl_domain_create_restore(ctx, &d_config, - cb, &child_console_pid, - &domid, restore_fd); + cb, &child_console_pid, + &domid, restore_fd, 0); /* * On subsequent reboot etc we should create the domain, not * restore/migrate-receive it again. @@ -1704,7 +1704,7 @@ start: restore_file = NULL; }else{ ret = libxl_domain_create_new(ctx, &d_config, - cb, &child_console_pid, &domid); + cb, &child_console_pid, &domid, 0); } if ( ret ) goto error_out; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6e-0006Wi-7y; Fri, 11 May 2012 17:58:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W4-ED for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:3989] by server-12.bemta-5.messagelabs.com id 2F/F0-01344-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30093 invoked from network); 11 May 2012 17:58:16 -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 May 2012 17:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435459" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HW-GE; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000e0-EE; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:46 +0100 Message-ID: <1336759092-2432-2-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 01/27] libxl: handle POLLERR, POLLHUP, POLLNVAL properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Pass POLLERR and POLLHUP to fd callbacks, as is necessary. Crash on POLLNVAL since that means our fds are messed up. Document the behaviour (including the fact that poll sometimes sets POLLHUP or POLLERR even if only POLLIN was requested. Fix the one current fd callback to do something with POLLERR|POLLHUP. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_event.c | 7 ++++++- tools/libxl/libxl_internal.h | 5 +++++ 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index e11a4e7..5046938 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -339,6 +339,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev, { EGC_GC; + if (revents & (POLLERR|POLLHUP)) + LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0); + for (;;) { char **event = xs_check_watch(CTX->xsh); if (!event) { @@ -743,7 +746,9 @@ static int afterpoll_check_fd(libxl__poller *poller, /* again, stale slot entry */ return 0; - int revents = fds[slot].revents & events; + assert(!(fds[slot].revents & POLLNVAL)); + + int revents = fds[slot].revents & (events | POLLERR | POLLHUP); /* we mask in case requested events have changed */ return revents; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 8947ddd..74e640f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -128,6 +128,11 @@ _hidden void libxl__alloc_failed(libxl_ctx *, const char *func, 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); + /* Note that revents may contain POLLERR or POLLHUP regardless of + * events; otherwise revents contains only bits in events. Contrary + * to the documentation for poll(2), POLLERR and POLLHUP can occur + * even if only POLLIN was set in events. (POLLNVAL is a fatal + * error and will cause libxl event machinery to fail an assertion.) */ struct libxl__ev_fd { /* caller should include this in their own struct */ /* read-only for caller, who may read only when registered: */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6o-0006jN-GS; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006X7-F8 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42728] by server-2.bemta-4.messagelabs.com id F9/02-17550-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!7 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32070 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435484" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ie-3L; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gg-0Y; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:09 +0100 Message-ID: <1336759092-2432-25-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson , Stefano Stabellini Subject: [Xen-devel] [PATCH 24/27] libxl: convert console callback to libxl_asyncprogress_how X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove the old console callback. (Its reentrancy properties were troublesome: in principle, the event loop might be reentered during the callback, and the libxl__domain_create_state swept out from under the feet of the domain creation.) As a side effect of the new code arrangements, the console callback for non-bootloader-using PV guests now occurs near the end of domain creation, in the same place as for HVM guests, rather than near the start. The new arrangements should in principle mean that by the time the console is described as ready by the callback, the xenstore key is indeed ready. So in the future the timeout might be removed from the console client. Signed-off-by: Ian Jackson Cc: Stefano Stabellini Acked-by: Ian Campbell --- tools/libxl/libxl.h | 17 ++++++----- tools/libxl/libxl_bootloader.c | 3 ++ tools/libxl/libxl_create.c | 59 +++++++++++++++++++++++----------------- tools/libxl/libxl_internal.h | 6 +++- tools/libxl/libxl_types.idl | 2 + tools/libxl/xl_cmdimpl.c | 25 ++++++++++------- 6 files changed, 67 insertions(+), 45 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index ba0f4de..979940a 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -509,18 +509,19 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */); /* domain related functions */ -typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv); - /* fixme-ao Need to review this API. If we keep it, the reentrancy - * properties need to be documented but they may turn out to be too - * awkward */ int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - const libxl_asyncop_how *ao_how); + uint32_t *domid, + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how); 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, - const libxl_asyncop_how *ao_how); + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how); + /* A progress report will be made via ao_console_how, of type + * domain_create_console_available, when the domain's primary + * console is available and can be connected to. + */ void libxl_domain_config_init(libxl_domain_config *d_config); void libxl_domain_config_dispose(libxl_domain_config *d_config); diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 1534bae..8436c07 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -377,6 +377,9 @@ static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) goto out; } + if (bl->console_available) + bl->console_available(egc, bl); + int bootloader_master = libxl__carefd_fd(bl->ptys[0].master); int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 63cb430..14721eb 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -569,10 +569,15 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, static void domcreate_devmodel_started(libxl__egc *egc, libxl__dm_spawn_state *dmss, int rc); +static void domcreate_bootloader_console_available(libxl__egc *egc, + libxl__bootloader_state *bl); static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int rc); +static void domcreate_console_available(libxl__egc *egc, + libxl__domain_create_state *dcs); + /* Our own function to clean up and call the user's callback. * The final call in the sequence. */ static void domcreate_complete(libxl__egc *egc, @@ -590,8 +595,6 @@ static void initiate_domain_create(libxl__egc *egc, /* convenience aliases */ libxl_domain_config *const d_config = dcs->guest_config; const int restore_fd = dcs->restore_fd; - const libxl_console_ready cb = dcs->console_cb; - void *const priv = dcs->console_cb_priv; memset(&dcs->build_state, 0, sizeof(dcs->build_state)); domid = 0; @@ -610,11 +613,6 @@ static void initiate_domain_create(libxl__egc *egc, dcs->guest_domid = domid; dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */ - if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) { - ret = (*cb)(ctx, domid, priv); - if (ret) goto error_out; - } - ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info); if (ret) goto error_out; @@ -629,6 +627,7 @@ static void initiate_domain_create(libxl__egc *egc, if (restore_fd < 0 && bootdisk) { dcs->bl.callback = domcreate_bootloader_done; + dcs->bl.console_available = domcreate_bootloader_console_available; dcs->bl.info = &d_config->b_info, dcs->bl.disk = bootdisk; dcs->bl.domid = dcs->guest_domid; @@ -644,6 +643,21 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_bootloader_console_available(libxl__egc *egc, + libxl__bootloader_state *bl) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(bl, *dcs, bl); + STATE_AO_GC(bl->ao); + domcreate_console_available(egc, dcs); +} + +static void domcreate_console_available(libxl__egc *egc, + libxl__domain_create_state *dcs) { + libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how, + NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE, + dcs->guest_domid)); +} + static void domcreate_bootloader_done(libxl__egc *egc, libxl__bootloader_state *bl, int ret) @@ -779,8 +793,6 @@ static void domcreate_devmodel_started(libxl__egc *egc, /* convenience aliases */ libxl_domain_config *const d_config = dcs->guest_config; - const libxl_console_ready cb = dcs->console_cb; - void *const priv = dcs->console_cb_priv; if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, @@ -818,12 +830,7 @@ static void domcreate_devmodel_started(libxl__egc *egc, goto error_out; } } - 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 ))) { - ret = (*cb)(ctx, domid, priv); - if (ret) goto error_out; - } + domcreate_console_available(egc, dcs); domcreate_complete(egc, dcs, 0); return; @@ -863,8 +870,9 @@ static void domain_create_cb(libxl__egc *egc, int rc, uint32_t domid); static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - int restore_fd, const libxl_asyncop_how *ao_how) + uint32_t *domid, + int restore_fd, const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { AO_CREATE(ctx, 0, ao_how); libxl__app_domain_create_state *cdcs; @@ -873,9 +881,8 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, cdcs->dcs.ao = ao; cdcs->dcs.guest_config = d_config; cdcs->dcs.restore_fd = restore_fd; - cdcs->dcs.console_cb = cb; - cdcs->dcs.console_cb_priv = priv; cdcs->dcs.callback = domain_create_cb; + libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how); cdcs->domid_out = domid; initiate_domain_create(egc, &cdcs->dcs); @@ -897,19 +904,21 @@ static void domain_create_cb(libxl__egc *egc, } int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, - const libxl_asyncop_how *ao_how) + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { - return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how); + return do_domain_create(ctx, d_config, domid, -1, + ao_how, aop_console_how); } 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, - const libxl_asyncop_how *ao_how) + const libxl_asyncop_how *ao_how, + const libxl_asyncprogress_how *aop_console_how) { - return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how); + return do_domain_create(ctx, d_config, domid, restore_fd, + ao_how, aop_console_how); } /* diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index a407317..3aa0ed7 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1699,11 +1699,14 @@ int libxl__openptys(libxl__openpty_state *op, typedef struct libxl__bootloader_state libxl__bootloader_state; typedef void libxl__run_bootloader_callback(libxl__egc*, libxl__bootloader_state*, int rc); +typedef void libxl__bootloader_console_callback(libxl__egc*, + libxl__bootloader_state*); struct libxl__bootloader_state { /* caller must fill these in, and they must all remain valid */ libxl__ao *ao; libxl__run_bootloader_callback *callback; + libxl__bootloader_console_callback *console_available; libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */ libxl_device_disk *disk; uint32_t domid; @@ -1739,9 +1742,8 @@ struct libxl__domain_create_state { libxl__ao *ao; libxl_domain_config *guest_config; int restore_fd; - libxl_console_ready console_cb; - void *console_cb_priv; libxl__domain_create_cb *callback; + libxl_asyncprogress_how aop_console_how; /* private to domain_create */ int guest_domid; libxl__domain_build_state build_state; diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 68599cb..551e367 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -459,6 +459,7 @@ libxl_event_type = Enumeration("event_type", [ (2, "DOMAIN_DEATH"), (3, "DISK_EJECT"), (4, "OPERATION_COMPLETE"), + (5, "DOMAIN_CREATE_CONSOLE_AVAILABLE"), ]) libxl_ev_user = UInt(64) @@ -484,4 +485,5 @@ libxl_event = Struct("event",[ ("operation_complete", Struct(None, [ ("rc", integer), ])), + ("domain_create_console_available", Struct(None, [])), ]))]) diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 621aeaf..b91a2d5 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1457,16 +1457,18 @@ static int freemem(libxl_domain_build_info *b_info) return ERROR_NOMEM; } -static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv) +static void autoconnect_console(libxl_ctx *ctx, libxl_event *ev, void *priv) { pid_t *pid = priv; + libxl_event_free(ctx, ev); + *pid = fork(); if (*pid < 0) { perror("unable to fork xenconsole"); - return ERROR_FAIL; + return; } else if (*pid > 0) - return 0; + return; postfork(); @@ -1533,7 +1535,7 @@ static int create_domain(struct domain_create *dom_info) int config_len = 0; int restore_fd = -1; int status = 0; - libxl_console_ready cb; + const libxl_asyncprogress_how *autoconnect_console_how; pid_t child_console_pid = -1; struct save_file_header hdr; @@ -1687,24 +1689,27 @@ start: goto error_out; } + libxl_asyncprogress_how autoconnect_console_how_buf; if ( dom_info->console_autoconnect ) { - cb = autoconnect_console; + autoconnect_console_how_buf.callback = autoconnect_console; + autoconnect_console_how_buf.for_callback = &child_console_pid; + autoconnect_console_how = &autoconnect_console_how_buf; }else{ - cb = NULL; + autoconnect_console_how = 0; } if ( restore_file ) { ret = libxl_domain_create_restore(ctx, &d_config, - cb, &child_console_pid, - &domid, restore_fd, 0); + &domid, restore_fd, + 0, autoconnect_console_how); /* * On subsequent reboot etc we should create the domain, not * restore/migrate-receive it again. */ restore_file = NULL; }else{ - ret = libxl_domain_create_new(ctx, &d_config, - cb, &child_console_pid, &domid, 0); + ret = libxl_domain_create_new(ctx, &d_config, &domid, + 0, autoconnect_console_how); } if ( ret ) goto error_out; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6n-0006hO-F1; Fri, 11 May 2012 17:58:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wf-4B for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.139.83:16356] by server-3.bemta-5.messagelabs.com id 6E/4E-25237-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!13 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30238 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435483" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Il-70; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000go-5P; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:11 +0100 Message-ID: <1336759092-2432-27-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 26/27] libxl: child processes cleanups X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Abolish libxl_fork. Its only callers were in xl. Its functionality is now moved elsewhere, as follows: * The "logging version of fork", which is what it was billed as, is now xl_fork, which also dies on failure. * Closing the xenstore handle in the child is now done in libxl__ev_child_fork, which is the only remaining place where fork is called in libxl. * We provide a new function libxl__ev_child_xenstore_reopen for in-libxl children to make the ctx useable for xenstore again. * Consequently libxl__spawn_record_pid now no longer needs to mess about with its own xenstore handle. As a bonus it can now just use libxl__xs_write. Also, since we have now converted all the forkers in libxl, we can always honour the fork_replacement childproc hook - so do so. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_exec.c | 35 ++++++++++++++++------------------- tools/libxl/libxl_fork.c | 25 ++++++++++++++++++++++++- tools/libxl/libxl_internal.h | 5 +++++ tools/libxl/libxl_utils.c | 21 --------------------- tools/libxl/libxl_utils.h | 3 +-- tools/libxl/xl.c | 12 ++++++++++++ tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 5 ++--- 8 files changed, 61 insertions(+), 46 deletions(-) diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index 882c048..b46b893 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx, } } -int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, - pid_t innerchild) +int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid) { - struct xs_handle *xsh = NULL; - const char *pid = NULL; - int rc, xsok; + int r, rc; - pid = GCSPRINTF("%d", innerchild); + rc = libxl__ev_child_xenstore_reopen(gc, spawn->what); + if (rc) goto out; - /* we mustn't use the parent's handle in the child */ - xsh = xs_daemon_open(); - if (!xsh) { - LOGE(ERROR, "write %s = %s: xenstore reopen failed", - spawn->pidpath, pid); - rc = ERROR_FAIL; goto out; - } - - xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid)); - if (!xsok) { + r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid); + if (r) { LOGE(ERROR, - "write %s = %s: xenstore write failed", spawn->pidpath, pid); + "write %s = %d: xenstore write failed", spawn->pidpath, pid); rc = ERROR_FAIL; goto out; } rc = 0; out: - if (xsh) xs_daemon_close(xsh); return rc ? SIGTERM : 0; } @@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss) /* we are now the middle process */ - child = fork(); + pid_t (*fork_replacement)(void*) = + CTX->childproc_hooks + ? CTX->childproc_hooks->fork_replacement + : 0; + child = + fork_replacement + ? fork_replacement(CTX->childproc_user) + : fork(); + if (child == -1) exit(255); if (!child) { diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c index 35c8bdd..9ff99e0 100644 --- a/tools/libxl/libxl_fork.c +++ b/tools/libxl/libxl_fork.c @@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch, if (!pid) { /* woohoo! */ - return 0; /* Yes, CTX is left locked in the child. */ + if (CTX->xsh) { + xs_daemon_destroy_postfork(CTX->xsh); + CTX->xsh = NULL; /* turns mistakes into crashes */ + } + /* Yes, CTX is left locked in the child. */ + return 0; } ch->pid = pid; @@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = { libxl_sigchld_owner_libxl, 0, 0 }; +int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) { + int rc; + + assert(!CTX->xsh); + CTX->xsh = xs_daemon_open(); + if (!CTX->xsh) { + LOGE(ERROR, "%s: xenstore reopen failed", what); + rc = ERROR_FAIL; goto out; + } + + libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1); + + return 0; + + out: + return rc; +} + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9f3f759..83fabea 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -640,6 +640,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out) static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out) { return childw_out->pid >= 0; } +/* Useable (only) in the child to once more make the ctx useable for + * xenstore operations. logs failure in the form "what: ". */ +_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what); + /* * Other event-handling support provided by the libxl event core to diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index f0d94c6..858410e 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath) return rc; } -pid_t libxl_fork(libxl_ctx *ctx) -{ - pid_t pid; - - pid = fork(); - if (pid == -1) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed"); - return -1; - } - - if (!pid) { - if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh); - ctx->xsh = 0; - /* This ensures that anyone who forks but doesn't exec, - * and doesn't reinitialise the libxl_ctx, is OK. - * It also means they can safely call libxl_ctx_free. */ - } - - return pid; -} - int libxl_pipe(libxl_ctx *ctx, int pipes[2]) { if (pipe(pipes) < 0) { diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h index 2b47622..74beb52 100644 --- a/tools/libxl/libxl_utils.h +++ b/tools/libxl/libxl_utils.h @@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data, * logged using filename (which is only used for logging) and what * (which may be 0). */ -pid_t libxl_fork(libxl_ctx *ctx); int libxl_pipe(libxl_ctx *ctx, int pipes[2]); - /* Just like fork(2), pipe(2), but log errors. */ + /* Just like pipe(2), but log errors. */ void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level, const char *what, pid_t pid, int status); diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index a6ffd25..d4db1f8 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -105,6 +105,18 @@ void postfork(void) } } +pid_t xl_fork(libxl_ctx *ctx) { + pid_t pid; + + pid = fork(); + if (pid == -1) { + perror("fork failed"); + exit(-1); + } + + return pid; +} + int main(int argc, char **argv) { int opt = 0; diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index f0d0ec8..2b6714a 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s); extern libxl_ctx *ctx; extern xentoollog_logger_stdiostream *logger; +pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */ void postfork(void); /* global options */ diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index b91a2d5..efaf3de 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1736,7 +1736,7 @@ start: pid_t child1, got_child; int nullfd; - child1 = libxl_fork(ctx); + child1 = xl_fork(ctx); if (child1) { printf("Daemon running with PID %d\n", child1); @@ -2779,8 +2779,7 @@ static void migrate_domain(const char *domain_spec, const char *rune, MUST( libxl_pipe(ctx, sendpipe) ); MUST( libxl_pipe(ctx, recvpipe) ); - child = libxl_fork(ctx); - if (child==-1) exit(1); + child = xl_fork(ctx); if (!child) { dup2(sendpipe[0], 0); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6k-0006cG-0q; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wq-Af for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42659] by server-3.bemta-4.messagelabs.com id 5C/F4-05853-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32026 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435467" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Ht-3p; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fe-1u; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:54 +0100 Message-ID: <1336759092-2432-10-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 09/27] libxl: provide libxl__datacopier_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org General facility for ao operations to shovel data between fds. This will be used by the bootloader machinery. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes in v7: * assert that the ao is non-null on _init. --- tools/libxl/Makefile | 3 +- tools/libxl/libxl_aoutils.c | 189 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 40 +++++++++ 3 files changed, 231 insertions(+), 1 deletions(-) create mode 100644 tools/libxl/libxl_aoutils.c diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 1261d43..5d9227e 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -64,7 +64,8 @@ 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_internal.o libxl_utils.o libxl_uuid.o \ + libxl_json.o libxl_aoutils.o \ libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c new file mode 100644 index 0000000..4c60ad9 --- /dev/null +++ b/tools/libxl/libxl_aoutils.c @@ -0,0 +1,189 @@ +/* + * Copyright (C) 2010 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. + */ + +#include "libxl_osdeps.h" /* must come before any other headers */ + +#include "libxl_internal.h" + +/*----- data copier -----*/ + +void libxl__datacopier_init(libxl__datacopier_state *dc) +{ + assert(dc->ao); + libxl__ev_fd_init(&dc->toread); + libxl__ev_fd_init(&dc->towrite); + LIBXL_TAILQ_INIT(&dc->bufs); +} + +void libxl__datacopier_kill(libxl__datacopier_state *dc) +{ + STATE_AO_GC(dc->ao); + libxl__datacopier_buf *buf, *tbuf; + + libxl__ev_fd_deregister(gc, &dc->toread); + libxl__ev_fd_deregister(gc, &dc->towrite); + LIBXL_TAILQ_FOREACH_SAFE(buf, &dc->bufs, entry, tbuf) + free(buf); + LIBXL_TAILQ_INIT(&dc->bufs); +} + +static void datacopier_callback(libxl__egc *egc, libxl__datacopier_state *dc, + int onwrite, int errnoval) +{ + libxl__datacopier_kill(dc); + dc->callback(egc, dc, onwrite, errnoval); +} + +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents); + +static void datacopier_check_state(libxl__egc *egc, libxl__datacopier_state *dc) +{ + STATE_AO_GC(dc->ao); + int rc; + + if (dc->used) { + if (!libxl__ev_fd_isregistered(&dc->towrite)) { + rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable, + dc->writefd, POLLOUT); + if (rc) { + LOG(ERROR, "unable to establish write event on %s" + " during copy of %s", dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + } + } else if (!libxl__ev_fd_isregistered(&dc->toread)) { + /* we have had eof */ + datacopier_callback(egc, dc, 0, 0); + return; + } else { + /* nothing buffered, but still reading */ + libxl__ev_fd_deregister(gc, &dc->towrite); + } +} + +static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents) { + libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, toread); + STATE_AO_GC(dc->ao); + + if (revents & ~POLLIN) { + LOG(ERROR, "unexpected poll event 0x%x (should be POLLIN)" + " on %s during copy of %s", revents, dc->readwhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + assert(revents & POLLIN); + for (;;) { + while (dc->used >= dc->maxsz) { + libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(&dc->bufs); + dc->used -= rm->used; + assert(dc->used >= 0); + LIBXL_TAILQ_REMOVE(&dc->bufs, rm, entry); + free(rm); + } + + libxl__datacopier_buf *buf = + LIBXL_TAILQ_LAST(&dc->bufs, libxl__datacopier_bufs); + if (!buf || buf->used >= sizeof(buf->buf)) { + buf = malloc(sizeof(*buf)); + if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf)); + buf->used = 0; + LIBXL_TAILQ_INSERT_TAIL(&dc->bufs, buf, entry); + } + int r = read(ev->fd, + buf->buf + buf->used, + sizeof(buf->buf) - buf->used); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) break; + LOGE(ERROR, "error reading %s during copy of %s", + dc->readwhat, dc->copywhat); + datacopier_callback(egc, dc, 0, errno); + return; + } + if (r == 0) { + libxl__ev_fd_deregister(gc, &dc->toread); + break; + } + buf->used += r; + dc->used += r; + assert(buf->used <= sizeof(buf->buf)); + } + datacopier_check_state(egc, dc); +} + +static void datacopier_writable(libxl__egc *egc, libxl__ev_fd *ev, + int fd, short events, short revents) { + libxl__datacopier_state *dc = CONTAINER_OF(ev, *dc, towrite); + STATE_AO_GC(dc->ao); + + if (revents & ~POLLOUT) { + LOG(ERROR, "unexpected poll event 0x%x (should be POLLOUT)" + " on %s during copy of %s", revents, dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, -1, 0); + return; + } + assert(revents & POLLOUT); + for (;;) { + libxl__datacopier_buf *buf = LIBXL_TAILQ_FIRST(&dc->bufs); + if (!buf) + break; + if (!buf->used) { + LIBXL_TAILQ_REMOVE(&dc->bufs, buf, entry); + free(buf); + continue; + } + int r = write(ev->fd, buf->buf, buf->used); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) break; + LOGE(ERROR, "error writing to %s during copy of %s", + dc->writewhat, dc->copywhat); + datacopier_callback(egc, dc, 1, errno); + return; + } + assert(r > 0); + assert(r <= buf->used); + buf->used -= r; + dc->used -= r; + assert(dc->used >= 0); + memmove(buf->buf, buf->buf+r, buf->used); + } + datacopier_check_state(egc, dc); +} + +int libxl__datacopier_start(libxl__datacopier_state *dc) +{ + int rc; + STATE_AO_GC(dc->ao); + + libxl__datacopier_init(dc); + + rc = libxl__ev_fd_register(gc, &dc->toread, datacopier_readable, + dc->readfd, POLLIN); + if (rc) goto out; + + rc = libxl__ev_fd_register(gc, &dc->towrite, datacopier_writable, + dc->writefd, POLLOUT); + if (rc) goto out; + + return 0; + + out: + libxl__datacopier_kill(dc); + return rc; +} + diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index e25569c..be11fbd 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -840,6 +840,7 @@ _hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds, */ _hidden int libxl__try_phy_backend(mode_t st_mode); + /* from libxl_pci */ _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting); @@ -1473,6 +1474,45 @@ _hidden const char *libxl__xen_script_dir_path(void); _hidden const char *libxl__lock_dir_path(void); _hidden const char *libxl__run_dir_path(void); +/*----- datacopier: copies data from one fd to another -----*/ + +typedef struct libxl__datacopier_state libxl__datacopier_state; +typedef struct libxl__datacopier_buf libxl__datacopier_buf; + +/* onwrite==1 means failure happened when writing, logged, errnoval is valid + * onwrite==0 means failure happened when reading + * errnoval==0 means we got eof and all data was written + * errnoval!=0 means we had a read error, logged + * onwrite==-1 means some other internal failure, errnoval not valid, logged + * in all cases copier is killed before calling this callback */ +typedef void libxl__datacopier_callback(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); + +struct libxl__datacopier_buf { + /* private to datacopier */ + LIBXL_TAILQ_ENTRY(libxl__datacopier_buf) entry; + int used; + char buf[1000]; +}; + +struct libxl__datacopier_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + int readfd, writefd; + ssize_t maxsz; + const char *copywhat, *readwhat, *writewhat; /* for error msgs */ + libxl__datacopier_callback *callback; + /* remaining fields are private to datacopier */ + libxl__ev_fd toread, towrite; + ssize_t used; + LIBXL_TAILQ_HEAD(libxl__datacopier_bufs, libxl__datacopier_buf) bufs; +}; + +_hidden void libxl__datacopier_init(libxl__datacopier_state *dc); +_hidden void libxl__datacopier_kill(libxl__datacopier_state *dc); +_hidden int libxl__datacopier_start(libxl__datacopier_state *dc); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6j-0006bs-Lq; Fri, 11 May 2012 17:58:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006X7-9f for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:57415] by server-2.bemta-4.messagelabs.com id 97/02-17550-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!3 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32036 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435474" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IK-Jj; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gB-Hy; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:02 +0100 Message-ID: <1336759092-2432-18-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 17/27] libxl: change some structures to unit arrays X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org In the next patch these variables will turn into actual pointers. To clarify that patch, prepare the ground by changing these variables from "struct foo var" to "struct foo var[1]". This enables accesses to them and their members to be made as if they were pointers. No functional change. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_create.c | 18 +++++----- tools/libxl/libxl_dm.c | 84 ++++++++++++++++++++++---------------------- 2 files changed, 51 insertions(+), 51 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index f7732aa..b137288 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -564,7 +564,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, { libxl_ctx *ctx = libxl__gc_owner(gc); libxl__spawner_starting *dm_starting = 0; - libxl__domain_build_state state; + libxl__domain_build_state state[1]; uint32_t domid; int i, ret; @@ -606,12 +606,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } } - memset(&state, 0, sizeof(state)); + memset(state, 0, sizeof(*state)); if ( restore_fd >= 0 ) { - ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state); + ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state); } else { - ret = libxl__domain_build(gc, &d_config->b_info, domid, &state); + ret = libxl__domain_build(gc, &d_config->b_info, domid, state); } if (ret) { @@ -649,7 +649,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, ret = init_console_info(&console, 0); if ( ret ) goto error_out; - libxl__device_console_add(gc, domid, &console, &state); + libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); libxl_device_vkb_init(&vkb); @@ -657,7 +657,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl_device_vkb_dispose(&vkb); ret = libxl__create_device_model(gc, domid, d_config, - &state, &dm_starting); + state, &dm_starting); if (ret < 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to create device model: %d", ret); @@ -683,11 +683,11 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, d_config->num_vfbs, d_config->vfbs, d_config->num_disks, &d_config->disks[0]); - libxl__device_console_add(gc, domid, &console, &state); + libxl__device_console_add(gc, domid, &console, state); libxl__device_console_dispose(&console); if (need_qemu) { - libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting); + libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting); } break; } @@ -701,7 +701,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { libxl__qmp_initializations(gc, domid, d_config); } - ret = libxl__confirm_device_model_startup(gc, &state, 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 --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 36b0730..725c3c0 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -678,10 +678,10 @@ static int libxl__create_stubdom(libxl__gc *gc, 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_domain_config dm_config[1]; libxl_device_vfb vfb; libxl_device_vkb vkb; - libxl__domain_build_state stubdom_state; + libxl__domain_build_state stubdom_state[1]; uint32_t dm_domid; char **args; struct xs_permissions perm[2]; @@ -694,58 +694,58 @@ static int libxl__create_stubdom(libxl__gc *gc, goto out; } - libxl_domain_create_info_init(&dm_config.c_info); - dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV; - dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", + libxl_domain_create_info_init(&dm_config->c_info); + dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV; + dm_config->c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, guest_domid)); - dm_config.c_info.ssidref = guest_config->b_info.device_model_ssidref; + dm_config->c_info.ssidref = guest_config->b_info.device_model_ssidref; - libxl_uuid_generate(&dm_config.c_info.uuid); + libxl_uuid_generate(&dm_config->c_info.uuid); - libxl_domain_build_info_init(&dm_config.b_info); - libxl_domain_build_info_init_type(&dm_config.b_info, LIBXL_DOMAIN_TYPE_PV); + libxl_domain_build_info_init(&dm_config->b_info); + libxl_domain_build_info_init_type(&dm_config->b_info, LIBXL_DOMAIN_TYPE_PV); - dm_config.b_info.max_vcpus = 1; - dm_config.b_info.max_memkb = 32 * 1024; - dm_config.b_info.target_memkb = dm_config.b_info.max_memkb; + 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.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz", + dm_config->b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path()); - dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid); - dm_config.b_info.u.pv.ramdisk.path = ""; - dm_config.b_info.u.pv.features = ""; + 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 = ""; - dm_config.b_info.device_model_version = + dm_config->b_info.device_model_version = guest_config->b_info.device_model_version; - dm_config.b_info.device_model = + 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->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; + 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; + dm_config->vifs = guest_config->vifs; + dm_config->num_vifs = guest_config->num_vifs; - ret = libxl__domain_create_info_setdefault(gc, &dm_config.c_info); + ret = libxl__domain_create_info_setdefault(gc, &dm_config->c_info); if (ret) goto out; - ret = libxl__domain_build_info_setdefault(gc, &dm_config.b_info); + ret = libxl__domain_build_info_setdefault(gc, &dm_config->b_info); if (ret) goto out; libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb); - dm_config.vfbs = &vfb; - dm_config.num_vfbs = 1; - dm_config.vkbs = &vkb; - dm_config.num_vkbs = 1; + 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 */ dm_domid = 0; - ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid); + ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid); if (ret) goto out; - ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state); + ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state); if (ret) goto out; @@ -790,20 +790,20 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - for (i = 0; i < dm_config.num_disks; i++) { - ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]); + for (i = 0; i < dm_config->num_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, dm_domid, &dm_config.vifs[i]); + for (i = 0; i < dm_config->num_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, dm_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, dm_domid, &dm_config.vkbs[0]); + ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config->vkbs[0]); if (ret) goto out_free; @@ -847,14 +847,14 @@ retry_transaction: break; } ret = libxl__device_console_add(gc, dm_domid, &console[i], - i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL); + i == STUBDOM_CONSOLE_LOGGING ? stubdom_state : NULL); if (ret) goto out_free; } if (libxl__create_xenpv_qemu(gc, dm_domid, - &dm_config, - &stubdom_state, + dm_config, + stubdom_state, &dm_starting) < 0) { ret = ERROR_FAIL; goto out_free; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6e-0006Wi-7y; Fri, 11 May 2012 17:58:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W4-ED for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:3989] by server-12.bemta-5.messagelabs.com id 2F/F0-01344-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30093 invoked from network); 11 May 2012 17:58:16 -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 May 2012 17:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435459" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HW-GE; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000e0-EE; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:46 +0100 Message-ID: <1336759092-2432-2-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 01/27] libxl: handle POLLERR, POLLHUP, POLLNVAL properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Pass POLLERR and POLLHUP to fd callbacks, as is necessary. Crash on POLLNVAL since that means our fds are messed up. Document the behaviour (including the fact that poll sometimes sets POLLHUP or POLLERR even if only POLLIN was requested. Fix the one current fd callback to do something with POLLERR|POLLHUP. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_event.c | 7 ++++++- tools/libxl/libxl_internal.h | 5 +++++ 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index e11a4e7..5046938 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -339,6 +339,9 @@ static void watchfd_callback(libxl__egc *egc, libxl__ev_fd *ev, { EGC_GC; + if (revents & (POLLERR|POLLHUP)) + LIBXL__EVENT_DISASTER(egc, "unexpected poll event on watch fd", 0, 0); + for (;;) { char **event = xs_check_watch(CTX->xsh); if (!event) { @@ -743,7 +746,9 @@ static int afterpoll_check_fd(libxl__poller *poller, /* again, stale slot entry */ return 0; - int revents = fds[slot].revents & events; + assert(!(fds[slot].revents & POLLNVAL)); + + int revents = fds[slot].revents & (events | POLLERR | POLLHUP); /* we mask in case requested events have changed */ return revents; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 8947ddd..74e640f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -128,6 +128,11 @@ _hidden void libxl__alloc_failed(libxl_ctx *, const char *func, 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); + /* Note that revents may contain POLLERR or POLLHUP regardless of + * events; otherwise revents contains only bits in events. Contrary + * to the documentation for poll(2), POLLERR and POLLHUP can occur + * even if only POLLIN was set in events. (POLLNVAL is a fatal + * error and will cause libxl event machinery to fail an assertion.) */ struct libxl__ev_fd { /* caller should include this in their own struct */ /* read-only for caller, who may read only when registered: */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006XH-03; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6d-0006WB-5Y for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:19 +0000 Received: from [85.158.139.83:16205] by server-9.bemta-5.messagelabs.com id A4/FD-09826-A335DAF4; Fri, 11 May 2012 17:58:18 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30124 invoked from network); 11 May 2012 17:58:17 -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 May 2012 17:58:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435461" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hc-MG; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eE-He; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:48 +0100 Message-ID: <1336759092-2432-4-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 03/27] libxl: event API: new facilities for waiting for subprocesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The current arrangements in libxl for spawning subprocesses have two key problems: (i) they make unwarranted (and largely undocumented) assumptions about the caller's use of subprocesses, (ii) they aren't integrated into the event system and can't be made asynchronous etc. So replace them with a new set of facilities. Primarily, from the point of view of code inside libxl, this is libxl__ev_child_fork which is both (a) a version of fork() and (b) an event source which generates a callback when the child dies. >From the point of view of the application, we fully document our use of SIGCHLD. The application can tell us whether it wants to own SIGCHLD or not; if it does, it has to tell us about deaths of our children. Currently there are no callers in libxl which use these facilities. All code in libxl which forks needs to be converted and libxl_fork needse to be be abolished. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl.c | 17 +++- tools/libxl/libxl.h | 1 + tools/libxl/libxl_event.c | 53 +++++++-- tools/libxl/libxl_event.h | 147 +++++++++++++++++++++++- tools/libxl/libxl_fork.c | 255 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 62 ++++++++++- 6 files changed, 515 insertions(+), 20 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index c420e19..939cc02 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, memset(ctx, 0, sizeof(libxl_ctx)); ctx->lg = lg; - /* First initialise pointers (cannot fail) */ + /* First initialise pointers etc. (cannot fail) */ LIBXL_TAILQ_INIT(&ctx->occurred); @@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, LIBXL_TAILQ_INIT(&ctx->death_list); libxl__ev_xswatch_init(&ctx->death_watch); + ctx->childproc_hooks = &libxl__childproc_default_hooks; + ctx->childproc_user = 0; + + ctx->sigchld_selfpipe[0] = -1; + /* The mutex is special because we can't idempotently destroy it */ if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) { @@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx) discard_events(&ctx->occurred); + /* If we have outstanding children, then the application inherits + * them; we wish the application good luck with understanding + * this if and when it reaps them. */ + libxl__sigchld_removehandler(ctx); + + if (ctx->sigchld_selfpipe[0] >= 0) { + close(ctx->sigchld_selfpipe[0]); + close(ctx->sigchld_selfpipe[1]); + } + pthread_mutex_destroy(&ctx->lock); GC_FREE; diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d59f0ee..fb90aed 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -380,6 +380,7 @@ enum { ERROR_NOT_READY = -11, ERROR_OSEVENT_REG_FAIL = -12, ERROR_BUFFERFULL = -13, + ERROR_UNKNOWN_CHILD = -14, }; diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 93c1d1f..3e784f0 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -627,6 +627,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, \ REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY); \ \ + int selfpipe = libxl__fork_selfpipe_active(CTX); \ + if (selfpipe >= 0) \ + REQUIRE_FD(selfpipe, POLLIN, BODY); \ + \ }while(0) #define REQUIRE_FD(req_fd_, req_events_, BODY) do{ \ @@ -766,10 +770,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller, int nfds, const struct pollfd *fds, struct timeval now) { + /* May make callbacks into the application for child processes. + * ctx must be locked exactly once */ EGC_GC; libxl__ev_fd *efd; - LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) { if (!efd->events) continue; @@ -780,11 +785,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller, } if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) { - char buf[256]; - int r = read(poller->wakeup_pipe[0], buf, sizeof(buf)); - if (r < 0) - if (errno != EINTR && errno != EWOULDBLOCK) - LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0); + int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]); + if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0); + } + + int selfpipe = libxl__fork_selfpipe_active(CTX); + if (selfpipe >= 0 && + afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) { + int e = libxl__self_pipe_eatall(selfpipe); + if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0); + libxl__fork_selfpipe_woken(egc); } for (;;) { @@ -1082,16 +1092,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p) void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p) { + int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]); + if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0); +} + +int libxl__self_pipe_wakeup(int fd) +{ static const char buf[1] = ""; for (;;) { - int r = write(p->wakeup_pipe[1], buf, 1); - if (r==1) return; + int r = write(fd, buf, 1); + if (r==1) return 0; assert(r==-1); if (errno == EINTR) continue; - if (errno == EWOULDBLOCK) return; - LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0); - return; + if (errno == EWOULDBLOCK) return 0; + assert(errno); + return errno; + } +} + +int libxl__self_pipe_eatall(int fd) +{ + char buf[256]; + for (;;) { + int r = read(fd, buf, sizeof(buf)); + if (r == sizeof(buf)) continue; + if (r >= 0) return 0; + assert(r == -1); + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) return 0; + assert(errno); + return errno; } } diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h index 2d2196f..713d96d 100644 --- a/tools/libxl/libxl_event.h +++ b/tools/libxl/libxl_event.h @@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx, * After libxl_ctx_free, all corresponding evgen handles become * invalid and must no longer be passed to evdisable. * - * Events enabled with evenable prior to a fork and libxl_ctx_postfork - * are no longer generated after the fork/postfork; however the evgen - * structures are still valid and must be passed to evdisable if the - * memory they use should not be leaked. - * * Applications should ensure that they eventually retrieve every * event using libxl_event_check or libxl_event_wait, since events * which occur but are not retreived by the application will be queued @@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl, void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl); +/*======================================================================*/ + +/* + * Subprocess handling. + * + * Unfortunately the POSIX interface makes this very awkward. + * + * There are two possible arrangements for collecting statuses from + * wait/waitpid. + * + * For naive programs: + * + * libxl will keep a SIGCHLD handler installed whenever it has an + * active (unreaped) child. It will reap all children with + * wait(); any children it does not recognise will be passed to + * the application via an optional callback (and will result in + * logged warnings if no callback is provided or the callback + * denies responsibility for the child). + * + * libxl may have children whenever: + * + * - libxl is performing an operation which can be made + * asynchronous; ie one taking a libxl_asyncop_how, even + * if NULL is passed indicating that the operation is + * synchronous; or + * + * - events of any kind are being generated, as requested + * by libxl_evenable_.... + * + * A multithreaded application which is naive in this sense may + * block SIGCHLD on some of its threads, but there must be at + * least one thread that has SIGCHLD unblocked. libxl will not + * modify the blocking flag for SIGCHLD (except that it may create + * internal service threads with all signals blocked). + * + * A naive program must only have at any one time only + * one libxl context which might have children. + * + * For programs which run their own children alongside libxl's: + * + * A program which does this must call libxl_childproc_setmode. + * There are two options: + * + * libxl_sigchld_owner_mainloop: + * 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. + * + * libxl_sigchld_owner_libxl_always: + * The application expects libxl to reap all of its children, + * and provides a callback to be notified of their exit + * statues. + * + * An application which fails to call setmode, or which passes 0 for + * hooks, while it uses any libxl operation which might + * create or use child processes (see above): + * - Must not have any child processes running. + * - Must not install a SIGCHLD handler. + * - Must not reap any children. + */ + + +typedef enum { + /* libxl owns SIGCHLD whenever it has a child. */ + libxl_sigchld_owner_libxl, + + /* Application promises to call libxl_childproc_exited but NOT + * from within a signal handler. libxl will not itself arrange to + * (un)block or catch SIGCHLD. */ + libxl_sigchld_owner_mainloop, + + /* libxl owns SIGCHLD all the time, and the application is + * relying on libxl's event loop for reaping its own children. */ + libxl_sigchld_owner_libxl_always, +} libxl_sigchld_owner; + +typedef struct { + libxl_sigchld_owner chldowner; + + /* All of these are optional: */ + + /* Called by libxl instead of fork. Should behave exactly like + * fork, including setting errno etc. May NOT reenter into libxl. + * Application may use this to discover pids of libxl's children, + * for example. + */ + pid_t (*fork_replacement)(void *user); + + /* With libxl_sigchld_owner_libxl, called by libxl when it has + * reaped a pid. (Not permitted with _owner_mainloop.) + * + * Should return 0 if the child was recognised by the application + * (or if the application does not keep those kind of records), + * ERROR_UNKNOWN_CHILD if the application knows that the child is not + * the application's; if it returns another error code it is a + * disaster as described for libxl_event_register_callbacks. + * (libxl will report unexpected children to its error log.) + * + * If not supplied, the application is assumed not to start + * any children of its own. + * + * This function is NOT called from within the signal handler. + * Rather it will be called from inside a libxl's event handling + * code and thus only when libxl is running, for example from + * within libxl_event_wait. (libxl uses the self-pipe trick + * to implement this.) + * + * childproc_exited_callback may call back into libxl, but it + * is best to avoid making long-running libxl calls as that might + * stall the calling event loop while the nested operation + * completes. + */ + int (*reaped_callback)(pid_t, int status, void *user); +} libxl_childproc_hooks; + +/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 } + * + * May not be called when libxl might have any child processes, or the + * behaviour is undefined. So it is best to call this at + * initialisation. + */ +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks, + void *user); + +/* + * This function is for an application which owns SIGCHLD and which + * therefore reaps all of the process's children. + * + * May be called only by an application which has called setmode with + * chldowner == libxl_sigchld_owner_mainloop. If pid was a process started + * by this instance of libxl, returns 0 after doing whatever + * processing is appropriate. Otherwise silently returns + * ERROR_UNKNOWN_CHILD. No other error returns are possible. + * + * May NOT be called from within a signal handler which might + * interrupt any libxl operation. The application will almost + * certainly need to use the self-pipe trick (or a working pselect or + * ppoll) to implement this. + */ +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status); + + /* * An application which initialises a libxl_ctx in a parent process * and then forks a child which does not quickly exec, must diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c index dce88ad..35c8bdd 100644 --- a/tools/libxl/libxl_fork.c +++ b/tools/libxl/libxl_fork.c @@ -46,6 +46,12 @@ static int atfork_registered; static LIBXL_LIST_HEAD(, libxl__carefd) carefds = LIBXL_LIST_HEAD_INITIALIZER(carefds); +/* non-null iff installed, protected by no_forking */ +static libxl_ctx *sigchld_owner; +static struct sigaction sigchld_saved_action; + +static void sigchld_removehandler_core(void); + static void atfork_lock(void) { int r = pthread_mutex_lock(&no_forking); @@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx) int r; atfork_lock(); + LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) { if (cf->fd >= 0) { r = close(cf->fd); @@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx) free(cf); } LIBXL_LIST_INIT(&carefds); + + if (sigchld_owner) + sigchld_removehandler_core(); + atfork_unlock(); } @@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf) } /* + * Actual child process handling + */ + +static void sigchld_handler(int signo) +{ + int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]); + assert(!e); /* errors are probably EBADF, very bad */ +} + +static void sigchld_removehandler_core(void) +{ + struct sigaction was; + int r; + + r = sigaction(SIGCHLD, &sigchld_saved_action, &was); + assert(!r); + assert(!(was.sa_flags & SA_SIGINFO)); + assert(was.sa_handler == sigchld_handler); + sigchld_owner = 0; +} + +void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */ +{ + atfork_lock(); + if (sigchld_owner == ctx) + sigchld_removehandler_core(); + atfork_unlock(); +} + +int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */ +{ + int r, rc; + + if (ctx->sigchld_selfpipe[0] < 0) { + r = pipe(ctx->sigchld_selfpipe); + if (r) { + ctx->sigchld_selfpipe[0] = -1; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "failed to create sigchld pipe"); + rc = ERROR_FAIL; + goto out; + } + } + + atfork_lock(); + if (sigchld_owner != ctx) { + struct sigaction ours; + + assert(!sigchld_owner); + sigchld_owner = ctx; + + memset(&ours,0,sizeof(ours)); + ours.sa_handler = sigchld_handler; + sigemptyset(&ours.sa_mask); + ours.sa_flags = SA_NOCLDSTOP | SA_RESTART; + r = sigaction(SIGCHLD, &ours, &sigchld_saved_action); + assert(!r); + + assert(((void)"application must negotiate with libxl about SIGCHLD", + !(sigchld_saved_action.sa_flags & SA_SIGINFO) && + (sigchld_saved_action.sa_handler == SIG_DFL || + sigchld_saved_action.sa_handler == SIG_IGN))); + } + atfork_unlock(); + + rc = 0; + out: + return rc; +} + +static int chldmode_ours(libxl_ctx *ctx) +{ + return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl; +} + +int libxl__fork_selfpipe_active(libxl_ctx *ctx) +{ + /* Returns the fd to read, or -1 */ + if (!chldmode_ours(ctx)) + return -1; + + if (LIBXL_LIST_EMPTY(&ctx->children)) + return -1; + + return ctx->sigchld_selfpipe[0]; +} + +static void perhaps_removehandler(libxl_ctx *ctx) +{ + if (LIBXL_LIST_EMPTY(&ctx->children) && + ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always) + libxl__sigchld_removehandler(ctx); +} + +static int childproc_reaped(libxl__egc *egc, pid_t pid, int status) +{ + EGC_GC; + libxl__ev_child *ch; + + LIBXL_LIST_FOREACH(ch, &CTX->children, entry) + if (ch->pid == pid) + goto found; + + /* not found */ + return ERROR_UNKNOWN_CHILD; + + found: + LIBXL_LIST_REMOVE(ch, entry); + ch->pid = -1; + ch->callback(egc, ch, pid, status); + + perhaps_removehandler(CTX); + + return 0; +} + +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status) +{ + EGC_INIT(ctx); + CTX_LOCK; + int rc = childproc_reaped(egc, pid, status); + CTX_UNLOCK; + EGC_FREE; + return rc; +} + +void libxl__fork_selfpipe_woken(libxl__egc *egc) +{ + /* May make callbacks into the application for child processes. + * ctx must be locked EXACTLY ONCE */ + EGC_GC; + + while (chldmode_ours(CTX) /* in case the app changes the mode */) { + int status; + pid_t pid = waitpid(-1, &status, WNOHANG); + + if (pid == 0) return; + + if (pid == -1) { + if (errno == ECHILD) return; + if (errno == EINTR) continue; + LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0); + return; + } + + int rc = childproc_reaped(egc, pid, status); + + if (rc) { + if (CTX->childproc_hooks->reaped_callback) { + CTX_UNLOCK; + rc = CTX->childproc_hooks->reaped_callback + (pid, status, CTX->childproc_user); + CTX_LOCK; + if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) { + char disasterbuf[200]; + snprintf(disasterbuf, sizeof(disasterbuf), " reported by" + " libxl_childproc_hooks->reaped_callback" + " (for pid=%lu, status=%d; error code %d)", + (unsigned long)pid, status, rc); + LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0); + return; + } + } else { + rc = ERROR_UNKNOWN_CHILD; + } + if (rc) + libxl_report_child_exitstatus(CTX, XTL_WARN, + "unknown child", (long)pid, status); + } + } +} + +pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch, + libxl__ev_child_callback *death) +{ + CTX_LOCK; + int rc; + + if (chldmode_ours(CTX)) { + rc = libxl__sigchld_installhandler(CTX); + if (rc) goto out; + } + + pid_t pid = + CTX->childproc_hooks->fork_replacement + ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user) + : fork(); + if (pid == -1) { + LOGE(ERROR, "fork failed"); + rc = ERROR_FAIL; + goto out; + } + + if (!pid) { + /* woohoo! */ + return 0; /* Yes, CTX is left locked in the child. */ + } + + ch->pid = pid; + ch->callback = death; + LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry); + rc = pid; + + out: + perhaps_removehandler(CTX); + CTX_UNLOCK; + return rc; +} + +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks, + void *user) +{ + GC_INIT(ctx); + CTX_LOCK; + + assert(LIBXL_LIST_EMPTY(&CTX->children)); + + if (!hooks) + hooks = &libxl__childproc_default_hooks; + + ctx->childproc_hooks = hooks; + ctx->childproc_user = user; + + switch (ctx->childproc_hooks->chldowner) { + case libxl_sigchld_owner_mainloop: + case libxl_sigchld_owner_libxl: + libxl__sigchld_removehandler(ctx); + break; + case libxl_sigchld_owner_libxl_always: + libxl__sigchld_installhandler(ctx); + break; + default: + abort(); + } + + CTX_UNLOCK; + GC_FREE; +} + +const libxl_childproc_hooks libxl__childproc_default_hooks = { + libxl_sigchld_owner_libxl, 0, 0 +}; + +/* * Local variables: * mode: C * c-basic-offset: 4 diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 01c9ba9..d04e856 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -198,6 +198,19 @@ _hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum); +typedef struct libxl__ev_child libxl__ev_child; +typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*, + pid_t pid, int status); +struct libxl__ev_child { + /* caller should include this in their own struct */ + /* read-only for caller: */ + pid_t pid; /* -1 means unused ("unregistered", ie Idle) */ + libxl__ev_child_callback *callback; + /* remainder is private for libxl__ev_... */ + LIBXL_LIST_ENTRY(struct libxl__ev_child) entry; +}; + + /* * evgen structures, which are the state we use for generating * events for the caller. @@ -306,10 +319,14 @@ struct libxl__ctx { LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens; - /* for callers who reap children willy-nilly; caller must only - * set this after libxl_init and before any other call - or - * may leave them untouched */ + const libxl_childproc_hooks *childproc_hooks; + void *childproc_user; + int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */ + LIBXL_LIST_HEAD(, libxl__ev_child) children; + + /* This is obsolete and must be removed: */ int (*waitpid_instead)(pid_t pid, int *status, int flags); + libxl_version_info version_info; }; @@ -557,6 +574,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw) /* + * For making subprocesses. This is the only permitted mechanism for + * code in libxl to do so. + * + * In the parent, returns the pid, filling in childw_out. + * In the child, returns 0. + * If it fails, returns a libxl error (all of which are -ve). + * + * The child should go on to exec (or exit) soon. The child may not + * make any further calls to libxl infrastructure, except for memory + * allocation and logging. If the child needs to use xenstore it + * must open its own xs handle and use it directly, rather than via + * the libxl event machinery. + * + * The parent may signal the child but it must not reap it. That will + * be done by the event machinery. death may be NULL in which case + * the child is still reaped but its death is ignored. + * + * It is not possible to "deregister" the child death event source. + * It will generate exactly one event callback; until then the childw + * is Active and may not be reused. + */ +_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out, + libxl__ev_child_callback *death); +static inline void libxl__ev_child_init(libxl__ev_child *childw_out) + { childw_out->pid = -1; } +static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out) + { return childw_out->pid >= 0; } + + +/* * Other event-handling support provided by the libxl event core to * the rest of libxl. */ @@ -610,6 +657,15 @@ _hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p); * ctx must be locked. */ _hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p); +/* Internal to fork and child reaping machinery */ +extern const libxl_childproc_hooks libxl__childproc_default_hooks; +int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */ +void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */ +int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */ +void libxl__fork_selfpipe_woken(libxl__egc *egc); +int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */ +int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */ + _hidden int libxl__atfork_init(libxl_ctx *ctx); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6n-0006hO-F1; Fri, 11 May 2012 17:58:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wf-4B for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.139.83:16356] by server-3.bemta-5.messagelabs.com id 6E/4E-25237-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!13 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30238 invoked from network); 11 May 2012 17:58: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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435483" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Il-70; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000go-5P; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:11 +0100 Message-ID: <1336759092-2432-27-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 26/27] libxl: child processes cleanups X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Abolish libxl_fork. Its only callers were in xl. Its functionality is now moved elsewhere, as follows: * The "logging version of fork", which is what it was billed as, is now xl_fork, which also dies on failure. * Closing the xenstore handle in the child is now done in libxl__ev_child_fork, which is the only remaining place where fork is called in libxl. * We provide a new function libxl__ev_child_xenstore_reopen for in-libxl children to make the ctx useable for xenstore again. * Consequently libxl__spawn_record_pid now no longer needs to mess about with its own xenstore handle. As a bonus it can now just use libxl__xs_write. Also, since we have now converted all the forkers in libxl, we can always honour the fork_replacement childproc hook - so do so. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_exec.c | 35 ++++++++++++++++------------------- tools/libxl/libxl_fork.c | 25 ++++++++++++++++++++++++- tools/libxl/libxl_internal.h | 5 +++++ tools/libxl/libxl_utils.c | 21 --------------------- tools/libxl/libxl_utils.h | 3 +-- tools/libxl/xl.c | 12 ++++++++++++ tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 5 ++--- 8 files changed, 61 insertions(+), 46 deletions(-) diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index 882c048..b46b893 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -127,34 +127,23 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx, } } -int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, - pid_t innerchild) +int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, pid_t pid) { - struct xs_handle *xsh = NULL; - const char *pid = NULL; - int rc, xsok; + int r, rc; - pid = GCSPRINTF("%d", innerchild); + rc = libxl__ev_child_xenstore_reopen(gc, spawn->what); + if (rc) goto out; - /* we mustn't use the parent's handle in the child */ - xsh = xs_daemon_open(); - if (!xsh) { - LOGE(ERROR, "write %s = %s: xenstore reopen failed", - spawn->pidpath, pid); - rc = ERROR_FAIL; goto out; - } - - xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid)); - if (!xsok) { + r = libxl__xs_write(gc, XBT_NULL, spawn->pidpath, "%d", pid); + if (r) { LOGE(ERROR, - "write %s = %s: xenstore write failed", spawn->pidpath, pid); + "write %s = %d: xenstore write failed", spawn->pidpath, pid); rc = ERROR_FAIL; goto out; } rc = 0; out: - if (xsh) xs_daemon_close(xsh); return rc ? SIGTERM : 0; } @@ -302,7 +291,15 @@ int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss) /* we are now the middle process */ - child = fork(); + pid_t (*fork_replacement)(void*) = + CTX->childproc_hooks + ? CTX->childproc_hooks->fork_replacement + : 0; + child = + fork_replacement + ? fork_replacement(CTX->childproc_user) + : fork(); + if (child == -1) exit(255); if (!child) { diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c index 35c8bdd..9ff99e0 100644 --- a/tools/libxl/libxl_fork.c +++ b/tools/libxl/libxl_fork.c @@ -347,7 +347,12 @@ pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch, if (!pid) { /* woohoo! */ - return 0; /* Yes, CTX is left locked in the child. */ + if (CTX->xsh) { + xs_daemon_destroy_postfork(CTX->xsh); + CTX->xsh = NULL; /* turns mistakes into crashes */ + } + /* Yes, CTX is left locked in the child. */ + return 0; } ch->pid = pid; @@ -395,6 +400,24 @@ const libxl_childproc_hooks libxl__childproc_default_hooks = { libxl_sigchld_owner_libxl, 0, 0 }; +int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what) { + int rc; + + assert(!CTX->xsh); + CTX->xsh = xs_daemon_open(); + if (!CTX->xsh) { + LOGE(ERROR, "%s: xenstore reopen failed", what); + rc = ERROR_FAIL; goto out; + } + + libxl_fd_set_cloexec(CTX, xs_fileno(CTX->xsh), 1); + + return 0; + + out: + return rc; +} + /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 9f3f759..83fabea 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -640,6 +640,11 @@ static inline void libxl__ev_child_init(libxl__ev_child *childw_out) static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out) { return childw_out->pid >= 0; } +/* Useable (only) in the child to once more make the ctx useable for + * xenstore operations. logs failure in the form "what: ". */ +_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what); + /* * Other event-handling support provided by the libxl event core to diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index f0d94c6..858410e 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -444,27 +444,6 @@ int libxl__remove_directory(libxl__gc *gc, const char *dirpath) return rc; } -pid_t libxl_fork(libxl_ctx *ctx) -{ - pid_t pid; - - pid = fork(); - if (pid == -1) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed"); - return -1; - } - - if (!pid) { - if (ctx->xsh) xs_daemon_destroy_postfork(ctx->xsh); - ctx->xsh = 0; - /* This ensures that anyone who forks but doesn't exec, - * and doesn't reinitialise the libxl_ctx, is OK. - * It also means they can safely call libxl_ctx_free. */ - } - - return pid; -} - int libxl_pipe(libxl_ctx *ctx, int pipes[2]) { if (pipe(pipes) < 0) { diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h index 2b47622..74beb52 100644 --- a/tools/libxl/libxl_utils.h +++ b/tools/libxl/libxl_utils.h @@ -47,9 +47,8 @@ int libxl_write_exactly(libxl_ctx *ctx, int fd, const void *data, * logged using filename (which is only used for logging) and what * (which may be 0). */ -pid_t libxl_fork(libxl_ctx *ctx); int libxl_pipe(libxl_ctx *ctx, int pipes[2]); - /* Just like fork(2), pipe(2), but log errors. */ + /* Just like pipe(2), but log errors. */ void libxl_report_child_exitstatus(libxl_ctx *ctx, xentoollog_level, const char *what, pid_t pid, int status); diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index a6ffd25..d4db1f8 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -105,6 +105,18 @@ void postfork(void) } } +pid_t xl_fork(libxl_ctx *ctx) { + pid_t pid; + + pid = fork(); + if (pid == -1) { + perror("fork failed"); + exit(-1); + } + + return pid; +} + int main(int argc, char **argv) { int opt = 0; diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index f0d0ec8..2b6714a 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -104,6 +104,7 @@ struct cmd_spec *cmdtable_lookup(const char *s); extern libxl_ctx *ctx; extern xentoollog_logger_stdiostream *logger; +pid_t xl_fork(libxl_ctx *ctx); /* like fork, but prints and dies if it fails */ void postfork(void); /* global options */ diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index b91a2d5..efaf3de 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1736,7 +1736,7 @@ start: pid_t child1, got_child; int nullfd; - child1 = libxl_fork(ctx); + child1 = xl_fork(ctx); if (child1) { printf("Daemon running with PID %d\n", child1); @@ -2779,8 +2779,7 @@ static void migrate_domain(const char *domain_spec, const char *rune, MUST( libxl_pipe(ctx, sendpipe) ); MUST( libxl_pipe(ctx, recvpipe) ); - child = libxl_fork(ctx); - if (child==-1) exit(1); + child = xl_fork(ctx); if (!child) { dup2(sendpipe[0], 0); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006b0-Ux; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006W1-5e for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4139] by server-2.bemta-5.messagelabs.com id 18/9B-17016-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!10 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30213 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IE-Fw; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000g3-Da; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:00 +0100 Message-ID: <1336759092-2432-16-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Campbell Subject: [Xen-devel] [PATCH 15/27] libxl: add a dummy ao_how to libxl_domain_core_dump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Ian Campbell Although this function is not currently slow it may become so in the future (this also depends somewhat on the size of the guest). Therefore arrange for it to take an ao_how which it completes immediately. This will allow us to make it asynchronous in the future without breaking API compatibility. Signed-off-by: Ian Campbell Acked-by: Ian Jackson --- tools/libxl/libxl.c | 18 ++++++++++++++---- tools/libxl/libxl.h | 4 +++- tools/libxl/xl_cmdimpl.c | 4 ++-- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index d5fb186..482adaa 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -642,16 +642,26 @@ int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid) } int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, - const char *filename) + const char *filename, + const libxl_asyncop_how *ao_how) { - int ret; + AO_CREATE(ctx, domid, ao_how); + int ret, rc; + ret = xc_domain_dumpcore(ctx->xch, domid, filename); if (ret<0) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s", domid, filename); - return ERROR_FAIL; + rc = ERROR_FAIL; + goto out; } - return 0; + + rc = 0; +out: + + libxl__ao_complete(egc, ao, rc); + + return AO_INPROGRESS; } int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 3087146..d8dbb1e 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -511,7 +511,9 @@ int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid, int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid); int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid); -int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename); +int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, + const char *filename, + const libxl_asyncop_how *ao_how); int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb); int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce); diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index c1cab9e..45e2c30 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1306,7 +1306,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, LOG("failed to construct core dump path"); } else { LOG("dumping core to %s", corefile); - rc=libxl_domain_core_dump(ctx, domid, corefile); + rc=libxl_domain_core_dump(ctx, domid, corefile, NULL); if (rc) LOG("core dump failed (rc=%d).", rc); } /* No point crying over spilled milk, continue on failure. */ @@ -2927,7 +2927,7 @@ static void core_dump_domain(const char *domain_spec, const char *filename) { int rc; find_domain(domain_spec); - rc=libxl_domain_core_dump(ctx, domid, filename); + rc=libxl_domain_core_dump(ctx, domid, filename, NULL); if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006YC-Sz; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wa-F5 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.143.35:57375] by server-1.bemta-4.messagelabs.com id 13/B9-20925-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25712 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435463" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hk-Sl; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eQ-Q7; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:51 +0100 Message-ID: <1336759092-2432-7-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 06/27] libxl: provide libxl__remove_file et al. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These utility functions cope with EINTR AND ENOENT, do error logging, and we provide a recursive version to delete whole directory trees. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 7 ++++ tools/libxl/libxl_utils.c | 79 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 86 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index d04e856..909e01f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -433,6 +433,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n); * string. (similar to a gc'd dirname(3)). */ _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s); +/* Each of these logs errors and returns a libxl error code. + * They do not mind if path is already removed. + * For _file, path must not be a directory; for _directory it must be. */ +_hidden int libxl__remove_file(libxl__gc *gc, const char *path); +_hidden int libxl__remove_directory(libxl__gc *gc, const char *path); +_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path); + _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t, diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 0cbd85e..1a4874c 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, READ_WRITE_EXACTLY(read, 1, /* */) READ_WRITE_EXACTLY(write, 0, const) +int libxl__remove_file(libxl__gc *gc, const char *path) +{ + for (;;) { + int r = unlink(path); + if (!r) return 0; + if (errno == ENOENT) return 0; + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove file %s", path); + return ERROR_FAIL; + } +} + +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path) +{ + for (;;) { + int r = rmdir(path); + if (!r) return 0; + if (errno == ENOENT) return 0; + if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path); + if (errno == ENOTDIR) return libxl__remove_file(gc, path); + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove %s", path); + return ERROR_FAIL; + } +} + +int libxl__remove_directory(libxl__gc *gc, const char *dirpath) +{ + int rc = 0; + DIR *d = 0; + + d = opendir(dirpath); + if (!d) { + if (errno == ENOENT) + goto out; + + LOGE(ERROR, "failed to opendir %s for removal", dirpath); + rc = ERROR_FAIL; + goto out; + } + + size_t need = offsetof(struct dirent, d_name) + + pathconf(dirpath, _PC_NAME_MAX) + 1; + struct dirent *de_buf = libxl__zalloc(gc, need); + struct dirent *de; + + for (;;) { + int r = readdir_r(d, de_buf, &de); + if (r) { + LOGE(ERROR, "failed to readdir %s for removal", dirpath); + rc = ERROR_FAIL; + break; + } + if (!de) + break; + + if (!strcmp(de->d_name, ".") || + !strcmp(de->d_name, "..")) + continue; + + const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name); + if (libxl__remove_file_or_directory(gc, subpath)) + rc = ERROR_FAIL; + } + + for (;;) { + int r = rmdir(dirpath); + if (!r) break; + if (errno == ENOENT) goto out; + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove emptied directory %s", dirpath); + rc = ERROR_FAIL; + } + + out: + if (d) closedir(d); + + return rc; +} pid_t libxl_fork(libxl_ctx *ctx) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006XH-03; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6d-0006WB-5Y for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:19 +0000 Received: from [85.158.139.83:16205] by server-9.bemta-5.messagelabs.com id A4/FD-09826-A335DAF4; Fri, 11 May 2012 17:58:18 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30124 invoked from network); 11 May 2012 17:58:17 -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 May 2012 17:58:17 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435461" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hc-MG; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eE-He; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:48 +0100 Message-ID: <1336759092-2432-4-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 03/27] libxl: event API: new facilities for waiting for subprocesses X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The current arrangements in libxl for spawning subprocesses have two key problems: (i) they make unwarranted (and largely undocumented) assumptions about the caller's use of subprocesses, (ii) they aren't integrated into the event system and can't be made asynchronous etc. So replace them with a new set of facilities. Primarily, from the point of view of code inside libxl, this is libxl__ev_child_fork which is both (a) a version of fork() and (b) an event source which generates a callback when the child dies. >From the point of view of the application, we fully document our use of SIGCHLD. The application can tell us whether it wants to own SIGCHLD or not; if it does, it has to tell us about deaths of our children. Currently there are no callers in libxl which use these facilities. All code in libxl which forks needs to be converted and libxl_fork needse to be be abolished. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl.c | 17 +++- tools/libxl/libxl.h | 1 + tools/libxl/libxl_event.c | 53 +++++++-- tools/libxl/libxl_event.h | 147 +++++++++++++++++++++++- tools/libxl/libxl_fork.c | 255 ++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 62 ++++++++++- 6 files changed, 515 insertions(+), 20 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index c420e19..939cc02 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -39,7 +39,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, memset(ctx, 0, sizeof(libxl_ctx)); ctx->lg = lg; - /* First initialise pointers (cannot fail) */ + /* First initialise pointers etc. (cannot fail) */ LIBXL_TAILQ_INIT(&ctx->occurred); @@ -58,6 +58,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version, LIBXL_TAILQ_INIT(&ctx->death_list); libxl__ev_xswatch_init(&ctx->death_watch); + ctx->childproc_hooks = &libxl__childproc_default_hooks; + ctx->childproc_user = 0; + + ctx->sigchld_selfpipe[0] = -1; + /* The mutex is special because we can't idempotently destroy it */ if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) { @@ -160,6 +165,16 @@ int libxl_ctx_free(libxl_ctx *ctx) discard_events(&ctx->occurred); + /* If we have outstanding children, then the application inherits + * them; we wish the application good luck with understanding + * this if and when it reaps them. */ + libxl__sigchld_removehandler(ctx); + + if (ctx->sigchld_selfpipe[0] >= 0) { + close(ctx->sigchld_selfpipe[0]); + close(ctx->sigchld_selfpipe[1]); + } + pthread_mutex_destroy(&ctx->lock); GC_FREE; diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d59f0ee..fb90aed 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -380,6 +380,7 @@ enum { ERROR_NOT_READY = -11, ERROR_OSEVENT_REG_FAIL = -12, ERROR_BUFFERFULL = -13, + ERROR_UNKNOWN_CHILD = -14, }; diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 93c1d1f..3e784f0 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -627,6 +627,10 @@ static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller, \ REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, BODY); \ \ + int selfpipe = libxl__fork_selfpipe_active(CTX); \ + if (selfpipe >= 0) \ + REQUIRE_FD(selfpipe, POLLIN, BODY); \ + \ }while(0) #define REQUIRE_FD(req_fd_, req_events_, BODY) do{ \ @@ -766,10 +770,11 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller, int nfds, const struct pollfd *fds, struct timeval now) { + /* May make callbacks into the application for child processes. + * ctx must be locked exactly once */ EGC_GC; libxl__ev_fd *efd; - LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) { if (!efd->events) continue; @@ -780,11 +785,16 @@ static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller, } if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) { - char buf[256]; - int r = read(poller->wakeup_pipe[0], buf, sizeof(buf)); - if (r < 0) - if (errno != EINTR && errno != EWOULDBLOCK) - LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0); + int e = libxl__self_pipe_eatall(poller->wakeup_pipe[0]); + if (e) LIBXL__EVENT_DISASTER(egc, "read wakeup", e, 0); + } + + int selfpipe = libxl__fork_selfpipe_active(CTX); + if (selfpipe >= 0 && + afterpoll_check_fd(poller,fds,nfds, selfpipe, POLLIN)) { + int e = libxl__self_pipe_eatall(selfpipe); + if (e) LIBXL__EVENT_DISASTER(egc, "read sigchld pipe", e, 0); + libxl__fork_selfpipe_woken(egc); } for (;;) { @@ -1082,16 +1092,37 @@ void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p) void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p) { + int e = libxl__self_pipe_wakeup(p->wakeup_pipe[1]); + if (e) LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", e, 0); +} + +int libxl__self_pipe_wakeup(int fd) +{ static const char buf[1] = ""; for (;;) { - int r = write(p->wakeup_pipe[1], buf, 1); - if (r==1) return; + int r = write(fd, buf, 1); + if (r==1) return 0; assert(r==-1); if (errno == EINTR) continue; - if (errno == EWOULDBLOCK) return; - LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0); - return; + if (errno == EWOULDBLOCK) return 0; + assert(errno); + return errno; + } +} + +int libxl__self_pipe_eatall(int fd) +{ + char buf[256]; + for (;;) { + int r = read(fd, buf, sizeof(buf)); + if (r == sizeof(buf)) continue; + if (r >= 0) return 0; + assert(r == -1); + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) return 0; + assert(errno); + return errno; } } diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h index 2d2196f..713d96d 100644 --- a/tools/libxl/libxl_event.h +++ b/tools/libxl/libxl_event.h @@ -163,11 +163,6 @@ void libxl_event_register_callbacks(libxl_ctx *ctx, * After libxl_ctx_free, all corresponding evgen handles become * invalid and must no longer be passed to evdisable. * - * Events enabled with evenable prior to a fork and libxl_ctx_postfork - * are no longer generated after the fork/postfork; however the evgen - * structures are still valid and must be passed to evdisable if the - * memory they use should not be leaked. - * * Applications should ensure that they eventually retrieve every * event using libxl_event_check or libxl_event_wait, since events * which occur but are not retreived by the application will be queued @@ -372,6 +367,148 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl, void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl); +/*======================================================================*/ + +/* + * Subprocess handling. + * + * Unfortunately the POSIX interface makes this very awkward. + * + * There are two possible arrangements for collecting statuses from + * wait/waitpid. + * + * For naive programs: + * + * libxl will keep a SIGCHLD handler installed whenever it has an + * active (unreaped) child. It will reap all children with + * wait(); any children it does not recognise will be passed to + * the application via an optional callback (and will result in + * logged warnings if no callback is provided or the callback + * denies responsibility for the child). + * + * libxl may have children whenever: + * + * - libxl is performing an operation which can be made + * asynchronous; ie one taking a libxl_asyncop_how, even + * if NULL is passed indicating that the operation is + * synchronous; or + * + * - events of any kind are being generated, as requested + * by libxl_evenable_.... + * + * A multithreaded application which is naive in this sense may + * block SIGCHLD on some of its threads, but there must be at + * least one thread that has SIGCHLD unblocked. libxl will not + * modify the blocking flag for SIGCHLD (except that it may create + * internal service threads with all signals blocked). + * + * A naive program must only have at any one time only + * one libxl context which might have children. + * + * For programs which run their own children alongside libxl's: + * + * A program which does this must call libxl_childproc_setmode. + * There are two options: + * + * libxl_sigchld_owner_mainloop: + * 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. + * + * libxl_sigchld_owner_libxl_always: + * The application expects libxl to reap all of its children, + * and provides a callback to be notified of their exit + * statues. + * + * An application which fails to call setmode, or which passes 0 for + * hooks, while it uses any libxl operation which might + * create or use child processes (see above): + * - Must not have any child processes running. + * - Must not install a SIGCHLD handler. + * - Must not reap any children. + */ + + +typedef enum { + /* libxl owns SIGCHLD whenever it has a child. */ + libxl_sigchld_owner_libxl, + + /* Application promises to call libxl_childproc_exited but NOT + * from within a signal handler. libxl will not itself arrange to + * (un)block or catch SIGCHLD. */ + libxl_sigchld_owner_mainloop, + + /* libxl owns SIGCHLD all the time, and the application is + * relying on libxl's event loop for reaping its own children. */ + libxl_sigchld_owner_libxl_always, +} libxl_sigchld_owner; + +typedef struct { + libxl_sigchld_owner chldowner; + + /* All of these are optional: */ + + /* Called by libxl instead of fork. Should behave exactly like + * fork, including setting errno etc. May NOT reenter into libxl. + * Application may use this to discover pids of libxl's children, + * for example. + */ + pid_t (*fork_replacement)(void *user); + + /* With libxl_sigchld_owner_libxl, called by libxl when it has + * reaped a pid. (Not permitted with _owner_mainloop.) + * + * Should return 0 if the child was recognised by the application + * (or if the application does not keep those kind of records), + * ERROR_UNKNOWN_CHILD if the application knows that the child is not + * the application's; if it returns another error code it is a + * disaster as described for libxl_event_register_callbacks. + * (libxl will report unexpected children to its error log.) + * + * If not supplied, the application is assumed not to start + * any children of its own. + * + * This function is NOT called from within the signal handler. + * Rather it will be called from inside a libxl's event handling + * code and thus only when libxl is running, for example from + * within libxl_event_wait. (libxl uses the self-pipe trick + * to implement this.) + * + * childproc_exited_callback may call back into libxl, but it + * is best to avoid making long-running libxl calls as that might + * stall the calling event loop while the nested operation + * completes. + */ + int (*reaped_callback)(pid_t, int status, void *user); +} libxl_childproc_hooks; + +/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libxl, 0, 0 } + * + * May not be called when libxl might have any child processes, or the + * behaviour is undefined. So it is best to call this at + * initialisation. + */ +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks, + void *user); + +/* + * This function is for an application which owns SIGCHLD and which + * therefore reaps all of the process's children. + * + * May be called only by an application which has called setmode with + * chldowner == libxl_sigchld_owner_mainloop. If pid was a process started + * by this instance of libxl, returns 0 after doing whatever + * processing is appropriate. Otherwise silently returns + * ERROR_UNKNOWN_CHILD. No other error returns are possible. + * + * May NOT be called from within a signal handler which might + * interrupt any libxl operation. The application will almost + * certainly need to use the self-pipe trick (or a working pselect or + * ppoll) to implement this. + */ +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t, int status); + + /* * An application which initialises a libxl_ctx in a parent process * and then forks a child which does not quickly exec, must diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c index dce88ad..35c8bdd 100644 --- a/tools/libxl/libxl_fork.c +++ b/tools/libxl/libxl_fork.c @@ -46,6 +46,12 @@ static int atfork_registered; static LIBXL_LIST_HEAD(, libxl__carefd) carefds = LIBXL_LIST_HEAD_INITIALIZER(carefds); +/* non-null iff installed, protected by no_forking */ +static libxl_ctx *sigchld_owner; +static struct sigaction sigchld_saved_action; + +static void sigchld_removehandler_core(void); + static void atfork_lock(void) { int r = pthread_mutex_lock(&no_forking); @@ -107,6 +113,7 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx) int r; atfork_lock(); + LIBXL_LIST_FOREACH_SAFE(cf, &carefds, entry, cf_tmp) { if (cf->fd >= 0) { r = close(cf->fd); @@ -118,6 +125,10 @@ void libxl_postfork_child_noexec(libxl_ctx *ctx) free(cf); } LIBXL_LIST_INIT(&carefds); + + if (sigchld_owner) + sigchld_removehandler_core(); + atfork_unlock(); } @@ -141,6 +152,250 @@ int libxl__carefd_fd(const libxl__carefd *cf) } /* + * Actual child process handling + */ + +static void sigchld_handler(int signo) +{ + int e = libxl__self_pipe_wakeup(sigchld_owner->sigchld_selfpipe[1]); + assert(!e); /* errors are probably EBADF, very bad */ +} + +static void sigchld_removehandler_core(void) +{ + struct sigaction was; + int r; + + r = sigaction(SIGCHLD, &sigchld_saved_action, &was); + assert(!r); + assert(!(was.sa_flags & SA_SIGINFO)); + assert(was.sa_handler == sigchld_handler); + sigchld_owner = 0; +} + +void libxl__sigchld_removehandler(libxl_ctx *ctx) /* non-reentrant */ +{ + atfork_lock(); + if (sigchld_owner == ctx) + sigchld_removehandler_core(); + atfork_unlock(); +} + +int libxl__sigchld_installhandler(libxl_ctx *ctx) /* non-reentrant */ +{ + int r, rc; + + if (ctx->sigchld_selfpipe[0] < 0) { + r = pipe(ctx->sigchld_selfpipe); + if (r) { + ctx->sigchld_selfpipe[0] = -1; + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, + "failed to create sigchld pipe"); + rc = ERROR_FAIL; + goto out; + } + } + + atfork_lock(); + if (sigchld_owner != ctx) { + struct sigaction ours; + + assert(!sigchld_owner); + sigchld_owner = ctx; + + memset(&ours,0,sizeof(ours)); + ours.sa_handler = sigchld_handler; + sigemptyset(&ours.sa_mask); + ours.sa_flags = SA_NOCLDSTOP | SA_RESTART; + r = sigaction(SIGCHLD, &ours, &sigchld_saved_action); + assert(!r); + + assert(((void)"application must negotiate with libxl about SIGCHLD", + !(sigchld_saved_action.sa_flags & SA_SIGINFO) && + (sigchld_saved_action.sa_handler == SIG_DFL || + sigchld_saved_action.sa_handler == SIG_IGN))); + } + atfork_unlock(); + + rc = 0; + out: + return rc; +} + +static int chldmode_ours(libxl_ctx *ctx) +{ + return ctx->childproc_hooks->chldowner == libxl_sigchld_owner_libxl; +} + +int libxl__fork_selfpipe_active(libxl_ctx *ctx) +{ + /* Returns the fd to read, or -1 */ + if (!chldmode_ours(ctx)) + return -1; + + if (LIBXL_LIST_EMPTY(&ctx->children)) + return -1; + + return ctx->sigchld_selfpipe[0]; +} + +static void perhaps_removehandler(libxl_ctx *ctx) +{ + if (LIBXL_LIST_EMPTY(&ctx->children) && + ctx->childproc_hooks->chldowner != libxl_sigchld_owner_libxl_always) + libxl__sigchld_removehandler(ctx); +} + +static int childproc_reaped(libxl__egc *egc, pid_t pid, int status) +{ + EGC_GC; + libxl__ev_child *ch; + + LIBXL_LIST_FOREACH(ch, &CTX->children, entry) + if (ch->pid == pid) + goto found; + + /* not found */ + return ERROR_UNKNOWN_CHILD; + + found: + LIBXL_LIST_REMOVE(ch, entry); + ch->pid = -1; + ch->callback(egc, ch, pid, status); + + perhaps_removehandler(CTX); + + return 0; +} + +int libxl_childproc_reaped(libxl_ctx *ctx, pid_t pid, int status) +{ + EGC_INIT(ctx); + CTX_LOCK; + int rc = childproc_reaped(egc, pid, status); + CTX_UNLOCK; + EGC_FREE; + return rc; +} + +void libxl__fork_selfpipe_woken(libxl__egc *egc) +{ + /* May make callbacks into the application for child processes. + * ctx must be locked EXACTLY ONCE */ + EGC_GC; + + while (chldmode_ours(CTX) /* in case the app changes the mode */) { + int status; + pid_t pid = waitpid(-1, &status, WNOHANG); + + if (pid == 0) return; + + if (pid == -1) { + if (errno == ECHILD) return; + if (errno == EINTR) continue; + LIBXL__EVENT_DISASTER(egc, "waitpid() failed", errno, 0); + return; + } + + int rc = childproc_reaped(egc, pid, status); + + if (rc) { + if (CTX->childproc_hooks->reaped_callback) { + CTX_UNLOCK; + rc = CTX->childproc_hooks->reaped_callback + (pid, status, CTX->childproc_user); + CTX_LOCK; + if (rc != 0 && rc != ERROR_UNKNOWN_CHILD) { + char disasterbuf[200]; + snprintf(disasterbuf, sizeof(disasterbuf), " reported by" + " libxl_childproc_hooks->reaped_callback" + " (for pid=%lu, status=%d; error code %d)", + (unsigned long)pid, status, rc); + LIBXL__EVENT_DISASTER(egc, disasterbuf, 0, 0); + return; + } + } else { + rc = ERROR_UNKNOWN_CHILD; + } + if (rc) + libxl_report_child_exitstatus(CTX, XTL_WARN, + "unknown child", (long)pid, status); + } + } +} + +pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *ch, + libxl__ev_child_callback *death) +{ + CTX_LOCK; + int rc; + + if (chldmode_ours(CTX)) { + rc = libxl__sigchld_installhandler(CTX); + if (rc) goto out; + } + + pid_t pid = + CTX->childproc_hooks->fork_replacement + ? CTX->childproc_hooks->fork_replacement(CTX->childproc_user) + : fork(); + if (pid == -1) { + LOGE(ERROR, "fork failed"); + rc = ERROR_FAIL; + goto out; + } + + if (!pid) { + /* woohoo! */ + return 0; /* Yes, CTX is left locked in the child. */ + } + + ch->pid = pid; + ch->callback = death; + LIBXL_LIST_INSERT_HEAD(&CTX->children, ch, entry); + rc = pid; + + out: + perhaps_removehandler(CTX); + CTX_UNLOCK; + return rc; +} + +void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks, + void *user) +{ + GC_INIT(ctx); + CTX_LOCK; + + assert(LIBXL_LIST_EMPTY(&CTX->children)); + + if (!hooks) + hooks = &libxl__childproc_default_hooks; + + ctx->childproc_hooks = hooks; + ctx->childproc_user = user; + + switch (ctx->childproc_hooks->chldowner) { + case libxl_sigchld_owner_mainloop: + case libxl_sigchld_owner_libxl: + libxl__sigchld_removehandler(ctx); + break; + case libxl_sigchld_owner_libxl_always: + libxl__sigchld_installhandler(ctx); + break; + default: + abort(); + } + + CTX_UNLOCK; + GC_FREE; +} + +const libxl_childproc_hooks libxl__childproc_default_hooks = { + libxl_sigchld_owner_libxl, 0, 0 +}; + +/* * Local variables: * mode: C * c-basic-offset: 4 diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 01c9ba9..d04e856 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -198,6 +198,19 @@ _hidden libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum); +typedef struct libxl__ev_child libxl__ev_child; +typedef void libxl__ev_child_callback(libxl__egc *egc, libxl__ev_child*, + pid_t pid, int status); +struct libxl__ev_child { + /* caller should include this in their own struct */ + /* read-only for caller: */ + pid_t pid; /* -1 means unused ("unregistered", ie Idle) */ + libxl__ev_child_callback *callback; + /* remainder is private for libxl__ev_... */ + LIBXL_LIST_ENTRY(struct libxl__ev_child) entry; +}; + + /* * evgen structures, which are the state we use for generating * events for the caller. @@ -306,10 +319,14 @@ struct libxl__ctx { LIBXL_LIST_HEAD(, libxl_evgen_disk_eject) disk_eject_evgens; - /* for callers who reap children willy-nilly; caller must only - * set this after libxl_init and before any other call - or - * may leave them untouched */ + const libxl_childproc_hooks *childproc_hooks; + void *childproc_user; + int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */ + LIBXL_LIST_HEAD(, libxl__ev_child) children; + + /* This is obsolete and must be removed: */ int (*waitpid_instead)(pid_t pid, int *status, int flags); + libxl_version_info version_info; }; @@ -557,6 +574,36 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw) /* + * For making subprocesses. This is the only permitted mechanism for + * code in libxl to do so. + * + * In the parent, returns the pid, filling in childw_out. + * In the child, returns 0. + * If it fails, returns a libxl error (all of which are -ve). + * + * The child should go on to exec (or exit) soon. The child may not + * make any further calls to libxl infrastructure, except for memory + * allocation and logging. If the child needs to use xenstore it + * must open its own xs handle and use it directly, rather than via + * the libxl event machinery. + * + * The parent may signal the child but it must not reap it. That will + * be done by the event machinery. death may be NULL in which case + * the child is still reaped but its death is ignored. + * + * It is not possible to "deregister" the child death event source. + * It will generate exactly one event callback; until then the childw + * is Active and may not be reused. + */ +_hidden pid_t libxl__ev_child_fork(libxl__gc *gc, libxl__ev_child *childw_out, + libxl__ev_child_callback *death); +static inline void libxl__ev_child_init(libxl__ev_child *childw_out) + { childw_out->pid = -1; } +static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out) + { return childw_out->pid >= 0; } + + +/* * Other event-handling support provided by the libxl event core to * the rest of libxl. */ @@ -610,6 +657,15 @@ _hidden void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p); * ctx must be locked. */ _hidden void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p); +/* Internal to fork and child reaping machinery */ +extern const libxl_childproc_hooks libxl__childproc_default_hooks; +int libxl__sigchld_installhandler(libxl_ctx *ctx); /* non-reentrant;logs errs */ +void libxl__sigchld_removehandler(libxl_ctx *ctx); /* non-reentrant */ +int libxl__fork_selfpipe_active(libxl_ctx *ctx); /* returns read fd or -1 */ +void libxl__fork_selfpipe_woken(libxl__egc *egc); +int libxl__self_pipe_wakeup(int fd); /* returns 0 or -1 setting errno */ +int libxl__self_pipe_eatall(int fd); /* returns 0 or -1 setting errno */ + _hidden int libxl__atfork_init(libxl_ctx *ctx); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6n-0006gG-02; Fri, 11 May 2012 17:58:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wa-2E for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42691] by server-1.bemta-4.messagelabs.com id 25/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32043 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435476" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IN-Li; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000gF-JS; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:03 +0100 Message-ID: <1336759092-2432-19-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 18/27] libxl: ao: convert libxl__spawn_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org libxl__spawn_spawn becomes a callback-style asynchronous function. The implementation is now in terms of libxl__ev_* including libxl_ev_child. All the callers need to be updated. This includes the device model spawning functions libxl__create_device_model and libxl__create_stubdom; these are replaced with libxl__spawn_local_dm and libxl__spawn_stubdom. libxl__confirm_device_model_startup is abolished; instead the dm spawner calls back. (The choice of which kind of device model to create is lifted out of what used to be libxl__create_device_model, because that function was indirectly recursive. Recursive callback-style operations are clumsy because they require a pointer indirection for the nested states.) Waiting for proper device model startup it is no longer notionally optional. Previously the code appeared to tolerate this by passing NULL for various libxl__spawner_starting* parameters to device model spawners. However, this was not used anywhere. Conversely, the "for_spawn" parameter to libxl__wait_for_offspring is no longer supported. It remains as an unused formal parameter to avoid updating, in this patch, all the call sites which pass NULL. libxl__wait_for_offspring is in any case itself an obsolete function, so this wrinkle will go away when its callers are updated to use the event system. Consequently libxl__spawn_check is also abolished. The "console ready" callback also remains unchanged in this patch. The API for this needs to be reviewed in the context of the event series and its reentrancy restrictions documented. Thus their callers need to be updated. These are the domain creation functions libxl_domain_create_new and _restore. These functions now take ao_hows, and have a private state structure. However domain creation remains not completely converted to the event mechanism; in particular it runs the outward-facing function libxl_run_bootloader with a NULL ao_how, which is quite wrong. As it happens in the current code this is not a bug because none of the rest of the functionality surrounding the bootloader call will mind if the event loop is reentered in the middle of its execution. The file-scope function libxl__set_fd_flag which was used by the previous spawn arrangements becomes unused and is removed; other places in libxl can use libxl_fd_set_nonblock and libxl_fd_set_cloexec, which of course remain. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v8: * Make midproc_cb callback with correct pid (that of the grandchild, not "middle" which is zero). Reported by Roger Pau Monne. Changes since v7: * Rename libxl__spawn_stubdom to libxl__spawn_stub_dm (and ..._state); rename the state's stubdom_* members to dm_*. * Eliminate the union between the two dm creation states in libxl__domain_create_state. Instead, the domain creation code simply uses libxl__stub_dm_spawn_state.dm directly, if we're taking the local dm path. * Remove a spurious "break". * In domain creation, move the PV non-qemu case into the switch. * Code style fixes. * Constify some convenience aliases. * Improve comments (including typo fixes). --- tools/libxl/libxl.h | 14 ++- tools/libxl/libxl_create.c | 206 +++++++++++++++++++----- tools/libxl/libxl_dm.c | 219 +++++++++++++++----------- tools/libxl/libxl_exec.c | 354 +++++++++++++++++++++--------------------- tools/libxl/libxl_internal.h | 286 +++++++++++++++++++++++----------- tools/libxl/xl_cmdimpl.c | 6 +- 6 files changed, 683 insertions(+), 402 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index d8dbb1e..e19d947 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -465,8 +465,18 @@ int libxl_ctx_free(libxl_ctx *ctx /* 0 is OK */); /* domain related functions */ 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); + /* fixme-ao Need to review this API. If we keep it, the reentrancy + * properties need to be documented but they may turn out to be too + * awkward */ + +int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, + libxl_console_ready cb, void *priv, uint32_t *domid, + const libxl_asyncop_how *ao_how); +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, + const libxl_asyncop_how *ao_how); + void libxl_domain_config_init(libxl_domain_config *d_config); void libxl_domain_config_dispose(libxl_domain_config *d_config); int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info, diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index b137288..9ce107a 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -558,16 +558,40 @@ static int store_libxl_entry(libxl__gc *gc, uint32_t domid, libxl_device_model_version_to_string(b_info->device_model_version)); } -static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, - uint32_t *domid_out, int restore_fd) +/*----- main domain creation -----*/ + +/* We have a linear control flow; only one event callback is + * outstanding at any time. Each initiation and callback function + * arranges for the next to be called, as the very last thing it + * does. (If that particular sub-operation is not needed, a + * function will call the next event callback directly.) + */ + +/* Event callbacks, in this order: */ +static void domcreate_devmodel_started(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc); + +/* Our own function to clean up and call the user's callback. + * The final call in the sequence. */ +static void domcreate_complete(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc); + +static void initiate_domain_create(libxl__egc *egc, + libxl__domain_create_state *dcs) { + STATE_AO_GC(dcs->ao); libxl_ctx *ctx = libxl__gc_owner(gc); - libxl__spawner_starting *dm_starting = 0; - libxl__domain_build_state state[1]; uint32_t domid; int i, ret; + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + const int restore_fd = dcs->restore_fd; + const libxl_console_ready cb = dcs->console_cb; + void *const priv = dcs->console_cb_priv; + domid = 0; ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); @@ -580,9 +604,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, goto error_out; } + dcs->guest_domid = domid; + dcs->dmss.dm.guest_domid = 0; /* means we haven't spawned */ + if ( d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV && cb ) { - if ( (*cb)(ctx, domid, priv) ) - goto error_out; + ret = (*cb)(ctx, domid, priv); + if (ret) goto error_out; } ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info); @@ -606,7 +633,17 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, } } - memset(state, 0, sizeof(*state)); + memset(&dcs->build_state, 0, sizeof(dcs->build_state)); + libxl__domain_build_state *state = &dcs->build_state; + + /* We might be going to call libxl__spawn_local_dm, or _spawn_stub_dm. + * Fill in any field required by either, including both relevant + * callbacks (_spawn_stub_dm will overwrite our trespass if needed). */ + dcs->dmss.dm.spawn.ao = ao; + dcs->dmss.dm.guest_config = dcs->guest_config; + dcs->dmss.dm.build_state = &dcs->build_state; + dcs->dmss.dm.callback = domcreate_devmodel_started; + dcs->dmss.callback = domcreate_devmodel_started; if ( restore_fd >= 0 ) { ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, state); @@ -656,14 +693,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl_device_vkb_add(ctx, domid, &vkb); libxl_device_vkb_dispose(&vkb); - ret = libxl__create_device_model(gc, domid, d_config, - state, &dm_starting); - if (ret < 0) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "failed to create device model: %d", ret); - goto error_out; - } - break; + dcs->dmss.dm.guest_domid = domid; + if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) + libxl__spawn_stub_dm(egc, &dcs->dmss); + else + libxl__spawn_local_dm(egc, &dcs->dmss.dm); + return; } case LIBXL_DOMAIN_TYPE_PV: { @@ -687,26 +722,52 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, libxl__device_console_dispose(&console); if (need_qemu) { - libxl__create_xenpv_qemu(gc, domid, d_config, state, &dm_starting); + dcs->dmss.dm.guest_domid = domid; + libxl__spawn_local_dm(egc, &dcs->dmss.dm); + return; + } else { + assert(!dcs->dmss.dm.guest_domid); + domcreate_devmodel_started(egc, &dcs->dmss.dm, 0); + return; } - break; } default: ret = ERROR_INVAL; goto error_out; } + abort(); /* not reached */ + + error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + +static void domcreate_devmodel_started(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int ret) +{ + libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm); + STATE_AO_GC(dmss->spawn.ao); + int i; + libxl_ctx *ctx = CTX; + int domid = dcs->guest_domid; + + /* convenience aliases */ + libxl_domain_config *const d_config = dcs->guest_config; + const libxl_console_ready cb = dcs->console_cb; + void *const priv = dcs->console_cb_priv; + + if (ret) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, + "device model did not start: %d", ret); + goto error_out; + } - if (dm_starting) { + if (dcs->dmss.dm.guest_domid) { if (d_config->b_info.device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { libxl__qmp_initializations(gc, domid, d_config); } - 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); - goto error_out; - } } for (i = 0; i < d_config->num_pcidevs; i++) @@ -734,38 +795,95 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, 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 ))) { - if ( (*cb)(ctx, domid, priv) ) - goto error_out; + ret = (*cb)(ctx, domid, priv); + if (ret) goto error_out; } - *domid_out = domid; - return 0; + domcreate_complete(egc, dcs, 0); + return; error_out: - if (domid) - libxl_domain_destroy(ctx, domid); + assert(ret); + domcreate_complete(egc, dcs, ret); +} - return ret; +static void domcreate_complete(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc) +{ + STATE_AO_GC(dcs->ao); + + if (rc) { + if (dcs->guest_domid) { + int rc2 = libxl_domain_destroy(CTX, dcs->guest_domid); + if (rc2) + LOG(ERROR, "unable to destroy domain %d following" + " failed creation", dcs->guest_domid); + } + dcs->guest_domid = -1; + } + dcs->callback(egc, dcs, rc, dcs->guest_domid); } +/*----- application-facing domain creation interface -----*/ + +typedef struct { + libxl__domain_create_state dcs; + uint32_t *domid_out; +} libxl__app_domain_create_state; + +static void domain_create_cb(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc, uint32_t domid); + +static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, + libxl_console_ready cb, void *priv, uint32_t *domid, + int restore_fd, const libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx, 0, ao_how); + libxl__app_domain_create_state *cdcs; + + GCNEW(cdcs); + cdcs->dcs.ao = ao; + cdcs->dcs.guest_config = d_config; + cdcs->dcs.restore_fd = restore_fd; + cdcs->dcs.console_cb = cb; + cdcs->dcs.console_cb_priv = priv; + cdcs->dcs.callback = domain_create_cb; + cdcs->domid_out = domid; + + initiate_domain_create(egc, &cdcs->dcs); + + return AO_INPROGRESS; +} + +static void domain_create_cb(libxl__egc *egc, + libxl__domain_create_state *dcs, + int rc, uint32_t domid) +{ + libxl__app_domain_create_state *cdcs = CONTAINER_OF(dcs, *cdcs, dcs); + STATE_AO_GC(cdcs->dcs.ao); + + if (!rc) + *cdcs->domid_out = domid; + + libxl__ao_complete(egc, ao, rc); +} + int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid) + libxl_console_ready cb, void *priv, + uint32_t *domid, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - int rc; - rc = do_domain_create(gc, d_config, cb, priv, domid, -1); - GC_FREE; - return rc; + return do_domain_create(ctx, d_config, cb, priv, domid, -1, ao_how); } int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, - libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd) + libxl_console_ready cb, void *priv, + uint32_t *domid, int restore_fd, + const libxl_asyncop_how *ao_how) { - GC_INIT(ctx); - int rc; - rc = do_domain_create(gc, d_config, cb, priv, domid, restore_fd); - GC_FREE; - return rc; + return do_domain_create(ctx, d_config, cb, priv, domid, restore_fd, ao_how); } /* diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 725c3c0..4ad7d02 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -669,24 +669,28 @@ retry_transaction: return 0; } -static int libxl__create_stubdom(libxl__gc *gc, - int guest_domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *d_state, - libxl__spawner_starting **starting_r) +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc); + +void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) { + STATE_AO_GC(sdss->dm.spawn.ao); libxl_ctx *ctx = libxl__gc_owner(gc); int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret; libxl__device_console *console; - libxl_domain_config dm_config[1]; libxl_device_vfb vfb; libxl_device_vkb vkb; - libxl__domain_build_state stubdom_state[1]; - uint32_t dm_domid; char **args; struct xs_permissions perm[2]; xs_transaction_t t; - libxl__spawner_starting *dm_starting = 0; + + /* convenience aliases */ + libxl_domain_config *const dm_config = &sdss->dm_config; + libxl_domain_config *const guest_config = sdss->dm.guest_config; + const int guest_domid = sdss->dm.guest_domid; + libxl__domain_build_state *const d_state = sdss->dm.build_state; + libxl__domain_build_state *const stubdom_state = &sdss->dm_state; if (guest_config->b_info.device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) { @@ -694,6 +698,8 @@ static int libxl__create_stubdom(libxl__gc *gc, goto out; } + sdss->pvqemu.guest_domid = 0; + libxl_domain_create_info_init(&dm_config->c_info); dm_config->c_info.type = LIBXL_DOMAIN_TYPE_PV; dm_config->c_info.name = libxl__sprintf(gc, "%s-dm", @@ -741,10 +747,10 @@ static int libxl__create_stubdom(libxl__gc *gc, dm_config->num_vkbs = 1; /* fixme: this function can leak the stubdom if it fails */ - dm_domid = 0; - ret = libxl__domain_make(gc, &dm_config->c_info, &dm_domid); + ret = libxl__domain_make(gc, &dm_config->c_info, &sdss->pvqemu.guest_domid); if (ret) goto out; + uint32_t dm_domid = sdss->pvqemu.guest_domid; ret = libxl__domain_build(gc, &dm_config->b_info, dm_domid, stubdom_state); if (ret) goto out; @@ -852,42 +858,67 @@ retry_transaction: goto out_free; } - if (libxl__create_xenpv_qemu(gc, dm_domid, - dm_config, - stubdom_state, - &dm_starting) < 0) { - ret = ERROR_FAIL; - goto out_free; - } - if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) { - ret = ERROR_FAIL; - goto out_free; - } - - libxl_domain_unpause(ctx, dm_domid); + sdss->pvqemu.guest_domid = dm_domid; + sdss->pvqemu.guest_config = &sdss->dm_config; + sdss->pvqemu.build_state = &sdss->dm_state; + sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb; - if (starting_r) { - *starting_r = calloc(1, sizeof(libxl__spawner_starting)); - (*starting_r)->domid = guest_domid; - (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid); - (*starting_r)->for_spawn = NULL; - } + libxl__spawn_local_dm(egc, &sdss->pvqemu); - ret = 0; + free(args); + return; out_free: free(args); out: - return ret; + assert(ret); + spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); } -int libxl__create_device_model(libxl__gc *gc, - int domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *state, - libxl__spawner_starting **starting_r) +static void spawn_stubdom_pvqemu_cb(libxl__egc *egc, + libxl__dm_spawn_state *stubdom_dmss, + int rc) { - libxl_ctx *ctx = libxl__gc_owner(gc); + libxl__stub_dm_spawn_state *sdss = + CONTAINER_OF(stubdom_dmss, *sdss, pvqemu); + STATE_AO_GC(sdss->dm.spawn.ao); + uint32_t dm_domid = sdss->pvqemu.guest_domid; + + if (rc) goto out; + + rc = libxl_domain_unpause(CTX, dm_domid); + if (rc) goto out; + + out: + if (rc) { + if (dm_domid) + libxl_domain_destroy(CTX, dm_domid); + } + sdss->callback(egc, &sdss->dm, rc); +} + +/* callbacks passed to libxl__spawn_spawn */ +static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, + const char *xsdata); +static void device_model_startup_failed(libxl__egc *egc, + libxl__spawn_state *spawn); + +/* our "next step" function, called from those callbacks and elsewhere */ +static void device_model_spawn_outcome(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc); + +void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss) +{ + /* convenience aliases */ + const int domid = dmss->guest_domid; + libxl__domain_build_state *const state = dmss->build_state; + libxl__spawn_state *const spawn = &dmss->spawn; + + STATE_AO_GC(dmss->spawn.ao); + + libxl_ctx *ctx = CTX; + libxl_domain_config *guest_config = dmss->guest_config; 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 = libxl__dm_vnc(guest_config); @@ -895,15 +926,13 @@ int libxl__create_device_model(libxl__gc *gc, int logfile_w, null; int rc; char **args, **arg; - libxl__spawner_starting buf_starting, *p; xs_transaction_t t; char *vm_path; char **pass_stuff; const char *dm; if (libxl_defbool_val(b_info->device_model_stubdomain)) { - rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r); - goto out; + abort(); } dm = libxl__domain_device_model(gc, b_info); @@ -947,25 +976,8 @@ int libxl__create_device_model(libxl__gc *gc, free(logfile); null = open("/dev/null", O_RDONLY); - if (starting_r) { - rc = ERROR_NOMEM; - *starting_r = calloc(1, sizeof(libxl__spawner_starting)); - if (!*starting_r) - goto out_close; - p = *starting_r; - p->for_spawn = calloc(1, sizeof(libxl__spawn_starting)); - } else { - p = &buf_starting; - p->for_spawn = NULL; - } - - 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; - goto out_close; - } + const char *dom_path = libxl__xs_get_dompath(gc, domid); + spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid"); if (vnc && vnc->passwd) { /* This xenstore key will only be used by qemu-xen-traditionnal. @@ -973,7 +985,7 @@ int libxl__create_device_model(libxl__gc *gc, retry_transaction: /* Find uuid and the write the vnc password to xenstore for qemu. */ t = xs_transaction_start(ctx->xsh); - vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", p->dom_path)); + vm_path = libxl__xs_read(gc,t,libxl__sprintf(gc, "%s/vm", dom_path)); if (vm_path) { /* Now write the vncpassword into it. */ pass_stuff = libxl__calloc(gc, 3, sizeof(char *)); @@ -990,8 +1002,15 @@ retry_transaction: for (arg = args; *arg; arg++) LIBXL__LOG(CTX, XTL_DEBUG, " %s", *arg); - rc = libxl__spawn_spawn(gc, p->for_spawn, "device model", - libxl_spawner_record_pid, p); + spawn->what = GCSPRINTF("domain %d device model", domid); + spawn->xspath = GCSPRINTF("/local/domain/0/device-model/%d/state", domid); + spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000; + spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path); + spawn->midproc_cb = libxl__spawn_record_pid; + spawn->confirm_cb = device_model_confirm; + spawn->failure_cb = device_model_startup_failed; + + rc = libxl__spawn_spawn(egc, spawn); if (rc < 0) goto out_close; if (!rc) { /* inner child */ @@ -1006,30 +1025,61 @@ out_close: close(logfile_w); free(args); out: - return rc; + if (rc) + device_model_spawn_outcome(egc, dmss, rc); +} + + +static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, + const char *xsdata) +{ + libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn); + STATE_AO_GC(spawn->ao); + + if (!xsdata) + return; + + if (strcmp(xsdata, "running")) + return; + + libxl__spawn_detach(gc, spawn); + + device_model_spawn_outcome(egc, dmss, 0); } +static void device_model_startup_failed(libxl__egc *egc, + libxl__spawn_state *spawn) +{ + libxl__dm_spawn_state *dmss = CONTAINER_OF(spawn, *dmss, spawn); + device_model_spawn_outcome(egc, dmss, ERROR_FAIL); +} -int libxl__confirm_device_model_startup(libxl__gc *gc, - libxl__domain_build_state *state, - libxl__spawner_starting *starting) +static void device_model_spawn_outcome(libxl__egc *egc, + libxl__dm_spawn_state *dmss, + int rc) { - char *path; - int domid = starting->domid; - int ret, ret2; - path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid); - ret = libxl__spawn_confirm_offspring_startup(gc, - LIBXL_DEVICE_MODEL_START_TIMEOUT, - "Device Model", path, "running", starting); + STATE_AO_GC(dmss->spawn.ao); + int ret2; + + if (rc) + LOG(ERROR, "%s: spawn failed (rc=%d)", dmss->spawn.what, rc); + + libxl__domain_build_state *state = dmss->build_state; + 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", - state->saved_state); - /* Do not clobber spawn_confirm error code with unlink error code. */ - if (!ret) ret = ret2; + if (ret2) { + LOGE(ERROR, "%s: failed to remove device-model state %s", + dmss->spawn.what, state->saved_state); + rc = ERROR_FAIL; + goto out; + } } - return ret; + + rc = 0; + + out: + dmss->callback(egc, dmss, rc); } int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid) @@ -1131,15 +1181,6 @@ out: return ret; } -int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid, - libxl_domain_config *guest_config, - libxl__domain_build_state *state, - libxl__spawner_starting **starting_r) -{ - libxl__create_device_model(gc, domid, guest_config, state, starting_r); - return 0; -} - /* * Local variables: * mode: C diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index 2ee2154..882c048 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -127,29 +127,35 @@ void libxl_report_child_exitstatus(libxl_ctx *ctx, } } -void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild) +int libxl__spawn_record_pid(libxl__gc *gc, libxl__spawn_state *spawn, + pid_t innerchild) { - libxl__spawner_starting *starting = for_spawn; - struct xs_handle *xsh; - char *path = NULL, *pid = NULL; - int len; - - if (asprintf(&path, "%s/%s", starting->dom_path, starting->pid_path) < 0) - goto out; + struct xs_handle *xsh = NULL; + const char *pid = NULL; + int rc, xsok; - len = asprintf(&pid, "%d", innerchild); - if (len < 0) - goto out; + pid = GCSPRINTF("%d", innerchild); /* we mustn't use the parent's handle in the child */ xsh = xs_daemon_open(); + if (!xsh) { + LOGE(ERROR, "write %s = %s: xenstore reopen failed", + spawn->pidpath, pid); + rc = ERROR_FAIL; goto out; + } - xs_write(xsh, XBT_NULL, path, pid, len); + xsok = xs_write(xsh, XBT_NULL, spawn->pidpath, pid, strlen(pid)); + if (!xsok) { + LOGE(ERROR, + "write %s = %s: xenstore write failed", spawn->pidpath, pid); + rc = ERROR_FAIL; goto out; + } + + rc = 0; - xs_daemon_close(xsh); out: - free(path); - free(pid); + if (xsh) xs_daemon_close(xsh); + return rc ? SIGTERM : 0; } int libxl__wait_for_offspring(libxl__gc *gc, @@ -184,19 +190,9 @@ int libxl__wait_for_offspring(libxl__gc *gc, tv.tv_sec = timeout; tv.tv_usec = 0; nfds = xs_fileno(xsh) + 1; - if (spawning && spawning->fd > xs_fileno(xsh)) - nfds = spawning->fd + 1; + assert(!spawning); while (rc > 0 || (!rc && tv.tv_sec > 0)) { - if ( spawning ) { - rc = libxl__spawn_check(gc, spawning); - if ( rc ) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, - "%s died during startup", what); - rc = -1; - goto err_died; - } - } p = xs_read(xsh, XBT_NULL, path, &len); if ( NULL == p ) goto again; @@ -218,8 +214,6 @@ again: free(p); FD_ZERO(&rfds); FD_SET(xs_fileno(xsh), &rfds); - if (spawning) - FD_SET(spawning->fd, &rfds); rc = select(nfds, &rfds, NULL, NULL, &tv); if (rc > 0) { if (FD_ISSET(xs_fileno(xsh), &rfds)) { @@ -229,207 +223,215 @@ again: else goto again; } - if (spawning && FD_ISSET(spawning->fd, &rfds)) { - unsigned char dummy; - if (read(spawning->fd, &dummy, sizeof(dummy)) != 1) - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG, - "failed to read spawn status pipe"); - } } } LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s not ready", what); -err_died: + xs_unwatch(xsh, path, path); xs_daemon_close(xsh); err: return -1; } -static int detach_offspring(libxl__gc *gc, - libxl__spawner_starting *starting) -{ - int rc; - rc = libxl__spawn_detach(gc, starting->for_spawn); - if (starting->for_spawn) - free(starting->for_spawn); - free(starting); - return rc; -} -int libxl__spawn_confirm_offspring_startup(libxl__gc *gc, - uint32_t timeout, char *what, - char *path, char *state, - libxl__spawner_starting *starting) -{ - int detach; - int problem = libxl__wait_for_offspring(gc, starting->domid, timeout, what, - path, state, - starting->for_spawn, NULL, NULL); - detach = detach_offspring(gc, starting); - return problem ? problem : detach; -} +/*----- spawn implementation -----*/ -static int libxl__set_fd_flag(libxl__gc *gc, int fd, int flag) -{ - int flags; +/* + * Full set of possible states of a libxl__spawn_state and its _detachable: + * + * ss-> ss-> ss-> | ssd-> ssd-> + * timeout xswatch ssd | mid ss + * - Undefined undef undef no | - - + * - Idle Idle Idle no | - - + * - Active Active Active yes | Active yes + * - Partial Active/Idle Active/Idle maybe | Active/Idle yes (if exists) + * - Detached - - - | Active no + * + * When in state Detached, the middle process has been sent a SIGKILL. + */ - flags = fcntl(fd, F_GETFL); - if (flags == -1) - return ERROR_FAIL; +/* Event callbacks. */ +static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw, + const char *watch_path, const char *event_path); +static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs); +static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw, + pid_t pid, int status); - flags |= flag; +/* Precondition: Partial. Results: Detached. */ +static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss); - if (fcntl(fd, F_SETFL, flags) == -1) - return ERROR_FAIL; +/* Precondition: Partial; caller has logged failure reason. + * Results: Caller notified of failure; + * after return, ss may be completely invalid as caller may reuse it */ +static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss); - return 0; +void libxl__spawn_init(libxl__spawn_state *ss) +{ + libxl__ev_time_init(&ss->timeout); + libxl__ev_xswatch_init(&ss->xswatch); + ss->ssd = 0; } -int libxl__spawn_spawn(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - const char *what, - void (*intermediate_hook)(void *for_spawn, - pid_t innerchild), - void *hook_data) +int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *ss) { - libxl_ctx *ctx = libxl__gc_owner(gc); - pid_t child, got; + STATE_AO_GC(ss->ao); + int r; + pid_t child; int status, rc; - pid_t intermediate; - int pipes[2]; - unsigned char dummy = 0; - - if (for_spawn) { - for_spawn->what = strdup(what); - if (!for_spawn->what) return ERROR_NOMEM; - - if (libxl_pipe(ctx, pipes) < 0) - goto err_parent; - if (libxl__set_fd_flag(gc, pipes[0], O_NONBLOCK) < 0 || - libxl__set_fd_flag(gc, pipes[1], O_NONBLOCK) < 0) - goto err_parent_pipes; - } - intermediate = libxl_fork(ctx); - if (intermediate ==-1) - goto err_parent_pipes; + libxl__spawn_init(ss); + ss->ssd = libxl__zalloc(0, sizeof(*ss->ssd)); + libxl__ev_child_init(&ss->ssd->mid); + + rc = libxl__ev_time_register_rel(gc, &ss->timeout, + spawn_timeout, ss->timeout_ms); + if (rc) goto out_err; - if (intermediate) { + rc = libxl__ev_xswatch_register(gc, &ss->xswatch, + spawn_watch_event, ss->xspath); + if (rc) goto out_err; + + pid_t middle = libxl__ev_child_fork(gc, &ss->ssd->mid, spawn_middle_death); + if (middle ==-1) { rc = ERROR_FAIL; goto out_err; } + + if (middle) { /* parent */ - if (for_spawn) { - for_spawn->intermediate = intermediate; - for_spawn->fd = pipes[0]; - close(pipes[1]); - } return 1; } - /* we are now the intermediate process */ - if (for_spawn) close(pipes[0]); + /* we are now the middle process */ child = fork(); if (child == -1) exit(255); if (!child) { - if (for_spawn) close(pipes[1]); return 0; /* caller runs child code */ } - intermediate_hook(hook_data, child); - - if (!for_spawn) _exit(0); /* just detach then */ - - got = waitpid(child, &status, 0); - assert(got == child); - - rc = (WIFEXITED(status) ? WEXITSTATUS(status) : - WIFSIGNALED(status) && WTERMSIG(status) < 127 - ? WTERMSIG(status)+128 : -1); - if (for_spawn) { - if (write(pipes[1], &dummy, sizeof(dummy)) != 1) - perror("libxl__spawn_spawn: unable to signal child exit to parent"); + int failsig = ss->midproc_cb(gc, ss, child); + if (failsig) { + kill(child, failsig); + _exit(127); } - _exit(rc); - err_parent_pipes: - if (for_spawn) { - close(pipes[0]); - close(pipes[1]); + for (;;) { + pid_t got = waitpid(child, &status, 0); + if (got == -1) { + assert(errno == EINTR); + continue; + } + assert(got == child); + break; } - err_parent: - if (for_spawn) free(for_spawn->what); + r = (WIFEXITED(status) && WEXITSTATUS(status) <= 127 ? WEXITSTATUS(status) : + WIFSIGNALED(status) && WTERMSIG(status) < 127 ? WTERMSIG(status)+128 : + -1); + _exit(r); - return ERROR_FAIL; + out_err: + spawn_cleanup(gc, ss); + return rc; } -static void report_spawn_intermediate_status(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - int status) +static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss) { - if (!WIFEXITED(status)) { - libxl_ctx *ctx = libxl__gc_owner(gc); - char *intermediate_what; - /* intermediate process did the logging itself if it exited */ - if ( asprintf(&intermediate_what, - "%s intermediate process (startup monitor)", - for_spawn->what) < 0 ) - intermediate_what = "intermediate process (startup monitor)"; - libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR, intermediate_what, - for_spawn->intermediate, status); + int r; + + libxl__ev_time_deregister(gc, &ss->timeout); + libxl__ev_xswatch_deregister(gc, &ss->xswatch); + + libxl__spawn_state_detachable *ssd = ss->ssd; + if (ssd) { + if (libxl__ev_child_inuse(&ssd->mid)) { + pid_t child = ssd->mid.pid; + r = kill(child, SIGKILL); + if (r && errno != ESRCH) + LOGE(WARN, "%s: failed to kill intermediate child (pid=%lu)", + ss->what, (unsigned long)child); + } + + /* disconnect the ss and ssd from each other */ + ssd->ss = 0; + ss->ssd = 0; } } -int libxl__spawn_detach(libxl__gc *gc, - libxl__spawn_starting *for_spawn) +static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss) { - libxl_ctx *ctx = libxl__gc_owner(gc); - int r, status; - pid_t got; - int rc = 0; + EGC_GC; + spawn_cleanup(gc, ss); + ss->failure_cb(egc, ss); /* must be last; callback may do anything to ss */ +} - if (!for_spawn) return 0; +static void spawn_timeout(libxl__egc *egc, libxl__ev_time *ev, + const struct timeval *requested_abs) +{ + /* Before event, was Active; is now Partial. */ + EGC_GC; + libxl__spawn_state *ss = CONTAINER_OF(ev, *ss, timeout); + LOG(ERROR, "%s: startup timed out", ss->what); + spawn_failed(egc, ss); /* must be last */ +} - if (for_spawn->intermediate) { - r = kill(for_spawn->intermediate, SIGKILL); - if (r) { - LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, - "could not kill %s intermediate process [%ld]", - for_spawn->what, - (unsigned long)for_spawn->intermediate); - abort(); /* things are very wrong */ - } - got = waitpid(for_spawn->intermediate, &status, 0); - assert(got == for_spawn->intermediate); - if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) { - report_spawn_intermediate_status(gc, for_spawn, status); - rc = ERROR_FAIL; - } - for_spawn->intermediate = 0; +static void spawn_watch_event(libxl__egc *egc, libxl__ev_xswatch *xsw, + const char *watch_path, const char *event_path) +{ + /* On entry, is Active. */ + EGC_GC; + libxl__spawn_state *ss = CONTAINER_OF(xsw, *ss, xswatch); + char *p = libxl__xs_read(gc, 0, ss->xspath); + if (!p && errno != ENOENT) { + LOG(ERROR, "%s: xenstore read of %s failed", ss->what, ss->xspath); + spawn_failed(egc, ss); /* must be last */ + return; } - - free(for_spawn->what); - for_spawn->what = 0; - - return rc; + ss->confirm_cb(egc, ss, p); /* must be last */ } -int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn) +static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw, + pid_t pid, int status) + /* Before event, was Active or Detached; + * is now Active or Detached except that ssd->mid is Idle */ { - pid_t got; - int status; - - if (!for_spawn) return 0; + EGC_GC; + libxl__spawn_state_detachable *ssd = CONTAINER_OF(childw, *ssd, mid); + libxl__spawn_state *ss = ssd->ss; - assert(for_spawn->intermediate); - got = waitpid(for_spawn->intermediate, &status, WNOHANG); - if (!got) return 0; - - assert(got == for_spawn->intermediate); - report_spawn_intermediate_status(gc, for_spawn, status); + if (!WIFEXITED(status)) { + const char *what = + GCSPRINTF("%s intermediate process (startup monitor)", + ss ? ss->what : "(detached)"); + int loglevel = ss ? XTL_ERROR : XTL_WARN; + libxl_report_child_exitstatus(CTX, loglevel, what, pid, status); + } else if (ss) { /* otherwise it was supposed to be a daemon by now */ + if (!status) + LOG(ERROR, "%s [%ld]: unexpectedly exited with exit status 0," + " when we were waiting for it to confirm startup", + ss->what, (unsigned long)pid); + else if (status <= 127) + LOG(ERROR, "%s [%ld]: failed startup with non-zero exit status %d", + ss->what, (unsigned long)pid, status); + else if (status < 255) { + int sig = status - 128; + const char *str = strsignal(sig); + if (str) + LOG(ERROR, "%s [%ld]: died during startup due to fatal" + " signal %s", ss->what, (unsigned long)pid, str); + else + LOG(ERROR, "%s [%ld]: died during startup due to unknown fatal" + " signal number %d", ss->what, (unsigned long)pid, sig); + } + ss->ssd = 0; /* detatch the ssd to make the ss be in state Partial */ + spawn_failed(egc, ss); /* must be last use of ss */ + } + free(ssd); +} - for_spawn->intermediate = 0; - return ERROR_FAIL; +void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state *ss) +{ + spawn_cleanup(gc, ss); } /* diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6fb99f6..dc84881 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -847,75 +847,198 @@ _hidden int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int num); _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid); -/* xl_exec */ +/* + *----- spawn ----- + * + * Higher-level double-fork and separate detach eg as for device models + * + * Each libxl__spawn_state is in one of the conventional states + * Undefined, Idle, Active + */ - /* higher-level double-fork and separate detach eg as for device models */ +typedef struct libxl__obsolete_spawn_starting libxl__spawn_starting; +/* this type is never defined, so no objects of this type exist + * fixme-ao This should go away completely. */ -typedef struct { - /* put this in your own status structure as returned to application */ - /* all fields are private to libxl_spawn_... */ - pid_t intermediate; - int fd; - char *what; /* malloc'd in spawn_spawn */ -} libxl__spawn_starting; +typedef struct libxl__spawn_state libxl__spawn_state; -typedef struct { - char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */ - const char *pid_path; /* only for libxl_spawner_record_pid */ - int domid; - libxl__spawn_starting *for_spawn; -} libxl__spawner_starting; +/* Clears out a spawn state; idempotent. */ +_hidden void libxl__spawn_init(libxl__spawn_state*); /* - * libxl__spawn_spawn - Create a new process - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * what: string describing the spawned process - * intermediate_hook: helper to record pid, such as libxl_spawner_record_pid - * hook_data: data to pass to the hook function + * libxl__spawn_spawn - Create a new process which will become daemonic + * Forks twice, to allow the child to detach entirely from the parent. + * + * We call the two generated processes the "middle child" (result of + * the first fork) and the "inner child" (result of the second fork + * which takes place in the middle child). + * + * The inner child must soon exit or exec. It must also soon exit or + * notify the parent of its successful startup by writing to the + * xenstore path xspath. + * + * The user (in the parent) will be called back (confirm_cb) every + * time that xenstore path is modified. + * + * In both children, the ctx is not fully usable: gc and logging + * operations are OK, but operations on Xen and xenstore are not. + * (The restrictions are the same as those which apply to children + * made with libxl__ev_child_fork.) + * + * midproc_cb will be called in the middle child, with the pid of the + * inner child; this could for example record the pid. midproc_cb + * should be fast, and should return. It will be called (reentrantly) + * within libxl__spawn_init. + * + * failure_cb will be called in the parent on failure of the + * intermediate or final child; an error message will have been + * logged. + * + * confirm_cb and failure_cb will not be called reentrantly from + * within libxl__spawn_spawn. + * + * what: string describing the spawned process, used for logging * * Logs errors. A copy of "what" is taken. * Return values: - * < 0 error, for_spawn need not be detached - * +1 caller is the parent, must call detach on *for_spawn eventually + * < 0 error, *spawn is now Idle and need not be detached + * +1 caller is the parent, *spawn is Active and must eventually be detached * 0 caller is now the inner child, should probably call libxl__exec - * Caller, may pass 0 for for_spawn, in which case no need to detach. + * + * The spawn state must be Undefined or Idle on entry. */ -_hidden int libxl__spawn_spawn(libxl__gc *gc, - libxl__spawn_starting *for_spawn, - const char *what, - void (*intermediate_hook)(void *for_spawn, pid_t innerchild), - void *hook_data); +_hidden int libxl__spawn_spawn(libxl__egc *egc, libxl__spawn_state *spawn); /* - * libxl_spawner_record_pid - Record given pid in xenstore - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * innerchild: pid of the child + * libxl__spawn_detach - Detaches the daemonic child. + * + * Works by killing the intermediate process from spawn_spawn. + * After this function returns, failures of either child are no + * longer reported via failure_cb. + * + * If called before the inner child has been created, this may prevent + * it from running at all. Thus this should be called only when the + * inner child has notified that it is ready. Normally it will be + * called from within confirm_cb. * - * This function is passed as intermediate_hook to libxl__spawn_spawn. + * Logs errors. + * + * The spawn state must be Active or Idle on entry and will be Idle + * on return. */ -_hidden void libxl_spawner_record_pid(void *for_spawn, pid_t innerchild); +_hidden void libxl__spawn_detach(libxl__gc *gc, libxl__spawn_state*); /* - * libxl__spawn_confirm_offspring_startup - Wait for child state - * gc: allocation pool - * timeout: how many seconds to wait for the child - * what: string describing the spawned process - * path: path to the state file in xenstore - * state: expected string to wait for in path (optional) - * starting: malloc'd pointer to libxl__spawner_starting + * If successful, this should return 0. * - * Returns 0 on success, and < 0 on error. + * Otherwise it should return a signal number, which will be + * sent to the inner child; the overall spawn will then fail. + */ +typedef int /* signal number */ +libxl__spawn_midproc_cb(libxl__gc*, libxl__spawn_state*, pid_t inner); + +/* + * Called if the spawn failed. The reason will have been logged. + * The spawn state will be Idle on entry to the callback (and + * it may be reused immediately if desired). + */ +typedef void libxl__spawn_failure_cb(libxl__egc*, libxl__spawn_state*); + +/* + * Called when the xspath watch triggers. xspath will have been read + * and the result placed in xsdata; if that failed because the key + * didn't exist, xspath==0. (If it failed for some other reason, + * the spawn machinery calls failure_cb instead.) * - * This function waits the given timeout for the given path to appear - * in xenstore, and optionally for state in path. - * The intermediate process created in libxl__spawn_spawn is killed. - * The memory referenced by starting->for_spawn and starting is free'd. + * If the child has indicated its successful startup, or a failure + * has occurred, this should call libxl__spawn_detach. + * + * If the child is still starting up, should simply return, doing + * nothing. + * + * The spawn state will be Active on entry to the callback; there + * are no restrictions on the state on return; it may even have + * been detached and reused. */ -_hidden int libxl__spawn_confirm_offspring_startup(libxl__gc *gc, - uint32_t timeout, char *what, - char *path, char *state, - libxl__spawner_starting *starting); +typedef void libxl__spawn_confirm_cb(libxl__egc*, libxl__spawn_state*, + const char *xsdata); + +typedef struct { + /* Private to the spawn implementation. + */ + /* This separate struct, from malloc, allows us to "detach" + * the child and reap it later, when our user has gone + * away and freed its libxl__spawn_state */ + struct libxl__spawn_state *ss; + libxl__ev_child mid; +} libxl__spawn_state_detachable; + +struct libxl__spawn_state { + /* must be filled in by user and remain valid */ + libxl__ao *ao; + const char *what; + const char *xspath; + const char *pidpath; /* only used by libxl__spawn_midproc_record_pid */ + int timeout_ms; /* -1 means forever */ + libxl__spawn_midproc_cb *midproc_cb; + libxl__spawn_failure_cb *failure_cb; + libxl__spawn_confirm_cb *confirm_cb; + + /* remaining fields are private to libxl_spawn_... */ + libxl__ev_time timeout; + libxl__ev_xswatch xswatch; + libxl__spawn_state_detachable *ssd; +}; + +static inline int libxl__spawn_inuse(libxl__spawn_state *ss) + { return !!ss->ssd; } + +/* + * libxl_spawner_record_pid - Record given pid in xenstore + * + * This function can be passed directly as an intermediate_hook to + * libxl__spawn_spawn. On failure, returns the value SIGTERM. + */ +_hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*, + pid_t innerchild); + +/*----- device model creation -----*/ + +/* First layer; wraps libxl__spawn_spawn. */ + +typedef struct libxl__dm_spawn_state libxl__dm_spawn_state; + +typedef void libxl__dm_spawn_cb(libxl__egc *egc, libxl__dm_spawn_state*, + int rc /* if !0, error was logged */); + +struct libxl__dm_spawn_state { + /* mixed - spawn.ao must be initialised by user; rest is private: */ + libxl__spawn_state spawn; + /* filled in by user, must remain valid: */ + uint32_t guest_domid; /* domain being served */ + libxl_domain_config *guest_config; + libxl__domain_build_state *build_state; /* relates to guest_domid */ + libxl__dm_spawn_cb *callback; +}; + +_hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*); + +/* Stubdom device models. */ + +typedef struct { + /* Mixed - user must fill in public parts EXCEPT callback, + * which may be undefined on entry. (See above for details) */ + libxl__dm_spawn_state dm; /* the stub domain device model */ + /* filled in by user, must remain valid: */ + libxl__dm_spawn_cb *callback; /* called as callback(,&sdss->dm,) */ + /* private to libxl__spawn_stub_dm: */ + libxl_domain_config dm_config; + libxl__domain_build_state dm_state; + libxl__dm_spawn_state pvqemu; +} libxl__stub_dm_spawn_state; + +_hidden void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state*); + /* * libxl__wait_for_offspring - Wait for child state @@ -948,31 +1071,6 @@ _hidden int libxl__wait_for_offspring(libxl__gc *gc, void *userdata), void *check_callback_userdata); -/* - * libxl__spawn_detach - Kill intermediate process from spawn_spawn - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * - * Returns 0 on success, and < 0 on error. - * - * Logs errors. Idempotent, but only permitted after successful - * call to libxl__spawn_spawn, and no point calling it again if it fails. - */ -_hidden int libxl__spawn_detach(libxl__gc *gc, - libxl__spawn_starting *for_spawn); - -/* - * libxl__spawn_check - Check intermediate child process - * gc: allocation pool - * for_spawn: malloc'd pointer to libxl__spawn_starting (optional) - * - * Returns 0 on success, and < 0 on error. - * - * Logs errors but also returns them. - * Caller must still call detach. - */ -_hidden int libxl__spawn_check(libxl__gc *gc, - libxl__spawn_starting *for_spawn); /* low-level stuff, for synchronous subprocesses etc. */ @@ -991,15 +1089,6 @@ _hidden int libxl__domain_build(libxl__gc *gc, /* for device model creation */ _hidden const char *libxl__domain_device_model(libxl__gc *gc, const libxl_domain_build_info *info); -_hidden int libxl__create_device_model(libxl__gc *gc, - int domid, - libxl_domain_config *guest_config, - 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__domain_build_state *state, - libxl__spawner_starting **starting_r); _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, int nr_consoles, libxl__device_console *consoles, int nr_vfbs, libxl_device_vfb *vfbs, @@ -1007,10 +1096,6 @@ _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, /* Caller must either: pass starting_r==0, or on successful * 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__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, uint32_t domid, char *state, libxl__spawn_starting *spawning, @@ -1581,6 +1666,31 @@ _hidden void libxl__bootloader_init(libxl__bootloader_state *bl); _hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); +/*----- Domain creation -----*/ + +typedef struct libxl__domain_create_state libxl__domain_create_state; + +typedef void libxl__domain_create_cb(libxl__egc *egc, + libxl__domain_create_state*, + int rc, uint32_t domid); + +struct libxl__domain_create_state { + /* filled in by user */ + libxl__ao *ao; + libxl_domain_config *guest_config; + int restore_fd; + libxl_console_ready console_cb; + void *console_cb_priv; + libxl__domain_create_cb *callback; + /* private to domain_create */ + int guest_domid; + libxl__domain_build_state build_state; + libxl__stub_dm_spawn_state dmss; + /* If we're not doing stubdom, we use only dmss.dm, + * for the non-stubdom device model. */ +}; + + /* * Convenience macros. */ diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 45e2c30..621aeaf 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1695,8 +1695,8 @@ start: if ( restore_file ) { ret = libxl_domain_create_restore(ctx, &d_config, - cb, &child_console_pid, - &domid, restore_fd); + cb, &child_console_pid, + &domid, restore_fd, 0); /* * On subsequent reboot etc we should create the domain, not * restore/migrate-receive it again. @@ -1704,7 +1704,7 @@ start: restore_file = NULL; }else{ ret = libxl_domain_create_new(ctx, &d_config, - cb, &child_console_pid, &domid); + cb, &child_console_pid, &domid, 0); } if ( ret ) goto error_out; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006YC-Sz; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wa-F5 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.143.35:57375] by server-1.bemta-4.messagelabs.com id 13/B9-20925-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25712 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435463" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hk-Sl; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eQ-Q7; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:51 +0100 Message-ID: <1336759092-2432-7-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 06/27] libxl: provide libxl__remove_file et al. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These utility functions cope with EINTR AND ENOENT, do error logging, and we provide a recursive version to delete whole directory trees. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 7 ++++ tools/libxl/libxl_utils.c | 79 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 86 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index d04e856..909e01f 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -433,6 +433,13 @@ _hidden char *libxl__strndup(libxl__gc *gc_opt, const char *c, size_t n); * string. (similar to a gc'd dirname(3)). */ _hidden char *libxl__dirname(libxl__gc *gc_opt, const char *s); +/* Each of these logs errors and returns a libxl error code. + * They do not mind if path is already removed. + * For _file, path must not be a directory; for _directory it must be. */ +_hidden int libxl__remove_file(libxl__gc *gc, const char *path); +_hidden int libxl__remove_directory(libxl__gc *gc, const char *path); +_hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path); + _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t, diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 0cbd85e..1a4874c 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -364,6 +364,85 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, READ_WRITE_EXACTLY(read, 1, /* */) READ_WRITE_EXACTLY(write, 0, const) +int libxl__remove_file(libxl__gc *gc, const char *path) +{ + for (;;) { + int r = unlink(path); + if (!r) return 0; + if (errno == ENOENT) return 0; + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove file %s", path); + return ERROR_FAIL; + } +} + +int libxl__remove_file_or_directory(libxl__gc *gc, const char *path) +{ + for (;;) { + int r = rmdir(path); + if (!r) return 0; + if (errno == ENOENT) return 0; + if (errno == ENOTEMPTY) return libxl__remove_directory(gc, path); + if (errno == ENOTDIR) return libxl__remove_file(gc, path); + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove %s", path); + return ERROR_FAIL; + } +} + +int libxl__remove_directory(libxl__gc *gc, const char *dirpath) +{ + int rc = 0; + DIR *d = 0; + + d = opendir(dirpath); + if (!d) { + if (errno == ENOENT) + goto out; + + LOGE(ERROR, "failed to opendir %s for removal", dirpath); + rc = ERROR_FAIL; + goto out; + } + + size_t need = offsetof(struct dirent, d_name) + + pathconf(dirpath, _PC_NAME_MAX) + 1; + struct dirent *de_buf = libxl__zalloc(gc, need); + struct dirent *de; + + for (;;) { + int r = readdir_r(d, de_buf, &de); + if (r) { + LOGE(ERROR, "failed to readdir %s for removal", dirpath); + rc = ERROR_FAIL; + break; + } + if (!de) + break; + + if (!strcmp(de->d_name, ".") || + !strcmp(de->d_name, "..")) + continue; + + const char *subpath = GCSPRINTF("%s/%s", dirpath, de->d_name); + if (libxl__remove_file_or_directory(gc, subpath)) + rc = ERROR_FAIL; + } + + for (;;) { + int r = rmdir(dirpath); + if (!r) break; + if (errno == ENOENT) goto out; + if (errno == EINTR) continue; + LOGE(ERROR, "failed to remove emptied directory %s", dirpath); + rc = ERROR_FAIL; + } + + out: + if (d) closedir(d); + + return rc; +} pid_t libxl_fork(libxl_ctx *ctx) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6i-0006b0-Ux; Fri, 11 May 2012 17:58:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006W1-5e for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.139.83:4139] by server-2.bemta-5.messagelabs.com id 18/9B-17016-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!10 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30213 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IE-Fw; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000g3-Da; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:00 +0100 Message-ID: <1336759092-2432-16-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Campbell Subject: [Xen-devel] [PATCH 15/27] libxl: add a dummy ao_how to libxl_domain_core_dump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Ian Campbell Although this function is not currently slow it may become so in the future (this also depends somewhat on the size of the guest). Therefore arrange for it to take an ao_how which it completes immediately. This will allow us to make it asynchronous in the future without breaking API compatibility. Signed-off-by: Ian Campbell Acked-by: Ian Jackson --- tools/libxl/libxl.c | 18 ++++++++++++++---- tools/libxl/libxl.h | 4 +++- tools/libxl/xl_cmdimpl.c | 4 ++-- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index d5fb186..482adaa 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -642,16 +642,26 @@ int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid) } int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, - const char *filename) + const char *filename, + const libxl_asyncop_how *ao_how) { - int ret; + AO_CREATE(ctx, domid, ao_how); + int ret, rc; + ret = xc_domain_dumpcore(ctx->xch, domid, filename); if (ret<0) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "core dumping domain %d to %s", domid, filename); - return ERROR_FAIL; + rc = ERROR_FAIL; + goto out; } - return 0; + + rc = 0; +out: + + libxl__ao_complete(egc, ao, rc); + + return AO_INPROGRESS; } int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 3087146..d8dbb1e 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -511,7 +511,9 @@ int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid, int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid); int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid); -int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char *filename); +int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, + const char *filename, + const libxl_asyncop_how *ao_how); int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint32_t target_memkb); int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int32_t target_memkb, int relative, int enforce); diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index c1cab9e..45e2c30 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1306,7 +1306,7 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, LOG("failed to construct core dump path"); } else { LOG("dumping core to %s", corefile); - rc=libxl_domain_core_dump(ctx, domid, corefile); + rc=libxl_domain_core_dump(ctx, domid, corefile, NULL); if (rc) LOG("core dump failed (rc=%d).", rc); } /* No point crying over spilled milk, continue on failure. */ @@ -2927,7 +2927,7 @@ static void core_dump_domain(const char *domain_spec, const char *filename) { int rc; find_domain(domain_spec); - rc=libxl_domain_core_dump(ctx, domid, filename); + rc=libxl_domain_core_dump(ctx, domid, filename, NULL); if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6m-0006f5-64; Fri, 11 May 2012 17:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-2I for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57424] by server-1.bemta-4.messagelabs.com id 85/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25786 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435478" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ic-0i; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000ga-UL; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:08 +0100 Message-ID: <1336759092-2432-24-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 23/27] libxl: remove malloc failure handling from NEW_EVENT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Change to use libxl__zalloc, where allocation failure is fatal. Also remove a spurious semicolon from the helper macro. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl.c | 2 -- tools/libxl/libxl_event.c | 8 +------- tools/libxl/libxl_internal.h | 4 ++-- 3 files changed, 3 insertions(+), 11 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 482adaa..4d01cf8 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -789,7 +789,6 @@ static void domain_death_occurred(libxl__egc *egc, *evg_upd = evg_next; libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid); - if (!ev) return; libxl__event_occurred(egc, ev); @@ -876,7 +875,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w, 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"); diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 460ef66..63719b2 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -989,13 +989,7 @@ libxl_event *libxl__event_new(libxl__egc *egc, { 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 = libxl__zalloc(0,sizeof(*ev)); ev->type = type; ev->domid = domid; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index d5cf69a..a407317 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -654,10 +654,10 @@ _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. */ + * Cannot fail. */ #define NEW_EVENT(egc, type, domid) \ - libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid)); + libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid)) /* Convenience macro. */ /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6c-0006WG-Ru; Fri, 11 May 2012 17:58:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W1-1V for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:16158] by server-2.bemta-5.messagelabs.com id 8B/8B-17016-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30078 invoked from network); 11 May 2012 17:58:16 -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 May 2012 17:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435458" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HV-Er; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000dy-Dl; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 18:57:45 +0100 Message-ID: <1336759092-2432-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 v9 00/27] libxl: child process handling X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org All of these patches have now been acked and tested. Thanks are due to to Ian Campbell and Roger Pau Monne. I am posting them in their final form and will apply them very shortly. 01/27 libxl: handle POLLERR, POLLHUP, POLLNVAL properly 02/27 libxl: support multiple libxl__ev_fds for the same fd 03/27 libxl: event API: new facilities for waiting for subprocesses 04/27 autoconf: trim the configure script; use autoheader 05/27 autoconf: New test for openpty et al. 06/27 libxl: provide libxl__remove_file et al. 07/27 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds 08/27 libxl: Clean up setdefault in do_domain_create 09/27 libxl: provide libxl__datacopier_* 10/27 libxl: provide libxl__openpty_* 11/27 libxl: ao: Convert libxl_run_bootloader 12/27 libxl: make libxl_create_logfile const-correct 13/27 libxl: log bootloader output 14/27 libxl: Allow AO_GC and EGC_GC even if not used 15/27 libxl: add a dummy ao_how to libxl_domain_core_dump 16/27 libxl: remove ctx->waitpid_instead 17/27 libxl: change some structures to unit arrays 18/27 libxl: ao: convert libxl__spawn_* 19/27 libxl: set guest_domid even if libxl__domain_make fails 20/27 libxl: make libxl_create run bootloader via callback 21/27 libxl: Fix an ao completion bug; document locking policy 22/27 libxl: provide progress reporting for long-running operations 23/27 libxl: remove malloc failure handling from NEW_EVENT 24/27 libxl: convert console callback to libxl_asyncprogress_how 25/27 libxl: clarify definition of "slow" operation 26/27 libxl: child processes cleanups 27/27 libxl: abort bootloader invocation when domain dies _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006Xn-Gr; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6d-0006W1-M2 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:16264] by server-2.bemta-5.messagelabs.com id 73/9B-17016-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30154 invoked from network); 11 May 2012 17:58:18 -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 May 2012 17:58:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435462" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hj-QF; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eM-OE; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 18:57:50 +0100 Message-ID: <1336759092-2432-6-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 05/27] autoconf: New test for openpty et al. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We may need to #include , and/or link with -lutil, to use openpty, login_tty, and the like. Provide INCLUDE_LIBUTIL_H (preprocessor constant, not always defined) and PTYFUNCS_LIBS (makefile variable). We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather than UTIL_LIBS, and #include where appropriate. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * Actually include the call to AX_CHECK_PTYFUNCS in this patch, not the previous one, and regenerate configure accordingly. Changes since v6: * Put failure macro call in correct place so it might actually happen. * Try both with -lutil and without. * Patch now contains update for config.h.in. --- config/Tools.mk.in | 2 + tools/config.h.in | 3 ++ tools/configure | 61 ++++++++++++++++++++++++++++++++++++++++ tools/configure.ac | 2 + tools/libxl/Makefile | 2 +- tools/libxl/libxl_bootloader.c | 4 ++ tools/m4/ptyfuncs.m4 | 28 ++++++++++++++++++ 7 files changed, 101 insertions(+), 1 deletions(-) create mode 100644 tools/m4/ptyfuncs.m4 diff --git a/config/Tools.mk.in b/config/Tools.mk.in index ee6cda3..5b80359 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -30,6 +30,8 @@ PTHREAD_CFLAGS := @PTHREAD_CFLAGS@ PTHREAD_LDFLAGS := @PTHREAD_LDFLAGS@ PTHREAD_LIBS := @PTHREAD_LIBS@ +PTYFUNCS_LIBS := @PTYFUNCS_LIBS@ + # Download GIT repositories via HTTP or GIT's own protocol? # GIT's protocol is faster and more robust, when it works at all (firewalls # may block it). We make it the default, but if your GIT repository downloads diff --git a/tools/config.h.in b/tools/config.h.in index 17c8913..bc1ed10 100644 --- a/tools/config.h.in +++ b/tools/config.h.in @@ -42,6 +42,9 @@ /* Define curses header to use */ #undef INCLUDE_CURSES_H +/* libutil header file name */ +#undef INCLUDE_LIBUTIL_H + /* Define to the address where bug reports for this package should be sent. */ #undef PACKAGE_BUGREPORT diff --git a/tools/configure b/tools/configure index d8918fe..be7feb6 100755 --- a/tools/configure +++ b/tools/configure @@ -598,6 +598,7 @@ ac_includes_default="\ ac_subst_vars='LTLIBOBJS LIBOBJS libiconv +PTYFUNCS_LIBS PTHREAD_LIBS PTHREAD_LDFLAGS PTHREAD_CFLAGS @@ -2308,6 +2309,8 @@ fi + + # Enable/disable options # Check whether --enable-githttp was given. @@ -6443,6 +6446,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; } + + ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default" +if test "x$ac_cv_header_libutil_h" = x""yes; then : + + +$as_echo "#define INCLUDE_LIBUTIL_H " >>confdefs.h + + +fi + + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5 +$as_echo_n "checking for openpty et al... " >&6; } +if test "${ax_cv_ptyfuncs_libs+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + + for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do + if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then + { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5 +$as_echo "$as_me: error: in \`$ac_pwd':" >&2;} +as_fn_error $? "Unable to find library for openpty and login_tty +See \`config.log' for more details" "$LINENO" 5 ; } + fi + + saved_LIBS="$LIBS" + + LIBS="$LIBS $ax_cv_ptyfuncs_libs" + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif +int main(void) { + openpty(0,0,0,0,0); + login_tty(0); +} + +_ACEOF +if ac_fn_c_try_link "$LINENO"; then : + + break + +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext + + LIBS="$saved_LIBS" + + done + +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5 +$as_echo "$ax_cv_ptyfuncs_libs" >&6; } + PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs" + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; } if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then : diff --git a/tools/configure.ac b/tools/configure.ac index deb848d..4e9cb03 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -32,6 +32,7 @@ m4_include([m4/uuid.m4]) m4_include([m4/pkg.m4]) m4_include([m4/curses.m4]) m4_include([m4/pthread.m4]) +m4_include([m4/ptyfuncs.m4]) # Enable/disable options AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP]) @@ -132,6 +133,7 @@ AC_SUBST(libext2fs) AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"]) AC_SUBST(libgcrypt) AX_CHECK_PTHREAD +AX_CHECK_PTYFUNCS AC_CHECK_LIB([yajl], [yajl_alloc], [], [AC_MSG_ERROR([Could not find yajl])]) AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 5469454..1261d43 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid endif LIBXL_LIBS = -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS) +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) CFLAGS += $(PTHREAD_CFLAGS) LDFLAGS += $(PTHREAD_LDFLAGS) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 2774062..b50944a 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -16,6 +16,10 @@ #include +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif + #include "libxl_internal.h" #define XENCONSOLED_BUF_SIZE 16 diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 new file mode 100644 index 0000000..7581704 --- /dev/null +++ b/tools/m4/ptyfuncs.m4 @@ -0,0 +1,28 @@ +AC_DEFUN([AX_CHECK_PTYFUNCS], [ + AC_CHECK_HEADER([libutil.h],[ + AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file name]) + ]) + AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ + for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do + if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then + AC_MSG_FAILURE([Unable to find library for openpty and login_tty]) + fi + AX_SAVEVAR_SAVE(LIBS) + LIBS="$LIBS $ax_cv_ptyfuncs_libs" + AC_LINK_IFELSE([ +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif +int main(void) { + openpty(0,0,0,0,0); + login_tty(0); +} +],[ + break + ],[]) + AX_SAVEVAR_RESTORE(LIBS) + done + ]) + PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs" + AC_SUBST(PTYFUNCS_LIBS) +]) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6l-0006dr-9b; Fri, 11 May 2012 17:58:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006XV-JJ for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42660] by server-1.bemta-4.messagelabs.com id 14/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25738 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435471" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I7-By; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fv-9Z; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:58 +0100 Message-ID: <1336759092-2432-14-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 13/27] libxl: log bootloader output X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This involves adding a new log feature to libxl__datacopier, and then using it. If the bootloader exits nonzero we print the log filename in a log message from libxl. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_aoutils.c | 10 ++++++++++ tools/libxl/libxl_bootloader.c | 24 ++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 3 ++- 3 files changed, 36 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 734a5dc..91e34de 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, libxl__ev_fd_deregister(gc, &dc->toread); break; } + if (dc->log) { + int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log); + if (wrote != r) { + assert(ferror(dc->log)); + assert(errno); + LOGE(ERROR, "error logging %s", dc->copywhat); + datacopier_callback(egc, dc, 0, errno); + return; + } + } buf->used += r; dc->used += r; assert(buf->used <= sizeof(buf->buf)); diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index bdc4cb4..1534bae 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) libxl__carefd_close(bl->ptys[i].master); libxl__carefd_close(bl->ptys[i].slave); } + if (bl->display.log) { + fclose(bl->display.log); + bl->display.log = NULL; + } } static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl) @@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) { STATE_AO_GC(bl->ao); libxl_domain_build_info *info = bl->info; + uint32_t domid = bl->domid; + char *logfile_tmp = NULL; int rc, r; libxl__bootloader_init(bl); @@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) bootloader_setpaths(gc, bl); + const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid); + rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp); + if (rc) goto out; + + /* Transfer ownership of log filename to bl and the gc */ + bl->logfile = logfile_tmp; + libxl__ptr_add(gc, logfile_tmp); + logfile_tmp = NULL; + + bl->display.log = fopen(bl->logfile, "a"); + if (!bl->display.log) { + LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile); + rc = ERROR_FAIL; + goto out; + } + for (;;) { r = mkdir(bl->outputdir, 0600); if (!r) break; @@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) out: assert(rc); out_ok: + free(logfile_tmp); bootloader_callback(egc, bl, rc); } @@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, libxl__datacopier_kill(&bl->display); if (status) { + LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile); libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader", pid, status); rc = ERROR_FAIL; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index e8502c6..c5ec586 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1503,6 +1503,7 @@ struct libxl__datacopier_state { int readfd, writefd; ssize_t maxsz; const char *copywhat, *readwhat, *writewhat; /* for error msgs */ + FILE *log; /* gets a copy of everything */ libxl__datacopier_callback *callback; /* remaining fields are private to datacopier */ libxl__ev_fd toread, towrite; @@ -1565,7 +1566,7 @@ struct libxl__bootloader_state { libxl_device_disk *disk; uint32_t domid; /* private to libxl__run_bootloader */ - char *outputpath, *outputdir; + char *outputpath, *outputdir, *logfile; char *diskpath; /* not from gc, represents actually attached disk */ libxl__openpty_state openpty; libxl__openpty_result ptys[2]; /* [0] is for bootloader */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006ZN-TP; Fri, 11 May 2012 17:58:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006WB-L8 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:4103] by server-9.bemta-5.messagelabs.com id 4C/FD-09826-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!9 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30198 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435473" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IJ-IS; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000g7-Fa; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:01 +0100 Message-ID: <1336759092-2432-17-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 16/27] libxl: remove ctx->waitpid_instead X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove this obsolete hook. Callers inside libxl which create and reap children should use the mechanisms provided by the event system. (This has no functional difference since there is no way for ctx->waitpid_instead ever to become set.) Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_exec.c | 12 +++--------- tools/libxl/libxl_internal.h | 3 --- 2 files changed, 3 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index b10e79f..2ee2154 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -19,11 +19,6 @@ #include "libxl_internal.h" -static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options) -{ - return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options); -} - static void check_open_fds(const char *what) { const char *env_debug; @@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc, if (!for_spawn) _exit(0); /* just detach then */ - got = call_waitpid(ctx->waitpid_instead, child, &status, 0); + got = waitpid(child, &status, 0); assert(got == child); rc = (WIFEXITED(status) ? WEXITSTATUS(status) : @@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc, (unsigned long)for_spawn->intermediate); abort(); /* things are very wrong */ } - got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0); + got = waitpid(for_spawn->intermediate, &status, 0); assert(got == for_spawn->intermediate); if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) { report_spawn_intermediate_status(gc, for_spawn, status); @@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc, int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn) { - libxl_ctx *ctx = libxl__gc_owner(gc); pid_t got; int status; if (!for_spawn) return 0; assert(for_spawn->intermediate); - got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG); + got = waitpid(for_spawn->intermediate, &status, WNOHANG); if (!got) return 0; assert(got == for_spawn->intermediate); diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 21fe99c..6fb99f6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -325,9 +325,6 @@ struct libxl__ctx { int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */ LIBXL_LIST_HEAD(, libxl__ev_child) children; - /* This is obsolete and must be removed: */ - int (*waitpid_instead)(pid_t pid, int *status, int flags); - libxl_version_info version_info; }; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6c-0006WG-Ru; Fri, 11 May 2012 17:58:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6c-0006W1-1V for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:18 +0000 Received: from [85.158.139.83:16158] by server-2.bemta-5.messagelabs.com id 8B/8B-17016-9335DAF4; Fri, 11 May 2012 17:58:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30078 invoked from network); 11 May 2012 17:58:16 -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 May 2012 17:58:16 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435458" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:15 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008HV-Er; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000dy-Dl; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 18:57:45 +0100 Message-ID: <1336759092-2432-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 v9 00/27] libxl: child process handling X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org All of these patches have now been acked and tested. Thanks are due to to Ian Campbell and Roger Pau Monne. I am posting them in their final form and will apply them very shortly. 01/27 libxl: handle POLLERR, POLLHUP, POLLNVAL properly 02/27 libxl: support multiple libxl__ev_fds for the same fd 03/27 libxl: event API: new facilities for waiting for subprocesses 04/27 autoconf: trim the configure script; use autoheader 05/27 autoconf: New test for openpty et al. 06/27 libxl: provide libxl__remove_file et al. 07/27 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds 08/27 libxl: Clean up setdefault in do_domain_create 09/27 libxl: provide libxl__datacopier_* 10/27 libxl: provide libxl__openpty_* 11/27 libxl: ao: Convert libxl_run_bootloader 12/27 libxl: make libxl_create_logfile const-correct 13/27 libxl: log bootloader output 14/27 libxl: Allow AO_GC and EGC_GC even if not used 15/27 libxl: add a dummy ao_how to libxl_domain_core_dump 16/27 libxl: remove ctx->waitpid_instead 17/27 libxl: change some structures to unit arrays 18/27 libxl: ao: convert libxl__spawn_* 19/27 libxl: set guest_domid even if libxl__domain_make fails 20/27 libxl: make libxl_create run bootloader via callback 21/27 libxl: Fix an ao completion bug; document locking policy 22/27 libxl: provide progress reporting for long-running operations 23/27 libxl: remove malloc failure handling from NEW_EVENT 24/27 libxl: convert console callback to libxl_asyncprogress_how 25/27 libxl: clarify definition of "slow" operation 26/27 libxl: child processes cleanups 27/27 libxl: abort bootloader invocation when domain dies _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6m-0006f5-64; Fri, 11 May 2012 17:58:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006XV-2I for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57424] by server-1.bemta-4.messagelabs.com id 85/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25786 invoked from network); 11 May 2012 17:58:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435478" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ic-0i; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000ga-UL; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:08 +0100 Message-ID: <1336759092-2432-24-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 23/27] libxl: remove malloc failure handling from NEW_EVENT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Change to use libxl__zalloc, where allocation failure is fatal. Also remove a spurious semicolon from the helper macro. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl.c | 2 -- tools/libxl/libxl_event.c | 8 +------- tools/libxl/libxl_internal.h | 4 ++-- 3 files changed, 3 insertions(+), 11 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 482adaa..4d01cf8 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -789,7 +789,6 @@ static void domain_death_occurred(libxl__egc *egc, *evg_upd = evg_next; libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid); - if (!ev) return; libxl__event_occurred(egc, ev); @@ -876,7 +875,6 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w, 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"); diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 460ef66..63719b2 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -989,13 +989,7 @@ libxl_event *libxl__event_new(libxl__egc *egc, { 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 = libxl__zalloc(0,sizeof(*ev)); ev->type = type; ev->domid = domid; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index d5cf69a..a407317 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -654,10 +654,10 @@ _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. */ + * Cannot fail. */ #define NEW_EVENT(egc, type, domid) \ - libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid)); + libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid)) /* Convenience macro. */ /* -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Ym-DU; Fri, 11 May 2012 17:58:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wb-IT for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:4085] by server-5.bemta-5.messagelabs.com id B9/DB-13566-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30162 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435465" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Hs-2A; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000fa-V0; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:53 +0100 Message-ID: <1336759092-2432-9-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 08/27] libxl: Clean up setdefault in do_domain_create X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org do_domain_create called libxl__domain_create_info_setdefault twice. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_create.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 6df20ca..d501102 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -573,9 +573,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); if (ret) goto error_out; - ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); - if (ret) goto error_out; - ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6l-0006dr-9b; Fri, 11 May 2012 17:58:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006XV-JJ for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42660] by server-1.bemta-4.messagelabs.com id 14/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!4 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25738 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435471" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I7-By; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fv-9Z; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:58 +0100 Message-ID: <1336759092-2432-14-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 13/27] libxl: log bootloader output X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This involves adding a new log feature to libxl__datacopier, and then using it. If the bootloader exits nonzero we print the log filename in a log message from libxl. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_aoutils.c | 10 ++++++++++ tools/libxl/libxl_bootloader.c | 24 ++++++++++++++++++++++++ tools/libxl/libxl_internal.h | 3 ++- 3 files changed, 36 insertions(+), 1 deletions(-) diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c index 734a5dc..91e34de 100644 --- a/tools/libxl/libxl_aoutils.c +++ b/tools/libxl/libxl_aoutils.c @@ -118,6 +118,16 @@ static void datacopier_readable(libxl__egc *egc, libxl__ev_fd *ev, libxl__ev_fd_deregister(gc, &dc->toread); break; } + if (dc->log) { + int wrote = fwrite(buf->buf + buf->used, 1, r, dc->log); + if (wrote != r) { + assert(ferror(dc->log)); + assert(errno); + LOGE(ERROR, "error logging %s", dc->copywhat); + datacopier_callback(egc, dc, 0, errno); + return; + } + } buf->used += r; dc->used += r; assert(buf->used <= sizeof(buf->buf)); diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index bdc4cb4..1534bae 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -236,6 +236,10 @@ static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) libxl__carefd_close(bl->ptys[i].master); libxl__carefd_close(bl->ptys[i].slave); } + if (bl->display.log) { + fclose(bl->display.log); + bl->display.log = NULL; + } } static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl) @@ -258,6 +262,8 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) { STATE_AO_GC(bl->ao); libxl_domain_build_info *info = bl->info; + uint32_t domid = bl->domid; + char *logfile_tmp = NULL; int rc, r; libxl__bootloader_init(bl); @@ -269,6 +275,22 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) bootloader_setpaths(gc, bl); + const char *logfile_leaf = GCSPRINTF("bootloader.%"PRIu32, domid); + rc = libxl_create_logfile(CTX, logfile_leaf, &logfile_tmp); + if (rc) goto out; + + /* Transfer ownership of log filename to bl and the gc */ + bl->logfile = logfile_tmp; + libxl__ptr_add(gc, logfile_tmp); + logfile_tmp = NULL; + + bl->display.log = fopen(bl->logfile, "a"); + if (!bl->display.log) { + LOGE(ERROR, "failed to create bootloader logfile %s", bl->logfile); + rc = ERROR_FAIL; + goto out; + } + for (;;) { r = mkdir(bl->outputdir, 0600); if (!r) break; @@ -308,6 +330,7 @@ void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) out: assert(rc); out_ok: + free(logfile_tmp); bootloader_callback(egc, bl, rc); } @@ -465,6 +488,7 @@ static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, libxl__datacopier_kill(&bl->display); if (status) { + LOG(ERROR, "bootloader failed - consult logfile %s", bl->logfile); libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader", pid, status); rc = ERROR_FAIL; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index e8502c6..c5ec586 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1503,6 +1503,7 @@ struct libxl__datacopier_state { int readfd, writefd; ssize_t maxsz; const char *copywhat, *readwhat, *writewhat; /* for error msgs */ + FILE *log; /* gets a copy of everything */ libxl__datacopier_callback *callback; /* remaining fields are private to datacopier */ libxl__ev_fd toread, towrite; @@ -1565,7 +1566,7 @@ struct libxl__bootloader_state { libxl_device_disk *disk; uint32_t domid; /* private to libxl__run_bootloader */ - char *outputpath, *outputdir; + char *outputpath, *outputdir, *logfile; char *diskpath; /* not from gc, represents actually attached disk */ libxl__openpty_state openpty; libxl__openpty_result ptys[2]; /* [0] is for bootloader */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6o-0006kC-UN; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wa-LA for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42720] by server-1.bemta-4.messagelabs.com id E5/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32065 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435482" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ii-5b; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gk-3B; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:10 +0100 Message-ID: <1336759092-2432-26-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 25/27] libxl: clarify definition of "slow" operation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Update the comment in libxl_internal.h to be clearer about which application-facing libxl operations need to take an ao_how. Reported-by: Dan Magenheimer Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 29 +++++++++++++++++++++++------ 1 files changed, 23 insertions(+), 6 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 3aa0ed7..9f3f759 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1439,17 +1439,34 @@ _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 - * inside libxl, because they can cause reentrancy callbacks. + * All "slow" functions (see below for the exact definition) 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 inside libxl, because they can cause reentrancy + * callbacks. * * For the same reason functions taking an ao_how may make themselves * an egc with EGC_INIT (and they will generally want to, to be able * to immediately complete an ao during its setup). * + * + * "Slow" functions includes any that might block on a guest or an + * external script. More broadly, it includes any operations which + * are sufficiently slow that an application might reasonably want to + * initiate them, and then carry on doing something else, while the + * operation completes. That is, a "fast" function must be fast + * enough that we do not mind blocking all other management operations + * on the same host while it completes. + * + * There are certain primitive functions which make a libxl operation + * necessarily "slow" for API reasons. These are: + * - awaiting xenstore watches (although read-modify-write xenstore + * transactions are OK for fast functions) + * - spawning subprocesses + * - anything with a timeout + * + * * Lifecycle of an ao: * * - Created by libxl__ao_create (or the AO_CREATE convenience macro). -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006ZN-TP; Fri, 11 May 2012 17:58:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006WB-L8 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:4103] by server-9.bemta-5.messagelabs.com id 4C/FD-09826-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!9 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30198 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435473" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008IJ-IS; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000g7-Fa; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:01 +0100 Message-ID: <1336759092-2432-17-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 16/27] libxl: remove ctx->waitpid_instead X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Remove this obsolete hook. Callers inside libxl which create and reap children should use the mechanisms provided by the event system. (This has no functional difference since there is no way for ctx->waitpid_instead ever to become set.) Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_exec.c | 12 +++--------- tools/libxl/libxl_internal.h | 3 --- 2 files changed, 3 insertions(+), 12 deletions(-) diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c index b10e79f..2ee2154 100644 --- a/tools/libxl/libxl_exec.c +++ b/tools/libxl/libxl_exec.c @@ -19,11 +19,6 @@ #include "libxl_internal.h" -static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options) -{ - return (waitpid_cb) ? waitpid_cb(pid, status, options) : waitpid(pid, status, options); -} - static void check_open_fds(const char *what) { const char *env_debug; @@ -344,7 +339,7 @@ int libxl__spawn_spawn(libxl__gc *gc, if (!for_spawn) _exit(0); /* just detach then */ - got = call_waitpid(ctx->waitpid_instead, child, &status, 0); + got = waitpid(child, &status, 0); assert(got == child); rc = (WIFEXITED(status) ? WEXITSTATUS(status) : @@ -404,7 +399,7 @@ int libxl__spawn_detach(libxl__gc *gc, (unsigned long)for_spawn->intermediate); abort(); /* things are very wrong */ } - got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, 0); + got = waitpid(for_spawn->intermediate, &status, 0); assert(got == for_spawn->intermediate); if (!(WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL)) { report_spawn_intermediate_status(gc, for_spawn, status); @@ -421,14 +416,13 @@ int libxl__spawn_detach(libxl__gc *gc, int libxl__spawn_check(libxl__gc *gc, libxl__spawn_starting *for_spawn) { - libxl_ctx *ctx = libxl__gc_owner(gc); pid_t got; int status; if (!for_spawn) return 0; assert(for_spawn->intermediate); - got = call_waitpid(ctx->waitpid_instead, for_spawn->intermediate, &status, WNOHANG); + got = waitpid(for_spawn->intermediate, &status, WNOHANG); if (!got) return 0; assert(got == for_spawn->intermediate); diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 21fe99c..6fb99f6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -325,9 +325,6 @@ struct libxl__ctx { int sigchld_selfpipe[2]; /* [0]==-1 means handler not installed */ LIBXL_LIST_HEAD(, libxl__ev_child) children; - /* This is obsolete and must be removed: */ - int (*waitpid_instead)(pid_t pid, int *status, int flags); - libxl_version_info version_info; }; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17: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 ) id 1SSu6f-0006Xn-Gr; Fri, 11 May 2012 17:58:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6d-0006W1-M2 for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:16264] by server-2.bemta-5.messagelabs.com id 73/9B-17016-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30154 invoked from network); 11 May 2012 17:58:18 -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 May 2012 17:58:18 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435462" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hj-QF; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eM-OE; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: xen-devel@lists.xen.org Date: Fri, 11 May 2012 18:57:50 +0100 Message-ID: <1336759092-2432-6-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 05/27] autoconf: New test for openpty et al. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We may need to #include , and/or link with -lutil, to use openpty, login_tty, and the like. Provide INCLUDE_LIBUTIL_H (preprocessor constant, not always defined) and PTYFUNCS_LIBS (makefile variable). We link libxl against PTYFUNCS_LIBS (which comes from autoconf) rather than UTIL_LIBS, and #include where appropriate. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v7: * Actually include the call to AX_CHECK_PTYFUNCS in this patch, not the previous one, and regenerate configure accordingly. Changes since v6: * Put failure macro call in correct place so it might actually happen. * Try both with -lutil and without. * Patch now contains update for config.h.in. --- config/Tools.mk.in | 2 + tools/config.h.in | 3 ++ tools/configure | 61 ++++++++++++++++++++++++++++++++++++++++ tools/configure.ac | 2 + tools/libxl/Makefile | 2 +- tools/libxl/libxl_bootloader.c | 4 ++ tools/m4/ptyfuncs.m4 | 28 ++++++++++++++++++ 7 files changed, 101 insertions(+), 1 deletions(-) create mode 100644 tools/m4/ptyfuncs.m4 diff --git a/config/Tools.mk.in b/config/Tools.mk.in index ee6cda3..5b80359 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -30,6 +30,8 @@ PTHREAD_CFLAGS := @PTHREAD_CFLAGS@ PTHREAD_LDFLAGS := @PTHREAD_LDFLAGS@ PTHREAD_LIBS := @PTHREAD_LIBS@ +PTYFUNCS_LIBS := @PTYFUNCS_LIBS@ + # Download GIT repositories via HTTP or GIT's own protocol? # GIT's protocol is faster and more robust, when it works at all (firewalls # may block it). We make it the default, but if your GIT repository downloads diff --git a/tools/config.h.in b/tools/config.h.in index 17c8913..bc1ed10 100644 --- a/tools/config.h.in +++ b/tools/config.h.in @@ -42,6 +42,9 @@ /* Define curses header to use */ #undef INCLUDE_CURSES_H +/* libutil header file name */ +#undef INCLUDE_LIBUTIL_H + /* Define to the address where bug reports for this package should be sent. */ #undef PACKAGE_BUGREPORT diff --git a/tools/configure b/tools/configure index d8918fe..be7feb6 100755 --- a/tools/configure +++ b/tools/configure @@ -598,6 +598,7 @@ ac_includes_default="\ ac_subst_vars='LTLIBOBJS LIBOBJS libiconv +PTYFUNCS_LIBS PTHREAD_LIBS PTHREAD_LDFLAGS PTHREAD_CFLAGS @@ -2308,6 +2309,8 @@ fi + + # Enable/disable options # Check whether --enable-githttp was given. @@ -6443,6 +6446,64 @@ $as_echo "$ax_cv_pthread_flags" >&6; } + + ac_fn_c_check_header_mongrel "$LINENO" "libutil.h" "ac_cv_header_libutil_h" "$ac_includes_default" +if test "x$ac_cv_header_libutil_h" = x""yes; then : + + +$as_echo "#define INCLUDE_LIBUTIL_H " >>confdefs.h + + +fi + + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty et al" >&5 +$as_echo_n "checking for openpty et al... " >&6; } +if test "${ax_cv_ptyfuncs_libs+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + + for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do + if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then + { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5 +$as_echo "$as_me: error: in \`$ac_pwd':" >&2;} +as_fn_error $? "Unable to find library for openpty and login_tty +See \`config.log' for more details" "$LINENO" 5 ; } + fi + + saved_LIBS="$LIBS" + + LIBS="$LIBS $ax_cv_ptyfuncs_libs" + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif +int main(void) { + openpty(0,0,0,0,0); + login_tty(0); +} + +_ACEOF +if ac_fn_c_try_link "$LINENO"; then : + + break + +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext + + LIBS="$saved_LIBS" + + done + +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_ptyfuncs_libs" >&5 +$as_echo "$ax_cv_ptyfuncs_libs" >&6; } + PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs" + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for yajl_alloc in -lyajl" >&5 $as_echo_n "checking for yajl_alloc in -lyajl... " >&6; } if test "${ac_cv_lib_yajl_yajl_alloc+set}" = set; then : diff --git a/tools/configure.ac b/tools/configure.ac index deb848d..4e9cb03 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -32,6 +32,7 @@ m4_include([m4/uuid.m4]) m4_include([m4/pkg.m4]) m4_include([m4/curses.m4]) m4_include([m4/pthread.m4]) +m4_include([m4/ptyfuncs.m4]) # Enable/disable options AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP]) @@ -132,6 +133,7 @@ AC_SUBST(libext2fs) AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"]) AC_SUBST(libgcrypt) AX_CHECK_PTHREAD +AX_CHECK_PTYFUNCS AC_CHECK_LIB([yajl], [yajl_alloc], [], [AC_MSG_ERROR([Could not find yajl])]) AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 5469454..1261d43 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid endif LIBXL_LIBS = -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(UTIL_LIBS) $(LIBUUID_LIBS) +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) CFLAGS += $(PTHREAD_CFLAGS) LDFLAGS += $(PTHREAD_LDFLAGS) diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index 2774062..b50944a 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -16,6 +16,10 @@ #include +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif + #include "libxl_internal.h" #define XENCONSOLED_BUF_SIZE 16 diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 new file mode 100644 index 0000000..7581704 --- /dev/null +++ b/tools/m4/ptyfuncs.m4 @@ -0,0 +1,28 @@ +AC_DEFUN([AX_CHECK_PTYFUNCS], [ + AC_CHECK_HEADER([libutil.h],[ + AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file name]) + ]) + AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ + for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do + if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then + AC_MSG_FAILURE([Unable to find library for openpty and login_tty]) + fi + AX_SAVEVAR_SAVE(LIBS) + LIBS="$LIBS $ax_cv_ptyfuncs_libs" + AC_LINK_IFELSE([ +#ifdef INCLUDE_LIBUTIL_H +#include INCLUDE_LIBUTIL_H +#endif +int main(void) { + openpty(0,0,0,0,0); + login_tty(0); +} +],[ + break + ],[]) + AX_SAVEVAR_RESTORE(LIBS) + done + ]) + PTYFUNCS_LIBS="$ax_cv_ptyfuncs_libs" + AC_SUBST(PTYFUNCS_LIBS) +]) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6k-0006d4-IS; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wa-DG for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42662] by server-1.bemta-4.messagelabs.com id 54/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32033 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I2-7k; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fn-6F; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:56 +0100 Message-ID: <1336759092-2432-12-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 11/27] libxl: ao: Convert libxl_run_bootloader X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Convert libxl_run_bootloader to an ao_how-taking function. It's implemented in terms of libxl__bootloader_run, which can be used internally. The resulting code is pretty much a rewrite. Significant changes include: - We direct the bootloader's results to a file, not a pipe. This makes it simpler to deal with as we don't have to read it concurrently along with everything else. - We now issue a warning if we find unexpected statements in the bootloader results. - The arrangements for buffering of bootloader input and output are completely changed. Now we have a fixed limit of 64k on output, and 4k on input, and discard the oldest data when this overflows (which it shouldn't). There is no timeout any more. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v6: * Use libxl__ev_child_inuse rather than testing pid directly. * Fix a code style error. * Properly initialise the sub-operations' aos in _init. * Bugfixes. --- tools/libxl/libxl.c | 4 + tools/libxl/libxl.h | 3 +- tools/libxl/libxl_bootloader.c | 713 +++++++++++++++++++++------------------- tools/libxl/libxl_create.c | 8 +- tools/libxl/libxl_internal.h | 34 ++ 5 files changed, 419 insertions(+), 343 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 939cc02..d5fb186 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1750,6 +1750,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk) * For other device types assume that the blktap2 process is * needed by the soon to be started domain and do nothing. */ + /* + * FIXME + * This appears to leak the disk in failure paths + */ return 0; } diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index fb90aed..3087146 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -495,7 +495,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx); int libxl_run_bootloader(libxl_ctx *ctx, libxl_domain_build_info *info, libxl_device_disk *disk, - uint32_t domid); + uint32_t domid, + libxl_asyncop_how *ao_how); /* 0 means ERROR_ENOMEM, which we have logged */ diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index b50944a..bdc4cb4 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -15,6 +15,7 @@ #include "libxl_osdeps.h" /* must come before any other headers */ #include +#include #ifdef INCLUDE_LIBUTIL_H #include INCLUDE_LIBUTIL_H @@ -22,67 +23,80 @@ #include "libxl_internal.h" -#define XENCONSOLED_BUF_SIZE 16 -#define BOOTLOADER_BUF_SIZE 4096 -#define BOOTLOADER_TIMEOUT 1 +#define BOOTLOADER_BUF_OUT 65536 +#define BOOTLOADER_BUF_IN 4096 -static char **make_bootloader_args(libxl__gc *gc, - libxl_domain_build_info *info, - uint32_t domid, - const char *fifo, char *disk) +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op); +static void bootloader_keystrokes_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_display_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status); + +/*----- bootloader arguments -----*/ + +static void bootloader_arg(libxl__bootloader_state *bl, const char *arg) +{ + assert(bl->nargs < bl->argsspace); + bl->args[bl->nargs++] = arg; +} + +static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl) { - flexarray_t *args; - int nr = 0; + const libxl_domain_build_info *info = bl->info; - args = flexarray_make(1, 1); - if (!args) - return NULL; + bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args); - flexarray_set(args, nr++, (char *)info->u.pv.bootloader); + GCNEW_ARRAY(bl->args, bl->argsspace); + +#define ARG(arg) bootloader_arg(bl, (arg)) + + ARG(info->u.pv.bootloader); if (info->u.pv.kernel.path) - flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s", - info->u.pv.kernel.path)); + ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path)); if (info->u.pv.ramdisk.path) - flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path)); + ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path)); if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0') - flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline)); + ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline)); - flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo)); - flexarray_set(args, nr++, "--output-format=simple0"); - flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/")); + ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath)); + ARG("--output-format=simple0"); + ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir)); if (info->u.pv.bootloader_args) { char **p = info->u.pv.bootloader_args; while (*p) { - flexarray_set(args, nr++, *p); + ARG(*p); p++; } } - flexarray_set(args, nr++, disk); + ARG(bl->diskpath); - /* Sentinal for execv */ - flexarray_set(args, nr++, NULL); + /* Sentinel for execv */ + ARG(NULL); - return (char **) flexarray_contents(args); /* Frees args */ +#undef ARG } -static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len) +/*----- synchronous subroutines -----*/ + +static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl, + char *slave_path, size_t slave_path_len) { + STATE_AO_GC(bl->ao); struct termios termattr; - int ret; - - ret = openpty(master, slave, NULL, NULL, NULL); - if (ret < 0) - return -1; - - ret = ttyname_r(*slave, slave_path, slave_path_len); - if (ret == -1) { - close(*master); - close(*slave); - *master = *slave = -1; - return -1; + int r, rc; + int slave = libxl__carefd_fd(bl->ptys[1].slave); + int master = libxl__carefd_fd(bl->ptys[1].master); + + r = ttyname_r(slave, slave_path, slave_path_len); + if (r == -1) { + LOGE(ERROR,"ttyname_r failed"); + rc = ERROR_FAIL; + goto out; } /* @@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_ * semantics on Solaris, so don't try to set any attributes * for it. */ -#if !defined(__sun__) && !defined(__NetBSD__) - tcgetattr(*master, &termattr); + tcgetattr(master, &termattr); cfmakeraw(&termattr); - tcsetattr(*master, TCSANOW, &termattr); - - close(*slave); - *slave = -1; -#else - tcgetattr(*slave, &termattr); - cfmakeraw(&termattr); - tcsetattr(*slave, TCSANOW, &termattr); -#endif - - fcntl(*master, F_SETFL, O_NDELAY); - fcntl(*master, F_SETFD, FD_CLOEXEC); + tcsetattr(master, TCSANOW, &termattr); return 0; + + out: + return rc; } -static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args) -{ - struct termios termattr; - 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); - return -1; - } +static const char *bootloader_result_command(libxl__gc *gc, const char *buf, + const char *prefix, size_t prefixlen) { + if (strncmp(buf, prefix, prefixlen)) + return 0; - /* - * On Solaris, the master pty side does not have terminal semantics, - * so don't try to set any attributes, as it will fail. - */ -#if !defined(__sun__) - tcgetattr(*master, &termattr); - cfmakeraw(&termattr); - tcsetattr(*master, TCSANOW, &termattr); -#endif + const char *rhs = buf + prefixlen; + if (!CTYPE(isspace,*rhs)) + return 0; - fcntl(*master, F_SETFL, O_NDELAY); + while (CTYPE(isspace,*rhs)) + rhs++; - return pid; + LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs); + + return rhs; } -/* - * filedescriptors: - * fifo_fd - bootstring output from the bootloader - * xenconsoled_fd - input/output from/to xenconsole - * bootloader_fd - input/output from/to pty that controls the bootloader - * The filedescriptors are NDELAY, so it's ok to try to read - * bigger chunks than may be available, to keep e.g. curses - * screen redraws in the bootloader efficient. xenconsoled_fd is the side that - * gets xenconsole input, which will be keystrokes, so a small number - * is sufficient. bootloader_fd is pygrub output, which will be curses screen - * updates, so a larger number (1024) is appropriate there. - * - * For writeable descriptors, only include them in the set for select - * if there is actual data to write, otherwise this would loop too fast, - * eating up CPU time. - */ -static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd) +static int parse_bootloader_result(libxl__egc *egc, + libxl__bootloader_state *bl) { - int ret; - - size_t nr_out = 0, size_out = 0; - char *output = NULL; - struct timeval wait; - - /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */ - int xenconsoled_prod = 0, xenconsoled_cons = 0; - char xenconsoled_buf[XENCONSOLED_BUF_SIZE]; - /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */ - int bootloader_prod = 0, bootloader_cons = 0; - char bootloader_buf[BOOTLOADER_BUF_SIZE]; - - while(1) { - fd_set wsel, rsel; - int nfds; - - /* Set timeout to 1s before starting to discard data */ - wait.tv_sec = BOOTLOADER_TIMEOUT; - wait.tv_usec = 0; - - /* Move buffers around to drop already consumed data */ - if (xenconsoled_cons > 0) { - xenconsoled_prod -= xenconsoled_cons; - memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons], - xenconsoled_prod); - xenconsoled_cons = 0; - } - if (bootloader_cons > 0) { - bootloader_prod -= bootloader_cons; - memmove(bootloader_buf, &bootloader_buf[bootloader_cons], - bootloader_prod); - bootloader_cons = 0; - } - - FD_ZERO(&rsel); - FD_SET(fifo_fd, &rsel); - nfds = fifo_fd + 1; - if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) { - /* The buffer is not full, try to read more data */ - FD_SET(xenconsoled_fd, &rsel); - nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds; - } - if (bootloader_prod < BOOTLOADER_BUF_SIZE) { - /* The buffer is not full, try to read more data */ - FD_SET(bootloader_fd, &rsel); - nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds; - } - - FD_ZERO(&wsel); - if (bootloader_prod > 0) { - /* The buffer has data to consume */ - FD_SET(xenconsoled_fd, &wsel); - nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds; - } - if (xenconsoled_prod > 0) { - /* The buffer has data to consume */ - FD_SET(bootloader_fd, &wsel); - nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds; - } - - if (xenconsoled_prod == XENCONSOLED_BUF_SIZE || - bootloader_prod == BOOTLOADER_BUF_SIZE) - ret = select(nfds, &rsel, &wsel, NULL, &wait); - else - ret = select(nfds, &rsel, &wsel, NULL, NULL); - if (ret < 0) { - if (errno == EINTR) - continue; - goto out_err; - } - - /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */ - if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) { - /* Drop the buffer */ - xenconsoled_prod = 0; - xenconsoled_cons = 0; - } else if (FD_ISSET(xenconsoled_fd, &rsel)) { - ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - xenconsoled_prod += ret; - } - if (FD_ISSET(bootloader_fd, &wsel)) { - ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - xenconsoled_cons += ret; - } + STATE_AO_GC(bl->ao); + char buf[PATH_MAX*2]; + FILE *f = 0; + int rc = ERROR_FAIL; + libxl_domain_build_info *info = bl->info; + + f = fopen(bl->outputpath, "r"); + if (!f) { + LOGE(ERROR,"open bootloader output file %s", bl->outputpath); + goto out; + } - /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */ - if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) { - /* Drop the buffer */ - bootloader_prod = 0; - bootloader_cons = 0; - } else if (FD_ISSET(bootloader_fd, &rsel)) { - ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - bootloader_prod += ret; + for (;;) { + /* Read a nul-terminated "line" and put the result in + * buf, and its length (not including the nul) in l */ + int l = 0, c; + while ((c = getc(f)) != EOF && c != '\0') { + if (l < sizeof(buf)-1) + buf[l] = c; + l++; } - if (FD_ISSET(xenconsoled_fd, &wsel)) { - ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - bootloader_cons += ret; - } - - if (FD_ISSET(fifo_fd, &rsel)) { - if (size_out - nr_out < 256) { - char *temp; - size_t new_size = size_out == 0 ? 32 : size_out * 2; - - temp = realloc(output, new_size); - if (temp == NULL) - goto out_err; - output = temp; - memset(output + size_out, 0, new_size - size_out); - size_out = new_size; + if (c == EOF) { + if (ferror(f)) { + LOGE(ERROR,"read bootloader output file %s", bl->outputpath); + goto out; } - - ret = read(fifo_fd, output + nr_out, size_out - nr_out); - if (ret > 0) - nr_out += ret; - if (ret == 0) + if (!l) break; } - } + if (l >= sizeof(buf)) { + LOG(WARN,"bootloader output contained" + " overly long item `%.150s...'", buf); + continue; + } + buf[l] = 0; - libxl__ptr_add(gc, output); - return output; + const char *rhs; +#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1))) -out_err: - free(output); - return NULL; -} - -static void parse_bootloader_result(libxl__gc *gc, - libxl_domain_build_info *info, - const char *o) -{ - while (*o != '\0') { - if (strncmp("kernel ", o, strlen("kernel ")) == 0) { + if (COMMAND("kernel")) { free(info->u.pv.kernel.path); - info->u.pv.kernel.path = strdup(o + strlen("kernel ")); + info->u.pv.kernel.path = libxl__strdup(NULL, rhs); libxl__file_reference_map(&info->u.pv.kernel); unlink(info->u.pv.kernel.path); - } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) { + } else if (COMMAND("ramdisk")) { free(info->u.pv.ramdisk.path); - info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk ")); + info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs); libxl__file_reference_map(&info->u.pv.ramdisk); unlink(info->u.pv.ramdisk.path); - } else if (strncmp("args ", o, strlen("args ")) == 0) { + } else if (COMMAND("args")) { free(info->u.pv.cmdline); - info->u.pv.cmdline = strdup(o + strlen("args ")); + info->u.pv.cmdline = libxl__strdup(NULL, rhs); + } else if (l) { + LOG(WARN, "unexpected output from bootloader: `%s'", buf); } - - o = o + strlen(o) + 1; } + rc = 0; + + out: + if (f) fclose(f); + return rc; } -int libxl_run_bootloader(libxl_ctx *ctx, - libxl_domain_build_info *info, - libxl_device_disk *disk, - uint32_t domid) + +/*----- init and cleanup -----*/ + +void libxl__bootloader_init(libxl__bootloader_state *bl) +{ + assert(bl->ao); + bl->diskpath = NULL; + bl->openpty.ao = bl->ao; + bl->ptys[0].master = bl->ptys[0].slave = 0; + bl->ptys[1].master = bl->ptys[1].slave = 0; + libxl__ev_child_init(&bl->child); + bl->keystrokes.ao = bl->ao; libxl__datacopier_init(&bl->keystrokes); + bl->display.ao = bl->ao; libxl__datacopier_init(&bl->display); +} + +static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) { - GC_INIT(ctx); - int ret, rc = 0; - char *fifo = NULL; - char *diskpath = NULL; - char **args = NULL; + STATE_AO_GC(bl->ao); + int i; - char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; - char *tempdir; + if (bl->outputpath) libxl__remove_file(gc, bl->outputpath); + if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir); - char *dom_console_xs_path; - char dom_console_slave_tty_path[PATH_MAX]; + if (bl->diskpath) { + libxl_device_disk_local_detach(CTX, bl->disk); + free(bl->diskpath); + bl->diskpath = 0; + } + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + for (i=0; i<2; i++) { + libxl__carefd_close(bl->ptys[i].master); + libxl__carefd_close(bl->ptys[i].slave); + } +} + +static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl) +{ + uint32_t domid = bl->domid; + bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid); + bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid); +} - int xenconsoled_fd = -1, xenconsoled_slave = -1; - int bootloader_fd = -1, fifo_fd = -1; +static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl, + int rc) +{ + bootloader_cleanup(egc, bl); + bl->callback(egc, bl, rc); +} - int blrc; - pid_t pid; - char *blout; +/*----- main flow of control -----*/ - struct stat st_buf; +void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) +{ + STATE_AO_GC(bl->ao); + libxl_domain_build_info *info = bl->info; + int rc, r; - rc = libxl__domain_build_info_setdefault(gc, info); - if (rc) goto out; + libxl__bootloader_init(bl); - if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) - goto out; + if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) { + rc = 0; + goto out_ok; + } - rc = libxl__domain_build_info_setdefault(gc, info); - if (rc) goto out; + bootloader_setpaths(gc, bl); - rc = ERROR_INVAL; - if (!disk) + for (;;) { + r = mkdir(bl->outputdir, 0600); + if (!r) break; + if (errno == EINTR) continue; + if (errno == EEXIST) break; + LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir); + rc = ERROR_FAIL; goto out; + } - rc = ERROR_FAIL; - ret = mkdir("/var/run/libxl/", S_IRWXU); - if (ret < 0 && errno != EEXIST) + for (;;) { + r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600); + if (r>=0) { close(r); break; } + if (errno == EINTR) continue; + LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath); + rc = ERROR_FAIL; goto out; + } - ret = stat("/var/run/libxl/", &st_buf); - if (ret < 0) + bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk); + if (!bl->diskpath) { + rc = ERROR_FAIL; goto out; + } - if (!S_ISDIR(st_buf.st_mode)) - goto out; + make_bootloader_args(gc, bl); - tempdir = mkdtemp(tempdir_template); - if (tempdir == NULL) - goto out; + bl->openpty.ao = ao; + bl->openpty.callback = bootloader_gotptys; + bl->openpty.count = 2; + bl->openpty.results = bl->ptys; + rc = libxl__openptys(&bl->openpty, 0,0); + if (rc) goto out; - ret = asprintf(&fifo, "%s/fifo", tempdir); - if (ret < 0) { - fifo = NULL; - goto out_close; - } + return; - ret = mkfifo(fifo, 0600); - if (ret < 0) { - goto out_close; - } + out: + assert(rc); + out_ok: + bootloader_callback(egc, bl, rc); +} - diskpath = libxl_device_disk_local_attach(ctx, disk); - if (!diskpath) { - goto out_close; - } +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) +{ + libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty); + STATE_AO_GC(bl->ao); + int rc, r; - args = make_bootloader_args(gc, info, domid, fifo, diskpath); - if (args == NULL) { - rc = ERROR_NOMEM; - goto out_close; + if (bl->openpty.rc) { + rc = bl->openpty.rc; + goto out; } /* @@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx, * where we copy characters between the two master fds, as well as * listening on the bootloader's fifo for the results. */ - ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave, + + char *dom_console_xs_path; + char dom_console_slave_tty_path[PATH_MAX]; + rc = setup_xenconsoled_pty(egc, bl, &dom_console_slave_tty_path[0], sizeof(dom_console_slave_tty_path)); - if (ret < 0) { - goto out_close; + if (rc) goto out; + + char *dompath = libxl__xs_get_dompath(gc, bl->domid); + if (!dompath) { rc = ERROR_FAIL; goto out; } + + dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath); + + rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", + dom_console_slave_tty_path); + if (rc) { + LOGE(ERROR,"xs write console path %s := %s failed", + dom_console_xs_path, dom_console_slave_tty_path); + rc = ERROR_FAIL; + goto out; } - dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); - libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); + int bootloader_master = libxl__carefd_fd(bl->ptys[0].master); + int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master); + + libxl_fd_set_nonblock(CTX, bootloader_master, 1); + libxl_fd_set_nonblock(CTX, xenconsole_master, 1); + + bl->keystrokes.writefd = bl->display.readfd = bootloader_master; + bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty"; + + bl->keystrokes.readfd = bl->display.writefd = xenconsole_master; + bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty"; + + bl->keystrokes.ao = ao; + bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT; + bl->keystrokes.copywhat = + GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid); + bl->keystrokes.callback = bootloader_keystrokes_copyfail; + rc = libxl__datacopier_start(&bl->keystrokes); + if (rc) goto out; + + bl->display.ao = ao; + bl->display.maxsz = BOOTLOADER_BUF_IN; + bl->display.copywhat = + GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid); + bl->display.callback = bootloader_display_copyfail; + rc = libxl__datacopier_start(&bl->display); + if (rc) goto out; + + LOG(DEBUG, "executing bootloader: %s", bl->args[0]); + for (const char **blarg = bl->args; + *blarg; + blarg++) + LOG(DEBUG, " bootloader arg: %s", *blarg); + + struct termios termattr; - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); - if (pid < 0) { - goto out_close; + pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; } - while (1) { - if (waitpid(pid, &blrc, WNOHANG) == pid) - goto out_close; + if (!pid) { + /* child */ + r = login_tty(libxl__carefd_fd(bl->ptys[0].slave)); + if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); } + setenv("TERM", "vt100", 1); + libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args); + exit(-1); + } - fifo_fd = open(fifo, O_RDONLY); - if (fifo_fd > -1) - break; + /* parent */ - if (errno == EINTR) - continue; + /* + * On Solaris, the master pty side does not have terminal semantics, + * so don't try to set any attributes, as it will fail. + */ +#if !defined(__sun__) + tcgetattr(bootloader_master, &termattr); + cfmakeraw(&termattr); + tcsetattr(bootloader_master, TCSANOW, &termattr); +#endif + + return; + + out: + bootloader_callback(egc, bl, rc); +} - goto out_close; +/* perhaps one of these will be called, but perhaps not */ +static void bootloader_copyfail(libxl__egc *egc, const char *which, + libxl__bootloader_state *bl, int onwrite, int errnoval) +{ + STATE_AO_GC(bl->ao); + int r; + + if (!onwrite && !errnoval) + LOG(ERROR, "unexpected eof copying %s", which); + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + if (libxl__ev_child_inuse(&bl->child)) { + r = kill(bl->child.pid, SIGTERM); + if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", + (unsigned long)bl->child.pid); } + bl->rc = ERROR_FAIL; +} +static void bootloader_keystrokes_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes); + bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval); +} +static void bootloader_display_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display); + bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval); +} - fcntl(fifo_fd, F_SETFL, O_NDELAY); +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) +{ + libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child); + STATE_AO_GC(bl->ao); + int rc; - blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd); - if (blout == NULL) { - goto out_close; + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + + if (status) { + libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader", + pid, status); + rc = ERROR_FAIL; + goto out; + } else { + LOG(DEBUG, "bootloader completed"); } - pid = waitpid(pid, &blrc, 0); - if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) { - goto out_close; + if (bl->rc) { + /* datacopier went wrong */ + rc = bl->rc; + goto out; } - parse_bootloader_result(gc, info, blout); + rc = parse_bootloader_result(egc, bl); + if (rc) goto out; rc = 0; -out_close: - if (diskpath) { - libxl_device_disk_local_detach(ctx, disk); - free(diskpath); - } - if (fifo_fd > -1) - close(fifo_fd); - if (bootloader_fd > -1) - close(bootloader_fd); - if (xenconsoled_fd > -1) - close(xenconsoled_fd); - if (xenconsoled_slave > -1) - close(xenconsoled_slave); - - if (fifo) { - unlink(fifo); - free(fifo); - } + LOG(DEBUG, "bootloader execution successful"); - rmdir(tempdir); + out: + bootloader_callback(egc, bl, rc); +} - free(args); +/*----- entrypoint for external callers -----*/ -out: - GC_FREE; - return rc; +static void run_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *st, int rc) +{ + libxl__ao_complete(egc, st->ao, rc); +} + +int libxl_run_bootloader(libxl_ctx *ctx, + libxl_domain_build_info *info, + libxl_device_disk *disk, + uint32_t domid, + libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx,domid,ao_how); + libxl__bootloader_state *bl; + + GCNEW(bl); + bl->ao = ao; + bl->callback = run_bootloader_done; + bl->info = info; + bl->disk = disk; + bl->domid = domid; + libxl__bootloader_run(egc, bl); + return AO_INPROGRESS; } /* diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index d501102..f7732aa 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -593,8 +593,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, if (ret) goto error_out; } - if ( restore_fd < 0 ) { - ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid); + libxl_device_disk *bootdisk = + d_config->num_disks > 0 ? &d_config->disks[0] : NULL; + + if (restore_fd < 0 && bootdisk) { + ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid, + 0 /* fixme-ao */); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to run bootloader: %d", ret); diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 3744a28..e8502c6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -42,6 +42,7 @@ #include #include #include +#include #include #include @@ -440,6 +441,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path); _hidden int libxl__remove_directory(libxl__gc *gc, const char *path); _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path); + _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t, @@ -1549,6 +1551,38 @@ int libxl__openptys(libxl__openpty_state *op, const struct winsize *winp); +/*----- bootloader -----*/ + +typedef struct libxl__bootloader_state libxl__bootloader_state; +typedef void libxl__run_bootloader_callback(libxl__egc*, + libxl__bootloader_state*, int rc); + +struct libxl__bootloader_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + libxl__run_bootloader_callback *callback; + libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */ + libxl_device_disk *disk; + uint32_t domid; + /* private to libxl__run_bootloader */ + char *outputpath, *outputdir; + char *diskpath; /* not from gc, represents actually attached disk */ + libxl__openpty_state openpty; + libxl__openpty_result ptys[2]; /* [0] is for bootloader */ + libxl__ev_child child; + int nargs, argsspace; + const char **args; + libxl__datacopier_state keystrokes, display; + int rc; +}; + +_hidden void libxl__bootloader_init(libxl__bootloader_state *bl); + +/* Will definitely call st->callback, perhaps reentrantly. + * If callback is passed rc==0, will have updated st->info appropriately */ +_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Ym-DU; Fri, 11 May 2012 17:58:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wb-IT for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:20 +0000 Received: from [85.158.139.83:4085] by server-5.bemta-5.messagelabs.com id B9/DB-13566-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1336759096!27925681!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30162 invoked from network); 11 May 2012 17:58:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435465" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008Hs-2A; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000fa-V0; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:53 +0100 Message-ID: <1336759092-2432-9-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 08/27] libxl: Clean up setdefault in do_domain_create X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org do_domain_create called libxl__domain_create_info_setdefault twice. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_create.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 6df20ca..d501102 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -573,9 +573,6 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); if (ret) goto error_out; - ret = libxl__domain_create_info_setdefault(gc, &d_config->c_info); - if (ret) goto error_out; - ret = libxl__domain_make(gc, &d_config->c_info, &domid); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6h-0006a5-N0; Fri, 11 May 2012 17:58:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wa-UJ for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42653] by server-1.bemta-4.messagelabs.com id 83/B9-20925-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25721 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435466" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hp-Vf; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eU-Sc; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:52 +0100 Message-ID: <1336759092-2432-8-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 07/27] libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Provide functions for sending and receiving fds. There used to be fd-sending functionality in libxl_qmp.c before 25298:84ae90427c54, which this implementation is partially derived from. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 11 ++++ tools/libxl/libxl_utils.c | 104 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 909e01f..e25569c 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1135,6 +1135,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid); _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, const libxl_domain_config *guest_config); +/* on failure, logs */ +int libxl__sendmsg_fds(libxl__gc *gc, int carrier, + const void *data, size_t datalen, + int nfds, const int fds[], const char *what); + +/* Insists on receiving exactly nfds and datalen. On failure, logs + * and leaves *fds untouched. */ +int libxl__recvmsg_fds(libxl__gc *gc, int carrier, + void *databuf, size_t datalen, + int nfds, int fds[], const char *what); + /* from libxl_json */ #include diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 1a4874c..19b4615 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr) free(list); } +int libxl__sendmsg_fds(libxl__gc *gc, int carrier, + const void *data, size_t datalen, + int nfds, const int fds[], const char *what) { + struct msghdr msg = { 0 }; + struct cmsghdr *cmsg; + size_t spaceneeded = nfds * sizeof(fds[0]); + char control[CMSG_SPACE(spaceneeded)]; + struct iovec iov; + int r; + + iov.iov_base = (void*)data; + iov.iov_len = datalen; + + /* compose the message */ + msg.msg_iov = &iov; + msg.msg_iovlen = 1; + msg.msg_control = control; + msg.msg_controllen = sizeof(control); + + /* attach open fd */ + cmsg = CMSG_FIRSTHDR(&msg); + cmsg->cmsg_level = SOL_SOCKET; + cmsg->cmsg_type = SCM_RIGHTS; + cmsg->cmsg_len = CMSG_LEN(spaceneeded); + memcpy(CMSG_DATA(cmsg), fds, spaceneeded); + + msg.msg_controllen = cmsg->cmsg_len; + + r = sendmsg(carrier, &msg, 0); + if (r < 0) { + LOGE(ERROR, "failed to send fd-carrying message (%s)", what); + return ERROR_FAIL; + } + + return 0; +} + +int libxl__recvmsg_fds(libxl__gc *gc, int carrier, + void *databuf, size_t datalen, + int nfds, int fds[], const char *what) +{ + struct msghdr msg = { 0 }; + struct cmsghdr *cmsg; + size_t spaceneeded = nfds * sizeof(fds[0]); + char control[CMSG_SPACE(spaceneeded)]; + struct iovec iov; + int r; + + iov.iov_base = databuf; + iov.iov_len = datalen; + + msg.msg_iov = &iov; + msg.msg_iovlen = 1; + msg.msg_control = control; + msg.msg_controllen = sizeof(control); + + for (;;) { + r = recvmsg(carrier, &msg, 0); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) return -1; + LOGE(ERROR,"recvmsg failed (%s)", what); + return ERROR_FAIL; + } + if (r == 0) { + LOG(ERROR,"recvmsg got EOF (%s)", what); + return ERROR_FAIL; + } + cmsg = CMSG_FIRSTHDR(&msg); + if (cmsg->cmsg_len <= CMSG_LEN(0)) { + LOG(ERROR,"recvmsg got no control msg" + " when expecting fds (%s)", what); + return ERROR_FAIL; + } + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + LOG(ERROR, "recvmsg got unexpected" + " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)", + cmsg->cmsg_level, SOL_SOCKET, + cmsg->cmsg_type, SCM_RIGHTS, + what); + return ERROR_FAIL; + } + if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) || + msg.msg_controllen != cmsg->cmsg_len) { + LOG(ERROR, "recvmsg got unexpected" + " number of fds or extra control data" + " (%ld bytes' worth, expected %ld) (%s)", + (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len, + what); + int i, fd; + unsigned char *p; + for (i=0, p=CMSG_DATA(cmsg); + CMSG_SPACE(i * sizeof(fds[0])); + i++, i+=sizeof(fd)) { + memcpy(&fd, p, sizeof(fd)); + close(fd); + } + return ERROR_FAIL; + } + memcpy(fds, CMSG_DATA(cmsg), spaceneeded); + return 0; + } +} + void libxl_dominfo_list_free(libxl_dominfo *list, int nr) { int i; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6o-0006kC-UN; Fri, 11 May 2012 17:58:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6g-0006Wa-LA for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:42720] by server-1.bemta-4.messagelabs.com id E5/B9-20925-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!6 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32065 invoked from network); 11 May 2012 17:58:20 -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; 11 May 2012 17:58:20 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435482" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 11 May 2012 18:58:17 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6b-0008Ii-5b; Fri, 11 May 2012 17:58:17 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6b-0000gk-3B; Fri, 11 May 2012 18:58:17 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:58:10 +0100 Message-ID: <1336759092-2432-26-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 25/27] libxl: clarify definition of "slow" operation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Update the comment in libxl_internal.h to be clearer about which application-facing libxl operations need to take an ao_how. Reported-by: Dan Magenheimer Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 29 +++++++++++++++++++++++------ 1 files changed, 23 insertions(+), 6 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 3aa0ed7..9f3f759 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1439,17 +1439,34 @@ _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 - * inside libxl, because they can cause reentrancy callbacks. + * All "slow" functions (see below for the exact definition) 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 inside libxl, because they can cause reentrancy + * callbacks. * * For the same reason functions taking an ao_how may make themselves * an egc with EGC_INIT (and they will generally want to, to be able * to immediately complete an ao during its setup). * + * + * "Slow" functions includes any that might block on a guest or an + * external script. More broadly, it includes any operations which + * are sufficiently slow that an application might reasonably want to + * initiate them, and then carry on doing something else, while the + * operation completes. That is, a "fast" function must be fast + * enough that we do not mind blocking all other management operations + * on the same host while it completes. + * + * There are certain primitive functions which make a libxl operation + * necessarily "slow" for API reasons. These are: + * - awaiting xenstore watches (although read-modify-write xenstore + * transactions are OK for fast functions) + * - spawning subprocesses + * - anything with a timeout + * + * * Lifecycle of an ao: * * - Created by libxl__ao_create (or the AO_CREATE convenience macro). -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6p-0006l8-De; Fri, 11 May 2012 17:58:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wq-Sr for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57433] by server-3.bemta-4.messagelabs.com id 6E/F4-05853-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25755 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435464" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hf-OW; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eJ-M1; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:49 +0100 Message-ID: <1336759092-2432-5-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne , Ian Jackson Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/27=5D_autoconf=3A_trim_the_conf?= =?utf-8?q?igure_script=3B_use_autoheader?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr c29uQGV1LmNpdHJpeC5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj aXRyaXguY29tPgpDYzogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4K CkNoYW5nZXMgc2luY2Ugdjc6CiAqIFJlbW92ZWQgQVhfQ0hFQ0tfUFRZRlVOQ1MgKHNudWNrIGlu IGZyb20gcHJldmlvdXMgcGF0Y2gpCi0tLQogYXV0b2dlbi5zaCAgICAgICAgIHwgICAgMSArCiB0 b29scy9jb25maWcuaC5pbiAgfCAgIDczICstCiB0b29scy9jb25maWd1cmUgICAgfCA4ODI1ICsr KysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHRvb2xz L2NvbmZpZ3VyZS5hYyB8ICAgNjAgKy0KIDQgZmlsZXMgY2hhbmdlZCwgMjk4MSBpbnNlcnRpb25z KCspLCA1OTc4IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2F1dG9nZW4uc2ggYi9hdXRvZ2Vu LnNoCmluZGV4IGMyODhiNzEuLjU4YTcxY2UgMTAwNzU1Ci0tLSBhL2F1dG9nZW4uc2gKKysrIGIv YXV0b2dlbi5zaApAQCAtMSwzICsxLDQgQEAKICMhL2Jpbi9zaCAtZQogY2QgdG9vbHMKIGF1dG9j b25mCithdXRvaGVhZGVyCmRpZmYgLS1naXQgYS90b29scy9jb25maWcuaC5pbiBiL3Rvb2xzL2Nv bmZpZy5oLmluCmluZGV4IGY4Zjk2ZGMuLjE3Yzg5MTMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZp Zy5oLmluCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCkBAIC0xLDE5ICsxLDY0IEBACi0vKgotICog Q29weXJpZ2h0IChDKSAyMDEyCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7 IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSAqIGl0IHVuZGVyIHRoZSB0 ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZAotICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4g d2l0aCB0aGUgc3BlY2lhbAotICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZp bGUgTElDRU5TRS4KLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhv cGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKLSAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsg d2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCi0gKiBNRVJDSEFOVEFCSUxJVFkg b3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCi0gKiBHTlUgTGVz c2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KLSAqLworLyogY29u ZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMgYnkgYXV0b2hlYWRlci4gICov CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8aW50dHlwZXMuaD4gaGVhZGVyIGZp bGUuICovCisjdW5kZWYgSEFWRV9JTlRUWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo YXZlIHRoZSBgY3J5cHRvJyBsaWJyYXJ5ICgtbGNyeXB0bykuICovCisjdW5kZWYgSEFWRV9MSUJD UllQVE8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB5YWpsJyBsaWJyYXJ5ICgt bHlhamwpLiAqLworI3VuZGVmIEhBVkVfTElCWUFKTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug aGF2ZSB0aGUgYHonIGxpYnJhcnkgKC1seikuICovCisjdW5kZWYgSEFWRV9MSUJaCisKKy8qIERl ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWVtb3J5Lmg+IGhlYWRlciBmaWxlLiAqLworI3Vu ZGVmIEhBVkVfTUVNT1JZX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRp bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJTlRfSAorCisvKiBEZWZpbmUg dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBI QVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5ncy5o PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklOR1NfSAorCisvKiBEZWZpbmUgdG8g MSBpZiB5b3UgaGF2ZSB0aGUgPHN0cmluZy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZF X1NUUklOR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3N0YXQuaD4g aGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfU1RBVF9ICisKKy8qIERlZmluZSB0byAx IGlmIHlvdSBoYXZlIHRoZSA8c3lzL3R5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhB VkVfU1lTX1RZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx1bmlzdGQu aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklTVERfSAogCiAvKiBEZWZpbmUgdG8g MSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLwog I3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogCi0vKiBEZWZpbmUgY3Vyc2VzIGhlYWRl ciB0byBpbmNsdWRlLiAqLworLyogRGVmaW5lIGN1cnNlcyBoZWFkZXIgdG8gdXNlICovCiAjdW5k ZWYgSU5DTFVERV9DVVJTRVNfSAorCisvKiBEZWZpbmUgdG8gdGhlIGFkZHJlc3Mgd2hlcmUgYnVn IHJlcG9ydHMgZm9yIHRoaXMgcGFja2FnZSBzaG91bGQgYmUgc2VudC4gKi8KKyN1bmRlZiBQQUNL QUdFX0JVR1JFUE9SVAorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBvZiB0aGlzIHBhY2th Z2UuICovCisjdW5kZWYgUEFDS0FHRV9OQU1FCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1l IGFuZCB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1NUUklORwor CisvKiBEZWZpbmUgdG8gdGhlIG9uZSBzeW1ib2wgc2hvcnQgbmFtZSBvZiB0aGlzIHBhY2thZ2Uu ICovCisjdW5kZWYgUEFDS0FHRV9UQVJOQU1FCisKKy8qIERlZmluZSB0byB0aGUgaG9tZSBwYWdl IGZvciB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9VUkwKKworLyogRGVmaW5lIHRv IHRoZSB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1ZFUlNJT04K KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIEFOU0kgQyBoZWFkZXIgZmlsZXMuICov CisjdW5kZWYgU1REQ19IRUFERVJTCmRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29s cy9jb25maWd1cmUKaW5kZXggODk3ZTA2MS4uZDg5MThmZSAxMDA3NTUKLS0tIGEvdG9vbHMvY29u ZmlndXJlCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQpAQCAtNTk1LDEyICs1OTUsOCBAQCBhY19pbmNs dWRlc19kZWZhdWx0PSJcCiAjIGluY2x1ZGUgPHVuaXN0ZC5oPgogI2VuZGlmIgogCi1hY19oZWFk ZXJfbGlzdD0KLWFjX2Z1bmNfbGlzdD0KIGFjX3N1YnN0X3ZhcnM9J0xUTElCT0JKUwotUE9XX0xJ QgogTElCT0JKUwotQUxMT0NBCiBsaWJpY29udgogUFRIUkVBRF9MSUJTCiBQVEhSRUFEX0xERkxB R1MKQEAgLTYxNiw2ICs2MTIsOSBAQCBQS0dfQ09ORklHX0xJQkRJUgogUEtHX0NPTkZJR19QQVRI CiBQS0dfQ09ORklHCiBDVVJTRVNfTElCUworRUdSRVAKK0dSRVAKK0NQUAogcHljb25maWcKIFBZ VEhPTlBBVEgKIE9DQU1MQlVJTEQKQEAgLTYzNSw4ICs2MzQsMTMgQEAgSU5TVEFMTF9EQVRBCiBJ TlNUQUxMX1NDUklQVAogSU5TVEFMTF9QUk9HUkFNCiBTRVRfTUFLRQotTE5fUwotU0VECitPQkpF WFQKK0VYRUVYVAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCiBJQVNM CiBCQ0MKIExEODYKQEAgLTY2NSwyNCArNjY5LDYgQEAgeGVuYXBpCiB2dHBtCiBtb25pdG9ycwog Z2l0aHR0cAotaG9zdF9vcwotaG9zdF92ZW5kb3IKLWhvc3RfY3B1Ci1ob3N0Ci1idWlsZF9vcwot YnVpbGRfdmVuZG9yCi1idWlsZF9jcHUKLWJ1aWxkCi1FR1JFUAotR1JFUAotQ1BQCi1PQkpFWFQK LUVYRUVYVAotYWNfY3RfQ0MKLUNQUEZMQUdTCi1MREZMQUdTCi1DRkxBR1MKLUNDCiB0YXJnZXRf YWxpYXMKIGhvc3RfYWxpYXMKIGJ1aWxkX2FsaWFzCkBAIC03NDAsMTIgKzcyNiw2IEBAIGVuYWJs ZV9kZWJ1ZwogICAgICAgYWNfcHJlY2lvdXNfdmFycz0nYnVpbGRfYWxpYXMKIGhvc3RfYWxpYXMK IHRhcmdldF9hbGlhcwotQ0MKLUNGTEFHUwotTERGTEFHUwotTElCUwotQ1BQRkxBR1MKLUNQUAog UFJFUEVORF9JTkNMVURFUwogUFJFUEVORF9MSUIKIEFQUEVORF9JTkNMVURFUwpAQCAtNzYyLDYg Kzc0MiwxMiBAQCBBUzg2CiBMRDg2CiBCQ0MKIElBU0wKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJ QlMKK0NQUEZMQUdTCitDUFAKIFBLR19DT05GSUcKIFBLR19DT05GSUdfUEFUSAogUEtHX0NPTkZJ R19MSUJESVIKQEAgLTEzNjUsMTAgKzEzNTEsNiBAQCBGaW5lIHR1bmluZyBvZiB0aGUgaW5zdGFs bGF0aW9uIGRpcmVjdG9yaWVzOgogX0FDRU9GCiAKICAgY2F0IDw8XF9BQ0VPRgotCi1TeXN0ZW0g dHlwZXM6Ci0gIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBmb3IgYnVpbGRpbmcgb24gQlVJ TEQgW2d1ZXNzZWRdCi0gIC0taG9zdD1IT1NUICAgICAgIGNyb3NzLWNvbXBpbGUgdG8gYnVpbGQg cHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQogX0FDRU9GCiBmaQogCkBAIC0xMzk5LDE0 ICsxMzgxLDYgQEAgT3B0aW9uYWwgRmVhdHVyZXM6CiAgIC0tZGlzYWJsZS1kZWJ1ZyAgICAgICAg IERpc2FibGUgZGVidWcgYnVpbGQgb2YgdG9vbHMgKGRlZmF1bHQgaXMgRU5BQkxFRCkKIAogU29t ZSBpbmZsdWVudGlhbCBlbnZpcm9ubWVudCB2YXJpYWJsZXM6Ci0gIENDICAgICAgICAgIEMgY29t cGlsZXIgY29tbWFuZAotICBDRkxBR1MgICAgICBDIGNvbXBpbGVyIGZsYWdzCi0gIExERkxBR1Mg ICAgIGxpbmtlciBmbGFncywgZS5nLiAtTDxsaWIgZGlyPiBpZiB5b3UgaGF2ZSBsaWJyYXJpZXMg aW4gYQotICAgICAgICAgICAgICBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGxpYiBkaXI+Ci0gIExJ QlMgICAgICAgIGxpYnJhcmllcyB0byBwYXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFy eT4KLSAgQ1BQRkxBR1MgICAgKE9iamVjdGl2ZSkgQy9DKysgcHJlcHJvY2Vzc29yIGZsYWdzLCBl LmcuIC1JPGluY2x1ZGUgZGlyPiBpZgotICAgICAgICAgICAgICB5b3UgaGF2ZSBoZWFkZXJzIGlu IGEgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxpbmNsdWRlIGRpcj4KLSAgQ1BQICAgICAgICAgQyBw cmVwcm9jZXNzb3IKICAgUFJFUEVORF9JTkNMVURFUwogICAgICAgICAgICAgICBMaXN0IG9mIGlu Y2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSkKICAgUFJFUEVO RF9MSUIgTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRo b3V0IC1MKQpAQCAtMTQyNSw2ICsxMzk5LDE0IEBAIFNvbWUgaW5mbHVlbnRpYWwgZW52aXJvbm1l bnQgdmFyaWFibGVzOgogICBMRDg2ICAgICAgICBQYXRoIHRvIGxkODYgdG9vbAogICBCQ0MgICAg ICAgICBQYXRoIHRvIGJjYyB0b29sCiAgIElBU0wgICAgICAgIFBhdGggdG8gaWFzbCB0b29sCisg IENDICAgICAgICAgIEMgY29tcGlsZXIgY29tbWFuZAorICBDRkxBR1MgICAgICBDIGNvbXBpbGVy IGZsYWdzCisgIExERkxBR1MgICAgIGxpbmtlciBmbGFncywgZS5nLiAtTDxsaWIgZGlyPiBpZiB5 b3UgaGF2ZSBsaWJyYXJpZXMgaW4gYQorICAgICAgICAgICAgICBub25zdGFuZGFyZCBkaXJlY3Rv cnkgPGxpYiBkaXI+CisgIExJQlMgICAgICAgIGxpYnJhcmllcyB0byBwYXNzIHRvIHRoZSBsaW5r ZXIsIGUuZy4gLWw8bGlicmFyeT4KKyAgQ1BQRkxBR1MgICAgKE9iamVjdGl2ZSkgQy9DKysgcHJl cHJvY2Vzc29yIGZsYWdzLCBlLmcuIC1JPGluY2x1ZGUgZGlyPiBpZgorICAgICAgICAgICAgICB5 b3UgaGF2ZSBoZWFkZXJzIGluIGEgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxpbmNsdWRlIGRpcj4K KyAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNzb3IKICAgUEtHX0NPTkZJRyAgcGF0aCB0byBwa2ct Y29uZmlnIHV0aWxpdHkKICAgUEtHX0NPTkZJR19QQVRICiAgICAgICAgICAgICAgIGRpcmVjdG9y aWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGgKQEAgLTE3OTcsMzExICsxNzc5 LDYgQEAgZmkKICAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCiAKIH0gIyBhY19mbl9jX3Ry eV9saW5rCi0KLSMgYWNfZm5fY19jaGVja19mdW5jIExJTkVOTyBGVU5DIFZBUgotIyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFRlc3RzIHdoZXRoZXIgRlVOQyBleGlzdHMs IHNldHRpbmcgdGhlIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseQotYWNfZm5fY19jaGVj a19mdW5jICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3Rh Y2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQotJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwi IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNh dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm cy5oLiAgKi8KLS8qIERlZmluZSAkMiB0byBhbiBpbm5vY3VvdXMgdmFyaWFudCwgaW4gY2FzZSA8 bGltaXRzLmg+IGRlY2xhcmVzICQyLgotICAgRm9yIGV4YW1wbGUsIEhQLVVYIDExaSA8bGltaXRz Lmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCi0jZGVmaW5lICQyIGlubm9jdW91c18kMgot Ci0vKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkg ZmV3IHByb3RvdHlwZXMsCi0gICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciAkMiAoKTsg YmVsb3cuCi0gICAgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp cyBkZWZpbmVkLCBzaW5jZQotICAgIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k aW5nIGNvbXBpbGVycy4gICovCi0KLSNpZmRlZiBfX1NURENfXwotIyBpbmNsdWRlIDxsaW1pdHMu aD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFzc2VydC5oPgotI2VuZGlmCi0KLSN1bmRlZiAkMgotCi0v KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K LSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh IEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0 aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1j aGFyICQyICgpOwotLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlv bnMgd2hpY2ggaXQgaW1wbGVtZW50cwotICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAg U29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCi0gICAgc29tZXRoaW5nIHN0YXJ0aW5n IHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovCi0jaWYgZGVmaW5l ZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBfX3N0dWJfX18kMgotY2hva2UgbWUKLSNlbmRpZgotCi1p bnQKLW1haW4gKCkKLXsKLXJldHVybiAkMiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBldmFsICIkMz15ZXMi Ci1lbHNlCi0gIGV2YWwgIiQzPW5vIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0 ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0 Ci1maQotZXZhbCBhY19yZXM9XCQkMwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIg PiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2si ID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2No ZWNrX2Z1bmMKLQotIyBhY19mbl9jX2NoZWNrX3R5cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVT Ci0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVGVzdHMg d2hldGhlciBUWVBFIGV4aXN0cyBhZnRlciBoYXZpbmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRp bmcgY2FjaGUKLSMgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgotYWNfZm5fY19jaGVja190eXBl ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yICQyLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNl dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGV2YWwgIiQz PW5vIgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBl bmQgY29uZmRlZnMuaC4gICovCi0kNAotaW50Ci1tYWluICgpCi17Ci1pZiAoc2l6ZW9mICgkMikp Ci0JIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ0Ci1pbnQKLW1haW4g KCkKLXsKLWlmIChzaXplb2YgKCgkMikpKQotCSAgICByZXR1cm4gMDsKLSAgOwotICByZXR1cm4g MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot Ci1lbHNlCi0gIGV2YWwgIiQzPXllcyIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0 LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jl cz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAk YXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGlu ZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQotfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQotCi0jIGFj X2ZuX2NfZmluZF9pbnRYX3QgTElORU5PIEJJVFMgVkFSCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCi0jIEZpbmRzIGEgc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRo IEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCi0jIGFjY29yZGluZ2x5LgotYWNfZm5f Y19maW5kX2ludFhfdCAoKQotewotICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGlu ZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGludCQyX3QiID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGludCQyX3QuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRl c3QgXCJcJHskMytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg IiA+JjYKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0g bmV2ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgotICAgICAjIHRo YW4gaGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdpZHRoLgotICAgICBmb3IgYWNfdHlwZSBp biBpbnQkMl90ICdpbnQnICdsb25nIGludCcgXAotCSAnbG9uZyBsb25nIGludCcgJ3Nob3J0IGlu dCcgJ3NpZ25lZCBjaGFyJzsgZG8KLSAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVm YXVsdAotCSAgICAgZW51bSB7IE4gPSAkMiAvIDIgLSAxIH07Ci1pbnQKLW1haW4gKCkKLXsKLXN0 YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAhKDAgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5 cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAxKSldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0K LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ TkVOTyI7IHRoZW4gOgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotCSAgICAg ICAgZW51bSB7IE4gPSAkMiAvIDIgLSAxIH07Ci1pbnQKLW1haW4gKCkKLXsKLXN0YXRpYyBpbnQg dGVzdF9hcnJheSBbMSAtIDIgKiAhKCgkYWNfdHlwZSkgKCgoKCgkYWNfdHlwZSkgMSA8PCBOKSA8 PCBOKSAtIDEpICogMiArIDEpCi0JCSA8ICgkYWNfdHlwZSkgKCgoKCgkYWNfdHlwZSkgMSA8PCBO KSA8PCBOKSAtIDEpICogMiArIDIpKV07Ci10ZXN0X2FycmF5IFswXSA9IDAKLQotICA7Ci0gIHJl dHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl biA6Ci0KLWVsc2UKLSAgY2FzZSAkYWNfdHlwZSBpbiAjKAotICBpbnQkMl90KSA6Ci0gICAgZXZh bCAiJDM9eWVzIiA7OyAjKAotICAqKSA6Ci0gICAgZXZhbCAiJDM9XCRhY190eXBlIiA7OwotZXNh YwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl c3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl eHQgY29uZnRlc3QuJGFjX2V4dAotICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgi bm8iOyB0aGVuIDoKLQotZWxzZQotICBicmVhawotZmkKLSAgICAgZG9uZQotZmkKLWV2YWwgYWNf cmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFs ICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19s aW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19maW5kX2ludFhfdAotCi0j IGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJTkVOTyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKLSMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBU cmllcyB0byBmaW5kIGlmIHRoZSBmaWVsZCBNRU1CRVIgZXhpc3RzIGluIHR5cGUgQUdHUiwgYWZ0 ZXIgaW5jbHVkaW5nCi0jIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2Nv cmRpbmdseS4KLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xp bmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3Rh Y2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgJDIuJDMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLiQzLi4uICIgPiY2OyB9 Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDQrc2V0fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ1Ci1pbnQKLW1haW4gKCkK LXsKLXN0YXRpYyAkMiBhY19hZ2dyOwotaWYgKGFjX2FnZ3IuJDMpCi1yZXR1cm4gMDsKLSAgOwot ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7 IHRoZW4gOgotICBldmFsICIkND15ZXMiCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ1Ci1pbnQKLW1h aW4gKCkKLXsKLXN0YXRpYyAkMiBhY19hZ2dyOwotaWYgKHNpemVvZiBhY19hZ2dyLiQzKQotcmV0 dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBp bGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZhbCAiJDQ9eWVzIgotZWxzZQotICBldmFsICIkND1u byIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0 ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq ZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jlcz1cJCQ0Ci0JICAgICAgIHsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUK LSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0 ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5v O30KLQotfSAjIGFjX2ZuX2NfY2hlY2tfbWVtYmVyCi0KLSMgYWNfZm5fY19maW5kX3VpbnRYX3Qg TElORU5PIEJJVFMgVkFSCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQot IyBGaW5kcyBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5n IGNhY2hlIHZhcmlhYmxlIFZBUgotIyBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfZmluZF91aW50WF90 ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWludCQyX3QiID4mNQotJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yIHVpbnQkMl90Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMr c2V0fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNl Ci0gIGV2YWwgIiQzPW5vIgotICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVyIGNoZWNr IGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKLSAgICAgIyB0aGFuIGhhbGYgb2Yg dGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KLSAgICAgZm9yIGFjX3R5cGUgaW4gdWludCQyX3Qg J3Vuc2lnbmVkIGludCcgJ3Vuc2lnbmVkIGxvbmcgaW50JyBcCi0JICd1bnNpZ25lZCBsb25nIGxv bmcgaW50JyAndW5zaWduZWQgc2hvcnQgaW50JyAndW5zaWduZWQgY2hhcic7IGRvCi0gICAgICAg Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZk ZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotc3RhdGlj IGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoKCgkYWNfdHlwZSkgLTEgPj4gKCQyIC8gMiAtIDEp KSA+PiAoJDIgLyAyIC0gMSkgPT0gMyldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0KLSAgOwotICBy ZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo ZW4gOgotICBjYXNlICRhY190eXBlIGluICMoCi0gIHVpbnQkMl90KSA6Ci0gICAgZXZhbCAiJDM9 eWVzIiA7OyAjKAotICAqKSA6Ci0gICAgZXZhbCAiJDM9XCRhY190eXBlIiA7OwotZXNhYwotZmkK LXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj X2V4dAotICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgibm8iOyB0aGVuIDoKLQot ZWxzZQotICBicmVhawotZmkKLSAgICAgZG9uZQotZmkKLWV2YWwgYWNfcmVzPVwkJDMKLQkgICAg ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19y ZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFsICRhc19saW5lbm9fc3Rh Y2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBh c19saW5lbm87fQotCi19ICMgYWNfZm5fY19maW5kX3VpbnRYX3QKIGNhdCA+Y29uZmlnLmxvZyA8 PF9BQ0VPRgogVGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNlZCBieSBjb21w aWxlcnMgd2hpbGUKIHJ1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5nIGlmIGNvbmZp Z3VyZSBtYWtlcyBhIG1pc3Rha2UuCkBAIC0yMzg2LDExICsyMDYzLDYgQEAgJGFzX2VjaG8gIiRh c19tZTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CiAgID4kY2FjaGVfZmlsZQog ZmkKIAotYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKLWFzX2ZuX2Fw cGVuZCBhY19oZWFkZXJfbGlzdCAiIHVuaXN0ZC5oIgotYXNfZm5fYXBwZW5kIGFjX2Z1bmNfbGlz dCAiIGFsYXJtIgotYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgiCi1hc19m bl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvcGFyYW0uaCIKICMgQ2hlY2sgdGhhdCB0aGUg cHJlY2lvdXMgdmFyaWFibGVzIHNhdmVkIGluIHRoZSBjYWNoZSBoYXZlIGtlcHQgdGhlIHNhbWUK ICMgdmFsdWUuCiBhY19jYWNoZV9jb3JydXB0ZWQ9ZmFsc2UKQEAgLTI1MDgsMTczMCArMjE4MCw0 MCBAQCBBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxl LiIgPiYyO30KIAogZmkKIAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19j b21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1h Y19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZM QUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9j X2NvbXBpbGVyX2dudQotaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4 dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4 fWdjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh Y193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7 IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1u ICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S Ci1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXog IiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj dXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7 IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKLSAgICAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlG Uz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAi JENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g Im5vIiA+JjY7IH0KLWZpCi0KLQotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhl bgotICBhY19jdF9DQz0kQ0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGdjYzsgYWNf d29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRo ZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIk YWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVf SUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0 IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFz X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCi0g ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25l Ci1JRlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3Rf Q0MKLWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAiJGFj X2N0X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0gIGlm IHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNl ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FS TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+ JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZp Ci1lbHNlCi0gIENDPSIkYWNfY3ZfcHJvZ19DQyIKLWZpCi0KLWlmIHRlc3QgLXogIiRDQyI7IHRo ZW4KLSAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4 fWNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4g IiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCi0gICAgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y ZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9 JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRD QyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJu byIgPiY2OyB9Ci1maQotCi0KLSAgZmkKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gICMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNf ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf Y3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJEND IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLSAgYWNfcHJvZ19yZWpl Y3RlZD1ubwotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2Rp ciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAm JiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl bnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g ICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2Mi OyB0aGVuCi0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKLSAgICAgICBjb250aW51ZQotICAg ICBmaQotICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1pZiB0 ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCi0gICMgV2UgZm91bmQgYSBib2dvbiBp biB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KLSAgc2V0IGR1bW15ICRh Y19jdl9wcm9nX0NDCi0gIHNoaWZ0Ci0gIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgotICAgICMgV2Ug Y2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgotICAgICMgSG93 ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9z ZW4KLSAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRo ZSBmdWxsIGZpbGUgbmFtZS4KLSAgICBzaGlmdAotICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIv JGFjX3dvcmQkezErJyAnfSRAIgotICBmaQotZmkKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MK LWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UK LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0 aGVuCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgZm9yIGFjX3Byb2cg aW4gY2wuZXhlCi0gIGRvCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9v bF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu Ci1zZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNh Y2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9n X0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2 ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8K LSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAg IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBp ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19D Qz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0g ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1m aQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNo byAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLSAg ICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCi0gIGRvbmUKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0 aGVuCi0gIGFjX2N0X0NDPSRDQwotICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKLWRvCi0gICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4K LSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgotICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19z YXZlX0lGUwotCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0 IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2 OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi0gIHRlc3QgLW4gIiRh Y19jdF9DQyIgJiYgYnJlYWsKLWRvbmUKLQotICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRo ZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7 OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZmkKLQotZmkKLQotCi10ZXN0IC16ICIk Q0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog aW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3 ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3Vu ZCBpbiBcJFBBVEgKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5P IiA1IDsgfQotCi0jIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIu Ci0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBj b21waWxlciB2ZXJzaW9uIiA+JjUKLXNldCBYICRhY19jb21waWxlCi1hY19jb21waWxlcj0kMgot Zm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwotICB7IHsgYWNf dHJ5PSIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCi1jYXNlICIoKCRhY190cnkiIGluCi0g ICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190cnlf ZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsg fSA+JjUKLSAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3Qu ZXJyCi0gIGFjX3N0YXR1cz0kPwotICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgotICAg IHNlZCAnMTBhXAotLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgotICAgICAg ICAgMTBxJyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQotICAgIGNhdCBjb25mdGVzdC5lcjEg PiY1Ci0gIGZpCi0gIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKLSAgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRl c3QgJGFjX3N0YXR1cyA9IDA7IH0KLWRvbmUKLQotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+ Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkK LXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1hY19jbGVhbl9maWxlc19zYXZlPSRh Y19jbGVhbl9maWxlcwotYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91 dC5kU1lNIGEuZXhlIGIub3V0IgotIyBUcnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91 dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEub3V0LgotIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2Ug YnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVpdGlvbgotIyBvZiBleGVl eHQuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdo ZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl dGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQotYWNfbGlua19kZWZhdWx0PWAk YXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKLQotIyBU aGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgotYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBj b25mdGVzdCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3QuKiIKLQotYWNfcm1maWxlcz0K LWZvciBhY19maWxlIGluICRhY19maWxlcwotZG8KLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICou JGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8 ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKLSAgICAq ICkgYWNfcm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsKLSAgZXNhYwotZG9uZQotcm0g LWYgJGFjX3JtZmlsZXMKLQotaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKLWNhc2Ug IigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry eTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0i XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hv ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUK LSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoK LSAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRv IGBubycuCi0jIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxk IGxlYWQgdG8gYEVYRUVYVCA9IG5vJwotIyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBv dmVycmlkZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwKLSMgc28gdGhhdCB0aGUgdXNl ciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCi0j IEF1dG9jb25mLgotZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcnCi1kbwotICB0ZXN0IC1mICIk YWNfZmlsZSIgfHwgY29udGludWUKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8 ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwg Ki5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkKLQk7OwotICAgIFthYl0ub3V0 ICkKLQkjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMg bW9zdAotCSMgY2VydGFpbmx5IHJpZ2h0LgotCWJyZWFrOzsKLSAgICAqLiogKQotCWlmIHRlc3Qg IiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5v OwotCXRoZW4gOjsgZWxzZQotCSAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1te Ll0qXChcLi4qXCknYAotCWZpCi0JIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0 aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90Ci0JIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5 IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCi0JIyBhcmd1bWVudCwgc28gd2Ug bWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVhZHkuCi0JIyBFdmVuIGlmIHRo aXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCi0JIyBhY3R1 YWxseSB3b3JraW5nLgotCWJyZWFrOzsKLSAgICAqICkKLQlicmVhazs7Ci0gIGVzYWMKLWRvbmUK LXRlc3QgIiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhlZXh0PQotCi1lbHNlCi0gIGFj X2ZpbGU9JycKLWZpCi1pZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRoZW4gOgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g Im5vIiA+JjY7IH0KLSRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQot c2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQotCi17IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yIDc3 ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMKLVNlZSBcYGNvbmZpZy5sb2cn IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotZWxzZQotICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5 ZXMiID4mNjsgfQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKLSRh c19lY2hvX24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFt ZS4uLiAiID4mNjsgfQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRhY19maWxlIiA+JjUKLSRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9Ci1hY19leGVl eHQ9JGFjX2N2X2V4ZWV4dAotCi1ybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0 ZXN0JGFjX2N2X2V4ZWV4dCBiLm91dAotYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3Nh dmUKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y IHN1ZmZpeCBvZiBleGVjdXRhYmxlcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm Zml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9Ci1pZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIK LWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c JGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlf ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRh c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1Ci0g IGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBc JD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0g ICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3 ZWxsLCBvYnNlcnZhYmxlKQotIyBjYXRjaCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3 aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCi0jIHdvcmsgcHJvcGVybHkgKGkuZS4sIHJl ZmVyIHRvIGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29uJ3Qgd2l0aAotIyBgcm0nLgotZm9y IGFjX2ZpbGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCi0gIHRlc3Qg LWYgIiRhY19maWxlIiB8fCBjb250aW51ZQotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4kYWNf ZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5i YmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OwotICAgICouKiAp IGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAotCSAgYnJl YWs7OwotICAgICogKSBicmVhazs7Ci0gIGVzYWMKLWRvbmUKLWVsc2UKLSAgeyB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1 Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l cnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29t cGlsZSBhbmQgbGluawotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5F Tk8iIDUgOyB9Ci1maQotcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Ci17ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4 dCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9Ci0KLXJtIC1mIGNvbmZ0ZXN0 LiRhY19leHQKLUVYRUVYVD0kYWNfY3ZfZXhlZXh0Ci1hY19leGVleHQ9JEVYRUVYVAotY2F0IGNv bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu ICAqLwotI2luY2x1ZGUgPHN0ZGlvLmg+Ci1pbnQKLW1haW4gKCkKLXsKLUZJTEUgKmYgPSBmb3Bl biAoImNvbmZ0ZXN0Lm91dCIsICJ3Iik7Ci0gcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChm KSAhPSAwOwotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWFjX2NsZWFuX2ZpbGVzPSIk YWNfY2xlYW5fZmlsZXMgY29uZnRlc3Qub3V0IgotIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBw cm9kdWNlcyBleGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKLSMgdGhlIGNv bXBpbGVyIGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KLXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29t cGlsaW5nIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNv bXBpbGluZy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0 aGVuCi0gIHsgeyBhY190cnk9IiRhY19saW5rIgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIq IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89 JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1 Ci0gIChldmFsICIkYWNfbGluayIpIDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0 ICRhY19zdGF0dXMgPSAwOyB9Ci0gIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4 dCcKLSAgeyB7IGNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190 cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZh bCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2Vj aG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX3RyeSIp IDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9 OyB0aGVuCi0gICAgY3Jvc3NfY29tcGlsaW5nPW5vCi0gIGVsc2UKLSAgICBpZiB0ZXN0ICIkY3Jv c3NfY29tcGlsaW5nIiA9IG1heWJlOyB0aGVuCi0JY3Jvc3NfY29tcGlsaW5nPXllcwotICAgIGVs c2UKLQl7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGlu IFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2Qn OiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMu Ci1JZiB5b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KLVNlZSBcYGNv bmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotICAgIGZpCi0gIGZp Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRj cm9zc19jb21waWxpbmciID4mNQotJGFzX2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQot Ci1ybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5v dXQKLWFjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZp bGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVz Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6 Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0g PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50 Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotcm0gLWYgY29uZnRl c3QubyBjb25mdGVzdC5vYmoKLWlmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgotY2FzZSAiKCgk YWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsK LSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRh Y190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKLSAgYWNfc3Rh dHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh Y19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKLSAgZm9yIGFj X2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KLSAgdGVzdCAt ZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOwotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4kYWNf ZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5i YmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKLSAgICAqKSBhY19jdl9vYmpleHQ9YGV4 cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKLSAgICAgICBicmVhazs7Ci0gIGVzYWMKLWRv bmUKLWVsc2UKLSAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1Ci1z ZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Ci0KLXsgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2Vj aG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8g ImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21waWxlCi1T ZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLWZpCi1y bSAtZiBjb25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIg PiY1Ci0kYXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9Ci1PQkpFWFQ9JGFjX2N2X29iamV4 dAotYWNfb2JqZXh0PSRPQkpFWFQKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBj b21waWxlci4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNh dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm cy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0jaWZuZGVmIF9fR05VQ19fCi0gICAgICAgY2hv a2UgbWUKLSNlbmRpZgotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf dHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY29tcGlsZXJfZ251PXllcwotZWxz ZQotICBhY19jb21waWxlcl9nbnU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWFjX2N2X2NfY29tcGlsZXJfZ251PSRh Y19jb21waWxlcl9nbnUKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQotJGFzX2VjaG8gIiRhY19j dl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7 IHRoZW4KLSAgR0NDPXllcwotZWxzZQotICBHQ0M9Ci1maQotYWNfdGVzdF9DRkxBR1M9JHtDRkxB R1Mrc2V0fQotYWNfc2F2ZV9DRkxBR1M9JENGTEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRh c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dl cnJvcl9mbGFnCi0gICBhY19jX3dlcnJvcl9mbGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5v Ci0gICBDRkxBR1M9Ii1nIgotICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7 Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P IjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAg ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u ZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1f QUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQot ICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIK LQkgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2 X3Byb2dfY2NfZz15ZXMKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0 LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgIGFjX2Nfd2Vycm9y X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKLSRhc19lY2hv ICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBz ZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxpZiB0ZXN0ICRhY19jdl9wcm9n X2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAgICBDRkxB R1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0gIGZpCi1lbHNlCi0gIGlmIHRl c3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIiCi0gIGVsc2UKLSAgICBDRkxB R1M9Ci0gIGZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1Ci0kYXNfZWNob19u ICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3Byb2dfY2NfYzg5PW5vCi1hY19z YXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot LyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFyZy5oPgotI2luY2x1ZGUgPHN0 ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KLS8q IE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNy Yy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsKLUZJTEUgKiAoKnJjc29wZW4p IChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1zdGF0aWMgY2hhciAqZSAocCwg aSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICByZXR1cm4gcFtpXTsKLX0KLXN0 YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikK LXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFydCAodixwKTsKLSAgcyA9IGcg KHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAgcmV0dXJuIHM7Ci19Ci0KLS8q IE9TRiA0LjAgQ29tcGFxIGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0 LiAgSXQgaGFzCi0gICBmdW5jdGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhI SCcgaGV4IGNoYXJhY3RlciBjb25zdGFudHMuCi0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVy cm9yIHVuZm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKLSAgIGFzICd4 Jy4gIFRoZSBmb2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0 byBnZXQKLSAgIHByb3BlciBBTlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlz IGNvbWVzIG91dCB0cnVlLCBmb3IgYW4KLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5l Y2Vzc2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwotICAgdGhhdCdzIHRy dWUgb25seSB3aXRoIC1zdGQuICAqLwotaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8g MSA6IC0xXTsKLQotLyogSUJNIEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQs IGJ1dCBpdCByZXBsYWNlcyBtYWNybyBwYXJhbWV0ZXJzCi0gICBpbnNpZGUgc3RyaW5ncyBhbmQg Y2hhcmFjdGVyIGNvbnN0YW50cy4gICovCi0jZGVmaW5lIEZPTyh4KSAneCcKLWludCB4bGM2X2Nj X2FycmF5W0ZPTyhhKSA9PSAneCcgPyAxIDogLTFdOwotCi1pbnQgdGVzdCAoaW50IGksIGRvdWJs ZSB4KTsKLXN0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Owotc3RydWN0IHMyIHtpbnQgKCpm KSAoZG91YmxlIGEpO307Ci1pbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShz dHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKLWludCBhcmdjOwot Y2hhciAqKmFyZ3Y7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBh cmd2WzBdICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKLSAgOwotICByZXR1cm4gMDsK LX0KLV9BQ0VPRgotZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1h bnNpIC1zdGQgXAotCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05T X18iCi1kbwotICBDQz0iJGFjX3NhdmVfQ0MgJGFjX2FyZyIKLSAgaWYgYWNfZm5fY190cnlfY29t cGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCi1maQot cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAotICB0ZXN0ICJ4JGFj X2N2X3Byb2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhawotZG9uZQotcm0gLWYgY29uZnRlc3Qu JGFjX2V4dAotQ0M9JGFjX3NhdmVfQ0MKLQotZmkKLSMgQUNfQ0FDSEVfVkFMCi1jYXNlICJ4JGFj X2N2X3Byb2dfY2NfYzg5IiBpbgotICB4KQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1Ci0kYXNfZWNobyAibm9uZSBu ZWVkZWQiID4mNjsgfSA7OwotICB4bm8pCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKLSRhc19lY2hvICJ1bnN1cHBv cnRlZCIgPiY2OyB9IDs7Ci0gICopCi0gICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCi0g ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j dl9wcm9nX2NjX2M4OSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0g OzsKLWVzYWMKLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6Ci0K LWZpCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29tcGlsZT0nJEND IC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNfbGluaz0nJEND IC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVz dC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9n bnUKLQotCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRD QyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRD QyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRl c3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJf Z251Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhv dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGhv dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9Ci0jIE9uIFN1bnMsIHNvbWV0 aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5LgotaWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAt ZCAiJENQUCI7IHRoZW4KLSAgQ1BQPQotZmkKLWlmIHRlc3QgLXogIiRDUFAiOyB0aGVuCi0gIGlm IHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19u ICIoY2FjaGVkKSAiID4mNgotZWxzZQotICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQ IG5lZWRzIHRvIGJlIGV4cGFuZGVkCi0gICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10 cmFkaXRpb25hbC1jcHAiICIvbGliL2NwcCIKLSAgICBkbwotICAgICAgYWNfcHJlcHJvY19vaz1m YWxzZQotZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCi1kbwotICAjIFVzZSBh IGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCi0g ICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgotICAjIFByZWZlciA8bGltaXRz Lmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKLSAgIyA8bGlt aXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCi0gICMgT24gdGhl IE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIs Ci0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0 Y2ggdGhpcyBjYXNlLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19TVERDX18KLSMgaW5jbHVkZSA8 bGltaXRzLmg+Ci0jZWxzZQotIyBpbmNsdWRlIDxhc3NlcnQuaD4KLSNlbmRpZgotCQkgICAgIFN5 bnRheCBlcnJvcgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoK LQotZWxzZQotICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCi1jb250aW51ZQotZmkK LXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKLQotICAjIE9L LCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVh ZGVycwotICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgotICBjYXQgY29uZmRlZnMuaCAtIDw8 X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVk ZSA8YWNfbm9uZXhpc3RlbnQuaD4KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5P IjsgdGhlbiA6Ci0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCi1jb250aW51 ZQotZWxzZQotICAjIFBhc3NlcyBib3RoIHRlc3RzLgotYWNfcHJlcHJvY19vaz06Ci1icmVhawot ZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKLQotZG9u ZQotIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNv ZGUgd2FzIHNraXBwZWQuCi1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k YWNfZXh0Ci1pZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6Ci0gIGJyZWFrCi1maQotCi0gICAgZG9u ZQotICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKLQotZmkKLSAgQ1BQPSRhY19jdl9wcm9nX0NQUAot ZWxzZQotICBhY19jdl9wcm9nX0NQUD0kQ1BQCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQotJGFzX2VjaG8gIiRDUFAiID4mNjsg fQotYWNfcHJlcHJvY19vaz1mYWxzZQotZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycg eWVzCi1kbwotICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNv bmZpZ3VyaW5nIGdsaWJjCi0gICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgot ICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5l ZCwgc2luY2UKLSAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21w aWxlcnMuCi0gICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUg Y29tcGlsZXIncyBwYXJzZXIsCi0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJy b3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD RU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19T VERDX18KLSMgaW5jbHVkZSA8bGltaXRzLmg+Ci0jZWxzZQotIyBpbmNsdWRlIDxhc3NlcnQuaD4K LSNlbmRpZgotCQkgICAgIFN5bnRheCBlcnJvcgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAg IiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5w dXQuCi1jb250aW51ZQotZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0 LiRhY19leHQKLQotICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRo ZXIgbm9uZXhpc3RlbnQgaGVhZGVycwotICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgotICBj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl ZnMuaC4gICovCi0jaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KLV9BQ0VPRgotaWYgYWNfZm5f Y190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Ci0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFs aWQgaW5wdXQuCi1jb250aW51ZQotZWxzZQotICAjIFBhc3NlcyBib3RoIHRlc3RzLgotYWNfcHJl cHJvY19vaz06Ci1icmVhawotZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0 ZXN0LiRhY19leHQKLQotZG9uZQotIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lG RUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCi1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0 ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Ci1pZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6Ci0KLWVs c2UKLSAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBp biBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk JzoiID4mMjt9Ci1hc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMg c2FuaXR5IGNoZWNrCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVO TyIgNSA7IH0KLWZpCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29t cGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNf bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19j b21waWxlcl9nbnUKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1Ci0k YXNfZWNob19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQg LWUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQK3NldH0iID0gc2V0OyB0 aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAteiAi JEdSRVAiOyB0aGVuCi0gIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQotICAjIExvb3AgdGhyb3Vn aCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAotICBh c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRI JFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0 ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dy ZXA7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv bnM7IGRvCi0gICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQi Ci0gICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRo X0dSRVAiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBz ZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCi0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQ Ci1jYXNlIGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCi0qR05VKikKLSAgYWNf Y3ZfcGF0aF9HUkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7Ci0qKQot ICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgotICB3 aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0 ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCi0gICAgY3AgImNv bmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVz dC5ubCIKLSAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gp LScgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawot ICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwg YnJlYWsKLSAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwK LSAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCi0g ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl dHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKLSAgICAgIGFj X3BhdGhfR1JFUF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFycyBh cyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEw ICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0 ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCi0KLSAgICAgICRhY19wYXRoX0dSRVBfZm91bmQg JiYgYnJlYWsgMwotICAgIGRvbmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0g IGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0dSRVAiOyB0aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8g Im5vIGFjY2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRP Ui91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3BhdGhfR1JF UD0kR1JFUAotZmkKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcGF0aF9H UkVQIiA+JjY7IH0KLSBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgotCi0KLXsgJGFzX2VjaG8gIiRh c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVncmVwIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9w YXRoX0VHUkVQK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+ JjYKLWVsc2UKLSAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxsIDI+JjEK LSAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCi0gICBlbHNlCi0gICAgIGlmIHRl c3QgLXogIiRFR1JFUCI7IHRoZW4KLSAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQotICAjIExv b3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUt TElTVAotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGly IGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgotZG8KLSAgSUZTPSRhc19zYXZl X0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19wcm9nIGlu IGVncmVwOyBkbwotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl bnNpb25zOyBkbwotICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVj X2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRh Y19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQotIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfRUdS RVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05VICRhY19w YXRoX0VHUkVQCi1jYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgotKkdO VSopCi0gIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2Zv dW5kPTo7OwotKikKLSAgYWNfY291bnQ9MAotICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25m dGVzdC5pbiIKLSAgd2hpbGUgOgotICBkbwotICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVz dC5pbiIgPiJjb25mdGVzdC50bXAiCi0gICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0Lmlu IgotICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgotICAgICRhc19lY2hvICdFR1JF UCcgPj4gImNvbmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29u ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawotICAgIGRpZmYg ImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKLSAg ICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKLSAgICBpZiB0 ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgotICAgICAgIyBC ZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25l Ci0gICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKLSAgICAgIGFjX3BhdGhf RUdSRVBfbWF4PSRhY19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5w dXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBi cmVhawotICBkb25lCi0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5u bCBjb25mdGVzdC5vdXQ7OwotZXNhYwotCi0gICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBi cmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLSAgaWYg dGVzdCAteiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIm5v IGFjY2VwdGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv dXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19jdl9wYXRoX0VHUkVQ PSRFR1JFUAotZmkKLQotICAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQotJGFzX2VjaG8gIiRhY19j dl9wYXRoX0VHUkVQIiA+JjY7IH0KLSBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCi0KLQoteyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBD IGhlYWRlciBmaWxlcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRl ciBmaWxlcy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9 IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBj b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5o LiAgKi8KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNpbmNsdWRl IDxzdHJpbmcuaD4KLSNpbmNsdWRlIDxmbG9hdC5oPgotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7 Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P IjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zdGRjPXllcwotZWxzZQotICBhY19jdl9oZWFkZXJf c3RkYz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg Y29uZnRlc3QuJGFjX2V4dAotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl bgotICAjIFN1bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5 IHRvIEFOU0kuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdHJpbmcuaD4KLQotX0FDRU9GCi1p ZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAibWVt Y2hyIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRj PW5vCi1maQotcm0gLWYgY29uZnRlc3QqCi0KLWZpCi0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9z dGRjID0geWVzOyB0aGVuCi0gICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUg ZnJlZSwgY29udHJhcnkgdG8gQU5TSS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGxpYi5o PgotCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwK LSAgJEVHUkVQICJmcmVlIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2 X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29uZnRlc3QqCi0KLWZpCi0KLWlmIHRlc3QgJGFj X2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCi0gICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdl dHMgbm9uLUFOU0kgY3R5cGUgbWFjcm9zIHVubGVzcyB1c2luZyAtYW5zaS4KLSAgaWYgdGVzdCAi JGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICA6Ci1lbHNlCi0gIGNhdCBjb25mZGVm cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K LSNpbmNsdWRlIDxjdHlwZS5oPgotI2luY2x1ZGUgPHN0ZGxpYi5oPgotI2lmICgoJyAnICYgMHgw RkYpID09IDB4MDIwKQotIyBkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0g J3onKQotIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScp IDogKGMpKQotI2Vsc2UKLSMgZGVmaW5lIElTTE9XRVIoYykgXAotCQkgICAoKCdhJyA8PSAoYykg JiYgKGMpIDw9ICdpJykgXAotCQkgICAgIHx8ICgnaicgPD0gKGMpICYmIChjKSA8PSAncicpIFwK LQkJICAgICB8fCAoJ3MnIDw9IChjKSAmJiAoYykgPD0gJ3onKSkKLSMgZGVmaW5lIFRPVVBQRVIo YykgKElTTE9XRVIoYykgPyAoKGMpIHwgMHg0MCkgOiAoYykpCi0jZW5kaWYKLQotI2RlZmluZSBY T1IoZSwgZikgKCgoZSkgJiYgIShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKLWludAotbWFpbiAoKQot ewotICBpbnQgaTsKLSAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQotICAgIGlmIChYT1IgKGlz bG93ZXIgKGkpLCBJU0xPV0VSIChpKSkKLQl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkK LSAgICAgIHJldHVybiAyOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlf cnVuICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZp Ci1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0 ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25m dGVzdC4kYWNfZXh0Ci1maQotCi1maQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9oZWFkZXJfc3RkYyIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHll czsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5o Ci0KLWZpCi0KLSMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29u ZmxpY3RpbmcuCi1mb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGli Lmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKLQkJICBpbnR0eXBlcy5oIHN0ZGludC5o IHVuaXN0ZC5oCi1kbyA6Ci0gIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8k YWNfaGVhZGVyIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRM SU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0 Ci0iCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6 Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRh Y19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCi0KLWZpCi0KLWRvbmUKLQotCi0KLSAg YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAi YWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0 ZXN0ICJ4JGFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotICBN SU5JWD15ZXMKLWVsc2UKLSAgTUlOSVg9Ci1maQotCi0KLSAgaWYgdGVzdCAiJE1JTklYIiA9IHll czsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMu aAotCi0KLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgK LQotCi0kYXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCi0KLSAgZmkKLQot Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1Ci0kYXNfZWNob19u ICJjaGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19f K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotCi0jCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKLQkgICRhY19pbmNs dWRlc19kZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FD RU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Nh ZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPXllcwotZWxzZQotICBhY19jdl9zYWZlX3RvX2Rl ZmluZV9fX2V4dGVuc2lvbnNfXz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0 ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl bnNpb25zX18iID4mNQotJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lv bnNfXyIgPiY2OyB9Ci0gIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19f ID0geWVzICYmCi0gICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25m ZGVmcy5oCi0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5o Ci0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCi0KLSAg JGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMu aAotCi0gICRhc19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAot Ci0KLSMgTWFrZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KLSRTSEVMTCAiJGFjX2F1eF9k aXIvY29uZmlnLnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKLSAgYXNfZm5fZXJyb3IgJD8g ImNhbm5vdCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1Ci0K LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQg c3lzdGVtIHR5cGUiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUu Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfYnVpbGQrc2V0fSIgPSBzZXQ7IHRoZW4gOgot ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19idWlsZF9hbGlhcz0kYnVp bGRfYWxpYXMKLXRlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgotICBhY19idWlsZF9hbGlh cz1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiYAotdGVzdCAieCRhY19idWlsZF9h bGlhcyIgPSB4ICYmCi0gIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsg eW91IG11c3Qgc3BlY2lmeSBvbmUiICIkTElORU5PIiA1Ci1hY19jdl9idWlsZD1gJFNIRUxMICIk YWNfYXV4X2Rpci9jb25maWcuc3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8Ci0gIGFzX2ZuX2Vycm9y ICQ/ICIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVk IiAiJExJTkVOTyIgNQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRhY19jdl9idWlsZCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+ JjY7IH0KLWNhc2UgJGFjX2N2X2J1aWxkIGluCi0qLSotKikgOzsKLSopIGFzX2ZuX2Vycm9yICQ/ ICJpbnZhbGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDUgOzsKLWVzYWMK LWJ1aWxkPSRhY19jdl9idWlsZAotYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJwotc2V0IHggJGFj X2N2X2J1aWxkCi1zaGlmdAotYnVpbGRfY3B1PSQxCi1idWlsZF92ZW5kb3I9JDIKLXNoaWZ0OyBz aGlmdAotIyBSZW1lbWJlciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBj cmVhdGUgJCosCi0jIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Ci1idWlsZF9vcz0kKgotSUZTPSRh Y19zYXZlX0lGUwotY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRfb3M9YGVjaG8gIiRidWls ZF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUiID4mNQotJGFzX2Vj aG9fbiAiY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHth Y19jdl9ob3N0K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+ JjYKLWVsc2UKLSAgaWYgdGVzdCAieCRob3N0X2FsaWFzIiA9IHg7IHRoZW4KLSAgYWNfY3ZfaG9z dD0kYWNfY3ZfYnVpbGQKLWVsc2UKLSAgYWNfY3ZfaG9zdD1gJFNIRUxMICIkYWNfYXV4X2Rpci9j b25maWcuc3ViIiAkaG9zdF9hbGlhc2AgfHwKLSAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRh Y19hdXhfZGlyL2NvbmZpZy5zdWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQotZmkK LQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk YWNfY3ZfaG9zdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2hvc3QiID4mNjsgfQotY2FzZSAkYWNf Y3ZfaG9zdCBpbgotKi0qLSopIDs7Ci0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1ZSBv ZiBjYW5vbmljYWwgaG9zdCIgIiRMSU5FTk8iIDUgOzsKLWVzYWMKLWhvc3Q9JGFjX2N2X2hvc3QK LWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKLXNldCB4ICRhY19jdl9ob3N0Ci1zaGlmdAotaG9z dF9jcHU9JDEKLWhvc3RfdmVuZG9yPSQyCi1zaGlmdDsgc2hpZnQKLSMgUmVtZW1iZXIsIHRoZSBm aXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAotIyBleGNlcHQgd2l0 aCBvbGQgc2hlbGxzOgotaG9zdF9vcz0kKgotSUZTPSRhY19zYXZlX0lGUwotY2FzZSAkaG9zdF9v cyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVz YWMKLQotCi0KLSMgTTQgTWFjcm8gaW5jbHVkZXMKLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQot Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0K LQotCi0KLQotCi0jIHBrZy5tNCAtIE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0aWxpc2UgcGtnLWNv bmZpZy4gICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCi0jIHNlcmlhbCAxIChwa2ctY29uZmln LTAuMjQpCi0jCi0jIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJlbW5hbnQgPHNjb3R0 QG5ldHNwbGl0LmNvbT4uCi0jCi0jIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Ci0jIGl0IHVuZGVyIHRoZSB0ZXJtcyBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Ci0jIHRoZSBG cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2Us IG9yCi0jIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCi0jCi0jIFRoaXMgcHJv Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBi dXQKLSMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJy YW50eSBvZgotIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuICBTZWUgdGhlIEdOVQotIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl dGFpbHMuCi0jCi0jIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBH ZW5lcmFsIFB1YmxpYyBMaWNlbnNlCi0jIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3Qs IHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCi0jIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBs ZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCi0jCi0jIEFz IGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBp ZiB5b3UKLSMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBj b250YWlucyBhCi0jIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwg eW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCi0jIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0 aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KLQotIyBQS0dfUFJPR19Q S0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KLSMgUEtHX1BST0dfUEtHX0NPTkZJRwotCi0jIFBLR19DSEVDS19FWElTVFMoTU9EVUxF UywgW0FDVElPTi1JRi1GT1VORF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKLSMKLSMgQ2hlY2sg dG8gc2VlIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4aXN0cy4gIFNpbWls YXIKLSMgdG8gUEtHX0NIRUNLX01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNldCB2YXJpYWJsZXMg b3IgcHJpbnQgZXJyb3JzLgotIwotIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBtNCBleHBhbmRzIEFD X1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKQotIyBvbmx5IGF0IHRoZSBmaXJzdCBvY2N1 cmVuY2UgaW4gY29uZmlndXJlLmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UKLSMgaXQncyBjYWxs ZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91 Ci0jIGhhdmUgdG8gY2FsbCBQS0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5Ci0jIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0KLQot IyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtNT0RVTEVTXSkKLSMgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIF9QS0dfQ09ORklHCi0K LSMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCi0jIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAotCi0KLSMgUEtHX0NIRUNLX01P RFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwKLSMgW0FD VElPTi1JRi1OT1QtRk9VTkRdKQotIwotIwotIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMgYSBwb3Nz aWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bwotIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3Qg aGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgotIyBleHBsaWNpdCBjYWxs IHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUuYWMKLSMKLSMKLSMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KLSMgUEtHX0NIRUNLX01PRFVMRVMKLQotCi0KLSMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5LCBQ VEhSRUFEX0NGTEFHUywgX0xERkxBR1MgYW5kIF9MSUJTCi0jIGV2ZW4gdGhvdWdoIGN1cnJlbnRs eSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCi0jIFRoaXMgbWVhbnMgdGhhdCB0 aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCi0jIHRoZSBmdXR1cmUgaWYg d2UgbWFrZSB0aGUgdGVzdCBtb3JlIHNvcGhpc3RpY2F0ZWQuCi0KLQotCi0jIFdlIGludm9rZSBB WF9QVEhSRUFEX1ZBUlMgd2l0aCB0aGUgbmFtZSBvZiBhbm90aGVyIG1hY3JvCi0jIHdoaWNoIGlz IHRoZW4gZXhwYW5kZWQgb25jZSBmb3IgZWFjaCB2YXJpYWJsZS4KLQotCi0KLQotCi0KLQotCi0j IEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0 dHAgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhl biA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX2dpdGh0dHA7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5h YmxlX2dpdGh0dHAiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfZ2l0aHR0cD0ibiIKLQot ZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9j dl9naXRodHRwPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgotCi0g ICAgYXhfY3ZfZ2l0aHR0cD0ibiIKLQotZmkKLWdpdGh0dHA9JGF4X2N2X2dpdGh0dHAKLQotCi0K LSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIk e2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxl X21vbml0b3JzOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsg dGhlbiA6Ci0KLSAgICBheF9jdl9tb25pdG9ycz0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9t b25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbW9uaXRvcnM9InkiCi0KLWVs aWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgotCi0gICAgYXhfY3ZfbW9uaXRvcnM9 InkiCi0KLWZpCi1tb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKLQotCi0KLSMgQ2hlY2sgd2hldGhl ciAtLWVuYWJsZS12dHBtIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3Z0cG0rc2V0fSIg PSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV92dHBtOwotZmkKLQotCi1pZiB0ZXN0 ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3Z0cG09Im4iCi0K LWVsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3Zf dnRwbT0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl92dHBtOyB0aGVuIDoKLQotICAgIGF4X2N2 X3Z0cG09Im4iCi0KLWZpCi12dHBtPSRheF9jdl92dHBtCi0KLQotCi0jIENoZWNrIHdoZXRoZXIg LS1lbmFibGUteGVuYXBpIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFwaTsKLWZpCi0KLQotaWYg dGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3hlbmFw aT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMiOyB0aGVuIDoKLQot ICAgIGF4X2N2X3hlbmFwaT0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl94ZW5hcGk7IHRoZW4g OgotCi0gICAgYXhfY3ZfeGVuYXBpPSJuIgotCi1maQoteGVuYXBpPSRheF9jdl94ZW5hcGkKLQot Ci0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1weXRob250b29scyB3YXMgZ2l2ZW4uCi1pZiB0 ZXN0ICIke2VuYWJsZV9weXRob250b29scytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZh bD0kZW5hYmxlX3B5dGhvbnRvb2xzOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250 b29scyIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9weXRob250b29scz0ibiIKLQotZWxp ZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250b29scyIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhf Y3ZfcHl0aG9udG9vbHM9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7IHRo ZW4gOgotCi0gICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCi0KLWZpCi1weXRob250b29scz0kYXhf Y3ZfcHl0aG9udG9vbHMKLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz IHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo ZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOwotZmkKLQotCi1pZiB0ZXN0ICJ4 JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X29jYW1sdG9v bHM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4g OgotCi0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9vY2Ft bHRvb2xzOyB0aGVuIDoKLQotICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCi0KLWZpCi1vY2FtbHRv b2xzPSRheF9jdl9vY2FtbHRvb2xzCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWlu aXRlcm0gd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7 IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9taW5pdGVybTsKLWZpCi0KLQotaWYgdGVzdCAi eCRlbmFibGVfbWluaXRlcm0iID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09 Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKLQot ICAgIGF4X2N2X21pbml0ZXJtPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0 aGVuIDoKLQotICAgIGF4X2N2X21pbml0ZXJtPSJuIgotCi1maQotbWluaXRlcm09JGF4X2N2X21p bml0ZXJtCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3YXMgZ2l2ZW4u Ci1pZiB0ZXN0ICIke2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxl dmFsPSRlbmFibGVfbG9tb3VudDsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfbG9tb3VudCIg PSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9sb21vdW50PSJuIgotCi1lbGlmIHRlc3QgIngk ZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X2xvbW91bnQ9Inki Ci0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6Ci0KLSAgICBheF9jdl9sb21v dW50PSJuIgotCi1maQotbG9tb3VudD0kYXhfY3ZfbG9tb3VudAotCi0KLQotIyBDaGVjayB3aGV0 aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfb3ZtZitzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX292bWY7Ci1maQotCi0KLWlmIHRl c3QgIngkZW5hYmxlX292bWYiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3Zfb3ZtZj0ibiIK LQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9j dl9vdm1mPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X292bWY7IHRoZW4gOgotCi0gICAgYXhf Y3Zfb3ZtZj0ibiIKLQotZmkKLW92bWY9JGF4X2N2X292bWYKKyMgTTQgTWFjcm8gaW5jbHVkZXMK IAogCiAKLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21iaW9zIHdhcyBnaXZlbi4KLWlmIHRl c3QgIiR7ZW5hYmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVu YWJsZV9yb21iaW9zOwotZmkKIAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9yb21iaW9zIiA9ICJ4bm8i OyB0aGVuIDoKIAotICAgIGF4X2N2X3JvbWJpb3M9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFibGVf cm9tYmlvcyIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9tYmlvcz0ieSIKIAotZWxp ZiB0ZXN0IC16ICRheF9jdl9yb21iaW9zOyB0aGVuIDoKIAotICAgIGF4X2N2X3JvbWJpb3M9Inki CiAKLWZpCi1yb21iaW9zPSRheF9jdl9yb21iaW9zCiAKIAogCi0jIENoZWNrIHdoZXRoZXIgLS1l bmFibGUtc2VhYmlvcyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9zZWFiaW9zK3NldH0i ID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfc2VhYmlvczsKLWZpCiAKIAotaWYg dGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICBheF9jdl9zZWFi aW9zPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3MiID0gInh5ZXMiOyB0aGVuIDoK IAotICAgIGF4X2N2X3NlYWJpb3M9InkiCiAKLWVsaWYgdGVzdCAteiAkYXhfY3Zfc2VhYmlvczsg dGhlbiA6CiAKLSAgICBheF9jdl9zZWFiaW9zPSJ5IgogCi1maQotc2VhYmlvcz0kYXhfY3Zfc2Vh YmlvcwogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWRlYnVnIHdhcyBnaXZlbi4KLWlm IHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRl bmFibGVfZGVidWc7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4bm8iOyB0 aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX2RlYnVn IiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9kZWJ1Zz0ieSIKIAotZWxpZiB0ZXN0IC16 ICRheF9jdl9kZWJ1ZzsgdGhlbiA6CiAKLSAgICBheF9jdl9kZWJ1Zz0ieSIKIAotZmkKLWRlYnVn PSRheF9jdl9kZWJ1ZwogCiAKIApAQCAtNDI0MCw5MzAgKzIyMjIsNDMyIEBAIGRlYnVnPSRheF9j dl9kZWJ1ZwogCiAKIAotZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCi1kbwotICAgIFBS RVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgotZG9uZQotZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9M SUIKLWRvCi0gICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKLWRvbmUKLWZvciBjZmxh ZyBpbiAkQVBQRU5EX0lOQ0xVREVTCi1kbwotICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWci Ci1kb25lCi1mb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCi1kbwotICAgIEFQUEVORF9MREZMQUdT Kz0iIC1MJGxkZmxhZyIKLWRvbmUKLUNGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQ UEVORF9DRkxBR1MiCi1MREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRf TERGTEFHUyIKIAogCiAKIAogCiAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRp bGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFsIDEg KHBrZy1jb25maWctMC4yNCkKKyMKKyMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQgSmFtZXMgUmVt bmFudCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29m dHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIg dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg YnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0 aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMK KyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi ZSB1c2VmdWwsIGJ1dAorIyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBp bXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCisjIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug Zm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyMgYWxvbmcgd2l0aCB0aGlzIHByb2dy YW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5j LiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVT QS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJv Z3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5 IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKKyMgdGhlIHNhbWUgZGlzdHJpYnV0 aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFtLgogCisj IFBLR19QUk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQorIyBQS0dfUFJPR19QS0dfQ09ORklHCiAKKyMgUEtHX0NIRUNLX0VY SVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQor IworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhp c3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0 IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0aGF0IG00 IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkgYXQgdGhl IGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQor IyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBh biAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKKyMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KIAogCisjIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNd KQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BL R19DT05GSUcKIAorIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyMgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECiAKIAorIyBQ S0dfQ0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9V TkRdLAorIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCisjCisjCisjIE5vdGUgdGhhdCBpZiB0aGVy ZSBpcyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRvCisjIFBLR19DSEVDS19NT0RVTEVT IG1pZ2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCisjIGV4 cGxpY2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwor IworIworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQorIyBQS0dfQ0hFQ0tfTU9EVUxFUwogCi0jIENoZWNrcyBmb3IgcHJvZ3Jh bXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dCIgPiY1Ci0kYXNfZWNob19uICJj aGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4gIiA+JjY7 IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9TRUQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICAgICAgICAgICAgYWNfc2NyaXB0PXMvYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEvYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi YmJiYmJiYmJiLwotICAgICBmb3IgYWNfaSBpbiAxIDIgMyA0IDUgNiA3OyBkbwotICAgICAgIGFj X3NjcmlwdD0iJGFjX3NjcmlwdCRhc19ubCRhY19zY3JpcHQiCi0gICAgIGRvbmUKLSAgICAgZWNo byAiJGFjX3NjcmlwdCIgMj4vZGV2L251bGwgfCBzZWQgOTlxID5jb25mdGVzdC5zZWQKLSAgICAg eyBhY19zY3JpcHQ9OyB1bnNldCBhY19zY3JpcHQ7fQotICAgICBpZiB0ZXN0IC16ICIkU0VEIjsg dGhlbgotICBhY19wYXRoX1NFRF9mb3VuZD1mYWxzZQotICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAotICBhc19zYXZlX0lG Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJ RlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9y IGFjX3Byb2cgaW4gc2VkIGdzZWQ7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gICAgICBhY19wYXRoX1NFRD0iJGFzX2Rpci8kYWNf cHJvZyRhY19leGVjX2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfU0VEIiAmJiAkYXNf dGVzdF94ICIkYWNfcGF0aF9TRUQiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNf cGF0aF9TRUQgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05V ICRhY19wYXRoX1NFRAotY2FzZSBgIiRhY19wYXRoX1NFRCIgLS12ZXJzaW9uIDI+JjFgIGluCi0q R05VKikKLSAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRoX1NFRCIgYWNfcGF0aF9TRURfZm91bmQ9 Ojs7Ci0qKQotICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0 LmluIgotICB3aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lmlu IiA+ImNvbmZ0ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCi0g ICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2VjaG8gJycgPj4gImNv bmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9TRUQiIC1mIGNvbmZ0ZXN0LnNlZCA8ICJjb25mdGVz dC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCi0gICAgZGlmZiAiY29u ZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawotICAgIGFz X2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAotICAgIGlmIHRlc3Qg JGFjX2NvdW50IC1ndCAke2FjX3BhdGhfU0VEX21heC0wfTsgdGhlbgotICAgICAgIyBCZXN0IG9u ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCi0gICAg ICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIgotICAgICAgYWNfcGF0aF9TRURfbWF4PSRh Y19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9y ZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawotICBkb25l Ci0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5v dXQ7OwotZXNhYwogCi0gICAgICAkYWNfcGF0aF9TRURfZm91bmQgJiYgYnJlYWsgMwotICAgIGRv bmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0gIGlmIHRlc3QgLXogIiRhY19j dl9wYXRoX1NFRCI7IHRoZW4KLSAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBzZWQg Y291bGQgYmUgZm91bmQgaW4gXCRQQVRIIiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19j dl9wYXRoX1NFRD0kU0VECi1maQogCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX1NFRCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2 X3BhdGhfU0VEIiA+JjY7IH0KLSBTRUQ9IiRhY19jdl9wYXRoX1NFRCIKLSAgcm0gLWYgY29uZnRl c3Quc2VkCisjIFdlIGRlZmluZSwgc2VwYXJhdGVseSwgUFRIUkVBRF9DRkxBR1MsIF9MREZMQUdT IGFuZCBfTElCUworIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0IHRoZW0gdmVy eSBzZXBhcmF0ZWx5LgorIyBUaGlzIG1lYW5zIHRoYXQgdGhlIG1ha2VmaWxlcyB3aWxsIG5vdCBu ZWVkIHRvIGNoYW5nZSBpbgorIyB0aGUgZnV0dXJlIGlmIHdlIG1ha2UgdGhlIHRlc3QgbW9yZSBz b3BoaXN0aWNhdGVkLgogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2Nv bXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFj X2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxB R1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2Nf Y29tcGlsZXJfZ251Ci1pZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9 Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4g IiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2NjIgotICAgICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZT PSRhc19zYXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi bm8iID4mNjsgfQotZmkKIAorIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJTIHdpdGggdGhlIG5h bWUgb2YgYW5vdGhlciBtYWNybworIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVkIG9uY2UgZm9yIGVh Y2ggdmFyaWFibGUuCiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAg YWNfY3RfQ0M9JENDCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQg Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9 JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0 X0NDIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1 c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI X1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwot ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAn JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZT PSRhc19zYXZlX0lGUwogCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1p ZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9D QyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKIAotICBpZiB0ZXN0 ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jv c3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6 IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K LWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZWxz ZQotICBDQz0iJGFjX2N2X3Byb2dfQ0MiCi1maQogCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0g ICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAgICMgRXh0cmFj dCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBh IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsg YWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj a2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4g OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0Mi OyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3Ig YXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19k aXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl X2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo ZW4KLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgotICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19z YXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0 aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk Q0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4m NjsgfQotZmkKIAogCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJh Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp dGggYXJncy4KLXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By b2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgot ZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9 bm8KLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4g JFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf ZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u czsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlm IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl bgotICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkK LSAgICBhY19jdl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBi cmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotaWYgdGVzdCAk YWNfcHJvZ19yZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhl IHBhdGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3Zf cHJvZ19DQwotICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3Nl IGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIs IGl0IGhhcyB0aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0g ICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVs bCBmaWxlIG5hbWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193 b3JkJHsxKycgJ30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0 ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k YXNfZWNobyAibm8iID4mNjsgfQorIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCisKKyMgQ2hlY2sg d2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dp dGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOwog ZmkKIAogCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0IC1uICIkYWNfdG9v bF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBkbwotICAgICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBzbyBpdCBj YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRhY190b29sX3ByZWZp eCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9 IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRl c3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBv dmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB UkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVz dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9n IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAg ZG9uZQotSUZTPSRhc19zYXZlX0lGUworaWYgdGVzdCAieCRlbmFibGVfZ2l0aHR0cCIgPSAieG5v IjsgdGhlbiA6CiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7 IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIg PiY2OyB9Ci1maQorICAgIGF4X2N2X2dpdGh0dHA9Im4iCiAKK2VsaWYgdGVzdCAieCRlbmFibGVf Z2l0aHR0cCIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgdGVzdCAtbiAiJENDIiAmJiBicmVhawot ICBkb25lCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBhY19jdF9DQz0kQ0MKLSAgZm9y IGFjX3Byb2cgaW4gY2wuZXhlCi1kbwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRh Y19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1t eSAkYWNfcHJvZzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mr c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot ICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRh Y19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZl X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwot ICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAg Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlm IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2Fj X2N0X0NDPSIkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAy Ci0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKKyAgICBheF9jdl9naXRodHRw PSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgorCisgICAgYXhfY3Zf Z2l0aHR0cD0ibiIKIAogZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQwotaWYg dGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfQ0Mi ID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCitnaXRodHRwPSRheF9j dl9naXRodHRwCiAKIAotICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCi1kb25lCiAKLSAg aWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQotICAgIGNh c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBX QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi ID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3RfQ0MKLSAg ZmkKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2ZW4uCitpZiB0ZXN0 ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h YmxlX21vbml0b3JzOwogZmkKIAotZmkKIAoraWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0g InhubyI7IHRoZW4gOgogCi10ZXN0IC16ICIkQ0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8g IiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIm5v IGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBcJFBBVEgKLVNlZSBcYGNvbmZpZy5sb2cn IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGF4X2N2X21vbml0b3JzPSJu IgogCi0jIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCi0kYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxl ciB2ZXJzaW9uIiA+JjUKLXNldCBYICRhY19jb21waWxlCi1hY19jb21waWxlcj0kMgotZm9yIGFj X29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwotICB7IHsgYWNfdHJ5PSIk YWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCi1jYXNlICIoKCRhY190cnkiIGluCi0gICpcIiog fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190cnlfZWNobz0k YWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK LSAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCi0g IGFjX3N0YXR1cz0kPwotICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgotICAgIHNlZCAn MTBhXAotLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgotICAgICAgICAgMTBx JyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQotICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Ci0g IGZpCi0gIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKLSAgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFj X3N0YXR1cyA9IDA7IH0KLWRvbmUKK2VsaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5 ZXMiOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVy Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0iID0gc2V0 OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZk ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq LworICAgIGF4X2N2X21vbml0b3JzPSJ5IgogCi1pbnQKLW1haW4gKCkKLXsKLSNpZm5kZWYgX19H TlVDX18KLSAgICAgICBjaG9rZSBtZQotI2VuZGlmCitlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0 b3JzOyB0aGVuIDoKIAotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBpbGVyX2dudT15ZXMKLWVsc2UK LSAgYWNfY29tcGlsZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9jX2NvbXBpbGVyX2dudT0kYWNf Y29tcGlsZXJfZ251CisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCiAKIGZpCi17ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251 IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQotaWYgdGVzdCAk YWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCi0gIEdDQz15ZXMKLWVsc2UKLSAgR0NDPQotZmkK LWFjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KLWFjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKLXsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAk Q0MgYWNjZXB0cyAtZyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2Nl cHRzIC1nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfZytzZXR9IiA9IHNl dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX3NhdmVf Y193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZwotICAgYWNfY193ZXJyb3JfZmxhZz15ZXMK LSAgIGFjX2N2X3Byb2dfY2NfZz1ubwotICAgQ0ZMQUdTPSItZyIKLSAgIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KK21v bml0b3JzPSRheF9jdl9tb25pdG9ycwogCi1pbnQKLW1haW4gKCkKLXsKIAotICA7Ci0gIHJldHVy biAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6 Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAgICBjYXQgY29u ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4g ICovCiAKLWludAotbWFpbiAoKQoteworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2Fz IGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu YWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQogCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YK LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKIAotZWxzZQotICBhY19j X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIKLQkgY2F0 IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz LmguICAqLworaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CiAKLWludAot bWFpbiAoKQoteworICAgIGF4X2N2X3Z0cG09Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRw bSIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ieSIKKworZWxpZiB0ZXN0IC16 ICRheF9jdl92dHBtOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCiAKLSAgOwotICByZXR1 cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g OgotICBhY19jdl9wcm9nX2NjX2c9eWVzCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29y ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICBh Y19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLWZpCi17ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1 Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9Ci1pZiB0ZXN0ICIkYWNfdGVzdF9D RkxBR1MiID0gc2V0OyB0aGVuCi0gIENGTEFHUz0kYWNfc2F2ZV9DRkxBR1MKLWVsaWYgdGVzdCAk YWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVuCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVu Ci0gICAgQ0ZMQUdTPSItZyAtTzIiCi0gIGVsc2UKLSAgICBDRkxBR1M9Ii1nIgotICBmaQotZWxz ZQotICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgotICAgIENGTEFHUz0iLU8yIgotICBlbHNl Ci0gICAgQ0ZMQUdTPQotICBmaQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4g OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jdl9wcm9nX2NjX2M4 OT1ubwotYWNfc2F2ZV9DQz0kQ0MKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0 LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNp bmNsdWRlIDxzdGRpby5oPgotI2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy9z dGF0Lmg+Ci0vKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJD UyA1LjcncyBzcmMvY29uZi5zaC4gICovCi1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Ci1GSUxFICog KCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwotc3RhdGljIGNo YXIgKmUgKHAsIGkpCi0gICAgIGNoYXIgKipwOwotICAgICBpbnQgaTsKLXsKLSAgcmV0dXJuIHBb aV07Ci19Ci1zdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIg KipwLCAuLi4pCi17Ci0gIGNoYXIgKnM7Ci0gIHZhX2xpc3QgdjsKLSAgdmFfc3RhcnQgKHYscCk7 Ci0gIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7Ci0gIHZhX2VuZCAodik7Ci0gIHJldHVybiBz OwotfQordnRwbT0kYXhfY3ZfdnRwbQogCi0vKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21lIHNv cnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwotICAgZnVuY3Rpb24gcHJvdG90 eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRzLgot ICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFkIGFy ZSBzaWxlbnRseSB0cmVhdGVkCi0gICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMgYW4g ZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0Ci0gICBwcm9wZXIgQU5TSSBtb2RlLiAg Q3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCi0gICBh cnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRv IGdldCBzb21ldGhpbmcKLSAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KLWludCBv c2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CiAKLS8qIElCTSBDIDYgZm9yIEFJ WCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1l dGVycwotICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwotI2Rl ZmluZSBGT08oeCkgJ3gnCi1pbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0x XTsKIAotaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7Ci1zdHJ1Y3QgczEge2ludCAoKmYpIChp bnQgYSk7fTsKLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OwotaW50IHBhaXJuYW1l cyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBp bnQpLCBpbnQsIGludCk7Ci1pbnQgYXJnYzsKLWNoYXIgKiphcmd2OwotaW50Ci1tYWluICgpCi17 Ci1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEpICE9 IGFyZ3ZbMV07Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWZvciBhY19hcmcgaW4gJycg LXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKLQktQWUgIi1BYSAtRF9IUFVY X1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgotZG8KLSAgQ0M9IiRhY19zYXZlX0NDICRh Y19hcmciCi0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf Y3ZfcHJvZ19jY19jODk9JGFjX2FyZworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFwaSB3 YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4gOgor ICBlbmFibGV2YWw9JGVuYWJsZV94ZW5hcGk7CiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg Y29uZnRlc3QuJGFjX29iamV4dAotICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSAieG5v IiAmJiBicmVhawotZG9uZQotcm0gLWYgY29uZnRlc3QuJGFjX2V4dAotQ0M9JGFjX3NhdmVfQ0MK KworCitpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhf Y3ZfeGVuYXBpPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieHllcyI7IHRo ZW4gOgorCisgICAgYXhfY3ZfeGVuYXBpPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFw aTsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9Im4iCiAKIGZpCi0jIEFDX0NBQ0hFX1ZBTAot Y2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KLSAgeCkKLSAgICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQotJGFzX2Vj aG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKLSAgeG5vKQotICAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Ci0kYXNfZWNo byAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OwotICAqKQotICAgIENDPSIkQ0MgJGFjX2N2X3Byb2df Y2NfYzg5IgotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQotJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4 OSIgPiY2OyB9IDs7Ci1lc2FjCi1pZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87 IHRoZW4gOgoreGVuYXBpPSRheF9jdl94ZW5hcGkKKwogCisKKyMgQ2hlY2sgd2hldGhlciAtLWVu YWJsZS1weXRob250b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9weXRob250b29s cytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwog ZmkKIAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0Mg LWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0Mg LW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0 LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2du dQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdo ZXRoZXIgbG4gLXMgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsbiAt cyB3b3Jrcy4uLiAiID4mNjsgfQotTE5fUz0kYXNfbG5fcwotaWYgdGVzdCAiJExOX1MiID0gImxu IC1zIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+ JjUKLSRhc19lY2hvICJubywgdXNpbmcgJExOX1MiID4mNjsgfQoraWYgdGVzdCAieCRlbmFibGVf cHl0aG9udG9vbHMiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4i CisKK2VsaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKwor ICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRv b2xzOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCiBmaQorcHl0aG9udG9v bHM9JGF4X2N2X3B5dGhvbnRvb2xzCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1 Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0Up Li4uICIgPiY2OyB9Ci1zZXQgeCAke01BS0UtbWFrZX0KLWFjX21ha2U9YCRhc19lY2hvICIkMiIg fCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAotaWYgZXZhbCAidGVzdCBcIlwk e2FjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAg JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0ID5jb25mdGVzdC5tYWtlIDw8 XF9BQ0VPRgotU0hFTEwgPSAvYmluL3NoCi1hbGw6Ci0JQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBA QCUlJScKLV9BQ0VPRgotIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRl cmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgotY2FzZSBgJHtNQUtFLW1ha2V9IC1m IGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCi0gICpAQEAlJSU9Pyo9QEBAJSUlKikKLSAg ICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OwotICAqKQotICAgIGV2 YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKLWVzYWMKLXJtIC1mIGNvbmZ0 ZXN0Lm1ha2UKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2 ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg ZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKIGZpCi1pZiBldmFsIHRlc3QgXCRhY19jdl9w cm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNobyAieWVzIiA+ JjY7IH0KLSAgU0VUX01BS0U9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICBTRVRf TUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29s cyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRl c3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29j YW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisK KyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgorCiBmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0 b29scwogCi0jIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJv Z3JhbSAoZmFzdGVyKSwKLSMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBC dXQgYXZvaWQgdGhlIGJyb2tlbiBvcgotIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6Ci0jIFN5c1Yg L2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAotIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxs Ci0jIElSSVggL3NiaW4vaW5zdGFsbAotIyBBSVggL2Jpbi9pbnN0YWxsCi0jIEFtaWdhT1MgL0Mv aW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKLSMgQUlY IDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBm bGFnCi0jIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4 aXN0ZW50IGFyZ3MKLSMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2Ug dGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKLSMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3 aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYwotIyAuL2luc3RhbGwsIHdo aWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2gu Ci0jIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUg ZmlsZXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQotaWYgdGVzdCAteiAiJElO U1RBTEwiOyB0aGVuCi1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFzX3NhdmVfSUZT PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElG Uz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICAjIEFj Y291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50 cy4KLWNhc2UgJGFzX2Rpci8gaW4gIygoCi0gIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKLSAgL2V0 Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmlu LyogfCBcCi0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11J TlNUQUxMW1xcL10qIHwgXAotICAvdXNyL3VjYi8qICkgOzsKLSAgKikKLSAgICAjIE9TRjEgYW5k IFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgotICAgICMgRG9u J3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9v dAotICAgICMgYnkgZGVmYXVsdC4KLSAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0 IGluc3RhbGw7IGRvCi0gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KLQlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVu Ci0JICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIGRzcG1zZyAiJGFz X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCi0JICAgICMg QUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4K LQkgICAgOgotCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIHB3 cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu Ci0JICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1 cy0tZG9uJ3QgdXNlLgotCSAgICA6Ci0JICBlbHNlCi0JICAgIHJtIC1yZiBjb25mdGVzdC5vbmUg Y29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgotCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQot CSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bwotCSAgICBta2RpciBjb25mdGVzdC5kaXIKLQkg ICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25m dGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKLQkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0 Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3Qu ZGlyL2NvbmZ0ZXN0Lm9uZSAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0 LnR3bwotCSAgICB0aGVuCi0JICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19w cm9nJGFjX2V4ZWNfZXh0IC1jIgotCSAgICAgIGJyZWFrIDMKLQkgICAgZmkKLQkgIGZpCi0JZmkK LSAgICAgIGRvbmUKLSAgICBkb25lCi0gICAgOzsKLWVzYWMKIAotICBkb25lCi1JRlM9JGFzX3Nh dmVfSUZTCiAKLXJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgor IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0ZXJtIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7 ZW5hYmxlX21pbml0ZXJtK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVf bWluaXRlcm07CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0 aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX21p bml0ZXJtIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9taW5pdGVybT0ieSIKKworZWxp ZiB0ZXN0IC16ICRheF9jdl9taW5pdGVybTsgdGhlbiA6CisKKyAgICBheF9jdl9taW5pdGVybT0i biIKIAogZmkKLSAgaWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo ZW4KLSAgICBJTlNUQUxMPSRhY19jdl9wYXRoX2luc3RhbGwKLSAgZWxzZQotICAgICMgQXMgYSBs YXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKLSAg ICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhpbiBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2Ug dGhhdCB3aWxsCi0gICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYg dGhhdCBkaXJlY3RvcnkgaXMKLSAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJl bGF0aXZlIG5hbWUuCi0gICAgSU5TVEFMTD0kYWNfaW5zdGFsbF9zaAotICBmaQorbWluaXRlcm09 JGF4X2N2X21pbml0ZXJtCisKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3 YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoK KyAgZW5hYmxldmFsPSRlbmFibGVfbG9tb3VudDsKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElOU1RBTEwiID4mNQotJGFzX2VjaG8gIiRJTlNU QUxMIiA+JjY7IH0KIAotIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5kbGVz IGJyYWNlcyBpbiAke3Zhci12YWx9LgotIyBJdCB0aGlua3MgdGhlIGZpcnN0IGNsb3NlIGJyYWNl IGVuZHMgdGhlIHZhcmlhYmxlIHN1YnN0aXR1dGlvbi4KLXRlc3QgLXogIiRJTlNUQUxMX1BST0dS QU0iICYmIElOU1RBTExfUFJPR1JBTT0nJHtJTlNUQUxMfScKIAotdGVzdCAteiAiJElOU1RBTExf U0NSSVBUIiAmJiBJTlNUQUxMX1NDUklQVD0nJHtJTlNUQUxMfScKK2lmIHRlc3QgIngkZW5hYmxl X2xvbW91bnQiID0gInhubyI7IHRoZW4gOgogCi10ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJ TlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworICAgIGF4X2N2X2xvbW91bnQ9Im4iCiAK LSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmlzb24iLCBzbyBpdCBjYW4gYmUgYSBwcm9n cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcGF0aF9CSVNPTitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJEJJU09OIGluCi0gIFtcXC9dKiB8ID86W1xc L10qKQotICBhY19jdl9wYXRoX0JJU09OPSIkQklTT04iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JJU09OPSIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJy ZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworZWxpZiB0ZXN0ICJ4 JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJ5 IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9t b3VudD0ibiIKIAotICA7OwotZXNhYwogZmkKLUJJU09OPSRhY19jdl9wYXRoX0JJU09OCi1pZiB0 ZXN0IC1uICIkQklTT04iOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkQklTT04iID4mNQotJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9Ci1l bHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu byIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorbG9tb3VudD0kYXhfY3ZfbG9tb3VudAorCisK KworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtl bmFibGVfb3ZtZitzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX292bWY7 CiBmaQogCiAKLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBi ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgot eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9 Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJEZMRVggaW4KLSAgW1xcL10qIHwg PzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJy aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZT OyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFz X3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4 ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAt ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAg YnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4 JGVuYWJsZV9vdm1mIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X292bWY9Im4iCisKK2Vs aWYgdGVzdCAieCRlbmFibGVfb3ZtZiIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3Zfb3Zt Zj0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vdm1mOyB0aGVuIDoKKworICAgIGF4X2N2X292 bWY9Im4iCiAKLSAgOzsKLWVzYWMKIGZpCi1GTEVYPSRhY19jdl9wYXRoX0ZMRVgKLWlmIHRlc3Qg LW4gIiRGTEVYIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJEZMRVgiID4mNQotJGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KLWVsc2UKLSAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK LSRhc19lY2hvICJubyIgPiY2OyB9Citvdm1mPSRheF9jdl9vdm1mCisKKworCisjIENoZWNrIHdo ZXRoZXIgLS1lbmFibGUtcm9tYmlvcyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9yb21i aW9zK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcm9tYmlvczsKIGZp CiAKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwZXJsIiwgc28gaXQgY2FuIGJlIGEg cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBwZXJsOyBhY193b3JkPSQyCi17ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y ZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJMK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkUEVSTCBpbgotICBbXFwvXSogfCA/Oltc XC9dKikKLSAgYWNfY3ZfcGF0aF9QRVJMPSIkUEVSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg dGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElG Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2 ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVh ayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK2lmIHRlc3QgIngkZW5h YmxlX3JvbWJpb3MiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfcm9tYmlvcz0ibiIKKwor ZWxpZiB0ZXN0ICJ4JGVuYWJsZV9yb21iaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9j dl9yb21iaW9zPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgorCisg ICAgYXhfY3Zfcm9tYmlvcz0ieSIKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QRVJMIiAmJiBh Y19jdl9wYXRoX1BFUkw9Im5vIgotICA7OwotZXNhYwogZmkKLVBFUkw9JGFjX2N2X3BhdGhfUEVS TAotaWYgdGVzdCAtbiAiJFBFUkwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1Ci0kYXNfZWNobyAiJFBFUkwiID4mNjsg fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK3JvbWJpb3M9JGF4X2N2X3JvbWJpb3MK KworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KK2lmIHRl c3QgIiR7ZW5hYmxlX3NlYWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVu YWJsZV9zZWFiaW9zOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9zZWFiaW9zIiA9ICJ4bm8i OyB0aGVuIDoKKworICAgIGF4X2N2X3NlYWJpb3M9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVf c2VhYmlvcyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3Zfc2VhYmlvcz0ieSIKKworZWxp ZiB0ZXN0IC16ICRheF9jdl9zZWFiaW9zOyB0aGVuIDoKKworICAgIGF4X2N2X3NlYWJpb3M9Inki CisKK2ZpCitzZWFiaW9zPSRheF9jdl9zZWFiaW9zCisKKworCisjIENoZWNrIHdoZXRoZXIgLS1l bmFibGUtZGVidWcgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfZGVidWcrc2V0fSIgPSBz ZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKK2ZpCisKKworaWYgdGVzdCAi eCRlbmFibGVfZGVidWciID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9Im4iCisK K2VsaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2 X2RlYnVnPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKKworICAgIGF4 X2N2X2RlYnVnPSJ5IgorCiBmaQorZGVidWc9JGF4X2N2X2RlYnVnCisKKworCisKKworCisKKwor Zm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0i IC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJF UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lO Q0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRm bGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIK K2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitM REZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyIKKworCiAK IAotaWYgdGVzdCB4IiR7UEVSTH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8g IlVuYWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1Ci1m aQotaWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgogCi0gICAgIyBFeHRyYWN0IHRoZSBm aXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3 aXRoIGFyZ3MuCi1zZXQgZHVtbXkgY3VybC1jb25maWc7IGFjX3dvcmQ9JDIKKworCisKKworCisK KworCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQ UEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRh Y19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRD UFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVy X2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7 IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdj YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHth Y190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0NV Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0g c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAk Q1VSTCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9DVVJMPSIkQ1VSTCIg IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICop Ci0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAi JENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgog Zm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIk YXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0 YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9 OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2NjIgogICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUxNzEsNDQgKzI2NTUsMzkgQEAg ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf Q1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1DVVJMPSRhY19j dl9wYXRoX0NVUkwKLWlmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENVUkwiID4mNQotJGFzX2VjaG8gIiRD VVJMIiA+JjY7IH0KK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhl bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEND IiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7 IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7Q1VSTH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5f ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJs LWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZpCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m ICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z ZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9n X0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m ICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15 IGdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh Y193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhl biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJFhNTCBpbgot ICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1 c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZl X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7 IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBv dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB UkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVz dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfWE1MPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01MjE2LDM5ICsyNjk1LDQzIEBAIGRvbmUK ICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIg JiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgotICA7OwotZXNhYwogZmkKLVhNTD0kYWNfY3ZfcGF0aF9Y TUwKLWlmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkWE1MIiA+JjUKLSRhc19lY2hvICIkWE1MIiA+JjY7IH0K K2ZpCithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0ND IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQogZWxzZQogICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIK LXRoZW4KLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBs ZWFzZSBpbnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQotZmkKLQorICBpZiB0ZXN0ICJ4 JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3Nf Y29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVz aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2Fj X3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQorZWxzZQor ICBDQz0iJGFjX2N2X3Byb2dfQ0MiCiBmaQotaWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7 IHRoZW4gOgogCi0gICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKLSAgaWYgdGVzdCAtbiAiJGFj X3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf dG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoraWYgdGVz dCAteiAiJENDIjsgdGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7 IHRoZW4KKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9 Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7 YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09D QU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIg PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0 ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MQz0iJE9DQU1MQyIgIyBM ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4K KyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K IGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIg aW4gJFBBVEgKQEAgLTUyNTcsNyArMjc0MCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYm IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg ICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3ByZWZpeH1vY2FtbGMiCisgICAgYWNfY3Zf cHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK ICAgICBicmVhayAyCiAgIGZpCkBAIC01MjY3LDI5ICsyNzUwLDMwIEBAIElGUz0kYXNfc2F2ZV9J RlMKIAogZmkKIGZpCi1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCi1pZiB0ZXN0IC1uICIkT0NB TUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJE9DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CitDQz0kYWNfY3Zf cHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsg fQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAorICBmaQogZmkKLWlmIHRl c3QgLXogIiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KLSAgYWNfY3RfT0NBTUxDPSRPQ0FNTEMK LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBw cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgoraWYg dGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjYzsgYWNf d29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6CiAg ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9P Q0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAj IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhl bgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0 LgogZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwpAQCAtNTI5Nyw3ICsyNzgxLDEx IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNf ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0i b2NhbWxjIgorICAgIGlmIHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91 c3IvdWNiL2NjIjsgdGhlbgorICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29u dGludWUKKyAgICAgZmkKKyAgICBhY19jdl9wcm9nX0NDPSJjYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01MzA1LDYxICsyNzkzLDQ0IEBAIGRvbmUK ICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0g eWVzOyB0aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJl IHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0Cisg IGlmIHRlc3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGls ZXIgZnJvbSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJh c2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNl dCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBz aGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBm aQogZmkKIGZpCi1hY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDCi1pZiB0ZXN0 IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0 X09DQU1MQyIgPiY2OyB9CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7 IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIg PiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9IHg7IHRoZW4KLSAgICBP Q0FNTEM9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dh cm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0 IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBw cmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7Owot ZXNhYwotICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCi0gIGZpCi1lbHNlCi0gIE9DQU1MQz0iJGFj X2N2X3Byb2dfT0NBTUxDIgotZmkKLQotCi0gIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRo ZW4KLSAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv biogKlwoLipcKSR8XDF8cCdgCi0gICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNQotJGFz X2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2OyB9Ci0gICAgICMgSWYg T0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKLSAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0 aGVuCi0gICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NB TUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAotICAgICBlbHNlCi0gICAgICAgIHsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ0FNTExJQiBwcmV2 aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQotJGFzX2VjaG8gIk9DQU1MTElCIHByZXZp b3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9Ci0gICAgIGZpCi0gICAgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCBsaWJyYXJ5IHBh dGggaXMgJE9DQU1MTElCIiA+JjUKLSRhc19lY2hvICJPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9D QU1MTElCIiA+JjY7IH0KLQotCiAKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAotICAg ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmly c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9w dDsgYWNfd29yZD0kMgorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAtbiAi JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8KKyAg ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNfdG9v bF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB TUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i ID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYg dGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxP UFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIkQ0Mi OyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig YXNfZGlyIGluICRQQVRICkBAIC01MzY4LDcgKzI4MzksNyBAQCBkbwogICB0ZXN0IC16ICIkYXNf ZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs ZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0 aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIK KyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKICAgICAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01Mzc4LDI4ICsyODQ5LDMyIEBA IElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9Q VAotaWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKLSRhc19lY2hvICIkT0NB TUxPUFQiID4mNjsgfQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIg PiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9 CiBmaQogCiAKKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKIGZpCi1pZiB0ZXN0 IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1M T1BUCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3Jk PSQyCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJv ZyBpbiBjbC5leGUKK2RvCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ci LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19w cm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtz ZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIg PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0 ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxP UFQ9IiRhY19jdF9PQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisg IGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFj X2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTU0 MDgsNyArMjg4Myw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAg Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlm IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2Fj X2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfcHJv ZyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01NDE2 LDE5ICsyODkxLDIzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi1maQotZmkK LWFjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCi1pZiB0ZXN0IC1uICIk YWNfY3RfT0NBTUxPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQotJGFzX2VjaG8gIiRhY19jdF9P Q0FNTE9QVCIgPiY2OyB9CitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitp ZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9D QyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0 ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE9QVD0ibm8iCisKKyAgdGVz dCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0Mi ID0geDsgdGhlbgorICAgIENDPSIiCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6 JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNTQzNiwzOTYgKzI5MTUsNjQ5IEBAIHllczop CiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4 ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CiBhY190b29sX3dhcm5lZD15ZXMgOzsKIGVzYWMK LSAgICBPQ0FNTE9QVD0kYWNfY3RfT0NBTUxPUFQKKyAgICBDQz0kYWNfY3RfQ0MKICAgZmkKLWVs c2UKLSAgT0NBTUxPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BUIgogZmkKIAotICAgICBPQ0FNTEJF U1Q9Ynl0ZQotICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgotCXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZpbmQgb2Nh bWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjUKLSRhc19lY2hvICIkYXNfbWU6 IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5 LiIgPiYyO30KLSAgICAgZWxzZQotCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAt ZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKLQlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIg IT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgotCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2Nh bWxvcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j YW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLiIgPiY2OyB9Ci0JICAgIE9DQU1MT1BUPW5vCi0JZWxz ZQotCSAgICBPQ0FNTEJFU1Q9b3B0CitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg PiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19m bl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2Vl IFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJv dmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24i ID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGlu IC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxl ciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAq XFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owor ZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk YWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAi JGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVz PSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4g cmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0 LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0g LWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfQorZG9uZQorCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0 dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCith Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5v dXQiCisjIFRyeSB0byBjcmVhdGUgYW4gZXhlY3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNy ZWdhcmQgYS5vdXQuCisjIEl0IHdpbGwgaGVscCB1cyBkaWFnbm9zZSBicm9rZW4gY29tcGlsZXJz LCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0aW9uCisjIG9mIGV4ZWV4dC4KK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21w aWxlciB3b3JrcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBp bGVyIHdvcmtzLi4uICIgPiY2OyB9CithY19saW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGlu ayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFteIF0qLy8nYAorCisjIFRoZSBwb3NzaWJsZSBvdXRw dXQgZmlsZXM6CithY19maWxlcz0iYS5vdXQgY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFf b3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgorCithY19ybWZpbGVzPQorZm9yIGFjX2ZpbGUgaW4g JGFjX2ZpbGVzCitkbworICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29m ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8 ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OworICAgICogKSBhY19ybWZpbGVzPSIk YWNfcm1maWxlcyAkYWNfZmlsZSI7OworICBlc2FjCitkb25lCitybSAtZiAkYWNfcm1maWxlcwor CitpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgor ICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5 X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7 IH0gPiY1CisgIChldmFsICIkYWNfbGlua19kZWZhdWx0IikgMj4mNQorICBhY19zdGF0dXM9JD8K KyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1 cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICAjIEF1dG9jb25mLTIu MTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVleHQgdmFyaWFibGUgdG8gYG5vJy4KKyMgU28gaWdu b3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhU ID0gbm8nCisjIGluIGEgTWFrZWZpbGUuICBXZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4 ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAorIyBzbyB0aGF0IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJj dWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJzIHVua25vd24gdG8KKyMgQXV0b2NvbmYuCitmb3Ig YWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKK2RvCisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250 aW51ZQorICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRz IHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwg Ki5kU1lNIHwgKi5vIHwgKi5vYmogKQorCTs7CisgICAgW2FiXS5vdXQgKQorCSMgV2UgZm91bmQg dGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0IGV4ZWV4dD0nJyBpcyBtb3N0CisJIyBjZXJ0YWlu bHkgcmlnaHQuCisJYnJlYWs7OworICAgICouKiApCisJaWYgdGVzdCAiJHthY19jdl9leGVleHQr c2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2X2V4ZWV4dCIgIT0gbm87CisJdGhlbiA6OyBlbHNl CisJICAgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCiAJ ZmkKLSAgICAgZmkKKwkjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBiZWNhdXNlIHRoZSBsYXRl ciB0ZXN0IGZvciBpdCBpcyBub3QKKwkjIHNhZmU6IGNyb3NzIGNvbXBpbGVycyBtYXkgbm90IGFk ZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKKwkjIGFyZ3VtZW50LCBzbyB3ZSBtYXkgbmVl ZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4KKwkjIEV2ZW4gaWYgdGhpcyBzZWN0 aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YKKwkjIGFjdHVhbGx5IHdv cmtpbmcuCisJYnJlYWs7OworICAgICogKQorCWJyZWFrOzsKKyAgZXNhYworZG9uZQordGVzdCAi JGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9CisKK2Vsc2UKKyAgYWNfZmlsZT0n JworZmkKK2lmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6CisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m NjsgfQorJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3Mv Xi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRh c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgNzcgIkMgY29t cGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1v cmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2 OyB9CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUiID4mNQorJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIg PiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNf Y3ZfZXhlZXh0CisKK3JtIC1mIC1yIGEub3V0IGEub3V0LmRTWU0gYS5leGUgY29uZnRlc3QkYWNf Y3ZfZXhlZXh0IGIub3V0CithY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4 IG9mIGV4ZWN1dGFibGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Yg ZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KK2lmIHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAi KCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5 OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJc IlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8g IiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3Rh dHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh Y19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBi b3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3QnIGFyZSBgcHJlc2VudCcgKHdlbGwsIG9i c2VydmFibGUpCisjIGNhdGNoIGBjb25mdGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3ln d2luLCBgbHMgY29uZnRlc3QnIHdpbGwKKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8g YGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3aXRoCisjIGBybScuCitmb3IgYWNfZmls ZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFj X2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAq Lnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICou bWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKi4qICkgYWNfY3Zf ZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJICBicmVhazs7Cisg ICAgKiApIGJyZWFrOzsKKyAgZXNhYworZG9uZQorZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5vdCBjb21waWxlIGFu ZCBsaW5rCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7 IH0KK2ZpCitybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9leGVleHQKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUK KyRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7IH0KIAorcm0gLWYgY29uZnRlc3QuJGFjX2V4 dAorRVhFRVhUPSRhY19jdl9leGVleHQKK2FjX2V4ZWV4dD0kRVhFRVhUCitjYXQgY29uZmRlZnMu aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisj aW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQoreworRklMRSAqZiA9IGZvcGVuICgiY29u ZnRlc3Qub3V0IiwgInciKTsKKyByZXR1cm4gZmVycm9yIChmKSB8fCBmY2xvc2UgKGYpICE9IDA7 CiAKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVh bl9maWxlcyBjb25mdGVzdC5vdXQiCisjIENoZWNrIHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1Y2Vz IGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgorIyB0aGUgY29tcGlsZXIg aXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxlLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmci ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5n Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiAhPSB5ZXM7IHRoZW4KKyAg eyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAq IHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5 OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2 YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0 YXR1cyA9IDA7IH0KKyAgaWYgeyBhY190cnk9Jy4vY29uZnRlc3QkYWNfY3ZfZXhlZXh0JworICB7 IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hv PVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3Ry eV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgor JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQor ICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog XCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4K KyAgICBjcm9zc19jb21waWxpbmc9bm8KKyAgZWxzZQorICAgIGlmIHRlc3QgIiRjcm9zc19jb21w aWxpbmciID0gbWF5YmU7IHRoZW4KKwljcm9zc19jb21waWxpbmc9eWVzCisgICAgZWxzZQorCXsg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNf cHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7 fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4gQyBjb21waWxlZCBwcm9ncmFtcy4KK0lmIHlv dSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2UgXGAtLWhvc3QnLgorU2VlIFxgY29uZmlnLmxv ZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisgICAgZmkKKyAgZmkKK2ZpCit7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGNyb3NzX2Nv bXBpbGluZyIgPiY1CiskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9CiAKLSAgICAg IyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAotICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVm aXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZp eH1vY2FtbGMub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNl dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitybSAtZiBj b25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2Ns ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUK KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2 OyB9CitpZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQi OyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIkT0NBTUxDRE9UT1BUIiAjIExldCB0 aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k UEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9J RlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQg aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNf ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2Fj X3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAg YnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIGNhdCBjb25m ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg Ki8KIAotZmkKLWZpCi1PQ0FNTENET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUCi1pZiB0 ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9D QU1MQ0RPVE9QVCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKK2lu dAorbWFpbiAoKQorewogCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK3JtIC1mIGNvbmZ0 ZXN0Lm8gY29uZnRlc3Qub2JqCitpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigo JGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7 CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJc JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIk YWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1CisgIGFjX3N0 YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgIGZvciBh Y19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCisgIHRlc3Qg LWYgIiRhY19maWxlIiB8fCBjb250aW51ZTsKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFj X2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICou YmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7CisgICAgKikgYWNfY3Zfb2JqZXh0PWBl eHByICIkYWNfZmlsZSIgOiAnLipcLlwoLipcKSdgCisgICAgICAgYnJlYWs7OworICBlc2FjCitk b25lCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQor c2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQogCit7IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQor U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CiBmaQot aWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FN TENET1RPUFQ9JE9DQU1MQ0RPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j YW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNr aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0 X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitybSAtZiBjb25mdGVzdC4kYWNfY3Zf b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2 X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFjX2N2X29iamV4dAorYWNfb2JqZXh0PSRPQkpFWFQK K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhl ciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+JjUKKyRhc19lY2hvX24gImNoZWNr aW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlci4uLiAiID4mNjsgfQor aWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN TENET1RPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3Rf T0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K LSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By b2dfYWNfY3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi ID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwor ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u ZmRlZnMuaC4gICovCiAKLWZpCi1maQotYWNfY3RfT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2Fj X2N0X09DQU1MQ0RPVE9QVAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4K LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j dF9PQ0FNTENET1RPUFQiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsg fQoraW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUKKyNl bmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBp bGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcwogZWxzZQotICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFz X2VjaG8gIm5vIiA+JjY7IH0KKyAgYWNfY29tcGlsZXJfZ251PW5vCiBmaQorcm0gLWYgY29yZSBj b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9j X2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FN TENET1RPUFQiID0geDsgdGhlbgotICAgIE9DQU1MQ0RPVE9QVD0ibm8iCi0gIGVsc2UKLSAgICBj YXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTog V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0 IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxDRE9UT1BUPSRh Y19jdF9PQ0FNTENET1RPUFQKLSAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hv ICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251 ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKIGVsc2UKLSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJv Z19PQ0FNTENET1RPUFQiCisgIEdDQz0KIGZpCi0KLSAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9Q VCIgIT0gIm5vIjsgdGhlbgotCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBzZWQgLW4g LWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04i ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9j YW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9t IG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQllbHNlCi0JICAgIE9DQU1M Qz0kT0NBTUxDRE9UT1BUCi0JZmkKLSAgICAgZmkKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2Ft bG9wdC5vcHQKLSAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgotCWlmIHRl c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy YW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5v cHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3Nl dH0iID0gc2V0OyB0aGVuIDoKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVf Q0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19uICJjaGVja2lu ZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3By b2dfY2NfZytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9 b2NhbWxvcHQub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICBhY19zYXZlX2Nfd2Vycm9yX2Zs YWc9JGFjX2Nfd2Vycm9yX2ZsYWcKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9w cm9nX2NjX2c9bm8KKyAgIENGTEFHUz0iLWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKLWZpCi1maQotT0NB TUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQKLWlmIHRlc3QgLW4gIiRPQ0FN TE9QVERPVE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRPQ0FNTE9QVERPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MT1BURE9U T1BUIiA+JjY7IH0KK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF T0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJv Z19jY19nPXllcwogZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCisgIENGTEFHUz0i IgorICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog ZW5kIGNvbmZkZWZzLmguICAqLwogCitpbnQKK21haW4gKCkKK3sKIAotZmkKLWlmIHRlc3QgLXog IiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTE9QVERPVE9Q VD0kT0NBTUxPUFRET1RPUFQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9w dC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15 IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf T0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVu Ci0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9Q VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9 JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09D QU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0g ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIDsKKyAg cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0 aGVuIDoKKworZWxzZQorICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcK KwkgQ0ZMQUdTPSItZyIKKwkgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKIAorICA7Cisg IHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg dGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKIGZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKIGZpCi1hY19jdF9PQ0FNTE9Q VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAtbiAiJGFj X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hv ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+ JjY7IH0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl c3QuJGFjX2V4dAogZmkKLQotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BURE9UT1BUIiA9IHg7 IHRoZW4KLSAgICBPQ0FNTE9QVERPVE9QVD0ibm8iCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9 JGFjX3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNf Y3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRo ZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cg PSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1n IC1PMiIKICAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQg aW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1 Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4 ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMK LSAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKKyAgICBDRkxBR1M9Ii1n IgogICBmaQogZWxzZQotICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RP UFQiCi1maQotCi0JaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCi0JICAg VE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiog KlwoLipcKSR8XDF8cCcgYAotCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS U0lPTiIgOyB0aGVuCi0JICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRp c2NhcmRlZC4iID4mNQotJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2Nh bWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCSAgIGVsc2UKLQkgICAgICBPQ0FNTE9QVD0k T0NBTUxPUFRET1RPUFQKLQkgICBmaQotICAgICAgICBmaQotICAgICBmaQotCi0KKyAgaWYgdGVz dCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENGTEFH Uz0KICAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo ZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hvX24g ImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9Citp ZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3Nh dmVfQ0M9JENDCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3Rk aW8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyog TW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3Jj L2NvbmYuc2guICAqLworc3RydWN0IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3Blbikg KHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBp KQorICAgICBjaGFyICoqcDsKKyAgICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3Rh dGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQor eworICBjaGFyICpzOworICB2YV9saXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAo cCwgdmFfYXJnICh2LGludCkpOworICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KIAorLyog T1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQu ICBJdCBoYXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhI JyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJy b3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gn LiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRv IGdldAorICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMg Y29tZXMgb3V0IHRydWUsIGZvciBhbgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVj ZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1 ZSBvbmx5IHdpdGggLXN0ZC4gICovCitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAx IDogLTFdOwogCisvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwg YnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBj aGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2Nf YXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWwg dG9wbGV2ZWwKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJh Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9 b2NhbWw7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MK3NldH0iID0g c2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVz dCAtbiAiJE9DQU1MIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRo ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ QVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAoraW50IHRlc3QgKGludCBpLCBkb3Vi bGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYpIChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgq ZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKiko c3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsK K2NoYXIgKiphcmd2OworaW50CittYWluICgpCit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0g YXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7 Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9 YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9O U19fIgogZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k aXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z OyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNf Y3ZfcHJvZ19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKLSAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCisgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgor ICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df Y2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCiBk b25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0ND PSRhY19zYXZlX0NDCiAKIGZpCi1maQotT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwKLWlmIHRlc3Qg LW4gIiRPQ0FNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRPQ0FNTCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MIiA+JjY7IH0KLWVsc2UK LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKLSRhc19lY2hvICJubyIgPiY2OyB9CisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9w cm9nX2NjX2M4OSIgaW4KKyAgeCkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVk IiA+JjY7IH0gOzsKKyAgeG5vKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQi ID4mNjsgfSA7OworICAqKQorICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJv Z19jY19jODkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citl c2FjCitpZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCiBmaQog CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAk Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBj b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj X2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAK LWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KLSAgYWNfY3RfT0NBTUw9 JE9DQU1MCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQy Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk YWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7 IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6 Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRo ZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg d2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAiID4mNjsgfQorc2V0IHggJHtN QUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2VkICdzLysvcC9nOyBzL1teYS16 QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgInRlc3QgXCJcJHthY19jdl9wcm9nX21ha2VfJHthY19t YWtlfV9zZXQrc2V0fVwiIiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19hY19jdF9PQ0FNTD0iJGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg dGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBh c19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl bgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgotICAgICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG UwotCi1maQotZmkKLWFjX2N0X09DQU1MPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MCi1pZiB0ZXN0 IC1uICIkYWNfY3RfT0NBTUwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUwiID4mNQotJGFzX2VjaG8gIiRhY19jdF9P Q0FNTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotICBpZiB0 ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7IHRoZW4KLSAgICBPQ0FNTD0ibm8iCi0gIGVsc2UKLSAg ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0 b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7CisgIGNhdCA+Y29uZnRlc3QubWFrZSA8 PFxfQUNFT0YKK1NIRUxMID0gL2Jpbi9zaAorYWxsOgorCUBlY2hvICdAQEAlJSU9JChNQUtFKT1A QEAlJSUnCitfQUNFT0YKKyMgR05VIG1ha2Ugc29tZXRpbWVzIHByaW50cyAibWFrZVsxXTogRW50 ZXJpbmcgLi4uIiwgd2hpY2ggd291bGQgY29uZnVzZSB1cy4KK2Nhc2UgYCR7TUFLRS1tYWtlfSAt ZiBjb25mdGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgorICAqQEBAJSUlPT8qPUBAQCUlJSopCisg ICAgZXZhbCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9eWVzOzsKKyAgKikKKyAgICBl dmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7CiBlc2FjCi0gICAgT0NBTUw9 JGFjX2N0X09DQU1MCi0gIGZpCitybSAtZiBjb25mdGVzdC5tYWtlCitmaQoraWYgZXZhbCB0ZXN0 IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCisgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2Vj aG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQogZWxzZQotICBPQ0FNTD0iJGFjX2N2X3Byb2df T0NBTUwiCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0Ut bWFrZX0iCiBmaQogCi0KLSAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKLSAgaWYgdGVzdCAtbiAi JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7 YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0 aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXA7IGFjX3dvcmQ9JDIK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyMg RmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVyIGEgQyBwcm9ncmFtIChmYXN0 ZXIpLAorIyBzbyBvbmUgc2NyaXB0IGlzIGFzIGdvb2QgYXMgYW5vdGhlci4gIEJ1dCBhdm9pZCB0 aGUgYnJva2VuIG9yCisjIGluY29tcGF0aWJsZSB2ZXJzaW9uczoKKyMgU3lzViAvZXRjL2luc3Rh bGwsIC91c3Ivc2Jpbi9pbnN0YWxsCisjIFN1bk9TIC91c3IvZXRjL2luc3RhbGwKKyMgSVJJWCAv c2Jpbi9pbnN0YWxsCisjIEFJWCAvYmluL2luc3RhbGwKKyMgQW1pZ2FPUyAvQy9pbnN0YWxsLCB3 aGljaCBpbnN0YWxscyBib290YmxvY2tzIG9uIGZsb3BweSBkaXNjcworIyBBSVggNCAvdXNyL2Jp bi9pbnN0YWxsYnNkLCB3aGljaCBkb2Vzbid0IHdvcmsgd2l0aG91dCBhIC1nIGZsYWcKKyMgQUZT IC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdoaWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJn cworIyBTVlI0IC91c3IvdWNiL2luc3RhbGwsIHdoaWNoIHRyaWVzIHRvIHVzZSB0aGUgbm9uZXhp c3RlbnQgZ3JvdXAgInN0YWZmIgorIyBPUy8yJ3Mgc3lzdGVtIGluc3RhbGwsIHdoaWNoIGhhcyBh IGNvbXBsZXRlbHkgZGlmZmVyZW50IHNlbWFudGljCisjIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJl IGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KKyMgUmVqZWN0 IGluc3RhbGwgcHJvZ3JhbXMgdGhhdCBjYW5ub3QgaW5zdGFsbCBtdWx0aXBsZSBmaWxlcy4KK3sg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgQlNE LWNvbXBhdGlibGUgaW5zdGFsbCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0Qt Y29tcGF0aWJsZSBpbnN0YWxsLi4uICIgPiY2OyB9CitpZiB0ZXN0IC16ICIkSU5TVEFMTCI7IHRo ZW4KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0iID0gc2V0OyB0aGVuIDoKICAg JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF UEFSQVRPUgorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNf ZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIi ICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4 dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4 dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K LSAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgotICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKKyAgICAjIEFj Y291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50 cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygoCisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0 Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmlu LyogfCBcCisgID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11J TlNUQUxMW1xcL10qIHwgXAorICAvdXNyL3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5k IFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9u J3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9v dAorICAgICMgYnkgZGVmYXVsdC4KKyAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0 IGluc3RhbGw7IGRvCisgICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVu CisJICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFz X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMg QUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4K KwkgICAgOgorCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3 cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu CisJICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1 cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUg Y29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQor CSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkg ICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25m dGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0 Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3Qu ZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0 LnR3bworCSAgICB0aGVuCisJICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19w cm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAgICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkK KyAgICAgIGRvbmUKKyAgICBkb25lCisgICAgOzsKK2VzYWMKKwogICBkb25lCiBJRlM9JGFzX3Nh dmVfSUZTCiAKK3JtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgor CiBmaQorICBpZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgor ICAgIElOU1RBTEw9JGFjX2N2X3BhdGhfaW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3Qg cmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMg dmFsdWUgZm9yIElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0 IHdpbGwKKyAgICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0 IGRpcmVjdG9yeSBpcworICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRp dmUgbmFtZS4KKyAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCisgIGZpCiBmaQotT0NBTUxERVA9 JGFjX2N2X3Byb2dfT0NBTUxERVAKLWlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KLSAgeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTERFUCIg PiY1Ci0kYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIg PiY2OyB9Ci1maQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9CiAKKyMgVXNlIHRl c3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4K KyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJz dGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09 JyR7SU5TVEFMTH0nCiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERFUCI7IHRo ZW4KLSAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y ZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgot c2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit0ZXN0IC16ICIkSU5TVEFMTF9TQ1JJUFQi ICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0IC16ICIkSU5TVEFMTF9EQVRB IiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworCisjIEV4dHJhY3QgdGhlIGZp cnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2df YWNfY3RfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRo X0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK IGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsgdGhlbgotICBhY19jdl9wcm9n X2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor ICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CSVNP Tj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4K KyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9y IGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNf ZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs ZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0 aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxkZXAiCisgICAgYWNfY3Zf cGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01ODMzLDUzICszNTY1LDM5IEBAIGRv bmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0 X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCi1pZiB0ZXN0IC1uICIkYWNfY3Rf T0NBTUxERVAiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERF UCIgPiY2OyB9CitCSVNPTj0kYWNfY3ZfcGF0aF9CSVNPTgoraWYgdGVzdCAtbiAiJEJJU09OIjsg dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JEJJU09OIiA+JjUKKyRhc19lY2hvICIkQklTT04iID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8g Im5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVu Ci0gICAgT0NBTUxERVA9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRh Y190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z dCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVk PXllcyA7OwotZXNhYwotICAgIE9DQU1MREVQPSRhY19jdF9PQ0FNTERFUAotICBmaQotZWxzZQot ICBPQ0FNTERFUD0iJGFjX2N2X3Byb2dfT0NBTUxERVAiCi1maQotCiAKLSAgIyBjaGVja2luZyBm b3Igb2NhbWxta3RvcAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y ZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg ZHVtbXkgZmxleDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RP UCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9 IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRl c3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FN TE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkRkxFWCBpbgorICBbXFwvXSog fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3Zl cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJ RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0k YXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNf ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0 IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RP UD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAgIGFjX2N2X3BhdGhfRkxFWD0iJGFz X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAg ICBicmVhayAyCiAgIGZpCkBAIC01ODg3LDM5ICszNjA1LDM5IEBAIGRvbmUKICAgZG9uZQogSUZT PSRhc19zYXZlX0lGUwogCisgIDs7Citlc2FjCiBmaQotZmkKLU9DQU1MTUtUT1A9JGFjX2N2X3By b2dfT0NBTUxNS1RPUAotaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1 Ci0kYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQorRkxFWD0kYWNfY3ZfcGF0aF9GTEVYCitp ZiB0ZXN0IC1uICIkRkxFWCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRGTEVYIiA+JjUKKyRhc19lY2hvICIkRkxFWCIgPiY2OyB9CiBl bHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu byIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1maQotaWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxNS1RPUCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxNS1RPUD0kT0NBTUxNS1RP UAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0b3AiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sbWt0b3A7IGFjX3dv cmQ9JDIKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBh IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgogeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6 CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfUEVSTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1L VE9QIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1L VE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZT PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkUEVSTCBpbgorICBbXFwvXSogfCA/ OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QRVJMPSIkUEVSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7 IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNf c2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhl Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1m ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN S1RPUD0ib2NhbWxta3RvcCIKKyAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBm aQpAQCAtNTkyNyw1MyArMzY0NSw0NiBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMK IAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QRVJMIiAmJiBhY19jdl9wYXRoX1BFUkw9Im5vIgor ICA7OworZXNhYwogZmkKLWZpCi1hY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09D QU1MTUtUT1AKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgotICB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtU T1AiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KK1BFUkw9JGFjX2N2 X3BhdGhfUEVSTAoraWYgdGVzdCAtbiAiJFBFUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1CiskYXNfZWNobyAiJFBF UkwiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVz dCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE1LVE9QPSJubyIKLSAg ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FN TE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCi0gIGZpCi1lbHNlCi0gIE9DQU1MTUtUT1A9IiRhY19j dl9wcm9nX09DQU1MTUtUT1AiCi1maQogCitpZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKK3Ro ZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3Rh bGwgcGVybCIgIiRMSU5FTk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6 CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9w cmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3By ZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K LXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKKyAgICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEg cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0k MgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig JGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2 OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6 CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsg dGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiRPQ0FNTE1LTElCIiAjIExldCB0aGUgdXNl ciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T RVBBUkFUT1IKKyAgY2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf cGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU T1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAt eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4 ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJHthY190b29sX3ByZWZpeH1v Y2FtbG1rbGliIgorICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01 OTgxLDM5ICszNjkyLDQ0IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCisgIHRl c3QgLXogIiRhY19jdl9wYXRoX0NVUkwiICYmIGFjX2N2X3BhdGhfQ1VSTD0ibm8iCisgIDs7Citl c2FjCiBmaQotZmkKLU9DQU1MTUtMSUI9JGFjX2N2X3Byb2dfT0NBTUxNS0xJQgotaWYgdGVzdCAt biAiJE9DQU1MTUtMSUIiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkT0NBTUxNS0xJQiIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MTUtMSUIi ID4mNjsgfQorQ1VSTD0kYWNfY3ZfcGF0aF9DVVJMCitpZiB0ZXN0IC1uICIkQ1VSTCI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDVVJM IiA+JjUKKyRhc19lY2hvICIkQ1VSTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4m NjsgfQogZmkKIAogCitpZiB0ZXN0IHgiJHtDVVJMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19m bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgY3VybC1jb25maWcsIHBsZWFzZSBpbnN0YWxsIGN1 cmwtY29uZmlnIiAiJExJTkVOTyIgNQogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1M TUtMSUIiOyB0aGVuCi0gIGFjX2N0X09DQU1MTUtMSUI9JE9DQU1MTUtMSUIKLSAgIyBFeHRyYWN0 IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2FtbG1rbGliOyBhY193b3JkPSQyCisgICAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRo ZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX1hNTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN TE1LTElCIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FN TE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkWE1MIGluCisgIFtcXC9dKiB8 ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7 IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNf c2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhl Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1m ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN S0xJQj0ib2NhbWxta2xpYiIKKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp CkBAIC02MDIxLDQ0ICszNzM3LDM5IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwog CisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIgJiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgorICA7 OworZXNhYwogZmkKLWZpCi1hY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1M TUtMSUIKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIi ID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK1hNTD0kYWNfY3ZfcGF0 aF9YTUwKK2lmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWE1MIiA+JjUKKyRhc19lY2hvICIkWE1MIiA+JjY7 IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNf Y3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCi0gICAgT0NBTUxNS0xJQj0ibm8iCi0gIGVsc2UKLSAg ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0 b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxNS0xJQj0k YWNfY3RfT0NBTUxNS0xJQgotICBmaQotZWxzZQotICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19P Q0FNTE1LTElCIgorCitpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1s Mi1jb25maWciICIkTElORU5PIiA1CiBmaQogCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9 ICJ4eSI7IHRoZW4gOgogCi0gICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgICAgICAjIGNoZWNr aW5nIGZvciBvY2FtbGMKICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9b2NhbWxkb2M7IGFjX3dvcmQ9JDIKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGM7IGFjX3dvcmQ9 JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y ICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoK K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNf ZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0 aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3Zl cnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3By b2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs c2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g JFBBVEgKQEAgLTYwNjcsNyArMzc3OCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFz X2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv bnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh Y19jdl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgIGFjX2N2 X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC02MDc3LDEwICszNzg4LDEwIEBAIElGUz0k YXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1PQ0FNTERPQz0kYWNfY3ZfcHJvZ19PQ0FNTERPQwotaWYg dGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MRE9DIiA+JjUKLSRhc19lY2hvICIkT0NBTUxET0Mi ID4mNjsgfQorT0NBTUxDPSRhY19jdl9wcm9nX09DQU1MQworaWYgdGVzdCAtbiAiJE9DQU1MQyI7 IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRPQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRPQ0FNTEMiID4mNjsgfQogZWxzZQogICB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj aG8gIm5vIiA+JjY7IH0KQEAgLTYwODgsMTcgKzM3OTksMTcgQEAgZmkKIAogCiBmaQotaWYgdGVz dCAteiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCi0gIGFjX2N0X09DQU1MRE9DPSRPQ0FN TERPQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2FtbGRvYzsgYWNfd29y ZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgorICBhY19jdF9PQ0FN TEM9JE9DQU1MQworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0 IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxjOyBhY193 b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQytzZXR9IiA9IHNl dDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDK3NldH0iID0gc2V0 OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIk YWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0 ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0i JGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBh c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRI CkBAIC02MTA3LDcgKzM4MTgsNyBAQCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf cHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2MiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN TEM9Im9jYW1sYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp CkBAIC02MTE3LDE3ICszODI4LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1hY19j dF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwotaWYgdGVzdCAtbiAiJGFjX2N0 X09DQU1MRE9DIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxE T0MiID4mNjsgfQorYWNfY3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVz dCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19j dF9PQ0FNTEMiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAg aWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCi0gICAgT0NBTUxET0M9Im5vIgor ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQyIgPSB4OyB0aGVuCisgICAgT0NBTUxDPSJubyIKICAg ZWxzZQogICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczop CkBAIC02MTM1LDI0ICszODQ2LDQxIEBAIHllczopCiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9 CiBhY190b29sX3dhcm5lZD15ZXMgOzsKIGVzYWMKLSAgICBPQ0FNTERPQz0kYWNfY3RfT0NBTUxE T0MKKyAgICBPQ0FNTEM9JGFjX2N0X09DQU1MQwogICBmaQogZWxzZQotICBPQ0FNTERPQz0iJGFj X2N2X3Byb2dfT0NBTUxET0MiCisgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxDIgogZmkKIAog Ci0gICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl Zml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm aXh9b2NhbWxidWlsZCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z ZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkOyBhY193b3JkPSQyCisgIGlmIHRl c3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12 IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlz ICRPQ0FNTFZFUlNJT04iID4mNQorJGFzX2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVS U0lPTiIgPiY2OyB9CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYg dGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13 aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAor ICAgICBlbHNlCisgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQor JGFzX2VjaG8gIk9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9 CisgICAgIGZpCisgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiBPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKKyRhc19lY2hvICJP Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjY7IH0KKworCisKKworICAgICAjIGNo ZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0 aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft bG9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg JHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2 X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3By b2dfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19PQ0FNTEJVSUxEPSIkT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl c3QuCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q VD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK QEAgLTYxNjEsNyArMzg4OSw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u CiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv CiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9w cm9nX09DQU1MQlVJTEQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKKyAgICBhY19jdl9w cm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgogICAgICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYxNzEsMTAgKzM4OTksMTAgQEAgSUZT PSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlM RAotaWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1Ci0kYXNfZWNobyAi JE9DQU1MQlVJTEQiID4mNjsgfQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRl c3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+ JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CkBAIC02MTgyLDE3ICszOTEwLDE3 IEBAIGZpCiAKIAogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQiOyB0aGVu Ci0gIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3 b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KLXNldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3Zf cHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BUCisgICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQyCiB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKK2lm IHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAg ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9P Q0FNTEJVSUxEIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19jdF9P Q0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUPSIk YWNfY3RfT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQog YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU SApAQCAtNjIwMSw3ICszOTI5LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly PS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg ZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2 X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAgICBhY19jdl9wcm9nX2FjX2N0 X09DQU1MT1BUPSJvY2FtbG9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh ayAyCiAgIGZpCkBAIC02MjExLDE3ICszOTM5LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkK IGZpCi1hY19jdF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQKLWlmIHRl c3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQlVJTEQiID4mNQotJGFzX2Vj aG8gIiRhY19jdF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9n X2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB TUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAk YXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQi ID0geDsgdGhlbgotICAgIE9DQU1MQlVJTEQ9Im5vIgorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1M T1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCiAgIGVsc2UKICAgICBjYXNlICRjcm9z c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNjIyOSw0NCArMzk1Nyw4 OSBAQCB5ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVz IDs7CiBlc2FjCi0gICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NBTUxCVUlMRAorICAgIE9DQU1MT1BU PSRhY19jdF9PQ0FNTE9QVAogICBmaQogZWxzZQotICBPQ0FNTEJVSUxEPSIkYWNfY3ZfcHJvZ19P Q0FNTEJVSUxEIgorICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFQiCiBmaQogCisgICAg IE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCisJ eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBDYW5ub3Qg ZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mNQorJGFzX2VjaG8g IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0 aW9uIG9ubHkuIiA+JjI7fQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBW RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh bWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz IGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KKwkgICAgT0NBTUxPUFQ9 bm8KKwllbHNlCisJICAgIE9DQU1MQkVTVD1vcHQKKwlmaQorICAgICBmaQogCi0gICAgaWYgdGVz dCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgogCi0gICAgICAgIGlmIHRlc3QgIngkZW5hYmxl X29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKIAotICAgICAgICAgICAgYXNfZm5fZXJyb3Ig JD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbCIgIiRMSU5F Tk8iIDUKLWZpCi0gICAgICAgIG9jYW1sdG9vbHM9Im4iCisgICAgICMgY2hlY2tpbmcgZm9yIG9j YW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4 dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNv IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29s X3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P Q0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICBhY19jdl9w cm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07 IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2Ft bGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCiBmaQorZmkKK09DQU1MQ0RPVE9QVD0kYWNf Y3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisg IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxD RE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh c19lY2hvICJubyIgPiY2OyB9CitmaQorCiAKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg b2YgImJhc2giLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IGJhc2g7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9Q VCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDRE9UT1BUPSRPQ0FNTENET1RPUFQKKyAgIyBFeHRyYWN0 IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGMub3B0OyBhY193b3JkPSQyCiB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNf Y3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNo b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRCQVNIIGluCi0gIFtcXC9dKiB8ID86 W1xcL10qKQotICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsg SUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsg dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9Q VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9 JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JBU0g9IiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE T1RPUFQ9Im9jYW1sYy5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsg MgogICBmaQpAQCAtNjI3NCw1NiArNDA0Nyw2MyBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2 ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9 Im5vIgotICA7OwotZXNhYwogZmkKLUJBU0g9JGFjX2N2X3BhdGhfQkFTSAotaWYgdGVzdCAtbiAi JEJBU0giOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkQkFTSCIgPiY1Ci0kYXNfZWNobyAiJEJBU0giID4mNjsgfQorZmkKK2FjX2N0X09D QU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRh Y19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIk YWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9 CiBmaQogCi0KLWlmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vy cm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBiYXNoIiAiJExJTkVO TyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCisgICAgT0NB TUxDRE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9v bF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp cGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMg OzsKK2VzYWMKKyAgICBPQ0FNTENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAorICBmaQorZWxz ZQorICBPQ0FNTENET1RPUFQ9IiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKIGZpCi1pZiB0ZXN0 ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7IHRoZW4gOgotCi0gICAgaWYgZWNobyAiJFBZVEhPTiIg fCBncmVwIC1xICJeLyI7IHRoZW4gOgogCi0gICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgotICAg ICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgICBpZiB0ZXN0ICIkT0NBTUxD RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNl ZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVS U0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1s Yzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz IGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCWVsc2UKKwkgICAg T0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQogCi1lbGlmIHRlc3QgLXogIiRQWVRI T04iOyB0aGVuIDoKLSAgUFlUSE9OPSJweXRob24iCi1lbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJQ WVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGgiICIkTElORU5PIiA1 Ci1maQotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJFBZVEhPTiIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJFBZVEhPTjsgYWNfd29y ZD0kMgorICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdC5vcHQKKyAgICAgaWYgdGVzdCAiJE9D QU1MT1BUIiAhPSAibm8iIDsgdGhlbgorCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo ZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s b3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt bXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK ICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAi JHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHth Y19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkUFlUSE9OUEFUSCBpbgotICBbXFwvXSog fCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1M T1BURE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIkT0NBTUxPUFRE T1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7 IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QWVRI T05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NB TUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0IgogICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYzMzEsNjIgKzQxMTEsMzkgQEAg ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf UFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKLSAgOzsKLWVzYWMKIGZp Ci1QWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKLWlmIHRlc3QgLW4gIiRQWVRIT05Q QVRIIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJFBZVEhPTlBBVEgiID4mNQotJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7IH0KK2Zp CitPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAi JE9DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxP UFRET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAot aWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3Ig JD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElO RU5PIiA1Ci1maQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQotJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1j ICdpbXBvcnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikp J2AKLWlmIHRlc3QgIiQ/IiAhPSAiMCIKLXRoZW4KLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP TiAtViAyPiYxYAotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICAgIGFzX2ZuX2Vycm9yICQ/ ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlz IDIuMyIgIiRMSU5FTk8iIDUKLWVsc2UKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQogZmkK LQotYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCi1hY19wcmV2aW91c19sZGZsYWdzPSRM REZMQUdTCi1hY19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5z eXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy KCJWRVJTSU9OIiknYAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OLWNvbmZp ZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJFBZ VEhPTi1jb25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BU RE9UT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTE9QVERPVE9QVD0kT0NBTUxPUFRET1RPUFQKKyAg IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUg YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29y ZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4g OgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0 OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkcHlj b25maWcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfcHljb25maWc9IiRw eWNvbmZpZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0g IDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYg dGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0 X09DQU1MT1BURE9UT1BUPSIkYWNfY3RfT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS QVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0 IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9weWNvbmZpZz0iJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSJvY2FtbG9w dC5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAt NjM5NCwxMjcgKzQxNTEsNjggQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAg dGVzdCAteiAiJGFjX2N2X3BhdGhfcHljb25maWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5v IgotICA7OwotZXNhYwogZmkKLXB5Y29uZmlnPSRhY19jdl9wYXRoX3B5Y29uZmlnCi1pZiB0ZXN0 IC1uICIkcHljb25maWciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkcHljb25maWciID4mNQotJGFzX2VjaG8gIiRweWNvbmZpZyIgPiY2 OyB9CitmaQorYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE T1RPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgeyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9Q VERPVE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KIGVs c2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v IiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIkcHljb25maWci ID09IHgibm8iOyB0aGVuIDoKLQotICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAt YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgIi1JIiArIGRp c3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIklOQ0xVREVQWSIpJ2AiCi0gICAgQ1BQ RkxBR1M9IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7 IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZM QUdTIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1 dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf Y29uZmlnX3ZhcigiTElCUyIpJ2AiCi0gICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMg J2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgICAgIHByaW50IGRpc3R1dGlscy5z eXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIlNZU0xJQlMiKSdgIgotICAgIExERkxBR1M9IiRMREZM QUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBw cmludCAiLUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNp ZmljPTEsXAotICAgICAgICBzdGFuZGFyZF9saWI9MSkgKyAiL2NvbmZpZyInYCIKLSAgICBMREZM QUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwK LSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZP UlNIQVJFRCIpJ2AiCi0gICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBk aXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcu Z2V0X2NvbmZpZ192YXIoIkxERkxBR1MiKSdgIgotCi1lbHNlCi0KLSAgICAgICAgQ1BQRkxBR1M9 IiRDRkxBR1MgYCRQWVRIT04tY29uZmlnIC0tY2ZsYWdzYCIKLSAgICBMREZMQUdTPSIkTERGTEFH UyBgJFBZVEhPTi1jb25maWcgLS1sZGZsYWdzYCIKLQotZmkKLQotYWNfZm5fY19jaGVja19oZWFk ZXJfbW9uZ3JlbCAiJExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAi JGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIg PSB4IiJ5ZXM7IHRoZW4gOgotCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RPUFQiID0g eDsgdGhlbgorICAgIE9DQU1MT1BURE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1 c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NB TUxPUFRET1RPUFQKKyAgZmkKIGVsc2UKLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k IFB5dGhvbiBkZXZlbG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQorICBPQ0FNTE9QVERPVE9Q VD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiCiBmaQogCisJaWYgdGVzdCAiJE9DQU1MT1BU RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12 IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3Qg IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBm cm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNp b24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQor CSAgIGVsc2UKKwkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAg ICBmaQorICAgICBmaQogCi1hc19hY19MaWI9YCRhc19lY2hvICJhY19jdl9saWJfcHl0aG9uJGFj X3B5dGhvbl92ZXJzaW9uJydfUHlBcmdfUGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hgCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJz ZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9u Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JGFzX2FjX0xpYitzZXR9XCIiID0gc2V0 OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tf bGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24gICRM SUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k IGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlw ZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNo IHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1l bnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwot ZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIFB5QXJnX1BhcnNlVHVwbGUgKCk7Ci1pbnQKLW1haW4g KCkKLXsKLXJldHVybiBQeUFyZ19QYXJzZVR1cGxlICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiRh c19hY19MaWI9eWVzIgotZWxzZQotICBldmFsICIkYXNfYWNfTGliPW5vIgotZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQot ZXZhbCBhY19yZXM9XCQkYXNfYWNfTGliCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVz IiA+JjY7IH0KLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfTGliIlwiID0geCJ5ZXMiOyB0aGVu IDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVf TElCcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCi0g IExJQlM9Ii1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uICRMSUJTIgogCi1lbHNlCi0gIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIHB5dGhvbiBkZXZlbG9wbWVudCBs aWJyYXJ5IiAiJExJTkVOTyIgNQotZmkKKyAgZmkKIAotQ1BQRkxBR1M9JGFjX3ByZXZpb3VzX2Nw cGZsYWdzCi1MRExGQUdTPSRhY19wcmV2aW91c19sZGZsYWdzCiAKIAotZmkKLSMgRXh0cmFjdCB0 aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg d2l0aCBhcmdzLgotc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCisgICMgY2hlY2tpbmcg Zm9yIG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVj a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VU VEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwrc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBj YXNlICRYR0VUVEVYVCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YR0VU VEVYVD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg cGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP UgorICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FN TCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9 JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hHRVRURVhU PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7 YWNfdG9vbF9wcmVmaXh9b2NhbWwiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJl YWsgMgogICBmaQpAQCAtNjUyMiw0NCArNDIyMCwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNf c2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0 aF9YR0VUVEVYVD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdF VFRFWFQKLWlmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Ci0kYXNfZWNobyAi JFhHRVRURVhUIiA+JjY7IH0KK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAt biAiJE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQogZWxzZQog ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m NQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9 PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4 dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBmaQotIyBFeHRyYWN0IHRo ZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg YXJncy4KLXNldCBkdW1teSBhczg2OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJv Z19PQ0FNTCI7IHRoZW4KKyAgYWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmly c3Qgd29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz Lgorc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9B Uzg2K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FN TCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl Ci0gIGNhc2UgJEFTODYgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQVM4 Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgot ICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlm IHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0i JGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2Fz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK IGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Bh dGhfQVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2Fj X2N0X09DQU1MPSJvY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAy CiAgIGZpCkBAIC02NTY3LDQ0ICs0MjYwLDUzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZl X0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFjX2N2X3BhdGhfQVM4Nj0i bm8iCi0gIDs7Ci1lc2FjCiBmaQotQVM4Nj0kYWNfY3ZfcGF0aF9BUzg2Ci1pZiB0ZXN0IC1uICIk QVM4NiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRBUzg2IiA+JjUKLSRhc19lY2hvICIkQVM4NiIgPiY2OyB9CitmaQorYWNfY3RfT0NB TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KIGVsc2UKICAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK ICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0FTODZ9IiA9PSB4Im5v IgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhczg2LCBwbGVhc2Ug aW5zdGFsbCBhczg2IiAiJExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7 IHRoZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6 JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo b3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3Mg dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJu ZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNlCisgIE9D QU1MPSIkYWNfY3ZfcHJvZ19PQ0FNTCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg ImxkODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15 IGxkODY7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRl c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193 b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoK K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJExEODYgaW4KLSAgW1xcL10q IHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K KyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK IGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4 dCIKKyAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgog ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY2MTIsNDQg KzQzMTQsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAi JGFjX2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKLSAgOzsKLWVzYWMKIGZp Ci1MRDg2PSRhY19jdl9wYXRoX0xEODYKLWlmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgotICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQot JGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KK2ZpCitPQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERF UAoraWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkT0NB TUxERVAiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYg dGVzdCB4IiR7TEQ4Nn0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs ZSB0byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBmaQotIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGJjYzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJv Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgogeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7 YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJDQyBpbgotICBbXFwvXSogfCA/Oltc XC9dKikKLSAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo ZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAg YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNl ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T RVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAg dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQkNDPSIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgogICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY2NTcsMjgzICs0 MzU0LDI0MSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIk YWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1C Q0M9JGFjX2N2X3BhdGhfQkNDCi1pZiB0ZXN0IC1uICIkQkNDIjsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEJDQyIgPiY1Ci0kYXNfZWNo byAiJEJDQyIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUxERVA9JGFjX2N2X3Byb2dfYWNfY3RfT0NB TUxERVAKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1 CiskYXNfZWNobyAiJGFjX2N0X09DQU1MREVQIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJu byIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0JDQ30iID09IHgibm8iCi10aGVuCi0gICAg YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAi JExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KKyAgICBP Q0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90 IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7 Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitlbHNlCisgIE9DQU1M REVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg b2YgImlhc2wiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IGlhc2w7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWt0b3AKKyAg aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0 IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1r dG9wOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JQVNMK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LVE9QK3NldH0iID0gc2V0OyB0 aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkSUFTTCBp bgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9JQVNMPSIkSUFTTCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1M TUtUT1AiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0 IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT PSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZl X0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4 dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9JQVNMPSIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29s X3ByZWZpeH1vY2FtbG1rdG9wIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr IDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi0gIHRlc3QgLXogIiRh Y19jdl9wYXRoX0lBU0wiICYmIGFjX2N2X3BhdGhfSUFTTD0ibm8iCi0gIDs7Ci1lc2FjCi1maQot SUFTTD0kYWNfY3ZfcGF0aF9JQVNMCi1pZiB0ZXN0IC1uICIkSUFTTCI7IHRoZW4KLSAgeyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJQVNMIiA+JjUKLSRh c19lY2hvICIkSUFTTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkK LQotCi1pZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9lcnJvciAk PyAiVW5hYmxlIHRvIGZpbmQgaWFzbCwgcGxlYXNlIGluc3RhbGwgaWFzbCIgIiRMSU5FTk8iIDUK LWZpCi0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkL3V1aWQu aCIgImFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYg dGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giID0geCIieWVzOyB0aGVuIDoKLQotICAg IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1 aWRfY2xlYXIgaW4gLWx1dWlkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2Ns ZWFyIGluIC1sdXVpZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfdXVpZF91dWlk X2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx1dWlkICAkTElC UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj b25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg dG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0 aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50 IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4 dGVybiAiQyIKLSNlbmRpZgotY2hhciB1dWlkX2NsZWFyICgpOwotaW50Ci1tYWluICgpCi17Ci1y ZXR1cm4gdXVpZF9jbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfdXVpZF91dWlkX2Ns ZWFyPXllcwotZWxzZQotICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCi1maQotcm0gLWYg Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKLWZp Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2 X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlk X2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4 IiJ5ZXM7IHRoZW4gOgotICBsaWJ1dWlkPSJ5IgotZmkKLQorICBmaQorZG9uZQorICBkb25lCitJ RlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0KLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi JExJTkVOTyIgInV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVm YXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgot ICBsaWJ1dWlkPSJ5IgogZmkKLQotCi1pZiB0ZXN0ICIkbGlidXVpZCIgIT0gInkiOyB0aGVuIDoK LQotICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIg IiRMSU5FTk8iIDUKLQorT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QCitpZiB0ZXN0 IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LVE9QIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS1RP UCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1hY19mbl9j X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJf Y3Vyc2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy X2N1cnNlc19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1Ci0k YXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CitmaQor aWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxN S1RPUD0kT0NBTUxNS1RPUAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0 b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9j YW1sbWt0b3A7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1M TUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog ZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGN1cnNlcyAgJExJ QlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg Y29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl IHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1l eHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xlYXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVy biBjbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlf bGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPXllcworICBp ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9P Q0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9bm8KK2FzX3NhdmVfSUZTPSRJ RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0 IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB TUxNS1RPUD0ib2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQot eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s aWJfY3Vyc2VzX2NsZWFyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIg PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVu IDoKLSAgY3Vyc2VzPSJ5IgorYWNfY3RfT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FN TE1LVE9QCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9Q IiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxNS1RPUCIgPiY2OyB9CiBlbHNlCi0gIGN1cnNl cz0ibiIKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KKyAgaWYgdGVzdCAieCRhY19j dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh Y19jdF9PQ0FNTE1LVE9QCisgIGZpCiBlbHNlCi0gIGN1cnNlcz0ibiIKKyAgT0NBTUxNS1RPUD0i JGFjX2N2X3Byb2dfT0NBTUxNS1RPUCIKIGZpCiAKIAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9u Z3JlbCAiJExJTkVOTyIgIm5jdXJzZXMuaCIgImFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giICIkYWNf aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgPSB4 IiJ5ZXM7IHRoZW4gOgotCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf Y3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAjIGNoZWNraW5nIGZv ciBvY2FtbG1rbGliCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df T0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sbmN1cnNl cyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw bHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xlYXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsK LXJldHVybiBjbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5f Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj15 ZXMKKyAgaWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxN S0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxz ZQotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rv b2xfcHJlZml4fW9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBj b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l eGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf bGliX25jdXJzZXNfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19jbGVh ciIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA9IHgiInllczsg dGhlbiA6Ci0gIG5jdXJzZXM9InkiCitPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIK K2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRP Q0FNTE1LTElCIiA+JjY7IH0KIGVsc2UKLSAgbmN1cnNlcz0ibiIKKyAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg PiY2OyB9CiBmaQogCiAKLWVsc2UKLSAgbmN1cnNlcz0ibiIKIGZpCi0KLQotaWYgdGVzdCAiJGN1 cnNlcyIgPSAibiIgJiYgdGVzdCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKLQotICAgIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJ TkVOTyIgNQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNf Y3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg Im9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0 IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj X2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAg YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9j YW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91 bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0jIFByZWZlciBuY3Vyc2VzIG92 ZXIgY3Vyc2VzIGlmIGJvdGggYXJlIHByZXNlbnQKLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5Ijsg dGhlbiA6Ci0KLSAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmlu ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKLQotCitmaQorYWNf Y3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIk YWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKKyRhc19lY2hvICIkYWNf Y3RfT0NBTUxNS0xJQiIgPiY2OyB9CiBlbHNlCi0KLSAgICBDVVJTRVNfTElCUz0iLWxjdXJzZXMi Ci0KLSRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPGN1cnNlcy5oPiIgPj5jb25m ZGVmcy5oCi0KLQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKKyAgaWYgdGVzdCAieCRh Y19jdF9PQ0FNTE1LTElCIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LTElCPSJubyIKKyAgZWxzZQor ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFz X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy aXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LTElC PSRhY19jdF9PQ0FNTE1LTElCCisgIGZpCitlbHNlCisgIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n X09DQU1MTUtMSUIiCitmaQogCiAKLQotCi0KLQotCi1pZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0df Q09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCi0JaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4 IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9 cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQg ZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCisgICMgY2hlY2tp bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9Q S0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FN TERPQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl bHNlCi0gIGNhc2UgJFBLR19DT05GSUcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2 X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo ZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3Zf cHJvZ19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19k aXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIg JiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0 ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgot ICAgIGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK KyAgICBhY19jdl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgogICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY5NDEsMTMgKzQ1 OTYsMTIgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVzYWMKIGZp Ci1QS0dfQ09ORklHPSRhY19jdl9wYXRoX1BLR19DT05GSUcKLWlmIHRlc3QgLW4gIiRQS0dfQ09O RklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJFBLR19DT05GSUciID4mNQotJGFzX2VjaG8gIiRQS0dfQ09ORklHIiA+JjY7IH0KK2Zp CitPQ0FNTERPQz0kYWNfY3ZfcHJvZ19PQ0FNTERPQworaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsg dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JE9DQU1MRE9DIiA+JjUKKyRhc19lY2hvICIkT0NBTUxET0MiID4mNjsgfQogZWxzZQogICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFz X2VjaG8gIm5vIiA+JjY7IH0KQEAgLTY5NTUsMjggKzQ2MDksMjYgQEAgZmkKIAogCiBmaQotaWYg dGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KLSAgYWNfcHRfUEtHX0NPTkZJ Rz0kUEtHX0NPTkZJRwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBrZy1jb25maWci LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IHBrZy1j b25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9DIjsgdGhl bgorICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz ZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX2Fj X3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9n X2FjX2N0X09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl ZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgotICBbXFwvXSogfCA/ OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJ RyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0g ICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIk YWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQor YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU SAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf cGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9jYW1sZG9jIgogICAgICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY5ODQsMjAgKzQ2MzYsMTkgQEAgZG9uZQog ICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVzYWMKIGZpCi1hY19wdF9QS0dfQ09O RklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcKLWlmIHRlc3QgLW4gIiRhY19wdF9QS0df Q09ORklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX3B0X1BLR19DT05GSUciID4mNQotJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09O RklHIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP QworaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRh c19lY2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+ JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19wdF9QS0dfQ09ORklHIiA9IHg7IHRoZW4KLSAg ICBQS0dfQ09ORklHPSIiCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxET0MiID0geDsgdGhlbgor ICAgIE9DQU1MRE9DPSJubyIKICAgZWxzZQogICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNf dG9vbF93YXJuZWQgaW4KIHllczopCkBAIC03MDA1LDYyNCArNDY1Niw3MTggQEAgeWVzOikKICRh c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3 aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAg IFBLR19DT05GSUc9JGFjX3B0X1BLR19DT05GSUcKKyAgICBPQ0FNTERPQz0kYWNfY3RfT0NBTUxE T0MKICAgZmkKIGVsc2UKLSAgUEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyIKLWZp Ci0KLWZpCi1pZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KLQlfcGtnX21pbl92ZXJzaW9u PTAuOS4wCi0JeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtn X21pbl92ZXJzaW9uLi4uICIgPiY2OyB9Ci0JaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2Nv bmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uOyB0aGVuCi0JCXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIg PiY2OyB9Ci0JZWxzZQotCQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLQkJUEtHX0NPTkZJRz0iIgot CWZpCi1maQotCi1wa2dfZmFpbGVkPW5vCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGNoZWNraW5nIGZvciBnbGliIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBnbGliLi4uICIgPiY2OyB9Ci0KLWlmIHRlc3QgLW4gIiRnbGliX0NGTEFHUyI7IHRoZW4KLSAg ICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKLSBlbGlmIHRlc3QgLW4gIiRQS0df Q09ORklHIjsgdGhlbgotICAgIGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCi0gICAgeyB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4 aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQotICAoJFBLR19DT05GSUcg LS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikgMj4mNQotICBhY19zdGF0dXM9JD8K LSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1 cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4KLSAgcGtnX2N2X2dsaWJfQ0ZM QUdTPWAkUEtHX0NPTkZJRyAtLWNmbGFncyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAotZWxzZQot ICBwa2dfZmFpbGVkPXllcwotZmkKLSBlbHNlCi0gICAgcGtnX2ZhaWxlZD11bnRyaWVkCi1maQot aWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KLSAgICBwa2dfY3ZfZ2xpYl9MSUJTPSIkZ2xp Yl9MSUJTIgotIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCi0gICAgaWYgdGVzdCAt biAiJFBLR19DT05GSUciICYmIFwKLSAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0y LjBcIiI7IH0gPiY1Ci0gICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xp Yi0yLjAiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfTsgdGhlbgotICBwa2dfY3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWIt Mi4wIiAyPi9kZXYvbnVsbGAKLWVsc2UKLSAgcGtnX2ZhaWxlZD15ZXMKLWZpCi0gZWxzZQotICAg IHBrZ19mYWlsZWQ9dW50cmllZAotZmkKLQotCi0KLWlmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7 IHRoZW4KLSAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLQotaWYgJFBLR19DT05GSUcgLS1hdGxl YXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRoZW4KLSAgICAgICAgX3BrZ19zaG9ydF9lcnJv cnNfc3VwcG9ydGVkPXllcwotZWxzZQotICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0 ZWQ9bm8KKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgogZmkKLSAgICAgICAgaWYg dGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCi0JICAgICAgICBn bGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3Jz ICJnbGliLTIuMCIgMj4mMWAKLSAgICAgICAgZWxzZQotCSAgICAgICAgZ2xpYl9QS0dfRVJST1JT PWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCi0gICAgICAgIGZp Ci0JIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBi ZWxvbmdzCi0JZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1Ci0KLQlhc19mbl9lcnJvciAkPyAi UGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6Ci0KLSRnbGliX1BL R19FUlJPUlMKLQotQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJv bm1lbnQgdmFyaWFibGUgaWYgeW91Ci1pbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRh cmQgcHJlZml4LgotCi1BbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQg dmFyaWFibGVzIGdsaWJfQ0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRv IGNhbGwgcGtnLWNvbmZpZy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBk ZXRhaWxzLiIgIiRMSU5FTk8iIDUKLWVsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRo ZW4KLSAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8g IiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIlRo ZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1h a2Ugc3VyZSBpdAotaXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9u bWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAotcGF0aCB0byBwa2ctY29uZmlnLgogCi1BbHRlcm5h dGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdT Ci1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KLVNl ZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgogCi1UbyBnZXQgcGtn LWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4KLVNlZSBc YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAjIGNoZWNr aW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVp bGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7 YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2 X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0JZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwotCWdsaWJf TElCUz0kcGtnX2N2X2dsaWJfTElCUwotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQot Ci1maQotCi0jIENoZWNrIGxpYnJhcnkgcGF0aAotaWYgdGVzdCAiXCR7ZXhlY19wcmVmaXh9L2xp YiIgPSAiJGxpYmRpciI7IHRoZW4gOgotICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5PTkUi ICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4PSRwcmVm aXgKLWZpCi0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIjsgdGhlbiA6Ci0gIGV4 ZWNfcHJlZml4PSRhY19kZWZhdWx0X3ByZWZpeAotZmkKLSAgICBpZiB0ZXN0IC1kICIke2V4ZWNf cHJlZml4fS9saWI2NCI7IHRoZW4gOgotCi0gICAgICAgIExJQl9QQVRIPSJsaWI2NCIKLQorICBp ZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIk T0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi0KLSAg ICAgICAgTElCX1BBVEg9ImxpYiIKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4 ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1v Y2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCiBmaQotCi1lbHNlCi0KLSAgICBMSUJf UEFUSD0iJHtsaWJkaXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVmaXgiICsgMWB9IgotCiBmaQot Ci0KLSMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs ICIkTElORU5PIiAiYnpsaWIuaCIgImFjX2N2X2hlYWRlcl9iemxpYl9oIiAiJGFjX2luY2x1ZGVz X2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9iemxpYl9oIiA9IHgiInllczsgdGhl biA6Ci0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKLSRhc19lY2hvX24gImNoZWNr aW5nIGZvciBCWjJfYnpEZWNvbXByZXNzSW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0K3NldH0iID0gc2V0OyB0aGVu IDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3Nh dmVfTElCUz0kTElCUwotTElCUz0iLWxiejIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9B Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVy cmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVz ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwot ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw cGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIEJa Ml9iekRlY29tcHJlc3NJbml0ICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gQloyX2J6RGVj b21wcmVzc0luaXQgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXBy ZXNzSW5pdD15ZXMKK09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAt biAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQi ID4mNjsgfQogZWxzZQotICBhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PW5vCi1m aQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29u ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZl X0xJQlMKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNf Y3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgotICB6bGli PSIkemxpYiAtREhBVkVfQlpMSUIgLWxiejIiCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkK IAogCiBmaQotCi0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem1h LmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0 ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVj b2RlciBpbiAtbGx6bWEiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bWFfc3RyZWFt X2RlY29kZXIgaW4gLWxsem1hLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9sem1h X2x6bWFfc3RyZWFtX2RlY29kZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlM RAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dv cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBz ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVj a19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGx6bWEgICRMSUJTIgotY2F0IGNvbmZkZWZz LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwot Ci0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv ZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk IHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlm Ci1jaGFyIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBs em1hX3N0cmVhbV9kZWNvZGVyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBh Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9sem1hX2x6bWFf c3RyZWFtX2RlY29kZXI9eWVzCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhl bgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19jdF9PQ0FNTEJVSUxEIiAjIExl dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKLSAgYWNfY3ZfbGliX2x6bWFfbHpt YV9zdHJlYW1fZGVjb2Rlcj1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16 ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi OyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgor ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u ZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2Rl Y29kZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIg PSB4IiJ5ZXM7IHRoZW4gOgotICB6bGliPSIkemxpYiAtREhBVkVfTFpNQSAtbGx6bWEiCithY19j dF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQKK2lmIHRlc3QgLW4gIiRh Y19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRhY19j dF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQog Ci0KKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJV SUxEPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJu ZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2Vz YWMKKyAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1M QlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCiBmaQogCiAKLWFjX2ZuX2NfY2hlY2tfaGVh ZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpv MXhfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHpv X2x6bzF4X2giID0geCIieWVzOyB0aGVuIDoKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5v IjsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl Y2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVf TElCUz0kTElCUwotTElCUz0iLWxsem8yICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgICAgICAgaWYg dGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgogCi0vKiBPdmVycmlk ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBj aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAg YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGx6bzF4 X2RlY29tcHJlc3MgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBsem8xeF9kZWNvbXByZXNz ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVzCi1l bHNlCi0gIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9bm8KLWZpCi1ybSAtZiBjb3Jl IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVl eHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICAgICAg ICAgICAgYXNfZm5fZXJyb3IgJD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8g ZmluZCBPY2FtbCIgIiRMSU5FTk8iIDUKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4m NQotJGFzX2VjaG8gIiRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA+JjY7IH0KLWlm IHRlc3QgIngkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4g OgotICB6bGliPSIkemxpYiAtREhBVkVfTFpPMVggLWxsem8yIgorICAgICAgICBvY2FtbHRvb2xz PSJuIgorCiBmaQogCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiYXNoIiwgc28g aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiYXNoOyBhY193 b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoK KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkQkFTSCBpbgorICBb XFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQVNIPSIkQkFTSCIgIyBMZXQgdGhlIHVz ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQkFT SD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+ JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAor ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9Im5vIgorICA7 OworZXNhYworZmkKK0JBU0g9JGFjX2N2X3BhdGhfQkFTSAoraWYgdGVzdCAtbiAiJEJBU0giOyB0 aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk QkFTSCIgPiY1CiskYXNfZWNobyAiJEJBU0giID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v IiA+JjY7IH0KIGZpCiAKIAoraWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCit0aGVuCisgICAg YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi ICIkTElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpbyIgPiY1Ci0kYXNfZWNob19uICJjaGVj a2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf bGliX2Fpb19pb19zZXR1cCtzZXR9IiA9IHNldDsgdGhlbiA6CithY19leHQ9YworYWNfY3BwPSck Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29y IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29y Li4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5 LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KKyAgQ1BQPQorZmkK K2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBh Y19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGFpbyAgJExJQlMiCi1jYXQgY29u ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgICAgICAjIERvdWJsZSBxdW90 ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKKyAgICBmb3IgQ1BQIGluICIkQ0Mg LUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgorICAgIGRvCisgICAgICBh Y19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMK K2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmln dXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMg UHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBz aW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVy cy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21w aWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIg aXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUg YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hh ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g ICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKKyNpZmRlZiBfX1NURENfXworIyBp bmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgogI2VuZGlmCi1j aGFyIGlvX3NldHVwICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gaW9fc2V0dXAgKCk7Ci0g IDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3ludGF4IGVycm9yCiBfQUNFT0YKLWlmIGFjX2Zu X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15 ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2 X2xpYl9haW9faW9fc2V0dXA9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz dC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAot TElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQg aW5wdXQuCitjb250aW51ZQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1Ci0kYXNfZWNobyAiJGFj X2N2X2xpYl9haW9faW9fc2V0dXAiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfYWlvX2lv X3NldHVwIiA9IHgiInllczsgdGhlbiA6Ci0gIHN5c3RlbV9haW89InkiCitybSAtZiBjb25mdGVz dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisKKyAgIyBPSywgd29ya3Mgb24gc2Fu ZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKKyAgIyBjYW4g YmUgZGV0ZWN0ZWQgYW5kIGhvdy4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPGFjX25vbmV4aXN0 ZW50Lmg+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorICAj IEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgorY29udGludWUKIGVsc2UKLSAgc3lz dGVtX2Fpbz0ibiIKKyAgIyBQYXNzZXMgYm90aCB0ZXN0cy4KK2FjX3ByZXByb2Nfb2s9OgorYnJl YWsKK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisK K2RvbmUKKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmlu ZyBjb2RlIHdhcyBza2lwcGVkLgorcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX2V4dAoraWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgorICBicmVhawogZmkKIAorICAg IGRvbmUKKyAgICBhY19jdl9wcm9nX0NQUD0kQ1BQCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIE1ENSBpbiAtbGNyeXB0byIgPiY1Ci0kYXNf ZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X2xpYl9jcnlwdG9fTUQ1K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKK2ZpCisgIENQUD0kYWNfY3ZfcHJvZ19DUFAKIGVsc2UKLSAgYWNf Y2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjcnlwdG8gICRMSUJTIgotY2F0IGNv bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jdl9wcm9nX0NQUD0k Q1BQCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDUFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNfcHJlcHJvY19vaz1mYWxzZQor Zm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRl ciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0 aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRv IDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+ IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQs IGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMg bm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhp cyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAv KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw bHVzCi1leHRlcm4gIkMiCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+Cisj ZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KICNlbmRpZgotY2hhciBNRDUgKCk7Ci1pbnQKLW1h aW4gKCkKLXsKLXJldHVybiBNRDUgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3lu dGF4IGVycm9yCiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK LSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8i OyB0aGVuIDoKKwogZWxzZQotICBhY19jdl9saWJfY3J5cHRvX01ENT1ubwotZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgICMg QnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCiBmaQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01E NSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KLWlmIHRlc3Qg IngkYWNfY3ZfbGliX2NyeXB0b19NRDUiID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRl ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBIQVZFX0xJQkNSWVBUTyAxCitybSAtZiBjb25mdGVzdC5l cnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisKKyAgIyBPSywgd29ya3Mgb24gc2FuZSBj YXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKKyAgIyBjYW4gYmUg ZGV0ZWN0ZWQgYW5kIGhvdy4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPGFjX25vbmV4aXN0ZW50 Lmg+CiBfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorICAjIEJy b2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgorY29udGludWUKK2Vsc2UKKyAgIyBQYXNz ZXMgYm90aCB0ZXN0cy4KK2FjX3ByZXByb2Nfb2s9OgorYnJlYWsKK2ZpCitybSAtZiBjb25mdGVz dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CiAKLSAgTElCUz0iLWxjcnlwdG8gJExJ QlMiCitkb25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xl YW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKIAogZWxzZQotICBhc19m bl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIgNQorICB7IHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3 ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K K2FzX2ZuX2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hl Y2sKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQog ZmkKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf bGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorYWNfZXh0PWMKK2Fj X2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxB R1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhl ZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1 JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5k bGVzIGxvbmcgbGluZXMgYW5kIC1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVw IHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth Y19jdl9wYXRoX0dSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgogZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGV4 dDJmcyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBh Y19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRo IGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsg SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91 c3IveHBnNC9iaW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBh Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNf cGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1m ICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250 aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlz IGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRo X0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFj X3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAk YXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAg IGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYg ImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0 ZXN0Lm5sIgorICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19w YXRoX0dSRVAiIC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5s IiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVz dC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5f YXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNf Y291bnQgLWd0ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBz byBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBh Y19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRh Y19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9y ZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25l CisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5v dXQ7OworZXNhYwogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh dm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSBy ZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJv dG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJu ICJDIgotI2VuZGlmCi1jaGFyIGV4dDJmc19vcGVuMiAoKTsKLWludAotbWFpbiAoKQotewotcmV0 dXJuIGV4dDJmc19vcGVuMiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfZXh0MmZzX2V4dDJm c19vcGVuMj15ZXMKKyAgICAgICRhY19wYXRoX0dSRVBfZm91bmQgJiYgYnJlYWsgMworICAgIGRv bmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisgIGlmIHRlc3QgLXogIiRhY19j dl9wYXRoX0dSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZ3Jl cCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIk TElORU5PIiA1CisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5v CisgIGFjX2N2X3BhdGhfR1JFUD0kR1JFUAogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf ZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisKIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZz X29wZW4yIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4m NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPSB4IiJ5ZXM7 IHRoZW4gOgotICBsaWJleHQyZnM9InkiCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNobyAiJGFjX2N2 X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKKworCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7 YWNfY3ZfcGF0aF9FR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0gIGxpYmV4dDJmcz0ibiIKKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUg JyhhfGIpJyA+L2Rldi9udWxsIDI+JjEKKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAg LUUiCisgICBlbHNlCisgICAgIGlmIHRlc3QgLXogIiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9F R1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRl c3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0 L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k aXI9LgorICAgIGZvciBhY19wcm9nIGluIGVncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBp biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0i JGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhf RUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBD aGVjayBmb3IgR05VIGFjX3BhdGhfRUdSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4K KyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VHUkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAi IC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRo X0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNf ZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNh dCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNv bmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0 Lm5sIgorICAgICRhc19lY2hvICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0 aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYv bnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rl di9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFj X2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQ X21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAg bG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0 aF9FR1JFUCIKKyAgICAgIGFjX3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAg IyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRl c3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0Lmlu IGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYworCisgICAgICAk YWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUK K0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVu CisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQg aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQor ZWxzZQorICBhY19jdl9wYXRoX0VHUkVQPSRFR1JFUAogZmkKIAorICAgZmkKK2ZpCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdS RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRoX0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFj X2N2X3BhdGhfRUdSRVAiCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVy K3NldH0iID0gc2V0OyB0aGVuIDoKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1CiskYXNfZWNob19u ICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcy4uLiAiID4mNjsgfQoraWYgdGVzdCAi JHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj YWNoZWQpICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9 Ii1sZ2NyeXB0ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh Y19leHQKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyog ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFy Zy5oPgorI2luY2x1ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGZsb2F0Lmg+CiAKLS8qIE92ZXJy aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNl IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0g ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZ2Ny eV9tZF9oYXNoX2J1ZmZlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIGdjcnlfbWRfaGFz aF9idWZmZXIgKCk7CisKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190 cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFz aF9idWZmZXI9eWVzCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cisg IGFjX2N2X2hlYWRlcl9zdGRjPXllcwogZWxzZQotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXI9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0k YWNfY2hlY2tfbGliX3NhdmVfTElCUworICBhY19jdl9oZWFkZXJfc3RkYz1ubwogZmkKLXsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2dj cnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlw dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlw dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYmdjcnlwdD0ieSIK K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj X2V4dAorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIFN1bk9T IDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0kuCisg IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFj X2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+L2Rldi9u dWxsIDI+JjE7IHRoZW4gOgorCiBlbHNlCi0gIGxpYmdjcnlwdD0ibiIKKyAgYWNfY3ZfaGVhZGVy X3N0ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKwogZmkKIAoraWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVj bGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3Rk bGliLmg+CiAKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+ JjUgfAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CiAKLSAgICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFk IGZsYWciID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZy4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHtheF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9 bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKIAotICAgICAgICBheF9jdl9wdGhyZWFkX2ZsYWdzPS1w dGhyZWFkCitmaQogCi0gICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgot ICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9M SUJTPSIiCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4v Y2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcg LWFuc2kuCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgor ZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl bmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIu aD4KKyNpZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdh JyA8PSAoYykgJiYgKGMpIDw9ICd6JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykg PyAnQScgKyAoKGMpIC0gJ2EnKSA6IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwK KwkJICAgKCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChj KSAmJiAoYykgPD0gJ3InKSBcCisJCSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6Jykp CisjIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQor I2VuZGlmCiAKKyNkZWZpbmUgWE9SKGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChm KSkpCitpbnQKK21haW4gKCkKK3sKKyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkr KykKKyAgICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAo aSkgIT0gVE9VUFBFUiAoaSkpCisgICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNF T0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgogCi0gICAgc2F2ZWRfQ0ZM QUdTPSIkQ0ZMQUdTIgorZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNv cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l eHQKK2ZpCiAKLSAgICBzYXZlZF9MREZMQUdTPSIkTERGTEFHUyIKK2ZpCitmaQoreyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3Rk YyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KK2lmIHRlc3QgJGFj X2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCiAKLSAgICBzYXZlZF9MSUJTPSIkTElCUyIKKyRh c19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNvbmZkZWZzLmgKIAorZmkKIAotICAg IENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9DRkxBR1MiCisjIE9uIElSSVggNS4zLCBzeXMvdHlw ZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZsaWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMv dHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBc CisJCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9 YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9j X2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFk ZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19I ZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj ZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VP RgogCi0gICAgTERGTEFHUz0iJExERkxBR1MgJFBUSFJFQURfTERGTEFHUyIKK2ZpCiAKLSAgICBM SUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgorZG9uZQogCi0gICAgICAgIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAot I2luY2x1ZGUgPHB0aHJlYWQuaD4KLWludCBtYWluKHZvaWQpIHsKLSAgcHRocmVhZF9hdGZvcmso MCwwLDApOwotICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKLX0KK2lmIHRlc3QgIngkcHl0aG9u dG9vbHMiID0gInh5IjsgdGhlbiA6CiAKLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJ TkVOTyI7IHRoZW4gOgorICAgIGlmIGVjaG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAiXi8iOyB0aGVu IDoKIAorICAgICAgICBQWVRIT05QQVRIPSRQWVRIT04KKyAgICAgICAgUFlUSE9OPWBiYXNlbmFt ZSAkUFlUSE9OUEFUSGAKKworZWxpZiB0ZXN0IC16ICIkUFlUSE9OIjsgdGhlbiA6CisgIFBZVEhP Tj0icHl0aG9uIgogZWxzZQotICBheF9jdl9wdGhyZWFkX2ZsYWdzPWZhaWxlZAorICBhc19mbl9l cnJvciAkPyAiUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoIiAi JExJTkVOTyIgNQogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl eHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgIyBFeHRy YWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg IiR7YWNfY3ZfcGF0aF9QWVRIT05QQVRIK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSog fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgK K2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K KyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K KyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Bh dGhfUFlUSE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf c2F2ZV9JRlMKIAotICAgIENGTEFHUz0iJHNhdmVkX0NGTEFHUyIKKyAgdGVzdCAteiAiJGFjX2N2 X3BhdGhfUFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKKyAgOzsKK2Vz YWMKK2ZpCitQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKK2lmIHRlc3QgLW4gIiRQ WVRIT05QQVRIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQorJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7 IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQogCi0gICAgTERGTEFHUz0iJHNh dmVkX0xERkxBR1MiCiAKLSAgICBMSUJTPSIkc2F2ZWRfTElCUyIKK2lmIHRlc3QgeCIke1BZVEhP TlBBVEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu ZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQorZmkKKyAgICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRo b24gdmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24g dmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgc3lz LmV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCitpZiB0ZXN0ICIkPyIg IT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAgICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor JGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiJHB5dGhvbl92ZXJzaW9u IGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAyLjMiICIkTElORU5PIiA1 CitlbHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KK2ZpCiAKK2FjX3ByZXZpb3VzX2Nw cGZsYWdzPSRDUFBGTEFHUworYWNfcHJldmlvdXNfbGRmbGFncz0kTERGTEFHUworYWNfcHl0aG9u X3ZlcnNpb249YCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAg cHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiVkVSU0lPTiIpJ2AKKyMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJFBZVEhPTi1jb25maWciLCBzbyBpdCBjYW4gYmUg YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRQWVRIT04tY29uZmlnOyBhY193 b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9weWNvbmZpZytzZXR9IiA9IHNldDsgdGhl biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJHB5Y29uZmln IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkcHljb25m aWciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7Owor ICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg ICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor SUZTPSRhc19zYXZlX0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX3B5Y29uZmlnIiAmJiBh Y19jdl9wYXRoX3B5Y29uZmlnPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitweWNvbmZpZz0kYWNfY3Zf cGF0aF9weWNvbmZpZworaWYgdGVzdCAtbiAiJHB5Y29uZmlnIjsgdGhlbgorICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJHB5Y29uZmlnIiA+JjUKKyRh c19lY2hvICIkcHljb25maWciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0K IGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4 X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQotJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+ JjY7IH0KLSAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhl bgotICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5F Tk8iIDUKLSAgICBmaQotCi0gICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdz IgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVB RF9MSUJTPSIiCiAKIAoraWYgdGVzdCB4IiRweWNvbmZpZyIgPT0geCJubyI7IHRoZW4gOgogCi17 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9j a19nZXR0aW1lIGluIC1scnQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dl dHRpbWUgaW4gLWxydC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfcnRfY2xvY2tf Z2V0dGltZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1scnQgICRMSUJT IgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLworICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1w b3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgIi1JIiArIGRpc3R1dGls cy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIklOQ0xVREVQWSIpJ2AiCisgICAgQ1BQRkxBR1M9 IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAg ICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZMQUdTIikn YCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5z eXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmln X3ZhcigiTElCUyIpJ2AiCisgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9y dCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25m aWcuZ2V0X2NvbmZpZ192YXIoIlNZU0xJQlMiKSdgIgorICAgIExERkxBR1M9IiRMREZMQUdTIGAk UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCAi LUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNpZmljPTEs XAorICAgICAgICBzdGFuZGFyZF9saWI9MSkgKyAiL2NvbmZpZyInYCIKKyAgICBMREZMQUdTPSIk TERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAg ICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZPUlNIQVJF RCIpJ2AiCisgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp bHMuc3lzY29uZmlnOyBcCisgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv bmZpZ192YXIoIkxERkxBR1MiKSdgIgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGNsb2NrX2dldHRpbWUgKCk7Ci1pbnQKLW1h aW4gKCkKLXsKLXJldHVybiBjbG9ja19nZXR0aW1lICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xp Yl9ydF9jbG9ja19nZXR0aW1lPXllcwogZWxzZQotICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt ZT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAot ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19s aWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPiY1Ci0kYXNfZWNobyAiJGFj X2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3J0 X2Nsb2NrX2dldHRpbWUiID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B Q0VPRgotI2RlZmluZSBIQVZFX0xJQlJUIDEKLV9BQ0VPRgogCi0gIExJQlM9Ii1scnQgJExJQlMi CisgICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9OLWNvbmZpZyAtLWNmbGFnc2AiCisg ICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04tY29uZmlnIC0tbGRmbGFnc2AiCiAKIGZpCiAK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHlh amxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB5YWpsX2Fs bG9jIGluIC1seWFqbC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfeWFqbF95YWps X2FsbG9jK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx5YWpsICAkTElC UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj b25mZGVmcy5oLiAgKi8KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJQ eXRob24uaCIgImFjX2N2X2hlYWRlcl9QeXRob25faCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor aWYgdGVzdCAieCRhY19jdl9oZWFkZXJfUHl0aG9uX2giID0geCIieWVzOyB0aGVuIDoKIAotLyog T3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0g ICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBH Q0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGls bCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hh ciB5YWpsX2FsbG9jICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4geWFqbF9hbGxvYyAoKTsK LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVO TyI7IHRoZW4gOgotICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19j dl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u ZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l eHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs ZSB0byBmaW5kIFB5dGhvbiBkZXZlbG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQogZmkKLXsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli X3lhamxfeWFqbF9hbGxvYyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxs b2MiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInll czsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9MSUJZ QUpMIDEKLV9BQ0VPRgotCi0gIExJQlM9Ii1seWFqbCAkTElCUyIKIAotZWxzZQotICBhc19mbl9l cnJvciAkPyAiQ291bGQgbm90IGZpbmQgeWFqbCIgIiRMSU5FTk8iIDUKLWZpCiAKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5 IGluIC1seiIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6 Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVDb3B5K3NldH0iID0g c2V0OyB0aGVuIDoKK2FzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9weXRob24kYWNfcHl0 aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVw bGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24uLi4g IiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1cIiIgPSBzZXQ7IHRo ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQogICBhY19jaGVja19saWJf c2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHogICRMSUJTIgorTElCUz0iLWxweXRob24kYWNfcHl0 aG9uX3ZlcnNpb24gICRMSUJTIgogY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCkBAIC03NjMyLDE4OTMgKzUzNzcsMTE3 MyBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAjaWZkZWYg X19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBkZWZsYXRlQ29weSAoKTsKK2No YXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIGRlZmxhdGVD b3B5ICgpOworcmV0dXJuIFB5QXJnX1BhcnNlVHVwbGUgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9 CiBfQUNFT0YKIGlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf bGliX3pfZGVmbGF0ZUNvcHk9eWVzCisgIGV2YWwgIiRhc19hY19MaWI9eWVzIgogZWxzZQotICBh Y19jdl9saWJfel9kZWZsYXRlQ29weT1ubworICBldmFsICIkYXNfYWNfTGliPW5vIgogZmkKIHJt IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAogICAgIGNvbmZ0ZXN0 JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CiBMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxh dGVDb3B5IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID0geCIi eWVzOyB0aGVuIDoKK2V2YWwgYWNfcmVzPVwkJGFzX2FjX0xpYgorCSAgICAgICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNf ZWNobyAiJGFjX3JlcyIgPiY2OyB9CitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0xpYiJcIiA9 IHgieWVzIjsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFW RV9MSUJaIDEKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFX0xJQnB5dGhvbiRhY19weXRob25fdmVy c2lvbiIgfCAkYXNfdHJfY3BwYCAxCiBfQUNFT0YKIAotICBMSUJTPSItbHogJExJQlMiCi0KLWVs c2UKLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1Ci1m aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y IGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9s aWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJ QlM9Ii1saWNvbnYgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworICBMSUJTPSItbHB5dGhvbiRhY19weXRo b25fdmVyc2lvbiAkTElCUyIKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMK LWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBsaWJpY29udl9vcGVuICgpOwotaW50Ci1tYWluICgp Ci17Ci1yZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfaWNv bnZfbGliaWNvbnZfb3Blbj15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29w ZW49bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tf bGliX3NhdmVfTElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQotJGFzX2VjaG8g IiRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2 X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYmljb252PSJ5 IgogZWxzZQotICBsaWJpY29udj0ibiIKKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k IGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1CiBmaQog CitDUFBGTEFHUz0kYWNfcHJldmlvdXNfY3BwZmxhZ3MKK0xETEZBR1M9JGFjX3ByZXZpb3VzX2xk ZmxhZ3MKIAogCi0jIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgotIyBUaGUgVWx0cml4IDQuMiBt aXBzIGJ1aWx0aW4gYWxsb2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKLSMgZm9y IGNvbnN0YW50IGFyZ3VtZW50cy4gIFVzZWxlc3MhCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X3dvcmtpbmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorZmkKKyMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRl c3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxhbGxvY2Eu aD4KLWludAotbWFpbiAoKQotewotY2hhciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVv ZiAoaW50KSk7Ci0JCQkgIGlmIChwKSByZXR1cm4gMDsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9B Q0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl93b3Jr aW5nX2FsbG9jYV9oPXllcwotZWxzZQotICBhY19jdl93b3JraW5nX2FsbG9jYV9oPW5vCisgIGNh c2UgJFhHRVRURVhUIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hHRVRU RVhUPSIkWEdFVFRFWFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBw YXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S Citmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXog IiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj dXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7 IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hHRVRURVhUPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hH RVRURVhUIiAmJiBhY19jdl9wYXRoX1hHRVRURVhUPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1ybSAt ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRh Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdFVFRFWFQK K2lmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1CiskYXNfZWNobyAiJFhHRVRU RVhUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2Fs bG9jYV9oIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9Ci1p ZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9jYV9oID0geWVzOyB0aGVuCiAKLSRhc19lY2hvICIj ZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5jb25mZGVmcy5oCiAKK2lmIHRlc3QgeCIke1hHRVRU RVhUfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg eGdldHRleHQsIHBsZWFzZSBpbnN0YWxsIHhnZXR0ZXh0IiAiJExJTkVOTyIgNQogZmkKLQoteyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgYWxsb2Nh IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBhbGxvY2EuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorIyBFeHRy YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l IHdpdGggYXJncy4KK3NldCBkdW1teSBhczg2OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf Y3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg IiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4 dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmZGVmIF9fR05VQ19fCi0jIGRlZmluZSBhbGxv Y2EgX19idWlsdGluX2FsbG9jYQotI2Vsc2UKLSMgaWZkZWYgX01TQ19WRVIKLSMgIGluY2x1ZGUg PG1hbGxvYy5oPgotIyAgZGVmaW5lIGFsbG9jYSBfYWxsb2NhCi0jIGVsc2UKLSMgIGlmZGVmIEhB VkVfQUxMT0NBX0gKLSMgICBpbmNsdWRlIDxhbGxvY2EuaD4KLSMgIGVsc2UKLSMgICBpZmRlZiBf QUlYCi0gI3ByYWdtYSBhbGxvY2EKLSMgICBlbHNlCi0jICAgIGlmbmRlZiBhbGxvY2EgLyogcHJl ZGVmaW5lZCBieSBIUCBjYyArT2xpYmNhbGxzICovCi1jaGFyICphbGxvY2EgKCk7Ci0jICAgIGVu ZGlmCi0jICAgZW5kaWYKLSMgIGVuZGlmCi0jIGVuZGlmCi0jZW5kaWYKLQotaW50Ci1tYWluICgp Ci17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgxKTsKLQkJCQkgICAgaWYgKHApIHJldHVy biAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPXllcwotZWxzZQotICBh Y19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf ZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxs b2NhX3dvcmtzIiA+JjY7IH0KLQotaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5 ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5o CisgIGNhc2UgJEFTODYgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQVM4 Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo ZW4KKyAgICBhY19jdl9wYXRoX0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisg ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l CitJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNf Y3ZfcGF0aF9BUzg2PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitBUzg2PSRhY19jdl9wYXRoX0FTODYK K2lmIHRlc3QgLW4gIiRBUzg2IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJEFTODYiID4mNQorJGFzX2VjaG8gIiRBUzg2IiA+JjY7IH0K IGVsc2UKLSAgIyBUaGUgU1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGlu Y29tcGF0aWJsZSBmdW5jdGlvbnMKLSMgdGhhdCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9u cyBkbyBub3QgZXZlbiBjb250YWluIGFsbG9jYSBvcgotIyBjb250YWluIGEgYnVnZ3kgdmVyc2lv bi4gIElmIHlvdSBzdGlsbCB3YW50IHRvIHVzZSB0aGVpciBhbGxvY2EsCi0jIHVzZSBhciB0byBl eHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBpbnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4K LQotQUxMT0NBPVwke0xJQk9CSkRJUn1hbGxvY2EuJGFjX29iamV4dAotCi0kYXNfZWNobyAiI2Rl ZmluZSBDX0FMTE9DQSAxIiA+PmNvbmZkZWZzLmgKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm aQogCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg d2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcy4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9vc19jcmF5K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgeCIk e0FTODZ9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu ZCBhczg2LCBwbGVhc2UgaW5zdGFsbCBhczg2IiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0 aGUgZmlyc3Qgd29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo IGFyZ3MuCitzZXQgZHVtbXkgbGQ4NjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Bh dGhfTEQ4NitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q IGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZiBkZWZpbmVkIENSQVkgJiYgISBkZWZpbmVkIENSQVky Ci13ZWJlY3JheQotI2Vsc2UKLXdlbm90YmVjcmF5Ci0jZW5kaWYKKyAgY2FzZSAkTEQ4NiBpbgor ICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9MRDg2PSIkTEQ4NiIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94 ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf TEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK IAotX0FDRU9GCi1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0g ICRFR1JFUCAid2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0gIGFjX2N2X29zX2Ny YXk9eWVzCi1lbHNlCi0gIGFjX2N2X29zX2NyYXk9bm8KKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhf TEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKKyAgOzsKK2VzYWMKIGZpCi1ybSAtZiBjb25m dGVzdCoKLQorTEQ4Nj0kYWNfY3ZfcGF0aF9MRDg2CitpZiB0ZXN0IC1uICIkTEQ4NiI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRMRDg2 IiA+JjUKKyRhc19lY2hvICIkTEQ4NiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m NjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiAkYWNfY3Zfb3NfY3JheSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQot aWYgdGVzdCAkYWNfY3Zfb3NfY3JheSA9IHllczsgdGhlbgotICBmb3IgYWNfZnVuYyBpbiBfZ2V0 YjY3IEdFVEI2NyBnZXRiNjc7IGRvCi0gICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVu Y18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIk YWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9 IHgieWVzIjsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgQ1JB WV9TVEFDS1NFR19FTkQgJGFjX2Z1bmMKLV9BQ0VPRgogCi0gICAgYnJlYWsKLWZpCiAKLSAgZG9u ZQoraWYgdGVzdCB4IiR7TEQ4Nn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8g IlVuYWJsZSB0byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBm aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHN0 YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgc3Rh Y2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9j X3N0YWNrX2RpcmVjdGlvbitzZXR9IiA9IHNldDsgdGhlbiA6CisjIEV4dHJhY3QgdGhlIGZpcnN0 IHdvcmQgb2YgImJjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz ZXQgZHVtbXkgYmNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQ0Mrc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBp ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Nfc3RhY2tf ZGlyZWN0aW9uPTAKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWlu dAotZmluZF9zdGFja19kaXJlY3Rpb24gKCkKLXsKLSAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOwot ICBhdXRvIGNoYXIgZHVtbXk7Ci0gIGlmIChhZGRyID09IDApCi0gICAgewotICAgICAgYWRkciA9 ICZkdW1teTsKLSAgICAgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKTsKLSAgICB9Ci0g IGVsc2UKLSAgICByZXR1cm4gKCZkdW1teSA+IGFkZHIpID8gMSA6IC0xOwotfQorICBjYXNlICRC Q0MgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkNDPSIkQkNDIiAjIExl dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf cGF0aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRh c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVf SUZTCiAKLWludAotbWFpbiAoKQotewotICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCkg PCAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAg YWNfY3ZfY19zdGFja19kaXJlY3Rpb249MQotZWxzZQotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlv bj0tMQotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i ZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkNDIiAmJiBhY19j dl9wYXRoX0JDQz0ibm8iCisgIDs7Citlc2FjCiBmaQotCitCQ0M9JGFjX2N2X3BhdGhfQkNDCitp ZiB0ZXN0IC1uICIkQkNDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJEJDQyIgPiY1CiskYXNfZWNobyAiJEJDQyIgPiY2OyB9CitlbHNl CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24iID4mNQotJGFz X2VjaG8gIiRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY2OyB9Ci1jYXQgPj5jb25mZGVmcy5o IDw8X0FDRU9GCi0jZGVmaW5lIFNUQUNLX0RJUkVDVElPTiAkYWNfY3ZfY19zdGFja19kaXJlY3Rp b24KLV9BQ0VPRgogCiAKK2lmIHRlc3QgeCIke0JDQ30iID09IHgibm8iCit0aGVuCisgICAgYXNf Zm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAiJExJ TkVOTyIgNQogZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0k MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2 OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfSUFTTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJElBU0wgaW4KKyAgW1xcL10q IHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9 JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0lBU0w9IiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLWZvciBh Y19oZWFkZXIgaW4gIFwKLSAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5 cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKLSAgICAgICAgICAgICAgICBuZXRk Yi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCi0g ICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21vdW50 Lmggc3lzL3BhcmFtLmggXAotICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZm cy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKLSAgICAgICAgICAgICAgICB1bmlz dGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfSUFTTCIg JiYgYWNfY3ZfcGF0aF9JQVNMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitJQVNMPSRhY19jdl9wYXRo X0lBU0wKK2lmIHRlc3QgLW4gIiRJQVNMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElBU0wiID4mNQorJGFzX2VjaG8gIiRJQVNMIiA+ JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQogCi1kbyA6Ci0gIGFzX2Fj X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK LWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgZXZhbCB0ZXN0IFwieFwkIiRh c19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD RU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEK LV9BQ0VPRgogCitpZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgaWFzbCwgcGxlYXNlIGluc3RhbGwgaWFzbCIgIiRMSU5F Tk8iIDUKIGZpCiAKLWRvbmUKLQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO TyIgInV1aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVz X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7 IHRoZW4gOgogCi0jIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxl ciBjaGFyYWN0ZXJpc3RpY3MuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OS4uLiAi ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oK3NldH0iID0gc2V0OyB0 aGVuIDoKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm b3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGli X3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh Y19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx1dWlkICAkTElC UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBj b25mZGVmcy5oLiAgKi8KIAotI2luY2x1ZGUgPHN0ZGJvb2wuaD4KLSNpZm5kZWYgYm9vbAotICJl cnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIKLSNlbmRpZgotI2lmbmRlZiBmYWxzZQotICJlcnJv cjogZmFsc2UgaXMgbm90IGRlZmluZWQiCi0jZW5kaWYKLSNpZiBmYWxzZQotICJlcnJvcjogZmFs c2UgaXMgbm90IDAiCi0jZW5kaWYKLSNpZm5kZWYgdHJ1ZQotICJlcnJvcjogdHJ1ZSBpcyBub3Qg ZGVmaW5lZCIKLSNlbmRpZgotI2lmIHRydWUgIT0gMQotICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIK LSNlbmRpZgotI2lmbmRlZiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZAotICJlcnJvcjog X19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCisvKiBPdmVycmlk ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBj aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAg YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgogI2VuZGlmCi0KLQlzdHJ1Y3Qg cyB7IF9Cb29sIHM6IDE7IF9Cb29sIHQ7IH0gczsKLQotCWNoYXIgYVt0cnVlID09IDEgPyAxIDog LTFdOwotCWNoYXIgYltmYWxzZSA9PSAwID8gMSA6IC0xXTsKLQljaGFyIGNbX19ib29sX3RydWVf ZmFsc2VfYXJlX2RlZmluZWQgPT0gMSA/IDEgOiAtMV07Ci0JY2hhciBkWyhib29sKSAwLjUgPT0g dHJ1ZSA/IDEgOiAtMV07Ci0JYm9vbCBlID0gJnM7Ci0JY2hhciBmWyhfQm9vbCkgMC4wID09IGZh bHNlID8gMSA6IC0xXTsKLQljaGFyIGdbdHJ1ZV07Ci0JY2hhciBoW3NpemVvZiAoX0Jvb2wpXTsK LQljaGFyIGlbc2l6ZW9mIHMudF07Ci0JZW51bSB7IGogPSBmYWxzZSwgayA9IHRydWUsIGwgPSBm YWxzZSAqIHRydWUsIG0gPSB0cnVlICogMjU2IH07Ci0JLyogVGhlIGZvbGxvd2luZyBmYWlscyBm b3IKLQkgICBIUCBhQysrL0FOU0kgQyBCMzkxMEIgQS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLwot CV9Cb29sIG5bbV07Ci0JY2hhciBvW3NpemVvZiBuID09IG0gKiBzaXplb2YgblswXSA/IDEgOiAt MV07Ci0JY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwgMCAmJiAtMSAtIChib29sKSAwIDwgMCA/IDEg OiAtMV07Ci0jCWlmIGRlZmluZWQgX194bGNfXyB8fCBkZWZpbmVkIF9fR05VQ19fCi0JIC8qIENh dGNoIGEgYnVnIGluIElCTSBBSVggeGxjIGNvbXBpbGVyIHZlcnNpb24gNi4wLjAuMAotCSAgICBy ZXBvcnRlZCBieSBKYW1lcyBMZW1sZXkgb24gMjAwNS0xMC0wNTsgc2VlCi0JICAgIGh0dHA6Ly9s aXN0cy5nbnUub3JnL2FyY2hpdmUvaHRtbC9idWctY29yZXV0aWxzLzIwMDUtMTAvbXNnMDAwODYu aHRtbAotCSAgICBUaGlzIHRlc3QgaXMgbm90IHF1aXRlIHJpZ2h0LCBzaW5jZSB4bGMgaXMgYWxs b3dlZCB0bwotCSAgICByZWplY3QgdGhpcyBwcm9ncmFtLCBhcyB0aGUgaW5pdGlhbGl6ZXIgZm9y IHhsY2J1ZyBpcwotCSAgICBub3Qgb25lIG9mIHRoZSBmb3JtcyB0aGF0IEMgcmVxdWlyZXMgc3Vw cG9ydCBmb3IuCi0JICAgIEhvd2V2ZXIsIGRvaW5nIHRoZSB0ZXN0IHJpZ2h0IHdvdWxkIHJlcXVp cmUgYSBydW50aW1lCi0JICAgIHRlc3QsIGFuZCB0aGF0IHdvdWxkIG1ha2UgY3Jvc3MtY29tcGls YXRpb24gaGFyZGVyLgotCSAgICBMZXQgdXMgaG9wZSB0aGF0IElCTSBmaXhlcyB0aGUgeGxjIGJ1 ZywgYW5kIGFsc28gYWRkcwotCSAgICBzdXBwb3J0IGZvciB0aGlzIGtpbmQgb2YgY29uc3RhbnQg ZXhwcmVzc2lvbi4gIEluIHRoZQotCSAgICBtZWFudGltZSwgdGhpcyB0ZXN0IHdpbGwgcmVqZWN0 IHhsYywgd2hpY2ggaXMgT0ssIHNpbmNlCi0JICAgIG91ciBzdGRib29sLmggc3Vic3RpdHV0ZSBz aG91bGQgc3VmZmljZS4gIFdlIGFsc28gdGVzdAotCSAgICB0aGlzIHdpdGggR0NDLCB3aGVyZSBp dCBzaG91bGQgd29yaywgdG8gZGV0ZWN0IG1vcmUKLQkgICAgcXVpY2tseSB3aGV0aGVyIHNvbWVv bmUgbWVzc2VzIHVwIHRoZSB0ZXN0IGluIHRoZQotCSAgICBmdXR1cmUuICAqLwotCSBjaGFyIGRp Z3NbXSA9ICIwMTIzNDU2Nzg5IjsKLQkgaW50IHhsY2J1ZyA9IDEgLyAoJihkaWdzICsgNSlbLTIg KyAoYm9vbCkgMV0gPT0gJmRpZ3NbNF0gPyAxIDogLTEpOwotIwllbmRpZgotCS8qIENhdGNoIGEg YnVnIGluIGFuIEhQLVVYIEMgY29tcGlsZXIuICBTZWUKLQkgICBodHRwOi8vZ2NjLmdudS5vcmcv bWwvZ2NjLXBhdGNoZXMvMjAwMy0xMi9tc2cwMjMwMy5odG1sCi0JICAgaHR0cDovL2xpc3RzLmdu dS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMS9tc2cwMDE2MS5odG1sCi0J ICovCi0JX0Jvb2wgcSA9IHRydWU7Ci0JX0Jvb2wgKnBxID0gJnE7Ci0KK2NoYXIgdXVpZF9jbGVh ciAoKTsKIGludAogbWFpbiAoKQogewotCi0JKnBxIHw9IHE7Ci0JKnBxIHw9ICEgcTsKLQkvKiBS ZWZlciB0byBldmVyeSBkZWNsYXJlZCB2YWx1ZSwgdG8gYXZvaWQgY29tcGlsZXIgb3B0aW1pemF0 aW9ucy4gICovCi0JcmV0dXJuICghYSArICFiICsgIWMgKyAhZCArICFlICsgIWYgKyAhZyArICFo ICsgIWkgKyAhIWogKyAhayArICEhbAotCQkrICFtICsgIW4gKyAhbyArICFwICsgIXEgKyAhcHEp OwotCityZXR1cm4gdXVpZF9jbGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgot aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJf c3RkYm9vbF9oPXllcwotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPW5vCi1maQotcm0g LWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0 Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGJv b2xfaCIgPiY2OyB9Ci1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJfQm9vbCIgImFjX2N2 X3R5cGVfX0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfdHlw ZV9fQm9vbCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0j ZGVmaW5lIEhBVkVfX0JPT0wgMQotX0FDRU9GCi0KLQotZmkKLQotaWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGJvb2xfaCA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUREJP T0xfSCAxIiA+PmNvbmZkZWZzLmgKLQotZmkKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3R5cGVfdWlkX3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNo b19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5 cGVzLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+ JjUgfAotICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotICBhY19jdl90 eXBlX3VpZF90PXllcwotZWxzZQotICBhY19jdl90eXBlX3VpZF90PW5vCi1maQotcm0gLWYgY29u ZnRlc3QqCi0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJGFjX2N2X3R5cGVfdWlkX3QiID4mNQotJGFzX2VjaG8gIiRhY19jdl90eXBlX3VpZF90 IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgotCi0kYXNfZWNo byAiI2RlZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAotCi0KLSRhc19lY2hvICIjZGVmaW5l IGdpZF90IGludCIgPj5jb25mZGVmcy5oCi0KLWZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1Ci0kYXNfZWNob19uICJj aGVja2luZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfaW5saW5l K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK LSAgYWNfY3ZfY19pbmxpbmU9bm8KLWZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lu bGluZTsgZG8KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot LyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmbmRlZiBfX2NwbHVzcGx1cwotdHlwZWRlZiBpbnQg Zm9vX3Q7Ci1zdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9Ci0k YWNfa3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQotI2VuZGlmCi0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX2lubGluZT0kYWNf a3cKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1 aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubwog ZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu JGFjX2V4dAotICB0ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCi1kb25lCi0K K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0 ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9M SUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1 aWRfdXVpZF9jbGVhciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xl YXIiID0geCIieWVzOyB0aGVuIDoKKyAgbGlidXVpZD0ieSIKIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfaW5saW5lIiA+JjUKLSRh c19lY2hvICIkYWNfY3ZfY19pbmxpbmUiID4mNjsgfQogCi1jYXNlICRhY19jdl9jX2lubGluZSBp bgotICBpbmxpbmUgfCB5ZXMpIDs7Ci0gICopCi0gICAgY2FzZSAkYWNfY3ZfY19pbmxpbmUgaW4K LSAgICAgIG5vKSBhY192YWw9OzsKLSAgICAgICopIGFjX3ZhbD0kYWNfY3ZfY19pbmxpbmU7Owot ICAgIGVzYWMKLSAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jaWZuZGVmIF9fY3BsdXNw bHVzCi0jZGVmaW5lIGlubGluZSAkYWNfdmFsCi0jZW5kaWYKLV9BQ0VPRgotICAgIDs7Ci1lc2Fj CiAKLWFjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIxNiIgImFjX2N2X2NfaW50MTZfdCIK LWNhc2UgJGFjX2N2X2NfaW50MTZfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCi0gICopCitmaQog Ci1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGludDE2X3QgJGFjX2N2X2NfaW50 MTZfdAotX0FDRU9GCi07OwotZXNhYwogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAi MzIiICJhY19jdl9jX2ludDMyX3QiCi1jYXNlICRhY19jdl9jX2ludDMyX3QgaW4gIygKLSAgbm98 eWVzKSA7OyAjKAotICAqKQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg InV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm IHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1dWlk PSJ5IgorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQzMl90ICRh Y19jdl9jX2ludDMyX3QKLV9BQ0VPRgotOzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAi JExJTkVOTyIgIjY0IiAiYWNfY3ZfY19pbnQ2NF90IgotY2FzZSAkYWNfY3ZfY19pbnQ2NF90IGlu ICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKK2lmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7IHRo ZW4gOgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGludDY0X3QgJGFjX2N2 X2NfaW50NjRfdAotX0FDRU9GCi07OwotZXNhYworICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3Qg ZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIgIiRMSU5FTk8iIDUKIAotYWNfZm5fY19maW5kX2lu dFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX2ludDhfdCIKLWNhc2UgJGFjX2N2X2NfaW50OF90 IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf QUNFT0YKLSNkZWZpbmUgaW50OF90ICRhY19jdl9jX2ludDhfdAotX0FDRU9GCi07OwotZXNhYwog Ci1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJtb2RlX3QiICJhY19jdl90eXBlX21vZGVf dCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIg PSB4IiJ5ZXM7IHRoZW4gOgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg ImN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX2N1cnNlc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQi CitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9jdXJzZXNfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCisg ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig Y2xlYXIgaW4gLWxjdXJzZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGlu IC1sY3Vyc2VzLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9jdXJzZXNfY2xlYXIr c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQor ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGN1cnNlcyAgJExJQlMiCitj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl ZnMuaC4gICovCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgbW9kZV90IGlu dAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJy b3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg b2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs ZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRp ZgorY2hhciBjbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGNsZWFyICgpOworICA7 CisgIHJldHVybiAwOworfQogX0FDRU9GCi0KK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i OyB0aGVuIDoKKyAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGli X2N1cnNlc19jbGVhcj1ubwogZmkKLQotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAib2Zm X3QiICJhY19jdl90eXBlX29mZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4 JGFjX2N2X3R5cGVfb2ZmX3QiID0geCIieWVzOyB0aGVuIDoKLQorcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0 ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jdXJzZXNf Y2xlYXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA+JjY7IH0KK2lm IHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjdXJz ZXM9InkiCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgb2ZmX3Qg bG9uZyBpbnQKLV9BQ0VPRgotCisgIGN1cnNlcz0ibiIKIGZpCiAKLWFjX2ZuX2NfY2hlY2tfdHlw ZSAiJExJTkVOTyIgInBpZF90IiAiYWNfY3ZfdHlwZV9waWRfdCIgIiRhY19pbmNsdWRlc19kZWZh dWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3BpZF90IiA9IHgiInllczsgdGhlbiA6CiAKIGVs c2UKKyAgY3Vyc2VzPSJuIgorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu ZSBwaWRfdCBpbnQKLV9BQ0VPRgogCi1maQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi JExJTkVOTyIgIm5jdXJzZXMuaCIgImFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giICIkYWNfaW5jbHVk ZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgPSB4IiJ5ZXM7 IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n IGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2 X2NfcmVzdHJpY3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sbmN1cnNlcyIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIgPiY2OyB9 CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoK ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY3ZfY19yZXN0cmljdD1u bwotICAgIyBUaGUgb3JkZXIgaGVyZSBjYXRlcnMgdG8gdGhlIGZhY3QgdGhhdCBDKysgZG9lcyBu b3QgcmVxdWlyZSByZXN0cmljdC4KLSAgIGZvciBhY19rdyBpbiBfX3Jlc3RyaWN0IF9fcmVzdHJp Y3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCi0gICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElC Uz0iLWxuY3Vyc2VzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0 LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLXR5cGVkZWYgaW50ICogaW50X3B0cjsK LQlpbnQgZm9vIChpbnRfcHRyICRhY19rdyBpcCkgewotCXJldHVybiBpcFswXTsKLSAgICAgICB9 CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291 bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k aWYKK2NoYXIgY2xlYXIgKCk7CiBpbnQKIG1haW4gKCkKIHsKLWludCBzWzFdOwotCWludCAqICRh Y19rdyB0ID0gczsKLQl0WzBdID0gMDsKLQlyZXR1cm4gZm9vKHQpCityZXR1cm4gY2xlYXIgKCk7 CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM SU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2lmIGFjX2ZuX2NfdHJ5 X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9eWVzCitl bHNlCisgIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICAgIHRlc3QgIiRh Y19jdl9jX3Jlc3RyaWN0IiAhPSBubyAmJiBicmVhawotICAgZG9uZQotCitybSAtZiBjb3JlIGNv bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0 cmljdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2NfcmVzdHJpY3QiID4mNjsgfQotCi0gY2FzZSAk YWNfY3ZfY19yZXN0cmljdCBpbgotICAgcmVzdHJpY3QpIDs7Ci0gICBubykgJGFzX2VjaG8gIiNk ZWZpbmUgcmVzdHJpY3QgLyoqLyIgPj5jb25mZGVmcy5oCi0gOzsKLSAgICopICBjYXQgPj5jb25m ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHJlc3RyaWN0ICRhY19jdl9jX3Jlc3RyaWN0Ci1fQUNF T0YKLSA7OwotIGVzYWMKLQotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic2l6ZV90IiAi YWNfY3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNf Y3ZfdHlwZV9zaXplX3QiID0geCIieWVzOyB0aGVuIDoKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY1 CiskYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjY7IH0KK2lmIHRlc3QgIngk YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKKyAgbmN1cnNlcz0ieSIK IGVsc2UKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBzaXplX3QgdW5zaWdu ZWQgaW50Ci1fQUNFT0YKLQorICBuY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19jaGVja190eXBl ICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVfc3NpemVfdCIgIiRhY19pbmNsdWRlc19k ZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3NzaXplX3QiID0geCIieWVzOyB0aGVuIDoK IAogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHNzaXplX3QgaW50 Ci1fQUNFT0YKLQorICBuY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19jaGVja19tZW1iZXIgIiRM SU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0 YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9t ZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7IHRoZW4gOgogCi1jYXQgPj5j b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRSAx Ci1fQUNFT0YKK2lmIHRlc3QgIiRjdXJzZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJu IjsgdGhlbiA6CiAKKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0YWJs ZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKIAogZmkKKyMgUHJlZmVyIG5jdXJzZXMgb3Zl ciBjdXJzZXMgaWYgYm90aCBhcmUgcHJlc2VudAoraWYgdGVzdCAiJG5jdXJzZXMiID0gInkiOyB0 aGVuIDoKIAotYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0 X2Jsb2NrcyIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibG9ja3MiICIkYWNfaW5jbHVk ZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2Nr cyIgPSB4IiJ5ZXM7IHRoZW4gOgotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5l IEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKLV9BQ0VPRgorICAgIENVUlNFU19MSUJTPSIt bG5jdXJzZXMiCiAKKyRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMu aD4iID4+Y29uZmRlZnMuaAogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUX0JMT0NLUyAxIiA+ PmNvbmZkZWZzLmgKIAogZWxzZQotICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiBmaWxlYmxv Y2tzLiRhY19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBmaWxlYmxvY2tz LiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQotZmkKLQogCi1hY19mbl9jX2NoZWNrX21lbWJlciAi JExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfcmRldiIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3Rh dF9zdF9yZGV2IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X21lbWJl cl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiA9IHgiInllczsgdGhlbiA6CisgICAgQ1VSU0VTX0xJQlM9 Ii1sY3Vyc2VzIgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RS VUNUX1NUQVRfU1RfUkRFViAxCi1fQUNFT0YKKyRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VS U0VTX0ggPGN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKIAogZmkKIAotYWNfZm5fY19maW5kX3Vp bnRYX3QgIiRMSU5FTk8iICIxNiIgImFjX2N2X2NfdWludDE2X3QiCi1jYXNlICRhY19jdl9jX3Vp bnQxNl90IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKIAogCi1jYXQgPj5jb25mZGVmcy5o IDw8X0FDRU9GCi0jZGVmaW5lIHVpbnQxNl90ICRhY19jdl9jX3VpbnQxNl90Ci1fQUNFT0YKLTs7 Ci0gIGVzYWMKIAotYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2Nf dWludDMyX3QiCi1jYXNlICRhY19jdl9jX3VpbnQzMl90IGluICMoCi0gIG5vfHllcykgOzsgIygK LSAgKikKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQzMl9UIDEiID4+Y29uZmRlZnMuaAogCiAK LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDMyX3QgJGFjX2N2X2NfdWlu dDMyX3QKLV9BQ0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVO TyIgIjY0IiAiYWNfY3ZfY191aW50NjRfdCIKLWNhc2UgJGFjX2N2X2NfdWludDY0X3QgaW4gIygK LSAgbm98eWVzKSA7OyAjKAoraWYgdGVzdCAieCRhY19jdl9lbnZfUEtHX0NPTkZJR19zZXQiICE9 ICJ4c2V0IjsgdGhlbgorCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWciLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9cGtnLWNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhf UEtHX0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CitlbHNlCisgIGNhc2UgJFBLR19DT05GSUcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisg IGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJy aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OwogICAqKQorICBhc19zYXZlX0lGUz0kSUZT OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4 ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1BLR19DT05GSUc9 IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1 CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLSRh c19lY2hvICIjZGVmaW5lIF9VSU5UNjRfVCAxIiA+PmNvbmZkZWZzLmgKLQorICA7OworZXNhYwor ZmkKK1BLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJFBLR19D T05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJFBLR19DT05GSUciID4mNjsgfQor ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf QUNFT0YKLSNkZWZpbmUgdWludDY0X3QgJGFjX2N2X2NfdWludDY0X3QKLV9BQ0VPRgotOzsKLSAg ZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4 X3QiCi1jYXNlICRhY19jdl9jX3VpbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAorZmkKK2lm IHRlc3QgLXogIiRhY19jdl9wYXRoX1BLR19DT05GSUciOyB0aGVuCisgIGFjX3B0X1BLR19DT05G SUc9JFBLR19DT05GSUcKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwa2ctY29uZmln Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBwa2ct Y29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09O RklHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs c2UKKyAgY2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAg YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CiAgICopCisgIGFzX3Nh dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94 ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf YWNfcHRfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k YXNfc2F2ZV9JRlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5o Ci0KLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50OF90ICRhY19jdl9j X3VpbnQ4X3QKLV9BQ0VPRgotOzsKLSAgZXNhYwotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F Tk8iICJwdHJkaWZmX3QiICJhY19jdl90eXBlX3B0cmRpZmZfdCIgIiRhY19pbmNsdWRlc19kZWZh dWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3B0cmRpZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgot Ci1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfUFRSRElGRl9UIDEKLV9B Q0VPRgotCi0KKyAgOzsKK2VzYWMKK2ZpCithY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2Fj X3B0X1BLR19DT05GSUcKK2lmIHRlc3QgLW4gIiRhY19wdF9QS0dfQ09ORklHIjsgdGhlbgorICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3B0X1BL R19DT05GSUciID4mNQorJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KK2Vsc2UK KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1 bmN0aW9ucy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp bmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVycm9y X2F0X2xpbmUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUr c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u ZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8ZXJyb3IuaD4KLWludAotbWFpbiAoKQotewotZXJyb3Jf YXRfbGluZSAoMCwgMCwgIiIsIDAsICJhbiBlcnJvciBvY2N1cnJlZCIpOwotICA7Ci0gIHJldHVy biAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0g IGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPXllcworICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05G SUciID0geDsgdGhlbgorICAgIFBLR19DT05GSUc9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1 c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBQS0dfQ09ORklHPSRhY19wdF9QS0dfQ09O RklHCisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5vCi1maQotcm0gLWYg Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgUEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NP TkZJRyIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2Vy cm9yX2F0X2xpbmUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUgPSBu bzsgdGhlbgotICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiBlcnJvci4kYWNfb2JqZXh0ICIq ICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgZXJyb3IuJGFjX29iamV4dCIKLSA7OwotZXNh YwogCiBmaQotCi1mb3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVj a19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInZmb3JrLmgiICJhY19jdl9oZWFkZXJfdmZvcmtf aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtf aCIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5l IEhBVkVfVkZPUktfSCAxCi1fQUNFT0YKLQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVu CisJX3BrZ19taW5fdmVyc2lvbj0wLjkuMAorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtn X21pbl92ZXJzaW9uIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQg bGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbi4uLiAiID4mNjsgfQorCWlmICRQS0dfQ09O RklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgor CQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+ JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorCWVsc2UKKwkJeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9 CisJCVBLR19DT05GSUc9IiIKKwlmaQogZmkKIAotZG9uZQotCi1mb3IgYWNfZnVuYyBpbiBmb3Jr IHZmb3JrCi1kbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMi IHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIk YXNfYWNfdmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRo ZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFW RV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQotZmkKLWRvbmUKK3BrZ19mYWls ZWQ9bm8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yIGdsaWIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdsaWIuLi4gIiA+JjY7IH0K IAotaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGZvcmsi ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yay4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9mdW5jX2Zvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGls aW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcworaWYgdGVz dCAtbiAiJGdsaWJfQ0ZMQUdTIjsgdGhlbgorICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJf Q0ZMQUdTIgorIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAt biAiJFBLR19DT05GSUciICYmIFwKKyAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0y LjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xp Yi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9DRkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJn bGliLTIuMCIgMj4vZGV2L251bGxgCiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19k ZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLQotCSAgLyogQnkgUnVlZGlnZXIgS3VobG1hbm4uICov Ci0JICByZXR1cm4gZm9yayAoKSA8IDA7Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgot aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfZm9ya193 b3Jrcz15ZXMKKyAgcGtnX2ZhaWxlZD15ZXMKK2ZpCisgZWxzZQorICAgIHBrZ19mYWlsZWQ9dW50 cmllZAorZmkKK2lmIHRlc3QgLW4gIiRnbGliX0xJQlMiOyB0aGVuCisgICAgcGtnX2N2X2dsaWJf TElCUz0iJGdsaWJfTElCUyIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAg IGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9y cyBcImdsaWItMi4wXCIiOyB9ID4mNQorICAoJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1l cnJvcnMgImdsaWItMi4wIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj X3N0YXR1cyA9IDA7IH07IHRoZW4KKyAgcGtnX2N2X2dsaWJfTElCUz1gJFBLR19DT05GSUcgLS1s aWJzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCiBlbHNlCi0gIGFjX2N2X2Z1bmNfZm9ya193b3Jr cz1ubworICBwa2dfZmFpbGVkPXllcwogZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRl c3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFj X29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyBlbHNlCisgICAgcGtnX2Zh aWxlZD11bnRyaWVkCiBmaQogCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9mdW5jX2Zvcmtfd29ya3MiID4mNjsgfQogCisKK2lmIHRlc3QgJHBrZ19mYWlsZWQgPSB5 ZXM7IHRoZW4KKyAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKworaWYgJFBLR19DT05GSUcgLS1h dGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRoZW4KKyAgICAgICAgX3BrZ19zaG9ydF9l cnJvcnNfc3VwcG9ydGVkPXllcwogZWxzZQotICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9JGFjX2N2 X2Z1bmNfZm9yaworICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9bm8KIGZpCi1p ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KLSAgY2FzZSAk aG9zdCBpbgotICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKLSAgICAgICMgT3Zl cnJpZGUsIGFzIHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKLSAg ICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubwotICAgICAgOzsKLSAgICAqKQotICAgICAgYWNf Y3ZfZnVuY19mb3JrX3dvcmtzPXllcwotICAgICAgOzsKLSAgZXNhYwotICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19m b3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1Ci0kYXNf ZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVz c2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9Ci1maQotYWNfY3ZfZnVuY192 Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yawotaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3Jr IiA9IHh5ZXM7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3Igd29ya2luZyB2Zm9yay4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3Jr X3dvcmtzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19j dl9mdW5jX3Zmb3JrX3dvcmtzPWNyb3NzCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRoYW5rcyB0 byBQYXVsIEVnZ2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0Ci0j aW5jbHVkZSA8c3lzL3dhaXQuaD4KLSNpZmRlZiBIQVZFX1ZGT1JLX0gKLSMgaW5jbHVkZSA8dmZv cmsuaD4KLSNlbmRpZgotLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBj aGlsZCB0byBsb2NhbCBhbmQgaW5jb21pbmcKLSAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJv cGFnYXRlZCBiYWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKLSAgIGlzIHRvbGQgYWJv dXQgdGhpcyB3aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCi0gICAo ZS5nLiBnY2MgLU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2lu ZyBhCi0gICBzdGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lz dGVyIHRoYXQgaXMKLSAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLwotc3RhdGljIHZvaWQK LSNpZmRlZiBfX2NwbHVzcGx1cwotc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQotIyBlbHNl Ci1zcGFyY19hZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKLSNlbmRpZgotewotICBzdGF0aWMg cGlkX3QgY2hpbGQ7Ci0gIGlmICghY2hpbGQpIHsKLSAgICBjaGlsZCA9IHZmb3JrICgpOwotICAg IGlmIChjaGlsZCA8IDApIHsKLSAgICAgIHBlcnJvciAoInZmb3JrIik7Ci0gICAgICBfZXhpdCgy KTsKLSAgICB9Ci0gICAgaWYgKCFjaGlsZCkgewotICAgICAgYXJnID0gZ2V0cGlkKCk7Ci0gICAg ICB3cml0ZSgtMSwgIiIsIDApOwotICAgICAgX2V4aXQgKGFyZyk7Ci0gICAgfQotICB9Ci19Cisg ICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZCA9IHllczsgdGhlbgor CSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXNob3J0LWVycm9ycyAtLXBy aW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCisgICAgICAgIGVsc2UKKwkgICAgICAgIGdsaWJf UEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAor ICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBlcnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cg d2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiRnbGliX1BLR19FUlJPUlMiID4mNQogCi1pbnQKLW1h aW4gKCkKLXsKLSAgcGlkX3QgcGFyZW50ID0gZ2V0cGlkICgpOwotICBwaWRfdCBjaGlsZDsKLQot ICBzcGFyY19hZGRyZXNzX3Rlc3QgKDApOwotCi0gIGNoaWxkID0gdmZvcmsgKCk7Ci0KLSAgaWYg KGNoaWxkID09IDApIHsKLSAgICAvKiBIZXJlIGlzIGFub3RoZXIgdGVzdCBmb3Igc3BhcmMgdmZv cmsgcmVnaXN0ZXIgcHJvYmxlbXMuICBUaGlzCi0gICAgICAgdGVzdCB1c2VzIGxvdHMgb2YgbG9j YWwgdmFyaWFibGVzLCBhdCBsZWFzdCBhcyBtYW55IGxvY2FsCi0gICAgICAgdmFyaWFibGVzIGFz IG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5nIGNvbXBpbGVyCi0gICAgICAgdGVt cG9yYXJpZXMuICA0IGxvY2FscyBhcmUgZW5vdWdoIGZvciBnY2MgMS40MC4zIG9uIGEgU29sYXJp cwotICAgICAgIDQuMS4zIHNwYXJjLCBidXQgd2UgdXNlIDggdG8gYmUgc2FmZS4gIEEgYnVnZ3kg Y29tcGlsZXIgc2hvdWxkCi0gICAgICAgcmV1c2UgdGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBmb3Ig b25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCi0gICAgICAgc2luY2UgaXQgd2lsbCB0aGluayB0 aGF0IHBhcmVudCBjYW4ndCBwb3NzaWJseSBiZSB1c2VkIGFueSBtb3JlCi0gICAgICAgaW4gdGhp cyByb3V0aW5lLiAgQXNzaWduaW5nIHRvIHRoZSBsb2NhbCB2YXJpYWJsZSB3aWxsIHRodXMKLSAg ICAgICBtdW5nZSBwYXJlbnQgaW4gdGhlIHBhcmVudCBwcm9jZXNzLiAgKi8KLSAgICBwaWRfdAot ICAgICAgcCA9IGdldHBpZCgpLCBwMSA9IGdldHBpZCgpLCBwMiA9IGdldHBpZCgpLCBwMyA9IGdl dHBpZCgpLAotICAgICAgcDQgPSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRwaWQo KSwgcDcgPSBnZXRwaWQoKTsKLSAgICAvKiBDb252aW5jZSB0aGUgY29tcGlsZXIgdGhhdCBwLi5w NyBhcmUgbGl2ZTsgb3RoZXJ3aXNlLCBpdCBtaWdodAotICAgICAgIHVzZSB0aGUgc2FtZSBoYXJk d2FyZSByZWdpc3RlciBmb3IgYWxsIDggbG9jYWwgdmFyaWFibGVzLiAgKi8KLSAgICBpZiAocCAh PSBwMSB8fCBwICE9IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAotCXx8IHAgIT0gcDUgfHwgcCAh PSBwNiB8fCBwICE9IHA3KQotICAgICAgX2V4aXQoMSk7Ci0KLSAgICAvKiBPbiBzb21lIHN5c3Rl bXMgKGUuZy4gSVJJWCAzLjMpLCB2Zm9yayBkb2Vzbid0IHNlcGFyYXRlIHBhcmVudAotICAgICAg IGZyb20gY2hpbGQgZmlsZSBkZXNjcmlwdG9ycy4gIElmIHRoZSBjaGlsZCBjbG9zZXMgYSBkZXNj cmlwdG9yCi0gICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdlcyB0aGUg cGFyZW50J3MgZGVzY3JpcHRvcgotICAgICAgIGFzIHdlbGwuICBUZXN0IGZvciB0aGlzIGJ5IGNs b3Npbmcgc3Rkb3V0IGluIHRoZSBjaGlsZC4gICovCi0gICAgX2V4aXQoY2xvc2UoZmlsZW5vKHN0 ZG91dCkpICE9IDApOwotICB9IGVsc2UgewotICAgIGludCBzdGF0dXM7Ci0gICAgc3RydWN0IHN0 YXQgc3Q7CisJYXNfZm5fZXJyb3IgJD8gIlBhY2thZ2UgcmVxdWlyZW1lbnRzIChnbGliLTIuMCkg d2VyZSBub3QgbWV0OgogCi0gICAgd2hpbGUgKHdhaXQoJnN0YXR1cykgIT0gY2hpbGQpCi0gICAg ICA7Ci0gICAgcmV0dXJuICgKLQkgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3Jr aW5nPyAgKi8KLQkgY2hpbGQgPCAwCiskZ2xpYl9QS0dfRVJST1JTCiAKLQkgLyogRGlkIHRoZSBj aGlsZCBmYWlsPyAgKFRoaXMgc2hvdWxkbid0IGhhcHBlbi4pICAqLwotCSB8fCBzdGF0dXMKK0Nv bnNpZGVyIGFkanVzdGluZyB0aGUgUEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxl IGlmIHlvdQoraW5zdGFsbGVkIHNvZnR3YXJlIGluIGEgbm9uLXN0YW5kYXJkIHByZWZpeC4KIAot CSAvKiBEaWQgdGhlIHZmb3JrL2NvbXBpbGVyIGJ1ZyBvY2N1cj8gICovCi0JIHx8IHBhcmVudCAh PSBnZXRwaWQoKQorQWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZh cmlhYmxlcyBnbGliX0NGTEFHUworYW5kIGdsaWJfTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBj YWxsIHBrZy1jb25maWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0 YWlscy4iICIkTElORU5PIiA1CitlbGlmIHRlc3QgJHBrZ19mYWlsZWQgPSB1bnRyaWVkOyB0aGVu CisgICAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKwl7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJUaGUg cGtnLWNvbmZpZyBzY3JpcHQgY291bGQgbm90IGJlIGZvdW5kIG9yIGlzIHRvbyBvbGQuICBNYWtl IHN1cmUgaXQKK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52aXJvbm1l bnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKK3BhdGggdG8gcGtnLWNvbmZpZy4KIAotCSAvKiBEaWQg dGhlIGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLwotCSB8fCBmc3RhdChmaWxlbm8oc3Rk b3V0KSwgJnN0KSAhPSAwCi0JICk7Ci0gIH0KLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVu ICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitBbHRlcm5h dGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdT CithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1Nl ZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgorCitUbyBnZXQgcGtn LWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4KK1NlZSBc YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQogZWxzZQotICBh Y19jdl9mdW5jX3Zmb3JrX3dvcmtzPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25m dGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4k YWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKKwlnbGliX0NGTEFH Uz0kcGtnX2N2X2dsaWJfQ0ZMQUdTCisJZ2xpYl9MSUJTPSRwa2dfY3ZfZ2xpYl9MSUJTCisgICAg ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CiAKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4mNQot JGFzX2VjaG8gIiRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA+JjY7IH0KIAotZmk7Ci1pZiB0ZXN0 ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KLSAgYWNfY3ZfZnVuY192 Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3JrcyBn dWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVz ZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitpZiB0 ZXN0ICJcJHtleGVjX3ByZWZpeH0vbGliIiA9ICIkbGliZGlyIjsgdGhlbiA6CisgIGlmIHRlc3Qg IiRleGVjX3ByZWZpeCIgPSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVu IDoKKyAgZXhlY19wcmVmaXg9JHByZWZpeAogZmkKKyAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgi ID0gIk5PTkUiOyB0aGVuIDoKKyAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4CitmaQor ICAgIGlmIHRlc3QgLWQgIiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6CiAKLWlmIHRlc3Qg IngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVm aW5lIEhBVkVfV09SS0lOR19WRk9SSyAxIiA+PmNvbmZkZWZzLmgKKyAgICAgICAgTElCX1BBVEg9 ImxpYjY0IgogCiBlbHNlCiAKLSRhc19lY2hvICIjZGVmaW5lIHZmb3JrIGZvcmsiID4+Y29uZmRl ZnMuaAorICAgICAgICBMSUJfUEFUSD0ibGliIgogCiBmaQotaWYgdGVzdCAieCRhY19jdl9mdW5j X2Zvcmtfd29ya3MiID0geHllczsgdGhlbgogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1dPUktJ TkdfRk9SSyAxIiA+PmNvbmZkZWZzLmgKK2Vsc2UKIAotZmkKKyAgICBMSUJfUEFUSD0iJHtsaWJk aXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVmaXgiICsgMWB9IgogCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2 YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIgPiY2 OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0OyB0 aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgd2hpbGUgOjsgZG8K LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KLSAg ICAgI2luY2x1ZGUgPHN0ZGlvLmg+Ci1pbnQKLW1haW4gKCkKLXsKLWludCAoKmZwKSAoRklMRSAq LCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKLSAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAsIDAp ICYmIGZwIChzdGRpbiwgMCwgMCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj X2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9z b3VyY2U9bm87IGJyZWFrCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj X29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgY2F0 IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz LmguICAqLwotI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCi0jaW5jbHVkZSA8c3lzL3R5cGVz Lmg+IC8qIGZvciBvZmZfdCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAo KQotewotaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAgICByZXR1 cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwotICByZXR1 cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot ICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhawogZmkKLXJtIC1mIGNvcmUgY29u ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj b25mdGVzdC4kYWNfZXh0Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24KLSAg YnJlYWsKLWRvbmUKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKLSRhc19lY2hvICIkYWNf Y3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQotY2FzZSAkYWNfY3Zfc3lzX2xhcmdlZmls ZV9zb3VyY2UgaW4gIygKLSAgbm8gfCB1bmtub3duKSA7OwotICAqKQotY2F0ID4+Y29uZmRlZnMu aCA8PF9BQ0VPRgotI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmls ZV9zb3VyY2UKLV9BQ0VPRgotOzsKLWVzYWMKLXJtIC1yZiBjb25mdGVzdCoKLQotIyBXZSB1c2Vk IHRvIHRyeSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEg YnVnCi0jIGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIgdGhp bmdzLgotIyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdyYWRl IHRvIGEgZml4ZWQgZ2xpYmMuCi1pZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAh PSB1bmtub3duOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29u ZmRlZnMuaAogCi1maQorIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK2FjX2ZuX2NfY2hlY2tfaGVh ZGVyX21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAiYWNfY3ZfaGVhZGVyX2J6bGliX2giICIk YWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2giID0g eCIieWVzOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5nIHNsYXNo IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRs ZXMgdHJhaWxpbmcgc2xhc2guLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19sc3Rh dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEJaMl9iekRl Y29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBCWjJf YnpEZWNvbXByZXNzSW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9s aWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0 LmZpbGUKLWVjaG8gPmNvbmZ0ZXN0LmZpbGUKLWlmIHRlc3QgIiRhc19sbl9zIiA9ICJsbiAtcyIg JiYgbG4gLXMgY29uZnRlc3QuZmlsZSBjb25mdGVzdC5zeW07IHRoZW4KLSAgaWYgdGVzdCAiJGNy b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJl bmNlc19zbGFzaGVkX3N5bWxpbms9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP RiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJT PSItbGJ6MiAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAorCisvKiBP dmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAg IFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdD QworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFy IEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwogaW50CiBtYWluICgpCiB7Ci1zdHJ1Y3Qgc3RhdCBz YnVmOwotICAgICAvKiBMaW51eCB3aWxsIGRlcmVmZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWls LCBhcyByZXF1aXJlZCBieSBQT1NJWC4KLQlUaGF0IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhh dCBpdCBtZWFucyB3ZSB3aWxsIG5vdAotCWhhdmUgdG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3Rh dCB3cmFwcGVyLiAgKi8KLSAgICAgcmV0dXJuIGxzdGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVm KSA9PSAwOworcmV0dXJuIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwogICA7CiAgIHJldHVybiAw OwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcwotZWxzZQotICBh Y19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KLWZpCi1ybSAt ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj X2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k YWNfZXh0Ci1maQotCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj X2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9eWVzCiBlbHNlCi0gICMgSWYgdGhlIGBs biAtcycgY29tbWFuZCBmYWlsZWQsIHRoZW4gd2UgcHJvYmFibHkgZG9uJ3QgZXZlbgotICAjIGhh dmUgYW4gbHN0YXQgZnVuY3Rpb24uCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3Ns YXNoZWRfc3ltbGluaz1ubworICBhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PW5v CiBmaQotcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKLQorcm0gLWYgY29yZSBjb25m dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv bmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9iejJf QloyX2J6RGVjb21wcmVzc0luaXQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYnoyX0JaMl9i ekRlY29tcHJlc3NJbml0IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2J6Ml9CWjJfYnpE ZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGliPSIkemxpYiAtREhBVkVfQlpM SUIgLWxiejIiCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4m NQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxp bmsiID4mNjsgfQotCi10ZXN0ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVk X3N5bWxpbmsgPSB5ZXMgJiYKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBM U1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSyAxCi1fQUNFT0YKIAorZmkKIAotaWYgdGVzdCAi eCRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID0geG5vOyB0 aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIGxzdGF0LiRhY19vYmpleHQgIiogKSA7 OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBsc3RhdC4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCiAK LWZpCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibHptYS5oIiAiYWNf Y3ZfaGVhZGVyX2x6bWFfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j dl9oZWFkZXJfbHptYV9oIiA9IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVz IG1ha2VkZXYiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBk ZWZpbmVzIG1ha2VkZXYuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N5c190 eXBlc19oX21ha2VkZXYrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAt bGx6bWEiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bWFfc3RyZWFtX2RlY29kZXIg aW4gLWxsem1hLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9sem1hX2x6bWFfc3Ry ZWFtX2RlY29kZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgogZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sbHptYSAgJExJQlMiCitj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRl ZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgbHptYV9zdHJlYW1fZGVj b2RlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIG1ha2VkZXYoMCwgMCk7CityZXR1cm4g bHptYV9zdHJlYW1fZGVjb2RlciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYg YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJfc3lzX3R5 cGVzX2hfbWFrZWRldj15ZXMKKyAgYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15 ZXMKIGVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9bm8KKyAgYWNfY3Zf bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj1ubwogZmkKIHJtIC1mIGNvcmUgY29uZnRlc3Qu ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAogICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz dC4kYWNfZXh0Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjUKLSRhc19lY2hv ICIkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYiID4mNjsgfQotCi1pZiB0ZXN0ICRh Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5vOyB0aGVuCi1hY19mbl9jX2NoZWNr X2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL21rZGV2LmgiICJhY19jdl9oZWFkZXJfc3lz X21rZGV2X2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy X3N5c19ta2Rldl9oIiA9IHgiInllczsgdGhlbiA6Ci0KLSRhc19lY2hvICIjZGVmaW5lIE1BSk9S X0lOX01LREVWIDEiID4+Y29uZmRlZnMuaAotCitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT CiBmaQotCi0KLQotICBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2ggPSBubzsgdGhl bgotICAgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFj cm9zLmgiICJhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1 bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giID0geCIieWVzOyB0 aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgTUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRl ZnMuaAotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID4mNQorJGFzX2VjaG8gIiRhY19j dl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3Zf bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGliPSIk emxpYiAtREhBVkVfTFpNQSAtbGx6bWEiCiBmaQogCiAKLSAgZmkKIGZpCiAKLWZvciBhY19oZWFk ZXIgaW4gc3RkbGliLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ TkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAiJGFjX2luY2x1ZGVzX2Rl ZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4g OgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RETElCX0ggMQot X0FDRU9GCi0KLWZpCiAKLWRvbmUKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F Tk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIgIiRhY19pbmNsdWRl c19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHpvX2x6bzF4X2giID0geCIieWVz OyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj a2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBtYWxsb2MiID4mNQotJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgbWFsbG9jLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem8xeF9k ZWNvbXByZXNzIGluIC1sbHpvMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpvMXhf ZGVjb21wcmVzcyBpbiAtbGx6bzIuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6 bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0 aGVuIDoKLSAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsPW5vCi1lbHNlCi0gIGNhdCBjb25m ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVf TElCUz0kTElCUworTElCUz0iLWxsem8yICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZiBkZWZpbmVk IFNURENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKLSMgaW5jbHVkZSA8c3RkbGli Lmg+Ci0jZWxzZQotY2hhciAqbWFsbG9jICgpOwotI2VuZGlmCiAKKy8qIE92ZXJyaWRlIGFueSBH Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgbHpvMXhfZGVjb21w cmVzcyAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuICEgbWFsbG9jICgwKTsKK3JldHVybiBs em8xeF9kZWNvbXByZXNzICgpOwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19m bl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u dWxsPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9s aWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPXllcwogZWxzZQotICBhY19jdl9mdW5jX21hbGxvY18w X25vbm51bGw9bm8KKyAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwogZmkKLXJt IC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3Qk YWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0 LiRhY19leHQKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAor ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19s aWJfc2F2ZV9MSUJTCiBmaQotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4mNQorJGFzX2Vj aG8gIiRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA+JjY7IH0KK2lmIHRlc3QgIngk YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGli PSIkemxpYiAtREhBVkVfTFpPMVggLWxsem8yIgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+ JjUKLSRhc19lY2hvICIkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KLWlmIHRl c3QgJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCA9IHllczsgdGhlbiA6Ci0KLSRhc19lY2hv ICIjZGVmaW5lIEhBVkVfTUFMTE9DIDEiID4+Y29uZmRlZnMuaAotCi1lbHNlCi0gICRhc19lY2hv ICIjZGVmaW5lIEhBVkVfTUFMTE9DIDAiID4+Y29uZmRlZnMuaAotCi0gICBjYXNlICIgJExJQk9C SlMgIiBpbgotICAqIiBtYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRM SUJPQkpTIG1hbGxvYy4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCi0KIAotJGFzX2VjaG8gIiNkZWZp bmUgbWFsbG9jIHJwbF9tYWxsb2MiID4+Y29uZmRlZnMuaAogCiBmaQogCiAKLXsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5k IHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgd2hldGhlciB0aW1lLmggYW5kIHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4g OgorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBpb19zZXR1cCBpbiAtbGFpbyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW9fc2V0 dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2Fpb19pb19zZXR1 cCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hl Y2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZz LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwot I2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy90aW1lLmg+Ci0jaW5jbHVkZSA8 dGltZS5oPgogCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p ZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1 cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90 eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJD IgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwogaW50CiBtYWluICgpCiB7Ci1pZiAoKHN0cnVj dCB0bSAqKSAwKQotcmV0dXJuIDA7CityZXR1cm4gaW9fc2V0dXAgKCk7CiAgIDsKICAgcmV0dXJu IDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK LSAgYWNfY3ZfaGVhZGVyX3RpbWU9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg dGhlbiA6CisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9eWVzCiBlbHNlCi0gIGFjX2N2X2hlYWRl cl90aW1lPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4 dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2 X2hlYWRlcl90aW1lIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0 aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIFRJTUVfV0lUSF9TWVNfVElNRSAxIiA+PmNvbmZkZWZz LmgKLQorICBhY19jdl9saWJfYWlvX2lvX3NldHVwPW5vCiBmaQotCi0KLQotCi0gIGZvciBhY19o ZWFkZXIgaW4gJGFjX2hlYWRlcl9saXN0Ci1kbyA6Ci0gIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8g ImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfaGVh ZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19p bmNsdWRlc19kZWZhdWx0Ci0iCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9 IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRh c19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCi0KK3JtIC1m IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFj X2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBm aQotCi1kb25lCi0KLQotCi0KLQotCi0KLQotICBmb3IgYWNfZnVuYyBpbiAkYWNfZnVuY19saXN0 Ci1kbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz X3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNf dmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgot ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNf ZnVuYyIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRh c19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2 X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vs c2UKKyAgc3lzdGVtX2Fpbz0ibiIKIGZpCi1kb25lCi0KIAogCi0KLQoteyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUiID4m NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgor eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgTUQ1 IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlw dG8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBz ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0 ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfd29ya2luZ19t a3RpbWU9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj X2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJ QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQg Y29uZmRlZnMuaC4gICovCi0vKiBUZXN0IHByb2dyYW0gZnJvbSBQYXVsIEVnZ2VydCBhbmQgVG9u eSBMZW5laXMuICAqLwotI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQotIyBpbmNsdWRlIDxzeXMv dGltZS5oPgotIyBpbmNsdWRlIDx0aW1lLmg+Ci0jZWxzZQotIyBpZmRlZiBIQVZFX1NZU19USU1F X0gKLSMgIGluY2x1ZGUgPHN5cy90aW1lLmg+Ci0jIGVsc2UKLSMgIGluY2x1ZGUgPHRpbWUuaD4K LSMgZW5kaWYKLSNlbmRpZgotCi0jaW5jbHVkZSA8bGltaXRzLmg+Ci0jaW5jbHVkZSA8c3RkbGli Lmg+CiAKLSNpZmRlZiBIQVZFX1VOSVNURF9ICi0jIGluY2x1ZGUgPHVuaXN0ZC5oPgotI2VuZGlm Ci0KLSNpZm5kZWYgSEFWRV9BTEFSTQotIyBkZWZpbmUgYWxhcm0oWCkgLyogZW1wdHkgKi8KKy8q IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgor ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg R0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp bGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCiAjZW5kaWYKLQot LyogV29yayBhcm91bmQgcmVkZWZpbml0aW9uIHRvIHJwbF9wdXRlbnYgYnkgb3RoZXIgY29uZmln IHRlc3RzLiAgKi8KLSN1bmRlZiBwdXRlbnYKLQotc3RhdGljIHRpbWVfdCB0aW1lX3RfbWF4Owot c3RhdGljIHRpbWVfdCB0aW1lX3RfbWluOwotCi0vKiBWYWx1ZXMgd2UnbGwgdXNlIHRvIHNldCB0 aGUgVFogZW52aXJvbm1lbnQgdmFyaWFibGUuICAqLwotc3RhdGljIGNvbnN0IGNoYXIgKnR6X3N0 cmluZ3NbXSA9IHsKLSAgKGNvbnN0IGNoYXIgKikgMCwgIlRaPUdNVDAiLCAiVFo9SlNULTkiLAot ICAiVFo9RVNUKzNFRFQrMixNMTAuMS4wLzAwOjAwOjAwLE0yLjMuMC8wMDowMDowMCIKLX07Ci0j ZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9zdHJpbmdzKSAvIHNpemVvZiAodHpfc3RyaW5n c1swXSkpCi0KLS8qIFJldHVybiAwIGlmIG1rdGltZSBmYWlscyB0byBjb252ZXJ0IGEgZGF0ZSBp biB0aGUgc3ByaW5nLWZvcndhcmQgZ2FwLgotICAgQmFzZWQgb24gYSBwcm9ibGVtIHJlcG9ydCBm cm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8KLXN0YXRpYyBpbnQKLXNwcmluZ19mb3J3YXJkX2dhcCAo KQotewotICAvKiBnbGliYyAodXAgdG8gYWJvdXQgMTk5OC0xMC0wNykgZmFpbGVkIHRoaXMgdGVz dC4gKi8KLSAgc3RydWN0IHRtIHRtOwotCi0gIC8qIFVzZSB0aGUgcG9ydGFibGUgUE9TSVguMSBz cGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgotICAgICBpbnN0ZWFkIG9m ICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBidWcgZXZlbgot ICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0ZW5zaW9uLCBv ciBkb24ndCBoYXZlIHRoZQotICAgICBmdWxsIHpvbmVpbmZvIHRhYmxlcyBpbnN0YWxsZWQuICAq LwotICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiKTsKLQotICB0 bS50bV95ZWFyID0gOTg7Ci0gIHRtLnRtX21vbiA9IDM7Ci0gIHRtLnRtX21kYXkgPSA1OwotICB0 bS50bV9ob3VyID0gMjsKLSAgdG0udG1fbWluID0gMDsKLSAgdG0udG1fc2VjID0gMDsKLSAgdG0u dG1faXNkc3QgPSAtMTsKLSAgcmV0dXJuIG1rdGltZSAoJnRtKSAhPSAodGltZV90KSAtMTsKLX0K LQotc3RhdGljIGludAotbWt0aW1lX3Rlc3QxICh0aW1lX3Qgbm93KQotewotICBzdHJ1Y3QgdG0g Kmx0OwotICByZXR1cm4gISAobHQgPSBsb2NhbHRpbWUgKCZub3cpKSB8fCBta3RpbWUgKGx0KSA9 PSBub3c7Ci19Ci0KLXN0YXRpYyBpbnQKLW1rdGltZV90ZXN0ICh0aW1lX3Qgbm93KQotewotICBy ZXR1cm4gKG1rdGltZV90ZXN0MSAobm93KQotCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAo dGltZV90X21heCAtIG5vdykpCi0JICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3Rf bWluICsgbm93KSkpOwotfQotCi1zdGF0aWMgaW50Ci1pcml4XzZfNF9idWcgKCkKLXsKLSAgLyog QmFzZWQgb24gY29kZSBmcm9tIEFyaWVsIEZhaWdvbi4gICovCi0gIHN0cnVjdCB0bSB0bTsKLSAg dG0udG1feWVhciA9IDk2OwotICB0bS50bV9tb24gPSAzOwotICB0bS50bV9tZGF5ID0gMDsKLSAg dG0udG1faG91ciA9IDA7Ci0gIHRtLnRtX21pbiA9IDA7Ci0gIHRtLnRtX3NlYyA9IDA7Ci0gIHRt LnRtX2lzZHN0ID0gLTE7Ci0gIG1rdGltZSAoJnRtKTsKLSAgcmV0dXJuIHRtLnRtX21vbiA9PSAy ICYmIHRtLnRtX21kYXkgPT0gMzE7Ci19Ci0KLXN0YXRpYyBpbnQKLWJpZ3RpbWVfdGVzdCAoaW50 IGopCi17Ci0gIHN0cnVjdCB0bSB0bTsKLSAgdGltZV90IG5vdzsKLSAgdG0udG1feWVhciA9IHRt LnRtX21vbiA9IHRtLnRtX21kYXkgPSB0bS50bV9ob3VyID0gdG0udG1fbWluID0gdG0udG1fc2Vj ID0gajsKLSAgbm93ID0gbWt0aW1lICgmdG0pOwotICBpZiAobm93ICE9ICh0aW1lX3QpIC0xKQot ICAgIHsKLSAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwotICAgICAgaWYg KCEgKGx0Ci0JICAgICAmJiBsdC0+dG1feWVhciA9PSB0bS50bV95ZWFyCi0JICAgICAmJiBsdC0+ dG1fbW9uID09IHRtLnRtX21vbgotCSAgICAgJiYgbHQtPnRtX21kYXkgPT0gdG0udG1fbWRheQot CSAgICAgJiYgbHQtPnRtX2hvdXIgPT0gdG0udG1faG91cgotCSAgICAgJiYgbHQtPnRtX21pbiA9 PSB0bS50bV9taW4KLQkgICAgICYmIGx0LT50bV9zZWMgPT0gdG0udG1fc2VjCi0JICAgICAmJiBs dC0+dG1feWRheSA9PSB0bS50bV95ZGF5Ci0JICAgICAmJiBsdC0+dG1fd2RheSA9PSB0bS50bV93 ZGF5Ci0JICAgICAmJiAoKGx0LT50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCBsdC0+dG1faXNkc3Qp Ci0JCSAgPT0gKHRtLnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IHRtLnRtX2lzZHN0KSkpKQotCXJl dHVybiAwOwotICAgIH0KLSAgcmV0dXJuIDE7Ci19Ci0KLXN0YXRpYyBpbnQKLXllYXJfMjA1MF90 ZXN0ICgpCi17Ci0gIC8qIFRoZSBjb3JyZWN0IGFuc3dlciBmb3IgMjA1MC0wMi0wMSAwMDowMDow MCBpbiBQYWNpZmljIHRpbWUsCi0gICAgIGlnbm9yaW5nIGxlYXAgc2Vjb25kcy4gICovCi0gIHVu c2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKLQotICBzdHJ1Y3QgdG0gdG07 Ci0gIHRpbWVfdCB0OwotICB0bS50bV95ZWFyID0gMjA1MCAtIDE5MDA7Ci0gIHRtLnRtX21vbiA9 IDIgLSAxOwotICB0bS50bV9tZGF5ID0gMTsKLSAgdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRt LnRtX3NlYyA9IDA7Ci0gIHRtLnRtX2lzZHN0ID0gLTE7Ci0KLSAgLyogVXNlIHRoZSBwb3J0YWJs ZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCi0gICAg IGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhl IGJ1ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBl eHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGlu c3RhbGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu MCIpOwotCi0gIHQgPSBta3RpbWUgKCZ0bSk7Ci0KLSAgLyogQ2hlY2sgdGhhdCB0aGUgcmVzdWx0 IGlzIGVpdGhlciBhIGZhaWx1cmUsIG9yIGNsb3NlIGVub3VnaAotICAgICB0byB0aGUgY29ycmVj dCBhbnN3ZXIgdGhhdCB3ZSBjYW4gYXNzdW1lIHRoZSBkaXNjcmVwYW5jeSBpcwotICAgICBkdWUg dG8gbGVhcCBzZWNvbmRzLiAgKi8KLSAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0xCi0JICB8fCAo MCA8IHQgJiYgYW5zd2VyIC0gMTIwIDw9IHQgJiYgdCA8PSBhbnN3ZXIgKyAxMjApKTsKLX0KLQor Y2hhciBNRDUgKCk7CiBpbnQKIG1haW4gKCkKIHsKLSAgdGltZV90IHQsIGRlbHRhOwotICBpbnQg aSwgajsKLQotICAvKiBUaGlzIHRlc3QgbWFrZXMgc29tZSBidWdneSBta3RpbWUgaW1wbGVtZW50 YXRpb25zIGxvb3AuCi0gICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vjb25kczsgYSBta3RpbWUgc2xv d2VyIHRoYW4gdGhhdAotICAgICBpc24ndCB3b3J0aCB1c2luZyBhbnl3YXkuICAqLwotICBhbGFy bSAoNjApOwotCi0gIGZvciAoOzspCi0gICAgewotICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEp ICsgMTsKLSAgICAgIGlmICh0IDw9IHRpbWVfdF9tYXgpCi0JYnJlYWs7Ci0gICAgICB0aW1lX3Rf bWF4ID0gdDsKLSAgICB9Ci0gIHRpbWVfdF9taW4gPSAtICgodGltZV90KSB+ICh0aW1lX3QpIDAg PT0gKHRpbWVfdCkgLTEpIC0gdGltZV90X21heDsKLQotICBkZWx0YSA9IHRpbWVfdF9tYXggLyA5 OTc7IC8qIGEgc3VpdGFibGUgcHJpbWUgbnVtYmVyICovCi0gIGZvciAoaSA9IDA7IGkgPCBOX1NU UklOR1M7IGkrKykKLSAgICB7Ci0gICAgICBpZiAodHpfc3RyaW5nc1tpXSkKLQlwdXRlbnYgKChj aGFyKikgdHpfc3RyaW5nc1tpXSk7Ci0KLSAgICAgIGZvciAodCA9IDA7IHQgPD0gdGltZV90X21h eCAtIGRlbHRhOyB0ICs9IGRlbHRhKQotCWlmICghIG1rdGltZV90ZXN0ICh0KSkKLQkgIHJldHVy biAxOwotICAgICAgaWYgKCEgKG1rdGltZV90ZXN0ICgodGltZV90KSAxKQotCSAgICAgJiYgbWt0 aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAqIDYwKSkKLQkgICAgICYmIG1rdGltZV90ZXN0ICgodGlt ZV90KSAoNjAgKiA2MCAqIDI0KSkpKQotCXJldHVybiAxOwotCi0gICAgICBmb3IgKGogPSAxOyA7 IGogPDw9IDEpCi0JaWYgKCEgYmlndGltZV90ZXN0IChqKSkKLQkgIHJldHVybiAxOwotCWVsc2Ug aWYgKElOVF9NQVggLyAyIDwgaikKLQkgIGJyZWFrOwotICAgICAgaWYgKCEgYmlndGltZV90ZXN0 IChJTlRfTUFYKSkKLQlyZXR1cm4gMTsKLSAgICB9Ci0gIHJldHVybiAhIChpcml4XzZfNF9idWcg KCkgJiYgc3ByaW5nX2ZvcndhcmRfZ2FwICgpICYmIHllYXJfMjA1MF90ZXN0ICgpKTsKK3JldHVy biBNRDUgKCk7CisgIDsKKyAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1 biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPXllcworaWYg YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3J5cHRvX01E NT15ZXMKIGVsc2UKLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubwotZmkKLXJtIC1mIGNv cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl ZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l eHQKLWZpCi0KKyAgYWNfY3ZfbGliX2NyeXB0b19NRDU9bm8KIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3Rp bWUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KLWlm IHRlc3QgJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUgPSBubzsgdGhlbgotICBjYXNlICIgJExJ Qk9CSlMgIiBpbgotICAqIiBta3RpbWUuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9 IiRMSUJPQkpTIG1rdGltZS4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCi0KK3JtIC1mIGNvcmUgY29u ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj b25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotCi0KLQot Ci0KLQotZm9yIGFjX2Z1bmMgaW4gZ2V0cGFnZXNpemUKLWRvIDoKLSAgYWNfZm5fY19jaGVja19m dW5jICIkTElORU5PIiAiZ2V0cGFnZXNpemUiICJhY19jdl9mdW5jX2dldHBhZ2VzaXplIgotaWYg dGVzdCAieCRhY19jdl9mdW5jX2dldHBhZ2VzaXplIiA9IHgiInllczsgdGhlbiA6Cit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jcnlw dG9fTUQ1IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQoraWYg dGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01ENSIgPSB4IiJ5ZXM7IHRoZW4gOgogICBjYXQgPj5j b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfR0VUUEFHRVNJWkUgMQorI2RlZmluZSBI QVZFX0xJQkNSWVBUTyAxCiBfQUNFT0YKIAorICBMSUJTPSItbGNyeXB0byAkTElCUyIKKworZWxz ZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIg NQogZmkKLWRvbmUKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyBmb3Igd29ya2luZyBtbWFwIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3 b3JraW5nIG1tYXAuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tbWFwX2ZpeGVk X21hcHBlZCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQor JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4m NjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNl dDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3Qg IiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVk X21hcHBlZD1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k YWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZXh0MmZzICAk TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVu ZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0Ci0vKiBtYWxsb2MgbWlnaHQg aGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KLSN1bmRlZiBtYWxsb2MKLQotLyog VGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3QuCi0gICBI ZXJlIGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKLQltbWFwIHByaXZhdGUgbm90 IGZpeGVkCi0JbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBw ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCi0JbW1h cCBzaGFyZWQgbm90IGZpeGVkCi0JbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJl bnRseSB1bm1hcHBlZAotCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1h cHBlZAotICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhhdCBjaGFu Z2VzIGNhbm5vdCBiZSByZWFkKCkKLSAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1tYXAncyBi YWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKLSAgIGFkZHJlc3MuICAoVGhlcmUgaGF2 ZSBiZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQotICAgaW1wbGVt ZW50ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdoZXJlIHRo ZQotICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVt IGJ1ZmZlciBjYWNoZQotICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFuZCBwb3Nz aWJseSBjb250ZW1wb3JhcnkgTmV0QlNELikKLSAgIEZvciBzaGFyZWQgbWFwcGluZ3MsIHdlIHNo b3VsZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0Ci0gICBwcm9wYWdhdGVkIGJh Y2sgdG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KLQotICAgR3JlcCB3 YW50cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgotICAgVGhlIG1haW4gdGhpbmdzIGdy ZXAgbmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKLSAgICogZG9lcyBpdCBleGlzdCBhbmQg aXMgaXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQotICAgKiBob3cgdG8gdXNl IGl0IChCU0QgdmFyaWFudHMpICAqLwotCi0jaW5jbHVkZSA8ZmNudGwuaD4KLSNpbmNsdWRlIDxz eXMvbW1hbi5oPgotCi0jaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVkIEhBVkVf U1RETElCX0gKLWNoYXIgKm1hbGxvYyAoKTsKLSNlbmRpZgotCi0vKiBUaGlzIG1lc3Mgd2FzIGNv cGllZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCi0jaWZuZGVmIEhBVkVfR0VUUEFH RVNJWkUKLSMgaWZkZWYgX1NDX1BBR0VTSVpFCi0jICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBzeXNj b25mKF9TQ19QQUdFU0laRSkKLSMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KLSMgIGlmZGVm IEhBVkVfU1lTX1BBUkFNX0gKLSMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KLSMgICBpZmRlZiBF WEVDX1BBR0VTSVpFCi0jICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJWkUKLSMg ICBlbHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KLSMgICAgaWZkZWYgTkJQRwotIyAgICAgZGVm aW5lIGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQotIyAgICAgaWZuZGVmIENMU0laRQotIyAg ICAgIGRlZmluZSBDTFNJWkUgMQotIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCi0jICAgIGVs c2UgLyogbm8gTkJQRyAqLwotIyAgICAgaWZkZWYgTkJQQwotIyAgICAgIGRlZmluZSBnZXRwYWdl c2l6ZSgpIE5CUEMKLSMgICAgIGVsc2UgLyogbm8gTkJQQyAqLwotIyAgICAgIGlmZGVmIFBBR0VT SVpFCi0jICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCi0jICAgICAgZW5kaWYg LyogUEFHRVNJWkUgKi8KLSMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KLSMgICAgZW5kaWYgLyog bm8gTkJQRyAqLwotIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KLSMgIGVsc2UgLyog bm8gSEFWRV9TWVNfUEFSQU1fSCAqLwotIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgxOTIJLyog cHVudCB0b3RhbGx5ICovCi0jICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jIGVu ZGlmIC8qIG5vIF9TQ19QQUdFU0laRSAqLwotCi0jZW5kaWYgLyogbm8gSEFWRV9HRVRQQUdFU0la RSAqLwogCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4g dHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBl IHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgor I2VuZGlmCitjaGFyIGV4dDJmc19vcGVuMiAoKTsKIGludAogbWFpbiAoKQogewotICBjaGFyICpk YXRhLCAqZGF0YTIsICpkYXRhMzsKLSAgY29uc3QgY2hhciAqY2RhdGEyOwotICBpbnQgaSwgcGFn ZXNpemU7Ci0gIGludCBmZCwgZmQyOwotCi0gIHBhZ2VzaXplID0gZ2V0cGFnZXNpemUgKCk7Ci0K LSAgLyogRmlyc3QsIG1ha2UgYSBmaWxlIHdpdGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAq LwotICBkYXRhID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0YSkKLSAg ICByZXR1cm4gMTsKLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgKihkYXRh ICsgaSkgPSByYW5kICgpOwotICB1bWFzayAoMCk7Ci0gIGZkID0gY3JlYXQgKCJjb25mdGVzdC5t bWFwIiwgMDYwMCk7Ci0gIGlmIChmZCA8IDApCi0gICAgcmV0dXJuIDI7Ci0gIGlmICh3cml0ZSAo ZmQsIGRhdGEsIHBhZ2VzaXplKSAhPSBwYWdlc2l6ZSkKLSAgICByZXR1cm4gMzsKLSAgY2xvc2Ug KGZkKTsKLQotICAvKiBOZXh0LCBjaGVjayB0aGF0IHRoZSB0YWlsIG9mIGEgcGFnZSBpcyB6ZXJv LWZpbGxlZC4gIEZpbGUgbXVzdCBoYXZlCi0gICAgIG5vbi16ZXJvIGxlbmd0aCwgb3RoZXJ3aXNl IHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUgcGFnZS4gICovCi0gIGZkMiA9IG9wZW4gKCJjb25m dGVzdC50eHQiLCBPX1JEV1IgfCBPX0NSRUFUIHwgT19UUlVOQywgMDYwMCk7Ci0gIGlmIChmZDIg PCAwKQotICAgIHJldHVybiA0OwotICBjZGF0YTIgPSAiIjsKLSAgaWYgKHdyaXRlIChmZDIsIGNk YXRhMiwgMSkgIT0gMSkKLSAgICByZXR1cm4gNTsKLSAgZGF0YTIgPSAoY2hhciAqKSBtbWFwICgw LCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwgZmQyLCAwTCk7 Ci0gIGlmIChkYXRhMiA9PSBNQVBfRkFJTEVEKQotICAgIHJldHVybiA2OwotICBmb3IgKGkgPSAw OyBpIDwgcGFnZXNpemU7ICsraSkKLSAgICBpZiAoKihkYXRhMiArIGkpKQotICAgICAgcmV0dXJu IDc7Ci0gIGNsb3NlIChmZDIpOwotICBpZiAobXVubWFwIChkYXRhMiwgcGFnZXNpemUpKQotICAg IHJldHVybiA4OwotCi0gIC8qIE5leHQsIHRyeSB0byBtbWFwIHRoZSBmaWxlIGF0IGEgZml4ZWQg YWRkcmVzcyB3aGljaCBhbHJlYWR5IGhhcwotICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQg YXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFrZSBzdXJlIHRoYXQKLSAgICAgd2Ugc2VlIHRoZSBz YW1lIGdhcmJhZ2UuICAqLwotICBmZCA9IG9wZW4gKCJjb25mdGVzdC5tbWFwIiwgT19SRFdSKTsK LSAgaWYgKGZkIDwgMCkKLSAgICByZXR1cm4gOTsKLSAgaWYgKGRhdGEyICE9IG1tYXAgKGRhdGEy LCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwKLQkJICAgICBNQVBfUFJJVkFURSB8 IE1BUF9GSVhFRCwgZmQsIDBMKSkKLSAgICByZXR1cm4gMTA7Ci0gIGZvciAoaSA9IDA7IGkgPCBw YWdlc2l6ZTsgKytpKQotICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEyICsgaSkpCi0gICAg ICByZXR1cm4gMTE7Ci0KLSAgLyogRmluYWxseSwgbWFrZSBzdXJlIHRoYXQgY2hhbmdlcyB0byB0 aGUgbWFwcGVkIGFyZWEgZG8gbm90Ci0gICAgIHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFz IHNlZW4gYnkgcmVhZCgpLiAgKFRoaXMgaXMgYSBidWcgb24KLSAgICAgc29tZSB2YXJpYW50cyBv ZiBpMzg2IHN2cjQuMC4pICAqLwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAg ICAqKGRhdGEyICsgaSkgPSAqKGRhdGEyICsgaSkgKyAxOwotICBkYXRhMyA9IChjaGFyICopIG1h bGxvYyAocGFnZXNpemUpOwotICBpZiAoIWRhdGEzKQotICAgIHJldHVybiAxMjsKLSAgaWYgKHJl YWQgKGZkLCBkYXRhMywgcGFnZXNpemUpICE9IHBhZ2VzaXplKQotICAgIHJldHVybiAxMzsKLSAg Zm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0YSArIGkpICE9ICoo ZGF0YTMgKyBpKSkKLSAgICAgIHJldHVybiAxNDsKLSAgY2xvc2UgKGZkKTsKK3JldHVybiBleHQy ZnNfb3BlbjIgKCk7CisgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5 X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPXll cworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfZXh0 MmZzX2V4dDJmc19vcGVuMj15ZXMKIGVsc2UKLSAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBl ZD1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i ZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KKyAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3Bl bjI9bm8KIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9m dW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNfbW1hcF9m aXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NTUFQIDEi ID4+Y29uZmRlZnMuaAotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq ZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNf Y2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXJtIC1mIGNvbmZ0ZXN0Lm1tYXAgY29uZnRlc3QudHh0 Ci0KLWZvciBhY19oZWFkZXIgaW4gc3RkbGliLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVja19oZWFk ZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAi JGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIg PSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhB VkVfU1RETElCX0ggMQotX0FDRU9GCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNQorJGFz X2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY2OyB9CitpZiB0ZXN0ICJ4 JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9IHgiInllczsgdGhlbiA6CisgIGxpYmV4 dDJmcz0ieSIKK2Vsc2UKKyAgbGliZXh0MmZzPSJuIgogZmkKIAotZG9uZQogCi17ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w YXRpYmxlIHJlYWxsb2MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv bXBhdGlibGUgcmVhbGxvYy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3JlYWxs b2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxn Y3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIg aW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5 X21kX2hhc2hfYnVmZmVyK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl ZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g OgotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVm cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElC Uz0kTElCUworTElCUz0iLWxnY3J5cHQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQg U1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAotIyBpbmNsdWRlIDxzdGRsaWIu aD4KLSNlbHNlCi1jaGFyICpyZWFsbG9jICgpOwotI2VuZGlmCiAKKy8qIE92ZXJyaWRlIGFueSBH Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZ2NyeV9tZF9oYXNo X2J1ZmZlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuICEgcmVhbGxvYyAoMCwgMCk7City ZXR1cm4gZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP RgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVh bGxvY18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6 CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMKIGVsc2UKLSAgYWNf Y3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXI9bm8KIGZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21v bi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQg Y29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj b25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj X2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLQoreyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2NyeXB0X2djcnlf bWRfaGFzaF9idWZmZXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKKyAgbGliZ2NyeXB0PSJ5IgorZWxzZQorICBs aWJnY3J5cHQ9Im4iCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjUKLSRhc19lY2hvICIk YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5j X3JlYWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKIAotJGFzX2VjaG8gIiNkZWZpbmUgSEFW RV9SRUFMTE9DIDEiID4+Y29uZmRlZnMuaAogCisKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWciID4mNQorJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth eF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh Y2hlZCkgIiA+JjYKIGVsc2UKLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9SRUFMTE9DIDAiID4+ Y29uZmRlZnMuaAogCi0gICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiByZWFsbG9jLiRhY19v YmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyByZWFsbG9jLiRhY19vYmpleHQi Ci0gOzsKLWVzYWMKKyAgICAgICAgYXhfY3ZfcHRocmVhZF9mbGFncz0tcHRocmVhZAorCisgICAg UFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJFQURfTERGTEFH Uz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisKKworICAgIHNh dmVkX0NGTEFHUz0iJENGTEFHUyIKKworICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgorCisg ICAgc2F2ZWRfTElCUz0iJExJQlMiCisKKworICAgIENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9D RkxBR1MiCisKKyAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgorCisgICAg TElCUz0iJExJQlMgJFBUSFJFQURfTElCUyIKKworICAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8 X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKyNpbmNs dWRlIDxwdGhyZWFkLmg+CitpbnQgbWFpbih2b2lkKSB7CisgIHB0aHJlYWRfYXRmb3JrKDAsMCww KTsKKyAgcHRocmVhZF9jcmVhdGUoMCwwLDAsMCk7Cit9CisKK19BQ0VPRgoraWYgYWNfZm5fY190 cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGF4X2N2X3B0aHJlYWRfZmxhZ3M9 ZmFpbGVkCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBc CisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworICAgIENGTEFHUz0i JHNhdmVkX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRzYXZlZF9MREZMQUdTIgogCisgICAgTElC Uz0iJHNhdmVkX0xJQlMiCiAKLSRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3JlYWxsb2Mi ID4+Y29uZmRlZnMuaAogCiBmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjUKKyRhc19lY2hvICIkYXhfY3Zf cHRocmVhZF9mbGFncyIgPiY2OyB9CisgICAgaWYgdGVzdCAieCRheF9jdl9wdGhyZWFkX2ZsYWdz IiA9IHhmYWlsZWQ7IHRoZW4KKyAgICAgICAgYXNfZm5fZXJyb3IgJD8gIi1wdGhyZWFkIGRvZXMg bm90IHdvcmsiICIkTElORU5PIiA1CisgICAgZmkKKworICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhf Y3ZfcHRocmVhZF9mbGFncyIKKyAgICBQVEhSRUFEX0xERkxBR1M9IiRheF9jdl9wdGhyZWFkX2Zs YWdzIgorICAgIFBUSFJFQURfTElCUz0iIgorCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4uLi4gIiA+JjY7IH0KLWlmIHRlc3Qg IiR7YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxv YyBpbiAtbHlhamwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4g LWx5YWpsLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mr c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot ICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNf c3Rybmxlbl93b3JraW5nPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx5 YWpsICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJy aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNl IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisg ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFq bF9hbGxvYyAoKTsKIGludAogbWFpbiAoKQogewotCi0jZGVmaW5lIFMgImZvb2JhciIKLSNkZWZp bmUgU19MRU4gKHNpemVvZiBTIC0gMSkKLQotICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRp b24gaXMgYnVnZ3k6IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAotICAgICBnaXZlIHN0cm5sZW4gKFMs IDEpID09IDMuICAqLwotCi0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyAr K2kpCi0gICAgewotICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsK LSAgICAgIGlmIChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKLQlyZXR1cm4gMTsKLSAgICB9 Ci0gIHJldHVybiAwOwotCityZXR1cm4geWFqbF9hbGxvYyAoKTsKICAgOwogICByZXR1cm4gMDsK IH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2 X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7 IHRoZW4gOgorICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19jdl9m dW5jX3N0cm5sZW5fd29ya2luZz1ubworICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCiBm aQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25m dGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29u ZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4 dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No ZWNrX2xpYl9zYXZlX0xJQlMKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8g IiRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli X3lhamxfeWFqbF9hbGxvYyIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8 X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKIAotZmkKLXsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVu X3dvcmtpbmciID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2 OyB9Ci10ZXN0ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElC T0JKUyAiIGluCi0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9 IiRMSUJPQkpTIHN0cm5sZW4uJGFjX29iamV4dCIKLSA7OwotZXNhYworICBMSUJTPSItbHlhamwg JExJQlMiCiAKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIk TElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3Igd29ya2luZyBzdHJ0b2QuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19zdHJ0 b2Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24g ImNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7 YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll czsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k TElCUworTElCUz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0 ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotJGFjX2luY2x1ZGVzX2RlZmF1 bHQKLSNpZm5kZWYgc3RydG9kCi1kb3VibGUgc3RydG9kICgpOworLyogT3ZlcnJpZGUgYW55IEdD QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAo KTsKIGludAotbWFpbigpCittYWluICgpCiB7Ci0gIHsKLSAgICAvKiBTb21lIHZlcnNpb25zIG9m IExpbnV4IHN0cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KLSAg ICBjaGFyICpzdHJpbmcgPSAiICs2OSI7Ci0gICAgY2hhciAqdGVybTsKLSAgICBkb3VibGUgdmFs dWU7Ci0gICAgdmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh2YWx1ZSAh PSA2OSB8fCB0ZXJtICE9IChzdHJpbmcgKyA0KSkKLSAgICAgIHJldHVybiAxOwotICB9Ci0KLSAg ewotICAgIC8qIFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFs dWUgZm9yIHRoZQotICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRp dGlvbnMuICAqLwotICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwotICAgIGNoYXIgKnRlcm07Ci0g ICAgc3RydG9kIChzdHJpbmcsICZ0ZXJtKTsKLSAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0 ZXJtIC0gMSkgPT0gMCkKLSAgICAgIHJldHVybiAxOwotICB9CityZXR1cm4gZGVmbGF0ZUNvcHkg KCk7CisgIDsKICAgcmV0dXJuIDA7CiB9Ci0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPXllcworaWYgYWNfZm5fY190cnlf bGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKIGVs c2UKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNv bmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0 LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X2xpYl96 X2RlZmxhdGVDb3B5PW5vCiBmaQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElC Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNQotJGFzX2VjaG8g IiRhY19jdl9mdW5jX3N0cnRvZCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9 IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHN0cnRvZC4kYWNfb2JqZXh0 ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpleHQiCi0gOzsK LWVzYWMKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZs YXRlQ29weSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHgi InllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9M SUJaIDEKK19BQ0VPRgogCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJwb3ciICJhY19j dl9mdW5jX3BvdyIKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoK KyAgTElCUz0iLWx6ICRMSUJTIgogCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3Qg ZmluZCB6bGliIiAiJExJTkVOTyIgNQogZmkKIAotaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBu bzsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciBwb3cgaW4gLWxtIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4g LWxtLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsg dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j dl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCiAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMK LUxJQlM9Ii1sbSAgJExJQlMiCitMSUJTPSItbGljb252ICAkTElCUyIKIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApA QCAtOTUyOCw1NSArNjU1Myw0NSBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz dC4kYWNfZXh0CiAjaWZkZWYgX19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBw b3cgKCk7CitjaGFyIGxpYmljb252X29wZW4gKCk7CiBpbnQKIG1haW4gKCkKIHsKLXJldHVybiBw b3cgKCk7CityZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9B Q0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJf bV9wb3c9eWVzCisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwogZWxzZQotICBh Y19jdl9saWJfbV9wb3c9bm8KKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KIGZp CiBybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKICAgICBjb25m dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAogTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf TElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7 IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsgdGhlbiA6Ci0gIFBPV19M SUI9LWxtCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGli X2ljb252X2xpYmljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZf bGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKIGVsc2UKLSAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3Qg ZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQotJGFzX2VjaG8g IiRhc19tZTogV0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRp b24gb2YgcG93IiA+JjI7fQotZmkKLQorICBsaWJpY29udj0ibiIKIGZpCiAKLWZpCiAKLWZvciBh Y19mdW5jIGluICBcCi0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dl dHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2Qg Z2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAg ICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3Zl IG1lbXNldCBta2RpciBcCi0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiBy ZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNv Y2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwK LSAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3Ry dG91bCBzdHJ0b3VsbCB0enNldCBcCi0gICAgICAgICAgICAgICAgdW5hbWUgXAogCisjIENoZWNr cyBmb3IgaGVhZGVyIGZpbGVzLgorZm9yIGFjX2hlYWRlciBpbiB5YWpsL3lhamxfdmVyc2lvbi5o CiBkbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz X3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNf dmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgor ICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAieWFqbC95YWpsX3ZlcnNp b24uaCIgImFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAiJGFjX2luY2x1ZGVzX2Rl ZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiA9IHgi InllczsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19l Y2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKKyNkZWZpbmUgSEFWRV9ZQUpMX1lB SkxfVkVSU0lPTl9IIDEKIF9BQ0VPRgogCiBmaQorCiBkb25lCiAKIApkaWZmIC0tZ2l0IGEvdG9v bHMvY29uZmlndXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IDU3Yzg4N2QuLmRlYjg0 OGQgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUu YWMKQEAgLTE5LDkgKzE5LDYgQEAgcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQ UkVQRU5EX0xJQiwgXAogQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hl biBwb3NzaWJsZS5dKQogXSkKIAotQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCi1BQ19DQU5PTklD QUxfSE9TVAotCiAjIE00IE1hY3JvIGluY2x1ZGVzCiBtNF9pbmNsdWRlKFttNC9zYXZldmFyLm00 XSkKIG00X2luY2x1ZGUoW200L2ZlYXR1cmVzLm00XSkKQEAgLTc1LDkgKzcyLDcgQEAgQUNfQVJH X1ZBUihbQkNDXSwgW1BhdGggdG8gYmNjIHRvb2xdKQogQUNfQVJHX1ZBUihbSUFTTF0sIFtQYXRo IHRvIGlhc2wgdG9vbF0pCiAKICMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLUFDX1BST0dfU0VECiBB Q19QUk9HX0NDCi1BQ19QUk9HX0xOX1MKIEFDX1BST0dfTUFLRV9TRVQKIEFDX1BST0dfSU5TVEFM TAogQUNfUEFUSF9QUk9HKFtCSVNPTl0sIFtiaXNvbl0pCkBAIC0xMzcsNyArMTMyLDYgQEAgQUNf U1VCU1QobGliZXh0MmZzKQogQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1 ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQogQUNfU1VCU1QobGliZ2Ny eXB0KQogQVhfQ0hFQ0tfUFRIUkVBRAotQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1l XSkKIEFDX0NIRUNLX0xJQihbeWFqbF0sIFt5YWpsX2FsbG9jXSwgW10sCiAgICAgW0FDX01TR19F UlJPUihbQ291bGQgbm90IGZpbmQgeWFqbF0pXSkKIEFDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRl Q29weV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQpAQCAtMTQ1 LDU4ICsxMzksNiBAQCBBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGli aWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCiBBQ19TVUJTVChsaWJpY29udikKIAogIyBDaGVj a3MgZm9yIGhlYWRlciBmaWxlcy4KLUFDX0ZVTkNfQUxMT0NBCi1BQ19DSEVDS19IRUFERVJTKFsg XAotICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRs LmggbGltaXRzLmggbWFsbG9jLmggXAotICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9p bi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKLSAgICAgICAgICAgICAg ICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0u aCBcCi0gICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUu aCBzeXNsb2cuaCB0ZXJtaW9zLmggXAotICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFq bF92ZXJzaW9uLmggXAotICAgICAgICAgICAgICAgIF0pCi0KLSMgQ2hlY2tzIGZvciB0eXBlZGVm cywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLUFDX0hFQURFUl9T VERCT09MCi1BQ19UWVBFX1VJRF9UCi1BQ19DX0lOTElORQotQUNfVFlQRV9JTlQxNl9UCi1BQ19U WVBFX0lOVDMyX1QKLUFDX1RZUEVfSU5UNjRfVAotQUNfVFlQRV9JTlQ4X1QKLUFDX1RZUEVfTU9E RV9UCi1BQ19UWVBFX09GRl9UCi1BQ19UWVBFX1BJRF9UCi1BQ19DX1JFU1RSSUNUCi1BQ19UWVBF X1NJWkVfVAotQUNfVFlQRV9TU0laRV9UCi1BQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5z dF9ibGtzaXplXSkKLUFDX1NUUlVDVF9TVF9CTE9DS1MKLUFDX0NIRUNLX01FTUJFUlMoW3N0cnVj dCBzdGF0LnN0X3JkZXZdKQotQUNfVFlQRV9VSU5UMTZfVAotQUNfVFlQRV9VSU5UMzJfVAotQUNf VFlQRV9VSU5UNjRfVAotQUNfVFlQRV9VSU5UOF9UCi1BQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90 XSkKLQotIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgotQUNfRlVOQ19FUlJPUl9BVF9M SU5FCi1BQ19GVU5DX0ZPUksKLUFDX0ZVTkNfRlNFRUtPCi1BQ19GVU5DX0xTVEFUX0ZPTExPV1Nf U0xBU0hFRF9TWU1MSU5LCi1BQ19IRUFERVJfTUFKT1IKLUFDX0ZVTkNfTUFMTE9DCi1BQ19GVU5D X01LVElNRQotQUNfRlVOQ19NTUFQCi1BQ19GVU5DX1JFQUxMT0MKLUFDX0ZVTkNfU1RSTkxFTgot QUNfRlVOQ19TVFJUT0QKLUFDX0NIRUNLX0ZVTkNTKFsgXAotICAgICAgICAgICAgICAgIGFsYXJt IGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCi0g ICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNp emUgZ2V0dGltZW9mZGF5IFwKLSAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2Nh bHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAotICAgICAgICAgICAgICAgIG1r ZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52 IFwKLSAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJk dXAgc3RyZXJyb3Igc3RybmR1cCBcCi0gICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0 cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAotICAgICAgICAgICAg ICAgIHVuYW1lIFwKLSAgICAgICAgICAgICAgICBdKQorQUNfQ0hFQ0tfSEVBREVSUyhbeWFqbC95 YWpsX3ZlcnNpb24uaF0pCiAKIEFDX09VVFBVVCgpCi0tIAoxLjcuMi41CgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6h-0006a5-N0; Fri, 11 May 2012 17:58:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6e-0006Wa-UJ for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42653] by server-1.bemta-4.messagelabs.com id 83/B9-20925-B335DAF4; Fri, 11 May 2012 17:58:19 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25721 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435466" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hp-Vf; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eU-Sc; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:52 +0100 Message-ID: <1336759092-2432-8-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 07/27] libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Provide functions for sending and receiving fds. There used to be fd-sending functionality in libxl_qmp.c before 25298:84ae90427c54, which this implementation is partially derived from. Signed-off-by: Ian Jackson Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 11 ++++ tools/libxl/libxl_utils.c | 104 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+), 0 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 909e01f..e25569c 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1135,6 +1135,17 @@ _hidden void libxl__qmp_cleanup(libxl__gc *gc, uint32_t domid); _hidden int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, const libxl_domain_config *guest_config); +/* on failure, logs */ +int libxl__sendmsg_fds(libxl__gc *gc, int carrier, + const void *data, size_t datalen, + int nfds, const int fds[], const char *what); + +/* Insists on receiving exactly nfds and datalen. On failure, logs + * and leaves *fds untouched. */ +int libxl__recvmsg_fds(libxl__gc *gc, int carrier, + void *databuf, size_t datalen, + int nfds, int fds[], const char *what); + /* from libxl_json */ #include diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 1a4874c..19b4615 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -579,6 +579,110 @@ void libxl_cputopology_list_free(libxl_cputopology *list, int nr) free(list); } +int libxl__sendmsg_fds(libxl__gc *gc, int carrier, + const void *data, size_t datalen, + int nfds, const int fds[], const char *what) { + struct msghdr msg = { 0 }; + struct cmsghdr *cmsg; + size_t spaceneeded = nfds * sizeof(fds[0]); + char control[CMSG_SPACE(spaceneeded)]; + struct iovec iov; + int r; + + iov.iov_base = (void*)data; + iov.iov_len = datalen; + + /* compose the message */ + msg.msg_iov = &iov; + msg.msg_iovlen = 1; + msg.msg_control = control; + msg.msg_controllen = sizeof(control); + + /* attach open fd */ + cmsg = CMSG_FIRSTHDR(&msg); + cmsg->cmsg_level = SOL_SOCKET; + cmsg->cmsg_type = SCM_RIGHTS; + cmsg->cmsg_len = CMSG_LEN(spaceneeded); + memcpy(CMSG_DATA(cmsg), fds, spaceneeded); + + msg.msg_controllen = cmsg->cmsg_len; + + r = sendmsg(carrier, &msg, 0); + if (r < 0) { + LOGE(ERROR, "failed to send fd-carrying message (%s)", what); + return ERROR_FAIL; + } + + return 0; +} + +int libxl__recvmsg_fds(libxl__gc *gc, int carrier, + void *databuf, size_t datalen, + int nfds, int fds[], const char *what) +{ + struct msghdr msg = { 0 }; + struct cmsghdr *cmsg; + size_t spaceneeded = nfds * sizeof(fds[0]); + char control[CMSG_SPACE(spaceneeded)]; + struct iovec iov; + int r; + + iov.iov_base = databuf; + iov.iov_len = datalen; + + msg.msg_iov = &iov; + msg.msg_iovlen = 1; + msg.msg_control = control; + msg.msg_controllen = sizeof(control); + + for (;;) { + r = recvmsg(carrier, &msg, 0); + if (r < 0) { + if (errno == EINTR) continue; + if (errno == EWOULDBLOCK) return -1; + LOGE(ERROR,"recvmsg failed (%s)", what); + return ERROR_FAIL; + } + if (r == 0) { + LOG(ERROR,"recvmsg got EOF (%s)", what); + return ERROR_FAIL; + } + cmsg = CMSG_FIRSTHDR(&msg); + if (cmsg->cmsg_len <= CMSG_LEN(0)) { + LOG(ERROR,"recvmsg got no control msg" + " when expecting fds (%s)", what); + return ERROR_FAIL; + } + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + LOG(ERROR, "recvmsg got unexpected" + " cmsg_level %d (!=%d) or _type %d (!=%d) (%s)", + cmsg->cmsg_level, SOL_SOCKET, + cmsg->cmsg_type, SCM_RIGHTS, + what); + return ERROR_FAIL; + } + if (cmsg->cmsg_len != CMSG_LEN(spaceneeded) || + msg.msg_controllen != cmsg->cmsg_len) { + LOG(ERROR, "recvmsg got unexpected" + " number of fds or extra control data" + " (%ld bytes' worth, expected %ld) (%s)", + (long)CMSG_LEN(spaceneeded), (long)cmsg->cmsg_len, + what); + int i, fd; + unsigned char *p; + for (i=0, p=CMSG_DATA(cmsg); + CMSG_SPACE(i * sizeof(fds[0])); + i++, i+=sizeof(fd)) { + memcpy(&fd, p, sizeof(fd)); + close(fd); + } + return ERROR_FAIL; + } + memcpy(fds, CMSG_DATA(cmsg), spaceneeded); + return 0; + } +} + void libxl_dominfo_list_free(libxl_dominfo *list, int nr) { int i; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6k-0006d4-IS; Fri, 11 May 2012 17:58:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wa-DG for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:21 +0000 Received: from [85.158.143.35:42662] by server-1.bemta-4.messagelabs.com id 54/B9-20925-C335DAF4; Fri, 11 May 2012 17:58:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1336759099!10700869!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32033 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435472" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6a-0008I2-7k; Fri, 11 May 2012 17:58:16 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6a-0000fn-6F; Fri, 11 May 2012 18:58:16 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:56 +0100 Message-ID: <1336759092-2432-12-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Ian Jackson Subject: [Xen-devel] [PATCH 11/27] libxl: ao: Convert libxl_run_bootloader X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Convert libxl_run_bootloader to an ao_how-taking function. It's implemented in terms of libxl__bootloader_run, which can be used internally. The resulting code is pretty much a rewrite. Significant changes include: - We direct the bootloader's results to a file, not a pipe. This makes it simpler to deal with as we don't have to read it concurrently along with everything else. - We now issue a warning if we find unexpected statements in the bootloader results. - The arrangements for buffering of bootloader input and output are completely changed. Now we have a fixed limit of 64k on output, and 4k on input, and discard the oldest data when this overflows (which it shouldn't). There is no timeout any more. Signed-off-by: Ian Jackson Acked-by: Ian Campbell Changes since v6: * Use libxl__ev_child_inuse rather than testing pid directly. * Fix a code style error. * Properly initialise the sub-operations' aos in _init. * Bugfixes. --- tools/libxl/libxl.c | 4 + tools/libxl/libxl.h | 3 +- tools/libxl/libxl_bootloader.c | 713 +++++++++++++++++++++------------------- tools/libxl/libxl_create.c | 8 +- tools/libxl/libxl_internal.h | 34 ++ 5 files changed, 419 insertions(+), 343 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 939cc02..d5fb186 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1750,6 +1750,10 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk) * For other device types assume that the blktap2 process is * needed by the soon to be started domain and do nothing. */ + /* + * FIXME + * This appears to leak the disk in failure paths + */ return 0; } diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index fb90aed..3087146 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -495,7 +495,8 @@ int libxl_get_max_cpus(libxl_ctx *ctx); int libxl_run_bootloader(libxl_ctx *ctx, libxl_domain_build_info *info, libxl_device_disk *disk, - uint32_t domid); + uint32_t domid, + libxl_asyncop_how *ao_how); /* 0 means ERROR_ENOMEM, which we have logged */ diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c index b50944a..bdc4cb4 100644 --- a/tools/libxl/libxl_bootloader.c +++ b/tools/libxl/libxl_bootloader.c @@ -15,6 +15,7 @@ #include "libxl_osdeps.h" /* must come before any other headers */ #include +#include #ifdef INCLUDE_LIBUTIL_H #include INCLUDE_LIBUTIL_H @@ -22,67 +23,80 @@ #include "libxl_internal.h" -#define XENCONSOLED_BUF_SIZE 16 -#define BOOTLOADER_BUF_SIZE 4096 -#define BOOTLOADER_TIMEOUT 1 +#define BOOTLOADER_BUF_OUT 65536 +#define BOOTLOADER_BUF_IN 4096 -static char **make_bootloader_args(libxl__gc *gc, - libxl_domain_build_info *info, - uint32_t domid, - const char *fifo, char *disk) +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op); +static void bootloader_keystrokes_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_display_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval); +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status); + +/*----- bootloader arguments -----*/ + +static void bootloader_arg(libxl__bootloader_state *bl, const char *arg) +{ + assert(bl->nargs < bl->argsspace); + bl->args[bl->nargs++] = arg; +} + +static void make_bootloader_args(libxl__gc *gc, libxl__bootloader_state *bl) { - flexarray_t *args; - int nr = 0; + const libxl_domain_build_info *info = bl->info; - args = flexarray_make(1, 1); - if (!args) - return NULL; + bl->argsspace = 7 + libxl_string_list_length(&info->u.pv.bootloader_args); - flexarray_set(args, nr++, (char *)info->u.pv.bootloader); + GCNEW_ARRAY(bl->args, bl->argsspace); + +#define ARG(arg) bootloader_arg(bl, (arg)) + + ARG(info->u.pv.bootloader); if (info->u.pv.kernel.path) - flexarray_set(args, nr++, libxl__sprintf(gc, "--kernel=%s", - info->u.pv.kernel.path)); + ARG(libxl__sprintf(gc, "--kernel=%s", info->u.pv.kernel.path)); if (info->u.pv.ramdisk.path) - flexarray_set(args, nr++, libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path)); + ARG(libxl__sprintf(gc, "--ramdisk=%s", info->u.pv.ramdisk.path)); if (info->u.pv.cmdline && *info->u.pv.cmdline != '\0') - flexarray_set(args, nr++, libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline)); + ARG(libxl__sprintf(gc, "--args=%s", info->u.pv.cmdline)); - flexarray_set(args, nr++, libxl__sprintf(gc, "--output=%s", fifo)); - flexarray_set(args, nr++, "--output-format=simple0"); - flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/")); + ARG(libxl__sprintf(gc, "--output=%s", bl->outputpath)); + ARG("--output-format=simple0"); + ARG(libxl__sprintf(gc, "--output-directory=%s", bl->outputdir)); if (info->u.pv.bootloader_args) { char **p = info->u.pv.bootloader_args; while (*p) { - flexarray_set(args, nr++, *p); + ARG(*p); p++; } } - flexarray_set(args, nr++, disk); + ARG(bl->diskpath); - /* Sentinal for execv */ - flexarray_set(args, nr++, NULL); + /* Sentinel for execv */ + ARG(NULL); - return (char **) flexarray_contents(args); /* Frees args */ +#undef ARG } -static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_t slave_path_len) +/*----- synchronous subroutines -----*/ + +static int setup_xenconsoled_pty(libxl__egc *egc, libxl__bootloader_state *bl, + char *slave_path, size_t slave_path_len) { + STATE_AO_GC(bl->ao); struct termios termattr; - int ret; - - ret = openpty(master, slave, NULL, NULL, NULL); - if (ret < 0) - return -1; - - ret = ttyname_r(*slave, slave_path, slave_path_len); - if (ret == -1) { - close(*master); - close(*slave); - *master = *slave = -1; - return -1; + int r, rc; + int slave = libxl__carefd_fd(bl->ptys[1].slave); + int master = libxl__carefd_fd(bl->ptys[1].master); + + r = ttyname_r(slave, slave_path, slave_path_len); + if (r == -1) { + LOGE(ERROR,"ttyname_r failed"); + rc = ERROR_FAIL; + goto out; } /* @@ -95,310 +109,217 @@ static int open_xenconsoled_pty(int *master, int *slave, char *slave_path, size_ * semantics on Solaris, so don't try to set any attributes * for it. */ -#if !defined(__sun__) && !defined(__NetBSD__) - tcgetattr(*master, &termattr); + tcgetattr(master, &termattr); cfmakeraw(&termattr); - tcsetattr(*master, TCSANOW, &termattr); - - close(*slave); - *slave = -1; -#else - tcgetattr(*slave, &termattr); - cfmakeraw(&termattr); - tcsetattr(*slave, TCSANOW, &termattr); -#endif - - fcntl(*master, F_SETFL, O_NDELAY); - fcntl(*master, F_SETFD, FD_CLOEXEC); + tcsetattr(master, TCSANOW, &termattr); return 0; + + out: + return rc; } -static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args) -{ - struct termios termattr; - 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); - return -1; - } +static const char *bootloader_result_command(libxl__gc *gc, const char *buf, + const char *prefix, size_t prefixlen) { + if (strncmp(buf, prefix, prefixlen)) + return 0; - /* - * On Solaris, the master pty side does not have terminal semantics, - * so don't try to set any attributes, as it will fail. - */ -#if !defined(__sun__) - tcgetattr(*master, &termattr); - cfmakeraw(&termattr); - tcsetattr(*master, TCSANOW, &termattr); -#endif + const char *rhs = buf + prefixlen; + if (!CTYPE(isspace,*rhs)) + return 0; - fcntl(*master, F_SETFL, O_NDELAY); + while (CTYPE(isspace,*rhs)) + rhs++; - return pid; + LOG(DEBUG,"bootloader output contained %s %s", prefix, rhs); + + return rhs; } -/* - * filedescriptors: - * fifo_fd - bootstring output from the bootloader - * xenconsoled_fd - input/output from/to xenconsole - * bootloader_fd - input/output from/to pty that controls the bootloader - * The filedescriptors are NDELAY, so it's ok to try to read - * bigger chunks than may be available, to keep e.g. curses - * screen redraws in the bootloader efficient. xenconsoled_fd is the side that - * gets xenconsole input, which will be keystrokes, so a small number - * is sufficient. bootloader_fd is pygrub output, which will be curses screen - * updates, so a larger number (1024) is appropriate there. - * - * For writeable descriptors, only include them in the set for select - * if there is actual data to write, otherwise this would loop too fast, - * eating up CPU time. - */ -static char * bootloader_interact(libxl__gc *gc, int xenconsoled_fd, int bootloader_fd, int fifo_fd) +static int parse_bootloader_result(libxl__egc *egc, + libxl__bootloader_state *bl) { - int ret; - - size_t nr_out = 0, size_out = 0; - char *output = NULL; - struct timeval wait; - - /* input from xenconsole. read on xenconsoled_fd write to bootloader_fd */ - int xenconsoled_prod = 0, xenconsoled_cons = 0; - char xenconsoled_buf[XENCONSOLED_BUF_SIZE]; - /* output from bootloader. read on bootloader_fd write to xenconsoled_fd */ - int bootloader_prod = 0, bootloader_cons = 0; - char bootloader_buf[BOOTLOADER_BUF_SIZE]; - - while(1) { - fd_set wsel, rsel; - int nfds; - - /* Set timeout to 1s before starting to discard data */ - wait.tv_sec = BOOTLOADER_TIMEOUT; - wait.tv_usec = 0; - - /* Move buffers around to drop already consumed data */ - if (xenconsoled_cons > 0) { - xenconsoled_prod -= xenconsoled_cons; - memmove(xenconsoled_buf, &xenconsoled_buf[xenconsoled_cons], - xenconsoled_prod); - xenconsoled_cons = 0; - } - if (bootloader_cons > 0) { - bootloader_prod -= bootloader_cons; - memmove(bootloader_buf, &bootloader_buf[bootloader_cons], - bootloader_prod); - bootloader_cons = 0; - } - - FD_ZERO(&rsel); - FD_SET(fifo_fd, &rsel); - nfds = fifo_fd + 1; - if (xenconsoled_prod < XENCONSOLED_BUF_SIZE) { - /* The buffer is not full, try to read more data */ - FD_SET(xenconsoled_fd, &rsel); - nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds; - } - if (bootloader_prod < BOOTLOADER_BUF_SIZE) { - /* The buffer is not full, try to read more data */ - FD_SET(bootloader_fd, &rsel); - nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds; - } - - FD_ZERO(&wsel); - if (bootloader_prod > 0) { - /* The buffer has data to consume */ - FD_SET(xenconsoled_fd, &wsel); - nfds = xenconsoled_fd + 1 > nfds ? xenconsoled_fd + 1 : nfds; - } - if (xenconsoled_prod > 0) { - /* The buffer has data to consume */ - FD_SET(bootloader_fd, &wsel); - nfds = bootloader_fd + 1 > nfds ? bootloader_fd + 1 : nfds; - } - - if (xenconsoled_prod == XENCONSOLED_BUF_SIZE || - bootloader_prod == BOOTLOADER_BUF_SIZE) - ret = select(nfds, &rsel, &wsel, NULL, &wait); - else - ret = select(nfds, &rsel, &wsel, NULL, NULL); - if (ret < 0) { - if (errno == EINTR) - continue; - goto out_err; - } - - /* Input from xenconsole, read xenconsoled_fd, write bootloader_fd */ - if (ret == 0 && xenconsoled_prod == XENCONSOLED_BUF_SIZE) { - /* Drop the buffer */ - xenconsoled_prod = 0; - xenconsoled_cons = 0; - } else if (FD_ISSET(xenconsoled_fd, &rsel)) { - ret = read(xenconsoled_fd, &xenconsoled_buf[xenconsoled_prod], XENCONSOLED_BUF_SIZE - xenconsoled_prod); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - xenconsoled_prod += ret; - } - if (FD_ISSET(bootloader_fd, &wsel)) { - ret = write(bootloader_fd, &xenconsoled_buf[xenconsoled_cons], xenconsoled_prod - xenconsoled_cons); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - xenconsoled_cons += ret; - } + STATE_AO_GC(bl->ao); + char buf[PATH_MAX*2]; + FILE *f = 0; + int rc = ERROR_FAIL; + libxl_domain_build_info *info = bl->info; + + f = fopen(bl->outputpath, "r"); + if (!f) { + LOGE(ERROR,"open bootloader output file %s", bl->outputpath); + goto out; + } - /* Input from bootloader, read bootloader_fd, write xenconsoled_fd */ - if (ret == 0 && bootloader_prod == BOOTLOADER_BUF_SIZE) { - /* Drop the buffer */ - bootloader_prod = 0; - bootloader_cons = 0; - } else if (FD_ISSET(bootloader_fd, &rsel)) { - ret = read(bootloader_fd, &bootloader_buf[bootloader_prod], BOOTLOADER_BUF_SIZE - bootloader_prod); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - bootloader_prod += ret; + for (;;) { + /* Read a nul-terminated "line" and put the result in + * buf, and its length (not including the nul) in l */ + int l = 0, c; + while ((c = getc(f)) != EOF && c != '\0') { + if (l < sizeof(buf)-1) + buf[l] = c; + l++; } - if (FD_ISSET(xenconsoled_fd, &wsel)) { - ret = write(xenconsoled_fd, &bootloader_buf[bootloader_cons], bootloader_prod - bootloader_cons); - if (ret < 0 && errno != EIO && errno != EAGAIN) - goto out_err; - if (ret > 0) - bootloader_cons += ret; - } - - if (FD_ISSET(fifo_fd, &rsel)) { - if (size_out - nr_out < 256) { - char *temp; - size_t new_size = size_out == 0 ? 32 : size_out * 2; - - temp = realloc(output, new_size); - if (temp == NULL) - goto out_err; - output = temp; - memset(output + size_out, 0, new_size - size_out); - size_out = new_size; + if (c == EOF) { + if (ferror(f)) { + LOGE(ERROR,"read bootloader output file %s", bl->outputpath); + goto out; } - - ret = read(fifo_fd, output + nr_out, size_out - nr_out); - if (ret > 0) - nr_out += ret; - if (ret == 0) + if (!l) break; } - } + if (l >= sizeof(buf)) { + LOG(WARN,"bootloader output contained" + " overly long item `%.150s...'", buf); + continue; + } + buf[l] = 0; - libxl__ptr_add(gc, output); - return output; + const char *rhs; +#define COMMAND(s) ((rhs = bootloader_result_command(gc, buf, s, sizeof(s)-1))) -out_err: - free(output); - return NULL; -} - -static void parse_bootloader_result(libxl__gc *gc, - libxl_domain_build_info *info, - const char *o) -{ - while (*o != '\0') { - if (strncmp("kernel ", o, strlen("kernel ")) == 0) { + if (COMMAND("kernel")) { free(info->u.pv.kernel.path); - info->u.pv.kernel.path = strdup(o + strlen("kernel ")); + info->u.pv.kernel.path = libxl__strdup(NULL, rhs); libxl__file_reference_map(&info->u.pv.kernel); unlink(info->u.pv.kernel.path); - } else if (strncmp("ramdisk ", o, strlen("ramdisk ")) == 0) { + } else if (COMMAND("ramdisk")) { free(info->u.pv.ramdisk.path); - info->u.pv.ramdisk.path = strdup(o + strlen("ramdisk ")); + info->u.pv.ramdisk.path = libxl__strdup(NULL, rhs); libxl__file_reference_map(&info->u.pv.ramdisk); unlink(info->u.pv.ramdisk.path); - } else if (strncmp("args ", o, strlen("args ")) == 0) { + } else if (COMMAND("args")) { free(info->u.pv.cmdline); - info->u.pv.cmdline = strdup(o + strlen("args ")); + info->u.pv.cmdline = libxl__strdup(NULL, rhs); + } else if (l) { + LOG(WARN, "unexpected output from bootloader: `%s'", buf); } - - o = o + strlen(o) + 1; } + rc = 0; + + out: + if (f) fclose(f); + return rc; } -int libxl_run_bootloader(libxl_ctx *ctx, - libxl_domain_build_info *info, - libxl_device_disk *disk, - uint32_t domid) + +/*----- init and cleanup -----*/ + +void libxl__bootloader_init(libxl__bootloader_state *bl) +{ + assert(bl->ao); + bl->diskpath = NULL; + bl->openpty.ao = bl->ao; + bl->ptys[0].master = bl->ptys[0].slave = 0; + bl->ptys[1].master = bl->ptys[1].slave = 0; + libxl__ev_child_init(&bl->child); + bl->keystrokes.ao = bl->ao; libxl__datacopier_init(&bl->keystrokes); + bl->display.ao = bl->ao; libxl__datacopier_init(&bl->display); +} + +static void bootloader_cleanup(libxl__egc *egc, libxl__bootloader_state *bl) { - GC_INIT(ctx); - int ret, rc = 0; - char *fifo = NULL; - char *diskpath = NULL; - char **args = NULL; + STATE_AO_GC(bl->ao); + int i; - char tempdir_template[] = "/var/run/libxl/bl.XXXXXX"; - char *tempdir; + if (bl->outputpath) libxl__remove_file(gc, bl->outputpath); + if (bl->outputdir) libxl__remove_directory(gc, bl->outputdir); - char *dom_console_xs_path; - char dom_console_slave_tty_path[PATH_MAX]; + if (bl->diskpath) { + libxl_device_disk_local_detach(CTX, bl->disk); + free(bl->diskpath); + bl->diskpath = 0; + } + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + for (i=0; i<2; i++) { + libxl__carefd_close(bl->ptys[i].master); + libxl__carefd_close(bl->ptys[i].slave); + } +} + +static void bootloader_setpaths(libxl__gc *gc, libxl__bootloader_state *bl) +{ + uint32_t domid = bl->domid; + bl->outputdir = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".d", domid); + bl->outputpath = GCSPRINTF(XEN_RUN_DIR "/bootloader.%"PRIu32".out", domid); +} - int xenconsoled_fd = -1, xenconsoled_slave = -1; - int bootloader_fd = -1, fifo_fd = -1; +static void bootloader_callback(libxl__egc *egc, libxl__bootloader_state *bl, + int rc) +{ + bootloader_cleanup(egc, bl); + bl->callback(egc, bl, rc); +} - int blrc; - pid_t pid; - char *blout; +/*----- main flow of control -----*/ - struct stat st_buf; +void libxl__bootloader_run(libxl__egc *egc, libxl__bootloader_state *bl) +{ + STATE_AO_GC(bl->ao); + libxl_domain_build_info *info = bl->info; + int rc, r; - rc = libxl__domain_build_info_setdefault(gc, info); - if (rc) goto out; + libxl__bootloader_init(bl); - if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) - goto out; + if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader) { + rc = 0; + goto out_ok; + } - rc = libxl__domain_build_info_setdefault(gc, info); - if (rc) goto out; + bootloader_setpaths(gc, bl); - rc = ERROR_INVAL; - if (!disk) + for (;;) { + r = mkdir(bl->outputdir, 0600); + if (!r) break; + if (errno == EINTR) continue; + if (errno == EEXIST) break; + LOGE(ERROR, "failed to create bootloader dir %s", bl->outputdir); + rc = ERROR_FAIL; goto out; + } - rc = ERROR_FAIL; - ret = mkdir("/var/run/libxl/", S_IRWXU); - if (ret < 0 && errno != EEXIST) + for (;;) { + r = open(bl->outputpath, O_WRONLY|O_CREAT|O_TRUNC, 0600); + if (r>=0) { close(r); break; } + if (errno == EINTR) continue; + LOGE(ERROR, "failed to precreate bootloader output %s", bl->outputpath); + rc = ERROR_FAIL; goto out; + } - ret = stat("/var/run/libxl/", &st_buf); - if (ret < 0) + bl->diskpath = libxl_device_disk_local_attach(CTX, bl->disk); + if (!bl->diskpath) { + rc = ERROR_FAIL; goto out; + } - if (!S_ISDIR(st_buf.st_mode)) - goto out; + make_bootloader_args(gc, bl); - tempdir = mkdtemp(tempdir_template); - if (tempdir == NULL) - goto out; + bl->openpty.ao = ao; + bl->openpty.callback = bootloader_gotptys; + bl->openpty.count = 2; + bl->openpty.results = bl->ptys; + rc = libxl__openptys(&bl->openpty, 0,0); + if (rc) goto out; - ret = asprintf(&fifo, "%s/fifo", tempdir); - if (ret < 0) { - fifo = NULL; - goto out_close; - } + return; - ret = mkfifo(fifo, 0600); - if (ret < 0) { - goto out_close; - } + out: + assert(rc); + out_ok: + bootloader_callback(egc, bl, rc); +} - diskpath = libxl_device_disk_local_attach(ctx, disk); - if (!diskpath) { - goto out_close; - } +static void bootloader_gotptys(libxl__egc *egc, libxl__openpty_state *op) +{ + libxl__bootloader_state *bl = CONTAINER_OF(op, *bl, openpty); + STATE_AO_GC(bl->ao); + int rc, r; - args = make_bootloader_args(gc, info, domid, fifo, diskpath); - if (args == NULL) { - rc = ERROR_NOMEM; - goto out_close; + if (bl->openpty.rc) { + rc = bl->openpty.rc; + goto out; } /* @@ -411,76 +332,188 @@ int libxl_run_bootloader(libxl_ctx *ctx, * where we copy characters between the two master fds, as well as * listening on the bootloader's fifo for the results. */ - ret = open_xenconsoled_pty(&xenconsoled_fd, &xenconsoled_slave, + + char *dom_console_xs_path; + char dom_console_slave_tty_path[PATH_MAX]; + rc = setup_xenconsoled_pty(egc, bl, &dom_console_slave_tty_path[0], sizeof(dom_console_slave_tty_path)); - if (ret < 0) { - goto out_close; + if (rc) goto out; + + char *dompath = libxl__xs_get_dompath(gc, bl->domid); + if (!dompath) { rc = ERROR_FAIL; goto out; } + + dom_console_xs_path = GCSPRINTF("%s/console/tty", dompath); + + rc = libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", + dom_console_slave_tty_path); + if (rc) { + LOGE(ERROR,"xs write console path %s := %s failed", + dom_console_xs_path, dom_console_slave_tty_path); + rc = ERROR_FAIL; + goto out; } - dom_console_xs_path = libxl__sprintf(gc, "%s/console/tty", libxl__xs_get_dompath(gc, domid)); - libxl__xs_write(gc, XBT_NULL, dom_console_xs_path, "%s", dom_console_slave_tty_path); + int bootloader_master = libxl__carefd_fd(bl->ptys[0].master); + int xenconsole_master = libxl__carefd_fd(bl->ptys[1].master); + + libxl_fd_set_nonblock(CTX, bootloader_master, 1); + libxl_fd_set_nonblock(CTX, xenconsole_master, 1); + + bl->keystrokes.writefd = bl->display.readfd = bootloader_master; + bl->keystrokes.writewhat = bl->display.readwhat = "bootloader pty"; + + bl->keystrokes.readfd = bl->display.writefd = xenconsole_master; + bl->keystrokes.readwhat = bl->display.writewhat = "xenconsole client pty"; + + bl->keystrokes.ao = ao; + bl->keystrokes.maxsz = BOOTLOADER_BUF_OUT; + bl->keystrokes.copywhat = + GCSPRINTF("bootloader input for domain %"PRIu32, bl->domid); + bl->keystrokes.callback = bootloader_keystrokes_copyfail; + rc = libxl__datacopier_start(&bl->keystrokes); + if (rc) goto out; + + bl->display.ao = ao; + bl->display.maxsz = BOOTLOADER_BUF_IN; + bl->display.copywhat = + GCSPRINTF("bootloader output for domain %"PRIu32, bl->domid); + bl->display.callback = bootloader_display_copyfail; + rc = libxl__datacopier_start(&bl->display); + if (rc) goto out; + + LOG(DEBUG, "executing bootloader: %s", bl->args[0]); + for (const char **blarg = bl->args; + *blarg; + blarg++) + LOG(DEBUG, " bootloader arg: %s", *blarg); + + struct termios termattr; - pid = fork_exec_bootloader(&bootloader_fd, info->u.pv.bootloader, args); - if (pid < 0) { - goto out_close; + pid_t pid = libxl__ev_child_fork(gc, &bl->child, bootloader_finished); + if (pid == -1) { + rc = ERROR_FAIL; + goto out; } - while (1) { - if (waitpid(pid, &blrc, WNOHANG) == pid) - goto out_close; + if (!pid) { + /* child */ + r = login_tty(libxl__carefd_fd(bl->ptys[0].slave)); + if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); } + setenv("TERM", "vt100", 1); + libxl__exec(-1, -1, -1, bl->args[0], (char**)bl->args); + exit(-1); + } - fifo_fd = open(fifo, O_RDONLY); - if (fifo_fd > -1) - break; + /* parent */ - if (errno == EINTR) - continue; + /* + * On Solaris, the master pty side does not have terminal semantics, + * so don't try to set any attributes, as it will fail. + */ +#if !defined(__sun__) + tcgetattr(bootloader_master, &termattr); + cfmakeraw(&termattr); + tcsetattr(bootloader_master, TCSANOW, &termattr); +#endif + + return; + + out: + bootloader_callback(egc, bl, rc); +} - goto out_close; +/* perhaps one of these will be called, but perhaps not */ +static void bootloader_copyfail(libxl__egc *egc, const char *which, + libxl__bootloader_state *bl, int onwrite, int errnoval) +{ + STATE_AO_GC(bl->ao); + int r; + + if (!onwrite && !errnoval) + LOG(ERROR, "unexpected eof copying %s", which); + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + if (libxl__ev_child_inuse(&bl->child)) { + r = kill(bl->child.pid, SIGTERM); + if (r) LOGE(WARN, "after failure, failed to kill bootloader [%lu]", + (unsigned long)bl->child.pid); } + bl->rc = ERROR_FAIL; +} +static void bootloader_keystrokes_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes); + bootloader_copyfail(egc, "bootloader input", bl, onwrite, errnoval); +} +static void bootloader_display_copyfail(libxl__egc *egc, + libxl__datacopier_state *dc, int onwrite, int errnoval) +{ + libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, display); + bootloader_copyfail(egc, "bootloader output", bl, onwrite, errnoval); +} - fcntl(fifo_fd, F_SETFL, O_NDELAY); +static void bootloader_finished(libxl__egc *egc, libxl__ev_child *child, + pid_t pid, int status) +{ + libxl__bootloader_state *bl = CONTAINER_OF(child, *bl, child); + STATE_AO_GC(bl->ao); + int rc; - blout = bootloader_interact(gc, xenconsoled_fd, bootloader_fd, fifo_fd); - if (blout == NULL) { - goto out_close; + libxl__datacopier_kill(&bl->keystrokes); + libxl__datacopier_kill(&bl->display); + + if (status) { + libxl_report_child_exitstatus(CTX, XTL_ERROR, "bootloader", + pid, status); + rc = ERROR_FAIL; + goto out; + } else { + LOG(DEBUG, "bootloader completed"); } - pid = waitpid(pid, &blrc, 0); - if (pid == -1 || (pid > 0 && WIFEXITED(blrc) && WEXITSTATUS(blrc) != 0)) { - goto out_close; + if (bl->rc) { + /* datacopier went wrong */ + rc = bl->rc; + goto out; } - parse_bootloader_result(gc, info, blout); + rc = parse_bootloader_result(egc, bl); + if (rc) goto out; rc = 0; -out_close: - if (diskpath) { - libxl_device_disk_local_detach(ctx, disk); - free(diskpath); - } - if (fifo_fd > -1) - close(fifo_fd); - if (bootloader_fd > -1) - close(bootloader_fd); - if (xenconsoled_fd > -1) - close(xenconsoled_fd); - if (xenconsoled_slave > -1) - close(xenconsoled_slave); - - if (fifo) { - unlink(fifo); - free(fifo); - } + LOG(DEBUG, "bootloader execution successful"); - rmdir(tempdir); + out: + bootloader_callback(egc, bl, rc); +} - free(args); +/*----- entrypoint for external callers -----*/ -out: - GC_FREE; - return rc; +static void run_bootloader_done(libxl__egc *egc, + libxl__bootloader_state *st, int rc) +{ + libxl__ao_complete(egc, st->ao, rc); +} + +int libxl_run_bootloader(libxl_ctx *ctx, + libxl_domain_build_info *info, + libxl_device_disk *disk, + uint32_t domid, + libxl_asyncop_how *ao_how) +{ + AO_CREATE(ctx,domid,ao_how); + libxl__bootloader_state *bl; + + GCNEW(bl); + bl->ao = ao; + bl->callback = run_bootloader_done; + bl->info = info; + bl->disk = disk; + bl->domid = domid; + libxl__bootloader_run(egc, bl); + return AO_INPROGRESS; } /* diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index d501102..f7732aa 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -593,8 +593,12 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config, if (ret) goto error_out; } - if ( restore_fd < 0 ) { - ret = libxl_run_bootloader(ctx, &d_config->b_info, d_config->num_disks > 0 ? &d_config->disks[0] : NULL, domid); + libxl_device_disk *bootdisk = + d_config->num_disks > 0 ? &d_config->disks[0] : NULL; + + if (restore_fd < 0 && bootdisk) { + ret = libxl_run_bootloader(ctx, &d_config->b_info, bootdisk, domid, + 0 /* fixme-ao */); if (ret) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "failed to run bootloader: %d", ret); diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 3744a28..e8502c6 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -42,6 +42,7 @@ #include #include #include +#include #include #include @@ -440,6 +441,7 @@ _hidden int libxl__remove_file(libxl__gc *gc, const char *path); _hidden int libxl__remove_directory(libxl__gc *gc, const char *path); _hidden int libxl__remove_file_or_directory(libxl__gc *gc, const char *path); + _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length); _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t, @@ -1549,6 +1551,38 @@ int libxl__openptys(libxl__openpty_state *op, const struct winsize *winp); +/*----- bootloader -----*/ + +typedef struct libxl__bootloader_state libxl__bootloader_state; +typedef void libxl__run_bootloader_callback(libxl__egc*, + libxl__bootloader_state*, int rc); + +struct libxl__bootloader_state { + /* caller must fill these in, and they must all remain valid */ + libxl__ao *ao; + libxl__run_bootloader_callback *callback; + libxl_domain_build_info *info; /* u.pv.{kernel,ramdisk,cmdline} updated */ + libxl_device_disk *disk; + uint32_t domid; + /* private to libxl__run_bootloader */ + char *outputpath, *outputdir; + char *diskpath; /* not from gc, represents actually attached disk */ + libxl__openpty_state openpty; + libxl__openpty_result ptys[2]; /* [0] is for bootloader */ + libxl__ev_child child; + int nargs, argsspace; + const char **args; + libxl__datacopier_state keystrokes, display; + int rc; +}; + +_hidden void libxl__bootloader_init(libxl__bootloader_state *bl); + +/* Will definitely call st->callback, perhaps reentrantly. + * If callback is passed rc==0, will have updated st->info appropriately */ +_hidden void libxl__bootloader_run(libxl__egc*, libxl__bootloader_state *st); + + /* * Convenience macros. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 17:58:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6p-0006l8-De; Fri, 11 May 2012 17:58:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSu6f-0006Wq-Sr for xen-devel@lists.xen.org; Fri, 11 May 2012 17:58:22 +0000 Received: from [85.158.143.35:57433] by server-3.bemta-4.messagelabs.com id 6E/F4-05853-D335DAF4; Fri, 11 May 2012 17:58:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1336759097!16331154!5 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25755 invoked from network); 11 May 2012 17:58:19 -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; 11 May 2012 17:58:19 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12435464" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 17:58: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, 11 May 2012 18:58:16 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSu6Z-0008Hf-OW; Fri, 11 May 2012 17:58:15 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1SSu6Z-0000eJ-M1; Fri, 11 May 2012 18:58:15 +0100 From: Ian Jackson To: Date: Fri, 11 May 2012 18:57:49 +0100 Message-ID: <1336759092-2432-5-git-send-email-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> References: <1336759092-2432-1-git-send-email-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Cc: Roger Pau Monne , Ian Jackson Subject: [Xen-devel] =?utf-8?q?=5BPATCH_04/27=5D_autoconf=3A_trim_the_conf?= =?utf-8?q?igure_script=3B_use_autoheader?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org UmVtb3ZlIGEgbG90IG9mIHVubmVjZXNzYXJ5IHRlc3RzLiAgU3BlY2lmaWNhbGx5LCB3ZSBubyBs b25nZXIgdGVzdApmb3Igc3RhbmRhcmQgUE9TSVggZmFjaWxpdGllcyB3aGljaCB3ZSBleHBlY3Qg dG8gYmUgcHJvdmlkZWQKZXZlcnl3aGVyZSBhbmQgd2hpY2ggd2UgZG9uJ3QgaW4gYW55IGNhc2Ug aGF2ZSBhbnkgYWx0ZXJuYXRpdmUgZm9yLgoKU3dpdGNoIHRvIGdlbmVyYXRpbmcgY29uZmlnLmgu aW4gd2l0aCBhdXRvaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNr c29uQGV1LmNpdHJpeC5jb20+CkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj aXRyaXguY29tPgpDYzogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4K CkNoYW5nZXMgc2luY2Ugdjc6CiAqIFJlbW92ZWQgQVhfQ0hFQ0tfUFRZRlVOQ1MgKHNudWNrIGlu IGZyb20gcHJldmlvdXMgcGF0Y2gpCi0tLQogYXV0b2dlbi5zaCAgICAgICAgIHwgICAgMSArCiB0 b29scy9jb25maWcuaC5pbiAgfCAgIDczICstCiB0b29scy9jb25maWd1cmUgICAgfCA4ODI1ICsr KysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHRvb2xz L2NvbmZpZ3VyZS5hYyB8ICAgNjAgKy0KIDQgZmlsZXMgY2hhbmdlZCwgMjk4MSBpbnNlcnRpb25z KCspLCA1OTc4IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2F1dG9nZW4uc2ggYi9hdXRvZ2Vu LnNoCmluZGV4IGMyODhiNzEuLjU4YTcxY2UgMTAwNzU1Ci0tLSBhL2F1dG9nZW4uc2gKKysrIGIv YXV0b2dlbi5zaApAQCAtMSwzICsxLDQgQEAKICMhL2Jpbi9zaCAtZQogY2QgdG9vbHMKIGF1dG9j b25mCithdXRvaGVhZGVyCmRpZmYgLS1naXQgYS90b29scy9jb25maWcuaC5pbiBiL3Rvb2xzL2Nv bmZpZy5oLmluCmluZGV4IGY4Zjk2ZGMuLjE3Yzg5MTMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZp Zy5oLmluCisrKyBiL3Rvb2xzL2NvbmZpZy5oLmluCkBAIC0xLDE5ICsxLDY0IEBACi0vKgotICog Q29weXJpZ2h0IChDKSAyMDEyCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7 IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKLSAqIGl0IHVuZGVyIHRoZSB0 ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZAotICogYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgdmVyc2lvbiAyLjEgb25seS4g d2l0aCB0aGUgc3BlY2lhbAotICogZXhjZXB0aW9uIG9uIGxpbmtpbmcgZGVzY3JpYmVkIGluIGZp bGUgTElDRU5TRS4KLSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhv cGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKLSAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsg d2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCi0gKiBNRVJDSEFOVEFCSUxJVFkg b3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCi0gKiBHTlUgTGVz c2VyIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KLSAqLworLyogY29u ZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMgYnkgYXV0b2hlYWRlci4gICov CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8aW50dHlwZXMuaD4gaGVhZGVyIGZp bGUuICovCisjdW5kZWYgSEFWRV9JTlRUWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo YXZlIHRoZSBgY3J5cHRvJyBsaWJyYXJ5ICgtbGNyeXB0bykuICovCisjdW5kZWYgSEFWRV9MSUJD UllQVE8KKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB5YWpsJyBsaWJyYXJ5ICgt bHlhamwpLiAqLworI3VuZGVmIEhBVkVfTElCWUFKTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Ug aGF2ZSB0aGUgYHonIGxpYnJhcnkgKC1seikuICovCisjdW5kZWYgSEFWRV9MSUJaCisKKy8qIERl ZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8bWVtb3J5Lmg+IGhlYWRlciBmaWxlLiAqLworI3Vu ZGVmIEhBVkVfTUVNT1JZX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdGRp bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJTlRfSAorCisvKiBEZWZpbmUg dG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBI QVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RyaW5ncy5o PiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NUUklOR1NfSAorCisvKiBEZWZpbmUgdG8g MSBpZiB5b3UgaGF2ZSB0aGUgPHN0cmluZy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZF X1NUUklOR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL3N0YXQuaD4g aGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfU1RBVF9ICisKKy8qIERlZmluZSB0byAx IGlmIHlvdSBoYXZlIHRoZSA8c3lzL3R5cGVzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhB VkVfU1lTX1RZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDx1bmlzdGQu aD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklTVERfSAogCiAvKiBEZWZpbmUgdG8g MSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9uLmg+IGhlYWRlciBmaWxlLiAqLwog I3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAogCi0vKiBEZWZpbmUgY3Vyc2VzIGhlYWRl ciB0byBpbmNsdWRlLiAqLworLyogRGVmaW5lIGN1cnNlcyBoZWFkZXIgdG8gdXNlICovCiAjdW5k ZWYgSU5DTFVERV9DVVJTRVNfSAorCisvKiBEZWZpbmUgdG8gdGhlIGFkZHJlc3Mgd2hlcmUgYnVn IHJlcG9ydHMgZm9yIHRoaXMgcGFja2FnZSBzaG91bGQgYmUgc2VudC4gKi8KKyN1bmRlZiBQQUNL QUdFX0JVR1JFUE9SVAorCisvKiBEZWZpbmUgdG8gdGhlIGZ1bGwgbmFtZSBvZiB0aGlzIHBhY2th Z2UuICovCisjdW5kZWYgUEFDS0FHRV9OQU1FCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1l IGFuZCB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1NUUklORwor CisvKiBEZWZpbmUgdG8gdGhlIG9uZSBzeW1ib2wgc2hvcnQgbmFtZSBvZiB0aGlzIHBhY2thZ2Uu ICovCisjdW5kZWYgUEFDS0FHRV9UQVJOQU1FCisKKy8qIERlZmluZSB0byB0aGUgaG9tZSBwYWdl IGZvciB0aGlzIHBhY2thZ2UuICovCisjdW5kZWYgUEFDS0FHRV9VUkwKKworLyogRGVmaW5lIHRv IHRoZSB2ZXJzaW9uIG9mIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1ZFUlNJT04K KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIEFOU0kgQyBoZWFkZXIgZmlsZXMuICov CisjdW5kZWYgU1REQ19IRUFERVJTCmRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29s cy9jb25maWd1cmUKaW5kZXggODk3ZTA2MS4uZDg5MThmZSAxMDA3NTUKLS0tIGEvdG9vbHMvY29u ZmlndXJlCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQpAQCAtNTk1LDEyICs1OTUsOCBAQCBhY19pbmNs dWRlc19kZWZhdWx0PSJcCiAjIGluY2x1ZGUgPHVuaXN0ZC5oPgogI2VuZGlmIgogCi1hY19oZWFk ZXJfbGlzdD0KLWFjX2Z1bmNfbGlzdD0KIGFjX3N1YnN0X3ZhcnM9J0xUTElCT0JKUwotUE9XX0xJ QgogTElCT0JKUwotQUxMT0NBCiBsaWJpY29udgogUFRIUkVBRF9MSUJTCiBQVEhSRUFEX0xERkxB R1MKQEAgLTYxNiw2ICs2MTIsOSBAQCBQS0dfQ09ORklHX0xJQkRJUgogUEtHX0NPTkZJR19QQVRI CiBQS0dfQ09ORklHCiBDVVJTRVNfTElCUworRUdSRVAKK0dSRVAKK0NQUAogcHljb25maWcKIFBZ VEhPTlBBVEgKIE9DQU1MQlVJTEQKQEAgLTYzNSw4ICs2MzQsMTMgQEAgSU5TVEFMTF9EQVRBCiBJ TlNUQUxMX1NDUklQVAogSU5TVEFMTF9QUk9HUkFNCiBTRVRfTUFLRQotTE5fUwotU0VECitPQkpF WFQKK0VYRUVYVAorYWNfY3RfQ0MKK0NQUEZMQUdTCitMREZMQUdTCitDRkxBR1MKK0NDCiBJQVNM CiBCQ0MKIExEODYKQEAgLTY2NSwyNCArNjY5LDYgQEAgeGVuYXBpCiB2dHBtCiBtb25pdG9ycwog Z2l0aHR0cAotaG9zdF9vcwotaG9zdF92ZW5kb3IKLWhvc3RfY3B1Ci1ob3N0Ci1idWlsZF9vcwot YnVpbGRfdmVuZG9yCi1idWlsZF9jcHUKLWJ1aWxkCi1FR1JFUAotR1JFUAotQ1BQCi1PQkpFWFQK LUVYRUVYVAotYWNfY3RfQ0MKLUNQUEZMQUdTCi1MREZMQUdTCi1DRkxBR1MKLUNDCiB0YXJnZXRf YWxpYXMKIGhvc3RfYWxpYXMKIGJ1aWxkX2FsaWFzCkBAIC03NDAsMTIgKzcyNiw2IEBAIGVuYWJs ZV9kZWJ1ZwogICAgICAgYWNfcHJlY2lvdXNfdmFycz0nYnVpbGRfYWxpYXMKIGhvc3RfYWxpYXMK IHRhcmdldF9hbGlhcwotQ0MKLUNGTEFHUwotTERGTEFHUwotTElCUwotQ1BQRkxBR1MKLUNQUAog UFJFUEVORF9JTkNMVURFUwogUFJFUEVORF9MSUIKIEFQUEVORF9JTkNMVURFUwpAQCAtNzYyLDYg Kzc0MiwxMiBAQCBBUzg2CiBMRDg2CiBCQ0MKIElBU0wKK0NDCitDRkxBR1MKK0xERkxBR1MKK0xJ QlMKK0NQUEZMQUdTCitDUFAKIFBLR19DT05GSUcKIFBLR19DT05GSUdfUEFUSAogUEtHX0NPTkZJ R19MSUJESVIKQEAgLTEzNjUsMTAgKzEzNTEsNiBAQCBGaW5lIHR1bmluZyBvZiB0aGUgaW5zdGFs bGF0aW9uIGRpcmVjdG9yaWVzOgogX0FDRU9GCiAKICAgY2F0IDw8XF9BQ0VPRgotCi1TeXN0ZW0g dHlwZXM6Ci0gIC0tYnVpbGQ9QlVJTEQgICAgIGNvbmZpZ3VyZSBmb3IgYnVpbGRpbmcgb24gQlVJ TEQgW2d1ZXNzZWRdCi0gIC0taG9zdD1IT1NUICAgICAgIGNyb3NzLWNvbXBpbGUgdG8gYnVpbGQg cHJvZ3JhbXMgdG8gcnVuIG9uIEhPU1QgW0JVSUxEXQogX0FDRU9GCiBmaQogCkBAIC0xMzk5LDE0 ICsxMzgxLDYgQEAgT3B0aW9uYWwgRmVhdHVyZXM6CiAgIC0tZGlzYWJsZS1kZWJ1ZyAgICAgICAg IERpc2FibGUgZGVidWcgYnVpbGQgb2YgdG9vbHMgKGRlZmF1bHQgaXMgRU5BQkxFRCkKIAogU29t ZSBpbmZsdWVudGlhbCBlbnZpcm9ubWVudCB2YXJpYWJsZXM6Ci0gIENDICAgICAgICAgIEMgY29t cGlsZXIgY29tbWFuZAotICBDRkxBR1MgICAgICBDIGNvbXBpbGVyIGZsYWdzCi0gIExERkxBR1Mg ICAgIGxpbmtlciBmbGFncywgZS5nLiAtTDxsaWIgZGlyPiBpZiB5b3UgaGF2ZSBsaWJyYXJpZXMg aW4gYQotICAgICAgICAgICAgICBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGxpYiBkaXI+Ci0gIExJ QlMgICAgICAgIGxpYnJhcmllcyB0byBwYXNzIHRvIHRoZSBsaW5rZXIsIGUuZy4gLWw8bGlicmFy eT4KLSAgQ1BQRkxBR1MgICAgKE9iamVjdGl2ZSkgQy9DKysgcHJlcHJvY2Vzc29yIGZsYWdzLCBl LmcuIC1JPGluY2x1ZGUgZGlyPiBpZgotICAgICAgICAgICAgICB5b3UgaGF2ZSBoZWFkZXJzIGlu IGEgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxpbmNsdWRlIGRpcj4KLSAgQ1BQICAgICAgICAgQyBw cmVwcm9jZXNzb3IKICAgUFJFUEVORF9JTkNMVURFUwogICAgICAgICAgICAgICBMaXN0IG9mIGlu Y2x1ZGUgZm9sZGVycyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSkKICAgUFJFUEVO RF9MSUIgTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRo b3V0IC1MKQpAQCAtMTQyNSw2ICsxMzk5LDE0IEBAIFNvbWUgaW5mbHVlbnRpYWwgZW52aXJvbm1l bnQgdmFyaWFibGVzOgogICBMRDg2ICAgICAgICBQYXRoIHRvIGxkODYgdG9vbAogICBCQ0MgICAg ICAgICBQYXRoIHRvIGJjYyB0b29sCiAgIElBU0wgICAgICAgIFBhdGggdG8gaWFzbCB0b29sCisg IENDICAgICAgICAgIEMgY29tcGlsZXIgY29tbWFuZAorICBDRkxBR1MgICAgICBDIGNvbXBpbGVy IGZsYWdzCisgIExERkxBR1MgICAgIGxpbmtlciBmbGFncywgZS5nLiAtTDxsaWIgZGlyPiBpZiB5 b3UgaGF2ZSBsaWJyYXJpZXMgaW4gYQorICAgICAgICAgICAgICBub25zdGFuZGFyZCBkaXJlY3Rv cnkgPGxpYiBkaXI+CisgIExJQlMgICAgICAgIGxpYnJhcmllcyB0byBwYXNzIHRvIHRoZSBsaW5r ZXIsIGUuZy4gLWw8bGlicmFyeT4KKyAgQ1BQRkxBR1MgICAgKE9iamVjdGl2ZSkgQy9DKysgcHJl cHJvY2Vzc29yIGZsYWdzLCBlLmcuIC1JPGluY2x1ZGUgZGlyPiBpZgorICAgICAgICAgICAgICB5 b3UgaGF2ZSBoZWFkZXJzIGluIGEgbm9uc3RhbmRhcmQgZGlyZWN0b3J5IDxpbmNsdWRlIGRpcj4K KyAgQ1BQICAgICAgICAgQyBwcmVwcm9jZXNzb3IKICAgUEtHX0NPTkZJRyAgcGF0aCB0byBwa2ct Y29uZmlnIHV0aWxpdHkKICAgUEtHX0NPTkZJR19QQVRICiAgICAgICAgICAgICAgIGRpcmVjdG9y aWVzIHRvIGFkZCB0byBwa2ctY29uZmlnJ3Mgc2VhcmNoIHBhdGgKQEAgLTE3OTcsMzExICsxNzc5 LDYgQEAgZmkKICAgYXNfZm5fc2V0X3N0YXR1cyAkYWNfcmV0dmFsCiAKIH0gIyBhY19mbl9jX3Ry eV9saW5rCi0KLSMgYWNfZm5fY19jaGVja19mdW5jIExJTkVOTyBGVU5DIFZBUgotIyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIFRlc3RzIHdoZXRoZXIgRlVOQyBleGlzdHMs IHNldHRpbmcgdGhlIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseQotYWNfZm5fY19jaGVj a19mdW5jICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3Rh Y2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQotJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwi IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNh dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm cy5oLiAgKi8KLS8qIERlZmluZSAkMiB0byBhbiBpbm5vY3VvdXMgdmFyaWFudCwgaW4gY2FzZSA8 bGltaXRzLmg+IGRlY2xhcmVzICQyLgotICAgRm9yIGV4YW1wbGUsIEhQLVVYIDExaSA8bGltaXRz Lmg+IGRlY2xhcmVzIGdldHRpbWVvZmRheS4gICovCi0jZGVmaW5lICQyIGlubm9jdW91c18kMgot Ci0vKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkg ZmV3IHByb3RvdHlwZXMsCi0gICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciAkMiAoKTsg YmVsb3cuCi0gICAgUHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBp cyBkZWZpbmVkLCBzaW5jZQotICAgIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5k aW5nIGNvbXBpbGVycy4gICovCi0KLSNpZmRlZiBfX1NURENfXwotIyBpbmNsdWRlIDxsaW1pdHMu aD4KLSNlbHNlCi0jIGluY2x1ZGUgPGFzc2VydC5oPgotI2VuZGlmCi0KLSN1bmRlZiAkMgotCi0v KiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4K LSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh IEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0 aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1j aGFyICQyICgpOwotLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlv bnMgd2hpY2ggaXQgaW1wbGVtZW50cwotICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAg U29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkCi0gICAgc29tZXRoaW5nIHN0YXJ0aW5n IHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovCi0jaWYgZGVmaW5l ZCBfX3N0dWJfJDIgfHwgZGVmaW5lZCBfX3N0dWJfX18kMgotY2hva2UgbWUKLSNlbmRpZgotCi1p bnQKLW1haW4gKCkKLXsKLXJldHVybiAkMiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBldmFsICIkMz15ZXMi Ci1lbHNlCi0gIGV2YWwgIiQzPW5vIgotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0 ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0 Ci1maQotZXZhbCBhY19yZXM9XCQkMwotCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1Ci0kYXNfZWNobyAiJGFjX3JlcyIg PiY2OyB9Ci0gIGV2YWwgJGFzX2xpbmVub19zdGFjazsgdGVzdCAieCRhc19saW5lbm9fc3RhY2si ID0geCAmJiB7IGFzX2xpbmVubz07IHVuc2V0IGFzX2xpbmVubzt9Ci0KLX0gIyBhY19mbl9jX2No ZWNrX2Z1bmMKLQotIyBhY19mbl9jX2NoZWNrX3R5cGUgTElORU5PIFRZUEUgVkFSIElOQ0xVREVT Ci0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLSMgVGVzdHMg d2hldGhlciBUWVBFIGV4aXN0cyBhZnRlciBoYXZpbmcgaW5jbHVkZWQgSU5DTFVERVMsIHNldHRp bmcgY2FjaGUKLSMgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgotYWNfZm5fY19jaGVja190eXBl ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yICQyLi4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMrc2V0fVwiIiA9IHNl dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGV2YWwgIiQz PW5vIgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBl bmQgY29uZmRlZnMuaC4gICovCi0kNAotaW50Ci1tYWluICgpCi17Ci1pZiAoc2l6ZW9mICgkMikp Ci0JIHJldHVybiAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ0Ci1pbnQKLW1haW4g KCkKLXsKLWlmIChzaXplb2YgKCgkMikpKQotCSAgICByZXR1cm4gMDsKLSAgOwotICByZXR1cm4g MDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgot Ci1lbHNlCi0gIGV2YWwgIiQzPXllcyIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0 LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jl cz1cJCQzCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAk YXNfbGluZW5vX3N0YWNrOyB0ZXN0ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGlu ZW5vPTsgdW5zZXQgYXNfbGluZW5vO30KLQotfSAjIGFjX2ZuX2NfY2hlY2tfdHlwZQotCi0jIGFj X2ZuX2NfZmluZF9pbnRYX3QgTElORU5PIEJJVFMgVkFSCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCi0jIEZpbmRzIGEgc2lnbmVkIGludGVnZXIgdHlwZSB3aXRoIHdpZHRo IEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCi0jIGFjY29yZGluZ2x5LgotYWNfZm5f Y19maW5kX2ludFhfdCAoKQotewotICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGlu ZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCi0gIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGludCQyX3QiID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGludCQyX3QuLi4gIiA+JjY7IH0KLWlmIGV2YWwgInRl c3QgXCJcJHskMytzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg IiA+JjYKLWVsc2UKLSAgZXZhbCAiJDM9bm8iCi0gICAgICMgT3JkZXIgaXMgaW1wb3J0YW50IC0g bmV2ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50aWFsbHkgc21hbGxlcgotICAgICAjIHRo YW4gaGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdpZHRoLgotICAgICBmb3IgYWNfdHlwZSBp biBpbnQkMl90ICdpbnQnICdsb25nIGludCcgXAotCSAnbG9uZyBsb25nIGludCcgJ3Nob3J0IGlu dCcgJ3NpZ25lZCBjaGFyJzsgZG8KLSAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVm YXVsdAotCSAgICAgZW51bSB7IE4gPSAkMiAvIDIgLSAxIH07Ci1pbnQKLW1haW4gKCkKLXsKLXN0 YXRpYyBpbnQgdGVzdF9hcnJheSBbMSAtIDIgKiAhKDAgPCAoJGFjX3R5cGUpICgoKCgoJGFjX3R5 cGUpIDEgPDwgTikgPDwgTikgLSAxKSAqIDIgKyAxKSldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0K LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJ TkVOTyI7IHRoZW4gOgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAotCSAgICAg ICAgZW51bSB7IE4gPSAkMiAvIDIgLSAxIH07Ci1pbnQKLW1haW4gKCkKLXsKLXN0YXRpYyBpbnQg dGVzdF9hcnJheSBbMSAtIDIgKiAhKCgkYWNfdHlwZSkgKCgoKCgkYWNfdHlwZSkgMSA8PCBOKSA8 PCBOKSAtIDEpICogMiArIDEpCi0JCSA8ICgkYWNfdHlwZSkgKCgoKCgkYWNfdHlwZSkgMSA8PCBO KSA8PCBOKSAtIDEpICogMiArIDIpKV07Ci10ZXN0X2FycmF5IFswXSA9IDAKLQotICA7Ci0gIHJl dHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhl biA6Ci0KLWVsc2UKLSAgY2FzZSAkYWNfdHlwZSBpbiAjKAotICBpbnQkMl90KSA6Ci0gICAgZXZh bCAiJDM9eWVzIiA7OyAjKAotICAqKSA6Ci0gICAgZXZhbCAiJDM9XCRhY190eXBlIiA7OwotZXNh YwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl c3QuJGFjX2V4dAotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl eHQgY29uZnRlc3QuJGFjX2V4dAotICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgi bm8iOyB0aGVuIDoKLQotZWxzZQotICBicmVhawotZmkKLSAgICAgZG9uZQotZmkKLWV2YWwgYWNf cmVzPVwkJDMKLQkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19yZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFs ICRhc19saW5lbm9fc3RhY2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19s aW5lbm89OyB1bnNldCBhc19saW5lbm87fQotCi19ICMgYWNfZm5fY19maW5kX2ludFhfdAotCi0j IGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJTkVOTyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKLSMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotIyBU cmllcyB0byBmaW5kIGlmIHRoZSBmaWVsZCBNRU1CRVIgZXhpc3RzIGluIHR5cGUgQUdHUiwgYWZ0 ZXIgaW5jbHVkaW5nCi0jIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2Nv cmRpbmdseS4KLWFjX2ZuX2NfY2hlY2tfbWVtYmVyICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xp bmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3Rh Y2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgJDIuJDMiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLiQzLi4uICIgPiY2OyB9 Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDQrc2V0fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ1Ci1pbnQKLW1haW4gKCkK LXsKLXN0YXRpYyAkMiBhY19hZ2dyOwotaWYgKGFjX2FnZ3IuJDMpCi1yZXR1cm4gMDsKLSAgOwot ICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7 IHRoZW4gOgotICBldmFsICIkND15ZXMiCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSQ1Ci1pbnQKLW1h aW4gKCkKLXsKLXN0YXRpYyAkMiBhY19hZ2dyOwotaWYgKHNpemVvZiBhY19hZ2dyLiQzKQotcmV0 dXJuIDA7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBp bGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgZXZhbCAiJDQ9eWVzIgotZWxzZQotICBldmFsICIkND1u byIKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0 ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq ZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ldmFsIGFjX3Jlcz1cJCQ0Ci0JICAgICAgIHsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUK LSRhc19lY2hvICIkYWNfcmVzIiA+JjY7IH0KLSAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyB0ZXN0 ICJ4JGFzX2xpbmVub19zdGFjayIgPSB4ICYmIHsgYXNfbGluZW5vPTsgdW5zZXQgYXNfbGluZW5v O30KLQotfSAjIGFjX2ZuX2NfY2hlY2tfbWVtYmVyCi0KLSMgYWNfZm5fY19maW5kX3VpbnRYX3Qg TElORU5PIEJJVFMgVkFSCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQot IyBGaW5kcyBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5n IGNhY2hlIHZhcmlhYmxlIFZBUgotIyBhY2NvcmRpbmdseS4KLWFjX2ZuX2NfZmluZF91aW50WF90 ICgpCi17Ci0gIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNf bGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWludCQyX3QiID4mNQotJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yIHVpbnQkMl90Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JDMr c2V0fVwiIiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNl Ci0gIGV2YWwgIiQzPW5vIgotICAgICAjIE9yZGVyIGlzIGltcG9ydGFudCAtIG5ldmVyIGNoZWNr IGEgdHlwZSB0aGF0IGlzIHBvdGVudGlhbGx5IHNtYWxsZXIKLSAgICAgIyB0aGFuIGhhbGYgb2Yg dGhlIGV4cGVjdGVkIHRhcmdldCB3aWR0aC4KLSAgICAgZm9yIGFjX3R5cGUgaW4gdWludCQyX3Qg J3Vuc2lnbmVkIGludCcgJ3Vuc2lnbmVkIGxvbmcgaW50JyBcCi0JICd1bnNpZ25lZCBsb25nIGxv bmcgaW50JyAndW5zaWduZWQgc2hvcnQgaW50JyAndW5zaWduZWQgY2hhcic7IGRvCi0gICAgICAg Y2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZk ZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWludAotbWFpbiAoKQotewotc3RhdGlj IGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoKCgkYWNfdHlwZSkgLTEgPj4gKCQyIC8gMiAtIDEp KSA+PiAoJDIgLyAyIC0gMSkgPT0gMyldOwotdGVzdF9hcnJheSBbMF0gPSAwCi0KLSAgOwotICBy ZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo ZW4gOgotICBjYXNlICRhY190eXBlIGluICMoCi0gIHVpbnQkMl90KSA6Ci0gICAgZXZhbCAiJDM9 eWVzIiA7OyAjKAotICAqKSA6Ci0gICAgZXZhbCAiJDM9XCRhY190eXBlIiA7OwotZXNhYwotZmkK LXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj X2V4dAotICAgICAgIGlmIGV2YWwgdGVzdCBcInhcJCIkMyJcIiA9IHgibm8iOyB0aGVuIDoKLQot ZWxzZQotICBicmVhawotZmkKLSAgICAgZG9uZQotZmkKLWV2YWwgYWNfcmVzPVwkJDMKLQkgICAg ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19y ZXMiID4mNQotJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQotICBldmFsICRhc19saW5lbm9fc3Rh Y2s7IHRlc3QgIngkYXNfbGluZW5vX3N0YWNrIiA9IHggJiYgeyBhc19saW5lbm89OyB1bnNldCBh c19saW5lbm87fQotCi19ICMgYWNfZm5fY19maW5kX3VpbnRYX3QKIGNhdCA+Y29uZmlnLmxvZyA8 PF9BQ0VPRgogVGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNlZCBieSBjb21w aWxlcnMgd2hpbGUKIHJ1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5nIGlmIGNvbmZp Z3VyZSBtYWtlcyBhIG1pc3Rha2UuCkBAIC0yMzg2LDExICsyMDYzLDYgQEAgJGFzX2VjaG8gIiRh c19tZTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CiAgID4kY2FjaGVfZmlsZQog ZmkKIAotYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKLWFzX2ZuX2Fw cGVuZCBhY19oZWFkZXJfbGlzdCAiIHVuaXN0ZC5oIgotYXNfZm5fYXBwZW5kIGFjX2Z1bmNfbGlz dCAiIGFsYXJtIgotYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgiCi1hc19m bl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvcGFyYW0uaCIKICMgQ2hlY2sgdGhhdCB0aGUg cHJlY2lvdXMgdmFyaWFibGVzIHNhdmVkIGluIHRoZSBjYWNoZSBoYXZlIGtlcHQgdGhlIHNhbWUK ICMgdmFsdWUuCiBhY19jYWNoZV9jb3JydXB0ZWQ9ZmFsc2UKQEAgLTI1MDgsMTczMCArMjE4MCw0 MCBAQCBBUFBFTkRfSU5DTFVERVMgYW5kIEFQUEVORF9MSUIgaW5zdGVhZCB3aGVuIHBvc3NpYmxl LiIgPiYyO30KIAogZmkKIAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19j b21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1h Y19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZM QUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9j X2NvbXBpbGVyX2dudQotaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4 dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4 fWdjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh Y193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7 IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1u ICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S Ci1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXog IiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj dXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7 IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKLSAgICAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlG Uz0kYXNfc2F2ZV9JRlMKLQotZmkKLWZpCi1DQz0kYWNfY3ZfcHJvZ19DQwotaWYgdGVzdCAtbiAi JENDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJENDIiA+JjUKLSRhc19lY2hvICIkQ0MiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g Im5vIiA+JjY7IH0KLWZpCi0KLQotZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhl bgotICBhY19jdF9DQz0kQ0MKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGdjYzsgYWNf d29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIgPSBzZXQ7IHRo ZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIk YWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVf SUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0 IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFz X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCi0g ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25l Ci1JRlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3Rf Q0MKLWlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Ci0kYXNfZWNobyAiJGFj X2N0X0NDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0gIGlm IHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgotICAgIENDPSIiCi0gIGVsc2UKLSAgICBjYXNl ICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTogV0FS TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+ JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgQ0M9JGFjX2N0X0NDCi0gIGZp Ci1lbHNlCi0gIENDPSIkYWNfY3ZfcHJvZ19DQyIKLWZpCi0KLWlmIHRlc3QgLXogIiRDQyI7IHRo ZW4KLSAgICAgICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4 fWNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4g IiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Y2MiCi0gICAgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29y ZCRhY19leGVjX2V4dCIgPiY1Ci0gICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9 JGFzX3NhdmVfSUZTCi0KLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRD QyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJu byIgPiY2OyB9Ci1maQotCi0KLSAgZmkKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0gICMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGNjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNf ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf Y3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJEND IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLSAgYWNfcHJvZ19yZWpl Y3RlZD1ubwotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2Rp ciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAm JiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl bnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi ICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0g ICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAiL3Vzci91Y2IvY2Mi OyB0aGVuCi0gICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKLSAgICAgICBjb250aW51ZQotICAg ICBmaQotICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQot ICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi1pZiB0 ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCi0gICMgV2UgZm91bmQgYSBib2dvbiBp biB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KLSAgc2V0IGR1bW15ICRh Y19jdl9wcm9nX0NDCi0gIHNoaWZ0Ci0gIGlmIHRlc3QgJCMgIT0gMDsgdGhlbgotICAgICMgV2Ug Y2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25lLgotICAgICMgSG93 ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9z ZW4KLSAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRo ZSBmdWxsIGZpbGUgbmFtZS4KLSAgICBzaGlmdAotICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIv JGFjX3dvcmQkezErJyAnfSRAIgotICBmaQotZmkKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MK LWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UK LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0 aGVuCi0gIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgZm9yIGFjX3Byb2cg aW4gY2wuZXhlCi0gIGRvCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkYWNfdG9v bF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu Ci1zZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNh Y2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgotICBhY19jdl9wcm9n X0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2 ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8K LSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAg IGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBp ZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3gg IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19D Qz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0g ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0KLWZpCi1m aQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KLSAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1Ci0kYXNfZWNo byAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIgPiY2OyB9Ci1maQotCi0KLSAg ICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCi0gIGRvbmUKLWZpCi1pZiB0ZXN0IC16ICIkQ0MiOyB0 aGVuCi0gIGFjX2N0X0NDPSRDQwotICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKLWRvCi0gICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4K LSAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgotICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19z YXZlX0lGUwotCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1pZiB0ZXN0 IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2 OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotCi0gIHRlc3QgLW4gIiRh Y19jdF9DQyIgJiYgYnJlYWsKLWRvbmUKLQotICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRo ZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29s X3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5v dCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7 OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZmkKLQotZmkKLQotCi10ZXN0IC16ICIk Q0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog aW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3 ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3Vu ZCBpbiBcJFBBVEgKLVNlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5P IiA1IDsgfQotCi0jIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIu Ci0kYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBj b21waWxlciB2ZXJzaW9uIiA+JjUKLXNldCBYICRhY19jb21waWxlCi1hY19jb21waWxlcj0kMgot Zm9yIGFjX29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwotICB7IHsgYWNf dHJ5PSIkYWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCi1jYXNlICIoKCRhY190cnkiIGluCi0g ICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190cnlf ZWNobz0kYWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsg fSA+JjUKLSAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3Qu ZXJyCi0gIGFjX3N0YXR1cz0kPwotICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgotICAg IHNlZCAnMTBhXAotLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgotICAgICAg ICAgMTBxJyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQotICAgIGNhdCBjb25mdGVzdC5lcjEg PiY1Ci0gIGZpCi0gIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKLSAgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRl c3QgJGFjX3N0YXR1cyA9IDA7IH0KLWRvbmUKLQotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+ Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkK LXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1hY19jbGVhbl9maWxlc19zYXZlPSRh Y19jbGVhbl9maWxlcwotYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBhLm91dCBhLm91 dC5kU1lNIGEuZXhlIGIub3V0IgotIyBUcnkgdG8gY3JlYXRlIGFuIGV4ZWN1dGFibGUgd2l0aG91 dCAtbyBmaXJzdCwgZGlzcmVnYXJkIGEub3V0LgotIyBJdCB3aWxsIGhlbHAgdXMgZGlhZ25vc2Ug YnJva2VuIGNvbXBpbGVycywgYW5kIGZpbmRpbmcgb3V0IGFuIGludHVpdGlvbgotIyBvZiBleGVl eHQuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdo ZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl dGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiAiID4mNjsgfQotYWNfbGlua19kZWZhdWx0PWAk YXNfZWNobyAiJGFjX2xpbmsiIHwgc2VkICdzLyAtbyAqY29uZnRlc3RbXiBdKi8vJ2AKLQotIyBU aGUgcG9zc2libGUgb3V0cHV0IGZpbGVzOgotYWNfZmlsZXM9ImEub3V0IGNvbmZ0ZXN0LmV4ZSBj b25mdGVzdCBhLmV4ZSBhX291dC5leGUgYi5vdXQgY29uZnRlc3QuKiIKLQotYWNfcm1maWxlcz0K LWZvciBhY19maWxlIGluICRhY19maWxlcwotZG8KLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICou JGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8 ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkgOzsKLSAgICAq ICkgYWNfcm1maWxlcz0iJGFjX3JtZmlsZXMgJGFjX2ZpbGUiOzsKLSAgZXNhYwotZG9uZQotcm0g LWYgJGFjX3JtZmlsZXMKLQotaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmtfZGVmYXVsdCIKLWNhc2Ug IigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3Ry eTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlfZWNobz0i XCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRhc19lY2hv ICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2xpbmtfZGVmYXVsdCIpIDI+JjUK LSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoK LSAgIyBBdXRvY29uZi0yLjEzIGNvdWxkIHNldCB0aGUgYWNfY3ZfZXhlZXh0IHZhcmlhYmxlIHRv IGBubycuCi0jIFNvIGlnbm9yZSBhIHZhbHVlIG9mIGBubycsIG90aGVyd2lzZSB0aGlzIHdvdWxk IGxlYWQgdG8gYEVYRUVYVCA9IG5vJwotIyBpbiBhIE1ha2VmaWxlLiAgV2Ugc2hvdWxkIG5vdCBv dmVycmlkZSBhY19jdl9leGVleHQgaWYgaXQgd2FzIGNhY2hlZCwKLSMgc28gdGhhdCB0aGUgdXNl ciBjYW4gc2hvcnQtY2lyY3VpdCB0aGlzIHRlc3QgZm9yIGNvbXBpbGVycyB1bmtub3duIHRvCi0j IEF1dG9jb25mLgotZm9yIGFjX2ZpbGUgaW4gJGFjX2ZpbGVzICcnCi1kbwotICB0ZXN0IC1mICIk YWNfZmlsZSIgfHwgY29udGludWUKLSAgY2FzZSAkYWNfZmlsZSBpbgotICAgICouJGFjX2V4dCB8 ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICouYmJnIHwg Ki5tYXAgfCAqLmluZiB8ICouZFNZTSB8ICoubyB8ICoub2JqICkKLQk7OwotICAgIFthYl0ub3V0 ICkKLQkjIFdlIGZvdW5kIHRoZSBkZWZhdWx0IGV4ZWN1dGFibGUsIGJ1dCBleGVleHQ9JycgaXMg bW9zdAotCSMgY2VydGFpbmx5IHJpZ2h0LgotCWJyZWFrOzsKLSAgICAqLiogKQotCWlmIHRlc3Qg IiR7YWNfY3ZfZXhlZXh0K3NldH0iID0gc2V0ICYmIHRlc3QgIiRhY19jdl9leGVleHQiICE9IG5v OwotCXRoZW4gOjsgZWxzZQotCSAgIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1te Ll0qXChcLi4qXCknYAotCWZpCi0JIyBXZSBzZXQgYWNfY3ZfZXhlZXh0IGhlcmUgYmVjYXVzZSB0 aGUgbGF0ZXIgdGVzdCBmb3IgaXQgaXMgbm90Ci0JIyBzYWZlOiBjcm9zcyBjb21waWxlcnMgbWF5 IG5vdCBhZGQgdGhlIHN1ZmZpeCBpZiBnaXZlbiBhbiBgLW8nCi0JIyBhcmd1bWVudCwgc28gd2Ug bWF5IG5lZWQgdG8ga25vdyBpdCBhdCB0aGF0IHBvaW50IGFscmVhZHkuCi0JIyBFdmVuIGlmIHRo aXMgc2VjdGlvbiBsb29rcyBjcnVmdHk6IGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mCi0JIyBhY3R1 YWxseSB3b3JraW5nLgotCWJyZWFrOzsKLSAgICAqICkKLQlicmVhazs7Ci0gIGVzYWMKLWRvbmUK LXRlc3QgIiRhY19jdl9leGVleHQiID0gbm8gJiYgYWNfY3ZfZXhlZXh0PQotCi1lbHNlCi0gIGFj X2ZpbGU9JycKLWZpCi1pZiB0ZXN0IC16ICIkYWNfZmlsZSI7IHRoZW4gOgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8g Im5vIiA+JjY7IH0KLSRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQot c2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQotCi17IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KLWFzX2ZuX2Vycm9yIDc3 ICJDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJsZXMKLVNlZSBcYGNvbmZpZy5sb2cn IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotZWxzZQotICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5 ZXMiID4mNjsgfQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lIiA+JjUKLSRh c19lY2hvX24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFt ZS4uLiAiID4mNjsgfQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRhY19maWxlIiA+JjUKLSRhc19lY2hvICIkYWNfZmlsZSIgPiY2OyB9Ci1hY19leGVl eHQ9JGFjX2N2X2V4ZWV4dAotCi1ybSAtZiAtciBhLm91dCBhLm91dC5kU1lNIGEuZXhlIGNvbmZ0 ZXN0JGFjX2N2X2V4ZWV4dCBiLm91dAotYWNfY2xlYW5fZmlsZXM9JGFjX2NsZWFuX2ZpbGVzX3Nh dmUKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y IHN1ZmZpeCBvZiBleGVjdXRhYmxlcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm Zml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9Ci1pZiB7IHsgYWNfdHJ5PSIkYWNfbGluayIK LWNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c JGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZhbCBhY190cnlf ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKLSRh c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX2xpbmsiKSAyPiY1Ci0g IGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBc JD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6Ci0g ICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0ZXN0JyBhcmUgYHByZXNlbnQnICh3 ZWxsLCBvYnNlcnZhYmxlKQotIyBjYXRjaCBgY29uZnRlc3QuZXhlJy4gIEZvciBpbnN0YW5jZSB3 aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCi0jIHdvcmsgcHJvcGVybHkgKGkuZS4sIHJl ZmVyIHRvIGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29uJ3Qgd2l0aAotIyBgcm0nLgotZm9y IGFjX2ZpbGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNvbmZ0ZXN0Lio7IGRvCi0gIHRlc3Qg LWYgIiRhY19maWxlIiB8fCBjb250aW51ZQotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4kYWNf ZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5i YmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OwotICAgICouKiAp IGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1teLl0qXChcLi4qXCknYAotCSAgYnJl YWs7OwotICAgICogKSBicmVhazs7Ci0gIGVzYWMKLWRvbmUKLWVsc2UKLSAgeyB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1 Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Ci1hc19mbl9l cnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4ZWN1dGFibGVzOiBjYW5ub3QgY29t cGlsZSBhbmQgbGluawotU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5F Tk8iIDUgOyB9Ci1maQotcm0gLWYgY29uZnRlc3QgY29uZnRlc3QkYWNfY3ZfZXhlZXh0Ci17ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2V4ZWV4 dCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2V4ZWV4dCIgPiY2OyB9Ci0KLXJtIC1mIGNvbmZ0ZXN0 LiRhY19leHQKLUVYRUVYVD0kYWNfY3ZfZXhlZXh0Ci1hY19leGVleHQ9JEVYRUVYVAotY2F0IGNv bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmgu ICAqLwotI2luY2x1ZGUgPHN0ZGlvLmg+Ci1pbnQKLW1haW4gKCkKLXsKLUZJTEUgKmYgPSBmb3Bl biAoImNvbmZ0ZXN0Lm91dCIsICJ3Iik7Ci0gcmV0dXJuIGZlcnJvciAoZikgfHwgZmNsb3NlIChm KSAhPSAwOwotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWFjX2NsZWFuX2ZpbGVzPSIk YWNfY2xlYW5fZmlsZXMgY29uZnRlc3Qub3V0IgotIyBDaGVjayB0aGF0IHRoZSBjb21waWxlciBw cm9kdWNlcyBleGVjdXRhYmxlcyB3ZSBjYW4gcnVuLiAgSWYgbm90LCBlaXRoZXIKLSMgdGhlIGNv bXBpbGVyIGlzIGJyb2tlbiwgb3Igd2UgY3Jvc3MgY29tcGlsZS4KLXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29t cGlsaW5nIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNv bXBpbGluZy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgIT0geWVzOyB0 aGVuCi0gIHsgeyBhY190cnk9IiRhY19saW5rIgotY2FzZSAiKCgkYWNfdHJ5IiBpbgotICAqXCIq IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKLSAgKikgYWNfdHJ5X2VjaG89 JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1 Ci0gIChldmFsICIkYWNfbGluayIpIDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0 ICRhY19zdGF0dXMgPSAwOyB9Ci0gIGlmIHsgYWNfdHJ5PScuL2NvbmZ0ZXN0JGFjX2N2X2V4ZWV4 dCcKLSAgeyB7IGNhc2UgIigoJGFjX3RyeSIgaW4KLSAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190 cnlfZWNobz1cJGFjX3RyeTs7Ci0gICopIGFjX3RyeV9lY2hvPSRhY190cnk7OwotZXNhYwotZXZh bCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2Vj aG9cIiIKLSRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQotICAoZXZhbCAiJGFjX3RyeSIp IDI+JjUKLSAgYWNfc3RhdHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB9 OyB0aGVuCi0gICAgY3Jvc3NfY29tcGlsaW5nPW5vCi0gIGVsc2UKLSAgICBpZiB0ZXN0ICIkY3Jv c3NfY29tcGlsaW5nIiA9IG1heWJlOyB0aGVuCi0JY3Jvc3NfY29tcGlsaW5nPXllcwotICAgIGVs c2UKLQl7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGlu IFxgJGFjX3B3ZCc6IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2Qn OiIgPiYyO30KLWFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgcnVuIEMgY29tcGlsZWQgcHJvZ3JhbXMu Ci1JZiB5b3UgbWVhbnQgdG8gY3Jvc3MgY29tcGlsZSwgdXNlIFxgLS1ob3N0Jy4KLVNlZSBcYGNv bmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQotICAgIGZpCi0gIGZp Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRj cm9zc19jb21waWxpbmciID4mNQotJGFzX2VjaG8gIiRjcm9zc19jb21waWxpbmciID4mNjsgfQot Ci1ybSAtZiBjb25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5v dXQKLWFjX2NsZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZp bGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVz Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6 Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0g PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotaW50 Ci1tYWluICgpCi17Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotcm0gLWYgY29uZnRl c3QubyBjb25mdGVzdC5vYmoKLWlmIHsgeyBhY190cnk9IiRhY19jb21waWxlIgotY2FzZSAiKCgk YWNfdHJ5IiBpbgotICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsK LSAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Ci1lc2FjCi1ldmFsIGFjX3RyeV9lY2hvPSJcIlwk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgotJGFzX2VjaG8gIiRh Y190cnlfZWNobyI7IH0gPiY1Ci0gIChldmFsICIkYWNfY29tcGlsZSIpIDI+JjUKLSAgYWNfc3Rh dHVzPSQ/Ci0gICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh Y19zdGF0dXMiID4mNQotICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKLSAgZm9yIGFj X2ZpbGUgaW4gY29uZnRlc3QubyBjb25mdGVzdC5vYmogY29uZnRlc3QuKjsgZG8KLSAgdGVzdCAt ZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlOwotICBjYXNlICRhY19maWxlIGluCi0gICAgKi4kYWNf ZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5i YmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNICkgOzsKLSAgICAqKSBhY19jdl9vYmpleHQ9YGV4 cHIgIiRhY19maWxlIiA6ICcuKlwuXCguKlwpJ2AKLSAgICAgICBicmVhazs7Ci0gIGVzYWMKLWRv bmUKLWVsc2UKLSAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1Ci1z ZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1Ci0KLXsgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2Vj aG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8g ImNhbm5vdCBjb21wdXRlIHN1ZmZpeCBvZiBvYmplY3QgZmlsZXM6IGNhbm5vdCBjb21waWxlCi1T ZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7IH0KLWZpCi1y bSAtZiBjb25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIg PiY1Ci0kYXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9Ci1PQkpFWFQ9JGFjX2N2X29iamV4 dAotYWNfb2JqZXh0PSRPQkpFWFQKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBj b21waWxlci4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNh dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVm cy5oLiAgKi8KLQotaW50Ci1tYWluICgpCi17Ci0jaWZuZGVmIF9fR05VQ19fCi0gICAgICAgY2hv a2UgbWUKLSNlbmRpZgotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf dHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY29tcGlsZXJfZ251PXllcwotZWxz ZQotICBhY19jb21waWxlcl9nbnU9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWFjX2N2X2NfY29tcGlsZXJfZ251PSRh Y19jb21waWxlcl9nbnUKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQotJGFzX2VjaG8gIiRhY19j dl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7 IHRoZW4KLSAgR0NDPXllcwotZWxzZQotICBHQ0M9Ci1maQotYWNfdGVzdF9DRkxBR1M9JHtDRkxB R1Mrc2V0fQotYWNfc2F2ZV9DRkxBR1M9JENGTEFHUwoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKLSRh c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19nK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dl cnJvcl9mbGFnCi0gICBhY19jX3dlcnJvcl9mbGFnPXllcwotICAgYWNfY3ZfcHJvZ19jY19nPW5v Ci0gICBDRkxBR1M9Ii1nIgotICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7 Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P IjsgdGhlbiA6Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAg ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u ZmRlZnMuaC4gICovCi0KLWludAotbWFpbiAoKQotewotCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1f QUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQot ICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIK LQkgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2 X3Byb2dfY2NfZz15ZXMKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0 LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgIGFjX2Nfd2Vycm9y X2ZsYWc9JGFjX3NhdmVfY193ZXJyb3JfZmxhZwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKLSRhc19lY2hv ICIkYWNfY3ZfcHJvZ19jY19nIiA+JjY7IH0KLWlmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBz ZXQ7IHRoZW4KLSAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUwotZWxpZiB0ZXN0ICRhY19jdl9wcm9n X2NjX2cgPSB5ZXM7IHRoZW4KLSAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KLSAgICBDRkxB R1M9Ii1nIC1PMiIKLSAgZWxzZQotICAgIENGTEFHUz0iLWciCi0gIGZpCi1lbHNlCi0gIGlmIHRl c3QgIiRHQ0MiID0geWVzOyB0aGVuCi0gICAgQ0ZMQUdTPSItTzIiCi0gIGVsc2UKLSAgICBDRkxB R1M9Ci0gIGZpCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1Ci0kYXNfZWNob19u ICJjaGVja2luZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9wcm9nX2NjX2M4OStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2N2X3Byb2dfY2NfYzg5PW5vCi1hY19z YXZlX0NDPSRDQwotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot LyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGFyZy5oPgotI2luY2x1ZGUgPHN0 ZGlvLmg+Ci0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KLS8q IE1vc3Qgb2YgdGhlIGZvbGxvd2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNy Yy9jb25mLnNoLiAgKi8KLXN0cnVjdCBidWYgeyBpbnQgeDsgfTsKLUZJTEUgKiAoKnJjc29wZW4p IChzdHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCk7Ci1zdGF0aWMgY2hhciAqZSAocCwg aSkKLSAgICAgY2hhciAqKnA7Ci0gICAgIGludCBpOwotewotICByZXR1cm4gcFtpXTsKLX0KLXN0 YXRpYyBjaGFyICpmIChjaGFyICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikK LXsKLSAgY2hhciAqczsKLSAgdmFfbGlzdCB2OwotICB2YV9zdGFydCAodixwKTsKLSAgcyA9IGcg KHAsIHZhX2FyZyAodixpbnQpKTsKLSAgdmFfZW5kICh2KTsKLSAgcmV0dXJuIHM7Ci19Ci0KLS8q IE9TRiA0LjAgQ29tcGFxIGNjIGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0 LiAgSXQgaGFzCi0gICBmdW5jdGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhI SCcgaGV4IGNoYXJhY3RlciBjb25zdGFudHMuCi0gICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVy cm9yIHVuZm9ydHVuYXRlbHksIGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKLSAgIGFzICd4 Jy4gIFRoZSBmb2xsb3dpbmcgaW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0 byBnZXQKLSAgIHByb3BlciBBTlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlz IGNvbWVzIG91dCB0cnVlLCBmb3IgYW4KLSAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5l Y2Vzc2FyeSB0byB3cml0ZSAnXHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZwotICAgdGhhdCdzIHRy dWUgb25seSB3aXRoIC1zdGQuICAqLwotaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8g MSA6IC0xXTsKLQotLyogSUJNIEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQs IGJ1dCBpdCByZXBsYWNlcyBtYWNybyBwYXJhbWV0ZXJzCi0gICBpbnNpZGUgc3RyaW5ncyBhbmQg Y2hhcmFjdGVyIGNvbnN0YW50cy4gICovCi0jZGVmaW5lIEZPTyh4KSAneCcKLWludCB4bGM2X2Nj X2FycmF5W0ZPTyhhKSA9PSAneCcgPyAxIDogLTFdOwotCi1pbnQgdGVzdCAoaW50IGksIGRvdWJs ZSB4KTsKLXN0cnVjdCBzMSB7aW50ICgqZikgKGludCBhKTt9Owotc3RydWN0IHMyIHtpbnQgKCpm KSAoZG91YmxlIGEpO307Ci1pbnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShz dHJ1Y3QgYnVmICosIHN0cnVjdCBzdGF0ICosIGludCksIGludCwgaW50KTsKLWludCBhcmdjOwot Y2hhciAqKmFyZ3Y7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBmIChlLCBhcmd2LCAwKSAhPSBh cmd2WzBdICB8fCAgZiAoZSwgYXJndiwgMSkgIT0gYXJndlsxXTsKLSAgOwotICByZXR1cm4gMDsK LX0KLV9BQ0VPRgotZm9yIGFjX2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1h bnNpIC1zdGQgXAotCS1BZSAiLUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05T X18iCi1kbwotICBDQz0iJGFjX3NhdmVfQ0MgJGFjX2FyZyIKLSAgaWYgYWNfZm5fY190cnlfY29t cGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCi1maQot cm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAotICB0ZXN0ICJ4JGFj X2N2X3Byb2dfY2NfYzg5IiAhPSAieG5vIiAmJiBicmVhawotZG9uZQotcm0gLWYgY29uZnRlc3Qu JGFjX2V4dAotQ0M9JGFjX3NhdmVfQ0MKLQotZmkKLSMgQUNfQ0FDSEVfVkFMCi1jYXNlICJ4JGFj X2N2X3Byb2dfY2NfYzg5IiBpbgotICB4KQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBub25lIG5lZWRlZCIgPiY1Ci0kYXNfZWNobyAibm9uZSBu ZWVkZWQiID4mNjsgfSA7OwotICB4bm8pCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6IHVuc3VwcG9ydGVkIiA+JjUKLSRhc19lY2hvICJ1bnN1cHBv cnRlZCIgPiY2OyB9IDs7Ci0gICopCi0gICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCi0g ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j dl9wcm9nX2NjX2M4OSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0g OzsKLWVzYWMKLWlmIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6Ci0K LWZpCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29tcGlsZT0nJEND IC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNfbGluaz0nJEND IC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVz dC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9n bnUKLQotCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2NvbXBpbGU9JyRD QyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFjX2xpbms9JyRD QyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRl c3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJf Z251Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhv dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGhv dyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uICIgPiY2OyB9Ci0jIE9uIFN1bnMsIHNvbWV0 aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5LgotaWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAt ZCAiJENQUCI7IHRoZW4KLSAgQ1BQPQotZmkKLWlmIHRlc3QgLXogIiRDUFAiOyB0aGVuCi0gIGlm IHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19u ICIoY2FjaGVkKSAiID4mNgotZWxzZQotICAgICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQ IG5lZWRzIHRvIGJlIGV4cGFuZGVkCi0gICAgZm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10 cmFkaXRpb25hbC1jcHAiICIvbGliL2NwcCIKLSAgICBkbwotICAgICAgYWNfcHJlcHJvY19vaz1m YWxzZQotZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCi1kbwotICAjIFVzZSBh IGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCi0g ICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgotICAjIFByZWZlciA8bGltaXRz Lmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKLSAgIyA8bGlt aXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCi0gICMgT24gdGhl IE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIs Ci0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0 Y2ggdGhpcyBjYXNlLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19TVERDX18KLSMgaW5jbHVkZSA8 bGltaXRzLmg+Ci0jZWxzZQotIyBpbmNsdWRlIDxhc3NlcnQuaD4KLSNlbmRpZgotCQkgICAgIFN5 bnRheCBlcnJvcgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoK LQotZWxzZQotICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCi1jb250aW51ZQotZmkK LXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKLQotICAjIE9L LCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVh ZGVycwotICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgotICBjYXQgY29uZmRlZnMuaCAtIDw8 X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVk ZSA8YWNfbm9uZXhpc3RlbnQuaD4KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY3BwICIkTElORU5P IjsgdGhlbiA6Ci0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCi1jb250aW51 ZQotZWxzZQotICAjIFBhc3NlcyBib3RoIHRlc3RzLgotYWNfcHJlcHJvY19vaz06Ci1icmVhawot ZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKLQotZG9u ZQotIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNv ZGUgd2FzIHNraXBwZWQuCi1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k YWNfZXh0Ci1pZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6Ci0gIGJyZWFrCi1maQotCi0gICAgZG9u ZQotICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAKLQotZmkKLSAgQ1BQPSRhY19jdl9wcm9nX0NQUAot ZWxzZQotICBhY19jdl9wcm9nX0NQUD0kQ1BQCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDUFAiID4mNQotJGFzX2VjaG8gIiRDUFAiID4mNjsg fQotYWNfcHJlcHJvY19vaz1mYWxzZQotZm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycg eWVzCi1kbwotICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNv bmZpZ3VyaW5nIGdsaWJjCi0gICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgot ICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5l ZCwgc2luY2UKLSAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21w aWxlcnMuCi0gICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUg Y29tcGlsZXIncyBwYXJzZXIsCi0gICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJy b3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD RU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaWZkZWYgX19T VERDX18KLSMgaW5jbHVkZSA8bGltaXRzLmg+Ci0jZWxzZQotIyBpbmNsdWRlIDxhc3NlcnQuaD4K LSNlbmRpZgotCQkgICAgIFN5bnRheCBlcnJvcgotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jcHAg IiRMSU5FTk8iOyB0aGVuIDoKLQotZWxzZQotICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5w dXQuCi1jb250aW51ZQotZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0 LiRhY19leHQKLQotICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRo ZXIgbm9uZXhpc3RlbnQgaGVhZGVycwotICAjIGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgotICBj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRl ZnMuaC4gICovCi0jaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KLV9BQ0VPRgotaWYgYWNfZm5f Y190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6Ci0gICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFs aWQgaW5wdXQuCi1jb250aW51ZQotZWxzZQotICAjIFBhc3NlcyBib3RoIHRlc3RzLgotYWNfcHJl cHJvY19vaz06Ci1icmVhawotZmkKLXJtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0 ZXN0LiRhY19leHQKLQotZG9uZQotIyBCZWNhdXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lG RUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCi1ybSAtZiBjb25mdGVzdC5pIGNvbmZ0 ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Ci1pZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6Ci0KLWVs c2UKLSAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBp biBcYCRhY19wd2QnOiIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdk JzoiID4mMjt9Ci1hc19mbl9lcnJvciAkPyAiQyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMg c2FuaXR5IGNoZWNrCi1TZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVO TyIgNSA7IH0KLWZpCi0KLWFjX2V4dD1jCi1hY19jcHA9JyRDUFAgJENQUEZMQUdTJwotYWNfY29t cGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JwotYWNf bGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFH UyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKLWFjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19j b21waWxlcl9nbnUKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZSIgPiY1Ci0k YXNfZWNob19uICJjaGVja2luZyBmb3IgZ3JlcCB0aGF0IGhhbmRsZXMgbG9uZyBsaW5lcyBhbmQg LWUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9HUkVQK3NldH0iID0gc2V0OyB0 aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAteiAi JEdSRVAiOyB0aGVuCi0gIGFjX3BhdGhfR1JFUF9mb3VuZD1mYWxzZQotICAjIExvb3AgdGhyb3Vn aCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAotICBh c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRI JFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0 ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19wcm9nIGluIGdyZXAgZ2dy ZXA7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv bnM7IGRvCi0gICAgICBhY19wYXRoX0dSRVA9IiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQi Ci0gICAgICB7IHRlc3QgLWYgIiRhY19wYXRoX0dSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRo X0dSRVAiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNfcGF0aF9HUkVQIGFuZCBz ZWxlY3QgaXQgaWYgaXQgaXMgZm91bmQuCi0gICMgQ2hlY2sgZm9yIEdOVSAkYWNfcGF0aF9HUkVQ Ci1jYXNlIGAiJGFjX3BhdGhfR1JFUCIgLS12ZXJzaW9uIDI+JjFgIGluCi0qR05VKikKLSAgYWNf Y3ZfcGF0aF9HUkVQPSIkYWNfcGF0aF9HUkVQIiBhY19wYXRoX0dSRVBfZm91bmQ9Ojs7Ci0qKQot ICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0LmluIgotICB3 aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0 ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCi0gICAgY3AgImNv bmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2VjaG8gJ0dSRVAnID4+ICJjb25mdGVz dC5ubCIKLSAgICAiJGFjX3BhdGhfR1JFUCIgLWUgJ0dSRVAkJyAtZSAnLShjYW5ub3QgbWF0Y2gp LScgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawot ICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwg YnJlYWsKLSAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwK LSAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0dSRVBfbWF4LTB9OyB0aGVuCi0g ICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJl dHRlciBvbmUKLSAgICAgIGFjX2N2X3BhdGhfR1JFUD0iJGFjX3BhdGhfR1JFUCIKLSAgICAgIGFj X3BhdGhfR1JFUF9tYXg9JGFjX2NvdW50Ci0gICAgZmkKLSAgICAjIDEwKigyXjEwKSBjaGFycyBh cyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCi0gICAgdGVzdCAkYWNfY291bnQgLWd0IDEw ICYmIGJyZWFrCi0gIGRvbmUKLSAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0 ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Ci1lc2FjCi0KLSAgICAgICRhY19wYXRoX0dSRVBfZm91bmQg JiYgYnJlYWsgMwotICAgIGRvbmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0g IGlmIHRlc3QgLXogIiRhY19jdl9wYXRoX0dSRVAiOyB0aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8g Im5vIGFjY2VwdGFibGUgZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRP Ui91c3IveHBnNC9iaW4iICIkTElORU5PIiA1Ci0gIGZpCi1lbHNlCi0gIGFjX2N2X3BhdGhfR1JF UD0kR1JFUAotZmkKLQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9HUkVQIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfcGF0aF9H UkVQIiA+JjY7IH0KLSBHUkVQPSIkYWNfY3ZfcGF0aF9HUkVQIgotCi0KLXsgJGFzX2VjaG8gIiRh c19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGVncmVwIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciBlZ3JlcC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9w YXRoX0VHUkVQK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+ JjYKLWVsc2UKLSAgaWYgZWNobyBhIHwgJEdSRVAgLUUgJyhhfGIpJyA+L2Rldi9udWxsIDI+JjEK LSAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAgLUUiCi0gICBlbHNlCi0gICAgIGlmIHRl c3QgLXogIiRFR1JFUCI7IHRoZW4KLSAgYWNfcGF0aF9FR1JFUF9mb3VuZD1mYWxzZQotICAjIExv b3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUt TElTVAotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGly IGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbgotZG8KLSAgSUZTPSRhc19zYXZl X0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19wcm9nIGlu IGVncmVwOyBkbwotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRl bnNpb25zOyBkbwotICAgICAgYWNfcGF0aF9FR1JFUD0iJGFzX2Rpci8kYWNfcHJvZyRhY19leGVj X2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfRUdSRVAiICYmICRhc190ZXN0X3ggIiRh Y19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQotIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfRUdS RVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05VICRhY19w YXRoX0VHUkVQCi1jYXNlIGAiJGFjX3BhdGhfRUdSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgotKkdO VSopCi0gIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIiBhY19wYXRoX0VHUkVQX2Zv dW5kPTo7OwotKikKLSAgYWNfY291bnQ9MAotICAkYXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25m dGVzdC5pbiIKLSAgd2hpbGUgOgotICBkbwotICAgIGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVz dC5pbiIgPiJjb25mdGVzdC50bXAiCi0gICAgbXYgImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0Lmlu IgotICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lm5sIgotICAgICRhc19lY2hvICdFR1JF UCcgPj4gImNvbmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29u ZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYvbnVsbCB8fCBicmVhawotICAgIGRpZmYg ImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rldi9udWxsIDI+JjEgfHwgYnJlYWsKLSAg ICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFjX2NvdW50PSRhc192YWwKLSAgICBpZiB0 ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQX21heC0wfTsgdGhlbgotICAgICAgIyBC ZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25l Ci0gICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0aF9FR1JFUCIKLSAgICAgIGFjX3BhdGhf RUdSRVBfbWF4PSRhY19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5w dXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBi cmVhawotICBkb25lCi0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5u bCBjb25mdGVzdC5vdXQ7OwotZXNhYwotCi0gICAgICAkYWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBi cmVhayAzCi0gICAgZG9uZQotICBkb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKLSAgaWYg dGVzdCAteiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIm5v IGFjY2VwdGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1Iv dXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19jdl9wYXRoX0VHUkVQ PSRFR1JFUAotZmkKLQotICAgZmkKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdSRVAiID4mNQotJGFzX2VjaG8gIiRhY19j dl9wYXRoX0VHUkVQIiA+JjY7IH0KLSBFR1JFUD0iJGFjX2N2X3BhdGhfRUdSRVAiCi0KLQoteyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBD IGhlYWRlciBmaWxlcyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRl ciBmaWxlcy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9 IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhdCBj b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5o LiAgKi8KLSNpbmNsdWRlIDxzdGRsaWIuaD4KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNpbmNsdWRl IDxzdHJpbmcuaD4KLSNpbmNsdWRlIDxmbG9hdC5oPgotCi1pbnQKLW1haW4gKCkKLXsKLQotICA7 Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5P IjsgdGhlbiA6Ci0gIGFjX2N2X2hlYWRlcl9zdGRjPXllcwotZWxzZQotICBhY19jdl9oZWFkZXJf c3RkYz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQg Y29uZnRlc3QuJGFjX2V4dAotCi1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhl bgotICAjIFN1bk9TIDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5 IHRvIEFOU0kuCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK LS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdHJpbmcuaD4KLQotX0FDRU9GCi1p ZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0gICRFR1JFUCAibWVt Y2hyIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2X2hlYWRlcl9zdGRj PW5vCi1maQotcm0gLWYgY29uZnRlc3QqCi0KLWZpCi0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl9z dGRjID0geWVzOyB0aGVuCi0gICMgSVNDIDIuMC4yIHN0ZGxpYi5oIGRvZXMgbm90IGRlY2xhcmUg ZnJlZSwgY29udHJhcnkgdG8gQU5TSS4KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29u ZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN0ZGxpYi5o PgotCi1fQUNFT0YKLWlmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwK LSAgJEVHUkVQICJmcmVlIiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotCi1lbHNlCi0gIGFjX2N2 X2hlYWRlcl9zdGRjPW5vCi1maQotcm0gLWYgY29uZnRlc3QqCi0KLWZpCi0KLWlmIHRlc3QgJGFj X2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCi0gICMgL2Jpbi9jYyBpbiBJcml4LTQuMC41IGdl dHMgbm9uLUFOU0kgY3R5cGUgbWFjcm9zIHVubGVzcyB1c2luZyAtYW5zaS4KLSAgaWYgdGVzdCAi JGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICA6Ci1lbHNlCi0gIGNhdCBjb25mZGVm cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8K LSNpbmNsdWRlIDxjdHlwZS5oPgotI2luY2x1ZGUgPHN0ZGxpYi5oPgotI2lmICgoJyAnICYgMHgw RkYpID09IDB4MDIwKQotIyBkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9IChjKSAmJiAoYykgPD0g J3onKQotIyBkZWZpbmUgVE9VUFBFUihjKSAoSVNMT1dFUihjKSA/ICdBJyArICgoYykgLSAnYScp IDogKGMpKQotI2Vsc2UKLSMgZGVmaW5lIElTTE9XRVIoYykgXAotCQkgICAoKCdhJyA8PSAoYykg JiYgKGMpIDw9ICdpJykgXAotCQkgICAgIHx8ICgnaicgPD0gKGMpICYmIChjKSA8PSAncicpIFwK LQkJICAgICB8fCAoJ3MnIDw9IChjKSAmJiAoYykgPD0gJ3onKSkKLSMgZGVmaW5lIFRPVVBQRVIo YykgKElTTE9XRVIoYykgPyAoKGMpIHwgMHg0MCkgOiAoYykpCi0jZW5kaWYKLQotI2RlZmluZSBY T1IoZSwgZikgKCgoZSkgJiYgIShmKSkgfHwgKCEoZSkgJiYgKGYpKSkKLWludAotbWFpbiAoKQot ewotICBpbnQgaTsKLSAgZm9yIChpID0gMDsgaSA8IDI1NjsgaSsrKQotICAgIGlmIChYT1IgKGlz bG93ZXIgKGkpLCBJU0xPV0VSIChpKSkKLQl8fCB0b3VwcGVyIChpKSAhPSBUT1VQUEVSIChpKSkK LSAgICAgIHJldHVybiAyOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlf cnVuICIkTElORU5PIjsgdGhlbiA6Ci0KLWVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N0ZGM9bm8KLWZp Ci1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0 ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25m dGVzdC4kYWNfZXh0Ci1maQotCi1maQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVhZGVyX3N0ZGMiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9oZWFkZXJfc3RkYyIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHll czsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBTVERDX0hFQURFUlMgMSIgPj5jb25mZGVmcy5o Ci0KLWZpCi0KLSMgT24gSVJJWCA1LjMsIHN5cy90eXBlcyBhbmQgaW50dHlwZXMuaCBhcmUgY29u ZmxpY3RpbmcuCi1mb3IgYWNfaGVhZGVyIGluIHN5cy90eXBlcy5oIHN5cy9zdGF0Lmggc3RkbGli Lmggc3RyaW5nLmggbWVtb3J5Lmggc3RyaW5ncy5oIFwKLQkJICBpbnR0eXBlcy5oIHN0ZGludC5o IHVuaXN0ZC5oCi1kbyA6Ci0gIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8k YWNfaGVhZGVyIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgIiRM SU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0 Ci0iCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9IHgieWVzIjsgdGhlbiA6 Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRh Y19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCi0KLWZpCi0KLWRvbmUKLQotCi0KLSAg YWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgIm1pbml4L2NvbmZpZy5oIiAi YWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0 ZXN0ICJ4JGFjX2N2X2hlYWRlcl9taW5peF9jb25maWdfaCIgPSB4IiJ5ZXM7IHRoZW4gOgotICBN SU5JWD15ZXMKLWVsc2UKLSAgTUlOSVg9Ci1maQotCi0KLSAgaWYgdGVzdCAiJE1JTklYIiA9IHll czsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMu aAotCi0KLSRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgK LQotCi0kYXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCi0KLSAgZmkKLQot Ci0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1Ci0kYXNfZWNob19u ICJjaGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19f K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotCi0jCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKLQkgICRhY19pbmNs dWRlc19kZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLQotICA7Ci0gIHJldHVybiAwOwotfQotX0FD RU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X3Nh ZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fPXllcwotZWxzZQotICBhY19jdl9zYWZlX3RvX2Rl ZmluZV9fX2V4dGVuc2lvbnNfXz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0 ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAotZmkKLXsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRl bnNpb25zX18iID4mNQotJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lv bnNfXyIgPiY2OyB9Ci0gIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19f ID0geWVzICYmCi0gICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25m ZGVmcy5oCi0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5o Ci0KLSAgJGFzX2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCi0KLSAg JGFzX2VjaG8gIiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMu aAotCi0gICRhc19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAot Ci0KLSMgTWFrZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KLSRTSEVMTCAiJGFjX2F1eF9k aXIvY29uZmlnLnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKLSAgYXNfZm5fZXJyb3IgJD8g ImNhbm5vdCBydW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1Ci0K LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQg c3lzdGVtIHR5cGUiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUu Li4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfYnVpbGQrc2V0fSIgPSBzZXQ7IHRoZW4gOgot ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19idWlsZF9hbGlhcz0kYnVp bGRfYWxpYXMKLXRlc3QgIngkYWNfYnVpbGRfYWxpYXMiID0geCAmJgotICBhY19idWlsZF9hbGlh cz1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcuZ3Vlc3MiYAotdGVzdCAieCRhY19idWlsZF9h bGlhcyIgPSB4ICYmCi0gIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsg eW91IG11c3Qgc3BlY2lmeSBvbmUiICIkTElORU5PIiA1Ci1hY19jdl9idWlsZD1gJFNIRUxMICIk YWNfYXV4X2Rpci9jb25maWcuc3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8Ci0gIGFzX2ZuX2Vycm9y ICQ/ICIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVk IiAiJExJTkVOTyIgNQotCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRhY19jdl9idWlsZCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+ JjY7IH0KLWNhc2UgJGFjX2N2X2J1aWxkIGluCi0qLSotKikgOzsKLSopIGFzX2ZuX2Vycm9yICQ/ ICJpbnZhbGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDUgOzsKLWVzYWMK LWJ1aWxkPSRhY19jdl9idWlsZAotYWNfc2F2ZV9JRlM9JElGUzsgSUZTPSctJwotc2V0IHggJGFj X2N2X2J1aWxkCi1zaGlmdAotYnVpbGRfY3B1PSQxCi1idWlsZF92ZW5kb3I9JDIKLXNoaWZ0OyBz aGlmdAotIyBSZW1lbWJlciwgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBJRlMgaXMgdXNlZCB0byBj cmVhdGUgJCosCi0jIGV4Y2VwdCB3aXRoIG9sZCBzaGVsbHM6Ci1idWlsZF9vcz0kKgotSUZTPSRh Y19zYXZlX0lGUwotY2FzZSAkYnVpbGRfb3MgaW4gKlwgKikgYnVpbGRfb3M9YGVjaG8gIiRidWls ZF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVzYWMKLQotCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUiID4mNQotJGFzX2Vj aG9fbiAiY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHth Y19jdl9ob3N0K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+ JjYKLWVsc2UKLSAgaWYgdGVzdCAieCRob3N0X2FsaWFzIiA9IHg7IHRoZW4KLSAgYWNfY3ZfaG9z dD0kYWNfY3ZfYnVpbGQKLWVsc2UKLSAgYWNfY3ZfaG9zdD1gJFNIRUxMICIkYWNfYXV4X2Rpci9j b25maWcuc3ViIiAkaG9zdF9hbGlhc2AgfHwKLSAgICBhc19mbl9lcnJvciAkPyAiJFNIRUxMICRh Y19hdXhfZGlyL2NvbmZpZy5zdWIgJGhvc3RfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQotZmkK LQotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk YWNfY3ZfaG9zdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2hvc3QiID4mNjsgfQotY2FzZSAkYWNf Y3ZfaG9zdCBpbgotKi0qLSopIDs7Ci0qKSBhc19mbl9lcnJvciAkPyAiaW52YWxpZCB2YWx1ZSBv ZiBjYW5vbmljYWwgaG9zdCIgIiRMSU5FTk8iIDUgOzsKLWVzYWMKLWhvc3Q9JGFjX2N2X2hvc3QK LWFjX3NhdmVfSUZTPSRJRlM7IElGUz0nLScKLXNldCB4ICRhY19jdl9ob3N0Ci1zaGlmdAotaG9z dF9jcHU9JDEKLWhvc3RfdmVuZG9yPSQyCi1zaGlmdDsgc2hpZnQKLSMgUmVtZW1iZXIsIHRoZSBm aXJzdCBjaGFyYWN0ZXIgb2YgSUZTIGlzIHVzZWQgdG8gY3JlYXRlICQqLAotIyBleGNlcHQgd2l0 aCBvbGQgc2hlbGxzOgotaG9zdF9vcz0kKgotSUZTPSRhY19zYXZlX0lGUwotY2FzZSAkaG9zdF9v cyBpbiAqXCAqKSBob3N0X29zPWBlY2hvICIkaG9zdF9vcyIgfCBzZWQgJ3MvIC8tL2cnYDs7IGVz YWMKLQotCi0KLSMgTTQgTWFjcm8gaW5jbHVkZXMKLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQot Ci0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0KLQotCi0K LQotCi0KLQotCi0jIHBrZy5tNCAtIE1hY3JvcyB0byBsb2NhdGUgYW5kIHV0aWxpc2UgcGtnLWNv bmZpZy4gICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCi0jIHNlcmlhbCAxIChwa2ctY29uZmln LTAuMjQpCi0jCi0jIENvcHlyaWdodCDCqSAyMDA0IFNjb3R0IEphbWVzIFJlbW5hbnQgPHNjb3R0 QG5ldHNwbGl0LmNvbT4uCi0jCi0jIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3Ug Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Ci0jIGl0IHVuZGVyIHRoZSB0ZXJtcyBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5Ci0jIHRoZSBG cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2Us IG9yCi0jIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCi0jCi0jIFRoaXMgcHJv Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBi dXQKLSMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJy YW50eSBvZgotIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuICBTZWUgdGhlIEdOVQotIyBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl dGFpbHMuCi0jCi0jIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBH ZW5lcmFsIFB1YmxpYyBMaWNlbnNlCi0jIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3Qs IHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCi0jIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBs ZSBQbGFjZSAtIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuCi0jCi0jIEFz IGEgc3BlY2lhbCBleGNlcHRpb24gdG8gdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBp ZiB5b3UKLSMgZGlzdHJpYnV0ZSB0aGlzIGZpbGUgYXMgcGFydCBvZiBhIHByb2dyYW0gdGhhdCBj b250YWlucyBhCi0jIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRvY29uZiwg eW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCi0jIHRoZSBzYW1lIGRpc3RyaWJ1dGlvbiB0ZXJtcyB0 aGF0IHlvdSB1c2UgZm9yIHRoZSByZXN0IG9mIHRoYXQgcHJvZ3JhbS4KLQotIyBQS0dfUFJPR19Q S0dfQ09ORklHKFtNSU4tVkVSU0lPTl0pCi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KLSMgUEtHX1BST0dfUEtHX0NPTkZJRwotCi0jIFBLR19DSEVDS19FWElTVFMoTU9EVUxF UywgW0FDVElPTi1JRi1GT1VORF0sIFtBQ1RJT04tSUYtTk9ULUZPVU5EXSkKLSMKLSMgQ2hlY2sg dG8gc2VlIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIHNldCBvZiBtb2R1bGVzIGV4aXN0cy4gIFNpbWls YXIKLSMgdG8gUEtHX0NIRUNLX01PRFVMRVMoKSwgYnV0IGRvZXMgbm90IHNldCB2YXJpYWJsZXMg b3IgcHJpbnQgZXJyb3JzLgotIwotIyBQbGVhc2UgcmVtZW1iZXIgdGhhdCBtNCBleHBhbmRzIEFD X1JFUVVJUkUoW1BLR19QUk9HX1BLR19DT05GSUddKQotIyBvbmx5IGF0IHRoZSBmaXJzdCBvY2N1 cmVuY2UgaW4gY29uZmlndXJlLmFjLCBzbyBpZiB0aGUgZmlyc3QgcGxhY2UKLSMgaXQncyBjYWxs ZWQgbWlnaHQgYmUgc2tpcHBlZCAoc3VjaCBhcyBpZiBpdCBpcyB3aXRoaW4gYW4gImlmIiwgeW91 Ci0jIGhhdmUgdG8gY2FsbCBQS0dfQ0hFQ0tfRVhJU1RTIG1hbnVhbGx5Ci0jIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0KLQot IyBfUEtHX0NPTkZJRyhbVkFSSUFCTEVdLCBbQ09NTUFORF0sIFtNT0RVTEVTXSkKLSMgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0jIF9QS0dfQ09ORklHCi0K LSMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECi0jIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCi0jIF9QS0dfU0hPUlRfRVJST1JTX1NVUFBPUlRFRAotCi0KLSMgUEtHX0NIRUNLX01P RFVMRVMoVkFSSUFCTEUtUFJFRklYLCBNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwKLSMgW0FD VElPTi1JRi1OT1QtRk9VTkRdKQotIwotIwotIyBOb3RlIHRoYXQgaWYgdGhlcmUgaXMgYSBwb3Nz aWJpbGl0eSB0aGUgZmlyc3QgY2FsbCB0bwotIyBQS0dfQ0hFQ0tfTU9EVUxFUyBtaWdodCBub3Qg aGFwcGVuLCB5b3Ugc2hvdWxkIGJlIHN1cmUgdG8gaW5jbHVkZSBhbgotIyBleHBsaWNpdCBjYWxs IHRvIFBLR19QUk9HX1BLR19DT05GSUcgaW4geW91ciBjb25maWd1cmUuYWMKLSMKLSMKLSMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KLSMgUEtHX0NIRUNLX01PRFVMRVMKLQotCi0KLSMgV2UgZGVmaW5lLCBzZXBhcmF0ZWx5LCBQ VEhSRUFEX0NGTEFHUywgX0xERkxBR1MgYW5kIF9MSUJTCi0jIGV2ZW4gdGhvdWdoIGN1cnJlbnRs eSB3ZSBkb24ndCBzZXQgdGhlbSB2ZXJ5IHNlcGFyYXRlbHkuCi0jIFRoaXMgbWVhbnMgdGhhdCB0 aGUgbWFrZWZpbGVzIHdpbGwgbm90IG5lZWQgdG8gY2hhbmdlIGluCi0jIHRoZSBmdXR1cmUgaWYg d2UgbWFrZSB0aGUgdGVzdCBtb3JlIHNvcGhpc3RpY2F0ZWQuCi0KLQotCi0jIFdlIGludm9rZSBB WF9QVEhSRUFEX1ZBUlMgd2l0aCB0aGUgbmFtZSBvZiBhbm90aGVyIG1hY3JvCi0jIHdoaWNoIGlz IHRoZW4gZXhwYW5kZWQgb25jZSBmb3IgZWFjaCB2YXJpYWJsZS4KLQotCi0KLQotCi0KLQotCi0j IEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKLQotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWdpdGh0 dHAgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfZ2l0aHR0cCtzZXR9IiA9IHNldDsgdGhl biA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX2dpdGh0dHA7Ci1maQotCi0KLWlmIHRlc3QgIngkZW5h YmxlX2dpdGh0dHAiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfZ2l0aHR0cD0ibiIKLQot ZWxpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9j dl9naXRodHRwPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgotCi0g ICAgYXhfY3ZfZ2l0aHR0cD0ibiIKLQotZmkKLWdpdGh0dHA9JGF4X2N2X2dpdGh0dHAKLQotCi0K LSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIk e2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxl X21vbml0b3JzOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieG5vIjsg dGhlbiA6Ci0KLSAgICBheF9jdl9tb25pdG9ycz0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9t b25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbW9uaXRvcnM9InkiCi0KLWVs aWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgotCi0gICAgYXhfY3ZfbW9uaXRvcnM9 InkiCi0KLWZpCi1tb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKLQotCi0KLSMgQ2hlY2sgd2hldGhl ciAtLWVuYWJsZS12dHBtIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3Z0cG0rc2V0fSIg PSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV92dHBtOwotZmkKLQotCi1pZiB0ZXN0 ICJ4JGVuYWJsZV92dHBtIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3Z0cG09Im4iCi0K LWVsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhfY3Zf dnRwbT0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl92dHBtOyB0aGVuIDoKLQotICAgIGF4X2N2 X3Z0cG09Im4iCi0KLWZpCi12dHBtPSRheF9jdl92dHBtCi0KLQotCi0jIENoZWNrIHdoZXRoZXIg LS1lbmFibGUteGVuYXBpIHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX3hlbmFwaStzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX3hlbmFwaTsKLWZpCi0KLQotaWYg dGVzdCAieCRlbmFibGVfeGVuYXBpIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X3hlbmFw aT0ibiIKLQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInh5ZXMiOyB0aGVuIDoKLQot ICAgIGF4X2N2X3hlbmFwaT0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl94ZW5hcGk7IHRoZW4g OgotCi0gICAgYXhfY3ZfeGVuYXBpPSJuIgotCi1maQoteGVuYXBpPSRheF9jdl94ZW5hcGkKLQot Ci0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1weXRob250b29scyB3YXMgZ2l2ZW4uCi1pZiB0 ZXN0ICIke2VuYWJsZV9weXRob250b29scytzZXR9IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZh bD0kZW5hYmxlX3B5dGhvbnRvb2xzOwotZmkKLQotCi1pZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250 b29scyIgPSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9weXRob250b29scz0ibiIKLQotZWxp ZiB0ZXN0ICJ4JGVuYWJsZV9weXRob250b29scyIgPSAieHllcyI7IHRoZW4gOgotCi0gICAgYXhf Y3ZfcHl0aG9udG9vbHM9InkiCi0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfcHl0aG9udG9vbHM7IHRo ZW4gOgotCi0gICAgYXhfY3ZfcHl0aG9udG9vbHM9InkiCi0KLWZpCi1weXRob250b29scz0kYXhf Y3ZfcHl0aG9udG9vbHMKLQotCi0KLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1vY2FtbHRvb2xz IHdhcyBnaXZlbi4KLWlmIHRlc3QgIiR7ZW5hYmxlX29jYW1sdG9vbHMrc2V0fSIgPSBzZXQ7IHRo ZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9vY2FtbHRvb2xzOwotZmkKLQotCi1pZiB0ZXN0ICJ4 JGVuYWJsZV9vY2FtbHRvb2xzIiA9ICJ4bm8iOyB0aGVuIDoKLQotICAgIGF4X2N2X29jYW1sdG9v bHM9Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4g OgotCi0gICAgYXhfY3Zfb2NhbWx0b29scz0ieSIKLQotZWxpZiB0ZXN0IC16ICRheF9jdl9vY2Ft bHRvb2xzOyB0aGVuIDoKLQotICAgIGF4X2N2X29jYW1sdG9vbHM9InkiCi0KLWZpCi1vY2FtbHRv b2xzPSRheF9jdl9vY2FtbHRvb2xzCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWlu aXRlcm0gd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7 IHRoZW4gOgotICBlbmFibGV2YWw9JGVuYWJsZV9taW5pdGVybTsKLWZpCi0KLQotaWYgdGVzdCAi eCRlbmFibGVfbWluaXRlcm0iID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3ZfbWluaXRlcm09 Im4iCi0KLWVsaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMiOyB0aGVuIDoKLQot ICAgIGF4X2N2X21pbml0ZXJtPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0 aGVuIDoKLQotICAgIGF4X2N2X21pbml0ZXJtPSJuIgotCi1maQotbWluaXRlcm09JGF4X2N2X21p bml0ZXJtCi0KLQotCi0jIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3YXMgZ2l2ZW4u Ci1pZiB0ZXN0ICIke2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxl dmFsPSRlbmFibGVfbG9tb3VudDsKLWZpCi0KLQotaWYgdGVzdCAieCRlbmFibGVfbG9tb3VudCIg PSAieG5vIjsgdGhlbiA6Ci0KLSAgICBheF9jdl9sb21vdW50PSJuIgotCi1lbGlmIHRlc3QgIngk ZW5hYmxlX2xvbW91bnQiID0gInh5ZXMiOyB0aGVuIDoKLQotICAgIGF4X2N2X2xvbW91bnQ9Inki Ci0KLWVsaWYgdGVzdCAteiAkYXhfY3ZfbG9tb3VudDsgdGhlbiA6Ci0KLSAgICBheF9jdl9sb21v dW50PSJuIgotCi1maQotbG9tb3VudD0kYXhfY3ZfbG9tb3VudAotCi0KLQotIyBDaGVjayB3aGV0 aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdpdmVuLgotaWYgdGVzdCAiJHtlbmFibGVfb3ZtZitzZXR9 IiA9IHNldDsgdGhlbiA6Ci0gIGVuYWJsZXZhbD0kZW5hYmxlX292bWY7Ci1maQotCi0KLWlmIHRl c3QgIngkZW5hYmxlX292bWYiID0gInhubyI7IHRoZW4gOgotCi0gICAgYXhfY3Zfb3ZtZj0ibiIK LQotZWxpZiB0ZXN0ICJ4JGVuYWJsZV9vdm1mIiA9ICJ4eWVzIjsgdGhlbiA6Ci0KLSAgICBheF9j dl9vdm1mPSJ5IgotCi1lbGlmIHRlc3QgLXogJGF4X2N2X292bWY7IHRoZW4gOgotCi0gICAgYXhf Y3Zfb3ZtZj0ibiIKLQotZmkKLW92bWY9JGF4X2N2X292bWYKKyMgTTQgTWFjcm8gaW5jbHVkZXMK IAogCiAKLSMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1yb21iaW9zIHdhcyBnaXZlbi4KLWlmIHRl c3QgIiR7ZW5hYmxlX3JvbWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICBlbmFibGV2YWw9JGVu YWJsZV9yb21iaW9zOwotZmkKIAogCi1pZiB0ZXN0ICJ4JGVuYWJsZV9yb21iaW9zIiA9ICJ4bm8i OyB0aGVuIDoKIAotICAgIGF4X2N2X3JvbWJpb3M9Im4iCiAKLWVsaWYgdGVzdCAieCRlbmFibGVf cm9tYmlvcyIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgYXhfY3Zfcm9tYmlvcz0ieSIKIAotZWxp ZiB0ZXN0IC16ICRheF9jdl9yb21iaW9zOyB0aGVuIDoKIAotICAgIGF4X2N2X3JvbWJpb3M9Inki CiAKLWZpCi1yb21iaW9zPSRheF9jdl9yb21iaW9zCiAKIAogCi0jIENoZWNrIHdoZXRoZXIgLS1l bmFibGUtc2VhYmlvcyB3YXMgZ2l2ZW4uCi1pZiB0ZXN0ICIke2VuYWJsZV9zZWFiaW9zK3NldH0i ID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRlbmFibGVfc2VhYmlvczsKLWZpCiAKIAotaWYg dGVzdCAieCRlbmFibGVfc2VhYmlvcyIgPSAieG5vIjsgdGhlbiA6CiAKLSAgICBheF9jdl9zZWFi aW9zPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX3NlYWJpb3MiID0gInh5ZXMiOyB0aGVuIDoK IAotICAgIGF4X2N2X3NlYWJpb3M9InkiCiAKLWVsaWYgdGVzdCAteiAkYXhfY3Zfc2VhYmlvczsg dGhlbiA6CiAKLSAgICBheF9jdl9zZWFiaW9zPSJ5IgogCi1maQotc2VhYmlvcz0kYXhfY3Zfc2Vh YmlvcwogCiAKIAotIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLWRlYnVnIHdhcyBnaXZlbi4KLWlm IHRlc3QgIiR7ZW5hYmxlX2RlYnVnK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgZW5hYmxldmFsPSRl bmFibGVfZGVidWc7Ci1maQogCiAKLWlmIHRlc3QgIngkZW5hYmxlX2RlYnVnIiA9ICJ4bm8iOyB0 aGVuIDoKIAotICAgIGF4X2N2X2RlYnVnPSJuIgogCi1lbGlmIHRlc3QgIngkZW5hYmxlX2RlYnVn IiA9ICJ4eWVzIjsgdGhlbiA6CiAKLSAgICBheF9jdl9kZWJ1Zz0ieSIKIAotZWxpZiB0ZXN0IC16 ICRheF9jdl9kZWJ1ZzsgdGhlbiA6CiAKLSAgICBheF9jdl9kZWJ1Zz0ieSIKIAotZmkKLWRlYnVn PSRheF9jdl9kZWJ1ZwogCiAKIApAQCAtNDI0MCw5MzAgKzIyMjIsNDMyIEBAIGRlYnVnPSRheF9j dl9kZWJ1ZwogCiAKIAotZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCi1kbwotICAgIFBS RVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgotZG9uZQotZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9M SUIKLWRvCi0gICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKLWRvbmUKLWZvciBjZmxh ZyBpbiAkQVBQRU5EX0lOQ0xVREVTCi1kbwotICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWci Ci1kb25lCi1mb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCi1kbwotICAgIEFQUEVORF9MREZMQUdT Kz0iIC1MJGxkZmxhZyIKLWRvbmUKLUNGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQ UEVORF9DRkxBR1MiCi1MREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRf TERGTEFHUyIKIAogCiAKIAogCiAKKyMgcGtnLm00IC0gTWFjcm9zIHRvIGxvY2F0ZSBhbmQgdXRp bGlzZSBwa2ctY29uZmlnLiAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgc2VyaWFsIDEg KHBrZy1jb25maWctMC4yNCkKKyMKKyMgQ29weXJpZ2h0IMKpIDIwMDQgU2NvdHQgSmFtZXMgUmVt bmFudCA8c2NvdHRAbmV0c3BsaXQuY29tPi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29m dHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIg dGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQg YnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0 aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMK KyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi ZSB1c2VmdWwsIGJ1dAorIyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBp bXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCisjIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug Zm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyMgYWxvbmcgd2l0aCB0aGlzIHByb2dy YW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwgSW5j LiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVT QS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRoaXMgZmlsZSBhcyBwYXJ0IG9mIGEgcHJv Z3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJhdGlvbiBzY3JpcHQgZ2VuZXJhdGVkIGJ5 IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIKKyMgdGhlIHNhbWUgZGlzdHJpYnV0 aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFtLgogCisj IFBLR19QUk9HX1BLR19DT05GSUcoW01JTi1WRVJTSU9OXSkKKyMgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQorIyBQS0dfUFJPR19QS0dfQ09ORklHCiAKKyMgUEtHX0NIRUNLX0VY SVNUUyhNT0RVTEVTLCBbQUNUSU9OLUlGLUZPVU5EXSwgW0FDVElPTi1JRi1OT1QtRk9VTkRdKQor IworIyBDaGVjayB0byBzZWUgd2hldGhlciBhIHBhcnRpY3VsYXIgc2V0IG9mIG1vZHVsZXMgZXhp c3RzLiAgU2ltaWxhcgorIyB0byBQS0dfQ0hFQ0tfTU9EVUxFUygpLCBidXQgZG9lcyBub3Qgc2V0 IHZhcmlhYmxlcyBvciBwcmludCBlcnJvcnMuCisjCisjIFBsZWFzZSByZW1lbWJlciB0aGF0IG00 IGV4cGFuZHMgQUNfUkVRVUlSRShbUEtHX1BST0dfUEtHX0NPTkZJR10pCisjIG9ubHkgYXQgdGhl IGZpcnN0IG9jY3VyZW5jZSBpbiBjb25maWd1cmUuYWMsIHNvIGlmIHRoZSBmaXJzdCBwbGFjZQor IyBpdCdzIGNhbGxlZCBtaWdodCBiZSBza2lwcGVkIChzdWNoIGFzIGlmIGl0IGlzIHdpdGhpbiBh biAiaWYiLCB5b3UKKyMgaGF2ZSB0byBjYWxsIFBLR19DSEVDS19FWElTVFMgbWFudWFsbHkKKyMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KIAogCisjIF9QS0dfQ09ORklHKFtWQVJJQUJMRV0sIFtDT01NQU5EXSwgW01PRFVMRVNd KQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BL R19DT05GSUcKIAorIyBfUEtHX1NIT1JUX0VSUk9SU19TVVBQT1JURUQKKyMgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KKyMgX1BLR19TSE9SVF9FUlJPUlNfU1VQUE9SVEVECiAKIAorIyBQ S0dfQ0hFQ0tfTU9EVUxFUyhWQVJJQUJMRS1QUkVGSVgsIE1PRFVMRVMsIFtBQ1RJT04tSUYtRk9V TkRdLAorIyBbQUNUSU9OLUlGLU5PVC1GT1VORF0pCisjCisjCisjIE5vdGUgdGhhdCBpZiB0aGVy ZSBpcyBhIHBvc3NpYmlsaXR5IHRoZSBmaXJzdCBjYWxsIHRvCisjIFBLR19DSEVDS19NT0RVTEVT IG1pZ2h0IG5vdCBoYXBwZW4sIHlvdSBzaG91bGQgYmUgc3VyZSB0byBpbmNsdWRlIGFuCisjIGV4 cGxpY2l0IGNhbGwgdG8gUEtHX1BST0dfUEtHX0NPTkZJRyBpbiB5b3VyIGNvbmZpZ3VyZS5hYwor IworIworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQorIyBQS0dfQ0hFQ0tfTU9EVUxFUwogCi0jIENoZWNrcyBmb3IgcHJvZ3Jh bXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dCIgPiY1Ci0kYXNfZWNob19uICJj aGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2VzIG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4gIiA+JjY7 IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9TRUQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNf ZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICAgICAgICAgICAgYWNfc2NyaXB0PXMvYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEvYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi YmJiYmJiYmJiLwotICAgICBmb3IgYWNfaSBpbiAxIDIgMyA0IDUgNiA3OyBkbwotICAgICAgIGFj X3NjcmlwdD0iJGFjX3NjcmlwdCRhc19ubCRhY19zY3JpcHQiCi0gICAgIGRvbmUKLSAgICAgZWNo byAiJGFjX3NjcmlwdCIgMj4vZGV2L251bGwgfCBzZWQgOTlxID5jb25mdGVzdC5zZWQKLSAgICAg eyBhY19zY3JpcHQ9OyB1bnNldCBhY19zY3JpcHQ7fQotICAgICBpZiB0ZXN0IC16ICIkU0VEIjsg dGhlbgotICBhY19wYXRoX1NFRF9mb3VuZD1mYWxzZQotICAjIExvb3AgdGhyb3VnaCB0aGUgdXNl cidzIHBhdGggYW5kIHRlc3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAotICBhc19zYXZlX0lG Uz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJ RlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9y IGFjX3Byb2cgaW4gc2VkIGdzZWQ7IGRvCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gICAgICBhY19wYXRoX1NFRD0iJGFzX2Rpci8kYWNf cHJvZyRhY19leGVjX2V4dCIKLSAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfU0VEIiAmJiAkYXNf dGVzdF94ICIkYWNfcGF0aF9TRUQiOyB9IHx8IGNvbnRpbnVlCi0jIENoZWNrIGZvciBHTlUgYWNf cGF0aF9TRUQgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KLSAgIyBDaGVjayBmb3IgR05V ICRhY19wYXRoX1NFRAotY2FzZSBgIiRhY19wYXRoX1NFRCIgLS12ZXJzaW9uIDI+JjFgIGluCi0q R05VKikKLSAgYWNfY3ZfcGF0aF9TRUQ9IiRhY19wYXRoX1NFRCIgYWNfcGF0aF9TRURfZm91bmQ9 Ojs7Ci0qKQotICBhY19jb3VudD0wCi0gICRhc19lY2hvX24gMDEyMzQ1Njc4OSA+ImNvbmZ0ZXN0 LmluIgotICB3aGlsZSA6Ci0gIGRvCi0gICAgY2F0ICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0Lmlu IiA+ImNvbmZ0ZXN0LnRtcCIKLSAgICBtdiAiY29uZnRlc3QudG1wIiAiY29uZnRlc3QuaW4iCi0g ICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCi0gICAgJGFzX2VjaG8gJycgPj4gImNv bmZ0ZXN0Lm5sIgotICAgICIkYWNfcGF0aF9TRUQiIC1mIGNvbmZ0ZXN0LnNlZCA8ICJjb25mdGVz dC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFrCi0gICAgZGlmZiAiY29u ZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8fCBicmVhawotICAgIGFz X2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3ZhbAotICAgIGlmIHRlc3Qg JGFjX2NvdW50IC1ndCAke2FjX3BhdGhfU0VEX21heC0wfTsgdGhlbgotICAgICAgIyBCZXN0IG9u ZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCi0gICAg ICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIgotICAgICAgYWNfcGF0aF9TRURfbWF4PSRh Y19jb3VudAotICAgIGZpCi0gICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9y ZSB0aGFuIGVub3VnaAotICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhawotICBkb25l Ci0gIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5v dXQ7OwotZXNhYwogCi0gICAgICAkYWNfcGF0aF9TRURfZm91bmQgJiYgYnJlYWsgMwotICAgIGRv bmUKLSAgZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCi0gIGlmIHRlc3QgLXogIiRhY19j dl9wYXRoX1NFRCI7IHRoZW4KLSAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBzZWQg Y291bGQgYmUgZm91bmQgaW4gXCRQQVRIIiAiJExJTkVOTyIgNQotICBmaQotZWxzZQotICBhY19j dl9wYXRoX1NFRD0kU0VECi1maQogCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX1NFRCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2 X3BhdGhfU0VEIiA+JjY7IH0KLSBTRUQ9IiRhY19jdl9wYXRoX1NFRCIKLSAgcm0gLWYgY29uZnRl c3Quc2VkCisjIFdlIGRlZmluZSwgc2VwYXJhdGVseSwgUFRIUkVBRF9DRkxBR1MsIF9MREZMQUdT IGFuZCBfTElCUworIyBldmVuIHRob3VnaCBjdXJyZW50bHkgd2UgZG9uJ3Qgc2V0IHRoZW0gdmVy eSBzZXBhcmF0ZWx5LgorIyBUaGlzIG1lYW5zIHRoYXQgdGhlIG1ha2VmaWxlcyB3aWxsIG5vdCBu ZWVkIHRvIGNoYW5nZSBpbgorIyB0aGUgZnV0dXJlIGlmIHdlIG1ha2UgdGhlIHRlc3QgbW9yZSBz b3BoaXN0aWNhdGVkLgogCi1hY19leHQ9YwotYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKLWFjX2Nv bXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKLWFj X2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxB R1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCi1hY19jb21waWxlcl9nbnU9JGFjX2N2X2Nf Y29tcGlsZXJfZ251Ci1pZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1nY2MiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9 Z2NjOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRlc3QgLW4g IiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2NjIgotICAgICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZT PSRhc19zYXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIk Q0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAi bm8iID4mNjsgfQotZmkKIAorIyBXZSBpbnZva2UgQVhfUFRIUkVBRF9WQVJTIHdpdGggdGhlIG5h bWUgb2YgYW5vdGhlciBtYWNybworIyB3aGljaCBpcyB0aGVuIGV4cGFuZGVkIG9uY2UgZm9yIGVh Y2ggdmFyaWFibGUuCiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19DQyI7IHRoZW4KLSAg YWNfY3RfQ0M9JENDCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZ2NjIiwgc28gaXQg Y2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBnY2M7IGFjX3dvcmQ9 JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y ICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X0NDK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0 X0NDIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0MiICMgTGV0IHRoZSB1 c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRI X1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAotZG8KLSAgSUZTPSRhc19zYXZlX0lGUwot ICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAn JyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iZ2NjIgotICAgICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZT PSRhc19zYXZlX0lGUwogCi1maQotZmkKLWFjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCi1p ZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQotJGFzX2VjaG8gIiRhY19jdF9D QyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKIAotICBpZiB0ZXN0 ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KLSAgICBDQz0iIgotICBlbHNlCi0gICAgY2FzZSAkY3Jv c3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHBy ZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6 IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30K LWFjX3Rvb2xfd2FybmVkPXllcyA7OwotZXNhYwotICAgIENDPSRhY19jdF9DQwotICBmaQotZWxz ZQotICBDQz0iJGFjX2N2X3Byb2dfQ0MiCi1maQogCi1pZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCi0g ICAgICAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAgICMgRXh0cmFj dCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1jYyIsIHNvIGl0IGNhbiBiZSBh IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1jYzsg YWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj a2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3Jk Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4g OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkQ0Mi OyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3Ig YXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19k aXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl X2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo ZW4KLSAgICBhY19jdl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWNjIgotICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19z YXZlX0lGUwogCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0ZXN0IC1uICIkQ0MiOyB0 aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk Q0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4m NjsgfQotZmkKIAogCi0gIGZpCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICAjIEV4dHJh Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp dGggYXJncy4KLXNldCBkdW1teSBjYzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3By b2dfQ0Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgot ZWxzZQotICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBM ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi0gIGFjX3Byb2dfcmVqZWN0ZWQ9 bm8KLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4g JFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNf ZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9u czsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAk YXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGlm IHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91c3IvdWNiL2NjIjsgdGhl bgotICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCi0gICAgICAgY29udGludWUKLSAgICAgZmkK LSAgICBhY19jdl9wcm9nX0NDPSJjYyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBi cmVhayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKIAotaWYgdGVzdCAk YWNfcHJvZ19yZWplY3RlZCA9IHllczsgdGhlbgotICAjIFdlIGZvdW5kIGEgYm9nb24gaW4gdGhl IHBhdGgsIHNvIG1ha2Ugc3VyZSB3ZSBuZXZlciB1c2UgaXQuCi0gIHNldCBkdW1teSAkYWNfY3Zf cHJvZ19DQwotICBzaGlmdAotICBpZiB0ZXN0ICQjICE9IDA7IHRoZW4KLSAgICAjIFdlIGNob3Nl IGEgZGlmZmVyZW50IGNvbXBpbGVyIGZyb20gdGhlIGJvZ3VzIG9uZS4KLSAgICAjIEhvd2V2ZXIs IGl0IGhhcyB0aGUgc2FtZSBiYXNlbmFtZSwgc28gdGhlIGJvZ29uIHdpbGwgYmUgY2hvc2VuCi0g ICAgIyBmaXJzdCBpZiB3ZSBzZXQgQ0MgdG8ganVzdCB0aGUgYmFzZW5hbWU7IHVzZSB0aGUgZnVs bCBmaWxlIG5hbWUuCi0gICAgc2hpZnQKLSAgICBhY19jdl9wcm9nX0NDPSIkYXNfZGlyLyRhY193 b3JkJHsxKycgJ30kQCIKLSAgZmkKLWZpCi1maQotZmkKLUNDPSRhY19jdl9wcm9nX0NDCi1pZiB0 ZXN0IC1uICIkQ0MiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkQ0MiID4mNQotJGFzX2VjaG8gIiRDQyIgPiY2OyB9Ci1lbHNlCi0gIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0k YXNfZWNobyAibm8iID4mNjsgfQorIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCisKKyMgQ2hlY2sg d2hldGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dp dGh0dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOwog ZmkKIAogCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBpZiB0ZXN0IC1uICIkYWNfdG9v bF9wcmVmaXgiOyB0aGVuCi0gIGZvciBhY19wcm9nIGluIGNsLmV4ZQotICBkbwotICAgICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciLCBzbyBpdCBj YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICRhY190b29sX3ByZWZp eCRhY19wcm9nOyBhY193b3JkPSQyCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9 IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGlmIHRl c3QgLW4gIiRDQyI7IHRoZW4KLSAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBv dmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB UkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVz dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfQ0M9IiRhY190b29sX3ByZWZpeCRhY19wcm9n IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAg ZG9uZQotSUZTPSRhc19zYXZlX0lGUworaWYgdGVzdCAieCRlbmFibGVfZ2l0aHR0cCIgPSAieG5v IjsgdGhlbiA6CiAKLWZpCi1maQotQ0M9JGFjX2N2X3Byb2dfQ0MKLWlmIHRlc3QgLW4gIiRDQyI7 IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDQyIgPiY1Ci0kYXNfZWNobyAiJENDIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIg PiY2OyB9Ci1maQorICAgIGF4X2N2X2dpdGh0dHA9Im4iCiAKK2VsaWYgdGVzdCAieCRlbmFibGVf Z2l0aHR0cCIgPSAieHllcyI7IHRoZW4gOgogCi0gICAgdGVzdCAtbiAiJENDIiAmJiBicmVhawot ICBkb25lCi1maQotaWYgdGVzdCAteiAiJENDIjsgdGhlbgotICBhY19jdF9DQz0kQ0MKLSAgZm9y IGFjX3Byb2cgaW4gY2wuZXhlCi1kbwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRh Y19wcm9nIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1t eSAkYWNfcHJvZzsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mr c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot ICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRh Y19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZl X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwot ICBJRlM9JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAg Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlm IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2Fj X2N0X0NDPSIkYWNfcHJvZyIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVhayAy Ci0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKKyAgICBheF9jdl9naXRodHRw PSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2dpdGh0dHA7IHRoZW4gOgorCisgICAgYXhfY3Zf Z2l0aHR0cD0ibiIKIAogZmkKLWZpCi1hY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQwotaWYg dGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfQ0Mi ID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCitnaXRodHRwPSRheF9j dl9naXRodHRwCiAKIAotICB0ZXN0IC1uICIkYWNfY3RfQ0MiICYmIGJyZWFrCi1kb25lCiAKLSAg aWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCi0gICAgQ0M9IiIKLSAgZWxzZQotICAgIGNh c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczopCi17ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNobyAiJGFzX21lOiBX QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi ID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBDQz0kYWNfY3RfQ0MKLSAg ZmkKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2ZW4uCitpZiB0ZXN0 ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h YmxlX21vbml0b3JzOwogZmkKIAotZmkKIAoraWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0g InhubyI7IHRoZW4gOgogCi10ZXN0IC16ICIkQ0MiICYmIHsgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8g IiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIm5v IGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBcJFBBVEgKLVNlZSBcYGNvbmZpZy5sb2cn IGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAgIGF4X2N2X21vbml0b3JzPSJu IgogCi0jIFByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tcGlsZXIuCi0kYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgQyBjb21waWxl ciB2ZXJzaW9uIiA+JjUKLXNldCBYICRhY19jb21waWxlCi1hY19jb21waWxlcj0kMgotZm9yIGFj X29wdGlvbiBpbiAtLXZlcnNpb24gLXYgLVYgLXF2ZXJzaW9uOyBkbwotICB7IHsgYWNfdHJ5PSIk YWNfY29tcGlsZXIgJGFjX29wdGlvbiA+JjUiCi1jYXNlICIoKCRhY190cnkiIGluCi0gICpcIiog fCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OwotICAqKSBhY190cnlfZWNobz0k YWNfdHJ5OzsKLWVzYWMKLWV2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogJGFjX3RyeV9lY2hvXCIiCi0kYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUK LSAgKGV2YWwgIiRhY19jb21waWxlciAkYWNfb3B0aW9uID4mNSIpIDI+Y29uZnRlc3QuZXJyCi0g IGFjX3N0YXR1cz0kPwotICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgotICAgIHNlZCAn MTBhXAotLi4uIHJlc3Qgb2Ygc3RkZXJyIG91dHB1dCBkZWxldGVkIC4uLgotICAgICAgICAgMTBx JyBjb25mdGVzdC5lcnIgPmNvbmZ0ZXN0LmVyMQotICAgIGNhdCBjb25mdGVzdC5lcjEgPiY1Ci0g IGZpCi0gIHJtIC1mIGNvbmZ0ZXN0LmVyMSBjb25mdGVzdC5lcnIKLSAgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1Ci0gIHRlc3QgJGFj X3N0YXR1cyA9IDA7IH0KLWRvbmUKK2VsaWYgdGVzdCAieCRlbmFibGVfbW9uaXRvcnMiID0gInh5 ZXMiOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVy Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfY29tcGlsZXJfZ251K3NldH0iID0gc2V0 OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0IGNvbmZk ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAq LworICAgIGF4X2N2X21vbml0b3JzPSJ5IgogCi1pbnQKLW1haW4gKCkKLXsKLSNpZm5kZWYgX19H TlVDX18KLSAgICAgICBjaG9rZSBtZQotI2VuZGlmCitlbGlmIHRlc3QgLXogJGF4X2N2X21vbml0 b3JzOyB0aGVuIDoKIAotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3Ry eV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2NvbXBpbGVyX2dudT15ZXMKLWVsc2UK LSAgYWNfY29tcGlsZXJfZ251PW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1hY19jdl9jX2NvbXBpbGVyX2dudT0kYWNf Y29tcGlsZXJfZ251CisgICAgYXhfY3ZfbW9uaXRvcnM9InkiCiAKIGZpCi17ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251 IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQotaWYgdGVzdCAk YWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCi0gIEdDQz15ZXMKLWVsc2UKLSAgR0NDPQotZmkK LWFjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KLWFjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKLXsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciAk Q0MgYWNjZXB0cyAtZyIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2Nl cHRzIC1nLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfZytzZXR9IiA9IHNl dDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX3NhdmVf Y193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZwotICAgYWNfY193ZXJyb3JfZmxhZz15ZXMK LSAgIGFjX2N2X3Byb2dfY2NfZz1ubwotICAgQ0ZMQUdTPSItZyIKLSAgIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KK21v bml0b3JzPSRheF9jdl9tb25pdG9ycwogCi1pbnQKLW1haW4gKCkKLXsKIAotICA7Ci0gIHJldHVy biAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6 Ci0gIGFjX2N2X3Byb2dfY2NfZz15ZXMKLWVsc2UKLSAgQ0ZMQUdTPSIiCi0gICAgICBjYXQgY29u ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4g ICovCiAKLWludAotbWFpbiAoKQoteworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2Fz IGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfdnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu YWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQogCi0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YK LWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKIAotZWxzZQotICBhY19j X3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLQkgQ0ZMQUdTPSItZyIKLQkgY2F0 IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz LmguICAqLworaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CiAKLWludAot bWFpbiAoKQoteworICAgIGF4X2N2X3Z0cG09Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRw bSIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfdnRwbT0ieSIKKworZWxpZiB0ZXN0IC16 ICRheF9jdl92dHBtOyB0aGVuIDoKKworICAgIGF4X2N2X3Z0cG09Im4iCiAKLSAgOwotICByZXR1 cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g OgotICBhY19jdl9wcm9nX2NjX2c9eWVzCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u ZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci1maQotcm0gLWYgY29y ZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICBh Y19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKLWZpCi17ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1 Ci0kYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfZyIgPiY2OyB9Ci1pZiB0ZXN0ICIkYWNfdGVzdF9D RkxBR1MiID0gc2V0OyB0aGVuCi0gIENGTEFHUz0kYWNfc2F2ZV9DRkxBR1MKLWVsaWYgdGVzdCAk YWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVuCi0gIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVu Ci0gICAgQ0ZMQUdTPSItZyAtTzIiCi0gIGVsc2UKLSAgICBDRkxBR1M9Ii1nIgotICBmaQotZWxz ZQotICBpZiB0ZXN0ICIkR0NDIiA9IHllczsgdGhlbgotICAgIENGTEFHUz0iLU8yIgotICBlbHNl Ci0gICAgQ0ZMQUdTPQotICBmaQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRDQyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19jY19jODkrc2V0fSIgPSBzZXQ7IHRoZW4g OgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBhY19jdl9wcm9nX2NjX2M4 OT1ubwotYWNfc2F2ZV9DQz0kQ0MKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0 LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxzdGRhcmcuaD4KLSNp bmNsdWRlIDxzdGRpby5oPgotI2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy9z dGF0Lmg+Ci0vKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVzdHMgYXJlIHN0b2xlbiBmcm9tIFJD UyA1LjcncyBzcmMvY29uZi5zaC4gICovCi1zdHJ1Y3QgYnVmIHsgaW50IHg7IH07Ci1GSUxFICog KCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpOwotc3RhdGljIGNo YXIgKmUgKHAsIGkpCi0gICAgIGNoYXIgKipwOwotICAgICBpbnQgaTsKLXsKLSAgcmV0dXJuIHBb aV07Ci19Ci1zdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykgKGNoYXIgKiosIGludCksIGNoYXIg KipwLCAuLi4pCi17Ci0gIGNoYXIgKnM7Ci0gIHZhX2xpc3QgdjsKLSAgdmFfc3RhcnQgKHYscCk7 Ci0gIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7Ci0gIHZhX2VuZCAodik7Ci0gIHJldHVybiBz OwotfQordnRwbT0kYXhfY3ZfdnRwbQogCi0vKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21lIHNv cnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcwotICAgZnVuY3Rpb24gcHJvdG90 eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRzLgot ICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFkIGFy ZSBzaWxlbnRseSB0cmVhdGVkCi0gICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMgYW4g ZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0Ci0gICBwcm9wZXIgQU5TSSBtb2RlLiAg Q3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCi0gICBh cnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0wIHRv IGdldCBzb21ldGhpbmcKLSAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KLWludCBv c2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CiAKLS8qIElCTSBDIDYgZm9yIEFJ WCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFyYW1l dGVycwotICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwotI2Rl ZmluZSBGT08oeCkgJ3gnCi1pbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6IC0x XTsKIAotaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7Ci1zdHJ1Y3QgczEge2ludCAoKmYpIChp bnQgYSk7fTsKLXN0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OwotaW50IHBhaXJuYW1l cyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBp bnQpLCBpbnQsIGludCk7Ci1pbnQgYXJnYzsKLWNoYXIgKiphcmd2OwotaW50Ci1tYWluICgpCi17 Ci1yZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEpICE9 IGFyZ3ZbMV07Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWZvciBhY19hcmcgaW4gJycg LXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKLQktQWUgIi1BYSAtRF9IUFVY X1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgotZG8KLSAgQ0M9IiRhY19zYXZlX0NDICRh Y19hcmciCi0gIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf Y3ZfcHJvZ19jY19jODk9JGFjX2FyZworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhlbmFwaSB3 YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV94ZW5hcGkrc2V0fSIgPSBzZXQ7IHRoZW4gOgor ICBlbmFibGV2YWw9JGVuYWJsZV94ZW5hcGk7CiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg Y29uZnRlc3QuJGFjX29iamV4dAotICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSAieG5v IiAmJiBicmVhawotZG9uZQotcm0gLWYgY29uZnRlc3QuJGFjX2V4dAotQ0M9JGFjX3NhdmVfQ0MK KworCitpZiB0ZXN0ICJ4JGVuYWJsZV94ZW5hcGkiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhf Y3ZfeGVuYXBpPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hlbmFwaSIgPSAieHllcyI7IHRo ZW4gOgorCisgICAgYXhfY3ZfeGVuYXBpPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hlbmFw aTsgdGhlbiA6CisKKyAgICBheF9jdl94ZW5hcGk9Im4iCiAKIGZpCi0jIEFDX0NBQ0hFX1ZBTAot Y2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KLSAgeCkKLSAgICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQotJGFzX2Vj aG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKLSAgeG5vKQotICAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1Ci0kYXNfZWNo byAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OwotICAqKQotICAgIENDPSIkQ0MgJGFjX2N2X3Byb2df Y2NfYzg5IgotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQotJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4 OSIgPiY2OyB9IDs7Ci1lc2FjCi1pZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87 IHRoZW4gOgoreGVuYXBpPSRheF9jdl94ZW5hcGkKKwogCisKKyMgQ2hlY2sgd2hldGhlciAtLWVu YWJsZS1weXRob250b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9weXRob250b29s cytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3B5dGhvbnRvb2xzOwog ZmkKIAotYWNfZXh0PWMKLWFjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCi1hY19jb21waWxlPSckQ0Mg LWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCi1hY19saW5rPSckQ0Mg LW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0 LiRhY19leHQgJExJQlMgPiY1JwotYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2du dQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdo ZXRoZXIgbG4gLXMgd29ya3MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBsbiAt cyB3b3Jrcy4uLiAiID4mNjsgfQotTE5fUz0kYXNfbG5fcwotaWYgdGVzdCAiJExOX1MiID0gImxu IC1zIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8sIHVzaW5nICRMTl9TIiA+ JjUKLSRhc19lY2hvICJubywgdXNpbmcgJExOX1MiID4mNjsgfQoraWYgdGVzdCAieCRlbmFibGVf cHl0aG9udG9vbHMiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfcHl0aG9udG9vbHM9Im4i CisKK2VsaWYgdGVzdCAieCRlbmFibGVfcHl0aG9udG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKwor ICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3B5dGhvbnRv b2xzOyB0aGVuIDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJ5IgorCiBmaQorcHl0aG9udG9v bHM9JGF4X2N2X3B5dGhvbnRvb2xzCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKSIgPiY1 Ci0kYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwkKE1BS0Up Li4uICIgPiY2OyB9Ci1zZXQgeCAke01BS0UtbWFrZX0KLWFjX21ha2U9YCRhc19lY2hvICIkMiIg fCBzZWQgJ3MvKy9wL2c7IHMvW15hLXpBLVowLTlfXS9fL2cnYAotaWYgZXZhbCAidGVzdCBcIlwk e2FjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCtzZXR9XCIiID0gc2V0OyB0aGVuIDoKLSAg JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2F0ID5jb25mdGVzdC5tYWtlIDw8 XF9BQ0VPRgotU0hFTEwgPSAvYmluL3NoCi1hbGw6Ci0JQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBA QCUlJScKLV9BQ0VPRgotIyBHTlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRl cmluZyAuLi4iLCB3aGljaCB3b3VsZCBjb25mdXNlIHVzLgotY2FzZSBgJHtNQUtFLW1ha2V9IC1m IGNvbmZ0ZXN0Lm1ha2UgMj4vZGV2L251bGxgIGluCi0gICpAQEAlJSU9Pyo9QEBAJSUlKikKLSAg ICBldmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OwotICAqKQotICAgIGV2 YWwgYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0PW5vOzsKLWVzYWMKLXJtIC1mIGNvbmZ0 ZXN0Lm1ha2UKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2 ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAg ZW5hYmxldmFsPSRlbmFibGVfb2NhbWx0b29sczsKIGZpCi1pZiBldmFsIHRlc3QgXCRhY19jdl9w cm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1Ci0kYXNfZWNobyAieWVzIiA+ JjY7IH0KLSAgU0VUX01BS0U9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICBTRVRf TUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29s cyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRl c3QgIngkZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29j YW1sdG9vbHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisK KyAgICBheF9jdl9vY2FtbHRvb2xzPSJ5IgorCiBmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0 b29scwogCi0jIEZpbmQgYSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJv Z3JhbSAoZmFzdGVyKSwKLSMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBC dXQgYXZvaWQgdGhlIGJyb2tlbiBvcgotIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6Ci0jIFN5c1Yg L2V0Yy9pbnN0YWxsLCAvdXNyL3NiaW4vaW5zdGFsbAotIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxs Ci0jIElSSVggL3NiaW4vaW5zdGFsbAotIyBBSVggL2Jpbi9pbnN0YWxsCi0jIEFtaWdhT1MgL0Mv aW5zdGFsbCwgd2hpY2ggaW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKLSMgQUlY IDQgL3Vzci9iaW4vaW5zdGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBm bGFnCi0jIEFGUyAvdXNyL2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4 aXN0ZW50IGFyZ3MKLSMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2Ug dGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiIKLSMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3 aGljaCBoYXMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYwotIyAuL2luc3RhbGwsIHdo aWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2gu Ci0jIFJlamVjdCBpbnN0YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUg ZmlsZXMuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciBhIEJTRC1jb21wYXRpYmxlIGluc3RhbGwiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQotaWYgdGVzdCAteiAiJElO U1RBTEwiOyB0aGVuCi1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsg dGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFzX3NhdmVfSUZT PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElG Uz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICAjIEFj Y291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50 cy4KLWNhc2UgJGFzX2Rpci8gaW4gIygoCi0gIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKLSAgL2V0 Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmlu LyogfCBcCi0gID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11J TlNUQUxMW1xcL10qIHwgXAotICAvdXNyL3VjYi8qICkgOzsKLSAgKikKLSAgICAjIE9TRjEgYW5k IFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgotICAgICMgRG9u J3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9v dAotICAgICMgYnkgZGVmYXVsdC4KLSAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0 IGluc3RhbGw7IGRvCi0gICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KLQlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVu Ci0JICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIGRzcG1zZyAiJGFz X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCi0JICAgICMg QUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4K LQkgICAgOgotCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgotCSAgICBncmVwIHB3 cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu Ci0JICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1 cy0tZG9uJ3QgdXNlLgotCSAgICA6Ci0JICBlbHNlCi0JICAgIHJtIC1yZiBjb25mdGVzdC5vbmUg Y29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgotCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQot CSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bwotCSAgICBta2RpciBjb25mdGVzdC5kaXIKLQkg ICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25m dGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKLQkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0 Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3Qu ZGlyL2NvbmZ0ZXN0Lm9uZSAmJgotCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0 LnR3bwotCSAgICB0aGVuCi0JICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19w cm9nJGFjX2V4ZWNfZXh0IC1jIgotCSAgICAgIGJyZWFrIDMKLQkgICAgZmkKLQkgIGZpCi0JZmkK LSAgICAgIGRvbmUKLSAgICBkb25lCi0gICAgOzsKLWVzYWMKIAotICBkb25lCi1JRlM9JGFzX3Nh dmVfSUZTCiAKLXJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgor IyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW1pbml0ZXJtIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7 ZW5hYmxlX21pbml0ZXJtK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVf bWluaXRlcm07CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX21pbml0ZXJtIiA9ICJ4bm8iOyB0 aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX21p bml0ZXJtIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9taW5pdGVybT0ieSIKKworZWxp ZiB0ZXN0IC16ICRheF9jdl9taW5pdGVybTsgdGhlbiA6CisKKyAgICBheF9jdl9taW5pdGVybT0i biIKIAogZmkKLSAgaWYgdGVzdCAiJHthY19jdl9wYXRoX2luc3RhbGwrc2V0fSIgPSBzZXQ7IHRo ZW4KLSAgICBJTlNUQUxMPSRhY19jdl9wYXRoX2luc3RhbGwKLSAgZWxzZQotICAgICMgQXMgYSBs YXN0IHJlc29ydCwgdXNlIHRoZSBzbG93IHNoZWxsIHNjcmlwdC4gIERvbid0IGNhY2hlIGEKLSAg ICAjIHZhbHVlIGZvciBJTlNUQUxMIHdpdGhpbiBhIHNvdXJjZSBkaXJlY3RvcnksIGJlY2F1c2Ug dGhhdCB3aWxsCi0gICAgIyBicmVhayBvdGhlciBwYWNrYWdlcyB1c2luZyB0aGUgY2FjaGUgaWYg dGhhdCBkaXJlY3RvcnkgaXMKLSAgICAjIHJlbW92ZWQsIG9yIGlmIHRoZSB2YWx1ZSBpcyBhIHJl bGF0aXZlIG5hbWUuCi0gICAgSU5TVEFMTD0kYWNfaW5zdGFsbF9zaAotICBmaQorbWluaXRlcm09 JGF4X2N2X21pbml0ZXJtCisKKworCisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbG9tb3VudCB3 YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9sb21vdW50K3NldH0iID0gc2V0OyB0aGVuIDoK KyAgZW5hYmxldmFsPSRlbmFibGVfbG9tb3VudDsKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElOU1RBTEwiID4mNQotJGFzX2VjaG8gIiRJTlNU QUxMIiA+JjY7IH0KIAotIyBVc2UgdGVzdCAteiBiZWNhdXNlIFN1bk9TNCBzaCBtaXNoYW5kbGVz IGJyYWNlcyBpbiAke3Zhci12YWx9LgotIyBJdCB0aGlua3MgdGhlIGZpcnN0IGNsb3NlIGJyYWNl IGVuZHMgdGhlIHZhcmlhYmxlIHN1YnN0aXR1dGlvbi4KLXRlc3QgLXogIiRJTlNUQUxMX1BST0dS QU0iICYmIElOU1RBTExfUFJPR1JBTT0nJHtJTlNUQUxMfScKIAotdGVzdCAteiAiJElOU1RBTExf U0NSSVBUIiAmJiBJTlNUQUxMX1NDUklQVD0nJHtJTlNUQUxMfScKK2lmIHRlc3QgIngkZW5hYmxl X2xvbW91bnQiID0gInhubyI7IHRoZW4gOgogCi10ZXN0IC16ICIkSU5TVEFMTF9EQVRBIiAmJiBJ TlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworICAgIGF4X2N2X2xvbW91bnQ9Im4iCiAK LSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiYmlzb24iLCBzbyBpdCBjYW4gYmUgYSBwcm9n cmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGJpc29uOyBhY193b3JkPSQyCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcGF0aF9CSVNPTitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJEJJU09OIGluCi0gIFtcXC9dKiB8ID86W1xc L10qKQotICBhY19jdl9wYXRoX0JJU09OPSIkQklTT04iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJ RlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFzX3Nh dmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNf ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JJU09OPSIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJy ZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworZWxpZiB0ZXN0ICJ4 JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9sb21vdW50PSJ5 IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2xvbW91bnQ7IHRoZW4gOgorCisgICAgYXhfY3ZfbG9t b3VudD0ibiIKIAotICA7OwotZXNhYwogZmkKLUJJU09OPSRhY19jdl9wYXRoX0JJU09OCi1pZiB0 ZXN0IC1uICIkQklTT04iOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkQklTT04iID4mNQotJGFzX2VjaG8gIiRCSVNPTiIgPiY2OyB9Ci1l bHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu byIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQorbG9tb3VudD0kYXhfY3ZfbG9tb3VudAorCisK KworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLW92bWYgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtl bmFibGVfb3ZtZitzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX292bWY7 CiBmaQogCiAKLSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBi ZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgot eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFj X3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9 Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGNhc2UgJEZMRVggaW4KLSAgW1xcL10qIHwg PzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJy aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZT OyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9JGFz X3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4 ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAt ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAg YnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCitpZiB0ZXN0ICJ4 JGVuYWJsZV9vdm1mIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X292bWY9Im4iCisKK2Vs aWYgdGVzdCAieCRlbmFibGVfb3ZtZiIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3Zfb3Zt Zj0ieSIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9vdm1mOyB0aGVuIDoKKworICAgIGF4X2N2X292 bWY9Im4iCiAKLSAgOzsKLWVzYWMKIGZpCi1GTEVYPSRhY19jdl9wYXRoX0ZMRVgKLWlmIHRlc3Qg LW4gIiRGTEVYIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJEZMRVgiID4mNQotJGFzX2VjaG8gIiRGTEVYIiA+JjY7IH0KLWVsc2UKLSAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK LSRhc19lY2hvICJubyIgPiY2OyB9Citvdm1mPSRheF9jdl9vdm1mCisKKworCisjIENoZWNrIHdo ZXRoZXIgLS1lbmFibGUtcm9tYmlvcyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9yb21i aW9zK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcm9tYmlvczsKIGZp CiAKIAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwZXJsIiwgc28gaXQgY2FuIGJlIGEg cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBwZXJsOyBhY193b3JkPSQyCi17ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y ZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfcGF0aF9QRVJMK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgY2FzZSAkUEVSTCBpbgotICBbXFwvXSogfCA/Oltc XC9dKikKLSAgYWNfY3ZfcGF0aF9QRVJMPSIkUEVSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg dGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElG Uz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2 ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19l eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfUEVSTD0iJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIKLSAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKLSAgICBicmVh ayAyCi0gIGZpCi1kb25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK2lmIHRlc3QgIngkZW5h YmxlX3JvbWJpb3MiID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3Zfcm9tYmlvcz0ibiIKKwor ZWxpZiB0ZXN0ICJ4JGVuYWJsZV9yb21iaW9zIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9j dl9yb21iaW9zPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3JvbWJpb3M7IHRoZW4gOgorCisg ICAgYXhfY3Zfcm9tYmlvcz0ieSIKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QRVJMIiAmJiBh Y19jdl9wYXRoX1BFUkw9Im5vIgotICA7OwotZXNhYwogZmkKLVBFUkw9JGFjX2N2X3BhdGhfUEVS TAotaWYgdGVzdCAtbiAiJFBFUkwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1Ci0kYXNfZWNobyAiJFBFUkwiID4mNjsg fQotZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KK3JvbWJpb3M9JGF4X2N2X3JvbWJpb3MK KworCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1zZWFiaW9zIHdhcyBnaXZlbi4KK2lmIHRl c3QgIiR7ZW5hYmxlX3NlYWJpb3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVu YWJsZV9zZWFiaW9zOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9zZWFiaW9zIiA9ICJ4bm8i OyB0aGVuIDoKKworICAgIGF4X2N2X3NlYWJpb3M9Im4iCisKK2VsaWYgdGVzdCAieCRlbmFibGVf c2VhYmlvcyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3Zfc2VhYmlvcz0ieSIKKworZWxp ZiB0ZXN0IC16ICRheF9jdl9zZWFiaW9zOyB0aGVuIDoKKworICAgIGF4X2N2X3NlYWJpb3M9Inki CisKK2ZpCitzZWFiaW9zPSRheF9jdl9zZWFiaW9zCisKKworCisjIENoZWNrIHdoZXRoZXIgLS1l bmFibGUtZGVidWcgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfZGVidWcrc2V0fSIgPSBz ZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9kZWJ1ZzsKK2ZpCisKKworaWYgdGVzdCAi eCRlbmFibGVfZGVidWciID0gInhubyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9Im4iCisK K2VsaWYgdGVzdCAieCRlbmFibGVfZGVidWciID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2 X2RlYnVnPSJ5IgorCitlbGlmIHRlc3QgLXogJGF4X2N2X2RlYnVnOyB0aGVuIDoKKworICAgIGF4 X2N2X2RlYnVnPSJ5IgorCiBmaQorZGVidWc9JGF4X2N2X2RlYnVnCisKKworCisKKworCisKKwor Zm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVTCitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0i IC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBpbiAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJF UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lO Q0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1MrPSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRm bGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIK K2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdTICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitM REZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZMQUdTICRBUFBFTkRfTERGTEFHUyIKKworCiAK IAotaWYgdGVzdCB4IiR7UEVSTH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8g IlVuYWJsZSB0byBmaW5kIHBlcmwsIHBsZWFzZSBpbnN0YWxsIHBlcmwiICIkTElORU5PIiA1Ci1m aQotaWYgdGVzdCAieCR4YXBpIiA9ICJ4eSI7IHRoZW4gOgogCi0gICAgIyBFeHRyYWN0IHRoZSBm aXJzdCB3b3JkIG9mICJjdXJsLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3 aXRoIGFyZ3MuCi1zZXQgZHVtbXkgY3VybC1jb25maWc7IGFjX3dvcmQ9JDIKKworCisKKworCisK KworCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQ UEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRh Y19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRD UFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVy X2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKK2lmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7 IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fWdj YyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHth Y190b29sX3ByZWZpeH1nY2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX0NV Ukwrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0iID0g c2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAk Q1VSTCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9DVVJMPSIkQ1VSTCIg IyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICop Ci0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAi JENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgog Zm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIk YXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0 YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9 OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9DVVJMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9Z2NjIgogICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTUxNzEsNDQgKzI2NTUsMzkgQEAg ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf Q1VSTCIgJiYgYWNfY3ZfcGF0aF9DVVJMPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1DVVJMPSRhY19j dl9wYXRoX0NVUkwKLWlmIHRlc3QgLW4gIiRDVVJMIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENVUkwiID4mNQotJGFzX2VjaG8gIiRD VVJMIiA+JjY7IH0KK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhl bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEND IiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7 IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7Q1VSTH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5f ZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29uZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJs LWNvbmZpZyIgIiRMSU5FTk8iIDUKIGZpCi0gICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m ICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z ZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9n X0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m ICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15 IGdjYzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRh Y193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfWE1MK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9DQytzZXR9IiA9IHNldDsgdGhl biA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJFhNTCBpbgot ICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1 c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZl X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7 IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBv dmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBB UkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVz dCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193 b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfWE1MPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01MjE2LDM5ICsyNjk1LDQzIEBAIGRvbmUK ICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIg JiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgotICA7OwotZXNhYwogZmkKLVhNTD0kYWNfY3ZfcGF0aF9Y TUwKLWlmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkWE1MIiA+JjUKLSRhc19lY2hvICIkWE1MIiA+JjY7IH0K K2ZpCithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19jdF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0ND IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIkYWNfY3RfQ0MiID4mNjsgfQogZWxzZQogICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQog JGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLQotaWYgdGVzdCB4IiR7WE1MfSIgPT0geCJubyIK LXRoZW4KLSAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sMi1jb25maWcsIHBs ZWFzZSBpbnN0YWxsIHhtbDItY29uZmlnIiAiJExJTkVOTyIgNQotZmkKLQorICBpZiB0ZXN0ICJ4 JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAgICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3Nf Y29tcGlsaW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZp eGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVz aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2Fj X3Rvb2xfd2FybmVkPXllcyA7OworZXNhYworICAgIENDPSRhY19jdF9DQworICBmaQorZWxzZQor ICBDQz0iJGFjX2N2X3Byb2dfQ0MiCiBmaQotaWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7 IHRoZW4gOgogCi0gICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMKLSAgaWYgdGVzdCAtbiAiJGFj X3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf dG9vbF9wcmVmaXh9b2NhbWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KLXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoraWYgdGVz dCAteiAiJENDIjsgdGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7 IHRoZW4KKyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9 Y2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7 YWNfdG9vbF9wcmVmaXh9Y2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09D QU1MQytzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfQ0Mrc2V0fSIg PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0 ZXN0IC1uICIkT0NBTUxDIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MQz0iJE9DQU1MQyIgIyBM ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4K KyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K IGVsc2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIg aW4gJFBBVEgKQEAgLTUyNTcsNyArMjc0MCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYm IGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu c2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAg ICBhY19jdl9wcm9nX09DQU1MQz0iJHthY190b29sX3ByZWZpeH1vY2FtbGMiCisgICAgYWNfY3Zf cHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK ICAgICBicmVhayAyCiAgIGZpCkBAIC01MjY3LDI5ICsyNzUwLDMwIEBAIElGUz0kYXNfc2F2ZV9J RlMKIAogZmkKIGZpCi1PQ0FNTEM9JGFjX2N2X3Byb2dfT0NBTUxDCi1pZiB0ZXN0IC1uICIkT0NB TUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJE9DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MQyIgPiY2OyB9CitDQz0kYWNfY3Zf cHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsg fQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAorICBmaQogZmkKLWlmIHRl c3QgLXogIiRhY19jdl9wcm9nX09DQU1MQyI7IHRoZW4KLSAgYWNfY3RfT0NBTUxDPSRPQ0FNTEMK LSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMiLCBzbyBpdCBjYW4gYmUgYSBw cm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sYzsgYWNfd29yZD0kMgoraWYg dGVzdCAteiAiJENDIjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImNjIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjYzsgYWNf d29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u ICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DQytzZXR9IiA9IHNldDsgdGhlbiA6CiAg ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9P Q0FNTEMiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNfY3RfT0NBTUxDIiAj IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhl bgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0 LgogZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwpAQCAtNTI5Nyw3ICsyNzgxLDEx IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNf ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0i b2NhbWxjIgorICAgIGlmIHRlc3QgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID0gIi91 c3IvdWNiL2NjIjsgdGhlbgorICAgICAgIGFjX3Byb2dfcmVqZWN0ZWQ9eWVzCisgICAgICAgY29u dGludWUKKyAgICAgZmkKKyAgICBhY19jdl9wcm9nX0NDPSJjYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01MzA1LDYxICsyNzkzLDQ0IEBAIGRvbmUK ICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0g eWVzOyB0aGVuCisgICMgV2UgZm91bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJl IHdlIG5ldmVyIHVzZSBpdC4KKyAgc2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0Cisg IGlmIHRlc3QgJCMgIT0gMDsgdGhlbgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGls ZXIgZnJvbSB0aGUgYm9ndXMgb25lLgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJh c2VuYW1lLCBzbyB0aGUgYm9nb24gd2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNl dCBDQyB0byBqdXN0IHRoZSBiYXNlbmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBz aGlmdAorICAgIGFjX2N2X3Byb2dfQ0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBm aQogZmkKIGZpCi1hY19jdF9PQ0FNTEM9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDCi1pZiB0ZXN0 IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N0 X09DQU1MQyIgPiY2OyB9CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7 IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIg PiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxDIiA9IHg7IHRoZW4KLSAgICBP Q0FNTEM9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dh cm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0 IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBw cmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVkPXllcyA7Owot ZXNhYwotICAgIE9DQU1MQz0kYWNfY3RfT0NBTUxDCi0gIGZpCi1lbHNlCi0gIE9DQU1MQz0iJGFj X2N2X3Byb2dfT0NBTUxDIgotZmkKLQotCi0gIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJubyI7IHRo ZW4KLSAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv biogKlwoLipcKSR8XDF8cCdgCi0gICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlzICRPQ0FNTFZFUlNJT04iID4mNQotJGFz X2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTiIgPiY2OyB9Ci0gICAgICMgSWYg T0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKLSAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0 aGVuCi0gICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NB TUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAotICAgICBlbHNlCi0gICAgICAgIHsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ0FNTExJQiBwcmV2 aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQotJGFzX2VjaG8gIk9DQU1MTElCIHByZXZp b3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9Ci0gICAgIGZpCi0gICAgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCBsaWJyYXJ5IHBh dGggaXMgJE9DQU1MTElCIiA+JjUKLSRhc19lY2hvICJPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9D QU1MTElCIiA+JjY7IH0KLQotCiAKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdAotICAg ICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmly c3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9w dDsgYWNfd29yZD0kMgorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAtbiAi JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8KKyAg ICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9nIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNfdG9v bF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NB TUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9nX0NDK3NldH0i ID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYg dGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MT1BUPSIkT0NBTUxP UFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0ZXN0IC1uICIkQ0Mi OyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCiBlbHNlCiBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3Ig YXNfZGlyIGluICRQQVRICkBAIC01MzY4LDcgKzI4MzksNyBAQCBkbwogICB0ZXN0IC16ICIkYXNf ZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs ZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0 aGVuCi0gICAgYWNfY3ZfcHJvZ19PQ0FNTE9QVD0iJHthY190b29sX3ByZWZpeH1vY2FtbG9wdCIK KyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIKICAgICAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01Mzc4LDI4ICsyODQ5LDMyIEBA IElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1PQ0FNTE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9Q VAotaWYgdGVzdCAtbiAiJE9DQU1MT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BUIiA+JjUKLSRhc19lY2hvICIkT0NB TUxPUFQiID4mNjsgfQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIg PiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9 CiBmaQogCiAKKyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKIGZpCi1pZiB0ZXN0 IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1M T1BUCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3Jk PSQyCitpZiB0ZXN0IC16ICIkQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJv ZyBpbiBjbC5leGUKK2RvCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ci LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19w cm9nOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtz ZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfQ0Mrc2V0fSIg PSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0 ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxP UFQ9IiRhY19jdF9PQ0FNTE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCisg IGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFj X2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKQEAgLTU0 MDgsNyArMjg4Myw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAg Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlm IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2Fj X2N0X09DQU1MT1BUPSJvY2FtbG9wdCIKKyAgICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfcHJv ZyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01NDE2 LDE5ICsyODkxLDIzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCi1maQotZmkK LWFjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCi1pZiB0ZXN0IC1uICIk YWNfY3RfT0NBTUxPUFQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQotJGFzX2VjaG8gIiRhY19jdF9P Q0FNTE9QVCIgPiY2OyB9CitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitp ZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9D QyIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0 ICJ4JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE9QVD0ibm8iCisKKyAgdGVz dCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0Mi ID0geDsgdGhlbgorICAgIENDPSIiCiAgIGVsc2UKICAgICBjYXNlICRjcm9zc19jb21waWxpbmc6 JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNTQzNiwzOTYgKzI5MTUsNjQ5IEBAIHllczop CiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4 ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CiBhY190b29sX3dhcm5lZD15ZXMgOzsKIGVzYWMK LSAgICBPQ0FNTE9QVD0kYWNfY3RfT0NBTUxPUFQKKyAgICBDQz0kYWNfY3RfQ0MKICAgZmkKLWVs c2UKLSAgT0NBTUxPUFQ9IiRhY19jdl9wcm9nX09DQU1MT1BUIgogZmkKIAotICAgICBPQ0FNTEJF U1Q9Ynl0ZQotICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5vIjsgdGhlbgotCXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogQ2Fubm90IGZpbmQgb2Nh bWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0aW9uIG9ubHkuIiA+JjUKLSRhc19lY2hvICIkYXNfbWU6 IFdBUk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5 LiIgPiYyO30KLSAgICAgZWxzZQotCVRNUFZFUlNJT049YCRPQ0FNTE9QVCAtdiB8IHNlZCAtbiAt ZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKLQlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIg IT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgotCSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2Nh bWxvcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9tIG9j YW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLiIgPiY2OyB9Ci0JICAgIE9DQU1MT1BUPW5vCi0JZWxz ZQotCSAgICBPQ0FNTEJFU1Q9b3B0CitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIg PiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19m bl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2Vl IFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisKKyMgUHJv dmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24i ID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNfb3B0aW9uIGlu IC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRhY19jb21waWxl ciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAq XFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7Owor ZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAk YWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAi JGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVz PSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcxMGFcCisuLi4g cmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEnIGNvbmZ0ZXN0 LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgZmkKKyAgcm0g LWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfQorZG9uZQorCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0 dXJuIDA7Cit9CitfQUNFT0YKK2FjX2NsZWFuX2ZpbGVzX3NhdmU9JGFjX2NsZWFuX2ZpbGVzCith Y19jbGVhbl9maWxlcz0iJGFjX2NsZWFuX2ZpbGVzIGEub3V0IGEub3V0LmRTWU0gYS5leGUgYi5v dXQiCisjIFRyeSB0byBjcmVhdGUgYW4gZXhlY3V0YWJsZSB3aXRob3V0IC1vIGZpcnN0LCBkaXNy ZWdhcmQgYS5vdXQuCisjIEl0IHdpbGwgaGVscCB1cyBkaWFnbm9zZSBicm9rZW4gY29tcGlsZXJz LCBhbmQgZmluZGluZyBvdXQgYW4gaW50dWl0aW9uCisjIG9mIGV4ZWV4dC4KK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21w aWxlciB3b3JrcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBp bGVyIHdvcmtzLi4uICIgPiY2OyB9CithY19saW5rX2RlZmF1bHQ9YCRhc19lY2hvICIkYWNfbGlu ayIgfCBzZWQgJ3MvIC1vICpjb25mdGVzdFteIF0qLy8nYAorCisjIFRoZSBwb3NzaWJsZSBvdXRw dXQgZmlsZXM6CithY19maWxlcz0iYS5vdXQgY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGEuZXhlIGFf b3V0LmV4ZSBiLm91dCBjb25mdGVzdC4qIgorCithY19ybWZpbGVzPQorZm9yIGFjX2ZpbGUgaW4g JGFjX2ZpbGVzCitkbworICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29m ZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8 ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwgKi5vYmogKSA7OworICAgICogKSBhY19ybWZpbGVzPSIk YWNfcm1maWxlcyAkYWNfZmlsZSI7OworICBlc2FjCitkb25lCitybSAtZiAkYWNfcm1maWxlcwor CitpZiB7IHsgYWNfdHJ5PSIkYWNfbGlua19kZWZhdWx0IgorY2FzZSAiKCgkYWNfdHJ5IiBpbgor ICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5 X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7 IH0gPiY1CisgIChldmFsICIkYWNfbGlua19kZWZhdWx0IikgMj4mNQorICBhY19zdGF0dXM9JD8K KyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1 cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4gOgorICAjIEF1dG9jb25mLTIu MTMgY291bGQgc2V0IHRoZSBhY19jdl9leGVleHQgdmFyaWFibGUgdG8gYG5vJy4KKyMgU28gaWdu b3JlIGEgdmFsdWUgb2YgYG5vJywgb3RoZXJ3aXNlIHRoaXMgd291bGQgbGVhZCB0byBgRVhFRVhU ID0gbm8nCisjIGluIGEgTWFrZWZpbGUuICBXZSBzaG91bGQgbm90IG92ZXJyaWRlIGFjX2N2X2V4 ZWV4dCBpZiBpdCB3YXMgY2FjaGVkLAorIyBzbyB0aGF0IHRoZSB1c2VyIGNhbiBzaG9ydC1jaXJj dWl0IHRoaXMgdGVzdCBmb3IgY29tcGlsZXJzIHVua25vd24gdG8KKyMgQXV0b2NvbmYuCitmb3Ig YWNfZmlsZSBpbiAkYWNfZmlsZXMgJycKK2RvCisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250 aW51ZQorICBjYXNlICRhY19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRz IHwgKi5kIHwgKi5wZGIgfCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwg Ki5kU1lNIHwgKi5vIHwgKi5vYmogKQorCTs7CisgICAgW2FiXS5vdXQgKQorCSMgV2UgZm91bmQg dGhlIGRlZmF1bHQgZXhlY3V0YWJsZSwgYnV0IGV4ZWV4dD0nJyBpcyBtb3N0CisJIyBjZXJ0YWlu bHkgcmlnaHQuCisJYnJlYWs7OworICAgICouKiApCisJaWYgdGVzdCAiJHthY19jdl9leGVleHQr c2V0fSIgPSBzZXQgJiYgdGVzdCAiJGFjX2N2X2V4ZWV4dCIgIT0gbm87CisJdGhlbiA6OyBlbHNl CisJICAgYWNfY3ZfZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCiAJ ZmkKLSAgICAgZmkKKwkjIFdlIHNldCBhY19jdl9leGVleHQgaGVyZSBiZWNhdXNlIHRoZSBsYXRl ciB0ZXN0IGZvciBpdCBpcyBub3QKKwkjIHNhZmU6IGNyb3NzIGNvbXBpbGVycyBtYXkgbm90IGFk ZCB0aGUgc3VmZml4IGlmIGdpdmVuIGFuIGAtbycKKwkjIGFyZ3VtZW50LCBzbyB3ZSBtYXkgbmVl ZCB0byBrbm93IGl0IGF0IHRoYXQgcG9pbnQgYWxyZWFkeS4KKwkjIEV2ZW4gaWYgdGhpcyBzZWN0 aW9uIGxvb2tzIGNydWZ0eTogaXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YKKwkjIGFjdHVhbGx5IHdv cmtpbmcuCisJYnJlYWs7OworICAgICogKQorCWJyZWFrOzsKKyAgZXNhYworZG9uZQordGVzdCAi JGFjX2N2X2V4ZWV4dCIgPSBubyAmJiBhY19jdl9leGVleHQ9CisKK2Vsc2UKKyAgYWNfZmlsZT0n JworZmkKK2lmIHRlc3QgLXogIiRhY19maWxlIjsgdGhlbiA6CisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m NjsgfQorJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3Mv Xi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKK3sgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRh c19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgNzcgIkMgY29t cGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcworU2VlIFxgY29uZmlnLmxvZycgZm9yIG1v cmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2 OyB9CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBmb3IgQyBjb21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUiID4mNQorJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRwdXQgZmlsZSBuYW1lLi4uICIg PiY2OyB9Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhY19maWxlIiA+JjY7IH0KK2FjX2V4ZWV4dD0kYWNf Y3ZfZXhlZXh0CisKK3JtIC1mIC1yIGEub3V0IGEub3V0LmRTWU0gYS5leGUgY29uZnRlc3QkYWNf Y3ZfZXhlZXh0IGIub3V0CithY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2ZQoreyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3VmZml4 IG9mIGV4ZWN1dGFibGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Yg ZXhlY3V0YWJsZXMuLi4gIiA+JjY7IH0KK2lmIHsgeyBhY190cnk9IiRhY19saW5rIgorY2FzZSAi KCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5 OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJc IlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8g IiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGluayIpIDI+JjUKKyAgYWNfc3Rh dHVzPSQ/CisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9ICRh Y19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9OyB0aGVuIDoKKyAgIyBJZiBi b3RoIGBjb25mdGVzdC5leGUnIGFuZCBgY29uZnRlc3QnIGFyZSBgcHJlc2VudCcgKHdlbGwsIG9i c2VydmFibGUpCisjIGNhdGNoIGBjb25mdGVzdC5leGUnLiAgRm9yIGluc3RhbmNlIHdpdGggQ3ln d2luLCBgbHMgY29uZnRlc3QnIHdpbGwKKyMgd29yayBwcm9wZXJseSAoaS5lLiwgcmVmZXIgdG8g YGNvbmZ0ZXN0LmV4ZScpLCB3aGlsZSBpdCB3b24ndCB3aXRoCisjIGBybScuCitmb3IgYWNfZmls ZSBpbiBjb25mdGVzdC5leGUgY29uZnRlc3QgY29uZnRlc3QuKjsgZG8KKyAgdGVzdCAtZiAiJGFj X2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAq Lnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICou bWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9iaiApIDs7CisgICAgKi4qICkgYWNfY3Zf ZXhlZXh0PWBleHByICIkYWNfZmlsZSIgOiAnW14uXSpcKFwuLipcKSdgCisJICBicmVhazs7Cisg ICAgKiApIGJyZWFrOzsKKyAgZXNhYworZG9uZQorZWxzZQorICB7IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2YgZXhlY3V0YWJsZXM6IGNhbm5vdCBjb21waWxlIGFu ZCBsaW5rCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNSA7 IH0KK2ZpCitybSAtZiBjb25mdGVzdCBjb25mdGVzdCRhY19jdl9leGVleHQKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUK KyRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7IH0KIAorcm0gLWYgY29uZnRlc3QuJGFjX2V4 dAorRVhFRVhUPSRhY19jdl9leGVleHQKK2FjX2V4ZWV4dD0kRVhFRVhUCitjYXQgY29uZmRlZnMu aCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisj aW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQoreworRklMRSAqZiA9IGZvcGVuICgiY29u ZnRlc3Qub3V0IiwgInciKTsKKyByZXR1cm4gZmVycm9yIChmKSB8fCBmY2xvc2UgKGYpICE9IDA7 CiAKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVh bl9maWxlcyBjb25mdGVzdC5vdXQiCisjIENoZWNrIHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1Y2Vz IGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBub3QsIGVpdGhlcgorIyB0aGUgY29tcGlsZXIg aXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxlLgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmci ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5n Li4uICIgPiY2OyB9CitpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiAhPSB5ZXM7IHRoZW4KKyAg eyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAq IHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5 OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2 YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0 YXR1cyA9IDA7IH0KKyAgaWYgeyBhY190cnk9Jy4vY29uZnRlc3QkYWNfY3ZfZXhlZXh0JworICB7 IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hv PVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3Ry eV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgor JGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQor ICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog XCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4K KyAgICBjcm9zc19jb21waWxpbmc9bm8KKyAgZWxzZQorICAgIGlmIHRlc3QgIiRjcm9zc19jb21w aWxpbmciID0gbWF5YmU7IHRoZW4KKwljcm9zc19jb21waWxpbmc9eWVzCisgICAgZWxzZQorCXsg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNf cHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7 fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4gQyBjb21waWxlZCBwcm9ncmFtcy4KK0lmIHlv dSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2UgXGAtLWhvc3QnLgorU2VlIFxgY29uZmlnLmxv ZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CisgICAgZmkKKyAgZmkKK2ZpCit7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGNyb3NzX2Nv bXBpbGluZyIgPiY1CiskYXNfZWNobyAiJGNyb3NzX2NvbXBpbGluZyIgPiY2OyB9CiAKLSAgICAg IyBjaGVja2luZyBmb3Igb2NhbWxjLm9wdAotICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVm aXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZp eH1vY2FtbGMub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNl dCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+ JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9wcm9nX09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitybSAtZiBj b25mdGVzdC4kYWNfZXh0IGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBjb25mdGVzdC5vdXQKK2FjX2Ns ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzIiA+JjUK KyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzLi4uICIgPiY2 OyB9CitpZiB0ZXN0ICIke2FjX2N2X29iamV4dCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQi OyB0aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIkT0NBTUxDRE9UT1BUIiAjIExldCB0 aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0k UEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9J RlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQg aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNf ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUPSIke2Fj X3Rvb2xfcHJlZml4fW9jYW1sYy5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0gICAg YnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIGNhdCBjb25m ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg Ki8KIAotZmkKLWZpCi1PQ0FNTENET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUCi1pZiB0 ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MQ0RPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9D QU1MQ0RPVE9QVCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKK2lu dAorbWFpbiAoKQorewogCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK3JtIC1mIGNvbmZ0 ZXN0Lm8gY29uZnRlc3Qub2JqCitpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIKK2Nhc2UgIigo JGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7 CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJc JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIk YWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1CisgIGFjX3N0 YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAk YWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6CisgIGZvciBh Y19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRvCisgIHRlc3Qg LWYgIiRhY19maWxlIiB8fCBjb250aW51ZTsKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAgICouJGFj X2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwgKi5iYiB8ICou YmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7CisgICAgKikgYWNfY3Zfb2JqZXh0PWBl eHByICIkYWNfZmlsZSIgOiAnLipcLlwoLipcKSdgCisgICAgICAgYnJlYWs7OworICBlc2FjCitk b25lCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdhczoiID4mNQor c2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQogCit7IHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19l Y2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3QgY29tcGlsZQor U2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDUgOyB9CiBmaQot aWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDRE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FN TENET1RPUFQ9JE9DQU1MQ0RPVE9QVAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9j YW1sYy5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IG9jYW1sYy5vcHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNr aW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0 X09DQU1MQ0RPVE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CitybSAtZiBjb25mdGVzdC4kYWNfY3Zf b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X29iamV4dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2 X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFjX2N2X29iamV4dAorYWNfb2JqZXh0PSRPQkpFWFQK K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhl ciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyIiA+JjUKKyRhc19lY2hvX24gImNoZWNr aW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlci4uLiAiID4mNjsgfQor aWYgdGVzdCAiJHthY19jdl9jX2NvbXBpbGVyX2dudStzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN TENET1RPUFQiOyB0aGVuCi0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9UT1BUPSIkYWNfY3Rf T0NBTUxDRE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBhc19kaXIgaW4gJFBBVEgK LWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K LSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K LSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3By b2dfYWNfY3RfT0NBTUxDRE9UT1BUPSJvY2FtbGMub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi ID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwor ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u ZmRlZnMuaC4gICovCiAKLWZpCi1maQotYWNfY3RfT0NBTUxDRE9UT1BUPSRhY19jdl9wcm9nX2Fj X2N0X09DQU1MQ0RPVE9QVAotaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4K LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j dF9PQ0FNTENET1RPUFQiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENET1RPUFQiID4mNjsg fQoraW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hva2UgbWUKKyNl bmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBp bGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcwogZWxzZQotICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFz X2VjaG8gIm5vIiA+JjY7IH0KKyAgYWNfY29tcGlsZXJfZ251PW5vCiBmaQorcm0gLWYgY29yZSBj b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9j X2NvbXBpbGVyX2dudT0kYWNfY29tcGlsZXJfZ251CiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FN TENET1RPUFQiID0geDsgdGhlbgotICAgIE9DQU1MQ0RPVE9QVD0ibm8iCi0gIGVsc2UKLSAgICBj YXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29s cyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19tZTog V0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0 IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxDRE9UT1BUPSRh Y19jdF9PQ0FNTENET1RPUFQKLSAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hv ICIkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251 ID0geWVzOyB0aGVuCisgIEdDQz15ZXMKIGVsc2UKLSAgT0NBTUxDRE9UT1BUPSIkYWNfY3ZfcHJv Z19PQ0FNTENET1RPUFQiCisgIEdDQz0KIGZpCi0KLSAgICAgaWYgdGVzdCAiJE9DQU1MQ0RPVE9Q VCIgIT0gIm5vIjsgdGhlbgotCVRNUFZFUlNJT049YCRPQ0FNTENET1RPUFQgLXYgfCBzZWQgLW4g LWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCi0JaWYgdGVzdCAiJFRNUFZFUlNJT04i ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KLQkgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9j YW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY1Ci0kYXNfZWNobyAidmVyc2lvbnMgZGlmZmVycyBmcm9t IG9jYW1sYzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KLQllbHNlCi0JICAgIE9DQU1M Qz0kT0NBTUxDRE9UT1BUCi0JZmkKLSAgICAgZmkKLQotICAgICAjIGNoZWNraW5nIGZvciBvY2Ft bG9wdC5vcHQKLSAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiAhPSAibm8iIDsgdGhlbgotCWlmIHRl c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy YW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5v cHQ7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNf d29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3Nl dH0iID0gc2V0OyB0aGVuIDoKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0KK2FjX3NhdmVf Q0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19uICJjaGVja2lu ZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3By b2dfY2NfZytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19PQ0FNTE9QVERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK LWZvciBhc19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9 b2NhbWxvcHQub3B0IgotICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAg ZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUworICBhY19zYXZlX2Nfd2Vycm9yX2Zs YWc9JGFjX2Nfd2Vycm9yX2ZsYWcKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9eWVzCisgICBhY19jdl9w cm9nX2NjX2c9bm8KKyAgIENGTEFHUz0iLWciCisgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiAKLWZpCi1maQotT0NB TUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQKLWlmIHRlc3QgLW4gIiRPQ0FN TE9QVERPVE9QVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRPQ0FNTE9QVERPVE9QVCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MT1BURE9U T1BUIiA+JjY7IH0KK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF T0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfcHJv Z19jY19nPXllcwogZWxzZQotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLWZpCisgIENGTEFHUz0i IgorICAgICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyog ZW5kIGNvbmZkZWZzLmguICAqLwogCitpbnQKK21haW4gKCkKK3sKIAotZmkKLWlmIHRlc3QgLXog IiRhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUIjsgdGhlbgotICBhY19jdF9PQ0FNTE9QVERPVE9Q VD0kT0NBTUxPUFRET1RPUFQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9w dC5vcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15 IG9jYW1sb3B0Lm9wdDsgYWNfd29yZD0kMgoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3Rf T0NBTUxPUFRET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgotZWxzZQotICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiOyB0aGVu Ci0gIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9IiRhY19jdF9PQ0FNTE9QVERPVE9Q VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCi1lbHNlCi1hc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCi1mb3IgYXNfZGlyIGluICRQQVRICi1kbwotICBJRlM9 JGFzX3NhdmVfSUZTCi0gIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wcm9nX2FjX2N0X09D QU1MT1BURE9UT1BUPSJvY2FtbG9wdC5vcHQiCi0gICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Ci0g ICAgYnJlYWsgMgotICBmaQotZG9uZQotICBkb25lCi1JRlM9JGFzX3NhdmVfSUZTCisgIDsKKyAg cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0 aGVuIDoKKworZWxzZQorICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcK KwkgQ0ZMQUdTPSItZyIKKwkgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKIAorICA7Cisg IHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsg dGhlbiA6CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKIGZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVy ciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKIGZpCi1hY19jdF9PQ0FNTE9Q VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAotaWYgdGVzdCAtbiAiJGFj X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKLSRhc19lY2hv ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQotZWxzZQotICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+ JjY7IH0KK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRl c3QuJGFjX2V4dAogZmkKLQotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MT1BURE9UT1BUIiA9IHg7 IHRoZW4KLSAgICBPQ0FNTE9QVERPVE9QVD0ibm8iCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9 JGFjX3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNf Y3ZfcHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRo ZW4KKyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cg PSB5ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1n IC1PMiIKICAgZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQg aW4KLXllczopCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5J Tkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1 Ci0kYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4 ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMK LSAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NBTUxPUFRET1RPUFQKKyAgICBDRkxBR1M9Ii1n IgogICBmaQogZWxzZQotICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RP UFQiCi1maQotCi0JaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCi0JICAg VE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiog KlwoLipcKSR8XDF8cCcgYAotCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS U0lPTiIgOyB0aGVuCi0JICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRp c2NhcmRlZC4iID4mNQotJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2Nh bWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQotCSAgIGVsc2UKLQkgICAgICBPQ0FNTE9QVD0k T0NBTUxPUFRET1RPUFQKLQkgICBmaQotICAgICAgICBmaQotICAgICBmaQotCi0KKyAgaWYgdGVz dCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1PMiIKKyAgZWxzZQorICAgIENGTEFH Uz0KICAgZmkKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNo ZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5IiA+JjUKKyRhc19lY2hvX24g ImNoZWNraW5nIGZvciAkQ0Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5Li4uICIgPiY2OyB9Citp ZiB0ZXN0ICIke2FjX2N2X3Byb2dfY2NfYzg5K3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2Vj aG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY3ZfcHJvZ19jY19jODk9bm8KK2FjX3Nh dmVfQ0M9JENDCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkYXJnLmg+CisjaW5jbHVkZSA8c3Rk aW8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3RhdC5oPgorLyog TW9zdCBvZiB0aGUgZm9sbG93aW5nIHRlc3RzIGFyZSBzdG9sZW4gZnJvbSBSQ1MgNS43J3Mgc3Jj L2NvbmYuc2guICAqLworc3RydWN0IGJ1ZiB7IGludCB4OyB9OworRklMRSAqICgqcmNzb3Blbikg KHN0cnVjdCBidWYgKiwgc3RydWN0IHN0YXQgKiwgaW50KTsKK3N0YXRpYyBjaGFyICplIChwLCBp KQorICAgICBjaGFyICoqcDsKKyAgICAgaW50IGk7Cit7CisgIHJldHVybiBwW2ldOworfQorc3Rh dGljIGNoYXIgKmYgKGNoYXIgKiAoKmcpIChjaGFyICoqLCBpbnQpLCBjaGFyICoqcCwgLi4uKQor eworICBjaGFyICpzOworICB2YV9saXN0IHY7CisgIHZhX3N0YXJ0ICh2LHApOworICBzID0gZyAo cCwgdmFfYXJnICh2LGludCkpOworICB2YV9lbmQgKHYpOworICByZXR1cm4gczsKK30KIAorLyog T1NGIDQuMCBDb21wYXEgY2MgaXMgc29tZSBzb3J0IG9mIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQu ICBJdCBoYXMKKyAgIGZ1bmN0aW9uIHByb3RvdHlwZXMgYW5kIHN0dWZmLCBidXQgbm90ICdceEhI JyBoZXggY2hhcmFjdGVyIGNvbnN0YW50cy4KKyAgIFRoZXNlIGRvbid0IHByb3Zva2UgYW4gZXJy b3IgdW5mb3J0dW5hdGVseSwgaW5zdGVhZCBhcmUgc2lsZW50bHkgdHJlYXRlZAorICAgYXMgJ3gn LiAgVGhlIGZvbGxvd2luZyBpbmR1Y2VzIGFuIGVycm9yLCB1bnRpbCAtc3RkIGlzIGFkZGVkIHRv IGdldAorICAgcHJvcGVyIEFOU0kgbW9kZS4gIEN1cmlvdXNseSAnXHgwMCchPSd4JyBhbHdheXMg Y29tZXMgb3V0IHRydWUsIGZvciBhbgorICAgYXJyYXkgc2l6ZSBhdCBsZWFzdC4gIEl0J3MgbmVj ZXNzYXJ5IHRvIHdyaXRlICdceDAwJz09MCB0byBnZXQgc29tZXRoaW5nCisgICB0aGF0J3MgdHJ1 ZSBvbmx5IHdpdGggLXN0ZC4gICovCitpbnQgb3NmNF9jY19hcnJheSBbJ1x4MDAnID09IDAgPyAx IDogLTFdOwogCisvKiBJQk0gQyA2IGZvciBBSVggaXMgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdCwg YnV0IGl0IHJlcGxhY2VzIG1hY3JvIHBhcmFtZXRlcnMKKyAgIGluc2lkZSBzdHJpbmdzIGFuZCBj aGFyYWN0ZXIgY29uc3RhbnRzLiAgKi8KKyNkZWZpbmUgRk9PKHgpICd4JworaW50IHhsYzZfY2Nf YXJyYXlbRk9PKGEpID09ICd4JyA/IDEgOiAtMV07CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWwg dG9wbGV2ZWwKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJh Y3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9 b2NhbWw7IGFjX3dvcmQ9JDIKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAk YWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MK3NldH0iID0g c2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgaWYgdGVz dCAtbiAiJE9DQU1MIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MPSIkT0NBTUwiICMgTGV0IHRo ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ QVRIX1NFUEFSQVRPUgotZm9yIGFzX2RpciBpbiAkUEFUSAoraW50IHRlc3QgKGludCBpLCBkb3Vi bGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYpIChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgq ZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJuYW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKiko c3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAqLCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsK K2NoYXIgKiphcmd2OworaW50CittYWluICgpCit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0g YXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEpICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7 Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4gJycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9 YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9IUFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9O U19fIgogZG8KLSAgSUZTPSRhc19zYXZlX0lGUwotICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k aXI9LgotICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25z OyBkbwotICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRh c190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNf Y3ZfcHJvZ19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKLSAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKLSAgICBicmVhayAyCi0gIGZpCisgIENDPSIkYWNfc2F2ZV9DQyAkYWNfYXJnIgor ICBpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2df Y2NfYzg5PSRhY19hcmcKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0CisgIHRlc3QgIngkYWNfY3ZfcHJvZ19jY19jODkiICE9ICJ4bm8iICYmIGJyZWFrCiBk b25lCi0gIGRvbmUKLUlGUz0kYXNfc2F2ZV9JRlMKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0ND PSRhY19zYXZlX0NDCiAKIGZpCi1maQotT0NBTUw9JGFjX2N2X3Byb2dfT0NBTUwKLWlmIHRlc3Qg LW4gIiRPQ0FNTCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRPQ0FNTCIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MIiA+JjY7IH0KLWVsc2UK LSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKLSRhc19lY2hvICJubyIgPiY2OyB9CisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9w cm9nX2NjX2M4OSIgaW4KKyAgeCkKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm9uZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVk IiA+JjY7IH0gOzsKKyAgeG5vKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiB1bnN1cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQi ID4mNjsgfSA7OworICAqKQorICAgIENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJv Z19jY19jODkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citl c2FjCitpZiB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCiBmaQog CithY19leHQ9YworYWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAk Q0ZMQUdTICRDUFBGTEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBj b25mdGVzdCRhY19leGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFj X2V4dCAkTElCUyA+JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAK LWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTCI7IHRoZW4KLSAgYWNfY3RfT0NBTUw9 JE9DQU1MCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQy Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk YWNfd29yZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7 IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTCtzZXR9IiA9IHNldDsgdGhlbiA6 Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRo ZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg d2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAiID4mNjsgfQorc2V0IHggJHtN QUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2VkICdzLysvcC9nOyBzL1teYS16 QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgInRlc3QgXCJcJHthY19jdl9wcm9nX21ha2VfJHthY19t YWtlfV9zZXQrc2V0fVwiIiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19hY19jdF9PQ0FNTD0iJGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg dGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKLWZvciBh c19kaXIgaW4gJFBBVEgKLWRvCi0gIElGUz0kYXNfc2F2ZV9JRlMKLSAgdGVzdCAteiAiJGFzX2Rp ciIgJiYgYXNfZGlyPS4KLSAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KLSAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl bgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUw9Im9jYW1sIgotICAgICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lG UwotCi1maQotZmkKLWFjX2N0X09DQU1MPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MCi1pZiB0ZXN0 IC1uICIkYWNfY3RfT0NBTUwiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUwiID4mNQotJGFzX2VjaG8gIiRhY19jdF9P Q0FNTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkKLQotICBpZiB0 ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7IHRoZW4KLSAgICBPQ0FNTD0ibm8iCi0gIGVsc2UKLSAg ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0 b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7CisgIGNhdCA+Y29uZnRlc3QubWFrZSA8 PFxfQUNFT0YKK1NIRUxMID0gL2Jpbi9zaAorYWxsOgorCUBlY2hvICdAQEAlJSU9JChNQUtFKT1A QEAlJSUnCitfQUNFT0YKKyMgR05VIG1ha2Ugc29tZXRpbWVzIHByaW50cyAibWFrZVsxXTogRW50 ZXJpbmcgLi4uIiwgd2hpY2ggd291bGQgY29uZnVzZSB1cy4KK2Nhc2UgYCR7TUFLRS1tYWtlfSAt ZiBjb25mdGVzdC5tYWtlIDI+L2Rldi9udWxsYCBpbgorICAqQEBAJSUlPT8qPUBAQCUlJSopCisg ICAgZXZhbCBhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQ9eWVzOzsKKyAgKikKKyAgICBl dmFsIGFjX2N2X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldD1ubzs7CiBlc2FjCi0gICAgT0NBTUw9 JGFjX2N0X09DQU1MCi0gIGZpCitybSAtZiBjb25mdGVzdC5tYWtlCitmaQoraWYgZXZhbCB0ZXN0 IFwkYWNfY3ZfcHJvZ19tYWtlXyR7YWNfbWFrZX1fc2V0ID0geWVzOyB0aGVuCisgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2Vj aG8gInllcyIgPiY2OyB9CisgIFNFVF9NQUtFPQogZWxzZQotICBPQ0FNTD0iJGFjX2N2X3Byb2df T0NBTUwiCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0Ut bWFrZX0iCiBmaQogCi0KLSAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKLSAgaWYgdGVzdCAtbiAi JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7 YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0 aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkZXA7IGFjX3dvcmQ9JDIK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh Y193b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MREVQK3NldH0iID0gc2V0OyB0aGVuIDoKKyMg RmluZCBhIGdvb2QgaW5zdGFsbCBwcm9ncmFtLiAgV2UgcHJlZmVyIGEgQyBwcm9ncmFtIChmYXN0 ZXIpLAorIyBzbyBvbmUgc2NyaXB0IGlzIGFzIGdvb2QgYXMgYW5vdGhlci4gIEJ1dCBhdm9pZCB0 aGUgYnJva2VuIG9yCisjIGluY29tcGF0aWJsZSB2ZXJzaW9uczoKKyMgU3lzViAvZXRjL2luc3Rh bGwsIC91c3Ivc2Jpbi9pbnN0YWxsCisjIFN1bk9TIC91c3IvZXRjL2luc3RhbGwKKyMgSVJJWCAv c2Jpbi9pbnN0YWxsCisjIEFJWCAvYmluL2luc3RhbGwKKyMgQW1pZ2FPUyAvQy9pbnN0YWxsLCB3 aGljaCBpbnN0YWxscyBib290YmxvY2tzIG9uIGZsb3BweSBkaXNjcworIyBBSVggNCAvdXNyL2Jp bi9pbnN0YWxsYnNkLCB3aGljaCBkb2Vzbid0IHdvcmsgd2l0aG91dCBhIC1nIGZsYWcKKyMgQUZT IC91c3IvYWZzd3MvYmluL2luc3RhbGwsIHdoaWNoIG1pc2hhbmRsZXMgbm9uZXhpc3RlbnQgYXJn cworIyBTVlI0IC91c3IvdWNiL2luc3RhbGwsIHdoaWNoIHRyaWVzIHRvIHVzZSB0aGUgbm9uZXhp c3RlbnQgZ3JvdXAgInN0YWZmIgorIyBPUy8yJ3Mgc3lzdGVtIGluc3RhbGwsIHdoaWNoIGhhcyBh IGNvbXBsZXRlbHkgZGlmZmVyZW50IHNlbWFudGljCisjIC4vaW5zdGFsbCwgd2hpY2ggY2FuIGJl IGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBmcm9tIC4vaW5zdGFsbC5zaC4KKyMgUmVqZWN0 IGluc3RhbGwgcHJvZ3JhbXMgdGhhdCBjYW5ub3QgaW5zdGFsbCBtdWx0aXBsZSBmaWxlcy4KK3sg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGEgQlNE LWNvbXBhdGlibGUgaW5zdGFsbCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYSBCU0Qt Y29tcGF0aWJsZSBpbnN0YWxsLi4uICIgPiY2OyB9CitpZiB0ZXN0IC16ICIkSU5TVEFMTCI7IHRo ZW4KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9pbnN0YWxsK3NldH0iID0gc2V0OyB0aGVuIDoKICAg JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAtbiAiJE9DQU1MREVQ IjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MREVQPSIkT0NBTUxERVAiICMgTGV0IHRoZSB1c2Vy IG92ZXJyaWRlIHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NF UEFSQVRPUgorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNf ZGlyIGluICRQQVRICiBkbwogICBJRlM9JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIi ICYmIGFzX2Rpcj0uCi0gICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4 dGVuc2lvbnM7IGRvCi0gIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4 dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K LSAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgotICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQotICAgIGJyZWFrIDIKLSAgZmkKLWRvbmUKKyAgICAjIEFj Y291bnQgZm9yIHBlb3BsZSB3aG8gcHV0IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50 cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygoCisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0 Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNyL2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmlu LyogfCBcCisgID86W1xcL11vczJbXFwvXWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11J TlNUQUxMW1xcL10qIHwgXAorICAvdXNyL3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5k IFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIgb3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9u J3QgdXNlIGluc3RhbGxic2QgZnJvbSBPU0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9v dAorICAgICMgYnkgZGVmYXVsdC4KKyAgICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0 IGluc3RhbGw7IGRvCisgICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf ZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19l eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVu CisJICBpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFz X2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMg QUlYIGluc3RhbGwuICBJdCBoYXMgYW4gaW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4K KwkgICAgOgorCSAgZWxpZiB0ZXN0ICRhY19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3 cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVu CisJICAgICMgcHJvZ3JhbS1zcGVjaWZpYyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1 cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUg Y29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQor CSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkg ICAgaWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25m dGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0 Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3Qu ZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0 LnR3bworCSAgICB0aGVuCisJICAgICAgYWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19w cm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAgICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkK KyAgICAgIGRvbmUKKyAgICBkb25lCisgICAgOzsKK2VzYWMKKwogICBkb25lCiBJRlM9JGFzX3Nh dmVfSUZTCiAKK3JtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgor CiBmaQorICBpZiB0ZXN0ICIke2FjX2N2X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgor ICAgIElOU1RBTEw9JGFjX2N2X3BhdGhfaW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3Qg cmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hlbGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMg dmFsdWUgZm9yIElOU1RBTEwgd2l0aGluIGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0 IHdpbGwKKyAgICAjIGJyZWFrIG90aGVyIHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0 IGRpcmVjdG9yeSBpcworICAgICMgcmVtb3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRp dmUgbmFtZS4KKyAgICBJTlNUQUxMPSRhY19pbnN0YWxsX3NoCisgIGZpCiBmaQotT0NBTUxERVA9 JGFjX2N2X3Byb2dfT0NBTUxERVAKLWlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4KLSAgeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTERFUCIg PiY1Ci0kYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KLWVsc2UKLSAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKLSRhc19lY2hvICJubyIg PiY2OyB9Ci1maQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9CiAKKyMgVXNlIHRl c3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4gJHt2YXItdmFsfS4K KyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2YXJpYWJsZSBzdWJz dGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNUQUxMX1BST0dSQU09 JyR7SU5TVEFMTH0nCiAKLWZpCi1pZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERFUCI7IHRo ZW4KLSAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y ZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgot c2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit0ZXN0IC16ICIkSU5TVEFMTF9TQ1JJUFQi ICYmIElOU1RBTExfU0NSSVBUPScke0lOU1RBTEx9JworCit0ZXN0IC16ICIkSU5TVEFMTF9EQVRB IiAmJiBJTlNUQUxMX0RBVEE9JyR7SU5TVEFMTH0gLW0gNjQ0JworCisjIEV4dHJhY3QgdGhlIGZp cnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2df YWNfY3RfT0NBTUxERVArc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRo X0JJU09OK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK IGVsc2UKLSAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MREVQIjsgdGhlbgotICBhY19jdl9wcm9n X2FjX2N0X09DQU1MREVQPSIkYWNfY3RfT0NBTUxERVAiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRl IHRoZSB0ZXN0LgotZWxzZQotYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor ICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CSVNP Tj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4K KyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9y IGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNf ZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJs ZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0 aGVuCi0gICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0ib2NhbWxkZXAiCisgICAgYWNfY3Zf cGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01ODMzLDUzICszNTY1LDM5IEBAIGRv bmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCisgIDs7Citlc2FjCiBmaQotZmkKLWFjX2N0 X09DQU1MREVQPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MREVQCi1pZiB0ZXN0IC1uICIkYWNfY3Rf T0NBTUxERVAiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxERVAiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERF UCIgPiY2OyB9CitCSVNPTj0kYWNfY3ZfcGF0aF9CSVNPTgoraWYgdGVzdCAtbiAiJEJJU09OIjsg dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JEJJU09OIiA+JjUKKyRhc19lY2hvICIkQklTT04iID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8g Im5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTERFUCIgPSB4OyB0aGVu Ci0gICAgT0NBTUxERVA9Im5vIgotICBlbHNlCi0gICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRh Y190b29sX3dhcm5lZCBpbgoteWVzOikKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9z dCB0cmlwbGV0IiA+JjUKLSRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KLWFjX3Rvb2xfd2FybmVk PXllcyA7OwotZXNhYwotICAgIE9DQU1MREVQPSRhY19jdF9PQ0FNTERFUAotICBmaQotZWxzZQot ICBPQ0FNTERFUD0iJGFjX2N2X3Byb2dfT0NBTUxERVAiCi1maQotCiAKLSAgIyBjaGVja2luZyBm b3Igb2NhbWxta3RvcAotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCi0gICMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sbWt0b3A7IGFjX3dvcmQ9JDIKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29y ZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg ZHVtbXkgZmxleDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS1RP UCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfRkxFWCtzZXR9IiA9 IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRl c3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtUT1A9IiRPQ0FN TE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkRkxFWCBpbgorICBbXFwvXSog fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9GTEVYPSIkRkxFWCIgIyBMZXQgdGhlIHVzZXIgb3Zl cnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJ RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0k YXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNf ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0 IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RP UD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAgIGFjX2N2X3BhdGhfRkxFWD0iJGFz X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAg ICBicmVhayAyCiAgIGZpCkBAIC01ODg3LDM5ICszNjA1LDM5IEBAIGRvbmUKICAgZG9uZQogSUZT PSRhc19zYXZlX0lGUwogCisgIDs7Citlc2FjCiBmaQotZmkKLU9DQU1MTUtUT1A9JGFjX2N2X3By b2dfT0NBTUxNS1RPUAotaWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCi0gIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1 Ci0kYXNfZWNobyAiJE9DQU1MTUtUT1AiID4mNjsgfQorRkxFWD0kYWNfY3ZfcGF0aF9GTEVYCitp ZiB0ZXN0IC1uICIkRkxFWCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRGTEVYIiA+JjUKKyRhc19lY2hvICIkRkxFWCIgPiY2OyB9CiBl bHNlCiAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu byIgPiY1CiAkYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1maQotaWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxNS1RPUCI7IHRoZW4KLSAgYWNfY3RfT0NBTUxNS1RPUD0kT0NBTUxNS1RP UAotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0b3AiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IG9jYW1sbWt0b3A7IGFjX3dv cmQ9JDIKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBh IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgogeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS1RPUCtzZXR9IiA9IHNldDsgdGhlbiA6 CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfUEVSTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1L VE9QIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtUT1A9IiRhY19jdF9PQ0FNTE1L VE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZT PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkUEVSTCBpbgorICBbXFwvXSogfCA/ OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QRVJMPSIkUEVSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7 IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNf c2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhl Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1m ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN S1RPUD0ib2NhbWxta3RvcCIKKyAgICBhY19jdl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBm aQpAQCAtNTkyNyw1MyArMzY0NSw0NiBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMK IAorICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9QRVJMIiAmJiBhY19jdl9wYXRoX1BFUkw9Im5vIgor ICA7OworZXNhYwogZmkKLWZpCi1hY19jdF9PQ0FNTE1LVE9QPSRhY19jdl9wcm9nX2FjX2N0X09D QU1MTUtUT1AKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LVE9QIjsgdGhlbgotICB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtU T1AiID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LVE9QIiA+JjY7IH0KK1BFUkw9JGFjX2N2 X3BhdGhfUEVSTAoraWYgdGVzdCAtbiAiJFBFUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkUEVSTCIgPiY1CiskYXNfZWNobyAiJFBF UkwiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAgaWYgdGVz dCAieCRhY19jdF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KLSAgICBPQ0FNTE1LVE9QPSJubyIKLSAg ZWxzZQotICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KLXllczop Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5n IGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1Ci0kYXNfZWNo byAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo b3N0IHRyaXBsZXQiID4mMjt9Ci1hY190b29sX3dhcm5lZD15ZXMgOzsKLWVzYWMKLSAgICBPQ0FN TE1LVE9QPSRhY19jdF9PQ0FNTE1LVE9QCi0gIGZpCi1lbHNlCi0gIE9DQU1MTUtUT1A9IiRhY19j dl9wcm9nX09DQU1MTUtUT1AiCi1maQogCitpZiB0ZXN0IHgiJHtQRVJMfSIgPT0geCJubyIKK3Ro ZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgcGVybCwgcGxlYXNlIGluc3Rh bGwgcGVybCIgIiRMSU5FTk8iIDUKK2ZpCitpZiB0ZXN0ICJ4JHhhcGkiID0gInh5IjsgdGhlbiA6 CiAKLSAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgotICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9w cmVmaXgiOyB0aGVuCi0gICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3By ZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4K LXNldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKKyAgICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImN1cmwtY29uZmlnIiwgc28gaXQgY2FuIGJlIGEg cHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBjdXJsLWNvbmZpZzsgYWNfd29yZD0k MgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig JGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2 OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6 CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfQ1VSTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19l Y2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsg dGhlbgotICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiRPQ0FNTE1LTElCIiAjIExldCB0aGUgdXNl ciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T RVBBUkFUT1IKKyAgY2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf cGF0aF9DVVJMPSIkQ1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBh IHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU T1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAt eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4 ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfT0NBTUxNS0xJQj0iJHthY190b29sX3ByZWZpeH1v Y2FtbG1rbGliIgorICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC01 OTgxLDM5ICszNjkyLDQ0IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwogCisgIHRl c3QgLXogIiRhY19jdl9wYXRoX0NVUkwiICYmIGFjX2N2X3BhdGhfQ1VSTD0ibm8iCisgIDs7Citl c2FjCiBmaQotZmkKLU9DQU1MTUtMSUI9JGFjX2N2X3Byb2dfT0NBTUxNS0xJQgotaWYgdGVzdCAt biAiJE9DQU1MTUtMSUIiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkT0NBTUxNS0xJQiIgPiY1Ci0kYXNfZWNobyAiJE9DQU1MTUtMSUIi ID4mNjsgfQorQ1VSTD0kYWNfY3ZfcGF0aF9DVVJMCitpZiB0ZXN0IC1uICIkQ1VSTCI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDVVJM IiA+JjUKKyRhc19lY2hvICIkQ1VSTCIgPiY2OyB9CiBlbHNlCiAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAkYXNfZWNobyAibm8iID4m NjsgfQogZmkKIAogCitpZiB0ZXN0IHgiJHtDVVJMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19m bl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgY3VybC1jb25maWcsIHBsZWFzZSBpbnN0YWxsIGN1 cmwtY29uZmlnIiAiJExJTkVOTyIgNQogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1M TUtMSUIiOyB0aGVuCi0gIGFjX2N0X09DQU1MTUtMSUI9JE9DQU1MTUtMSUIKLSAgIyBFeHRyYWN0 IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2FtbG1rbGliOyBhY193b3JkPSQyCisgICAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh Y193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg fQotaWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRo ZW4gOgoraWYgdGVzdCAiJHthY19jdl9wYXRoX1hNTCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN TE1LTElCIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9PQ0FN TE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KLWVsc2UKLWFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgY2FzZSAkWE1MIGluCisgIFtcXC9dKiB8 ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hNTD0iJFhNTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJp ZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7 IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNf c2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhl Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1m ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxN S0xJQj0ib2NhbWxta2xpYiIKKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp CkBAIC02MDIxLDQ0ICszNzM3LDM5IEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZlX0lGUwog CisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hNTCIgJiYgYWNfY3ZfcGF0aF9YTUw9Im5vIgorICA7 OworZXNhYwogZmkKLWZpCi1hY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1M TUtMSUIKLWlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIi ID4mNQotJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK1hNTD0kYWNfY3ZfcGF0 aF9YTUwKK2lmIHRlc3QgLW4gIiRYTUwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkWE1MIiA+JjUKKyRhc19lY2hvICIkWE1MIiA+JjY7 IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0gIGlmIHRlc3QgIngkYWNf Y3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCi0gICAgT0NBTUxNS0xJQj0ibm8iCi0gIGVsc2UKLSAg ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCi15ZXM6KQoteyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0 b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw bGV0IiA+JjI7fQotYWNfdG9vbF93YXJuZWQ9eWVzIDs7Ci1lc2FjCi0gICAgT0NBTUxNS0xJQj0k YWNfY3RfT0NBTUxNS0xJQgotICBmaQotZWxzZQotICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19P Q0FNTE1LTElCIgorCitpZiB0ZXN0IHgiJHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1s Mi1jb25maWciICIkTElORU5PIiA1CiBmaQogCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9 ICJ4eSI7IHRoZW4gOgogCi0gICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9jCisgICAgICAjIGNoZWNr aW5nIGZvciBvY2FtbGMKICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgotICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9b2NhbWxkb2M7IGFjX3dvcmQ9JDIKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGM7IGFjX3dvcmQ9 JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y ICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHthY19jdl9wcm9nX09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoK K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTEMrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNf ZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUxET0MiOyB0 aGVuCi0gIGFjX2N2X3Byb2dfT0NBTUxET0M9IiRPQ0FNTERPQyIgIyBMZXQgdGhlIHVzZXIgb3Zl cnJpZGUgdGhlIHRlc3QuCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3By b2dfT0NBTUxDPSIkT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVs c2UKIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4g JFBBVEgKQEAgLTYwNjcsNyArMzc3OCw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFz X2Rpcj0uCiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lv bnM7IGRvCiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYg JGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBh Y19jdl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgorICAgIGFjX2N2 X3Byb2dfT0NBTUxDPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYyIKICAgICAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf ZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZpCkBAIC02MDc3LDEwICszNzg4LDEwIEBAIElGUz0k YXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1PQ0FNTERPQz0kYWNfY3ZfcHJvZ19PQ0FNTERPQwotaWYg dGVzdCAtbiAiJE9DQU1MRE9DIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MRE9DIiA+JjUKLSRhc19lY2hvICIkT0NBTUxET0Mi ID4mNjsgfQorT0NBTUxDPSRhY19jdl9wcm9nX09DQU1MQworaWYgdGVzdCAtbiAiJE9DQU1MQyI7 IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRPQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRPQ0FNTEMiID4mNjsgfQogZWxzZQogICB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2Vj aG8gIm5vIiA+JjY7IH0KQEAgLTYwODgsMTcgKzM3OTksMTcgQEAgZmkKIAogCiBmaQotaWYgdGVz dCAteiAiJGFjX2N2X3Byb2dfT0NBTUxET0MiOyB0aGVuCi0gIGFjX2N0X09DQU1MRE9DPSRPQ0FN TERPQwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZG9jIiwgc28gaXQgY2Fu IGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KLXNldCBkdW1teSBvY2FtbGRvYzsgYWNfd29y ZD0kMgoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxDIjsgdGhlbgorICBhY19jdF9PQ0FN TEM9JE9DQU1MQworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYyIsIHNvIGl0 IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxjOyBhY193 b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQytzZXR9IiA9IHNl dDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDK3NldH0iID0gc2V0 OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIk YWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorICBpZiB0 ZXN0IC1uICIkYWNfY3RfT0NBTUxDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQz0i JGFjX2N0X09DQU1MQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCiBh c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRI CkBAIC02MTA3LDcgKzM4MTgsNyBAQCBkbwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf cHJvZ19hY19jdF9PQ0FNTERPQz0ib2NhbWxkb2MiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FN TEM9Im9jYW1sYyIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAyCiAgIGZp CkBAIC02MTE3LDE3ICszODI4LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkKIGZpCi1hY19j dF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQwotaWYgdGVzdCAtbiAiJGFjX2N0 X09DQU1MRE9DIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKLSRhc19lY2hvICIkYWNfY3RfT0NBTUxE T0MiID4mNjsgfQorYWNfY3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVz dCAtbiAiJGFjX2N0X09DQU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19j dF9PQ0FNTEMiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKLSAg aWYgdGVzdCAieCRhY19jdF9PQ0FNTERPQyIgPSB4OyB0aGVuCi0gICAgT0NBTUxET0M9Im5vIgor ICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQyIgPSB4OyB0aGVuCisgICAgT0NBTUxDPSJubyIKICAg ZWxzZQogICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KIHllczop CkBAIC02MTM1LDI0ICszODQ2LDQxIEBAIHllczopCiAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5H OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9 CiBhY190b29sX3dhcm5lZD15ZXMgOzsKIGVzYWMKLSAgICBPQ0FNTERPQz0kYWNfY3RfT0NBTUxE T0MKKyAgICBPQ0FNTEM9JGFjX2N0X09DQU1MQwogICBmaQogZWxzZQotICBPQ0FNTERPQz0iJGFj X2N2X3Byb2dfT0NBTUxET0MiCisgIE9DQU1MQz0iJGFjX2N2X3Byb2dfT0NBTUxDIgogZmkKIAog Ci0gICMgY2hlY2tpbmcgZm9yIG9jYW1sYnVpbGQKLSAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJl Zml4IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVm aXh9b2NhbWxidWlsZCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1z ZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGJ1aWxkOyBhY193b3JkPSQyCisgIGlmIHRl c3QgIiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12 IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIHsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBPQ2FtbCB2ZXJzaW9uIGlz ICRPQ0FNTFZFUlNJT04iID4mNQorJGFzX2VjaG8gIk9DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVS U0lPTiIgPiY2OyB9CisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQKKyAgICAgaWYg dGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAkT0NBTUxDIC13 aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcgJyAtZiA0YAor ICAgICBlbHNlCisgICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBPQ0FNTExJQiBwcmV2aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC4iID4mNQor JGFzX2VjaG8gIk9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY2OyB9 CisgICAgIGZpCisgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiBPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjUKKyRhc19lY2hvICJP Q2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCIiA+JjY7IH0KKworCisKKworICAgICAjIGNo ZWNraW5nIGZvciBvY2FtbG9wdAorICAgICBpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0 aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2Ft bG9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg JHthY190b29sX3ByZWZpeH1vY2FtbG9wdDsgYWNfd29yZD0kMgogeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQogJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2 X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3By b2dfT0NBTUxPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgogZWxzZQotICBpZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KLSAgYWNfY3ZfcHJv Z19PQ0FNTEJVSUxEPSIkT0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRl c3QuCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q VD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK QEAgLTYxNjEsNyArMzg4OSw3IEBAIGRvCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u CiAgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv CiAgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9w cm9nX09DQU1MQlVJTEQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZCIKKyAgICBhY19jdl9w cm9nX09DQU1MT1BUPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0IgogICAgICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl Y19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYxNzEsMTAgKzM4OTksMTAgQEAgSUZT PSRhc19zYXZlX0lGUwogCiBmaQogZmkKLU9DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlM RAotaWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1Ci0kYXNfZWNobyAi JE9DQU1MQlVJTEQiID4mNjsgfQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRl c3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+ JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CkBAIC02MTgyLDE3ICszOTEwLDE3 IEBAIGZpCiAKIAogZmkKLWlmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQiOyB0aGVu Ci0gIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKLSAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3 b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn cy4KLXNldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3Zf cHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BUCisgICMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQyCiB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEK3NldH0iID0gc2V0OyB0aGVuIDoKK2lm IHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAg ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgLW4gIiRhY19jdF9P Q0FNTEJVSUxEIjsgdGhlbgotICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19jdF9P Q0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KKyAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUPSIk YWNfY3RfT0NBTUxPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxzZQog YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU SApAQCAtNjIwMSw3ICszOTI5LDcgQEAgZG8KICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly PS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg ZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2 X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0ib2NhbWxidWlsZCIKKyAgICBhY19jdl9wcm9nX2FjX2N0 X09DQU1MT1BUPSJvY2FtbG9wdCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVh ayAyCiAgIGZpCkBAIC02MjExLDE3ICszOTM5LDE3IEBAIElGUz0kYXNfc2F2ZV9JRlMKIAogZmkK IGZpCi1hY19jdF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQKLWlmIHRl c3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQlVJTEQiID4mNQotJGFzX2Vj aG8gIiRhY19jdF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2FjX2N0X09DQU1MT1BUPSRhY19jdl9wcm9n X2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxPUFQiOyB0aGVuCisgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NB TUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIgPiY2OyB9CiBlbHNlCiAgIHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiAk YXNfZWNobyAibm8iID4mNjsgfQogZmkKIAotICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQlVJTEQi ID0geDsgdGhlbgotICAgIE9DQU1MQlVJTEQ9Im5vIgorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1M T1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCiAgIGVsc2UKICAgICBjYXNlICRjcm9z c19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCiB5ZXM6KQpAQCAtNjIyOSw0NCArMzk1Nyw4 OSBAQCB5ZXM6KQogJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQogYWNfdG9vbF93YXJuZWQ9eWVz IDs7CiBlc2FjCi0gICAgT0NBTUxCVUlMRD0kYWNfY3RfT0NBTUxCVUlMRAorICAgIE9DQU1MT1BU PSRhY19jdF9PQ0FNTE9QVAogICBmaQogZWxzZQotICBPQ0FNTEJVSUxEPSIkYWNfY3ZfcHJvZ19P Q0FNTEJVSUxEIgorICBPQ0FNTE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFQiCiBmaQogCisgICAg IE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8iOyB0aGVuCisJ eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBDYW5ub3Qg ZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mNQorJGFzX2VjaG8g IiRhc19tZTogV0FSTklORzogQ2Fubm90IGZpbmQgb2NhbWxvcHQ7IGJ5dGVjb2RlIGNvbXBpbGF0 aW9uIG9ubHkuIiA+JjI7fQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBW RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2Nh bWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz IGZyb20gb2NhbWxjOyBvY2FtbG9wdCBkaXNjYXJkZWQuIiA+JjY7IH0KKwkgICAgT0NBTUxPUFQ9 bm8KKwllbHNlCisJICAgIE9DQU1MQkVTVD1vcHQKKwlmaQorICAgICBmaQogCi0gICAgaWYgdGVz dCAieCRPQ0FNTEMiID0gInhubyI7IHRoZW4gOgogCi0gICAgICAgIGlmIHRlc3QgIngkZW5hYmxl X29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKIAotICAgICAgICAgICAgYXNfZm5fZXJyb3Ig JD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8gZmluZCBPY2FtbCIgIiRMSU5F Tk8iIDUKLWZpCi0gICAgICAgIG9jYW1sdG9vbHM9Im4iCisgICAgICMgY2hlY2tpbmcgZm9yIG9j YW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4 dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNv IGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29s X3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19P Q0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9UT1BUIjsgdGhlbgorICBhY19jdl9w cm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUg dGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitm b3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRh c19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRh YmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19l eGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07 IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJHthY190b29sX3ByZWZpeH1vY2Ft bGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCiBmaQorZmkKK09DQU1MQ0RPVE9QVD0kYWNf Y3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRPQ0FNTENET1RPUFQiOyB0aGVuCisg IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxD RE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BUIiA+JjY7IH0KK2Vsc2UKKyAgeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh c19lY2hvICJubyIgPiY2OyB9CitmaQorCiAKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg b2YgImJhc2giLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IGJhc2g7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQ0RPVE9Q VCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxDRE9UT1BUPSRPQ0FNTENET1RPUFQKKyAgIyBFeHRyYWN0 IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbGMub3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGMub3B0OyBhY193b3JkPSQyCiB7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNf Y3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNo b19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBjYXNlICRCQVNIIGluCi0gIFtcXC9dKiB8ID86 W1xcL10qKQotICBhY19jdl9wYXRoX0JBU0g9IiRCQVNIIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsg SUZTPSRQQVRIX1NFUEFSQVRPUgorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxDRE9UT1BUIjsg dGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVD0iJGFjX2N0X09DQU1MQ0RPVE9Q VCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9 JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX0JBU0g9IiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENE T1RPUFQ9Im9jYW1sYy5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsg MgogICBmaQpAQCAtNjI3NCw1NiArNDA0Nyw2MyBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2 ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9 Im5vIgotICA7OwotZXNhYwogZmkKLUJBU0g9JGFjX2N2X3BhdGhfQkFTSAotaWYgdGVzdCAtbiAi JEJBU0giOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkQkFTSCIgPiY1Ci0kYXNfZWNobyAiJEJBU0giID4mNjsgfQorZmkKK2FjX2N0X09D QU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRh Y19jdF9PQ0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIk YWNfY3RfT0NBTUxDRE9UT1BUIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9 CiBmaQogCi0KLWlmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vy cm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBiYXNoIiAiJExJTkVO TyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MQ0RPVE9QVCIgPSB4OyB0aGVuCisgICAgT0NB TUxDRE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9v bF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJp cGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBu b3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMg OzsKK2VzYWMKKyAgICBPQ0FNTENET1RPUFQ9JGFjX2N0X09DQU1MQ0RPVE9QVAorICBmaQorZWxz ZQorICBPQ0FNTENET1RPUFQ9IiRhY19jdl9wcm9nX09DQU1MQ0RPVE9QVCIKIGZpCi1pZiB0ZXN0 ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSI7IHRoZW4gOgotCi0gICAgaWYgZWNobyAiJFBZVEhPTiIg fCBncmVwIC1xICJeLyI7IHRoZW4gOgogCi0gICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgotICAg ICAgICBQWVRIT049YGJhc2VuYW1lICRQWVRIT05QQVRIYAorICAgICBpZiB0ZXN0ICIkT0NBTUxD RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1gJE9DQU1MQ0RPVE9QVCAtdiB8IHNl ZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAnIGAKKwlpZiB0ZXN0ICIkVE1QVkVS U0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAgICB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1s Yzsgb2NhbWxjLm9wdCBkaXNjYXJkZWQuIiA+JjUKKyRhc19lY2hvICJ2ZXJzaW9ucyBkaWZmZXJz IGZyb20gb2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCWVsc2UKKwkgICAg T0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAgICBmaQogCi1lbGlmIHRlc3QgLXogIiRQWVRI T04iOyB0aGVuIDoKLSAgUFlUSE9OPSJweXRob24iCi1lbHNlCi0gIGFzX2ZuX2Vycm9yICQ/ICJQ WVRIT04gc3BlY2lmaWVkLCBidXQgaXMgbm90IGFuIGFic29sdXRlIHBhdGgiICIkTElORU5PIiA1 Ci1maQotICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJFBZVEhPTiIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJFBZVEhPTjsgYWNfd29y ZD0kMgorICAgICAjIGNoZWNraW5nIGZvciBvY2FtbG9wdC5vcHQKKyAgICAgaWYgdGVzdCAiJE9D QU1MT1BUIiAhPSAibm8iIDsgdGhlbgorCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRo ZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1s b3B0Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt bXkgJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQ7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUK ICRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAi JHthY19jdl9wYXRoX1BZVEhPTlBBVEgrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHth Y19jdl9wcm9nX09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkUFlUSE9OUEFUSCBpbgotICBbXFwvXSog fCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1M T1BURE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MT1BURE9UT1BUPSIkT0NBTUxPUFRE T1RPUFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAg SUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZv ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7 IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9QWVRI T05QQVRIPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NB TUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQub3B0IgogICAgICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNf ZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTYzMzEsNjIgKzQxMTEsMzkgQEAg ZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAiJGFjX2N2X3BhdGhf UFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKLSAgOzsKLWVzYWMKIGZp Ci1QWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKLWlmIHRlc3QgLW4gIiRQWVRIT05Q QVRIIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJFBZVEhPTlBBVEgiID4mNQotJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7IH0KK2Zp CitPQ0FNTE9QVERPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAi JE9DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJE9DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxP UFRET1RPUFQiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAot aWYgdGVzdCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3Ig JD8gIlVuYWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElO RU5PIiA1Ci1maQotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog Y2hlY2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQotJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KLWAkUFlUSE9OIC1j ICdpbXBvcnQgc3lzOyBzeXMuZXhpdChldmFsKCJzeXMudmVyc2lvbl9pbmZvIDwgKDIsIDMpIikp J2AKLWlmIHRlc3QgIiQ/IiAhPSAiMCIKLXRoZW4KLSAgICBweXRob25fdmVyc2lvbj1gJFBZVEhP TiAtViAyPiYxYAotICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotICAgIGFzX2ZuX2Vycm9yICQ/ ICIkcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlz IDIuMyIgIiRMSU5FTk8iIDUKLWVsc2UKLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQogZmkK LQotYWNfcHJldmlvdXNfY3BwZmxhZ3M9JENQUEZMQUdTCi1hY19wcmV2aW91c19sZGZsYWdzPSRM REZMQUdTCi1hY19weXRob25fdmVyc2lvbj1gJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5z eXNjb25maWc7IFwKLSAgICBwcmludCBkaXN0dXRpbHMuc3lzY29uZmlnLmdldF9jb25maWdfdmFy KCJWRVJTSU9OIiknYAotIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OLWNvbmZp ZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQgZHVtbXkgJFBZ VEhPTi1jb25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MT1BU RE9UT1BUIjsgdGhlbgorICBhY19jdF9PQ0FNTE9QVERPVE9QVD0kT0NBTUxPUFRET1RPUFQKKyAg IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJvY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4gYmUg YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0Lm9wdDsgYWNfd29y ZD0kMgogeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgJGFjX3dvcmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIg PiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3BhdGhfcHljb25maWcrc2V0fSIgPSBzZXQ7IHRoZW4g OgoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUK3NldH0iID0gc2V0 OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkcHlj b25maWcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfcHljb25maWc9IiRw eWNvbmZpZyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0g IDs7Ci0gICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYg dGVzdCAtbiAiJGFjX2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0 X09DQU1MT1BURE9UT1BUPSIkYWNfY3RfT0NBTUxPUFRET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS QVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0 IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9weWNvbmZpZz0iJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BURE9UT1BUPSJvY2FtbG9w dC5vcHQiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJlYWsgMgogICBmaQpAQCAt NjM5NCwxMjcgKzQxNTEsNjggQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAg dGVzdCAteiAiJGFjX2N2X3BhdGhfcHljb25maWciICYmIGFjX2N2X3BhdGhfcHljb25maWc9Im5v IgotICA7OwotZXNhYwogZmkKLXB5Y29uZmlnPSRhY19jdl9wYXRoX3B5Y29uZmlnCi1pZiB0ZXN0 IC1uICIkcHljb25maWciOyB0aGVuCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkcHljb25maWciID4mNQotJGFzX2VjaG8gIiRweWNvbmZpZyIgPiY2 OyB9CitmaQorYWNfY3RfT0NBTUxPUFRET1RPUFQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRE T1RPUFQKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgeyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE9Q VERPVE9QVCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjY7IH0KIGVs c2UKICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v IiA+JjUKICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIkcHljb25maWci ID09IHgibm8iOyB0aGVuIDoKLQotICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAt YyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgIi1JIiArIGRp c3R1dGlscy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIklOQ0xVREVQWSIpJ2AiCi0gICAgQ1BQ RkxBR1M9IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7 IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZM QUdTIiknYCIKLSAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1 dGlscy5zeXNjb25maWc7IFwKLSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRf Y29uZmlnX3ZhcigiTElCUyIpJ2AiCi0gICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMg J2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgICAgIHByaW50IGRpc3R1dGlscy5z eXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIlNZU0xJQlMiKSdgIgotICAgIExERkxBR1M9IiRMREZM QUdTIGAkUFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAotICAgICAgICBw cmludCAiLUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNp ZmljPTEsXAotICAgICAgICBzdGFuZGFyZF9saWI9MSkgKyAiL2NvbmZpZyInYCIKLSAgICBMREZM QUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwK LSAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZP UlNIQVJFRCIpJ2AiCi0gICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBk aXN0dXRpbHMuc3lzY29uZmlnOyBcCi0gICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcu Z2V0X2NvbmZpZ192YXIoIkxERkxBR1MiKSdgIgotCi1lbHNlCi0KLSAgICAgICAgQ1BQRkxBR1M9 IiRDRkxBR1MgYCRQWVRIT04tY29uZmlnIC0tY2ZsYWdzYCIKLSAgICBMREZMQUdTPSIkTERGTEFH UyBgJFBZVEhPTi1jb25maWcgLS1sZGZsYWdzYCIKLQotZmkKLQotYWNfZm5fY19jaGVja19oZWFk ZXJfbW9uZ3JlbCAiJExJTkVOTyIgIlB5dGhvbi5oIiAiYWNfY3ZfaGVhZGVyX1B5dGhvbl9oIiAi JGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9QeXRob25faCIg PSB4IiJ5ZXM7IHRoZW4gOgotCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxPUFRET1RPUFQiID0g eDsgdGhlbgorICAgIE9DQU1MT1BURE9UT1BUPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1 c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE9QVERPVE9QVD0kYWNfY3RfT0NB TUxPUFRET1RPUFQKKyAgZmkKIGVsc2UKLSAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k IFB5dGhvbiBkZXZlbG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQorICBPQ0FNTE9QVERPVE9Q VD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQiCiBmaQogCisJaWYgdGVzdCAiJE9DQU1MT1BU RE9UT1BUIiAhPSAibm8iOyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12 IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3Qg IiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBm cm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNp b24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQor CSAgIGVsc2UKKwkgICAgICBPQ0FNTE9QVD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAg ICBmaQorICAgICBmaQogCi1hc19hY19MaWI9YCRhc19lY2hvICJhY19jdl9saWJfcHl0aG9uJGFj X3B5dGhvbl92ZXJzaW9uJydfUHlBcmdfUGFyc2VUdXBsZSIgfCAkYXNfdHJfc2hgCi17ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBQeUFyZ19QYXJz ZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBQeUFyZ19QYXJzZVR1cGxlIGluIC1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9u Li4uICIgPiY2OyB9Ci1pZiBldmFsICJ0ZXN0IFwiXCR7JGFzX2FjX0xpYitzZXR9XCIiID0gc2V0 OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tf bGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24gICRM SUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5k IGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlw ZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNo IHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1l bnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwot ZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIFB5QXJnX1BhcnNlVHVwbGUgKCk7Ci1pbnQKLW1haW4g KCkKLXsKLXJldHVybiBQeUFyZ19QYXJzZVR1cGxlICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGV2YWwgIiRh c19hY19MaWI9eWVzIgotZWxzZQotICBldmFsICIkYXNfYWNfTGliPW5vIgotZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCi1maQot ZXZhbCBhY19yZXM9XCQkYXNfYWNfTGliCi0JICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKLSRhc19lY2hvICIkYWNfcmVz IiA+JjY7IH0KLWlmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfTGliIlwiID0geCJ5ZXMiOyB0aGVu IDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVf TElCcHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uIiB8ICRhc190cl9jcHBgIDEKLV9BQ0VPRgotCi0g IExJQlM9Ii1scHl0aG9uJGFjX3B5dGhvbl92ZXJzaW9uICRMSUJTIgogCi1lbHNlCi0gIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIHB5dGhvbiBkZXZlbG9wbWVudCBs aWJyYXJ5IiAiJExJTkVOTyIgNQotZmkKKyAgZmkKIAotQ1BQRkxBR1M9JGFjX3ByZXZpb3VzX2Nw cGZsYWdzCi1MRExGQUdTPSRhY19wcmV2aW91c19sZGZsYWdzCiAKIAotZmkKLSMgRXh0cmFjdCB0 aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUg d2l0aCBhcmdzLgotc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCisgICMgY2hlY2tpbmcg Zm9yIG9jYW1sIHRvcGxldmVsCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVj a2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9YR0VU VEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CitpZiB0ZXN0ICIke2FjX2N2X3Byb2dfT0NBTUwrc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBj YXNlICRYR0VUVEVYVCBpbgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9YR0VU VEVYVD0iJFhHRVRURVhUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg cGF0aC4KLSAgOzsKLSAgKikKLSAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP UgorICBpZiB0ZXN0IC1uICIkT0NBTUwiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUw9IiRPQ0FN TCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCiBmb3IgYXNfZGlyIGluICRQQVRICiBkbwogICBJRlM9 JGFzX3NhdmVfSUZTCiAgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCiAgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCiAgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KLSAgICBhY19jdl9wYXRoX1hHRVRURVhU PSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUw9IiR7 YWNfdG9vbF9wcmVmaXh9b2NhbWwiCiAgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CiAgICAgYnJl YWsgMgogICBmaQpAQCAtNjUyMiw0NCArNDIyMCwzOSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNf c2F2ZV9JRlMKIAotICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9YR0VUVEVYVCIgJiYgYWNfY3ZfcGF0 aF9YR0VUVEVYVD0ibm8iCi0gIDs7Ci1lc2FjCiBmaQotWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdF VFRFWFQKLWlmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1Ci0kYXNfZWNobyAi JFhHRVRURVhUIiA+JjY7IH0KK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAt biAiJE9DQU1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJE9DQU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQogZWxzZQog ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m NQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYgdGVzdCB4IiR7WEdFVFRFWFR9IiA9 PSB4Im5vIgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB4Z2V0dGV4 dCwgcGxlYXNlIGluc3RhbGwgeGdldHRleHQiICIkTElORU5PIiA1CiBmaQotIyBFeHRyYWN0IHRo ZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGgg YXJncy4KLXNldCBkdW1teSBhczg2OyBhY193b3JkPSQyCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJv Z19PQ0FNTCI7IHRoZW4KKyAgYWNfY3RfT0NBTUw9JE9DQU1MCisgICMgRXh0cmFjdCB0aGUgZmly c3Qgd29yZCBvZiAib2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz Lgorc2V0IGR1bW15IG9jYW1sOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9B Uzg2K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FN TCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl Ci0gIGNhc2UgJEFTODYgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfQVM4 Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgot ICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlm IHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTD0i JGFjX2N0X09DQU1MIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2Fz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgK IGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K ICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K ICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3Bh dGhfQVM4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICBhY19jdl9wcm9nX2Fj X2N0X09DQU1MPSJvY2FtbCIKICAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKICAgICBicmVhayAy CiAgIGZpCkBAIC02NTY3LDQ0ICs0MjYwLDUzIEBAIGRvbmUKICAgZG9uZQogSUZTPSRhc19zYXZl X0lGUwogCi0gIHRlc3QgLXogIiRhY19jdl9wYXRoX0FTODYiICYmIGFjX2N2X3BhdGhfQVM4Nj0i bm8iCi0gIDs7Ci1lc2FjCiBmaQotQVM4Nj0kYWNfY3ZfcGF0aF9BUzg2Ci1pZiB0ZXN0IC1uICIk QVM4NiI7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRBUzg2IiA+JjUKLSRhc19lY2hvICIkQVM4NiIgPiY2OyB9CitmaQorYWNfY3RfT0NB TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KIGVsc2UKICAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK ICRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0FTODZ9IiA9PSB4Im5v IgotdGhlbgotICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhczg2LCBwbGVhc2Ug aW5zdGFsbCBhczg2IiAiJExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MIiA9IHg7 IHRoZW4KKyAgICBPQ0FNTD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6 JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBo b3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3Mg dG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJu ZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUw9JGFjX2N0X09DQU1MCisgIGZpCitlbHNlCisgIE9D QU1MPSIkYWNfY3ZfcHJvZ19PQ0FNTCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg ImxkODYiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15 IGxkODY7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIGlmIHRl c3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwOyBhY193 b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9MRDg2K3NldH0iID0gc2V0OyB0aGVuIDoK K2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJExEODYgaW4KLSAgW1xcL10q IHwgPzpbXFwvXSopCi0gIGFjX2N2X3BhdGhfTEQ4Nj0iJExEODYiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K KyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVycmlk ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK IGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAi JGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1 dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg fTsgdGhlbgotICAgIGFjX2N2X3BhdGhfTEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4 dCIKKyAgICBhY19jdl9wcm9nX09DQU1MREVQPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIgog ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY2MTIsNDQg KzQzMTQsMzkgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgdGVzdCAteiAi JGFjX2N2X3BhdGhfTEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKLSAgOzsKLWVzYWMKIGZp Ci1MRDg2PSRhY19jdl9wYXRoX0xEODYKLWlmIHRlc3QgLW4gIiRMRDg2IjsgdGhlbgotICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJExEODYiID4mNQot JGFzX2VjaG8gIiRMRDg2IiA+JjY7IH0KK2ZpCitPQ0FNTERFUD0kYWNfY3ZfcHJvZ19PQ0FNTERF UAoraWYgdGVzdCAtbiAiJE9DQU1MREVQIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MREVQIiA+JjUKKyRhc19lY2hvICIkT0NB TUxERVAiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKIAotaWYg dGVzdCB4IiR7TEQ4Nn0iID09IHgibm8iCi10aGVuCi0gICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs ZSB0byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBmaQotIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5h bWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IGJjYzsgYWNfd29yZD0kMgoraWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxERVAiOyB0aGVuCisgIGFjX2N0X09DQU1MREVQPSRPQ0FNTERFUAorICAj IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sZGVwIiwgc28gaXQgY2FuIGJlIGEgcHJv Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBvY2FtbGRlcDsgYWNfd29yZD0kMgogeyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dv cmQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3BhdGhfQkNDK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7 YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhc2UgJEJDQyBpbgotICBbXFwvXSogfCA/Oltc XC9dKikKLSAgYWNfY3ZfcGF0aF9CQ0M9IiRCQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo ZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAg YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNl ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T RVBBUkFUT1IKIGZvciBhc19kaXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAg dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IjsgfTsgdGhlbgotICAgIGFjX2N2X3BhdGhfQkNDPSIkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgogICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY2NTcsMjgzICs0 MzU0LDI0MSBAQCBkb25lCiAgIGRvbmUKIElGUz0kYXNfc2F2ZV9JRlMKIAotICB0ZXN0IC16ICIk YWNfY3ZfcGF0aF9CQ0MiICYmIGFjX2N2X3BhdGhfQkNDPSJubyIKLSAgOzsKLWVzYWMKIGZpCi1C Q0M9JGFjX2N2X3BhdGhfQkNDCi1pZiB0ZXN0IC1uICIkQkNDIjsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEJDQyIgPiY1Ci0kYXNfZWNo byAiJEJDQyIgPiY2OyB9CitmaQorYWNfY3RfT0NBTUxERVA9JGFjX2N2X3Byb2dfYWNfY3RfT0NB TUxERVAKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTERFUCIgPiY1 CiskYXNfZWNobyAiJGFjX2N0X09DQU1MREVQIiA+JjY7IH0KIGVsc2UKICAgeyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKICRhc19lY2hvICJu byIgPiY2OyB9CiBmaQogCi0KLWlmIHRlc3QgeCIke0JDQ30iID09IHgibm8iCi10aGVuCi0gICAg YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAi JExJTkVOTyIgNQorICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7IHRoZW4KKyAgICBP Q0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90 IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7 Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitlbHNlCisgIE9DQU1M REVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKIGZpCi0jIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg b2YgImlhc2wiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1 bW15IGlhc2w7IGFjX3dvcmQ9JDIKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWt0b3AKKyAg aWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0 IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcCIsIHNvIGl0IGNhbiBiZSBhIHBy b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbG1r dG9wOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFj X3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9JQVNMK3NldH0iID0gc2V0 OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FNTE1LVE9QK3NldH0iID0gc2V0OyB0 aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkSUFTTCBp bgotICBbXFwvXSogfCA/OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9JQVNMPSIkSUFTTCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0gICopCi0gIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAtbiAiJE9DQU1M TUtUT1AiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJE9DQU1MTUtUT1AiICMgTGV0 IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT PSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFUSAogZG8KICAgSUZTPSRhc19zYXZl X0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgogICAgIGZvciBhY19leGVjX2V4 dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwogICBpZiB7IHRlc3QgLWYgIiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3ZfcGF0aF9JQVNMPSIkYXNfZGlyLyRh Y193b3JkJGFjX2V4ZWNfZXh0IgorICAgIGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29s X3ByZWZpeH1vY2FtbG1rdG9wIgogICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFr IDIKLSAgZmkKLWRvbmUKLSAgZG9uZQotSUZTPSRhc19zYXZlX0lGUwotCi0gIHRlc3QgLXogIiRh Y19jdl9wYXRoX0lBU0wiICYmIGFjX2N2X3BhdGhfSUFTTD0ibm8iCi0gIDs7Ci1lc2FjCi1maQot SUFTTD0kYWNfY3ZfcGF0aF9JQVNMCi1pZiB0ZXN0IC1uICIkSUFTTCI7IHRoZW4KLSAgeyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRJQVNMIiA+JjUKLSRh c19lY2hvICIkSUFTTCIgPiY2OyB9Ci1lbHNlCi0gIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotZmkK LQotCi1pZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIKLXRoZW4KLSAgICBhc19mbl9lcnJvciAk PyAiVW5hYmxlIHRvIGZpbmQgaWFzbCwgcGxlYXNlIGluc3RhbGwgaWFzbCIgIiRMSU5FTk8iIDUK LWZpCi0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJ1dWlkL3V1aWQu aCIgImFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYg dGVzdCAieCRhY19jdl9oZWFkZXJfdXVpZF91dWlkX2giID0geCIieWVzOyB0aGVuIDoKLQotICAg IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1 aWRfY2xlYXIgaW4gLWx1dWlkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2Ns ZWFyIGluIC1sdXVpZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfdXVpZF91dWlk X2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx1dWlkICAkTElC UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj b25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUg dG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0 aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50 IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4 dGVybiAiQyIKLSNlbmRpZgotY2hhciB1dWlkX2NsZWFyICgpOwotaW50Ci1tYWluICgpCi17Ci1y ZXR1cm4gdXVpZF9jbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfdXVpZF91dWlkX2Ns ZWFyPXllcwotZWxzZQotICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCi1maQotcm0gLWYg Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKLWZp Ci17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2 X2xpYl91dWlkX3V1aWRfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlk X2NsZWFyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4 IiJ5ZXM7IHRoZW4gOgotICBsaWJ1dWlkPSJ5IgotZmkKLQorICBmaQorZG9uZQorICBkb25lCitJ RlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0KLQotYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi JExJTkVOTyIgInV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVm YXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgot ICBsaWJ1dWlkPSJ5IgogZmkKLQotCi1pZiB0ZXN0ICIkbGlidXVpZCIgIT0gInkiOyB0aGVuIDoK LQotICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIg IiRMSU5FTk8iIDUKLQorT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19PQ0FNTE1LVE9QCitpZiB0ZXN0 IC1uICIkT0NBTUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FNTE1LVE9QIiA+JjUKKyRhc19lY2hvICIkT0NBTUxNS1RP UCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKIAogCi1hY19mbl9j X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAiY3Vyc2VzLmgiICJhY19jdl9oZWFkZXJf Y3Vyc2VzX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy X2N1cnNlc19oIiA9IHgiInllczsgdGhlbiA6Ci0KLSAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbGVhciBpbiAtbGN1cnNlcyIgPiY1Ci0k YXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxjdXJzZXMuLi4gIiA+JjY7IH0KLWlm IHRlc3QgIiR7YWNfY3ZfbGliX2N1cnNlc19jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CitmaQor aWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxN S1RPUD0kT0NBTUxNS1RPUAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sbWt0 b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9j YW1sbWt0b3A7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1M TUtUT1Arc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgog ZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGN1cnNlcyAgJExJ QlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQg Y29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl IHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1l eHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xlYXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVy biBjbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlf bGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfY3Vyc2VzX2NsZWFyPXllcworICBp ZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9P Q0FNTE1LVE9QPSIkYWNfY3RfT0NBTUxNS1RPUCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl IHRlc3QuCiBlbHNlCi0gIGFjX2N2X2xpYl9jdXJzZXNfY2xlYXI9bm8KK2FzX3NhdmVfSUZTPSRJ RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0 IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB TUxNS1RPUD0ib2NhbWxta3RvcCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVh ayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwogZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQot eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s aWJfY3Vyc2VzX2NsZWFyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIg PiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVu IDoKLSAgY3Vyc2VzPSJ5IgorYWNfY3RfT0NBTUxNS1RPUD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FN TE1LVE9QCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS1RPUCI7IHRoZW4KKyAgeyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LVE9Q IiA+JjUKKyRhc19lY2hvICIkYWNfY3RfT0NBTUxNS1RPUCIgPiY2OyB9CiBlbHNlCi0gIGN1cnNl cz0ibiIKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KKyAgaWYgdGVzdCAieCRhY19j dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh Y19jdF9PQ0FNTE1LVE9QCisgIGZpCiBlbHNlCi0gIGN1cnNlcz0ibiIKKyAgT0NBTUxNS1RPUD0i JGFjX2N2X3Byb2dfT0NBTUxNS1RPUCIKIGZpCiAKIAotYWNfZm5fY19jaGVja19oZWFkZXJfbW9u Z3JlbCAiJExJTkVOTyIgIm5jdXJzZXMuaCIgImFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giICIkYWNf aW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgPSB4 IiJ5ZXM7IHRoZW4gOgotCi0gICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiBjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBjbGVhciBpbiAtbG5jdXJzZXMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNf Y3ZfbGliX25jdXJzZXNfY2xlYXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAjIGNoZWNraW5nIGZv ciBvY2FtbG1rbGliCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWIiLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9b2NhbWxta2xpYjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Byb2df T0NBTUxNS0xJQitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1sbmN1cnNl cyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0v KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw bHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgY2xlYXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsK LXJldHVybiBjbGVhciAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5f Y190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj15 ZXMKKyAgaWYgdGVzdCAtbiAiJE9DQU1MTUtMSUIiOyB0aGVuCisgIGFjX2N2X3Byb2dfT0NBTUxN S0xJQj0iJE9DQU1MTUtMSUIiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgogZWxz ZQotICBhY19jdl9saWJfbmN1cnNlc19jbGVhcj1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQ QVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lG UworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBp biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19k aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIke2FjX3Rv b2xfcHJlZml4fW9jYW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKIGZpCi1ybSAtZiBj b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19l eGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf bGliX25jdXJzZXNfY2xlYXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbmN1cnNlc19jbGVh ciIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA9IHgiInllczsg dGhlbiA6Ci0gIG5jdXJzZXM9InkiCitPQ0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIK K2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRP Q0FNTE1LTElCIiA+JjY7IH0KIGVsc2UKLSAgbmN1cnNlcz0ibiIKKyAgeyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIg PiY2OyB9CiBmaQogCiAKLWVsc2UKLSAgbmN1cnNlcz0ibiIKIGZpCi0KLQotaWYgdGVzdCAiJGN1 cnNlcyIgPSAibiIgJiYgdGVzdCAiJG5jdXJzZXMiID0gIm4iOyB0aGVuIDoKLQotICAgIGFzX2Zu X2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBhIHN1aXRhYmxlIGN1cnNlcyBsaWJyYXJ5IiAiJExJ TkVOTyIgNQoraWYgdGVzdCAteiAiJGFjX2N2X3Byb2dfT0NBTUxNS0xJQiI7IHRoZW4KKyAgYWNf Y3RfT0NBTUxNS0xJQj0kT0NBTUxNS0xJQgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg Im9jYW1sbWtsaWIiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0 IGR1bW15IG9jYW1sbWtsaWI7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2Fj X2N0X09DQU1MTUtMSUIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAg YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCPSIkYWNfY3RfT0NBTUxNS0xJQiIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9Im9j YW1sbWtsaWIiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91 bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKIGZpCi0jIFByZWZlciBuY3Vyc2VzIG92 ZXIgY3Vyc2VzIGlmIGJvdGggYXJlIHByZXNlbnQKLWlmIHRlc3QgIiRuY3Vyc2VzIiA9ICJ5Ijsg dGhlbiA6Ci0KLSAgICBDVVJTRVNfTElCUz0iLWxuY3Vyc2VzIgotCi0kYXNfZWNobyAiI2RlZmlu ZSBJTkNMVURFX0NVUlNFU19IIDxuY3Vyc2VzLmg+IiA+PmNvbmZkZWZzLmgKLQotCitmaQorYWNf Y3RfT0NBTUxNS0xJQj0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LTElCCitpZiB0ZXN0IC1uICIk YWNfY3RfT0NBTUxNS0xJQiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v LSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9PQ0FNTE1LTElCIiA+JjUKKyRhc19lY2hvICIkYWNf Y3RfT0NBTUxNS0xJQiIgPiY2OyB9CiBlbHNlCi0KLSAgICBDVVJTRVNfTElCUz0iLWxjdXJzZXMi Ci0KLSRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPGN1cnNlcy5oPiIgPj5jb25m ZGVmcy5oCi0KLQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KIGZpCiAKKyAgaWYgdGVzdCAieCRh Y19jdF9PQ0FNTE1LTElCIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LTElCPSJubyIKKyAgZWxzZQor ICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3Nz IHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFz X21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy aXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LTElC PSRhY19jdF9PQ0FNTE1LTElCCisgIGZpCitlbHNlCisgIE9DQU1MTUtMSUI9IiRhY19jdl9wcm9n X09DQU1MTUtMSUIiCitmaQogCiAKLQotCi0KLQotCi1pZiB0ZXN0ICJ4JGFjX2N2X2Vudl9QS0df Q09ORklHX3NldCIgIT0gInhzZXQiOyB0aGVuCi0JaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4 IjsgdGhlbgotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9 cGtnLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCi1zZXQg ZHVtbXkgJHthY190b29sX3ByZWZpeH1wa2ctY29uZmlnOyBhY193b3JkPSQyCisgICMgY2hlY2tp bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCiB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiAkYXNfZWNob19uICJj aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfcGF0aF9Q S0dfQ09ORklHK3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgIiR7YWNfY3ZfcHJvZ19PQ0FN TERPQytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBl bHNlCi0gIGNhc2UgJFBLR19DT05GSUcgaW4KLSAgW1xcL10qIHwgPzpbXFwvXSopCi0gIGFjX2N2 X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRo ZSB0ZXN0IHdpdGggYSBwYXRoLgotICA7OwotICAqKQotICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9 JFBBVEhfU0VQQVJBVE9SCisgIGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3Zf cHJvZ19PQ0FNTERPQz0iJE9DQU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKIGZvciBhc19k aXIgaW4gJFBBVEgKIGRvCiAgIElGUz0kYXNfc2F2ZV9JRlMKICAgdGVzdCAteiAiJGFzX2RpciIg JiYgYXNfZGlyPS4KICAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0 ZW5zaW9uczsgZG8KICAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgot ICAgIGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIK KyAgICBhY19jdl9wcm9nX09DQU1MRE9DPSIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIgogICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY5NDEsMTMgKzQ1 OTYsMTIgQEAgZG9uZQogICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVzYWMKIGZp Ci1QS0dfQ09ORklHPSRhY19jdl9wYXRoX1BLR19DT05GSUcKLWlmIHRlc3QgLW4gIiRQS0dfQ09O RklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJFBLR19DT05GSUciID4mNQotJGFzX2VjaG8gIiRQS0dfQ09ORklHIiA+JjY7IH0KK2Zp CitPQ0FNTERPQz0kYWNfY3ZfcHJvZ19PQ0FNTERPQworaWYgdGVzdCAtbiAiJE9DQU1MRE9DIjsg dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JE9DQU1MRE9DIiA+JjUKKyRhc19lY2hvICIkT0NBTUxET0MiID4mNjsgfQogZWxzZQogICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFz X2VjaG8gIm5vIiA+JjY7IH0KQEAgLTY5NTUsMjggKzQ2MDksMjYgQEAgZmkKIAogCiBmaQotaWYg dGVzdCAteiAiJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyI7IHRoZW4KLSAgYWNfcHRfUEtHX0NPTkZJ Rz0kUEtHX0NPTkZJRwotICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInBrZy1jb25maWci LCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgotc2V0IGR1bW15IHBrZy1j b25maWc7IGFjX3dvcmQ9JDIKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MRE9DIjsgdGhl bgorICBhY19jdF9PQ0FNTERPQz0kT0NBTUxET0MKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICJvY2FtbGRvYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz ZXQgZHVtbXkgb2NhbWxkb2M7IGFjX3dvcmQ9JDIKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKICRhc19lY2hvX24gImNo ZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9wYXRoX2Fj X3B0X1BLR19DT05GSUcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAiJHthY19jdl9wcm9n X2FjX2N0X09DQU1MRE9DK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl ZCkgIiA+JjYKIGVsc2UKLSAgY2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgotICBbXFwvXSogfCA/ OltcXC9dKikKLSAgYWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJ RyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCi0gIDs7Ci0g ICopCi0gIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKKyAgaWYgdGVzdCAt biAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MRE9DPSIk YWNfY3RfT0NBTUxET0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQor YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgogZm9yIGFzX2RpciBpbiAkUEFU SAogZG8KICAgSUZTPSRhc19zYXZlX0lGUwogICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgogICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bwogICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCi0gICAgYWNfY3Zf cGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg IGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9jYW1sZG9jIgogICAgICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l eHQiID4mNQogICAgIGJyZWFrIDIKICAgZmkKQEAgLTY5ODQsMjAgKzQ2MzYsMTkgQEAgZG9uZQog ICBkb25lCiBJRlM9JGFzX3NhdmVfSUZTCiAKLSAgOzsKLWVzYWMKIGZpCi1hY19wdF9QS0dfQ09O RklHPSRhY19jdl9wYXRoX2FjX3B0X1BLR19DT05GSUcKLWlmIHRlc3QgLW4gIiRhY19wdF9QS0df Q09ORklHIjsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX3B0X1BLR19DT05GSUciID4mNQotJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09O RklHIiA+JjY7IH0KK2ZpCithY19jdF9PQ0FNTERPQz0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERP QworaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MRE9DIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MRE9DIiA+JjUKKyRh c19lY2hvICIkYWNfY3RfT0NBTUxET0MiID4mNjsgfQogZWxzZQogICB7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQogJGFzX2VjaG8gIm5vIiA+ JjY7IH0KIGZpCiAKLSAgaWYgdGVzdCAieCRhY19wdF9QS0dfQ09ORklHIiA9IHg7IHRoZW4KLSAg ICBQS0dfQ09ORklHPSIiCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxET0MiID0geDsgdGhlbgor ICAgIE9DQU1MRE9DPSJubyIKICAgZWxzZQogICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNf dG9vbF93YXJuZWQgaW4KIHllczopCkBAIC03MDA1LDYyNCArNDY1Niw3MTggQEAgeWVzOikKICRh c19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3 aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KIGFjX3Rvb2xfd2FybmVkPXllcyA7OwogZXNhYwotICAg IFBLR19DT05GSUc9JGFjX3B0X1BLR19DT05GSUcKKyAgICBPQ0FNTERPQz0kYWNfY3RfT0NBTUxE T0MKICAgZmkKIGVsc2UKLSAgUEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NPTkZJRyIKLWZp Ci0KLWZpCi1pZiB0ZXN0IC1uICIkUEtHX0NPTkZJRyI7IHRoZW4KLQlfcGtnX21pbl92ZXJzaW9u PTAuOS4wCi0JeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu ZyBwa2ctY29uZmlnIGlzIGF0IGxlYXN0IHZlcnNpb24gJF9wa2dfbWluX3ZlcnNpb24iID4mNQot JGFzX2VjaG9fbiAiY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtn X21pbl92ZXJzaW9uLi4uICIgPiY2OyB9Ci0JaWYgJFBLR19DT05GSUcgLS1hdGxlYXN0LXBrZ2Nv bmZpZy12ZXJzaW9uICRfcGtnX21pbl92ZXJzaW9uOyB0aGVuCi0JCXsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQotJGFzX2VjaG8gInllcyIg PiY2OyB9Ci0JZWxzZQotCQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLQkJUEtHX0NPTkZJRz0iIgot CWZpCi1maQotCi1wa2dfZmFpbGVkPW5vCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGNoZWNraW5nIGZvciBnbGliIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBnbGliLi4uICIgPiY2OyB9Ci0KLWlmIHRlc3QgLW4gIiRnbGliX0NGTEFHUyI7IHRoZW4KLSAg ICBwa2dfY3ZfZ2xpYl9DRkxBR1M9IiRnbGliX0NGTEFHUyIKLSBlbGlmIHRlc3QgLW4gIiRQS0df Q09ORklHIjsgdGhlbgotICAgIGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCi0gICAgeyB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4 aXN0cyAtLXByaW50LWVycm9ycyBcImdsaWItMi4wXCIiOyB9ID4mNQotICAoJFBLR19DT05GSUcg LS1leGlzdHMgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIikgMj4mNQotICBhY19zdGF0dXM9JD8K LSAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1 cyIgPiY1Ci0gIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH07IHRoZW4KLSAgcGtnX2N2X2dsaWJfQ0ZM QUdTPWAkUEtHX0NPTkZJRyAtLWNmbGFncyAiZ2xpYi0yLjAiIDI+L2Rldi9udWxsYAotZWxzZQot ICBwa2dfZmFpbGVkPXllcwotZmkKLSBlbHNlCi0gICAgcGtnX2ZhaWxlZD11bnRyaWVkCi1maQot aWYgdGVzdCAtbiAiJGdsaWJfTElCUyI7IHRoZW4KLSAgICBwa2dfY3ZfZ2xpYl9MSUJTPSIkZ2xp Yl9MSUJTIgotIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCi0gICAgaWYgdGVzdCAt biAiJFBLR19DT05GSUciICYmIFwKLSAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0y LjBcIiI7IH0gPiY1Ci0gICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xp Yi0yLjAiKSAyPiY1Ci0gIGFjX3N0YXR1cz0kPwotICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKLSAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfTsgdGhlbgotICBwa2dfY3ZfZ2xpYl9MSUJTPWAkUEtHX0NPTkZJRyAtLWxpYnMgImdsaWIt Mi4wIiAyPi9kZXYvbnVsbGAKLWVsc2UKLSAgcGtnX2ZhaWxlZD15ZXMKLWZpCi0gZWxzZQotICAg IHBrZ19mYWlsZWQ9dW50cmllZAotZmkKLQotCi0KLWlmIHRlc3QgJHBrZ19mYWlsZWQgPSB5ZXM7 IHRoZW4KLSAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogbm8iID4mNQotJGFzX2VjaG8gIm5vIiA+JjY7IH0KLQotaWYgJFBLR19DT05GSUcgLS1hdGxl YXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRoZW4KLSAgICAgICAgX3BrZ19zaG9ydF9lcnJv cnNfc3VwcG9ydGVkPXllcwotZWxzZQotICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0 ZWQ9bm8KKyAgT0NBTUxET0M9IiRhY19jdl9wcm9nX09DQU1MRE9DIgogZmkKLSAgICAgICAgaWYg dGVzdCAkX3BrZ19zaG9ydF9lcnJvcnNfc3VwcG9ydGVkID0geWVzOyB0aGVuCi0JICAgICAgICBn bGliX1BLR19FUlJPUlM9YCRQS0dfQ09ORklHIC0tc2hvcnQtZXJyb3JzIC0tcHJpbnQtZXJyb3Jz ICJnbGliLTIuMCIgMj4mMWAKLSAgICAgICAgZWxzZQotCSAgICAgICAgZ2xpYl9QS0dfRVJST1JT PWAkUEtHX0NPTkZJRyAtLXByaW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCi0gICAgICAgIGZp Ci0JIyBQdXQgdGhlIG5hc3R5IGVycm9yIG1lc3NhZ2UgaW4gY29uZmlnLmxvZyB3aGVyZSBpdCBi ZWxvbmdzCi0JZWNobyAiJGdsaWJfUEtHX0VSUk9SUyIgPiY1Ci0KLQlhc19mbl9lcnJvciAkPyAi UGFja2FnZSByZXF1aXJlbWVudHMgKGdsaWItMi4wKSB3ZXJlIG5vdCBtZXQ6Ci0KLSRnbGliX1BL R19FUlJPUlMKLQotQ29uc2lkZXIgYWRqdXN0aW5nIHRoZSBQS0dfQ09ORklHX1BBVEggZW52aXJv bm1lbnQgdmFyaWFibGUgaWYgeW91Ci1pbnN0YWxsZWQgc29mdHdhcmUgaW4gYSBub24tc3RhbmRh cmQgcHJlZml4LgotCi1BbHRlcm5hdGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQg dmFyaWFibGVzIGdsaWJfQ0ZMQUdTCi1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRv IGNhbGwgcGtnLWNvbmZpZy4KLVNlZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBk ZXRhaWxzLiIgIiRMSU5FTk8iIDUKLWVsaWYgdGVzdCAkcGtnX2ZhaWxlZCA9IHVudHJpZWQ7IHRo ZW4KLSAgICAgCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiBubyIgPiY1Ci0kYXNfZWNobyAibm8iID4mNjsgfQotCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQotJGFzX2VjaG8g IiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQotYXNfZm5fZXJyb3IgJD8gIlRo ZSBwa2ctY29uZmlnIHNjcmlwdCBjb3VsZCBub3QgYmUgZm91bmQgb3IgaXMgdG9vIG9sZC4gIE1h a2Ugc3VyZSBpdAotaXMgaW4geW91ciBQQVRIIG9yIHNldCB0aGUgUEtHX0NPTkZJRyBlbnZpcm9u bWVudCB2YXJpYWJsZSB0byB0aGUgZnVsbAotcGF0aCB0byBwa2ctY29uZmlnLgogCi1BbHRlcm5h dGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdT Ci1hbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KLVNl ZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgogCi1UbyBnZXQgcGtn LWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4KLVNlZSBc YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQorICAjIGNoZWNr aW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sYnVp bGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7 YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2 X3Byb2dfT0NBTUxCVUlMRCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0JZ2xpYl9DRkxBR1M9JHBrZ19jdl9nbGliX0NGTEFHUwotCWdsaWJf TElCUz0kcGtnX2N2X2dsaWJfTElCUwotICAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKLSRhc19lY2hvICJ5ZXMiID4mNjsgfQot Ci1maQotCi0jIENoZWNrIGxpYnJhcnkgcGF0aAotaWYgdGVzdCAiXCR7ZXhlY19wcmVmaXh9L2xp YiIgPSAiJGxpYmRpciI7IHRoZW4gOgotICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgiID0gIk5PTkUi ICYmIHRlc3QgIiRwcmVmaXgiICE9ICJOT05FIjsgdGhlbiA6Ci0gIGV4ZWNfcHJlZml4PSRwcmVm aXgKLWZpCi0gICAgaWYgdGVzdCAiJGV4ZWNfcHJlZml4IiA9ICJOT05FIjsgdGhlbiA6Ci0gIGV4 ZWNfcHJlZml4PSRhY19kZWZhdWx0X3ByZWZpeAotZmkKLSAgICBpZiB0ZXN0IC1kICIke2V4ZWNf cHJlZml4fS9saWI2NCI7IHRoZW4gOgotCi0gICAgICAgIExJQl9QQVRIPSJsaWI2NCIKLQorICBp ZiB0ZXN0IC1uICIkT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEJVSUxEPSIk T0NBTUxCVUlMRCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCiBlbHNlCi0KLSAg ICAgICAgTElCX1BBVEg9ImxpYiIKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4 ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1v Y2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZv dW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkK K2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUwogCiBmaQotCi1lbHNlCi0KLSAgICBMSUJf UEFUSD0iJHtsaWJkaXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVmaXgiICsgMWB9IgotCiBmaQot Ci0KLSMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCi1hY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVs ICIkTElORU5PIiAiYnpsaWIuaCIgImFjX2N2X2hlYWRlcl9iemxpYl9oIiAiJGFjX2luY2x1ZGVz X2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9iemxpYl9oIiA9IHgiInllczsgdGhl biA6Ci0KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yIEJaMl9iekRlY29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKLSRhc19lY2hvX24gImNoZWNr aW5nIGZvciBCWjJfYnpEZWNvbXByZXNzSW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0K3NldH0iID0gc2V0OyB0aGVu IDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3Nh dmVfTElCUz0kTElCUwotTElCUz0iLWxiejIgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9B Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotCi0vKiBPdmVy cmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVz ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwot ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw cGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIEJa Ml9iekRlY29tcHJlc3NJbml0ICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gQloyX2J6RGVj b21wcmVzc0luaXQgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFjX2ZuX2Nf dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXBy ZXNzSW5pdD15ZXMKK09DQU1MQlVJTEQ9JGFjX2N2X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAt biAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQi ID4mNjsgfQogZWxzZQotICBhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PW5vCi1m aQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29u ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZl X0xJQlMKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNf Y3ZfbGliX2J6Ml9CWjJfYnpEZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgotICB6bGli PSIkemxpYiAtREhBVkVfQlpMSUIgLWxiejIiCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkK IAogCiBmaQotCi0KLWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem1h LmgiICJhY19jdl9oZWFkZXJfbHptYV9oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0 ICJ4JGFjX2N2X2hlYWRlcl9sem1hX2giID0geCIieWVzOyB0aGVuIDoKLQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVj b2RlciBpbiAtbGx6bWEiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bWFfc3RyZWFt X2RlY29kZXIgaW4gLWxsem1hLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9sem1h X2x6bWFfc3RyZWFtX2RlY29kZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgoraWYgdGVzdCAteiAiJGFj X2N2X3Byb2dfT0NBTUxCVUlMRCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxCVUlMRD0kT0NBTUxCVUlM RAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sYnVpbGQiLCBzbyBpdCBjYW4g YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sYnVpbGQ7IGFjX3dv cmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAi ID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQrc2V0fSIgPSBz ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBhY19jaGVj a19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGx6bWEgICRMSUJTIgotY2F0IGNvbmZkZWZz LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwot Ci0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv ZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk IHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlm Ci1jaGFyIGx6bWFfc3RyZWFtX2RlY29kZXIgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBs em1hX3N0cmVhbV9kZWNvZGVyICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBh Y19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9sem1hX2x6bWFf c3RyZWFtX2RlY29kZXI9eWVzCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTEJVSUxEIjsgdGhl bgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQ9IiRhY19jdF9PQ0FNTEJVSUxEIiAjIExl dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KIGVsc2UKLSAgYWNfY3ZfbGliX2x6bWFfbHpt YV9zdHJlYW1fZGVjb2Rlcj1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16 ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi OyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxEPSJvY2FtbGJ1aWxkIgor ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u ZQorSUZTPSRhc19zYXZlX0lGUworCiBmaQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQK LUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2Rl Y29kZXIiID4mNQotJGFzX2VjaG8gIiRhY19jdl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVy IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIg PSB4IiJ5ZXM7IHRoZW4gOgotICB6bGliPSIkemxpYiAtREhBVkVfTFpNQSAtbGx6bWEiCithY19j dF9PQ0FNTEJVSUxEPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQlVJTEQKK2lmIHRlc3QgLW4gIiRh Y19jdF9PQ0FNTEJVSUxEIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MQlVJTEQiID4mNQorJGFzX2VjaG8gIiRhY19j dF9PQ0FNTEJVSUxEIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQog Ci0KKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJV SUxEPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJu ZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB Uk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIg PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJl Zml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2Vz YWMKKyAgICBPQ0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1M QlVJTEQ9IiRhY19jdl9wcm9nX09DQU1MQlVJTEQiCiBmaQogCiAKLWFjX2ZuX2NfY2hlY2tfaGVh ZGVyX21vbmdyZWwgIiRMSU5FTk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpv MXhfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHpv X2x6bzF4X2giID0geCIieWVzOyB0aGVuIDoKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAieG5v IjsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl Y2tpbmcgZm9yIGx6bzF4X2RlY29tcHJlc3MgaW4gLWxsem8yIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIGZvciBsem8xeF9kZWNvbXByZXNzIGluIC1sbHpvMi4uLiAiID4mNjsgfQotaWYgdGVz dCAiJHthY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVf TElCUz0kTElCUwotTElCUz0iLWxsem8yICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyAgICAgICAgaWYg dGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyI7IHRoZW4gOgogCi0vKiBPdmVycmlk ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBj aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAg YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGx6bzF4 X2RlY29tcHJlc3MgKCk7Ci1pbnQKLW1haW4gKCkKLXsKLXJldHVybiBsem8xeF9kZWNvbXByZXNz ICgpOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9eWVzCi1l bHNlCi0gIGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3M9bm8KLWZpCi1ybSAtZiBjb3Jl IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVl eHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICAgICAg ICAgICAgYXNfZm5fZXJyb3IgJD8gIk9jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUgdG8g ZmluZCBPY2FtbCIgIiRMSU5FTk8iIDUKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4m NQotJGFzX2VjaG8gIiRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA+JjY7IH0KLWlm IHRlc3QgIngkYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4g OgotICB6bGliPSIkemxpYiAtREhBVkVfTFpPMVggLWxsem8yIgorICAgICAgICBvY2FtbHRvb2xz PSJuIgorCiBmaQogCitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJiYXNoIiwgc28g aXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBiYXNoOyBhY193 b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQVNIK3NldH0iID0gc2V0OyB0aGVuIDoK KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkQkFTSCBpbgorICBb XFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9CQVNIPSIkQkFTSCIgIyBMZXQgdGhlIHVz ZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVf SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfQkFT SD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+ JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKIAor ICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CQVNIIiAmJiBhY19jdl9wYXRoX0JBU0g9Im5vIgorICA7 OworZXNhYworZmkKK0JBU0g9JGFjX2N2X3BhdGhfQkFTSAoraWYgdGVzdCAtbiAiJEJBU0giOyB0 aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk QkFTSCIgPiY1CiskYXNfZWNobyAiJEJBU0giID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v IiA+JjY7IH0KIGZpCiAKIAoraWYgdGVzdCB4IiR7QkFTSH0iID09IHgibm8iCit0aGVuCisgICAg YXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJhc2gsIHBsZWFzZSBpbnN0YWxsIGJhc2gi ICIkTElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciBpb19zZXR1cCBpbiAtbGFpbyIgPiY1Ci0kYXNfZWNob19uICJjaGVj a2luZyBmb3IgaW9fc2V0dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf bGliX2Fpb19pb19zZXR1cCtzZXR9IiA9IHNldDsgdGhlbiA6CithY19leHQ9YworYWNfY3BwPSck Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29y IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29y Li4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5 LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KKyAgQ1BQPQorZmkK K2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmIHRlc3QgIiR7YWNfY3ZfcHJvZ19DUFArc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBh Y19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGFpbyAgJExJQlMiCi1jYXQgY29u ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisgICAgICAjIERvdWJsZSBxdW90 ZXMgYmVjYXVzZSBDUFAgbmVlZHMgdG8gYmUgZXhwYW5kZWQKKyAgICBmb3IgQ1BQIGluICIkQ0Mg LUUiICIkQ0MgLUUgLXRyYWRpdGlvbmFsLWNwcCIgIi9saWIvY3BwIgorICAgIGRvCisgICAgICBh Y19wcmVwcm9jX29rPWZhbHNlCitmb3IgYWNfY19wcmVwcm9jX3dhcm5fZmxhZyBpbiAnJyB5ZXMK K2RvCisgICMgVXNlIGEgaGVhZGVyIGZpbGUgdGhhdCBjb21lcyB3aXRoIGdjYywgc28gY29uZmln dXJpbmcgZ2xpYmMKKyAgIyB3aXRoIGEgZnJlc2ggY3Jvc3MtY29tcGlsZXIgd29ya3MuCisgICMg UHJlZmVyIDxsaW1pdHMuaD4gdG8gPGFzc2VydC5oPiBpZiBfX1NURENfXyBpcyBkZWZpbmVkLCBz aW5jZQorICAjIDxsaW1pdHMuaD4gZXhpc3RzIGV2ZW4gb24gZnJlZXN0YW5kaW5nIGNvbXBpbGVy cy4KKyAgIyBPbiB0aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21w aWxlcidzIHBhcnNlciwKKyAgIyBub3QganVzdCB0aHJvdWdoIGNwcC4gIlN5bnRheCBlcnJvciIg aXMgaGVyZSB0byBjYXRjaCB0aGlzIGNhc2UuCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLQotLyogT3ZlcnJpZGUg YW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hh ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g ICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKKyNpZmRlZiBfX1NURENfXworIyBp bmNsdWRlIDxsaW1pdHMuaD4KKyNlbHNlCisjIGluY2x1ZGUgPGFzc2VydC5oPgogI2VuZGlmCi1j aGFyIGlvX3NldHVwICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4gaW9fc2V0dXAgKCk7Ci0g IDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3ludGF4IGVycm9yCiBfQUNFT0YKLWlmIGFjX2Zu X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfbGliX2Fpb19pb19zZXR1cD15 ZXMKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorCiBlbHNlCi0gIGFjX2N2 X2xpYl9haW9faW9fc2V0dXA9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVz dC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAot TElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQg aW5wdXQuCitjb250aW51ZQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO RU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY1Ci0kYXNfZWNobyAiJGFj X2N2X2xpYl9haW9faW9fc2V0dXAiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfYWlvX2lv X3NldHVwIiA9IHgiInllczsgdGhlbiA6Ci0gIHN5c3RlbV9haW89InkiCitybSAtZiBjb25mdGVz dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisKKyAgIyBPSywgd29ya3Mgb24gc2Fu ZSBjYXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKKyAgIyBjYW4g YmUgZGV0ZWN0ZWQgYW5kIGhvdy4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRl c3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPGFjX25vbmV4aXN0 ZW50Lmg+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorICAj IEJyb2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgorY29udGludWUKIGVsc2UKLSAgc3lz dGVtX2Fpbz0ibiIKKyAgIyBQYXNzZXMgYm90aCB0ZXN0cy4KK2FjX3ByZXByb2Nfb2s9OgorYnJl YWsKK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisK K2RvbmUKKyMgQmVjYXVzZSBvZiBgYnJlYWsnLCBfQUNfUFJFUFJPQ19JRkVMU0UncyBjbGVhbmlu ZyBjb2RlIHdhcyBza2lwcGVkLgorcm0gLWYgY29uZnRlc3QuaSBjb25mdGVzdC5lcnIgY29uZnRl c3QuJGFjX2V4dAoraWYgJGFjX3ByZXByb2Nfb2s7IHRoZW4gOgorICBicmVhawogZmkKIAorICAg IGRvbmUKKyAgICBhY19jdl9wcm9nX0NQUD0kQ1BQCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIE1ENSBpbiAtbGNyeXB0byIgPiY1Ci0kYXNf ZWNob19uICJjaGVja2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X2xpYl9jcnlwdG9fTUQ1K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKK2ZpCisgIENQUD0kYWNfY3ZfcHJvZ19DUFAKIGVsc2UKLSAgYWNf Y2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWxjcnlwdG8gICRMSUJTIgotY2F0IGNv bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jdl9wcm9nX0NQUD0k Q1BQCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRDUFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNfcHJlcHJvY19vaz1mYWxzZQor Zm9yIGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRl ciBmaWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0 aCBhIGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRv IDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+ IGV4aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQs IGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMg bm90IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhp cyBjYXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAv KiBlbmQgY29uZmRlZnMuaC4gICovCi0KLS8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJv dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0gICBidWlsdGluIGFuZCB0aGVuIGl0cyBh cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwotI2lmZGVmIF9fY3BsdXNw bHVzCi1leHRlcm4gIkMiCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+Cisj ZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KICNlbmRpZgotY2hhciBNRDUgKCk7Ci1pbnQKLW1h aW4gKCkKLXsKLXJldHVybiBNRDUgKCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19CisJCSAgICAgU3lu dGF4IGVycm9yCiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoK LSAgYWNfY3ZfbGliX2NyeXB0b19NRDU9eWVzCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8i OyB0aGVuIDoKKwogZWxzZQotICBhY19jdl9saWJfY3J5cHRvX01ENT1ubwotZmkKLXJtIC1mIGNv cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4 ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisgICMg QnJva2VuOiBmYWlscyBvbiB2YWxpZCBpbnB1dC4KK2NvbnRpbnVlCiBmaQoteyAkYXNfZWNobyAi JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01E NSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KLWlmIHRlc3Qg IngkYWNfY3ZfbGliX2NyeXB0b19NRDUiID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRl ZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBIQVZFX0xJQkNSWVBUTyAxCitybSAtZiBjb25mdGVzdC5l cnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CisKKyAgIyBPSywgd29ya3Mgb24gc2FuZSBj YXNlcy4gIE5vdyBjaGVjayB3aGV0aGVyIG5vbmV4aXN0ZW50IGhlYWRlcnMKKyAgIyBjYW4gYmUg ZGV0ZWN0ZWQgYW5kIGhvdy4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPGFjX25vbmV4aXN0ZW50 Lmg+CiBfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7IHRoZW4gOgorICAjIEJy b2tlbjogc3VjY2VzcyBvbiBpbnZhbGlkIGlucHV0LgorY29udGludWUKK2Vsc2UKKyAgIyBQYXNz ZXMgYm90aCB0ZXN0cy4KK2FjX3ByZXByb2Nfb2s9OgorYnJlYWsKK2ZpCitybSAtZiBjb25mdGVz dC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0CiAKLSAgTElCUz0iLWxjcnlwdG8gJExJ QlMiCitkb25lCisjIEJlY2F1c2Ugb2YgYGJyZWFrJywgX0FDX1BSRVBST0NfSUZFTFNFJ3MgY2xl YW5pbmcgY29kZSB3YXMgc2tpcHBlZC4KK3JtIC1mIGNvbmZ0ZXN0LmkgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19leHQKK2lmICRhY19wcmVwcm9jX29rOyB0aGVuIDoKIAogZWxzZQotICBhc19m bl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIgNQorICB7IHsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3 ZCc6IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30K K2FzX2ZuX2Vycm9yICQ/ICJDIHByZXByb2Nlc3NvciBcIiRDUFBcIiBmYWlscyBzYW5pdHkgY2hl Y2sKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQog ZmkKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm b3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3Zf bGliX2V4dDJmc19leHQyZnNfb3BlbjIrc2V0fSIgPSBzZXQ7IHRoZW4gOgorYWNfZXh0PWMKK2Fj X2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxB R1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhl ZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1 JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5k bGVzIGxvbmcgbGluZXMgYW5kIC1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVw IHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth Y19jdl9wYXRoX0dSRVArc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVk KSAiID4mNgogZWxzZQotICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbGV4 dDJmcyAgJExJQlMiCi1jYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCisgIGlmIHRlc3QgLXogIiRHUkVQIjsgdGhlbgorICBh Y19wYXRoX0dSRVBfZm91bmQ9ZmFsc2UKKyAgIyBMb29wIHRocm91Z2ggdGhlIHVzZXIncyBwYXRo IGFuZCB0ZXN0IGZvciBlYWNoIG9mIFBST0dOQU1FLUxJU1QKKyAgYXNfc2F2ZV9JRlM9JElGUzsg SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91 c3IveHBnNC9iaW4KK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfcHJvZyBpbiBncmVwIGdncmVwOyBkbworICAgIGZvciBh Y19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNf cGF0aF9HUkVQPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1m ICIkYWNfcGF0aF9HUkVQIiAmJiAkYXNfdGVzdF94ICIkYWNfcGF0aF9HUkVQIjsgfSB8fCBjb250 aW51ZQorIyBDaGVjayBmb3IgR05VIGFjX3BhdGhfR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlz IGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUgJGFjX3BhdGhfR1JFUAorY2FzZSBgIiRhY19wYXRo X0dSRVAiIC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfR1JFUD0iJGFj X3BhdGhfR1JFUCIgYWNfcGF0aF9HUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAk YXNfZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAg IGNhdCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYg ImNvbmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0 ZXN0Lm5sIgorICAgICRhc19lY2hvICdHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19w YXRoX0dSRVAiIC1lICdHUkVQJCcgLWUgJy0oY2Fubm90IG1hdGNoKS0nIDwgImNvbmZ0ZXN0Lm5s IiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25mdGVz dC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNfZm5f YXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAkYWNf Y291bnQgLWd0ICR7YWNfcGF0aF9HUkVQX21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBz byBmYXIsIHNhdmUgaXQgYnV0IGtlZXAgbG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBh Y19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiCisgICAgICBhY19wYXRoX0dSRVBfbWF4PSRh Y19jb3VudAorICAgIGZpCisgICAgIyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9y ZSB0aGFuIGVub3VnaAorICAgIHRlc3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25l CisgIHJtIC1mIGNvbmZ0ZXN0LmluIGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5v dXQ7OworZXNhYwogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBh dm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSBy ZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJv dG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVzcGx1cwotZXh0ZXJu ICJDIgotI2VuZGlmCi1jaGFyIGV4dDJmc19vcGVuMiAoKTsKLWludAotbWFpbiAoKQotewotcmV0 dXJuIGV4dDJmc19vcGVuMiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfZXh0MmZzX2V4dDJm c19vcGVuMj15ZXMKKyAgICAgICRhY19wYXRoX0dSRVBfZm91bmQgJiYgYnJlYWsgMworICAgIGRv bmUKKyAgZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisgIGlmIHRlc3QgLXogIiRhY19j dl9wYXRoX0dSRVAiOyB0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZ3Jl cCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRIX1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIk TElORU5PIiA1CisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yPW5v CisgIGFjX2N2X3BhdGhfR1JFUD0kR1JFUAogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf ZXh0Ci1MSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCisKIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9leHQyZnNfZXh0MmZz X29wZW4yIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4m NjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPSB4IiJ5ZXM7 IHRoZW4gOgotICBsaWJleHQyZnM9InkiCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfR1JFUCIgPiY1CiskYXNfZWNobyAiJGFjX2N2 X3BhdGhfR1JFUCIgPiY2OyB9CisgR1JFUD0iJGFjX2N2X3BhdGhfR1JFUCIKKworCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBlZ3JlcCIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZWdyZXAuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7 YWNfY3ZfcGF0aF9FR1JFUCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0gIGxpYmV4dDJmcz0ibiIKKyAgaWYgZWNobyBhIHwgJEdSRVAgLUUg JyhhfGIpJyA+L2Rldi9udWxsIDI+JjEKKyAgIHRoZW4gYWNfY3ZfcGF0aF9FR1JFUD0iJEdSRVAg LUUiCisgICBlbHNlCisgICAgIGlmIHRlc3QgLXogIiRFR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9F R1JFUF9mb3VuZD1mYWxzZQorICAjIExvb3AgdGhyb3VnaCB0aGUgdXNlcidzIHBhdGggYW5kIHRl c3QgZm9yIGVhY2ggb2YgUFJPR05BTUUtTElTVAorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0 L2JpbgorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19k aXI9LgorICAgIGZvciBhY19wcm9nIGluIGVncmVwOyBkbworICAgIGZvciBhY19leGVjX2V4dCBp biAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICAgICAgYWNfcGF0aF9FR1JFUD0i JGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhf RUdSRVAiICYmICRhc190ZXN0X3ggIiRhY19wYXRoX0VHUkVQIjsgfSB8fCBjb250aW51ZQorIyBD aGVjayBmb3IgR05VIGFjX3BhdGhfRUdSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4K KyAgIyBDaGVjayBmb3IgR05VICRhY19wYXRoX0VHUkVQCitjYXNlIGAiJGFjX3BhdGhfRUdSRVAi IC0tdmVyc2lvbiAyPiYxYCBpbgorKkdOVSopCisgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRo X0VHUkVQIiBhY19wYXRoX0VHUkVQX2ZvdW5kPTo7OworKikKKyAgYWNfY291bnQ9MAorICAkYXNf ZWNob19uIDAxMjM0NTY3ODkgPiJjb25mdGVzdC5pbiIKKyAgd2hpbGUgOgorICBkbworICAgIGNh dCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5pbiIgPiJjb25mdGVzdC50bXAiCisgICAgbXYgImNv bmZ0ZXN0LnRtcCIgImNvbmZ0ZXN0LmluIgorICAgIGNwICJjb25mdGVzdC5pbiIgImNvbmZ0ZXN0 Lm5sIgorICAgICRhc19lY2hvICdFR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0 aF9FR1JFUCIgJ0VHUkVQJCcgPCAiY29uZnRlc3QubmwiID4iY29uZnRlc3Qub3V0IiAyPi9kZXYv bnVsbCB8fCBicmVhaworICAgIGRpZmYgImNvbmZ0ZXN0Lm91dCIgImNvbmZ0ZXN0Lm5sIiA+L2Rl di9udWxsIDI+JjEgfHwgYnJlYWsKKyAgICBhc19mbl9hcml0aCAkYWNfY291bnQgKyAxICYmIGFj X2NvdW50PSRhc192YWwKKyAgICBpZiB0ZXN0ICRhY19jb3VudCAtZ3QgJHthY19wYXRoX0VHUkVQ X21heC0wfTsgdGhlbgorICAgICAgIyBCZXN0IG9uZSBzbyBmYXIsIHNhdmUgaXQgYnV0IGtlZXAg bG9va2luZyBmb3IgYSBiZXR0ZXIgb25lCisgICAgICBhY19jdl9wYXRoX0VHUkVQPSIkYWNfcGF0 aF9FR1JFUCIKKyAgICAgIGFjX3BhdGhfRUdSRVBfbWF4PSRhY19jb3VudAorICAgIGZpCisgICAg IyAxMCooMl4xMCkgY2hhcnMgYXMgaW5wdXQgc2VlbXMgbW9yZSB0aGFuIGVub3VnaAorICAgIHRl c3QgJGFjX2NvdW50IC1ndCAxMCAmJiBicmVhaworICBkb25lCisgIHJtIC1mIGNvbmZ0ZXN0Lmlu IGNvbmZ0ZXN0LnRtcCBjb25mdGVzdC5ubCBjb25mdGVzdC5vdXQ7OworZXNhYworCisgICAgICAk YWNfcGF0aF9FR1JFUF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUK K0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfRUdSRVAiOyB0aGVu CisgICAgYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgZWdyZXAgY291bGQgYmUgZm91bmQg aW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluIiAiJExJTkVOTyIgNQorICBmaQor ZWxzZQorICBhY19jdl9wYXRoX0VHUkVQPSRFR1JFUAogZmkKIAorICAgZmkKK2ZpCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfRUdS RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9wYXRoX0VHUkVQIiA+JjY7IH0KKyBFR1JFUD0iJGFj X2N2X3BhdGhfRUdSRVAiCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxnY3J5cHQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVy K3NldH0iID0gc2V0OyB0aGVuIDoKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcyIgPiY1CiskYXNfZWNob19u ICJjaGVja2luZyBmb3IgQU5TSSBDIGhlYWRlciBmaWxlcy4uLiAiID4mNjsgfQoraWYgdGVzdCAi JHthY19jdl9oZWFkZXJfc3RkYytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj YWNoZWQpICIgPiY2CiBlbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9 Ii1sZ2NyeXB0ICAkTElCUyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh Y19leHQKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyog ZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFy Zy5oPgorI2luY2x1ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGZsb2F0Lmg+CiAKLS8qIE92ZXJy aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgotICAgVXNl IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCi0g ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLwotI2lmZGVmIF9fY3BsdXNwbHVzCi1leHRlcm4gIkMiCi0jZW5kaWYKLWNoYXIgZ2Ny eV9tZF9oYXNoX2J1ZmZlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIGdjcnlfbWRfaGFz aF9idWZmZXIgKCk7CisKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgotaWYgYWNfZm5fY190 cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFz aF9idWZmZXI9eWVzCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6Cisg IGFjX2N2X2hlYWRlcl9zdGRjPXllcwogZWxzZQotICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXI9bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf b2JqZXh0IFwKLSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0k YWNfY2hlY2tfbGliX3NhdmVfTElCUworICBhY19jdl9oZWFkZXJfc3RkYz1ubwogZmkKLXsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2dj cnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlw dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlw dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYmdjcnlwdD0ieSIK K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFj X2V4dAorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIFN1bk9T IDQueCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRvIEFOU0kuCisg IGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25m ZGVmcy5oLiAgKi8KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKworX0FDRU9GCitpZiAoZXZhbCAiJGFj X2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAibWVtY2hyIiA+L2Rldi9u dWxsIDI+JjE7IHRoZW4gOgorCiBlbHNlCi0gIGxpYmdjcnlwdD0ibiIKKyAgYWNfY3ZfaGVhZGVy X3N0ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKwogZmkKIAoraWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVj bGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9G ID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3Rk bGliLmg+CiAKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+ JjUgfAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CiAKLSAgICB7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFk IGZsYWciID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZy4uLiAiID4m NjsgfQotaWYgdGVzdCAiJHtheF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoK LSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9 bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKIAotICAgICAgICBheF9jdl9wdGhyZWFkX2ZsYWdzPS1w dGhyZWFkCitmaQogCi0gICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgot ICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVBRF9M SUJTPSIiCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3RkYyA9IHllczsgdGhlbgorICAjIC9iaW4v Y2MgaW4gSXJpeC00LjAuNSBnZXRzIG5vbi1BTlNJIGN0eXBlIG1hY3JvcyB1bmxlc3MgdXNpbmcg LWFuc2kuCisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgOgor ZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl bmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8Y3R5cGUuaD4KKyNpbmNsdWRlIDxzdGRsaWIu aD4KKyNpZiAoKCcgJyAmIDB4MEZGKSA9PSAweDAyMCkKKyMgZGVmaW5lIElTTE9XRVIoYykgKCdh JyA8PSAoYykgJiYgKGMpIDw9ICd6JykKKyMgZGVmaW5lIFRPVVBQRVIoYykgKElTTE9XRVIoYykg PyAnQScgKyAoKGMpIC0gJ2EnKSA6IChjKSkKKyNlbHNlCisjIGRlZmluZSBJU0xPV0VSKGMpIFwK KwkJICAgKCgnYScgPD0gKGMpICYmIChjKSA8PSAnaScpIFwKKwkJICAgICB8fCAoJ2onIDw9IChj KSAmJiAoYykgPD0gJ3InKSBcCisJCSAgICAgfHwgKCdzJyA8PSAoYykgJiYgKGMpIDw9ICd6Jykp CisjIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gKChjKSB8IDB4NDApIDogKGMpKQor I2VuZGlmCiAKKyNkZWZpbmUgWE9SKGUsIGYpICgoKGUpICYmICEoZikpIHx8ICghKGUpICYmIChm KSkpCitpbnQKK21haW4gKCkKK3sKKyAgaW50IGk7CisgIGZvciAoaSA9IDA7IGkgPCAyNTY7IGkr KykKKyAgICBpZiAoWE9SIChpc2xvd2VyIChpKSwgSVNMT1dFUiAoaSkpCisJfHwgdG91cHBlciAo aSkgIT0gVE9VUFBFUiAoaSkpCisgICAgICByZXR1cm4gMjsKKyAgcmV0dXJuIDA7Cit9CitfQUNF T0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgogCi0gICAgc2F2ZWRfQ0ZM QUdTPSIkQ0ZMQUdTIgorZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubworZmkKK3JtIC1mIGNv cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l eHQKK2ZpCiAKLSAgICBzYXZlZF9MREZMQUdTPSIkTERGTEFHUyIKK2ZpCitmaQoreyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3Rk YyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KK2lmIHRlc3QgJGFj X2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuCiAKLSAgICBzYXZlZF9MSUJTPSIkTElCUyIKKyRh c19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNvbmZkZWZzLmgKIAorZmkKIAotICAg IENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9DRkxBR1MiCisjIE9uIElSSVggNS4zLCBzeXMvdHlw ZXMgYW5kIGludHR5cGVzLmggYXJlIGNvbmZsaWN0aW5nLgorZm9yIGFjX2hlYWRlciBpbiBzeXMv dHlwZXMuaCBzeXMvc3RhdC5oIHN0ZGxpYi5oIHN0cmluZy5oIG1lbW9yeS5oIHN0cmluZ3MuaCBc CisJCSAgaW50dHlwZXMuaCBzdGRpbnQuaCB1bmlzdGQuaAorZG8gOgorICBhc19hY19IZWFkZXI9 YCRhc19lY2hvICJhY19jdl9oZWFkZXJfJGFjX2hlYWRlciIgfCAkYXNfdHJfc2hgCithY19mbl9j X2NoZWNrX2hlYWRlcl9jb21waWxlICIkTElORU5PIiAiJGFjX2hlYWRlciIgIiRhc19hY19IZWFk ZXIiICIkYWNfaW5jbHVkZXNfZGVmYXVsdAorIgoraWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY19I ZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj ZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEKK19BQ0VP RgogCi0gICAgTERGTEFHUz0iJExERkxBR1MgJFBUSFJFQURfTERGTEFHUyIKK2ZpCiAKLSAgICBM SUJTPSIkTElCUyAkUFRIUkVBRF9MSUJTIgorZG9uZQogCi0gICAgICAgIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAot I2luY2x1ZGUgPHB0aHJlYWQuaD4KLWludCBtYWluKHZvaWQpIHsKLSAgcHRocmVhZF9hdGZvcmso MCwwLDApOwotICBwdGhyZWFkX2NyZWF0ZSgwLDAsMCwwKTsKLX0KK2lmIHRlc3QgIngkcHl0aG9u dG9vbHMiID0gInh5IjsgdGhlbiA6CiAKLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJ TkVOTyI7IHRoZW4gOgorICAgIGlmIGVjaG8gIiRQWVRIT04iIHwgZ3JlcCAtcSAiXi8iOyB0aGVu IDoKIAorICAgICAgICBQWVRIT05QQVRIPSRQWVRIT04KKyAgICAgICAgUFlUSE9OPWBiYXNlbmFt ZSAkUFlUSE9OUEFUSGAKKworZWxpZiB0ZXN0IC16ICIkUFlUSE9OIjsgdGhlbiA6CisgIFBZVEhP Tj0icHl0aG9uIgogZWxzZQotICBheF9jdl9wdGhyZWFkX2ZsYWdzPWZhaWxlZAorICBhc19mbl9l cnJvciAkPyAiUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBhbiBhYnNvbHV0ZSBwYXRoIiAi JExJTkVOTyIgNQogZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl eHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgIyBFeHRy YWN0IHRoZSBmaXJzdCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3Qg IiR7YWNfY3ZfcGF0aF9QWVRIT05QQVRIK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9f biAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSog fCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQg dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFz X3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgK K2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4K KyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8K KyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVz dF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Bh dGhfUFlUSE9OUEFUSD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFj X2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNf c2F2ZV9JRlMKIAotICAgIENGTEFHUz0iJHNhdmVkX0NGTEFHUyIKKyAgdGVzdCAteiAiJGFjX2N2 X3BhdGhfUFlUSE9OUEFUSCIgJiYgYWNfY3ZfcGF0aF9QWVRIT05QQVRIPSJubyIKKyAgOzsKK2Vz YWMKK2ZpCitQWVRIT05QQVRIPSRhY19jdl9wYXRoX1BZVEhPTlBBVEgKK2lmIHRlc3QgLW4gIiRQ WVRIT05QQVRIIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJFBZVEhPTlBBVEgiID4mNQorJGFzX2VjaG8gIiRQWVRIT05QQVRIIiA+JjY7 IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQogCi0gICAgTERGTEFHUz0iJHNh dmVkX0xERkxBR1MiCiAKLSAgICBMSUJTPSIkc2F2ZWRfTElCUyIKK2lmIHRlc3QgeCIke1BZVEhP TlBBVEh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu ZCAkUFlUSE9OLCBwbGVhc2UgaW5zdGFsbCAkUFlUSE9OIiAiJExJTkVOTyIgNQorZmkKKyAgICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBweXRo b24gdmVyc2lvbiA+PSAyLjMgIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBweXRob24g dmVyc2lvbiA+PSAyLjMgLi4uICIgPiY2OyB9CitgJFBZVEhPTiAtYyAnaW1wb3J0IHN5czsgc3lz LmV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgyLCAzKSIpKSdgCitpZiB0ZXN0ICIkPyIg IT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249YCRQWVRIT04gLVYgMj4mMWAKKyAgICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor JGFzX2VjaG8gIm5vIiA+JjY7IH0KKyAgICBhc19mbl9lcnJvciAkPyAiJHB5dGhvbl92ZXJzaW9u IGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBpcyAyLjMiICIkTElORU5PIiA1 CitlbHNlCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1 bHQ6IHllcyIgPiY1CiskYXNfZWNobyAieWVzIiA+JjY7IH0KK2ZpCiAKK2FjX3ByZXZpb3VzX2Nw cGZsYWdzPSRDUFBGTEFHUworYWNfcHJldmlvdXNfbGRmbGFncz0kTERGTEFHUworYWNfcHl0aG9u X3ZlcnNpb249YCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAg cHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiVkVSU0lPTiIpJ2AKKyMg RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJFBZVEhPTi1jb25maWciLCBzbyBpdCBjYW4gYmUg YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRQWVRIT04tY29uZmlnOyBhY193 b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4g IiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9weWNvbmZpZytzZXR9IiA9IHNldDsgdGhl biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJHB5Y29uZmln IGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkcHljb25m aWciICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7Owor ICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg ICBhY19jdl9wYXRoX3B5Y29uZmlnPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAg ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor SUZTPSRhc19zYXZlX0lGUwogCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX3B5Y29uZmlnIiAmJiBh Y19jdl9wYXRoX3B5Y29uZmlnPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitweWNvbmZpZz0kYWNfY3Zf cGF0aF9weWNvbmZpZworaWYgdGVzdCAtbiAiJHB5Y29uZmlnIjsgdGhlbgorICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJHB5Y29uZmlnIiA+JjUKKyRh c19lY2hvICIkcHljb25maWciID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0K IGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGF4 X2N2X3B0aHJlYWRfZmxhZ3MiID4mNQotJGFzX2VjaG8gIiRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+ JjY7IH0KLSAgICBpZiB0ZXN0ICJ4JGF4X2N2X3B0aHJlYWRfZmxhZ3MiID0geGZhaWxlZDsgdGhl bgotICAgICAgICBhc19mbl9lcnJvciAkPyAiLXB0aHJlYWQgZG9lcyBub3Qgd29yayIgIiRMSU5F Tk8iIDUKLSAgICBmaQotCi0gICAgUFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdz IgotICAgIFBUSFJFQURfTERGTEFHUz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCi0gICAgUFRIUkVB RF9MSUJTPSIiCiAKIAoraWYgdGVzdCB4IiRweWNvbmZpZyIgPT0geCJubyI7IHRoZW4gOgogCi17 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBjbG9j a19nZXR0aW1lIGluIC1scnQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsb2NrX2dl dHRpbWUgaW4gLWxydC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfcnRfY2xvY2tf Z2V0dGltZStzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJQlM9Ii1scnQgICRMSUJT IgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLworICAgICAgICBDUFBGTEFHUz0iJENGTEFHUyBgJFBZVEhPTiAtYyAnaW1w b3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgIi1JIiArIGRpc3R1dGls cy5zeXNjb25maWcuZ2V0X2NvbmZpZ192YXIoIklOQ0xVREVQWSIpJ2AiCisgICAgQ1BQRkxBR1M9 IiRDUFBGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAg ICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiQ0ZMQUdTIikn YCIKKyAgICBMREZMQUdTPSIkTERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5z eXNjb25maWc7IFwKKyAgICAgICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmln X3ZhcigiTElCUyIpJ2AiCisgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9y dCBkaXN0dXRpbHMuc3lzY29uZmlnOyBcCisgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25m aWcuZ2V0X2NvbmZpZ192YXIoIlNZU0xJQlMiKSdgIgorICAgIExERkxBR1M9IiRMREZMQUdTIGAk UFlUSE9OIC1jICdpbXBvcnQgZGlzdHV0aWxzLnN5c2NvbmZpZzsgXAorICAgICAgICBwcmludCAi LUwiICsgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfcHl0aG9uX2xpYihwbGF0X3NwZWNpZmljPTEs XAorICAgICAgICBzdGFuZGFyZF9saWI9MSkgKyAiL2NvbmZpZyInYCIKKyAgICBMREZMQUdTPSIk TERGTEFHUyBgJFBZVEhPTiAtYyAnaW1wb3J0IGRpc3R1dGlscy5zeXNjb25maWc7IFwKKyAgICAg ICAgcHJpbnQgZGlzdHV0aWxzLnN5c2NvbmZpZy5nZXRfY29uZmlnX3ZhcigiTElOS0ZPUlNIQVJF RCIpJ2AiCisgICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04gLWMgJ2ltcG9ydCBkaXN0dXRp bHMuc3lzY29uZmlnOyBcCisgICAgICAgIHByaW50IGRpc3R1dGlscy5zeXNjb25maWcuZ2V0X2Nv bmZpZ192YXIoIkxERkxBR1MiKSdgIgogCi0vKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHBy b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KLSAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwotICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KLSNpZmRlZiBfX2NwbHVz cGx1cwotZXh0ZXJuICJDIgotI2VuZGlmCi1jaGFyIGNsb2NrX2dldHRpbWUgKCk7Ci1pbnQKLW1h aW4gKCkKLXsKLXJldHVybiBjbG9ja19nZXR0aW1lICgpOwotICA7Ci0gIHJldHVybiAwOwotfQot X0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2xp Yl9ydF9jbG9ja19nZXR0aW1lPXllcwogZWxzZQotICBhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGlt ZT1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAot ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0Ci1MSUJTPSRhY19jaGVja19s aWJfc2F2ZV9MSUJTCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIgPiY1Ci0kYXNfZWNobyAiJGFj X2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3J0 X2Nsb2NrX2dldHRpbWUiID0geCIieWVzOyB0aGVuIDoKLSAgY2F0ID4+Y29uZmRlZnMuaCA8PF9B Q0VPRgotI2RlZmluZSBIQVZFX0xJQlJUIDEKLV9BQ0VPRgogCi0gIExJQlM9Ii1scnQgJExJQlMi CisgICAgICAgIENQUEZMQUdTPSIkQ0ZMQUdTIGAkUFlUSE9OLWNvbmZpZyAtLWNmbGFnc2AiCisg ICAgTERGTEFHUz0iJExERkxBR1MgYCRQWVRIT04tY29uZmlnIC0tbGRmbGFnc2AiCiAKIGZpCiAK LXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHlh amxfYWxsb2MgaW4gLWx5YWpsIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB5YWpsX2Fs bG9jIGluIC1seWFqbC4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9saWJfeWFqbF95YWps X2FsbG9jK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUwotTElCUz0iLWx5YWpsICAkTElC UyIKLWNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBj b25mZGVmcy5oLiAgKi8KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJQ eXRob24uaCIgImFjX2N2X2hlYWRlcl9QeXRob25faCIgIiRhY19pbmNsdWRlc19kZWZhdWx0Igor aWYgdGVzdCAieCRhY19jdl9oZWFkZXJfUHl0aG9uX2giID0geCIieWVzOyB0aGVuIDoKIAotLyog T3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0g ICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBH Q0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGls bCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMKLWV4dGVybiAiQyIKLSNlbmRpZgotY2hh ciB5YWpsX2FsbG9jICgpOwotaW50Ci1tYWluICgpCi17Ci1yZXR1cm4geWFqbF9hbGxvYyAoKTsK LSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVO TyI7IHRoZW4gOgotICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19j dl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29u ZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19l eHQKLUxJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs ZSB0byBmaW5kIFB5dGhvbiBkZXZlbG9wbWVudCBoZWFkZXJzIiAiJExJTkVOTyIgNQogZmkKLXsg JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGli X3lhamxfeWFqbF9hbGxvYyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxs b2MiID4mNjsgfQotaWYgdGVzdCAieCRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHgiInll czsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFWRV9MSUJZ QUpMIDEKLV9BQ0VPRgotCi0gIExJQlM9Ii1seWFqbCAkTElCUyIKIAotZWxzZQotICBhc19mbl9l cnJvciAkPyAiQ291bGQgbm90IGZpbmQgeWFqbCIgIiRMSU5FTk8iIDUKLWZpCiAKLXsgJGFzX2Vj aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGRlZmxhdGVDb3B5 IGluIC1seiIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6 Li4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl96X2RlZmxhdGVDb3B5K3NldH0iID0g c2V0OyB0aGVuIDoKK2FzX2FjX0xpYj1gJGFzX2VjaG8gImFjX2N2X2xpYl9weXRob24kYWNfcHl0 aG9uX3ZlcnNpb24nJ19QeUFyZ19QYXJzZVR1cGxlIiB8ICRhc190cl9zaGAKK3sgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIFB5QXJnX1BhcnNlVHVw bGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp bmcgZm9yIFB5QXJnX1BhcnNlVHVwbGUgaW4gLWxweXRob24kYWNfcHl0aG9uX3ZlcnNpb24uLi4g IiA+JjY7IH0KK2lmIGV2YWwgInRlc3QgXCJcJHskYXNfYWNfTGliK3NldH1cIiIgPSBzZXQ7IHRo ZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQogICBhY19jaGVja19saWJf c2F2ZV9MSUJTPSRMSUJTCi1MSUJTPSItbHogICRMSUJTIgorTElCUz0iLWxweXRob24kYWNfcHl0 aG9uX3ZlcnNpb24gICRMSUJTIgogY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwogCkBAIC03NjMyLDE4OTMgKzUzNzcsMTE3 MyBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAjaWZkZWYg X19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBkZWZsYXRlQ29weSAoKTsKK2No YXIgUHlBcmdfUGFyc2VUdXBsZSAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIGRlZmxhdGVD b3B5ICgpOworcmV0dXJuIFB5QXJnX1BhcnNlVHVwbGUgKCk7CiAgIDsKICAgcmV0dXJuIDA7CiB9 CiBfQUNFT0YKIGlmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zf bGliX3pfZGVmbGF0ZUNvcHk9eWVzCisgIGV2YWwgIiRhc19hY19MaWI9eWVzIgogZWxzZQotICBh Y19jdl9saWJfel9kZWZsYXRlQ29weT1ubworICBldmFsICIkYXNfYWNfTGliPW5vIgogZmkKIHJt IC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAogICAgIGNvbmZ0ZXN0 JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CiBMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT CiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdl9saWJfel9kZWZsYXRlQ29weSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2xpYl96X2RlZmxh dGVDb3B5IiA+JjY7IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID0geCIi eWVzOyB0aGVuIDoKK2V2YWwgYWNfcmVzPVwkJGFzX2FjX0xpYgorCSAgICAgICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNf ZWNobyAiJGFjX3JlcyIgPiY2OyB9CitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0xpYiJcIiA9 IHgieWVzIjsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgSEFW RV9MSUJaIDEKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFX0xJQnB5dGhvbiRhY19weXRob25fdmVy c2lvbiIgfCAkYXNfdHJfY3BwYCAxCiBfQUNFT0YKIAotICBMSUJTPSItbHogJExJQlMiCi0KLWVs c2UKLSAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1Ci1m aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y IGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9s aWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6Ci0gICRhc19lY2hvX24g IihjYWNoZWQpICIgPiY2Ci1lbHNlCi0gIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKLUxJ QlM9Ii1saWNvbnYgICRMSUJTIgotY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLworICBMSUJTPSItbHB5dGhvbiRhY19weXRo b25fdmVyc2lvbiAkTElCUyIKIAotLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuCi0gICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKLSAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCi0jaWZkZWYgX19jcGx1c3BsdXMK LWV4dGVybiAiQyIKLSNlbmRpZgotY2hhciBsaWJpY29udl9vcGVuICgpOwotaW50Ci1tYWluICgp Ci17Ci1yZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VP RgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJfaWNv bnZfbGliaWNvbnZfb3Blbj15ZXMKLWVsc2UKLSAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29w ZW49bm8KLWZpCi1ybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwK LSAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAotTElCUz0kYWNfY2hlY2tf bGliX3NhdmVfTElCUwotZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P fTogcmVzdWx0OiAkYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW4iID4mNQotJGFzX2VjaG8g IiRhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY2OyB9Ci1pZiB0ZXN0ICJ4JGFjX2N2 X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA9IHgiInllczsgdGhlbiA6Ci0gIGxpYmljb252PSJ5 IgogZWxzZQotICBsaWJpY29udj0ibiIKKyAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5k IGEgc3VpdGFibGUgcHl0aG9uIGRldmVsb3BtZW50IGxpYnJhcnkiICIkTElORU5PIiA1CiBmaQog CitDUFBGTEFHUz0kYWNfcHJldmlvdXNfY3BwZmxhZ3MKK0xETEZBR1M9JGFjX3ByZXZpb3VzX2xk ZmxhZ3MKIAogCi0jIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgotIyBUaGUgVWx0cml4IDQuMiBt aXBzIGJ1aWx0aW4gYWxsb2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKLSMgZm9y IGNvbnN0YW50IGFyZ3VtZW50cy4gIFVzZWxlc3MhCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X3dvcmtpbmdfYWxsb2NhX2grc2V0fSIgPSBzZXQ7IHRoZW4gOgorZmkKKyMgRXh0 cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAieGdldHRleHQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHhnZXR0ZXh0OyBhY193b3JkPSQyCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRl c3QgIiR7YWNfY3ZfcGF0aF9YR0VUVEVYVCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpbmNsdWRlIDxhbGxvY2Eu aD4KLWludAotbWFpbiAoKQotewotY2hhciAqcCA9IChjaGFyICopIGFsbG9jYSAoMiAqIHNpemVv ZiAoaW50KSk7Ci0JCQkgIGlmIChwKSByZXR1cm4gMDsKLSAgOwotICByZXR1cm4gMDsKLX0KLV9B Q0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl93b3Jr aW5nX2FsbG9jYV9oPXllcwotZWxzZQotICBhY19jdl93b3JraW5nX2FsbG9jYV9oPW5vCisgIGNh c2UgJFhHRVRURVhUIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1hHRVRU RVhUPSIkWEdFVFRFWFQiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBw YXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9S Citmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXog IiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj dXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRh Y19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7 IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hHRVRURVhUPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4 ZWNfZXh0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1hH RVRURVhUIiAmJiBhY19jdl9wYXRoX1hHRVRURVhUPSJubyIKKyAgOzsKK2VzYWMKIGZpCi1ybSAt ZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKLSAgICBjb25mdGVzdCRh Y19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorWEdFVFRFWFQ9JGFjX2N2X3BhdGhfWEdFVFRFWFQK K2lmIHRlc3QgLW4gIiRYR0VUVEVYVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRYR0VUVEVYVCIgPiY1CiskYXNfZWNobyAiJFhHRVRU RVhUIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQoteyAkYXNfZWNo byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl93b3JraW5nX2Fs bG9jYV9oIiA+JjUKLSRhc19lY2hvICIkYWNfY3Zfd29ya2luZ19hbGxvY2FfaCIgPiY2OyB9Ci1p ZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9jYV9oID0geWVzOyB0aGVuCiAKLSRhc19lY2hvICIj ZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5jb25mZGVmcy5oCiAKK2lmIHRlc3QgeCIke1hHRVRU RVhUfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQg eGdldHRleHQsIHBsZWFzZSBpbnN0YWxsIHhnZXR0ZXh0IiAiJExJTkVOTyIgNQogZmkKLQoteyAk YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgYWxsb2Nh IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBhbGxvY2EuLi4gIiA+JjY7IH0KLWlmIHRl c3QgIiR7YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgorIyBFeHRy YWN0IHRoZSBmaXJzdCB3b3JkIG9mICJhczg2Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l IHdpdGggYXJncy4KK3NldCBkdW1teSBhczg2OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNf Y3ZfcGF0aF9BUzg2K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg IiA+JjYKIGVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4 dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmZGVmIF9fR05VQ19fCi0jIGRlZmluZSBhbGxv Y2EgX19idWlsdGluX2FsbG9jYQotI2Vsc2UKLSMgaWZkZWYgX01TQ19WRVIKLSMgIGluY2x1ZGUg PG1hbGxvYy5oPgotIyAgZGVmaW5lIGFsbG9jYSBfYWxsb2NhCi0jIGVsc2UKLSMgIGlmZGVmIEhB VkVfQUxMT0NBX0gKLSMgICBpbmNsdWRlIDxhbGxvY2EuaD4KLSMgIGVsc2UKLSMgICBpZmRlZiBf QUlYCi0gI3ByYWdtYSBhbGxvY2EKLSMgICBlbHNlCi0jICAgIGlmbmRlZiBhbGxvY2EgLyogcHJl ZGVmaW5lZCBieSBIUCBjYyArT2xpYmNhbGxzICovCi1jaGFyICphbGxvY2EgKCk7Ci0jICAgIGVu ZGlmCi0jICAgZW5kaWYKLSMgIGVuZGlmCi0jIGVuZGlmCi0jZW5kaWYKLQotaW50Ci1tYWluICgp Ci17Ci1jaGFyICpwID0gKGNoYXIgKikgYWxsb2NhICgxKTsKLQkJCQkgICAgaWYgKHApIHJldHVy biAwOwotICA7Ci0gIHJldHVybiAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPXllcwotZWxzZQotICBh Y19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubwotZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv bmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNf ZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxs b2NhX3dvcmtzIiA+JjY7IH0KLQotaWYgdGVzdCAkYWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5 ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5o CisgIGNhc2UgJEFTODYgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQVM4 Nj0iJEFTODYiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgor ICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3Ig YXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19k aXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxl X2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRo ZW4KKyAgICBhY19jdl9wYXRoX0FTODY9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisg ICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25l CitJRlM9JGFzX3NhdmVfSUZTCiAKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQVM4NiIgJiYgYWNf Y3ZfcGF0aF9BUzg2PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitBUzg2PSRhY19jdl9wYXRoX0FTODYK K2lmIHRlc3QgLW4gIiRBUzg2IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IHJlc3VsdDogJEFTODYiID4mNQorJGFzX2VjaG8gIiRBUzg2IiA+JjY7IH0K IGVsc2UKLSAgIyBUaGUgU1ZSMyBsaWJQVyBhbmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGlu Y29tcGF0aWJsZSBmdW5jdGlvbnMKLSMgdGhhdCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9u cyBkbyBub3QgZXZlbiBjb250YWluIGFsbG9jYSBvcgotIyBjb250YWluIGEgYnVnZ3kgdmVyc2lv bi4gIElmIHlvdSBzdGlsbCB3YW50IHRvIHVzZSB0aGVpciBhbGxvY2EsCi0jIHVzZSBhciB0byBl eHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBpbnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4K LQotQUxMT0NBPVwke0xJQk9CSkRJUn1hbGxvY2EuJGFjX29iamV4dAotCi0kYXNfZWNobyAiI2Rl ZmluZSBDX0FMTE9DQSAxIiA+PmNvbmZkZWZzLmgKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9Citm aQogCiAKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg d2hldGhlciBcYGFsbG9jYS5jJyBuZWVkcyBDcmF5IGhvb2tzIiA+JjUKLSRhc19lY2hvX24gImNo ZWNraW5nIHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcy4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9vc19jcmF5K3NldH0iID0gc2V0OyB0aGVuIDoKK2lmIHRlc3QgeCIk e0FTODZ9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu ZCBhczg2LCBwbGVhc2UgaW5zdGFsbCBhczg2IiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0 aGUgZmlyc3Qgd29yZCBvZiAibGQ4NiIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo IGFyZ3MuCitzZXQgZHVtbXkgbGQ4NjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9f biAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3Bh dGhfTEQ4NitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2 CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8q IGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZiBkZWZpbmVkIENSQVkgJiYgISBkZWZpbmVkIENSQVky Ci13ZWJlY3JheQotI2Vsc2UKLXdlbm90YmVjcmF5Ci0jZW5kaWYKKyAgY2FzZSAkTEQ4NiBpbgor ICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9MRDg2PSIkTEQ4NiIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3Nh dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94 ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf TEQ4Nj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21l OiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0 IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMK IAotX0FDRU9GCi1pZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8Ci0g ICRFR1JFUCAid2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6Ci0gIGFjX2N2X29zX2Ny YXk9eWVzCi1lbHNlCi0gIGFjX2N2X29zX2NyYXk9bm8KKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhf TEQ4NiIgJiYgYWNfY3ZfcGF0aF9MRDg2PSJubyIKKyAgOzsKK2VzYWMKIGZpCi1ybSAtZiBjb25m dGVzdCoKLQorTEQ4Nj0kYWNfY3ZfcGF0aF9MRDg2CitpZiB0ZXN0IC1uICIkTEQ4NiI7IHRoZW4K KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRMRDg2 IiA+JjUKKyRhc19lY2hvICIkTEQ4NiIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4m NjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiAkYWNfY3Zfb3NfY3JheSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQot aWYgdGVzdCAkYWNfY3Zfb3NfY3JheSA9IHllczsgdGhlbgotICBmb3IgYWNfZnVuYyBpbiBfZ2V0 YjY3IEdFVEI2NyBnZXRiNjc7IGRvCi0gICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVu Y18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIk YWNfZnVuYyIgIiRhc19hY192YXIiCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9 IHgieWVzIjsgdGhlbiA6Ci0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgQ1JB WV9TVEFDS1NFR19FTkQgJGFjX2Z1bmMKLV9BQ0VPRgogCi0gICAgYnJlYWsKLWZpCiAKLSAgZG9u ZQoraWYgdGVzdCB4IiR7TEQ4Nn0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8g IlVuYWJsZSB0byBmaW5kIGxkODYsIHBsZWFzZSBpbnN0YWxsIGxkODYiICIkTElORU5PIiA1CiBm aQotCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHN0 YWNrIGRpcmVjdGlvbiBmb3IgQyBhbGxvY2EiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgc3Rh Y2sgZGlyZWN0aW9uIGZvciBDIGFsbG9jYS4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9j X3N0YWNrX2RpcmVjdGlvbitzZXR9IiA9IHNldDsgdGhlbiA6CisjIEV4dHJhY3QgdGhlIGZpcnN0 IHdvcmQgb2YgImJjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz ZXQgZHVtbXkgYmNjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9CQ0Mrc2V0 fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBp ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Nfc3RhY2tf ZGlyZWN0aW9uPTAKLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu JGFjX2V4dAotLyogZW5kIGNvbmZkZWZzLmguICAqLwotJGFjX2luY2x1ZGVzX2RlZmF1bHQKLWlu dAotZmluZF9zdGFja19kaXJlY3Rpb24gKCkKLXsKLSAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOwot ICBhdXRvIGNoYXIgZHVtbXk7Ci0gIGlmIChhZGRyID09IDApCi0gICAgewotICAgICAgYWRkciA9 ICZkdW1teTsKLSAgICAgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKTsKLSAgICB9Ci0g IGVsc2UKLSAgICByZXR1cm4gKCZkdW1teSA+IGFkZHIpID8gMSA6IC0xOwotfQorICBjYXNlICRC Q0MgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkNDPSIkQkNDIiAjIExl dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAg YXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFU SAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9 LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBk bworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190 ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3Zf cGF0aF9CQ0M9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRh c19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVj X2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVf SUZTCiAKLWludAotbWFpbiAoKQotewotICByZXR1cm4gZmluZF9zdGFja19kaXJlY3Rpb24gKCkg PCAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAg YWNfY3ZfY19zdGFja19kaXJlY3Rpb249MQotZWxzZQotICBhY19jdl9jX3N0YWNrX2RpcmVjdGlv bj0tMQotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i ZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkNDIiAmJiBhY19j dl9wYXRoX0JDQz0ibm8iCisgIDs7Citlc2FjCiBmaQotCitCQ0M9JGFjX2N2X3BhdGhfQkNDCitp ZiB0ZXN0IC1uICIkQkNDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t JExJTkVOT306IHJlc3VsdDogJEJDQyIgPiY1CiskYXNfZWNobyAiJEJDQyIgPiY2OyB9CitlbHNl CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19zdGFja19kaXJlY3Rpb24iID4mNQotJGFz X2VjaG8gIiRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY2OyB9Ci1jYXQgPj5jb25mZGVmcy5o IDw8X0FDRU9GCi0jZGVmaW5lIFNUQUNLX0RJUkVDVElPTiAkYWNfY3ZfY19zdGFja19kaXJlY3Rp b24KLV9BQ0VPRgogCiAKK2lmIHRlc3QgeCIke0JDQ30iID09IHgibm8iCit0aGVuCisgICAgYXNf Zm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGJjYywgcGxlYXNlIGluc3RhbGwgYmNjIiAiJExJ TkVOTyIgNQogZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiaWFzbCIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgaWFzbDsgYWNfd29yZD0k MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2 OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhfSUFTTCtzZXR9IiA9IHNldDsgdGhlbiA6CisgICRh c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJElBU0wgaW4KKyAgW1xcL10q IHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSUFTTD0iJElBU0wiICMgTGV0IHRoZSB1c2VyIG92 ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0k SUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9 JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFj X2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVz dCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rp ci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0lBU0w9IiRh c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLWZvciBh Y19oZWFkZXIgaW4gIFwKLSAgICAgICAgICAgICAgICBhcnBhL2luZXQuaCBmY250bC5oIGludHR5 cGVzLmggbGliaW50bC5oIGxpbWl0cy5oIG1hbGxvYy5oIFwKLSAgICAgICAgICAgICAgICBuZXRk Yi5oIG5ldGluZXQvaW4uaCBzdGRkZWYuaCBzdGRpbnQuaCBzdGRsaWIuaCBzdHJpbmcuaCBcCi0g ICAgICAgICAgICAgICAgc3RyaW5ncy5oIHN5cy9maWxlLmggc3lzL2lvY3RsLmggc3lzL21vdW50 Lmggc3lzL3BhcmFtLmggXAotICAgICAgICAgICAgICAgIHN5cy9zb2NrZXQuaCBzeXMvc3RhdHZm cy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKLSAgICAgICAgICAgICAgICB1bmlz dGQuaCB5YWpsL3lhamxfdmVyc2lvbi5oIFwKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfSUFTTCIg JiYgYWNfY3ZfcGF0aF9JQVNMPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitJQVNMPSRhY19jdl9wYXRo X0lBU0wKK2lmIHRlc3QgLW4gIiRJQVNMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJElBU0wiID4mNQorJGFzX2VjaG8gIiRJQVNMIiA+ JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQogCi1kbyA6Ci0gIGFzX2Fj X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK LWFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgZXZhbCB0ZXN0IFwieFwkIiRh c19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD RU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEK LV9BQ0VPRgogCitpZiB0ZXN0IHgiJHtJQVNMfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9l cnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgaWFzbCwgcGxlYXNlIGluc3RhbGwgaWFzbCIgIiRMSU5F Tk8iIDUKIGZpCiAKLWRvbmUKLQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVO TyIgInV1aWQvdXVpZC5oIiAiYWNfY3ZfaGVhZGVyX3V1aWRfdXVpZF9oIiAiJGFjX2luY2x1ZGVz X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl91dWlkX3V1aWRfaCIgPSB4IiJ5ZXM7 IHRoZW4gOgogCi0jIENoZWNrcyBmb3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxl ciBjaGFyYWN0ZXJpc3RpY3MuCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25mb3JtcyB0byBDOTkiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIHN0ZGJvb2wuaCB0aGF0IGNvbmZvcm1zIHRvIEM5OS4uLiAi ID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9oZWFkZXJfc3RkYm9vbF9oK3NldH0iID0gc2V0OyB0 aGVuIDoKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciB1dWlkX2NsZWFyIGluIC1sdXVpZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBm b3IgdXVpZF9jbGVhciBpbiAtbHV1aWQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGli X3V1aWRfdXVpZF9jbGVhcitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNo ZWQpICIgPiY2CiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh Y19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx1dWlkICAkTElC UyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBj b25mZGVmcy5oLiAgKi8KIAotI2luY2x1ZGUgPHN0ZGJvb2wuaD4KLSNpZm5kZWYgYm9vbAotICJl cnJvcjogYm9vbCBpcyBub3QgZGVmaW5lZCIKLSNlbmRpZgotI2lmbmRlZiBmYWxzZQotICJlcnJv cjogZmFsc2UgaXMgbm90IGRlZmluZWQiCi0jZW5kaWYKLSNpZiBmYWxzZQotICJlcnJvcjogZmFs c2UgaXMgbm90IDAiCi0jZW5kaWYKLSNpZm5kZWYgdHJ1ZQotICJlcnJvcjogdHJ1ZSBpcyBub3Qg ZGVmaW5lZCIKLSNlbmRpZgotI2lmIHRydWUgIT0gMQotICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIK LSNlbmRpZgotI2lmbmRlZiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZAotICJlcnJvcjog X19ib29sX3RydWVfZmFsc2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCisvKiBPdmVycmlk ZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBj aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAg YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgogI2VuZGlmCi0KLQlzdHJ1Y3Qg cyB7IF9Cb29sIHM6IDE7IF9Cb29sIHQ7IH0gczsKLQotCWNoYXIgYVt0cnVlID09IDEgPyAxIDog LTFdOwotCWNoYXIgYltmYWxzZSA9PSAwID8gMSA6IC0xXTsKLQljaGFyIGNbX19ib29sX3RydWVf ZmFsc2VfYXJlX2RlZmluZWQgPT0gMSA/IDEgOiAtMV07Ci0JY2hhciBkWyhib29sKSAwLjUgPT0g dHJ1ZSA/IDEgOiAtMV07Ci0JYm9vbCBlID0gJnM7Ci0JY2hhciBmWyhfQm9vbCkgMC4wID09IGZh bHNlID8gMSA6IC0xXTsKLQljaGFyIGdbdHJ1ZV07Ci0JY2hhciBoW3NpemVvZiAoX0Jvb2wpXTsK LQljaGFyIGlbc2l6ZW9mIHMudF07Ci0JZW51bSB7IGogPSBmYWxzZSwgayA9IHRydWUsIGwgPSBm YWxzZSAqIHRydWUsIG0gPSB0cnVlICogMjU2IH07Ci0JLyogVGhlIGZvbGxvd2luZyBmYWlscyBm b3IKLQkgICBIUCBhQysrL0FOU0kgQyBCMzkxMEIgQS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLwot CV9Cb29sIG5bbV07Ci0JY2hhciBvW3NpemVvZiBuID09IG0gKiBzaXplb2YgblswXSA/IDEgOiAt MV07Ci0JY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwgMCAmJiAtMSAtIChib29sKSAwIDwgMCA/IDEg OiAtMV07Ci0jCWlmIGRlZmluZWQgX194bGNfXyB8fCBkZWZpbmVkIF9fR05VQ19fCi0JIC8qIENh dGNoIGEgYnVnIGluIElCTSBBSVggeGxjIGNvbXBpbGVyIHZlcnNpb24gNi4wLjAuMAotCSAgICBy ZXBvcnRlZCBieSBKYW1lcyBMZW1sZXkgb24gMjAwNS0xMC0wNTsgc2VlCi0JICAgIGh0dHA6Ly9s aXN0cy5nbnUub3JnL2FyY2hpdmUvaHRtbC9idWctY29yZXV0aWxzLzIwMDUtMTAvbXNnMDAwODYu aHRtbAotCSAgICBUaGlzIHRlc3QgaXMgbm90IHF1aXRlIHJpZ2h0LCBzaW5jZSB4bGMgaXMgYWxs b3dlZCB0bwotCSAgICByZWplY3QgdGhpcyBwcm9ncmFtLCBhcyB0aGUgaW5pdGlhbGl6ZXIgZm9y IHhsY2J1ZyBpcwotCSAgICBub3Qgb25lIG9mIHRoZSBmb3JtcyB0aGF0IEMgcmVxdWlyZXMgc3Vw cG9ydCBmb3IuCi0JICAgIEhvd2V2ZXIsIGRvaW5nIHRoZSB0ZXN0IHJpZ2h0IHdvdWxkIHJlcXVp cmUgYSBydW50aW1lCi0JICAgIHRlc3QsIGFuZCB0aGF0IHdvdWxkIG1ha2UgY3Jvc3MtY29tcGls YXRpb24gaGFyZGVyLgotCSAgICBMZXQgdXMgaG9wZSB0aGF0IElCTSBmaXhlcyB0aGUgeGxjIGJ1 ZywgYW5kIGFsc28gYWRkcwotCSAgICBzdXBwb3J0IGZvciB0aGlzIGtpbmQgb2YgY29uc3RhbnQg ZXhwcmVzc2lvbi4gIEluIHRoZQotCSAgICBtZWFudGltZSwgdGhpcyB0ZXN0IHdpbGwgcmVqZWN0 IHhsYywgd2hpY2ggaXMgT0ssIHNpbmNlCi0JICAgIG91ciBzdGRib29sLmggc3Vic3RpdHV0ZSBz aG91bGQgc3VmZmljZS4gIFdlIGFsc28gdGVzdAotCSAgICB0aGlzIHdpdGggR0NDLCB3aGVyZSBp dCBzaG91bGQgd29yaywgdG8gZGV0ZWN0IG1vcmUKLQkgICAgcXVpY2tseSB3aGV0aGVyIHNvbWVv bmUgbWVzc2VzIHVwIHRoZSB0ZXN0IGluIHRoZQotCSAgICBmdXR1cmUuICAqLwotCSBjaGFyIGRp Z3NbXSA9ICIwMTIzNDU2Nzg5IjsKLQkgaW50IHhsY2J1ZyA9IDEgLyAoJihkaWdzICsgNSlbLTIg KyAoYm9vbCkgMV0gPT0gJmRpZ3NbNF0gPyAxIDogLTEpOwotIwllbmRpZgotCS8qIENhdGNoIGEg YnVnIGluIGFuIEhQLVVYIEMgY29tcGlsZXIuICBTZWUKLQkgICBodHRwOi8vZ2NjLmdudS5vcmcv bWwvZ2NjLXBhdGNoZXMvMjAwMy0xMi9tc2cwMjMwMy5odG1sCi0JICAgaHR0cDovL2xpc3RzLmdu dS5vcmcvYXJjaGl2ZS9odG1sL2J1Zy1jb3JldXRpbHMvMjAwNS0xMS9tc2cwMDE2MS5odG1sCi0J ICovCi0JX0Jvb2wgcSA9IHRydWU7Ci0JX0Jvb2wgKnBxID0gJnE7Ci0KK2NoYXIgdXVpZF9jbGVh ciAoKTsKIGludAogbWFpbiAoKQogewotCi0JKnBxIHw9IHE7Ci0JKnBxIHw9ICEgcTsKLQkvKiBS ZWZlciB0byBldmVyeSBkZWNsYXJlZCB2YWx1ZSwgdG8gYXZvaWQgY29tcGlsZXIgb3B0aW1pemF0 aW9ucy4gICovCi0JcmV0dXJuICghYSArICFiICsgIWMgKyAhZCArICFlICsgIWYgKyAhZyArICFo ICsgIWkgKyAhIWogKyAhayArICEhbAotCQkrICFtICsgIW4gKyAhbyArICFwICsgIXEgKyAhcHEp OwotCityZXR1cm4gdXVpZF9jbGVhciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgot aWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJf c3RkYm9vbF9oPXllcwotZWxzZQotICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPW5vCi1maQotcm0g LWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0 Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh Y19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N0ZGJv b2xfaCIgPiY2OyB9Ci1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJfQm9vbCIgImFjX2N2 X3R5cGVfX0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfdHlw ZV9fQm9vbCIgPSB4IiJ5ZXM7IHRoZW4gOgotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0j ZGVmaW5lIEhBVkVfX0JPT0wgMQotX0FDRU9GCi0KLQotZmkKLQotaWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGJvb2xfaCA9IHllczsgdGhlbgotCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUREJP T0xfSCAxIiA+PmNvbmZkZWZzLmgKLQotZmkKLQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgiID4mNQotJGFz X2VjaG9fbiAiY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X3R5cGVfdWlkX3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNo b19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j b25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29uZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5 cGVzLmg+Ci0KLV9BQ0VPRgotaWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+ JjUgfAotICAkRUdSRVAgInVpZF90IiA+L2Rldi9udWxsIDI+JjE7IHRoZW4gOgotICBhY19jdl90 eXBlX3VpZF90PXllcwotZWxzZQotICBhY19jdl90eXBlX3VpZF90PW5vCi1maQotcm0gLWYgY29u ZnRlc3QqCi0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogJGFjX2N2X3R5cGVfdWlkX3QiID4mNQotJGFzX2VjaG8gIiRhY19jdl90eXBlX3VpZF90 IiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X3R5cGVfdWlkX3QgPSBubzsgdGhlbgotCi0kYXNfZWNo byAiI2RlZmluZSB1aWRfdCBpbnQiID4+Y29uZmRlZnMuaAotCi0KLSRhc19lY2hvICIjZGVmaW5l IGdpZF90IGludCIgPj5jb25mZGVmcy5oCi0KLWZpCi0KLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlubGluZSIgPiY1Ci0kYXNfZWNob19uICJj aGVja2luZyBmb3IgaW5saW5lLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2NfaW5saW5l K3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UK LSAgYWNfY3ZfY19pbmxpbmU9bm8KLWZvciBhY19rdyBpbiBpbmxpbmUgX19pbmxpbmVfXyBfX2lu bGluZTsgZG8KLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAot LyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmbmRlZiBfX2NwbHVzcGx1cwotdHlwZWRlZiBpbnQg Zm9vX3Q7Ci1zdGF0aWMgJGFjX2t3IGZvb190IHN0YXRpY19mb28gKCkge3JldHVybiAwOyB9Ci0k YWNfa3cgZm9vX3QgZm9vICgpIHtyZXR1cm4gMDsgfQotI2VuZGlmCi0KLV9BQ0VPRgotaWYgYWNf Zm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9jX2lubGluZT0kYWNf a3cKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3V1 aWRfdXVpZF9jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhcj1ubwog ZmkKLXJtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3Qu JGFjX2V4dAotICB0ZXN0ICIkYWNfY3ZfY19pbmxpbmUiICE9IG5vICYmIGJyZWFrCi1kb25lCi0K K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0 ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9M SUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6 ICRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3V1 aWRfdXVpZF9jbGVhciIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl91dWlkX3V1aWRfY2xl YXIiID0geCIieWVzOyB0aGVuIDoKKyAgbGlidXVpZD0ieSIKIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2NfaW5saW5lIiA+JjUKLSRh c19lY2hvICIkYWNfY3ZfY19pbmxpbmUiID4mNjsgfQogCi1jYXNlICRhY19jdl9jX2lubGluZSBp bgotICBpbmxpbmUgfCB5ZXMpIDs7Ci0gICopCi0gICAgY2FzZSAkYWNfY3ZfY19pbmxpbmUgaW4K LSAgICAgIG5vKSBhY192YWw9OzsKLSAgICAgICopIGFjX3ZhbD0kYWNfY3ZfY19pbmxpbmU7Owot ICAgIGVzYWMKLSAgICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jaWZuZGVmIF9fY3BsdXNw bHVzCi0jZGVmaW5lIGlubGluZSAkYWNfdmFsCi0jZW5kaWYKLV9BQ0VPRgotICAgIDs7Ci1lc2Fj CiAKLWFjX2ZuX2NfZmluZF9pbnRYX3QgIiRMSU5FTk8iICIxNiIgImFjX2N2X2NfaW50MTZfdCIK LWNhc2UgJGFjX2N2X2NfaW50MTZfdCBpbiAjKAotICBub3x5ZXMpIDs7ICMoCi0gICopCitmaQog Ci1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGludDE2X3QgJGFjX2N2X2NfaW50 MTZfdAotX0FDRU9GCi07OwotZXNhYwogCi1hY19mbl9jX2ZpbmRfaW50WF90ICIkTElORU5PIiAi MzIiICJhY19jdl9jX2ludDMyX3QiCi1jYXNlICRhY19jdl9jX2ludDMyX3QgaW4gIygKLSAgbm98 eWVzKSA7OyAjKAotICAqKQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg InV1aWQuaCIgImFjX2N2X2hlYWRlcl91dWlkX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm IHRlc3QgIngkYWNfY3ZfaGVhZGVyX3V1aWRfaCIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJ1dWlk PSJ5IgorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBpbnQzMl90ICRh Y19jdl9jX2ludDMyX3QKLV9BQ0VPRgotOzsKLWVzYWMKIAotYWNfZm5fY19maW5kX2ludFhfdCAi JExJTkVOTyIgIjY0IiAiYWNfY3ZfY19pbnQ2NF90IgotY2FzZSAkYWNfY3ZfY19pbnQ2NF90IGlu ICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKK2lmIHRlc3QgIiRsaWJ1dWlkIiAhPSAieSI7IHRo ZW4gOgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGludDY0X3QgJGFjX2N2 X2NfaW50NjRfdAotX0FDRU9GCi07OwotZXNhYworICAgIGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3Qg ZmluZCBhIHZhbGlkIHV1aWQgbGlicmFyeSIgIiRMSU5FTk8iIDUKIAotYWNfZm5fY19maW5kX2lu dFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX2ludDhfdCIKLWNhc2UgJGFjX2N2X2NfaW50OF90 IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf QUNFT0YKLSNkZWZpbmUgaW50OF90ICRhY19jdl9jX2ludDhfdAotX0FDRU9GCi07OwotZXNhYwog Ci1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJtb2RlX3QiICJhY19jdl90eXBlX21vZGVf dCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX21vZGVfdCIg PSB4IiJ5ZXM7IHRoZW4gOgorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIg ImN1cnNlcy5oIiAiYWNfY3ZfaGVhZGVyX2N1cnNlc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQi CitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9jdXJzZXNfaCIgPSB4IiJ5ZXM7IHRoZW4gOgogCisg ICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig Y2xlYXIgaW4gLWxjdXJzZXMiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGNsZWFyIGlu IC1sY3Vyc2VzLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9jdXJzZXNfY2xlYXIr c2V0fSIgPSBzZXQ7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQor ICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGN1cnNlcyAgJExJQlMiCitj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl ZnMuaC4gICovCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgbW9kZV90IGlu dAorLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJy b3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg b2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs ZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRp ZgorY2hhciBjbGVhciAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJuIGNsZWFyICgpOworICA7 CisgIHJldHVybiAwOworfQogX0FDRU9GCi0KK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8i OyB0aGVuIDoKKyAgYWNfY3ZfbGliX2N1cnNlc19jbGVhcj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGli X2N1cnNlc19jbGVhcj1ubwogZmkKLQotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAib2Zm X3QiICJhY19jdl90eXBlX29mZl90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4 JGFjX2N2X3R5cGVfb2ZmX3QiID0geCIieWVzOyB0aGVuIDoKLQorcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0 ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jdXJzZXNf Y2xlYXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfY3Vyc2VzX2NsZWFyIiA+JjY7IH0KK2lm IHRlc3QgIngkYWNfY3ZfbGliX2N1cnNlc19jbGVhciIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjdXJz ZXM9InkiCiBlbHNlCi0KLWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgb2ZmX3Qg bG9uZyBpbnQKLV9BQ0VPRgotCisgIGN1cnNlcz0ibiIKIGZpCiAKLWFjX2ZuX2NfY2hlY2tfdHlw ZSAiJExJTkVOTyIgInBpZF90IiAiYWNfY3ZfdHlwZV9waWRfdCIgIiRhY19pbmNsdWRlc19kZWZh dWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3BpZF90IiA9IHgiInllczsgdGhlbiA6CiAKIGVs c2UKKyAgY3Vyc2VzPSJuIgorZmkKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmlu ZSBwaWRfdCBpbnQKLV9BQ0VPRgogCi1maQorYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAi JExJTkVOTyIgIm5jdXJzZXMuaCIgImFjX2N2X2hlYWRlcl9uY3Vyc2VzX2giICIkYWNfaW5jbHVk ZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX25jdXJzZXNfaCIgPSB4IiJ5ZXM7 IHRoZW4gOgogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5n IGZvciBDL0MrKyByZXN0cmljdCBrZXl3b3JkLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2 X2NfcmVzdHJpY3Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgorICAgIHsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNsZWFyIGluIC1sbmN1cnNlcyIgPiY1 CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xlYXIgaW4gLWxuY3Vyc2VzLi4uICIgPiY2OyB9 CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyK3NldH0iID0gc2V0OyB0aGVuIDoK ICAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgYWNfY3ZfY19yZXN0cmljdD1u bwotICAgIyBUaGUgb3JkZXIgaGVyZSBjYXRlcnMgdG8gdGhlIGZhY3QgdGhhdCBDKysgZG9lcyBu b3QgcmVxdWlyZSByZXN0cmljdC4KLSAgIGZvciBhY19rdyBpbiBfX3Jlc3RyaWN0IF9fcmVzdHJp Y3RfXyBfUmVzdHJpY3QgcmVzdHJpY3Q7IGRvCi0gICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElC Uz0iLWxuY3Vyc2VzICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0 LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLXR5cGVkZWYgaW50ICogaW50X3B0cjsK LQlpbnQgZm9vIChpbnRfcHRyICRhY19rdyBpcCkgewotCXJldHVybiBpcFswXTsKLSAgICAgICB9 CisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy cm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl IG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291 bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5k aWYKK2NoYXIgY2xlYXIgKCk7CiBpbnQKIG1haW4gKCkKIHsKLWludCBzWzFdOwotCWludCAqICRh Y19rdyB0ID0gczsKLQl0WzBdID0gMDsKLQlyZXR1cm4gZm9vKHQpCityZXR1cm4gY2xlYXIgKCk7 CiAgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRM SU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfY19yZXN0cmljdD0kYWNfa3cKK2lmIGFjX2ZuX2NfdHJ5 X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX25jdXJzZXNfY2xlYXI9eWVzCitl bHNlCisgIGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyPW5vCiBmaQotcm0gLWYgY29yZSBjb25mdGVz dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0Ci0gICAgIHRlc3QgIiRh Y19jdl9jX3Jlc3RyaWN0IiAhPSBubyAmJiBicmVhawotICAgZG9uZQotCitybSAtZiBjb3JlIGNv bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfY19yZXN0 cmljdCIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2X2NfcmVzdHJpY3QiID4mNjsgfQotCi0gY2FzZSAk YWNfY3ZfY19yZXN0cmljdCBpbgotICAgcmVzdHJpY3QpIDs7Ci0gICBubykgJGFzX2VjaG8gIiNk ZWZpbmUgcmVzdHJpY3QgLyoqLyIgPj5jb25mZGVmcy5oCi0gOzsKLSAgICopICBjYXQgPj5jb25m ZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHJlc3RyaWN0ICRhY19jdl9jX3Jlc3RyaWN0Ci1fQUNF T0YKLSA7OwotIGVzYWMKLQotYWNfZm5fY19jaGVja190eXBlICIkTElORU5PIiAic2l6ZV90IiAi YWNfY3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNf Y3ZfdHlwZV9zaXplX3QiID0geCIieWVzOyB0aGVuIDoKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfbmN1cnNlc19jbGVhciIgPiY1 CiskYXNfZWNobyAiJGFjX2N2X2xpYl9uY3Vyc2VzX2NsZWFyIiA+JjY7IH0KK2lmIHRlc3QgIngk YWNfY3ZfbGliX25jdXJzZXNfY2xlYXIiID0geCIieWVzOyB0aGVuIDoKKyAgbmN1cnNlcz0ieSIK IGVsc2UKLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBzaXplX3QgdW5zaWdu ZWQgaW50Ci1fQUNFT0YKLQorICBuY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19jaGVja190eXBl ICIkTElORU5PIiAic3NpemVfdCIgImFjX2N2X3R5cGVfc3NpemVfdCIgIiRhY19pbmNsdWRlc19k ZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3NzaXplX3QiID0geCIieWVzOyB0aGVuIDoK IAogZWxzZQotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIHNzaXplX3QgaW50 Ci1fQUNFT0YKLQorICBuY3Vyc2VzPSJuIgogZmkKIAotYWNfZm5fY19jaGVja19tZW1iZXIgIiRM SU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19jdl9tZW1iZXJfc3RydWN0X3N0 YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9t ZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4IiJ5ZXM7IHRoZW4gOgogCi1jYXQgPj5j b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxLU0laRSAx Ci1fQUNFT0YKK2lmIHRlc3QgIiRjdXJzZXMiID0gIm4iICYmIHRlc3QgIiRuY3Vyc2VzIiA9ICJu IjsgdGhlbiA6CiAKKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgYSBzdWl0YWJs ZSBjdXJzZXMgbGlicmFyeSIgIiRMSU5FTk8iIDUKIAogZmkKKyMgUHJlZmVyIG5jdXJzZXMgb3Zl ciBjdXJzZXMgaWYgYm90aCBhcmUgcHJlc2VudAoraWYgdGVzdCAiJG5jdXJzZXMiID0gInkiOyB0 aGVuIDoKIAotYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0 X2Jsb2NrcyIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibG9ja3MiICIkYWNfaW5jbHVk ZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsb2Nr cyIgPSB4IiJ5ZXM7IHRoZW4gOgotCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5l IEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTIDEKLV9BQ0VPRgorICAgIENVUlNFU19MSUJTPSIt bG5jdXJzZXMiCiAKKyRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VSU0VTX0ggPG5jdXJzZXMu aD4iID4+Y29uZmRlZnMuaAogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1NUX0JMT0NLUyAxIiA+ PmNvbmZkZWZzLmgKIAogZWxzZQotICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiBmaWxlYmxv Y2tzLiRhY19vYmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBmaWxlYmxvY2tz LiRhY19vYmpleHQiCi0gOzsKLWVzYWMKLQotZmkKLQogCi1hY19mbl9jX2NoZWNrX21lbWJlciAi JExJTkVOTyIgInN0cnVjdCBzdGF0IiAic3RfcmRldiIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3Rh dF9zdF9yZGV2IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X21lbWJl cl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiA9IHgiInllczsgdGhlbiA6CisgICAgQ1VSU0VTX0xJQlM9 Ii1sY3Vyc2VzIgogCi1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RS VUNUX1NUQVRfU1RfUkRFViAxCi1fQUNFT0YKKyRhc19lY2hvICIjZGVmaW5lIElOQ0xVREVfQ1VS U0VTX0ggPGN1cnNlcy5oPiIgPj5jb25mZGVmcy5oCiAKIAogZmkKIAotYWNfZm5fY19maW5kX3Vp bnRYX3QgIiRMSU5FTk8iICIxNiIgImFjX2N2X2NfdWludDE2X3QiCi1jYXNlICRhY19jdl9jX3Vp bnQxNl90IGluICMoCi0gIG5vfHllcykgOzsgIygKLSAgKikKIAogCi1jYXQgPj5jb25mZGVmcy5o IDw8X0FDRU9GCi0jZGVmaW5lIHVpbnQxNl90ICRhY19jdl9jX3VpbnQxNl90Ci1fQUNFT0YKLTs7 Ci0gIGVzYWMKIAotYWNfZm5fY19maW5kX3VpbnRYX3QgIiRMSU5FTk8iICIzMiIgImFjX2N2X2Nf dWludDMyX3QiCi1jYXNlICRhY19jdl9jX3VpbnQzMl90IGluICMoCi0gIG5vfHllcykgOzsgIygK LSAgKikKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQzMl9UIDEiID4+Y29uZmRlZnMuaAogCiAK LWNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgdWludDMyX3QgJGFjX2N2X2NfdWlu dDMyX3QKLV9BQ0VPRgotOzsKLSAgZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVO TyIgIjY0IiAiYWNfY3ZfY191aW50NjRfdCIKLWNhc2UgJGFjX2N2X2NfdWludDY0X3QgaW4gIygK LSAgbm98eWVzKSA7OyAjKAoraWYgdGVzdCAieCRhY19jdl9lbnZfUEtHX0NPTkZJR19zZXQiICE9 ICJ4c2V0IjsgdGhlbgorCWlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBF eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fXBrZy1jb25maWciLCBz byBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9v bF9wcmVmaXh9cGtnLWNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X3BhdGhf UEtHX0NPTkZJRytzZXR9IiA9IHNldDsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg PiY2CitlbHNlCisgIGNhc2UgJFBLR19DT05GSUcgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisg IGFjX2N2X3BhdGhfUEtHX0NPTkZJRz0iJFBLR19DT05GSUciICMgTGV0IHRoZSB1c2VyIG92ZXJy aWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OwogICAqKQorICBhc19zYXZlX0lGUz0kSUZT OyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFz X3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4 ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAt ZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8k YWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1BLR19DT05GSUc9 IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1 CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCiAKLSRh c19lY2hvICIjZGVmaW5lIF9VSU5UNjRfVCAxIiA+PmNvbmZkZWZzLmgKLQorICA7OworZXNhYwor ZmkKK1BLR19DT05GSUc9JGFjX2N2X3BhdGhfUEtHX0NPTkZJRworaWYgdGVzdCAtbiAiJFBLR19D T05GSUciOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog cmVzdWx0OiAkUEtHX0NPTkZJRyIgPiY1CiskYXNfZWNobyAiJFBLR19DT05GSUciID4mNjsgfQor ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCiAKLWNhdCA+PmNvbmZkZWZzLmggPDxf QUNFT0YKLSNkZWZpbmUgdWludDY0X3QgJGFjX2N2X2NfdWludDY0X3QKLV9BQ0VPRgotOzsKLSAg ZXNhYwogCi1hY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjgiICJhY19jdl9jX3VpbnQ4 X3QiCi1jYXNlICRhY19jdl9jX3VpbnQ4X3QgaW4gIygKLSAgbm98eWVzKSA7OyAjKAorZmkKK2lm IHRlc3QgLXogIiRhY19jdl9wYXRoX1BLR19DT05GSUciOyB0aGVuCisgIGFjX3B0X1BLR19DT05G SUc9JFBLR19DT05GSUcKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJwa2ctY29uZmln Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBwa2ct Y29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09O RklHK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs c2UKKyAgY2FzZSAkYWNfcHRfUEtHX0NPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAg YWNfY3ZfcGF0aF9hY19wdF9QS0dfQ09ORklHPSIkYWNfcHRfUEtHX0NPTkZJRyIgIyBMZXQgdGhl IHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CiAgICopCisgIGFzX3Nh dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94 ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhf YWNfcHRfUEtHX0NPTkZJRz0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3Jk JGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0k YXNfc2F2ZV9JRlMKIAotJGFzX2VjaG8gIiNkZWZpbmUgX1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5o Ci0KLQotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSB1aW50OF90ICRhY19jdl9j X3VpbnQ4X3QKLV9BQ0VPRgotOzsKLSAgZXNhYwotCi1hY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F Tk8iICJwdHJkaWZmX3QiICJhY19jdl90eXBlX3B0cmRpZmZfdCIgIiRhY19pbmNsdWRlc19kZWZh dWx0IgotaWYgdGVzdCAieCRhY19jdl90eXBlX3B0cmRpZmZfdCIgPSB4IiJ5ZXM7IHRoZW4gOgot Ci1jYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfUFRSRElGRl9UIDEKLV9B Q0VPRgotCi0KKyAgOzsKK2VzYWMKK2ZpCithY19wdF9QS0dfQ09ORklHPSRhY19jdl9wYXRoX2Fj X3B0X1BLR19DT05GSUcKK2lmIHRlc3QgLW4gIiRhY19wdF9QS0dfQ09ORklHIjsgdGhlbgorICB7 ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3B0X1BL R19DT05GSUciID4mNQorJGFzX2VjaG8gIiRhY19wdF9QS0dfQ09ORklHIiA+JjY7IH0KK2Vsc2UK KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+ JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiBmaQogCi0KLSMgQ2hlY2tzIGZvciBsaWJyYXJ5IGZ1 bmN0aW9ucy4KLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp bmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVycm9y X2F0X2xpbmUuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUr c2V0fSIgPSBzZXQ7IHRoZW4gOgotICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQot ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Ci0vKiBlbmQgY29u ZmRlZnMuaC4gICovCi0jaW5jbHVkZSA8ZXJyb3IuaD4KLWludAotbWFpbiAoKQotewotZXJyb3Jf YXRfbGluZSAoMCwgMCwgIiIsIDAsICJhbiBlcnJvciBvY2N1cnJlZCIpOwotICA7Ci0gIHJldHVy biAwOwotfQotX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Ci0g IGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPXllcworICBpZiB0ZXN0ICJ4JGFjX3B0X1BLR19DT05G SUciID0geDsgdGhlbgorICAgIFBLR19DT05GSUc9IiIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3Nz X2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1 c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9Cith Y190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBQS0dfQ09ORklHPSRhY19wdF9QS0dfQ09O RklHCisgIGZpCiBlbHNlCi0gIGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lPW5vCi1maQotcm0gLWYg Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNf ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgUEtHX0NPTkZJRz0iJGFjX2N2X3BhdGhfUEtHX0NP TkZJRyIKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX2Vy cm9yX2F0X2xpbmUiID4mNjsgfQotaWYgdGVzdCAkYWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUgPSBu bzsgdGhlbgotICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiBlcnJvci4kYWNfb2JqZXh0ICIq ICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgZXJyb3IuJGFjX29iamV4dCIKLSA7OwotZXNh YwogCiBmaQotCi1mb3IgYWNfaGVhZGVyIGluIHZmb3JrLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVj a19oZWFkZXJfbW9uZ3JlbCAiJExJTkVOTyIgInZmb3JrLmgiICJhY19jdl9oZWFkZXJfdmZvcmtf aCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgotaWYgdGVzdCAieCRhY19jdl9oZWFkZXJfdmZvcmtf aCIgPSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5l IEhBVkVfVkZPUktfSCAxCi1fQUNFT0YKLQoraWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVu CisJX3BrZ19taW5fdmVyc2lvbj0wLjkuMAorCXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogY2hlY2tpbmcgcGtnLWNvbmZpZyBpcyBhdCBsZWFzdCB2ZXJzaW9uICRfcGtn X21pbl92ZXJzaW9uIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHBrZy1jb25maWcgaXMgYXQg bGVhc3QgdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbi4uLiAiID4mNjsgfQorCWlmICRQS0dfQ09O RklHIC0tYXRsZWFzdC1wa2djb25maWctdmVyc2lvbiAkX3BrZ19taW5fdmVyc2lvbjsgdGhlbgor CQl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+ JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorCWVsc2UKKwkJeyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9 CisJCVBLR19DT05GSUc9IiIKKwlmaQogZmkKIAotZG9uZQotCi1mb3IgYWNfZnVuYyBpbiBmb3Jr IHZmb3JrCi1kbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMi IHwgJGFzX3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIk YXNfYWNfdmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRo ZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFW RV8kYWNfZnVuYyIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQotZmkKLWRvbmUKK3BrZ19mYWls ZWQ9bm8KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg Zm9yIGdsaWIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdsaWIuLi4gIiA+JjY7IH0K IAotaWYgdGVzdCAieCRhY19jdl9mdW5jX2ZvcmsiID0geHllczsgdGhlbgotICB7ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIGZvcmsi ID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yay4uLiAiID4mNjsgfQot aWYgdGVzdCAiJHthY19jdl9mdW5jX2Zvcmtfd29ya3Mrc2V0fSIgPSBzZXQ7IHRoZW4gOgotICAk YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgotZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGls aW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1jcm9zcworaWYgdGVz dCAtbiAiJGdsaWJfQ0ZMQUdTIjsgdGhlbgorICAgIHBrZ19jdl9nbGliX0NGTEFHUz0iJGdsaWJf Q0ZMQUdTIgorIGVsaWYgdGVzdCAtbiAiJFBLR19DT05GSUciOyB0aGVuCisgICAgaWYgdGVzdCAt biAiJFBLR19DT05GSUciICYmIFwKKyAgICB7IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu by0kTElORU5PfTogXCRQS0dfQ09ORklHIC0tZXhpc3RzIC0tcHJpbnQtZXJyb3JzIFwiZ2xpYi0y LjBcIiI7IH0gPiY1CisgICgkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9ycyAiZ2xp Yi0yLjAiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu ZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0g MDsgfTsgdGhlbgorICBwa2dfY3ZfZ2xpYl9DRkxBR1M9YCRQS0dfQ09ORklHIC0tY2ZsYWdzICJn bGliLTIuMCIgMj4vZGV2L251bGxgCiBlbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg PmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19k ZWZhdWx0Ci1pbnQKLW1haW4gKCkKLXsKLQotCSAgLyogQnkgUnVlZGlnZXIgS3VobG1hbm4uICov Ci0JICByZXR1cm4gZm9yayAoKSA8IDA7Ci0KLSAgOwotICByZXR1cm4gMDsKLX0KLV9BQ0VPRgot aWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfZm9ya193 b3Jrcz15ZXMKKyAgcGtnX2ZhaWxlZD15ZXMKK2ZpCisgZWxzZQorICAgIHBrZ19mYWlsZWQ9dW50 cmllZAorZmkKK2lmIHRlc3QgLW4gIiRnbGliX0xJQlMiOyB0aGVuCisgICAgcGtnX2N2X2dsaWJf TElCUz0iJGdsaWJfTElCUyIKKyBlbGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIjsgdGhlbgorICAg IGlmIHRlc3QgLW4gIiRQS0dfQ09ORklHIiAmJiBcCisgICAgeyB7ICRhc19lY2hvICIkYXNfbWU6 JHthc19saW5lbm8tJExJTkVOT306IFwkUEtHX0NPTkZJRyAtLWV4aXN0cyAtLXByaW50LWVycm9y cyBcImdsaWItMi4wXCIiOyB9ID4mNQorICAoJFBLR19DT05GSUcgLS1leGlzdHMgLS1wcmludC1l cnJvcnMgImdsaWItMi4wIikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19t ZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFj X3N0YXR1cyA9IDA7IH07IHRoZW4KKyAgcGtnX2N2X2dsaWJfTElCUz1gJFBLR19DT05GSUcgLS1s aWJzICJnbGliLTIuMCIgMj4vZGV2L251bGxgCiBlbHNlCi0gIGFjX2N2X2Z1bmNfZm9ya193b3Jr cz1ubworICBwa2dfZmFpbGVkPXllcwogZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRl c3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFj X29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKKyBlbHNlCisgICAgcGtnX2Zh aWxlZD11bnRyaWVkCiBmaQogCi1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2Zvcmtfd29ya3MiID4mNQotJGFzX2VjaG8gIiRh Y19jdl9mdW5jX2Zvcmtfd29ya3MiID4mNjsgfQogCisKK2lmIHRlc3QgJHBrZ19mYWlsZWQgPSB5 ZXM7IHRoZW4KKyAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl c3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKworaWYgJFBLR19DT05GSUcgLS1h dGxlYXN0LXBrZ2NvbmZpZy12ZXJzaW9uIDAuMjA7IHRoZW4KKyAgICAgICAgX3BrZ19zaG9ydF9l cnJvcnNfc3VwcG9ydGVkPXllcwogZWxzZQotICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9JGFjX2N2 X2Z1bmNfZm9yaworICAgICAgICBfcGtnX3Nob3J0X2Vycm9yc19zdXBwb3J0ZWQ9bm8KIGZpCi1p ZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KLSAgY2FzZSAk aG9zdCBpbgotICAgICotKi1hbWlnYW9zKiB8ICotKi1tc2Rvc2RqZ3BwKikKLSAgICAgICMgT3Zl cnJpZGUsIGFzIHRoZXNlIHN5c3RlbXMgaGF2ZSBvbmx5IGEgZHVtbXkgZm9yaygpIHN0dWIKLSAg ICAgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz1ubwotICAgICAgOzsKLSAgICAqKQotICAgICAgYWNf Y3ZfZnVuY19mb3JrX3dvcmtzPXllcwotICAgICAgOzsKLSAgZXNhYwotICB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19m b3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiY1Ci0kYXNf ZWNobyAiJGFzX21lOiBXQVJOSU5HOiByZXN1bHQgJGFjX2N2X2Z1bmNfZm9ya193b3JrcyBndWVz c2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mMjt9Ci1maQotYWNfY3ZfZnVuY192 Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yawotaWYgdGVzdCAieCRhY19jdl9mdW5jX3Zmb3Jr IiA9IHh5ZXM7IHRoZW4KLSAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyBmb3Igd29ya2luZyB2Zm9yayIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3Igd29ya2luZyB2Zm9yay4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3Zmb3Jr X3dvcmtzK3NldH0iID0gc2V0OyB0aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK LWVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19j dl9mdW5jX3Zmb3JrX3dvcmtzPWNyb3NzCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKLS8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLS8qIFRoYW5rcyB0 byBQYXVsIEVnZ2VydCBmb3IgdGhpcyB0ZXN0LiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0Ci0j aW5jbHVkZSA8c3lzL3dhaXQuaD4KLSNpZmRlZiBIQVZFX1ZGT1JLX0gKLSMgaW5jbHVkZSA8dmZv cmsuaD4KLSNlbmRpZgotLyogT24gc29tZSBzcGFyYyBzeXN0ZW1zLCBjaGFuZ2VzIGJ5IHRoZSBj aGlsZCB0byBsb2NhbCBhbmQgaW5jb21pbmcKLSAgIGFyZ3VtZW50IHJlZ2lzdGVycyBhcmUgcHJv cGFnYXRlZCBiYWNrIHRvIHRoZSBwYXJlbnQuICBUaGUgY29tcGlsZXIKLSAgIGlzIHRvbGQgYWJv dXQgdGhpcyB3aXRoICNpbmNsdWRlIDx2Zm9yay5oPiwgYnV0IHNvbWUgY29tcGlsZXJzCi0gICAo ZS5nLiBnY2MgLU8pIGRvbid0IGdyb2sgPHZmb3JrLmg+LiAgVGVzdCBmb3IgdGhpcyBieSB1c2lu ZyBhCi0gICBzdGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVzcyBpcyBwdXQgaW50byBhIHJlZ2lz dGVyIHRoYXQgaXMKLSAgIGNsb2JiZXJlZCBieSB0aGUgdmZvcmsuICAqLwotc3RhdGljIHZvaWQK LSNpZmRlZiBfX2NwbHVzcGx1cwotc3BhcmNfYWRkcmVzc190ZXN0IChpbnQgYXJnKQotIyBlbHNl Ci1zcGFyY19hZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsKLSNlbmRpZgotewotICBzdGF0aWMg cGlkX3QgY2hpbGQ7Ci0gIGlmICghY2hpbGQpIHsKLSAgICBjaGlsZCA9IHZmb3JrICgpOwotICAg IGlmIChjaGlsZCA8IDApIHsKLSAgICAgIHBlcnJvciAoInZmb3JrIik7Ci0gICAgICBfZXhpdCgy KTsKLSAgICB9Ci0gICAgaWYgKCFjaGlsZCkgewotICAgICAgYXJnID0gZ2V0cGlkKCk7Ci0gICAg ICB3cml0ZSgtMSwgIiIsIDApOwotICAgICAgX2V4aXQgKGFyZyk7Ci0gICAgfQotICB9Ci19Cisg ICAgICAgIGlmIHRlc3QgJF9wa2dfc2hvcnRfZXJyb3JzX3N1cHBvcnRlZCA9IHllczsgdGhlbgor CSAgICAgICAgZ2xpYl9QS0dfRVJST1JTPWAkUEtHX0NPTkZJRyAtLXNob3J0LWVycm9ycyAtLXBy aW50LWVycm9ycyAiZ2xpYi0yLjAiIDI+JjFgCisgICAgICAgIGVsc2UKKwkgICAgICAgIGdsaWJf UEtHX0VSUk9SUz1gJFBLR19DT05GSUcgLS1wcmludC1lcnJvcnMgImdsaWItMi4wIiAyPiYxYAor ICAgICAgICBmaQorCSMgUHV0IHRoZSBuYXN0eSBlcnJvciBtZXNzYWdlIGluIGNvbmZpZy5sb2cg d2hlcmUgaXQgYmVsb25ncworCWVjaG8gIiRnbGliX1BLR19FUlJPUlMiID4mNQogCi1pbnQKLW1h aW4gKCkKLXsKLSAgcGlkX3QgcGFyZW50ID0gZ2V0cGlkICgpOwotICBwaWRfdCBjaGlsZDsKLQot ICBzcGFyY19hZGRyZXNzX3Rlc3QgKDApOwotCi0gIGNoaWxkID0gdmZvcmsgKCk7Ci0KLSAgaWYg KGNoaWxkID09IDApIHsKLSAgICAvKiBIZXJlIGlzIGFub3RoZXIgdGVzdCBmb3Igc3BhcmMgdmZv cmsgcmVnaXN0ZXIgcHJvYmxlbXMuICBUaGlzCi0gICAgICAgdGVzdCB1c2VzIGxvdHMgb2YgbG9j YWwgdmFyaWFibGVzLCBhdCBsZWFzdCBhcyBtYW55IGxvY2FsCi0gICAgICAgdmFyaWFibGVzIGFz IG1haW4gaGFzIGFsbG9jYXRlZCBzbyBmYXIgaW5jbHVkaW5nIGNvbXBpbGVyCi0gICAgICAgdGVt cG9yYXJpZXMuICA0IGxvY2FscyBhcmUgZW5vdWdoIGZvciBnY2MgMS40MC4zIG9uIGEgU29sYXJp cwotICAgICAgIDQuMS4zIHNwYXJjLCBidXQgd2UgdXNlIDggdG8gYmUgc2FmZS4gIEEgYnVnZ3kg Y29tcGlsZXIgc2hvdWxkCi0gICAgICAgcmV1c2UgdGhlIHJlZ2lzdGVyIG9mIHBhcmVudCBmb3Ig b25lIG9mIHRoZSBsb2NhbCB2YXJpYWJsZXMsCi0gICAgICAgc2luY2UgaXQgd2lsbCB0aGluayB0 aGF0IHBhcmVudCBjYW4ndCBwb3NzaWJseSBiZSB1c2VkIGFueSBtb3JlCi0gICAgICAgaW4gdGhp cyByb3V0aW5lLiAgQXNzaWduaW5nIHRvIHRoZSBsb2NhbCB2YXJpYWJsZSB3aWxsIHRodXMKLSAg ICAgICBtdW5nZSBwYXJlbnQgaW4gdGhlIHBhcmVudCBwcm9jZXNzLiAgKi8KLSAgICBwaWRfdAot ICAgICAgcCA9IGdldHBpZCgpLCBwMSA9IGdldHBpZCgpLCBwMiA9IGdldHBpZCgpLCBwMyA9IGdl dHBpZCgpLAotICAgICAgcDQgPSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwgcDYgPSBnZXRwaWQo KSwgcDcgPSBnZXRwaWQoKTsKLSAgICAvKiBDb252aW5jZSB0aGUgY29tcGlsZXIgdGhhdCBwLi5w NyBhcmUgbGl2ZTsgb3RoZXJ3aXNlLCBpdCBtaWdodAotICAgICAgIHVzZSB0aGUgc2FtZSBoYXJk d2FyZSByZWdpc3RlciBmb3IgYWxsIDggbG9jYWwgdmFyaWFibGVzLiAgKi8KLSAgICBpZiAocCAh PSBwMSB8fCBwICE9IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNAotCXx8IHAgIT0gcDUgfHwgcCAh PSBwNiB8fCBwICE9IHA3KQotICAgICAgX2V4aXQoMSk7Ci0KLSAgICAvKiBPbiBzb21lIHN5c3Rl bXMgKGUuZy4gSVJJWCAzLjMpLCB2Zm9yayBkb2Vzbid0IHNlcGFyYXRlIHBhcmVudAotICAgICAg IGZyb20gY2hpbGQgZmlsZSBkZXNjcmlwdG9ycy4gIElmIHRoZSBjaGlsZCBjbG9zZXMgYSBkZXNj cmlwdG9yCi0gICAgICAgYmVmb3JlIGl0IGV4ZWNzIG9yIGV4aXRzLCB0aGlzIG11bmdlcyB0aGUg cGFyZW50J3MgZGVzY3JpcHRvcgotICAgICAgIGFzIHdlbGwuICBUZXN0IGZvciB0aGlzIGJ5IGNs b3Npbmcgc3Rkb3V0IGluIHRoZSBjaGlsZC4gICovCi0gICAgX2V4aXQoY2xvc2UoZmlsZW5vKHN0 ZG91dCkpICE9IDApOwotICB9IGVsc2UgewotICAgIGludCBzdGF0dXM7Ci0gICAgc3RydWN0IHN0 YXQgc3Q7CisJYXNfZm5fZXJyb3IgJD8gIlBhY2thZ2UgcmVxdWlyZW1lbnRzIChnbGliLTIuMCkg d2VyZSBub3QgbWV0OgogCi0gICAgd2hpbGUgKHdhaXQoJnN0YXR1cykgIT0gY2hpbGQpCi0gICAg ICA7Ci0gICAgcmV0dXJuICgKLQkgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3Jr aW5nPyAgKi8KLQkgY2hpbGQgPCAwCiskZ2xpYl9QS0dfRVJST1JTCiAKLQkgLyogRGlkIHRoZSBj aGlsZCBmYWlsPyAgKFRoaXMgc2hvdWxkbid0IGhhcHBlbi4pICAqLwotCSB8fCBzdGF0dXMKK0Nv bnNpZGVyIGFkanVzdGluZyB0aGUgUEtHX0NPTkZJR19QQVRIIGVudmlyb25tZW50IHZhcmlhYmxl IGlmIHlvdQoraW5zdGFsbGVkIHNvZnR3YXJlIGluIGEgbm9uLXN0YW5kYXJkIHByZWZpeC4KIAot CSAvKiBEaWQgdGhlIHZmb3JrL2NvbXBpbGVyIGJ1ZyBvY2N1cj8gICovCi0JIHx8IHBhcmVudCAh PSBnZXRwaWQoKQorQWx0ZXJuYXRpdmVseSwgeW91IG1heSBzZXQgdGhlIGVudmlyb25tZW50IHZh cmlhYmxlcyBnbGliX0NGTEFHUworYW5kIGdsaWJfTElCUyB0byBhdm9pZCB0aGUgbmVlZCB0byBj YWxsIHBrZy1jb25maWcuCitTZWUgdGhlIHBrZy1jb25maWcgbWFuIHBhZ2UgZm9yIG1vcmUgZGV0 YWlscy4iICIkTElORU5PIiA1CitlbGlmIHRlc3QgJHBrZ19mYWlsZWQgPSB1bnRyaWVkOyB0aGVu CisgICAgIAl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog bm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KKwl7IHsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjUKKyRhc19lY2hvICIk YXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2ZuX2Vycm9yICQ/ICJUaGUg cGtnLWNvbmZpZyBzY3JpcHQgY291bGQgbm90IGJlIGZvdW5kIG9yIGlzIHRvbyBvbGQuICBNYWtl IHN1cmUgaXQKK2lzIGluIHlvdXIgUEFUSCBvciBzZXQgdGhlIFBLR19DT05GSUcgZW52aXJvbm1l bnQgdmFyaWFibGUgdG8gdGhlIGZ1bGwKK3BhdGggdG8gcGtnLWNvbmZpZy4KIAotCSAvKiBEaWQg dGhlIGZpbGUgZGVzY3JpcHRvciBidWcgb2NjdXI/ICAqLwotCSB8fCBmc3RhdChmaWxlbm8oc3Rk b3V0KSwgJnN0KSAhPSAwCi0JICk7Ci0gIH0KLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVu ICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfdmZvcmtfd29ya3M9eWVzCitBbHRlcm5h dGl2ZWx5LCB5b3UgbWF5IHNldCB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGVzIGdsaWJfQ0ZMQUdT CithbmQgZ2xpYl9MSUJTIHRvIGF2b2lkIHRoZSBuZWVkIHRvIGNhbGwgcGtnLWNvbmZpZy4KK1Nl ZSB0aGUgcGtnLWNvbmZpZyBtYW4gcGFnZSBmb3IgbW9yZSBkZXRhaWxzLgorCitUbyBnZXQgcGtn LWNvbmZpZywgc2VlIDxodHRwOi8vcGtnLWNvbmZpZy5mcmVlZGVza3RvcC5vcmcvPi4KK1NlZSBc YGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1IDsgfQogZWxzZQotICBh Y19jdl9mdW5jX3Zmb3JrX3dvcmtzPW5vCi1maQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25m dGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4k YWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAotZmkKKwlnbGliX0NGTEFH Uz0kcGtnX2N2X2dsaWJfQ0ZMQUdTCisJZ2xpYl9MSUJTPSRwa2dfY3ZfZ2xpYl9MSUJTCisgICAg ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMi ID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CiAKIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfdmZvcmtfd29ya3MiID4mNQot JGFzX2VjaG8gIiRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA+JjY7IH0KIAotZmk7Ci1pZiB0ZXN0 ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7IHRoZW4KLSAgYWNfY3ZfZnVuY192 Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yawotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s aW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY192Zm9ya193b3JrcyBn dWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24iID4mNQotJGFzX2VjaG8gIiRhc19t ZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIGd1ZXNzZWQgYmVjYXVz ZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KKyMgQ2hlY2sgbGlicmFyeSBwYXRoCitpZiB0 ZXN0ICJcJHtleGVjX3ByZWZpeH0vbGliIiA9ICIkbGliZGlyIjsgdGhlbiA6CisgIGlmIHRlc3Qg IiRleGVjX3ByZWZpeCIgPSAiTk9ORSIgJiYgdGVzdCAiJHByZWZpeCIgIT0gIk5PTkUiOyB0aGVu IDoKKyAgZXhlY19wcmVmaXg9JHByZWZpeAogZmkKKyAgICBpZiB0ZXN0ICIkZXhlY19wcmVmaXgi ID0gIk5PTkUiOyB0aGVuIDoKKyAgZXhlY19wcmVmaXg9JGFjX2RlZmF1bHRfcHJlZml4CitmaQor ICAgIGlmIHRlc3QgLWQgIiR7ZXhlY19wcmVmaXh9L2xpYjY0IjsgdGhlbiA6CiAKLWlmIHRlc3Qg IngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCi0KLSRhc19lY2hvICIjZGVm aW5lIEhBVkVfV09SS0lOR19WRk9SSyAxIiA+PmNvbmZkZWZzLmgKKyAgICAgICAgTElCX1BBVEg9 ImxpYjY0IgogCiBlbHNlCiAKLSRhc19lY2hvICIjZGVmaW5lIHZmb3JrIGZvcmsiID4+Y29uZmRl ZnMuaAorICAgICAgICBMSUJfUEFUSD0ibGliIgogCiBmaQotaWYgdGVzdCAieCRhY19jdl9mdW5j X2Zvcmtfd29ya3MiID0geHllczsgdGhlbgogCi0kYXNfZWNobyAiI2RlZmluZSBIQVZFX1dPUktJ TkdfRk9SSyAxIiA+PmNvbmZkZWZzLmgKK2Vsc2UKIAotZmkKKyAgICBMSUJfUEFUSD0iJHtsaWJk aXI6YGV4cHIgbGVuZ3RoICIkZXhlY19wcmVmaXgiICsgMWB9IgogCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBfTEFSR0VGSUxFX1NPVVJDRSB2 YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZv ciBfTEFSR0VGSUxFX1NPVVJDRSB2YWx1ZSBuZWVkZWQgZm9yIGxhcmdlIGZpbGVzLi4uICIgPiY2 OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlK3NldH0iID0gc2V0OyB0 aGVuIDoKLSAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKLWVsc2UKLSAgd2hpbGUgOjsgZG8K LSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNv bmZkZWZzLmguICAqLwotI2luY2x1ZGUgPHN5cy90eXBlcy5oPiAvKiBmb3Igb2ZmX3QgKi8KLSAg ICAgI2luY2x1ZGUgPHN0ZGlvLmg+Ci1pbnQKLW1haW4gKCkKLXsKLWludCAoKmZwKSAoRklMRSAq LCBvZmZfdCwgaW50KSA9IGZzZWVrbzsKLSAgICAgcmV0dXJuIGZzZWVrbyAoc3RkaW4sIDAsIDAp ICYmIGZwIChzdGRpbiwgMCwgMCk7Ci0gIDsKLSAgcmV0dXJuIDA7Ci19Ci1fQUNFT0YKLWlmIGFj X2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9z b3VyY2U9bm87IGJyZWFrCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj X29iamV4dCBcCi0gICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKLSAgY2F0 IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAotLyogZW5kIGNvbmZkZWZz LmguICAqLwotI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAxCi0jaW5jbHVkZSA8c3lzL3R5cGVz Lmg+IC8qIGZvciBvZmZfdCAqLwotICAgICAjaW5jbHVkZSA8c3RkaW8uaD4KLWludAotbWFpbiAo KQotewotaW50ICgqZnApIChGSUxFICosIG9mZl90LCBpbnQpID0gZnNlZWtvOwotICAgICByZXR1 cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkgJiYgZnAgKHN0ZGluLCAwLCAwKTsKLSAgOwotICByZXR1 cm4gMDsKLX0KLV9BQ0VPRgotaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgot ICBhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZT0xOyBicmVhawogZmkKLXJtIC1mIGNvcmUgY29u ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAotICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj b25mdGVzdC4kYWNfZXh0Ci0gIGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPXVua25vd24KLSAg YnJlYWsKLWRvbmUKLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlIiA+JjUKLSRhc19lY2hvICIkYWNf Y3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNjsgfQotY2FzZSAkYWNfY3Zfc3lzX2xhcmdlZmls ZV9zb3VyY2UgaW4gIygKLSAgbm8gfCB1bmtub3duKSA7OwotICAqKQotY2F0ID4+Y29uZmRlZnMu aCA8PF9BQ0VPRgotI2RlZmluZSBfTEFSR0VGSUxFX1NPVVJDRSAkYWNfY3Zfc3lzX2xhcmdlZmls ZV9zb3VyY2UKLV9BQ0VPRgotOzsKLWVzYWMKLXJtIC1yZiBjb25mdGVzdCoKLQotIyBXZSB1c2Vk IHRvIHRyeSBkZWZpbmluZyBfWE9QRU5fU09VUkNFPTUwMCB0b28sIHRvIHdvcmsgYXJvdW5kIGEg YnVnCi0jIGluIGdsaWJjIDIuMS4zLCBidXQgdGhhdCBicmVha3MgdG9vIG1hbnkgb3RoZXIgdGhp bmdzLgotIyBJZiB5b3Ugd2FudCBmc2Vla28gYW5kIGZ0ZWxsbyB3aXRoIGdsaWJjLCB1cGdyYWRl IHRvIGEgZml4ZWQgZ2xpYmMuCi1pZiB0ZXN0ICRhY19jdl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSAh PSB1bmtub3duOyB0aGVuCiAKLSRhc19lY2hvICIjZGVmaW5lIEhBVkVfRlNFRUtPIDEiID4+Y29u ZmRlZnMuaAogCi1maQorIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK2FjX2ZuX2NfY2hlY2tfaGVh ZGVyX21vbmdyZWwgIiRMSU5FTk8iICJiemxpYi5oIiAiYWNfY3ZfaGVhZGVyX2J6bGliX2giICIk YWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX2J6bGliX2giID0g eCIieWVzOyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiBjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVzIHRyYWlsaW5nIHNsYXNo IiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgbHN0YXQgY29ycmVjdGx5IGhhbmRs ZXMgdHJhaWxpbmcgc2xhc2guLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19sc3Rh dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFz X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEJaMl9iekRl Y29tcHJlc3NJbml0IGluIC1sYnoyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBCWjJf YnpEZWNvbXByZXNzSW5pdCBpbiAtbGJ6Mi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19jdl9s aWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0K3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2Vj aG9fbiAiKGNhY2hlZCkgIiA+JjYKIGVsc2UKLSAgcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0 LmZpbGUKLWVjaG8gPmNvbmZ0ZXN0LmZpbGUKLWlmIHRlc3QgIiRhc19sbl9zIiA9ICJsbiAtcyIg JiYgbG4gLXMgY29uZnRlc3QuZmlsZSBjb25mdGVzdC5zeW07IHRoZW4KLSAgaWYgdGVzdCAiJGNy b3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4gOgotICBhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJl bmNlc19zbGFzaGVkX3N5bWxpbms9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP RiA+Y29uZnRlc3QuJGFjX2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJT PSItbGJ6MiAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNf ZXh0CiAvKiBlbmQgY29uZmRlZnMuaC4gICovCi0kYWNfaW5jbHVkZXNfZGVmYXVsdAorCisvKiBP dmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAg IFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdD QworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFy IEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwogaW50CiBtYWluICgpCiB7Ci1zdHJ1Y3Qgc3RhdCBz YnVmOwotICAgICAvKiBMaW51eCB3aWxsIGRlcmVmZXJlbmNlIHRoZSBzeW1saW5rIGFuZCBmYWls LCBhcyByZXF1aXJlZCBieSBQT1NJWC4KLQlUaGF0IGlzIGJldHRlciBpbiB0aGUgc2Vuc2UgdGhh dCBpdCBtZWFucyB3ZSB3aWxsIG5vdAotCWhhdmUgdG8gY29tcGlsZSBhbmQgdXNlIHRoZSBsc3Rh dCB3cmFwcGVyLiAgKi8KLSAgICAgcmV0dXJuIGxzdGF0ICgiY29uZnRlc3Quc3ltLyIsICZzYnVm KSA9PSAwOworcmV0dXJuIEJaMl9iekRlY29tcHJlc3NJbml0ICgpOwogICA7CiAgIHJldHVybiAw OwogfQogX0FDRU9GCi1pZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNf Y3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcwotZWxzZQotICBh Y19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9bm8KLWZpCi1ybSAt ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj X2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k YWNfZXh0Ci1maQotCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj X2N2X2xpYl9iejJfQloyX2J6RGVjb21wcmVzc0luaXQ9eWVzCiBlbHNlCi0gICMgSWYgdGhlIGBs biAtcycgY29tbWFuZCBmYWlsZWQsIHRoZW4gd2UgcHJvYmFibHkgZG9uJ3QgZXZlbgotICAjIGhh dmUgYW4gbHN0YXQgZnVuY3Rpb24uCi0gIGFjX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3Ns YXNoZWRfc3ltbGluaz1ubworICBhY19jdl9saWJfYnoyX0JaMl9iekRlY29tcHJlc3NJbml0PW5v CiBmaQotcm0gLWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKLQorcm0gLWYgY29yZSBjb25m dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv bmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9iejJf QloyX2J6RGVjb21wcmVzc0luaXQiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfYnoyX0JaMl9i ekRlY29tcHJlc3NJbml0IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2J6Ml9CWjJfYnpE ZWNvbXByZXNzSW5pdCIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGliPSIkemxpYiAtREhBVkVfQlpM SUIgLWxiejIiCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy ZXN1bHQ6ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID4m NQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxp bmsiID4mNjsgfQotCi10ZXN0ICRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVk X3N5bWxpbmsgPSB5ZXMgJiYKIAotY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgotI2RlZmluZSBM U1RBVF9GT0xMT1dTX1NMQVNIRURfU1lNTElOSyAxCi1fQUNFT0YKIAorZmkKIAotaWYgdGVzdCAi eCRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbmsiID0geG5vOyB0 aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIGxzdGF0LiRhY19vYmpleHQgIiogKSA7 OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyBsc3RhdC4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCiAK LWZpCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibHptYS5oIiAiYWNf Y3ZfaGVhZGVyX2x6bWFfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j dl9oZWFkZXJfbHptYV9oIiA9IHgiInllczsgdGhlbiA6CiAKLXsgJGFzX2VjaG8gIiRhc19tZTok e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVz IG1ha2VkZXYiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBk ZWZpbmVzIG1ha2VkZXYuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3N5c190 eXBlc19oX21ha2VkZXYrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7 YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgbHptYV9zdHJlYW1fZGVjb2RlciBpbiAt bGx6bWEiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGx6bWFfc3RyZWFtX2RlY29kZXIg aW4gLWxsem1hLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl9sem1hX2x6bWFfc3Ry ZWFtX2RlY29kZXIrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAi ID4mNgogZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0 CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sbHptYSAgJExJQlMiCitj YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQgY29uZmRl ZnMuaC4gICovCi0jaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisKKy8qIE92ZXJyaWRlIGFueSBHQ0Mg aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVz ZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFu ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lm ZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgbHptYV9zdHJlYW1fZGVj b2RlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuIG1ha2VkZXYoMCwgMCk7CityZXR1cm4g bHptYV9zdHJlYW1fZGVjb2RlciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VPRgogaWYg YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9oZWFkZXJfc3lzX3R5 cGVzX2hfbWFrZWRldj15ZXMKKyAgYWNfY3ZfbGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj15 ZXMKIGVsc2UKLSAgYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXY9bm8KKyAgYWNfY3Zf bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2Rlcj1ubwogZmkKIHJtIC1mIGNvcmUgY29uZnRlc3Qu ZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAogICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVz dC4kYWNfZXh0Ci0KLWZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtlZGV2IiA+JjUKLSRhc19lY2hv ICIkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYiID4mNjsgfQotCi1pZiB0ZXN0ICRh Y19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5vOyB0aGVuCi1hY19mbl9jX2NoZWNr X2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL21rZGV2LmgiICJhY19jdl9oZWFkZXJfc3lz X21rZGV2X2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKLWlmIHRlc3QgIngkYWNfY3ZfaGVhZGVy X3N5c19ta2Rldl9oIiA9IHgiInllczsgdGhlbiA6Ci0KLSRhc19lY2hvICIjZGVmaW5lIE1BSk9S X0lOX01LREVWIDEiID4+Y29uZmRlZnMuaAotCitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJT CiBmaQotCi0KLQotICBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX21rZGV2X2ggPSBubzsgdGhl bgotICAgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICJzeXMvc3lzbWFj cm9zLmgiICJhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiAiJGFjX2luY2x1ZGVzX2RlZmF1 bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zeXNfc3lzbWFjcm9zX2giID0geCIieWVzOyB0 aGVuIDoKLQotJGFzX2VjaG8gIiNkZWZpbmUgTUFKT1JfSU5fU1lTTUFDUk9TIDEiID4+Y29uZmRl ZnMuaAotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2N2X2xpYl9sem1hX2x6bWFfc3RyZWFtX2RlY29kZXIiID4mNQorJGFzX2VjaG8gIiRhY19j dl9saWJfbHptYV9sem1hX3N0cmVhbV9kZWNvZGVyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3Zf bGliX2x6bWFfbHptYV9zdHJlYW1fZGVjb2RlciIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGliPSIk emxpYiAtREhBVkVfTFpNQSAtbGx6bWEiCiBmaQogCiAKLSAgZmkKIGZpCiAKLWZvciBhY19oZWFk ZXIgaW4gc3RkbGliLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3JlbCAiJExJ TkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAiJGFjX2luY2x1ZGVzX2Rl ZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIgPSB4IiJ5ZXM7IHRoZW4g OgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfU1RETElCX0ggMQot X0FDRU9GCi0KLWZpCiAKLWRvbmUKK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F Tk8iICJsem8vbHpvMXguaCIgImFjX2N2X2hlYWRlcl9sem9fbHpvMXhfaCIgIiRhY19pbmNsdWRl c19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl9oZWFkZXJfbHpvX2x6bzF4X2giID0geCIieWVz OyB0aGVuIDoKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj a2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSBtYWxsb2MiID4mNQotJGFzX2VjaG9fbiAiY2hl Y2tpbmcgZm9yIEdOVSBsaWJjIGNvbXBhdGlibGUgbWFsbG9jLi4uICIgPiY2OyB9Ci1pZiB0ZXN0 ICIke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRh c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsem8xeF9k ZWNvbXByZXNzIGluIC1sbHpvMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgbHpvMXhf ZGVjb21wcmVzcyBpbiAtbGx6bzIuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2x6 bzJfbHpvMXhfZGVjb21wcmVzcytzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihj YWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0 aGVuIDoKLSAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsPW5vCi1lbHNlCi0gIGNhdCBjb25m ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVf TElCUz0kTElCUworTElCUz0iLWxsem8yICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNF T0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSNpZiBkZWZpbmVk IFNURENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKLSMgaW5jbHVkZSA8c3RkbGli Lmg+Ci0jZWxzZQotY2hhciAqbWFsbG9jICgpOwotI2VuZGlmCiAKKy8qIE92ZXJyaWRlIGFueSBH Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgbHpvMXhfZGVjb21w cmVzcyAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuICEgbWFsbG9jICgwKTsKK3JldHVybiBs em8xeF9kZWNvbXByZXNzICgpOwogICA7CiAgIHJldHVybiAwOwogfQogX0FDRU9GCi1pZiBhY19m bl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25u dWxsPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9s aWJfbHpvMl9sem8xeF9kZWNvbXByZXNzPXllcwogZWxzZQotICBhY19jdl9mdW5jX21hbGxvY18w X25vbm51bGw9bm8KKyAgYWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcz1ubwogZmkKLXJt IC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3Qk YWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0 LiRhY19leHQKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAor ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19s aWJfc2F2ZV9MSUJTCiBmaQotCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO T306IHJlc3VsdDogJGFjX2N2X2xpYl9sem8yX2x6bzF4X2RlY29tcHJlc3MiID4mNQorJGFzX2Vj aG8gIiRhY19jdl9saWJfbHpvMl9sem8xeF9kZWNvbXByZXNzIiA+JjY7IH0KK2lmIHRlc3QgIngk YWNfY3ZfbGliX2x6bzJfbHpvMXhfZGVjb21wcmVzcyIgPSB4IiJ5ZXM7IHRoZW4gOgorICB6bGli PSIkemxpYiAtREhBVkVfTFpPMVggLWxsem8yIgogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+ JjUKLSRhc19lY2hvICIkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KLWlmIHRl c3QgJGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVsbCA9IHllczsgdGhlbiA6Ci0KLSRhc19lY2hv ICIjZGVmaW5lIEhBVkVfTUFMTE9DIDEiID4+Y29uZmRlZnMuaAotCi1lbHNlCi0gICRhc19lY2hv ICIjZGVmaW5lIEhBVkVfTUFMTE9DIDAiID4+Y29uZmRlZnMuaAotCi0gICBjYXNlICIgJExJQk9C SlMgIiBpbgotICAqIiBtYWxsb2MuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9IiRM SUJPQkpTIG1hbGxvYy4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCi0KIAotJGFzX2VjaG8gIiNkZWZp bmUgbWFsbG9jIHJwbF9tYWxsb2MiID4+Y29uZmRlZnMuaAogCiBmaQogCiAKLXsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5k IHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tp bmcgd2hldGhlciB0aW1lLmggYW5kIHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQuLi4g IiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfaGVhZGVyX3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4g OgorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv ciBpb19zZXR1cCBpbiAtbGFpbyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgaW9fc2V0 dXAgaW4gLWxhaW8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2Fpb19pb19zZXR1 cCtzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNl Ci0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hl Y2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxhaW8gICRMSUJTIgorY2F0IGNvbmZkZWZz LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwot I2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy90aW1lLmg+Ci0jaW5jbHVkZSA8 dGltZS5oPgogCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p ZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1 cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90 eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJD IgorI2VuZGlmCitjaGFyIGlvX3NldHVwICgpOwogaW50CiBtYWluICgpCiB7Ci1pZiAoKHN0cnVj dCB0bSAqKSAwKQotcmV0dXJuIDA7CityZXR1cm4gaW9fc2V0dXAgKCk7CiAgIDsKICAgcmV0dXJu IDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoK LSAgYWNfY3ZfaGVhZGVyX3RpbWU9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg dGhlbiA6CisgIGFjX2N2X2xpYl9haW9faW9fc2V0dXA9eWVzCiBlbHNlCi0gIGFjX2N2X2hlYWRl cl90aW1lPW5vCi1maQotcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4 dCBjb25mdGVzdC4kYWNfZXh0Ci1maQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfdGltZSIgPiY1Ci0kYXNfZWNobyAiJGFjX2N2 X2hlYWRlcl90aW1lIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2hlYWRlcl90aW1lID0geWVzOyB0 aGVuCi0KLSRhc19lY2hvICIjZGVmaW5lIFRJTUVfV0lUSF9TWVNfVElNRSAxIiA+PmNvbmZkZWZz LmgKLQorICBhY19jdl9saWJfYWlvX2lvX3NldHVwPW5vCiBmaQotCi0KLQotCi0gIGZvciBhY19o ZWFkZXIgaW4gJGFjX2hlYWRlcl9saXN0Ci1kbyA6Ci0gIGFzX2FjX0hlYWRlcj1gJGFzX2VjaG8g ImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAKLWFjX2ZuX2NfY2hlY2tfaGVh ZGVyX2NvbXBpbGUgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFzX2FjX0hlYWRlciIgIiRhY19p bmNsdWRlc19kZWZhdWx0Ci0iCi1pZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX0hlYWRlciJcIiA9 IHgieWVzIjsgdGhlbiA6Ci0gIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRh c19lY2hvICJIQVZFXyRhY19oZWFkZXIiIHwgJGFzX3RyX2NwcGAgMQotX0FDRU9GCi0KK3JtIC1m IGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFj X2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBm aQotCi1kb25lCi0KLQotCi0KLQotCi0KLQotICBmb3IgYWNfZnVuYyBpbiAkYWNfZnVuY19saXN0 Ci1kbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz X3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNf dmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgot ICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNf ZnVuYyIgfCAkYXNfdHJfY3BwYCAxCi1fQUNFT0YKLQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfYWlvX2lvX3NldHVwIiA+JjUKKyRh c19lY2hvICIkYWNfY3ZfbGliX2Fpb19pb19zZXR1cCIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2 X2xpYl9haW9faW9fc2V0dXAiID0geCIieWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vs c2UKKyAgc3lzdGVtX2Fpbz0ibiIKIGZpCi1kb25lCi0KIAogCi0KLQoteyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBta3RpbWUiID4m NQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lLi4uICIgPiY2OyB9Ci1p ZiB0ZXN0ICIke2FjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUrc2V0fSIgPSBzZXQ7IHRoZW4gOgor eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgTUQ1 IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBNRDUgaW4gLWxjcnlw dG8uLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2NyeXB0b19NRDUrc2V0fSIgPSBz ZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0 ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfd29ya2luZ19t a3RpbWU9bm8KLWVsc2UKLSAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj X2V4dAorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJ QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CiAvKiBlbmQg Y29uZmRlZnMuaC4gICovCi0vKiBUZXN0IHByb2dyYW0gZnJvbSBQYXVsIEVnZ2VydCBhbmQgVG9u eSBMZW5laXMuICAqLwotI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQotIyBpbmNsdWRlIDxzeXMv dGltZS5oPgotIyBpbmNsdWRlIDx0aW1lLmg+Ci0jZWxzZQotIyBpZmRlZiBIQVZFX1NZU19USU1F X0gKLSMgIGluY2x1ZGUgPHN5cy90aW1lLmg+Ci0jIGVsc2UKLSMgIGluY2x1ZGUgPHRpbWUuaD4K LSMgZW5kaWYKLSNlbmRpZgotCi0jaW5jbHVkZSA8bGltaXRzLmg+Ci0jaW5jbHVkZSA8c3RkbGli Lmg+CiAKLSNpZmRlZiBIQVZFX1VOSVNURF9ICi0jIGluY2x1ZGUgPHVuaXN0ZC5oPgotI2VuZGlm Ci0KLSNpZm5kZWYgSEFWRV9BTEFSTQotIyBkZWZpbmUgYWxhcm0oWCkgLyogZW1wdHkgKi8KKy8q IE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgor ICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg R0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp bGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCiAjZW5kaWYKLQot LyogV29yayBhcm91bmQgcmVkZWZpbml0aW9uIHRvIHJwbF9wdXRlbnYgYnkgb3RoZXIgY29uZmln IHRlc3RzLiAgKi8KLSN1bmRlZiBwdXRlbnYKLQotc3RhdGljIHRpbWVfdCB0aW1lX3RfbWF4Owot c3RhdGljIHRpbWVfdCB0aW1lX3RfbWluOwotCi0vKiBWYWx1ZXMgd2UnbGwgdXNlIHRvIHNldCB0 aGUgVFogZW52aXJvbm1lbnQgdmFyaWFibGUuICAqLwotc3RhdGljIGNvbnN0IGNoYXIgKnR6X3N0 cmluZ3NbXSA9IHsKLSAgKGNvbnN0IGNoYXIgKikgMCwgIlRaPUdNVDAiLCAiVFo9SlNULTkiLAot ICAiVFo9RVNUKzNFRFQrMixNMTAuMS4wLzAwOjAwOjAwLE0yLjMuMC8wMDowMDowMCIKLX07Ci0j ZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9zdHJpbmdzKSAvIHNpemVvZiAodHpfc3RyaW5n c1swXSkpCi0KLS8qIFJldHVybiAwIGlmIG1rdGltZSBmYWlscyB0byBjb252ZXJ0IGEgZGF0ZSBp biB0aGUgc3ByaW5nLWZvcndhcmQgZ2FwLgotICAgQmFzZWQgb24gYSBwcm9ibGVtIHJlcG9ydCBm cm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8KLXN0YXRpYyBpbnQKLXNwcmluZ19mb3J3YXJkX2dhcCAo KQotewotICAvKiBnbGliYyAodXAgdG8gYWJvdXQgMTk5OC0xMC0wNykgZmFpbGVkIHRoaXMgdGVz dC4gKi8KLSAgc3RydWN0IHRtIHRtOwotCi0gIC8qIFVzZSB0aGUgcG9ydGFibGUgUE9TSVguMSBz cGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgotICAgICBpbnN0ZWFkIG9m ICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBidWcgZXZlbgot ICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0ZW5zaW9uLCBv ciBkb24ndCBoYXZlIHRoZQotICAgICBmdWxsIHpvbmVpbmZvIHRhYmxlcyBpbnN0YWxsZWQuICAq LwotICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiKTsKLQotICB0 bS50bV95ZWFyID0gOTg7Ci0gIHRtLnRtX21vbiA9IDM7Ci0gIHRtLnRtX21kYXkgPSA1OwotICB0 bS50bV9ob3VyID0gMjsKLSAgdG0udG1fbWluID0gMDsKLSAgdG0udG1fc2VjID0gMDsKLSAgdG0u dG1faXNkc3QgPSAtMTsKLSAgcmV0dXJuIG1rdGltZSAoJnRtKSAhPSAodGltZV90KSAtMTsKLX0K LQotc3RhdGljIGludAotbWt0aW1lX3Rlc3QxICh0aW1lX3Qgbm93KQotewotICBzdHJ1Y3QgdG0g Kmx0OwotICByZXR1cm4gISAobHQgPSBsb2NhbHRpbWUgKCZub3cpKSB8fCBta3RpbWUgKGx0KSA9 PSBub3c7Ci19Ci0KLXN0YXRpYyBpbnQKLW1rdGltZV90ZXN0ICh0aW1lX3Qgbm93KQotewotICBy ZXR1cm4gKG1rdGltZV90ZXN0MSAobm93KQotCSAgJiYgbWt0aW1lX3Rlc3QxICgodGltZV90KSAo dGltZV90X21heCAtIG5vdykpCi0JICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3QpICh0aW1lX3Rf bWluICsgbm93KSkpOwotfQotCi1zdGF0aWMgaW50Ci1pcml4XzZfNF9idWcgKCkKLXsKLSAgLyog QmFzZWQgb24gY29kZSBmcm9tIEFyaWVsIEZhaWdvbi4gICovCi0gIHN0cnVjdCB0bSB0bTsKLSAg dG0udG1feWVhciA9IDk2OwotICB0bS50bV9tb24gPSAzOwotICB0bS50bV9tZGF5ID0gMDsKLSAg dG0udG1faG91ciA9IDA7Ci0gIHRtLnRtX21pbiA9IDA7Ci0gIHRtLnRtX3NlYyA9IDA7Ci0gIHRt LnRtX2lzZHN0ID0gLTE7Ci0gIG1rdGltZSAoJnRtKTsKLSAgcmV0dXJuIHRtLnRtX21vbiA9PSAy ICYmIHRtLnRtX21kYXkgPT0gMzE7Ci19Ci0KLXN0YXRpYyBpbnQKLWJpZ3RpbWVfdGVzdCAoaW50 IGopCi17Ci0gIHN0cnVjdCB0bSB0bTsKLSAgdGltZV90IG5vdzsKLSAgdG0udG1feWVhciA9IHRt LnRtX21vbiA9IHRtLnRtX21kYXkgPSB0bS50bV9ob3VyID0gdG0udG1fbWluID0gdG0udG1fc2Vj ID0gajsKLSAgbm93ID0gbWt0aW1lICgmdG0pOwotICBpZiAobm93ICE9ICh0aW1lX3QpIC0xKQot ICAgIHsKLSAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwotICAgICAgaWYg KCEgKGx0Ci0JICAgICAmJiBsdC0+dG1feWVhciA9PSB0bS50bV95ZWFyCi0JICAgICAmJiBsdC0+ dG1fbW9uID09IHRtLnRtX21vbgotCSAgICAgJiYgbHQtPnRtX21kYXkgPT0gdG0udG1fbWRheQot CSAgICAgJiYgbHQtPnRtX2hvdXIgPT0gdG0udG1faG91cgotCSAgICAgJiYgbHQtPnRtX21pbiA9 PSB0bS50bV9taW4KLQkgICAgICYmIGx0LT50bV9zZWMgPT0gdG0udG1fc2VjCi0JICAgICAmJiBs dC0+dG1feWRheSA9PSB0bS50bV95ZGF5Ci0JICAgICAmJiBsdC0+dG1fd2RheSA9PSB0bS50bV93 ZGF5Ci0JICAgICAmJiAoKGx0LT50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCBsdC0+dG1faXNkc3Qp Ci0JCSAgPT0gKHRtLnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IHRtLnRtX2lzZHN0KSkpKQotCXJl dHVybiAwOwotICAgIH0KLSAgcmV0dXJuIDE7Ci19Ci0KLXN0YXRpYyBpbnQKLXllYXJfMjA1MF90 ZXN0ICgpCi17Ci0gIC8qIFRoZSBjb3JyZWN0IGFuc3dlciBmb3IgMjA1MC0wMi0wMSAwMDowMDow MCBpbiBQYWNpZmljIHRpbWUsCi0gICAgIGlnbm9yaW5nIGxlYXAgc2Vjb25kcy4gICovCi0gIHVu c2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKLQotICBzdHJ1Y3QgdG0gdG07 Ci0gIHRpbWVfdCB0OwotICB0bS50bV95ZWFyID0gMjA1MCAtIDE5MDA7Ci0gIHRtLnRtX21vbiA9 IDIgLSAxOwotICB0bS50bV9tZGF5ID0gMTsKLSAgdG0udG1faG91ciA9IHRtLnRtX21pbiA9IHRt LnRtX3NlYyA9IDA7Ci0gIHRtLnRtX2lzZHN0ID0gLTE7Ci0KLSAgLyogVXNlIHRoZSBwb3J0YWJs ZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAiCi0gICAg IGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBkZXRlY3QgdGhl IGJ1ZyBldmVuCi0gICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRoZSBPbHNvbiBl eHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCi0gICAgIGZ1bGwgem9uZWluZm8gdGFibGVzIGlu c3RhbGxlZC4gICovCi0gIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4xLjAsTTEwLjUu MCIpOwotCi0gIHQgPSBta3RpbWUgKCZ0bSk7Ci0KLSAgLyogQ2hlY2sgdGhhdCB0aGUgcmVzdWx0 IGlzIGVpdGhlciBhIGZhaWx1cmUsIG9yIGNsb3NlIGVub3VnaAotICAgICB0byB0aGUgY29ycmVj dCBhbnN3ZXIgdGhhdCB3ZSBjYW4gYXNzdW1lIHRoZSBkaXNjcmVwYW5jeSBpcwotICAgICBkdWUg dG8gbGVhcCBzZWNvbmRzLiAgKi8KLSAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0xCi0JICB8fCAo MCA8IHQgJiYgYW5zd2VyIC0gMTIwIDw9IHQgJiYgdCA8PSBhbnN3ZXIgKyAxMjApKTsKLX0KLQor Y2hhciBNRDUgKCk7CiBpbnQKIG1haW4gKCkKIHsKLSAgdGltZV90IHQsIGRlbHRhOwotICBpbnQg aSwgajsKLQotICAvKiBUaGlzIHRlc3QgbWFrZXMgc29tZSBidWdneSBta3RpbWUgaW1wbGVtZW50 YXRpb25zIGxvb3AuCi0gICAgIEdpdmUgdXAgYWZ0ZXIgNjAgc2Vjb25kczsgYSBta3RpbWUgc2xv d2VyIHRoYW4gdGhhdAotICAgICBpc24ndCB3b3J0aCB1c2luZyBhbnl3YXkuICAqLwotICBhbGFy bSAoNjApOwotCi0gIGZvciAoOzspCi0gICAgewotICAgICAgdCA9ICh0aW1lX3RfbWF4IDw8IDEp ICsgMTsKLSAgICAgIGlmICh0IDw9IHRpbWVfdF9tYXgpCi0JYnJlYWs7Ci0gICAgICB0aW1lX3Rf bWF4ID0gdDsKLSAgICB9Ci0gIHRpbWVfdF9taW4gPSAtICgodGltZV90KSB+ICh0aW1lX3QpIDAg PT0gKHRpbWVfdCkgLTEpIC0gdGltZV90X21heDsKLQotICBkZWx0YSA9IHRpbWVfdF9tYXggLyA5 OTc7IC8qIGEgc3VpdGFibGUgcHJpbWUgbnVtYmVyICovCi0gIGZvciAoaSA9IDA7IGkgPCBOX1NU UklOR1M7IGkrKykKLSAgICB7Ci0gICAgICBpZiAodHpfc3RyaW5nc1tpXSkKLQlwdXRlbnYgKChj aGFyKikgdHpfc3RyaW5nc1tpXSk7Ci0KLSAgICAgIGZvciAodCA9IDA7IHQgPD0gdGltZV90X21h eCAtIGRlbHRhOyB0ICs9IGRlbHRhKQotCWlmICghIG1rdGltZV90ZXN0ICh0KSkKLQkgIHJldHVy biAxOwotICAgICAgaWYgKCEgKG1rdGltZV90ZXN0ICgodGltZV90KSAxKQotCSAgICAgJiYgbWt0 aW1lX3Rlc3QgKCh0aW1lX3QpICg2MCAqIDYwKSkKLQkgICAgICYmIG1rdGltZV90ZXN0ICgodGlt ZV90KSAoNjAgKiA2MCAqIDI0KSkpKQotCXJldHVybiAxOwotCi0gICAgICBmb3IgKGogPSAxOyA7 IGogPDw9IDEpCi0JaWYgKCEgYmlndGltZV90ZXN0IChqKSkKLQkgIHJldHVybiAxOwotCWVsc2Ug aWYgKElOVF9NQVggLyAyIDwgaikKLQkgIGJyZWFrOwotICAgICAgaWYgKCEgYmlndGltZV90ZXN0 IChJTlRfTUFYKSkKLQlyZXR1cm4gMTsKLSAgICB9Ci0gIHJldHVybiAhIChpcml4XzZfNF9idWcg KCkgJiYgc3ByaW5nX2ZvcndhcmRfZ2FwICgpICYmIHllYXJfMjA1MF90ZXN0ICgpKTsKK3JldHVy biBNRDUgKCk7CisgIDsKKyAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5X3J1 biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPXllcworaWYg YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfY3J5cHRvX01E NT15ZXMKIGVsc2UKLSAgYWNfY3ZfZnVuY193b3JraW5nX21rdGltZT1ubwotZmkKLXJtIC1mIGNv cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl ZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l eHQKLWZpCi0KKyAgYWNfY3ZfbGliX2NyeXB0b19NRDU9bm8KIGZpCi17ICRhc19lY2hvICIkYXNf bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfd29ya2luZ19ta3Rp bWUiID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lIiA+JjY7IH0KLWlm IHRlc3QgJGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUgPSBubzsgdGhlbgotICBjYXNlICIgJExJ Qk9CSlMgIiBpbgotICAqIiBta3RpbWUuJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9 IiRMSUJPQkpTIG1rdGltZS4kYWNfb2JqZXh0IgotIDs7Ci1lc2FjCi0KK3JtIC1mIGNvcmUgY29u ZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBj b25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCiBmaQotCi0KLQot Ci0KLQotZm9yIGFjX2Z1bmMgaW4gZ2V0cGFnZXNpemUKLWRvIDoKLSAgYWNfZm5fY19jaGVja19m dW5jICIkTElORU5PIiAiZ2V0cGFnZXNpemUiICJhY19jdl9mdW5jX2dldHBhZ2VzaXplIgotaWYg dGVzdCAieCRhY19jdl9mdW5jX2dldHBhZ2VzaXplIiA9IHgiInllczsgdGhlbiA6Cit7ICRhc19l Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl9jcnlw dG9fTUQ1IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2NyeXB0b19NRDUiID4mNjsgfQoraWYg dGVzdCAieCRhY19jdl9saWJfY3J5cHRvX01ENSIgPSB4IiJ5ZXM7IHRoZW4gOgogICBjYXQgPj5j b25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhBVkVfR0VUUEFHRVNJWkUgMQorI2RlZmluZSBI QVZFX0xJQkNSWVBUTyAxCiBfQUNFT0YKIAorICBMSUJTPSItbGNyeXB0byAkTElCUyIKKworZWxz ZQorICBhc19mbl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGliY3J5cHRvIiAiJExJTkVOTyIg NQogZmkKLWRvbmUKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj aGVja2luZyBmb3Igd29ya2luZyBtbWFwIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciB3 b3JraW5nIG1tYXAuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19tbWFwX2ZpeGVk X21hcHBlZCtzZXR9IiA9IHNldDsgdGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l bm8tJExJTkVOT306IGNoZWNraW5nIGZvciBleHQyZnNfb3BlbjIgaW4gLWxleHQyZnMiID4mNQor JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcy4uLiAiID4m NjsgfQoraWYgdGVzdCAiJHthY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMitzZXR9IiA9IHNl dDsgdGhlbiA6CiAgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CiBlbHNlCi0gIGlmIHRlc3Qg IiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKLSAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVk X21hcHBlZD1ubwotZWxzZQotICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k YWNfZXh0CisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1sZXh0MmZzICAk TElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVu ZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0Ci0vKiBtYWxsb2MgbWlnaHQg aGF2ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KLSN1bmRlZiBtYWxsb2MKLQotLyog VGhhbmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3QuCi0gICBI ZXJlIGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKLQltbWFwIHByaXZhdGUgbm90 IGZpeGVkCi0JbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBw ZWQKLQltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCi0JbW1h cCBzaGFyZWQgbm90IGZpeGVkCi0JbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJl bnRseSB1bm1hcHBlZAotCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1h cHBlZAotICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhhdCBjaGFu Z2VzIGNhbm5vdCBiZSByZWFkKCkKLSAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1tYXAncyBi YWNrIGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKLSAgIGFkZHJlc3MuICAoVGhlcmUgaGF2 ZSBiZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQotICAgaW1wbGVt ZW50ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdoZXJlIHRo ZQotICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVt IGJ1ZmZlciBjYWNoZQotICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFuZCBwb3Nz aWJseSBjb250ZW1wb3JhcnkgTmV0QlNELikKLSAgIEZvciBzaGFyZWQgbWFwcGluZ3MsIHdlIHNo b3VsZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0Ci0gICBwcm9wYWdhdGVkIGJh Y2sgdG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KLQotICAgR3JlcCB3 YW50cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgotICAgVGhlIG1haW4gdGhpbmdzIGdy ZXAgbmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKLSAgICogZG9lcyBpdCBleGlzdCBhbmQg aXMgaXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQotICAgKiBob3cgdG8gdXNl IGl0IChCU0QgdmFyaWFudHMpICAqLwotCi0jaW5jbHVkZSA8ZmNudGwuaD4KLSNpbmNsdWRlIDxz eXMvbW1hbi5oPgotCi0jaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVkIEhBVkVf U1RETElCX0gKLWNoYXIgKm1hbGxvYyAoKTsKLSNlbmRpZgotCi0vKiBUaGlzIG1lc3Mgd2FzIGNv cGllZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCi0jaWZuZGVmIEhBVkVfR0VUUEFH RVNJWkUKLSMgaWZkZWYgX1NDX1BBR0VTSVpFCi0jICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBzeXNj b25mKF9TQ19QQUdFU0laRSkKLSMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KLSMgIGlmZGVm IEhBVkVfU1lTX1BBUkFNX0gKLSMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KLSMgICBpZmRlZiBF WEVDX1BBR0VTSVpFCi0jICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJWkUKLSMg ICBlbHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KLSMgICAgaWZkZWYgTkJQRwotIyAgICAgZGVm aW5lIGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQotIyAgICAgaWZuZGVmIENMU0laRQotIyAg ICAgIGRlZmluZSBDTFNJWkUgMQotIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCi0jICAgIGVs c2UgLyogbm8gTkJQRyAqLwotIyAgICAgaWZkZWYgTkJQQwotIyAgICAgIGRlZmluZSBnZXRwYWdl c2l6ZSgpIE5CUEMKLSMgICAgIGVsc2UgLyogbm8gTkJQQyAqLwotIyAgICAgIGlmZGVmIFBBR0VT SVpFCi0jICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCi0jICAgICAgZW5kaWYg LyogUEFHRVNJWkUgKi8KLSMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KLSMgICAgZW5kaWYgLyog bm8gTkJQRyAqLwotIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KLSMgIGVsc2UgLyog bm8gSEFWRV9TWVNfUEFSQU1fSCAqLwotIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgxOTIJLyog cHVudCB0b3RhbGx5ICovCi0jICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCi0jIGVu ZGlmIC8qIG5vIF9TQ19QQUdFU0laRSAqLwotCi0jZW5kaWYgLyogbm8gSEFWRV9HRVRQQUdFU0la RSAqLwogCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4g dHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBl IHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgor I2VuZGlmCitjaGFyIGV4dDJmc19vcGVuMiAoKTsKIGludAogbWFpbiAoKQogewotICBjaGFyICpk YXRhLCAqZGF0YTIsICpkYXRhMzsKLSAgY29uc3QgY2hhciAqY2RhdGEyOwotICBpbnQgaSwgcGFn ZXNpemU7Ci0gIGludCBmZCwgZmQyOwotCi0gIHBhZ2VzaXplID0gZ2V0cGFnZXNpemUgKCk7Ci0K LSAgLyogRmlyc3QsIG1ha2UgYSBmaWxlIHdpdGggc29tZSBrbm93biBnYXJiYWdlIGluIGl0LiAq LwotICBkYXRhID0gKGNoYXIgKikgbWFsbG9jIChwYWdlc2l6ZSk7Ci0gIGlmICghZGF0YSkKLSAg ICByZXR1cm4gMTsKLSAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgKihkYXRh ICsgaSkgPSByYW5kICgpOwotICB1bWFzayAoMCk7Ci0gIGZkID0gY3JlYXQgKCJjb25mdGVzdC5t bWFwIiwgMDYwMCk7Ci0gIGlmIChmZCA8IDApCi0gICAgcmV0dXJuIDI7Ci0gIGlmICh3cml0ZSAo ZmQsIGRhdGEsIHBhZ2VzaXplKSAhPSBwYWdlc2l6ZSkKLSAgICByZXR1cm4gMzsKLSAgY2xvc2Ug KGZkKTsKLQotICAvKiBOZXh0LCBjaGVjayB0aGF0IHRoZSB0YWlsIG9mIGEgcGFnZSBpcyB6ZXJv LWZpbGxlZC4gIEZpbGUgbXVzdCBoYXZlCi0gICAgIG5vbi16ZXJvIGxlbmd0aCwgb3RoZXJ3aXNl IHdlIHJpc2sgU0lHQlVTIGZvciBlbnRpcmUgcGFnZS4gICovCi0gIGZkMiA9IG9wZW4gKCJjb25m dGVzdC50eHQiLCBPX1JEV1IgfCBPX0NSRUFUIHwgT19UUlVOQywgMDYwMCk7Ci0gIGlmIChmZDIg PCAwKQotICAgIHJldHVybiA0OwotICBjZGF0YTIgPSAiIjsKLSAgaWYgKHdyaXRlIChmZDIsIGNk YXRhMiwgMSkgIT0gMSkKLSAgICByZXR1cm4gNTsKLSAgZGF0YTIgPSAoY2hhciAqKSBtbWFwICgw LCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwgTUFQX1NIQVJFRCwgZmQyLCAwTCk7 Ci0gIGlmIChkYXRhMiA9PSBNQVBfRkFJTEVEKQotICAgIHJldHVybiA2OwotICBmb3IgKGkgPSAw OyBpIDwgcGFnZXNpemU7ICsraSkKLSAgICBpZiAoKihkYXRhMiArIGkpKQotICAgICAgcmV0dXJu IDc7Ci0gIGNsb3NlIChmZDIpOwotICBpZiAobXVubWFwIChkYXRhMiwgcGFnZXNpemUpKQotICAg IHJldHVybiA4OwotCi0gIC8qIE5leHQsIHRyeSB0byBtbWFwIHRoZSBmaWxlIGF0IGEgZml4ZWQg YWRkcmVzcyB3aGljaCBhbHJlYWR5IGhhcwotICAgICBzb21ldGhpbmcgZWxzZSBhbGxvY2F0ZWQg YXQgaXQuICBJZiB3ZSBjYW4sIGFsc28gbWFrZSBzdXJlIHRoYXQKLSAgICAgd2Ugc2VlIHRoZSBz YW1lIGdhcmJhZ2UuICAqLwotICBmZCA9IG9wZW4gKCJjb25mdGVzdC5tbWFwIiwgT19SRFdSKTsK LSAgaWYgKGZkIDwgMCkKLSAgICByZXR1cm4gOTsKLSAgaWYgKGRhdGEyICE9IG1tYXAgKGRhdGEy LCBwYWdlc2l6ZSwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwKLQkJICAgICBNQVBfUFJJVkFURSB8 IE1BUF9GSVhFRCwgZmQsIDBMKSkKLSAgICByZXR1cm4gMTA7Ci0gIGZvciAoaSA9IDA7IGkgPCBw YWdlc2l6ZTsgKytpKQotICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEyICsgaSkpCi0gICAg ICByZXR1cm4gMTE7Ci0KLSAgLyogRmluYWxseSwgbWFrZSBzdXJlIHRoYXQgY2hhbmdlcyB0byB0 aGUgbWFwcGVkIGFyZWEgZG8gbm90Ci0gICAgIHBlcmNvbGF0ZSBiYWNrIHRvIHRoZSBmaWxlIGFz IHNlZW4gYnkgcmVhZCgpLiAgKFRoaXMgaXMgYSBidWcgb24KLSAgICAgc29tZSB2YXJpYW50cyBv ZiBpMzg2IHN2cjQuMC4pICAqLwotICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKLSAg ICAqKGRhdGEyICsgaSkgPSAqKGRhdGEyICsgaSkgKyAxOwotICBkYXRhMyA9IChjaGFyICopIG1h bGxvYyAocGFnZXNpemUpOwotICBpZiAoIWRhdGEzKQotICAgIHJldHVybiAxMjsKLSAgaWYgKHJl YWQgKGZkLCBkYXRhMywgcGFnZXNpemUpICE9IHBhZ2VzaXplKQotICAgIHJldHVybiAxMzsKLSAg Zm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCi0gICAgaWYgKCooZGF0YSArIGkpICE9ICoo ZGF0YTMgKyBpKSkKLSAgICAgIHJldHVybiAxNDsKLSAgY2xvc2UgKGZkKTsKK3JldHVybiBleHQy ZnNfb3BlbjIgKCk7CisgIDsKICAgcmV0dXJuIDA7CiB9CiBfQUNFT0YKLWlmIGFjX2ZuX2NfdHJ5 X3J1biAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPXll cworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfZXh0 MmZzX2V4dDJmc19vcGVuMj15ZXMKIGVsc2UKLSAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBl ZD1ubwotZmkKLXJtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5v dXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKLSAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5i ZWFtIGNvbmZ0ZXN0LiRhY19leHQKLWZpCi0KKyAgYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3Bl bjI9bm8KIGZpCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs dDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQotJGFzX2VjaG8gIiRhY19jdl9m dW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KLWlmIHRlc3QgJGFjX2N2X2Z1bmNfbW1hcF9m aXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KLQotJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NTUFQIDEi ID4+Y29uZmRlZnMuaAotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq ZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNf Y2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXJtIC1mIGNvbmZ0ZXN0Lm1tYXAgY29uZnRlc3QudHh0 Ci0KLWZvciBhY19oZWFkZXIgaW4gc3RkbGliLmgKLWRvIDoKLSAgYWNfZm5fY19jaGVja19oZWFk ZXJfbW9uZ3JlbCAiJExJTkVOTyIgInN0ZGxpYi5oIiAiYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiAi JGFjX2luY2x1ZGVzX2RlZmF1bHQiCi1pZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl9zdGRsaWJfaCIg PSB4IiJ5ZXM7IHRoZW4gOgotICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCi0jZGVmaW5lIEhB VkVfU1RETElCX0ggMQotX0FDRU9GCi0KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNQorJGFz X2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY2OyB9CitpZiB0ZXN0ICJ4 JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9IHgiInllczsgdGhlbiA6CisgIGxpYmV4 dDJmcz0ieSIKK2Vsc2UKKyAgbGliZXh0MmZzPSJuIgogZmkKIAotZG9uZQogCi17ICRhc19lY2hv ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBHTlUgbGliYyBjb21w YXRpYmxlIHJlYWxsb2MiID4mNQotJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv bXBhdGlibGUgcmVhbGxvYy4uLiAiID4mNjsgfQotaWYgdGVzdCAiJHthY19jdl9mdW5jX3JlYWxs b2NfMF9ub25udWxsK3NldH0iID0gc2V0OyB0aGVuIDoKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIgaW4gLWxn Y3J5cHQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGdjcnlfbWRfaGFzaF9idWZmZXIg aW4gLWxnY3J5cHQuLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7YWNfY3ZfbGliX2djcnlwdF9nY3J5 X21kX2hhc2hfYnVmZmVyK3NldH0iID0gc2V0OyB0aGVuIDoKICAgJGFzX2VjaG9fbiAiKGNhY2hl ZCkgIiA+JjYKIGVsc2UKLSAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5ZXM7IHRoZW4g OgotICBhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVm cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElC Uz0kTElCUworTElCUz0iLWxnY3J5cHQgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VP RiA+Y29uZnRlc3QuJGFjX2V4dAogLyogZW5kIGNvbmZkZWZzLmguICAqLwotI2lmIGRlZmluZWQg U1REQ19IRUFERVJTIHx8IGRlZmluZWQgSEFWRV9TVERMSUJfSAotIyBpbmNsdWRlIDxzdGRsaWIu aD4KLSNlbHNlCi1jaGFyICpyZWFsbG9jICgpOwotI2VuZGlmCiAKKy8qIE92ZXJyaWRlIGFueSBH Q0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLwor I2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZ2NyeV9tZF9oYXNo X2J1ZmZlciAoKTsKIGludAogbWFpbiAoKQogewotcmV0dXJuICEgcmVhbGxvYyAoMCwgMCk7City ZXR1cm4gZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9BQ0VP RgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfcmVh bGxvY18wX25vbm51bGw9eWVzCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6 CisgIGFjX2N2X2xpYl9nY3J5cHRfZ2NyeV9tZF9oYXNoX2J1ZmZlcj15ZXMKIGVsc2UKLSAgYWNf Y3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbD1ubworICBhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXI9bm8KIGZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21v bi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0LiRhY19vYmpleHQg Y29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBj b25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFj X2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLQoreyAkYXNfZWNobyAiJGFz X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZ2NyeXB0X2djcnlf bWRfaGFzaF9idWZmZXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXIiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfZ2NyeXB0X2djcnlfbWRf aGFzaF9idWZmZXIiID0geCIieWVzOyB0aGVuIDoKKyAgbGliZ2NyeXB0PSJ5IgorZWxzZQorICBs aWJnY3J5cHQ9Im4iCiBmaQoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99 OiByZXN1bHQ6ICRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjUKLSRhc19lY2hvICIk YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5j X3JlYWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKIAotJGFzX2VjaG8gIiNkZWZpbmUgSEFW RV9SRUFMTE9DIDEiID4+Y29uZmRlZnMuaAogCisKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHth c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBwdGhyZWFkIGZsYWciID4mNQorJGFzX2Vj aG9fbiAiY2hlY2tpbmcgZm9yIHB0aHJlYWQgZmxhZy4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHth eF9jdl9wdGhyZWFkX2ZsYWdzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh Y2hlZCkgIiA+JjYKIGVsc2UKLSAgJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9SRUFMTE9DIDAiID4+ Y29uZmRlZnMuaAogCi0gICBjYXNlICIgJExJQk9CSlMgIiBpbgotICAqIiByZWFsbG9jLiRhY19v YmpleHQgIiogKSA7OwotICAqKSBMSUJPQkpTPSIkTElCT0JKUyByZWFsbG9jLiRhY19vYmpleHQi Ci0gOzsKLWVzYWMKKyAgICAgICAgYXhfY3ZfcHRocmVhZF9mbGFncz0tcHRocmVhZAorCisgICAg UFRIUkVBRF9DRkxBR1M9IiRheF9jdl9wdGhyZWFkX2ZsYWdzIgorICAgIFBUSFJFQURfTERGTEFH Uz0iJGF4X2N2X3B0aHJlYWRfZmxhZ3MiCisgICAgUFRIUkVBRF9MSUJTPSIiCisKKworICAgIHNh dmVkX0NGTEFHUz0iJENGTEFHUyIKKworICAgIHNhdmVkX0xERkxBR1M9IiRMREZMQUdTIgorCisg ICAgc2F2ZWRfTElCUz0iJExJQlMiCisKKworICAgIENGTEFHUz0iJENGTEFHUyAkUFRIUkVBRF9D RkxBR1MiCisKKyAgICBMREZMQUdTPSIkTERGTEFHUyAkUFRIUkVBRF9MREZMQUdTIgorCisgICAg TElCUz0iJExJQlMgJFBUSFJFQURfTElCUyIKKworICAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8 X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKyNpbmNs dWRlIDxwdGhyZWFkLmg+CitpbnQgbWFpbih2b2lkKSB7CisgIHB0aHJlYWRfYXRmb3JrKDAsMCww KTsKKyAgcHRocmVhZF9jcmVhdGUoMCwwLDAsMCk7Cit9CisKK19BQ0VPRgoraWYgYWNfZm5fY190 cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGF4X2N2X3B0aHJlYWRfZmxhZ3M9 ZmFpbGVkCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBc CisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKKworICAgIENGTEFHUz0i JHNhdmVkX0NGTEFHUyIKKworICAgIExERkxBR1M9IiRzYXZlZF9MREZMQUdTIgogCisgICAgTElC Uz0iJHNhdmVkX0xJQlMiCiAKLSRhc19lY2hvICIjZGVmaW5lIHJlYWxsb2MgcnBsX3JlYWxsb2Mi ID4+Y29uZmRlZnMuaAogCiBmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F Tk99OiByZXN1bHQ6ICRheF9jdl9wdGhyZWFkX2ZsYWdzIiA+JjUKKyRhc19lY2hvICIkYXhfY3Zf cHRocmVhZF9mbGFncyIgPiY2OyB9CisgICAgaWYgdGVzdCAieCRheF9jdl9wdGhyZWFkX2ZsYWdz IiA9IHhmYWlsZWQ7IHRoZW4KKyAgICAgICAgYXNfZm5fZXJyb3IgJD8gIi1wdGhyZWFkIGRvZXMg bm90IHdvcmsiICIkTElORU5PIiA1CisgICAgZmkKKworICAgIFBUSFJFQURfQ0ZMQUdTPSIkYXhf Y3ZfcHRocmVhZF9mbGFncyIKKyAgICBQVEhSRUFEX0xERkxBR1M9IiRheF9jdl9wdGhyZWFkX2Zs YWdzIgorICAgIFBUSFJFQURfTElCUz0iIgorCiAKIAoteyAkYXNfZWNobyAiJGFzX21lOiR7YXNf bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuIiA+JjUKLSRhc19l Y2hvX24gImNoZWNraW5nIGZvciB3b3JraW5nIHN0cm5sZW4uLi4gIiA+JjY7IH0KLWlmIHRlc3Qg IiR7YWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNf ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxv YyBpbiAtbHlhamwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4g LWx5YWpsLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2Mr c2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgogZWxzZQot ICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNf c3Rybmxlbl93b3JraW5nPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv bmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx5 YWpsICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQK IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KLSRhY19pbmNsdWRlc19kZWZhdWx0CisKKy8qIE92ZXJy aWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNl IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisg ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgeWFq bF9hbGxvYyAoKTsKIGludAogbWFpbiAoKQogewotCi0jZGVmaW5lIFMgImZvb2JhciIKLSNkZWZp bmUgU19MRU4gKHNpemVvZiBTIC0gMSkKLQotICAvKiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRp b24gaXMgYnVnZ3k6IHRoYXQgb2YgQUlYIDQuMyB3b3VsZAotICAgICBnaXZlIHN0cm5sZW4gKFMs IDEpID09IDMuICAqLwotCi0gIGludCBpOwotICBmb3IgKGkgPSAwOyBpIDwgU19MRU4gKyAxOyAr K2kpCi0gICAgewotICAgICAgaW50IGV4cGVjdGVkID0gaSA8PSBTX0xFTiA/IGkgOiBTX0xFTjsK LSAgICAgIGlmIChzdHJubGVuIChTLCBpKSAhPSBleHBlY3RlZCkKLQlyZXR1cm4gMTsKLSAgICB9 Ci0gIHJldHVybiAwOwotCityZXR1cm4geWFqbF9hbGxvYyAoKTsKICAgOwogICByZXR1cm4gMDsK IH0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2 X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllcworaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7 IHRoZW4gOgorICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPXllcwogZWxzZQotICBhY19jdl9m dW5jX3N0cm5sZW5fd29ya2luZz1ubworICBhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jPW5vCiBm aQotcm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25m dGVzdCRhY19leGVleHQgXAotICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29u ZnRlc3QuJGFjX2V4dAorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4 dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2No ZWNrX2xpYl9zYXZlX0xJQlMKIGZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ TkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNQorJGFzX2VjaG8g IiRhY19jdl9saWJfeWFqbF95YWpsX2FsbG9jIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGli X3lhamxfeWFqbF9hbGxvYyIgPSB4IiJ5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8 X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKIAotZmkKLXsgJGFzX2VjaG8g IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJubGVu X3dvcmtpbmciID4mNQotJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyIgPiY2 OyB9Ci10ZXN0ICRhY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZyA9IG5vICYmIGNhc2UgIiAkTElC T0JKUyAiIGluCi0gICoiIHN0cm5sZW4uJGFjX29iamV4dCAiKiApIDs7Ci0gICopIExJQk9CSlM9 IiRMSUJPQkpTIHN0cm5sZW4uJGFjX29iamV4dCIKLSA7OwotZXNhYworICBMSUJTPSItbHlhamwg JExJQlMiCiAKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwiICIk TElORU5PIiA1CitmaQogCi17ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306 IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIgPiY1Ci0kYXNfZWNob19uICJjaGVja2luZyBm b3Igd29ya2luZyBzdHJ0b2QuLi4gIiA+JjY7IH0KLWlmIHRlc3QgIiR7YWNfY3ZfZnVuY19zdHJ0 b2Qrc2V0fSIgPSBzZXQ7IHRoZW4gOgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM SU5FTk99OiBjaGVja2luZyBmb3IgZGVmbGF0ZUNvcHkgaW4gLWx6IiA+JjUKKyRhc19lY2hvX24g ImNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHouLi4gIiA+JjY7IH0KK2lmIHRlc3QgIiR7 YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkrc2V0fSIgPSBzZXQ7IHRoZW4gOgogICAkYXNfZWNob19u ICIoY2FjaGVkKSAiID4mNgogZWxzZQotICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHll czsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPW5vCi1lbHNlCi0gIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0k TElCUworTElCUz0iLWx6ICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0 ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIAotJGFjX2luY2x1ZGVzX2RlZmF1 bHQKLSNpZm5kZWYgc3RydG9kCi1kb3VibGUgc3RydG9kICgpOworLyogT3ZlcnJpZGUgYW55IEdD QyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNh dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4g YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisj aWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKICNlbmRpZgorY2hhciBkZWZsYXRlQ29weSAo KTsKIGludAotbWFpbigpCittYWluICgpCiB7Ci0gIHsKLSAgICAvKiBTb21lIHZlcnNpb25zIG9m IExpbnV4IHN0cnRvZCBtaXMtcGFyc2Ugc3RyaW5ncyB3aXRoIGxlYWRpbmcgJysnLiAgKi8KLSAg ICBjaGFyICpzdHJpbmcgPSAiICs2OSI7Ci0gICAgY2hhciAqdGVybTsKLSAgICBkb3VibGUgdmFs dWU7Ci0gICAgdmFsdWUgPSBzdHJ0b2QgKHN0cmluZywgJnRlcm0pOwotICAgIGlmICh2YWx1ZSAh PSA2OSB8fCB0ZXJtICE9IChzdHJpbmcgKyA0KSkKLSAgICAgIHJldHVybiAxOwotICB9Ci0KLSAg ewotICAgIC8qIFVuZGVyIFNvbGFyaXMgMi40LCBzdHJ0b2QgcmV0dXJucyB0aGUgd3JvbmcgdmFs dWUgZm9yIHRoZQotICAgICAgIHRlcm1pbmF0aW5nIGNoYXJhY3RlciB1bmRlciBzb21lIGNvbmRp dGlvbnMuICAqLwotICAgIGNoYXIgKnN0cmluZyA9ICJOYU4iOwotICAgIGNoYXIgKnRlcm07Ci0g ICAgc3RydG9kIChzdHJpbmcsICZ0ZXJtKTsKLSAgICBpZiAodGVybSAhPSBzdHJpbmcgJiYgKih0 ZXJtIC0gMSkgPT0gMCkKLSAgICAgIHJldHVybiAxOwotICB9CityZXR1cm4gZGVmbGF0ZUNvcHkg KCk7CisgIDsKICAgcmV0dXJuIDA7CiB9Ci0KIF9BQ0VPRgotaWYgYWNfZm5fY190cnlfcnVuICIk TElORU5PIjsgdGhlbiA6Ci0gIGFjX2N2X2Z1bmNfc3RydG9kPXllcworaWYgYWNfZm5fY190cnlf bGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRlQ29weT15ZXMKIGVs c2UKLSAgYWNfY3ZfZnVuY19zdHJ0b2Q9bm8KLWZpCi1ybSAtZiBjb3JlICouY29yZSBjb3JlLmNv bmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4ZWV4dCBcCi0gIGNvbmZ0ZXN0 LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNfZXh0CisgIGFjX2N2X2xpYl96 X2RlZmxhdGVDb3B5PW5vCiBmaQotCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4k YWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElC Uz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19zdHJ0b2QiID4mNQotJGFzX2VjaG8g IiRhY19jdl9mdW5jX3N0cnRvZCIgPiY2OyB9Ci1pZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9 IG5vOyB0aGVuCi0gIGNhc2UgIiAkTElCT0JKUyAiIGluCi0gICoiIHN0cnRvZC4kYWNfb2JqZXh0 ICIqICkgOzsKLSAgKikgTElCT0JKUz0iJExJQk9CSlMgc3RydG9kLiRhY19vYmpleHQiCi0gOzsK LWVzYWMKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk YWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZs YXRlQ29weSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHgi InllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9M SUJaIDEKK19BQ0VPRgogCi1hY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICJwb3ciICJhY19j dl9mdW5jX3BvdyIKLWlmIHRlc3QgIngkYWNfY3ZfZnVuY19wb3ciID0geCIieWVzOyB0aGVuIDoK KyAgTElCUz0iLWx6ICRMSUJTIgogCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBub3Qg ZmluZCB6bGliIiAiJExJTkVOTyIgNQogZmkKIAotaWYgdGVzdCAkYWNfY3ZfZnVuY19wb3cgPSBu bzsgdGhlbgotICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNr aW5nIGZvciBwb3cgaW4gLWxtIiA+JjUKLSRhc19lY2hvX24gImNoZWNraW5nIGZvciBwb3cgaW4g LWxtLi4uICIgPiY2OyB9Ci1pZiB0ZXN0ICIke2FjX2N2X2xpYl9tX3BvdytzZXR9IiA9IHNldDsg dGhlbiA6Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n IGZvciBsaWJpY29udl9vcGVuIGluIC1saWNvbnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg Zm9yIGxpYmljb252X29wZW4gaW4gLWxpY29udi4uLiAiID4mNjsgfQoraWYgdGVzdCAiJHthY19j dl9saWJfaWNvbnZfbGliaWNvbnZfb3BlbitzZXR9IiA9IHNldDsgdGhlbiA6CiAgICRhc19lY2hv X24gIihjYWNoZWQpICIgPiY2CiBlbHNlCiAgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMK LUxJQlM9Ii1sbSAgJExJQlMiCitMSUJTPSItbGljb252ICAkTElCUyIKIGNhdCBjb25mZGVmcy5o IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKIC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KIApA QCAtOTUyOCw1NSArNjU1Myw0NSBAQCBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz dC4kYWNfZXh0CiAjaWZkZWYgX19jcGx1c3BsdXMKIGV4dGVybiAiQyIKICNlbmRpZgotY2hhciBw b3cgKCk7CitjaGFyIGxpYmljb252X29wZW4gKCk7CiBpbnQKIG1haW4gKCkKIHsKLXJldHVybiBw b3cgKCk7CityZXR1cm4gbGliaWNvbnZfb3BlbiAoKTsKICAgOwogICByZXR1cm4gMDsKIH0KIF9B Q0VPRgogaWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgotICBhY19jdl9saWJf bV9wb3c9eWVzCisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXllcwogZWxzZQotICBh Y19jdl9saWJfbV9wb3c9bm8KKyAgYWNfY3ZfbGliX2ljb252X2xpYmljb252X29wZW49bm8KIGZp CiBybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKICAgICBjb25m dGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAogTElCUz0kYWNfY2hlY2tfbGliX3NhdmVf TElCUwogZmkKLXsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0 OiAkYWNfY3ZfbGliX21fcG93IiA+JjUKLSRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7 IH0KLWlmIHRlc3QgIngkYWNfY3ZfbGliX21fcG93IiA9IHgiInllczsgdGhlbiA6Ci0gIFBPV19M SUI9LWxtCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog JGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGli X2ljb252X2xpYmljb252X29wZW4iID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfaWNvbnZf bGliaWNvbnZfb3BlbiIgPSB4IiJ5ZXM7IHRoZW4gOgorICBsaWJpY29udj0ieSIKIGVsc2UKLSAg eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBjYW5ub3Qg ZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBvZiBwb3ciID4mNQotJGFzX2VjaG8g IiRhc19tZTogV0FSTklORzogY2Fubm90IGZpbmQgbGlicmFyeSBjb250YWluaW5nIGRlZmluaXRp b24gb2YgcG93IiA+JjI7fQotZmkKLQorICBsaWJpY29udj0ibiIKIGZpCiAKLWZpCiAKLWZvciBh Y19mdW5jIGluICBcCi0gICAgICAgICAgICAgICAgYWxhcm0gYXRleGl0IGJ6ZXJvIGNsb2NrX2dl dHRpbWUgZHVwMiBmZGF0YXN5bmMgZnRydW5jYXRlIFwKLSAgICAgICAgICAgICAgICBnZXRjd2Qg Z2V0aG9zdGJ5bmFtZSBnZXRob3N0bmFtZSBnZXRwYWdlc2l6ZSBnZXR0aW1lb2ZkYXkgXAotICAg ICAgICAgICAgICAgIGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBtZW1tb3Zl IG1lbXNldCBta2RpciBcCi0gICAgICAgICAgICAgICAgbWtmaWZvIG11bm1hcCBwYXRoY29uZiBy ZWFscGF0aCByZWdjb21wIHJtZGlyIHNlbGVjdCBzZXRlbnYgXAotICAgICAgICAgICAgICAgIHNv Y2tldCBzdHJjYXNlY21wIHN0cmNociBzdHJjc3BuIHN0cmR1cCBzdHJlcnJvciBzdHJuZHVwIFwK LSAgICAgICAgICAgICAgICBzdHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3Ry dG91bCBzdHJ0b3VsbCB0enNldCBcCi0gICAgICAgICAgICAgICAgdW5hbWUgXAogCisjIENoZWNr cyBmb3IgaGVhZGVyIGZpbGVzLgorZm9yIGFjX2hlYWRlciBpbiB5YWpsL3lhamxfdmVyc2lvbi5o CiBkbyA6Ci0gIGFzX2FjX3Zhcj1gJGFzX2VjaG8gImFjX2N2X2Z1bmNfJGFjX2Z1bmMiIHwgJGFz X3RyX3NoYAotYWNfZm5fY19jaGVja19mdW5jICIkTElORU5PIiAiJGFjX2Z1bmMiICIkYXNfYWNf dmFyIgotaWYgZXZhbCB0ZXN0IFwieFwkIiRhc19hY192YXIiXCIgPSB4InllcyI7IHRoZW4gOgor ICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAieWFqbC95YWpsX3ZlcnNp b24uaCIgImFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiAiJGFjX2luY2x1ZGVzX2Rl ZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X2hlYWRlcl95YWpsX3lhamxfdmVyc2lvbl9oIiA9IHgi InllczsgdGhlbiA6CiAgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKLSNkZWZpbmUgYCRhc19l Y2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9jcHBgIDEKKyNkZWZpbmUgSEFWRV9ZQUpMX1lB SkxfVkVSU0lPTl9IIDEKIF9BQ0VPRgogCiBmaQorCiBkb25lCiAKIApkaWZmIC0tZ2l0IGEvdG9v bHMvY29uZmlndXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IDU3Yzg4N2QuLmRlYjg0 OGQgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUu YWMKQEAgLTE5LDkgKzE5LDYgQEAgcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQ UkVQRU5EX0xJQiwgXAogQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hl biBwb3NzaWJsZS5dKQogXSkKIAotQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCi1BQ19DQU5PTklD QUxfSE9TVAotCiAjIE00IE1hY3JvIGluY2x1ZGVzCiBtNF9pbmNsdWRlKFttNC9zYXZldmFyLm00 XSkKIG00X2luY2x1ZGUoW200L2ZlYXR1cmVzLm00XSkKQEAgLTc1LDkgKzcyLDcgQEAgQUNfQVJH X1ZBUihbQkNDXSwgW1BhdGggdG8gYmNjIHRvb2xdKQogQUNfQVJHX1ZBUihbSUFTTF0sIFtQYXRo IHRvIGlhc2wgdG9vbF0pCiAKICMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KLUFDX1BST0dfU0VECiBB Q19QUk9HX0NDCi1BQ19QUk9HX0xOX1MKIEFDX1BST0dfTUFLRV9TRVQKIEFDX1BST0dfSU5TVEFM TAogQUNfUEFUSF9QUk9HKFtCSVNPTl0sIFtiaXNvbl0pCkBAIC0xMzcsNyArMTMyLDYgQEAgQUNf U1VCU1QobGliZXh0MmZzKQogQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1 ZmZlcl0sIFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQogQUNfU1VCU1QobGliZ2Ny eXB0KQogQVhfQ0hFQ0tfUFRIUkVBRAotQUNfQ0hFQ0tfTElCKFtydF0sIFtjbG9ja19nZXR0aW1l XSkKIEFDX0NIRUNLX0xJQihbeWFqbF0sIFt5YWpsX2FsbG9jXSwgW10sCiAgICAgW0FDX01TR19F UlJPUihbQ291bGQgbm90IGZpbmQgeWFqbF0pXSkKIEFDX0NIRUNLX0xJQihbel0sIFtkZWZsYXRl Q29weV0sIFtdLCBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB6bGliXSldKQpAQCAtMTQ1 LDU4ICsxMzksNiBAQCBBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmljb252X29wZW5dLCBbbGli aWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCiBBQ19TVUJTVChsaWJpY29udikKIAogIyBDaGVj a3MgZm9yIGhlYWRlciBmaWxlcy4KLUFDX0ZVTkNfQUxMT0NBCi1BQ19DSEVDS19IRUFERVJTKFsg XAotICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRs LmggbGltaXRzLmggbWFsbG9jLmggXAotICAgICAgICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9p bi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKLSAgICAgICAgICAgICAg ICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0u aCBcCi0gICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUu aCBzeXNsb2cuaCB0ZXJtaW9zLmggXAotICAgICAgICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFq bF92ZXJzaW9uLmggXAotICAgICAgICAgICAgICAgIF0pCi0KLSMgQ2hlY2tzIGZvciB0eXBlZGVm cywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGljcy4KLUFDX0hFQURFUl9T VERCT09MCi1BQ19UWVBFX1VJRF9UCi1BQ19DX0lOTElORQotQUNfVFlQRV9JTlQxNl9UCi1BQ19U WVBFX0lOVDMyX1QKLUFDX1RZUEVfSU5UNjRfVAotQUNfVFlQRV9JTlQ4X1QKLUFDX1RZUEVfTU9E RV9UCi1BQ19UWVBFX09GRl9UCi1BQ19UWVBFX1BJRF9UCi1BQ19DX1JFU1RSSUNUCi1BQ19UWVBF X1NJWkVfVAotQUNfVFlQRV9TU0laRV9UCi1BQ19DSEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5z dF9ibGtzaXplXSkKLUFDX1NUUlVDVF9TVF9CTE9DS1MKLUFDX0NIRUNLX01FTUJFUlMoW3N0cnVj dCBzdGF0LnN0X3JkZXZdKQotQUNfVFlQRV9VSU5UMTZfVAotQUNfVFlQRV9VSU5UMzJfVAotQUNf VFlQRV9VSU5UNjRfVAotQUNfVFlQRV9VSU5UOF9UCi1BQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90 XSkKLQotIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgotQUNfRlVOQ19FUlJPUl9BVF9M SU5FCi1BQ19GVU5DX0ZPUksKLUFDX0ZVTkNfRlNFRUtPCi1BQ19GVU5DX0xTVEFUX0ZPTExPV1Nf U0xBU0hFRF9TWU1MSU5LCi1BQ19IRUFERVJfTUFKT1IKLUFDX0ZVTkNfTUFMTE9DCi1BQ19GVU5D X01LVElNRQotQUNfRlVOQ19NTUFQCi1BQ19GVU5DX1JFQUxMT0MKLUFDX0ZVTkNfU1RSTkxFTgot QUNfRlVOQ19TVFJUT0QKLUFDX0NIRUNLX0ZVTkNTKFsgXAotICAgICAgICAgICAgICAgIGFsYXJt IGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCi0g ICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNp emUgZ2V0dGltZW9mZGF5IFwKLSAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2Nh bHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAotICAgICAgICAgICAgICAgIG1r ZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52 IFwKLSAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJk dXAgc3RyZXJyb3Igc3RybmR1cCBcCi0gICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0 cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAotICAgICAgICAgICAg ICAgIHVuYW1lIFwKLSAgICAgICAgICAgICAgICBdKQorQUNfQ0hFQ0tfSEVBREVSUyhbeWFqbC95 YWpsX3ZlcnNpb24uaF0pCiAKIEFDX09VVFBVVCgpCi0tIAoxLjcuMi41CgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Fri May 11 18:04:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 18:04:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuCb-0002HC-5L; Fri, 11 May 2012 18:04:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuCZ-0002Gn-5j for xen-devel@lists.xensource.com; Fri, 11 May 2012 18:04:27 +0000 Received: from [85.158.138.51:40988] by server-8.bemta-3.messagelabs.com id A0/5C-24428-AA45DAF4; Fri, 11 May 2012 18:04:26 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336759464!17741172!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14245 invoked from network); 11 May 2012 18:04:25 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-7.tower-174.messagelabs.com with SMTP; 11 May 2012 18:04:25 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 11:04:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141975764" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 11:04:24 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 11:04:24 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 02:04:22 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAGHQueAADaqsA== Date: Fri, 11 May 2012 18:04:21 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> In-Reply-To: <20120511142758.GA29677@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: >> Liu, Jinsong wrote: >>> Just notice your reply (so quick :) >>> >>> Agree and will update later, except 1 concern below. >>> >>> Konrad Rzeszutek Wilk wrote: >>>>> >>>>> Hmm, it's good if it's convenient to do it automatically via >>>>> dev->release. However, dev container (pcpu) would be free at some >>>>> other error cases, so I prefer do it 'manually'. >>>> >>>> You could also call pcpu_release(..) to do it manually. >>>> >>> >>> that means kfree(pcpu) would be done twice at some error cases, do >>> you think it really good? >>> >> >> Ping. >> >> I think error recovery should be kept inside error logic level >> itself, if try to recover upper level error would bring trouble. >> >> In our example, there are 2 logic levels: >> pcpu level (as container), and dev level (subfield used for sys) > > So you need to untangle free_pcpu from doing both. Meaning one does > the SysFS and the other deals with free-ing the structure and > removing itself from the list. > free_cpu is very samll, just consist of the 2 parts your said: * pcpu_sys_remove() deal with sysfs * list_del/kfree(pcpu) deal with pcpu > >> dev->release should only recover error occurred at dev/sys level, >> and the pcpu error should be recovered at pcpu level. >> >> If dev->release try to recover its container pcpu level error, like >> list_del/kfree(pcpu), it would make confusing. i.e., considering >> pcpu_sys_create(), 2 error cases: device_register fail, and >> device_create_file fail --> how can the caller decide kfree(pcpu) or >> not? > > Then you should free it manually. But you can do this by a wrapper > function: > > __pcpu_release(..) { > .. > /* Does the removing itself from the list and kfree the pcpu */ > } > pcpu_release(..) { > struct pcpcu *p= container_of(..) > __pcpu_release(p); > } > > dev->release = &pcpu_release; > Too weird way. If we want to release dev itself it's good to use dev->release, but for pcpu I doubt it. (consider the example I gave --> why we create issue (it maybe solved in weird method I agree), just for using dev->release?) In kernel many dev->release keep NULL. An example of using dev->release is cpu/mcheck/mce.c --> mce_device_release(), it *just* deal dev itself. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 18:04:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 18:04:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuCb-0002HC-5L; Fri, 11 May 2012 18:04:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuCZ-0002Gn-5j for xen-devel@lists.xensource.com; Fri, 11 May 2012 18:04:27 +0000 Received: from [85.158.138.51:40988] by server-8.bemta-3.messagelabs.com id A0/5C-24428-AA45DAF4; Fri, 11 May 2012 18:04:26 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1336759464!17741172!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzMTk3\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14245 invoked from network); 11 May 2012 18:04:25 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-7.tower-174.messagelabs.com with SMTP; 11 May 2012 18:04:25 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 11:04:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="141975764" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 11:04:24 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 11:04:24 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 02:04:22 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAGHQueAADaqsA== Date: Fri, 11 May 2012 18:04:21 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> In-Reply-To: <20120511142758.GA29677@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: >> Liu, Jinsong wrote: >>> Just notice your reply (so quick :) >>> >>> Agree and will update later, except 1 concern below. >>> >>> Konrad Rzeszutek Wilk wrote: >>>>> >>>>> Hmm, it's good if it's convenient to do it automatically via >>>>> dev->release. However, dev container (pcpu) would be free at some >>>>> other error cases, so I prefer do it 'manually'. >>>> >>>> You could also call pcpu_release(..) to do it manually. >>>> >>> >>> that means kfree(pcpu) would be done twice at some error cases, do >>> you think it really good? >>> >> >> Ping. >> >> I think error recovery should be kept inside error logic level >> itself, if try to recover upper level error would bring trouble. >> >> In our example, there are 2 logic levels: >> pcpu level (as container), and dev level (subfield used for sys) > > So you need to untangle free_pcpu from doing both. Meaning one does > the SysFS and the other deals with free-ing the structure and > removing itself from the list. > free_cpu is very samll, just consist of the 2 parts your said: * pcpu_sys_remove() deal with sysfs * list_del/kfree(pcpu) deal with pcpu > >> dev->release should only recover error occurred at dev/sys level, >> and the pcpu error should be recovered at pcpu level. >> >> If dev->release try to recover its container pcpu level error, like >> list_del/kfree(pcpu), it would make confusing. i.e., considering >> pcpu_sys_create(), 2 error cases: device_register fail, and >> device_create_file fail --> how can the caller decide kfree(pcpu) or >> not? > > Then you should free it manually. But you can do this by a wrapper > function: > > __pcpu_release(..) { > .. > /* Does the removing itself from the list and kfree the pcpu */ > } > pcpu_release(..) { > struct pcpcu *p= container_of(..) > __pcpu_release(p); > } > > dev->release = &pcpu_release; > Too weird way. If we want to release dev itself it's good to use dev->release, but for pcpu I doubt it. (consider the example I gave --> why we create issue (it maybe solved in weird method I agree), just for using dev->release?) In kernel many dev->release keep NULL. An example of using dev->release is cpu/mcheck/mce.c --> mce_device_release(), it *just* deal dev itself. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 18:36:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 18:36:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuhU-00038l-2P; Fri, 11 May 2012 18:36:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuhS-00038f-9P for xen-devel@lists.xensource.com; Fri, 11 May 2012 18:36:22 +0000 Received: from [85.158.143.35:42857] by server-1.bemta-4.messagelabs.com id D6/6E-20925-52C5DAF4; Fri, 11 May 2012 18:36:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336761379!13739740!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32690 invoked from network); 11 May 2012 18:36:20 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 18:36:20 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BIaHST009370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 18:36:18 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 q4BIaG9M016047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 18:36:17 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 q4BIaGp2026911; Fri, 11 May 2012 13:36:16 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 11:36:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 999C740359; Fri, 11 May 2012 14:30:12 -0400 (EDT) Date: Fri, 11 May 2012 14:30:12 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120511183012.GB21486@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done I just did this with 3.2.16 and didn't experience this. Can you try 3.2.16 pls? I used the attached .config --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.2.16 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_KTIME_SCALAR=y CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_FHANDLE is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="early-devs" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_INITRAMFS_COMPRESSION_NONE is not set CONFIG_INITRAMFS_COMPRESSION_GZIP=y # CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set # CONFIG_INITRAMFS_COMPRESSION_LZMA is not set # CONFIG_INITRAMFS_COMPRESSION_XZ is not set # CONFIG_INITRAMFS_COMPRESSION_LZO is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBDAF=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set # CONFIG_INLINE_READ_UNLOCK is not set # CONFIG_INLINE_READ_UNLOCK_BH is not set # CONFIG_INLINE_READ_UNLOCK_IRQ is not set # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set # CONFIG_INLINE_WRITE_UNLOCK is not set # CONFIG_INLINE_WRITE_UNLOCK_BH is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_BIGSMP=y # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y # CONFIG_X86_32_IRIS is not set CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_LGUEST_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MELAN is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_X86_GENERIC=y CONFIG_X86_INTERNODE_CACHE_SHIFT=7 CONFIG_X86_CMPXCHG=y CONFIG_CMPXCHG_LOCAL=y CONFIG_CMPXCHG_DOUBLE=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y # CONFIG_X86_PPRO_FENCE is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=5 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_CYRIX_32=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_CPU_SUP_TRANSMETA_32=y CONFIG_CPU_SUP_UMC_32=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_NR_CPUS=256 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_ANCIENT_MCE=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=y CONFIG_X86_THERMAL_VECTOR=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=3 CONFIG_HAVE_ARCH_BOOTMEM=y CONFIG_HAVE_ARCH_ALLOC_REMAP=y CONFIG_ARCH_HAVE_MEMORY_PRESENT=y CONFIG_NEED_NODE_MEMMAP_SIZE=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ILLEGAL_POINTER_VALUE=0 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_STATIC=y CONFIG_HAVE_MEMBLOCK=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y # CONFIG_MEMORY_FAILURE is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set CONFIG_CLEANCACHE=y CONFIG_HIGHPTE=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW=64 # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # CONFIG_KEXEC_JUMP is not set CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_X86_NEED_RELOCS=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y # CONFIG_PM_RUNTIME is not set CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_PM_ADVANCED_DEBUG is not set # CONFIG_PM_TEST_SUSPEND is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_PROCFS_POWER is not set # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_NUMA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_APEI is not set # CONFIG_SFI is not set # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # # CONFIG_X86_PCC_CPUFREQ is not set CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set CONFIG_X86_POWERNOW_K8=m # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set CONFIG_X86_P4_CLOCKMOD=m # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_INTEL_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y # CONFIG_PCIEAER_INJECT is not set CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y # CONFIG_PCI_PRI is not set # CONFIG_PCI_PASID is not set CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_ALIX is not set CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_RAPIDIO is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_HAVE_ATOMIC_IOMAP=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE_DEMUX is not set CONFIG_IP_MROUTE=y # CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_LRO=y # CONFIG_INET_DIAG is not set CONFIG_TCP_CONG_ADVANCED=y # CONFIG_TCP_CONG_BIC is not set CONFIG_TCP_CONG_CUBIC=y # CONFIG_TCP_CONG_WESTWOOD is not set # CONFIG_TCP_CONG_HTCP is not set # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # CONFIG_TCP_CONG_LP is not set # CONFIG_TCP_CONG_VENO is not set # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=y # CONFIG_IPV6_PRIVACY is not set # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=y CONFIG_INET6_ESP=y # CONFIG_INET6_IPCOMP is not set # CONFIG_IPV6_MIP6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_MROUTE is not set CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_NETFILTER_ADVANCED is not set # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_IRC=y # CONFIG_NF_CONNTRACK_NETBIOS_NS is not set CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CT_NETLINK=y CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_STATE=y # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y # CONFIG_NF_NAT_TFTP is not set # CONFIG_NF_NAT_AMANDA is not set # CONFIG_NF_NAT_PPTP is not set # CONFIG_NF_NAT_H323 is not set CONFIG_NF_NAT_SIP=y CONFIG_IP_NF_MANGLE=y # CONFIG_IP_NF_RAW is not set # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=y CONFIG_NF_CONNTRACK_IPV6=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y CONFIG_IP6_NF_MANGLE=y # CONFIG_IP6_NF_RAW is not set # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_L2TP is not set CONFIG_STP=y CONFIG_BRIDGE=y CONFIG_BRIDGE_IGMP_SNOOPING=y # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set # CONFIG_NET_SCH_HTB is not set # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set # CONFIG_NET_SCH_MULTIQ is not set # CONFIG_NET_SCH_RED is not set # CONFIG_NET_SCH_SFB is not set # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DRR is not set # CONFIG_NET_SCH_MQPRIO is not set # CONFIG_NET_SCH_CHOKE is not set # CONFIG_NET_SCH_QFQ is not set # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set # CONFIG_NET_CLS_FW is not set # CONFIG_NET_CLS_U32 is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set # CONFIG_NET_CLS_CGROUP is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 # CONFIG_NET_EMATCH_CMP is not set # CONFIG_NET_EMATCH_NBYTE is not set # CONFIG_NET_EMATCH_U32 is not set # CONFIG_NET_EMATCH_META is not set # CONFIG_NET_EMATCH_TEXT is not set CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set # CONFIG_NET_ACT_GACT is not set # CONFIG_NET_ACT_MIRRED is not set # CONFIG_NET_ACT_IPT is not set # CONFIG_NET_ACT_NAT is not set # CONFIG_NET_ACT_PEDIT is not set # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_ACT_CSUM is not set CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set # CONFIG_NET_DROP_MONITOR is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y # CONFIG_NET_9P is not set # CONFIG_CAIF is not set # CONFIG_CEPH_LIB is not set # CONFIG_NFC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_DEVRES=y CONFIG_SYS_HYPERVISOR=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set # CONFIG_BLK_DEV_RBD is not set # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=m CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m # CONFIG_SCSI_CXGB3_ISCSI is not set # CONFIG_SCSI_CXGB4_ISCSI is not set # CONFIG_SCSI_BNX2_ISCSI is not set # CONFIG_SCSI_BNX2X_FCOE is not set # CONFIG_BE2ISCSI is not set CONFIG_BLK_DEV_3W_XXXX_RAID=m # CONFIG_SCSI_HPSA is not set CONFIG_SCSI_3W_9XXX=m # CONFIG_SCSI_3W_SAS is not set CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 CONFIG_AIC79XX_DEBUG_ENABLE=y CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set # CONFIG_SCSI_MVSAS_TASKLET is not set # CONFIG_SCSI_MVUMI is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_ARCMSR=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m CONFIG_SCSI_FLASHPOINT=y # CONFIG_VMWARE_PVSCSI is not set CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m # CONFIG_FCOE_FNIC is not set CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=m # CONFIG_SCSI_IPR_TRACE is not set # CONFIG_SCSI_IPR_DUMP is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m # CONFIG_SCSI_QLA_ISCSI is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_NSP32=m CONFIG_SCSI_DEBUG=m # CONFIG_SCSI_PMCRAID is not set # CONFIG_SCSI_PM8001 is not set CONFIG_SCSI_SRP=m # CONFIG_SCSI_BFA_FC is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m # CONFIG_SATA_AHCI_PLATFORM is not set CONFIG_SATA_INIC162X=m # CONFIG_SATA_ACARD_AHCI is not set CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARASAN_CF is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_ATP867X is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CS5536 is not set # CONFIG_PATA_CYPRESS is not set CONFIG_PATA_EFAR=m # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set CONFIG_PATA_MARVELL=m # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC2027X is not set CONFIG_PATA_PDC_OLD=m CONFIG_PATA_RADISYS=m # CONFIG_PATA_RDC is not set # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SCH=m # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_SIL680 is not set CONFIG_PATA_SIS=m # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_VIA is not set CONFIG_PATA_WINBOND=m # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # # CONFIG_PATA_ACPI is not set CONFIG_ATA_GENERIC=m CONFIG_PATA_LEGACY=m CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MULTICORE_RAID456 is not set CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m # CONFIG_DM_THIN_PROVISIONING is not set CONFIG_DM_MIRROR=m # CONFIG_DM_RAID is not set # CONFIG_DM_LOG_USERSPACE is not set CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_MULTIPATH_QL is not set # CONFIG_DM_MULTIPATH_ST is not set CONFIG_DM_DELAY=m # CONFIG_DM_UEVENT is not set # CONFIG_DM_FLAKEY is not set CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m CONFIG_TCM_FC=m CONFIG_ISCSI_TARGET=m CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_FIREWIRE_NOSY is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_NET_CORE=y # CONFIG_BONDING is not set # CONFIG_DUMMY is not set # CONFIG_EQUALIZER is not set # CONFIG_NET_FC is not set CONFIG_MII=m # CONFIG_IFB is not set # CONFIG_MACVLAN is not set CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_TUN=y # CONFIG_VETH is not set CONFIG_VIRTIO_NET=m CONFIG_SUNGEM_PHY=m # CONFIG_ARCNET is not set # # CAIF transport drivers # CONFIG_ETHERNET=y CONFIG_MDIO=m CONFIG_NET_VENDOR_3COM=y # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_3C589 is not set CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_VENDOR_ADAPTEC=y # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_NET_VENDOR_ALTEON=y # CONFIG_ACENIC is not set CONFIG_NET_VENDOR_AMD=y # CONFIG_AMD8111_ETH is not set # CONFIG_PCNET32 is not set # CONFIG_PCMCIA_NMCLAN is not set CONFIG_NET_VENDOR_ATHEROS=y # CONFIG_ATL2 is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set CONFIG_ATL1C=m CONFIG_NET_VENDOR_BROADCOM=y # CONFIG_B44 is not set CONFIG_BNX2=m # CONFIG_CNIC is not set CONFIG_TIGON3=y CONFIG_BNX2X=m CONFIG_NET_VENDOR_BROCADE=y # CONFIG_BNA is not set CONFIG_NET_VENDOR_CHELSIO=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y # CONFIG_ENIC is not set # CONFIG_DNET is not set CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_PCMCIA_XIRCOM is not set CONFIG_NET_VENDOR_DLINK=y # CONFIG_DL2K is not set # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y # CONFIG_BE2NET is not set CONFIG_NET_VENDOR_EXAR=y # CONFIG_S2IO is not set # CONFIG_VXGE is not set CONFIG_NET_VENDOR_FUJITSU=y # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IGB=m CONFIG_IGBVF=m # CONFIG_IXGB is not set CONFIG_IXGBE=m # CONFIG_IXGBEVF is not set CONFIG_NET_VENDOR_I825XX=y # CONFIG_ZNET is not set # CONFIG_IP1000 is not set # CONFIG_JME is not set CONFIG_NET_VENDOR_MARVELL=y CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set # CONFIG_SKGE_GENESIS is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MELLANOX=y # CONFIG_MLX4_EN is not set # CONFIG_MLX4_CORE is not set CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8851_MLL is not set # CONFIG_KSZ884X_PCI is not set CONFIG_NET_VENDOR_MYRI=y # CONFIG_MYRI10GE is not set # CONFIG_FEALNX is not set CONFIG_NET_VENDOR_NATSEMI=y # CONFIG_NATSEMI is not set # CONFIG_NS83820 is not set CONFIG_NET_VENDOR_8390=y # CONFIG_PCMCIA_AXNET is not set CONFIG_NE2K_PCI=m # CONFIG_PCMCIA_PCNET is not set CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=y CONFIG_NET_VENDOR_OKI=y # CONFIG_PCH_GBE is not set # CONFIG_ETHOC is not set CONFIG_NET_PACKET_ENGINE=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y # CONFIG_QLA3XXX is not set # CONFIG_QLCNIC is not set # CONFIG_QLGE is not set # CONFIG_NETXEN_NIC is not set CONFIG_NET_VENDOR_REALTEK=y # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_R8169=m CONFIG_NET_VENDOR_RDC=y # CONFIG_R6040 is not set CONFIG_NET_VENDOR_SEEQ=y # CONFIG_SEEQ8005 is not set CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=m CONFIG_NET_VENDOR_SIS=y # CONFIG_SIS900 is not set # CONFIG_SIS190 is not set # CONFIG_SFC is not set CONFIG_NET_VENDOR_SMSC=y # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_EPIC100 is not set # CONFIG_SMSC9420 is not set CONFIG_NET_VENDOR_STMICRO=y # CONFIG_STMMAC_ETH is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m # CONFIG_NIU is not set CONFIG_NET_VENDOR_TEHUTI=y # CONFIG_TEHUTI is not set CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=m CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_VIA_VELOCITY=m CONFIG_NET_VENDOR_XIRCOM=y # CONFIG_PCMCIA_XIRC2PS is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_STE10XP is not set # CONFIG_LSI_ET1011C_PHY is not set # CONFIG_MICREL_PHY is not set CONFIG_FIXED_PHY=y # CONFIG_MDIO_BITBANG is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set CONFIG_TR=y # CONFIG_PCMCIA_IBMTR is not set # CONFIG_IBMOL is not set # CONFIG_IBMLS is not set CONFIG_3C359=m # CONFIG_TMS380TR is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_HSO is not set # CONFIG_USB_IPHETH is not set # CONFIG_WLAN is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=y # CONFIG_VMXNET3 is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_POLLDEV is not set CONFIG_INPUT_SPARSEKMAP=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_AS5011 is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_USB_ACECAD is not set # CONFIG_TABLET_USB_AIPTEK is not set # CONFIG_TABLET_USB_GTCO is not set # CONFIG_TABLET_USB_HANWANG is not set # CONFIG_TABLET_USB_KBTAB is not set # CONFIG_TABLET_USB_WACOM is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set # CONFIG_INPUT_PCSPKR is not set # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_UINPUT is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MFD_HSU is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y # CONFIG_SERIAL_JSM is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_PCH_UART is not set # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_VIRTIO_CONSOLE=y # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_MMAP is not set # CONFIG_HANGCHECK_TIMER is not set CONFIG_TCG_TPM=y CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y # CONFIG_RAMOOPS is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y # CONFIG_I2C_ISCH is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_DESIGNWARE_PCI is not set # CONFIG_I2C_INTEL_MID is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # CONFIG_I2C_EG20T is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_STUB is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_SPI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # # Enable Device Drivers -> PPS to see the PTP clock options. # CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_BQ20Z75 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_MAX8903 is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_K10TEMP is not set # CONFIG_SENSORS_FAM15H_POWER is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SCH56XX_COMMON is not set # CONFIG_SENSORS_SCH5627 is not set # CONFIG_SENSORS_SCH5636 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_VIA_CPUTEMP is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_APPLESMC is not set # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set # CONFIG_SENSORS_ATK0110 is not set CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TPS6105X is not set # CONFIG_TPS6507X is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set # CONFIG_LPC_SCH is not set # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_ALI=y CONFIG_AGP_ATI=y CONFIG_AGP_AMD=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_NVIDIA=y CONFIG_AGP_SIS=y CONFIG_AGP_SWORKS=y CONFIG_AGP_VIA=y CONFIG_AGP_EFFICEON=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m # CONFIG_DRM_VMWGFX is not set # CONFIG_STUB_POULSBO is not set # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=y # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_VESA is not set CONFIG_FB_EFI=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_VIRTUAL is not set CONFIG_XEN_FBDEV_FRONTEND=m # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=m # CONFIG_HID_ACRUX is not set CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set CONFIG_HID_EZKEY=m # CONFIG_HID_HOLTEK is not set # CONFIG_HID_KEYTOUCH is not set CONFIG_HID_KYE=m # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set CONFIG_HID_GYRATION=m # CONFIG_HID_TWINHAN is not set CONFIG_HID_KENSINGTON=m # CONFIG_HID_LCPOWER is not set CONFIG_HID_LOGITECH=m CONFIG_HID_LOGITECH_DJ=m CONFIG_LOGITECH_FF=y # CONFIG_LOGIRUMBLEPAD2_FF is not set # CONFIG_LOGIG940_FF is not set CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m # CONFIG_HID_MULTITOUCH is not set CONFIG_HID_NTRIG=m # CONFIG_HID_ORTEK is not set CONFIG_HID_PANTHERLORD=m CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=m # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_QUANTA is not set # CONFIG_HID_ROCCAT is not set CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m # CONFIG_HID_SPEEDLINK is not set CONFIG_HID_SUNPLUS=m # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set CONFIG_HID_TOPSEED=m # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB_ARCH_HAS_XHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_DWC3 is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_XHCI_HCD is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # CONFIG_NOP_USB_XCEIV is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set # CONFIG_LEDS_CLEVO_MAIL is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_DELL_NETBOOKS is not set # CONFIG_LEDS_TRIGGERS is not set # # LED Triggers # # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=y # CONFIG_EDAC_MCE_INJ is not set # CONFIG_EDAC_MM_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y # CONFIG_RTC_HCTOSYS is not set # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_INTEL_MID_DMAC is not set # CONFIG_INTEL_IOATDMA is not set # CONFIG_TIMB_DMA is not set # CONFIG_PCH_DMA is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set CONFIG_VIRTIO=y CONFIG_VIRTIO_RING=y # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=y # CONFIG_VIRTIO_MMIO is not set # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=m CONFIG_XEN_BACKEND=y CONFIG_XENFS=m CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=y CONFIG_XEN_GRANT_DEV_ALLOC=y CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=y CONFIG_XEN_PCIDEV_BACKEND=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set # CONFIG_USBIP_CORE is not set # CONFIG_ECHO is not set # CONFIG_COMEDI is not set # CONFIG_ASUS_OLED is not set # CONFIG_RTS_PSTOR is not set # CONFIG_RTS5139 is not set # CONFIG_TRANZPORT is not set # CONFIG_POHMELFS is not set # CONFIG_IDE_PHISON is not set CONFIG_DRM_NOUVEAU=m # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set CONFIG_DRM_NOUVEAU_DEBUG=y # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_VME_BUS is not set # CONFIG_DX_SEP is not set # CONFIG_IIO is not set CONFIG_XVMALLOC=y CONFIG_ZRAM=y # CONFIG_ZRAM_DEBUG is not set CONFIG_ZCACHE=y # CONFIG_FB_SM7XX is not set # CONFIG_CRYSTALHD is not set # CONFIG_FB_XGI is not set # CONFIG_ACPI_QUICKSTART is not set # CONFIG_USB_ENESTORAGE is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_DRM_PSB is not set # CONFIG_STAGING_MEDIA is not set CONFIG_X86_PLATFORM_DEVICES=y # CONFIG_ACER_WMI is not set # CONFIG_ACERHDF is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_DELL_WMI is not set # CONFIG_DELL_WMI_AIO is not set # CONFIG_FUJITSU_LAPTOP is not set # CONFIG_TC1100_WMI is not set # CONFIG_HP_ACCEL is not set # CONFIG_HP_WMI is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_IDEAPAD_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_INTEL_MENLOW is not set CONFIG_EEEPC_LAPTOP=y # CONFIG_ASUS_WMI is not set CONFIG_ACPI_WMI=m # CONFIG_MSI_WMI is not set # CONFIG_ACPI_ASUS is not set # CONFIG_TOPSTAR_LAPTOP is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_TOSHIBA_BT_RFKILL is not set # CONFIG_ACPI_CMPC is not set # CONFIG_INTEL_IPS is not set # CONFIG_IBM_RTL is not set # CONFIG_XO15_EBOOK is not set # CONFIG_SAMSUNG_LAPTOP is not set CONFIG_MXM_WMI=m # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set # # Hardware Spinlock drivers # CONFIG_CLKSRC_I8253=y CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_IOMMU_SUPPORT=y # CONFIG_INTEL_IOMMU is not set # CONFIG_VIRT_DRIVERS is not set # CONFIG_HYPERV is not set # CONFIG_PM_DEVFREQ is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_DMI_SYSFS is not set CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_SIGMA is not set # CONFIG_GOOGLE_FIRMWARE is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_FS_XIP=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_XFS_FS=m # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=m CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_AUTOFS4_FS=y # CONFIG_FUSE_FS is not set CONFIG_GENERIC_ACL=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_ECRYPT_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_LOGFS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_PSTORE is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFS_USE_NEW_IDMAPPER is not set # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y # CONFIG_CEPH_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_KMEMLEAK is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_ATOMIC_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_REDUCED=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_LIST is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 CONFIG_RCU_CPU_STALL_VERBOSE=y # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_LKDTM is not set # CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set CONFIG_FAULT_INJECTION=y # CONFIG_FAILSLAB is not set # CONFIG_FAIL_PAGE_ALLOC is not set CONFIG_FAIL_MAKE_REQUEST=y # CONFIG_FAIL_IO_TIMEOUT is not set CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y # CONFIG_FUNCTION_TRACER is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_FTRACE_SYSCALLS is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_STACK_TRACER is not set CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set # CONFIG_RING_BUFFER_BENCHMARK is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_DYNAMIC_DEBUG is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_ASYNC_RAID6_TEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y # CONFIG_KGDB_TESTS is not set # CONFIG_KGDB_LOW_LEVEL_TRAP is not set # CONFIG_KGDB_KDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y # CONFIG_KMEMCHECK is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_X86_PTDUMP=y CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_NX_TEST=m CONFIG_DOUBLEFAULT=y # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set # # Security options # CONFIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_PATH is not set CONFIG_LSM_MMAP_MIN_ADDR=65534 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_IMA is not set # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=y # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_VMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m # CONFIG_CRYPTO_GHASH is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_586=y # CONFIG_CRYPTO_AES_NI_INTEL is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_586 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_586 is not set # # Compression # # CONFIG_CRYPTO_DEFLATE is not set CONFIG_CRYPTO_ZLIB=y # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_PADLOCK is not set # CONFIG_CRYPTO_DEV_GEODE is not set CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m # CONFIG_KVM_MMU_AUDIT is not set CONFIG_VHOST_NET=y # CONFIG_LGUEST is not set CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=y # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m # CONFIG_CRC8 is not set CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPU_RMAP=y CONFIG_NLATTR=y # CONFIG_AVERAGE is not set # CONFIG_CORDIC is not set --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --3MwIy2ne0vdjdPXF-- From xen-devel-bounces@lists.xen.org Fri May 11 18:36:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 18:36:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuhU-00038l-2P; Fri, 11 May 2012 18:36:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSuhS-00038f-9P for xen-devel@lists.xensource.com; Fri, 11 May 2012 18:36:22 +0000 Received: from [85.158.143.35:42857] by server-1.bemta-4.messagelabs.com id D6/6E-20925-52C5DAF4; Fri, 11 May 2012 18:36:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1336761379!13739740!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32690 invoked from network); 11 May 2012 18:36:20 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 18:36:20 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BIaHST009370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 18:36:18 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 q4BIaG9M016047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 18:36:17 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 q4BIaGp2026911; Fri, 11 May 2012 13:36:16 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 11:36:15 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 999C740359; Fri, 11 May 2012 14:30:12 -0400 (EDT) Date: Fri, 11 May 2012 14:30:12 -0400 From: Konrad Rzeszutek Wilk To: "Christopher S. Aker" Message-ID: <20120511183012.GB21486@phenom.dumpdata.com> References: <4FA7EBF6.6040204@theshore.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <4FA7EBF6.6040204@theshore.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: > Xen: 4.1.3-rc1-pre (xenbits @ 23285) > Dom0: 3.2.6 PAE and 3.3.4 PAE > > We seeing the below crash on 3.x dom0s. A simple lvcreate/lvremove > loop deployed to a few dozen boxes will hit it quite reliably within > a short time. This happens on both an older LVM userspace and > newest, and in production we have seen this hit on lvremove, > lvrename, and lvdelete. > > #!/bin/bash > while true; do > lvcreate -L 256M -n test1 vg1; lvremove -f vg1/test1 > done I just did this with 3.2.16 and didn't experience this. Can you try 3.2.16 pls? I used the attached .config --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.2.16 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_KTIME_SCALAR=y CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_FHANDLE is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="early-devs" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_INITRAMFS_COMPRESSION_NONE is not set CONFIG_INITRAMFS_COMPRESSION_GZIP=y # CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set # CONFIG_INITRAMFS_COMPRESSION_LZMA is not set # CONFIG_INITRAMFS_COMPRESSION_XZ is not set # CONFIG_INITRAMFS_COMPRESSION_LZO is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBDAF=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set # CONFIG_INLINE_READ_UNLOCK is not set # CONFIG_INLINE_READ_UNLOCK_BH is not set # CONFIG_INLINE_READ_UNLOCK_IRQ is not set # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set # CONFIG_INLINE_WRITE_UNLOCK is not set # CONFIG_INLINE_WRITE_UNLOCK_BH is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_BIGSMP=y # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y # CONFIG_X86_32_IRIS is not set CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_LGUEST_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MELAN is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_X86_GENERIC=y CONFIG_X86_INTERNODE_CACHE_SHIFT=7 CONFIG_X86_CMPXCHG=y CONFIG_CMPXCHG_LOCAL=y CONFIG_CMPXCHG_DOUBLE=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y # CONFIG_X86_PPRO_FENCE is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=5 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_CYRIX_32=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_CPU_SUP_TRANSMETA_32=y CONFIG_CPU_SUP_UMC_32=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_NR_CPUS=256 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_ANCIENT_MCE=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=y CONFIG_X86_THERMAL_VECTOR=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=3 CONFIG_HAVE_ARCH_BOOTMEM=y CONFIG_HAVE_ARCH_ALLOC_REMAP=y CONFIG_ARCH_HAVE_MEMORY_PRESENT=y CONFIG_NEED_NODE_MEMMAP_SIZE=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ILLEGAL_POINTER_VALUE=0 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_STATIC=y CONFIG_HAVE_MEMBLOCK=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y # CONFIG_MEMORY_FAILURE is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set CONFIG_CLEANCACHE=y CONFIG_HIGHPTE=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW=64 # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # CONFIG_KEXEC_JUMP is not set CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y CONFIG_X86_NEED_RELOCS=y CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y # CONFIG_PM_RUNTIME is not set CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_PM_ADVANCED_DEBUG is not set # CONFIG_PM_TEST_SUSPEND is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_PROCFS_POWER is not set # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_NUMA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_APEI is not set # CONFIG_SFI is not set # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # # CONFIG_X86_PCC_CPUFREQ is not set CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set CONFIG_X86_POWERNOW_K8=m # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set CONFIG_X86_P4_CLOCKMOD=m # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_INTEL_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y # CONFIG_PCIEAER_INJECT is not set CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y # CONFIG_PCI_PRI is not set # CONFIG_PCI_PASID is not set CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_ALIX is not set CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_RAPIDIO is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_HAVE_ATOMIC_IOMAP=y CONFIG_HAVE_TEXT_POKE_SMP=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE_DEMUX is not set CONFIG_IP_MROUTE=y # CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_LRO=y # CONFIG_INET_DIAG is not set CONFIG_TCP_CONG_ADVANCED=y # CONFIG_TCP_CONG_BIC is not set CONFIG_TCP_CONG_CUBIC=y # CONFIG_TCP_CONG_WESTWOOD is not set # CONFIG_TCP_CONG_HTCP is not set # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # CONFIG_TCP_CONG_LP is not set # CONFIG_TCP_CONG_VENO is not set # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=y # CONFIG_IPV6_PRIVACY is not set # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=y CONFIG_INET6_ESP=y # CONFIG_INET6_IPCOMP is not set # CONFIG_IPV6_MIP6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_MROUTE is not set CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_NETFILTER_ADVANCED is not set # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_IRC=y # CONFIG_NF_CONNTRACK_NETBIOS_NS is not set CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CT_NETLINK=y CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_STATE=y # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y # CONFIG_NF_NAT_TFTP is not set # CONFIG_NF_NAT_AMANDA is not set # CONFIG_NF_NAT_PPTP is not set # CONFIG_NF_NAT_H323 is not set CONFIG_NF_NAT_SIP=y CONFIG_IP_NF_MANGLE=y # CONFIG_IP_NF_RAW is not set # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=y CONFIG_NF_CONNTRACK_IPV6=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y CONFIG_IP6_NF_MANGLE=y # CONFIG_IP6_NF_RAW is not set # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_L2TP is not set CONFIG_STP=y CONFIG_BRIDGE=y CONFIG_BRIDGE_IGMP_SNOOPING=y # CONFIG_NET_DSA is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set # CONFIG_NET_SCH_HTB is not set # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set # CONFIG_NET_SCH_MULTIQ is not set # CONFIG_NET_SCH_RED is not set # CONFIG_NET_SCH_SFB is not set # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DRR is not set # CONFIG_NET_SCH_MQPRIO is not set # CONFIG_NET_SCH_CHOKE is not set # CONFIG_NET_SCH_QFQ is not set # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set # CONFIG_NET_CLS_FW is not set # CONFIG_NET_CLS_U32 is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set # CONFIG_NET_CLS_CGROUP is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 # CONFIG_NET_EMATCH_CMP is not set # CONFIG_NET_EMATCH_NBYTE is not set # CONFIG_NET_EMATCH_U32 is not set # CONFIG_NET_EMATCH_META is not set # CONFIG_NET_EMATCH_TEXT is not set CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set # CONFIG_NET_ACT_GACT is not set # CONFIG_NET_ACT_MIRRED is not set # CONFIG_NET_ACT_IPT is not set # CONFIG_NET_ACT_NAT is not set # CONFIG_NET_ACT_PEDIT is not set # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_ACT_CSUM is not set CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set # CONFIG_NET_DROP_MONITOR is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y # CONFIG_NET_9P is not set # CONFIG_CAIF is not set # CONFIG_CEPH_LIB is not set # CONFIG_NFC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_DEVRES=y CONFIG_SYS_HYPERVISOR=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set # CONFIG_BLK_DEV_RBD is not set # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=m CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m # CONFIG_SCSI_CXGB3_ISCSI is not set # CONFIG_SCSI_CXGB4_ISCSI is not set # CONFIG_SCSI_BNX2_ISCSI is not set # CONFIG_SCSI_BNX2X_FCOE is not set # CONFIG_BE2ISCSI is not set CONFIG_BLK_DEV_3W_XXXX_RAID=m # CONFIG_SCSI_HPSA is not set CONFIG_SCSI_3W_9XXX=m # CONFIG_SCSI_3W_SAS is not set CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 CONFIG_AIC79XX_DEBUG_ENABLE=y CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set # CONFIG_SCSI_MVSAS_TASKLET is not set # CONFIG_SCSI_MVUMI is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_ARCMSR=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m CONFIG_SCSI_FLASHPOINT=y # CONFIG_VMWARE_PVSCSI is not set CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m # CONFIG_FCOE_FNIC is not set CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=m # CONFIG_SCSI_IPR_TRACE is not set # CONFIG_SCSI_IPR_DUMP is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m # CONFIG_SCSI_QLA_ISCSI is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_NSP32=m CONFIG_SCSI_DEBUG=m # CONFIG_SCSI_PMCRAID is not set # CONFIG_SCSI_PM8001 is not set CONFIG_SCSI_SRP=m # CONFIG_SCSI_BFA_FC is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m # CONFIG_SATA_AHCI_PLATFORM is not set CONFIG_SATA_INIC162X=m # CONFIG_SATA_ACARD_AHCI is not set CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARASAN_CF is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_ATP867X is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CS5536 is not set # CONFIG_PATA_CYPRESS is not set CONFIG_PATA_EFAR=m # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set CONFIG_PATA_MARVELL=m # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC2027X is not set CONFIG_PATA_PDC_OLD=m CONFIG_PATA_RADISYS=m # CONFIG_PATA_RDC is not set # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SCH=m # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_SIL680 is not set CONFIG_PATA_SIS=m # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_VIA is not set CONFIG_PATA_WINBOND=m # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # # CONFIG_PATA_ACPI is not set CONFIG_ATA_GENERIC=m CONFIG_PATA_LEGACY=m CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MULTICORE_RAID456 is not set CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m # CONFIG_DM_THIN_PROVISIONING is not set CONFIG_DM_MIRROR=m # CONFIG_DM_RAID is not set # CONFIG_DM_LOG_USERSPACE is not set CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_MULTIPATH_QL is not set # CONFIG_DM_MULTIPATH_ST is not set CONFIG_DM_DELAY=m # CONFIG_DM_UEVENT is not set # CONFIG_DM_FLAKEY is not set CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m CONFIG_TCM_FC=m CONFIG_ISCSI_TARGET=m CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_FIREWIRE_NOSY is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_NET_CORE=y # CONFIG_BONDING is not set # CONFIG_DUMMY is not set # CONFIG_EQUALIZER is not set # CONFIG_NET_FC is not set CONFIG_MII=m # CONFIG_IFB is not set # CONFIG_MACVLAN is not set CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_TUN=y # CONFIG_VETH is not set CONFIG_VIRTIO_NET=m CONFIG_SUNGEM_PHY=m # CONFIG_ARCNET is not set # # CAIF transport drivers # CONFIG_ETHERNET=y CONFIG_MDIO=m CONFIG_NET_VENDOR_3COM=y # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_3C589 is not set CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_VENDOR_ADAPTEC=y # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_NET_VENDOR_ALTEON=y # CONFIG_ACENIC is not set CONFIG_NET_VENDOR_AMD=y # CONFIG_AMD8111_ETH is not set # CONFIG_PCNET32 is not set # CONFIG_PCMCIA_NMCLAN is not set CONFIG_NET_VENDOR_ATHEROS=y # CONFIG_ATL2 is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set CONFIG_ATL1C=m CONFIG_NET_VENDOR_BROADCOM=y # CONFIG_B44 is not set CONFIG_BNX2=m # CONFIG_CNIC is not set CONFIG_TIGON3=y CONFIG_BNX2X=m CONFIG_NET_VENDOR_BROCADE=y # CONFIG_BNA is not set CONFIG_NET_VENDOR_CHELSIO=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y # CONFIG_ENIC is not set # CONFIG_DNET is not set CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_PCMCIA_XIRCOM is not set CONFIG_NET_VENDOR_DLINK=y # CONFIG_DL2K is not set # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y # CONFIG_BE2NET is not set CONFIG_NET_VENDOR_EXAR=y # CONFIG_S2IO is not set # CONFIG_VXGE is not set CONFIG_NET_VENDOR_FUJITSU=y # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IGB=m CONFIG_IGBVF=m # CONFIG_IXGB is not set CONFIG_IXGBE=m # CONFIG_IXGBEVF is not set CONFIG_NET_VENDOR_I825XX=y # CONFIG_ZNET is not set # CONFIG_IP1000 is not set # CONFIG_JME is not set CONFIG_NET_VENDOR_MARVELL=y CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set # CONFIG_SKGE_GENESIS is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MELLANOX=y # CONFIG_MLX4_EN is not set # CONFIG_MLX4_CORE is not set CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8851_MLL is not set # CONFIG_KSZ884X_PCI is not set CONFIG_NET_VENDOR_MYRI=y # CONFIG_MYRI10GE is not set # CONFIG_FEALNX is not set CONFIG_NET_VENDOR_NATSEMI=y # CONFIG_NATSEMI is not set # CONFIG_NS83820 is not set CONFIG_NET_VENDOR_8390=y # CONFIG_PCMCIA_AXNET is not set CONFIG_NE2K_PCI=m # CONFIG_PCMCIA_PCNET is not set CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=y CONFIG_NET_VENDOR_OKI=y # CONFIG_PCH_GBE is not set # CONFIG_ETHOC is not set CONFIG_NET_PACKET_ENGINE=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y # CONFIG_QLA3XXX is not set # CONFIG_QLCNIC is not set # CONFIG_QLGE is not set # CONFIG_NETXEN_NIC is not set CONFIG_NET_VENDOR_REALTEK=y # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_R8169=m CONFIG_NET_VENDOR_RDC=y # CONFIG_R6040 is not set CONFIG_NET_VENDOR_SEEQ=y # CONFIG_SEEQ8005 is not set CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=m CONFIG_NET_VENDOR_SIS=y # CONFIG_SIS900 is not set # CONFIG_SIS190 is not set # CONFIG_SFC is not set CONFIG_NET_VENDOR_SMSC=y # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_EPIC100 is not set # CONFIG_SMSC9420 is not set CONFIG_NET_VENDOR_STMICRO=y # CONFIG_STMMAC_ETH is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m # CONFIG_NIU is not set CONFIG_NET_VENDOR_TEHUTI=y # CONFIG_TEHUTI is not set CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=m CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_VIA_VELOCITY=m CONFIG_NET_VENDOR_XIRCOM=y # CONFIG_PCMCIA_XIRC2PS is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_STE10XP is not set # CONFIG_LSI_ET1011C_PHY is not set # CONFIG_MICREL_PHY is not set CONFIG_FIXED_PHY=y # CONFIG_MDIO_BITBANG is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set CONFIG_TR=y # CONFIG_PCMCIA_IBMTR is not set # CONFIG_IBMOL is not set # CONFIG_IBMLS is not set CONFIG_3C359=m # CONFIG_TMS380TR is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_HSO is not set # CONFIG_USB_IPHETH is not set # CONFIG_WLAN is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=y # CONFIG_VMXNET3 is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_POLLDEV is not set CONFIG_INPUT_SPARSEKMAP=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_AS5011 is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_USB_ACECAD is not set # CONFIG_TABLET_USB_AIPTEK is not set # CONFIG_TABLET_USB_GTCO is not set # CONFIG_TABLET_USB_HANWANG is not set # CONFIG_TABLET_USB_KBTAB is not set # CONFIG_TABLET_USB_WACOM is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set # CONFIG_INPUT_PCSPKR is not set # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_UINPUT is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MFD_HSU is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y # CONFIG_SERIAL_JSM is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_PCH_UART is not set # CONFIG_SERIAL_XILINX_PS_UART is not set CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_VIRTIO_CONSOLE=y # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_MMAP is not set # CONFIG_HANGCHECK_TIMER is not set CONFIG_TCG_TPM=y CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y # CONFIG_RAMOOPS is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y # CONFIG_I2C_ISCH is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_DESIGNWARE_PCI is not set # CONFIG_I2C_INTEL_MID is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # CONFIG_I2C_EG20T is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_STUB is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_SPI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # # Enable Device Drivers -> PPS to see the PTP clock options. # CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_BQ20Z75 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_MAX8903 is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_K10TEMP is not set # CONFIG_SENSORS_FAM15H_POWER is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SCH56XX_COMMON is not set # CONFIG_SENSORS_SCH5627 is not set # CONFIG_SENSORS_SCH5636 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_VIA_CPUTEMP is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_APPLESMC is not set # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set # CONFIG_SENSORS_ATK0110 is not set CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TPS6105X is not set # CONFIG_TPS6507X is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_CS5535 is not set # CONFIG_LPC_SCH is not set # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_ALI=y CONFIG_AGP_ATI=y CONFIG_AGP_AMD=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_NVIDIA=y CONFIG_AGP_SIS=y CONFIG_AGP_SWORKS=y CONFIG_AGP_VIA=y CONFIG_AGP_EFFICEON=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m # CONFIG_DRM_VMWGFX is not set # CONFIG_STUB_POULSBO is not set # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m # CONFIG_FB_WMT_GE_ROPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=y # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_VESA is not set CONFIG_FB_EFI=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_VIRTUAL is not set CONFIG_XEN_FBDEV_FRONTEND=m # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=m # CONFIG_HID_ACRUX is not set CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set CONFIG_HID_EZKEY=m # CONFIG_HID_HOLTEK is not set # CONFIG_HID_KEYTOUCH is not set CONFIG_HID_KYE=m # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set CONFIG_HID_GYRATION=m # CONFIG_HID_TWINHAN is not set CONFIG_HID_KENSINGTON=m # CONFIG_HID_LCPOWER is not set CONFIG_HID_LOGITECH=m CONFIG_HID_LOGITECH_DJ=m CONFIG_LOGITECH_FF=y # CONFIG_LOGIRUMBLEPAD2_FF is not set # CONFIG_LOGIG940_FF is not set CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m # CONFIG_HID_MULTITOUCH is not set CONFIG_HID_NTRIG=m # CONFIG_HID_ORTEK is not set CONFIG_HID_PANTHERLORD=m CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=m # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_QUANTA is not set # CONFIG_HID_ROCCAT is not set CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m # CONFIG_HID_SPEEDLINK is not set CONFIG_HID_SUNPLUS=m # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set CONFIG_HID_TOPSEED=m # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB_ARCH_HAS_XHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_DWC3 is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_XHCI_HCD is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # CONFIG_NOP_USB_XCEIV is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set # CONFIG_LEDS_CLEVO_MAIL is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_DELL_NETBOOKS is not set # CONFIG_LEDS_TRIGGERS is not set # # LED Triggers # # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=y # CONFIG_EDAC_MCE_INJ is not set # CONFIG_EDAC_MM_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y # CONFIG_RTC_HCTOSYS is not set # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_INTEL_MID_DMAC is not set # CONFIG_INTEL_IOATDMA is not set # CONFIG_TIMB_DMA is not set # CONFIG_PCH_DMA is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set CONFIG_VIRTIO=y CONFIG_VIRTIO_RING=y # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=y # CONFIG_VIRTIO_MMIO is not set # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=m CONFIG_XEN_BACKEND=y CONFIG_XENFS=m CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=y CONFIG_XEN_GRANT_DEV_ALLOC=y CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=y CONFIG_XEN_PCIDEV_BACKEND=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set # CONFIG_USBIP_CORE is not set # CONFIG_ECHO is not set # CONFIG_COMEDI is not set # CONFIG_ASUS_OLED is not set # CONFIG_RTS_PSTOR is not set # CONFIG_RTS5139 is not set # CONFIG_TRANZPORT is not set # CONFIG_POHMELFS is not set # CONFIG_IDE_PHISON is not set CONFIG_DRM_NOUVEAU=m # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set CONFIG_DRM_NOUVEAU_DEBUG=y # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_VME_BUS is not set # CONFIG_DX_SEP is not set # CONFIG_IIO is not set CONFIG_XVMALLOC=y CONFIG_ZRAM=y # CONFIG_ZRAM_DEBUG is not set CONFIG_ZCACHE=y # CONFIG_FB_SM7XX is not set # CONFIG_CRYSTALHD is not set # CONFIG_FB_XGI is not set # CONFIG_ACPI_QUICKSTART is not set # CONFIG_USB_ENESTORAGE is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_DRM_PSB is not set # CONFIG_STAGING_MEDIA is not set CONFIG_X86_PLATFORM_DEVICES=y # CONFIG_ACER_WMI is not set # CONFIG_ACERHDF is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_DELL_WMI is not set # CONFIG_DELL_WMI_AIO is not set # CONFIG_FUJITSU_LAPTOP is not set # CONFIG_TC1100_WMI is not set # CONFIG_HP_ACCEL is not set # CONFIG_HP_WMI is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_IDEAPAD_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_INTEL_MENLOW is not set CONFIG_EEEPC_LAPTOP=y # CONFIG_ASUS_WMI is not set CONFIG_ACPI_WMI=m # CONFIG_MSI_WMI is not set # CONFIG_ACPI_ASUS is not set # CONFIG_TOPSTAR_LAPTOP is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_TOSHIBA_BT_RFKILL is not set # CONFIG_ACPI_CMPC is not set # CONFIG_INTEL_IPS is not set # CONFIG_IBM_RTL is not set # CONFIG_XO15_EBOOK is not set # CONFIG_SAMSUNG_LAPTOP is not set CONFIG_MXM_WMI=m # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set # # Hardware Spinlock drivers # CONFIG_CLKSRC_I8253=y CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_IOMMU_SUPPORT=y # CONFIG_INTEL_IOMMU is not set # CONFIG_VIRT_DRIVERS is not set # CONFIG_HYPERV is not set # CONFIG_PM_DEVFREQ is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_DMI_SYSFS is not set CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_SIGMA is not set # CONFIG_GOOGLE_FIRMWARE is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_FS_XIP=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_XFS_FS=m # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=m CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_AUTOFS4_FS=y # CONFIG_FUSE_FS is not set CONFIG_GENERIC_ACL=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_ECRYPT_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_LOGFS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_PSTORE is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFS_USE_NEW_IDMAPPER is not set # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y # CONFIG_CEPH_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4 # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_KMEMLEAK is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_ATOMIC_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_REDUCED=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_LIST is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 CONFIG_RCU_CPU_STALL_VERBOSE=y # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_LKDTM is not set # CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set CONFIG_FAULT_INJECTION=y # CONFIG_FAILSLAB is not set # CONFIG_FAIL_PAGE_ALLOC is not set CONFIG_FAIL_MAKE_REQUEST=y # CONFIG_FAIL_IO_TIMEOUT is not set CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y # CONFIG_FUNCTION_TRACER is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_FTRACE_SYSCALLS is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_STACK_TRACER is not set CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set # CONFIG_RING_BUFFER_BENCHMARK is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_DYNAMIC_DEBUG is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_ASYNC_RAID6_TEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y # CONFIG_KGDB_TESTS is not set # CONFIG_KGDB_LOW_LEVEL_TRAP is not set # CONFIG_KGDB_KDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y # CONFIG_KMEMCHECK is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_X86_PTDUMP=y CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_NX_TEST=m CONFIG_DOUBLEFAULT=y # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set # # Security options # CONFIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_PATH is not set CONFIG_LSM_MMAP_MIN_ADDR=65534 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_IMA is not set # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=y # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_VMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m # CONFIG_CRYPTO_GHASH is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_586=y # CONFIG_CRYPTO_AES_NI_INTEL is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_586 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_586 is not set # # Compression # # CONFIG_CRYPTO_DEFLATE is not set CONFIG_CRYPTO_ZLIB=y # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_PADLOCK is not set # CONFIG_CRYPTO_DEV_GEODE is not set CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m # CONFIG_KVM_MMU_AUDIT is not set CONFIG_VHOST_NET=y # CONFIG_LGUEST is not set CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=y # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m # CONFIG_CRC8 is not set CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPU_RMAP=y CONFIG_NLATTR=y # CONFIG_AVERAGE is not set # CONFIG_CORDIC is not set --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --3MwIy2ne0vdjdPXF-- From xen-devel-bounces@lists.xen.org Fri May 11 19:07:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19: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 ) id 1SSvAy-0003i0-VW; Fri, 11 May 2012 19:06:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvAw-0003hv-OG for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:06:50 +0000 Received: from [85.158.143.35:14657] by server-2.bemta-4.messagelabs.com id 65/AF-17550-A436DAF4; Fri, 11 May 2012 19:06:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336763208!13578662!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4963 invoked from network); 11 May 2012 19:06:49 -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 May 2012 19:06:49 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJ6jHn014884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:06:46 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 q4BJ6iVm029225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:06:45 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 q4BJ6iJ6000517; Fri, 11 May 2012 14:06:44 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:06:44 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5B69640359; Fri, 11 May 2012 15:00:41 -0400 (EDT) Date: Fri, 11 May 2012 15:00:41 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511190041.GA3785@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: > Konrad Rzeszutek Wilk wrote: > > On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > >> Liu, Jinsong wrote: > >>> Just notice your reply (so quick :) > >>> > >>> Agree and will update later, except 1 concern below. > >>> > >>> Konrad Rzeszutek Wilk wrote: > >>>>> > >>>>> Hmm, it's good if it's convenient to do it automatically via > >>>>> dev->release. However, dev container (pcpu) would be free at some > >>>>> other error cases, so I prefer do it 'manually'. > >>>> > >>>> You could also call pcpu_release(..) to do it manually. > >>>> > >>> > >>> that means kfree(pcpu) would be done twice at some error cases, do > >>> you think it really good? > >>> > >> > >> Ping. > >> > >> I think error recovery should be kept inside error logic level > >> itself, if try to recover upper level error would bring trouble. > >> > >> In our example, there are 2 logic levels: > >> pcpu level (as container), and dev level (subfield used for sys) > > > > So you need to untangle free_pcpu from doing both. Meaning one does > > the SysFS and the other deals with free-ing the structure and > > removing itself from the list. > > > > free_cpu is very samll, just consist of the 2 parts your said: > * pcpu_sys_remove() deal with sysfs > * list_del/kfree(pcpu) deal with pcpu > > > > >> dev->release should only recover error occurred at dev/sys level, > >> and the pcpu error should be recovered at pcpu level. > >> > >> If dev->release try to recover its container pcpu level error, like > >> list_del/kfree(pcpu), it would make confusing. i.e., considering > >> pcpu_sys_create(), 2 error cases: device_register fail, and > >> device_create_file fail --> how can the caller decide kfree(pcpu) or > >> not? > > > > Then you should free it manually. But you can do this by a wrapper > > function: > > > > __pcpu_release(..) { > > .. > > /* Does the removing itself from the list and kfree the pcpu */ > > } > > pcpu_release(..) { > > struct pcpcu *p= container_of(..) > > __pcpu_release(p); > > } > > > > dev->release = &pcpu_release; > > > > Too weird way. If we want to release dev itself it's good to use dev->release, but for pcpu I doubt it. > (consider the example I gave --> why we create issue (it maybe solved in weird method I agree), just for using dev->release?) > > In kernel many dev->release keep NULL. > An example of using dev->release is cpu/mcheck/mce.c --> mce_device_release(), it *just* deal dev itself. OK? I am not sure what are we arguing here anymore? I think using 'kfree(pcpu)' on the error paths (as long as it is done before device_register) is OK. I think that seperating the SysFS deletion from the pcpu deletion should be done to avoid races. Perhaps the SysFS deletion function should also remove the pcpu from the list. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:07:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19: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 ) id 1SSvAy-0003i0-VW; Fri, 11 May 2012 19:06:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvAw-0003hv-OG for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:06:50 +0000 Received: from [85.158.143.35:14657] by server-2.bemta-4.messagelabs.com id 65/AF-17550-A436DAF4; Fri, 11 May 2012 19:06:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336763208!13578662!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4963 invoked from network); 11 May 2012 19:06:49 -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 May 2012 19:06:49 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJ6jHn014884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:06:46 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 q4BJ6iVm029225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:06:45 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 q4BJ6iJ6000517; Fri, 11 May 2012 14:06:44 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:06:44 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5B69640359; Fri, 11 May 2012 15:00:41 -0400 (EDT) Date: Fri, 11 May 2012 15:00:41 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511190041.GA3785@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: > Konrad Rzeszutek Wilk wrote: > > On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > >> Liu, Jinsong wrote: > >>> Just notice your reply (so quick :) > >>> > >>> Agree and will update later, except 1 concern below. > >>> > >>> Konrad Rzeszutek Wilk wrote: > >>>>> > >>>>> Hmm, it's good if it's convenient to do it automatically via > >>>>> dev->release. However, dev container (pcpu) would be free at some > >>>>> other error cases, so I prefer do it 'manually'. > >>>> > >>>> You could also call pcpu_release(..) to do it manually. > >>>> > >>> > >>> that means kfree(pcpu) would be done twice at some error cases, do > >>> you think it really good? > >>> > >> > >> Ping. > >> > >> I think error recovery should be kept inside error logic level > >> itself, if try to recover upper level error would bring trouble. > >> > >> In our example, there are 2 logic levels: > >> pcpu level (as container), and dev level (subfield used for sys) > > > > So you need to untangle free_pcpu from doing both. Meaning one does > > the SysFS and the other deals with free-ing the structure and > > removing itself from the list. > > > > free_cpu is very samll, just consist of the 2 parts your said: > * pcpu_sys_remove() deal with sysfs > * list_del/kfree(pcpu) deal with pcpu > > > > >> dev->release should only recover error occurred at dev/sys level, > >> and the pcpu error should be recovered at pcpu level. > >> > >> If dev->release try to recover its container pcpu level error, like > >> list_del/kfree(pcpu), it would make confusing. i.e., considering > >> pcpu_sys_create(), 2 error cases: device_register fail, and > >> device_create_file fail --> how can the caller decide kfree(pcpu) or > >> not? > > > > Then you should free it manually. But you can do this by a wrapper > > function: > > > > __pcpu_release(..) { > > .. > > /* Does the removing itself from the list and kfree the pcpu */ > > } > > pcpu_release(..) { > > struct pcpcu *p= container_of(..) > > __pcpu_release(p); > > } > > > > dev->release = &pcpu_release; > > > > Too weird way. If we want to release dev itself it's good to use dev->release, but for pcpu I doubt it. > (consider the example I gave --> why we create issue (it maybe solved in weird method I agree), just for using dev->release?) > > In kernel many dev->release keep NULL. > An example of using dev->release is cpu/mcheck/mce.c --> mce_device_release(), it *just* deal dev itself. OK? I am not sure what are we arguing here anymore? I think using 'kfree(pcpu)' on the error paths (as long as it is done before device_register) is OK. I think that seperating the SysFS deletion from the pcpu deletion should be done to avoid races. Perhaps the SysFS deletion function should also remove the pcpu from the list. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:21:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:21:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvOJ-0003yq-Dm; Fri, 11 May 2012 19:20:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvOH-0003yl-QT for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:20:38 +0000 Received: from [85.158.139.83:27853] by server-9.bemta-5.messagelabs.com id F1/B4-09826-3866DAF4; Fri, 11 May 2012 19:20:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336764034!28252269!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18976 invoked from network); 11 May 2012 19:20:34 -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; 11 May 2012 19:20:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12436088" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 19:20: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, 11 May 2012 20:20:33 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSvOD-0000Iu-LQ; Fri, 11 May 2012 19:20:33 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSvOD-0005I0-KJ; Fri, 11 May 2012 20:20:33 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 11 May 2012 20:20:33 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12853: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12853 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12852 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken REGR. vs. 12852 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 42553101ccfe baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 broken test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:21:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:21:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvOJ-0003yq-Dm; Fri, 11 May 2012 19:20:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvOH-0003yl-QT for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:20:38 +0000 Received: from [85.158.139.83:27853] by server-9.bemta-5.messagelabs.com id F1/B4-09826-3866DAF4; Fri, 11 May 2012 19:20:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1336764034!28252269!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODU1MQ==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18976 invoked from network); 11 May 2012 19:20:34 -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; 11 May 2012 19:20:34 -0000 X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="12436088" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 11 May 2012 19:20: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, 11 May 2012 20:20:33 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1SSvOD-0000Iu-LQ; Fri, 11 May 2012 19:20:33 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SSvOD-0005I0-KJ; Fri, 11 May 2012 20:20:33 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 11 May 2012 20:20:33 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12853: regressions - trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12853 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12852 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken REGR. vs. 12852 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen 42553101ccfe baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 broken test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:38:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:38:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvew-0004CS-2V; Fri, 11 May 2012 19:37:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSveu-0004CN-Sn for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:37:49 +0000 Received: from [85.158.138.51:34395] by server-6.bemta-3.messagelabs.com id 91/C6-05145-C8A6DAF4; Fri, 11 May 2012 19:37:48 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336765065!26663605!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1155 invoked from network); 11 May 2012 19:37:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 19:37:47 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJbgc0001680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:37:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BJbfQC025675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:37:41 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 q4BJbfH9032039; Fri, 11 May 2012 14:37:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:37:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E3B3840359; Fri, 11 May 2012 15:31:37 -0400 (EDT) Date: Fri, 11 May 2012 15:31:37 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511193137.GE3785@phenom.dumpdata.com> References: <20120511140454.GA13735@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > >> +struct pcpu { > >> + struct list_head list; > >> + struct device dev; > >> + uint32_t cpu_id; > >> + uint32_t flags; > >> +}; > >> + > >> +static struct bus_type xen_pcpu_subsys = { > >> + .name = "xen_cpu", > >> + .dev_name = "xen_cpu", > >> +}; > >> + > >> +static DEFINE_MUTEX(xen_pcpu_lock); > >> + > >> +static LIST_HEAD(xen_pcpus); > > > > So what about the recommendation to get rid of that and > > instead do > > > > struct pcpu *xen_cpu; > > I'm not quite clear your meaning here, do you mean 'LIST_HEAD(xen_pcpus)' instead of 'struct pcpu *xen_cpu'? No. Just use the embedded 'struct list_head' inside of 'struct pcpu' as your iterator. And your first 'struct pcpu' won't ever be deleted (as it is for CPU0), so you can iterate from that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:38:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:38:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvew-0004CS-2V; Fri, 11 May 2012 19:37:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSveu-0004CN-Sn for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:37:49 +0000 Received: from [85.158.138.51:34395] by server-6.bemta-3.messagelabs.com id 91/C6-05145-C8A6DAF4; Fri, 11 May 2012 19:37:48 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336765065!26663605!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1155 invoked from network); 11 May 2012 19:37:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 19:37:47 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJbgc0001680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:37:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BJbfQC025675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:37:41 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 q4BJbfH9032039; Fri, 11 May 2012 14:37:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:37:40 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id E3B3840359; Fri, 11 May 2012 15:31:37 -0400 (EDT) Date: Fri, 11 May 2012 15:31:37 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511193137.GE3785@phenom.dumpdata.com> References: <20120511140454.GA13735@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface (V2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > >> +struct pcpu { > >> + struct list_head list; > >> + struct device dev; > >> + uint32_t cpu_id; > >> + uint32_t flags; > >> +}; > >> + > >> +static struct bus_type xen_pcpu_subsys = { > >> + .name = "xen_cpu", > >> + .dev_name = "xen_cpu", > >> +}; > >> + > >> +static DEFINE_MUTEX(xen_pcpu_lock); > >> + > >> +static LIST_HEAD(xen_pcpus); > > > > So what about the recommendation to get rid of that and > > instead do > > > > struct pcpu *xen_cpu; > > I'm not quite clear your meaning here, do you mean 'LIST_HEAD(xen_pcpus)' instead of 'struct pcpu *xen_cpu'? No. Just use the embedded 'struct list_head' inside of 'struct pcpu' as your iterator. And your first 'struct pcpu' won't ever be deleted (as it is for CPU0), so you can iterate from that. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:49:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:49:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvpS-0004Mp-5w; Fri, 11 May 2012 19:48:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvpQ-0004Mk-LQ for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:48:40 +0000 Received: from [85.158.143.99:54248] by server-1.bemta-4.messagelabs.com id C5/30-20925-71D6DAF4; Fri, 11 May 2012 19:48:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336765716!27585133!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1599 invoked from network); 11 May 2012 19:48:37 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 19:48:37 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJli9k028438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:47:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BJlgkg012681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:47:43 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 q4BJlfw0005698; Fri, 11 May 2012 14:47:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:47:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5A02B40359; Fri, 11 May 2012 15:41:38 -0400 (EDT) Date: Fri, 11 May 2012 15:41:38 -0400 From: Konrad Rzeszutek Wilk To: Carsten Schiers Message-ID: <20120511194138.GA30099@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , xen-devel , Jan Beulich , Sander Eikelenboom Subject: Re: [Xen-devel] Load increase after memory upgrade (part2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote: > Hi Konrad, > = > =A0 > don't want to be pushy, as I have no real issue. I simply use the Xenifie= d kernel or take the double load. = > = > But I think this mistery is still open. My last status was that the lates= t patch you produced resulted in a BUG, = Yes, that is right. Thank you for reminding me. > = > so we still have not checked whether our theory is correct. No we haven't. And I should be have no trouble reproducing this. I can just= write a tiny module that allocates vmalloc_32(). But your timming sucks - I am going on a week vacation next week :-( Ah, if there was just a cloning machine - I could stick myself in it, and Baseline_0 goes on vacation, while Clone_1 goes on working. Then git merge Baseline_0 and Clone_1 in a week and fixup the merge conflicts and continue on. Sigh. Can I ask you to be patient with me once more and ping me in a week - when I am back from vacation and my brain is fresh to work on this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:49:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19:49:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvpS-0004Mp-5w; Fri, 11 May 2012 19:48:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvpQ-0004Mk-LQ for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:48:40 +0000 Received: from [85.158.143.99:54248] by server-1.bemta-4.messagelabs.com id C5/30-20925-71D6DAF4; Fri, 11 May 2012 19:48:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336765716!27585133!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTI1MDUy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1599 invoked from network); 11 May 2012 19:48:37 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 19:48:37 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJli9k028438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:47:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BJlgkg012681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:47:43 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 q4BJlfw0005698; Fri, 11 May 2012 14:47:41 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:47:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 5A02B40359; Fri, 11 May 2012 15:41:38 -0400 (EDT) Date: Fri, 11 May 2012 15:41:38 -0400 From: Konrad Rzeszutek Wilk To: Carsten Schiers Message-ID: <20120511194138.GA30099@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , xen-devel , Jan Beulich , Sander Eikelenboom Subject: Re: [Xen-devel] Load increase after memory upgrade (part2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote: > Hi Konrad, > = > =A0 > don't want to be pushy, as I have no real issue. I simply use the Xenifie= d kernel or take the double load. = > = > But I think this mistery is still open. My last status was that the lates= t patch you produced resulted in a BUG, = Yes, that is right. Thank you for reminding me. > = > so we still have not checked whether our theory is correct. No we haven't. And I should be have no trouble reproducing this. I can just= write a tiny module that allocates vmalloc_32(). But your timming sucks - I am going on a week vacation next week :-( Ah, if there was just a cloning machine - I could stick myself in it, and Baseline_0 goes on vacation, while Clone_1 goes on working. Then git merge Baseline_0 and Clone_1 in a week and fixup the merge conflicts and continue on. Sigh. Can I ask you to be patient with me once more and ping me in a week - when I am back from vacation and my brain is fresh to work on this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:57:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19: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 ) id 1SSvxS-0004Vi-59; Fri, 11 May 2012 19:56:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvxR-0004Vd-Fv for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:56:57 +0000 Received: from [85.158.143.35:49512] by server-2.bemta-4.messagelabs.com id FF/63-17550-80F6DAF4; Fri, 11 May 2012 19:56:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336766214!14149234!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25671 invoked from network); 11 May 2012 19:56:56 -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; 11 May 2012 19:56:56 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJupq0021693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:56:52 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 q4BJupwQ018647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:56:51 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 q4BJunh0012067; Fri, 11 May 2012 14:56:51 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:56:49 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D4A5E40359; Fri, 11 May 2012 15:50:46 -0400 (EDT) Date: Fri, 11 May 2012 15:50:46 -0400 From: Konrad Rzeszutek Wilk To: Rajendra Bele Message-ID: <20120511195046.GA30343@phenom.dumpdata.com> References: <20120510153901.GF6389@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen Enhancement X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 02:33:50PM +0545, Rajendra Bele wrote: > yes i am interested in this research Ok, lets put xen-devel back on the CC. .. snip.. > >> can anybody help me for following activities > >> > >> 1. Install Xen on laptop That should be easy. Just install Fedora Core 17 and run 'yum install xen' > >> > >> 2. Add open source os to create virtualization environment Like Linux? > >> > >> 3. check performance with current souce code > >> > >> 4. Identify algorithms associated with existing > >> > >> 5. Identify performance bottlenecks with current algorithms > >> > >> 6. Modify algorithms and implement code > >> > >> 7. execute the code and check performance So .. may I suggest a different path. Try installing Fedora Core 17 and just try installing a guest - using virt-install. Then come back and I can give you an idea of where we know there are bottlenecks. > >> > >> I will be more happy if abybody guides me to conduct above research plan > > > > Are you still interested in this? > > > >> > >> Thanking you > > > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 19:57:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 19: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 ) id 1SSvxS-0004Vi-59; Fri, 11 May 2012 19:56:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSvxR-0004Vd-Fv for xen-devel@lists.xensource.com; Fri, 11 May 2012 19:56:57 +0000 Received: from [85.158.143.35:49512] by server-2.bemta-4.messagelabs.com id FF/63-17550-80F6DAF4; Fri, 11 May 2012 19:56:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1336766214!14149234!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25671 invoked from network); 11 May 2012 19:56:56 -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; 11 May 2012 19:56:56 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BJupq0021693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 19:56:52 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 q4BJupwQ018647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 19:56:51 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 q4BJunh0012067; Fri, 11 May 2012 14:56:51 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 12:56:49 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id D4A5E40359; Fri, 11 May 2012 15:50:46 -0400 (EDT) Date: Fri, 11 May 2012 15:50:46 -0400 From: Konrad Rzeszutek Wilk To: Rajendra Bele Message-ID: <20120511195046.GA30343@phenom.dumpdata.com> References: <20120510153901.GF6389@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen Enhancement X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 02:33:50PM +0545, Rajendra Bele wrote: > yes i am interested in this research Ok, lets put xen-devel back on the CC. .. snip.. > >> can anybody help me for following activities > >> > >> 1. Install Xen on laptop That should be easy. Just install Fedora Core 17 and run 'yum install xen' > >> > >> 2. Add open source os to create virtualization environment Like Linux? > >> > >> 3. check performance with current souce code > >> > >> 4. Identify algorithms associated with existing > >> > >> 5. Identify performance bottlenecks with current algorithms > >> > >> 6. Modify algorithms and implement code > >> > >> 7. execute the code and check performance So .. may I suggest a different path. Try installing Fedora Core 17 and just try installing a guest - using virt-install. Then come back and I can give you an idea of where we know there are bottlenecks. > >> > >> I will be more happy if abybody guides me to conduct above research plan > > > > Are you still interested in this? > > > >> > >> Thanking you > > > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 20:31:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 20:31:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwUj-00056R-GK; Fri, 11 May 2012 20:31:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwUh-00056M-Ta for xen-devel@lists.xensource.com; Fri, 11 May 2012 20:31:20 +0000 Received: from [85.158.139.83:34257] by server-7.bemta-5.messagelabs.com id 3F/12-16195-7177DAF4; Fri, 11 May 2012 20:31:19 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336768277!27865050!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc4Nzcw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15472 invoked from network); 11 May 2012 20:31:18 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-15.tower-182.messagelabs.com with SMTP; 11 May 2012 20:31:18 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 11 May 2012 13:31:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99104894" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 13:31:17 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 13:31:16 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 04:31:14 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAHTcp+AABcXMA== Date: Fri, 11 May 2012 20:31:15 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> <20120511190041.GA3785@phenom.dumpdata.com> In-Reply-To: <20120511190041.GA3785@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: >> Konrad Rzeszutek Wilk wrote: >>> On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: >>>> Liu, Jinsong wrote: >>>>> Just notice your reply (so quick :) >>>>> >>>>> Agree and will update later, except 1 concern below. >>>>> >>>>> Konrad Rzeszutek Wilk wrote: >>>>>>> >>>>>>> Hmm, it's good if it's convenient to do it automatically via >>>>>>> dev->release. However, dev container (pcpu) would be free at >>>>>>> some other error cases, so I prefer do it 'manually'. >>>>>> >>>>>> You could also call pcpu_release(..) to do it manually. >>>>>> >>>>> >>>>> that means kfree(pcpu) would be done twice at some error cases, >>>>> do you think it really good? >>>>> >>>> >>>> Ping. >>>> >>>> I think error recovery should be kept inside error logic level >>>> itself, if try to recover upper level error would bring trouble. >>>> >>>> In our example, there are 2 logic levels: >>>> pcpu level (as container), and dev level (subfield used for sys) >>> >>> So you need to untangle free_pcpu from doing both. Meaning one does >>> the SysFS and the other deals with free-ing the structure and >>> removing itself from the list. >>> >> >> free_cpu is very samll, just consist of the 2 parts your said: >> * pcpu_sys_remove() deal with sysfs >> * list_del/kfree(pcpu) deal with pcpu >> >>> >>>> dev->release should only recover error occurred at dev/sys level, >>>> and the pcpu error should be recovered at pcpu level. >>>> >>>> If dev->release try to recover its container pcpu level error, like >>>> list_del/kfree(pcpu), it would make confusing. i.e., considering >>>> pcpu_sys_create(), 2 error cases: device_register fail, and >>>> device_create_file fail --> how can the caller decide kfree(pcpu) >>>> or not? >>> >>> Then you should free it manually. But you can do this by a wrapper >>> function: >>> >>> __pcpu_release(..) { >>> .. >>> /* Does the removing itself from the list and kfree the pcpu */ } >>> pcpu_release(..) { >>> struct pcpcu *p= container_of(..) >>> __pcpu_release(p); >>> } >>> >>> dev->release = &pcpu_release; >>> >> >> Too weird way. If we want to release dev itself it's good to use >> dev->release, but for pcpu I doubt it. (consider the example I gave >> --> why we create issue (it maybe solved in weird method I agree), >> just for using dev->release?) >> >> In kernel many dev->release keep NULL. >> An example of using dev->release is cpu/mcheck/mce.c --> >> mce_device_release(), it *just* deal dev itself. > > OK? I am not sure what are we arguing here anymore? > I think using 'kfree(pcpu)' on the error paths (as long as it is > done before device_register) is OK. I think that seperating > the SysFS deletion from the pcpu deletion should be done to > avoid races. Perhaps the SysFS deletion function should also > remove the pcpu from the list. How about static array pcpu[NR_CPUS]? It seems solve all issues we argued :) Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 20:31:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 20:31:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwUj-00056R-GK; Fri, 11 May 2012 20:31:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwUh-00056M-Ta for xen-devel@lists.xensource.com; Fri, 11 May 2012 20:31:20 +0000 Received: from [85.158.139.83:34257] by server-7.bemta-5.messagelabs.com id 3F/12-16195-7177DAF4; Fri, 11 May 2012 20:31:19 +0000 X-Env-Sender: jinsong.liu@intel.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1336768277!27865050!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc4Nzcw\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15472 invoked from network); 11 May 2012 20:31:18 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-15.tower-182.messagelabs.com with SMTP; 11 May 2012 20:31:18 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 11 May 2012 13:31:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99104894" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 11 May 2012 13:31:17 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 13:31:16 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.6]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.133]) with mapi id 14.01.0355.002; Sat, 12 May 2012 04:31:14 +0800 From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk Thread-Topic: [Xen-devel] [PATCH 3/3] Xen physical cpus interface Thread-Index: AQHNLr1B1b8pDRiwSFiwkpXixs4X8JbDIYNQgAHTcp+AABcXMA== Date: Fri, 11 May 2012 20:31:15 +0000 Message-ID: References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> <20120511190041.GA3785@phenom.dumpdata.com> In-Reply-To: <20120511190041.GA3785@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Konrad Rzeszutek Wilk wrote: > On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: >> Konrad Rzeszutek Wilk wrote: >>> On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: >>>> Liu, Jinsong wrote: >>>>> Just notice your reply (so quick :) >>>>> >>>>> Agree and will update later, except 1 concern below. >>>>> >>>>> Konrad Rzeszutek Wilk wrote: >>>>>>> >>>>>>> Hmm, it's good if it's convenient to do it automatically via >>>>>>> dev->release. However, dev container (pcpu) would be free at >>>>>>> some other error cases, so I prefer do it 'manually'. >>>>>> >>>>>> You could also call pcpu_release(..) to do it manually. >>>>>> >>>>> >>>>> that means kfree(pcpu) would be done twice at some error cases, >>>>> do you think it really good? >>>>> >>>> >>>> Ping. >>>> >>>> I think error recovery should be kept inside error logic level >>>> itself, if try to recover upper level error would bring trouble. >>>> >>>> In our example, there are 2 logic levels: >>>> pcpu level (as container), and dev level (subfield used for sys) >>> >>> So you need to untangle free_pcpu from doing both. Meaning one does >>> the SysFS and the other deals with free-ing the structure and >>> removing itself from the list. >>> >> >> free_cpu is very samll, just consist of the 2 parts your said: >> * pcpu_sys_remove() deal with sysfs >> * list_del/kfree(pcpu) deal with pcpu >> >>> >>>> dev->release should only recover error occurred at dev/sys level, >>>> and the pcpu error should be recovered at pcpu level. >>>> >>>> If dev->release try to recover its container pcpu level error, like >>>> list_del/kfree(pcpu), it would make confusing. i.e., considering >>>> pcpu_sys_create(), 2 error cases: device_register fail, and >>>> device_create_file fail --> how can the caller decide kfree(pcpu) >>>> or not? >>> >>> Then you should free it manually. But you can do this by a wrapper >>> function: >>> >>> __pcpu_release(..) { >>> .. >>> /* Does the removing itself from the list and kfree the pcpu */ } >>> pcpu_release(..) { >>> struct pcpcu *p= container_of(..) >>> __pcpu_release(p); >>> } >>> >>> dev->release = &pcpu_release; >>> >> >> Too weird way. If we want to release dev itself it's good to use >> dev->release, but for pcpu I doubt it. (consider the example I gave >> --> why we create issue (it maybe solved in weird method I agree), >> just for using dev->release?) >> >> In kernel many dev->release keep NULL. >> An example of using dev->release is cpu/mcheck/mce.c --> >> mce_device_release(), it *just* deal dev itself. > > OK? I am not sure what are we arguing here anymore? > I think using 'kfree(pcpu)' on the error paths (as long as it is > done before device_register) is OK. I think that seperating > the SysFS deletion from the pcpu deletion should be done to > avoid races. Perhaps the SysFS deletion function should also > remove the pcpu from the list. How about static array pcpu[NR_CPUS]? It seems solve all issues we argued :) Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 20:55:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 20:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwrE-0005RI-Qg; Fri, 11 May 2012 20:54:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwrC-0005RD-JK for xen-devel@lists.xensource.com; Fri, 11 May 2012 20:54:34 +0000 Received: from [85.158.138.51:56319] by server-10.bemta-3.messagelabs.com id 13/B6-29478-98C7DAF4; Fri, 11 May 2012 20:54:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336769671!26703529!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30158 invoked from network); 11 May 2012 20:54:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 20:54:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BKsT7k002659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 20:54:30 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 q4BKsSDC012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 20:54:28 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 q4BKsRYX014239; Fri, 11 May 2012 15:54:27 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 13:54:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B6CEB4035B; Fri, 11 May 2012 16:48:24 -0400 (EDT) Date: Fri, 11 May 2012 16:48:24 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511204824.GA2156@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> <20120511190041.GA3785@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 08:31:15PM +0000, Liu, Jinsong wrote: > Konrad Rzeszutek Wilk wrote: > > On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: > >> Konrad Rzeszutek Wilk wrote: > >>> On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > >>>> Liu, Jinsong wrote: > >>>>> Just notice your reply (so quick :) > >>>>> > >>>>> Agree and will update later, except 1 concern below. > >>>>> > >>>>> Konrad Rzeszutek Wilk wrote: > >>>>>>> > >>>>>>> Hmm, it's good if it's convenient to do it automatically via > >>>>>>> dev->release. However, dev container (pcpu) would be free at > >>>>>>> some other error cases, so I prefer do it 'manually'. > >>>>>> > >>>>>> You could also call pcpu_release(..) to do it manually. > >>>>>> > >>>>> > >>>>> that means kfree(pcpu) would be done twice at some error cases, > >>>>> do you think it really good? > >>>>> > >>>> > >>>> Ping. > >>>> > >>>> I think error recovery should be kept inside error logic level > >>>> itself, if try to recover upper level error would bring trouble. > >>>> > >>>> In our example, there are 2 logic levels: > >>>> pcpu level (as container), and dev level (subfield used for sys) > >>> > >>> So you need to untangle free_pcpu from doing both. Meaning one does > >>> the SysFS and the other deals with free-ing the structure and > >>> removing itself from the list. > >>> > >> > >> free_cpu is very samll, just consist of the 2 parts your said: > >> * pcpu_sys_remove() deal with sysfs > >> * list_del/kfree(pcpu) deal with pcpu > >> > >>> > >>>> dev->release should only recover error occurred at dev/sys level, > >>>> and the pcpu error should be recovered at pcpu level. > >>>> > >>>> If dev->release try to recover its container pcpu level error, like > >>>> list_del/kfree(pcpu), it would make confusing. i.e., considering > >>>> pcpu_sys_create(), 2 error cases: device_register fail, and > >>>> device_create_file fail --> how can the caller decide kfree(pcpu) > >>>> or not? > >>> > >>> Then you should free it manually. But you can do this by a wrapper > >>> function: > >>> > >>> __pcpu_release(..) { > >>> .. > >>> /* Does the removing itself from the list and kfree the pcpu */ } > >>> pcpu_release(..) { > >>> struct pcpcu *p= container_of(..) > >>> __pcpu_release(p); > >>> } > >>> > >>> dev->release = &pcpu_release; > >>> > >> > >> Too weird way. If we want to release dev itself it's good to use > >> dev->release, but for pcpu I doubt it. (consider the example I gave > >> --> why we create issue (it maybe solved in weird method I agree), > >> just for using dev->release?) > >> > >> In kernel many dev->release keep NULL. > >> An example of using dev->release is cpu/mcheck/mce.c --> > >> mce_device_release(), it *just* deal dev itself. > > > > OK? I am not sure what are we arguing here anymore? > > I think using 'kfree(pcpu)' on the error paths (as long as it is > > done before device_register) is OK. I think that seperating > > the SysFS deletion from the pcpu deletion should be done to > > avoid races. Perhaps the SysFS deletion function should also > > remove the pcpu from the list. > > How about static array pcpu[NR_CPUS]? > It seems solve all issues we argued :) Ugh. That could mean a structure of more than 4K of items. Lets stick with making it dynamic. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 20:55:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 20:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwrE-0005RI-Qg; Fri, 11 May 2012 20:54:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSwrC-0005RD-JK for xen-devel@lists.xensource.com; Fri, 11 May 2012 20:54:34 +0000 Received: from [85.158.138.51:56319] by server-10.bemta-3.messagelabs.com id 13/B6-29478-98C7DAF4; Fri, 11 May 2012 20:54:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1336769671!26703529!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUyNzMzOQ==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30158 invoked from network); 11 May 2012 20:54:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2012 20:54:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BKsT7k002659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 20:54:30 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 q4BKsSDC012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 20:54:28 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 q4BKsRYX014239; Fri, 11 May 2012 15:54:27 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 13:54:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B6CEB4035B; Fri, 11 May 2012 16:48:24 -0400 (EDT) Date: Fri, 11 May 2012 16:48:24 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20120511204824.GA2156@phenom.dumpdata.com> References: <20120420192439.GA32170@phenom.dumpdata.com> <20120510145745.GO26152@phenom.dumpdata.com> <20120511142758.GA29677@phenom.dumpdata.com> <20120511190041.GA3785@phenom.dumpdata.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "'xen-devel@lists.xensource.com'" , "'linux-kernel@vger.kernel.org'" Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, May 11, 2012 at 08:31:15PM +0000, Liu, Jinsong wrote: > Konrad Rzeszutek Wilk wrote: > > On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote: > >> Konrad Rzeszutek Wilk wrote: > >>> On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote: > >>>> Liu, Jinsong wrote: > >>>>> Just notice your reply (so quick :) > >>>>> > >>>>> Agree and will update later, except 1 concern below. > >>>>> > >>>>> Konrad Rzeszutek Wilk wrote: > >>>>>>> > >>>>>>> Hmm, it's good if it's convenient to do it automatically via > >>>>>>> dev->release. However, dev container (pcpu) would be free at > >>>>>>> some other error cases, so I prefer do it 'manually'. > >>>>>> > >>>>>> You could also call pcpu_release(..) to do it manually. > >>>>>> > >>>>> > >>>>> that means kfree(pcpu) would be done twice at some error cases, > >>>>> do you think it really good? > >>>>> > >>>> > >>>> Ping. > >>>> > >>>> I think error recovery should be kept inside error logic level > >>>> itself, if try to recover upper level error would bring trouble. > >>>> > >>>> In our example, there are 2 logic levels: > >>>> pcpu level (as container), and dev level (subfield used for sys) > >>> > >>> So you need to untangle free_pcpu from doing both. Meaning one does > >>> the SysFS and the other deals with free-ing the structure and > >>> removing itself from the list. > >>> > >> > >> free_cpu is very samll, just consist of the 2 parts your said: > >> * pcpu_sys_remove() deal with sysfs > >> * list_del/kfree(pcpu) deal with pcpu > >> > >>> > >>>> dev->release should only recover error occurred at dev/sys level, > >>>> and the pcpu error should be recovered at pcpu level. > >>>> > >>>> If dev->release try to recover its container pcpu level error, like > >>>> list_del/kfree(pcpu), it would make confusing. i.e., considering > >>>> pcpu_sys_create(), 2 error cases: device_register fail, and > >>>> device_create_file fail --> how can the caller decide kfree(pcpu) > >>>> or not? > >>> > >>> Then you should free it manually. But you can do this by a wrapper > >>> function: > >>> > >>> __pcpu_release(..) { > >>> .. > >>> /* Does the removing itself from the list and kfree the pcpu */ } > >>> pcpu_release(..) { > >>> struct pcpcu *p= container_of(..) > >>> __pcpu_release(p); > >>> } > >>> > >>> dev->release = &pcpu_release; > >>> > >> > >> Too weird way. If we want to release dev itself it's good to use > >> dev->release, but for pcpu I doubt it. (consider the example I gave > >> --> why we create issue (it maybe solved in weird method I agree), > >> just for using dev->release?) > >> > >> In kernel many dev->release keep NULL. > >> An example of using dev->release is cpu/mcheck/mce.c --> > >> mce_device_release(), it *just* deal dev itself. > > > > OK? I am not sure what are we arguing here anymore? > > I think using 'kfree(pcpu)' on the error paths (as long as it is > > done before device_register) is OK. I think that seperating > > the SysFS deletion from the pcpu deletion should be done to > > avoid races. Perhaps the SysFS deletion function should also > > remove the pcpu from the list. > > How about static array pcpu[NR_CPUS]? > It seems solve all issues we argued :) Ugh. That could mean a structure of more than 4K of items. Lets stick with making it dynamic. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 22:40:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 22:40:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSyVV-0006OY-Kl; Fri, 11 May 2012 22:40:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSyVU-0006OT-Qp for xen-devel@lists.xensource.com; Fri, 11 May 2012 22:40:17 +0000 Received: from [85.158.143.35:26055] by server-1.bemta-4.messagelabs.com id D6/1D-20925-0559DAF4; Fri, 11 May 2012 22:40:16 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-7.tower-21.messagelabs.com!1336776014!15677244!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18763 invoked from network); 11 May 2012 22:40:14 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-7.tower-21.messagelabs.com with SMTP; 11 May 2012 22:40:14 -0000 Received: from [10.0.1.5] (c-68-44-174-16.hsd1.nj.comcast.net [68.44.174.16]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q4BMeCah004362; Fri, 11 May 2012 18:40:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: "Christopher S. Aker" In-Reply-To: <20120511183012.GB21486@phenom.dumpdata.com> Date: Fri, 11 May 2012 18:40:12 -0400 Message-Id: <9B6030CC-6E1F-469E-8C97-8331222BF9CC@theshore.net> References: <4FA7EBF6.6040204@theshore.net> <20120511183012.GB21486@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On May 11, 2012, at 2:30 PM, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: >> Xen: 4.1.3-rc1-pre (xenbits @ 23285) > I just did this with 3.2.16 and didn't experience this. Can you > try 3.2.16 pls? > > I used the attached .config > <.config.txt> Thanks, but no joy with 3.2.16 and your config - only changes made were to build in a few drivers verses as modules to avoid initrd. Two boxes hit it out of a dozen in under an hour. [ 2152.285097] BUG: unable to handle kernel paging request at bffff3f0 [ 2152.285160] IP: [] __page_check_address+0xca/0x1b0 [ 2152.285238] *pdpt = 000000001b5ac027 *pde = 0000000000000000 [ 2152.285286] Oops: 0000 [#1] PREEMPT SMP [ 2152.285338] Modules linked in: dm_snapshot xen_evtchn xenfs ext2 dm_mod tpm_tis ata_generic ata_piix e1000e sg [ 2152.285468] [ 2152.285495] Pid: 506, comm: lvremove Tainted: G W 3.2.16 #4 Supermicro X8DT6/X8DT6 [ 2152.285572] EIP: 0061:[] EFLAGS: 00010246 CPU: 14 [ 2152.285607] EIP is at __page_check_address+0xca/0x1b0 [ 2152.285641] EAX: bffff000 EBX: dbe79dd8 ECX: 00000000 EDX: e2c00000 [ 2152.285678] ESI: bffff3f0 EDI: e33538e0 EBP: daf03e58 ESP: daf03e48 [ 2152.285715] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [ 2152.285750] Process lvremove (pid: 506, ti=daf02000 task=dd18a3e0 task.ti=daf02000) [ 2152.285804] Stack: [ 2152.285830] 00000fff e33538e0 dd1a5400 da4826c0 daf03e8c c1138b69 daf03e7c 00000000 [ 2152.285938] 00000124 00000000 c158df53 b767e000 00000000 b7686000 da4826c0 b767e000 [ 2152.286042] e33538e0 daf03f1c c11390e3 00000002 e2c00280 008c7025 daf03ebc c1037d59 [ 2152.286146] Call Trace: [ 2152.286178] [] try_to_unmap_one+0x29/0x370 [ 2152.286218] [] ? _raw_spin_unlock+0x13/0x40 [ 2152.286255] [] try_to_unmap_file+0x83/0x5a0 [ 2152.286295] [] ? xen_pte_val+0xb9/0x140 [ 2152.286332] [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [ 2152.286372] [] ? vm_normal_page+0x28/0xe0 [ 2152.286408] [] ? xen_pmd_val+0x6d/0xf0 [ 2152.286446] [] ? get_parent_ip+0xb/0x40 [ 2152.286482] [] try_to_munlock+0x1c/0x40 [ 2152.286518] [] munlock_vma_page+0x49/0x90 [ 2152.286582] [] munlock_vma_pages_range+0x6d/0xb0 [ 2152.286620] [] mlock_fixup+0xc7/0x130 [ 2152.286656] [] do_mlock+0x97/0xc0 [ 2152.286690] [] sys_munlock+0x42/0x60 [ 2152.286728] [] sysenter_do_call+0x12/0x28 [ 2152.286761] Code: e0 c4 76 c1 8b 04 85 c0 c4 76 c1 2b 90 b0 12 00 00 c1 e2 05 03 90 ac 12 00 00 89 d0 e8 b0 9e f3 ff 8b 4d 0c 85 c9 8d 34 30 75 0c 06 01 01 00 00 0f 84 ab 00 00 00 8b 03 8b 53 04 ff 15 14 25 [ 2152.287263] EIP: [] __page_check_address+0xca/0x1b0 SS:ESP 0069:daf03e48 [ 2152.287331] CR2: 00000000bffff3f0 [ 2152.287560] ---[ end trace a7919e7f17c0a74d ]--- [ 2152.287622] note: lvremove[506] exited with preempt_count 1 [ 2152.287685] BUG: sleeping function called from invalid context at kernel/rwsem.c:21 [ 2152.287767] in_atomic(): 1, irqs_disabled(): 0, pid: 506, name: lvremove [ 2152.287833] Pid: 506, comm: lvremove Tainted: G D W 3.2.16 #4 [ 2152.287897] Call Trace: [ 2152.287983] [] __might_sleep+0xe4/0x110 [ 2152.288047] [] down_read+0x17/0x30 [ 2152.288112] [] acct_collect+0x3a/0x160 [ 2152.288177] [] do_exit+0x65a/0x810 [ 2152.288240] [] ? kmsg_dump+0x98/0xc0 [ 2152.288303] [] oops_end+0x90/0xd0 [ 2152.288367] [] no_context+0xbe/0x190 [ 2152.288430] [] __bad_area_nosemaphore+0x98/0x140 [ 2152.288496] [] ? xen_clocksource_read+0x2c/0x60 [ 2152.288560] [] bad_area_nosemaphore+0x12/0x20 [ 2152.288625] [] do_page_fault+0x2b3/0x450 [ 2152.288690] [] ? handle_percpu_irq+0x34/0x50 [ 2152.288753] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.288819] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.288886] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 2152.288953] [] ? rcu_enter_nohz+0x4a/0x80 [ 2152.289017] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.289083] [] ? get_parent_ip+0xb/0x40 [ 2152.289145] [] ? sub_preempt_count+0x7b/0xb0 [ 2152.289209] [] ? spurious_fault+0x130/0x130 [ 2152.289273] [] error_code+0x67/0x6c [ 2152.289365] [] ? __page_check_address+0xca/0x1b0 [ 2152.289429] [] try_to_unmap_one+0x29/0x370 [ 2152.289494] [] ? _raw_spin_unlock+0x13/0x40 [ 2152.289558] [] try_to_unmap_file+0x83/0x5a0 [ 2152.289623] [] ? xen_pte_val+0xb9/0x140 [ 2152.289686] [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [ 2152.289752] [] ? vm_normal_page+0x28/0xe0 [ 2152.289816] [] ? xen_pmd_val+0x6d/0xf0 [ 2152.289879] [] ? get_parent_ip+0xb/0x40 [ 2152.289943] [] try_to_munlock+0x1c/0x40 [ 2152.291288] [] munlock_vma_page+0x49/0x90 [ 2152.291352] [] munlock_vma_pages_range+0x6d/0xb0 [ 2152.291417] [] mlock_fixup+0xc7/0x130 [ 2152.291479] [] do_mlock+0x97/0xc0 [ 2152.291542] [] sys_munlock+0x42/0x60 [ 2152.291606] [] sysenter_do_call+0x12/0x28 [ 2152.291759] Modules linked in: dm_snapshot xen_evtchn xenfs ext2 dm_mod tpm_tis ata_generic ata_piix e1000e sg [ 2152.292366] Pid: 506, comm: lvremove Tainted: G D W 3.2.16 #4 -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 22:40:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 22:40:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSyVV-0006OY-Kl; Fri, 11 May 2012 22:40:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSyVU-0006OT-Qp for xen-devel@lists.xensource.com; Fri, 11 May 2012 22:40:17 +0000 Received: from [85.158.143.35:26055] by server-1.bemta-4.messagelabs.com id D6/1D-20925-0559DAF4; Fri, 11 May 2012 22:40:16 +0000 X-Env-Sender: caker@theshore.net X-Msg-Ref: server-7.tower-21.messagelabs.com!1336776014!15677244!1 X-Originating-IP: [67.18.92.50] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18763 invoked from network); 11 May 2012 22:40:14 -0000 Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50) by server-7.tower-21.messagelabs.com with SMTP; 11 May 2012 22:40:14 -0000 Received: from [10.0.1.5] (c-68-44-174-16.hsd1.nj.comcast.net [68.44.174.16]) by www.theshore.net (8.13.6/8.9.1) with ESMTP id q4BMeCah004362; Fri, 11 May 2012 18:40:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: "Christopher S. Aker" In-Reply-To: <20120511183012.GB21486@phenom.dumpdata.com> Date: Fri, 11 May 2012 18:40:12 -0400 Message-Id: <9B6030CC-6E1F-469E-8C97-8331222BF9CC@theshore.net> References: <4FA7EBF6.6040204@theshore.net> <20120511183012.GB21486@phenom.dumpdata.com> To: Konrad Rzeszutek Wilk X-Mailer: Apple Mail (2.1084) Cc: xen devel Subject: Re: [Xen-devel] LVM userspace causing dom0 crash X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On May 11, 2012, at 2:30 PM, Konrad Rzeszutek Wilk wrote: > On Mon, May 07, 2012 at 11:36:22AM -0400, Christopher S. Aker wrote: >> Xen: 4.1.3-rc1-pre (xenbits @ 23285) > I just did this with 3.2.16 and didn't experience this. Can you > try 3.2.16 pls? > > I used the attached .config > <.config.txt> Thanks, but no joy with 3.2.16 and your config - only changes made were to build in a few drivers verses as modules to avoid initrd. Two boxes hit it out of a dozen in under an hour. [ 2152.285097] BUG: unable to handle kernel paging request at bffff3f0 [ 2152.285160] IP: [] __page_check_address+0xca/0x1b0 [ 2152.285238] *pdpt = 000000001b5ac027 *pde = 0000000000000000 [ 2152.285286] Oops: 0000 [#1] PREEMPT SMP [ 2152.285338] Modules linked in: dm_snapshot xen_evtchn xenfs ext2 dm_mod tpm_tis ata_generic ata_piix e1000e sg [ 2152.285468] [ 2152.285495] Pid: 506, comm: lvremove Tainted: G W 3.2.16 #4 Supermicro X8DT6/X8DT6 [ 2152.285572] EIP: 0061:[] EFLAGS: 00010246 CPU: 14 [ 2152.285607] EIP is at __page_check_address+0xca/0x1b0 [ 2152.285641] EAX: bffff000 EBX: dbe79dd8 ECX: 00000000 EDX: e2c00000 [ 2152.285678] ESI: bffff3f0 EDI: e33538e0 EBP: daf03e58 ESP: daf03e48 [ 2152.285715] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [ 2152.285750] Process lvremove (pid: 506, ti=daf02000 task=dd18a3e0 task.ti=daf02000) [ 2152.285804] Stack: [ 2152.285830] 00000fff e33538e0 dd1a5400 da4826c0 daf03e8c c1138b69 daf03e7c 00000000 [ 2152.285938] 00000124 00000000 c158df53 b767e000 00000000 b7686000 da4826c0 b767e000 [ 2152.286042] e33538e0 daf03f1c c11390e3 00000002 e2c00280 008c7025 daf03ebc c1037d59 [ 2152.286146] Call Trace: [ 2152.286178] [] try_to_unmap_one+0x29/0x370 [ 2152.286218] [] ? _raw_spin_unlock+0x13/0x40 [ 2152.286255] [] try_to_unmap_file+0x83/0x5a0 [ 2152.286295] [] ? xen_pte_val+0xb9/0x140 [ 2152.286332] [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [ 2152.286372] [] ? vm_normal_page+0x28/0xe0 [ 2152.286408] [] ? xen_pmd_val+0x6d/0xf0 [ 2152.286446] [] ? get_parent_ip+0xb/0x40 [ 2152.286482] [] try_to_munlock+0x1c/0x40 [ 2152.286518] [] munlock_vma_page+0x49/0x90 [ 2152.286582] [] munlock_vma_pages_range+0x6d/0xb0 [ 2152.286620] [] mlock_fixup+0xc7/0x130 [ 2152.286656] [] do_mlock+0x97/0xc0 [ 2152.286690] [] sys_munlock+0x42/0x60 [ 2152.286728] [] sysenter_do_call+0x12/0x28 [ 2152.286761] Code: e0 c4 76 c1 8b 04 85 c0 c4 76 c1 2b 90 b0 12 00 00 c1 e2 05 03 90 ac 12 00 00 89 d0 e8 b0 9e f3 ff 8b 4d 0c 85 c9 8d 34 30 75 0c 06 01 01 00 00 0f 84 ab 00 00 00 8b 03 8b 53 04 ff 15 14 25 [ 2152.287263] EIP: [] __page_check_address+0xca/0x1b0 SS:ESP 0069:daf03e48 [ 2152.287331] CR2: 00000000bffff3f0 [ 2152.287560] ---[ end trace a7919e7f17c0a74d ]--- [ 2152.287622] note: lvremove[506] exited with preempt_count 1 [ 2152.287685] BUG: sleeping function called from invalid context at kernel/rwsem.c:21 [ 2152.287767] in_atomic(): 1, irqs_disabled(): 0, pid: 506, name: lvremove [ 2152.287833] Pid: 506, comm: lvremove Tainted: G D W 3.2.16 #4 [ 2152.287897] Call Trace: [ 2152.287983] [] __might_sleep+0xe4/0x110 [ 2152.288047] [] down_read+0x17/0x30 [ 2152.288112] [] acct_collect+0x3a/0x160 [ 2152.288177] [] do_exit+0x65a/0x810 [ 2152.288240] [] ? kmsg_dump+0x98/0xc0 [ 2152.288303] [] oops_end+0x90/0xd0 [ 2152.288367] [] no_context+0xbe/0x190 [ 2152.288430] [] __bad_area_nosemaphore+0x98/0x140 [ 2152.288496] [] ? xen_clocksource_read+0x2c/0x60 [ 2152.288560] [] bad_area_nosemaphore+0x12/0x20 [ 2152.288625] [] do_page_fault+0x2b3/0x450 [ 2152.288690] [] ? handle_percpu_irq+0x34/0x50 [ 2152.288753] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.288819] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.288886] [] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 2152.288953] [] ? rcu_enter_nohz+0x4a/0x80 [ 2152.289017] [] ? xen_force_evtchn_callback+0x1a/0x30 [ 2152.289083] [] ? get_parent_ip+0xb/0x40 [ 2152.289145] [] ? sub_preempt_count+0x7b/0xb0 [ 2152.289209] [] ? spurious_fault+0x130/0x130 [ 2152.289273] [] error_code+0x67/0x6c [ 2152.289365] [] ? __page_check_address+0xca/0x1b0 [ 2152.289429] [] try_to_unmap_one+0x29/0x370 [ 2152.289494] [] ? _raw_spin_unlock+0x13/0x40 [ 2152.289558] [] try_to_unmap_file+0x83/0x5a0 [ 2152.289623] [] ? xen_pte_val+0xb9/0x140 [ 2152.289686] [] ? __raw_callee_save_xen_pte_val+0x6/0x8 [ 2152.289752] [] ? vm_normal_page+0x28/0xe0 [ 2152.289816] [] ? xen_pmd_val+0x6d/0xf0 [ 2152.289879] [] ? get_parent_ip+0xb/0x40 [ 2152.289943] [] try_to_munlock+0x1c/0x40 [ 2152.291288] [] munlock_vma_page+0x49/0x90 [ 2152.291352] [] munlock_vma_pages_range+0x6d/0xb0 [ 2152.291417] [] mlock_fixup+0xc7/0x130 [ 2152.291479] [] do_mlock+0x97/0xc0 [ 2152.291542] [] sys_munlock+0x42/0x60 [ 2152.291606] [] sysenter_do_call+0x12/0x28 [ 2152.291759] Modules linked in: dm_snapshot xen_evtchn xenfs ext2 dm_mod tpm_tis ata_generic ata_piix e1000e sg [ 2152.292366] Pid: 506, comm: lvremove Tainted: G D W 3.2.16 #4 -Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 23:21:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23: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 ) id 1SSz8R-0007Kc-4c; Fri, 11 May 2012 23:20:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSz8P-0007KX-NA for xen-devel@lists.xen.org; Fri, 11 May 2012 23:20:29 +0000 Received: from [85.158.143.35:26392] by server-2.bemta-4.messagelabs.com id 9C/8D-17550-DBE9DAF4; Fri, 11 May 2012 23:20:29 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336778427!8479488!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28120 invoked from network); 11 May 2012 23:20:27 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 23:20:27 -0000 Received: by werf3 with SMTP id f3so1744940wer.32 for ; Fri, 11 May 2012 16:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=InXuae00m5qOq7s4m0m2CplwgaOrheHyh+J5fZ0fHN4=; b=TJkw0vqafb5fMm8UsiktsYQ4W8WxfDKQZ2+uTaJbsq6H5TnZ+TOx4vcwB+1g5v4ZDe wvxyvc48Ea5pCI06CwvtRVIi2gc9hA3v0iV6zYy+DPYsqFFmTBFLw2MvGQUnjF0yITBv RpB2Zgwc0PBNS070HSGeSLYNCpwnbM7w5MQKB3MvIgBQNzmqWoEvWNHnWN3b0Hpg6t6V 8owPngsy03397c9aMtlb5qZv8zY5Z99FSsy9MswvWrVrqTGKmXvzPlcFGShx19P7QPgu 49k+05DdldR61j+E93An/PvZxWF/7QCBq6XM+Bw7nJeI+AOJlLANhW5QlrpOTC+ynygV 2iRg== Received: by 10.216.150.213 with SMTP id z63mr2635723wej.102.1336778427115; Fri, 11 May 2012 16:20:27 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id bn9sm14083376wib.5.2012.05.11.16.20.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 16:20:25 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 20943633a63e0691272bd940459c6c9c34e8f5c8 Message-Id: <20943633a63e0691272b.1336778417@Solace> User-Agent: Mercurial-patchbomb/2.2.1 Date: Sat, 12 May 2012 01:20:17 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xm supports the following syntax (in the config file) for specific VCPU to PCPU mapping: cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 Allow for the same to be done in xl. Signed-off-by: Dario Faggioli 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 @@ -71,6 +71,8 @@ static uint32_t domid; static const char *common_domname; static int fd_lock = -1; +/* Stash for specific vcpu to pcpu mappping */ +static int *vcpu_to_pcpu; static const char savefileheader_magic[32]= "Xen saved domain, xl format\n \0 \r"; @@ -630,6 +632,21 @@ static void parse_config_data(const char exit(1); } + /* Prepare the array for single vcpu to pcpu mappings */ + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); + + /* + * Idea here is to let libxl think all the domain's vcpus + * have cpu affinity with all the pcpus on the list. + * It is then us, here in xl, that matches each single vcpu + * to its pcpu (and that's why we need to stash such info in + * the vcpu_to_pcpu array now) after the domain has been created. + * Doing it like this saves the burden of passing to libxl + * some big array hosting the single mappings. Also, using + * the cpumap derived from the list ensures memory is being + * allocated on the proper nodes anyway. + */ libxl_cpumap_set_none(&b_info->cpumap); while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { i = atoi(buf); @@ -638,6 +655,8 @@ static void parse_config_data(const char exit(1); } libxl_cpumap_set(&b_info->cpumap, i); + if (n_cpus < b_info->max_vcpus) + vcpu_to_pcpu[n_cpus] = i; n_cpus++; } } @@ -1709,6 +1728,31 @@ start: if ( ret ) goto error_out; + /* If single vcpu to pcpu mapping was requested, honour it */ + if (vcpu_to_pcpu) { + libxl_cpumap vcpu_cpumap; + + libxl_cpumap_alloc(ctx, &vcpu_cpumap); + for (i = 0; i < d_config.b_info.max_vcpus; i++) { + + if (vcpu_to_pcpu[i] != -1) { + libxl_cpumap_set_none(&vcpu_cpumap); + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); + } else { + libxl_cpumap_set_any(&vcpu_cpumap); + } + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + ret = ERROR_FAIL; + goto error_out; + } + } + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + } + ret = libxl_userdata_store(ctx, domid, "xl", config_data, config_len); if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 23:21:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23: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 ) id 1SSz8R-0007Kc-4c; Fri, 11 May 2012 23:20:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSz8P-0007KX-NA for xen-devel@lists.xen.org; Fri, 11 May 2012 23:20:29 +0000 Received: from [85.158.143.35:26392] by server-2.bemta-4.messagelabs.com id 9C/8D-17550-DBE9DAF4; Fri, 11 May 2012 23:20:29 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1336778427!8479488!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28120 invoked from network); 11 May 2012 23:20:27 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 23:20:27 -0000 Received: by werf3 with SMTP id f3so1744940wer.32 for ; Fri, 11 May 2012 16:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=InXuae00m5qOq7s4m0m2CplwgaOrheHyh+J5fZ0fHN4=; b=TJkw0vqafb5fMm8UsiktsYQ4W8WxfDKQZ2+uTaJbsq6H5TnZ+TOx4vcwB+1g5v4ZDe wvxyvc48Ea5pCI06CwvtRVIi2gc9hA3v0iV6zYy+DPYsqFFmTBFLw2MvGQUnjF0yITBv RpB2Zgwc0PBNS070HSGeSLYNCpwnbM7w5MQKB3MvIgBQNzmqWoEvWNHnWN3b0Hpg6t6V 8owPngsy03397c9aMtlb5qZv8zY5Z99FSsy9MswvWrVrqTGKmXvzPlcFGShx19P7QPgu 49k+05DdldR61j+E93An/PvZxWF/7QCBq6XM+Bw7nJeI+AOJlLANhW5QlrpOTC+ynygV 2iRg== Received: by 10.216.150.213 with SMTP id z63mr2635723wej.102.1336778427115; Fri, 11 May 2012 16:20:27 -0700 (PDT) Received: from [127.0.1.1] (ip-182-223.sn1.eutelia.it. [62.94.182.223]) by mx.google.com with ESMTPS id bn9sm14083376wib.5.2012.05.11.16.20.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 16:20:25 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 20943633a63e0691272bd940459c6c9c34e8f5c8 Message-Id: <20943633a63e0691272b.1336778417@Solace> User-Agent: Mercurial-patchbomb/2.2.1 Date: Sat, 12 May 2012 01:20:17 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xm supports the following syntax (in the config file) for specific VCPU to PCPU mapping: cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 Allow for the same to be done in xl. Signed-off-by: Dario Faggioli 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 @@ -71,6 +71,8 @@ static uint32_t domid; static const char *common_domname; static int fd_lock = -1; +/* Stash for specific vcpu to pcpu mappping */ +static int *vcpu_to_pcpu; static const char savefileheader_magic[32]= "Xen saved domain, xl format\n \0 \r"; @@ -630,6 +632,21 @@ static void parse_config_data(const char exit(1); } + /* Prepare the array for single vcpu to pcpu mappings */ + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); + + /* + * Idea here is to let libxl think all the domain's vcpus + * have cpu affinity with all the pcpus on the list. + * It is then us, here in xl, that matches each single vcpu + * to its pcpu (and that's why we need to stash such info in + * the vcpu_to_pcpu array now) after the domain has been created. + * Doing it like this saves the burden of passing to libxl + * some big array hosting the single mappings. Also, using + * the cpumap derived from the list ensures memory is being + * allocated on the proper nodes anyway. + */ libxl_cpumap_set_none(&b_info->cpumap); while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { i = atoi(buf); @@ -638,6 +655,8 @@ static void parse_config_data(const char exit(1); } libxl_cpumap_set(&b_info->cpumap, i); + if (n_cpus < b_info->max_vcpus) + vcpu_to_pcpu[n_cpus] = i; n_cpus++; } } @@ -1709,6 +1728,31 @@ start: if ( ret ) goto error_out; + /* If single vcpu to pcpu mapping was requested, honour it */ + if (vcpu_to_pcpu) { + libxl_cpumap vcpu_cpumap; + + libxl_cpumap_alloc(ctx, &vcpu_cpumap); + for (i = 0; i < d_config.b_info.max_vcpus; i++) { + + if (vcpu_to_pcpu[i] != -1) { + libxl_cpumap_set_none(&vcpu_cpumap); + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); + } else { + libxl_cpumap_set_any(&vcpu_cpumap); + } + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + ret = ERROR_FAIL; + goto error_out; + } + } + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + } + ret = libxl_userdata_store(ctx, domid, "xl", config_data, config_len); if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri May 11 23:24:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23:24:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSzBb-0007QL-QH; Fri, 11 May 2012 23:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSzBa-0007QC-BR for xen-devel@lists.xen.org; Fri, 11 May 2012 23:23:46 +0000 Received: from [85.158.143.99:22435] by server-3.bemta-4.messagelabs.com id A3/ED-05853-18F9DAF4; Fri, 11 May 2012 23:23:45 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-2.tower-216.messagelabs.com!1336778624!22304758!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6639 invoked from network); 11 May 2012 23:23:44 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-2.tower-216.messagelabs.com with SMTP; 11 May 2012 23:23:44 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77810963; Sat, 12 May 2012 01:23:43 +0200 Message-ID: <1336778609.27081.1.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Sat, 12 May 2012 01:23:29 +0200 In-Reply-To: <20943633a63e0691272b.1336778417@Solace> References: <20943633a63e0691272b.1336778417@Solace> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7115100927558285491==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7115100927558285491== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MwjyKRp4azlLmCvBx/79" --=-MwjyKRp4azlLmCvBx/79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote:=20 > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: >=20 > cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 >=20 > Allow for the same to be done in xl. >=20 And yes, I'm proposing this for 4.2, as not having it is a feature parity between xm and xl bug someone reported on @xen-users. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-MwjyKRp4azlLmCvBx/79 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+tn3EACgkQk4XaBE3IOsRTGgCfbDgcCEB9BtvVynZBioj8DceT GkUAnR6v2LaWN88BlC0Bq7qn84yiV8hC =cbeX -----END PGP SIGNATURE----- --=-MwjyKRp4azlLmCvBx/79-- --===============7115100927558285491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7115100927558285491==-- From xen-devel-bounces@lists.xen.org Fri May 11 23:24:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23:24:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSzBb-0007QL-QH; Fri, 11 May 2012 23:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSzBa-0007QC-BR for xen-devel@lists.xen.org; Fri, 11 May 2012 23:23:46 +0000 Received: from [85.158.143.99:22435] by server-3.bemta-4.messagelabs.com id A3/ED-05853-18F9DAF4; Fri, 11 May 2012 23:23:45 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-2.tower-216.messagelabs.com!1336778624!22304758!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6639 invoked from network); 11 May 2012 23:23:44 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-2.tower-216.messagelabs.com with SMTP; 11 May 2012 23:23:44 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77810963; Sat, 12 May 2012 01:23:43 +0200 Message-ID: <1336778609.27081.1.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Sat, 12 May 2012 01:23:29 +0200 In-Reply-To: <20943633a63e0691272b.1336778417@Solace> References: <20943633a63e0691272b.1336778417@Solace> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7115100927558285491==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7115100927558285491== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MwjyKRp4azlLmCvBx/79" --=-MwjyKRp4azlLmCvBx/79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote:=20 > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: >=20 > cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 >=20 > Allow for the same to be done in xl. >=20 And yes, I'm proposing this for 4.2, as not having it is a feature parity between xm and xl bug someone reported on @xen-users. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-MwjyKRp4azlLmCvBx/79 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+tn3EACgkQk4XaBE3IOsRTGgCfbDgcCEB9BtvVynZBioj8DceT GkUAnR6v2LaWN88BlC0Bq7qn84yiV8hC =cbeX -----END PGP SIGNATURE----- --=-MwjyKRp4azlLmCvBx/79-- --===============7115100927558285491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7115100927558285491==-- From xen-devel-bounces@lists.xen.org Fri May 11 23:53:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23:53:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSze7-0007iy-AM; Fri, 11 May 2012 23:53:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSze5-0007iq-7g for xen-devel@lists.xen.org; Fri, 11 May 2012 23:53:13 +0000 Received: from [85.158.143.99:27233] by server-1.bemta-4.messagelabs.com id D8/16-20925-866ADAF4; Fri, 11 May 2012 23:53:12 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336780389!22347175!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24442 invoked from network); 11 May 2012 23:53:10 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 23:53:10 -0000 Received: by pbbro12 with SMTP id ro12so4202148pbb.32 for ; Fri, 11 May 2012 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNfcSANEwjGY2FleqJky+Coe8OKzqV/Q8xuxwLywkBY=; b=FNz4v8tQbfnS9vmC84SfW+3pfUnO1ykw8kad1EsStFVvH8nLT476SGFn4BHR9+zd6W ivaqWZfmgKbDWnMoc+uWTcE1T5LcXDhJtY4//Wnd/U1VCo1s5hLvC1alKRar9UMmKhDe LUPvNWbbkL2HlTo8LTwfj+lb6E6nCgxRxyH+Ur8pPO26wEffs4Lb2H6sVdQMTzSc0rne +3rsaYONUfJcEK4n9wXIIqQ5J5gbeCyw/Cui9v49d1yTazOCpt/fRe68zVuxtXqeqtB6 kMhD8VNgd5IwHYwS3acwMYYSyMh9743Z/CY2sugK6NEqaH8DTfGEznNT/rLjmBSmN9Es vIUA== MIME-Version: 1.0 Received: by 10.68.228.195 with SMTP id sk3mr217478pbc.20.1336780388181; Fri, 11 May 2012 16:53:08 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Fri, 11 May 2012 16:53:07 -0700 (PDT) In-Reply-To: <20397.10224.96552.711065@mariner.uk.xensource.com> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sat, 12 May 2012 07:53:07 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Content-Type: multipart/mixed; boundary=047d7b2eda632e25c404bfcb70c5 Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --047d7b2eda632e25c404bfcb70c5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): >> libxl/xend: name tap devices vifX.Y-emu > > Committed-by: Ian Jackson This is my backport version which excludes the following: Lastly also move libxl__device_* to a better place in the header, otherwise the comment about evgen stuff isn't next to the associated functions (noticed jsut because I was going to add nic_devname near to the setdefault functions) I have tested with xm and xl with and without vifname set in domU config for hvmdomain and pvdomain. For your review and comments please. Thanks. Kindest regards, Giam Teck Choon libxl/xend: name tap devices vifX.Y-emu This prevents the udev scripts from operating on other tap devices (e.g. openvpn etc) Correct the documentation for the "vifname" option which suggested it applied to HVM tap devices only, which is not the case. Reported by Michael Young. Also fix the use of vifname with emulated devices. This is slightly complex. The current hotplug scripts rely on being able to parse the "tapX.Y" (now "vifX.Y-emu") name in order to locate the xenstore backend dir relating to the corresponding vif. This is because we cannot inject our own environment vars into the tap hotplug events. However this means that if the tap is initially named with a user specified name (which will not match the expected scheme) we fail to do anything useful with the device. So now we create the initial tap device with the standard "vifX.Y-emu" name and the hotplug script will handle the rename to the desired name. This is also how PV vif devices work -- they are always created by netback with the name vifX.Y and renamed in the script. xen-unstable changeset: 25290:7a6dcecb1781 Signed-off-by: Giam Teck Choon --- tools/hotplug/Linux/vif-common.sh | 15 +++++++++++++-- tools/hotplug/Linux/xen-backend.rules | 2 +- tools/libxl/libxl_dm.c | 17 ++++++----------- tools/python/xen/xend/image.py | 6 +----- 4 files changed, 21 insertions(+), 19 deletions(-) diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh index c9c5d41..fff22bb 100644 --- a/tools/hotplug/Linux/vif-common.sh +++ b/tools/hotplug/Linux/vif-common.sh @@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then : ${INTERFACE:?} # Get xenbus_path from device name. - # The name is built like that: "tap${domid}.${devid}". - dev_=${dev#tap} + # The name is built like that: "vif${domid}.${devid}-emu". + dev_=${dev#vif} + dev_=${dev_%-emu} domid=${dev_%.*} devid=${dev_#*.} XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid" + vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "") + if [ "$vifname" ] + then + vifname="${vifname}-emu" + if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null + then + do_or_die ip link set "$dev" name "$vifname" + fi + dev="$vifname" + fi fi ip=${ip:-} diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index 40f2658..405387f 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600" KERNEL=="gntdev", NAME="xen/%k", MODE="0600" KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" -SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 1ffcc90..2c030ca 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -134,11 +134,9 @@ static char ** libxl_build_device_model_args_old(libxl__gc *gc, char *smac = libxl__sprintf(gc, "%02x:%02x:%02x:%02x:%02x:%02x", vifs[i].mac[0], vifs[i].mac[1], vifs[i].mac[2], vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]); - char *ifname; - if (!vifs[i].ifname) - ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid); - else - ifname = vifs[i].ifname; + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", + info->domid, + vifs[i].devid); flexarray_vappend(dm_args, "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model), @@ -271,12 +269,9 @@ static char ** libxl_build_device_model_args_new(libxl__gc *gc, char *smac = libxl__sprintf(gc, "%02x:%02x:%02x:%02x:%02x:%02x", vifs[i].mac[0], vifs[i].mac[1], vifs[i].mac[2], vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]); - char *ifname; - if (!vifs[i].ifname) { - ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid); - } else { - ifname = vifs[i].ifname; - } + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", + info->domid, + vifs[i].devid); flexarray_append(dm_args, "-net"); flexarray_append(dm_args, libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model)); diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py index f1464ac..3c8d80c 100644 --- a/tools/python/xen/xend/image.py +++ b/tools/python/xen/xend/image.py @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): ret.append("-net") ret.append("nic,vlan=%d,macaddr=%s,model=%s" % (nics, mac, model)) - vifname = devinfo.get('vifname') - if vifname: - vifname = "tap-" + vifname - else: - vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1) + vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1) ret.append("-net") ret.append("tap,vlan=%d,ifname=%s,bridge=%s" % (nics, vifname, bridge)) --047d7b2eda632e25c404bfcb70c5 Content-Type: application/octet-stream; name="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Disposition: attachment; filename="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h23wier60 bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB2aWZYLlktZW11CgpUaGlzIHByZXZlbnRzIHRo ZSB1ZGV2IHNjcmlwdHMgZnJvbSBvcGVyYXRpbmcgb24gb3RoZXIgdGFwIGRldmljZXMgKGUuZy4K b3BlbnZwbiBldGMpCgpDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgInZpZm5hbWUi IG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25s eSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLgoKUmVwb3J0ZWQgYnkgTWljaGFlbCBZb3VuZy4KCkFs c28gZml4IHRoZSB1c2Ugb2YgdmlmbmFtZSB3aXRoIGVtdWxhdGVkIGRldmljZXMuIFRoaXMgaXMg c2xpZ2h0bHkgY29tcGxleC4KVGhlIGN1cnJlbnQgaG90cGx1ZyBzY3JpcHRzIHJlbHkgb24gYmVp bmcgYWJsZSB0byBwYXJzZSB0aGUgInRhcFguWSIgKG5vdwoidmlmWC5ZLWVtdSIpIG5hbWUgaW4g b3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBiYWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUK Y29ycmVzcG9uZGluZyB2aWYuIFRoaXMgaXMgYmVjYXVzZSB3ZSBjYW5ub3QgaW5qZWN0IG91ciBv d24gZW52aXJvbm1lbnQgdmFycwppbnRvIHRoZSB0YXAgaG90cGx1ZyBldmVudHMuIEhvd2V2ZXIg dGhpcyBtZWFucyB0aGF0IGlmIHRoZSB0YXAgaXMgaW5pdGlhbGx5Cm5hbWVkIHdpdGggYSB1c2Vy IHNwZWNpZmllZCBuYW1lICh3aGljaCB3aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1l KSB3ZQpmYWlsIHRvIGRvIGFueXRoaW5nIHVzZWZ1bCB3aXRoIHRoZSBkZXZpY2UuIFNvIG5vdyB3 ZSBjcmVhdGUgdGhlIGluaXRpYWwgdGFwCmRldmljZSB3aXRoIHRoZSBzdGFuZGFyZCAidmlmWC5Z LWVtdSIgbmFtZSBhbmQgdGhlIGhvdHBsdWcgc2NyaXB0IHdpbGwgaGFuZGxlCnRoZSByZW5hbWUg dG8gdGhlIGRlc2lyZWQgbmFtZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3Jr IC0tIHRoZXkKYXJlIGFsd2F5cyBjcmVhdGVkIGJ5IG5ldGJhY2sgd2l0aCB0aGUgbmFtZSB2aWZY LlkgYW5kIHJlbmFtZWQgaW4gdGhlIHNjcmlwdC4KCnhlbi11bnN0YWJsZSBjaGFuZ2VzZXQ6IDI1 MjkwOjdhNmRjZWNiMTc4MQpTaWduZWQtb2ZmLWJ5OiBHaWFtIFRlY2sgQ2hvb24gPGdpYW10ZWNr Y2hvb25AZ21haWwuY29tPgotLS0KIHRvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaCAg ICAgfCAgIDE1ICsrKysrKysrKysrKystLQogdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2Vu ZC5ydWxlcyB8ICAgIDIgKy0KIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMgICAgICAgICAgICAgICAg fCAgIDE3ICsrKysrKy0tLS0tLS0tLS0tCiB0b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkg ICAgICAgIHwgICAgNiArLS0tLS0KIDQgZmlsZXMgY2hhbmdlZCwgMjEgaW5zZXJ0aW9ucygrKSwg MTkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29t bW9uLnNoIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNoCmluZGV4IGM5YzVkNDEu LmZmZjIyYmIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaAor KysgYi90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gKQEAgLTg1LDEyICs4NSwyMyBA QCBlbGlmIFsgIiR0eXBlX2lmIiA9IHRhcCBdOyB0aGVuCiAgICAgOiAke0lOVEVSRkFDRTo/fQog CiAgICAgIyBHZXQgeGVuYnVzX3BhdGggZnJvbSBkZXZpY2UgbmFtZS4KLSAgICAjIFRoZSBuYW1l IGlzIGJ1aWx0IGxpa2UgdGhhdDogInRhcCR7ZG9taWR9LiR7ZGV2aWR9Ii4KLSAgICBkZXZfPSR7 ZGV2I3RhcH0KKyAgICAjIFRoZSBuYW1lIGlzIGJ1aWx0IGxpa2UgdGhhdDogInZpZiR7ZG9taWR9 LiR7ZGV2aWR9LWVtdSIuCisgICAgZGV2Xz0ke2RldiN2aWZ9CisgICAgZGV2Xz0ke2Rldl8lLWVt dX0KICAgICBkb21pZD0ke2Rldl8lLip9CiAgICAgZGV2aWQ9JHtkZXZfIyoufQogCiAgICAgWEVO QlVTX1BBVEg9Ii9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8kZG9taWQvJGRldmlkIgorICAg IHZpZm5hbWU9JCh4ZW5zdG9yZV9yZWFkX2RlZmF1bHQgIiRYRU5CVVNfUEFUSC92aWZuYW1lIiAi IikKKyAgICBpZiBbICIkdmlmbmFtZSIgXQorICAgIHRoZW4KKyAgICAgICAgdmlmbmFtZT0iJHt2 aWZuYW1lfS1lbXUiCisgICAgICAgIGlmIFsgIiRjb21tYW5kIiA9PSAiYWRkIiBdICYmICEgaXAg bGluayBzaG93ICIkdmlmbmFtZSIgPiYvZGV2L251bGwKKyAgICAgICAgdGhlbgorICAgICAgICAg ICAgZG9fb3JfZGllIGlwIGxpbmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKKyAgICAgICAg ZmkKKyAgICAgICAgZGV2PSIkdmlmbmFtZSIKKyAgICBmaQogZmkKIAogaXA9JHtpcDotfQpkaWZm IC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcyBiL3Rvb2xzL2hv dHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKaW5kZXggNDBmMjY1OC4uNDA1Mzg3ZiAxMDA2 NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcworKysgYi90b29s cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzCkBAIC0xMyw0ICsxMyw0IEBAIEtFUk5F TD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3RhcC0yL2NvbnRyb2wiLCBNT0RFPSIw NjAwIgogS0VSTkVMPT0iZ250ZGV2IiwgTkFNRT0ieGVuLyVrIiwgTU9ERT0iMDYwMCIKIEtFUk5F TD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCiBLRVJORUw9PSJ0YXBk ZXZbYS16XSoiLCBOQU1FPSJ4ZW4vYmxrdGFwLTIvdGFwZGV2JW0iLCBNT0RFPSIwNjAwIgotU1VC U1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElPTj09ImFkZCIsIFJVTis9Ii9ldGMv eGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0eXBlX2lmPXRhcCIKK1NVQlNZU1RF TT09Im5ldCIsIEtFUk5FTD09InZpZiotZW11IiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0iL2V0Yy94 ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5cGVfaWY9dGFwIgpkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKaW5kZXgg MWZmY2M5MC4uMmMwMzBjYSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysg Yi90b29scy9saWJ4bC9saWJ4bF9kbS5jCkBAIC0xMzQsMTEgKzEzNCw5IEBAIHN0YXRpYyBjaGFy ICoqIGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX29sZChsaWJ4bF9fZ2MgKmdjLAogICAg ICAgICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3ByaW50ZihnYywgIiUwMng6JTAyeDol MDJ4OiUwMng6JTAyeDolMDJ4IiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB2aWZzW2ldLm1hY1swXSwgdmlmc1tpXS5tYWNbMV0sIHZpZnNbaV0ubWFjWzJdLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzNd LCB2aWZzW2ldLm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwotICAgICAgICAgICAgICAgIGNoYXIg KmlmbmFtZTsKLSAgICAgICAgICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKQotICAgICAgICAg ICAgICAgICAgICBpZm5hbWUgPSBsaWJ4bF9fc3ByaW50ZihnYywgInRhcCVkLiVkIiwgaW5mby0+ ZG9taWQsIHZpZnNbaV0uZGV2aWQpOwotICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAg ICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7CisgICAgICAgICAgICAgICAgY29uc3Qg Y2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2aWYlZC4lZC1lbXUiLAorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPmRvbWlk LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZp ZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3Ms CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICItbmV0IiwgbGlieGxfX3NwcmludGYo Z2MsICJuaWMsdmxhbj0lZCxtYWNhZGRyPSVzLG1vZGVsPSVzIiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWZzW2ldLmRldmlkLCBzbWFj LCB2aWZzW2ldLm1vZGVsKSwKQEAgLTI3MSwxMiArMjY5LDkgQEAgc3RhdGljIGNoYXIgKiogbGli eGxfYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3KGxpYnhsX19nYyAqZ2MsCiAgICAgICAgICAg ICAgICAgY2hhciAqc21hYyA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJTAyeDolMDJ4OiUwMng6JTAy eDolMDJ4OiUwMngiLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHZpZnNbaV0ubWFjWzBdLCB2aWZzW2ldLm1hY1sxXSwgdmlmc1tpXS5tYWNbMl0sCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5tYWNbM10sIHZpZnNb aV0ubWFjWzRdLCB2aWZzW2ldLm1hY1s1XSk7Ci0gICAgICAgICAgICAgICAgY2hhciAqaWZuYW1l OwotICAgICAgICAgICAgICAgIGlmICghdmlmc1tpXS5pZm5hbWUpIHsKLSAgICAgICAgICAgICAg ICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ0YXAlZC4lZCIsIGluZm8tPmRvbWlk LCB2aWZzW2ldLmRldmlkKTsKLSAgICAgICAgICAgICAgICB9IGVsc2UgewotICAgICAgICAgICAg ICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKLSAgICAgICAgICAgICAgICB9CisgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2aWYl ZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhhcnJh eV9hcHBlbmQoZG1fYXJncywgIi1uZXQiKTsKICAgICAgICAgICAgICAgICBmbGV4YXJyYXlfYXBw ZW5kKGRtX2FyZ3MsIGxpYnhsX19zcHJpbnRmKGdjLCAibmljLHZsYW49JWQsbWFjYWRkcj0lcyxt b2RlbD0lcyIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5kZXZpZCwgc21h Yywgdmlmc1tpXS5tb2RlbCkpOwpkaWZmIC0tZ2l0IGEvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2lt YWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5CmluZGV4IGYxNDY0YWMuLjNj OGQ4MGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5weQorKysgYi90 b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkxNywxMSArOTE3LDcgQEAgY2xhc3Mg SFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6CiAgICAgICAgICAgICByZXQuYXBwZW5kKCIt bmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2bGFuPSVkLG1hY2FkZHI9JXMsbW9k ZWw9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIG1hYywgbW9kZWwpKQotICAg ICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8uZ2V0KCd2aWZuYW1lJykKLSAgICAgICAgICAgIGlm IHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9ICJ0YXAtIiArIHZpZm5hbWUKLSAg ICAgICAgICAgIGVsc2U6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9ICJ0YXAlZC4lZCIgJSAo c2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCisgICAgICAgICAgICB2aWZuYW1lID0gInZpZiVk LiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCiAgICAgICAgICAgICByZXQu YXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoInRhcCx2bGFuPSVkLGlmbmFt ZT0lcyxicmlkZ2U9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIHZpZm5hbWUs IGJyaWRnZSkpCg== --047d7b2eda632e25c404bfcb70c5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --047d7b2eda632e25c404bfcb70c5-- From xen-devel-bounces@lists.xen.org Fri May 11 23:53:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 May 2012 23:53:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSze7-0007iy-AM; Fri, 11 May 2012 23:53:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SSze5-0007iq-7g for xen-devel@lists.xen.org; Fri, 11 May 2012 23:53:13 +0000 Received: from [85.158.143.99:27233] by server-1.bemta-4.messagelabs.com id D8/16-20925-866ADAF4; Fri, 11 May 2012 23:53:12 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1336780389!22347175!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24442 invoked from network); 11 May 2012 23:53:10 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 May 2012 23:53:10 -0000 Received: by pbbro12 with SMTP id ro12so4202148pbb.32 for ; Fri, 11 May 2012 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNfcSANEwjGY2FleqJky+Coe8OKzqV/Q8xuxwLywkBY=; b=FNz4v8tQbfnS9vmC84SfW+3pfUnO1ykw8kad1EsStFVvH8nLT476SGFn4BHR9+zd6W ivaqWZfmgKbDWnMoc+uWTcE1T5LcXDhJtY4//Wnd/U1VCo1s5hLvC1alKRar9UMmKhDe LUPvNWbbkL2HlTo8LTwfj+lb6E6nCgxRxyH+Ur8pPO26wEffs4Lb2H6sVdQMTzSc0rne +3rsaYONUfJcEK4n9wXIIqQ5J5gbeCyw/Cui9v49d1yTazOCpt/fRe68zVuxtXqeqtB6 kMhD8VNgd5IwHYwS3acwMYYSyMh9743Z/CY2sugK6NEqaH8DTfGEznNT/rLjmBSmN9Es vIUA== MIME-Version: 1.0 Received: by 10.68.228.195 with SMTP id sk3mr217478pbc.20.1336780388181; Fri, 11 May 2012 16:53:08 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Fri, 11 May 2012 16:53:07 -0700 (PDT) In-Reply-To: <20397.10224.96552.711065@mariner.uk.xensource.com> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sat, 12 May 2012 07:53:07 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Content-Type: multipart/mixed; boundary=047d7b2eda632e25c404bfcb70c5 Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --047d7b2eda632e25c404bfcb70c5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): >> libxl/xend: name tap devices vifX.Y-emu > > Committed-by: Ian Jackson This is my backport version which excludes the following: Lastly also move libxl__device_* to a better place in the header, otherwise the comment about evgen stuff isn't next to the associated functions (noticed jsut because I was going to add nic_devname near to the setdefault functions) I have tested with xm and xl with and without vifname set in domU config for hvmdomain and pvdomain. For your review and comments please. Thanks. Kindest regards, Giam Teck Choon libxl/xend: name tap devices vifX.Y-emu This prevents the udev scripts from operating on other tap devices (e.g. openvpn etc) Correct the documentation for the "vifname" option which suggested it applied to HVM tap devices only, which is not the case. Reported by Michael Young. Also fix the use of vifname with emulated devices. This is slightly complex. The current hotplug scripts rely on being able to parse the "tapX.Y" (now "vifX.Y-emu") name in order to locate the xenstore backend dir relating to the corresponding vif. This is because we cannot inject our own environment vars into the tap hotplug events. However this means that if the tap is initially named with a user specified name (which will not match the expected scheme) we fail to do anything useful with the device. So now we create the initial tap device with the standard "vifX.Y-emu" name and the hotplug script will handle the rename to the desired name. This is also how PV vif devices work -- they are always created by netback with the name vifX.Y and renamed in the script. xen-unstable changeset: 25290:7a6dcecb1781 Signed-off-by: Giam Teck Choon --- tools/hotplug/Linux/vif-common.sh | 15 +++++++++++++-- tools/hotplug/Linux/xen-backend.rules | 2 +- tools/libxl/libxl_dm.c | 17 ++++++----------- tools/python/xen/xend/image.py | 6 +----- 4 files changed, 21 insertions(+), 19 deletions(-) diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh index c9c5d41..fff22bb 100644 --- a/tools/hotplug/Linux/vif-common.sh +++ b/tools/hotplug/Linux/vif-common.sh @@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then : ${INTERFACE:?} # Get xenbus_path from device name. - # The name is built like that: "tap${domid}.${devid}". - dev_=${dev#tap} + # The name is built like that: "vif${domid}.${devid}-emu". + dev_=${dev#vif} + dev_=${dev_%-emu} domid=${dev_%.*} devid=${dev_#*.} XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid" + vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "") + if [ "$vifname" ] + then + vifname="${vifname}-emu" + if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null + then + do_or_die ip link set "$dev" name "$vifname" + fi + dev="$vifname" + fi fi ip=${ip:-} diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules index 40f2658..405387f 100644 --- a/tools/hotplug/Linux/xen-backend.rules +++ b/tools/hotplug/Linux/xen-backend.rules @@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600" KERNEL=="gntdev", NAME="xen/%k", MODE="0600" KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" -SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 1ffcc90..2c030ca 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -134,11 +134,9 @@ static char ** libxl_build_device_model_args_old(libxl__gc *gc, char *smac = libxl__sprintf(gc, "%02x:%02x:%02x:%02x:%02x:%02x", vifs[i].mac[0], vifs[i].mac[1], vifs[i].mac[2], vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]); - char *ifname; - if (!vifs[i].ifname) - ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid); - else - ifname = vifs[i].ifname; + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", + info->domid, + vifs[i].devid); flexarray_vappend(dm_args, "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model), @@ -271,12 +269,9 @@ static char ** libxl_build_device_model_args_new(libxl__gc *gc, char *smac = libxl__sprintf(gc, "%02x:%02x:%02x:%02x:%02x:%02x", vifs[i].mac[0], vifs[i].mac[1], vifs[i].mac[2], vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]); - char *ifname; - if (!vifs[i].ifname) { - ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid); - } else { - ifname = vifs[i].ifname; - } + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", + info->domid, + vifs[i].devid); flexarray_append(dm_args, "-net"); flexarray_append(dm_args, libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s", vifs[i].devid, smac, vifs[i].model)); diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py index f1464ac..3c8d80c 100644 --- a/tools/python/xen/xend/image.py +++ b/tools/python/xen/xend/image.py @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): ret.append("-net") ret.append("nic,vlan=%d,macaddr=%s,model=%s" % (nics, mac, model)) - vifname = devinfo.get('vifname') - if vifname: - vifname = "tap-" + vifname - else: - vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1) + vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1) ret.append("-net") ret.append("tap,vlan=%d,ifname=%s,bridge=%s" % (nics, vifname, bridge)) --047d7b2eda632e25c404bfcb70c5 Content-Type: application/octet-stream; name="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Disposition: attachment; filename="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h23wier60 bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB2aWZYLlktZW11CgpUaGlzIHByZXZlbnRzIHRo ZSB1ZGV2IHNjcmlwdHMgZnJvbSBvcGVyYXRpbmcgb24gb3RoZXIgdGFwIGRldmljZXMgKGUuZy4K b3BlbnZwbiBldGMpCgpDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgInZpZm5hbWUi IG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25s eSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLgoKUmVwb3J0ZWQgYnkgTWljaGFlbCBZb3VuZy4KCkFs c28gZml4IHRoZSB1c2Ugb2YgdmlmbmFtZSB3aXRoIGVtdWxhdGVkIGRldmljZXMuIFRoaXMgaXMg c2xpZ2h0bHkgY29tcGxleC4KVGhlIGN1cnJlbnQgaG90cGx1ZyBzY3JpcHRzIHJlbHkgb24gYmVp bmcgYWJsZSB0byBwYXJzZSB0aGUgInRhcFguWSIgKG5vdwoidmlmWC5ZLWVtdSIpIG5hbWUgaW4g b3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBiYWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUK Y29ycmVzcG9uZGluZyB2aWYuIFRoaXMgaXMgYmVjYXVzZSB3ZSBjYW5ub3QgaW5qZWN0IG91ciBv d24gZW52aXJvbm1lbnQgdmFycwppbnRvIHRoZSB0YXAgaG90cGx1ZyBldmVudHMuIEhvd2V2ZXIg dGhpcyBtZWFucyB0aGF0IGlmIHRoZSB0YXAgaXMgaW5pdGlhbGx5Cm5hbWVkIHdpdGggYSB1c2Vy IHNwZWNpZmllZCBuYW1lICh3aGljaCB3aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1l KSB3ZQpmYWlsIHRvIGRvIGFueXRoaW5nIHVzZWZ1bCB3aXRoIHRoZSBkZXZpY2UuIFNvIG5vdyB3 ZSBjcmVhdGUgdGhlIGluaXRpYWwgdGFwCmRldmljZSB3aXRoIHRoZSBzdGFuZGFyZCAidmlmWC5Z LWVtdSIgbmFtZSBhbmQgdGhlIGhvdHBsdWcgc2NyaXB0IHdpbGwgaGFuZGxlCnRoZSByZW5hbWUg dG8gdGhlIGRlc2lyZWQgbmFtZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3Jr IC0tIHRoZXkKYXJlIGFsd2F5cyBjcmVhdGVkIGJ5IG5ldGJhY2sgd2l0aCB0aGUgbmFtZSB2aWZY LlkgYW5kIHJlbmFtZWQgaW4gdGhlIHNjcmlwdC4KCnhlbi11bnN0YWJsZSBjaGFuZ2VzZXQ6IDI1 MjkwOjdhNmRjZWNiMTc4MQpTaWduZWQtb2ZmLWJ5OiBHaWFtIFRlY2sgQ2hvb24gPGdpYW10ZWNr Y2hvb25AZ21haWwuY29tPgotLS0KIHRvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaCAg ICAgfCAgIDE1ICsrKysrKysrKysrKystLQogdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2Vu ZC5ydWxlcyB8ICAgIDIgKy0KIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMgICAgICAgICAgICAgICAg fCAgIDE3ICsrKysrKy0tLS0tLS0tLS0tCiB0b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkg ICAgICAgIHwgICAgNiArLS0tLS0KIDQgZmlsZXMgY2hhbmdlZCwgMjEgaW5zZXJ0aW9ucygrKSwg MTkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29t bW9uLnNoIGIvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNoCmluZGV4IGM5YzVkNDEu LmZmZjIyYmIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaAor KysgYi90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gKQEAgLTg1LDEyICs4NSwyMyBA QCBlbGlmIFsgIiR0eXBlX2lmIiA9IHRhcCBdOyB0aGVuCiAgICAgOiAke0lOVEVSRkFDRTo/fQog CiAgICAgIyBHZXQgeGVuYnVzX3BhdGggZnJvbSBkZXZpY2UgbmFtZS4KLSAgICAjIFRoZSBuYW1l IGlzIGJ1aWx0IGxpa2UgdGhhdDogInRhcCR7ZG9taWR9LiR7ZGV2aWR9Ii4KLSAgICBkZXZfPSR7 ZGV2I3RhcH0KKyAgICAjIFRoZSBuYW1lIGlzIGJ1aWx0IGxpa2UgdGhhdDogInZpZiR7ZG9taWR9 LiR7ZGV2aWR9LWVtdSIuCisgICAgZGV2Xz0ke2RldiN2aWZ9CisgICAgZGV2Xz0ke2Rldl8lLWVt dX0KICAgICBkb21pZD0ke2Rldl8lLip9CiAgICAgZGV2aWQ9JHtkZXZfIyoufQogCiAgICAgWEVO QlVTX1BBVEg9Ii9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8kZG9taWQvJGRldmlkIgorICAg IHZpZm5hbWU9JCh4ZW5zdG9yZV9yZWFkX2RlZmF1bHQgIiRYRU5CVVNfUEFUSC92aWZuYW1lIiAi IikKKyAgICBpZiBbICIkdmlmbmFtZSIgXQorICAgIHRoZW4KKyAgICAgICAgdmlmbmFtZT0iJHt2 aWZuYW1lfS1lbXUiCisgICAgICAgIGlmIFsgIiRjb21tYW5kIiA9PSAiYWRkIiBdICYmICEgaXAg bGluayBzaG93ICIkdmlmbmFtZSIgPiYvZGV2L251bGwKKyAgICAgICAgdGhlbgorICAgICAgICAg ICAgZG9fb3JfZGllIGlwIGxpbmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKKyAgICAgICAg ZmkKKyAgICAgICAgZGV2PSIkdmlmbmFtZSIKKyAgICBmaQogZmkKIAogaXA9JHtpcDotfQpkaWZm IC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcyBiL3Rvb2xzL2hv dHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKaW5kZXggNDBmMjY1OC4uNDA1Mzg3ZiAxMDA2 NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFja2VuZC5ydWxlcworKysgYi90b29s cy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzCkBAIC0xMyw0ICsxMyw0IEBAIEtFUk5F TD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3RhcC0yL2NvbnRyb2wiLCBNT0RFPSIw NjAwIgogS0VSTkVMPT0iZ250ZGV2IiwgTkFNRT0ieGVuLyVrIiwgTU9ERT0iMDYwMCIKIEtFUk5F TD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1PREU9IjA2MDAiCiBLRVJORUw9PSJ0YXBk ZXZbYS16XSoiLCBOQU1FPSJ4ZW4vYmxrdGFwLTIvdGFwZGV2JW0iLCBNT0RFPSIwNjAwIgotU1VC U1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElPTj09ImFkZCIsIFJVTis9Ii9ldGMv eGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0eXBlX2lmPXRhcCIKK1NVQlNZU1RF TT09Im5ldCIsIEtFUk5FTD09InZpZiotZW11IiwgQUNUSU9OPT0iYWRkIiwgUlVOKz0iL2V0Yy94 ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5cGVfaWY9dGFwIgpkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKaW5kZXgg MWZmY2M5MC4uMmMwMzBjYSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYworKysg Yi90b29scy9saWJ4bC9saWJ4bF9kbS5jCkBAIC0xMzQsMTEgKzEzNCw5IEBAIHN0YXRpYyBjaGFy ICoqIGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX29sZChsaWJ4bF9fZ2MgKmdjLAogICAg ICAgICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3ByaW50ZihnYywgIiUwMng6JTAyeDol MDJ4OiUwMng6JTAyeDolMDJ4IiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB2aWZzW2ldLm1hY1swXSwgdmlmc1tpXS5tYWNbMV0sIHZpZnNbaV0ubWFjWzJdLAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzNd LCB2aWZzW2ldLm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwotICAgICAgICAgICAgICAgIGNoYXIg KmlmbmFtZTsKLSAgICAgICAgICAgICAgICBpZiAoIXZpZnNbaV0uaWZuYW1lKQotICAgICAgICAg ICAgICAgICAgICBpZm5hbWUgPSBsaWJ4bF9fc3ByaW50ZihnYywgInRhcCVkLiVkIiwgaW5mby0+ ZG9taWQsIHZpZnNbaV0uZGV2aWQpOwotICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAg ICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7CisgICAgICAgICAgICAgICAgY29uc3Qg Y2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2aWYlZC4lZC1lbXUiLAorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPmRvbWlk LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZp ZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3Ms CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICItbmV0IiwgbGlieGxfX3NwcmludGYo Z2MsICJuaWMsdmxhbj0lZCxtYWNhZGRyPSVzLG1vZGVsPSVzIiwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWZzW2ldLmRldmlkLCBzbWFj LCB2aWZzW2ldLm1vZGVsKSwKQEAgLTI3MSwxMiArMjY5LDkgQEAgc3RhdGljIGNoYXIgKiogbGli eGxfYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3KGxpYnhsX19nYyAqZ2MsCiAgICAgICAgICAg ICAgICAgY2hhciAqc21hYyA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJTAyeDolMDJ4OiUwMng6JTAy eDolMDJ4OiUwMngiLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHZpZnNbaV0ubWFjWzBdLCB2aWZzW2ldLm1hY1sxXSwgdmlmc1tpXS5tYWNbMl0sCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5tYWNbM10sIHZpZnNb aV0ubWFjWzRdLCB2aWZzW2ldLm1hY1s1XSk7Ci0gICAgICAgICAgICAgICAgY2hhciAqaWZuYW1l OwotICAgICAgICAgICAgICAgIGlmICghdmlmc1tpXS5pZm5hbWUpIHsKLSAgICAgICAgICAgICAg ICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ0YXAlZC4lZCIsIGluZm8tPmRvbWlk LCB2aWZzW2ldLmRldmlkKTsKLSAgICAgICAgICAgICAgICB9IGVsc2UgewotICAgICAgICAgICAg ICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKLSAgICAgICAgICAgICAgICB9CisgICAg ICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2aWYl ZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhhcnJh eV9hcHBlbmQoZG1fYXJncywgIi1uZXQiKTsKICAgICAgICAgICAgICAgICBmbGV4YXJyYXlfYXBw ZW5kKGRtX2FyZ3MsIGxpYnhsX19zcHJpbnRmKGdjLCAibmljLHZsYW49JWQsbWFjYWRkcj0lcyxt b2RlbD0lcyIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmlmc1tpXS5kZXZpZCwgc21h Yywgdmlmc1tpXS5tb2RlbCkpOwpkaWZmIC0tZ2l0IGEvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2lt YWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5CmluZGV4IGYxNDY0YWMuLjNj OGQ4MGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5weQorKysgYi90 b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkxNywxMSArOTE3LDcgQEAgY2xhc3Mg SFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6CiAgICAgICAgICAgICByZXQuYXBwZW5kKCIt bmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2bGFuPSVkLG1hY2FkZHI9JXMsbW9k ZWw9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIG1hYywgbW9kZWwpKQotICAg ICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8uZ2V0KCd2aWZuYW1lJykKLSAgICAgICAgICAgIGlm IHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9ICJ0YXAtIiArIHZpZm5hbWUKLSAg ICAgICAgICAgIGVsc2U6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9ICJ0YXAlZC4lZCIgJSAo c2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCisgICAgICAgICAgICB2aWZuYW1lID0gInZpZiVk LiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCiAgICAgICAgICAgICByZXQu YXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoInRhcCx2bGFuPSVkLGlmbmFt ZT0lcyxicmlkZ2U9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5pY3MsIHZpZm5hbWUs IGJyaWRnZSkpCg== --047d7b2eda632e25c404bfcb70c5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --047d7b2eda632e25c404bfcb70c5-- From xen-devel-bounces@lists.xen.org Sat May 12 00:40:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 00:40:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST0NG-0008V0-7w; Sat, 12 May 2012 00:39:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST0NF-0008Uv-BH for xen-devel@lists.xensource.com; Sat, 12 May 2012 00:39:53 +0000 Received: from [85.158.138.51:2914] by server-9.bemta-3.messagelabs.com id 21/C7-26691-851BDAF4; Sat, 12 May 2012 00:39:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336783191!26761841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29406 invoked from network); 12 May 2012 00:39:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 00:39:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12437912" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 00:39: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, 12 May 2012 01:39:49 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1ST0NB-0001yj-ME; Sat, 12 May 2012 00:39:49 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1ST0NB-00063K-Kj; Sat, 12 May 2012 01:39:49 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 12 May 2012 01:39:49 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12854: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12854 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12854/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12852 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail like 12849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cd4dd23a831d baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=cd4dd23a831d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 cd4dd23a831d + branch=xen-unstable + revision=cd4dd23a831d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r cd4dd23a831d 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 39 changesets with 117 changes to 43 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 00:40:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 00:40:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST0NG-0008V0-7w; Sat, 12 May 2012 00:39:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST0NF-0008Uv-BH for xen-devel@lists.xensource.com; Sat, 12 May 2012 00:39:53 +0000 Received: from [85.158.138.51:2914] by server-9.bemta-3.messagelabs.com id 21/C7-26691-851BDAF4; Sat, 12 May 2012 00:39:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336783191!26761841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29406 invoked from network); 12 May 2012 00:39:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 00:39:51 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12437912" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 00:39: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, 12 May 2012 01:39:49 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1ST0NB-0001yj-ME; Sat, 12 May 2012 00:39:49 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1ST0NB-00063K-Kj; Sat, 12 May 2012 01:39:49 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 12 May 2012 01:39:49 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12854: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12854 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12854/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12852 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail like 12849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cd4dd23a831d baseline version: xen 54c8c9eaee92 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=cd4dd23a831d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 cd4dd23a831d + branch=xen-unstable + revision=cd4dd23a831d + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig 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 + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : 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 ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r cd4dd23a831d 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 39 changesets with 117 changes to 43 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:42:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1Lc-0004GI-6h; Sat, 12 May 2012 01:42:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1La-0004GD-1T for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:42:14 +0000 Received: from [85.158.138.51:9537] by server-5.bemta-3.messagelabs.com id C4/7B-17113-5FFBDAF4; Sat, 12 May 2012 01:42:13 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336786932!8003883!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18436 invoked from network); 12 May 2012 01:42:12 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:42:12 -0000 Received: by wgbdr1 with SMTP id dr1so2779708wgb.24 for ; Fri, 11 May 2012 18:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Fqnz0BYdHdblscBBNIib+pG1tQESKxt4zQSjYz6pdNs=; b=SGiSyiaINEMvSIlNHA1sRdBmHJ2zUZ94QUDyzqB/Ue0T/d5Vlep0Q74i3rofR3vXpt mtVo5ppN+ostVf93qkyJ3RLHxWqGuUfe2vt9rYKU6OuVdOFNgoGesmgGTzClv6fbZnNb 3L4KOTE0znlWNrtNHCf6El5LGztOA04zGTwGj1qzJke2Orf4SpbiQ7oT5LN2argcOGPv 34lGT0WrhkhvR7FltpQbX958RZSVAhT4xUTB1/QuVZ8iOGlTBCLRVLaKfk+46ZeEp5ua 2k+Kgxkv+LzeBZm3IpRsNO2pHyBJIinvtKaDetHyol/TavmZkWgODQuggHUIMRMUMZn1 HlgQ== MIME-Version: 1.0 Received: by 10.180.24.103 with SMTP id t7mr589875wif.16.1336786932005; Fri, 11 May 2012 18:42:12 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:42:11 -0700 (PDT) In-Reply-To: <1331916862-20504-3-git-send-email-anthony.perard@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-3-git-send-email-anthony.perard@citrix.com> Date: Fri, 11 May 2012 21:42:11 -0400 X-Google-Sender-Auth: SS8ITEJpxLDLR6WixfszFFkYGWY Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Anthony Liguori , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 2/8] configure: Introduce --enable-xen-pci-passthrough. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Mar 16, 2012 at 12:54 PM, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD I thought I reviewed this last time? Is there a reason for not attaching 'Reviewed-by: Konrad Rzeszutek Wilk ' on this patch? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:42:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1Lc-0004GI-6h; Sat, 12 May 2012 01:42:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1La-0004GD-1T for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:42:14 +0000 Received: from [85.158.138.51:9537] by server-5.bemta-3.messagelabs.com id C4/7B-17113-5FFBDAF4; Sat, 12 May 2012 01:42:13 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1336786932!8003883!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.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18436 invoked from network); 12 May 2012 01:42:12 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:42:12 -0000 Received: by wgbdr1 with SMTP id dr1so2779708wgb.24 for ; Fri, 11 May 2012 18:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Fqnz0BYdHdblscBBNIib+pG1tQESKxt4zQSjYz6pdNs=; b=SGiSyiaINEMvSIlNHA1sRdBmHJ2zUZ94QUDyzqB/Ue0T/d5Vlep0Q74i3rofR3vXpt mtVo5ppN+ostVf93qkyJ3RLHxWqGuUfe2vt9rYKU6OuVdOFNgoGesmgGTzClv6fbZnNb 3L4KOTE0znlWNrtNHCf6El5LGztOA04zGTwGj1qzJke2Orf4SpbiQ7oT5LN2argcOGPv 34lGT0WrhkhvR7FltpQbX958RZSVAhT4xUTB1/QuVZ8iOGlTBCLRVLaKfk+46ZeEp5ua 2k+Kgxkv+LzeBZm3IpRsNO2pHyBJIinvtKaDetHyol/TavmZkWgODQuggHUIMRMUMZn1 HlgQ== MIME-Version: 1.0 Received: by 10.180.24.103 with SMTP id t7mr589875wif.16.1336786932005; Fri, 11 May 2012 18:42:12 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:42:11 -0700 (PDT) In-Reply-To: <1331916862-20504-3-git-send-email-anthony.perard@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-3-git-send-email-anthony.perard@citrix.com> Date: Fri, 11 May 2012 21:42:11 -0400 X-Google-Sender-Auth: SS8ITEJpxLDLR6WixfszFFkYGWY Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Anthony Liguori , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 2/8] configure: Introduce --enable-xen-pci-passthrough. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Mar 16, 2012 at 12:54 PM, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD I thought I reviewed this last time? Is there a reason for not attaching 'Reviewed-by: Konrad Rzeszutek Wilk ' on this patch? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:44:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1NB-0004JZ-M8; Sat, 12 May 2012 01:43:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1NA-0004JT-Hi for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:43:52 +0000 Received: from [85.158.139.83:4341] by server-5.bemta-5.messagelabs.com id 21/0A-13566-750CDAF4; Sat, 12 May 2012 01:43:51 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336787030!27961252!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50 X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24771 invoked from network); 12 May 2012 01:43:51 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:43:51 -0000 Received: by wgbdr1 with SMTP id dr1so2780152wgb.24 for ; Fri, 11 May 2012 18:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TZBLiY1yngN9QrdExLxL+KugYR+7Dt7OX6aRpsKD688=; b=Gs1cmqhX9FwnlVDlaKMAesy+uI6jd3OAAPgJmkP33txHXjV/F4+lfZh85JnuGiwocD 31UvXKZK8zK8NtKexYg15422+DOuJ7FKkI1aUJPmYJmgFvG5pcwreFKiJaGw7wZlKn8N f4w6NVrQBxLmvmqE7u8/J4WnmAayb8EPTG03jLMshAlOhd0L4Nav94gepMP9Rsgm6Azb WaFlfonzN1dXD1IitvTF7/B/4NxtCz1DtAhND/q1bq+3dSO1h7KkVlehKl3GF/VRSEr9 dm4zzmDjUZbp4ky3SFjehC6lxX7gKS1dJp9xYxZplTN5ucPFn3yW4exF6StV6uuaUWeP uBtA== MIME-Version: 1.0 Received: by 10.180.81.37 with SMTP id w5mr585977wix.16.1336787030710; Fri, 11 May 2012 18:43:50 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:43:50 -0700 (PDT) In-Reply-To: <4F6764BD.4060708@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-2-git-send-email-anthony.perard@citrix.com> <4F6764BD.4060708@citrix.com> Date: Fri, 11 May 2012 21:43:50 -0400 X-Google-Sender-Auth: 8xu3pmCqMVDs3Zq3Zg3Iqlcd2Bc Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Xen Devel , "Michael S . Tsirkin" , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 1/8] pci_ids: Add INTEL_82599_VF id. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Mar 19, 2012 at 12:54 PM, Anthony PERARD wrote: > On 19/03/12 11:50, Stefano Stabellini wrote: >> >> On Fri, 16 Mar 2012, Anthony PERARD wrote: >>> >>> Signed-off-by: Anthony PERARD >>> --- >>> =A0hw/pci_ids.h | =A0 =A01 + >>> =A01 files changed, 1 insertions(+), 0 deletions(-) >>> >>> diff --git a/hw/pci_ids.h b/hw/pci_ids.h >>> index e8235a7..943106a 100644 >>> --- a/hw/pci_ids.h >>> +++ b/hw/pci_ids.h >>> @@ -118,6 +118,7 @@ >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939 >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c >>> +#define PCI_DEVICE_ID_INTEL_82599_VF =A0 =A0 0x10ed >> >> >> maybe it should be PCI_DEVICE_ID_INTEL_82599_SFP_VF for consistency with >> Linux? > > > Ok, I'll change that. > And can you add why you need this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:44:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1NB-0004JZ-M8; Sat, 12 May 2012 01:43:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1NA-0004JT-Hi for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:43:52 +0000 Received: from [85.158.139.83:4341] by server-5.bemta-5.messagelabs.com id 21/0A-13566-750CDAF4; Sat, 12 May 2012 01:43:51 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336787030!27961252!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP,UPPERCASE_25_50 X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24771 invoked from network); 12 May 2012 01:43:51 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:43:51 -0000 Received: by wgbdr1 with SMTP id dr1so2780152wgb.24 for ; Fri, 11 May 2012 18:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TZBLiY1yngN9QrdExLxL+KugYR+7Dt7OX6aRpsKD688=; b=Gs1cmqhX9FwnlVDlaKMAesy+uI6jd3OAAPgJmkP33txHXjV/F4+lfZh85JnuGiwocD 31UvXKZK8zK8NtKexYg15422+DOuJ7FKkI1aUJPmYJmgFvG5pcwreFKiJaGw7wZlKn8N f4w6NVrQBxLmvmqE7u8/J4WnmAayb8EPTG03jLMshAlOhd0L4Nav94gepMP9Rsgm6Azb WaFlfonzN1dXD1IitvTF7/B/4NxtCz1DtAhND/q1bq+3dSO1h7KkVlehKl3GF/VRSEr9 dm4zzmDjUZbp4ky3SFjehC6lxX7gKS1dJp9xYxZplTN5ucPFn3yW4exF6StV6uuaUWeP uBtA== MIME-Version: 1.0 Received: by 10.180.81.37 with SMTP id w5mr585977wix.16.1336787030710; Fri, 11 May 2012 18:43:50 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:43:50 -0700 (PDT) In-Reply-To: <4F6764BD.4060708@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-2-git-send-email-anthony.perard@citrix.com> <4F6764BD.4060708@citrix.com> Date: Fri, 11 May 2012 21:43:50 -0400 X-Google-Sender-Auth: 8xu3pmCqMVDs3Zq3Zg3Iqlcd2Bc Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Xen Devel , "Michael S . Tsirkin" , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 1/8] pci_ids: Add INTEL_82599_VF id. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Mar 19, 2012 at 12:54 PM, Anthony PERARD wrote: > On 19/03/12 11:50, Stefano Stabellini wrote: >> >> On Fri, 16 Mar 2012, Anthony PERARD wrote: >>> >>> Signed-off-by: Anthony PERARD >>> --- >>> =A0hw/pci_ids.h | =A0 =A01 + >>> =A01 files changed, 1 insertions(+), 0 deletions(-) >>> >>> diff --git a/hw/pci_ids.h b/hw/pci_ids.h >>> index e8235a7..943106a 100644 >>> --- a/hw/pci_ids.h >>> +++ b/hw/pci_ids.h >>> @@ -118,6 +118,7 @@ >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939 >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a >>> =A0#define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c >>> +#define PCI_DEVICE_ID_INTEL_82599_VF =A0 =A0 0x10ed >> >> >> maybe it should be PCI_DEVICE_ID_INTEL_82599_SFP_VF for consistency with >> Linux? > > > Ok, I'll change that. > And can you add why you need this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:54:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1Wy-0004Xu-P5; Sat, 12 May 2012 01:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1Wx-0004Xp-TB for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:54:00 +0000 Received: from [85.158.139.83:7118] by server-5.bemta-5.messagelabs.com id AF/7E-13566-6B2CDAF4; Sat, 12 May 2012 01:53:58 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336787637!24022395!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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12181 invoked from network); 12 May 2012 01:53:58 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:53:58 -0000 Received: by wgbdr1 with SMTP id dr1so2782994wgb.24 for ; Fri, 11 May 2012 18:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8KaLyXu+frq7Sm3w1UxsP4JVt/Tsi6Vn1Q+sdOSYHiQ=; b=wXLB2svNPfk2P6jEhij5C+bIE1sbdjQLR3FBVq9oG4G3CGBDp3DJTbqO/M3a7nHoTQ fRZjE6PdOlq1CCyIGAtj4CJqZ2XEhyoRvRdpQYiRYWP8JFVHQ4bFguEab+gpIIUZ0tcz rytPt00FeGrKyEu2jqz3pLfp0Z4s25jWfSo6LhijEFF4KKvoiM9/FPr+53aKbgvis9YS oxtXIU6Vx9CYEkAo+VMSDYJOOXgTgyqY8ym9CKAA1MSSieiIYnUmRmv4FTFt+ArZrDmZ I0M+TmFkZFkMjZGptfs2UAHi1ZmUn3Fjcia01FQ72d4i5+HgVRWjG9mjJbipJNYO9/SX 9GJw== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr668231wib.13.1336787637102; Fri, 11 May 2012 18:53:57 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:53:57 -0700 (PDT) In-Reply-To: <1331916862-20504-6-git-send-email-anthony.perard@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-6-git-send-email-anthony.perard@citrix.com> Date: Fri, 11 May 2012 21:53:57 -0400 X-Google-Sender-Auth: -QULaPtcQSovOsP0WQy4oHJdtlQ Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Guy Zana , Xen Devel , Allen Kay , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 5/8] Introduce Xen PCI Passthrough, qdevice (1/3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > +void pt_log(const PCIDevice *d, const char *f, ...) > +{ > + =A0 =A0va_list ap; > + > + =A0 =A0va_start(ap, f); > + =A0 =A0if (d) { > + =A0 =A0 =A0 =A0fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus), %02x.%d > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PCI_SLOT(d->devfn), PCI_FUNC(d->devfn)); > + =A0 =A0} > + =A0 =A0vfprintf(stderr, f, ap); > + =A0 =A0va_end(ap); > +} > +static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len) I wish there was some way to combine this function along with the pt_pci_write_config one. They look so similar. Besides that it looks ok. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 01:54:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 01: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 ) id 1ST1Wy-0004Xu-P5; Sat, 12 May 2012 01:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1Wx-0004Xp-TB for xen-devel@lists.xensource.com; Sat, 12 May 2012 01:54:00 +0000 Received: from [85.158.139.83:7118] by server-5.bemta-5.messagelabs.com id AF/7E-13566-6B2CDAF4; Sat, 12 May 2012 01:53:58 +0000 X-Env-Sender: konrad.r.wilk@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1336787637!24022395!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.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12181 invoked from network); 12 May 2012 01:53:58 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 01:53:58 -0000 Received: by wgbdr1 with SMTP id dr1so2782994wgb.24 for ; Fri, 11 May 2012 18:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8KaLyXu+frq7Sm3w1UxsP4JVt/Tsi6Vn1Q+sdOSYHiQ=; b=wXLB2svNPfk2P6jEhij5C+bIE1sbdjQLR3FBVq9oG4G3CGBDp3DJTbqO/M3a7nHoTQ fRZjE6PdOlq1CCyIGAtj4CJqZ2XEhyoRvRdpQYiRYWP8JFVHQ4bFguEab+gpIIUZ0tcz rytPt00FeGrKyEu2jqz3pLfp0Z4s25jWfSo6LhijEFF4KKvoiM9/FPr+53aKbgvis9YS oxtXIU6Vx9CYEkAo+VMSDYJOOXgTgyqY8ym9CKAA1MSSieiIYnUmRmv4FTFt+ArZrDmZ I0M+TmFkZFkMjZGptfs2UAHi1ZmUn3Fjcia01FQ72d4i5+HgVRWjG9mjJbipJNYO9/SX 9GJw== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr668231wib.13.1336787637102; Fri, 11 May 2012 18:53:57 -0700 (PDT) Received: by 10.180.7.137 with HTTP; Fri, 11 May 2012 18:53:57 -0700 (PDT) In-Reply-To: <1331916862-20504-6-git-send-email-anthony.perard@citrix.com> References: <1331916862-20504-1-git-send-email-anthony.perard@citrix.com> <1331916862-20504-6-git-send-email-anthony.perard@citrix.com> Date: Fri, 11 May 2012 21:53:57 -0400 X-Google-Sender-Auth: -QULaPtcQSovOsP0WQy4oHJdtlQ Message-ID: From: Konrad Rzeszutek Wilk To: Anthony PERARD Cc: Guy Zana , Xen Devel , Allen Kay , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V8 RESEND 5/8] Introduce Xen PCI Passthrough, qdevice (1/3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: konrad@darnok.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > +void pt_log(const PCIDevice *d, const char *f, ...) > +{ > + =A0 =A0va_list ap; > + > + =A0 =A0va_start(ap, f); > + =A0 =A0if (d) { > + =A0 =A0 =A0 =A0fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus), %02x.%d > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PCI_SLOT(d->devfn), PCI_FUNC(d->devfn)); > + =A0 =A0} > + =A0 =A0vfprintf(stderr, f, ap); > + =A0 =A0va_end(ap); > +} > +static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t addr, int len) I wish there was some way to combine this function along with the pt_pci_write_config one. They look so similar. Besides that it looks ok. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:17:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02:17:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1tB-00056w-Ot; Sat, 12 May 2012 02:16:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1t9-00056r-Nv for xen-devel@lists.xen.org; Sat, 12 May 2012 02:16:55 +0000 Received: from [85.158.138.51:22684] by server-8.bemta-3.messagelabs.com id 6B/FF-24428-618CDAF4; Sat, 12 May 2012 02:16:54 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-10.tower-174.messagelabs.com!1336789014!22656799!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11778 invoked from network); 12 May 2012 02:16:54 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:16:54 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id D72E1298144 for ; Sat, 12 May 2012 02:16:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm6814Xdo2zi for ; Sat, 12 May 2012 02:16:48 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 39013298022 for ; Sat, 12 May 2012 02:16:48 +0000 (UTC) Date: Sat, 12 May 2012 04:16:45 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512041645.11509848@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello everyone, Said Xen version running on kernel 3.3.4 x86_64. I had put in Grub's "module /vmlinuz.gz" line: xen_pciback.hide=(02:10.0)(02:10.2)(etc.) This yields an error in dmesg: xen_pciback: Unknown parameter `2)' I tried all sorts of variations: quoting the pci devices, prefixing the devices with an extra 0000:, putting the thing somewhere else. But the error keeps returning. I am working around this by having added the hide option in a modules.conf entry. For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:17:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02:17:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1tB-00056w-Ot; Sat, 12 May 2012 02:16:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST1t9-00056r-Nv for xen-devel@lists.xen.org; Sat, 12 May 2012 02:16:55 +0000 Received: from [85.158.138.51:22684] by server-8.bemta-3.messagelabs.com id 6B/FF-24428-618CDAF4; Sat, 12 May 2012 02:16:54 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-10.tower-174.messagelabs.com!1336789014!22656799!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11778 invoked from network); 12 May 2012 02:16:54 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:16:54 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id D72E1298144 for ; Sat, 12 May 2012 02:16:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm6814Xdo2zi for ; Sat, 12 May 2012 02:16:48 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 39013298022 for ; Sat, 12 May 2012 02:16:48 +0000 (UTC) Date: Sat, 12 May 2012 04:16:45 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512041645.11509848@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello everyone, Said Xen version running on kernel 3.3.4 x86_64. I had put in Grub's "module /vmlinuz.gz" line: xen_pciback.hide=(02:10.0)(02:10.2)(etc.) This yields an error in dmesg: xen_pciback: Unknown parameter `2)' I tried all sorts of variations: quoting the pci devices, prefixing the devices with an extra 0000:, putting the thing somewhere else. But the error keeps returning. I am working around this by having added the hide option in a modules.conf entry. For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02: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 ) id 1ST24S-0005GP-0X; Sat, 12 May 2012 02:28:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST24Q-0005GK-FQ for xen-devel@lists.xen.org; Sat, 12 May 2012 02:28:34 +0000 Received: from [85.158.138.51:16572] by server-9.bemta-3.messagelabs.com id 90/EE-26691-1DACDAF4; Sat, 12 May 2012 02:28:33 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-10.tower-174.messagelabs.com!1336789713!22657728!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6927 invoked from network); 12 May 2012 02:28:33 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:28:33 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id CDA46298144 for ; Sat, 12 May 2012 02:28:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNR3Z3+A6C16 for ; Sat, 12 May 2012 02:28:31 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 43378298022 for ; Sat, 12 May 2012 02:28:31 +0000 (UTC) Date: Sat, 12 May 2012 04:28:31 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512042831.6460b834@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] bug report for network device i82599er: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org When trying to start a FreeBSD 9.0 HVM guest I see the following line in qemu-dm-freebsd.log: qemu-dm: /src/xen-stable-hg/src/xen-4.1-testing.hg-build/tools/ioemu-dir/hw/eepro100.c:1320: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. The domain crashes. I suspect this occurs because I am trying to build the domain with a vif where model=i82559er. Changing the model to e1000 does build the domain. I would prefer to have the ability to use 10Gbps because my physical nic is also a 10Gbps nic: 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02: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 ) id 1ST24S-0005GP-0X; Sat, 12 May 2012 02:28:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST24Q-0005GK-FQ for xen-devel@lists.xen.org; Sat, 12 May 2012 02:28:34 +0000 Received: from [85.158.138.51:16572] by server-9.bemta-3.messagelabs.com id 90/EE-26691-1DACDAF4; Sat, 12 May 2012 02:28:33 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-10.tower-174.messagelabs.com!1336789713!22657728!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6927 invoked from network); 12 May 2012 02:28:33 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:28:33 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id CDA46298144 for ; Sat, 12 May 2012 02:28:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNR3Z3+A6C16 for ; Sat, 12 May 2012 02:28:31 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 43378298022 for ; Sat, 12 May 2012 02:28:31 +0000 (UTC) Date: Sat, 12 May 2012 04:28:31 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512042831.6460b834@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] bug report for network device i82599er: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org When trying to start a FreeBSD 9.0 HVM guest I see the following line in qemu-dm-freebsd.log: qemu-dm: /src/xen-stable-hg/src/xen-4.1-testing.hg-build/tools/ioemu-dir/hw/eepro100.c:1320: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. The domain crashes. I suspect this occurs because I am trying to build the domain with a vif where model=i82559er. Changing the model to e1000 does build the domain. I would prefer to have the ability to use 10Gbps because my physical nic is also a 10Gbps nic: 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:32:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02:32:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST27o-0005Mx-Kq; Sat, 12 May 2012 02:32:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST27o-0005Mr-6u for xen-devel@lists.xen.org; Sat, 12 May 2012 02:32:04 +0000 Received: from [193.109.254.147:48730] by server-3.bemta-14.messagelabs.com id 56/91-23274-3ABCDAF4; Sat, 12 May 2012 02:32:03 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-9.tower-27.messagelabs.com!1336789922!8521625!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21814 invoked from network); 12 May 2012 02:32:02 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:32:02 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id 88263298144 for ; Sat, 12 May 2012 02:32:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q5Emz9czE1J for ; Sat, 12 May 2012 02:32:01 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 91D55298022 for ; Sat, 12 May 2012 02:32:01 +0000 (UTC) Date: Sat, 12 May 2012 04:32:01 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512043201.7e6055e7@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] bug report for network device i82599er: eepro100_write4 assertation failed X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Sorry, reposting this with a shorter subject line. When trying to start a FreeBSD 9.0 HVM guest I see the following line in qemu-dm-freebsd.log: qemu-dm: /src/xen-stable-hg/src/xen-4.1-testing.hg-build/tools/ioemu-dir/hw/eepro100.c:1320: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. The domain crashes. I suspect this occurs because I am trying to build the domain with a vif where model=i82559er. Changing the model to e1000 does build the domain. I would prefer to have the ability to use 10Gbps because my physical nic is also a 10Gbps nic: 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 02:32:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 02:32:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST27o-0005Mx-Kq; Sat, 12 May 2012 02:32:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST27o-0005Mr-6u for xen-devel@lists.xen.org; Sat, 12 May 2012 02:32:04 +0000 Received: from [193.109.254.147:48730] by server-3.bemta-14.messagelabs.com id 56/91-23274-3ABCDAF4; Sat, 12 May 2012 02:32:03 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-9.tower-27.messagelabs.com!1336789922!8521625!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21814 invoked from network); 12 May 2012 02:32:02 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2012 02:32:02 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id 88263298144 for ; Sat, 12 May 2012 02:32:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mx1.internecto.net Received: from mx1.internecto.net ([176.9.245.29]) by localhost (polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q5Emz9czE1J for ; Sat, 12 May 2012 02:32:01 +0000 (UTC) Received: from internecto.net (unknown [IPv6:2001:888:173e:1:221:85ff:fe10:3c98]) by mx1.internecto.net (Postfix) with ESMTP id 91D55298022 for ; Sat, 12 May 2012 02:32:01 +0000 (UTC) Date: Sat, 12 May 2012 04:32:01 +0200 From: Mark To: xen-devel@lists.xen.org Message-ID: <20120512043201.7e6055e7@internecto.net> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Subject: [Xen-devel] bug report for network device i82599er: eepro100_write4 assertation failed X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Sorry, reposting this with a shorter subject line. When trying to start a FreeBSD 9.0 HVM guest I see the following line in qemu-dm-freebsd.log: qemu-dm: /src/xen-stable-hg/src/xen-4.1-testing.hg-build/tools/ioemu-dir/hw/eepro100.c:1320: eepro100_write4: Assertion `!"feature is missing in this emulation: " "unknown longword write"' failed. The domain crashes. I suspect this occurs because I am trying to build the domain with a vif where model=i82559er. Changing the model to e1000 does build the domain. I would prefer to have the ability to use 10Gbps because my physical nic is also a 10Gbps nic: 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) For further contact please be aware I am not receiving xen-devel emails, so please include me in CC's when more info is required. Thank you, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 05:48:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 05:48:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5Ar-0006dw-IY; Sat, 12 May 2012 05:47:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5Ap-0006dr-Gt for xen-devel@lists.xensource.com; Sat, 12 May 2012 05:47:23 +0000 Received: from [85.158.143.35:25256] by server-2.bemta-4.messagelabs.com id 53/61-17550-A69FDAF4; Sat, 12 May 2012 05:47:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336801641!4008819!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21281 invoked from network); 12 May 2012 05:47:22 -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; 12 May 2012 05:47:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439037" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 05:47:21 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 06:47:20 +0100 Message-ID: <1336801640.3891.17.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Sat, 12 May 2012 06:47:20 +0100 In-Reply-To: <20397.18234.50742.594420@mariner.uk.xensource.com> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> <20397.18234.50742.594420@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 18:07 +0100, Ian Jackson wrote: > Bastian Blank writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"): > > On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > > > --- /dev/null > > > +++ b/tools/xenstore/compat/xs.h > > > > Why not in tools/xenstore? > > Good question. One answer is that this prevents in-tree users from > accidentally using the old header - but do we really care about that ? I thought it was worth doing it -- the cost is minimal. > > > > +#ifndef XENSTORE_COMPAT_H > > > +#define XENSTORE_COMPAT_H > > > > Don't. > > I guess you mean that we want a warning each time is #included, > rather than only the first time. In which case I agree. I'm not convinced that getting multiple warnings+backtraces for each .c file which includes xs.h is any more useful than just getting one, but OK. > Ian: I tried your patch but it didn't seem to apply to my current tip. You've been shovelling stuff in all day ;-) I'll refresh/resend on Monday. You did take note of the "git-ness" of the patch though? -- ISTR your tools had trouble with this format last time. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 05:48:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 05:48:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5Ar-0006dw-IY; Sat, 12 May 2012 05:47:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5Ap-0006dr-Gt for xen-devel@lists.xensource.com; Sat, 12 May 2012 05:47:23 +0000 Received: from [85.158.143.35:25256] by server-2.bemta-4.messagelabs.com id 53/61-17550-A69FDAF4; Sat, 12 May 2012 05:47:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1336801641!4008819!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21281 invoked from network); 12 May 2012 05:47:22 -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; 12 May 2012 05:47:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439037" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 05:47:21 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 06:47:20 +0100 Message-ID: <1336801640.3891.17.camel@dagon.hellion.org.uk> From: Ian Campbell To: Ian Jackson Date: Sat, 12 May 2012 06:47:20 +0100 In-Reply-To: <20397.18234.50742.594420@mariner.uk.xensource.com> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> <20397.18234.50742.594420@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 18:07 +0100, Ian Jackson wrote: > Bastian Blank writes ("Re: [Xen-devel] [PATCH] Rename public xenstore headers"): > > On Fri, May 11, 2012 at 05:49:59PM +0100, Ian Campbell wrote: > > > --- /dev/null > > > +++ b/tools/xenstore/compat/xs.h > > > > Why not in tools/xenstore? > > Good question. One answer is that this prevents in-tree users from > accidentally using the old header - but do we really care about that ? I thought it was worth doing it -- the cost is minimal. > > > > +#ifndef XENSTORE_COMPAT_H > > > +#define XENSTORE_COMPAT_H > > > > Don't. > > I guess you mean that we want a warning each time is #included, > rather than only the first time. In which case I agree. I'm not convinced that getting multiple warnings+backtraces for each .c file which includes xs.h is any more useful than just getting one, but OK. > Ian: I tried your patch but it didn't seem to apply to my current tip. You've been shovelling stuff in all day ;-) I'll refresh/resend on Monday. You did take note of the "git-ness" of the patch though? -- ISTR your tools had trouble with this format last time. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 05:51:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 05: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 ) id 1ST5E7-0006jd-5N; Sat, 12 May 2012 05:50:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5E5-0006jT-Ii for xen-devel@lists.xen.org; Sat, 12 May 2012 05:50:45 +0000 Received: from [85.158.143.99:35651] by server-3.bemta-4.messagelabs.com id 17/07-05853-43AFDAF4; Sat, 12 May 2012 05:50:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336801843!17872446!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16143 invoked from network); 12 May 2012 05:50:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 05:50:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439043" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 05:50: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; Sat, 12 May 2012 06:50:43 +0100 Message-ID: <1336801842.3891.18.camel@dagon.hellion.org.uk> From: Ian Campbell To: Keir Fraser Date: Sat, 12 May 2012 06:50:42 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bei Guan , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:47 +0100, Keir Fraser wrote: > On 11/05/2012 17:33, "Bei Guan" wrote: > > > 2012/5/12 Ian Campbell > >> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > >> > >> > >>> No, it doesn't work for me. There is the same error. > >> > >> Hrm. Since you can reproduce would you mind experimenting a bit to > >> figure out the correct fix for this? > >> > >> Perhaps adding -Wno-unused-result to C flags helps (google suggests it > >> may not)? > > Yes, I add this option to Makefile. And now it works well. The patch is as the > > following. Thank you very much. > > I'd be worried about more command-line meddling causing even more fallout. > Particularly because we haven't used that option anywhere else so far, so > it's untested by us. E.g., do all gcc support -Wno-unused-result? We could have used cc-option, but your {read,write}_exact patch looks like a better fix anyway. Ian. > > -- Keir > > > > > diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile > > --- a/tools/blktap2/drivers/Makefile Fri Apr 27 11:09:26 2012 +0200 > > +++ b/tools/blktap2/drivers/Makefile Sat May 12 00:31:12 2012 +0800 > > @@ -11,6 +11,7 @@ > > > > CFLAGS += -Werror -g > > CFLAGS += -Wno-unused > > +CFLAGS += -Wno-unused-result > > CFLAGS += -fno-strict-aliasing > > CFLAGS += -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers > > CFLAGS += $(CFLAGS_libxenctrl) > > > > > > > > > > Thanks, > > Bei Guan > > > > > > > > > >> > >> Or maybe just assigning to a dummy variable. > >> > >> Ian. > >> > >>> My environment and gcc version are like this: > >>> > >>> root@gavin-desktop:~# uname -a > >>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > >>> 2011 x86_64 GNU/Linux > >>> > >>> root@gavin-desktop:~# gcc -v > >>> Using built-in specs. > >>> Target: x86_64-linux-gnu > >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >>> 4.4.3-4ubuntu5' > >>> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > >>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > >>> --enable-shared --enable-multiarch --enable-linker-build-id > >>> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > >>> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > >>> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > >>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > >>> --disable-werror --with-arch-32=i486 --with-tune=generic > >>> --enable-checking=release --build=x86_64-linux-gnu > >>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu > >>> Thread model: posix > >>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > >>> > >>> > >>> > >>> > >>> Thanks, > >>> Bei Guan > >>> > >>> > >>> > >>> > >>> > >>> 8<------------------------------------------------------ > >>> > >>> # HG changeset patch > >>> # User Ian Campbell > >>> # Date 1336751175 -3600 > >>> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > >>> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > >>> blktap: avoid attribute warn_unused_result build failures. > >>> > >>> I'm not proud of this, but since none of these callers of > >>> read/write have any > >>> other error handling and return void themselves (for several > >>> links up the call > >>> chain AFAICT) and because I don't really want to get into a > >>> massive reworking > >>> of blktap2 I suppose it is at least pragmatic > >>> > >>> Signed-off-by: Ian Campbell > >>> > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-log.c > >>> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -247,7 +247,7 @@ tlog_flush(void) > >>> wsize = ((size + 511) & (~511)); > >>> > >>> memset(tapdisk_log.buf + size, '\n', wsize - size); > >>> - write(fd, tapdisk_log.buf, wsize); > >>> + (void)write(fd, tapdisk_log.buf, wsize); > >>> > >>> tapdisk_log.p = tapdisk_log.buf; > >>> > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-queue.c > >>> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > >>> uint64_t val; > >>> > >>> if (lio->flags & LIO_FLAG_EVENTFD) > >>> - read(lio->event_fd, &val, sizeof(val)); > >>> + (void)read(lio->event_fd, &val, sizeof(val)); > >>> } > >>> > >>> static void > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-stream.c > >>> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > >>> { > >>> int dummy; > >>> > >>> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >>> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >>> p->set = 0; > >>> } > >>> > >>> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > >>> int dummy = 0; > >>> > >>> if (!p->set) { > >>> - write(p->pipe[POLL_WRITE], &dummy, > >>> sizeof(dummy)); > >>> + (void)write(p->pipe[POLL_WRITE], &dummy, > >>> sizeof(dummy)); > >>> p->set = 1; > >>> } > >>> } > >>> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > >>> { > >>> unsigned long idx = (unsigned > >>> long)tapdisk_stream_request_idx(s, sreq); > >>> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > >>> idx, 0); > >>> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > >>> + (void)write(s->out_fd, buf, sreq->secs << > >>> SECTOR_SHIFT); > >>> } > >>> > >>> static void > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk2.c > >>> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > >>> 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > >>> 2012 +0100 > >>> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > >>> if (optind != argc) > >>> usage(argv[0], EINVAL); > >>> > >>> - chdir("/"); > >>> + if (chdir("/")) { > >>> + DPRINTF("failed to chdir(/): %d\n", errno); > >>> + err = 1; > >>> + goto out; > >>> + } > >>> + > >>> tapdisk_start_logging("tapdisk2"); > >>> > >>> err = tapdisk_server_init(); > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Best Regards, > >>> Bei Guan > >>> > >> > >> > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 05:51:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 05: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 ) id 1ST5E7-0006jd-5N; Sat, 12 May 2012 05:50:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5E5-0006jT-Ii for xen-devel@lists.xen.org; Sat, 12 May 2012 05:50:45 +0000 Received: from [85.158.143.99:35651] by server-3.bemta-4.messagelabs.com id 17/07-05853-43AFDAF4; Sat, 12 May 2012 05:50:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1336801843!17872446!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16143 invoked from network); 12 May 2012 05:50:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 05:50:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439043" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 05:50: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; Sat, 12 May 2012 06:50:43 +0100 Message-ID: <1336801842.3891.18.camel@dagon.hellion.org.uk> From: Ian Campbell To: Keir Fraser Date: Sat, 12 May 2012 06:50:42 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bei Guan , xen-devel Subject: Re: [Xen-devel] Errors of doing "make install-tools" with xen-4.2-unstable? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 17:47 +0100, Keir Fraser wrote: > On 11/05/2012 17:33, "Bei Guan" wrote: > > > 2012/5/12 Ian Campbell > >> On Fri, 2012-05-11 at 17:10 +0100, Bei Guan wrote: > >> > >> > >>> No, it doesn't work for me. There is the same error. > >> > >> Hrm. Since you can reproduce would you mind experimenting a bit to > >> figure out the correct fix for this? > >> > >> Perhaps adding -Wno-unused-result to C flags helps (google suggests it > >> may not)? > > Yes, I add this option to Makefile. And now it works well. The patch is as the > > following. Thank you very much. > > I'd be worried about more command-line meddling causing even more fallout. > Particularly because we haven't used that option anywhere else so far, so > it's untested by us. E.g., do all gcc support -Wno-unused-result? We could have used cc-option, but your {read,write}_exact patch looks like a better fix anyway. Ian. > > -- Keir > > > > > diff -r 54c8c9eaee92 tools/blktap2/drivers/Makefile > > --- a/tools/blktap2/drivers/Makefile Fri Apr 27 11:09:26 2012 +0200 > > +++ b/tools/blktap2/drivers/Makefile Sat May 12 00:31:12 2012 +0800 > > @@ -11,6 +11,7 @@ > > > > CFLAGS += -Werror -g > > CFLAGS += -Wno-unused > > +CFLAGS += -Wno-unused-result > > CFLAGS += -fno-strict-aliasing > > CFLAGS += -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers > > CFLAGS += $(CFLAGS_libxenctrl) > > > > > > > > > > Thanks, > > Bei Guan > > > > > > > > > >> > >> Or maybe just assigning to a dummy variable. > >> > >> Ian. > >> > >>> My environment and gcc version are like this: > >>> > >>> root@gavin-desktop:~# uname -a > >>> Linux gavin-desktop 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC > >>> 2011 x86_64 GNU/Linux > >>> > >>> root@gavin-desktop:~# gcc -v > >>> Using built-in specs. > >>> Target: x86_64-linux-gnu > >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >>> 4.4.3-4ubuntu5' > >>> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > >>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > >>> --enable-shared --enable-multiarch --enable-linker-build-id > >>> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > >>> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > >>> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > >>> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc > >>> --disable-werror --with-arch-32=i486 --with-tune=generic > >>> --enable-checking=release --build=x86_64-linux-gnu > >>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu > >>> Thread model: posix > >>> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) > >>> > >>> > >>> > >>> > >>> Thanks, > >>> Bei Guan > >>> > >>> > >>> > >>> > >>> > >>> 8<------------------------------------------------------ > >>> > >>> # HG changeset patch > >>> # User Ian Campbell > >>> # Date 1336751175 -3600 > >>> # Node ID 15ed8f45c4e57a1e206af020e0ff17b792108e99 > >>> # Parent adc74e492edfee6cf44e433e3e93743a3cf71999 > >>> blktap: avoid attribute warn_unused_result build failures. > >>> > >>> I'm not proud of this, but since none of these callers of > >>> read/write have any > >>> other error handling and return void themselves (for several > >>> links up the call > >>> chain AFAICT) and because I don't really want to get into a > >>> massive reworking > >>> of blktap2 I suppose it is at least pragmatic > >>> > >>> Signed-off-by: Ian Campbell > >>> > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-log.c > >>> --- a/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-log.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -247,7 +247,7 @@ tlog_flush(void) > >>> wsize = ((size + 511) & (~511)); > >>> > >>> memset(tapdisk_log.buf + size, '\n', wsize - size); > >>> - write(fd, tapdisk_log.buf, wsize); > >>> + (void)write(fd, tapdisk_log.buf, wsize); > >>> > >>> tapdisk_log.p = tapdisk_log.buf; > >>> > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-queue.c > >>> --- a/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-queue.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -435,7 +435,7 @@ tapdisk_lio_ack_event(struct tqueue *que > >>> uint64_t val; > >>> > >>> if (lio->flags & LIO_FLAG_EVENTFD) > >>> - read(lio->event_fd, &val, sizeof(val)); > >>> + (void)read(lio->event_fd, &val, sizeof(val)); > >>> } > >>> > >>> static void > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk-stream.c > >>> --- a/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >>> 16:19:16 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk-stream.c Fri May 11 > >>> 16:46:15 2012 +0100 > >>> @@ -145,7 +145,7 @@ tapdisk_stream_poll_clear(struct tapdisk > >>> { > >>> int dummy; > >>> > >>> - read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >>> + (void)read(p->pipe[POLL_READ], &dummy, sizeof(dummy)); > >>> p->set = 0; > >>> } > >>> > >>> @@ -155,7 +155,7 @@ tapdisk_stream_poll_set(struct tapdisk_s > >>> int dummy = 0; > >>> > >>> if (!p->set) { > >>> - write(p->pipe[POLL_WRITE], &dummy, > >>> sizeof(dummy)); > >>> + (void)write(p->pipe[POLL_WRITE], &dummy, > >>> sizeof(dummy)); > >>> p->set = 1; > >>> } > >>> } > >>> @@ -203,7 +203,7 @@ tapdisk_stream_print_request(struct tapd > >>> { > >>> unsigned long idx = (unsigned > >>> long)tapdisk_stream_request_idx(s, sreq); > >>> char *buf = (char *)MMAP_VADDR(s->vbd->ring.vstart, > >>> idx, 0); > >>> - write(s->out_fd, buf, sreq->secs << SECTOR_SHIFT); > >>> + (void)write(s->out_fd, buf, sreq->secs << > >>> SECTOR_SHIFT); > >>> } > >>> > >>> static void > >>> diff -r adc74e492edf -r 15ed8f45c4e5 > >>> tools/blktap2/drivers/tapdisk2.c > >>> --- a/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:19:16 > >>> 2012 +0100 > >>> +++ b/tools/blktap2/drivers/tapdisk2.c Fri May 11 16:46:15 > >>> 2012 +0100 > >>> @@ -79,7 +79,12 @@ main(int argc, char *argv[]) > >>> if (optind != argc) > >>> usage(argv[0], EINVAL); > >>> > >>> - chdir("/"); > >>> + if (chdir("/")) { > >>> + DPRINTF("failed to chdir(/): %d\n", errno); > >>> + err = 1; > >>> + goto out; > >>> + } > >>> + > >>> tapdisk_start_logging("tapdisk2"); > >>> > >>> err = tapdisk_server_init(); > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Best Regards, > >>> Bei Guan > >>> > >> > >> > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:39:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST5yd-0007CL-0s; Sat, 12 May 2012 06:38:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5yc-0007CG-8A for xen-devel@lists.xen.org; Sat, 12 May 2012 06:38:50 +0000 Received: from [85.158.143.99:55347] by server-2.bemta-4.messagelabs.com id F4/F1-17550-9750EAF4; Sat, 12 May 2012 06:38:49 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336804727!20118968!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzNjQy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16763 invoked from network); 12 May 2012 06:38:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-11.tower-216.messagelabs.com with SMTP; 12 May 2012 06:38:48 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 23:38:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="142159298" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 23:38:46 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 23:38:45 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 14:38:43 +0800 From: "Hao, Xudong" To: "Jan Beulich (JBeulich@suse.com)" Thread-Topic: [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjw== Date: Sat, 12 May 2012 06:38:42 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Zhang, Xiantao" , "Nakajima, Jun" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow exception(#OF; generated by INTO) and int n instruction emulation. #BP and #OF should use software exception, which int n instruction should use software interrupt. Signed-off-by: Eddie Dong Signed-off-by: Xudong Hao diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t curr->arch.hvm_vmx.vmx_emulate = 1; } +/* + * Generate the virtual event to guest. + * NOTE: + * This is for processor execution generated exceptions, + * and INT 3(CC), INTO (CE) instruction emulation. It is + * not intended for the delivery of event due to emulation + * of INT nn (CD nn) instruction, which should use + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. + */ void vmx_inject_hw_exception(int trap, int error_code) { unsigned long intr_info; @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ break; + case TRAP_overflow: + type = X86_EVENTTYPE_SW_EXCEPTION; + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ + break; + default: if ( trap > TRAP_last_reserved ) { - type = X86_EVENTTYPE_SW_EXCEPTION; + type = X86_EVENTTYPE_SW_INTERRUPT; __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ } break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:39:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST5yd-0007CL-0s; Sat, 12 May 2012 06:38:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST5yc-0007CG-8A for xen-devel@lists.xen.org; Sat, 12 May 2012 06:38:50 +0000 Received: from [85.158.143.99:55347] by server-2.bemta-4.messagelabs.com id F4/F1-17550-9750EAF4; Sat, 12 May 2012 06:38:49 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1336804727!20118968!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzNjQy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16763 invoked from network); 12 May 2012 06:38:48 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-11.tower-216.messagelabs.com with SMTP; 12 May 2012 06:38:48 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 11 May 2012 23:38:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="142159298" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 11 May 2012 23:38:46 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 May 2012 23:38:45 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 14:38:43 +0800 From: "Hao, Xudong" To: "Jan Beulich (JBeulich@suse.com)" Thread-Topic: [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjw== Date: Sat, 12 May 2012 06:38:42 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Zhang, Xiantao" , "Nakajima, Jun" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow exception(#OF; generated by INTO) and int n instruction emulation. #BP and #OF should use software exception, which int n instruction should use software interrupt. Signed-off-by: Eddie Dong Signed-off-by: Xudong Hao diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t curr->arch.hvm_vmx.vmx_emulate = 1; } +/* + * Generate the virtual event to guest. + * NOTE: + * This is for processor execution generated exceptions, + * and INT 3(CC), INTO (CE) instruction emulation. It is + * not intended for the delivery of event due to emulation + * of INT nn (CD nn) instruction, which should use + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. + */ void vmx_inject_hw_exception(int trap, int error_code) { unsigned long intr_info; @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ break; + case TRAP_overflow: + type = X86_EVENTTYPE_SW_EXCEPTION; + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ + break; + default: if ( trap > TRAP_last_reserved ) { - type = X86_EVENTTYPE_SW_EXCEPTION; + type = X86_EVENTTYPE_SW_INTERRUPT; __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ } break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:49:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST686-0007La-38; Sat, 12 May 2012 06:48:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST683-0007LV-Vo for xen-devel@lists.xensource.com; Sat, 12 May 2012 06:48:36 +0000 Received: from [85.158.139.83:21952] by server-9.bemta-5.messagelabs.com id 1D/A9-09826-3C70EAF4; Sat, 12 May 2012 06:48:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336805313!28029765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26263 invoked from network); 12 May 2012 06:48:33 -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 May 2012 06:48:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439226" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 06:48:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 07:48:32 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1ST67z-0003wB-SW; Sat, 12 May 2012 06:48:31 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1ST67z-00049X-Oz; Sat, 12 May 2012 07:48:31 +0100 To: Message-ID: From: xen.org Date: Sat, 12 May 2012 07:48:31 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12856: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12856 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12856/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf-pin 9 guest-start fail pass in 12854 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12854 pass in 12856 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 12854 pass in 12856 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12854 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cd4dd23a831d baseline version: xen cd4dd23a831d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:49:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST686-0007La-38; Sat, 12 May 2012 06:48:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST683-0007LV-Vo for xen-devel@lists.xensource.com; Sat, 12 May 2012 06:48:36 +0000 Received: from [85.158.139.83:21952] by server-9.bemta-5.messagelabs.com id 1D/A9-09826-3C70EAF4; Sat, 12 May 2012 06:48:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1336805313!28029765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODY1Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26263 invoked from network); 12 May 2012 06:48:33 -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 May 2012 06:48:33 -0000 X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="12439226" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 06:48:32 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 07:48:32 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1ST67z-0003wB-SW; Sat, 12 May 2012 06:48:31 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1ST67z-00049X-Oz; Sat, 12 May 2012 07:48:31 +0100 To: Message-ID: From: xen.org Date: Sat, 12 May 2012 07:48:31 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12856: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12856 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12856/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf-pin 9 guest-start fail pass in 12854 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 12854 pass in 12856 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-localmigrate/x10 fail in 12854 pass in 12856 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12854 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass version targeted for testing: xen cd4dd23a831d baseline version: xen cd4dd23a831d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:50:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST69b-0007PE-I7; Sat, 12 May 2012 06:50:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST69Z-0007P4-7R for xen-devel@lists.xen.org; Sat, 12 May 2012 06:50:09 +0000 Received: from [85.158.139.83:62421] by server-10.bemta-5.messagelabs.com id 69/0B-08260-0280EAF4; Sat, 12 May 2012 06:50:08 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336805406!25285571!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25433 invoked from network); 12 May 2012 06:50:07 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 06:50:07 -0000 Received: by werf3 with SMTP id f3so1871196wer.32 for ; Fri, 11 May 2012 23:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=frEfaqsruexgMoun2Cns+7raRKyXIeweyHs4WqdZoqI=; b=bKGCMORcjopFmwFIQM29iAGhPg0otqpD0CP8g8VCRKsFij3D5pesIiVDrjuP26/l8Q oCpRrbSYH/iI/FbDcj9VquQJi2P6QwEs5x2sn1ryuh9a1xXx+Rc9xYgwMkgfxiwN7Mrv u5lSkeW4Uku7ISUaFnkrp3BKm7evflCYeG4aqerwdsLjEMiuZd2DhSkCQzA72/K9LB7A bC1BIT3jnhldxWwqKEIkor37HkBD7YYZdNRGoemMAuBEXC7yYbBVt/mMSEPfc6iJzRsK nyDSmKFiaamWC+sB0jOlFwvVxrJP7ZAE+qt1HAXStZFmrjSkj5f50ds1spwQPmuBs97m s1gw== Received: by 10.180.83.196 with SMTP id s4mr2099065wiy.15.1336805406462; Fri, 11 May 2012 23:50:06 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id du4sm26074962wib.10.2012.05.11.23.50.03 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 23:50:05 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sat, 12 May 2012 07:49:57 +0100 From: Keir Fraser To: "Hao, Xudong" , "Jan Beulich (JBeulich@suse.com)" Message-ID: Thread-Topic: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjwAAbpla In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@SHSMSX102.ccr.corp.intel.com> Mime-version: 1.0 Cc: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 12/05/2012 07:38, "Hao, Xudong" wrote: > Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #BP and #OF should use software exception, which int n instruction should use > software interrupt. This patch doesn't fix #BP, which is already using SW_EXCEPTION. It does however fix #DB, which was using SW_EXCEPTION and you fix to use HW_EXCEPTION. Also your new comment at the top of the function is a bit wishful. It may not be suitable to use this function for INT nn, but it *is* making a half-arsed attempt at handling it anyway, and it is being called for that purpose. Perhaps the comment should admit this, but indicate that this needs to go away during 4.3 development? Apart from these gripes, your code changes look correct. If this tests okay for others, we can check this in when you provide a fixed changeset description and code comment. -- Keir > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 > @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. It is > + * not intended for the delivery of event due to emulation > + * of INT nn (CD nn) instruction, which should use > + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. > + */ > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); > @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ > } > break; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 06:50:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 06: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 ) id 1ST69b-0007PE-I7; Sat, 12 May 2012 06:50:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST69Z-0007P4-7R for xen-devel@lists.xen.org; Sat, 12 May 2012 06:50:09 +0000 Received: from [85.158.139.83:62421] by server-10.bemta-5.messagelabs.com id 69/0B-08260-0280EAF4; Sat, 12 May 2012 06:50:08 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1336805406!25285571!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_DONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25433 invoked from network); 12 May 2012 06:50:07 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 06:50:07 -0000 Received: by werf3 with SMTP id f3so1871196wer.32 for ; Fri, 11 May 2012 23:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=frEfaqsruexgMoun2Cns+7raRKyXIeweyHs4WqdZoqI=; b=bKGCMORcjopFmwFIQM29iAGhPg0otqpD0CP8g8VCRKsFij3D5pesIiVDrjuP26/l8Q oCpRrbSYH/iI/FbDcj9VquQJi2P6QwEs5x2sn1ryuh9a1xXx+Rc9xYgwMkgfxiwN7Mrv u5lSkeW4Uku7ISUaFnkrp3BKm7evflCYeG4aqerwdsLjEMiuZd2DhSkCQzA72/K9LB7A bC1BIT3jnhldxWwqKEIkor37HkBD7YYZdNRGoemMAuBEXC7yYbBVt/mMSEPfc6iJzRsK nyDSmKFiaamWC+sB0jOlFwvVxrJP7ZAE+qt1HAXStZFmrjSkj5f50ds1spwQPmuBs97m s1gw== Received: by 10.180.83.196 with SMTP id s4mr2099065wiy.15.1336805406462; Fri, 11 May 2012 23:50:06 -0700 (PDT) Received: from [192.168.1.84] (host217-43-89-104.range217-43.btcentralplus.com. [217.43.89.104]) by mx.google.com with ESMTPS id du4sm26074962wib.10.2012.05.11.23.50.03 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 23:50:05 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sat, 12 May 2012 07:49:57 +0100 From: Keir Fraser To: "Hao, Xudong" , "Jan Beulich (JBeulich@suse.com)" Message-ID: Thread-Topic: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjwAAbpla In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@SHSMSX102.ccr.corp.intel.com> Mime-version: 1.0 Cc: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 12/05/2012 07:38, "Hao, Xudong" wrote: > Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #BP and #OF should use software exception, which int n instruction should use > software interrupt. This patch doesn't fix #BP, which is already using SW_EXCEPTION. It does however fix #DB, which was using SW_EXCEPTION and you fix to use HW_EXCEPTION. Also your new comment at the top of the function is a bit wishful. It may not be suitable to use this function for INT nn, but it *is* making a half-arsed attempt at handling it anyway, and it is being called for that purpose. Perhaps the comment should admit this, but indicate that this needs to go away during 4.3 development? Apart from these gripes, your code changes look correct. If this tests okay for others, we can check this in when you provide a fixed changeset description and code comment. -- Keir > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 > @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. It is > + * not intended for the delivery of event due to emulation > + * of INT nn (CD nn) instruction, which should use > + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. > + */ > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); > @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ > } > break; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:17:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6Zw-0007wF-8E; Sat, 12 May 2012 07:17:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6Zu-0007wA-5S for xen-devel@lists.xen.org; Sat, 12 May 2012 07:17:22 +0000 Received: from [85.158.139.83:26576] by server-1.bemta-5.messagelabs.com id 6E/0A-28458-18E0EAF4; Sat, 12 May 2012 07:17:21 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336807039!27987199!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzNjQy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20090 invoked from network); 12 May 2012 07:17:20 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-182.messagelabs.com with SMTP; 12 May 2012 07:17:20 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 12 May 2012 00:17:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="142165810" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 12 May 2012 00:17:18 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 12 May 2012 00:17:18 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 15:17:15 +0800 From: "Hao, Xudong" To: 'Keir Fraser' , "Jan Beulich (JBeulich@suse.com)" Thread-Topic: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjwAAbplaAAA7nnA= Date: Sat, 12 May 2012 07:17:14 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC2CFC@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@SHSMSX102.ccr.corp.intel.com> In-Reply-To: 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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: Saturday, May 12, 2012 2:50 PM > To: Hao, Xudong; Jan Beulich (JBeulich@suse.com) > Cc: Aravindh Puthiyaparambil; Dong, Eddie; Zhang, Xiantao; Nakajima, Jun; > xen-devel (xen-devel@lists.xen.org) > Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception > handler > > On 12/05/2012 07:38, "Hao, Xudong" wrote: > > > Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow > > exception(#OF; generated by INTO) and int n instruction emulation. > > > > #BP and #OF should use software exception, which int n instruction should > use > > software interrupt. > > This patch doesn't fix #BP, which is already using SW_EXCEPTION. It does > however fix #DB, which was using SW_EXCEPTION and you fix to use > HW_EXCEPTION. > Yes, it fixed #DB, #OF and int n , not for #BP. > Also your new comment at the top of the function is a bit wishful. It may > not be suitable to use this function for INT nn, but it *is* making a > half-arsed attempt at handling it anyway, and it is being called for that > purpose. Perhaps the comment should admit this, but indicate that this needs > to go away during 4.3 development? > No, the new comment on the top of function is a little suitable, I'll correct it. > Apart from these gripes, your code changes look correct. If this tests okay > for others, we can check this in when you provide a fixed changeset > description and code comment. > I'll supply next version to modify the description and comment. > -- Keir > > > Signed-off-by: Eddie Dong > > Signed-off-by: Xudong Hao > > > > diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c > > --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 > > +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 > > @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t > > curr->arch.hvm_vmx.vmx_emulate = 1; > > } > > > > +/* > > + * Generate the virtual event to guest. > > + * NOTE: > > + * This is for processor execution generated exceptions, > > + * and INT 3(CC), INTO (CE) instruction emulation. It is > > + * not intended for the delivery of event due to emulation > > + * of INT nn (CD nn) instruction, which should use > > + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. > > + */ > > void vmx_inject_hw_exception(int trap, int error_code) > > { > > unsigned long intr_info; > > @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i > > switch ( trap ) > > { > > case TRAP_debug: > > - type = X86_EVENTTYPE_SW_EXCEPTION; > > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > > { > > __restore_debug_registers(curr); > > @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i > > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > > break; > > > > + case TRAP_overflow: > > + type = X86_EVENTTYPE_SW_EXCEPTION; > > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > > + break; > > + > > default: > > if ( trap > TRAP_last_reserved ) > > { > > - type = X86_EVENTTYPE_SW_EXCEPTION; > > + type = X86_EVENTTYPE_SW_INTERRUPT; > > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 > */ > > } > > break; > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:17:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6Zw-0007wF-8E; Sat, 12 May 2012 07:17:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6Zu-0007wA-5S for xen-devel@lists.xen.org; Sat, 12 May 2012 07:17:22 +0000 Received: from [85.158.139.83:26576] by server-1.bemta-5.messagelabs.com id 6E/0A-28458-18E0EAF4; Sat, 12 May 2012 07:17:21 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1336807039!27987199!1 X-Originating-IP: [143.182.124.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjMzNjQy\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20090 invoked from network); 12 May 2012 07:17:20 -0000 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by server-2.tower-182.messagelabs.com with SMTP; 12 May 2012 07:17:20 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 12 May 2012 00:17:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="142165810" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 12 May 2012 00:17:18 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 12 May 2012 00:17:18 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 15:17:15 +0800 From: "Hao, Xudong" To: 'Keir Fraser' , "Jan Beulich (JBeulich@suse.com)" Thread-Topic: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler Thread-Index: Ac0wCbcSZBF1B8nJRNeU7sQ1kiyfjwAAbplaAAA7nnA= Date: Sat, 12 May 2012 07:17:14 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC2CFC@SHSMSX102.ccr.corp.intel.com> References: <403610A45A2B5242BD291EDAE8B37D300FDC28B5@SHSMSX102.ccr.corp.intel.com> In-Reply-To: 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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: Saturday, May 12, 2012 2:50 PM > To: Hao, Xudong; Jan Beulich (JBeulich@suse.com) > Cc: Aravindh Puthiyaparambil; Dong, Eddie; Zhang, Xiantao; Nakajima, Jun; > xen-devel (xen-devel@lists.xen.org) > Subject: Re: [Xen-devel] [PATCH] Fix the mistake for #BP and #OF exception > handler > > On 12/05/2012 07:38, "Hao, Xudong" wrote: > > > Fix the mistake for breakpoint exception(#BP; generated by INT3), overflow > > exception(#OF; generated by INTO) and int n instruction emulation. > > > > #BP and #OF should use software exception, which int n instruction should > use > > software interrupt. > > This patch doesn't fix #BP, which is already using SW_EXCEPTION. It does > however fix #DB, which was using SW_EXCEPTION and you fix to use > HW_EXCEPTION. > Yes, it fixed #DB, #OF and int n , not for #BP. > Also your new comment at the top of the function is a bit wishful. It may > not be suitable to use this function for INT nn, but it *is* making a > half-arsed attempt at handling it anyway, and it is being called for that > purpose. Perhaps the comment should admit this, but indicate that this needs > to go away during 4.3 development? > No, the new comment on the top of function is a little suitable, I'll correct it. > Apart from these gripes, your code changes look correct. If this tests okay > for others, we can check this in when you provide a fixed changeset > description and code comment. > I'll supply next version to modify the description and comment. > -- Keir > > > Signed-off-by: Eddie Dong > > Signed-off-by: Xudong Hao > > > > diff -r 98fe3b2a572d xen/arch/x86/hvm/vmx/vmx.c > > --- a/xen/arch/x86/hvm/vmx/vmx.c Tue May 01 14:20:37 2012 +0100 > > +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun May 12 03:14:04 2013 +0800 > > @@ -1350,6 +1350,15 @@ static void __vmx_inject_exception(int t > > curr->arch.hvm_vmx.vmx_emulate = 1; > > } > > > > +/* > > + * Generate the virtual event to guest. > > + * NOTE: > > + * This is for processor execution generated exceptions, > > + * and INT 3(CC), INTO (CE) instruction emulation. It is > > + * not intended for the delivery of event due to emulation > > + * of INT nn (CD nn) instruction, which should use > > + * X86_EVENTTYPE_SW_INTERRUPT as interrupt type. > > + */ > > void vmx_inject_hw_exception(int trap, int error_code) > > { > > unsigned long intr_info; > > @@ -1365,7 +1374,6 @@ void vmx_inject_hw_exception(int trap, i > > switch ( trap ) > > { > > case TRAP_debug: > > - type = X86_EVENTTYPE_SW_EXCEPTION; > > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > > { > > __restore_debug_registers(curr); > > @@ -1387,10 +1395,15 @@ void vmx_inject_hw_exception(int trap, i > > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > > break; > > > > + case TRAP_overflow: > > + type = X86_EVENTTYPE_SW_EXCEPTION; > > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > > + break; > > + > > default: > > if ( trap > TRAP_last_reserved ) > > { > > - type = X86_EVENTTYPE_SW_EXCEPTION; > > + type = X86_EVENTTYPE_SW_INTERRUPT; > > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 > */ > > } > > break; > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:20:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6cc-00081A-RU; Sat, 12 May 2012 07:20:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6cb-000813-FP for xen-devel@lists.xen.org; Sat, 12 May 2012 07:20:09 +0000 Received: from [193.109.254.147:53714] by server-1.bemta-14.messagelabs.com id 8A/4B-29372-82F0EAF4; Sat, 12 May 2012 07:20:08 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-11.tower-27.messagelabs.com!1336807207!2072657!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17397 invoked from network); 12 May 2012 07:20:07 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-11.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 12 May 2012 07:20:07 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49385 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ST6Y2-0002sZ-1x; Sat, 12 May 2012 09:15:26 +0200 Date: Sat, 12 May 2012 09:20:04 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <318116397.20120512092004@eikelenboom.it> To: Mark In-Reply-To: <20120512041645.11509848@internecto.net> References: <20120512041645.11509848@internecto.net> MIME-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Mark, Saturday, May 12, 2012, 4:16:45 AM, you wrote: > Hello everyone, > Said Xen version running on kernel 3.3.4 x86_64. > I had put in Grub's "module /vmlinuz.gz" line: > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) Should be xen-pciback.hide (not a underscore) -- Sander > This yields an error in dmesg: > xen_pciback: Unknown parameter `2)' > I tried all sorts of variations: quoting the pci devices, prefixing > the devices with an extra 0000:, putting the thing somewhere else. But > the error keeps returning. > I am working around this by having added the hide option in a > modules.conf entry. > For further contact please be aware I am not receiving xen-devel > emails, so please include me in CC's when more info is required. > Thank you, > Mark -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:20:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6cc-00081A-RU; Sat, 12 May 2012 07:20:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6cb-000813-FP for xen-devel@lists.xen.org; Sat, 12 May 2012 07:20:09 +0000 Received: from [193.109.254.147:53714] by server-1.bemta-14.messagelabs.com id 8A/4B-29372-82F0EAF4; Sat, 12 May 2012 07:20:08 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-11.tower-27.messagelabs.com!1336807207!2072657!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17397 invoked from network); 12 May 2012 07:20:07 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-11.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 12 May 2012 07:20:07 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49385 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ST6Y2-0002sZ-1x; Sat, 12 May 2012 09:15:26 +0200 Date: Sat, 12 May 2012 09:20:04 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <318116397.20120512092004@eikelenboom.it> To: Mark In-Reply-To: <20120512041645.11509848@internecto.net> References: <20120512041645.11509848@internecto.net> MIME-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Mark, Saturday, May 12, 2012, 4:16:45 AM, you wrote: > Hello everyone, > Said Xen version running on kernel 3.3.4 x86_64. > I had put in Grub's "module /vmlinuz.gz" line: > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) Should be xen-pciback.hide (not a underscore) -- Sander > This yields an error in dmesg: > xen_pciback: Unknown parameter `2)' > I tried all sorts of variations: quoting the pci devices, prefixing > the devices with an extra 0000:, putting the thing somewhere else. But > the error keeps returning. > I am working around this by having added the hide option in a > modules.conf entry. > For further contact please be aware I am not receiving xen-devel > emails, so please include me in CC's when more info is required. > Thank you, > Mark -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:29:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6lL-0008EB-TH; Sat, 12 May 2012 07:29:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6lK-0008E3-Ns for xen-devel@lists.xen.org; Sat, 12 May 2012 07:29:11 +0000 Received: from [85.158.143.35:40581] by server-3.bemta-4.messagelabs.com id 8C/00-05853-6411EAF4; Sat, 12 May 2012 07:29:10 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336807745!4695979!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21752 invoked from network); 12 May 2012 07:29:07 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 07:29:07 -0000 Received: by pbbro12 with SMTP id ro12so4467895pbb.32 for ; Sat, 12 May 2012 00:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BO/3b2ZUWIAaJao/NLZ1qxrl7v/o1a7lnzXAFn7iOMc=; b=jyO1FA79tdx/BIGCELp1u1rSTtk4e2T9T34+lHJizVHKk8VZ4hWdJzPLabG7X0Er6i WnBRLOcj4l7RlVmzhZUD3eZjKvUi79RgYZwv6A8QqCuAB1kDO7IPE6e1BAdxMakHlKPd xw1B92SD8XT2k7J4dpXNyvZMdz3I5FBTvnSi3e+JGdNI1yIpOzIAI0r08O+3K2e9XuA2 23DbBv+uzt8+wXQj1gqSnKz2/EXA9B3aucwKHi/D647c9Hv2pbIFJtFcmSEGcuicAWvK FvWOKzg0LBft//XiNFRdNmdpP6LbPPBmJfYuqUmvD4+7Qiq98durflB9kjJgynmuegMz +zvQ== MIME-Version: 1.0 Received: by 10.68.130.3 with SMTP id oa3mr2762561pbb.62.1336807743845; Sat, 12 May 2012 00:29:03 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Sat, 12 May 2012 00:29:03 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sat, 12 May 2012 15:29:03 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam wrote: > On Fri, May 11, 2012 at 10:53 PM, Ian Jackson = wrote: >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering = with openvpn"): >>> libxl/xend: name tap devices vifX.Y-emu >> >> Committed-by: Ian Jackson > > This is my backport version which excludes the following: > > Lastly also move libxl__device_* to a better place in the header, otherwi= se the > comment about evgen stuff isn't next to the associated functions (noticed= jsut > because I was going to add nic_devname near to the setdefault functions) > > I have tested with xm and xl with and without vifname set in domU > config for hvmdomain and pvdomain. Sorry, when re-test one of the test case failed... xm create hvmdomain with vifname set. I must have missed certain test case :( Kindest regards, Giam Teck Choon > > For your review and comments please. > > Thanks. > > Kindest regards, > Giam Teck Choon > > > > > libxl/xend: name tap devices vifX.Y-emu > > This prevents the udev scripts from operating on other tap devices (e.g. > openvpn etc) > > Correct the documentation for the "vifname" option which suggested it app= lied > to HVM tap devices only, which is not the case. > > Reported by Michael Young. > > Also fix the use of vifname with emulated devices. This is slightly compl= ex. > The current hotplug scripts rely on being able to parse the "tapX.Y" (now > "vifX.Y-emu") name in order to locate the xenstore backend dir relating t= o the > corresponding vif. This is because we cannot inject our own environment v= ars > into the tap hotplug events. However this means that if the tap is initia= lly > named with a user specified name (which will not match the expected schem= e) we > fail to do anything useful with the device. So now we create the initial = tap > device with the standard "vifX.Y-emu" name and the hotplug script will ha= ndle > the rename to the desired name. This is also how PV vif devices work -- t= hey > are always created by netback with the name vifX.Y and renamed in the scr= ipt. > > xen-unstable changeset: 25290:7a6dcecb1781 > Signed-off-by: Giam Teck Choon > --- > =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- > =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- > =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++++++-= ---------- > =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- > =A04 files changed, 21 insertions(+), 19 deletions(-) > > diff --git a/tools/hotplug/Linux/vif-common.sh > b/tools/hotplug/Linux/vif-common.sh > index c9c5d41..fff22bb 100644 > --- a/tools/hotplug/Linux/vif-common.sh > +++ b/tools/hotplug/Linux/vif-common.sh > @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then > =A0 =A0 : ${INTERFACE:?} > > =A0 =A0 # Get xenbus_path from device name. > - =A0 =A0# The name is built like that: "tap${domid}.${devid}". > - =A0 =A0dev_=3D${dev#tap} > + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". > + =A0 =A0dev_=3D${dev#vif} > + =A0 =A0dev_=3D${dev_%-emu} > =A0 =A0 domid=3D${dev_%.*} > =A0 =A0 devid=3D${dev_#*.} > > =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" > + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") > + =A0 =A0if [ "$vifname" ] > + =A0 =A0then > + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" > + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifna= me" >&/dev/null > + =A0 =A0 =A0 =A0then > + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" > + =A0 =A0 =A0 =A0fi > + =A0 =A0 =A0 =A0dev=3D"$vifname" > + =A0 =A0fi > =A0fi > > =A0ip=3D${ip:-} > diff --git a/tools/hotplug/Linux/xen-backend.rules > b/tools/hotplug/Linux/xen-backend.rules > index 40f2658..405387f 100644 > --- a/tools/hotplug/Linux/xen-backend.rules > +++ b/tools/hotplug/Linux/xen-backend.rules > @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", > NAME=3D"xen/blktap-2/control", MODE=3D"0600" > =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" > =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" > =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"06= 00" > -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", > RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" > +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", > RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 1ffcc90..2c030ca 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -134,11 +134,9 @@ static char ** > libxl_build_device_model_args_old(libxl__gc *gc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, > "%02x:%02x:%02x:%02x:%02x:%02x", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], > vifs[i].mac[1], vifs[i].mac[2], > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], > vifs[i].mac[4], vifs[i].mac[5]); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t= ap%d.%d", > info->domid, vifs[i].devid); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(gc= , "vif%d.%d-emu", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", l= ibxl__sprintf(gc, > "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, > smac, vifs[i].model), > @@ -271,12 +269,9 @@ static char ** > libxl_build_device_model_args_new(libxl__gc *gc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, > "%02x:%02x:%02x:%02x:%02x:%02x", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], > vifs[i].mac[1], vifs[i].mac[2], > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], > vifs[i].mac[4], vifs[i].mac[5]); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t= ap%d.%d", > info->domid, vifs[i].devid); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(gc= , "vif%d.%d-emu", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__sprintf(= gc, > "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid, sm= ac, vifs[i].model)); > diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image= .py > index f1464ac..3c8d80c 100644 > --- a/tools/python/xen/xend/image.py > +++ b/tools/python/xen/xend/image.py > @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model=3D%s= " % > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) > - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') > - =A0 =A0 =A0 =A0 =A0 =A0if vifname: > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname > - =A0 =A0 =A0 =A0 =A0 =A0else: > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDom= id(), nics-1) > + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDomid()= , nics-1) > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s= " % > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 07:29:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 07: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 ) id 1ST6lL-0008EB-TH; Sat, 12 May 2012 07:29:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST6lK-0008E3-Ns for xen-devel@lists.xen.org; Sat, 12 May 2012 07:29:11 +0000 Received: from [85.158.143.35:40581] by server-3.bemta-4.messagelabs.com id 8C/00-05853-6411EAF4; Sat, 12 May 2012 07:29:10 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1336807745!4695979!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21752 invoked from network); 12 May 2012 07:29:07 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 07:29:07 -0000 Received: by pbbro12 with SMTP id ro12so4467895pbb.32 for ; Sat, 12 May 2012 00:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BO/3b2ZUWIAaJao/NLZ1qxrl7v/o1a7lnzXAFn7iOMc=; b=jyO1FA79tdx/BIGCELp1u1rSTtk4e2T9T34+lHJizVHKk8VZ4hWdJzPLabG7X0Er6i WnBRLOcj4l7RlVmzhZUD3eZjKvUi79RgYZwv6A8QqCuAB1kDO7IPE6e1BAdxMakHlKPd xw1B92SD8XT2k7J4dpXNyvZMdz3I5FBTvnSi3e+JGdNI1yIpOzIAI0r08O+3K2e9XuA2 23DbBv+uzt8+wXQj1gqSnKz2/EXA9B3aucwKHi/D647c9Hv2pbIFJtFcmSEGcuicAWvK FvWOKzg0LBft//XiNFRdNmdpP6LbPPBmJfYuqUmvD4+7Qiq98durflB9kjJgynmuegMz +zvQ== MIME-Version: 1.0 Received: by 10.68.130.3 with SMTP id oa3mr2762561pbb.62.1336807743845; Sat, 12 May 2012 00:29:03 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Sat, 12 May 2012 00:29:03 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sat, 12 May 2012 15:29:03 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam wrote: > On Fri, May 11, 2012 at 10:53 PM, Ian Jackson = wrote: >> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering = with openvpn"): >>> libxl/xend: name tap devices vifX.Y-emu >> >> Committed-by: Ian Jackson > > This is my backport version which excludes the following: > > Lastly also move libxl__device_* to a better place in the header, otherwi= se the > comment about evgen stuff isn't next to the associated functions (noticed= jsut > because I was going to add nic_devname near to the setdefault functions) > > I have tested with xm and xl with and without vifname set in domU > config for hvmdomain and pvdomain. Sorry, when re-test one of the test case failed... xm create hvmdomain with vifname set. I must have missed certain test case :( Kindest regards, Giam Teck Choon > > For your review and comments please. > > Thanks. > > Kindest regards, > Giam Teck Choon > > > > > libxl/xend: name tap devices vifX.Y-emu > > This prevents the udev scripts from operating on other tap devices (e.g. > openvpn etc) > > Correct the documentation for the "vifname" option which suggested it app= lied > to HVM tap devices only, which is not the case. > > Reported by Michael Young. > > Also fix the use of vifname with emulated devices. This is slightly compl= ex. > The current hotplug scripts rely on being able to parse the "tapX.Y" (now > "vifX.Y-emu") name in order to locate the xenstore backend dir relating t= o the > corresponding vif. This is because we cannot inject our own environment v= ars > into the tap hotplug events. However this means that if the tap is initia= lly > named with a user specified name (which will not match the expected schem= e) we > fail to do anything useful with the device. So now we create the initial = tap > device with the standard "vifX.Y-emu" name and the hotplug script will ha= ndle > the rename to the desired name. This is also how PV vif devices work -- t= hey > are always created by netback with the name vifX.Y and renamed in the scr= ipt. > > xen-unstable changeset: 25290:7a6dcecb1781 > Signed-off-by: Giam Teck Choon > --- > =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- > =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- > =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++++++-= ---------- > =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- > =A04 files changed, 21 insertions(+), 19 deletions(-) > > diff --git a/tools/hotplug/Linux/vif-common.sh > b/tools/hotplug/Linux/vif-common.sh > index c9c5d41..fff22bb 100644 > --- a/tools/hotplug/Linux/vif-common.sh > +++ b/tools/hotplug/Linux/vif-common.sh > @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then > =A0 =A0 : ${INTERFACE:?} > > =A0 =A0 # Get xenbus_path from device name. > - =A0 =A0# The name is built like that: "tap${domid}.${devid}". > - =A0 =A0dev_=3D${dev#tap} > + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". > + =A0 =A0dev_=3D${dev#vif} > + =A0 =A0dev_=3D${dev_%-emu} > =A0 =A0 domid=3D${dev_%.*} > =A0 =A0 devid=3D${dev_#*.} > > =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" > + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") > + =A0 =A0if [ "$vifname" ] > + =A0 =A0then > + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" > + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifna= me" >&/dev/null > + =A0 =A0 =A0 =A0then > + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" > + =A0 =A0 =A0 =A0fi > + =A0 =A0 =A0 =A0dev=3D"$vifname" > + =A0 =A0fi > =A0fi > > =A0ip=3D${ip:-} > diff --git a/tools/hotplug/Linux/xen-backend.rules > b/tools/hotplug/Linux/xen-backend.rules > index 40f2658..405387f 100644 > --- a/tools/hotplug/Linux/xen-backend.rules > +++ b/tools/hotplug/Linux/xen-backend.rules > @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", > NAME=3D"xen/blktap-2/control", MODE=3D"0600" > =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" > =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" > =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"06= 00" > -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", > RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" > +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", > RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 1ffcc90..2c030ca 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -134,11 +134,9 @@ static char ** > libxl_build_device_model_args_old(libxl__gc *gc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, > "%02x:%02x:%02x:%02x:%02x:%02x", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], > vifs[i].mac[1], vifs[i].mac[2], > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], > vifs[i].mac[4], vifs[i].mac[5]); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t= ap%d.%d", > info->domid, vifs[i].devid); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(gc= , "vif%d.%d-emu", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", l= ibxl__sprintf(gc, > "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, > smac, vifs[i].model), > @@ -271,12 +269,9 @@ static char ** > libxl_build_device_model_args_new(libxl__gc *gc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, > "%02x:%02x:%02x:%02x:%02x:%02x", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], > vifs[i].mac[1], vifs[i].mac[2], > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], > vifs[i].mac[4], vifs[i].mac[5]); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "t= ap%d.%d", > info->domid, vifs[i].devid); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(gc= , "vif%d.%d-emu", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__sprintf(= gc, > "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid, sm= ac, vifs[i].model)); > diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image= .py > index f1464ac..3c8d80c 100644 > --- a/tools/python/xen/xend/image.py > +++ b/tools/python/xen/xend/image.py > @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model=3D%s= " % > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) > - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') > - =A0 =A0 =A0 =A0 =A0 =A0if vifname: > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname > - =A0 =A0 =A0 =A0 =A0 =A0else: > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDom= id(), nics-1) > + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDomid()= , nics-1) > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") > =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%s= " % > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 09:13:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 09: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 ) id 1ST8Nd-0000qP-Su; Sat, 12 May 2012 09:12:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST8Nc-0000qJ-Gc for xen-devel@lists.xen.org; Sat, 12 May 2012 09:12:48 +0000 Received: from [85.158.138.51:36868] by server-2.bemta-3.messagelabs.com id 8D/85-09269-F892EAF4; Sat, 12 May 2012 09:12:47 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336813965!26689151!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3Njkx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19510 invoked from network); 12 May 2012 09:12:46 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-8.tower-174.messagelabs.com with SMTP; 12 May 2012 09:12:46 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 12 May 2012 02:12:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99257650" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 12 May 2012 02:12:44 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 12 May 2012 02:12:44 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 17:12:41 +0800 From: "Hao, Xudong" To: "Jan Beulich (JBeulich@suse.com)" , "Keir Fraser (keir.xen@gmail.com)" Thread-Topic: [PATCH v2] Fix the mistake for #DB and #OF exception Thread-Index: Ac0wHoS1rWMeWTdrSEKneX/7Xlgnsw== Date: Sat, 12 May 2012 09:12:40 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix the mistake for debug exception(#DB; generated by INT1), overflow exception(#OF; generated by INTO) and int n instruction emulation. #DB should use hardware exception(except #DB generated by opcode 0xf1), #OF should use software exception, which int n instruction should use software interrupt. Signed-off-by: Eddie Dong Signed-off-by: Xudong Hao diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t curr->arch.hvm_vmx.vmx_emulate = 1; } +/* + * Generate the virtual event to guest. + * NOTE: + * This is for processor execution generated exceptions, + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and + * INT0 use software exception, and INT n should use + * software interrupt. + */ void vmx_inject_hw_exception(int trap, int error_code) { unsigned long intr_info; @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ break; + case TRAP_overflow: + type = X86_EVENTTYPE_SW_EXCEPTION; + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ + break; + default: if ( trap > TRAP_last_reserved ) { - type = X86_EVENTTYPE_SW_EXCEPTION; + type = X86_EVENTTYPE_SW_INTERRUPT; __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ } break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 09:13:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 09: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 ) id 1ST8Nd-0000qP-Su; Sat, 12 May 2012 09:12:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ST8Nc-0000qJ-Gc for xen-devel@lists.xen.org; Sat, 12 May 2012 09:12:48 +0000 Received: from [85.158.138.51:36868] by server-2.bemta-3.messagelabs.com id 8D/85-09269-F892EAF4; Sat, 12 May 2012 09:12:47 +0000 X-Env-Sender: xudong.hao@intel.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1336813965!26689151!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3Njkx\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19510 invoked from network); 12 May 2012 09:12:46 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-8.tower-174.messagelabs.com with SMTP; 12 May 2012 09:12:46 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 12 May 2012 02:12:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99257650" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 12 May 2012 02:12:44 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 12 May 2012 02:12:44 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.6]) with mapi id 14.01.0355.002; Sat, 12 May 2012 17:12:41 +0800 From: "Hao, Xudong" To: "Jan Beulich (JBeulich@suse.com)" , "Keir Fraser (keir.xen@gmail.com)" Thread-Topic: [PATCH v2] Fix the mistake for #DB and #OF exception Thread-Index: Ac0wHoS1rWMeWTdrSEKneX/7Xlgnsw== Date: Sat, 12 May 2012 09:12:40 +0000 Message-ID: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fix the mistake for debug exception(#DB; generated by INT1), overflow exception(#OF; generated by INTO) and int n instruction emulation. #DB should use hardware exception(except #DB generated by opcode 0xf1), #OF should use software exception, which int n instruction should use software interrupt. Signed-off-by: Eddie Dong Signed-off-by: Xudong Hao diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t curr->arch.hvm_vmx.vmx_emulate = 1; } +/* + * Generate the virtual event to guest. + * NOTE: + * This is for processor execution generated exceptions, + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and + * INT0 use software exception, and INT n should use + * software interrupt. + */ void vmx_inject_hw_exception(int trap, int error_code) { unsigned long intr_info; @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ break; + case TRAP_overflow: + type = X86_EVENTTYPE_SW_EXCEPTION; + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ + break; + default: if ( trap > TRAP_last_reserved ) { - type = X86_EVENTTYPE_SW_EXCEPTION; + type = X86_EVENTTYPE_SW_INTERRUPT; __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ } break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 22:01:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 22: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 ) id 1STKMi-0002vA-CR; Sat, 12 May 2012 22:00:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKMh-0002v5-4L for xen-devel@lists.xen.org; Sat, 12 May 2012 22:00:39 +0000 Received: from [85.158.143.99:46536] by server-1.bemta-4.messagelabs.com id 19/54-20925-68DDEAF4; Sat, 12 May 2012 22:00:38 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336860034!20685030!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24864 invoked from network); 12 May 2012 22:00:36 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 22:00:36 -0000 Received: by pbbro12 with SMTP id ro12so4937138pbb.32 for ; Sat, 12 May 2012 15:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJbt5+WNAb8xWXViFbednmuMXoU8lyhmbyfT3VDttE4=; b=y+J0WVQmw9LJ4Q9P40SE9YjdsC8E5j+FZvqIKop4FKQ8JKjQIkkkWxYy5h4Oocgd+8 Av2rrLFX3S7YGE1JnZ4nGewFBmtGXTQxj4DoUd4URohztzfFE+twiGWNfWoxJZ+VFF5P Dg7h6O4E3C0g+YTb6VfvnZtF1JYFLpctf9DU0P9v5npi5ldRB+wC920MbFhj3uVteeLI toHztHcAylOlYdmpL5HL1RthKhxZM2+6tL0OZtuMqoyA2w+j4IJjz69g/S/AsmVmB1CV W1pRsF1v5z39a7bkMxO+4C5KvJTn5gmOtJ8XyzVlT7JjEXiwCNmR80PDmfBQr2W+nVAp QHBA== MIME-Version: 1.0 Received: by 10.68.242.33 with SMTP id wn1mr7904182pbc.167.1336860034054; Sat, 12 May 2012 15:00:34 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Sat, 12 May 2012 15:00:33 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sun, 13 May 2012 06:00:33 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam wrote: > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam > wrote: >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering= with openvpn"): >>>> libxl/xend: name tap devices vifX.Y-emu >>> >>> Committed-by: Ian Jackson >> >> This is my backport version which excludes the following: >> >> Lastly also move libxl__device_* to a better place in the header, otherw= ise the >> comment about evgen stuff isn't next to the associated functions (notice= d jsut >> because I was going to add nic_devname near to the setdefault functions) >> >> I have tested with xm and xl with and without vifname set in domU >> config for hvmdomain and pvdomain. > > Sorry, when re-test one of the test case failed... xm create hvmdomain > with vifname set. =A0I must have missed certain test case :( The same test case failed for xen unstable latest changeset 25326:cd4dd23a8= 31d. My tests as below: 1. xm create pvdomain without vifname set 2. xl create pvdomain without vifname set 3. xm create hvmdomain without vifname set 4. xl create hvmdomain without vifname set 5. xm create pvdomain with vifname set 6. xl create pvdomain with vifname set 7. xm create hvmdomain with vifname set 8. xl create hvmdomain with vifname set Thanks. Kindest regards, > > Kindest regards, > Giam Teck Choon > > > >> >> For your review and comments please. >> >> Thanks. >> >> Kindest regards, >> Giam Teck Choon >> >> >> >> >> libxl/xend: name tap devices vifX.Y-emu >> >> This prevents the udev scripts from operating on other tap devices (e.g. >> openvpn etc) >> >> Correct the documentation for the "vifname" option which suggested it ap= plied >> to HVM tap devices only, which is not the case. >> >> Reported by Michael Young. >> >> Also fix the use of vifname with emulated devices. This is slightly comp= lex. >> The current hotplug scripts rely on being able to parse the "tapX.Y" (now >> "vifX.Y-emu") name in order to locate the xenstore backend dir relating = to the >> corresponding vif. This is because we cannot inject our own environment = vars >> into the tap hotplug events. However this means that if the tap is initi= ally >> named with a user specified name (which will not match the expected sche= me) we >> fail to do anything useful with the device. So now we create the initial= tap >> device with the standard "vifX.Y-emu" name and the hotplug script will h= andle >> the rename to the desired name. This is also how PV vif devices work -- = they >> are always created by netback with the name vifX.Y and renamed in the sc= ript. >> >> xen-unstable changeset: 25290:7a6dcecb1781 >> Signed-off-by: Giam Teck Choon >> --- >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++++++= ----------- >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >> =A04 files changed, 21 insertions(+), 19 deletions(-) >> >> diff --git a/tools/hotplug/Linux/vif-common.sh >> b/tools/hotplug/Linux/vif-common.sh >> index c9c5d41..fff22bb 100644 >> --- a/tools/hotplug/Linux/vif-common.sh >> +++ b/tools/hotplug/Linux/vif-common.sh >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >> =A0 =A0 : ${INTERFACE:?} >> >> =A0 =A0 # Get xenbus_path from device name. >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >> - =A0 =A0dev_=3D${dev#tap} >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >> + =A0 =A0dev_=3D${dev#vif} >> + =A0 =A0dev_=3D${dev_%-emu} >> =A0 =A0 domid=3D${dev_%.*} >> =A0 =A0 devid=3D${dev_#*.} >> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") >> + =A0 =A0if [ "$vifname" ] >> + =A0 =A0then >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifn= ame" >&/dev/null >> + =A0 =A0 =A0 =A0then >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" >> + =A0 =A0 =A0 =A0fi >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >> + =A0 =A0fi >> =A0fi >> >> =A0ip=3D${ip:-} >> diff --git a/tools/hotplug/Linux/xen-backend.rules >> b/tools/hotplug/Linux/xen-backend.rules >> index 40f2658..405387f 100644 >> --- a/tools/hotplug/Linux/xen-backend.rules >> +++ b/tools/hotplug/Linux/xen-backend.rules >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0= 600" >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> index 1ffcc90..2c030ca 100644 >> --- a/tools/libxl/libxl_dm.c >> +++ b/tools/libxl/libxl_dm.c >> @@ -134,11 +134,9 @@ static char ** >> libxl_build_device_model_args_old(libxl__gc *gc, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> "%02x:%02x:%02x:%02x:%02x:%02x", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], >> vifs[i].mac[1], vifs[i].mac[2], >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], >> vifs[i].mac[4], vifs[i].mac[5]); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "= tap%d.%d", >> info->domid, vifs[i].devid); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(g= c, "vif%d.%d-emu", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", = libxl__sprintf(gc, >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >> smac, vifs[i].model), >> @@ -271,12 +269,9 @@ static char ** >> libxl_build_device_model_args_new(libxl__gc *gc, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> "%02x:%02x:%02x:%02x:%02x:%02x", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], >> vifs[i].mac[1], vifs[i].mac[2], >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], >> vifs[i].mac[4], vifs[i].mac[5]); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "= tap%d.%d", >> info->domid, vifs[i].devid); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(g= c, "vif%d.%d-emu", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__sprintf= (gc, >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid, s= mac, vifs[i].model)); >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/imag= e.py >> index f1464ac..3c8d80c 100644 >> --- a/tools/python/xen/xend/image.py >> +++ b/tools/python/xen/xend/image.py >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model=3D%= s" % >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >> - =A0 =A0 =A0 =A0 =A0 =A0else: >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDo= mid(), nics-1) >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDomid(= ), nics-1) >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%= s" % >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 22:01:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 22: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 ) id 1STKMi-0002vA-CR; Sat, 12 May 2012 22:00:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKMh-0002v5-4L for xen-devel@lists.xen.org; Sat, 12 May 2012 22:00:39 +0000 Received: from [85.158.143.99:46536] by server-1.bemta-4.messagelabs.com id 19/54-20925-68DDEAF4; Sat, 12 May 2012 22:00:38 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1336860034!20685030!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24864 invoked from network); 12 May 2012 22:00:36 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 22:00:36 -0000 Received: by pbbro12 with SMTP id ro12so4937138pbb.32 for ; Sat, 12 May 2012 15:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJbt5+WNAb8xWXViFbednmuMXoU8lyhmbyfT3VDttE4=; b=y+J0WVQmw9LJ4Q9P40SE9YjdsC8E5j+FZvqIKop4FKQ8JKjQIkkkWxYy5h4Oocgd+8 Av2rrLFX3S7YGE1JnZ4nGewFBmtGXTQxj4DoUd4URohztzfFE+twiGWNfWoxJZ+VFF5P Dg7h6O4E3C0g+YTb6VfvnZtF1JYFLpctf9DU0P9v5npi5ldRB+wC920MbFhj3uVteeLI toHztHcAylOlYdmpL5HL1RthKhxZM2+6tL0OZtuMqoyA2w+j4IJjz69g/S/AsmVmB1CV W1pRsF1v5z39a7bkMxO+4C5KvJTn5gmOtJ8XyzVlT7JjEXiwCNmR80PDmfBQr2W+nVAp QHBA== MIME-Version: 1.0 Received: by 10.68.242.33 with SMTP id wn1mr7904182pbc.167.1336860034054; Sat, 12 May 2012 15:00:34 -0700 (PDT) Received: by 10.68.189.133 with HTTP; Sat, 12 May 2012 15:00:33 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Date: Sun, 13 May 2012 06:00:33 +0800 Message-ID: From: Teck Choon Giam To: Ian Jackson Cc: Roger Pau Monne , "xen-devel@lists.xen.org" , Ian Campbell , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam wrote: > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam > wrote: >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering= with openvpn"): >>>> libxl/xend: name tap devices vifX.Y-emu >>> >>> Committed-by: Ian Jackson >> >> This is my backport version which excludes the following: >> >> Lastly also move libxl__device_* to a better place in the header, otherw= ise the >> comment about evgen stuff isn't next to the associated functions (notice= d jsut >> because I was going to add nic_devname near to the setdefault functions) >> >> I have tested with xm and xl with and without vifname set in domU >> config for hvmdomain and pvdomain. > > Sorry, when re-test one of the test case failed... xm create hvmdomain > with vifname set. =A0I must have missed certain test case :( The same test case failed for xen unstable latest changeset 25326:cd4dd23a8= 31d. My tests as below: 1. xm create pvdomain without vifname set 2. xl create pvdomain without vifname set 3. xm create hvmdomain without vifname set 4. xl create hvmdomain without vifname set 5. xm create pvdomain with vifname set 6. xl create pvdomain with vifname set 7. xm create hvmdomain with vifname set 8. xl create hvmdomain with vifname set Thanks. Kindest regards, > > Kindest regards, > Giam Teck Choon > > > >> >> For your review and comments please. >> >> Thanks. >> >> Kindest regards, >> Giam Teck Choon >> >> >> >> >> libxl/xend: name tap devices vifX.Y-emu >> >> This prevents the udev scripts from operating on other tap devices (e.g. >> openvpn etc) >> >> Correct the documentation for the "vifname" option which suggested it ap= plied >> to HVM tap devices only, which is not the case. >> >> Reported by Michael Young. >> >> Also fix the use of vifname with emulated devices. This is slightly comp= lex. >> The current hotplug scripts rely on being able to parse the "tapX.Y" (now >> "vifX.Y-emu") name in order to locate the xenstore backend dir relating = to the >> corresponding vif. This is because we cannot inject our own environment = vars >> into the tap hotplug events. However this means that if the tap is initi= ally >> named with a user specified name (which will not match the expected sche= me) we >> fail to do anything useful with the device. So now we create the initial= tap >> device with the standard "vifX.Y-emu" name and the hotplug script will h= andle >> the rename to the desired name. This is also how PV vif devices work -- = they >> are always created by netback with the name vifX.Y and renamed in the sc= ript. >> >> xen-unstable changeset: 25290:7a6dcecb1781 >> Signed-off-by: Giam Teck Choon >> --- >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++++++= ----------- >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >> =A04 files changed, 21 insertions(+), 19 deletions(-) >> >> diff --git a/tools/hotplug/Linux/vif-common.sh >> b/tools/hotplug/Linux/vif-common.sh >> index c9c5d41..fff22bb 100644 >> --- a/tools/hotplug/Linux/vif-common.sh >> +++ b/tools/hotplug/Linux/vif-common.sh >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >> =A0 =A0 : ${INTERFACE:?} >> >> =A0 =A0 # Get xenbus_path from device name. >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >> - =A0 =A0dev_=3D${dev#tap} >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >> + =A0 =A0dev_=3D${dev#vif} >> + =A0 =A0dev_=3D${dev_%-emu} >> =A0 =A0 domid=3D${dev_%.*} >> =A0 =A0 devid=3D${dev_#*.} >> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") >> + =A0 =A0if [ "$vifname" ] >> + =A0 =A0then >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifn= ame" >&/dev/null >> + =A0 =A0 =A0 =A0then >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" >> + =A0 =A0 =A0 =A0fi >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >> + =A0 =A0fi >> =A0fi >> >> =A0ip=3D${ip:-} >> diff --git a/tools/hotplug/Linux/xen-backend.rules >> b/tools/hotplug/Linux/xen-backend.rules >> index 40f2658..405387f 100644 >> --- a/tools/hotplug/Linux/xen-backend.rules >> +++ b/tools/hotplug/Linux/xen-backend.rules >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE=3D"0= 600" >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> index 1ffcc90..2c030ca 100644 >> --- a/tools/libxl/libxl_dm.c >> +++ b/tools/libxl/libxl_dm.c >> @@ -134,11 +134,9 @@ static char ** >> libxl_build_device_model_args_old(libxl__gc *gc, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> "%02x:%02x:%02x:%02x:%02x:%02x", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], >> vifs[i].mac[1], vifs[i].mac[2], >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], >> vifs[i].mac[4], vifs[i].mac[5]); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "= tap%d.%d", >> info->domid, vifs[i].devid); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(g= c, "vif%d.%d-emu", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net", = libxl__sprintf(gc, >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >> smac, vifs[i].model), >> @@ -271,12 +269,9 @@ static char ** >> libxl_build_device_model_args_new(libxl__gc *gc, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> "%02x:%02x:%02x:%02x:%02x:%02x", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[0], >> vifs[i].mac[1], vifs[i].mac[2], >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vifs[i].mac[3], >> vifs[i].mac[4], vifs[i].mac[5]); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc, "= tap%d.%d", >> info->domid, vifs[i].devid); >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprintf(g= c, "vif%d.%d-emu", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__sprintf= (gc, >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid, s= mac, vifs[i].model)); >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/imag= e.py >> index f1464ac..3c8d80c 100644 >> --- a/tools/python/xen/xend/image.py >> +++ b/tools/python/xen/xend/image.py >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model=3D%= s" % >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >> - =A0 =A0 =A0 =A0 =A0 =A0else: >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.getDo= mid(), nics-1) >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDomid(= ), nics-1) >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge=3D%= s" % >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 22:31:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 22:31:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKpl-0003D2-Tj; Sat, 12 May 2012 22:30:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKpk-0003Cx-6n for xen-devel@lists.xen.org; Sat, 12 May 2012 22:30:40 +0000 Received: from [85.158.138.51:59708] by server-8.bemta-3.messagelabs.com id 46/4B-24428-F84EEAF4; Sat, 12 May 2012 22:30:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336861838!18696697!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODc4Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8616 invoked from network); 12 May 2012 22:30: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; 12 May 2012 22:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,577,1330905600"; d="scan'208";a="12442322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 22:30:38 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 23:30:38 +0100 Message-ID: <1336861837.3891.29.camel@dagon.hellion.org.uk> From: Ian Campbell To: Teck Choon Giam Date: Sat, 12 May 2012 23:30:37 +0100 In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: > On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam > wrote: > > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam > > wrote: > >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: > >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): > >>>> libxl/xend: name tap devices vifX.Y-emu > >>> > >>> Committed-by: Ian Jackson > >> > >> This is my backport version which excludes the following: > >> > >> Lastly also move libxl__device_* to a better place in the header, otherwise the > >> comment about evgen stuff isn't next to the associated functions (noticed jsut > >> because I was going to add nic_devname near to the setdefault functions) > >> > >> I have tested with xm and xl with and without vifname set in domU > >> config for hvmdomain and pvdomain. > > > > Sorry, when re-test one of the test case failed... xm create hvmdomain > > with vifname set. I must have missed certain test case :( > > The same test case failed for xen unstable latest changeset 25326:cd4dd23a831d. Oh dear. > My tests as below: Which ones fail? > 1. xm create pvdomain without vifname set > 2. xl create pvdomain without vifname set > 3. xm create hvmdomain without vifname set > 4. xl create hvmdomain without vifname set > 5. xm create pvdomain with vifname set > 6. xl create pvdomain with vifname set > 7. xm create hvmdomain with vifname set > 8. xl create hvmdomain with vifname set > > Thanks. > > Kindest regards, > > > > > > Kindest regards, > > Giam Teck Choon > > > > > > > >> > >> For your review and comments please. > >> > >> Thanks. > >> > >> Kindest regards, > >> Giam Teck Choon > >> > >> > >> > >> > >> libxl/xend: name tap devices vifX.Y-emu > >> > >> This prevents the udev scripts from operating on other tap devices (e.g. > >> openvpn etc) > >> > >> Correct the documentation for the "vifname" option which suggested it applied > >> to HVM tap devices only, which is not the case. > >> > >> Reported by Michael Young. > >> > >> Also fix the use of vifname with emulated devices. This is slightly complex. > >> The current hotplug scripts rely on being able to parse the "tapX.Y" (now > >> "vifX.Y-emu") name in order to locate the xenstore backend dir relating to the > >> corresponding vif. This is because we cannot inject our own environment vars > >> into the tap hotplug events. However this means that if the tap is initially > >> named with a user specified name (which will not match the expected scheme) we > >> fail to do anything useful with the device. So now we create the initial tap > >> device with the standard "vifX.Y-emu" name and the hotplug script will handle > >> the rename to the desired name. This is also how PV vif devices work -- they > >> are always created by netback with the name vifX.Y and renamed in the script. > >> > >> xen-unstable changeset: 25290:7a6dcecb1781 > >> Signed-off-by: Giam Teck Choon > >> --- > >> tools/hotplug/Linux/vif-common.sh | 15 +++++++++++++-- > >> tools/hotplug/Linux/xen-backend.rules | 2 +- > >> tools/libxl/libxl_dm.c | 17 ++++++----------- > >> tools/python/xen/xend/image.py | 6 +----- > >> 4 files changed, 21 insertions(+), 19 deletions(-) > >> > >> diff --git a/tools/hotplug/Linux/vif-common.sh > >> b/tools/hotplug/Linux/vif-common.sh > >> index c9c5d41..fff22bb 100644 > >> --- a/tools/hotplug/Linux/vif-common.sh > >> +++ b/tools/hotplug/Linux/vif-common.sh > >> @@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then > >> : ${INTERFACE:?} > >> > >> # Get xenbus_path from device name. > >> - # The name is built like that: "tap${domid}.${devid}". > >> - dev_=${dev#tap} > >> + # The name is built like that: "vif${domid}.${devid}-emu". > >> + dev_=${dev#vif} > >> + dev_=${dev_%-emu} > >> domid=${dev_%.*} > >> devid=${dev_#*.} > >> > >> XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid" > >> + vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "") > >> + if [ "$vifname" ] > >> + then > >> + vifname="${vifname}-emu" > >> + if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null > >> + then > >> + do_or_die ip link set "$dev" name "$vifname" > >> + fi > >> + dev="$vifname" > >> + fi > >> fi > >> > >> ip=${ip:-} > >> diff --git a/tools/hotplug/Linux/xen-backend.rules > >> b/tools/hotplug/Linux/xen-backend.rules > >> index 40f2658..405387f 100644 > >> --- a/tools/hotplug/Linux/xen-backend.rules > >> +++ b/tools/hotplug/Linux/xen-backend.rules > >> @@ -13,4 +13,4 @@ KERNEL=="blktap-control", > >> NAME="xen/blktap-2/control", MODE="0600" > >> KERNEL=="gntdev", NAME="xen/%k", MODE="0600" > >> KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" > >> KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" > >> -SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", > >> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" > >> +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", > >> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" > >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > >> index 1ffcc90..2c030ca 100644 > >> --- a/tools/libxl/libxl_dm.c > >> +++ b/tools/libxl/libxl_dm.c > >> @@ -134,11 +134,9 @@ static char ** > >> libxl_build_device_model_args_old(libxl__gc *gc, > >> char *smac = libxl__sprintf(gc, > >> "%02x:%02x:%02x:%02x:%02x:%02x", > >> vifs[i].mac[0], > >> vifs[i].mac[1], vifs[i].mac[2], > >> vifs[i].mac[3], > >> vifs[i].mac[4], vifs[i].mac[5]); > >> - char *ifname; > >> - if (!vifs[i].ifname) > >> - ifname = libxl__sprintf(gc, "tap%d.%d", > >> info->domid, vifs[i].devid); > >> - else > >> - ifname = vifs[i].ifname; > >> + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", > >> + info->domid, > >> + vifs[i].devid); > >> flexarray_vappend(dm_args, > >> "-net", libxl__sprintf(gc, > >> "nic,vlan=%d,macaddr=%s,model=%s", > >> vifs[i].devid, > >> smac, vifs[i].model), > >> @@ -271,12 +269,9 @@ static char ** > >> libxl_build_device_model_args_new(libxl__gc *gc, > >> char *smac = libxl__sprintf(gc, > >> "%02x:%02x:%02x:%02x:%02x:%02x", > >> vifs[i].mac[0], > >> vifs[i].mac[1], vifs[i].mac[2], > >> vifs[i].mac[3], > >> vifs[i].mac[4], vifs[i].mac[5]); > >> - char *ifname; > >> - if (!vifs[i].ifname) { > >> - ifname = libxl__sprintf(gc, "tap%d.%d", > >> info->domid, vifs[i].devid); > >> - } else { > >> - ifname = vifs[i].ifname; > >> - } > >> + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", > >> + info->domid, > >> + vifs[i].devid); > >> flexarray_append(dm_args, "-net"); > >> flexarray_append(dm_args, libxl__sprintf(gc, > >> "nic,vlan=%d,macaddr=%s,model=%s", > >> vifs[i].devid, smac, vifs[i].model)); > >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py > >> index f1464ac..3c8d80c 100644 > >> --- a/tools/python/xen/xend/image.py > >> +++ b/tools/python/xen/xend/image.py > >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): > >> ret.append("-net") > >> ret.append("nic,vlan=%d,macaddr=%s,model=%s" % > >> (nics, mac, model)) > >> - vifname = devinfo.get('vifname') > >> - if vifname: > >> - vifname = "tap-" + vifname > >> - else: > >> - vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1) > >> + vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1) > >> ret.append("-net") > >> ret.append("tap,vlan=%d,ifname=%s,bridge=%s" % > >> (nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 22:31:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 22:31:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKpl-0003D2-Tj; Sat, 12 May 2012 22:30:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STKpk-0003Cx-6n for xen-devel@lists.xen.org; Sat, 12 May 2012 22:30:40 +0000 Received: from [85.158.138.51:59708] by server-8.bemta-3.messagelabs.com id 46/4B-24428-F84EEAF4; Sat, 12 May 2012 22:30:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1336861838!18696697!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODc4Nw==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8616 invoked from network); 12 May 2012 22:30: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; 12 May 2012 22:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.75,577,1330905600"; d="scan'208";a="12442322" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 May 2012 22:30:38 +0000 Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sat, 12 May 2012 23:30:38 +0100 Message-ID: <1336861837.3891.29.camel@dagon.hellion.org.uk> From: Ian Campbell To: Teck Choon Giam Date: Sat, 12 May 2012 23:30:37 +0100 In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: > On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam > wrote: > > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam > > wrote: > >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: > >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfering with openvpn"): > >>>> libxl/xend: name tap devices vifX.Y-emu > >>> > >>> Committed-by: Ian Jackson > >> > >> This is my backport version which excludes the following: > >> > >> Lastly also move libxl__device_* to a better place in the header, otherwise the > >> comment about evgen stuff isn't next to the associated functions (noticed jsut > >> because I was going to add nic_devname near to the setdefault functions) > >> > >> I have tested with xm and xl with and without vifname set in domU > >> config for hvmdomain and pvdomain. > > > > Sorry, when re-test one of the test case failed... xm create hvmdomain > > with vifname set. I must have missed certain test case :( > > The same test case failed for xen unstable latest changeset 25326:cd4dd23a831d. Oh dear. > My tests as below: Which ones fail? > 1. xm create pvdomain without vifname set > 2. xl create pvdomain without vifname set > 3. xm create hvmdomain without vifname set > 4. xl create hvmdomain without vifname set > 5. xm create pvdomain with vifname set > 6. xl create pvdomain with vifname set > 7. xm create hvmdomain with vifname set > 8. xl create hvmdomain with vifname set > > Thanks. > > Kindest regards, > > > > > > Kindest regards, > > Giam Teck Choon > > > > > > > >> > >> For your review and comments please. > >> > >> Thanks. > >> > >> Kindest regards, > >> Giam Teck Choon > >> > >> > >> > >> > >> libxl/xend: name tap devices vifX.Y-emu > >> > >> This prevents the udev scripts from operating on other tap devices (e.g. > >> openvpn etc) > >> > >> Correct the documentation for the "vifname" option which suggested it applied > >> to HVM tap devices only, which is not the case. > >> > >> Reported by Michael Young. > >> > >> Also fix the use of vifname with emulated devices. This is slightly complex. > >> The current hotplug scripts rely on being able to parse the "tapX.Y" (now > >> "vifX.Y-emu") name in order to locate the xenstore backend dir relating to the > >> corresponding vif. This is because we cannot inject our own environment vars > >> into the tap hotplug events. However this means that if the tap is initially > >> named with a user specified name (which will not match the expected scheme) we > >> fail to do anything useful with the device. So now we create the initial tap > >> device with the standard "vifX.Y-emu" name and the hotplug script will handle > >> the rename to the desired name. This is also how PV vif devices work -- they > >> are always created by netback with the name vifX.Y and renamed in the script. > >> > >> xen-unstable changeset: 25290:7a6dcecb1781 > >> Signed-off-by: Giam Teck Choon > >> --- > >> tools/hotplug/Linux/vif-common.sh | 15 +++++++++++++-- > >> tools/hotplug/Linux/xen-backend.rules | 2 +- > >> tools/libxl/libxl_dm.c | 17 ++++++----------- > >> tools/python/xen/xend/image.py | 6 +----- > >> 4 files changed, 21 insertions(+), 19 deletions(-) > >> > >> diff --git a/tools/hotplug/Linux/vif-common.sh > >> b/tools/hotplug/Linux/vif-common.sh > >> index c9c5d41..fff22bb 100644 > >> --- a/tools/hotplug/Linux/vif-common.sh > >> +++ b/tools/hotplug/Linux/vif-common.sh > >> @@ -85,12 +85,23 @@ elif [ "$type_if" = tap ]; then > >> : ${INTERFACE:?} > >> > >> # Get xenbus_path from device name. > >> - # The name is built like that: "tap${domid}.${devid}". > >> - dev_=${dev#tap} > >> + # The name is built like that: "vif${domid}.${devid}-emu". > >> + dev_=${dev#vif} > >> + dev_=${dev_%-emu} > >> domid=${dev_%.*} > >> devid=${dev_#*.} > >> > >> XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid" > >> + vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "") > >> + if [ "$vifname" ] > >> + then > >> + vifname="${vifname}-emu" > >> + if [ "$command" == "add" ] && ! ip link show "$vifname" >&/dev/null > >> + then > >> + do_or_die ip link set "$dev" name "$vifname" > >> + fi > >> + dev="$vifname" > >> + fi > >> fi > >> > >> ip=${ip:-} > >> diff --git a/tools/hotplug/Linux/xen-backend.rules > >> b/tools/hotplug/Linux/xen-backend.rules > >> index 40f2658..405387f 100644 > >> --- a/tools/hotplug/Linux/xen-backend.rules > >> +++ b/tools/hotplug/Linux/xen-backend.rules > >> @@ -13,4 +13,4 @@ KERNEL=="blktap-control", > >> NAME="xen/blktap-2/control", MODE="0600" > >> KERNEL=="gntdev", NAME="xen/%k", MODE="0600" > >> KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600" > >> KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600" > >> -SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", > >> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" > >> +SUBSYSTEM=="net", KERNEL=="vif*-emu", ACTION=="add", > >> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap" > >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > >> index 1ffcc90..2c030ca 100644 > >> --- a/tools/libxl/libxl_dm.c > >> +++ b/tools/libxl/libxl_dm.c > >> @@ -134,11 +134,9 @@ static char ** > >> libxl_build_device_model_args_old(libxl__gc *gc, > >> char *smac = libxl__sprintf(gc, > >> "%02x:%02x:%02x:%02x:%02x:%02x", > >> vifs[i].mac[0], > >> vifs[i].mac[1], vifs[i].mac[2], > >> vifs[i].mac[3], > >> vifs[i].mac[4], vifs[i].mac[5]); > >> - char *ifname; > >> - if (!vifs[i].ifname) > >> - ifname = libxl__sprintf(gc, "tap%d.%d", > >> info->domid, vifs[i].devid); > >> - else > >> - ifname = vifs[i].ifname; > >> + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", > >> + info->domid, > >> + vifs[i].devid); > >> flexarray_vappend(dm_args, > >> "-net", libxl__sprintf(gc, > >> "nic,vlan=%d,macaddr=%s,model=%s", > >> vifs[i].devid, > >> smac, vifs[i].model), > >> @@ -271,12 +269,9 @@ static char ** > >> libxl_build_device_model_args_new(libxl__gc *gc, > >> char *smac = libxl__sprintf(gc, > >> "%02x:%02x:%02x:%02x:%02x:%02x", > >> vifs[i].mac[0], > >> vifs[i].mac[1], vifs[i].mac[2], > >> vifs[i].mac[3], > >> vifs[i].mac[4], vifs[i].mac[5]); > >> - char *ifname; > >> - if (!vifs[i].ifname) { > >> - ifname = libxl__sprintf(gc, "tap%d.%d", > >> info->domid, vifs[i].devid); > >> - } else { > >> - ifname = vifs[i].ifname; > >> - } > >> + const char *ifname = libxl__sprintf(gc, "vif%d.%d-emu", > >> + info->domid, > >> + vifs[i].devid); > >> flexarray_append(dm_args, "-net"); > >> flexarray_append(dm_args, libxl__sprintf(gc, > >> "nic,vlan=%d,macaddr=%s,model=%s", > >> vifs[i].devid, smac, vifs[i].model)); > >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py > >> index f1464ac..3c8d80c 100644 > >> --- a/tools/python/xen/xend/image.py > >> +++ b/tools/python/xen/xend/image.py > >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): > >> ret.append("-net") > >> ret.append("nic,vlan=%d,macaddr=%s,model=%s" % > >> (nics, mac, model)) > >> - vifname = devinfo.get('vifname') > >> - if vifname: > >> - vifname = "tap-" + vifname > >> - else: > >> - vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1) > >> + vifname = "vif%d.%d-emu" % (self.vm.getDomid(), nics-1) > >> ret.append("-net") > >> ret.append("tap,vlan=%d,ifname=%s,bridge=%s" % > >> (nics, vifname, bridge)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 23:14:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 23: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 ) id 1STLVk-0003x0-VZ; Sat, 12 May 2012 23:14:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STLVj-0003wv-TQ for xen-devel@lists.xensource.com; Sat, 12 May 2012 23:14:04 +0000 Received: from [85.158.143.99:24507] by server-2.bemta-4.messagelabs.com id 10/1D-17550-BBEEEAF4; Sat, 12 May 2012 23:14:03 +0000 X-Env-Sender: jrnieder@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336864440!27694653!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15432 invoked from network); 12 May 2012 23:14:02 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 23:14:02 -0000 Received: by yhkk6 with SMTP id k6so4613356yhk.30 for ; Sat, 12 May 2012 16:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a2T93G/TMKZdKa2Zafiq+eQbtW7dTlSGr4wYvO4J4yM=; b=A4yp/V+snTpn1QGeIqSD/s6JXqgzKL93u/rbQjHZDe2mIB8Z+X/JzRAh0HJt54cJ8A CDMhEISpFcKraKbPzhI2MxbiAzCU9Bq+lOY9G59kw5Lu+BQlIu4H0Stx9bvBTuhpyX1Z YLGGKjlvSSB4qAB3EKjcWlycACm1mo8k20jBpJyUZpfEvy4EprlIeqXhQqyLZEwlubVJ WiqjlRKKuqNS7mPXRqMdPzqq43BVuEgHIEFHEgouH/HlCn9X2m6l6naZ7mSlSB01mOoo O3K99K6mlfUR3Xuu+7zz3HYDdj4enZh7/cyTLVRIpSVfrBqkCxgdWpQJg/YfWw2KzaYh MD6g== Received: by 10.42.151.130 with SMTP id e2mr1338937icw.37.1336864440117; Sat, 12 May 2012 16:14:00 -0700 (PDT) Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9]) by mx.google.com with ESMTPS id vw8sm6835983igb.5.2012.05.12.16.13.58 (version=SSLv3 cipher=OTHER); Sat, 12 May 2012 16:13:59 -0700 (PDT) Date: Sat, 12 May 2012 18:13:49 -0500 From: Jonathan Nieder To: "Tian, Kevin" Message-ID: <20120512231349.GA17443@burratino> References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <20110829041532.GA22087@elie.gateway.2wire.net> <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-devel@lists.xensource.com" , Robert Scott , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Ian Campbell , Andreas Wallberg , "mingo@redhat.com" , Fengzhe Zhang , Thomas Gleixner , Lars Boegild Thomsen Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi again, In September, Kevin Tian wrote: >> Lars Boegild Thomsen writes[1]: >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after >>> sleep. Back to latest 2.6 kernel works fine. > > [...] >>> Upon wakeup, the power light go from slow flashing to on, the battery light >>> goes from off to on, the hdd light blink once and then everything is dead. [...] >>> 983bbf1af0664b78689612b247acb514300f62c7 is the first bad commit >> [...] >>> I also tried to go back to HEAD and manually change arch/x86/irq.c revert this >>> particular commit and it works. [...] > fixup_irqs is invoked in suspend path. The only impact this change may > bring to resume path is the interrupt line state, which is saved later > in suspend and then restored in resume. w/ above change after resume > given interrupt line is always masked, while w/o it there may be at least > one interrupt raising. If this does matter to make your ideapad working, > I'd think there may have other bugs which are hidden originally, e.g. by > triggering a reschedule from that interrupt though the handler itself > does nothing except masking the interrupt line. > > So... above commit is not important which can be easily reverted. My > only concern is whether other severe issues are just hidden. > > btw, any serial output you may capture? Sorry for the slow response. Result from reporters is: - 3.4-rc2 is affected as well - this only affects suspend-to-RAM --- suspend-to-disk works fine - all five pm_test modes for suspend-to-RAM work fine - this netbook doesn't have a serial port. Netconsole gives: | [ 745.161322] PM: Syncing filesystems ... done. | [ 747.088247] PM: Preparing system for mem sleep | [ 747.187932] Freezing user space processes ... (elapsed 0.01 seconds) done. | [ 747.204325] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. | [ 747.220416] PM: Entering mem sleep | [ 747.221085] sd 1:0:0:0: [sda] Synchronizing SCSI cache | [ 747.222247] sd 1:0:0:0: [sda] Stopping disk | | (then nothing) Serial console via a USB-to-serial converter gives: | [ 814.016541] PM: Syncing filesystems ... done. | [ 814.018516] PM: Preparing system for mem sleep | [ 814.100393] Freezing user space processes ... (elapsed 0.01 se | | before it goes to sleep, and it doesn't output anything on (attempted) wakeup. - passing parameters "hpet=disable highres=off nohz=off" helps some people if I understand correctly, but I might have misunderstood.[2] I'd be interested to hear whether the same problem occurs when trying to suspend from the minimal initramfs environment. (On systems like Debian that use initramfs-tools, that means passing the kernel command line parameter "break=top", booting, loading some appropriate minimal collection of modules --- maybe none ---, and then running "echo mem >/sys/power/state". initramfs-tools(8) has details.) Hope that helps, Jonathan >> [1] http://bugs.debian.org/635575 [2] https://bugzilla.kernel.org/show_bug.cgi?id=41932 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 23:14:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 23: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 ) id 1STLVk-0003x0-VZ; Sat, 12 May 2012 23:14:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STLVj-0003wv-TQ for xen-devel@lists.xensource.com; Sat, 12 May 2012 23:14:04 +0000 Received: from [85.158.143.99:24507] by server-2.bemta-4.messagelabs.com id 10/1D-17550-BBEEEAF4; Sat, 12 May 2012 23:14:03 +0000 X-Env-Sender: jrnieder@gmail.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1336864440!27694653!1 X-Originating-IP: [209.85.213.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15432 invoked from network); 12 May 2012 23:14:02 -0000 Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com) (209.85.213.43) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 23:14:02 -0000 Received: by yhkk6 with SMTP id k6so4613356yhk.30 for ; Sat, 12 May 2012 16:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a2T93G/TMKZdKa2Zafiq+eQbtW7dTlSGr4wYvO4J4yM=; b=A4yp/V+snTpn1QGeIqSD/s6JXqgzKL93u/rbQjHZDe2mIB8Z+X/JzRAh0HJt54cJ8A CDMhEISpFcKraKbPzhI2MxbiAzCU9Bq+lOY9G59kw5Lu+BQlIu4H0Stx9bvBTuhpyX1Z YLGGKjlvSSB4qAB3EKjcWlycACm1mo8k20jBpJyUZpfEvy4EprlIeqXhQqyLZEwlubVJ WiqjlRKKuqNS7mPXRqMdPzqq43BVuEgHIEFHEgouH/HlCn9X2m6l6naZ7mSlSB01mOoo O3K99K6mlfUR3Xuu+7zz3HYDdj4enZh7/cyTLVRIpSVfrBqkCxgdWpQJg/YfWw2KzaYh MD6g== Received: by 10.42.151.130 with SMTP id e2mr1338937icw.37.1336864440117; Sat, 12 May 2012 16:14:00 -0700 (PDT) Received: from burratino (c-24-1-56-9.hsd1.il.comcast.net. [24.1.56.9]) by mx.google.com with ESMTPS id vw8sm6835983igb.5.2012.05.12.16.13.58 (version=SSLv3 cipher=OTHER); Sat, 12 May 2012 16:13:59 -0700 (PDT) Date: Sat, 12 May 2012 18:13:49 -0500 From: Jonathan Nieder To: "Tian, Kevin" Message-ID: <20120512231349.GA17443@burratino> References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <20110829041532.GA22087@elie.gateway.2wire.net> <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-devel@lists.xensource.com" , Robert Scott , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Ian Campbell , Andreas Wallberg , "mingo@redhat.com" , Fengzhe Zhang , Thomas Gleixner , Lars Boegild Thomsen Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi again, In September, Kevin Tian wrote: >> Lars Boegild Thomsen writes[1]: >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after >>> sleep. Back to latest 2.6 kernel works fine. > > [...] >>> Upon wakeup, the power light go from slow flashing to on, the battery light >>> goes from off to on, the hdd light blink once and then everything is dead. [...] >>> 983bbf1af0664b78689612b247acb514300f62c7 is the first bad commit >> [...] >>> I also tried to go back to HEAD and manually change arch/x86/irq.c revert this >>> particular commit and it works. [...] > fixup_irqs is invoked in suspend path. The only impact this change may > bring to resume path is the interrupt line state, which is saved later > in suspend and then restored in resume. w/ above change after resume > given interrupt line is always masked, while w/o it there may be at least > one interrupt raising. If this does matter to make your ideapad working, > I'd think there may have other bugs which are hidden originally, e.g. by > triggering a reschedule from that interrupt though the handler itself > does nothing except masking the interrupt line. > > So... above commit is not important which can be easily reverted. My > only concern is whether other severe issues are just hidden. > > btw, any serial output you may capture? Sorry for the slow response. Result from reporters is: - 3.4-rc2 is affected as well - this only affects suspend-to-RAM --- suspend-to-disk works fine - all five pm_test modes for suspend-to-RAM work fine - this netbook doesn't have a serial port. Netconsole gives: | [ 745.161322] PM: Syncing filesystems ... done. | [ 747.088247] PM: Preparing system for mem sleep | [ 747.187932] Freezing user space processes ... (elapsed 0.01 seconds) done. | [ 747.204325] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. | [ 747.220416] PM: Entering mem sleep | [ 747.221085] sd 1:0:0:0: [sda] Synchronizing SCSI cache | [ 747.222247] sd 1:0:0:0: [sda] Stopping disk | | (then nothing) Serial console via a USB-to-serial converter gives: | [ 814.016541] PM: Syncing filesystems ... done. | [ 814.018516] PM: Preparing system for mem sleep | [ 814.100393] Freezing user space processes ... (elapsed 0.01 se | | before it goes to sleep, and it doesn't output anything on (attempted) wakeup. - passing parameters "hpet=disable highres=off nohz=off" helps some people if I understand correctly, but I might have misunderstood.[2] I'd be interested to hear whether the same problem occurs when trying to suspend from the minimal initramfs environment. (On systems like Debian that use initramfs-tools, that means passing the kernel command line parameter "break=top", booting, loading some appropriate minimal collection of modules --- maybe none ---, and then running "echo mem >/sys/power/state". initramfs-tools(8) has details.) Hope that helps, Jonathan >> [1] http://bugs.debian.org/635575 [2] https://bugzilla.kernel.org/show_bug.cgi?id=41932 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 23:38:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 23: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 ) id 1STLss-0004Fq-6q; Sat, 12 May 2012 23:37:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STLsq-0004Fl-5l for xen-devel@lists.xen.org; Sat, 12 May 2012 23:37:56 +0000 Received: from [85.158.143.99:17459] by server-3.bemta-4.messagelabs.com id D8/71-05853-354FEAF4; Sat, 12 May 2012 23:37:55 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336865872!26819578!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29636 invoked from network); 12 May 2012 23:37:53 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 23:37:53 -0000 Received: by obbwd20 with SMTP id wd20so6941358obb.32 for ; Sat, 12 May 2012 16:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJi47pL8DFT8fbvAK36ij+fe4s2DM9sC96j9MD5CIQE=; b=r6ncdxdfIePsd3188soc5qgGzdf8gRV2wK843tZFwl+NhRUdCbPTwP+dktF66PN/0e 2TnXt5TvqI2IJU8G+mfn3Pp0TznOJ8C4t7/6IPLmkoNlsc7k7n1jAIWADRkS58YtGjw/ YHS3odoCSGk2Nkevw+v/kG6+fIGvfgFVIgbLChMXbLh8E4gtmV+UQyarPEdZi8bm6mw3 GK2G5VHFa6C7qsqQCT473nZyZWKGgatiZJDYx71JFUulfh39d9NDcrmp6XQW87JkmExe s8bZhFNiVwGM3w4nGgcKcOYHaRtULgFCP0QcmXoKPnrn6jPLEEDb2CfB1wv1QwZ8mmyb bMxw== MIME-Version: 1.0 Received: by 10.60.14.162 with SMTP id q2mr3950837oec.22.1336865872005; Sat, 12 May 2012 16:37:52 -0700 (PDT) Received: by 10.182.9.170 with HTTP; Sat, 12 May 2012 16:37:51 -0700 (PDT) In-Reply-To: <1336861837.3891.29.camel@dagon.hellion.org.uk> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> <1336861837.3891.29.camel@dagon.hellion.org.uk> Date: Sun, 13 May 2012 07:37:51 +0800 Message-ID: From: Teck Choon Giam To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 13, 2012 at 6:30 AM, Ian Campbell wro= te: > On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: >> On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam >> wrote: >> > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam >> > wrote: >> >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >> >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfer= ing with openvpn"): >> >>>> libxl/xend: name tap devices vifX.Y-emu >> >>> >> >>> Committed-by: Ian Jackson >> >> >> >> This is my backport version which excludes the following: >> >> >> >> Lastly also move libxl__device_* to a better place in the header, oth= erwise the >> >> comment about evgen stuff isn't next to the associated functions (not= iced jsut >> >> because I was going to add nic_devname near to the setdefault functio= ns) >> >> >> >> I have tested with xm and xl with and without vifname set in domU >> >> config for hvmdomain and pvdomain. >> > >> > Sorry, when re-test one of the test case failed... xm create hvmdomain >> > with vifname set. =A0I must have missed certain test case :( >> >> The same test case failed for xen unstable latest changeset 25326:cd4dd2= 3a831d. > > Oh dear. > >> My tests as below: > > Which ones fail? > >> 1. xm create pvdomain without vifname set >> 2. xl create pvdomain without vifname set >> 3. xm create hvmdomain without vifname set >> 4. xl create hvmdomain without vifname set >> 5. xm create pvdomain with vifname set >> 6. xl create pvdomain with vifname set >> 7. xm create hvmdomain with vifname set xm create hvmdomain with vifname set I track down the problem already. It happens that xm and xl behave differently when creating $dev device? In short, just set $dev down before: do_or_die ip link set "$dev" name "$vifname" Then set $vifname up after the above fix my problem. Is the above suitable in upstream/unstable? If yes, can you fix that in xen-unstable or you need me to submit a patch for review for xen-unstable? With the below partial of my latest backport patch fix the problem but I have to re-run all tests to double confirm all are fix and good to go :p diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh index c9c5d41..86c0aaa 100644 --- a/tools/hotplug/Linux/vif-common.sh +++ b/tools/hotplug/Linux/vif-common.sh @@ -85,12 +85,25 @@ elif [ "$type_if" =3D tap ]; then : ${INTERFACE:?} # Get xenbus_path from device name. - # The name is built like that: "tap${domid}.${devid}". - dev_=3D${dev#tap} + # The name is built like that: "vif${domid}.${devid}-emu". + dev_=3D${dev#vif} + dev_=3D${dev_%-emu} domid=3D${dev_%.*} devid=3D${dev_#*.} XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" + vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") + if [ "$vifname" ] + then + vifname=3D"${vifname}-emu" + if [ "$command" =3D=3D "add" ] && ! ip link show "$vifname" >&/dev= /null + then + ip link set "$dev" down + do_or_die ip link set "$dev" name "$vifname" + ip link set "$vifname" up + fi + dev=3D"$vifname" + fi fi Thanks. Kindest regards, Giam Teck Choon >> 8. xl create hvmdomain with vifname set >> >> Thanks. >> >> Kindest regards, >> >> >> > >> > Kindest regards, >> > Giam Teck Choon >> > >> > >> > >> >> >> >> For your review and comments please. >> >> >> >> Thanks. >> >> >> >> Kindest regards, >> >> Giam Teck Choon >> >> >> >> >> >> >> >> >> >> libxl/xend: name tap devices vifX.Y-emu >> >> >> >> This prevents the udev scripts from operating on other tap devices (e= .g. >> >> openvpn etc) >> >> >> >> Correct the documentation for the "vifname" option which suggested it= applied >> >> to HVM tap devices only, which is not the case. >> >> >> >> Reported by Michael Young. >> >> >> >> Also fix the use of vifname with emulated devices. This is slightly c= omplex. >> >> The current hotplug scripts rely on being able to parse the "tapX.Y" = (now >> >> "vifX.Y-emu") name in order to locate the xenstore backend dir relati= ng to the >> >> corresponding vif. This is because we cannot inject our own environme= nt vars >> >> into the tap hotplug events. However this means that if the tap is in= itially >> >> named with a user specified name (which will not match the expected s= cheme) we >> >> fail to do anything useful with the device. So now we create the init= ial tap >> >> device with the standard "vifX.Y-emu" name and the hotplug script wil= l handle >> >> the rename to the desired name. This is also how PV vif devices work = -- they >> >> are always created by netback with the name vifX.Y and renamed in the= script. >> >> >> >> xen-unstable changeset: 25290:7a6dcecb1781 >> >> Signed-off-by: Giam Teck Choon >> >> --- >> >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- >> >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >> >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 +++= +++----------- >> >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >> >> =A04 files changed, 21 insertions(+), 19 deletions(-) >> >> >> >> diff --git a/tools/hotplug/Linux/vif-common.sh >> >> b/tools/hotplug/Linux/vif-common.sh >> >> index c9c5d41..fff22bb 100644 >> >> --- a/tools/hotplug/Linux/vif-common.sh >> >> +++ b/tools/hotplug/Linux/vif-common.sh >> >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >> >> =A0 =A0 : ${INTERFACE:?} >> >> >> >> =A0 =A0 # Get xenbus_path from device name. >> >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >> >> - =A0 =A0dev_=3D${dev#tap} >> >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >> >> + =A0 =A0dev_=3D${dev#vif} >> >> + =A0 =A0dev_=3D${dev_%-emu} >> >> =A0 =A0 domid=3D${dev_%.*} >> >> =A0 =A0 devid=3D${dev_#*.} >> >> >> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >> >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") >> >> + =A0 =A0if [ "$vifname" ] >> >> + =A0 =A0then >> >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >> >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$v= ifname" >&/dev/null >> >> + =A0 =A0 =A0 =A0then >> >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" >> >> + =A0 =A0 =A0 =A0fi >> >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >> >> + =A0 =A0fi >> >> =A0fi >> >> >> >> =A0ip=3D${ip:-} >> >> diff --git a/tools/hotplug/Linux/xen-backend.rules >> >> b/tools/hotplug/Linux/xen-backend.rules >> >> index 40f2658..405387f 100644 >> >> --- a/tools/hotplug/Linux/xen-backend.rules >> >> +++ b/tools/hotplug/Linux/xen-backend.rules >> >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >> >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE= =3D"0600" >> >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> >> index 1ffcc90..2c030ca 100644 >> >> --- a/tools/libxl/libxl_dm.c >> >> +++ b/tools/libxl/libxl_dm.c >> >> @@ -134,11 +134,9 @@ static char ** >> >> libxl_build_device_model_args_old(libxl__gc *gc, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> >> "%02x:%02x:%02x:%02x:%02x:%02x", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >> >> vifs[i].mac[1], vifs[i].mac[2], >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >> >> vifs[i].mac[4], vifs[i].mac[5]); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc= , "tap%d.%d", >> >> info->domid, vifs[i].devid); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprint= f(gc, "vif%d.%d-emu", >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net= ", libxl__sprintf(gc, >> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >> >> smac, vifs[i].model), >> >> @@ -271,12 +269,9 @@ static char ** >> >> libxl_build_device_model_args_new(libxl__gc *gc, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> >> "%02x:%02x:%02x:%02x:%02x:%02x", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >> >> vifs[i].mac[1], vifs[i].mac[2], >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >> >> vifs[i].mac[4], vifs[i].mac[5]); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc= , "tap%d.%d", >> >> info->domid, vifs[i].devid); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprint= f(gc, "vif%d.%d-emu", >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__spri= ntf(gc, >> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid= , smac, vifs[i].model)); >> >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/i= mage.py >> >> index f1464ac..3c8d80c 100644 >> >> --- a/tools/python/xen/xend/image.py >> >> +++ b/tools/python/xen/xend/image.py >> >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model= =3D%s" % >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >> >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >> >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >> >> - =A0 =A0 =A0 =A0 =A0 =A0else: >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.ge= tDomid(), nics-1) >> >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDom= id(), nics-1) >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge= =3D%s" % >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge= )) > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat May 12 23:38:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 May 2012 23: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 ) id 1STLss-0004Fq-6q; Sat, 12 May 2012 23:37:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STLsq-0004Fl-5l for xen-devel@lists.xen.org; Sat, 12 May 2012 23:37:56 +0000 Received: from [85.158.143.99:17459] by server-3.bemta-4.messagelabs.com id D8/71-05853-354FEAF4; Sat, 12 May 2012 23:37:55 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336865872!26819578!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29636 invoked from network); 12 May 2012 23:37:53 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 May 2012 23:37:53 -0000 Received: by obbwd20 with SMTP id wd20so6941358obb.32 for ; Sat, 12 May 2012 16:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJi47pL8DFT8fbvAK36ij+fe4s2DM9sC96j9MD5CIQE=; b=r6ncdxdfIePsd3188soc5qgGzdf8gRV2wK843tZFwl+NhRUdCbPTwP+dktF66PN/0e 2TnXt5TvqI2IJU8G+mfn3Pp0TznOJ8C4t7/6IPLmkoNlsc7k7n1jAIWADRkS58YtGjw/ YHS3odoCSGk2Nkevw+v/kG6+fIGvfgFVIgbLChMXbLh8E4gtmV+UQyarPEdZi8bm6mw3 GK2G5VHFa6C7qsqQCT473nZyZWKGgatiZJDYx71JFUulfh39d9NDcrmp6XQW87JkmExe s8bZhFNiVwGM3w4nGgcKcOYHaRtULgFCP0QcmXoKPnrn6jPLEEDb2CfB1wv1QwZ8mmyb bMxw== MIME-Version: 1.0 Received: by 10.60.14.162 with SMTP id q2mr3950837oec.22.1336865872005; Sat, 12 May 2012 16:37:52 -0700 (PDT) Received: by 10.182.9.170 with HTTP; Sat, 12 May 2012 16:37:51 -0700 (PDT) In-Reply-To: <1336861837.3891.29.camel@dagon.hellion.org.uk> References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> <1336861837.3891.29.camel@dagon.hellion.org.uk> Date: Sun, 13 May 2012 07:37:51 +0800 Message-ID: From: Teck Choon Giam To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, May 13, 2012 at 6:30 AM, Ian Campbell wro= te: > On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: >> On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam >> wrote: >> > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam >> > wrote: >> >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >> >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfer= ing with openvpn"): >> >>>> libxl/xend: name tap devices vifX.Y-emu >> >>> >> >>> Committed-by: Ian Jackson >> >> >> >> This is my backport version which excludes the following: >> >> >> >> Lastly also move libxl__device_* to a better place in the header, oth= erwise the >> >> comment about evgen stuff isn't next to the associated functions (not= iced jsut >> >> because I was going to add nic_devname near to the setdefault functio= ns) >> >> >> >> I have tested with xm and xl with and without vifname set in domU >> >> config for hvmdomain and pvdomain. >> > >> > Sorry, when re-test one of the test case failed... xm create hvmdomain >> > with vifname set. =A0I must have missed certain test case :( >> >> The same test case failed for xen unstable latest changeset 25326:cd4dd2= 3a831d. > > Oh dear. > >> My tests as below: > > Which ones fail? > >> 1. xm create pvdomain without vifname set >> 2. xl create pvdomain without vifname set >> 3. xm create hvmdomain without vifname set >> 4. xl create hvmdomain without vifname set >> 5. xm create pvdomain with vifname set >> 6. xl create pvdomain with vifname set >> 7. xm create hvmdomain with vifname set xm create hvmdomain with vifname set I track down the problem already. It happens that xm and xl behave differently when creating $dev device? In short, just set $dev down before: do_or_die ip link set "$dev" name "$vifname" Then set $vifname up after the above fix my problem. Is the above suitable in upstream/unstable? If yes, can you fix that in xen-unstable or you need me to submit a patch for review for xen-unstable? With the below partial of my latest backport patch fix the problem but I have to re-run all tests to double confirm all are fix and good to go :p diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh index c9c5d41..86c0aaa 100644 --- a/tools/hotplug/Linux/vif-common.sh +++ b/tools/hotplug/Linux/vif-common.sh @@ -85,12 +85,25 @@ elif [ "$type_if" =3D tap ]; then : ${INTERFACE:?} # Get xenbus_path from device name. - # The name is built like that: "tap${domid}.${devid}". - dev_=3D${dev#tap} + # The name is built like that: "vif${domid}.${devid}-emu". + dev_=3D${dev#vif} + dev_=3D${dev_%-emu} domid=3D${dev_%.*} devid=3D${dev_#*.} XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" + vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") + if [ "$vifname" ] + then + vifname=3D"${vifname}-emu" + if [ "$command" =3D=3D "add" ] && ! ip link show "$vifname" >&/dev= /null + then + ip link set "$dev" down + do_or_die ip link set "$dev" name "$vifname" + ip link set "$vifname" up + fi + dev=3D"$vifname" + fi fi Thanks. Kindest regards, Giam Teck Choon >> 8. xl create hvmdomain with vifname set >> >> Thanks. >> >> Kindest regards, >> >> >> > >> > Kindest regards, >> > Giam Teck Choon >> > >> > >> > >> >> >> >> For your review and comments please. >> >> >> >> Thanks. >> >> >> >> Kindest regards, >> >> Giam Teck Choon >> >> >> >> >> >> >> >> >> >> libxl/xend: name tap devices vifX.Y-emu >> >> >> >> This prevents the udev scripts from operating on other tap devices (e= .g. >> >> openvpn etc) >> >> >> >> Correct the documentation for the "vifname" option which suggested it= applied >> >> to HVM tap devices only, which is not the case. >> >> >> >> Reported by Michael Young. >> >> >> >> Also fix the use of vifname with emulated devices. This is slightly c= omplex. >> >> The current hotplug scripts rely on being able to parse the "tapX.Y" = (now >> >> "vifX.Y-emu") name in order to locate the xenstore backend dir relati= ng to the >> >> corresponding vif. This is because we cannot inject our own environme= nt vars >> >> into the tap hotplug events. However this means that if the tap is in= itially >> >> named with a user specified name (which will not match the expected s= cheme) we >> >> fail to do anything useful with the device. So now we create the init= ial tap >> >> device with the standard "vifX.Y-emu" name and the hotplug script wil= l handle >> >> the rename to the desired name. This is also how PV vif devices work = -- they >> >> are always created by netback with the name vifX.Y and renamed in the= script. >> >> >> >> xen-unstable changeset: 25290:7a6dcecb1781 >> >> Signed-off-by: Giam Teck Choon >> >> --- >> >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-- >> >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >> >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 +++= +++----------- >> >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >> >> =A04 files changed, 21 insertions(+), 19 deletions(-) >> >> >> >> diff --git a/tools/hotplug/Linux/vif-common.sh >> >> b/tools/hotplug/Linux/vif-common.sh >> >> index c9c5d41..fff22bb 100644 >> >> --- a/tools/hotplug/Linux/vif-common.sh >> >> +++ b/tools/hotplug/Linux/vif-common.sh >> >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >> >> =A0 =A0 : ${INTERFACE:?} >> >> >> >> =A0 =A0 # Get xenbus_path from device name. >> >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >> >> - =A0 =A0dev_=3D${dev#tap} >> >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >> >> + =A0 =A0dev_=3D${dev#vif} >> >> + =A0 =A0dev_=3D${dev_%-emu} >> >> =A0 =A0 domid=3D${dev_%.*} >> >> =A0 =A0 devid=3D${dev_#*.} >> >> >> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >> >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") >> >> + =A0 =A0if [ "$vifname" ] >> >> + =A0 =A0then >> >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >> >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$v= ifname" >&/dev/null >> >> + =A0 =A0 =A0 =A0then >> >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" >> >> + =A0 =A0 =A0 =A0fi >> >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >> >> + =A0 =A0fi >> >> =A0fi >> >> >> >> =A0ip=3D${ip:-} >> >> diff --git a/tools/hotplug/Linux/xen-backend.rules >> >> b/tools/hotplug/Linux/xen-backend.rules >> >> index 40f2658..405387f 100644 >> >> --- a/tools/hotplug/Linux/xen-backend.rules >> >> +++ b/tools/hotplug/Linux/xen-backend.rules >> >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >> >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >> >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE= =3D"0600" >> >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> >> index 1ffcc90..2c030ca 100644 >> >> --- a/tools/libxl/libxl_dm.c >> >> +++ b/tools/libxl/libxl_dm.c >> >> @@ -134,11 +134,9 @@ static char ** >> >> libxl_build_device_model_args_old(libxl__gc *gc, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> >> "%02x:%02x:%02x:%02x:%02x:%02x", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >> >> vifs[i].mac[1], vifs[i].mac[2], >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >> >> vifs[i].mac[4], vifs[i].mac[5]); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc= , "tap%d.%d", >> >> info->domid, vifs[i].devid); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprint= f(gc, "vif%d.%d-emu", >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-net= ", libxl__sprintf(gc, >> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >> >> smac, vifs[i].model), >> >> @@ -271,12 +269,9 @@ static char ** >> >> libxl_build_device_model_args_new(libxl__gc *gc, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >> >> "%02x:%02x:%02x:%02x:%02x:%02x", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >> >> vifs[i].mac[1], vifs[i].mac[2], >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >> >> vifs[i].mac[4], vifs[i].mac[5]); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(gc= , "tap%d.%d", >> >> info->domid, vifs[i].devid); >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprint= f(gc, "vif%d.%d-emu", >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__spri= ntf(gc, >> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devid= , smac, vifs[i].model)); >> >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/i= mage.py >> >> index f1464ac..3c8d80c 100644 >> >> --- a/tools/python/xen/xend/image.py >> >> +++ b/tools/python/xen/xend/image.py >> >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model= =3D%s" % >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >> >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >> >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >> >> - =A0 =A0 =A0 =A0 =A0 =A0else: >> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.ge= tDomid(), nics-1) >> >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDom= id(), nics-1) >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge= =3D%s" % >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridge= )) > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 00:40:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 00:40:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STMqS-00057O-Tw; Sun, 13 May 2012 00:39:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STMqQ-00057J-AZ for xen-devel@lists.xen.org; Sun, 13 May 2012 00:39:30 +0000 Received: from [193.109.254.147:50933] by server-11.bemta-14.messagelabs.com id 68/C5-05858-1C20FAF4; Sun, 13 May 2012 00:39:29 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336869566!2140474!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20754 invoked from network); 13 May 2012 00:39:28 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2012 00:39:28 -0000 Received: by obbwd20 with SMTP id wd20so7019454obb.32 for ; Sat, 12 May 2012 17:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h3k9dsTMBqa+bTLY7GjlCjxS5MeucB5cYGofYcDXDJ0=; b=RrXNLw1MzFPxwdl7d/7sfRecn3VkF+4aa3314V9FkJpOeC+6cdeGtCdij9Ep9Cc0XK nT+fcvkcGJnU2L0o4m+GzkScfX36zfL5pBD97SoXs3ErjbEJyc9iBItRsvkC7iIY7XAz EXtubSN7wUlmp3zE7mkCl3GphASk/IcGMLHZvYH1gt7HgjrwmTIUgJHv242XoWYINGCg +eqGr1p4Fr48sp9BvpGN8txUtdfxRokb53m3aEiERCKHb9hxbgp35n52MAhONSq6SuWM OQfRr5yWBOnwQ/ctTrPiuL/uiO0oyhRv/O4bYdPPNCsrfUzCAISg31jiWMjIPVtjmmB4 uKOA== MIME-Version: 1.0 Received: by 10.182.5.132 with SMTP id s4mr4518342obs.65.1336869566048; Sat, 12 May 2012 17:39:26 -0700 (PDT) Received: by 10.182.9.170 with HTTP; Sat, 12 May 2012 17:39:25 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> <1336861837.3891.29.camel@dagon.hellion.org.uk> Date: Sun, 13 May 2012 08:39:25 +0800 Message-ID: From: Teck Choon Giam To: Ian Campbell Content-Type: multipart/mixed; boundary=f46d0447967d98696104bfe033c9 Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --f46d0447967d98696104bfe033c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 7:37 AM, Teck Choon Giam wrote: > On Sun, May 13, 2012 at 6:30 AM, Ian Campbell w= rote: >> On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: >>> On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam >>> wrote: >>> > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam >>> > wrote: >>> >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >>> >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfe= ring with openvpn"): >>> >>>> libxl/xend: name tap devices vifX.Y-emu >>> >>> >>> >>> Committed-by: Ian Jackson >>> >> >>> >> This is my backport version which excludes the following: >>> >> >>> >> Lastly also move libxl__device_* to a better place in the header, ot= herwise the >>> >> comment about evgen stuff isn't next to the associated functions (no= ticed jsut >>> >> because I was going to add nic_devname near to the setdefault functi= ons) >>> >> >>> >> I have tested with xm and xl with and without vifname set in domU >>> >> config for hvmdomain and pvdomain. >>> > >>> > Sorry, when re-test one of the test case failed... xm create hvmdomai= n >>> > with vifname set. =A0I must have missed certain test case :( >>> >>> The same test case failed for xen unstable latest changeset 25326:cd4dd= 23a831d. >> >> Oh dear. >> >>> My tests as below: >> >> Which ones fail? >> >>> 1. xm create pvdomain without vifname set >>> 2. xl create pvdomain without vifname set >>> 3. xm create hvmdomain without vifname set >>> 4. xl create hvmdomain without vifname set >>> 5. xm create pvdomain with vifname set >>> 6. xl create pvdomain with vifname set >>> 7. xm create hvmdomain with vifname set > > xm create hvmdomain with vifname set > > > I track down the problem already. =A0It happens that xm and xl behave > differently when creating $dev device? > > In short, just set $dev down before: > do_or_die ip link set "$dev" name "$vifname" > Then set $vifname up after the above fix my problem. > > Is the above suitable in upstream/unstable? =A0If yes, can you fix that > in xen-unstable or you need me to submit a patch for review for > xen-unstable? > > With the below partial of my latest backport patch fix the problem but > I have to re-run all tests to double confirm all are fix and good to > go :p Attached is my final backport for xen-4.1-testing which passed all my tests as stated below: 1. xm create pvdomain without vifname set 2. xl create pvdomain without vifname set 3. xm create hvmdomain without vifname set 4. xl create hvmdomain without vifname set 5. xm create pvdomain with vifname set 6. xl create pvdomain with vifname set 7. xm create hvmdomain with vifname set 8. xl create hvmdomain with vifname set My initial backport patch failed for test no. 7 and when I perform test for all the above in latest xen-unstable it failed in test no. 7 as well. For review and comments please. Thanks. Kindest regards, Giam Teck Choon > > diff --git a/tools/hotplug/Linux/vif-common.sh > b/tools/hotplug/Linux/vif-common.sh > index c9c5d41..86c0aaa 100644 > --- a/tools/hotplug/Linux/vif-common.sh > +++ b/tools/hotplug/Linux/vif-common.sh > @@ -85,12 +85,25 @@ elif [ "$type_if" =3D tap ]; then > =A0 =A0 : ${INTERFACE:?} > > =A0 =A0 # Get xenbus_path from device name. > - =A0 =A0# The name is built like that: "tap${domid}.${devid}". > - =A0 =A0dev_=3D${dev#tap} > + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". > + =A0 =A0dev_=3D${dev#vif} > + =A0 =A0dev_=3D${dev_%-emu} > =A0 =A0 domid=3D${dev_%.*} > =A0 =A0 devid=3D${dev_#*.} > > =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" > + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") > + =A0 =A0if [ "$vifname" ] > + =A0 =A0then > + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" > + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifna= me" >&/dev/null > + =A0 =A0 =A0 =A0then > + =A0 =A0 =A0 =A0 =A0 =A0ip link set "$dev" down > + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" > + =A0 =A0 =A0 =A0 =A0 =A0ip link set "$vifname" up > + =A0 =A0 =A0 =A0fi > + =A0 =A0 =A0 =A0dev=3D"$vifname" > + =A0 =A0fi > =A0fi > > > Thanks. > > Kindest regards, > Giam Teck Choon > > > >>> 8. xl create hvmdomain with vifname set >>> >>> Thanks. >>> >>> Kindest regards, >>> >>> >>> > >>> > Kindest regards, >>> > Giam Teck Choon >>> > >>> > >>> > >>> >> >>> >> For your review and comments please. >>> >> >>> >> Thanks. >>> >> >>> >> Kindest regards, >>> >> Giam Teck Choon >>> >> >>> >> >>> >> >>> >> >>> >> libxl/xend: name tap devices vifX.Y-emu >>> >> >>> >> This prevents the udev scripts from operating on other tap devices (= e.g. >>> >> openvpn etc) >>> >> >>> >> Correct the documentation for the "vifname" option which suggested i= t applied >>> >> to HVM tap devices only, which is not the case. >>> >> >>> >> Reported by Michael Young. >>> >> >>> >> Also fix the use of vifname with emulated devices. This is slightly = complex. >>> >> The current hotplug scripts rely on being able to parse the "tapX.Y"= (now >>> >> "vifX.Y-emu") name in order to locate the xenstore backend dir relat= ing to the >>> >> corresponding vif. This is because we cannot inject our own environm= ent vars >>> >> into the tap hotplug events. However this means that if the tap is i= nitially >>> >> named with a user specified name (which will not match the expected = scheme) we >>> >> fail to do anything useful with the device. So now we create the ini= tial tap >>> >> device with the standard "vifX.Y-emu" name and the hotplug script wi= ll handle >>> >> the rename to the desired name. This is also how PV vif devices work= -- they >>> >> are always created by netback with the name vifX.Y and renamed in th= e script. >>> >> >>> >> xen-unstable changeset: 25290:7a6dcecb1781 >>> >> Signed-off-by: Giam Teck Choon >>> >> --- >>> >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-= - >>> >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >>> >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++= ++++----------- >>> >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >>> >> =A04 files changed, 21 insertions(+), 19 deletions(-) >>> >> >>> >> diff --git a/tools/hotplug/Linux/vif-common.sh >>> >> b/tools/hotplug/Linux/vif-common.sh >>> >> index c9c5d41..fff22bb 100644 >>> >> --- a/tools/hotplug/Linux/vif-common.sh >>> >> +++ b/tools/hotplug/Linux/vif-common.sh >>> >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >>> >> =A0 =A0 : ${INTERFACE:?} >>> >> >>> >> =A0 =A0 # Get xenbus_path from device name. >>> >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >>> >> - =A0 =A0dev_=3D${dev#tap} >>> >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >>> >> + =A0 =A0dev_=3D${dev#vif} >>> >> + =A0 =A0dev_=3D${dev_%-emu} >>> >> =A0 =A0 domid=3D${dev_%.*} >>> >> =A0 =A0 devid=3D${dev_#*.} >>> >> >>> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >>> >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" ""= ) >>> >> + =A0 =A0if [ "$vifname" ] >>> >> + =A0 =A0then >>> >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >>> >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$= vifname" >&/dev/null >>> >> + =A0 =A0 =A0 =A0then >>> >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname= " >>> >> + =A0 =A0 =A0 =A0fi >>> >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >>> >> + =A0 =A0fi >>> >> =A0fi >>> >> >>> >> =A0ip=3D${ip:-} >>> >> diff --git a/tools/hotplug/Linux/xen-backend.rules >>> >> b/tools/hotplug/Linux/xen-backend.rules >>> >> index 40f2658..405387f 100644 >>> >> --- a/tools/hotplug/Linux/xen-backend.rules >>> >> +++ b/tools/hotplug/Linux/xen-backend.rules >>> >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >>> >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE= =3D"0600" >>> >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >>> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >>> >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >>> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >>> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >>> >> index 1ffcc90..2c030ca 100644 >>> >> --- a/tools/libxl/libxl_dm.c >>> >> +++ b/tools/libxl/libxl_dm.c >>> >> @@ -134,11 +134,9 @@ static char ** >>> >> libxl_build_device_model_args_old(libxl__gc *gc, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >>> >> "%02x:%02x:%02x:%02x:%02x:%02x", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >>> >> vifs[i].mac[1], vifs[i].mac[2], >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >>> >> vifs[i].mac[4], vifs[i].mac[5]); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(g= c, "tap%d.%d", >>> >> info->domid, vifs[i].devid); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprin= tf(gc, "vif%d.%d-emu", >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-ne= t", libxl__sprintf(gc, >>> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >>> >> smac, vifs[i].model), >>> >> @@ -271,12 +269,9 @@ static char ** >>> >> libxl_build_device_model_args_new(libxl__gc *gc, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >>> >> "%02x:%02x:%02x:%02x:%02x:%02x", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >>> >> vifs[i].mac[1], vifs[i].mac[2], >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >>> >> vifs[i].mac[4], vifs[i].mac[5]); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(g= c, "tap%d.%d", >>> >> info->domid, vifs[i].devid); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprin= tf(gc, "vif%d.%d-emu", >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__spr= intf(gc, >>> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devi= d, smac, vifs[i].model)); >>> >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/= image.py >>> >> index f1464ac..3c8d80c 100644 >>> >> --- a/tools/python/xen/xend/image.py >>> >> +++ b/tools/python/xen/xend/image.py >>> >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model= =3D%s" % >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >>> >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >>> >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >>> >> - =A0 =A0 =A0 =A0 =A0 =A0else: >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.g= etDomid(), nics-1) >>> >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDo= mid(), nics-1) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge= =3D%s" % >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridg= e)) >> >> --f46d0447967d98696104bfe033c9 Content-Type: application/octet-stream; name="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Disposition: attachment; filename="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h25dl3f20 bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB2aWZYLlktZW11CgpUaGlzIHByZXZlbnRzIHRo ZSB1ZGV2IHNjcmlwdHMgZnJvbSBvcGVyYXRpbmcgb24gb3RoZXIgdGFwIGRldmljZXMgKGUuZy4K b3BlbnZwbiBldGMpCgpDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgInZpZm5hbWUi IG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25s eSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLgoKUmVwb3J0ZWQgYnkgTWljaGFlbCBZb3VuZy4KCkFs c28gZml4IHRoZSB1c2Ugb2YgdmlmbmFtZSB3aXRoIGVtdWxhdGVkIGRldmljZXMuIFRoaXMgaXMg c2xpZ2h0bHkgY29tcGxleC4KVGhlIGN1cnJlbnQgaG90cGx1ZyBzY3JpcHRzIHJlbHkgb24gYmVp bmcgYWJsZSB0byBwYXJzZSB0aGUgInRhcFguWSIgKG5vdwoidmlmWC5ZLWVtdSIpIG5hbWUgaW4g b3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBiYWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUK Y29ycmVzcG9uZGluZyB2aWYuIFRoaXMgaXMgYmVjYXVzZSB3ZSBjYW5ub3QgaW5qZWN0IG91ciBv d24gZW52aXJvbm1lbnQgdmFycwppbnRvIHRoZSB0YXAgaG90cGx1ZyBldmVudHMuIEhvd2V2ZXIg dGhpcyBtZWFucyB0aGF0IGlmIHRoZSB0YXAgaXMgaW5pdGlhbGx5Cm5hbWVkIHdpdGggYSB1c2Vy IHNwZWNpZmllZCBuYW1lICh3aGljaCB3aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1l KSB3ZQpmYWlsIHRvIGRvIGFueXRoaW5nIHVzZWZ1bCB3aXRoIHRoZSBkZXZpY2UuIFNvIG5vdyB3 ZSBjcmVhdGUgdGhlIGluaXRpYWwgdGFwCmRldmljZSB3aXRoIHRoZSBzdGFuZGFyZCAidmlmWC5Z LWVtdSIgbmFtZSBhbmQgdGhlIGhvdHBsdWcgc2NyaXB0IHdpbGwgaGFuZGxlCnRoZSByZW5hbWUg dG8gdGhlIGRlc2lyZWQgbmFtZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3Jr IC0tIHRoZXkKYXJlIGFsd2F5cyBjcmVhdGVkIGJ5IG5ldGJhY2sgd2l0aCB0aGUgbmFtZSB2aWZY LlkgYW5kIHJlbmFtZWQgaW4gdGhlIHNjcmlwdC4KCnhlbi11bnN0YWJsZSBjaGFuZ2VzZXQ6IDI1 MjkwOjdhNmRjZWNiMTc4MQpTaWduZWQtb2ZmLWJ5OiBHaWFtIFRlY2sgQ2hvb24gPGdpYW10ZWNr Y2hvb25AZ21haWwuY29tPgotLS0KIHRvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaCAg ICAgfCAgIDE3ICsrKysrKysrKysrKysrKy0tCiB0b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNr ZW5kLnJ1bGVzIHwgICAgMiArLQogdG9vbHMvbGlieGwvbGlieGxfZG0uYyAgICAgICAgICAgICAg ICB8ICAgMTcgKysrKysrLS0tLS0tLS0tLS0KIHRvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5w eSAgICAgICAgfCAgICA2ICstLS0tLQogNCBmaWxlcyBjaGFuZ2VkLCAyMyBpbnNlcnRpb25zKCsp LCAxOSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1j b21tb24uc2ggYi90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gKaW5kZXggYzljNWQ0 MS4uODZjMGFhYSAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNo CisrKyBiL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaApAQCAtODUsMTIgKzg1LDI1 IEBAIGVsaWYgWyAiJHR5cGVfaWYiID0gdGFwIF07IHRoZW4KICAgICA6ICR7SU5URVJGQUNFOj99 CiAKICAgICAjIEdldCB4ZW5idXNfcGF0aCBmcm9tIGRldmljZSBuYW1lLgotICAgICMgVGhlIG5h bWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidGFwJHtkb21pZH0uJHtkZXZpZH0iLgotICAgIGRldl89 JHtkZXYjdGFwfQorICAgICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidmlmJHtkb21p ZH0uJHtkZXZpZH0tZW11Ii4KKyAgICBkZXZfPSR7ZGV2I3ZpZn0KKyAgICBkZXZfPSR7ZGV2XyUt ZW11fQogICAgIGRvbWlkPSR7ZGV2XyUuKn0KICAgICBkZXZpZD0ke2Rldl8jKi59CiAKICAgICBY RU5CVVNfUEFUSD0iL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLyRkb21pZC8kZGV2aWQiCisg ICAgdmlmbmFtZT0kKHhlbnN0b3JlX3JlYWRfZGVmYXVsdCAiJFhFTkJVU19QQVRIL3ZpZm5hbWUi ICIiKQorICAgIGlmIFsgIiR2aWZuYW1lIiBdCisgICAgdGhlbgorICAgICAgICB2aWZuYW1lPSIk e3ZpZm5hbWV9LWVtdSIKKyAgICAgICAgaWYgWyAiJGNvbW1hbmQiID09ICJhZGQiIF0gJiYgISBp cCBsaW5rIHNob3cgIiR2aWZuYW1lIiA+Ji9kZXYvbnVsbAorICAgICAgICB0aGVuCisgICAgICAg ICAgICBpcCBsaW5rIHNldCAiJGRldiIgZG93bgorICAgICAgICAgICAgZG9fb3JfZGllIGlwIGxp bmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKKyAgICAgICAgICAgIGlwIGxpbmsgc2V0ICIk dmlmbmFtZSIgdXAKKyAgICAgICAgZmkKKyAgICAgICAgZGV2PSIkdmlmbmFtZSIKKyAgICBmaQog ZmkKIAogaXA9JHtpcDotfQpkaWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFj a2VuZC5ydWxlcyBiL3Rvb2xzL2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKaW5kZXgg NDBmMjY1OC4uNDA1Mzg3ZiAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFj a2VuZC5ydWxlcworKysgYi90b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzCkBA IC0xMyw0ICsxMyw0IEBAIEtFUk5FTD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3Rh cC0yL2NvbnRyb2wiLCBNT0RFPSIwNjAwIgogS0VSTkVMPT0iZ250ZGV2IiwgTkFNRT0ieGVuLyVr IiwgTU9ERT0iMDYwMCIKIEtFUk5FTD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1PREU9 IjA2MDAiCiBLRVJORUw9PSJ0YXBkZXZbYS16XSoiLCBOQU1FPSJ4ZW4vYmxrdGFwLTIvdGFwZGV2 JW0iLCBNT0RFPSIwNjAwIgotU1VCU1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElP Tj09ImFkZCIsIFJVTis9Ii9ldGMveGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0 eXBlX2lmPXRhcCIKK1NVQlNZU1RFTT09Im5ldCIsIEtFUk5FTD09InZpZiotZW11IiwgQUNUSU9O PT0iYWRkIiwgUlVOKz0iL2V0Yy94ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5 cGVfaWY9dGFwIgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xp YnhsL2xpYnhsX2RtLmMKaW5kZXggMWZmY2M5MC4uMmMwMzBjYSAxMDA2NDQKLS0tIGEvdG9vbHMv bGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCkBAIC0xMzQsMTEg KzEzNCw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX29s ZChsaWJ4bF9fZ2MgKmdjLAogICAgICAgICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3By aW50ZihnYywgIiUwMng6JTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4IiwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWZzW2ldLm1hY1swXSwgdmlmc1tpXS5tYWNb MV0sIHZpZnNbaV0ubWFjWzJdLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZpZnNbaV0ubWFjWzNdLCB2aWZzW2ldLm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwot ICAgICAgICAgICAgICAgIGNoYXIgKmlmbmFtZTsKLSAgICAgICAgICAgICAgICBpZiAoIXZpZnNb aV0uaWZuYW1lKQotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSBsaWJ4bF9fc3ByaW50Zihn YywgInRhcCVkLiVkIiwgaW5mby0+ZG9taWQsIHZpZnNbaV0uZGV2aWQpOwotICAgICAgICAgICAg ICAgIGVsc2UKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7Cisg ICAgICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2 aWYlZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhh cnJheV92YXBwZW5kKGRtX2FyZ3MsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIt bmV0IiwgbGlieGxfX3NwcmludGYoZ2MsICJuaWMsdmxhbj0lZCxtYWNhZGRyPSVzLG1vZGVsPSVz IiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB2aWZzW2ldLmRldmlkLCBzbWFjLCB2aWZzW2ldLm1vZGVsKSwKQEAgLTI3MSwxMiArMjY5LDkg QEAgc3RhdGljIGNoYXIgKiogbGlieGxfYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3KGxpYnhs X19nYyAqZ2MsCiAgICAgICAgICAgICAgICAgY2hhciAqc21hYyA9IGxpYnhsX19zcHJpbnRmKGdj LCAiJTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4OiUwMngiLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzBdLCB2aWZzW2ldLm1hY1sxXSwgdmlm c1tpXS5tYWNbMl0sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dmlmc1tpXS5tYWNbM10sIHZpZnNbaV0ubWFjWzRdLCB2aWZzW2ldLm1hY1s1XSk7Ci0gICAgICAg ICAgICAgICAgY2hhciAqaWZuYW1lOwotICAgICAgICAgICAgICAgIGlmICghdmlmc1tpXS5pZm5h bWUpIHsKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ0 YXAlZC4lZCIsIGluZm8tPmRvbWlkLCB2aWZzW2ldLmRldmlkKTsKLSAgICAgICAgICAgICAgICB9 IGVsc2UgewotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKLSAg ICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGli eGxfX3NwcmludGYoZ2MsICJ2aWYlZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAg ICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1uZXQiKTsKICAgICAgICAg ICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsIGxpYnhsX19zcHJpbnRmKGdjLCAibmlj LHZsYW49JWQsbWFjYWRkcj0lcyxtb2RlbD0lcyIsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdmlmc1tpXS5kZXZpZCwgc21hYywgdmlmc1tpXS5tb2RlbCkpOwpkaWZmIC0tZ2l0IGEvdG9v bHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdl LnB5CmluZGV4IGYxNDY0YWMuLjNjOGQ4MGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4v eGVuZC9pbWFnZS5weQorKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkx NywxMSArOTE3LDcgQEAgY2xhc3MgSFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6CiAgICAg ICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2 bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5p Y3MsIG1hYywgbW9kZWwpKQotICAgICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8uZ2V0KCd2aWZu YW1lJykKLSAgICAgICAgICAgIGlmIHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9 ICJ0YXAtIiArIHZpZm5hbWUKLSAgICAgICAgICAgIGVsc2U6Ci0gICAgICAgICAgICAgICAgdmlm bmFtZSA9ICJ0YXAlZC4lZCIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCisgICAgICAg ICAgICB2aWZuYW1lID0gInZpZiVkLiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNz LTEpCiAgICAgICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBl bmQoInRhcCx2bGFuPSVkLGlmbmFtZT0lcyxicmlkZ2U9JXMiICUKICAgICAgICAgICAgICAgICAg ICAgICAgKG5pY3MsIHZpZm5hbWUsIGJyaWRnZSkpCg== --f46d0447967d98696104bfe033c9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --f46d0447967d98696104bfe033c9-- From xen-devel-bounces@lists.xen.org Sun May 13 00:40:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 00:40:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STMqS-00057O-Tw; Sun, 13 May 2012 00:39:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STMqQ-00057J-AZ for xen-devel@lists.xen.org; Sun, 13 May 2012 00:39:30 +0000 Received: from [193.109.254.147:50933] by server-11.bemta-14.messagelabs.com id 68/C5-05858-1C20FAF4; Sun, 13 May 2012 00:39:29 +0000 X-Env-Sender: giamteckchoon@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336869566!2140474!1 X-Originating-IP: [209.85.214.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20754 invoked from network); 13 May 2012 00:39:28 -0000 Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2012 00:39:28 -0000 Received: by obbwd20 with SMTP id wd20so7019454obb.32 for ; Sat, 12 May 2012 17:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h3k9dsTMBqa+bTLY7GjlCjxS5MeucB5cYGofYcDXDJ0=; b=RrXNLw1MzFPxwdl7d/7sfRecn3VkF+4aa3314V9FkJpOeC+6cdeGtCdij9Ep9Cc0XK nT+fcvkcGJnU2L0o4m+GzkScfX36zfL5pBD97SoXs3ErjbEJyc9iBItRsvkC7iIY7XAz EXtubSN7wUlmp3zE7mkCl3GphASk/IcGMLHZvYH1gt7HgjrwmTIUgJHv242XoWYINGCg +eqGr1p4Fr48sp9BvpGN8txUtdfxRokb53m3aEiERCKHb9hxbgp35n52MAhONSq6SuWM OQfRr5yWBOnwQ/ctTrPiuL/uiO0oyhRv/O4bYdPPNCsrfUzCAISg31jiWMjIPVtjmmB4 uKOA== MIME-Version: 1.0 Received: by 10.182.5.132 with SMTP id s4mr4518342obs.65.1336869566048; Sat, 12 May 2012 17:39:26 -0700 (PDT) Received: by 10.182.9.170 with HTTP; Sat, 12 May 2012 17:39:25 -0700 (PDT) In-Reply-To: References: <1334658395.23948.6.camel@zakaz.uk.xensource.com> <1334817587.11493.44.camel@dagon.hellion.org.uk> <1334912603.28331.2.camel@zakaz.uk.xensource.com> <20369.15528.270106.567037@mariner.uk.xensource.com> <1334918900.28331.47.camel@zakaz.uk.xensource.com> <20369.16555.46229.798603@mariner.uk.xensource.com> <1334919613.28331.53.camel@zakaz.uk.xensource.com> <20369.17085.330843.561841@mariner.uk.xensource.com> <1335347949.28015.19.camel@zakaz.uk.xensource.com> <20375.52677.287182.934829@mariner.uk.xensource.com> <1335348880.28015.24.camel@zakaz.uk.xensource.com> <1335358736.28015.41.camel@zakaz.uk.xensource.com> <20397.10224.96552.711065@mariner.uk.xensource.com> <1336861837.3891.29.camel@dagon.hellion.org.uk> Date: Sun, 13 May 2012 08:39:25 +0800 Message-ID: From: Teck Choon Giam To: Ian Campbell Content-Type: multipart/mixed; boundary=f46d0447967d98696104bfe033c9 Cc: "xen-devel@lists.xen.org" , Roger Pau Monne , Ian Jackson , M A Young Subject: Re: [Xen-devel] [patch] xen udev rule interfering with openvpn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --f46d0447967d98696104bfe033c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 7:37 AM, Teck Choon Giam wrote: > On Sun, May 13, 2012 at 6:30 AM, Ian Campbell w= rote: >> On Sat, 2012-05-12 at 23:00 +0100, Teck Choon Giam wrote: >>> On Sat, May 12, 2012 at 3:29 PM, Teck Choon Giam >>> wrote: >>> > On Sat, May 12, 2012 at 7:53 AM, Teck Choon Giam >>> > wrote: >>> >> On Fri, May 11, 2012 at 10:53 PM, Ian Jackson wrote: >>> >>> Ian Campbell writes ("Re: [Xen-devel] [patch] xen udev rule interfe= ring with openvpn"): >>> >>>> libxl/xend: name tap devices vifX.Y-emu >>> >>> >>> >>> Committed-by: Ian Jackson >>> >> >>> >> This is my backport version which excludes the following: >>> >> >>> >> Lastly also move libxl__device_* to a better place in the header, ot= herwise the >>> >> comment about evgen stuff isn't next to the associated functions (no= ticed jsut >>> >> because I was going to add nic_devname near to the setdefault functi= ons) >>> >> >>> >> I have tested with xm and xl with and without vifname set in domU >>> >> config for hvmdomain and pvdomain. >>> > >>> > Sorry, when re-test one of the test case failed... xm create hvmdomai= n >>> > with vifname set. =A0I must have missed certain test case :( >>> >>> The same test case failed for xen unstable latest changeset 25326:cd4dd= 23a831d. >> >> Oh dear. >> >>> My tests as below: >> >> Which ones fail? >> >>> 1. xm create pvdomain without vifname set >>> 2. xl create pvdomain without vifname set >>> 3. xm create hvmdomain without vifname set >>> 4. xl create hvmdomain without vifname set >>> 5. xm create pvdomain with vifname set >>> 6. xl create pvdomain with vifname set >>> 7. xm create hvmdomain with vifname set > > xm create hvmdomain with vifname set > > > I track down the problem already. =A0It happens that xm and xl behave > differently when creating $dev device? > > In short, just set $dev down before: > do_or_die ip link set "$dev" name "$vifname" > Then set $vifname up after the above fix my problem. > > Is the above suitable in upstream/unstable? =A0If yes, can you fix that > in xen-unstable or you need me to submit a patch for review for > xen-unstable? > > With the below partial of my latest backport patch fix the problem but > I have to re-run all tests to double confirm all are fix and good to > go :p Attached is my final backport for xen-4.1-testing which passed all my tests as stated below: 1. xm create pvdomain without vifname set 2. xl create pvdomain without vifname set 3. xm create hvmdomain without vifname set 4. xl create hvmdomain without vifname set 5. xm create pvdomain with vifname set 6. xl create pvdomain with vifname set 7. xm create hvmdomain with vifname set 8. xl create hvmdomain with vifname set My initial backport patch failed for test no. 7 and when I perform test for all the above in latest xen-unstable it failed in test no. 7 as well. For review and comments please. Thanks. Kindest regards, Giam Teck Choon > > diff --git a/tools/hotplug/Linux/vif-common.sh > b/tools/hotplug/Linux/vif-common.sh > index c9c5d41..86c0aaa 100644 > --- a/tools/hotplug/Linux/vif-common.sh > +++ b/tools/hotplug/Linux/vif-common.sh > @@ -85,12 +85,25 @@ elif [ "$type_if" =3D tap ]; then > =A0 =A0 : ${INTERFACE:?} > > =A0 =A0 # Get xenbus_path from device name. > - =A0 =A0# The name is built like that: "tap${domid}.${devid}". > - =A0 =A0dev_=3D${dev#tap} > + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". > + =A0 =A0dev_=3D${dev#vif} > + =A0 =A0dev_=3D${dev_%-emu} > =A0 =A0 domid=3D${dev_%.*} > =A0 =A0 devid=3D${dev_#*.} > > =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" > + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" "") > + =A0 =A0if [ "$vifname" ] > + =A0 =A0then > + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" > + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$vifna= me" >&/dev/null > + =A0 =A0 =A0 =A0then > + =A0 =A0 =A0 =A0 =A0 =A0ip link set "$dev" down > + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname" > + =A0 =A0 =A0 =A0 =A0 =A0ip link set "$vifname" up > + =A0 =A0 =A0 =A0fi > + =A0 =A0 =A0 =A0dev=3D"$vifname" > + =A0 =A0fi > =A0fi > > > Thanks. > > Kindest regards, > Giam Teck Choon > > > >>> 8. xl create hvmdomain with vifname set >>> >>> Thanks. >>> >>> Kindest regards, >>> >>> >>> > >>> > Kindest regards, >>> > Giam Teck Choon >>> > >>> > >>> > >>> >> >>> >> For your review and comments please. >>> >> >>> >> Thanks. >>> >> >>> >> Kindest regards, >>> >> Giam Teck Choon >>> >> >>> >> >>> >> >>> >> >>> >> libxl/xend: name tap devices vifX.Y-emu >>> >> >>> >> This prevents the udev scripts from operating on other tap devices (= e.g. >>> >> openvpn etc) >>> >> >>> >> Correct the documentation for the "vifname" option which suggested i= t applied >>> >> to HVM tap devices only, which is not the case. >>> >> >>> >> Reported by Michael Young. >>> >> >>> >> Also fix the use of vifname with emulated devices. This is slightly = complex. >>> >> The current hotplug scripts rely on being able to parse the "tapX.Y"= (now >>> >> "vifX.Y-emu") name in order to locate the xenstore backend dir relat= ing to the >>> >> corresponding vif. This is because we cannot inject our own environm= ent vars >>> >> into the tap hotplug events. However this means that if the tap is i= nitially >>> >> named with a user specified name (which will not match the expected = scheme) we >>> >> fail to do anything useful with the device. So now we create the ini= tial tap >>> >> device with the standard "vifX.Y-emu" name and the hotplug script wi= ll handle >>> >> the rename to the desired name. This is also how PV vif devices work= -- they >>> >> are always created by netback with the name vifX.Y and renamed in th= e script. >>> >> >>> >> xen-unstable changeset: 25290:7a6dcecb1781 >>> >> Signed-off-by: Giam Teck Choon >>> >> --- >>> >> =A0tools/hotplug/Linux/vif-common.sh =A0 =A0 | =A0 15 +++++++++++++-= - >>> >> =A0tools/hotplug/Linux/xen-backend.rules | =A0 =A02 +- >>> >> =A0tools/libxl/libxl_dm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 17 ++= ++++----------- >>> >> =A0tools/python/xen/xend/image.py =A0 =A0 =A0 =A0| =A0 =A06 +----- >>> >> =A04 files changed, 21 insertions(+), 19 deletions(-) >>> >> >>> >> diff --git a/tools/hotplug/Linux/vif-common.sh >>> >> b/tools/hotplug/Linux/vif-common.sh >>> >> index c9c5d41..fff22bb 100644 >>> >> --- a/tools/hotplug/Linux/vif-common.sh >>> >> +++ b/tools/hotplug/Linux/vif-common.sh >>> >> @@ -85,12 +85,23 @@ elif [ "$type_if" =3D tap ]; then >>> >> =A0 =A0 : ${INTERFACE:?} >>> >> >>> >> =A0 =A0 # Get xenbus_path from device name. >>> >> - =A0 =A0# The name is built like that: "tap${domid}.${devid}". >>> >> - =A0 =A0dev_=3D${dev#tap} >>> >> + =A0 =A0# The name is built like that: "vif${domid}.${devid}-emu". >>> >> + =A0 =A0dev_=3D${dev#vif} >>> >> + =A0 =A0dev_=3D${dev_%-emu} >>> >> =A0 =A0 domid=3D${dev_%.*} >>> >> =A0 =A0 devid=3D${dev_#*.} >>> >> >>> >> =A0 =A0 XENBUS_PATH=3D"/local/domain/0/backend/vif/$domid/$devid" >>> >> + =A0 =A0vifname=3D$(xenstore_read_default "$XENBUS_PATH/vifname" ""= ) >>> >> + =A0 =A0if [ "$vifname" ] >>> >> + =A0 =A0then >>> >> + =A0 =A0 =A0 =A0vifname=3D"${vifname}-emu" >>> >> + =A0 =A0 =A0 =A0if [ "$command" =3D=3D "add" ] && ! ip link show "$= vifname" >&/dev/null >>> >> + =A0 =A0 =A0 =A0then >>> >> + =A0 =A0 =A0 =A0 =A0 =A0do_or_die ip link set "$dev" name "$vifname= " >>> >> + =A0 =A0 =A0 =A0fi >>> >> + =A0 =A0 =A0 =A0dev=3D"$vifname" >>> >> + =A0 =A0fi >>> >> =A0fi >>> >> >>> >> =A0ip=3D${ip:-} >>> >> diff --git a/tools/hotplug/Linux/xen-backend.rules >>> >> b/tools/hotplug/Linux/xen-backend.rules >>> >> index 40f2658..405387f 100644 >>> >> --- a/tools/hotplug/Linux/xen-backend.rules >>> >> +++ b/tools/hotplug/Linux/xen-backend.rules >>> >> @@ -13,4 +13,4 @@ KERNEL=3D=3D"blktap-control", >>> >> NAME=3D"xen/blktap-2/control", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"gntdev", NAME=3D"xen/%k", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"pci_iomul", NAME=3D"xen/%k", MODE=3D"0600" >>> >> =A0KERNEL=3D=3D"tapdev[a-z]*", NAME=3D"xen/blktap-2/tapdev%m", MODE= =3D"0600" >>> >> -SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"tap*", ACTION=3D=3D"add", >>> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >>> >> +SUBSYSTEM=3D=3D"net", KERNEL=3D=3D"vif*-emu", ACTION=3D=3D"add", >>> >> RUN+=3D"/etc/xen/scripts/vif-setup $env{ACTION} type_if=3Dtap" >>> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >>> >> index 1ffcc90..2c030ca 100644 >>> >> --- a/tools/libxl/libxl_dm.c >>> >> +++ b/tools/libxl/libxl_dm.c >>> >> @@ -134,11 +134,9 @@ static char ** >>> >> libxl_build_device_model_args_old(libxl__gc *gc, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >>> >> "%02x:%02x:%02x:%02x:%02x:%02x", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >>> >> vifs[i].mac[1], vifs[i].mac[2], >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >>> >> vifs[i].mac[4], vifs[i].mac[5]); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(g= c, "tap%d.%d", >>> >> info->domid, vifs[i].devid); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprin= tf(gc, "vif%d.%d-emu", >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_vappend(dm_args, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-ne= t", libxl__sprintf(gc, >>> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid, >>> >> smac, vifs[i].model), >>> >> @@ -271,12 +269,9 @@ static char ** >>> >> libxl_build_device_model_args_new(libxl__gc *gc, >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *smac =3D libxl__sprintf(gc, >>> >> "%02x:%02x:%02x:%02x:%02x:%02x", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[0], >>> >> vifs[i].mac[1], vifs[i].mac[2], >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0vifs[i].mac[3], >>> >> vifs[i].mac[4], vifs[i].mac[5]); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!vifs[i].ifname) { >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D libxl__sprintf(g= c, "tap%d.%d", >>> >> info->domid, vifs[i].devid); >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifname =3D vifs[i].ifname; >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char *ifname =3D libxl__sprin= tf(gc, "vif%d.%d-emu", >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->domid, >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifs[i].devid); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, "-net"); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flexarray_append(dm_args, libxl__spr= intf(gc, >>> >> "nic,vlan=3D%d,macaddr=3D%s,model=3D%s", >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vifs[i].devi= d, smac, vifs[i].model)); >>> >> diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/= image.py >>> >> index f1464ac..3c8d80c 100644 >>> >> --- a/tools/python/xen/xend/image.py >>> >> +++ b/tools/python/xen/xend/image.py >>> >> @@ -917,11 +917,7 @@ class HVMImageHandler(ImageHandler): >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("nic,vlan=3D%d,macaddr=3D%s,model= =3D%s" % >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, mac, model)) >>> >> - =A0 =A0 =A0 =A0 =A0 =A0vifname =3D devinfo.get('vifname') >>> >> - =A0 =A0 =A0 =A0 =A0 =A0if vifname: >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap-" + vifname >>> >> - =A0 =A0 =A0 =A0 =A0 =A0else: >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "tap%d.%d" % (self.vm.g= etDomid(), nics-1) >>> >> + =A0 =A0 =A0 =A0 =A0 =A0vifname =3D "vif%d.%d-emu" % (self.vm.getDo= mid(), nics-1) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("-net") >>> >> =A0 =A0 =A0 =A0 =A0 =A0 ret.append("tap,vlan=3D%d,ifname=3D%s,bridge= =3D%s" % >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(nics, vifname, bridg= e)) >> >> --f46d0447967d98696104bfe033c9 Content-Type: application/octet-stream; name="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Disposition: attachment; filename="backport-unstable-25290-to-xen-4.1-testing.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h25dl3f20 bGlieGwveGVuZDogbmFtZSB0YXAgZGV2aWNlcyB2aWZYLlktZW11CgpUaGlzIHByZXZlbnRzIHRo ZSB1ZGV2IHNjcmlwdHMgZnJvbSBvcGVyYXRpbmcgb24gb3RoZXIgdGFwIGRldmljZXMgKGUuZy4K b3BlbnZwbiBldGMpCgpDb3JyZWN0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgInZpZm5hbWUi IG9wdGlvbiB3aGljaCBzdWdnZXN0ZWQgaXQgYXBwbGllZAp0byBIVk0gdGFwIGRldmljZXMgb25s eSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLgoKUmVwb3J0ZWQgYnkgTWljaGFlbCBZb3VuZy4KCkFs c28gZml4IHRoZSB1c2Ugb2YgdmlmbmFtZSB3aXRoIGVtdWxhdGVkIGRldmljZXMuIFRoaXMgaXMg c2xpZ2h0bHkgY29tcGxleC4KVGhlIGN1cnJlbnQgaG90cGx1ZyBzY3JpcHRzIHJlbHkgb24gYmVp bmcgYWJsZSB0byBwYXJzZSB0aGUgInRhcFguWSIgKG5vdwoidmlmWC5ZLWVtdSIpIG5hbWUgaW4g b3JkZXIgdG8gbG9jYXRlIHRoZSB4ZW5zdG9yZSBiYWNrZW5kIGRpciByZWxhdGluZyB0byB0aGUK Y29ycmVzcG9uZGluZyB2aWYuIFRoaXMgaXMgYmVjYXVzZSB3ZSBjYW5ub3QgaW5qZWN0IG91ciBv d24gZW52aXJvbm1lbnQgdmFycwppbnRvIHRoZSB0YXAgaG90cGx1ZyBldmVudHMuIEhvd2V2ZXIg dGhpcyBtZWFucyB0aGF0IGlmIHRoZSB0YXAgaXMgaW5pdGlhbGx5Cm5hbWVkIHdpdGggYSB1c2Vy IHNwZWNpZmllZCBuYW1lICh3aGljaCB3aWxsIG5vdCBtYXRjaCB0aGUgZXhwZWN0ZWQgc2NoZW1l KSB3ZQpmYWlsIHRvIGRvIGFueXRoaW5nIHVzZWZ1bCB3aXRoIHRoZSBkZXZpY2UuIFNvIG5vdyB3 ZSBjcmVhdGUgdGhlIGluaXRpYWwgdGFwCmRldmljZSB3aXRoIHRoZSBzdGFuZGFyZCAidmlmWC5Z LWVtdSIgbmFtZSBhbmQgdGhlIGhvdHBsdWcgc2NyaXB0IHdpbGwgaGFuZGxlCnRoZSByZW5hbWUg dG8gdGhlIGRlc2lyZWQgbmFtZS4gVGhpcyBpcyBhbHNvIGhvdyBQViB2aWYgZGV2aWNlcyB3b3Jr IC0tIHRoZXkKYXJlIGFsd2F5cyBjcmVhdGVkIGJ5IG5ldGJhY2sgd2l0aCB0aGUgbmFtZSB2aWZY LlkgYW5kIHJlbmFtZWQgaW4gdGhlIHNjcmlwdC4KCnhlbi11bnN0YWJsZSBjaGFuZ2VzZXQ6IDI1 MjkwOjdhNmRjZWNiMTc4MQpTaWduZWQtb2ZmLWJ5OiBHaWFtIFRlY2sgQ2hvb24gPGdpYW10ZWNr Y2hvb25AZ21haWwuY29tPgotLS0KIHRvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaCAg ICAgfCAgIDE3ICsrKysrKysrKysrKysrKy0tCiB0b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNr ZW5kLnJ1bGVzIHwgICAgMiArLQogdG9vbHMvbGlieGwvbGlieGxfZG0uYyAgICAgICAgICAgICAg ICB8ICAgMTcgKysrKysrLS0tLS0tLS0tLS0KIHRvb2xzL3B5dGhvbi94ZW4veGVuZC9pbWFnZS5w eSAgICAgICAgfCAgICA2ICstLS0tLQogNCBmaWxlcyBjaGFuZ2VkLCAyMyBpbnNlcnRpb25zKCsp LCAxOSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1j b21tb24uc2ggYi90b29scy9ob3RwbHVnL0xpbnV4L3ZpZi1jb21tb24uc2gKaW5kZXggYzljNWQ0 MS4uODZjMGFhYSAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC92aWYtY29tbW9uLnNo CisrKyBiL3Rvb2xzL2hvdHBsdWcvTGludXgvdmlmLWNvbW1vbi5zaApAQCAtODUsMTIgKzg1LDI1 IEBAIGVsaWYgWyAiJHR5cGVfaWYiID0gdGFwIF07IHRoZW4KICAgICA6ICR7SU5URVJGQUNFOj99 CiAKICAgICAjIEdldCB4ZW5idXNfcGF0aCBmcm9tIGRldmljZSBuYW1lLgotICAgICMgVGhlIG5h bWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidGFwJHtkb21pZH0uJHtkZXZpZH0iLgotICAgIGRldl89 JHtkZXYjdGFwfQorICAgICMgVGhlIG5hbWUgaXMgYnVpbHQgbGlrZSB0aGF0OiAidmlmJHtkb21p ZH0uJHtkZXZpZH0tZW11Ii4KKyAgICBkZXZfPSR7ZGV2I3ZpZn0KKyAgICBkZXZfPSR7ZGV2XyUt ZW11fQogICAgIGRvbWlkPSR7ZGV2XyUuKn0KICAgICBkZXZpZD0ke2Rldl8jKi59CiAKICAgICBY RU5CVVNfUEFUSD0iL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLyRkb21pZC8kZGV2aWQiCisg ICAgdmlmbmFtZT0kKHhlbnN0b3JlX3JlYWRfZGVmYXVsdCAiJFhFTkJVU19QQVRIL3ZpZm5hbWUi ICIiKQorICAgIGlmIFsgIiR2aWZuYW1lIiBdCisgICAgdGhlbgorICAgICAgICB2aWZuYW1lPSIk e3ZpZm5hbWV9LWVtdSIKKyAgICAgICAgaWYgWyAiJGNvbW1hbmQiID09ICJhZGQiIF0gJiYgISBp cCBsaW5rIHNob3cgIiR2aWZuYW1lIiA+Ji9kZXYvbnVsbAorICAgICAgICB0aGVuCisgICAgICAg ICAgICBpcCBsaW5rIHNldCAiJGRldiIgZG93bgorICAgICAgICAgICAgZG9fb3JfZGllIGlwIGxp bmsgc2V0ICIkZGV2IiBuYW1lICIkdmlmbmFtZSIKKyAgICAgICAgICAgIGlwIGxpbmsgc2V0ICIk dmlmbmFtZSIgdXAKKyAgICAgICAgZmkKKyAgICAgICAgZGV2PSIkdmlmbmFtZSIKKyAgICBmaQog ZmkKIAogaXA9JHtpcDotfQpkaWZmIC0tZ2l0IGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFj a2VuZC5ydWxlcyBiL3Rvb2xzL2hvdHBsdWcvTGludXgveGVuLWJhY2tlbmQucnVsZXMKaW5kZXgg NDBmMjY1OC4uNDA1Mzg3ZiAxMDA2NDQKLS0tIGEvdG9vbHMvaG90cGx1Zy9MaW51eC94ZW4tYmFj a2VuZC5ydWxlcworKysgYi90b29scy9ob3RwbHVnL0xpbnV4L3hlbi1iYWNrZW5kLnJ1bGVzCkBA IC0xMyw0ICsxMyw0IEBAIEtFUk5FTD09ImJsa3RhcC1jb250cm9sIiwgTkFNRT0ieGVuL2Jsa3Rh cC0yL2NvbnRyb2wiLCBNT0RFPSIwNjAwIgogS0VSTkVMPT0iZ250ZGV2IiwgTkFNRT0ieGVuLyVr IiwgTU9ERT0iMDYwMCIKIEtFUk5FTD09InBjaV9pb211bCIsIE5BTUU9Inhlbi8layIsIE1PREU9 IjA2MDAiCiBLRVJORUw9PSJ0YXBkZXZbYS16XSoiLCBOQU1FPSJ4ZW4vYmxrdGFwLTIvdGFwZGV2 JW0iLCBNT0RFPSIwNjAwIgotU1VCU1lTVEVNPT0ibmV0IiwgS0VSTkVMPT0idGFwKiIsIEFDVElP Tj09ImFkZCIsIFJVTis9Ii9ldGMveGVuL3NjcmlwdHMvdmlmLXNldHVwICRlbnZ7QUNUSU9OfSB0 eXBlX2lmPXRhcCIKK1NVQlNZU1RFTT09Im5ldCIsIEtFUk5FTD09InZpZiotZW11IiwgQUNUSU9O PT0iYWRkIiwgUlVOKz0iL2V0Yy94ZW4vc2NyaXB0cy92aWYtc2V0dXAgJGVudntBQ1RJT059IHR5 cGVfaWY9dGFwIgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xp YnhsL2xpYnhsX2RtLmMKaW5kZXggMWZmY2M5MC4uMmMwMzBjYSAxMDA2NDQKLS0tIGEvdG9vbHMv bGlieGwvbGlieGxfZG0uYworKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCkBAIC0xMzQsMTEg KzEzNCw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdzX29s ZChsaWJ4bF9fZ2MgKmdjLAogICAgICAgICAgICAgICAgIGNoYXIgKnNtYWMgPSBsaWJ4bF9fc3By aW50ZihnYywgIiUwMng6JTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4IiwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWZzW2ldLm1hY1swXSwgdmlmc1tpXS5tYWNb MV0sIHZpZnNbaV0ubWFjWzJdLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZpZnNbaV0ubWFjWzNdLCB2aWZzW2ldLm1hY1s0XSwgdmlmc1tpXS5tYWNbNV0pOwot ICAgICAgICAgICAgICAgIGNoYXIgKmlmbmFtZTsKLSAgICAgICAgICAgICAgICBpZiAoIXZpZnNb aV0uaWZuYW1lKQotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSBsaWJ4bF9fc3ByaW50Zihn YywgInRhcCVkLiVkIiwgaW5mby0+ZG9taWQsIHZpZnNbaV0uZGV2aWQpOwotICAgICAgICAgICAg ICAgIGVsc2UKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gdmlmc1tpXS5pZm5hbWU7Cisg ICAgICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ2 aWYlZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAgICAgICAgICAgICAgIGZsZXhh cnJheV92YXBwZW5kKGRtX2FyZ3MsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIt bmV0IiwgbGlieGxfX3NwcmludGYoZ2MsICJuaWMsdmxhbj0lZCxtYWNhZGRyPSVzLG1vZGVsPSVz IiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB2aWZzW2ldLmRldmlkLCBzbWFjLCB2aWZzW2ldLm1vZGVsKSwKQEAgLTI3MSwxMiArMjY5LDkg QEAgc3RhdGljIGNoYXIgKiogbGlieGxfYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV3KGxpYnhs X19nYyAqZ2MsCiAgICAgICAgICAgICAgICAgY2hhciAqc21hYyA9IGxpYnhsX19zcHJpbnRmKGdj LCAiJTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4OiUwMngiLAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0ubWFjWzBdLCB2aWZzW2ldLm1hY1sxXSwgdmlm c1tpXS5tYWNbMl0sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dmlmc1tpXS5tYWNbM10sIHZpZnNbaV0ubWFjWzRdLCB2aWZzW2ldLm1hY1s1XSk7Ci0gICAgICAg ICAgICAgICAgY2hhciAqaWZuYW1lOwotICAgICAgICAgICAgICAgIGlmICghdmlmc1tpXS5pZm5h bWUpIHsKLSAgICAgICAgICAgICAgICAgICAgaWZuYW1lID0gbGlieGxfX3NwcmludGYoZ2MsICJ0 YXAlZC4lZCIsIGluZm8tPmRvbWlkLCB2aWZzW2ldLmRldmlkKTsKLSAgICAgICAgICAgICAgICB9 IGVsc2UgewotICAgICAgICAgICAgICAgICAgICBpZm5hbWUgPSB2aWZzW2ldLmlmbmFtZTsKLSAg ICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqaWZuYW1lID0gbGli eGxfX3NwcmludGYoZ2MsICJ2aWYlZC4lZC1lbXUiLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPmRvbWlkLAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZnNbaV0uZGV2aWQpOwogICAg ICAgICAgICAgICAgIGZsZXhhcnJheV9hcHBlbmQoZG1fYXJncywgIi1uZXQiKTsKICAgICAgICAg ICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGRtX2FyZ3MsIGxpYnhsX19zcHJpbnRmKGdjLCAibmlj LHZsYW49JWQsbWFjYWRkcj0lcyxtb2RlbD0lcyIsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdmlmc1tpXS5kZXZpZCwgc21hYywgdmlmc1tpXS5tb2RlbCkpOwpkaWZmIC0tZ2l0IGEvdG9v bHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdlLnB5IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL2ltYWdl LnB5CmluZGV4IGYxNDY0YWMuLjNjOGQ4MGMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4v eGVuZC9pbWFnZS5weQorKysgYi90b29scy9weXRob24veGVuL3hlbmQvaW1hZ2UucHkKQEAgLTkx NywxMSArOTE3LDcgQEAgY2xhc3MgSFZNSW1hZ2VIYW5kbGVyKEltYWdlSGFuZGxlcik6CiAgICAg ICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBlbmQoIm5pYyx2 bGFuPSVkLG1hY2FkZHI9JXMsbW9kZWw9JXMiICUKICAgICAgICAgICAgICAgICAgICAgICAgKG5p Y3MsIG1hYywgbW9kZWwpKQotICAgICAgICAgICAgdmlmbmFtZSA9IGRldmluZm8uZ2V0KCd2aWZu YW1lJykKLSAgICAgICAgICAgIGlmIHZpZm5hbWU6Ci0gICAgICAgICAgICAgICAgdmlmbmFtZSA9 ICJ0YXAtIiArIHZpZm5hbWUKLSAgICAgICAgICAgIGVsc2U6Ci0gICAgICAgICAgICAgICAgdmlm bmFtZSA9ICJ0YXAlZC4lZCIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNzLTEpCisgICAgICAg ICAgICB2aWZuYW1lID0gInZpZiVkLiVkLWVtdSIgJSAoc2VsZi52bS5nZXREb21pZCgpLCBuaWNz LTEpCiAgICAgICAgICAgICByZXQuYXBwZW5kKCItbmV0IikKICAgICAgICAgICAgIHJldC5hcHBl bmQoInRhcCx2bGFuPSVkLGlmbmFtZT0lcyxicmlkZ2U9JXMiICUKICAgICAgICAgICAgICAgICAg ICAgICAgKG5pY3MsIHZpZm5hbWUsIGJyaWRnZSkpCg== --f46d0447967d98696104bfe033c9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --f46d0447967d98696104bfe033c9-- From xen-devel-bounces@lists.xen.org Sun May 13 01:23:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 01: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 ) id 1STNW4-0001Gg-E7; Sun, 13 May 2012 01:22:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STNW2-0001Gb-Th for xen-devel@lists.xensource.com; Sun, 13 May 2012 01:22:31 +0000 Received: from [85.158.143.35:25596] by server-3.bemta-4.messagelabs.com id A2/1A-05853-6DC0FAF4; Sun, 13 May 2012 01:22:30 +0000 X-Env-Sender: lth@cow.dk X-Msg-Ref: server-9.tower-21.messagelabs.com!1336872149!4087081!1 X-Originating-IP: [95.166.183.192] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20052 invoked from network); 13 May 2012 01:22:29 -0000 Received: from 4607ds7-vby.0.fullrate.dk (HELO cow.netcompartner.com) (95.166.183.192) by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 13 May 2012 01:22:29 -0000 Received: from [210.195.65.36] (helo=ncpws04.localnet) by cow.netcompartner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from ) id 1STNVo-0006JF-N0; Sun, 13 May 2012 03:22:18 +0200 From: Lars Boegild Thomsen Organization: Call of the Wild BBS To: Jonathan Nieder Date: Sun, 13 May 2012 09:22:10 +0800 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; ) References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> <20120512231349.GA17443@burratino> In-Reply-To: <20120512231349.GA17443@burratino> MIME-Version: 1.0 Message-Id: <201205130922.10945.lth@cow.dk> X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "cow.netcompartner.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sunday 13 May 2012 07:13:49 Jonathan Nieder wrote: > In September, Kevin Tian wrote: > >> Lars Boegild Thomsen writes[1]: > >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up > >>> after sleep. Back to latest 2.6 kernel works fine. > - passing parameters "hpet=disable highres=off nohz=off" helps some > people if I understand correctly, but I might have misunderstood.[2] [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "Tian, Kevin" , "xen-devel@lists.xensource.com" , Robert Scott , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Ian Campbell , Andreas Wallberg , "mingo@redhat.com" , Fengzhe Zhang , Thomas Gleixner Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sunday 13 May 2012 07:13:49 Jonathan Nieder wrote: > In September, Kevin Tian wrote: > >> Lars Boegild Thomsen writes[1]: > >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up > >>> after sleep. Back to latest 2.6 kernel works fine. > - passing parameters "hpet=disable highres=off nohz=off" helps some > people if I understand correctly, but I might have misunderstood.[2] I didn't notice this one before but that actually works for me. Adding those kernel params and sleep works again. I tried combinations thereof but no-go - all 3 required. > I'd be interested to hear whether the same problem occurs when trying > to suspend from the minimal initramfs environment. (On systems like > Debian that use initramfs-tools, that means passing the kernel command > line parameter "break=top", booting, loading some appropriate minimal > collection of modules --- maybe none ---, and then running > "echo mem >/sys/power/state". initramfs-tools(8) has details.) And I just tried this loading no modules manually and it's the same - never wakes up after sleep. //Lars... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 01:23:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 01: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 ) id 1STNW4-0001Gg-E7; Sun, 13 May 2012 01:22:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STNW2-0001Gb-Th for xen-devel@lists.xensource.com; Sun, 13 May 2012 01:22:31 +0000 Received: from [85.158.143.35:25596] by server-3.bemta-4.messagelabs.com id A2/1A-05853-6DC0FAF4; Sun, 13 May 2012 01:22:30 +0000 X-Env-Sender: lth@cow.dk X-Msg-Ref: server-9.tower-21.messagelabs.com!1336872149!4087081!1 X-Originating-IP: [95.166.183.192] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20052 invoked from network); 13 May 2012 01:22:29 -0000 Received: from 4607ds7-vby.0.fullrate.dk (HELO cow.netcompartner.com) (95.166.183.192) by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 13 May 2012 01:22:29 -0000 Received: from [210.195.65.36] (helo=ncpws04.localnet) by cow.netcompartner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from ) id 1STNVo-0006JF-N0; Sun, 13 May 2012 03:22:18 +0200 From: Lars Boegild Thomsen Organization: Call of the Wild BBS To: Jonathan Nieder Date: Sun, 13 May 2012 09:22:10 +0800 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; ) References: <625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@shsmsx502.ccr.corp.intel.com> <625BA99ED14B2D499DC4E29D8138F15063048B864D@shsmsx502.ccr.corp.intel.com> <20120512231349.GA17443@burratino> In-Reply-To: <20120512231349.GA17443@burratino> MIME-Version: 1.0 Message-Id: <201205130922.10945.lth@cow.dk> X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "cow.netcompartner.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sunday 13 May 2012 07:13:49 Jonathan Nieder wrote: > In September, Kevin Tian wrote: > >> Lars Boegild Thomsen writes[1]: > >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up > >>> after sleep. Back to latest 2.6 kernel works fine. > - passing parameters "hpet=disable highres=off nohz=off" helps some > people if I understand correctly, but I might have misunderstood.[2] [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "Tian, Kevin" , "xen-devel@lists.xensource.com" , Robert Scott , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , Ian Campbell , Andreas Wallberg , "mingo@redhat.com" , Fengzhe Zhang , Thomas Gleixner Subject: Re: [Xen-devel] [regression] Ideapad S10-3 does not wake up from suspend X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sunday 13 May 2012 07:13:49 Jonathan Nieder wrote: > In September, Kevin Tian wrote: > >> Lars Boegild Thomsen writes[1]: > >>> After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up > >>> after sleep. Back to latest 2.6 kernel works fine. > - passing parameters "hpet=disable highres=off nohz=off" helps some > people if I understand correctly, but I might have misunderstood.[2] I didn't notice this one before but that actually works for me. Adding those kernel params and sleep works again. I tried combinations thereof but no-go - all 3 required. > I'd be interested to hear whether the same problem occurs when trying > to suspend from the minimal initramfs environment. (On systems like > Debian that use initramfs-tools, that means passing the kernel command > line parameter "break=top", booting, loading some appropriate minimal > collection of modules --- maybe none ---, and then running > "echo mem >/sys/power/state". initramfs-tools(8) has details.) And I just tried this loading no modules manually and it's the same - never wakes up after sleep. //Lars... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 07:19:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 07:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STT4k-0003tG-Tb; Sun, 13 May 2012 07:18:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STT4j-0003tB-2o for xen-devel@lists.xensource.com; Sun, 13 May 2012 07:18:41 +0000 Received: from [193.109.254.147:46319] by server-1.bemta-14.messagelabs.com id D4/D9-29372-0506FAF4; Sun, 13 May 2012 07:18:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336893519!2149232!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODc5Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4780 invoked from network); 13 May 2012 07:18:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2012 07:18:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,579,1330905600"; d="scan'208";a="12443488" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 May 2012 07:18:39 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 13 May 2012 08:18:38 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1STT4g-0003IA-Nu; Sun, 13 May 2012 07:18:38 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1STT4g-0002jb-KR; Sun, 13 May 2012 08:18:38 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sun, 13 May 2012 08:18:38 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12857: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12857 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12857/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 12856 test-amd64-amd64-xl-sedf-pin 9 guest-start fail in 12856 pass in 12857 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12856 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail in 12856 never pass version targeted for testing: xen cd4dd23a831d baseline version: xen cd4dd23a831d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 07:19:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 07:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STT4k-0003tG-Tb; Sun, 13 May 2012 07:18:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STT4j-0003tB-2o for xen-devel@lists.xensource.com; Sun, 13 May 2012 07:18:41 +0000 Received: from [193.109.254.147:46319] by server-1.bemta-14.messagelabs.com id D4/D9-29372-0506FAF4; Sun, 13 May 2012 07:18:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336893519!2149232!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODc5Nw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4780 invoked from network); 13 May 2012 07:18:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2012 07:18:39 -0000 X-IronPort-AV: E=Sophos;i="4.75,579,1330905600"; d="scan'208";a="12443488" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 May 2012 07:18:39 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 13 May 2012 08:18:38 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1STT4g-0003IA-Nu; Sun, 13 May 2012 07:18:38 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1STT4g-0002jb-KR; Sun, 13 May 2012 08:18:38 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sun, 13 May 2012 08:18:38 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 12857: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 12857 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12857/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-localmigrate.2 fail pass in 12856 test-amd64-amd64-xl-sedf-pin 9 guest-start fail in 12856 pass in 12857 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail like 12856 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 9 guest-start.2 fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 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-rhel6hvm-amd 11 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-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop 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-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail in 12856 never pass version targeted for testing: xen cd4dd23a831d baseline version: xen cd4dd23a831d jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 08:36:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 08: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 ) id 1STUHY-0004hx-Lj; Sun, 13 May 2012 08:36:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STUHW-0004hs-7c for xen-devel@lists.xen.org; Sun, 13 May 2012 08:35:58 +0000 Received: from [85.158.138.51:35373] by server-9.bemta-3.messagelabs.com id 04/60-26691-D627FAF4; Sun, 13 May 2012 08:35:57 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-11.tower-174.messagelabs.com!1336898156!26833718!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14565 invoked from network); 13 May 2012 08:35:56 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-11.tower-174.messagelabs.com with SMTP; 13 May 2012 08:35:56 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77827918; Sun, 13 May 2012 10:35:55 +0200 Message-ID: <1336898139.2612.1.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Sun, 13 May 2012 10:35:39 +0200 In-Reply-To: <1336778609.27081.1.camel@Abyss> References: <20943633a63e0691272b.1336778417@Solace> <1336778609.27081.1.camel@Abyss> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7363166968530265349==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7363166968530265349== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6sClyjmvO9Yib4cz+xM1" --=-6sClyjmvO9Yib4cz+xM1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-05-12 at 01:23 +0200, Dario Faggioli wrote:=20 > On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote:=20 > > xm supports the following syntax (in the config file) for > > specific VCPU to PCPU mapping: > >=20 > > cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > >=20 > > Allow for the same to be done in xl. > >=20 > And yes, I'm proposing this for 4.2, as not having it is a feature > parity between xm and xl bug someone reported on @xen-users. >=20 Damn! I forgot to update the doc (xl manual) accordingly! Feel free to provide any comments but, please, wait for a new and complete version before applying. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-6sClyjmvO9Yib4cz+xM1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+vclsACgkQk4XaBE3IOsRiWQCgpBVZDuKq8UdtLjU1H4mdxwif HZUAn2ozGWKSZR7lSobsSlgs9T7k/3tx =og5C -----END PGP SIGNATURE----- --=-6sClyjmvO9Yib4cz+xM1-- --===============7363166968530265349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7363166968530265349==-- From xen-devel-bounces@lists.xen.org Sun May 13 08:36:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 08: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 ) id 1STUHY-0004hx-Lj; Sun, 13 May 2012 08:36:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STUHW-0004hs-7c for xen-devel@lists.xen.org; Sun, 13 May 2012 08:35:58 +0000 Received: from [85.158.138.51:35373] by server-9.bemta-3.messagelabs.com id 04/60-26691-D627FAF4; Sun, 13 May 2012 08:35:57 +0000 X-Env-Sender: raistlin@linux.it X-Msg-Ref: server-11.tower-174.messagelabs.com!1336898156!26833718!1 X-Originating-IP: [193.205.80.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14565 invoked from network); 13 May 2012 08:35:56 -0000 Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99) by server-11.tower-174.messagelabs.com with SMTP; 13 May 2012 08:35:56 -0000 Received: from [62.94.182.223] (account d.faggioli@sssup.it HELO [192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14) with ESMTPSA id 77827918; Sun, 13 May 2012 10:35:55 +0200 Message-ID: <1336898139.2612.1.camel@Abyss> From: Dario Faggioli To: xen-devel@lists.xen.org Date: Sun, 13 May 2012 10:35:39 +0200 In-Reply-To: <1336778609.27081.1.camel@Abyss> References: <20943633a63e0691272b.1336778417@Solace> <1336778609.27081.1.camel@Abyss> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Cc: Ian Jackson , Ian Campbell Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7363166968530265349==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7363166968530265349== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6sClyjmvO9Yib4cz+xM1" --=-6sClyjmvO9Yib4cz+xM1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-05-12 at 01:23 +0200, Dario Faggioli wrote:=20 > On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote:=20 > > xm supports the following syntax (in the config file) for > > specific VCPU to PCPU mapping: > >=20 > > cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > >=20 > > Allow for the same to be done in xl. > >=20 > And yes, I'm proposing this for 4.2, as not having it is a feature > parity between xm and xl bug someone reported on @xen-users. >=20 Damn! I forgot to update the doc (xl manual) accordingly! Feel free to provide any comments but, please, wait for a new and complete version before applying. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-6sClyjmvO9Yib4cz+xM1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+vclsACgkQk4XaBE3IOsRiWQCgpBVZDuKq8UdtLjU1H4mdxwif HZUAn2ozGWKSZR7lSobsSlgs9T7k/3tx =og5C -----END PGP SIGNATURE----- --=-6sClyjmvO9Yib4cz+xM1-- --===============7363166968530265349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7363166968530265349==-- From xen-devel-bounces@lists.xen.org Sun May 13 08:56:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 08: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 ) id 1STUbH-0004sY-Iy; Sun, 13 May 2012 08:56:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STUbF-0004sT-Ie for xen-devel@lists.xen.org; Sun, 13 May 2012 08:56:21 +0000 Received: from [193.109.254.147:14355] by server-3.bemta-14.messagelabs.com id 40/6A-23274-4377FAF4; Sun, 13 May 2012 08:56:20 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-15.tower-27.messagelabs.com!1336899379!2156001!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDcyNTA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18039 invoked from network); 13 May 2012 08:56:20 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 May 2012 08:56:20 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id EA05B179B; Sun, 13 May 2012 11:56:18 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A12AF2005D; Sun, 13 May 2012 11:56:18 +0300 (EEST) Date: Sun, 13 May 2012 11:56:18 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Sander Eikelenboom Message-ID: <20120513085618.GL2058@reaktio.net> References: <20120512041645.11509848@internecto.net> <318116397.20120512092004@eikelenboom.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <318116397.20120512092004@eikelenboom.it> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mark , xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 09:20:04AM +0200, Sander Eikelenboom wrote: > Hello Mark, > > Saturday, May 12, 2012, 4:16:45 AM, you wrote: > > > Hello everyone, > > > Said Xen version running on kernel 3.3.4 x86_64. > > > I had put in Grub's "module /vmlinuz.gz" line: > > > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) > > Should be xen-pciback.hide (not a underscore) > Yep. Also the subject is misleading because this is a *Linux* dom0 kernel configuration issue, not xen-4.1-testing.hg issue. -- Pasi > -- > Sander > > > > This yields an error in dmesg: > > > xen_pciback: Unknown parameter `2)' > > > I tried all sorts of variations: quoting the pci devices, prefixing > > the devices with an extra 0000:, putting the thing somewhere else. But > > the error keeps returning. > > > I am working around this by having added the hide option in a > > modules.conf entry. > > > For further contact please be aware I am not receiving xen-devel > > emails, so please include me in CC's when more info is required. > > > Thank you, > > Mark > > > > > > -- > Best regards, > Sander mailto:linux@eikelenboom.it > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 08:56:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 08: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 ) id 1STUbH-0004sY-Iy; Sun, 13 May 2012 08:56:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STUbF-0004sT-Ie for xen-devel@lists.xen.org; Sun, 13 May 2012 08:56:21 +0000 Received: from [193.109.254.147:14355] by server-3.bemta-14.messagelabs.com id 40/6A-23274-4377FAF4; Sun, 13 May 2012 08:56:20 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-15.tower-27.messagelabs.com!1336899379!2156001!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDcyNTA=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18039 invoked from network); 13 May 2012 08:56:20 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 May 2012 08:56:20 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id EA05B179B; Sun, 13 May 2012 11:56:18 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A12AF2005D; Sun, 13 May 2012 11:56:18 +0300 (EEST) Date: Sun, 13 May 2012 11:56:18 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Sander Eikelenboom Message-ID: <20120513085618.GL2058@reaktio.net> References: <20120512041645.11509848@internecto.net> <318116397.20120512092004@eikelenboom.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <318116397.20120512092004@eikelenboom.it> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mark , xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, May 12, 2012 at 09:20:04AM +0200, Sander Eikelenboom wrote: > Hello Mark, > > Saturday, May 12, 2012, 4:16:45 AM, you wrote: > > > Hello everyone, > > > Said Xen version running on kernel 3.3.4 x86_64. > > > I had put in Grub's "module /vmlinuz.gz" line: > > > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) > > Should be xen-pciback.hide (not a underscore) > Yep. Also the subject is misleading because this is a *Linux* dom0 kernel configuration issue, not xen-4.1-testing.hg issue. -- Pasi > -- > Sander > > > > This yields an error in dmesg: > > > xen_pciback: Unknown parameter `2)' > > > I tried all sorts of variations: quoting the pci devices, prefixing > > the devices with an extra 0000:, putting the thing somewhere else. But > > the error keeps returning. > > > I am working around this by having added the hide option in a > > modules.conf entry. > > > For further contact please be aware I am not receiving xen-devel > > emails, so please include me in CC's when more info is required. > > > Thank you, > > Mark > > > > > > -- > Best regards, > Sander mailto:linux@eikelenboom.it > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 10:19:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 10:19:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STVsk-0005LM-TM; Sun, 13 May 2012 10:18:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STVsj-0005LH-No for xen-devel@lists.xen.org; Sun, 13 May 2012 10:18:29 +0000 Received: from [85.158.139.83:17064] by server-7.bemta-5.messagelabs.com id 26/E6-16195-47A8FAF4; Sun, 13 May 2012 10:18:28 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-8.tower-182.messagelabs.com!1336904308!16845747!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19170 invoked from network); 13 May 2012 10:18:28 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-8.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 13 May 2012 10:18:28 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49473 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1STVoF-0006Bc-9x; Sun, 13 May 2012 12:13:51 +0200 Date: Sun, 13 May 2012 12:18:25 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1049107950.20120513121825@eikelenboom.it> To: Internecto List Subscriber In-Reply-To: <20120512125506.4a4a927c@internecto.net> References: <20120512041645.11509848@internecto.net> <318116397.20120512092004@eikelenboom.it> <20120512125506.4a4a927c@internecto.net> MIME-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Internecto, Saturday, May 12, 2012, 12:55:06 PM, you wrote: > On Sat, 12 May 2012 09:20:04 +0200 > Sander Eikelenboom wrote: >> Hello Mark, > Hi Sander, >> >> Saturday, May 12, 2012, 4:16:45 AM, you wrote: >> >> > Hello everyone, >> >> > Said Xen version running on kernel 3.3.4 x86_64. >> >> > I had put in Grub's "module /vmlinuz.gz" line: >> >> > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) >> >> Should be xen-pciback.hide (not a underscore) > Thanks for the suggestion, but unfortunately this makes no difference... > I still get the same error. Also, I think both are allowed, the actual > name of the module is xen_pciback and I think kmod considers both - and > _ to be equally valid.. You have compiled xen-pciback as a module, perhaps you could try to compile it in the kernel to rule out problems with module loading ? It works for me (tm), could you also give the complete grub lines ? -- Sander > Mark -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 10:19:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 10:19:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STVsk-0005LM-TM; Sun, 13 May 2012 10:18:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STVsj-0005LH-No for xen-devel@lists.xen.org; Sun, 13 May 2012 10:18:29 +0000 Received: from [85.158.139.83:17064] by server-7.bemta-5.messagelabs.com id 26/E6-16195-47A8FAF4; Sun, 13 May 2012 10:18:28 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-8.tower-182.messagelabs.com!1336904308!16845747!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19170 invoked from network); 13 May 2012 10:18:28 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-8.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 13 May 2012 10:18:28 -0000 Received: from 2-69-ftth.onsneteindhoven.nl ([88.159.69.2]:49473 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1STVoF-0006Bc-9x; Sun, 13 May 2012 12:13:51 +0200 Date: Sun, 13 May 2012 12:18:25 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1049107950.20120513121825@eikelenboom.it> To: Internecto List Subscriber In-Reply-To: <20120512125506.4a4a927c@internecto.net> References: <20120512041645.11509848@internecto.net> <318116397.20120512092004@eikelenboom.it> <20120512125506.4a4a927c@internecto.net> MIME-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-pciback.hide bug report: parse error in current xen-4.1-stable.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hello Internecto, Saturday, May 12, 2012, 12:55:06 PM, you wrote: > On Sat, 12 May 2012 09:20:04 +0200 > Sander Eikelenboom wrote: >> Hello Mark, > Hi Sander, >> >> Saturday, May 12, 2012, 4:16:45 AM, you wrote: >> >> > Hello everyone, >> >> > Said Xen version running on kernel 3.3.4 x86_64. >> >> > I had put in Grub's "module /vmlinuz.gz" line: >> >> > xen_pciback.hide=(02:10.0)(02:10.2)(etc.) >> >> Should be xen-pciback.hide (not a underscore) > Thanks for the suggestion, but unfortunately this makes no difference... > I still get the same error. Also, I think both are allowed, the actual > name of the module is xen_pciback and I think kmod considers both - and > _ to be equally valid.. You have compiled xen-pciback as a module, perhaps you could try to compile it in the kernel to rule out problems with module loading ? It works for me (tm), could you also give the complete grub lines ? -- Sander > Mark -- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 20:25:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 20:25:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STfLC-0001cM-B2; Sun, 13 May 2012 20:24:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STfLB-0001cH-AC for xen-devel@lists.xensource.com; Sun, 13 May 2012 20:24:29 +0000 Received: from [193.109.254.147:32299] by server-12.bemta-14.messagelabs.com id 8E/BC-05898-C7810BF4; Sun, 13 May 2012 20:24:28 +0000 X-Env-Sender: k@itoc.dk X-Msg-Ref: server-12.tower-27.messagelabs.com!1336940666!9049142!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19430 invoked from network); 13 May 2012 20:24:27 -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; 13 May 2012 20:24:27 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1STfL8-0005gm-1I for xen-devel@lists.xensource.com; Sun, 13 May 2012 13:24:26 -0700 Date: Sun, 13 May 2012 13:24:26 -0700 (PDT) From: Kristoffer Harthing Egefelt To: xen-devel@lists.xensource.com Message-ID: <1336940666023-5708399.post@n5.nabble.com> In-Reply-To: <20120510154255.GH6389@phenom.dumpdata.com> References: <20120327192644.GQ12984@reaktio.net> <1332880165775-5598838.post@n5.nabble.com> <1332883903167-5598955.post@n5.nabble.com> <20120327215159.GA17203@phenom.dumpdata.com> <1332887727951-5599061.post@n5.nabble.com> <20120328143712.GG18161@phenom.dumpdata.com> <1333009808678-5602999.post@n5.nabble.com> <20120329145944.GF12008@phenom.dumpdata.com> <1333046630807-5604684.post@n5.nabble.com> <20120510154255.GH6389@phenom.dumpdata.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] no-carrier on qlogic 8242 10gig with linux 3.x running xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Any luck? Actually after finding out about the pci=nomsi kernel parameter, I have not had any problems. Regarding the firmware upgrade, qlogic and dell need a supported OS to run their diag tools on, I'm tired of dealing with them, so I have not gathered this info yet. Didn't try to downgrade the driver either. But I'm about to try pci passthrough, to have 10gig directly in the domU. I'll let you know if it works. -- View this message in context: http://xen.1045712.n5.nabble.com/no-carrier-on-qlogic-8242-10gig-with-linux-3-x-running-xen-tp5597283p5708399.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sun May 13 20:25:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 May 2012 20:25:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STfLC-0001cM-B2; Sun, 13 May 2012 20:24:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STfLB-0001cH-AC for xen-devel@lists.xensource.com; Sun, 13 May 2012 20:24:29 +0000 Received: from [193.109.254.147:32299] by server-12.bemta-14.messagelabs.com id 8E/BC-05898-C7810BF4; Sun, 13 May 2012 20:24:28 +0000 X-Env-Sender: k@itoc.dk X-Msg-Ref: server-12.tower-27.messagelabs.com!1336940666!9049142!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19430 invoked from network); 13 May 2012 20:24:27 -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; 13 May 2012 20:24:27 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1STfL8-0005gm-1I for xen-devel@lists.xensource.com; Sun, 13 May 2012 13:24:26 -0700 Date: Sun, 13 May 2012 13:24:26 -0700 (PDT) From: Kristoffer Harthing Egefelt To: xen-devel@lists.xensource.com Message-ID: <1336940666023-5708399.post@n5.nabble.com> In-Reply-To: <20120510154255.GH6389@phenom.dumpdata.com> References: <20120327192644.GQ12984@reaktio.net> <1332880165775-5598838.post@n5.nabble.com> <1332883903167-5598955.post@n5.nabble.com> <20120327215159.GA17203@phenom.dumpdata.com> <1332887727951-5599061.post@n5.nabble.com> <20120328143712.GG18161@phenom.dumpdata.com> <1333009808678-5602999.post@n5.nabble.com> <20120329145944.GF12008@phenom.dumpdata.com> <1333046630807-5604684.post@n5.nabble.com> <20120510154255.GH6389@phenom.dumpdata.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] no-carrier on qlogic 8242 10gig with linux 3.x running xen X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Any luck? Actually after finding out about the pci=nomsi kernel parameter, I have not had any problems. Regarding the firmware upgrade, qlogic and dell need a supported OS to run their diag tools on, I'm tired of dealing with them, so I have not gathered this info yet. Didn't try to downgrade the driver either. But I'm about to try pci passthrough, to have 10gig directly in the domU. I'll let you know if it works. -- View this message in context: http://xen.1045712.n5.nabble.com/no-carrier-on-qlogic-8242-10gig-with-linux-3-x-running-xen-tp5597283p5708399.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 01:27:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 01: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 ) id 1STk3Y-0007CQ-7Y; Mon, 14 May 2012 01:26:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STk3W-0007CL-Bt for xen-devel@lists.xen.org; Mon, 14 May 2012 01:26:34 +0000 Received: from [193.109.254.147:19113] by server-11.bemta-14.messagelabs.com id 30/6A-05858-94F50BF4; Mon, 14 May 2012 01:26:33 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336958792!9123702!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3ODA1\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15786 invoked from network); 14 May 2012 01:26:32 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-3.tower-27.messagelabs.com with SMTP; 14 May 2012 01:26:32 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 13 May 2012 18:26:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99631985" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 13 May 2012 18:26:30 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 13 May 2012 18:26:30 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Mon, 14 May 2012 09:26:28 +0800 From: "Dong, Eddie" To: "Hao, Xudong" , "Jan Beulich (JBeulich@suse.com)" , "Keir Fraser (keir.xen@gmail.com)" Thread-Topic: [PATCH v2] Fix the mistake for #DB and #OF exception Thread-Index: Ac0wHoS1rWMeWTdrSEKneX/7XlgnswBUfZ4g Date: Mon, 14 May 2012 01:26:27 +0000 Message-ID: References: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xudong: VM_ENTRY_INSTRUCTION_LEN is hard to detect due to the prefix instruction. We may rely on the caller to handle... Thx, Eddie > -----Original Message----- > From: Hao, Xudong > Sent: Saturday, May 12, 2012 5:13 PM > To: Jan Beulich (JBeulich@suse.com); Keir Fraser (keir.xen@gmail.com) > Cc: Aravindh Puthiyaparambil; Dong, Eddie; Zhang, Xiantao; Nakajima, Jun; > xen-devel (xen-devel@lists.xen.org) > Subject: [PATCH v2] Fix the mistake for #DB and #OF exception > > Fix the mistake for debug exception(#DB; generated by INT1), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #DB should use hardware exception(except #DB generated by opcode 0xf1), > #OF should use software exception, which int n instruction should use > software interrupt. > > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 > @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and > + * INT0 use software exception, and INT n should use > + * software interrupt. > + */ > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); > @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 > */ > } > break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 01:27:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 01: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 ) id 1STk3Y-0007CQ-7Y; Mon, 14 May 2012 01:26:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STk3W-0007CL-Bt for xen-devel@lists.xen.org; Mon, 14 May 2012 01:26:34 +0000 Received: from [193.109.254.147:19113] by server-11.bemta-14.messagelabs.com id 30/6A-05858-94F50BF4; Mon, 14 May 2012 01:26:33 +0000 X-Env-Sender: eddie.dong@intel.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336958792!9123702!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjc3ODA1\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15786 invoked from network); 14 May 2012 01:26:32 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-3.tower-27.messagelabs.com with SMTP; 14 May 2012 01:26:32 -0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 13 May 2012 18:26:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="99631985" Received: from azsmsx601.amr.corp.intel.com ([10.2.121.193]) by AZSMGA002.ch.intel.com with ESMTP; 13 May 2012 18:26:30 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 13 May 2012 18:26:30 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.133]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.90]) with mapi id 14.01.0355.002; Mon, 14 May 2012 09:26:28 +0800 From: "Dong, Eddie" To: "Hao, Xudong" , "Jan Beulich (JBeulich@suse.com)" , "Keir Fraser (keir.xen@gmail.com)" Thread-Topic: [PATCH v2] Fix the mistake for #DB and #OF exception Thread-Index: Ac0wHoS1rWMeWTdrSEKneX/7XlgnswBUfZ4g Date: Mon, 14 May 2012 01:26:27 +0000 Message-ID: References: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@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: Aravindh Puthiyaparambil , "Dong, Eddie" , "Nakajima, Jun" , "Zhang, Xiantao" , "xen-devel \(xen-devel@lists.xen.org\)" Subject: Re: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Xudong: VM_ENTRY_INSTRUCTION_LEN is hard to detect due to the prefix instruction. We may rely on the caller to handle... Thx, Eddie > -----Original Message----- > From: Hao, Xudong > Sent: Saturday, May 12, 2012 5:13 PM > To: Jan Beulich (JBeulich@suse.com); Keir Fraser (keir.xen@gmail.com) > Cc: Aravindh Puthiyaparambil; Dong, Eddie; Zhang, Xiantao; Nakajima, Jun; > xen-devel (xen-devel@lists.xen.org) > Subject: [PATCH v2] Fix the mistake for #DB and #OF exception > > Fix the mistake for debug exception(#DB; generated by INT1), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #DB should use hardware exception(except #DB generated by opcode 0xf1), > #OF should use software exception, which int n instruction should use > software interrupt. > > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 > @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and > + * INT0 use software exception, and INT n should use > + * software interrupt. > + */ > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); > @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 > */ > } > break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 07:39:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 07: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 ) id 1STps6-0003OS-6d; Mon, 14 May 2012 07:39:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STps5-0003ON-99 for xen-devel@lists.xen.org; Mon, 14 May 2012 07:39:09 +0000 Received: from [193.109.254.147:8039] by server-2.bemta-14.messagelabs.com id 23/66-19409-C96B0BF4; Mon, 14 May 2012 07:39:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336981147!9072977!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24554 invoked from network); 14 May 2012 07:39:07 -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; 14 May 2012 07:39:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 08:39:07 +0100 Message-Id: <4FB0D2B70200007800083547@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 08:39:03 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 18:01, Stefano Stabellini wrote: > On Thu, 10 May 2012, Jan Beulich wrote: >> While for the "normal" case (called from blk_send_response_all()) >> decrementing requests_finished is correct, doing so in the parse error >> case is wrong; requests_inflight needs to be decremented instead. >> >> Signed-off-by: Jan Beulich >> >> --- a/hw/xen_disk.c >> +++ b/hw/xen_disk.c >> @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i >> blkdev->requests_finished++; >> } >> >> -static void ioreq_release(struct ioreq *ioreq) >> +static void ioreq_release(struct ioreq *ioreq, bool finish) >> { >> struct XenBlkDev *blkdev = ioreq->blkdev; >> >> @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * >> memset(ioreq, 0, sizeof(*ioreq)); >> ioreq->blkdev = blkdev; >> QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); >> - blkdev->requests_finished--; >> + if (finish) >> + blkdev->requests_finished--; >> + else >> + blkdev->requests_inflight--; >> } >> >> /* >> @@ -449,7 +452,7 @@ static void blk_send_response_all(struct >> while (!QLIST_EMPTY(&blkdev->finished)) { >> ioreq = QLIST_FIRST(&blkdev->finished); >> send_notify += blk_send_response_one(ioreq); >> - ioreq_release(ioreq); >> + ioreq_release(ioreq, true); >> } >> if (send_notify) { >> xen_be_send_notify(&blkdev->xendev); >> @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X >> if (blk_send_response_one(ioreq)) { >> xen_be_send_notify(&blkdev->xendev); >> } >> - ioreq_release(ioreq); >> + ioreq_release(ioreq, false); >> continue; >> } > > In case of an error returned by ioreq_parse requests_finished should > also be decremented. I don't think so - it gets incremented in ioreq_finish(), and that gets called only when I/O was at least attempted (which isn't the case when parse failed). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 07:39:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 07: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 ) id 1STps6-0003OS-6d; Mon, 14 May 2012 07:39:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STps5-0003ON-99 for xen-devel@lists.xen.org; Mon, 14 May 2012 07:39:09 +0000 Received: from [193.109.254.147:8039] by server-2.bemta-14.messagelabs.com id 23/66-19409-C96B0BF4; Mon, 14 May 2012 07:39:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1336981147!9072977!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24554 invoked from network); 14 May 2012 07:39:07 -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; 14 May 2012 07:39:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 08:39:07 +0100 Message-Id: <4FB0D2B70200007800083547@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 08:39:03 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <4FABFCF40200007800082CE0@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] qemu/xendisk: properly update stats in ioreq_release() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 18:01, Stefano Stabellini wrote: > On Thu, 10 May 2012, Jan Beulich wrote: >> While for the "normal" case (called from blk_send_response_all()) >> decrementing requests_finished is correct, doing so in the parse error >> case is wrong; requests_inflight needs to be decremented instead. >> >> Signed-off-by: Jan Beulich >> >> --- a/hw/xen_disk.c >> +++ b/hw/xen_disk.c >> @@ -154,7 +154,7 @@ static void ioreq_finish(struct ioreq *i >> blkdev->requests_finished++; >> } >> >> -static void ioreq_release(struct ioreq *ioreq) >> +static void ioreq_release(struct ioreq *ioreq, bool finish) >> { >> struct XenBlkDev *blkdev = ioreq->blkdev; >> >> @@ -162,7 +162,10 @@ static void ioreq_release(struct ioreq * >> memset(ioreq, 0, sizeof(*ioreq)); >> ioreq->blkdev = blkdev; >> QLIST_INSERT_HEAD(&blkdev->freelist, ioreq, list); >> - blkdev->requests_finished--; >> + if (finish) >> + blkdev->requests_finished--; >> + else >> + blkdev->requests_inflight--; >> } >> >> /* >> @@ -449,7 +452,7 @@ static void blk_send_response_all(struct >> while (!QLIST_EMPTY(&blkdev->finished)) { >> ioreq = QLIST_FIRST(&blkdev->finished); >> send_notify += blk_send_response_one(ioreq); >> - ioreq_release(ioreq); >> + ioreq_release(ioreq, true); >> } >> if (send_notify) { >> xen_be_send_notify(&blkdev->xendev); >> @@ -505,7 +508,7 @@ static void blk_handle_requests(struct X >> if (blk_send_response_one(ioreq)) { >> xen_be_send_notify(&blkdev->xendev); >> } >> - ioreq_release(ioreq); >> + ioreq_release(ioreq, false); >> continue; >> } > > In case of an error returned by ioreq_parse requests_finished should > also be decremented. I don't think so - it gets incremented in ioreq_finish(), and that gets called only when I/O was at least attempted (which isn't the case when parse failed). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 07:41:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 07: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 ) id 1STpuC-0003Sm-N2; Mon, 14 May 2012 07:41:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STpuB-0003Sh-Fh for xen-devel@lists.xen.org; Mon, 14 May 2012 07:41:19 +0000 Received: from [193.109.254.147:14128] by server-2.bemta-14.messagelabs.com id 84/98-19409-E17B0BF4; Mon, 14 May 2012 07:41:18 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336981277!9120819!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7906 invoked from network); 14 May 2012 07:41:17 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2012 07:41:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 08:41:16 +0100 Message-Id: <4FB0D339020000780008354D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 08:41:13 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> <4FAD3C0802000078000830D8@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Olaf Hering , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 19:07, Stefano Stabellini wrote: > On Fri, 11 May 2012, Jan Beulich wrote: >> >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: >> > Legacy (non-pvops) gntdev drivers may require this to be done when the >> > number of grants intended to be used simultaneously exceeds a certain >> > driver specific default limit. >> > >> > Signed-off-by: Jan Beulich >> > >> > --- a/hw/xen_disk.c >> > +++ b/hw/xen_disk.c >> > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * >> > if (xen_mode != XEN_EMULATE) { >> > batch_maps = 1; >> > } >> > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, >> > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) >> >> In more extensive testing it appears that very rarely this value is still >> too low: >> >> xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) >> >> 342 + 11 = 353 > 352 = 32 * 11 >> >> Could someone help out here? I first thought this might be due to >> use_aio being non-zero, but ioreq_start() doesn't permit more than >> max_requests struct ioreqs-s to be around. > > Actually 342 + 11 = 353, that should be still OK because it is equal to > 32 * 11 + 1, where the additional 1 is for the ring, right? The +1 is for the ring, yes. And the calculation in the driver actually appears to be fine. It's rather an issue with fragmentation afaict - the driver needs to allocate 11 contiguous slots, and such may not be available. I'll send out a v2 of the patch soon, taking fragmentation into account. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 07:41:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 07: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 ) id 1STpuC-0003Sm-N2; Mon, 14 May 2012 07:41:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STpuB-0003Sh-Fh for xen-devel@lists.xen.org; Mon, 14 May 2012 07:41:19 +0000 Received: from [193.109.254.147:14128] by server-2.bemta-14.messagelabs.com id 84/98-19409-E17B0BF4; Mon, 14 May 2012 07:41:18 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1336981277!9120819!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7906 invoked from network); 14 May 2012 07:41:17 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2012 07:41:17 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 08:41:16 +0100 Message-Id: <4FB0D339020000780008354D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 08:41:13 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <4FACD9940200007800082F0D@nat28.tlf.novell.com> <4FAD3C0802000078000830D8@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Olaf Hering , "qemu-devel@nongnu.org" , xen-devel Subject: Re: [Xen-devel] [PATCH] qemu/xendisk: set maximum number of grants to be used X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 11.05.12 at 19:07, Stefano Stabellini wrote: > On Fri, 11 May 2012, Jan Beulich wrote: >> >>> On 11.05.12 at 09:19, "Jan Beulich" wrote: >> > Legacy (non-pvops) gntdev drivers may require this to be done when the >> > number of grants intended to be used simultaneously exceeds a certain >> > driver specific default limit. >> > >> > Signed-off-by: Jan Beulich >> > >> > --- a/hw/xen_disk.c >> > +++ b/hw/xen_disk.c >> > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * >> > if (xen_mode != XEN_EMULATE) { >> > batch_maps = 1; >> > } >> > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, >> > + max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) >> >> In more extensive testing it appears that very rarely this value is still >> too low: >> >> xen be: qdisk-768: can't map 11 grant refs (Cannot allocate memory, 342 maps) >> >> 342 + 11 = 353 > 352 = 32 * 11 >> >> Could someone help out here? I first thought this might be due to >> use_aio being non-zero, but ioreq_start() doesn't permit more than >> max_requests struct ioreqs-s to be around. > > Actually 342 + 11 = 353, that should be still OK because it is equal to > 32 * 11 + 1, where the additional 1 is for the ring, right? The +1 is for the ring, yes. And the calculation in the driver actually appears to be fine. It's rather an issue with fragmentation afaict - the driver needs to allocate 11 contiguous slots, and such may not be available. I'll send out a v2 of the patch soon, taking fragmentation into account. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:05:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08: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 ) id 1STqHY-0004Dd-F7; Mon, 14 May 2012 08:05:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqHW-0004DV-Mt for xen-devel@lists.xen.org; Mon, 14 May 2012 08:05:26 +0000 Received: from [85.158.143.99:53303] by server-2.bemta-4.messagelabs.com id 40/9D-17550-5CCB0BF4; Mon, 14 May 2012 08:05:25 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336982724!26955442!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 418 invoked from network); 14 May 2012 08:05: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; 14 May 2012 08:05:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 09:05:23 +0100 Message-Id: <4FB0D8DF0200007800083566@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 09:05:19 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Eddie Dong , "xen-devel\(xen-devel@lists.xen.org\)" , "Keir Fraser\(keir.xen@gmail.com\)" , Jun Nakajima , Xiantao Zhang Subject: Re: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 12.05.12 at 11:12, "Hao, Xudong" wrote: > Fix the mistake for debug exception(#DB; generated by INT1), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #DB should use hardware exception(except #DB generated by opcode 0xf1), #OF > should use software exception, which int n instruction should use software > interrupt. > > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 > @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and > + * INT0 use software exception, and INT n should use INTO ... > + * software interrupt. > + */ Neither comment nor description still say anything about what needs to be fixed going forward (namely the need to properly handle INT nn when nn < 0x20). > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); While the description correctly mentions the opcode 0xf1 case, the code makes no attempt at dealing with it. At least a comment would seem appropriate here, indicating the need for further adjustment. > @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ So you're adding one more of these incorrect length settings. This is particularly harmful here, as iirc some gcc versions generate 2-byte INT 4 instructions in certain overflow checking functions. As this needs to be taken care of here anyway, we should aim at fixing it for the other code paths too (as I just saw Eddie also suggests). Jan > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ > } > break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:05:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08: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 ) id 1STqHY-0004Dd-F7; Mon, 14 May 2012 08:05:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqHW-0004DV-Mt for xen-devel@lists.xen.org; Mon, 14 May 2012 08:05:26 +0000 Received: from [85.158.143.99:53303] by server-2.bemta-4.messagelabs.com id 40/9D-17550-5CCB0BF4; Mon, 14 May 2012 08:05:25 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1336982724!26955442!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2ODM=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 418 invoked from network); 14 May 2012 08:05: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; 14 May 2012 08:05:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 14 May 2012 09:05:23 +0100 Message-Id: <4FB0D8DF0200007800083566@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 14 May 2012 09:05:19 +0100 From: "Jan Beulich" To: "Xudong Hao" References: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FDC2D41@SHSMSX102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Aravindh Puthiyaparambil , Eddie Dong , "xen-devel\(xen-devel@lists.xen.org\)" , "Keir Fraser\(keir.xen@gmail.com\)" , Jun Nakajima , Xiantao Zhang Subject: Re: [Xen-devel] [PATCH v2] Fix the mistake for #DB and #OF exception X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 12.05.12 at 11:12, "Hao, Xudong" wrote: > Fix the mistake for debug exception(#DB; generated by INT1), overflow > exception(#OF; generated by INTO) and int n instruction emulation. > > #DB should use hardware exception(except #DB generated by opcode 0xf1), #OF > should use software exception, which int n instruction should use software > interrupt. > > Signed-off-by: Eddie Dong > Signed-off-by: Xudong Hao > > diff -r cd4dd23a831d xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri May 11 18:59:07 2012 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Mon May 13 01:01:24 2013 +0800 > @@ -1350,6 +1350,14 @@ static void __vmx_inject_exception(int t > curr->arch.hvm_vmx.vmx_emulate = 1; > } > > +/* > + * Generate the virtual event to guest. > + * NOTE: > + * This is for processor execution generated exceptions, > + * and INT 3(CC), INTO (CE) instruction emulation. INT3 and > + * INT0 use software exception, and INT n should use INTO ... > + * software interrupt. > + */ Neither comment nor description still say anything about what needs to be fixed going forward (namely the need to properly handle INT nn when nn < 0x20). > void vmx_inject_hw_exception(int trap, int error_code) > { > unsigned long intr_info; > @@ -1365,7 +1373,6 @@ void vmx_inject_hw_exception(int trap, i > switch ( trap ) > { > case TRAP_debug: > - type = X86_EVENTTYPE_SW_EXCEPTION; > if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) > { > __restore_debug_registers(curr); While the description correctly mentions the opcode 0xf1 case, the code makes no attempt at dealing with it. At least a comment would seem appropriate here, indicating the need for further adjustment. > @@ -1387,10 +1394,15 @@ void vmx_inject_hw_exception(int trap, i > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ > break; > > + case TRAP_overflow: > + type = X86_EVENTTYPE_SW_EXCEPTION; > + __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* into */ So you're adding one more of these incorrect length settings. This is particularly harmful here, as iirc some gcc versions generate 2-byte INT 4 instructions in certain overflow checking functions. As this needs to be taken care of here anyway, we should aim at fixing it for the other code paths too (as I just saw Eddie also suggests). Jan > + break; > + > default: > if ( trap > TRAP_last_reserved ) > { > - type = X86_EVENTTYPE_SW_EXCEPTION; > + type = X86_EVENTTYPE_SW_INTERRUPT; > __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */ > } > break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:15:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:15:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqQg-0004av-Ia; Mon, 14 May 2012 08:14:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqQf-0004aq-Ik for xen-devel@lists.xen.org; Mon, 14 May 2012 08:14:53 +0000 Received: from [193.109.254.147:5060] by server-9.bemta-14.messagelabs.com id C1/C2-05787-CFEB0BF4; Mon, 14 May 2012 08:14:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336983292!9163939!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18399 invoked from network); 14 May 2012 08:14:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 08:14:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450309" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:14: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, 14 May 2012 09:14:51 +0100 Message-ID: <1336983290.31817.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 09:14:50 +0100 In-Reply-To: <1336898139.2612.1.camel@Abyss> References: <20943633a63e0691272b.1336778417@Solace> <1336778609.27081.1.camel@Abyss> <1336898139.2612.1.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 2012-05-13 at 09:35 +0100, Dario Faggioli wrote: > On Sat, 2012-05-12 at 01:23 +0200, Dario Faggioli wrote: > > On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote: > > > xm supports the following syntax (in the config file) for > > > specific VCPU to PCPU mapping: > > > > > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > > > > > Allow for the same to be done in xl. > > > > > And yes, I'm proposing this for 4.2, as not having it is a feature > > parity between xm and xl bug someone reported on @xen-users. > > > Damn! I forgot to update the doc (xl manual) accordingly! That was going to be my first comment ;-) It would also be useful if the commit message mentions the impact on the existing syntax -- I'm not sure if this is changing the behaviour of an existing xl syntax or adding a whole new one (maybe the docs will answer that). Ian. > Feel free to provide any comments but, please, wait for a new and > complete version before applying. > > Thanks and Regards, > Dario > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:15:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:15:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqQg-0004av-Ia; Mon, 14 May 2012 08:14:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqQf-0004aq-Ik for xen-devel@lists.xen.org; Mon, 14 May 2012 08:14:53 +0000 Received: from [193.109.254.147:5060] by server-9.bemta-14.messagelabs.com id C1/C2-05787-CFEB0BF4; Mon, 14 May 2012 08:14:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1336983292!9163939!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18399 invoked from network); 14 May 2012 08:14:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 08:14:52 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450309" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:14: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, 14 May 2012 09:14:51 +0100 Message-ID: <1336983290.31817.4.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 09:14:50 +0100 In-Reply-To: <1336898139.2612.1.camel@Abyss> References: <20943633a63e0691272b.1336778417@Solace> <1336778609.27081.1.camel@Abyss> <1336898139.2612.1.camel@Abyss> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, 2012-05-13 at 09:35 +0100, Dario Faggioli wrote: > On Sat, 2012-05-12 at 01:23 +0200, Dario Faggioli wrote: > > On Sat, 2012-05-12 at 01:20 +0200, Dario Faggioli wrote: > > > xm supports the following syntax (in the config file) for > > > specific VCPU to PCPU mapping: > > > > > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > > > > > Allow for the same to be done in xl. > > > > > And yes, I'm proposing this for 4.2, as not having it is a feature > > parity between xm and xl bug someone reported on @xen-users. > > > Damn! I forgot to update the doc (xl manual) accordingly! That was going to be my first comment ;-) It would also be useful if the commit message mentions the impact on the existing syntax -- I'm not sure if this is changing the behaviour of an existing xl syntax or adding a whole new one (maybe the docs will answer that). Ian. > Feel free to provide any comments but, please, wait for a new and > complete version before applying. > > Thanks and Regards, > Dario > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:19:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:19:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqUx-0004ll-9d; Mon, 14 May 2012 08:19:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqUv-0004lb-Bl for xen-devel@lists.xen.org; Mon, 14 May 2012 08:19:17 +0000 Received: from [193.109.254.147:5752] by server-7.bemta-14.messagelabs.com id 75/62-01627-400C0BF4; Mon, 14 May 2012 08:19:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336983555!6672827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3159 invoked from network); 14 May 2012 08:19: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 May 2012 08:19:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450426" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:19:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 09:19:15 +0100 Message-ID: <1336983554.31817.8.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 09:19:14 +0100 In-Reply-To: <20943633a63e0691272b.1336778417@Solace> References: <20943633a63e0691272b.1336778417@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-12 at 00:20 +0100, Dario Faggioli wrote: > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > Allow for the same to be done in xl. > > Signed-off-by: Dario Faggioli > > 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 > @@ -71,6 +71,8 @@ static uint32_t domid; > static const char *common_domname; > static int fd_lock = -1; > > +/* Stash for specific vcpu to pcpu mappping */ > +static int *vcpu_to_pcpu; > > static const char savefileheader_magic[32]= > "Xen saved domain, xl format\n \0 \r"; > @@ -630,6 +632,21 @@ static void parse_config_data(const char > exit(1); > } > > + /* Prepare the array for single vcpu to pcpu mappings */ > + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); > + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); > + > + /* > + * Idea here is to let libxl think all the domain's vcpus > + * have cpu affinity with all the pcpus on the list. > + * It is then us, here in xl, that matches each single vcpu > + * to its pcpu (and that's why we need to stash such info in > + * the vcpu_to_pcpu array now) after the domain has been created. > + * Doing it like this saves the burden of passing to libxl > + * some big array hosting the single mappings. Also, using > + * the cpumap derived from the list ensures memory is being > + * allocated on the proper nodes anyway. So effectively we create the domain pinned to the right nodes and then rebind all the CPUS later to be mapped to specific phys-processors? This means that the memory which is allocated is from the correct nodes, even though we appear to do the pinning later. Clever. > + */ > libxl_cpumap_set_none(&b_info->cpumap); > while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { > i = atoi(buf); > @@ -638,6 +655,8 @@ static void parse_config_data(const char > exit(1); > } > libxl_cpumap_set(&b_info->cpumap, i); > + if (n_cpus < b_info->max_vcpus) > + vcpu_to_pcpu[n_cpus] = i; > n_cpus++; > } > } > @@ -1709,6 +1728,31 @@ start: > if ( ret ) > goto error_out; > > + /* If single vcpu to pcpu mapping was requested, honour it */ > + if (vcpu_to_pcpu) { This is always allocated above, isn't it? I'm concerned that this might break the non-1-1 case. > + libxl_cpumap vcpu_cpumap; > + > + libxl_cpumap_alloc(ctx, &vcpu_cpumap); > + for (i = 0; i < d_config.b_info.max_vcpus; i++) { > + > + if (vcpu_to_pcpu[i] != -1) { > + libxl_cpumap_set_none(&vcpu_cpumap); > + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); > + } else { > + libxl_cpumap_set_any(&vcpu_cpumap); > + } > + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { > + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + ret = ERROR_FAIL; > + goto error_out; > + } > + } > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); vpuc_to_pcpu = NULL, in case you go back around again... For that reason it might be preferable to put vcpu_to_pcpu struct dom_info and pass that to parse_config -- I think Goncalo is doing something similar for the vncviewer option. > + } > + > ret = libxl_userdata_store(ctx, domid, "xl", > config_data, config_len); > if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:19:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:19:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqUx-0004ll-9d; Mon, 14 May 2012 08:19:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqUv-0004lb-Bl for xen-devel@lists.xen.org; Mon, 14 May 2012 08:19:17 +0000 Received: from [193.109.254.147:5752] by server-7.bemta-14.messagelabs.com id 75/62-01627-400C0BF4; Mon, 14 May 2012 08:19:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1336983555!6672827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3159 invoked from network); 14 May 2012 08:19: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 May 2012 08:19:15 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450426" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:19:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 09:19:15 +0100 Message-ID: <1336983554.31817.8.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 09:19:14 +0100 In-Reply-To: <20943633a63e0691272b.1336778417@Solace> References: <20943633a63e0691272b.1336778417@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, 2012-05-12 at 00:20 +0100, Dario Faggioli wrote: > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > Allow for the same to be done in xl. > > Signed-off-by: Dario Faggioli > > 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 > @@ -71,6 +71,8 @@ static uint32_t domid; > static const char *common_domname; > static int fd_lock = -1; > > +/* Stash for specific vcpu to pcpu mappping */ > +static int *vcpu_to_pcpu; > > static const char savefileheader_magic[32]= > "Xen saved domain, xl format\n \0 \r"; > @@ -630,6 +632,21 @@ static void parse_config_data(const char > exit(1); > } > > + /* Prepare the array for single vcpu to pcpu mappings */ > + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); > + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); > + > + /* > + * Idea here is to let libxl think all the domain's vcpus > + * have cpu affinity with all the pcpus on the list. > + * It is then us, here in xl, that matches each single vcpu > + * to its pcpu (and that's why we need to stash such info in > + * the vcpu_to_pcpu array now) after the domain has been created. > + * Doing it like this saves the burden of passing to libxl > + * some big array hosting the single mappings. Also, using > + * the cpumap derived from the list ensures memory is being > + * allocated on the proper nodes anyway. So effectively we create the domain pinned to the right nodes and then rebind all the CPUS later to be mapped to specific phys-processors? This means that the memory which is allocated is from the correct nodes, even though we appear to do the pinning later. Clever. > + */ > libxl_cpumap_set_none(&b_info->cpumap); > while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { > i = atoi(buf); > @@ -638,6 +655,8 @@ static void parse_config_data(const char > exit(1); > } > libxl_cpumap_set(&b_info->cpumap, i); > + if (n_cpus < b_info->max_vcpus) > + vcpu_to_pcpu[n_cpus] = i; > n_cpus++; > } > } > @@ -1709,6 +1728,31 @@ start: > if ( ret ) > goto error_out; > > + /* If single vcpu to pcpu mapping was requested, honour it */ > + if (vcpu_to_pcpu) { This is always allocated above, isn't it? I'm concerned that this might break the non-1-1 case. > + libxl_cpumap vcpu_cpumap; > + > + libxl_cpumap_alloc(ctx, &vcpu_cpumap); > + for (i = 0; i < d_config.b_info.max_vcpus; i++) { > + > + if (vcpu_to_pcpu[i] != -1) { > + libxl_cpumap_set_none(&vcpu_cpumap); > + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); > + } else { > + libxl_cpumap_set_any(&vcpu_cpumap); > + } > + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { > + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + ret = ERROR_FAIL; > + goto error_out; > + } > + } > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); vpuc_to_pcpu = NULL, in case you go back around again... For that reason it might be preferable to put vcpu_to_pcpu struct dom_info and pass that to parse_config -- I think Goncalo is doing something similar for the vncviewer option. > + } > + > ret = libxl_userdata_store(ctx, domid, "xl", > config_data, config_len); > if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:35:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08: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 ) id 1STqk0-0005bT-Ii; Mon, 14 May 2012 08:34:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqjy-0005bG-OD for xen-devel@lists.xensource.com; Mon, 14 May 2012 08:34:51 +0000 Received: from [85.158.139.83:13884] by server-9.bemta-5.messagelabs.com id 75/58-09826-8A3C0BF4; Mon, 14 May 2012 08:34:48 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336984487!27549131!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9394 invoked from network); 14 May 2012 08:34:47 -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; 14 May 2012 08:34:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450859" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:34: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, 14 May 2012 09:34:46 +0100 Message-ID: <1336984485.31817.17.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Mon, 14 May 2012 09:34:45 +0100 In-Reply-To: <1336801640.3891.17.camel@dagon.hellion.org.uk> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> <20397.18234.50742.594420@mariner.uk.xensource.com> <1336801640.3891.17.camel@dagon.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: multipart/mixed; boundary="=-JAQUWIbHp0H2oacY4bGT" X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --=-JAQUWIbHp0H2oacY4bGT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Sat, 2012-05-12 at 06:47 +0100, Ian Campbell wrote: > > You've been shovelling stuff in all day ;-) I'll refresh/resend on > Monday. It applied for me this morning so I suspect you hadn't noticed this: > You did take note of the "git-ness" of the patch though? -- ISTR your > tools had trouble with this format last time. Here it is a gain in non-git format and with the header guards removed from the compat headers as requested. I stuck with the compat subdir. qemu-xs-compat.patch is again attached. 8<-------------------------------- # HG changeset patch # User Ian Campbell # Date 1336984299 -3600 # Node ID e71b19157a4788d8a56bb578f9ddc01cb92c331f # Parent 54fcdee8740f86c9d3ca4f8bf5b780d292cd11f7 xenstore: rename public xenstore headers The xenstore header xs.h is producing conflicts with other software[1]. xs is a too short identifier and does not matche the library. Renaming the headers to xenstore.h and xenstore_lib.h is the easiest way to make them easy recognizable and prevent furthe problems. [1]: http://bugs.debian.org/668550 Signed-off-by: Bastian Blank Signed-off-by: Ian Campbell diff -r 54fcdee8740f -r e71b19157a47 Makefile --- a/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/Makefile Mon May 14 09:31:39 2012 +0100 @@ -241,6 +241,8 @@ uninstall: rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore-compat/xs_lib.h $(D)$(INCLUDEDIR)/xensotre-compat/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h rm -rf $(D)$(INCLUDEDIR)/xen rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl* rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h diff -r 54fcdee8740f -r e71b19157a47 extras/mini-os/lib/sys.c --- a/extras/mini-os/lib/sys.c Mon May 14 09:11:00 2012 +0100 +++ b/extras/mini-os/lib/sys.c Mon May 14 09:31:39 2012 +0100 @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 extras/mini-os/lib/xs.c --- a/extras/mini-os/lib/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/extras/mini-os/lib/xs.c Mon May 14 09:31:39 2012 +0100 @@ -9,7 +9,7 @@ #ifdef HAVE_LIBC #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/Makefile --- a/tools/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/tools/Makefile Mon May 14 09:31:39 2012 +0100 @@ -150,7 +150,8 @@ subdir-all-qemu-xen-dir subdir-install-q --source-path=$$source \ --extra-cflags="-I$(XEN_ROOT)/tools/include \ -I$(XEN_ROOT)/tools/libxc \ - -I$(XEN_ROOT)/tools/xenstore" \ + -I$(XEN_ROOT)/tools/xenstore \ + -I$(XEN_ROOT)/tools/xenstore/compat" \ --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ -L$(XEN_ROOT)/tools/xenstore" \ --bindir=$(LIBEXEC) \ diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/drivers/blktapctrl.c --- a/tools/blktap/drivers/blktapctrl.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/drivers/blktapctrl.c Mon May 14 09:31:39 2012 +0100 @@ -47,7 +47,7 @@ #include #include #include -#include +#include #include #include #ifdef MEMSHR diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/blktaplib.h --- a/tools/blktap/lib/blktaplib.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/blktaplib.h Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/xenbus.c --- a/tools/blktap/lib/xenbus.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/xenbus.c Mon May 14 09:31:39 2012 +0100 @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/xs_api.c --- a/tools/blktap/lib/xs_api.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/xs_api.c Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/console/client/main.c --- a/tools/console/client/main.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/client/main.c Mon May 14 09:31:39 2012 +0100 @@ -39,7 +39,7 @@ #include #endif -#include "xs.h" +#include #include "xenctrl.h" #define ESCAPE_CHARACTER 0x1d diff -r 54fcdee8740f -r e71b19157a47 tools/console/daemon/io.c --- a/tools/console/daemon/io.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/daemon/io.c Mon May 14 09:31:39 2012 +0100 @@ -22,7 +22,7 @@ #include "utils.h" #include "io.h" -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/console/daemon/utils.h --- a/tools/console/daemon/utils.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/daemon/utils.h Mon May 14 09:31:39 2012 +0100 @@ -26,7 +26,7 @@ #include #include -#include "xs.h" +#include void daemonize(const char *pidfile); bool xen_setup(void); diff -r 54fcdee8740f -r e71b19157a47 tools/libvchan/init.c --- a/tools/libvchan/init.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/libvchan/init.c Mon May 14 09:31:39 2012 +0100 @@ -40,7 +40,7 @@ #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/libxl/libxl_internal.h Mon May 14 09:31:39 2012 +0100 @@ -44,7 +44,7 @@ #include #include -#include +#include #include #include "xentoollog.h" diff -r 54fcdee8740f -r e71b19157a47 tools/misc/xen-lowmemd.c --- a/tools/misc/xen-lowmemd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/misc/xen-lowmemd.c Mon May 14 09:31:39 2012 +0100 @@ -5,7 +5,7 @@ #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/checkpoint.c --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c Mon May 14 09:31:39 2012 +0100 @@ -2,7 +2,7 @@ #include -#include +#include #include #include "checkpoint.h" diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/checkpoint.h --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h Mon May 14 09:31:39 2012 +0100 @@ -8,7 +8,7 @@ #include #include -#include +#include typedef enum { dt_unknown, diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Mon May 14 09:31:39 2012 +0100 @@ -11,7 +11,7 @@ #include #include -#include +#include #include "checkpoint.h" diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/xs/xs.c --- a/tools/python/xen/lowlevel/xs/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/xs/xs.c Mon May 14 09:31:39 2012 +0100 @@ -30,7 +30,7 @@ #include #include -#include "xs.h" +#include /** @file * Python interface to the Xen Store Daemon (xs). diff -r 54fcdee8740f -r e71b19157a47 tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/tests/mce-test/tools/xen-mceinj.c Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #define MCi_type_CTL 0x0 #define MCi_type_STATUS 0x1 diff -r 54fcdee8740f -r e71b19157a47 tools/xcutils/xc_save.c --- a/tools/xcutils/xc_save.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xcutils/xc_save.c Mon May 14 09:31:39 2012 +0100 @@ -19,7 +19,7 @@ #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenbackendd/xenbackendd.c Mon May 14 09:31:39 2012 +0100 @@ -28,7 +28,7 @@ #include #include -#include +#include #define DEVTYPE_UNKNOWN 0 #define DEVTYPE_VIF 1 diff -r 54fcdee8740f -r e71b19157a47 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenpaging/xenpaging.c Mon May 14 09:31:39 2012 +0100 @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include #include "xc_bitops.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenpmd/xenpmd.c --- a/tools/xenpmd/xenpmd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenpmd/xenpmd.c Mon May 14 09:31:39 2012 +0100 @@ -40,7 +40,7 @@ #include #include #include -#include +#include /* #define RUN_STANDALONE */ #define RUN_IN_SIMULATE_MODE diff -r 54fcdee8740f -r e71b19157a47 tools/xenstat/libxenstat/src/xenstat_priv.h --- a/tools/xenstat/libxenstat/src/xenstat_priv.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstat/libxenstat/src/xenstat_priv.h Mon May 14 09:31:39 2012 +0100 @@ -24,7 +24,7 @@ #define XENSTAT_PRIV_H #include -#include +#include #include "xenstat.h" #include "xenctrl.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/COPYING --- a/tools/xenstore/COPYING Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/COPYING Mon May 14 09:31:39 2012 +0100 @@ -1,6 +1,6 @@ This license (LGPL) applies to the xenstore library which interfaces -with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and -xs_lib.h). The remaining files in the directory are licensed as +with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and +xenstore_lib.h). The remaining files in the directory are licensed as stated in the comments (as of this writing, GPL, see ../../COPYING). diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/Makefile --- a/tools/xenstore/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/Makefile Mon May 14 09:31:39 2012 +0100 @@ -109,6 +109,7 @@ install: all $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xenstore-compat $(INSTALL_DIR) $(DESTDIR)/var/run/xenstored $(INSTALL_DIR) $(DESTDIR)/var/lib/xenstored $(INSTALL_PROG) xenstored $(DESTDIR)$(SBINDIR) @@ -122,8 +123,12 @@ install: all ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR) ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so $(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR) - $(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs.h + $(INSTALL_DATA) compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs_lib.h + ln -sf xenstore-compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xs.h + ln -sf xenstore-compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xs_lib.h -include $(DEPS) diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/compat/xs.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/compat/xs.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,2 @@ +#warning xs.h is deprecated use xenstore.h instead +#include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/compat/xs_lib.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/compat/xs_lib.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,2 @@ +#warning xs_lib.h is deprecated use xenstore_lib.h instead +#include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/init-xenstore-domain.c --- a/tools/xenstore/init-xenstore-domain.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/init-xenstore-domain.c Mon May 14 09:31:39 2012 +0100 @@ -7,7 +7,7 @@ #include #include #include -#include +#include #include static uint32_t domid = -1; diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/xenstore.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,236 @@ +/* + Xen Store Daemon providing simple tree-like database. + Copyright (C) 2005 Rusty Russell IBM Corporation + + 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 St, Fifth Floor, Boston, MA 02110-1301 USA +*/ + +#ifndef XENSTORE_H +#define XENSTORE_H + +#include + +#define XBT_NULL 0 + +#define XS_OPEN_READONLY 1UL<<0 +#define XS_OPEN_SOCKETONLY 1UL<<1 + +struct xs_handle; +typedef uint32_t xs_transaction_t; + +/* IMPORTANT: For details on xenstore protocol limits, see + * docs/misc/xenstore.txt in the Xen public source repository, and use the + * XENSTORE_*_MAX limit macros defined in xen/io/xs_wire.h. + */ + +/* On failure, these routines set errno. */ + +/* Open a connection to the xs daemon. + * Attempts to make a connection over the socket interface, + * and if it fails, then over the xenbus interface. + * Mode 0 specifies read-write access, XS_OPEN_READONLY for + * read-only access. + * Returns a handle or NULL. + */ +struct xs_handle *xs_open(unsigned long flags); + +/* Close the connection to the xs daemon. */ +void xs_close(struct xs_handle *xsh); + +/* Connect to the xs daemon. + * Returns a handle or NULL. + * Deprecated, please use xs_open(0) instead + */ +struct xs_handle *xs_daemon_open(void); +struct xs_handle *xs_domain_open(void); + +/* Connect to the xs daemon (readonly for non-root clients). + * Returns a handle or NULL. + * Deprecated, please use xs_open(XS_OPEN_READONLY) instead + */ +struct xs_handle *xs_daemon_open_readonly(void); + +/* Close the connection to the xs daemon. + * Deprecated, please use xs_close() instead + */ +void xs_daemon_close(struct xs_handle *); + +/* Throw away the connection to the xs daemon, for use after fork(). */ +void xs_daemon_destroy_postfork(struct xs_handle *); + +/* Get contents of a directory. + * Returns a malloced array: call free() on it after use. + * Num indicates size. + */ +char **xs_directory(struct xs_handle *h, xs_transaction_t t, + const char *path, unsigned int *num); + +/* Get the value of a single file, nul terminated. + * Returns a malloced value: call free() on it after use. + * len indicates length in bytes, not including terminator. + */ +void *xs_read(struct xs_handle *h, xs_transaction_t t, + const char *path, unsigned int *len); + +/* Write the value of a single file. + * Returns false on failure. + */ +bool xs_write(struct xs_handle *h, xs_transaction_t t, + const char *path, const void *data, unsigned int len); + +/* Create a new directory. + * Returns false on failure, or success if it already exists. + */ +bool xs_mkdir(struct xs_handle *h, xs_transaction_t t, + const char *path); + +/* Destroy a file or directory (and children). + * Returns false on failure, or if it doesn't exist. + */ +bool xs_rm(struct xs_handle *h, xs_transaction_t t, + const char *path); + +/* Restrict a xenstore handle so that it acts as if it had the + * permissions of domain @domid. The handle must currently be + * using domain 0's credentials. + * + * Returns false on failure, in which case the handle continues + * to use the old credentials, or true on success. + */ +bool xs_restrict(struct xs_handle *h, unsigned domid); + +/* Get permissions of node (first element is owner, first perms is "other"). + * Returns malloced array, or NULL: call free() after use. + */ +struct xs_permissions *xs_get_permissions(struct xs_handle *h, + xs_transaction_t t, + const char *path, unsigned int *num); + +/* Set permissions of node (must be owner). + * Returns false on failure. + */ +bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, + const char *path, struct xs_permissions *perms, + unsigned int num_perms); + +/* Watch a node for changes (poll on fd to detect, or call read_watch()). + * When the node (or any child) changes, fd will become readable. + * Token is returned when watch is read, to allow matching. + * Returns false on failure. + */ +bool xs_watch(struct xs_handle *h, const char *path, const char *token); + +/* Return the FD to poll on to see if a watch has fired. */ +int xs_fileno(struct xs_handle *h); + +/* Check for node changes. On success, returns a non-NULL pointer ret + * such that ret[0] and ret[1] are valid C strings, namely the + * triggering path (see docs/misc/xenstore.txt) and the token (from + * xs_watch). On error return value is NULL setting errno. + * + * Callers should, after xs_fileno has become readable, repeatedly + * call xs_check_watch until it returns NULL and sets errno to EAGAIN. + * (If the fd became readable, xs_check_watch is allowed to make it no + * longer show up as readable even if future calls to xs_check_watch + * will return more watch events.) + * + * After the caller is finished with the returned information it + * should be freed all in one go with free(ret). + */ +char **xs_check_watch(struct xs_handle *h); + +/* Find out what node change was on (will block if nothing pending). + * Returns array containing the path and token. Use XS_WATCH_* to access these + * elements. Call free() after use. + */ +char **xs_read_watch(struct xs_handle *h, unsigned int *num); + +/* Remove a watch on a node: implicitly acks any outstanding watch. + * Returns false on failure (no watch on that node). + */ +bool xs_unwatch(struct xs_handle *h, const char *path, const char *token); + +/* Start a transaction: changes by others will not be seen during this + * transaction, and changes will not be visible to others until end. + * Returns NULL on failure. + */ +xs_transaction_t xs_transaction_start(struct xs_handle *h); + +/* End a transaction. + * If abandon is true, transaction is discarded instead of committed. + * Returns false on failure: if errno == EAGAIN, you have to restart + * transaction. + */ +bool xs_transaction_end(struct xs_handle *h, xs_transaction_t t, + bool abort); + +/* Introduce a new domain. + * This tells the store daemon about a shared memory page, event channel and + * store path associated with a domain: the domain uses these to communicate. + */ +bool xs_introduce_domain(struct xs_handle *h, + unsigned int domid, + unsigned long mfn, + unsigned int eventchn); + +/* Set the target of a domain + * This tells the store daemon that a domain is targetting another one, so + * it should let it tinker with it. + */ +bool xs_set_target(struct xs_handle *h, + unsigned int domid, + unsigned int target); + +/* Resume a domain. + * Clear the shutdown flag for this domain in the store. + */ +bool xs_resume_domain(struct xs_handle *h, unsigned int domid); + +/* Release a domain. + * Tells the store domain to release the memory page to the domain. + */ +bool xs_release_domain(struct xs_handle *h, unsigned int domid); + +/* Query the home path of a domain. Call free() after use. + */ +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); + +/* Only useful for DEBUG versions */ +char *xs_debug_command(struct xs_handle *h, const char *cmd, + void *data, unsigned int len); + +int xs_suspend_evtchn_port(int domid); +#endif /* XENSTORE_H */ + +/* + * Local variables: + * c-file-style: "linux" + * indent-tabs-mode: t + * c-indent-level: 8 + * c-basic-offset: 8 + * tab-width: 8 + * End: + */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_client.c --- a/tools/xenstore/xenstore_client.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstore_client.c Mon May 14 09:31:39 2012 +0100 @@ -18,7 +18,7 @@ #include #include #include -#include +#include #include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_control.c --- a/tools/xenstore/xenstore_control.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstore_control.c Mon May 14 09:31:39 2012 +0100 @@ -2,7 +2,7 @@ #include #include -#include "xs.h" +#include "xenstore.h" int main(int argc, char **argv) diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_lib.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/xenstore_lib.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,85 @@ +/* + Common routines between Xen store user library and daemon. + Copyright (C) 2005 Rusty Russell IBM Corporation + + 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 St, Fifth Floor, Boston, MA 02110-1301 USA +*/ + +#ifndef XENSTORE_LIB_H +#define XENSTORE_LIB_H + +#include +#include +#include +#include +#include + +/* Bitmask of permissions. */ +enum xs_perm_type { + XS_PERM_NONE = 0, + XS_PERM_READ = 1, + XS_PERM_WRITE = 2, + /* Internal use. */ + XS_PERM_ENOENT_OK = 4, + XS_PERM_OWNER = 8, +}; + +struct xs_permissions +{ + unsigned int id; + enum xs_perm_type perms; +}; + +/* Each 10 bits takes ~ 3 digits, plus one, plus one for nul terminator. */ +#define MAX_STRLEN(x) ((sizeof(x) * CHAR_BIT + CHAR_BIT-1) / 10 * 3 + 2) + +/* Path for various daemon things: env vars can override. */ +const char *xs_daemon_rootdir(void); +const char *xs_daemon_rundir(void); +const char *xs_daemon_socket(void); +const char *xs_daemon_socket_ro(void); +const char *xs_domain_dev(void); +const char *xs_daemon_tdb(void); + +/* Simple write function: loops for you. */ +bool xs_write_all(int fd, const void *data, unsigned int len); + +/* Convert strings to permissions. False if a problem. */ +bool xs_strings_to_perms(struct xs_permissions *perms, unsigned int num, + const char *strings); + +/* Convert permissions to a string (up to len MAX_STRLEN(unsigned int)+1). */ +bool xs_perm_to_string(const struct xs_permissions *perm, + char *buffer, size_t buf_len); + +/* Given a string and a length, count how many strings (nul terms). */ +unsigned int xs_count_strings(const char *strings, unsigned int len); + +/* Sanitising (quoting) possibly-binary strings. */ +struct expanding_buffer { + char *buf; + int avail; +}; + +/* Ensure that given expanding buffer has at least min_avail characters. */ +char *expanding_buffer_ensure(struct expanding_buffer *, int min_avail); + +/* sanitise_value() may return NULL if malloc fails. */ +char *sanitise_value(struct expanding_buffer *, const char *val, unsigned len); + +/* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ +void unsanitise_value(char *out, unsigned *out_len_r, const char *in); + +#endif /* XENSTORE_LIB_H */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_core.c --- a/tools/xenstore/xenstored_core.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_core.c Mon May 14 09:31:39 2012 +0100 @@ -44,7 +44,7 @@ #include "utils.h" #include "list.h" #include "talloc.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "xenstored_core.h" #include "xenstored_watch.h" #include "xenstored_transaction.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_core.h --- a/tools/xenstore/xenstored_core.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_core.h Mon May 14 09:31:39 2012 +0100 @@ -27,7 +27,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "list.h" #include "tdb.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_transaction.c --- a/tools/xenstore/xenstored_transaction.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_transaction.c Mon May 14 09:31:39 2012 +0100 @@ -33,7 +33,7 @@ #include "xenstored_transaction.h" #include "xenstored_watch.h" #include "xenstored_domain.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" struct changed_node diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_watch.c --- a/tools/xenstore/xenstored_watch.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_watch.c Mon May 14 09:31:39 2012 +0100 @@ -27,7 +27,7 @@ #include "talloc.h" #include "list.h" #include "xenstored_watch.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" #include "xenstored_domain.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs.c --- a/tools/xenstore/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs.c Mon May 14 09:31:39 2012 +0100 @@ -32,7 +32,7 @@ #include #include #include -#include "xs.h" +#include "xenstore.h" #include "list.h" #include "utils.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs.h --- a/tools/xenstore/xs.h Mon May 14 09:11:00 2012 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,236 +0,0 @@ -/* - Xen Store Daemon providing simple tree-like database. - Copyright (C) 2005 Rusty Russell IBM Corporation - - 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 St, Fifth Floor, Boston, MA 02110-1301 USA -*/ - -#ifndef _XS_H -#define _XS_H - -#include - -#define XBT_NULL 0 - -#define XS_OPEN_READONLY 1UL<<0 -#define XS_OPEN_SOCKETONLY 1UL<<1 - -struct xs_handle; -typedef uint32_t xs_transaction_t; - -/* IMPORTANT: For details on xenstore protocol limits, see - * docs/misc/xenstore.txt in the Xen public source repository, and use the - * XENSTORE_*_MAX limit macros defined in xen/io/xs_wire.h. - */ - -/* On failure, these routines set errno. */ - -/* Open a connection to the xs daemon. - * Attempts to make a connection over the socket interface, - * and if it fails, then over the xenbus interface. - * Mode 0 specifies read-write access, XS_OPEN_READONLY for - * read-only access. - * Returns a handle or NULL. - */ -struct xs_handle *xs_open(unsigned long flags); - -/* Close the connection to the xs daemon. */ -void xs_close(struct xs_handle *xsh); - -/* Connect to the xs daemon. - * Returns a handle or NULL. - * Deprecated, please use xs_open(0) instead - */ -struct xs_handle *xs_daemon_open(void); -struct xs_handle *xs_domain_open(void); - -/* Connect to the xs daemon (readonly for non-root clients). - * Returns a handle or NULL. - * Deprecated, please use xs_open(XS_OPEN_READONLY) instead - */ -struct xs_handle *xs_daemon_open_readonly(void); - -/* Close the connection to the xs daemon. - * Deprecated, please use xs_close() instead - */ -void xs_daemon_close(struct xs_handle *); - -/* Throw away the connection to the xs daemon, for use after fork(). */ -void xs_daemon_destroy_postfork(struct xs_handle *); - -/* Get contents of a directory. - * Returns a malloced array: call free() on it after use. - * Num indicates size. - */ -char **xs_directory(struct xs_handle *h, xs_transaction_t t, - const char *path, unsigned int *num); - -/* Get the value of a single file, nul terminated. - * Returns a malloced value: call free() on it after use. - * len indicates length in bytes, not including terminator. - */ -void *xs_read(struct xs_handle *h, xs_transaction_t t, - const char *path, unsigned int *len); - -/* Write the value of a single file. - * Returns false on failure. - */ -bool xs_write(struct xs_handle *h, xs_transaction_t t, - const char *path, const void *data, unsigned int len); - -/* Create a new directory. - * Returns false on failure, or success if it already exists. - */ -bool xs_mkdir(struct xs_handle *h, xs_transaction_t t, - const char *path); - -/* Destroy a file or directory (and children). - * Returns false on failure, or if it doesn't exist. - */ -bool xs_rm(struct xs_handle *h, xs_transaction_t t, - const char *path); - -/* Restrict a xenstore handle so that it acts as if it had the - * permissions of domain @domid. The handle must currently be - * using domain 0's credentials. - * - * Returns false on failure, in which case the handle continues - * to use the old credentials, or true on success. - */ -bool xs_restrict(struct xs_handle *h, unsigned domid); - -/* Get permissions of node (first element is owner, first perms is "other"). - * Returns malloced array, or NULL: call free() after use. - */ -struct xs_permissions *xs_get_permissions(struct xs_handle *h, - xs_transaction_t t, - const char *path, unsigned int *num); - -/* Set permissions of node (must be owner). - * Returns false on failure. - */ -bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, - const char *path, struct xs_permissions *perms, - unsigned int num_perms); - -/* Watch a node for changes (poll on fd to detect, or call read_watch()). - * When the node (or any child) changes, fd will become readable. - * Token is returned when watch is read, to allow matching. - * Returns false on failure. - */ -bool xs_watch(struct xs_handle *h, const char *path, const char *token); - -/* Return the FD to poll on to see if a watch has fired. */ -int xs_fileno(struct xs_handle *h); - -/* Check for node changes. On success, returns a non-NULL pointer ret - * such that ret[0] and ret[1] are valid C strings, namely the - * triggering path (see docs/misc/xenstore.txt) and the token (from - * xs_watch). On error return value is NULL setting errno. - * - * Callers should, after xs_fileno has become readable, repeatedly - * call xs_check_watch until it returns NULL and sets errno to EAGAIN. - * (If the fd became readable, xs_check_watch is allowed to make it no - * longer show up as readable even if future calls to xs_check_watch - * will return more watch events.) - * - * After the caller is finished with the returned information it - * should be freed all in one go with free(ret). - */ -char **xs_check_watch(struct xs_handle *h); - -/* Find out what node change was on (will block if nothing pending). - * Returns array containing the path and token. Use XS_WATCH_* to access these - * elements. Call free() after use. - */ -char **xs_read_watch(struct xs_handle *h, unsigned int *num); - -/* Remove a watch on a node: implicitly acks any outstanding watch. - * Returns false on failure (no watch on that node). - */ -bool xs_unwatch(struct xs_handle *h, const char *path, const char *token); - -/* Start a transaction: changes by others will not be seen during this - * transaction, and changes will not be visible to others until end. - * Returns NULL on failure. - */ -xs_transaction_t xs_transaction_start(struct xs_handle *h); - -/* End a transaction. - * If abandon is true, transaction is discarded instead of committed. - * Returns false on failure: if errno == EAGAIN, you have to restart - * transaction. - */ -bool xs_transaction_end(struct xs_handle *h, xs_transaction_t t, - bool abort); - -/* Introduce a new domain. - * This tells the store daemon about a shared memory page, event channel and - * store path associated with a domain: the domain uses these to communicate. - */ -bool xs_introduce_domain(struct xs_handle *h, - unsigned int domid, - unsigned long mfn, - unsigned int eventchn); - -/* Set the target of a domain - * This tells the store daemon that a domain is targetting another one, so - * it should let it tinker with it. - */ -bool xs_set_target(struct xs_handle *h, - unsigned int domid, - unsigned int target); - -/* Resume a domain. - * Clear the shutdown flag for this domain in the store. - */ -bool xs_resume_domain(struct xs_handle *h, unsigned int domid); - -/* Release a domain. - * Tells the store domain to release the memory page to the domain. - */ -bool xs_release_domain(struct xs_handle *h, unsigned int domid); - -/* Query the home path of a domain. Call free() after use. - */ -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); - -/* Only useful for DEBUG versions */ -char *xs_debug_command(struct xs_handle *h, const char *cmd, - void *data, unsigned int len); - -int xs_suspend_evtchn_port(int domid); -#endif /* _XS_H */ - -/* - * Local variables: - * c-file-style: "linux" - * indent-tabs-mode: t - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_lib.c --- a/tools/xenstore/xs_lib.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs_lib.c Mon May 14 09:31:39 2012 +0100 @@ -23,7 +23,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" /* Common routines for the Xen store daemon and client library. */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_lib.h --- a/tools/xenstore/xs_lib.h Mon May 14 09:11:00 2012 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ -/* - Common routines between Xen store user library and daemon. - Copyright (C) 2005 Rusty Russell IBM Corporation - - 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 St, Fifth Floor, Boston, MA 02110-1301 USA -*/ - -#ifndef _XS_LIB_H -#define _XS_LIB_H - -#include -#include -#include -#include -#include - -/* Bitmask of permissions. */ -enum xs_perm_type { - XS_PERM_NONE = 0, - XS_PERM_READ = 1, - XS_PERM_WRITE = 2, - /* Internal use. */ - XS_PERM_ENOENT_OK = 4, - XS_PERM_OWNER = 8, -}; - -struct xs_permissions -{ - unsigned int id; - enum xs_perm_type perms; -}; - -/* Each 10 bits takes ~ 3 digits, plus one, plus one for nul terminator. */ -#define MAX_STRLEN(x) ((sizeof(x) * CHAR_BIT + CHAR_BIT-1) / 10 * 3 + 2) - -/* Path for various daemon things: env vars can override. */ -const char *xs_daemon_rootdir(void); -const char *xs_daemon_rundir(void); -const char *xs_daemon_socket(void); -const char *xs_daemon_socket_ro(void); -const char *xs_domain_dev(void); -const char *xs_daemon_tdb(void); - -/* Simple write function: loops for you. */ -bool xs_write_all(int fd, const void *data, unsigned int len); - -/* Convert strings to permissions. False if a problem. */ -bool xs_strings_to_perms(struct xs_permissions *perms, unsigned int num, - const char *strings); - -/* Convert permissions to a string (up to len MAX_STRLEN(unsigned int)+1). */ -bool xs_perm_to_string(const struct xs_permissions *perm, - char *buffer, size_t buf_len); - -/* Given a string and a length, count how many strings (nul terms). */ -unsigned int xs_count_strings(const char *strings, unsigned int len); - -/* Sanitising (quoting) possibly-binary strings. */ -struct expanding_buffer { - char *buf; - int avail; -}; - -/* Ensure that given expanding buffer has at least min_avail characters. */ -char *expanding_buffer_ensure(struct expanding_buffer *, int min_avail); - -/* sanitise_value() may return NULL if malloc fails. */ -char *sanitise_value(struct expanding_buffer *, const char *val, unsigned len); - -/* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ -void unsanitise_value(char *out, unsigned *out_len_r, const char *in); - -#endif /* _XS_LIB_H */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_tdb_dump.c --- a/tools/xenstore/xs_tdb_dump.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs_tdb_dump.c Mon May 14 09:31:39 2012 +0100 @@ -5,7 +5,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "tdb.h" #include "talloc.h" #include "utils.h" --=-JAQUWIbHp0H2oacY4bGT Content-Disposition: attachment; filename="qemu-xs-compat.patch" Content-Type: text/x-patch; name="qemu-xs-compat.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit qemu-xen-traditional: use compat xenstore headers. Pending a transition to the new names Signed-off-by: Ian Campbell diff --git a/Makefile b/Makefile index 37c7066..a43ca67 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,7 @@ recurse-all: $(SUBDIR_RULES) CPPFLAGS += -I$(XEN_ROOT)/tools/libxc CPPFLAGS += -I$(XEN_ROOT)/tools/blktap/lib CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS += -I$(XEN_ROOT)/tools/include tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c diff --git a/xen-hooks.mak b/xen-hooks.mak index b55f45b..8e9cadf 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -1,5 +1,6 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS+= -I$(XEN_ROOT)/tools/include SSE2 := $(call cc-option,-msse2,) --=-JAQUWIbHp0H2oacY4bGT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=-JAQUWIbHp0H2oacY4bGT-- From xen-devel-bounces@lists.xen.org Mon May 14 08:35:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08: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 ) id 1STqk0-0005bT-Ii; Mon, 14 May 2012 08:34:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STqjy-0005bG-OD for xen-devel@lists.xensource.com; Mon, 14 May 2012 08:34:51 +0000 Received: from [85.158.139.83:13884] by server-9.bemta-5.messagelabs.com id 75/58-09826-8A3C0BF4; Mon, 14 May 2012 08:34:48 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336984487!27549131!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgwMw==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9394 invoked from network); 14 May 2012 08:34:47 -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; 14 May 2012 08:34:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12450859" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:34: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, 14 May 2012 09:34:46 +0100 Message-ID: <1336984485.31817.17.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Mon, 14 May 2012 09:34:45 +0100 In-Reply-To: <1336801640.3891.17.camel@dagon.hellion.org.uk> References: <20120416154210.GA6338@wavehammer.waldi.eu.org> <1334591484.14560.219.camel@zakaz.uk.xensource.com> <20374.54942.132249.434292@mariner.uk.xensource.com> <1336754999.23818.144.camel@zakaz.uk.xensource.com> <20120511170240.GA15662@wavehammer.waldi.eu.org> <20397.18234.50742.594420@mariner.uk.xensource.com> <1336801640.3891.17.camel@dagon.hellion.org.uk> Organization: Citrix Systems, Inc. Content-Type: multipart/mixed; boundary="=-JAQUWIbHp0H2oacY4bGT" X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bastian Blank , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Rename public xenstore headers X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --=-JAQUWIbHp0H2oacY4bGT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Sat, 2012-05-12 at 06:47 +0100, Ian Campbell wrote: > > You've been shovelling stuff in all day ;-) I'll refresh/resend on > Monday. It applied for me this morning so I suspect you hadn't noticed this: > You did take note of the "git-ness" of the patch though? -- ISTR your > tools had trouble with this format last time. Here it is a gain in non-git format and with the header guards removed from the compat headers as requested. I stuck with the compat subdir. qemu-xs-compat.patch is again attached. 8<-------------------------------- # HG changeset patch # User Ian Campbell # Date 1336984299 -3600 # Node ID e71b19157a4788d8a56bb578f9ddc01cb92c331f # Parent 54fcdee8740f86c9d3ca4f8bf5b780d292cd11f7 xenstore: rename public xenstore headers The xenstore header xs.h is producing conflicts with other software[1]. xs is a too short identifier and does not matche the library. Renaming the headers to xenstore.h and xenstore_lib.h is the easiest way to make them easy recognizable and prevent furthe problems. [1]: http://bugs.debian.org/668550 Signed-off-by: Bastian Blank Signed-off-by: Ian Campbell diff -r 54fcdee8740f -r e71b19157a47 Makefile --- a/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/Makefile Mon May 14 09:31:39 2012 +0100 @@ -241,6 +241,8 @@ uninstall: rm -rf $(D)$(BINDIR)/xenpvnetboot $(D)$(BINDIR)/qemu-*-xen rm -rf $(D)$(INCLUDEDIR)/xenctrl* $(D)$(INCLUDEDIR)/xenguest.h rm -rf $(D)$(INCLUDEDIR)/xs_lib.h $(D)$(INCLUDEDIR)/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore-compat/xs_lib.h $(D)$(INCLUDEDIR)/xensotre-compat/xs.h + rm -rf $(D)$(INCLUDEDIR)/xenstore_lib.h $(D)$(INCLUDEDIR)/xenstore.h rm -rf $(D)$(INCLUDEDIR)/xen rm -rf $(D)$(INCLUDEDIR)/_libxl* $(D)$(INCLUDEDIR)/libxl* rm -rf $(D)$(INCLUDEDIR)/xenstat.h $(D)$(INCLUDEDIR)/xentoollog.h diff -r 54fcdee8740f -r e71b19157a47 extras/mini-os/lib/sys.c --- a/extras/mini-os/lib/sys.c Mon May 14 09:11:00 2012 +0100 +++ b/extras/mini-os/lib/sys.c Mon May 14 09:31:39 2012 +0100 @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 extras/mini-os/lib/xs.c --- a/extras/mini-os/lib/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/extras/mini-os/lib/xs.c Mon May 14 09:31:39 2012 +0100 @@ -9,7 +9,7 @@ #ifdef HAVE_LIBC #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/Makefile --- a/tools/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/tools/Makefile Mon May 14 09:31:39 2012 +0100 @@ -150,7 +150,8 @@ subdir-all-qemu-xen-dir subdir-install-q --source-path=$$source \ --extra-cflags="-I$(XEN_ROOT)/tools/include \ -I$(XEN_ROOT)/tools/libxc \ - -I$(XEN_ROOT)/tools/xenstore" \ + -I$(XEN_ROOT)/tools/xenstore \ + -I$(XEN_ROOT)/tools/xenstore/compat" \ --extra-ldflags="-L$(XEN_ROOT)/tools/libxc \ -L$(XEN_ROOT)/tools/xenstore" \ --bindir=$(LIBEXEC) \ diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/drivers/blktapctrl.c --- a/tools/blktap/drivers/blktapctrl.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/drivers/blktapctrl.c Mon May 14 09:31:39 2012 +0100 @@ -47,7 +47,7 @@ #include #include #include -#include +#include #include #include #ifdef MEMSHR diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/blktaplib.h --- a/tools/blktap/lib/blktaplib.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/blktaplib.h Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/xenbus.c --- a/tools/blktap/lib/xenbus.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/xenbus.c Mon May 14 09:31:39 2012 +0100 @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/blktap/lib/xs_api.c --- a/tools/blktap/lib/xs_api.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/blktap/lib/xs_api.c Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/console/client/main.c --- a/tools/console/client/main.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/client/main.c Mon May 14 09:31:39 2012 +0100 @@ -39,7 +39,7 @@ #include #endif -#include "xs.h" +#include #include "xenctrl.h" #define ESCAPE_CHARACTER 0x1d diff -r 54fcdee8740f -r e71b19157a47 tools/console/daemon/io.c --- a/tools/console/daemon/io.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/daemon/io.c Mon May 14 09:31:39 2012 +0100 @@ -22,7 +22,7 @@ #include "utils.h" #include "io.h" -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/console/daemon/utils.h --- a/tools/console/daemon/utils.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/console/daemon/utils.h Mon May 14 09:31:39 2012 +0100 @@ -26,7 +26,7 @@ #include #include -#include "xs.h" +#include void daemonize(const char *pidfile); bool xen_setup(void); diff -r 54fcdee8740f -r e71b19157a47 tools/libvchan/init.c --- a/tools/libvchan/init.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/libvchan/init.c Mon May 14 09:31:39 2012 +0100 @@ -40,7 +40,7 @@ #include #include -#include +#include #include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/libxl/libxl_internal.h --- a/tools/libxl/libxl_internal.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/libxl/libxl_internal.h Mon May 14 09:31:39 2012 +0100 @@ -44,7 +44,7 @@ #include #include -#include +#include #include #include "xentoollog.h" diff -r 54fcdee8740f -r e71b19157a47 tools/misc/xen-lowmemd.c --- a/tools/misc/xen-lowmemd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/misc/xen-lowmemd.c Mon May 14 09:31:39 2012 +0100 @@ -5,7 +5,7 @@ #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/checkpoint.c --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.c Mon May 14 09:31:39 2012 +0100 @@ -2,7 +2,7 @@ #include -#include +#include #include #include "checkpoint.h" diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/checkpoint.h --- a/tools/python/xen/lowlevel/checkpoint/checkpoint.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/checkpoint.h Mon May 14 09:31:39 2012 +0100 @@ -8,7 +8,7 @@ #include #include -#include +#include typedef enum { dt_unknown, diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Mon May 14 09:31:39 2012 +0100 @@ -11,7 +11,7 @@ #include #include -#include +#include #include "checkpoint.h" diff -r 54fcdee8740f -r e71b19157a47 tools/python/xen/lowlevel/xs/xs.c --- a/tools/python/xen/lowlevel/xs/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/python/xen/lowlevel/xs/xs.c Mon May 14 09:31:39 2012 +0100 @@ -30,7 +30,7 @@ #include #include -#include "xs.h" +#include /** @file * Python interface to the Xen Store Daemon (xs). diff -r 54fcdee8740f -r e71b19157a47 tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/tests/mce-test/tools/xen-mceinj.c Mon May 14 09:31:39 2012 +0100 @@ -38,7 +38,7 @@ #include #include #include -#include +#include #define MCi_type_CTL 0x0 #define MCi_type_STATUS 0x1 diff -r 54fcdee8740f -r e71b19157a47 tools/xcutils/xc_save.c --- a/tools/xcutils/xc_save.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xcutils/xc_save.c Mon May 14 09:31:39 2012 +0100 @@ -19,7 +19,7 @@ #include #include -#include +#include #include #include diff -r 54fcdee8740f -r e71b19157a47 tools/xenbackendd/xenbackendd.c --- a/tools/xenbackendd/xenbackendd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenbackendd/xenbackendd.c Mon May 14 09:31:39 2012 +0100 @@ -28,7 +28,7 @@ #include #include -#include +#include #define DEVTYPE_UNKNOWN 0 #define DEVTYPE_VIF 1 diff -r 54fcdee8740f -r e71b19157a47 tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenpaging/xenpaging.c Mon May 14 09:31:39 2012 +0100 @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include #include "xc_bitops.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenpmd/xenpmd.c --- a/tools/xenpmd/xenpmd.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenpmd/xenpmd.c Mon May 14 09:31:39 2012 +0100 @@ -40,7 +40,7 @@ #include #include #include -#include +#include /* #define RUN_STANDALONE */ #define RUN_IN_SIMULATE_MODE diff -r 54fcdee8740f -r e71b19157a47 tools/xenstat/libxenstat/src/xenstat_priv.h --- a/tools/xenstat/libxenstat/src/xenstat_priv.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstat/libxenstat/src/xenstat_priv.h Mon May 14 09:31:39 2012 +0100 @@ -24,7 +24,7 @@ #define XENSTAT_PRIV_H #include -#include +#include #include "xenstat.h" #include "xenctrl.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/COPYING --- a/tools/xenstore/COPYING Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/COPYING Mon May 14 09:31:39 2012 +0100 @@ -1,6 +1,6 @@ This license (LGPL) applies to the xenstore library which interfaces -with the xenstore daemon (as stated in xs.c, xs.h, xs_lib.c and -xs_lib.h). The remaining files in the directory are licensed as +with the xenstore daemon (as stated in xs.c, xenstore.h, xs_lib.c and +xenstore_lib.h). The remaining files in the directory are licensed as stated in the comments (as of this writing, GPL, see ../../COPYING). diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/Makefile --- a/tools/xenstore/Makefile Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/Makefile Mon May 14 09:31:39 2012 +0100 @@ -109,6 +109,7 @@ install: all $(INSTALL_DIR) $(DESTDIR)$(BINDIR) $(INSTALL_DIR) $(DESTDIR)$(SBINDIR) $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)/xenstore-compat $(INSTALL_DIR) $(DESTDIR)/var/run/xenstored $(INSTALL_DIR) $(DESTDIR)/var/lib/xenstored $(INSTALL_PROG) xenstored $(DESTDIR)$(SBINDIR) @@ -122,8 +123,12 @@ install: all ln -sf libxenstore.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libxenstore.so.$(MAJOR) ln -sf libxenstore.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenstore.so $(INSTALL_DATA) libxenstore.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) xs.h $(DESTDIR)$(INCLUDEDIR) - $(INSTALL_DATA) xs_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) xenstore_lib.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs.h + $(INSTALL_DATA) compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xenstore-compat/xs_lib.h + ln -sf xenstore-compat/xs.h $(DESTDIR)$(INCLUDEDIR)/xs.h + ln -sf xenstore-compat/xs_lib.h $(DESTDIR)$(INCLUDEDIR)/xs_lib.h -include $(DEPS) diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/compat/xs.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/compat/xs.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,2 @@ +#warning xs.h is deprecated use xenstore.h instead +#include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/compat/xs_lib.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/compat/xs_lib.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,2 @@ +#warning xs_lib.h is deprecated use xenstore_lib.h instead +#include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/init-xenstore-domain.c --- a/tools/xenstore/init-xenstore-domain.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/init-xenstore-domain.c Mon May 14 09:31:39 2012 +0100 @@ -7,7 +7,7 @@ #include #include #include -#include +#include #include static uint32_t domid = -1; diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/xenstore.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,236 @@ +/* + Xen Store Daemon providing simple tree-like database. + Copyright (C) 2005 Rusty Russell IBM Corporation + + 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 St, Fifth Floor, Boston, MA 02110-1301 USA +*/ + +#ifndef XENSTORE_H +#define XENSTORE_H + +#include + +#define XBT_NULL 0 + +#define XS_OPEN_READONLY 1UL<<0 +#define XS_OPEN_SOCKETONLY 1UL<<1 + +struct xs_handle; +typedef uint32_t xs_transaction_t; + +/* IMPORTANT: For details on xenstore protocol limits, see + * docs/misc/xenstore.txt in the Xen public source repository, and use the + * XENSTORE_*_MAX limit macros defined in xen/io/xs_wire.h. + */ + +/* On failure, these routines set errno. */ + +/* Open a connection to the xs daemon. + * Attempts to make a connection over the socket interface, + * and if it fails, then over the xenbus interface. + * Mode 0 specifies read-write access, XS_OPEN_READONLY for + * read-only access. + * Returns a handle or NULL. + */ +struct xs_handle *xs_open(unsigned long flags); + +/* Close the connection to the xs daemon. */ +void xs_close(struct xs_handle *xsh); + +/* Connect to the xs daemon. + * Returns a handle or NULL. + * Deprecated, please use xs_open(0) instead + */ +struct xs_handle *xs_daemon_open(void); +struct xs_handle *xs_domain_open(void); + +/* Connect to the xs daemon (readonly for non-root clients). + * Returns a handle or NULL. + * Deprecated, please use xs_open(XS_OPEN_READONLY) instead + */ +struct xs_handle *xs_daemon_open_readonly(void); + +/* Close the connection to the xs daemon. + * Deprecated, please use xs_close() instead + */ +void xs_daemon_close(struct xs_handle *); + +/* Throw away the connection to the xs daemon, for use after fork(). */ +void xs_daemon_destroy_postfork(struct xs_handle *); + +/* Get contents of a directory. + * Returns a malloced array: call free() on it after use. + * Num indicates size. + */ +char **xs_directory(struct xs_handle *h, xs_transaction_t t, + const char *path, unsigned int *num); + +/* Get the value of a single file, nul terminated. + * Returns a malloced value: call free() on it after use. + * len indicates length in bytes, not including terminator. + */ +void *xs_read(struct xs_handle *h, xs_transaction_t t, + const char *path, unsigned int *len); + +/* Write the value of a single file. + * Returns false on failure. + */ +bool xs_write(struct xs_handle *h, xs_transaction_t t, + const char *path, const void *data, unsigned int len); + +/* Create a new directory. + * Returns false on failure, or success if it already exists. + */ +bool xs_mkdir(struct xs_handle *h, xs_transaction_t t, + const char *path); + +/* Destroy a file or directory (and children). + * Returns false on failure, or if it doesn't exist. + */ +bool xs_rm(struct xs_handle *h, xs_transaction_t t, + const char *path); + +/* Restrict a xenstore handle so that it acts as if it had the + * permissions of domain @domid. The handle must currently be + * using domain 0's credentials. + * + * Returns false on failure, in which case the handle continues + * to use the old credentials, or true on success. + */ +bool xs_restrict(struct xs_handle *h, unsigned domid); + +/* Get permissions of node (first element is owner, first perms is "other"). + * Returns malloced array, or NULL: call free() after use. + */ +struct xs_permissions *xs_get_permissions(struct xs_handle *h, + xs_transaction_t t, + const char *path, unsigned int *num); + +/* Set permissions of node (must be owner). + * Returns false on failure. + */ +bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, + const char *path, struct xs_permissions *perms, + unsigned int num_perms); + +/* Watch a node for changes (poll on fd to detect, or call read_watch()). + * When the node (or any child) changes, fd will become readable. + * Token is returned when watch is read, to allow matching. + * Returns false on failure. + */ +bool xs_watch(struct xs_handle *h, const char *path, const char *token); + +/* Return the FD to poll on to see if a watch has fired. */ +int xs_fileno(struct xs_handle *h); + +/* Check for node changes. On success, returns a non-NULL pointer ret + * such that ret[0] and ret[1] are valid C strings, namely the + * triggering path (see docs/misc/xenstore.txt) and the token (from + * xs_watch). On error return value is NULL setting errno. + * + * Callers should, after xs_fileno has become readable, repeatedly + * call xs_check_watch until it returns NULL and sets errno to EAGAIN. + * (If the fd became readable, xs_check_watch is allowed to make it no + * longer show up as readable even if future calls to xs_check_watch + * will return more watch events.) + * + * After the caller is finished with the returned information it + * should be freed all in one go with free(ret). + */ +char **xs_check_watch(struct xs_handle *h); + +/* Find out what node change was on (will block if nothing pending). + * Returns array containing the path and token. Use XS_WATCH_* to access these + * elements. Call free() after use. + */ +char **xs_read_watch(struct xs_handle *h, unsigned int *num); + +/* Remove a watch on a node: implicitly acks any outstanding watch. + * Returns false on failure (no watch on that node). + */ +bool xs_unwatch(struct xs_handle *h, const char *path, const char *token); + +/* Start a transaction: changes by others will not be seen during this + * transaction, and changes will not be visible to others until end. + * Returns NULL on failure. + */ +xs_transaction_t xs_transaction_start(struct xs_handle *h); + +/* End a transaction. + * If abandon is true, transaction is discarded instead of committed. + * Returns false on failure: if errno == EAGAIN, you have to restart + * transaction. + */ +bool xs_transaction_end(struct xs_handle *h, xs_transaction_t t, + bool abort); + +/* Introduce a new domain. + * This tells the store daemon about a shared memory page, event channel and + * store path associated with a domain: the domain uses these to communicate. + */ +bool xs_introduce_domain(struct xs_handle *h, + unsigned int domid, + unsigned long mfn, + unsigned int eventchn); + +/* Set the target of a domain + * This tells the store daemon that a domain is targetting another one, so + * it should let it tinker with it. + */ +bool xs_set_target(struct xs_handle *h, + unsigned int domid, + unsigned int target); + +/* Resume a domain. + * Clear the shutdown flag for this domain in the store. + */ +bool xs_resume_domain(struct xs_handle *h, unsigned int domid); + +/* Release a domain. + * Tells the store domain to release the memory page to the domain. + */ +bool xs_release_domain(struct xs_handle *h, unsigned int domid); + +/* Query the home path of a domain. Call free() after use. + */ +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); + +/* Only useful for DEBUG versions */ +char *xs_debug_command(struct xs_handle *h, const char *cmd, + void *data, unsigned int len); + +int xs_suspend_evtchn_port(int domid); +#endif /* XENSTORE_H */ + +/* + * Local variables: + * c-file-style: "linux" + * indent-tabs-mode: t + * c-indent-level: 8 + * c-basic-offset: 8 + * tab-width: 8 + * End: + */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_client.c --- a/tools/xenstore/xenstore_client.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstore_client.c Mon May 14 09:31:39 2012 +0100 @@ -18,7 +18,7 @@ #include #include #include -#include +#include #include diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_control.c --- a/tools/xenstore/xenstore_control.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstore_control.c Mon May 14 09:31:39 2012 +0100 @@ -2,7 +2,7 @@ #include #include -#include "xs.h" +#include "xenstore.h" int main(int argc, char **argv) diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstore_lib.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tools/xenstore/xenstore_lib.h Mon May 14 09:31:39 2012 +0100 @@ -0,0 +1,85 @@ +/* + Common routines between Xen store user library and daemon. + Copyright (C) 2005 Rusty Russell IBM Corporation + + 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 St, Fifth Floor, Boston, MA 02110-1301 USA +*/ + +#ifndef XENSTORE_LIB_H +#define XENSTORE_LIB_H + +#include +#include +#include +#include +#include + +/* Bitmask of permissions. */ +enum xs_perm_type { + XS_PERM_NONE = 0, + XS_PERM_READ = 1, + XS_PERM_WRITE = 2, + /* Internal use. */ + XS_PERM_ENOENT_OK = 4, + XS_PERM_OWNER = 8, +}; + +struct xs_permissions +{ + unsigned int id; + enum xs_perm_type perms; +}; + +/* Each 10 bits takes ~ 3 digits, plus one, plus one for nul terminator. */ +#define MAX_STRLEN(x) ((sizeof(x) * CHAR_BIT + CHAR_BIT-1) / 10 * 3 + 2) + +/* Path for various daemon things: env vars can override. */ +const char *xs_daemon_rootdir(void); +const char *xs_daemon_rundir(void); +const char *xs_daemon_socket(void); +const char *xs_daemon_socket_ro(void); +const char *xs_domain_dev(void); +const char *xs_daemon_tdb(void); + +/* Simple write function: loops for you. */ +bool xs_write_all(int fd, const void *data, unsigned int len); + +/* Convert strings to permissions. False if a problem. */ +bool xs_strings_to_perms(struct xs_permissions *perms, unsigned int num, + const char *strings); + +/* Convert permissions to a string (up to len MAX_STRLEN(unsigned int)+1). */ +bool xs_perm_to_string(const struct xs_permissions *perm, + char *buffer, size_t buf_len); + +/* Given a string and a length, count how many strings (nul terms). */ +unsigned int xs_count_strings(const char *strings, unsigned int len); + +/* Sanitising (quoting) possibly-binary strings. */ +struct expanding_buffer { + char *buf; + int avail; +}; + +/* Ensure that given expanding buffer has at least min_avail characters. */ +char *expanding_buffer_ensure(struct expanding_buffer *, int min_avail); + +/* sanitise_value() may return NULL if malloc fails. */ +char *sanitise_value(struct expanding_buffer *, const char *val, unsigned len); + +/* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ +void unsanitise_value(char *out, unsigned *out_len_r, const char *in); + +#endif /* XENSTORE_LIB_H */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_core.c --- a/tools/xenstore/xenstored_core.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_core.c Mon May 14 09:31:39 2012 +0100 @@ -44,7 +44,7 @@ #include "utils.h" #include "list.h" #include "talloc.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "xenstored_core.h" #include "xenstored_watch.h" #include "xenstored_transaction.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_core.h --- a/tools/xenstore/xenstored_core.h Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_core.h Mon May 14 09:31:39 2012 +0100 @@ -27,7 +27,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "list.h" #include "tdb.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_transaction.c --- a/tools/xenstore/xenstored_transaction.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_transaction.c Mon May 14 09:31:39 2012 +0100 @@ -33,7 +33,7 @@ #include "xenstored_transaction.h" #include "xenstored_watch.h" #include "xenstored_domain.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" struct changed_node diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xenstored_watch.c --- a/tools/xenstore/xenstored_watch.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xenstored_watch.c Mon May 14 09:31:39 2012 +0100 @@ -27,7 +27,7 @@ #include "talloc.h" #include "list.h" #include "xenstored_watch.h" -#include "xs_lib.h" +#include "xenstore_lib.h" #include "utils.h" #include "xenstored_domain.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs.c --- a/tools/xenstore/xs.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs.c Mon May 14 09:31:39 2012 +0100 @@ -32,7 +32,7 @@ #include #include #include -#include "xs.h" +#include "xenstore.h" #include "list.h" #include "utils.h" diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs.h --- a/tools/xenstore/xs.h Mon May 14 09:11:00 2012 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,236 +0,0 @@ -/* - Xen Store Daemon providing simple tree-like database. - Copyright (C) 2005 Rusty Russell IBM Corporation - - 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 St, Fifth Floor, Boston, MA 02110-1301 USA -*/ - -#ifndef _XS_H -#define _XS_H - -#include - -#define XBT_NULL 0 - -#define XS_OPEN_READONLY 1UL<<0 -#define XS_OPEN_SOCKETONLY 1UL<<1 - -struct xs_handle; -typedef uint32_t xs_transaction_t; - -/* IMPORTANT: For details on xenstore protocol limits, see - * docs/misc/xenstore.txt in the Xen public source repository, and use the - * XENSTORE_*_MAX limit macros defined in xen/io/xs_wire.h. - */ - -/* On failure, these routines set errno. */ - -/* Open a connection to the xs daemon. - * Attempts to make a connection over the socket interface, - * and if it fails, then over the xenbus interface. - * Mode 0 specifies read-write access, XS_OPEN_READONLY for - * read-only access. - * Returns a handle or NULL. - */ -struct xs_handle *xs_open(unsigned long flags); - -/* Close the connection to the xs daemon. */ -void xs_close(struct xs_handle *xsh); - -/* Connect to the xs daemon. - * Returns a handle or NULL. - * Deprecated, please use xs_open(0) instead - */ -struct xs_handle *xs_daemon_open(void); -struct xs_handle *xs_domain_open(void); - -/* Connect to the xs daemon (readonly for non-root clients). - * Returns a handle or NULL. - * Deprecated, please use xs_open(XS_OPEN_READONLY) instead - */ -struct xs_handle *xs_daemon_open_readonly(void); - -/* Close the connection to the xs daemon. - * Deprecated, please use xs_close() instead - */ -void xs_daemon_close(struct xs_handle *); - -/* Throw away the connection to the xs daemon, for use after fork(). */ -void xs_daemon_destroy_postfork(struct xs_handle *); - -/* Get contents of a directory. - * Returns a malloced array: call free() on it after use. - * Num indicates size. - */ -char **xs_directory(struct xs_handle *h, xs_transaction_t t, - const char *path, unsigned int *num); - -/* Get the value of a single file, nul terminated. - * Returns a malloced value: call free() on it after use. - * len indicates length in bytes, not including terminator. - */ -void *xs_read(struct xs_handle *h, xs_transaction_t t, - const char *path, unsigned int *len); - -/* Write the value of a single file. - * Returns false on failure. - */ -bool xs_write(struct xs_handle *h, xs_transaction_t t, - const char *path, const void *data, unsigned int len); - -/* Create a new directory. - * Returns false on failure, or success if it already exists. - */ -bool xs_mkdir(struct xs_handle *h, xs_transaction_t t, - const char *path); - -/* Destroy a file or directory (and children). - * Returns false on failure, or if it doesn't exist. - */ -bool xs_rm(struct xs_handle *h, xs_transaction_t t, - const char *path); - -/* Restrict a xenstore handle so that it acts as if it had the - * permissions of domain @domid. The handle must currently be - * using domain 0's credentials. - * - * Returns false on failure, in which case the handle continues - * to use the old credentials, or true on success. - */ -bool xs_restrict(struct xs_handle *h, unsigned domid); - -/* Get permissions of node (first element is owner, first perms is "other"). - * Returns malloced array, or NULL: call free() after use. - */ -struct xs_permissions *xs_get_permissions(struct xs_handle *h, - xs_transaction_t t, - const char *path, unsigned int *num); - -/* Set permissions of node (must be owner). - * Returns false on failure. - */ -bool xs_set_permissions(struct xs_handle *h, xs_transaction_t t, - const char *path, struct xs_permissions *perms, - unsigned int num_perms); - -/* Watch a node for changes (poll on fd to detect, or call read_watch()). - * When the node (or any child) changes, fd will become readable. - * Token is returned when watch is read, to allow matching. - * Returns false on failure. - */ -bool xs_watch(struct xs_handle *h, const char *path, const char *token); - -/* Return the FD to poll on to see if a watch has fired. */ -int xs_fileno(struct xs_handle *h); - -/* Check for node changes. On success, returns a non-NULL pointer ret - * such that ret[0] and ret[1] are valid C strings, namely the - * triggering path (see docs/misc/xenstore.txt) and the token (from - * xs_watch). On error return value is NULL setting errno. - * - * Callers should, after xs_fileno has become readable, repeatedly - * call xs_check_watch until it returns NULL and sets errno to EAGAIN. - * (If the fd became readable, xs_check_watch is allowed to make it no - * longer show up as readable even if future calls to xs_check_watch - * will return more watch events.) - * - * After the caller is finished with the returned information it - * should be freed all in one go with free(ret). - */ -char **xs_check_watch(struct xs_handle *h); - -/* Find out what node change was on (will block if nothing pending). - * Returns array containing the path and token. Use XS_WATCH_* to access these - * elements. Call free() after use. - */ -char **xs_read_watch(struct xs_handle *h, unsigned int *num); - -/* Remove a watch on a node: implicitly acks any outstanding watch. - * Returns false on failure (no watch on that node). - */ -bool xs_unwatch(struct xs_handle *h, const char *path, const char *token); - -/* Start a transaction: changes by others will not be seen during this - * transaction, and changes will not be visible to others until end. - * Returns NULL on failure. - */ -xs_transaction_t xs_transaction_start(struct xs_handle *h); - -/* End a transaction. - * If abandon is true, transaction is discarded instead of committed. - * Returns false on failure: if errno == EAGAIN, you have to restart - * transaction. - */ -bool xs_transaction_end(struct xs_handle *h, xs_transaction_t t, - bool abort); - -/* Introduce a new domain. - * This tells the store daemon about a shared memory page, event channel and - * store path associated with a domain: the domain uses these to communicate. - */ -bool xs_introduce_domain(struct xs_handle *h, - unsigned int domid, - unsigned long mfn, - unsigned int eventchn); - -/* Set the target of a domain - * This tells the store daemon that a domain is targetting another one, so - * it should let it tinker with it. - */ -bool xs_set_target(struct xs_handle *h, - unsigned int domid, - unsigned int target); - -/* Resume a domain. - * Clear the shutdown flag for this domain in the store. - */ -bool xs_resume_domain(struct xs_handle *h, unsigned int domid); - -/* Release a domain. - * Tells the store domain to release the memory page to the domain. - */ -bool xs_release_domain(struct xs_handle *h, unsigned int domid); - -/* Query the home path of a domain. Call free() after use. - */ -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); - -/* Only useful for DEBUG versions */ -char *xs_debug_command(struct xs_handle *h, const char *cmd, - void *data, unsigned int len); - -int xs_suspend_evtchn_port(int domid); -#endif /* _XS_H */ - -/* - * Local variables: - * c-file-style: "linux" - * indent-tabs-mode: t - * c-indent-level: 8 - * c-basic-offset: 8 - * tab-width: 8 - * End: - */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_lib.c --- a/tools/xenstore/xs_lib.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs_lib.c Mon May 14 09:31:39 2012 +0100 @@ -23,7 +23,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" /* Common routines for the Xen store daemon and client library. */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_lib.h --- a/tools/xenstore/xs_lib.h Mon May 14 09:11:00 2012 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ -/* - Common routines between Xen store user library and daemon. - Copyright (C) 2005 Rusty Russell IBM Corporation - - 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 St, Fifth Floor, Boston, MA 02110-1301 USA -*/ - -#ifndef _XS_LIB_H -#define _XS_LIB_H - -#include -#include -#include -#include -#include - -/* Bitmask of permissions. */ -enum xs_perm_type { - XS_PERM_NONE = 0, - XS_PERM_READ = 1, - XS_PERM_WRITE = 2, - /* Internal use. */ - XS_PERM_ENOENT_OK = 4, - XS_PERM_OWNER = 8, -}; - -struct xs_permissions -{ - unsigned int id; - enum xs_perm_type perms; -}; - -/* Each 10 bits takes ~ 3 digits, plus one, plus one for nul terminator. */ -#define MAX_STRLEN(x) ((sizeof(x) * CHAR_BIT + CHAR_BIT-1) / 10 * 3 + 2) - -/* Path for various daemon things: env vars can override. */ -const char *xs_daemon_rootdir(void); -const char *xs_daemon_rundir(void); -const char *xs_daemon_socket(void); -const char *xs_daemon_socket_ro(void); -const char *xs_domain_dev(void); -const char *xs_daemon_tdb(void); - -/* Simple write function: loops for you. */ -bool xs_write_all(int fd, const void *data, unsigned int len); - -/* Convert strings to permissions. False if a problem. */ -bool xs_strings_to_perms(struct xs_permissions *perms, unsigned int num, - const char *strings); - -/* Convert permissions to a string (up to len MAX_STRLEN(unsigned int)+1). */ -bool xs_perm_to_string(const struct xs_permissions *perm, - char *buffer, size_t buf_len); - -/* Given a string and a length, count how many strings (nul terms). */ -unsigned int xs_count_strings(const char *strings, unsigned int len); - -/* Sanitising (quoting) possibly-binary strings. */ -struct expanding_buffer { - char *buf; - int avail; -}; - -/* Ensure that given expanding buffer has at least min_avail characters. */ -char *expanding_buffer_ensure(struct expanding_buffer *, int min_avail); - -/* sanitise_value() may return NULL if malloc fails. */ -char *sanitise_value(struct expanding_buffer *, const char *val, unsigned len); - -/* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */ -void unsanitise_value(char *out, unsigned *out_len_r, const char *in); - -#endif /* _XS_LIB_H */ diff -r 54fcdee8740f -r e71b19157a47 tools/xenstore/xs_tdb_dump.c --- a/tools/xenstore/xs_tdb_dump.c Mon May 14 09:11:00 2012 +0100 +++ b/tools/xenstore/xs_tdb_dump.c Mon May 14 09:31:39 2012 +0100 @@ -5,7 +5,7 @@ #include #include #include -#include "xs_lib.h" +#include "xenstore_lib.h" #include "tdb.h" #include "talloc.h" #include "utils.h" --=-JAQUWIbHp0H2oacY4bGT Content-Disposition: attachment; filename="qemu-xs-compat.patch" Content-Type: text/x-patch; name="qemu-xs-compat.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit qemu-xen-traditional: use compat xenstore headers. Pending a transition to the new names Signed-off-by: Ian Campbell diff --git a/Makefile b/Makefile index 37c7066..a43ca67 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,7 @@ recurse-all: $(SUBDIR_RULES) CPPFLAGS += -I$(XEN_ROOT)/tools/libxc CPPFLAGS += -I$(XEN_ROOT)/tools/blktap/lib CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS += -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS += -I$(XEN_ROOT)/tools/include tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c diff --git a/xen-hooks.mak b/xen-hooks.mak index b55f45b..8e9cadf 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -1,5 +1,6 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore +CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/compat CPPFLAGS+= -I$(XEN_ROOT)/tools/include SSE2 := $(call cc-option,-msse2,) --=-JAQUWIbHp0H2oacY4bGT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=-JAQUWIbHp0H2oacY4bGT-- From xen-devel-bounces@lists.xen.org Mon May 14 08:56:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:56:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STr4Y-0006CJ-EO; Mon, 14 May 2012 08:56:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STr4X-0006CE-7D for xen-devel@lists.xen.org; Mon, 14 May 2012 08:56:05 +0000 Received: from [85.158.138.51:8359] by server-11.bemta-3.messagelabs.com id B8/79-18894-4A8C0BF4; Mon, 14 May 2012 08:56:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336985763!27014077!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1040 invoked from network); 14 May 2012 08:56:03 -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 May 2012 08:56:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12451388" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:56:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 09:56:02 +0100 Message-ID: <1336985761.31817.30.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "rshriram@cs.ubc.ca" Date: Mon, 14 May 2012 09:56:01 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 16:06 +0100, Shriram Rajagopalan wrote: > On Tue, May 8, 2012 at 9:59 AM, Ian Campbell > wrote: > On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I've not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in > freeze for > > the next release release now, I don't think anything is > going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree > that we use > > with xen-unstable, but considering that we are in freeze > ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release > cycle. > > > Thanks. I will mark these as "deferred to 4.3" and remove from > the list. > If they do go into upstream we can revisit whether we > backport. > > > > Is it still the case that save/restore is waiting on > lib{c,l} patches > > > and Remus is waiting for those? What's the hold up there? > > > > The libxl save/restore patches haven't been applied yet. > > > > Ian J -- have you dropped these or are you waiting for > something? > > > > > > Ian J, also note that the remus libxl patches may not apply cleanly > after > applying stefano's patches (even these might require some re-basing), > given that a lot of patches that came in later (the event based stuff, > Ian C's refactorings,etc) > went in. > > If you could just let me know when they have been committed, I can > certainly rebase mine and post them. Seems like this request was missed -- the libxl save patches seem to be in now, please do rebase+repost. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 08:56:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 08:56:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STr4Y-0006CJ-EO; Mon, 14 May 2012 08:56:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STr4X-0006CE-7D for xen-devel@lists.xen.org; Mon, 14 May 2012 08:56:05 +0000 Received: from [85.158.138.51:8359] by server-11.bemta-3.messagelabs.com id B8/79-18894-4A8C0BF4; Mon, 14 May 2012 08:56:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336985763!27014077!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1040 invoked from network); 14 May 2012 08:56:03 -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 May 2012 08:56:03 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12451388" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 08:56:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 09:56:02 +0100 Message-ID: <1336985761.31817.30.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "rshriram@cs.ubc.ca" Date: Mon, 14 May 2012 09:56:01 +0100 In-Reply-To: References: <1336469655.14542.21.camel@zakaz.uk.xensource.com> <1336474322.14542.61.camel@zakaz.uk.xensource.com> <1336489170.13218.11.camel@cthulhu.hellion.org.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Anthony Perard , xen-devel , Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-05-08 at 16:06 +0100, Shriram Rajagopalan wrote: > On Tue, May 8, 2012 at 9:59 AM, Ian Campbell > wrote: > On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I've not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in > freeze for > > the next release release now, I don't think anything is > going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree > that we use > > with xen-unstable, but considering that we are in freeze > ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release > cycle. > > > Thanks. I will mark these as "deferred to 4.3" and remove from > the list. > If they do go into upstream we can revisit whether we > backport. > > > > Is it still the case that save/restore is waiting on > lib{c,l} patches > > > and Remus is waiting for those? What's the hold up there? > > > > The libxl save/restore patches haven't been applied yet. > > > > Ian J -- have you dropped these or are you waiting for > something? > > > > > > Ian J, also note that the remus libxl patches may not apply cleanly > after > applying stefano's patches (even these might require some re-basing), > given that a lot of patches that came in later (the event based stuff, > Ian C's refactorings,etc) > went in. > > If you could just let me know when they have been committed, I can > certainly rebase mine and post them. Seems like this request was missed -- the libxl save patches seem to be in now, please do rebase+repost. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:22:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrTP-0006Se-3i; Mon, 14 May 2012 09:21:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrTO-0006SW-4Z for xen-devel@lists.xensource.com; Mon, 14 May 2012 09:21:46 +0000 Received: from [85.158.139.83:49904] by server-6.bemta-5.messagelabs.com id 6F/35-13222-9AEC0BF4; Mon, 14 May 2012 09:21:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336987304!21014724!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5556 invoked from network); 14 May 2012 09:21:44 -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; 14 May 2012 09:21:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452077" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:21:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:21:44 +0100 Message-ID: <1336987293.31817.41.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Mon, 14 May 2012 10:21:33 +0100 In-Reply-To: <5e21532dab5b1c31e54e.1336743092@kodo2> References: <5e21532dab5b1c31e54e.1336743092@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > + > +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ > +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + FILE *f; > + int rc = 0; > + unsigned dom, bus, dev, func; > + > + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); > + > + if (f == NULL) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + SYSFS_PCIBACK_DRIVER"/slots"); > + return ERROR_FAIL; > + } > + > + while(fscanf(f, "%x:%x:%x.%x\n", &dom, &bus, &dev, &func)==3) { Shouldn't this 3 be 4 now that you include dom? Also ISTR some change to the precise formatting using by the kernel for BDFs recently (A . became a : or vice versa?). CCing Konrad for input in case it impacts this too. The rest all looked fine. > + if(dom == pcidev->domain > + && bus == pcidev->bus > + && dev == pcidev->dev > + && func == pcidev->func) { > + rc = 1; > + goto out; > + } > + } > +out: > + fclose(f); > + return rc; > +} > + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:22:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrTP-0006Se-3i; Mon, 14 May 2012 09:21:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrTO-0006SW-4Z for xen-devel@lists.xensource.com; Mon, 14 May 2012 09:21:46 +0000 Received: from [85.158.139.83:49904] by server-6.bemta-5.messagelabs.com id 6F/35-13222-9AEC0BF4; Mon, 14 May 2012 09:21:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1336987304!21014724!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5556 invoked from network); 14 May 2012 09:21:44 -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; 14 May 2012 09:21:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452077" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:21:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:21:44 +0100 Message-ID: <1336987293.31817.41.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Mon, 14 May 2012 10:21:33 +0100 In-Reply-To: <5e21532dab5b1c31e54e.1336743092@kodo2> References: <5e21532dab5b1c31e54e.1336743092@kodo2> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 3 of 4 v2] libxl: Introduce pci_assignable_add and pci_assignable_remove X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > + > +/* Scan through /sys/.../pciback/slots looking for pcidev's BDF */ > +static int pciback_dev_has_slot(libxl__gc *gc, libxl_device_pci *pcidev) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + FILE *f; > + int rc = 0; > + unsigned dom, bus, dev, func; > + > + f = fopen(SYSFS_PCIBACK_DRIVER"/slots", "r"); > + > + if (f == NULL) { > + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", > + SYSFS_PCIBACK_DRIVER"/slots"); > + return ERROR_FAIL; > + } > + > + while(fscanf(f, "%x:%x:%x.%x\n", &dom, &bus, &dev, &func)==3) { Shouldn't this 3 be 4 now that you include dom? Also ISTR some change to the precise formatting using by the kernel for BDFs recently (A . became a : or vice versa?). CCing Konrad for input in case it impacts this too. The rest all looked fine. > + if(dom == pcidev->domain > + && bus == pcidev->bus > + && dev == pcidev->dev > + && func == pcidev->func) { > + rc = 1; > + goto out; > + } > + } > +out: > + fclose(f); > + return rc; > +} > + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:24:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STrVf-0006XE-OI; Mon, 14 May 2012 09:24:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrVe-0006X6-0o for xen-devel@lists.xensource.com; Mon, 14 May 2012 09:24:06 +0000 Received: from [193.109.254.147:49326] by server-3.bemta-14.messagelabs.com id 15/0C-23274-53FC0BF4; Mon, 14 May 2012 09:24:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336987444!2277006!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6262 invoked from network); 14 May 2012 09:24:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:24:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452150" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:24: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, 14 May 2012 10:24:04 +0100 Message-ID: <1336987443.31817.43.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Mon, 14 May 2012 10:24:03 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 14:31 +0100, George Dunlap wrote: > pci-assignable-add will always store the driver rebind path, but > pci-assignable-remove will only actually rebind if asked to do so. > > v2: > - Use libxl_device_pci_init() instead of memset() > - Call xlu_cfg_destroy() properly > > Signed-off-by: George Dunlap Acked-by: Ian Campbell (one typo below twice, if you don't end up reposting due to comments on 3/4 I'll fix that up as it goes in) > +static void pciassignable_add(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + libxl_device_pci_init(&pcidev); > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } init [...] > +static void pciassignable_remove(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + libxl_device_pci_init(&pcidev); > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } And again. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:24:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STrVf-0006XE-OI; Mon, 14 May 2012 09:24:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrVe-0006X6-0o for xen-devel@lists.xensource.com; Mon, 14 May 2012 09:24:06 +0000 Received: from [193.109.254.147:49326] by server-3.bemta-14.messagelabs.com id 15/0C-23274-53FC0BF4; Mon, 14 May 2012 09:24:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1336987444!2277006!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6262 invoked from network); 14 May 2012 09:24:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:24:05 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452150" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:24: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, 14 May 2012 10:24:04 +0100 Message-ID: <1336987443.31817.43.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Mon, 14 May 2012 10:24:03 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 4 of 4 v2] xl: Add pci_assignable_add and remove commands X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-05-11 at 14:31 +0100, George Dunlap wrote: > pci-assignable-add will always store the driver rebind path, but > pci-assignable-remove will only actually rebind if asked to do so. > > v2: > - Use libxl_device_pci_init() instead of memset() > - Call xlu_cfg_destroy() properly > > Signed-off-by: George Dunlap Acked-by: Ian Campbell (one typo below twice, if you don't end up reposting due to comments on 3/4 I'll fix that up as it goes in) > +static void pciassignable_add(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + libxl_device_pci_init(&pcidev); > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } init [...] > +static void pciassignable_remove(const char *bdf, int rebind) > +{ > + libxl_device_pci pcidev; > + XLU_Config *config; > + > + libxl_device_pci_init(&pcidev); > + > + config = xlu_cfg_init(stderr, "command line"); > + if (!config) { perror("xlu_cfg_inig"); exit(-1); } And again. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:27:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrYl-0006g1-Aq; Mon, 14 May 2012 09:27:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrYk-0006fw-4o for xen-devel@lists.xen.org; Mon, 14 May 2012 09:27:18 +0000 Received: from [193.109.254.147:31396] by server-11.bemta-14.messagelabs.com id 1B/14-05858-5FFC0BF4; Mon, 14 May 2012 09:27:17 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336987618!2290465!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31685 invoked from network); 14 May 2012 09:26:58 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:26:58 -0000 Received: by wibhr14 with SMTP id hr14so1329445wib.14 for ; Mon, 14 May 2012 02:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=4H37rO4+x915MljWl1uZMlkPC70zfj9w+2yLGKStBXg=; b=y3hX7jU0KzV5YZZao/Nf5BmgHc/5s/MV4aQGYFXb8NgewhkS3OAZ9Ow7iOaZWdpQ6B nzMLQMD1WOrapYmjH+MIeRjsH97nXtwFIKvK12mxUXB2svzEHy6gwk+AARtG1xxjLHXO k7rKQYTetvjIDlIRyLIGizaFqZIug3qFTmxxqpSX5knQTBmy1wCcvLNjOPaL1g9wmfmP vz6IUGKWYHo83tkxKMCcfj3AsgXbnc4HJImF0fLCcn5MO8fOfeI+lEW7ZkJFidzalCt+ nt+7Lou7QQuuKM1c17e+O2JxWFBdLvWd2fQoXfKEHPAHFNdRgVNIJWmCfZSdvg/ACTOy X/qA== Received: by 10.216.142.200 with SMTP id i50mr4661145wej.47.1336987617913; Mon, 14 May 2012 02:26:57 -0700 (PDT) Received: from [127.0.1.1] (ip-178-202.sn2.eutelia.it. [83.211.178.202]) by mx.google.com with ESMTPS id z3sm34991054wix.0.2012.05.14.02.26.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 02:26:56 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 0953e429ec0a517b247fd8334f20799d72112c81 Message-Id: <0953e429ec0a517b247f.1336987609@Solace> User-Agent: Mercurial-patchbomb/2.2.1 Date: Mon, 14 May 2012 11:26:49 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH v2] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xm supports the following syntax (in the config file) for specific VCPU to PCPU mapping: cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 Allow for the same in xl. Signed-off-by: Dario Faggioli diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -108,9 +108,25 @@ created online and the remainder will be =item B List of which cpus the guest is allowed to use. Default behavior is -`all cpus`. A list of cpus may be specified as follows: `cpus="0-3,5,^1"` -(all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus -will run on cpus 2 and 3). +`all cpus`. A C may be specified as follows: + +=over 4 + +=item "all" + +To allow all the vcpus of the guest tov run on all the cpus on the host. + +=item "0-3,5,^1" + +To allow all the vcpus of the guest to run on cpus 0,2,3,5. + +=item [2, 3] + +To ask for specific vcpu mapping. That means (in this example), vcpu #0 +of the guest will run on cpu #2 of the host and vcpu #1 of the guest will +run on cpu #3 of the host. + +=back =item B 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 @@ -71,6 +71,8 @@ static uint32_t domid; static const char *common_domname; static int fd_lock = -1; +/* Stash for specific vcpu to pcpu mappping */ +static int *vcpu_to_pcpu; static const char savefileheader_magic[32]= "Xen saved domain, xl format\n \0 \r"; @@ -630,6 +632,21 @@ static void parse_config_data(const char exit(1); } + /* Prepare the array for single vcpu to pcpu mappings */ + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); + + /* + * Idea here is to let libxl think all the domain's vcpus + * have cpu affinity with all the pcpus on the list. + * It is then us, here in xl, that matches each single vcpu + * to its pcpu (and that's why we need to stash such info in + * the vcpu_to_pcpu array now) after the domain has been created. + * Doing it like this saves the burden of passing to libxl + * some big array hosting the single mappings. Also, using + * the cpumap derived from the list ensures memory is being + * allocated on the proper nodes anyway. + */ libxl_cpumap_set_none(&b_info->cpumap); while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { i = atoi(buf); @@ -638,6 +655,8 @@ static void parse_config_data(const char exit(1); } libxl_cpumap_set(&b_info->cpumap, i); + if (n_cpus < b_info->max_vcpus) + vcpu_to_pcpu[n_cpus] = i; n_cpus++; } } @@ -1714,6 +1733,31 @@ start: if ( ret ) goto error_out; + /* If single vcpu to pcpu mapping was requested, honour it */ + if (vcpu_to_pcpu) { + libxl_cpumap vcpu_cpumap; + + libxl_cpumap_alloc(ctx, &vcpu_cpumap); + for (i = 0; i < d_config.b_info.max_vcpus; i++) { + + if (vcpu_to_pcpu[i] != -1) { + libxl_cpumap_set_none(&vcpu_cpumap); + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); + } else { + libxl_cpumap_set_any(&vcpu_cpumap); + } + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + ret = ERROR_FAIL; + goto error_out; + } + } + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + } + ret = libxl_userdata_store(ctx, domid, "xl", config_data, config_len); if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:27:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrYl-0006g1-Aq; Mon, 14 May 2012 09:27:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrYk-0006fw-4o for xen-devel@lists.xen.org; Mon, 14 May 2012 09:27:18 +0000 Received: from [193.109.254.147:31396] by server-11.bemta-14.messagelabs.com id 1B/14-05858-5FFC0BF4; Mon, 14 May 2012 09:27:17 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1336987618!2290465!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31685 invoked from network); 14 May 2012 09:26:58 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:26:58 -0000 Received: by wibhr14 with SMTP id hr14so1329445wib.14 for ; Mon, 14 May 2012 02:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:user-agent:date:from:to:cc; bh=4H37rO4+x915MljWl1uZMlkPC70zfj9w+2yLGKStBXg=; b=y3hX7jU0KzV5YZZao/Nf5BmgHc/5s/MV4aQGYFXb8NgewhkS3OAZ9Ow7iOaZWdpQ6B nzMLQMD1WOrapYmjH+MIeRjsH97nXtwFIKvK12mxUXB2svzEHy6gwk+AARtG1xxjLHXO k7rKQYTetvjIDlIRyLIGizaFqZIug3qFTmxxqpSX5knQTBmy1wCcvLNjOPaL1g9wmfmP vz6IUGKWYHo83tkxKMCcfj3AsgXbnc4HJImF0fLCcn5MO8fOfeI+lEW7ZkJFidzalCt+ nt+7Lou7QQuuKM1c17e+O2JxWFBdLvWd2fQoXfKEHPAHFNdRgVNIJWmCfZSdvg/ACTOy X/qA== Received: by 10.216.142.200 with SMTP id i50mr4661145wej.47.1336987617913; Mon, 14 May 2012 02:26:57 -0700 (PDT) Received: from [127.0.1.1] (ip-178-202.sn2.eutelia.it. [83.211.178.202]) by mx.google.com with ESMTPS id z3sm34991054wix.0.2012.05.14.02.26.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 02:26:56 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 0953e429ec0a517b247fd8334f20799d72112c81 Message-Id: <0953e429ec0a517b247f.1336987609@Solace> User-Agent: Mercurial-patchbomb/2.2.1 Date: Mon, 14 May 2012 11:26:49 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org, xen-devel@lists.xen.org Cc: Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH v2] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xm supports the following syntax (in the config file) for specific VCPU to PCPU mapping: cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 Allow for the same in xl. Signed-off-by: Dario Faggioli diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -108,9 +108,25 @@ created online and the remainder will be =item B List of which cpus the guest is allowed to use. Default behavior is -`all cpus`. A list of cpus may be specified as follows: `cpus="0-3,5,^1"` -(all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus -will run on cpus 2 and 3). +`all cpus`. A C may be specified as follows: + +=over 4 + +=item "all" + +To allow all the vcpus of the guest tov run on all the cpus on the host. + +=item "0-3,5,^1" + +To allow all the vcpus of the guest to run on cpus 0,2,3,5. + +=item [2, 3] + +To ask for specific vcpu mapping. That means (in this example), vcpu #0 +of the guest will run on cpu #2 of the host and vcpu #1 of the guest will +run on cpu #3 of the host. + +=back =item B 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 @@ -71,6 +71,8 @@ static uint32_t domid; static const char *common_domname; static int fd_lock = -1; +/* Stash for specific vcpu to pcpu mappping */ +static int *vcpu_to_pcpu; static const char savefileheader_magic[32]= "Xen saved domain, xl format\n \0 \r"; @@ -630,6 +632,21 @@ static void parse_config_data(const char exit(1); } + /* Prepare the array for single vcpu to pcpu mappings */ + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); + + /* + * Idea here is to let libxl think all the domain's vcpus + * have cpu affinity with all the pcpus on the list. + * It is then us, here in xl, that matches each single vcpu + * to its pcpu (and that's why we need to stash such info in + * the vcpu_to_pcpu array now) after the domain has been created. + * Doing it like this saves the burden of passing to libxl + * some big array hosting the single mappings. Also, using + * the cpumap derived from the list ensures memory is being + * allocated on the proper nodes anyway. + */ libxl_cpumap_set_none(&b_info->cpumap); while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { i = atoi(buf); @@ -638,6 +655,8 @@ static void parse_config_data(const char exit(1); } libxl_cpumap_set(&b_info->cpumap, i); + if (n_cpus < b_info->max_vcpus) + vcpu_to_pcpu[n_cpus] = i; n_cpus++; } } @@ -1714,6 +1733,31 @@ start: if ( ret ) goto error_out; + /* If single vcpu to pcpu mapping was requested, honour it */ + if (vcpu_to_pcpu) { + libxl_cpumap vcpu_cpumap; + + libxl_cpumap_alloc(ctx, &vcpu_cpumap); + for (i = 0; i < d_config.b_info.max_vcpus; i++) { + + if (vcpu_to_pcpu[i] != -1) { + libxl_cpumap_set_none(&vcpu_cpumap); + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); + } else { + libxl_cpumap_set_any(&vcpu_cpumap); + } + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + ret = ERROR_FAIL; + goto error_out; + } + } + libxl_cpumap_dispose(&vcpu_cpumap); + free(vcpu_to_pcpu); + } + ret = libxl_userdata_store(ctx, domid, "xl", config_data, config_len); if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:29:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STraA-0006m4-QE; Mon, 14 May 2012 09:28:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STra9-0006lz-Qv for xen-devel@lists.xen.org; Mon, 14 May 2012 09:28:46 +0000 Received: from [85.158.138.51:53934] by server-11.bemta-3.messagelabs.com id 69/E4-18894-D40D0BF4; Mon, 14 May 2012 09:28:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336987722!27042379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTIxMDI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30789 invoked from network); 14 May 2012 09:28:44 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330923600"; d="scan'208";a="194660853" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 05:28:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 05:28:41 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1STra5-0007nl-74; Mon, 14 May 2012 10:28:41 +0100 Message-ID: <4FB0D047.7010104@citrix.com> Date: Mon, 14 May 2012 10:28:39 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Bei Guan References: In-Reply-To: Cc: xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bei Guan escribi=F3: > Hi, > > This problem is solved now. > > My environment is 64-bit ubuntu and xl needs to find libyajl from the fol= lowing paths. > > trying file=3D/lib/libyajl.so.2 > trying file=3D/usr/lib/libyajl.so.2 > trying file=3D/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2 > trying file=3D/lib/x86_64-linux-gnu/tls/libyajl.so.2 > ... > > However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 wh= ere I just installed into. > So, a symbolic link is enough to solve this problem. Just like this: > # ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2 I'ts probably best to add /usr/local/lib to LD_LIBRARY_PATH instead = polluting /usr/lib or /lib with symlinks. > Thanks, > Bei Guan > > > > > 2012/5/12 Bei Guan> > Hi, > > When I do "xl list", there is an error like this: > > root@gavin-desktop:~# xl list > xl: error while loading shared libraries: libyajl.so.2: cannot open share= d object file: No such file or directory > > I install the yajl followed this message: > http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html > > After that, the module libyajl.so.2 is copied to /usr/local/lib/. > > Is there any advice on this problem. Thank you so much. > > > Best Regards, > Bei Guan > > > > > -- > Best Regards, > Bei Guan > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:29:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STraA-0006m4-QE; Mon, 14 May 2012 09:28:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STra9-0006lz-Qv for xen-devel@lists.xen.org; Mon, 14 May 2012 09:28:46 +0000 Received: from [85.158.138.51:53934] by server-11.bemta-3.messagelabs.com id 69/E4-18894-D40D0BF4; Mon, 14 May 2012 09:28:45 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1336987722!27042379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTIxMDI=\n X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30789 invoked from network); 14 May 2012 09:28:44 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330923600"; d="scan'208";a="194660853" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 05:28:41 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 05:28:41 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1STra5-0007nl-74; Mon, 14 May 2012 10:28:41 +0100 Message-ID: <4FB0D047.7010104@citrix.com> Date: Mon, 14 May 2012 10:28:39 +0100 From: Roger Pau Monne User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Bei Guan References: In-Reply-To: Cc: xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Bei Guan escribi=F3: > Hi, > > This problem is solved now. > > My environment is 64-bit ubuntu and xl needs to find libyajl from the fol= lowing paths. > > trying file=3D/lib/libyajl.so.2 > trying file=3D/usr/lib/libyajl.so.2 > trying file=3D/lib/x86_64-linux-gnu/tls/x86_64/libyajl.so.2 > trying file=3D/lib/x86_64-linux-gnu/tls/libyajl.so.2 > ... > > However, the actual path of libyajl is /usr/local/lib/libyajl.so.2.0.5 wh= ere I just installed into. > So, a symbolic link is enough to solve this problem. Just like this: > # ln -s /usr/local/lib/libyajl.so.2.0.5 /lib/libyajl.so.2 I'ts probably best to add /usr/local/lib to LD_LIBRARY_PATH instead = polluting /usr/lib or /lib with symlinks. > Thanks, > Bei Guan > > > > > 2012/5/12 Bei Guan> > Hi, > > When I do "xl list", there is an error like this: > > root@gavin-desktop:~# xl list > xl: error while loading shared libraries: libyajl.so.2: cannot open share= d object file: No such file or directory > > I install the yajl followed this message: > http://lists.xen.org/archives/html/xen-users/2012-03/msg00325.html > > After that, the module libyajl.so.2 is copied to /usr/local/lib/. > > Is there any advice on this problem. Thank you so much. > > > Best Regards, > Bei Guan > > > > > -- > Best Regards, > Bei Guan > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:34:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:34:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrfd-00072p-Jn; Mon, 14 May 2012 09:34:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrfb-00072j-Vt for xen-devel@lists.xen.org; Mon, 14 May 2012 09:34:24 +0000 Received: from [193.109.254.147:15856] by server-9.bemta-14.messagelabs.com id ED/D1-05787-F91D0BF4; Mon, 14 May 2012 09:34:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336988062!9084893!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24678 invoked from network); 14 May 2012 09:34:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:34:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452433" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:34: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, 14 May 2012 10:34:22 +0100 Message-ID: <1336988060.31817.51.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 10:34:20 +0100 In-Reply-To: <0953e429ec0a517b247f.1336987609@Solace> References: <0953e429ec0a517b247f.1336987609@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-14 at 10:26 +0100, Dario Faggioli wrote: > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > Allow for the same in xl. > > Signed-off-by: Dario Faggioli > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -108,9 +108,25 @@ created online and the remainder will be > =item B > > List of which cpus the guest is allowed to use. Default behavior is > -`all cpus`. A list of cpus may be specified as follows: `cpus="0-3,5,^1"` > -(all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus > -will run on cpus 2 and 3). > +`all cpus`. A C may be specified as follows: > + > +=over 4 > + > +=item "all" > + > +To allow all the vcpus of the guest tov run on all the cpus on the host. typo: to > + > +=item "0-3,5,^1" > + > +To allow all the vcpus of the guest to run on cpus 0,2,3,5. > + > +=item [2, 3] Is this [2, 3] or ["2", "3"] as you used in the commit message? (would it be confusing the make those distinct, represent the current xl behaviour and xm behaviour respectively?) I think you missed my review on the v1 code when preparing this posting (we probably passed in mid-air)? > + > +To ask for specific vcpu mapping. That means (in this example), vcpu #0 > +of the guest will run on cpu #2 of the host and vcpu #1 of the guest will > +run on cpu #3 of the host. > + > +=back > > =item B > > 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 > @@ -71,6 +71,8 @@ static uint32_t domid; > static const char *common_domname; > static int fd_lock = -1; > > +/* Stash for specific vcpu to pcpu mappping */ > +static int *vcpu_to_pcpu; > > static const char savefileheader_magic[32]= > "Xen saved domain, xl format\n \0 \r"; > @@ -630,6 +632,21 @@ static void parse_config_data(const char > exit(1); > } > > + /* Prepare the array for single vcpu to pcpu mappings */ > + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); > + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); > + > + /* > + * Idea here is to let libxl think all the domain's vcpus > + * have cpu affinity with all the pcpus on the list. > + * It is then us, here in xl, that matches each single vcpu > + * to its pcpu (and that's why we need to stash such info in > + * the vcpu_to_pcpu array now) after the domain has been created. > + * Doing it like this saves the burden of passing to libxl > + * some big array hosting the single mappings. Also, using > + * the cpumap derived from the list ensures memory is being > + * allocated on the proper nodes anyway. > + */ > libxl_cpumap_set_none(&b_info->cpumap); > while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { > i = atoi(buf); > @@ -638,6 +655,8 @@ static void parse_config_data(const char > exit(1); > } > libxl_cpumap_set(&b_info->cpumap, i); > + if (n_cpus < b_info->max_vcpus) > + vcpu_to_pcpu[n_cpus] = i; > n_cpus++; > } > } > @@ -1714,6 +1733,31 @@ start: > if ( ret ) > goto error_out; > > + /* If single vcpu to pcpu mapping was requested, honour it */ > + if (vcpu_to_pcpu) { > + libxl_cpumap vcpu_cpumap; > + > + libxl_cpumap_alloc(ctx, &vcpu_cpumap); > + for (i = 0; i < d_config.b_info.max_vcpus; i++) { > + > + if (vcpu_to_pcpu[i] != -1) { > + libxl_cpumap_set_none(&vcpu_cpumap); > + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); > + } else { > + libxl_cpumap_set_any(&vcpu_cpumap); > + } > + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { > + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + ret = ERROR_FAIL; > + goto error_out; > + } > + } > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + } > + > ret = libxl_userdata_store(ctx, domid, "xl", > config_data, config_len); > if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:34:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:34:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrfd-00072p-Jn; Mon, 14 May 2012 09:34:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrfb-00072j-Vt for xen-devel@lists.xen.org; Mon, 14 May 2012 09:34:24 +0000 Received: from [193.109.254.147:15856] by server-9.bemta-14.messagelabs.com id ED/D1-05787-F91D0BF4; Mon, 14 May 2012 09:34:23 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1336988062!9084893!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24678 invoked from network); 14 May 2012 09:34:22 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2012 09:34:22 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452433" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:34: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, 14 May 2012 10:34:22 +0100 Message-ID: <1336988060.31817.51.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dario Faggioli Date: Mon, 14 May 2012 10:34:20 +0100 In-Reply-To: <0953e429ec0a517b247f.1336987609@Solace> References: <0953e429ec0a517b247f.1336987609@Solace> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] xl: introduce specific VCPU to PCPU mapping in config file X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-05-14 at 10:26 +0100, Dario Faggioli wrote: > xm supports the following syntax (in the config file) for > specific VCPU to PCPU mapping: > > cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3 > > Allow for the same in xl. > > Signed-off-by: Dario Faggioli > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -108,9 +108,25 @@ created online and the remainder will be > =item B > > List of which cpus the guest is allowed to use. Default behavior is > -`all cpus`. A list of cpus may be specified as follows: `cpus="0-3,5,^1"` > -(all vcpus will run on cpus 0,2,3,5), or `cpus=["2", "3"]` (all vcpus > -will run on cpus 2 and 3). > +`all cpus`. A C may be specified as follows: > + > +=over 4 > + > +=item "all" > + > +To allow all the vcpus of the guest tov run on all the cpus on the host. typo: to > + > +=item "0-3,5,^1" > + > +To allow all the vcpus of the guest to run on cpus 0,2,3,5. > + > +=item [2, 3] Is this [2, 3] or ["2", "3"] as you used in the commit message? (would it be confusing the make those distinct, represent the current xl behaviour and xm behaviour respectively?) I think you missed my review on the v1 code when preparing this posting (we probably passed in mid-air)? > + > +To ask for specific vcpu mapping. That means (in this example), vcpu #0 > +of the guest will run on cpu #2 of the host and vcpu #1 of the guest will > +run on cpu #3 of the host. > + > +=back > > =item B > > 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 > @@ -71,6 +71,8 @@ static uint32_t domid; > static const char *common_domname; > static int fd_lock = -1; > > +/* Stash for specific vcpu to pcpu mappping */ > +static int *vcpu_to_pcpu; > > static const char savefileheader_magic[32]= > "Xen saved domain, xl format\n \0 \r"; > @@ -630,6 +632,21 @@ static void parse_config_data(const char > exit(1); > } > > + /* Prepare the array for single vcpu to pcpu mappings */ > + vcpu_to_pcpu = xmalloc(sizeof(int) * b_info->max_vcpus); > + memset(vcpu_to_pcpu, -1, sizeof(int) * b_info->max_vcpus); > + > + /* > + * Idea here is to let libxl think all the domain's vcpus > + * have cpu affinity with all the pcpus on the list. > + * It is then us, here in xl, that matches each single vcpu > + * to its pcpu (and that's why we need to stash such info in > + * the vcpu_to_pcpu array now) after the domain has been created. > + * Doing it like this saves the burden of passing to libxl > + * some big array hosting the single mappings. Also, using > + * the cpumap derived from the list ensures memory is being > + * allocated on the proper nodes anyway. > + */ > libxl_cpumap_set_none(&b_info->cpumap); > while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) { > i = atoi(buf); > @@ -638,6 +655,8 @@ static void parse_config_data(const char > exit(1); > } > libxl_cpumap_set(&b_info->cpumap, i); > + if (n_cpus < b_info->max_vcpus) > + vcpu_to_pcpu[n_cpus] = i; > n_cpus++; > } > } > @@ -1714,6 +1733,31 @@ start: > if ( ret ) > goto error_out; > > + /* If single vcpu to pcpu mapping was requested, honour it */ > + if (vcpu_to_pcpu) { > + libxl_cpumap vcpu_cpumap; > + > + libxl_cpumap_alloc(ctx, &vcpu_cpumap); > + for (i = 0; i < d_config.b_info.max_vcpus; i++) { > + > + if (vcpu_to_pcpu[i] != -1) { > + libxl_cpumap_set_none(&vcpu_cpumap); > + libxl_cpumap_set(&vcpu_cpumap, vcpu_to_pcpu[i]); > + } else { > + libxl_cpumap_set_any(&vcpu_cpumap); > + } > + if (libxl_set_vcpuaffinity(ctx, domid, i, &vcpu_cpumap)) { > + fprintf(stderr, "setting affinity failed on vcpu `%d'.\n", i); > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + ret = ERROR_FAIL; > + goto error_out; > + } > + } > + libxl_cpumap_dispose(&vcpu_cpumap); > + free(vcpu_to_pcpu); > + } > + > ret = libxl_userdata_store(ctx, domid, "xl", > config_data, config_len); > if (ret) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon May 14 09:36:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STrhQ-000792-8g; Mon, 14 May 2012 09:36:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrhO-00078r-3y for xen-devel@lists.xen.org; Mon, 14 May 2012 09:36:14 +0000 Received: from [85.158.143.99:47981] by server-2.bemta-4.messagelabs.com id F3/EB-17550-D02D0BF4; Mon, 14 May 2012 09:36:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336988171!16665841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18762 invoked from network); 14 May 2012 09:36:11 -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; 14 May 2012 09:36:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:36:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:36:10 +0100 Message-ID: <1336988169.31817.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Roger Pau Monne Date: Mon, 14 May 2012 10:36:09 +0100 In-Reply-To: <4FB0D047.7010104@citrix.com> References: <4FB0D047.7010104@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bei Guan , xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gTW9uLCAyMDEyLTA1LTE0IGF0IDEwOjI4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6 Cj4gQmVpIEd1YW4gZXNjcmliacOzOgo+ID4gSGksCj4gPgo+ID4gVGhpcyBwcm9ibGVtIGlzIHNv bHZlZCBub3cuCj4gPgo+ID4gTXkgZW52aXJvbm1lbnQgaXMgNjQtYml0IHVidW50dSBhbmQgeGwg bmVlZHMgdG8gZmluZCBsaWJ5YWpsIGZyb20gdGhlIGZvbGxvd2luZyBwYXRocy4KPiA+Cj4gPiAg ICAgdHJ5aW5nIGZpbGU9L2xpYi9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vdXNy L2xpYi9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vbGliL3g4Nl82NC1saW51eC1n bnUvdGxzL3g4Nl82NC9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vbGliL3g4Nl82 NC1saW51eC1nbnUvdGxzL2xpYnlhamwuc28uMgo+ID4gICAgLi4uCj4gPgo+ID4gSG93ZXZlciwg dGhlIGFjdHVhbCBwYXRoIG9mIGxpYnlhamwgaXMgL3Vzci9sb2NhbC9saWIvbGlieWFqbC5zby4y LjAuNSB3aGVyZSBJIGp1c3QgaW5zdGFsbGVkIGludG8uCj4gPiBTbywgYSBzeW1ib2xpYyBsaW5r IGlzIGVub3VnaCB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIEp1c3QgbGlrZSB0aGlzOgo+ID4gIyBs biAtcyAvdXNyL2xvY2FsL2xpYi9saWJ5YWpsLnNvLjIuMC41IC9saWIvbGlieWFqbC5zby4yCj4g Cj4gSSd0cyBwcm9iYWJseSBiZXN0IHRvIGFkZCAvdXNyL2xvY2FsL2xpYiB0byBMRF9MSUJSQVJZ X1BBVEggaW5zdGVhZCAKPiBwb2xsdXRpbmcgL3Vzci9saWIgb3IgL2xpYiB3aXRoIHN5bWxpbmtz LgoKV2VpcmQgdGhhdCAvdXNyL2xvY2FsLypzb21ldGhpbmcqIGlzbid0IGluIC9ldGMvbGQuc28u Y29uZgooL3Vzci9sb2NhbC9saWIgaXMgdGhlcmUgb24gbXkgRGViaWFuIHN5c3RlbSkKCkluIGFu eSBjYXNlIGl0IGlzIGV2ZW4gYmV0dGVyIHRvIGp1c3QgaW5zdGFsbCB0aGUgbGlieWFqbCBwYWNr YWdlcyBmcm9tCnlvdXIgZGlzdHJvIC0tIHRoZXJlJ3Mgbm8gcmVxdWlyZW1lbnQgdG8gYnVpbGQg aXQgZnJvbSBzb3VyY2UuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Mon May 14 09:36:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09: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 ) id 1STrhQ-000792-8g; Mon, 14 May 2012 09:36:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STrhO-00078r-3y for xen-devel@lists.xen.org; Mon, 14 May 2012 09:36:14 +0000 Received: from [85.158.143.99:47981] by server-2.bemta-4.messagelabs.com id F3/EB-17550-D02D0BF4; Mon, 14 May 2012 09:36:13 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1336988171!16665841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5ODgxMA==\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18762 invoked from network); 14 May 2012 09:36:11 -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; 14 May 2012 09:36:11 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="12452489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 09:36:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:36:10 +0100 Message-ID: <1336988169.31817.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Roger Pau Monne Date: Mon, 14 May 2012 10:36:09 +0100 In-Reply-To: <4FB0D047.7010104@citrix.com> References: <4FB0D047.7010104@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.2.2-1 MIME-Version: 1.0 Cc: Bei Guan , xen-devel Subject: Re: [Xen-devel] Error about loading shared libraries libyajl.so.2 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gTW9uLCAyMDEyLTA1LTE0IGF0IDEwOjI4ICswMTAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6 Cj4gQmVpIEd1YW4gZXNjcmliacOzOgo+ID4gSGksCj4gPgo+ID4gVGhpcyBwcm9ibGVtIGlzIHNv bHZlZCBub3cuCj4gPgo+ID4gTXkgZW52aXJvbm1lbnQgaXMgNjQtYml0IHVidW50dSBhbmQgeGwg bmVlZHMgdG8gZmluZCBsaWJ5YWpsIGZyb20gdGhlIGZvbGxvd2luZyBwYXRocy4KPiA+Cj4gPiAg ICAgdHJ5aW5nIGZpbGU9L2xpYi9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vdXNy L2xpYi9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vbGliL3g4Nl82NC1saW51eC1n bnUvdGxzL3g4Nl82NC9saWJ5YWpsLnNvLjIKPiA+ICAgICB0cnlpbmcgZmlsZT0vbGliL3g4Nl82 NC1saW51eC1nbnUvdGxzL2xpYnlhamwuc28uMgo+ID4gICAgLi4uCj4gPgo+ID4gSG93ZXZlciwg dGhlIGFjdHVhbCBwYXRoIG9mIGxpYnlhamwgaXMgL3Vzci9sb2NhbC9saWIvbGlieWFqbC5zby4y LjAuNSB3aGVyZSBJIGp1c3QgaW5zdGFsbGVkIGludG8uCj4gPiBTbywgYSBzeW1ib2xpYyBsaW5r IGlzIGVub3VnaCB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIEp1c3QgbGlrZSB0aGlzOgo+ID4gIyBs biAtcyAvdXNyL2xvY2FsL2xpYi9saWJ5YWpsLnNvLjIuMC41IC9saWIvbGlieWFqbC5zby4yCj4g Cj4gSSd0cyBwcm9iYWJseSBiZXN0IHRvIGFkZCAvdXNyL2xvY2FsL2xpYiB0byBMRF9MSUJSQVJZ X1BBVEggaW5zdGVhZCAKPiBwb2xsdXRpbmcgL3Vzci9saWIgb3IgL2xpYiB3aXRoIHN5bWxpbmtz LgoKV2VpcmQgdGhhdCAvdXNyL2xvY2FsLypzb21ldGhpbmcqIGlzbid0IGluIC9ldGMvbGQuc28u Y29uZgooL3Vzci9sb2NhbC9saWIgaXMgdGhlcmUgb24gbXkgRGViaWFuIHN5c3RlbSkKCkluIGFu eSBjYXNlIGl0IGlzIGV2ZW4gYmV0dGVyIHRvIGp1c3QgaW5zdGFsbCB0aGUgbGlieWFqbCBwYWNr YWdlcyBmcm9tCnlvdXIgZGlzdHJvIC0tIHRoZXJlJ3Mgbm8gcmVxdWlyZW1lbnQgdG8gYnVpbGQg aXQgZnJvbSBzb3VyY2UuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Mon May 14 09:38:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 May 2012 09:38:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STriw-0007Fc-Sm; Mon, 14 May 2012 09:37:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1STriu-0007FO-UR for xen-devel@lists.xen.org; Mon, 14 May 2012 09:37:49 +0000 Received: from [85.158.139.83:59016] by server-1.bemta-5.messagelabs.com id C4/23-19304-C62D0BF4; Mon, 14 May 2012 09:37:48 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1336988265!27562961!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNTIxMDI=\n X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30681 invoked from network); 14 May 2012 09:37:47 -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; 14 May 2012 09:37:47 -0000 X-IronPort-AV: E=Sophos;i="4.75,584,1330923600"; d="scan'208";a="194661566" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 May 2012 05:36:42 -0400 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 05:36:42 -0400 Received: from [10.80.3.120] (helo=dhcp-3-120.uk.xensource.com.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1STrhp-0007ul-MW; Mon, 14 May 2012 10:36:41 +0100 From: Roger Pau Monne To: xen-devel@lists.xen.org Date: Mon, 14 May 2012 10:36:37 +0100 Message-ID: <1336988197-29450-1-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com, Roger Pau Monne Subject: [Xen-devel] [PATCH v4] libxl: prevent xl from running if xend is running. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Prevent xl from doing any operation if xend daemon is running. That prevents bugs that happened when xl and xend raced to close a domain. Changes since v3: * Refresh to apply to current tree. Changes since v2: * Allow to dry run even if xend is running. * Refresh to apply to current tree. Changes since v1: * Add documentation to xl man page. * Permit the execution of commands that don't modify anything. * Indent error message. Cc: ian.jackson@eu.citrix.com Signed-off-by: Roger Pau Monne --- docs/man/xl.pod.1 | 6 ++ tools/libxl/xl.c | 22 +++++++- tools/libxl/xl.h | 1 + tools/libxl/xl_cmdimpl.c | 5 +- tools/libxl/xl_cmdtable.c | 130 ++++++++++++++++++++++---------------------- 5 files changed, 96 insertions(+), 68 deletions(-) diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 283c9ed..b192efa 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -75,6 +75,12 @@ Verbose. Dry run: do not actually execute the command. +=item B<-f> + +Force execution: xl will refuse to run some commands if it detects that xend is +also running, this option will force the execution of those commands, even +though it is unsafe. + =back =head1 DOMAIN SUBCOMMANDS diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c index d4db1f8..750a61c 100644 --- a/tools/libxl/xl.c +++ b/tools/libxl/xl.c @@ -32,8 +32,11 @@ #include "libxlutil.h" #include "xl.h" +#define XEND_LOCK { "/var/lock/subsys/xend", "/var/lock/xend" } + xentoollog_logger_stdiostream *logger; int dryrun_only; +int force_execution; int autoballoon = 1; char *lockfile; char *default_vifscript = NULL; @@ -126,8 +129,9 @@ int main(int argc, char **argv) char *config_file; void *config_data = 0; int config_len = 0; + const char *locks[] = XEND_LOCK; - while ((opt = getopt(argc, argv, "+vN")) >= 0) { + while ((opt = getopt(argc, argv, "+vfN")) >= 0) { switch (opt) { case 'v': if (minmsglevel > 0) minmsglevel--; @@ -135,6 +139,9 @@ int main(int argc, char **argv) case 'N': dryrun_only = 1; break; + case 'f': + force_execution = 1; + break; default: fprintf(stderr, "unknown global option\n"); exit(2); @@ -185,6 +192,19 @@ int main(int argc, char **argv) ret = 1; goto xit; } + if (cspec->modifies && !dryrun_only) { + for (int i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) { + if (!access(locks[i], F_OK) && !force_execution) { + fprintf(stderr, +"xend is running, which prevents xl from working correctly.\n" +"If you still want to force the execution of xl please use the -f\n" +"option.\n" + ); + ret = 1; + goto xit; + } + } + } ret = cspec->cmd_impl(argc, argv); } else if (!strcmp(cmd, "help")) { help(argv[1]); diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h index 2b6714a..5d0d504 100644 --- a/tools/libxl/xl.h +++ b/tools/libxl/xl.h @@ -21,6 +21,7 @@ struct cmd_spec { char *cmd_name; int (*cmd_impl)(int argc, char **argv); int can_dryrun; + int modifies; char *cmd_desc; char *cmd_usage; char *cmd_option; diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index efaf3de..5fc5cde 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1937,7 +1937,7 @@ void help(const char *command) struct cmd_spec *cmd; if (!command || !strcmp(command, "help")) { - printf("Usage xl [-vN] [args]\n\n"); + printf("Usage xl [-vfN] [args]\n\n"); printf("xl full list of subcommands:\n\n"); for (i = 0; i < cmdtable_len; i++) { printf(" %-19s ", cmd_table[i].cmd_name); @@ -1948,7 +1948,8 @@ void help(const char *command) } else { cmd = cmdtable_lookup(command); if (cmd) { - printf("Usage: xl [-v%s] %s %s\n\n%s.\n\n", + printf("Usage: xl [-v%s%s] %s %s\n\n%s.\n\n", + cmd->modifies ? "f" : "", cmd->can_dryrun ? "N" : "", cmd->cmd_name, cmd->cmd_usage, diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c index 2796460..9d33707 100644 --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -19,7 +19,7 @@ struct cmd_spec cmd_table[] = { { "create", - &main_create, 1, + &main_create, 1, 1, "Create a domain from config file ", " [options] [vars]", "-h Print this help.\n" @@ -33,7 +33,7 @@ struct cmd_spec cmd_table[] = { "-e Do not wait in the background for the death of the domain." }, { "config-update", - &main_config_update, 1, + &main_config_update, 1, 1, "Update a running domain's saved configuration, used when rebuilding " "the domain after reboot", " [options] [vars]", @@ -42,7 +42,7 @@ struct cmd_spec cmd_table[] = { "-d Enable debug messages.\n" }, { "list", - &main_list, 0, + &main_list, 0, 0, "List information about all/some domains", "[options] [Domain]\n", "-l, --long Output all VM details\n" @@ -50,12 +50,12 @@ struct cmd_spec cmd_table[] = { "-Z, --context Prints out security context" }, { "destroy", - &main_destroy, 0, + &main_destroy, 0, 1, "Terminate a domain immediately", "", }, { "shutdown", - &main_shutdown, 0, + &main_shutdown, 0, 1, "Issue a shutdown signal to a domain", "[options] ", "-h Print this help.\n" @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = { "-w Wait for guest to shutdown.\n" }, { "reboot", - &main_reboot, 0, + &main_reboot, 0, 1, "Issue a reboot signal to a domain", "[options] ", "-h Print this help.\n" @@ -72,44 +72,44 @@ struct cmd_spec cmd_table[] = { " no PV drivers.\n" }, { "pci-attach", - &main_pciattach, 0, + &main_pciattach, 0, 1, "Insert a new pass-through pci device", " [Virtual Slot]", }, { "pci-detach", - &main_pcidetach, 0, + &main_pcidetach, 0, 1, "Remove a domain's pass-through pci device", " ", }, { "pci-list", - &main_pcilist, 0, + &main_pcilist, 0, 0, "List pass-through pci devices for a domain", "", }, { "pci-list-assignable-devices", - &main_pcilist_assignable, 0, + &main_pcilist_assignable, 0, 0, "List all the assignable pci devices", "", }, { "pause", - &main_pause, 0, + &main_pause, 0, 1, "Pause execution of a domain", "", }, { "unpause", - &main_unpause, 0, + &main_unpause, 0, 1, "Unpause a paused domain", "", }, { "console", - &main_console, 0, + &main_console, 0, 0, "Attach to domain's console", "[options] \n" "-t console type, pv or serial\n" "-n console number" }, { "vncviewer", - &main_vncviewer, 0, + &main_vncviewer, 0, 0, "Attach to domain's VNC server.", "[options] \n" "--autopass Pass VNC password to viewer via stdin and\n" @@ -117,14 +117,14 @@ struct cmd_spec cmd_table[] = { "--vncviewer-autopass (consistency alias for --autopass)" }, { "save", - &main_save, 0, + &main_save, 0, 1, "Save a domain state to restore later", "[options] []", "-h Print this help.\n" "-c Leave domain running after creating the snapshot." }, { "migrate", - &main_migrate, 0, + &main_migrate, 0, 1, "Save a domain state to restore later", "[options] ", "-h Print this help.\n" @@ -136,12 +136,12 @@ struct cmd_spec cmd_table[] = { " of the domain." }, { "dump-core", - &main_dump_core, 0, + &main_dump_core, 0, 1, "Core dump a domain", " " }, { "restore", - &main_restore, 0, + &main_restore, 0, 1, "Restore a domain from a saved state", "[options] [] ", "-h Print this help.\n" @@ -150,68 +150,68 @@ struct cmd_spec cmd_table[] = { "-d Enable debug messages." }, { "migrate-receive", - &main_migrate_receive, 0, + &main_migrate_receive, 0, 1, "Restore a domain from a saved state", "- for internal use only", }, { "cd-insert", - &main_cd_insert, 0, + &main_cd_insert, 0, 1, "Insert a cdrom into a guest's cd drive", " ", }, { "cd-eject", - &main_cd_eject, 0, + &main_cd_eject, 0, 1, "Eject a cdrom from a guest's cd drive", " ", }, { "mem-max", - &main_memmax, 0, + &main_memmax, 0, 1, "Set the maximum amount reservation for a domain", " ", }, { "mem-set", - &main_memset, 0, + &main_memset, 0, 1, "Set the current memory usage for a domain", " ", }, { "button-press", - &main_button_press, 0, + &main_button_press, 0, 1, "Indicate an ACPI button press to the domain", "